全員がAIエージェントを構築している。しかし、テクニカルデット（技術的負債）については誰も語っていない。
ほとんどの開発者がテクニカルデットを知っています。それは、今日取るショートカットが、明日問題を引き起こすことです。通常、この負債はコードの中に存在します。乱雑なロジックや、古くなったライブラリといった形で現れます。
AIエージェントは、これを変えてしまいます。
エージェントは新しい種類の負債を生み出します。それはコードの中にだけ存在するわけではありません。プロンプト、メモリレイヤー、そしてツール統合の中に存在します。この負債は、静かに増大していきます。
注意すべき「エージェント的負債」の4つのタイプは以下の通りです：
プロンプト負債 (Prompt Debt) シンプルな2行のプロンプトが、いつの間にか300行もの宣言文（マニフェスト）に変わってしまうことがよくあります。開発者は些細なエラーを修正するために指示を追加していきます。すると、やがて特定の単語がなぜそこにあるのか、誰も分からなくなります。もしプロンプトを変更することを恐れているなら、それはプロンプト負債を抱えている証拠です。これはコストを増大させ、システムの速度を低下させます。
コンテキスト負債 (Context Debt) チームはしばしば「データが多いほど結果も良くなる」と考えがちです。データベース全体やPDFをコンテキストウィンドウに詰め込んでしまいます。しかし、これは間違いです。大量のノイズはハルシネーション（幻覚）や高レイテンシの原因となります。賢明なシステムは、単にデータを読み込むのではなく、データをフィルタリングします。
評価負債 (Evaluation Debt) 従来のコードには明確なテストがあります。Xを入力すれば、Yが返ってくることを期待できます。しかし、エージェントは異なります。それらは確率論的です。同じ質問に対して異なる回答を返すことがあります。自動化された評価パイプラインなしでエージェントをリリースすることは、目隠しをして飛行しているようなものです。
ツール負債 (Tool Debt) エージェントに社内のあらゆるAPIへのアクセス権を与えるのは危険です。セキュリティリスクや複雑な障害を引き起こします。もしエージェントが25個のツールを持っていても、実際に使っているのが5個だけなら、残りの20個は純粋な負債です。
解決策：
- プロンプトをコードとして扱う。バージョン管理とピアレビューを活用する。
- コンテキストを精査する。単にデータを詰め込むのではなく、rerankersを使用して情報をクリーンに保つ。
- まず評価環境を構築する。新機能を追加する前に、テスト用データセットを作成する。
- 最小権限の原則を用いる。エージェントには、機能するために必要なツールだけを与える。
勝者となるチームは、単に最高のデモを作るだけではありません。安定し、メンテナンス可能なシステムを構築するチームです。
Optional learning community: https://t.me/GyaanSetuAi