Agentic OS 技術スタックを下から読む 第14回：段を重ねるほど崩れる ―― 信頼性の崖と、編成の型

見えたあとに考えること

前回は、複数のエージェントが動くとき、その難しさは個々の点よりも「間」に出る、という話をした。

誰が何を受け取り、何を判断し、次へ何を渡したのか。
それを見ないままでは、失敗の原因も、改善すべき場所もつかみにくい。だから実行ツリーが要る。処理の流れを、ただのログではなく、枝分かれした構造として見る必要がある。

では、見えるようになったら次に何を考えるのか。

自然な問いは、複数のエージェントをどう束ねるかである。どの役割を分けるのか。どこで計画を立てるのか。誰が全体を見るのか。

ただし、その前に押さえておくべき数字がある。
編成の良し悪しを決める、かなり手前の数字である。

それは、一段ごとの成功率である。

各段は、完璧ではない

エージェントの一手は、たいてい一度では確実に決まらない。

調べるべき情報を取りこぼすことがある。
道具の呼び出しが失敗することがある。
入力の意味を少し取り違えることがある。
途中までは正しいが、最後の判断だけ外れることもある。

これは、エージェントが低品質だから、という話ではない。むしろ、かなりよくできていても起きる。

外部の情報は欠ける。
入力は曖昧である。
道具は時々失敗する。
判断には境界例がある。

つまり、一段ごとの成功率は、どれだけ高く見積もっても百点にはならない。

ここでいう一段とは、小さな処理のまとまりである。要求を分類する。検索する。候補を選ぶ。要約する。次の担当へ渡す。出力を確認する。こうした一つひとつの段で、一定の確率でうまくいき、一定の確率で外れる。

単体で見れば、その失敗率は小さく見える。
だが、複数の段をつなぐと、話が変わる。

信頼性の崖：成功率は掛け算で落ちる

ここで効いてくるのが、掛け算である。

仮に、一段の成功率が九割五分あるとする。かなり高い数字である。百回のうち九十五回はうまくいく。単体の部品として見れば、十分に優秀に見える。

ところが、その段を十個つなげるとどうなるか。

全体が最初から最後まで成功するには、十段すべてが成功しなければならない。すると全体の成功率は、九割五分を十回かけた値になる。

およそ六割である。

一段ごとは優秀なのに、十段通すと、四割近くはどこかで失敗する。これは直感に反しやすい。一つひとつが少しずつ不確実なだけなのに、長くつないだ瞬間、全体の信頼性が急に下がる。

段数が増えるほど、この目減りは加速する。

仮に二十段なら、さらに低くなる。三十段なら、もっと厳しい。もちろん現実には、各段の失敗が完全に独立しているとは限らない。途中で直せる場合もあるし、ある失敗が後段で吸収される場合もある。だから、この計算は厳密な予測ではない。

それでも、構造を見るための近似としては十分である。

長い鎖は、段を重ねるほど壊れやすくなる。
これが信頼性の崖である。

怖いのは、各段が目に見えて悪いわけではない点である。一段ずつ見ると、どれもそれなりに動いている。ログを眺めても、大きな破綻は見えない。だが、端から端まで通すと成功率が落ちている。

長い一本の鎖を、何の区切りもなく素朴につなぐと、各段がどれだけ賢くても、全体は静かに崩れていく。

だから、長い一本の鎖にしない

この崖への答えは、一段一段をもっと賢くすることだけではない。

もちろん、各段の品質を上げることには意味がある。分類をよくする。検索をよくする。出力形式を安定させる。こうした改善は必要である。

しかし、それだけでは足りない。

一段の成功率には上限がある。百点にはならない。九割五分を九割八分にできたとしても、段を長くつなげば、やはり掛け算で落ちる。

だから、答えは構造のほうにある。

長い自由な連鎖を避ける。
短く区切る。
要所で確かめる。
必要なら戻す。
十分なら止める。

複数エージェントの編成の型は、いろいろな名前で語られることがある。だが、その根をたどると、多くはこの一点に戻ってくる。

長い一本の鎖を、そのまま伸ばさないための工夫である。

型その一：振り分けてから、専門家へ

まず考えやすいのは、何でも一体にやらせないことである。

入ってきた要求を、最初に見分ける。これは調査なのか。計算なのか。文章化なのか。確認なのか。種類を見て、それに向いた担当へ回す。

調べる仕事は、調べる担当へ。
計算する仕事は、計算する担当へ。
文章を整える仕事は、文章を整える担当へ。

ここで大事なのは、役割を分けること自体が目的ではない、という点である。目的は、各担当が抱える鎖を短くすることにある。

一人に全部をやらせると、文脈が太る。
文脈が太ると、判断の焦点がぼやける。
焦点がぼやけると、関係の薄い情報まで後段に流れ込む。

その結果、後ろの段ほど、何を前提にすればよいのかが曖昧になる。

