はじめに

CLAUDE.md を書いたのに出力が変わった実感がない。
そう感じたことはないでしょうか。

書き方が悪いのだと思ってテンプレートを調べ直す人が多いのですが、原因はたいてい別の場所にあります。
トレンドであるHarness Engineering の枠組みで整理すると、後述するハーネスの枠組みのほとんどはコピペで埋めることができる一方で、最も重要な要素が空のまま放置されています。

この記事ではその空いている要素を特定して、
コードを用いずに、プロンプトの考え方や仕組みなどを中心に書いていきます。

想定読者

Claude Code や Codex を毎日使っているのに CLAUDE.md（AGENTS.md）の効果を感じられていない方
Harness Engineering（ハーネスエンジニアリング）という言葉は見かけたものの実装の記事ばかりで腹落ちしていない方
プログラミングにあまり触れておらず、生成AI活用をされている方

上記に該当しない方でも、Desktopアプリしか使ってない。hookやrulesの作成が難しいのでプロンプトやナレッジでなんとかしたい。

という方はぜひこの記事を参考にしていただけたら嬉しいです。

※参照している公式ドキュメントは2026年8月時点のものです。

1. 同じモデルなのに出力が違うのはなぜか

生成AI活用の支援や相談を受けていると、業務で深く使い込んでいる人と、毎日触ってはいるものの成果が横ばいの人がいます。

もちろん無料版と有料版とで回答に明確な差が出ることは自明ですが、全く同じプラン・同じモデルでも大きく出力が異なる場合、大体は渡しているコンテキストに問題があります。

利用者の方を観察しているとわかるのですが、差はプロンプトを投げる前に何を一緒に渡したかにほぼ集約されます。
深く使っている人の依頼文が特別長いわけでもありません。

すでに仕組み作りが整っているのなら

「〜をして」

のような短い依頼でも成果を出します。

ただしその短い依頼の背後には前提や制約や評価基準が定義されています。

配置している場所がファイルなのかチャット欄なのか、それともプロジェクトナレッジなのかは実のところどちらでもよくて、生成AIに定義が伝わっているかが最も重要な論点になります。

この定義を示すのが、昨今のトレンドであるharness（ハーネス）というものです。

2. そもそも harness ってなに?

直訳すると馬具、馬に乗る時の鞍や高所作業なんかの安全ベルトもハーネスと呼びますね。
今回はシステムの話ですが、本質は同じです。

生成AIを安全に、効果的に使うための環境を揃える手段を指してハーネスと呼びます。

Anthropic の定義がいちばん短いので引用します。

An agent harness is the software scaffolding around a model: the loop, tools, context management, and guardrails that turn raw intelligence into a working agent.

モデルを取り囲むソフトウェアの足場であり、生の知能を実働するエージェントに変えるループ・ツール・コンテキスト管理・ガードレールのことだと書かれています（Agent Harness Design）

プロンプトテクニックやループエンジニアリングなどが運用のためのテクニックだとしたら、ハーネスはAIが上手に仕事をするための環境を作成する手段であると言えます。

3. ハーネスの要素について

ハーネスを分解するとおおよそ次の5つになります。

コンテキスト — 前提・制約・評価基準・出力形式
ツール — 検索、ファイル操作、情報源
ガードレール — 入れてはいけない情報と、させてはいけない操作
フィードバック — 出力を評価して返す仕組み
メモリー — 渡した文脈を溜めて再利用する仕組み

このうち2から5はネットで調べるか生成AIに聞けば大体は準備が整います。
MCP を繋げばツールが増え、hooks を書けばガードレールが立ちます。テストを通せばフィードバックが回り、MEMORY.md を置けばメモリーもできます。

基本的にはいずれも誰かが作ったものを設置する作業です。

悲しいことに生成AIを使う上では自分で考えるより、二十四時間のうちの十六時間以上を生成AIに捧げる賢人が作成したものを取り込む方が良いです。

では一般的なユーザーである我々ができることは何か。

それが1のコンテキストを作成することです。
ここは自分の頭の中にしかないので、誰も代わりに書いてくれません。

