第0章 お試しの壁（PoCの死の谷）——実験で終わらせず、本番の仕事で使うための手順
対象＝中小企業の経営者・役員・現場リーダー。 「テレビやネットを見てAIを試してみたが、結局おもちゃで終わり、日々の仕事には使えなかった」という挫折を防ぎ、社内の承認（稟議）を通して実際の業務に安全に組み込むための実践手順書です。 ※本章は導入の考え方を示すもので、特定ツールの機能提供宣言や、効果の絶対保証、税務・法律上の助言ではありません。
1. 全体の流れ：本番の仕事に使うまでの6つの手順
- 「なぜ立ち消えになるのか」失敗パターンを知る
後述する「よくある失敗表」を見て、自社が当てはまりそうな落とし穴を事前に確認します。ツールの比較を始める前に、「なぜ導入が止まるのか」の共通認識を社内で揃えます。 - 対象にする仕事を「たった1つの小さな作業」に絞る
「入口（どんな書類やデータが届くか）」→「処理（AIが下調べ・下書き）」→「出口（何が確定するか）」→「例外（人間が直接見るケース）」をA4用紙1枚にまとめます。「全社で一斉に導入」「複数の部署を同時に変える」は失敗の最大の原因となるため禁止します。 - お試し（デモ）と実際の仕事（本番）の違いを赤字で洗い出す
社員のアクセス権限、誰が最後にハンコを押すか、操作履歴の記録（監査ログ）、外部送信の有無、個人情報の扱い、効果の測り方——「お試しの画面」では見落とされがちな本番の必須項目を箇条書きにします。 - 人の最終チェック担当（Human Approval Gate / 承認者）を実名で決める
「誰が内容を確認し、社外送信や台帳登録の許可を出すか」を担当者と代行者の「個人名」で確定します。担当者が休みのときのルールも決め、「誰も見ていないのにAIが勝手に送信する」事態を絶対に防ぎます。 - A4用紙1枚の導入企画書（稟議書）を埋める
①目的／②対象にする1つの作業／③見込める効果（仮説・要実測）／④危険と緊急停止の仕組み／⑤人の確認体制——この5項目を埋めてから、具体的なツールの選定に入ります。 - 全員一致で「本番開始（Go/No-Go）」を判定する
後述のチェックリストがすべて「合格」になるまでは、本物の顧客データを入れたり、取引先へ自動送信したりしてはいけません。「今回はまだ見送る（No-Go）」という判断も、会社を守る立派な成果として記録します。
業界別の具体的な業務手順や事例は、画面上部の「導入ロードマップ」または「業界別ライブラリ」をご覧ください。
2. チェックリスト（お試しの成功 ≠ 実際の業務で使える）
3. よくある失敗パターン（中小企業の現場あるある）
| # | 失敗パターン | 現場で起きるトラブル | 先にやっておくべき解決策 |
|---|---|---|---|
| A | 欲張って範囲を広げすぎる | 「ついでにあの業務も」と手を広げ、例外が多すぎて誰も責任を持てなくなる | たった1つの定型作業（1循環）だけに絞る |
| B | 効果の測り方を決めていない | デモを見て「AIってすごいね」で終わり。役員会で「結局いくら儲かるの？」と聞かれて止まる | 「何分短縮できそうか（仮説）」を紙1枚に数字で書く |
| C | 例外のルールを決めていない | 普段と違う書類が来るたびに現場リーダーの机に山積みになり、仕事が麻痺する | 「金額が○万円以上」「初めての取引先」など人の確認条件を箇条書きにする |
| D | 誰が責任を持つか曖昧 | 「みんなで確認しよう」とした結果、誰も見ずに放置され誤送信が起きる | 最終確認をする社員の「実名」と代行者を決める |
| E | 情シスやセキュリティを後回し | いざ本番導入の直前で「セキュリティや権限が不安」と止められ、すべて白紙に戻る | 計画の初期段階でIT担当や管理部門に相談し、ルールを作る |
| F | 記録（ログ）を残していない | 後から税務調査や取引先から聞かれても、「なぜその数字になったか」説明できない | 承認履歴（Audit Trail）の保存と、AI学習への流用防止（ZDR）を確認する |
| G | ツール選びが先走る | 各社ツールのパンフレット集めに熱中し、自社の業務のどこを削るかが決まっていない | 企画書（稟議書）の骨子を先に作り、それに合う道具を選ぶ |
| H | 効果を過大に断定してしまう | 「人件費が必ず3割減ります」と大風呂敷を広げ、現場の反発や経営陣の不信を買う | 「まずは仮説として検証し、実測して見直す」と合意をとる |
4. 効果はどう測るか（効果の保証ではなく「仮説・要実測」）
「必ず人件費が削減できる」といった甘い言葉は禁物です。導入前後の実績をストップウォッチや日報で計測し、続けるかやめるかの客観的な判断材料にします。
| 測定する項目 | 最初の仮説の立て方（例） | 実際の測定方法 | 注意点 |
|---|---|---|---|
| 1件あたりの作業時間 | 「現在1件15分 $\rightarrow$ AI下書き導入で5分に短縮（仮説）」 | 導入前後2週間の作業時間を日報で記録 | 社員の「なんとなく楽になった」という体感だけで判断しない |
| 手戻り・やり直しの件数 | 「事前のAIチェックにより入力ミスが半減する（仮説）」 | やり直しになった理由をメモして集計 | 減っていなければ、AIへの指示文や業務の切り方を見直す |
| 人間が直接確認した割合（例外率） | 「全体の8割は定型、2割が要確認（仮説）」 | 人間の確認が必要だった件数を数える | 要確認が多すぎるなら、仕事の切り出し方が広すぎる証拠 |
| 承認待ちの滞留時間 | 「月末の締め日に遅れず処理できるか」 | 担当者の確認トレイに何時間溜まっているか | ボトルネックになっているなら、代行者を増やす |
| 重大トラブルの発生数 | 「誤送信・情報漏洩・誤請求 0件」 | 軽微なヒヤリハットも含めて即時共有 | 1件でも重大インシデントがあれば即座に一時停止を検討 |
5. 誰がハンコを押すか（必ず人が確認する仕組み / 役割分担）
AIは極めて優秀な「下書き作成アシスタント（新入社員）」です。会社の名前で社外へ連絡したり、お金を動かしたりする「最終決定権」は絶対に人間に残します（Human Approval Gate / HITL）。
| 社内の役割 | この人が決めること・責任 | 止められる権限 |
|---|---|---|
| 社長・役員（経営責任者） | 導入の目的、予算の上限、撤退基準（中止条件） | 計画の中止、予算の凍結 |
| 現場責任者（部門長・リーダー） | 業務のルール、日常の承認・差し戻しの判断 | 当該業務の確定操作、現場での利用停止 |
| IT担当・セキュリティ担当 | アクセス権限、ログの管理、料金リミッター（Token Capping） | システム接続の遮断、社外送信の技術的制限 |
| 確認代行者 | 担当者が不在時の確認（あらかじめ決められた範囲内） | 迷った案件は現場責任者へエスカレーション |
| AIエージェント | 資料の下調べ、下書き作成、入力ミスの指摘 | 社外送信や金額確定の権限は一切持たせない |
現場が慣れて作業がスムーズになっても、「人の確認（Human Approval Gate）」を外して全自動化してはいけません。
6. 部門別ミニケース——お試しは成功したのに、なぜ本番でコケたのか
営業部門：商談後のお礼・提案メール下書きの失敗例
現状の課題
営業担当のAさんは週に10件ほど、商談後のフォローメールを手作業で書いています。顧客管理画面（CRM）のメモとExcelの単価表を見比べながら、顧客の名前や要望に合わせた提案文を作るため、毎回30分以上かかっていました。 お試し導入では「お客様の名前と商談内容を入れると、驚くほど丁寧なお礼メールが一瞬で完成」し、営業部内は大盛り上がりでした。 しかし役員会議で、「誰が最終確認して送るのか」「勝手に過度な値引き提案を書いて送ったらどうするのか」が未解決だと指摘され、導入はストップ。営業現場は「せっかく便利そうだったのに…」と落胆しました。
本番で使うための安全な手順
- AIの役割：顧客の要望メモと過去の安全な送信例から、メールの下書きを1〜2案作成する。
- 営業担当者の確認：事実関係、納期、金額が正しいか、人間の目で赤入れして修正する。
- 承認関所（Human Approval Gate）：修正した文面を確認し、「送信許可」ボタンを押す（許可が出るまで送信ボタンは押せない）。
- 記録：送信した最終文面と、確認した担当者名・日時を履歴として保存する。
- 例外：通常と異なる特別値引きや他社比較が含まれる場合は、必ず営業課長へ事前相談する。
承認ルール
- 通常の確認者：担当営業本人（実名）。
- 特別値引き・重要案件：営業課長または営業部長。
- 担当者不在時：課長が代行。確認されないまま時間が経っても「自動送信」は絶対にしない。
明日すぐできること
- 「お試しの画面」と「実際の運用」で足りない点（送信ボタンの制御、履歴の残し方）を紙に書き出す。
- 測定指標を「メール作成時間」と「誤送信0件」の2つに絞る。
- 顧客リスト全体をAIに読み込ませず、学習利用防止（ZDR）が明記されたプランを使う。
総務部門：社内規程の問い合わせ回答ボットの失敗例
現状の課題
総務のBさんは、全社員から「在宅勤務は何日まで可能？」「慶弔休暇の申請方法は？」といった問い合わせを毎日受けています。PDFの就業規則をいちいち開いて探すのに手間取っていました。 テストで導入したAIチャットは、社内規程を読み込ませるとスラスラ回答し、現場の評判も上々でした。 しかし、ある社員が「私の有給の残り日数は？」「休職手当はいくら出る？」と個人的な相談を入力した際、個人情報の取り扱いや給与データへのアクセス範囲が整理されていなかったため、管理部門から「情報管理の観点で危険すぎる」とストップがかかりました。
本番で使うための安全な手順
- AIの役割：社内で公開されている就業規則や一般的なFAQだけを元に、回答の下書きを作る。
- 総務担当者の確認：回答の根拠となった規程のページ番号を確認し、問題なければ社員に伝える。
- 個人の事情は人へ転送：給与、有給残日数、家庭の事情、メンタルヘルス等が含まれる場合は、AIではなく総務担当者が直接個別に対応する。
- 記録：どの規程に基づいて回答したかを記録に残す。
- 社員の個人情報（氏名、給与、健診結果など）はAIの入力画面に貼り付けないことを社内周知する。
承認ルール
- 通常の確認者：総務担当者。
- 人事・個別相談：総務課長または人事担当役員へ直接回送。
明日すぐできること
- 「全員に公開されている規程の質問」だけに対象を限定した業務フロー図を作る。
- 「個人情報は絶対に入力しない」という注意書きを利用画面の先頭に明記する。
経理部門：請求書の突合・仕訳候補出しの失敗例
現状の課題
経理のCさんは毎月末、届いた請求書PDFと社内の発注データを突き合わせて確認しています。月100枚前後の書類を目視でチェックし、会計ソフトに入力する作業は毎月の大きな負担でした。 デモでは「請求書を読み取ると、会計ソフトの科目候補が自動で表示される」ところまで成功しました。 しかし、軽減税率や値引き、端数処理の例外に対応するルールがなく、締め日の忙しい時期に「結局人間が全件検算しないと怖くて振込指示が出せない」となり、現場で使われなくなってしまいました。
本番で使うための安全な手順
- AIの役割：請求書PDFから会社名、金額、税率を読み取り、発注データとのズレがないか下調べして一覧表示する。
- 経理担当者の確認：AIが見つけた「発注書と金額が一致しない部分」や「新規取引先」だけを重点的に目視確認する。
- 承認関所（Human Approval Gate）：通常の請求書は担当者が承認。支払確定や高額案件は経理課長が最終承認する。
- 確定：人間の承認印（電子承認）が出て初めて、会計ソフトの確定仕訳や銀行振込リストへ送られる。
- 操作履歴（Audit Trail）：どの請求書を誰がいつ承認したかの証拠を電子帳簿保存法に沿って保管する。
承認ルール
- 通常の突合確認：経理担当者。
- 支払確定・例外処理：経理課長または経理部長。
- 担当者不在時：自動承認は禁止（必ず代行責任者が目視確認）。
明日すぐできること
- 「複数税率」「値引き」「初めての取引先」など、AIが迷いやすい例外パターンを紙に書き出しておく。
- 測定指標を「請求書1枚あたりの下調べ時間」と「入力ミスの件数」に絞って稟議書を作る。
- 取引先情報がAIの再学習に勝手に使われない法人向け契約（ZDR）であることを確認する。
会社を守るコンプライアンスの基本原則
本章でご紹介した手順は、無理のない安全な社内導入を進めるための考え方です。特定ツールの効果を保証するものではなく、法律・税務・投資上の正式な助言ではありません。各社ごとの法規制や社内規程に沿って、最後は経営者ご自身の責任においてご判断ください。
本章で参照している公的ガイドライン・引用ID
本書の手順は、以下の公的機関・国際機関のフレームワークの考え方に準拠しています。
METI-AI-GL-1.2（経済産業省・総務省「AI事業者ガイドライン」）NIST-AI-RMF-1.0（米国国立標準技術研究所 AIリスクマネジメントフレームワーク）HITL-SURVEY-WU-2022（人間参加型AI / Human-in-the-loop 運用調査）CAO-AI-STRATEGY-2022（内閣府 AI戦略）
次章への案内
自社が陥りがちな失敗パターンを把握できたら、次は実際の仕事をAIと人間に分けるステップです。 → 第1章「業務プロセスの解体」へ進み、仕事を「入力・判断・例外・確定・記録」の5段階に分けて、無理のない導入範囲を決めましょう。