Agentic OS 技術スタックを下から読む 第38回：委譲とは、文脈を切り離すこと ―― 重い探索を別の頭に任せ、結論だけ持ち帰る

Agentic OS 技術スタックを下から読む 第38回：委譲とは、文脈を切り離すこと ―― 重い探索を別の頭に任せ、結論だけ持ち帰る

評価の層から、編成の層へ

前回は、物差しが古びる話をしました。

一度はよく効いた測り方でも、作るものが変わると、急に足りなくなります。何をよしとするか。どこを見落とすか。その物差し自体が、しだいに古くなります。そこで最後に、次回はまた別の層の急所へ降りる、と書きました。

今回は、編成の層へ降ります。

前に編成を見た回では、多体の難所は「間」にある、と書きました。ひとつひとつの頭が賢くても、それらの間で仕事を渡すと、急に信頼性が落ちます。道具を呼ぶ場面も見ました。呼び出しそのものより、呼ぶ前後のつなぎ方が難所になります。

今回は、その一点をさらに深く見ます。

委譲です。

つまり、仕事を別の頭に渡すことです。ただし、ここで大事なのは、賢い分業という見方ではありません。委譲とは、文脈を切り離すことです。重い探索を、別の頭のまっさらな窓に逃がします。そして、結論だけを持ち帰ります。

主たる窓は守られます。

しかし、ただで守られるわけではありません。渡すときと、取り込むとき。この二つの境で、情報は必ず目減りします。

なぜ別の頭に渡すのか

大きな仕事があります。

たとえば、コード全体を端から調べる仕事です。ある処理がどこから呼ばれているかを追う。古い作りを新しい形へ移す。似た処理がどこに散っているかを探す。ひとつの画面の不具合を直すために、保存、表示、取り出し、整形、権限の確認まで順に見る。

こういう仕事は、文脈の窓を大量に食います。

文脈の窓とは、いまの頭が同時に持っていられる作業用の場所です。人間でいえば、机の上に広げられる紙の広さに近いです。紙はたくさん広げられますが、無限ではありません。前に第27回で、注意には予算がある、と書きました。見ているものが増えるほど、いま大事にしたい筋に使える注意は減ります。

主たる頭が、重い探索を全部自分で抱えるとどうなるか。

最初はよいです。入口のファイルを読む。呼び出し元を探す。設定を開く。似た名前を検索する。試しに動かす。失敗する。別の経路を見る。古い処理を見つける。さらに例外処理を見る。

この生の探索が、窓を埋めていきます。

読んだ場所。試した手。外れた仮説。途中で見つけた枝道。全部が、机の上に積まれます。すると、もともと追っていた肝心の筋が、押し出されます。なぜこの調査を始めたのか。どの制約を守るべきだったのか。最後に何を決めたいのか。そういう骨が、だんだん薄くなります。

重い探索をしながら、本筋を見失う。

これが、主たる窓で全部を抱えるときの危うさです。

だから、別の頭に渡します。しかも、作業だけを渡すのではありません。その頭専用の、まっさらな窓ごと渡します。

まっさらな窓で燃やす

渡された頭は、自分だけの窓を持ちます。

そこでは、重い探索を遠慮なく燃やせます。何十ものファイルを開いてもよいです。何度も検索してよいです。似た処理を並べて比べてもよいです。途中で仮説を外してもよいです。失敗した試し方が積み上がってもよいです。

汚れるのは、その頭の窓だけです。

主たる頭の窓は、汚れません。主たる頭は、いま追っている筋を持ったままでいられます。何を変えたいのか。何を変えてはいけないのか。次にどの判断をするのか。そこに注意を残せます。

そして、渡された頭は、最後に結論だけを持ち帰ります。

生の探索の山を、そのまま戻すのではありません。読んだ全ファイルの長い一覧を戻すのでもありません。外れた仮説を全部戻すのでもありません。煮詰めた一握りの答えを戻します。

たとえば、こうです。

この処理の入口は三か所あります。そのうち一つだけが外部に開いています。残り二つは内部の定期処理からだけ呼ばれます。外部に開いている入口では、入力の形を先にそろえています。内部の二つでは、すでにそろった値が渡ってきます。

