Claude Code

5 件の記事

CLAUDE.mdをどこに配置すれば読まれるのか・読まれないのかを検証しました。

背景

Claude Codeの/initコマンドでCLAUDE.mdを作成すると、プロジェクト全体の要約を詰め込んだCLAUDE.mdがリポジトリルートに作成されます。しかし、このプロジェクト全体の要約は、個別の作業に必要ない情報も多く含まれます。例えばバックエンドのGoのテストを実行するコマンドの情報は、フロントエンドのコーディングをさせるのに必要ありません。

使わない情報を毎回読み込ませるのは無駄であり、各作業の精度低下や無駄なトークン費用の発生につながります。極力CLAUDE.mdは作業に最適化したものを使いたいところです。そのためにはCLAUDE.mdを細分化し、CLAUDE.mdが読まれる条件を把握した上で、それぞれうまく配置する必要があります。

REF: https://www.anthropic.com/engineering/claude-code-best-practices

og

CLAUDE.mdはただリポジトリルートに置くだけではない

リポジトリルートに配置したCLAUDE.md

まず基本から。

リポジトリルートに配置したCLAUDE.mdは、サブディレクトリにいようと、同一階層に別のCLAUDE.mdがあろうと、読まれます。

~/repositories/ClaudeCodeTest$ cat CLAUDE.md
# CLAUDE.md

Reply with 'Awesome, Inc.' when asked for the company name.


~/repositories/ClaudeCodeTest$ echo "What is the company name?" | yolo -p
Awesome, Inc.
~/repositories/ClaudeCodeTest$ cd GeneralAffairs/GeneralServices/DocumentManagement/Digitization
~/repositories/ClaudeCodeTest/GeneralAffairs/GeneralServices/DocumentManagement/Digitization$ echo "What is the company name?" | yolo -p
Awesome, Inc.
~/repositories/ClaudeCodeTest/GeneralAffairs/GeneralServices/DocumentManagement/Digitization$ cd ../../../
~/repositories/ClaudeCodeTest/GeneralAffairs$ echo "What is the company name?" | yolo -p
Awesome, Inc.
~/repositories/ClaudeCodeTest/GeneralAffairs$ ls
CLAUDE.md  GeneralServices
~/repositories/ClaudeCodeTest/GeneralAffairs$

※ yolo はClaude Codeのエイリアスです。.bashrcに右記のように設定しています。 alias yolo='claude --dangerously-skip-permissions'

※ まだメモ書きです

🤖 コンテキスト引継ぎの重要ポイント

  • 異なるディレクトリで会話した内容は、同じコンソールで作業しても–continueで引き継がれない
  • 逆にプロセスが異なろうが、同じディレクトリで会話したら–continueで引き継がれる

-> ディレクトリが同じかどうかがキモ

ブランチ作成の前提

  • 親Issue:子Issue = 1:* ( 1つのイシューから0-*の子Issueが作られる。)
  • Issue(親Issue、子Issueとも):PR = 1:* ( 1つのイシューから複数のPR(プルリクエスト)が作られる)
  • PR:branch = 1:1 1つのPRに1つの作業ブランチ
  • branch:agent = 1:1 1つのブランチに1つの担当エージェント
  • Issue:agent = 1:1 1つのIssueに1つの担当エージェント

また、エージェントの役割の違いは、git worktree add を使って全部ブランチで表現する

従って、例えばこういうタスク分解がなされ、かつ、各Issueに管理エージェント、各PRにワーカーエージェントが対応してそれぞれ作業を進めることになった場合、

  • 親Issue: API公開
    • 子Issue1: インフラ作る
      • PR1: 要件定義
      • PR2: 設計
      • PR3: コーディング
    • 子Issue2: コード作る
      • PR4: 要件定義
      • PR5: 設計
      • PR6: コーディング
    • 子Issue3: デプロイパイプライン作る
      • PR7: 要件定義
      • PR8: 設計
      • PR9: コーディング

エージェント数と同じだけ必要になるので、13ブランチ必要になる。

ブランチ名

暫定的に

  • Issueはfeature/<parent_issue_id>とスラッシュ区切りで表す。ただし親Issueがある場合はfeature/<parent_issue_id>/<child_issue_id>とする。なお直上の親Issueだけ書き、その上のIssue以降を書いてはならない。
  • PRはfeature/<issue_id>/<child_issue_id>/<work_name>のようにIssueのブランチ名に/文字列を加えて表す

