Claude Code社内勉強会の資料を発表

TORANOANA Lab Claude Code社内勉強会の 資料を発表 社内で発表した個人的なTipsの7⃣選を抜粋 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

自己紹介 所属 虎の穴ラボ株式会社 AT&CSIRT チーム 主な担当 各プロダクトのセキュリティ対応、 図があるとき アーキテクト検討、フロントエンド設 計＆実装 ✅ 設計＆実装 → 最近、かなり多め 最近の推し ：ちいかわ Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

目次 ● ● 活用Tips 7⃣ 選 ○ 1. 🏆大規模マイグレーションの進め方 ○ 2. 🥈反復的なテスト・修正サイクル ○ 3. 🥈PRレビュー指摘への対応 ○ 4. 🥇仕様/不具合調査の進め方 ○ 5. 🥇ブラウザ操作・動作確認 ○ 6. 🥈テスト仕様書の自動作成 ○ 7. 🥈PR作成を依頼する まとめ Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

活用Tips 7⃣ 選 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

Tipsのランクづけ ● 🏆：とても効果ある ● 🥇：すごい効果ある ● 🥈：そこそこ効果がある ● 🥉：まあまあ効果ある → 普段は右の画像のような感じで 並列作業してます （中には時間がかかるタスクもある ため） → 次ページ以降、右の黒い部分は あまり読み上げません （後ほど資料確認を願います） Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

SpringFramework / JDK →21 の移行などで実施、実際のプロンプト例 1. 🏆大規模マイグ レーションの進め方 初期計画の依頼 ● Spring Frameworkへの移行を進めます。まずはOpenJDK 21へ ● コンテナ環境を移行してください。また、Tomcatも10の最新版へ移行 してください。 並行作業の依頼 ● 別のタスクでJDKやTomcat自身のアップデートが走っているので、 並行してJDK21のセキュリティ回避設定を進めてください。 1. 計画作成を依頼 2. レビューしやすいようにブランチ を分けて作業を依頼 3. 「ビルドが通るまで進めてから」 PRを作成 4. 定期的にビルドエラーチェックを 依頼 5. アップグレードの検討材料 ブランチ分割の依頼 ● 一気に修正してしまったコードをフェーズごとにブランチで分けてくだ さい → 修正単位で分けるように指示すると分けてくれる → AI自身も誤って混ぜてしまうことがあるので修正させる ドキュメント化 ● ここまでの計画と今後の予定を精査して作成し Markdown（または CSV）として書き出してください。タスクリストや見積もりのベースに します 依存ライブラリの調査、アップグレード検討 ● httpclientの4系にアップデートするPRを作成してください。 ● httpclientの5系にアップデートするPRを作成してください → 4系と5系のPRを比較して、どちらを採用するか決める Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

とらのあな通販には元になったパッケージがある 元のパッケージがSpringFrameworkをアップデートした場合の 差分が16万行あるのでそれを参考にアップデートが必要 （そのまま適用はカスタマイズされているので不可） 16万行の差分分析、、、みるだけで大変 → 人：16h以上はかかりそう → AI：1hほど、AIの結果から内容の確認2〜3hで完了 進め方の詳細 1. 差分から見積もり（タスク 一覧と予想工数）を作成 2. さらにタスク一覧から提案 書なども作成 他のJSONパーサーの移行とかセッション管理の移行の設計や見 積もりに集中できた。 差分の分析結果はタスク一覧にしてTSVを出力 → 「概要」「開発詳細」「開発工数」「テスト工数」の項目を 指定 → 内容は人でチェック（多すぎたり少なかったりはある） Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

見積もりシートの一部（ TSVを貼り付けて整形したものの一部） 概要 開発詳細 JDK本体とTomcat本体のアップデート、VM引数を 変更 インフラ・JDKを21へ移行 ・Tomcat本体を10へ移行 - OpenJDK 21への移行が必要 - AnsibleのJDK設定更新が必要 省略 Java 新しいリフレクションのセキュリティ回避設定 Tomcatとバッチ起動時にadd-opensを追加 以下省略 Java 起動オプションの変更 - 削除とか推奨するJVMオプション 以下省略 Maven、Gradleのバージョンアップ 以下省略 ライブラリの差し替え（クラスパスを移行） 以下省略 Tomcat10 ＆ Jakarta EE への移行 jarの差し替え 以下省略 〜.jar 以下省略 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

