Claude Codeの業務活用Tips 7選！

虎の穴ラボの古賀です。 主な担当は各プロダクトのセキュリティ対応、アーキテクト検討、フロントエンド設計＆実装です。

最近の推しは「ちいかわ」です。私はハチワレ推しですが妻はモモンガ推しで夫婦で楽しんでいます。 ハチワレの名言の「なんとかなれー」が最近のモットーです。

虎の穴ラボ Tech Talk #7 〜日々のAI活用〜 でClaude CodeのTipsとともに業務でどのように活用しているか？をご紹介致しましたが スライドでは読みづらい部分や時間の都合でご紹介しきれなかった部分、直近で変更した内容などがあったため、今回はブログとしてもご紹介させていただきたいと思います。

虎の穴ラボ Tech Talk #7で発表したスライドはこちらです。

www.docswell.com

Tipsは2025年12月〜2026年1月の数千件のプロンプト履歴を、カテゴリ分類→頻度集計→効果実感の3ステップで分析したなかから抽出した活用方法です。 自分の履歴を振り返ってみると「え、俺こんなにテスト実行ばっかりお願いしてたの？」と新鮮な発見もあって、なかなか面白い作業でした。みなさまのClaude Code活用の参考になれば幸いです。

最後の方にプロンプト履歴をClaude Codeで分析した方法も記載しています！ので、かなり長文となりますがよろしければご覧ください。

• 1. はじめに
  • 並列作業が前提
• 2. 活用Tips 7選
  • 開発・実装に関わるTips
    • Tips 1. 🏆 大規模マイグレーションの進め方
    • Tips 2. 🥇 仕様/不具合調査の進め方
      • 実行例：追加要望の影響調査
  • テスト・品質確認に関わるTips
    • Tips 3. 🥈 反復的なテスト・修正サイクル
      • 実行例：RSpec実行
    • Tips 4. 🥇 ブラウザ操作・動作確認
    • Tips 5. 🥈 テスト仕様書の自動作成
      • 実行例：シナリオテスト作成
  • レビュー・PR
    • Tips 6. 🥈 PRレビュー指摘への対応（ghコマンド）
      • 実施例：PRのCopilot指摘収集 → 計画作成
    • Tips 7. 🥈 PR作成を依頼する
  • 効率化・ナレッジ
    • Tips 8. 🥉 カスタムコマンド/スキルの作成
    • おまけ. 🥇 自己分析・Tips作成
• 3. 効果的に活用するための3原則
  • 原則 1. 反復的確認
  • 原則 2. 証跡重視
  • 原則 3. 最終確認は人間で
• 4. まとめ

---

1. はじめに

この記事で紹介するTipsは、日々の業務で蓄積された数千件のプロンプト履歴をClaude Code自身に分析させて抽出したものです。 完全に主観ではありますが、実際に効果を感じた度合いに応じて、以下のようにランク付けしています。あくまで体感値で実際に計測したわけではなく、以前の作業時間の記憶と感覚での比較です。 「うちの環境だと違う」ということもあるかも？しれませんが、目安として見ていただければ。。。

ランク	意味
🏆	体感で生産性2倍以上
🥇	体感で生産性1.5倍程度
🥈	体感で生産性1.3倍程度
🥉	体感で生産性1.2倍程度

並列作業が前提

Tipsの紹介に入る前に、私のClaude Codeの使い方の前提をお伝えします。基本的にターミナルを3つほど開いて並列作業しています。

• 1つ目：Planモードでコード修正 → 静的解析 → agent-browserで動作確認
• 2つ目：PRの指摘修正、コードレビュー、別タスクのPlan作成
• 3つ目：問い合わせや不具合調査のPlanと修正

