AgentCore GatewayのSlack統合プロバイダーをCDKで設定して3LOで認証認可を通す

Last updated at 2026-08-15Posted at 2026-08-15

はじめに

こんにちは、ふくちと申します。

以前の記事で、Claude Code × AgentCore Gateway × Slack MCPの構成をユーザー単位のOAuth(3LO)でつなぐ方法について解説しました。今回はその番外編です。

本記事ではAgentCore Gatewayの統合プロバイダーテンプレートの使い方を深堀りしていきます。実はこれの選択肢としてSlackがあり、面倒な設定をしなくてもツール一式が事前設定済みで生えてくる便利なものです。

私はAgentCoreが出たばかりのタイミングでこのテンプレートの検証をしており、なんとなくの使い方は下記を見ていただいければわかるかと思います。

公式ドキュメントは下記です。
今でこそ、テンプレートで使えるツールなどが記載されていますが、昨年9月の段階では全く記載されていませんでした。当時私から報告させていただいたAWS JapanのSAさんがちゃんとエスカレくださったのだと思います、感謝です🙏

ただこれを設定する際、2点ほど気になる点がありました。
1つ目は、上記ドキュメントの記載とコンソールの記載が異なる点。

ドキュメントには "Outbound authentication types accepted: API key" と記載されています。つまりアウトバウンド認証に使えるのはAPI Keyタイプのみということ。

ただコンソールを見ると、OAuthクライアントも選択肢にあるんですよね(何気に統合プロバイダーの選択するところも若干変わっていたりします)。
まぁ画面で設定できるということは使えるということだと思うのですが、ちょっと矛盾しているのが気になります。

↓おかげで1回勘違いしてた私

また、3LOでの認証をしたくても2LOしか選択できないケースもありました。これに関してはMCPバージョンの問題とコンソールに書いてあるのですぐわかるんですが、なぜなのかまで理解できていなかったのでちゃんと理解しておきたいですよね。

2つ目は、この統合プロバイダーをターゲットにする設定をIaC(AWS CDK)でできないかと考えていた点。
以前やっていた点は全て手作業だったのですが、大コーディングエージェント時代に手作業はちょっと嫌ですよね。

ということでこの2点を色々試してみました。

結論

OAuthクライアントでもSlackターゲットに接続できる
- コンソールが正で、ドキュメントが誤っているっぽい
- AgentCore GatewayのMCPバージョンは2025-11-25以上が必須
統合プロバイダーテンプレートに相当するものはCDKでも設定できる
- 実体はopenApiSchema型のMCPターゲット(AWS管理のOpenAPIスキーマを参照)と、OAuthクレデンシャルプロバイダーの組み合わせ

ということで、両方できました。

調査

統合プロバイダーテンプレートと、MCPバージョンのところを調査してみてました。

統合プロバイダーテンプレート

結論で記載した通り、これはopenApiSchema型のMCPターゲットでした。
これの確認方法は、get-gateway-target APIを使えばできます。一度AgentCore GatewayのターゲットをSlackテンプレートにして作成した上で、下記を実行します。

aws bedrock-agentcore-control get-gateway-target \
  --gateway-identifier <gateway-id> \
  --target-id <target-id>

上記の実行結果として返ってきたtargetConfigurationはこうでした。

{
  "mcp": {
    "openApiSchema": {
      "s3": {
        "uri": "s3://amazonbedrockagentcore-built-sampleschemas.../slack-open-api.json"
      }
    }
  }
}

ということで、テンプレートの中身はAWSが管理するS3バケットに置かれたSlack Web APIのOpenAPIスキーマを参照する、ただのopenApiSchemaターゲットです。
このスキーマから、チャンネル履歴取得やメッセージ投稿など20個ほどのツールが生成されています。

コンソールでは統合プロバイダーテンプレートとして記載されていますが、裏側ではAWS側が定義したOpenAPIスキーマが使われていた、というかたちですね。

