初めてAIエージェントを構築するほぼすべてのチームに起きる瞬間がある。デモは美しく動く。エージェントは質問に答え、ツールを使い、コンテキストを覚える。ステークホルダーに見せると感銘を受ける。そして誰かが聞く：「これを本番に入れられますか？」
その質問はほとんどのチームが過小評価するギャップを明らかにする。デモエージェントは制御された環境で、開発者が見ている状態で、一度動くように構築される。本番エージェントは誰も見ていない状態で、予測不可能な条件で、何千回も動く必要がある。その2つの要件の間のギャップがほとんどのAIエージェントプロジェクトが行き詰まる場所であり——ランタイムの選択が非常に重要になり始める場所だ。
デモの罠
デモの罠は誘惑的だ。なぜならデモは本当に構築しやすいから。現代のAIフレームワークは言語モデルを接続し、いくつかのツールを与え、質問に答えさせることを簡単にする。難しい部分は動かすことではない——動き続けさせることだ。
デモエージェントは通常ステートレスだ。再起動しても何も失われない、なぜなら何も保存されていないから。認証がない、なぜならデモを動かしている開発者は信頼されているから。レート制限がない、なぜならユーザーが1人だから。モニタリングがない、なぜなら開発者が何が起きているか見られるから。エラーハンドリングがない、なぜならデモにはハッピーパスだけが重要だから。
本番はそれらの前提のすべてを剥ぎ取る。エージェントが再起動するとユーザーはコンテキストを失う。認証されていないユーザーがエンドポイントを見つける。誰かが1分間に1,000メッセージを送る。エージェントが間違った答えを出して誰も理由を知らない。AIプロバイダーがダウンしてエージェントが優雅に劣化する代わりにクラッシュする。これらの失敗モードのそれぞれは予測可能——そして正しく処理するためにそれぞれが意図的なアーキテクチャ上の決定を要求する。
この移行をうまく乗り越えるチームは、最初からAIエージェントをスクリプトではなくインフラとして扱うチームだ。
本番が実際に要求するもの
最初の要件は永続的で信頼性の高い状態だ。本番エージェントは進行中の会話、蓄積されたユーザー設定、タスクキュー、学習したコンテキストを管理する。その状態は再起動を生き残り、クラッシュを生き残り、何かがうまくいかないときに回復可能である必要がある。アトミックな書き込みが必要——エージェントのコンテキストを破損する半分書かれたメモリエントリなし。検査可能である必要がある——エージェントが予期しない動作をするとき、何を知っていてなぜその決定をしたかを見られるように。
ZeroClawはWALモードのSQLiteでこれを処理する：ACIDコンプライアント、シングルファイル、電源障害を生き残る。エージェントの状態全体が1つのファイルに保存される。バックアップは`cp memory.db memory.db.bak`だ。復元は`cp memory.db.bak memory.db`だ。管理するデータベースサーバーなし、設定する接続プールなし、セットアップするレプリケーションなし。エージェントが実際に使うアクセスパターン——何百万ではなく何千ものメモリ——に対して、SQLiteは分散データベースを上回る、なぜなら途中にネットワークラウンドトリップがないから。
第二の要件は信頼に依存しないセキュリティモデルだ。本番エージェントは本物の認証情報を扱い、本物のファイルシステムにアクセスし、弱点を探る本物のユーザーとやり取りする。セキュリティモデルは「プラグイン開発者を信頼する」や「ユーザーが行儀よくすると仮定する」ではいけない。デフォルト拒否である必要がある：すべてのツール、すべてのファイルパス、すべてのネットワークエンドポイントはエージェントがアクセスする前に明示的に許可される必要がある。監査ログはすべてのツール実行をその入力と出力と共に記録する必要がある——何かがうまくいかないとき、追跡できるトレイルがあるように。
これはまさにOpenClawのアーキテクチャが2026年に失敗した場所だ。WebSocketの信頼モデル、OSレベルのスキル権限、41.7%の脆弱なエントリを持つプラグインマーケットプレイスはバグではなかった——開発者ツールには意味があり、本物の認証情報と本物のデータを扱う本番インフラとしてデプロイされたときに負債になったアーキテクチャ上の決定だった。
第三の要件は観測可能性だ。エージェントが本番で間違った答えを出したとき、「間違ったコンテキストを使った」は有用な診断ではない。メッセージ受信からレスポンス配信までのリクエストトレーシング、会話ごとおよびユーザーごとのトークン使用量追跡、入力と出力を持つツール実行ログ、各リクエストに注入されたコンテキストを正確に示すメモリ検索ログが必要だ。これなしでは、本番問題のデバッグは推測になる——そして午前2時に何かが壊れているときの推測は高価だ。
信頼性は第四の要件で、「クラッシュしない」より微妙だ。本番は24時間365日の稼働時間の期待を意味する——クラッシュ時の自動再起動、AIプロバイダーが利用不可能なときの優雅な劣化、チャンネルの指数バックオフ付き接続リトライ、モニタリングシステム用のヘルスチェックエンドポイントを意味する。ユーザーに見える停止を作らないコールドスタートタイムも意味する。8秒で再起動するエージェントは、1年間で合計すると何時間もの停止時間になる利用不可能なウィンドウを作る。10ミリ秒で再起動するエージェントは事実上常に利用可能だ——ユーザーはギャップに気づかない。
第五の要件はコストコントロールだ。制御されていないAIエージェントは予測しにくい方法でトークンを燃やす。長い会話ができることを発見した単一のユーザーが1日で何百ドルものAPIコストを生み出せる。本番はユーザーごとおよびチャンネルごとのトークン予算、乱用を防ぐレート制限、モデルルーティング——シンプルなクエリには安いモデル、複雑なものには高いモデル——を要求する。これらのコントロールなしでは、トークンコストがサプライズになる。
ほとんどのフレームワークが間違えること
本番のために設計されていないフレームワーク全体でパターンは一貫している：ハッピーパスに全注意を払い、それ以外すべてに投資不足だ。
エラーハンドリングはコンソールにログを記録するtry-catchになる。リトライロジックは読者への演習として残される。優雅な劣化はTODOコメントだ。AIプロバイダーが429を返すとき、エージェントはバックオフ付きでリクエストをキューに入れて再試行する代わりにクラッシュする。これらはエッジケースではない——十分長く動くサービスの通常の動作条件だ。
リソース効率はコスト乗数ではなくあれば良いものとして扱われる。単一のエージェントインスタンスに1GBのRAMを使うフレームワークは高価なインフラなしにマルチテナントデプロイにスケールできない。各エンタープライズ顧客に専用のエージェントインスタンスを与えたい場合——データ分離のためにしばしば正しいアーキテクチャだ——インスタンスごとに1GBで何百ものインスタンスを同時に動かせるサーバーが必要だ。インスタンスごとに4MBなら、5ドル/月のVPSで十分だ。
セキュリティは最も一般的な後付けだ。本能は最初に機能を構築して後でセキュリティを追加することだ。しかしセキュリティは許容的なアーキテクチャに後付けできない——OpenClaw危機はこれを大規模に実証した。デフォルト拒否、メモリ安全性、サンドボックスは最初から設計に組み込む必要がある。後で追加することは許容的なアクセスを前提に構築されたものを壊すことを意味するから。
ZeroClawの本番ストーリー
ZeroClawは最初から本番のために設計され、設計上の決定はそれを反映している。シングルバイナリはデプロイが1つの12MBファイルをコピーすることを意味する——依存関係解決なし、バージョン競合なし、「自分のマシンでは動く」なし。4MBのRAMフットプリントは単一の1GB VPSで50のエージェントインスタンスを動かせることを意味し、他のどのランタイムでも専用サーバーが必要なスケールでマルチテナントデプロイを経済的に実行可能にする。10ms未満のコールドスタートは再起動がユーザーに見えず、ローリングアップデートがゼロダウンタイムを引き起こすことを意味する。
Rustのメモリ安全性はコンパイル時に脆弱性クラス全体を排除する——バッファオーバーフロー、use-after-free、データ競合はコンパイルエラーで、ランタイムのサプライズではない。デフォルト拒否のアローリストモデルはすべてのツール、ファイルパス、ネットワークエンドポイントがエージェントがアクセスする前にconfig.tomlで明示的に許可される必要があることを意味する。WALモードのSQLiteは管理するデータベースサーバーなしで単一ファイルにACIDコンプライアントな状態を提供する。distrolessのDockerイメージはZeroClawバイナリと必要な証明書のみを含む——シェルなし、パッケージマネージャーなし、最小限の攻撃面。
本番チェックリスト
AIエージェントを本番に持っていくチームにとって、チェックリストは機能よりも運用の成熟度についてだ。ローンチ前にツール権限を明示的に定義する——エージェントは何にアクセスでき、何が明示的に拒否されているか？請求書のサプライズを受ける前にユーザーごとおよびチャンネルごとのトークン予算を設定する。エラーレートとレイテンシパーセンタイルのモニタリングとアラートを設定する。メモリデータベースの自動バックアップをセットアップする。意図的に失敗シナリオをテストする：AIプロバイダーがダウンしたら何が起きるか？チャンネルが切断したら？ディスクが満杯になったら？エンドユーザーのためにエージェントの能力と制限を文書化する。エージェントの誤動作のためのインシデント対応プロセスを必要になる前に確立する。
デモと本番の間のギャップは運用の成熟度だ。選ぶフレームワークはその成熟度がどれだけ組み込まれているか対後付けされているかを決定する。最初から本番のために設計されたランタイムは構築するための基盤を提供する。デモのために設計され、本番機能で後付けされたランタイムは時間とともに複利で増えるメンテナンス負担を提供する。最初に行う選択がその後のすべてを形作る。