ターミナルを開いた瞬間に、黒い画面と英語の表示で手が止まる。ClaudeCodeを使えば開発が速くなるとわかっていても、「どこで何を入力するのか」「勝手にファイルを壊さないか」「許可画面で何を選べばいいのか」が不安になる。最初に必要なのは、難しいプロンプト術ではなく、画面の見方、移動の仕方、指示の出し方、確認の順番を決めること。これができると、ClaudeCodeは怖い黒い画面ではなく、作業を一緒に進める実用的な相棒になる。
- 最初に覚えるべき操作は、起動、移動、確認、指示、差分チェックの五つです。
- 失敗を防ぐ鍵は、作業前にGitで保存点を作り、小さな依頼から始めることです。
- 慣れてきたら、使用量確認、許可設定、テーマ、遠隔操作、VSCode連携で作業速度を上げられます。
まず理解したいClaudeCodeの正体

AIのイメージ
ClaudeCodeは、ターミナルの中で動く開発支援AIです。普通のチャットAIと違い、画面上で返事をするだけではありません。プロジェクトのファイルを読み、必要な箇所を編集し、テストコマンドを実行し、Gitの差分まで確認できます。
つまり、読者が向き合う相手は「文章を返すAI」ではなく、手元の開発環境を操作できるAIエージェントです。便利な反面、操作の順番を間違えると、どのファイルが変わったのか追いにくくなります。
最初から「アプリ全体を作って」と頼むより、「このエラーの原因を読んで」「この関数だけ直して」「変更後にテストを実行して」と小さく分けるほうが安全です。ClaudeCodeは広い範囲を見られるため、指示が広すぎると変更範囲も広がります。初心者ほど、依頼を小さく切るだけで成功率が上がります。
ターミナル操作で最初に覚える画面の見方
いまどこにいるかを確認する
ターミナルでは、最初に「いま自分がどのフォルダにいるか」を確認します。ClaudeCodeは現在開いているフォルダを基準に動くため、違う場所で起動すると、目的のプロジェクトを読めません。
プロジェクトのフォルダへ移動してからClaudeCodeを起動すると、AIがその中のファイル構成を理解しやすくなります。画面にファイル名やフォルダ名が表示されたら、まず「自分が作業したい場所にいるか」を確認してください。
初心者がつまずきやすいのは、デスクトップやホームフォルダで起動してしまい、「ファイルが見つからない」「関係ない場所を読んでいる」と混乱する場面です。作業前にフォルダ移動を済ませるだけで、この失敗はかなり減ります。
起動後は会話欄に自然な日本語で指示する
ClaudeCodeを起動すると、入力待ちの行が表示されます。そこに日本語で依頼を書けば操作が始まります。たとえば、「このプロジェクトの構成を読んで、主要なフォルダの役割を説明して」と入力すると、いきなり編集せずに読み取りから始められます。
初回は編集を頼まないほうが安全です。まず読ませる。次に直させる。最後に確認させる。この順番にすると、AIが何を見ているのか読者側も追いやすくなります。
初回起動から安全に作業する基本手順
ClaudeCodeを安全に使うには、作業前、作業中、作業後の流れを固定します。毎回同じ順番にすると、失敗しても戻りやすくなります。
- プロジェクトのフォルダをターミナルで開き、作業対象のファイルが見える状態にします。
- Gitで現在の状態を保存し、あとから戻せる安全な地点を作ります。
- ClaudeCodeを起動し、最初は「構成を読んで説明して」と依頼します。
- 修正したい範囲を一つに絞り、「このファイルだけ」「この関数だけ」のように具体的に伝えます。
- 変更案が出たら、許可画面で内容を読み、問題なければ承認します。
- 作業後に差分を確認し、意図しない変更があれば戻すか、追加修正を依頼します。
- テストや起動確認を実行し、画面上で期待どおりに動くか確かめます。
この流れの中で特に大事なのは、作業前に保存点を作ることです。Gitに慣れていない場合でも、「いまの状態を残してから触る」という考え方だけは先に覚えてください。AIに任せる範囲が広くなるほど、戻れる状態があるだけで安心感が変わります。
初心者が使うべき最初の依頼文
いきなり作らせずに読ませる
最初の依頼は、「このプロジェクトを読んで、起動方法、主要ファイル、注意点を整理して」と書くのが扱いやすいです。これならファイル編集は発生せず、ClaudeCodeがどこを見ているか確認できます。
返答に起動コマンドやフォルダ構成が出たら、内容が自分のプロジェクトと合っているか見ます。見覚えのないファイル名ばかり出る場合は、起動した場所が間違っている可能性があります。そのときは一度終了し、正しいプロジェクトフォルダで起動し直してください。
修正依頼は一文で範囲を縛る
修正を頼むときは、「ログイン画面の文言だけを変更して。デザインや認証処理は触らないで」のように、やることと触らないことを同時に書きます。
初心者は「いい感じに直して」と言いがちですが、これは危険です。ClaudeCodeは親切に広く直そうとするため、関係ないファイルまで変わることがあります。触ってよい範囲と触ってはいけない範囲を分けるだけで、差分が読みやすくなります。
許可画面で迷ったときの判断基準
ClaudeCodeは、ファイル編集やコマンド実行の前に確認を求めることがあります。この画面で焦って承認すると、想定外の変更が進むことがあります。
ファイル編集の許可なら、対象ファイル名を見ます。自分が頼んだ範囲のファイルなら承認しやすいです。依頼していない設定ファイルや認証情報に近いファイルが出たら、一度止めて「なぜそのファイルを変更する必要があるのか説明して」と聞いてください。
コマンド実行の許可なら、何を実行するのかを見ます。テスト、ビルド、型チェックのような確認系は比較的安全です。一方で、削除、初期化、強制上書き、外部送信に見える操作は慎重に扱います。
便利だからといって、最初からすべて自動承認にする必要はありません。慣れるまでは、許可画面を学習材料として使うほうが安全です。どの操作で何が起きるか見えてくると、あとから許可設定を絞って効率化できます。
変更後に必ず見るべき差分とテスト
ClaudeCodeが作業を終えたら、「終わった」という返事だけで判断しないでください。大事なのは、実際にどこが変わったかです。
差分を見ると、追加された行、削除された行、変更された設定が確認できます。頼んだ内容と違う変更が入っていたら、「この変更は不要なので戻して」と指示できます。
その次にテストを実行します。テストがない小さなプロジェクトなら、起動して画面を触ります。フォームなら入力する。ボタンなら押す。エラー修正なら、同じ操作をもう一度行う。ClaudeCodeに「変更後の確認手順を短く書いて」と頼むと、どこを見ればよいか整理できます。
最新のClaudeCodeでは、使用量の確認は「/usage」にまとまっています。以前の呼び方を入力しても関連画面に進める場合がありますが、これから覚えるなら/usageだけで十分です。作業量が増えてきたら、こまめに使用状況を見ると、長い作業の途中で制限にぶつかりにくくなります。
設定ファイルで毎回の説明を減らす
毎回同じ説明をClaudeCodeに書いているなら、プロジェクト内にルールをまとめると楽になります。たとえば、使う技術、起動方法、テスト方法、禁止したい変更、命名ルールを一つの文書にまとめます。
このファイルがあると、ClaudeCodeは作業前提を読みやすくなります。読者側も「このプロジェクトでは何を守るべきか」を一か所で確認できます。
書く内容は難しくありません。「パッケージ管理はこのツールを使う」「テストはこの手順で実行する」「環境変数を勝手に追加しない」「認証周りは変更前に確認する」のように、現場で困りやすいことを短く書けば十分です。
ClaudeCodeが同じミスをしたら、その都度ルールに追記します。これを続けると、依頼文が短くなり、出てくる変更も安定していきます。
ターミナル操作を速くする実務の型
左右に分けて見ると迷子になりにくい
ターミナルを一枚だけで使うと、ClaudeCodeの会話、ファイル確認、テスト実行が混ざります。初心者ほど、画面を左右に分けると楽になります。
左側でClaudeCodeを動かし、右側でファイル一覧やテストを確認します。これだけで「AIが作業している場所」と「自分が確認する場所」が分かれます。複数タブを使えるターミナルを選ぶと、プロジェクトごとに作業を分けやすくなります。
完了待ちは通知で減らす
ClaudeCodeに少し長い作業を任せると、画面を眺め続けたくなります。しかし、待ち続ける時間はもったいないです。ターミナルアプリの通知やセッション管理を使うと、入力待ちになったタイミングで気づけます。
作業が止まったら、何を求められているかを見ます。承認が必要なのか、追加情報が必要なのか、エラーで止まったのか。ここを見分けるだけで、無駄な待機時間が減ります。
VSCode連携とターミナル単体の使い分け
ターミナルだけで操作する方法は、軽くて速く、Gitやテストとの相性がよいです。一方で、ファイルを横に開いて細かく見たい場合は、VSCode連携が便利です。
VSCode側では、変更箇所を画面上で確認しながら会話できます。コードを見ながら「この行だけ直して」と伝えたい場面では、ターミナル単体より迷いにくくなります。
ただし、最初から環境を増やしすぎると混乱します。はじめの一週間は、ターミナルで「起動、依頼、許可、差分確認」までを覚える。その後、細かいレビューが増えたらVSCode連携を使う。この順番なら、道具に振り回されにくくなります。
スマホ操作や遠隔操作を使う前の注意点
ClaudeCodeは、ローカルで動いているセッションを別画面から操作できる仕組みもあります。席を離れても進捗確認や簡単な承認ができるため、長めの修正や調査では便利です。
ただし、スマホは細かいコードレビューに向きません。小さな承認や状況確認ならよいですが、認証処理、決済、データ削除、権限管理のような重要部分は、必ず大きな画面で差分を確認してください。
また、接続用のURLやQRコードは、セッションを操作できる鍵のようなものです。人に見せない、チャットに貼らない、画面共有中に映さない。この三つを守るだけで、不要なリスクをかなり避けられます。
ClaudeCodeターミナル操作に関する疑問解決
| 困る場面 | その場で取る行動 |
|---|---|
| 何を入力すればよいかわからない | まず「このプロジェクトの構成を読んで、起動方法と注意点を説明して」と入力します。 |
| 関係ないファイルまで変わりそうで怖い | 依頼文に「対象はこのファイルだけ」「それ以外は変更しないで」と入れます。 |
| 許可画面で承認してよいかわからない | ファイル名とコマンド内容を見て、説明できないものは承認せず理由を聞きます。 |
| 作業後に正しいか判断できない | 差分を確認し、テストまたは実際の画面操作で同じ不具合が消えたか見ます。 |
| 使用量や作業量が気になる | 入力欄で/usageを開き、現在の利用状況を確認します。 |
この表の使い方は簡単です。迷った場面に近い行を見て、そのまま行動に移してください。ClaudeCodeは難しい知識よりも、止まったときに次の一手を選べることが大事です。
初心者が最初につまずく落とし穴

