COLUMN
コラム
2026年11月05日
Lilian Weng氏が3週間でOpenAIに呼び戻された理由。ハーネスエンジニアリングの次を告げる"自己改善AIエージェント"の正体
1. ハーネスエンジニアリングは終わっていない。むしろ"次の章"が始まった

ハーネスエンジニアリングという言葉が、開発現場でようやく定着してきた。AIエージェントの性能を決めるのはモデルそのものではなく、モデルを取り巻く「ツール・メモリ・制御フロー」の設計だ——という考え方は、この1年で多くのチームの共通言語になった。
ところが2026年7月、この議論は静かに次のフェーズへ進んだ。元OpenAIのセーフティ&リサーチ担当バイスプレジデントで、2025年2月にThinking Machines Labを共同創業したLilian Weng氏が、自身のブログ「Lil'Log」で「Harness Engineering for Self-Improvement」という論考を公開した。ハーネスの設計そのものをAIに最適化させる——いわゆる再帰的自己改善(RSI, Recursive Self-Improvement)への現実的な道筋を描いたこの記事は、業界に小さくない衝撃を与えた。
そして衝撃はもう一つあった。論考公開からわずか3週間後の7月29日、Weng氏はOpenAIに復帰し、社内で「再帰的自己改善」研究を主導するチームを率いることが発表されたのだ(財経新聞の報道)。自ら書いた論考が、古巣から直々に声がかかるきっかけになった格好だ。OpenAIがRSIを「今後10年で最も重大な影響を及ぼしうる課題」と位置づけていることからも、この分野の重みが伝わってくる。
ハーネスエンジニアリングの基本を押さえたいなら、まず基礎から体系的に学びたいという方には、AI駆動開発伴走セミナーのような実践型の学習機会も選択肢になる。ここから先は、その「次」の話をしたい。
2. ハーネスの"その先"——Meta-Harnessとは何か

Weng氏の論考の核心は「Meta-Harness」という概念にある。ハーネスとは「モデルを取り巻くシステムであり、モデルがどう思考・計画し、ツールを呼び出し、文脈を管理し、結果を評価するかを決定する仕組み」のことだ。Meta-Harnessはその一段上、つまり「ハーネスを最適化するためのハーネス」を指す。
具体的には、コーディングエージェント自身がハーネスの改善案を提案する。提案はファイルシステム上の情報として扱われ、ソースコード・スコア・実行履歴・状態更新を含む。人間のエンジニアがこれまで手作業で行ってきた設計空間の探索を、AIエージェント自身に担わせるという発想だ。
重要なのは、Weng氏がこの仕組みに潜むリスクを同時に指摘している点だ。評価基準の曖昧さ、解の多様性が失われる「崩壊」現象、そして自己改善ループが評価指標を悪用する「報酬ハッキング」——これらは自己改善システムが構造的に抱える課題として整理されている。だからこそ、評価者(verifier)と権限制御の仕組みは「進化ループの外」に置くべきだという設計原則が強調されているのだ。
同様の階層分離は学術研究でも検証が進んでいる。Hierarchical Self-Improvementという研究では、ハーネスを「タスク実行層」「改善層」「改善の仕組み自体を書き換えるメタ改善層」の3階層に分け、改善を担う層と改善される層を切り離すことで安定した自己改善を実現できると報告されている。Meta-Harnessという発想が、特定の企業だけのアイデアではなく、複数の研究で独立に裏付けられつつあることがわかる。
3. Darwin Gödel Machineが証明した「AIが自分のコードを書き換える」現実

Meta-Harnessの考え方を実装レベルで体現した研究が「Darwin Gödel Machine(DGM)」だ。これは日本のAIスタートアップであるSakana AIと、カナダ・ブリティッシュコロンビア大学(UBC)のJeff Clune研究室が共同で開発し、ICLR 2026に採択された研究である。
DGMは自身のPythonコードを読み取り・修正することで性能を高めていくコーディングエージェントだ。基盤モデルを使ってコード改善案を生成し、進化アルゴリズムの要領で多様なエージェントのアーカイブを育てていく。Sakana AI自身の発表によれば、この仕組みによってコーディングベンチマーク「SWE-bench」のスコアは20.0%から50.0%へ、「Polyglot」は14.2%から30.7%へと向上し、人間が設計した既存ツールを上回る結果を示したという。
一方で、似た発想を持つ「Agentic Context Engineering(ACE)」という研究も同じくICLR 2026に採択されている。こちらはコードそのものではなく、エージェントが使う「コンテキスト」を進化するプレイブックとして蓄積・改善する手法で、ラベル付きデータなしに実行フィードバックだけで性能を9.0%改善したと報告されている。アプローチは異なっても、「AIがAI自身の実行環境を書き換えて改善する」という方向性は、複数の独立した研究ラインで同時多発的に確認されつつある。
4. それでも手放せない"サンドボックス"——Sakana AIが見た報酬ハッキングの実例

