AWS MCP（ドキュメント検索・リソース操作系）を整理｜権限の絞り方とAssumeRole（網羅・要確認）

AWS環境が大規模化・複雑化する中で、必要なドキュメントやリソースを即座に特定し、安全に操作することは容易ではありません。特に近年では、AIがコンテキストを理解してツールを実行するMCP（Model Context Protocol）の概念が登場し、エンジニアが手動でコンソールを叩くのではなく、プログラムやエージェントを介してAWSリソースを操作する場面が増えています。

本記事では、AWSにおけるリソース検索（ドキュメント検索）の仕組みから、それらを安全に操作するためのIAM権限の絞り方、そして実務に不可欠なAssumeRoleの設計までを網羅的に解説します。

AWS環境におけるドキュメント・リソース検索の全体像

AWS上で「何かを探す」という行為は、対象によって利用するサービスが異なります。メタデータを探すのか、ファイルの中身を探すのかによって、適切なアーキテクチャを選択する必要があります。

AWS Resource Explorerによるメタデータ検索

「あのEC2インスタンスはどこにある？」「特定タグがついたS3バケットを一覧化したい」といった要望に応えるのが、AWS Resource Explorerです。これは、AWSマネジメントコンソール上部にある検索バーのバックエンドとしても機能しています。

• 特徴: リージョンを跨いだ検索が可能（アグリゲーターリージョンの設定が必要）。
• 料金: 基本機能は無料。
• 公式サイト: AWS Resource Explorer

Amazon Kendraによるドキュメント検索

設計書（PDF）や運用マニュアル（Word）、S3上のテキストデータの内容までを深く検索（セマンティック検索）したい場合は、Amazon Kendraが選択肢に入ります。これは高機能なエンタープライズ検索サービスであり、機械学習を用いて質問に対する回答を抽出します。

大規模な組織では、このKendraをMCPのデータソースとして活用し、AIエージェントがAWSドキュメントを読み取って判断を下す仕組みを構築します。なお、Kendraの料金はDeveloper Editionで月額約810ドルからとなっており、導入にはコスト対効果の検討が必須です（公式料金ページ：Amazon Kendra Pricing）。

社内のデータ活用においては、AWSリソースだけでなく、SaaSに蓄積された情報の統合も重要です。例えば、経理周りの情報をAWS経由で分析する際、楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャで語られるような、データ連携の自動化が先行して求められるケースも多々あります。

権限設計の鉄則：検索権限と操作権限の分離

AWSリソースを検索・操作するMCPエージェントやスクリプトを運用する際、最も陥りやすい罠が「権限の与えすぎ」です。

ReadOnlyAccessを安易に使わない理由

AWS管理ポリシーの ReadOnlyAccess は一見安全に見えますが、実は非常に強力な権限です。S3バケットの中身を閲覧できたり、Lambdaのコードをダウンロードできたりするため、機密情報が含まれる環境では「過剰な権限」となります。

アクションレベルでの権限の絞り方

最小権限の原則（Least Privilege）に基づき、以下の3層でポリシーを定義することを推奨します。

1. List系: リソースの存在を確認する（例：s3:ListAllMyBuckets）
2. Describe/Get系: リソースの設定詳細を確認する（例：ec2:DescribeInstances）
3. Operate系: リソースの状態を変更する（例：ec2:StartInstances）

MCPツールを構成する場合、まずは「List」と「Describe」のみを許可した「閲覧専用ロール」から作成し、必要に応じて「Operate」権限を段階的に追加していくのが実務上の定石です。

AssumeRoleによる安全なリソース操作

静的なIAMユーザーのアクセスキーを使い続けることは、漏洩時のリスクが極めて高いです。そこで利用すべきなのが AssumeRole（一時的認証情報） です。

AssumeRoleの仕組みとメリット

AssumeRoleは、信頼されたエンティティ（ユーザーや他のAWSサービス）に対し、一定時間だけ有効なセキュリティトークンを発行する仕組みです。

• 有効期限の存在: トークンは最短15分、最長12時間で失効する。
• アクセスキー不要: エージェント実行環境（EC2やLambda）にインスタンスプロファイルを付与すれば、コード内に秘密鍵を記述する必要がない。

スイッチロール設定の具体的なステップ

実務で頻用される「操作用アカウントへスイッチする」際の手順を整理します。

1. ロールの作成: 操作対象のアカウント（Account B）でIAMロールを作成。信頼ポリシーに操作元アカウント（Account A）のIDを指定。
2. 権限の付与: 操作元（Account A）のユーザー/グループに sts:AssumeRole 権限を付与。
3. 実行: AWS CLIの場合、~/.aws/config に role_arn と source_profile を記述。

このように、インフラの権限管理を自動化・セキュアに保つことは、SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐといったID管理の全体最適化にも繋がる重要なステップです。

実務で使える検索・操作ツール比較

検索と操作の要件に応じた主要ツールの比較表です。

MCP（Model Context Protocol）導入時のIAM権限実装ガイド

LLMを介してAWSを操作するMCPサーバーをデプロイする際、セキュリティと利便性のバランスをどう取るべきか。具体的な実装例を示します。

特定S3バケットのみを対象にするポリシー例

「ドキュメント検索」を特定バケット（my-company-docs）に限定する場合、以下のようなIAMポリシー（JSON）が最小構成となります。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::my-company-docs"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::my-company-docs/*"
}
]
}

よくあるエラー「AccessDenied」のデバッグ手法

AssumeRoleを用いた検索や操作でエラーが発生する場合、以下の3点を確認してください。

• 信頼関係（Trust Relationship）: IAMロール側の「信頼関係」タブに、AssumeRoleを試みているエンティティが許可されているか。
• セッション持続時間: MCPサーバーやスクリプトが長時間稼働する場合、トークンの有効期限が切れていないか。
• SCP（Service Control Policies）: AWS Organizationsを利用している場合、親アカウント側でその操作（例：Kendraへのアクセス）が禁止されていないか。

さらに、AWSの運用だけでなく、Google WorkspaceなどのSaaSを組み合わせた業務自動化を検討しているなら、Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイドが参考になります。AWSの強力なバックエンドとAppSheetのようなフロントエンドを組み合わせることで、非エンジニアでも安全にリソース検索結果を活用できる環境が整います。

まとめ

AWSのMCP（ドキュメント検索・リソース操作）を使いこなす鍵は、高度な検索ツールの選定以上に、「誰が、どのリソースに対し、どこまでの権限で触れるか」をAssumeRoleを用いて厳格に定義することにあります。Resource ExplorerやKendraを適切に配置し、IAMでの絞り込みを徹底することで、安全で機動的なITインフラ運用を実現してください。