タスクオーケストレーション

🔄 前回のおさらい: レッスン3でコンテキスト管理——最小限のコンテキスト原則、レイヤー戦略、タスク別コンテキスト戦略を学びました。ここではコンテキスト管理のスキルを活かして、複雑なタスクをオーケストレーションする方法を学びます。

一問一答を超えて

多くのClaude Codeユーザーは単発の質問しかしていません。ちょっとした質問には十分ですが、本格的な開発では、ワークフロー全体をオーケストレーションしたい。

つまり、複雑な作業を分解し、論理的な順序で並べ、正しくなるまで反復しながら、Claudeをマルチステップタスクを通じて指揮するということです。

オーケストレーションの考え方

自分をテックリードとして、有能な開発者を指揮していると考えましょう。

ダメなテックリード： 「機能を作って」 良いテックリード： 「分解しよう。まずアプローチの概要。次にデータ層。次にAPI。次にテスト。」

Claudeも同じです。曖昧で大きなリクエストは曖昧で大きなアウトプットを生みます。構造化された指示が質の高い結果を生みます。

タスクの分解

複雑なタスクは必ず分解できます：

元のタスク： 「アプリにユーザー認証を追加」

分解後：

1. 認証フローの設計（何がどこで起きるか）
2. ユーザーモデルとDBスキーマの作成
3. ログイン/ログアウトのエンドポイント実装
4. パスワードハッシュの追加
5. セッション管理の作成
6. 認証ミドルウェアの追加
7. テストの作成

各ピースが具体的。各ピースに明確な「完了」状態がある。

実践パターン

パターン：実装前に計画

いきなり実装に飛び込まない。

> APIレスポンスにキャッシュ層を追加する必要がある。
> まずアプローチの概要を出して。考慮すべき点：
> - 何をキャッシュすべきか
> - キャッシュ無効化戦略
> - Redis vs インメモリ
> まだコードは書かないで——計画だけ。

計画をレビュー。代替案を議論。次に：

> いい計画だ。オプション2のRedisで実装しよう。
> まずキャッシュユーティリティ関数から始めて。

パターン：インクリメンタル実装

レイヤーごとに構築し、各レイヤーを検証。

# ステップ1
> ショッピングカートのデータモデルを作成して。
> モデルだけ、APIはまだ不要。

# レビュー、次に...

# ステップ2
> カートサービスをadd、remove、clear操作で追加して。
> さっき作ったモデルを使って。

# レビュー、次に...

# ステップ3
> カートサービスを使うAPIエンドポイントを作成して。

# レビュー、次に...

# ステップ4
> カートサービスのテストを追加して。

各ステップが前のステップの上に構築される。問題を早期にキャッチできる。

✅ 確認クイズ: なぜ「完璧な一発」を目指すより「反復改善」のほうが効率的でしょうか？→一発で完璧は非現実的です。最初のアウトプットをベースに、具体的なフィードバックで改善するほうが、ゼロからやり直すより速い。何が正しくて何を変えるべきかをClaudeに伝えれば、良い部分を活かしつつ問題だけを修正できます。

パターン：反復改善

Claudeの最初のアウトプットが完璧であることは稀です。それで問題ない。

> CSVファイルをパースする関数を作成して。カラム：name, email, created_at

# アウトプットが近いが完璧ではない

> いいスタートだけど：
> - 空セルは空文字ではなくnullを返して
> - emailの形式バリデーションを追加して
> - 日付パースはISOとUSフォーマット両方に対応して

具体的なフィードバックは、タスク全体を再説明するより速い。

会話の継続性

Claudeはセッションを記憶します。これを活用しましょう。

良い例：

> さっき作った関数にエラーハンドリングを追加して。

Claudeはどの関数か分かっています。

不要な繰り返し：

> ファイルパスを受け取ってname、email、created_atフィールドの
> オブジェクト配列を返すparseCSV関数に
> エラーハンドリングを追加して。

既にコンテキストにあることを再説明しない。

タスクがうまくいかない時

Claudeが脱線した

> ストップ。それは頼んだことじゃない。
> XじゃなくてYが必要。
> 具体的には：[明確な再説明]

直接的に。明確にリダイレクト。

Claudeが行き詰まった

> 一歩引こう。このタスクの何が難しい？
> どんな情報があれば助かる？

Claudeが何が足りないか分かるようにガイドする。

アウトプットが部分的に正しい

> 前半は正しい。それはキープ。
> バリデーションロジックだけ変更して：[具体的な修正]

良い部分を捨てない。正確に何を変えるべきか指し示す。

タスク複雑度の判断

オーケストレーションの労力をタスクの複雑度に合わせる。

まとめ

• 複雑なタスクを明確で検証可能なステップに分解する
• 非自明なものは実装前に計画する
• やり直しではなく、具体的なフィードバックで反復改善する
• 会話の継続性を活用する——Claudeはコンテキストを記憶している
• オーケストレーションの労力をタスクの複雑度にマッチさせる

次のレッスン： ファイル操作——安全で効率的にファイルを扱う方法を学びます。