Reins Engineering — 手綱のあるAI Image: AI generated

手綱のない馬

AIコーディングツールは速くなった。ログイン30秒。決済2分。MVPは3週間で出荷される。

3ヶ月後、崩壊する。

AIが決済ロジックを「整理」して割引計算を変える。リファクタリングの依頼で公開APIのフィールド名が変わる。新機能の追加で認証が壊れる。カーネギーメロンの研究（MSR 2026）によると、AIコーディングツール導入後、コードの複雑さは恒久的に41%増加する。Google DORA Report（2025）は、AI導入率が25%増加するごとに配信安定性が7.2%低下することを示している。

問題はAIが愚かなことではない。手綱がないことだ。

ハーネスは柵である

業界は「harness engineering」で応えた。リンター、フォーマッター、CI/CD、プロジェクト構造、コーディングガイドライン。エージェントを外に出さない柵だ。

柵は方向を定めない。エージェントが柵の中で何をしようと——既存のロジックを上書きしようと、型を変えようと、状態遷移をスキップしようと——リンターは通る。フォーマッターは通る。CIは通る。コードは「きれいだが間違っている」状態でプロダクションに届く。

鞍はつけた。騎手は乗った。しかし手綱がなければ、太ももで踏ん張って3ヶ月で落馬する。

Reins Engineering

Reins Engineeringとは、AIエージェントに決定論的な契約を与え、契約が破られたとき進行をブロックするエンジニアリングアプローチである。

3つの要素で構成される：

1. 決定論的フィードバック

エージェントに意見ではなく事実を与える。「これは変に見える」ではなく「41行目：フィールド名の不一致、期待値 ‘user_id’、実際値 ‘userId’」。sycophancyの余地がないフィードバック。TDADの研究（arxiv 2026）によると、手続き的な「TDDを実行せよ」という指示はリグレッションを悪化させ（6.08% → 9.94%）、一方で具体的なテストファイルをコンテキストに提供するとリグレッションが70%削減される（6.08% → 1.82%）。

2. 契約の固定（Ratchet Pattern）

検証が通ったら固定する。この方法で書かれた検証コードをratchet codeと呼ぶ。HurlテストはプレーンテキストでAPIの振る舞いを宣言し、CIで毎コミット実行される。通ったratchet codeは削除できない。エージェントはコードを自由に変えられるが、振る舞いは変えられない。ドリフトは構造的に抑制される。

3. 意思決定と実装の分離

コードに混在する3つのもの——ユーザーの意思決定、ビジネスロジック、実装の詳細——を分離する。意思決定は宣言的な仕様（OpenAPI、DDL、状態遷移図）に置く。実装はAIが自由に生成する。AIが意思決定を詳細と間違えて上書きすることはできない。意思決定の生存がモデルサイズから独立する。

進化

Prompt Engineering      → うまく言えばうまくいく
Context Engineering     → 良いコンテキストを与えればうまくいく
Harness Engineering     → 構造で囲い込む
Reins Engineering       → 手綱で方向を示す

各段階は前の段階の限界から生まれた。プロンプトだけでは一貫性がなかった。コンテキストではエージェントの暴走を止められなかった。柵では境界内のドリフトを防げなかった。

Reins Engineeringは柵ではない——手綱だ。エージェントの自由を制約するのではなく、エージェントが目的地に到達することを保証する。

2026年6月、この系譜にもう一つの名前が登録された。Loop Engineering——エージェントにプロンプトを打つ人間をやめ、プロンプトを生成するループを設計せよ（Addy Osmani、2026年）。診断は正しい。ループは生成をスケールさせる。しかし判定はスケールさせない。Osmani自身が弱点を書き残している——“A loop running unattended is also a loop making mistakes unattended."（無人で回るループは、無人で間違いを犯すループでもある。）ループが普遍化するほど、ボトルネックは一箇所に移動する：ループの検証スロットに何を差し込むのか？

そのレイヤーをverifier engineeringと呼ぼうが、eval engineeringと呼ぼうが、gate engineeringと呼ぼうが——実体は一つだ。**ループの判定スロットに必要なのはLLMではなく、決定論的な契約である。**私はそれをReins Engineeringと呼ぶ。手綱なしにループは収束しない。

80 : 20

Reins Engineeringはすべてをカバーしない。何をカバーするかを正確に知っている。

Deque Systemsは13,000以上のページにわたる約300,000件のアクセシビリティ品質問題を分析した（2021年）。57%は完全に自動化可能、23%はAI支援が必要、20%は人間のみが判定可能だった。アクセシビリティとコードはドメインが異なるが、「機械が判定できる割合」という構造は共有している。

このレンズでコード品質を見ると：

  • 57% — ラチェットの領域。振る舞いを宣言し、機械が問い合わせなしに違反を判定する。go test、Hurl、yongol check、filefunc validate。
  • 23% — ハーネスの領域。リンター、フォーマッター、CI。メカニズムは決定論的だが、検証の深さは表層にとどまる。振る舞いの正しさは捕捉できないが、構造とスタイルを整え、AI生成の品質を高める。
  • 20% — 人間の領域。ビジネス適合性、UX、アーキテクチャの方向性。

Reins Engineeringはハーネスを置き換えない。ハーネスの上に乗る。

ハーネス（表層の決定論）   23%
+ ラチェット（振る舞いの決定論）   57%
──────────────────────
                         80%

