AIがAIを乗っ取る｜Google ADKで鍵3種流出

監修者伊東雄歩

株式会社ウォーカー CEO。東北大学卒。MENSA会員、JDLA認定講師、健全AI教育協会理事。生成AI×教育・学習科学を専門とし、2億円超のシステム開発プロジェクトを統括。

Google の AI エージェント開発キット「ADK」のリポジトリで、AI が別の AI を乗っ取る権限昇格が見つかりました
GitHub の Issue や PR に仕込んだ文章だけで、CI/CD サーバー上で任意のコードが実行できました
盗まれたのは bot のアクセストークン、Google API キー、Google Cloud のサービスアカウント鍵です
Google は 3 つの自動化ワークフローを削除し、2026 年 7 月 21 日までに修正を完了しました
「自然言語が認可の経路に入った」という新しい攻撃クラスで、日本企業の対策も待ったなしです

AI に仕事を任せるとき、その AI が「別の AI をだます道具」になるとは考えたことがあるでしょうか。2026 年 8 月、Google の AI エージェント開発キットで、まさにその形の攻撃が実証されました。GitHub に投稿された 1 本の Issue が、社内向けの高権限ワークフローを起動させたのです。

何が起きたのか｜AIが「同僚AI」に化けた

イスラエルの AI セキュリティ企業 Pillar Security が、Google の ADK（Agent Development Kit）の Python 版リポジトリに深刻な欠陥を見つけました。

研究を主導したのは同社の Dan Lisichkin 氏です。

問題の中心にあったのは、プルリクエストを自動で仕分けする AI エージェント「adk_pr_triaging_agent」でした。このエージェントは「adk-bot」というアカウントで動きます。

ここに落とし穴がありました。adk-bot は GitHub 上で単なるボットではなく、Collaborator（共同開発者）扱いだったのです。つまり、外部の人には触れない「メンテナー専用の自動処理」を呼び出せる立場にいました。

攻撃者はこの立場を借りました。エージェントに読ませる文章を細工して、adk-bot の名前で特定のコマンドを投稿させたのです。

受け取った側の高権限ワークフローは、「投稿者が Collaborator だから安全」と判断して起動しました。中身が外部から操られたものだとは、誰も検証していませんでした。

Google ADKとは？AIエージェント開発の土台

そもそも ADK とは何でしょうか。

ADK は、AI エージェント（自分で判断して作業を進める AI）を作るための開発キットです。Google が公開しているオープンソースソフトウェアで、Python 版は v1.0 の安定版に到達しています。

2026 年には TypeScript 版の SDK も登場しました。さらに v2.0 のアルファ版では、処理の流れを図（グラフ）で決め打ちできる仕組みが入っています。

ADK が支えているのが A2A（Agent2Agent）プロトコルです。これは、違う会社・違う言語で作られた AI エージェント同士が会話するための共通ルールにあたります。

各エージェントは「Agent Card」という自己紹介ファイルを /.well-known/agent.json に置きます。相手はそれを読んで「何ができる子か」を把握し、仕事を頼みます。

ちなみに、この「エージェント同士が連携する」設計こそが、今回の攻撃の舞台になりました。

攻撃の流れ｜Issue 1本からCI/CD陥落まで

ステップ1：公開Issueに指示文を埋め込む

攻撃は驚くほど手軽に始まります。

攻撃者は GitHub の公開 Issue を開き、そこにプロンプトインジェクション（AI への命令を文章に紛れ込ませる攻撃）を書き込むだけです。

特別なアカウントも、内部関係者の協力も要りません。誰でも書ける公開の場所に、AI 向けの指示を置いておくのです。

ステップ2：仕分けAIが指示に従ってしまう

Issue が立つと、Gemini を積んだ仕分けエージェントが自動で起動します。

このエージェントは Issue の本文を「分析対象のデータ」ではなく「自分への指示」として読んでしまいました。

結果、エージェントは攻撃者の望むコメントを投稿します。「/adk-issue-fix」や「@gemini-cli」で始まる、特定の自動処理を呼び出すコマンドです。

