手綱を渡されたツールに、手綱がなかった — ハーネスとレインスの境界

Image: AI generated

2026年3月31日、AnthropicがClaude Codeのnpmパッケージ(v2.1.88)にソースマップを誤って同梱して公開した。.npmignoreに1行が漏れたためだ。¹ 59.8MBのソースマップが難読化されていないTypeScript約51万2千行、1,900余りのファイルをそのまま晒した。Anthropicは「セキュリティ侵害ではなく配布パッケージングのミス、人為的ミス」と説明し、ユーザーにはv2.1.87へピン固定するよう推奨した。

人々が覗き込んだコードベースで、あるファイル(print.ts)の単一関数が3,167行に達していた。²

世界で最も売れているコーディングエージェント、私たちにコードの手綱を渡すと謳うそのツールが — 正作自分自身には手綱をかけていなかった。

このアイロニーを嘲笑うために持ち出したのではない。正反対だ。この事件は、私が長い間すっきりと答えられずにいた問いへの、最も鮮明な答えだ。

「Reins Engineering、結局 harness engineering じゃないですか？」

良い問いだ。鋭い問いでもある。両者は確かに似ている。どちらもモデルの外にあるものだ。どちらもコードで組む非モデル構造物だ。どちらもエージェントが的外れな動きをできないようにする。だから「手綱は馬具の一部に過ぎないのでは」という疑念は正当だ。

私はしばらくこの問いにすっきりと答えられなかった。答えを見つけてみると、その答え自体がReinsとは何かを最も正確に説明する。そして上記の流出事件は、その答えを実物で証明する。

まず、両者は対立しない

馬具(馬具)を思い浮かべてみよう。馬の背に載せる鞍と頭絡、そしてその頭絡にはみ(bit/재갈)を咬ませて人の手まで繋がる二本の紐 — 手綱。

手綱は頭絡に咬ませてある。 馬具の外にあるのではなく、馬具に装着された部品だ。だから「ハーネスとレインスは明らかに異なるか、対立するか?」と問えば答えは否だ。両者はひとつの装備の部分と部分だ。

ここから始めなければならない。よくあるコピー — 「ハーネスは柵、レインスは操縦」 — は両者を対立させる。対立させた瞬間に負ける。「検証ゲートもハーネスの一部じゃないか」というひと言で崩れる。正しい話だからだ。CI も、型チェックも、テストスイートもモデル外のスキャフォールディングであり、それはハーネスが含むものだ。

だから問いを変えなければならない。対立するかではなく、どこで分かれるか。

レインスはどこから可能になるか — 三層のループ

分かれる場所を見つける前に、レインスがどこで初めて可能になるかから見なければならない。ループの層で見れば三つだ。

① チャットループ     LLM → 人間 → LLM              全て確率的。レインス不可能。
② エージェントループ LLM → 実行 → 結果観測 → LLM   実行が決定論的な地を踏む → レインス可能。
③ Reins ループ       ② + 設計された検証器 + ラチェット  レインス完成。

チャットループには頭絡をかける場所がない。馬に乗ることさえできない状態だ。LLMが答え、人間が読み、再びLLMに投げる間、どのコマも決定論的なところがない。信号を咬ませる金具がないのだ。

エージェントループが鞍を載せる。実行が介入する瞬間 — コンパイラが走り、テストが落ち、ファイルが書かれ — ループが決定論的な地を初めて踏む。 ようやく掴む場所ができる。

Claude Codeが圧倒的に成功した理由がまさにここだ。Bash、ファイルI/O、テスト実行という決定論的ゲートをループの中に(半ば偶然に)組み込み、「部分的レインス」をすでに持っていた。 チャット時代にはなかったものだ。

これは私の主張だけではない。プリンストンのHAL(Holistic Agent Leaderboard)は、同じモデルでもスキャフォールドを入れ替えるだけで精度が数十パーセントポイント揺れることを、2万1千余りのエージェント実行で示した。³ モデルは固定、変わったのはモデルを包む構造だけだ。Addy Osmaniは一言でまとめる。「それなりのモデル + 優れたハーネス > 優れたモデル + 粗悪なハーネス。」彼は同じOpusがClaude Codeよりカスタムハーネスの中でより高いスコアを出すとも書いた。⁴

ここまでが業界が「ハーネスエンジニアリング」と呼ぶ領域だ。正しい発見だ。そしてこれがまさに、レインスと混同しやすい場所だ。どちらもモデルの外で結果を作るから。

しかし②はレインスの偶然の半分に過ぎない。Reins Engineeringはその半分を意図的に完成させる仕事だ。偶然に入り込んだゲートを、設計された検証器とラチェットと決定/実装分離で置き換えて②を③へ引き上げること。ハーネス言説はレインスを証明するが、代替することはできない。

三つの軸

一頭の馬を前に二人が仕事をする。

一人は馬具を作る。鞍の寸法、頭絡の強度、はみの形。これはどの馬、どの旅程にも同じく使える。 一度うまく作ってしまえば、東京に行こうと大阪に行こうと同じ馬具だ。作る人は馬具職人 — 馬に乗る人ではない。

