使い方を覚えるのに、まず何から触ればよいですか？

よく知っている小さなプロジェクトの根でセッションを始め、修正ではなく質問から入るのが近道です。「このプロジェクトは何をするものか」を尋ねて答えの正しさを判断できる状態なら、次の依頼の精度も上げやすくなります。

勝手にファイルを書き換えられるのが不安です。

Shift+Tabで許可の段階を切り替えられます。Manualモードなら読み取り以外は毎回確認が入ります。加えて、設定ファイルにdenyのルールを書いておくと、どのモードでもそのコマンドやファイルは止まります。

変更を元に戻すにはどうすればよいですか？

`/rewind`または入力欄が空の状態でEscを2回押すと、依頼ごとの地点に戻せます。ただしシェルコマンドによる変更は対象外なので、作業前にコミットしておき、戻すときはGitを使うのが確実です。

Claude Codeの使い方｜Macで最初の依頼から変更の確認まで

Q: Claude Codeは無料で使えますか？

公式のセットアップのページには、Pro・Max・Team・Enterpriseのいずれかの契約かConsoleのアカウントが必要で、claude.aiの無料プランには含まれないと明記されています。インストール自体は無料でできますが、ログインの時点で契約が必要になります。

「claude code 使い方」で検索して出てくる記事の多くは、インストールの手順と機能の一覧で終わっている。実際に詰まるのはその先で、依頼を出したあとに何が起きたのかが追えなくなる場面だ。ファイルがいくつ変わったのか、どこまで戻せるのか、どの段階で人が確認すべきなのか。この記事は機能の紹介ではなく、Macで1つの作業を最後まで終える順番として使い方を並べる。記載は公式ドキュメント（code.claude.com）の2026年9月時点の内容に沿っている。

Claude Codeが何をする道具なのかを先に押さえる

Claude Codeは、ブラウザで使うチャットとは役割が違う。チャットは文章を返すだけで、手元のファイルには触れない。Claude Codeは作業フォルダの中のファイルを自分で読み、必要なら書き換え、テストやビルドのコマンドを実行する。つまり「相談相手」ではなく「作業する相手」で、だからこそ許可の考え方と確認の手順が使い方の本体になる。

呼び出し方は1つではない。ターミナルでclaudeと打つ形、Claudeのデスクトップアプリの中にあるCodeタブ、VS CodeやJetBrainsの拡張、そしてブラウザやスマートフォンから使うクラウドのセッションがある。公式ドキュメントはこれらを同じエンジンにつながる入り口として説明していて、プロジェクトのCLAUDE.mdや設定、MCPの設定はどの入り口でも共通に効く。

料金の前提も先に確認しておきたい。公式のセットアップのページには、Claude CodeはPro・Max・Team・Enterpriseのいずれかの契約か、Consoleのアカウントが必要で、claude.aiの無料プランには含まれないと明記されている。無料で試せるのは道具そのものではなく、Macに入れるまでの手順だけだと考えておくと齟齬がない。

作業を始める前に決める3つのこと

使い方でいちばん結果に響くのは、実は最初の3つの選択で、これらは記事にも書かれにくい。

どのフォルダで起動するか。 Claude Codeは起動したディレクトリを作業フォルダとして扱う。リポジトリの根（.gitやpackage.jsonがある場所）で起動するのが基本になる。5つのプロジェクトが同居する親フォルダで起動すると探す範囲が無駄に広がり、逆にsrcの中で起動するとテストの設定が見えなくなる。
どの入り口を使うか。 画面で差分を見ながら進めたいならデスクトップアプリ、自動実行や他のコマンドとつなぐ用途があるならターミナル、というのが公式の案内に沿った分け方になる。
どのモードで始めるか。 許可の段階（パーミッションモード）は、何を人が承認するかを決める。Pro・Max・Teamの契約では、ターミナルの対話セッションは自動モードで始まる。別のモデルが行動を点検して危ないものを止める仕組みで、それ以外の契約では1つずつ確認するManualモードで始まる。

