7章分を、判断の道具にする

ここまで、AIの分類、実務への組み込み、DXの前提、開発、自作ツール、経営と現場のギャップ、危険性を見てきました。最後の章では、これらを実際に判断するときに使える形にまとめます。読み終えたあと何をするかまで書きます。

用途に応じた選定の判断軸

「どのAIを使えばよいか」という問いには、単独の正解がありません。代わりに、次の5つを順に決めていくと選択肢が絞られます。順序が重要です。

  1. 何を作らせるのか(第1章) ― 生成系か、認識・分類系か、予測系か。ここで候補が大きく分かれます。生成系だと思っていた作業が実は分類作業だった場合、選ぶ道具も評価方法も変わります。
  2. 間違えたときの影響はどれくらいか ― 社内メモの下書きと、請求金額の算出では、必要な確認体制が別物です。影響が大きいほど、人の確認を厚くします。
  3. 扱うデータの機密度はどれくらいか(第7章) ― 公開情報か、社内限りか、個人情報を含むか。これでクラウドかローカルかが決まります。
  4. 件数はどれくらいか(第3章) ― 月間件数から、費用の見積もりと自動化の効果が計算できます。件数が少なければ、そもそも手作業のままが合理的な場合もあります。
  5. 維持できる体制があるか(第5章) ― 変更・復旧ができる人が社内に何人いるか。ここが0人なら、規模を縮めるか外部の保守を契約する必要があります。

この5つに答えられれば、製品比較は最後の作業になります。逆に、この5つを飛ばして製品比較から始めると、選定基準が「機能の多さ」や「価格」になり、導入後に前提の不一致が発覚します。

導入前のチェックポイント

投資を決める前に確認しておく項目を挙げます。第6章で述べた「データの現状に触れていない提案」を避けるためのものです。

  • 対象データは、いまどこにどの形で存在するか ― 「作れば集まる」は前提として成立しません。
  • 対象範囲は全業務の何割か ― 精度の数値と必ずセットで確認します。
  • 人の確認を含めた合計時間はどうなるか ― ここが減らなければ効果はありません。
  • 1件あたりの費用と、月間の上限はいくらか ― 処理量課金では使用量に比例します。
  • 例外はどれくらいの割合で発生するか ― 1か月数えれば見えます(第3章)。
  • 止まったときに業務はどう回すか ― 手作業に戻せるか、戻す手順があるか。
  • 社内で変更・復旧できる人は何人か ― 事業継続の観点です。
  • 入力してよい情報の区分は決まっているか ― 3段階の区分(第7章)。

この8項目に答えられない状態で投資を決めると、着手後に前提の確認から始めることになります。逆に、答えられない項目が明確になれば、それが着手前にやるべき調査の一覧になります。

AIに任せる範囲と、人が担う範囲

線引きの原則は単純です。間違いに気づける工程を人が持つこと。これだけです。

具体的には次の3つの型になります(第2章で挙げたものと同じです)。

  • 全件を人が確認する ― 導入初期。AIは下書きを作る役。
  • 条件で振り分ける ― 金額が大きい、確信度が低い、新規の取引先。運用が安定してから移行。
  • 事後に抜き取り検査する ― 誤りの影響が小さい処理。検査結果は必ず記録する。

加えて、人が最終責任を持つ工程を明示します。「AIがそう出力したから」は、対外的にも社内的にも説明として成立しません。誰が最終的に判断したのかを記録に残す運用にしてください。

現場のシーン架空の例

三月二十七日、朝凪精機の経営企画部の瀬尾は、カスタマーサポート課で4週間の限定試行の記録をめくっていました。誤った案内の送信は0件でした。ただ、存在しない型番の仕様を書いた回答案を送信前に止めた1件は、記録の上では「使えなかった」の一つに数えられているだけでした。課長の村瀬は「何を見つけて止めたかは、どこにも残っていないのよ」と言います。瀬尾は記録を「AI案」と「担当者確認」の2列に分け、食い違ったら何が違ったかを1行書き、確かめた担当者の名前も残す形を稟議書に入れました。四月の本導入からこの形で記録を続けると、六月末の見直しでは、食い違った行を数えるだけで回答案が外れた件数とその中身が出てきました。2列に分けて記録したことが、そのまま精度の実測データになりました。

