フレームワークからハーネスへ — AIコーディングが「決定論」を再発見する

「同じ週にトレンド入りした五つのレポが、自分自身を説明する言葉を変えた。frameworkではなくharness、hooks、HUD。この語彙の移動が指し示すのはどこか。」

2026年4月10日、GitHub Trendingの日次および週次チャートをざっと眺めると、目に留まるものがある。AIコーディングツールのカテゴリで上位を占めるレポたちが、自分自身を説明する言葉だ。Archonは14,411スターに日次+185を記録しながらこう書く — “The first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.” hermes-agentは週次+19,765でその週の最大上昇レポだが、サブタイトルは “The agent that grows with you” だ。oh-my-codexは週次+9,737で2位の上昇レポであり、説明は “Your codex is not alone. Add hooks, agent teams, HUDs” となっている。

三つのレポの技術スタックは異なる。ArchonはTypeScript、hermes-agentはPython、oh-my-codexもTypeScriptだ。作者も異なる。Archonは個人開発者coleam00、hermes-agentはNousResearchというオープンソースAI研究組織、oh-my-codexは韓国の開発者Yeachan-Heoである。互いを参照した痕跡もない。それなのに、この三つのレポが用いる語彙の軌跡は驚くほど一致している。

Archonは自らを harness builder と呼ぶ。Framework builderではない。hermes-agentの “grows with you” は、ユーザーがエージェントの中に入っていくのではなく、エージェントがユーザーの外側を包みながらついてくる関係を含意する。oh-my-codexの三つの単語 — hooks、teams、HUDs — はそれぞれ、ソフトウェア工学において「既存の流れに差し込むもの(hook)」「水平的な協業単位(team)」「コックピットから現在状態を見せる計器盤(HUD: Heads-Up Display)」を意味する。この三つの単語のいずれも、frameworkの語彙ではない。Override、pipeline、orchestrator — これらが2023~2025年のAIエージェント・フレームワークが用いていた語彙だった。hooks、teams、HUDsは別の世界から来た言葉だ。既存システムを変えず、その上に覆い被せる世界。

本稿はこの語彙の移動を追跡する。「frameworkからharnessへ」という語彙的転換が、製品マーケティングの流行ではなく、AIコーディングツール生態系が2年間のフレームワーク時代から学んだ構造的教訓を反映している、というのが核心的論旨である。そしてこの転換の中心には一つの言葉がある — 決定論(determinism)。

1. Archonの宣言 — “The First Open-Source Harness Builder”

ArchonのREADMEの第一文が本エッセイの出発点である。“The first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.” 二つの文だ。第一文はポジショニングであり、第二文はバリュープロポジションである。どちらも分解する価値がある。

「Harness builder」という自己定義

Archonが自らをharness builderと呼ぶのは、意識的な選択である。2024年であれば、同じ機能を持つツールが「AI coding framework」や「agent orchestration platform」と自己紹介しただろう。実際、その時期のツールはそうしていた。LangChainは「framework for developing applications powered by large language models」と称し、CrewAIは「framework for orchestrating role-playing, autonomous AI agents」と称した。Frameworkという言葉は2023~2025年のAIエージェントツールの事実上の標準的自己紹介だった。

Archonはその言葉を意図的に避ける。Harnessだ。この選択が単なるマーケティング差別化なのか、それとも実質的な設計哲学の違いを反映しているのかが鍵となる。

答えを探すためにArchonの第二文を見よう。“Make AI coding deterministic and repeatable.” 決定論的かつ反復可能にする。この二つの形容詞はフレームワークの言葉ではない。フレームワークのバリュープロポジションは通常、「簡単に(easy)」「速く(fast)」「強力に(powerful)」のような言葉で表現される。決定論的で反復可能だという表現は別の伝統から来ている — ソフトウェアテスティングと品質保証の伝統である。テストが決定論的であるべきというのは、同じ入力に同じ出力が出るべきだという意味だ。テストが反復可能であるべきというのは、誰がどこで何回回しても同じ結果が出るべきだという意味である。

ArchonがAIコーディングにこの二つの属性を付与すると宣言するのは、AIコーディングの本質的問題 — LLMの確率的性格のため同じプロンプトに異なる結果が出ること — をツール層で統制するという意志の表明である。フレームワークが「より多くのことを可能にしてくれる」と約束したのに対し、harnessは「同じことを確実にできるようにする」と約束する。拡張(expansion)対 収束(convergence)。これが語彙の違いの背後にある設計哲学の違いである。

「First」という修飾語の意味

Archonが「the first」を主張するのは、このカテゴリそのものが新しいという認識を前提とする。AI coding frameworkは既に数十存在する。AI coding harness builderは — Archonの自己認識によれば — まだ存在しなかった。カテゴリを新たに作るという宣言である。これが誇張かどうかは市場が判断することだが、少なくともこの開発者がharnessという言葉をframeworkとは区別される別個のカテゴリとして認識しているという事実は明らかだ。

14,411スターと日次+185という数字が、この認識にコミュニティが反応していることを示している。もちろんGitHubのスターが製品の品質を保証するわけではない。しかしスターの速度 — 日次の増分 — は、特定の時点で特定のメッセージがコミュニティの関心を惹いているという事実を示す。2026年4月10日時点で、「harness builder」というメッセージが関心を惹いているのだ。

