MENU
合同会社JOBIRUNのHPです。
  1. ホーム
  2. AI関係
  3. AI技術
  4. ［開発者向け］AIエージェントのセキュリティ設計、何から始める？IBMとAnthropicが示す実践的な指針

［開発者向け］AIエージェントのセキュリティ設計、何から始める？IBMとAnthropicが示す実践的な指針

AI技術 エンジニア関連
目次

はじめに

　IBMのテクノロジー解説チャンネルが2026年2月19日に公開した動画では、IBMとAnthropicが共同で策定したガイドライン「Architecting Secure Enterprise AI Agents with MCP」の内容をもとに、エンタープライズ向けAIエージェントのセキュリティ設計における考え方と具体的な実装方針が解説されています。本稿では、その内容を整理してお伝えします。

参考記事

要点

  • IBMとAnthropicは2025年10月、エンタープライズ向けAIエージェントの安全な設計・運用を体系化したガイドライン「Architecting Secure Enterprise AI Agents with MCP」を共同で公開した
  • AIエージェントは従来の決定論的なソフトウェアと異なり、確率的な挙動・適応的な学習・評価主導の開発という3つのパラダイム転換を伴う
  • 主なセキュリティリスクとして、攻撃対象領域の拡大、過剰な権限付与、プロンプトインジェクション、データ漏洩、自律動作による被害の増幅などが挙げられる
  • 対策の核心は「最小権限の原則」の徹底、エージェント固有の識別情報管理、AIゲートウェイによるトラフィック監査、そして人間による監視体制の確保である
  • ガイドラインは開発・テスト・デプロイ・監視の各フェーズにわたるエージェント開発ライフサイクル（ADLC）を定義し、DevSecOpsの考え方をAIエージェントに適用している

詳細解説

AIエージェントがもたらすパラダイムの転換

　AIエージェントとは、文脈を認識し、目標と制約に基づいて推論し、各種ツールやサービスを通じて自律的に行動するシステムです。IBMのガイドラインでは、従来のソフトウェアとの根本的な違いとして3つの転換が整理されています。

　第一に、決定論的から確率論的への転換です。従来のソフトウェアは同じ入力に対して常に同じ出力を返しますが、AIエージェントは確率と統計に基づくため、同一の入力であっても異なる判断を下す場合があります。

　第二に、静的から適応的への転換です。エージェントは人間のフィードバックをもとに継続的に挙動を変化させます。

　第三に、コード優先から評価優先への転換です。実装の詳細よりも、設定した目標に対して成果がどの程度達成されているかを継続的に測定することが中心となります。

　この特性の変化が、従来のITセキュリティの枠組みでは対応しきれない新たなリスクを生み出していると言えます。

エージェントが直面する主なセキュリティリスク

　動画では、AIエージェントが直面するリスクが具体的に列挙されています。まず、エージェントの導入それ自体が攻撃対象領域（アタックサーフェス）を拡張します。AIモデル自体への攻撃に加え、エージェントと外部ツール・サービスをつなぐ通信プロトコルであるMCP（Model Context Protocol）も新たな攻撃経路となり得ます。

　また、エージェントが必要以上のアクセス権を持つ過剰な権限付与や、自らの権限を不正に拡大しようとする権限昇格のリスクも指摘されています。さらに、大規模言語モデルへの代表的な攻撃手法であるプロンプトインジェクション（外部から命令を埋め込んでシステムを乗っ取る手法）や、データ漏洩への対策も不可欠です。

　特に注意が必要なのが、攻撃増幅のリスクです。エージェントが自律的に動作する性質上、一度侵害されると、被害が人間の介入なしに急速に拡大する可能性があります。このリスクは、従来のソフトウェアと比べてより深刻と考えられます。

設計原則：最小権限と「評価優先」の考え方

　これらのリスクに対して、IBMのガイドラインはセキュリティ・バイ・デザイン、すなわち後付けではなく設計段階からセキュリティを組み込む姿勢を基本方針として掲げています。