ちなみにtargetConfiguration.mcpのunionは openApiSchema, smithyModel, lambda, mcpServer, apiGateway の5種類だけです。
integrationやtemplateという種別が無いことからも裏取りできました。

そしてこれが分かると、テンプレートはCDKでも設定できます。コンソールが最終的に作るものと同じものをCDKで書けば良いですね。

AgentCore GatewayのMCPバージョン

AgentCore GatewayのターゲットでSlackテンプレートを選択した際に3LOが選べなかった理由は、MCPバージョンが古かったためです。

執筆時点でAgentCore Gatewayがサポートするのは2025-03-26 / 2025-06-18 / 2025-11-25 / 2026-07-28の4バージョンです。そしてデフォルト値は2025-03-26となるようです。

しかし先のコンソールで記載されていた通り、3LOを採用する場合は2025-11-25以上の設定が必要です。

理由は、3LOの処理で用いられるMCPのURLエリシテーションが関係しているため、だと考えられます。
3LOにおいては、処理途中でAgentCore GatewayからMCPクライアントにURLを渡し、ユーザーに同意してもらう必要があります。

これがMCPのURLエリシテーションという2025-11-25以降で搭載された仕組みを用いて実現されているもののようなんですよね。エリシテーションというのは以前からあったみたいですが、URLモードが新しく追加されたのが2025-11-25みたいです。

新機能：MCP仕様の2025-11-25バージョンにて、「URLモード誘出（elicitation）」が導入されました

古いMCPバージョンにはURLモードが無いので、3LOを設定しても処理が完了できません。なので3LOを選択できないバージョンがあるというわけです。

そもそもエリシテーションて何やねんという方は以下をどうぞ。

実装

ここから具体的にAWS CDKでどう書いていけばいいかをまとめます。要素は大きく3つです。

AgentCore Gateway本体(MCPバージョン2025-11-25を指定する)
3LO用のOAuth2クレデンシャルプロバイダー(AgentCore Identity)
統合プロバイダーテンプレート相当のopenApiSchemaターゲット

このうち2については、Slackのユーザー用エンドポイントを指定したカスタムプロバイダーを作る必要があります。作り方は以前の記事に書いたのでそちらを参照してください。
以降のコード中のslackOAuthProvider(プロバイダー本体)とslackOAuthClientSecret(クライアントシークレットを入れたSecrets Managerのシークレット)はそれを指します。

AgentCore Gateway本体

まずはAgentCore Gatewayそのものの定義です。ここで2025-11-25を指定します。

import { aws_bedrockagentcore as agentcore } from "aws-cdk-lib";

// userPool / userPoolClient は別途作成済みのCognitoリソース

// 3LOターゲットを使うにはMCP 2025-11-25以上が必要
const MCP_VERSION_FOR_USER_OAUTH =
  agentcore.MCPProtocolVersion.of("2025-11-25");

const gateway = new agentcore.Gateway(this, "McpGateway", {
  gatewayName: "example-mcp-gateway",
  description: "サンプルゲートウェイ",
  protocolConfiguration: new agentcore.McpProtocolConfiguration({
    // ここがMCPバージョンの指定箇所。省略するとデフォルト値のままになる
    supportedVersions: [MCP_VERSION_FOR_USER_OAUTH],
    searchType: agentcore.McpGatewaySearchType.SEMANTIC,
  }),
  // インバウンド認証。ここではCognitoのJWTで受ける想定
  authorizerConfiguration: agentcore.GatewayAuthorizer.usingCognito({
    userPool,
    allowedClients: [userPoolClient],
  }),
});

MCPバージョンはprotocolConfiguration.supportedVersionsで指定します。CDKのL2 Constructはこのpropsを渡さないとCloudFormationテンプレートにsupportedVersions自体を出力しないようです。

つまりCDK側が気を利かせて新しいバージョンを入れてくれることは無いので、明示指定が必要です。
なのでこれを設定せずに作成してしまうと、ターゲット設定時に3LOが選択できなくなります。

また、このagentcore.MCPProtocolVersionはenumではなくクラスで、MCP_2025_03_26 / MCP_2025_06_18という定数のほかにof(value)というエスケープハッチが用意されています。

