AIエージェントの信頼の境界線と、実務を回すガバナンス層の有無

公開Sentryキー一つでAIエージェントが乗っ取られる仕組み

6月17日、Tenet SecurityのThreat Labsチームが「Agentjacking」と名付けた攻撃手法を公開した。Claude Code、Cursor、CodexといったAIコーディングエージェントが、偽のSentryエラーレポートを信じ込んで攻撃者の意図通りのコマンドを実行してしまう。

攻撃の起点はSentryのDSNだ。Data Source Nameは書き込み専用の認証情報で、フロントエンドのJavaScriptに埋め込んで使うことが公式に推奨されている。CensysのクエリやGitHubのコード検索で簡単に見つかる。Tenetの調査では2,388の組織がインジェクション可能なDSNを公開しており、そのうち71はTranco top-1Mにランクインする規模だった。

攻撃者がDSNを手に入れた後の手順は単純だ。SentryのインジェストエンドポイントにDSN以外の認証なしで偽のエラーイベントを送る。ペイロードのメッセージやコンテキストフィールドにマークダウンを仕込み、Sentryの解決テンプレートに見せかけたセクションの中にnpxコマンドを埋め込む。SentryはHTTP 200を返し、偽イベントを本物のクラッシュと一緒に保管する。

開発者が「Sentryの未解決エラーを修正して」とエージェントに依頼する。日常的なワークフローだ。エージェントはMCPサーバー経由でそのイベントを取り込み、

（MCP: Model Context Protocolは、AIモデルが外部データソースやツールに標準化された方法でアクセスするためのオープンプロトコルである）偽の解決策を信頼できるガイダンスとして読む。そして開発者自身の権限で、開発者自身のマシン上でコマンドを実行する。Tenetのテストでは、npmパッケージが環境変数、クラウド設定ファイル、認証ストアへのアクセスを確認し、AWS鍵やGitHubトークンがすべて手の届く範囲にあることを実証した。100以上の実行が別々の組織で確認されたと報告されている。ただしこの数字はTenet自身の制御下でのテスト結果であり、独立した計測として読むべきだろう。

根本的な問題は、エージェントがデータとインストラクションを区別できないことにある。人間がエラーログを読む前提で設計されたDSNの公開運用は、AIエージェントが同じログを読むことで攻撃経路に変わる。エラーメッセージに埋め込まれたマークダウンを指示として解釈するのは、モデル自体の限界であり、設定変更で修正できるものではない。MCPが外部サービスのデータを信頼して渡す構造と、DSNが誰でも書き込める性質。それぞれは単独では無害だが、組み合わせると危険になる。

金曜の午後にSentryのバックログを一括処理する。そんな日常が攻撃の前提になっている点が厄介だ。エージェントにエラー処理を任せるワークフロー自体を見直すか、MCPサーバーが返すデータをどこまで信頼するかの線引きを明確にする必要がある。ただ、データと指示の区別という根本問題に対する汎用的な解決策が何になるのか、現時点では分からない。

セマンティック層なしにAI分析は回らないという証明

Anthropicが自社ブログで興味深い数字を出した。社内のビジネス分析クエリの95%をClaudeが自動処理している。全体の精度も約95%。一部ドメインでは99%に近づいている。ただし、この数字自体よりも重要なのがその前提だ。

スキルを何も与えない状態だと、Claudeの正答率はたった21%だった。分析ワークフローとビジネスコンテキストを「スキル」として符号化して初めて、95%を超える。モデルの賢さではなく、文脈の与え方で精度が決まる。この差は残酷なほど明確だ。

Anthropicが組んだのは4層構造。データ基盤、ナレッジ層、スキル、検証システム。「週次アクティブユーザー」という曖昧な問いを、ガバナンス下の特定エンティティに解決する仕組みだ。直接テーブルにクエリを投げるのではなく、セマンティック層を経由してメタ定義・リネージ・ビジネスコンテキストを参照する。データアーキテクトのFrancesco Mucioも指摘している。肝はセマンティックレイヤーだ、と。

この構成は自己サーブ型分析の古いジレンマを突く。誰でも自由にクエリを投げられると、指標の定義が部門ごとに分裂する。一方で厳格に管理すると、端っこの質問に答えられずダッシュボードが増殖する。Claudeにスキルとして文脈を与える手法は、この両方を同時に解決しようとしている。

データサイエンスチームは定型作業から解放され、因果モデリングや予測、機械学習といった戦略的領域に注力できるようになったとある。ここは納得できる。分析のボトルネックは往々にして「この数字の定義は何か」という確認作業だ。それをシステム化した意味は大きい。

一方でコミュニティの反応は割れている。分析は決定的で冪等な結果を返すべきだという批判がある。確率の出力にビジネス判断を委ねることへの懸念だ。この指摘はもっともだ。95%の精度が十分かどうかは、誤りの5%がどこで起きるかによる。誤差が許容される領域と、許容されない領域があるはずだ。