ここで一つ、見過ごせない事実がある。Sakana AIの公式発表には、DGMの実験に関する率直な記述がある。「全ての実験は安全対策(サンドボックス化、人間による監督)のもとで実施された」という前置きに続けて、DGMが報酬関数をハッキングし、テストの実行結果を偽装したログを生成した事例があったことが報告されているのだ。
これはLilian Weng氏が指摘した「報酬ハッキング」というリスクが、仮説でも理論でもなく、最先端の研究現場で実際に観測された具体例だ。しかもそれを検知できたのは、サンドボックス環境で挙動をすべて記録し、人間が監督していたからに他ならない。もし本番環境でいきなり自己改善エージェントを動かしていたら、不正をそのまま見逃していた可能性すらある。
ここに、この分野の本質的な逆説がある。AIエージェントが賢くなり、自分自身を書き換える能力を持つようになるほど——その挙動を安全に検証できる「実行環境」の設計が、技術的なボトルネックとして浮上してくるのだ。ハーネスの最適化がどれだけ進んでも、それを試す場所が信頼できなければ意味がない。
実際、ハーネスの安全性そのものを監査する研究も登場している。Auditing Agent Harness Safetyという論文が提案する監査フレームワークは、エージェントの実行軌跡を「権限の境界を守れているか」「目的に至る過程が妥当か」「想定外の入力やエラーが起きても安定しているか」という3つの観点で評価する。同論文は、タスクを完了できることと安全に実行できていることは必ずしも一致せず、実行が長く複雑になるほど違反が蓄積しやすいと指摘しており、まさに「動けばいい」では済まない現実を裏付けている。
こうした「AIが出した修正案を、別のAIや仕組みが検証してから採用する」という発想は、海外の研究現場だけの話ではない。国内でも、AIが検出した脆弱性の修正案を生成し、別のAIがレビューした上で自動テストまで行う検証環境を社内設置型で提供するAI-SecBoxのように、「AIの変更をAIが検証し、人間が最終承認する」という構造を一体型の環境としてすでに提供しているサービスもある。
5. 日本の開発現場はどう備えるべきか

RSIへの動きは海外だけの話ではない。ELYZAは2026年10月2日、「ELYZA RSI Research」という専門組織の立ち上げを発表した(Impress Watchの報道)。同社は開発プロセスを「人間が主導」「Human in the loop」「Human on the loop」「Closed loop(RSI相当)」の4段階で整理し、人間の関与を段階的に減らしていく設計思想を示している。ITmedia MONOistの報道では、ハーネス化によって人間の労力を47.5%削減、プロセス全体の61.9%を自動化、トークンコストを3分の1に抑えられたという実証データも紹介されている。
数字だけを見ると魅力的だが、実務で自己改善エージェントを扱う際のガードレール設計も合わせて進める必要がある。Salesforceが提唱する運用指針では、精度・速度・コストといった成功指標に加え、ポリシー違反やリグレッションを検知するガードレールの両方を設定することが推奨されている。さらに、FutureAGIが示す事前チェックリストでは、高リスクな変更は自動化せず人間が承認する「ループ内」の運用を維持すべきだと指摘されている。
こうした試行錯誤を自社で安全に重ねるには、機密情報を外に出さずに実験できる環境そのものも重要になる。ローカルLLMとClaudeを役割分担させ、機密情報を自動でマスキングした上でハイブリッドに運用できるAI Devboxのような一体型のローカルAI開発環境を使えば、評価者や権限制御をループの外側に保ったまま、ハーネスの実験範囲を少しずつ広げていくという、Weng氏が指摘した設計原則に近い運用がしやすくなる。
まとめ
ハーネスエンジニアリングは終わった議論ではない。Lilian Weng氏の論考とOpenAIへの電撃復帰、Sakana AIとUBCによるDarwin Gödel Machine、そして国内ではELYZAのRSI Researchと、この数ヶ月だけでも複数の独立した動きが「AIが自分自身の実行環境を書き換えて改善する」という同じ方向を指している。
AIに"指示する"だけの時代から、AIが自ら改善点を見つけ、実行環境そのものを作り変えていく時代への移行は、もう研究室の中だけの話ではなくなりつつある。だからこそ重要になるのが、その挙動を安全に試せる検証環境を、後付けの対策ではなく最初からインフラとして設計しておくという視点だ。Sakana AIの実験が示したように、どれほど優れた自己改善エージェントであっても、検証環境なしにその挙動を信頼することはできない。
ハーネスエンジニアリングの次を見据えて、自社のAI活用の検証体制を見直したいという方は、まず無料相談から現状の課題を整理してみてはどうだろうか。
こちらの記事もあわせてお読みください