Claude Code 完全ガイド

懐疑派からパワーユーザーへ：マルチエージェントAIワークフロー構築で学んだすべて。

パート1：はじめに

Claude Code への道のり

最初から信じていたわけではありません。

Claude Code がローンチされたとき、私は懐疑的でした。また別のAIコーディングツール？革命を約束してオートコンプリートを提供するデモを見すぎていました。私のワークフローは問題なかった。VS Code、GitHub Copilot、必要なときにブラウザタブでChatGPT。なぜ変える必要が？

でも同僚がずっと絶賛していました。「オートコンプリートじゃないの」と彼女は言いました。「眠らない、イライラしない、3時間前に話したことをちゃんと覚えているシニアデベロッパーがいるようなものよ。」

1週間試してみることにしました。

それから6ヶ月。もう戻れません。

Claude Code の本質

Claude Code はAnthropicの公式Claude用コマンドラインインターフェースです。でもCLIと呼ぶのは過小評価です。

AIネイティブな開発環境です。コードベースを読みます。会話を記憶します。コマンドを実行します。ファイルを作成します。他のAIエージェントをオーケストレートします。MCP（Model Context Protocol）を通じて外部ツールと接続します。カスタムスキルを通じてパターンを学習します。

ツールというより、ターミナルに住む永続的なコラボレーターと考えてください。

マインドセットの変化

最大の調整は技術的なものではなく、精神的なものでした。

AIを質問応答サービスとして考えるのをやめなければなりませんでした。Claude Code は問い合わせるものではありません。一緒に働くものです。

今、複雑な機能に取り組むとき、「これをどうコーディングしよう？」とは考えません。「Claude に助けてもらうために、必要なことをどう説明しよう？」と考えます。

説明はタイピング速度より重要です。明確さはキーボードショートカットより重要です。目標を理解することはすべてのAPIを知ることより重要です。

何が変わったか

Claude Code を6ヶ月使った後：

スピード： 数時間かかっていたタスクが数分で終わります。速くタイプできるようになったからではなく、うまく委任できるようになったから。Claude が繰り返しの部分を処理し、私は決定に集中します。

品質： コードがより一貫しています。Claude は確立したパターンを覚えています。慣習から外れると気づきます。忘れていたであろうテストを提案します。

学習： 常に学んでいます。Claude が私と違う方法で何かを解決するたびに、新しいアプローチを見ることができます。自分とは違う経験を持つ人とペアプログラミングしているようなものです。

スコープ： より大きなプロジェクトに取り組みます。一人では野心的すぎると思えたことが、疲れを知らないコラボレーターがいると実現可能になります。

複合効果

本当の力は単一の機能にあるのではありません。それらが積み重なる方法にあります。

ワークスペースの設定はすべてを記憶します。カスタムスキルはベストプラクティスをコード化します。MCP接続はClaude に実データへのアクセスを与えます。コマンドライブラリは繰り返しタスクを自動化します。

各層は前の層の上に構築されます。毎週、設定は少しずつ良くなります。「Claude Code を使う私」と「使わない私」の生産性ギャップは継続的に広がります。

このガイドが存在する理由

始めたとき、偶然に機能を発見するのに何週間もかかりました。ドキュメントは良いですが、実際の使用から生まれるワークフローを捉えることはできません。あったらよかったと思うガイドを作りたかったのです。

これはすべての機能についてではありません。重要な機能について—積み重なるパターン、時間を節約する設定、すべてをクリックさせるメンタルモデルについてです。

始めたばかりでも、レベルアップを目指していても、私の旅があなたの旅を加速する助けになればと思います。

ワークスペースの設定

Claude Code を真剣に考え始めたのは、ツールとして扱うのをやめ、ワークスペースとして扱い始めたときでした。その変化には組織化が必要でした。

ほとんどのガイドはすぐにコマンドに飛びます。しかし構造のないコマンドは混沌です。散らばったファイル、忘れられたコンテキスト、時間とともにClaude をより役に立たなくする増え続ける混乱で終わります。

すべてをどう組織化しているか見せましょう。

2ドメインアーキテクチャ

根本的な洞察：ワークスペースには2種類のものがあります。

