会話ログの中身に違和感を覚える
共通フォルダの仕組みが少しずつ動くようになり、
ひとまずいい感じかなと思っていました。
ただ、データベース（SQLite）に保存されている会話の記録を眺めていたとき、
なんだか様子がおかしいことに気がつきました。
記録されている文章の形式が一定ではなくて、
私からの発言のところに、
見覚えのない英語の指示やタグのような記号がたくさん入っていたのです。
「もしかして、本来の会話がちゃんと記録されていなかったり、
変な風に書き換わってしまう仕組みになっているのではないか」と気になり、
AIにデータベースの中身を最初から洗い直してもらうことにしました。
裏で動く処理まで全部記録されていた
調べてもらった結果、会話が漏れているわけではなく、
私とAIのやり取り自体はすべて残っていることがわかりました。
問題だったのは「記録漏れ」ではなく、
その逆の「記録しすぎ」でした。
原因は次のような仕組みになっていました。
・AIに相談する中で、裏側で別のプログラムや会議の仕組みが動く
・その処理が終わるたびに、会話終了時用の自動記録フックが反応してしまう
・裏側のシステム指示まで「人間からの新しい発言」と勘違いして保存してしまう
なんと、データベースにあった全105件の記録のうち、
半分以上の59件が、こうした裏側の処理データ（ゴミデータ）でした。
どうりで身に覚えのない長文やタグだらけの記録が混ざっていたわけです。
安全装置のロックを手動で外して掃除する
原因がわかったので、さっそく不要な記録の削除と、
今後は裏側の処理を記録しないようにする修正をお願いしました。
ところが、大事な設定ファイルをAIが書き換えようとしたタイミングで、
エディタの安全装置が働いて処理が止まってしまいました。
そこで、AIに教えてもらった通りに、
私の方で設定ファイルの指定された行へ設定を追記しました。
「追記してみたけど合ってる？」と確認しながら進めたところ、
無事にロックが外れて、掃除のプログラムが最後まで動きました。
ゴミデータだった59件がきれいに消えて、
本来の会話記録である46件だけが残りました。
システム用の余計なタグも取り除いてもらい、
ようやくデータベースの中身がすっきりしました。
一番怖かった「不要なファイルの整理」に挑む
ログの掃除が終わったあと、
ずっと気になっていたもう一つの作業に取りかかることにしました。
プロジェクト全体の整理（リファクタリング）です。
ここまで手探りで作業を進めてきたので、
途中で方針が変わった部分もたくさんあります。
おそらく、今はもう使っていないファイルや古い設定が残っていて、
中身が一部ぐちゃぐちゃになっているだろうなと思っていました。
ただ、正直なところ、この作業が一番怖かったです。
今の自分では、どれが本当にいらない仕組みで、
どれが消してはいけない大事な仕組みなのかを切り分けるのが難しいからです。
下手にファイルを消して、今まで作ったものが全部動かなくなるのだけは避けたいところでした。
そこで、いきなり削除を始めるのではなく、
先日作ったばかりの自律会議システムを立ち上げて、
批判的な視点を持つエージェントに「消していいもの」と「消してはいけないもの」を、
事前に厳しくチェックしてもらうことにしました。
一見使われていないファイルが大事な窓口だった
会議システムで調べてもらった結果を見て、
すぐに消さなくて本当によかったと胸をなでおろしました。
一見すると不要に見えるけれど、
消すと全体が動かなくなる危ない箇所がいくつも見つかったのです。
特に危なかったのが、次のようなケースでした。
・親フォルダ内ではどこからも呼ばれていないファイル
親フォルダの中だけを探すと、まったく使われていない孤立したファイルに見えます。
しかし実際には、別のプロジェクト（子フォルダ）から呼び出される、
一番大事な窓口のファイルでした。
もしこれを消していたら、他のプロジェクトがすべてエラーで止まるところでした。
・古いフック設定の削除とテストの数字ズレ
データベースに残っていた使っていないフック設定をいきなり消すと、
「フックが何個あるか」をチェックしている確認用プログラムの数字と合わなくなり、
エラーになってしまう状態でした。
人間や1つのAIがパッと見ただけでは、
「使われていないから消そう」と判断してしまいそうな箇所ばかりでした。
Gitを保険にして整理を実行する
危ない箇所と安全な手順がはっきりわかったので、
「もし何か失敗したときは、またGitから元に戻せばいい」と気持ちを切り替えて、
実際に整理の作業を実行してもらいました。
作業は以下の順番で進めてもらいました。
・作業中の一時ファイルが入っていたフォルダを完全に削除する
・子フォルダから呼ばれる大事な窓口ファイルには、
将来間違えて消さないように「絶対削除禁止」という注意書きを先頭に書き込む
・確認用プログラムのチェック数値を先に直してから、データベースの古いフック設定を削除する
事前に危ないところを洗い出していたおかげで、
一度もエラーが出ることなく、すべての整理が無事に終わりました。
これまでの作業で溜まっていた不要なファイルやゴミデータがなくなり、
ずいぶん見通しがよくなりました。
よくわからないまま触るのが怖いときでも、
事前に別角度からチェックする仕組みを使うことと、
いつでも戻せるようにGitに記録しておくことのありがたみを実感した1日でした。