ハーネスエンジニアリングとは AIの外殻を設計する話

AIエージェントまわりの話題で、2026年に入ってから急に見かけるようになった言葉があります
それがハーネスエンジニアリングです

ざっくり言うと、AIモデル本体ではなく、その周りを取り囲む”足場”を設計するという考え方です
ハーネスエンジニアリングとは何なのか、なぜ今この言葉が広まっているのかを、初心者向けにかみ砕いて整理してみます

この記事は「AIの○○エンジニアリング」連載の3本目です
前回はコンテキストをどう積むかという話でしたが、今回はそのコンテキストを積んだり道具を渡したりする外側の仕組みそのものに目を向けます

前回のおさらいをしたい方は、こちらもどうぞ

ハーネスエンジニアリングとは?ざっくり言うと

結論から言うと、ハーネスエンジニアリングとは、AIモデル本体をのぞいた「モデルを取り囲むソフトウェア基盤全部」を設計する営みのことです
ツールをつなぐ・途中経過を覚える・入力欄に何を載せるか・失敗したら立て直す、といった裏方の仕組みをまとめて指します

ハーネス(harness)という英単語は、もともと馬具や、登山・パラシュートで体を支える装具を意味します
暴れる馬や高所の体を、道具でしっかり支えて安全に働かせる、そんなニュアンスの言葉です

AIの世界では、この言葉が「賢いけど、そのままだと何もできないモデル」を実際に仕事させるための装具一式という意味で使われます
モデルは頭脳、ハーネスは体や道具や段取り、というイメージが近いです

ここで大事なのは、モデルとハーネスは別モノという点です
同じモデルでも、取り囲むハーネスの出来しだいで、できる仕事の質はかなり変わってきます

この「同じ頭脳なのに、周りの装具で結果が変わる」という感覚が、ハーネスエンジニアリングの一番の勘どころです
あとの章で、その中身を具体的に見ていきます

なぜ2026年に「ハーネス」が主流の言葉になったのか

この言葉がここまで広まった背景には、AIの作り方をめぐる言葉の進化ラダー(はしご)があります
ざっくり言えば、注目される設計対象が少しずつ外側へ広がってきた、という流れです

• プロンプトエンジニアリング:指示文(プロンプト)そのものを工夫する段階
• コンテキストエンジニアリング:入力欄ぜんぶに何を積むかを設計する段階(前回のテーマ)
• ハーネスエンジニアリング:そのコンテキストを扱う外側の仕組みごと設計する段階(今回)

指示文 → 文脈 → 外殻、と設計する範囲がだんだん広がってきたわけです
2026年に入って、この一番外側の「外殻(ハーネス)」に注目が集まった、というのがおおまかな流れになります

背景には、2026年ごろから長く動き続けるエージェントが実用になってきた、という事情もあります
数十分から数時間かけて自律的に作業させると、途中でつまずいたり脱線したりが増えるので、それを支える外側の仕組みの出来が、そのまま成果を左右するようになってきたわけです

「ハーネス」という語自体は公式も使っている

ハーネスという語自体は、一部の界隈で使われているような言葉ではありません

Claude を開発する Anthropic は、2025年11月に公開した記事で、自社のClaude Agent SDK(エージェントを作るための開発キット)を “a general-purpose agent harness”(汎用のエージェントハーネス)とはっきり呼んでいます
つまり「モデルを取り囲む装具」という意味でのハーネスは、公式の文書にも登場する実在の用語です

一次ソースを確認したい方はこちらです
Effective harnesses for long-running agents(Anthropic・英語)

「独立した分野」と呼ぶのは新しめのフレーミング

一方で、「ハーネスエンジニアリング」を一つの独立した専門分野として名指す言い方は、2026年になって広まった新しめの枠づけです
ベンダーのブログや技術記事から広がったフレーミングで、教科書に載っている確立した分類とはまだ言えません

「2024年はプロンプト・2025年はコンテキスト・2026年はハーネス」といったキャッチフレーズも見かけます
これは分かりやすい世代論として語られているだけで、公式に定められた区分ではない、という点は押さえておきたいです