実務で注目すべきは、Anthropicがスキルファイルのテンプレートを添付している点だ。再現性がある。自社のセマンティック層と検証パイプラインが整っていれば、同じ構成を取れる。整っていなければ、まずそこの投資が必要になる。AIエージェントの精度は文脈定義の品質で決まる。モデルのパラメータ数ではない。

Gemini CLIが終わってAntigravity CLIになった、でも自動化で困りそうだ

GoogleがオープンソースのGemini CLIを廃止し、クローズドソースのGoバイナリであるAntigravity CLIに置き換えた。10万以上のGitHubスターと数百人のコントリビューターを持っていたツールが、6月18日をもって個人アカウント向けのリクエスト処理を停止した。猶予期間なし。移行日には既に旧ツールが使えなくなっていた。

Googleの主張は三つ。Goで書かれたAntigravity CLIは「よりスナップで応答性が高い」。複数エージェントをバックグラウンドで動かせるため「大規模リファクタリングや複数トピックの調査でターミナルがロックされない」。機能の1:1パリティは最初ないが、重要な機能は引き継ぐ。強気な内容だ。

実際のテスト結果を見ると、スピードの主張は崩れている。Gemini CLI v0.47.0の中央値が約3.2秒なのに対し、Antigravity CLI v1.0.9は約3.97秒。単純なプロンプトで新ツールの方が遅い。ただし実行時間のばらつきはAntigravityの方が小さく、起動時のノイズ出力もない。体感の落ち着きは向上していると読める。

個人的に気になるのはnon-interactive modeの挙動だ。Gemini CLIはファイルの読み取りはできるが、書き込みツールやシェルコマンド実行が使えず、スクリプト経由での自動編集ができない。一方Antigravity CLIは--dangerously-skip-permissionsフラグで2分10秒程度で型ヒントの追加タスクを完遂した。CI/CDパイプラインに組み込むなら、ヘッドレスでファイルを書き換えられるかは致命的な差になる。

もう一つ、503エラーとクオータ消費の問題がある。テスト中、Gemini CLIはサーバー側の503エラーを頻発。リトライ待ちで1分以上ハングしたうえ、その失敗リクエストがすべて無料枠を消化した。flash-liteモデルの1日20リクエスト制限にあっさり到達し、実質テスト不能に。サーバー側の不調をユーザーのクオータで肩代わりさせる設計は、自動化前提のワークフローでは受け入れがたい。Antigravity側では503エラーは出なかったとのことだが、この挙動が根本的に改善されているのか、単に移行日の混雑による一時現象だったのかは判然としない。

オープンソースからクローズドソースへの転換も懸念材料だ。コミュニティの貢献で育ったツールが、突然ブラックボックスに置き換わる。拡張やデバッグの透明性が失われる。移行期の混乱はいずれ収まるとしても、エコシステムの信頼という点では後退しているとしか言えない。

Valkey 9.1がバックポート自動化で見せたAIエージェントの実戦投入

Valkey 9.1がリリースされたとき、新機能やパフォーマンス改善に目が向いていた。しかし裏で面白い動きがあった。バグ修正のバックポートをAIエージェントに任せていたのだ。

バックポート作業は地味だが厄介だ。メインブランチで修正されたバグを、古いリリースブランチにチェリーピックする。コードが分岐しているとマージコンフリクトも発生する。Valkeyは7.2、8.0、8.1、9.0、9.1と複数のサポートブランチを同時に管理している。インメモリデータストアは常に稼働し続ける要件が多く、ユーザーが最新メジャーバージョンにすぐ飛びつくとは限らない。だから古いバージョンの保守も欠かせない。

メンテナのMadelyn Olsonによれば、これまではバグやセキュリティ修正のバックポートに何時間も費やしていたという。そこで9.1サイクルではAIエージェントを投入した。エージェントがチェリーピック、マージコンフリクトの解決、CIパイプラインの実行までを自動で処理する。結果、エンジニア1人あたり週数時間のテスト時間を節約できたとのこと。

人間が完全に外れたわけではない。エージェントが作業を進め、最終的なマージのサインオフは人間が行う。この「人間は最後の承認だけ」という形は、AIエージェントの使い方として筋が通っている。ルーチンで決定的な作業は機械に任せ、判断が必要な箇所だけ人間が関与する。

もう一つ興味深いのがProvenance Guardというエージェントだ。PRに許可されていないコードベースからの混入がないかスキャンする。ValkeyはRedisのフォークであり、ライセンス問題に配慮する必要があるのだろう。このエージェントはバックグラウンドで動き、問題がありそうなPRをメンテナに通知する。人間のレビューの前段として初期スキャンを肩代わりする仕組みだ。

AIエージェントがコードを書くという話はよく聞くが、Valkeyの事例は少し違う。新機能の開発を任せたわけではない。既存の修正を別のブランチに適用する、という退屈だが必要な作業を自動化した。まさに「人間の判断を厳密に必要としない繰り返し作業」の丸出しの場面だ。

