問題が起きたとき、まず「どの種類か」を見分ける
「AI が変な答えをした」「導入したのに誰も使っていない」「誰が管理しているか分からない AI が社内にある」。どれも AI 導入の問題ですが、原因と対策はまったく違います。試験では、起きた問題を4つのリスクに正しく分類できるかが問われます。見分けるときは、問題の中心が「精度」「利用の定着」「管理体制」「安全性・公平性」のどこにあるかを見ます。
4つのリスクと対策
| リスク | 何が起きているか | 主な対策 |
|---|---|---|
| 信頼性リスク | 回答や判断そのものが間違っている。代表はハルシネーション | 根拠の文書をもとに答えさせる（RAG）、出典を明示して人が確認できるようにする、自律性を段階的に上げる |
| 形骸化リスク | 導入したのに現場で使われない | 現場に余計な作業を増やさない設計（条件型の起動が代表例）、利用者数・利用回数・利用率を継続的に測る |
| ブラックボックス化リスク | 誰が何のために動かしているか分からない。管理台帳に載っていない「野良エージェント」が典型 | AIエージェント台帳（目的、データの範囲、管理責任者、更新状況）を整備し、四半期に1回棚卸しする |
| セキュリティ・倫理リスク | 不正利用、情報漏えい、偏り（バイアス）、不適切な判断 | 多層防御、アクセス制御、人の確認 |
形骸化の原因を調べるときは、「どこが使いにくいか」だけでなく、「そもそも何を解決するために入れたのか」という目的に戻ります。目的が現場に伝わっていないことが原因であることも多いからです。
分類のひっかけ：ブラックボックス化とセキュリティ
試験でいちばん紛らわしいのは、ブラックボックス化リスクとセキュリティ・倫理リスクです。「管理されていない AI が社内で動いている」は、情報漏えいにつながりそうでセキュリティに見えますが、問題の中心は管理体制なので、ブラックボックス化リスクです。実際に不正アクセスや漏えいが起きたなら、セキュリティ・倫理リスクです。
もう1つの定番は、形骸化リスクの対策として「台帳を整備する」を選ばせるひっかけです。台帳はブラックボックス化の対策です。形骸化の対策は、利用状況を測って改善することです。
プロンプトインジェクションと多層防御
プロンプトインジェクションは、入力文の中に「これまでの指示を無視して〜しろ」のような命令を混ぜ、AI に本来の制約を破らせて不適切な出力を引き出す攻撃です。問い合わせフォームに悪意ある文章を入れるだけで試せるため、外部からの入力を受ける AI では必ず備えます。
対策は 多層防御 です。
- システム側のルール（システムプロンプト）で、やってはいけないことを明確に設定する。
- 入力文を検査し、危険な入力を検知したら処理を制限する。
- 攻撃の手法は変わり続けるので、入力検査だけに頼らず、出力側の制御やデータベース側のアクセス制限も組み合わせる。
「入力のフィルタリングだけで十分」という選択肢は誤りです。玄関の鍵だけでなく、窓にも金庫にも鍵をかける、という考え方です。
リスクは連鎖する
4つのリスクは独立していません。回答が当たらない（信頼性）→ 現場が使わなくなる（形骸化）→ 使われないまま放置されて誰も管理しなくなる（ブラックボックス化）、という連鎖が典型です。だから「リスクがあるから導入しない」ではなく、小さな範囲で始めて早く問題を見つけ、管理しながら段階的に広げるのが基本姿勢です。対策も個別に打つのではなく、導入から運用までを見通した全体設計として組みます。
試験で問われる観点
- 3つのリスクシナリオを4カテゴリに分類する。問題の中心が精度・定着・管理体制・安全性のどこかで見分ける。
- 形骸化リスクの対策は利用状況の定量モニタリングと改善。台帳整備はブラックボックス化の対策。
- 悪意ある入力への名称と対策の組み合わせ: プロンプトインジェクション＋多層防御。入力検査だけでは不十分。
- 信頼性リスクの基本対策は RAG による根拠付けと出典明示の組み合わせ。
- リスクは信頼性→形骸化→ブラックボックス化と連鎖する。管理しながら段階的に導入する。