AIニュース解説 AIエージェントの「scaffold」と「harness」──設計を間違えないための用語整理

AIエージェントの「scaffold」と「harness」──設計を間違えないための用語整理

2026.06.01 · AIニュース解説 · スキル・学習 · 約14分

この記事は約 14 分で読めます

ちょっと白状すると、私はこの言葉たちにずっとモヤッとしていました。エージェント、scaffold、harness、ツール、ポリシー。みんな当たり前のように使うのに、人によって指しているものが違う気がして、会話のたびに小さくつまずいていたんです。今日はそのモヤモヤがほどけた話をします。

HuggingFace が「言葉の地図」を一枚出してきました

あなたも最近、AIエージェントまわりの記事を読んでいて「同じ単語なのに書いてる人ごとに意味がズレてる?」と感じたこと、ありませんか。私はわりと頻繁にあります。

2026年5月25日、HuggingFace の公式ブログが、その混乱をまっすぐ整理しにきた記事を出しました（Harness, Scaffold, and the AI Agent Terms Worth Getting Right）。Model（モデル）、Scaffolding（足場）、Harness（駆動部）、Agent、Policy、Tool Use、Skills、Sub-agents、Context Engineering……と、現場でぐちゃっと混ざりがちな言葉を、ひとつずつ区別して定義しています。

派手な新モデルの発表ではありません。でも、エージェントを実際に組んだり運用したりしている人ほど、これは効くはずです。私はタイトルを見た瞬間に「あ、ずっと自分がつまずいてたやつだ」と思って、思わず読みふけってしまいました。

補足

この記事自体、用語に唯一の正解があると主張しているわけではありません。フレームワークやチームによって言葉の使い方は揺れる、と前置きしたうえで「実務で混乱しないための共通の足場」を提案する、という姿勢です。なので本文の定義も、絶対のルールではなく「この粒度で揃えると話が通じやすい」くらいの温度で受け取ってもらえると安全です。

名前がついた瞬間に、設計できるものに変わる

ここ、私がいちばん「おっ」となったところです。

記事の軸は、普段ひとまとめに「AIエージェント」と呼んでいるものを、Model / Scaffold / Harness / Tool Use と役割ごとに分けて考えることにあります。記事自身はコミュニティでよく使われる 「Agent = Model + Harness」 という簡略式にも触れつつ、その Harness と Scaffold の区別をていねいに解きほぐしてくれます。なかでも、ずっと混ざりがちだった2つがきれいに分かれるんです。

ここで大事なのは

scaffold は「モデルに何を見せるか」、harness は「モデルの外側で何を回すか」。

scaffold（足場）は、システムプロンプト、ツールの説明文、出力フォーマット、コンテキストの組み立て方など、モデルから見える世界の設計です。一方の harness（駆動部）は、モデルを実際に呼び出して、ツール実行を受け取り、いつ止めるかを判断する外側の制御ループ。同じ「エージェントの挙動がおかしい」でも、原因が scaffold 側か harness 側かで、直す場所がまるで違ってきます。

私はもともと UI を作る仕事をしているので、この感覚はすごく腑に落ちました。名前のない要素は、設計できないんです。「なんとなく雰囲気で配置されたボタン」を直すのは難しいけれど、「これはプライマリアクション」と名前がついた瞬間に、扱い方が決まる。エージェントの用語も同じで、scaffold と harness に名前が分かれた途端、「じゃあ今の不具合はどっちの話?」と切り分けられるようになる。地味ですが、ここが今回のいちばんの収穫だと感じています。

AIエージェントを内側の『scaffold(モデルに見せる設計)』と外側の『harness(モデルを動かし止める制御ループ)』に分けて示した図解。左に女性開発者が設計カードを見る。
左: scaffold(モデルに見せる設計) / 右: harness(モデルを動かし止める制御ループ)