Assets — 実際のもの。コード、画像、動画、PDF。それらについて考えることとは独立して存在するもの。

Knowledge — ものについての理解。ノート、分析、日記。アセットの上で行う知的作業。

これら2つのドメインは別々の場所に存在します：

My Workspace/
├── projects/           # Assets: 実際のコード
├── learning/           # Assets: コース教材
├── media/              # Assets: 画像、動画
├── archive/            # Assets: コールドストレージ
│
└── vault/              # Knowledge: すべてのノート
    ├── _inbox/         # クイックキャプチャ
    ├── projects/       # プロジェクトについてのノート
    ├── research/       # リサーチ出力
    ├── technical/      # 技術ドキュメント
    └── personal/       # 日記、キャリア

決定ルール

何かを作成するとき、1つの質問がどこに行くかを決定します：

これはもの自体なのか、ものについてのノートなのか？

構築中のSwiftUIコンポーネント？projects/SwiftUI-Components/に入ります。学んだSwiftUIパターンについてのノート？vault/technical/swiftui-patterns.mdに入ります。

ダウンロードした研究論文PDF？media/papers/。その論文の分析？vault/research/topic-name/。

シンプルに聞こえますが、変革的です。何がどこにあるか迷うことはありません。決定ルールは明確です。

なぜこれがClaude にとって重要か

Claude Code は探すべき場所を知っているときに最もよく機能します。

「LLMエージェントについての研究を確認して」と言うと、Claude はvault/research/を見ます。「認証コンポーネントを更新して」と言うと、Claude はprojects/を見ます。構造が予測可能性を生み出します。

さらに重要なことに、Claude は以前の作業を参照できます。すでにトピックを分析していれば、Claude はゼロから始める代わりにその分析を見つけます。知識は断片化せずに蓄積されます。

Vault の構造

ナレッジサイドはより詳細を必要とします：

vault/
├── _inbox/             # クイックキャプチャ（毎週空にする）
├── _templates/         # Obsidian テンプレート
├── _attachments/       # 画像、生成ファイル
│
├── projects/           # プロジェクトノート（コードではない）
├── research/           # リサーチ出力
│   └── [topic]/        # 研究エリアごとに1フォルダ
├── technical/          # 技術ドキュメント
├── financial-analysis/ # ファイナンスワークフロー出力
├── presentations/      # デッキワークフロー出力
│
└── personal/
    ├── journal/        # 日次エントリー
    └── career/         # キャリアプランニング

各主要ワークフローには場所があります。リサーチ出力はvault/research/へ。財務分析はvault/financial-analysis/へ。これにより、トピックについての以前の作業を常に見つけることができます。

命名規則

命名の一貫性は認知負荷を節約します：

タイプ	規則	例
フォルダ	`kebab-case`	`swiftui-components/`
Markdown	`kebab-case.md`	`api-patterns.md`
日付付き作業	`YYYY-MM-DD-topic`	`2026-01-21-aapl/`
日記	`YYYY-MM-DD.md`	`2026-01-21.md`

もうこれについて考えません。規則は自動的です。

CLAUDE.md ファイル

すべての主要ディレクトリにはCLAUDE.mdファイルを持つことができます—そのエリアで作業するときのClaude への特別な指示。

ルートのCLAUDE.mdには：

ワークスペースの高レベル構造
キーコマンドとその目的
Claude が従うべき規則
重要なレジストリへの参照

プロジェクト固有のCLAUDE.mdファイルには：

プロジェクト固有のパターン
技術選択
テスト規則
デプロイノート

Claude はこれらを自動的に読みます。すべての会話の前にClaude にブリーフィングを与えるようなものです。

ゼロから始める

新しく始める場合：

基本構造を作成 — トップレベルにアセットフォルダ、ナレッジ用にvault
ルートCLAUDE.mdを追加 — ワークスペースを説明し、キー規則をリスト
vault _inboxを設定 — ここにクイックキャプチャが入る
最初のプロジェクトフォルダを作成 — 独自のCLAUDE.md付き
Obsidianに接続 — vaultは手動編集にObsidianと美しく機能します

最初から過度に設計しないでください。構造は使用するにつれて進化します。シンプルに始め、必要に応じて複雑さを追加してください。

毎日使う必須コマンド

