Claude Code の使い方

• 開発者：Anthropic（Claude の開発元）
• 形態：ターミナルの CLI が基本形。ほかにデスクトップアプリ・Web 版・VS Code / JetBrains 拡張
• 料金：Claude のサブスクリプション（Pro / Max）か、API 従量課金（使った分だけ払う方式）。Pro から Max 20x まで上げ切った経緯は別記事に書きました
• できること：コードの読み書き・シェル実行・テスト・git 操作・Web 検索など、開発作業ほぼ一式

「補完ツール」ではなく「作業者」です。指示を出すと、必要なファイルを自分で探して読み、方針を立て、実装して、検証結果つきで報告してきます。

npm install -g @anthropic-ai/claude-code

プロジェクトのルートで起動して、あとは日本語で話すだけです。

cd my-project
claude

初回はログイン（サブスク認証）を求められます。起動後は「このリポジトリの構成を説明して」あたりから始めると、何ができるかの感触がつかめます。

Claude Code とのやり取りは「指示を出す→エージェントがツール（ファイル編集・コマンド実行）を使って作業する→結果を報告してくる」の繰り返しです。

押さえておきたいのは権限モデルです。ファイルの書き換えや影響の大きいコマンドは、既定では実行前に許可を求めてきます。最初は全部確認しながら使い、信頼できる操作から順に許可リストへ入れていくと、確認疲れせずに安全側へ倒せます。

リポジトリ直下に CLAUDE.md を置くと、毎セッション自動で読み込まれます。ここが Claude Code 運用の本丸で、「毎回口頭で言っていた指示」をここに書いて二度と言わないのが基本方針です。

うちの CLAUDE.md に入れているものの例：

• 開発の進め方（仕様を文書で合意してから実装する・テスト先行にする条件）
• 応答のルール（日本語で・完了報告は変更点の箇条書き＋検証結果に圧縮）
• 安全の線引き（秘密情報はコミットしない・本番反映とデータ削除は事前に一言）
• コミットの作法（作者情報〔author〕を固定＝どのセッションから commit しても履歴の名義が揃い、実メールアドレスも載らない・コメントは非自明な制約のみ＝理由は後述「陳腐化したコメントを真に受ける」の穴）

コツは「命令の羅列」ではなく判断基準ごと書くことです。「テストを書け」より「計算・バリデーション・認可など壊れたら痛いロジックはテスト先行」のほうが、初見のタスクでも意図どおりに動いてくれます。

開設記録にも書いたとおり、このサイトの開発で私はコードを 1 行も書いていません。それでも破綻しないのは、確認が必ず来る操作を先に決めてあるからです。

• 必ず確認：お金が絡む操作・本番デプロイ・データ削除・外部に公開される変更
• 任せる：実装・テスト・リファクタ・デバッグ・ドキュメント更新

この線を引いた上で、日々のやり取りは「進めて」「続けて」「はい」がほとんどになります。エージェントの自走力を活かすほど、人間の仕事は「何を作るか」と「どこに確認の線を引くか」に寄っていきます。

最初に押さえておくと、後で慌てずに済むものです。

• ビルドは緑なのに本番だけ動かない：ローカルと本番の実行環境差（このサイトでは Cloudflare Workers にファイルシステムが無い等）はエージェントも踏みます。「ビルドが通る」ではなく「本番相当の環境で検証してから完了報告する」ルールにしておくと、この種の事故が減ります。
• セッションが長くなると文脈があふれる：1 セッション 1 タスクを目安に区切り、決定事項はファイル（設計メモや ADR）に書かせて次のセッションに引き継ぐのが安定します。ADR は「何を・なぜそう決めたか」を 1 件 1 枚で残す意思決定の記録で、例えばこのサイトなら「ビルドは webpack に固定する。理由は Turbopack の出力を本番用アダプタが読めないから」のような 1 枚です。理由ごと残しておくと、次のセッションの Claude が同じ検討をやり直したり、過去の決定をうっかり覆したりしにくくなります。「会話に覚えさせる」のではなく「リポジトリに書かせる」が原則です。
• 完了報告を鵜呑みにしない：「テスト緑」の報告には何のテストが何本通ったかまで言わせる、目に見える変更は自分でも一度見る。確認コストは残りますが、コードを書くコストよりずっと小さいです。この「作れるのに中身が分からない」問題を掘り下げた話はこちらに書きました。