XでバズっているエンジニアのCLAUDE.md を全く同じように置いたり、良質なSkillやhooksを使っても出力が変わらなかった人はたいてい2から5だけを埋めているだけのように思えます。

4. なぜ出力が一般論になってしまうのか

生成AIの回答に対して「これは一般論だからウチには当てはまらない」という感想はよく聞きます。

ではなぜ一般論になるのか。
多くの場合、自分が何を基準に判断しているかを自分で把握できていないことが原因です。
自分でも把握できていないのだから、それを生成AIに伝えることはできません。

毎日やっている判断ほどそれが当たり前になり、言語化する機会を失っていきます。

数字を見てこれは異常だと感じるのに、その閾値がいくつなのかと聞かれると答えられない。
レビューでこれは通せないと判断するのに、何が足りないのかを説明しようとした途端に曖昧になる。

心当たりのある人は多いはずです。
これは所謂叩き上げの経験によって作られた判断基準なわけですから、これまで通り仕事をするのであれば特段大きな問題にはなりません。
暗黙のままでも、共通の認識を持っている人間同士なら回ります。

ここで、新人にやや気難しいクライアントへの挨拶を任せる場面を想像してみてください。

「あの人はこういう癖があるから、前もってこれしといた方がいいよ！」

良いマネージャー・上司ならこのような一言を必ず添えるはずです。

生成AIはこのような暗黙知を知りません。
この気遣いにあたる判断基準を渡さないまま依頼している限り、返ってくるのは誰にでも当てはまる答えになります。

5. 渡した情報の種類で出力がこう変わるという実例

抽象的な話が続いたので実物を出します。同じ依頼を2通りで投げた例です。

A. コンテキストを渡さない場合

【入力】

開発チームの生産性を上げる施策を5つ提案してください。

【出力】

返ってくるのは所謂どの会社にも当てはまる一般論ばかりです。
CI/CDの整備、ペアプログラミング、ドキュメント文化、1on1の実施。
どの会社にも当てはまる内容のため、間違ってはいないものの実際の現場に落とし込むことはできません。

B. コンテキストを供与

当社開発チームのレビュー滞留を解消する施策を提案してください。

前提: エンジニア8名（うち業務委託3名）。PRのレビュー待ちは平均2.5日で、
      承認できるのはテックリード2名に集中している。リリースは週1回の定期便。
制約: 増員はなし。CI環境の変更は来期まで凍結。レビューの品質は落とさないこと。
評価基準: レビュー待ち時間の短縮に直接効くこと。テックリードの負荷を増やさないこと。
出力形式: 施策名 / 狙い / 最初の1週間でやること / 想定リスク の表で5件。

今度はテックリード2名に承認が集中しているという前提を踏まえた案が上位に並びます。

注目してほしいのはプロンプトの長さではなく、足した情報の種類のほうです。
増えているのは前提・制約・評価基準・出力形式で、経験上はだいたいこの4種類に収まります。

CLAUDE.md に書く内容も、突き詰めるとこのあたりに収束していくように思います。
ファイルに移すかその場で貼るかという置き場所の違いだけで、やっていることはそれほど変わりません。

6. どの要素が抜けやすいか

抜け方にはそれぞれ症状の傾向があります。

評価基準を書かないと、何が良い出力かを AI が自分で決めます。
狙いとずれた方向で完成してしまい、しかも出力そのものの完成度は高いので読み終わるまで気づけません。

制約を書かないと実行できない提案が混ざります。
予算も期限や体制も伝わっていないので当然です。
選別にこちらの時間を取られて、結局は手間が増えます。

出力形式を書かないと毎回かたちが変わります。
最近ではHTMLで出力させることがトレンドですが、これもあらかじめ定義して伝えないことにはMD形式で生成され、後々成形の手間がかかります。

普段自分が書いているプロンプト、使っているCLAUDE.md（AGENTS.md）やhookにこれらの要素が入っているか、一度数えてみてください。
コピペしているからわからないという方は今が良い機会です。ぜひ一度確認してみてください。

