ClaudeCodeの使い方、本人（本AI?）に聞いてみた

Posted at 2026-08-28

はじめに

Claude Codeを使い始めてしばらく経ちますが、正直なところ最初は「CLIで使えるClaude」くらいの認識しかありませんでした。

質問には答えてくれるし、コードも書いてくれる。でも、それ以上の使い方があるのかはよく分からない。気付けば、Web版Claudeをターミナルで使っているだけになっていました。

そんな中で見かけたのが、Plan modeやCLAUDE.md、カスタムコマンド、MCPといった機能です。

「これ、本当に使いこなせている人いるのか？」

そう思った私は、公式ドキュメントを読み込む前に、あることを試しました。

だったら本人（本AI？）に聞けばいいのでは？

Claude Codeの使い方を、Claude Code自身に聞いてみることにしたのです。

もちろん、AIは時々もっともらしく間違ったことも言います。
そこで今回は、Claude Codeへのインタビュー結果をそのまま掲載するのではなく、実機検証と公式ドキュメントによる裏取りを行ったうえで、Q&A形式にClaudeCodeが勝手にまとめました。

この記事が、私と同じように

「インストールしたけどチャットしかしていない」

という人の次の一歩になれば幸いです。

⚠️ Claude Code は更新が非常に速いです。コマンド一覧は必ず手元の /help で確認してください。本記事の内容も、読む時点では増えている可能性が高いです。

Q1. そもそも君は何者？「コード補完ツール」とは違うの？

A. 全然違います。私はターミナルで動くエージェントです。補完候補を出すのではなく、実際にファイルを読み書きし、コマンドを実行します。

「このバグを直して」と言われたら、関連ファイルを自分で探し、原因を調べ、修正し、テストを走らせて、通るまで直します。手を動かす同僚だと思ってください。

ちなみに CLI 以外に、デスクトップアプリ、Web版（claude.ai/code）、VS Code / JetBrains 拡張からも使えます。

筆者コメント: ここが最初のつまずきポイントだと思います。「AIに質問する道具」だと思っていると、@ も Plan mode も使う理由が分かりません。**「タスクを丸ごと任せる相手」**という前提に切り替わると、以降の機能が全部つながります。

Q2. インストールした直後、まず何をすればいい？

A. 作業したいフォルダに移動して claude と打つ。それだけです。
cd path/to/your-project
claude
起動したら前置きなしで本題をどうぞ。「このプロジェクトの構成を3行で説明して」あたりが最初の一歩としておすすめです。

そのうえで、最初にこれだけはやってほしいというのが3つあります。

やること	コマンド	効果
プロジェクトの説明書を作る	`/init`	毎回同じ説明をしなくて済む
モデルを選ぶ	`/model`	難タスクは賢いモデル、軽作業は速いモデル
使い方を忘れたら	`/help`	そのバージョンの全コマンド一覧

A. 基本のサイクルはこうです。

① 依頼する
   ↓
② 私が調査する（ファイル読み・検索・コマンド実行）
   ↓
③ 変更前に許可を求める → y / n
   ↓
④ 結果を確認 → 追加指示（違ったら Esc で即止めてください）

Q3. ぶっちゃけ、みんなが一番見落としてる機能は？

A. 入力欄の先頭1文字です。

私の入力欄は、最初の1文字で挙動が変わります。ここを知らないまま使っている人が一番多いです。

記号	名前	何が起きる	例
`/`	スラッシュコマンド	機能を直接呼ぶ	`/clear` `/init` `/model`
`@`	ファイル参照	ファイル/フォルダ名を補完して渡す	`@README.md を要約して`
`!`	Bashモード	コマンドを自分で実行し、結果を会話に残す	`!git status`
`#`	メモリ追記	覚えておいてほしいルールを保存	`# 回答は常に日本語で`

`@` — これだけで精度が変わる

