オリジナル記事は、Claude Code の開発者であるBoris Cherny氏によるものです。

編集・構成： Xiaohu AI

Claude Codeについて聞いたことがあるかもしれませんし、コードを書いたりドキュメントを編集したりする際に使ったことがあるかもしれません。しかし、AIが単なる「一時的なツール」ではなく、開発プロセスの正式なメンバー、あるいは自動化されたコラボレーションシステムになった場合、仕事のやり方がどのように変わるか考えたことがありますか？

Claude Code の作成者である Boris Cherny 氏は、このツールをいかに効率的に使用しているか、また彼と彼のチームが実際の作業においていかにして Claude をエンジニアリング プロセス全体に深く統合しているかについて、非常に詳細なツイートを投稿しました。

この記事では、彼の経験について体系的な概要と分かりやすい解釈を提供します。

Boris はどのようにして AI をワークフローの自動化パートナーにしたのでしょうか?

要点:

彼は自身のワークフローについて次のように説明しました。

クロードの使い方:

複数の Claude インスタンスを同時に実行: ターミナルと Web ページで 5 ～ 10 個のセッションを開いてタスクを並行して処理し、モバイル フォンでも Claude を使用します。

デフォルト設定を無計画に変更することは避けてください。Claude はそのまま使用でき、複雑な構成は必要ありません。

最も強力なモデル (Opus 4.5) を使用します。少し遅くなりますが、よりスマートで使いやすくなります。

コードを書く前に計画を立てる (計画モード): 書き始める前に Claude が物事をじっくり考えるのを手伝ってくれるので、成功率が向上します。

コードを生成した後、エラーを回避するためにツールを使用して形式を確認します。

クロードを使えば使うほど賢くなる方法:

チームは「知識ベース」を維持しています。クロードがミスをしたときはいつでも、同じミスを繰り返さないようにその経験を知識ベースに追加します。

PR を書くときに Claude を自動的にトレーニングする: Claude に PR を見せて、新しい使用法や規則を学習させます。

頻繁に使用するコマンドはスラッシュ コマンドになり、Claude が自動的に呼び出すことができるため、繰り返しの作業が省けます。

コードの簡素化や機能の検証など、特定の固定タスクを処理するには、「サブエージェント」を使用します。

権限を管理する方法:

権限を恣意的にスキップするのではなく、安全なコマンドが自動的に通過するように設定します。

複数のデバイス (Web、端末、モバイル) 間で Claude ワークフローを同期します。

最も重要な点:

Claude には、書き込んだ内容が正しいかどうかを検証できる「検証メカニズム」が提供される必要があります。

たとえば、Claude は自動的にテストを実行し、ブラウザでテスト Web ページを開いて、機能が動作しているかどうかを確認できます。

クロード・コードは「ツール」ではなく「パートナー」です。

ボリスはまず核となるコンセプトを伝えました。それは、Claude Code は静的なツールではなく、ユーザーと連携し、継続的に学習し、共に成長できるインテリジェントなパートナーであるというものです。

複雑な設定は必要なく、すぐに使える強力なツールです。しかし、より良い利用パターンを構築するために時間を投資する意思があれば、その効率性は何倍にも高まります。

モデルの選択: 最も速いものではなく、最も賢いものを選択してください。

Boris は、すべての開発タスクに「考える」という考え方を取り入れた、Claude の主力モデルである Opus 4.5+ を使用しました。

このモデルは Sonnet よりも大きくて遅いですが、次のような利点があります。

• より強い理解力がある
• ツールをより良く使いこなす能力
• 繰り返しの指導は必要なく、やり取りのコミュニケーションは最小限
• 全体的に、高速モデルを使用するよりも時間が節約されます。
• 教訓: 真の生産性は実行速度ではなく、「ミスの減少、やり直しの減少、繰り返しの説明の減少」にあります。

1. 計画モード: AI を使用してコードを記述する場合、急いで「記述」させないでください。

