ソフトウェア開発のボトルネック変遷：計算資源から認知資源、そしてこれから

導入：ボトルネックは移動する

制約理論（Theory of Constraints）の基本的な洞察は単純だ。どんなシステムにも必ず1つのボトルネックがあり、それを解消すると次のボトルネックが顕在化する。 ボトルネックは消えるのではなく、移動する。

ソフトウェア開発の歴史は、このボトルネックの移動の歴史として読み直すことができる。そしてその移動の先にある現在の地点を見ると、人間とAIが驚くほど同じ種類の制約に直面していることが分かる。

計算資源がボトルネックだった時代

1960年代から1990年代にかけて、ソフトウェア開発の中心的な制約はコンピュータの物理的リソースだった。メモリは高価で、CPUサイクルは貴重で、ストレージは限られていた。

この時代の開発者の主要な関心事は「いかに少ないリソースで動かすか」だった。データ構造とアルゴリズムの選択は、計算量やメモリ使用量の最適化を意味していた。バブルソートとクイックソートの違いは理論的な関心ではなく、プログラムが実用的な時間で終わるかどうかの死活問題だった。

この時代に生まれたプラクティスは、計算資源という有限リソースの管理戦略だ。

• アルゴリズムの計算量解析（O記法）— 有限のCPU時間をどう配分するか
• データ構造の最適化 — 有限のメモリをどう構造化するか
• キャッシュ戦略 — 遅い記憶装置へのアクセスをどう減らすか
• データベースの正規化とインデックス設計 — 有限のストレージとI/Oをどう効率化するか

これらのプラクティスに共通するのは、有限のリソースに対して、何を保持し、何を捨て、どう構造化するかを設計するという思考パターンだ。この構造は、後の時代にも繰り返し現れる。

認知資源がボトルネックになった時代

2000年代以降、状況は大きく変わった。ムーアの法則による計算能力の指数的向上、クラウドコンピューティングの普及、ストレージコストの劇的な低下。計算資源はもはや多くのソフトウェアにとって主要な制約ではなくなった。

ところが、生産性は計算資源の向上に比例して伸びなかった。Fred Brooksが1986年に「No Silver Bullet」で指摘した通り、ソフトウェア開発の本質的複雑性は技術の進歩では消えない。計算資源のボトルネックが解消されたことで、次のボトルネックが顕在化した。人間の認知能力だ。

人間のワーキングメモリは約4±1チャンクしか保持できない。どれだけコンピュータが高速になっても、システムを設計し、理解し、変更するのは人間だ。コードベースが数百万行に膨れ上がったとき、ボトルネックは「コンピュータがそれを実行できるか」ではなく「人間がそれを理解できるか」に移った。

この時代に生まれたプラクティスは、認知資源という有限リソースの管理戦略だ。

• モジュール化 — システムを認知可能な単位に分割する。一度に理解すべき範囲を制限する
• Domain-Driven Design — ユビキタス言語で翻訳負荷を削減する。ドメインとコードの間の概念変換コストを最小化する
• Team Topologies — チーム構造を認知負荷に基づいて設計する。コンウェイの法則を逆手に取って、認知的に管理可能な境界でチームを分割する
• 関心の分離、インターフェース設計 — 「知らなくていいこと」を明確に定義する

ここで注目すべきは、これらのプラクティスが計算資源時代のプラクティスと同型の構造を持っていることだ。

どちらも本質的には同じ問題に取り組んでいる。有限のリソースに対して、何を保持し、何を捨て、どう構造化するか。 対象がCPUサイクルとメモリからワーキングメモリとアテンションに変わっただけだ。

AIにおける同型の制約

そして現在、AIがソフトウェア開発に参入してきた。AIは「コードを書く」というボトルネックを大幅に緩和しつつある。しかし、AIもまた有限リソースの制約から逃れていない。

LLMのコンテキストウィンドウは、人間のワーキングメモリと驚くほど類似した制約構造を持つ。

量的なスケールは異なるが、制約の構造が同型だ。どちらも「有限の処理容量の中で、どの情報を保持し、どの情報を外に出し、どう構造化するか」という問題に直面している。

この類似性が示唆しているのは、認知資源時代に発展したプラクティスが、AIのコンテキスト管理にもそのまま適用可能だということだ。

• モジュール化 → コンテキスト分離：サブエージェントに独立したコンテキストウィンドウを持たせ、結果のサマリーだけを返す。人間がモジュールの内部実装を知らなくていいように、親エージェントはサブエージェントの詳細を知らなくていい
• ユビキタス言語 → 共有語彙の設計：人間とAIの間、あるいはAIエージェント間で概念のズレを減らすことで、翻訳負荷を削減する
• Team Topologies → マルチエージェント設計：エージェントの責務をコンテキスト負荷に基づいて分割する
• 段階的開示 → 必要な情報のみを読み込む：すべてをコンテキストに詰め込むのではなく、必要に応じて情報を取得する

有限リソース管理という不変の問題構造

ここまでの議論を振り返ると、ソフトウェア開発の歴史を通じて同じ問題構造が繰り返し現れていることが分かる。

有限リソース → 管理戦略の発展 → ボトルネックの解消 → 次の有限リソースの顕在化

計算資源の制約に対してアルゴリズムとデータ構造が生まれ、認知資源の制約に対してモジュール化とドメイン設計が生まれ、コンテキストウィンドウの制約に対して同型の管理戦略が適用される。

これは、ソフトウェア開発が本質的に**「有限リソースの中で複雑性をどう管理するか」という問い**に取り組み続けてきたことを意味している。リソースの種類が変わっても、問いの構造は変わらない。

そして、この視点は実践的な含意を持つ。AIツールの設計やAIとの協働方法を考えるとき、ゼロから新しいパラダイムを発明する必要はない。数十年かけて蓄積されたソフトウェアエンジニアリングのプラクティスは、対象リソースを読み替えるだけで驚くほどそのまま適用できる。認知負荷を管理するために学んできたことが、コンテキストウィンドウの管理にも活きる。これは、エンジニアにとって朗報だと思う。

その先の問い：コンテキストの制約が消えたら

ただし、一つ留保がある。

計算資源の制約が（実質的に）解消されたように、コンテキストウィンドウの制約もいずれ大幅に緩和される可能性がある。ウィンドウが事実上無限に広がり、AIが任意の量の情報を同時に処理できるようになったとき、次のボトルネックは何になるのか。

計算資源時代の経験が教えてくれるのは、制約の解消は問題の解消ではなく、問題の移動だということだ。計算資源が潤沢になっても、ソフトウェアは良くならなかった。次のボトルネック——人間の認知能力——が顕在化しただけだった。

同様に、コンテキストウィンドウが無限になっても、それだけでソフトウェアは良くならないだろう。その先には、「何を作るべきか」「誰の欲求に応えるべきか」「共有される概念をどう設計するか」という、量的な制約では解けない問いが待っている。

---

関連記事

• AI時代の「仕様」問題：翻訳方向の非対称性とSSoTの所在 — 意図と実装の翻訳問題
• 「仕様」の正体：Requirements・Contract・Structureによるソフトウェアの理解 — 仕様の多層構造