さらに、同じプロジェクトを2つ以上cloneしておき、片方の .claude/rules/*.md に「並行作業用のプロジェクトなので、コード修正のみにとどめること」と書いておくと便利です。

AIに手を動かしてもらっている間に、自分は思考に集中できます。最初は「ターミナル3つも開いて何するの？」と思うかもしれませんが、慣れると1つでは物足りなくなります。

2つ目を開いた瞬間から「もう戻れないな・・・」と感じるはずです。

---

2. 活用Tips 7選

実際の業務で効果を感じたTipsをカテゴリ別に紹介します。各Tipsには効果ランクと実際のプロンプト例を添えています。

「これ、そのまま使えそう」と思ったものがあれば、ぜひ試してみてくださいね。

開発・実装に関わるTips

Tips 1. 🏆 大規模マイグレーションの進め方

とらのあな通販のSpring Framework 6.2への移行が決まった時、正直「これは何日かかるんだ...」と気が重くなりました。JDK 21、Tomcat10、依存ライブラリの互換性確認などなど、やることが多すぎて途方に暮れそうになります。

ところが、Claude Codeに計画から任せてみたら、予想以上にスムーズに進みました。全体の計画策定からブランチの分割、依存ライブラリの調査まで、一連の流れをClaude Codeと壁打ちしながら進められます。

最初は「まず計画を立てて」くらいのつもりで依頼したんですが、返ってきた計画が思いのほか的確で、「あ、これそのまま進められるな」と。勢いで一気に修正してしまっても、後から「フェーズごとにブランチを分けて」と指示すればきれいに整理してくれるので、とりあえず走り出してから考えるでも何とかなってます。

実際のプロンプト例

初期計画の依頼：

Spring Framework 6.2への移行を進めます。まずはOpenJDK 21へコンテナ環境を移行してください。 コンテナ環境を移行してください。また、Tomcatも10の最新版へ移行してください。

並行作業の依頼：

JDK21のセキュリティ回避設定を進めてください。

ブランチ分割の依頼：

一気に修正してしまったコードをフェーズごとにブランチで分けてください。

大規模な修正になるので、フェーズ単位で分けるように指示すると分けてくれます、失敗することもあるのでブランチはバックアップしましょう。 Claude Code自身も誤って混ぜてしまうことがあるので、それも含めて修正させます。

依存ライブラリのアップグレード検討：

httpclientの4系にアップデートするPRを作成してください。

httpclientの5系にアップデートするPRを作成してください。

4系と5系それぞれのPRを作成させて比較し、どちらを採用するか判断する使い方もできます。コードの差分を見ながら「5系のほうが将来の保守が楽そうだな」と判断材料にできるのは、Claude Codeに高速で両パターンを作らせるからこそです。

進め方のコツ

1. まずは計画作成を依頼する
2. レビューしやすいようにブランチを分けて作業を依頼する
3. 「ビルドが通るまで進めてから」PRを作成させる
4. 定期的にビルドエラーチェックを依頼する
5. アップグレードの検討材料としてAIに複数パターンを出させる

あと非常に困ったのは、とらのあな通販には元になったパッケージがあり単純なSpring Frameworkでないところが曲者です。

その元のパッケージがSpringFrameworkを6.2へアップデートした場合の差分が16万行あるのでそれをいただいて参考にしアップデートを進めますが、、、 （そのままパッチ適用はとらのあな通販向けにカスタマイズされているので難しい）

16万行の差分分析、、、みるだけで大変！ → 人：数十時間以上はかかりそう・・・ → AI：1hほど、AIの結果から内容の確認2〜3hで完了

AIに任せている間は、他のJSONパーサーの移行とかセッション管理の移行の設計や見積もりに集中できたのも良いところです。

差分の分析結果はタスク一覧にしてTSVを出力 → 「概要」「開発詳細」「開発工数」「テスト工数」の項目を指定 → 内容は人でチェック（多すぎたり少なかったりはある）

できた分析結果は以下のようになります。 （公開しても差し障りがない程度に省略しています）

概要	開発詳細	開発工数	テスト工数
JDK本体とTomcat本体のアップデート、VM引数を変更		xx	xx
インフラ・JDKを21へ移行 ・Tomcat本体を10へ移行	- OpenJDK 21への移行が必要 - AnsibleのJDK設定更新が必要 省略	xx	xx
Java 新しいリフレクションのセキュリティ回避設定	Tomcatとバッチ起動時にadd-opensを追加 以下省略	xx	xx
Java 起動オプションの変更	- 削除とか推奨するJVMオプション 以下省略	xx	xx
Maven、Gradleのバージョンアップ	以下省略	xx	xx
ライブラリの差し替え（クラスパスを移行）	以下省略	xx	xx
Tomcat10 ＆ Jakarta EE への移行 jarの差し替え	以下省略	xx	xx
〜.jar	以下省略	xx	xx

この工数見積もり表を元にアップデートの社内向けの提案書もMarkdownで作ってもらい、Googleドキュメントに変換しました。 （同じく公開しても差し障りがない程度に省略しています）

Tips 2. 🥇 仕様/不具合調査の進め方

「ログインして○○を開くと500エラーになる」——こういう報告を受けたとき、以前は関連しそうなファイルをgrepやVSCodeの検索で片っ端から探していました。コードベースが大きいと、それだけで数十分かかることもあります。

Claude Codeに症状を報告すると、ソースコードを横断的に調査して原因を特定し、修正計画まで立ててくれます。人間がgrepで探し回るよりも圧倒的に速いですね、、、

ただ、ここで学んだのはヒントの大切さです。最初の頃は「この不具合を直して」とだけ伝えていたんですが、見当違いの方向に調査が進んで時間を無駄にしたことが何度かありました。「たぶんセッション周りが怪しい」とか「最近このあたりのコード触ったからそれが原因かも」の一言を添えるだけで、セッション周りを念入りに調べたり、最近の関連するコード差分を先に調べたり、調査精度がまるで違います。

エンジニアの勘って、AIに伝える時にもちゃんと価値があるんですね！AIも賢いですが、まだまだ人間のエンジニアも捨てたものではありません。

基本的な進め方は「症状報告 → ソースコード調査で原因特定 → 再現確認 → 修正 → テスト追加」の流れです。

実際のプロンプト例

不具合の初期報告：

ソースコードから不具合の原因調査をお願いします。不具合の内容は、ログインして〜を開いて〜しようとすると〜というエラーが起きます。（原因の予想：〜）まずは原因を調査して修正の計画を立ててください。

修正後のテスト追加：

今回の不具合が起きないようにテストケースを追加してください。このテストをユニットテストなどで事前に気づく方法はありますか？

この最後の「事前に気づく方法はありますか？」がポイントで、再発防止だけでなく「同じ種類のバグを他にも仕込んでいないか」まで考えてくれることがあります。

他にも気をつけていることとしては、不具合の内容は具体的に書く（画面名と操作手順）、「ログを見て」と伝えるとログファイルも確認してくれる、修正後はテスト追加まで依頼して再発を防止する、という感じです。

なお、ブラウザ上での再現確認にはagent-browser（Vercel製のPlaywright CLIラッパー）が便利です。

github.com

実行例：追加要望の影響調査

これは自作のSKILLを利用して、マーケターからいただいた追加要望の調査をClaude Codeにやってもらった例です。

このSKILLはエージェントチームを組んで調査するようになっており、コンテキストは大量に消費しますがフロントエンドやバックエンドで別々のエージェントを立ち上げて並行して調査し、別のエージェントが整合性を確認しながら調査を実施してくれます。

その結果でてくる影響の調査結果は精度が高いものが出てくることが多いです。

❯ /investigation-team （依頼内容をまるごと貼り付ける） 

⏺ 調査テーマを分析し、プロジェクト構成を確認してチーム調査を開始します。

  まずプロジェクト構成を確認します。

⏺ Read 2 files (ctrl+o to expand)

⏺ プロジェクト構成を確認しました。フロントエンドとバックエンドの両方があるため、4人構成（調査員2人 + レビュアー2人）で調査を開始します。

  チームを作成し、タスクを定義します。

⏺ タスクの依存関係を設定しました。Stage 1の調査員2人を並列でスポーンします。

⏺ 2 agents launched (ctrl+o to expand)
   ├─ @frontend-investigator
   │  ⎿  Frontend investigation: xxxxx (↓ to manage)
   └─ @backend-investigator
      ⎿  Backend investigation: xxxxx (↓ to manage)

⏺ 調査員2人を並列でスポーンしました。調査結果が届くまで待機します。

  - frontend-investigator: フロントエンド観点でxxxxxを調査中
  - backend-investigator: バックエンド観点でxxxxxを調査中

  結果が届き次第、レビュアー2人に検証を依頼します。

⏺ 調査員が作業中です。結果を待っています...


@frontend-investigator❯ Frontend investigation results for xxxxx

⏺ フロントエンド調査員の結果が届きました。バックエンド調査員の結果を待っています...

⏺ バックエンド調査員の結果を待機中です。


@backend-investigator❯ Backend investigation results for xxxxxx

⏺ 両方の調査員から結果が届きました。Stage 2のレビュアー2人を並列でスポーンします。

⏺ 2 agents launched (ctrl+o to expand)
   ├─ @accuracy-reviewer
   │  ⎿  Accuracy review: xxxxx findings (↓ to manage)
   └─ @integration-reviewer
      ⎿  Integration review: xxxxx findings (↓ to manage)

⏺ レビュアー2人を並列でスポーンしました。検証結果を待っています...

  - accuracy-reviewer: 調査結果の事実正確性をコードを読んで検証中
  - integration-reviewer: フロント/バック間の整合性・完全性を検証中


@accuracy-reviewer❯ Accuracy review complete: all findings verified with corrections

@integration-reviewer❯ Integration review: xxxxx complete

⏺ 全レビュアーの結果が揃いました。タスクを完了させ、チームメイトをシャットダウンします。

✻ Cooked for 26m 41s

⏺ シャットダウンリクエストを送信しました。最終レポートを統合します。

  Investigation Report: xxxxxx（パターン1）

⏺ 調査チームの全メンバーが正常にシャットダウンし、クリーンアップが完了しました。

  上記の統合レポートが最終結果です。要点をまとめると：

  パターン1は技術的に実現可能で、影響範囲は比較的小さいです。

  xxxxxxxxxxxxx

  これらが決まれば実装に着手できる状態です。何かご質問があればお聞きください。

✻ Worked for 11m 23s

  ---
  仕様を整理すると：xxxxxx

  この仕様で実装方針をまとめると：


  ---
  xxxxxxx: 影響範囲の比較

  結論: 影響範囲はかなり広くなります。決済のクリティカルパスに手を入れる必要があり、リスクが高い。


# 結果を確認して、影響範囲の広さやリスクを共有

1次調査としては非常に優秀で、内容を確認して2次調査を実施して問題なさそうであればそのままマーケターへの説明にも利用できます。

テスト・品質確認に関わるTips

Tips 3. 🥈 反復的なテスト・修正サイクル

地味です。華やかさゼロです。でも、正直いちばんお世話になっているのがこれです。

修正後のテスト実行や静的解析は、もっとも頻繁に使うプロンプトで、1セッションで10回以上繰り返すことも珍しくありません。履歴を分析したとき、上位に来たプロンプトの大半が「もう一度テスト回して」系だったのは自分でも笑いました。

「もう一度テスト回して」——たったこの一言で、テスト実行→結果確認→エラー修正まで勝手に進めてくれるので、自分は次の修正に集中できます。

実際のプロンプト例

繰り返しテスト依頼：

他の箇所も修正したので、もう一度テストとチェックを実行してください。

修正後の確認：

修正したのでLintや他の静的解析でエラーが出てないか確認してください。

特定のテストの再実行：

RSpecでエラーが出ています、再実行してエラー内容を確認して修正してください。

重いコマンドの代行：

修正後にテストと静的解析とコンポーネントテストを実施して！

これの何がいいかというと、「テスト回すの面倒だから後でまとめて、、、」という先延ばしがなくなることです。以前の自分は、正直に言うと3〜4ファイル修正してPR作るまでテストを回さないことがザラでした。

で、まとめて回すとたくさんエラーが出て「どの修正が原因だ...？」と切り分けに時間がかかる。。。。。今は1修正ごとに気軽にテストを投げられるので、エラーが出ても原因が明白です。

こまめにテストを回す習慣がついたのは、Claude Codeを使い始めて一番変わったことかもしれません。

テストやビルドのように時間がかかるコマンドこそ、AIに任せて別作業を進めたり今後の作業を考える絶好のタイミングです。

実行例：RSpec実行

これも自作のSKILLを利用して、さくっと依頼できるようにしました。

このSKILLはRubyのテストを実施してくれますが、さらにテスト結果をPRに貼り付けやすいように整形してくれます。PRを作る場合も手間なし！です。

❯ /run-rspec https://github.com/xxx/xxx-xxx/pull/xxxx 

⏺ PR #xxx の差分からspecファイルを特定します。

⏺ Bash(gh pr diff xxxx --repo xxxx/xxxx --name-only | grep '_spec\.rb')
  ⎿  spec/models/xxxx_spec.rb

⏺ Bash(gh pr diff xxxx --repo xxxx/xxxx | grep '^+' | grep -E '^\+\s*(it|context|describe)\s' | sed
      's/^+//')
  ⎿      context
     'xxxxx
     ' do
           it 'xxxxx' do
     … +5 lines (ctrl+o to expand)

⏺ Bash(cd xxxx && docker compose exec xxxx grep -n
      "xxxxxxx"
      spec/models/xxxxxx_spec.rb && docker compose exec…)
  ⎿  Error: Exit code 1
     (eval):cd:1: no such file or directory: xxxx

     (eval):cd:1: no such file or directory: xxxx

⏺ Bash(docker compose exec xxxxx grep -n
      "xxxxxxx"
      spec/models/xxxxxxx_spec.rb && docker compose exec xxxxxxx grep…)
  ⎿  238:    context
     'xxxxxxx' do
     252:      it 'xxxxxxx' do
     … +8 lines (ctrl+o to expand)

⏺ PR #xxxx の差分から特定したテストケース:
  - spec/models/xxxxx_spec.rb:xxx (context "xxxxx")
# 省略

⏺ Bash(rspec ARGS="xxxxx_spec.rb:xxx spec/mod…)
  ⎿  Error: Exit code 2
     make: xxxxx: No such file or directory
     make: *** No rule to make target `xxxxx'.  Stop.

     make: xxxxx: No such file or directory
     make: *** No rule to make target `xxxx'.  Stop.

⏺ Read 1 file (ctrl+o to expand)
# ちょっと実行に失敗

# 再リトライ（自動で）
⏺ Bash(cd xxxx && rspec ARGS="spec/models/xxx_spec.rb:xxx spec/mod…)
  ⎿  🚀 バックエンドのテストを実行します...
     cd xxx && docker compose exec xxx bundle exec rspec spec/models/xxx_spec.rb:xxx spec/models/xxx_spec.rb:xxx spec/models/xxx_spec.rb:xxx spec/models/xxx_spec.rb:xxx … +21 lines (ctrl+o to expand)
  ⎿  (timeout 5m)

⏺ 全テストパスしました。結果をツリー形式で表示します。

  xxx
    #xxx
      xxxxxx
        aaaaa
        bbbbb
        ccccc
    #xxx
      xxxxxxx
        aaaaaaa

  ---
  4 examples, 0 failures  →  そのままPRに貼り付けしている
✻ Sautéed for 51s

テスト実行→結果確認→エラー修正までから、さらに次のタスクも楽にしてくれるには？を考えると自然とSKILLにできました。

Tips 4. 🥇 ブラウザ操作・動作確認

これは初めて使った時にちょっと感動しました。先ほども紹介したagent-browser（Vercel製のPlaywright CLIラッパー）を使うと、Claude Codeが実際にブラウザを開いて画面をポチポチ操作してくれるんです。ターミナルに操作ログが流れていくのを眺めながら「おお、ログインした...次のページに遷移した...」と見ているのは、不思議な体験でした。

（あ、、、失敗した、、、というのもよくあります。その場合はESCで止めて再指示します。）

github.com

しかもスクリーンショットや動画まで撮ってくれるので、PRの証跡や不具合報告にそのまま貼れます。自分でも同じ操作を試せばダブルチェックになりますし、「ここの画面遷移できない？」とAIが気づいてくれることもあって、思った以上に頼りになります。

（500エラーとかを気づかずに正常完了！と言ってきた時には笑いましたが、スクショのおかげで気づけました）

実際のプロンプト例

新規アプリの動作確認：

ブラウザを開いて動作確認をしてください。

確認結果からの修正指示：

ログインは成功してそうですが、ダッシュボードに遷移してもSign In画面のままです。修正してください。

証跡の取得：

このPRを作る前に動作確認の証跡のためのスクショが欲しいです。

agent-browserでの確認フロー：

agent-browserで動作確認して、スクショを見せてから次のPR作成作業を始めてください。

さらに、テストデータの作成から動作確認まで一気に進めることもできます。「ローカルDBにテスト用データを入れて、ブラウザで動作確認して」と指示するだけで、Rails系ならRails Console、JavaプロジェクトならDocker上のSQL Plusを使ってデータを作り、そのままブラウザで確認してくれます。この一連の流れを全部自動でやってくれるのは、本当に楽です。

このあたり、Rails系ならRails Consoleで既存のモデルの関数をそのまま使ってデータを入れてくれるので、入るデータの間違いもあまりありません。

一点だけ注意すると、ブラウザ操作は環境によってうまくいかないこともあります。最初の設定で「SSLの自己署名証明書によるエラー」「reCaptcha」系のエラーにハマりました。

SSLはChromiumを --ignore-certificate-errors 付きで起動し、agent-browserからCDP接続する。「reCaptcha」は無効化の手順をCLAUDE.mdに書くで解決しました。

Tips 5. 🥈 テスト仕様書の自動作成

テスト仕様書の作成って、地味に時間がかかりますよね。改修内容を整理して、テスト観点を洗い出して、ケースを書いて...。正直、開発は好きだけどテスト仕様書を書くのは苦手、という人も多いんじゃないでしょうか（自分もそうです）。

これをClaude Codeに任せたら、驚くほど早く下書きが出てきました。しかもロジック観点とデータ観点の両方からのテストケースを一連のシナリオで出してくれるので、自分では見落としていた観点に気づくこともあります。

前提として、PRの説明はある程度しっかり書いておくことと、マイルストーンを付与しておくことが必要です。ここが雑だとテスト仕様書の質も下がるので、後述のPR作成をClaude Codeに任せつつしっかり書くようにしています。

「テスト仕様書のためにPRの説明をしっかり書く」というのは一見遠回りですが、結果的にレビュアーにとっても読みやすいPRになるので、一石二鳥ですね。

実際のプロンプト例

初期依頼：

〜リポジトリのマイルストーン（マイルストーン名）が付与されたPRの改修内容の説明や修正されたソースコードを参考に、Markdownでシステムテストの仕様書を作成してください。ロジック観点とデータ観点から改修内容が正常に実装されているか確認するための仕様書にしてください。テスト仕様書はシステムを知らない開発者でもテストが可能なように分かりやすく作成してください。

テストケース数の最適化：

一連のケースで複数の観点を確認するようにして、確認する観点は減らさずにテストケース数を減らした新しいテストケースを別のファイルに作成してください。

工数見積もり：

このテストを実施するとしたら何時間程度かかりますか？

同僚からの指摘にも「指摘事項を対応して対応結果の差分を教えて」で対応できます。差分を見せてもらえるので、指摘が正しく反映されたかの確認もスムーズです。

実行例：シナリオテスト作成

これも自作のSKILLを利用して、さくっと依頼できるようにしました。履歴が残ってなかったので詳細な流れがお見せできず申し訳ないです。

このSKILLはマイルストーンのURLから対象のPRやIssueの概要、変更したコードを収集して、収集した結果からシナリオテストを作成してくれます。押すボタンの名前や画面名は必ずソースコードから収集するように指示していて、間違えることはあまりありません。

/generate-scenario-test マイルストーンのURL1 マイルストーンのURL2 マイルストーン名1 マイルストーン名2 作成フォルダ

↓ 
マイルストーン名の解決とPR収集

↓ 
エージェントチーム作成と調査タスク定義

↓ 
結果収集と統合

↓ 
テスト仕様書の出力（TSVまたはMarkdown）

・・・のような感じで出力されます

次は作成するシナリオテストのテンプレートの例です。テンプレートがあると、Claude Codeがだす結果が安定して良くなります。

ただ、思ったより良い構成がでることが少なくなるので、そのバランスです。余裕がある場合は、テンプレートなしで試しに出力したりします。

# シナリオテスト仕様書

## 1. テスト概要

- **マイルストーン**: {milestone_name}
- **対象リポジトリ**: {repos}
- **生成日**: {date}
- **テストケース数**: {total_cases}

### 対象PR一覧

| リポジトリ | PR# | タイトル | ラベル |
|-----------|-----|---------|--------|
| {repo} | #{number} | [{title}]({html_url}) | {labels} |

## 2. テスト環境・テストデータ準備

### 必要アカウント一覧


| # | アカウント種別 | 用途 | 準備手順 |
|---|-------------|------|---------|
| 1 | {種別} | {用途} | {手順} |

### テストデータ一覧

| # | データ項目 | 状態 | 準備方法 |
|---|----------|------|---------|
| 1 | {項目} | {状態} | {方法} |

### 環境設定

- {必要な環境設定項目}

## 3. シナリオテストケース

### 3.1 {機能エリア名}


#### TC-{N}: {テストケースタイトル}

- **対象PR**: #{number1}, #{number2}
- **テスト観点**: ロジック / データ / 決済
- **前提条件**:
  - {前提条件1}
  - {前提条件2}

**手順:**

| # | 操作 | 期待結果 |
|---|------|---------|
| 1 | {具体的な操作} | {期待される結果} |
| 2 | {具体的な操作} | {期待される結果} |

**検証ポイント:**

- [ ] {検証ポイント1}
- [ ] {検証ポイント2}
- [ ] {検証ポイント3}



**データパターン:**

| パターン | 入力値 | 期待結果 |
|---------|--------|---------|
| 正常系 | {値} | {結果} |
| 境界値 | {値} | {結果} |
| 異常系 | {値} | {結果} |

## 4. 決済リグレッションテストマトリクス

| テストケース | 決済方法 | 金額パターン | 状態遷移 | 検証ポイント |
|-------------|---------|------------|---------|------------|
| TC-{N} | {方法} | {パターン} | {遷移} | {ポイント} |

{決済関連の変更がない場合は「対象マイルストーンに決済関連の変更はありません」と記載}

## 5. テストデータ準備チェックリスト

- [ ] {準備項目1}
- [ ] {準備項目2}
- [ ] {準備項目3}

レビュー・PR

Tips 6. 🥈 PRレビュー指摘への対応（ghコマンド）

PR出したらCode RabbitやGitHub CopilotなどのAIレビューから20件くらい指摘が飛んできた...という経験、ありませんか？あの通知を見た瞬間の「うわ...」という気持ち。一つひとつ確認して対応するのは結構な手間です。

これもClaude Codeにまとめて投げると、指摘の妥当性を検証した上で対応してくれます。全部が全部対応すべきものとは限らないので、「この指摘は対応したほうがいい」「これは既存の設計意図があるのでスキップでOK」と仕分けてくれるのが地味にありがたい。

ghコマンドを利用するため、MCP（Model Context Protocol）と違ってPAT（Personal Access Token）の設定が不要で、gh auth login で認証済みならすぐに使えるのも嬉しいところです。MCPの設定で苦労した経験がある方は、ぜひこちらを試してみてください。

これまで紹介したTipsのGitHubからの情報収集や操作は、すべてghコマンドでClaude Codeが実施しています。

実際のプロンプト例

Code Rabbitの指摘確認：

{PRのURL}のCode Rabbitからのコメントについて、対応が必要か確認してください。

一括対応：

{PRのURL}のすべてのコメントに対応要否を返信してください。対応推奨から任意のものは対応してください。

指摘の妥当性検証：

{PRのコメントURL}のこの指摘は正しいでしょうか？

複数指摘の一括対応：

{PRのURL}のPRのCopilotからの次の指摘を対応してください。 {PRのコメントのURL}の指摘はSuggested changeの内容を確認して受け入れてください。 {PRのコメントのURL}指摘通りに対応してください。

コツとしては、指摘の妥当性をまず検証し、Planモードで計画させてから対応するとスムーズです。複数の指摘URLをまとめて依頼できるので、1つずつ対応するより効率的。対応後は「対応結果の差分をDiff形式で見せて」で確認し、GitHubコメントへの返信まで依頼できます。PR作成、レビュー、コメント返信、ラベル付与と、GitHub周りの操作は一通りClaude Code経由でできるので、ブラウザとターミナルを行き来する回数がかなり減りました。

実施例：PRのCopilot指摘収集 → 計画作成

❯ /collect-pr-comments https://github.com/xxxxx/xxxxxx/pull/xxxx/ 

⏺ PR #xxxx のコメントを収集します。

⏺ Bash(gh api repos/xxxxxx/xxxxxxx/pulls/xxxx/reviews)
  ⎿  [
       {
         "id": xxxxxxxxx,
     … +22 lines (ctrl+o to expand)

⏺ PR #xxxxx レビューコメント（Copilot: 6件）

  修正必要（must）: 2件

┌─────┬────────────────────┬─────────────────────────────────────────────────────────────────────────────────┬───────┐
  │  #  │      ファイル      │                                    指摘内容                                     │ 優先  │
  │     │                    │                                                                                 │  度   │
  ├─────┼────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼───────┤
  │ 1   │ xxxxx.vue: │ 文言不一致: xxxxxxx  │ 高    │
  │     │ xxx                │ xxxxx。統一が必要                                                        │       │
  ├─────┼────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼───────┤
  │ 2   │ xxxxxx.vue:x │ 同上                                                                            │ 高    │
  │     │ xx                 │                                                                                 │       │
  └─────┴────────────────────┴─────────────────────────────────────────────────────────────────────────────────┴───────┘

  提案（suggestion）: 2件

 ┌─────┬───────────────────────┬───────────────────────────────────────────────────────────────────────────┬────────┐
  │  #  │       ファイル        │                                 指摘内容                                  │ 優先度 │
  ├─────┼───────────────────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
  │ 3   │ xxxxxxxxx.vue:xxx │ xxxxxの日付判定をxxxxxxに変更（コードベースの一貫性） │ 中     │
  ├─────┼───────────────────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
  │ 4   │ xxxxxxxx.vue:xxx  │ 同上                                                                      │ 中     │
  └─────┴───────────────────────┴───────────────────────────────────────────────────────────────────────────┴────────┘

  軽微（nits）: 2件

  ┌─────┬───────────────────────────┬──────────────────────────────────────────────────────────────┬────────┐
  │  #  │         ファイル          │                           指摘内容                           │ 優先度 │
  ├─────┼───────────────────────────┼──────────────────────────────────────────────────────────────┼────────┤
  │ 5   │ xxxxxxxx.vue:xxx-xxx │ 〜条件が外側のxxxxxxと重複。削除推奨 │ 低     │
  ├─────┼───────────────────────────┼──────────────────────────────────────────────────────────────┼────────┤
  │ 6   │ xxxxxxx.vue:xxx-xxx  │ 同上（xxxxxxxx）                                │ 低     │
  └─────┴───────────────────────────┴──────────────────────────────────────────────────────────────┴────────┘

  これらの指摘について修正計画を立てますか？

⏺ User answered Claude's questions:
  ⎿  · これらのCopilot指摘に対応しますか？ → 全て対応で文言は「xxxxxxx」の方に合わせてください。
     · 文言はどちらに統一しますか？ → xxxxxxx

⏺ 了解しました。全ての指摘に対応し、文言は「xxxxxxx」に統一します。

  修正計画を立てるため、対象ファイルを確認します。

⏺ Bash(git show origin/feature/xxxxxxxxx:components/xxxxxx/xxxxxxx.vue | head -600 | tail -300)
  ⎿                  </div>
                   </div>
                 </div>
     … +70 lines (ctrl+o to expand)

⏺ 対象コードを確認しました。PRの文言を「xxxxxxxxxx」に合わせるため、PRタイトルと説明を更新する必要があります
  。

  修正計画をまとめます。

⏺ Updated plan
  ⎿  /plan to preview

⏺ 計画を作成しました。

Tips 7. 🥈 PR作成を依頼する

PRの概要を書くのって、地味に面倒じゃないですか？修正内容を思い出しながら「どう説明したら伝わるかな」と考えて、テンプレートを埋めて...。これが1日に何本もあると、それだけでかなりの時間を使ってしまいます。

ブランチ作成からPR作成まで、一連の作業をClaude Codeに任せてしまえば、その間に次の作業に取りかかれます。

実際のプロンプト例

ブランチ作成からPR作成まで：

〜の形式で別ブランチを作って、プッシュとPR作成を実施してください。PRレビューのしやすさや理解を第一に、この不具合を詳しく知らない人でもわかるようにPRの概要を作成してください。

コミット分割：

一気に修正してしまったコードをフェーズごとに分割してPUSHしてください。

CLAUDE.mdに以下の内容を書いておくと、毎回「PR作って」と指示するたびに自動的に考慮してくれます。

• PRテンプレートの場所
• 使用するラベルの一覧
• ブランチ命名規則

これ、一度設定してしまうと本当に楽で。以前は「あれ、このプロジェクトのブランチ名ルールなんだっけ」とSlackを遡って確認していた時間がゼロになりました。CLAUDE.mdは「チームのお約束を集めておく場所」として機能するので、新メンバーが入った時に「CLAUDE.md読めばわかるよ」と言えるのも副次的な効果です。

テスト仕様書（Tips 5）を作る際にも、PRの説明がしっかり書かれていることが重要なので、ここを丁寧にやっておくと後工程が楽になります。

効率化・ナレッジ

Tips 8. 🥉 カスタムコマンド/スキルの作成

「あれ、前もこれと同じ指示を書いたな」と思ったら、コマンド化のチャンスです。

きっかけは、APIのテストコードを3回連続で似たようなプロンプトを書いて作ったときでした。3回目に「これ、毎回同じこと書いてるな...」と気づいて、Claude Codeに「今回のテスト作成を別のAPIクラスに対して指示するためのカスタムコマンドをプロジェクト内に追加してください」と依頼しました。

実際のプロンプト例

実装例：

/create-api-test 〜Api

このように、APIクラス名を渡すだけで対応するテストを自動生成するカスタムコマンドを作成できます。GitHubにコミットすれば、チームメンバー全員が同じコマンドを使えるようになるのも嬉しいところです。

一度コマンドを作ってしまうと「あ、これもコマンドにしたい」「これも」と欲が出てきて、気づくとコマンドが増えていきます。個人的にはこの「自分の仕事を仕組み化していく感覚」がけっこう楽しいです。プログラマの三大美徳の「怠惰」ってこういうことだよな、と思いながらコマンドを量産しています。

Claude Codeでテストを作成したセッションの知見を、そのままコマンド化に活用できるのも効率的です。「うまくいったセッションの手順をそのままコマンドにして」と依頼するだけで、次回からは一発です。

おまけ. 🥇 自己分析・Tips作成

ここまで読んでいただいた方はお気づきかもしれませんが、実はこの記事自体がこのTipsの成果物です。

Claude Codeに自分のプロンプト履歴を分析させて「どんな使い方をしているか」をまとめてもらったら、それがそのままブログのネタになりました。完全にマッチポンプです。でも、けっこう実用的なマッチポンプです。

面白かったのは、自分が「これが一番便利だ」と思っていた機能と、実際に一番使っていた機能が違ったこと。頭では「マイグレーションで生産性爆上がり！」と思っていたんですが、履歴を見たら一番多いのは「テスト回して」でした。地味な作業ほど頻度が高くて、積み重なると大きな時短になるんだなと。

実際のプロンプト例

@/Users/xxxx/.claude/history.jsonl を見て、Claude Codeをどのように活用しているかTipsをまとめてください。ブログの元ネタや社内の技術共有会の資料の元ネタにしたいと思っています。

ランク付けを依頼する場合：

また、次のようにランク付けしてください。🏆：とても効果ある、🥇：すごい効果ある、🥈：そこそこ効果がある、🥉：まあまあ効果ある

活用シーン

• ブログ記事の元ネタ（まさにこれ）
• 社内技術共有会の資料
• チームへのナレッジ共有
• 自分の使い方の振り返りと改善

---

3. 効果的に活用するための3原則

Tipsを実践する中で「こうしておけばよかった」と思うことが何度かありました。その反省も含めて、常に意識しておきたい3つの原則をまとめます。

原則 1. 反復的確認

修正→テスト→確認のサイクルを繰り返し回すことが重要です（→ Tips 3）。

Claude Codeで作ったし「一発で動かなくても時間的になんとかなる」と思ってテストをサボると、あとから連鎖的にバグが出てきて余計に時間がかかった...という経験が何度かあります。

ある時は、3ファイルまとめて修正した後にテストを回したら5件エラーが出て、どの修正が原因かの切り分けだけで30分かかりました。あの30分があれば、こまめにテストを回す時間は十分お釣りが来ます。

Claude Codeなどのコーディングエージェントを使った場合は修正したコードや周辺のコードを把握しきれてないこともあるので、面倒でもテストや静的解析、レビューはとくにこまめに回しましょう。その方がきっと近道です。

原則 2. 証跡重視

調査結果やスクリーンショットなど、証跡（エビデンス）を残すことを意識します（→ Tips 4）。

AIに「証跡をまとめて」と依頼すると、どのファイルのどの行を確認したか明示してくれるため、後から検証しやすくなります。これは人間がAIの回答を信頼できるかどうかの判断材料にもなります。「AIがこう言ってました」より「AIがこのファイルのこの行を根拠にこう判断しました」のほうが安心です。

AIの結果に不安がある場合はなぜ、その考えに至ったか確認しつつ証跡を要求するようにしましょう。その方がAI自身も見直しになり問題を自身で検出してくれる可能性が上がります。

原則 3. 最終確認は人間で

AIはあくまで補助的なツールです。 最終確認・最終判断は必ず人間が行います。

• コードレビューは人間の目で確認する
• ビジネスロジックの正しさは人間が判断する
• セキュリティに関わる部分はとくに慎重に確認する

「AIがOKと言ったからOK」で済ませていると、いずれ痛い目に遭います。実際、自分も「AIが大丈夫と言った画面がテスト環境で確認したら500エラーだった」という経験をしています。テストでエラーが出るとローカルで気づくより修正の負荷も時間も修正やPRの再提出が必要になり、AIを使っていてせっかく早く完了したのに無駄に時間がかかってしまいます。

その時の教訓は今でも生きています。ここだけは手を抜かないようにしましょう。

---

4. まとめ

この記事では、数千件のプロンプト履歴から抽出したClaude Codeの業務活用Tips 7選+αをご紹介しました。Tipは追加で2個をご紹介致しましたが勢いで増やしてしまいました。

振り返ってみると、使い始めた頃は「本当にAIにコード書かせて大丈夫なのかな」と半信半疑でした。今では「これなしでどうやって仕事してたんだっけ」と思うくらい手放せなくなっています。大規模マイグレーションからバグ調査、テスト仕様書の作成まで、AIが得意なことはどんどん任せて、自分は判断や設計に集中する。この分業がうまく回ると、仕事が楽しくなります。

ただし、良さそうに見えても後で見返すと「ここ微妙だな」というところは正直あります。この記事だって、AI(Claude Code)に履歴を分析させてTipsの骨子を作ってもらいましたが、最終的にそれから肉付けして書いたのは自分です。

みなさまもClaude Codeの活用Tips、ぜひ試してみてください。ハチワレの「なんとかなれー」の精神で、まずはAIを気軽に使ってみるところから始めてみてはいかがでしょうか。

最後までご覧いただき、ありがとうございました！