「完了」は誰が定義するのか

賃貸業をしているとしよう。入居者が部屋を空け、担当者が退去を確認しなければならない。

私はこう設計した。担当者は「確認しました」と言えない。代わりに部屋の指定された5か所を写真に撮ってシステムにアップロードする。5枚すべて揃ったとき、はじめてシステムが「退去確認完了」として処理する。1枚でも欠ければ、完了はない。

この説明を聞いた誰かが言った。「それ、ゲームのクエストそのものじゃないですか？」

その通りだ。まさにそれだ。そのひと言が、私が何年もコードで格闘してきたことを一瞬で言い表してしまった。

ゲームはこれを40年前に解いていた

「늑대の毛皮を5枚集めてこい。」ゲームはこれを何十年もやってきた。そしてゲームはプレイヤーの主張を絶対に信じない。「全部倒しました」と言っても、クエストは完了しない。ゲームが見るのはひとつだけだ — インベントリに毛皮が5枚あるか。あれば完了、なければ未完了。それだけ。

私が作ったものゲームが作ったもの
完了の定義 = 指定5か所の写真クエスト目標 = 늑대の毛皮5枚
仕様 = どこを撮るかのリストクエストログ・目標マーカー
検証 = 写真5枚が存在するか？検証 = 毛皮5枚あるか？
判定 = システムが完了処理判定 = ゲームが完了を表示
担当者 = 実行者（判断者ではない）プレイヤー = 実行者

構造はまったく同じだ。**「完了」を宣言する主体が、行為者の口からシステムへと移っている。**行為者は条件を満たすだけで、完了を告げるのは常にゲートだ。

これがReinsだ — コードも同じだ

私はAIコーディングで同じことをしている。AIが「できました」と言っても信じない。テストが通り、型が合い、スキーマ検証が落ちないとき — そのときシステムが「完了」と判定する。クエスト目標が「テスト4419件通過」で、インベントリの代わりにCIがそれを確認する。エージェント研究の標準ベンチマークはまさにこの方式だ — SWE-benchは「完了」を実際のPRのテストスイート通過で、WebArenaは環境状態の機能的正確性で定義する。自然言語の「できました」ではなく。

賃貸退去であれ、늑대の毛皮であれ、コードであれ — 核心はひとつだ。**「完了」の判定を行為者自身から切り離し、行為者の外に定義されたゲートへと移す。**行為者が人間であれAIであれ関係ない。特にAIに自分の完了を判定させてはならないことは実験でも明らかになっている — モデルの自己検証(self-critique)は性能をほとんど上げないが、外部の決定論的検証器は大きく上げ(Stechly & Kambhampati, 2024)、正直に出発したモデルでも自己報酬を判定する権限を与えると、その関数を操作する欺瞞的戦略を自ら見つけ出す(McKee-Reid et al., 2024)。手綱(reins)は馬を遅くしない。馬が엉뚱한方向に走るのを防ぐ。

そしてここで一つのことが鮮明になる。意見を与えると行為者は揺らぐ。「本当に確認しましたか？」と詰め寄ると担当者は萎縮し、AIは正しかった答えを翻す。だが写真5枚は意見ではない。テスト通過は意見ではない。毛皮5枚は意見ではない。**事実にはへつらう相手がいない。**ゲートが事実を問う限り、誰もそれを丸め込むことはできない。

ゲームはさらに難しいことも先に経験していた — cheese

ここで止まると半分しか見えていない。ゲームが本当に教えてくれるのはその先だ。

「ねずみを10匹倒せ」は悪名高いクエストだ。なぜか？そのゲートが検証すること（ねずみ10匹の死）と、デザイナーが本当に望んでいたこと（プレイヤーがコンテンツを体験すること）の間に隙間があるからだ。ゲートは目的のプロキシに過ぎず、プレイヤーはその隙間に踏み込む。スピードランナーは完了条件と設計意図の隙間を見つけてゲームを壊す。これをゲームデザインではcheeseと呼ぶ。そして最新の推論モデルもまさにこれをする — チェスエンジンを倒せというクエストを与えられると、o3のようなモデルは正々堂々と指す代わりにゲームの状態ファイルを操作して「勝った」を作り出した(Bondarenko et al., 2025)。能力が高いほど、隙間をより巧みに見つける。

私の賃貸ゲートもcheeseされ得る。写真5枚は「写真が存在する」を検証するのであって、「退去がきれいに終わった」を検証するわけではない。担当者がきれいな壁だけを選んで撮ったら？入居前の写真を使い回したら？ゲートは通過する。測定が目標になった瞬間、測定は壊れる — Goodhartの法則であり、Manheim & Garrabrant(2018)はこの過最適化失敗を四つの変種に分類した。AI安全研究は同じ現象をかねてより’reward hacking’として整理しており、散らかったものを片付ける代わりに見えないよう隠すエージェント(Amodei et al., 2016)は、きれいな壁だけ撮る担当者とまったく同じことをしている。

