テストやルールになにを書くかは、なにをエージェントに任せるかで変わる

この記事は2026年7月時点の情報に基づきます。モデルの能力やエージェント製品の状況は変化が速い領域のため、お読みになる時点では状況が変わっている可能性があります。

先に結論だけ

モデルの世代交代がもたらすのは、同じタスクの成功率の向上だけではありません。どの工程をエージェントに委任できるかという、境界線の移動をともないます。

テストやルールなど、知識をどこに書くかの設計（この記事では「知識集約構造」と呼びます）は、この委任の境界線に合わせて調整されています。境界が動くと、古い境界を前提に置いた制約は安全策から足枷へ反転します。

だから知識集約構造に最終形はなく、古くなることを前提に引き直し続けるしかありません。実務上の規律は、どの境界を前提に構造を引いたかを記録し、境界が動いたときに低いコストで更新できる形で持つことです。

はじめに

新しいモデルの評価は「ベンチマークが何ポイント上がったか」で語られがちです。しかしプロジェクトを運営する視点では、成功率の数字よりも重要な変化があります。それは「昨日まで人間がやるしかなかった工程を、今日からエージェントに任せられるようになる」という、委任の境界線の移動です。

境界線が動くと、プロジェクトに関する知識をどこに書くべきかも変わります。なにをテストとして固定し、なにをルールとして文書化し、なにを書かずにエージェントの判断へ委ねるか。この配分は、境界線の位置を前提とした設計判断だからです。

この記事は、コーディングエージェントをプロジェクトに導入していて、テスト戦略やエージェント向けルール（CLAUDE.mdなど）の置き方を再考したい開発者・チームリードへ向けたものです。まず筆者がこの見方に至った体験を紹介し、次に中心となる考え方を示し、2つの実例（テストの意味の反転、ハーネスへの委任範囲の拡大）で裏づけ、最後に実務上の規律へ落とします。個別ツールのセットアップ手順は扱いません。

仮説立案から検証まで任せて走り切ったチューニングセッション

この記事を書くきっかけは、あるパフォーマンスチューニングのセッションでした。処理速度の改善を目的に、「同じ結果を保てるならロジックごと変更してよい」と指定して、エージェント（モデルはFable）に作業を任せました。

エージェントは、改善につながりそうな仮説を複数、自分から提案しました。そして、どの仮説が目的にもっとも近づくかを確かめるテストコードを自分で作成し、計測して比較しました。人間が渡したのは目的と「ロジック変更可」という許可だけです。仮説の立案から検証手段の用意までがエージェントの側で完結し、セッションは最後まで走り切りました。

この体験で印象に残ったのは、性能の数字よりも、任せられる範囲の変化でした。少し前まで「実装を任せる」だったものが、「検証のやり方を考えることまで任せる」へ広がっていたのです。

同時に、人間側の責任も変わっていました。実装のコードを1つずつレビューする代わりに、エージェントが用意したテストコードの方針が妥当かどうかを確かめる。それが人間側の仕事になっていました。この変化を一般化したものが、次に述べる委任の境界線という見方です。

委任の境界線を動かす、能力と権限の2軸

どの工程をエージェントに任せられるかは、2つの軸の組み合わせで決まります。

• 能力: モデルがその工程を十分にこなせるか
• 権限: それを実行させてよいか（どこまでを人間が確認し、どこから先を信頼して任せるか）

どちらか一方の軸が動くだけでも、境界線は動きます。たとえばコーディングエージェントへのシェル実行権限の付与は権限軸の移動であり、モデルの世代交代は能力軸の移動です。能力は拡大し続け、権限も実績に応じて段階的に開かれていくため、境界線は今後も動き続けます。

ただし、2つの軸は対称ではありません。能力的に実行可能になった工程でも、「実行させてはいけない」という判断は残り続けるからです。たとえば経営にかかわる判断では、補助するエージェントの性能がどれだけ上がっても、決裁を行うのは常に人間です。こうした判断の基準はコードのどこにも書かれておらず、エージェントがコードを読んでも導き出せません。権限の境界線は開かれていく一方で、人間の側に残る一線があります。

知識集約構造は、委任の境界線に合わせた設計

プロジェクトの知識は、置き場所によって拘束の強さが変わります。置き場所は大きく3つの層に分かれ、それぞれの層には複数の仕組みが属します。

• 強制の層: テスト、エージェントのhook、CI、権限のdenyリストなど。違反すると先へ進めない形で、機械的に強制されます
• 指針の層: ルール、スキル、ドキュメントなど。エージェントの提案を方向づけます
• 記録の層: コミットログなどの作業記録。あとから参照できます

