AIの信頼性を高めるUX設計｜根拠・確認・取り消しの6パターン、精度より先に効く見せ方

その夜、完成しかけていたホームページの画面のあちこちで、エラーが噴き出しました。

読み込みが異様に重いページ。データベースとの通信に失敗する画面。昨日まで機嫌よく動いていたはずの箇所が、仕上げの確認を始めた途端、次々と音を上げていく。ひとつ直すと、別の場所で似た症状が出る。もぐらたたきです。

原因を追いかけていくと、行き着いた先は数か月前の自分でした。開発の初期、ひとつのコンポーネント——画面の部品——を参考に、AIに派生させる形で複数の部品を作らせていたのです。「これと同じ感じで、あの画面用のも作って」。便利な頼み方でした。実際、部品はすいすい増えていきました。

ただ、それぞれの部品は、それぞれの場面で少しずつ違う使われ方をしていて、AIはそのつど、その場面に最適な作り方を選んでいた。気づけばプロジェクトの中に、動作のポリシーが微妙に食い違う部品が同居していました。データの取りに行く方法がバラバラだから、あるページでは通信量が膨れ上がり、あるページではデータベースへの接続がこける。一つひとつの部品は正しいのに、集まると壊れる。個別最適の寄せ集めが、全体では不整合になっていた訳です。

筆者はAIと一緒にアプリを作る、いわゆるバイブコーディングの人間です（経緯は自己紹介にて）。そしてこの数か月間、AIの作業は、どこからどう見ても順調でした。頼めば作ってくれる。動く。画面もできていく。順調に「見えて」いただけだったのです。

「順調に見える」が、いちばん怖い

この事件でこたえたのは、不具合の修正作業そのものではありません。信頼の壊れ方です。

AIは一度も嘘をつきませんでした。頼んだものは作ってくれたし、そのつど「できました」と報告もしてくれた。ただ、部品同士の設計が割れ始めていることを、AIは言わなかったし、筆者には見えなかった。見えないまま進んだ作業は、壊れるときに、まとめて壊れます。　そして一度まとめて壊れると、それまでの「できました」の全部が疑わしくなる。あの夜の筆者は、動いている画面まで疑い始めていました。

これがAIとの仕事の、信頼の構造なんだと思います。壊れる前にどれだけ順調でも、途中が見えていなければ、信頼の貯金は実はゼロのまま。逆に言えば、AIへの信頼は、賢さではなく「見え方」で作られる。

念のため添えると、これはバイブコーディングに限った話ではありません。資料を要約するAI、問い合わせに答えるAI、データを集計するAI。どれも「できました」は言えますが、その裏で何をどう解釈したかは、設計しなければ見えません。見えないまま受け入れる日々が続いたあと、どこかで大きめの誤りが露見して、担当者がそれまでの全出力を検算し始める——この展開は、業種を問わず起きています。

実は筆者は、これとそっくりな話を、AIとは何の関係もない場所で叩き込まれています。電力会社の、稟議書です。

上司の「うん」を引き出す、稟議書の技術

かつて大きな電力会社で働いていたころ、稟議書——社内でお伺いを立てる文書——を、それはもう山ほど書きました。若手のころは、正しい結論を書けば通るものだと思っていました。実際には、内容がまっとうでも質問攻めに遭う日もあれば、似たような案件がするりと通る日もある。この差はどこから来るのか。場数を踏むうちに、通る資料の共通点が見えてきました。

まず、書面はシンプルに保つ。そのうえで、検討の過程は「書く」のではなく「持っておく」。どんな選択肢を並べて、何を捨てて、なぜこれにしたのか——その検討メモは書面に盛り込まず手元に控えておき、質問が飛んできたら、即座に的確に答えられるようにしておく。何でも書き込んだ分厚い資料は、読み手の時間を奪ううえ、余計な質問の的も増やします。書面は薄く、弾薬は手元に。これが標準形です。

ただし、例外を一つだけ作ります。「ちゃんと考えたのか？」という質問が来そうな箇所に限って、検討の過程をあらかじめ書いておくのです。ここは突っ込まれる、と分かっている論点だけ、比較した選択肢と捨てた理由を先回りして載せる。すると面白いもので、書いていない部分への質問まで減ります。急所で「考えてある」ことを示した書き手は、残りの部分もちゃんと考えていそうだ——という信用が生まれるからです。全部を見せるのではなく、問われる所だけ先に見せて、残りは出せるように持っておく。この濃淡が肝でした。

