レッスン1: ハーネスとは何か: モデルの外側にある制御コード
学習目標:
- ハーネスとモデルの境界線を引き、「アクションを提案する」側と「実行して制御する」側がそれぞれどちらに属するかを言う
- エージェントとワークフローの違いを使って、あるシステムが何をもってエージェントと呼ばれるのかを説明する
- 「エージェントが十分に信頼できない」という問題を、モデル層で直すべきかハーネス層で直すべきかを判断する
前提: このシリーズの最初の6つのコースを終えており、1回のツール呼び出しの往復（stop_reason: "tool_use" / tool_result）を理解していること | 次: レッスン2 >>
あの1回の往復で、あなたはすでにハーネスを見ている
「エージェントツール呼び出し: エージェントに実際に行動させる」では、完全なツール呼び出しの往復を分解しました: モデルはあなたの質問とツールの一覧を見て、stop_reason: "tool_use" と、「このツールを、このパラメータで呼び出せ」と告げる tool_use ブロックを返してきます。その次に何が起きるかを、ドキュメントは率直に述べています: "The model never executes anything on its own. It emits a structured request, your code (or Anthropic's servers) runs the operation, and the result flows back into the conversation."（モデルは自分では何も実行しない。モデルは構造化されたリクエストを発行し、あなたのコード（またはAnthropicのサーバー）がその操作を実行し、結果が会話に戻ってくる）1 ファイルを開くこと、コマンドを実行すること、ネットワーク呼び出しを行うこと——それらはすべて、エージェントを動かしているホストコードの仕事です。ホストは処理を終えると、出力を tool_result に包み、会話に追記し、次のリクエストを送り出します。
そのホストコードの塊——ツールを実行し、次に何をするかを決める部分——が、このレッスンの主題です。それには名前があります: ハーネス（harness）、モデルの周りに巻かれた制御コードの層です。
ただし、あの前のコースは1回の往復で止まっていました。実際のエージェントが1往復だけで終わることはめったにありません。ツール呼び出しが結果を返し、モデルがその結果を見て、たいていは次のツールを呼び出したくなり、さらに次を呼び出し、ぐるぐると回り続けます。その回り続ける動きを誰が動かすのでしょうか。いつ止めるべきかを誰が決めるのでしょうか。脱線したときに誰が引き戻すのでしょうか。それらはすべてハーネスの仕事です。このレッスンではハーネスとモデルの境界線を引きます。それ以降のレッスンでは、ハーネスを1つずつ部品に分解していきます。
エージェントとは何か: ループの中でツールを使うLLM
Anthropicのエンジニアリングチームは、エージェントについて率直な定義を与えています: "They are typically just LLMs using tools based on environmental feedback in a loop."（それらは典型的には、ループの中で環境からのフィードバックに基づいてツールを使うLLMにすぎない）2 この一文で重みを担っているのは3つの言葉です——ツール、環境からのフィードバック、そしてループ。モデルがツールを呼び出し（ツール）、ホストがそれを実行して結果を返し（環境からのフィードバック）、モデルが結果を読んで次に何をするかを決め、場合によっては別のツールを呼び出し、そしてまた回る（ループ）。前に学んだ往復は、まさにこのループの最初の1回転でした。
同じ記事は、人々が絶えず混同する2種類のシステムを切り分けています。1つ目はワークフローです: "Workflows are systems where LLMs and tools are orchestrated through predefined code paths."（ワークフローとは、LLMとツールが事前定義されたコードパスを通じてオーケストレーションされるシステムである）2 これをやって、次にあれをやって、この分岐では左に行く——すべて人間が事前に決めています。2つ目はエージェントです: "Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage"（一方エージェントとは、LLMが自身のプロセスとツールの使い方を動的に指揮するシステムである）2。
この2つの定義を並べると、違いはモデルの強さの話ではないことがわかります。誰が制御フローの決定を下すかの話です。ワークフローでは、次のステップはハードコードされています。エージェントでは、次のステップはループの中でモデルがその場で決めたものです。ロードマップの言い方を借りれば、それこそがエージェントという名前に値する条件です: "An agent makes its own control-flow decisions inside a loop."（エージェントは、ループの中で自分自身の制御フローの決定を下す）3 そして、そのループを担い、モデルの決定を実際の効果に変えるものが、ハーネスです。
ここで1つ、言い回しに注意が必要です。「モデルが次のステップを決める」とは、モデルが毎ターン、アクションを提案するという意味です。ループがそもそも回るかどうか、モデルにもう一度尋ねるかどうかは、依然としてハーネスのコード次第です。モデルは提案し、ハーネスが裁定する。この線が、以降のすべての土台になります。
同じモデル、違うハーネス、まったく違う結果
さて、このレッスンが最も覚えておいてほしい一文です。あるコミュニティのロードマップは、それをきっぱりこう書いています: "Same model, different harness, completely different result."（同じモデル、違うハーネス、まったく違う結果）3
最初は逆に聞こえるかもしれません。私たちはエージェントの信頼性をモデルの口座につけることに慣れています——こっちは強い、あっちは弱い、と。しかし、あの往復でモデルが実際に何をしたかを思い出してください: 現在の会話を見て、次のアクションを提案しただけです。そのアクションが本当に実行されるかどうか、その後もループが続くかどうか、20ターン空振りが続いたところで打ち切るかどうか、提案されたアクションがデータベースのテーブルを丸ごと落とすものだったときに先に人間に確認するかどうか——どれ1つとしてモデルの裁量ではありません。そのすべてがハーネスに属します。
具体的な比較を挙げます。同じモデル、同じツールセット、同じタスク: プロジェクト内の未使用の依存関係を整理する。
- ハーネスAは、モデルが提案したアクションを無条件にすべて実行します。ターン数の上限もなければ、エージェントが同じ場所で空転していないかのチェックもありません。あるターンでモデルが判断を誤り、誤った削除を提案する。ハーネスは削除する。その後モデルは、すでに自分で壊した状態から先に推論を進め、1つの誤ったステップが10個に膨らみます。この種のシステムの厄介さは、エージェントの自律性からまっすぐ来ています: "The autonomous nature of agents means higher costs, and the potential for compounding errors."（エージェントの自律的な性質は、より高いコストと、エラーが積み重なる可能性を意味する）2
- ハーネスBは同じモデルを動かし、同じ提案を受け取りますが、この制御層はターン数に上限を設け、実質的な進捗のないターンが何回も続いていないかを監視し、削除のような影響の大きいアクションを実行する前には手を止めて人間に尋ねます。同じ悪い提案が、ここではディスクではなく承認弁にぶつかります。
モデルは同一。提案も両方で同一だったかもしれません。一方の実行はプロジェクトを壊し、もう一方は軌道に留まります。違いはすべて、外側の制御コードから来ています。ですから、エージェントが信頼できないとき、まず強いモデルに手を伸ばさないでください——多くの場合、問題はモデル層ではなくハーネス層にあります。
ハーネスは1つのものではなく、部品の集合
ここまで来ると、ハーネスを「あのループ」だと思い描いているかもしれません——それは少し違います。ループはその中心的な部品ですが、ハーネスは複数のコンポーネントが協働する集合体です。ロードマップはそれを和集合として説明しています: "the harness is the union of:"（ハーネスは次のものの和集合である）——ループ制御、ツールディスパッチ、コンテキスト管理、その他3。今は顔ぶれを知っておけば十分です。以降のレッスンで1つずつ分解します:
- ループ制御。ロードマップでは "loop control. The while-loop driving model→tools→model."（ループ制御。モデル→ツール→モデルを駆動するwhileループ）と説明されています3。モデルが返した
stop_reason を読み、このターンの次にもう1ターンが続くのか、それとも停止なのかを決めます。これはハーネスの心臓部であり、レッスン2はまるごとこれに充てられます。
- ツールディスパッチ: モデルが「このツールをこのパラメータで呼べ」と提案したあと、そのリクエストを本物の関数にルーティングし、実行し、出力を
tool_result に詰め直すコードです。その1ステップ分は前に学びました。ハーネスがやるのは、それをループに配線し、何度も繰り返し使うことです。
- コンテキスト管理: ループが1回転するたびに会話にデータが積み上がります。なぜなら "An agent running in a loop generates more and more data that could be relevant for the next turn of inference"（ループの中で動くエージェントは、次の推論ターンに関係しうるデータをどんどん生成する）4 からです。そしてモデルの注意はタダではありません: "LLMs have an "attention budget" that they draw on when parsing large volumes of context"（LLMは大量のコンテキストを解析する際に引き出す「注意の予算」を持っている）4、そして "Every new token introduced depletes this budget by some amount"（新しく導入されたトークンはそれぞれ、この予算をある程度消費する）4。ですからハーネスは、その履歴をどこに置き、どれだけを残すかを、膨れ上がるに任せるのではなく決めなければなりません。
さらに2つの部品は、このコースの後半でまとめて扱います。ここでは、それらもハーネスに属することがわかるように名前だけ挙げておきます:
- 停止条件:
stop_reason に従うことに加えて、"it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control."（制御を保つために、停止条件（最大反復回数など）を含めることもよくある）2 いつ打ち切るかはレッスン3の主題です。
- 暴走の歯止めと人間の介入: ループは長い区間にわたって回り続けることがあり、"The LLM will potentially operate for many turns, and you must have some level of trust in its decision-making."（LLMは多数のターンにわたって動作する可能性があり、その意思決定にある程度の信頼を置かなければならない）2 ただし信頼は白紙委任と同じではありません——"Agents can then pause for human feedback at checkpoints or when encountering blockers."（そのうえでエージェントは、チェックポイントで、あるいは障害にぶつかったときに、人間のフィードバックを待って一時停止できる）2 デッドループ、空回り、予算バーンアウトをどう捕まえるか（レッスン4）、そして実行の途中で人間がどう割り込んで方向を変えるか（レッスン5）は、どちらもこの層の話です。
各部品の詳細を今すぐ暗記する必要はありません。全体の形だけ押さえてください: ハーネスとは、モデルの周りにある制御コードの総称であり、いくつかの部品が組み合わさって、このエージェントがどれだけ安定して動くかを決めている。 これは、ハーネスを取り替えると結果がこれほど変わる理由の説明にもなっています——取り替えたのはコード1行ではなく、ループを制御する戦略まるごとだからです。
この制御層が本当に必要になるとき
ハーネスがこれだけのことを面倒みられるとわかると、逆の極端に振れやすくなります: モデルを使うたびに、ループ制御と承認弁と空転検出まで揃った一式が必要なのでしょうか。いいえ。
エージェントとワークフローの線に戻りましょう。タスクが決まった道筋をたどるなら——チケットが来て、分類され、カテゴリごとに振り分けられる——そしてすべての分岐を事前に決められるなら、それはワークフローであり、"through predefined code paths"（事前定義されたコードパスを通じて）2 オーケストレーションすれば十分です。モデルにループの中で制御フローの決定をさせる理由はありません。そこに自律的なループを取り付けても、脱線する機会が増えるだけです。
本当に完全なハーネスを必要とするのは、ステップ数と道筋を事前に言えないタスクです: 何個のファイルを変更する必要があるのか、どれを最初に読むのか、あるステップの結果によって前のステップをやり直すことになるのか。それらは、現在の状態を見ているモデルにしか決められません。そういうときこそ、ループの中でモデル自身に決めさせつつ、しっかり制御下に置いておくハーネスが欲しくなります。一般的な自制として、次の一節は覚えておく価値があります: "you should consider adding complexity only when it demonstrably improves outcomes."（結果が明らかに改善される場合にのみ、複雑さを追加することを検討すべきである）2 ハーネスの中の制御ロジックは1つ1つ、実際に制御を失う問題にぶつかったからそこにあるべきで、みんながそう作っているからではありません。
このコースの残りは、その2種類目のタスクで最も重要になり、最も頻繁に壊れる部分——ループそのもの——に焦点を当てます。エージェントが頼れるかどうかをハーネスが決め、そのハーネスの心臓がループ制御である以上、次のレッスンは、そのループが1回の往復から回り続けるものへとどう育つかから始めます。
まとめ
- ハーネスとは、モデルの周りにある制御コードの総称です——ツールを実行し、ループを駆動し、いつ停止していつ人間を待つかを決めます。モデルは次のアクションを提案するだけで、そのアクションが実行されるか、ループが続くかを裁定するのはハーネスです。1
- エージェントとは、環境からのフィードバックに基づいてループの中でツールを使うLLMです。2 ワークフローとの違いはモデルの強さではなく、誰が制御フローの決定を下すかです: ワークフローは事前定義されたコードパスをたどり、エージェントの次のステップはループの中でモデルが決めます。2 そしてそのループを担うものがハーネスです——エージェントは、ループの中で自分自身の制御フローの決定を下します。3
- Same model, different harness, completely different result.（同じモデル、違うハーネス、まったく違う結果）3 ですからエージェントが信頼できないときは、まずハーネス層を確認してください: ターン数の上限、進捗なしの検出、影響の大きいアクションへの承認は、たいてい強いモデルより多くを直します。
- ハーネスは単一の物体ではなく、部品の集合です: ループ制御、ツールディスパッチ、コンテキスト管理が、それぞれ自分の仕事を持っています。3 特にコンテキストは管理が必要です。ループが1回転するたびに会話にデータが積み上がり、有限の注意の予算を削っていくからです。4
- すべての状況が完全なハーネスを必要とするわけではありません。 道筋が固定されたタスクはワークフローで十分ですし、2 ステップと道筋を事前に言えず、モデルが本当に自分で決めなければならないときにだけハーネスに手を伸ばし、結果が明らかに改善される場合にのみ複雑さを追加してください。2
>> レッスン2: コアループ: 一度の往復から継続的な運転へ