そして「なにをどの強さで固定するか」の判断は、エージェントへの信頼度、つまり委任境界の位置に依存しています。

運用のイメージを1つ挙げます。ニーズを受け取って実装案の提案まで任せられる、広い境界を持つエージェントを導入したプロジェクトなら、知識の置き場所を次のように動かせます。

• 強制の層: 挙動を細かく固定していたテストを薄くし、守るべき一線以外は指針の層（ルール）へ降格させる
• 指針の層: ルールのうち、エージェントが常識として確実に知っている事項は削除する
• 記録の層: 作業の経緯や試行錯誤は、エージェントが承認なしで自由にコミットログへ記録してよいことにする

境界が手前にある（実装の一部だけを任せる）プロジェクトなら、同じ知識をもっと強い層に置くことになります。配分は境界の位置しだいで決まります。

問題は、境界が動いたあとです。エージェントの能力不足を補うために置いた制約は、不足が解消された途端、意味が変わります。守ってくれていた柵が、探索を妨げる足枷になります。構造そのものは1行も変わっていないのに、境界の位置が変わるだけで、同じ構造の価値が反転するのです。

以下、境界の移動が構造の意味を変える様子を、2つの実例で確認します。

実例1: 境界の前後で反転する、重厚なテストの意味

テストの重厚化への批判

「テストは厚く網羅的にするほど安全だ」という前提への批判は、新しいものではありません。Kent Beckは2008年の時点で「私は動くコードに対価をもらっている。テストにではない」（筆者訳）と述べ、Google Testing Blogは2015年に、挙動が同じなのに実装変更で失敗するテストを有害だと指摘しました。1999年から2019年まで、テストの重厚化を戒める主張は繰り返し発表されてきました¹。

テストが重厚になりやすい、構造的な理由

これだけの指摘が続いても、テストの重厚化は簡単にはなくなりませんでした。重厚化には理由があるからです。自動テストは、コードの品質や一貫性を守る仕組み（ガバナンス）として、もっとも導入しやすい手段です。そのため、本来は設計思想の共有やチームの育成といった別の手法でケアすべき部分まで、テストにしわ寄せが行きやすい構造がありました。

テストは、実装方針の空間に対する枝刈りとして働きます。1本のテストは「この挙動を変える実装は禁止」という宣言であり、テストを増やすほど、生き残る実装は書いた人間が予期した形へ絞られていきます。人間だけが実装していた時代にも、この枝刈りのコストは支払われていました。テストの数だけメンテナンスの手間は増え、既存のテストが新機能の追加を難しくする場面もありました。それでも、刈られて困るほど広い探索は、そもそも実行できませんでした。複数の実装案を書き比べるだけの人手をかけることは、経済的に成立しなかったからです。維持の手間はかかっても、探索を失う側のコストは小さかったため、変更を機械的に検知してくれる重厚なテストは割に合う保険でした。

境界が動くと、同じテストは探索を刈る足枷になる

こうした重厚で実装に密に結合したテストが抱えていた問題は、コーディングエージェントの出現によって露見しやすくなりました。エージェントが広い実装空間を探索し、人間が予期しなかった実装案を提案できるようになると、損得の計算が変わります。網羅的なテストは「以前と同じ挙動」をまるごと固定してしまうため、本質と関係のない挙動の差異までがテストを失敗させ、提案を却下します。枝刈りで失う探索価値は、モデルの提案能力に比例して増大します。

つまり「薄いテストが良い」という主張自体は20年来の再確認にすぎませんが、その重みが変わりました。かつては人間のリファクタリング自由度のための助言だったものが、エージェントの探索を活かすために欠かせない前提になったのです。

テストを薄くすることは、実装の選択をエージェントへ委任することと表裏一体です。守るべき一線だけをテストとして残し、それ以外を委ねる。これは、動いた境界線に合わせた、知識集約構造の引き直しです。

実例2: ハーネスへの委任は、判定基準の提案まで拡大

エージェントをループで回し続けて成果物を作らせる仕組み（ハーネス）は、以前から存在します。Geoffrey Huntleyが2025年7月に公開したRalph loopは、自然言語で書いた1つの仕様書（PROMPT.md）をループでエージェントに与え続ける手法です。OpenAI Codexのgoal modeも、ゴールを与えてエージェントを自律的に走らせる公式機能です²。

注目したいのは、goal modeの公式の作法です。測定可能なターゲットやテスト基準をゴールに書くこととされています。つまり、完了を判定する基準は人間が用意して渡す設計です。境界線がこの位置にあるあいだは、判定基準の供給が人間の仕事として残ります。

