「え、そんなことできるの」Claude Code の知らないと損する便利機能

はじめに
第1章: 知ったら今すぐ使いたくなる便利機能
第2章: コンテキスト管理 — Claude Code で一番大切なスキル
まとめ
- 参考リンク

はじめに

Claude Code を毎日使っていても、まだ知らない機能があります。

「コード生成やバグ修正には使っている。でも、本当に使いこなせているのだろうか」そう感じたことはないでしょうか。Claude Code はアップデートが速く、気づかないうちに便利な機能が増えています。知っているかどうかで、日々の開発体験がかなり変わります。

この記事は、Claude Code をすでに使っているけれど、もっと良い使い方を探しているエンジニアを対象にしています。機能のリストではなく、どんな場面でなぜ便利なのかという切り口で紹介します。

本記事の情報は 2026 年 4 月時点のものです。Claude Code は頻繁にアップデートされるため、コマンドの挙動や仕様が変わっている場合があります。最新情報は公式ドキュメントをご確認ください。

第1章: 知ったら今すぐ使いたくなる便利機能

/btw — 作業の流れを止めずに横から質問する

Claude がファイルを編集している最中に「そういえばこの API の引数は何だっけ」と思ったことはないでしょうか。

従来の方法では、Claude の返答を待ってから質問するか、別のウィンドウで検索するしかありませんでした。/btw はそれを変えます。

/btw は By The Way（ところで）を略したコマンドで、Claude が作業中でも横から質問を投げられます。回答は画面上に一時的に重ねて表示され、閉じると消えます。メインの会話履歴にも残りません。

/btw この関数の引数の型は何ですか

このコマンドの最大の特徴は「会話履歴に入らない」点です。質問と回答がコンテキストに蓄積しないため、メインの作業スレッドを汚しません。

また、/btw は親の会話のプロンプトキャッシュを再利用するため、追加コストも小さく抑えられます。現在の会話に含まれる情報は参照できるので、「さっき見たあのファイルの中身は」といった質問にも答えられます。ただしツールは使えないため、ファイルを読み直したり、コマンドを実行したり、検索したりはできません。 /btw は一問一答なので、続けて深掘りしたい場合は通常のプロンプトに切り替えます。

こんな場面で役立ちます。

大規模なリファクタ中に別の関数の仕様を確認したいとき
Claude がテストを書いている間に関連するドキュメントについて聞きたいとき
長い応答が生成されている最中に、関連する仕様だけ先に確認したいとき

/autofix-pr — PR のレビューコメントを自動で修正する

プルリクエストを出した後、レビュアーから「変数名を変えてください」「ここにコメントを追加してください」といったコメントが届く。日常的に PR を出すエンジニアなら誰もが経験する場面です。

/autofix-pr は、この PR の修正ループを自動化します。

コマンドを実行すると、Claude Code はセッションの全コンテキスト（会話履歴、ファイル編集内容、推論プロセス）をクラウドに送信します。その後、PR の GitHub イベント（新しいレビューコメント、CI のチェック失敗）を自動で監視し、対応する修正コミットを作成します。

ターミナルで PR のブランチにいる状態で、以下のコマンドを実行します。

/autofix-pr

実行すると Claude Code が gh コマンドでオープン中の PR を検知し、クラウドセッションを起動して自動修正を有効化します。ノートパソコンを閉じてもクラウド側で動き続けるため、翌朝確認すると修正が完了していた、という使い方もできます。

修正内容が明確な場合（変数名の変更、typo 修正など）、Claude は自動で修正してプッシュします。レビューコメントの解釈が複数ある場合や、アーキテクチャに関わる変更が必要な場合は、先に確認を求めてきます。

利用にあたっての条件は以下のとおりです。

GitHub App のインストールが必要（PR の Webhook を受け取るため）
Claude Code の Pro、Max、Team、Enterprise プランのユーザーが対象
ゼロデータリテンション（Zero Data Retention）が有効な組織では利用不可。ゼロデータリテンションとは、Anthropic 側にデータを一切保持させない設定を指し、Enterprise プランから選択できる

/voice — キーボードを打たずに Claude に話しかける

Claude Code のヘビーユーザーの中には「タイピングではなく、Claude に話しかけてコーディングすることがほとんど」という人もいます。