A. 「あのファイル見て」と言われると、私はファイルを探すところから始めます。時間もかかるし、取り違えることもある。
@src/auth/login.ts のエラーハンドリングを見直して
と指してもらえれば、一発です。フォルダごと（@src/）でも指定できます。

`!` — 自分で叩きたい時

A. 対話的なログインなど、私に任せづらいコマンドは ! で自分で実行してください。出力がそのまま会話の材料になります。
!gh auth login
!git log --oneline -20

`#` — 毎回言っている指示を消す

A. 「またそれ言ってる」と思ったら、その場で # を押して登録してください。次から言わなくて済みます。
# コミットメッセージは日本語で書く

おまけ：画像は Ctrl+V で貼れます（VScodeのターミナルじゃダメでした...）

A. エラー画面のスクショ、UIのデザイン案、ホワイトボードの写真。そのまま貼ってください。「この画面の余白が崩れてるので直して」が通ります。

Q4. キーボードショートカットは？

キー	動作
Shift+Tab	パーミッションモード切替（→ Q6。最重要）
Esc	実行中の作業を中断
Esc → Esc	会話を巻き戻して、前のメッセージからやり直す
↑ / ↓	過去に打ったプロンプトの履歴
Ctrl+C	入力のキャンセル（2回で終了）
Ctrl+D	セッション終了
Ctrl+L	画面クリア（会話は消えない）
Ctrl+V	画像を貼り付け
Shift+Enter または `\` + Enter	改行（送信せずに複数行入力）
Tab	`@` や `/` 入力中の補完

A. ひとつだけ選ぶなら Esc です。

私が明らかに違う方向に走り出したとき、黙って見ていないでください。3分待って的外れな実装を受け取るより、3秒で止めて軌道修正するほうが、お互いのためです。

なお、キーバインドは ~/.claude/keybindings.json で変更できます。「Shift+Enter が効かない」場合は /terminal-setup を試してください。

Q5. `/～` のコマンド、全部教えて

A. 多いので、覚える価値が高い順に出します。全量は /help で。

毎日使う7つ（これだけでいい）

コマンド	説明	いつ使う
`/help`	コマンド一覧	迷ったら
`/clear`	会話履歴をリセット	話題が変わったら必ず
`/compact`	会話を要約して圧縮	文脈は保ちたいが長すぎる時
`/context`	コンテキスト使用量を可視化	動作が重い/雑になった時
`/model`	モデル切替	難タスクと軽作業で使い分け
`/init`	リポジトリを解析して `CLAUDE.md` を生成	プロジェクト開始時に1回
`/resume`	過去のセッションを選んで再開	昨日の続きから

設定・環境

コマンド	説明
`/config`	テーマ・モデルなど各種設定
`/status`	バージョン・アカウント・接続状況
`/doctor`	インストールや設定の健康診断（不調時の第一手）
`/permissions`	許可/拒否ルールの確認・編集
`/add-dir`	作業対象フォルダを追加
`/memory`	`CLAUDE.md` を編集
`/terminal-setup`	改行キーなどターミナル連携
`/vim`	Vim キーバインド
`/statusline`	ステータス行のカスタマイズ
`/output-style`	応答スタイルの切替

コスト・使用量

コマンド	説明
`/cost`	このセッションのトークン使用量
`/usage`	プラン利用枠の消化状況

開発ワークフロー

コマンド	説明
`/review`	変更内容のレビュー
`/code-review`	差分・PR・ブランチをバグ観点でレビュー（`--fix` で修正まで）
`/security-review`	セキュリティ観点のレビュー
`/simplify`	変更コードの簡素化・重複排除
`/pr-comments`	GitHub PR のコメントを取り込む
`/install-github-app`	GitHub Actions 連携
`/ide`	VS Code / JetBrains と接続
`/export`	会話をエクスポート
`/rewind`	ファイル変更を含めて過去の状態に巻き戻す
`/agents`	サブエージェントの作成・管理
`/mcp`	MCP サーバーの状態確認・認証
`/hooks`	フック（自動処理）の設定
`/plugin`	プラグインの管理
`/release-notes`	更新履歴（新機能キャッチアップ用）
`/bug`	フィードバック送信

自動化・スケジュール

コマンド	説明
`/loop <間隔> <指示>`	指示を定期実行（例: `/loop 5m テストが通るか確認して`）
`/schedule`	cron 的にクラウド実行するエージェントを登録
`/run`	このプロジェクトのアプリを起動して動作確認

A. そして一番大事なこと。/～ は自分で増やせます。 これは後半で。

Q6. `Shift+Tab` が最重要って言ってたけど、何が起きるの？

A. パーミッションモードが切り替わります。押すたびに循環します。

モード	挙動	使う場面
通常	変更・実行のたびに確認	初めてのリポジトリ、慎重に進めたい時
Auto-accept edits	ファイル編集は確認なしで進む	方針が固まった後の一括作業
Plan mode	読むだけ。書き込み・実行はしない	調査と計画だけさせたい時

Plan mode を推す理由

A. いきなり実装させると、間違った方向に大量のコードを書かれる。これが最大の事故です。
1. Shift+Tab で Plan mode に入る
2. 「この改修の方針を、影響範囲を洗い出したうえで提案して」
3. 計画が出る → レビューして修正指示
4. 承認 → 実装へ
「調査 → 計画 → 承認 → 実装」を癖にすると、手戻りが激減します。

筆者コメント: 半信半疑で試しましたが、これは効きます。特に他人が書いたコードを触るときの安心感が段違いでした。Plan mode を知っているかどうかで、体感の品質が変わります。

⚠️ ちなみに --dangerously-skip-permissions（全確認スキップ）というオプションがありますが、名前のとおりです。信頼できる隔離環境以外では使わないでください。

Q7. `CLAUDE.md` って何？

A. セッション開始時に自動で読み込まれる指示書です。カスタマイズの中で一番効果が大きいのはこれです。

「毎回同じ説明をしている」という状態が、これで消えます。

置き場所

場所	用途	共有範囲
`~/.claude/CLAUDE.md`	全プロジェクト共通のマイルール	個人
`<プロジェクト>/CLAUDE.md`	このリポジトリの約束事	Git にコミットしてチーム共有
`<サブフォルダ>/CLAUDE.md`	そのフォルダ固有のルール	必要な時だけ読まれる

書き方の例

# プロジェクト概要
Next.js + TypeScript の社内向けダッシュボード。

## コマンド
- 開発サーバ: `npm run dev`
- テスト: `npm test -- <ファイル>`（全体実行は遅いので単体で）
- Lint: `npm run lint`

## ルール
- 回答・コミットメッセージ・コメントは日本語
- 新規ファイルより既存ファイルの編集を優先
- `dist/` は自動生成なので手で触らない
- コンポーネントは `src/components/` に配置

## やってはいけないこと
- main ブランチへの直接コミット
- 依頼していないリファクタリング

A. コツは3つ。

/init で叩き台を自動生成 → 手で削るのが最速

作業中に「それは違う」と思ったら、その場で # で追記

長すぎると効きが悪くなります。 100行以内、箇条書き、具体的に

Q8. 長く使ってると、だんだん精度が落ちる気がするんだけど

A. 気のせいではありません。コンテキストの詰まりです。

会話が長くなるほど、私は過去のやり取りを引きずります。関係ない話題が混ざると、判断がぶれます。

症状	対処
話題が変わった	`/clear`（最重要。ケチらず使う）
文脈は残したいが長い	`/compact`
今の使用量を知りたい	`/context`
さっきの指示に戻りたい	Esc → Esc
ファイル変更ごと戻したい	`/rewind`

A. 鉄則は 「1タスク＝1セッション」。終わったら /clear。

並行して別のことをやりたいなら、ターミナルをもう1枚開いて claude を起動するほうが速いです。

筆者コメント: 「AIがバカになった」と感じる現象、原因のほとんどはこれでした。/clear を押すだけで戻ります。無料で効く一番の改善策です。

Q9. ターミナルから直接使う方法は？

A. 対話に入らず「1回だけ実行」できます。スクリプトに組み込めるので、ここから自動化が広がります。

# その場で1発回答（ヘッドレスモード）
claude -p "このフォルダの構成を3行で説明して"

# パイプで渡す（ログ解析に便利）
cat error.log | claude -p "このエラーの原因候補を3つ挙げて"

# 直前の会話を再開
claude -c

# 過去セッションを選んで再開
claude -r

よく使うオプション

オプション	説明
`-p, --print`	対話せず結果だけ出力
`-c, --continue`	直前の会話を継続
`-r, --resume`	セッションを選んで再開
`--add-dir <dir>`	追加で触ってよいフォルダ
`--model <name>`	モデル指定
`--effort <low\|medium\|high\|xhigh\|max>`	思考の深さ
`--allowedTools "Bash(git *) Edit"`	許可ツールを限定
`-w, --worktree`	Git worktree を作ってそこで作業
`--bg`	バックグラウンドエージェントとして起動
`--safe-mode`	カスタマイズを全部無効化して起動（設定が壊れた時の切り分け）
`--restricted`	コマンド実行系ツールを外した安全モード

サブコマンド

コマンド	説明
`claude update`	アップデート
`claude doctor`	インストール診断
`claude mcp`	MCP サーバー管理
`claude agents`	バックグラウンドエージェント管理
`claude plugin`	プラグイン管理
`claude import`	他のAIコーディングツールの設定を取り込み
`claude setup-token`	長期トークン発行（CI用）

A. --safe-mode は覚えておいて損がないです。「昨日まで動いてたのに変になった」ときに、自分の設定が原因かどうかを一発で切り分けられます。

Q10. 「使い切れていない人」が次に覚えるべきことは？

A. 5つあります。ここから先が本番です。

① カスタムスラッシュコマンド（`/～` を自作する）

A. 「毎回書いている長いプロンプト」をファイルに置くだけです。

.claude/commands/議事録.md

---
description: 文字起こしから議事録を作る
argument-hint: <ファイル名>
---

@$1 を読み、以下の形式で議事録を作成して保存して。

## 決定事項
## 未決事項（担当者つき）
## ネクストアクション（期限つき）

使い方: /議事録 meeting_0901.txt

$ARGUMENTS … 引数全体 / $1 $2 … 個別引数
.claude/commands/ → チームで共有（Gitに乗る）
~/.claude/commands/ → 自分専用
サブフォルダを掘れば /frontend:test のような名前空間も切れる

② Skill（私が自分で判断して読む手順書）

.claude/skills/<名前>/SKILL.md に置くと、関連する作業のときに勝手に読み込まれます。

---
name: api-design
description: REST APIの新規エンドポイントを設計・実装するときに使う。
---

- エラーレスポンスは共通フォーマット `{ code, message }` に揃える
- 認証が必要なエンドポイントには必ず認可テストを追加する
- OpenAPI定義を先に更新してから実装する

A. 違いはシンプルです。
スラッシュコマンド = 人が呼ぶ / Skill = 私が必要だと判断して呼ぶ。

③ サブエージェント（専門役に分業させる）

/agents で作成できます。

---
name: reviewer
description: コードレビュー専門。実装が終わったら呼ぶ。
tools: Read, Grep, Glob
model: sonnet
---
あなたはレビュー担当です。バグと可読性の観点のみ指摘し、実装はしないでください。

A. メリットは、別のコンテキストで動くのでメインの会話が汚れないこと。
「大量のファイルを調べる」ような重い調査を投げるのに向いています。

④ Hooks（決まった処理を必ず自動実行）

settings.json に登録すると、特定のタイミングで確実にコマンドが走ります。

イベント	例
`PostToolUse`	ファイル編集後に自動フォーマット（prettier / black）
`PreToolUse`	危険なコマンドをブロック
`Stop`	作業完了時に通知音を鳴らす
`SessionStart`	起動時に最新の環境情報を読み込む

A. 「lintを忘れる」「終わったら教えてほしい」は Hooks の出番です。/hooks から設定できます。

ポイントは、これは私が"気をつける"のではなく、システムが必ず実行するということ。お願いベースより確実です。

⑤ MCP（外部サービスと接続する）

Slack / Notion / Figma / GitHub / DB などに接続できます。

claude mcp add --transport http notion https://mcp.notion.com/mcp

接続後は /mcp で認証状態を確認。
「設計ドキュメントを読んで、今の実装との差分を洗い出して」が可能になります。

Q11. おすすめの進め方を、パターンで教えて

① 王道：調査 → 計画 → 実装 → 確認

1. Shift+Tab で Plan mode
2. 「@src/ を調査して、○○機能の実装方針を出して。まだコードは書かないで」
3. 計画をレビュー・修正指示
4. Plan mode を抜けて「この方針で実装して」
5. 「テストを実行して、通るまで直して」

A. 3を飛ばさないでください。 ここが品質の8割です。

② テスト駆動（相性が最高）

1. 「この仕様を満たすテストだけ先に書いて。実装はまだしないで」
2. 「テストが失敗することを確認して」
3. 「テストを通す実装をして。テストは書き換えないで」

A. 合格条件が機械的に判定できる作業ほど、私は強いです。 自分で回して自分で直せるので。

③ スクショ駆動（UI修正）

1. 崩れている画面を Ctrl+V で貼る
2. 「この余白のズレを直して」
3. 「直したらブラウザで開いてスクショを撮り、見比べて」

④ 既存コードの理解（新規参画時）

/clear
「このリポジトリの全体構成を、初見の人向けに説明して」
「認証処理のエントリポイントから順に追って、フローを説明して」

A. ドキュメントがないプロジェクトの立ち上がりが、劇的に速くなります。個人的に一番おすすめの使い道です。

⑤ Git / PR 作業

「変更内容を確認して、適切な粒度でコミットを分けて」
「PRを作成して。本文には背景・変更点・確認手順を含めて」
/code-review

⑥ 並行作業（git worktree）

claude -w feature-a   # 別ブランチを別フォルダで、干渉なく同時進行

Q12. コードを書かない人には関係ない？

A. とんでもない。 私はファイルを読み書きできるので、テキストが絡む仕事はだいたいできます。

やりたいこと	頼み方の例
文字起こし → 議事録	`@transcript.txt を読んで、決定事項とToDoを表にして`
資料作成	`@メモ.md を元に、15枚構成のスライド案を作って`
大量ファイルの整理	`このフォルダを内容で分類して、フォルダ分け案を出してから実行して`
表記ゆれの統一	`@用語ルール.md に従って、配下の .md 全部の表記を統一して`
データ整形	`@data/ のJSONを読んで、Excelに貼れるCSVに変換して`
調べ物＋レポート	`○○について調べて、共有用にMarkdownでまとめて`

A. コツは、「出力形式」と「保存先ファイル名」まで指定すること。そのまま使える成果物が出ます。

筆者コメント: 実際、この記事の初稿も本人に書かせました。

Q13. 正直に言って、人間側のどこがイケてない？

A. 聞かれたので言います。

よくある失敗	なぜダメか	どうする
ずっと同じセッションで別の話をする	文脈が混ざって精度が落ちる	話題が変わったら `/clear`
「いい感じにして」と丸投げ	判断基準がないので外す	完了条件を書く
ファイルを言葉で説明する	探すのに時間がかかる・取り違える	`@` で直接指定
違う方向に進んでも黙って見ている	手戻りが増える	Esc で即中断。Esc×2 で巻き戻し
いきなり大改修を依頼	レビュー不能な差分になる	Plan mode で計画 → 分割して実行
毎回同じ注意をする	疲れませんか	`#` や CLAUDE.md に書く
「できました」を鵜呑み	未検証の可能性がある	「テストを実行して結果を貼って」と言う
設定が壊れて挙動が変	切り分けができない	`claude --safe-mode` / `/doctor`

