AI駆動開発のボトルネックを解消する5ステップ｜TOC活用法【Qiita AI Summitレポート】
生成AIの進化により、コーディングやプルリクエスト作成の速度は飛躍的に向上しました。しかし、「実装は速くなったのに、なぜか全体のリリース速度が変わらない」という違和感を抱えるチームは少なくありません。AI駆動開発が浸透するにつれ、コードのブラックボックス化や「ダークファクトリー化」、そしてコードレビュー待ちの滞留といった新たなボトルネックが浮き彫りになっています。
2026年9月に開催された「Qiita AI Summit」において、レッドハット株式会社は局所最適化の罠に陥らないための実践知見を提示。TOC（制約理論）に基づく「5ステップの開発プロセス改善法」と、人間の関与を「将来への投資」と捉えるアプローチを共有しました。本稿では、AIのスピードを組織全体のデリバリー力へ昇華させるためのセッション内容をお届けします。
※本セッションレポートは2026年9月時点の内容です。
目次
プロフィール
サービス事業本部 コンサルティングサービス部 Architect, Agile Development Coach
サービス事業本部 コンサルティングサービス部 コンサルタント
レッドハットが目指すイノベーション支援
みなさん、こんばんは。レッドハット株式会社（以下、レッドハット）です。本日はお忙しい中ご参加いただき、ありがとうございます。今回は「AI駆動開発におけるボトルネックの考察と、その立ち向かい方」というテーマで発表します。
今、様々なカンファレンスや勉強会では、「AIで開発がどう変わるか」「ボトルネックがどこにあるか」などのテーマでお話を聞く機会が多いと思います。本日は、我々が実際の開発現場に入り込んで培ってきた泥臭い知見や実態を、凝縮してお届けします。ぜひ何か1つでも持ち帰っていただければと思っております。
レッドハットといえば、まずOSやアプリケーションプラットフォームを思い浮かべる方が多いかもしれません。私たちはそうしたOSから、クラウドネイティブなアプリケーションプラットフォーム、インフラ自動化ツール「Ansible」の提供、インテグレーションの基盤、エッジコンピューティングも提供しています。さらには、AI領域に関して言えば、モデルの提供・運用を支えるAIプラットフォーム「OpenShift AI」も展開しています。
さらに、「プロフェッショナルサービス」という組織があります。ここでは単に製品を導入するだけでなく、お客さまのエンジニアリング組織の改革、プロセスの変革、そして開発文化の変革までを伴走して支援しています。特に我々が展開している「オープンイノベーションラボ」では、お客さまと一緒に現場にディープダイブし、良いビジネスアイデアを考えてそれを素早く市場へリリースしていくためのライフサイクル全体を、いかに高速化・最適化していくかをご支援しております。プロフェッショナルサービス部門では、「AI駆動開発」に関連したサービスを展開しています。
本日は、「AI駆動開発」サービスを実施する実際の現場で我々が見てきた「AI駆動開発のリアルな課題と解決策」について、生の声としてお話しします。
AI駆動開発への期待と現場の現実。コード量増加の裏に潜む「ダークファクトリー化」の危機
さて、本題に入りましょう。みなさんご承知の通り、今や「AI駆動開発」は大きな注目を集めており、経営層や役員、マネジメント層から現場に対して「AIを使って生産性を上げてほしい」という期待が降りてきているのではないでしょうか。
ここで現場において求められる「生産性」とは、現状、多くの場合「アウトプットの量」を指しています。作成されたコードや、提出されたプルリクエスト（以下、PR）の量などを指しています。これらを上げるために、どれだけAIに作業を任せられるかという点が主題になると考えています。
エンジニアがAIとペアプログラミングをしながら書いていくスタイルもあれば、「ソフトウェアファクトリー」のように、要件からデプロイまでを全て自動化する環境を構築されている方たちまで、様々な形があります。
ここでよく議論になるのが、「AIが書いたコードに対して、どこまで人間が関与し続けるべきなのか？」という非常に根深い問題です。AI駆動開発の現場で実際に起きている4つの深刻な課題として、以下が挙げられます。
(1)コードの「ブラックボックス化」:
AIにどんどんタスクを投げていくと、人間はコードを読まなくなりますし、コードの挙動を自分たちの言葉で説明することもできなくなっていきます。これがコードの「ブラックボックス化」です。
(2)ダークファクトリー化：
さらに危険なのが「ダークファクトリー化」です。自分たちでADR（Architecture Decision Records）に記録した設計方針や、時間をかけて議論したドメインモデリングの内部構造と、AIが実際に出力したコードとの間に大きなズレが生じていても、誰もそれに気づかないままシステムが組み上がっていってしまうのです。
(3)コードスメルの増加と認知複雑度の上昇：
また、既存システムが存在するプロジェクトでは、AIは「既存のコード」をお手本にしてコーディングを行います。もし既存のコードが汚ければ、AIもそれに合わせて汚いコードを吐き出します。結果としてコードスメルが増加し、認知複雑度が高まり、どんどんメンテナンス性が低くなってしまう懸念があります。
(4)エンジニア自身の経験の喪失：
そして何より、「人間の、エンジニアとしての経験が奪われていく」と考えています。ほとんどの問題はAIが解いてくれます。AIが書いたコードが動けば、人は中身を読まなくなりますが、そうすると、人が読まないままのコードが積み上がり、結果として中身を説明できる人がいなくなってしまいます。出力されたコードに対して安易にYESを出し続けてしまうと、自力で深く考える経験が蓄積されません。
完全にワークフロー化・自動化を進めた結果、もしAIが正しいコードを出力してくれないような複雑な例外要件に直面したときや、生成に時間がかかって解決できない事態に陥ったときには、人間が自力で解く能力が残っておらず、すでに手遅れになっているケースが多いと思います。
「人の関与」はボトルネックの原因か、将来への投資か？
では、人間はAIが出力したコードに対してどこまで関与すべきなのでしょうか？ 私は正解はないと思っていますが、「判断を外したときに、どのような損失があるか」をあらかじめ考えておくことが、一つの案かなと思います。
「人間の関与を残してコードの理解やチェックを行ったが、実はチェックしなくても問題なかった」という場合、失われる損は「コード理解に費やした工数（時間）」だけです。一方で、「人間の関与を極力減らして自動化したが、実は手動チェックが必要だった」という場合、発生する損は「後から大量の汚いコードを修正し、自分たちにシステム主権を取り戻す」という、とてつもなく重いリカバリー作業になります。無駄な時間を発生させる損と、後からすべてを直す損。どちらを手間として捉えるかが、大きな考え方になると思います。
上層部から「生産性を上げろ」と叩かれている現場では、人間がコードに関与する時間は一見すると開発を遅らせる「ボトルネック」のように見えるかもしれません。ですが、「AIが解く問題を、人間自身も解ける状態に維持しておくことは、単なる無駄なコストではなく、将来に向けた大切な『投資』である」 という考え方もあるのではないでしょうか。
そのため、生産性を向上させると同時に、いざという時に自分たちの手にコントロールを取り戻せる状態を作っておくことが重要です。そのための具体的なアクションは、以下の通りです。
エンジニアリング教育への投資：AIが出力したコードをしっかり読み解き、アーキテクチャや設計の妥当性を正しく判断できるエンジニアを組織に育て、残すこと
テスト自動化への投資：システムに不具合や意図しない変更が起きた時に、すぐに検知できるテストを、日頃からしっかり育てること
現場で「このコード、説明できません」となったら、安全な方に倒すのが最も良い選択だと考えます。とはいえ、AIのアウトプット量は増え続ける一方ですので、開発プロセス全体の「フロー効率」を意識しなければならない問題は残ります。ここからは、このフロー効率への対処について、お話しします。
TOC（制約理論）で解き明かす「実装10倍速」の罠──ボトルネックは消えず、次の工程へ移動する
改めまして、齋藤と申します。先ほどの「ボトルネックと投資」という概念を踏まえた上で、そのボトルネックを具体的にどう扱っていくかというお話をさせていただきます。
まず前提として、「AIを導入しても、ボトルネックは消えてなくなるわけではなく、別の場所へ移動するだけである」ということを伝えさせてください。みなさんも様々なカンファレンスなどで耳にされているかもしれません。AIによって実装の処理能力が上がると、その前後の工程が新しい制約になってきます。
いくらAIを使って実装のスピードを10倍に早めたとしても、顧客に価値を届ける全体のリードタイムが10倍になるわけではありません。一部の工程だけを早める「局所最適化」は、全体の最適化にはつながらないのです。まさにこれこそが、TOC（Theory of Constraints：制約理論） が主張しているコアな現象そのものです。
工場を舞台にした具体例として、例えば「前後の工程が1時間に『100個』製造できる能力を持っていても、途中の1工程が1時間に『25個』しか処理できなければ、工場全体から出てくる完成品は1時間に『25個』にしかならない」という話があります。つまり、システム全体の「スループット」は、最も能力が低い「制約」によって決まるということです。
TOCにおける「改善の5つのステップ」というフレームワークが体系化されています。我々が現場をご支援する際も、この5ステップに沿って改善を進めています。
- ステップ1：制約を特定する（Identify）：システムの中で最も流れを止めている場所（制約）を見つけ出す
- ステップ2：制約を徹底的に活用する（Exploit）：追加投資をする前に、今ある制約の能力を無駄なく100%使い切る
- ステップ3：すべてを制約の決定に従わせる（Subordinate）：制約以外のすべての工程のペースを、制約の処理能力に同期させて、処理できない仕事を作りすぎない
- ステップ4：制約の能力を高める（Elevate）：ステップ2・3でも能力が足りない場合に、追加の資源や投資を行って制約を強化する
- ステップ5：制約の移動を確認し、繰り返す（Repeat）：制約が解消して別の場所に移動したら、惰性を防ぎ、ステップ1へ戻る
現場で成果を出すTOC実践アプローチ、バリューマップ可視化からPR流量制限まで
では、我々が実際に支援させていただいているお客さまの現場で、このTOCの5ステップをどのように具体化しているかをお話しします。分かりやすく一般化した例でご紹介します。
【ステップ1】制約を特定する：バリューマップでプロセスの「滞留」を可視化する
我々がアセスメントに入る際、まず最初に行うのが「バリューマップ（Value Stream Map）」の作成です。お客さまの開発プロセス全体を描き出し、要件定義から実装、レビュー、デプロイに至るまでの各工程で、どこにどれだけの待ち時間（リードタイム）が発生しているかを可視化していきます。
あるお客さまの例では、工程全体の時間経過を分析したところ、実装後の「コードレビュー待ち時間」が実に6日間に及んでいることが判明しました。他のどの工程よりもレビューで仕事が滞留していたのです。これにより「まずはレビュー待ちを解消することで、価値提供速度の向上に最も貢献するのではないか」という仮説に至りました。
【ステップ2】制約を徹底的に活用する：レビュー作業を切り分け、人間の集中力を守る
ボトルネックが見つかると、すぐに投資したくなりがちですが、まずは今ある制約の能力を無駄なく使い切る工夫をします。レビューがボトルネックであれば、レビュアーが本当に必要な判断に集中できるように、仕組みを整えることです。
例えば従来のレビューでは、フォーマットの確認、Lint確認、セキュリティ診断、例外ケースの判断、アーキテクチャの判断などを、一人のレビュアーが全部背負ってパンクしてしまっていたとします。そこで役割分担をして、自動化できるものは自動化していきます。
- 機械的チェックの自動化：Lint、SAST、DAST、自動テストなどをパイプラインに組み込み、機械的に判定できるものはすべて自動化する
- AIによる一次レビュー：コードの文脈や意味論的な妥当性は、AIエージェントに一次レビューさせる
- 人間の注力領域の純化：人間は「設計上の重要判断」や「例外ケースの判定」という、人間でしかできない業務にのみ集中させる
このように制約である人間のレビュー作業を純化することで、既存リソースのままで処理能力を極限まで引き出すことができます。
【ステップ3】すべてを制約の決定に従わせる：PRの流量を制限し「見えない在庫」を撲滅する
他の工程を制約のペースに合わせて、処理できない仕事を作りすぎないということです。処理できない仕事は、必ず他の工程に影響を及ぼすためです。
例えば、1日に最大5件のPRしか消化できないレビュアーに対し、AIを使った実装チームが1日10件のPRを依頼したとします。さばききれない5件は「見えない在庫」として滞留し、コンフリクトの多発、認知負荷の増大、コンテキストスイッチの増加、そして将来的なメンテナンス性の著しい低下につながり、結果として開発全体の足を引っぱってしまいます。
そこで「PRの提出数を1日5件に制限する」 というルールを適用します。トヨタ生産方式（TPS）における「つくりすぎのムダ」と同じです。作り出せる量ではなく、全体のパイプラインを「流れる量」に合わせるのです。余った前工程のリソースは、別の価値ある作業に割り当てて有効活用できます。
【ステップ4】 制約の能力を高める：チームトポロジーと権限移譲による組織構造改革
ステップ2と3をやり尽くしてもなおレビュー能力が不足する場合に、初めてステップ4として投資やリソースのアロケーションを行います。
例えば、承認権限を開発チーム内へ移譲し、仕事と判断の距離を近づけることで、チーム内で迅速にレビューと決定が完結する組織構造へと強化を図ります。
【ステップ5】繰り返す：制約の移動を追跡し、古いルールを捨て去る
レビューのボトルネックが解消されると、制約は要件定義やQAといった別の工程へ移動します。以前の制約に合わせて作ったルールを惰性で残さず、バリューマップを定期的に分析し直し、改善サイクルを絶え間なく回し続けることが不可欠です。
おわりに：全社最適のプロセス変革を目指して
最後にまとめです。AI時代において本当に必要なのは、要件定義エージェントやコードレビューエージェントといったものを個別に作って、各工程を単体で「点」で高速化することではありません。
重要なのは、「全体の価値の流れを見た時に、どこが現在の制約になっているのか」 を組織として継続的に問い続けることです。そのための非常に有効なフレームワークの一つが、本日ご紹介したTOC（制約理論）です。
レッドハットのプロフェッショナルサービスでは、このような「AI駆動開発コンサルタント」がお客さまの現場に入り、単なるAIツールの導入支援だけでなく、デリバリーパフォーマンス全体を向上させるための組織変革・プロセス変革をご支援しています。
現在、採用募集も行っておりますので、ご興味のある方はご応募いただけますと幸いです。本日はご清聴いただき、誠にありがとうございました！