AI研修で何を納品してもらう？座学で終わらせない業務設計

研修を発注する前に、受講者が研修後にどの業務を実行できる状態を目指すかを決めます。以下では、その目的に合わせた成果物の内容と、研修・本番開発の範囲を決める考え方を説明します。

研修の目的と納品物を揃える

経営者が導入判断を学ぶ研修と、現場が特定業務へ組み込む研修では、必要なものが違います。前者なら比較の観点や判断材料、後者なら実行と確認の手順が中心になります。

この区別がないまま「AIを活用できるようにする」と頼むと、何をもって終わりとするかが曖昧になります。受講者が操作を覚えたら完了なのか、社内で試す準備ができたら完了なのか、発注する側と提供する側で完了の条件を合わせておきます。

NISTのAIリスク管理の枠組みでも、役割と責任の明確化、担当業務に沿った教育が扱われています。これは特定の研修商品を推奨するものではありませんが、学ぶ内容を実際の役割につなげる参考になります。NIST：AI RMF Core・GOVERN 2

以下は、実務導入向けの研修で確認する成果物の例です。公的な必須要件ではなく、会社へ仕事の進め方を残すための提案です。

一つ目は対象業務の設計書

最初に残すのは、何をAIに任せるかが分かる短い設計書です。「営業でAIを使う」では広すぎます。どこから始まり、どこで終わる仕事なのかを決めます。

想定例として、複数の営業担当者から集まる活動記録を、週次の報告へまとめる業務を考えます。研修では単に要約を作るだけでなく、記録の取得、情報の整理、確認、正式な保存までを対象にします。

設計書には、元資料の置き場、実行する担当者、AIへ渡してよい項目、生成する形式、確認する担当者、保存先を記載します。自動で次へ渡す範囲と、人が判断する範囲も分けます。

この時点で、必要な記録がそろっていないと分かるかもしれません。それは研修の失敗ではありません。AIを動かす前に片付ける課題が明らかになったということです。足りない情報を誰が用意するかまで決めれば、次の作業へつながります。

二つ目は使える入力と使わない入力

研修用のきれいな資料では動いても、社内の資料で同じように動くとは限りません。だからといって、機密資料をそのまま研修へ持ち込む必要はありません。

実務の形式を保ったダミーデータや、利用許可を確認した情報で試します。大事なのは、どの入力なら処理できるか、どの状態なら止めるかを残すことです。

先ほどの想定例なら、担当者名がない、対象期間が違う、同じ記録が重複している場合を用意します。足りないところをAIが勝手に埋めるのではなく、確認が必要な入力として扱えるかを試します。

使える入力例だけでなく、使わない入力例と理由があると、研修後の判断を揃えやすくなります。ただし、使わない入力例に挙がっていない資料でも、無条件に使ってよいとは限りません。迷う場合の相談先も併せて残します。

三つ目は完成と判断する基準

報告に使えるかは、文章の自然さだけでなく、その仕事に必要な条件を満たしているかで判断します。対象期間、必要項目、数字の対応、元資料とのつながりなどを完成基準として決めます。

講師がその場で修正するだけでなく、どの条件を満たしていなかったかも記録します。同じ問題が出たとき、社員が確認すべき条件を把握できるようにするためです。

ここで全件を人が最初から読み直す前提にする必要はありません。項目の有無や重複など機械的に確かめられるものは自動検査へ、意味の判断が必要なものは担当者へ、と分けて設計します。自動検査そのものが正しく動くかも試験対象です。

研修の成果物には、合格例、不合格例、不合格の理由を含めます。完成した出力だけを渡されても、途中で間違った際に直せるとは限りません。

四つ目は担当者が再現できる手順

講師の画面で一度動いたことと、社員が自分の環境で回せることは違います。受講者が手順に沿って実行し、成果物を保存するところまで確認します。

操作手順に加え、必要な権限、利用する会社アカウント、参照資料の版など、開始前の条件を書きます。実行後に記録する内容と、実行できなかった場合にどこへ戻るかも決めます。

手順書が長ければよいわけではありません。普段の担当者が読む部分と、管理者が設定する部分を分ける方が使いやすいでしょう。利用者が毎回すべての設定を判断し直す形にしないことです。

最後に、作った本人とは別の担当者に、手順に沿って実行してもらいます。口頭で補足しなければ進まない箇所があれば、その説明を手順書に追記します。これは社員の理解不足を探す試験ではなく、引き継げる成果物になっているかの確認です。

研修と本番開発の境界を残す

業務の流れができたからといって、そのまま本番運用できるとは限りません。試作で省いていた監視やエラー対応、連携設定が残る場合もあります。

そこで、納品時には「できたこと」と「本番までに必要なこと」を分けます。誰が、何を、どの条件で進めるかが分かるようにします。未完成の試作を、完成した業務システムのように扱わないためです。

• 今回の範囲：業務設計まで。成果物の考え方：入力、処理、確認、保存と担当を決める
• 今回の範囲：試作まで。成果物の考え方：限定したデータで動作と課題を記録する
• 今回の範囲：本番導入まで。成果物の考え方：運用、停止、復旧などを含めて検証する

外注先の保守や追加開発が必要なら、その費用を研修費と分けて見積もります。逆に、社内の既存環境で運用できるなら、何でも開発案件に広げる必要はありません。

資料の量より次の仕事が決まること

研修後は、資料の枚数だけでなく、担当者が対象業務を実行できるかを確認します。その際、「この仕事は、この情報を使い、この手順で進める」と担当者が説明できるかも確かめます。

最初から全業務を対象にせず、一つで構いません。実行する担当者と、困ったときの相談先、試す範囲、見直す時点を決めます。残る課題があるなら、それを隠さず次の作業にします。

要は、研修を知識の受け取りだけで終わらせないことです。会社としてAIに何を任せるのか、その仕事をどう完了させるのか。そこまで残る研修なら、受講した人の記憶だけに頼らず、社内で続ける土台になります。

まとめ

研修の成果物には、対象業務、元資料、実行手順、確認条件を含めます。受講者が自分の環境で実行し、成果物を保存できるかを確認します。