提案書の一部 Markdownを貼り付けて整形 したものの一部 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実際のプロンプト例 → 静的解析とテスト再実行と結果の確認の繰り返しは数十分かかるので面倒 2. 🥈反復的なテスト ・修正サイクル ● 修正→確認→修正のサイ クルをループで品質確保 ● 人が修正した場合のテス トや静的解析を指示 ● 時間のかかるコマンドは AIに任せて、その間別作 業をする 繰り返しテスト依頼（実際に10回以上使用） ● 他の箇所も修正したので、もう一度テストとチェックを実行してくださ い 修正後の確認 ● 修正したのでLintや他の静的解析でエラーがでてないか確認してくだ さい 特定のテストの再実行 ● RSpecでエラーが出ています、再実行してエラー内容を確認して修正 してください。 重いコマンドを代わりにやってもらう ● 修正後にテストと静的解析とコンポーネントテストを実施して！ 別作業の例 ● 他の担当のPRコードレビュー ● 別の改修の設計（これもAIとプランニング） ● PR指摘の対応（AIで収集して要約、よければそのまま修正） Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例： RSpec実行（1/3、自作SKILL利用） ❯ /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 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例： RSpec実行（2/3） ⏺ 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'. ⏺ Read 1 file (ctrl+o to expand) # ちょっと実行に失敗 Stop. Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例： RSpec実行（3/3） # 再リトライ（自動で） ⏺ 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 ✻ Sautéed for 51s → そのままPRに貼り付けしている Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

3. 🥈PRレビュー指 摘への対応 （ghコマンド） ● Code Rabbit / Copilot からの指摘を効率的に処 実際のプロンプト例 Code Rabbitの指摘確認 ● {PRのURL}のCode Rabbitからのコメントについて、対応が必要か 確認してください。 一括対応 ● {PRのURL}のすべてのコメントに対応要否を返信してください。対応 推奨から任意のものは対応してください。 指摘の妥当性検証 ● {PRのコメントURL}のこの指摘は正しいでしょうか？ 理 ● MCPと違ってPATが不要 （gh auth loginで認証済 で使える） ● PR作成、レビュー、コメン ト返信やラベル付与も可 複数指摘の一括対応 ● {PRのURL} のPRのCopilotからの次の指摘を対応してください。 ● {PRのコメントのURL} の指摘はSuggested changeの内容を確認し て受け入れてください。 ● {PRのコメントのURL} 指摘通りに対応してください。 PRレビュー → Planモードで修正 ● {PRのURL} のPRをレビューしてください → そのままPlanモードに入って修正を指示 能 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

