Mindset Strategy Fundamentals Subagents

オペレーターから Director へ：マインドセットの転換

すべてを変えるメンタルモデル。Claude Code を並列エージェント、専門ツール、自律機能を備えたエグゼクティブチームとして捉える方法。

2026年1月10日 • 12 分で読める • 著者：Claude World

Claude Code をマスターする上での最大の障壁は技術的なものではなく、精神的なものです。ほとんどの開発者は AI アシスタンスに対して間違ったマインドセットでアプローチし、Claude を手取り足取り指導が必要なジュニア開発者のように扱っています。

この記事は、すべてを変えるマインドセットの転換について、Claude Code の公式機能を使った具体的な例を交えて解説します。

Claude Code の 2 つの使い方

オペレーターのマインドセット

オペレーターはステップバイステップの指示を出します：

User: Read the file src/utils/date.ts
Claude: [shows file]
User: Find the formatDate function
Claude: [shows function]
User: Add a parameter for timezone
Claude: [makes change]
User: Now update the tests
Claude: [updates tests]

これは機能します。しかし、疲れます。あなたがすべての思考を行い、Claude はただタイピングしているだけです。

コスト分析：

  • シンプルなタスクに 4 回以上のやり取り
  • 並列実行なし—すべてが順次処理
  • すべてのステップを覚えておく認知負荷があなたにかかる
  • Claude Code のエージェント機能をまったく活用していない

Director のマインドセット

Director は成果を定義し、委任します：

User: "Our date formatting doesn't handle timezones correctly.
       Users in different timezones see wrong dates.
       Fix this throughout the codebase."

Claude: [autonomously using parallel agents]
  → Explore agent: Maps all date-related files
  → Explore agent: Finds timezone-related patterns
  → Implementation: Updates formatDate with timezone support
  → Implementation: Propagates changes to all usages
  → test-runner: Runs tests and verifies coverage
  → Verification: Confirms no regressions

成果に焦点を当てた1つの依頼で、手作業の調整を減らします。

重要な洞察

Claude Code はタイピングアシスタントではありません。専門エージェントを持つ思考パートナーです。

Claude Code は以下を提供します：

  • Agent ツールによるサブエージェントへの委任。タスクが独立していれば並列委任も可能
  • 組み込みおよびプロジェクト定義のサブエージェント。実際の利用可否は設定に依存
  • ライフサイクルイベントで設定済みチェックを実行する Hooks
  • 永続的なプロジェクトコンテキストと指針を提供する CLAUDE.md

すべてのキーストロークを管理すると、計画と調整の負担が自分に残ります。成果を明確にすれば Claude の agentic workflow をより活用でき、最終検証の責任は自分で保持できます。

5 つのメンタルシフト

シフト 1：「どのように」から「何を」へ

オペレーター的思考：「この変更を Claude にどう伝えればいいか？」

Director 的思考：「どんな成果が必要か？」

代わりにこう考える
「ファイル X を読んで、関数 Y を見つけて、Z を追加して」「機能 X が Y をサポートする必要がある」
「npm test を実行して失敗を見せて」「テストがパスすることを確認して」
「…という名前の新しいファイルを作成して」「…のためのユーティリティが必要」
「…のすべての使用箇所を検索して」「このパターンが使われているすべての場所を見つけて」
「デバッグのために console.log を追加して」「これが失敗する理由をデバッグして」

実際の例：

❌ Operator prompt:
"Read src/api/users.ts, find the createUser function, add try-catch
around the database call, log errors with prefix '[UserAPI]',
return 500 status on failure."

✅ Director prompt:
"Add proper error handling to the user creation endpoint
following our API error standards."

シフトのポイント：意図を指示に翻訳するのをやめましょう。意図を直接述べましょう。

シフト 2：コントロールから信頼へ

オペレーター的思考：「すべてのステップを確認する必要がある」

Director 的思考：「最終結果を確認すればいい」

これは開発者にとって難しいことです。私たちはすべての行を理解するよう訓練されています。しかし、考えてみてください：

  • チームメイトが書くすべての行をレビューしていますか？
  • それとも彼らを信頼して、プルリクエストをレビューしていますか？

Claude も同じ信頼に値します—最後に同じ検証を行えばいいのです。

信頼しつつエージェントで検証：

Delegate implementation of the user-profile editing feature to a subagent.
Ask it to follow existing patterns and return changed files plus verification.

After implementation, use a separate reviewer to inspect quality and patterns,
then run the related tests and report the actual results.

シフト 3：順次処理から並列処理へ

オペレーター的思考：「まずこれ、次にあれ、それからこれ」

Director 的思考：「何を同時に実行できるか？」

Director は財務が終わるのを待ってからマーケティングを始めたりしません。並列で実行し、マイルストーンで同期します。

並列化が有効なのは、ブランチが独立している場合だけです。依存する作業は順序を保つ必要があり、fan-out には常に調整コストが加わります：