投稿主は adk-bot。信頼された内部アカウントです。

ステップ3：高権限ワークフローが起動する

ここが分岐点でした。

受け側の issue-fix.yml というワークフローは、コマンドの投稿者が「owner・member・collaborator のいずれか」かどうかだけを確認していました。

adk-bot は条件を満たします。しかし、その bot 自身が外部の文章に操られている可能性は、まったく検証されていませんでした。

もう一方の経路では、細工されたコメントが gemini-invoke.yml を呼び出し、高権限エージェントが持つツールの一覧をそっくり吐き出させることに成功しています。

ステップ4：認証情報を根こそぎ盗む

起動した高権限ジョブは、CI ランナー（自動テストを走らせるサーバー）上で任意のコマンドを実行できました。

そこから抜き取られたものは深刻です。

adk-bot の個人アクセストークン（PAT）
Google API キー
Google Cloud のサービスアカウント認証情報

研究チームは、盗んだトークンの pull-requests: write と issues: write 権限を使い、レビュー履歴そのものを偽造してみせました。

Lisichkin 氏はこれを「PR 承認のライフサイクルを汚染する」と表現しています。実際にはレビューされていないコードに、承認されたように見える足跡を作れるということです。

攻撃者はマージ権限を持つ必要すらありません。「マージして大丈夫そうだ」と人間に思わせる証拠を作れれば十分だからです。

Googleの対応と時系列

Google は 3 つのワークフローをリポジトリから削除しました。issue-analyze.yml、issue-fix.yml、pr-analyze.yml の 3 本です。

削除コミットの作成日は 2026 年 6 月 9 日。研究者が不在を確認したのが 7 月 2 日で、Google が正式に修正を認めたのが 7 月 21 日でした。

なお CVE 番号は割り当てられていません。影響を受けたのはリポジトリの自動化設定であって、配布されている ADK の Python パッケージ本体ではないためです。

また Google は、この報告に対するバグバウンティ（報奨金）支払いを見送りました。「ソーシャルエンジニアリングの要素を含む」というのが理由と伝えられています。

なぜ「エージェント間」が新しいのか｜他フレームワークとの比較

プロンプトインジェクション自体は、2023 年から知られている古典的な攻撃です。では、今回の何が新しいのでしょうか。

答えは「AI が AI への踏み台になった」という点にあります。

従来の議論は「AI が変な出力をする」「AI が機密を漏らす」という単体の話でした。今回は、権限の低い AI の出力が、そのまま権限の高い AI を動かす引き金になっています。

Greyhound Research の Sanchit Vir Gogia 氏は、この変化をこう言い切りました。

自然言語が認可の経路に加わった。それこそが報じる価値のある変化だ。

これまで「誰が何をしてよいか」を決めるのは、トークンや権限設定といった機械的な仕組みでした。そこに、書き換え自由な日本語や英語の文章が割り込んできたのです。

Gemini CLIでも同じパターンが見つかっていた

実は Pillar Security は、今回より前に Gemini CLI でも似た欠陥を報告しています。

こちらは GitHub スター数 10 万 1000 超の人気プロジェクトが対象でした。2026 年 4 月 16 日に Google の OSS 報奨金プログラムへ報告され、4 月 24 日に GHSA-wpqr-6v78-jr5g として修正が公開されています。

修正版は Gemini CLI 0.39.1 と 0.40.0-preview.3、GitHub Action 側は run-gemini-cli 0.1.22 です。

注目すべきは、同じ危ういパターンが Google の 8 つ以上のリポジトリで使われていたという指摘です。1 か所の設定ミスではなく、設計思想の問題だったことがわかります。

他社フレームワークは無関係ではない

「Google の話でしょう」と思うかもしれません。しかし、この構造は ADK 固有ではありません。

LangChain、AutoGen、CrewAI など、複数エージェントを連携させる仕組みはどれも同じ形をしています。あるエージェントの出力が、別のエージェントの入力になる設計だからです。

