LangGraph（会話や処理の流れをグラフ構造で組み立てるエージェント開発フレームワーク）を使ってエージェントを開発しているチームが、本番運用の段階でAWSのBedrock AgentCore（エージェントの実行基盤となるマネージドサービス群）を検討するとき、よく起きる誤解があります。
「LangGraphとAgentCoreのどちらを選ぶべきか」という二択で考えてしまう落とし穴です。両者は競合するツールではなく、スタックの異なる層を担当しています。この誤解が設計レビューやアーキテクチャ選定の場で混乱を生むケースを整理し、確認すべきポイントを示します。
何が起きるか：責任範囲の二重化と抜け漏れ
LangGraphとAgentCoreを「どちらか一方」で考えると、本来どちらかが担うべき機能が宙に浮きます。
たとえば、エージェントの実行ループ（reason-act-observeのサイクル）を止める仕組みです。LangGraphにはrecursion_limitというパラメータがあり、デフォルトで25ステップを超えるとGraphRecursionErrorを送出して停止します。これはグラフ内部の制御フローの話です。
一方でAgentCoreのRuntimeサービスは、セッション全体の実行時間に上限を設けます。標準のmicroVM（軽量な仮想マシン）経路ではmaxLifetimeのデフォルト上限が8時間です。両者は別のレイヤーで別の理由から「止める」仕組みを持っています。
この二重構造を知らずに設計すると、LangGraph側の制限だけで安全だと思い込み、AgentCore側のセッション管理設定を見落とすことが起こり得ます。逆に、AgentCoreさえ使えばLangGraph側のループ制御は不要だと誤解するケースも考えられます。
なぜ起きるか：層の違いが名前から見えにくい
原因を分解すると、まず「エージェントを作る」という言葉が指す範囲が曖昧なことが挙げられます。
エージェントを本格的に設計するとき、実際には6つの要素を組み立てています。State（状態を保持する型付きオブジェクト）、Node（分類・計画・検証などの個別ステップ）、Edge（ステップ同士の接続）、Routing（どのEdgeを通るか決める条件分岐）、Loop（試行と観察を繰り返す制御）、Checkpoint（状態を永続化してクラッシュや人間の介入に備える仕組み）です。
LangGraphはこの6つのうち、State・Node・Edge・Routing・Loopの「考え方」そのものを担います。StateGraphやreducer（状態の更新ルール）、条件付きEdgeを使って、エージェントがどう思考するかを明示的なグラフとして書くフレームワークです。
AgentCoreはこれらを置き換えません。Runtime・Memory・Gateway・Identity・Observability・Code Interpreter・Browserといった機能を持つ、運用のためのマネージドサービス群です。2025年10月13日に主要機能が一般提供（GA）となりました。
さらに紛らわしいのは、AgentCore自体が後から機能を追加し続けている点です。PolicyとEvaluationsは2025年12月2日にプレビュー公開され、GAはPolicyが2026年3月3日、Evaluationsが2026年3月31日と別々の日程でした。Harnessというマネージドのエージェントループ機能はさらに後発で、2026年4月にプレビュー、6月にGAという経緯をたどっています。つまり「AgentCoreは2025年後半にGAした」という一言では、機能ごとの成熟度の違いを見落とします。
もう一つの誤解の原因は、AgentCoreがフレームワークに依存しない設計だという点です。LangGraphだけでなくCrewAI、LlamaIndex、Strands、OpenAI Agents SDKなどで作ったエージェントも、AgentCoreのRuntime上で動かせます。Runtimeのサービス契約はHTTP、MCP（モデルとツールを接続するプロトコル）、A2A、AGUIという形式で通信します。AWS自身の整理では「フレームワークがオーケストレーションのロジックを持ち、AgentCoreはそれが動くランタイムのインフラを持つ」という役割分担です。この関係を知らないと、AgentCore導入時に「グラフを書き直す必要があるのでは」と不要な懸念を抱くことになります。
自分のプロジェクトが該当するか確認する方法
まず、現在のLangGraphコードでrecursion_limitをどう設定しているか確認します。
# グラフ実行時の設定を確認
config = {"recursion_limit": 25} # デフォルト値
app.invoke(input_data, config=config)この値を変更していない場合、25ステップを超える複雑なエージェントではデフォルトのまま運用していないか見直す価値があります。
次に、チェックポイント（状態の永続化）をどう実装しているか確認します。LangGraphのcheckpointerをメモリ内（MemorySaverなど）で使っている場合、プロセスが落ちると状態が失われます。本番運用でAgentCoreのRuntimeやMemoryサービスに移行する予定があるなら、この永続化層の置き換えが発生する想定をしておく必要があります。
最後に、ツール呼び出しの経路を確認します。LangGraphのNode内で直接APIを呼んでいるか、それともMCP経由で外部ツールを呼ぶ設計になっているかで、AgentCoreのGateway（APIやLambda関数をMCP互換のツールに変換するサービス）への移行コストが変わります。既存のツール呼び出しコードをgrepして、直接のHTTPクライアント呼び出しが散在していないか洗い出しておくと移行計画が立てやすくなります。
対策の手順
- 責任分界点を表にする: State・Node・Edge・Routing・Loop・Checkpointの6項目について、現状どのコンポーネントが担当しているか一覧化します
- recursion_limitとmaxLifetimeを別物として管理する: LangGraph側のステップ数上限とAgentCore Runtime側の実行時間上限は独立した設定です。どちらか一方だけ見直して満足しないようにします
- AgentCoreの機能ごとのGA日付を確認する: Policy、Evaluations、Harnessは個別のリリーススケジュールを持ちます。採用を検討する機能がどのくらいの運用実績を積んでいるか、AWSの公式リリースノートで確認します
- Gateway経由のツール設計に寄せる: 直接API呼び出しをしているNodeがあれば、MCP互換のGateway経由に置き換えることで、将来的に複数エージェント間でツールを再利用しやすくなります
- Policyによるガバナンスとアプリ内Routingを混同しない: Policyはツール呼び出しをGatewayの境界で許可・拒否するガバナンスの仕組みで、エージェント内の条件分岐（Routing）とは別のレイヤーです
まとめ
LangGraphとAgentCoreを対立する選択肢として扱うと、どちらが何を担当するか曖昧なまま本番導入が進んでしまいます。
今日から確認できることとして、まず自分のコードベースでrecursion_limitの設定値と、チェックポイントの永続化方式を洗い出してみてください。
そのうえで、State・Node・Edge・Routing・Loop・Checkpointの6要素のうち、どれをLangGraphが担い、どれをAgentCoreの各サービス（Memory、Gateway、Policy、Runtime）に委ねるのか、一度チームで言語化しておくと設計レビューでの手戻りを減らせます。