「小さく・素早く・たくさん」プロダクト開発成功へのアプローチ
ここからはプロダクト開発に焦点をあてて、AIエージェントの技術的な不確実性に対処するアプローチについて紹介します。
「要件は変化する」ことを前提にした高速な改善サイクル
開発が進むにつれて、要件や評価基準は変化していくものです。特にAIエージェント開発においては、従来の分類や予測タスクとは異なり、初期段階では「具体的に何ができるのか」というイメージが開発者とユーザーの間で十分に共有されていないことがあります。
しかしデモを作成して実際の挙動を共有すると、ユーザーの利用イメージが一気に具体的になり、「あれもできるのではないか」「こう動いてほしい」といった要望が後から次々と出てきます。これは計画の不備ではなく、むしろ相互理解が深まりプロジェクトが正常に進んでいるポジティブなサインといえます。
技術的な観点で見ると、これらの現象は入力に対する正解の定義が変化する『概念ドリフト』、評価を通じてあるべき評価観点に気がつく『評価指標ドリフト』、入力データの分布が変化する『データドリフト』として観測されます。
最近ではコーディングエージェントをはじめとする開発ツールの発展により、ユーザーが新しいインターフェースに触れるまでの期間が大幅に短縮され、ユーザーからのフィードバックや要求変更の頻度も高まっています。
こうしたドリフトに対処する方針の一つが「高速に改善サイクルを回す」ことです。特に運用時に発生した追加要求やエラーは暫定対応と恒久対応で分けて対処し、暫定対応については素早くフィードバックを受け取り、即座にステージング環境にデプロイできるような CI/CDを整備します。
トレーサビリティの確保と回帰テストの整備
1ページ目で解説した問題の「モグラ叩き（ある修正が別の不具合を生む現象）」を防ぐためには、変更を加えるたびに過去のテストケースも含めて再評価を行う回帰テストの仕組みが不可欠です。
変化する環境下で、持続的に運用と改善のサイクルを回していくための基盤となるのがトレーサビリティの確保です。
AIエージェントを運用するといくつか課題が浮き彫りになります。性能改善のための「プロンプト修正」やモデル廃止・更新に伴う「モデル変更」が頻繁に発生します。また思考や行動の連鎖によって推論過程が複雑になればなるほど、発生したエラーを再現することも難しくなります。
入出力データの記録に加えて、トレース日時をモデル・外部ツール・コンテキストのバージョンと紐付けたり、トークン数やコスト情報などのメタデータをセットでトレースしておくと原因の切り分けがしやすくなります。
プロンプトエンジニアリングの本質は「地道なルール作り」
実業務で使えるAIエージェントを作る場合、その本質は「AIエージェントの行動を制限する地道なルールづくり」にあると考えられます。運用を重ねて性能が安定してくると、（創造的なタスクを除き）プロンプトは詳細なものになっていきます。
最近では高性能なLLMが多く公開されており、一般常識や専門知識といったコンテキストに依存しない推論は得意になりつつあります。一方で、定められた厳密な推論過程の遵守や、現場特有の判断基準に基づく境界値の判定、といったコンテキストに依存する推論は、開発者がそのコンテキストを詳細に指示しない限り、期待通りの結果を得ることは困難です。
品質管理のフレームワークである『狩野モデル』を引用すると、一定上手くいきそうという所感を生みやすいAIエージェントは、提案段階での「一元品質・魅力的品質」の創出に紐付きやすい一方で、失敗時のリスクが大きなルールをミスなく守り続けるといった検証・運用段階での「当たり前品質」の担保に苦労することが多いとも解釈できるかもしれません。これは苦労する要因が現場特有の判断基準を反映できていないことにあることが多いためです。
このギャップを埋めるには、重要なコンテキストとなる現場業務の暗黙知を、人間が詳細な仕様として形式知化することです。ここではその形式知化のタイミングで特に押さえておきたいポイントを以下に紹介します。
タスク説明と制約条件
- 記述内容が適切であるかどうか、ドメインエキスパートやクライアントと合意する
- 制約条件は漸進的に更新されることが多いため、地道にルールづくりをする
- 設計段階で要件が全て揃うことはないため、テスト結果や運用時の監視に基づいて改修することを前提とする
行動条件と推論手順の厳密な定義
- 終了条件や推論手順、遷移条件は注意深く定義する（AIが推論を強制終了・スキップしたり、「次のエージェントを呼び出します」といった発話が画面表示されるのを防ぐ）
- どのような条件下でどの行動を取るか、またどのような順序で推論を進めるべきかを明示する
- 条件分岐や終了条件については、複数の解釈がなされないよう明記する（特に格助詞や指示語の使い方に注意する）
ただし、全ての暗黙知を人間が言語化して管理しようとすると、かつてのナレッジエンジニアリングのように維持コストが破綻しかねません。したがって、絶対的な禁止事項のみを明示的なルールとし、言語化が難しい複雑な判断は過去の成功事例を動的に参照させる「事例ベースの制御」に委ねるのが現実解です。
コンテキストエンジニアリングとは？ AIに渡す情報の選別方法
一般にコンテキストのトークン数が多くなると、指示文の一部を無視したり、意図しない文章を生成したりすることがあります。そこでタスクの実行に必要最小限かつ重要な情報だけを選別してLLMに渡す『コンテキストエンジニアリング』という考え方が重要視されています。
具体的な解説についてはAnthropicの記事を参照していただきたいのですが、現場で使えるAIエージェント開発のために押さえておきたいポイントをいくつか紹介します。
メモリ管理とチャンクの再構成戦略
- 記憶の選択と更新：参照対象の情報間にコンフリクトが生じた場合、どの情報を正とするかの判断が難しくなります。単なる記憶の検索だけでなく、メタデータによるフィルタリングや、記憶の登録時に古い情報を明示的に更新・削除する仕組みが必要です。
- 検索用データと参照用データの分離：一般的なRAGの多くは、文書をチャンク分割して検索対象としますが、この方法だとチャンク外の文脈が失われてしまいます。そのため「AIが検索の対象とする情報」と「AIが応答の対象とする情報」は切り分けて管理すると良いです。
- 多様な観点での要約戦略：検索精度を高めるためには、検索対象に意味のまとまりを持たせることが重要です。Amazon Bedrock AgentsのMemory機能がメモリの種類として「意味記憶」「ユーザー嗜好記憶」「要約」など、複数の観点でタッチポイントを持つように、さまざまな観点から要約した文章を検索対象とすることで、ヒット率の向上が期待できます。
- コンテキストの再構成：応答時には、単に検索されたチャンクを渡すだけでなく、メタデータとして保持しておいたチャンク間の関係性を用いてコンテキストを再構築することで、チャンク分割によって失われる情報を考慮できます。
「制御ロジック」はLLMの外で管理する
AIエージェントを設計する際、完了条件や分岐の判断といった「制御ロジック」までLLMに委ねてしまうのはリスクがあります。LLMは必ずしも決定論的に動作するわけではないため、勝手にタスクを中断されたり、なぜその判断をしたのかユーザーが説明できないブラックボックス問題が発生してしまいます。
これを防ぐためには「制御ロジックはLLMの外でもつ」ことが有効です。LLMには最終判断に必要な根拠のみを生成させ、その情報が条件を満たしているかどうかの最終判定は、if文などの条件式で管理します。
例えば、タスク指向対話におけるスロットフィリングであれば、ヒアリング項目を外部メモリのステートとして管理し、終了条件は「全てのステートが埋まったかどうか」でプログラム側で判定します。あるいはリッカート尺度のような定量評価の場合でも、評価観点ごとの採点をLLMがおこない、総合点の算出や合否判定ロジックをプログラム側で判定します。
これにより行動決定の制御が容易になり、また評価対象が「根拠+判断」から「根拠」のみに限定されます。さらに「最終判断」が決定論的に算出されるため、根拠の抽出性能が一定担保されることで、ユーザーに対しても「なぜその結果になったか」を説明しやすくなります。
