AIエージェントのセキュリティ｜Sophos導入事例で学ぶ判断と実行を分離する完全ガイド

AIが自律的にタスクをこなす環境において、AIの判断ミスがシステムの実行に直結するリスクが存在する。調査時間を96%削減したセキュリティ企業Sophosの事例は、AIの「推論」と「実行」を物理的に切り離す設計を示している。

金融大手AmexもAIの「意図認証」を導入した。AIエージェントの暴走を防ぎ、信頼性を担保するための「ガードレール設計」を解説する。Claude Codeでコードを書く中で避けるべき「AIを盲信するリスク」と、実装可能な安全なアーキテクチャを深掘りする。

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

AIエージェントの自律化と「判断の分離」という潮流

AIエージェントの活用において、セキュリティと信頼性を担保するアーキテクチャへの注目が高まっている。セキュリティ企業Sophosと金融大手American Express（Amex）の事例がその先駆けだ。

SophosはAIエージェント導入により、調査時間を96%削減した。AIがインシデントの52%をエンドツーエンドで解決する。

システムはAIが調査計画を立て、実行し、人間がレビューする「計画・実行・評価」のループで構成される。AIがすべてを完結させるのではなく、重要な判断の最終地点には人間が介在する。

AmexはAIによる不正取引を防ぐ「意図認証フレームワーク」を導入した。調査によると、66%の消費者がAIエージェントによる価格比較や調査に意欲を示す。

AmexはAIがユーザーの意図を把握しているかを確認するため、「意図ID」と「意図証明トークン」を生成する仕組みを構築した。AIはユーザーのクレジットカード番号ではなく、制約条件が付与された決済クレデンシャルを使用する。

しんたろー：
調査時間96%カットという数字は驚異的だ。裏側で「人間によるレビュー」を挟む設計が肝だと感じる。AIに全権委任せず、「AIの推論」と「実行権限」を切り離す設計は、自律型ツールを組む際に参考になる。

事例に共通するのは、AIを「推論を行う補助者」として配置し、出力を検証する多層的な防衛策だ。AIの非決定的な挙動を考慮し、失敗が許されない領域では、AIの判断をそのままシステムへ渡さない「ガードレール」が機能する。

技術的な検証コミュニティからは、AIによる「自己評価」の限界も指摘される。同じモデルが生成と評価を担う場合、モデル固有のバイアスにより誤った判断を「正しい」と誤認するリスクがある。生成モデルとは異なるロジックや、独立した検証ステップを設けることが最適解とされる。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

AIエージェント実装における「信頼の境界線」

今回の事例で明確になったのは、AIエージェントを「全自動の実行者」とせず、「推論エンジン」と「実行権限」を分離するアーキテクチャだ。AIの判断をそのままシステムへ直結させることのリスクを、業界全体が共有している。

開発者目線では、システムデザインの根本的な変更を意味する。「ユーザーの指示→AIが実行→システムが完了」という直線的なフローは、エージェントの実運用においては脆弱性の温床となる。決済やセキュリティといった領域では、AIの出力を「仮説」として扱い、独立した検証ステップでフィルタリングする設計が標準だ。

しんたろー：
Claude Codeでコード生成をすると、AIは自信満々にコマンドを返してくる。それを脳死で実行すると環境が壊れることがある。AIが生成したプランを一度人間が確認し、パス指定などを止めるプロセスが早い。AIを信頼するのではなく、成果物を「検証対象」として扱う感覚がしっくりくる。

AIによる「自己評価」には限界がある。生成と評価を同じモデルで行うことは、同じバイアスを共有する「共犯関係」を構築することに等しい。AIが生成した誤ったコードを、同じAIが「完璧です」と評価する現象はエンジニアなら経験があるはずだ。

この「評価の不透明性」を解決するために、Amexは「意図のトークン化」を採用した。AIの推論結果から抽出可能な「意図（Intent）」を切り出し、第三者的な認証ロジックで検証する。AIの曖昧な判断を、システムが解釈可能な「契約」へと変換する作業だ。

