ハルシネーションはシステム障害ですか？

同じではありません。処理は正常終了していても、生成内容が根拠と食い違う失敗であり、稼働監視だけでは検知できません。

検索を接続すればゼロになりますか？

なりません。資料の選択、古さ、引用の取り違え、根拠が主張を支えない問題が残ります。

重要主張を一次資料と照合し、不確実なら回答を保留し、高リスク用途では人の承認と訂正経路を設けます。

このカードで意味するもの	生成AIのハルシネーションは、誤った内容をもっともらしく生成・提示する現象です。
同じものとして扱わない	内容の真偽の失敗／処理や通信の失敗
共有する前に確認	出力は完了したか主張を一次資料で検証できるか誤った場合の影響と承認者

「AIのエラー」と一語で済ませると、直す場所まで誤ります。共有前に分けたいのは、「応答したか」「内容を根拠と照合できるか」「原因まで特定できたか」の三欄です。ミハルは、分からない原因を無理に名付けません。

通信障害や例外は処理が止まり、エラーコードが出るため機械的に検知しやすい失敗です。ハルシネーションは自信のある回答として完了することがあり、外部根拠と照合しないと発見できません。

ハコは「応答した」と「正しかった」を別の欄に記録します。前者は可用性、後者は内容品質です。HTTP 200が返っても、日付や引用が正しいとは限りません。

この表は原因を決め打ちするためではなく、最初の切り分けです。同じ画面の裏で、生成、検索、外部連携、権限の問題が重なることもあります。

存在しない文献、誤った日付、入力と矛盾する要約など形は様々です。創作では架空内容が目的に合う場合もあるため、同じ出力でも利用文脈でリスクが変わります。

架空の物語を作る依頼で架空人物を出すのは失敗ではありません。一方、実在論文の一覧で存在しない書誌情報を出せば問題です。判定には利用目的と、どの主張が検証可能であるべきかが要ります。

ここで「ハルシネーション」と呼んでいるのは、検証されるべき内容が根拠と食い違う現象です。どの段で起きたか、なぜ起きたかまでを、その名前だけで確定することはできません。

検索や外部ツールを接続しても誤りはゼロになりません。古い資料、取り違え、引用と主張の不一致もあります。出典らしいURLがあるだけでなく、資料が文を支えるか確認します。

そのため、誤った回答の画面だけを見て「モデルが作った」「検索が壊れた」と原因を選びません。まず誤っていた主張を特定し、使われた資料、入力、処理記録を順に確かめます。確認できない段階は「原因未確認」のまま残します。

モデルの大きさだけでも解消しません。「パラメータ数と性能」は設計情報であり、誤りの種類と頻度は同一条件で測ります。

役割から分けると、サービスが応答できる状態を確かめるのが稼働監視、返した内容を根拠と照合するのが内容評価です。運用では検証が必要な主張を識別し、一次資料、回答拒否、人の承認を組み合わせます。障害監視とは別に標本評価と訂正経路を設けます。

停止、遅延、エラー率はシステム監視で追えます。内容面は代表質問の定期評価、根拠照合、利用者からの訂正受付が必要です。「ベンチマークと実務評価」を分けるのも同じ理由です。

覚え方: 止まらなかった失敗は、監視画面に出てこない。