ボリスの9クロードコードの実用的なヒント:マスターの構成は非常に「シンプル」であることがわかりました ボリス・チェルニーはアンソロピック内でニックネームを持っています:クロード・コードの父親です。 最近はXで活動しているので、多くの人がボリスに「Claude Codeはどうやって使っているの?」と尋ねます。 彼はXに関する9つの実用的なヒントを共有しました。 思っているほど多くのトリックはなく、どれも飾り気のないものです。 [1] コア哲学:クロード・コードのベストプラクティスに対する標準的な答えはありません ボリスは次のように開場しました。 > 私のセットアップは意外とバニラかもしれません! Claude Codeは箱から出してすぐに動作するので、個人的にはあまりカスタマイズしません。 > 私の構成はご想像通り「オリジナル」かもしれません。 Claude Codeは箱から出してすぐにとても動作し、私は個人的にあまりカスタマイズをしませんでした。 スキルやプラグインのようなベストプラクティスが、Claude Code開発者として長く機能に組み込まれてきたのは理解できます。 Claude Codeの正しい使い方は一つではありません。 チームは意図的にカジュアルに使えるように設計しており、好きなように、どう変えたいか、どう変えたいかで自由に使えます。 Claude Codeチームの全員が全く異なる使い方をしています。 ですから、「ベストプラクティス」を見つけるのに苦労する必要はありません。最も重要なのは自分のリズムに合わせることです。 [2] マルチエージェントタスクの並行:同時に十数台のClaudeを起動 ボリスの日常のルーティンはこうです:ターミナルで5つのClaude Codeインスタンスを開き、タブ番号1から5までを開き、システム通知をオンにして、入力すべき通知を飛ばします。 同時に、ウェブ版でも5〜10のタスクを担当しています。 端末とウェブページは互いに「ハンドオフ」できます。ローカルセッションをウェブページに転送するには & 記号を使ったり、--teleport を使って両側で切り替えたりできます。 彼は毎朝と日中にスマホのClaudeアプリからいくつかのタスクを起動し、後で結果を確認するために戻ってくる。 この「マルチスレッド」作業の基本的な論理は、Claude Codeが自律性に優れており、多くのタスクが監視を必要としないという点にあります。 タスクを始めて方向性を出して、動かして、自分で別のことをします。 確認が必要なときは控えめにしましょう。 これは従来の「人間がコードを一行打つだけで、AIが数行を作っている」とは全く異なります。 ただし、これにはより多くのユーザー要件が必要で、エージェントにタスクを割り当てるのが得意で、いつでも複数のタスクを切り替えられる必要があります。 これは、従来の開発モデルにとって大きな課題であり、単独で開発し、同時に一つのタスクしか持たない環境にとって大きな課題です。 恥ずかしながらも、Coding Agentも定期的に使っていますが、同時に多くのタスクを同時にこなすのにはまだ慣れていないので、今年はこの分野の実践を強化しようと思います。 [3] モデル選択:なぜより速いソネットではなくオーパスを使うのか ボリスは思考モードのタスクにOpus 4.5を使っていると言っています。 これは彼がこれまでに使った中で最高のプログラミングモデルです。 こう尋ねる人もいるでしょう。『オーパス』は『ソネット』よりも大きくて遅いのではないですか? ボリスの答えは、単一の応答はやや遅いものの、修正する必要はずっと少なく、ツールコールがより正確で、最終的な結果も速いということです。 実際、コードを書くことは速くはできないが、高品質でなければならないと常に同意しています。高速モデルで3回修正が必要な場合は、遅いモデルで一度に修正した方が良いと。 時間はモデルの応答時間だけでなく、あなたの注意と労力のコストにも関わっています。 唯一の問題は、Opusの方がコストが高いことです。 【4】 はClaudeコードの特別な設定ファイルで、プロジェクトのルートに配置されています。 Claude Codeを起動するたびに、自動的にファイルを読み取り、その内容を「バックグラウンド知識」として扱います。 理解すると、これはAIに書いたプロジェクトの仕様書で、プロジェクトの構造、仕様、注意事項を伝えるものです。 Borisチームのアプローチは、Claude Codeのリポジトリ全体を単一のGitで管理することです。 毎週、人々はリガーノに新しいものを加えています。 ルールはシンプルです:クロードが何か間違っているのを見たら、必ず「これをやらないで」と書くと、次はすぐに気づきます。 さらに興味深いのは、コードのレビューでもこの仕組みが使われていることです。 ボリスは同僚のPRで@.claudeを使い、クロードに新しいルールを追加するよう頼みます。 これはClaude CodeのGitHub Actionを通じて実現されています。 ダン・シッパーはこれを「複利プロジェクト」と呼びます。すべてのエラー訂正がチームの資産となり、AIがあなたのプロジェクトをより深く理解できるようになります。 まだコマンドを使っていなければ、Claudeが自動的にプロジェクト構造を分析し、初期バージョンを生成します。 そして使いながら追加し、問題点を見つけたら追加していきます。 [5] プランモード:実行する前にはっきり考える ボリスはほとんどのセッションをプランモードで始めると言っています。 Claude CodeでShift+Tabをダブルクリックして切り替えます。 プランモードでは、Claudeはコードを直接変更せず、まず実行計画を提示します。 計画について何度も話し合い、見直しをして満足するまで続けてください。 その後、Claudeが通常一度に自動承認モードに切り替えます。 「良い計画は本当に重要だ」という習慣は、ソフトウェア開発の古典的な知恵をAIコラボレーションに移しています。つまり、まずデザイン、次にコードを書くというものです。 多くの人がAIを使ってコードを書く問題は、直接書き始めることで、誤った方向性のために再作業コストが高くなることです。 数分かけて計画を調整することで、何時間もの再作業を節約できます。 [6] 繰り返し作業の自動化:スラッシュコマンドとサブエージェント ボリスは一日に何十回も手術をしなければならず、それをスラッシュコマンドに変えた。 例えば、「/commit-push-pr」は、投稿、プッシュ、PR作成をワンクリックで完了します。 スラッシュコマンドは基本的にMarkdownファイルで、.claude/commands/ディレクトリの下に置かれます。 自然言語でコマンドを書くこともできますし、bashスクリプトを埋め込むことで事前に情報を得られるので、モデルとの呼び出し回数を減らせます。 これらのコマンドはGitに提出し、チーム全体で共有できます。 スラッシュコマンドに加えて、彼はサブエージェントも使用しています(エージェントとは、特定の種類の仕事に特化したクロードの別インスタンスです。 例えば、メインのClaudeが作業を終えた後に自動的にコードを簡略化するコード簡略化サブエージェントを持っています。 また、エンドツーエンドのテストを担当するVerify-Appサブエージェントも存在します。 この二つの特徴に共通しているのは、繰り返し自分のやっていることを確立し、クロード自身がそれを決められることです。 毎回説明を繰り返す必要も、コマンドの詳細を覚える必要もありません。 PostToolUse Hookを使ってClaudeで生成されたコードをフォーマットしてください。 Claudeは通常、適切にフォーマットされたコードを自動生成し、このフックが継続的統合(CI)プロセスでの誤フォーマットを防ぐためにコードの最後の10%を処理します。 [7] セキュリティと統合:権限設定と外部ツール ボリスは「危険にスキップ」という権限オプションを使いません。 代わりに、確認ボックスが毎回ポップアップしないように、/permissions コマンドでよく使われるセキュリティコマンドを事前に承認しています。 これらの構成は.claude/settings.jsonに保存され、チームで共有されます。 さらに強力なのはMCPサーバーとの連携です。 MCPはModel Context Protocolの略で、Anthropicが導入した標準プロトコルで、AIが外部ツールに接続できるようにします。 MCPを使えば、Claude Codeは直接以下を行えます: - Slackメッセージの検索と送信 - データ質問に答えるためのBigQueryクエリを実行する - Sentryからエラーログを取得する BorisチームもSlackのMCP設定をリポジトリに提出し、みんなすぐに使っていました。 つまり、Claude Codeは単なるプログラミングツールではなく、ツールチェーン全体を呼び出せる「オールインワンアシスタント」なのです。 [8] 長時間のタスク処理:クロード自身に検証させてください 長期ミッションのために、ボリスにはいくつかの戦略があります。 1つ目は、Claudeが完了後に自動的にバックグラウンドエージェントを使って結果を検証できるようにすることです。 プロンプトでリクエストすることもできますし、Stop Hookを使ってより決定的にトリガーすることもできます。 >注:フックはClaude Codeの「フック」機構で、Claudeがアクションを行っている特定の瞬間にカスタムロジックを挿入できる仕組みです。 これは「トリガー」と考えることができます。イベントが発生したときに、自動的にプリセットのコマンドやスクリプトを実行します。 > ストップフックはクロードが反応し、コントロールを渡す準備ができた瞬間です。 >関連文書: 二つ目はralph-wiggumプラグインを使うことです。これは本質的にBashループです。単純なデッドループ(真ですが)同じタスクステートメント(プロンプトファイル)をAIエージェントに何度も送り続け、完全に終わるまで何度も作業を改善していくイメージです。 三つ目は、サンドボックス環境で --permission-mode=dontAsk または --dangerously-skip-permissions を使うことで、クロードが許可確認で中断されて自分で最後まで走り続けることを防ぐことです。 核心的な考え方は、長い作業だから待たせないということです。 十分な自律性と自己修正能力を与えてください。 [9] 最も重要なのは、クロードに検証機能を与えることです ボリスはこれを最後に挙げ、これが良い結果を得るために最も重要な要素だと言います。 クロードが自分の作業を検証できれば、最終的な出力品質を2〜3倍に向上させることができます。 彼は例を挙げました:変更を提出するたびに、ClaudeはChrome拡張機能で自分自身をテストします。ブラウザを開き、UIをテストし、問題が見つかったら繰り返し、正常に動作し、体験が合理的になるまで繰り返します。 検証方法は状況によって異なります。 bashコマンドを実行したり、テストスイートを実行したり、ブラウザやモバイルエミュレーターでアプリをテストしたりすることもあります。 フォームは重要ではありませんが、重要なのはAIにフィードバックループを与えることです。 この真実は実はとてもシンプルです。 人間のエンジニアは「コードを書く→テスト→結果の確認→修正」というサイクルにも頼って品質を確保しています。 AIも同様です。 もし書くだけで測定できないなら、目を閉じてやっているようなもので、質は運次第です。 ボリスの提案は、検証メカニズムの強化に投資することです。 これが投資収益率が最も高いのです。 [10] 達人は剣を使って手を使わずに勝つ 武道小説では、師匠は剣の装飾や装飾をあまり持っておらず、勝つための技もありません。 Borisは複雑なカスタム設定を見せず、謎めいたプライベートプロンプトもなく、公式機能を使っています。 違いは、彼がこれらの機能の背後にある論理を本当に理解し、それらを効率的なワークフローに組み込んでいる点です。 並列作業が行われるのは、クロードが自律的に実行できるからです。 Opusが使われる理由は全体的な効率が高いためです。 それは誤り訂正を資産に変えることです。 プランモードは、実行する前に冷静に考えることです。 スラッシュコマンドとサブエージェントは自動化された反復労働であり、 検証の仕組みは、AIにフィードバックを閉じたループとして与えることです。 Claude Codeを始めたばかりなら、高度な設定に急ぐ必要はありません。 まずは基本をしっかり活用しましょう:並行作業を学び、計画を立て、AI検証手法を蓄積すること。 本当にボトルネックに遭遇したときは、花を捨てるのに遅すぎることはありません。

Borisが言及しなかったのは、基本的なCI/コードレビューのワークフローで、これは彼らの大企業では普通のことであり、デフォルトであるべきことです 例えば、Claude Codeでタスクを完了したとき、直接メインブランチにマージするよう指示せず、PRを提出します。 PRを送信すると、すべてのlintおよび自動テストがCIサーバー上で自動的に実行され、テストが失敗した場合はPRをマージできません。 PRはすべての自動化テストに合格し、コードレビューを行う人が必要です(もちろんAIの支援も可能ですが、確認が必要です)。コードレビューで問題が見つかった場合は修正が必要です。 多くの個人開発者はCIやコードレビューのワークフロー構築に慣れておらず、Gitのコード管理もしていないため、何か問題が起きてもロールバックできません。

[10] 見えないあのもの Borisが言及しなかったのは、基本的なソース管理/CI/コードレビューのワークフローで、これは彼らの大企業では普通のことであり、デフォルトであるべきものです 例えば、Claude Codeでタスクを完了したとき、直接メインブランチにマージするよう指示せず、PRを提出します。 PRを送信すると、すべてのlintおよび自動テストがCIサーバー上で自動的に実行され、テストが失敗した場合はPRをマージできません。 PRはすべての自動化テストに合格し、コードレビューを行う人が必要です(もちろんAIの支援も可能ですが、確認が必要です)。コードレビューで問題が見つかった場合は修正が必要です。 これらはまた、マルチタスクが並列できる能力の基盤でもあり、これらの基本的なワークフローがなければ並列作業はできません。 多くの個人開発者はCIやコードレビューのワークフロー構築に慣れておらず、Gitのコード管理もしていないため、何か問題が起きてもロールバックできません。