Sequential (Operator):
  Analyze → Plan → Implement → Test → Review

Parallel (Director):
  ┌→ Analyze structure ─┐
  ├→ Find patterns      ├→ Implement → Test + Review
  └→ Check tests       ─┘

実際の実装：

Investigate the authentication system. Delegate independent read-only checks
in parallel: map the file structure, find JWT patterns, trace middleware,
inspect existing tests, and review recent auth changes. Synthesize the findings
before proposing an implementation.

シフト 4：繰り返しの指示から再利用可能な指針へ

オペレーター的思考：「今回 Claude に何をするか伝える」

Director 的思考：「持続するコンテキストは CLAUDE.md に置き、強制ポリシーは別の層で実装する」

CLAUDE.md は共有のプロジェクトプレイブックです。長く使う指針は一度書けますが、必ず強制したい境界には permissions、sandbox、hooks を使います：

# CLAUDE.md - Project Constitution

## Code Standards
- TypeScript strict mode, no `any` types
- All functions must have explicit return types
- Maximum 50 lines per function

## Testing Policy
- All features require tests before completion
- Minimum 80% coverage for new code
- Integration tests for API routes

## Security Guidance
- Changes in auth/, payment/, admin/ require security review
- No hardcoded secrets
- Validate all user inputs

## Working Defaults
Claude should normally:
- Read any project file
- Run tests and linting
- Create/modify files in src/ and tests/
- Create local git branches

## Boundaries to enforce in settings, sandbox, or hooks
- Pushing to remote
- Modifying environment files
- Deleting files

シフト 5：手動チェックから自動 Hooks へ

オペレーター的思考：「認証の変更後にセキュリティチェックを実行することを忘れないように」

Director 的思考：「これを自動的に行う Hooks を設定しよう」

Hooks のドキュメントより：

{
  "hooks": {
    "Stop": [{
      "matcher": "*",
      "hooks": [{
        "type": "prompt",
        "prompt": "If code in auth/, payment/, or admin/ was modified, verify security-auditor was run. If not, block and explain."
      }]
    }]
  }
}

利用可能な Hook イベント：

Eventタイミングユースケース
PreToolUseツール実行前危険なコマンドをブロック
PostToolUseツール実行後変更を監査
Stop完了前要件を検証
SessionStartセッション開始時コンテキストを読み込み

Director がすること（オペレーターがしないこと）

1. コンテキストを一度設定する

オペレーターは毎回のプロンプトでコンテキストを繰り返します。

Director は CLAUDE.md でコンテキストを確立します：

# Project Context
React 18 app with TypeScript.
Using Prisma for database, Zod for validation.
See @docs/architecture.md for structure.

これで、すべての会話が共通の理解から始まります。

2. ステップではなく制約を定義する

オペレーターはすべてのステップをリストします。

Director は境界を定義します：

"Add user search functionality.

Constraints:
- Use existing search patterns
- Must be performant (< 200ms)
- Include proper pagination
- Don't modify the user model

Freedom to:
- Choose UI implementation
- Design the API contract
- Structure the components"

3. スペシャリストに委任する

オペレーターはすべてを自分で行います。

Director はレビュー役を明示的に委任します。security-auditor のようなカスタム名は、利用前に設定しておく必要があります：

For this authentication change:
- Ask the configured security reviewer to check vulnerabilities.
- Use a separate reviewer for code quality and project patterns.
- Run the relevant tests and report coverage from the actual test output.

4. プロセスではなく成果をレビューする

オペレーターは中間ステップをすべてチェックします。

Director は最終結果を検証します：

"Before I merge:
- All tests pass?
- Security review complete?
- Documentation updated?
- Backward compatible?"

プロンプト比較：10 の実例

例 1：機能の追加

❌ Operator:
"Create a new file src/components/DarkModeToggle.tsx. Add a React
component with a button. Use useState for the theme state. Add
onClick handler. Import from theme context. Add CSS classes..."

✅ Director:
"Add dark mode toggle to the settings page. Use our existing
theme system and persist the preference."

例 2：バグの修正

❌ Operator:
"Read src/api/orders.ts. Find line 45. There's a null check missing.
Add if statement before accessing user.id."

✅ Director:
"Orders API crashes when user is undefined. Find and fix the root cause."

例 3：コードレビュー

❌ Operator:
"Show me file 1. Now file 2. Check for security issues in file 1.
Check for type errors in file 2. Look for missing tests..."

✅ Director:
"Review PR #123 comprehensively. Check security, quality, and coverage."

例 4：リファクタリング

❌ Operator:
"Open utils/helpers.ts. Find formatCurrency. Move to utils/currency.ts.
Update imports in file1.ts, file2.ts, file3.ts..."

✅ Director:
"Extract currency utilities into their own module. Update all usages."

例 5：デバッグ

❌ Operator:
"Add console.log at line 20. Run the app. Show me output.
Now add console.log at line 35..."

