Command → Agent → Skill アーキテクチャ

Command → Agent → Skill 3層アーキテクチャ

User input / command trigger
       │
       ▼
┌──────────────┐    Command (entry point) 
│  /command    │    .claude/commands/*.md
└──────┬───────┘
       │ Agent tool
       ▼
┌──────────────┐    Agent (executor) 
│  Agent       │    .claude/agents/*.md
└──────┬───────┘
       │ Preload/invoke Skill
       ▼
┌──────────────┐    Skill (knowledge) 
│  Skill       │    .claude/skills/*/SKILL.md
└──────────────┘

• Command — ユーザーのエントリポイント。Agentの呼び出し順序を調整。 82内蔵 カスタム

• Agent — 独立したコンテキスト実行者。並列実行が可能。 5内蔵 カスタム

• Skill — 再利用可能な指示パック。ロードまたは呼び出しが可能。 10内蔵 カスタム

比較

選択のガイド: 複数の Agent を連携させる多段階のフローを制御したい → Command。独立したコンテキスト、並列実行、ツールの分離が必要 → Agent。様々なシナリオで読み込まれる再利用可能な指示パックが必要 → Skill。

関係性とユースケース

なぜハーネスが重要なのか

出力品質の公式: quality = f(effective_context, model_capability, iteration_loops) ハーネスは「有効コンテキスト」と「反復ループ」に直接影響します。

ハーネス: 10 のコア機能

「Skills、Commands、Subagents はすべて最終的にプロンプトになるのだから、強力なプロンプトだけで十分では？」— 技術的には正しいですが、実践的には誤りです。ハーネスがプロンプトでは到達できないレイヤーで何をするのかを以下に示します。

User input: "Write a recursive flatten function"     ← (a) ~6 tokens

