ビッグテックのハーネスエンジニアリング無用論と、無分別なループ次世代論に対する批判

ビッグテックのハーネスエンジニアリング無用論を扱うAI Times の関連記事が掲載された後、複数のテック リーダーが意見を交わしました。Google に続いて OpenAI も次世代モデルが現在のハーネス機能のかなりの部分を吸収できるという旨の発言をしたというレポートでした。

この記事も、その議論に付け加える記事です。結論から言うと、ほとんどのハーネスが無用になるという見通しには同意します。私自身もハーネスエンジニアリング完全解説 — 誕生・概念・格差・未来をすべて一度にの投稿でモデルの弱点を補正するために作られた複雑なハーネスは、モデルが良くなると素早く置き換わると書きました。

しかし、これを根拠にハーネス全体がすぐに不要になると言うなら、ハーネスの本質を見落としてしまいます。モデルが機能を吸収する問題と、人間と組織が AI に仕事を任せながら責任を管理する問題は異なります。

まず、キーワードが流通する方式を見る必要があります

しかし、まずテックキーワードは国内が海外と異なる方式と意味で消費される場合が多かったため、これに対する検証を先に行いました。今回も、元々の発言、実際の技術議論、国内で作られたフレームを分けて見る必要があります。

ハーネスエンジニアリング完全解説 — 誕生・概念・格差・未来をすべて一度にの投稿からのハーネスエンジニアリング キーワードの国内とグローバルな消費比較です。

今回も拡大解釈するのには少し慎重な点は、英語圏で harness is dead や harness is useless が広く流通するスローガンという根拠が明確ではなかったということです。モデルのツール使用能力が良くなり、一部のスキャフォルディングがモデルまたはプラットフォーム内に吸収され、手作業で積み上げた複雑な調整レイヤーの寿命が短くなる可能性があるという議論がより近いです。Noam Brown 副社長の発言も、私が直接元出所まで確認したものではなく、国内外のレポートを通して接したものです。そのため、国内で素早く固定化した「ハーネス無用論」フレーム自体を検討してみます。

消えるハーネスと残るべきハーネスは異なります

消えるハーネスは明らかです。プロンプトを複数段階に分割しなければならない方式、特定のモデルの欠陥を回避するための一時的なルール、ツール呼び出しの順序を人間が無理に固定した浅い作業フロー は、モデルが良くなるほど吸収される可能性があります。このようなハーネスは消えるのが正しいです。

しかし、A2Sys の이동수 CEO の整理のように、これをすべてのハーネスに拡大解釈するのは危険だと思います。整理すると以下の通りです。

• プロンプト・作業フロー ハーネスはモデルに吸収される可能性があります。同意します。
• ツール実行ハーネスは権限、承認、失敗復旧を扱います。これが本当に消えるハーネスでしょうか？
• ランタイム・メモリ・インフラ ハーネスはコンテキスト、キャッシュ、モデルルーティング、コスト、遅延時間、監査ログを扱います。これもまた消えるハーネスとは見なしがたいと考えます。

私が『ハーネスエンジニアリング：Re:ゼロから始まる AI ソフトウェア工学』第 7 章から 11 章で述べたハーネスの核もここにあります。契約は許容範囲を定め、構造と隔離は変更範囲を狭め、追跡性と検証は元々の目標と実際の結果を結びつけました。測定と運営はコスト、権限、障害、復旧を管理します。この範囲のハーネスエンジニアリングはモデルが良くなっても解決されない部分です。

一方、ハーネス、ループ、プロンプト エンジニアリングが人間のヒューリスティックであるという主張も正しいです。すべての方法論はヒューリスティックから始まります。型、テスト、CI、コード レビュー、権限分離もすべて、人間が複雑なシステムを扱うために作った方法です。しかし、ここでより重要なのは、透明性と責任までフラッグシップ モデルに任せられるかということです。仕事を任せたなら、ちゃんと意図どおりに仕事をしているか、責任を超えて問題を起こすことはないか は、AI 自身ではできません。もちろん、これを監視して補正する AI があるかもしれませんが、そうするとそれがハーネスです。

한상기 教授のコメント欄で、私はこの立場をこう書きました。

ハーネスエンジニアリングをどこまで見るかによって異なるようです。組織と開発者の意図がある限り、なくなることは難しいと見ています。

モデルがより賢くなるほど、AI がより奇妙なことをより素敵に最後まで作る可能性も一緒に大きくなります。だからハーネスはモデルの弱点補正装置ではなく、方向と責任を固定する運営装置です。

実際の運用では、モデル能力より責任の境界が先です

