Codexとの会話が長くなるほど、前に話した内容がそのまま残っていること自体が、かえって邪魔になってきました。途中でやめた案も、古い仕様も、いま採用している判断も、同じ会話の中に同じ重さで並んでいるからです。セッションを新しくすれば、その山を最初から読み直すところに戻ります。
そこで2026年8月15日、私は自分のPCで、「保存して」と伝えるとプロジェクトの現在地を調べ、次の作業に必要な内容だけを外部ファイルへ書き出す仕組みを作りました。作った当日に、過去のチャットへも同じやり方を適用しています。
長い会話を、現在の状態へ圧縮する
たとえば開発中に、A方式からB方式を経てC方式へ変わったとします。次に作業を再開するとき、AとBを検討した経緯を全部たどり直す必要はありません。現在はC方式であること、そちらを採った理由、テストがどこまで通っているか、何が残っているか。それが分かれば手は動きます。
私が外部ファイルへ残したいのも、会話の短い要約ではなく、そこです。現在の目標と実装状況、設計判断とその理由、次に開くべき主要ファイル、実行したテストと結果、既知の問題、不採用にした方法、未完了の項目と次の行動。加えて、公開や削除のように人の承認が要る操作の線引きも一緒に書いておきます。
「会話をアーカイブすればトークンを80％節約できる」といった固定の効果は、私は計測していません。不要になった検討過程を毎回読ませずに済むぶん、期間の長い仕事ほど整理は効きやすい、という程度に扱っています。削減率を保証できる話ではありません。
状態ファイルは、コードとGitから組み直す
現在地はDEV_STATE.mdのような一枚のファイルにまとめられます。ただし、その中身をチャットの内容だけから起こすと壊れます。
会話の中では実装済みでも、ファイルへ反映されないまま終わっていることがあります。いったん書いて、あとで戻していることもあります。テストが落ちたままなら、それは「完成」ではありません。
そこで私は、保存する前に現在のコード、Gitの状態と差分、テスト結果、公開済みの内容を見てから書くようにしました。記録と現物が食い違ったときは、現物を正として記録のほうを直します。
このファイルは開発日記でもありません。完了して今後の判断に効かなくなった情報は減らします。履歴を積む場所と、今日の状態を読む場所を分けておかないと、結局また長い記録を読み直すことになるからです。
「保存して」で走る処理
今回作った保存処理は、大きく四つの段階に分かれています。
- コード、Git、テスト結果を確認し、目標、判断、問題、次の行動を組み立てる
- 秘密情報や顧客情報が混ざっていないか検査し、今日の状態と、変更しない履歴とを分ける
- 読み返し用の複製と、変更履歴用の記録を、それぞれの保存先へ書き出す
- 別の場所から復元できるかを確かめる
生のチャット全文、ソースコード本体、バイナリ、APIキー、Cookie、顧客情報、個人情報、非公開URL、PC内の絶対パスは、この対象から外しています。
保存先を三つに分けた理由
保存先は、PC内の記憶専用フォルダ、非公開のGitHubリポジトリ、Google Drive上のObsidian保管庫の三つです。役割を分けています。
| 保存先 | 私の使い分け |
|---|---|
| PC内の専用フォルダ | ファイルを作り、内容を検査する |
| 非公開GitHub | 変更履歴を残し、別環境から復元する |
| Google Drive上のObsidian | 現状と過去の判断を人が読み返す |
Obsidian保管庫には`.git`を置いていません。同期されるフォルダの中へGitの管理情報まで入れて、競合や破損の材料を増やしたくなかったためです。履歴はGitHub、読み返すノートはObsidian、と切りました。
毎日の仕事メモを同じ項目で残し、Claude CodeやCodexへ渡すところから始める場合は、ObsidianのTemplaterで仕事メモを作る手順で、目的・決定・未確認事項を固定するひな型を使えます。
私は以前、Notionを第二の脳に近い保存先として使っていました。記録が増え、Claude CodeやCodexから必要なファイルを選んで読ませる作業が増えたことで、いまの分け方へ移っています。Notionが一般に不向きだという話ではなく、私の作業量と参照のしかたに合わせた判断です。
PLAUDの記録をNotionへ保存し、Obsidianへ移した経緯
作業中のリポジトリへは書き込まなかった
最初は、各プロジェクトのリポジトリへDEV_STATE.mdを一枚足せば済むと考えていました。ところがPCの中を見ると、作業リポジトリには約9,300件のステージ済みファイルがあり、そのほかに未ステージ・未追跡のファイルも残っていました。ブラウザのキャッシュやCookieに関係する、触れたくないパスも含まれていました。
これは私の環境を、その日に見た時点の結果です。それでも、この状態で`git add .`や`git add -A`を使えば、残したい記録とは無関係なものまで一緒に入ります。
そこで既存のプロジェクトには手を入れず、長期保存だけを扱う非公開リポジトリを別に立てました。コミットするときも、今回生成したファイルを一つずつ名指しします。非公開だから何を入れてもよい、とは考えていません。アクセス制限とは別に、保存前の除外と秘密情報の検査を通します。
過去チャットは、プロジェクト単位にまとめ直した
同じやり方は、取得できた過去チャットにも通りました。
そのとき確認できた直近50件から現在の会話を除き、まだ続いていると判断した13件へ、読み取り専用の移行指示を送っています。全部を一つのファイルへ混ぜたわけではありません。それぞれ対応するプロジェクトを特定し、同じ仕事について複数の会話がある場合だけ、一つの現在地へ統合しました。初回に長期保存できたのは、8つの継続プロジェクトです。接続できなかった別環境のチャットは含みません。
古い会話は、どこを調べればいいかの手掛かりにはなります。ただし会話そのものを正本には置きません。現在のファイル、Git、テスト、公開状態と突き合わせてから、次の手を決めます。
復元できるところまで確かめた
ファイルを書き出した時点では、まだ長期記憶として成立していません。今回は次の点を試しました。
- 秘密情報を模した文字列が、長期保存の前に拒否されること
- PC側とObsidian側にある32ファイルのハッシュが一致すること
- GitHubリポジトリが非公開になっていること
- GitHubから一時フォルダへ複製し、記録を復元できること
- 記憶専用リポジトリに、未記録の差分が残っていないこと
PCからGoogle Drive上の保管庫へ書き込めることは確かめましたが、クラウド側へ反映される時刻までは保証していません。「書いた」で終わらせず、必要な場所から読めるところまで見ます。
新しいセッションでは、記録も疑って読ませる
新しいCodexセッションでは、こう伝えると入りが早くなります。
DEV_STATE.mdを読み、現在のコード、Gitの状態、テスト結果と差異がないか確認してください。差異があれば現物を優先して状態を更新し、Next Actionsの先頭から作業を続けてください。
保存したあとに別の変更が入れば、この一枚も古くなります。古い指示を守らせ続けるための仕掛けではなく、短時間で現在地を取り直すための入口として置いています。
保存と、外部への操作は分ける
私の運用で「保存して」が指すのは、外部記憶へ現在の状態を記録することだけです。WordPressの公開、SNSへの送信、作業リポジトリのコミットやプッシュ、デプロイ、削除、課金、アカウント設定の変更は、この言葉には入りません。どれも別に明示して承認します。
営業の記録でも、同じ線を引いています。PLAUDの文字起こし原文とAI要約は分けたまま保存し、要約だけで固有名詞、数字、担当者、期限を確定させません。必要な箇所は元音声と前後の文脈へ戻ります。
AIへ渡す範囲、正本にする記録、公開や社外送信の判断は、人が持ちます。会話を記憶装置にしない。Gitとファイルを記憶装置にして、AIには必要な現在地だけ読ませる。この分け方を、数日空いた後や別のセッションでも、現物を見ながら続きへ戻るための入口にしています。
よくある疑問
この仕組みで、AI自身が覚えてくれるようになりますか？
なりません。AIの外側にあるファイルを、人とAIが読み書きしているだけです。次に立ち上げたAIは、そのファイルを読んだぶんだけ現在地を知ります。
最初からGitHubやObsidianまで用意しないと始められませんか？
一つのフォルダと一枚の状態ファイルで始められます。目標、いまできていること、確定した判断、残った問題、次の行動を書いておく。履歴からの復元や、複数プロジェクトの整理が必要になった段階で、保存先を分ければ間に合います。
