Coding AIはモデルよりAgentの方が重要なのか？

Coding AIを比べていると、少し逆張りっぽい言い方が出てきます。

「ModelよりHarnessの方が重要」

確かに、Model名だけ見てCoding toolを選ぶのは単純化しすぎです。

ただし、その反動でHarnessを新しい絶対王者にすると、問題はあまり改善しません。

FineInTheoryの結論はもっと面倒です。

結果はModelとHarnessだけではなく、Context、Environment、Reviewまで含めたInteractionで変わる。

それを忘れないために、この記事では次の式を使います。

Result = Model × Harness × Context × Environment × Review

これは数学ではありません。

Benchmark equationでもありません。

「5項目とも見ろ」というEditorial modelです。

Model — 頭脳は当然重要

Modelが違えば、推論、コード生成、長いTaskの扱い、誤り方などが変わる可能性があります。

Model性能を無視する必要はありません。

むしろCodingではかなり重要です。

ただし、Modelは自分でRepoを開いてShellを叩いているわけではありません。

Modelが何を見て、何を触れて、どこまで実行できるかは、その周囲の仕組みに依存します。

Harness — 頭脳に仕事をさせる仕組み

Harnessは、Modelの周りで、

• どのFileを読むか
• どのToolを使うか
• どこまで編集するか
• Shellを実行するか
• Testを走らせるか
• BrowserやMCPを使うか
• Permissionをどう扱うか
• 何回考え直すか

を管理します。

Cursorの現在のDocumentationでは、AgentをInstructions、Tools、Modelの組み合わせとして説明しています。

この分解はかなり分かりやすい。

同じModelを選んでも、使えるToolやInstructionが違えば、実際のCoding workflowは同じにはなりません。

Context — 何を知っているか

Coding Agentに必要なのは「賢さ」だけではありません。

正しい情報を見せることです。

例えば、

• Repo全体
• 関連File
• AGENTS.md / Rules
• Issue内容
• 過去の変更
• Architecture note
• Test failure

がContextになります。

強いModelでも、古い仕様だけ渡されれば古い仕様に従えます。

非常に忠実です。

それが困ることがあります。

Environment — 何を実際に試せるか

同じコード生成でも、Agentが、

• Shellを使える
• Dependencyをinstallできる
• Testを実行できる
• BrowserでUIを確認できる
• Networkへ出られる
• Sandbox内だけ動ける

のでは結果が変わります。

ここで重要なのは、自律性が高いほど良いわけではないことです。

Production credentialへ無制限に触れるAgentは、能力というよりIncidentの予約になる可能性があります。

EnvironmentはCapabilityとControlの両方を見る必要があります。

Review — 最後に誰が責任を持つか

Agentがコードを書いてTestも通した。

それで終わるとは限りません。

見るべきものには、

• Diff
• Test coverage
• Regression
• Security
• Requirement fit
• Rollback
• Production impact

があります。

Review surfaceが弱いと、Agentの速度がそのまま確認作業の負債になることがあります。

逆に、変更理由、Diff、Test結果が追いやすければ、同じ生成能力でも実務で使いやすくなる。

同じModelでもToolによって違って見える理由

ここまでをまとめると簡単です。

同じModelでも、

Native Agent

専用のInstruction、Tool、Cloud/CLI environment、permission modelがある。

AI IDE

Editor context、現在File、terminal、diff、developerの操作が近い。

Open/BYOK Harness

Model/providerを変えられる一方、設定やAPI key、tool構成を自分で持つ。

Custom API Agent

Context selection、tool、permission、review workflowまで自分で設計できる。

違うのはModelだけではありません。

Modelに与えた仕事場が違う。

ではHarnessの方がModelより重要？

ここでYesと言うと、また一つ雑なランキングが完成します。

Taskによって違います。

例えば難しいReasoningが必要ならModel差が大きいかもしれない。

一方、単純な変更でもRepo contextが悪ければ失敗しやすい。

Browser validationが必須ならEnvironmentが重要になる。

High-riskなProduction変更ならReviewとPermissionが重要になる。

だから「何が一番重要か」ではなく、

そのTaskでどの要素がbottleneckかを見る方が使えます。

選ぶときの順番

1. Purpose — 何を完成させたいか
2. Surface — どこで作業するか
3. Delegation — どこまで任せるか
4. Context — 何を見せる必要があるか
5. Environment — 何を実行できる必要があるか
6. Control / Review — 何を人間が確認するか
7. Model — その条件でどのModelを使うか

Modelを最後まで無視するのではありません。

Modelだけを最初から全体の代理変数にしないという話です。

Level Bで本当に調べるなら

将来需要が確認されたら、実機比較は2方向でやる必要があります。

Same Model / Different Harness

同一Modelを、異なるHarness/Surfaceで使う。

これでHarness、Context、Environment差を見る。

Same Harness / Different Model

同じHarness/設定でModelだけ変える。

これでModel差を見る。

片方だけやると、ModelとHarnessを分離したつもりで混ぜる可能性があります。

Phase 0ではここまで実測しません。

結論

Modelは頭脳です。

Harnessは、その頭脳に何を見せ、何を触らせ、どこまで実行させるかを決めます。

Contextは材料。 Environmentは仕事場。 Reviewは最後の責任境界です。

どれか一つを「最重要」に固定するより、Taskごとのbottleneckを見る。

Coding toolを選ぶとき、Model名だけを見るのをやめる。

それがこの記事の目的です。

The model is the brain. The harness decides what the brain is allowed to see, touch, break and apologize for.

What would change our mind?

• Agent間でContext / Environmentがほぼ標準化する
• Harness差が極端に小さくなる
• Model capability差が他要因を圧倒する
• Review/permissionが共通規格化する
• 実測で特定要素が多くのTaskで一貫して支配的と示される