「ハーネス」って結局、何？ みんな使い方が違うAIエージェント用語をHugging Faceが整理

AIエージェントの話をしていると、知らない言葉が次々と出てくる。

「ハーネス」「スキャフォールド」「コンテキストエンジニアリング」——どれも聞いたことはあるけど、正確に説明できるかというと...ちょっと難しいよね。

しかも困ったことに、同じ言葉なのに人によって指しているものが違う。これが本当にやっかいで。

😅 ICLR 2026でもみんな混乱していた

2026年5月末、AI分野のコミュニティ「Hugging Face」がひとつのブログ記事を公開した。タイトルは「Harness, Scaffold, and the AI Agent Terms Worth Getting Right（ハーネス、スキャフォールド、そして正しく理解すべきAIエージェント用語）」。

このグロッサリー（用語集）が生まれたきっかけが、正直すぎて笑える。

AI分野の主要学会ICLR 2026に参加したHugging Faceのメンバー（@ariG23498）が、学会後にこんな投稿をした。

世界最高峰の学会の参加者でさえ、定義が揃っていなかったんだよね。

ということは、私たちが「なんとなくわかったふり」をしていたのも、しょうがなかったかもしれない 😂

🔍 まず「AIエージェント」って何をする存在？

用語の整理に入る前に、エージェント全体のイメージを掴んでおきたい。

普通のチャットAI（Claude, ChatGPTなど）は、質問したら答えて終わり。1回の「問い→答え」で完結する。

エージェントは違う。外部のツールを使い、結果を確認し、次の行動を決め、また動く——というループを自律的に繰り返す。Claude Codeがコードを書いてテストを走らせてエラーを修正する、みたいな動きが代表例だよね。

で、このエージェントを構成する要素を分解すると、Hugging Faceの整理はこうなる。

🧩 用語を分解する

モデル（Model）

これはシンプル。Claude, GPT, Qwenみたいな、テキストを受け取ってテキストを返すLLM本体のこと。

モデル単体では「記憶がなく、ループもない」。ツールを使いたいという意思は示せるけど、実際に実行する仕組みは持っていない。1回答えたら止まる。

スキャフォールド（Scaffolding）

スキャフォールドは「建築でいう足場」と思ってほしい。

モデルの周りを囲む「行動定義レイヤー」——システムプロンプト、ツールの説明、モデルの出力をどう解釈するか、複数ステップをまたぐ記憶の管理方法——こういった設定の集合体がスキャフォールドだ。

要は「モデルに世界をどう見せるか」を決める部分といえるかもしれない。

ハーネス（Harness）

ここが一番混乱が多かった用語。

狭義のハーネスは「実行レイヤー」だ。モデルを呼び出し、ツール実行を処理し、いつ止めるかを決める部分。「エージェントを実際に動かすエンジン」と言ってもいい。

一方で広義のハーネスは「モデル以外のすべて」を指すこともある。Claude Codeの公式ドキュメントにはこう書いてある——「Claude Codeは、Claudeの周りにあるエージェントハーネスとして機能する」。この使い方だとスキャフォールドもハーネスに含まれる。

どちらが正しいかというより、文脈によって使い分けられているのが現状。Hugging Faceはこのズレを認めたうえで「どちらの意味で使っているかを意識しよう」と言っている。

ちなみに「ハーネスエンジニアリング」という言葉も最近よく見かける。エージェントをうまく動かすための実行層の設計全体——エラーハンドリング、停止条件、ガードレールの設計——を指す新しい実践領域だ。

エージェント（Agent）

コミュニティでよく使われる等式がある。

エージェント = モデル + ハーネス

もっと正確に言えば「モデル + スキャフォールド + ハーネス」で、それが合わさって「ループの中で行動できる存在」になる。

面白いのは、同じモデルでもハーネスが違えば、まったく別のエージェントに見えること。Claude Codeと別の何かが同じモデルを使っていたとしても、ハーネスの設計次第で全然違う使い心地になる。モデル、ハーネス、プロダクトは別物なんだよね。