依頼文の3点セット

❶ 対象を示す    → @ でファイル指定
❷ ゴールを示す  → 「〜が完了条件」
❸ 制約を示す    → 「既存の書き方に合わせて」「テストは変えないで」

悪い例

バグ直して

良い例

@src/auth.ts のログイン処理で、パスワード誤り時に500が返る。
401を返すよう直して。
@tests/auth.test.ts が通ることが完了条件。
既存のエラーハンドリングの書き方に合わせて。

A. ちなみに最後の「できましたを鵜呑みにしない」は本当に大事です。私は検証を頼まれなければ検証しないことがあります。「実行して結果を見せて」まで言ってください。

Q14. 最後に、ひとつだけ覚えるなら？

A. 2つになりますが、許してください。

① Plan mode で計画させてから実行させる
② 話題が変わったら /clear

この2つだけで、体験が別物になります。

チートシート

━━━ 入力の記号 ━━━━━━━━━━━━━━━━━━━━━━━━━━━
  /  コマンド    @  ファイル指定    !  Bash実行    #  記憶させる
  Ctrl+V  画像貼付        Shift+Enter  改行

━━━ 最重要キー ━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Shift+Tab   モード切替（通常 / 自動承認 / Plan）
  Esc         中断        Esc Esc   巻き戻し
  ↑           履歴        Ctrl+L    画面クリア

