#claude-code-getting-started

最初のつまずきはだいたい決まっている。Claude Code を「入れたのに動かない」と言いながら、実は入れ方と起動場所を外しているだけだ。ここを雑に済ませると、最初の 10 分で気持ちが折れる。逆に言えば、そこさえ通せばあとはかなり素直に使える。 Claude Code 入門とか Claude Code 使い方を探しているなら、まずは「何ができるか」を盛る前に、起動して最初の依頼を通すところまでを一気にやるのがいい。コードを書く人だけの道具に見えるが、実際はファイル整理、文書の下書き、散らかったディレクトリの棚卸しにも使える。最初に必要なのは、派手な設定ではなく、ちゃんとした足場だ。 Claude Code は、チャット画面を開いて雑談するものではない。ターミナル、つまり黒い画面から呼び出して、ローカルのファイルや作業ディレクトリを相手にする CLI ツールだ。ここを勘違いすると、いつまでたっても「どこで使うのか」が見えない。 なので最初にやることは単純だ。自分のPCで端末を開き、Claude Code を入れて、作業したいフォルダの中で起動する。それだけでよい。 逆に、ホーム画面や

それ、なんでも丸投げできる道具だと思っているなら最初に一度つまずく。Claude Code は万能ロボットではなく、手元のファイルを読ませて、編集させて、確認させるのが得意な CLI エージェントだ。だからこそ強い。逆に、曖昧な気分相談や、外部の事実確認を雑に任せると、平気で手戻りする。 ここで大事なのは、「何を頼めるか」を機能名で覚えることではない。何を渡すと速いか、何を渡すと危ないかを線引きすることだ。これがわかると、コード修正だけでなく、書類整理、不要ファイルの洗い出し、文章のたたき台作りまで、かなり現実的に使えるようになる。 Claude Code が強いのは、すでにあるファイルやディレクトリを読んで、そこから作業を進める場面である。たとえば、こんな依頼は相性がいい。 ```text このディレクトリ配下を見て、README を実態に合わせて直して。 古い手順、存在しないファイル名、曖昧な説明を消してほしい。 変更前に、どこをどう直すつもりか要約してから進めて。 ``` これはコードでも文書でも同じだ。実在するファイルを読ませて、そこから整える。Claude C

最初にやるべきことを飛ばして、いきなりClaude Codeに「これ直して」と投げる人は多い。で、あとからコンテキストが足りない、差分が広がりすぎる、同じ説明を何度も繰り返す、となって手戻りする。もったいない。 Claude Codeは、ただ起動して雑に命令する道具ではない。最初にプロジェクトの輪郭を整えると、以後のやり取りがかなり軽くなる。ここでやるべき設定は、細かい小技ではない。`CLAUDE.md` を置くこと、作業対象をきちんと閉じること、そして危ない自動実行を避けることだ。この3つを先に固めるだけで、迷走がかなり減る。 Claude Codeは、毎回ゼロから空気を読むわけではない。プロジェクトのルール、よく使うコマンド、触ってはいけない場所を先に書いておくほうが強い。これが `CLAUDE.md` だ。リポジトリのルートに置くのが基本になる。 たとえば開発案件なら、こんな内容で十分だ。 ```markdown このプロジェクトでは次のルールに従う。 既存のコードスタイルに合わせる 変更は必要最小限にする 依存関係の追加は事前確認する テストは `npm test` で実行する

コンテキスト管理を雑にすると、Claude Code はすぐ「前の話」を背負い込んで重くなる。これを放置してから「なんか話がズレるな」と首をひねるのは、だいたい手遅れだ。`/clear` は失敗の後始末ではなく、作業を切り替えるための道具として使う。 Claude Code のセッションは、ひとつの長話にしすぎるとだるい。依頼の文脈が積み上がり、関係ない前提まで抱えたまま応答する。コード修正でも文書作成でも同じで、「今やっている仕事」と「さっきまでの仕事」が混ざった瞬間に精度が落ちる。だから、`/clear` は気分転換ではなく、仕事の区切りを明示するために入れる。 まず感覚だけ先に言う。次のどれかに当てはまるなら、ほぼ ` /clear` でいい。 一つ目は、作業の目的が変わったときだ。たとえば、最初はバグ修正を頼んでいたのに、途中から仕様の相談に変わる。あるいは、ファイル整理をしていたのに、急に文案の推敲を始める。これは同じ仕事ではない。前の前提を持ち越すメリットがないので、切ったほうが早い。 二つ目は、別のディレクトリ、別の案件、別の対象に移るときだ。Claude Code は作

その長いファイル、わざわざ貼らなくていい。むしろ貼るな、である。 Claude Code に仕事をさせるときは、内容を全部コピーして投げるより、「どのファイルの、どこを、どう見ればいいか」を指示したほうが速いし、手戻りも少ない。コンテキストを無駄食いしないので、あとから本題の会話が崩れにくい。ファイル整理でも、仕様確認でも、議事録からの文書作成でも、この差は地味に効く。 筆者は最初、雑に本文を貼り付けていた。で、すぐ詰まった。長文のせいで肝心の指示が薄まり、返ってくる答えも広く浅い。しかも、途中で「この表だけ見れば足りたのに」と気づく。あれは本当にだるい。Claude Code は「探させる」ほうが強い。 やり方は単純だ。最初から全文を渡さず、ファイル名、場所、探してほしい観点をセットで渡す。たとえば、こんな感じだ。 ```text プロジェクト内の仕様書を見て、 「ログイン失敗時のエラーメッセージ」がどこで定義されているか探して。 関連するファイル名と該当箇所を挙げて、要点だけ説明して。 全文の要約は不要。 ``` もう少し実務っぽくすると、こうなる。 ```text /Users/