Claude Code には数十のコマンドがあります。毎日約10個を使います。

これらは最も派手なコマンドではありません—27エージェントのリサーチワークフローはここにありません。繰り返しによって毎週何時間も節約する地味なものです。

クイックキャプチャ: `/capture`

最もよく使うコマンド：

/capture "認証フローを改善するアイデア - JWTの代わりにセッショントークンを使う"

これはシンプルだけど強力なことをします：ノートを正しい場所に自動的にルーティングします。

技術的な観察？vault/technical/へ
プロジェクトアイデア？関連するプロジェクトノートへ
ランダムな思考？vault/_inbox/へ

Claude はコンテンツに基づいてルーティングを決定します。目的地を選びません。キャプチャするだけです。

日記エントリー: `/journal`

日次の振り返りコマンド：

/journal

Claude が構造化された日次エントリーを通してガイドします：

何を達成したか？
何を学んだか？
何がブロックしているか？
明日の計画は？

エントリーは適切なfrontmatterと共にvault/personal/journal/YYYY-MM-DD.mdに入ります。

クイックInbox: `/inbox`

Claude にルーティング決定をさせずにキャプチャしたいとき：

/inbox "あの新しいReactコンパイラを調べる"

直接vault/_inbox/へ。分析なし、ルーティングなし。純粋なスピード。

リサーチサマリー: `/research-quick`

完全な11エージェントワークフローなしのクイックリサーチ用：

/research-quick "JWTとセッショントークンの違い"

Claude は焦点を絞ったリサーチを行い、サマリーを返します。ファイル作成なし、精巧なプロセスなし。コンテキストが必要なときの答えだけ。

コンテキスト確認: `/context`

長い会話に必須：

/context

現在のコンテキストウィンドウの使用状況を表示します。高くなったら、続ける前に終わらせるか要約する必要があります。

より便利なバリエーション：

/context dump

現在の会話状態をファイルにエクスポートします。コンテキストが埋まってきているがタスクが終わっていないときに使います。

並列実行: `/parallel`

独立したタスクがあるとき：

/parallel "テスト実行" "コードlint" "型チェック"

3つすべてが同時に実行されます。互いに依存しないタスクの場合、並列実行は大幅に時間を節約します。

日次パターン

私の典型的な1日：

朝：

/journal                    # 前日の振り返り
/inbox "考え..."            # 夜間のアイデアをキャプチャ
/context                    # 現在地を確認

作業中：

/capture "洞察..."          # 作業中にキャプチャ
/research-quick "質問"      # クイックリサーチ
/parallel "test" "lint"     # チェックを実行

1日の終わり：

/changelog                  # 変更を文書化
/context dump               # 必要に応じて状態を保存
/journal                    # 日次の振り返り

これらの10コマンドがClaude Code とのインタラクションの80%をカバーします。

第二の脳を構築する

あらゆるノートシステムを試しました。Evernote。Notion。Roam。Logseq。Apple Notes。プレーンテキストファイル。それぞれしばらく機能し、その後自身の複雑さで崩壊しました。

問題はツールではありませんでした。摩擦でした。ノートを取るのは簡単。後で見つけるのが難しい。

Claude Code がこれを変えました。より良いノートアプリだからではありません—そもそもノートアプリではありません。しかしノートを使えるようにするからです。

Obsidian との統合

私のvaultはObsidian vaultです。これが重要な理由：

ローカルファイル： すべてがディスク上のmarkdown。同期問題なし、ベンダーロックインなし。

Wikilinks： [[note-name]]でノートをリンクできます。接続のグラフが自然に生まれます。

プラグイン： Obsidianのプラグインエコシステムが複雑さなしに機能を追加します。

Claude と連携： Claude Code は同じファイルを読み書きします。インポート/エクスポートはありません。

Claude が私のVaultをどう使うか

リサーチワークフローを開始すると、Claude の最初のアクションはフェーズ0：コンテキスト発見です。

関連する以前の作業をvaultで検索します。3ヶ月前に類似のトピックを研究していれば、Claude はゼロから始める代わりにその研究を見つけて構築します。

これが複合効果です。取るすべてのノートが将来の作業の潜在的なコンテキストになります。

