AI Agent がもたらすものは発展か破壊か？リスクと対策(IDEsaster 含む)
2025年の Google AI Agent トピック
2025年は AI エージェントにおいて、パラダイムシフトとも言える飛躍的な進化を遂げた一年でした。Google においても同様、否、むしろ牽引するほど挙げればキリがないアップデートがありました。
その中から特に印象的なものや、AI Agent の進化に大きく影響を及ぼしたと考えるものを四半期ごとにピックアップします。
Canvas は AI の普及に大きな影響を与えました。私自身もまだAIをあまり活用していない人たちにその魅力をお伝えする際に大いに活用させていただきました。サクッと実際に遊べるゲームを作ってみせると途端に目がキラキラと輝いていました。
Thinking Mode のアプローチも、AI Agent の自律性に大きく影響を及ぼしたと考えます。
Google Next では、みんな大好き ADK が発表されました。だれもが簡単に AI Agent を開発できるようになりました。また、開発したエージェントを稼働するための Vertex AI Agent Engine も GA されました。
また、コンピューティングリソースを大量に使用する AI Agent において、第７世代の TPU となる「Ironwood」も発表されました。
個人的には玄人好みの印象の第3四半期を経て、Gemini 3 のリリースがありました。私の肌感には、Gemini がコレまでで一番、世の中にポジティブな驚きを与えたバージョンのように感じています。
同タイミングで、AI エディタの「Google Antigravity」もリリースされています。
AI Agent の特徴
私はよくこの説明に、副操縦士から優秀な新入社員への変化と例えます。
これまでの AI は、コーディングでの入力補完や、膨大なドキュメントの要約、翻訳など、自身の作業を補助する役割でした。
一方、AI Agent は、目的を指定することで、その達成のためにさまざまなツールを活用しながら目的達成の道筋を自律的に立てます。また、ツール使用の結果を自ら振り返り、必要に応じて試行錯誤を繰り返します。
ただし、完全に放置しておくだけで勝手にあなたの仕事を完遂してくれるわけではありません。正しい指示（インプット）を与える必要があります。やってはダメなことも伝える必要があります。
LLM の脅威的な進化に伴って、プロンプトの理解力が飛躍的に向上している今も変わりはありません。例えるなら、超優秀なスペックを持った新入社員のようなものです。
用途が変われば、アーキテクチャも変わります。
従来のアーキテクチャが線形処理だったのに対し、AI Agentはループ型の処理を撮ることが一般的です。ループ処理を行うためにオーケストレーション処理や記憶領域が必要になります。
これらの用途やアーキテクチャの変更の違いに伴って、新たなリスクも発生しています。
AI Agent のリスク
従来の AI リスクは、AI システムを直接的に攻撃してくるものでした。一方、AI Agent でのリスクは、Agent を介して、システムや組織の脆弱性を突くことができてしまうようになります。
いくつか、具体的なリスクについても簡単に解説しておきます。
間接的プロンプトインジェクション
プロンプトインジェクションとは、悪意あるユーザーが、AIに直接悪意のある指示（プロンプト）を与えるものでした。
具体的には、一般的な AI サービスは、犯罪行為などに悪用されないよう、予めそのようなインプットを受け付けないようにチューニング（指示）されています。プロンプトインジェクションでは、「コレまでの指示を全て忘れるように」と入れることで、犯罪行為への利用が可能になるようなものです。
一方、間接的プロンプトインジェクションでは、ユーザー自身は悪意がないまま、プロンプトを介して被害に遭います。例えば、「このWebサイトの記事を要約して」という指示をするように仕向けます。このサイトは一見、正規のものであるように作られていますが、人間が視認できないほどの小さな文字や透明な文字でインジェクションが埋め込まれています。それにより、ユーザーの認証情報などが盗まれることもあり得ます。
権限の不一致
AI Agent を作成する場合は、一人だけで利用するものは稀です。大体は複数名で利用します。それぞれの人には権限がまちまちです。
エージェントはその最大値の権限で振る舞える必要があります。しかしながら、そのエージェントを利用する人が持つ権限を超える動きはしてはなりません。
エージェントの利用時に、利用者の権限を引き継いで振る舞う必要があります。
例えば、人事データを取り扱うことができる社員がエージェントを利用する際は、人事データを参照してもいいが、そうでなければ人事データを参照しないようにするべきです。
メモリポイズニング
AI Agent のアーキテクチャの特徴であるループ処理の実現にあたっては、メモリが利用されます。メモリには、短期的な記憶と長期的な記憶があります。短期的なものはその名の通りオンメモリであったりキャッシュ型のデータストアが採用されます。一方、長期的なものには、ベクターDBが採用されます。
このリスクは、これらのメモリ領域（とくに長期的なもの）を活用した攻撃です。
攻撃者はメモリ領域に悪意ある指示を潜ませておくことで、時限爆弾のように設置（仕込み）と爆発（被害の発生）のタイミングをずらすことができます。
こうすることで、原因究明の難解化を図ることもできます。
AI Agents のリスク対策
これらのリスクに対して、いくつかの対策案を挙げておきます。
HITL ワークフロー
現時点では、最も重要な考え方の一つです。
Human In The Loop というもので、AI に完全な自己完結を委ねるのではなく、重要な操作の際は必ず人間の承認を挟むようにします。
これは、人間だけでの作業でも同じです。重要な本番環境への変更作業を、一人の作業者が全て単独で進めることは危険です。作業内容やその結果に対して、第三者によるレビューを挟むことが一般的です。
ただ、何でもかんでも HITL とするのは、個人的には反対です。AI Agent の価値が半減します。人間の作業においても、何でもかんでもダブルチェックというのは非効率的ですし、承認の精度も落ちがちです。どこに HITL を確実に適用するかが、今後の鍵になってくると考えます。
OBO 認証と JIT アクセス
OAuth 2.0 の仕組みを使った On-Behalf-Of ユーザー認証を行うことで、エージェント利用者の権限下でエージェントが振る舞うようにします。また当然、その権限は永続的に持たせるのではなく、一時的（Just In Time）であるべきです。
Vertex AI における Agent Identity のような機能であったり、フェデレーテッドで動く MCP サーバーも増えていますが、API キーベースのものなど、そうでないものもまだまだあります。
自律的に動く AI Agent が意図せずこのような権限の超過をしないような統制は、非常に困難なところです。
フロントエンドとエージェントランライムでのサニタイズ
AI Agent のセキュリティ対策においても、多層防御は有効です。
（間接的）プロンプトインジェクションの検出、防御のために、UI でサニタイジングを行うことに加え、LLMによる解釈の結果をツール使用に流す前に検証することも効果的です。
サンドボックス化
こちらも、セキュリティ対策としてはレガシーな種類ですが、AI Agent においても非常に効果的です。
AI Agent が意図しない暴走を行った時も、被害を局所化できるようにコンテナやマイクロ VM で動くようにしておきたいです。
IDEsaster
最後に、IDEsaster にも触れておきます。
Google Antigravity など、最近多くの AI Agent を搭載した IDE がリリースされていますが、調査レポートによれば、その調査対象となった３０種ぐらいの IDE すべてに脆弱性が見つかったというものです。IDE + Desaster（災害）の造語です。
これらは、従来は人間がタイピングすることで利用することを前提に設計されてきた IDE に対し、自律的に振る舞う AI Agent を搭載することによって、これまでなかった脆弱性が確認できたというものになります。
例えるなら住居に泥棒するために、これまでは外からドアを破壊するような直接的な AI 自体への突破（プロンプトインジェクションなど）を試みることに対し、IDEsaster では住人を騙すことで、中から鍵を開けさせるような攻撃が発見されたようなものです。その手法としては、先ほど挙げた間接的プロンプトインジェクションのようなものが用いられています。
IDEsaster が怖いところとしては、一見、なんともなさそうな README の閲覧だけでも、被害が発生する可能性があるところです。さらに、その際に、IDE のグローバル設定を書き換えることで、永続化や水平展開も行われてしまいかねません。
IDEsaster 対策としては、コンテナで動かすなどサンドボックス対策が有効策の一つです。また、確実に問題のないリポジトリや MCP の利用を徹底する必要があります。第三者でフォークされたリポジトリでなく、本家のものを参照しましょう。HITL 対応の IDE も多いので、必要に応じて活用しましょう。
また、原始的ではあるものの、こまめなアップデートも重要です。AI Agent は進化も早いです。その中で攻撃手法も日々進化しています。対策をあてるようにしましょう。
さらなる対策として、AI Agent 自身に攻撃の検知や防御をさせるだけでなく、攻撃のシミュレート（Red Teaming）をすることも提唱されています。
Antigravity において、コンテナ上で稼働させるモードや、HITL の挿入機能もあるので、積極的に活用しましょう。
Antigravity によって、ファイル消失したというような書き込みを見かけましたが、DevContainer で動かしていれば防げたのではなかろうかと。
Secure Mode という、セキュリティを優先したモードがあるので、個人的にはデフォルトでこれを選択、必要に応じて個別でチューニングがベターかと考えます。
まとめ
AI Agent がもたらすものは発展か破壊か？
私は、前者と考えます。
善人が使わなくとも、悪人は AI Agent を悪用して、攻撃の複雑化をしてきます。これは断言できます。この速度には、従来のやり方だけでは追いつけません。
我々は、AI Agent を正しく安全に活用して、立ち向かう必要があります。
しかしながら、現時点では完全な安全を保証できる銀の弾丸はありません。少なくとも自分は知りません。リスクを把握しながら対処していく必要があります。
Google には、ADK や Vertex AI のような、Agent 開発・運用をサポートしてくれる基盤も提供されています。これらには、本文でも紹介した機能以外にも、トレーサビリティや多段防御を補助する仕組みが提供されます。
本ブログが安全な AI Agent 利用の促進に一役立てばこれ幸い。
このブログで記載した内容を含め、以下でお話しさせていただくので、ご興味いただけましたら是非ご登録ください！
Discussion