境界線が先へ動くと、同じハーネスに任せられる範囲が広がります。参照となる情報（既存実装や仕様）から判定基準をエージェント自身が導けるなら、人間がすべての基準を書き上げる必要はなくなり、エージェントは判定基準そのものを提案できるようになります。人間の役割は、基準をゼロから書くことから、提案された基準を確認して承認することへ移ります。仕組みは同じまま、委任の範囲が「作業の実行」から「判定基準の提案」まで広がる。これも境界線の移動の現れの1つです。

BunのZigからRustへの移植は、境界移動の実例

境界線が実際に動いたことを示す事例として、Bunの移植があります。Bunのコアランタイムは、GitHub PR #30412（ブランチ名 claude/phase-a-port）でZigからRustへ移植されました。PRの作成は2026年5月8日、mainへのマージは5月14日で、追加行数は約100万行（1,009,257行）です。BunチームはAnthropic傘下にあり、移植にはClaude Codeが大規模に使われています。

この移植で興味深いのは、次の2点です。

• 参照実装が判定基準を兼ねた: PR本文には「アーキテクチャもデータ構造も元と同じ」とあり、リポジトリ内の移植計画書にはZig実装とRust実装の出力を突き合わせるshadow-diff検証が記されています。既存テストスイートの通過と合わせ、既存実装そのものが「正しさ」の参照として機能しました
• 境界がすべて動いたわけではない: マージ後も安定版はZigベースのv1.3.14のままで、Rust版はcanaryでのみ提供されています。どの差異を許容して安定版に載せるかの判断は、人間の側に残っています

100万行規模の移植をエージェント側の検証ループで回せるようになった一方、最終判断の権限は人間が保持している。能力軸は大きく動き、権限軸は部分的にしか動いていない、という境界の動き方が、ここから見て取れます。

規律: どの境界を前提に引いたかを、構造自体に記録

境界線が動き続けるなら、知識集約構造は「一度正しく設計して終わり」にはできません。実務でできるのは、更新のコストを下げておくことです。具体的には2つの規律に集約されます。

前提としたモデル能力を、ルールに併記

文書化すべき範囲は「エージェントが確実には持っていない知識」です。今のモデルが確実に守れる普遍的な事項（たとえば「メモリリークを起こすな」）をルールに書く必要はありません。ただし、この線引きはモデルによって変わります。書かずに済ませた前提は、モデルを差し替えた瞬間に抜け落ちます。だから、どのモデル能力を前提にその線を引いたかを、ルール自体に記録しておきます。

制約には昇格だけでなく、降格の経路も用意

同じ学びを何度も再発見しているなら、その知識はより強い層（ルールやテスト）へ昇格させる時期です。逆に、制約を置いた理由が環境の変化で消えたなら、降格・破棄します。この降格判定を可能にするのは、制約を置いたときの理由の記録です。「なぜこの制約を置いたか」を捨てて制約だけを残すと、境界が動いたあとで、その制約が古くなったかどうかを判定できなくなります。昇格の仕組みだけがあって捨てる仕組みがない構造は、古い環境の名残でいっぱいになっていきます。

この記事の主張も、次の境界移動で古くなる

最後に、この主張は自分自身にも適用されます。この記事が示した整理も、2026年7月時点の能力と権限の境界に合わせて調整された見取り図です。境界がさらに動けば、「テストを薄くする」「前提モデルを併記する」という規律の具体形も引き直しになるでしょう。変わらないのは、構造がどの境界を前提としているかを自覚し、境界の移動を検知したら構造を疑う、という姿勢の側です。

おわりに

モデルの世代交代を評価するとき、「賢くなったか」に加えて「任せられる範囲がどう変わったか」を見ることをオススメします。境界線が動いたと感じたら、テスト・ルール・ログの配分を見直すタイミングです。かつての安全策が、いまの足枷になっていないか。その点検自体を、プロジェクトの定常的な営みに組み込むことが、境界線が動き続ける時代との付き合い方だと考えます。

1. Brian Marick「How to Misuse Code Coverage」(1999)。Kent Beck『Test-Driven Development: By Example』(2002)、およびStack Overflow回答(2008)。Ian Cooper「TDD, Where Did It All Go Wrong」(NDC Oslo 2013)。DHH「Test-induced design damage」(2014)。James O. Coplien「Why Most Unit Testing is Waste」(2014)。Google Testing Blog「Change-Detector Tests Considered Harmful」(2015)。Kent C. Dodds「Write tests. Not too many. Mostly integration.」(2018)。Kent Beck「Test Desiderata」(2019)。 ↩

2. goal modeの公式ドキュメントの記述は、2026年6月21日に閲覧した時点のものです。 ↩