新しい AI スタック：モデル、ハーネス、ループ、そして自己改善型エージェント

みんな AI モデルの話ばかりしている。

誰も、それらを実際に役立つものにしているレイヤーについては話していない。

Claude Code。Codex。Cursor。

これらは単なるモデルではない。

それらはシステムに包まれたモデルだ。

そのシステムはハーネスと呼ばれる。

そして、最高のハーネスは今や自分自身を改善する。

新しい AI スタックについて理解すべきすべてがここにある。

誰もが信じている AI プロダクトに関する嘘

ほとんどの人は、AI の進歩 = より賢いモデルだと思っている。

そうではない。

モデルはスタックの一部に過ぎない。

アーキテクチャは公開されている。誰もが同じトランスフォーマーをコピーする。すべての研究所が同じ構成要素を使っている。

Claude Code と週末プロジェクトを実際に分けているのは、モデルではない。

モデルを取り巻くものだ。

ハーネスである。

2017 年、AI の進歩はアテンション機構に関するものだった。2020 年にはスケールに関するものだった。2026 年、それはハーネスエンジニアリングに関するものだ。

そしてハーネスは今、人間ではなく AI によって設計されている。

ハーネスとは何か？

ハーネスとは、モデルを取り巻くシステムのことだ。

それは決定する：

→ モデルがどのように考え、計画するか

→ いつツールを呼び出し、その結果をどうするか

→ ステップ間で何を記憶するか

→ アーティファクトをどのように保存し、状態を管理するか

→ 自身の出力をどのように評価するか

→ いつループバックして再試行するか

オペレーティングシステムのように考えてみよう。

モデルが CPU だ。ハーネスが OS だ。

強力な CPU とひどいソフトウェアを持っていても、役に立つものは何も出荷できない。控えめな CPU と優れたソフトウェアを持っていれば、素晴らしいものを出荷できる。

最も成功しているコーディングエージェント（Claude Code、Codex、Cursor）はすべて、同じ洞察を持っている：

ループはモデルと同じくらい重要である。

すべての AI ビルダーが必要とする 3 つのハーネスパターン

すべての本番 AI システムは、これらの少なくとも 1 つを使用している。

パターン 1: ループ

モデルは一度答えて止まるわけではない。

ループする。

計画 → 実行 → 観察 → 改善 → 繰り返す

これはすべてのコーディングエージェントの中核である。

簡略化された Claude Code のループ：

1. タスクを読む
2. アプローチを計画する
3. コードを書く → 実行する
4. 何が失敗したかを見る
5. 修正する
6. 再度実行する
7. テストが通るまで繰り返す

モデルはループ 3 の方がループ 1 より賢いわけではない。

しかし、システムは賢くなる。

各ループはモデルに新しいコンテキスト（エラーメッセージ、テスト結果、実行トレース）を与える。

ループ 1 の出力がループ 2 の入力になる。

この複合的なコンテキストこそが、エージェントシステムが複雑なタスクにおいて単発のプロンプトよりも優れている理由である。

重要な洞察： モデルは固定されたまま。コンテキストが賢くなる。

パターン 2: ファイルシステムとしてのメモリ

ほとんどの開発者は、すべてをコンテキストウィンドウに詰め込む。

これは罠である。

長期にわたるタスクは以下を生成する：

→ 実験ログ

→ コード差分 → エラートレース

→ 過去のロールアウト履歴 → 論文要約 → 中間アーティファクト

それらすべては、どんなコンテキストウィンドウもはるかに超えて成長する。

解決策：コンテキストではなく、ファイルに書き込む。

1# 悪い例：すべてをコンテキストに
2context = previous_output + tool_result + error_log + history...
3# ステップ 47 で爆発する
4
5# 良い例：ファイルシステムを使う
6agent.write("experiments/run_3/error_log.txt", error_trace)
7agent.write("experiments/run_3/results.json", metrics)
8
9# 後で、エージェントは必要なものだけを読む
10relevant = agent.read("experiments/run_3/results.json")

これにより、長期タスクに関するすべてが変わる。

→ エージェントはクラッシュ後に再開できる

→ エージェントは自身の実行履歴に基づいて推論できる

→ ステップ 200 でもコンテキストはクリーンなまま

→ 複数のサブエージェントがファイルを介して状態を共有できる

最高のエージェントは、ファイルシステムを第二の脳のように扱う。

単なるダンプではない。構造化されたメモリである。

パターン 3: サブエージェント

1 つのエージェントですべてができるわけではない。

最高のシステムは、並列サブエージェントを生成する。

親エージェントは：

→ タスクを独立したサブタスクに分割する

→ サブエージェントを起動して並列実行する

