AIの出力がいまいちなとき、モデルを替える前に見る7か所 — 「ハーネス」という考え方

AIに頼んだ仕事の出来がいまいちだったとき、まず何を疑うでしょうか。
おそらく、モデルです。
もっと賢いモデルに切り替えれば、この雑な出力もマシになるのではないか。
上位プランに上げれば解決するのではないか。

私も同じ順番で考えてきました。

ただ、2026年前半に出てきた実測は少し違う話をしています。
LangChain という開発ツールの会社が、使うモデルを一切変えずに周辺の作り込みだけを組み直したところ、共通テストの正答率が52.8%から66.5%へ上がりました。
同じモデルのまま、13.7ポイントの差。

モデルを替える前に、見ておく場所がある。
その場所の総称として業界で定着した呼び名が「ハーネス」です。

この記事は2部構成にします。
前半は難しい話を抜きにして、モデル以外に何を整えればいいかだけを書きます。
コマンドは出てきません。
後半は、言葉の出どころ、実践している人たちが実際に組んでいるもの、そして「作り込むだけ無駄」という反対意見を扱います。
前半だけ読んで閉じてもらって構いません。

モデルは頭の良さ、ハーネスは職場環境

ハーネスとは、AIが仕事をするとき、その周りに用意されている環境の一式を指します。
どんな道具を使えるか、どこまで勝手に進めていいか、終わったあと何で確認するか、前回までの経緯をどこから読むか。
モデル本体ではなく、モデルを取り囲んでいる側の話です。

もともとは馬具の言葉です。
馬の力を荷車や農具へ伝えるための引き具を harness と呼びます。
AIの力を実作業へ伝えるための装具、という含意でそのまま使われています。

一度だけ例えを使います。
モデルは人の頭の良さにあたり、ハーネスは職場環境にあたります。
資料の置き場が誰にも分からず、成果物を誰も確認せず、申し送りが口頭しか残らない職場を想像してみてください。
どれだけ優秀な人を放り込んでも、出てくる仕事は雑になります。
手順と確認の仕組みが整った職場に同じ人を置けば、まともな成果が出ます。

AIに対して私たちがやっているのは、たいてい前者に近い扱いです。
毎回ゼロから説明し、出てきたものをそのまま受け取り、ミスをされたら文句を言って会話を閉じる。
モデルを上げる前に、この環境のほうに手を入れる余地がかなり残っています。

整えどころは7か所に収束している

公開されている実践を突き合わせると、書いてあることは7点にほぼ収束します（本記事の整理）。
中でも全員に共通しているのは、最初の3つです。
専門用語のまま並べても使えないので、普段の頼み方に翻訳します。

1. 検証ループを持たせる。「終わったら実際に動かして、結果を見せてください」を頼み方の中に入れておく。文章の作業なら「指定した条件を全部満たしているか、最後に照合して結果を見せて」と頼む形です

2. ルールは失敗から逆算する。ミスをされたら怒って終わりにせず、1行のルールにしてファイルへ足す。増えすぎたら消す。目安は指示ファイル全体で60行前後

3. 会話の長さを意図的に管理する。同じ説明を2回したら、または話が噛み合わなくなってきたら、要点をファイルへ書き出させて新しい会話を始める

4. 決めごとは会話でなくファイルに置く。「さっき決めましたよね」が通じる相手ではない

5. 道具は少なく始める。便利そうな拡張を入れる前に、標準の機能で足りるかを先に試す

6. 作った本人に採点させない。点検は別の会話で確認させる

7. 人間が見る場所を手前へ動かす。出来上がりを直すより、作業前の計画を読むほうが効く

何度も出てくる「ファイル」について補足します。
ここでいうファイルは、Claude Code なら CLAUDE.md、Codex なら AGENTS.md という名前のファイルにあたります。
ブラウザの ChatGPT だけで使っている場合は、カスタム指示やプロジェクトの説明欄が同じ役割です。
AIが毎回最初に読む場所、と考えてください。
そういう置き場がないアプリを使っているなら、手元のメモに書いておいて会話の最初に貼るだけでも同じ効果があります。

