背景
Claude Code のセッションは、私にとって「記事を書く場」ではなく わからないことを聞いて理解を深める場 です。それなのに調査結果は会話ログに閉じてしまい、後から見返しづらいのが悩みでした。一方、入り口で「これは記事にする」と意識すると質問が制約されます。記事化は 後付けで効くようにしたい という気持ちがありました。
そこで「Claude Code での Q&A は自由に進め、最後にコマンド1発でブログのドラフトに変換する」運用に切り替えました。
方法
カスタムスラッシュコマンド
.claude/commands/<name>.md をプロジェクト直下に置くと、/<name> として呼べます。本文がそのままプロンプトとして展開されます。コマンドは Git 管理されるので、指示文面の改訂履歴がそのまま残ります。
コマンドのサンプルは、この記事の最後に乗せています。
コマンドファイルの主な仕様
.claude/commands/draft.md に明文化している指示は次のとおりです。
- 想定読者はその分野の技術者。初心者向けの噛み砕きは入れない
- 構成の型は「背景 → 方法 → 結果 → 議論」
- 一人称は「私」、文体は「ですます調」
- このセッションで実際に話した内容だけを書く（「次に試したいこと」などの推測セクション禁止）
- カテゴリは frontmatter にもタグにも書かない（事後決定）
- タグは1つだけ
draft: true必須- 保存先はカテゴリディレクトリを作らず
src/content/posts/draft/直下 - 比較は具体物（コード・設定・差分・数値）で
- 出力はファイルパスだけ
結果
運用は次の手順に収まりました。
/clearで新しいセッションを開く（記事化は意識しない）- わからないことを自由に聞き、調べる
- 理解が深まったところで
/draftを実行する src/content/posts/draft/<YYYYMMDD>-<slug>.mdが生成される- 後日、本文を手で整え、カテゴリディレクトリへ移動し、
draft: falseにして公開する
当然、すべてのチャット履歴を残す必要はなく、不要なセッションは/draftを実行せず/clearして消します。
運用ルール
draft: trueをfalseにするのは必ず人間が行う- カテゴリ移動（
draft/→ai/などへ）も人間 - コマンドの指示を変えたくなったら
.claude/commands/draft.mdを編集する。Git 履歴が改善ログになる - ファイル名の slug が既存と衝突したら末尾に
-2などを付ける
コマンドファイルのサンプル
---
description: このセッションでのやり取りを、ブログのドラフトとして src/content/posts/draft/ に書き出す
---
これまでこのセッションで私（ユーザー）とやり取りしてきた内容を読み返し、私が学んだこと・理解を深めた内容を、ブログ記事のドラフトとして1ファイル保存してください。
## 大前提
- 私はこのセッションを「記事を書くため」ではなく「わからないことを聞いて理解を深めるため」に使ってきた。会話には脱線・行き詰まり・撤回も含まれる
- 記事化の対象は **会話の結果として私が腑に落ちた内容** であって、会話の議事録ではない
- カテゴリや最終的な公開可否は私が事後に判断する。コマンド側では決めない
## 保存先
`src/content/posts/draft/YYYYMMDD-<内容に合ったslug>.md`
- 日付は今日（実時間で取得）
- `slug` は英小文字＋ハイフン。内容を端的に表すものを Claude 側で命名する
- 同名ファイルがある場合は slug 末尾に `-2` などを付けて衝突回避
- ディレクトリは既に存在する前提（なければ作成）
## frontmatter（必須項目）
- `pubDatetime`: 今日の日付（ISO 8601、`YYYY-MM-DDT00:00:00.000Z` でよい）
- `title`: 記事の要旨を示す日本語タイトル
- `slug`: 上のファイル名と一致させる
- `featured: false`
- `draft: true` （**必須**。これを忘れると本番ビルドで公開されかねない）
- `tags`: 内容に合ったタグを1つだけとする
- `description`: 1〜2文の概要
カテゴリは **frontmatter に書かない**（タグでもなく、ディレクトリ構造でもなく、私が後で移動するときに決める）。
## 本文の書き方
- **想定読者は「ITのその分野の技術者」**。一般的なIT技術の用語は説明不要。前提知識を共有する読者を想定し、初心者向けの噛み砕きは入れない
- **構成の型**：基本は「背景（なぜやったか）→ 方法（何をしたか）→ 結果（どうなったか）→ 議論（注意点）」の順。テーマに応じて見出し名は調整するが、この順序を崩さない（論文の Introduction → Method → Result → Discussion のゆるい応用）
- **一人称は「私」で統一する**。「自分」は使わない
- **簡潔さ最優先**。同じ意味を言い換えない。各文・各箇条書きは1〜2行で収める。「次のとおりです」「次の点でハマりました」のような繋ぎ文は、見出しがあれば書かない
- **メタ説明（楽屋話）を増やさない**。「太字で強調します」「〜と書きます」のような「なぜこう書いたか」は、本質的な判断1〜2点に絞る。仕様や事実を淡々と書く
- **比較は具体物で**：選択肢を並べるときは、選択肢ごとにコード・設定・差分・数値といった具体物を見せる。「A は安全、B は便利」のような形容詞だけの比較は避ける。表または短い箇条書きで、文章として長く膨らませない
- **文体は「ですます調」（敬体）で統一する**。「〜だ」「〜である」「〜だろう」などの常体は使わない。コードブロック内のコメントや出力例はこの限りではない
- **このセッションで実際に話した内容だけを書く**。会話に出ていない発展案・展望・「次にやりたいこと」「応用案」「TODO」などを推測で足してはいけない。「次に試したいこと」「今後の展望」のようなセクションを勝手に作らない。会話で実際に言及した未解決事項がある場合のみ、その範囲で書いてよい
- 会話の地の文をそのまま貼らない。私が後で1人で読み返して思い出せる粒度に **再構成** する
- 会話中で私が「これは記事化しなくていい」「これは違った」と言った内容は除外する
- Web 情報・公式ドキュメントを参照した箇所は出典リンクを残す
- コードブロック・コマンド例はそのままコピペで動く形に整える
## 出力
保存し終わったら、ファイルパスだけを最後に返してください（本文の再掲は不要）。複数の独立したテーマが混ざっていた場合は、そう判断した理由を一言添えて、テーマ別に複数ファイルに分けて保存してかまいません。