/voice は音声入力でプロンプトを送るコマンドです。外部ツール不要でターミナル内で動作します。

CLI での使い方は次のとおりです。

セッション内で /voice を実行して音声入力を有効化する
スペースバーを長押しながら話す
離すと録音が終わり、テキストに変換される

音声はリアルタイムで文字起こしされ、プロンプト入力欄に表示されます。確定前にキーボードで編集できます。

特に便利な場面を挙げます。

長い要件や背景情報を口頭で伝えたいとき
コードレビューのフィードバックを詳しく説明したいとき
手が離せない状況でのハンズフリー操作

デフォルト言語は英語です。日本語で使う場合は /config で言語設定を変更してください。録音した音声は Anthropic のサーバーに送信され、サーバー側で文字起こしされます。

なお、/voice を使うには Claude.ai アカウントでのログインが必須です。Anthropic API キー直接利用、Amazon Bedrock、Google Vertex AI、Microsoft Foundry 経由で認証している場合は利用できません。SSH セッションや Claude Code on the Web のようにローカルマイクへアクセスできない環境でも動作しません。

--bare — スクリプトや CI での実行を最大 10 倍高速化する

Claude Code を CI/CD パイプラインや自動化スクリプトに組み込んでいる場合、起動時間が積み重なると無視できないコストになります。

デフォルトでは、claude -p（SDK 経由の実行）を呼び出すたびに、Claude Code はローカルの CLAUDE.md、設定ファイル、MCP サーバーを自動検索します。インタラクティブな開発では便利な機能ですが、スクリプトやバッチ処理では不要な処理です。

--bare フラグはこの自動探索をスキップします。Hooks、スキル、プラグイン、MCP サーバー、自動メモリの読み込みをすべてバイパスするため、起動が高速化されます。Claude Code 開発者の Boris Cherny 氏は「最大 10 倍速くなる」と述べています。

# 通常の実行
claude -p "このコードをレビューしてください"

# --bare を使った高速実行
claude -p --bare --system-prompt "You are a code reviewer" "Review this PR"

公式には「将来のバージョンでは --bare をデフォルトにする予定」とされています。

--bare モードではいくつかの制限があります。Bash、ファイル読み取り、ファイル編集の基本ツールのみが利用可能です。また、OAuth キーチェーン認証が無効になるため、ANTHROPIC_API_KEY 環境変数か --settings での API キー指定が必要です。

主な用途は次のとおりです。

CI/CD パイプラインでのコードレビュー自動化
GitHub Actions での PR チェック
定期実行スクリプトへの組み込み

シェルコマンドの直接実行 — セッションを抜けずにコマンドを実行する

Claude Code のセッション中に、ちょっとしたシェルコマンドを実行したくなることがあります。ls -la でファイルを確認したい、git status を見たい、という程度の操作です。そのためだけに Claude に頼むのは大げさですし、別のタブに切り替えるのも面倒です。

! コマンドを使うと、セッションを抜けずにシェルコマンドを直接実行できます。

!ls -la
!git status
!cat package.json

コマンドの出力は会話コンテキストに追加されます。Claude を介さずに直接実行されるため、許可確認なしで素早く結果を確認できます。「Claude に頼むまでもないけれど、わざわざ切り替えるほどでもない」という操作にぴったりです。

/rewind・/rename・/effort — 知っていると差がつく 3 つのコマンド

/rewind — セッション内のやり直しを瞬時に

Claude が予期しない方向で変更を加えてしまったとき、/rewind（または Esc を 2 回押す）で会話とコードを任意の時点まで巻き戻せます。

Esc を 2 回押すと、巻き戻し先を選ぶメニューが表示されます。選択肢は以下の 5 つです。

両方を復元（Restore code and conversation）— 完全な巻き戻し
会話のみ復元（Restore conversation）— コード変更はそのままで、会話だけを巻き戻す
コードのみ復元（Restore code）— 会話はそのままで、ファイル変更だけを巻き戻す
ここから要約（Summarize from here）— 選択した地点以降の会話を要約してコンテキストを圧縮する
Never mind — 何もせずメニューを閉じる

「ここから要約」については後述のコンテキスト管理のセクションで詳しく説明します。

/undo も /rewind の別名として使えます。