この3つを決めずに触り始めると、「勝手に書き換わった」「何も進まない」という両極の感想になりやすい。

最初の依頼から変更の確認までの手順

手を動かす順番は次のようになる。

プロジェクトの根に移動してclaudeを起動する。入力欄の上に出ている作業フォルダを目で確認する。
いきなり修正を頼まず、まず読ませる。「このプロジェクトは何をするものか」「入口はどこか」のような質問から始める。公式のクイックスタートも、最初の手順を質問に充てている。
依頼は具体的に書く。公式が例として挙げているのは「バグを直して」ではなく「ログイン時に誤ったパスワードを入れると白い画面になる不具合を直して」という書き方で、症状と場所と条件が入っている。
変更が2ファイルを超えそうなら、計画モードで方針を先に出させる。Shift+Tabでモードを切り替えると、状態表示が計画モードに変わる。
実行させたあと、差分で確かめる。git statusとgit diff、デスクトップアプリなら差分ビューを開く。
残すか戻すかを決める。残すならコミット、戻すなら/rewindかGitで戻す。

この6つのうち、飛ばされやすいのは2と5だ。2を飛ばすと見当違いのファイルを触られ、5を飛ばすと気づかないまま次の依頼に進んでしまう。

許可の段階を使い分ける

許可の段階は、速さと目の届きやすさの取引になる。公式ドキュメントの整理を要約すると次の通り。

モード	確認なしで動く範囲	向いている場面
Manual（default）	読み取りだけ	初めてのリポジトリ、慎重に進めたい作業
acceptEdits	読み取りとファイル編集、mkdirやmvなど	差分を見ながら反復する作業
plan	読み取り中心で、ソースは編集しない	変更前の調査
auto	ほぼすべて。別のモデルが背後で点検する	長い作業、確認の回数を減らしたいとき
bypassPermissions	すべて	コンテナや仮想マシンなど隔離された環境のみ

モードとは別に、許可のルールを設定ファイルに書ける。.claude/settings.jsonにdenyとして書いたものは、どのモードでも止まる。.envの読み取りや本番へのデプロイコマンドのように「絶対に動かしたくないもの」は、CLAUDE.mdに文章で書くのではなくここに書く。公式ドキュメントは、許可のルールはモデルではなくClaude Code自身が強制すると明記している。文章での指示は方針、ルールは強制で、役割が違う。

CLAUDE.mdに覚えさせることと、書かないこと

セッションは毎回まっさらな状態から始まる。引き継がれるのはCLAUDE.mdに書いた内容と、Claude自身が書き足していく自動メモの2つだけだ。プロジェクトの根に置いたCLAUDE.mdはチームで共有され、~/.claude/CLAUDE.mdは自分の全プロジェクトに効く。個人的な設定はCLAUDE.local.mdに分け、バージョン管理から外す。

書く内容は「2回説明したこと」に絞ると外れない。ビルドとテストのコマンド、ディレクトリの約束事、必ず踏む手順などが該当する。逆に、長い手順や特定の場所にしか関係しない規則は、スキルや.claude/rules/に分けたほうが効く。公式は1ファイル200行未満を目安として示している。毎回コンテキストに読み込まれるため、長くなるほど守られにくくなるからだ。/initを実行すると、コードを読んだうえでの草案が生成されるので、そこから削って整えるのが早い。

取り消しが効く範囲を正確に知る

Claude Codeは、ターンを始める依頼のたびにチェックポイントを作る。/rewindか、入力欄が空の状態でEscを2回押すと、どの依頼の時点に戻すかを選べる。コードだけ、会話だけ、両方、の3通りから選べて、再開したセッションでも使える。

ただし戻せない範囲がある。公式ドキュメントが挙げているのは次のものだ。

シェルコマンドによる変更。rmやmv、整形ツールや生成ツールが書き換えたファイルは対象外になる
多くのサブエージェントが行った編集。Gitで戻すよう案内されている
セッションの外で人が手で編集したファイル
シンボリックリンクやハードリンクのファイル。復元時に読み飛ばされ、警告が出る

