生成AIを開発組織に入れる前に決める3つのこと

「ChatGPTかCopilotか、まずどれを契約すればいいか」——導入検討の最初の会議で、この問いから始まる組織は少なくない。

現場では別の景色が見える。ライセンスは配ったのに、使う人と使わない人が分かれ、セキュリティ部門が後からブレーキをかけ、経営は「効果があったのか」と聞くが数字がない。PoCは成功したのに本番に進まない、ツールを入れたのに現場で定着しない——生成AI導入の失速は、だいたいここで起きる。

先に決めるべきはツールではない。用途・送信境界・評価指標の3つだ。 この3つが決まるまで、ベンダー比較は後回しでよい。

結論：導入前に固定する3つ

決めること	問いの形	決まらないときの症状
用途	どのワークフローの、どの工程を短縮するか	全社展開しても利用率がばらつく
送信境界	何をモデルに送ってよいか／だめか	監査・セキュリティで後から止まる
評価指標	導入前後で何のリードタイムを比べるか	「便利になった」で終わり、投資判断できない

ツール選定は、この表が埋まってからで十分間に合う。

現場で見た、よくある失速パターン

匿名化した一例だ。従業員数百名規模の開発組織で、生成AIの全社ライセンスを先に契約した。キックオフ資料には「生産性30%向上」とあったが、用途の定義は「コーディング支援全般」止まりだった。

3ヶ月後の実態はこうだった。

• 一部のエンジニアは日常的に使う一方、半数以上はログインすらしていない
• 設計書の一部が外部モデルに貼られた疑いがあり、情報システムが利用を一時停止
• 効果測定はアンケートの「満足度」だけで、リードタイムの前後比較がない

結果として「使われていないライセンス」と「止められた活用」が同時に残った。問題はモデルの性能ではなく、用途・境界・指標を決めずに広げたことだった。

もう一つのパターンは、PoCだけが上手くいくケースだ。特定チームでチャットUIのデモは通る。しかし本番のチケットフロー、権限、ログ保管、障害時の責任分界が未設計のままなので、セキュリティレビューで止まる。デモの成功を「導入成功」と誤認しないことが重要だ。

1. 用途を「全社」ではなく「ワークフロー」単位で切る

「生産性向上」は目的にならない。どの作業の、どの工程を短縮するのかまで落とす。

向いている切り方の例:

• 要件整理のたたき台作成（会議メモ → 論点リスト）
• テストケース生成（仕様書 → 境界値ケース）
• 障害調査の一次切り分け（ログ断片 → 仮説リスト）
• 社内ドキュメント検索（RAGで既存Wikiを横断）

向いていない切り方:

• 「エンジニア全員のコーディングを速くする」
• 「全社のナレッジ活用」
• 「AIでDXする」

用途が曖昧なまま全社展開すると、使う人と使わない人が分断され、評価もできない。最初のパイロットは1ワークフロー・1チーム・2週間が上限だ。成功したワークフローだけを横展開する。

2. ガバナンスは「禁止」ではなく「送信境界」で設計する

「機密は出すな」だけでは守れない。口頭ルールは、忙しい現場では必ず崩れる。必要なのは、送信してよいデータの境界を明文化することだ。

例:

データ種別	方針	補足
顧客個人情報	送信不可	マスクしても再識別リスクがあるものは不可
設計書の概要	匿名化後に可	社名・個人名・接続先を除去
公開済みAPI仕様	可	既に外部公開されているものに限る
未公開の脆弱性情報	送信不可	社内チケットのまま扱う

あわせて決めるべき運用項目は次のとおりだ。

• プロンプトログの保管期間とアクセス権限
• レビュー責任者（情シス／セキュリティ／開発リードの誰か）
• インシデント時のエスカレーション先
• 個人のAPIキー持ち込みを許すか（原則禁止が安全）

後から監査できない導入は、いずれ止められる。「禁止リスト」より「送信してよい一覧」の方が現場は動きやすい。

3. 評価指標は「体感」ではなくリードタイムで測る

「便利になった」は経営判断に使えない。導入前後で比較できる指標を、ツール契約の前に決める。

対象ワークフロー	指標の例	測り方
要件定義	初回レビューまでの日数	チケット作成〜レビュー完了
実装	PR作成〜マージまでの時間	CIとPRメタデータ
品質	再オープン率、本番障害件数	既存の障害トラッカー
調査	障害初動の平均時間	アラート〜一次報告

2週間のパイロットで十分だ。数値が改善したワークフローだけを残し、改善しない用途は止める。全社展開の判断は、満足度アンケートではなくこの表で行う。

判断軸：今すぐやる／まだやらなくてよい

状況	推奨
短縮したい工程が1つに特定でき、責任者がいる	小さくパイロットする
「とりあえず全社ライセンス」から始めたい	まだやらなくてよい。用途を先に決める
PoCは通ったが送信境界とログ方針がない	本番化しない。境界を先に書く
効果を「雰囲気」で報告する予定	指標を先に決めてから始める
既存の開発プロセス自体が荒れている	生成AIより、リリース／レビューの型を先に直す

生成AIは、壊れたプロセスを自動では直さない。速い下書きを増やすだけだ。プロセスが荒い組織ほど、先に型を整えた方が投資対効果が高い。

社内で確認すべきチェックリスト

導入検討の次の会議で、次を埋められるか確認する。

1. 対象ワークフローは何か（工程名まで）
2. パイロットの対象人数と期間は何か
3. 送信してよい／だめなデータの一覧はあるか
4. プロンプトログの保管と責任者は決まっているか
5. 導入前後で比べる指標は何か（1つでよい）
6. 数値が改善しなかった場合、止める権限は誰にあるか

この6つが空欄のままベンダー選定に入ると、失速パターンに入りやすい。

よくある質問

Q. まずChatGPTとCopilot、どちらを契約すべきですか？

用途が決まってから選ぶ。コーディング支援が主ならIDE統合型、調査・文書・要件整理が主ならチャット／エージェント型、社内文書検索が主ならRAG構成、と用途起点で十分だ。先に契約すると、用途が契約に引きずられる。

Q. セキュリティ部門が反対して進みません。どうすればよいですか？

反対を「感情」扱いにせず、送信境界表とログ方針のドラフトを先に渡す。禁止の是非ではなく、送ってよい範囲と監査可能性の議論に移すと前進しやすい。

Q. 小さなチームなら、3つを決める前に使ってよいですか？

個人の学習用途ならよい。ただし顧客データや未公開設計に触れる瞬間から、境界とログの話は必須になる。チームの公式ツールにするなら、規模に関わらず3つは短くてよいので先に書く。

Q. 指標がすぐ取れない組織でも始められますか？

始められるが、その場合はパイロットをさらに小さくする。例えば「障害初動メモの作成時間を手動で10件測る」など、粗い前後比較でも「体感のみ」より判断材料になる。

まとめ

生成AIは魔法ではない。用途・送信境界・評価指標——この3つを先に決めれば、ツール選定は速くなり、失速も減る。

逆に、この3つが決まらないまま導入すると、半年後に残るのは「使われていないライセンス」と「止められた活用」だけだ。まずは1ワークフロー分の表を埋めるところから始めればよい。

---

生成AI活用支援の相談は、お問い合わせフォーム からどうぞ。