Who Runs The Agent — 後編
エージェント性は、モデルを包むコード＝ハーネスに宿る。
では、そのループはどこまで自分で書き、
どこから既製品に乗るのか。
動かしているのは、
中心のモデルではない。
外側のリングだ。
前編の結論はこうだった。モデルはステートレスな「次の一手関数」で、計画も記憶も持たない。「計画→実行→観察→改善」を回しているのは、モデルを包む外側のコード（ハーネス）のほうだ——と。
すると、実務の問いが立つ。各プロバイダは既に何らかのハーネスを取り入れている。だとすると、自分で組もうとしたとき——ハーネスの上に、さらにハーネスを重ねることになるのか。
この記事が答える問い
ハーネスの上に、
さらにハーネスを重ねることになるのか？
結論を先に言う。重なるかどうかは「どの層に乗るか」で決まる。タスクの種類ではない。三章で解いていく。各章は前の章を前提に進む。
Ch.01
ハーネスの「階段」
重なるのはどの層か
Ch.02
買うか、書くか
判断軸はループの性質
Ch.03
2種のクッション
思考と画像生成の違い
動かしているのは、中心のモデルではなく、外側のリング。
前編 — 「次の単語を選んでいるだけ」の先にあるもの の続き
Chapter 01
「ハーネスにハーネス」が本当に起きるのはどの層か。層を三つに分けると、重なる場所と重ならない場所がはっきりする。重なりが起きるのは、このうち一つに乗ったときだけだ。
エージェント的に振る舞うよう事後学習されている。だがこれは「ループ」ではなく、ループに合う形へ研がれた関数の挙動だ。コードとしてのハーネスではない。
tool useの形式、構造化出力、停止理由。ループを回す道具を渡しているだけで、ループ自体は回さない。生のMessages APIは、ツール呼び出しを返すが実行はしない。実行も次の往復も、あなたのコードの仕事だ。＝生APIなら「あなた＝唯一のハーネス」。
コーディングエージェントなどがこれにあたる。ここで初めて「ループが既に存在する」。実行もリトライも繰り返しも、製品の中で回っている。
だから二重ループが現実に起きるのは、③に乗ったときだけだ。①＋②に直接乗る（＝生API）なら重なりはなく、あなたのループが最初で唯一になる。「プロバイダが既にハーネスを取り入れている」と感じるものの正体は、ほとんどが①と②——ループそのものではなく、ループを支える部品と、ループに合うよう訓練された挙動。だからそれを包んでも、定義上は二重ループにならない。
図 A — 上るほど「自分が書く範囲」が縮む
私はどちらもやっている。朝刊エージェント（Lambda＋Claude API）は生API直叩き＝自分でハーネスを書いた、重なっていない。Claude Code は Anthropic のハーネスに乗った＝自分では書いていない。問題は「重なるか」ではなく「どの高度に乗るか」の選択だ。
第1章の結論。重なるのは特化製品（③）に乗ったときだけ。——では、どの高度に乗るかは、何で決めるのか。
Chapter 02
判断軸は「タスクの種類」ではない。そのタスクのループが安定しているか、実行時に形が変わるか——これが乗る／書くを分ける。二つの例が、ちょうど両極になる。
ディープリサーチは、ループの形がどのタスクでもほぼ同じだ（検索→読む→評価→足りなければまた検索→統合）。パターンが安定しているから、特化した完成品にしやすい。だから既製品が成立し、買ってくる選択が合理的になりやすい。
ダイナミックワークフローは、「動的」がまさに、固定ループに収まらないという意味だ。何をするかが実行時の状況で変わるなら、それは既製のテンプレに最も入りにくい部分で、定義上あなたの要件に固有になる。汎用基盤の上に、分岐と状態遷移を自分で書くことになる。
図 B — ループの性質が「乗る／書く」を決める
同じ「ハーネス」でも、左に寄るタスクは乗るもの、右に寄るタスクは書くものになる。判断はタスク名ではなく、ループが反復で固まるか／状況で形が変わるかで引く。
トレードオフは単純だ。生API＝最大の制御、ただしループ・リトライ・コンテキスト管理を自前で再実装。SDK／フレームワーク＝楽だが、相手のループの前提を継承し、自分の要件がずれた瞬間に「相手のデフォルトと戦う」コストが出る。これが"重ねる"の本当の痛みで、ループが二つになって両方をデバッグする羽目になる。
第2章の結論。安定なら乗る、動的なら書く。——では、思考モデルや画像生成で感じる「ワンクッション」は、この階段のどこに足されるのか。じつは別の軸だ。
Chapter 03
ここは混ざりやすい。思考モデルと画像生成では、増える「クッション」の中身がまったく別ものだ。一方は深さ方向、もう一方は横方向のハンドオフ。
シンキングモデルのクッションは、モデルの内側に増える。出力の前に思考トークンを生成してから答える。だがあなたのループから見れば、依然として1回の関数呼び出しだ。「文脈を入れる→（中で考える）→返ってくる」で、往復の回数は変わらない。ハーネスの段は増えていない。増えたのは関数の中の深さで、外の段数ではない。
画像生成は、層が増えるというより、モードが別系統だ。テキストLLM（次トークン予測）と、画像モデル（多くは拡散＝ノイズを消していく。前編で触れた「別系統」）は、そもそも違う仕組み。だから一枚生成するとき、しばしば「LLMが指示を画像モデル用のプロンプトに翻訳→画像モデルが生成」という、別エンジンへの受け渡し（ハンドオフ）が挟まる。境界をまたいでいる。
図 C — 同じ"ワンクッション"でも、軸が直交する
深さ方向（思考モデル）
横のハンドオフ（画像生成）
左は1つのエンジンの中で深くなる（往復は不変）。右は別エンジンへ渡す（段が増えるのではなく境界をまたぐ）。二つの"クッション"は直交する軸で、シンキングは左、画像生成は右。
画像で勝手が違って感じる理由は、層の数ではなく、この境界にある。指示が一度別の表現に翻訳されるので、言葉のニュアンスがそのまま効かない。フィードバックの形も違う——テキストは「次の一語」を連続で調整できるが、拡散は一枚を一気に作るので途中で軌道を細かく直しにくい。
そして決定的なのが前編の検証可能性だ。コードは自動採点できるが、「いい画像か」は自動で点をつけられない。採点表が無いから、テキストで慣れた「対話で寄せていく」やり方で詰めきれない。
Conclusion
三章——階段・買う／書く・2種のクッション——に共通する一点がある。境界はどれも固定ではない。プロバイダはハーネスを上へ食い込ませている（サーバ側でのツール実行、組み込みメモリ、SDKでのループ提供）。ネイティブにマルチモーダルなモデルが普及すれば、図Cの翻訳ハンドオフも消えていく方向にある。
つまり「自分で書く範囲」（図Aのテラコッタの帯）は年々縮み、その分だけ"重ね"や"ハンドオフ"の発生面も動く。固定の汎用原則はない。判断は、再発明の手間 vs フレームワークと戦う手間を、タスクごとに天秤にかけるだけだ。
このループは安定か、
実行時に形が変わるか。
安定なら乗る。動的なら書く。
新しいエージェント案件を見たら、まずこう問う。そして半年ごとに「いま何が既製で降りてきたか」を測り直す。一度引いた線を固定しないこと自体が、原則だ。
前提が動いている注記
この記事の層・製品の地図は、2026年央のスナップショットだ。プロバイダがハーネスを上へ食い込ませる速度は速く、半年で塗り替わりうる。「いま自分で書くしかない範囲」も、来年には製品が降りてきているかもしれない。固有名や境界の位置は前提が動く——だからこそ、結論を「定期的に測り直す」に置いた。
連作: 機械認知 2部作（全2回）