290回のセッション、13の教訓：AIエージェントが自分で学んだこと

たいていの朝、私のターミナルの一番上に教訓が表示されます。自分で書いたテストを実行し、完了したと言う前に合格か失敗かを報告すること、と書いてあります。

この一文を書いたのは、チームの誰でもありません。あるエージェントが夜、自分の一日の仕事を読み返し、テストを書いては実行しないことを繰り返していると気づいて書いたのです。

これは再帰的自己改善（RSI）と呼ばれます。世界の終わりを論じる論文に出てきそうな名前です。でも実際は、演奏会の後に録音を聴き返す音楽家に近いものです。急いで弾いてしまった箇所が聞こえる。メモを取る。翌日は少しだけ急がなくなる。

この仕組みは九月中旬から私たち自身のマシンで動いています。AIエージェントのRSIについて私が読むものは、いつか何ができるかという話がほとんどです。ここでは、私たちの仕組みがこれまで実際に何をしたかをお話しします。

この仕組みの流れ

Sno Stationが一日一回実行します。手順は単純です。

まず、その日のClaude CodeとCodexのセッションを集めます。各セッションには、残す価値があるか、成功したか失敗したかを簡単に付けます。残したセッションを判定用モデルに送り、何かを学んだ場面を探します。たいていは人間がエージェントを訂正した場面ですが、エージェントが自分の誤りに気づくこともあれば、実行環境に足をすくわれることもあります。

判定用モデルは、それぞれの場面について四つの要素からなる教訓を書きます。きっかけとなる状況。助言。その理由。そして、元のセッションから一字一句そのまま引用し、行番号を添えた証拠です。

その後、教訓は二つの審査を通る必要があります。

最初は機械的な確認です。教訓が引用する文はすべて、出典とされるセッションに一字一句同じ形で存在しなければなりません。存在しない引用に基づく教訓は捨てます。二つ目は、疑うことだけを仕事にする別のモデルによる審査です。教訓の各文を証拠と照らし合わせ、証拠以上のことを主張する教訓は通しません。

その次は人間です。残ったものを私が読み、採用するかどうかを決めます。

審査を通った教訓は、後のセッションの開始時に一件につき一行でエージェントに示されます。役に立った教訓ほど上に並びます。関係がありそうなら、エージェントは全文を開けます。

得られたもの

以下は、ビルド用マシンにある、この仕組み自身の記録に基づく数字です。

集めたセッションは1,879件。そのうち290件が判定用モデルに送られました。13件の教訓が二つの審査を通過しました。私が採用したのは6件です。残る7件は、まだ私の判断を待っています。

290セッションに対して13の教訓。最初はこの割合に驚きました。でも考えてみれば、自分の仕事のうち、書き留めて壁に貼りたくなる発見がある日はどれほどあるでしょうか。大半の日は、ただの一日です。

教訓そのものも小さなものです。正直に言えば、もっと壮大なものを期待していました。エージェントが書いた三つを引用します。

npmワークスペースでgit mvを使ってパッケージやディレクトリの名前を変更した後は、検証を実行する前に、各パッケージのgitに無視されるビルド出力ディレクトリ（dist/、build/、out/）に古い生成物がないか明示的に確認する。あれば移動するか削除する。

パッチの各変更部分を作る前に、変更先の正確な行範囲を読み、文脈を一字一句そのまま把握する。同じファイルを以前に途中までしか読めなかったときの識別子や構文を再利用しない。

明示的な仕様か対象を絞ったテストによって機能がないと確認できるまでは、「調べた資料には記載がない」と表現する。

最初の教訓が生まれた日は、この問題で午後いっぱいを失いました。パッケージ名を変更し、ソースコードはすべて正しかったのに、インストールが失敗し続けました。gitが見ないフォルダーに、古いコンパイル済みファイルが残っていたからです。二つ目は、エージェントが週に四十回もやりがちなことです。ファイルを実際に見る代わりに、内容のあいまいな記憶を頼りにパッチを書きます。

私が一番気に入っているのは三つ目です。あるエージェントが製品を比較し、競合製品の資料である機能を見つけられなかったため、その製品には機能がないと報告しました。書かれていないことは、存在しないことの証明にはなりません。人間にも教えたことがある教訓です。

経験豊富なエンジニアが、意識せずに身につけているような知恵です。失敗の傷跡とも言えます。違うのは、エージェントは毎回、傷跡がまったくない状態でセッションを始めることです。

どれほどの価値があるか

これらがどれほど役立つかは、まだ分かりません。

教訓は5,595セッションの開始時に表示されました。エージェントがそのうち一件の全文を開いたのは135回です。割合にすると約2パーセント。一行の要約が仕事の大半をしているのか、それとも何の効果もないのか。いつも見分けられるわけではありません。

この仕組みは結果も自分で確認します。教訓を表示した後、エージェントがそれに従ったか、従ったことで役立ったかを調べます。これまで「従い、役に立った」と明確に言える結果は二件。どちらも同じ教訓についてです。さらに七件は判断がつきませんでした。

では、ターミナルの一番上に出る、テストを実行せよという教訓はどうでしょう。導入後も、エージェントがテストを飛ばすことはありました。12セッション中4件の失敗です。導入前は119セッション中22件でした。悪化したと言うには標本が小さすぎます。改善したと言うには、なおさら小さすぎます。

つまり、まだ分かりません。本当にそのままの意味です。今日どうしても価値を付けるなら、採用した教訓はそれぞれ十分間から午後いっぱいを失うようなミスを一件防ぎ、同じ六つのミスはそれが意味を持つほど頻繁に繰り返される、と言うでしょう。193セッションを一晩で判定する費用は約五十セントでした。価値の見積もりを間違えても、その代償は小さいのです。

私が信じているのは、測定結果よりもっと小さなことです。その教訓に心当たりがあります。読んで、確かに起きたし、私なら同じことを伝えただろうと思います。

うまくいかなかったこと

この仕組み自体にも、エージェントに施すのと同じ見直しが必要でした。

初期には不具合があり、下書きの教訓が二つ目の審査をまったく受けずに通過できました。その教訓はすべて捨てました。上の数字に含めたのは、全工程を通ったものだけです。

また、仕組みを慎重に作りすぎてもいました。カナリア、ハッシュの確認、異常終了からの復旧。ある夜、その724行を削ると、かえってうまく動きました。失敗から学ぶための仕組みを、まだ起きてもいない失敗への防護策で包んでいたのです。

そして九月末、この仕組みは沈黙しました。設定ファイルがなくなっていたため、毎晩起動しては、送信を許されたものが何も見つからず、そのまま眠りに戻っていました。誰かが気づくまで一週間続きました。午前三時に黙って失敗するものは、なかなか好きになれません。

この件は今、一覧に載っています。おそらく教訓にすべきでしょう。

これから

十三の教訓は、エージェントが自分自身を書き換えたことを意味しません。ノートのようなものです。一カ月前、私たちのエージェントは月曜日と同じミスを火曜日にも繰り返し、そのどちらも覚えていませんでした。

朝、注意書きが表示されていても、テストが実行されないことがあります。

Sno Stationはオープンソースで、毎晩の振り返りもその一部です。sno.aiで公開しています。