AIエージェントが「自分を改善する」仕組みとは
AIエージェントが自身の動作環境（プロンプト、ルールセット、ツール定義、分類体系など）を観測し、改善案を提案する仕組みを「メタハーネス」と呼ぶ。コーディングエージェントやパーソナルAIの領域では既に実装が進んでいて、Stanford / KRAFTON / MIT による Meta-Harness 論文（Lee et al., 2026）や、UBC / Meta / Edinburgh らによる HyperAgents（Zhang, J. et al., 2026）といったプレプリントが並行して出ている状況だ。
問題は、個人向けツールで動いている設計理論をそのまま企業の運用環境に持ち込もうとすると、複数の前提が根本から変わることだ。この「何が変わるのか」を正面から論じた設計論として、Zenn に公開された本稿は読む価値がある。
なぜ今これが論点になるのか
メタハーネスが機能しやすいのは「評価関数が明確で、改変対象が単一プロセス内に閉じている領域」だ。個人の作業自動化や単一ドメインのコーディングエージェントがまさにそこに当たる。
一方、企業環境では話が変わる。監査要件、複数部署の利害、コンプライアンス制約、承認フロー——これらが絡まると、「観測できるデータ」と「AIが改変を提案してよいデータ」は全く異なる集合になる。企業データの多くは改竄不可で扱われる必要があり、メタハーネスが実際に触れる「Type B」領域（プロンプトテンプレート、スキル定義、ワークフロー定義、分類体系など）は極めて限定的になる。この非対称性を設計に織り込まずに動かし始めると、何が起きるか。
設計の核心：責任範囲の分離
本稿が最初に明確にしているのは、「エンジニアの責任範囲」と「メタハーネスの責任範囲」の分離だ。
エンジニアの仕事は、エージェントの職務範囲そのものを定義すること、改善対象の境界を設計すること、承認権限の階層を決めることだ。メタハーネスの仕事は、その境界の内側で観測し、提案し、承認パイプラインに送り出すことだけ。「どんな機能を実装するか」「要件の発散をどう抑えるか」はメタハーネスに委ねる判断ではない。
これは当たり前に聞こえるが、実装が進むにつれて境界が溶けていく。「便利だからツールを足す」「状況を見ながら調整する」という判断を重ねていくと、エージェントのスコープは構造的に広がり続ける。
具体的に何が起きるか：ツール数と精度の話
ここからは数字の話をする。
Berkeley Function Calling Leaderboard（Patil et al., 2025, ICML）を中核とする研究群は、ツール数が増えるほどLLMの正しいツール選択精度が急落することを繰り返し示してきた。Gan & Sun（2025）のRAG-MCPは、MCP stress testにおいてベースライン手法のツール選択正答率がツール候補数の増加に伴い13.62%まで低下し、retrievalベースのツール選択導入によって43.13%へと3倍以上に改善することを示している。さらに、position 100以降の評価では選択失敗が成功を上回る領域に突入することも報告されている。
Anthropicの内部測定では、58個のツール定義が約55,000トークンを消費する。LiveMCPBench（arXiv:2508.01780）による12のフロンティアLLMを対象とした実環境評価では、Claude-Sonnet-4が78.95%のタスク成功率に到達した一方、大半のモデルは30〜50%の範囲に留まり、失敗の約半数がツール検索段階の誤りに起因していた。
ここで見えてくる設計上の含意は単純だ。「念のため使えるツールを増やしておこう」という判断は、今使っていない選択肢が、これから使う選択肢の精度を確実に下げる。スコープの広さはそれ自体がコストであり、しかもそのコストは後払いで累積する。
「改善」と「仕様変更」は別物である
本稿が提示するもう一つの重要な区別が「改善（improvement）」と「仕様変更（spec change）」の分離だ。
プロンプトテンプレートの修正、分類カテゴリの細分化、エラーハンドリングロジックの調整——これらは改善だ。新しいツールの追加、新しいデータソースへの接続、エージェントの担当タスクの拡張——これらは仕様変更であり、メタハーネスの自動ループの中で発生してはならない。
なぜか。仕様変更を許せば、改善ループは「このエラー解消には新しいAPIを呼べる必要がある」→その APIが新しい信号源になる→新しいエラーパターンが観測対象になる→またcapabilityが必要になる、という連鎖を止められなくなる。表面上は「継続的改善」をしているように見えて、エージェントの実体は元の設計から完全に乖離していく。
ただし、この境界は現場では常にクリアに引けるわけではない。たとえば「エラー分類カテゴリの細分化」は一見改善に見えるが、新しい区別を成立させるために認証フローのトレースデータが新規に必要になる場合、それは新しい信号源の追加——仕様変更に該当する。表面的な変更の規模ではなく、実装の前提条件が変わるかどうかで判断する必要がある。
実務への示唆：設計コストはいつ払うか
ここからは見方の話だが、この設計論が実務に持つ最も重要な含意は「設計コストの前払い」という原則だと思う。
本稿が明確に述べているように、「まず運用を開始し、状況を見ながら調整する」という方針は、企業文脈では成立しない。信号源、改変対象、評価基準——これらを事前に定義しなければBoundedな改善ループはそもそも動かせないし、事後に定義しようとすると、すでに動いているシステムの構造を遡及的に変更することになる。
これはどういう意味か。企業AIエージェントの導入プロジェクトで「まずPoCを動かして、ユースケースを探りながら精緻化する」というアプローチは広く使われているが、メタハーネスを前提に設計するなら、PoCの段階で少なくともLayer 1（エージェントのスコープ）をTOMLやYAMLの設定ファイルとして書き切る習慣が求められる。これを先送りにすると、後でメタハーネスを組もうとしたときに「改善対象が何かが定義されていない」という問題に直面する。
もう一点。本稿はAIが自律的にハーネスを書き換え続けるシナリオを、現時点のハルシネーション制御では「実用域にない」と明確に判断している。Claude CodeやCodex CLIに代表されるPRワークフロー——AIがコード変更案を生成し、人間の承認を経て本番に反映する運用——は既に本番稼働しており、それは否定していない。問題は「完全自律的な自己改変ループを企業の業務システム本体に対して回す」形態だ。この線引きは今後も論点になるはずで、ハルシネーション制御の精度がどこまで上がれば「実用域」と判断できるのかは、まだ誰も明確な基準を持っていない。
まとめに代えて
「AIに自分を改善させる」という発想は魅力的だが、企業環境でそれを動かすには、先に人間が決め切らなければならないことが思った以上に多い。何を観測させるか、何を提案させるか、何には絶対に触れさせないか——この設計を曖昧にしたまま運用を始めると、AIは技術的に筋の通った越境提案を出し続け、運用側はそれを却下し続けるだけになる。それは「AIが使えない」のではなく、「ハーネスの設計が機能していない」という問題だ。