3. PRレビュー指摘への対応のポイント （ghコマンド） ● 指摘の妥当性を検証し Planで計画させてから対応 ● 複数の指摘 URLをまとめて依頼可能 ● 「対応結果の差分を Diff形式で見せて」で確認 対応後に GitHubコメントへの返信も依頼可能 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例： PRのCopilot指摘収集 → 計画作成（ SKILL利用） ❯ /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件 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例： PRのCopilot指摘収集 → 計画作成 ┌─────┬────────────────────┬─────────────────────────────────────────────────────────────────────────────────┬─────── ┐ │ # │ ファイル │ 指摘内容 │ 優先 │ │ │ │ │ 度 │ ├─────┼────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼─────── ┤ │ 1 │ xxxxx.vue: │ 文言不一致: xxxxxxx │ 高 │ │ │ xxx │ xxxxx。統一が必要 │ │ ├─────┼────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼─────── ┤ │ 2 │ xxxxxx.vue:x │ 同上 │ 高 │ │ │ xx │ │ │ └─────┴────────────────────┴─────────────────────────────────────────────────────────────────────────────────┴─────── ┘ 提案（suggestion）: 2件 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例： PRのCopilot指摘収集 → 計画作成 ┌─────┬───────────────────────┬───────────────────────────────────────────────────────────────────────────┬────────┐ │ # │ ファイル │ 指摘内容 │ 優先度 │ ├─────┼───────────────────────┼───────────────────────────────────────────────────────────────────────────┼────────┤ │ 3 │ xxxxxxxxx.vue:xxx │ xxxxxの日付判定をxxxxxxに変更（コードベースの一貫性） │ 中 │ ├─────┼───────────────────────┼───────────────────────────────────────────────────────────────────────────┼────────┤ │ 4 │ xxxxxxxx.vue:xxx │ 同上 │ 中 │ └─────┴───────────────────────┴───────────────────────────────────────────────────────────────────────────┴────────┘ 軽微（nits）: 2件 ┌─────┬───────────────────────────┬──────────────────────────────────────────────────────────────┬────────┐ │ # │ ファイル │ 指摘内容 │ 優先度 │ ├─────┼───────────────────────────┼──────────────────────────────────────────────────────────────┼────────┤ │ 5 │ xxxxxxxx.vue:xxx-xxx │ 〜条件が外側のxxxxxxと重複。削除推奨 │ 低 │ ├─────┼───────────────────────────┼──────────────────────────────────────────────────────────────┼────────┤ │ 6 │ xxxxxxx.vue:xxx-xxx │ 同上（xxxxxxxx） │ 低 │ └─────┴───────────────────────────┴──────────────────────────────────────────────────────────────┴────────┘ Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例： PRのCopilot指摘収集 → 計画作成 これらの指摘について修正計画を立てますか？ ⏺ 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タイトルと説明を更新する必要があります 。 修正計画をまとめます。 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実際のプロンプト例 4. 🥇仕様/不具合調 査の進め方 ● バグ報告または調査依頼 → ソースコードの調査で 特定 → agent-browserなど で再現させる → （Plan解除）修正＆再 不具合の初期報告 ● ソースコードから不具合の原因調査をお願いします。 不具合の内容は、ログインして〜を開いて〜しようとすると〜というエ ラーが起きます。 （不具合の原因の予想、同僚の助言やヒントがあれば書く） ますは原因を調査して修正の計画をたててください。 重要 ● ● 予想やヒントを与える 不具合の内容を具体的に書く（画面名で何をしたらおきるか） ログ確認の依頼 ● ログを見てというとみてくれる。 修正後のテスト追加 ● 今回の不具合が起きないようにテストケースを追加してください → このテストをユニットテストなどで気づく方法はありますか？ → 統合テスト（Request Spec）はRailsで追加できますか？ 現しないことを確認 → テスト追加 で進める Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例：追加要望の影響調査（ 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人を並列でスポーンしました。調査結果が届くまで待機します。 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例：追加要望の影響調査（ SKILL利用） - frontend-investigator: フロントエンド観点でxxxxxを調査中 - backend-investigator: バックエンド観点でxxxxxを調査中 結果が届き次第、レビュアー2人に検証を依頼します。 ⏺ 調査員が作業中です。結果を待っています... @frontend-investigator❯ Frontend investigation results for xxxxx ⏺ フロントエンド調査員の結果が届きました。バックエンド調査員の結果を待っています... ⏺ バックエンド調査員の結果を待機中です。 @backend-investigator❯ Backend investigation results for xxxxxx ⏺ 両方の調査員から結果が届きました。Stage 2のレビュアー2人を並列でスポーンします。 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例：追加要望の影響調査（ SKILL利用） ⏺ 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 ⏺ シャットダウンリクエストを送信しました。最終レポートを統合します。 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例：追加要望の影響調査（ SKILL利用） Investigation Report: xxxxxx（パターン1） ⏺ 調査チームの全メンバーが正常にシャットダウンし、クリーンアップが完了しました。 上記の統合レポートが最終結果です。要点をまとめると： パターン1は技術的に実現可能で、影響範囲は比較的小さいです。 xxxxxxxxxxxxx これらが決まれば実装に着手できる状態です。何かご質問があればお聞きください。 ✻ Worked for 11m 23s --仕様を整理すると：xxxxxx この仕様で実装方針をまとめると： Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例：追加要望の影響調査（ SKILL利用） バックエンド変更箇所 xxxxxxxxx フロントエンド変更箇所 xxxxxxxxx この方針で進めてよろしいですか？ ✻ Churned for 1m 15s # この時点の仕様をマーケターに共有 ❯ さらなる xxxxx（追加要件）をさせる場合は影響範囲は広くなりすぎますか、検討してください。 ⏺ xxxxxxについて、影響範囲を調査します。 ⏺ Searched for 7 patterns, read 6 files (ctrl+o to expand) ⏺ 調査結果をまとめます。 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例：追加要望の影響調査（ SKILL利用） --xxxxxxx: 影響範囲の比較 結論: 影響範囲はかなり広くなります。決済のクリティカルパスに手を入れる必要があり、リスクが高い。 # 結果を確認して、影響範囲の広さやリスクを共有 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実際のプロンプト例 5. 🥇ブラウザ操作・ 動作確認 ● スクショやスクリーン動画 を撮ってくれる → PRや仕様や不具合の 調査依頼の結果に利用 ● 自分でも試すとダブル チェックになる （品質Up） 新規アプリの動作確認依頼 1. ブラウザを開いて動作確認をしてください → ログインは成功してそうですが、ダッシュボートに遷移しても Sign IN画面のままです。意図通りでしょうか？修正してください 2. （Claude Codeが修正、、、） 3. → ログインして、ダッシュボードが表示されました！ 4. → 次の実装を進めてください 証跡の取得 ● PRを作る前に修正と他の動作確認、動作確認の証跡のためのスクショ が欲しいです。リンクは本文の色と合わせて下線を引くように修正して ください。 agent-browserでの確認 ● スクリーンショットを確認しました。〜の文言を消して、〜をリンクに 修正してください。 ● agent-browserで動作確認して、スクショを見せてから次の PR作成 作業を始めてください。 テストデータ作成から動作確認まで ● ローカルDBのデータを確認して、テスト用データを作るように指示 → Rails系はRails Consoleで作り始める → JavaプロジェクトならDocker上のSQL Plusやコードで作り始め る Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実際のプロンプト例 6. 🥈テスト仕様書の 自動作成 ● PRの改修内容からシステ ムテスト仕様書の下書き を作成 ● PRの説明や内容はある 程度書く ● マイルストーン付ける必 要あり 初期依頼 ● 〜リポジトリのマイルストーン（マイルストーン名）が付与された PR の改修内容の説明や修正されたソースコードを参考に、 Markdownでシ ステムテストの仕様書を作成してください。 ● システムテストの仕様書にはロジック観点とデータ観点から改修内容が 正常に実装されているか、確認するための仕様書を作成します。 ● テスト仕様書はシステムを知らない開発者でもテストが可能なように分 かりやすく作成してください。 工数見積もり ● このテストを実施するとしたら何時間程度かかりますか？ テストケース数の最適化 ● 一連のケースで複数の観点を確認するようにして、確認する観点は減ら さずにテストケース数を減らした新しいテストケースを別のファイルに 作成してください。 同僚からの指摘対応 ● 次のような指摘がありました。指摘事項を対応して 対応結果の差分を教えてください。 [以下省略] Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実行例：シナリオテスト作成（ SKILL利用） （履歴が残ってなかった） /generate-scenario-test マイルストーンのURL1 マイルストーンのURL2 マイルストーン名1 マイルストーン名2 作成フォルダ ↓ マイルストーン名の解決とPR収集 ↓ エージェントチーム作成と調査タスク定義 ↓ 結果収集と統合 ↓ テスト仕様書の出力（TSVまたはMarkdown） ・・・のような感じで出力されます Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

