結論から
ハーネスとは、AI（モデル）を実際の仕事に使えるようにする「外側の仕組み」全体のことです。モデルは「エンジン」。ハーネスは、そのエンジンを積んで走らせる「車体」——毎ターンどの文脈（コンテキスト）を渡し、どんなツールをつなぎ、結果をどう戻し、要らない履歴をどう捨てるか、を受け持つ土台です。
この記事で伝えたいのは一点です。AIの品質は、モデルの賢さだけでは決まらない。同じモデルでも、ハーネス（土台）の作り込み次第で、結果は大きく変わる。 そして——ハーネスがやっていることは、突きつめると全部、前回までに話した「文脈をどう出し入れするか」（→ コンテキストの記事）と「エージェントをどう回すか」（→ エージェントの記事）の設計です。ここが分かると、「なぜ同じAIなのに、ツールによって出来が違うのか」が腑に落ちます。
- ハーネスとは：モデルの「外側」の仕組み。文脈を組む・ツールを渡す・結果を戻す・履歴を削る、を受け持つ
- なぜ大事：モデルは賢くても、土台がなければ実務では使えない。同じモデルでも土台次第で結果が変わる
- 3つの層：プロンプト（一回の言い方）→ コンテキスト（一回分の中身）→ ハーネス（何回ものやり取りの土台）
- あなたにも関係：アプリに組み込むAI機能も、小さなハーネス。品質は「どんな文脈をどう渡すか」でほぼ決まる
動画版（約2分半）は本文の上に埋め込んであります。
① モデルは「エンジン」、ハーネスは「車体」
「AIが賢い／賢くない」という話をするとき、私たちはついモデル（GPT や Claude といった頭脳そのもの）だけを見がちです。でも、モデル単体は、机の上に置かれたエンジンのようなもの。それだけでは、どこにも走っていけません。
エンジンを実際の移動に使うには、車体が要ります。ハンドル、タイヤ、ブレーキ、燃料を送る配管。ハーネスは、この「車体」にあたる仕組みです。ユーザーの入力を受け取り、必要な資料を集めて文脈を組み立て、モデルに渡し、モデルが「このツールを使え」と言えば実際にツールを動かし、その結果をまたモデルに戻す。長くなった履歴を要約して捨てる。エラーが出たらやり直す。——こうしたモデルの周りの段取り全部が、ハーネスです。
前回のエージェントの記事で「AIを動かす土台」と呼んだもの、その正体がこれです。エージェントが「自分でループする」ことだとすれば、ハーネスは「そのループを実際に回してやる装置」。
② ハーネスがやっている4つのこと
ハーネスの仕事は、だいたい次の4つに整理できます。全部、コンテキストの出し入れだと気づいてください。
- 文脈を組む：ユーザーの入力に、必要な資料・過去のやり取り・守ってほしいルールを足して、モデルに渡す「一回分の文脈」を作る（→ RAG は、この「必要な資料を足す」部分の仕組みでした）
- ツールを渡す：モデルが使える道具（検索、ファイル編集、外部API…）を用意し、モデルが「これを使う」と言ったら実際に動かして、結果を文脈に戻す（→ MCP は、この「外の道具をつなぐ」共通の差し込み口でした）
- 結果を戻す：ツールの実行結果や、途中経過を、次のターンの文脈に入れて、モデルに続きを考えさせる
- 履歴を削る：やり取りが長くなったら、要点だけ残して古い部分を捨てる・要約する。放っておくと「コンテキスト・ロット」で精度が落ちるから（→ コンテキストの記事）
こうして並べると分かります。RAG も MCP もスキルも、ハーネスという土台の「部品」だったのです。ハーネスは、それらを組み合わせて「今このタスクに要る文脈を、過不足なく用意し続ける」装置なのです。
③ だから、同じモデルでも結果が変わる
ここが実感しにくいところですが、とても大事です。まったく同じモデルを使っても、ハーネスの作り込み次第で、結果は大きく変わります。
AIの仕事は、3つの層で考えると整理できます。
- プロンプト：一回の「言い方」を工夫する（例：「箇条書きで」「まず結論から」）
- コンテキスト：一回分の「中身」を過不足なく渡す（必要な資料を入れ、ノイズを入れない）
- ハーネス：何回ものやり取りをまたいで、文脈をリセット・引き継ぎ・圧縮する「土台」を設計する
「ハーネス・エンジニアリング」という言葉が2026年ごろから使われ始めたのも、モデルの賢さが上がるほど、差がつくのは"周りの土台"の方だと分かってきたからです。実際、コーディングを手伝うAIツール（SWE-agent、OpenHands など、同じ土台の上に別々のハーネスを組んだもの）は、中のモデルが同じでも、土台の設計次第でベンチマークの成績が大きく違います。エンジンが同じでも、車体の出来でタイムが変わるのと同じです。
④ あなたのアプリのAI機能も、小さなハーネス
「ハーネスなんて、AIツールを作る会社の話でしょう」と思うかもしれません。でも、あなたがアプリにAI機能を組み込むとき、あなたは小さなハーネスを作っています。
たとえば「問い合わせ内容を、AIに要約させて保存する」機能。ここであなたは、①どの情報をAIに渡すか（問い合わせ本文だけ？ 過去の履歴も？）、②どんなルールを添えるか（「個人情報は書かない」など）、③結果をどう受け取って保存するか、を決めています。これがハーネスの設計そのものです。そしてAI機能の品質は、賢いモデルを選ぶこと以上に、この「どんな文脈を、どう渡すか」の設計でほぼ決まります。
さらに、ここは安全性にも直結します。AIに渡す文脈に、他人のデータや余計な権限が混ざれば、精度が落ちるだけでなく、情報漏えいや誤操作の事故になります（→ RAGとデータ漏えい、AIエージェントの権限過剰の記事）。ハーネスの設計は、性能と安全性の、両方の土台なのです。だからこそ、公開前に「どんな文脈が、どこまでAIに渡っているか」を一度点検する価値があります。
よくある質問
ハーネスとエージェントは、どう違うんですか。
エージェントは「AIが自分でループして仕事をこなす」というやり方、ハーネスは「そのループを実際に回してやる土台・装置」です。エージェントが運転手なら、ハーネスは車そのもの。ほぼセットで語られます。
プロンプトを工夫すれば、ハーネスは要らない？
一回きりの単純な用途なら、良いプロンプトで十分です。でも、資料を集めて渡す・ツールを使う・長い作業を続ける、となると、その段取り（ハーネス）が要ります。プロンプトは「一回の言い方」、ハーネスは「何回分もの土台」で、層が違います。
個人でも、ハーネスを意識する意味はありますか。
あります。アプリにAI機能を1つ足すだけでも、「何を渡し、何を渡さないか」を決めた時点で、あなたは小さなハーネスを設計しています。ここを雑にすると、精度も安全性も落ちます。
結局、モデルとハーネス、どっちが大事？
両方ですが、モデルの性能が上がるほど、差がつくのはハーネスの方になってきています。良いエンジンは大前提。その上で、周りの土台の作り込みが、実務での出来を分けます。
