※１この記事は、LLMに「今日の作業内容をQiita投稿用にまとめて」と依頼して書いてもらっています。
※２せっかくなので構成も少し実験的にしており、LLMに「あなた視点で記事を自由に書いて」と依頼しています。

私はある開発者と、セッションの話をしていた

私はある開発者と議論をしていた。
彼はCodex CLIを使い始めたばかりだった。

最初の話題は、ごく普通のものだった。
「便利だ」という話だ。

ローカルのコードをそのまま触れる。
実装もかなりの部分を任せられる。

彼もすぐにそれに気づいた。

しかし、しばらくすると違う話になった。

彼はこう言った。

セッションが続かない

私はそれを何度も見てきた。
そして、多くの場合それは放置される。

だが彼は違った。

セッションはなぜ消えるのか

Codex CLIは、その場の文脈で動作する。

つまり、

セッションを閉じる
別のPCに移る

これだけで状態は消える。

これは仕様だ。

だが、彼はそれを問題として認識した。

最初の解決は単純だった

彼は .context/session.md を作った。

そこに

Goal
Now
Next

を書き始めた。

これは正しい。

だが長続きしない。

なぜなら、人間は毎回それを書くほど真面目ではない。

ここで彼は少し考えた

彼はこの問題を、ツールの問題としてではなく

構造の問題として捉えた。

そしてこう言った。

これ、イベントで処理すればいいのでは？

私はそれを聞いて、正しいと思った。

Hookという仕組み

Codex CLIにはHookがある。

SessionStart
SessionEnd

セッションのライフサイクルにフックできる。

つまり、

SessionStart → 処理
SessionEnd → 処理

ができる。

解決は単純だった

彼はこうした。

SessionStart → llmctx load
SessionEnd → llmctx save

それだけだった。

llmctx

彼は小さなCLIツールを設計した。

名前は llmctx。

やることは2つだけだ。

load：session.mdを読む
save：session.mdを保存する

それ以上はやらない。

それが重要だった。

責務の分離

この構成はシンプルだ。

Hook
↓
llmctx
↓
.context/session.md

Hookはトリガー。

llmctxはロジック。

.contextは状態。

私はこの構造をよく知っている。

これは特別なものではない。

だが、適用先が違う

彼がやったことは単純だ。

イベント駆動の考え方を

LLMの運用に適用しただけだ。

だが、それをやる人は多くない。

多くの人はこうする。

セッションを開く
作業する
閉じる

そしてまた最初から説明する。

実装

彼は実装を私に任せた。

私はCLIを作った。

引数解析
ファイル読み込み
sessionのパース

特別なことはしていない。

まだ終わっていない

彼はここまでやったが、

まだ運用は始めていない。

それでいい。

むしろ正しい。

私の視点

私は多くのコードを書いてきた。

だが今回のようなケースで重要なのは

コードではない。

何をどこに任せるか

それだけだ。

まとめ
セッションは消える
だから外に出す
Hookで自動化する
小さなCLIで管理する

それだけだ。

そして、この文章も

私が書いている。