人間は残りの20%に集中する。

より大きなモデルが答えではない理由

「GPT-6が解決してくれる。」

解決しない。問題はモデルの知性ではなく、メディアにある。コードというメディアは意思決定と実装を区別しない。コードを読むどのモデルも、意思決定と詳細が同じテキストに混在しているのを見る。

4.5Bのローカルモデル（Gemma4）に決定論的フィードバック＋サンプルコンテキストを与えると、SSOTをエラーゼロで編集する。フロンティアモデルが生のコードを編集するとドリフトが発生する。違いは構造であり、知性ではない。

モデルを変えるな。契約を追加しろ。

実証

yongolはReins Engineeringの実装である。10の宣言的仕様（SSOT）の整合性を287のルールで交差検証し、コードを生成する。

ZenFlowベンチマーク——マルチテナントのワークフロー自動化SaaS。32エンドポイント、14テーブル、47 Hurlリクエスト。11/11ステージ合格。機能追加でスピードは落ちなかった。既存のテストは一度も壊れなかった。

4.5Bのローカルモデルで動くバックエンドの生成に成功した。コスト$0。オフライン。Reinsはモデルサイズが残すギャップを埋める。

AIレビュー自動化ではない——コードレビュー自動化だ

業界の主流アプローチはAIレビュー自動化だ。LLMがコードを生成し、別のLLMがそのコードをレビューする。酔っ払いが酔っ払いの友人に「俺、酔ってる？」と聞く構造だ。フロンティアモデルのsycophancy屈服率は58%。LLM-as-Judgeの偽pass率は36%。確率的生成に確率的検証を掛け合わせれば精度は劣化する。

Reins Engineeringはコードレビュー自動化だ。LLMが生成し、決定論的なコードが検証する。validateはお世辞を言わない。go testは幻覚を見ない。カバレッジ測定は嘘をつかない。passはpass、failはfailだ。

AIレビュー自動化:     LLM → LLM検証 → 追従 → 偽pass → ドリフト
コードレビュー自動化:  LLM → コード検証 → 事実 → pass/fail → 収束

AIエージェントが毎秒数十行を生成する時代に、人間がすべてのコードを読むことはできない。だからといってAIにレビューを任せれば、お世辞が検証を代替する。コードが機械的に検証可能な部分を代行すれば、人間は機械が判定できない決定——ビジネス適合性、UX、アーキテクチャの方向性——にだけ集中できる。

人間のレビューがゼロになるわけではない。人間のレビューの苦痛が減るのだ。コードがレビューできることはコードがやり、人間がレビューすべきことだけ人間がやる。

手綱のないハーネスはただの柵

AIはすでに十分強力だ。足りないのは方向だ。

柵を高く建てれば、エージェントはその中でより速くドリフトする。手綱を握れば、エージェントは目的地へ走る。

Reins Engineering——AIエージェントのための構造化された決定論的検証。

独立した収束

同じ原理に独立して収束した5つのプロジェクト：

  • episteme — UIUCの研究者によるAIエージェントのための認知制御プレーン。不可逆的なアクションの前にファイルシステムレベルでReasoning Surfaceの作成を強制する。ラチェットと同じ原理、異なる実装。
  • MagLab — KAISTのスピントロニクス研究者による物理研究パイプライン。“LLMs only reason and plan. They do not compute numbers, fabricate citations, or generate figure data.” 決定論的ツールがすべての数値出力を生成する。
  • Manifesto — フロントエンドの状態遷移を宣言的に定義するMEL。“Agent proposes, World verifies.” エージェントは意図のみを提案し、状態遷移は決定論的に検証される。
  • NEKOWORK — マージ前にAIコードの差分を決定論的ルールでスキャンするセキュリティゲート。ソースに関係なく機能する。LLMは判定しない。
  • oh-my-kamisama — Claude・Codex・Geminiを指揮するマルチCLIコンダクター。ワーカーの主張ではなく実際のgit diffを読んで検証し（「diffs beat claims」）、プロジェクトのテストが通って初めて完了を宣言する。すべての実行は消えるチャットではなく、監査可能なアーティファクトとしてディスクに残る。

すべてを要約すると：生成は確率的でよい。検証は決定論的でなければならない。

関連記事

References

  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Google Cloud (2025). DORA Report 2025. cloud.google.com
  • Wang, Z. et al. (2026). “TDAD: Test-Driven Agentic Development.” ACM AIWare 2026. arxiv.org/abs/2603.17973
  • Karpathy, A. (2026). “From Vibe Coding to Agentic Engineering.” thenewstack.io
  • Deque Systems (2021). “Automated Testing Study Identifies 57 Percent of Digital Accessibility Issues.” deque.com
  • Anthropic (2026). “Demystifying Evals for AI Agents.” anthropic.com
  • Osmani, A. (2026). “Loop Engineering.” addyosmani.com

変更履歴

  • 2026-05-23: 初回公開
  • 2026-05-27: 「独立した収束」セクション追加（episteme、MagLab、Manifesto、NEKOWORK）
  • 2026-05-28: 「80:20」セクション — ハーネス(23%) + ラチェット(57%) = 80%、Deque実証データで定量化
  • 2026-05-31: 「独立した収束」に oh-my-kamisama を追加
  • 2026-06-10: 「進化」セクションに Loop Engineering の段落を追加——ループの判定スロット、別名の吸収（verifier/eval/gate engineering）