個人は速いのに、組織で止まる――大阪ガスが挑む「止まらない開発組織」のつくり方

コーディングAIを導入すれば、開発速度は自然に上がる。そう考えたくなる。だが大阪ガスのビジネスアナリシスセンター（BAC）がClaude Codeなどを約100人規模の開発者へ広げると、むしろリリース速度が上がらない事態が起きた。「AI要件定義サミット2026」で國政 秀太郎氏が語ったのは、AIを速く動かす話ではなかった。AIが組織の中で止まらず働くための、要件定義、設計、テスト、運用の作り替えである。

個人では速いのに、組織へ入れると開発が止まった

BACは、事業部の課題を見つけ、データ分析で解き、システムとして現場に定着させる社内コンサルティング組織である。年間30件超のプロジェクトを扱い、Google Cloud上にデータ収集、分析、機械学習、アプリ開発の基盤を整え、データを「つなぐ、ためる、つくる、運用する」までを一つの環境で回してきた。

要件定義から運用までを一つの組織が見ていたからこそ、局所的なコード生成の速さと、案件全体の遅さの差も見えている。そうした中、BACは問題をAIツールの使い方ではなく、設計から運用までに残る待ち時間と判断のばらつきとして捉え直した。

開発スピードを上げるための突破口として導入したのがClaude CodeなどのコーディングAIだった。約100人規模の開発者へ利用を広げたが、多くのプロジェクトでリリース速度が想定ほど上がらず、ベロシティ（一定期間にチームが完了できる開発量）が落ちた例もあった。「個人開発ではものすごく速くなったのに、なぜチームに入れると遅くなるのか」と國政氏は振り返る。

出力が増えるほど、レビューできるベテランへ仕事が集中した。テストを通すためにAIが修正を繰り返し、本来の設計から離れることもあった。不具合を含むコードがメインブランチへ入ると、別のブランチのAIはそれを正しい前提として参照し、誤りを増幅する。AIが遅かったのではない。速く働くAIを受け止める開発構造が、従来のままだったのが原因だ。

ボトルネックは、設計・テスト・運用に残った属人性

BACが洗い出した問題は3つある。①設計とコーディング、②テスト、③運用である。開発標準はあっても、設計思想やアーキテクチャの選択はプロジェクトマネージャーやアーキテクトに委ねられていた。AI向けのスキルも案件ごとに作られ、同じ基盤上のプロジェクトでも前提がそろっていなかった。

テストでは、カバレッジや結果をレポートに出しても、基準未達のコードをマージするかは人の判断に残っていた。納期が迫れば例外が積み上がり、受け入れテストで不具合が表面化する。プレビュー環境が一つか二つしかなければ、確認待ちも発生する。AIがコードを速く作っても、検査の順番待ちで開発は止まっていた。

運用にはさらに多くの要素がある。エラーログだけでなく、関連するソースコード、仕様書、発生時のデータベース状態をそろえなければ原因を追えない。開発と運用の部隊を分けても、初期障害では開発者が呼び戻される。

國政氏は「AIは掛け算である」と表現した。指示する人の業務知識、設計の質、テスト基準がそろっていれば速度を増幅する。前提がばらつけば、そのばらつきも増幅する。モデル選びより先に、何を正解として渡すかを組織で決める必要があった。

この見立てに立つと、AI導入の評価も個人のコード生成量だけでは足りない。要件が設計へ渡り、検査を通り、障害対応で得た学びが次の開発へ戻るまでを一つの流れとして測る必要がある。BACが手を入れたのは、AIの出力そのものより、その出力が組織の成果へ届くまでの経路だった。

AIが走れる高速道路を、要件定義からログまで通す

BACは、AIを「優秀な部下だが、自社をよく知らない新人」と捉え、各工程の配置を作り直した。要件定義では、Notion AIにベテランが確認する論点やアンチパターンを仕込み、議事録などの材料から業務要件、機能要件を順に生成する。所定のページを提出しなければ次工程へ進めない運用にした。

詳細設計は、ドメイン駆動設計（DDD）に統一した。ドメイン層、ユースケース層、インフラ層といった共通語で事業部、開発者、AIが会話する。機能を適切な粒度に分け、AIへ渡す文脈を狭めることで、長い指示の途中で前提を失う問題も抑えた。

テストは共通レポートへそろえ、基準を一つでも満たさなければCI（テスト結果を自動判定し、不合格ならマージを止める仕組み）がマージを止める。人が例外を認める余地を減らし、AIが参照するメインブランチを正しい状態に保つ。E2Eテストでは、プルリクエストごとに独立したプレビュー環境を立ち上げる。講演資料では、並列1,000件の変更に対して1,000環境を自動で用意する構成を示した。

プルリクエストを出すと、講演で示された運用例では約10分後に専用URLが発行される。確認者は社内認証を経て、その変更だけが反映された画面やAPIを確かめられる。コード生成を速くするだけでなく、確認環境の待ち時間も減らさなければ、チーム全体の速度にはならないという設計である。

國政氏はAIを、少し自動運転できるスポーツカーに例えた。砂利道で無理に速度を上げれば事故る。だからこそ、非決定的に動くAIの前後へ、テストやログ取得のような決定的な仕組みを置く。AIの性能を上げる前に「高速道路と交通ルール」を用意するという考え方である。

残る仕事は、プラットフォームを作る人とAIの上司

講演では、エース級の開発者3人が半日以上かけた初期運用のインシデント対応を、同じ種類の仕組みで最速30分以内まで短縮した例が紹介された。単に回答文を作るのではなく、発生時のデータを取り寄せ、修正コードまで出せる状態にした効果である。個別事例の数値ではあるが、運用まで標準化する意味を示している。

自動化が進んだ後に残る役割として、國政氏は2つを挙げた。一つは、AIが安定して走れる共通環境を作るプラットフォームエンジニア。もう一つは、業務を理解して仕事を切り出し、AIの成果物に説明責任を持つ「AI上司」である。

「全人類がAIの上司になった」。この言葉が指すのは、全員がAIを操作するというだけではない。仕事を分けて指示し、結果を検査し、成果物への説明責任を引き受ける側になったということだ。明日、能力の高い新人が加わったとき、すぐ仕事を任せられる要件、設計、検査、運用の環境があるか。AI導入後の速度差は、モデル性能より受け入れ側の設計に表れる。