DXエンジニア向け_工程別チートシート_20261018

DXエンジニア向け｜Claude Code 工程別チートシート 8工程 ＋ Skill作成・タスク分解・テスト立案 ＋ 戻す・差分・新しく始める 1 現状分析 2 目的 3 ゴール 4 範囲 5 回収 6 実装 7 テスト 8 レビュー 使い方：VSCodeの統合ターミナル（Ctrl+`）で claude を起動。使用例のプロンプトは日本語のまま貼れます。確認日 2026/10/18

PHASE 1–2 ①現状分析 ／ ②目的 まず読むだけ。次に「何のためにやるか」を言葉にする 1 現状分析 プランモードで読み、事実・推測・不明に分ける claude --permission-mode plan 読むだけで起動 Shift+Tab plan mode on に切替 /context 記憶の使用量を確認 code-explorer など 調査を別室（サブエージェント）へ 2 使用例 サブエージェントを使って、請求バッチの 処理の流れと呼び出し元を調べて。 git履歴も見て経緯を要約し、確認できたこと／ 推測／不明の3つに分けて。 目的 なぜ引き継ぐのか・何を守るのかを確定 /plan 依頼 計画だけ立てさせる インタビュー方式 わからない点だけ質問させる SPEC.md 目的を1段落で残す うさうさ研修工房｜DXエンジニア向け 工程別チートシート 使用例 この改修の目的を整理したいので、私に インタビューして。コードから読めることは 先に調べ、業務上の理由だけ質問して。 結果は SPEC.md の「目的」に書き出して。 2

PHASE 3–4 ③ゴール ／ ④範囲 「どうなれば完了か」と「どこまでやるか」を先に決める 3 ゴール 完了条件を、合否が出る形で書く /goal 条件 条件を満たすまで継続 結果を表示 条件に必ず入れる /run /verify 実際に動かして確認 4 使用例 /goal `npm test` の結果が会話に表示され、 全テストが成功していること。 加えて、請求バッチの出力CSVが旧システムの 出力と一致することを表示して確認すること。 範囲 対象と「やらないこと」を名指しで書く @ファイル名 対象ファイルを指定 SPEC.md「やらないこと」 範囲外を明記 範囲を絞る investigate を無制限にしない うさうさ研修工房｜DXエンジニア向け 工程別チートシート 使用例 対象は @src/billing/ のみ。DBスキーマと 他モジュールは変更しないで。 範囲外を直したくなったら、変更せずに SPEC.md の「やらないこと」へ追記して。 3

PHASE 5–6 ⑤回収 ／ ⑥実装 分かったことを文書に残してから、小さく作る 5 回収 会話ではなく文書・スキル・フックに残す /init CLAUDE.md の土台 /memory 共通ルールを回収 /doctor CLAUDE.md を削る提案 /hooks 毎回必ず動かす処理 6 使用例 ここまでの調査で、毎回守るべきルール（テスト 実行方法・命名・禁止事項）だけを CLAUDE.md に追記して。コードから分かることは書かない。 終わったら /clear します。 実装 計画→小さく実装。隔離して並列に /plan 依頼 実装前に計画を作る claude -w 名前 専用worktreeで作業 /simplify 整理（バグ探しではない） /batch 指示 大量ファイルへ同じ変更 うさうさ研修工房｜DXエンジニア向け 工程別チートシート 使用例 SPEC.md を読んで、請求バッチのリファクタ 計画を /plan で作って。 承認したら worktree 内で小さな単位に分けて 実装し、各単位でテストを実行して。 4

PHASE 7–8 ⑦テスト ／ ⑧レビュー 失敗するテストが先。レビューは書いた人と別の目で 7 テスト 現行動作を固定し、通るまで回す /goal 条件 全テスト成功まで継続 /verify ビルド・起動して観察 test-writer（worktree） 現状のテストを書く係 証拠を見せて 出力とコマンドを提示 8 使用例 test-writer で、請求バッチの現行動作を固定する テストを書いて。本番コードは変更しない。 まず再現する失敗テストを書き、それから直して。 テスト出力と実行コマンドを見せて。 レビュー 目的別に使い分け、不足だけ拾う /code-review high --fix 正しさのバグ（--comment でPRへ） /security-review インジェクション・認可・露出 別セッション／ reviewer 書いた人と分ける うさうさ研修工房｜DXエンジニア向け 工程別チートシート 使用例 サブエージェントで、この差分を PLAN.md と 照らしてレビューして。要件の実装漏れ、 エッジケースのテスト、範囲外の変更だけ報告。 スタイルの好みは不要。 5

ADD-ON 1 Skill作成 毎回同じ手順を説明しているなら、スキルにする。置き場所は .claude/skills/名前/SKILL.md SKILL.md のひな形 どこに残す？（回収先の判断） --name: billing-test-planner • 常に守るルール → CLAUDE.md • たまに使う手順・ドメイン知識 → スキル description: 請求バッチのテスト観点を洗い出し、 テスト計画を作るときに使う。 • 毎回必ず実行したい処理 → フック（/hooks） --# 手順 1. SPEC.md の「目的」「範囲」を読む 2. 正常系・境界値・異常系を一覧にする 3. 現行動作を固定するテストから書く 4. テスト出力を証拠として提示する 作成を頼む例（そのまま貼れる） • 「今日の請求バッチ調査の手順を、スキルにして。.claude/skills/ に SKILL.md で作って」 • description は「いつ使うか」を具体的に # やらないこと - 本番コードは変更しない 関連コマンド・注意 うさうさ研修工房｜DXエンジニア向け 工程別チートシート • /run-skill-generator：/run と /verify に起動方法を教えるスキルを作る • サブエージェントの skills 項目で事前読み込みも可 • 詳細ドキュメントはリンクで足りる。短く書く 6

ADD-ON 2 タスク分解・進め方 「一気にやらせない」。計画→分解→単位ごとに実装→検証、を繰り返す 1 SPEC.md 目的・範囲・やらないこと 2 /plan 実装前に計画を作る 3 PLAN.md 小さな単位に分解して保存 4 単位ごとに実装 worktreeで隔離 5 6 /goal 単位ごとに合格条件 レビュー PLAN.mdと照合 使用例（分解を頼む） 分解・並列で使うコマンド SPEC.md を読んで、請求バッチのリファクタを 独立して実装・テストできる小さな単位に分解して。 /tasks 動いているタスクの確認 /subtask <task> 脇の作業→完了で会話に戻る /batch <指示> 独立した5〜30単位に自動分割 claude agents 複数セッションを一画面で Ctrl+B 実行中を背景へ回す 各単位に、①対象ファイル ②完了条件（実行できるテスト） ③依存する単位 を書いて、PLAN.md に保存して。 実装はまだ始めないで。 承認後：「単位1だけ実装して。終わったら テストの実行結果を見せて」 うさうさ研修工房｜DXエンジニア向け 工程別チートシート 7

ADD-ON 3 テスト立案 専用の「テスト立案コマンド」はありません。計画系コマンド＋依頼文＋test-writerで進めます ① 観点を出す（plan mode） ② 計画にする（/plan） ③ 書かせる（test-writer） SPEC.md と @src/billing/ を読んで、 テスト観点を一覧にして。正常系／境界値／ 異常系／業務ルール別に分け、根拠の ファイルと行を付けて。まだテストは 書かないで。 観点を、優先度つきのテスト計画にして。 現行動作の固定を最優先に。各テストの 合格条件（実行コマンドと期待結果）を書き、 PLAN.md の「テスト」に保存して。 test-writer で、PLAN.md の優先度1〜3を 書いて。モックは使わない。本番コードは 変更しない。まず失敗するテストを書き、 実行結果を見せて。 使うコマンド 立案のコツ /plan 依頼 計画だけ立てる @ファイル 対象を名指し /goal 条件 全テスト成功まで継続 /verify 動かして確認 うさうさ研修工房｜DXエンジニア向け 工程別チートシート • 弱い依頼「テストを書いて」→ 強い依頼「ログアウト時のエッジケース。モックな し」 • テストとコードは別のClaudeに書かせると偏りにくい • 観点の根拠（出典）を必ず付けさせる 8

EXAMPLES 1/9 現状分析：使用例集 すべて plan mode（読むだけ）で。範囲と出典を必ず指定する 使うコマンド ① 全体構成 ② 業務フロー code-explorer で、src/ の構成とエントリ ポイントを調べて。主要モジュール同士の 呼び出し関係を、ファイルパス付きで。 請求バッチが起動してから出力までの流れを、 処理順に整理して。分岐条件がある箇所は ファイルと行番号を付けて。 ③ 経緯を知る（出典指定） ④ 影響範囲 ExecutionFactory の git 履歴を見て、この APIがどうなってきたか要約して。関連する チケット番号が分かれば併記して。 calcTax() の戻り値を変えたら影響する 呼び出し元を全部洗い出して。テストが ある／ないも分けて。 ⑤ 事実・推測・不明に分ける ⑥ 脇の質問（/btw） ここまでの調査を、確認できたこと／ 推測にとどまること／わからないことの 3つに分けて書いて。 /btw この関数名の Impl は命名規則として 何を意味している？ ※ 会話の履歴に残りません claude --permission-mode plan 読むだけで起動 Shift+Tab plan mode on に切替 @"code-explorer (agent)" 依頼 調査係を確実に起動 /context 記憶の使用量を確認 /btw 質問 会話に残さず脇の質問 うさうさ研修工房｜DXエンジニア向け 工程別チートシート 9

EXAMPLES 2/9 実装：使用例集 計画 → 小さな単位 → 各単位でテスト。範囲外は触らない 使うコマンド /plan 依頼 実装前に計画だけ作る claude -w 名前 専用worktreeで作業 /simplify [対象] 整理（バグ探しではない） /batch <指示> 大量ファイルへ同じ変更 /subtask <task> 脇の作業を背景で実施 うさうさ研修工房｜DXエンジニア向け 工程別チートシート ① 計画から入る ② 小さく実装 SPEC.md を読んで、請求バッチのリファクタ 計画を /plan で作って。変更するファイルと 順序、各段階のテスト方法を書いて。 PLAN.md の単位1だけ実装して。終わったら テストを実行し、結果を見せて。他の単位は まだ触らないで。 ③ 既存を再利用 ④ 一括変換（/batch） 新しく書く前に、既存のユーティリティで 使えるものがないか調べて。あれば @ファイルを 指定して、それを使う形で実装して。 /batch migrate src/ from JavaScript to TypeScript ※ 5〜30単位に分割→承認後に並列実装 ⑤ 並行して脇の作業 ⑥ 範囲外を見つけたとき /subtask 現在の変更に対するパーサーの 単体テストを下書きして ※ 完了したらこの会話に戻る 範囲外の不具合を見つけても修正しないで。 SPEC.md の「やらないこと」に、場所と内容を 追記だけして。 10

EXAMPLES 3/9 エラー対応：使用例集 「直して」の前に「再現」。2回直らなければ /clear して最初から 使うコマンド /btw 質問 原因の脇の質問 ① 再現テストが先 ② 原因を事実と推測に分ける セッションタイムアウト後にログインが失敗する。 src/auth/ のトークン更新を見て。まず再現する 失敗テストを書き、それから直して。 このエラーの原因候補を挙げて。コードで 確認できたものと推測を分け、推測には、 確かめる方法も書いて。 ③ 直るまで回す ④ 不安定なテスト（--bg） /goal `npm test` の結果が会話に表示され、 全テストが成功していること claude --bg "flaky なテストを調べて" → claude agents で状況を確認 → claude logs <id> で最近の出力 ⑤ 2回直らなかったら ⑥ 動かして確かめる /clear して、ここまでで分かった原因と 試したことを書き込んだ新しいプロンプトで 最初からやり直す。 直したあと /verify を実行して、実際に 起動して該当画面の動作を確認して。 「成功した」だけでなく操作結果を見せて。 /goal 条件 直るまで継続 /verify 実際に動かして確認 Esc Esc ／ /rewind 一つ前に戻す /clear 学びを入れて最初から claude --bg "依頼" 背景で調査を開始 うさうさ研修工房｜DXエンジニア向け 工程別チートシート 11

EXAMPLES 4/9 差分確認：使用例集 AIの変更は、自分の目で差分を確認してから受け入れる 使うコマンド ① 範囲外の変更がないか ② 変更の意図を説明させる 今回の変更で、PLAN.md の対象外のファイルを 触っていないか確認して。あれば一覧にして、 理由も説明して。 この差分を、ファイルごとに「何を・なぜ変えたか」 3行以内で説明して。理由が説明できない 変更は、元に戻す候補として挙げて。 ③ 要件と照合 ④ 旧挙動との差 サブエージェントで、この差分を PLAN.md と 照らしてレビューして。実装漏れとテスト不足の ある箇所だけ報告して。 リファクタ前後で出力が変わっていないか、 現行テストの結果と合わせて確認して。 変わった箇所は理由つきで報告して。 ⑤ コミット前チェック ⑥ PRにコメント git diff --staged の内容を見て、デバッグ用の 出力や不要なコメントが残っていないか確認 して。 /code-review 1234 --comment /code-review high --fix ※ --fix は修正を適用。差分を再確認する /diff Claudeの変更内容を確認 /code-review [--comment] 差分のバグ確認／PRへコメント git diff / git diff --staged 未ステージ／ステージ済み（git） git log -p ファイル 履歴と差分（git） VSCode Ctrl+Shift+G ソース管理で差分を見る うさうさ研修工房｜DXエンジニア向け 工程別チートシート 12

EXAMPLES 5/9 現在の実装から「仕様書」を作る コードが唯一の真実なとき。読み取れたことと業務ルールの質問を分ける 使うコマンド ① 機能単位で逆起こし ② 事実と推測を分ける code-explorer で @src/billing/ を調べて、 機能ごとに「入力・処理・出力」を整理し、 SPEC.md の下書きにして。行番号を付けて。 SPEC.md の各項目に、コードで確認できた(事実)／ 推測／不明 のラベルを付けて。推測と不明は 末尾の「未確認事項」に集めて。 ③ 不明点をインタビュー ④ やらないことを明記 未確認事項について、私にインタビューして。 1回1問、選択肢つきで。聞き終えたら SPEC.md を更新して。 SPEC.md に「やらないこと」の節を作り、 今回の対象外の機能・画面・バッチを 理由つきで書いて。 ⑤ 検証手順を末尾に ⑥ 仕様書で新セッション開始 SPEC.md の最後に、エンドツーエンドの検証手順 （実行コマンドと期待結果）を書いて。 実際に動かして確認してから確定して。 /clear して SPEC.md を読んで。その仕様に 沿って、請求バッチの現行動作を固定する テスト計画を /plan で作って。 claude --permission-mode plan 読むだけで起動 @"code-explorer (agent)" 依頼 調査係で事実を集める インタビュー方式 不明な業務ルールだけ質問 SPEC.md 書き出し先 /clear 書き出し後に新セッションへ うさうさ研修工房｜DXエンジニア向け 工程別チートシート 13

EXAMPLES 6/9 現在の実装から「要件書」を作る 「コードがそうなっている」と「そうあるべき」は別。確認を挟んで要件にする 使うコマンド ① 現行動作を要件候補に ② 機能／非機能に分類 code-explorer で現行コードの振る舞いを調べ、 要件候補を「〜できること」の形で列挙して。 根拠のファイルと行を付けて。 要件候補を、機能要件／非機能要件（性能・ セキュリティ・運用）／業務ルール に分類して。 分類が不明なものは別枠にして。 ③ バグ疑いを分離 ④ 受入条件を付ける 現行コードの挙動で、仕様として意図したのか バグか判断できないものを一覧にして。 私に質問して、要件に含めるか決める。 各要件に、実行できる受入条件を付けて。 例：入力Aのとき出力Bになる。テストで 確認できる形に。 ⑤ 優先度と範囲 ⑥ 食い違いの確認 要件を、必須／あると良い／対象外に分けて。 対象外は理由を書き、SPEC.md の 「やらないこと」と整合させて。 REQUIREMENTS.md と SPEC.md を照らして、 食い違い・抜けを報告して。スタイルの好みは 不要。不足だけ。 plan mode 読むだけで調査 code-explorer 根拠つきで事実収集 インタビュー方式 要件の意図を確認 REQUIREMENTS.md 書き出し先（名前は自由） /btw 質問 脇の確認は履歴に残さない うさうさ研修工房｜DXエンジニア向け 工程別チートシート 14

EXAMPLES 7/9 禁止・制約を操るコマンド 「お願い」ではなく「仕組み」で縛る。弱い順：依頼文 → CLAUDE.md → 権限・ツール → フック 使うコマンド --permission-mode plan ファイルを変更させない ① 読み取り専用の調査係 ② 本番コード変更を禁止 name: code-explorer／tools: Read, Glob, Grep 本文に「Never modify files」。 → 書き込み系ツールを渡さない test-writer の本文に「Do not change production code」と書き、isolation: worktree で隔離。 変更が出たら /diff で確認する ③ 放置実行を安全に ④ 禁止事項を常時ルール化 claude -p "…" --allowedTools "Edit,Bash(git commit *)" --permission-mode dontAsk → 許可外の操作は自動で拒否 /memory で CLAUDE.md に追記：「DBスキーマは 変更しない。.env は読まない」。短く、 消したらAIが間違うものだけ ⑤ テスト未通過を許さない ⑥ 禁止の例外を許可する Stopフック：テストが通るまでターン終了を ブロック。/hooks で設定。 「お願い」ではなく決定論で止める 範囲を一時的に広げるときは SPEC.md の 「やらないこと」を更新してから依頼する。 口頭の例外は次のセッションで消える --permission-mode dontAsk 承認が要る操作を拒否（放置実行） --allowedTools "Edit,Bash(git commit *)" 必要なツールだけ事前承認 tools / disallowedTools サブエージェントの許可・拒否 /hooks Stopフック等の決定論的な門番 /memory CLAUDE.md に禁止事項を追記 うさうさ研修工房｜DXエンジニア向け 工程別チートシート 15

EXAMPLES 8/9 サブエージェントの使用例集 定義は .claude/agents/*.md（name と description が必須）。description は「いつ任せるか」 使うコマンド @"名前 (agent)" 依頼 確実に起動（@メンション） ① 定義：調べる人 ② 3人チームで進める name: code-explorer／tools: Read, Glob, Grep model: sonnet／本文：「事実・推測・ 未解決の質問」の3点で報告する code-explorer で現状→test-writer で現行テスト→ reviewer で確認、の順で請求バッチの改修を 進めて。各段階の結果を要約して。 ③ 指名して起動 ④ 並列の上限に注意 @"code-explorer (agent)" 認証の変更点を見て ※ 自然な言葉より確実に起動できる 同時に動くサブエージェントは既定で最大20。 入れ子は3階層まで。1で入れ子を無効化 （環境変数で変更可） ⑤ レビュー役の頼み方 ⑥ 置き場所と優先度 Use a subagent to review the diff against PLAN.md…Report gaps, not style preferences. → 不足だけ報告させる 管理設定＞--agents＞.claude/agents/＞ ~/.claude/agents/＞プラグイン。 名前が衝突したら優先度の高い方が勝つ claude --agent 名前 セッション全体を1役に Ctrl+B 実行中を背景へ background: true 常に背景で動かす isolation: worktree 隔離して実行 model / maxTurns / effort モデル・ターン上限・思考量 うさうさ研修工房｜DXエンジニア向け 工程別チートシート 16

EXAMPLES 9/9 Skill編集：使用例集 専用の「編集コマンド」は記事にありません。SKILL.md を依頼文またはVSCodeで直接編集します 使うコマンド VSCodeで SKILL.md を開く 直接編集（Ctrl+P でファイル名検索） ① 手順をスキルに格上げ ② description を直す 今日の調査手順を、.claude/skills/investigatebilling/SKILL.md にして。description は 「請求バッチ調査の依頼を受けたとき」。 SKILL.md の description を、いつ使うか 具体的になるよう書き直して。「◯◯と言われたとき」 「△△のファイルを触るとき」の形で。 ③ 長いスキルを削る ④ 「やらないこと」を追加 SKILL.md を見直して、コードを読めば分かる 説明とAPIの詳細は削除し、詳細は リンクにして。短くして。 SKILL.md の末尾に「やらないこと」を追加して： 本番コードは変更しない／範囲外は 報告のみ。 ⑤ 効いているか試す ⑥ スキルかフックか迷ったら /clear して、スキルの対象になる依頼を 出して。スキルの手順どおりに動くか確認し、 外れた箇所を SKILL.md に反映して。 毎回必ず実行したい → フック。 たまに使う手順・知識 → スキル。 常に守るルール → CLAUDE.md。 /run-skill-generator 起動・ビルド方法のスキルを作る skills（サブエージェント） 事前読み込みするスキルを指定 /hooks スキルより確実に動かしたい処理 /diff 編集内容の差分確認 /clear 編集後に新セッションで試す うさうさ研修工房｜DXエンジニア向け 工程別チートシート 17

RECOVERY 戻し方・差分確認・新しく始める 失敗しても戻れるように、作業の前にコミットしておく 戻し方 差分確認 新しく始める Esc Esc ／ /rewind 一つ前の時点に戻す /diff Claudeの変更内容を確認 /clear 無関係な作業の間に /clear 会話を空にする（文書は 残る） git diff 未ステージの差分（git） /branch 名前 会話を分岐して別方針を 試す git restore ファイル 変更を元に戻す（git） git diff --staged ステージ済みの差分（git） /fork プロンプト 会話をコピーして別セッ ションへ git stash 作業を一時退避（git） git log -p ファイル ファイルの履歴と差分 （git） claude -w 名前 新しいworktreeで始める git switch - 直前のブランチへ（git） VSCode ソース管理 Ctrl+Shift+G でファイルを 選ぶ claude --bg "依頼" 背景で新しく開始 目安：同じ指摘を2回しても直らないなら /clear して、学んだことを入れたプロンプトで最初から。戻し方の (git) は一般的なgitコマンドで、Claude Code固有ではありません。/rewind が 戻す範囲は公式の commands ページで確認してください。 うさうさ研修工房｜DXエンジニア向け 工程別チートシート 18