2. LangChain時代の遺産 — フレームワーク疲労の解剖

Archonがharnessという言葉を選んだ背景を理解するには、その言葉が置き換えようとしているもの — framework — の歴史をまず見なければならない。2023年から2025年までのおよそ2年は、AIエージェント・フレームワークの全盛期であり、疲労の時期でもあった。

2023:抽象化の春

LangChainが2022年末に登場したとき、開発者コミュニティの反応は熱狂的だった。LLMを呼び出すコードを直接書くのは反復的で退屈だった。プロンプトテンプレートを管理し、APIレスポンスをパースし、複数の呼び出しをチェーンし、外部ツールを接続する — このすべてのボイラープレートを抽象化してくれるフレームワークが出たのだから、当然歓迎された。2023年初頭、LangChainはGitHubで最も急速に成長するオープンソースプロジェクトの一つとなった。

続いてAutoGen(Microsoft)、CrewAI、LangGraph(LangChainチームの後継作)などが追随した。それぞれのアプローチは異なったが、共通のパターンがあった — ユーザーの作業をフレームワークが定義した構造の中に入れることである。LangChainのChain、AutoGenのAgent-Agent対話、CrewAIのCrew-Task-Agentの階層。ユーザーはフレームワークのメンタルモデルをまず学び、自らの問題をそのモデルに合わせて再構成しなければならなかった。

これはソフトウェア工学で「inversion of control」と呼ばれるパターンの典型である。ユーザーのコードがライブラリを呼び出すのではなく、フレームワークがユーザーのコードを呼び出す。制御の主体が反転する。Ruby on Railsがこのパターンの代表的成功事例だ — 「convention over configuration」という哲学のもと、開発者がRailsの方式に合わせれば莫大な生産性を得られる。合わせなければ苦しむ。

2024-2025:抽象化の冬

AIエージェント・フレームワークでも同じ力学が作動した。初期にはフレームワークの方式に合わせるのが容易だった。シンプルなRAGパイプライン、単一エージェントのツール呼び出し、定型的なQ&A。こうした標準的なユースケースではLangChainは優れていた。

問題は標準を外れた瞬間から始まった。エージェントが複雑化し、ツール呼び出しが入れ子になり、エラー処理が細密になり、プロダクション環境の要求(ロギング、モニタリング、コスト制御、タイムアウト)が付き始めると、フレームワークの抽象化が障壁となった。LangChainのChainの中で非同期エラーを掴むにはLangChainの内部実装を理解する必要があった。CrewAIのTask実行順序をカスタマイズするにはCrewAIの内部スケジューラを迂回する必要があった。抽象化が助けるのではなく、邪魔するものになった。

この現象に対するHacker Newsと開発者ブログの反応は次第に鋭くなった。「LangChain is not needed」「Why I stopped using LangChain」「The case against AI frameworks」のようなタイトルの記事が2024年中ずっと上がった。批判の核は一貫していた — フレームワークが解決してくれる問題よりフレームワーク自体が作り出す問題のほうが大きい。抽象化のレイヤーが多すぎてデバッグが難しく、フレームワークのアップデートがユーザーのコードを壊し、フレームワークが隠すもの(LLM API呼び出しの詳細、プロンプトの実際の中身、トークン使用量)を見たいのに見られない。

この疲労感の頂点は2025年中盤、AnthropicがClaude Agent SDKを発表したときに現れた。SDKの設計哲学はフレームワークとは正反対だった。Anthropicはエージェントを三つの要素の組み合わせとして定義した — model + tools + context management。そしてこの三要素を組み合わせる方式は開発者に委ねた。「我々が提供するのは最小限のビルディングブロックである。それをどう組み立てるかはあなたが決める。」これはフレームワークのアプローチではない。SDKのアプローチだ。そしてこの最小主義が — 意図したか否かはともかく — コミュニティに一つの空白を開いた。「モデルとツールの間を包む外部レイヤーを我々が直接作れる」という可能性の空間である。

Archonはまさにこの空間で生まれた。

3. Harness vs Framework — ソフトウェア工学史でこの言葉が意味してきたもの

Archonが選んだ「harness」という言葉はAIコーディングでは新しいものだが、ソフトウェア工学では数十年の歴史を持つ用語である。この歴史を押さえずには、語彙の移動がなぜ意味深いのかを取り逃がす。

Test harness:言葉の起源

ソフトウェアテスティングで「test harness」はテストを実行するためのインフラを意味する。JUnitのrunner、pytestのfixture system、SeleniumのWebDriver — これらがtest harnessだ。Test harnessがすることは三つある。第一に、テストが実行される環境を準備する(setup)。第二に、テストを実行し結果を収集する(execution + collection)。第三に、後片付けをする(teardown)。Harnessはテストコードそのものを書くわけではない。テストのロジックに介入しない。テストが正しい条件で正しい順序で実行されるよう保証するだけだ。

これをtest frameworkと比較してみよう。Test framework — 例えばRuby on Railsの組み込みテストフレームワークやDjangoのTestCase — はテストがどのように書かれるべきかを規定する。どのクラスを継承すべきか、どのメソッド名規約に従うべきか、assertionはどのAPIを使うべきか。Frameworkはテストの構造を決定する。Harnessはテストの実行のみを管理する。