Nextain は開発受託企業と Discord で仕事を進めています。そして今日、私はここに特定のイシューを解決していた Claude Code のエージェントを入れました。Discord に参加した Nextain エージェント（実は サーバーに置かれた Claude Code）が Discord チャネルを読んで返答します。

当該チャネルにいた非開発者の運営者がテスト結果と不足点と要件を伝えました。そしてここに対して処理できることを処理していたのですが、重要な配置や触ってはいけないリソースを修正する必要がある場合、私の承認が必要なことは私に許可を求めます。

また最初に投入したので要件を聞いてすぐに仕事を始めるため、指示した人の立場からはもどかしがっています。業務プロセスを指示しました。要件を聞いたら聞いたと返信して、分析を進めて計画を立てた後、計画を再度 Discord チャネルに報告して、作業を進めてください。そして最後に作業が完了したら最終報告を出して、万が一途中で問題が生じたら、私（開発リーダー）を呼び出して、判断が必要なことは Discord で聞いてみてください。と指示しました。

このハーネスの核は Nextain の開発プロセスと各構成員の権限です。これがフラッグシップなら、勝手に最善の方法で仕事をするでしょうか？最善の方法が本当に 1 つですか？組織と業務プロセスの一貫性とは、結局のところハーネスです。この責任の境界はモデルの能力とは別です。モデルがより多くの仕事をできるようになるほど、何をしてもよいかとどこで止めるべきかはより厳格に分ける必要があります。

現業の問題はドリフトとコストです

現業で Codex と Claude を使う開発者が直面する問題は、相変わらずドリフトです。目標を絞っても別の道に漏れ、するなと言った変更をして、テストを変えて通ったと言い、運営権限の境界を見落とします。モデルが精巧になるほど、この問題はより滑らかに隠れる可能性があります。

この時「もっとたくさん回せばいい」という答えはビッグテックには可能です。推論時間を増やして、候補をもっと作って、失敗した経路を捨てて、外部検証を付けることができます。しかし、現業の開発者と 1 円を節約する必要があるスタートアップはそうはできません。国内企業の現実も同じです。

上にリンクを張った한상기 教授とのコメント欄で、하정우 前 AI 未来企画秘書官が言及された「トークン総コスト効率性」がまさにこの基準です。ハーネスはフラッグシップ モデルを否定する装置ではありません。高いモデルを本当に必要な判断にだけ使って、反復可能な仕事は小さなモデル・ローカルツール・スクリプト・決定論的検証器に分離するためのコスト制御装置です。

最近発表された OpenAI の数学関連の成果も 2 つの時点で区別する必要があります。私はErdős 平面単位距離問題の反例に関連した最初の成果は、既存のアプローチと異なる数学的な接続を見出した可能性として高く評価します。AI だけが出せる新しい発見の可能性を示した事例だからです。

反面、その後より注目されたテスト時間コンピューティングは、推論時点でより多くの演算と候補探索、検証、反復を投じる方向です。これも重要な技術です。しかし、それをモデル 1 つの純粋な知能向上としてのみ言うなら、コスト構造が消えます。物量作戦も技術ですが、ビッグテックに特に有利な技術です。

ハーネスはコストとデータの防線です

「モデルがハーネスを食べ尽くすだろう」という言葉は刺激的です。しかし、そのモデルを誰がいくらで使うかは別の問題です。モデルがより多くの機能を吸収するほど、ユーザーのコードはシンプルになる可能性があります。同時に、より重く、より高いモデル呼び出しに依存するようになるかもしれません。複雑性が消えるのではなく、ユーザーの作業場からモデル提供者の課金レイヤーに移動しているのです。

データも同じです。エージェントが本当に有用になるには、ドキュメント、コード、スケジュール、メール、運営ログ、障害履歴、決裁フロー、顧客データを見る必要があります。エージェントが作業場になった瞬間、ユーザーの仕事全体が入力になります。

良いハーネスは必要なコンテキストだけを外部モデルに送って、残りはユーザーの作業場に残します。モデルをルーティングして、キャッシュを再利用して、権限を分割して、再現可能な検証を付けます。だからハーネスはコスト防線であり、データ防線です。

この観点から見ると、グローバル モデル企業が強いユーザー側のハーネスを不便に感じる可能性もあります。ユーザーが先に小さなモデルとローカルツールで処理して、必要な瞬間にだけフラッグシップを呼び出すなら、呼び出し量と送信されるコンテキストが減ります。これは事実、単定ではなく、フロンティア モデル開発・推論・GPU・電力コストが大きくなる業界構造では、自然に検討する必要な利害関係です。

