ブログ一覧

AIエージェント基盤の選び方：Vertex AI・Bedrock AgentCore・LangGraphの役割を理解する

2026年10月29日 · 約18分で読めます

業務向けAIエージェントを初めて設計する人へ。AIが依頼を受けて外部の処理を呼び出す流れから、処理の組み立て方・実行環境・保存先の違いを整理し、Vertex AI系の基盤、Bedrock AgentCore、LangGraphの役割を説明します。発注業務を例に構成を選び、承認待ちと再開まで設計します。

本文の点線の語を押すと、説明が開きます。

この記事の目的と前提知識

目的： モデル、処理の制御、実行環境、保存先、業務APIの役割を理解し、どの処理を自分で実装し、どこを基盤へ任せるか判断できるようになります。

前提知識： Web APIで別の処理を呼び出し、データベースに情報を保存する基本を知っている方を想定します。AIエージェントの動作と各基盤の役割は、最初から説明します。

扱う範囲： 人の承認を待って発注する業務を例に、Vertex AI系の基盤、Bedrock AgentCore、LangGraphを構成図へ結び付けます。承認待ちからの再開、重複発注の防止、権限の確認まで扱います。

AIエージェントの基本動作とツール

ここでは、依頼に応じてツールを選び、結果を見ながら処理を進めるエージェントを扱います。モデルは入力された文章やデータから回答を生成し、ツール呼び出しに対応するモデルなら、必要なツール名と引数を出力できます。ツールは在庫照会のような処理を呼び出すために定義した関数やAPIです。モデルへ渡す定義にはその用途と入力項目を記述します。

たとえば「商品Aを10個、金曜までに届けたい」という依頼に、モデルが在庫照会を選んだとします。モデルの出力を受けたアプリが入力と権限を確認し、在庫APIを呼びます。結果をモデルへ返すと、配送日を調べるか、条件に合わないと回答するかなど、次の処理を決められます。モデルがツール名を出力しただけでは、データベースの参照や注文は実行されません。管理されたサービスにツール実行を任せる構成もあります。

すべての手順をモデルに選ばせる必要はありません。在庫と配送日の照会順序が決まっていればコードで制御し、依頼の解釈や発注案の説明をモデルへ任せられます。処理の繰り返しには回数・時間・費用の上限と、失敗時に保留する条件を設けます。これらをどの部品で制御するかが、基盤を選ぶときの論点です。

エージェントを構成する役割

「Vertex AI、Bedrock、LangGraphのどれを使うか」という問いには、モデルの提供元、処理の作り方、配置先という別々の選択が含まれます。まず、エージェントの動作に必要な役割を分けます。一つの製品が複数の役割を担う場合もあります。

これらに加えて、注文や承認の現在状態を管理する業務APIとDBが必要です。会話履歴に「承認した」と残っていても、それだけでは現在の発注案に対する承認とは判断できません。また、実行環境が動いていることと、停止後に状態を復元できることは別の性質です。保存する内容と復元方法を設計します。

Google CloudのVertex AI系の基盤とADK

Vertex AIのエージェント基盤を調べると、現在の公式資料ではGemini Enterprise Agent Platformという名称が出てきます。Agent Engineの現在の名称はAgent Runtimeです。旧名称と新名称を別製品として比較せず、どの機能を指す資料かを確認します。ここでは、コードで業務の制御を作るADKと、そのコードを配置するAgent Runtimeを中心に見ます。

GoogleのADK（Agent Development Kit）は、エージェント、ツール、処理のつながりをコードで組み立てるフレームワークです。Agent Runtimeはその実装を配置・実行する管理された環境で、ADK以外のフレームワークを使う構成もあります。つまり、ADKを選ぶことと、どこへ配置するかを決めることは別の判断です。

保存機能にも役割の違いがあります。Google Cloud Sessionsは一つの会話で交わした履歴を扱い、Memory Bankは複数の会話をまたいで利用者に関する情報を扱います。「会話を覚えている」「処理を再開できる」「注文の現在状態が分かる」は同じではありません。独自の承認待ちを実装するなら、その再開に必要な値がどこへ保存されるかを別途確認します。