/rename — セッションに意味のある名前をつける

デフォルトでは、過去のセッションはタイムスタンプでしか識別できません。/rename でセッションに名前をつけておくと、後から /resume で探しやすくなります。

/rename auth-refactoring

セッション開始時に名前をつける場合は claude -n auth-refactoring とします。

/effort — 推論の深さをセッション単位で制御する

/effort は、Claude がどれだけ深く考えてから回答するかを設定するコマンドです。2026 年 4 月 16 日にリリースされた Opus 4.7 では low、medium、high、xhigh、max の 5 段階で、デフォルトは xhigh です。xhigh は high と max の間に位置する新しいレベルで、推論の深さとレイテンシのトレードオフを細かく制御できます。

/effort xhigh

Anthropic は xhigh を API 設計、レガシーコードの移行、大規模なコードベースのレビューなど、知性が求められるエージェント的タスクに推奨しています。ただし、分類・抽出・フォーマット・短い要約のような軽い作業では medium や low の方がトークンを節約できます。難しい問題でさらに性能を引き出したいときだけ max を使うのが実用的です。

特定のメッセージだけ深く考えさせたい場合は、プロンプト内に ultrathink と書くと、そのターンだけ高いレベルの推論が実行されます。

ultrathink でこの認証フローの脆弱性を分析して

推論の深さを制御する正式な方法は 2 つあります。ultrathink はそのターンだけ深い推論を促すインコンテキスト指示で、API に送信される effort レベル自体は変更しません。/effort はセッション全体に適用されます。

/recap — 席を外して戻ってきたときに会話を思い出す

長時間のセッションで作業していると、会議やランチで席を外すことがあります。戻ってきたときに「この会話、どこまで進んだんだっけ」と思い出すのに時間がかかる場面は、誰にでもあるはずです。

/recap は、現在のセッションの進捗を 1 行で要約して表示するコマンドです。さらに便利なのは、自動で生成される点です。

自動生成の条件は次のとおりです。

ターミナルがフォーカスされていない（別のウィンドウやアプリに移っている状態）
最後のターン完了から 3 分以上経過している
セッションがすでに 3 ターン以上進んでいる

条件を満たすとバックグラウンドで要約が生成されるので、ターミナルに戻ってきた時点ですでに 1 行のサマリーが表示されています。同じ要約が連続して出ることはありません。

/recap

手動で /recap を実行すれば、いつでもその時点までの要約を生成できます。どのプラン・プロバイダーでもデフォルトで有効です。

自動生成を無効にしたい場合は /config で「Session recap」をオフにします。環境変数 CLAUDE_CODE_ENABLE_AWAY_SUMMARY でも制御でき、0 で無効、1 で有効です。非対話モード（claude -p）では常にスキップされます。

第2章: コンテキスト管理 — Claude Code で一番大切なスキル

コンテキストウィンドウの管理は、Claude Code の出力品質を左右する最も重要なスキルです。機能を知ることと同じくらい、いやそれ以上に大切です。

コンテキストウィンドウの基本

2026 年 4 月時点で、Opus 4.7、Opus 4.6、Sonnet 4.6 はいずれも 1M トークン（100 万トークン）のコンテキストウィンドウをサポートしています。数字だけ見ると「これだけあれば何でも入れられる」と感じる方もいるでしょう。しかし、実際の制約は想像より深いところにあります。

なお、Opus 4.7 は新しいトークナイザーを採用しており、同じテキストでも Opus 4.6 と比べて最大 1.35 倍のトークンを消費することがあります。1M のウィンドウに収まっていた入力が 4.7 では少し余裕がなくなる可能性があるため、移行時はトークン消費の変化に注意してください。

コンテキストが膨れるほど、モデルのパフォーマンスは低下します。これは「Lost in the Middle」問題として知られており、会話の冒頭と末尾の情報は高い精度で処理される一方、中央に埋まった情報は見落とされやすくなります。

つまり、コンテキストウィンドウが大きいことは「詰め込んでいい」という意味ではなく、「余裕をもって管理できる」という意味です。

/context でトークン使用量を把握する

まず現状を知ることから始めましょう。セッション内で /context を実行すると、トークンの使用状況が分類別に表示されます。

