Article 006
中小企業の生成AI導入ロードマップ：30日でPoC→最小運用まで（0/7/14/30日）
生成AIを『入れたい』が先行すると、PoCはできても運用に乗らず止まりがちです。0/7/14/30日で最小運用へ到達するために、先に固定すべき前提と手順を整理します。
この記事の前提（重要）
この記事の『30日で運用』は、全社展開や完全自動化ではありません。対象業務を1つに絞り、ガード＋評価＋運用の習慣が回り始める『最小運用』まで到達することを指します。
PoCの成否は、モデル選定より『仕事の設計』で決まります。データの線引き、権限、監査ログ、評価指標を、後で困らない最小構成で先に固定します。
- 対象業務は1つに絞る（最小運用の前提）
- データの線引き（入力禁止）を先に文章化する
- PoCの評価指標を本番モニタリングへ接続する
- 規格/フレームワークは『参照点』として使う（作業を増やさない）
0日目：目的・対象業務・成功指標・責任分界を決める（ここが勝負）
30日ロードマップの成否は、0日目にほぼ決まります。ここで決めるのはツールではなく『仕事の設計』です。
対象業務を1つに絞り、成功指標を『業務KPI + リスクKPI』で置き、責任分界（RACIの超ミニ版）と、入力禁止ルールを先に固定します。
- 対象業務: 問い合わせ一次回答/議事録→要約→タスク化/社内文書検索など（まず1つ）
- 業務KPI: 工数削減、一次解決率、レビュー時間など
- リスクKPI: 誤回答率上限、禁止入力違反件数、想定外共有（ゼロ）
- 最小RACI: 事業オーナー/運用責任者/技術担当（兼務OK）
7日目：PoCの設計（評価セットとログ）を作る
PoCは『できるか』ではなく『価値が出るか』を判定するフェーズです。評価セット（代表ケース）を固定し、同条件で比較できる状態にします。
同時に、入力データの線引きとログ（入力/出力/人の判断）を設計します。ログがないPoCは再現性がなく、本番に接続できません。
- 評価セット: 10〜30ケース（成功ケース＋失敗しやすいケース）
- ログ: 入力/出力/採用可否/理由（最低限）
- 変更履歴: プロンプト/手順の更新履歴を残す
14日目：守れる本番へ（データ・権限・監査・例外）
本番で詰まりやすいのは生成品質ではなく『守り（ガード）』です。用途別の権限、監査ログ、禁止入力、例外時のエスカレーションを先に固めます。
例外（不確実/根拠なし/曖昧）の扱いを決めることが運用を守ります。『答えないで人に回す』を許容できる設計が重要です。
- データ: 入力してよい/ダメ、保存期間、マスキング方針
- 権限: 最小権限、用途別権限、実行者の個別ID、監査ログ
- 例外: 自信がない時は回答しない/人に回す/保留する
30日目：最小運用を回す（効果・品質・コスト・事故）
最小運用の成功は『定例の棚卸し』で決まります。効果だけでなく、コストと事故（誤案内/情報漏えいリスク/監査不可）を同時に見ます。
運用の基本は、ログの蓄積と改善サイクル（週次/月次）です。ログがないと改善できません。
- 週次: 成功/失敗ケースのレビューと改善
- 月次: KPI（工数/品質/コスト）と継続判断
- 事故時: 影響範囲→原因→再発防止（入力制限/権限/レビュー強化）
補足：規格/原則を『参照点』として使う
規格やフレームワークは『守ればOK』ではなく、迷ったときの判断軸（参照点）として置きます。SMBが実装できる最小統制へ翻訳するのが現実的です。
- AIリスクの考え方: NIST AI RMF / NIST GenAI Profile
- プライバシー: NIST Privacy Framework / PPC / APPI（e-Gov）
- マネジメント参照点: ISO/IEC 42001 / 用語: ISO/IEC 22989 / リスク: ISO/IEC 23894
- LLM特有リスク: OWASP Top 10 for LLM Applications
参考文献/出典
本記事は、一次情報（公式ドキュメント/標準/公的/公式）へのリンクを参考として付記します。