弁護士ドットコムのAWS DevOps Agent事例に学ぶ、AIエージェントの認証・認可セキュリティ要件

AWS Japan Blog：寄稿：弁護士ドットコムにおける AWS DevOps Agent の活用事例（2026年7月27日公開）は、生成AIエージェントを本番の運用フローに組み込んだ、極めて具体的で新しい事例です。この記事では、まず事例そのものを解説し、次に「なぜ本番投入しても安全と言えるのか」をAWS公式ドキュメントまで踏み込んで深掘りし、最後にAIエージェントを安全に運用するために押さえるべきセキュリティ要件をまとめます。

1. 何が起きたのか（事例の要約）

弁護士ドットコム株式会社は、国内最大級の法律相談ポータル「弁護士ドットコム」と、契約マネジメントプラットフォーム「クラウドサイン」を運営する企業です。事業拡大に伴いアラート数が増加し、原因調査が一部の熟練エンジニアに依存する「属人化」が課題になっていました。

導入前の課題

調査対応が一部の熟練エンジニアに依存していたため、属人化の解消が急務

従来は、アラートを認知してから原因を特定し対応するまでのプロセスに、熟練エンジニアでも約30分かかっていました。

構成と自動化フロー

Datadog（監視・アラート検知）
  ↓ webhook
AWS DevOps Agent（自動起動）
  ├─ Datadogのメトリクス・APMトレースを分析
  ├─ Amazon ECSのデプロイ履歴・タスク状態と相関分析
  ├─ Amazon CloudWatchのメトリクスを横断分析
  └─ ホスト単位の影響範囲を特定
  ↓
Jira（自動起票）＋ Slack（構造化レポート配信）

DevOps Agentは、Datadogのデータだけでなく、Amazon ECSのデプロイ履歴やタスク状態、Amazon CloudWatchのメトリクスといった複数のAWSリソース情報を横断的に分析します。実際の事例では、特定インスタンスでレイテンシが15倍に増幅するN+1クエリ問題を、調査開始から約10分で特定しました。

効果

• 調査時間：30分 → 約10分
• 対応漏れの解消：自動起票によりインシデントの追跡が強化される
• 属人化の解消：非専門のエンジニアでも構造化レポートから対応判断が可能に

2. なぜこの事例が「学び」になるのか

元記事で、本番環境への適用を後押しした理由として挙げられているのは次の一文です。

DevOps Agent は参照権限のみで動作する点も、本番環境への適用を安心して行えるポイントでした。

これは非常に重要な指摘ですが、元記事では具体的な権限スコープまでは明かされていません。「参照権限のみ」が実際にどう技術的に担保されているのかが分からなければ、自組織で同様の仕組みを検討する際の判断材料になりません。そこで、AWS公式ドキュメントまで踏み込んで深掘りします。

3. 深掘り：AWS DevOps Agentの認証・認可モデル

3.1 二層の権限モデル（IAMロール × Permission Guardrail）

AWS DevOps Agentがユーザーのリソースへアクセスする際、実際に使える権限は次の**積集合（AND）**で決まります。

実際に使える権限 = あなたが設定したIAMロールのポリシー ∩ Permission Guardrail（AWS側が設定するセッションポリシー）

Permission Guardrailは、DevOps Agentがセッションを開始するたびに適用するセッションポリシーで、「エージェントが絶対に超えられない上限」として機能します。つまり、運用者がIAMロールにうっかり強い権限を付与してしまっても、Guardrailに含まれていない権限は一切使われません。

デフォルトで有効なのはAIDevOpsAgentAccessPolicyという管理ポリシーで、約150のAWSサービスに対するDescribe*／Get*／List*中心の読み取り専用権限で構成されています。書き込み系のアクションはcloudtrail:StartQuery（ログの検索実行）とsupport:CreateCase（サポートケース起票）のみで、リソースを変更・削除するアクションは含まれません。