セキュリティの文脈では、AIの判断を「権限レベル」で分ける戦略も有効だ。Sophosの事例では、AIが調査とプランニングを行い、重大な操作には人間の承認を必須とする「Human-in-the-loop」が組み込まれている。

開発者はAIを「いつ暴走してもおかしくない外部API」として扱う。AIが「この操作を実行してよい」と判断しても、それは一つの意見に過ぎない。システムが受け入れる前に、「この操作はユーザーの意図と合致しているか」「破壊的ではないか」を判定する静的なバリデーション層を、AIとは独立したコードで実装する。

この「AIと実行層の間に挟む壁」が、これからのAI開発における差別化要因だ。AIモデル自体はコモディティ化するが、出力の「信頼性を担保するガードレール」を堅牢に実装できるかどうかが重要だ。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

実務レベルで組み込むべき「意図認証」の設計

AIエージェントを業務アプリに組み込む際、「AIの出力をそのまま処理に流さない」という原則を徹底する。決済やデータ変更、外部API呼び出しを伴う機能では、AIが生成したアクションを一度「意図（Intent）」として切り出し、検証するステップをコードレベルで強制する。

具体的には、AIが生成したJSON形式のアクションに対して、静的なバリデーションを挟む。「残高を移動する」というAIの提案に対し、移動元と移動先、金額が許可された範囲内か、ユーザーの操作履歴と矛盾していないかを、AIとは無関係なプログラムでチェックする。この「中間層」のロジックが、エージェントの暴走を防ぐ防波堤となる。

しんたろー：
Claude Codeでコードを書かせるときも、AIが提案する変更案をそのまま適用するのは怖い。必ず差分を確認してから適用している。これをシステム側で自動化し、「この操作はリスクが高いから人間が承認して」と弾くロジックを自前で書くのが、今のSaaS開発の肝だ。

AIによる「自己評価」を過信しない。評価者（Evaluator）を導入するなら、生成モデルとは異なるアーキテクチャや、異なるシステムプロンプトを設定した別モデルを使い、独立性を担保する。

実務においては、以下の3点を「開発標準」とする。

* アクションのトークン化: ユーザーの操作意図を識別子として保存し、実行時までそのIDを追跡する仕組みを作る。

* 権限レベルの分離: AIエージェントに渡す権限は「読み取り」と「計画の立案」に限定し、「実行」の権限は人間が介在するゲートウェイを通す。

* ログの検証可能性: AIの推論プロセス（Chain of Thought）をログとして残し、後から人間が操作の根拠をトレースできるようにしておく。

検証層を構築するコストは、誤作動によるデータ消失や意図しない決済の修正コストと比較して圧倒的に安い。AIが生成した判断をいかに「安全に制御するか」に開発リソースを割く。AIは優秀なインターンと同じであり、最終的な承認権限を預けてはいけない。

よくある質問

AIエージェントの誤作動を防ぐためのベストプラクティスは？

AIの出力を直接実行せず、必ず「意図の確認」というステップを設けることです。ユーザーの注文内容をトークン化して認証したり、操作の重要度に応じて「通知・連携・承認」といった権限レベルを設ける設計が有効です。重要な操作には人間の承認を挟むゲートウェイを構築することで、AIの非決定的な挙動の影響を最小限に抑えられます。

AIによる自己評価（Self Evaluation）は信頼できますか？

単一のモデルで生成と評価を完結させるのは推奨しません。同じモデルは学習データやバイアスを共有しているため、誤った回答を「正しい」と誤認する可能性が高いためです。信頼性を高めるには、生成モデルとは異なるアーキテクチャを持つモデルを評価者として採用するか、決定論的なルールベースの検証ロジックを併用する「独立した評価」の仕組みを構築することが不可欠です。

開発者が実装時に避けるべき「AIへの過信」とは？

AIを「正解を出す装置」ではなく、「推論を行う補助ツール」として扱うマインドセットが必要です。AIが生成した回答をそのままシステム実行のトリガーにするのは、検証プロセスが欠如した状態です。AIが提示したプランに対して、静的なバリデーションや別モデルによるクロスチェックを組み込み、「AIの判断」と「実行の許可」を物理的に分離したアーキテクチャを標準化してください。