Claude Code CLI 高效活用：7つのコツと自動化実践

はじめに

深夜3時、ターミナル画面の光が目に刺さる。画面上で18回目のテスト失敗が走り抜けるのを見つめながら、頭に浮かんだのは一つのこと——/clear というコマンドを早く知っていれば、今夜こんな時間まで起きなくて済んだのに。

正直、かなり悔しかったです。

公式データによると、Claude Code は SWE-bench テストで80.9%のコード問題を自律的に解決できます。すごい数字ですが、問題は——本当にその核心能力を使っているかどうか。周りの友人を観察していて気づいた興味深い現象：多くの人は Claude Code を起動し、claude コマンドを使って、少し話して、コードを修正して、それで終わり。

50以上のコマンドがあるのに、3〜5個しか使っていない。効率ポテンシャルの90%を無駄にしているのです。

この記事では、私が実際に検証した7つの CLI コツと、3つの自動化実践例を紹介します。読んですぐ忘れるようなテクニックリストではなく、シーン別に分類した体系的なメソッド——基本コマンドからコンテキスト管理、Hooks 設定、CI/CD 統合まで。読み終われば、「使える」から「本当に効率的に使える」にレベルアップできるはずです。

---

第一章：CLI基本の三銃士 — 起動、モード、コマンド

まず基礎を固めておけば、後の高度なテクニックも意味を持ちます。

1.1 三つの起動方法、それぞれに用途がある

claude              # 現在ディレクトリで対話インターフェースを起動
claude -c           # 最近のセッションを継続
claude --print "この関数の型定義を確認"  # 単発クエリ後に終了

多くの人は最初の方法しか知りません。実は2番目の -c が特に実用的——セッションを閉じた後、まだ解決していない問題があることに気づいた時、直接 claude -c でさっきのコンテキストに戻れ、プロジェクト背景を最初から説明する必要がありません。

3番目の --print は素早いクエリに使います。型定義が正しいか確認したいとき、一つのコマンドで完了し、完全な対話モードに入る必要がありません。時間を節約できます。

1.2 三つの作業モード、シーンに合わせて切り替え

これは公式ドキュメントの核心概念で、Alibaba Cloud の深掘り記事でも特集されていました：

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

Default モードでは、ファイル変更やコマンド実行のたびに手動確認が必要です。面倒ですが安全。未知のプロジェクトを調査する時に適しています。

Auto-Accept モード——ファイル変更は自動実行、シェルコマンドは依然として確認が必要。自分のプロジェクトで一括リファクタリングをする時、このモードで Claude が一気に変更を完了し、最後に統一的にチェックすれば良い。効率が倍増します。

Plan モードは複雑な問題を分析する時に使っています。Claude にまずプロジェクト全体を読ませ、詳細な実行計画を出力させます。この時は何も変更せず、計画のみ。計画を見て妥当だと思ったら、Auto-Accept モードに切り替えて実行します。

1.3 三つのスラッシュコマンド、必ず覚える

公式には50以上のコマンドがありますが、多くの人は10%も使っていません。この三つを最も頻繁に使っています：

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

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

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

/compact はコンテキストに多くの会話履歴が溜まった時に使います。Claude が重要な情報を保持し、冗長な部分を削除して、トークン消費を節約。同じセッションで何度も修正を繰り返した場合に適しています。

---

第二章：コンテキスト管理の芸術 — クリア、圧縮、並行

この部分は Builder.io の実践記事からヒントを得ました——彼らは /clear を「最大の生産性向上ポイント」と言っていました。1週間試してみて、確かにその通りだと実感しました。

2.1 /clear の正しい使い方

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

タスク切り替え時。

例えば、バグ修正をしていて、Claude と20回やり取りし、問題を特定しました。そこで上司から別の緊急 issue を処理するよう指示されました。多くの人は：同じセッションで話題を切り替えます。

間違いです。

この時、まず /clear でさっきの会話履歴をすべてクリアすべきです。なぜ？それらの履歴会話がトークンを消費し、かつ新しいタスクと完全に無関係だから。Claude は古いコンテキストに「汚染」され、新しい問題の理解品質が低下します。

私の習慣：あるタスクから別のタスクに切り替える時、まず /clear、それから新タスクの背景を簡単に説明。古いセッションで続けるよりも効果が格段に良いです。

2.2 /compact をいつ使うか

同じタスクで何度も修正を繰り返した時——十数個のファイルを変更し、30回以上メッセージを交わした——コンテキストはすでにかなり長くなっています。

/compact はこれらの履歴を圧縮し、重要な情報（変更したファイル、重要な決定）を保持し、冗長な会話を削除します。

いつトリガーするか？大まかなルールを自分に課しています：会話が30回を超えたら compact を1回。厳密でなく、なんとなく「長くなったな」と感じたら圧縮。

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つのターミナルウィンドウで同時に作業可能：一方で Claude に feature-A のコードを書かせ、もう一方で feature-B を処理。2つのセッションは互いに干渉せず、コンテキストは各自独立。

