Claude Code ターミナル：パワーユーザーのためのワークフロー強化 7 選

素の Claude Code でも、すぐに役に立ちます。インストールして、プロンプトを投げれば、望むものを作ってくれる。多くの人にとってはその“バイブコーディング”のセットアップで十分に機能します。

一方で、端末を自分流にカスタマイズして使っている人の Claude Code は、もはや別物です。信頼できる bash コマンドを事前承認しておけば、Claude はほとんど権限を尋ねてきません。プロジェクトのルートには CLAUDE.md があり、セッションを開いた瞬間から Claude はそのプロジェクトの作法を把握しています。セッションが混乱してきたときに手に取るコマンドも、再起動ではありません。

この記事は、その2つのセットアップの間を埋める7つのアップグレードです。どれも設定に10分とかかりませんが、1週間以内に投資回収できます。

Claude Code をまだ一度も開いたことがない場合は、Claude Code のメインガイドから始めてください。以降は、すでにプロンプトとツール呼び出しを扱えることを前提にしています。

1. 同じコマンドの再承認をやめる

デフォルトでは、新しいツール呼び出しのたびに承認を求められます。初回の pytest はそれで良いのですが、3回目には煩わしく、10回目にはプロンプトを読まずに Enter を連打してしまいます。これは最悪の状況です。安全確認を無視するよう自分を訓練してしまううえ、速度も落ちたままだからです。

もちろん「危険だが権限確認をバイパス」するモード、つまり「自動モード」もあります。そのトレードオフについては、Claude Code の自動モードとチャンネルに関するチュートリアルで詳しく扱いました。

settings.json ファイルで権限を定義する

解決策は、プロジェクトのルートに .claude/settings.json を置き、permissions ブロックで信頼できるパターンを事前承認し、信頼できないものをブロックすることです：

{
  "permissions": {
	"allow": [
  	"Bash(pytest *)",
  	"Bash(uv run *)",
  	"Bash(ruff check *)",
  	"Read(~/.zshrc)"
	],
	"deny": [
  	"Bash(curl *)",
  	"Read(./.env)",
  	"Read(./.env.*)",
  	"Read(./secrets/**)"
	]
  }
}

ルールは固定の順序で評価されます。まず deny、次に ask、最後に allow。最初に一致したものが優先されるため、deny は常に後続の allow より強く適用されます。

スコープとワイルドカードを使いこなす

初めてこれを書いたときに多くの人がつまずく点が3つあります。

1. まずはスコープ。プロジェクトの .claude/settings.json はグローバルの ~/.claude/settings.json を上書きします。つまり、グローバルで Bash(rm *) を許可していても、プロジェクトで deny していればプロジェクトが勝ちます。正しいデフォルトですが、グローバルの allow が固定だと思っていると驚くはずです。