→ それらのステータスを監視する → 結果をマージする

研究用ハーネスの例：

1親エージェントが受信：「完全な競合分析レポートを書いてください」
2
34 つのサブエージェントを同時に生成：
4→ サブエージェント 1：競合 A の価格と機能を調査
5→ サブエージェント 2：競合 B の価格と機能を調査
6→ サブエージェント 3：両競合に関する最近のニュースを検索
7→ サブエージェント 4：Reddit と App Store からユーザーレビューを取得
8
9親は待機し、4 つの出力すべてを最終レポートにマージ
10
11合計時間：最も遅いサブエージェントと同じ（4 倍ではない）

重要な設計ルール：サブエージェントの出力はファイルに保存すること。

一時的なコンテキストではない。ファイルである。

コンテキストにしか存在しない場合、サブエージェントのセッションが終了すると消えてしまう。

ファイルに存在すれば、親エージェントが検査でき、システムはクラッシュから回復でき、すべてが監査可能になる。

すべてのコーディングエージェントが使用するツール

エージェントを構築しているなら、これが主要なコーディングエージェントが標準化しているツールキットである。

1ファイルシステムツール：
2→ glob, grep, ls          # ファイルを検索
3→ read, read_many         # コンテンツを読む
4→ write                   # 新しいファイルを作成
5→ edit                    # 文字列置換編集
6→ apply_patch             # 構造化差分
7
8シェルツール：
9→ bash                    # 任意のコマンドを実行
10→ PowerShell              # Windows 版
11
12バージョン管理：
13→ git_status, git_diff    # 変更を検査
14→ git_commit              # 進捗を保存
15
16エージェント管理：
17→ spawn_agent             # サブエージェントを起動
18→ wait_agent              # 結果を待つ
19→ list_agents             # 実行中のものを確認
20→ interrupt_agent         # 必要に応じてキャンセル
21
22外部コンテキスト：
23→ web_search, web_fetch   # 最新情報を取得
24→ MCP ツール              # 外部サービスに接続

すべてのエージェントにこれらすべてが必要なわけではない。

しかし、本番エージェントは最終的にそのほとんどを必要とする。

初期に最も重要なもの：bash、read、write、edit。

これら 4 つをマスターすれば、ほとんど何でも構築できる。

コンテキストエンジニアリング：誰も語らないスキル

モデルは固定されている。

実行時にその重みを変更することはできない。

しかし、モデルが見るものを変更することはできる。

それがコンテキストエンジニアリングである。

そしてそれは今や、AI エンジニアリングにおいて最もレバレッジの効くスキルの 1 つである。

悪いコンテキスト：

→ すべてをダンプする → うまくいくことを願う

→ コンテキストが肥大化する → モデルの焦点がぼける → 出力が劣化する

良いコンテキスト：

→ 構造化されている。簡潔。進化する。

→ 適切なステップで適切な情報。

→ 以前の失敗が現在の試みに情報を与える。

最先端のアプローチ（ACE — Agentic Context Engineering）：

13 つのコンポーネント：
2
3Generator:   タスクを実行し、構造化されたコンテキストプレイブックを参照する
4Reflector:   成功と失敗を分析し、洞察を抽出する
5Curator:     新しい学習内容でプレイブックを更新する — 追加、削除、重複排除を行う
6
7プレイブックはプロンプトの塊ではない。
8それは（識別子、洞察）ペアの構造化されたリストである。
9
10例：
11{
12  "id": "001",
13  "insight": "再試行する前に、必ずエラートレースをファイルに書き込む。"
14},
15{
16  "id": "002",
17  "insight": "Web 検索用のサブエージェントは、サイト固有のクエリでより良い結果を返す。"
18},
19{
20  "id": "003",
21  "insight": "コミット前にテストを実行すると、回帰の 80% をキャッチできる。"
22}

プレイブックは実行ごとに更新される。

タスク 50 を実行するエージェントは、49 回分の抽出された学習内容を活用している。

タスク 1 を実行するエージェントには何もなかった。

これが、モデルの重みに触れずにシステムが賢くなる方法である。

自分自身を改善するハーネス

ここからが面白くなるところだ。

もしハーネス自体が最適化される対象だったらどうだろう？

プロンプトではない。モデルではない。

エージェントを実行するコードである。

これこそが、Self-Harness が行うことである。

3 ステップのループ：

ステップ 1 — 弱点を発見する

一連のタスクで現在のハーネスを実行する。失敗トレースを収集する。根本原因ごとに失敗をクラスタリングする。

「失敗した」ではない。なぜ失敗したか、である。

発見された失敗タイプ：

