AWS Builder Center

Builder Center

AIエージェントに「人間の承認」を：Amazon Bedrock × MCP × Slack で作る承認ゲート

AIエージェントに「人間の承認」を：Amazon Bedrock × MCP × Slack で作る承認ゲート

AIエージェントに「人間の承認」を

Yuuki Yamashita

Cloud Engineer
AIエージェントは一線を越えました。
ツール利用によって、質問に答えるだけでなく「行動」するようになったからです
Amazon Bedrock を使えば、エージェントは判断と実行を1つのループの中で完結できます。
これがエージェント型AIの魅力であり、同時にリスクでもあります。「自律」が「無監督」であってはいけません。
そこで作ったのが Aegis です。任意のエージェントが高リスクな操作の前に一旦止まり、人間に Approve（承認）/ Deny（却下）/ Edit & Approve（修正して承認） を Slack で求められる、人間が承認するためのコントロールプレーンです。
  • ▶️ デモ動画: https://youtu.be/c1jqPDPo6AU
  • 💻 コード: https://github.com/yama3133/aegis-slack-app

Amazon Bedrock の2つの役割

Aegis では Bedrock が、性格の異なる2つの仕事で登場します。

① 自律エージェント（Claude Sonnet 4.6 / Converse + ツール利用）

エージェントは Converse API のツール利用ループで動きます。安全性はオーケストレーターにハードコードされているのではなく、システムプロンプトと「与えられた承認ツール」から生まれます。
1
2
3
4
5
6
const res = await bedrock.send(new ConverseCommand({
modelId: "us.anthropic.claude-sonnet-4-6",
system: [{ text: SYSTEM_PROMPT }], // 「高リスク操作の前に必ず request_approval を呼ぶ…」
messages,
toolConfig: { tools }, // request_approval / check_approval / wait_for_approval
}));
高リスクな操作の前にモデルは request_approval を呼び、wait_for_approval で人間の判断が出るまでブロックします。
人間が引数を修正した場合、プロンプトは「返ってきた値を使って」と要求します。
モデルが自分自身をゲートします——追加のフレームワークは不要です。

② レビュアーの補助（Claude Haiku 4.5）

承認の質は、レビュアーがその操作をどれだけ理解しているかで決まります。
そこで各リクエストは、カード投稿の前に、高速・低コストな Bedrock モデル（Claude Haiku 4.5）で平易な言葉に要約されます。
📋 In plain language: ops-agent will issue a $1,200 refund to ACME Corp for order ORD-4413 due to a reported duplicate charge.
レビュアーはJSONの塊ではなく、1文を読むだけで済みます。
2つのモデル、2つのコスト/レイテンシ特性を、1つのワークフローで使い分ける——Bedrock のモデル選択の良さが活きる場面です。

ゲートは MCP で疎結合に

承認ロジックをエージェントに埋め込みたくありませんでした。
Model Context Protocol（MCP）がその「継ぎ目」です。
Aegis は3つのツールを公開する MCP サーバーで、Bedrock 製でも他でも、どのエージェントも推論ロジックを変えずに導入できます。
ツール役割
request_approvalSlackに承認カードを投稿し、リクエストIDを返す（ポリシーで自動承認の場合あり）
check_approval現在のステータスと、修正された引数を取得
wait_for_approval人間が判断するか、タイムアウトするまでブロック

ポリシー：$45の返金で人間を呼ばない

すべての操作を止めるゲートは、誰も使わないでしょう。
小さなポリシーエンジンが「誰の承認が必要か」を判定します。
  • 自動承認：低リスク・少額（$45の返金は即座に🤖通過）
  • N-of-M：critical な操作——本番テーブルの削除には2人の承認が必要
  • TTL：保留のまま放置されたリクエストは失効。フェイルセーフ設計

ワークスペースの文脈：Real-Time Search

Bedrock の要約に加えて、Aegis は各カードに関連する Slack メッセージを Slack の Real-Time Search API（assistant.search.context）で添付します。
承認者はカードを離れずに、そこに至った会話をパーマリンク付きで確認できます。

アーキテクチャ

Amazon Bedrock 上のエージェントが MCP 経由で request_approval を呼ぶ
→ Aegis がポリシー判定し、Bedrock 要約と Real-Time Search の文脈で内容を強化
→ Slack に Block Kit の承認カードを投稿
→ 人間の判断が wait_for_approval でエージェントに返る。
すべてのステップは監査ログに記録されます。

ビルダーへの学び

  • Bedrock のモデルの多様性は「機能」である。 エージェントの推論には強いモデル（Sonnet 4.6）、要約には高速なモデル（Haiku 4.5）——同じAPIで、異なるトレードオフを使い分けられる。
  • ガードレールはエージェントの外に置く。 MCP により、承認ゲートは複数のエージェント/フレームワークで再利用できる。
  • Human-in-the-loop は UX の問題。 要約・文脈・そして操作を「修正できる」ことが、承認を“ハンコ”ではなく“判断”に変える。
Slack Agent Builder Challenge 向けに制作。技術スタック: TypeScript · Amazon Bedrock（Claude Sonnet 4.6 + Claude Haiku 4.5）· Model Context Protocol · Slack Bolt（Socket Mode）· Slack Real-Time Search API。
  • ⭐ コード・セットアップ: https://github.com/yama3133/aegis-slack-app
  • ▶️ デモ: https://youtu.be/c1jqPDPo6AU
# amazon-bedrock# mcp# typescript
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article