さらに、S3オブジェクトの読み取りやDynamoDBのクエリなど、デフォルトにはない権限もGuardrail側では許可リストに用意されており、運用者が明示的にオプトインすることで初めて使えるようになります。Guardrailに含まれない権限は、ロール側でいくら許可しても使えません。例えばs3:PutObjectやec2:TerminateInstancesのような書き込み・削除系のアクションは、Guardrailに存在しないため、ロールが許可していてもエージェントは実行できません。

3.2 Service-Linked Role（AWSServiceRoleForAIDevOps）

DevOps Agentサービス自身が使うロールは、aidevops.amazonaws.comのみを信頼するService-Linked Roleです。権限は、自身の使用状況メトリクスをAWS/AIDevOps名前空間にのみ送信する（cloudwatch:PutMetricDataをnamespace条件で限定）、プライベート接続用のVPC Latticeリソースを自分が作成したものだけ操作できる（aws:RequestTag/aws:ResourceTag条件で限定）など、サービスの動作に必要な範囲だけに厳格にスコープされています。IAMの最小権限設計として模範的な作り方です。

3.3 Primary Account RoleとSecondary Account Role

複数のAWSアカウントにまたがるシステムを調査する場合、DevOps Agentは以下の2種類のロールを使い分けます。

ロール種別	対象
Primary account role	Agent Spaceを作成したAWSアカウント内のリソースへのアクセス
Secondary account role	Agent Spaceへ追加接続した他のAWSアカウントへのアクセス

どちらのロールでも、アクセス可能なAWSサービス・リソース・リージョンを個別に制限できます。実務では、リソースARNパターン（例：production-*という名前のLambda関数のみ）やリソースタグ（例：Environment=productionのみ）、リージョン（aws:RequestedRegion条件）で絞り込むことが推奨されています。

3.4 秘密情報へのアクセス設計

AIDevOpsAgentAccessPolicyにはsecretsmanager:Describe*・secretsmanager:GetResourcePolicy・secretsmanager:List*が含まれていますが、secretsmanager:GetSecretValueは含まれていません。

つまりDevOps Agentは「どんなシークレットが存在するか」「そのシークレットにどんなリソースポリシーが設定されているか」までは調査できますが、シークレットの中身（実際の値）は読み取れません。認証情報を扱うAIエージェントにおいて、これは非常に重要な設計判断です。調査に必要な情報（存在・設定の妥当性）と、漏洩してはならない情報（実際の認証情報）を、権限レベルで明確に分離しています。

3.5 MCP／A2Aサーバー接続の認証（アクセストークン管理）

弁護士ドットコムの事例では、Datadog・Jira・SlackとMCP経由で連携しています。この接続を支えるのが、DevOps Agent自身が持つアクセストークン管理機能です。

• aidevops:CreateAccessToken – リモートMCP／A2Aサーバー認証用のアクセストークンを発行
• aidevops:RotateAccessToken – 設定を保ったままトークン値だけを更新（ローテーション）
• aidevops:RevokeAccessToken – トークンを永久に無効化

サードパーティサービスとの連携は、長期の固定シークレットではなく、発行・ローテーション・失効を管理できるアクセストークンを介して行う設計です。加えて、Operator Web App（人間がDevOps Agentを操作するための画面）には、外部IdPとの連携設定（UpdateOperatorAppIdpConfig）やワンタイムログインセッション（CreateOneTimeLoginSession）の仕組みも用意されており、人間側のログインとエージェント側のリソースアクセスとで、認証の経路が明確に分離されています。

3.6 事例記事との答え合わせ

以上を踏まえると、弁護士ドットコムの記事にあった「参照権限のみで動作する」という一文は、実際には次の3つの仕組みの組み合わせで担保されていると解釈できます。

1. デフォルトで読み取り専用権限（AIDevOpsAgentAccessPolicy）のみが有効
2. 仮に運用者が誤って強い権限をロールに追加しても、Permission Guardrailが上限として機能し続ける
3. シークレットの値やIAMの変更・EC2の削除など、書き込み・機密情報系のアクションはGuardrail自体に存在しない

「参照権限のみ」という一文だけを信じるのではなく、その裏にある技術的な担保の仕組みを確認できるかどうかが、AIエージェントを本番投入する際の判断材料になります。

