>
>
公開日
2026年7月末、AnthropicのAIアシスタント「Claude」で、ユーザーが共有機能で作成した会話ページやArtifactsの一部が、GoogleやBingの検索結果に表示される状態になっていたと報じられました。露出した内容には業務資料や医療記録、暗号資産ウォレットの秘密情報まで含まれていたとされ、生成AIの「共有」という何気ない操作が持つリスクが改めて可視化された事案です。
ただし本件は、Claudeの認証を突破して非公開チャットが盗まれた事故ではありません。利用者自身が公開URLを発行した会話が、想定より広い範囲から発見できる状態だったという構造の問題です。この違いを正しく押さえないと、社内での説明も対応も的を外します。
本記事では、公開情報と一次情報をもとに、何が起きたのか・技術的な原因は何か・情シスとして何を確認し、どう恒久的な統制に落とし込むかを整理します。Claudeそのものの概要や企業利用の考え方は【2026年最新】Claude（クロード）とは？読み方・料金・ChatGPTとの違いを情シス向けに完全解説もあわせてご覧ください。
何が起きたのか｜経過と影響範囲
発覚したのは、Claudeの共有ページのURLパスを指定して検索すると、第三者が共有した会話を大量に発見できる状態だったという事象です。対象は利用者が明示的に共有操作を行った会話に限られ、非公開チャットへの不正アクセスを示す情報は確認されていません。
報道によると、最初の指摘はコミュニティサイトRedditのClaude関連フォーラムに投稿されたものでした。共有ページに共通するURLパスをサイト指定検索に入れることで、多数の共有会話が検索結果に並ぶことが報告され、そこにキーワードを足すと内容に関連した会話を絞り込めることも指摘されています。
時系列（報道ベース）
日時（現地時間） | 出来事 |
|---|---|
2026年7月25日 | RedditのClaudeコミュニティに、サイト指定検索で共有会話を閲覧できるとの投稿（日本時間では7月26日未明） |
7月25〜26日 | 会話ページに加え、Artifactsの公開ページも検索結果に表示されていると複数メディアが報道 |
7月26日〜27日 | Google側で該当クエリの検索結果が表示されなくなったとの確認が広がる |
7月27日時点 | Bingでは報道時点で約612件のインデックス済みページが確認されたと報じられる |
7月27〜28日 | 第三者がGitHub上に共有会話をMarkdown形式で保存したアーカイブが公開状態のまま残存 |
7月28日時点 | Anthropicからは広報担当者のコメントのみで、公式発表としての声明は確認できず |
露出したと報じられている内容
報道で挙げられた例は、日常的な相談から極めて機微なものまで幅がありました。
履歴書やプログラミングの相談、業務資料の下書き
事業計画、未公開の製品ロードマップ、未公開のブログ記事
従業員名が入った給与計算スプレッドシート、社内CRMのエクスポートデータ
臨床試験の計画文書、実在の患者の病歴を含む医療報告書
暗号資産ウォレットのシードフレーズ（口座のマスターパスワードに相当）
弁護士による法律相談、氏名・電話番号などの個人情報
会話ページ側は claude.ai/share 配下、Artifacts側は claude.ai/public/artifacts 配下に格納されるため、この2系統がそれぞれ検索対象になっていたと報じられています。
なお、第三者がGitHub上に保存したアーカイブの件数は、報道や確認のタイミングによって数値が異なります（Claudeの会話410件／3,405メッセージという記載、Claude 453件とGrok 519件で計11,241メッセージという記載など）。いずれにせよ数百件規模の会話が第三者の手元にコピーされたという点が、情シスにとって重要な事実です。
原因は「robots.txtでブロック、noindexは未設定」というズレ
報道各社は、共有ページに noindex メタタグが設定されていなかったことが直接的な原因だと指摘しています。Anthropicはrobots.txtで共有ディレクトリのクロールを拒否していましたが、robots.txtによるクロール拒否は検索結果への表示を防ぐ手段ではありません。
ここは情シスにとって、他社の失敗を自社に転用できる最も価値のあるポイントです。仕組みを分解します。
なぜクロールを拒否していたのにインデックスされたのか
Googleの公式ドキュメントは、robots.txtの Disallow はクローラーにページを取得させない指示であり、URLがWeb上の別の場所に掲載された場合のインデックス登録を妨げるものではないと明記しています。つまり、次のような順序で露出が起きます。
共有ページのURLがRedditやXなどの公開ページに投稿される
検索エンジンはそのリンクからURLの存在を認識する
robots.txtでクロールを拒否されているため、ページの中身は取得できない
中身を取得できないので、ページ内に
noindexがあってもそれを読めない結果として、URLだけがインデックスに登録される
この状態のページは、検索結果に「このページに関する情報はありません」というラベル付きで表示されます。Googleはリンクの存在を知っているが、内容を説明できない状態です。
情シスが自社に持ち帰るべき教訓
この「robots.txtで隠したつもりが、外部リンク経由でインデックスされる」構図は、生成AIに限った話ではありません。自社が抱える次のような資産で、同じ事故が起こり得ます。
対象 | 起こりがちなこと | 正しい打ち手 |
|---|---|---|
社内向け情報を置いた公開ドメイン配下のページ | robots.txtだけで隠したつもりになっている | 認証（Basic認証・IdP認証）でアクセス制御する |
ステージング環境・検証環境 | robots.txtのみで運用し、URLがSlackやチケットに残る | IP制限または認証を必須にする |
検索結果に出したくない公開ページ | robots.txtでブロック＋ページ内にnoindex（矛盾した設定） | クロールは許可し、 |
ファイル共有リンク | 「URLを知る人だけ」という前提で機密を置く | 公開Webページと同じ扱いにし、閲覧者制限と期限を設定する |
押さえておくべき原則は明確です。noindex は検索結果への掲載を抑制する仕組みであり、アクセス制御ではありません。 URLが第三者に渡れば閲覧できますし、一般のクローラーや保存ツールが必ず指示に従う保証もありません。「見せたくないものはアクセス制御する」以外に代替はありません。
Claudeの共有機能の仕様｜どこまでが公開されるのか
Claudeの会話は既定で非公開です。公開されるのは、利用者が共有ボタンを押した時点までの会話スナップショットのみで、共有後に追加したメッセージは自動的には公開されません。ただしプランと共有対象によって公開範囲が大きく異なるため、正確な把握が前提になります。
Anthropicのヘルプセンター（一次情報）をもとに整理すると、次のようになります。
共有対象ごとの公開範囲
共有対象 | プラン | 公開範囲 | 添付ファイルの扱い |
|---|---|---|---|
チャットの共有 | Free / Pro / Max | リンクを知る人が誰でも閲覧可能な公開URL | 添付ファイル自体はスナップショットに含まれない。MCPツール呼び出しの生データも非表示 |
チャットの共有 | Team / Enterprise | 同一組織のメンバーのみ。公開共有は不可 | 同上 |
Artifactsの公開（Publish） | Free / Pro / Max | リンクを知る人が誰でも閲覧・操作可能 | — |
Artifactsの共有（Share） | Team / Enterprise | 同一組織のメンバーのみ。ログイン必須 | 閲覧者は、そのArtifactsを生成した会話内の添付ファイルにもアクセス可能 |
Cowork のライブArtifacts | Team / Enterprise のみ | 組織内限定。どのプランでも公開不可 | — |
ここで見落としやすい差分が2つあります。
1つ目は、チャット共有とArtifacts共有で添付ファイルの扱いが逆になる点です。 通常のチャット共有では添付ファイル自体は含まれませんが、Artifactsを共有する場合、閲覧者は生成元の会話にある添付やファイルにもアクセスできると明記されています。機密資料を読み込ませて作った資料やダッシュボードを共有する運用は、想定以上の範囲を開いてしまいます。
2つ目は、添付ファイルが含まれなくても内容は漏れ得るという点です。 利用者のプロンプトやClaudeの回答本文に、ファイルから読み取った内容・顧客名・個人情報が書き出されていれば、そのテキストは共有対象になります。「ファイルは共有されないから安全」という理解は誤りです。
プランの違いが、そのままリスクの違いになる
今回の事案でもっとも実務的な意味を持つのは、Team / Enterpriseプランでは公開共有そのものが存在しないという点です。裏を返せば、検索露出のリスクを負っていたのは主にFree / Pro / Maxの個人プラン利用者です。
企業にとってこれは、「Claudeが危険かどうか」の問題ではなく、従業員が個人プランを業務で使っている状態（シャドーAI）をどこまで把握できているかの問題に置き換わります。Enterpriseプランでの認証・認可の統制についてはClaude Enterprise認証管理 完全ガイド、Coworkの管理ポイントはClaude Coworkとは？機能・料金・法人利用時の管理ポイントで解説しています。
情シスがまず打つべき5つの手
「Google検索から消えたので対応完了」という判断は避けてください。検索結果からの消失とインターネット上からのデータ消失は別の事象であり、第三者が保存したコピーは共有解除では回収できません。 優先順位は、影響範囲の特定 → 棚卸し → 是正 → 記録の順です。
ステップ1：影響範囲を特定する（当日）
まず確認するのは「自社に該当者がいるか」です。以下のいずれかに当てはまる場合、調査対象になります。
Free / Pro / Max の個人プランでClaudeを業務利用している従業員がいる
会社のメールアドレスで個人プランに登録しているアカウントがある
Team / Enterprise を導入済みだが、個人アカウントとの併用が残っている
ここで問題になるのが、そもそも誰が使っているか分からないケースです。個人プランは経費精算に乗らないことも多く、支出データだけでは捕捉できません。SaaS管理プラットフォームによるSaaS・アカウントの可視化や、Google Workspace / Microsoft 365 のOAuth連携履歴の監査を組み合わせるのが現実的な手段です。手法の比較は情シスのための生成AI 利用状況 可視化ガイドにまとめています。
ステップ2：従業員に共有リンクの棚卸しを依頼する（当日〜3日）
Free / Pro / Max プランでは、利用者自身が過去に作成した共有リンクを一覧で確認できます。手順は次のとおりです。
Claude（Web版）で「設定」を開く
「プライバシー」内の「共有チャット」の「管理」に進む
共有した会話のタイトル・共有日・リンクの一覧を確認する
不要な会話は「共有解除（Unshare）」を選び、非公開に戻す
個別の会話画面から解除する場合は、共有メニューの公開範囲を「Public」から「Private」に変更します。Artifactsを公開している場合は、Artifacts側で「非公開化（Unpublish）」を行います。なお一度非公開にしたArtifactsは同じものを再公開できず、永続ストレージを使っていた場合はそのデータも削除される点に注意してください。
重要な制約が1つあります。組織の管理者が全従業員の共有リンクを横断して一覧確認する仕組みは、個人プランには用意されていません。 そのため、この工程は本人による棚卸しと申告に依存します。依頼文の雛形は後述します。
ステップ3：中身を分類し、リスクを判定する（3日〜1週間）
共有していた会話に以下が含まれていた場合、単なる解除では対応が終わりません。
含まれていた情報 | 必要な追加対応 |
|---|---|
APIキー、秘密鍵、アクセストークン、パスワード | 即時失効・再発行。ローテーション後にログを確認 |
顧客・取引先の個人情報 | 法務／個人情報保護管理者へ連絡し、報告義務の該当性を判断 |
従業員の個人情報（給与・人事評価など） | 人事部門と連携し、影響を受ける本人への説明方針を決定 |
未公開の製品情報、契約条件、社内資料の要約 | 事業部門と共有し、営業秘密としての秘密管理性への影響を評価 |
ソースコード、脆弱性情報、社内システム構成 | セキュリティ部門でリスク評価。必要に応じて設定変更 |
本人の同意なく入力した第三者の情報 | 法務と対応方針を協議 |
個人情報が含まれていた場合の報告義務の有無は、情報の種類・件数・実際の閲覧可能性など個別事情で判断が変わります。一般論で結論を出さず、必ず自社の法務部門および個人情報保護管理者と協議してください。
ステップ4：外部に残ったコピーを前提に判断する
今回の事案では、共有会話が第三者のGitHubリポジトリにMarkdownとして保存されていました。共有を解除しても、次のものは自動的に消えません。
第三者の端末に保存されたコピー
検索エンジンのキャッシュ
Webアーカイブサービスに保存されたスナップショット
GitHubなどに再配布されたテキスト
秘密情報が公開されていた場合は、回収不能を前提に、資格情報のローテーションと影響評価を先に済ませるという判断が妥当です。
ステップ5：記録して報告ラインに乗せる
対応内容は、時系列・確認範囲・是正措置・未確定事項に分けて記録します。監査や後日の照会に耐える形で残しておくと、同種の事案が再発したときの初動が速くなります。
初動チェックリスト
個人プランでのClaude利用者を洗い出した
対象者へ共有リンクの棚卸しを依頼し、完了報告を回収した
共有していた会話の内容を分類し、機微情報の有無を判定した
認証情報が含まれていた場合、失効・再発行を完了した
法務／人事／セキュリティへのエスカレーションを実施した
外部アーカイブに残存する可能性を前提に影響評価を行った
対応記録を作成し、報告ラインに共有した
Team / Enterprise への移行、または利用ポリシーの更新を計画に入れた
従業員向けアナウンス文の雛形
社内周知は、恐怖を煽らず、やることを1つに絞ると完了率が上がります。 以下はそのまま使える雛形です。自社の状況に合わせて調整してください。
恒久対策｜共有リンクを「公開Webページ」として扱う統制設計
個別ツールの不備を追いかける運用は続きません。「共有リンクは公開Webページの発行である」という前提を、プラン・ポリシー・可視化・監査の4層で仕組みに落とすのが本筋です。
第1層：プランで構造的に封じる
最も確実なのは、公開共有という選択肢そのものを利用者から取り上げることです。Claudeの場合、Team / Enterpriseプランでは共有先が同一組織メンバーに限定され、公開URLの発行ができません。
観点 | 個人プラン（Free/Pro/Max） | 法人プラン（Team/Enterprise） |
|---|---|---|
公開共有 | 可能（リンクを知る人が誰でも閲覧） | 不可（組織内限定） |
閲覧時の認証 | 不要 | 組織アカウントでのログインが必須 |
管理者による横断的な共有状況の把握 | 不可 | 組織設定・監査機能で対応 |
Artifactsの公開 | 可能 | 組織内共有のみ |
監査・DLP連携 | なし | Compliance API 経由で監査基盤と連携可能 |
Anthropicは2026年5月に企業管理者向けの Compliance API を提供しており、Claude上で共有された機密データの露出やプロンプトインジェクションを監査基盤側で可視化する連携が進んでいます。詳細はClaude Enterprise認証管理 完全ガイドを参照してください。
第2層：ポリシーに「共有」の条項を追加する
多くの生成AI利用ポリシーは「入力してよい情報／禁止する情報」までは定めていますが、出力後の共有・公開について書かれていないケースが目立ちます。少なくとも次の項目を明記してください。
Claude / ChatGPT / Gemini などの共有URLを、社外秘資料の受け渡しやレビューに使わない
公開リンクを作成するのは、自社Webサイトに掲載しても問題がない情報に限る
共有前に、個人情報・認証情報・顧客名・社内URL・ソースコードの有無を確認する
業務アカウントで作成した共有リンクは、定期的に棚卸しし、不要なものを解除する
機微情報を共有していたことが判明した場合の報告先とエスカレーション経路
ポリシーの雛形と策定手順は情シス必見！AI利用ガイドラインの作り方｜生成AI 社内ルールに必要な10項目にまとめています。
第3層：可視化で「知らない利用」を減らす
ポリシーは、利用実態が見えていなければ空文化します。今回のようなニュースが出たとき、「自社に該当者がいるか」を数時間で答えられる状態かどうかが、初動の質を決めます。
SaaS管理の観点では、次の3点が土台になります。
シャドーIT／シャドーAIの検知：従業員が個人判断で利用しているAIサービスを、SaaSデータベースとの照合やOAuth連携履歴から検出する（シャドーIT検出機能）
アカウントの一元管理：どの従業員がどのサービスにアカウントを持っているかを台帳化し、退職者・異動者の孤立アカウントを残さない（SaaSアカウント管理）
外部公開コンテンツの検知：クラウドストレージやコラボレーションツール上で、意図せず公開状態になったファイルを自動検知しアラートする（外部公開ファイル検知）
3つ目は、今回の事案と本質的に同じ構図を扱う機能です。「共有したつもりが公開になっていた」という事故は、生成AIに限らずGoogle DriveやNotion、Figmaでも日常的に起きます。機能の考え方は「ファイルが公開されてる！」を防ぐ外部共有コンテンツ管理機能で解説しています。
シャドーAIそのものの全体像はシャドーAIとは？リスクと2026年最新の検知・対策ガイドを、生成AI経由の情報漏洩パターンは情シス必見！生成AI・ChatGPTの情報漏洩対策と事例をあわせてご覧ください。
第4層：監査とインシデント手順に組み込む
共有リンクの棚卸しを年次・半期の定期作業に組み込み、機微情報が公開されていた場合の手順（認証情報のローテーション、ログ確認、関係者への通知）をインシデント対応手順書に書き込みます。検索結果から見えなくなったことを対応完了と判断しないという原則を、手順書のレベルで明文化しておくのが有効です。
なぜ同じ事故が繰り返されるのか｜ChatGPT・Grokとの横並び比較
Claudeの事案は初めてのケースではありません。ChatGPT、Grokでも同じ構造の露出が起きており、AIチャットの「共有＝固有の公開URL発行」という設計が、利用者の期待とずれ続けていることを示しています。
項目 | ChatGPT | Grok | Claude |
|---|---|---|---|
発生時期 | 2025年7月末 | 2025年8月下旬 | 2026年7月下旬 |
報じられた規模 | 約4,500件の会話が検索可能（報道） | 37万件以上が検索可能（Forbes報道） | 数百件規模のアーカイブを確認、Bingで約612件（報道時点） |
直接の原因 | 「このチャットを検索エンジンで見つけられるようにする」オプトインのチェックボックス | 共有ページに検索除外設定がなかったと報じられる | 共有ページに |
提供元の対応 | 該当機能を削除。「意図しない共有の機会を作りすぎた」と説明 | noindexタグで修正と報じられる | 検索結果からの消失が確認。公式声明は広報コメントのみ |
残存リスク | Webアーカイブに保存された会話が現在も閲覧可能 | 検索キャッシュ・アーカイブに残存 | 第三者のGitHubアーカイブが公開状態のまま |
3件に共通するのは、次の3点です。
既定は非公開でも、共有操作の一手でアクセス制御のない公開ページが生まれる
利用者の理解は「リンクを渡した相手だけ」で止まっており、検索対象になる可能性を認識していない
提供元が修正しても、第三者に複製された分は回収できない
つまりこれは特定ベンダーの品質問題ではなく、AIチャットという製品カテゴリに共通する構造リスクです。情シスとしては「どのベンダーが安全か」を探すより、どのツールを評価するときも共有機能の公開範囲を必須チェック項目に据えるほうが再現性があります。
主要モデルの企業利用時の比較はChatGPT Work・Gemini Spark・Claude Cowork徹底比較、個別モデルの検討材料はGPT-5.6 情シス向け導入ガイド、Grok 4.5 ガイド、Claude Fable 5 情シス向け導入ガイドをご覧ください。
【共有機能の観点】生成AIツール選定・棚卸しのチェックリスト
新しいAIツールを評価するときに、共有機能の観点を10項目に固定しておくと、今回のような事案が起きても「自社は該当するか」を即答できます。
# | 確認項目 | 望ましい状態 |
|---|---|---|
1 | 会話・生成物の既定の公開範囲 | 非公開が既定である |
2 | 共有リンクの認証方式 | 組織アカウントでのログインを要求できる |
3 | 公開共有の管理者による無効化 | 管理者設定で公開共有そのものを禁止できる |
4 | 検索エンジンへの露出制御 | 共有ページに |
5 | 共有リンクの有効期限 | 期限を設定できる |
6 | 管理者による共有状況の横断把握 | 組織内の共有リンクを一覧・監査できる |
7 | 添付ファイル・連携データの扱い | 共有スナップショットに含まれるかが明文化されている |
8 | 共有解除時の挙動 | 解除で即時に無効化され、挙動が文書化されている |
9 | 監査ログ・DLP連携 | 監査基盤やDLP製品と連携できるAPIがある |
10 | インシデント時の連絡経路 | 提供元のセキュリティ窓口と報告手順が明示されている |
MCPやコネクタ経由で外部データにつながるツールでは、共有時に何が持ち出されるかの見積もりがさらに複雑になります。前提知識はMCPの企業導入ガイド、AIエージェントに認証情報を扱わせる場合の考え方は1Password for Claudeとは？、開発現場での統制はClaude Code 企業利用の統制ガイドにまとめています。
よくある質問（FAQ）
Claudeの非公開チャットが漏洩したのですか？
いいえ。今回検索対象になったのは、利用者が共有機能を操作して公開URLを発行した会話です。Claudeの認証を回避して非公開の会話にアクセスできたことを示す情報は確認されていません。ただし「リンクを渡した相手だけが見る状態」と「検索エンジンから誰でも発見できる状態」は利用者にとって意味が異なるため、実質的な影響は軽視できません。
共有リンクを作ったことがない場合も影響がありますか？
共有リンクを一度も作成していない場合、今回の事象による直接の影響はありません。ただし、自分が共有した記憶がなくても過去の操作を忘れているケースがあるため、設定画面の共有チャット一覧で実際に確認することをおすすめします。
共有を解除すれば元に戻りますか？
共有解除により、それ以降のアクセスは止まります。しかし第三者が既に保存またアーカイブしたコピーは削除されません。今回の事案では、第三者のGitHubリポジトリに会話がMarkdownとして保存されていました。認証情報や機微情報を含んでいた場合は、解除に加えて資格情報のローテーションが必要です。
添付ファイルも公開されたのですか？
Anthropicの説明では、通常のチャット共有スナップショットには添付ファイル自体は含まれず、MCPツール呼び出しの生データも非表示になります。一方、Artifactsを共有する場合は、閲覧者が生成元の会話にある添付やファイルにもアクセスできると明記されています。また、ファイルから読み取った内容がプロンプトや回答本文に書き出されていれば、そのテキストは共有対象になります。
Team／Enterpriseプランなら安全ですか？
Team / Enterpriseプランでは、チャットもArtifactsも同一組織のメンバーにしか共有できず、公開URLの発行そのものができません。この点で今回の検索露出リスクは構造的に回避されています。ただし組織内共有の範囲設計、プロジェクト単位のアクセス権、退職者アカウントの残存といった管理は引き続き必要です。
Google検索から消えたので、情シスの対応は不要ですか？
対応は必要です。検索結果からの消失は「発見しやすさ」が下がっただけで、データが消えたわけではありません。共有URLを直接知っている人はアクセスできる状態が続く可能性があり、外部アーカイブに保存された分も残ります。少なくとも、社内で誰が共有リンクを作成していたかの棚卸しは実施すべきです。
情シスは全社員の共有リンクを一覧で確認できますか？
Free / Pro / Max の個人プランでは、共有リンクの一覧は利用者本人の設定画面からしか確認できず、管理者が横断的に把握する仕組みはありません。そのため個人プラン中心の環境では、本人による棚卸しと申告に依存します。組織として共有状況を管理したい場合は、Team / Enterpriseプランへの移行が前提になります。
個人情報が含まれていた場合、報告義務はありますか？
報告義務の該当性は、情報の種類・件数・実際に第三者が閲覧した可能性など、個別事情によって判断が変わります。一般論で結論を出すべき領域ではありません。個人情報や顧客情報が含まれていた場合は、速やかに自社の法務部門・個人情報保護管理者・インシデント対応部門に連絡し、外部保存の有無を含めた影響評価を行ってください。
まとめ
今回の事案から情シスが持ち帰るべき点を整理します。
本質は不正アクセスではなく、共有機能の公開範囲と利用者の期待のズレです。 社内説明もこの前提で組み立てるほうが伝わります。
技術的な原因は、robots.txtでのクロール拒否と
noindex未設定の組み合わせです。 クロール拒否はインデックスを防ぎません。この構図は自社の公開ドメインやステージング環境にも当てはまります。Team / Enterpriseプランでは公開共有ができません。 リスクを負っていたのは主に個人プラン利用者であり、問題はシャドーAIの可視化に帰着します。
共有解除は対応の一部にすぎません。 認証情報のローテーション、法務・人事への連携、外部アーカイブ残存を前提とした影響評価まで含めて初動を設計してください。
同種の事故はChatGPT、Grokでも起きています。 ツール選定時の必須チェック項目として、共有機能の公開範囲を固定しておくことをおすすめします。
生成AIの利用を止めずに安全性を担保するには、「誰がどのツールを使っているか」を継続的に把握できる状態が土台になります。マネーフォワード Adminaは、SaaS・アカウント・デバイスの統合管理とシャドーIT検出、外部公開ファイルの自動検知により、この土台づくりを支援します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