✅ Director:
"Dashboard loads slowly (8s, should be <2s). Find the bottleneck and fix it."

例 6：テスト

❌ Operator:
"Create test file. Import component. Write test for render.
Write test for click handler. Write test for state change..."

✅ Director:
"Add comprehensive tests for the checkout flow. Cover edge cases."

例 7：ドキュメント

❌ Operator:
"Open README. Add section for installation. Add section for usage.
Add section for API..."

✅ Director:
"Update documentation to reflect the new authentication flow."

例 8：セキュリティ監査

❌ Operator:
"Check file1 for SQL injection. Check file2 for XSS.
Check file3 for auth bypass..."

✅ Director:
"Audit the payment module for security vulnerabilities."

例 9：パフォーマンス

❌ Operator:
"Profile the dashboard. Show me slow queries.
Add index to users table. Cache the results..."

✅ Director:
"Optimize dashboard performance. Target <2s load time."

例 10：マイグレーション

❌ Operator:
"Read current API. List all endpoints. Create new versions.
Update route 1. Update route 2..."

✅ Director:
"Migrate from REST to GraphQL. Maintain backward compatibility."

信頼の方程式

効果的な委任には信頼が必要です。信頼は以下から構築されます：

能力： Claude はコードを深く理解しています。それを実証させましょう。

明確さ： 成果について明確であれば、Claude は提供します。

検証： 信頼しつつ、専門エージェントで検証します。

反復： フィードバックが将来のインタラクションを改善します。

公式：

Effective Delegation = Clear Outcome + Defined Constraints + Agent Verification

いつオペレートし、いつ Director になるか

すべてのタスクに Director Mode が必要なわけではありません。

オペレーターモードを使う場合：

  • 何かがどのように動作するかを学ぶとき
  • ステップバイステップのトレースでデバッグするとき
  • コントロールしたい実験
  • 1 行の変更

Director Mode を使う場合：

  • 機能の実装
  • コードレビュー
  • リファクタリング
  • 複数のステップを持つすべてのタスク
  • チームメイトに委任するようなすべてのこと

マインドセット別のモデル選択

マインドセットを固定モデル名に結び付けないでください。モデル、デフォルト、価格、提供状況は変わります：

タスクタイプデフォルト戦略上書きする条件
探索セッションモデルを継承低コストの選択肢でも必要な品質を保てると測定できたとき
実装セッションのデフォルトを使用benchmark で品質、速度、コストの有利な差が出たとき
セキュリティまたは設計十分な能力を選び、結果を検証リスクと評価結果が上書きを支持するとき

移行プラン

スイッチを切り替えるわけではありません。徐々に移行します。

1 週目：認識 マイクロマネジメントしているときに気づく。「代わりに成果を述べることができたか？」と問う。

2 週目：実験 1 日に 1 つのタスクを Director Mode で試す。体験を比較する。

3 週目：並列エージェント Agent 委任を使って独立した Explore 調査を行い、その結果を統合する。

4 週目：CLAUDE.md プロジェクト憲法を開発する。コンテキストを一度確立する。

2 ヶ月目：フル Director Mode Director Mode をデフォルトにする。意図的にオペレーターモードに落とす。 自動ポリシー適用のための Hooks を設定する。

成功の測定

効率メトリクス

メトリクスオペレーターモードDirector Mode
プロンプトの形多数の手順単位の引き継ぎ少数の成果単位の引き継ぎ
コンテキストスイッチング高低
完了までの時間順次実行の基準タスクの独立性と調整コストに依存
一貫性場当たり的なプロンプトに依存明確なコンテキストと検証で改善

品質指標

Director Mode が機能しているとき：

  • Claude が最初の試みであなたのスタイルに合ったコードを生成する
  • 同じ間違いを 2 度修正することがほとんどない
  • ブランチが本当に独立しているとき、並列エージェントが待ち時間を短縮する
  • 明示的に委任した場合、または設定済み Hooks で強制した場合にレビューが実行される

より大きな視点

このマインドセットの転換はキャリアの進化を反映しています：

  • ジュニア開発者：特定のタスクを実行する
  • シニア開発者：より広い問題を解決する
  • テックリード：成果を定義し調整する
  • エンジニアリングマネージャー：方向性を設定し委任する

Claude Code での Director Mode は単なる生産性ハックではありません。リーダーシップの練習です。効果的な委任のスキルを開発しているのです—成果を定義し、制約を設定し、他者が道を見つけることを信頼する。

今日から始める

次のタスクを選んでください。プロンプトする前に、自分に問いかけてください：

  1. どんな成果が必要か？
  2. どんな制約が重要か？
  3. Claude は何を決定できるか？
  4. どの専門エージェントが検証すべきか？

そして、ステップではなく成果をプロンプトしてください。

違いに気づいてください。そこから構築していってください。

出典：Claude Code subagents、Claude Code model configuration、Claude Code hooks、Claude Code memory