摩擦を減らすテンプレート

Obsidianテンプレート + Claude ワークフロー = 一貫した構造。

私のリサーチテンプレート：

---
created: "[date:YYYY-MM-DDTHH:mm:ss]"
type: research
tags: [research]
---

# [title]

## キー質問
-

## ソース
-

## 発見
-

## 含意
-

Claude が/researchを実行すると、この構造でノートを作成します。一貫性は発見可能性を意味します。

機能する検索

Claude 以前は、Obsidianの検索に依存していました。良いですが、キーワードベースです。

今はClaude のセマンティック理解を使います：

/vault-search "認証トークンについてやった分析"

Claude はキーワードを一致させるだけではありません。リクエストを理解し、正確な用語を覚えていなくても関連するノートを見つけます。

MCP Tools：すべてと接続する

Model Context Protocol — MCP — はClaude Code が本当に強力になる場所です。

MCPなしでは、Claude は賢いですが孤立しています。ファイルを読んでコマンドを実行できますが、メールをチェックしたり、データベースにクエリしたり、ウェブサイトをスクレイピングしたり、APIにアクセスしたりはできません。

MCPがあれば、Claude はすべてに接続します。

MCPとは何か

MCPサーバーをアダプタと考えてください。各サーバーはClaude に特定の機能を公開します：

[Claude Code] ←→ [MCPサーバー] ←→ [外部サービス]

Firecrawl MCPサーバーを設定すると、Claude はウェブページをスクレイピングする能力を得ます。arXivサーバーを設定すると、Claude は学術論文を検索できます。

現在のMCP設定

サーバー	目的	可能にすること
Firecrawl	Webスクレイピング	ページのスクレイプ、コンテンツ抽出
Exa	セマンティック検索	AI理解によるWeb検索
Context7	ライブラリドキュメント	任意のライブラリのドキュメントアクセス
arXiv	学術論文	研究の検索とダウンロード
AlphaVantage	金融データ	株価、ファンダメンタルズ
Apple Health	健康データ	健康メトリクスのクエリ
Twitter	ソーシャルデータ	ツイート読み取り（読み取り専用）
GitHub	リポジトリ操作	PR、issue、コミット
Chrome	ブラウザ制御	Web操作の自動化
claude-mem	ワーキングメモリ	セッション間でコンテキストを永続化

各サーバーが機能を追加します。一緒になると、Claude は全知のように感じられます。

Claude がMCPをどう使うか

外部データを必要とする質問をすると、Claude は自動的に適切なツールを使用します：

私：「Appleの株価は？」 Claude：[AlphaVantageを使用] 「Appleは$189.84で取引されています...」

私：「transformerアーキテクチャについての最近の論文を見つけて」 Claude：[arXivを使用] 「15件の関連論文を見つけました...」

MCPツールを直接呼び出しません。Claude がいつ使うか決定します。

パート2：マルチエージェントの基礎

なぜ1つのClaude では足りないのか

マルチエージェントワークフローに数ヶ月抵抗しました。複雑に見えました。複数のAIエージェントをオーケストレートするのは早すぎる最適化に感じました。

そして壁にぶつかりました。

リサーチの品質が頭打ちになりました。プロンプトがどれだけ良くなっても、単一Claudeのリサーチは浅く感じました。明らかなソースを見つけ、ニュアンスを見逃し、早まった結論を宣言していました。

問題はClaude の能力ではありませんでした。視点でした。

シングルエージェントの罠

単一のエージェントはすべてを行います：研究、分析、合成、批評。しかしこれは微妙な問題を生みます。

1つのエージェントが情報を見つけて分析すると、新鮮な視点がありません。データを収集した同じ「心」がそれを解釈します。確証バイアスが忍び込みます。

マルチエージェントの洞察

複数のエージェントは責任の分離を生み出します：

リサーチャーが情報を見つける
アナリストがパターンを解釈する
クリティックが結論に挑戦する
シンセサイザーが視点を組み合わせる

アナリストは生のリサーチプロセスを見ていません。クリティックはアナリストがなぜ特定の結論に達したかを知りません。この分離が真の多様性を生み出します。

マルチエージェントが重要なとき

シングルエージェントがうまく機能する場合：