What the model actually sees:                       ← (b) ~15,000 tokens
  ├── CLAUDE.md (Project specs)
  ├── Matched .claude/rules/*.md (paths trigger)
  ├── Modular system prompt fragments (110+)
  ├── Tool definitions
  ├── Environment context (cwd, git status, platform)
  ├── Previous conversation turns
  ├── Files read via Read/Grep
  └── User's 6-token request

サブエージェント

5つの組み込みタイプ

カスタムエージェントのフロントマター（16フィールド）

コマンドシステム（82個の内蔵コマンド）

Claude Codeには82個のスラッシュコマンドが組み込まれており、11のカテゴリに分類されています。カスタムコマンドは.claude/commands/*.mdに配置します。

カスタムコマンド：.claude/commands/*.mdに配置。16のフロントマターフィールド（name、description、argument-hint、arguments、contextなど）に対応。“!`command```で動的コンテキスト注入が可能。

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

Weather Reporter 完全なオーケストレーションフローアニメーション

User: /weather-orchestrator
       │
       ▼
┌──────────────────────────┐
│  weather-orchestrator    │  ← Command (entry point) 
│  1. Ask temperature unit C/F   │
│  2. Call weather-agent   │
│  3. Call svg-creator     │
└──────┬───────────────────┘
       ▼
┌──────────────────────────┐
│  weather-agent           │  ← Agent
│  preload: weather-fetcher │  ← Skill (preloaded) 
└──────┬───────────────────┘
       ▼
┌──────────────────────────┐
│  weather-svg-creator     │  ← Skill (invoked) 
│  output: weather.svg         │
└──────────────────────────┘

タスクシステム

Claude Code の組み込みタスク追跡システムは、作成、クエリ、更新、依存関係管理をサポートしています。サブエージェントおよびスキルと連携します。

4 つのコアツール

タスクライフサイクル

pending → in_progress → completed
                 ↘ deleted

依存関係

• addBlocks — 「指定されたタスクは、このタスクが完了するまで開始できない」とマークします
• addBlockedBy — 「このタスクは、指定されたタスクが完了するまで待機してから開始する必要がある」とマークします
• **DAG（有向非巡回グラフ）**を形成し、実行順序を保証します

環境変数: CLAUDE_CODE_TASK_LIST_ID が現在のタスクリストを識別し、ファイルは ~/.claude/tasks/ に永続化されます。

スキルシステム

重要なポイント: スキルは（単なる Markdown ファイルではなく）フォルダです。スクリプト、データ、リソース、設定テンプレートなど、エージェントが検出、読み取り、操作できるものすべてを含めることができます。SKILL.md はエントリポイントですが、全体像ではありません。実際の例についてはオーケストレーションを参照してください。

スキルは .claude/skills/<name>/SKILL.md に配置され、自動検出とトリガーが行われます。セッション開始時、Claude はすべての利用可能なスキルの description フィールドをスキャンし、現在のタスクと一致させます。

• 段階的情報読み込み — SKILL.md を通じてフォルダ内のファイルを Claude に伝えます。詳細は必要な場合にのみ読み取られます。すべての情報を一度に読み込んでコンテキストを浪費するのを防ぎます。

• Description はモデル向け — description フィールドは単なる要約ではなく、トリガー条件の説明です。「このスキルをいつ使用すべきか」を明確に記述すると、Claude はそれに応じて自動マッチングを行います。

9 つの設定パターン

2 つの読み込みモード

• Preload モード（エージェントスキル） — エージェントの skills: フィールド経由で読み込まれます。エージェント起動時に自動注入されます。

• Invoke モード（呼び出しスキル） — Skill ツールまたは /skill-name 経由でトリガーされます。Claude が自動マッチして呼び出すことも可能です。

9つの使用カテゴリ

Anthropic内部の数百のスキルから抽出（Thariq, 2026.03）。優れたスキルは1つのカテゴリに属します。複数のカテゴリにまたがるスキルは、通常分割する必要があります。

16のFrontmatterフィールド

10の組み込みスキル

フックシステム

ライフサイクルイベント駆動の自動化スクリプト。.claude/settings.json または エージェントのフロントマターで設定します。

4つのフックタイプ

エージェントフロントマターの制限: エージェントで使用可能なフックイベントは6つのみです: PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest, Stop, SubagentStop。残りの21のイベントはメインセッションでのみ利用可能です。

27のライフサイクルイベント

機能別にグループ化。すべてのイベントはasyncとtimeoutオプションをサポートしています。

設定例

フックは設定で構成するか、必要に応じてスキルのフロントマターで有効化します。

{
  "hooks": {
    "Stop": [{
      "type": "command",
      "command": "python3 .claude/hooks/scripts/hooks.py --event Stop"
    }],
    "PostToolUse": [{
      "type": "command",
      "command": "python3 .claude/hooks/scripts/hooks.py --event PostToolUse"
    }]
  }
}

高度なツール使用

Prompt-to-Code (PTC) — パラダイムシフト

システムプロンプトに指示を詰め込む代わりに、PTCはそれらをサンドボックスで実行される実行可能なコードルールにコンパイルします。結果：より短いプロンプト、より正確な推論、約37%のトークン節約。

{
  "type": "code_execution_20250825",
  "name": "data_processor",
  "allowed_callers": ["code_execution_20250825"],
  "input_schema": {
    "type": "object",
    "properties": {
      "task": { "type": "string" }
    }
  }
}

PTC高度なパターン

• バッチ処理 — 単一のPTC呼び出しで複数のレコードをループ処理し、ツールの呼び出し回数を削減。バッチ翻訳や分類などに最適。

• 早期終了 — コードに条件チェックを追加し、しきい値に達した時点で即座にreturn。不要な計算を回避します。

• 条件分岐 — 入力タイプに基づいて異なる処理ブランチを動的に選択。それぞれに個別のツールを定義する必要がありません。

PTCの制約

動的ツールフィルタリング

Web Search / Web Fetchの結果は、そのまま挿入されるのではなく、コードによって事前処理されてからコンテキストに入ります。ベータヘッダー anthropic-beta: code-execution-web-tools-2026-02-09 が必要です。

ツール検索

使用頻度の低いツールに defer_loading: true を設定すると、モデルが必要に応じて検索・読み込みを行い、ツール定義を約85%削減できます。

// Tool definitionsExample
{
  "name": "specialized_analyzer",
  "defer_loading": true,
  "description": "..."
}

// Claude Code environment variable
ENABLE_TOOL_SEARCH=auto:5  // Keep 5 common tools, defer the rest

ツール使用例

ツール定義に input_examples 配列（1〜5項目）を追加し、実際のデータサンプルを含めます。モデルの呼び出し精度が72%から90%に向上します。

{
  "name": "query_database",
  "input_examples": [
    { "sql": "SELECT * FROM users WHERE active = true LIMIT 10" },
    { "sql": "SELECT COUNT(*) FROM orders WHERE date > '2026-01-01'" }
  ]
}

Claude Codeでの利用可能性

**CLIユーザーへの優先事項：**CLAUDE.mdでTool Use ExamplesとTool Searchをまず設定してください（ENABLE_TOOL_SEARCH=auto:5）。これらはCLIユーザーに最も大きなメリットをもたらします。PTCとDynamic Filteringは主にSDK/APIでの高度な統合シナリオ向けです。

設定の5層優先度

管理設定の配信方法

コア設定

拒否ルールは常に最高優先度を持ちます — いずれかのレベルでの拒否は、すべての許可ルールをオーバーライドします。配列設定はレベル間で置き換えられるのではなく、マージされて重複排除されます。

管理層の内部優先度

管理層内では、ソースは次の順序で使用されます（1つのソースのみ、層をまたぐマージはなし）：

v2.1.126の変更: /configは変更をメモリ内に保持するのではなく、~/.claude/settings.jsonに永続化するようになりました。インタラクティブな設定UIからの変更は再起動後も維持されます。

権限モード

設定のpermissionsキーで設定します。

ツール権限の構文

パスプレフィックス

マッチングルール

• 複合コマンド: &&, ||, ;, |で分割され、各サブコマンドは独立してマッチします。Bash(safe-cmd *)はsafe-cmd && other-cmdをカバーしません
• ワイルドカードの位置: *はプレフィックス、サフィックス、インフィックスとして使用可能。Bash(* install)はnpm installにマッチ、Bash(git * main)はgit push mainにマッチ
• 単語境界: Bash(ls *)（スペースあり）はlsofにマッチしません。Bash(ls*)（スペースなし）は両方にマッチします
• シンボリックリンク: 許可にはシンボリックリンクとターゲットの両方が許可ディレクトリ内にある必要があります。拒否はどちらかでトリガーされます
• プロセスラッパー: timeout, time, nice, nohupはマッチング前に除外されます。watch, find -execは常にプロンプトを表示します

グローバル設定とプロジェクト設定

• グローバル ~/.claude/ — settings.json グローバル設定 CLAUDE.md すべてのプロジェクト指示 用途：個人設定、一般的な構成、シェルエイリアス

• プロジェクト .claude/ — settings.json チーム共有（コミット対象） settings.local.json 個人用オーバーライド（git-ignore対象） CLAUDE.md プロジェクト指示 agents/ SubAgent 定義 skills/ スキル定義 commands/ カスタムコマンド

6つの設定ディメンション

ディレクトリ構造

~/.claude/                          .claude/
├── settings.json      ← Global settings    ├── settings.json      ← Team shared
├── settings.local.json               ├── settings.local.json ← Personal override
├── CLAUDE.md          ← Global instructions    ├── CLAUDE.md          ← Project instructions
├── mcp.json           ← Global MCP    ├── agents/            ← Subagent definitions
├── agents/            ← Global agents    │   ├── reviewer.md
│   ├── explorer.md                   │   └── coder.md
│   └── researcher.md                 ├── skills/            ← Skill definitions
├── skills/            ← Global skills    │   ├── lint-check/
│   └── deploy-check/                 │   │   └── SKILL.md
├── commands/          ← Global commands    │   └── test-runner/
│   └── review.md                     │       └── SKILL.md
├── plans/             ← Plan files    ├── commands/          ← Custom commands
├── tasks/             ← Task persistence  │   └── commit.md
├── memory/            ← Auto memory    ├── rules/             ← Conditional rules
└── plugins/           ← Plugin installs    │   ├── tests.md
                                      │   └── security.md
                                      └── mcp.json           ← Project MCP

6つの設計原則

グローバル専用機能

• allowedPlugins / deniedPlugins — プラグインの許可リスト/拒否リスト
• managedSettings — IT部門による組織レベルの設定
• autoUpdatesChannel — アップデートチャネルの制御
• cleanupPeriodDays — セッションの自動クリーンアップ
• pluginRegistry — カスタムプラグインソース
• plansDirectory — グローバルプランファイルディレクトリ
• autoMemoryEnabled — メモリシステムの切り替え

CLAUDE.md仕様

CLAUDE.mdは、Claude Codeにおける最も影響力のある設定です。適切に構成されたCLAUDE.mdは、どのような設定の調整よりも出力品質を向上させます。

4つの保存場所

.claude/rules/の条件付き読み込み

• paths:フロントマターあり — 一致するパスで操作する場合にのみ遅延読み込みされます。フレームワーク固有のルールに最適です。例：paths: ["src/**/*.test.ts"]はテストファイルの編集時にのみ読み込まれます。