AWSのBedrockとAgentCore

Amazon Bedrockにはモデルを呼び出すAPIがあります。一方、Bedrock AgentCoreは、エージェントの実行やツール接続などを支えるサービス群です。モデルAPIを呼べるようにしただけでは、業務アプリの配置先、承認待ちの保存先、注文APIへの権限までは決まりません。

AgentCore Runtimeは実行環境を提供し、AgentCore Memoryは会話や長期的な情報を保存します。Gatewayは既存APIなどをツールとして接続し、Identityは認証情報やサービスへのアクセスを扱います。これらは必要な機能を組み合わせて利用できます。Gatewayに接続したことだけを根拠に、利用者がすべての注文を操作できるようにはしません。

処理の制御にはLangGraphやADKなどを組み合わせる構成も、管理されたエージェントループを使うAgentCore Harnessもあります。自分でグラフを実装するか、ループをサービスに任せるかで、アプリ側に書く処理が変わります。ここからの設計例はフレームワークで制御を実装する構成を扱います。

LangGraphのグラフと状態

LangGraphは、処理のつながりをグラフで定義するフレームワークです。ノードはモデル呼び出しや入力検証などの処理、エッジは次にどのノードへ進むかという接続、状態（state）は各処理が参照・更新するデータです。たとえば、依頼内容、照会結果、発注案のバージョンを状態として持ち、承認が必要かどうかで進み先を変えます。すべてのノードがモデルを呼ぶ必要はありません。

承認待ちで止め、後から再開するには、グラフの状態を保存する仕組みも必要です。後半で説明するCheckpointerがその役割を担います。LangGraphの制御を選んでも、モデルの提供元や配置先は別に選べます。Google CloudのAgent RuntimeやAWSのAgentCore Runtimeと組み合わせる構成も候補になるため、クラウドの実行基盤とLangGraphを同列の代替品として比べる必要はありません。

承認を待って発注する購買業務の設計例

架空の社内購買業務を考えます。担当者が依頼した商品について在庫と配送日を照会し、エージェントが発注案を作ります。承認者が翌日に内容を確認することもあります。承認後は既存の注文APIへ送信し、注文が受け付けられたことを確認して完了にします。発注案ができただけでは業務は完了しません。

構成の一例は、BedrockのモデルAPI、LangGraphの制御、AgentCore Runtimeの実行環境、永続的なCheckpointer、既存の注文・承認DB、Gateway経由の業務APIです。Google Cloudを使うなら、ADKまたはLangGraphをAgent Runtimeへ配置する構成を検討できます。以下のADKとLangGraphの説明は、同じ業務要件をそれぞれで考える例であり、両方の導入を求めるものではありません。

この例では、処理を進めてよい条件を先に決めます。在庫や配送日が未確定なら保留し、案が変わったら承認を取り直し、注文の結果が不明なら照会します。以降のJSON、図、疑似コード、試験項目は独自の設計例で、製品の設定ファイルや導入効果の実測ではありません。

ADKの並列処理とJoinNodeでの合流

ADK 2.xのグラフなら、独立した在庫照会と配送日照会へ分岐し、JoinNodeという合流用のノードで結果をまとめる構成を考えられます。公式資料では、合流へ入る前段のノードに出力が必要とされています。前段の処理が終わることと、発注に必要な値が有効であることは分けて扱います。

配送日を取得できなかった結果を空欄の正常データに変えると、後段のモデルが「最短で届く」と補ってしまうかもしれません。取得できなかったことを状態として残し、発注案を作ってよいかはコードで検証します。一方の結果を他方の入力に必要とするなら、その2処理は同時に開始する対象から外します。

会話・実行状態・注文の保存先