この区別は微妙だが重要だ。Frameworkの世界ではユーザーがフレームワークのルールに合わせなければならない。Harnessの世界ではユーザーのコードがどんな形でも構わず、harnessがそのコードを包んで実行する。Frameworkが「中に入ってこい」なら、harnessは「外から包む」だ。

Harnessの核心的属性:非侵襲的(non-invasive)な包み込み

Test harnessの最も重要な属性は非侵襲的であるということだ。Harnessを取り替えてもテストコードは変わらない。JUnitのrunnerをTestNGのrunnerに変えても、テストロジックそのものは同一である。これはframeworkとは根本的に異なる。RailsからSinatraに移ればコードを書き直さなければならない。DjangoからFlaskに移ればコードを書き直さなければならない。Frameworkはユーザーのコードと結合し、harnessはユーザーのコードと分離する。

この属性をAIコーディングツールに当てはめると意味が鮮明になる。LangChainのChainの中で書いたエージェントロジックはLangChainの外でそのまま使えない。LangChainの抽象化に依存しているからだ。CrewAIのCrew-Task構造で設計したワークフローはCrewAIなしでは動作しない。これがframeworkの結合(coupling)である。

Archonがharnessを標榜するのは、この結合を避けるという宣言だ。ユーザーのAIコーディング・ワークフローがどんな形でも — どのモデルを使おうと、どのツールを使おうと、どのプロンプト戦略を使おうと — Archonがそれを外側から包んで決定論と反復可能性を付与する。ユーザーのコードを変えずに。これがharnessの約束である。

Test harnessからagent harnessへの拡張

本ブログの以前のエッセイ「モデルがすべてではなかった — Coding Agentを本当に動かすもの」で、Sebastian RaschkaのAgent Harness概念を扱ったことがある。その記事はharnessの六つの構成要素 — Live Repo Context、Prompt Shape、Tool Access、Context Bloat最小化、Session Memory、Bounded Subagents — を解剖した。本稿ではその解剖を繰り返さない。ただ一点だけ押さえておく。

Raschkaがharnessという言葉を選んだことと、数か月後にArchonが同じ言葉を選んだことの間には連関がある。Raschkaの記事は学術的分析だった — 「coding agentの構造をこう理解できる」というフレームワーク(今回は分析的意味でのフレームワーク)の提案だった。Archonはその分析を製品にしたものだ — 「そのharnessを直接作れるようにする」というツールの提案である。学術的概念が製品カテゴリに転換された瞬間であり、その転換がGitHub Trending上位に上ったということは、コミュニティがこの転換を認めたという意味だ。

4. 歴史的類比 — EJBからSpringへ、そして馬具の原義

語彙の移動がなぜ重要なのかを理解するため、ソフトウェア史で類似の転換が起きた瞬間を深く覗いてみよう。最も教訓的な事例は1990年代後半から2000年代初頭のEJBからSpringへの転換である。

EJB:フレームワークの極端

Enterprise JavaBeans(EJB)は1998年にSun Microsystemsが発表したJavaエンタープライズアプリケーションの標準フレームワークだった。EJBの約束は野心的だった。分散トランザクション、リモートメソッド呼び出し、オブジェクト永続化、セキュリティ、並行性管理 — エンタープライズソフトウェアのあらゆる難問をフレームワークが解決してくれるというものだった。

その代償は侵襲的結合(invasive coupling)だった。EJBを使うには開発者のビジネスオブジェクトが特定のインターフェースを実装し、特定のクラスを継承し、特定のデプロイメント記述子(deployment descriptor)をXMLで書かなければならなかった。簡単な計算ロジック一つをEJB化するにはHomeインターフェース、Remoteインターフェース、Bean実装クラス、デプロイメント記述子 — 最低四つのファイルが必要だった。ビジネスロジック10行のためにボイラープレート100行を書く必要があった。

より深刻な問題はテストだった。EJBはアプリケーションサーバの中でしか実行されなかった。ビジネスロジックを単体テストするには全体のアプリケーションサーバを起動する必要があった。これはテストを事実上不可能にした。開発者のコードがフレームワークと深く結合しすぎていて、フレームワークなしではコードが存在できなかった。

この状況は2024年のLangChainと重なるだろうか?正確に重なる。LangChainのChainの中で書いたエージェントロジックを単独でテストするにはLangChainのランタイムが必要だった。エージェントの振る舞いをデバッグするにはLangChainの抽象化層を突き抜けて入る必要があった。フレームワークが解決してくれるものよりフレームワーク自体が作り出す複雑度のほうが大きくなる瞬間が来た。EJBが1990年代後半に経験したのと同じ軌跡である。

Spring:POJOを包む

2002年、Rod Johnsonが Expert One-on-One J2EE Design and Development という書籍を出版し、EJBへの体系的批判とともに代替案を提示した。これがSpring Frameworkの始まりである。Springの核心哲学は一つだった — POJO(Plain Old Java Object)を尊重せよ。

