Claude CodeのSlash Commands機能を使えば、セッション終了前に詳細な開発日誌を自動生成できます。
この記事では、Slash Commands /devlog を作って、開発の判断理由や試行錯誤の過程を含む詳細な開発日誌を自動生成する方法、設定ファイルのテンプレートと実際の出力例を解説します。

    なぜSlash Commandsなのか?

    いくつかの方法を検討しました:

    方式特徴採用理由
    Stop Hook毎回自動実行❌ 永久ループ問題が発生
    SessionEnd Hookセッション終了時❌ blockできない(通知のみ)
    Slash Commands手動実行✅ 必要な時だけ、確実に動作

    Stop Hookは「Claudeがレスポンス完了する直前」に毎回実行されるため、日誌作成→完了→また日誌作成...の無限ループに陥りました。

    結局、タスク完了時に手動で /devlog を実行するのが最もシンプルで確実でした。

    設定方法

    1. Slash Commandファイルを作成

    Claude Code v2.1.89以降は、カスタムコマンドの保存場所が .claude/commands/ から .claude/skills/ に変更されました。

    バージョン保存場所
    〜v2.1.88.claude/commands/devlog.md
    v2.1.89〜.claude/skills/devlog/SKILL.md

    プロジェクト共通で使うなら .claude/skills/devlog/SKILL.md、全プロジェクトで使うなら ~/.claude/skills/devlog/SKILL.md に作成します。

    ---
    description: 開発日誌を作成(コンテキスト圧縮前やTask区切りで使用)
    ---
    
    # 開発日誌の作成
    
    現在のセッションの開発日誌を作成してください。
    
    ## 出力先
    `logs/devlog/` ディレクトリに以下の形式で作成:
    - **ファイル名**: `YYYY-MM-DD_TaskX.X_機能名.md`
    - 例: `2026-01-09_Task6.5_CodeRabbit修正.md`
    
    ## テンプレート
    
    # 開発日誌 - YYYY-MM-DD HH:MM
    
    ## セッション概要
    - 📝 **作業内容**: [何を実装したか - 1行で要約]
    - ⏱️ **作業時間**: XX分(概算でOK)
    - 📊 **Context消費**: XX% → XX%(現在のContext left表示から推測)
    
    ## 実施作業の詳細
    
    ### やったこと
    - 具体的な実装内容
    - 変更したファイル・関数
    
    ### なぜこの設計にしたか
    - 判断理由を明記
    - 「〇〇という選択肢もあったが、△△の理由でこちらを採用」
    
    ### 試行錯誤した点
    - 最初に試したアプローチ
    - うまくいかなかった理由
    - 最終的な解決方法
    
    ## 重要判断・方針決定
    
    | 判断内容 | 採用した方針 | 理由 |
    |---------|------------|------|
    | 例: エラーハンドリング | try-catch方式 | 既存コードとの一貫性 |
    
    ## 💡 学びと気づき
    - 今回の実装で得た知見
    - 次回に活かせるポイント
    - 参考になったドキュメント・パターン
    
    ## 😤 感情メモ(任意だが推奨)
    - 「ここで3時間ハマって焦った...」
    - 「解決した時はスッキリ!」
    - 「この設計は我ながらうまくいった」
    
    ## 継続タスク
    - [ ] 未完了の作業項目
    - [ ] 次回確認すべきこと
    
    ## 記載のポイント
    
    1. **判断理由を必ず書く**: 後で「なぜこうしたんだっけ?」を防ぐ
    2. **試行錯誤の過程も書く**: 失敗から学ぶ情報が最も価値がある
    3. **感情も素直に書く**: 振り返り時に状況を思い出しやすくなる
    4. **ブログ記事の素材になるレベル**で書く
    
    ## 補足引数
    
    `$ARGUMENTS` が指定された場合、その内容を作業内容の補足情報として使用してください。
    
    例: `/devlog CodeRabbit指摘の修正完了` → 作業内容に反映
    

    2. ディレクトリを作成

    mkdir -p logs/devlog
    

    3. 使い方

    タスク完了時に実行するだけ:

    /devlog Task 6.5: CodeRabbit修正
    

    実際の出力例

    以下は、実際に生成された開発日誌の抜粋です(132行の詳細な記録):

    # 開発日誌 - 2026-01-09 14:32
    
    ## セッション概要
    - 📝 **作業内容**: CodeRabbit 6回目レビュー指摘事項の重要問題修正
    - ⏱️ **作業時間**: 45分(概算)
    - 📊 **Context消費**: 78% → 85%
    
    ## 実施作業の詳細
    
    ### なぜこの設計にしたか
    
    #### shallow copy修正について
    - **選択肢1**: JSON.parse(JSON.stringify()) でdeep copy
    - **選択肢2**: 既存のdeepClone() メソッド活用
    - **採用**: 選択肢2
    - **理由**: 既にstructuredClone()のフォールバック付きdeepClone()が実装済みで、統一性と保守性を重視
    
    ### 試行錯誤した点
    
    #### settings-manager.jsの修正順序
    - **最初**: validateAndMergeSettingsから修正開始
    - **気づき**: 既にdeepClone()メソッドが実装済みであることを発見
    - **効率化**: 統一的にdeepClone()を使用する方針で4箇所まとめて修正
    
    ## 重要判断・方針決定
    
    | 判断内容 | 採用した方針 | 理由 |
    |---------|------------|------|
    | shallow copy修正 | 既存deepClone()活用 | コード統一性・structuredClone対応済み |
    | ページリーク対策 | minimal change approach | 既存パターン改善で最大効果 |
    
    ## 😤 感情メモ
    
    ### ポジティブな瞬間
    - **発見の喜び**: settings-manager.jsに既にdeepClone()が実装されていた発見で「あ、これ使えばすぐ解決!」となってスッキリ
    

    従来のログとの使い分け

    開発日誌は、既存のログファイルと役割が異なります:

    ログ種別目的内容
    CHANGELOG.md進捗・変更履歴端的な実装内容
    ERRORLOG.mdエラー解決記録技術的なエラー情報
    PATTERNS.mdコードパターン集再利用可能なコード例
    devlog/*.md詳細な振り返り判断理由・試行錯誤・感情

    開発日誌にはストーリー性があるため、そのままブログ記事の素材として使えます。

    ワークフローへの組み込み

    私は以下のワークフローで運用しています:

    Task X.X.1: Explore(調査)
    Task X.X.2: Plan(計画)
    Task X.X.3: Code & Test(実装・テスト)
    Task X.X.4: Record & Commit(記録・コミット)
        ↓
      /devlog Task X.X [機能名]  ← ここで実行
        ↓
      git commit & push
    

    なぜ感情メモが重要なのか

    テンプレートに「😤 感情メモ」を入れている理由があります。

    1. 振り返り時に状況を思い出しやすい

      • 「ここで焦った」「スッキリした」という記録があると、当時の文脈が蘇る
    2. ブログ記事に臨場感が出る

      • 技術的な内容だけでなく、感情も含めると読み物として面白くなる
    3. 成長を実感できる

      • 「あの時ハマったけど、今なら簡単に解決できる」という比較ができる

    参考:Claude CodeのSlash Commandsで日報を作成するでも、感情を含めた記録の重要性が述べられています。

    Stop Hookがうまくいかなかった話

    最初はStop Hookで自動化しようとしました。

    # devlog-hook.sh
    cat << EOF
    {
      "decision": "block",
      "reason": "セッション終了前に開発日誌を作成してください..."
    }
    EOF
    

    しかし、永久ループ問題が発生:

    Claude回答完了 → Stop hook発火 → 日誌作成促す 
    → Claude日誌作成 → 完了 → Stop hook発火 → ...
    

    Stop Hookは「Claudeがレスポンス完了する直前」に毎回実行されるため、日誌を書いた後にまたHookが発火してしまいます。

    結論:開発日誌にはSlash Commandsが最適でした。

    まとめ

    Claude Codeに開発日誌を書いてもらうことで:

    • 「なぜこうしたんだっけ?」問題が解消
    • 試行錯誤の過程が記録される
    • ブログ記事の素材がそのまま手に入る
    • 後日の参考材料にすることができる

    試してみてください。

    参考リンク

    関連記事

    Claude Codeの会話ログをObsidianに自動保存する仕組みを試してみた @kentaro さんの記事「会話を自動でObsidianに記録する仕組みを作った 」を見て、Claude Codeとの会話を自動でObsidianに記録する仕組みを導入してみました。非常に便利な仕組みですが、実際に動かすまでにいくつかハマったポイントがあった...  続きを読む CodeRabbit + Claude Codeで自動修正したら、開発日誌も残そう CodeRabbit + Claude Codeで自動修正した内容を開発日誌に記録する方法を解説。環境変数化の指摘が実環境で使えなかった実例や、/devlogコマンドで修正理由を残すワークフローを紹介。後から追跡可能な開発体制を構築できます。  続きを読む