　中核となる考え方が最小権限の原則（Principle of Least Privilege）です。これは、エージェントが業務を遂行するために必要な最小限のアクセス権だけを付与し、不要になった瞬間に回収するというものです。加えて、ロールベースのアクセス制御（RBAC）をエージェントにも適用し、人間のユーザーと同様に役割に応じた権限を割り当てます。エージェントをサンドボックス環境（隔離された実行環境）内で動作させることも、万一の際の被害を局限する手段として有効です。

　また、設計段階で「このエージェントに何を許可し、何を禁止するか」という許容範囲の明確化を行うことが重要とされています。ガイドラインでは、KPI（重要業績評価指標）を定義して成果を継続的に計測する「評価優先」のアプローチを採用することで、技術的な実装の詳細よりも目標への適合度を常に確認する体制を構築するよう求めています。

セキュリティフレームワーク：IAM・ゲートウェイ・脅威検知の三層構造

　ガイドラインが示すセキュリティフレームワークは、大きく三つの層で構成されています。

　第一の層はアイデンティティとアクセス管理（IAM）です。重要な点は、エージェントを「非人間的なアイデンティティ」として扱い、固有の認証情報を割り当てることです。エージェント間での認証情報の共有を禁止し、特定のタスクを実行する際にのみ一時的にアクセス権を付与するジャストインタイムアクセスの導入が推奨されています。また、どのエージェントがいつ何を行ったかを追跡できる監査ログの整備も必須とされています。

　第二の層はデータとモデルの保護です。利用者からのリクエストがAIモデルに直接届くのではなく、AIファイアウォール（ゲートウェイ）を経由させる構成が推奨されています。このゲートウェイでプロンプトインジェクションの検出やポリシーの適用を行い、MCPを通じたデータのやり取りにおいてはデータ損失防止（DLP）の観点からの監視も実施します。MCP自体は2024年11月にAnthropicが策定し現在広く普及しているオープンな通信プロトコルで、AIエージェントと外部ツールをつなぐ標準的な仕組みとして機能しています。

　第三の層は脅威の検知と対応です。エージェントが呼び出すツールや操作するサービス、その影響を継続的にモニタリングし、異常な挙動（過剰なデータアクセスや予期しない設定変更など）を検知するアラートを用意します。さらに、反応的な対応にとどまらず、仮説を立てて潜在的な脅威を能動的に調査する脅威ハンティングも重要とされています。

ADLCとDevSecOps：エージェント開発に特化したライフサイクル管理

　ガイドラインは、AIエージェントに特化したエージェント開発ライフサイクル（ADLC）を定義しています。計画・コーディング・テスト・デバッグ・デプロイ・監視という一連のフェーズにわたって、DevSecOps（開発・運用・セキュリティを統合するアプローチ）の考え方を適用します。

　従来のDevOpsではセキュリティが後工程に位置づけられがちでしたが、DevSecOpsでは設計段階から運用・保守に至るまでセキュリティを一貫して維持します。ガイドラインでは特に、開発フェーズと運用フェーズの間に「実験ループ」と「ランタイム最適化ループ」という2つの反復プロセスを設けることで、エージェントの挙動を継続的に改善する仕組みを提唱しています。また、コンフィギュレーションドリフト（設定が意図せず変化していく現象）の監視も、長期運用における重要な管理項目として位置づけられています。

　IBMによれば、このフレームワークはヘルスケア・通信・金融といった規制の厳しい業界でも適用できるよう設計されており、監査証跡の確保やコンプライアンス対応も考慮に入れた内容となっています。

まとめ

　IBMとAnthropicが示したガイドラインは、AIエージェントを安全に運用するための体系的な考え方を提供しています。最小権限の徹底、エージェント固有の識別管理、ゲートウェイによる監査、そして人間による継続的な監視という基本原則は、エージェントAIの導入を検討する組織にとって参考になる指針だと思います。エージェントの自律性が高まるほど、こうした設計段階からの安全対策の重要性も増していくと考えられます。

AI技術 エンジニア関連
AIエージェント AI安全性

この記事が気に入ったら
フォローしてね！

  • URLをコピーしました！
  • URLをコピーしました！

関連記事

目次