AI開発・導入の進め方：試作から運用までの依頼条件を決める

AIが担当する操作と、人が受け取る成果物を決める

最初に、誰が何を入力し、何を受け取って、どの判断に使うかを書きます。例えば問い合わせ分類なら、問い合わせ本文を読み、担当部署の候補を表示し、人が振り分けを確定する流れです。分類結果を返す機能と、実際に担当部署へ送信する操作は分けて依頼します。以下の依頼メモは編集部の提案です。

個別開発、既製のSDK、GPU基盤、機器では、購入する範囲が違います。モデルの作成、画面、データ接続、機器設置、ログ、運用支援のどれを含むかを表にして、対象外の部分を誰が用意するか確認します。『AI対応』という名称だけで一式が含まれるとは判断しません。

試作品を見せてもらう前に、受け入れ方をそろえる

普段の入力、入力が欠ける場合、対象外の入力を用意し、それぞれに期待する出力と確認担当を書きます。業務で許容できない誤りは個別に残し、平均の正答率だけで採否を決めないようにします。既存の手順にも同じ入力を通すと、改善した部分と追加の確認作業を把握できます。

モデルを調整する材料と最後に採否を判断する材料を分けます。scikit-learnの公式解説でも、評価用データが学習や前処理の調整に混ざると、性能を楽観的に見積もる原因になると説明されています。検証結果には、入力、処理の版、実行日時、期待値、実際の出力、判定理由を残します。

10件の計算例で、工程別の正しさと全体の成功を分ける

編集部が作成・計算した架空の例です。ID 1〜10の帳票に対し、抽出結果と整形結果を、それぞれ原本の正解と照合します。抽出はID 10だけ誤り、整形はID 9だけ誤りなら、各工程の正しい件数は9/10件（90%）です。一方、両方が正しいのはID 1〜8の8/10件（80%）です。工程別の90%を、そのまま業務全体の成功率とは呼べません。

次に、両工程ともID 10だけ誤る例へ変えると、工程別は同じ90%でも、両方が正しいのは9/10件（90%）になります。失敗したIDの重なりが違うためです。この例では、全件について二つの結果を観測できると仮定しています。途中で処理が止まる業務では、未実行を正解や誤りに混ぜず記録し、全体の集計では最初に受け付けた10件を起点にします。これは製品の性能測定ではなく、母数と失敗の重なりを確認するための計算例です。

継続費用と、更新・停止・引き継ぎの担当を決める

導入時の作業費と、毎月の利用料・機器保守・データ更新・人による確認の費用を分けます。通常時と処理が集中する時の入力件数や処理量を記し、上限到達時の挙動と追加費用を確認します。見積もりに使う数量がまだ分からない場合は、測る期間と担当を決めます。

誤った出力、接続障害、権限変更、モデル更新が起きた場合に、誰が止めて、どの状態へ戻すかを決めます。設定、接続仕様、評価データ、操作手順の受け渡し形式も確認します。NISTのPlaybookは用途に応じて選ぶ任意の提案集です。本ガイドの確認欄を埋めたことが、NISTへの適合や導入効果の証明になるわけではありません。

確認した根拠を、残しましょう。

入力は送信されません。ページを離れると消えるため、必要な記録を保存してください。確認済みの数は、導入の適否や品質を表す点数ではありません。

入力・出力・人の確定操作が決まっているか 確認資料の例：代表的な入力、完成例、操作と承認の担当

購入・開発する範囲と対象外が明確か 確認資料の例：モデル・画面・接続・機器・運用の作業分担表

調整用と採否判定用のデータを分けたか 確認資料の例：データの版、分割条件、評価担当、合否の根拠

費用の数量・上限・対象期間を確認したか 確認資料の例：通常時と繁忙時の利用量、見積もりの内訳

更新・障害時の停止と復旧を依頼できるか 確認資料の例：変更履歴、停止判断、戻し先、連絡担当

引き継ぐものと継続する作業を合意したか 確認資料の例：設定・仕様・評価記録・操作手順と保守範囲

出典と確認範囲

リンク先は提供元の公式情報です。このガイド全体や当社の手順が、提供元に承認されているという意味ではありません。

scikit-learn：データ漏洩と前処理の注意点：学習と評価の分離、前処理による情報混入の説明を参照。製品をこのライブラリで実装する指定ではありません。

NIST AI RMF Playbook：Govern・Map・Measure・Manageに沿う任意の提案集であり、全項目を実施するチェックリストではないという位置付けを確認。依頼メモは当社の整理です。