プロジェクトナレッジやhookに書いているよーという方、
僕と同じ思想なので握手しましょう。

7. 書けない前提は AI に掘らせる

これらの要素を毎回自分で書き切るのは正直しんどいです。
しかも書き忘れた前提には自分で気づけません。
気づけないものは書けません。

生成AIでなんでもできる昨今において、
結局ゼネラリストよりもスペシャリストの方が良い仕事をできる根拠はこれです。

そこで AI 側から質問させます。

これから[業務テーマ]について依頼します。
まず回答せずに、良いアウトプットを出すために不足している情報を、
重要な順に5つまで私に質問してください。
私の回答を受けてから本題に入ってください。

これを挟むと、分析の対象は何月分なのか・読み手は誰なのかといった回答に必要な前提を出力の前に聞いてくれます。
前提のずれが対話のなかで解消されるわけです。

Claude では Ask User Question という仕組みとして実装されていますが、上のように書けばGemini でも ChatGPT でも同じ対話が起きます。ツール固有の機能ではありません。

ただ、この型の本当の価値は出力の質ではなく、

答える際に詰まってしまった質問こそが、
自分の中で言語化されていない判断基準そのものである

という点にあると考えています。

8. おすすめの判断基準と、フィードバックへの回し方

最後に、出力を受け取ったときの判断基準としておすすめのものを置いておきます。

自社の固有名詞や数値が出てくるか？
→出てこないなら前提が足りていません
明日から動ける粒度か？
→方針止まりなら制約が伝わっていません
勝手な仮定で話が進んでいないか？
→進んでいるなら前提の渡し漏れです
なぜその案なのかが書かれているか？
→書かれていないなら評価基準を渡していません

見てのとおり、どの症状も先ほどの要素のどれかに対応しています。
ポイントは「なんか違う」で終わらせないことです。

減点の理由をどの要素が欠けていたかで説明できれば、足りなかったコンテキストが1つ特定できます。
それを次の依頼なり CLAUDE.md なりに書き足す。

この繰り返しが、自分の生成AIを自分専用に磨き上げていく方法だと考えています。

ここで一つ補足があります。
この往復をループと呼びたくなるのですが、正確には違うと考えています。

ループと呼ぶべきなのは、ハーネスという環境に基づいて AI が計画から実行と自己チェック、人間へのハンドオフまでを自動で回す仕組みのほうです。
Claude Code の /goal がその典型で、公式ドキュメントも the agentic loop をコンテキスト収集 → 実行 → 検証というエージェント側の循環として説明しています。
人間が手で回すこの往復は、そのループが正しく回るように環境を厚くしていく作業です。

ループの中に人が入るのではなく、ループが回る土台を育てる。
Harness Engineering が本来指しているのはこちらだと考えています。

まとめ

Harness Engineering という言葉はどうしても実装の話に見えます。

実際Engineeringという名称が付いている関係上実装の話で間違いはないのですが、生成AI活用者全員に対して重要な思想にもかかわらず、hooks を書く、MCP を繋ぐ、CI を回すといったプロダクト開発をメインのトピックに置いた記事が多い印象です。

ただ、足場をどれだけ立派に組んでも、そこに載せる材料（コンテキスト）を自分が持っていなければ良い出力にはなりません。

材料とは自分の判断基準のことで、たいていは言語化されていません。
だから掘り出す作業が要ります。

逆質問のプロンプトも今回の判断基準も、まずはコピペで使い始めて構いません。
ただ、コピペのままでは誰かのハーネスを借りている状態が続きます。

この機会に中身を理解して、自分なりのコンテキストを渡す癖をつけてもらえたら嬉しいです。

参考

Agent Harness Design: 3 Patterns for Harnessing Claude's Intelligence（Anthropic, 2026-04-02）
Effective context engineering for AI agents（Anthropic, 2025-09-29）
The new rules of context engineering for Claude 5 generation models（Anthropic, 2026-07-24）
My AI Adoption Journey（Mitchell Hashimoto, 2026-02-05）
How Claude Code works（Anthropic Docs）
Manage Claude's memory（Anthropic Docs）
AGENTS.md