Session Log × Assets
フォルダをひとつ動かしたら、昨日の会話が消えた。
AIとの作業ログは、静かに積もり、あっけなく迷子になる。
三度の事故と、そのログが化けたものの記録。
会話そのものは、
いつか消える。
蒸留したものだけが、
持ち運べる。
Claude Code のような AI エージェントと毎日仕事をしていると、会話の記録——セッションログ——が手元に静かに積もっていく。前作「エージェントハーネスの内部」では、このログ29本を顕微鏡のように覗き込み、AI エージェントの内部構造を解剖した。本作はその続編だ。今度は顕微鏡を置いて、ログを資産として運用する話をする。消失、復旧、引っ越し、蒸留、集計——そして最後は、遊び。
この記事の問い
AI との共同作業の記録は、
いま、どこにいるのか。いつ、消えるのか。
そして正しく扱えば、何に化けるのか?
先に答えを置く。ログの居場所は作業フォルダのパスに縛られていて、フォルダのリネームひとつで迷子になる。実際、自分は3回消しかけた。それでも正しく扱えば、ルールに、スキルに、コスト分析に、果ては動画の素材にまで化ける。そして3回の事故の末に行き着いた鍵は、意外にも「全部を守る」ではなかった。会話そのものより、そこから蒸留した記憶（memory）と原則を持ち運ぶ——それだけで、仕事は途切れない。
ざっくり言うと
AI との会話ログは、住所（作業フォルダのパス）で棚分けされた倉庫に自動で仕舞われていく。フォルダの移動やリネームは住所変更だ。届け出をしないと、荷物は旧住所の棚に取り残され、新居からは見えなくなる。段ボールを全部運び直す手もある。だが本当に要るのは、決めごとを書き溜めた1冊のノートだけ——それさえ手元にあれば、仕事は続けられる。
Chapter 01
ざっくり言うと——Claude Code との会話は、1行1メッセージのテキストファイルとして、ぜんぶ手元に残っている。棚の名前は「どのフォルダで作業を始めたか」のパスそのもの。だから、フォルダが動くと紐付けが切れる。
まず、在り処から。Claude Code との会話は、ホームディレクトリの隠しフォルダ ~/.claude/projects/ の下に、勝手に保存されていく。開いてみると、ハイフンだらけの見慣れないフォルダ名がずらりと並ぶ。
正体は、作業フォルダの絶対パスだ。手元の複数の実例を見比べるかぎり、規則はこう推測できる——先頭に - を置き、パス区切りの / と、英数字以外の文字（空白・_・.・日本語など）をぜんぶ - に置き換える。たとえば /Users/me/workspace/my-app で作業を始めれば、-Users-me-workspace-my-app という棚ができる。公式の明文仕様は見つけていないので、ここは「実例からの帰納」と断っておく。この棚の名前を、以降プロジェクトキーと呼ぶ。
~/.claude/projects/ └─ -Users-me-workspace-my-app/ ← プロジェクトキー（パス由来） ├─ <セッションID>.jsonl ← 会話本体（1行＝1メッセージ） ├─ <セッションID>/ │ ├─ subagents/ ← 分身たちの作業ログ │ └─ tool-results/ ← 大きな実行結果の退避先 └─ memory/ ← 蒸留された記憶
棚の中身の主役は <セッションID>.jsonl——会話の本体だ。JSONL は「1行に1個のJSON」を積んだだけのテキスト形式で、1行がおおよそ1メッセージにあたる。各行には作業フォルダ（cwd）・時刻・発話者の種別が入り、AI の応答行にはトークン使用量の内訳まで刻まれている。前作で解剖したのは、まさにこのファイルだった。
本体の脇には、同名のフォルダがぶら下がる。subagents/ には並列で走らせた分身（サブエージェント）の作業ログ、tool-results/ には大きすぎて本体に収まらないツール実行結果の退避分。そして棚の直下にもうひとつ、memory/——AI が会話から蒸留した記憶のメモ置き場がある。索引の MEMORY.md と、トピック別のメモ。どのセッションから生まれた記憶かの ID まで刻まれている。この memory/ が、後の章で主役になる。
ここまでは、平和な話だ。問題は、この仕組みが「作業フォルダのパス」を唯一の鍵にしていること。フォルダの場所や名前を変えれば、パスが変わる。パスが変わればキーが変わる。過去ログは旧キーの棚に残ったまま、claude --resume（会話の再開コマンド）の一覧から静かに消える。——ここから、それを3回やった記録になる。
Chapter 02
ざっくり言うと——PC の引っ越しで予兆を踏み、2日後、フォルダ整理で本番が来た。前日から続くセッションが再開一覧から消え、grep での捜索と519箇所のパス書き換えという外科手術で、会話は戻ってきた。
予兆は、PC の引っ越し（2026年5月19日）で踏んでいた。新しい PC へセッションログも運ぼうとしたら、まず macOS 同梱の rsync が古くて、使いたいオプションに対応しておらず失敗。次に cp -rn が、コピー元のフォルダ名——例のプロジェクトキー——が - で始まっているせいで、フォルダ名をコマンドのオプションと誤認してまた失敗。あのハイフンだらけの命名は、シェルコマンドの足元まで狙ってくる。最終的に絶対パス指定に切り替えて、7プロジェクト分を一括コピーした。
このとき既に「フォルダ構成を develop/ から workspace/ に変えたら、過去のやりとりが見えない」という症状も併発していて、過去の JSONL を新パスのキー側へコピーして凌いだ。ログはパスに紐づく——頭では分かったつもりだった。
2日後の5月21日、本番が来た。フォルダ整理の一環で、あるプロジェクトのフォルダを別の場所へ動かした。作業場の整頓そのものは、ふだんから気にかけている話で、作業場の設計について記事を書いたこともある。ただ、その整頓に副作用があった。前日から続けていた作業セッション——8MB・597行——が、再開一覧から消えたのだ。
復旧は、外科手術になった。まず grep で全プロジェクトの棚を横断検索し、作業キーワードを含む JSONL を探して迷子を特定。先頭行に記録された旧 cwd を読み取り、会話が参照していたファイル10個が新パス側に実在することを確かめてから、旧 JSONL を新プロジェクトキーの棚へ同名コピーした。
これだけでは終わらない。ログの中身には、旧絶対パスが染み込んでいる。Python で全文を読み込み、旧パス→新パスを519箇所置換。さらに Markdown リンク表記で残っていた相対パスを4箇所。最後に、全597行が JSON として読めることを検証して、旧ファイルは壊さず残した。ここまでやって、ようやく再開一覧に会話が帰ってきた。
もうひとつの台帳と、NFD の罠
手術の途中で、CLI とは別に Desktop アプリが独自の台帳を持っていることも見つけた。場所も別で、cwd やセッションのタイトルを独自に抱えている。しかもそちらのパスは NFD 正規化——「ば」を「は＋濁点」という別のバイト列で持つ、Mac 由来の文字の持ち方——で格納されていて、見た目が同じ文字列でも単純置換では一致しない。バックアップを取り、cwd 系の2フィールドだけを、正規化を考慮して書き換えた。（Desktop 側はこの書き換えまでで、一覧表示が戻ったかの最終確認はログに残っていない。）
会話は戻った。ただ、かかった手数を数えると——grep 捜索、コピー、519＋4箇所の置換、597行の検証、別台帳の修正。次も同じ手術をやる気には、なれなかった。
Chapter 03
ざっくり言うと——1ヶ月後の移動では、消える前に手を打った。プロジェクト本体とログの棚を、続けて mv で一括移動。ここで「プロジェクトキーはセッション開始時に固定される」という挙動をひとつ学んだ。
1ヶ月あまり経った6月30日、今度は自作プロジェクトをホーム直下から workspace/ 配下へ移す用事ができた。前回の教訓は単純だ。事故ってから運ぶのではなく、消える前に、同時に運ぶ。
手順も、前回よりずっと短い。コードに絶対パスが焼き込まれていないか、動作中のプロセスがないかを先に確かめて、あとは本体とログの棚を続けて動かすだけ。
# 本体と、ログの棚を、続けて動かす mv ~/my-app ~/workspace/my-app mv ~/.claude/projects/-Users-me-my-app \ ~/.claude/projects/-Users-me-workspace-my-app
面白かったのは、そのあとだ。移動を頼んだセッション自身は、まだ走っている。そしてそのセッションは、mv のあとも旧キーの棚に書き込み続けた。つまり Claude Code は、プロジェクトキーをセッション開始時に一度だけ決めて、以後はそれを使い回す。結果、同じセッション ID のファイルが新旧の棚に分裂した。
発見
プロジェクトキーは、セッション開始時に固定される。
走行中のセッションは、フォルダを動かしても旧キーに書き続ける。
だから後始末（旧断片を新側へ追記して、旧棚を消す）は、セッションが終わってから。
外科手術に比べれば、あっけないほど軽い。ただ、この時点でもまだ「会話ログは運ぶべきもの」という前提そのものは疑っていなかった。それが変わるのが、3回目だ。
Chapter 04
ざっくり言うと——3回目は、会話ログをあえて置いていった。運んだのは許可設定の引き継ぎと memory フォルダだけ。それでも翌セッションの AI は「メモリとgit履歴で状況を把握できました」と言って、作業をやり切った。
3回目は7月8日。自作 MCP サーバーのリポジトリを bookmeter-mcp から media-log-mcp へ改名するのにあわせて、手元のフォルダ名も変える必要が出た。読書記録だけだった中身が、メディア全般の記録に育った——その改名だ。
今回の手順には、これまでと違う判断がひとつ入っている。GitHub 上でリポジトリを改名し、設定ファイル ~/.claude.json をバックアップしてから、フォルダを mv。~/.claude.json の中の MCP サーバーのパスと、projects のキー名を書き換えて、ツール許可の設定を引き継ぐ。それから memory/ フォルダを新キーの棚へ cp -R——記憶は、リネームに自動では付いてこないからだ。一方で、MCP の登録名（変えると許可設定が無効になる）と、デプロイ先のスタック名（URL の再発行を避ける）は、わざと据え置いた。
そして——会話の JSONL は、移さなかった。519箇所の置換をもう一度やる価値が、あるとは思えなかった。
翌セッション。自分は正直にこう頼んだ。「フォルダ名変更で作業ログ消えてるかもだけど、続きの作業をお願い」。AI は過去の会話ログには一切触れず、新キー側に運んでおいた memory と、git のコミット履歴から状況を組み立て直し、デプロイまでやり切った。ログにはこう残っている——「フォルダ名変更後もメモリとgit履歴で状況を把握できました」。
| 観点 | ① 5/21 事後 | ② 6/30 同時 | ③ 7/8 設計込み |
|---|---|---|---|
| 会話ログ | 手術で復元（519＋4箇所置換） | mv で温存 | 移さない（割り切り） |
| 頼り先 | JSONL 手術＋別台帳の修正 | ディレクトリごと移動 | memory ＋ git 履歴 |
| 手数 | 最多 | 中 | 最少 |
並べてみると、事後の手術→同時の引っ越し→そもそも運ばない、と手数が減り続けている。これを「洗練」と読むのは自分の解釈だが、3回目で何を運び何を捨てるかは、明確に選んでいる。変わったのは技術ではなく、何を本体とみなすかだ。1回目は、会話の全文が本体だと思っていた。3回目には、蒸留された記憶と、コードの履歴があれば仕事は続くと分かっていた。会話はキャッシュで、memory と git が本体——そう見えた瞬間、ログの消失は「事故」ではなく「許容できる劣化」になる。
Chapter 05 — 図で見る
ざっくり言うと——リネームが切るのは「作業フォルダ→プロジェクトキー」のたった1本。だがその1本で、下にぶら下がる会話も分身のログも記憶も、まとめて迷子になる。手で運ぶのは記憶と許可、会話は置いていける。
3回分の経験を、1枚に畳むとこうなる。倉庫の構造と、リネームで切れる線と、手で運ぶべきもの。
リネームや移動が切るのは、左の「フォルダ→キー」のたった1本。だがキーが変われば、旧キーの棚ごと——会話も、分身のログも、記憶も——再開一覧から見えなくなる。会話の JSONL まで運ぶなら、中身のパス置換が必要になる（第2章の手術）。運ばないと決めるなら、memory/ と許可設定の2つだけを手で持って行く（第4章の割り切り）。どちらを選ぶかは、会話の全文をどれだけ「本体」とみなすか次第だ。
図の下段が、3回の事故の答え合わせになっている。そして、ここまでは倉庫を「守る」話だった。ここからは、この倉庫を「使う」話に移る。掘る、数える、遊ぶ——の3本立てだ。
Chapter 06
ざっくり言うと——852本のログから「繰り返した修正指示」「再発した失敗」「うまくいった手順」を掘り出し、二十数本のルールと3本のスキルに蒸留した。再発する失敗の大半は、「出力前の検証不足」というひとつの根に行き着いた。
倉庫を守れるようになったら、次は掘る番だ。7月2日、たまったログに対して、こういう発注をした。繰り返している修正指示はルールに。再発している失敗は禁止事項に。うまくいった手順はスキル（再利用できる作業手順書）に——分類して提案し、反映は承認を待て。
手元の全 JSONL を走査すると、852セッションあった。全部を精読させるのではなく、主要7プロジェクトの直近約50セッションに絞り、jq というコマンドで「ユーザーの発話だけ」を抽出してから、プロジェクト別に4本の分身へ並列で分析させた。AI の応答は膨大だが、自分が何を言い直したかはユーザー発話に凝縮されている——掘るなら、そこだけでいい。
最大の所見
再発する失敗の大半は、「出力前の検証不足」に行き着いた。
リンクの実在を確かめない。レイアウト崩れを見ない。事実の裏取りをしない。デプロイの反映を確認しない。
——別々の失敗に見えて、根はぜんぶ同じだった。
逆に、うまくいっていたのは「構造化した発注→ラベル付きの選択肢→短い承認」で回っているときだった。成果はあわせて9件。グローバル用に新設した CLAUDE.md（AI への常設指示書）に11本、このサイトのプロジェクトに追記6本、別プロジェクトに新設7本、ノート置き場側にも追記——という二十数本のルールと、新規スキル3本、既存コマンドの修正2件。うち「コード図解」のスキルは、4つのプロジェクトで9回以上繰り返していた定型作業を、1コマンドに吸収したものだ。変更前のファイルはバックアップへ退避してから反映した。
このとき生まれたスキルは、いまも現役で動いている。ログを掘って作ったルールが、その後のログの中で実際に効いている——資産と呼びたくなるのは、この循環があるからだ。ついでに、この「jq でユーザー発話だけ抜いて並列分析」という掘り方そのものも memory に記録した。レシピもまた、資産になる。
ひとつ、裏返しの注意も書いておく。掘れるのは、ログに残った作業だけだ。たとえばローカルLLM——手元のPCだけで動かすAI——を試した記事のように、Claude Code の外で回した試行錯誤は、この倉庫には積もらない。あとから資産に変えられるのは、記録された作業だけ。記録の外の苦労は、思い出補正つきの記憶にしか残らない。
Chapter 07
ざっくり言うと——ログに残るトークン内訳を全部足すと、会話の正体が見える。量にして9割超が「キャッシュの読み直し」で、新しく書かれる出力は1%未満。会話のコストはおおよそ「ターン数×そのとき抱えている文脈量」で決まる。
ログの各行には、トークン使用量の内訳——新規の入力、出力、キャッシュへの書き込み、キャッシュからの読み込み——が刻まれている。つまり、足し算するだけで、自分と AI の会話が何でできているかを割り出せる。6月と7月、2回に分けて集計した。
1回目は6月11日。約2ヶ月分・71セッションを Python で集計すると、出力トークンは約1,300万。対してキャッシュ読込は約9.2億——トークン量の約85%を占めていた。1応答が抱えるコンテキストは中央値13.8万トークン、上位10%は33万トークン。月ごとの出力も215万→335万→（6月は11日時点で）559万と加速していて、その日の5時間だけで API 呼び出しは1,492回、13本のセッションが入れ替わり立ち替わり走っていた（同時最大4本）。
自分の計測を、自分で正す
最初のレポートで、この「キャッシュ読込85%」を、そのままコストの85%であるかのように扱いかけた。だが85%はトークン量の話で、キャッシュ読込は単価が大幅に安い。単価で按分し直すと、キャッシュ読込の寄与は約39%まで下がる。量の85%と、負担の39%。集計は、単位を取り違えた瞬間に嘘をつく。
2回目の7月3日は、もっと踏み込んだ。直近2日・Fable 5 を使った153セッションを、モデルの単価とキャッシュ倍率まで含めて全件合算。トークン構成はキャッシュ読取92.5%、出力はわずか0.8%。AI との会話は、新しい言葉のやりとりではなく、「これまでの文脈を毎ターン読み直す」営みでできている。だからコストの法則は、近似的にこうなる——ターン数 × 1ターンあたりのコンテキスト量。文脈が20万トークン近くまで育った長い会話は、何を頼んでも、1ターンごとに読み直しの固定費がかかる。
実例をひとつ。「ノート置き場の重複・矛盾を調査して整理」という発注は、自分の発話はたった4ターンだったのに、AI 側は482ターン・総1.35億トークン・使い捨ての分身139本という規模になった。指示の短さと、動く量は比例しない。この構造をどう設計に活かすかは、トークンの配分設計の記事で書いた話と地続きだ。
そして、この分析も最後は道具に昇華させた。集計ロジックを読み取り専用の自己診断スクリプト（claude_cost.py）に落とし、実ログとの一致を検証した。方針はひとつ——自分の固有の実績値は捨て、誰でも自分のログで再現・検証できる原理と直し方だけを残す。数字は古びるが、測り方は古びない。ログの資産化として、これがたぶん一番きれいな形だと思っている。
Chapter 08
ざっくり言うと——ログには「AI が何を作ったか」のファイルパスも全部残っている。それを索引に過去の成果物を掘り出し、10本選んで30秒のループ映像に仕立てた。ログは日記であると同時に、成果物の索引でもある。
最後は、肩の力を抜いた使い道を。7月7日、こんな発注をした。「セッションログから、やってたプロジェクトの artifact 拾って30秒くらいの attract movie 作って」。attract movie というのは、ゲームセンターの筐体が、誰も遊んでいないあいだに流しているデモ映像のことだ。
種明かしをすれば、これもただのログ活用だった。JSONL を grep すると、AI が Write ツールで生成した HTML ファイルのパスが36個出てくる。実在を確かめると23個。そこからジャンルの違う10本を選び、headless Chrome（画面なしで動くブラウザ）で実際にレンダリングしてスクリーンショットを撮り、ゆっくりズームする演出とキャプションを付けて、30秒のループ映像（HTML+JS）にした。家計レポートのように資産額が写り込むものは、タイトル部分だけを切り出す配慮も入れて。
後日、特定のモデルとの作業に絞った11.2秒・7カットの小さな GIF 版も作った。数ヶ月分の作業がデモ画面みたいに流れていくのは、単純にうれしい。
遊びと呼んだが、気づきはある。ログは読み返す日記であるだけでなく、成果物の索引でもある。「いつ何を話したか」ではなく、「何が生み出されたか」で引ける。第4章で、会話の全文を運ぶ価値は薄いと書いた。正確にはこうだ——会話の本文は読み返さなくても、そこに刻まれたパスと数字は、あとから何度でも働く。
消えかけた記録の話から始めて、ルール、スキル、数字、映像まで来た。振り返れば、やっていることはずっとひとつだ。会話という揮発しやすい素材から、揮発しないものを蒸留して、パスの変化に耐える場所へ置く。memory へ、CLAUDE.md へ、スキルへ、スクリプトへ、git へ。そこまでやって初めて、ログは「積もっているだけのファイル」から、資産になる。
Coda
会話そのものは、
いつか消える。
蒸留したものだけが、
残って、働く。
三度の事故が教えてくれたのは、守り方より、
持ち運ぶべきものの正体だった。
セッションログは、放っておけばただ積もる。ときどき掘り返して、ルールに、スキルに、数字に、ときには30秒の映像に変えてやる。フォルダをリネームする日が来ても、蒸留したものだけは手に持って歩く。それだけで、AI との仕事は途切れなくなる。
Fact-check
本記事の出来事は、すべて筆者自身のセッションログに残る実作業に基づく：PC移行（2026-05-19）・消失からの復旧（05-21）・予防の一括移動（06-30）・リネーム時の割り切り（07-08）・ナレッジ抽出（07-02）・トークン分析（06-11と07-03）・映像化（07-07）。519＋4箇所の置換、597行、852セッション、ルール11＋6＋7本と新規スキル3本、キャッシュ読取92.5%／出力0.8%（07-03・直近2日153セッションの実測）、キャッシュ読込約9.2億トークン＝量の約85%（06-11・約2ヶ月分の実測）、482ターン・総1.35億トークンなどの数値は、各ログの記載のとおり。トークン比率は筆者の使い方での実測値であり、誰にでも当てはまる一般値ではない。プロジェクトキーのエンコード規則（先頭に-、/と記号類を-へ置換）は複数の実例からの帰納で、公式仕様の明文は未確認。「プロジェクトキーはセッション開始時に固定」（06-30）と「フォルダ名変更後もメモリとgit履歴で状況を把握できました」（07-08）は、ログ内の発言として記録がある。パス例のユーザー名やプロジェクト名は一般化して表記した。一方で、3回の対応を「洗練」と読む筋立てと、「会話はキャッシュ、memoryとgitが本体」という整理は、筆者の解釈だ。事実の誤りには、反論を歓迎する。
連作: ハーネスの解剖と運用（全2回）解剖 → 運用