ハーネス(外殻)は大きく6つの部品でできている

ハーネスと言われても、中身が見えないとピンとこないと思います
ここでは、モデルを取り囲む外殻を6つの部品に分けて見てみます

部品	ざっくりの役割
ツール統合	ファイルの読み書き・コマンド実行・Web検索など、モデルが外の世界に手を伸ばす手段
メモリと状態	会話やタスクの途中経過を覚えておく仕組み
コンテキスト管理	限られた入力欄に、何を載せて何を捨てるかの調整(前回のテーマ)
オーケストレーションループ	考える→動く→結果を見る→また動く、を繰り返す司令塔(次回のテーマ)
検証と回復	失敗やエラーを見つけて立て直す仕組み
権限ガードレール	やっていい操作・ダメな操作の線引き

この6つのうち、コンテキスト管理を掘り下げたのが前回のコンテキストエンジニアリングでした
そして次回は、オーケストレーションループを掘り下げるエージェントループの回になります

連載でバラバラに見えていたテーマが、実はハーネスという一つの外殻の部品どうしだった、という見取り図です
今回はその外殻の全体像を押さえておく、という位置づけになります

モデルが賢いのではなく、外殻が賢さを引き出す

ここがこの記事で一番伝えたいところです
モデルの地力だけで決まるのではなく、周りの足場が賢さを引き出しているという見方です
効いているのはモデルと足場の両方で、そのうち足場の側の働きが見落とされがちだと思っています

たとえば同じ人でも、道具も資料も何もない部屋に放り込まれたら、実力を出しきれません
逆に、必要な資料・使い慣れた道具・失敗しても戻れる段取りがそろっていれば、同じ人でもぐっと良い仕事ができます

AIで言えば、資料を丸ごと読めるか・途中結果を覚えておけるか・失敗したときにやり直せるか、そのあたりが「道具のそろった部屋」かどうかにあたります
同じモデルでも、この段取りが足りないと、同じ問いに何度も答えを外す、ということが起きます

AIエージェントも同じで、モデルの地力は同じでも、ハーネスの出来で成果が大きく動きます
ここを混同すると「新しいモデルが賢くなった」と思っていた変化が、実は「周りの足場が良くなっただけ」だった、というズレが起きます

同じモデルでも足場でスコアが動く

この「足場で差がつく」現象は、コード生成の力を測るベンチマーク(性能テスト)でもよく話題になります
プログラムの課題をどれだけ解けるかを測るSWE-bench系のテストがその代表です

ここでは、モデル素の力を比べるために、あえて最小限のハーネスを使う工夫がされています
そのうえで、各社が自前で作り込んだ足場をかぶせると、同じモデルでもスコアが10〜30ポイントほど上がるという報告もあります(公開リーダーボードの一例)

数値は測り方や時期で変わるので鵜呑みは禁物ですが、足場を変えるだけで結果が大きく動くという傾向は、あちこちで共通して見られます
「モデルだけ見ていても半分しか分からない」というのが、ハーネスに注目する理由です

scaffold(足場)とハーネスはどう違うのか

ハーネスを調べていくと、たいていscaffold(スキャフォールド)という言葉に出くわします
日本語にすると「足場」で、建設現場に組む、あの足場と同じ単語です

結論を先に言うと、scaffold と harness は、ほぼ同じものを指す言葉です
どちらも「モデルを取り囲むソフトウェアの基盤」を意味していて、はっきり線を引ける別物ではありません

違うのは、主にニュアンスと、よく使われてきた場面です
ざっくり並べると、こんな呼び分けになります

見る角度	scaffold(足場)	ハーネス(装具)
言葉の出どころ	研究・評価まわりの旧来語	製品・実行環境まわりの新しめの語
イメージ	建設現場に組む足場	登山やパラシュートの命綱・馬具
よく使われた例	AutoGPT の “scaffolded GPT-4″、Agentless	Claude Agent SDK の “agent harness”、Claude Code
指しているもの	ほぼ同じ(モデルを取り囲むソフト基盤)

