「Claude Codeを使っているけど、もっと効率的な使い方があるのでは？」と思ったことはありませんか。
今回、Claude Codeの開発者であるBoris Cherny氏が、自身の実際のセットアップと使い方をXで公開しました。開発者本人がどのようにClaude Codeを使いこなしているのか、13のテクニックを紹介します。
意外にも「バニラ（デフォルト）に近いセットアップ」とのことで、カスタマイズに迷っている方にとって参考になる内容です。
目次
並列実行で作業効率を上げる
Boris氏の最大の特徴は、複数のClaudeを同時に動かしている点です。ターミナルとWeb、さらにはスマホからも並列でセッションを走らせています。
1ターミナルで5つのClaudeを並列実行
Boris氏はターミナルのタブを1〜5まで番号付けし、それぞれでClaude Codeを動かしています。システム通知を設定しておくことで、どのClaudeが入力待ちになったかをすぐに把握できます。
ターミナルを5つのタブで管理。Claudeが入力を求めると通知が飛ぶ
通知の設定方法は公式ドキュメントで解説されています。iTerm2を使っている場合は、簡単に設定できます。
2claude.ai/codeでさらに5〜10セッションを追加
ローカルのターミナルに加えて、Web版（claude.ai/code）でも5〜10のセッションを並列で走らせているとのこと。ローカルとWebの間で & コマンドや --teleport を使ってセッションを行き来できます。
Web版のClaude Code。セッション履歴が残るので、後から確認しやすい
さらに、毎朝スマホ（iOSアプリ）からもセッションを開始して、後でチェックする使い方もしているそうです。
モデル選択はOpus 4.5一択
どのモデルを使うかは悩みどころですが、Boris氏は明確な方針を持っています。
3Opus 4.5 + Thinkingをすべてのタスクに使用
Boris氏は「これまで使った中で最高のコーディングモデル」としてOpus 4.5を推しています。Sonnetより大きく遅いものの、修正の手間が減るため、結果的に速く終わることが多いとのこと。
“It’s the best coding model I’ve ever used, and even though it’s bigger & slower than Sonnet, since you have to steer it less and it’s better at tool use, it is almost always faster than using a smaller model in the end.”
「ステアリング（軌道修正）の手間が少ない」「ツール使用が上手い」という点がポイント。単純な速度だけでなく、タスク完了までのトータル時間で考えると、大きなモデルの方が効率的な場合も多いようです。
CLAUDE.mdでチームの知見を蓄積する
Claude Codeを継続的に使うなら、CLAUDE.mdの運用が鍵になります。Boris氏のチームでは、これをチーム全体で共有・更新しています。
4チーム共通のCLAUDE.mdをGitで管理
Claude Codeのリポジトリには、チーム共通のCLAUDE.mdが1つだけあり、全員が週に何度も更新しています。Claudeが間違った動作をしたら、「次は同じミスをしないように」とCLAUDE.mdに追記するルールです。
実際のCLAUDE.md。開発ワークフローやコマンド例が記載されている
CLAUDE.mdに書く内容の例として、以下のようなものが挙げられていました。
- 使用するパッケージマネージャー（例：npmではなくbunを使う）
- 型チェック、テスト、リントの実行コマンド
- PRを作成する前に実行すべきコマンド
5コードレビュー中に@claudeでCLAUDE.mdを更新
コードレビュー中に「これもCLAUDE.mdに追加しておいて」というフィードバックがあれば、PRの中で直接 @claude をメンションして更新を依頼できます。GitHub Actionsと連携する形で、Claudeがコメントに反応してCLAUDE.mdを更新してくれます。
PRのコメントで@claudeに依頼すると、自動でCLAUDE.mdを更新してコミット
この仕組みを導入するには、/install-github-action コマンドでGitHub Actionsをセットアップします。
CLAUDE.md運用のメリット
チームで使う場合、「Claudeがやりがちなミス」を全員で共有できます。一度学んだことは次から活かせるので、チーム全体の生産性が上がります。個人で使う場合も、プロジェクトごとにCLAUDE.mdを育てていくと、どんどん精度が上がっていきます。
ワークフローを自動化する
日常的に繰り返す作業は、スラッシュコマンドやサブエージェントで自動化できます。Boris氏は「内部ループ」のワークフローを徹底的に自動化しています。
6Planモードでまず計画を立てる
多くのセッションは、まずPlanモード（shift+tabを2回押す）で始めるとのこと。Pull Requestを書くのが目的なら、Planモードで計画を練って、納得できる内容になったら「自動承認モード」に切り替えて一気に実行します。
Planモードでは、実行前に計画を確認できる
7スラッシュコマンドで繰り返し作業を効率化
毎日何度も行う作業は、スラッシュコマンドとして登録しておきます。たとえば、Boris氏は /commit-push-pr というコマンドを1日に何十回も使っているそうです。
/commit-push-pr でコミット→プッシュ→PR作成を一発で実行
コマンドは .claude/commands/ ディレクトリに保存され、Gitで管理できます。インラインでbashを実行して git status などの情報を事前取得することで、モデルとのやり取りを減らし、高速化しているとのことです。
8サブエージェントで定型ワークフローを自動化
PRを作成するたびに行う定型作業は、サブエージェントとして切り出しています。Boris氏が使っているサブエージェントの例は以下の通りです。
.claude/agents/配下にサブエージェントの設定ファイルを配置
- code-simplifier：Claudeの作業後にコードをシンプルに整理
- verify-app：Claude Codeをエンドツーエンドでテストする詳細な手順
- build-validator：ビルドの検証
- code-architect：コード設計のレビュー
詳しくはサブエージェントの公式ドキュメントを参照してください。
コード品質を自動で担保する
フォーマットやリントは、手動で気にするよりも自動化した方が確実です。
9PostToolUseフックでコードを自動フォーマット
Claudeが生成するコードは基本的に整ったフォーマットですが、残り10%の調整はフックで自動処理しています。これにより、CIでのフォーマットエラーを事前に防げます。
Write/Edit操作後に自動でフォーマッターを実行する設定
設定例を見ると、"matcher": "Write|Edit" で書き込み・編集操作を検知し、bun run format を自動実行しています。|| true を付けることで、フォーマッターがエラーを返しても処理を継続します。
権限管理を最適化する
セキュリティと利便性のバランスは難しいところですが、Boris氏は明確な方針を持っています。
10–dangerously-skip-permissionsは使わない
すべての権限チェックをスキップする --dangerously-skip-permissions は使わず、代わりに /permissions コマンドで安全なコマンドだけを事前許可しています。
/permissionsで許可済みのコマンドを管理。bun run系やgit系を事前許可
許可設定は .claude/settings.json に保存され、チームで共有できます。「このプロジェクトではこれらのコマンドは安全」という判断をチームで共有することで、余計な確認ダイアログを減らしつつ、セキュリティも維持できます。
外部ツールと連携する
Claude Codeの真価は、外部ツールとの連携で発揮されます。
11MCPサーバーでSlack、BigQuery、Sentryと連携
Boris氏はClaude Codeから以下のツールを直接操作しています。
- Slack：検索やメッセージ投稿（MCPサーバー経由）
- BigQuery：分析クエリの実行（bq CLI経由）
- Sentry：エラーログの取得
.mcp.jsonにSlackのMCPサーバー設定を記載
MCP（Model Context Protocol）の設定は .mcp.json に書いて、チームで共有できます。一度設定すれば、「Slackで〜を検索して」「BigQueryでDAUを調べて」といった指示がそのまま実行されます。
長時間タスクを管理する
長時間かかるタスクをどう管理するかは、Claude Codeを使いこなす上での課題の一つです。
12バックグラウンドエージェントやStopフックで自動検証
長時間タスクの場合、Boris氏は以下のアプローチを使い分けています。
- タスク完了時に「バックグラウンドエージェントで検証して」とプロンプトに含める
- Stopフックを使って、より決定論的に検証を実行
- ralph-wiggumプラグインを使う（自動で作業を継続するプラグイン）
1日2時間47分、240万トークンを消費した長時間セッションの例
サンドボックス環境では --permission-mode=dontAsk や --dangerously-skip-permissions を使って、権限確認をスキップすることもあるそうです。本番環境ではセキュリティを優先しつつ、検証環境では効率を優先するという使い分けです。
最重要：検証の仕組みを用意する
Boris氏が「おそらく最も重要」と強調しているのが、この検証の仕組みです。
13Claudeに検証手段を与えると、結果の質が2〜3倍になる
“Probably the most important thing to get great results out of Claude Code — give Claude a way to verify its work. If Claude has that feedback loop, it will 2-3x the quality of the final result.”
実際にBoris氏のチームでは、Claude Codeへの変更を加えるたびに、Claude自身がChrome拡張機能を使ってブラウザを操作し、UIをテストしています。コードが動くか、UXが良いかを確認して、問題があれば修正を繰り返すフローです。
検証の方法は領域によって異なりますが、以下のような選択肢があります。
- bashコマンドの実行結果を確認
- テストスイートを実行
- ブラウザでアプリをテスト（Chrome拡張機能）
- スマホシミュレーターでテスト
＼ Chrome拡張機能でブラウザテストを自動化 ／
Chrome拡張機能の詳細を見るまとめ
Claude Code開発者のBoris氏から学べるポイントを振り返ります。
- 並列実行：ターミナル5つ + Web版5〜10 + スマホで効率化
- モデル選択：Opus 4.5 + Thinkingで修正の手間を減らす
- CLAUDE.md：チームで共有・更新し、知見を蓄積
- Planモード：まず計画を立ててから実行に移す
- スラッシュコマンド：繰り返し作業を自動化
- サブエージェント：定型ワークフローを切り出し
- フック：コード品質を自動で担保
- 権限管理：安全なコマンドだけを事前許可
- ツール連携：Slack、BigQuery、SentryをMCPで統合
- 検証の仕組み：フィードバックループで品質2〜3倍
興味深いのは、Boris氏自身が「意外とバニラに近い」と言っていること。Claude Codeはデフォルトでもよく動くので、過度なカスタマイズは不要かもしれません。
ただし、CLAUDE.mdの運用と検証の仕組みづくりは、どの環境でも効果が出やすいポイントです。まずはこの2つから始めてみるのがおすすめです。
グーグル