コンテキストを減らすほど、システムは賢くなる: AI開発とモノレポ設計に共通する発想

使えるはずの頭脳が、なぜすぐ詰まるのか

大きな仕事ほど、なぜか突然うまく進まなくなる。コードは書ける、仕様も分かっている、ツールも揃っている。なのに、途中から判断が鈍り、確認が増え、修正のたびに別の箇所まで不安になる。原因は能力不足ではなく、コンテキストの飽和であることが多い。

これはAIの世界だけの話ではない。人間の作業でも、ひとつの巨大な文脈にすべてを押し込むと、理解は深まるどころか浅くなる。情報が増えるほど賢くなるのではなく、むしろ「何を今見なくてよいか」を見失う。そこで効くのが、仕事を分割し、役割ごとに視界を限定する設計だ。

一見すると、これは単なる整理術に見える。しかし本質はもっと深い。複雑さを一箇所に集約して制御するのではなく、複雑さを小さな境界で分散統治するという発想である。AIのサブエージェントも、pnpmを使ったモノレポ管理も、同じ原理で動いている。

本当に解くべき問題は「情報量」ではなく「境界設計」

多くの人は、詰まりの原因を「情報が足りない」と考える。だからログを足し、メモを増やし、仕様を詳細化し、文脈を長くする。しかし実際には、問題の中心は逆にある。情報が多すぎて、意味の境界が曖昧になることだ。

たとえば、コードレビューを想像してみてほしい。変更点が巨大なひとつのPRにまとまっていると、レビュー担当者は「何を守るべき変更で、何が副作用なのか」を切り分けられない。結果として確認範囲が広がり、品質保証は形式的になる。ここで必要なのは、もっと多く読むことではない。責務を分け、見るべき範囲を狭めることだ。

AIのタスク分解も同じである。ひとつのモデルに長大な背景、実装、検証、改善案まで全部持たせると、注意資源が散る。だが、品質チェックだけを担当する小さな役割を切り出すと、そのエージェントは「何を良しとし、何を危険とみなすか」に集中できる。これは能力の削減ではなく、認知の純度を上げる行為だ。

強いシステムは、すべてを知っているシステムではない。見なくてよいものを決められるシステムである。

この視点は、開発組織にもそのまま当てはまる。チームが大きくなるほど、全員が全体を理解することは不可能になる。だからこそ、アーキテクチャだけでなく、パッケージ構成、責務分離、レビュー範囲、AIへの役割付与まで含めて、境界を設計する必要がある。

サブエージェントとモノレポは、どちらも「注意の分権化」である

サブエージェントの魅力は、単に作業を自動化することではない。一つの会話の中で発生する認知負荷を、役割ごとに分けられることにある。実装者は実装に集中し、品質チェック担当は品質だけを見る。人間が全部を同時に抱えると起きる、視野の混線を避けられる。

ここで面白いのは、pnpmを使ったモノレポ設計にも同じ感覚があることだ。モノレポは本来、複数のパッケージをひとつの倉庫にまとめる発想だが、うまく運用するには、ただ「全部同じ場所に置く」だけでは足りない。依存関係を明確にし、共通基盤は共有しつつ、各パッケージの境界を保つ必要がある。pnpmはその点で、依存の解決を効率化しながら、構造の見通しを良くする。

つまり、サブエージェントとpnpmが解いているのは同じ問題である。どちらも、複雑なものを一箇所に押し込めて頑張るのではなく、複雑さを保ったまま、扱える粒度に分解する。ここに共通するのは「分割すれば楽になる」という素朴な話ではない。むしろ、分割によって各単位の責任を鋭くし、全体としての信頼性を上げる、という設計哲学である。

たとえば家事で考えると分かりやすい。全員が「家のこと全部やる」では破綻する。料理、掃除、買い物、在庫管理に役割を分けると、やることは減らないのに、なぜか回り始める。理由は、作業量が減ったからではない。判断の焦点が定まったからだ。

コンテキストを減らすことは、無知になることではない

ここで誤解してはいけないのは、コンテキストを減らすことが単なる情報遮断ではないという点だ。大事なのは、知る範囲を狭めるのではなく、意思決定に必要な情報だけをその瞬間に立ち上げることである。

