【ITニュース解説】Your library isn't in the training data: making AI agents use it well

AIは大量のデータで学習しているため、一般的なコード（ReactコンポーネントやJestテストなど）は得意である。しかし、もしAIに自社の内部APIクライアント、特定のデザインシステム、あまり知られていないオープンソースライブラリ、あるいは大幅な変更があった新しいバージョンのライブラリを使わせようとすると、問題が発生する。AIは知らないものに対して「何もしない」のではなく、自分が知っている最も近い情報で穴を埋めようとする。そのため、一見すると正しいが、実は細かい部分で誤ったコードを自信満々に生成してしまう。例えば、似たようなライブラリのオプション名を使ったり、人気のある代替ライブラリからインポートしたり、間違った戻り値の形式を想定したりする。これは、AIが自信を持って誤った情報を生成する状態と言える。

AIエージェントに自社独自のライブラリやAPIを正しく使わせるためには、モデルに正確な知識を与えることが不可欠である。その際、単なる「こうしてはいけない」という警告の羅列ではなく、具体的な「どうすれば良いか」という情報を提供することが重要だ。具体的には、関数の引数やオプション名まで完全に記述されたシグネチャ、特に人気ライブラリと異なる場合の戻り値の形、コードを書く上での順序やファイル構成といったパターン、そして何よりも完全に動作する具体的なコード例が効果的である。モデルにとっては、一つでも動く例がある方が、長文の説明を読むよりもはるかに学習しやすい。

AIエージェントとの対話には、送受信する情報量に応じて内部処理コストがかかる。そのため、すべての関連情報を常にモデルに渡すのは非効率的である。この問題を解決するには、提供する情報を層に分ける戦略が有効だ。多くのタスクで必要となる基本的な情報だけを「コア」として用意し、残りの詳細な情報は別のファイルにまとめておく。そして、モデルが必要と判断した場合にのみ、その詳細な情報を読み込ませるようにする。これにより、モデルに与える情報量を最適化し、AIエージェントの運用効率を保ちつつ、必要な時には十分な情報を提供できる。

型付けされたAPIを使用することは、AIエージェントにとって非常に強力な教師役となる。AIエージェントが架空のオプション名を考案したり、引数を間違った順序で渡したりした場合でも、型チェックを走らせれば、すぐにコンパイルエラーとして検出できる。これにより、実行時になって初めてバグが見つかるという事態を防ぎ、開発の初期段階で間違いを修正できる。そのため、独自のAPIは厳密に型付けし、オプション名のスペルミスが許容されるような曖昧な設計は避けるべきだ。AIエージェントには、コードを実行する前に必ず型チェックを行うよう指示することで、最も安価で効率的なチェックを組み込むことができる。

型システムだけでは検出できない種類の間違いも存在する。例えば、awaitの記述忘れ、意図しない人気ライブラリからのインポート、デバッグ用のコード残骸（.onlyなど）、あるいは常に未定義となるプロパティへのアクセスといった、文法的には正しくても論理的に誤っているコードがそれだ。このような「有効だが間違ったコード」を特定し、修正するために、専用のリンターが有効である。理想的なリンターは、設定不要で簡単に実行でき、安全なケースでは自動修正機能を提供し、そして何よりもエラーメッセージが具体的で、問題の原因と修正方法を明確に指示する。これにより、AIエージェントも人間も、次に何をすべきかを正確に理解できる。

AIエージェントは、人間と同じようにコンソールログを読み取るが、チェックマークを数えたり、行数を数えたりする際に誤認識することがある。これからは、CLIツールなどの出力は人間だけでなく、プログラム（AIエージェントも含む）も読み手であることを意識して設計する必要がある。具体的には、きれいな出力の隣に、機械が解析しやすいJSON形式のレポートを提供すると良い。このレポートには、実行結果、各失敗の詳細なエラーメッセージ、そして人間が確認したい診断情報を含める。また、コマンドには--format jsonのようなオプションを提供し、ツールが問題点を報告する際の出口コード（終了コード）にも意味を持たせる（例：成功、問題あり、何もしなかったなど）。

AIエージェントへの指示やルールは、コードと同じように時間の経過とともに劣化する可能性がある。善意で行われた変更が、エージェントが頼りにしていた重要なルールをひっそりと削除してしまい、誰も気づかないという事態も起こり得る。これを防ぐためには、「Evals（評価）」、つまりエージェントのテストを実施することが不可欠だ。これは、小さなプロジェクトを用意し、エージェントにタスクを与え、その生成物を採点するというものだ。評価には、生成されたファイルの内容に対する正規表現マッチや、特定ツールの呼び出しの有無など、確定的で常に同じ結果を出すグレーダーを優先的に使う。また、意図的にエラーを仕込んだファイルから始めさせ、エージェントがそれを修正できるかを確認するようなテストケースも有効だ。Evalsはコストがかかるため、頻繁に実行するのではなく、リリース前や指示変更後に実行するなど、計画的に運用することが重要である。

AIエージェントに対する指示が、実際のライブラリの最新の状態と乖離していく「ドリフト」は、最も静かで気づきにくい失敗の一つである。AIエージェントは指示を忠実に実行するため、指示が間違っていれば、間違ったコードを生成してしまう。この問題を避けるためには、二つの習慣が役立つ。一つは、指示にバージョン固有の注釈（例：「バージョン1.8で修正」「1.9以降が必要」など）を含めないことだ。モデルはどのバージョンを使っているかを知らないため、現在の振る舞いを直接記述するべきである。もう一つは、指示に含まれる主張を記憶ではなく、常にソースコードと照合して確認することだ。特に、あるルールの背後にある理由が本当に正しいかを定期的に検証する必要がある。

AIエージェントがまだあなたのライブラリ、SDK、またはデザインシステムについて十分な知識を持っていない場合、以下の点が重要になる。まず、完全なコード例を含め、情報を層に分けて一度にAPIの知識を徹底的に教え込む。次に、APIを厳密に型付けし、エージェントにコンパイラを実行させて間違いを早期に検出させる。そして、型チェックでは見つけられない問題をリンターで検出し、設定不要で自動修正機能があり、分かりやすいメッセージを提供するものを使う。また、エージェントが情報を正確に読み取れるよう、JSON形式のレポートと意味のある終了コードを提供する。さらに、指示の品質を維持するために、主に確実な評価基準を持つEvalsを作成し、リリース前などに実行する。最後に、指示の内容を常に最新のソースコードと照合し、正確さを維持すること。モデルがあなたのライブラリをよく知るようになる日まで、ライブラリ側がモデルの知識不足を補う努力が必要だ。