📑 技術調査 - AIコーディングの委任契約とレビュー可能性

調査対象: 論文 Software Delegation Contracts: Measuring Reviewability in AI Coding-Agent Work (arXiv 2606.17099, Vincent Schmalbach, 2026-06-14)
本記事は論文・方法論の技術調査です。C4 は委任契約フレームワークの論理構造に読み替えています。本文中「実装案」と付記したコードは論文の主張ではなく、公式ドキュメントを参照した実装提案です。

■概要

論文の目的と位置づけ

AIコーディングエージェントは、タスクを受け取りリポジトリを変更してパッチを返すところまで自走できるようになりました。しかし人間のレビュアーが直面する問題は「動くか」から「レビューできるか」へ移行しつつあります。本論文は、この レビュー可能性 (reviewability) を構造的に高める手段として「委任契約 (Delegation Contract)」を定義し、その効果を対照実験で測定しました。

"Contracts buy reviewability, not correctness, on tasks like these."
— Schmalbach 2026, 中核的発見

論文の主張を一文で言えば、委任契約は正しさを買うのではなくレビュー可能性を買う、です。AIエージェントの客観的な成果品質 (テスト合否・スコープ違反) は契約の有無によらず飽和しますが、エビデンスの充実度と曖昧さ低減は契約によって大きく改善されました。

解決しようとする問題

現行の「issue風プロンプト → PR」フローでは、エージェントが何を変更したか・なぜ変更したか・何をテストしたか・残留リスクは何かが返却物に含まれません。レビュアーは成果物を見て自力で文脈を再構成する必要があり、レビュー詰まり (review bottleneck) が生じます。委任契約はこの問題を「最初から何を返却させるかを契約として明示する」ことで解決します。

想定読者

• LLMOps / AI開発基盤チーム: エージェント実行の出力仕様設計
• 開発リード / エンジニアリングマネージャー: AIエージェントへの委任ポリシー設計
• レビュー設計者 / DevEx担当: レビュープロセスのスケール設計

関連概念との関係

■特徴

• 委任契約の形式定義: 委任契約を 4-tuple ⟨T, A, W, C⟩ (Task / Authority / Work package / Acceptance context) として定式化し、明示的な契約として実験で操作しました。暗黙的だった委任の要素を構造化した点が本研究の起点です。
• Evidence Bundle テンプレートの提案: Summary / Changed files / Commands run / Tests and results / Known limitations / Residual risks / Reviewer checklist の 7 固定セクションからなる返却物テンプレートを定義しました。
• 64 runs / 192 reviews の対照実験: A/B 条件を 10 タスク × 2 モデルティア (Sonnet 4.6 / Haiku 4.5) で実施し (40 runs)、さらに Sonnet の replicate (10 タスク × A/B = 20 runs) と C 条件の 4-run preview を加えて計 64 runs としました。条件ブラインドな 3 独立モデルレビュアーによる固定ルーブリック評価 (median-of-three) で再現性を担保しました。
• Reviewability と Correctness の解離発見: 全 64 runs で客観成果 (hidden test pass / スコープ違反ゼロ) が飽和する一方、エビデンス充実度は条件間で大幅に差異が出ました。本実験条件 (小規模・十分仕様化されたタスク) では、客観成果が天井に達する一方で reviewability 指標だけが改善し、少なくとも小タスクでは両者が乖離しうることを示しました。
• モデルティア効果の逆説: より能力の低い Haiku の方が契約による恩恵が大きい結果でした (evidence +1.00 vs Sonnet +0.75, ambiguity −0.50 vs −0.10)。契約はモデル能力の弱さを構造で補う可能性を示しました。
• コストの定量計測: tokens / wall-clock time / tool invocations / patch size の 4 指標でコスト増加を計測しました。

条件 A / B / C の比較

条件 C は 4-run preview のためサンプル規模が小さく、B との差異は参考値です。
残留リスク・レビュアーチェックリストは条件 B (契約) でも自発記載は 0% で、必須テンプレート (条件 C) で初めて 100% になります。

■構造

委任契約フレームワークの論理構造を C4 model の 3 段階で示します。論文は具体システムを持たないため、C4 を「委任契約の運用パイプライン」の論理構造に読み替えています。

●システムコンテキスト図

委任契約システムと外部アクター・外部システムの関係を示します。

●コンテナ図

