目次
Claude Code
Anthropic社のコーディングAIエージェント
ヘッドレスモード
対話モードを起動せずにワンショットの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という環境変数がセットされている。これを見て遅延ロードしないように分岐すると良い
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: 重要な指示が埋もれる
- 検証なしの信頼: 検証できないものは出荷しない
- スコープなき調査: コンテキストが膨大なファイル読み込みで消費される