もう一つの実用的なターミナルテクニック：Ctrl+B で長時間実行される bash コマンドをバックグラウンドに移動。Claude が時間のかかる操作（npm install、テスト実行など）を実行中に、セッション画面がブロックされません。

---

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

これまで説明したテクニックはすべて手動。ここからは自動化——Claude が作業している間に、繰り返し作業を勝手にやってくれるように。

3.1 Hooks メカニズム：タスクトリガー

Hooks は Claude Code の自動化の核心。三つの主要タイプがあります：

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 の公式ブログは三つのワークフローを紹介しています：

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

この方向はまだ研究中ですが、可能性はすでに見えています——Claude Code を開発プロセス全体に組み込み、CI/CD パイプラインの一部にする。

---

第四章：実践事例 — 設定から自動化まで

原理を説明したので、実際にどう使うか見てみましょう。

ケース1：一言で git commit 完了

これが私が最も頻繁に使うシーンです。

従来の方法：git add、git status、commit message 作成、git commit。一連の流れで数分。

Claude Code では：

claude
> commit these changes

一言。Claude が現在の変更を自動的に読み取り、適切な commit message を生成してコミット。変更内容を分析し、今回の変更の核心意図を理解し、意味のある 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 が自動的にコードをレビューし、PR の下にコメント。コード品質、潜在的バグ、セキュリティ脆弱性、パフォーマンス問題をチェックできます。

1ヶ月使ってみて、私が手動で見つけるよりも多くのバグを見つけていることに気づきました——サボらないので、すべてのファイルを真面目に見るからです。

---

第五章：生産性倍増テクニック — 設定簡素化とツールチェーン統合

最後のいくつかのテクニックは、Marmelab と Builder.io の記事から学んだもの——ワークフロー全体をよりスムーズにする方法について。

5.1 CLAUDE.md 簡潔哲学

多くの人は CLAUDE.md 設定ファイルを非常に詳細に書きます——プロジェクト背景、技術スタック規約、コードスタイル、禁止事項……びっしり数千文字。

Marmelab のアドバイスは逆：CLAUDE.md を可能な限り短く保つ。

なぜ？設定が長いほど、Claude は「過度に従う」ようになりやすい——毎回の操作で設定を参照し、逆に柔軟性が制限される。しかも長い設定自体もトークンを消費。

彼らが推奨する書き方：最も核心的な3〜5つのルールのみ書き、設定を「コードベースを簡素化する強制関数」として扱う。例えば：

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

これだけで十分です。

5.2 Bash Wrapper 戦略

Builder.io の記事で印象的だった観点：長いドキュメント説明を書かず、bash wrapper スクリプトを書く。

例えば、チームメンバーに素早くプロジェクトを起動させたい時、複雑な README に「まず npm install、次に環境変数を設定、次に dev server を起動」と書くより、直接スクリプトを書く：

#!/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）関連のツール統合。

二つの実用的な例：

Snyk MCP Server：Claude がコードを書く際に自動的にセキュリティ脆弱性と依存関係の問題をチェック。手動で指示する必要がなく、新しい依存関係を導入するたびに自動的にセキュリティスキャンを実行。

rtk ツール：コマンド出力のフィルタリングと圧縮。GitHub に専門のテクニックがあります——多くの CLI コマンドの出力は非常に長く（npm install のログなど）、大量のトークンを消費。rtk でこれらの出力を圧縮し、重要な情報のみ保持。

この2つのツールはまだ完全に統合できていませんが、方向性は明確：Claude Code にコードを書かせるだけでなく、セキュリティチェック、依存関係管理のツールチェーン全体に組み込む。

---

まとめ

いろいろ話しましたが、核心はいくつかのこと：

基本コマンドを確実に——三つの起動方法、三つの作業モード、シーンに合わせて切り替え。最もシンプルなものだけを使わない。

コンテキスト管理をサボらない——タスク切り替え時に /clear、会話が長すぎたら /compact。この二つの習慣で大量のトークン無駄を節約。

自動化は投資する価値がある——Hooks 設定、GitHub Actions 統合、最初は学習に時間を費やすが、後で節約できる時間は倍になる。

設定は簡潔に——CLAUDE.md は短く、複雑なプロセスはスクリプトでカプセル化。ドキュメントが長いほど良いわけではない。

私の提案：

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

Claude Code の設定最適化について深く知りたい場合は、シリーズ第一弾《Claude にコードを勝手に書かせない！設定ファイル一つで AI 精度を10%向上》（CLAUDE.md の書き方）をご覧ください。Subagent メカニズムを知りたい場合は、第二弾《Claude の返答が長すぎる？Subagent で自分専用 AI チームを作る》をご覧ください。この記事はシリーズ第7弾で、CLI コマンドラインのテクニックに焦点。

これらのテクニックは、私が試行錯誤して学んだものです。読み終わった後、少しでも失敗を減らし、早めに効率を上げられることを願っています。