POJOはどのフレームワークにも依存しない、純粋なJavaオブジェクトだ。特定のインターフェースを実装せず、特定のクラスを継承しない。SpringはこのPOJOをそのまま置き、外側から包む方式を選んだ。Dependency Injectionという技法を通じ、オブジェクト間の依存関係を外部から注入した。オブジェクト自体は自分がSpringの中で動いているかさえ知らなくてよかった。

これはまさにharnessのアプローチである。Springは開発者のコードを変えなかった。開発者のコードを包んで、トランザクション管理、セキュリティ、リモート呼び出しのようなエンタープライズ機能を外部から覆い被せた。開発者のPOJOはフレームワークなしでテスト可能だった。Springを剥がしてもビジネスロジックは無傷だった。非侵襲的な包み込み。Harnessの定義そのものだ。

結果は歴史が証明する。EJBは3.0で大幅に簡素化されたが、すでに勢力は逆転した後だった。SpringはJavaエコシステムの事実上の標準となり、20年が過ぎた2026年現在もその地位を維持している。フレームワークは負け、harness(の精神)が勝ったのだ。

馬具(horse harness)の原義

ここでもう一歩後ろに引いて、harnessという英単語の語源を見よう。この言葉の最も古い意味は「馬具(ばぐ)」だ。馬の体に被せて、馬の力を馬車や鋤に伝える装置である。

馬具の核心的特性を見ると、ソフトウェアharnessとの類比は驚くほど正確だ。

第一に、馬の能力を変えない。馬具を被せても馬が速くなったり強くなったりはしない。馬の力はそのままだ。馬具がするのはその力の方向を定めることである。 — LLMの推論能力を変えないが、その推論がどこへ向かうかを制御するagent harnessと同じだ。

第二に、馬がいなければ意味がない。馬具だけあって馬がいなければ役に立たない革と金属である。 — モデルなしでは動作しないharnessと同じだ。一方、フレームワークは独自の構造とロジックを持っており、ユーザーのコードがなくても「何かが存在する」感じを与える。空のRailsプロジェクトを生成するとディレクトリ構造と設定ファイルが直ちに作られる。空のharnessには何もない。

第三に、取り替え可能だ。馬に鋤用の馬具を被せれば畑を耕し、馬車用の馬具を被せれば荷物を運ぶ。同じ馬に違う馬具。 — 同じモデルに違うharness設定を適用すれば違う種類の作業をする。Archonが「harness builder」を標榜する理由がここにある。一つの固定されたharnessを提供するのではなく、ユーザーが自身の作業に合うharnessを作れるようにするということだ。

第四に、そしてこれが最も重要だが — 決定論を付与する。馬具のない馬はどこへ走るか分からない。馬具があれば馬の力が予測可能な方向に伝わる。 — LLMの確率的出力を決定論的かつ反復可能なワークフローに変えるというArchonの約束がこれだ。

EJBからSpringへの転換と馬具の比喩を重ねると、2026年のAIコーディングツールで起きていることの輪郭が見えてくる。2023~2025年のAIエージェント・フレームワークはEJBだった。野心的で、包括的で、侵襲的だった。2026年のharnessアプローチはSpringだ。最小主義的で、非侵襲的で、ユーザーのコードを尊重する。そして馬がすでに十分強くなった時代 — GPT-5、Claude Opus 4.6、Gemini 3.1のようなフロンティアモデルがすでに強力な推論能力を備えた時代 — に必要なのはより強い馬ではなく、より良い馬具である。

5. hermes-agentとoh-my-codex — 「Hooks」「Grows with you」が露わにするパラダイム

Archonがharnessという言葉を明示的に使った唯一のレポだとすれば、hermes-agentとoh-my-codexは同じパラダイムを別の語彙で表現している。この二つのレポの言語を解剖すれば、harnessパラダイムが単一プロジェクトのマーケティングではなく、より広い潮流であることを確認できる。

hermes-agent:“The agent that grows with you”

hermes-agentのサブタイトル “The agent that grows with you” の核心は “with you” である。エージェントが成長するという主張は新しくない。すべてのAIツールが「もっと賢くなる」と言う。しかし「with you」 — あなたと共に — という修飾が、関係の方向を規定する。

フレームワークの関係は「中に入ってこい」だ。ユーザーがフレームワークの構造に合わせる。LangChainのChainに自身のロジックをはめ込み、CrewAIのCrewに自身のエージェントを登録し、AutoGenの会話プロトコルに合わせてメッセージを設計する。ユーザーがフレームワークへ移動する。

「grows with you」は反対方向だ。ユーザーがいる場所にエージェントが来る。ユーザーが成長すればエージェントもそれに従って成長する。ユーザーのワークフローが変わればエージェントもそれに合わせる。これは包む(wrapping)関係だ。エージェントがユーザーを外側から包み、ユーザーの変化に応じて包み方を調整する。フレームワークではなくharnessの関係である。

hermes-agentが週次+19,765でその週の最大上昇レポであるという事実は注目に値する。NousResearchはオープンソースAI研究で既に認知度のある組織であり、hermesモデルシリーズのブランドパワーが作用しただろう。しかし44,309スターという絶対値は単純なブランド効果を超える。「grows with you」というメッセージが開発者コミュニティに反響を起こしているのだ。

oh-my-codex:Hooks、Teams、HUDs

