Claude Code CLI 効率活用：7 つのテクニックと自動化実践

ターミナルで 18 回目のテスト失敗を見たとき——/clear コマンドを早く知っていれば、ここまで夜更かししなくて済んだのに。

公式データによると、Claude Code は SWE-bench テストで 80.9% のコード問題を自律的に解決できます。でも本当の問いは——そのコア機能をちゃんと使えているか、ということです。多くの人は Claude Code を起動して claude で少し話し、コードを直して終わり。50 以上のコマンドのうち 3〜5 個しか使わず、効率の 90% を捨てています。

この記事では 7 つの CLI テクニックと 3 つの自動化実践例を、シーン別に体系的に紹介します。基本コマンドからコンテキスト管理、Hooks 設定、CI/CD 連携まで。「使える」から「本当に効率よく使える」へ。

---

第 1 章：CLI 基本の三つ — 起動・モード・コマンド

まず基礎を固めておきましょう。ここができて初めて、後の上級テクニックが活きます。

1.1 3 つの起動方法、それぞれ用途が違う

claude              # カレントディレクトリで対話を開始
claude -c           # 直近のセッションを再開
claude --print "この関数の型定義を確認して"  # 単発クエリ後に終了

多くの人は 1 つ目しか知りません。2 つ目の -c は特に便利です。セッションを閉じたあと「あ、あれ聞き忘れた」と思ったとき、claude -c で直前のコンテキストにそのまま戻れます。プロジェクト背景を一から説明する必要がありません。

3 つ目の --print はクイック確認向け。型定義が合っているか確認したいとき、1 コマンドで済み、フル対話モードに入る必要もありません。時間の節約になります。

1.2 3 つのワークモード、シーンで切り替える

これは公式ドキュメントのコア概念で、Alibaba Cloud（アリババクラウド）の深掘り記事でも詳しく触れられています。

モード	安全性	適したシーン
Default（デフォルト）	高	新規プロジェクトの探索、不確かな操作
Auto-Accept	中	慣れたコードベース、一括修正
Plan	最高	問題分析、方針策定

Default モードでは、ファイル変更やコマンド実行のたびに手動確認が必要です。面倒ですが安全。馴染みのないプロジェクトを把握するとき向けです。

Auto-Accept モードではファイル変更は自動実行、shell コマンドは引き続き確認が必要です。自分のプロジェクトで一括リファクタリングするとき、Claude が一気に直し切って、最後にまとめてチェックできます。効率は倍増します。

Plan モードは複雑な問題の分析に向いています。Claude にプロジェクト全体を読ませ、詳細な実行計画を出力させます。この段階では変更は行わず、計画だけ。内容を確認して問題なければ、Auto-Accept に切り替えて実行します。

1.3 覚えておくべき 3 つのスラッシュコマンド

公式 50 以上のコマンドのうち、多くの人は 10% 未満しか使いません。私が最も使う 3 つはこちらです。

/init     # プロジェクトをスキャンして CLAUDE.md を生成
/clear    # セッション履歴をクリア
/compact  # コンテキストを圧縮してトークンを節約

/init は新しいプロジェクトで初めて起動するときに使います。Claude がコードベース全体をスキャンし、構造・依存・規約をまとめた設定ファイルを生成します。以降の操作はこの設定を参照します。

/clear は後述しますが——私が見つけた最大の効率向上ポイントです。

/compact は会話履歴が積み上がったときに使います。Claude が重要情報を残し、冗長な部分を削ってトークン消費を抑えます。同じセッションで何度も修正を重ねたときに向いています。

---

第 2 章：コンテキスト管理 — クリア・圧縮・並列

この章は Builder.io の実践記事から得たヒントです。彼らは /clear を「最大の生産性向上ポイント」と呼んでいます。1 週間試してみて、本当にその通りだと実感しました。

2.1 /clear の正しい使い方

いつセッションをクリアするか？

タスクを切り替えるとき。

たとえばバグ修正で Claude と 20 ラウンド会話し、原因を特定した直後。上司から別の緊急 issue 対応を命じられた——多くの人は同じセッションで話題を切り替えます。

それは間違いです。

このとき先に /clear して、さきほどの会話履歴をすべて消すべきです。なぜか。履歴はトークンを消費し、新しいタスクとは無関係だからです。古いコンテキストに「汚染」されると、新しい問題の理解精度が下がります。

私の習慣：タスクを切り替えるたびに /clear し、新しいタスクの背景を簡潔に説明する。古いセッションをそのまま続けるより、はるかに効果的です。

2.2 /compact をいつ使うか

同じタスクで何度も修正を重ね——十数ファイルを直し、30 件以上メッセージを交わした——コンテキストはかなり長くなっています。

/compact は履歴を圧縮し、変更したファイルや重要な判断は残し、冗長な会話は削ります。

