AIニュース速報 2026.07.29 （更新: 2026.07.30）

シャドーAIエージェントの棚卸し手順｜発見・分類・廃止の実務【2026年】

結論：社内のAIエージェントを棚卸しするには、「SaaSの連携アプリ一覧」「OAuth付与済みアプリ」「APIキーの発行履歴」「CI/CDのサービスアカウント」の4つの面を順に洗い出すのが最短ルートです。

Cloud Security Alliance（CSA）が2026年4月21日に公表した調査（418件回答）では、82%の組織が過去1年間に「それまで把握していなかったAIエージェント」を発見しています
棚卸しは「発見 → 分類 → 判断 → 廃止」の4フェーズで進めます。ツール導入より先に、既存の管理画面だけでできる範囲が大きいです
最大の落とし穴は「作りっぱなし」。正式な廃止プロセスを持つ組織はわずか21%でした

この記事の対象読者：情報システム部門・セキュリティ担当者・AI活用推進の責任者
今日やること：Google WorkspaceまたはMicrosoft 465の管理コンソールを開き、サードパーティアプリの連携一覧を1度眺めてみる。それだけで「見覚えのないもの」が見つかることは珍しくありません。

「うちの会社で動いているAIエージェント、全部言えますか？」――生成AI研修やAI導入支援の現場でこの質問をすると、即答できる情シス担当者はほとんどいません。ChatGPTのGPTs、Claudeのエージェント連携、SlackやNotionに刺さった自動化アプリ、開発チームが検証で作ったスクリプト。個々には把握していても、「全体のリスト」を持っている組織は少数派なんです。

これは感覚論ではなくデータで裏付けられています。Cloud Security Alliance（CSA）が2026年4月に公表した調査では、回答組織の68%が「AIエージェントの可視性に自信がある」と答えた一方で、82%が過去1年間に未把握のエージェントを実際に発見していました。「自信」と「実態」のギャップこそが、シャドーAIエージェント問題の本質です。

本記事では、この調査結果の解説は最小限にとどめ、「では、どうやって見つけて、どう整理するのか」という実務手順に全振りします。調査全体の読み解きは関連記事「AIエージェント事故は企業の65%で発生｜CSA調査418件の読み方」で詳しく扱っているので、背景から知りたい方はそちらからどうぞ。

正直、棚卸しは地味な作業です。ただ、専用ツールを買わなくても、いま使っている管理画面だけで7割方は進められます。順番に見ていきましょう。

なぜ今「AIエージェントの棚卸し」なのか

CSA調査が示した「把握していないエージェント」の実態

まず前提となる事実を、原典に忠実に整理します。CSAがToken Securityの委託で実施した調査（2026年1月にオンライン実施、IT・セキュリティ実務者418件回答、2026年4月21日公表）の要点は次の通りです。

82%の組織が、過去1年間に「それまで把握していなかった（unknown / shadow）AIエージェント」を自社環境で発見した。うち41%は複数回発見している
一方で68%は「AIエージェントへの可視性は高い」と自己評価しており、認識と実態が乖離している
65%が過去12ヶ月にAIエージェント関連のインシデントを経験。影響の内訳はデータ露出61%、業務停止44%、金銭的損失45%
正式な廃止（デコミッション）プロセスを持つ組織は21%にとどまる

注意したいのは、82%という数字は「シャドーAIエージェントが82%の環境に存在する」という常時観測値ではなく、「過去1年間に未知のエージェントを発見した組織の割合」だという点です。裏を返せば、探せば見つかる状態が大半の組織で常態化している、と読むのが正確です。

シャドーエージェントは「どこ」から生まれるのか

同調査は、未把握エージェントの発生源も示しています。棚卸しの探索範囲を決めるうえで、ここが実務上いちばん役に立ちます。

社内の自動化・スクリプト環境：51%（RPA、業務スクリプト、ノーコード自動化など）
LLMプラットフォーム上のカスタムツール・アシスタント・プラグイン：47%（GPTsやカスタムエージェントなど）
自動化機能を内蔵したSaaS：40%（CRMやグループウェアのAI機能・連携アプリ）
開発者が作ったワークフロー：40%（CI/CD、検証用ボットなど)

つまり「怪しい野良ツール」だけを探しても不十分で、正規に契約しているSaaSの中と、開発チームの足元にこそシャドーエージェントは潜んでいます。従業員個人によるAIサービスの無断利用（いわゆるシャドーAI全般）への対策は「シャドーAIとは？従業員の8割が無断利用する実態と5つの対策」で扱っており、本記事はその中でも「エージェント（自律的に動くプログラム）」の発見・棚卸しに焦点を絞ります。

フェーズ1：発見｜4つの探索面を順に洗う

棚卸しの第一歩は「発見」です。専用のAIセキュリティ製品がなくても、既存の管理画面には手がかりが揃っています。探索すべき面は次の4つです。

探索面①：SaaSの連携アプリ一覧

最初に見るべきは、IDaaS・グループウェアの管理コンソールにある「連携済みアプリの一覧」です。