これは料理に似ている。プロの厨房には巨大な倉庫があるが、調理台の上には今使うものしか出ていない。全部を手元に置けば安心に見えるが、実際は遅くなる。必要な材料だけが目の前にあることで、判断が速くなり、ミスが減る。コンテキスト設計も同じで、重要なのは「どれだけ持つか」ではなく、どのタイミングでどの文脈を呼び出すかだ。

AI開発では、これが特に重要になる。ひとつのモデルに全部を見せると、短期的には便利に見える。だが、長文の背景や過去の議論まで抱え込むと、出力は平均化され、鋭さが失われる。対して、役割ごとに文脈を切り替えると、品質チェックは厳しく、実装提案は機動的に、設計レビューは抽象度高く保てる。これは「狭い視野」ではなく、視野の切り替え能力である。

pnpmのモノレポも同じで、すべての依存を毎回頭から再構築するのではなく、共有可能なものは共有し、個別の責務は切り離す。その結果、開発者は「いま触るべきパッケージ」と「気にしなくてよい周辺」を分けて扱える。大きなシステムほど、実はこの切り替えが生産性を決める。

複雑な仕事の生産性は、理解の総量ではなく、文脈の切り替え精度で決まる。

この視点を持つと、これまで「情報を増やすこと」で解決しようとしていた多くの問題が、実は「役割を切り替えられていない」だけだと分かる。調査、実装、検証、レビュー、保守は、同じ頭で同時にやるには重すぎる。だからこそ、分割が必要になる。

実務に落とすなら、まず「誰が何を見ないか」を決める

この発想を実務に移すとき、最初にやるべきなのはツール導入ではない。見ない範囲の定義である。多くの組織は、役割を増やす前に情報共有を増やしすぎる。だが、本当に必要なのは、共有の最大化ではなく、共有の最適化だ。

次のように考えると設計しやすい。

1. 品質チェック用の視点を独立させる 実装者が自分の変更をそのまま評価すると、視点が近すぎて見落としが起きる。品質だけを見る役割を作ると、チェック基準が明確になる。

2. パッケージや機能単位に責務を閉じる モノレポでは、共通化したい部分と独立させたい部分を分ける。依存を薄く保つほど、変更の波及が小さくなる。

3. AIにも人間にも、入力の上限を設ける 何でも入る箱は便利に見えるが、実際には判断を鈍らせる。文脈は多いほど良いのではなく、目的に対して十分であることが重要だ。

4. レビュー観点を固定する レビューのたびに観点が変わると、判断はぶれる。性能、可読性、セキュリティなど、役割を分けて見ると、チェックは速く、深くなる。

5. 全体像は一度に持たず、必要時に再構成する システム全体の理解を常時持つのではなく、目的ごとに地図を描き直す。これは忘却ではなく、再編成である。

ここで重要なのは、分割の目的が「楽をすること」ではない点だ。分割の本質は、信頼できる判断を反復可能にすることにある。ある時だけうまくいく個人芸ではなく、誰がやっても質が安定する構造を作ること。それが、サブエージェントやモノレポのような設計に共通する価値である。

Key Takeaways

• コンテキスト不足ではなく、コンテキスト過多が詰まりの原因になることが多い。 まず情報を増やす前に、見なくてよい範囲を決める。
• 強いシステムは、全体を抱えるのではなく、役割ごとに文脈を切り替えられる。
• 品質チェック、実装、設計、運用は、同じ視点で同時にやらない。 役割を分けると判断が鋭くなる。
• モノレポやサブエージェントの価値は、分割そのものではなく、境界を設計できることにある。
• 「何を共有するか」より「何を共有しないか」が、生産性と品質を左右する。

結論: 賢さとは、全部を知ることではなく、全部を同時に見ない技術である

私たちはしばしば、優れたシステムとは情報をたくさん抱えられるものだと思いがちだ。しかし実際には逆で、優れたシステムほど、必要なときに必要な文脈だけを呼び出し、不要なものを一時的に沈める。そこでは、知識よりも編集能力が重要になる。

サブエージェントは、AIにその編集能力を持たせる試みだ。pnpmを使ったモノレポは、ソフトウェアの依存関係に同じ編集能力を与える試みだ。両者が示しているのは、複雑さをなくすことはできなくても、複雑さに飲み込まれない設計はできる、ということだ。

だから次に何かが詰まったら、まず「もっと知るべきか」とは問わないほうがいい。代わりに、こう問うべきだ。この仕事に必要なのは、より大きなコンテキストか、それともより鋭い境界か。 その問いに答えられるようになると、仕事の見え方は根本から変わる。