Claude を開くと、多くの人が本能的に「インターフェースの作成を手伝ってください」または「このコードをリファクタリングしてください」と入力します... Claude は通常「いくつか作成」しますが、道を誤っていたり、ロジックを見落としたり、要件を誤解したりすることが多々あります。

ボリスの最初のステップは、クロードにコードを一切書かせないことでした。彼はプランパターンを採用しました。まずボリスとクロードは協力して実装計画を立て、それから実行フェーズへと進むというものです。

彼はどうやってそれをやったのですか？

プル リクエストを開始するとき、Boris は Claude に直接コードを書かせません。代わりに、Plan モードを使用します。

1. 目標を説明する

2. クロードと一緒に計画を立てます。

3. 各ステップを確認する

4. それから初めて、クロードは書き始めました。

「特定の API にレート制限を追加する」など、新しい機能を実装する必要がある場合は、Claude と段階的に確認します。

• ミドルウェアを使用して実装されていますか、それともロジックに組み込まれていますか?
• レート制限構成は動的な変更をサポートする必要がありますか?
• ログ記録は必須ですか? 失敗した場合は何を返す必要がありますか?

この「計画協議」のプロセスは、2 人が一緒に「建築設計図」を作成するのと似ています。

クロードが目標を理解すると、Boris は「編集の自動承認」モードをオンにして、クロードが直接コードを変更し、PR を送信できるようにします。場合によっては、手動での確認も必要ありません。

「クロードのコードの品質は、コードを書く前に合意に達したかどうかにかかっています。」— ボリス

教訓: クロードさんのミスを​​繰り返し修正するのではなく、最初から一緒に明確なロードマップを描く方が良いです。

まとめ

プランモードは時間の無駄ではありません。事前の交渉によって安定した実行が保証されます。どんなに強力なAIでも、ユーザーが「明確に説明」する必要があります。

2. 複数のクロードの並行開発: 単一のAIではなく、仮想開発チーム

ボリスはクロードという名前だけを使うわけではありません。彼の日課はこんな感じです。

• ターミナルで 5 つのローカル Claude インスタンスを開き、セッションをさまざまなタスク (リファクタリング、テストの作成、デバッグなど) に割り当てます。
• ブラウザでさらに 5 ～ 10 個の Claude インスタンスを開き、ローカル マシンと同時に実行します。
• 携帯電話の Claude iOS アプリを使用して、いつでもタスクを開始できます。

各 Claude インスタンスは「パーソナル アシスタント」のようなものです。コードの作成を担当するもの、ドキュメントの完成を担当するもの、長時間にわたってバックグラウンドでテスト タスクを実行するものなどがあります。

さらに、クロードが入力を待っているときにすぐに警告が届くように、システム通知も設定しました。

なぜそうするのでしょうか?

Claude のコンテキストはローカルであるため、「すべてを 1 つのウィンドウで実行する」には適していません。Boris は Claude を複数のロールに分割して並列処理することで、待機時間と「メモリへの干渉」の両方を削減します。

また、彼はシステム通知を通じて「クロード 4 があなたの返事を待っています」や「クロード 1 がテストを完了しました」と自分自身に思い出させ、マルチスレッド システムを管理するかのようにこれらの AI を管理しました。

類推的理解

5人の優秀なインターン生に囲まれ、それぞれが担当業務を担当していると想像してみてください。すべてを最後までやり遂げる必要はありません。タスクがスムーズに進むよう、重要な場面で「人員交代」をするだけで十分です。

意味: クロードを複数の「仮想アシスタント」として扱い、さまざまなタスクを実行すると、待機時間とコンテキスト切り替えコストが大幅に削減されます。

3. スラッシュ コマンド: 日常のタスクを Claude のショートカットに変換します。

私たちが 1 日に何十回も実行するワークフローの一部:

• コードを修正 → コミット → プッシュ → PR を作成
• ビルドステータスを確認 → チームに通知 → 問題を更新
• 複数のウェブセッションとローカルセッションへの変更を同期する
• Boris は、Claude に対して「まずコミットして、次にプッシュして、最後に PR を作成してください...」と頻繁に促したくありませんでした。

