AIコーディングエージェントを選ぶ際、多くの人はモデルの性能だけを比較している。しかし、真に重要なのはモデルそのものではなく、それを取り巻く「ハーネス」と呼ばれる実行環境である。Claude CodeとCodexは同等のモデル性能を持ちながら、根本的に異なるアーキテクチャ哲学を体現している。一方はローカル環境への完全アクセスと段階的実行を重視し、もう一方は隔離されたサンドボックスでの安全性と構造化を優先する。この違いは単なる好みの問題ではなく、チームの作業プロセス、セキュリティ体制、そして将来の切り替えコストを左右する戦略的決定である。ハーネスへの投資は毎週複利的に蓄積され、後からの変更は組織全体のワークフローを再構築することを意味する。モデルの優劣論争に惑わされず、ハーネスの本質を理解することが、2026年以降のAI活用を左右する鍵となる。
- AIハーネスとは何か、そしてなぜ誰も語らないのか
- 誰もハーネスを比較しない
- Claude CodeとCodexの根本的な違い
- 2月5日の同時リリースが明らかにしたこと
- Anthropicのハーネス哲学:構造化された記憶
- OpenAIのハーネス哲学:リポジトリを記録のシステムに
- 実務者の視点:Calvin French Owenの使い分け
- ハーネスの分岐を構成する5つの要素
- 1. 実行哲学の分岐
- 2. 状態と記憶
- 3. コンテキスト管理
- 4. ツール統合
- 5. マルチエージェントアーキテクチャ
- 実践者の視点:1年間の進化
- ツール比較から戦略問題へ
- クラウド戦争との類似性
- あなたにとって何を意味するか
- 本当の質問とは
- より詳しい情報はSubstackで
AIハーネスとは何か、そしてなぜ誰も語らないのか
AIハーネスは私たちの働き方を形作っているものですが、十分に語られていません。Claude CodeやCodex、CursorのようなAIコーディングエージェントを使うとき、あるいはChatGPTのようなチャットウィンドウを使うとき、私たちは実は2つのものと同時にやり取りしています。
1つ目はモデルです。これは知性の部分であり、リクエストを理解し、応答を生成する部分です。これが誰もが比較しがちな部分ですよね。見出しで争われているのもこの部分です。
そして2つ目が、それ以外のすべてです。AIは実際にどこで作業を行うのでしょうか。あなたのコンピューター上でしょうか、それともどこかのサーバー上でしょうか。ノートパソコンを閉じて明日戻ってきたとき、AIはあなたが作っていたものを覚えているのでしょうか、それとも初めて会ったかのようにゼロから始めるのでしょうか。AIはあなたのプロジェクト管理ツールやデザインファイル、テストシステムにアクセスできるのでしょうか、それともすべて遮断されているのでしょうか。5つのタスクを同時に実行する必要があるとき、AIはチームのようにそれらのタスクを調整するのでしょうか、それとも互いに連絡のない別々の部屋でそれぞれを実行するのでしょうか。
今説明したすべて、つまり「それ以外のすべて」、これがハーネスです。そしてこれは最近、モデルよりもはるかに重要なのです。なぜなら、モデルはあなたのAIがどれだけ賢いかを決定しますが、ハーネスはそれがあなたの仕事にどのように適合するかを決定するからです。
そしてハーネスがモデルよりもはるかに重要な理由は、モデルは次のトークンをどれだけうまく予測できるかを決めるだけだからです。ハーネスは、それがあなたの仕事にどれだけ有用に適合するか、あなたとどう協力するか、何に触れられるか、何を覚えているか、どう失敗するか、6ヶ月後に別のツールに切り替えたいときに何が起こるかを決定します。
ハーネスこそが、個人的な関係であれ仕事上の関係であれ、あなたが関係を築く相手なのです。モデルは瓶の中の脳のようなもので、ハーネスなしでは大したことはできません。
誰もハーネスを比較しない
誰もハーネスを比較していません。今月あなたが読んだすべての比較記事、ClaudeとChatGPTの比較であれ、Gemini 3.1 Proと以前のバージョンのGeminiの比較であれ、すべてただ瓶の中の脳を比較しているだけだと言えます。
それはハーネスをテストするのが本当に難しいからです。テストすることもまれですし、語られることもまれです。そして、トータルパッケージについて語り、得られる価値や成果物のすべてを、あたかもその小さな瓶の中の脳が仕事をしているかのように帰属させる方が簡単なのです。
これは、すべてのAIハーネスがほぼ同じであれば、本当にマイナーな盲点で済むでしょう。そして多くの人は基本的にそうだと思い込んでいます。人々はこんなメンタルイメージを持っているのではないでしょうか。OpenAIやClaudeが作った特別な脳があって、それを包む体は単なるフランケンシュタインのようなもので、どうでもいいと。
でも実際のハーネスはそんな風には機能しません。ハーネスは本当に速く分岐していますし、それは意図的なものです。
Claude CodeとCodexの根本的な違い
例えば、Claude CodeとCodexは同じものの2つのフレーバーではありません。そしてそれはモデルの違いだけではありません。これらは実際、人間とAIがどのように協力すべきかについて根本的に異なる考え方を体現しています。
一方はあなたの実際のワークスペースに座り、マシン上のすべてにアクセスでき、時間をかけてプロジェクトの記憶を構築します。もう一方はコードのコピーを持った密閉された部屋で作業します。内密に考え、完成した結果をドアの下からスライドさせるのです。
一方はあなたの隣の机にいる協力者であり、もう一方はクリーンルームにいる請負業者です。これらは単なる好みの問題ではありません。これらは、モデルメーカーが長期的に効果的なソリューションだと考えるものに対するアーキテクチャなのです。
アーキテクチャについて重要なのは、あなたのチームが意識的にせよ無意識的にせよ、その周りに構築していくということです。習慣、プロセス、検証ステップ、統合の配管、すべてがあなたが選んだハーネスの周りに蓄積され、毎月価値を増していきます。
ハーネスを切り替えるとなると、チームが新しいモデルを学ぶだけではありません。チームがプロセス全体を再構築することになるのです。すべてがゼロにリセットされます。
これが今日の決定で誰も価格に織り込んでいないロックインです。ベンダーのサブスクリプションロックインではありません。ハーネスを通じて表現された、仕事がどうあるべきかというモデルメーカーの哲学へのロックインなのです。
2月5日の同時リリースが明らかにしたこと
2月5日、AnthropicとOpenAIはともに新しいフラッグシップコーディングモデルを同じ日にリリースしました。AnthropicのClaude Opus 4.6とOpenAIのGPT-5.3 Codexです。
私はここ数週間、開発者コミュニティの反応を追跡してきましたが、モデルは能力で収束しています。問題は、ハーネスが収束していないことです。ハーネスは分岐しており、それが重要なのです。
この分岐こそがこの比較における本当の物語なのに、誰もがモデルについて語っています。では、ハーネスの分岐は実際にどのようなものなのでしょうか。それを目にしたとき、何のコストがかかるのでしょうか。そしてなぜこれが、私たちが語っていない興味深いツール決定の1つなのでしょうか。
さらに進む前に、1つの数字がこの論点を際立たせます。あなたは「ああ、Nateはただ話しているだけだろう。瓶の中の脳こそが重要で、これは本当には問題じゃない」と思うかもしれません。
でも2026年1月のAI Engineer Summitで、Anthropicは公開された科学的結果を再現するエージェントの能力をテストするCOREベンチマークの結果を発表しました。同じClaudeモデル、同一のウェイト、同一のトレーニングが、Claude Codeのハーネス内で実行されたときには78%のスコアを記録しましたが、別のスタートアップが構築した異なるハーネスであるSmall Agents内で実行されたときには42%でした。
同じ脳、異なる体で、パフォーマンスがほぼ2倍です。これはプロンプトエンジニアリングで説明できる限界的な差ではありません。ハーネスが行うすべてのこと、つまりコンテキストをどう管理するか、セッション間で状態をどう引き継ぐか、ツールをどう接続するか、結果をどう検証するかによって説明される構造的な差なのです。
ハーネスはモデルの上の最適化レイヤーではありません。モデルの知性が実際に有用な仕事に変換されるかどうかを決定するパフォーマンス倍率器なのです。
Anthropicのハーネス哲学:構造化された記憶
今最も重要な2つのハーネスは、その体がどうあるべきかについて非常に異なる賭けをしています。
まず、Anthropicのエンジニアリングチームは、彼らのハーネスが解決するために構築された問題の詳細な説明を公開しました。彼らは非常に鮮明にそれを組み立てました。
シフト制で働くエンジニアがスタッフとして配置されたソフトウェアプロジェクトを想像してください。各新しいエンジニアは前のシフトで何が起こったかについてゼロの記憶で到着します。これがAIエージェントが複数のコンテキストウィンドウにわたって作業するときに起こることです。モデルは賢いですが、各セッションを本当に白紙の状態から始めるのです。
Anthropicのソリューションは構造的なもので、単なるプロンプティングではありませんでした。Claude Codeのハーネスは2部構成のパターンを使用します。
最初に実行されるイニシャライザーエージェントがあり、プロジェクトをセットアップします。これは構造化された機能リスト、開始スクリプト、進捗ログ、クリーンなコミットを作成します。そして、その後のすべてのセッションで実行されるコーディングエージェントがあり、一度に1つの機能について段階的に進捗し、次のセッションのために構造化された成果物を残します。
コーダーでない人がなぜ気にすべきか疑問に思うなら、これは基本的に今日のAnthropicのCo-workの中にあるものと同じです。
進捗ファイルとGit履歴がエージェントの組織的記憶になります。すべてのセッションは同じ方法で始まります。進捗ログを読み、Git履歴を確認し、基本的なテストを実行して何も壊れていないことを確認します。そして次の機能を選んで開始します。
重要な設計選択は、ハーネスが段階主義を強制することです。自分自身に任せると、モデルはすべてを一度に構築しようとします。Anthropicはこれを「ワンショット」と呼び、実装の途中でコンテキストを使い果たし、次のセッションが半分完成した仕事を推測することになります。
ハーネスはタスクリストを単一のJSONに構造化することでこれを防ぎます。皮肉なことに、Markdownではありません。どうやらモデルがタスクリストとして構造化データ形式のJSONを破損させる可能性が低いからです。そしてエージェントにセッションごとに正確に1つの機能に取り組むようプロンプトします。
ハーネスはまた検証を強制します。エージェントはPuppeteer MCPサーバーのようなブラウザ自動化ツールを使用して、人間がするように機能をエンドツーエンドでテストし、ユニットテストが見逃すバグをキャッチします。
コーダーでない方は、Co-workでこの計画への執着を見ることができます。タスクの連続シリーズを公開し、サブエージェントでそれらのタスクに取り組みます。
これがClaude Codeの表面下のアーキテクチャです。実際のターミナル、シェル、環境変数、SSHキーで実行されます。Anthropicのエンジニアはこの哲学を「bashがあればすべて十分」と表現しています。
エンジニアの方なら、ここで笑うでしょう。何十もの特殊なツールを構築するのではなく、エージェントはgrepやgit、npmのような組み合わせ可能なUnixプリミティブを使用し、それらを連鎖させて実際に非常に有用なツールをオンザフライで作成します。
これによってコンテキストウィンドウが非常に無駄のないものになります。なぜならツールの説明はコストが高いからです。そしてエージェントに人間のエンジニアが持つであろうすべてへのアクセスを与えます。
トレードオフは、信頼境界があなたのワークステーション全体であることです。コンピューターをそれに信頼させる必要があります。
OpenAIのハーネス哲学:リポジトリを記録のシステムに
OpenAIのハーネスエンジニアリングチームは、異なる出発点から異なるアーキテクチャに到達しました。彼らはCodexエージェントのみを使用して5ヶ月間で100万行の内部製品を構築した詳細な説明を公開しました。手動で書かれたコードはゼロ行、約1,500のプルリクエスト、当初はわずか3人のエンジニアによって駆動されました。
彼らの中心的な洞察は、予想されるものとほぼ正反対でした。初期の進捗は予想よりも遅かったのですが、それはCodexがコードを書けなかったからではなく、環境が十分に仕様化されていなかったからです。エージェントは高レベルの目標に向かって進捗するための構造、ツール、フィードバックメカニズムを欠いていました。
OpenAIの対応は、リポジトリをすべての記録のシステムにすることでした。アーキテクチャの決定はそこにあります。アライメントのスレッドもそこにあります。製品原則もそこにあります。リポジトリにないものはエージェントに判読できず、したがって存在しませんでした。
彼らは1つの大きなagents.markdownアプローチを試しましたが、本当に失敗しました。すべてが重要だとマークされると、本当に何も重要ではなくなります。そしてファイルはルールの墓場ですぐに腐ってしまいます。
代わりに、OpenAIはエージェントがナビゲートできる集中的なクロスリンクドキュメンテーションの段階的開示システムを構築することにしました。彼らは検証された依存関係の方向と限定された許容エッジを持つ厳格な階層アーキテクチャを強制し、すべてを多くのリンターでチェックしました。これらのリンター自体もCodexによって書かれました。
リンターのエラーメッセージは巧みに修復指示として二重の役割を果たしました。エージェントがアーキテクチャルールに違反すると、エラーが違反の修正方法を教えてくれるのです。
これがCodexの表面下の構造です。そして私たちはこれを知っています。なぜなら彼らが教えてくれたからです。秘密を話しているわけではありません。公開されています。
隔離されたクラウドコンテナでタスクを実行します。あなたのコードはそのコンテナにクローンされます。インターネットアクセスはデフォルトで無効です。そしてエージェントは独立して作業します。
Claude Codeがエージェントにあなたの環境への完全アクセスを与え、段階主義と人間の監視を通じてリスクを管理するのに対し、Codexはエージェントの環境を制約し、隔離と本当に機械的な強制を通じてリスクを管理します。
Anthropicのハーネスがエージェントに記憶させるのに対し、OpenAIのハーネスはコードベースに記憶させます。両方とも同じ問題を解決することに関心があります。多くのセッションにわたってAIから信頼できる仕事をどう得るか。しかし彼らはこの問題を、組織的知識がどこにあるべきかについて genuinely異なる理論を通じて解決しているのです。
実務者の視点:Calvin French Owenの使い分け
Codex Webプロダクトの立ち上げを手伝い、今は両方のツールを広範に使用しているCalvin French Owenは、実際的な結果を説明しています。
彼は自分の時間がどれだけあるか、そしてどれだけ長く自律的に実行させたいかの関数としてコーディングエージェントを選びます。彼はClaude Codeを計画、ターミナルの編成、コードベースの部分がどう機能するかの説明に使用します。Opusは同時に複数のサブエージェントをスピンアップし、探索を非常に高速なHaikuインスタンスに委譲します。Calvinの言葉で言えば、開発者が言及するのを忘れたことを提案する点でより創造的です。
Codexは実際のコードに使用します。なぜならCalvinによれば、Codexのコードは単純により少ないバグを持つからです。そこで彼はClaude Codeで始めてそれを開いたままにし、実装の準備ができたらCodexに切り替えます。時々、CodexにClaudeの作業をレビューさせると、Claudeが見逃した間違いをキャッチします。
Calvinはこれらを交換可能なツールとは全く見ていません。代わりに、異なる種類の投資に報いる補完的なアーキテクチャと見ています。ハーネスが彼がこれらの製品をどう使えるかを形作っているのです。
ハーネスの分岐を構成する5つの要素
これらのハーネスの中で分岐している、それらを仕事にとってこれほど異なるものにしているのは何でしょうか。私はこれについてシンプルかつ明確に語っている人を見つけられませんでした。だから私がただ言います。
これらのプラットフォーム間のアーキテクチャのギャップは1つのことではありません。少なくとも5つのことであり、すべてが異なる方向に同時に複利的に作用しています。そして両社からの一次資料は、これらの選択がどれほど意図的で異なる動機によるものかを明らかにしています。
1. 実行哲学の分岐
まず、実行哲学がどう分岐しているかについて話しましょう。Anthropicの立場は非常に意図的に「bashがあればすべて十分」です。
長い説明を持つ多くの特殊なツールを構築するのではなく、Claude CodeはエージェントにgrepやgitのようなUnixプリミティブへのアクセスだけを与え、それらをパイプで連鎖させます。bashの1行でデータベースをクエリしたり、結果をフィルタリングしたり、ファイルに書き込んだりできます。これは3つの別々のツールを書くよりもトークンではるかに安価で、はるかに柔軟です。
ML6チームの分析では、GitHub MCPサーバーの38のツールが15,000トークン相当のツール説明を消費することが示されました。GitHub CLIは、コンテキストウィンドウではるかに少ないトークンで同じ機能を実現します。
言い換えれば、GitHub CLIは、創造的なツールを使うエージェントがUnixプリミティブだけで非常に多くのことを成し遂げられるようにし、企業や他のハイパースケーラーがAIに必要だと考えがちな特殊なツールの多くを回避できるのです。
これがAnthropicがテーブルにもたらす実行哲学です。
一方、OpenAIはChrome DevTools Protocolをランタイムで直接Codexエージェントに配線しました。これによってDOMスナップショット、スクリーンショット、ナビゲーション機能へのアクセスが得られ、UIのバグを再現し、実際にアプリケーションを駆動することで修正を検証できます。
また、すべてのCodexエージェントに独自の一時的な可観測性スタックを与えました。VictoriaLogsとVictoriaMetricsがGitワークツリーごとにスピンアップし、作業が完了すると消えます。これによってエージェントはセッション内でログとメトリクスをクエリできます。
「サービスを800ミリ秒未満で起動させる」というプロンプトがテスト可能な受け入れ基準になります。なぜならエージェントが実際に起動時間を測定できるからです。そしてエージェントが測定できなければ、改善もできません。
これらの哲学は両方ともエージェントに手を与えますが、一方はあなたの手、つまりあなたの実際の環境への完全アクセス、組み合わせ可能で強力で、そして聞こえる通り正確に危険なものを与えます。もう一方は制御された部屋でカスタムの手を構築し、デフォルトでより安全ですが、あなたが既に使っているツールにアクセスする能力は低くなります。
これが、Codexがデフォルトでより多くのツールを構築しなければならないと私が考える理由の一部です。なぜならCodexはあなたのローカルシステムにアクセスできないからです。
2. 状態と記憶
状態と記憶についてはどうでしょうか。どう分岐しているのでしょうか。
Anthropicのハーネスは構造化された成果物でクロスセッションメモリ問題を解決します。彼らのエンジニアリングレポートは、すべてのコーディングエージェントがセッション開始時に読み、終了時に更新するclaude-progress.txtのような進捗ファイルと、JSONとして保存される機能リストについて説明しています。
これらのファイルとgitコミットを組み合わせることで、任意の新しいエージェントインスタンスが辿れる軌跡が作成され、プロジェクトがどこにあり、次に何をすべきかを把握できます。
claude.mdファイルのような成果物に投資する開発者は、複利的な資産を構築することになります。より多くのコンテキストが蓄積されるほど、その後のClaudeセッションすべてがより良く機能します。
OpenAIのアプローチは組織的記憶をリポジトリに押し込みます。リポジトリにないものは判読できず、存在しません。なぜならエージェントがサンドボックスで動作しているからです。
アーキテクチャの決定、バグの原則、すべてがドキュメンテーションとしてエンコードされます。興味深いことに、OpenAIはエージェント生成コードに固有のエントロピー問題を発見しました。Codexはリポジトリに存在するパターンを複製しますが、不均一または最適でないパターンも含まれ、これは必然的にドリフトにつながります。
彼らの最初の対応は、毎週金曜日に「AIスロップ」と呼ばれるものを手動でクリーンアップすることでしたが、スケールしませんでした。よりスケーラブルに対処するため、彼らはゴールデン原則をリポジトリにエンコードし、バックグラウンドのCodexタスクが逸脱をスキャンし、ターゲットを絞ったリファクタリングPRを開く自動クリーンアッププロセスを構築しました。
これによってリポジトリが最終的に自らを監視できるようになります。一方のハーネスはエージェントに記憶させ、もう一方はコードベースに記憶させます。両方とも機能しますが、どちらも他方にきれいに転送されません。なぜなら、チームがclaude.markdownファイルに行ったすべての投資は、リポジトリを見るように訓練されたCodexにはあまり役に立たないからです。
3. コンテキスト管理
コンテキスト管理も、これらのハーネスが分岐するもう1つの場所です。両社はコンテキストについて同じ教訓を学びました。それがキュレーションされていなければ、多ければ良いというものではありません。
OpenAIは1つの大きなagents.markdownアプローチを試しましたが、失敗しました。Anthropicは異なる方向から同様の原則に到達しました。
すべての利用可能なツール説明を最初にシステムプロンプトに読み込むのではなく、Claudeはツールとスキルをファイルシステム上のファイルとして保存します。なぜならローカルコンピューターへのアクセスがあるからです。そしてエージェントがジャストインタイムでそれらを取得できるようにします。
ツール検索ツールによって、エージェントは事前ロードされるのではなく、利用可能な機能をセマンティックに検索できます。
ここでの実際的な違いは、Claude Codeがコンテキストウィンドウの圧縮とサブエージェントへの委譲を通じてコンテキストを管理する傾向があることです。つまり、古いコンテキストを自動的に要約し、それぞれが独自のウィンドウを持つ並列エージェントをスピンアップして、物事をクリーンに保ちます。
Codexはより多くの隔離を持っています。各タスクはきれいなサンドボックスで実行され、タスクはスペースを競合しません。
これは、1つのタスクがコードベースの深い理解を必要とする場合にClaudeがより優れていることが多く、独立したタスクを並列で実行していて、中央のコンテキストウィンドウを汚染せずにそれらのタスクに対してトークンを消費したい場合にCodexがより優れていることを意味します。
4. ツール統合
ツール統合についてはどうでしょうか。AnthropicはModel Context Protocol(MCP)を作成しました。これはAIエージェントを外部ツールに接続するための基本的なオープンスタンダードです。
現在、OpenAI、Google、Microsoft、みんなに支持されています。Linux Foundationによって管理されています。Claude CodeはMCPを中心に最初から構築されました。
しかし、より興味深いハーネスの洞察は、両社がコンテキストウィンドウ内のツール統合のコストをどう処理するかです。Anthropicはスキルを導入しました。これは本当にただのMarkdownファイルとファイルシステムに保存されたスクリプトです。
エージェントはスキルの短い名前と説明、基本的に最初の50または100トークンだけを見て、完全な指示は見ません。完全な指示は数千トークンに及ぶ可能性があります。
つまり、エージェントは使用することを決定したときにのみ完全なスキル定義を読みます。これはハーネス設計としてのコンテキスト管理です。ツール統合レイヤーは意図的にトークンについて吝嗇になるように設計されています。
OpenAIのCodex App Serverは非常に異なるアプローチを取ります。これはあなたのスタックと並行して実行される双方向JSON RPCハーネスで、gitやテストランナー、Chrome DevTools、アプリログ、メトリクスなどのツールをRPCエンドポイントとして公開します。
エージェントはこれらのツールをプログラム的に呼び出します。ハーネスはワークツリーごとのインスタンスをスピンアップし、スクリーンショットとDOMスナップショットをキャプチャし、それらのシグナルを使って修正を検証できます。
統合は深いですが、アーキテクチャはエージェントがあなたのマシン上ではなくクラウド内のサーバー媒介環境で作業していることを前提としています。
両方のツールがMCPを話しますが、統合哲学は非常に異なります。実際、非常に異なるため、ComposioのテストチームはCodexをFigmaとJiraのMCPと連携させるためにカスタムプロキシアダプターを構築しなければなりませんでした。
AIコーディングエージェントをエンタープライズツールチェーンに統合する場合、エージェントがJiraから読み取り、GitHubにプッシュし、Slackを更新する必要がある場合、プロトコルの下の実装の深さはプロトコル自体と同じくらい重要です。
5. マルチエージェントアーキテクチャ
最後に、マルチエージェントアーキテクチャについて話したいと思います。Claude Codeのエージェントチームは、それぞれが専用のコンテキストウィンドウと共有タスクリスト、依存関係追跡を持つ複数のサブエージェントを生成します。
1つのサブエージェントがAPIを構築している間、別のサブエージェントがフロントエンドを構築し、3番目がテストを書き、途中でお互いにメッセージを送ることができます。
探索サブツールは、非常に高速で安価なモデルであるHaikuを使用して大量のコードを処理し、それをすべてOpusに返して意思決定を行います。これは非常にオーケストレーションされた協力モデルです。コーディネーターがワークフローを管理し、システムは戦略的監督者として人間をループ内に保つように設計されています。
Codexのマルチエージェントアプローチは、各タスクを独自の隔離されたサンドボックスで実行します。調整はコードベース自体を通じて行われ、通常はマージされるgitブランチを介して行われます。
OpenAIの実験的なサブエージェントサポートは向上していますが、Calvin French Owenは、並列性がClaude Codeが委譲を処理する方法と比較してまだ完全には達していないと指摘しています。
トレードオフは、Codexの隔離モデルが自律運用にとって本質的にはるかにはるかに安全であることです。エージェントは互いに干渉できず、互いの状態にアクセスできず、障害を連鎖させることができません。
実践者の視点:1年間の進化
Claude Codeの進化に関する最も詳細な実践者の記録の1つであるEmergent Mindsからの1年間の回顧は、この分岐をリアルタイムで記録しています。
著者はツールの過去1年間の5つの明確な時代を説明し、それぞれが以前のアプローチを原始的に見せています。roadmap.markdownやultrathinkorScratchpadのようなコミュニティの回避策は、1年間にわたってClaude Codeのネイティブハーネス機能に体系的に吸収されました。
彼のメタ観察は、「CLIツーリングレイヤーには堀がない。良いパターンはすべて製品に吸収される」というものです。
ハーネスは高速で進化しており、すべての側面でそうです。問題は今日どのハーネスが優れているかではありません。どのハーネスの進化軌道があなたのチームが向かっている場所と一致するかです。
ツール比較から戦略問題へ
ここで、これは単なるツール比較から戦略問題になります。Calvin French Owenのスキル進化は、ハーネスロックインが実際にどう複利的に作用し、チームに影響を与えるかについて多くを語っています。
彼は最初に/commitスキルを追加することから始めました。一貫した方法でコミットしてプッシュするようモデルに伝えるだけです。しかしその後、別々のワークツリーで作業するエージェントが必要になりました。そこで/worktreeを追加しました。そして常に最初に計画することに気づきました。
そこで、始めたいときに/implementを追加しました。その後、implementの呼び出しを連鎖させ始めました。そして最終的に、実装を容易にするためにimplement allを追加しました。
彼が環境を構築しているのがわかります。少なくとも6つのワークフロー自動化の複数のレイヤーを持っていました。それぞれが前のものの上に構築されています。それぞれがClaude Codeのハーネスアーキテクチャ、そのスキルシステム、コンテキストフォーキング、サブエージェントモデルに特化しています。
別のハーネスに移行することは、新しいコマンドを学ぶだけではありませんでした。同じ抽象化をサポートしていないかもしれないアーキテクチャで、複利的な自動化チェーン全体をゼロから再構築することを意味しました。
では、この小さな課題をチーム内のすべてのエンジニア、彼らが触れるすべてのプロジェクト、蓄積したすべてのMarkdownファイル、デプロイしたすべてのMCPコネクターで掛け算してください。
それが人々がモデルについて話すときに価格に織り込んでいないロックインです。そしてそれがハーネスを理解することがとても重要な理由です。
組織はこれらのツールの周りにワークフローを構築しています。単にサブスクリプションを採用しているだけではありません。特定のエージェントアーキテクチャの周りに組織的知識、プロセスドキュメンテーション、検証プロトコルを構築しているのです。
クラウド戦争との類似性
これは初期のクラウド戦争にやや類似しています。2010年、AWSとAzureは両方とも仮想マシンとオブジェクトストレージを提供しているので基本的に同じだと企業に言うことができました。技術的には正しかったでしょうが、戦略的には間違っていました。
それらのアーキテクチャ間の違いを理解していた組織、AWS LambdaがAzure Functionsとは異なる方法でアプリケーション設計を再形成することを把握していた組織。それらの組織は正しい決定を下すのに十分理解していました。
そしてそれが今日私がハーネスについて話している理由です。なぜなら私たちはAIに関して同じレベルの流暢さが必要だからです。私たちはAIコーディングツールの2010年代にいます。モデルはベンチマークで似ているように見えます。アーキテクチャは分離し、2年後、2028年に特定のアーキテクチャで何が可能かを決定する線に沿って分岐しています。そして調達決定はベンチマークスコアを見ている人々や、モデルがすべてだと考えている人々によって行われています。
あなたにとって何を意味するか
では、これはあなたにとって何を意味するのでしょうか。
生計を立てるためにコードを書いているなら、1つのツールを選ぶ時代は終わりつつあります。今日最も多くの価値を引き出している開発者は、両方のプラットフォームを使用し、タスクが必要とするものと自分が持っている時間に基づいて作業をルーティングしています。
私はCalvin French Owenのワークフローについて話しました。CodexとClaude Codeの両方を含む他の多くのワークフローがあります。
スキルはそれらのツールのいずれかを使うことにあるのではありません。実際、どのハーネスの傾向が今日行っている作業の種類と一致するかを知ることにあります。そしてそれが、このビデオでこれらのハーネスがどう機能するかについて詳細に多くの時間を費やした理由です。
今エンジニアリングチームをリードしているなら、行っている決定は、どのツールを標準化するかではありません。どのアーキテクチャ哲学を中心にチームを組織するかです。そしてハイブリッドワークフローを構築する場合、その境界を越えて作業をどのように知的に引き継ぐかです。
これは非常にプロセス設計の問題であり、調達の問題ではありません。チームは現在タスクルーティングをどう処理していますか。1つのエージェントを使って他のエージェントの作業をチェックしていますか。claude.markdownファイルに投資していますか。Claude Codeの完全アクセスローカル実行対Codexのサンドボックス隔離のセキュリティ上の影響をどう処理しますか。
これらの質問はベンダー比較チャートには現れませんが、エンジニアリングリーダーとしてあなたの心の片隅にあるべきです。
これを正しく理解する組織は、ハーネスの決定をアーキテクチャのコミットメントとして扱うだけでなく、私たちの他の非技術的知識労働者が2026年後半に世界をどう経験するかを形作る決定を下すことになります。なぜならこれらのハーネスは知識労働の残りの部分に漏れ出しているからです。
だからこそこのビデオでCo-workへの言及をしました。Claude CodeはCo-workの基盤でした。Co-workは基本的に知識労働のためのClaude Codeの上のスキンであり、理由があって非常に人気になっています。
ですから、これらのハーネスとこれらの根本的に異なるアーキテクチャアプローチが、2026年の残りでマーケティング、製品、カスタマーサクセスの残りに漏れ出していくことを期待すべきです。
非技術的なシニアリーダーであり、これらのツールについて予算決定を行っている場合、チームがレンチを買うように頼んでいるのではないことを理解する必要があります。
ワークベンチ、1つか2つのワークベンチ、そして本当に人間とAIエージェント間の関係を組織する方法へのコミットメントを求めています。それはビジネス全体でのあなたの速度を形作り、セキュリティ体制を形作り、雇用能力と今後何年にもわたる切り替えコストを形作るでしょう。
ですから、正しい質問はどのツールが最も安いかではあり得ません。どのアーキテクチャ哲学がチームの働き方と一致するか、そして私たちが考えを変えるのにどれだけのコストがかかるかである必要があります。
2番目の質問への答えは通常たくさんあり、四半期ごとに上がっていきます。なぜなら四半期ごとにチームが選択した現在のアーキテクチャの周りにより多くのインフラを構築しているからです。
本当の質問とは
見てください、誰もが尋ねている質問、どのモデルが最高か。私は言い続けています、それは2022年または2023年の質問です。賞味期限が非常に短いのです。モデルは常に改善し続けています。はい、任意のリリースでモデルが得る利点は一時的です。はい。
しかし、その下にある本当の質問は十分に尋ねられていません。私たちはAIで最も重要な2つの企業が、人間とAIエージェントがどう協力すべきかについてgenuinely異なる賭けをしているのを見ています。
そして彼らは非常に強くそれを信じているので、文字通りそれらの特定のハーネス内で機能するようにモデルを訓練しています。
ハーネスの決定を戦略的コミットメントとして扱うべきです。なぜならそれはそういうものだからです。
そして、簡単な方法でハーネスを理解する時間を取らなければ、私たちは皆、困難な方法でハーネスロックインを発見することになるでしょう。そしてそれが私がこのビデオを作った理由です。
より詳しい情報はSubstackで
これに関してSubstackでもっと多くのことがあります。ハーネスを理解することが本当に重要だと思います。どのハーネスがあなたとあなたのワークフローに適しているかを理解する機会を自分に与えるために、もっと多くをそこに載せるつもりです。
そして、あなたが非コーダーや非技術者であっても、そこにはあなたのためのガイドの部分もあることを確認します。他のみんなは困難な方法でロックインを発見するでしょう。私はあなたに簡単な方法でそれを発見してほしいのです。そしてそれが私がこのビデオを作った理由です。
どのハーネスがあなたに適しているかを理解する方法についてのより詳細がそこにあるSubstackがあります。そして非コーダーの方にも、詳細があります。
これが技術的なビデオのように感じられたことは分かっています。ハーネスの技術的詳細を少し理解する必要があります。なぜならそれが2026年後半に向けて私たちの仕事すべてを形作っているものだからです。
これらのモデルは、1980年から2018年までに必要だったよりももう少し技術的な流暢さを必要とします。そしてそれを和らげる方法はありません。
LLMを理解することは、私たちが快適に感じるよりも少しだけ深く掘り下げる意欲を必要とします。そしてそれは今、テックのすべての非技術的労働者が取り組んでいることです。
そして私はただあなたに言いたい、私があなたをサポートします。私たちはこのようなことを説明し続けます。これがあなたが理解できる方法で技術的なことを説明する最後のビデオではありません。なぜなら、それが私がこれらすべてのアナロジーをずっと使った理由だからです。
それが私たちが瓶の中の脳について話した理由です。それが私たちが手と足とフランケンシュタインの怪物について話した理由です。私はあなたにハーネスのようなものが抽象的すぎる、理解するのが難しすぎると感じてほしくないのです。本当にそうではありません。それは本当にモデルに手と足を与えるだけです。
そしてそれが誰もが話している以上に重要であることが判明しました。だから今日それをカバーしたのです。頑張ってください。
コメント