• フロントマターなし — CLAUDE.mdと同等に毎セッション読み込まれます。プロジェクト全体のルールに最適です。

執筆のガイドライン

• 200行以内に収める — これを超えると遵守率が低下します
• **「何を（WHAT）」ではなく「なぜ（WHY）」**を書く — コードはすでに「何を」を説明しています。隠れた制約、微妙な不変条件、特定のバグの回避策を記録してください
• 否定形の指示がより効果的 — 「パターンXを使用しない」は、「パターンYを使用する」よりも明確です
• コードがすでに表現している当たり前のことを書かない — CLAUDE.mdの価値は、Claudeをデフォルトの考え方から引き出すことにあります
• コードパターン、アーキテクチャのスナップショット、git履歴を保存しない — これらはコードから派生可能です
• プロジェクト固有の制約を含める：ビルド順序の依存関係、互換性のない既知のライブラリバージョン、特別なデプロイメントプロセスなど

claudeMdExcludes

claudeMdExcludes設定を使用して、不要なCLAUDE.mdファイルをスキップします：

{
  "claudeMdExcludes": [
    "**/vendor/**/CLAUDE.md",
    "**/node_modules/**/CLAUDE.md"
  ]
}

除外設定はユーザー、プロジェクト、およびローカルメモリにのみ適用されます。管理対象のポリシーファイルは除外できません。

モノレポの読み込みメカニズム

