実在しない判例が裁判所に提出された|AIの出力をどこで確かめるか
2025年1月、米国テキサス州の裁判所で公聴会が開かれました。前年に提出された弁護士の意見書に、実在しない判例が引用されていたことが判明したためです。
先に結論をお伝えします。この事故の原因は、技術の限界ではありませんでした。公的機関の記録に、そう読める一文が残っています。そして対策は「全部を疑うこと」ではなく、「外に出るものだけ、決まった場所を見ること」です。
「知らなかった」が事故の原因だった
この事例は、IPA(情報処理推進機構)の「情報セキュリティ10大脅威 2026」の解説書に記載されています。原文はこうです。
2025 年 1 月、米国テキサス州の裁判所で公聴会が開催された。前年に同州の弁護士が提出した意見書に実在しない判例が引用されていることが判明し、生成 AI を用いて作成していたことが明らかになった。当該弁護士は、生成 AI を用いて作成したデータにハルシネーションが起こりうることを知らなかったという。
最後の一文が、この記事の出発点です。
使い方を誤ったのでも、確認を怠ったのでもありません。そもそも「AIが事実でないことを書く場合がある」という前提を持っていなかった。だから確認するという発想自体が生まれませんでした。
裁判所に提出する書面ですから、この弁護士が仕事に不誠実だったとは考えにくいところです。知っていれば確認したはずのことを、知らなかった。それだけで事故になりました。
これは他人事ではありません。社内でAIを使っている人全員が、この前提を持っているでしょうか。導入するとき、その説明をしたでしょうか。
多くの場合、AIは誰かが個人的に使い始めて、便利だったから広がるという経路をたどります。上から配られた道具なら説明の機会がありますが、下から広がった道具には、その機会がありません。使い方は口伝えで広がっても、注意点は一緒には伝わらないのが普通です。
AIが事実でないことを述べる現象そのものについては、AIはなぜ間違ったことを自信満々に言うのかで扱っています。本記事は、その先の「では業務でどう扱うか」という話です。
公的機関が、今年はじめてリストに入れた
この事例が載っている「情報セキュリティ10大脅威」は、IPAが毎年発表しているものです。専門家で構成される選考会が、社会的な影響の大きかった脅威を選んでいます。
2026年版の組織向けの一覧に、これまでになかった項目が入りました。
| 順位 | 脅威(原文のまま) |
|---|---|
| 1 | ランサム攻撃による被害 |
| 2 | サプライチェーンや委託先を狙った攻撃 |
| 3 | AIの利用をめぐるサイバーリスク(初選出) |
| 4 | システムの脆弱性を悪用した攻撃 |
| 5 | 機密情報を狙った標的型攻撃 |
IPA「情報セキュリティ10大脅威 2026」組織向け(2026年1月29日公開)の記載にもとづく。6位以下は本記事の主題から離れるため省略
ここで正確にお伝えしておきます。IPAは解説書の冒頭で、順位の意味についてこう断っています。
組織の脅威はランキング形式で紹介しているが、順位が危険度を表しているわけではない。昨年の被害事例等の状況から、「10 大脅威選考会」の参加者がそれぞれの観点で、社会的に影響が大きかったと判断した脅威の順である。
「3位だから3番目に危険」ではありません。影響の大きさで並べた結果です。
それでも注目に値します。初めて選ばれて、いきなり上位に入った。1位と2位が4年連続で変わっていない中での出来事です。
この項目の説明には、4つの内容が含まれています。原文から引きます。
AIに対する不十分な理解による、意図しない問題として他者の権利侵害、情報漏えい、AI が加工・生成した結果を十分に検証せず鵜呑みにすることにより生じる問題、AI の悪用によるサイバー攻撃の容易化、手口の巧妙化などがあげられる。
3つ目が本記事の主題です。そして冒頭の弁護士の事例は、まさにこれにあたります。
動くことと、正しいことは別
ここから実務の話に移ります。
AIに何かを作らせたとき、私たちは自然に「動いたかどうか」で判断します。文書なら読めるか、表なら計算が合うか、ツールなら起動するか。
ところが、この確認は「正しいかどうか」を見ていません。
実在しない判例の事例が、それをよく示しています。書面としては完成していました。体裁も整い、論旨も通っていたはずです。問題は、引用された判例が存在しなかったことだけでした。
読める文章と、正しい文章は、見た目で区別がつきません。むしろAIが作るものは体裁が整っているぶん、間違いが目立ちにくくなります。
よくできた模造品のようなものです。粗雑な偽物なら見ればわかりますが、精巧なものは手に取っただけでは判断できません。調べる工程を通さないと分からない、という点が同じです。
IPAも、この点を利用者側の課題として書いています。
生成 AI の業務利用においては、生成された情報の正確性を確認せず活用した結果、思わぬトラブルが引き起こされるリスクもあるため、利用者が十分に確認する必要性について指摘されている。
どこを確認すればいいのか
「確認しましょう」だけでは動けません。どこを見るかを決めます。
結論から言うと、優先すべきは固有名詞・数字・出典の3つです。
| 見るもの | 確認の方法 | なぜ優先するか |
|---|---|---|
| 固有名詞 | 検索して実在するか見る | 架空でも自然に読める |
| 数字 | 元の資料に当たる | 桁や単位がずれても気づけない |
| 出典 | そのURLを実際に開く | 存在しないURLが作られることがある |
| 言い回し・構成 | 読んで違和感を見る | 間違っても実害が小さい |
上の3つに共通するのは、「元をたどれるかどうか」で判定できることです。正しいかどうかを自分で判断する必要がありません。たどれなければ疑わしい。それだけです。
これは、知識のない分野でも実行できるという点で重要です。判例の正しさを判断するには法律の知識が要りますが、その判例が存在するかを確かめるだけなら、誰にでもできます。
冒頭の事例も、判例名を検索するだけで防げたはずです。難しい確認ではありませんでした。必要だと知らなかっただけです。
全部を確認しなくてよい
ここが実務では最も大事な点です。すべての出力を確認しようとすると、必ず続きません。
AIを使う理由は速さです。そこに全件確認を課すと、速さが消えます。すると現場は確認をやめるか、AIを使うのをやめます。どちらも望ましくありません。
ですから、線を引きます。判断の基準は1つで足ります。
「間違っていた場合に、誰かが損をするか」。
| 扱い | 対象の例 |
|---|---|
| 必ず確認する | 社外に出る文書、金銭が動く判断、人事・法務に関わる内容、公開する記事 |
| 気づいたら直す | 社内の共有資料、会議のたたき台 |
| そのまま使う | 自分用のメモ、アイデア出し、下書き、自分が内容を判断できる範囲のもの |
3段目を用意することが、この表の要点です。「確認しなくてよいもの」を明示しないと、現場は全部を確認するか、何も確認しないかの二択になります。
健康診断のようなものです。全身をくまなく毎日調べる人はいません。年に一度、決まった項目を見る。それで大半は足ります。
IPAも、対策として挙げているのは全件確認ではありません。解説書の「AI利用における教育の徹底」には、こう書かれています。
ユーザーの指示等を正確に反映した結果を出力するとは限らないこと、ハルシネーションが存在することを理解する/AI への過剰な依存に留意する
「理解する」と「留意する」です。禁止でも全件確認でもありません。冒頭の弁護士に欠けていたのは、まさにこの理解でした。
確認する人を分ける
もう1つ、手順に組み込むと効くことがあります。作った人以外が確認することです。
理由は、自分が指示して出てきたものは、期待どおりに見えてしまうからです。「こう書いてほしい」と依頼して、そのとおりの体裁で返ってくると、内容まで合っている気がします。
いわば、自分で書いた文章の誤字が見つけられないのと同じです。頭の中に正解があるので、目がそこを補ってしまいます。他人が読むと一瞬で見つかります。
ただし、中小企業では確認役を別に立てる余裕がない場面も多いはずです。その場合は、時間をずらすだけでも効果があります。作った直後ではなく、翌朝に見る。それだけで「期待どおりに見える」状態から少し離れられます。
ここは本シリーズで扱った送金の確認と、構造が同じです。依頼が届いた経路の中で確かめても意味がないので、別の経路を用意する。作った本人の目も、同じ経路の中にあります。
AIに確認させれば済むのではないか
ここで当然の疑問が出ます。「AIの出力を、別のAIに確認させればいいのではないか」。
実際、それは有効な場面があります。誤字の検出や、文章の整合性のチェックは、機械のほうが速く正確です。
ただし、この記事で扱っている種類の誤りには効きません。理由は2つあります。
1つ目は、確認する側も同じ性質を持っていることです。実在しない判例を「実在するか」と尋ねても、実在するという答えが返ってくる場合があります。存在しないものを、存在するかのように述べる。それが問題の本体だからです。
2つ目は、AIには「元をたどる」動作が保証されていないことです。前章で挙げた確認方法は、判例名を検索して原典に当たることでした。実際にそのページを開いたかどうかが要点であって、開いたつもりの回答では意味がありません。
体温計を体温計で測るようなものです。同じ仕組みで作られたものを突き合わせても、両方が同じようにずれていれば、ずれは見つかりません。
ですから、確認の最後には人が実際に原典を開く工程が要ります。ここだけは省略できません。逆に言えば、省略できないのはここだけです。
この考え方は、AIを業務に組み込むときの安全設計と共通しています。詳しくはAIセキュリティ対策チェックリストで扱っています。
AIに作らせた業務ツールの場合
文書だけでなく、AIに小さな業務ツールを作らせるケースも増えています。集計表を自動で作る、問い合わせを分類する、といったものです。
ここでも「動くことと正しいことは別」が当てはまりますが、確認する場所が変わります。
最優先は公開範囲です。社内向けのつもりで作ったものが、URLを知っていれば誰でも開ける状態になっていないか。
これは数分で確認できて、見つかったときの影響が最も大きい項目です。実際に開いてみる、ログアウトした状態で開いてみる。それだけで分かります。
次に見るのは扱っているデータの範囲です。集計のために顧客名簿を丸ごと読み込ませていないか。必要な列だけで足りないか。
動作テストでは、この2つは見つかりません。テストは「期待どおり動くか」を見るもので、「想定していない使われ方をしたときどうなるか」は見ていないからです。
鍵をかけ忘れた部屋のようなものです。中で仕事をしている限り、何の問題も起きません。困るのは、誰もいない時間に誰かが入れることのほうです。
IPAは同じ章で、もう1つ別の型の事例も挙げています。製品側に脆弱性が見つかった例です。
2025 年 6 月、Microsoft 365 Copilot の脆弱性「EchoLeak」の存在が報道された。この脆弱性を悪用する不正プロンプトが外部から注入されると、不適切な AI の動作が誘発され、…社内の秘密データ等が流出する可能性があったという
この件はすでに修正済みだとIPAも記載しています。ここで挙げたのは、危険を煽るためではありません。自社の作り方とは無関係に、使っている製品の側で問題が見つかることもあるという一点を示すためです。
だからこそ、最新の状態に保つことと、公開範囲を絞っておくことの両方が要ります。製品側の問題は自社では直せませんが、届く範囲は自社で決められます。
外部から来た指示がAIを動かす仕組みそのものについては、本シリーズの別の記事で扱っています。外部に開発を委託する場合の見極め方は、AIベンダーのセキュリティを見極める設計にまとめています。
IPAは対策を、立場ごとに分けて書いている
ここまでは確認のやり方でした。組織として何を決めるかについて、IPAは対策を2つの立場に分けて挙げています。この分け方自体が参考になります。
解説書には、「経営者層」と「システム管理者、従業員、職員」という2つの見出しが立っています。前者は決めることで、後者は日々やることです。
| 立場 | 挙げられている項目(原文の要点) |
|---|---|
| 経営者層 | 未許可・未認可のAIサービス利用の禁止/利用規定の整備(個人アカウントでの業務利用の制限、規程違反時の対応の明確化)/入力データを学習対象から除外するオプトアウト設定の徹底/契約時の約款の確認/相談窓口の確保/決裁・承認プロセスに複数名によるチェックを規程化 |
| システム管理者 従業員・職員 |
利用状況の把握と多要素認証の徹底/既存対策全般の点検/社内の秘密情報等を安易に入力しない/ハルシネーションが存在することを理解する/AIへの過剰な依存に留意する/最新の手口の把握/被害を受けた後の報告・連絡・相談 |
IPA「情報セキュリティ10大脅威 2026」解説書[組織編]の記載にもとづく(2026年3月)
この一覧を見ると、本記事の主題がどこに位置するかが分かります。「ハルシネーションが存在することを理解する」は、従業員側の項目です。つまり教育の話として整理されています。
そして注目したいのは、経営者層の側に「決裁・承認プロセスに複数名によるチェックを規程化」があることです。理解を促すだけでなく、理解していなくても止まる仕組みを作れ、という構成になっています。
言い換えれば、教育と手順は両輪です。教育だけでは忙しい日に抜けます。手順だけでは、なぜやるのか分からないまま形骸化します。
なお、この一覧のうち「入力データを学習対象から除外するオプトアウト設定」と「複数名によるチェック」は、本シリーズの別の記事で詳しく扱っています。前者は入力した情報がどこに残るかという話、後者は送金指示の確認という話です。IPAの3位は、AI利用の広い範囲を1項目にまとめたものだと分かります。
確認を手順にする
ここまでの内容を、続く形にします。意識ではなく手順にするのが要点です。
理由は単純で、意識は忙しいと下がるからです。冒頭の事例も、締め切り前に起きたことかもしれません。
やることは3つです。
1つ目は、確認する対象を先に決めることです。前章の表のように、「必ず確認する」に入るものを数個だけ挙げます。全部を挙げると使われません。
2つ目は、確認したことを残すことです。提出物のチェック欄に「出典を開いて確認した」の1行を足す。署名する場所があると、飛ばしにくくなります。
3つ目は、社内に一度説明することです。冒頭の事例が示すとおり、知らないことは確認できません。「AIは事実でないことを書く場合がある」という一文を共有するだけで、防げる事故があります。
社内に伝えるときの言い方
3つ目の「一度説明する」について、もう少し具体的に書きます。伝え方で定着が変わります。
避けたいのは、性能の話から入ることです。「AIはまだ完璧ではない」という言い方をすると、聞いた側は「では性能が上がれば要らなくなる話だ」と受け取ります。実際には、確認が要る理由は性能ではなく、扱う内容が外に出るかどうかで決まります。
効くのは、具体的な事故を1つ話すことです。冒頭の判例の事例は、この目的にちょうど合っています。専門家が、まじめに仕事をしていて、それでも起きた。「気をつけていれば防げる」という話にならないところが要点です。
そのうえで、やることを1文で示します。「外に出る資料は、固有名詞と数字と出典だけ確認してください」。これなら覚えられます。
説明会を開く必要はありません。朝礼で3分、あるいは既存のマニュアルに1段落足すだけで足ります。大事なのは、全員が一度は聞いた状態を作ることです。
確認にかかる時間の見当
「確認」と聞くと工数が心配になりますが、実際にかかる時間は限られています。
固有名詞と数字の確認は、検索して元の資料が出てくるかを見るだけです。1件あたり十数秒から数十秒で、A4数枚の資料でも数分で終わります。
むしろ時間がかかるのは、確認するかどうかを毎回迷うことのほうです。だから前章のように、対象を先に決めます。迷う時間をなくすほうが、確認そのものの時間より効きます。
判断の記録をどう残すかは、AIの判断に説明責任を持たせる設計で扱っています。社内ルール全体の設計は生成AIの社内ガイドライン作成ガイドにまとめています。
明日から始める3つの手順
3番目が最も効きます。費用もかからず、時間も数分です。そして冒頭の事例は、まさにこれが欠けていたために起きました。
把握されていない利用が社内に広がっていると、この説明が届きません。その状態への対処はシャドーAI対策ガイドで扱っています。
まとめ|疑うのではなく、通り道を作る
整理します。米国の弁護士が、実在しない判例を引用した書面を裁判所に提出しました。IPAはその事例に「ハルシネーションが起こりうることを知らなかったという」という一文を添えています。
そして2026年、「AIの利用をめぐるサイバーリスク」が組織向けの脅威として初めて選ばれました。その説明には「AIが加工・生成した結果を十分に検証せず鵜呑みにすることにより生じる問題」が含まれています。
私たちが実務で大事だと考えているのは、「疑う文化」を作らないことです。全部を疑えという運用は、速さを失わせ、やがて形骸化します。
代わりに、通り道を1本作ります。外に出るものだけ、固有名詞と数字と出典の3つを見る。正しさを判断するのではなく、元をたどれるかを見るだけなので、専門外でも実行できます。
そして、いちばん効くのは社内に一度説明することです。冒頭の弁護士に欠けていたのは技術でも注意力でもなく、「AIは事実でないことを書く場合がある」という一文でした。
この記事で扱った確認は、どれも専門知識を必要としません。固有名詞を検索する、数字の出どころに当たる、URLを実際に開く。正しいかどうかを判断するのではなく、たどれるかどうかを見るだけです。
だから、導入した部署でなくても、詳しい担当者がいなくても実行できます。費用もかかりません。必要なのは、外に出るものを決めることと、その3つを見る習慣だけです。
自社でどこから手をつけるべきか迷われている場合は、無料相談でも承っています。
よくある質問
AIの出力を毎回確認するのは現実的ではないのですが、どうすればいいですか?
全部を同じ強さで確認する必要はありません。判断の基準は「間違っていた場合に、誰かが損をするか」です。社外に出る文書、金銭が動く判断、人事や法務に関わる内容は、確認の対象にします。一方、社内の下書きやアイデア出し、自分が内容を判断できる範囲のものは、そのまま使ってよいと考えています。IPAは「情報セキュリティ10大脅威 2026」の解説書で、AI利用における教育として「ユーザーの指示等を正確に反映した結果を出力するとは限らないこと、ハルシネーションが存在することを理解する」ことと「AIへの過剰な依存に留意する」ことを挙げています。全件を疑うのではなく、外に出るものと戻せないものを選んで確認する、という切り分けが現実的です(2026年8月29日時点の公開情報)。
AIが作った資料の、どこを確認すればいいですか?
優先すべきは、固有名詞と数字と出典です。実在しない判例が裁判所に提出された事例では、判例という固有名詞が架空でした。この種の誤りは、文章としては自然に読めるため、通読しただけでは気づけません。確認の方法は単純で、その固有名詞や数字を検索して、元の資料に当たれるかを見ます。当たれなければ、実在しない可能性があります。逆に、文章の言い回しや構成は、間違っていても実害が小さいので確認の優先度は下がります。IPAも解説書で「利用者は生成結果の精査を行うことが求められる」と書いています(2026年8月29日時点の公開情報)。
AIに作らせた社内ツールは、動いていれば大丈夫ですか?
動くことと安全であることは別です。動作確認は「想定した使い方をしたとき、期待どおりに動くか」を見るものであり、「想定していない使われ方をしたとき、どうなるか」は見ていません。IPAは「情報セキュリティ10大脅威 2026」で、AIの利用をめぐるサイバーリスクを組織向けの一覧に挙げており、その説明にAIが加工・生成した結果を十分に検証せず鵜呑みにすることにより生じる問題を含めています。実務では、公開範囲の確認から始めるのが有効です。社内向けのつもりで作ったものが、URLを知っていれば誰でも開ける状態になっていないかを見ます。この確認は数分で終わり、見つかったときの影響が大きい項目です(2026年8月29日時点の公開情報)。
参考にした情報
- IPA 独立行政法人 情報処理推進機構|情報セキュリティ10大脅威 2026
- IPA プレス発表|「情報セキュリティ10大脅威 2026」を決定(2026年1月29日)
- IPA|AI利用者のためのセキュリティ豆知識(2025年12月版・2026年4月公開)
本記事は2026年8月29日時点で公開されている情報にもとづいています。公的機関の資料は更新される場合があるため、社内ルールを決める前に最新の記載をご確認ください。