→ 「エージェントが長いファイル読み取りでタイムアウトする」

→ 「親がクラッシュしたときにサブエージェントの出力が失われる」

→ 「エラーメッセージが自己修正するのに十分な情報を提供しない」

→ 「ステップ 30 以降でコンテキストが大きくなりすぎ、モデルの焦点がぼける」

ステップ 2 — 修正を提案する

同じモデルが失敗パターンを見る。ハーネスコードに対する具体的で狭い範囲の編集を提案する。

書き換えではない。対象を絞った編集である。

提案されたハーネス編集：

→ ファイル読み取り操作にタイムアウトハンドラを追加

→ サブエージェントの出力を毎ステップ（最後だけでなく）ディスクに自動フラッシュ

→ エラーメッセージ形式を標準化し、ステップ、ツール、入力、出力、失敗理由を含める

→ 25 ターンごとにコンテキスト圧縮ステップを追加

ステップ 3 — 検証してマージする

提案された各編集は、保留されたタスクでテストされる。

弱点を修正し、他の何も壊さないか？

はいの場合：ハーネスにマージされる。いいえの場合：ログに記録され、却下され、ハーネスは変更されない。

結果：ハーネスは世代を重ねるごとに良くなる。

Self-Harness を実行した Claude 3.5 Sonnet は、SWE-bench Verified で 20% から 50% に向上した。

より良いモデルからではない。

より良いシステムからである。

進化的ハーネス探索

Self-Harness は 1 つのハーネスを反復的に修正する。

AlphaEvolve はハーネスの集団を実行し、最良のものを進化させる。

アルゴリズム：

11. ハーネス候補のプールから開始する
22. ベンチマークタスクでそれぞれをスコアリングする
33. 最もパフォーマンスの良いものを「親」として選択する
44. モデルに差分/改善を提案させる
55. 新しい「子」ハーネスを生成する
66. 子をスコアリングする
77. 改善されたものを保持する
88. プールに戻す
99. 繰り返す
10
11（自然淘汰と同じロジック。コードに適用。）

（自然淘汰と同じロジック。コードに適用。）

AlphaEvolve からの重要な設計詳細の 1 つ：

進化の対象となるコード領域は明示的にマークされる：

1# EVOLVE-BLOCK-START
2def plan_next_step(context, tools):
3    # このセクションは進化的探索によって変更される可能性があります
4    prompt = f"与えられた: {context}\n利用可能なツール: {tools}\n次のアクション:"
5    return llm.generate(prompt)
6# EVOLVE-BLOCK-END
7
8# ハーネスの残りの部分は固定されたまま
9def run_tool(tool_name, args):
10    return tool_registry[tool_name](**args)

この封じ込めにより、エージェントが誤って安全クリティカルなコードを変更するのを防ぐ。

進化的探索は、明示的に許可したものにのみ触れる。

AlphaEvolve はこれを使用して行列乗算アルゴリズムを最適化した。

結果：DeepMind の手動最適化コードを打ち負かした。

エージェントは、人間のエンジニアが何十年も発見していなかった解決策を見つけた。

ダーウィン・ゲーデルマシン：自分自身を書き換えるエージェント

このアイデアの最も極端なバージョン。

タスクをより良くこなすために、自身のハーネスコードを変更するエージェント。

ダーウィン・ゲーデルマシン（DGM）：

11. プール内の 1 つのコーディングエージェントから開始する
22. ベンチマークで実行し、スコアを収集する
33. エージェントが自身の評価ログを調べる
44. エージェントが自身のハーネスコードへの改善を提案する
55. 利用可能なツール：bash + ファイルエディタ（ファイルの表示/作成/編集）
66. エージェントの新しいバージョンが作成される
77. 新しいバージョンがスコアリングされる
88. より良い場合：プールに追加される
99. より悪い場合：破棄される
1010. 繰り返す — パフォーマンスによって親を選択し、子孫の数に反比例させる

開始条件：Claude 3.5 Sonnet + シンプルな初期ハーネス。

結果：

→ SWE-bench Verified: 20% → 50%

→ 多言語コーディングベンチマーク: 14.2% → 30.7%

モデルの重みへの変更はゼロ。世代間の人間によるエンジニアリングはゼロ。

エージェントは自分自身のより良いバージョンを設計した。

これは SF ではない。

これは 2025 年の論文である。

避けるべき 5 つの失敗モード

これらは実際の研究チームが失敗した方法である。

すべて文書化されている。すべて回避可能である。

1. コンテキスト崩壊

長期タスクは、ログが永続的なアーティファクトとして書き込まれない場合、重要な詳細を失う。