Google Workspace：管理コンソールの「アプリのアクセス制御」で、Workspaceのデータにアクセスしているサードパーティアプリと、そのアクセス範囲を一覧できます（Google Workspace管理者ヘルプ）
Microsoft 465 / Entra ID：「エンタープライズアプリケーション」の一覧で、テナントに登録された外部アプリとその権限を確認できます（Microsoft Learn）
Slack・Notion・kintoneなどの業務SaaS：それぞれの管理画面に「インストール済みアプリ」の一覧があります。AI系アプリ（要約ボット、自動返信、議事録連携など）はここに現れます

ここでの目の付け所は「アプリ名にAIと付いているか」ではなく、「メールの読み取り」「ファイルの全読み取り」「代理送信」のような強い権限を持つアプリはどれかです。エージェントの危険度は名前ではなく権限で決まります。

探索面②：OAuth付与済みアプリ（ユーザー単位の承認）

管理者が入れた覚えがなくても、従業員が個人の判断で「Googleでログイン」「アカウントへのアクセスを許可」したアプリは、ユーザー単位でOAuthトークンを持っています。議事録AIやメール下書きAIの多くはこの経路で入ってきます。

Google WorkspaceやEntra IDでは、管理者側からユーザーが同意したアプリとスコープを確認・制限できます。ここで見るべきは次の4点です。

誰が・いつ・どのアプリに同意したか
付与されたスコープ（読み取りだけか、書き込み・送信まで含むか）
最後にトークンが使われたのはいつか（長期間未使用なら失効候補）

探索面③：APIキーの発行履歴

OpenAI・Anthropic・Google AIなどの組織アカウントの管理画面には、APIキーの発行一覧があります。エージェントは最終的に何らかのAPIキーで動いているので、キーの一覧はエージェントの一覧にかなり近い情報源です。確認ポイントは次の通り。

誰の名義で、何個のキーが発行されているか
キーごとの直近の利用状況（使われていないキーは削除候補）
会社のドメイン外（個人アカウント）で契約されたAPI利用がないか。これは経費精算の明細やカード利用履歴から「OpenAI」「Anthropic」等の請求を拾うのが現実的です

探索面④：CI/CDのサービスアカウントと開発環境

CSA調査で発生源の40%を占めた「開発者が作ったワークフロー」の主な生息地がここです。

GitHubなどの組織監査ログ：組織の監査ログで、ワークフローの作成・シークレットの登録・アプリのインストールといったイベントを追えます（GitHub Docs）
CI/CDのシークレット一覧：リポジトリや組織に登録されたシークレットの中に、AI系APIキーが混じっていないか
常駐ボット・cron的な自動実行：検証のつもりで作ったAIボットが、担当者の異動後も動き続けているケースは典型的なシャドーエージェントです

4つの面を洗ったら、発見したものを1つの台帳に集約します。次のプロンプトをそのまま使えば、台帳のたたき台は5分で作れます。

あなたは情報システム部門のアシスタントです。
社内のAIエージェント棚卸し台帳をスプレッドシート形式で設計してください。

列は以下を含めてください：
名称／種別（SaaS連携・OAuthアプリ・APIキー・CI/CDボット）／
作成者・管理者／利用部門／接続先データ（例：メール、顧客DB）／
権限レベル（読み取りのみ・書き込み・外部送信）／
最終稼働日／業務上の必要性（高・中・低）／
判断（残す・権限を絞る・止める）／対応期限

さらに、記入例を4行分ダミーデータで示してください。

フェーズ2：分類｜「誰が・何の権限で・いつまで動いていたか」

発見したエージェントは、リスク判断に必要な4軸で分類します。台帳の核になるのは次の4つの問いです。

分類軸①：誰が作り、誰が面倒を見ているか

オーナー不明のエージェントが最も危険です。作成者が退職・異動していて「触れない・止められない」状態のものは、それだけで最優先の対応対象になります。オーナー確認には、社内への一斉ヒアリングが手っ取り早いです。文面テンプレを置いておきます。

件名：【回答依頼・所要4分】AIツール・自動化の利用状況確認

お疲れさまです。情報システム部です。
社内で利用中のAIツール・自動化の棚卸しを実施しています。
以下に心当たりがある方は、フォームから登録をお願いします。

・ChatGPTのGPTsやカスタムエージェントを業務で使っている
・Slack／Notion等にAI系アプリを追加した
・会社データに接続するAPIキーを発行した
・自動で動くスクリプト・ボットを作った（検証用含む）

※申告による不利益は一切ありません。目的は禁止ではなく、
　安全に使い続けるための現状把握です。

最後の2行が重要です。申告を罰しないと明言しないと、シャドーはさらに深く潜ります。研修の現場でも、「怒られると思って黙っていた」が最も多い未申告理由です。

分類軸②：何のデータに、どの強さの権限で触れるか

権限は「読み取りのみ」「書き込みあり」「外部送信あり」の4段階で色分けするのが実務的です。CSA調査でインシデント影響の第1位がデータ露出（61%）だったことを踏まえると、特に「顧客情報・人事情報に触れる」×「外部送信できる」の組み合わせは最優先でレビューすべきです。

分類軸③：最終稼働日はいつか