oh-my-codexのサブタイトル “Your codex is not alone. Add hooks, agent teams, HUDs” は三つの技術用語を前面に押し出す。この三つの単語がどこから来たかを追跡すれば、oh-my-codexが自らをどの伝統の中に位置づけようとしているかが見えてくる。

Hooks. ソフトウェア工学でhookは「既存システムの実行フローにユーザー定義コードを差し込むエントリポイント」だ。Git hooks、React hooks、WordPress hooks — すべて同じパターンである。既存システムを修正せず、既存システムが提供するエントリポイントに自身のコードを引っ掛ける(hook)。これはフレームワークのoverrideパターンとは異なる。Overrideは既存の振る舞いを置き換える。Hookは既存の振る舞いを維持しつつ追加の振る舞いを差し込む。非破壊的(non-destructive)拡張。Harnessの特性と正確に一致する。

oh-my-codexがOpenAIのCodex CLIにhooksを追加するということは、Codexの既存動作を変えず、特定の時点でユーザー定義の動作を差し込むということだ。Codexがコードを生成する前に検証ロジックを差し込んだり、生成後にフォーマットを適用したり、特定のパターンが検知されると警告を送ったり。既存ツールを包む外部レイヤーである。

Teams. ここでteamはAIエージェントのグループを意味するが、語彙の選択自体が示唆的だ。フレームワーク時代の語彙は「orchestration」だった。オーケストレーションは中央指揮者(conductor)が各楽器(agent)を統制するモデルである。階層的で、中央集権的だ。Teamは水平的である。各メンバーが自律性を持ち、協業するが中央指揮を受けない。CrewAIも「crew(船員)」という似た隠喩を使うが、その内部実装は中央オーケストレーションに近い。oh-my-codexが「team」を使い、これをhooksと並置するということは、エージェント間の関係も非侵襲的(各自のコードを変えずに協業する)であるという含意を与える。

HUDs. Heads-Up Display。戦闘機パイロットのヘルメットバイザーに飛行情報が投射されるのを思い浮かべよう。HUDの核心的特性は二つある。第一に、現実を遮らない。パイロットは依然として窓の外を見ている。情報が現実の上に重ねられるだけだ。第二に、情報はリアルタイムである。過去のデータではなく、今の状態を見せる。

これをAIコーディングツールの文脈に当てはめると — oh-my-codexのHUDはCodexが何をしているかをユーザーにリアルタイムで見せつつ、Codexの動作そのものを遮ったり変更したりしない。フレームワークの「dashboard」と比較してみよう。Dashboardは通常、フレームワークの内部状態をフレームワークの用語で見せる。HUDはユーザーの視野の上に情報を乗せる。前者はフレームワーク中心的であり、後者はユーザー中心的だ。

三つの単語 — hooks、teams、HUDs — を総合すると、oh-my-codexの設計哲学が見えてくる。既存ツール(Codex CLI)を変えない。既存ツールの外側でエントリポイント(hooks)を作り、水平的協業構造(teams)を載せ、リアルタイム状態表示(HUDs)を被せる。これはharnessだ。Archonのように言葉を直接使ってはいないが、アプローチは同一である。

週次+9,737という上昇値は、19,938という総スター数とともに、このアプローチがコミュニティで強い反応を得ていることを示す。韓国の開発者が作ったツールがグローバルGitHub Trending週次2位に上ったこと自体も注目に値するが、本稿の関心はそこではない。関心は、このツールが用いる語彙 — hooks、teams、HUDs — がArchonのharness、hermes-agentの「grows with you」と同じ方向を指し示しているという事実である。

6. Claude Agent SDKと最小主義 — 外部ラッピングレイヤーを招き入れた方法

三つのレポが同時にharnessパラダイムへ移動したのが偶然ではないとすれば、何がこの移動を引き起こしたのか。複数の要因があるが、最も直接的な触媒は AnthropicのClaude Agent SDKが提示した最小主義的なエージェント定義 である。

“Agent = Model + Tools + Context Management”

Claude Agent SDKのエージェント定義は意図的に最小だ。エージェントとはモデルがツールにアクセスし、コンテキストを管理することである。この定義にはオーケストレーションがない。ワークフローがない。ステートマシンがない。計画立案がない。LangGraphがエージェントを「ノードとエッジから成るグラフ」と定義し、CrewAIがエージェントを「役割とタスクの階層」と定義したのと対照的に、Anthropicはエージェントを最も低い水準のビルディングブロックに還元した。

この最小主義がharnessエコシステムを可能にした理由は明確だ。フレームワークがすでに豊富な構造を提供すれば、外部レイヤーの入る余地はない。LangChainがオーケストレーション、メモリ、ツール管理をすべて提供しているのに、その上にさらに別のレイヤーを載せれば重複と衝突が生じる。一方、SDKが「モデル + ツール + コンテキスト管理」だけを提供すれば、その上に決定論的実行、反復可能なワークフロー、品質ゲート、モニタリングなどを載せる空間が開く。Archonがまさにこの空間に入り込んだ。

比喩を拡張すればこうだ。Claude Agent SDKは馬(モデル)と基本的な手綱(ツールアクセス)を提供する。馬具(harness)はコミュニティが作る。Anthropicは馬具を提供しなかった — 意図的に。馬具の設計をコミュニティに委ねることで、多様な種類の馬具が多様な用途に作られるエコシステムを開いた。農作業用馬具、運送用馬具、レース用馬具 — それぞれ異なるユーザーの異なる要求に合わせたharnessが登場し得る。