次に、想定される問題とデッドラインを、先にこちらから書く。都合の悪い話を隠さず、「ここが危ない・いつまでに決める必要がある」を明記する。不思議なもので、リスクを書けば突っ込まれそうなのに、実際は逆です。先に書いてあるリスクは「把握済みの管理対象」に見え、質問で暴かれたリスクは「隠していた地雷」に見える。同じリスクでも、出どころで意味が変わるのです。

そして、「ここまではセーフ」を分かりやすくする。この範囲なら失敗しても引き返せる、影響はここで止まる、という線を引いて見せる。決裁のハンコは、要は「何かあったら自分も責任を負う」という意思表示ですから、上司が本当に知りたいのは成功の見込みより「最悪のとき、どこまでで止まるのか」だったりします。

こうして作った資料は、上司の「うん」が、驚くほど軽く出ます。人は、結論の正しさではなく、問われる前の備えと、外れたときの戻りやすさで「うん」と言う訳です。

で、あの夜のHPの話に戻ると——筆者がAIに欲しかったものは、まさにこれでした。問われれば出てくる検討の過程。危ない箇所の先出し。ここまではセーフの線。つまり、稟議書の技術です。

「ここまではセーフ」を画面にする ― AIの信頼性を高めるUXとは・6つの設計パターン

稟議書で人間相手にやっていたことを、AIプロダクトの画面に翻訳する。それがこの章の地図です。

AIの信頼性とは｜性能の信頼性と、体験の信頼性

AIの信頼性には2つの層があります。ひとつはモデルの性能——正答率や安定性。もうひとつは体験としての信頼性——ユーザーが結果を理解でき、確かめられ、間違いに気づけ、直せること。この記事が扱うのは後者です。そして実務でユーザーの「任せられる／任せられない」を分けるのは、多くの場合こちらの層です。

なぜ精度だけでは信頼されないのか

AIの出力は毎回同じとは限らず、しかも自信のある口調のまま間違えることがあります（この現象と対策の全体像はハルシネーションの対策が詳しいです）。精度を99％まで上げても、残り1％の外れ方が「気づけない・戻れない」形なら、ユーザーは全出力を疑うしかなくなります。信頼は平均値ではなく、最悪の一回の扱いやすさで決まります。

信頼が壊れる3つの瞬間

筆者のHP事件は、2番目の典型です。間違いというより「割れ始めた設計」でしたが、気づける画面がどこにも無かった。

設計6パターンの全体像

パターン1｜根拠の提示

答えと一緒に「何を参照したか」を出し、ワンタップで原典を開けるようにします。社内文書を扱うAIなら、答えの正しさを議論するより「根拠をすぐ開けられるか」を設計するほうが早い。ユーザーは毎回原典まで開くわけではありません。それでも「開こうと思えば開ける」ことが、開かずに信じるための条件になる。裏取りできる相手だから、裏を取らずに済む——稟議書の「過程は書かずに、持っておく」と同じ備えの構造です。画面を根拠で埋め尽くす必要はなく、求められた瞬間に出せることが信頼を作ります。検索と根拠提示の仕組みはRAGとはで扱われている領域です。

パターン2｜途中経過の表示

「いま、この3つの資料を確認しています」。それが一行見えるだけで、ブラックボックスから答えがぽんと出てくるのとは安心感が別物になります。長い処理ほど、進み具合と、いま何をしているかを見せる。カウンターの向こうで手が動いているのが見えるお店のほうが、なんとなく安心して任せられるのと同じ理屈です。筆者のHP事件で言えば、部品を作るたびに「既存の部品とは別の通信方式を選びました」の一行が見えていれば、あの夜は来なかったはずなのです。

パターン3｜実行前の確認

取り返しのつきにくい操作の前に、「これから◯◯を△△します。よろしいですか」を挟みます。確認は敵ではありません。むしろ、確認があるからこそ、ユーザーは日常の操作を安心して任せられます。ポイントは確認文の中身で、「実行しますか？」だけでは確認になっていません。何を・どこに・どのくらい、が一目で分かる具体性があって、はじめてユーザーは判断できます。稟議書と同じで、判断材料のない伺いは、伺いの形をした丸投げです。