モノレポにおけるCLAUDE.mdの読み込みメカニズム（Boris Cherny氏原典）

• 祖先の読み込み — 起動時に上位に向かって走査し、すべてのCLAUDE.mdファイルを即座に読み込みます。即時

• 子孫の読み込み — サブディレクトリのCLAUDE.mdファイルは、そのディレクトリで操作する場合にのみ読み込まれます。遅延

シナリオ比較

モノレポの構造：frontend/CLAUDE.md、backend/CLAUDE.md、api/CLAUDE.md、ルートのCLAUDE.mdがあると仮定します。

シナリオ1：ルートから起動 cd /mymonorepo && claude

シナリオ2：コンポーネントディレクトリから起動 cd /mymonorepo/frontend && claude

**ベストプラクティス：**ルートのCLAUDE.mdに共通の規約を配置し、コンポーネント固有の指示は各コンポーネントのCLAUDE.mdに配置します。個人の設定はCLAUDE.local.md（git管理外）に記述します。

自動メモリ

Claude Code の自動メモリシステムは、セッション間で情報を永続化します。メモリファイルはプロジェクトの.claude/ディレクトリまたはグローバルの~/.claude/に保存され、YAMLフロントマター + Markdown形式で構成されています。

4つのメモリタイプ

メモリファイルの構造

各メモリはYAMLフロントマターを使用した独立したMarkdownファイルです：

---
name: feedback-testing
description: Testing preferences and corrections
metadata:
  type: feedback
---

Integration tests must use a real database, not mocks.
**Why:** Last quarter a migration failed due to mock/production environment divergence. 

[[testing-patterns]]  ← link to related memory

MEMORY.md インデックス

すべてのメモリはMEMORY.mdインデックスファイルを通じて管理され、200行以下に保たれます。1行あたりのインデックス形式：

- [Title](filename.md) — one-line summary

保存すべきでないもの

• コードパターン、アーキテクチャ、ファイルパス — コードから導出可能
• Git履歴、最近の変更 — git logが信頼できる情報源
• デバッグの解決策 — 修正はコードに、コンテキストはコミットメッセージに
• CLAUDE.mdで既にカバーされている内容
• 一時的なタスクの詳細 — 代わりにTaskまたはPlanを使用

設定

エージェントメモリの3つのスコープ

サブエージェントを使用すると、メモリはエージェント間で知識を永続化できます。

MEMORY.mdインデックスファイルは200行以下に保ってください。

MCP サービス

一般的な MCP サービス

MCP 設定キー

設定例

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-context7"]
    },
    "always-on-server": {
      "type": "http",
      "url": "https://mcp.example.com",
      "alwaysLoad": true
    }
  }
}

主要機能

• alwaysLoad (v2.1.121) — サーバー設定で "alwaysLoad": true を設定すると、遅延ディスカバリではなく、すべてのツールを即座に読み込みます。毎ターン必要な小規模なツールセット専用です。

• ホットリロード (v2.1.139) — /mcp 再接続は、セッションを再起動せずに .mcp.json を再読み込みします。また、stdio サーバー環境に CLAUDE_PROJECT_DIR を注入します。

環境変数の展開

.mcp.json で ${ENV_VAR} 構文を使用して環境変数を参照し、ハードコードされたシークレットを回避できます：

{
  "mcpServers": {
    "my-api": {
      "url": "https://mcp.example.com/mcp?token=${MCP_API_TOKEN}"
    }
  }
}

workspace は予約済みの MCP サーバー名です (v2.1.128)。この名前のユーザー定義サーバーは、警告付きでスキップされます。

OAuth 互換サーバーは認証を自動的に完了します (RFC 9728 に準拠)。手動での apiKeyHelper 設定は不要です。

RPI ワークフロー

Research（調査） → Plan（計画） → Implement（実装）、各フェーズには検証ゲートがあります。サブエージェントを介して複数のエージェントロールを統率します。

Step 1: RESEARCH   → RESEARCH.md (GO / NO-GO) 
Step 2: PLAN       → PLAN.md + pm.md + ux.md + eng.md
Step 3: IMPLEMENT  → IMPLEMENT.md (phased, each phase has test gates) 

8つのエージェントロール

3つのコマンド

rpi/{feature-slug}/
├── REQUEST.md              # Feature description
├── research/RESEARCH.md    # GO/NO-GO analysis
├── plan/
│   ├── PLAN.md             # Implementation roadmap (3-5 phases) 
│   ├── pm.md               # Product requirements document
│   ├── ux.md               # UX design draft
│   └── eng.md              # Technical specification
└── implement/IMPLEMENT.md  # Implementation log (per-phase verification) 

CRISPY メソッド

C — Clarify      Define requirements
R — Research     Technical research
I — Ideate       Brainstorm solutions
S — Structure    Architecture design
P — Plan         Create plan
Y — Yield        Produce implementation
  + Iterate      Iterate & refine

