AIにおける「モデル」「エフォート」「ハーネス」の違い

CodexやOpenCodeのようなコーディングエージェントを使っていると、「どちらのモデルが賢いのか」「なぜ同じモデルなのに結果が違うのか」という疑問が出てきます。

この比較が難しいのは、モデルの性能とツールとしての性能が、1つのものとして語られがちだからです。実際には、少なくとも次の3つの層を分けて考える必要があります。

モデル：何を知り、どう考えるか
エフォート：どれだけ計算して答えを出すか
ハーネス：どのような手順と道具で仕事をさせるか

この記事では、この3層の役割と、同じモデルを使っても結果が変わる理由を整理します。

モデルとは何か

モデルは、入力された文章やコードをもとに、次に何を出力するかを予測するAIそのものです。

たとえば、あるモデルはコードの理解や生成が得意で、別のモデルは長い文脈の保持や複雑な推論を得意とします。学習データ、モデルの構造、調整方法などの違いによって、知識の広さ、推論の癖、コードの品質、指示への従いやすさが変わります。

コーディングエージェントにおいてモデルが担うのは、主に次のような判断です。

ユーザーの要求をどう解釈するか
既存コードが何をしているかをどう理解するか
どのファイルをどう変更するか
エラーやテスト結果から何を推測するか
最終的にどのような回答を返すか

つまり、モデルは「考える主体」です。ただし、モデルだけではローカルファイルの読み取り、コマンドの実行、変更の適用はできません。そうした作業を可能にするのが、後述するハーネスです。

エフォートとは何か

エフォート（effort、reasoning effort）は、モデルやエージェントが問題を解くときに、どの程度の計算資源や思考時間を使うかを調整する設定です。

サービスによって呼び方は異なります。ChatGPTでは「推論レベル」、Claudeでは「エフォート」、Kimiでは「思考強度」などと表記されます。本記事では、これらをまとめて「エフォート」と呼びます。

同じモデルでも、短い応答を優先する設定と、時間をかけて複数の可能性を検討する設定では結果が変わります。単純な質問なら低いエフォートでも十分です。一方、複数ファイルにまたがる変更や、原因を特定するデバッグでは、より高いエフォートが役立つこともあります。

エフォートを上げると、一般には次のような変化が期待できます。

要件や制約の読み落としが減る
実装前に複数の方針を比較しやすくなる
エラーの原因を段階的に切り分けやすくなる
変更後の影響範囲を確認しやすくなる

一方で、エフォートを上げれば必ず正解になるわけではありません。前提となる情報が不足していたり、使えるツールが限られていたりすれば、時間をかけても誤った方向に進む場合があります。また、応答時間やコストも増えます。

そのため、エフォートは「モデルの賢さを別のモデルに変える設定」ではありません。「同じモデルにどれだけ考えさせるかを調整する設定」です。このように捉えると理解しやすいです。

ハーネスとは何か

ハーネス（harness）は、モデルを実際の仕事につなぐための実行環境や制御ロジックです。コーディングエージェントの場合、モデルにどのツールを、どのような形式で、どのタイミングに使わせるかを決める仕組みを指します。

「ハーネス」は製品間で厳密な定義が統一された用語ではありません。この記事では、ツール、コンテキスト、実行ループ、権限制御、検証手順など、モデルをエージェントとして動かす周辺の仕組みをまとめて指します。

ハーネスには、たとえば次のような役割があります。

ファイルの一覧や内容をモデルに渡す
検索、編集、コマンド実行などのツールを提供する
ツールの結果をモデルに返す
実行の前後にルールや安全制約を適用する
変更内容を確認し、テストやビルドを実行する
会話の履歴や作業状態を管理する

人間にたとえるなら、モデルが「考える人」だとすると、ハーネスはその人に机や資料などを用意する助手・作業環境に相当します。どれだけ能力の高い人でも、必要な資料を渡されなければ成果は安定しません。道具を使えず、作業手順も曖昧な場合も同様です。

