AI導入チェックリスト

目的/戦略

「何を良くしたいか」を先に固定しないと、PoCが迷走しやすくなります。

導入目的（業務課題）を1文で言える

例：問い合わせ対応の一次回答を高速化、議事録作成の工数削減など。

目的

対象業務の範囲（入力→処理→出力）を定義した

どこまでAIが担当し、どこから人がレビューするかを明確化。

範囲

「やらないこと」（禁止・除外）を決めた

例：契約判断、医療/法務の確定回答、機密の外部送信など。

制約

ステークホルダー（利用部署/責任者）を決めた

誰が意思決定し、誰が運用するか（責任の所在）を整理。

体制

PoCの成功条件（KPI）を事前に設定した

例：回答時間、一次解決率、工数、品質（レビュー合格率）など。

KPI

運用後の改善サイクル（更新頻度・責任者）を決めた

モデル/プロンプト/ナレッジ更新、品質レビューのリズムを設計。

改善

データ

AIの性能はデータと設計で大きく変わります。RAGを使うなら特に重要です。

参照させたい情報（FAQ/マニュアル等）を棚卸しした

社内規程、ナレッジ、製品資料など、出典となる情報を整理。

棚卸し

データの更新頻度と「正本」を決めた

どのドキュメントが最新か、更新担当、改定履歴の管理。

更新

機密・個人情報の含有を確認した

PII/社外秘が混ざる場合はマスキングやアクセス制御が必要。

確認

RAG用の分割（チャンク）方針を決めた

章/見出し単位、メタデータ（カテゴリ・日付・版）付与など。

RAG

出典リンク（参照元）を表示できる設計にした

「どこから答えたか」が見えると運用での信頼性が上がります。

出典

評価用の質問セット（代表Q）を用意した

現場のよくある質問・難問・禁止領域の質問を含める。

評価

セキュリティ / ガバナンス

導入後に問題になりやすいのは「情報の扱い」と「権限」です。

入力してはいけない情報（禁止事項）を明文化した

個人情報、社外秘、顧客データ等の取り扱いルールを作る。

ルール

アクセス権（誰が使えるか）を設計した

部署・役職・用途で権限分離。退職/異動時の運用も含める。

権限

ログ（入力/出力/参照元）を残す方針を決めた

監査・トラブル対応・改善に必要。保存期間も検討。

ログ

誤回答時の対処（エスカレーション）を決めた

誰に回すか、どの条件で止めるか（自動停止含む）。

対応

第三者サービス利用時の契約/条項を確認した

データ保存、学習利用、サブプロセッサ、地域要件など。

契約

禁止領域のガードレール（拒否/警告）を用意した

法務/医療/個人データなどの扱いをUI/プロンプトで制御。

ガード

運用

現場に定着するかは、プロンプト設計より「運用設計」で決まることが多いです。

人のレビュー工程（ダブルチェック）を設計した

どの出力は人が必ず確認するか（重要度でルール化）。

レビュー

利用手順（短いマニュアル）を用意した

現場が迷わないよう「入力例」「NG例」を添える。

手順

問い合わせ・フィードバック窓口を決めた

改善が回るように、報告ルートと優先順位付けを作る。

改善

コスト管理（トークン/回数/時間）を設計した

上限や警告、用途別のモデル切替など、予算超過を防ぐ。

コスト

障害時の代替手段（手作業/バックアップ）を用意した

モデルや外部サービス停止時の業務継続を決めておく。

BCP

運用責任者（オーナー）を明確にした

誰が更新・品質・ルールを持つか。属人化を防ぐ。

オーナー

評価 / ROI

「良くなった」を数字や基準で示せないと、継続投資が止まりやすくなります。

導入前のベースライン（現状値）を取った

現在の工数、時間、品質、問い合わせ件数などを把握。

現状

成功/失敗の判定基準（合格ライン）を定めた

例：レビュー合格率、誤回答率、対応時間の目標など。

基準

リスク（誤回答・漏洩）のコストを見積もった

リスクが高い用途ほど、ガードレールとレビューを強める。

リスク

効果測定のレポート形式を決めた

誰に、どの頻度で、何を報告するか（例：月次）。

報告

小さく始めて拡張するロードマップを作った

1業務→部署→全社へ。拡張条件（KPI達成など）を決める。

拡張

撤退条件（やめ時）も定義した

成果が出ない場合の判断を事前に決め、無駄な継続を防ぐ。

撤退

AI導入チェックリスト

チェック項目の追加・修正提案