7番目が分かりにくいかもしれません。
計画の1行の誤りは、そのあと数百行分の誤りに膨らみます。
完成品を見て直す作業より、着手前の段取りを3分読むほうが安く済む、という意味です。

6番目には理由があります。
Anthropic の技術記事に、モデルは自分が作ったものの品質を必ず過大評価する、という表現が出てきます。
「できました」という自己申告を成果の判定に使うと、その時点で検証が成立しなくなります。

自分のハーネス点検リスト

7つを、そのまま質問に直しました。
自分の普段の使い方を思い浮かべて、Yes か No で答えてみてください。

1. AIが「できました」と言ったとき、実際の結果を見て確かめていますか

2. 同じミスをされたとき、ルールとして書き残していますか

3. 会話が長くなったとき、要点をファイルに残してから切り替えていますか

4. 決めたことを、会話の中ではなくファイルに書かせていますか

5. 拡張や連携を増やす前に、標準の機能で足りるかを試していますか（まだ何も入れていないなら、それが正解です。Yes 扱いで構いません）

6. できたものの点検を、作った本人以外にやらせていますか

7. 作業を始める前に、やることの計画を見せてもらっていますか

No が5つ6つ付いた人もいると思います。
全部を埋めにいかないでください。
No のうち、直近1週間で実際に困った項目を1つだけ選ぶ。
失敗が起点のルールは、要らなくなったときに消しやすいからです。
先回りして組んだルールほど、あとから消す判断ができなくなります。

点検はAIに頼めばいい

自分で振り返るのが面倒なら、点検ごと任せられます。
読んでいる人はほぼ全員、手元にAIを持っているはずです。

チャット欄に、次の文をそのまま貼ってみてください。

私がAIに仕事を頼むときの使い方を点検してほしいです。
次の7項目について、私が普段どうしているかを1問ずつ質問してください。
まとめて聞かず、1つ答えたら次に進んでください。

1. 終わったあと、実際の結果で確認しているか
2. 同じミスをされたとき、ルールとして書き残しているか
3. 会話が長くなったとき、要点をファイルに残しているか
4. 決めごとを会話でなくファイルに書かせているか
5. 拡張を増やす前に、標準の機能で足りるか試しているか
6. できたものの点検を、作った本人以外にやらせているか
7. 作業前に計画を見せてもらっているか

全部聞き終わったら、私に一番効きそうな改善を1つだけ提案してください。
その1つは、設定ファイルやメモのファイルへの反映までお願いします。
書き換える前に、何をどう書くのかを見せてください。

貼ると、7つの質問が順に来ます。
答え終わると、効きそうな改善が1つ返ってきます。

末尾の「書き換える前に、何をどう書くのかを見せてください」は消さないでください。
反映内容を自分の目で確認してから進める、という一手間だけは残しておくほうがいい。
点検を任せる相手も、点検される使い方の当事者です。

ファイルを扱えないチャットアプリの場合は、その一文を「反映する内容を、私が貼り付けられる文章として出してください」に置き換えてください。

効いたのは、ミスのたびに1行足す運用

自分の環境の話も1つ書いておきます。

私はAIに何かを任せる環境をいくつか動かしていて、ミスが起きるたびにルールを1行だけファイルへ足す運用を続けています。
長い規約を先に書いたのではなく、事故が起きた順に1行ずつ増えてきたものです。
例えば私のファイルには「PowerShell で UTF-8 のファイルを読み書きするときは、必ず -Encoding UTF8 を明示する」という1行があります。
文字化けで手痛い思いを一度してから足したルールで、それ以来この型の事故は起きていません。
続けてみて、同じ型のミスの再発は減っている実感があります。

減った件数を数えたわけではないので、割合は書けません。
それでも、以前は同じ説明を何度も繰り返していた感覚が、今はほとんどありません。