CodexやOpenCodeのようなツールは、単にモデルへ文字列を送るだけのものではありません。どのファイルを先に読むか、編集をどのように適用するか、コマンドの結果をどう解釈させるかといった、エージェントとしての作業の流れまで含んでいます。この部分がハーネスです。

同じモデルでも結果が変わる理由

同じモデルを利用していても、実際の結果が異なるのは珍しくありません。理由は、モデルの外側にある条件が異なるためです。

1. 与えられる文脈が違う

あるハーネスは、関連するファイルや設定を自動的に読み込んでからモデルへ渡します。別のハーネスでは、モデル自身が必要なファイルを検索する設計もあります。

前者は最初から十分な情報を持って始められますが、後者では探索の仕方そのものが結果に影響します。反対に、自動的に渡される情報が多すぎると、重要な情報が埋もれることもあります。

2. ツールの使い方が違う

同じ「ファイルを編集する」という機能でも、全文を書き換えるのか、差分を適用するのか、編集前に確認を求めるのかによって安全性や精度は変わります。

また、検索、テスト、ビルド、Git操作など、利用できるツールはハーネスごとに異なります。呼び出し方にも違いがあります。モデルの能力だけではなく、「何ができる状態で考えているか」が成果を左右します。

3. 制御ルールが違う

プロジェクト固有の指示、ツールの利用ルール、変更前後の確認手順などが、システムプロンプトや設定ファイルとして追加される場合があります。

同じモデルでも、より具体的な作業ルールと検証手順が与えられていれば、不要な変更を避け、結果を確認しながら進めやすくなります。

4. エフォートや実行回数が違う

同じモデルとハーネスでも、エフォート、コンテキストの上限、ツールを呼び出せる回数、失敗時のリトライ方法が違えば結果は変わります。

そのため、ツールAとツールBの結果を比べるときは、「モデル名が同じか」だけでなく、エフォートとハーネスの条件もそろえる必要があります。

APIを直接使う場合との違い

APIを直接呼び出す場合、基本的には自分でモデルへの入力を組み立て、必要ならツール呼び出しのループも実装します。この方法は自由度が高い一方で、次のような仕事を自分で設計しなければなりません。

どの情報をコンテキストに含めるか
どのツールを定義するか
ツールの結果をどのように返すか
いつ処理を終了するか
失敗時にどう復旧するか
変更をどのように検証するか

つまり、APIを直接使う場合にも、実質的には自分でハーネスを作ることになります。

一方、CodexやOpenCodeのようなコーディングエージェントは、ファイル操作、検索、コマンド実行、作業ルール、検証といった一連の流れを、すぐ使える形にまとめています。モデルを選ぶだけではなく、「開発作業をどう進めるか」という設計も含まれている点が、APIを直接使う場合との大きな違いです。

3層に分けて比較する

コーディングエージェントを比較するときは、次の順番で見ると混乱しにくくなります。

層	主に決めるもの	比較するときの観点
モデル	知識、理解力、推論力、生成品質	コード理解や問題解決の能力はどうか
エフォート	思考にかける計算量や時間	どの程度の深さで考えさせているか
ハーネス	ツール、文脈、手順、安全性	作業をどのように実行・検証させるか

たとえば、実装の品質が低かった場合に、すぐ「モデルが弱い」と結論づけるのは早計です。

原因として、必要なファイルの欠落、編集ツールの不適切な使い方、低すぎるエフォート、モデル自体の能力不足が考えられます。

3層に分解すれば、どこを改善すべきかを切り分けられます。

結論

AIを使った開発環境は、モデルだけを見ても全体像をつかめません。モデル・エフォート・ハーネスは、それぞれ別の役割を持ちます。

要点を一言でまとめると、次のとおりです。

モデル＝誰に任せるか、エフォート＝どれだけ計算させるか、ハーネス＝どう仕事をさせるか。

CodexやOpenCodeを比較するときも、モデル名だけで優劣を決めるのではなく、同じ条件でエフォートとハーネスを確認することが重要です。最終的な使い勝手や成果物の品質は、3つの層が組み合わさって決まります。