AIツールを入れたのに速くなった気がしない方へ
生成AIツールを導入して1年前後、現場は「もう手放せない」と言うのに、経営やビジネス側からは「開発が速くなった」という実感が返ってこない——その状態を説明できる実名の事例が出てきました。
ラクスが自社イベントの登壇内容を技術ブログで公開しています（ラクス「AIを載せることはゴールではない」2026年7月29日）。成功事例集ではなく、うまくいかなかった過程の共有です。登壇者本人が「少し泥くさい話になります」と断ったうえで話しています。
工程では削れていました
同社の開発組織は国内約350人、海外約100人。2022年秋に GitHub Copilot を使うメンバーが現れ、2023年4月に全面導入、2026年4月には Claude Code を全面導入しています。報告された成果は次のとおりです。
| 対象 | 削減 |
|---|---|
| 開発工数 | SPEC駆動開発（SDD）導入で50%削減 |
| テスト工数 | E2Eテスト自動化で30%削減 |
| 調査コスト | 25%削減 |
| 海外チームとのリードタイム | 30%削減 |
あるプロジェクトではコードの95%を生成AIが実装したとしています。現場の声も「実装は楽になった、もう戻れない」「PoCや新機能開発は確実に速くなった」。
数字も体感も出ている。それでもビジネス側から「明らかに速くなった」という声は返ってきませんでした。
実数を測ったら、伸びていませんでした
ここが記事の核心です。同社は体感で終わらせず、全面導入の前後でリリース回数と新機能数がどう変化したかを計測しました。結果は、期待したほど伸びていない。
登壇者は同時に、この数値の限界も明示しています。機能の規模を無視した参考値であり、サービス開始から6年以上経過したプロダクトのみでの計測だと。数字の扱いは慎重です。
そのうえで導かれた結論が、明快でした。実装フェーズは確かに楽になった。しかしその前後の工程やプロセス全体が変わらなければ、価値提供のスピードは上がらない。従来のプロセスにAIツールを足すだけでは、成果には届かない。
工程単位の削減率と事業成果の数字が食い違うこと自体は珍しくありません。公表される生産性の数字が何を測ったものかの読み分けはAI開発の生産性200倍は何を測った数字かで扱いました。今回はその先——なぜ届かないのかの答えが、同じ組織の内部から出ています。
犯人は「実装以外の工程」でした
同社は次の打ち手として現状の可視化に進み、AI駆動開発がどこまで浸透しているかを測るサーベイを作りました。開発チームごと・工程ごとに成熟度を自己評価する仕組みです。
出てきたのは3つです。
- チーム間のばらつきが大きい
- 実装フェーズは浸透しているが、テストとレビューはほぼ手つかず
- 開発速度が改善しているチームほど、実装以外の工程でもAIを使い、SPEC駆動開発を取り入れている
3つ目が答えになっています。速くなったチームと、そうでないチームの差は、ツールの有無ではなく適用した工程の広さでした。
現場からは「AIならではの手戻りが発生する」「レビューが重く、品質確認の負荷はむしろ増えた」という声も上がっていました。実装だけを速くすると、下流のレビューに詰まる。全体では速くなりません。レビュー側で何が起きるかはAIが作ったコードを人がレビューする理由で扱っています。
「優秀な現場に任せれば進む」が外れました
もう1つ、組織論として重い話が出ています。
同社は各チームが技術スタックも拠点も異なり、それぞれ最適なやり方を選んで成果を出してきた組織です。その実績があったからこそ「優秀な現場にAIツールを渡せば、良い使い方を見つけて自然に進むだろう」という前提を置いていた、と振り返っています。
その前提が外れました。ヒアリングで見えた、浸透を止めていた要因は3つです。
- コスト意識が高いため、効果が見えるまで新しいツールの導入判断に時間がかかる
- AI活用の「目指す姿」が見えにくく、学習コストを踏まえると日々の開発が優先される
- チームをリードする推進役が不足し、良い使い方がチーム全体に広がらない
どれも、現場の能力の問題ではありません。判断の材料と基準が組織から示されていないという問題です。優秀な現場ほど、効果の不確かなものに時間を割く判断を自分では下しません。合理的だからです。
自律の文化を捨てて、強制力に振りました
同社が打った手は、方針の転換でした。自律的な最適化に任せる文化を持つ組織が、あえて組織としての強制力に踏み込んでいます。
浸透を止めていた3要因への打ち手
- 効果検証を待たない: 生産性向上がはっきりしていた Claude Code を全面導入し、それを前提とした SPEC駆動開発を海外拠点も含めて全面展開する（各チームでの効果検証を待たない）
- 「実践カタログ」で目指す姿を明文化する: 実践すべき約20項目を職種ごとに定義し、「どこまでやれば実践できていると言えるか」まで書く。ガイドラインで止めず、開発マネージャーの目標に組み込む
- 推進役を置いて外から支援する: 勉強会、社内イベント、社内報での紹介、表彰制度、他チームの有識者による支援を用意し、成功事例が横に流れる経路を作る
3つとも「現場が判断できない理由」を組織側が引き取る形になっています。自社で1つも当てはまらないなら、ツールの追加導入より先に決めるべきことが残っています
「効果検証を待たない」は思い切った判断です。ただ、要因1が「効果が見えるまで判断に時間がかかる」なのだから、効果検証を各チームに委ねる限りループは抜けられません。因果の順序として筋が通っています。
正答率を上げても使われませんでした
同じイベントでは、プロダクトへAIを載せる側の話も出ています。当初もっとも力を入れていたのは正答率の向上だったが、ユーザーの関心はそこになかった、という報告です。
ユーザーが見ていたのは、正答率そのものよりも最終的な正解へ早く楽にたどり着けるかでした。なぜその答えなのかの分かりやすさ、方向を示して軌道修正できること、間違ったときに戻しやすいこと。
打ち手は、面倒な作業は自動化し、確認と修正は人に残す設計です。優先順位はこう言い切られています。
「90%正解でも、確認・修正しづらいAI ＜ 80%正解でも、確認・修正しやすいAI」
開発に熱が入るほど見落としやすい観点です。エンジニアの自然な発想である精度向上が、ユーザー価値と直結していなかった。組織の話と同じ構図——手段の改善が目的の達成と一致していない——がプロダクト側でも起きています。
発注側が確認できること
外注先や社内の開発チームが「AIで速くなります」と言うとき、この事例が示した観測点を当てられます。
適用範囲を聞く。実装だけか、要件定義・テスト・レビューまで入っているか。実装だけなら、削った時間は下流の渋滞に吸われます。
組織として何を決めたかを聞く。ツールの導入は決定ではありません。どの工程で何をどこまでやるかが職種ごとに定義され、達成状況が誰かの目標に紐づいているか。示せないなら、まだ現場任せの段階です。
リリース頻度で見る。工程ごとの削減率は、事業成果を保証しません。判断に使うなら、リリース回数や機能の提供間隔のような、価値が顧客に届いた時点の数字を見てください。
「決めていない」ことの費用は生成AIを使う日本企業は86.4%で組織として何も決めていない企業は27%で統計として扱いました。今回はその統計に、実名の中身が入った形です。
実装の速さは、もう差になりません
ツールを配れば実装は速くなります。それは450人規模の組織で実証済みで、あなたの会社でも同じことが起きるはずです。
差がつくのはその先——実装以外の工程を作り替えられるか、そしてそれを現場の判断に委ねずに組織として決められるかです。前者は技術の話ですが、後者は経営の話です。公開された事例が示したのは、後者を先に片付けないと前者が進まないという順序でした。
実装が速くなった後に「何を作るか」が重くなる構造は実装が速くなった今 受託開発は何を売るのか、体制としてどう組むかはAIネイティブ開発で扱っています。
自社のAI活用が実装フェーズで止まっているかを確かめたい段階でしたら、お問い合わせからご相談ください。どの工程が手つかずかの棚卸しから始めます。