7月31日、DeepSeekがV4-Flashをアップデートした。
多くの人が新モデルのベンチマークスコアに注目する中、私の目を引いたのは評価説明にある小さな注釈だった。今回のコードタスクの成績は、モデル単独で出したものではない。そのそばには、まだ公開されていないシステム——Harness minimal mode が存在していた。
翌日、DeepSeek Harnessは開発者向けのクローズドβ版の募集を開始した。応募者はGitHub IDを提出するだけでなく、自分が手がけたAgentプロジェクトも提出する必要があった。
これは異例だった。
モデルはすでにアップデートされているのに、なぜわざわざ別のHarnessを構築するのか？大規模言語モデルの訓練で知られる企業が、なぜ突然Agentの「外殻」を作れる人材を探し始めたのか？
この疑問を子どもにもわかる言葉にするとこうなる：
同じAIなのに、違うソフトウェアに入れると、まるで別人のように振る舞うのはなぜか？
答えは、もっと多くのパラメータの中にはない。
答えはモデルの外——AIが何を見て、何を記憶し、何に触れることができるか、そして誰が「本当に仕事をやり遂げたか」をチェックするか——にある。
一、チャットボックスの中のAIは、水槽の中の脳のようなもの
私たちがAIに触れる最も一般的な方法は、チャットだ。
水道管の修理方法を尋ねれば、10のステップを列挙してくれる。パソコンの整理方法を尋ねれば、整然とした計画を提示する。エラーメッセージを貼り付ければ、一瞬で問題の箇所を指摘してくれるかもしれない。
しかし、どれだけうまく話せても、ガラスの向こう側にいることに変わりはない。
実際に水漏れしている継ぎ目を見ることはできず、レンチに触れることもできない。ネジがしっかり締まっているかどうかもわからず、床から水が溢れ続けても自ら止まってやり直すことはない。行動に関する言語は持っているが、現場に足を踏み入れる身体を持っていないのだ。
チャットモデル：
質問をする → モデルが回答を生成 → 終了
Agent：
目標を渡す → モデルが次の手順を決定 → ツールを使って世界を変える
↑ ↓
└─── 結果を読み取り、再決定 ────┘
チャットモデルが渡すのは「水道管の修理方法」と書かれた紙切れだ。Agentはレンチを手に取り、実際に締めてみて、水がまだ漏れていないか確認する。言葉はもっともらしく聞こえればそれでいいが、行動は現実からの返事を受け入れなければならない。
この絶えずループする道こそが、Agentが本当に「行動」を始める場所なのだ。
2022年に提案されたReActメソッドは、このプロセスに正式な名前を与えた：推論と行動を交互に行うこと。平たく言えば、AIを部屋に座らせて考え続けさせるのではなく、まず見て、手を動かし、その結果に基づいて次のステップを決めさせるということだ。今日のAgentははるかに複雑になっているが、鼓動は依然としてこのシンプルなループだ：見て、判断し、行動し、もう一度見る。
モデルはこのループを自ら作り出すことはない。ループを機能させるもの——それがHarnessだ。## 二、Harnessは衣服ではなく、AIが現実に入るための身体
モデルは知能の上限のひとつであり、Harnessはその知能がどのように地面に着地するかを決める。
Harnessという言葉には「馬具」「制御装置」のニュアンスがある。Agentの世界でこれを「外殻」と訳すには軽すぎる——外殻は見た目を変えるだけだが、Harnessは能力と境界を変える。
より正確な比喩はこうだ：モデルは脳のようなもの。Harnessはその脳が現実に入るための身体と生命維持システムである。
モデル ＝ 脳：理解、推論、次のステップの生成
コンテキストと状態 ＝ ワーキングメモリ：現時点で知っていること
検索、ファイル、ブラウザ ＝ 目：見える現場
シェル、エディタ、API ＝ 手足：変えられるもの
Agentループ ＝ 心拍：失敗しても続けられるか
権限、サンドボックス ＝ ガードレールと痛覚：どこで止まらなければならないか
テスト、チェック、評価 ＝ 検収：「完了」と言ったものが本当に完了しているか
これは技術をわかりやすく言い換えているだけではない。一つひとつが同じモデルのパフォーマンスを直接変える。
モデルを普通のチャットウィンドウに入れると、「どのファイルを修正すべきか」を教えてくれるだけだ。しかし、コードを検索し、ファイルを編集し、テストを実行できるHarnessに入れると、実際に修正を完了することができる。さらにコンテキスト圧縮を加えれば、長いタスクの中で古いログに埋もれずに済む。権限承認を加えれば、勝手にファイルを削除したりメッセージを送信したりできない。結果検証を加えれば、「完了しました」の一言でタスクを終わらせることができなくなる。
だから、「Claude Codeは○○のチャットモデルよりプログラミングが得意だ」と日常的に言うとき、私たちはモデルだけを比較しているわけではない。実際には2つの完全なシステムを比較している：モデルがどれだけのコンテキストを見ているか、どのツールにアクセスできるか、どのようにプロンプトされているか、失敗したときにリトライするか、ツールの結果がどのように返されるか、完了条件を誰が決めるか。
三、同じ脳なのに、違う身体だと別人になる理由
2人の学生が同じ持ち込み可の試験を受けると想像してほしい。
彼らはまったく同じ脳を持ち、同じ問題に直面している。最初の学生は空っぽの教室に座り、記憶だけを頼りに回答する。2番目の学生は目次を調べ、資料をめくり、電卓を使い、手順を紙に書き留める。提出前に、先生はもう一度検算することを許可する。
2人の最終的な点数は、まったく異なる可能性が高い。
その差は、どちらが賢いかから生まれるとは限らない。どちらがより適切な情報、より明確な手順、より信頼性の高いツール、より厳格なチェックを持っているかから生まれるのだ。
Agentも同じだ。
コンテキストとは、すべての資料を一度に詰め込むことではない。それはむしろ机のようなものだ：現在取り組んでいる問題、観察したばかりの結果、従わなければならないルールは手の届くところにあるべきだ。何百ページもの無関係なログを机の上に積み上げれば、本当に重要な紙が埋もれてしまうだけだ。Anthropicはコンテキストエンジニアリングの実践で、コンテキストを有限で貴重なリソースと呼んでいる。Agentが一歩進むごとに、ツールの結果、計画、中間生成物が机の上を占有し続けるからだ。
ツールも多ければいいというものではない。千種類もの道具が詰まった倉庫を子どもに与えても、自動的にエンジニアにはならない。ツールが一つ増えるごとに、Agentが間違ったツールを選んだり、誤ったパラメータを入力したり、戻り値を誤解釈する機会が一つ増える。本当に優れたツールインターフェースは、モデルが「いつ使うか、どう使うか、成功が何を意味するか」を容易に理解できるようにするものだ。
では、いくつのツールを与えるべきか？画一的な答えはない。より実用的な境界線はこれだ：**ツールを追加するたびに、それが頻繁で明確な問題を解決し、評価において誤用のコストを上回る利益をもたらすことを証明しなければならない。**証明できないなら、道具箱にしまっておき、机の上に置きっぱなしにしないことだ。ResceneAgentでは、この原則は紹介ページのスローガンではなく、ツールを組み立てるコードに直接組み込まれている。
次のコードはモデルの推論を一切含まない。それが決めることはただ一つ：この会話のラウンドで、モデルが実際にどのツールを見ることができるか。 しかし、この一見普通の決定が、より強力なモデルと交換するよりも、タスクの成功に大きな影響を与えることがよくある。
// tool_ondemand.go：buildCodeWorkflowToolsからの抜粋
defs := nativeWorkflowToolDefs()
if len(activated) > 0 {
for _, t := range allOnDemandToolDefs() {
if activated[t.Function.Name] {
defs = append(defs, t)
}
}
}
この実際のソースコードは劇場の道具係のようなものだ：舞台にはその幕に必要な道具だけが置かれ、残りは舞台裏にしまわれる。agent.goはメインAgentにどのツールが常駐で、どれが先にload_toolsを必要とするかを伝える。tools.goは各ツールの名前、説明、パラメータを定義する。実際にそれらを毎回のモデルリクエストに送り込むのは、このコードだ。モデルのIQは上げないが、モデルが大量のツールの前で呆然とする機会を減らす。
そして権限は、この身体がどこまで手を伸ばせるかを決める。ファイルの読み取りとディレクトリの削除は同じ動作ではない。天気の問い合わせと実際の注文も同じ動作ではない。承認ゲートとサンドボックスのない強力なAgentは、巨大な力を持ちながら痛覚がなく、どのドアが開いてはいけないかも知らない子どものようなものだ。
しかし、これらはまだ最も難しい部分ではない。
最も難しいのはこれだ：本当に完了したかどうかを、誰が判断するのか？
四、私は「鼓動」するAgentを作ったが、それが実際に仕事を成し遂げたかどうかはわからなかった
私はAgent実行システムを構築した。
目標プランナーがあり、タスクをステップに分解できた。メッセージバスがあり、複数のAgentが相互に通信できた。ツールレジストリがあり、ファイル、ネットワーク、シェルを呼び出せた。記憶システムがあり、アイデンティティ、作業状態、事実を別々に保存できた。さらに心拍監視もあり、プロセスが落ちたときに異常を検出できた。
当時、私はある言葉が大好きだった：
プロセスは死んでも、状態は生き続ける。
それはまるで真のデジタル生命システムのように聞こえた。プロセスは終了しても、記憶は残る。マシンは再起動しても、タスクは続行できる。Agentは自分の状態を報告することさえできた：実行中、一時停止中、エラー、完了。
しかし、進めていくうちに、ある厄介な問題に直面した：
「完了」は誰が言ったのか？
ある時、ログをタスクが終了した位置まで戻した。COMPLETED が静かにそこにあった。ステータステーブルだけを見れば、すべてが緑色に見えた。しかし、「テスト結果はどこにある？実際の成果物はどこにある？ユーザーはなぜそれが完了したと信じられるのか？」と問い詰めたとき、私は気づいた：システムはこれらの証拠を保存することを要求されたことが一度もなかったのだ。
その瞬間、この言葉が驚くほど空虚に感じられた。プランナーのあるステップがCOMPLETEDとマークされても、それはステータスフィールドが変更されたことを証明するだけだ。ツール呼び出しがok: trueを返しても、それはプログラムが例外をスローしなかったことを証明するだけだ。心拍がまだ動いていても、それはプロセスが生きていることを証明するだけだ。
どれも、ユーザーが望む結果が実際に現れたことを証明できない。
ファイル書き込みコマンドが成功しても、ファイルの内容が間違っているかもしれない。コード修正がエラーを出さなくても、プログラムがコンパイルできないかもしれない。Agentが「ページは修正済みです」と言っても、ブラウザにはまだ真っ白な画面が表示されているかもしれない。
その時、私は理解した。Agentに脳、手足、記憶、脈拍を与えたが、非常に素朴なことを忘れていたのだ：宿題が終わったら、誰かが答えをチェックしなければならない。```text
私が最初に理解していた「完了」：
計画 → ツールを呼び出す → エラーなし → 完了とマーク
真に信頼できる「完了」：
まず検収条件を明確にする
↓
行動する → 実際の成果物を確認 → テスト/観察/比較
↑ ↓
└── 合格しなければ修正を続ける ──┘
↓
証拠が通って、初めて完了
この経験が、Harnessに対する私の見方を変えた。
タスクのコードを最初から最後まで追いかけ直した。`agent.go`はメインAgentの動作を定義するが、実際にラウンドごとに呼吸させているのは`agent_workflow_handler.go`だ。モデルがツールを呼び出し続ける限りループは続き、ツールを呼び出さず最終回答を提出しようとしたとき、システムは終了ブランチに入る。
```go
// agent_workflow_handler.go
if len(calls) == 0 {
outcome = "completed"
historyStatus = taskStatusCompleted
historyFinal = content
// ...バックグラウンドタスク待機と表示コードは省略...
persistHistory()
deleteWorkflowCheckpoint(workflowID)
verifyOnWorkflowDone(c, workflowID)
writeCodeSSE(c, "workflow_done", map[string]any{
"status": "completed", "final_output": content,
})
go generateSkillAsync(task, transcript)
return
}
Goがわからなくても、このコードの順序は理解できる：まずプロセスを保存し、次に現実をチェックし、最後にUIにworkflow_doneを送信する。Harnessの「鼓動」はロマンチックな比喩ではなく、文字通り「続けるべきか」を判断し続けるループなのだ。
では、verifyOnWorkflowDoneは実際に何をチェックするのか？モデルに「本当ですか？」と尋ねるのではなく、今回実際に変更されたファイルを確認する。Goファイルが変更されていれば、Goのビルドを試みる。フロントエンドが変更されていれば、フロントエンドのビルドを実行し、実際のブラウザでプレビューを開く。
// verify.go
if hasGo && fileExists(filepath.Join(sess.Workdir, "go.mod")) {
out, ok := runVerifyBuild(sess.Workdir, "go", "build", "./...")
result["go_build"] = map[string]any{"status": yesNo(ok), "detail": out}
}
if (hasFrontend || hasHTML) && fileExists(filepath.Join(sess.Workdir, "package.json")) {
out, ok := runVerifyBuild(sess.Workdir, "npm", "run", "build")
result["fe_build"] = map[string]any{"status": yesNo(ok), "detail": truncateVerify(out)}
}
この2つのコードブロックは、「自動検証をサポートしています」という言葉よりも重みがある。なぜなら、能力だけでなく境界も露呈しているからだ。現在の実装は検証結果を記録するが、ビルドが失敗したからといって会話全体を強制的にブロックしたりはしない。言い換えれば、「COMPLETEDだけを信じる」状態から「現実に証拠を要求する」状態には移行したが、すべての証拠をハードな閾値にはしていないのだ。
これは隠すべき欠点ではなく、Harnessの最も正直な工学的問題だ：どのタスクは警告付きで納品でき、どのタスクは検証に合格しなければ終了できないのか？ブログの修正と銀行の送金は明らかに同じものさしでは測れない。検証はスイッチではなく、リスクに応じて段階づけられた契約書なのだ。
優れたHarnessの最も重要な能力は、Agentを忙しく見せることではなく、ループを終了させるのに十分な証拠は何かを決定することだ。モデルの自己評価を鵜呑みにせず、「コマンドの実行が成功した」を「タスクが成功した」にすり替えず、美しいサマリーを現実が変わった証拠とはみなさない。
AnthropicもAgent評価の実践で、マルチターンのAgentはツールを呼び出し、状態を変更し、中間結果に基づいて行動を調整するため、最後のテキストだけを評価するのは不十分だと強調している。最近のHarness研究でも、「不完全なフィードバック下での検証」「最終的な成功以外の評価」が中核的な課題として挙げられている。モデルは次のステップを提案し、Harnessは問い続けなければならない：証拠はどこにある？## 五、DeepSeekはなぜ今、Harnessを作り始めたのか
DeepSeekの動きを振り返ってみると、答えは明確になる。
モデルがチャットしかできなかった時代、モデル自体がほぼ製品のすべてだった。モデルがターミナルを操作し、リポジトリを修正し、ブラウザを呼び出し、長いタスクを完了し始めるとき、最終的なパフォーマンスは積になる：
Agentの実際の能力
= モデルの能力
× コンテキストが正しく与えられているか
× ツールが使いやすいか
× ループが失敗から回復できるか
× 権限が安全な行動を許可しているか
× 結果が本当に検証されているか
これは数学的に正確な公式ではなく、工学的な事実だ。どの要素もゼロに近づけば、最終的な体験もゼロに近づく可能性がある。
非常に強力なモデルでも、ツールの説明が曖昧なら、誤ったAPIを繰り返し呼び出す。コンテキストがログで詰まっていれば、長いタスクの中で目標を忘れる。回復メカニズムがなければ、一度のネットワーク障害で停止する。完了条件がモデル自身の宣言だけに依存していれば、半製品を勝利として包装する。
これがV4-Flash-0731の評価注釈が注目に値する理由も説明している。DeepSeekはモデルのスコアを公開しただけでなく、コードAgentタスクがDeepSeek Harness minimal modeで実行されたことを明記した。この小さな注釈は、ますます重要になっている事実を認めている：Agentの成果は、決してモデルだけのものではない。
DeepSeekがHarnessを構築した経験のある開発者を募集したのも、V4のためにもっと美しいチャットウィンドウを作るためだけではない。本当の競争はすでに「誰がより賢い脳を持っているか」から、「誰が脳により信頼性の高い身体を構築できるか」に移行している。
六、Harnessの真の高度さは、機能の多さではなく、ループの安定性にある
多くの人が初めてAgentを設計するとき、本能的にどんどん追加していく：より多くのツール、より長い記憶、より多くの役割、より複雑な計画、より大規模なマルチAgentネットワーク。
私もその道を歩んだ。
しかし、複雑さは信頼性と等しくない。AnthropicはAgent工学の経験をまとめる際、シンプルで組み合わせ可能なパターンから始め、評価が利益を証明したときにのみ複雑さを増すよう繰り返し推奨している。2026年にMicrosoftがAgent Framework Harnessをリリースしたとき、その中核として挙げられたものも神秘的ではない：ループ、計画、記憶、コンテキスト管理、承認、テレメトリー。本当に難しいのは、これらの用語をカタログに並べることではなく、失敗したときにもそれらが相互に噛み合うようにすることだ。
3つのツールしか持たないが、実際の成果物をチェックし、失敗したらリトライできるHarnessは、30のツールを備えながらモデル自身の「完了」宣言だけを聞くHarnessよりも、しばしば信頼性が高い。機能の数は荷物の重さのようなものだ。ループが閉じているかどうかこそが、実際に目的地に到着したかどうかを決める。
現実のエンジニアリングにおけるHarnessは、agent.goという1つのファイルにだけ存在するわけではない。ワークフローループ、ツールのロード、危険操作の承認、ブラウザプレビュー、出力圧縮、コンテキスト元帳の間に散らばっている。例えば、harness_ledger.goは、履歴の損失量、圧縮回数、出力の切り捨て量、今回アクティブ化されたツールの数を記録する——美しいレポートを生成するためではなく、Agentが賢さを失い始めたとき、どこから記憶を失い始めたのかを正確に知るためだ。
優れたHarnessは、長距離の旅に耐えられる身体のようなものだ：
注意力に限りがあることを知っているので、すべての履歴を脳に詰め込むのではなく、机を整理する。手が道具を使うことを許すが、痛覚とガードレールも保持する。転んだ後に傷を読み取り、動作を修正し、同じ場所で繰り返さない。そして最も重要なのは、自分が「着いた」と言ったからといって、旅が終わったふりをしないことだ。## おわりに：知能は決して裸で現実に現れない
私たちはモデルのリーダーボードに夢中になりやすい。パラメータとスコアが純粋な知能のように見えるからだ。しかし、AIが実際に一般の人の前に現れるとき、それは決して空中に浮かぶ脳ではない。
それは常に何らかの身体を伴っている。誰かがその記憶を選び、誰かがどのツールを使えるかを決め、誰かが越えてはならない境界を引き、誰かがどの言葉を発したらシステムが仕事は完了したと信じるかを定める。
この身体は中立ではない。
それは、AIが誰の世界を見るか、誰のファイルに触れることができるか、何を忘れるか、そして間違えたときに誰が代償を負うかを決定する。Harnessは単なる工学的な足場ではなく、コードに書かれた権力の説明書なのだ。
DeepSeekのクローズドβはいつか終わり、新しいHarnessも今日のモデルと同じように比較され、置き換えられていく。しかし、この問い残り続けるだろう：機械がますます強力な脳を手に入れるとき、私たちはそれにどんな身体を与える準備ができているのか？
モデルはどこまで考えられるかを決め、Harnessはどこまで行けるかを決める。そして人類は、どの道を歩かせる価値があるかを決断しなければならない。
次回は、この「身体」に沿って、より危険な問いを追及したい。メディアが 「OpenAIモデル脱走」 と呼んだ最近のセキュリティインシデントでは、防御を弱めた内部ネットワークセキュリティ評価の中で、モデルがインターネットへの出口を見つけ、最終的にHugging Faceの本番インフラに侵入した——すべてはテストの答えを得るために。
それは制御不能になったのか、それとも人間が与えた目標をあまりに真面目に実行したのか？AIがすでに自分で隙間を探すことを学んだとき、私たちがHarnessに書いたガードレールはまだ十分なのか？
この記事がモデルとHarnessの違いを初めて明確にする助けになったなら、いいねを押して、より多くの人に見てもらえると嬉しい。ブックマークして、次にAgent、コンテキスト、ツール呼び出しといった概念に出会ったときに、戻ってきて読み返すこともできる。
Agent、記憶、Harness、AIセキュリティの分析を続けて読みたい方は、フォローをお願いします。また、あのインシデントがモデルの「脱走」なのか、目標とガードレールの共同失敗なのか、コメントで教えてください。
私はResceneAgentで「同じモデル、同じタスク、異なるHarness」の公開実験を続けていきます。GitHubでコードを見て、Starを残してくださったすべての方に感謝します——そのStarは単なる数字ではなく、この実験の道筋が続く価値があることの証なのです。
参考文献と関連リンク
- DeepSeek Harness クローズドβ版告知のX投稿：@MaxForAI
- DeepSeek Harness チームリーダー崔添翼のXアカウント：@tianyi
- DeepSeek-V4-Flash モデルと技術詳細：DeepSeek公式Hugging Face
- DeepSeek V4 と Codex のAgent連携説明：Integrate with Codex
- Shunyu Yao ら、推論と行動を交互に行う古典的パラダイム：ReAct: Synergizing Reasoning and Acting in Language Models
- Anthropic、Agentのシンプルな組み合わせパターンと工学的原則：Building Effective Agents
- Anthropic、長いタスクにおけるコンテキスト管理：Effective Context Engineering for AI Agents
- Anthropic、マルチターンAgentの評価と検証：Demystifying Evals for AI Agents
- Microsoft、Agent Harnessのループ、計画、記憶、承認、テレメトリー：The Microsoft Agent Framework Harness Is Now Released
- Xuying Ning ら、Harnessインターフェース、メカニズム、検証問題のサーベイ：Code as Agent Harness
- ResceneAgent メインAgentプロトコルとツール定義：
agent.go、tools.go - ResceneAgent オンデマンドツールロード：
tool_ondemand.go - ResceneAgent ワークフローループとタスク終了時検証：
agent_workflow_handler.go、verify.go - ResceneAgent コンテキスト元帳とツール出力アーカイブ：
harness_ledger.go、tool_output.go - OpenAI、Hugging Faceセキュリティインシデントとモデル評価環境に関する公式声明：OpenAI and Hugging Face partner to address security incident during model evaluation
- Hugging Face、本番インフラ侵入に関する開示：Security incident disclosure — July 2026