本シリーズの位置づけ
本シリーズは、PoC を終えた AI を本番に乗せるための実装設計を 10 話に分けて扱ってきました。最終話では、第1〜9話の論点を 1 枚のチェックリストにまとめます。
本番昇格を社内で判定するとき、このチェックリストを「全項目に Yes が付くまで本番昇格しない」というルールで運用すると、半年後の事故率が大きく下がります。
第1章｜入り口の設計（第1〜3話）
3 つの問いと PoC・本番昇格基準を確認します。
- - [ ] 何の成果のために導入するか、1 文で書けるか
- - [ ] 失敗の責任者と監督責任者が明文化されているか
- - [ ] やめる条件（撤退基準）が事前に決まっているか
- - [ ] PoC スコープが 1 業務・5 名以下に絞られていたか
- - [ ] PoC の終了条件（成功・継続・撤退）が事前合意されていたか
- - [ ] 本番昇格判定 5 軸（再現性／リカバリ性／継続性／コスト予測性／ガバナンス整合性）すべて「黄」以上か
- - [ ] PoC 不参加の担当者 3 名で 2 週間追試をして同等の効果が出たか
第2章｜接続とデータ（第4〜5話）
接続パターンとデータ準備の確認です。
- - [ ] 接続パターン（API／ファイル／RPA／コピー＆ペースト）を業務単位で選択しているか
- - [ ] API 連携の場合、接続先のライフサイクル方針を確認したか
- - [ ] ファイル連携の場合、スキーマ管理とエラー通知ルートを決めたか
- - [ ] RPA 連携の場合、専任保守担当 1 人と月次点検を決めたか
- - [ ] 社内 wiki に最終確認日と廃止カテゴリを設定済みか
- - [ ] 文書を公開／社内公開／部署内秘／守秘の 4 段階で AI 渡し可否を分類したか
- - [ ] FAQ 上位 30 件に社内承認済み回答を 1 対 1 で付けたか
- - [ ] 入力／出力／評価の 3 種ログを取る仕組みがあるか
- - [ ] 個人情報・機微情報を AI に渡さない設計になっているか
第3章｜セキュリティと運用（第6〜8話）
セキュリティ・運用・コストの確認です。
- - [ ] 入力分離・出力検証・権限最小化の 3 段が組み込まれているか
- - [ ] AI に外部システムの強い権限（送信・削除・決済）を直接渡していないか
- - [ ] ベンダー側のログ保存・学習利用の方針を契約で明文化したか
- - [ ] 認証は社員 ID 紐付けで、共有 ID を使っていないか
- - [ ] ログ 90 日以上保存・月次サンプルレビュー・半期内部監査を組んだか
- - [ ] インシデント対応の検知／影響範囲特定／通知の 3 段を文書化したか
- - [ ] モニタリングをシステム／品質／業務の 3 層で設計したか
- - [ ] 固定ベンチマーク 30 件を月次測定する仕組みがあるか
- - [ ] 改善ループ（評価ログ／パターン抽出／対応策／再測定）が月次で回るか
- - [ ] 業務オーナーと技術オーナーの 2 役を明文化したか
- - [ ] コストをベンダー課金／人件費／リカバリ工数の 3 層で予算化したか
- - [ ] トークン使用量の上限ラインをシステムにアラート組み込み済みか
- - [ ] 部署横断で使う場合、コスト按分ルールを事前合意したか