これは、主たる頭にとって使いやすい答えです。

主たる頭は、探索の山を抱えなくてよいです。入口が三か所あること。そのうち一つだけが外部に開いていること。扱いを変えるべき境目がそこにあること。それだけを受け取れば、次の判断に進めます。

委譲の値打ちは、ここにあります。

賢さを分けるためというより、窓を分けるためです。重い探索を別の窓で燃やし、小さな結論だけを主たる窓へ戻す。この形によって、主たる窓は守られます。

渡し損ねる

しかし、ここに最初の境があります。

渡された頭は、主たる頭の文脈を持っていません。まっさらな窓で始まるとは、そういうことです。明示して持たせたものしか知りません。

ここで、渡し損ねが起きます。

たとえば、主たる頭は「外部に開いた入口は触るな」と考えていたとします。そこは利用者に直接影響するため、今回は調査だけにして、変更案からは外すつもりです。しかし、その前提を渡し忘れたらどうなるか。

渡された頭は、まっさらです。

外部に開いた入口を、他と同じ候補として調べます。場合によっては、そこを直すのが一番きれいだと結論するかもしれません。コードだけ見れば、その判断は筋が通っていることもあります。入力を受ける場所でそろえるのが自然だ、という理屈はありえます。

しかし、主たる頭が持っていた制約から見れば、的外れです。

原因は、渡された頭が粗いからではありません。境で必要な前提が落ちたからです。

では、すべてを渡せばよいのでしょうか。

それも違います。主たる頭が持っている事情を、何もかも渡すと、今度は渡す側で窓が埋まります。過去の議論、例外の事情、関係しそうなファイル、関係しないかもしれない注意点、古い失敗例。全部を詰めて渡すなら、別の頭に任せた意味が薄くなります。

重いものを逃がしたいのに、逃がす前の荷造りで机を埋めてしまいます。

だから、渡すものは選ばなければなりません。

関係する一切れだけを渡します。目的。見てほしい範囲。触ってはいけない場所。答えの形。疑ってほしい点。これだけは守ってほしい制約。逆に、不要な背景は持たせません。

第34回で、外殻が文脈の窓を所有すると書きました。これは、自分の窓を守るだけの話ではありません。委譲では、相手の窓も設計します。何を入れるか。何を入れないか。その選び方が、別の頭の見え方を決めます。

取り込み損ねる

二つ目の境は、帰り道にあります。

渡された頭は、結論を持ち帰ります。けれども、主たる頭は、その結論にどう至ったかを見ていません。途中で何を読み、何を捨て、どの仮説を試し、どこで判断を変えたのか。その生の筋は、主たる窓にはありません。

受け取るのは、煮詰めた要約です。

ここで、取り込み損ねが起きます。

たとえば、渡された頭が「入口は安全です」と持ち帰ったとします。主たる頭は、その結論を使って次の設計へ進みます。入口が安全なら、内側の処理だけを直せばよい。外側の確認は増やさなくてよい。そう考えます。

しかし、本当の結論は少し違っていたかもしれません。

「入口は安全です。ただし、ある特殊な場合を除いて」

この但し書きが、要約の途中で削れたとします。渡された頭は、細かすぎると思って落としたのかもしれません。めったに起きない場合だから、主たる頭には不要だと見たのかもしれません。あるいは、最後の短い答えにまとめるとき、単に薄まったのかもしれません。

主たる頭は、欠けた結論を受け取ります。

そして、その欠けた土台の上に判断を積みます。さらに厄介なのは、欠けていることに気づきにくい点です。なぜなら、主たる頭は途中の筋を見ていないからです。要約だけを見ています。

第12回で、記憶とは「何をしたか」だけではなく、「なぜそうしたか」を残すことだと書きました。委譲の帰り道では、まさにこの「なぜ」が落ちやすいです。

結論だけが戻ると、速く進めます。

しかし、理由が薄い結論は、あとで折れます。どこまで確かめたのか。どこは見ていないのか。どんな条件なら成り立つのか。そこが戻らないと、主たる頭は結論の使いどころを間違えます。

