経営層は生成AIの活用を号令し、ライセンスは全社に配布済み。それでも開発のリードタイムと品質は変わっていない——いま、事業会社の開発組織からSIerまで、規模を問わず同じ相談が寄せられています。原因はツールでも現場の意欲でもありません。「ツールの導入」と「開発プロセスへの定着」が別の仕事であり、後者を担う人が組織のどこにもいないことです。本コラムでは、定着までの道のりを5段の階段に整理し、社内推進が止まる構造的な理由を解説したうえで、段の先へ登る道のりを「定着までの12週間」として、モデルケースの時系列でお見せします。
ある共通の風景があります。
経営会議で生成AIの活用が方針として掲げられ、GitHub CopilotやClaudeのライセンスが開発部門に配布される。若手を中心にAI推進の委員会が立ち上がる。数ヶ月後、経営層が「開発はどれくらい速くなったか」と問うと、答えられる数字がどこにもない——。
これは特定の会社の話ではありません。アルムナイSaaSを運営するHR Tech企業でも、物流大手のユーザー系SIerでも、物流コンサルティングを手がけるSI企業でも、私たちはほとんど同じ文言の課題を聞いています。実際、フリーランス人材の市場には「AI駆動開発の導入・定着を推進できる人」を求める案件が並び、月額単価は経験豊富なテックリード級の水準に達しています。組織の外にお金を払ってでも埋めたい欠落が、そこにあるということです。
課題の言い回しは各社さまざまですが、分解すると同じ3つに行き着きます。
注目すべきは、この3つのどれも「ツールが使えない」という話ではないことです。ツールはもう入っています。止まっているのは、その先です。
ツールの配布から組織としての定着までは、ひと続きの作業ではなく、性質の異なる5つの段階に分かれます。
段2までは調達の仕事、段3からは開発プロセス設計の仕事。性質が変わる段差で多くの組織が止まる。
多くの組織は段2で停滞する。段3以降は担当者と工数を割り当てない限り進まない。
多くの組織が止まっているのは、段2「個人利用」です。感度の高い数人が自分の作業にAIを使い、その人の生産性は確かに上がっている。しかし隣の席のメンバーは使っておらず、使っている人のやり方も共有されていない。この状態では、組織の数字——リードタイム、レビュー滞留、障害率——は動きません。個人の工夫は個人のものだからです。
段2と段3の間には、それまでと質の違う壁があります。段2までは「ツールを買って配る」という調達の仕事で登れますが、段3から先は開発プロセスを設計し直す仕事になるのです。どの工程でAIに何をさせるか、生成物を誰がどう検証するか、AIに読ませる資料（設計書・コーディング規約・過去の障害知見）をどう整備するか。これはツールの知識ではなく、開発プロセス改善の仕事であり、担当者を決めて工数を割り当てない限り、自然には誰もやりません。
「ツールは導入済みなのに変わらない」という状態は、失敗ではなく、単に階段の途中にいるだけです。ただし、段2から段3へは放っておいても登れない——ここが本コラムの出発点になります。
多くの組織は、この壁を「推進委員会」や「AIワーキンググループ」で越えようとします。そして、その多くが数ヶ月で失速します。委員会のメンバーが無能だからではありません。3つの欠落が重なる構造になっているからです。
| 欠落 | 何が起きるか |
|---|---|
| 工数の欠落 | メンバー全員が開発業務と兼務。検証や整備は「手が空いたら」になり、繁忙期に止まる |
| 経験の欠落 | 定着まで到達した経験者が社内にいない。何から着手すべきかの優先順位がつけられない |
| 事例の欠落 | 参照できる社内の成功事例がゼロ。説得材料がなく、懐疑的なメンバーを巻き込めない |
このうち最も重いのは経験の欠落です。工数は経営判断で確保できますし、事例は最初の一つが生まれれば解消します。しかし「どの工程から着手すれば早く成果が出るか」「生成AIのガイドラインには何を書き、何を書かなくてよいか」「効果測定はどの指標なら現場の負担なく取れるか」といった判断は、一度定着までやり切った経験がないと精度が出ません。手探りで進めると、検証だけで数ヶ月が過ぎ、その間に現場の期待値が下がっていきます。
もうひとつ見落とされがちなのは、失速のコストが「現状維持」では済まないことです。一度「AIをやってみたが大して変わらなかった」という空気が組織に定着すると、二度目の推進は最初よりはるかに難しくなります。段2で止まった状態を長く放置すること自体が、将来の選択肢を削っているのです。
では、段3から先へは実際にどう登るのか。ここからは、私たちが受けてきた複数の支援・相談をもとに再構成した架空のモデルケースを、12週間の時系列でお見せします。特定の企業の事例ではありませんが、起きる出来事・つまずく場所・数字の動き方は、現場で繰り返し目にしてきたものだけで組み立てています。
舞台は、製造業グループの情報子会社。10年を超えて稼働する販売・在庫管理システム（.NET）を、25名の開発チームが保守しています。経営からは「来期末までに開発工数2割削減」という期限付きの目標がグループ全体に下りています。Copilotの配布から8ヶ月。アンケート上は25名中14名が「使ったことがある」、日常的に使うのは3名。兼務の推進委員会（5名）は月1回の定例を8回重ねて、成果物は調査資料が2本——第1章の風景そのままの状態から始まります。
順序に意味がある。現状分析が先、ツール活用の設計は後。
まず足さずに実態を測ることから始め、最後は社内主導へ引き継ぐ。
Week 1–2にやるのは、新しい取り組みを何も足さないことです。よく「まずAIに触れず、分析から」と言われますが、正確ではありません。現場はもう触っていますし、止める理由もありません。足すのを我慢して、すでに起きていることを測るのです。
最初に見えたのは、利用実態のばらつきでした。日常的に使う3名の作業の進め方と成果物を突き合わせると——
同じツール、同じシステム、同じ業務で、効果は人によって数倍違い、無駄の多い使い方は誰にも指摘されないまま続いていました。これが段2「個人利用」の実像です。「使っていない」のではなく、ばらばらに使っていて、良い工夫も悪い癖も共有されていない。だから組織の数字にならないのです。
並行して、直近6ヶ月分のRedmineチケット約400件と作業実績をエクスポートし、工程別の工数を集計します。出てきた数字はこうでした。
「コードを書く速さ」を上げても、動くのは全体の3割だけ。テスト・レビュー・影響調査を合わせると6割を超えます。レガシーシステムの保守開発こそ効果が出やすいと言われるのはこのためで、工数を食っているのは新しいコードを書く作業ではなく、既存の資産を「読む」作業と「確かめる」作業なのです。あわせて、あとで比較するための基準値——テスト仕様書の作成工数、レビューにかかる時間——も、この段階で記録しておきます。
なお、この時期の課題一覧には、開発工程の外の相談も載ってきます。「グループ会社からの問い合わせ対応が派遣スタッフ頼みなので、AIで一次対応できないか」といった類のものです。捨てずに一覧へ残します。ただし順序は、経営に数字を返しやすい開発工程が先です。
対象工程の選定で、最初の衝突が起きます。現場のエース格は「どうせやるなら新規機能の開発で試したい。そのほうがモチベーションが上がる」と主張し、私たちは回帰テストの仕様書生成を推しました。理由は3つ。失敗しても本番コードに影響しない。着手前の基準値が取りやすい。同種の作業が毎月発生するので、整備したものの再利用回数が最も多い。
議論は1時間半かかりました。決め手は「新規機能は次の四半期に必ずやる。ただし順番として、経営に数字を返せるものを先に作る」という委員長の裁定です。対象は受注登録の機能一帯に絞りました。画面のコードビハインドOrderEntry.aspx.cs(約4,200行)と、引当ロジックのStockAllocationService.cs。運用対応の改修が毎月入り続けている、このシステムで最も回帰テストが重い場所です。
この順序の議論を曖昧にしたまま進むと、3ヶ月後に「楽しかったが数字がない」状態になる——それは、失速した組織で繰り返し見てきた形でした。
最初の検証結果は散々でした。受注登録まわりの3画面を対象に、既存コードと設計書からテストケースを生成させたところ、4割がこのチームのテスト規約に合っていません。境界値の取り方が違う。異常系の網羅の粒度が違う。「なぜこの値を使うのか」が書かれていない。
重要なのは、原因がAIの能力ではなかったことです。そのテスト規約は、正式なドキュメントとしては存在せず、ベテラン2名の頭の中と、過去のテスト仕様書の「空気」の中にだけありました。AIが読めなかったのではなく、読ませるものがなかったのです。
そこからの2週間は、地味な作業に費やされます。ベテランへのヒアリングで暗黙のルールを書き出し、過去の障害票から「二度とやってはいけないこと」を禁則事項として整理し、AIが参照できるファイルに落としていく。この2週間でリポジトリに増えたのは、次の4つのMarkdownでした。
(リポジトリ直下)
├─ CLAUDE.md AIが最初に読む入口。規約の要点と参照先の索引
└─ docs/ai-context/
├─ test-conventions.md テスト規約。境界値の取り方、異常系の粒度、ケースの命名
├─ incident-rules.md 過去の障害票から起こした禁則事項
└─ domain-glossary.md 受注・引当・出荷の用語と状態遷移
たとえばincident-rules.mdには、こういう項目が並びます。
## 禁則: 引当数量の丸め
- 引当数量の計算で既定の Math.Round を使わない
(銀行丸めが原因で棚卸差異の障害が出た。MidpointRounding.AwayFromZero を明示する)
- 数量系のテストには、端数0.5ちょうどの境界ケースを必ず含める
要点は、人間が読む利用ガイドライン(docs/ai-guideline.md)と、AIに読ませるコンテクスト(docs/ai-context/)を分けて整備することです。ガイドラインには「使ってよいデータと確認の手順」を、コンテクストには「生成の品質を決める事実」を書く。これにより、生成物の品質が個人のプロンプトの巧拙に依存しなくなります。ここが、段2（個人の工夫）と段4（組織のプロセス）を分ける技術的な分岐点です。
副産物がひとつありました。整備の途中で、設計書と実装が乖離している箇所が17件見つかったのです。10年物のシステムでは驚く話ではありませんが、乖離の一覧が文書になったのは初めてでした。AIのための整備は、そのまま属人化の棚卸しになります。
生成には、リポジトリ全体とdocs/ai-context/を読ませられるClaude Codeを使いました(CLAUDE.mdを置いたのはこのためで、セッション開始時に自動で読み込まれます)。入力は、Excelから起こした設計書のMarkdownと対象画面の実装、そしてコンテクスト一式。OrderEntry.aspx.csを含む3画面で計測すると、テスト仕様書の作成工数は1画面あたり約6時間から約2時間になりました。生成物をそのまま使うのではなく、必ず検証工程を挟む前提での数字です。
この週には、もうひとつの出来事がありました。「AIの書くものは信用しない」と公言していた懐疑派のベテランが、生成された仕様書の異常系一覧——引当数量0.5ちょうどの境界ケースが入っている——を見て、こう言ったのです。
これ、俺が3年前に踏んだ丸めの障害のパターンが入ってる。
入っていたのは当然で、その人の障害票から起こした禁則事項がincident-rules.mdに書いてあったからです。自分の経験が組織の資産として動いているのを見た瞬間、人は転びます。説得資料では起きないことが、動くものの前では起きるのです。
利用ガイドライン初版のdocs/ai-guideline.md（使ってよいデータ、確認の手順、禁止事項）を配布し、勉強会を開きました。出席者20名。翌週、実際に手順どおり使い始めた人は4名でした。
配って読ませる方式は、ライセンス配布と同じ失敗を辿る——そう判断して、方式を変えます。週に2枠、実際の担当案件を持ち込んでもらい、経験者と並んで作業する時間を設けました。資料を読む時間ではなく、自分の仕事が楽になる体験をする時間にする。持ち込まれたのは、月次の在庫締めバッチ(MonthlyStockClose.cs)の改修や、棚卸差異レポートの照会画面といった、その週の実案件です。
この枠にはもうひとつ役割がありました。作業中に規約の抜けに気づいたら、その場でtest-conventions.mdに1行足す。docs/ai-context/への変更は通常のコードと同じくプルリクエストでレビューする運用にしたので、コンテクストはペア作業のたびに育っていきます。
体制の壁もここで越えます。保守の実働には協力会社のメンバーも入っており、個人の工夫のままでは社外の人に渡せません。しかしリポジトリのコンテクストと利用ガイドラインになっていれば、所属を問わず同じ品質で回せます。属人化の解消は、社内に閉じた話ではないのです。3週間で、日常的に使うメンバーは4名から11名になりました。定着は「理解した人数」ではなく「自分の案件で使った人数」で数えます。ここを間違えると、勉強会の出席率という動かない数字を追うことになります。
12週目、経営への報告に載せたのは3つの数字だけでした。
凝った指標より、着手前の基準値と比較できる数字を優先する。
品質系の指標——障害率や手戻り工数——は、12週では動きません。これは無理に飾らず、「基準値を取得済み、次の四半期の測定対象」として報告します。動いた数字と、まだ動かない数字を分けて出すことが、報告の信頼を作ります。
そして次の四半期の計画として、レビューの一次スクリーニング（規約違反と影響範囲の見落とし検出）への展開を提案します。ここが最後の分岐点で、次の工程は社内メンバーが主導し、私たちはレビュー役に退きます。経営会議の結論は、推進メンバー2名の専任化（50%工数）と、次期予算の承認でした。8ヶ月動かなかったものが、12週間で「予算と工数が継続的につく活動」に変わったのです。
経営層の号令で始まった取り組みは、経営層に数字を返せた時点で初めて、続く活動になります。凝った指標は要りません。着手前に基準値を取っておき、同じ物差しで測って返す——それだけです。
ここまでの整理を踏まえると、外部支援に求めるべきものがはっきりします。第3章で見たとおり、社内に欠けているのは工数・経験・事例の3つでした。このうち外部から本当に調達すべきは経験であり、工数と事例は組織の中に作られるべきものです。モデルケースの12週間でも、事例（最初のPoCと数字）と工数（専任化）は、組織の内側に生まれています。
この区別を誤ると、支援の形が「代行」になります。外部の専門家がPoCを作り、ガイドラインを書き、成果を出して去っていく——一見成功に見えますが、契約が終わった瞬間に段2へ逆戻りします。ノウハウが個人（それも社外の個人）に残り、組織に残っていないからです。
私たちがAI駆動開発の導入・定着支援を「伴走」の形で設計しているのは、このためです。現状分析と設計図の作成は経験者が主導しつつ、PoCの実施もルールの整備も、貴社の開発メンバーと共同で進めます。ゴールは私たちが成果を出すことではなく、次の対象工程には貴社のメンバーだけで展開できる状態——つまり内製化です。定着とは、外部支援が不要になることの別名だからです。
判断の材料として、外部支援を検討する意味があるのは次のような状況です。
逆に、まだツールの配布すら済んでいない段階であれば、外部支援より先に社内の合意形成が必要です（その論点はAI駆動開発の最初のハードルは社内承認で扱っています）。
Chapter Techでは、本コラムで整理した現状分析から効果測定までの定着支援を、AI Delivery Scope+として提供しています。自社がいま階段のどの段にいるかの見立てからで構いません。現状の開発プロセスと課題感を、お問い合わせからお聞かせください。