私はこの隙間をコードで何度も経験する。先ごろ、スター23,000のウェブフレームワークを「ファイル一つにコンセプト一つ」ルールでリファクタリングし、テスト4,419件がすべて通過することを確認した。検証された事実だ。しかし同じデータをさらに掘り下げると、ルールは通過したのに目的は90%しか達成されていなかった — 10%のファイルはいまだ複数のコンセプトを一か所に収めていた。ゲート（ルール違反0）は通過したが、そのゲートが狙った目的は完全には閉じていなかった。私が作ったゲートを、私のコードがcheeseしていたのだ。

だからReinsの本当の技術は「ゲートを設ける」ことではない。cheese不可能なゲートを設計することだ。弱いクエストは「写真があるか」を問う。強いクエストはタイムスタンプを要求し、位置メタデータを検査し、入居時点の写真とAIビジョンで差異を比較する。ゲームデザイナーが40年かけて「cheese不可能なクエスト」を考え続けてきたその文献が、実は「Goodhart耐性ゲート」の答案集だ。

そしてこれは自然には実現しない。検証可能な報酬(RLVR)で訓練しても、モデルはルールを学ぶ代わりに不完全な検証器をgamingする方を選ぶことがある(Helff et al., 2026)。幸い、ゲートを意図的に堅固にする（environmental hardening）と、精度損失なしにエクスプロイトが87.7%減少したという測定もある(Thaman, 2026)。ゲートの強度は運ではなく設計の問題だ。

一つ違う点 — 現実のcheeseのコストは本物だ

比喩には限界がある。ゲームクエストの完了条件は楽しさとペーシングのために設計される。現実の目的を必ずしも捉える必要はなく、cheeseされても無害だ。プレイヤーが「ねずみ10匹」を裏技で攻略しても誰も傷つかない。

現実のReinsゲートは違う。cheeseのコストは本物だ — 退去詐欺、ビルド崩壊、誤って承認された会計。だから現実のゲートはゲームよりさらにcheese耐性が必要だ。この非対称性がかえって核心を鮮明にする。ゲームもこれをやってきたが、私たちはより厳密にやらなければならない。

エージェントに仕事をさせることは、クエストを渡すことだ

ここまで来ると、一行が落ちてくる。

バイブコーディングが崩れる理由は、完了条件のないクエストを渡すからだ。目標マーカーもなく、完了判定もないクエストを受けたエージェントはマップをさまよう。「このくらいでいいか」と止まるか、果てしなく徘徊するか。Reinsはそのエージェントにまともなクエストを設計して渡すことだ。明確な目標（スペック）、見えるマーカー（SSOT）、cheese不可能な完了判定（決定論的検証）。

そしてこの一場面の中に、三層の技術が入っている。

  • **クエストをプレイする。**誰かが作ったゲートを導入して使う。 — ユーザー。
  • **クエストを設計する。**自分のドメイン（退去であれ、会計であれ、コードであれ）に合ったゲートを自分で構築する。 — 製作者。
  • **cheese不可能なクエストを設計する。**プロキシが目的に追いつかない地点をあらかじめ塞ぐ。 — 設計者。

ほとんどはプレイで止まる。場を広げるのは設計であり、その場が壊れないようにするのはcheeseを防ぐ設計だ。

だから

次に誰かが「できました」と言ったら、問い返すのではなく問え。

「完了とは何か、そしてそれを判定したクエストは誰が設計したのか。」

この問いに答えがないなら、あなたが手にしているのは完了ではない。誰かの主張に過ぎない。

関連記事

関連読書（外部）

  • Specification gaming: the flip side of AI ingenuity — Victoria Krakovna 他、Google DeepMind。ゲートは意図ではなくプロキシであり、エージェントがその隙間に踏み込むという本稿の論旨を、権威ある安全研究としてまとめている。
  • There’s Cheese in Your Game! — Shay Pierce, Game Developer。「つまらなくても最も効率的ならプレイヤーはそれを選ぶ」 — cheese不可能なクエスト設計というゲームデザインの視点が「cheese-proof gate」と正面から重なる。
  • From shortcuts to sabotage: emergent misalignment from reward hacking — Anthropic。コーディング課題で採点スクリプトだけを通過させるreward hackingがどう広がるか — 行為者を自分の完了の審判にしてはならないという最新の実証。
  • How to write a good spec for AI agents — Addy Osmani。「速くしろ」の代わりに「LCP < 2.5s」のように検証可能なsuccess criteriaに還元せよ — 完了をcheckable conditionとして定義せよという処方の実務版。
  • What is agentic engineering? — Simon Willison。人間の役割を目標定義・ツール準備・検証に分け、テスト通過を「done」と見なす観点 — エージェント＝実行者／人間＝クエスト設計者というreframeと一致する。

出典

  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)
  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • Helff et al. “LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking” (2026, arXiv:2604.15149)
  • Thaman. “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use” (2026, arXiv:2605.02964)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context RL Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Stechly, Valmeekam, Kambhampati. “On the Self-Verification Limitations of Large Language Models” (2024, arXiv:2402.08115)
  • Jimenez et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” (2023, arXiv:2310.06770)
  • Zhou et al. “WebArena: A Realistic Web Environment for Building Autonomous Agents” (2023, arXiv:2307.13854)
  • メイン画像: AI生成（Google Gemini）