明確な答えのあるクイック質問
定義された要件のコード生成
明らかな結論のあるシンプルな分析

マルチエージェントが輝く場合：

複数の視点を必要とするリサーチ
確証バイアスがリスクになる分析
重大なステークスのある複雑な決定

ルール：人間からセカンドオピニオンが欲しいなら、おそらく2番目のエージェントが欲しい。

スキルシステム

コマンドは明示的に呼び出すものです。/researchはリサーチを実行します。

スキルは違います。コンテキストが一致すると自動的にアクティブになります。

「アイデア」を求めると、brainstormスキルがアクティブになります。ダッシュボードを構築していると、design-systemスキルがロードされます。デバッグしていると、sequential-thinkingが作動します。

スキル vs. コマンドの決定

コマンドを使う場合：

ユーザーが明示的にアクションを要求する必要がある
マルチステップワークフローをオーケストレートする
成果物としての出力を生成する

スキルを使う場合：

コンテキストに基づいて自動的に動作を適用すべき
何の作業をするかではなくどう作業を行うかを変更する

コマンドは動詞：「これをして。」スキルは副詞：「こうやって物事をして。」

アクティブなスキル

スキル	トリガー	何をするか
Brainstorm	「アイデア」「探索」	発散/収束型の発想
Sequential Thinking	複雑な問題	信頼度付きステップバイステップ
Design System	ダッシュボード生成	Digital Craftトークン
Python Data Analysis	データ分析	Pandasパターン
MCP Resilience	MCP障害	リトライロジック
Error Handling	ワークフロー障害	回復パターン
Quality Gates	ワークフロー終了	検証

ドキュメント生成

Claude Code はテキストを書くだけでなく、実際のドキュメントを生成します。

ドキュメントコマンド

/pdf "report.md"            # markdownからPDF生成
/slides "deck"              # PowerPointプレゼンテーション生成
/spreadsheet "data"         # Excelワークブック生成
/docx "proposal"            # Wordドキュメント生成

各コマンドはターゲットフォーマットの強みを理解しています。

マルチフォーマット出力

主要なワークフローは複数のフォーマットを自動的に生成します。

/deckワークフローの出力：

PowerPointファイル（メインデッキ）
PDF（共有用）
Markdown（参照用）
スピーカーノート

/researchワークフローの出力：

Markdownレポート
PDF（フォーマット済み）
エグゼクティブサマリー

リサーチワークフロー

私の/researchワークフローは11の専門エージェントを実行します。最もよく使うワークフローです。

11エージェントアーキテクチャ

フェーズ0：コンテキスト発見
  └─ Exploreエージェント（以前の作業を見つける）

フェーズ1：リサーチ（3エージェント並列）
  ├─ アカデミックリサーチャー
  ├─ Webリサーチャー
  └─ ニュースリサーチャー

フェーズ2：分析（3エージェント並列）
  ├─ ソースアナライザー
  ├─ パターンディテクター
  └─ ギャップアナライザー

フェーズ3：品質保証（2エージェント）
  ├─ ファクトチェッカー
  └─ バイアスディテクター

フェーズ4：合成（2エージェント）
  ├─ シンセサイザー
  └─ エグゼクティブサマリー

出力

リサーチ出力はvault/research/[topic]/へ：

vault/research/llm-agents-2026/
├── research-report.md
├── executive-summary.md
├── sources.md
├── gaps.md
└── data/
    └── sources.json

コンテキストエンジニアリング

AI作業においてコンテキストはすべてです。すべてのインタラクションはコンテキストウィンドウ内で発生します。そのウィンドウに何があるかがClaude がどれだけ助けられるかを決定します。

コンテキスト問題

2つの失敗モード：

コンテキスト不足： Claude に十分な情報を与えない。

コンテキスト汚染： 無関係な情報でウィンドウを埋める。

どちらもより悪い出力につながります。

私のコンテキスト戦略

段階的開示： 最初は最小限のコンテキストをロード。必要に応じて拡張。

コンテキスト分割： マルチエージェントワークフローはエージェント間でコンテキストを分割。

含める代わりに参照： 貼り付けの代わりにパスでファイルを参照。

状態管理： /context dumpで定期的に状態を保存。

