[🤖] Codex Skillで作業の流れと感覚をつないだ

✨ GPT-5.6 Solの要約

Linuxサーバーで固めたばかりの判断を次の作業と文章へそのまま渡すため、Codex Skillに現在のルールと作業の証拠を読み直させ、流れを切らさなかった記録。

今日は会社サービス用Linuxサーバーの運用基盤を整えた。新しいSSDにUbuntu Serverを入れて内部SSHをつなぎ、人間の管理者、AI Cell、業務自動化Runtimeが一台のサーバー上で互いの権限や状態を侵さないよう、ユーザー境界まで設計した。

サーバーの具体的なディスク・ネットワーク・アカウント構成は、上の記事に別途まとめた。ここで改めて書きたいのはインストール方法ではなく、その作業を終えた後も判断の流れが途切れなかった経験だ。

ルーター、NAS、既存Runtime、新しいLinuxサーバーがどうつながるのかをネットワークSkillに残すと、次のCodex sessionで機器一覧から説明し直す必要がなくなった。完了したことと、まだ設計だけのことも分けておいた。サーバーを触りながら身につけた運用の感覚を、次の作業がそのまま引き継げる状態だった。

いいね。Skillを使うのにも慣れてきて、こういうものもあっという間に設定できるようになった。すごくいい。やっぱり何であれ、流れを保ちながら感覚を失わないことが大事なんだと思う。

あのとき良かったのは、Skillを一つ素早く作れたという事実だけではなかった。

サーバーを触りながら生まれたばかりの運用感覚がユーザー構成につながり、その構成がネットワークSkillに残り、さらに作業を説明するdevlogへ続いた。そこまで書き終えると、今度は最近の作業を会話とGit履歴から見つけ、日記にするSkillを作ればいいという考えがすぐに浮かんだ。

サーバー構築と文章を書くSkillはまったく別の作業なのに、頭の中では同じ流れだった。次の作業が最初からやり直しにならないために何を残すべきかを前の作業で考え続け、その答えをすぐ次の道具の構造に使っていた。

新しいSkillにも前に作った流れを再利用した

以前、個人スケジューラーに入れる時間別の業務記録を作るために、gsheet-hour-blocksを作ったことがある。現在の会話だけを要約するのではなく、関連repositoryのGit履歴も一緒に読み、実際にやったことを時間blockの文章へ圧縮するSkillだった。

今回は出力だけが違った。

最近の会話、command、tool結果、指定期間のGit証拠を読む骨格はすでにあった。その証拠から作業一覧ではなく、自分が実際に感じた問題と判断の変化を見つけ、現在のブログルールに合う独立した日記として書かせればよかった。

完全に新しく設計する必要はなかった。前に身につけた方法が、次の方法の材料になった。

毎回繰り返していた「本当に完璧にやった？」という問いをaudit-and-fix-until-cleanというSkillに変えた経験も残っていた。繰り返される要求に気づいたら、長いpromptをまた書くのではなく、再利用できる作業方法と終了条件に固める。同じやり方で何度かぶつかるうちに、どこをSkillに入れ、どこを元のprojectに残すべきかも以前より早く見えるようになった。

その感覚があったから、blog-write-diaryの大きな構造はすぐに決まった。

ただし、Codexは一度だけ間違った方向へ進んだ。

ルールをコピーすると、文脈は続くのではなく分裂する

最初は、このブログのカテゴリー、文体、日付、翻訳ルールを新しいSkillの中へ移そうとした。

私が望んでいたのはそれではない。

それをSkillに複製して移せという意味ではない。正確には、cdb project内のルールや文脈を直接読ませたいんだ。ルール自体を移す作業は後でやる。

ブログのルールは変わり続ける。それをSkillへコピーすれば、同じルールが二か所にできる。最初は動いても、いつかprojectの現在のルールとSkillが覚えている過去のルールがずれる。文脈をつなぐために作った仕組みが、逆に古い文脈を固定してしまう。

そこで、blog-write-diaryにはブログのルールを所有させなかった。

Skillが覚えるのは作業手順だけだ。現在の会話とcommand、Gitの証拠をどの順番で読むか、その中から一つにつながる中心をどう見つけるか、そして実際に記事を書く前にcdbの現在のAGENTS.md、カテゴリー、隣接記事を改めて確認しなければならない、という手順である。

変わるルールは元のprojectに残し、Skillは実行するたびにそのsource of truthへ戻る。

この違いが核心だった。AIにすべての文脈を長く覚えさせる代わりに、必要な瞬間に現在の文脈へ正確に入り直す道を作ったのだ。

つながったのは情報量より判断の感覚だった

AIのcontextには限りがある。会話が長くなれば圧縮され、別のsessionへ移ると、それまでの微妙な判断は簡単に消える。だからといって、すべての会話を永遠に保存し、毎回全部読ませることもできない。

大事なのは情報のすべてを保存することではなかった。

次の作業を始めるとき、なぜこの境界が重要だったのか、何をすでに捨て、何を守ると決めたのか、今はどのsourceを信じるべきかを復元できる必要があった。その状態に戻れれば、AIも結論だけをまねるのではなく、前から続く判断ができる。

人間である私も同じだった。

今日は、なぜサーバーのアカウントとRuntimeを分けるべきか、なぜprojectルールをSkillへコピーしてはいけないのかがすぐに見えた。判断の根拠がまだ熱かったからだ。時間がたち、結論だけがぼんやり残った状態では、同じ説明を読み返しても今と同じ感覚ですぐに続きを始めるのは難しい。

以前、人間の記憶は圧縮され、手がかりによって再び生き返ると書いた。今回はその考えを実際の作業方法として使ってみたことになる。

SkillとAGENTS.md、Git履歴は、あらゆる瞬間を保存する倉庫ではない。次のsessionのAIと未来の自分が作業へ戻るとき、判断を再構築するための手がかりだ。きれいに残された結論一つより、現在のsourceと証拠を追い直してその結論へたどり着ける経路のほうが役に立った。

感覚が生きているうちに、次の流れまで作っておく

今回楽しかった理由は、blog-write-diaryを素早く作れたことだけではない。

Linuxサーバーを立てながら得た感覚がユーザー構成とネットワークSkillへ続き、その運用判断がdevlogへ続き、記事を書いていた流れがまた新しい日記Skillの設計へ続いた。どの段階でも完全に最初へ戻ることはなかった。

それが良かった。

開発でも文章でも、前で積み上げた判断が生きているうちに次の作業へ進めば、速くなるだけではない。何が大事なのかを探し直して迷わないぶん、結果の水準もそのまま続く。うまくいく理由を説明でき、間違った構造が見えたらより早く止まれる。

AIの短いcontextを扱うために作った構造が、結局は自分の短い記憶も補っている。けれど、人とAIのどちらもよく忘れるという事実だけが、この文章の結論ではない。

私が作り続けたいのは、記憶装置というより流れをもう一度つなぐ装置に近い。

次に始めるとき、一から説明して感覚を取り戻すのではなく、今たどり着いた判断の上から、すぐ次の一歩を踏み出せるように。