彼はこれらの操作を次のようなスラッシュ コマンドにカプセル化しました。

/commit-push-pr

これらのコマンドは Bash スクリプト ロジックに基づいており、.claude/commands/ フォルダーに保存され、チーム メンバーが使用できるように Git によって管理されます。

これらのコマンドをClaudeで使用するにはどうすればよいですか?

Claude はこのコマンドに遭遇すると、単に「指示を実行する」のではなく、コマンドが表すワークフローを理解し、中間ステップを自動的に実行し、パラメータを事前に入力して、繰り返しの通信を回避することができます。

重要なポイントを理解する

スラッシュコマンドは、Claudeにインストールする「自動ボタン」のようなものです。タスクフローを理解できるようにトレーニングすれば、ワンクリックで実行できるようになります。

「コマンドを使えば、私だけでなくクロードも時間を節約できます。」— ボリス

学んだ教訓: プロンプトを繰り返し入力することは避け、高頻度のタスクをコマンドに抽象化して、Claude との共同作業を自動化します。

4. チーム ナレッジ ベース: Claude はプロンプトを通じて学習するのではなく、チームが管理するナレッジ ベースを通じて学習します。

Boris のチームは .claude リポジトリを管理しており、それを Git 管理に組み込んでいます。

これはクロードにとっての「内部ウィキペディア」のようなもので、次のように記録されています。

• 正しい書き方は何でしょうか？
• チーム合意のベストプラクティスは何ですか?
• どのような問題に遭遇する可能性があり、それをどのように修正する必要があるでしょうか?

クロードはこのナレッジベースを自動的に参照してコンテキストを理解し、コード スタイルを決定します。

クロードが何か悪いことをしたとき、どうすればいいでしょうか?

クロードが誤解したり、論理的な誤りを犯したりするたびに、その教訓が方程式に追加されます。

各チームは独自のバージョンを維持します。

全員が共同で編集作業を行い、クロードはこの知識ベースをリアルタイムで参照して判断を下します。

例えば：

クロードさんがページ区切りのロジックを間違って書き続ける場合、チームは正しいページ区切りの標準をナレッジ ベースに書き込むだけで、すべてのユーザーが自動的にその恩恵を受けることができます。

ボリスのアプローチ: 叱ったり電源を切ったりするのではなく、「一度訓練する」のです。

这段代码我们不这样写，加进知识库

クロードは次回同じ間違いを繰り返さないだろう。

さらに重要なのは、このメカニズムは Boris 一人によって維持されているのではなく、チーム全体が毎週貢献し、修正しているということです。

教訓: AI を使うということは、各人が単独で作業することではなく、「集合的記憶」のシステムを構築することです。

5. 自動学習メカニズム: PR 自体が Claude の「トレーニング データ」です。

Boris はコードをレビューするときに、プル リクエストに @Claude を追加することがよくあります。例:

@.claude この関数構文をナレッジベースに追加してください。

GitHub Actions と併用すると、Claude は変更の背後にある意図を自動的に学習し、それに応じて内部知識を更新します。

これは「クロードへの継続的なトレーニング」に似ており、各レビューによってコードが改善されるだけでなく、AI の機能も強化されます。

これはもはや「事後メンテナンス」ではなく、AI の学習メカニズムを日常のコラボレーションに統合するものです。

チームはプルリクエストを使用してコードの品質を向上させ、同時にクロードは自身の知識を向上させました。

学んだ教訓: PR は単なるコード レビュー プロセスではなく、AI ツールが進化する機会でもあります。

6. サブエージェント: Claude が複雑なタスクをモジュール方式で実行できるようにします。

メインのタスク フローに加えて、Boris は一般的な補助タスクを処理するためのサブエージェントもいくつか定義します。

サブエージェントは、次のような自動的に実行される一連のモジュールです。

• code-simplifier: Claude で記述されたコードの構造を自動的に簡素化します。
• verify-app: 新しいコードが使用可能かどうかを確認するために完全なテストを実行します。
• log-analyzer: エラー ログを分析して、問題をすばやく特定します。