「全部おまかせ」で回すと、だいたいどこかで余計なものまで触る。Claude Code の権限モードは、その事故をどこで止めるかを決める仕組みだ。ここを雑に扱うと、ファイル整理のつもりが思わぬ上書きになったり、コード修正のつもりが確認なしで広範囲の変更に進んだりする。 権限モードで見るべき本質は単純だ。Claude Code に何を自動で許し、何を必ず止めるかを先に決めることだ。自動承認は便利だが、便利さの裏には「止めどころを失う」危険がある。特に、削除・移動・上書き・外部コマンド実行のあたりは、最初から雑に広く許可しないほうがいい。 Claude Code には、作業を進める前に都度確認を挟むか、ある程度まとめて承認するか、といった権限の扱いがある。呼び方や細かな表示は環境で違うことがあるが、考え方は同じだ。普段の編集は流し、壊れやすい操作だけ人間が止める。これが基本線になる。 たとえば、文章作成やファイル整理で使うなら、こう考えるといい。下書き作成やリネーム案の提示はかなり自由に任せる。だが、実際の移動・削除・上書きは一段慎重にする。開発でも同じで、コードの提案や差分

いきなり実行させてから「違う、そうじゃない」と止めるのは、だいたい一番高くつく。Claude Code のプランモードは、その手戻りを先に潰すための道具だ。作業を走らせる前に、方針・手順・危ない点を一回紙に出させる。これを挟むだけで、コンテキストの無駄食いも、雑な一括変更も、かなり減る。 プランモードは「何をするか」を先に固めるために使う。実行そのものを急がない。ここを逆にすると、便利な機能がただの遠回りになる。筆者も最初は、いきなり修正を走らせて、あとから「その前に依存関係を整理してほしかった」と気づいてやり直した。差分が肥大化すると、どこから崩れたのか追うのがだるい。だから先に方針確認だ。 使い方は単純で、最初に「変更はまだしないで、計画だけ出して」と頼む。たとえばコード修正なら、こんなふうに始める。 ```text この作業はまだ実行しないでください。 まず方針を確認したいです。 目的: 既存のログ出力を整理したい ただし振る舞いは変えすぎたくない やってほしいこと: 1. 関係するファイルを洗い出す 2. 変更方針を3案くらい出す 3. それぞれのメリット・リスクを書く 4.

大きな作業を一気に投げると、だいたいロクなことにならない。Claude Code でも同じで、広い範囲をまとめて触らせるほど、意図しない変更が混ざるし、あとから差分を読むのも地獄になる。 ここでやるべきなのは、仕事を小さく切ることだ。Claude Code に「全部やって」で渡すのではなく、変更の境界を先に決める。そうすると、差分が読みやすくなるだけではない。途中で止めて確認しやすいし、手戻りしても被害が小さい。ファイル整理でも、文章修正でも、コード修正でも、この考え方が効く。 筆者は最初、ひとまとまりの依頼をそのまま投げて、関係ないファイルまで巻き込まれたことがある。修正点そのものは合っているのに、差分が太りすぎてレビューで疲れるやつだ。あれはかなりだるい。以後は「どこまでやるか」を先に決めてから頼むようにしている。 差分を小さくするコツは、作業を結果で分けるのではなく、工程で分けることだ。 たとえば、ひとつの大きな改修があったとする。いきなり完成版を作らせるより、こう分ける。 1. 既存の構成を確認する 2. 変更対象を絞る 3. 最小の修正を入れる 4. 差分を見て、余計な変更を

Claude Code が変な方向に進んだとき、いちばん危ないのは「少し直せば戻るだろう」と粘ることだ。そこから先は、直すための指示がさらに増えて、コンテキストも汚れて、結局もっと面倒になる。 この手の CLI コーディングエージェントは、雑に言えば「今ある作業状態」を読んで次を決める。だから、間違えたときは作業を抱えたまま修正会議を続けるより、いったん捨てて、まっさらな状態でやり直したほうが早い場面が多い。 筆者も最初はこれで何度かやらかした。小さな修正のつもりで指示を重ねたら、diff が妙に広がって、元の意図から外れた変更まで混ざる。あとから人間が見て「これはどこから来た？」となるやつだ。 なのでこの話では、Claude Code が迷走したときに何を捨て、何を残し、どうやって再出発するかを、実務寄りに整理する。 まず押さえるべきなのは、戻し方は1つではないという点だ。 すでにファイルを書き換えたあとなら Git で戻す。まだファイルを触っていないなら、セッションを切って、依頼文を作り直す。途中までの成果に価値がないなら、未練なく捨てる。ここを曖昧にすると、いつまでも半端な状態が

「ターミナルは怖いから触らない」は、Claude Code を使うときだけはかなり損だ。 ただし、だからといって黒い画面の達人になる必要はない。覚えるのは本当に少しでいい。`cd` で場所を変える、`claude` を起動する、終わるときは `exit`。まずはこれだけで回る。 Claude Code は Anthropic の CLI コーディングエージェントだが、名前に反してエンジニア専用ではない。フォルダの中身を整理したい、散らかった文書をまとめたい、不要ファイルを減らしたい。そういう用途でもかなり使える。大事なのは、ターミナルを「操作する」ことではなく、Claude Code に「そのフォルダで何をしてほしいか」を短く伝えることだ。 最初にやることは単純だ。作業したいフォルダに移動して、Claude Code を起動する。 ```bash cd ~/Documents/案件A claude ``` ここで `cd` は「そのフォルダに入る」コマンド、`claude` は Claude Code を立ち上げるコマンドだ。フォルダ名のところは自分の環境に合わせればいい。たとえば書類

Claude Code は、ターミナルの玄人向けツールに見えて、実際は「最小限だけ覚えて雑に使う」ほうが向いている。ここを勘違いして、最初から bash を全部理解しようとして止まる人が多い。そんな気合はいらない。必要なのは、起動する、依頼を書く、承認する、終わる。この4つだけだ。 しかもこれは開発者だけの話ではない。フォルダの中身を整理したい、散らかった文書を直したい、同じ内容のファイルをまとめたい、ディスクを空けたい、そういう用途でもかなり使える。大事なのは「Claude Code に何をしてほしいか」を、短く具体的に伝えることだ。ターミナル操作そのものは、ほぼ付け足しでいい。 まず、最低限の入り口だけ押さえる。インストール方法は公式案内に従うのが安全だが、使い方の芯は単純だ。作業したいフォルダに移動して、Claude Code を起動する。だいたいの流れはこうなる。 ```bash cd /path/to/your/project claude ``` ここで `claude` を実行すると、対話モードに入る。あとは普通の会話と同じように、やってほしいことを書けばいい。たとえば文

やりがちなのは、Claude Code が変な方向に進んだのに、そのまま修正させ続けることだ。これ、たいてい泥沼になる。少し直したつもりが別のファイルまで触られ、diff が膨らみ、どこから壊れたのか分からなくなる。そんなときは、粘るより一度捨てたほうが早い。 Claude Code は CLI の作業エージェントなので、手元のファイルを実際に書き換える。つまり、間違えたときに大事なのは「どう直すか」より「どこまでを無かったことにするか」だ。ここを間違えると、コンテキストも時間も無駄に食う。筆者も最初は、ズレた指示のまま会話を続けて手戻りした。結局、途中成果を捨ててやり直したほうが速かった、という場面がかなり多い。 いちばん手堅いのは、まず差分を確認して、必要なら作業ツリーをそのまま戻すことだ。Git を使っているなら話は早い。Claude Code に触らせる前にコミットしておけば、戻す先がはっきりする。これだけで事故率がかなり下がる。 ```bash git status git diff git restore . ``` `git restore .` は、未コミットの

一気に全部やろうとすると、だいたい雑になる。Claude Code でも同じで、でかい変更をひと塊で投げると、途中で文脈があふれて、直したい箇所まで巻き込んで壊しやすい。差分を小さく保つコツは、気合いではなく区切り方だ。 Claude Code は、ローカルのファイルを読んで、変更案を返して、そのまま編集まで進められる。だからこそ、最初の依頼文で「何を1回分の仕事にするか」をはっきり切るだけで、手戻りがかなり減る。開発でも文書整理でもファイル整理でも効く。むしろ非エンジニアほど、この区切りが効く。 たとえば、フォルダ整理で「重複っぽい書類を見つけて、年別に分けて、ファイル名も整えて、不要キャッシュも消して」と全部まとめて頼むと、途中で迷う。先にやるべきなのは、検出だけなのか、移動までなのか、削除までなのかを分けることだ。Claude Code に任せる単位を小さくすると、確認もしやすいし、戻すのも楽になる。 まずは、頼み方を「調べる」「提案する」「実行する」に分ける。これだけで事故率が下がる。 ```bash Claude Code に以下を依頼する: 「このフォルダ内で重複していそう

