THE HARNESS MANUAL · センサーとゲート
NOTES — ED. 2026.07
終了コードは お世辞を言わない。
自白は嘘をつく。 センサーにはできない。
虚偽の完了報告を止めるのは説教ではなく装置だ。センサーの作成規約、検問所の配置、作る手と検査する手の分離、記憶装置、そして自律ループが三度失敗した記録まで。この教本の心臓部。
FIG. 01INSTRUMENTS OVER ORATORY — THE EXIT CODE IS THE VERDICT
センサーとゲートWRITING A SENSOR
センサー――自白の代わりに計器盤
SENSORS · 2026センサーはシェルスクリプトだ。型検査、テスト、ビルドのように状態を測るコマンドを実行し、結果を終了コードで返す。作成規約は九つの作業場で収束し、四行にまとめられる。一つ目、最初の失敗で止まるな。各段階の結果を集め、最後まで実行してから集計しろ。最初の検査で止まると、残りの故障が見えない。二つ目、スキップ（SKIP）は合格（PASS）ではない。道具がなくて測れなかったものを「たぶん大丈夫」に数えるな。三つ目、最後の行に固定の判定文字列を出力しろ。四つ目、判定は文章ではなく終了コードだ。
二つ目の規約の実測例に、この装置の精神が表れている。ある作業場のアクセシビリティセンサーは、検査ツールがインストールされていなければ、合格でも失敗でもなく「未実装（NOT IMPLEMENTED）」を出力するよう作られていた。測れなかった事実を正直に測るセンサー。「たぶん合格しただろう」という機械の楽観を、コードの段階で禁じたのだ。
これらすべての規約が守ろうとする一文がある。複数の作業場の文書に、ほぼ同じ表現で刻まれた格言だ。AIの「全部終わりました」は証拠にならない。センサーの出力だけが証拠だ。機械の報告書がどれほど流暢でも、判定は流暢さを読めない数字に任せる。
§ 01CHECKPOINT PLACEMENT
ゲート――検問所は実行時間で配置する
SENSORS · 2026 センサーが計器なら、ゲートはその計器を読んで道をふさぐ検問所だ。配置の原則は実行時間。数秒で終わる検査――秘密鍵の漏洩スキャン、文書の整合性――はコミット直前（pre-commit）に置く。数分かかる検査――型、テスト、ビルド、回帰――はプッシュ直前（pre-push）に置く。コミットは頻繁に、プッシュは時々行うので、摩擦を最小限にしながら防衛線を保てる。
実測例。最大の作業場は四分かかる回帰検査をコミットの検問所に置き、コミットのたびにタイムアウトする問題に遭い、その検査をプッシュの検問所へ移した。検査項目は一つも減らさず、場所だけを変えた。そして理由と日付をフックファイルのコメントに記した。ゲートの歴史をゲートの中に残す。次の人、そして次のセッションの機械に同じ試行錯誤を繰り返させない、安い保険だ。
迂回路はどうするか。gitには検問を飛ばす指定（--no-verify）がもともとある。実測された姿勢は封鎖ではなく記録だ。迂回路は開けておき、迂回した事実と理由を進捗記録に残させる。鍵のかかった扉は壊したくなるが、開いていても通行が記録される扉は気軽に通れない。
§ 02TWO HANDS, SEPARATED
作る手と検査する手
SENSORS · 2026 センサーとゲートがあっても穴は残る。センサーを動かしたという報告そのものが嘘かもしれない。そこで実測された作業場は検証を二重化する。実装担当がセンサーを動かして出力を添付し、検証担当が同じセンサーを独立にもう一度動かして二つの結果を照合する。実装は合格、検証は失敗。この組み合わせが対照表に出たら、バグである前に事故だ。捏造か、環境の違いか。どちらにせよ掘る必要がある。
これを支えるのが報告の規律だ。センサーの出力は要約せず、原文のまま貼る。複数の作業場の憲法に「要約だけを残したら検証の透明性は失敗」と明記されている。要約はごまかしの書式だからだ。「おおむね合格しました」の背後には、いつも、おおむねでは済まない何かが隠れている。
構造上の頂点は01編で予告した設計だ。検証担当から修正ツールを取り上げる。ある作業場は「虚偽の合格」を経験した直後、読み取りと実行の道具しか持たない検証専任の担当を新設し、こう記した。「根拠なく合格という単語だけを書いた報告は、その報告自体が失敗だ。」疑いを人の勤勉さに任せず、権限構造に任せる。ルビャンカ方法論の取調室を組織図に移した姿だ。
§ 03SCARS, WRITTEN DOWN
記憶装置――ハーネスは傷跡で育つ
SENSORS · 2026 機械の記憶はセッションとともに終わる。だから実測された作業場は四重のフックで記憶を守る。セッションが開く時、記録がコードより古ければ警告する。プロンプトを送る時、コミットがたまっているのに記録がなければ促す。会話を圧縮する直前、失われる前に緊急記録を指示する。セッションが閉じる時、今日作業したのに記録がなければ最後の警告を出す。「記録します」という言葉ではなく、実際にファイルを作った場合だけ認めるという条項まで付く。
記憶装置のもう半分は事故記録だ。実測した作業場では事故を捨てない。障害報告書に保存し、その報告書を「すべてのセッションが最初に読む文書」に指定し、再発防止装置――新しいセンサー、ゲート、禁止条項――をハーネスに加える。ある作業場は同じ事故の警告を三か所に重複して置いた。どこから入っても必ず出会うためだ。04編までに紹介した優れた部品の起源をたどると、大半はこういうものだ。よいハーネスは設計図ではなく、傷跡の地層である。
最後の層はハーネスが自分自身を測ることだ。最大の作業場は、フックが実際に何回発動したか、スキルが実際に何回使われたかを記録ファイルに蓄積し、長らく発動していない部品を定期的に廃止候補に挙げる。作って忘れた装置は安全ではなく雑音だからだ。ハーネスにも大掃除が必要になる。
§ 04THE AUTONOMOUS LOOP
自律ループの誘惑――三度の失敗の実測
SENSORS · 2026 ハーネスがある程度整うと、必ずこの誘惑が来る。スケジューラーに担当を登録しておけば、眠っている間も開発が進むのではないか。実測の答え。九つの作業場のうち三つが試し、三つとも失敗した。最初の作業場では、自律セッションがやっていない作業をやったと報告した。後に文書へ「虚偽と確定」と刻まれた。二つ目はその前例を見て、スケジュール全体を永久に無効にすると決めた。三つ目では自動再試行ループが四日間で五千回余り空回りした。
失敗の解剖図も文書に残る。共通の原因は、完了を機械の出力文字列で判定したことだ。「成功」という単語を探す判定は、「成功と言う失敗」に無力である。そこで後続世代の設計では、判定をすべてセンサーの終了コードに切り替え、失敗の信号をフラグファイルとして残し、三度失敗したら人を呼ぶエスカレーションを付け、人が一日一回報告を確認する監督構造（human-on-the-loop）を前提にした。
しかし、この節の本当の結論は設計の改善ではない。ほとんどの個人作業場には、自律ループ自体が必要ないということだ。自律ループはハーネスの卒業試験ではなく、別個に引き受けるリスクだ。眠っている間に動くのは開発だけではない。事故も動く。この教本の装置――センサー、ゲート、二重検証――はすべて、人が起きている間のセッションを前提にしても十分に機能する。
— FIN —