サイバー攻撃の対策

内部不正の防止

システムやデータの保護

業務プロセスの改善

社内情報の共有

テレワークの導入

データ分析の実現

人材の育成

採用の効率化

採用管理システム

人事評価の適正化

情報の可視化

ペーパーレス化の実現

総務・経理業務の最適化

IT資産管理の最適化

営業プロセスの改善

見込み客（リード）の
獲得・育成

AIの“それらしい答え”、そのまま出していませんか――誤り・著作権・見えない指示への備え

AIが示した情報を信じて送ったら、実在しなかった――。こうした事故を防ぐには、どこまで確認すべきか。ハルシネーションや著作権、資料に紛れた“見えない指示”を基に、AIの出力を使う際の線引きを整理する。

公開 2026年09月30日 07時00分

著者

廣山豊（KDDIアイレット）

[キーマンズネット]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

　例えば、ある担当者が、契約まわりの質問にAIで回答を作りました。「根拠の条文も教えて」と頼むと、AIは条番号付きでスラスラ答えます。正しそうに見えたので、そのまま客先メールに貼り付けて送信――。後日、相手から「その条文は存在しないのですが」と指摘が入りました。AIが“それらしく”作り上げた、実在しない条文だったのです。

　第1回「なぜ今、『防御とAI』なのか」ではAIリスクの全体像と「見える化」を、第2回「『シゴデキ社員』ほどシャドーAIに陥りやすい？」では会社が把握していないAI利用への対策を、第3回「その見積書、ChatGPTに入れて大丈夫？」ではチャットAIに入力してよい情報の線引きを扱いました。

　第4回のテーマは、その次にくる「出力」を巡るリスクです。扱うのは（1）もっともらしい誤り（ハルシネーション）、（2）著作権、（3）資料に紛れた“見えない指示”の3つ。いずれも「そのまま採用してよいか」という一点でつながります。最後に「重要度別の確認の構え」を持ち帰れるようにします。

もっともらしいうそ――ハルシネーション

　生成AIが事実と異なる内容を、さも本当のように出力してしまう現象を「ハルシネーション」（hallucination＝幻覚）と呼びます。理由を一言でいえば、AIは正しさそのものを判断するのではなく、「それらしい続き」を確率的に選んで文章を組み立てているからです。

　OWASP（Webやアプリのセキュリティ指針を公開する国際的な非営利団体）が公開する生成AI向けのリスク一覧では、ハルシネーションは、モデルが学習データの“隙間”を統計的なパターンで埋めるために起こり、もっともらしく聞こえても根拠のない答えを出すことがあると説明されています。意味を理解して答えているのではなく、もっともらしさを優先して言葉をつないでいるため、AIは自信たっぷりに間違えることがあるのです。

　これが業務に入り込むと、一見地味でも深刻な実害につながります。実在しない判例や条文を引いてくる、製品の仕様を勝手に“盛る”、統計の数字を微妙にずらす、人名や社名を取り違える――。どれも文章としては自然なので、読んだだけでは誤りに気付けません。問題は、間違いそのものより「間違いに見えないこと」にあります。

　これは作り話ではありません。米国では2023年6月、ニューヨーク州南部地区連邦地方裁判所が、ChatGPTに頼って作成された裁判書面に実在しない判例が引用されていた件で、担当した弁護士2人と所属法律事務所に対し、連帯して5000ドルを納付するよう命じる制裁決定を出しました（Mata v. Avianca事件）。

　書面で引用された6件の判例はいずれもAIが作り出した架空のもので、もっともらしい事件名と引用文まで付いていたため、相手方が探しても見つからず、裁判所の指摘で初めて発覚しています。OWASPの生成AIリスク一覧でも、この「偽の判例」は、AIの誤情報を人がうのみにした代表例として取り上げられています。

　誤りを生むのはAIですが、それを世に出してしまうのは人です。OWASPは、ハルシネーション（誤った出力）と、それを検証せず信じ込む「過度の依存」（overreliance）が組み合わさることで、被害が大きくなると整理しています。

　AIの誤りをゼロにはできない以上、守りの要は「人がどう確かめるか」に移ります。後半の検証レベル表は、まさにこの構えを形にしたものです。

“正しそう”が会社の責任になる――出力の実害

　「AIが言ったことだから」は、対外的な言い訳になりません。海外の例ですが、ある航空会社では、自社サイトのチャットbotが遺族割引運賃の規定について誤った案内をし、それを信じた利用者が不利益を被ったとして、2024年2月、カナダ・ブリティッシュコロンビア州の民事解決審判所（少額の民事紛争を扱う準司法機関）が同社に賠償を命じました（Moffatt v. Air Canada）。

　同社は、チャットbotの回答に自社が責任を負うべきではないと主張しました。これに対し、審判所は、チャットbotを自らの言動に責任を負う別個の法的主体と見なすに等しい主張だと指摘しました。その上で、チャットbotも同社のWebサイトの一部であり、同社が掲載情報に責任を負うことに変わりはないとして、主張を退けました。

　賠償額の大小が論点ではありません。AIの出力をそのまま外に出せば、その内容は“会社が言ったこと”として扱われる――この点が、業務でAIを使う全ての場面に共通する教訓です。

　社外メールや見積書、提案書、契約まわりの回答。AIに下書きさせること自体は問題ありませんが、最終的に「これは当社の回答です」と差し出す責任は、人の側に残り続けます。