つまり、会話に細かく出てくる変更ほど戻しやすく、会話に「12ファイル変更」としか出ない変更ほど戻しにくい。作業を始める前にコミットして、区切りごとにgit statusを見る習慣が、結局いちばん確実な保険になる。公式も、チェックポイントはバージョン管理の代わりではないと書いている。

入り口ごとの違いと、無料で試せる範囲

入り口の違いは機能表よりも「どこで確認するか」で選ぶとぶれない。ターミナルは最も機能が揃っていて、スクリプトからの実行や自動化ができる唯一の入り口になる。デスクトップアプリは、複数のセッションを並行させる、差分に行単位でコメントを付けて直させる、画像やPDFを添付する、といった場面で強い。エディタの拡張は、すでにそのエディタで1日を過ごしている人向けだ。

ローカルの環境を用意せずに試す道もある。

ローカル環境を用意しなくても、ブラウザから Claude Code を使える環境が claude.ai/code で提供されています。Anthropic のインフラ上で動くため、自分のマシンがオフでも実行し続けます。出典: qiita.com

ただしクラウドのセッションはGitHubのリポジトリを対象にする形なので、手元のフォルダをそのまま扱いたい用途には向かない。手元のファイルを直接触らせたいならターミナルかデスクトップアプリ、長時間回したい処理はクラウド、という住み分けになる。

注意しておきたい弱点

便利さの裏側にある弱点も、使い方の一部として知っておきたい。

第一に、作業量の把握が難しい。会話は「何をしたか」を語るが、ファイルシステムの実際とは別物で、整形ツールが走ると小さな修正が大量の差分に埋もれる。確認の手間を減らすには、整形の範囲を触ったファイルに限らせる依頼の仕方が効く。

第二に、並行作業での取り違えがある。同じリポジトリで2つのセッションを同時に走らせると、互いの変更が同じ作業ツリーに混ざる。--worktreeを付けて起動すると、セッションごとに別のチェックアウトが割り当てられ、コミットするまで混ざらない。

第三に、確認を人が飛ばしやすいことだ。自動モードは確認の回数を減らすが、その分だけ最後の差分確認の重みが増す。速く進めるほど、終わりの点検を省けなくなる。

第四に、指示が積み重なると矛盾することがある。CLAUDE.mdに書いた規則どうしが食い違っていると、どちらが採られるかは安定しない。公式も、矛盾した規則があるとどちらかが任意に選ばれると書いている。数週間に一度は自分の書いた規則を読み返して、古くなった行を消すほうが、書き足すより効果が大きい。あわせて.claude/settings.local.jsonに溜まった承認の記録を見ると、毎回許可しているコマンドが分かるので、共有側の設定に移すか、範囲が広すぎるものを狭めるかの判断ができる。

画面の行き来が、実は一番の消耗になる

1つの作業自体は数分で終わる。それでも1日の終わりに疲れが残るのは、セッションを見るターミナル、差分を見るエディタ、ファイルの実体を見るFinderの間を何度も往復するからだ。1回の切り替えは数秒でも、回数が増えれば確認そのものが面倒になり、省かれる。

道具の側で減らせる部分もある。フォルダとターミナルが同じ窓にあれば、git statusを見るのも、生成されたファイルを開くのも、移動先を確かめるのも、窓を切り替えずに済む。フォルダとターミナルとAIが同じ窓にある形で作業すると、上の手順の5番目が「別の窓を開く」ではなく「目を動かす」だけになる。どんな機能でそれを実現しているかはできることに、他のファイル管理アプリとの違いは他のファイル管理との比較にまとめてある。費用の目安は料金、動作条件や細かい疑問はよくある質問で確認できる。

席を立ったあとの扱いも同じ発想で考えられる。エージェントが確認待ちで止まっているとき、Macの前に戻るまで進まないのは待ち時間の無駄になる。外から手元のMacに触れる手段があるかどうかは、iPhone・iPadから続きをで確かめておくと、長い作業の組み立て方が変わる。