はじめに
現在、私は多言語対応やコンテンツマイグレーションを伴う、中〜大規模CMSのリニューアル案件に携わっている。
設計要素の多い案件ということもあり、生成AIを積極的に活用している。
設計書のたたき台を作ったり、情報をMarkdownに整理したり、既存コンテンツを分析したりと、以前では考えられないほど作業効率は向上した。
一方で、プロジェクトを進める中で、いくつか気になることがあった。
一つは、経験の浅いメンバーが生成AIを使っても、思ったほど成果物の品質が向上しないことである。
生成AIは、見た目の整った設計書やコードを書いてくれる。
しかし、利用する側が、
- 設計の良し悪しを判断できない
- デザインとの矛盾に気付けない
- 「なぜその設計なのか」を説明できない
- 後工程への影響まで考えられない
という状態では、レビューの際に多くの手戻りが発生してしまう。
また、自分自身もコンテンツモデルの設計を進めていて、生成AIを活用していたにもかかわらず、2時間で設計・レビューできたのは3〜4ページ程度だった。
「AIを使っているのに遅い」のではない。
レビューと設計判断に時間を使っていたのである。
そして、ある日ふと気付いた。
「生成AIを使うと仕事が楽になると思っていたのに、なぜか以前より忙しい。」
この違和感を整理していくうちに、
- TPS（トヨタ生産方式）
- リーン
- TOC（Theory of Constraints：制約理論）
の考え方が、生成AI時代のソフトウェア開発にも応用できるのではないかと思い始めた。
私はTPS・リーン・TOCの専門家ではなく、基本的な考え方を知っている程度である。
また、本記事の考察は、実際の業務で生成AIを活用する中で感じたことを整理したものである。
現在、業務ではMicrosoft 365 Copilot ChatとChatGPT Businessを利用し、個人ではChatGPT Plusを契約している。また、Codexについては使い始めたばかりで、試行錯誤しながら活用している。
私は生成AIそのものを否定したいわけではない。むしろ、現在では業務に欠かせない存在になっている。
本記事は「生成AIは便利か」という話ではなく、「生成AIを前提とした開発プロセスはどうあるべきか」という視点から考えてみた内容である。
そのため、理論の解説や新しい方法論の提唱ではなく、
「生成AI時代の開発プロセスをTPS・リーン・TOCの視点で眺めると、どのように見えるか」
という考察・仮説として読んでいただければ幸いである。
TPS・リーン・TOCに共通するもの
TPS・リーン・TOCは、成立した背景や細かな思想こそ異なるものの、共通している部分がある。
それは、
「全体の流れを最適化する」
という考え方である。
TPSでは、ジャストインタイムや一個流しなどを通して、
- 作り過ぎをなくす
- WIP（仕掛品）を減らす
- 後工程を意識する
- 問題を早く顕在化させる
ことを重視する。
リーンでは、
- ムダをなくす
- 小さく素早く検証する
- 顧客にとっての価値を考える
- 価値の流れを作る
ことを重視する。
TOCでは、
- ボトルネックを見つける
- 制約以上に仕事を流さない
- 制約を最大限に活用する
- 個別最適ではなく全体最適を考える
ことが重要になる。
細かな違いはあるものの、共通しているのは、
個々の工程を最大限に速くすることよりも、全体として価値が流れる状態を作る
という点ではないだろうか。
AIは成果物を生み出す速度を飛躍的に高めた
生成AI以前の開発は、大まかに言えば、
「人が作り、人がレビューする」
という流れだった。
生成AIの登場により、
「AIが生成し、人がレビュー・判断する」
という流れへ変化しつつある。
ここで重要なのは、
ボトルネックが「生成」から「判断・レビュー」へ移動した可能性がある
ということである。
AIは数分で設計書やコードを生成できる。
しかし、
- 正しいか
- 要件を満たしているか
- 保守できるか
- 将来の変更に耐えられるか
- 他の設計やシステムと矛盾しないか
を最終的に判断するのは、現時点では人間であることが多い。
AIは「考えるための材料」や「レビュー対象」を爆発的に供給できるようになった。
一方で、人間の認知能力や、一日に判断できる量そのものが、同じ割合で増えたわけではない。
AIはレビュー対象を増やすことはできても、人間の認知能力そのものを増やしたわけではない。
結果として、人間は以前より多くの成果物を確認し、判断し続ける仕事へシフトする。
これが、
「生成AIを使うと、以前より忙しい」
という現象の一因ではないかと考えている。
ボトルネックはどこへ移ったのか
もちろん、すべての開発現場でレビューがボトルネックになるとは限らない。
要件整理、顧客との合意形成、実装、テスト、環境構築など、案件によって制約になる場所は異なる。
しかし、少なくとも生成AIを積極的に活用する現場では、成果物を作る速度に対して、人がそれを確認し、意味を理解し、採用するかを判断する速度が追いつかなくなる場面は増えているように思う。
TOCの観点で考えると、ある工程だけの処理能力が大幅に上がっても、制約になっている工程の処理能力が変わらなければ、システム全体のスループットはそれほど向上しない。
例えば、生成AIが1日に100件の成果物を作れるようになったとしても、人が1日に10件しか確認できないのであれば、残りの90件は未レビューのまま滞留する。
この状態で「AIが100件生成したから、生産性が10倍になった」と考えるのは、少し違うのではないだろうか。
実際に価値として利用できた成果物が10件であれば、全体としてのスループットは10件である。
AIの生成能力だけを指標にすると、局所的な効率は上がって見える。
しかし、開発プロセス全体で見ると、未レビュー成果物が積み上がっただけかもしれない。
生成AI時代の生産性を考える際には、
AIがどれだけ生成したか
ではなく、
どれだけ人の判断を通過し、実際の価値につながったか
を見る必要があるのではないかと思う。
AI時代のWIP制限
TPS・リーン・TOCでは、それぞれ表現や位置付けは異なるものの、WIP（Work In Progress：仕掛中の仕事）を増やし過ぎないという考え方が重視される。
従来は、
- 人が仕事を抱え込み過ぎない
- 仕掛品や在庫を減らす
- 問題を早く発見する
- ボトルネックを詰まらせない
といった意味合いが強かった。
しかし、生成AI時代では、WIPはさらに別の意味も持ち始めているように思う。
AIへ投入する情報のWIP
生成AIには、巨大な仕様や資料を一度に渡すよりも、
- コンテンツモデル
- コンポーネント
- マイグレーション
- 多言語
- 認証
- 機能単位の仕様
など、小さな単位に区切って考えさせた方が扱いやすい場面が多い。
大量の情報を一度に渡すこと自体が、必ずしも悪いわけではない。
しかし、誤った前提や不完全な要件までまとめて処理させると、その誤りを引き継いだ成果物が広い範囲に生成されてしまう。
小さな単位に区切ることで、
- 問題を局所化できる
- 修正範囲を限定できる
- 前提条件を確認しやすくなる
- AIの出力を段階的に検証できる
というメリットがある。
AIへのインプットについても、一度に処理させる量や、同時に検討する論点を意識した方がよいのではないか。
人がレビューする成果物のWIP
AIは100件生成できても、人は100件レビューできない。
つまり、生成工程ではなく、
人のレビュー能力
がボトルネックになる。
TOC的に考えるなら、ボトルネックの処理能力を超えて成果物を流しても、全体のスループットは向上しない。
むしろ、
- 未レビュー成果物が増える
- 優先順位が分からなくなる
- 誤った成果物を前提に次の成果物が作られる
- レビュー待ちの期間が長くなる
- どこまで確認済みか分からなくなる
といった問題が生じる可能性がある。
生成AIは、前工程の生産能力だけを極端に高める。
そのため、後工程である人間のレビュー能力を意識せずに生成し続けると、開発プロセス全体としてはかえって流れが悪くなることも考えられる。
AIの後工程が人間のレビューであるなら、AIは後工程が処理できる量を意識して使う必要があるのではないだろうか。
AIは「作り過ぎ」を数分で起こせる
TPSでは、一般に
「作り過ぎは大きなムダである」
と考えられている。
これは、生成AIにも当てはまるのではないか。
例えば、要件の解釈が誤っている状態で、大量の設計書やコードを生成した場合、失われるのは生成にかかった時間だけではない。
- 出力トークン
- 推論時間
- 修正工数
- レビュー工数
- 誤りを説明するためのコミュニケーション
- 間違った成果物を前提に進めた後工程の工数
などが無駄になる。
つまり、
未検証成果物の大量生成
こそが、AI時代の「作り過ぎ」なのではないだろうか。
従来の開発でも作り過ぎは問題だった。
しかし、人間が成果物を作る場合、大量生産そのものに時間がかかる。
作成の途中で違和感に気付いたり、周囲から指摘が入ったりする可能性もある。
一方、生成AIは数分で大量の設計書、コード、テストケースなどを生成できる。
つまり、
AIは作り過ぎをなくしたのではなく、作り過ぎる速度を飛躍的に高めた
とも考えられる。
問題が見つかる前に、大量の未検証成果物が生まれ、人間のレビュー能力を簡単に超えてしまう。
生成のコストが下がることで、「とりあえず作らせてみる」という判断はしやすくなった。
しかし、生成コストが低いことと、その後の確認コストが低いことは別の話である。
むしろ大量に生成できるからこそ、何を生成し、何を生成しないかを判断する重要性が高まっているのではないかと思う。
AI時代の在庫とは何か
TPSでは、在庫は問題を隠すと考えられている。
在庫が多いと、工程の不具合や処理能力の差が表面化しにくくなるためである。
AI時代の在庫とは、
- 未レビューの仕様書
- 未確認のコード
- 未検証の設計
- 未評価のAI生成物
- 採用するか決まっていない提案
- 実行結果を確認していないスクリプト
などではないだろうか。
レビューされるまでは、それらは完成した価値ではなく、品質リスクを抱えた仕掛品である。
未レビュー成果物が大量にある状態では、品質上の問題もその中に埋もれてしまう。
どの成果物が正しいのか、どこまで確認したのか、どの前提が古いのかが分からなくなれば、成果物を探し、整理し、比較する作業まで発生する。
さらに、未検証成果物は、人が作る場合よりも損失が大きくなる可能性がある。
人が設計していれば、数ページ書いた時点で違和感に気付くかもしれない。
しかし生成AIでは、数分で数十ページ、場合によっては数百ファイル規模の成果物が生成できてしまう。
間違いが分かった時には、既に大量の成果物が「在庫」として積み上がっている、という状況が起こり得る。
これは、TPSで作り過ぎが問題とされる理由と、よく似ているように感じる。
Pull型生成という考え方
TPSには、後工程が必要とするものを、必要な時に、必要な量だけ前工程から引き取るというPull型の考え方がある。
AIの生成についても、同じように考えられるのではないか。
AIが作れるだけ大量にPushするのではなく、
- まず小さな単位で生成する
- 人がレビューする
- 前提や方向性を確認する
- 必要になった段階で次を生成する
という流れである。
言い換えると、
人がレビューできる分だけ生成する
という考え方である。
レビューが終わったら、次を生成する。
誤りが見つかったら、そこで前提を修正する。
一度に大量生成してからまとめて確認するよりも、少量ずつ生成と検証を繰り返す方が、手戻りの範囲を小さくできる可能性がある。
もちろん、すべての作業を一件ずつ進める必要はない。
定型的な変換や、機械的に検証できる処理であれば、大量生成が有効な場面もある。
重要なのは、生成量をAIの能力に合わせるのではなく、
後工程が処理できる量や、誤った場合の影響範囲に合わせる
ことではないかと思う。
モデルよりも「情報設計」が重要ではないか
ここまで考えると、重要なのは、
「どのLLMを使うか」
だけではなく、
どの情報を、どの粒度で、どの順番でAIへ渡すか
なのではないかと思う。
巨大なrequirements.mdを一つだけ持つのではなく、
- 共通ルール
- コンポーネント仕様
- マイグレーション方針
- ADR（設計判断の記録）
- 機能単位の仕様
- 用語や命名規則
- 確定事項と未確定事項
などに構造化し、必要な情報を必要なタイミングでAIへ渡す。
これは特定のツールだけに限った話ではなく、Claude CodeやCodexなど、多くのAIコーディングツールにも共通する考え方ではないだろうか。
高性能なモデルに大量の情報を渡せば、常に良い成果物が得られるとは限らない。
情報同士が矛盾していたり、古い仕様と新しい仕様が混在していたり、確定事項と仮説が区別されていなければ、モデルの性能が高くても安定した結果は得にくい。
生成AI時代には、成果物の設計だけでなく、
AIに理解させるための情報構造そのものを設計する
という作業の重要性が高まるのかもしれない。
AI時代は「トークン」も経営資源になる
生成AIの普及に伴い、企業では、
- API利用料
- トークン消費量
- 推論に必要な計算資源
- AIサービスの利用枠
- 人がレビューする時間
などが、新たなコストとして意識され始めている。
従来から、企業活動では、
- 人
- モノ
- 時間
- 資金
などが経営資源として扱われてきた。
生成AIを業務で本格的に使うのであれば、そこへ、
- トークン
- AIの利用クレジット
- 推論コスト
- 人がレビューできる情報量
も加わるのではないか。
AIは無限に使える魔法ではなく、
有限の経営資源
として考える必要がある。
実際、私自身もCodexを使い始めた当初、ツールの特性を十分理解しないまま大量の情報を解析させた結果、付帯していたクレジットを短期間で使い切ってしまった経験がある。
当時は単に「使い過ぎた」と考えていた。
しかし、今振り返ると、要求や設計が十分に固まる前に大量の情報を投入し、生成や試行錯誤を繰り返していたことも一因だったのかもしれない。
もちろん、これは一つの事例に過ぎない。
また、生成AIによる作業時間の短縮効果が、利用料金を大きく上回る場面も多い。
そのため、単純にトークン使用量を減らせばよい、という話ではない。
重要なのは、
価値につながる利用なのか、未検証成果物を積み上げるだけの利用なのか
を区別することではないだろうか。
要件の誤りに気付かず大量生成すれば、品質だけでなく、AI利用コストまで失うことになる。
WIP制限は、品質管理や認知負荷の軽減だけでなく、
AI利用コストを管理する考え方
としての意味も持ち始めるのではないかと思う。
「AIがレビューすればよい」という話ではない
ここまで書くと、
「レビューもAIに任せればよいのでは？」
という意見もあると思う。
私自身、AIによるレビューは非常に有効だと考えている。
コーディング規約、静的解析、命名規則、セキュリティ上の問題、仕様間の矛盾の指摘など、AIが代替・支援できるレビューは今後さらに増えていくだろう。
人が見落とした点をAIが指摘したり、複数の観点からレビューさせたりすることで、品質を高められる場面も多い。
しかし、
- この要件解釈で本当によいのか
- この設計は運用まで考えられているか
- 将来の仕様変更に耐えられるか
- 他システムや他工程への影響はないか
- 顧客が本当に求めているものか
- どのリスクを受け入れ、どのリスクを避けるか
といった設計判断や最終的な品質保証については、現時点では人が担う場面が多い。
仮に、
AI生成 → AIレビュー → 人レビュー
という流れになったとしても、最終的なボトルネックが人の判断である限り、WIPやフローを考える意味はなくならない。
AIレビューによって人の負荷が下がれば、ボトルネックの位置や処理能力は変化するだろう。
将来的には、現在人が行っている判断の一部もAIへ移っていくかもしれない。
それでも、その時点でどこが制約になっているのかを確認し、制約以上に仕事を流さないという考え方自体は残るのではないかと思う。
生成AIは仕事を減らすのか
生成AIによって、個々の作業が速くなることは多い。
設計書のたたき台を作る時間、コードを書く時間、情報を整理する時間、既存資料を読む時間は、確実に短縮できる。
一方で、できることが増えた結果、
- より多くの案を比較する
- より広い範囲を確認する
- 以前なら作らなかった資料まで作る
- より短い期間で多くの判断を行う
- 次々と新しい改善点を見つける
という状況も起こる。
一つの作業にかかる時間が短くなっても、その分だけ新しい作業や判断が増えれば、体感として忙しくなることはあり得る。
生成AIによって仕事が単純に減るというより、
仕事の密度が高くなる
という方が近い場面もあるように感じる。
AIが短時間で多くの情報や選択肢を提示することで、人間は以前より短い時間の中で、連続して判断を求められる。
生成AI時代の開発プロセスでは、作業時間だけでなく、人間の認知負荷や判断回数についても考える必要があるのかもしれない。
おわりに
現時点での私の仮説は、次のようになる。
- AIは成果物を生み出す速度を飛躍的に向上させた。
- その結果、ボトルネックが人間の判断やレビューへ移りつつある現場もある。
- AI時代のWIP制限は、人間の認知負荷だけでなく、未検証成果物やレビューコスト、AI利用コストを抑える意味も持つ。
- AIへ渡す情報も、人がレビューする成果物も、小さく流した方が問題を局所化しやすい。
- 未検証のAI生成物は、完成品ではなく品質リスクを抱えた仕掛品と考えられる。
- AIは作り過ぎをなくしたのではなく、作り過ぎる速度を飛躍的に高めた可能性がある。
- TPS・リーン・TOCは、AIそのものではなく、AIを含めた開発フローを設計するためのヒントになるかもしれない。
もちろん、これは実案件を通して考え始めた段階の仮説であり、今後も検証が必要である。
また、TPS・リーン・TOCの専門家という立場でもないため、考え方の捉え違いや、より適切な理論・表現もあるかもしれない。
本記事の目的は、「これが正解だ」と主張することではない。
生成AI時代のソフトウェア開発を、TPS・リーン・TOCの視点で考えてみると、どのようなことが見えてくるのか。
最近、私はそのようなことを考えている。
生成AIは、ソフトウェア開発の在り方を大きく変え始めている。
しかし、変わったのは、設計やレビューが不要になったということではない。
成果物を生み出す能力が飛躍的に向上したことで、人間が判断し、品質を保証し、何を作らないかを決める重要性は、むしろ高まっているようにも感じる。
今後、AIによるレビューや設計支援がさらに進化すれば、ボトルネックの位置も再び変化していくだろう。
それでも、
どこが制約になっているのか どこに仕掛品が滞留しているのか 全体として価値が流れているのか
を考える視点は、AI時代になっても変わらず重要なのではないだろうか。
同じようなことを考えた方がいれば、ぜひ意見を聞いてみたい。
※本記事は、筆者の実務経験と考察をもとに、ChatGPTを文章構成・推敲の補助として利用して作成しています。
