AIが答えられないときの設計

AI機能の設計で最も差が出るのは、うまくいったときの作りではなく、うまくいかなかったときの作りです。外部のAI APIは、応答しないことがあり、遅れることがあり、そして何より、もっともらしい間違いを返すことがあります。

これらをゼロにすることはできません。したがって設計の問いは「どうすれば失敗しないか」ではなく、「失敗したときに何が起きるか」になります。本記事では、既存のAI APIを組み込んだサービスで、失敗をどう扱うかを整理します。

失敗を二種類に分ける

まず、AI機能の失敗を混ぜて扱わないことが出発点です。性質がまったく異なる二つがあります。

通信側の失敗は、外部APIに届かない、時間内に返らない、利用上限に達して断られる、サービス側の一時的な障害といったものです。こちらは自社の入力に問題がなく、時間をおけば成功する可能性があります。

内容側の失敗は、返ってきたが空だった、指定した形式になっていない、明らかに事実と違う、質問と無関係、あるいはAIが方針上答えられないと判断した、といったものです。こちらは同じ入力を送る限り、何度試しても結果は大きく変わりません。

この二つを見分けずに「エラーが出たら再試行」とだけ作ると、直らない失敗に利用料を払い続けることになります。逆に「失敗したら諦める」とだけ作ると、一時的な通信の揺れで利用者を取りこぼします。

再試行は通信側だけ、回数と間隔を決める

再試行してよいのは通信側の失敗です。実務上の目安は次のとおりです。

• 回数の上限を置く：2〜3回で止めます。それ以上試して成功する割合は低く、費用と待ち時間だけが増えます。
• 間隔を空けて広げる：1秒後、次は3秒後、次は9秒後、というように間隔を広げます。障害中のサービスに全員が同じ速さで殺到すると、復旧を遅らせます。
• 利用上限で断られたときは長めに待つ：AI APIには単位時間あたりの呼び出し上限があります。断られた場合、すぐ再送しても再び断られます。応答に待つべき時間が示されていれば、それに従います。
• 再試行の状況を記録する：どの程度の割合で再試行が発生しているかが分かると、上限の引き上げやモデル変更を検討する材料になります。

再試行を裏側で行う仕組みは、AI処理を待たせない作り方で述べたキューと相性がよく、利用者を待たせずに数回試せます。

内容側の失敗に対しては、再試行ではなく作り直しが対処です。入力が長すぎるなら短くして送る、形式が崩れているなら形式の指定を強めてもう一度だけ送る、といった変更を伴う一回の再送に限ります。同じものを送り直すことに意味はありません。

諦める条件を先に決める

技術的に最も見落とされるのが、「いつ諦めるか」です。ここが決まっていないと、システムは延々と試み続け、利用者は待たされ続けます。

諦める条件は、次の三つの軸で決めます。

1. 時間：この処理は何秒（何分）を超えたら打ち切るか
2. 回数：何回試して駄目なら失敗として確定させるか
3. 費用：一件の処理に何回までAIを呼んでよいか

これらは技術者だけで決められません。「顧客からの問い合わせ返信の下書きなら30秒待ってもらってよい」「入力中の補助機能なら3秒で諦めて消える」というように、業務上の許容と結びついています。発注側が方針を示すべき部分です。

そして、諦めたあとに何をするかが本題になります。

諦めたあとの受け皿を用意する

AIが答えを出せなかったとき、利用者の前に何を出すか。選択肢は概ね次のとおりです。

人に引き継ぐ場合、利用者が入力した内容をそのまま持ち越すことが要点です。「担当者におつなぎします」と言われたあとで、また最初から事情を説明させられるのは、利用者から見ると機能していないのと同じです。会話の履歴、入力したフォームの内容、どこで詰まったかを担当者の画面に渡してください。

一方で、有人対応の体制がないのに引き継ぎ導線だけ作るのは避けるべきです。受け付けたまま誰も見ない窓口は、放置された問い合わせとして跳ね返ってきます。体制がないなら、AIが答えられない範囲は最初からサービスの対象外だと明示するほうが誠実です。

「分からない」と言わせる

もう一つ、失敗の設計として重要なのが、AI自身に答えを出させないという選択肢です。

既存のAI APIは、確信がなくても文章としては自然なものを返します。社内の規程にない内容を聞かれても、それらしい規程を作って答えてしまうことがあります。この誤りは、通信の失敗と違って画面上は成功に見えるため、放置されやすいのが厄介な点です。

対処は主に三つです。

• 答えてよい範囲を指示に明記する：与えた資料に書かれていない場合は「分かりません」と答える、と指示に含めます。
• 根拠を示させる：どの資料のどこを見て答えたかを出させ、根拠が示せない回答は表示しない扱いにします。
• 出力を検査する：期待した形式や範囲に収まっているかを、表示前に自社側で確認します。

三つ目についてはAIの出力をそのまま表示しないで詳しく扱います。いずれも「答えられないことを答えられないと出す」ための仕掛けであり、利用者からの信頼はここで決まります。

失敗が見えている状態を保つ

最後に運用の話です。失敗への対処を作り込んでも、どれくらい失敗しているかが見えていなければ、改善の判断ができません。

記録して定期的に見るべきなのは、失敗の件数と種類の内訳、再試行の発生割合、人への引き継ぎが発生した割合、そして打ち切りに至った件数です。これらが急に増えたときは、外部サービス側の変化か、自社の入力の変化か、利用者層の変化のいずれかが起きています。

外部AIサービスに広範な障害が起きた場合に備え、サービス上に状況を知らせる手段も決めておきます。何も表示されないまま動かないのが、利用者にとって最も負担の大きい状態です。

弊社は既存のAI APIをプロダクトや業務システムに組み込む立場で開発しており、この失敗時の設計を「あとで考える」ことにしない進め方を取っています。どこまでをAIに任せ、どこから人が引き取るかは、技術の問題である以上に事業の設計です。

AI活用開発やWebシステム開発で、この線引きから相談されたい場合はお問い合わせからご連絡ください。オンラインで、いまの体制で無理のない範囲を一緒に決めます。