良い記録は、機械を止める関所の代わりにならない

Armin Ronacherが2026年6月に公開した「The Coming Loop」は、Hacker Newsのフロントページに載った(出典)。彼はエージェントが動く様子を二つの層に分けている。一つは、モデルがツールを呼び出し、ファイルを読み書きし、テストを流すエージェントループ。もう一つは、そのエージェントループの外側で、作業がキューに積まれ、機械が拾い、試し、終わったと判断するハーネスループだ。彼が警告しているのは後者で、curlのメンテナであるDaniel Stenbergが「レポートの大半がAI生成のものに埋もれて対応しきれない」と嘆いた例を引きながら、人間が説明を経由せずに機械とだけ会話し、最後には「自分で完全には説明できないコードをマージする人が増える」と述べている。

PRレビューツールParryを開発している立場からこの記事を読むと、思い当たる節がある。Parryが最初からPRに要求してきたWhy/Risk/Confidence/Why notという四軸は、まさに「機械が完了と判断した作業を、人間が説明抜きで受け入れてしまう」場面への手当てのはずだった。理由と懸念点を書かせておけば、人間はそれを読んで判断できる。ハーネスループの中に、人間の理解を差し込む窓ができる。そう考えたくなる。

窓はあったのに、通らなかった

だが、Parry自身の初期の運用記録を読み返すと、そう単純には言えない。ブログ公開パイプラインを最初にドッグフーディングした際、mainブランチへの直pushを止める仕組みがまだ実装されていなかった時期がある。四軸を書いてPRを送る運用ルールは存在していたのに、うっかりmainへ直接pushしてしまったことがあった。レビューを経ずに変更が反映された形になる。幸い公開システムは何ごともなかったかのように動いていて、実害はなかった。

この一件が示しているのは、四軸という記録の有無ではない。記録を書く運用ルールは、直push一つで丸ごと迂回できる程度のものだったという事実だ。ハーネスループを止めていたのは、Whyの説明の質でも、Riskの記述の精度でもなかった。単に、mainへ直接書き込む経路が技術的に開いていたかどうかだった。実際にParryが手当てしたのも、四軸の書式を洗練させることではなく、IAMポリシーでmainへのdirect pushそのものを禁止することだった。それ以降、変更は必ずPRを経由し、四軸を含んだ状態で人間の前に立ち止まる。

関所を通る前提で書かれた記録は、関所そのものではない

四軸のような記録は、関所を通る人間が判断するための材料であって、関所そのものではない。この二つを重ねて考えてしまうと、記録の書式さえ整えれば人間の理解を守れるという話に見えてしまう。だが直push一つで迂回できた事実が示すのは逆で、記録が意味を持つのは、その記録を読まずには先へ進めない仕組みが技術的に成立しているときに限られる。Ronacherが「pi」や「制御可能なハーネス」への期待として書いているのも、おそらくこの技術的な強制の話であって、記録の質の話ではない。

そう考えると、Ronacherの懸念に対してParryが答えているのは、彼が挙げた問題のうち限られた一点だけだ。彼が描くハーネスループは、タスクをキューから拾い、試し、次に進むか止まるかを機械が判断し続ける、もっと広い自律の連なりを指している。Parryが関所を置いているのは、その中のマージという一点でしかない。どのタスクを次に着手するか、いつ試行を打ち切るか、失敗をどう扱うかという判断は、依然としてハーネスの設計者かモデル自身に委ねられたままだ。

マージ前の一点に関所を置くやり方を、ループの他の分岐点にも増やしていけば、Ronacherが恐れる「機械なしでは自分のコードを説明できない」状態を防げるのか。それとも、関所を増やすこと自体が、人間の役割を彼の言う「診断医」(症状を見て対処するだけで、仕組みそのものは理解しない立場)へ縮小させることの追認にしかならないのか。ここまでは、自分たちの運用記録から言えることだけを書いた。この先は、まだ検証していない。