MCP（Model Context Protocol）でツールをつなぐ場合も同様です。信頼できない文章が、どこかで信頼された命令に化ける経路があれば、同じ攻撃が成立します。

今回の事例が価値を持つのは、Google という最も体制の整った組織ですら踏み抜いたことを示した点にあります。

日本市場への影響｜ガイドラインはすでに動いている

日本の企業にとって、これは対岸の火事ではありません。

IPA（情報処理推進機構）が公表した「情報セキュリティ 10 大脅威 2026」では、「AI の利用をめぐるサイバーリスク」が組織向けランキングで初めて 3 位に選出されました。AI の使い方そのものが、上位の脅威として認定されたということです。

OWASP も 2025 年 12 月に「OWASP Top 10 for Agentic Applications 2026」を公開しました。エージェント特有の脅威を整理した文書で、プロンプトインジェクションと過剰な権限付与が最大級の脅威として並んでいます。

制度面も動いています。2026 年 3 月に更新された総務省・経済産業省の「AI 事業者ガイドライン（第 1.2 版）」では、AI を自社システムに組み込む提供者にガードレールの実装を求めています。

身近な現場で何が起きうるか

ある受託開発会社のケースを想像してみてください。GitHub の Issue を AI に仕分けさせ、簡単なバグは自動で直させる仕組みを入れたとします。

顧客企業の担当者が Issue を書ける設定になっていれば、そこが入口です。悪意ある取引先や、乗っ取られたアカウントから、AI 向けの指示が流し込めます。

別の例として、社内ヘルプデスクの AI を考えます。ユーザーからの問い合わせ文を読み、必要に応じて「アカウント権限を変更する AI」に引き継ぐ設計だとします。

問い合わせ文に指示を仕込めば、権限変更 AI を動かせるかもしれません。引き継ぎメッセージが検証されていなければ、人事評価データや給与情報に手が届く恐れがあります。

3 つ目は、ECサイトのカスタマーサポートです。レビュー文を要約する AI が、その要約を「在庫や価格を操作できる AI」に渡している場合、商品レビュー欄が攻撃の入口になります。

いずれも特殊な構成ではありません。「AI が AI に仕事を渡す」設計を採用した瞬間に、同じリスクが生まれます。

企業が今すぐやるべき5つの対策

研究者やアナリストが挙げた対策を、実務向けに整理します。

1. 権限の連鎖を洗い出す

IDC Asia Pacific の Sakshi Grover 氏は、3 つの問いを追跡するよう勧めています。どのエージェントが外部の文章を読むか。その出力が高権限の処理を起動するか。起動先は最大で何ができるか。

2. エージェントを「協力者」にしない

今回の根本原因は、bot に Collaborator 権限を与えたことでした。自動処理用のアカウントには、必要最小限の権限だけを渡します。

3. 認証情報をディスクに残さない

Pillar は、外部からの入力を扱うワークフローでは persist-credentials: false を必ず指定するよう提言しています。CI サーバー上に鍵を置きっぱなしにしないという、地味ですが効く一手です。

4. 承認・レビューの変更を監査する

レビューコメントや承認状態の書き換えを、それ自体をセキュリティイベントとして別系統で記録します。承認履歴が改ざんされても気づける状態を作ります。

5. 人間の承認をコードに紐づける

「この差分を確認して承認した」という形で紐づけ、内容が変われば承認を無効化します。Human-in-the-Loop（重要な操作の前に人が確認する仕組み）は、対象が固定されて初めて機能します。

Pillar Security はこう釘を刺しています。

プロンプトインジェクションは権限の問題として扱うべきだ。プロンプトを堅くしても、権限を持ちすぎたエージェントの被害範囲は変わらない。

よくある質問（FAQ）

Q1. ADK を使っているアプリは危険ですか？

今回の欠陥は、Google の GitHub リポジトリの自動化設定にあったもので、配布されている ADK の Python パッケージ本体の欠陥ではありません。ADK を組み込んだ自社アプリが直ちに危険になるわけではないと考えられます。ただし、同じ「エージェント間の受け渡し」を検証せずに使っている場合は、自社の設計を点検すべきです。