90日以上動いていないエージェント・使われていないAPIキーは、業務上の必要性を問うまでもなく失効候補です。「動いていないが権限だけ生きている」状態は、攻撃者にとって格好の侵入口になります。

フェーズ4：判断｜「残す・権限を絞る・止める」の4択に落とす

分類が済んだら、1件ずつ「残す／権限を絞る／止める」の4択に落とします。判断基準を表にまとめます。

判断	該当する条件	具体的なアクション
残す	オーナー明確・業務上の必要性が高い・権限が用途に見合っている	台帳に正式登録し、オーナーと次回レビュー日（半年後など）を記録する
権限を絞る	業務上必要だが、権限が過剰（全読み取り・代理送信など）	スコープを必要最小限に再設定。絞れない仕様なら代替ツールを検討する
止める	オーナー不明・90日以上未稼働・業務上の必要性が説明できない	利用部門に事前通知のうえ、連携解除・トークン失効・キー削除を実施する

ここでよくある失敗パターンを挙げておきます。

❌ 失敗1：いきなり全部止める
⭕ 実は業務の根幹を担っていたエージェントを止めて現場が停止する事故は起こりがちです。「止める」前に必ず利用部門へ通知し、1〜2週間の異議申し立て期間を置きます。

❌ 失敗2：棚卸しを「一度きりの大掃除」にする
⭕ エージェントは毎月増えます。初回の棚卸し後は「四半期ごとの定期レビュー」と「新規導入時の申請ルール」をセットで回さないと、1年後には元通りです。

❌ 失敗4：リスト化だけして判断しない
⭕ 台帳を作って満足してしまうケース。台帳の全行に「判断」と「対応期限」の列を埋めるところまでが棚卸しです。

❌ 失敗4：シャドーの作成者を処罰する
⭕ 処罰すると次からは申告されず、より深いシャドー化を招きます。現場が勝手に作ったエージェントは「業務ニーズの表明」でもあります。止める場合も、代替手段をセットで提示するのが定着のコツです。

フェーズ4：廃止手順の定型化｜21%しか持っていない「終わらせ方」

CSA調査で最も示唆的だったのが、正式な廃止プロセスを持つ組織が21%しかないという点です。エージェントは「作り方」は共有されても「終わらせ方」は誰も決めていない。ここを定型化するだけで、他社の8割と差がつきます。

廃止手順は、次の6ステップをチェックリスト化しておけば十分です。

利用部門への廃止通知（廃止日と代替手段を明記）
OAuthトークン・アクセス権の失効（連携解除だけでなくトークン自体を無効化）
APIキーの削除（無効化ではなく削除。復活の芽を残さない）
サービスアカウント・シークレットの削除（CI/CD側の残骸も忘れずに）
エージェントが保持していたデータの処置（ログ・キャッシュ・学習用データの削除または保管）
台帳への廃止記録（いつ・誰が・何を止めたかを残す）

このチェックリストも、AIに社内向けの様式へ整えさせると早いです。

以下の6ステップを、社内Wikiに掲載する
「AIエージェント廃止手順書」の形式に整えてください。

1. 利用部門への廃止通知（廃止日と代替手段を明記）
2. OAuthトークン・アクセス権の失効
4. APIキーの削除
4. サービスアカウント・シークレットの削除
5. 保持データの処置（削除または保管）
6. 台帳への廃止記録

各ステップに「担当者欄」「実施日欄」「確認者欄」を付け、
チェックボックス付きの表形式にしてください。

AI活用、何から始めればいい？

100社以上の研修実績をもとに、30分の無料相談で貴社の課題を整理します。

無料相談はこちら →

全部は無理なとき：優先順位の付け方

4つの探索面を全部洗うのが理想ですが、情シスが1〜2名の会社では現実的に厳しいこともあります。その場合は、リスクの大きい順に次の優先度で着手してください。

最優先：APIキーの発行一覧。作業量が最も少なく（管理画面を1つ見るだけ）、エージェントの全体像に最も近い情報が得られます。未使用キーの削除だけでも即効性があります
第2優先：OAuth付与済みアプリのうち、強い権限を持つもの。「メール・ファイルの全読み取り」「代理送信」のスコープを持つアプリに絞ってレビューすれば、件数は一気に減ります
第4優先：オーナー不明のもの全般。作成者が退職・異動済みのエージェントは、権限の強弱にかかわらず対応順位を上げます
後回しでよいもの：読み取り権限のみで、社外秘データに触れないエージェント。台帳に載せるだけ載せて、判断は定期レビューに回して構いません

ポイントは「網羅性より先に、最悪ケースの芽を摘む」ことです。CSA調査でインシデントの帰結として最多だったのはデータ露出（61%）でした。つまり「外に出せる権限を持つ未把握エージェント」を潰すことが、費用対効果の最も高い一手になります。逆に、読み取り専用の社内ボットを100件リスト化しても、リスク削減効果は限定的です。

なお、エージェントの権限設計そのものを見直したい場合は、最小権限やゼロトラストの考え方をAIエージェントに適用する議論が進んでいます。台帳の「権限を絞る」判断の物差しとして、こうしたフレームを参照するのも有効です。