修正：重要なものはすべてファイルに書き込む。ステップ 20 を超えたら、コンテキストだけに頼ってはならない。

2. 実装ドリフト

タスクが技術的に難しくなると、モデルは実際の目標ではなく、より簡単で一般的な解決策にドリフトする。

修正：最初にスペックファイルを書く。エージェントはすべてのループでスペックをチェックする。

3. 過度の楽観主義

モデルは、実験が失敗したにもかかわらず成功を宣言する。

「数値的なごまかし」— 実際の問題を解決せずにメトリクスを良く見せるパッチ — を見つける。

修正：エージェントが決して見ることのないテストセットを保持する。保持されたデータでのみ検証する。

4. 報酬ハッキング

エージェントは与えられたシグナルを何でも最適化する。

シグナルが単体テストなら — 常にパスするテストを書く。シグナルが判定モデルなら — 判定モデルを騙すトリックを学ぶ。シグナルがベンチマークスコアなら — ベンチマークのアーティファクトを悪用する。

修正：評価者はループの外側にいる。重要な決定ポイントで人間によるレビューを行う。

5. 多様性の崩壊

進化的ループは 1 つの戦略に収束する。

すべての世代が同じ解決策のバリエーションのように見える。

修正：新規性を明示的に追跡する。既存のプールメンバーとあまりにも類似した解決策にペナルティを課す（埋め込みベースのコサイン類似度が機能する）。

平易な英語での新しい AI スタック

本格的な AI プロダクトを構築するときに、実際に構築しているものはこれである：

レイヤー 1 — モデル

生の知能。事前学習済み。実行時に重みは固定。

これが CPU である。強力だが受動的。

レイヤー 2 — ハーネス

OS。モデルをラップする。すべてをオーケストレーションする。

→ ツール（bash、ファイル読み取り/書き込み、Web 検索）

→ メモリ（ファイルシステム、構造化ログ）

→ ループ（計画 → 実行 → 評価 → 再試行） → サブエージェント（並列実行）

→ コンテキスト管理（各ステップでモデルが見るもの）

レイヤー 3 — オプティマイザー

ハーネスを改善するハーネス。

→ 実行トレースから失敗パターンを発掘する

→ ハーネスコードへの対象を絞った編集を提案する → 保留されたタスクで検証する

→ 改善をマージし、後退を破棄する

レイヤー 4 — 評価者

他のすべてのレイヤーの外側に存在する。

→ ベンチマークスコア → 重要な決定ポイントでの人間によるレビュー → オプティマイザーが決して触れない保持されたテストセット

どのレイヤーもスキップできない。

レイヤー 2 をスキップする — あなたのモデルはチャットボットであり、プロダクトではない。

レイヤー 3 をスキップする — 手動エンジニアリングなしではシステムは決して良くならない。

レイヤー 4 をスキップする — エージェントは間違ったものを最適化し、あなたは気づかない。

これが今、ビルダーにとって何を意味するか

これらのアイデアから利益を得るために、自己改善型ハーネスを構築する必要はない。

ここから始めよう：

週 1: ループを構築する

単発のプロンプトの構築をやめよう。複数のステップを要するタスクには、計画 → 実行 → 評価 → 再試行のループを構築する。

週 2: 永続メモリを追加する

コンテキストに頼るのをやめよう。中間出力をファイルに書き込む。エージェントが自身の以前の作業を読めるようにする。

週 3: サブエージェントを追加する

ワークフローの中で並列実行できる部分を特定する。サブエージェントを生成する。それらの出力をファイルに書き込む。マージする。

週 4: コンテキストエンジニアリングを追加する

成功と失敗につながるパターンを追跡する。実行ごとに更新されるシンプルな構造化プレイブックを構築する。

それがハーネスである。

モデルではない。

モデルはすでにそこにある。

ハーネスはあなたが構築するものである。

2026 年の AI に関する不都合な真実

フロンティアラボにおける研究の加速は劇的に増加している。

Anthropic と OpenAI はかつてない速さで出荷している。

モデルが一夜にして賢くなったからではない。

ハーネスが良くなったからである。

ループし、記憶し、サブ委任し、自己修正するエージェントは、間違った使い方をされたより賢いモデルよりも優れている。

堀はモデルではない。

堀はシステムである。

そしてシステムは今や自分自身を改善できる。

これが役に立ったなら：

→ リポスト — すべての AI ビルダーはこのスタックを理解する必要がある

→ @sairahul1 をフォローして、このような解説をもっと見る

→ ブックマーク — 4 層スタックだけでも保存する価値がある

さらに興味深い記事については、theaibuilders.co に登録してください

私は AI、プロダクト構築、そしてあなたなしで機能するシステムについて書いています。