claude-opus-4-7 · 380k/1000k tokens (38%)
System prompt:      2.7k tokens  (0.3%)
System tools:      16.8k tokens  (1.7%)
Memory files:       7.4k tokens  (0.7%)
Messages:         353.1k tokens  (35.3%)
Free space:         587k         (58.7%)
Autocompact buffer: 33.0k tokens (3.3%)

それぞれの項目が何を指すかを理解しておくと、改善のヒントが見えてきます。

System prompt と System tools は Claude Code 自体のオーバーヘッドで、変更できません。 Memory files は CLAUDE.md の内容であり、内容が多いほどすべてのターンでトークンを消費します。公式の Best Practices でも、CLAUDE.md が長すぎると重要なルールがノイズに埋もれ、Claude が指示を無視しやすくなると注意されています。 CLAUDE.md は「短く保つこと自体がコンテキスト管理」と覚えておいてください。

Messages が管理の主な対象となる会話履歴です。Autocompact buffer は約 33K トークンが自動圧縮のために予約されており、この閾値を超えると自動圧縮が実行されます。

また、接続しているが使っていない MCP サーバーがある場合、そのツール定義がすべてのリクエストで送信されます。使っていない MCP サーバーは切断しておくと、トークンを節約できます。

/statusline でコンテキスト使用率を常時表示する

/context は手動で実行するコマンドですが、コンテキスト使用率を常に画面に表示しておく方法もあります。それが statusline 機能です。

/statusline コマンドを使えば、自然言語で指示するだけでステータスラインを設定できます。

/statusline モデル名、コンテキスト使用率、セッションコストを表示して

これだけで、画面下部にコンテキスト使用率がリアルタイムで表示されます。常に見えていれば、「気づいたら 80% を超えていた」という事態を防げます。

より細かくカスタマイズしたい場合は、シェルスクリプトを自作して ~/.claude/settings.json に登録できます。 Claude Code はセッション情報の JSON を stdin で送信するので、スクリプト側で整形して stdout に出力します。

{
  "statusLine": {
    "type": "command",
    "command": "sh ~/.claude/statusline.sh",
    "padding": 0
  }
}

まずは /statusline コマンドで試して、物足りなくなったらスクリプトを自作する、という流れがおすすめです。

3 つのコンテキスト管理コマンド

/clear — 完全リセット

別のタスクへ切り替えるとき、または今のコンテキストが不要になった時点で使います。

/clear

会話履歴がすべて削除され、新しいセッションと同じ状態になります。関係のないタスクの文脈を引き継いでしまう「コンテキスト汚染」を防ぐ最も確実な方法です。

/compact — 指示付きで圧縮する

作業を継続しながらコンテキストを軽くしたいときに使います。単に /compact と実行してもよいですが、指示を添えると圧縮精度が上がります。

/compact API設計の決定事項とDBスキーマは保持して、デバッグのやり取りだけ圧縮して

「何を残すか」を指定することで、重要な情報が圧縮で失われるリスクを下げられます。

自動圧縮（Auto-compact）は便利ですが、コンテキストが 83.5% 近くまで膨らんだタイミングで発動するため、すでにモデルが圧迫された状態での圧縮になります。手動で早めに /compact を実行する方が、より良い要約が得られます。

Esc × 2 →「ここから要約（Summarize from here）」 — ピンポイント圧縮

前述の /rewind で触れたオプションですが、コンテキスト管理の観点から改めて説明します。

Esc を 2 回押して巻き戻しメニューを開き、「ここから要約」を選択すると、指定した地点から先の会話を要約してコンテキストを縮小できます。

/compact は会話全体を圧縮しますが、「ここから要約」は任意の地点から先だけを対象にできます。たとえば次のような使い方ができます。

デバッグ中の試行錯誤（失敗した試みの記録）だけを圧縮して、最初の設計議論はそのまま残す
長い調査セッションの後半部分だけを圧縮して、前半の重要な発見は原文のまま保持する

/compact よりも細かく制御できるため、重要な情報を誤って失うリスクを下げられます。

毎ターンが分岐点 — 5 つの選択肢を意識する

Claude Code チームの Thariq 氏の投稿と、それに関連する「セッション管理についてのブログ記事」の中で、Claude が応答を返すたびに 5 つの選択肢があると説明されています。

