同じ「危険性」が両方向に使われる
AIの危険性は、実態より小さく語られることもあり、大きく語られることもあります。方向は逆ですが働きは同じで、どちらも相手の検討時間を削ります。
この章の特徴は、対象が両方向にあることです。リスクを過小に見せる説明は導入を促し、過大に煽る説明は乗り換えを促します。どちらも共通しているのは、実態の確認を経ずに結論へ導くことです。
過小に見せる型
型1 ― ハルシネーションを運用の問題に矮小化する
「人が確認すれば問題ありません」という説明は、部分的に正しく、しかし不十分です。表の第18章で述べたとおり、確認は続けるうちに形式的になり、そして根拠が示されない出力の確認は実質的に行えません。
確認すべき点を挙げます。
- 根拠がない場合の振る舞い ― 「わからない」と答える設定があるか。なければ推測で答えます(第2章)。
- 出典の表示 ― 判断者が原文を確認できるか。
- 確認工程の設計 ― 誰が、何を、どれだけの時間で確認するか。
- 誤答率の実測 ― 検証セットで測った数値があるか(第14章)。
4番目が示されない場合、誤りの頻度は不明です。「精度は高いです」という説明は、測った結果ではなく印象である可能性があります。
型2 ― 知識の鮮度の問題を伏せる
表の第18章で扱った論点です。モデルは学習時点以降を原理的に知りません。この性質が説明から落ちると、法令・仕様・バージョンに関する回答が現行のものとして扱われます。
確認は次の2問です。
- 「このモデルの知識はいつ時点までですか」 ― モデルカードに記載があるのが一般的です(表の網羅版 第3章「主要AIサービス・モデルの比較」)。
- 「それ以降の情報が必要な場合、どう渡しますか」 ― RAGや検索連携の必要性がここで決まります。
型3 ― セキュリティの説明を「安全です」で済ませる
セキュリティについて具体的な説明がなく、結論だけが示される型です。表の網羅版 第21章「セキュリティ」の確認項目のうち、最低限の2問を挙げます。
- 「この仕組みは外部から来たデータを処理しますか」 ― 該当すれば間接型プロンプトインジェクションの対象です。
- 「AIに与えている操作権限は何ですか」 ― 読み取り・書き込み・送信・削除・実行。
両方が該当する場合(外部データを処理し、操作権限がある)、その仕組みは高リスクです。「安全です」という説明ではなく、承認の工程と権限の分離が示される必要があります(第21章)。
型4 ― 出力の非決定性を伏せる
同じ入力に同じ出力が返らないという性質は、業務設計の前提になります(表の第18章)。この性質が説明されないと、次の問題が稼働後に現れます。
- 「先週はこう出たのに」という差異が、不具合として報告される
- 出力形式が揺れ、後続の処理が失敗する
- 1回の動作確認で検収を通してしまう
- 重要な判断に使う設計になっている
確認は「同じ入力で複数回実行した結果を見せてもらえますか」です。3〜5回の結果が示されれば、振れ幅が分かります(第14章)。
過大に煽る型
型5 ― 危険性を強調して乗り換えを迫る
他社製品や現行の運用の危険性を強調し、自社サービスへの移行を促す型です。指摘されている危険性が実在する場合もあるため、指摘の妥当性と、提案されている対処の妥当性を別に評価する必要があります。
| 順 | 確認すること |
|---|---|
| 1 | 指摘されている危険性は、自社の用途に当てはまるか(用途によって該当しない場合がある) |
| 2 | その危険性は、現行の構成でどの程度の確率・影響で生じるか |
| 3 | 提案されている対処は、その危険性に対応しているか |
| 4 | 同じ対処を、現行の構成のまま実施できないか |
| 5 | 移行に伴う費用と作業は、その危険性の低減に見合うか |
4番目が重要です。指摘された危険性への対処が、設定変更や運用の追加で済む場合があります。権限の縮小、承認工程の追加、ログの記録、確認の型の変更。いずれも移行を伴わずに実施できます。
型6 ― 規制リスクを誇張する
法規制への対応が必要であることを根拠に、特定の製品やサービスへの移行が促される型です。規制の存在は事実である場合が多いため、確認すべきは自社への適用範囲です。
表の網羅版 第19章「法規制・コンプライアンス」に確認先の一覧があります。実務的な手順は次のとおりです。
- 指摘された規制の名称と、該当する条項を確認する
- 自社の用途がその適用範囲に入るかを、所管の公表情報で確認する
- 入る場合、求められる対応の内容を確認する
- その対応が、提案されている製品でなければ実施できないかを確認する
4番目が判断の核心です。規制対応が製品の購入によってのみ達成されることは、通常ありません。記録を残す、根拠を示せる設計にする、判断者を明示する。これらは構成に依存しない対応です(表の網羅版 第20章「AI倫理とバイアス」)。
危険性を根拠に判断を急がされた場合、「その危険性が実際に生じた場合、どういう影響がどの範囲に出ますか」と確認してください。影響の範囲と大きさが具体的に説明されれば、それは対処の優先順位を決める材料になります。「重大な問題になり得ます」という水準で止まる場合、リスクの評価ができていません。加えて「その対処は、現在の構成のままで実施できませんか」を必ず確認してください。
両方向に共通する対処
過小・過大のいずれに対しても、同じ確認が効きます。危険性を評価する枠組みを自社で持つことです。
表の第18章の対応表に対応する形で、自社の用途について次を整理しておきます。
| 危険性 | 自社の用途で該当するか | 現行の対処 |
|---|---|---|
| ハルシネーション | 生成系を使うか | 根拠がない場合の振る舞い、出典表示、確認工程 |
| 知識の鮮度 | 変化する情報を扱うか | 一次情報を渡す設計、知識の時点の把握 |
| 機密情報の流出 | 社外にデータを送るか | 3段階の区分、送信範囲の限定、権限 |
| 間接型プロンプトインジェクション | 外部データを処理し、操作権限があるか | 権限の最小化、人による承認、処理の分離 |
| 非決定性 | 出力を後続処理に渡すか | 形式の固定、複数回の検証 |
| バイアス | 人に対する判断に使うか | 属性ごとの集計と記録 |
| 著作権 | 生成物を社外に出すか | 類似の確認工程、法務の確認 |
この表を持っていると、指摘を受けたときの評価が具体的になります。該当する行があれば現行の対処と比べ、該当しない行であればその指摘は自社の判断材料になりません。
二年目の三月四日、朝凪精機のCS課が前日に送った回答メールに、社内手順書の一節が入っていたと分かりました。その日の夕方、来社したクラウゼル・テクノロジーズの黒江営業部長は「重大インシデント」だとして、問い合わせ対応ごと自社のセキュア版へ移るよう勧めます。AI推進室の瀬尾室長代理は、影響の範囲を出すまで2日をもらいます。確かめると、指摘に当たるのは回答案づくりと社内文書検索のつなぎ目の1か所で、送信権限は付与されていませんでした。二月中旬につないだとき、外の文面を読む処理と社内文書を検索する処理を1つにしていたのです。指摘された危険性への対処として必要だったのは、その1か所で2つの処理を分け、顧客からの受領資料を検索対象の領域から外すことであり、移行は不要でした。確認に要したのは半日でした。
この場面は網羅物語之巻 第14章「小さな事故」に出てきます。
この章の確認質問
過小・過大の両方に使える質問を並べます。
- 「誤答率は、どの検証で測った数値ですか」 ― 印象ではなく実測か。
- 「根拠がない場合、どう振る舞いますか」 ― 推測で答える設定になっていないか。
- 「このモデルの知識はいつ時点までですか」
- 「外部から来たデータを処理しますか。操作権限は何ですか」 ― 両方該当すれば高リスク。
- 「同じ入力で複数回実行した結果を見せてもらえますか」 ― 振れ幅の確認。
- 「その危険性が生じた場合、どういう影響がどの範囲に出ますか」 ― 過大な煽りの検証。
- 「その対処は、現在の構成のままで実施できませんか」 ― 移行の必要性の検証。
6番目と7番目は、過大な煽りに対する標準的な確認です。この2問に具体的に答えられる指摘は、対処の優先順位を決める有用な情報になります。