この戦略が意図的だったかどうかはAnthropicのみが知る。結果的に起きたのは、SDKの最小主義がharness builder(Archon)、hooks拡張(oh-my-codex)、適応型エージェント(hermes-agent)のような外部プロジェクトの爆発的成長を可能にしたということだ。

より広い文脈:obra/superpowersとonyx

同じ週次トレンディングでobra/superpowersは143,000スターで圧倒的存在感を示す。このプロジェクトは自らを「skills framework & software development methodology」と紹介する。Frameworkという言葉を使いながらも、「methodology」という補助の言葉を並べる。Methodologyはフレームワークよりも緩い概念だ。コード構造を強制するのではなく、作業の方法論を提案するものである。「こう構造化せよ」ではなく「こうアプローチしてみよ」。これはframeworkとharnessの中間地帯である — 構造を提供するが強制はしない。

onyx-dot-app/onyxは26,000スター、週次+5,556のAIチャットプラットフォームだ。サブタイトルは「works with every LLM.」すべてのLLMで動作する。これはplatform-agnosticな外部レイヤーである。特定のモデルに結合せず、どのモデルでも包んでチャットインターフェースを提供する。Chat層でのharnessパターンだ。

superpowersとonyxをArchon、hermes-agent、oh-my-codexと並べると、同じ週にGitHub Trendingを占めたAI関連プロジェクトが一つの方向 — 既存ツール/モデルを変えず外側から包むこと — を共有していることがより鮮明になる。これを偶然の一致と呼ぶには、一致するプロジェクトが多すぎる。

7. 決定論(Determinism)がなぜ今、論題となったか — Agentic失敗の教訓

Archonの第二文 — “Make AI coding deterministic and repeatable” — に戻ろう。この文が2024年ではなく2026年に出てきたのには理由がある。2024年には「AIコーディングを決定論的にする」というバリュープロポジションが共感を得るのは難しかっただろう。2024年の関心事は「AIコーディングが可能か」「AIがどこまでできるか」だった。可能性の拡張が最優先だった。決定論は可能性を制限するように聞こえただろう。

2026年に決定論が論題になったのは、その間の2年間のagentic失敗経験が蓄積されたからだ。

失敗類型1:非決定論的ワークフローのデバッグ不能性

AIエージェントをプロダクションに投入したチームが最初にぶつかった問題は、エージェントの振る舞いが再現不可能だということだった。同じ入力を与えたのに違う結果が出る。モデルの温度(temperature)設定、プロンプトの微細な変化、コンテキストウィンドウの中身、ツール呼び出しの順序 — このすべてが確率的に変動するため、一度成功したワークフローが次は失敗し得る。そしてなぜ失敗したか分からない。フレームワークが中間の状態を抽象化してしまったからだ。

伝統的ソフトウェアでデバッグが可能な理由は決定論にある。同じ入力に同じ出力が出ることが保証されれば、入力を変えながら問題を絞り込める。AIエージェントでこの保証がなければ、デバッグは「もう一度回したら今回はうまくいった」レベルに落ちる。これはプロダクション環境で受け入れられない状態である。

失敗類型2:フレームワークが隠した制御フロー

LangChainやCrewAIのようなフレームワークを使ったチームが報告した二つ目の問題は、エージェントの制御フローを理解できないということだった。フレームワークが内部的にどの順序でツールを呼び出すのか、どの条件で再試行するのか、エラーが発生したときどう復旧するのか — このすべてがフレームワークの抽象化の裏に隠れていた。

以前のエッセイで扱ったattributionバグ — Claude Codeが自分自身の発言をユーザーの発言として誤って帰属させた事例 — がこの問題の極端な形だ。Harness層でメッセージの役割を誤って処理すると、モデルは存在しないユーザー指示を確信を持って遂行する。こうした問題がフレームワークの抽象化の裏に隠れていれば、発見そのものが難しい。dwyer.co.zaの著者が「破壊的行動と共に現れたときにだけ目立つ」と語ったのがこれだ。

失敗類型3:「動くがなぜ動くか分からない」

本ブログの以前のエッセイ「モデルがすべてではなかった」で扱ったMagantiのsyntaqliteの経験がこの類型の典型である。最初のビルドで500以上のテストがパスした。「動いた」。それなのに、なぜ動くのかをManganti自身も理解できなかった。AIが生成したコードの構造を把握できなかった。これは「false reassurance」 — 偽の安心感 — である。テストがパスするという事実はシステムの健全性を保証しない。

この経験がharnessパラダイムと結びつくのはここだ。Harnessは決定論と反復可能性を約束する。決定論は「同じ入力に同じ出力」を保証する。反復可能性は「同じ過程を再び実行できる」を保証する。この二つの属性があれば、「なぜ動くか」を事後に追跡できる。入力を変えながら出力の変化を観察できる。過程を反復しながら各ステップの寄与を分離できる。科学的方法論の基本条件 — 統制された変数と反復実験 — がAIコーディングにも適用されるのだ。

三つの失敗の共通分母

