LangGraphやPythonでAIエージェントを24時間死なせない4つの設計

• 事実と背景：AIエージェントの24時間連続稼働には、APIタイムアウトやLLMのパースエラーによるクラッシュが不可避である。
• 技術的変革：ハートビート、状態の外部化（チェックポイント）、冪等性を担保した自動再起動、コンテキストプルーニングを導入する。
• 現場への影響：LangGraphの永続化機能やRedisを活用し、クラッシュしても中断地点から安全に再開できる堅牢なシステムを構築できる。

デモ動画やローカル環境で完璧に動いていたAIエージェントが、本番環境にデプロイした途端、深夜2時に音もなく沈黙する。翌朝、Slackの監視チャンネルが静まり返っていることに気づき、ログを恐る恐る覗くと、LLMが返した想定外のJSONフォーマットによるパースエラーや、外部APIのわずか数秒のタイムアウト、あるいはコンテナのOOM Kill（Out of Memory）の爪痕が残されている――。これは、AIエージェントをプロダクション環境で運用しようとしたエンジニアなら、誰もが一度は通る「洗礼」である。

我々エンジニアがまず認識すべき冷酷な事実は、「エージェントは必ずクラッシュする」ということだ。ネットワークの瞬断、LLMの気まぐれな出力、レートリミットの到達など、制御不能な外部要因が多すぎる。したがって、問いは「どうすればクラッシュを防げるか」ではなく、「クラッシュした後に、いかにして素早く、かつ安全に自動復旧させるか」でなければならない。

この生存戦略の第一歩が「ハートビート（ヘルスチェック）」である。エージェント自身に、一定周期（例えば15秒おき）で「私は生きている」というタイムスタンプをRedisやファイルシステムに書き込ませる。そして、独立した監視プロセス（ウォッチドッグ）がその生存報告を監視する。もし30秒以上報告が途絶えたら、プロセスがハングアップしたか、あるいはデッドロックに陥っていると判断し、強制的に再起動をかける。このシンプルな「死の検知」こそが、24時間稼働を支える最小単位のインフラとなるのだ。

エージェントが死ぬことを前提とするならば、次に解決すべきは「死んだ瞬間に、それまでの進捗をすべて失う」という最悪のシナリオだ。Pythonのメモリ上（ローカル変数やオブジェクトのプロパティ）だけで状態を管理しているエージェントは、プロセスが再起動した瞬間に記憶喪失となり、また最初からタスクをやり直すことになる。これはAPIコストの無駄遣いであるばかりか、ユーザー体験を著しく損ねる。

解決策は、状態の「外部化（Externalization）」と「チェックポイント（Checkpointing）」の徹底である。エージェントが1ステップ実行するごとに、その時点のコンテキスト、変数、実行履歴をSQLiteやPostgreSQL、Redisなどの永続ストレージに保存する。起動時には、新規タスクの作成ではなく、まず「未完了のチェックポイント」が存在するかをスキャンし、存在すればそのステップからシームレスに処理を再開する設計にするのだ。

LangGraphを採用しているプロジェクトであれば、この仕組みはSqliteSaverやPostgresSaverといった「Checkpointer」として標準提供されているため、車輪の再発明を避けることができる。

しかし、ここでシニアエンジニアとして強く警鐘を鳴らしたいのが「副作用の重複実行」という罠だ。例えば、エージェントが「決済APIを呼び出す」というツールを実行した直後、その結果をチェックポイントに保存する前にコンテナがクラッシュしたとする。再起動したエージェントは、チェックポイントから「決済前」の状態を読み込み、再び同じ決済APIを呼び出してしまう。この「2回実行される恐怖」を防ぐためには、すべてのツール呼び出しに「冪等性（Idempotency）キー」を付与することが不可欠である。リクエストIDやステップIDのハッシュ値をキーとしてAPI側に渡し、重複実行をインフラレベルで拒否する設計を怠ってはならない。

エージェントが順調に、何日も連続して動き続けたとしても、別の静かなる死神が忍び寄る。それが「コンテキストの肥大化」だ。

エージェントが自律的に思考し、ツールを呼び出し、その結果を履歴に追加していくと、会話履歴（コンテキスト）は雪だるま式に膨れ上がっていく。これは単にトークン消費量を爆発させ、API課金で会社の財布を直撃するだけではない。LLMのコンテキストウィンドウが圧迫されることで、推論のレイテンシが秒単位から分単位へと悪化し、さらには「迷子（Lost in the Middle）」現象によって、LLMが過去の不要な情報に惑わされ、指示を無視したり、無限ループに陥ったりする原因となる。

この問題に対する処方箋が「階層的なコンテキストプルーニング（剪定）」である。直近の重要なやり取り（例えば最新の10メッセージ）はそのまま保持しつつ、それ以前の古い履歴はLLM自身に「これまでの要約」として1つのシステムメッセージに圧縮させる。

このプルーニング処理を挟むことで、エージェントに渡されるコンテキストサイズは常に一定の範囲内に収まり、動作が「決定論的（Deterministic）」に近づく。同じ要約と直近のコンテキストからは、常に予測可能で安定した次のアクションが導き出される。無限に広がるスパゲッティのような履歴をLLMに丸投げするのをやめ、エンジニアがコンテキストのライフサイクルを厳密にコントロールすることこそが、長期稼働における真のブレイクスルーなのだ。

ここまで、24時間動き続けるAIエージェントを支える「ハートビート」「チェックポイント」「冪等性」「コンテキスト管理」の4つの柱について議論してきた。これらは、単なる「動くデモ」を「本物のプロダクト」へと昇華させるための境界線である。

ここで我々エンジニアが自問すべきは、「我々はLLMの『賢さ』に甘え、ソフトウェアエンジニアリングの基本原則を忘れてはいないか？」という点だ。どれほど高度なフロンティアモデルを使おうとも、それを動かすランタイムが不安定であれば、システム全体の信頼性はゼロに等しい。

明日からあなたのプロジェクトで実践すべき具体的な処方箋を提示する。

• 第一に、現在開発中のエージェントのコードを開き、状態がメモリ上に閉じていないか確認すること。もし閉じているなら、今すぐLangGraphのMemorySaverを導入するか、自前でSQLiteへのチェックポイント保存ロジックを実装せよ。
• 第二に、エージェントが呼び出す外部APIやツールの一覧を洗い出し、それらが「2回実行されても安全か（冪等か）」を検証すること。安全でないものには、即座に一意なトランザクションIDや冪等性キーを組み込む設計変更を行うこと。
• 第三に、コンテキストの最大トークン数を監視し、一定の閾値を超えたら自動的に要約・剪定するバックグラウンド処理を組み込むこと。

AIエージェントの運用とは、LLMという「不確実性の塊」を、いかにして従来の「確実なソフトウェア」の枠組みで包み込むかという、極めて高度なエンジニアリングの戦いである。あなたのエージェントは、今夜も静かに生き延びることができるだろうか？