前半はここまでです。
点検リストの No を1つ選んで直すところまでやれば、実用上は足ります。

ここから先は、実践者の具体と反対意見

言葉が定着したのは2026年2月

広く読まれるようになった起点としてよく挙がるのが、開発者 Mitchell Hashimoto が2026年2月5日に公開した文章です。
「エージェント = モデル + ハーネス」という形で整理し、エージェントがミスをするたびに二度と同じミスをしないよう環境側へ解決策を作り込む、という運用を書いています。
7つでいう2番目の原型にあたります。

同じ2月、OpenAI が Codex の開発方針として「ハーネスエンジニアリング」を掲げました。
原文は閲覧できなかったので、技術メディア InfoQ の報道を通じて内容を確認しています。
扱われているのは、エージェントを取り囲む環境の全体です。
コードやファイルをまとめて置いておく作業フォルダ（リポジトリ）の構造、指示書、変更のたびに自動でテストを走らせる仕組み、書き方の誤りを機械的に指摘する仕組みまで含まれます。

4月には Anthropic が、モデルを取り巻くソフトウェアの足場として4つを挙げています。
実行のループ、使える道具、会話の管理、そしてガードレール（危ない操作をその手前で止める仕組み）です。
同じ月、Birgitta Böckeler が martinfowler.com で、事前に方向を決めるもの（guides）と事後に観測するもの（sensors）という2系統で整理しました。
呼び名は違っても、指しているものはほぼ重なっています。

同じモデルでも数字は動く

冒頭の数字の条件を書いておきます。

LangChain の事例は、モデルを GPT-5.2-Codex に固定したまま、周辺のハーネスだけを作り直したものです。
Terminal-Bench 2.0 というベンチマーク（各社が同じ条件で解いて比べる共通の問題集）で、正答率が52.8%から66.5%へ動きました。
順位でいうと、上位30位圏から上位5位圏への移動にあたります。

Anthropic も似た検証を出しています。
同一モデルで、ツールの出力を絞り込む仕掛けを入れるか入れないかだけを変え、BrowseComp というベンチマークで45.3%から61.6%へ変化しました。
道具を増やす方向だけが正解でもなく、Claude 3.5 Sonnet が bash とエディタの2つだけで SWE-bench Verified 49%を取った例も同じ記事に載っています。

ただし、どちらも各社の自社発表で、モデルを上げた場合の伸びと直接比べた公開データも見当たりません。
言えるのは「モデルを変えなくてもこれだけ動く」まで、です。

実践者が実際に組んでいるもの

5人分を並べますが、先に共通点を書きます。
全員が、失敗を記録に変える経路と、自己申告に頼らない確認の経路を持っています。

Claude Code の開発を率いた Boris Cherny は、検索に専用の検索基盤を使わず、grep や glob という昔からある文字列検索の道具を使わせています。
同じ指摘を3〜4回する羽目になったら、その指摘を毎回自動でチェックされる仕組み（lint）に変える。
残りのミスは CLAUDE.md という指示ファイルへ集約しています。

Dex Horthy は、調査・計画・実装の3工程を分けます。
会話の使用量は4〜6割に保ち、超えそうなら意図的に要約する。
人間のレビューを、実装後でなく計画段階に置いています。
指示ファイルも60行以内へ抑える運用です。

Addy Osmani は、起きたミスを恒久ルールへ変える運用を「ratcheting」と呼んでいます。
各ルールは実際の失敗に紐づける、という運用です。
「成功は静かに、失敗は饒舌に」という原則も挙げています。

Anthropic の長時間タスク向けの設計では、計画役・生成役・評価役を別々に立てます。
受け渡しは会話ではなくファイル経由。
先に触れた「モデルは自作物の品質を必ず過大評価する」が、評価役を分ける根拠です。

日本語の一次事例としては、エアークローゼットの辻氏が Zenn に書いた運用があります。
一定の基準を満たさない変更を先へ通さない関門（品質ゲート）を置き、自動レビューを通ったものは自動で本体へ取り込む形です。
4ヶ月で63万行・790件の変更を通したという内容になっています。

