Agentic OS 技術スタックを下から読む 第40回：同じ能力でも、渡し方で変わる ―― 編集という一手で読む、道具の設計

Agentic OS 技術スタックを下から読む 第40回：同じ能力でも、渡し方で変わる ―― 編集という一手で読む、道具の設計

また別の層の急所へ降りる

前回は、読むことと書くことの非対称を見ました。読むだけなら、すでにあるものをたどれます。書くときは、まだないものを一語ずつ生む必要があります。だから高くつきます。

今回は、そこからまた運行時へ降ります。第15回では、道具呼び出しを、外の世界へ出る分散した呼び出しとして見ました。返事が遅れることがあります。途中で失敗することがあります。同じ指示をもう一度送る必要もあります。だから、やり直しても壊れない作りや、境界での確かめが要りました。

今回は、そのさらに手前です。道具をどういう面として作るか、です。同じ能力でも、渡し方で成否が変わります。ここでは、ファイルを直す、というありふれた一手で読みます。

編集というありふれた一手

エージェントに、ファイルを直させる。これは、とても普通の能力に見えます。

たとえば、ある設定の一行を変える。余分な関数を消す。名前をそろえる。説明を足す。どれも、外から見ると「編集する」です。

しかし、道具の作りは一つではありません。何行目を書き換えろ、と渡す作りがあります。古い中身と新しい中身を両方渡す作りがあります。読んだ行に短い目印を付け、その目印と一緒に編集させる作りもあります。

どれも、能力としては同じです。ファイルを直します。けれど、中で何を確かめるかが違います。何をモデルに書かせるかも違います。失敗したときに、どこで止まるかも違います。

この差が、成功率に効きます。出力の重さにも効きます。さらに、無関係な変更にどれだけ強いかにも効きます。

行番号だけでは脆い

いちばん素朴な渡し方は、行番号です。

十行目をこれに変えろ。十行目から二十三行目まで消せ。こう書ければ、人間には分かりやすい。道具も作りやすい。

しかし、この作りは脆いです。

なぜなら、行番号は中身を持っていないからです。行番号は、場所の番号にすぎません。その場所に、いま何があるかは保証しません。

途中で一行が足されると、番号は後ろへずれます。別の作業枝に切り替わっていれば、同じ十行目でも中身は別物です。モデルが読んだつもりの内容と、実際のファイルの内容が食い違っていることもあります。

このとき、行番号だけの道具は止まれません。十行目と言われたら、十行目を書き換えます。そこが本当に意図した場所かどうかは、道具の面では確かめられません。

つまり、番号は指せますが、確かめられません。ここが問題です。

古い中身を言わせる

そこで、よくある作りは、古い中身も一緒に書かせます。

ここにこう書いてあるはずだ。それをこう変えろ。こういう形です。

道具は、まず実際のファイルを見ます。そして、渡された古い中身と照らします。一字一句合っていれば、そこで初めて書き換えます。合っていなければ、書き換えません。

これで、ずれた場所を止められます。モデルの思い違いも止められます。別の作業でファイルが変わっていた場合も、古い中身が合わないので止まります。

これは、第31回で見た考えと地続きです。戻しにくい操作の手前で確かめる。ファイルの書き換えは、軽く見えても外の状態を変えます。だから、踏む前に、本当にその場所かを確かめます。

古い中身を書かせることは、その確かめです。道具の面の中に、待ったをかける仕組みを埋め込んでいるわけです。

安全には代償がある

ただし、この作りにも代償があります。

まず、出力が重くなります。古い中身を、そのまま書かせる必要があるからです。消したいだけの長い塊でも、いったん丸ごと書き写させることになります。

第39回で見たとおり、書かせる相は高くつきます。読むよりも、生むほうが高い。ならば、確認のためだけに長い古い中身を書かせるのは、かなり重い支払いです。

もう一つの代償は、もっと地味で厄介です。古い中身には、空白があります。引用符があります。かっこがあります。見た目では分かりにくい改行もあります。

モデルは、そこを少し間違えます。空白を一つ落とす。記号を似たものにする。行末を変える。すると、道具から見ると一致しません。安全のために、書き換えは拒まれます。

拒まれること自体は正しいです。間違った場所を書き換えるよりは、止まるほうがよいからです。けれど、止まれば、同じ編集をもう一度やり直す必要があります。

だから、道具の良し悪しは、一回分の出力だけでは決まりません。書かせる量が多いほど、書き間違いも増えます。書き間違いが増えれば、やり直しも増えます。安全のための確認が、失敗の入口にもなるのです。

札を付けて軽く確かめる

別の作りがあります。

ファイルを読むときに、各行へ短い札を付けて返します。たとえば、四文字ほどの札です。この札は、その行の中身をぎゅっと縮めた検査値です。行の中身が変わると、札も変わります。

編集するときは、行番号と札と新しい中身だけを渡します。古い中身を丸ごと書き写す必要はありません。

道具は、実際の行から同じように札を作ります。そして、渡された札と比べます。合っていれば、その行は読んだときから変わっていないと見なせます。合っていなければ、止めます。

この作りでは、確認の役目を札が担います。古い中身そのものを言わせる代わりに、古い中身の目印を言わせます。

効き目は特に、削除で出ます。長い塊を消すとき、古い塊を丸ごと出す必要がありません。行ごとの札だけで、そこが読んだときのままかを確かめられます。札の重さは、一行あたり二〜三トークンほどで済みます。

つまり、同じ安全を、かなり軽く買えます。確認をなくしたのではありません。確認の形を変えたのです。

どこで確かめるか

確認は、どの細かさで置くかによって性質が変わります。

一行ごとの札は、細かい確認です。ある行を直すとき、その行の札だけを見ればよい。ファイルの別の場所が変わっていても、関係ありません。目的の行が変わっていなければ、編集できます。

もっと粗くすることもできます。ファイル全体に、一つの目印を付ける作りです。この場合、編集するときは、行番号と全体の目印を渡します。範囲もまとめて指せます。十行目から二十三行目まで、という指定も軽くなります。

しかし、粗い確認には弱点があります。ファイルのどこか一か所でも変わると、全体の目印が変わります。目的の場所とは無関係な変更でも、編集は失敗します。

ここに取引があります。

細かく確かめると、無関係な変更に強くなります。その代わり、行ごとに札を持つ手間が増えます。粗く確かめると、軽くなります。範囲も扱いやすくなります。その代わり、無関係な変更に弱くなります。

同じ確認付き編集でも、どこで確かめるかで、強みと弱みが入れ替わります。

道具はただの穴ではない

ここまでを見ると、編集道具はただの通り道ではないと分かります。

同じ能力があります。ファイルを直す、という能力です。けれど、古い中身を全部書かせるのか。一行ごとの札で済ませるのか。全体の目印でまとめるのか。渡し方によって、成否も、出力の重さも、頼りなさも変わります。

道具は、能力をつなぐ穴ではありません。設計された面です。その面には、安全と、出力の重さと、無関係な変化への強さが畳み込まれています。

モデルが賢くなっても、面が悪ければ、賢さはそこでこぼれます。逆に、面がよければ、同じモデルでも速く、確かに動きます。

第34回では、外殻が制御の流れを所有すると見ました。その流れの中で、道具の一つひとつの面も設計の対象になります。何を確かめさせるか。何を書かせるか。どこで失敗させるか。それを握るのは、道具を作る側です。

能力を渡すとは、面を設計することです。次回は、また別の層の急所へ降ります。