委任契約フローを構成する主要要素を示します。

●コンポーネント図

各コンテナの内部構成要素を示します。

Contract Spec の内部構成

Evidence Bundle の内部構成

Review Process の内部構成

実装例: Claude Code + GitHub テンプレート

上図は論文の方法論を Claude Code + GitHub で実装する一例です。論文自体は特定のツール構成を規定していません。

■データ

論文に登場する主要エンティティの概念モデルと情報モデルを示します。

●概念モデル

委任契約 ⟨T,A,W,C⟩ を中心に、実験設計を支えるエンティティ群を示します。

●情報モデル

各エンティティの主要属性を示します。属性が論文に明示されていない場合は「推測」と注記します。

主要エンティティの属性補足

ルーブリック 6 次元

エンティティ多重度まとめ

■構築方法

本セクションは論文の方法論を現場で実装する具体例を補完します。「実装案」と付記したものは論文の主張ではなく、公式ドキュメントを参照した実装提案です。

委任契約テンプレートの定義

論文は ⟨T, A, W, C⟩ の 4-tuple を構造化プロンプトとして渡す方式を採用しています。Markdown と YAML の両形式で表現できます。

Markdown 形式 (実装案: .claude/templates/delegation-contract.md)

# 委任契約: {タスク名}

## Task (T)
- Objective: {達成目標を1文で}
- Scope: {変更してよいファイル・モジュールの範囲}
- Non-goals: {今回は対象外とすること}
- Success criteria: {完了の判断基準。テスト合格・型チェック通過など}

