プロトタイプは簡単です。 本番環境のエージェントはそうではありません。

モデルの高度化やコンテキストウィンドウの拡張だけでは、エージェントが本番環境で直面する本質的な問題であるハルシネーションを解決することはできません。ハルシネーションはモデル自体の欠陥ではなく、データ検索の失敗に起因します。どれほど高性能なモデルであっても、行動を起こすべき瞬間に最新かつ信頼できる適切なデータセットにアクセスできなければ、依然としてハルシネーションを引き起こします。

これは多くの場合、信頼性の問題に見せかけたデータの永続化の問題です。状態（単一の実行で生成されるデータ）とメモリ（エージェントが実行をまたいで保持するデータ）ではライフサイクルが異なります。両者を混同すると、「信頼性が低い」という評価につながります。処理の中断から正常にリカバリーできることは本番環境のエージェントにおける必須要件であり、メモリはスケーラブルかつ高性能に永続化される必要があります。

メモリ、ガバナンス、評価、オーケストレーションは、ワークフローエンジンに後付けされる単なる機能ではなく、それぞれ独立した製品カテゴリーです。これらすべてを社内で一から構築するには、膨大なエンジニアリングリソースの投入が必要となります。現実的なアプローチは、自社のビジネスに固有のロジックに開発を集中し、その基盤となるテクノロジーカテゴリーは実績のある製品を導入することです。

これは、セキュリティギャップとして現れる連携の問題です。共有ツールレジストリがない場合、新しいエージェントをリリースするたびに、エンジニアリング工数の重複、追加のセキュリティリスクへの露出、そして技術的負債の増加を招くことになります。解決策は、チームごとの場当たり的な個別対応を繰り返すことではなく、どのようなツールが存在し、誰がそれを所有し、何がレビューされたかを一元的に可視化することです。

適切なデータベースを選択していれば、そのような問題は起きません。エージェント型コーディングは反復的なアプローチをとるため、細かなコード変更のたびに作業を中断してマイグレーションスクリプトを作成する必要はありません。MongoDB のドキュメントモデルなら、コードの変更に合わせてスキーマを柔軟に適応させることができます。同じことがシステムスタック全体にも当てはまります。トランザクション、検索、分析、ベクトルを単一のプラットフォームで統合処理することで、エージェントやエンジニアの作業を停滞させるシステムのサイロ化や肥大化を防ぐことができます。