パターン4｜影響範囲の明示

この操作で変わるのはどこまでか、変わらないのはどこか。「ここまではセーフ」の線を画面で引きます。「この変更は8つのファイルに影響します」「この設定は自分にだけ適用されます」。影響範囲が見えない操作は、小さくても怖い。見えれば、大きくても任せられる。ユーザーが操作をためらって手が止まる場所には、たいていこの線が引かれていません。

パターン5｜取り消し・やり直し

外れたときに、一手で戻れること。全部のやり直しではなく、一部分だけ直せること。人がAIに任せられるのは、「最後のひと筆を自分で入れられる」と分かっているときです（この原則はAIのUI/UXデザインでも設計6原則のひとつとして書きました）。戻れる設計は、それ自体が信頼の作り方です。

パターン6｜限界の自己申告

「この種の質問は苦手です」「この範囲のデータしか見ていません」「この回答の確信度は低めです」を、AI自身に言わせます。できないことを黙っている道具より、先に申告する道具のほうが、できることを信じてもらえます。稟議書で、問われそうな急所だけを先回りして書いておくのと同じ理屈です。全部の回答に自信満々なAIは、ユーザーから見れば「自信の情報量がゼロ」のAIでもあります。強気と弱気の差があるからこそ、強気の回答が信じられるのです。

6パターンを画面部品に翻訳すると

抽象論で終わらせないために、それぞれのパターンがどんな画面部品になるかの対応も置いておきます。

どれも新発明ではなく、良いソフトウェアが昔からやってきたことの応用です。AIだから特別な部品が要るのではなく、AIだから「昔からある誠実な部品」の優先度が上がった、と捉えるのが正確だと思います。

導入の順番｜効く順に足す

6つ全部を一度に作る必要はありません。筆者のおすすめは、確認（3）→根拠（1）→取り消し（5）の順です。まず事故を止め、次に疑いを減らし、最後に外れたときの回復を軽くする。途中経過（2）と影響範囲（4）と自己申告（6）は、その骨格に肉付けしていく形で足せます。

やりすぎの罠

信頼の設計にも過剰摂取があります。あらゆる操作に確認を挟めば、ユーザーは読まずにOKを連打するようになり、確認は形骸化します。警告を出しすぎれば、本当に危ない一回が埋もれます。確認は「取り返しのつきにくさ」に比例させて濃淡をつける——ここも稟議と同じです。何でも書き込んだ分厚い資料が読まれないように、何でも見せて何でも確認するAIも、信用されない。書面は薄く、弾薬は手元に、急所だけ先出しに。あの濃淡の技術が、そのまま画面に要るのです。

組織に効く、もうひとつの理由

信頼のUXは、ユーザー個人の安心のためだけではありません。AIツールの社内導入では、必ず「何かあったら誰が責任を取るのか」という問いが出ます。根拠が示され、実行前に確認が挟まり、影響範囲が見え、取り消せる——この設計は、その問いへの答えそのものです。稟議が通る資料の条件と、AIツールが社内で承認される条件は、構造がほとんど同じなのです。

効果の測り方

実行前確認の承認率（高すぎるなら確認が形骸化）、取り消し機能の利用率（使われているなら回復設計が仕事をしている）、人手による事後チェックの減り方。この3つの推移で、信頼設計が効いているかをおおよそ追えます。とくに3つ目は導入効果の説明にそのまま使えます。「AIの出力を全件人がチェックしている」状態から、確認が要る場面だけ人が見る状態へ——この移行の速さが、信頼設計の投資対効果です。

——地図はここまでです。最後に、あの夜の話の続きを。

AIは、稟議書を書かない。だから画面がそれを代わる

HPの不具合の山を片付けながら、筆者は考えていました。あれだけ「順調に見えた」数か月の間に、何が見えていれば良かったのか。

答えは、たぶん派手なものではありません。部品を派生させるたびに「既存の部品と通信方式が異なります」と一言出る。まとめて変更する前に「影響は8ファイルです」と確認が入る。おかしくなったら、派生前まで一手で戻れる。——どれも、いまとなっては自分で仕組みを整えられる類のものです（AIの能力は日進月歩なので、この種の自己申告はどんどん上手くなってもいます）。