執筆時点の最新版(aws-cdk-lib@2.265.0)を確認しても2025-11-25や2026-07-28の定数はまだ無いので、of("2025-11-25")で渡して設定する形になります。

AgentCore Gateway名は後から変更できませんが、supportedVersionsのほうはUpdateGatewayで差し替えができます。バージョンを間違えても作り直しにはならないので、そこは安心してよさそうです。

なおインバウンド認証にCognitoを使う場合、Claude CodeなどのMCP OAuthクライアントはAgentCore Gateway URLをresourceパラメータとして送ってきます。
Cognito側がそのresourceを知らないとトークンを発行してくれないので、AgentCore Gateway URLをidentifierにしたリソースサーバーも合わせて作成します。

userPool.addResourceServer("McpGatewayResourceServer", {
  userPoolResourceServerName: "example-mcp-gateway",
  identifier: gateway.gatewayUrl!,
});

resourceってなんやねんという方は下記記事をどうぞ。

ターゲットでSlackテンプレートを設定する

続いて、本題のSlackテンプレートをCDKで定義します。前述の通りopenApiSchemaターゲットを用います。

import { aws_s3 as s3 } from "aws-cdk-lib";

// コンソールの統合プロバイダーテンプレートが参照する、AWS管理のサンプルスキーマバケット。
// URIは環境で異なる可能性があるため、一度コンソールでテンプレートからターゲットを作り、
// get-gateway-target で実際のURIを確認して転記するのが確実。
const SLACK_API_SCHEMA_BUCKET = "amazonbedrockagentcore-built-sampleschemas...";
const SLACK_API_SCHEMA_KEY = "slack-open-api.json";

const schemaBucket = s3.Bucket.fromBucketName(
  this,
  "SlackApiSampleSchemaBucket",
  SLACK_API_SCHEMA_BUCKET,
);

const slackApiTarget = gateway.addOpenApiTarget("SlackApiTarget", {
  gatewayTargetName: "SlackApi",
  description: "3LOを用いたSlack MCPツール",
  apiSchema: agentcore.ApiSchema.fromS3File(
    schemaBucket,
    SLACK_API_SCHEMA_KEY,
  ),
  credentialProviderConfigurations: [
    agentcore.GatewayCredentialProvider.fromOauthIdentityArn({
      providerArn: slackOAuthProvider.attrCredentialProviderArn,
      secretArn: slackOAuthClientSecret.secretArn,
      scopes: [
        "channels:history",
        "channels:read",
        "groups:history",
        "groups:read",
      ],
    }),
  ],
});

L2 ConstructのApiSchema.fromS3FileはS3のURI文字列ではなくS3バケットのconstructを要求します。AWS管理バケットは自アカウントに存在しないので、s3.Bucket.fromBucketNameで名前参照を作って渡します。

synth結果を確認すると、ちゃんとs3://バケット名/キー形式のURIに展開されます。

ただ、これだけだと認可グラントタイプが既定値(2LO)のままなので、3LOを明示的に設定します。
執筆時点のAgentCore Gateway L2 Constructはグラントタイプとreturn URLを直接設定できないため、L1へのプロパティオーバーライドで指定します。

// ターゲットの設定を上書きする
const slackApiTargetResource = slackApiTarget.node
  .defaultChild as agentcore.CfnGatewayTarget;

slackApiTargetResource.addPropertyOverride(
  "CredentialProviderConfigurations.0.CredentialProvider.OauthCredentialProvider.GrantType",
  "AUTHORIZATION_CODE", // 3LOの設定
);
slackApiTargetResource.addPropertyOverride(
  "CredentialProviderConfigurations.0.CredentialProvider.OauthCredentialProvider.DefaultReturnUrl",
  "http://localhost:3000/callback",
);

DefaultReturnUrlにはhttp://localhost:3000/callbackを指定しています。ここは3LOの流れを理解する必要があります。簡単に言うと、セッションバインディングが必要だから、という話です。