トリガーの目安：会話が 30 件を超えたら一度 compact する。厳密でなくてよく、「少し長くなってきた」と感じたら圧縮すれば十分です。

2.3 並列セッション戦略

このテクニックは Claude 公式 Help Center 由来です。3〜5 個のセッションを同時に走らせ、それぞれ異なる git worktree でコードベースの別パートを担当します。

git worktree とは？同じリポジトリから複数の作業ディレクトリを作り、各ディレクトリで別ブランチに切り替えられる仕組みです。

# worktree を作成
git worktree add ../feature-A feature-branch-A
git worktree add ../feature-B feature-branch-B

# 各 worktree で Claude を起動
cd ../feature-A && claude
cd ../feature-B && claude

2 つのターミナルで同時に作業できます。一方で feature-A のコードを書かせ、もう一方で feature-B を処理。セッションは互いに干渉せず、コンテキストも独立します。

実用的なターミナルテクニックも：Ctrl+B で長時間実行の bash コマンドをバックグラウンドに移せます。Claude が npm install や長時間テストを走らせているあいだ、セッション画面がブロックされません。

---

第 3 章：自動化の三要素 — Hooks・Routines・CI/CD

ここまでのテクニックは手動操作でした。この章からは自動化——Claude が作業しているあいだに、繰り返し作業を代わりにこなしてもらいます。

3.1 Hooks 機構：タスクトリガー

Hooks は Claude Code 自動化の中核です。主な 3 タイプがあります。

Hook タイプ	トリガー	典型的な用途
PreToolUse	ツール実行前	権限チェック、パラメータ前処理
PostToolUse	ツール実行後	テスト自動実行、コードフォーマット
Notification	通知イベント	Slack 送信、ログ記録

最も実用的なのは PostToolUse です。hook を設定すれば、Claude がコードを直すたびにテストが自動実行されます。

// settings.json の設定例
{
  "hooks": {
    "PostToolUse": [{
      "command": "npm test",
      "timeout": 60000
    }]
  }
}

この設定の効果：Claude が Write ツールでファイルを変更するたびに npm test が走ります。テストが失敗すれば Claude は出力を見て、自分で修正します。

3.2 Routines：繰り返しフローの定義

Routines は繰り返し現れるタスクフローの定義に向いています。

公式ドキュメントの例：Claude が特定条件（たとえばあるファイルの存在）を検知したら、あらかじめ設定した一連のコマンドを自動実行する、という使い方です。

設定はやや複雑で、私はまだ本番環境で大規模には使っていません。ただ方向性は有望です——「毎回やるチェック」を固定化し、毎回 Claude に手動でリマインドしなくて済むようにする。

3.3 CI/CD 連携：GitHub Actions 実践

公式が提供する headless モード：claude -p。

GitHub Actions 上で使えば、Claude が PR review、issue 実装、セキュリティ監査を自動処理できます。

# .github/workflows/claude-review.yml
name: Claude Code Review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Review
        run: claude -p "Review this PR and suggest improvements"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

GitLab の公式ブログでは 3 つのワークフローを紹介しています。

1. issue から MR を作成
2. パフォーマンス退行を分析
3. 機能を直接実装し CI で検証

この方向はまだ研究中ですが、ポテンシャルは見えています——Claude Code を開発フロー全体に組み込み、CI/CD パイプラインの一部にする、ということです。

---

第 4 章：実践ケース — 設定から自動化まで

原理は説明しました。実際の使い方を見ていきましょう。

ケース 1：一言で git commit

私が最もよく使うシーンです。

従来：git add、git status、commit message を書く、git commit。一連の流れで数分。

Claude Code なら：

claude
> commit these changes

一言です。Claude が現在の変更を読み取り、適切な commit message を生成してコミットします。diff を分析し、今回の変更の意図を理解したうえで、意味のある message を書きます。

実測では、生成される message の質は自分で書くより上——diff を本当に読んでいるから、適当には書きません。

ケース 2：PostToolUse Hook でテスト自動実行

先ほどの hook 設定の完全版です。

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "command": "npm run test:related",
        "timeout": 30000
      }
    ]
  }
}

matcher: "Write" は Write ツール（ファイル変更）だけを監視します。npm run test:related は私が定義したコマンドで、変更ファイルに関連するテストだけを実行——全量テストではなく、かなり速いです。

効果：Claude がコードを直すたびに 30 秒以内でテスト結果が見えます。失敗すれば Claude が出力を受け取り、自動で修正します。

ハマった点：最初は全量テスト npm test を設定していました。遅すぎてタイムアウトが頻発。関連ファイルだけに絞ったら解決しました。

ケース 3：GitHub Actions で PR Review 自動化

この設定は公式ドキュメント由来です。