しかもこの分け方、私たちが普段触っているツールにそのまま当てはまります。たとえば Claude Code のサブエージェントは、独立したコンテキスト・専用のシステムプロンプト・使えるツールの範囲を個別に設定できますが、これはまさに scaffold を切り分ける作業です。逆に OpenAI Agents SDK が面倒を見てくれる handoffs（別エージェントへの委譲）、guardrails（入出力チェック）、sessions（会話状態）、tracing（ログ）は、ほとんどが harness 側の仕事。「自分でループを書かなくていい」とドキュメントが言っているのは、harness を肩代わりしてくれるという意味なんですよね。あなたが普段その設定画面で何気なく触っている項目も、たどっていけば scaffold か harness のどちらかに必ず属しています。

自動化を請けるなら、まず売るのは「モデル」じゃなくて「止め方」

副業で社内自動化や業務効率化を請け負うことを考えているあなたに、ここはぜひ持って帰ってほしい話です。

クライアントと話していると、つい「どのモデルを使うか」に意識が向きがちです。でも今回の整理を踏まえると、提案で差がつくのは、たぶんそこじゃない。harness 側、つまりログをどう残すか・どの操作に人間の承認を挟むか・どこでループを止めるか・失敗したらどう再試行するかを設計できるかどうかです。

たとえば「請求書を読み取って社内システムに登録する」エージェントを請けたとします。モデルの精度はもちろん大事ですが、クライアントが本当に怖いのは「変なデータを無言で大量登録されること」のほう。ここで「登録の前に必ず人間が確認する一手間を入れます」「エラーが3回続いたら止めて通知します」と説明できると、要件定義の解像度が一気に上がります。これ、全部 harness の設計の話です。

  • ログ設計: いつ・どのツールを・どんな入力で呼んだかを残す（後から説明責任を果たせる）
  • 権限と承認: 取り返しのつかない操作の前に人間を挟む
  • 停止条件: 無限ループや暴走を止める基準を先に決める
  • リトライ方針: 失敗時にどこまで自動で粘り、どこで人に渡すか

scaffold（プロンプトやツール定義）と harness（この4つ）を分けて話せるだけで、見積りも説明も具体的になります。「AIで自動化します」より、ずっと信頼される言い方ができるはずです。

個人開発でいちばん効くのは、トラブったときの切り分けです

個人開発をしているあなたなら、一度はこの状況に覚えがあるかもしれません。自作のエージェントが、なんか思った通りに動かない。出力が雑、ツールを呼ばない、途中で迷子になる——でも原因が分からなくて、とりあえずプロンプトをいじって祈る。私もこれを延々やっていました。

scaffold と harness の区別は、この「祈りデバッグ」から抜け出す地図になります。出力の中身が変なら scaffold（プロンプト・出力フォーマット・ツールの説明文）。ツールの呼び方や止まり方が変なら harness（実行ループ・停止判断）。どこを触るべきかが先に決まると、試行回数がぐっと減ります。

エージェントの不具合(出力が雑/ツールを呼ばない)を見て、scaffoldとharnessのどちらを直すか切り分ける様子の図解。右に女性開発者が直す層を選ぶ。
不具合(出力が雑/ツール未呼び出し)を見て、scaffoldとharnessのどちらを直すか切り分ける

ツールの呼び出しそのものを設計するときに、いま現実的な選択肢になっているのが MCP（Model Context Protocol）です。仕様を読むと、サーバーが tools/list で使えるツールの一覧を返し、モデルが「これを使う」と選んだものを、クライアント（harness）側が tools/call で実行する、という流れになっています。ツールは名前・説明・入力スキーマ（JSON Schema）で定義される。これって、まさに scaffold の「ツールの説明文」と harness の「実行」がプロトコルとして分かれている例なんです。一度 MCP でツール層を作っておけば、別のプロダクトでも同じツールを使い回せる、という発想が成り立ちます。

収益化で私が見ているのは、金額より「壊れにくさ」

収益化、と聞くと身構えてしまいますが、今回の話とつなげると意外とシンプルです。

先に正直に書いておくと、この記事では「月◯万円」のような金額は出しません。私自身がその実績を持っているわけではないし、エージェント受託の単価は案件の難易度やクライアント規模で大きくぶれるからです。煽った金額で誰かを動かすのは、媒体として違うなと思っています。