これらのサブエージェントは、プラグインのように、Claude のワークフローに自動的に統合され、繰り返しプロンプトを必要とせずに共同で実行されます。

教訓: サブエージェントはクロード氏の「チームメンバー」であり、クロード氏をアシスタントから「プロジェクト指揮官」に昇格させます。

クロードは単なる人間ではなく、チームを率いることができるミニマネージャーです。

7. 補足1: PostToolUseフック – コードフォーマットの最後の門番

チーム内で、全員が一貫したスタイルでコードを書けるようにするのは簡単ではありません。Claude は強力なコード生成機能を備えていますが、インデントが少しずれていたり、空行が多すぎたりするといった小さな欠陥から逃れられるわけではありません。

Boris のアプローチは、 PostToolUse フックを設定することです。

簡単に言えば、これは「タスクが完了した」後に Claude が自動的に呼び出す「後処理フック」です。

その機能は次のとおりです:

• 自動コードフォーマット修復
• 不足している注釈を追加する
• CI がクラッシュするのを防ぐために lint エラーを処理します。

このステップは通常はシンプルですが、非常に重要です。記事を書いた後にGrammarlyを再度実行するようなものです。これにより、提出された記事が一貫性があり、整然としたものになっていることが保証されます。

AI ツールの場合、使いやすさの鍵となるのは、生成力ではなく、タスクを処理する能力であることが多いです。

8. アクセス制御: スキップではなく事前承認。

Boris は、コマンド実行時にすべての権限プロンプトをスキップする Claude Code のパラメータである `--dangerously-skip-permissions` を使用していないことを明確に述べています。

便利に聞こえますが、誤ってファイルを削除したり、間違ったスクリプトを実行したりするなど、危険な場合もあります。

彼の代替案は次のとおりです。

1. /permissions コマンドを使用して、信頼されるコマンドを明示的に宣言します。

2. これらの権限設定を.claude/settings.jsonに記述します。

3. これらのセキュリティ設定をチーム全体と共有します。

これは、次のような、Claude の操作の「ホワイトリスト」を事前に作成するようなものです。

"preApprovedCommands": [

"git commit",

"npm run build",

"pytest"

]

クロードはこれらの操作を毎回中断することなく直接実行します。

この権限メカニズムは、スタンドアロンツールというよりも、チームOSのように設計されています。彼は`/permissions`コマンドを使用して、頻繁に使用される安全なbashコマンドを事前承認し、これらの設定は`.claude/settings.json`に保存され、チームで共有されています。

教訓：AIによる自動化は制御の喪失を意味するものではありません。真のエンジニアリングとは、自動化プロセス自体に安全戦略を組み込むことにあります。

9. マルチツールリンケージ：クロード＝多機能ロボット

BorisはClaudeにローカルでのコード記述を許可しただけでなく、MCP（中央制御サービスモジュール）を介してClaudeが複数のコアプラットフォームにアクセスできるように設定しました。

• Slack 通知 (ビルド結果など) を自動的に送信します。
• BigQuery データ（ユーザー行動指標など）をクエリします。
• Sentry ログをキャプチャします (例: オンライン異常追跡用)。

これを実現するにはどうすればよいでしょうか?

MCP設定は.mcp.jsonに保存されます。

Claude は実行時に構成を読み取り、クロスプラットフォーム タスクを自律的に実行します。

チーム全体で単一の構成を共有します。

これらすべては、MCP (Claude の中央制御システム) を介して Claude と統合することで実現され、構成は .mcp.json に保存されます。

クロードは、次のようなことを手伝ってくれるロボット アシスタントのようなものです。

「コードを書く→PRを送信する→結果を確認する→QAに通知する→ログを報告する」。

これはもはや従来の意味での AI ツールではなく、エンジニアリング システムの中枢です。

教訓: AI を「エディター」内でのみ動作させないでください。

システム エコシステム全体のスケジューラーになることができます。

