開発効率化

Codexの/endをただの終了コマンドで終わらせない方法

Codex を使っていると、いい会話やいい判断ほど、その場で流れやすいと感じます。実装方針、運用ルール、次回も使える判断基準は本来かなり価値があるのに、セッションが終わると埋もれやすいからです。

そこで今回は、/end をただの終了合図ではなく、knowledge capture の入口に変える仕組みを作りました。結論から言うと、/end の直前に「再利用できる知識だけを抽出する」1ステップを挟むだけで、Codex の使い勝手はかなり変わります。

結論: /end は「会話を閉じる操作」ではなく「知識を仕分ける操作」にした方がいい

今回やったことを一言でまとめると、/end を closeout ではなく knowledge capture の入口に寄せた、ということです。

今の標準フローはこうです。

  1. セッション終端で dream 候補を抽出する
  2. 候補をざっと見る
  3. 残す価値があるものだけ lesson や memory に昇格する
  4. TASKS.md と handoff を更新して終わる

この形にすると、会話の終わりが単なる終了ではなく、次回に渡す知識の仕分けになります。

きっかけは OpenClaw の /dreaming だった

発想のきっかけは OpenClaw の /dreaming です。会話やメモから、あとで使える情報だけを抽出して残す。この核の考え方はかなり強いと思いました。

もちろん OpenClaw と Codex は別物です。なので今回やったのは機能移植ではなく、Codex の今の作業環境で同じ価値を持つ最小版を作ることでした。

まずは最小版を作った

入れた仕組みはかなりシンプルです。

  • 会話ログやメモを入力する
  • 再利用価値がありそうな文だけを抽出する
  • ~/.codex/memories/dreams/ に保存する

実装したのは次の3つです。

  • dreaming_capture.py
  • capture_codex_dream.sh
  • codex-dream

たとえば、クリップボードの内容をそのまま dream 候補として見たいなら、次のように使えます。

pbpaste | codex-dream --title closeout --stdout-only

今の版はルールベース抽出です。まだ LLM に深く意味判断させるところまではやっていませんが、「話して終わり」を減らす最初の導線としては十分機能します。

一番大事だったのは dream と durable memory を分けたこと

最初は「/end のたびに全部 memory に入れればいいのでは」と考えがちです。ただ、それをやるとノイズまで残ります。後から見返した時に使いづらくなるので、今回は次のように分けました。

置き場 役割 扱い
dream 候補 広めに取る
learned-lessons project-local な知見 レビュー後に残す
global memory cross-project な知識 さらに厳しめに残す

つまり dream は一次置き場です。抽出した時点では「残す価値があるかもしれない候補」にすぎません。この分離を入れたことで、closeout と knowledge capture がぶつからなくなりました。

/end を knowledge capture の入口にした

今回の中心はここです。/end を単なる終了コマンドではなく、セッションの知識を仕分ける境界面として扱うようにしました。

この流れに合わせて、closeout 周りも整えています。

  • session-closeout skill
  • closeout checklist
  • session closeout template

返答フォーマットも固定しました。

TASKS.md: updated | unchanged
Dreams: captured | skipped
Handoff: updated | unchanged
Lessons: saved | skipped

このくらいの軽さにしておくと、/end が重い儀式になりません。

実務上のハマりどころ: skill を作っても候補に出なかった

今回の実装で一番実務的だった詰まりどころは、skill を作ったのに Codex 側の候補に出てこなかったことでした。

原因は単純で、Codex の repo-local skill discovery は skills/ ではなく .agents/skills/ を見ていたからです。つまり、openclaw/skills/session-closeout/SKILL.md だけ置いても、Codex 側の discovery には乗りません。

最終的には、Codex が見える場所にも mirror を作りました。

  • .agents/skills/session-closeout/SKILL.md
  • .agents/skills/learned-lessons/SKILL.md

skill を作ったのに候補に出ないなら、まず .agents/skills/ を疑った方がいいです。

この運用が向いている人

  • Codex を継続的に使っている人
  • 会話の中で決まった運用ルールが流れやすい人
  • 次回セッションへ知識を渡しやすくしたい人
  • AI の memory を自動化しすぎてノイズを増やしたくない人

向いていないケース

  • 単発でしか Codex を使わない
  • 会話ログを知識として残す必要がほとんどない
  • closeout の手順を増やしたくない

この場合は、無理に /end を knowledge capture へ広げない方が自然です。

まとめ

今回やったのは派手な機能追加ではありません。ただ、Codex を日常的に使うならかなり効く整備でした。

/end を closeout の入口にするだけなら普通です。そこに dream 候補抽出を挟み、レビュー後にだけ昇格するルールを入れると、/end は knowledge capture の入口になります。

もし Codex を長く使う前提なら、/end をただの終了コマンドのままにしておくのは少しもったいないです。会話を閉じる場所を、知識を育てる場所に変えた方がいいと思います。

関連記事

Codex を WordPress 運用にどう組み込むかは、Codex と wp-cli でブログ運用を自動化する考え方 がつながります。ローカル原稿から WordPress へ下書き投入する流れは、WordPress 記事をローカルで書いてから下書き投入する方法 を読むと理解しやすいです。

-開発効率化