BorisのClaude Code運用Tipsを実務へ｜30項目から選ぶ改善の順番

30項目を一度に導入せず、詰まっている仕事から選ぶ

Tipsを読んでも運用が変わらない原因の1つは、改善したい問題が決まっていないことです。実装が速くても、仕様の確認が遅ければ全体は進みません。並列セッションを増やしても、レビューできなければ未確認の変更が積み上がります。

この順序は編集部の提案です。Boris本人はプロフィールでClaude Codeを作ったことを説明しています。日常の運用方法を広く確認するには、公式のベストプラクティスも併読してください。

本人の投稿と、この記事の実務への提案を分ける

Boris本人の発信は、2026年1月の運用紹介スレッドと、チームの使い方を紹介したスレッドから確認できます。本人も使い方は一通りではないと説明しています。このページの30項目は、その発信と公式機能の説明を仕事に取り入れるための編集です。

検証については、本人の補足投稿が具体的です。コードの出力を確かめる道具を渡し、いつ使うかが分かる説明を与えるという趣旨です。以下の導入順序や業務例は、その考え方を基にした編集部の提案で、本人の実績や逐語訳ではありません。

1〜3：計画・検証・並列実行を一組で考える

1. 大きい変更では、実装前に計画を確認する

何を変えるかだけでなく、何を維持するかも決めます。利用者の操作、データの流れ、失敗時の表示まで書けると、計画の抜けを指摘しやすくなります。小さく明確な修正まで、長い計画書を必須にする必要はありません。

2. 検証方法を最初の依頼に含める

「直して」で終わらせず、再現手順、テスト、実画面など、正しくなったことを示す方法を渡します。テストが通った事実と、利用者の目的を満たした事実は分けて確認します。

3. worktreeは独立した変更に使う

別々の作業ディレクトリは変更の衝突を避ける助けになります。ただし、同じデータベースや公開先まで分かれるわけではありません。独立した仕事だけを同時に進め、統合する担当を決めます。

4〜8：繰り返す規則と権限を整理する

4. CLAUDE.mdは、失敗から必要な規則を足す。何でも書き込むのではなく、プロジェクトで毎回必要な注意に絞ります。5. 繰り返す仕事はSkillへまとめる。手順だけでなく、入力、成果物、完了条件も定義します。6. チーム共通の設定を管理する。個人環境や秘密を混ぜず、変更理由が追えるようにします。

7. よく使う操作と慎重に扱う操作を分ける。指示文だけでアクセス制御ができたと考えず、実際の権限設定を確認します。8. 複数ディレクトリを参照するときは範囲を明示する。関連するからといって、不要な個人フォルダまで対象に広げません。

規則の置き方はメモリの公式資料、再利用する手順はSkillsの公式資料を確認します。規則が長くなり過ぎたら、常時必要なものと、その仕事のときだけ参照するものを分けます。

9〜15：仕事の流れの中に、確認する機会を置く

9. 調査や検証を役割で分ける。依頼には問いと報告形式を付け、結論の根拠を受け取ります。10. 整形や検査を、保存などの決まったタイミングで処理を動かすHooksへ組み込む。実行されたか、失敗したかが分かる記録を残します。11. レビューで得た学びを規則へ戻す。一度の例外を永久ルールにする前に、次の仕事にも適用する理由を確認します。

12. 現在地を見えるようにする。使用量や実行状態など、判断に必要な情報を表示します。13. 画面の仕事はブラウザでも確認する。HTMLを作っただけで表示確認済みとはしません。14. 分析では元データと集計条件を残す。数字の見栄えより再計算できることを優先します。15. 仕様が曖昧なら、実装が変わる質問を先にする。決まっている前提を何度も聞き直す必要はありません。

16〜20：文脈と外部ツールを増やし過ぎない

16. 共通規則と作業中の記録を分ける。CLAUDE.mdに案件の日誌を詰め込まず、必要な記録へ案内します。17. 対象別のルールを置く。フロントエンドとデータ移行では注意点が異なります。18. 会話を区切る基準を持つ。別案件へ移るなら、現在地を保存してから新しい会話に移ります。