# .github/workflows/claude-pr-review.yml
name: Claude PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}

      - name: Claude Review
        uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Review this PR for:
            - Code quality issues
            - Potential bugs
            - Security vulnerabilities
            - Performance concerns
          api_key: ${{ secrets.ANTHROPIC_API_KEY }}

この workflow は PR 作成・更新時にトリガーされ、Claude がコードを review して PR にコメントします。コード品質、潜在的なバグ、セキュリティ脆弱性、パフォーマンス問題をチェックします。

1 ヶ月使ってみて、手動 review より多くのバグを拾ってくれました——サボらず、すべてのファイルを丁寧に見てくれるからです。

---

第 5 章：生産性を倍増させるテクニック — 設定の簡素化とツールチェーン連携

最後に、Marmelab と Builder.io の記事から学んだ、ワークフロー全体をスムーズにするコツです。

5.1 CLAUDE.md は短く

多くの人は CLAUDE.md を詳細に書きます——プロジェクト背景、技術スタックの約束、コードスタイル、禁止事項……数千字に及ぶことも。

Marmelab の提案は逆です：CLAUDE.md はできるだけ短く。

なぜか。設定が長いほど Claude は「過度に従いすぎ」——毎回設定を引っ張り出し、柔軟性が下がります。長い設定自体もトークンを消費します。

推奨される書き方：コアな 3〜5 条だけ。設定は「コードベースを簡素化する強制関数」と考える。例：

# CLAUDE.md
- TypeScript 厳格モード、すべての変数に型を付ける
- コンポーネントファイルは src/components/ に置く
- テストファイルはソースと同じディレクトリに置く
- var は使わず const と let のみ

これで十分です。

5.2 Bash Wrapper 戦略

Builder.io の記事で印象的だったのは、長いドキュメントを書くより bash wrapper スクリプトを書け、という考え方です。

チームメンバーにプロジェクトを素早く起動してもらうなら、複雑な README で「まず npm install、次に環境変数、それから dev server」と書くより、スクリプトを 1 本用意する方が早い。

#!/bin/bash
# dev.sh - 開発環境を素早く起動

npm install
source .env.local
npm run dev

Claude Code では「run dev.sh」と言うだけ。シンプルで、考える必要がありません。

Claude 自体にも応用できます。よく使うコマンドの組み合わせを alias や script にまとめ、毎回長いコマンドを打たなくて済むようにする。

5.3 MCP Server 連携：セキュリティチェックと出力フィルタ

最後は MCP（Model Context Protocol）関連のツール連携です。

2 つの実用例：

Snyk MCP Server：Claude がコードを書くあいだに、セキュリティ脆弱性と依存関係の問題を自動チェック。手動でリマインドしなくても、新しい依存を入れるたびにセキュリティスキャンを走らせます。

rtk ツール：コマンド出力のフィルタと圧縮。GitHub 上のテクニックでも触れられています——npm install のログなど、多くの CLI 出力は非常に長く、大量のトークンを消費します。rtk は出力を圧縮し、重要な情報だけ残します。

2 つともまだ完全には統合できていませんが、方向性は明確です——Claude Code をコードを書くだけのツールではなく、セキュリティチェックや依存管理のツールチェーン全体に接続する。

---

まとめ

要点はシンプルです。

基本コマンドを固める——3 つの起動方法、3 つのワークモードをシーンで切り替える。いつも一番簡単な方法だけ使わない。

コンテキスト管理を怠らない——タスク切り替え時は /clear、会話が長くなったら /compact。この 2 つの習慣で、大量のトークン浪費を防げます。

自動化に投資する価値がある——Hooks 設定、GitHub Actions 連携。最初に学ぶ時間をかければ、後から節約できる時間は何倍にもなります。

設定は簡潔に——CLAUDE.md は短く、複雑なフローはスクリプトに。長いドキュメントが必ずしも正解ではありません。

おすすめのアクション：

1. 今日すぐ試す：現在のセッションで /clear を入力し、クリア後のすっきり感を体験する
2. 今週のタスク：PostToolUse hook を 1 つ設定し、Claude がコードを直すたびにテストを自動実行させる
3. 長期目標：Claude Code を CI/CD フローに組み込み、チームの標準ツールにする

Claude Code の設定最適化を深く知りたいなら、シリーズ第 1 篇『もう Claude に適当なコードを書かせない！設定ファイル 1 つで AI の精度を 10 倍に』（CLAUDE.md の書き方）をどうぞ。Subagent 機構については第 2 篇『Claude の返答が冗長すぎる？Subagent で専属 AI チームを作る』を参照してください。本記事はシリーズ第 7 篇で、CLI コマンドラインのテクニックに特化しています。

これらのテクニックは、すべて試行錯誤の末に身につけたものです。この記事が、あなたのハマりどころを減らし、早く効率を引き上げる助けになれば幸いです。