コンテキスト使用状況の監視

/context

使用率	アクション
0-40%	通常通り続行
40-60%	大きなワークフローを避ける
60-80%	まず圧縮
80-95%	ダンプして再起動

パート3：高度なオーケストレーション

マルチエージェントオーケストレーション

複数のエージェントを実行するのは簡単です。効果的に調整するのが難しい部分です。

オーケストレーションの次元

タイミング — 各エージェントはいつ実行するか？ 依存関係 — どのエージェントがどの他のエージェントからの出力を必要とするか？ データフロー — エージェント間でどの情報が渡されるか？合成 — 出力はどう結合されるか？

並列 vs. 逐次

並列実行： 互いに依存しないエージェントは同時に実行。

逐次実行： エージェントBがエージェントAの出力を必要とするとき、順番に実行。

ハイブリッドパターン： フェーズ内：並列。フェーズ間：逐次。

フェーズ設計

フェーズ0：コンテキスト発見
フェーズ1：収集（並列）
フェーズ2：処理（並列）
フェーズ3：品質保証（並列）
フェーズ4：合成（逐次）
フェーズ5：出力（逐次）

Quality Gates

AI生成コンテンツは自信を持って間違っている可能性があります。

Quality gatesは出力が進む前に検証されるチェックポイントです。

Quality Gatesがチェックすること

チェック	何を捕まえるか
引用検証	ソースなしの主張
ソース品質	信頼できないソース
信頼度キャリブレーション	過信した主張
内部整合性	矛盾
ギャップ識別	欠けている側面

品質レポート

# 品質レポート

## 総合スコア：87/100

## 検証済み主張
✓ 収益数字（ソース：SEC 10-Q）

## フラグ付きアイテム
⚠ アナリスト予測に基づく予測

## 未検証主張
✗ 「業界インサイダーが示唆...」

## 推奨事項
注意事項付きで使用可能。

Ralph Loops

Claude が早く止まりすぎることに気づきました。80%のテストカバレッジを求めると、いくつかのテストと「カバレッジを改善しました」を受け取りました。しかしカバレッジはまだ50%でした。

Ralph loopsがこれを修正します。

コアコンセプト

完了プロミスが検出されるまで止まらない。

/ralph-loop "テストカバレッジを80%に改善。完了したら<promise>80% COVERAGE</promise>を出力。"

Claude が実行。カバレッジをチェック。テストを書く。80%まで繰り返す。そしてプロミスを出力。ループ終了。

良いプロンプトの書き方

明確な現在状態： 現在のテストカバレッジ：45%

測定可能なターゲット： ターゲット：80%カバレッジ

バイナリ完了： カバレッジ >= 80%のとき<promise>80% COVERAGE ACHIEVED</promise>を出力

安全制限

最大イテレーションキャップ（デフォルト：20）
ストール検出（3イテレーション進捗なしで終了）
チェックポイント保存

プレゼンテーションフレームワーク

私の/deckワークフローはMcKinsey、BCG、Sequoia、Amazon、Appleのフレームワークをコード化しています。

8つのフレームワーク

フレームワーク	使用場面	スライド数
McKinsey Pyramid + SCQA	エグゼクティブ決定	10-15
Hypothesis-Driven	戦略的提言	12-20
Sequoia Pitch	投資ピッチ	10
Amazon PRFAQ	製品ローンチ	6-10
Assertion-Evidence	技術オーディエンス	15-25
Marketing Strategy	キャンペーンピッチ	15-20
Agency Creative	クリエイティブコンセプト	15-25
Apple Keynote	製品キーノート	30-50

コア原則

結論ファースト： 推奨から始める。

アクションタイトル： スライドタイトルは完全な文であるべき。

1スライド1メッセージ： スライドが2つのポイントを作るなら、分割する。

パート4：本番ワークフロー

Deep Research

標準の/researchは11エージェントを実行します。/deep-researchは12フェーズにわたる27エージェントで、100+ソースを目指します。

アーキテクチャ