反対意見: ハーネスはモデルに食われる

ここまで読むと作り込みたくなりますが、逆の立場も明確に存在します。

1つは Bitter Lesson 派の主張です。
AIの歴史では、人間が手で作り込んだ工夫が、より強い汎用の学習に繰り返し置き換えられてきました。
同じことがハーネスにも起きる。
今日ルールで防いでいる失敗の多くは、次のモデルでは最初から起きない。
Lee Hanchung は、だから各要素に賞味期限を設計し、いつでも削除できる形で持て、と書いています。

もう1つはコストです。
推している側の Anthropic 自身が、同じタスクの実測を並べています。
エージェント単独なら20分・9ドル（約1,400円）で済んだタスクが、フル構成では6時間・200ドル（約31,000円）かかっています。
モデルが強くなるほど、評価役を回すオーバーヘッドは正当化しにくくなります。

Horthy も、ハーネスだけでは足りないと言っています。
何を作りたいかという意図や、実装の選択、主観的な出来の良さといった部分は、環境を整えても埋まらないという指摘です。
締めすぎて動けなくする過剰拘束と、緩すぎる過小防御の両側にリスクがあります。

つまり2026年前半には、「作り込めば13.7ポイント上がる」と「6時間200ドルかけても次のモデルで不要になる」が同時に存在しています。
どちらかが嘘なのではなく、両方が本当です。

この緊張から出てくる現実解が、前半の点検リストの使い方につながります。
先回りして全部を組まない。
実際に起きた失敗を1つ拾って、1行のルールにして足す。
Osmani の「各ルールは実際の失敗に紐づける」も、Hashimoto の「ミスをするたびに環境側へ作り込む」も、順序としては同じです。
失敗が起点なら、モデルが強くなってその失敗が消えたとき、そのルールも迷わず消せます。

私の記事も、部品を1つずつ整えた記録

書いてきた記事を並べ直すと、どれもハーネスの部品の話でした。

長いセッションで判断が雑になる問題には、メインの会話を調停役に絞り、実行を別に立てたサブエージェント（本体とは別に動かす作業用のAI）へ渡す形で対応しました。
7つでいえば6番目にあたります。

会話が圧縮されたあとに認識がずれる問題には、決めごとをファイルへ書き出して読み直させる運用で対応しました。
3番目と4番目です。

auto mode の標準化を前に判定ルールの全文を読んで、どこまで自動で通すかを決めた回もありました。
ガードレールの設計そのものだった、といまなら言えます。
当時は個別の困りごとへの対処だったので、共通の名前があると知ったのは後です。

まとめ

• 出力がいまいちなとき、モデルの前に環境（ハーネス）を見直す余地がかなり残っている

• 公開されている実践を突き合わせると整えどころは7点に収束し、全員共通は実行結果での検証・失敗からのルール化・会話の長さの管理の3つ

• 同じモデルのままで52.8%→66.5%、45.3%→61.6% という実測がある（いずれも各社の自社発表で、モデル更新との直接比較ではない）

• 一方でフル構成は6時間・約31,000円という実測もあり、次のモデルで不要になる部分も出る

• だから先回りして組まず、実際に起きた失敗を1行のルールにして足す。要らなくなったら消す

次の一手は1つだけです。
点検リストの7問に答えて、No が付いた中から直近で実際に困ったものを1つ選ぶ。
そのまま1行のルールを書いて、AIが読むファイルへ足してください。
手が止まるようなら、上のプロンプトを貼って聞き取りから任せてしまえば済みます。

この記事が参考になったら、ぜひ「スキ」をお願いします。

あわせて読みたい

生成役と評価役を分ける設計は、こちらで具体的に書いています。

会話の長さの管理と、状態をファイルへ置く運用はこちらです。

どこまで自動で通すかを決めたときの記録はこちらに。