TL;DR
- Claude は「長い指示」を書くより、タスクの境界を狭く切ると強い
- 出力の検証観点を先に伝えると、修正コストが大幅に下がる
- 反復作業はテンプレート化し、毎回の迷いを減らす
- 「プロンプトの質」より「仕事の渡し方」が成果を左右する
仕事の切り方――Claudeに何をやらせないかを決める
Claude に仕事を任せるとき、最初にやるべきことは「何を頼むか」ではない。**「何をやらせないか」**を決めることだ。
仕様の判断、事実確認、最終承認。この3つのどこを人間が持つのかを最初に明示するだけで、出力のブレは大幅に減る。曖昧な境界のまま「よしなにやって」と投げると、Claude は善意で判断範囲を広げ、結果として修正コストが膨らむ。
これはプロンプトからエージェントへの転換で述べた「指示（Prompt）から仕組み（Agent Engineering）への移行」と同じ発想だ。単発の指示を磨くより、仕事の渡し方を構造化するほうが効果は持続する。
指示の粒度を揃える
1回の依頼で欲しいものは1つに絞る。要約と実装とレビューを同時に頼むより、順番を分けたほうが結果は安定する。
悪い例と良い例を比較するとわかりやすい。
| やり方 | 指示の例 | 起きること |
|---|---|---|
| 悪い例 | 「この PR をレビューして、修正して、テストも書いて」 | 3つの責務が混ざり、どれも中途半端になる |
| 良い例 | 「この PR の問題点を3つ以内で指摘して」→ 確認後に「指摘1を修正して」 | 各ステップで品質を確認できる |
Claude Code の subagents を使う場合も、この原則は同じだ。subagents の粒度設計で詳述しているが、read-heavy なタスク（レビュー・探索）は分割しやすく、write-heavy なタスク（実装）は分割リスクが高い。まずは「調べる」と「書く」を分けるだけでも精度が上がる。
具体的な切り出しパターン
実務で使いやすいタスクの切り方を3つ挙げる。
- 探索 → 判断 → 実装: まず「影響範囲を調べて」と依頼し、結果を人間が確認してから実装に入る
- 下書き → レビュー → 修正: 一発で完成を求めず、段階的に精緻化する
- 定型 → 例外: テンプレートで処理できる部分を先に片付け、例外だけ人間が判断する
確認の仕方――出力を見る前に検証観点を決める
Claude の出力は、そのまま採用するより**「確認ポイント」を先に決めて見る**のが安全だ。
たとえばコードレビューなら、次の3点だけ確認すれば実務上は十分に機能する。
- 動作: 意図した動きをするか
- 例外: エッジケースや異常系の考慮があるか
- 整合性: 既存の仕様やコードベースと矛盾しないか
この「検証観点の事前定義」は、CLAUDE.md の最適化で紹介されている「rules（何をしてよくて、何をしてはいけないのか）」の考え方とそのまま接続する。検証観点をリポジトリに残しておけば、次のセッションでも同じ品質基準で確認できる。
出力が期待と違ったときの対処
Claude の出力がズレた場合、プロンプトを長くして修正しようとするのは悪手だ。代わりに、次の順序で対処する。
- 前提を確認する: Claude が参照した情報に誤解がないかチェック
- スコープを狭める: 1回の依頼で求めすぎていないか見直す
- 検証観点を明示する: 「〇〇の観点でチェックして」と具体的に伝える
# 悪い例：長文で修正を求める
「さっきの出力は〇〇の点が足りなくて、△△も考慮されていないので、
□□を踏まえて、もう一度全体を見直してください」
# 良い例：観点を1つに絞る
「このコードを、例外処理の網羅性だけに絞ってレビューしてください」
使い回しのコツ――テンプレートで迷いを減らす
反復するタスクは、毎回ゼロから指示を書かずに短いテンプレートに寄せる。レビュー観点、出力形式、NG事項が固定されると、Claude の返答も安定する。
これは「プロンプトの再利用」ではない。ワークフローの標準化だ。
Claude Code でブログを量産するパイプラインでも解説している通り、高品質な成果物を安定して出すには「ガバナンス層（ルール）→ 実行層（テンプレート）→ 改善層（レビュー）」の三層構造が効く。個人の開発タスクでも、この考え方はそのまま使える。
テンプレートの実例
たとえば、コミットメッセージのレビューを毎回頼むなら、こう固定する。
## タスク: コミットメッセージのレビュー
### 入力
- 対象: staged changes の diff
### 検証観点
1. 変更内容を正確に要約しているか
2. conventional commits の形式に沿っているか
3. breaking change がある場合に明記されているか
### 出力形式
- OK / NG + 理由（1行）
- NG の場合は修正案を1つ提示
このテンプレートを Claude Code の skills として保存しておけば、必要なときに呼び出すだけで毎回同じ品質のレビューが走る。コンテキストの分業設計で解説している「skills = 再利用手順の置き場」という考え方そのものだ。
テンプレート化すべきタスクの見極め
すべてをテンプレート化する必要はない。基準は単純だ。
- 週に3回以上同じ種類の依頼をしているか
- 出力の品質にばらつきが出ているか
- 他の人にも使わせたい手順か
1つでも当てはまれば、テンプレート化の投資対効果は高い。
まとめ――仕事の切り方が成果を決める
Claude は万能な自動化装置ではない。うまく切り出した仕事を速く終わらせる相棒だ。
押さえるべきポイントは3つだけ。
- タスクの境界を狭く切る: 1回1依頼。探索と実装は分ける
- 検証観点を先に決める: 出力を見てから考えるのではなく、見る前に基準を用意する
- 反復作業はテンプレートに落とす: 毎回のプロンプト改善より、仕組みの標準化に投資する
プロンプトのテクニックを磨くのも大事だが、それ以上に効くのは仕事の渡し方を構造化することだ。まずは今日、自分が Claude に頼んでいるタスクを1つ選び、「探索 → 判断 → 実装」に分解してみてほしい。それだけで、実務での使い勝手はかなり変わる。
2026-05 時点の実務 Tips（Skill / Subagent / Hook 前提）
2026 年中頃の Claude Code は Hooks / Subagents / Skills の 3 拡張レイヤー が標準提供され[公式値]（Claude Code 公式 docs）、本記事の「タスク境界の切り方」「検証観点の固定」「テンプレート化」をそれぞれ別レイヤーで担う設計が現実解になりました。詳細な役割分担は CLAUDE.md 最適化と Skill との分担 を参照。
タスク境界 = Subagent で隔離する
「探索」「判断」「実装」を別タスクとして切り出すなら、Subagent でコンテキストを隔離するのが現実解[公式値]（Subagents 公式）。Subagent の verbose 出力（探索ログ・複数手順）は親会話に持ち込まれず、サマリだけ返ってくるため、コンテキストウィンドウを節約できます。Skill との使い分けは Skills対Subagents使い分け5軸 を参照。
検証観点 = Hook で deterministic に強制する
「出力を見る前に検証観点を決める」を プロンプトの祈りに頼らず仕組みで強制したいなら Hook です[公式値]（Hooks 公式）。PreToolUse hook で「特定 tool の前に test を走らせる」「特定パスへの書き込みをブロックする」が deterministic に実現できます。実装パターン集は Claude Code hooks の実践パターン集、承認境界の強制例は PlanGate v8.6 Hook Enforcement。
テンプレート化 = Skill で再利用する
「毎回同じ指示を書く」を Skill 化すれば、/skill-name で呼び出すだけで完走できます[公式値]。Skill の本体は SKILL.md で、必要時だけロードされるため CLAUDE.md を肥大化させません。プロンプトを資産化する全体像は プロンプトからエージェントへの転換 を参照。
2026 ツール選定との接続
実務 Tips をどのツールで実装するかは、Claude Code / OpenAI Codex CLI / GitHub Copilot coding agent のいずれを主軸にするかで変わります。比較フレームは 2026 年の AI コーディング自動運転最前線 を参照してください。
FAQ
Q1. Claude Code の Skill / Subagent / Hook はいつ使い分ければよいですか？
3 つは役割が直交します[公式値]: Skill = 再利用したい手順、Subagent = コンテキストを隔離して並列タスク、Hook = 必ず実行される deterministic 制約。最初は Skill から導入、次に Hook、最後に Subagent の順が現実解（経験則）。詳細は CLAUDE.md 最適化と役割分担表。
Q2. プロンプト改善と仕組み化、どちらに時間を投資すべきですか？
仕組み化（経験則）。同じタスクが 3 回以上来るなら その時点で Skill / Hook / Subagent のいずれかに落とす 投資判断が現実的です。詳細は プロンプトからエージェントへの転換。
Q3. タスク境界を狭く切る具体的な例は？
「リポジトリ全体を探索 → 実装案 → コード → テスト → ドキュメント」を 1 ターンで全部やらせるのではなく、探索を Subagent に分離 → 実装案を別ターンで判断 → コード生成と検証を別 Skill で、のように切り分けます（経験則）。
Q4. 実装した Skill / Hook の効果はどう測りますか？
(1) 同タスクの所要時間の中央値、(2) 出力品質のレビュー時間、(3) 手戻り率、の 3 指標で判定（経験則）。組織全体の生産性指標との接続は DORAとSPACEの選び方 を参照。
Q5. Codex CLI との使い分けは？
Claude Code は Hooks / Subagents / Skills の 3 層モデルが標準[公式値]、Codex CLI は MultiAgentV2 で sub-agent 並列実行に強い[公式値]。役割分担と機能対比表は 2026 年の AI コーディング自動運転最前線 を参照。
References
- Claude Code 公式 docs
- Claude Code Subagents 公式
- Claude Code Hooks 公式
- Claude Code Skills 公式
- Claude Code Memory 公式