2. 次にネットワーク系コマンドのワイルドカード。 Bash(curl http://github.com/ *) は制限しているように見えて、https://、URL の前のオプション、リダイレクト、シェル変数展開を拾いません。ドキュメント推奨のパターンは、まず Bash(curl *) を全面的に deny すること。そのうえで、許可したいドメインに対しては WebFetch(domain:github.com) のように WebFetch ツールを使います。

3. 3つ目は空白。 Bash(ls *) は ls -la に一致しますが、lsof には一致しません。 Bash(ls*) なら両方に一致します。アスタリスクの前のスペースは“効いている”ので、どちらを書いたかは意図的に選びましょう。

端末との“戦い”をやめる、という意味では、権限ルールと並んで覚えておきたいキーバインドがいくつかあります。

• Shift+Tab で権限モードを循環（デフォルト、自動承認、プラン）

• Esc+Esc で巻き戻しピッカーを開く（#3 参照）

• Ctrl+R でプロンプト履歴を逆検索（bash や zsh と同様）

• Ctrl+U でカーソル位置から行頭まで削除

• Shift+Enter でプロンプト内に改行を挿入

これらの多くは、ほとんどのターミナルでそのまま動作します。もし動かない場合は、一度 /terminal-setup スラッシュコマンドを実行してセットアップしてください。

2. Claude Code にプロジェクトを覚えさせる

各セッションは新しいコンテキストウィンドウから始まります。

デフォルトでは、Claude は pip ではなく uv を使っていることを覚えていません。テストが test/ ではなく tests/ にあることも覚えていません。昨日10ターンかけて説明した API の作法も消えています。これを解決するのが、プロジェクトルートの CLAUDE.md です。そのディレクトリ（またはサブディレクトリ）から Claude Code を起動すれば、最初のプロンプトの前に自動で読み込まれます。

最速の始め方は /init。プロジェクト内で実行すると、Claude がコードベースを読み、ビルドコマンド、テスト手順、推測できる作法を盛り込んだ初期版 CLAUDE.md を生成します。これは“完成品”ではなく“動く初期値”なので、その後に編集してください。

Claude がコンテキストを探す場所は3つあり、積み重ねで使われます。

プロジェクト CLAUDE.md は ./CLAUDE.md に置き、リポジトリに同梱します。全メンバーで共通なので、プロジェクト固有の事実を書きます。

• パッケージマネージャと使用言語のバージョン
• テストの実行コマンドとテスト配置場所
• ディレクトリ構成と、分かりづらい作法
• 新メンバーが初日に知っておくべきこと

ユーザー CLAUDE.md は ~/.claude/CLAUDE.md に置き、マシン上のあらゆるプロジェクトにまたがって使われます。個人的な嗜好、たとえばコーディングスタイル、好みの docstring 記法、まず使う言語などはこちらへ。プロジェクトの事実は書かないでください。ほかのリポジトリにも“にじみ出て”しまいます。

自動メモリ は3つ目で、Claude 自身が書き込みます。セッション中に（「ここでは snake_case で、camelCase は使いません」など）修正を入れると、~/.claude/projects/<project>/memory/MEMORY.md にログが残ります。その最初の200行または25KB が、同一プロジェクトの会話開始時に毎回読み込まれます。読み込まれた内容は /memory で確認でき、自動メモリのオン／オフも切り替えられます。

ボリュームに関する基準：CLAUDE.md はそれぞれ200行未満に保ちましょう。超えると各ターンでのコンテキスト消費が目立ち始め、長文は短文に比べて追従性が落ちます。肥大化してきたら、.claude/rules/ にパススコープ付きで分割してください。CLAUDE.md に何を書くべきかの詳説は、拙稿 最高の CLAUDE.md を書くチュートリアル を参照してください。

3. セッションが不調でも、再起動をやめる

セッションの調子が悪いときの反射は /clear でやり直すことですが、多くの場合それは間違いです。再開すると、Claude が編集していたファイルパス、追っていた失敗テスト、冒頭で伝えた制約などが捨てられます。新しいセッションはそれらを再学習する必要があり、トークンと時間のコストを払うことになります。

まず覚えるべきは症状です。こうしたコンテキストの腐敗は、次のようなサインで分かります。

• 数ターン前に編集したファイルパスを Claude が再度聞いてくる
• すでに却下した提案を繰り返す
• 現在のブランチを見失う
• 同じポイントを1セッションで2回以上訂正した

それらが見えたら、選択肢は4つあります。しかも相互に置き換えられるわけではありません。

セッションを圧縮する

 /compact は、一部のユーザーが言うほど悪くありません。

プロジェクトの CLAUDE.md は圧縮後も生き残ります。Claude は圧縮後にファイルを再読込して再注入するので、作法が失われません。さらに、/compact keep the auth refactor decisions, drop the failed test runs のように要約の焦点を指示できます。これが、役立つ要約と凡庸な要約の差になります。

Claude Code の「取り消し」を使う

Esc+Esc の巻き戻しピッカーは、大半の人が存在を知りません。セッション内のすべてのプロンプトチェックポイントの一覧が開き、選ぶと「会話のみ」「コードのみ」「両方」の3つから復元方法を選べます。

多くの人が欲しいのは「コードと会話を復元」です。30分の悪いターンが、git を触らずに消えます。セッション全体に対する取り消しに最も近い機能です。

再起動をやめられたら、次の課題はセッションの再発見です。

セッションに名前を付けて再オープンする

claude -n <name>（または --name）は名前付きセッションを開始し、名前は /resume とターミナルタイトルに表示されます。同じリポジトリで3つの作業（実験ブランチ、リファクタ、デバッグ）を並行するなら、名前が識別の手がかりです。途中でスコープが変われば /rename で変更できます。

小ワザ：同一ウィンドウで複数セッションを走らせるときは /color でさらに識別しやすくできます。

セッションの再オープンは2つのフラグを使います。 claude --continue（または -c）は、現在のディレクトリで最も最近の会話を読み込みます。直前まで作業していて、その続きに使います。

claude --resume はインタラクティブなピッカーを開き、claude --resume <name-or-id> なら特定セッションへダイレクトに飛びます。セッションは git ブランチのように扱ってください。作業ストリームごとに分ける価値があります。

4. 難しい作業は計画、簡単な作業は節約

カスタム環境で最大のコスト要因は、エディタやキーバインドではありません。タスクの難易度に合わせて計算資源の投入量を適切に合わせることです。これに効くのが3つのツール、プランモード、/effort、そして /model です。

Claude Code のプランモードを使う

プランモードは、ファイルに触る前にアプローチを検討するよう Claude に指示します。計画を書き、あなたが読み、承認または差し戻し、その後にのみ実行します。

私が計画を堅牢にするためによく使う簡単なプロンプトがあります。

Red-team this plan from multiple angles using as many Opus 4.7 agents as you need.

これにより複数のサブエージェントが起動し、計画を多角的にレビューして修正提案を行います。500行を超える計画ファイルに取り組むときのよい実践です。

コストとしては、計画とレッドチームでコードが落ちる前に2ターン増えるため、大きな機能やバグ修正でない限りはオーバーヘッドになります。

プランモードに入る方法は5通りあります。

インライン形式（/plan refactor the auth module to use JWT）は見落とされがちです。モードとタスクを一度で設定でき、二手を一手に短縮します。レビュー優先のプランワークフローの詳細は、Claude Code プランモードのチュートリアルでステップごとに解説しています。

適切なエフォートレベルを設定する

次に学ぶのはエフォートです。各ターンで Claude がどれだけ拡張思考を行うかを制御します。高いほど推論は深く、トークン消費は増え、応答は遅くなります。

/effort <level> と --effort <level> フラグは5段階すべてを受け付けます。low、medium、high、xhigh はセッションをまたいで保持されます。max はトークン消費制約を外すためセッション限定で、毎回意図的に設定します。日常の既定値は low または medium が適切です。 high や xhigh は本当に難しい課題に、max は“間違うくらいならトークンを燃やす”という場面に取っておきましょう。

ただし注意点を1つ。コンテキストが優れていれば、低エフォートのモデルが、悪いコンテキストの最大エフォートより勝つことがよくあります。エフォートを上げるより、プロンプトを整えるほうが効果的なことが多いです。

適切なモデルを選ぶ

モデル選択こそが、本当のコスト削減ポイントです。 /model はセッション中に切り替えられ、Option+P（macOS）/ Alt+P（Win/Linux）なら、入力中のテキストを消さずに切り替えられます。覚えておきたいエイリアス：

• sonnet は日常使いのデフォルト

• opus は最難関の課題向け（best エイリアスも opus を指します）

• haiku は速度重視のとき

• sonnet[1m] と opus[1m] は 1M コンテキスト版

• opusplan は計画を Opus、実行を Sonnet で行う構成

• default は上書きを解除し推奨モデルに戻す

常に Opus をデフォルトにしているなら、日中の大半を Sonnet に切り替えるのが、最も大きなコスト削減になります。

行き詰まった難題には、最も賢いモデルである Opus が適任です。それ以外のほとんどは Sonnet で十分にこなせます。両者のコスト差は大きく、「念のため常に Opus」は、自動操縦に残してはいけない最も高くつく習慣です。

5. 手作業を自動化する

摩擦がなくなったら、次はまだ手でやっている作業の層です。

スケジュールタスク

自動化した方が、しない理由を探すより簡単です。ほとんどをカバーするのは2つ、/loop（本来なら張り付きで見守る定期チェック）と、CLAUDE.md の指示では保証できないことを担保するフックです。

/loop は、プロンプトやスラッシュコマンドを定期スケジュールで再実行します。シンタックスは2通り：

• /loop 5m <prompt> は5分ごとにプロンプトを実行

• /loop <prompt> 単体なら、実行間隔の決定をモデルに委ねる

間隔の単位は s、m、h、d で、最小は1分。Claude Code v2.1.72 以降が必要です。

例えば、テスト監視を設定できます： /loop 2m run the test suite and report failures。変更のたびにテスト実行を“覚えておく”（そして半分は忘れる）代わりに、Claude が2分ごとのタイミングでテスト失敗を知らせてくれます。

同じパターンでステージングのデプロイ監視（/loop 10m check if the staging deploy is green）や、不安定なインシデント中のログ追跡（/loop 1m tail the last 50 lines of app.log and flag errors）も可能です。

ループの寿命は7日です。

7日目に最後の1回が実行され、自動で削除されます。ループはセッションスコープなので、--continue や --resume で閉じた後も復活します。途中で止めるには Esc。セッションをまたいでも存続する（毎晩のチェック、週次ダイジェストなど）スケジューリングが必要なら、代わりに /schedule で Routines を使ってください。

フック

フックはもう半分の解です。Claude のワークフローの特定ポイントでシェルコマンドを走らせます。設定は .claude/settings.json に記述します。

CLAUDE.md の指示ではなくフックを使う理由は1つ。CLAUDE.md は助言的で、フックは必ず実行されるという点です。典型は「編集後に常にリンターを回す」という規則。Claude が半分はスキップするような場合でも、フックなら抜け漏れを塞げます。

イベントは6つで大半をカバーできます。

最小構成の PostToolUse フック（ファイル編集のたびにリンターを回す）：

{
  "hooks": {
	"PostToolUse": [
  	{
    	"matcher": "Edit|Write",
    	"hooks": [
      	{ "type": "command", "command": "/path/to/lint-check.sh" }
    	]
  	}
	]
  }
}

覚えておくべき落とし穴が1つ。Claude をブロックするのは終了コード 2 のみです。終了コード 1 は非ブロッキングエラーとして扱われ、Unix では一般的に失敗コードであっても、Claude は処理を続行します。ルールを強制したいフックの場合は 2 を返してください。

なお、フックを手書きする必要はありません。

「ファイル編集のたびに ruff を実行するフックを書いて」とプロンプトすれば、Claude が JSON を下書きしてくれます。/hooks は有効なフック設定をすべて一覧表示するため、想定外の発火があっても設定ファイルを grep せずに確認できます。全イベントカタログと stdin/stdout の JSON スキーマについては、拙稿 Claude Code フックのチュートリアル を参照してください。

6. コストを常に把握する

ループ、長時間のセッション、常時 Opus は、いずれもトークンを燃やします。3つのコマンドで支出を可視化し、重要なのは“設定”ではなく“チラ見して習慣化”することです。

/usage はプラン階層、セッション合計、モデル別のコスト内訳、5時間および週次のレート制限ウィンドウの進捗バーを表示します。

/context は現在のコンテキストウィンドウを色分けグリッドで可視化し、容量警告と、どのツールやファイルがスペースを食っているかの示唆を出します。セッションが重く感じられ、/compact と /clear のどちらにすべきか迷うときに使います。

/statusline はターミナル下部に常時表示のバーを設定します。モデル、コンテキスト使用率、レート制限ウィンドウ、その他セッション JSON から読み取れるものを表示可能です。コスト関連の数字を作業中の視界の端に置けるため、行動を最も変えるコマンドです。

/statusline を実行して、表示したい内容を自然言語で伝えれば、Claude がスクリプトを生成し設定を更新します。もう1つの方法は、シェルスクリプトを自分で書き、~/.claude/settings.json から参照することです。

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

より長期のセッション横断トラッキングには、npx ccusage というコミュニティツールがあります。これはサードパーティ製（Anthropic 製ではありません）ですが、セッション単位の /usage と月次請求の間を埋めてくれます。

7. 知っておくと役立つ3つの機能

上の6つは私が毎日使うもの。以下の3つは使用頻度は低めですが、“必要なその日”に取り出せるよう、存在は知っておくべき機能です。

/voice でプッシュ・トゥ・トーク

/voice でプッシュ・トゥ・トークの音声入力が有効になります。 Space を押しながら話し、離すと、文字起こしされたテキストがプロンプトに入ります。v2.1.69 以降が必要で、20言語に対応しています。

歩きながら考えを声に出すときや、タスク開始時にまだ文言が固まっていない意図を口述する場面では、音声のほうが打鍵に勝ります。行単位の修正のような、たとえば「47行目を…」といった操作には打鍵のほうが向いています。

/teleport でクラウドセッションを引っ張る

/teleport（エイリアス /tp）は、クラウド上のセッションをローカルのターミナルに取り込みます。Web アプリや iOS アプリで長時間タスクを始め、今はラップトップに戻ってきた、という状況で便利です。 claude --teleport を実行するとピッカーが開き、適切なブランチがチェックアウトされた状態で、そのセッションをターミナルに着地できます。

いくつかの要件が揃っている必要があります。

• git の作業ツリーがクリーン
• 該当リポジトリである
• クラウドセッションと同じ claude.ai アカウント
• ブランチがリモートへ push 済み

--teleport と --resume を混同しないでください。後者はこのマシンのローカル履歴からしか再オープンしません。詳しい手順は、当社の Claude Code リモート操作チュートリアル をご覧ください。

/btw で横道の質問をする

/btw は、流れを壊さずに投げたい短い質問のためのコマンドです。

Claude が作業の真っ最中。長い編集やツール呼び出しを走らせている間に、IP をマッチさせる正規表現や、あるフラグの意味をすぐに知りたくなったとします。

そんなときは /btw <question> と打つだけ。回答は閉じられるオーバーレイで表示され、進行中のタスクはそのまま走り続けます。回答は会話履歴に入らないため、単発の調べ物に新しいセッションを作る必要もなく、今のセッションを汚しません。

結論

この記事の内容を一日で全部試すのは、最短で元に戻る方法です。2〜3個を選び、それらの筋肉記憶を作ってから、残りは最初のセットが自動化されたころに足してください。

最初に選ぶなら、この3つ。いずれも一日の別の場面を担当するので、互いに干渉しません。

• 引き締まったプロジェクト CLAUDE.md と、毎セッションで再承認している bash コマンド用に、.claude/settings.json に2〜3個のワイルドカード権限ルール。これは朝のセットアップ習慣で、遮られなくなって初めて効果を実感します。

• /compact と /clear の使い分け、そして Esc+Esc の巻き戻しピッカー。これはセッション中盤の習慣で、合図は“1時間前に知っていたファイルパスを Claude が再度聞いてきた瞬間”です。

• 時間を取られている定期チェックを1つ、/loop で自動化。これは背後で回る習慣で、一度走り始めれば勝手に回収してくれます。

Sonnet、Opus、Haiku の違いがまだあいまいなら、 Introduction to Claude Models コースが、各モデルの使いどころを解説します。そうなれば /effort や /model の判断がずっと楽になります。