振り分けを先に置くと、各担当が見る範囲は狭くなる。狭いから、判断の基準をはっきりさせやすい。必要な道具も限られる。出力の形も決めやすい。

これは、能力を小さくするという意味ではない。
責任の範囲を小さくする、という意味である。

責任の範囲が小さければ、一段ごとの成功率も上げやすくなる。そして何より、長い一本の鎖を、いくつかの短い鎖に分けられる。

型その二：先に計画、それから実行

もう一つの型は、いきなり走り出さないことである。

複雑な仕事では、最初の一手をそのまま次の一手につなぎ、さらに次へ進めていくと、途中から目的がずれやすい。前の段の小さな誤差が、後ろの段で前提になってしまうからである。

そこで、まず全体の計画を立てる。

何を達成するのか。
どの作業に分けるのか。
どの順番で進めるのか。
最後に何を出せば完了なのか。

先にこれを決めてから、実行に移る。

計画があると、各段が小さくなる。小さくなるだけでなく、その段で何をすればよいかがはっきりする。すると、途中で確かめやすくなる。

今やっている作業は、計画のどこに当たるのか。
この出力は、次の段に渡せる形になっているのか。
そもそも、この段はもう終わってよいのか。

こうした問いを置ける。

行き当たりばったりの長い連鎖では、途中の判断がそのまま次の目的を作ってしまう。目的が毎段少しずつ動くので、最後に出てきたものが、最初の要求から離れていても気づきにくい。

計画は、自由を奪うためのものではない。
途中の自由が、全体の目的を壊さないようにするためのものである。

型その三：監督役と、明示的な終わり

さらに、全体を見る役を置くという型がある。

各担当は、自分の段には詳しい。だが、自分の段に集中するほど、全体として十分かどうかは見えにくくなる。調査担当はもっと調べたくなる。修正担当はもっと直したくなる。確認担当は別の観点も見たくなる。

そこで、全体を見張る役が要る。

この役は、細部の作業をすべて代わりに行うわけではない。各段の結果を見て、次に進んでよいか、やり直すべきか、ここで打ち切るべきかを判断する。

あわせて重要なのが、明示的な終わりである。

たとえば、段数の上限を決めておく。
試行回数の上限を決めておく。
十分とみなす条件を決めておく。

これがないと、エージェントは同じところを回り続けることがある。うまくいっていないのに、次こそは直せると思って再試行する。再試行の結果をまた確認し、また少し直し、また確認する。外から見ると、前に進んでいるようで、実は同じ範囲を回っている。

監督役と終了条件は、この堂々巡りを止めるためにある。

ここでも、本質は「誰か偉い役を置く」ことではない。
全体の進行を、局所的な勢いだけに任せないことである。

共通する一つの考え：短く保ち、節目で確かめる

振り分ける。
計画してから実行する。
監督役を置き、終わりを決める。

これらは違う型に見える。実際、使う場面も違う。要求の種類が広いなら振り分けが効く。仕事が複雑なら計画が効く。再試行や分岐が多いなら監督が効く。

しかし、根にある考えは同じである。

長い一本の自由な鎖を避ける。
短い区切りを作る。
節目ごとに確かめる。

信頼性の崖に対する答えは、賢い一発ではない。構造である。

一段の成功率を上げることは大事だが、それだけでは長い鎖の問題を解けない。段が増えるほど掛け算で落ちるなら、段のつなぎ方を変えなければならない。

複数エージェントの編成とは、ただ人数を増やすことではない。
会話の相手を増やすことでもない。
長い処理を、どの単位に分け、どこで確かめるかを設計することである。

Agentic OS への含意

これは、オペレーティングシステムが長い処理を扱ってきた発想にも近い。

長い処理を無制限に走らせない。
途中に区切りを持たせる。
状態を見られるようにする。
終わりの条件を持たせる。

複数のエージェントを束ねるときにも、同じ考え方が要る。

自由に喋らせ合えば、知的な協調が自然に生まれるわけではない。むしろ、長い一本の鎖になり、信頼性の崖へ近づくことがある。

だから設計する。

どこで要求を分けるのか。
どこで計画に落とすのか。
どこで結果を確認するのか。
どこで止めるのか。

ここまで来ると、L4 の編成が単なる「複数エージェントの使い方」ではないことが見えてくる。これは、確率的に揺れる一手を、長い処理として成立させるための構造である。

ただし、構造を整えても、まだ足りない。

各段の中では、もっと細かい失敗が起きる。同じ操作を二度実行してしまう。処理が止まらない。壊れたデータが次の段へ渡る。外部の道具を呼んだつもりが、途中で失敗して状態だけが変わる。

これらは、編成の型だけでは防ぎきれない。

次回は、その一手ごとの歯止めに進む。道具の呼び出しを、ただの関数呼び出しではなく、分散した相手への呼び出しとして扱う話である。