先に結論：直すべきは脆弱性ではなく、連携の管理不在
2026年7月23日、イスラエルのセキュリティ企業Zenity Labsが「AgentForger」と名付けた脆弱性を公開した（Zenity Labs: AgentForger, Part 1 — ChatGPT Cross-Site Agent Forgery）。細工されたリンクを従業員が1回クリックするだけで、ChatGPT上に攻撃者が遠隔操作する自律AIエージェントが作られ、その従業員が既に許可していたGmail・Outlook・SharePointなどの連携をそのまま引き継ぐ——というものだ。作られたエージェントは承認確認を「常に許可」に切り替え、5分おきに攻撃者からの指示を受け取り、メールやファイルを読み書き・削除し、結果を外部へ送信する。
まず落ち着いて押さえるべき事実がある。この脆弱性はOpenAIが既に修正した。 Zenityは2026年6月4日にBugcrowd経由で報告し、OpenAIは翌6月5日に受理、6月8日には脆弱なURLパラメータを削除している。つまり「今すぐ何かにパッチを当てないと危ない」という話ではない。
にもかかわらずこの一件を取り上げるのは、AgentForgerが中小・中堅企業の経営者にとって本当に危険な構造を可視化したからだ。攻撃が成立する前提は、たった一つ——従業員が、業務で使うメールやファイル置き場へのアクセスをAIエージェントに既に許可していること。そしてその状態を、多くの会社では経営者も情シスも把握していない。脆弱性は直せても、「誰が・どのAIに・どの業務データへのアクセスを許しているか」を会社が管理していない状態は、直っていない。次に別の連携機能で同じことが起きたとき、被害を受けるかどうかはそこで決まる。
この記事は、AgentForgerの仕組みを正確に理解したうえで、AIエージェントに社内データの連携を許可する前に、経営者として何を決めておくべきかを、非ITの意思決定者が使えるチェックリストと判断軸の形で示す。
この記事の対象読者：ChatGPTやAIエージェントの業務利用が社内で始まっている（または黙認している）年商1〜10億円規模の経営者・事業責任者・兼任情シス。専任の情報セキュリティ担当がおらず、「便利そうだから使わせているが、リスクの全体像が見えない」という状態の方。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
AgentForgerは何を突いたのか——「新しいCSRF」の正体
従来のCSRFとの違い
AgentForgerは、Zenity自身が「Cross-Site Agent Forgery（クロスサイト・エージェント・フォージェリ）」と呼ぶ、新種の攻撃だ。名前が示す通り、古くから知られる**CSRF（クロスサイト・リクエスト・フォージェリ）**のAIエージェント版にあたる。
従来のCSRFは、ログイン中の利用者に細工リンクを踏ませ、本人が意図しない操作を1回だけ実行させる攻撃だった。たとえば「パスワードを変更する」「送金する」といった単発の操作だ。AgentForgerが恐ろしいのは、踏ませた瞬間に実行される「意図しない操作」の中身が、単発の操作ではなく、自律的に動き続けるシステムそのものの作成である点だ。
横にスクロールして確認できます
| 観点 | 従来のCSRF | AgentForger（Cross-Site Agent Forgery） |
|---|---|---|
| 踏ませて起きること | 1回の意図しない操作 | 自律エージェントの作成・公開 |
| 継続性 | その場限り | 作成後も動き続ける（5分おきに指令確認） |
| 引き継ぐ権限 | その操作の権限のみ | 本人が認可済みの全連携（メール・ファイル・チャット） |
| 攻撃者の関与 | 事前に仕込んだ1操作 | 事後もメール経由で継続的に指令できる |
| 気づきやすさ | 操作履歴に残ることがある | 正規機能で作られた「本人名義のエージェント」に見える |
攻撃が成立する3つの条件
Zenityの技術解説によれば、この攻撃が成立するには被害者側に次の3つがそろっている必要があった。逆に言えば、これは「あなたの会社に当てはまるか」のチェックリストにもなる。
- 従業員がChatGPTにログインしている（業務端末で開きっぱなしは珍しくない）
- ワークスペースエージェント（Workspace Agents）機能が使える状態にある
- 少なくとも1つの業務コネクタを認可済み——Outlook、Gmail、Slack、Google Drive、SharePoint、Teamsなど、一度つなぐと以後は認証画面が出ない
この3つ目が肝だ。コネクタは一度認可すると、次からOAuthの同意画面が出ない。だから偽造エージェントが連携を引き継いでも、本人には新しい認証確認が一切表示されない。「知らないアプリがアクセスを求めています」という見慣れた警告すら出ないまま、攻撃者の手先が本人の権限で動き出す。
作られたエージェントは何をするのか
Zenityが実証（PoC）で作らせたエージェントの挙動は、そのまま「AIエージェントに強い権限を渡すと何が起きるか」の教科書になっている。
- 本人が認可済みのコネクタを自動で紐づける
- Outlookの承認確認を「常に許可（Never ask）」に切り替え、人間の確認をなくす
- 「5分おき（00分・05分・10分…）」の定期実行スケジュールで公開し、実質5分間隔で攻撃者の指令を確認する
- 攻撃者が管理するアドレスからのメールを監視し、そこに書かれた命令を実行する
- メール・カレンダー・ファイル保管・チーム連携ツールに対し「読み取り・書き込み・削除」を行い、取得したデータをマスキングせずそのまま外部へ送信する
つまり、一度作られれば、初回のフィッシングが終わった後も長期間にわたって「本人になりすました内通者」として動き続ける。機微データの持ち出し、認証情報やMFAトークンの収集、本人名義でのメール送信——いずれも可能だった。なお現時点でCVE番号やCVSSスコアは付与されていない（研究者による報告と修正で完結したため）。
なぜ「うちの会社の問題」なのか——シャドーAIという前提
ここまでは技術の話だ。だが本題は、この構造がすでに多くの中小・中堅企業に存在しているという点にある。
多くの会社で、ChatGPTの業務利用は「会社が導入を決めた」のではなく「従業員が便利だから使い始めた」形で広がっている。いわゆるシャドーAIだ。そして生成AIが「文章を作る道具」から「メールを読んで返信し、ファイルを整理する道具（エージェント）」へ進化するにつれ、従業員は自然に、業務メールやクラウドストレージへの連携を自分の判断で許可していく。便利にするほど、AIに渡す権限は広がる。
経営者の視点で怖いのは、次の3点が同時に成り立っていることだ。
- 把握していない：どの従業員が、どのAIに、どの業務データへのアクセスを許可しているか、会社は一覧を持っていない。
- 止められない：許可は個人のアカウント上で完結するため、会社側に「取り消す」ボタンがない。
- 気づけない：AgentForgerのように正規機能を悪用されると、不正なアクセスが「本人の正当な利用」と見分けがつかない。
AgentForgerという特定の脆弱性はふさがれた。しかし、この3点がそろった状態は、AIエージェントの新機能が出るたびに新しい攻撃面を生む。直すべきは個別の脆弱性ではなく、連携を野放しにしている管理の不在のほうだ。 これは、AIエージェントに高権限の操作を任せる危うさとして繰り返し論じてきた論点でもある（AIエージェントに任せてはいけない高リスク操作の一覧）。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
発注前ガバナンスの型——連携を許可する前に決める4ステップ
では、経営者として何をすればいいのか。「AIを禁止する」は現実的でも得策でもない。生産性を捨てることになるうえ、禁止しても隠れて使われるだけだ。目指すのは禁止ではなく、管理された許可である。GXOがAI導入の可否を第三者として診断する際に使っている観点を、4ステップに落とすと次のようになる。
ステップ1：棚卸し——「誰が・どのAIに・何を許可しているか」を一覧化する
最初にやるのは、新しいツールの導入でも規程の作成でもなく、現状の可視化だ。次の3つを従業員に申告してもらう（または管理者機能で確認する）。
- 業務で使っているAIサービス名（ChatGPT、Copilot、Geminiなど）とアカウント種別（個人／法人契約）
- そのAIに認可している連携（メール、カレンダー、ストレージ、チャット、SaaS）
- その連携を使って何を自動化しているか（返信、要約、ファイル整理、外部送信など）
この棚卸しがないまま規程だけ作っても、守られているかを確認できない。逆に一覧さえあれば、「営業部の3人がGmail連携を許可している」「経理が請求書フォルダへのアクセスをAIに渡している」といった具体的なリスクの所在が見える。
ステップ2：許可基準——データの機微度で連携の可否を分ける
次に、どの業務データなら連携を許可してよいかの基準を、データの機微度で3段階に分ける。禁止事項を羅列するのではなく、「この区分なら許可、この区分は要承認、この区分は禁止」という判断の型にするのがコツだ。
横にスクロールして確認できます
| 機微度 | 例 | AIエージェント連携の方針 |
|---|---|---|
| 低（公開情報・社内一般） | 製品カタログ、公開済み資料、社内共有の一般文書 | 連携可。ただし外部送信の範囲は確認 |
| 中（業務データ） | 通常の業務メール、社内スケジュール、案件資料 | 承認制。承認ゲートを外さないことを条件に許可 |
| 高（機微・法規制対象） | 個人情報、要配慮個人情報、契約書、財務、認証情報 | 原則連携禁止。必要なら閉じた環境で個別設計 |
「高」に何が入るかは業種で変わる。人事総務が扱う健診結果や産業医記録は要配慮個人情報にあたり得るため、AIへの入力・連携の線引きは特に慎重に決める必要がある（この論点は社員が機微データをAIに入力する前の可否基準の作り方で詳しく整理している）。
ステップ3：承認ゲート——「常に許可」を作らせない
AgentForgerが決定的な被害に至った分岐点は、偽造エージェントが承認確認を「常に許可（Never ask）」に切り替えた瞬間だった。人間の確認をなくした自律動作こそが、内通者を成立させた。
裏を返せば、防御側の設計原則も明快だ。AIエージェントに、外部送信・削除・権限変更のような不可逆な操作を人間の承認なしで実行させない。 具体的には次を組織のルールとして固定する。
- メール送信・ファイル削除・外部共有は、都度の人間承認を必須にする（「常に許可」を禁止設定にする）
- 定期実行（スケジュール）で自律的に外部と通信するエージェントは、申請・承認制にする
- 誰が承認権限を持つかを明確にし、承認ログを残す
この「不可逆な操作には承認ゲート」という考え方は、AIエージェント一般の権限設計の基本であり、コネクタ連携の権限をどう絞るかはChatGPTコネクタの権限設計とOpenAIワークスペースエージェントのガバナンスで具体的に扱っている。
ステップ4：監査——「本人の正当な利用」と見分ける仕組み
最後に、平常時から誰がどのエージェントを作り、どの連携で何をしているかを定期的に点検する仕組みを持つ。AgentForgerの怖さは「正規機能で作られたため不正と見分けにくい」点にあった。だからこそ、定期的な棚卸しの更新と、身に覚えのないエージェント・スケジュール・連携がないかの確認を運用に組み込む。専任の担当を置けない会社は、この点検を外部のセキュリティ診断に定期委託する選択肢もある（セキュリティ診断・セキュリティ顧問（リテイナー））。
導入前チェックリスト（経営者が10分で確認できる）
自社のAIエージェント利用が「管理された許可」になっているかを、次の10項目で確認してほしい。3つ以上に「いいえ／わからない」がつくなら、連携を広げる前に整理が必要な状態だ。
- 従業員が業務で使っているAIサービスを、会社は一覧で把握しているか
- どのAIに、どの業務データ（メール・ファイル・SaaS）への連携を許可しているかを把握しているか
- 個人アカウントではなく、管理機能のある法人契約に統一できているか
- 機微度の高いデータ（個人情報・契約・財務）のAI連携を原則禁止にしているか
- メール送信・削除・外部共有など不可逆な操作に、人間の承認を必須にしているか
- 「常に許可」で承認ゲートを外す運用を禁止しているか
- 従業員が自律実行スケジュールを持つエージェントを勝手に作れない、または申請制になっているか
- 退職者・異動者のAI連携を速やかに取り消せる手順があるか
- 身に覚えのないエージェント・連携がないかを定期点検しているか
- AI利用のルールが「文書化」だけでなく「守られているかの確認」まで設計されているか
この記事のまとめと、GXOに相談すべきタイミング
AgentForgerは、修正済みの一過性の脆弱性として消費してよい話ではない。それが可視化したのは、AIエージェント連携という新しい攻撃面が、経営者の知らないうちに社内へ入り込んでいるという構造だ。防ぐべきは次の脆弱性ではなく、その構造のほうである。
- 直すべきは脆弱性ではなく、「誰が・どのAIに・何を許可しているか」の管理不在
- 目指すのは禁止ではなく、棚卸し→許可基準→承認ゲート→監査の4ステップによる管理された許可
- 決定的な分岐は、不可逆な操作を人間の承認なしに自律実行させるかどうか
次のいずれかに当てはまるなら、連携を広げる前に、売り込み前提のない第三者の目を一度入れる価値がある。
- AIの業務利用が現場発で広がっているが、リスクの全体像を把握できていない——まず現状の棚卸しと可否の線引きから整理したい。
- AIエージェントを本格導入したいが、セキュリティとガバナンスの設計に自信がない——導入して大丈夫か、どの範囲までなら任せてよいかを診断してほしい。
- すでに連携を許可しているが、承認ゲートや監査の仕組みがない——運用に穴がないかを点検したい。
GXOは自社ツールを売り込む立場ではなく、AIを導入して問題ないか・どこまで任せてよいかを第三者として診断する立場でこの相談を受けている。AI導入の可否と適用範囲の診断はAI導入診断（AIアセスメント）で、AIエージェントの設計・実装そのものはAIエージェント導入支援で、全社のセキュリティ体制の点検はセキュリティ診断で扱っている。どれに当たるか判然としない段階の相談はお問い合わせ（無料相談）から受け付けている。
FAQ（よくある質問）
Q. AgentForgerは今も危険ですか？ 何かパッチを当てる必要はありますか？ A. いいえ。OpenAIが2026年6月8日に脆弱なURLパラメータを削除して修正済みで、利用者側で当てるパッチはありません。危険なのはこの脆弱性そのものではなく、「従業員がAIに業務データへのアクセスを許可している状態を会社が管理していない」構造のほうです。次の連携機能で同じ手口が使われたときに備えるべきは、パッチではなくガバナンスです。
Q. うちは無料版のChatGPTしか使っていません。関係ありますか？ A. AgentForgerが突いたワークスペースエージェント機能自体は特定機能ですが、より重要なのは「連携（コネクタ）を許可しているか」です。無料版でも従業員が個人アカウントで業務データを扱っていれば、管理不在という根本問題は同じです。まずは個人アカウント利用を把握し、管理機能のある法人契約に統一することを検討してください。
Q. AIを全面禁止すれば安全では？ A. 現実には逆効果になりがちです。禁止しても隠れて使われる（シャドーAI化する）ため、かえって会社が把握できなくなります。生産性も失います。目指すべきは全面禁止ではなく、機微度に応じて許可・要承認・禁止を切り分ける「管理された許可」です。
Q. 専任の情シスやセキュリティ担当がいません。何から始めればいいですか？ A. 最初の一歩は棚卸し（誰がどのAIに何を許可しているかの一覧化）です。ツール導入も規程作成もその後で構いません。棚卸しの結果を見れば、どこにリスクが集中しているかが具体的に分かります。自社だけで判断が難しい場合は、AI導入診断で現状整理から支援できます。
Q. どんな業種が特に注意すべきですか？ A. 個人情報や機微情報を日常的に扱う業種——人事総務、医療・介護、士業、金融、EC——は特に線引きを慎重にすべきです。要配慮個人情報や契約・財務データのAI連携は原則禁止から始め、必要な範囲だけを個別に設計するのが安全です。
公式情報・一次ソース（確認日：2026年7月26日）
- Zenity Labs: AgentForger, Part 1 — ChatGPT Cross-Site Agent Forgery（攻撃の仕組み・要件・偽造エージェントの挙動・開示タイムラインの一次解説）
- The Hacker News: ChatGPT AgentForger Flaw Could Deploy Rogue Workspace Agents via a Phishing Link（第三者報道・2026年7月23日開示の整理）
- SecurityWeek: OpenAI Fixes ChatGPT Agent Flaw That Could Let Attackers Forge an AI Insider（第三者報道）
- The Register: One ChatGPT link could smuggle a rogue AI agent into your company（第三者報道）
- 本文中の連携・権限設計に関する記述は、上記一次ソースの技術内容と、AIエージェントの権限設計に関する既報の整理に基づく。CVE番号・CVSSスコアは本稿確認時点で付与されていない。