AIのイメージ
落とし穴1ターミナルを開いたのに目的のプロジェクトが見つからない
ターミナルを開いてClaudeCodeを起動したのに、「このプロジェクトの構成を読んで」と入力しても、見覚えのないフォルダ名ばかり返ってくる。初心者がかなり高い確率で最初にぶつかるのがこれです。
原因はシンプルで、ClaudeCodeを作業したいフォルダの外側で起動しているからです。ClaudeCodeは、いまターミナルで開いている場所を基準にファイルを読みます。つまり、別の場所で起動すると、別の景色を見ながら話している状態になります。
こうすれば一発で解決できます。
- まずパソコン上で、作業したいプロジェクトのフォルダを探します。
- そのフォルダの名前を確認します。たとえば「myapp」や「portfolio」のような名前です。
- ターミナルで「cd」と入力し、そのあとにフォルダの場所を指定してEnterを押します。cdは移動するための合図です。
- 移動できたら「ls」と入力してEnterを押します。lsは中身を見るための合図です。
- package.json、src、app、README.mdなど、見覚えのあるファイル名が表示されたら正しい場所です。
- その状態でClaudeCodeを起動します。
- 起動後に「このフォルダの構成を読んで、主要ファイルを説明して」と入力します。
この場面で、lsをして見覚えのあるファイルが表示されると、ClaudeCodeは正しい場所から作業を始められます。逆に、何も見覚えがない場合は、まだ移動先が違います。そこで焦ってAIに頼むより、先にフォルダの場所を直すほうが早いです。
落とし穴2許可画面で全部Enterしてしまい、何が変わったかわからなくなる
ClaudeCodeが「このファイルを編集していいですか?」のような確認を出したとき、初心者はついEnterを押して進めがちです。すると数分後に作業は終わるのに、「結局どこが変わったの?」「これ、本当に安全なの?」という状態になります。
原因は、許可画面をただの邪魔な確認だと思ってしまうことです。実際には、許可画面はClaudeCodeがこれから触るファイルや実行する命令を確認する大事なチェックポイントです。
こうすれば一発で解決できます。
- 許可画面が出たら、すぐにEnterを押さずに手を止めます。
- 表示されているファイル名を1つ見ます。
- 自分が依頼した範囲に関係するファイルか確認します。
- 関係がある場合だけ承認します。
- 知らない設定ファイル、認証情報、削除を含む命令が出たら承認せずに止めます。
- ClaudeCodeに「なぜそのファイルを変更する必要がありますか?初心者にもわかるように説明して」と入力します。
- 説明を読んで納得できた場合だけ、もう一度作業を進めます。
この場面で、1回止まって理由を聞くと、作業の主導権が読者側に戻ります。ClaudeCodeは速いですが、速さに飲まれると初心者は置いていかれます。最初の3日間くらいは、許可画面を練習問題だと思って読むのが一番安全です。
落とし穴3最初から大きな依頼をして差分が読めなくなる
「ログイン機能を作って」「デザインを全部整えて」「エラーを全部直して」と頼むと、ClaudeCodeはかなり広い範囲を変更しようとします。作業が終わったあとに20ファイル以上変わっていて、どこを確認すればいいかわからなくなる。これも初心者あるあるです。
原因は、依頼の粒度が大きすぎることです。ClaudeCodeは優秀なので広く動けますが、初心者の確認力はまだ追いつきません。AIができる範囲と、読者がレビューできる範囲を分けて考える必要があります。
こうすれば一発で解決できます。
- 依頼する前に、修正したい画面や機能を1つだけ決めます。
- 「まず調査だけして。まだ編集しないで」と入力します。
- ClaudeCodeが原因や変更候補を説明したら、対象ファイルを1つか2つに絞ります。
- 「この2ファイルだけ変更して。それ以外は触らないで」と入力します。
- 作業後に差分を確認します。
- 意図した変更だけなら、テストまたは画面確認をします。
- 問題なければ、そこで一度作業を区切ります。
この場面で、調査、修正、確認を分けると、初心者でも追いつけます。ぶっちゃけ、最初はAIに全部任せるより、AIを小分けに使うほうが圧倒的に上達が早いです。
知っているとできるの差を埋める実践ロードマップ
1日目黒い画面に慣れて現在地を確認する
所要時間は15分です。まずターミナルを開きます。何かを作ろうとしなくて大丈夫です。今日の目的は、ターミナルで自分の場所を確認できるようになることです。
ターミナルの場面で、作業したいフォルダへ移動して「ls」と入力すると、そのフォルダの中身が表示されます。ファイル名が3個以上見えたらOKです。ここで大事なのは、完璧に理解することではありません。「この画面は怖いものではなく、フォルダの中を文字で見ているだけ」と体で覚えることです。
完了の判断基準は、作業したいフォルダの中身をターミナルに表示できることです。
2日目ClaudeCodeを起動して読ませるだけにする
所要時間は20分です。1日目に確認したフォルダでClaudeCodeを起動します。起動したら、いきなり編集を頼まずに「このプロジェクトの構成を読んで、初心者向けに説明して」と入力します。
ClaudeCodeの入力欄で、読むだけの依頼をすると、ファイル編集なしで全体像が返ってきます。これにより、「AIがどのフォルダを見ているか」を安全に確認できます。
完了の判断基準は、主要フォルダの役割が3つ以上説明されることです。説明に知らないフォルダ名しか出てこない場合は、起動場所が違います。その日は修正せず、フォルダ移動の練習に戻ってOKです。
3日目1文字だけ変える練習をする
所要時間は25分です。いきなり機能追加をせず、画面に表示される文言を1つだけ変えます。たとえば「送信」を「送信する」に変えるような小さな作業です。
ClaudeCodeの場面で、「画面に表示される〇〇という文言を□□に変えて。関係ないファイルは触らないで」と入力すると、変更範囲が小さくなります。作業後に差分を確認し、1か所だけ変わっていれば成功です。
完了の判断基準は、変更されたファイルが1個から2個に収まることです。5個以上のファイルが変わったら、依頼が広すぎます。その場合は「今の変更を戻して、対象ファイルを確認してからもう一度進めて」と頼みます。
4日目エラー文をそのまま読ませる
所要時間は30分です。アプリを起動したときにエラーが出たら、その文章を丸ごとClaudeCodeに渡します。初心者はエラー文を読む前に焦りますが、エラー文は道案内です。
エラーが出た場面で、表示された文章をコピーして「このエラーの意味を初心者向けに説明して。まだ修正しないで」と入力すると、原因の候補が整理されます。そのあとで「一番可能性が高い原因から1つだけ直して」と頼みます。
完了の判断基準は、エラーの原因候補が2つから3つに整理されることです。すぐに修正まで進めないのがポイントです。先に意味を理解すると、次に同じエラーが出たときの怖さが半分になります。
5日目Gitで戻れる安心感を作る
所要時間は30分です。Git(変更履歴を残すセーブ機能のようなもの)を使って、作業前の状態を残します。ゲームでボス戦の前にセーブする感覚です。
作業前の場面で、現在の変更を確認して保存点を作ると、ClaudeCodeの修正が失敗しても戻せます。初心者にとってGitは難しく見えますが、最初は「戻れるようにする道具」とだけ考えれば十分です。
完了の判断基準は、作業前と作業後の差分を見比べられることです。差分が見えれば、AIの変更をただ信じる状態から卒業できます。
6日目テストか画面確認を1回だけ実行する
所要時間は30分です。修正後に「動いた気がする」で終わらせず、1つだけ確認します。テスト(自動で動作を確認する仕組み)があるならテストを実行します。ない場合はアプリを起動して、変更した画面を実際に触ります。
確認の場面で、ClaudeCodeに「今回の変更を確認するための最短手順を3ステップで書いて」と頼むと、見るべき場所が絞られます。その手順どおりに操作して、期待した表示になればOKです。
完了の判断基準は、自分の手で1回確認できたことです。AIが「完了しました」と言ったことではありません。最後に確認ボタンを押すのは読者です。
7日目自分用の依頼テンプレートを作る
所要時間は20分です。1週間でうまくいった依頼文を1つ保存します。毎回ゼロから文章を考えると疲れます。型を持つと一気に楽になります。
実作業の場面で、「対象、やること、触らない範囲、確認方法」の4つを入れて依頼すると、ClaudeCodeの動きが安定します。たとえば「対象はログイン画面です。やることはエラー文の修正です。認証処理は触らないでください。最後に確認手順を出してください」という形です。
完了の判断基準は、次回そのまま使える依頼文が1つ手元に残ることです。この1文があるだけで、2週目からの迷いがかなり減ります。
現実でよくあるあるある失敗と専門家の対処法
失敗1エラー文を読まずに「直して」とだけ頼む
アプリを起動したら赤いエラーが出る。焦ってClaudeCodeに「直して」とだけ入力する。するとClaudeCodeは広い範囲を調べ始め、複数ファイルを変更します。作業後にエラーは消えたように見えるけれど、別の場所が壊れている。かなりリアルに起きます。
根本的な原因は、エラーの場所を渡していないことです。人間に「なんか壊れた」とだけ言っても原因がわからないのと同じです。AIにも、画面に出ているエラー文、実行した操作、起きた結果を渡す必要があります。
専門家ならこう対処します。
- エラーが出たら、まず画面の文章をコピーします。
- どの操作をしたら出たのかを1文で書きます。
- ClaudeCodeに「このエラーの意味を説明して。まだ修正しないで」と入力します。
- 原因候補を読んで、一番小さい修正から始めます。
- 修正後に同じ操作をもう一度行い、エラーが消えたか確認します。
予防策は、エラーが出た瞬間に修正ではなく説明を頼むことです。エラー画面の場面で、先に原因説明を頼むと、余計な変更を避けられます。
失敗2成功したあとに保存せず、次の作業で壊す
1回うまく修正できたのに、嬉しくなって次の依頼を続ける。2つ目の作業で壊れて、最初の成功状態に戻せなくなる。これは初心者だけでなく、慣れた人でも油断するとやります。
根本的な原因は、成功した瞬間に区切っていないことです。ClaudeCodeはテンポよく作業できるので、そのまま次々進めたくなります。でも、初心者のうちは1成功1保存が鉄則です。
専門家なら、うまくいった場面で一度止まります。画面確認をして、差分を見て、問題なければGitで保存します。そのあとで次の作業に進みます。
予防策は、1回のClaudeCode作業を30分以内に区切ることです。30分を超えると、人間側の記憶が曖昧になります。「何を頼んだっけ?」となる前に保存点を作るのがコツです。
失敗3便利ツールを先に入れすぎて本題に進めない
ターミナルを快適にしようとして、ターミナルアプリ、補助ツール、テーマ、拡張機能、遠隔操作まで一気に入れようとする。結果、設定で半日つぶれて、ClaudeCodeで何も作っていない。これも本当によくあります。
根本的な原因は、環境作りが目的になっていることです。便利ツールは、基本操作で困ったあとに入れるから効果があります。困る前に全部入れると、何が便利なのか判断できません。
専門家なら、最初の7日間は道具を増やしません。ターミナル、ClaudeCode、Git、この3つだけで小さな修正を1回成功させます。その後、「待ち時間が多い」「差分確認がつらい」「画面を分けたい」という具体的な不満が出たところでツールを足します。
予防策は、便利そうだから入れるを禁止することです。待ち時間の場面で通知が欲しくなったら通知ツールを入れる。差分確認の場面で見づらいと感じたらエディタ連携を使う。この順番なら、設定沼に落ちません。
ぶっちゃけこうした方がいい!
ぶっちゃけ、初心者が最初からClaudeCodeを完璧に使いこなそうとする必要はありません。最初の目標は、AIに大きな仕事を任せることではなく、小さな変更を安全に成功させることです。
まず7日間は、派手なことをしなくていいです。遠隔操作も、複数セッションも、高度な設定も、最初は後回しで大丈夫です。むしろ最初から触ると混乱します。まず集中するのは、「正しいフォルダで起動する」「読ませる」「1か所だけ直す」「差分を見る」「動作確認する」の5つだけです。
カフェで後輩に教えるなら、こう言います。最初の1週間は、ClaudeCodeを天才エンジニアだと思わないでください。めちゃくちゃ速いけど、説明しないと暴走する新人だと思ったほうがうまくいきます。新人に仕事を頼むなら、「この画面だけ見て」「この文言だけ直して」「終わったら何を変えたか教えて」と言いますよね。ClaudeCodeにも同じように頼めばいいです。
一番コスパがいい練習は、文言変更です。ボタン名、見出し、エラーメッセージ、説明文。このあたりを1つだけ変える練習を3回やると、許可画面、差分確認、動作確認の流れが自然に身につきます。たった3回でも、「あ、こういう感じで進むんだ」と体が覚えます。
逆に、最初にやらなくていいのは、大規模リファクタリング(コードの中身を整理して作り直すこと)、認証機能(ログインや権限を扱う仕組み)、決済機能(お金のやり取りを扱う仕組み)、デプロイ自動化(公開作業を自動で行う仕組み)です。このあたりは便利そうに見えますが、初心者が最初に触ると確認ポイントが多すぎます。
最短で結果を出すなら、1日目にフォルダ移動、2日目に読み取り、3日目に文言変更、4日目にエラー説明、5日目に保存点作成、6日目に画面確認、7日目に依頼テンプレ作成。この流れが一番堅いです。派手ではありません。でも、実務ではこういう地味な型を持っている人が強いです。
ClaudeCodeは、魔法のボタンではありません。でも、正しい場面で小さく使うと、初心者の背中をかなり押してくれます。画面で迷ったら、いきなり直させずに説明させる。変更が怖ければ、対象を1つに絞る。終わったら、AIの完了報告ではなく、自分の目で差分と画面を見る。
ぶっちゃけ、これだけで最初の壁は越えられます。完璧な環境より、1回の小さな成功。大量の知識より、今日ターミナルを開いて1つ直す体験。ClaudeCodeを使える人になる近道は、難しいことを覚えることではなく、小さく頼んで、小さく確認して、小さく保存することです。
よくある質問
ターミナル初心者でもClaudeCodeは使えますか?
使えます。ただし、最初から全部を覚える必要はありません。プロジェクトのフォルダへ移動する、ファイル一覧を見る、ClaudeCodeを起動する、この三つから始めれば十分です。わからない表示が出たら、画面をそのまま読ませて「次に何をすればよいか説明して」と聞くと、操作を進めやすくなります。
日本語で指示しても問題ありませんか?
問題ありません。むしろ初心者は日本語で具体的に書いたほうが安全です。「何をしたいか」「どこまで触ってよいか」「最後に何を確認してほしいか」を自然な日本語で書けば、作業の意図が伝わります。英語の短い命令より、日本語の丁寧な制約付き依頼のほうが失敗しにくい場面もあります。
自動承認は使ったほうがよいですか?
最初は使わないほうが安全です。許可画面を見ることで、ClaudeCodeが何をしようとしているか学べます。毎回同じテストや整形コマンドだけが出るようになったら、その範囲だけ許可を緩めると効率が上がります。すべてを一気に許可するより、よく使う安全な操作だけを少しずつ許可するほうが失敗を減らせます。
大きな機能追加を頼むときのコツはありますか?
最初に実装させず、計画を出させます。「実装前に、変更するファイル、作業順、確認方法を説明して」と頼むと、いきなり大きな差分が出るのを防げます。計画を読んで、不要な作業を削ってから実装に進むと、レビューしやすいサイズに収まります。
作業後に不安が残るときはどうすればよいですか?
「今回の変更で壊れやすい箇所を三つ挙げて、確認手順を書いて」と頼んでください。ClaudeCodeに自己点検させると、入力フォーム、権限、例外処理、表示崩れなど、見落としやすい確認点が出てきます。その手順を実際に画面で試し、問題がなければ保存点を作ります。
まとめ
ClaudeCodeをターミナルで使うとき、最初の壁はAIの性能ではなく、操作の順番が決まっていないことです。プロジェクトの場所を確認し、Gitで戻れる状態を作り、小さな依頼を出し、許可画面を読み、差分とテストで確認する。この流れだけで、初心者でもかなり安全に使えます。
慣れてきたら、/usageで使用状況を見たり、プロジェクトのルールを文書化したり、通知やVSCode連携を取り入れたりすると、待ち時間と確認の負担が減ります。
今日やることは一つで十分です。ターミナルで作業したいプロジェクトを開き、「このプロジェクトの構成を読んで、起動方法と注意点を説明して」と入力してください。そこから、ClaudeCodeは怖い道具ではなく、手順を守れば一緒に開発を前へ進められる実践的な作業環境に変わります。


コメント