この記事を読むべき人
あなたはClaude Codeを「普通に」使っていないだろうか？
ターミナルを開いて、プロンプトを打って、返答を待つ。それを繰り返す。
もしそうなら、あなたはClaude Codeの本来の力の10%も引き出せていない。
2026年1月、Claude Codeの生みの親であるBoris Cherny氏（Anthropic Staff Engineer）が、社内チームだけで共有されていた10個の内部プラクティスをXで公開した。
このスレッドは公開からわずか数時間で開発者コミュニティを震撼させた。なぜなら、そこに書かれていたのは「ドキュメントに載っていない」実戦で磨かれた技術だったからだ。
この記事では、そのスレッドを徹底解剖し、日本語で完全解説する。
この記事の内容を実践した開発者からは「生産性が3-5倍になった」という報告が相次いでいる。一度この使い方を知ると、もう元には戻れない。
1. Git Worktreeによる並列処理 - 「1セッション1タスク」は時代遅れ
これがBoris氏が「最も効果が高い」と断言したプラクティスだ。
ほとんどのユーザーは、1つのターミナルで1つのClaudeセッションを動かしている。Boris氏のチームは違う。
# 3-5個のworktreeを同時に走らせる
git worktree add ../project-a feature-a
git worktree add ../project-b feature-b
git worktree add ../project-c bugfix-c
各worktreeで独立したClaudeセッションを起動する。
つまり、あなたが1つのタスクを待っている間に、別のClaude達が別のタスクを進めている。
実践テクニック
Anthropicの内部チームは、シェルエイリアスを設定している：
# ~/.zshrc に追加
alias za='cd ~/worktrees/project-a && claude'
alias zb='cd ~/worktrees/project-b && claude'
alias zc='cd ~/worktrees/project-c && claude'
zaと打つだけで、worktree Aに移動してClaudeが起動する。
さらに、彼らは「分析専用worktree」を持っている。ログ解析やクエリ実行など、メインの開発フローを邪魔しないための専用空間だ。
なぜこれが効くのか？
Claude Codeは各セッションで独立したコンテキストを持つ。worktreeを分けることで、Gitの競合を防ぎながら、複数のClaudeを「チーム」として働かせることができる。
2. Plan Modeの本当の使い方 - 1発で実装を決める技術
「複雑なタスクは、まずPlan Modeに投資せよ」
これがBoris氏の教えだ。
多くのユーザーはPlan Modeを「なんとなく」使っている。しかし、Anthropicの内部では明確な戦略がある。
2段階レビューシステム
1. Claude A: 計画を作成
2. Claude B: その計画をスタッフエンジニアとしてレビュー
そう、Claudeに自分の計画をレビューさせるのだ。
あなたはスタッフエンジニアです。以下の実装計画をレビューしてください。
セキュリティ、パフォーマンス、保守性の観点から問題点を指摘してください。
[計画をペースト]
問題が見つかったら？即座にPlan Modeにリセットする。
実装の途中で「これ違うかも」と思った瞬間、Shift+Tabを2回押してPlan Modeに戻る。中途半端なコードを書き続けるより、計画を練り直す方が圧倒的に速い。
3. CLAUDE.mdの進化的運用 - AIを「学習」させる
これは多くの人が見落としている、最も重要なプラクティスかもしれない。
Boris氏のチームでは、Claudeがミスをしたとき、こう指示する：
「CLAUDE.mdを更新して、同じミスを繰り返さないようにして」
これだけだ。しかし、この一言が決定的な違いを生む。
実際の運用フロー
# CLAUDE.md
## 過去のミスと対策
### 2026-01-15: APIレスポンスの型定義漏れ
- 問題: 新しいエンドポイント追加時に型定義を忘れた
- 対策: APIエンドポイント追加時は必ず types/ ディレクトリの更新を確認する
### 2026-01-20: テストのモック不足
- 問題: 外部API呼び出しのモックを忘れてCIが失敗
- 対策: 外部依存がある場合は必ずモックを作成する
エラー率が測定可能なレベルで下がるまで、この文書を反復改善する。
さらに高度なテクニックとして、プロジェクト固有のnotesディレクトリを作成し、CLAUDE.mdからそれを参照させる：
# CLAUDE.md
プロジェクト固有の注意事項は ./notes/ ディレクトリを参照してください。
特に以下のファイルは必ず確認すること：
- notes/architecture-decisions.md
- notes/common-pitfalls.md
- notes/coding-standards.md
4. 再利用可能なSkillsの構築 - 「毎日同じこと」を自動化する
あなたは毎日、同じようなプロンプトを打っていないだろうか？
Boris氏のチームは、繰り返しのタスクをすべてSkillsまたはSlash Commandsに変換している。
実例: /techdebt コマンド
# .claude/commands/techdebt.md
---
description: 技術的負債を発見・分析する
---
以下の観点でコードベースを分析し、技術的負債を特定してください：
1. 重複コードの検出
2. 複雑度が高すぎる関数の特定
3. 古いパターンや非推奨APIの使用箇所
4. テストカバレッジが不足している領域
結果は優先度順にリストアップし、各項目に推定工数を付けてください。
/techdebtと打つだけで、完全な技術的負債レポートが生成される。
さらに高度な例: 統合コンテキストダンプ
Anthropicの内部チームは、複数のサービスから情報を集約するSkillを持っている：
- Slackの関連スレッド
- Google Driveのドキュメント
- Asanaのタスク
- GitHubのIssue/PR
これらを1つのコマンドで統合し、Claudeに渡す。
ポイント: Skillsはgitにコミットする。チーム全員が同じSkillsを使えるようにすることで、ナレッジが共有される。
5. 自動バグ修正ワークフロー - 「貼って"fix"」の世界
これを聞いて驚くかもしれない。
Boris氏のチームは、バグ報告が来たとき、Slackのスレッドをそのまま貼り付けて「fix」とだけ言う。
セットアップ
- Slack MCP統合を有効化する
- バグスレッドのURLをClaudeに渡す
-
fixと入力する
それだけだ。
Claudeは以下を自動で実行する：
- Slackスレッドの内容を解析
- 関連するコードを特定
- バグの原因を推測
- 修正を実装
- テストを追加
分散システムのトラブルシューティングでは、Dockerログを直接Claudeに向ける：
docker logs my-service 2>&1 | claude --stdin "このログからエラーを特定して修正して"
アプローチをマイクロマネジメントする必要はない。 Claudeに任せる。
6. 高度なプロンプト戦略 - Claudeを「試す」
Boris氏のチームは、単に「これを実装して」とは言わない。
Claudeに自分の実装を「証明」させる。
「Prove to me」テクニック
この変更が正しく動作することを証明してください。
以下の方法で：
1. 変更前と変更後のブランチを比較
2. 影響を受けるすべてのパスをリストアップ
3. 各パスでの動作を説明
4. エッジケースの処理を実演
「Grill」テクニック
変更を承認する前に、Claudeに自分の変更を批判させる：
あなたはセキュリティ監査者です。
この変更の問題点を徹底的に洗い出してください。
攻撃者の視点で脆弱性を探してください。
スペック駆動開発
実装を渡す前に、詳細な仕様を書く。曖昧さを排除することで、Claudeの1発実装率が劇的に向上する。
7. ターミナル環境の最適化 - 見た目も生産性
Anthropicの内部チームが選んでいるターミナルはGhostty。
理由：
- 高速なレンダリング
- 優れたUnicodeサポート
- Claude Codeとの相性
ステータスライン活用
/statuslineコマンドでカスタマイズ可能：
- 現在のコンテキスト使用量（%表示）
- 現在のGitブランチ
- アクティブなサブエージェント数
タブの色分け
タスクごとにタブの色を変える。視覚的に「今何をしているか」が一目でわかる。
音声入力の活用
これは意外かもしれないが、Boris氏のチームは音声入力を多用している。
「音声入力は3倍速い。そして、よりリッチなプロンプトが書ける」
キーボードで打つより、話す方が自然言語として豊かな指示が出せる。
8. サブエージェントによるスケーリング - 計算力を分散する
複雑なタスクでは、「use subagents」をプロンプトに追加する。
このコードベース全体をリファクタリングしてください。
use subagents
Claudeは自動的に：
- タスクを分割
- 複数のサブエージェントを起動
- 各サブエージェントに部分タスクを割り当て
- 結果を統合
メインエージェントの集中力を維持
個別のタスク（例：ファイル検索、パターン分析）をサブエージェントにオフロードすることで、メインエージェントは「全体像」に集中できる。
セキュリティスキャン+自動承認
高度な設定として、Boris氏のチームはOpus 4.5のhooksを使って：
- 変更のセキュリティスキャンを自動実行
- 安全と判断された変更は自動承認
- 怪しい変更だけ人間にエスカレート
9. データ分析統合 - SQLを書かない世界
BigQueryユーザーに朗報だ。
Boris氏のチームは、bq CLIを活用したSkillsをgitにコミットしている。
# .claude/commands/metrics.md
---
description: プロダクトメトリクスを分析
---
BigQueryを使用して以下のメトリクスを取得してください：
- 過去7日間のDAU推移
- 機能別の使用率
- エラー率の推移
bq コマンドを使用し、結果を視覚的にわかりやすく整形してください。
チームの中には「もうSQLを手で書かなくなった」エンジニアもいる。
メトリクスが必要なとき、Claudeに聞けばいい。Claudeがクエリを書き、実行し、結果を解釈してくれる。
10. 学習フォーカスの設定 - Claudeを「教師」にする
これは特に新しいコードベースに入ったとき、あるいはチームに新メンバーが入ったときに威力を発揮する。
Explanatoryモード
/config set output_style explanatory
この設定で、Claudeはすべての変更の理由を説明するようになる。
「なぜこのパターンを使ったのか」「なぜこの順序で処理するのか」—コードと一緒に知識が蓄積される。
HTML/Markdownプレゼンテーション生成
新しいコードベースを理解するとき：
このリポジトリの全体構造を理解するためのHTMLプレゼンテーションを生成してください。
各モジュールの責任、データフロー、主要なパターンを説明してください。
ASCIIダイアグラムの活用
プロトコルやシステム間連携を理解するとき：
このAPIの認証フローをASCIIダイアグラムで説明してください。
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Client │────▶│ Auth │────▶│ API │
│ │◀────│ Server │◀────│ Server │
└──────────┘ └──────────┘ └──────────┘
│ │ │
│ 1. Login │ │
│───────────────▶│ │
│ 2. Token │ │
│◀───────────────│ │
│ │ 3. Verify │
│ │───────────────▶│
│ │ 4. OK │
│ │◀───────────────│
スペースド・リペティションSkill
知識のギャップを感じたとき、学習用のSkillを構築する：
# .claude/commands/learn.md
---
description: 特定のトピックについて学習セッションを開始
---
以下のトピックについて、段階的に学習できるセッションを開始してください：
{{topic}}
1. 基本概念の説明
2. 実際のコードでの使用例
3. よくある間違い
4. クイズ形式での理解確認
5. 次に学ぶべきトピックの提案
まとめ: 「正解」はない、しかし「差」はある
Boris Cherny氏がスレッドの最後に書いた言葉を引用しよう：
「Claude Codeの使い方に正解はない。実験して、あなたのセットアップに合うものを見つけてほしい」
しかし、これだけは言える。
これらのプラクティスを知っているかどうかで、生産性に何倍もの差がつく。
あなたが1つのターミナルで1つのClaudeを動かしている間、Boris氏のチームは10-15のClaudeを並列で動かし、自動化されたワークフローでバグを修正し、サブエージェントでタスクを分散している。
この差は、時間が経つほど広がる。
今すぐ始める3つのステップ
- 今日: Git worktreeを設定し、2つのClaudeセッションを並列で動かしてみる
- 今週: CLAUDE.mdを作成し、Claudeのミスを記録し始める
- 今月: 毎日使うタスクを1つSkillに変換する
知っているだけでは意味がない。実践してこそ差がつく。