---
title: DXエンジニア向け_工程別チートシート_20261018
tags:  #claude  
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/PJXQWNVZ7X.jpg?width=480
description: DXエンジニア向け_工程別チートシート_20261018 by Yukiko
published: October 18, 26
canonical: https://image.docswell.com/s/yukiko_it/KX2VQG-2026-10-18-190127
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/PJXQWNVZ7X.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/3JK9VNQVJD.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/LE3WMVKQE5.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/8EDK683W7G.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/V7PKY84XJ8.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/2JVVGNX3JQ.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/5EGL8KVYJL.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4JQY9N667P.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/K74WXG4ME1.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/LJ1YND4YEG.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/GJWG4YX172.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4EZL2X6X73.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/Y76WV42P7V.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/G75MDQ2P74.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/9J298P4ZER.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/DEY465MNJM.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/VJNYZNWV78.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/YE9PZRXVJ3.jpg)

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