著作権・引用のリスク――“似てしまう”を避ける

　出力を巡るもう一つの注意点が、著作権です。生成AIが作った文章や画像・コードが、たまたま既存の著作物とよく似てしまうことがあります。そのまま公開・配布すると、意図せず権利を侵害してしまう可能性があります。

　日本では文化庁が「AIと著作権に関する考え方について」（2024年3月）や「AIと著作権に関するチェックリスト＆ガイダンス」（2024年7月）を公表しています。

　これらの一次資料によれば、AIの生成物が既存の著作物の権利を侵害するかどうかは、おおむね「類似性」（表現が既存の著作物と似ているか）と「依拠性」（その著作物を基に作られたといえるか）の2点から判断されるとされています。

　重要なのは、利用者が元ネタを知らなかったとしても、学習データに含まれていたなどの事情から依拠性が認められる場合があり得ると整理されている点です。「知らなかった」が必ずしも免罪符にならないと理解しておくのが安全です。

　商用利用の条件は、サービスの利用規約によっても異なります。生成物の権利の扱い、商用利用の可否、出典表示の要否などは断定せず、使うサービスの規約を都度確認することが基本です。本稿の制度・規約に関する記述は、2026年9月時点の公開情報に基づきます。いずれも改定されるため、判断時は最新版をご確認ください。

　法律問題に発展しそうなときは、社内の法務や専門家に相談してください。本連載で押さえたいのは、公開・配布する成果物ほど「似ていないか」「出典は確かか」を人がチェックするという運用の構えです。AIの出力に出典がそれらしく付いていても、それ自体がハルシネーションのことがあるため、引用は必ず原典に当たって確かめます。

資料に紛れた“見えない指示”――プロンプトインジェクション

　ここまでは、主にAIの出力そのものに含まれるリスクを見てきました。最後に、AIが外部からの“仕込み”によって意図せぬ動きをさせられるリスクに触れます。プロンプトインジェクションです。OWASPの生成AIリスク一覧では、生成AIにとって筆頭のリスク（LLM01）に位置付けられています。

　これは「AIへの指示」（プロンプト）に、攻撃者が用意した別の指示を“注入（インジェクション）”して、AIの動きを乗っ取る手口です。この手口は、AIに何をさせているかで被害の重さが変わります。第4回では、資料を読ませて要約させるような「答えるAI」の場面――つまり、誤った出力をつかまされるところまでを扱います。

　これがメール送信やファイル操作まで自分で行う「実行するAI」（エージェント）になると、仕込まれた指示通りに操作まで実行してしまいます。OWASPも2025年12月、エージェント専用の「Top 10 for Agentic Applications（2026年版）」を公開し、その筆頭に「ASI01：目的の乗っ取り（Agent Goal Hijack）」を置きました。第5回では、この「実行するAI」に固有のリスクと、どこまで任せてよいかの線引きを扱います。

　厄介なのは、その指示が利用者本人ではなく、AIに読ませる外部資料の側に仕込まれているパターン――OWASPが「間接的プロンプトインジェクション」と呼ぶものです。

　OWASPによれば、LLMがWebサイトやファイルなど外部のソースから入力を受け取ると、その外部コンテンツに埋め込まれた指示によって、AIの挙動が意図せず変えられることがあります。例として、Webページの要約をAIに頼んだところ、ページに隠された指示によって、AIが会話内容を外部へ送信するよう誘導されるシナリオが挙げられています。

　「自分はエージェントなんて使っていない、チャットで質問するだけだ」という方も無関係ではありません。外部のPDFやWebページをAIに貼り付けて「要約して」と頼む――これだけで、間接的プロンプトインジェクションの入り口になり得ます。

　OWASPも、こうした指示は人が目で読める形である必要はないと指摘しています。実際、ブラウザ開発元のBraveが2025年8月に公表した検証では、白い背景に白い文字、HTMLのコメント、画像内のほとんど見えない文字といった形で指示を仕込めることが示されました。人の目に触れない形でも仕込めるため、利用者が「怪しいことは何もしていない」つもりでも巻き込まれてしまうのです。

　これはAI開発側も認める、根の深い課題です。OpenAIは2025年11月、プロンプトインジェクションを、攻撃手法と対策が進化し続ける「フロンティアの安全課題」、すなわち現在も研究と対策が続く解決途上の課題と位置付けています。

　だからこそ、利用者側の心構えが効いてきます。難しい対策の前に、まず「出どころの不確かな資料やURLを、安易にAIへ丸ごと渡さない」という基本が、最初の備えになります。

　この手口の流れを、図にまとめました。

図1　間接的プロンプトインジェクションの流れ（出典：筆者作成。OWASP「LLM01:2025 Prompt Injection」およびOpenAIの公開見解を参考に整理）

結論は一つ――「AIの出力は下書き」

　ハルシネーションや著作権、プロンプトインジェクションは、形は違っても、対処の入り口は同じです。AIの出力は“完成品”ではなく“下書き”として扱い、最後は人が確認する。これに尽きます。

　とはいえ、全ての出力を同じ水準で確認していては仕事が回りません。大切なのは、用途のリスクに応じて確認の水準を変えることです。アイデア出しのメモなら本人がざっと見れば十分ですが、契約や公表物のように間違えると影響が大きいものは、複数人で原典に照らし合わせる。この「重要度別の検証レベル」をあらかじめ決めておけば、迷わず、抜けなく確認できます。次の表をたたき台にしてください。