フェーズ0   → コンテキスト発見
フェーズ1   → リサーチ計画
フェーズ2   → プライマリ検索（5エージェント並列）
フェーズ3   → 論文取得
フェーズ4   → 引用チェーン再帰
フェーズ5   → 品質保証（4エージェント）
フェーズ5.1 → 信頼性ディープダイブ（4エージェント）
フェーズ5.5 → ファクトチェックフィードバックループ
フェーズ6   → 高度分析（3エージェント）
フェーズ7   → 合成（3エージェント）
フェーズ8   → 可視化（2エージェント）
フェーズ9   → レポート生成
フェーズ10  → 統合

引用チェーン再帰

基礎的な論文は現在の研究から2-3引用離れていることが多い。再帰がそれらを見つけます。

リソース消費

メトリック	/research	/deep-research
エージェント	11	27
トークン	~300K	~750K
実行時間	5-10分	30-60分
ソース	25-50	100+

マーケティングワークフロー

私の/marketingワークフロー：4サブワークフローにわたる12エージェント。

サブワークフロー

/marketing "Product"           → フル4フェーズ（12エージェント）
/marketing-research "Product"  → リサーチのみ（3エージェント）
/marketing-strategy "Product"  → 戦略のみ（3エージェント）
/marketing-creative "Product"  → クリエイティブのみ（3エージェント）
/marketing-execution "Product" → 実行のみ（3エージェント）

フェーズ1：リサーチ

Market Intel： 市場規模、競合、価格設定 Social Research： リスニング、センチメント、フィードバック SEO Content： キーワード、コンテンツギャップ

フェーズ2：戦略

Strategy Architect： ポジショニング、ペルソナ、メッセージング Channel Strategist： チャネル、インフルエンサー、メール Validation Agent： すべての主張をファクトチェック

フェーズ3：クリエイティブ

Creative Lead： コンセプト、ビジュアルディレクション Content Producer： ヘッドライン、コピー、CTA Video Producer： スクリプト、ストーリーボード

フェーズ4：実行

Media Planner： 予算、ペーシング、チャネル Analytics Architect： KPI、アトリビューション、テスト Viz Generator： ポジショニングマップ、ジャーニービジュアライゼーション

カスタムスキルの作成

スキルはコンテキストが一致すると自動的にアクティブになります。

スキルの構造

.claude/skills/[skill-name]/
├── SKILL.md           # コア指示
├── scripts/           # 自動化ヘルパー
├── references/        # 詳細ドキュメント
└── assets/            # テンプレート

重要なFrontmatter

---
name: skill-name
version: 1.0.0
description: アクティベーション用の特定のトリガー。
---

悪い： 「コンテキスト管理を支援」 良い： 「コンテキスト > 60%のとき現在のタスク状態をmarkdownにエクスポート」

良いスキルの条件

特定のトリガーが広いトリガーに勝つ
コンテンツよりプロセス
一貫した出力フォーマット
統合がチェーニングを可能にする

コマンドからワークフローへ

コマンドは明示的な呼び出し。ワークフローはオーケストレートされたマルチエージェントプロセス。

設計原則

常にフェーズ0： 関連する以前の作業をチェック。

可能な限り並列： 独立した作業は同時に実行。

明示的な依存関係： 各エージェントが必要とするものを文書化。

構造化されたハンドオフ： 生データではなくサマリーを渡す。

Quality Gates： 合成前に検証。

グレースフルデグラデーション： 完全な失敗なしに障害を処理。

付録

クイックリファレンス

ワークフロー比較

ワークフロー	エージェント	実行時間	出力
`/research`	11	5-10分	リサーチレポート
`/deep-research`	27	30-60分	文献レビュー
`/finance`	7	10-15分	財務分析
`/marketing`	12	15-20分	GTM戦略
`/deck`	10	10-15分	プレゼンテーション

コンテキストガイド

使用率	アクション
0-40%	通常通り続行
40-60%	大きなワークフローを避ける
60-80%	まず圧縮
80-95%	ダンプして再起動

コマンドチートシート

デイリーコマンド

/capture "ノート"      # スマートルーティング
/journal              # 日次エントリー
/inbox "ノート"       # クイックキャプチャ
/context              # 使用率チェック
/context dump         # 状態エクスポート

リサーチ & 分析

/research "トピック"           # 11エージェントリサーチ
/deep-research "トピック"      # 27エージェントレビュー
/finance "TICKER"             # 財務分析