続行 — そのまま次のメッセージを送る
/rewind — 前のメッセージに戻ってやり直す
/clear — 新しいセッションを始める
/compact — 要約して圧縮する
サブエージェント — 独立したコンテキストで作業を委任する

自然な流れは「続行」ですが、残りの 4 つを意識するだけでコンテキストの質が変わります。ここでは特に重要な 2 つの考え方を紹介します。

修正メッセージより /rewind を使う

Claude にテストを書かせたが、方針が合わなかったとします。つい「モックを使わないで書き直して」と修正メッセージを送りたくなりますが、Thariq 氏はこの場面で /rewind を推奨しています。

修正メッセージを送ると、モックで書いたテストコードやその過程のやり取りがコンテキストにそのまま残ります。これがノイズです。/rewind でテストを依頼した時点まで巻き戻し、「モックは使わず、実際の DB へ接続するインテグレーションテストを書いて」と最初から指示し直せば、失敗した試行がコンテキストに蓄積しません。

失敗の記録から学びだけを残したい場合は、巻き戻しメニューで「ここから要約」を選ぶと、要点だけを圧縮して保持できます。

/compact で失敗しやすいケース

/compact は便利な一方で、圧縮の質が悪くなることもあります。Thariq 氏によると、bad compact が起きやすい状況は「次にやることをモデルの側で予測できないとき」です。

たとえば、長いデバッグセッションの後に自動圧縮が走ると、デバッグの内容が要約の中心になります。その直後に「さっき見えた bar.ts の警告も直して」と指示しても、その警告は要約から落ちている可能性があります。

コンテキストが大きくなるほどモデルの注意力は分散するため、圧迫された状態での自動圧縮はモデルが一番苦手なタイミングで実行されることになります。1M コンテキストの余裕があるうちに、手動で /compact を実行し、何を残すかを指示で明示する方が安全です。

新しいタスクには新しいセッション

もう 1 つ重要な原則があります。Thariq 氏の言葉を借りれば「新しいタスクを始めるなら、新しいセッションも始めるべき」です。

1M トークンのコンテキストがあると、セッションを切り替えずにそのまま別のタスクに取りかかれてしまいます。しかし、前のタスクの文脈が残っていると、それがノイズになります。/clear して、必要な情報だけを最初のメッセージとして伝え直す方が、結果的に速く正確です。

グレーゾーンもあります。たとえば、機能を実装した直後にそのドキュメントを書く場合です。/clear すると Claude はさっき編集したファイルを読み直す必要があり、二度手間になります。関連タスクでコンテキストの再利用に価値がある場合は、続行する判断もあります。

まとめ

この記事で紹介した機能と考え方を振り返ります。

すぐに試せる便利コマンドをまとめます。

/btw: 作業中のサイドクエリ。コンテキストを汚さずに横から質問できる
/autofix-pr: PR のレビューコメントと CI 失敗をクラウドで自動修正する
/voice: スペースバーを押しながら話すだけで音声入力が使える
--bare: スクリプトや CI での実行を最大 10 倍高速化する
!: セッション内からシェルコマンドを直接実行する
/rewind: Esc 2 回で任意の地点に巻き戻す
/rename: セッションに名前をつけて後から探しやすくする
/effort: 推論の深さをセッション単位で設定する。Opus 4.7 では xhigh がデフォルト
/recap: セッションの進捗を 1 行で要約。席を外している間に自動生成される

コンテキスト管理の基本コマンドも整理します。

/context: 現在のトークン使用量を分類別に確認する
/statusline: コンテキスト使用率を常時表示する
/compact: 指示付きで会話を圧縮して作業を継続する
/clear: 別タスクへ移るときに完全リセットする
Esc × 2 →「ここから要約」: 任意の地点から先だけをピンポイントで圧縮する

1つ強調したいのは、コンテキスト管理は機能を覚えることではなく、習慣にすることです。コンテキストの使用率が高くなったら /context で確認する、別のタスクへ切り替えるときは /clear する。この 2 つを意識するだけで、Claude Code からの回答の質が明らかに変わります。

参考リンク

シナジーマーケティング株式会社では一緒に働く仲間を募集しています。

TECHSCORE BLOG

マーケティングSaaS を提供するシナジーマーケティングのエンジニアブログです。