その日のあらすじ
対話型の AI エージェントに指摘をしても、セッションが終わればその指摘は消えて、次のセッションではまた一から同じことを指摘することになります。この指摘をどこへ書き残せば次のセッションにも効くのかを、デスクトップ用の自作ツールと、研究予稿と研究運営のリポジトリという分野も作りもまるで違う二つの開発で、ここ数週間分のコミット履歴と設計文書を読み直して探したところ、二つは別々に進みながら、指摘の定着先をまったく同じ三層へ切り分けていました。
三層とは、エージェントが毎セッション読み込む指示ファイルと運用ルールの文書、固定した手順をまとめたスキル、判断の履歴だけを残すセッション外のメモリのことで、どの層へ置くかは、別のセッションがリポジトリだけを見て同じ運用と品質を再現できるか、という一つの基準だけで決まります。行き着いた結論は、指摘をその場で直すことではなく、その指摘をどの層に置くかを毎回選ぶことでした。
ここに至るまでには、失敗もありました。汎用のルールをメモリへ書き続けて、別のセッションで規律が再現されなかったのです。そのあとで、運用ルールの要約を最上位の指示ファイルへ移し、編集の直前に注意を促して操作は止めないフックと、機械で判定できるものと意味の判定とを分ける二層のテストを整えました。これらは、数週間の別々の日の出来事です。
セッションが終わると指摘は消える
この二、三週間、デスクトップ用の自作ツールと、研究予稿と研究運営のリポジトリという二つの開発を並行で進めてきました。その間ずっと、対話型の AI エージェントに同じことを何度も指摘している自分がいました。何かを指摘しても、セッションが終わればその指摘は残らず、次のセッションで僕はまた一から同じことを指摘することになります。この記事で書くのは、その指摘をどこへ書き残せば、指摘を受けていない次のセッションにも効くのか、という定着先の選び方です。分野も作りもまるで違うこの二つの開発が、指摘を三つの層に振り分けるまったく同じ形に、別々にたどり着きました。この一致があったので、その三層の切り分けと、どの層へ置くかを決めるたった一つの基準を、次に同じことで困る人にも渡せる形で書き残すことにしました。
三つの層と一つの基準
三層の切り分けは、こうです。別のセッションがリポジトリだけを見て同じ成果物を再現するのに必要な汎用のルールは、エージェントが毎セッション読み込む指示ファイルと運用ルールの文書へ置きます。手順が固まっていて機械的に繰り返せる作業は、その手順をまとめたスキルへ置きます。そして、いつどんな指摘を受けてどこへ移したかという判断の履歴の一次記録だけを、エージェントがセッションの外へ持ち越すメモリへ置きます。
振り分けの基準は一つだけで、別のセッションがリポジトリだけを見て、同じ運用と同じ品質を再現できるか、です。再現に必要なものはリポジトリの中へ置き、個人に固有で再現には使わない履歴だけをメモリへ置く、それだけで振り分けます。
汎用のルールをメモリへ書き続けた失敗
なぜこの基準に行き着いたかというと、逆をやって一度つまずいたからでした。片方の開発で、指摘を受けたらその場でメモリへ書き込む、という運用がいつのまにか暗黙の癖になっていて、本来は誰が読んでも効くべき汎用的な執筆規律まで、片っ端からメモリへ書き続けていた時期があります。運用ルール自体は、文書としてリポジトリに書いてあったのです。ですが、その文書は、新しいセッションが能動的に読みにいかないと効かない位置に置かれていました。そのために、別のセッションや並列で動くエージェントがリポジトリだけを見ても、規律がまるで再現されない状態に陥っていました。
そこで、運用ルールの文書の要約を、毎セッション必ず読まれる最上位の指示ファイルの側へ移しました。メモリへ書いていた汎用ルールの数件は、受けた指摘の経緯だけを残す薄い履歴の記録へ書き換えて、ルールの本体は指示ファイルとスキルに置き、メモリからはそこを参照させる形へ組み直しています。
読まれなくても効く層へ寄せる
ただ、指示ファイルへ移しても、読まれること自体に運用が依存している弱点は残ります。そこでもう一段、読まれなくても効く層へ寄せました。片方の開発では、デザインや日本語の文言や文書を編集する直前に自動で走る仕組みとしてフックを入れて、該当するスキルを読めと気づかせるようにしました。このフックは許可の判定を出さず、追加の情報を渡すだけで、操作を止めることはしません。もう片方の開発では、指摘の一部を自動テストへ変換して、字数や句読点や体裁のように機械で白黒がつくものはプログラムのチェックに、意味や論理のように文脈に依存する判定は AI 自身を判定役にする、という二層に分けました。
もっとも、テストは入れたら終わりではなく、テストの側にも弱点が出ます。たとえば、意味を判定する側のテストは、研究のために観察できた事例の件数が少ない日の本文にまで、留保の言葉を足して主張を弱めるよう求めてきました。そこで、その日に観察できた事例の件数や日数をあらかじめ宣言するファイルを置き、宣言した範囲を超える主張だけを落とすように判定を緩めました。直し方を示さないまま不合格だけを返す挙動も、他の章の文脈を渡していないために起きる誤った不合格も、仕組みに手を入れて直しています。
この三層への組み直しを終えたと判断するのに使えた確かな根拠は、多くありません。さきほど触れたとおり、フックは操作の権限を変えず、気づかせるだけです。そのフックが壊れていないかは、登録済みのフックからスクリプトの置き場所を取り出して、そのファイルが実在するかを確かめるテストで守っています。確かめられたのは、このあたりまでです。
それでも残る、読まれることへの依存
ここまでやっても、読まれることへの依存が消えたわけではありません。コードの変更ごとに自動で検査を回す仕組みが見るのはプログラムのチェックの一部だけで、意味の判定は手元での実行のままです。判定役を呼ぶ先のサービスにサインインしていないと、判定が素通りしてテストが通ったように見えてしまう罠も残っています。指示ファイルの側にも仕組み上の代償があって、指示ファイルが大きくなれば、エージェントがセッションのたびに読み込んで処理する量はそのぶん増えます。それでどれだけ遅くなるかを測った一次情報は、まだ取れていません。
同種の指摘の再発が本当に減ったのかも、まだ分かりません。コミットの履歴から取り出せるのは、ルールを書き込んだ回数とテストの件数の推移までで、この仕組みを入れる前と後とで、条件を揃えて再発の割合を比べたデータがないからです。
機械へ寄せた先に残った人間の仕事
検査を機械へ寄せた分、人間が判断する境界の方がはっきり残りました。どの検査を機械に任せ、どれを任せないかの線引きです。テストは失敗のたびに、修正案と、その指摘が本文の書き換えで直るのか、それとも裏づけの計測へ戻るべきなのかの区別を返してきます。それを受けてどう動くかは、まだこちらの手にあります。こちらからは、形ばかりを機械的に照合するテストは取りこぼしがあるので削ってほしい、実際には指摘していないルールを勝手にテスト化しないでほしい、という指示も出していて、何をルールとして書き残し、何を書き残さないかを決めること自体が、まだ人間の側に残った仕事なのだと思っています。
結局たどり着いたのは、指摘をその場で直すことより、その指摘をどの層に置くかを毎回選ぶ、という運用でした。AI エージェントに同じ指摘を何度も繰り返している人がいたら、その指摘をどこへ置けば次のセッションにも効くのか、という選び方の一つとして、この記事が届けば幸いです。