ドキュメントを育てる

先週の金曜日、ここ３ヶ月準備していたピクチャレ大会のアップデートをリリースしました。
このタスクは、今年01月に導入したCodexをさらに活用するための踏み台のような位置付けでした。
Codex開発自体は特に誰から教えてもらうわけでもなく、試行錯誤しています。
今回このタスクで確立したのは、セッションログを記録・集約するシステムプロンプトを含めるということです。
これにより、もう少し高いレベルでCodexにプロジェクトを理解してもらうことができたと感じています。

たとえば、日頃からCodexに指示（プロンプト）を投げていると、
その中には「今後も把握していてほしい情報」というのが含まれていることがあります。
Codexはそのセッションではその情報を理解して考慮してくれるのですが、
新しいセッションを始めたときやセッションログの量が多くなってきたとき、必ずしも考慮してくれるとはかぎりません。
また、自分自身も過去にどんなプロンプトを書いてきたか検索したいというニーズがあります。
そこで、システムプロンプトに「作業完了時に毎回、セッションログを特定フォルダに出力して」
と指示することで、まずCodexとのやりとりは全部ドキュメント化することができます。
ただこれだけだとCodexは内容を適切に理解してくれないので、
適宜、「セッションログを読み取って、恒久的に理解すべき内容をsummaryに書き出して整理して」と指示します。
そして最上位のAGENTS.mdには、そのsummaryに書いてあることをまず遵守すべきと明記しておきます。
こうすることにより、コンテキスト量を抑えつつ守ってほしいルールを幅広く理解してくれるというわけですね。
ついでにログファイルを解析して、今月書いたプロンプト量なんかも出力できるようになります。

AIがドキュメントを「育てる」手法は巷では「LLM Wiki」という概念がもてはやされており、
パーソナルナレッジベースの作り方も今後大きく変革しそうな予感がしています。
LLM Wikiは収集するだけでAIは触らない一次情報と、AI自身の一次情報への理解（関連性）を整理しておく二次情報、
そして人間からAIへの質問を記録・整理する三次情報にディレクトリを分けるという考え方だそうです。
扱う情報が大きくなってきた場合に、効率的にAIに情報を理解させる合理的な手法です。
開発作業にここまで徹底した情報整理が必要かと言われると微妙なところですが、
一方で技術負債を増やさないために情報を整理するニーズは確かにあり、
こういうのを参考にして試行錯誤を続けていくことになりそうです。
自分の場合、情報整理特化のCodex活用という観点はブログの整理で真価を発揮しそうな予感がしています。
LLM Wikiをそのまま応用すれば長年構想していた自動タグ機能を実装できるんじゃないだろうか。

ともあれ、Codex系作業は金曜の大型アップデートで一区切りとなりました。
土日はイベント準備とブログで消費しましたが、明けて今週からはいったんニュートラルポジションに戻っています。
これまでの経験を活かして、いよいよ今年最大のプロジェクトを完成まで持っていきたいところです。