【要約】AgentCore GatewayのSlack統合プロバイダーをCDKで設定して3LOで認証認可を通す [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がAgentCore Gatewayを用いてSlack連携を自動化しようとする際、以下の技術的課題に直面する。
- ドキュメントとコンソールの不整合：ドキュメントにはAPI Keyのみとあるが、実際にはOAuthも利用可能である。
- MCPバージョンの制約：デフォルトのMCPバージョンでは3LOに必要なURLエリシテーション機能が不足している。
- IaCによる管理の困難さ：統合プロバイダーの設定がコンソール操作に依存しており、自動化が難しい。
- ドキュメントとコンソールの不整合：ドキュメントにはAPI Keyのみとあるが、実際にはOAuthも利用可能である。
- MCPバージョンの制約：デフォルトのMCPバージョンでは3LOに必要なURLエリシテーション機能が不足している。
- IaCによる管理の困難さ：統合プロバイダーの設定がコンソール操作に依存しており、自動化が難しい。
// Approach
開発者は、コンソールの挙動を解析し、CDKを用いて統合プロバイダーの構成要素を直接定義する手法を採用した。
- MCPバージョンの明示指定：
- OpenAPIスキーマの利用：AWS管理のS3バケットからSlackのスキーマを参照し、ターゲットを定義する。
- L1プロパティオーバーライド：CDKのL2 Constructで設定できない
- CLIによる事後処理：
- MCPバージョンの明示指定：
supportedVersionsに2025-11-25以降を指定し、3LOを有効化する。- OpenAPIスキーマの利用：AWS管理のS3バケットからSlackのスキーマを参照し、ターゲットを定義する。
- L1プロパティオーバーライド：CDKのL2 Constructで設定できない
GrantTypeをAUTHORIZATION_CODEに強制する。- CLIによる事後処理：
update-workload-identityを実行し、リダイレクトURLを許可リストに登録する。// Result
開発者は、手動操作を排除したIaCによるSlack連携環境の構築に成功した。
- 認証認可の自動化：CDKにより、3LOを用いたセキュアなユーザー単位の認証フローを構築できた。
- 設定の簡略化：AWS管理のスキーマを利用することで、複雑なツール定義を省略してSlack操作を実現した。
- 構成の最適化：AWSテンプレートと公式MCPを比較し、用途に応じた使い分けの指針を得た。
- 認証認可の自動化：CDKにより、3LOを用いたセキュアなユーザー単位の認証フローを構築できた。
- 設定の簡略化：AWS管理のスキーマを利用することで、複雑なツール定義を省略してSlack操作を実現した。
- 構成の最適化：AWSテンプレートと公式MCPを比較し、用途に応じた使い分けの指針を得た。
Senior Engineer Insight
> 本手法は、AWSのマネージドサービスを最大限活用しつつ、IaCによる統制を効かせる実践的なアプローチである。ただし、CDKのL2 Constructが未成熟であり、L1へのオーバーライドやデプロイ後のCLI実行が必要な点は、CI/CDパイプライン設計上の留意点となる。また、AWSテンプレートはJSONを直接返すため、LLMのトークン消費量が増大する懸念がある。実運用では、レスポンスの整形度合いとコストのトレードオフを考慮し、公式MCPサーバーの採用も視野に入れるべきだ。