ドキュメント生成

/pdf "コンテンツ"     # PDF生成
/slides "トピック"    # PowerPoint
/spreadsheet "データ" # Excel
/docx "ドキュメント"  # Word

ワークフロー制御

/parallel "cmd1" "cmd2"   # 並列実行
/ralph-loop "タスク"      # 反復ループ
/cancel-ralph            # ループ停止

エージェント設定例

リサーチエージェント

Task({
  subagent_type: "research-analyst",
  model: "opus",
  prompt: `[topic]をリサーチ。見つけるもの：
    - 学術ソース
    - 業界の視点
    - 最近の動向
    構造化された発見を返す。`
})

Quality Gateエージェント

Task({
  subagent_type: "code-reviewer",
  model: "opus",
  prompt: `主張を検証：
    [主張]

    各々について：ソース、検証、信頼度。`
})

最後に

Claude Code との6ヶ月は私の働き方を変えました。単一の機能のためではなく、能力が積み重なる方法のためです。

ワークスペース構造によりClaude は以前の作業を見つけられます。vaultは知識を保存します。MCPは外部データに接続します。スキルはベストプラクティスをコード化します。ワークフローは複雑なプロセスをオーケストレートします。Quality gatesは信頼性を保証します。

各層は前の層の上に構築されます。毎週、システムは少しずつ良くなります。

始めたばかりなら：基本に集中してください。ワークスペース構造。デイリーコマンド。習慣を作ること。

レベルアップを目指しているなら：深める1つのエリアを選んでください。マルチエージェントオーケストレーション。カスタムスキル。Quality gates。広げる前に深く行ってください。

Claude Code はここ数年で採用した最も重要な生産性ツールです。私のために機能するからではなく、私と一緒に機能するから。

このガイドは6ヶ月の日常使用からの教訓をまとめています。特定のコマンドリファレンスについては、コマンドチートシートを参照してください。

Claude Code 完全ガイド

目次

パート1：はじめに

Claude Code への道のり

Claude Code の本質

マインドセットの変化

何が変わったか

複合効果

このガイドが存在する理由

ワークスペースの設定

2ドメインアーキテクチャ

決定ルール

なぜこれがClaude にとって重要か

Vault の構造

命名規則

CLAUDE.md ファイル

ゼロから始める

毎日使う必須コマンド

クイックキャプチャ: /capture

日記エントリー: /journal

クイックInbox: /inbox

リサーチサマリー: /research-quick

コンテキスト確認: /context

並列実行: /parallel

日次パターン

第二の脳を構築する

Obsidian との統合

Claude が私のVaultをどう使うか

摩擦を減らすテンプレート

機能する検索

MCP Tools：すべてと接続する

MCPとは何か

現在のMCP設定

Claude がMCPをどう使うか

パート2：マルチエージェントの基礎

なぜ1つのClaude では足りないのか

シングルエージェントの罠

マルチエージェントの洞察

マルチエージェントが重要なとき

スキルシステム

スキル vs. コマンドの決定

アクティブなスキル

ドキュメント生成

ドキュメントコマンド

マルチフォーマット出力

リサーチワークフロー

11エージェントアーキテクチャ

出力

コンテキストエンジニアリング

コンテキスト問題

私のコンテキスト戦略

コンテキスト使用状況の監視

パート3：高度なオーケストレーション

マルチエージェントオーケストレーション

オーケストレーションの次元

並列 vs. 逐次

フェーズ設計

Quality Gates

Quality Gatesがチェックすること

品質レポート

Ralph Loops

コアコンセプト

良いプロンプトの書き方

安全制限

プレゼンテーションフレームワーク

8つのフレームワーク

コア原則

パート4：本番ワークフロー

Deep Research

アーキテクチャ

引用チェーン再帰

リソース消費

マーケティングワークフロー

サブワークフロー

フェーズ1：リサーチ

フェーズ2：戦略

フェーズ3：クリエイティブ

フェーズ4：実行

カスタムスキルの作成

スキルの構造

クイックキャプチャ: `/capture`

日記エントリー: `/journal`

クイックInbox: `/inbox`

リサーチサマリー: `/research-quick`

コンテキスト確認: `/context`

並列実行: `/parallel`