CRISPYはRPIの進化版であり、Ideate（構想）とStructure（構造化）フェーズを追加し、ソリューション設計が実装よりも重要であることを強調しています。

クロスモデルコラボレーション（Claude + Codex）

Claude Code (Opus) + Codex CLI (GPT) クロスモデル4ステップコラボレーションワークフロー

STEP 1: PLAN          Claude Code Opus · Plan Mode
STEP 2: QA REVIEW     Codex CLI GPT · Review plan, insert findings
STEP 3: IMPLEMENT     Claude Code Opus · Phase-by-phase implementation
STEP 4: VERIFY        Codex CLI GPT · Verify against plan

**核となるアイデア：**異なるモデルが相互にレビュー。Codexは元の計画を書き換えることなく、「Codex Finding」注釈を付加します。

エージェントチーム

エージェントチームのマルチエージェントコラボレーションワークフロー

共有のタスクリスト（TaskCreate/TaskUpdate）を通じて複数のエージェントを連携させます。独立したサブタスクに分割可能な大規模なリファクタリングに最適です。

チーム連携パターン

Time Orchestrationを例に挙げます。3つのロールが並行してビルドを行い、データコントラクト {time, timezone, formatted} を共有します。

エージェントチームコンポーネント一覧

---
name: time-agent
description: Get current Dubai time (Asia/Dubai, UTC+4) 
tools: Bash
model: haiku
color: blue
maxTurns: 3
skills: time-fetcher
---
Use Bash to execute `TZ='Asia/Dubai' date`, return time/timezone/formatted fields. 

---
description: Get Dubai time and generate SVG time card
model: haiku
---
1. Agent(time-agent) → fetch {time, timezone, formatted}
2. Skill(time-svg-creator) → generate SVG card
Note: Must execute sequentially, cannot parallelize. 

---
name: time-fetcher
description: Fetch current Dubai time via bash
user-invocable: false
---
Command: TZ='Asia/Dubai' date '+%Y-%m-%d %H:%M:%S %Z'
Return format: { time: "HH:MM:SS", timezone: "GST (UTC+4)", formatted: "full output" }

---
name: time-svg-creator
description: Create Dubai time SVG card
allowed-tools: Write, Read
---
Receive time/timezone/formatted, generate self-contained SVG card. 
Output: agent-teams/output/dubai-time.svg + output.md

スケジュールタスク

# CronCreate Parameters
cron: "*/5 * * * *"     # Standard 5-field cron (local timezone) 
prompt: "Check CI status"   # Prompt executed on trigger
recurring: true          # true=recurring, false=one-shot
durable: true            # true=persist to file

ゴール駆動

タスクシステムを利用して、自動的にタスクを分解し進捗を追跡します。

1. ユーザーがゴールを設定する
2. Claudeがサブタスクに分解し、タスクリストを作成する
3. ステップごとに実装し、各ステップでステータスを更新する
4. ブロックされた場合はユーザーの入力を求める

コミュニティのゴール運用のコツ

セッション管理

コンテキストの劣化（Context Rot）は約300〜400kあたりから現れ始めます。修正するよりも差し戻すのが優先です。

LLMパフォーマンス低下分析

LLM出力品質の日次変動

9層推論スタック（固定重み ≠ 固定動作）

┌──────────────────────────────────────────────┐
│  User session context              ← In-session degradation    │
│  System Prompt                    ← Periodically updated      │
│  Post-Training (RLHF/fine-tuning)  ← Can update silently    │
│  Sampling params (temperature/top-p) ← Server-adjustable    │
│  Speculative Decoding (draft model) ← Quality fluctuation      │
│  MoE routing / batch composition   ← ±8-14% variance   │
│  Hardware routing (TPU/GPU/Trainium)← Different failure modes  │
│  Quantization level (FP16/INT8/INT4)← May change under load │
│  Compiler & runtime (XLA:TPU/CUDA) ← Confirmed bugs  │
├──────────────────────────────────────────────┤
│  Model weights (frozen) ← This layer does not change                    │
└──────────────────────────────────────────────┘

主な知見

Anthropic 2025.9 事後分析：3つのインフラバグ

バグ #1 — コンテキストウィンドウルーティングエラー

バグ #2 — TPU出力破損

バグ #3 — XLA:TPUコンパイラの誤コンパイル（最も厄介）

Claudeは3つの異なるハードウェアプラットフォーム（AWS Trainium、NVIDIA GPU、Google TPU）で動作しており、それぞれ異なる故障モード、コンパイラ、精度動作を持っています。リクエストは日によって異なるハードウェアにヒットする可能性があります。

MoEルーティング分散（Scale AI研究）

MoE（Mixture of Experts）アーキテクチャでは、バッチ内の他のユーザーのクエリ構成が、あなたのリクエストがどのエキスパートにルーティングされるかを決定し、この構成は非決定的です。

