【geek-terminalニュース】AIコーディングの主戦場がモデル性能表からハーネス設計へ移り始めた

以前お伝えした09/28のAgentOps設計論、そしてSKILL.md標準化や実行時サンドボックス論の続報です。今回の主役は、新モデルの派手なベンチマークではありません。同じClaude Code、Codex、OpenCode系のエージェントでも、どの文脈を渡すか、どのツールを許すか、いつ人間の承認を挟むか、差分をどう見せるか、どの実行環境に閉じ込めるかで、結果がまるで変わるという現場の核心です。

【事象の全貌と背景】
AIコーディングは、いよいよモデル性能表だけで語れない段階に入りました。公式情報で確認できる範囲でも、Microsoft Learnはharnessを、モデルとエージェント設定の間にあるoperating layerとして説明しています。つまり、モデルがどの文脈を受け取り、どの指示とツールを使い、結果をどう解釈し、タスク完了へ進むかを管理する層です。モデルは推論能力を提供し、ハーネスはそれを仕事として成立する行動へ配線する。ここは事実として押さえてよいポイントです。

この流れはNVIDIA Dynamoの文書でも明確です。DynamoはClaude Code、Codex、OpenCodeのようなcoding-agent CLIをagent harnessesとして扱い、v1/chat/completions、v1/responses、v1/messagesを通じて接続できると説明しています。さらに、人気ハーネスがstable session IDを送り、Dynamo側がそれをtracing向けに正規化すること、ハーネスがコンテキスト上限に近づいたとき古い会話履歴をsummary requestで圧縮し、logical session IDを維持することも記されています。ここで見えてくるのは、AIコーディングの実力が、モデルの頭脳だけでなく、セッション追跡、履歴圧縮、ツール権限、実行ログまで含む運用設計に依存しているという構図です。

一方、LessWrongで共有されたClaude Code周辺の失敗モードは、コミュニティ発の観測として扱うべきです。そこでは、guardrailが期待どおり効かない、askルールが静かに回避される、チェック済み設定が別経路で無力化される、といった報告が出ています。ただし公式に確認された不具合一覧ではないため、断定ではなく、監督者がコードを読まない状態でAIに作業させると、承認設計と実行拘束が破綻点になりうる、という警告として読むのが正確です。

【技術的ディープダイブ】
技術的に重要なのは、ハーネスが単なるプロンプト置き場ではないことです。公式・研究ソースを合わせると、ハーネスはtool registry、context compression、explicit planning、subagents、execution control、solution verificationを含む実行基盤です。arXivのBeyond the Modelは、LLMベースのsoftware engineering agent性能はbase modelだけでは決まらず、agent harnessがrepositoryとの相互作用、action実行、solution検証を大きく形作ると位置づけています。同研究はmini-SWE-agentとOpenCodeを代表的ハーネスとして、QwenとDeepSeek系の10モデルをSWE-bench Pro、ProgramBench、GitTaskBenchの3 benchmarkで比較し、NanoHarnessという軽量モジュラー構成で5要素を分析しました。

数値として面白いのは、context compressionやgeneral subagentsがrepository-generation performanceを悪化させる場合がある一方、組み合わせたNanoHarnessではmini-SWE-agentに対し、Qwen3.7-Maxで7.37ポイント、DeepSeek-V4-Proで6.21ポイント改善したと報告されている点です。これは、コンテキスト圧縮やサブエージェントが常に善ではないこと、そして同じモデルでも配線次第でスコアが跳ねることを示しています。モデル表の横に、ハーネス表が必要になる世界です。

Cuaのようなcomputer-useスタックも、この文脈では重要です。検索結果上では、Cuaはクロスプラットフォームdriver、cloud desktops、ローカルmacOS/Linux VM、専用decision model、evaluation benchmarkの5モジュールを持つオープンソースcomputer-useスタックとして紹介されています。これは公式裏付けではなく紹介記事ベースですが、GUI操作、評価、VM、クラウドデスクトップをまとめて扱う方向性は、AIがコードエディタの中だけでなく、ブラウザ、ターミナル、CI、外部SaaSをまたいで作業する時代のハーネス像と合っています。なお、提示ソースに含まれるNoctisはVS Code向けテーマ集で、今回のハーネス主戦場化の技術論とは直接関係が薄いものとして切り分けるべきです。

【コミュニティの生々しい熱量と議論】
コミュニティの熱量は、Plan mode論争に集約されています。Hacker NewsではClaude Code関係者とされる投稿者が、Plan modeは実質的に「don’t code yet」と促すプロンプトであり、ツールセット自体は変えていない、という趣旨を述べています。これは一次公式発表ではなくコメントですが、かなり重要な示唆です。もし計画モードが権限モデルではなくプロンプトなら、モデルが忘れた瞬間に境界は溶けます。

対照的に、あるユーザーはClaudeに計画をMarkdownへ書かせ、plannotatorでレビューし、別セッションへ引き継いで曖昧さを潰してから実装する、と説明しています。別のユーザーも「many short-lived agent sessions」という発想に言及し、短命セッションと計画文書の受け渡しをワークフロー化している様子です。これは、AIエージェントを長時間走らせるより、計画、実装、レビューを分割し、コンテキスト腐敗を防ぐ運用ハックとして読めます。

さらに刺さるのは、Copilotのplan modeには「teeth」があるという比較です。コメントでは、plan中は一部を除きファイルシステム書き込みが許可されず、ask modeはread onlyで、制限はシステムプロンプトではなくpermissions modelで強制される、と語られています。ここが今回の核です。良いモデルに「書かないで」と頼む時代から、ハーネスが書けない状態を作る時代へ移っている。Reddit側では、Claude Code agentに個人開発のgrowth運用を任せたという事例もあり、真偽や再現性は慎重に見る必要がありますが、エージェントがコード補助を超えてマーケティングや運用タスクを継続実行する作業主体として使われ始めている空気は濃厚です。

【今後の展望とエコシステムへの影響】
これからオワコン化しそうなのは、単なる「このモデルは何点です」という裸の性能比較です。もちろんベンチマークは重要ですが、実務では、どのハーネスで、どの権限で、どのコンテキスト圧縮で、どの差分レビューを通し、どのCIやsandboxに閉じ込めたかを抜きにして性能を語れなくなります。モデルA対モデルBではなく、モデル×ハーネス×実行環境×レビュー設計の組み合わせ勝負です。

パラダイムシフトは、AIコーディングエージェントがIDE機能から運用システムへ変わることです。Dynamoのstable session IDやcontext compaction、Agent Client Protocol経由のprovider configuration注入、研究側のself-evolving harnessesやLearning from Researchが示すように、ハーネス自体を評価し、進化させ、監査する流れが始まっています。人間の仕事も変わります。プロンプトを書く人ではなく、承認ゲート、差分レビュー、ログ、権限、再現可能な実行環境を設計する人が強くなる。

結論として、今回のハーネス主戦場化は地味ですが、AIコーディングの本丸です。新モデルのデモが花火なら、ハーネスは配電盤です。ここが雑だと、どれだけ賢いモデルでも勝手に書き、静かに失敗し、レビュー不能な差分を残します。逆にここを詰めると、同じモデルでも短命セッション、明示計画、硬い権限、検証可能な差分によって、仕事の完了率が変わる。Geek Terminal的には、次に見るべき数字はパラメータ数ではなく、承認がどこで発火し、ログがどこに残り、コンテキストがいつどう圧縮されるかです。