Claude Codeの生みの親は、実際にどうClaude Codeを使っているのか

Claude Codeの生みの親であるBoris Chernyが、自身の開発ワークフローを公開しました。投稿はわずか2時間で5,000いいねを超えました。ツールを作った本人が「実際にどう使っているか」を明かせば、当然注目が集まります。

最も驚いたのは、そのシンプルさです。凝ったカスタマイズも、秘密の設定もありません。彼のアプローチの核心は、Claude Codeに標準搭載された機能を、規律をもって意図的に組み合わせることです。

Andrej Karpathyが最近公開した「AIコードエージェントにおける抽象化レイヤー」の解説を読んだ方には、Borisのガイドはその実践編として位置づけられます。

並列処理 — Claudeセッションを15個同時に回す

Borisはターミナルで5つのClaudeインスタンスを同時に実行し、さらにclaude.ai/codeのブラウザ経由で5〜10セッションを追加で走らせています。朝、スマートフォンからセッションを開始し、後から進捗を確認することもあるそうです。

彼のセットアップは以下の通りです。

• ターミナルタブに1から5の番号を振り、入力が必要になったらシステム通知で把握する。
• &コマンドでローカルセッションとWebセッションを切り替える。
• --teleportでセッション間を移動する。
• 各ターミナルタブに独立したgitチェックアウトを用意し、セッションごとに独立したブランチで独立した計画を実行する。

これは見せかけのマルチタスクではありません。各セッションが明確にスコープされた個別のタスクを担当しています。並列性は、コンテキストスイッチングではなく、明確な計画から生まれます。

コメント欄で興味深い補足がありました。Borisはgit worktreeではなく、ターミナルタブごとに個別のgitチェックアウトを使っています。多数のセッションを扱うときは、シンプルなモデルの方が把握しやすいという判断です。

Opus 4.5 + Thinking — 大きいモデルの方が実は速い

Borisはすべてのタスクで利用可能な最大モデルを使用しています。直感に反する選択です。Opusはトークンあたりの処理速度が遅く、コストも高いからです。しかし彼の理屈は実用的で、大きいモデルの方が修正回数が少なく、ツールの使い方がより正確で、一発目の出力品質が高いということです。

結果として、タスク全体の完了時間はOpusの方が小さいモデルより短くなります。ミスの修正やプロンプトのやり直しに費やす時間が大幅に減るためです。

• 彼がテストした中で、最高のコーディング性能を発揮するモデルです。
• 実行中に人間が介入する回数が少なくなります。
• トークンあたりのレイテンシは高いにもかかわらず、実際の所要時間は短縮されます。

CLAUDE.md — チーム全体のコンテキストエンジニアリング

チーム全員で一つのCLAUDE.mdファイルをGitにコミットしています。Claudeがミスをするたびに、誰かがこのファイルにメモを追加し、同じエラーが二度と起きないようにします。

これは複利で効くエンジニアリングの実践です。

• 複数のチームメンバーが毎週アップデートを追加します。
• コードレビュー時に@.claudeタグを使い、CLAUDE.mdへの追記をリクエストします。
• チームごとに独自のCLAUDE.mdを管理しています。
• このファイルは、すべてのClaudeセッションが継承する組織知識の蓄積体になります。

コンセプト自体は単純ですが、これを一貫して維持する規律こそが威力を生んでいます。

プランモード — 良い計画が成功の90%を決める

Borisはほとんどのセッションをプランモード（Shift+Tab 2回）で始めます。ゴールがプルリクエストであれば、納得いくまでClaudeと計画を議論し、その後auto-acceptモードに切り替えて、計画全体を中断なしで実行させます。

ワークフローは以下の通りです。

1. 計画フェーズに十分な時間を投資する。
2. エッジケースや潜在的な問題をカバーするまで計画を練り上げる。
3. 計画が固まったら、自動実行モードに切り替える。
4. 実装中のやり取りを最小限に抑える。

このパターンは、最も一般的な失敗モードを排除します。それは、アプローチが明確になる前にコーディングを始めてしまうことです。計画のコストは低く、やり直しのコストは高い。この原則を徹底しています。

スラッシュコマンドとサブエージェント — 繰り返し作業を自動化する

Borisが1日に数回以上使うワークフローは、すべてスラッシュコマンドとして.claude/commands/に保存されます。/commit-push-prのようなコマンドは、開発者だけでなくClaude自身も利用可能になります。

• 繰り返しのプロンプトを完全に排除します。
• インラインbashでコンテキストを事前計算し、コマンドの実行速度を上げます。
• code-simplifierやverify-appなどのサブエージェントが、よくある検証ワークフローを処理します。
• PostToolUseフックが編集のたびにコードを自動フォーマットします。

BorisはSkillsもスラッシュコマンドの一形態として捉えています。再利用可能で共有可能なワークフロー定義であり、Claudeが特定のタスクにどうアプローチするかを標準化するものです。

パーミッション管理とツール連携

Borisは--dangerously-skip-permissionsを使わず、/permissionsで安全なコマンドを事前承認します。チームでMCPサーバーの設定を共有し、ClaudeがSlack、BigQuery、Sentryなどのツールに直接アクセスできるようにしています。

• パーミッション設定は.claude/settings.jsonで共有します。
• ツール連携は.mcp.jsonで共有します。
• セキュリティを犠牲にすることなく、不要なパーミッションプロンプトを最小限に抑えます。

これは完全なロックダウンと無制限のアクセスの間にある現実的な落としどころです。何が安全かをチームで合意し、コードとして固め、先に進みます。

検証ループ — 品質を2〜3倍にする最重要プラクティス

Borisのワークフローで最も重要な習慣は、Claudeに自分の作業を自ら検証する手段を与えることです。

claude.ai/codeでは、Chrome拡張機能を通じて実際のアプリケーションと連携させ、すべての変更をテストさせています。検証ループには以下が含まれます。

• バックグラウンドエージェントが作業完了後にチェックを行います。
• Agent Stopフックが決定論的なバリデーションを実行します。
• ralph-wiggumプラグインによる追加検証を行います。
• サンドボックス環境でパーミッションモードを調整し、ブロッキングを回避します。
• ブラウザやシミュレーターでの実際のUXテストを実施します。

これはオプションの仕上げ工程ではありません。Borisは、検証ループこそが品質を1倍から2〜3倍に引き上げる決定的な違いだと考えています。

プラクティスの背後にあるパターン

具体的なツールや設定を取り除くと、4つの原則が浮かび上がります。

• 積極的に並列化する。 明確なスコープと独自のブランチを持つセッションを多数実行します。
• 作る前に計画する。 プランモードはClaude Codeで最もレバレッジの高い機能です。
• チームでコンテキストを共有する。 CLAUDE.mdが個人の学びをチームの知識に変えます。
• 検証ループを閉じる。 レビューの前にClaude自身に作業をチェックさせます。

Borisのセットアップで最も印象的なのは、特定のテクニックではありません。動くパーツの少なさです。ツールの生みの親は、エキゾチックな設定に頼っていません。基本を一貫して実行すること。それが彼のやり方です。