具体例：同じモデルがジェイルブレイク耐性である日に77%、翌日に63%をスコアしました。これはバグゼロ、変更ゼロでの14ポイントの変動です。

システムプロンプトとポストトレーニングの更新

Stanford研究（2023）— そしてその論争

Chen/Zaharia/Zouの画期的な研究は、「素数判定」におけるGPT-4の精度が**97.6%から2.4%**に低下した（2023年3月→6月）ことを発見しましたが、方法論的な問題がありました：

• 3月バージョンはtemperature 0.0を使用、6月バージョンはtemperature 1.0を使用 — 根本的な交絡変数
• タスクごとに500クエリのみ — サンプルサイズが小さすぎる
• 「数学問題」は実際にはyes/no質問であり、数学能力の低下ではなく推測パターンの変化
• 変更は意図的でない低下ではなく、意図的なポストトレーニングの安全性更新の可能性がある

心理的要因

Codex 5.3 比較分析

Claudeに短期的な低下が生じた場合、Codex 5.3が著しく優れているように見えることがあります。その理由は：

1. 製品目標との適合性 — Codexはコード生成に最適化されており、同等のモデル強度でもより優れたコーディング結果を生成する
2. 推論戦略の違い — 各プロバイダーがレイテンシ/推論の深さ/デコーディングのデフォルトを独自に調整している
3. サービパスの分離 — 異なるルーティングレイヤー/コンパイラ/リリースパイプラインを持っており、一方の障害が他方に影響しない
4. リリースのタイミング — 一方のプロバイダーがリリース中で他方が安定している場合、大きな一時的な品質の乖離が生じる可能性がある

低下仮説ランキング

実践的な推奨事項

1. 利用可能な場合、モデルスナップショットを固定する（フローティングエイリアスの代わりに）
2. リクエストメタデータ（モデルID、パラメータ、レイテンシ、エラー率）を保存する
3. 固定された日次カナリアテストを実行し、回帰時にアラートを出す
4. 複数回の失敗後に長いセッションをリセットまたはコンパクトする
5. バックアッププロバイダー/モデルパスを維持する
6. 内部ダッシュボードで**「モデル品質」と「サービス信頼性」を分離**する

**最も重要な単一アクション：**品質が低下したと感じたら、/compactを使用するか、新しいセッションを開始してください。これが最も効果的な単一アクションです。「Claudeが愚かになった」ことの大部分は、モデルの低下ではなくコンテキスト汚染です。

ハーネスの重要性

よくある誤解：skill/command/subagent/hookはすべて最終的にプロンプトになるため、良いプロンプトを書けば十分だという考え。**これは間違っています。**エンジニアリングの観点では、ハーネスはプロンプトの構築システム + 決定論的実行システム + コンテキストアーキテクチャシステムです。

ハーネスの10の機能（プロンプトでは再現不可能）

出力品質 = f(有効コンテキスト, モデル能力, 反復ループ)。ユーザーが制御できる有効コンテキストはごくわずかであり、残りの部分と反復ループ全体はハーネスが制御します。強力なプロンプトは必要条件ですが、十分条件ではありません。

ブラウザMCPの比較

推奨ワークフロー

# Install command
npx playwright install
claude mcp add playwright -s user -- npx @playwright/mcp@latest
claude mcp add chrome-devtools -s user -- npx chrome-devtools-mcp@latest

Playwrightが最も高いトークン効率を持ち（186.3k残り）、Chrome DevToolsが最も低い（181k残り）。その差は約5.3kトークンです。

モノリポジトリでのスキル検出

スキルの検出・読み込みメカニズムは、CLAUDE.mdとは異なります。CLAUDE.mdは上位に向かってトラバース（祖先の読み込み）しますが、スキルはネストされたディレクトリの自動検出（子孫の検出）を使用し、対応するディレクトリ内のファイルを編集する際にオンデマンドでのみ読み込まれます。モノリポジトリの読み込みメカニズムを参照してください。

標準的なスキルの場所

CLAUDE.mdとスキルの読み込み比較

文字数バジェットはデフォルトで15,000文字です。SLASH_COMMAND_TOOL_CHAR_BUDGET環境変数で調整可能です。予算制限によりスキルが除外されたかどうかを確認するには、/contextを使用してください。

• 一般的なワークフローはルートの.claude/skills/に配置
• パッケージ固有のスキルは対応するパッケージの.claude/skills/に配置
• 危険な操作のスキルではdisable-model-invocation: trueを設定
• 混同を避けるためにパッケージ名のプレフィックスを使用（例：frontend-review、backend-deploy）

使用量と制限

監視コマンド

コスト最適化

• 単純なタスクにはmodel: haikuを使用
• effort: lowで推論を削減
• バックグラウンドエージェントはブロッキングを回避
• APIキーユーザーは--max-budget-usdを使用してコストを制御
• 予期しない課金を避けるため、追加使用量の月上限を設定

