Agentic OS 技術スタックを下から読む 第34回：層を束ねる外殻 ―― モデルを、制御できるループに収める

Agentic OS 技術スタックを下から読む 第34回：層を束ねる外殻 ―― モデルを、制御できるループに収める

連載の背骨は外殻へ向かっていた

前回は、ゼロから鍛える手仕事の話で終わりました。静かに失敗する訓練を、一段ずつ確かめる規律です。その規律こそが、この連載の背骨でした。

ここまで、下から順に見てきました。計算の土台がありました。モデルがありました。動かす時の仕組みがありました。役割を分ける編成がありました。危ない操作の手前で止める設計がありました。結果を確かめる仕組みがありました。最後には、外の現場に接続する時の難しさも見ました。

では、それらを一つの動くものにするのは何でしょうか。

答えは、もっと賢いモデルではありません。もちろんモデルは中心にあります。けれど、層を束ねる力は、モデルそのものからは出てきません。モデルを囲み、決まった形で呼び出し、途中で止め、やり直し、人へ渡し、記録を残す。そういう地味なソフトウェアの外殻が、全体を動くものにします。

多くのエージェントは、ほとんどソフトウェアです

いわゆるエージェントを中から見ると、実体は案外地味です。決まった手順のコードがあります。その途中に、モデルへ判断を頼む箇所があります。道具を呼ぶ箇所があります。結果を保存する箇所があります。失敗した時に戻る箇所があります。

つまり、全部をモデルが考えているわけではありません。外側のソフトウェアが流れを作り、その一部としてモデルが使われています。

反対に、全部を任せる作りもできます。最初に指示を渡します。使える道具を渡します。あとは、モデルに次の一手を考えさせます。終わったらまた考えさせます。これをぐるぐる回します。

この作りは、七割八割まではよく見えます。見た目の動きは派手です。簡単な仕事なら最後まで行きます。けれど、残りの二割三割で急に苦しくなります。現場で本当に効くのは、むしろその残りです。途中で誤った時に戻れるか。危ない操作の前で止まれるか。あとから原因を追えるか。人に渡す形があるか。そこが、きれいに動く見本と、壊れにくい仕組みの差になります。

回すだけの仕組みが崩れる理由

回すだけの仕組みでは、まず文脈がふくらみます。文脈とは、モデルが次の答えを作るために一度に読む材料です。過去の指示、途中の結果、道具の返り値、失敗の記録、利用者の追加指示が、どんどん積まれます。

量が増えると、肝心なものが薄れます。モデルは文字を無限には見られません。見られる範囲が広く見えても、その中で何を重く扱うかには限りがあります。古い誤りが残り続けると、それを正しい前提として次の判断に使うことがあります。小さなズレが、次のズレを呼びます。

これは、前に見た信頼性の崖と同じ構図です。一手ごとの成功率が高く見えても、長い鎖では話が変わります。一手が九割うまくいっても、十手、二十手、三十手と続けば、どこかで外れます。しかも、外れた一手が記録の中に残ると、その後の一手も汚れます。

さらに、回すだけでは後から追いにくくなります。どの指示で、どの材料を見て、どの道具を呼び、その結果をどう解釈したのか。そこが記録されていないと、失敗を直せません。途中で人に渡したくても、いま何が確定していて、何が未確定なのかを渡せません。

だから、内側のモデルを賢くするだけでは足りません。外側で締める必要があります。

プロンプトを自分の側で持つ

締める第一は、モデルへの指示を自分で持つことです。

プロンプトとは、モデルに何をどうしてほしいかを渡す指示文です。ただのお願い文ではありません。仕事の範囲、禁止事項、出力の形、判断の順序、迷った時の扱いを決める仕様です。

ここを外側の仕組みに任せきると、見えない指示が混ざります。便利な既定値に見えるものが、実際には挙動を変えます。こちらは短い指示を渡したつもりでも、内部では別の説明や命令が足されています。すると、なぜその答えになったのかを追えません。

前に仕様の話をしました。曖昧な仕様は、曖昧な結果を呼びます。プロンプトも同じです。版を持って管理します。どの版で、どの入力を処理し、どんな結果になったかを残します。少し言い方を変えたら、結果がどう動くかを確かめます。

指示を自分の言葉で持つとは、気合いの話ではありません。変えた時に差分を見られる形にすることです。戻せる形にすることです。失敗した時に、モデルのせいだけにせず、指示のどの部分が弱かったのかを調べられるようにすることです。

文脈の窓を設計する