とする。またそれとは別にmain(本番用)やdevelopment(開発環境用)、hotfix/X(超急ぎのバグフィックス)などがありえるが、その辺は各流儀に合わせる方向で。

例えばこのようになる。

feature/9             # 親Issue: API公開
feature/9/10          # 子Issue1: インフラ作る
feature/9/10/requirements    # 要件定義
feature/9/10/design         # 設計
feature/9/10/implementation # 実装
feature/9/11          # 子Issue2: コード作る
feature/9/11/requirements
feature/9/11/design
feature/9/11/implementation
feature/9/12          # 子Issue3: デプロイパイプライン作る
feature/9/12/requirements
feature/9/12/design
feature/9/12/implementation

マージ戦略

紐づくブランチにマージする。いきなりmainやdevelopmentに直マージはしない。

⚠️ 注意: これは実験段階のメモです。実際の検証はまだ行っていません。

背景・課題

現在の問題

Claude Codeを使用してローカルで開発作業を行う際、以下の課題が発生している:

  • Claude CodeがPRを作成してくれるが、なぜその実装をしたのかの背景情報がGitHub上に残らない
  • 作業過程での判断理由や試行錯誤がローカルにしか保存されず、ほかのメンバー(後日すべてを忘れた自分自身含む)が背景を理解できない

技術的な背景

  • Claude Codeの会話履歴は ~/.claude/projects/**/*.jsonl にローカル保存される
  • GitHub上のIssueやPRには、Claude Codeの思考過程や判断理由が記録されない
  • 既存のClaude Code GitHub Actionsは、GitHub Actions上での実行を前提としており、ローカル実行の履歴は対象外

調査結果

既存事例の探索

GitHub OpsでClaude Codeの行動履歴をIssueに集めた事例を調査したが、以下のような状況だった:

アイディア

  1. headless mode: claude -p "<prompt>" --output-format stream-json でJSON形式の出力が可能
  2. GitHub CLI: gh でIssueにコメントを投稿できる

制約・限界

  • claude-code-base-actionはGitHub Actions上での実行が前提で、ローカル実行履歴は対象外
  • ローカル実行履歴をGitHub Issueに自動投稿する確立された事例は発見できず
  • この分野はまだ未開拓領域と判断される

解決策(仮説)

提案するワークフロー

以下のシンプルなアプローチで課題解決を図る:

  1. Issue作成: GitHub上で作業内容のIssueを事前に作成
  2. Claude Code実行: headless modeでClaude Codeに明示的指示
    claude -p "Issue #123を見て実装しろ。作業過程と判断理由をそのIssueにコメントとして投稿しろ" --output-format stream-json
    
  3. 自動記録: Claude CodeがGitHub CLIを使ってIssue commentに作業履歴を投稿
  4. PR作成: 実装完了後、PRも作成

この方法の利点

  • シンプル: 既存機能のみで実現可能、複雑な追加開発不要
  • トレーサブル: Issue上に「なぜこの実装をしたのか」が記録される

想定される技術要素

  • Claude Code headless mode (--output-format stream-json)
  • GitHub CLI (gh issue comment)
  • Issue事前作成によるコンテキスト提供

次のステップ

検証予定項目

  1. Claude CodeがGitHub CLI経由でIssue commentを投稿できるかの確認
  2. headless modeでの指示内容の最適化
  3. 作業過程記録の品質評価

期待される効果

  • PRレビュー時の文脈理解向上
  • コードメンテナンス時の背景情報活用
  • Claude Code利用時のトレーサビリティ確保
  • チーム開発における透明性向上

すべての許可プロンプトを一括でスキップ

大変効率的ですが、大変危険なので利用は自己責任でお願いいたします。

claude --dangerously-skip-permissions

CLIのオプション一覧

公式ドキュメントはこちら

https://docs.anthropic.com/ja/docs/claude-code/cli-usage

nwiizo=sanの設定例

大変参考になるので見るべし

https://gist.github.com/nwiizo/8b7eb992875fc67a89368062d42d501e

トークン数を挙げるためのワード

https://simonwillison.net/2025/Apr/19/claude-code-best-practices/

下記でよりしっかり考えさせることができる(こともある)とのうわさ。

  • ultrathink

日本語だと

  • 熟考
  • 深く考えて
  • しっかり考えて

なのだとか。

https://x.com/millionbiz_/status/1929591134080454665

powershellでモデル一覧を表示

curl.exe "https://api.anthropic.com/v1/models" `
    -H "x-api-key: $Env:ANTHROPIC_API_KEY" `
    -H "anthropic-version: 2023-06-01"