散文で交わした約束は、壊れてもエラーにならない

kamo78氏は、あるレビューコメントの書式を文章で定義していた。ある日、気づく。その書式は一度も実際には守られておらず、検知の仕組みも一度も動いていなかった。誰も嘘をついたわけではない。文章で決めただけの約束は、破られてもエラーにならず、誰も気づかない(出典)。

氏がこの経験から導いた対処は、「文章の書式探し」をやめることだった。書式をルールとして書き記す代わりに、ツールが決定論的に埋め込む目印に切り替える。約束を守るかどうかを人間の注意力に委ねるのではなく、仕組みの側に埋め込む。

五層のガードと、Verdictだけが持つ特殊な地位

氏はこの発想を、AIエージェントのループ全体に広げている。ワークフローガード(工程順序・分岐・停止条件)、ステップガード(各工程内の手順)、Verdictガード(次へ進むか戻るか止めるかを構造化出力に限定する)、品質ゲートガード(lint・テスト・型チェックなどLLMを通さない機械的検査)、標準ガード(規約・変更種別ごとの必須ゲート)。五つのうち特に重要な区別は、Verdictガードが「LLMの判断を構造化する」のに対し、品質ゲートガードは「LLMをそもそも通さない」という点にある。

判断そのものは人間かLLMにしか下せない。だが、その判断を自由な文章のまま出力させるか、限られた選択肢に構造化して出力させるかは、設計で選べる。氏が選んだのは後者だ。

最後に人間が全部見る、を失敗パターンとして退ける

ここで氏は、直感に反する立場を取る。ループの最後に人間がすべて確認する、という設計そのものを失敗パターンとして退けている。「完了」は主張であって証明ではない、という言葉とともに、機械的なゲートをループの内側に配置し、人間が見るべきものだけが人間の前に届くようにすべきだと説く。人間が最後にまとめて全部見る設計は、見る量が増えるほど確認が形骸化する。

Parryの四軸は、散文ではなく構造化を選んでいる

一見すると、これはPRレビューツールParryの設計思想と正面から衝突するように見える。Parryは「confirm, don't write」、AIが書き、人間が確認するという哲学を掲げ、PRごとにWhy(なぜこの変更か)、Risk(影響範囲)、Confidence(自信度)、Context(背景)という4項目を人間の目の前に置く。氏の言う「人間が最後に全部確認する」設計そのものに見えなくもない。

だが、氏が退けているのは「人間が最後にすべてを見る」ことそのものではなく、「機械的に弾けるものまで人間の確認に委ねる」ことのほうだ。品質ゲートガードがlintやテストや型チェックをLLM抜きで機械的に弾くように、Parryの四軸もCIやlintを代替するものではない。四軸が引き受けているのは、機械的に弾けない領域、つまりなぜこの実装を選んだかという判断そのものである。ここは氏の言うVerdictガードに近い。LLMの判断を「進む・戻る・止める」という構造化出力に限定するのと同じように、Parryも判断を4つの構造化された欄に限定し、散文で自由に書かせない。

PRの説明欄を自由記述の散文にしてしまえば、氏が最初に壊れた例と同じ運命をたどる。書式は決めたのに誰も守らず、検知も一度も動かない。Parryが4項目を必須の構造化入力にしているのは、この散文契約の脆さを避けるための設計でもある。

それでも残る宿題

氏の指摘をもう一段まで押し進めると、Parryにもまだ答えていない問いが残る。すべてのPRに毎回、同じ重さで四軸の入力を求めていれば、それは氏が退けた「人間が最後に全部見る」設計に、四軸という構造化された姿のまま逆戻りしているだけかもしれない。機械的に弾けるはずの低リスクな変更を、品質ゲートガードのように先に弾く仕組みがないなら、確認の形骸化は構造化された欄の中でも起こりうる。

散文を構造化に変えたことは、約束が壊れたときに気づけるようにした、という一歩に過ぎない。気づけるようになった約束を、実際に毎回きちんと守っているかどうかは、また別の検証を要する。