もう一人は手綱を握る。彼はこの旅程を知っている。どの分かれ道で左に曲がるべきか、どこが目的地か、いつ「着いた」と言えるか。彼が握る紐は同じ馬具に咬ませてあるが、彼が送るシグナルは旅程ごとに異なる。シグナルを送る人は馬具職人ではなく騎手だ。

ここに三つの軸がある。

• 機能。 ハーネスは防ぐ — できないようにする境界。レインスは導く — どこへ行き、いつ終わったか。
• 寿命。 ハーネスは一度作ってすべての課題に再利用される。レインスは課題ごとに新たに設計される。
• 所有。 ハーネスはベンダーが出荷する。レインスはアーキテクトが著述する。

Claude Codeのループは私のプロジェクトが何であれ同一だ。それはハーネスだ。Anthropicが作って出荷し、全ユーザーに等しい。しかし「賃借人退去 = 指定箇所5か所の写真」という完了の定義は、私が、このドメインのために、直接書いたものだ。どんなハーネスにもそれは入っていない。それがレインスだ。

依存は一方向にしか流れない

両者が同じものなら、片方だけ取り外すことができないはずだ。取り外してみよう。

ハーネスはあるのにレインスがない。 エージェントは動く。止まらずに動く。ただし迷う。目標マーカーも完了判定もない野原を彷徨って、「このくらいでいいだろう」と止まる。私たちはこれをすでに知っている。バイブコーディングと呼ぶ。

レインスはあるのにハーネスがない。 これは成立すらしない。手綱を握ったのに咬ませる頭絡がない。シグナルを送る場所がない。虚空に紐を握っているだけだ。

依存は一方向だ。レインスはハーネスを必要とするが、ハーネスはレインスを必要としない。ハーネスはレインスなしでも動く — 悪く動くだけだ。この非対称性が「両者は同じ」を明快に論駁する。同じものなら取り外したとき両方が崩れるはずだが、ハーネスは一人でも走る。

重なる場所はただ一コマ

では本当に重なるところがないのか? ある。正確に一コマだ。

実行される検証ゲート。 CIがエージェントループの中で動く。その執行面は両側にかかる — ハーネスの一部でもあり、レインスがかけるものでもある。ここが「それはハーネスじゃないか」という問いが生まれる場所だ。そうだ、その一コマでは両者が同じものを指す。

しかしその外は分かれる。

   ハーネスのみ           積集合              レインスのみ
─────────────────  ─────────────────  ─────────────────
 サンドボックス·権限  検証ゲート           完了の定義
 ツール配線           (実行されるチェック)  チーズ防御設計
 コンテキスト管理                          プロキシ↔目的分析
 (方向なき封鎖)       (執行面)             (基板なき意図)

ハーネスには方向のない封鎖が別にある — サンドボックスはどこへ行けとは言わない、ただ出られないよう塞ぐだけだ。レインスには執行基板のない意図が別にある — 「何が完了か」という定義は、それを実行するゲートがなくても先に存在する。どちらも相手を丸ごと含めることはできない。両者は交差する。包含しない。

部分集合かという問いが誤りである理由

「ではレインスはハーネスの部分集合か?」

部分集合であるためには両者が同じ物差しで測られなければならない。しかしハーネスは誰が出荷しどれだけ再利用されるか(基板の軸)で定義され、レインスは軌跡に何をするか(機能の軸)で定義される。軸が異なる。

「赤は重さの部分集合か?」と問うのと同じだ。赤くて重いもの(=実行されるゲート)はあるが、色が重さに含まれることはない。測る物差しが異なるからだ。部分集合という関係自体がここではカテゴリーエラーだ。

正確な関係はこうだ。レインスはハーネスを前提とするが、ハーネスに含まれない。 上に乗る層は中に収まる部分ではない。乗ったものは基板の向こうへ延びる。

本当に分かれる場所 — チーズ

ここまでは構造の話だ。しかしReinsがハーネス言説と決定的に分かれる場所は別にある。チーズ(cheese)だ。

ゲームデザイナーは知っている。「ネズミを10匹捕まえろ」は悪名高いクエストだ。ゲートが検証するもの(ネズミ10匹の死)とデザイナーが本当に求めたもの(プレイヤーがコンテンツを体験すること)の間に隙間があり、プレイヤーはその隙間に入り込む。これをチーズ(cheese)と呼ぶ — ゲームをズルく攻略する行為のことだ。AI安全研究が「仕様ゲーミング(specification gaming)」と呼ぶものと正確に同じ現象だ — ボートレースエージェントがゴールラインの代わりにスコアアイテムをぐるぐる回って拾い、テトリスエージェントが負けないようにゲームを永遠に一時停止させる。⁵

私の賃貸ゲートもチーズされる。写真5枚は「写真が存在する」を検証するのであって、「退去が無事に終わった」を検証しない。担当者がきれいな壁だけ選んで撮ったなら? ゲートは通過する。測定が目標になった瞬間、測定は壊れる — グッドハートの法則だ。⁶