そのうえで、私が「収益につながりやすい」と感じているのは、納品物が壊れにくいことです。あなたがもし継続で声をかけられる人になりたいなら、ここは効いてくるはずです。受託の世界で次も頼んでくれるクライアントは、派手なデモより「黙って安定して動くもの」を評価します。harness 側のログ・権限・停止条件をきちんと組んだエージェントは、トラブっても原因を説明でき、直しやすい。結果として「次もあの人に頼もう」につながる。用語を正しく使えること自体が、実は信頼と単価にじわじわ効いてくる、というのが私の見方です。

補足

SaaS のような形で個人開発プロダクトに育てる場合も、tool use（外部とのやり取り）と policy（どう振る舞うか）を分けて説明できると、保守性が上がるぶん提案もしやすくなります。最初から全部きれいに分けるのは難しいので、「動かしながら、混ざってきた部分を後で切り分ける」くらいの気持ちで十分だと思います。

最初の数日でやりたいのは、用語と設定箇所を結びつけること

いきなり身構えなくて大丈夫です。今回のテーマは、新しい技術を覚えるというより「今あるものに名前を付け直す」作業なので、初期費用はほぼかかりません。私がこの数日でやるなら、こんな順番です。

  1. 用語を自分の言葉に置き換える: HuggingFace の記事を一度通して読み、scaffold / harness / tool use / policy / sub-agents を「自分なら何と呼ぶか」でメモする
  2. 触っているツールに当てはめる: Claude Code やお使いのフレームワークで、「この設定は scaffold? harness?」と一つずつ仕分けてみる。設定画面と用語が結びつくと、一気に手に馴染みます
  3. 小さく一個作る: ツールを1つだけ持つ最小のエージェントを組んで、わざと壊して、scaffold 側と harness 側のどちらを直すと直るかを体で覚える

必要なのは、基本的には公式ドキュメントを読む時間と、無料〜サブスク枠で触れるツールだけです。お金より「設定箇所と用語をひもづける根気」のほうが、ここでは効きます。あなたがすでに何かしらのエージェントを触っているなら、それがいちばんの教材になります。

用語を覚える前に、ここだけは見落とさないでほしい

ここは、あなたにいちばん読んでほしいパートです。便利な地図ほど、過信すると道を間違えます。私が気をつけたいと思っている点を3つに絞ります。

ここは注意

用語はフレームワークごとに揺れる。唯一の正解だと思い込まない。

これは記事自身が最初に断っていることです。scaffold と harness の境界も、実装によっては曖昧になります。「この定義が絶対」と暗記するのではなく、「相手はこの言葉を何の意味で使っているか」を都度確認する姿勢のほうが、現場では事故りません。

ここは注意

ツールの自動実行に、人間の確認を省かない。

MCP の公式仕様でも、ツール呼び出しには人間が拒否できる仕組みを置くべきだ、と明記されています。データを書き換える・外部に送るといった操作を、確認なしで全自動にするのは、便利さと引き換えにかなりのリスクを背負うことになります。harness の停止条件・承認フローは、機能としてではなく安全装置として設計してほしいところです。

ここは注意

仕様の更新が早い。古い情報を「今の仕様」として書かない。

MCP の仕様にも日付付きのバージョンがあるように、この分野は数週間単位で前提が変わります。記事やドキュメントを参照するときは、必ず公開日と対象バージョンを確認してください。半年前のベストプラクティスが、今は非推奨になっていることも珍しくありません。

私は、この「名づけ直し」を地味だけど大事な前進だと思っています

あなたなら、scaffold と harness、どちらの設計が今いちばん手薄になっていそうですか。

新しいモデルが出るたびに盛り上がるのは分かるし、私もその熱が好きです。でも今回みたいに「言葉をそろえる」地味な記事のほうが、実は長く効くんじゃないかと感じています。名前がないものは設計できないし、設計できないものは人に説明できない。エージェントを副業や個人開発の道具にしていくなら、モデルの性能を追いかける前に、まず自分の中の言葉を整える。私はそこから始めるつもりです。

具体的には、手元の小さなエージェントを一度バラして、「これは scaffold、これは harness」と棚卸しするところから。性能の話は、その地図ができてからでも遅くないと思っています。

参考にしたもの

WRITTEN BY 「運営者プロフィール」
FILED UNDER AIニュース解説 · スキル・学習

関連記事