勢いで走らせると、だいたいあとで直す羽目になる。Claude Code でもそこは同じで、いきなり実行させるより、先に方針だけ確認させたほうがずっと事故が少ない。 プランモードは、作業を始める前に「何をどう進めるつもりか」を先に出させる使い方だ。コード修正でも、フォルダ整理でも、文章のたたき台作りでも効く。しかも、単に相談するだけではなく、こちらが許可した筋道で進ませやすい。やる前に地図を見せる、という感覚に近い。 筆者は最初、普通に「これ直して」「これ整理して」とだけ投げていた。すると、意図は合っていても手順が遠回りだったり、無関係なファイルまで触りそうになったりする。小さな修正ならまだいいが、ディレクトリ全体をまたぐ整理や、文章ファイルの一括整形になると、確認なしで走らせるのはけっこう怖い。そこで先に方針を出させると、手戻りが目に見えて減る。 Claude Code でこれをやるコツは、最初の依頼で「実行」ではなく「計画」を求めることだ。たとえば次のように頼む。 ```text この作業を始める前に、方針だけ先に出してください。 目的、変更対象、進める順番、危ない点、確認したい点を

「自動承認にしておけば全部ラク」みたいな雑な使い方をすると、だいたいどこかで痛い目を見る。Claude Code は便利だが、便利さの芯にあるのは“どこまで勝手にやってよいか”の線引きだ。ここを曖昧にしたまま走らせると、ファイルを思った以上に触られたり、確認待ちで手が止まったりする。 権限モードを理解する意味は単純で、Claude Code に任せる作業と、人間が止める作業を分けることにある。ファイル整理でも、文章作成でも、コード修正でも同じだ。雑に広く許すより、最初に少しだけ考えておいたほうが、後でやり直しが減る。 まず押さえるべきなのは、Claude Code は「提案だけする」道具ではない、という点だ。ターミナル上で実際にコマンドを走らせ、ファイルを読むだけでなく、書き換えもする。だから権限モードは、AI の賢さとは別に、実行の自由度を調整するための装置だと思っておけばいい。 ざっくり言うと、考え方はこうなる。 何も考えずに広く許可する 危ない操作だけ確認を挟む ほぼ毎回止めて、人間が承認する この三段階をどう使い分けるかが本題だ。Claude Code には、自動承認の強さを変

「このファイル全部読んで」。その頼み方、だいたい雑だ。Claude Code に丸ごと貼る前に、まず探させればいい。これだけでコンテキストの無駄食いが減るし、長い設定ファイルや複数の文書を相手にするときの手戻りもかなり減る。 Claude Code は、ただ貼られた文章を読むだけの道具ではない。リポジトリや作業ディレクトリの中を見て、該当箇所を探して、必要な部分だけを扱うほうがずっと向いている。特に、設定ファイル、議事録、契約書の下書き、案件フォルダのように「どこに何があるか分かっていないが、探せば見つかる」場面で効く。 最初にやるべきは、いきなり本文を貼ることではなく、「探す条件」を先に渡すことだ。たとえばこう書く。 ```text このリポジトリの中から、APIキーの設定に関係する箇所を探して。 ファイル名、該当行、周辺の文脈を短く抜き出して、何を直せばよいか説明して。 全文の貼り付けは不要。見つかった部分だけで十分。 ``` これで十分なことが多い。要するに、Claude Code に「答えそのもの」ではなく「答えを見つける作業」をやらせるわけだ。人間でも、まず検索して、見つかっ

長く雑に話し続けるほど賢くなる、なんて思っていると痛い目を見る。Claude Code は会話の文脈をちゃんと使うが、使い続ければ使い続けるほど、今やっている作業に不要な前提まで抱え込む。これがコンテキスト管理の話だ。 `/clear` は「会話を捨てるためのボタン」ではない。作業の単位を切り替えるための道具である。ここを外すと、指示はだんだん鈍るし、差分はでかくなるし、直したい場所と違う場所を触り始める。筆者は最初、便利だからと同じセッションを延々引っ張って、最後には「その話、もう前の前提だよね」とこちらが補足し直す羽目になった。あれはだるい。 `/clear` を入れるべきタイミングは、だいたい次の三つだ。 ひとつ目は、話題が変わったとき。たとえば「このディレクトリを整理してほしい」の次に「別の案件の資料を要約してほしい」を続けるなら、同じ会話に載せないほうがいい。 ふたつ目は、ひとつの作業が終わったとき。実装、修正、整理、要約。完了したら一度切る。 みっつ目は、返答が妙に回りくどくなったときだ。前の指示や途中経過を引きずって、同じ説明を繰り返し始めたら、会話が長すぎるサインである

最初に何も決めずに Claude Code を走らせると、だいたい雑に広がる。コンテキストは無駄に食うし、差分はでかくなるし、あとで「それじゃない」を言い直す羽目になる。あれは地味にだるい。 プロジェクトを開いたら、まずやるべき設定は3つだけだ。 「作業範囲を固定する」「出力の粒度を揃える」「触ってほしくないものを先に塞ぐ」。この3つを最初に入れておくと、Claude Code が勝手に遠回りしにくくなる。非エンジニアでも同じで、たとえば書類整理やフォルダ整備を頼むときほど効く。何を見て、何を見ないかが曖昧だと、ツールはすぐ迷子になる。 Claude Code は、プロジェクト内の指示を置いておくとそれを読みやすい。ここでやるべきなのは、毎回口頭で説明していた前提を `CLAUDE.md` に逃がすことだ。 コードベースなら「どのディレクトリを主に触るか」「テストの走らせ方」「命名の癖」。文書作成なら「書式」「表記ゆれの方針」「触ってはいけない原本」。この手の話は、毎回チャットで打つには細かすぎるし、打ち忘れやすい。 たとえば、こんな感じで置く。 ```md 変更は最小限にする 既存の