19. 巻き戻せる範囲を理解する。チェックポイントは、外部に送った情報や実行した取引まで取り消すものではありません。20. MCP接続は仕事に必要なものから。接続先を増やすと、権限や管理の対象も増えます。まず読み取り中心の小さな仕事で動作を確かめます。

21〜24：非対話実行では「終わった」の根拠を作る

21. 非対話実行をスクリプトに組み込む。起動できたことと仕事が完了したことを分け、成果物を検査します。22. 大きな変更を独立した単位へ分ける。機械的にファイル数で割る前に、共通の型や設定への依存を確認します。

23. 課題管理から渡す内容を整理する。Issueの長い履歴をそのまま実装指示にせず、現在の仕様と完了条件を確認します。24. 必ず実行する検査を仕組みにする。守るべき条件があるなら、説明文だけに頼らず、適切な設定と検証を組み合わせます。具体的な作業例は公式のワークフロー集が参考になります。

25〜30：変化の速い機能は、昔の名前のまま使わない

25. コード整理とレビューの目的を分ける。原記事で登場するコマンド名や挙動は更新の影響を受けます。現在のヘルプと変更履歴を確認し、コードを書き換える仕事なのか、問題を報告する仕事なのかを明示します。26. GitHub連携には実行条件を設ける。メンションを受けたら何を許可するかを、リポジトリの運用に合わせます。

27. レビューの深さを変更の影響に合わせる。表示文言の修正と認証まわりの変更を同じ重さでは扱いません。28. 定期実行には重複防止と失敗記録を付ける。起動回数だけで成功を数えないようにします。29. 大きい計画を別環境へ渡すときは入力をそろえる。参照できるファイルや権限の違いを確かめます。

30. Remote Controlとクラウド実行を混同しない。接続しているセッションがどこで動くのかを確認します。ローカルのセッションを別端末から操作する用途についてはRemote Controlの公式説明を参照してください。画面を遠隔で開けることから、処理が自動でクラウドへ移ったとは判断できません。

1件の修正で「計画→検証→規則への反映」を試す

例えば問い合わせフォームで、送信後に完了表示が出ない問題を直すとします。最初に症状と再現手順を渡し、次のように依頼します。

対象フォームで送信後の完了表示が出ません。
入力内容、送信処理、完了表示のどこで止まるかを調べ、
原因の根拠と最小の修正計画を示してください。
修正後は正常送信と入力エラーの両方を、許可した検証環境で確認します。
本番の顧客データは操作しません。

計画では、送信そのものが失敗したのか、表示だけの問題なのかを確認します。実装後は、関連するテストと実画面の両方で結果を確認し、送信先に検証データが意図した件数だけ届いたかも見ます。未確認の範囲があれば、完了報告に残します。

同じ見落としが繰り返されるなら、「フォーム変更時は正常送信・入力エラー・二重送信を確認する」といった共通の条件をCLAUDE.mdへ反映します。長い手順はSkillへ分けます。単発の不具合の経緯をすべて常設ルールへ詰める必要はありません。この一連の例を確認できてから、別の仕事を並列で任せる範囲を広げます。

一つの変更で試す例：問い合わせフォームの送信ボタンを連打したときに二重登録される、という架空の課題を選びます。修正前はテスト用送信を2回行い登録件数を記録し、修正後は同じ操作で1件だけになるか、失敗時に再送できるかを確認します。実装担当と確認担当へ同じ条件を渡し、結果には画面・入力・登録件数・未確認事項を残します。実データへの送信で練習しないでください。

週に1度、導入数より完了した仕事を見直す

よくある質問

30項目を全部設定する必要はありますか？

ありません。現在の仕事で詰まっている箇所を選び、効果を確認してから範囲を広げます。

Borisと同じ並列数にすればよいですか？

レビューできる量や仕事の独立性が違います。まず少数の仕事で、統合と確認まで完了できるかを確かめます。

まとめ：完成条件と検証から始める

運用Tipsの価値は、設定をまねることより、仕事の進め方を変えることにあります。次の依頼に完成条件と検証方法を添え、繰り返した問題を1つだけ規則へ戻す。その小さな改善から取り入れると、並列化や自動化も目的を持って選べます。