Cat Paw Software

この文書は読取専用です。文書のソースを閲覧することは可能ですが、変更はできません。もし変更したい場合は管理者に連絡してください。
<markdown>
# Claude Code

Anthropic社のコーディングAIエージェント

- [Claude Code by Anthropic | AI Coding Agent, Terminal, IDE(claude.com)](https://claude.com/product/claude-code)
- [Claude Code overview - Claude Code Docs(code.claude.com)](https://code.claude.com/docs/)

## 設定ファイル

設定ファイルは３種類

- グローバルスコープ: `~/.claude/settings.json`
- プロジェクトスコープ: `.claude/settings.json`
- ローカルスコープ: `.claude/settings.local.json`

下のスコープほど優先度が高い。

- グローバルスコープ: どこで起動しても有効になる個人設定
- プロジェクトスコープ: プロジェクトで共有する設定、[VCS](/vcs)にコミットして管理する想定
- ローカルスコープ: プロジェクトにおけるユーザの固有設定、バージョン管理から除外する想定

## CLAUDE.md

セッション開始時に読み込まれるプロンプト。セッション開始時に進みコンテキストが増えるほど影響が小さくなっていく。このため常に守って欲しいルール、例えば「コード修正したらテストを実行すること」といったルールを書くべきではない。（このようなルールはhookを使うといい）

CLAUDE.mdには、セッション開始時に「このプロジェクトは何？」といった作業の取り掛かりになる情報を与えるのが良い。


## ヘッドレスモード

対話モードを起動せずにワンショットのCLIツールとして起動するモード

```
cat error.log | claude -p 'このエラーの原因を簡潔に説明してください'
```

プロンプトは次のようになる。この時カレントディレクトリのCLAUDE.mdも参照される

```
<error.logの内容>
このエラーの原因を簡潔に説明してください
```

## Claude Codeが実行するシェル環境

（このセクションはv2.1.45時点での情報です）

claude codeはコマンドをbashまたはzshで実行する。この時の環境はログインシェルかつ非インタラクティブシェルである。つまりzshであれば`,zprofile`は読み込まれるが`.zshrc`は読み込まれないはずである。しかしclaude codeは`,zshrc`で定義している関数や環境変数を使うことができる。

これはshell-snapshotという仕組みで実現されている。詳細は不明だがおそらく.zshrcの内容を先に実行して、その結果作成されるシェル関数、シェルオプション、コマンドエイリアス、PATH環境変数を~/.claude/shell-snapshots以下に書き出し、コマンド実行のたびにsourceして読み込んでいるものと推測される。

この仕組みのためか、コマンドの遅延ロードのようなギミックを仕込んでいるとコマンドが正常に動かないことがある。shell-snapshotを作成するときは`CLAUDECODE`という環境変数がセットされている。これを見て遅延ロードしないように分岐すると良い

```bash
if command -v rbenv >/dev/null 2>&1; then
  if [[ $CLAUDECODE == 1 ]]; then
    # claude codeはrbenvを即時ロードする
    eval "$(command rbenv init -)"
  else
    # 人間はrbenvを遅延ロードする
    _rbenv_lazy_init() {
      unfunction _rbenv_lazy_init rbenv ruby bundle gem rake rails irb 2>/dev/null
      eval "$(command rbenv init -)"
    }
    for cmd in rbenv ruby bundle gem rake rails irb; do
      eval "${cmd}() { _rbenv_lazy_init; ${cmd} \"\$@\" }"
    done
  fi
fi

```


## AIの使い方の方針

以下は2026年初頭時点で推奨される方針である。LLM自身もLLMの利用方法も発展途上であり、以下の方針もあくまで現時点での出発点に過ぎない。何がうまくいき、何が失敗したかを観察してアップデートしていくことが重要。

### 0. コンテキストウィンドウ

コンテキストウィンドウはすぐに埋まり、埋まるほど性能が低下することを意識する。会話履歴、読み込んだファイル、コマンド出力がすべて蓄積されるため、このリソース管理は重要になる。

### 1. 検証手段を与える

Claudeが自分の作業を検証できると劇的に性能が向上します。テスト、スクリーンショット、期待される出力を提示し、Claude自身にチェックさせるのは効果の高い施策である。

### 2. 探索→計画→実装の順序

いきなりコーディングに入らず、Plan Modeで調査・計画を行ってから実装に移ることで間違った問題を解くリスクを減らす。ただし、単純な変更には不要なオーバーヘッドになる場合もある。

Plan Modeが有効であるのは次の「具体的な指示」が作られることによる

### 3. 具体的な指示を出す

曖昧な指示より、対象ファイル・制約・参照すべきパターンを明示する。LLMはAという表現を別のBという表現に変換する関数のようなものであり、出力の品質は入力の質が反映されたものになる。曖昧な指示による入力には相応の低品質なコードが出力されると熟知せよ。

### 4. 複数セッションで並列化

独立したタスクは別セッションで並行処理する。「書く人」と「レビューする人」を分けるパターンは非常に有効。ただし日常的な用途ではオーバースペックになることもある。


## 避けるべきアンチパターン

- 無関係なタスクの混在: /clearで区切る
- 繰り返しの修正: 2回失敗したら最初からやり直す
  - 失敗すると失敗した状態をコンテキストにしてしまう。これは性能を大幅に劣化させる原因となる
- 長すぎるCLAUDE.md: 重要な指示が埋もれる
- 検証なしの信頼: 検証できないものは出荷しない
- スコープなき調査: コンテキストが膨大なファイル読み込みで消費される

</markdown>