Claude Code に何でも押しつけると、だいたい最後にしわ寄せが来る。雑に投げると、長い説明を読ませたわりに成果物が中途半端、しかも人間が後で直す羽目になる。そこを先に切り分けておくと、Claude Code はかなり使える道具になる。 Claude Code は、Anthropic の CLI コーディングエージェントだが、ここでの本質は「端末から指示して、作業をまとめて任せる相手」だという点にある。コードを書かせるだけの道具ではない。ファイルを探す、差分をまとめる、文書を整える、不要なものを洗い出す、そんな地味だが面倒な仕事に向いている。 逆に、曖昧な判断、最後の責任が重い決定、見通しの甘い大工事は苦手だ。ここを間違えると、コンテキストを無駄食いし、diff が膨らみ、手戻りが増える。筆者も最初は「全部まとめてやって」と投げて、あとで細部を直すほうが面倒になる失敗を何度かやった。便利だが、万能ではない。 Claude Code が強いのは、手元のファイルや既存の文脈を読みながら、具体的な作業に落とす場面だ。人間が「どこにあるのか」「何を直せばいいのか」を探す時間を削れる。 た

「入れたのに何を頼めばいいか分からない」で止まる人が多い。そこが一番もったいない。Claude Code は、起動した瞬間から小さく使い始めるのが正解だ。最初の一回で大仕事をさせる必要はない。むしろ、ファイルの中身を読ませて、整理や要約、簡単な修正を一つ通すところから始めると、使い方の勘所が一気につかめる。 Claude Code 入門としても、Claude Code 使い方の最初の一歩としても、まずは「インストールして、起動して、短い依頼を出す」までを通す。ここで詰まる人は、だいたい準備を広げすぎる。Node.js の確認、認証、作業フォルダの選び方、この3つだけ押さえれば十分だ。 まず前提をそろえる。Claude Code は Anthropic の CLI コーディングエージェントで、ターミナルから動かす。なので、普段 GUI しか触らない人でも、最初だけはコマンドを打つ必要がある。Node.js が入っていない環境では動かないので、そこだけは先に済ませる。インストール方法は環境で少し変わるが、基本は Node.js を入れて、Claude Code を公式手順どおりに入れる流れ