詳細は下記リンクをご参照ください。
なお、これはClaude Codeなどのローカル環境からAgentCore GatewayへMCP接続している前提に基づきます。

最後に、cdk deployした後に下記コマンドを実行する必要があります。

aws bedrock-agentcore-control update-workload-identity \
  --name <gateway-id> \
  --allowed-resource-oauth2-return-urls "<return-url>"

何をしているかと言うと、AgentCore Gatewayに紐づくワークロードアイデンティティ(AgentCore Identity上の実行主体)の許可リストにこのURLを登録しています。

AgentCore Gatewayが3LOを開始するとき、内部的にはGetResourceOauth2Tokenが呼ばれ、DefaultReturnUrlはresourceOauth2ReturnUrlとして渡ります。そのパラメータの説明がこれです。

The callback URL to redirect to after the OAuth 2.0 token retrieval is complete. This URL must be one of the provided URLs configured for the workload identity.
OAuth 2.0 トークンの取得が完了した後にリダイレクトするコールバックURLです。このURLは、ワークロードアイデンティティに設定されている指定済みURLのいずれかと一致している必要があります。

ざっくり流れを整理するとこんな感じです。

OAuthのredirect_uri事前登録と同じ発想で、ここに登録されたURLだけを許可する設定を入れておく必要があるということです。ちなみにこの許可リストが空の時は一切の検証が走らず、どんなURLでも通るようになっているようです。つまりセキュリティが結構ガバガバ。

一方で1つでも登録したら、その許可リストのURLと完全一致していないと弾かれるようになります。なのでプログラム上必須ではないのですが、設定しておくに越したことはないパラメータとなっているようです。

AgentCore Gatewayを作るとそのIDを名前にしたワークロードアイデンティティが自動生成されるので、デプロイ後にこの許可リストを更新します。
執筆時点ではこのプロパティをCDK側から設定できないため、私はCI/CDのデプロイジョブの後処理として先程のコマンドを実行しています。

そしてここまでを踏まえて、デプロイしてターゲットがREADYになれば完成です。認可グラントタイプも3LOが選択されているはずです。

これを使って、Claude Codeから自分の権限の範囲でSlackを参照して、イベント運営の準備などを色々やっています。

おまけ：公式MCPサーバーとどう使い分けるか

おまけとして、同じAgentCore GatewayにAWSが提供するSlackテンプレートとSlack公式MCPサーバーを両方ターゲットとして設定し、比較してみました。

観点	AWSテンプレート	Slack公式MCP
経路	Slack Web APIへ接続	リモートMCPサーバーへ接続
ツールの粒度	Web APIのラッパー	エージェント向けに設計済み
返り値	生のJSON	整形済みテキスト
追加コンポーネント	なし	環境によっては互換proxyが必要

AgentCore GatewayからSlack APIへ直接繋げられる点では、AWSテンプレートの方がシンプルな構成です。AWS側の設定もかなりシンプルなので、最初はこっちの方が楽かもしれません。

ただしツールの使い勝手は公式MCPが上です。設定は若干大変ですが。

シンプルにチャンネルの最新メッセージを取ってくる作業1つ取っても、公式MCPは読みやすく整形されたテキストを返してくれます。
しかしAWSテンプレート側はJSONをそのまま返すのでトークン消費量的に結構ネックそうです。

個人的にはPoCならAWSテンプレートを使い、本番で使うならSlack公式MCPを使うかな、という感覚です。

まとめ

ということで冒頭の謎2つは解消されました。

ドキュメントとコンソールの整合取れていない問題は、ドキュメント側の記載が若干おかしいっぽいです。Slackテンプレートの認証にはAPI KeyだけでなくOAuthでも使えます。
また、CDKでも設定可能なのでコンソールぽちぽちしなくていいのはありがたいですね。

これにて下記は解消済みとさせていただきます^^

宣伝

2026.12.19(土)にAWS × AIなイベント、AI Builders Day 2026をAWS Japanの麻布台オフィスにて開催します！Save the Date！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up