テンプレート例：シナリオテスト作成（ SKILL利用） # シナリオテスト仕様書 ## 1. テスト概要 - **マイルストーン**: {milestone_name} - **対象リポジトリ**: {repos} - **生成日**: {date} - **テストケース数**: {total_cases} ### 対象PR一覧 | リポジトリ | PR# | タイトル | ラベル | |-----------|-----|---------|--------| | {repo} | #{number} | [{title}]({html_url}) | {labels} | ## 2. テスト環境・テストデータ準備 ### 必要アカウント一覧 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

テンプレート例：シナリオテスト作成（ SKILL利用） | # | アカウント種別 | 用途 | 準備手順 | |---|-------------|------|---------| | 1 | {種別} | {用途} | {手順} | ### テストデータ一覧 | # | データ項目 | 状態 | 準備方法 | |---|----------|------|---------| | 1 | {項目} | {状態} | {方法} | ### 環境設定 - {必要な環境設定項目} ## 3. シナリオテストケース ### 3.1 {機能エリア名} Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

テンプレート例：シナリオテスト作成（ SKILL利用） #### TC-{N}: {テストケースタイトル} - **対象PR**: #{number1}, #{number2} - **テスト観点**: ロジック / データ / 決済 - **前提条件**: - {前提条件1} - {前提条件2} **手順:** | # | 操作 | 期待結果 | |---|------|---------| | 1 | {具体的な操作} | {期待される結果} | | 2 | {具体的な操作} | {期待される結果} | **検証ポイント:** - [ ] {検証ポイント1} - [ ] {検証ポイント2} - [ ] {検証ポイント3} Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