ここが核心だ。ハーネスは「通過したか」までしか答えられない。 テストがグリーンか、型が合っているか、スキーマが壊れていないか — そこまでだ。しかし**「その通過が目的を捉えているか」** はハーネスが永遠に答えられない。何がチーズかはドメインの目的を知ってはじめて定義されるからだ。きれいな壁だけ撮った写真がなぜ詐欺なのか、規則はすべて通過したのになぜ目的は90%しか閉じていないのか — それはこの仕事が何のためかを知る人だけが知っている。

その人が騎手だ。レインスを握る者。

チーズ不可能なゲートを設計すること — プロキシが目的に追いつかない地点を事前に防ぐこと — は本質的に課題ごとに異なり、ドメイン知識を含み、運用者が著述する。task-agnosticなハーネスはこれを与えられない。与えられないのではなく、ドメインを知らないからそもそも扱えない。

ここがReins Engineeringがharness engineering、agentic engineering言説にない固有の領土だ。彼らは馬具をより良く作る方法を語る。Reinsはこの旅程を、壊れずに、どの門へ向かわせるかを語る。

だから改めて、流出事件へ

今、最初のアイロニーに戻ろう。その事件がなぜ嘲笑ではなく証拠なのかが今は見える。

馬は天才だった。Opusは確率的な力そのものだ。鞍も機能した — Claude Codeは世界最高の馬具であり、HALの数字がそれを証明する。しかしその馬具で作った自らのコードベースは正確に予測された失敗モードへとドリフトした。ひとつの関数が3,167行。200エンドポイントの壁がコードとして現れた姿そのままだ。流出自体も.npmignoreの1行欠落 — デプロイ成果物にゲートがなかったという意味だ。

世界最高の馬具を作った会社でさえ、その馬具を自らの厩舎にはかけなかった。

これは反テーゼではなくテーゼの決定的証拠だ。レインスはモデルやエージェントが持つ属性ではなく、適用する規律だ。 エージェントが賢いことと、そのエージェントで作ったコードがレインスの下に置かれることは完全に別の話だ。より大きなモデルが答えではない。より良い馬具も答えではない。手綱を握り、この旅程の完了を自ら定義し、チーズを防ぐようにゲートを設計する — その規律が答えだ。

だから

ハーネスは馬を走らせる。レインスは馬をどの門へ向かわせるかを定める。ハーネスは一度かけておくものであり、レインスは毎瞬間握っているものだ。ハーネスは職人が出荷し、レインスは騎手が手に握る。

両者は対立しない。同じ馬具の異なる部品だ。しかし、異なる部品だ。ハーネスなしにレインスは存在できず、レインスなしにハーネスは迷う。そしてこの仕事がきちんと終わったかを知るのは — 常に手綱を握る手だ。

次に誰かが「それは結局ハーネスじゃないか」と問うなら、こう答えよ。

「ハーネスはベンダーが出荷するものであり、レインスは私がこのクエストのために設計するものだ。ハーネスなきレインスはないが、レインスなきハーネスはただ迷う。私たちに手綱を渡したそのツールでさえ、自らのコードには手綱がなかった — レインスは持つものではなく、かけるものだからだ。」

関連して読む

• 手綱のあるAI: Reins Engineering — ゲート=手綱 reframeの出典
• 「完了」は誰が定義するか — チーズ不可能なゲート、クエストデザインとしてのタスキング
• コーディングエージェントはなぜ機能し、なぜ壊れるか — 「生成は確率的であっても検証は決定論的でなければならない」
• なぜあなたのエージェントは止まらないか — 止まれるシステム = 完了が定義されたシステム
• 竜骨(yongol): 200エンドポイントの壁 — 運用者が著述する仕様 = レインスの実物

合わせて読みたい

この文が扱った境界 — ハーネスとレインス、止まる方法、ゲーミングされる仕様 — をより深く、あるいは別の角度から掘り下げた外部記事。

• How Coding Agents Work — Simon Willison — 「コーディングエージェントはLLMを包むハーネスだ。」本文に入る前に読むハーネスの決定版定義。
• Agent Harness Engineering — Addy Osmani — ハーネスをひとつのエンジニアリング分野として正式化。‘sprint contract’で終了条件を扱う — 本文と最も正面から重なる。
• Reward Hacking in Reinforcement Learning — Lilian Weng — グッドハート法則と仕様ゲーミングの理論的骨格。「チーズ」がなぜ起きるかをRL・RLHF観点から支える。
• Water Finds a Crack — Soren Johnson — 「機会が与えられればプレイヤーはゲームを最適化で搾り取る。」報酬ハッキングの人間的原型を示すゲームデザインの古典。
• Effective Harnesses for Long-Running Agents — Anthropic — 「終わってもいないのに終わったと宣言する」失敗を1次当事者が扱う。終了条件と決定論的検証を一記事に。