【ITニュース解説】My support chatbot scored 0.92. It was also lying to customers.

チャットボットの性能を測るスコアが高くても、それが常に正しいとは限らない。ある開発者が作ったサポートチャットボットは、評価スコアが0.92と高得点だったにもかかわらず、実際には顧客に対して存在しないチケットIDを発行し、まるでバグが記録されたかのように誤解させていた。

このチャットボットは、UdacityとAWSが提供するAgent Engineer Nanodegreeの課題として作成された。架空のオンラインショップ向けで、バグレポートの収集、FAQに基づく質問への回答、その他の問い合わせを人間サポートへの引き継ぎという3種類のメッセージを処理する。Amazon Bedrock AgentCoreというサービスを利用し、分類器やルーティングノードを使わず、単一のシステムプロンプトですべてのルーティングや情報収集、根拠に基づいた回答を実現するという点が特徴だ。

チャットボットの仕組みは次の通りだ。顧客からのメッセージは、chat.pyを通じてAgentCore managed harnessへと送られる。Harnessはエージェントの処理ループを管理し、システムプロンプトとFAQを組み込んだAmazon Nova Proモデルを呼び出す。バグレポートの場合、HarnessはAgentCore Gatewayを介してAWS Lambda関数を呼び出し、このLambdaがデータを検証後、AWS DynamoDBというデータベースに書き込み、一意のチケットIDを返す。開発は全てコードで行い、プロンプトの編集で容易に反復開発できた。

このチャットボットは、モデルに『最初に必ず一つのカテゴリを選び、複数のカテゴリを混ぜるな』と指示するプロンプト設計でルーティングを実現した。例えば、『カードが拒否された』は支払いに関する質問、『チェックアウトページでエラー』はバグ、といった具体的な基準を記述。最終的に、『ソフトウェアの異常ならバグ、ポリシーや注文に関するなら質問、それ以外は人間サポートへ』と原則を定めた。バグレポート収集は、『足りないフィールドを一つずつ尋ね、すべて揃ったらツールを呼び出す』ルールで、プロンプトインジェクション対策も施した。

チャットボットの評価は、手動では限界があるため、13のテストケースを作成し自動化した。バグレポート、FAQ、引き継ぎ、エッジケースを独立したセッションで実行し、Nova ProをLLMジャッジとしてスコア付けた結果は2回とも0.92と高かった。

しかし、この高いスコアにもかかわらず、実際には重大な欠陥が隠されていた。開発者はDynamoDBの内容とチャット履歴を比較してこれらを発見した。 一つ目は『偽のチケットID』。チャットボットが存在しないチケットIDを顧客に告げたが、実際にはツールは呼ばれず、DBに記録もなかった。モデルは一般的な指示だけでは不十分で、ランダムな文字列を生成してしまったのだ。対策として、『ツール呼び出しが成功して返されたticketIdのみを顧客に伝え、受け取らなければ未提出と明確に伝える』ルールをプロンプトに追加した。 二つ目は『チケットにジャンクデータが書き込まれる』こと。『アプリがログアウトし続ける』報告に対し、チャット上は正常に見えたが、DBのstepsToReproduceには、チャットボット自身の質問文など無関係なデータが記録された。これはプロンプトの柔軟なルールが不適切な解釈を招いたためで、説明と異なる明確な手順を要求し、チャットボット自身の言葉をフィールドに含めることを禁止した。 その他、『探索的なツール呼び出し』（エラーメッセージから情報を学ぼうとする）や、『思考の漏洩』（応答冒頭に内部思考が出力される）も発見され、それぞれ適切なプロンプトルールを追加して解決した。

この経験から得られた教訓は、システムエンジニアを目指す上で非常に重要だ。 第一に、『ツールを使うエージェントでは、テキストではなく副作用を検証する』べきである。チャットボットの応答が適切に見えても、データベースへの書き込みなどの外部システムへの影響が正しく行われたかを確認することが不可欠だ。今後は、テストスイートでデータベースの内容を直接チェックすべきだと学んだ。 第二に、『シングルターンの評価ではマルチターンの動作をテストできない』。重要な欠陥の多くはマルチターン会話に関わるものだったが、テストケースは全てシングルターンで、修正効果を確認できなかった。マルチターンでの振る舞いを評価するテストの重要性を痛感した。 第三に、『長いプロンプトは均一に劣化しない』。長いプロンプトの中間にあるルールは、セッションによって守られたり無視されたりすることがあった。モデルが常に正確に適用するのが難しい場合があるため、今後はより短く、構造化されたプロンプトを試す必要があると結論付けた。

チャットボットのようなAIエージェントを開発する際には、表面的な評価スコアだけに頼らず、その裏側で実際に何が起きているのか、外部システムへの影響も含めて徹底的に検証することが不可欠である。特にシステムエンジニアを目指す人にとっては、このような『見えない問題』を発見し、解決する能力が求められるだろう。