この場面は物語之巻 第8話「稟議書の最後の一行」に出てきます。

継続的な検証と運用の体制

導入して終わりにならないための最小限の仕組みを挙げます。大掛かりな体制は不要です。

  1. 月次で5つの数字を見る(第6章) ― 対象範囲の割合、確認を含む所要時間、1件あたりの費用、例外の発生率、直せる人の数。
  2. モデルの更新に気づく経路を持つ ― 使っているサービスのモデルが更新されると、出力の傾向が変わることがあります。更新の通知を受け取る担当を決めます。
  3. 出力の記録を残す ― 入力と出力を保存しておかないと、変化に気づけません。「前より悪くなった気がする」を数字で確認できる状態にします。
  4. 使わなくなったら止める ― 利用が減ったツールは、放置すると管理対象としてだけ残ります。止める条件を先に決めておきます(第5章)。
  5. 記録を更新する担当を決める ― 参照させている社内文書が古くなると、答えも古くなります(第3章)。

担当が自分ひとりの場合

ここまでの話は、法務や情報システムの部署がある前提で読めてしまいます。実際には、AIの検討を任されたのが自分ひとりで、相談できる部署がないという状況のほうが多いはずです。その場合に効く順序を書いておきます。

  • 件数の多い1業務だけに絞る ― 手を広げないことが最大の防御です。月間件数がいちばん多い業務を1つ選び、そこだけで始めます(第3章)。
  • 入力してよい情報の線引きを、自分で1枚書く ― 公開情報・社内限り・入力禁止の3段階(第7章)。承認が取れないうちは、自分の運用ルールとして持っておくだけでも事故を防げます。
  • 権限を与えない構成から始める ― 読み取りだけ、下書きだけ。送信・削除・書き込みをさせない構成なら、間違えても取り返せます(第7章)。
  • 外部の窓口を先に1つ持つ ― 顧問の税理士や弁護士、商工会議所の専門家相談、業種の団体。「相談先がない」は確認を省く理由になりません。
  • やめ方を先に決める ― 月額いくらまで、いつまでに何が起きなければ止める。ひとり体制では、これを書いておかないと止める理由を自分で作れなくなります。

逆に、ひとりだからこそ有利な点もあります。認識のずれが起きる相手がいないため、第6章のギャップの問題が発生しません。対象範囲と確認時間を自分で測れるので、判断は速くできます。

失敗を許容する運用文化

ここは制度の話です。AIの導入では、着手してみて「データが足りない」「効果が出ない」と判明する案件が一定割合で出ます。これは失敗ではなく、検証の結果です。

ところが、中止が担当者の評価を下げる組織では、中止の判断が遅れます。効果が出ていない施策が延命され、次の案件に予算が回らなくなります。第6章で触れたように、中止した理由の共有は、次の案件で最も価値のある情報です。中止を報告しても不利にならない扱いにすることが、結果として組織全体の速度を上げます。

読み終えたあとに ― 3つの持ち帰り

この8章を実際の行動に変えるために、3つだけ持ち帰ってください。

  1. 「AI」と言われたら、種類を聞く ― 生成系か、認識・分類系か、予測系か。この一言で議論の精度が変わります(第1章)。
  2. 提案を受けたら、対象範囲の割合とデータの現状を聞く ― この2つに答えられない提案は、まだ判断できる段階にありません(第6章)。
  3. 外部データを読み込む仕組みでは、AIの操作権限を確認する ― 読み取りだけで済むなら、送信・削除の権限を与えない(第7章)。

この3つは、いずれも専門知識を必要としません。AIを詳しく知らなくても、これを聞けるだけで、判断の質は実際に変わります。聞ける質問をもっと持ちたい場合は、裏之巻 第7章「罠を見破るための質問リスト・チェックリスト」に場面別の質問リストがあります。

最後に ― 使っているかどうかは評価軸ではない

AIを使っているかどうかは、それ自体では成果ではありません。評価すべきは、製品や業務がどれだけ良くなったかです。AIを使わずに手順を1つ削ったほうが効果が大きい業務も、実際に多くあります。

ここを外すと、「AIを導入した」という事実自体が目的になり、効果の検証が後回しになります。導入の是非を判断するときは、AIの有無を一度外して、「この業務の何が、どれだけ良くなるのか」だけを見てください。それが本サイトを通じての結論です。