三つの失敗類型の共通分母は 制御の喪失 である。フレームワークが制御を奪った結果、開発者はエージェントの振る舞いを予測することも、再現することも、理解することもできなくなった。Harnessの約束はこの制御を取り戻すというものだ。エージェントの内部 — モデルの推論 — は依然として確率的だが、エージェントの外部 — harnessが管理する実行条件、入力構成、出力検証、ツール呼び出し順序 — は決定論的にできる。内部は制御できないが、外部は制御できる。そして外部を制御すれば、内部の不確実性が全体システムの不確実性へ伝播するのを防げる。

これがArchonが「deterministic and repeatable」をバリュープロポジションの中心に据えた理由だ。2年間のagentic失敗が教えた教訓は、「より強いモデル」ではなく「より決定論的な実行環境」が必要だということだった。そして決定論的な実行環境はフレームワークの内部ではなく、harnessの外部でより自然に実装される。

8. RailsからSinatraへ、そして再び — 重さと軽さの振り子

歴史的類比をもう一つ深く展開すれば、この転換の位置をより正確に把握できる。Ruby生態系の Rails vs Sinatra の振り子運動である。

Railsの全盛期と反動

Ruby on Railsは2004年に登場したとき、ウェブ開発の盤面を変えた。「Convention over Configuration」 — 規約が設定を代替する — という哲学のもと、開発者が決めるべきことをフレームワークがあらかじめ定めていた。ディレクトリ構造、ネーミング規則、データベースマッピング、ルーティング — すべてが「Rails方式」で決められていた。この規約に従えば驚くべき生産性が得られた。15分でブログを作るデモが世間を驚かせた。

しかしRailsの規約から外れる瞬間 — 非標準的なデータベース構造、特殊な認証ロジック、マイクロサービス・アーキテクチャ — が来ると、Railsは助けではなく障害となった。「Rails方式」ではないことをしようとすると「Railsを迂回する方法」を学ぶ必要があった。フレームワークを使いながらフレームワークと戦う逆説。

これに対する反動として2007年にSinatraが登場した。Sinatraは自らを「micro-framework」と呼んだが、実質的には ルーティングharness に近かった。HTTPリクエストを受け取ってユーザーのコードに渡すこと、まさにそれだけをした。ディレクトリ構造を強制しなかった。ORMを内蔵しなかった。テンプレートエンジンを指定しなかった。ユーザーが望むものを望む方式で書き、SinatraはそれをHTTP上で実行してくれるだけだった。

Python生態系でも同じ振り子が作動した。Django(フレームワーク) vs Flask(マイクロ-harness)。Djangoは「電池含む(batteries included)」を標榜し、認証、ORM、管理者パネル、フォーム処理まで提供した。FlaskはWSGI上のルーティングとテンプレートレンダリングのみを提供した。

両方の生態系で同じパターンが観察される。フレームワークがまず市場を掌握し、複雑度が臨界点を超えると軽い代替案が浮上する。そして軽い代替案の上に必要な機能が一つ二つ載っていくにつれて、結局また別の形の「重さ」が生まれる。振り子は一方向にだけ進むのではない。

AIエージェントの振り子はどこにあるか

この振り子の観点から見ると、AIエージェント生態系は今まさに RailsからSinatraへ移動する区間 にある。LangChain/CrewAI/AutoGenがRailsだったとすれば、Archon/hermes-agent/oh-my-codex世代がSinatraだ。フレームワークの規約から外れ、ユーザーのコードを尊重する最小主義的な外部レイヤーへの移動である。

しかし歴史の教訓はここで終わらない。SinatraはRailsを代替できなかった。FlaskもDjangoを代替できなかった。市場は二分された。標準的なユースケースではフレームワークが依然として優位を占め、非標準的なユースケースで軽い代替案が定着した。そして時間が経つにつれ、軽い代替案の上にも生態系が積み重なり始めた — Flask拡張、Sinatraミドルウェア — 結局「軽いフレームワーク」という撞着語法が現実となった。

AIエージェント生態系でも同じことが起きる可能性が高い。Harnessがフレームワークを完全に代替することはないだろう。標準的なRAGパイプライン、シンプルなチャットボット、定型化されたワークフローではLangChainやその後継が依然として効率的だろう。Harnessが輝く領域はプロダクション、カスタマイズ、決定論が必要な場所だ。そして時間が経てばharnessの上にも生態系が積み重なり、その生態系がまた別の形の「重さ」となるだろう。

重要なのは現在の振り子の位置を知ることである。2026年4月時点で、振り子は明らかにharness側に動いている。GitHub Trendingがその証拠だ。

9. 実務者への含意 — あなたのエージェントにharnessはあるか

ここまでの分析を総合すると、実務者にいくつかの具体的な含意が導かれる。

第一に、語彙を点検せよ。

あなたがAIエージェントツールを評価するとき、そのツールが自らをどんな言葉で説明しているかを注意深く見よ。Frameworkというか、harnessというか、それともそもそもカテゴリを定義していないか。語彙は設計哲学を反映する。Frameworkを標榜するツールはユーザーのコードがその構造の中に入る必要がある。Harnessを標榜するツールはユーザーのコードを外側から包む。この違いがあなたのコードベースとワークフローに与える影響は大きい。

第二に、結合度を測定せよ。