OpenAI と Anthropic はCodexとClaude Codeを通じてハーネス競争の最前線にあります。一方、Google はモデル企業でありながらクラウド事業者でもあります。企業ごとに全く同じ利害関係だと言うことはできませんが、この論争を純粋な技術予測としてのみ聞くのが難しい理由は明らかです。良いハーネスはビッグテックが望む「作業場をモデルに移してデータを収集したい欲望」と「フラッグシップ使用依存」を減らしてしまいます。

ループは次世代のデフォルト値ではありません

ループも同じです。私はループを使っていますが、ほとんどのミッションにはループを使わない方が正しいと見ています。一般の開発者に任せても適切な結果が出せる仕事なら、良いモデルを 1 回ちゃんと使う方がより安く、速い可能性が大きいです。意外にループが効果的なケースは限られています。

1 つ目は研究開発です。正解がなく、実験結果に応じて仮説が変わり、次の実験が前の結果を読んで能動的に変わる必要がある仕事です。社内で進める音声・歌唱研究がそうです。この場合、実験結果と全体データを複数の AI が検討して、既存実験との継続性、ドリフト有無、次サイクルの必要性を判断します。完了基準はそれらしい結果ではなく、指標がもう上がらないという判断です。探索の収束が目標だからループが正しいです。

2 つ目は限定された環境で小さなモデルを使う時です。小さな LLM は目標を縮小して「この程度で十分」と止まりやすいです。ただこの場合、必要なのは長いループというより目標と終了条件を締める装置です。ループというより Claude Code の goal 機能に近いハーネスです。一般ユーザーの日常作業にループを濫用すると、コスト浪費になります。ループは探索の収束のために使って、ハーネスは目標と責任を固定するために使います。2 つは置き換え関係ではありません。

Naia はワークスペースをユーザー側に残そうとします

Naia はフラッグシップ モデルを否定しません。開発には クラウドのフラッグシップ を徹底的に活用する予定です。良いモデルは使うべきです。

ただし、すべてのワークスペースとデータをビッグテック プラットフォームに渡す考えはありません。Naia が指向するのはローカル、P2P、オープンウェイト、小さなモデル、決定論的検証器、明示的権限ハーネスを一緒に使う構造です。高いフラッグシップは必要な判断に使いますが、基本ワークスペースはユーザーの手に残すべきです。

この点でDeepSeek、Qwen、Kimi、GLM系列のようなオープンウェイト モデルの発展は重要です。目的に応じてモデルを組み合わせ、ローカルでデータを守りながら、必要な瞬間にだけ閉鎖形フラッグシップを呼び出す構成が可能になります。韓国では Upstage や Naver のような独自モデル戦略もこの流れの中で意味があります。グローバル ビッグテックのフラッグシップをそのまま後追いするより、オープンウェイト・独自モデル・特化ハーネス・国内業務コンテキストをよく束ねる道がより現実的かもしれません。

モデルは借りることができます。しかし、ワークスペースとデータまで借りる必要はありません。

結論：無用論より必要なのは技術レベルの議論です

消えるハーネスは消えるでしょう。モデルが吸収する機能も増えるでしょう。この点を否定する理由はありません。しかし、モデルが吸収する機能、組織の意図と責任を固定する実行体系、コストとデータの境界を守る運営体系が消えるとは思われません。AI に仕事をさせる主体が人間であり、結果に責任を持つ主体も人間なら、契約・構造・追跡性・検証・運営は消えません。

これからはハーネスが死んだか生きているかのようなキーワード論争をやめてほしいです。何をモデル内に入れるか、何をユーザーと組織の統制下に残すか、ドリフトをどう検証して巻き戻すか、トークンコストとデータ露出を誰が負担するかのような真の技術中心の議論が先に進むことを望みます。

参考と出典

私の記事と著作

• 『ハーネスエンジニアリング：Re:ゼロから始まる AI ソフトウェア工学』
• 「ハーネスエンジニアリング完全解説 — 誕生・概念・格差・未来をすべて一度に」
• 「ハーネスエンジニアリング」出版ニュース

今回の議論の直接のきっかけ

• AI Times「Google に続き OpenAI も『ハーネス無用論』...次世代モデルが機能を吸収するだろう」
• AI Times「『モデルがハーネスを食べ尽くすだろう...』」
• 한상기 教授の Facebook 投稿とコメント論議
• 이동수 A2Sys CEO「ハーネス無用論？半分正しく半分間違っています」

原文と技術資料

• OpenAI「Learning to Reason with LLMs」
• OpenAI「An OpenAI model has disproved a central conjecture in discrete geometry」
• OpenAI「Introducing Codex」
• OpenAI「Introducing OpenAI o3 and o4-mini」
• Google「Gemini 2.0: our new AI model for the agentic era」
• 「The Interplay of Harness Design and Post-Training in LLM Agents」
• 「More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding」
• 「AutoHarness」