良い制約こそが、ソフトウェアの黄金期と私のキャリアを形作ってきた。12 ファクターアプリの原則や MVC のような、いくつかの意見が明確なアプローチは、信頼性の高いサービスを構築し、関心事の分離を設計するための共通言語を与えてくれた。シンプルなルールで、示すのは簡単だが、完璧に従うのは難しい。それらは SaaS、PaaS、クラウドインフラといった産業全体を生み出した。すべては、よく練られた制約の上に築かれている。その制約は、ビルダーにこう告げる。「ここが境界だ。この境界の範囲内に留まれ。そうすれば良い結果が得られる」と。私は自身の最高の仕事のいくつかで、これらの制約を適用することで個人的に恩恵を受けてきた。
AI ネイティブなソフトウェアには、独自の制約が必要だと私は考えている。以下が、私が考え出した制約だ。
あなたのコードベースには最大サイズが存在する。これは好みの問題ではない。その限界は現実的で、測定可能であり、あなたが思っているよりも小さい。
その限界とは、あなたのエージェントが製品を構築・保守するために使用する AI モデルのコンテキストウィンドウの半分である。つまり、中核となるビジネスロジックとシステムコンテキストのサイズは、依存する LLM のコンテキストウィンドウの半分を超えてはならない。
なぜ半分なのか？コンテキストウィンドウには 2 つの目的がある。最初の半分はコードを保持する。次の半分は、エージェントが推論、計画、生成を行う場所だ。ウィンドウ全体をコードで埋めれば、思考する余地はゼロになる。半分は理解のために。半分は認知のために。
ソフトウェアビジネスにおいて最も難しい部分は、決して機能を構築することではなかった。
経験豊富なテックファウンダーは皆知っている。難しいのは、十分な規模の顧客セグメントに対して最小限の有用なソフトウェアを特定し、その後、顧客獲得、カスタマーサービス、リテンションという困難な作業に人々を結集させることだった。
ソフトウェアを構築するのはかつては高価だった。エンジニアのコストは高かった。これにより摩擦が生まれ、反復的な開発プロセスが生まれたが、同時に規律も課せられた。選択を迫られたのだ。顧客が最も必要としているものは何か？構築する価値がある最小のものは何か？エンジニアリングの人件費がチームの集中力を維持した。制約が明確さを生み出した。シリコンバレーの最高の企業は、このようにして成長した。
今や AI エージェントは、依頼すればほぼ何でも構築してしまう。ボトルネックは消えた。ボトルネックとともに規律も消えた。
自由な生産は過剰生産を招く。過剰生産は、AI ネイティブ企業のデフォルトの失敗モードである。
非技術系のファウンダーや投資家はこれを理解する必要がある。より多くの機能、より多くのコード、そして保守すべきプロダクトサーフェスエリアの増加は、もはや進歩の兆候ではない。それらは、質の高い制約を欠いた企業、そして時には根本的な明確さの欠如を示している。
スケーラブルな流通と消費なしの過剰生産は、価値の獲得に大きな漏れを生み出す。10 の機能をリリースする。2 つがリテンションを促進する。残りの 8 つは複雑さを増し、重要な 2 つを遅らせる。コードの 1 行 1 行は、資産を装った負債になる。
経験豊富なビルダーは転換点を知っている。コードは、顧客にサービスを提供することから、自分自身にサービスを提供することへとシフトする。複雑さは製品の敵になる。チームは、顧客体験を改善するよりも、ソフトウェアの管理に多くの時間を費やす。システムは使いにくくなり、ユーザーは離脱し始め、カスタマー対応チームは静かに不満を募らせる。
かつての世界では、その転換点に達するまでに何年もかかっていた。AI ネイティブの世界では、転換点に数週間で達する。エージェントは決して疲れを知らず、決して反論せず、決して「これは複雑すぎる、やめるべきだ」とは言わない。
いつ止めるべきか、どうやってわかるのか？AI が無制限に無料でコードを書くとき、十分だと告げるシグナルは何か？
それが「ハーフウィンドウルール」である。
中核となるビジネスロジックは、コードベースを保守するモデルのコンテキストウィンドウの半分に収まらなければならない。コードベースをトークンで測定せよ。それをコンテキストウィンドウの半分と比較せよ。超えているなら、あなたの AI 労働力はすでに劣化している——目に見える形ではなく、劇的でもなく、しかし静かに、着実に。
危険性：この線を越えても、明らかに何かが壊れるわけではない。エージェントは拒否しない。コードは正しく見える。テストは通る。報告されたバグは修正される。
しかし、エージェントは今やシステムを完全に理解せずに動作している。エージェントは全体を推論する代わりに、断片にパターンマッチングを行う。微妙なリグレッションが現れる。ロジックがエージェントの見えないコードベースの部分で重複する。問題は、既存のコードを変更すべき箇所で、コードを追加することで「解決」される。
あなたはすぐには気づかないだろう。ベロシティはまだ高いと感じる。プルリクエストはまだ流れる。それぞれが次のプルリクエストを少しずつ悪化させる。複合的な劣化があなたに不利に働く。
「なぜエージェントが同じところをぐるぐる回っているのか？」と疑問に思う頃には、問題は深刻化している。
このルールは、技術的な衣をまとったビジネス規律である。
生産コストがゼロになったとき、シンプルさが競争優位性になる。顧客に真の価値を提供する最小のコードベースを構築せよ。不必要な機能、不要な抽象化、推測によるコードの 1 行 1 行が、AI 労働力の認知予算を食いつぶす。やがて、それらは会社の動く力を蝕む。
最高の製品は、常に、現実の問題を完全に解決する最もシンプルなものであった。この原則に違反した場合の罰則は、今やより速く到来し、より強く累積する。AI エージェントは、不満を抱えたシニアエンジニアのように反論することはない。
このルールはアーキテクチャに応じてスケールする。単一プロダクトのスタートアップ：コードベース全体に適用する。マルチサービスの企業：各サービスに独立して適用する。システムの中で全体として理解されなければならない部分は、エージェントが全体像を推論する境界内に収まらなければならない。
あなたのプロダクトアーキテクチャは、エージェントの認知境界を反映するものになる。それを意図して設計するかどうかに関わらず。意図的にこのために設計するファウンダーは、苦痛を通じて学ぶ者たちを凌駕するだろう。
これは完璧を求めるものではない。常に線の内側に留まれるわけではない。コードベースは成長する。機能が追加される。複雑さは蓄積される。重要なのは、厳格な遵守ではなく、目標を持つことだ。このルールを念頭に置き、境界に近づき続ければ、何を構築し、何を分割し、何を削除するかについて、より良い判断ができるようになる。この制約は、「もっと構築しろ」とすべてが言うときに、基準点を与えてくれる。時には、ルールに適合するようにサブエージェントアーキテクチャを再設計することも意味する——これは、人間のチームが成長に伴って所有権を分割する方法と非常によく似ている。
私は自身の仕事でこのルールに従うよう努めている。ルールを破ることが即座の失敗を意味するからではなく、この制約に近づき続けることで、長期間にわたって有用で、保守可能で、価値のあるソフトウェアを構築する助けになるからだ。このルールを軸に据えるファウンダーは遠くへ行くだろう。制約を完全に無視する者たちは、苦痛を通じて学ぶことになる。
良い制約は成功を保証するものではない。しかし、最も一般的な失敗の仕方を排除することで、成功の可能性を高める。12 ファクターアプリは、SaaS 企業を自動的に構築してくれる一連の原則ではなかったが、それに従えば、スケールが必要なときにインフラが機能した。ハーフウィンドウルールもまったく同じように機能する。精神に従え。境界に近づき続けよ。永続する有用なソフトウェアビジネスを構築せよ。
シンプルさは常に勝つ。今やシンプルさはより速く勝つ。
著者について：Abhishek Parolkar は、https://brain.pe の CEO であり、プライベートエクイティ企業が自社または特定の取引のためにデジタル AI ブレインを作成するのを支援している。あなたは AI を採用したかもしれないが、AI はあなたを採用しただろうか？