10. 長時間実行タスクの非同期処理: バックグラウンドエージェント + プラグイン + フック

実際のプロジェクトでは、Claude は次のような長いタスクを処理する必要がある場合があります。

• ビルド + テスト + デプロイ
• レポートを生成してメールを送信する
• データ移行スクリプト実行中

Boris のアプローチは非常にエンジニアリング指向です。

長いタスクを処理する 3 つの方法:

1. 完了後、クロードはバックグラウンド エージェントを使用して結果を確認します。

2. タスクの終了時に後続のアクションを自動的にトリガーするには、停止フックを使用します。

3. ralph-wiggum プラグイン (@GeoffreyHuntley が提案) を使用して、長時間実行されるプロセスの状態を管理します。

これらのシナリオでは、ボリスは以下を使用します。

--permission-mode=dontAsk

または、権限プロンプトによってプロセス全体が中断されるのを避けるために、タスクをサンドボックスで実行します。

Claude は「常時監視」を行う人ではなく、むしろプロジェクトを管理するために信頼できる協力者です。

教訓: AI ツールは、適切な「管理メカニズム」を構築すれば、迅速かつ簡単な操作に適しているだけでなく、長期的で複雑なプロセスにも適しています。

11. 自動検証メカニズム: クロードの出力値に価値はありません。重要なのは、それが自身を検証できるかどうかです。

ボリスが学んだ最も重要な教訓は次のとおりです。

Claude によって出力される結果には、その正確性を確認するための「検証メカニズム」が必要です。

彼は、Claude に検証スクリプトまたはフックを追加します。

• コードの記述が完了すると、Claude は自動的にテスト ケースを実行し、コードが正しいことを確認します。
• ブラウザでのユーザー操作をシミュレートして、フロントエンドのエクスペリエンスを検証します。
• 実行前と実行後のログとメトリックを自動的に比較します。

失敗した場合、Claude は成功するまで自動的に修正して再実行します。

まるでクロードが独自の「閉ループフィードバックシステム」を導入したかのようです。

これにより、品質が向上するだけでなく、人々の認知的負担も軽減されます。

教訓: AI 結果の品質を本当に決定するのは、モデル パラメータの数ではなく、「結果チェック メカニズム」を設計しているかどうかです。

要約すると、目標は AI が人間に取って代わることではなく、AI が人間のように協力することです。

ボリスのアプローチは、「隠し機能」や黒魔術に頼るのではなく、クロードの使用を設計し、「チャットツール」から高性能な作業システムのコンポーネントにアップグレードしました。

彼のクロードの使い方には、いくつかの重要な特徴があります。

• マルチセッション並列処理：より明確なタスク分割と高い効率
• 計画優先:計画モードは、クロード氏の目標の整合性を向上させます。
• 知識システムのサポート:チームは共同で AI の知識ベースを維持し、継続的に反復します。
• タスクの自動化:スラッシュ コマンド + サブエージェントにより、Claude はワークフロー エンジンのように動作します。
• 閉ループ フィードバック メカニズム: Claude の各出力には、安定した信頼性の高い出力を確保するための検証ロジックがあります。

実際、ボリスのアプローチは AI の新しい使い方を示しています。

• クロードを「会話型アシスタント」から「自動プログラミングシステム」にアップグレードする
• 人間の脳に蓄積された知識を AI の知識ベースに変換します。
• プロセスを反復的な手動操作から、スクリプト化されたモジュール式の共同自動化ワークフローに変換します。

このアプローチは黒魔術に頼るものではなく、エンジニアリング能力を示すものです。また、このアプローチから学ぶことで、Claude やその他の AI ツールをより効率的かつインテリジェントに活用できるようになります。

Claude を使用しているときに、「少しは知っているが、信頼できない」または「書き込んだコードを常に修正する必要がある」と感じることがよくある場合、問題は Claude にあるのではなく、成熟したコラボレーション メカニズムを提供していないことにある可能性があります。

クロード氏は、どのように活用するかによって、有能なインターンにも、信頼できるエンジニアリング パートナーにもなります。