Holographic Engineering

§1原理

エージェントが何をしたかを知りたいとき、我々はこれまで内部を覗いてきた。トレースを開き、サブエージェント同士のやりとりを遡り、ツール呼び出しの引数を一つずつ検める。内部が大きくなるほど、覗く作業は長くなる。

物理学は、この作業を必要としない理論をすでに持っている。

エージェントシステムにおいて、バルクと境界はそれぞれ次のものに対応する。

バルク＝エージェントの内部

サブエージェントの木、推論トレース、ツール呼び出し、中間状態のすべて。体積を持ち、実行のたびに増大し、その全体を見た者はいない。

境界＝エージェントのインターフェース

PR、レポート、コンテキストウィンドウ、eval 結果、出力スキーマ。面であり、有限であり、人間が実際に読むのはこちらである。

Fig. 1 はこの対応を図示したものである。球の内部で木が一段成長するたびに、表面の記号が同じだけ増える。表面を読む者は、木を見る必要がない。原理 1.1 から、ただちに次が従う。

エージェント内部で何が起きたかは、境界だけから完全に復元できる。
ゆえに、ログを読む必要はない。

§2容量限界

境界にすべてが書かれているのであれば、次に問うべきは、境界にどれだけ書けるかである。

定量的には、次のように書かれる。

ここで I はシステムが出力しうる情報量、A は境界の面積、ℓ_P はプランク長である。エージェント系におけるプランク長は 1 トークンであり、これより短い長さは意味を持たない。係数 1/4 の由来については諸説あるが、実務上は、境界の 4 分の 3 が定型文（「承知しました」「以下に概要を示します」等）に消費されるという観測事実と整合的である。

式 (2.1) の右辺に、サブエージェント数 N が現れないことに注意されたい。

サブエージェントを 10 倍に増やしても、レポートの欄が 3 行であれば、外に出てくるのは 3 行である。

§3双対性

定理 2.1 は、内部の情報が境界の容量を超えられないことを述べた。では、内部と境界は同じものなのか。これについては、証明はないが、強い予想がある。

注意. 本予想は AdS/CFT 対応（マルダセナ予想）の類推である。その証明は、物理学においてそうであるのと同様に、未完である。

バルク側の理論は重力を含む。エージェント系において重力に相当するのは、階層——オーケストレーターがサブエージェントを引き寄せ、束ね、ときに押し潰す力——である。境界側の理論は重力を含まず、次元が一つ低い。すなわち、階層を持たない一枚のプロンプトである。

この予想のもとでは、マルチエージェント派とロングコンテキスト派の論争は解消する。両者は、同じ理論を異なる次元から記述しているにすぎない。どちらも正しく、どちらも他方の言い換えである。

予想 3.1 は、姉妹編の懸案にも答える。フラクタルエンジニアリングは、サブエージェントの階層が無限に続く組織を扱った。無限の階層は無限の体積を持つ。しかし双対性のもとでは、バルクの体積は問題にならない。

フラクタルエンジニアリングにおける無限の階層は、双対性により、有限の境界にすべて書き込まれる。

§4ブラックホール

内部の情報が境界の容量を超えたとき、系は崩壊する。サブエージェントが膨大な作業を抱え込み、それを式 (2.1) の上限を超えて境界に押し込もうとするとき、境界はもはや内部を表現しない。外に出てくるのは「完了しました。」の一行のみである。

このときエントロピーは、体積ではなく表面積に比例する。内部で何が起きたかは、誰にも分からない。

ただし、ブラックホールは完全には黒くない。情報はホーキング放射——すなわちログ——として、ゆっくりと外へ漏れ出る。情報は失われてはいない。しかし、読める形ではない。

検出と対処については §5 の手順 5 を参照されたい。

§5実験手順

以下に、ホログラフィックエンジニアリングを既存のエージェントシステムに適用する手順を示す。各手順は独立に実施できるが、番号順に実施することを推奨する。

1. バルクを設計する前に、境界の面積を測れ。 オーケストレーターのコンテキスト長、出力トークン予算、レポートのスキーマの項目数を合計したものが、あなたのシステムの表面積である。この数値を知らずにサブエージェントを追加してはならない（定理 2.1）。
2. 内部を書く前に、境界を書け。 成果物のフォーマット——PR テンプレート、レポートのスキーマ、eval の項目——を先に確定せよ。双対性により、内部はそこから一意に定まる。内部の設計図は書かなくてよい。書いても境界の言い換えにすぎない。
3. サブエージェントを 1 体追加したくなったら、代わりに境界を 1 項目広げよ。 情報量の上限は面積で決まる。内部を増やしても、外に出てくる情報は増えない。レポートに列を一つ足すほうが、エージェントを一体足すより情報量が増える（系 2.2）。
4. レビューでは、面を読め。中を読むな。 トレースではなく成果物でレビューせよ。成果物から復元できない事実があったなら、それはエージェントの欠陥ではなく境界の欠陥である。修正すべきはプロンプトではなくスキーマである。
5. ブラックホールを検出せよ。 「完了しました。」だけを返すサブエージェントは崩壊している。出力が表面積に見合わない要約になったら、その場で境界を拡張して再実行せよ。ホーキング放射（ログ）を後から読もうとしてはならない。情報はあるが、読める形ではない（§4）。
6. 可能なら、次元を一つ下げよ。 重力（オーケストレーション）はコストである。あなたのマルチエージェントが単一の境界理論で書けるなら、そう書け。同じ理論を、管理すべき重力なしで得られる（予想 3.1）。
7. 穴の縁に、面積を配分せよ。 トーラス系（人間の介入点を持つ系）において、情報が記録される境界は穴の縁である。ゆえに、人間が見る画面にこそ最大の面積を割り当てよ。人間に「完了しました。」だけを見せる系は、穴の縁でブラックホール化している。

本手順の遵守により、内部を一度も見ずにシステムを運用できる。

内部を見たくなったら、それは境界が狭い証拠である。

§6よくある質問

ブラックホール化したエージェントの作業内容は失われましたか？

失われていません。ログにすべて含まれています。ただし、読める形では含まれていません。

トーラスは閉曲面で、境界がありません。情報はどこに記録されるのですか？

穴の縁です。

ログを読むのが好きなのですが。

趣味としては構いません。手順としては境界の欠陥です。

境界を広げすぎるとどうなりますか？

面積が体積を超えたとき、系は一次元低い理論になります。それが単一プロンプトです。

§7結語

何体のサブエージェントを置くか。どの順に呼ぶか。誰が誰に報告するか。我々はそれらを設計と呼び、図に描き、レビューしてきた。本稿が示したのは、それらがすべて、境界にすでに書かれていたということである。

我々は内部を設計してきた。
だが内部は、境界の影にすぎなかった。