繰り返し踏んだ穴と、実際に効いた対処です。新しい穴を踏むたびに追記します。

「できない」を最終回答にしない

Claude Code が「これは無理」と言い切っても、それがそのセッション・そのアプローチだけの限界であることがあります。

• 症状：Yahoo Finance のデータ取得について、あるとき「自宅環境への依存から抜けられない（クラウドには移せない）」と言い切られた。
• やった対処：別の AI（このときは Fable）に相談したら、OCI（クラウド）へ移す案が出てきた。その線で進めたところ、実際に移設できた。
• 効いたか：効いた。ひとつのセッションの「できない」を鵜呑みにせず、別の AI や別の角度でセカンドオピニオンを取ると道が開けることがある、と学んだ。非決定性は厄介な性質だが、裏を返せば「一度ダメでも粘る・角度を変える」価値がある。

書いていないことに勝手に反応して暴走する

• 症状：こちらが指示も入力もしていないことに Claude Code が反応して、勝手に会話を続け始めることがある。しかも、そのまま続けるほど挙動がおかしくなっていく。
• やった対処：粘らない。立て直そうとせず、そのセッションはさっさと諦めて、新しいセッションに切り替える。
• 効いたか：崩れたセッションを直すより、切り替えるほうが速い。ふだんから 1 セッション 1 タスクで短く区切っておくと、切り替えたときの取り返しも小さくて済む。

古い・スコープ外の情報に引きずられる

個人的に一番多いのがこれです。Claude Code は目の前の文脈をよく読む反面、その文脈に古い情報やスコープ外の情報が混じっていると、素直に引きずられます。私が踏んだ形は 3 つありました。

コード内の陳腐化したコメントを真に受ける

• 症状：実装はもう変わっているのに、古いコメントの説明を「今の仕様」と思い込んで動く。
• やった対処：コメントの方針そのものを見直した。挙動を説明するコメントは書かない。残すのは、コードから読み取れない非自明な制約（外部 API の制限・ライブラリの回避策・意図的な設計判断）だけ。残す場合も日付や根拠を添える。そして、触ったファイルで実装と食い違うコメントは、その場で消す。
• 効いたか：効いた。コメントの本当の読者は AI で、挙動はコードが正・意図は仕様が正。だからコメントは少ないほど、古い情報に騙される余地が減る。

アーカイブした過去の決定を「今も有効」と誤認する

• 症状：すでに廃止・アーカイブした設計記録を、Claude が今の方針として持ち出してくる。
• やった対処：最初はルールの書き方の問題かと思ったが、ルール自体は作り込んであり、しかもこの症状は途中から出はじめた。そこで疑ったのは、読み込む文脈の量。設計記録も教訓も加算していくだけで、それぞれ 100 本を超えていた。全体を棚卸しして、もう関係なくなったものを整理し、ドキュメントを圧縮した。
• 効いたか：効いた。整理してからは今のところ再発していない。あわせて、ドキュメントの肥大化を定期的に検知する仕組みを入れて、また増えたら気づけるようにしている。

あるプロジェクトのルールを、別プロジェクトに持ち出す

• 症状：あるプロジェクト固有のローカルルールを、関係のない別プロジェクトに適用してくる。
• やった対処：原因を追ったら、Claude 側の勘違いではなかった。ドキュメントを整理していたとき、プロジェクト固有のルールが、全体共通のはずの CLAUDE.md に紛れ込んでいた。全体ルールとして書いてあるものを全体に適用していただけで、正しく振る舞っていた。置き場所を直したら止まった。
• 効いたか：効いた。ルールが効きすぎるときは、エージェントを疑う前に「そのルール、どこに書いてあるか」を見に行くほうが早い。

• Claude Code とこのサイトを 1 日で作った話 — 実際の開発の様子
• Claude Code 公式ドキュメント — インストール・設定の一次情報