## Authority (A)
- Allowed paths: {変更可能なパス。例: src/api/**, tests/**}
- Allowed commands: {実行可能なコマンド。例: npm run test, npm run build}
- Forbidden actions: {禁止事項。例: 依存変更, node_modules 書き換え, git commit}

## Expected Work Package (W)
以下の 7 セクションを含む Evidence Bundle を返してください:
1. Summary
2. Changed files (変更理由付き)
3. Commands run
4. Tests and results
5. Known limitations
6. Residual risks
7. Reviewer checklist

## Acceptance Context (C)
- Reviewer: {担当者 / チーム名}
- Review rubric: scope_compliance / evidence_sufficiency / reviewer_confidence / ambiguity / repair_required / acceptance_decision

YAML 形式 (実装案: .claude/templates/delegation-contract.yaml)

contract:
  task:
    objective: ""
    scope: []
    non_goals: []
    success_criteria: []
  authority:
    allowed_paths: []
    allowed_commands: []
    forbidden_actions:
      - "modify package.json"
      - "modify node_modules"
      - "git commit"
      - "git push"
  work_package:
    required_sections:
      - summary
      - changed_files_with_reasons
      - commands_run
      - tests_and_results
      - known_limitations
      - residual_risks
      - reviewer_checklist
  acceptance_context:
    reviewers: []
    rubric: scope_compliance,evidence_sufficiency,reviewer_confidence,ambiguity,repair_required,acceptance_decision

Evidence Bundle テンプレートの雛形

論文実験 (Condition C) で用いた Evidence Bundle の 7 セクション構成です。PR 本文またはエージェント出力の定型フォーマットとして使用します。

実装案: .github/PULL_REQUEST_TEMPLATE.md

## Summary
<!-- 何を・なぜ変更したかを2〜3文で -->

## Changed files
| ファイル | 変更内容 | 変更理由 |
|---|---|---|
|  |  |  |

## Commands run
<!-- 実行したコマンドを順番に列挙 -->

## Tests and results
<!-- テスト実行結果を貼り付け -->

## Known limitations
<!-- 今回の実装で対応できなかった既知の制約 -->

## Residual risks
<!-- レビュアーが注意すべき残存リスク -->

## Reviewer checklist
- [ ] scope compliance: 許可されたファイルのみ変更されているか
- [ ] evidence sufficiency: 変更理由・テスト結果が十分か
- [ ] known limitations が正直に記載されているか
- [ ] residual risks を理解して accept するか

論文知見: residual_risks と reviewer_checklist は「要求したときだけ出現する (demand-driven)」セクションです。契約構造を渡すだけの条件 B でも自発出現率は 0% のままで、必須テンプレートを課す条件 C で初めて 100% になりました。テンプレートに必須フィールドとして固定することが出現の条件です。

Authority を Claude Code と GitHub で実装する

Claude Code settings.json (実装案)

.claude/settings.json に permissions を定義することで、エージェントが触れるツール・コマンド・ファイルを制限できます。

{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Edit(src/**)",
      "Edit(tests/**)",
      "Bash(npm run test)",
      "Bash(npm run build)",
      "Bash(npm run lint)",
      "Bash(git diff:*)",
      "Bash(git status)"
    ],
    "deny": [
      "Edit(package.json)",
      "Edit(package-lock.json)",
      "Edit(.env)",
      "Bash(git commit:*)",
      "Bash(git push:*)",
      "Bash(npm install:*)"
    ]
  }
}

実装注: permissions は deny → ask → allow の順で評価され、最初にマッチしたルールが適用されます。deny にマッチした呼び出しは、より広い allow があってもブロックされます (allow による例外指定はできません)。禁止アクションは deny に列挙して確実に止めます (参考: Claude Code Permissions ドキュメント)。

CLAUDE.md による自然言語制約 (実装案)

## Authority (このセッションの権限範囲)

### 変更可能なファイル
- src/ 以下のすべての TypeScript ファイル
- tests/ 以下のすべてのテストファイル

### 実行可能なコマンド
- npm run test / npm run build / npm run lint

### 禁止アクション
- package.json / package-lock.json の変更
- node_modules/ への書き込み
- git commit / git push の実行

実装注: CLAUDE.md はモデルの行動を指示しますが、権限境界は settings.json の permissions が Claude Code のツール使用レベルで強制します。双方を組み合わせることで「意図 (CLAUDE.md) + 強制 (settings.json)」の二重防護になります。なお Bash の子プロセスが間接的に行う読み書きまで OS レベルで閉じるには、permissions に加えて sandbox の併用が必要です。

GitHub CODEOWNERS (実装案)

委任契約の「Acceptance Context (C)」に対応するレビュアー指定を自動化します。CODEOWNERS のパターン記法は .gitignore に似ていますが、最後にマッチしたルールが優先されます。ただし ! による否定や文字範囲など一部の gitignore 構文は使えません。

# .github/CODEOWNERS
*                   @org/senior-engineers
src/api/**          @org/senior-engineers @org/security-team
tests/**            @org/qa-team
package.json        @org/team-leads

■利用方法

Issue / タスクを委任契約に変換する手順

エージェントへの委任契約の渡し方

委任契約はプロンプトの冒頭に構造化ブロックとして渡します。

実装案: プロンプト構造例

以下の委任契約に従ってタスクを実行してください。

## Task (T)
- Objective: バリデーション関数 validateEmail の入力境界バグを修正する
- Scope: src/validators/email.ts, tests/validators/email.test.ts
- Non-goals: メールフォーマット仕様の拡張、他のバリデーション関数への変更
- Success criteria: npm run test が全テストパス、型エラーゼロ

## Authority (A)
- Allowed paths: src/validators/email.ts, tests/validators/email.test.ts
- Allowed commands: npm run test, npm run build, npm run lint
- Forbidden actions: package.json 変更, git commit, git push

## Expected Work Package (W)
以下の 7 セクションを含む Evidence Bundle を返してください:
1. Summary
2. Changed files (変更ファイル名と変更理由)
3. Commands run (実行したコマンドと出力)
4. Tests and results (テスト結果の全文)
5. Known limitations (今回対応できなかった制約)
6. Residual risks (レビュアーが注意すべきリスク)
7. Reviewer checklist (レビュアーが確認すべき項目)

では開始してください。

論文知見: Baseline (Issue 風プロンプト) と比較して、Contract 条件では「変更理由付きファイル一覧」が 7% → 93%、「実行コマンド記録」が 7% → 70% に向上しました。明示的な構造が Evidence Bundle の充実に直結します。

返却された Work Package のレビュー手順

エージェントが返却した Work Package を、論文実験と同じ 6 次元ルーブリックで採点します。

実装案: レビュールーブリック

| 次元 | スケール | 評価 | コメント |
|---|---|---|---|
| scope_compliance | 1〜5 (5=完全準拠) | | 許可されたファイルのみ変更したか |
| evidence_sufficiency | 1〜5 (5=十分) | | 変更理由・テスト結果が読んで判断できるか |
| reviewer_confidence | 1〜5 (5=高い) | | accept に自信を持てるか |
| ambiguity | 1〜5 (1=低=良い) | | 不明点・曖昧な記述が少ないか |
| repair_required | 0/1 (0=不要) | | 追加修正が必要か |
| acceptance_decision | 0〜3 (3=即 merge) | | 0=reject / 3=accept |

採点後のアクション判断:

• acceptance_decision = 3 かつ repair_required = 0 → merge
• ambiguity が高い → Known limitations / Residual risks を確認し、判断不能な箇所を差し戻す
• scope_compliance が 4 以下 → Changed files で許可外パスへの変更がないか確認する
• evidence_sufficiency が 3 以下 → Commands run / Tests and results の詳細を要求して再提出を依頼する

論文知見: Baseline の evidence_sufficiency 平均 3.90 が Contract で 4.73 (+0.83, p<0.0001) に向上しました。accept rate は 0.86 → 0.93 と動きましたが p=0.12 で統計的有意ではなく、acceptance decision も 2.93 → 2.97 (p=0.56) とほぼ変化しません。改善したのはレビュー可能性であって受け入れ判定そのものではありません。

■運用

委任契約をいつ使うか / 使わないか

論文の中核的警告は「小タスクでは正しさは天井に達する」です。全 64 runs が隠しテストをすべてパスし、スコープ違反はゼロでした。契約が改善したのは reviewability であって correctness ではありません。

• 使う価値が高いケース: リスキーな変更 (破壊的 API 変更・認証周りの修正)、大型機能追加、複数ファイルにまたがるリファクタリング。これらは正しさの天井が低く、エビデンスによるレビュー支援の効果が出やすいと推定されます (論文は未検証・著者の open question)。
• コスト過剰になりやすいケース: 1〜2 ファイル修正・typo fix など、レビュー証跡がそもそも不要な軽微な作業。正しさは天井に達しており、証跡が要らないなら +38% の wall-clock time が見合いません。なおドキュメント更新は evidence 改善が大きい側なので、レビュー証跡を残したい場合は契約の効果が出ます。

# 判断フロー (実装補完)
if task_risk == "low" and file_count <= 2:
    use_contract = False   # issue 風プロンプトで十分
else:
    use_contract = True    # 委任契約 + Evidence Bundle を使う

タスクファミリ別の傾向 (論文データ)

リファクタリングでは「共有ヘルパーがページネーションオフセットも計算すべきか」といったインターフェース設計の判断がレビュアーに浮かび上がり、契約の基準が逆に精査 (scrutiny) を高める場合があります。

コスト管理

パッチサイズの増加は本番コードの増加ではなく追加テストの増加が主因です。

• 許容できる: レビュアーの人件費が節約できるなら、+38% の実行時間増は割に合う可能性があります。ただし論文はレビュー時間を実測しておらず、トータルコストは未知です。
• 許容しにくい: CI/CD の並列ジョブ数が少ない環境や API コストが支配的なバッチ処理では、+13% tokens × タスク数のコスト増が積み上がります。
• 目安: 1 タスクあたり約 +13% tokens・+38% latency を予算に見込みます。

レビュー結果の蓄積

# Evidence Bundle 評価記録のサンプル (実装補完)
task_id: T07
model: haiku-4.5
condition: contract
rubric:
  scope_compliance: 4
  evidence_sufficiency: 4
  reviewer_confidence: 5
  ambiguity: 1
  repair_required: false
  acceptance_decision: 3
notes: "shared helper の設計判断でレビュアーが迷った"

スコアを蓄積することで、タスクファミリ・モデルティア別の「契約の効きやすさ」パターンが見えてきます。evidence_sufficiency が継続して低い場合は、Work package テンプレートの required セクションを見直すシグナルです。

■ベストプラクティス

evidence sufficiency を上げる返却物設計

論文が明示した「即効性の高い必須化」の優先順位です。

1. 最優先: changed files with reasons と tests run の必須化。コストが低く、ほぼ普遍的に compliance し、evidence gains が最大です (changed files は 7%→93%、commands run は 7%→70%)。
2. リスク閾値以上で必須: known limitations と residual risks。これらは要求しなければ出現しません (known limitations 0%→80%、residual risks は条件 C で初めて 0%→100%)。trivial risk を超えるタスクで条件必須化する運用が有効と考えられますが、大型・リスキータスクは論文では future work であり、初期導入では A/B 実測を推奨します。
3. オプション: reviewer checklist はレビュアー誘導に効果的ですが、記入粒度が一定しないため明示的なフォーマット指定が必要です。

モデルティア別の使い分け

• Haiku (弱いモデル): 契約の効果が最大 (evidence +1.00, ambiguity −0.50)。自発的に良いレポートを書かないため、契約が代替します。コスト削減目的で弱いモデルを使う場合、契約を強く検討する根拠になります。
• Sonnet (強いモデル): 効果は存在しますが相対的に小さい (evidence +0.75, ambiguity −0.10)。強いモデルは契約なしでもある程度のレポートを書きます。

実装上の示唆 (論文の推論から補完): 高リスクタスクは Sonnet + 契約、レビュー証跡が要る低リスク定型作業は Haiku + 軽量契約、証跡不要な試作・探索は Haiku + 契約なし (コスト優先)。契約の価値はモデルが弱いほど高いという観点から、安価なモデルへの委任こそ契約コストを正当化しやすいと言えます。

注意: Haiku と Sonnet の差分 (evidence +1.00 vs +0.75 等) は記述統計であり、モデルティア間差異の統計的有意性は論文では明示されていません。サンプルは Haiku・Sonnet 各 10 タスクと小さいため、傾向として扱ってください。

「正しさ」は契約では上がらない前提でのテスト設計

論文の核心的な dissociation は Contracts buy reviewability, not correctness です。

• 正しさの担保は別途設計が必要です。hidden acceptance tests・型チェック・linting・CI ゲートを、契約とは独立して整備してください。
• 受け入れ基準 (C) は「レビュアーが何を見るか」を定義しますが、「テストが通っているか」は C の外で機械的に確認する構造が堅牢です。

LLM レビュアー前提の外挿注意

論文の限界として、全 192 reviews が LLM レビュアーによるものです。人間レビューでの再現は未検証です。

• rubric スコアの改善が人間の工数削減に直結するかは不明です。
• 「LLM レビュアーが confident になった」=「人間レビュアーも楽になった」という等号は成立しません。
• 運用では初期段階で人間レビュアーによる A/B 比較を試み、実際の時間節約を実測することを推奨します。

過剰納品 (over-delivery) へのフレーミング

実験中、一部タスクで契約の基準を超えた成果物を agent が提出し、レビュアーが scope compliance を低く評価する事例が見られました。これは correctness の問題ではなく framing の問題です。Work package の non-goals で「最小限の要件を超えることを歓迎するか」を明示することで対処できます。

妥当性への脅威 (Threats to Validity)

論文が明示する妥当性の脅威を、運用で過信しないための注意点として整理します。本研究の結論はこれらの条件下で成立するもので、外挿には注意が必要です。

■トラブルシューティング

■まとめ

委任契約 ⟨T,A,W,C⟩ は、AIコーディングエージェントの成果物に「変更理由・テスト結果・既知の制約・残留リスク」をエビデンスとして添えさせる仕組みです。論文の対照実験では、契約は正しさ (テスト合否・スコープ違反) を改善しませんでしたが、レビュー可能性 (evidence sufficiency +0.83, ambiguity −0.23) を有意に高めました。小タスクでは正しさが天井に達するため、契約の価値はレビュー工数の削減にあり、コスト (+13% tokens / +38% time) と引き換えに「レビューしやすさ」を買う設計だと整理できます。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

■参考リンク

一次論文 (本フレームワーク)

• arXiv 2606.17099 (abstract): Software Delegation Contracts
• arXiv 2606.17099 (HTML 全文)

関連ツール公式 (実装補完の出典)

• Configure permissions - Claude Code Docs — settings.json permissions 記法
• About issue and pull request templates - GitHub Docs — PR / Issue テンプレの配置と書式
• About code owners - GitHub Docs — CODEOWNERS 記法と優先順位ルール

関連分野 (系譜)

• SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — エージェントのタスク解決率 (pass/fail) 評価のベンチマーク。本論文が「解決率を一定にした上で別軸を測る」と位置づける対比対象
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023) — 本論文のレビュアー (モデルによる採点) 方法論の系譜にあたる LLM-as-judge 研究
• Principal-Agent / Agency Theory (Jensen & Meckling, 1976) — 委任における情報非対称とインセンティブ設計の古典。論文が「契約」をエビデンス開示の政策手段と位置づける際の理論的背景