結論：blog コマンドで、実装内容が即「技術記事」になる
最近、Claude Code での開発がどんどん進化していて、その中でも「ログをどう活かすか」がめちゃくちゃ大事になってきてる
実装ゴリゴリやったのに（いや、ほとんどClaude Code やろうけどね）、いざ技術記事を書こうとすると「何やったっけ？」ってなる
そんな悩みを解決するために、「/blog」というカスタムスラッシュコマンドを作ってみた。といっても誰でも数分で作れる。マークダウンファイルにプロンプト書くだけだもん
カスタムスラッシュコマンドってさ、Claude Code で使える、オレオレコマンドなんよね
スラッシュつけて叩くと、.claude/commands/blog.md の内容を、Claude Code に指示できるわけ
ただ、この２つの作業が必要
.claude/commands/の中に md ファイルを作る- 作った md ファイルの中にプロンプトを書く
これだけ
これを使えば、実装完了後にコマンド一発で、その日や最近の技術的取り組みが記事になる。しかも Markdown 形式で、すぐ投稿可能な状態で保存される。Claude Code との相性も抜群で、自分用ログと外向け記事が一気に仕上がる。
つまり、こういうことができる
- Claude Code に自動で実装してもらう
_/docsに実装内容を自動記録してもらう- その内容をもとに、blog コマンドで記事を自動生成する
どうよ？個人開発しながら、ブログを作る。ほぼ自動
で、これ肝心なところなんだが
書いた記事を、izanami に投稿する！
izanami は、かなりSEOに強い。ワイSEO保守10年以上やってたから、その知見を詰め込んでる。リリースして数ヶ月なのにPV右肩上がり。おまけに LLMO に強い設計で作られてる
管理画面で、SEOスコア表示したり、バズるタイトルの提案をツールがやってくれる。これ無料よ？
その結果、露出が増えるのよ
あれだったら、izanami の記事の冒頭で、君のサイトやプロダクトへのリンクをつけて露出を増やせばいいと思うのよ
そういう使い方は、izanami ではOKなんよ。
izanami のポリシーは「ユーザーのプロダクトの露出を増やす」だからね
ただ、明らかにスパム目的の投稿には最大限のペナルティーを処します…
よし！想像以上に便利だったので、今回はその仕組みと活用ポイントをまとめておくね
仕組みの全体像
実行の流れ
| ステップ | 処理内容 |
|---|---|
| 1. git log の取得 | git log --since=3.days のように最近の変更履歴を収集 |
2. _docs/ の解析 | _docs/2025-06-19_Jestテスト環境構築.md のようなファイルを読み取り、文脈を抽出 |
| 3. ファイル変更の抽出 | git diff などで変更点の概要を特定 |
| 4. LLM への入力 | 上記情報を Claude に渡し、「技術記事のテンプレートに従って出力して」と依頼 |
| 5. Markdown 生成 | タイトル・概要・コード例などを含む構成で Markdown 出力 |
| 6. 保存 | _docs/blog/ 配下にファイル名形式で保存（例: 2025-06-19_Jestテスト環境の構築.md） |
どんなときに使える？
- 今日の作業を終えたあと
- 朝イチで「昨日のまとめ」を出すとき
- リリース後に、仕様変更や改善点を振り返りたいとき
つまり、毎日の記録と公開記事を兼ねた仕組みとして最適。
記事テンプレート
Markdown のテンプレートは以下のような構成
これは後で一覧化しやすいし、Claude Code に _docs/blog/*.md を全部読ませて、ナレッジベースにできるのも強い。
なぜ作ったか
毎日実装はしてるのに、アウトプットにできてないことが多かった。
でも実際、過去のコミットログとか _docs/ にある実装メモを組み合わせれば、けっこう作れることに気づいた
ただ、それを毎回手動でまとめるのは面倒だし、忘れてしまう。
だったら、「作業したあとに /blog って打つだけで、自動でまとめてくれればよくない？」って思ったのがきっかけ。
これ、Claude Code のチャットに直接入力してもいいし、VSCode のタスクにしてもいい。
Claude Code との相性が最高だった
Claude の特徴って、過去文脈の保持と論理構成力が高いところ。
だから _docs/ にちゃんと実装ログが残ってれば、「これとこれをやったから、こういう記事になりますね」って自然に構成してくれる。
たとえばこんな感じでプロンプトを投げてもいいよね
そしてちゃんと、見出し付きの整った Markdown が返ってくる。
人間が整える手間がかなり減る。
他の開発者にも応用できるポイント
この仕組み、Claude Code を使ってる人以外にも応用できる。
- Git コミット履歴＋docsフォルダ でログを管理してる人
- LLM とのプロンプト連携を自動化したい人
- ブログ投稿の自動化をしたい個人開発者
例えば以下のような応用パターンが考えられる
| 応用例 | 内容 |
|---|---|
| Notion に保存 | 出力された記事を Notion API で自動投稿 |
| GitHub Pages | _docs/blog/ をそのまま技術ブログに使う |
| Twitter連携 | /blog 実行後、自動でタイトルをポストする Zapier |
LLM時代の「アウトプット最適化」として
ここまで使ってみて思ったのは、「実装→まとめ→公開」のフローがワンアクションで済むのはめっちゃ楽。
時代よねー。去年は考えられなかった…
ここまでできるようになると、Claude Code 一強になっちゃうよね（いや、なってるかｗ）
アウトプットって、書き始めるまでが一番ハードル高いんよね。だからこの /blog コマンドがあると、精神的にもハードルが下がる。
たとえば：
- めんどくさい Markdown 構成を考えなくていい
- 「何書こうかな」から解放される
- 逆に、「これ記事にできるかも？」という意識が日常的に芽生える
自分だけの「実装 → 発信」の習慣を持てるのが、この仕組みの本当の価値だと思ってる。
終わりに
技術ブログって、書くといいことたくさんあるのに、なかなか続かない。
でも「実装したら勝手に記事になる」仕組みがあるだけで、続けるハードルが一気に下がる。
Claude Code × 実装ログ × /blog コマンド、この組み合わせは、個人開発者にとって最強のアウトプット生成機になりうる
今後は、複数ファイルをまとめたシリーズ記事生成や、定期まとめ機能も試していきたい。
