SIerの生成AI研修｜実務で定着する5段階
目次
はじめに
研修では全員がうなずいた。翌週、AIを使ったのは数人だけ。用途も議事録の要約とメールの推敲に偏っていた——。SIerで生成AI研修を開くと、こんな場面が起きやすい。
実案件には顧客情報、品質基準、契約上の制約がある。「何を入力してよいか」「誰が出力を保証するか」が分からなければ、現場は止まる。
SIerの生成AI研修は、ツールの操作説明では足りない。安全に使う境界を決め、実際の工程で試し、成果物をレビューし、チームの標準へ戻すところまでを一つの学習設計にする必要がある。
SIerの生成AI研修を座学で終わらせない
生成AIは文章作成ならすぐ使える。システム開発では事情が違う。要件定義書やコードには顧客固有の情報が含まれる。例外処理や非機能要件が抜ければ、正しそうな出力でも納品品質を満たさない。
三菱総合研究所のシステム開発における生成AI活用の整理でも、要件や仕様には企業ごとのルール、既存システ ムとの関係、ドメイン知識が必要だと指摘されている。コード生成では、品質、セキュリティ、知的財産権を確認し、人間がレビューする必要もある。
つまり、研修と実務の間には三つの溝がある。
- 入力してよい情報の境界が分からない
- AIの出力を合否判定する基準がない
- 個人の工夫を案件標準へ戻す方法がない
この溝を埋めずに「自由に使ってください」と言っても、慎重な人ほど使えない。必要なのは、同じ条件で安全に再現できる仕事を増やすことだ。SIer向けの生成AI研修は、ここを出発点にする。
生成AI研修を定着させる5段階
1. 安全な入力境界を一枚にする
初回研修では、便利なプロンプトより先に利用境界を決める。教材は分厚い規程ではなく、「入力可・要加工・入力不可」の3列でよい。
| 区分 | 例 | 研修での扱い |
|---|---|---|
| 入力可 | 公開済み仕様、架空データ、承認済みテンプレート | そのまま演習に使う |
| 要加工 | 議事録、障害票、既存コード | 固有名詞や識別子を除き、承認済み環境だけで使う |
| 入力不可 | 認証情報、未公開の個人情報、契約で外部送信を禁じた情報 | 入力せず、代替データを用意する |
IPAサイトで公開されている中核人材育成プログラム卒業プロジェクトのガイドラインは、導入、運用、リスク管理を分け、利用ルールを文書化する構成を示している。IPAの公式見解ではないとの注記はあるが、検討項目の洗い出しに使える。AIのセキュリティ要件のチェックリストも、案件用の確認項目へ落とす際に役立つ。
利用ツールのデータ保持、学習利用、ログを確認する担当者も決める。案件開始時にPMが確認できるチェック欄へ落とす。
2. 工程を一つに絞って実務演習する
次は、部署共通のサンプルではなく、実案件に近い一工程を選ぶ。おすすめは、入力と期待する出力を比較しやすい作業だ。
- 顧客ヒアリングから要件候補と未決定点を分ける
- 既存仕様からテスト観点を抽出する
- コード差分から影響範囲の確認項目を作る
- 障害票を事実、推測、次の調査に分ける
一度の研修で全工程を扱わない。工程ごとに良い出力の条件が違うからだ。要件定義なら「未決定点を勝手に埋めていないか」、テストなら例外と境界値の抜けを見る。
電通総研は上流工程のAIエージェント検証で、要件定義や基本設計の生産性が従来手法より30%向上したと公表している。設計情報を蓄積し、仕様変更の影響範囲まで扱う点が参考になる。
演習には失敗例も混ぜる。「情報が足りない」「仕様が矛盾する」「権限外の操作を求める」といった入力を渡し、AIが止まる場面を見つけてもらう。すると、仕事の判断基準が会話の中心になる。
3. AIの出力をレビューする力を測る
AIが作った成果物を提出できる人より、問題を説明して直せる人を育てる。SIerでは、出力の速さだけでなく、顧客に説明できることが欠かせない。
レビュー表は、次の五つから始めると扱いやすい。
- 根拠：入力資料のどこに基づくか示せるか
- 完全性：例外、制約、非機能要件が抜けていないか
- 整合性：既存仕様や前後工程と矛盾しないか
- 安全性：機密、権限、脆弱性の問題を増やしていないか
- 説明可能性：採用・修正・却下の理由を言葉にできるか
IIJによる実務研修の研究報告では、希望者47名へ1.5時間の研修を行い、生成AIの文章を判断するチェックポイントを演習へ組み込んだ。参加者アンケートでは、ためらいの軽減や理解度向上が報告された。対照群を置いた検証ではなく、継続的な定着は今後の課題である。
AIを使う不安は、気合で消すものではない。レビュー基準を共有し、どこを見ればよいか分かる状態にする。既存のコードレビューへ適用するなら、AIコードレビューの7つの確認点も併せて使える。
4. 良い使い方を案件の共有資産へ戻す
個人用プロンプト集だけでは、モデルや案件条件が変わるたびに前提がずれる。
残すべきものは、プロンプトそのものより次の四点である。
- 対象工程と利用目的
- 入力できる資料と加工条件
- 期待する出力形式
- 人間が確認する合格・失格条件
たとえば「議事録から要件を作るプロンプト」ではなく、「ヒアリング記録から事実、要望、制約、未決定点を分離し、未決定点は補完しない」という作業仕様にする。これなら利用ツールが変わっても引き継げる。
成果物の型は、既存の開発標準へ組み込む。新しいAI専用ルールを別冊で増やすと、現場は二重管理になる。SIerが仕様駆動開発を導入する理由で触れているように、仕様を実装とレビューの共通起点にすると、AIの出力も既存工程へ接続しやすい。
各段階を、入力仕様、受け入れ条件、変更履歴、レビュー証跡へ結び付ける。曖昧な依頼文を名人芸で改善するより、チームが同じ形で再利用できる方が強い。AIが読める仕様書の7 項目は、その土台として使える。
5. 利用率ではなく業務の変化を測る
受講率や月間利用者だけでは、成果は分からない。手戻りが増えれば開発は速くならない。
研修前に対象工程の基準値を取る。研修後は、速度と品質を対で追う。
| 観点 | 指標例 | 確認時期 |
|---|---|---|
| 行動 | 対象工程でAIを使った案件数 | 毎週 |
| 速度 | 要件整理やレビューの所要時間 | 研修前、2週後、4週後 |
| 品質 | 差し戻し件数、重大な見落とし件数 | 2週後、4週後 |
| 再現性 | 標準化した作業仕様の再利用件数 | 月次 |
| 安全 | 入力ルール違反、権限外操作の件数 | 発生時と月次 |
AI研修の評価では、満足度、学習、行動、成果を分ける考え方が使われる。生成AI研修の効果測定に関する実務整理も、利用率、業務適用率、時間削減、手戻りを別々に見る必要を示している。特に時間だけを追わない。レビュー修正が倍になったなら、前工程が速くても全体最適ではない。
30日で研修を実務へつなぐ
最初の30日は、1チーム、1工程、1成果物で回せる。
責任分担も固定する。研修責任者は教材と測定を持ち、PMは案件適用を承認する。品質担当は採点基準と重大な失格条件を管理し、受講者はAIを使った箇所と修正理由を残す。
1週目：境界を決める。 利用環境、入力区分、責任者、禁止操作を一枚にする。所要時間と差し戻し件数も記録する。
2週目：同じ課題で演習する。 5〜10人ほどで、通常例と失敗例を解く。成果物は共通のレビュー表で採点し、点数より判断理由を話す。
3週目：実案件で並走する。 AI利用あり・なしを比較できる小さな作業を選ぶ。顧客提出前には必ず人間が確認し、修正箇所を残す。
4週目：標準へ戻す。 再利用できた作業仕様、失敗例、レビュー観点を案件テンプレートへ反映する。利用されなかった場合も、理由を「関心がない」で終わらせず、情報境界、ツール権限、成果物の型のどこで止まったかを調べる。
IPAのAI人材育成に関する整理が示すように、AIを開発する人だけでなく、サービスへ組み込む人、業務で使う人にも異なるスキルが要る。SIerの研修も、全員に同じ操作を覚えさせるより、営業、PM、設計者、開発者、品質担当の役割に合わせて課題を変える方がよい。
研修のゴールは「生成AIを使える人」を増やすことではない。顧客の制約を守り、AIの出力を検証し、再利用できる開発標準へ戻せるチームを作ることだ。そこまでつながれば、研修は一日のイベントではなく、案件ごとに更新される仕組みになる。
自社の案件に合わせて研修課題、利用境界、レビュー基準ま で設計したい場合は、株式会社Atsumellへ相談する。要件整理から小規模な実証、開発標準への組み込みまで一緒に進められる。