4. AIエージェント特有の攻撃面（認証だけでは防げないリスク）

IAMによる認証・認可はAIエージェントの安全性の土台ですが、それだけでは防げないリスクもあります。OWASP Top 10 for LLM Applicationsの観点も踏まえ、DevOps Agentのような「観測データを読み、外部ツールと連携し、レポートを配信する」エージェントに特有のリスクを整理します。

リスク	内容	DevOps Agent文脈での具体例
間接的プロンプトインジェクション	エージェントが読み込むデータ自体に悪意ある指示文が混入し、AIがそれを指示として解釈してしまう	ログメッセージやAPMトレースのタグに攻撃者が仕込んだ文字列が含まれ、エージェントの挙動を誘導される
Excessive Agency（過剰な自律性）	エージェントに与えられた権限・自律的な行動範囲が、本来の目的に対して過剰になる	Permission Guardrailで技術的に上限は抑えられるが、ロール側で追加権限を安易に有効化すると実質的な行動範囲が広がる
機微情報の二次的漏洩	読み取り専用でも、収集した情報を要約・転記した先（Slack／Jira等）から情報が広く見えるようになる	IAMロール構成やセキュリティグループ設定など、インフラの内部構造がSlackチャンネルの閲覧者全員に見える状態になる
サードパーティ・サプライチェーンリスク	MCPサーバーや連携先ツール自体が侵害された場合、エージェント経由で影響が波及する	Datadog／Jira／Slack等の連携設定や認証情報が侵害された場合の影響範囲
トークン漏洩時の影響範囲	アクセストークンが漏洩した場合に、どこまでの操作が可能になるか	ローテーション・失効の仕組みがあるか、漏洩検知の仕組みがあるかが被害の広がりを左右する

5. 押さえるべきセキュリティ要件チェックリスト

自組織でAIエージェントを本番運用へ組み込む際に、最低限確認すべき項目です。

認証・認可

• エージェントが引き受けるロールは、デフォルトで読み取り専用（Describe/Get/List中心）になっているか
• ロールの権限とは別に、AWS（またはプラットフォーム）側が管理する「上限」の仕組み（セッションポリシー等）が存在するか
• 複数アカウント・複数環境にまたがる場合、アカウントごと・環境ごとにロールが分離されているか
• リソースへのアクセスをARNパターン・タグ・リージョンで絞り込めるか
• シークレットの「存在確認」と「値の読み取り」が権限レベルで分離されているか（GetSecretValue相当の権限が不用意に付与されていないか）
• サードパーティ連携（MCP等）の認証情報は、発行・ローテーション・失効を管理できる仕組みになっているか
• 人間の操作用ログイン（管理画面等）と、エージェントのリソースアクセス用の認証経路が分離されているか
• 書き込み・削除を伴う操作は、人間の承認（Human-in-the-loop）を経由する設計になっているか

AI特有の攻撃面

• エージェントが読み込む外部データ（ログ・トレース・チケット等）に対する間接的プロンプトインジェクション対策を検討したか
• エージェントの権限拡張（デフォルト以上の権限追加）を行う際、実際に必要な範囲かをレビューする運用があるか
• エージェントが生成する調査結果・レポートの配信先（チャット・チケット管理ツール等）のアクセス範囲は適切か
• 連携する外部サービス（監視ツール・チケット管理・チャット等）自体のセキュリティ状態を評価しているか
• アクセストークン漏洩を想定した検知・ローテーション・失効の運用手順があるか

6. まとめ

弁護士ドットコムの事例は、生成AIエージェントを本番の運用フローへ組み込むという、他社にとっても参考になる先進的な取り組みです。一方で、公開されている事例記事だけでは「なぜ安全と言えるのか」の技術的な裏付けまでは分かりません。

AIエージェントを評価する際は、「参照権限のみ」「最小権限」といった説明を鵜呑みにせず、実際にどのような仕組みでその説明が担保されているのか（今回であればIAMロールとPermission Guardrailの二層構造、シークレット値へのアクセス制限、アクセストークンのライフサイクル管理）を確認することが、AIエージェントを安全に採用するための実務的な出発点になります。