Fastモード（/fast）は、最初のトークンから追加使用量としてカウントされ、サブスクリプションプランの含まれる枠を消費しません。使用するには、追加使用量を有効にして資金を供給する必要があります。

スピナーバーブ

Claude Codeの読み込みアニメーションでは、179のランダムな動詞が使用されます。一般的なもの：

学習パス

5つの主要フェーズ・37枚のスライドを通じて、ゼロから天気レポーターを構築する完全な学習ジャーニー：

フェーズ順序（認知的依存関係に基づく再構成）

LEVELSマッピング（6レベル）

const LEVELS = {
  context:     '🔴 Context Window',   // context-window.jpeg, context.jpg
  claude_md:   '🟠 CLAUDE.md',   // Project instruction system
  agents:      '🟡 Agent System',     // Built-in + custom agents
  skills:      '🟢 Skills System',     // Skills framework
  commands:    '🔵 Commands System',     // Commands orchestration
  workflow:    '🟣 Full Workflow'    // End-to-end integration
}

37枚のスライド構成

リソースの再利用

再設計における確認事項

• **goToSlide()**の対象：37箇所すべての呼び出しサイトでインデックス番号の更新が必要
• data-level属性：各スライドのレベルマーカーをLEVELSにマッピングする必要がある
• ナビゲーションコンポーネント：prev/nextボタンを新しいスライド順序にバインドする必要がある
• プログレスバー：5セグメントの進捗インジケーターを5つのフェーズにマッピング

シンプルに始め → 段階的に構成 → 完全なオーケストレーションへ。最初から複雑なアーキテクチャを構築しないでください。フェーズの順序は認知的依存関係に基づいて再構成されています：まず「誰が」（Agents）、次に「何ができるか」（Skills）、次に「環境」（Context）、次に「ルール」（CLAUDE.md）、最後に「オーケストレーション」（Commands）を理解します。

SDKとCLIのシステムプロンプトの比較

Claude Code CLIとAgent SDKは、異なるシステムプロンプト戦略を使用しています：

主な違い

SDKはmodularプロンプトタイプを提供し、ツールの説明を個別に追加できるため、CLIの完全読み込みに比べて多くのトークンを節約できます。

10億ドルの価値がある問い

コミュニティから寄せられた13の未解決の深い問い — もしあなたが答えを持っているなら、それは10億ドルの価値ある洞察です。

メモリと指示（4つの質問）

1. CLAUDE.mdには何を含めるべきか？ — 何を入れ、何を除外すべきか？
2. CLAUDE.mdが存在する場合、constitution.mdやrules.mdはまだ必要か？
3. CLAUDE.mdはどのくらいの頻度で更新すべきか？古くなったことをどう見分けるか？
4. なぜClaudeは大文字のMUSTを使っても、CLAUDE.md内の指示を無視することがあるのか？

エージェント、スキル、ワークフロー（6つの質問）

1. Command、Agent、Skillの使い分け — ネイティブのClaude Codeが優れているのはいつか？
2. モデルがアップグレードされる際、エージェント/コマンド/ワークフローはどのくらいの頻度で更新すべきか？
3. 汎用 vs 役割/機能特化型サブエージェント — 詳細なペルソナは実際に品質を向上させるか？
4. Claude Codeの内蔵プランモードを使うか、チームのワークフローを強制するためにカスタムプランニングコマンド/エージェントを構築するか？
5. 個人スキルとコミュニティスキルはどのように共存するか？衝突した場合、どちらが優先されるか？
6. **究極の問い：**既存のコードベースをスペックに変換し、コードを削除して、AIにスペックだけから再生成させることはできるか？

スペックとドキュメント（3つの質問）

1. リポジトリ内のすべての機能にスペックファイルは必要か？
2. スペックを最新に保つため、どのくらいの頻度で更新すべきか？
3. 新機能を実装する際、他の機能のスペックへの段階的な影響にどう対処するか？

これらの問いへの答えは、エージェントエンジニアリングのベストプラクティスの方向性を決定づけるものです。もしあなたに洞察があれば、それこそが最前線です。

Boris Cherny — 13のルール

Boris Cherny — Claude Code Core Engineer

Boris Cherny は Anthropic の Claude Code コアエンジニアで、数十万人の開発者が使うエージェント型コーディングツールの開発を主導しています。O’Reilly『Programming TypeScript』の著者であり、AI 支援開発ワークフローに関する公開講演を頻繁に行っています。以下の 13 のルールは、彼の講演・デモ・PR コメントで繰り返し語られた核心的なアドバイス――チームメイトに Claude Code を教えるときに必ず伝える内容――を抽出したものです。

15の隠し機能

Boris Cherny（Meta）による、Claude Codeのあまり知られていない15の機能。それぞれが使用方法を大きく変えるものです。

12のカスタマイズのヒント

10の高度なヒント

コードレビューのヒント

