会話を残す手段、知らずに損していませんか
Claude Code で長時間のデバッグセッションを終えた翌朝、「あの議論、どこまで掘り下げたんだっけ」と思ったことはないでしょうか。バグの再現手順・試した仮説・却下した実装案——それらはすべて昨日の会話の中にあったはずが、セッションを閉じた瞬間にアクセスしにくくなる。新しいセッションで「続きから」と話しかけても、コンテキストは白紙に戻ります。
この問題を解決する組み込みコマンドが /export です。Claude Code には会話履歴を plain text ファイルとして書き出す機能が標準搭載されていますが、「コマンドの存在は知っていたけど使ったことがない」という方は多いはずです。スラッシュコマンド全般については別記事で整理していますが、/export だけは単体で深掘りする価値があると感じて本記事を書きました。
何のために使うか — 活用事例
コマンドの仕様に入る前に、「なぜ会話を残すのか」を先に整理します。使う動機が明確でないと、あとで「結局やらなかった」になりやすいためです。
設計判断の記録
大規模リファクタに入る前、「なぜこのアーキテクチャ判断にしたか」を Claude と詰める時間があります。その議論を /export decision-2026-05-24.md で保存しておけば、半年後に「なぜこうしたのか」と問われたとき、会話ログを開くだけで経緯を再現できます。ADR（Architecture Decision Record）の下書きとしても使えますし、Git にコミットすれば「考えた記録」として残ります。
デバッグセッションの引き継ぎ
長時間のデバッグ。バグの再現手順・試した仮説・効かなかった対処が会話に蓄積されていきます。完了時点で /export bug-1234-investigation.md し、PR や issue にリンクを添えておけば、同じバグが再発したとき誰でも参照できます。「どう直したか」だけでなく「何をやったら直らなかったか」が残るのが、自分の文章で書いたドキュメントとの差です。
チームへの共有
「どうやって直したの？」と聞かれたとき、Slack で説明する代わりに /export の中身をそのまま貼る。手順だけでなく「Claude にどう聞いたか」「どこで間違えたか」も伝わります。チームメンバーが同じプロンプトを再現する際の参考にもなります。
ADR 補助・コードベース外のドキュメント化
README や設計書には書ききれない検討プロセスを別ファイルで保管する使い方です。「なぜこの設計を選ばなかったか」という否定の文脈こそ、後から読み返したときに価値を持ちます。このブログを動かしている blog-agents の運用でも、researcher が脱線したセッション・auditor が usage limit に当たった瞬間などを /export しておけば、記事化の一次資料として活用できると痛感しています。
公式仕様 — 実際の使い方
公式 commands リファレンスの定義は1行です。
> /export [filename] — Export the current conversation as plain text. With a filename, writes directly to that file. Without, opens a dialog to copy to clipboard or save to a file.
短い定義ですが、引数の有無によって挙動が変わります。
引数なしで /export
ダイアログが開き、「クリップボードにコピー」または「ファイルに保存」を選べます。保存先とファイル名はその場で指定します。初めて使う場合はこのパターンで試してみてください。
/export でファイル直書き
/export auth-refactor-notes.md
/export bug-1234-investigation.md
/export decision-2026-05-24.mdファイルパスを直接指定すると、ダイアログなしで書き込みます。既存ファイルがあれば上書きになるため、日付をファイル名に含める習慣にしておくと安全です。繰り返し使う場合はこのパターンが最も速い。
/export からクリップボード選択
ダイアログで「クリップボード」を選ぶと、テキスト全体がコピーされます。Slack や PR コメントへ即貼り付けたいときに向きます。
出力フォーマットは plain text のみ です。JSON や Markdown の構造化フォーマットには対応していません。システムプロンプト・tool 呼び出し・コードブロック・Claude の応答が会話の流れとして人間可読な形で書き出されます。
transcript JSONL との関係
/export の出力と「セッションファイル」の関係を整理します。
Claude Code はセッションの生データを ~/.claude/projects/ 配下に JSONL 形式で自動保存しています。このブログの blog-agents プロジェクトの場合、~/.claude/projects/-Users-itoudaichi-project-blog-agents/ に 5 本以上の JSONL ファイルが存在し、最大 6.5MB・最小 2.8KB という規模感です。
JSONL の先頭数行はこういった構造になっています。
{"type":"permission-mode","permissionMode":"bypassPermissions","sessionId":"89c900db-..."}
{"type":"queue-operation","operation":"enqueue","timestamp":"2026-05-12T21:04:56.001Z",...}
{"parentUuid":null,"type":"user","message":{"role":"user","content":"..."},"sessionId":"..."}tool_use_id・session_id・raw_tool_input などを含む機械可読なデータ構造で、人間がそのまま読むには向きません。/export はこの生 JSONL を「人間が読める transcript」に整形して plain text で出力する、という関係になっています。
用途別の使い分けをまとめると次の通りです。
| 用途 | 推奨手段 |
|---|---|
同じ会話を別マシンで /resume したい | JSONL（自動で利用される） |
| 会話を共有・アーカイブしたい | /export |
| 過去ログを検索・発掘したい | サードパーティ extractor |
| 機械処理・構造化が必要 | サードパーティ extractor |
/export は手動で実行するコマンドです。JSONL は Claude Code が自動保存するものです。「残したい」と思ったタイミングで /export を打つ習慣が、運用上のポイントになります。
/export で取り出したログをどう整理するかについては、knowledge/ の設計と活用も参考になります。
類似コマンドとの使い分け
/export と混同しやすい公式コマンドがいくつかあります。名前や説明文だけ見ると目的がかぶって見えるので、実際に触った感覚をもとに整理します。
/copy [n]
最後（または n 番目前）の応答だけをクリップボードに取ります。インタラクティブなコードブロック選択 UI が開くため、「直前の回答のコードだけ欲しい」というピンポイント操作に向いています。全部ではなく一部を取りたいときは /copy です。
/recap
現在のセッションを一行サマリで返します。「今日何をやったっけ」を手早く確認したいときに使います。サマリであって記録ではないため、後から詳しく参照したい場合は /export が必要です。
/insights
セッションの分析レポートを生成します。プロジェクト領域・作業パターン・摩擦点などの俯瞰情報が得られます。個別の会話を取り出すものではないため、/export の代替にはなりません。
/feedback（aliases: /bug, /share）
会話を Anthropic にフィードバックとして送信します。/share というエイリアスがあるため「共有」と勘違いしやすいですが、これは Anthropic への共有であり、チームへの共有ではありません。
会話全体を外部ファイルとして取り出す組み込み手段は /export だけです。
サードパーティで補う — claude-conversation-extractor と ccexport
組み込みの /export で対応できないケースには、外部ツールが選択肢になります。
claude-conversation-extractor — 実績あり
GitHub スター 581個（フォーク 76）、最新リリース v1.1.2 でアクティブにメンテされているツールです（GitHubの公開情報より）。
pipx install claude-conversation-extractor~/.claude/projects/ の JSONL を直接読んで Markdown / JSON / HTML に変換します。特筆すべき機能は過去ログの検索です。「あのデバッグセッション、いつだったっけ」という状況で力を発揮します。/export が「今の会話を残す」ためのコマンドなのに対し、こちらは「過去の会話を発掘する」ためのツールと整理できます。
ccexport — シークレット redact が必要なケース
GitHub スター 4個の小規模プロジェクトで、メンテ状況は不明です。GitHub-flavored Markdown 変換と複数の HTML テンプレートに対応していますが、最大の特徴は TruffleHog による自動シークレット検出・redact 機能です。会話ログを外部公開・ブログ記事化する場合、API キーや認証情報が混入していないか確認が必要です。ccexport はその検出を自動化します。ただし、スター数と規模感から、本番運用での採用には慎重な判断が必要です。
どちらを選ぶか
正直なところ、ほとんどのケースは /export で事足ります。外部ツールを使う場面は限られています。
- 社内 Slack・PR・自分用アーカイブ →
/exportで十分 - 公開ブログ・記事化（シークレット検出が欲しい）→ ccexport
- 古いセッションの発掘・検索 → claude-conversation-extractor
- 機械処理・JSON 構造化が必要 → claude-conversation-extractor
まとめ
/export は地味なコマンドですが、「昨日の議論を今日に持ち越す」「デバッグの経緯をチームに伝える」「設計判断の背景を残す」という使い方を続けると、プロジェクトに知識が溜まります。
まずは次のセッション終了時に一度、/export を打ってみてください。plain text で書き出されたログを眺めると、「これ、残しておいてよかった」と思う瞬間が来るはずです。
過去ログをさかのぼりたくなったタイミングで claude-conversation-extractor を導入する、という順序が現実的です。最初から全部を整えようとせず、/export の習慣化からはじめてみてください。
コメント