はじめに
Claude Code でシステムを組み始めると、特定の処理を「エージェントに任せたい」という誘惑が出てくる。「提案書作成専用エージェント」「書類管理エージェント」「メール下書きエージェント」——作業ごとに担当者を立てる発想は自然だ。
しかし実際には、エージェントを増やすほど「誰が何を判断したか」が追いにくくなり、システムは複雑になる。八雲の内部設計ではエージェントは3人の責任者のみに絞り、定型作業はすべてスキル（スラッシュコマンド）として実装している。この記事ではその設計判断の背景と、運用してわかった実態を書く。
課題: agent と skill の違い、agent を増やすと何が壊れるか
Claude Code には大きく2つの拡張手段がある。
エージェント（.claude/agents/） は会話コンテキストを持つ独立した判断主体だ。@agent-name で呼び出し、自律的に複数ツールを組み合わせて判断・実行する。メモリを持ち、複数ステップにまたがる作業を引き受けられる。
スキル（.claude/skills/） はスラッシュコマンドで呼び出す手順書だ。引数を受け取り、定義された手順を実行して終わる。判断はしない。実行する。
問題は「エージェントを作りすぎると何が起きるか」だ。具体的には3つの問題が出る。
まず判断の追跡が難しくなる。エージェントAがエージェントBを呼び出してエージェントCに委任すると、「どのエージェントがこの判断をしたか」が見えにくくなる。何かミスが起きたとき、原因を特定するのが難しい。
次にコンテキストが断片化する。エージェントは独立したコンテキストで動く。複数エージェントが同じドメインの情報を扱うと、整合性が保てなくなる。「どちらのエージェントが正しい情報を持っているか」という問題が生まれる。
最後に保守コストが増える。エージェントが10人いれば、10人分の設計を更新し続ける必要がある。作業が変わるたびに複数エージェントを修正する。スキルなら手順書1本を更新すれば済む。
アプローチ: 「判断は責任者エージェント、実行はスキル」境界
八雲の設計はシンプルな原則に立つ。
エージェントが持つべきもの: 業務の文脈・優先順位・例外処理の判断。「この案件は提案すべきか」「このメールに返信が必要か」という判断レイヤー。
スキルに任せるもの: 判断が固まった後の実行。「提案書を作る」「下書きを保存する」という確定済みアクション。
組織図で言えばこうなる。
事業責任者 director
├─ 営業責任者 sales-director
└─ 開発責任者 dev-director
└─ web-developer（Web 制作の実装担当）
共通スキル（責任者が必要に応じて直接実行）
書類系: /estimate /invoice /publish /onboard
営業系: /scrape /pipeline /propose /submit
秘書系: /minutes /recap /mail-draft
Web 制作: /website-build（+ 内部の /web-* 群）
タスク管理: /task-create /task-sync
レポート系: /weekly-reportエージェントは3人だけ。残りはすべてスキルだ。
責任者エージェントがスキルを呼び出すことで、「誰が判断してこの作業を実行させたか」が常に明確になる。@sales-director が /propose を実行した、という委任チェーンが見える形で残る。
skill にすべき作業の見分け方
どんな作業をスキルにすべきか。判断基準は3点だ。
決定論的であること。同じ入力から同じ出力が得られる作業。テンプレートへの値の流し込み、API への定型リクエスト、ファイルの移動・保存——これらは判断を必要としない。
テンプレート化可能であること。フォーマットが固定されている作業。提案書も見積書も、テンプレートがあればスクリプトで生成できる。「どのテンプレートを選ぶか」という判断だけが人間（または責任者エージェント）の仕事だ。
繰り返し発生すること。1回きりの作業をスキルにする意味は薄い。週次レポート・日次スクレイピング・メール下書きのように定期的に発生するものが候補になる。
逆に言えば、コンテキストが変わるたびに判断が必要な作業はスキルに落とせない。「今の営業状況を踏まえてこの案件を評価する」という処理は、判断レイヤーの責任者エージェントが担うべきだ。
実例: スキルとして実装した作業群
八雲の Synapse には現在、6カテゴリ・17本のスキルが実装されている。
書類作成系（4本）: 見積書・請求書の PDF 生成と公開、新規案件のフォルダ・初期書類準備。テンプレートを Drive から files.copy するだけなので、LLM を介さずスクリプトだけで完結する。
営業自動化系（6本）: クラウドソーシング案件のスクレイピング・スコアリング・提案書作成・フォーム提出・出品管理・サムネイル生成。このカテゴリは内部実装の詳細を公開する性質ではないが、「どのサイトに・どの手順で・何を送るか」がすべてスキルと設定ファイルに閉じている。
秘書・記録系（3本）: 議事録の Google Docs 保存、セッション振り返り要約、Gmail 未読への返信下書き自動生成。判断（返信が必要かどうか）は Claude が担うが、実行（下書き作成）はスキルの手順通りに動く。
Web 制作系（1本 + 内部 5本）: /website-build が「競合調査 → デザインシステム定義 → ページ設計 → 実装 → レビュー」の 5 段階パイプラインを順に実行する。内部では /web-research /web-design /web-architect /web-build /web-review という個別スキルに分割されており、途中ステップからの再開も --from オプションで可能だ。
タスク管理系（2本）: Notion タスクの新規作成と、承認済みタスクの自動実行・完了化。launchd で 5 分ごとに polling しているため、Notion を承認するだけで処理が走る。
レポート系（1本）: 個人の週次活動（git・Gmail・Calendar）を集計してスプレッドシートに追記する。毎週実行されるが、スキルの中身は変わらない。
これらすべてに共通するのは「判断を内包していない」という点だ。提案書を「誰に送るか」は @sales-director が決める。スキルはその判断を受け取って「どう送るか」を実行するだけだ。
運用してわかった効果と落とし穴
運用を続けて見えてきたことがある。
効果として大きかったのは変更コストの低さだ。 スキルは手順書なので、仕様が変わったら1ファイルを書き直せば済む。エージェントだと「このエージェントはその変更を知っているか」という確認作業が生まれる。スキルファーストの設計は、仕様変更への耐性が高い。
もうひとつは手順の透明性だ。 スキルには実行手順がそのまま書かれている。「何をしているか」が読めば分かる。エージェントだと「エージェントが判断してどう動いたか」が見えにくくなることがある。
落とし穴としては、スキルを汎用化しすぎると複雑になる点がある。 最初は「どの書類にも使えるスキルを作ろう」と考えがちだが、見積書と請求書はフォーマットもロジックも違う。引数で分岐させるよりスキルを分けた方が読みやすい。実際、/estimate と /invoice は最初の設計では1本にしようとしたが、分割して正解だった。
もうひとつの落とし穴は、責任者エージェントへの依存が増えすぎることだ。 スキルが増えれば増えるほど、「どのスキルを使うべきか」を判断する責任者エージェントの負荷が上がる。スキル数が 30 本を超えると、エージェントのコンテキストにスキル一覧が収まりきらない問題が出てくるかもしれない。現時点では 17 本で収まっているが、将来的にはスキルをカテゴリ別に分割して部分ロードする仕組みが必要になるかもしれない。
まとめ
エージェントを増やすことは組織を増やすことに似ている。「専門担当者がいれば速い」という直感は正しい場面もあるが、組織が大きくなると調整コスト・伝達コスト・責任の不明確さが積み上がる。
スキルファースト設計の核心は「判断と実行を分離すること」だ。判断は責任者エージェントが持つ。実行はスキルが担う。この境界を意識的に引くことで、システムの見通しと変更耐性が保てる。
「エージェントを作るべきかスキルにすべきか」で迷ったとき、問うべきは一点だ。この処理は文脈によって判断が変わるか？ 変わるならエージェント、変わらないならスキルだ。