あなたが今使っているAIエージェントツールとあなたのコードの間の結合度(coupling)を測定してみよ。そのツールを剥がしたとき、あなたのコードはどれほど生き残るか? LangChainのChainの中にあるロジックをLangChainなしで実行できるか? 結合度が高いほどツール交換のコストが大きく、ツールの問題があなたの問題となる。低い結合度はharnessアプローチの核心的約束である。

第三に、決定論を要求せよ。

AIエージェントがプロダクションに入るとき、「同じ入力に同じ出力」をどれほど保証できるかを問うべきだ。完全な決定論はLLMの確率的性格上不可能だが、harness水準での決定論 — 同じプロンプト構成、同じツール呼び出し順序、同じ検証ロジック — は可能だ。これがあればデバッグが可能であり、なければデバッグは不可能である。Archonがこれをバリュープロポジションの核心に置いたのは偶然ではない。

第四に、以前のエッセイのHarnessの六つと結びつけよ。

「モデルがすべてではなかった」で扱ったharnessの六つの要素 — Live Repo Context、Prompt Shape、Tool Access、Context Bloat最小化、Session Memory、Bounded Subagents — はharnessの解剖学だった。本エッセイが扱うのはharnessの歴史的位置と生態系的意味だ。両者を合わせるとこうなる — 解剖学的にharnessが何かを知り(以前のエッセイ)、生態系でharnessがなぜ今台頭しているかを知れば(本エッセイ)、自身のワークフローにどんなharnessが必要かを判断できる。

第五に、振り子の位置を覚えておけ。

Harnessが万能ではないことも知るべきだ。RailsからSinatraへの移動がSinatraの勝利を意味しなかったように、FrameworkからHarnessへの移動がHarnessの絶対的優位を意味するわけではない。標準的なユースケースではフレームワークが依然として効率的だ。非標準的、プロダクション級、決定論が必要なユースケースでharnessが輝く。自分がどのユースケースにいるかを知ることが第一である。

10. 開かれた問い — 語彙の移動はどこまで進むか

2026年4月10日のGitHub Trendingが示したのは、AIコーディングツールの語彙が移動しているという事実である。Frameworkからharnessへ。Overrideからhooksへ。DashboardからHUDへ。Orchestrationからteamへ。「中に入ってこい」から「外から包む」へ。

この移動が一時的な流行か、構造的な転換かは時間が答えるだろう。ただし本稿が追跡した証拠 — Archonの明示的な「harness builder」宣言、hermes-agentの「grows with you」、oh-my-codexのhooks/teams/HUDs、2年間のフレームワーク疲労感、EJBからSpringへの歴史的先例、Claude Agent SDKの最小主義が開いた空間、agentic失敗から学習された決定論の必要性 — は一時的な流行よりも構造的な転換に重みを置かせる。

開かれた問いは複数ある。

第一に、harnessの標準化はどう進むか。 Test harness領域ではJUnitが事実上の標準となり、他の言語のtest harness(pytest、RSpec、Jest)も似たインターフェースに従うようになった。Agent harnessでも似た標準化が起きるだろうか? Archonが「first」を主張するのは、この標準を先取りしようとする試みとして読める。

第二に、フレームワークはharnessを吸収するか。 Springは最初EJBの代替案だったが、時間が経つにつれてSpring自体が巨大なフレームワークとなった。Harnessとして始まったツールが機能を追加しながらフレームワークになる循環は繰り返されるか? それとも今回は違うのか?

第三に、モデル自体がharnessを内蔵するか。 現在のharnessはモデル外部のソフトウェア層である。しかしモデルがより強力になれば、決定論的実行と反復可能性がモデル内部の機能となる可能性もある。モデルが自らtool validationを行い、context bloatを管理し、session memoryを維持するなら、外部harnessの役割は縮小する。この未来が来れば、harnessパラダイムはどう進化するか?

第四に、決定論のコストは何か。 Archonが約束する決定論と反復可能性にはコストがあるはずだ。決定論を強制すれば、LLMの確率的探索 — 時に予想外の良い結果を生む — が制限され得る。決定論と創造性の間のトレードオフをharnessはどう管理するか?

これらの問いへの答えはまだない。答えがある必要もない。重要なのは問いの方向だ。2023~2025年の問いが「AIエージェントで何ができるか」だったとすれば、2026年の問いは「AIエージェントをどう制御できるか」だ。可能性から制御へ。拡張から収束へ。Frameworkからharnessへ。

Archonが自らを「the first open-source harness builder for AI coding」と紹介し、“Make AI coding deterministic and repeatable” と付け加えたあの二つの文は、2026年のAIコーディングツール生態系の転換を圧縮している。フレームワーク時代に我々はAIにより多くのことができる自由を与えた。Harness時代に我々はAIが行ったことを理解し再現できる構造を要求する。自由から規律へ。そしてソフトウェア工学の歴史が一貫して示してきたように、規律が先に確立された領域で本当に生産的な自由が花開く。

馬は馬具を着けてこそ畑を耕せる。馬具が馬の自由を奪ったのか? いや。馬具が馬の力に目的を付与したのだ。2026年のAIコーディングが決定論を再発見したのも同じ理由である。モデルの力はすでに十分だ。今やその力に方向を与える番である。

出典