SIerの生成AIガイドライン｜開発現場の7項目
目次
「生成AIは使ってよい。ただし機密情報は入れないこと」。
方針としては正しい。ところが、開発現場に渡すと手が止まる。顧客から受領した画面仕様は機密なのか。障害ログを要約させてよいのか。AIが書いたテストコードは、誰がどこまで確認するのか。案件ごとの判断に必要な答えがないからだ。
反対に、全面禁止へ振ると利用が見えなくなる。個人契約のツールへ断片的な情報を貼り付ける「シャドー利用」が起き れば、管理はさらに難しい。
SIerの生成AIガイドラインには、理念だけでなく作業単位の境界が要る。開発工程、顧客との契約、再委託先、成果物の品質保証までを一つにつなぐ設計である。
SIerにおける生成AIのガイドラインは規制集ではない
AI事業者ガイドライン第1.2版は、AIに関わる主体を開発者、提供者、利用者に分け、リスクに応じて対策を選ぶ考え方を示している。SIerは案件によって三つの立場を行き来する。自社向けツールの利用者であり、顧客システムへ組み込む開発者であり、運用サービスの提供者にもなる。
だから、一枚の禁止事項だけでは足りない。少なくとも次の3層を分けたい。
- 全社方針：法務、情報セキュリティ、利用可能な契約形態を定める
- 案件ルール：顧客データ、対象工程、承認者、再委託先を定める
- 成果物の受け入れ条件：設計書、コード、テスト結果を人がどう検証するか定める
IPAが掲載する卒業プロジェクト成果物「テキスト生成AIの導入・運用ガイドライン」も、導入、運用、リスク管理を別章で扱っている。これはIPAの公式見解ではなく、プロジェクトメンバーによる成果物である。その位置づけを踏まえても、ツールを許可して終わりにせず、使い続ける条件と問題発生時の扱いまで考える構成は参考になる。
開発現場で決める7項目
1. 利用目的と対象工程
「生産性向上」では広すぎる。要件の論点抽出、設計案の比較、コード補完、テストケース作成、障害調査など、作業まで分解する。
整理方法の一例は、作業を緑・黄・赤の3区分にすることだ。公開情報の要約は緑。顧客情報を加工した設計支援は承認付きの黄。本番データの直接投入や、AIだけでの本番反映は赤、といった具合である。全社基準を最低ラインにし、案件では顧客契約やデータ特性に応じて制限を追加する。緩和が必要なら、案件判断だけで済ませず全社の法務・セキュリティ承認へ戻す。
2. 入力してよい情報
「機密情報禁止」では、判断する人によって答えが変わる。入力情報を具体的に分類する。
- 公開済みの仕様やOSSドキュメント
- 匿名化した要件 、画面項目、サンプルデータ
- 顧客固有の仕様書、ソースコード、構成情報
- 個人情報、認証情報、本番ログ、未公開の脆弱性情報
各区分に、利用可能な環境、匿名化の方法、承認者を結び付ける。APIキーを伏せても、URLや顧客名から案件を推測できる場合がある。項目単体ではなく、組み合わせたときの再識別リスクも見る。
3. 利用する環境とデータの扱い
同じモデル名でも、個人向け画面、法人契約、APIでは条件が違う。学習利用の有無、保存期間、管理者による監査、データ処理地域、削除手順を確認する。モデルを切り替えたときに規約まで変わる点も見落としやすい。
許可リストには製品名だけを書かない。「法人テナントの指定プラン」「会社発行ID」「学習利用を無効化」「指定リージョン」のように、使える状態を記録する。契約更新時の再確認日も必要だ。
4. 出力の受け入れ条件
生成物を参考情報と呼ぶだけでは品質は守れない。工程ごとに合格条件を置く。
要件なら、原文との対応、未決事項、例外条件が見えること。コードなら、静的解析、テスト、依存ライセンス、セキュリティレビューを通すこと。テストケースなら、正常系だけでなく境界値と異常系を含むことだ。
AIの出力基準を具体化すると、人が書いた成果物の基準も明確になる。仕様駆動開発をSIerが導入する理由で扱ったように、受け入れ条件を先に合意すれば、作成者が人かAIかにかかわらず同じ観点でレビューできる。
5. 人の責任と承認経路
「最終判断は人間」と書いても、その人が誰か分からなければ機能しない。作成者、確認者、承認者を成果物ごとに置く。営業提案、要件、設計、コード、本番操作では、必要な権限が違うからだ。
多重の委託構造では、元請けだけがルールを知っていても不十分である。再委託先が使える環境、顧客への説明主体、生成物に起因する不具合の一次対応を契約と案件計画へ落とす。責任をAIへ移すことはできない。
6. 記録と追跡可能性
すべての会話を無期限に保存すると、秘密情報の保管場所が増える。逆に何も残さないと、障害時に判断を追えない。保存するのは監査と再現に必要な最小限でよい。
たとえば、利用者、日時、目的、利用環境、モデルの版、参照した資料の管理番号、生成物の保存先、レビュー結果を残す。プロンプト本文を保存する場合は、機密情報のマスキングと閲覧権限を決める。NTTデータグループのAI-Native開発に関する資料も、商用システムで品質、透明性、説明責任をどう確保するかを論点にしている。
7. 停止条件と事故対応
誤回答が一度出たら全面停止、では現場は続かない。停止の単位を決める。個人の利用停止、特定機能の停止、案件全体の停止を分け、発動条件と解除条件を置く。
本番情報の誤投入、秘密情報の外部送信、権利侵害の疑い、重大な品質事故が起きたときは、誰へ連絡し、ログをどう保全し、顧客へいつ説明するのか。インシデント対応表に生成AI固有の入口を追加しておく。新しい会議体を増やすより、既存の連絡網へ組み込む方が動きやすい。
工程別に一行で確認できる形へ落とす
長い規程は必要だ。とはいえ、実作業のたびに30ページを読み返す人はいない。工程別のチェックシートを一枚ずつ作る。
要件定義と設計
入力元、顧客承認の要否、AIが提案してよい範囲、未決事項の表示方法を決める。議事録から要件を抽出するなら、原文への参照を残し、AIが補った内容を確定事項へ混ぜない。
実装とレビュー
対象リポジトリ、送信禁止ファイル、許可する拡張機能、必須テストを決める。生成コードは差分でレビューし、ライブラリの追加と権限変更を重点的に見る。大量生成より、小さな差分を短い周期で検証する方が原因を追いやすい。
テストと本番運用
テストデータの作り方、期待値の根拠、誤検知の扱いを定める。本番でAIが判断を伴うなら、信頼度が低い場合の人への引き渡し、実行回数の上限、緊急停止を仕様にする。AI PMOの5つの設計で紹介した決定・課題・変更の管理とつなぐと、例外を放置しにくい。
案件開始時に責任分界表を一枚作る
SIer固有の難しさは、利用者と責任者が同じ会社にいないことだ。顧客、元請け、再委託先、生成AIサービス提供者の間で、確認と説明の境界がずれる。そこで案件開始時に、次の列を持つ責任分界表を一枚作る。
- 作業と生成物
- AIを使う会社と利用環境
- 入力情報の管理者
- 生成物の確認者と承認者
- 顧客へ事前説明する条件
- 不具合時の一次対応と報告期限
- 成果物の権利帰属と再利用可否
たとえば再委託先がテストコードを生成するなら、元請けは利用環境を確認し、成果物を検収する。顧客には、契約や案件ルールで合意した条件に従って説明する。生成AIサービスの規約が変わっても、顧客への品質責任が自動で移るわけではない。
デジタル庁の生成AI調達・利活用ガイドライン第2.0版が技術や制度の変化を踏まえて更新されたように、企業のルールも改定を前提にする。月次の案件会議で、迷った事例、レビューで直した件数、根拠を確認できなかった件数を確認する。利用回数だけでなく、品質と承認待ち時間も見れば、許可範囲を広げる判断がしやすい。
導入前に確認したいチェックリスト
- 対象工程と禁止作業を一文で説明できるか
- 入力情報ごとに利用可能な環境が決まっているか
- 学習利用、保存期間、監査方法を確認したか
- 成果物ごとの受け入れ条件があるか
- 作成者、確認者、承認者が決まっているか
- 再委託先にも同じ条件が伝わっているか
- 必要最小限の利用記録を残せるか
- 停止条件、連絡先、再開条件があるか
- 月次または四半期で見直す責任者がいるか
一つでも答えが曖昧なら、ツール導入を止める必要 はない。まず黄色の承認付き作業として試し、判断材料を集めればよい。最初から例外のない規程は作れない。迷いを記録し、次の版へ反映する運用の方が強い。
ガイドラインを仕様として育てる
SIerにおける生成AIのガイドラインは、法務文書であると同時に開発仕様でもある。「してよい」「してはいけない」だけでなく、入力、判断、出力、確認者、停止条件を記述する。そうすれば現場は自分で判断でき、管理側も例外を追える。
Atsumellでは、業務フローの整理から要件定義、権限設計、受け入れ条件、AIを組み込む実行基盤まで一緒に設計している。生成AIの利用ルールを案件の作業へ落とし込みたいなら、お問い合わせから相談してほしい。