テンプレート例：シナリオテスト作成（ SKILL利用） **データパターン:** | パターン | 入力値 | 期待結果 | |---------|--------|---------| | 正常系 | {値} | {結果} | | 境界値 | {値} | {結果} | | 異常系 | {値} | {結果} | ## 4. 決済リグレッションテストマトリクス | テストケース | 決済方法 | 金額パターン | 状態遷移 | 検証ポイント | |-------------|---------|------------|---------|------------| | TC-{N} | {方法} | {パターン} | {遷移} | {ポイント} | {決済関連の変更がない場合は「対象マイルストーンに決済関連の変更はありません」と記載} ## 5. テストデータ準備チェックリスト - [ ] {準備項目1} Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

実際のプロンプト例 7. 🥈PR作成を依頼 する ● PR作成中の間は他の作 業ができる ● PRの概要を考えて作るの ブランチ作成からPR作成まで ● 〜の形式で別ブランチを作って、プッシュとPR作成を実施してくださ い PRレビューのしやすさや理解を第一にこの不具合を詳しく知らない人 でもわかるようにPRの概要を作成してください。 CLAUDE.mdに書いておくと良いこと、毎回「PR作って」と指示するたびに考 慮してくれる ● PRテンプレートの場所 ● 使用するラベルの一覧 ● ブランチ命名規則 一気に修正したコードの整理 は時間がかかる ● 前のTipのテスト仕様書 作成のためにも実施する コミット分割 ● 一気に修正してしまったコードをフェーズごとに分割して PUSHしてく ださい ○ 規模が大きくなる場合に Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

• http://claude.md

まとめ Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

重要な心構え 効果的に活用するた めの3原則 1. 反復的確認: 修正→テスト →確認のサイクルを回す 2. 証跡重視: 調査結果やスク ショでエビデンスを 3. 最終確認は人間で : AIの AIはあくまで補助的なツール！ 最終確認・最終判断は必ず人間が行う 品質は確保することを意識する （No CheckはまだNG） ● ● ● コードレビューは人間の目で ビジネスロジックの正しさは人間が判断 セキュリティに関わる部分は特に慎重に 明確な完了条件を伝える ❌「修正してください」 ✅「修正後にテストの正常動作やRubocopでエラーがないか確認してくださ い」 作成結果は必ず人間が確 認 Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

🚨必ず、最終確認は人間で！ （良さそうに見えても見返すと微妙なところよくあります） Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.

ご清聴、ありがとうございました！ Copyright (C) 2025 Toranoana Lab Inc. All Rights Reserved.