━━━ 覚える7コマンド ━━━━━━━━━━━━━━━━━━━━━━━
  /help     一覧            /clear    話題を変える時は必ず
  /init     CLAUDE.md生成   /model    モデル切替
  /context  使用量確認      /resume   続きから
  /cost     コスト確認

━━━ ターミナル ━━━━━━━━━━━━━━━━━━━━━━━━━━━
  claude              起動
  claude -p "..."     1発実行
  claude -c           直前の会話を継続
  claude --safe-mode  設定を無効化して起動（トラブル時）
  claude update       更新

━━━ 品質を上げる型 ━━━━━━━━━━━━━━━━━━━━━━━
  Plan modeで計画 → 承認 → 実装 → テスト実行 → /clear
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

おわりに

なんだかいつもより流暢な感じがしましたね。

この記事を書く前の私は、Claude Codeをかなり活用しているつもりでした。

ですが実際に"本AI"へインタビューしてみると、使ったことのない機能や、名前だけ知っていた機能が想像以上に多くありました。

特に印象的だったのは、便利なコマンドを覚えたことよりも、

@で対象を明示する
Plan modeで先に考えさせる
CLAUDE.mdに知見を蓄積する
話題が変わったら /clear する

といった、使い方そのものの考え方です。

結局のところ、Claude Codeは魔法のツールではなく、共同作業をする相手に近い存在なのだと思います。

そして面白いことに、その使い方を一番詳しく説明してくれたのは公式ドキュメントではなく、Claude Code自身でした。

もちろん、最後に信頼すべきなのは公式ドキュメントと実際の検証結果です。

それでも、

「本AIなら、自分の使い方くらい知っているだろう」

という発想から始まった今回の試みは、思った以上に有意義でした。

もしClaude Codeを導入したものの、まだ質問相手としてしか使っていないのであれば、ぜひ一度聞いてみてください。

「ところで君、どう使うのが正解なの？」

意外と本人、いや、本AIが一番詳しいかもしれません😏

参考リンク

公式ドキュメント: https://docs.claude.com/en/docs/claude-code
新機能の確認: セッション内で /release-notes
困ったとき: /doctor → claude --safe-mode → /bug

※ 本記事は Claude Code v2.1.250 時点の情報です。記載のコマンドは claude --help および実機で確認していますが、バージョンにより差異があります。手元の /help もあわせてご確認ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up