Claude Code 30の運用Tips完全解説

Claude Codeの生みの親『Boris Cherny』が「これだけは押さえとけ」って言ってる運用Tipsを30個、今回の記事に自力で全部まとめました。マジで神記事です。 正直、これ知ってるか知らないかでClaude Codeの使い心地が天と地ほど変わります。毎回同じ指示繰り返してたあの時間、手戻りで溶かしてた1時間、全部要らなかったって気づきます。 ところで皆さん普段ClaudeCode使ってて、こんな悩み、ないですか？ ・Claude Code使ってるけど、毎回同じこと指示してる気がする。学習してくれよって思う ・大きめの変更を任せると手戻りばっかりで、結局自分で直した方が早かったってなる ・機能が多すぎて、結局どれから手をつければいいのか分からない ・会話が長くなると途中から噛み合わなくなって、「あれ、さっき言ったよね？」ってなる Claude Codeって、マジで文脈の持たせ方、検証のさせ方、権限の決め方、並列で動かす設計、自動化、このあたりをちゃんと組んで使うと、体感がガラッと変わります。 この記事は、Boris Cherny（Claude Codeを作った人）のX投稿、Anthropicの公式ドキュメント、GitHubの公式リポジトリと公式Action、このあたりを中心に2026年4月23日時点の一次情報を優先してClaudeCodeStudioが独自で調査し、執筆したものです！ Borisは「I created Claude Code（Claude Code作ったの俺です）」って明言してるので、彼の運用発言を現場の生の声として重視しつつ、CLIのオプションとか設定の細かいところは公式Docsで裏取りして今回の記事を書きました！😆 絶対にClaudeCode使ってる人なら見てください！！！ 保存も必須です！！！！ リアルに生産性１０倍は変わります！ではいきましょう！👇 ■ まず押さえてほしい3つの原則 Claude Codeを実戦で強くする最大の要因って、突き詰めると本当に3つしかないです。 Plan Modeで「調べる」と「実装する」を分けること。Claudeに自分の仕事を検証させること。そして並列セッションを前提に働くこと。 Borisも「Almost always use Plan mode（ほぼ常にPlan mode使え）」「give Claude a way to verify its output（Claudeに自分の出力を検証する手段を持たせろ）」「3〜5 git worktrees（worktreeを3〜5本並列で）」って繰り返し言ってます。 ■ 「唯一の正解はない」という考え方 Borisの投稿をいろいろ読んでいくと、Claude Codeに唯一の正解なんてないけど、めちゃくちゃカスタマイズできる運用ツールとして使え、というスタンスがよく出てきます。彼自身「there is no one right way to use Claude Code（使い方に唯一の正解はない）」と何度も繰り返してる。 その前提の上で、彼が言ってる一番効くワークフローはこんな感じ👇 Plan Modeで調査・計画 　 ↓ 実装セッション 　 ↓ テスト・スクリーンショット・CLIで自己検証 　 ↓ PR作成 　 ↓ Code Review / Ultrareview 　 ↓ 学びをCLAUDE.md・Hook・Skillに還元 この流れを頭に入れた状態で、具体的な30個のTipsを見ていきましょう。 ■ 30個の運用Tips 現場で効くやつから順に並べてます。BorisのX投稿で方向性が出てるやつはXを主にして、設定とか制約の細かい話は公式DocsとGitHubで補強。研究プレビュー機能はその旨ちゃんと明記してます。 ■ Tip 1：大きい変更はまずPlan Modeで分離する 調査・計画・実装を分けるだけで、誤実装と手戻りがガッと減ります。シンプルなんだけど、これがBorisが何度も「Almost always use Plan mode」と言う理由。 例えばこんな感じ👇 「Plan Modeで src/auth と secrets まわりを読んで。Google OAuth導入で影響するファイル、データの流れ、テストの観点を整理してから実装に入って。」 Plan Modeなしでいきなり大規模変更に突っ込むと、途中でcontext切れたり方向修正が入ったりします。先に全体像を掴ませるだけで、そのあとの実装精度が本当に変わります。 ■ Tip 2：Claude自身に検証させる Borisが「single highest-leverage thing（一番レバレッジが効くやつ）」と呼んでるのがこれ。テスト実行、スクリーンショット確認、CLI出力のチェック、こういうのをClaude本人にやらせる。 「修正したあと npm test を走らせて、全テスト通ることを確認してから完了にして。」 たったこれだけで、人間がレビューする前にClaude自身が問題見つけて直してくれます。検証コマンドが重すぎると時間食うので、最初は最低限のスモークテストから始めるのがおすすめ。 ■ Tip 3：3〜5本のgit worktreeを並列で回す Borisが「最重要の生産性ブースト」と言ってるのが並列worktree運用。 git worktree add ../repo-auth -b feat/auth みたいに複数のworktreeを切って、それぞれで別のclaudeを起動する。待ち時間がほぼゼロになって、独立したタスクを同時進行できます。 最適な本数は環境次第。3〜5本が目安だけど、レビューの捌ける量とかCPU、自分の頭の切り替えコストによっては、2本がちょうどいい人もいれば6本いける人もいる。自分の環境で実測するのが一番確実です。 ■ Tip 4：CLAUDE.mdを容赦なく編集し続ける CLAUDE.mdというのはプロジェクト固有のルールブックです。放置するとどんどん古くなって、Claudeが間違った前提で動き始める。 Borisの運用方針はめっちゃシンプルで、「Ruthlessly edit your CLAUDE.md over time（時間とともに容赦なく編集し続けろ）」「Add to it when Claude makes the same mistake a second time（同じミスを2回したら追記しろ）」。 逆に、いらなくなったルールは消す。膨らみすぎるとcontextを食うので、定期的に棚卸しして簡潔に保つのが大事です。 ■ Tip 5：毎日繰り返す作業はskills化してgitにコミット 繰り返しの手順を毎回会話で説明するのって、時間の無駄です。.claude/skills/deploy/SKILL.md を作っておいて /deploy staging で呼べばOK。 Borisいわく「If you do something more than once a day, turn it into a skill or command（1日1回以上やることはskillかcommandにしろ）」、しかも「costs almost nothing until you need it（使うまではほぼコストかからない）」。 ただSkillが膨らみすぎると、いつ発火するのか曖昧になるので、長い参考資料は分割した方がいいです。 ■ Tip 6：チーム共通設定はsettings.jsonに入れてgit管理する プロジェクト固有の設定をバージョン管理しておけば、チーム全員が同じClaude Code体験を得られます。新メンバーのオンボーディングも速くなるし、設定が誰か一人に依存しちゃう問題も防げる。 当たり前だけど、個人のAPIキーやトークンは絶対にコミットしないこと。.gitignoreの確認は忘れずに。 ■ Tip 7：安全な権限は事前承認、危険な領域はdenyする 毎回「この操作許可しますか？」と聞かれるの、地味にストレスじゃないですか？ allow / ask / deny を使い分けると、この確認ダイアログ疲れが消えます。 "allow": ["Bash(npm test *)"], "ask": ["Bash(git push *)"], "deny": ["Read(./.env)", "Read(./secrets/**)"] Borisは「Pre-approve common permissions（よく使う権限は事前承認しとけ）」と言ってて、公式Docsは「Rules are evaluated in order: deny… ask… allow（denyから順に評価）」と仕様を示してる。ワイルドカードを広げすぎると危険なので、.envとかsecrets系は明示的にdenyするのが原則。 ■ Tip 8：--add-dirで複数フォルダ・複数repoを跨がせる モノレポの外にあるドキュメントとかライブラリも見せたい場面、結構あります。 CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir ../docs --add-dir ../shared-libs これでドキュメントやライブラリを参照しながらコーディングできます。環境変数を有効にしないと、追加したディレクトリのCLAUDE.mdが読み込まれないので注意。 ■ Tip 9：subagentsを前提に役割分担する 調査・レビュー・デバッグを全部メインのcontextに突っ込むと、文脈がどんどん汚れてきます。Borisも「I use a few subagents regularly（いくつかsubagentを常用してる）」と言ってて、各subagentは自分専用のcontext windowで動きます。 code-reviewer、debugger、data-scientistみたいなsubagentを用意して、descriptionをはっきり書くこと。曖昧だと自動で振り分けが起きにくいし、使えるツールの制限設計も必要になります。 ■ Tip 10：PostToolUse hookで整形・検査を自動化 Claudeがファイル編集するたびに、formatterやlintを自動で走らせるやつ。 「Write a hook that runs prettier --write after every file edit.（ファイル編集後にprettier走らせるhook書いて）」 ってClaudeに頼めば、hookの生成から.claude/settings.jsonへの組み込みまでやってくれます。これだけでコードスタイルの統一が完全自動化されて、レビューでスタイル指摘するのが消える。 hookが重いとセッション全体が遅くなるので、実行時間の上限は設けておきましょう。 ■ Tip 11：PRコメントでCLAUDE.mdを更新する コードだけじゃなくて「これからのルール」もPRで一緒に変えちゃう。Borisは「tag @.claude on my coworkers' PRs to add something to the CLAUDE.md（同僚のPRに@.claudeつけてCLAUDE.mdに追記させることがある）」と言ってます。 例えば「@claude この学びをCLAUDE.mdに追記して。src/billing配下の変更は必ずPlan Modeから始める。」みたいにコメントする。同じ観点の指摘を次回以降減らせます。ただし局所的な事情を全体ルールにしすぎないように、スコープは必ず明示すること。 ■ Tip 12：status lineで今の状態を常に把握する 画面下に常時表示される情報で、「いま何をどのブランチでやっていて、contextをどれだけ使っていて、いくらかかっているか」が一目で分かります。 /statusline show model name, git branch, context percentage, cost まずは branch、context%、cost の3つだけ表示すれば十分。context切れとか別branch誤操作に早く気づけるようになります。 ■ Tip 13：Chrome拡張でフロントエンド作業を加速する Borisは「Use the Chrome extension for frontend work（フロントエンド作業にはChrome拡張を使え）」と推してます。ブラウザのログイン状態を共有できるので、スクリーンショット比較をClaudeに見せてUI確認をさせられる。 コードだけじゃ見えないUI崩れをClaude自身が検出してくれるのは大きい。ただしアクセシビリティとか体感速度まではスクリーンショットでは測れないので、必要に応じてLighthouseやe2eテストを併用します。 ■ Tip 14：分析タスクもCLI経由でClaudeにやらせる SQLやCLIをClaudeに使わせると、開発・分析・施策検討が同じ作業面に入ります。 「Use the bq CLI to pull last 7 days conversion metrics by channel, summarize anomalies, and suggest hypotheses.」 Borisが「Use Claude for data analysis」と言ってるように、開発者だけじゃなくプロダクト担当者にも効くTipsです。データ権限とかPII、コストには注意が必要で、CLIの認証と出力整形は先に整えておきましょう。 ■ Tip 15：仕様が曖昧ならまずClaudeにインタビューさせる 公式Docsに「Let Claude interview you」という一節があります。いきなり実装に入るんじゃなくて、まずClaudeに質問させて要件を引き出す。 仕様の穴が実装前に埋まるから、結果的に手戻りが圧倒的に減ります。特に「何を作るか」がふわっとしてる段階で効果大きい。 ■ Tip 16：CLAUDE.mdとauto memoryの役割を分ける ルールは人間がCLAUDE.mdに書く。発見された好みや癖はauto memoryにClaudeが覚える。この切り分けを意識するだけで、設定が散らからなくなります。 CLAUDE.mdにはbuild/test/conventionsを書いて、auto memoryにはローカルな学習やデバッグ癖を任せる。auto memoryはworking tree単位で読み込み量にも上限があるので、本当に重要なルールは必ずCLAUDE.md側に残すこと。 ■ Tip 17：パス別ルールとcompaction挙動を知った上で設計する monorepoでは「全体ルール」と「局所ルール」を分けるのが基本。ルートのCLAUDE.mdに全体規約、src/billingなどには局所規約を置く。 /compactのあとにサブディレクトリのCLAUDE.mdが読まれなくなる可能性があるので、明示的に再読込を指示する癖をつけておくといいです。 ■ Tip 18：文脈を積極的に管理する 公式Docsは「Manage context aggressively（文脈は積極的に管理しろ）」とはっきり書いてます。重要な運用知はCLAUDE.mdやskillへ昇格させて、/compactでcontext windowを定期的に整理する。進行中タスクの要点は/btwで差し込めます。 compactは戻せないので、重要情報は事前にCLAUDE.mdへ退避しておくこと。 ■ Tip 19：/rewindとcheckpointsで「怖い変更」を試す Claude Codeのすべての操作はcheckpointになります。Escを2回、または/rewindを開いて、message checkpointから code only / conversation only / both で戻せる。 深いリファクタとか代替実装を試すときに「戻せる」っていう安心感があると、探索の幅が広がります。ただし外部副作用がある作業（DB操作とかAPI呼び出し）はcheckpointでは戻せないので、そこは別途確認が必要。 ■ Tip 20：MCPサーバーで外部ツールと接続する Slack、Jira、データベース、社内API、これらをClaude Codeから直接操作できるようにすると、ツール間の移動が激減します。全部が同じ作業面で完結する世界はかなり快適。MCP接続先のセキュリティとアクセス権限は事前に整備しておくこと。 ■ Tip 21：非対話モード（claude -p）でスクリプト・CIに組み込む 非対話モードはClaude Codeの自動化入口。 claude -p "List all API endpoints" --output-format json claude -p "Analyze this log file" --output-format stream-json CI、pre-commit、スクリプト連携がこれだけで実現します。ただし非対話だと人間の介入がないので、出力形式と許可ツールを明示して、ログは必ず残すこと。 ■ Tip 22：大規模移行はclaude -pをファイル単位でfan-outする 1セッションで巨大移行を抱え込むのは無理があります。横に分散する方がいい。 for file in $(cat files.txt); do claude -p "Migrate $file..." --allowedTools "Edit,Bash(git commit *)" done 200〜2000ファイル級の移行でスループット出ます。ただし、いきなり全量で回さないこと。まず数ファイルで失敗パターンを洗い出してから全体に展開する。 ■ Tip 23：課題管理ツールから直接実装させる GitHub IssueやLinearのチケットをClaudeに読ませて、そのまま実装に入らせる。仕様と実装の距離が一気に縮まります。 ただしプロンプトインジェクションのリスクがある。外部入力を直接渡す場合は、内容を事前に検証すること。 ■ Tip 24：例外なく守らせたい規則はhooksで強制する CLAUDE.mdは「助言」、hooksは「実行」。この違いを混同しないのが大事。 「Write a hook that blocks writes to the migrations folder.」 「Write a hook that runs eslint after every file edit.」 公式Docsの言葉を借りると「zero exceptions（例外ゼロ）」「guarantee the action happens（その動作が確実に起こるようにする）」。毎回守るべき規則を人間のレビューに頼らず、hookで確実に実行する。 Hookが増えすぎると保守が重くなるので、まず「絶対に守るべき最小集合」から始めるのが正解。 ■ Tip 25：/simplifyで最近触ったコードを並列レビューさせる 3つのreview agentが重複・品質・効率を同時にチェックして、修正までやってくれる。 /simplify focus on memory efficiency リファクタの見落としが減って、コード品質が底上げされます。 ■ Tip 26：GitHub Actionで@claudeメンションを使う 公式のclaude-code-actionを使えば、PRやIssueで@claudeとメンションするだけで質問回答やコード変更実装ができます。GitHub上のやりとりだけでClaude Codeの力を使えるのは、チーム運用ではかなり便利。 ■ Tip 27：PRレビューはCode ReviewとUltrareviewを使い分ける 常設レビューと深掘りレビューは別物。日常的にはCode Reviewを有効化しておいて、マージ前に深く掘りたいときは /ultrareview または /ultrareview 1234 で実行する。 Borisが言う「team of agents runs a deep review（エージェント群が深いレビューを行う）」「fleet of specialized agents（専門化したエージェント群）」がこれ。どちらも研究プレビュー要素があるので、可用性・課金・認証の制約は事前に確認しておきましょう。 ■ Tip 28：決まった反復運用はRoutines化する 週次整備、APIトリガー、PR連動作業、こうした反復作業はクラウド常駐に寄せる。 /schedule daily PR review at 9am 公式Docsの「keep working when your laptop is closed（ラップトップを閉じていても動き続ける）」がまさにこれ。研究プレビューで仕様が変わりうるのと、GitHub triggerやAPI token管理の設計は別途必要。 ■ Tip 29：計画が重い案件はUltraplanでクラウドに逃がす terminalで計画を待つんじゃなくて、ブラウザで章ごとにレビューする。 /ultraplan migrate the auth service from sessions to JWTs terminalを塞がずに、より広い画面で計画を検討できます。研究プレビューなので、クラウド実行のコストとセキュリティは事前に検討すること。 ■ Tip 30：Remote Controlでクラウドセッションを操作する ローカルからクラウド上のClaude Codeセッションを制御する機能。研究プレビュー段階で、認証・ネットワーク・課金条件の確認が必要です。 ■ まだ固まってない運用ポイント 方向性は見えてるけど、ベストプラクティスが確立してない領域も正直に書いておきます。 Chrome拡張 + Lighthouse + axe + e2eテストの組み合わせは、スクリーンショット比較がUI崩れには効く一方で、アクセシビリティとか体感速度は測れない。段階的に追加しながら、どこまで自動化するか線引きする必要があります。 Stop hooksを使った「days at a time」運用も、長時間動かした実例はあるものの、障害復旧・再開戦略・監視条件の詳細は明示されてない。まずは1〜2時間のsoak testから始めて、ログ量、停止率、再起動手順、通知条件を決めてから延長するのが現実的です。 ■ どこから始めるか 開発者なら、まず「Tip 1・2・4・7・9・18」の6つだけ入れるのがいいです。Plan Mode、自己検証、CLAUDE.md更新、permissions設計、subagents、文脈整理。これだけでClaude Codeは「その場しのぎのチャット」から「継続的に学習する開発環境」に変わります。 プロダクト担当者なら「Tip 14・15・23・27・28」が効きます。CLIとMCPでデータ・課題・設計知見を同じ面に集約して、Interviewで仕様を掘って、レビューやRoutineで運用のループまで閉じる。単なる「文章生成」じゃなくて「プロダクト運営支援」としてClaude Codeを使えるようになります。 ■ 週次チェックリスト ・同じミスを二度指摘してないか → してたらCLAUDE.mdに追記 ・Skillやhookで吸収できる反復作業が残ってないか → あればskill化 ・context window使用率が高すぎないか → /compactの習慣を見直す ・worktreeの本数は適切か → レビュー帯域とCPUに応じて調整 ■ 結論 Claude Codeを実運用で使いこなす鍵は、「Plan → Verify → Persist → Automate」の順に、運用構成要素を一つずつ固めること。 Plan Modeで探索と実装を分離して、テスト・スクリーンショット・CLIで検証して、学びをCLAUDE.mdやhooksへ還元して、Routinesやfan-outで自動化する。この一連の流れが、Anthropic公式のagentic loop説明とBorisの運用発言の交点にある勝ち筋です。 「全部盛り」で始める必要はありません。まずTip 1・2・4の3つだけでも、Claude Codeとの開発体験は根本から変わります。 また、オープンチャットも始めました！ ここから参加できます👇 x.gd/b2zkP まだまだ、告知全然してないので数は少ないですが 今後ここで有益な情報も発信したり、無料セミナーを開いていこうかなと思っておりますので、よろしければぜひご参加ください😆 今後とも、有益な記事を書いていきますのでこのアカウントをどうかよろしくお願いいたします🙇 またこの記事が少しでも参考になった方へ。 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝗦𝘁𝘂𝗱𝗶𝗼 @ 𝗝𝗮𝗽𝗮𝗻（@ClaudeCode_love）は、 Claude Codeガチ勢3人で運営しているアカウントです。 実務レベルのCLI活用・自動化を毎日発信しています。 現在は上場企業とAIエージェントを共同開発中。 普段の発信内容👇 ・Claude CodeやClaudeを活用したリアルなプロダクト開発事例 ・Claude Code活用／Vibe Coding／開発トレンドの整理 ・海外のClaude Codeに関する最新情報 開発思想から設計、実装、改善まで、 「作って終わり」じゃなく動くプロダクトを世に出すところまでを 海外の情報や1次情報をまとめています。 ご関心のある方は、ぜひフォローしてチェックしてみてください👀有益だと思います！