第二は、モデルが一度に見る窓を自分で持つことです。

文脈の窓とは、モデルが一回の判断で読む材料の範囲です。ここに何を入れるかで、同じモデルでも結果は大きく変わります。多く入れればよい、というものではありません。

前に注意の予算を見ました。モデルには、読む力の配分があります。長い材料を入れるほど、細部への注意は散ります。関係の薄い記録まで詰めると、重要な条件が埋もれます。古い判断と新しい判断が混ざると、どちらを優先すべきかがぼやけます。

だから、窓の中身は設計します。まず、いまの一手に必要な材料だけを選びます。次に、長すぎるものは要約します。ただし、要約で落としてはいけない事実は残します。日時、数値、利用者の明示した制約、戻せない操作の有無は、短くしても消してはいけません。

順番も効きます。最初に目的を置きます。次に守るべき制約を置きます。そのあとに判断材料を置きます。最後に求める出力の形を置きます。こうすると、モデルは何のために材料を読むのかを見失いにくくなります。

手元のすべてを流し込むのは、設計ではありません。選び、削り、並べることが設計です。

制御の流れを外側で握る

第三は、次に何をするかの流れを自分で握ることです。

制御の流れとは、処理がどの順番で進むかという骨組みです。いつ道具を呼ぶか。いつ保存するか。いつ止めるか。いつやり直すか。いつ人に渡すか。これをモデルの気分に任せると、同じ入力でも動きが揺れます。

外側のコードが流れを持つと、モデルはその中の一部品になります。たとえば、まず入力を検査します。足りない材料があれば質問します。材料がそろったら候補を作ります。危ない操作が含まれるなら止めます。人の確認を受けたら実行します。実行結果を保存します。失敗したら決められた場所まで戻ります。

前に見た、戻せない操作の手前で人を挟む設計もここに入ります。送信、削除、購入、公開のように、あとから戻しにくい操作があります。その手前では、モデルに「必要なら確認して」と頼むだけでは弱いです。外側の流れとして、必ず止めます。確認された事実だけを次へ進めます。

この違いは大きいです。モデルがうまく判断した時だけ安全なのではなく、仕組みとして安全になります。

状態を外に出し、小さく専念させる

ここで、二つの設計が効きます。

一つ目は、状態を外に出すことです。状態とは、いまどこまで進んだか、何が決まり、何が未処理で、次に何をすべきかを表す記録です。これをエージェントの内側だけに抱え込ませると、途中で落ちた時に戻れません。何を終えたのかが消えます。

よい形は、いまの状態と新しい入力を受け取り、次の状態を返す形です。エージェントそのものは変換に近くなります。状態は外の保存先に残ります。こうすると、途中で止まっても、最後に保存された状態から再開できます。前に見た、落ちても戻せる設計と地続きです。

二つ目は、一つに全部をやらせないことです。調べるもの、要約するもの、危険を判定するもの、実行するもの、結果を点検するものを分けます。小さく専念した単位にすると、壊れた場所を切り分けやすくなります。

大きく賢い一個は、うまくいく時は気持ちよく見えます。けれど、失敗した時にどこを直せばよいかが見えにくいです。小さな多数は地味です。その代わり、一つずつ試せます。差し替えられます。記録を比べられます。前に見た編成の話は、ここで外殻の設計に戻ってきます。

外殻が、賢さを現場に留める

層を一つの動くものに束ねるのは、外殻です。モデルを囲み、制御できるループに収める、地味なソフトウェアです。

鍵は四つです。プロンプトを自分の側で持つこと。文脈の窓を自分の側で設計すること。制御の流れを外側で握ること。状態を外に出して、落ちても戻れる形にすることです。

モデルは中心の部品です。けれど、全体を動かすのは外殻です。安全にするのも外殻です。人を要所で挟むのも外殻です。あとから失敗を追えるようにするのも外殻です。

もっと賢いモデルさえあれば現場が動く、とはなりません。賢さを、握れる形に囲う設計がいつも要ります。賢さは中身です。外殻は器です。器がなければ、賢さは現場でこぼれます。

これで、技術層を下から外殻まで、ひと通り見終えました。計算の土台から、モデル、動かす仕組み、編成、安全、結果の確かめ方、外の現場、そしてそれらを束ねる外殻までです。

ただし、ここは終章ではありません。急いで上ってきたぶん、各層にはまだ覗いていない急所が残っています。次回からは、もう一度それぞれの層へ降ります。通り過ぎた細部を、もう一段深く読み直していきます。全体の地図を一枚にまとめるのは、その先です。