🔧 ついでに整理しておきたい関連用語

コンテキストエンジニアリング

プロンプトエンジニアリングとよく混同されるけど、指している範囲が違う。

• プロンプトエンジニアリング → 1回の推論でどう指示を書くか

• コンテキストエンジニアリング → その推論ウィンドウの中に、何の情報をどう入れるか

エージェントが動くにつれて「前のステップの結果をどうコンテキストに含めるか」が変わっていく。この動的な管理全体がコンテキストエンジニアリングの範囲だ。

スキルとサブエージェント

• ツール → 単一のアクション（「このコマンドを実行」）

• スキル → 複数ステップのタスクをこなすための再利用可能な知識パッケージ（「バグを調べて仮説を立てて修正する」）

• サブエージェント → 別のエージェントに呼び出される独立したエージェント。自分自身でツールを使い、さらにサブエージェントを呼ぶこともできる

複数のエージェントを束ねる上位の制御役をオーケストレーターと呼ぶ。ハーネスが「一つのエージェントを動かす」のに対して、オーケストレーターは「複数エージェントを調整する」イメージ。

💡 Miccellの視点：「定義を揃えること」自体が次のフロンティア

この用語集で気になったのは、内容そのものよりも「なぜこれが必要になったか」という背景かもしれない。

AIエージェントの分野は、技術の進歩があまりに速くて、用語の共通認識が追いついていない。ICLR 2026という最前線の学会で、関係者が同じ言葉で違うものを指していた——それは笑い話じゃなくて、フロンティア領域ならではの現象だと思う。

電気が普及し始めた頃、「電圧」「電流」「抵抗」の定義が人によってバラバラだった時代を想像してほしい。共通言語が生まれるのは、技術がある程度成熟して、複数の人が協力して何かを作り始めるときだ。

今のAIエージェントはまさにその段階に入りつつあるんじゃないかな。

Hugging Faceがこういう用語集を出したこと自体が、コミュニティが「そろそろ言葉を揃えないと次に進めない」という段階に来たサインだと思っている。仕組みを正確に語れる人が、次の設計を正確にできる。そういう時期に差し掛かっているかもしれない。

📝 まとめ：混乱しているのはみんな同じ

この記事で整理したことをざっとおさらいすると、

• モデル → LLM本体。単体では動けない

• スキャフォールド → モデルに「世界の見せ方」を定義する設定層

• ハーネス → 実行エンジン。狭義は実行ループ、広義はモデル以外の全部

• エージェント → モデル＋ハーネス（＋スキャフォールド）の合体

• コンテキストエンジニアリング → コンテキストウィンドウの中身の設計と管理

「ハーネス」の意味があいまいだったのは、あなただけじゃない。世界中の研究者も同じ状況だったんだよね。

とはいえ、こうして定義が整理されてくると、エージェントの設計や議論がずっとしやすくなるはずだ。次にClaude CodeやCodexの話をするとき、「モデルじゃなくてハーネスの設計の違いだよね」という会話ができるようになるとちょっと面白くなるんじゃない？

あなたが「ハーネス」という言葉で一番しっくりきた定義はどれでしたか？ぜひコメントで教えてほしい。

✏️ 製作ノート

この記事を書くきっかけは、ハーネスエンジニアリングの記事をいくつか読んでいたときに「あれ、ハーネスの定義がサイトによって違う」と気づいたこと。

調べてみたら、Hugging Faceがちょうどその混乱を解消する用語集を出していた。「自分が混乱していただけじゃなかった」と知ったときの安堵感は大きかった 😂

モデルとハーネスを分けて考えるようになると、「このエージェントが上手く動かないのはモデルの問題か、ハーネスの設計の問題か」という切り分けができるようになる。これ、実際に使う上でかなり大事な視点だと思っている。

Miccell - 仕組みがわかれば、世界はもっと面白くなる。