おおまかには、scaffold は研究や評価の文脈で長く使われてきた言葉で、harness は製品・実行環境の文脈で2026年に主流化した言葉という住み分けです
新しく記事を読むときは、どちらが出てきても「あぁ、外殻の話ね」と同じ引き出しに入れて大丈夫です

Claude Code はハーネスエンジニアリングの実例

抽象的な話が続いたので、身近な実例に落とします
私が普段使っているClaude Code(Claude にファイル操作やコマンド実行までまかせられるツール)は、まさにハーネスの分かりやすい例です

あらためて振り返ってみると、私がClaude Codeを使いこんで「便利になった」と感じた場面の多くは、モデルが急に賢くなったからではありませんでした
ファイルを読ませる・コマンドを走らせる・失敗したら差し戻す、といった周りの段取り(=ハーネス)が整ったからという感覚のほうが近いです

ちなみに Anthropic 自身も、Claude Code と同じ土台をClaude Agent SDKとして公開していて、これを「エージェントハーネス」と位置づけています
つまり Claude Code は、ハーネスを実際の製品にした一例だと言えます

拡張機構はぜんぶハーネスの部品だった

Claude Code には、いわゆる拡張機構と呼ばれる仕組みがいくつかあり、この記事では代表的な4つを取り上げます
先ほどの「6つの部品」に重ねて見ると、それぞれの位置づけが分かりやすくなります

• MCP:外部の道具やデータにつなぐ規格 → ハーネスのツール統合にあたる
• サブエージェント(Agents):役割ごとに小さな担当を立てて任せる → オーケストレーションにあたる
• Hooks:処理の途中に自動で割り込ませる仕掛け → 検証と回復・権限にあたる
• Skills:再利用できる手順書をまとめておく仕組み → 段取りを部品化する働き

つまり、Claude Code の拡張機構をいじるという作業は、実は自分の手でハーネスを組み替えているのと同じことなんです
拡張機構そのものの入門は、こちらで別途まとめています

Claude Code拡張機構入門(Skills / Agents / MCP / Hooks)
Claude Code設定ファイル早見表

同じ枠組みは Claude 以外にもあります
OpenAI のCodex CLIや Google の Gemini CLI も、モデルの周りに独自のハーネスを組んだ製品で、各社が自前の外殻で腕を競っている、という構図です

なので、これからエージェント系のツールを選ぶときは、モデル名だけでなく、どんなハーネスを積んでいるかにも目を向けると、実際の使い勝手が見えてきます
同じモデルを積んでいても、使える道具の多さや失敗したときの粘り強さで、体感はけっこう変わってきます

ハーネスエンジニアリングのよくある質問

まとめ 次回はハーネスの中の”ループ”を深掘り

最後に、この記事の要点を振り返っておきます

• ハーネスエンジニアリングとは、モデルを取り囲む外殻(足場)を設計する営み
• 定式は Agent = Model + Harness、同じモデルでも足場で成果が変わる
• 外殻はツール統合・メモリと状態・コンテキスト管理・ループ・検証と回復・権限の6部品
• scaffold とハーネスはほぼ同義、語感と使われる場面の違いくらい
• Claude Code はハーネスの実例、拡張機構はその部品

今回は外殻の全体像を押さえました
次回は、その中でも司令塔にあたるオーケストレーションループ、いわゆるエージェントループを一段深く掘り下げます

「考える→動く→結果を見る→また動く」をどう回すか、その設計に注目したエージェントループの話です
続きは次回のループエンジニアリングでどうぞ

連載「AIの○○エンジニアリング」の記事一覧

• 連載ハブ:AIの4つの○○エンジニアリング総まとめ
• 1本目:プロンプトエンジニアリングとは
• 2本目:コンテキストエンジニアリングとは
• 3本目:ハーネスエンジニアリングとは(この記事)
• 4本目:エージェントループの話

用語をまとめて確認したい方は、AI用語集もあわせてどうぞ