LangGraphで同じ流れを実装する場合、Checkpointerはスレッドごとのグラフ状態をチェックポイントとして保存します。スレッドは一連の実行と保存状態を識別する単位です。Storeはスレッドをまたぐアプリの情報を扱います。たとえば承認待ちから処理を再開するための状態と、説明の好みのような情報は保存範囲が違います。注文が受け付けられたかは、注文APIや業務DBの現在状態で判断します。

本番の実行環境を自分たちで運用する場合、InMemorySaverだけを使うと、プロセスが失われた後の復元には使えません。永続的な保存実装を用意します。Agent Serverのように保存を管理するサービスを使う場合は、その機能がどこまでを管理するか確認します。クラウドの会話履歴やメモリ機能を使う場合も、グラフの再開に必要な情報まで保存・復元する連携なのかを確かめます。

AgentCoreのセッションと状態の復元

AgentCore RuntimeのmicroVM（軽量な仮想マシン）はセッションごとの実行環境を分離します。しかし、既定の計算環境のメモリとディスクは一時的です。停止後に同じruntimeSessionIdで呼び出しても、新しい計算環境で動く場合があります。設定したセッションストレージでファイルを残せても、プロセスの変数まで自動で復元されるわけではありません。この説明を、保存方式の異なるRuntime Instancesへそのまま広げないようにします。

これらは同じ値にそろえるためのIDではありません。バックエンドが対応を管理し、利用者から渡されたIDを信用して別案件の状態を読み出さないようにします。AWSも、AgentCoreがセッションと利用者の対応を強制しないため、アプリ側で関係を管理すると説明しています。

{
  "tenant_id": "tenant-A",
  "case_id": "case-42",
  "thread_id": "thread-case-42",
  "runtimeSessionId": "a88003d1-7216-48ef-91bc-aee70370b77f",
  "proposal_revision": 3,
  "approval_status": "pending",
  "operation_id": "order-case-42-rev-3",
  "order_status": "not_submitted"
}

翌日に新しい計算環境で動くなら、保存先からスレッドの状態を読み、業務DBで発注案のバージョンと承認の有効性を確かめます。古い会話に「承認した」と書かれていても、発注案が更新されていれば現在の案の承認として使いません。

LangGraphの承認待ちと再開時の再実行

LangGraphでは、interrupt関数で処理を止めて入力を待ちます。再開するときは、同じ処理を識別するthread_idを指定し、Commandにresume（再開用の入力値）を渡します。このとき、interruptを呼んだノードは先頭から実行されます。停止した行の次から、Pythonプロセスの続きをそのまま動かす方式ではありません。

def approval_node(state):
    notify_reviewer(state["case_id"])
    decision = interrupt(state["proposal"])
    return {"decision": decision}

この形では、承認者への通知が再送され得ます。通知を同じ通知IDで繰り返しても1回の結果になる処理にするか、通知と承認待ちを別のノードへ分けます。ノードを分けたことだけで通知先の処理と保存が一体になるわけではないため、通知の再送にも重複対策は必要です。

def approval_node(state):
    decision = interrupt({
        "case_id": state["case_id"],
        "proposal_revision": state["proposal_revision"],
        "proposal": state["proposal"],
    })
    return {"decision": decision}

後続の処理は、decision（再開時に受け取った判断）の文字列や、承認を表す真偽値だけを信じて発注しません。認証した承認者、案件、対象の発注案のバージョン、期限、現在の権限を業務の承認記録と照合します。承認が有効なら操作へ進み、案が変わっていれば改めて確認します。待機中のノードを変更する場合も、保存済み状態とinterruptの並びに互換性があるかを確かめます。

注文APIの応答を失ったときの結果照会

承認後の操作を別ノードへ移しても、外部APIが注文を受け付けた直後にプロセスが停止すれば、グラフ側へ結果を保存できない場合があります。チェックポイントには「送信前」と残り、注文先には注文が存在するというずれです。ノードを再実行するだけでは、このずれは解決しません。

