Agent Runtimeはすでに存在する——Amazon Connectという名前で
AIエージェントの「実行基盤」を作りたい。そう考えて、LangGraphやCrewAIのドキュメントを読み始めた人は多いと思う。
私もその一人だった。
だが、ある日ふと気づいた。自分がすでに何年も運用してきたAmazon Connectの構造を、改めて分解してみたら——それは、まさにAgent Runtimeそのものだった。
この記事では、Amazon ConnectをAgent Runtimeの視点から再解釈する。電話の中に、すでにAIエージェントの実行基盤が存在していた——その構造を整理したい。
Agent Runtimeとは何か
まず前提を揃える。
Agent Runtimeとは、AIが仕事を実行するための実行基盤のことだ。LangGraphは自らを「agent runtime and low-level orchestration framework」と定義している。
一般的な構造はこうなる。
・Input（入力）
・Perception（意図理解）
・Planning（計画）
・Action（実行）
・Tools（外部ツール連携）
・Memory（記憶・文脈保持）
LangGraphもCrewAIもAutoGenも、基本はこの構造を持つ。入力を受け取り、意図を理解し、計画を立て、ツールを使って実行し、結果を記憶する。
ここまでは、多くのエンジニアが理解しているはずだ。
Amazon Connectの構造を分解する
ここからが本題になる。
Amazon Connectの内部構造を、同じフレームで分解してみる。
・Voice / Chat / SMS / Email / Video → Input
・Amazon Lex（NLU/ASR） → Perception
・Contact Flow（ワークフロー） → Planning
・AWS Lambda / API → Action
・DynamoDB / Redshift / CRM → Tools
・Customer Profiles → Memory
つまり、Amazon Connectは実質的にAgent Runtimeの構造を持っている。
これは比喩ではない。Amazon Connectの公式ドキュメントを読むと、Flowsは「customer experienceをstart to finishで定義するもの」と明記されている。入力の受け取りから、意図理解、分岐判断、外部API呼び出し、結果の返却まで——すべてが一つのワークフローの中で完結する。
私はAmazon Connectをシドニーリージョンの時代から触ってきた。当時、Amazon Connectはまだ東京リージョンに対応しておらず、APAC圏で使うにはシドニーを選ぶしかなかった。シドニーで検証し、サービスとして運用を始めてから、約1年後にようやく東京リージョンに来た記憶がある。当時Twilioも並行して検討したが、AWSサービスとの統合という意味ではAmazon Connect一択だった。
その実務経験から言えることがある。
Amazon Connectの設計思想は、最初から「電話を受けて人につなぐ」ではなかった。「入力を受け取り、判断し、実行し、結果を返す」——この一連のフローを、ドラッグ＆ドロップで組み立てるものだった。
振り返ると、それはAgent Runtimeの設計そのものだった。
Amazon Connect Healthが示した進化
2026年3月、AWSはAmazon Connect Healthの一般提供を開始した。医療機関向けのAgentic AIだ。
5つのAI Agentが提供されている。
・患者認証（Patient verification）— リアルタイムでEHR照合
・予約管理（Appointment management）— 自然言語で24時間予約受付、保険適格性チェック付き
・患者インサイト（Patient insights）— 診察前に臨床コンテキストを自動整理
・環境ドキュメント（Ambient documentation）— 診察中の会話からリアルタイムでカルテ生成
・医療コーディング（Medical coding）— カルテからICD-10/CPTコードを自動生成
ここで注目すべきは、構造の変化だ。
従来のAmazon Connectは、こうだった。
ユーザー → AI（意図理解） → 人へ転送
Amazon Connect Healthは、こう変わった。
ユーザー → AI Agent → 業務実行 → 必要なら人
つまり、Agent Runtimeが「転送」で終わっていたものが、「業務の完了」まで拡張された。
患者が「来週診察したい」と電話する。AI Agentが患者を認証し、保険を確認し、医師のスケジュールを照会し、予約を登録する。このフローは、LangGraphで組むAIエージェントのフローと完全に同じ構造だ。
違うのは、実行基盤がOSSかエンタープライズかという点だけだ。
OSS Agent Runtimeとの決定的な違い
LangGraphやCrewAIは、LLMが次の行動を自律的に決定する。柔軟で拡張性が高い。一方で、行動の予測が難しく、監査が弱い。
Amazon Connectは、設計されたWorkflowで制御する。自律性は制限されるが、安定性と監査性が圧倒的に高い。
整理するとこうなる。
OSS Agent Runtime（LangGraph等）
・自律性：高い
・安定性：低い（LLMの判断に依存）
・監査性：弱い（ログはあるが再現性が低い）
・導入速度：開発が必要
Amazon Connect
・自律性：中程度（Workflowで制御）
・安定性：高い（決定論的フロー）
・監査性：強い（全通話録音、Contact Lens分析、フロー可視化）
・導入速度：数日〜数週間で本番運用可能
企業運用においては、Amazon Connect型の方が圧倒的に採用されやすい。理由は明確で、電話応対は「失敗が許されない」業務だからだ。LLMが自律的に判断した結果、患者の予約を間違えることは許されない。
ただし、ここにAmazon Connect Healthの巧みさがある。Amazon Connectは今、generative AIとdeterministic flowのハイブリッドを実現している。つまり「自律的に対話しながら、業務実行はWorkflowで制御する」という構造だ。
これは、Agent Runtimeの理想形に近い。
Amazon Connectは「音声AI」ではない
ここが本質だと考えている。
Amazon Connectを「クラウド型コールセンター」や「音声AI」として捉える人は多い。だが、構造を分解すると見えてくるのは、それがVoice Runtimeだということだ。
Voice → Intent → Workflow → Execution
この構造は、Agent Runtimeの一種にほかならない。
しかもAmazon Connectは、すでにVoiceだけではない。Chat、SMS、Email、Video、Taskの6チャネルに対応している。158ヶ国のDID番号を持ち、40以上のTier-1キャリアと直接接続している。
つまり、Amazon Connectはすでにこうなっている。
Voice / Chat / SMS / Email / Video / Task → Agent Runtime → Workflow → Business Systems
これは「電話システム」ではない。企業AIの実行基盤だ。
なぜAWSはVoiceから始めたのか
AWSがAgent Runtimeを、なぜVoiceから始めたのか。
私なりの解釈はこうだ。
Voiceは入力が明確だ。テキストと違い、音声には「今すぐ解決したい」という明確な意図がある。曖昧な検索クエリとは違う。
ユースケースが山ほどある。コールセンターは世界中のあらゆる業種に存在する。
そしてROIが出やすい。通話1件あたりのコスト削減効果が即座に計測できる。Fujitsuの事例では、5,000人以上のエージェントが450社以上の顧客を対応し、予測精度96%超、品質保証効率15%向上、顧客満足度10%向上という数字が出ている。
Agent Runtimeを「研究テーマ」ではなく「事業成果」として示すには、Voiceが最適だった。
実務で感じていたこと
私はAmazon Connectをシドニーリージョンの時代から使ってきた。東京リージョン自体は存在していたが、Amazon Connectの東京対応はそれより遅かったと記憶している。だからAPAC圏でサービス化するなら、シドニーを選ぶしかなかった時期がある。
Contact Flowを設計していて、いつも感じていたことがある。これは単なるIVR設計ではない、と。
顧客の発話を聞き、意図を理解し、条件分岐で判断し、外部APIを叩いて情報を取得し、結果を音声で返す。まさに「エージェントの行動設計」をしていた。当時はそれを「Agent Runtime」とは呼んでいなかっただけだ。
Amazon Connect Healthの登場で、この構造がようやく名前を得た。AWSは「Agentic AI」と呼んでいる。しかし構造自体は、Amazon Connectが最初から持っていたものだ。
これから何が起きるか
Amazon Connectはおそらく、こう進化していく。
全チャネル（Voice / Chat / Email / SMS / Video）からの入力を統合的に受け取り、Agent Runtimeが業務を判断・実行し、Workflowが品質と監査を担保し、Business Systemsに結果を書き込む。
Bedrock AgentCore Gatewayとの統合もすでに始まっている。つまり、Amazon Connectの内側からBedrock Agentsを呼び出すことができる。MCP（Model Context Protocol）経由でサードパーティのAIエージェントとも接続可能だ。
これは「コールセンターの進化」ではない。企業AIの実行基盤が、電話の中から立ち上がっているということだ。
まとめ
Agent Runtimeは、新しい概念ではなかった。
Amazon Connectは、最初からその構造を持っていた。入力を受け取り、意図を理解し、計画に基づいて実行し、結果を記憶する。そしてAmazon Connect Healthによって、AIが業務を「完了」させる段階に入った。
LangGraphを触ることに意味がないとは言わない。だが、企業で電話応対のAI化を考えているなら、まずAmazon Connectの構造を理解することをすすめたい。あなたが探しているAgent Runtimeは、もう電話の中にある。
関連記事
・AmazonConnectが変えた「電話」という概念——機能ではなく、事業インフラとして再設計する（note）
https://note.com/haboshi/n/nafcdbe0bb3b2
・AIエージェントは「ツール」ではない（note）
https://note.com/haboshi/n/n8b9db998df8d
・AIエージェントはどう「動く」のか——Agent Runtimeという新しい設計（Zenn）
https://zenn.dev/haboshi/articles/agent-runtime-architecture
参考ソース
[1] Amazon Connect Feature Overview — AWS公式ドキュメント
https://docs.aws.amazon.com/connect/latest/adminguide/connect-feature-overview.html
[2] Amazon Connect Features — Cloud Contact Center
https://aws.amazon.com/connect/features/
[3] Introducing Amazon Connect Health, Agentic AI Built for Healthcare — AWS What's New (2026-03-06)
https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-connect-health-agentic-ai-healthcare/
[4] LangGraph — Agent Orchestration Framework for Reliable AI Agents
https://www.langchain.com/langgraph
[5] Amazon Connect Conversational AI and Chatbots
https://aws.amazon.com/connect/conversational-ai/
[6] Flows in Amazon Connect — AWS公式ドキュメント
https://docs.aws.amazon.com/connect/latest/adminguide/connect-contact-flows.html
[7] Amazon Connect Customers — Fujitsu事例
https://aws.amazon.com/connect/customers/
[8] Amazon Connect Pricing
https://aws.amazon.com/connect/pricing/
[9] Availability of Amazon Connect features by Region
https://docs.aws.amazon.com/connect/latest/adminguide/regions.html
[10] Amazon Bedrock Agents
https://aws.amazon.com/bedrock/agents/
[11] Amazon Connect Health Product Page
https://aws.amazon.com/health/connect-health/