そして、あの夜以来、筆者のAIへの頼み方もひとつ変わりました。作業をお願いするとき、「進め方の選択肢と、危ない箇所を先に教えて」を添えるようになったのです。すると面白いもので、AIはけっこう律儀に、検討過程とリスクを並べてくれる。つまり相手は、稟議書を書けないのではなく、求められていなかっただけ、なのかもしれません。プロダクトの画面設計でも同じで、AIに「見せ方」を仕込むのは、作り手が求めさえすれば、できることなのです。

でも本質は、個別の機能ではないのだと思います。AIは、稟議書を書きません。だから、検討の過程も、危ない箇所も、セーフの線も、画面の設計がAIに代わって言わせるしかない。　それがAIプロダクトにおける信頼のUXの、いちばん短い定義なんだろうと思います。

そういえば、あの「うん」と言ってくれた上司も、筆者の説明が上手いから頷いていたわけではないのでした。問われそうな所は先に書いてあり、それ以外も聞けばすぐ答えが返ってくる。危ない話が先に出ていて、引き返せる線が引いてある。だから安心して任せた。信頼は、賢さからではなく、戻れる設計から生まれる。　相手が人間でもAIでも、たぶん、ここは変わりません。

AIの信頼性UXのよくある質問

AIの信頼性を高めるUXとは何ですか？

AIモデルの精度を上げる取り組みとは別に、ユーザーが結果の根拠を確かめられ、途中経過が見え、間違いに気づけ、外れたときに戻れるように接点を設計することです。実務でユーザーが「任せられる」と感じるかどうかは、精度よりこの層で決まることが多いです。

精度が高ければ信頼は付いてくるのではないですか？

平均的な精度が高くても、外れた一回に「気づけない・戻れない」設計だと、ユーザーは全出力を疑うようになります。信頼は平均値ではなく最悪の一回の扱いやすさで決まる、というのが本文の実話から得た結論です。精度改善と見せ方の設計は、両輪で進める必要があります。

何から実装すればよいですか？

効く順は、実行前の確認→根拠の提示→取り消し、が目安です。まず取り返しのつきにくい操作に確認を挟んで事故を止め、根拠のワンタップ表示で疑いのコストを下げ、一部分だけ直せる導線で回復を軽くします。途中経過・影響範囲・限界の自己申告はその後に肉付けできます。いきなり6パターン全部を要件に積むと開発が重くなるので、対象業務で「いちばん取り返しのつかない操作」をひとつ選び、そこから始めるのが現実的です。

確認ダイアログを増やすと、うっとうしがられませんか？

なります。全操作に確認を挟むとユーザーは読まずに連打し、確認自体が形骸化します。確認の濃さは「取り返しのつきにくさ」に比例させ、軽い操作は取り消し可能にして確認を省く、という濃淡の設計が実務的です。

AIの間違い（ハルシネーション）はUXで防げますか？

発生自体を完全には防げませんが、被害と信頼の毀損は大きく減らせます。参照した根拠を示す、実行前に確認を挟む、影響範囲を明示する、取り消せるようにする——誤りを前提にした設計です。発生側の対策と併せて取り組むのが基本です。「間違えないAIを目指す」より「間違えても壊れない体験を作る」ほうが、現実的で、しかも早く効きます。

開発の初期から信頼のUXを考える必要がありますか？

はい、初期からが安上がりです。本文のHP事件のとおり、見えない不整合は後から発覚するほど直しが高くつきます。プロトタイプの段階では作り込みは不要ですが、「どこに確認を置くか」「何を根拠として見せるか」「どこまで戻れるようにするか」の3つの問いだけは、最初の設計時に決めておくことをおすすめします。

社内向けツールでも、ここまで必要ですか？

社内向けこそ効きます。本文の稟議書の話のとおり、組織の意思決定は「問われる前の備え」と「戻れる線」で動いています。AIの作業がそれを画面で示せれば、上長の承認や現場の利用は明らかに通りやすくなります。PoCを本番化する局面では特に、この設計の有無が判断材料になります。

この記事は、ARCHECOが運営するメディア「AI・新規事業戦略大学」でお届けしました。ARCHECOは、UI/UXデザインとプロダクト開発を強みに、お客さまと並走しながら「使われるもの」をつくっているチームです。ご相談・お問い合わせはこちらからどうぞ。