アプリは発注する意図と操作IDを先に記録し、同じ操作の重複受付を条件付き更新などで管理します。ただし、その記録の保存と外部APIでの注文受付を、まとめて成功・取り消しできるわけではありません。注文APIが冪等性キーと結果照会に対応しているなら、その仕様と保持期間の中で同じ操作IDを使います。

注文APIに重複防止や照会の機能がなければ、結果不明のまま新しい操作IDで再発注する設計は避けます。この業務では保留して担当者へ渡し、注文先の記録と突き合わせます。どのフレームワークを使っても、外部サービスが提供しない保証をチェックポイントから作り出すことはできません。

AgentCore Gatewayの認証と業務APIの認可

AgentCore Gatewayを通してツールへ接続する場合、入口側（inbound）ではGatewayへ入る要求を確認し、出口側（outbound）では接続先への認証を扱います。対応する接続ではGatewayのサービスロール、呼び出し元のAWSの認証情報（IAM）、OAuthなどを選べますが、接続先によって使える方式が異なります。inboundで認証した利用者の権限が、すべてのoutbound方式でそのまま伝わるとは考えません。

特にAUTHENTICATE_ONLYは、署名を検証してもGateway自身で認可判断をしない方式です。認可を別の構成要素へ委ねるなら、その構成要素で検証する必要があります。共有接続を使うこの発注例では、信頼できる呼び出し元の情報を業務APIまで結び付け、別顧客の商品や注文を更新しないようにします。

停止と再開を含む導入前の検証

次の表はこの発注業務の試験計画です。文章が自然かを確認する評価とは別に、保存状態と業務結果を照合します。これは実製品で実行済みの試験結果ではありません。

少なくとも、どの案件を再開したか、どの発注案が承認されたか、どの権限で何を実行したか、注文先でどう受け付けられたかを追えるようにします。会話の回答だけを見て「復旧できた」と判断せず、結果不明の案件と、人が処理する残件も確認します。

構成図に残す判断

1. まず業務の完了条件と保留条件を決める。発注案のバージョン、承認、操作ID、受付結果のどれをどこに保存するかを明記する。
2. 次に制御を選ぶ。依存関係が決まる処理はグラフにし、独立した照会だけを並列化する。LangGraphを使うならCheckpointerとStoreの範囲、中断・再開の単位を決める。ADKを使うなら対象バージョンの合流と出力の扱いを確認する。
3. その実装を動かす基盤と接続方法を選ぶ。Agent RuntimeやAgentCoreの対応バージョン、保存先へ接続できること、計算環境の停止、認証・認可を、同じ案件の試験で確かめる。

自分の構成図には、各役割の製品名に加え、保存する情報、権限を検証する場所、停止後の復元方法を追記します。たとえば「LangGraphをAgentCore Runtimeで動かす」という選定は、処理の制御と配置先を決めた段階です。永続的なCheckpointer、承認記録、注文APIの重複対策まで具体化して、発注業務としての構成が決まります。

一次資料と確認範囲

製品の挙動は以下の公式資料で確認しました。2026年10月29日時点の説明で、提供地域・開発用の部品・連携先などの対応条件は採用時に再確認してください。この記事の発注処理、復旧手順、疑似コードと試験計画は設計を説明するための例で、クラウドへの配置、実モデルの品質・費用、障害復旧の実測は行っていません。

• Google Cloud — Agents overview: ADK, Agent Runtime, Sessions, and Memory Bank
• AWS — Tool use with Amazon Bedrock models
• LangGraph — Overview
• Google Cloud — Agent Runtime framework quickstart
• Google Cloud — Agent Platform release notes
• Google ADK — Graph routes and JoinNode
• AWS — Amazon Bedrock AgentCore overview
• AWS — Bedrock Agents Classic maintenance mode
• AWS — AgentCore Runtime sessions
• AWS — Gateway inbound authorization
• AWS — Gateway outbound authorization
• LangGraph — Persistence: Checkpointer and Store
• LangGraph — Checkpointers
• LangGraph — Interrupts and node replay