最初のつまずきはだいたい決まっている。Claude Code を「入れたのに動かない」と言いながら、実は入れ方と起動場所を外しているだけだ。ここを雑に済ませると、最初の 10 分で気持ちが折れる。逆に言えば、そこさえ通せばあとはかなり素直に使える。
Claude Code 入門とか Claude Code 使い方を探しているなら、まずは「何ができるか」を盛る前に、起動して最初の依頼を通すところまでを一気にやるのがいい。コードを書く人だけの道具に見えるが、実際はファイル整理、文書の下書き、散らかったディレクトリの棚卸しにも使える。最初に必要なのは、派手な設定ではなく、ちゃんとした足場だ。
Claude Code は、チャット画面を開いて雑談するものではない。ターミナル、つまり黒い画面から呼び出して、ローカルのファイルや作業ディレクトリを相手にする CLI ツールだ。ここを勘違いすると、いつまでたっても「どこで使うのか」が見えない。
なので最初にやることは単純だ。自分のPCで端末を開き、Claude Code を入れて、作業したいフォルダの中で起動する。それだけでよい。
逆に、ホーム画面や適当な場所で起動すると、あとで「思ったファイルを見ていない」「別の案件を触ってしまった」という事故になる。筆者は最初、これをやって無駄にコンテキストを食わせた。案件フォルダを開かずに頼みごとをして、まったく関係ないファイル群の話をさせてしまったのだ。地味だが、かなりだるい失敗である。
Claude Code は、作業ディレクトリの中で使う前提で考えたほうがいい。エンジニアならリポジトリごとに、非エンジニアなら案件ごと、書類ごと、整理対象ごとにフォルダを分ける。これがないと、何を片付けたいのかが曖昧なまま広い範囲を相手にしてしまう。
たとえばファイル整理なら、こんな具合だ。
Documents/
2024_tax/
job_change/
scanned_receipts/
この単位で Claude Code を起動する。そうすると「このフォルダ内の重複っぽいファイルを洗って」「日付ごとに振り分けて」といった依頼が通しやすい。最初から全部のファイルを見せる必要はない。むしろ、見せる範囲を狭くしたほうが事故が減る。
インストール方法は環境で少し変わる。ここで無理に古い手順を覚える必要はない。まずは公式ドキュメントを確認するのが正解だ。最新版の挙動や導線は docs.claude.com を見るのが確実である。
ただし、やることの骨格は変わらない。必要なのはだいたいこの流れだ。
claude を起動するここで大事なのは、手元の環境に合わせて指示を選ぶことだ。macOS、Linux、Windows で使い方が微妙に違うことがあるし、シェルの種類でも詰まり方が変わる。曖昧なブログ記事のコピペで済ませると、変なところで止まる。公式の案内に戻るのが結局いちばん早い。
入ったかどうかは、端末で起動して確かめる。コマンド名は公式ドキュメントの表記に従うのが安全だが、基本は claude を呼び出して対話を始める形だ。初回は認証や案内が出ることが多いので、それに沿って進めればいい。
たとえば、案件フォルダに移動してから起動する。
cd ~/Documents/job_change
claude
ここで対話が始まったら、次は小さく頼む。いきなり「全部整理して」は雑すぎる。最初は短く、範囲を絞る。
このフォルダの中身を見て、就職活動の書類らしいものを用途ごとに分ける方針を提案して。
いきなり移動や削除はしないで、まずは手順だけ出して。
これなら、最初の一手としてかなり安全だ。Claude Code の反応を見るには十分だし、いきなりファイルを書き換えずに済む。
エンジニア寄りなら、こういう頼み方もよい。
このリポジトリの構成をざっと把握して、README を読むべき順番と、最初に確認すべきファイルを教えて。
変更はまだしないで。
要するに、最初の依頼は「小さく」「読み取り中心」「いきなり破壊しない」が鉄則である。
Claude Code は、あいまいな依頼に対してもそれなりに動く。ここが便利でもあり、危険でもある。
「整理して」「見やすくして」「いい感じにして」は、実はかなり危ない。どこまでやるかの境界がないからだ。結果として、差分が肥大化したり、意図しない変更を混ぜたりする。
筆者は一度、文書フォルダの整理で「重複をまとめて」と頼んだつもりが、保存名の揺れまで勝手に吸収しようとして、確認のやり取りが増えた。単純にしておけば終わる話を、自分で面倒にしたわけだ。最初の依頼ほど、作業対象とやってほしいことを細かく切るべきである。
悪い依頼の例はこうだ。
この辺を全部いい感じに整理して。
よい依頼はこうなる。
このフォルダ内の PDF を、ファイル名と更新日を見て用途別に分類したい。
まずは分類案だけ出して、削除や移動はしないで。
ここで「まずは案だけ」と書くだけで、事故率がぐっと下がる。
非エンジニアが最初に覚えるべき操作は多くない。だいたいこの3つで足りる。
cdpwdlsたとえば次のように動く。
cd ~/Documents/scanned_receipts
pwd
ls
claude
これだけで、「今どこを見ているのか」がわかる。端末は怖く見えるが、やること自体は単純だ。むしろ、どのフォルダで話しているかが見えないまま進めるほうがまずい。
Windows なら環境に応じて端末の使い方が少し違う。そこは無理に一気に覚えなくていい。まずは自分の環境で Claude Code を開けること、そして作業フォルダに入ってから会話を始めることだけ押さえれば十分だ。
最初のうちは、依頼文にこの一文を入れておくといい。
削除や上書きはしないで、まず提案だけ出して。
これは単なる保険ではない。Claude Code に限らず、作業エージェントは手を動かせるからこそ、どこまでやるかを人間が先に決める必要がある。最初に雑に任せると、確認作業のほうが重くなる。
もし文書作成に使うなら、こんな出し方が扱いやすい。
このメモを、社内共有向けに読みやすく整えて。
意味は変えず、見出しだけ足して。
ファイル整理ならこうだ。
このフォルダの重複ファイル候補を挙げて。
名前が似ているだけのものは除外して、判断理由も書いて。
このくらいの粒度が、最初の一回にはちょうどいい。
初回で止まる原因は、だいたい次のどれかに集約される。
claude が見つからない特に多いのは、作業フォルダを開かずに起動するミスだ。これで「読んでほしいファイルが見えていない」状態になる。筆者もこれで何度か無駄な往復をした。最初は自分の依頼が悪いと気づきにくいが、実際にはただの場所違いであることが多い。
詰まったら、いったん pwd で現在地を確認し、ls で中身を見て、必要ならフォルダに移動し直す。地味だが、これでだいたい片が付く。
初回の依頼が通ったら、次は「自分がいつも何を頼むか」をテンプレ化しておくと楽になる。たとえば、
1. まず現状を要約する
2. 問題点を3つ挙げる
3. 変更案を出す
4. 実行前に確認を求める
この順番にすると、毎回ゼロから頼み文句を考えなくていい。Claude Code は、手順が見えているほど働きやすい。逆に、毎回ふわっとした指示だけ投げると、やり取りが長引く。
そのあとで、用途ごとに依頼文を少しずつ育てればよい。開発ならコード修正、文書なら推敲、整理なら分類と重複確認。最初に通すべきは完璧な設定ではない。小さく動かして、期待どおりに止められる感覚を掴むことだ。
Claude Code を最初に動かすまでのコツは、派手な初期設定ではなく、場所を決めて、小さく頼むことに尽きる。ここを外さなければ、次の一歩はかなり楽になる。