AI エージェントアーキテクチャの半減期は 6 ヶ月、Inngest CTO が警告

AI エージェントのアーキテクチャは「6 ヶ月」で陳腐化する？Inngest CTO が警告する、技術的負債を防ぐ設計思想

AI エージェント開発に携わる開発者の多くが直面している現実があります。あなたが 6 ヶ月前に構築したシステムの一部が、現在もそのまま動いているでしょうか？Inngest の CTO、Dan Farrelly は、モデルやプロンプトの急速な変化により、AI エージェントのアーキテクチャには平均して「半減期が 6 ヶ月」という残酷な現実があると警告します。この課題を解決する鍵は、すべての要素を結合した設計ではなく、「実行層」を独立させ、変化するコンテキストや計算リソースから切り離すことです。

アーキテクチャの半減期：なぜ 6 ヶ月で書き換えが必要になるのか

AI エンジニアリングの世界では、技術の変化が前例のないスピードで進んでいます。新しいモデルが登場し、フレームワークがバージョンアップし、ツール呼び出しの標準が変わり、新たなパターンが生まれます。これらの変化は、開発者が意図的に設計したかどうかに関わらず、システムに大きな影響を与えます。

Dan Farrelly は、6 ヶ月前にリリースしたプロダクトを振り返ってみるよう提案します。「多くの場合、コードの一部は生き残っていますが、それは偶然でしょうか？それとも、意図的な設計によるものですか？」と問いかけます。多くのチームが直面しているのは、特定のフレームワークや事前構築されたハッチ（harness）に依存し、その抽象化レベルが高すぎて内部の仕組みが見えなくなっている状態です。この結果、オーケストレーションが深い階層に埋もれ、状態管理がサンドボックス内に混在し、リトライロジックがプロンプト処理と絡み合います。

「一度何かを交換しようとしても、ほぼすべてを書き換えなければならなくなるのが現状です。」

これが技術的負債の蓄積であり、アーキテクチャの半減期が 6 ヶ月である理由です。科学用語としての「半減期」は、物質が半分まで減少する時間を指しますが、AI エージェントの設計においても同様の現象が起きています。

• プロンプト：幸運を込めても数週間で陳腐化します。
• モデル：最良の場合でも数ヶ月で置き換わりが必要です。
• 実行ロジック：正しく設計されていれば、数年にわたって安定して機能するはずです。

しかし、多くのチームはこれらすべての層を密結合させているため、変動の速い層（プロンプトやモデル）の変化が、安定すべき層（実行ロジック）まで波及し、システム全体を書き換える必要が生じてしまいます。

3 つの概念層を分離する：脳、知識、手

特定のコンポーネントに目を奪われるのではなく、システムを構築する際の「概念的な層」を意識することが重要です。Dan Farrelly は、AI エージェントアーキテクチャを以下の 3 つの明確に分離された層として捉えるべきだと提唱します。

1. 実行層（The Execution Layer）：脳の役割

この層はシステムの「脳」として機能し、フロー、状態管理、永続性、リトライ処理を担当します。ここが設計の核心であり、長期的な安定性を担保する場所です。

2. コンテキスト層（The Context Layer）：知識の役割

モデル、プロンプト、ツール、メモリなど、システムが「知っていること」を管理する層です。これが最も頻繁に変化する部分であり、半減期が最短です。

3. 計算層（The Compute Layer）：手の役割

サンドボックス、ランタイム、ブラウザ自動化など、実際に作業を実行する「手」としての機能です。

これらの層を明確に分離し、それぞれの変動周期を個別に管理することが、技術的負債を防ぐ唯一の道です。もしこれらが結合されていれば、変動が速い層の変化が他の層を drag（引きずり）落とし、システム全体の安定性を損ないます。

実行層を安定させるための 3 つの戦略

6 ヶ月ごとの書き換えを防ぎ、長期的に維持可能なアーキテクチャを構築するためには、「実行層」をどのように設計するかが鍵となります。Dan Farrelly は、この層が備えるべき 3 つの重要な特性を指摘しています。

1. 再開可能性（Resumability）：失敗から復旧できる仕組み

AI エージェントは、以前よりも長く-running なタスクを処理することが増えています。LLM の呼び出しやツールの実行で失敗が起きることは避けられません。重要なのは、失敗したステップからやり直すのではなく、その時点から再開できることです。

「3 時間のランニング中にエラーが発生した場合、メモリやディスクに状態を保持するだけでは不十分です。状態は作業の外、つまり外部の永続ストレージに存在する必要があります。」

手動でチェックポイントを作成したり、ログベースで状態を復元しようとするアプローチは、他の層との結合を深め、システムの変更を困難にします。実行層が独立して状態を管理することで、失敗してもコストや時間を浪費せず、継続して作業を進めることが可能になります。

2. 柔軟な呼び出しパターン：多様なオーケストレーションのサポート

単一のワークフローだけでなく、cron（定期タスク）、イベントトリガー、API 呼び出し、人間を介したループ（human-in-the-loop）、サブエージェントの起動など、多様な呼び出しパターンを柔軟に組み合わせられる必要があります。

同期処理、非同期処理、遅延実行など、あらゆるシナリオに対応できる実行とオーケストレーションのプリミティブが備わっていなければなりません。これにより、システムに必要なアーキテクチャを自由に構築でき、キューやポーリング、バックオフなどの概念がハッチロジックに混入するのを防ぎます。

3. 完全な可観測性（Observability）：セッション全体を見渡す視点

デバッグと改善のためには、LLM の呼び出しやツールの実行だけでなく、データベースのエラー、権限の問題、トリガーの状況、パフォーマンスに至るまで、セッション全体のトレースを可視化できることが不可欠です。

「トリガーからスタック全体までの完全なトレースが見えない場合、デバッグは困難であり、エージェントを進化させることもできません。」

実行層が独立して設計されていれば、サンドボックス（手）の文脈やシーケンス、永続性を提供し、長期的な監視と分析を可能にします。

未来のアーキテクチャ：背景エージェントとループシステム

今後 6 ヶ月で注目されるのは、バックグラウンドエージェント、動的ワークフロー、自律的なループ、エージェントファクトリーといった新しいパターンです。これらはすべて、リクエストレスポンス型の対話ではなく、数時間から数日にわたって非同期で実行され、数百回のツール呼び出しを含む可能性があります。

例えば、「背景エージェント」は、ユーザーが待っている間に裏側で動作し、健康チェックやトリage（トリアージ）を実行します。また「ループシステム」は、定期的に状態を評価し、目標に対して何を行うべきかを判断して継続的に実行されます。これらの複雑なシステムを構築・維持するためには、3 ヶ月前のフレームワークでは対応できず、 proper な実行層の設計が不可欠です。

まとめ：設計の意図こそが未来を変える

AI エージェント開発において、技術的負債を回避し、長期的な保守性を確保するための最善策は、アーキテクチャを「脳（実行）」、「知識（コンテキスト）」、「手（計算）」という 3 つの層に分離することです。特に、変動の激しいプロンプトやモデルから独立した「実行層」を設計し、状態管理、柔軟な呼び出し、完全な可観測性を備えることで、6 ヶ月ごとの書き換えを防ぎ、変化する環境に柔軟に対応できるシステムを構築できます。

「変化を恐れるのではなく、変化を受け入れること。そして、その中で安定する層に投資し、意図的な設計を行うことが重要です。」

Dan Farrelly の警告は、単なる技術のアップデートではなく、開発者がアーキテクチャをどう捉え直すかという根本的な問いかけです。未来の AI エージェントシステムを構築する今こそ、その設計思想を見直す時です。