CI/CDパイプラインを自分で組っていると、バックポートやチェリーピックの自動化は確かにやりたい課題の一つになる。ブランチ間の差分が大きくなればなるほど手作業のコストが跳ね上がる。Valkeyの取り組みは、AIエージェントの使いどころとして実務に即した線を引いているように見える。

使用量ベース課金の分散イベントをどう正確に金額に変換するか

AtlassianがForge課金プラットフォームの内部設計を公開した。ForgeはJiraやConfluence向けのサーバーレスアプリを構築するための拡張プラットフォームだが、課金モデルが使用量ベースに移行したことで、分散システム特有の難しさが表面化した。関数呼び出し回数、ストレージ消費量、運用テレメトリ。こうした細粒度のシグナルを、テナントごとに正しく帰属させ、重複なく金額に変換しなければならない。

アーキテクチャの全体像は次の流れになる。各Forgeサービスが構造化された使用量イベントを発行し、Kafkaベースのストリーミング層がそれを集約する。その後、Usage Tracking Service（UTS）が検証・正規化・エンリッチメント・重複排除を担当し、下流の課金・コマースシステムに渡す。UTSはAtlassian自身が「Forge Billingの神経系」と呼ぶ調整層で、すべてのイベントが正しいエンタイトルメントやサブスクリプションコンテキストに紐づくことを保証する。

ここで一番難しいのは帰属とシェイプの整合性だ。イベントがどの契約に属するかを間違えれば、請求先が変わる。シェイプがUTSのコントラクトに合わなければ、下流の処理が壊れる。分散システムではイベントの遅延や重複配信も日常茶飯事で、Atlassianはべき等なイベント設計と時間ベースのウィンドウ集約で対処している。遅れて到着したイベントはウィンドウ処理で取り込み、重複配送はべき等性で二重カウントを防ぐ。実装の詳細は公開されていないが、このあたりの境界条件をどう処理しているかは知りたいところだ。

データ保存も二層に分かれている。監査用途の不変長期ストレージと、ダッシュボード・API向けの低遅延分析層。開発者はDev Consoleから自分のアプリの使用量をニアリアルタイムで確認できる。使用量ベース課金では、開発者がコストを予測・制御できるかがプラットフォームの信頼性に直結する。可視性がないと、開発者は不安になって離れる。

マイクロサービスでイベント駆動アーキテクチャを組んでいると、重複や順序の問題は必ず踏む。Kafkaでイベントを流すところまでは素直でも、そこから先の「正しい金額への変換」が本番の難所だ。Atlassianの事例は、プロデューサーとコンシューマーを分離し、UTSという単一の調整層でスキーマ検証と帰属を集中管理する構成をとっている。この集中化がトレードオフなしに機能しているのか、それともボトルネックのリスクを抱えているのか。スケール時の挙動については、まだ分からない部分が多い。

まとめ

AIエージェントの実務投入が具体的になっている。同時に、エージェントがどこまで信頼できるかという境界線も浮き彫りになった。Sentryの偽エラーレポートでエージェントが乗っ取られる攻撃は、データと指示の区別がつかないことの危険さを示している。日常のワークフローが攻撃経路に変わる。一方でValkeyのバックポート自動化は、人間が最後の承認だけを行う形で境界線をうまく引いている。ルーチン作業を機械に任せ、判断だけ人間が関与する。この線引きは筋が通っている。

信頼をシステム化する動きも出ている。AnthropicがClaudeの分析精度を引き上げたのは、モデルの賢さではなくセマンティック層の整備があったからだ。ビジネスコンテキストをスキルとして符号化しなければ、正答率は21%に落ちる。Atlassianが分散イベントを正確な金額に変換するためにUTSという調整層を置いたのも同様の課題だ。入力の正しさを保証する仕組みなしには、AIもイベント処理も回らない。

ツールのエコシステムが不安定になる中で、実務にどう耐えるかも問われている。Gemini CLIのクローズド化と自動化の制約は、CI/CDパイプラインを組む立場からすると困りものだ。コミュニティの貢献で育ったツールが突然ブラックボックスに置き換わる。non-interactive modeの挙動やクオータ消費の問題も、自動化前提のワークフローでは受け入れがたい。便利だったものが突然使えなくなるリスクは、エコシステムの信頼という点で後退しているとしか言えない。

AIも分散システムも、結局は「適切なコンテキストの与え方」と「検証・調整の仕組み」で勝負が決まる。モデルの賢さやツールのスピードに目を奪われがちだ。しかし実務で回すなら、地味なガバナンスの層にこそ手を入れる必要がある。セマンティック層が整っていなければAI分析は回らないし、イベントの帰属が正しくなければ請求先が変わる。派手な機能の裏で起きている調整の泥仕事こそが、今の技術動向の核心ではないか。

参照記事

記録日: 2026-06-22