AIエージェントを動かしていると、ある悩みにぶつかります。
思った通りに動かない。
途中で脱線する。
決めたはずのガードレールも越えていく。
けれど、なぜそうなったのかは見えてきません。
原因は、ログの山に埋もれてしまうのです。
最近、Redditでこの問題を扱った投稿が話題になっていました。
投稿者が目をつけたのは、大手のオブザーバビリティ（観測）企業が出している「自己改善ループ」の仕組みです。
そして、それを自分でオープンソースとして作り直し、公開したそうです。
自己改善ループとは何か
そもそも自己改善ループとは何でしょうか。
仕組みはシンプルです。
まず、エージェントが過去に残した実行記録（トレース）を分析する。
そして、そこからエラーや挙動のズレ、無駄を自動で洗い出す。
さらに、直すべき箇所を提案する。
中身を開けてみると、その判定を担っているのは別のLLMでした。
いわゆる「該当箇所をこう直しました。
中身を開けてみると、その判定を担っているのは別のLLMでした。
LLMを審判役に立てる構成です。
英語では「LLM-as-a-judge構成ですね。
大手各社は、これを製品として出しています。
完成度は高い。
ただ、投稿者はそこに不満を抱えていました。
まず、導入のハードルが高い。
機能は有料の壁の向こうにある。
しかも、エンタープライズ契約でなければ、自分のデータすら手元に置けない。
そういう不満です。
そこで彼はこう考えます。
中身がLLMの判定なら、自分のマシンでも同じことができるはずだ、と。
すでにClaude Codeのような契約を持っている人なら、なおさらです。
公開されたツールの中身
公開されたツールは、いくつかの部品で組み上がっています。
- ローカルで完結するトレースの取り込みと保存（OpenTelemetry上で動く）
- 分析のためにローカルのエージェントを起動し、トレースを読ませる仕組み
- 性能を追いかけるための評価ハーネス（コードやLLMによる評価を生成して実行する）
- 見つかった証拠をもとに、修正を人間が承認するための観測パネル
全体が自己ホスト型で、ローカルで動きます。
ダッシュボードから人が操作してもいい。
あるいは、CLI経由でエージェントに任せてもいい。
投稿にはデモも添えられていました。
SierraのTau2ベンチマークを解くエージェントを分析した例です。
提案された修正を当てたところ、同じモデルでも一度のループで精度が24%上がった。
そう紹介されていました。
ただ、これは投稿者本人の主張です。
数字をそのまま鵜呑みにせず、参考程度に受け止めるのがよいでしょう。
コーディングを直すのか、エージェントを直すのか
コメント欄で、こんな質問が出ていました。
ウェブサイトの掲示板をClaude Codeで作った。 5回のセッションのうち3回は作り直しになって、正直うんざりした。 このツールはそこを助けてくれるのか
投稿者の答えは明快でした。
このツールが主に狙っているのは、Claude Codeのコーディング能力そのものを上げることではない。
狙いは別にある。
あなたが業務に投入した、もう一方のエージェントを良くすることです。
たとえばカスタマーサポートのエージェントを思い浮かべてください。
これは平気でハルシネーションを起こします。
途中で壊れる。
決めたはずのガードレールからも外れていく。
そうした事象が本当に起きているのか。
なぜ起きるのか。
どう直すのか。
それを掴むために使う、というわけです。
ただし、と彼は付け加えます。
質問者のケースでも使い道はある。
まず、Claude Codeのセッションを読み込ませれば、批評を受け取れる。
その内容をもとに、CLAUDE.mdを書き換える。
すると、次回そのプロジェクトでの仕事ぶりは確かに良くなる。
そういう話です。
別のコメントが、ここに乗っかってきます。
年初からClaude Codeの履歴をずっと貯め込んでいる。 プロダクトマネジメントの仕事をClaude Codeで回してきたから、これはスキル抽出を待っている知識の鉱脈だ
1月まで遡るログを、人手で掘るのは現実的ではありません。
だからこそ、こうしたツールに値打ちが出てくるのですね。
一番面白い論点：同じ勘違いを強化してしまう
ここからが、議論で一番おもしろかったところです。
あるコメントが、鋭い問いを投げました。
「評価する側が、同じ勘違いを強化してしまうのを、どう防ぐのか」。
複数のモデルが、揃って同じ誤った結論にたどり着く。
そんな場面を何度も見てきた、と言うのです。
原因は、元の仕様に肝心の意図が抜けていたこと。
だからループは、正しさではなく、仕様との一貫性ばかりを追いかけ続けてしまった。
そういう話でした。
この問いを、別のコメントがさらに突き詰めます。
自己改善ループとは、要するにAIが自分の答案を自分で採点する仕組みです。
自信たっぷりに間違える。
しかも、その間違いに気づけない。
これは、ほとんど唯一とも言える状況でしょう。
ループは、トレースと仕様が「良い」と決めたものへ向かって、自分を磨いていきます。
けれど、もし意図が仕様から抜け落ちていたら、どうなるか。
出力をどれだけ調べても、その穴は見つかりません。
穴は、そもそもデータの中に存在しないからです。
だからループは、きれいに、間違ったゴールへ収束していく。
しかも「うまくいった」と報告する。
ここが怖いところですね。
だとすれば、人間が承認するパネルは、単なる予備のスイッチではありません。
ループが構造的に見えない誤りを、唯一つかまえられる場所だからです。
ループの本当の仕事は、抜けた意図を自分で見つけることではない。
それを見抜ける人間に向けて、状況を素早く、読み解けるかたちで差し出すこと。
そこにあるのです。
多エージェントで解決できるのか
これに対して、反論もありました。
ループは構造的に盲目なわけではない。 役割を分けたエージェントのチームは、十分に機能している。 分析役、評価役、エンジニア役といった具合に、仕事を割り当てたものだ。 最先端の現場でも、そう作られている。 だから人間は必須ではない。 あくまで選択肢のひとつだ
もっともな指摘です。
役割を分けた複数のエージェントが、単一のエージェントより強い。
これは、おそらく事実でしょう。
ただ、これに対する切り返しが見事でした。
仕様の穴というのは、あるエージェントが見落とした、という種類の問題ではない。
チームの全員が、同じ仕様を受け継いでいるのです。
だから評価役は、人間から抜け落ちた意図をそっくり引き継ぐ。
そのまま、エンジニア役を採点する。
結果、全員が、きれいに合意して、揃って間違える。
この誤りをつかまえるには、仕様の外側から来る何かが要ります。
人間か、現実世界のテストか、現実との接触か。
私たちが賢いからではありません。
ただ、同じ指示書から仕事をしていない、というだけのことです。
バグやズレ、効率の改善が相手なら、自律エージェントは見事にこなすでしょう。
けれど、意図そのものに空いた穴については話が別です。
ループは「壊れているものの下流」にいる。
これが核心でした。
自己ホストである理由と、自律への移り方
なぜ自己ホストなのか。
理由のひとつは、分析するエージェントにリポジトリの中身まで触らせたいからです。
最良の文脈で推論させたい。
そのためには、コードベースへのアクセスが欠かせません。
そして、契約（サブスクリプション）で回すのにも理由があります。
APIで処理すると、費用がかさむからですね。
運用の進め方についても、腑に落ちる整理がありました。
まずは、人間が一件ずつ確認するところから始める。
システムの素性を知り、信頼できるかを見極める。
そのうえで、少しずつ自律の度合いを上げていく。
つまり、信頼が自律の前提条件になるわけです。
評価の層が、ガードレールとして十分に頑丈になったら、次の段階へ進む。
「例外だけを人間が見る」運用へ移るのです。
これが自然な順番でしょう。
ここに、本質的な緊張があります。
人間が確認する方式は、安全網になります。
けれど、同時にボトルネックにもなる。
1日に数百、数千のセッションが流れるようになると、どうなるか。
「暗黙知は開発者の頭の中にある」という事実そのものが、重しに変わります。
解決策ではなく、制約になってしまうのです。
まとめ
AIエージェントの自己改善は、強力な発想です。
トレースを掘る。
似た問題を束ねる。
評価を回しながら直していく。
バグやドリフトを潰す用途なら、目を見張る成果が出るでしょう。
ただ、忘れてはいけない一線があります。
自分の答案を自分で採点する仕組みは、採点基準そのものが歪んでいるとき、無力になる。
その穴を埋められるのは、仕様の外側にいる誰かだけです。
あるいは、現実との接触だけなのです。
オープンソースで自己ホストできるツールが現れました。
おかげで、こうした実験のハードルは確かに下がっています。
けれど、ツールがどれだけ賢くなっても、変わらないことがある。
最後に「意図そのものが正しいか」を問える役割は、人間の側に残るのです。
この役割を手放さないこと。
自律化を進めるうえで、そこがいちばん大事なのだと思います。