境では必ず目減りする

渡しと取り込み。

この二つの境では、どちらも情報が目減りします。

渡すときには、要らないと思って落としたものが、実は要ることがあります。取り込むときには、短くまとめるために削ったものが、実は後の判断に効くことがあります。

委譲とは、境での圧縮です。

長いものを短くして、境を越えさせます。主たる頭の持っている文脈を、短い依頼へ圧縮します。渡された頭の重い探索を、短い報告へ圧縮します。

圧縮には、必ず損があります。

完全に保ったまま小さくすることはできません。小さくするとは、何かを捨てることです。問題は、捨てること自体ではありません。何を捨てたかを、設計する側が握っているかどうかです。

第14回で、多体の難所は「間」にあると書きました。その「間」は、抽象的な言葉ではありません。委譲でいえば、渡しと取り込みの境です。

一体ずつは正しく働いても、境で落ちた一片が、後で全体を狂わせます。

渡された頭は、与えられた依頼には忠実だったかもしれません。主たる頭も、受け取った結論をまじめに使ったかもしれません。それでも失敗します。なぜなら、必要な前提や但し書きが、境を越えるときに落ちたからです。

信頼性の崖は、ここで生まれます。

頭の性能だけを上げても、境の目減りは消えません。むしろ頭がよくなるほど、短い結論がもっともらしく見えます。だから、なおさら境を設計する必要があります。

何を渡し、何を自分で持つか

何でも渡せばよいわけではありません。

委譲には、向く仕事と向かない仕事があります。

渡すのに向くのは、文脈を大量に食うが、結論は小さく畳める仕事です。広い探索。たくさんの検索。全体の見直し。呼び出し元の洗い出し。似た処理の一覧化。設定の経路確認。こういう仕事は、入口が重く、出口が軽いです。

入口では、多くのものを見る必要があります。

しかし出口では、「入口は三か所」「外部に開いているのは一つ」「危ない分岐はこの条件だけ」といった形に畳めます。こういう仕事は、別の窓で燃やす価値があります。

逆に、委譲に向かない仕事もあります。

主たる筋の文脈を、まるごと要する仕事です。たとえば、今回の変更で何を優先するかを決める仕事です。速さを取るのか。壊れにくさを取るのか。利用者への影響を避けるのか。あとで直しやすい形に寄せるのか。こういう判断は、主たる頭が持っている流れそのものに依存します。

また、途中の理由そのものが後の判断で効く仕事も、渡しにくいです。

結論だけでは足りません。どの選択肢を捨てたのか。なぜ捨てたのか。どこで迷ったのか。どの条件なら別案になるのか。そういう途中の筋が、次の判断材料になります。

この場合、結論だけ持ち帰ると、肝心が落ちます。

だから、自分の窓で持つべきです。多少重くても、主たる頭が抱えたほうがよい仕事があります。窓を空けたい誘惑と、境で失う危うさを、秤にかけます。

安く窓を空けられても、肝心が境で落ちるなら、かえって高くつきます。

委譲とは、窓の所有を広げること

まとめます。

委譲とは、賢い分業ではありません。文脈を切り離すことです。重い探索を別の頭のまっさらな窓へ逃がします。そして、結論だけを持ち帰ります。主たる窓は守られます。

しかし、渡しと取り込みの境で、情報は必ず目減りします。

だから、委譲の設計とは、どの境で、何を落とすかを選ぶ設計です。何を持たせるか。何を持たせないか。何を持ち帰らせるか。どの理由まで残させるか。何を自分の窓に置いたままにするか。

外殻が文脈の窓を所有する、という話は、ここまで含んでいます。

自分の窓だけを守ればよいのではありません。渡す相手の窓も設計します。持ち帰る結論の形も設計します。委譲は、窓の所有を、境の向こうへ広げる行為です。

別の頭に任せれば、主たる窓は軽くなります。

けれども、軽くなったぶんは、どこかへ消えたのではありません。境で圧縮されただけです。その圧縮で何を捨てたかを握っていないと、委譲は静かに肝心を落とします。

次回は、また別の層の急所へ降ります。