AIの出力をそのまま表示しない

AI機能で最も起きやすい実装上の判断ミスは、返ってきた文章をそのまま画面に流してしまうことです。試作の段階ではうまく動いて見えますが、本番では形式が崩れた出力が届き、意図しない記述が混ざり、断定された誤りが利用者に伝わります。

原則は一つです。AIの出力は、外部から来た未検証のデータとして扱う。自社が呼び出したAPIの応答であっても、その中身は利用者の入力や外部の文書に影響されて生成されたものです。入力の検査についてはAIに渡す前の入力チェックで扱いました。本記事はその反対側、出口の設計です。

形式を決めて出させ、検証する

自由な文章として返させると、扱いが難しくなります。機械的に処理する用途であれば、出力の形式を先に決めて指定するのが基本です。

多くのAI APIには、決まった構造で返させる機能があります。項目名と型を指定しておけば、応答がその形に沿う可能性が高まります。「分類結果」「確信度」「理由」といった項目を定義しておけば、受け取る側は素直に処理できます。

ただし、指定したからといって必ずその形で返るわけではありません。受け取った側でも必ず検証します。

• 必要な項目がすべて存在するか
• 値が想定した範囲・選択肢に収まっているか
• 数値であるべき箇所が数値か
• 文字数が想定の範囲か

検証に失敗したときの対処は、AIが答えられないときの設計で述べた「内容側の失敗」にあたります。同じ入力で再送しても直りにくいため、形式の指示を強めて一度だけ試し、それでも駄目なら失敗として扱う、という流れが実務的です。崩れた出力をなんとか読み取って使おうとする処理は書かないでください。そこが不具合の温床になります。

表示前に無害化する

文章として画面に出す場合、そのまま画面へ流し込むのは危険です。

AIの出力には、利用者の入力や読み込ませた文書の内容が反映されます。そこに画面を操作するための記述が含まれていた場合、そのまま表示すると実行されてしまう恐れがあります。他人の入力が自分の画面で動く、という状態は、そのまま情報漏えいにつながります。

対処としては、次を守ります。

• 文字として表示する：出力を画面の構造として解釈させず、文字列として表示します。多くの開発フレームワークは既定でそうなっていますが、AIの出力を見出しや太字付きで表示したいという要望から、あえて解釈させる実装に変えてしまうことがあります。ここが危険です。
• 書式を使いたい場合は許可する範囲を限る：見出し、箇条書き、強調など、表示に必要な種類だけを通し、それ以外は落とします。
• リンクを信用しない：AIが出力したURLは実在しないことも、意図しない先を指すこともあります。外部リンクとして機能させる場合は、行き先を確認するか、リンクにせず文字として出します。
• 出力で処理を起こさない：AIの応答内容をもとに、メール送信、データの削除、決済といった処理を自動で実行しない。実行が必要な場合は人の確認を挟みます。

誤りが許されない箇所を洗い出す

無害化が済んでも、内容が正しいかは別の問題です。AIは、確信がなくても自然な文章を返します。存在しない条文、実在しない製品仕様、計算の合わない金額が、まったく同じ文体で出てきます。

ここで有効なのは、機能全体を「正確か不正確か」で論じるのをやめ、出力の中で誤りが許されない箇所を特定することです。

三行目が実務上の要点です。数値や固有名詞をAIに書かせないという設計判断は、驚くほど多くの問題を消します。文章の骨格はAIに作らせ、金額や日付や顧客名は自社のデータベースから差し込む。この分担であれば、文章の自然さを得ながら、事実の正確さは自社側で担保できます。

根拠を示す

社内文書やFAQを参照して答える機能では、回答と一緒にどこを見て答えたかを示す設計が有効です。

根拠の提示には二つの効果があります。一つは、利用者が自分で確認できること。もう一つは、根拠を示せない回答を表示しない、という制御が可能になることです。参照した箇所が見つからなかった場合は「該当する情報が見つかりませんでした」と返し、担当者への導線を出す。これは、もっともらしい作り話を表示するよりはるかに健全です。

一方で、根拠の提示は万能ではありません。参照した文書は正しくても、そこからの解釈が誤っていることはあります。根拠付きの回答は「確認しやすくなる」ものであって、「正しいことの証明」ではない、という理解を社内で共有しておいてください。

人の承認を挟む範囲を決める

AIの出力が外部に出る前に人が確認するかどうかは、事業判断です。

判断の軸は、間違ったものが出たときに取り返せるかです。社内向けの下書きであれば、間違っていても書き直せば済みます。顧客へ自動送信されるメール、公開される記事、契約に関わる回答であれば、出てしまった後では取り返せません。

実務的な整理としては、次の三段階があります。

1. 人が必ず承認する：AIは下書きを作り、担当者が編集・承認してから外に出す。対外文書、顧客への回答、公開コンテンツ。
2. 人が事後に確認する：自動で出すが、一定割合を抽出して品質を点検し、傾向を把握する。分類、振り分け、社内向けの要約。
3. 人が確認しない：誤りの影響が小さく、利用者が自分で判断できるもの。入力補助、言い換えの候補、検索の並べ替え。

段階を上げるほど運用の人手がかかります。だからこそ、最初から全部を自動化しようとせず、1から始めて実績を見ながら2へ、可能なら3へという進め方が安全です。逆順、つまり自動で出し始めてから問題が起きて人を挟む、という流れは信頼の回復に時間がかかります。

AIが作ったと伝え、直せる導線を置く

最後に表示上の設計です。AIが生成した内容であることを利用者に伝えてください。「AIが作成した下書きです。内容をご確認ください」の一行があるかどうかで、利用者の受け取り方は変わります。

あわせて、誤りを報告できる導線を用意します。表示のそばに「この回答は役に立ちましたか」「誤りを報告する」を置き、報告と一緒に該当の入出力を記録する。これが品質改善の材料になります。指示文の修正も、参照させる資料の追加も、この報告がなければ当てずっぽうになります。画面上の見せ方はAI機能の画面の作り方で扱います。

弊社は既存のAI APIを組み込む立場で開発しており、この「どこまでを自動で出すか」の線引きを発注者と一緒に決めることを設計の一部としています。誤りが許されない領域では、AIに書かせない設計をご提案することもあります。

AI活用開発やWebシステム開発についてのご相談はお問い合わせからお受けしています。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。