正しいだけでは、伝わらない
AI 導入を進めると、社内のあちこちから厳しい問いが飛んできます。この節で扱うのは、その中でも AI 導入に特有で、答えられずにプロジェクトが止まりがちな5つです。試験で問われるのは、内容は間違っていないが相手に伝わらない答えと、正確でありながら相手に伝わる答えを区別できることです。共通するコツは、「大丈夫です」と断言しないこと、比較対象を「完璧」ではなく「現状」に置くこと、そして相手を「一緒に確認する仲間」として巻き込むことです。
問い1 「AI は間違えるのではないか」
経営層からも現場からも最も多く出る問いです。まず事実として、AI は間違えます。同じ入力に常に同じ出力を返すとは限らず、ハルシネーションも起きます。従来の IT システムは「同じ入力なら同じ結果」が前提でしたが、AI は一定の揺らぎを前提に設計・運用する必要があります。
ここで必要なのは「間違えるから使えない」ではなく、**「間違え方を設計する」**という発想の転換です。3点セットで説明します。
- 間違えてもリカバリーできる業務から導入する（低リスク業務の選定）。
- 間違いを人が検出できる仕組みを組み込む（Human-in-the-Loop）。
- 間違いの頻度を数値で測り、許容範囲内かを判断する。
伝わる言い方の例: 「AI は間違えます。ただし人も間違えます。いまの契約書レビューの指摘漏れ率は 5% です。AI の漏れ率を 1% 未満に抑え、かつ担当者が最終確認する仕組みを入れれば、現状より安全になります」。比較対象を「完璧」ではなく「現状の人のミス率」にすると、議論が建設的になります。
試験では「最新の LLM は高精度なので問題ない」「精度保証はベンダーの責任」「100% にならないので見送るべき」がすべて誤りで、「精度は保証できない。まず小規模な PoC で測定し、その結果で判断してもらう」が正解になります。
問い2 「デモではうまく動いたが、本番でも同じ品質が出るのか」
デモは想定したデータと典型的な場面で動かすので、品質が出やすい。本番ではデータのばらつき、例外、想定外の使い方が加わるので、同じ品質がそのまま再現されるとは限りません。
だから「デモどおり本番でも動きます」と断定してはいけません。本番で期待との差が出たとき「事前の説明と違う」と受け止められ、信頼を失います。適切な答え方は、デモと本番の間には差があり、その差を確認するために PoC を行うと説明することです。あわせて、PoC は必ず成功しなければならない工程ではないことを経営層に事前に理解してもらいます。期待を下回る結果が出ても、「この方法では足りない」「別の条件が必要」と本番前に分かったこと自体が重要な知見です。
伝わる言い方の例: 「デモは理想的な条件で動かしています。本番では想定外のデータが来るので、まず 50 件で検証し、精度を測ってから判断しましょう。2週間あれば結論が出ます」。検証の件数と期間を具体的に示すことで信頼が生まれます。
問い3 「自社データを入れても問題はないのか」
IT 部門と法務部門から必ず出ます。多くの推進者がここで答えきれず、プロジェクトが止まります。回答の核心は 「何のデータを、どこに、どう渡すかを設計で制御できる」 と説明することです。実務的なポイントは3つです。
- LLM に渡す前に個人情報や機密をマスキングする前処理を設計できる。
- クラウドの API に送るか、自社サーバー（オンプレミス）で処理するかを選べる。
- 送信したデータがモデルの学習に使われるかどうかは、契約と設定で制御できる。
伝わる言い方の例: 「契約書の条項の文面と契約種別は AI に渡しますが、取引先名と金額、担当者の個人情報はマスキングして渡しません。API の契約上、送信データはモデルの学習に使われない設定です。この設計を IT 部門と一緒にレビューしたいのですが、いかがでしょうか」。何を渡し、何を渡さないかを具体的に示し、一緒に確認しようと持ちかけるのがポイントです。「大手クラウドなので問題ありません」と断言するのは懸念に正面から答えておらず、「オンプレミスなら問題は存在しない」も、オンプレミスにも別のリスクがあるので不正確です。
問い4 「投資対効果（ROI）は見込めるのか」
経営層から必ず問われます。ただし AI の ROI は従来の IT 投資より試算が難しい。出力の品質や業務への適合度は、PoC をしてみないと確定しない部分が多いからです。「やってみなければ分からない」とだけ答えるのも、不確実な数字を確定値のように示すのも、どちらも不適切です。
正解は 前提条件付きで ROI を試算し、その前提が成り立つかを PoC で検証する という形で示すことです。
伝わる言い方の例: 「確定した ROI は現時点では算出できません。ただし、標準的な契約の 70% を AI が一次レビューできれば、年間約 400 万円の工数削減になります。この前提が正しいかを 50 件の PoC で検証します。PoC 費用は 50 万円、期間は1か月です。結果を見てから本格投資を判断いただけませんか」。大きな予算をいきなり求めず、小さな検証費用で判断材料を提供するのが予算獲得の鉄則です。50 万円の意思決定と 400 万円の意思決定では、ハードルがまったく違います。
問い5 「責任は誰が負うのか」
法務だけでなく、現場からも強く意識される問いです。「AI の判断を使った結果なのに、なぜ自分が責任を負うのか」という不安は、抵抗につながります。
原則は、AIエージェント自体に法的・実務上の責任主体としての地位はないことです。問題が起きても AI に責任を帰属させることはできません。だから導入前に、誰がどの判断を担い、どの段階で責任を負うのかを明確にします。
ただし「最終的にはすべて人の責任」とだけ伝えると、現場の抵抗が強まります。実務では、人がどの時点で関与し、何を確認するのかを含めて責任構造を設計します。その代表が Human-in-the-Loop です。AI の出力がそのまま確定するのではなく、人が確認・承認してから実行される設計なら、責任構造は従来の業務における確認・承認の仕組みに近い形で整理できます。
責任は一人に集中させず、役割ごとに分けます。判断基準やルールの設計に誤りがあれば設計側、確認すべき内容を見逃したなら承認者、導入の方針や許容リスクの設定は経営側、という分け方です。
伝わる言い方の例: 「AI は指摘案を出しますが、そのまま確定するわけではありません。あなたが確認して承認したうえで相手先に返します。最終判断は人が担うので、責任構造はいまの業務と同じです。ゼロから条項を読んでいた作業が、AI の下書きを確認する作業に変わるだけです」。試験では「責任はベンダーが負う」「AI は間違えないので責任の問題は発生しない」「責任はすべて経営層にある」がすべて誤りです。
試験で問われる観点
- 「精度は保証できるか」への最も適切な回答（保証はできない。小規模な PoC で測定し、結果で判断してもらう）。
- 「クラウドに送って漏えいのリスクはないか」への対応（送るデータと送らないデータを具体的に示し、IT 部門と一緒にレビューする場を設ける）。
- 「AI が間違えたら私の責任か」への回答（人が確認・承認するフローなので責任構造は今の業務と同じ）。
- ROI は前提条件付きで示し、前提の成立を PoC で検証する。小さな検証費用の判断を求める。
- 比較対象は「完璧」ではなく「現状の人のミス率」。断言せず、検証の件数と期間を具体的に示す。