Claude Code開発でLangGraphへ移行する理由。本番運用のエラー監視と評価の独立性が成否を分ける

開発の70パーセントを書き直す。本番運用の壁

AIエージェントの開発で、1週間でMVPが動く。現実は非情だ。

本番運用に入った途端、エラーで止まったエージェントの「どこからやり直せばいいか分からない」という事態に直面する。

あるプロジェクトでは、この問題に対応するためにコードの70パーセントをゼロから書き直した。

移行先はLangGraphだ。

この選択は商用レベルの信頼性を確保するための道だ。

開発初期の爆速という言葉の裏には、後から修正不可能なアーキテクチャ負債が隠れている。

抽象度の高いフレームワークが本番で牙を剥く理由

AI開発シーンでは、CrewAIやAutoGen、OpenAI Swarmといったツールが使われる。

10行程度のコードで複雑なタスクをこなすエージェントが動く。

だが、その高い抽象度こそが本番運用における敵になる。

エージェントがタスクの途中でエラーを起こした際、内部の状態がブラックボックス化されているため、リトライの制御が効かない。

どこまで処理が進み、どの変数が保持されているのか。

これが見えないフレームワークは、一度失敗したら最初からやり直しという挙動を強いる。

一方で、LangGraphは学習コストが高い。

StateGraphという概念を理解し、ノードとエッジ、状態の遷移を一つずつ定義する。

最初の2週間は定義の多さに時間を要する。

しかし、この定義こそがエラー時の可観測性と制御力を生む。

どのステップで、どのモデルが、どんな出力をしたのか。

それらを全て状態として管理できるため、エラーが起きてもその一歩前から再開する制御が可能になる。

これはAPI利用料が高騰する現在の開発環境において、コスト優位性につながる。

さらに、GitHub Copilotは2026年に入り、AI creditsによる従量課金モデルへ移行した。

以前はクレジットを使い切っても低速なベースモデルにフォールバックしていたが、現在は上限に達した瞬間にアクセスが遮断される。

開発チームの予算管理が、開発の継続性に直結する。

エージェントの無駄なリトライや非効率なループは、予算を消費するリスクになる。

しんたろー：
10行で動く魔法に惹かれる気持ちは理解できる。
でも、その魔法が解けた後の動かない理由が分からない時間は厳しい。
結局、LangGraphのような泥臭い制御に行き着くのは、サービスを作っているからだ。

開発者目線で見る「制御」と「評価」の分離

Claude Codeを使ってコードを書く際、AIに自律的なタスクを任せる時は思考のブラックボックス化に注意が必要だ。

Claude CodeのようなCLIツールをプロダクトに組み込むなら、エージェントが何を根拠にその判断をしたかをログとして残し、ステップごとに検証できる設計にする。

ここでLangGraphの設計思想が機能する。

エージェントの挙動をグラフ構造として定義することで、分岐の条件やリトライの回数までもがコードとして明示される。

なぜこのパスを通ったのかという問いに、ログを追うだけで答えられる状態を作る。

これこそが開発者に求められる制御の品質だ。

また、RAGの評価についても誤解がある。

多くの開発者がfaithfulnessという指標だけを見て、回答が検索結果に基づいているから合格と判断する。

だが、ここにはgrounded-but-wrongという罠がある。

検索されたドキュメント自体に誤りがある場合、AIは間違った情報に忠実な、自信満々の誤回答を生成する。

これはfaithfulnessのスコアでは検出できない。

これを防ぐには、生成モデルとは完全に独立した評価モデルを導入する。

自分の回答を自分で採点させる自己選好バイアスを排除する。

具体的には、Gold Answerを用意し、回答を生成したモデルとは別のモデルに、客観的なcorrectnessを判定させるパイプラインを構築する。

この評価の独立性を設計の初期段階から組み込んでいないシステムは、本番環境で自信満々に嘘をつくという欠陥を抱える。

実務への影響。設計を変える3つのポイント

本番運用で詰まないためのアクションアイテムを整理する。

第一に、状態管理の外部化だ。

エージェントの各ステップにおける変数の状態を、メモリ内だけでなく、チェックポイントとして永続化できる設計にする。

LangGraphはこの機能を標準で備えている。

これにより、サーバーが再起動したり、APIがタイムアウトしたりしても、中断した箇所から再開できる。

第二に、評価パイプラインの独立だ。

RAGシステムを構築するなら、検索の精度と生成の精度を切り分けて測定する環境を作る。

リランカーを導入してP@1が上がったとしても、Recall@10が下がっていれば、生成モデルに渡される情報は貧弱になる。

どこがボトルネックなのかを数字で特定する。

第三に、コストのハードストップ設定だ。

GitHub Copilotの従量課金への移行に伴い、ユーザー予算とエンタープライズ予算を適切に組み合わせる。

特に、プロモーション期間中の消費量で将来の予算を組まない。

9月以降に標準単価に戻った際、予算不足で開発が止まる事態を避ける。

AI credits paid usageポリシーを適切に設定し、予期せぬ請求からチームを守る。

しんたろー：
開発効率を上げるためのツールで、予算管理に追われるのは本末転倒に見えるかもしれない。
でも、これがAIが当たり前になった世界の開発風景だ。
Claude Codeで爆速で書いて、LangGraphで堅牢に組む。このバランスが今の最適解だ。

FAQ

Q1: MVP開発でCrewAIを使い、後からLangGraphに移行するのはなぜ非推奨なのですか？

移行コストが、最初からLangGraphで構築する工数を上回るからです。

状態遷移の設計思想が根本的に異なります。

CrewAIはタスクベースで進行しますが、LangGraphはグラフと状態ベースで動きます。

このギャップを埋めるには、コードの大部分を書き直す必要があり、MVPで稼いだ時間が消費されます。

Q2: RAGの評価で「faithfulness」だけでは不十分な理由は何ですか？

faithfulnessは回答が検索された文脈に基づいているかを測るだけで、回答そのものが事実として正しいかを判定できないからです。

検索結果自体が間違っていた場合、AIがその間違いを忠実に再現すれば、faithfulnessのスコアは高くなります。

これを防ぐには、正解データであるGold Answerと比較するcorrectnessの評価が不可欠です。

Q3: GitHub Copilotの従量課金で、業務を止めないためのベストプラティクスは？

ユーザー予算と支出上限を適切に組み合わせ、Stop usage when budget limit is reachedを確実にオンにすることです。

また、モデルの使い分けを徹底してください。

高コストなモデルをデフォルトにせず、タスクの難易度に応じてモデルを切り替える設計にすることで、クレジットの消費を抑えられます。

まとめ

AI開発の主戦場は、動くものを作ることではなく、本番で安定して動かし続けることへ移った。

LangGraphへの移行や、独立した評価パイプラインの構築は、一見遠回りに見える。

しかし、その手間を惜しんだツケは、運用フェーズでの高額な請求と、原因不明のエラーとして返ってくる。

開発者に求められているのは、AIの魔法を信じることではなく、その魔法を制御可能な技術として手なずける規律だ。

動くデモで満足していませんか？

本番運用で詰まないためのAIシステム設計の勘所を、ThreadPostでさらに深掘りしていきましょう。

👉 ThreadPostでSNS運用を自動化する