多くのプロダクトチームは、AIの引用を、生成されたテキストの横に整然と並ぶ小さな青い数字として設計します。彼らは高速な接続環境で一度実装し、プレビューが0.5秒でパッと開くのを確認して、次の作業に移ります。それはステージング環境では機能します。しかし、実際のインターネット環境に放り出されると、そうはいきません。
ソースは腐敗します。企業はブログ記事を削除します。政府のポータルサイトはリダイレクトなしにURLを再編します。ペイウォールが設置されます。CDNが一時的な不具合を起こします。AIが3ヶ月前にスキャンしたドキュメントは、昨日書き換えられたかもしれません。もし引用コンポーネントが「すべてが順調なとき」に美しく見えることしか考えていないなら、問題が発生したときにユーザーに対して嘘をつくことになります。さらに悪いことに、その証拠がそもそも存在したのかどうかさえ、ユーザーを混乱させてしまうのです。
信頼できる引用システムには、状態（ステート）を伝える能力が必要です。単なるハイパーリンクやツールチップだけでは不十分です。証拠に対して今何が起きているのかを、リアルタイムで読者に伝える必要があります。
4つの実在する状態を設計する
引用を小さなステートマシンとして考えてください。AIが表示するすべてのソースは、4つの条件のいずれかに当てはまります。インターフェースは、その一つひとつに対して誠実に対処すべきです。
Loading（読み込み中）。 ユーザーが上付き数字をクリックすると、システムはプレビュー、スニペット、または元のページを取得します。その待ち時間の間に、何かが進行中であることを示してください。スケルトン（プレースホルダー）、脈動する抜粋フレーム、あるいは「ソースを取得中...」というプレーンテキストであっても、何も表示されない状態よりはマシです。何も表示されないと、ユーザーはクリックが機能したのか不安になります。モデルの思考に合わせてソースが届くストリーミングインターフェースでは、読み込み状態を表示することで、テキスト生成をブロックせずにリンクを解決するための時間を稼ぐこともできます。
Available（利用可能）。 これは誰もが設計の対象とする状態です。リンクは解決し、テキストはモデルが見た内容と一致しており、ユーザーは明確な抜粋と直接リンクを受け取ります。しかし、生のURLをただ放り込むだけで終わらせてはいけません。タイトル、ドメイン、そして関連する一節を表示してください。読者がそのページを離れるかどうかを判断できるだけの十分なコンテキストを提供しましょう。括弧内に生のhrefを書くことは、技術的には引用ですが、優れたユーザー体験とは言えません。
Changed（変更あり）。 これは痛いパターンです。ページは読み込まれますが、コンテンツの中にAIが引用したはずの言葉や統計が含まれていません。出版社が記事を更新したのかもしれません。あるいは、AIの学習スナップショットが、後に変更された見出しを捉えてしまったのかもしれません。コンポーネントは、すべてが一致しているふりをするのではなく、この不一致をフラグ立てすべきです。「このソースはインデックス作成後に更新されました」といった短い注釈があれば、ユーザーが既に存在しない一文を探して10分間無駄にすることを防げます。また、信頼性の維持にもつながります。不一致を隠してしまうと、ユーザーは最終的に「この製品はでっち上げをしている」と思い込んでしまうでしょう。
Missing（欠落）。 404エラー、タイムアウト、ペイウォール。ステータスコードは200を返しながらも、中身は汎用的な「コンテンツは削除されました」というページを表示するサーバー。リンクを青いまま放置して、機能しているふりをさせてはいけません。「ページは削除されました」「リンクは利用できません」「ソースはオフラインです」といった平易な言葉に置き換えてください。失敗した理由がわかっているなら、それを伝えましょう。Internet Archiveやキャッシュされたコピーが存在する場合は、それを提供してください。目的は、読者を途方に暮れさせることではなく、情報のループを完結させることです。
アクセシビリティは譲れない条件
引用コンポーネントは、UIの中でもトラフィックが多く、重要度の高い場所に位置します。チェックアウトフォームや航空券の予約フローと同じレベルの厳格さが求められます。
ステータスを示すにはテキストを使用してください。色覚多様性を持つユーザーは、緑の点や赤い枠線だけに頼ることはできません。インジケーターには「利用可能」「変更あり」「利用不可」といった言葉を添えてください。この小さなラベルは、視覚を持つすべてのユーザーにとっても役立ちます。なぜなら、ステータスを表す色は、文化や製品によって意味が異なることが多いためです。
スクリーンリーダー向けに説明的な名前を記述してください。スクリーンリーダーを使用している人が、有用な情報を聞き取れるようにリンクにラベルを付けます。単なる「リンク」ではなく、「ソース3：監査ログの保持ポリシー」のように読み上げます。これにより、聞き手はリンクを開く前に、何が得られるのかを正確に知ることができます。
フローを保護してください。引用をクリックしたことで、AIが生成した回答が消えてしまうようなことがあってはなりません。パネル、モーダル、またはインライン展開を使用してください。読者は特定の主張を検証するためにソースを開いたのです。もしインターフェースが、今読んでいた主張を消し去ってしまうなら、ユーザーは証拠を探している間、そのテキストをワーキングメモリに保持し続けなければならなくなります。これは不必要な認知負荷です。
フォーカスを意図的に管理してください。ユーザーが引用を開いたときは、キーボードフォーカスを新しいパネルやポップアップ内に移動させます。閉じるときは、トリガー（元の場所）にフォーカスを戻します。ストリームがページにソースを書き込んでいる最中に、フォーカスを奪い取らないでください。ユーザーがコントロールを維持できるようにしましょう。
ストリーミングの扱いは慎重に行ってください。生成インターフェースが引用を逐次追加していく場合、新しい上付き数字が出るたびにスクリーンリーダー利用者にアナウンスを送り、彼らを困惑させてはいけません。それらをまとめて処理しましょう。2、3個溜まったタイミングで、「2つのソースが追加されました」といった丁寧な要約をアナウンスしてください。絶え間ない割り込みは、支援技術を利用するユーザーにとって、出力を読みづらくさせてしまいます。
引用が何を証明するかを忘れないでください
この点は、何度繰り返してもしすぎることはありません。引用は「出所」を示すものであり、「真実」を示すものではないのです。
AIがソースを引用するとき、それは「ここでこの表現を見つけました」と言っているに過ぎません。「この専門家は正しい」と言っているわけでも、「この研究は適切に行われた」と言っているわけでもありません。さらには「文脈を正しく理解した」と言っているわけでもないのです。引用とは、元の根拠へと戻るための地図です。読者は自らその道を辿り、その根拠が妥当かどうかを判断しなければなりません。
デザインによって、その違いを明確にする必要があります。ユーザーが関連する行をざっと確認できるような抜粋を使用してください。根拠がどれほど新しいものか読者が判断できるよう、発行日を表示しましょう。ソースがフォーラム、プレスリリース、あるいは一次研究である場合は、その文脈を明示して、読者が適切に判断できるようにしてください。インターフェースは、人間の判断を置き換えるのではなく、支援するように構築すべきです。
現実に基づいてテストする
視覚的なレビューを通過した引用コンポーネントは、まだ完成の半分に過ぎません。あなたには