テスト時の計算（Test Time Compute）: コードレビューにより、モデルは独立したコンテキストで「再度考え」、出力が**200%**増加します。マルチエージェントによる並列レビュー（セキュリティ＋パフォーマンス＋アーキテクチャ）は、単一レビューよりも高品質な結果をもたらします。

PR統計（Boris Chernyの実際のデータ）

Borisの新しいコードは約100%がAIによる記述で、人間はレビューと方向性の指示を行っています。鍵となるのは、履歴を明確にするためにファイルごとに独立したコミットを行うことです。

2つのマージのヒント

Opus 4.7 効率化の6つのヒント

Opus 4.7リリース後、Boris Chernyがまとめた6つのコア効率改善方法。

自動モードのベストプラクティス: effort: highと/focusと併用し、エージェントが高い推論深度で自律的に作業し、重要な決定ポイントのみを報告させる。

Thariq — スキル設計

Thariq Koya は Anthropic の Claude Code チームのエンジニアで、スキル設計、セッション管理、実践的なエージェントワークフローに焦点を当てています。以下のセクションは、彼が最も引用されるアドバイス――2026 年 3 月の Anthropic 内部スキルレビューと、実環境での Claude Code 利用に関する実戦ノート――を抽出したもので、本番チーム向けのスキルを設計する際に彼自身が従うのと同じパターンです。

Thariq — 実践的なヒント

セッション管理 — 詳細ガイド

Thariqの詳細なセッション管理フレームワーク：コンテキストの劣化、ブランチング戦略、サブエージェントのガベージコレクションについて理解する。

コンテキストの劣化（Context Rot）：およそ30万〜40万トークンに達すると、モデルは以前の会話を「忘れ」始め、出力品質が著しく低下します。これはバグではなく、アテンションの数学的な性質によるものです。

5つのブランチング戦略

• 戦略シナリオ説明 continue直前から継続完全なコンテキストを復元して会話を継続する rewind特定の時点に戻る指定したステップまで取り消し、そこから再開する clear新規開始コンテキストをクリアし、ゼロからやり直す compact圧縮して保持重要な情報を保持しながらインテリジェントに圧縮する subagent独立した実行サブエージェントを派遣し、メインのコンテキストを汚染しない

主要な判断表

• シナリオ推奨される対処 コンテキスト > 50%/compact またはサブエージェントを派遣 方向性の誤りrewind で分岐点に戻る、その場で修正しない compact後の品質低下要約指示付きで /compact [brief] を使用、または clear + CLAUDE.md を直接実行 履歴の保持が必要サブエージェントに新しいタスクを処理させ、メインの会話は軽量に保つ サブエージェントのコンテキスト肥大化サブエージェントには組み込みのGCがある — 完了後に自動回収され、メインセッションへの影響はない

CompactとFreshの使い分け：会話履歴が高度に関連している場合（例：デバッグの連鎖）、compact + briefを使用します。トピックが完全に変わった場合は、clearでCLAUDE.mdからコンテキストを再構築する方が効率的です。compactの品質が悪くなる典型的な原因：圧縮指示が曖昧で、重要な制約が欠落すること。

83のカテゴリ別ヒント

コミュニティのプラクティスと公式の推奨事項から、16のツールカテゴリに整理しています。主な参考文献：CLAUDE.md 規約、サブエージェント 並列処理、RPI ワークフロー。

動画ハイライト

Boris Cherny × Ryan Peterman — Claude Codeクリエイターのキャリアストーリー 初級

Boris Cherny × Lenny's Podcast — Claude Code誕生とプロダクト哲学 プロダクト

Karpathy × AI Engineer — Vibe CodingからAgentic Engineeringへ 上級

Matt Pocock ワークショップ — 2時間のClaude Code実践ワークショップ チュートリアル

よく使うコマンド（82個内蔵）

CLIフラグ（16カテゴリ）

機能別に整理された完全なCLI起動フラグリファレンス。

環境変数

設定テンプレート

# Project Name

## Tech Stack
- Frontend: React + TypeScript
- Backend: Node.js + Express

## Coding Conventions
- File naming: kebab-case
- Components: functional + hooks
- Testing: Vitest

## Constraints
- Do not use any type
- Do not skip tests
- API must have error handling

{
  "permissions": {
    "allow": ["Bash(npm run *)","Bash(git status)","Read","Grep","Glob"],
    "deny": ["Bash(rm -rf *)","Bash(git push --force)"]
  }
}

---
name: my-agent
description: Perform specific task
tools: "Bash,Read,Write,Edit,Grep"
model: sonnet
maxTurns: 20
memory: project
---

# My Agent
1. Read relevant files
2. Analyze code
3. Implement changes
4. Verify results

---
name: my-skill
description: What to do
arguments: filename
allowed-tools: "Read,Write,Edit"
paths: "src/**/*.ts"
---

Process $filename: 
1. Read → 2. Transform → 3. Write back

ワークフローチートシート