Skillsは効率化、Agentsは"自分の拡張"——Builder時代のエージェント編成（CC Night 2026）

CC Night（Claude Code Night）2026-06-12 の登壇資料です。

Claude CodeのSkillsとAgents（Subagents）をどう使い分けるか。「Skillsは効率化、Agentsは自分の拡張」という整理を軸に、30日分の作業ログ集計から、エージェント編成の実態とコストを扱います。

主な内容:
- Skills / Subagents / Agent Teams / Workflow の定義と使い分け
- 30日の実測データ: 起動回数・トークンコスト・エージェントの死因分類
- Claude Code作者 Boris Cherny ら先人たちの運用スタイルと検収の考え方の比較
- ブランド制作を分担する6体のエージェントチームの編成・命名・Memory運用
- デザイナーからbuilderへ、役割が広がる現在地

Transcript

1. claude code night Skillsは効率化、 Subagentsは“自分の拡張” 上村 裕樹 / Studyplus デザイン責任者 Builder時代のエージェント編成 2026-06-12
2. profile 上村 裕樹 Studyplus デザイン責任者 ここの見出しは8回書き直したけど 決まりませんでした( by Claude) Claudeの私への評価 検収: 一級。成果物を無検収で通さない——この登壇資料も4観点の監査agentにかけられ 原動力: しつこい楽観。 Studyplus デザイン責任者（2025-12〜） 。 デザインシステム運用・リニューアル主導・デザイン組織の発足/評価/育成・ AI×開発プロセス改善 軸は UI/UX × フロントエンド × 教育。 ここ数ヶ月はアプリ実装・LPコーディング・ロゴ・UI・スライドとマネジメント 経歴: ヤフー（広告ツールのデザインリード/フロントエンド）→ atama plus（教育×プロダクトデザイン）→ LayerX（バクラク/デザインマネージャー・デザインオプス）→ Studyplus 02 / 31
3. profile Flugma: FlutterでFigma Likeなライブデザインキャンバス 2ヶ月前（2026-04、社内の四半期総会）に発表したFlutter個人開発ツール Flutterの本番コードを無限キャンバスに並べ、選択したWidgetを自然言語で編集。Claudeがコードを書きHot Reloadで即反 映 Figmaなどの中間制作物を経由せず、本番コードでそのままデザインする（Code = Design） Dartを書いたことのないデザイナーが、200画面のリニューアルを進めるためのツールをAIに作らせた実例 3週間 で実用レベル クローズしたIssue 100件超 1日最大 18コミット 200画面 を俯瞰 03 / 31
4. demo Flugmaデモ 「この余白を詰めて」 「色をブランドに合わせて」と指示すると、本番コードが書き換わります。 04 / 31
5. definitions & data Subagentsの定義とデータ 01 05 / 31
6. definitions Subagents .claude/agents/ （定義ファイル） 1. Subagents（本義） 単発委譲。結果は親にのみ返す。 主目的 = メインコンテキストの保護 Main agent Subagent 2. Agent Teams 複数インスタンスが直接通信。リー ド1＋メンバー（実験的機能） 。 主目的 = チーム戦と相互批評 Lead Agent Member 3. Background 並列独立セッション。セッション間通信 なし。 主目的 = 長時間タスクの並列放牧 session session session session ＋ Workflow コードがSubagentsを順番・並列・ループで指揮する自動化層。agent同士は通信せず、結果はスクリプトが受けて次に配る。走らせ方の4つ目ではなく、 Subagentsの上に乗る指揮の道具 06 / 31
7. definitions .claude/agents/ は至る所に増殖する TIPS: 同名agentは project > user で上書き（shadowing） 。plugin agentでは hooks / mcpServers / permissionMode が無効 ——挙動を変えたい借り物は .claude/agents/ にコピーして所有する dotfiles × 会社repo × plugin——エージェント定義は気づくと点在します 実例: 自分のブランドチーム定義が3箇所に重複。どれが正か、作者本人も分からなくなった 数十体入りの「全部盛りプラグイン」は、入れても呼ばれない。仕事に紐づかない定義は読まれない 対処: 置き場所の正を1つに決める / 借り物は使う分だけ自分の置き場に移す / 編成判断そのものを自動化する 自作の team-builder スキル: dotfiles・プロジェクト・プラグインに散らばる全agent定義をスキャンし、チームサイエンスの 知見（適正人数・思考スタイルの偏り検出）を当てて、タスクに合うチームを組成・実行・記録する 07 / 31
8. data 自宅のMacで呼び出したSubagentsの集計 Agent （10 回以上） 回数 中身 codex-rescue 35 別エンジンの独立レビュー general-purpose 32 汎用的な作業委譲 domain-specialist 22 個人開発のドメイン専門家 Skill側の上位は session_reflection 11 / review 7 / dev_loop 5 / gmail-inbox 5 本業Mac（会社環境）の上位はSkill——slack-watch 17 / sync-claude 15。縦に深い個人開発はagent中心、横に広い本業 はskill中心で回っていました 08 / 31
9. data Subagentsたちの墓場——呼び出し0回が23体 自宅Macの30日で呼び出し0回が23体。丁寧に人格設計したagentほど、安らかに眠っています。 ……ほか10体。人格を込めて設計したのに、名前を思い出すのに30秒かかりました 死因1: 構造死——ラベルだけで仕事が流れていない（蘇らない）［例: ui-designer, art-director］ 死因2: 時代死——人間による手動ディスパッチの限界（Dynamic Workflows / hooks / Agent Teamsで蘇る）［例: obento-master］ clerk financial-planner obento-master social-secretary travel-agent health-coach art-director creative-director ui-designer ux-researcher executive business-analyst data-scientist 09 / 31
10. data 生き残った自作agentは全部「拡張」 生存則は「仕事が流れている × 自分の拡張」 。 Skillsは効率化（自分の型化・転用が効く） 、Agentsは拡張（外側の能力を自分に加える） 死んだ自作agentの典型が、さっきのデザインstudio陣（art-director / creative-director / ui-designer / ux-researcher） ——自分の仕事の型化どまりで、型化はSkillで足ります 生きた自作agent（個人開発のドメイン専門家 22回 / product-manager / code-architect / codex-rescue 35回）は全 部、自分の外側の領域 自分の領域で生きた例外 brand-qa は、自分の成果物への独立レビュー。自己レビューでは出せない視点＝これも拡張です 10 / 31
11. data Subagentsのコスト agentのコストを測ると、正しい組み方が見えました +35% ターン所要の増加——主作業をsubagentに委譲した場合 わたしの実測・30日 ＝細切れに渡すと、往復で遅くなる 5 〜6倍 3体並列のトークン消費——単体比 ICLR 2026実測 含意: 並列に作らせると、高くつく メインのスレッドで密に進める。レビューと検証だけを、別のSubagentsに切り出す ——この切り出し方をコードで構造化する道具がworkflowです 11 / 31
12. data 名付けしてみたら覚えやすかった ネイビー クリエイティブディレクター ピンク ビジュアルデザイナー イエロー コピーライター アジュール Webビルダー ターコイズ PMM ベージュ デザインオプス Studyplusのブランド制作（ロゴ・LP・スライド・名刺・アイコン）を分担する6体のエージェントチーム 名前はブランドカラーから。パレットがそのまま名簿になり、色の意味が役割を覚えさせる 12 / 31
13. learnings Subagentsと向き合って学んだこと 02 13 / 31
14. memory MEMORYを育てる user (~/.claude/agent-memory/) project (.claude/agent-memory/) local MEMORY.md 先頭200行（または25KB）が システムプロンプトに自動注入される TIPS: plugin agentにもmemoryを付与できる（無効は hooks / mcpServers / permissionMode のみ、2026-06-11確認） 。ディレ クトリは初回呼び出しで生成——一度も呼ばれていないagentにはディレクトリ自体が無い（墓場の検出にも使える） コアエージェント への集中 1. 記憶が貯まる 2. 良い仕事をする 3. また使われる 設定はfrontmatterに memory: project の1行のみ（git共有でチー ムにも渡る） 全agentに配るのではなく、よく使う少数のコアagentに集中させ る 育つ条件は「呼ばれる × 跨いで覚える価値がある」 。個人開発の PM agentのMEMORY.mdは毎日更新 14 / 31
15. science キャラ付けの効果 層 効果 根拠 名乗り（ 「一流の専門家として」 ） 知識タスクに微害 PRISM（2026-03）: ペルソナ付与でMMLU 71.6%→66.3% 語彙・制約（形式・トーン指定） 効く 同研究: アライメント系タスクには有益 観点固定（レビュー観点の割り当て） 効く 役割分化は情報の流れを変える（multi-agent debate研究） 独立コンテキスト 効く コンテキストウィンドウの増殖。Fable 5公式も独立検証を推奨 名前・顔 人間に効く TMS（Wegner 1987）: 「誰を呼ぶか」の検索精度 人格はモデルの能力を足しません。効くのは構造（語彙・観点・権限・コンテキスト）と、人間側の運用記憶です 3〜7体の適正規模は同時に協調させる数（1タスクあたり） 。定義済みの名簿の総数ではありません——名簿はglobal（汎用）/ project（文脈特化）の階層で持ち、走らせるのは都度3〜7体 実験中: agentに思考スタイル（分析型・生成型・批判型）のメタデータを付け、チーム編成時に偏りを検出する——「批判役の 割り当てが議論を深める」ことは研究でも実証されています（EMNLP 2024 / CHI 2026） 15 / 31
16. naming 命名と分割の設計 命名 name 人間のため（呼ぶ・覚える） description 機械のため（委譲の判定材料） 本文 モデルのため（振る舞いの指示） 呼び出しを決めるのはdescriptionだけ。nameは職能名でも 固有名でも挙動は変わらない descriptionの公式の型 [職能名] for [具体用途]. Use proactively when [トリガー条件] 分割 シェフ 味を最大化 vs 管理栄養士 制約を守る 分割の判断軸はタスク数ではなく「目的の方向が逆か」 。生 成と検証を1体が兼ねると、自分の出力を正当化する方向 に収束する（思考の縮退） 方向が逆 → 分ける / 同方向 → 統合1体で始めて、問題が 出てから分割する。投機的な分割は過剰設計 TIPS: モデルの割り当ても編成の設計判断——model を省略すると主モデルを継承し、Fable 5セッションでは全workerがFable 5で走ってsession limitに到達（実測） 。レビュー・定型は model: sonnet を明示固定 16 / 31
17. now & next 現在から未来へ 03 17 / 31
18. map multi-agentの地形（2026年） 2026-03-19 Cognitionの転向: 「Devin can now Manage Devins」を発表。9ヶ月前に「Don't Build Multi-Agents」と 書いた当人たちが、自分で作りました 2026-04 研究: 等トークン予算ではsingle-agentが優位になりやすい（multiが有利なのはコンテキスト超過・並列探索時）/ 異モデル 間の誤り重複は小さい——独立検証は別エンジンが効く 2026-06 Claude Fable 5公式ガイド: 並列subagentの積極活用、 「独立した検証サブエージェントは自己批評より良い結果を出す傾向 がある」 、モデル世代ごとの環境棚卸しを公式推奨 現在の問いは「使うか否か」ではなく「どの条件で何を走らせるか」です 構成: coordinator役のDevinが作業範囲を決め、複数のmanaged Devinを独立した実行環境で並列に走らせる 理由は「contextが溜まるとfocusが劣化し、サブタスクの品質が落ちる」——隔離の論理にたどり着いての実装。撤回宣言 はなく、実装が答えでした 18 / 31
19. map 巨人の考え 人物 並列度 検収のスタイル Boris Cherny（Claude Code作者） 日に数百〜数万体（2026- 06-08） 検収もagent化——仕様→草稿→簡素化→検証のパイプライン。8ヶ月 コードを手書きしていない Peter Steinberger（PSPDFKit創業者） 5〜10体並列 コードは読まない。テストと結果で検収 Mitchell Hashimoto（Ghostty作者） commit単位の独立セッシ ョン 人間が全行レビュー。理解したコードだけ出荷 Andrej Karpathy（OpenAI共同創業者） 条件付き並列（2025-12に 転換） コンテキスト規律と監視を重視 Armin Ronacher（Flask作者） 使いつつ自戒 「agent psychosis」＝没入で判断が歪み、寝ずに作り続けてしまう 中毒への警告（2026-01） ほぼ全員が並列前提になりました。重心はmultiへ——Cognition転向・Cursor 3.0並列agent・Dynamic Workflows・ Fable 5公式推奨（いずれも2026年） 分かれているのは検収のやり方です。実行は任せられるようになっても、検収の設計は自分の仕事として残っている 19 / 31
20. builder shift 「builder」への置き換えが始まっている PM Designer Engineer Builder 64% Figma「State of the Designer 2026」で、デ ザイナーの64%が「2つ以 上のロールを兼ねる product builder」と自認 +17.5% 前年比で担当タスク領域が 拡大（同調査） 「software engineerという肩書は消えていき、 『builder』に置き換わる」 — Boris Cherny（Claude Code作者、2026-02） TIPS: LinkedInは新卒APM採用を廃止しAssociate Product Builderを新設（2025-09採用開始） 。背景はAIで「作る力」の供給が需要の伸びより先に 増え、1人の守備範囲が横（複数プロジェクト）にも縦（上流の判断）にも広がる構造 20 / 31
21. craft Craftに根を下ろし、横はAgent資産で広げる Skills（効率化） 自分のやり方を言語化し、専門知識を 肉付けする。転用が効く（モビリテ ィ） 。 Agents（拡張） 自分の外側の領域を系に加える Skills（効率化） 自分の仕事の型化 Human (Core Craft) 自分の最も深い専門性 Agents（拡張） 自分の中に「元」がない領域を補う。 効率化ではなく、能力そのものの拡張 （例: デザイナーがAIのQAエンジニア を雇う） 。 誰もがBuilderになる時代、 「全部そこそこ」AIができてしまうのでただ広げるだけだと差別化できない。 自分のCraftに深く根を下ろしたまま、横の広がりはAgent資産でカバーする。 21 / 31
22. 自分の外側の仕事も、100%自律で、 高い能力で回るようになる いまは70%、80%かもしれません。それでも半年後、1年後には、自分の外側の仕事も100%自律 で、高い能力で回るようになります。 自分はそのループの内側にいません。Builderは自分のCore Craftを軸にagentを横に多数配置し、 agentチームを経営していく——それが仕事になります。 22 / 31
23. tonight 自己計測の方法 # agentの呼び出し回数 grep -ho '"subagent_type":"[^"]*"' ~/.claude/projects/*/*.jsonl | sort | uniq -c | sort -rn # skillの呼び出し回数 grep -ho '"skill":"[^"]*"' ~/.claude/projects/*/*.jsonl | sort | uniq -c | sort -rn TIPS: transcriptは ~/.claude/projects/*/*.jsonl に全部残っている——grep 2行で自分のログを計測できる 作った数と呼んだ数を並べると、自分の墓場が見えます 編成は設計ではなく逆算で決まる。計測してから消す・育てる 23 / 31
24. recruiting プロダクトデザイナーを募集しています 今回のスライドに興味を持った方、ぜひお待ちしています！ Studyplusアプリ LP 少人数のデザイン組織で、学習を支えるプロダクト群を横断するポジション デザインも実装もAIも使う「横に広い」働き方——今日お見せした通りです 詳細は採用資料へ。今日この後、会場で声をかけてください 24 / 31
25. thank you Subagentsを使って自分を拡張していこう
26. appendix Appendix（Q&A用データ） A 26 / 31
27. appendix 1 subagent frontmatter 全フィールド フィールド 用途 name / description 識別子 / 委譲判定の材料（親モデルが読む） tools / disallowedTools 許可ツールの限定 / 禁止ツール（read-only化など） model / effort agent別のモデル指定 / 思考強度指定 memory 永続メモリ（user / project / local） 。注入は先頭200行または25KBの先着 skills プリロードするskill isolation 実行環境の隔離（worktree等） background / maxTurns バックグラウンド実行 / ターン上限 color UI表示色 配置スコープは project / user / plugin / session の4種 plugin agentでは hooks / mcpServers / permissionMode が無効（公式doc確認済） 同名定義は project > user で解決される 27 / 31
28. appendix 2 実運用の見分け方4指標（国内外事例） 指標 事例 「3ヶ月後」の追記記事がある yamato_snow（Zenn）: Skill 21本・Plan/Explore/実装の3役分離を長期運用 出力物が数値化されている CyberAgent WinTicket: 非エンジニア24名の研修後1ヶ月でPR 13件超 失敗・制約・注意が書いてある スパイダープラス: 「AI出力は実機確認と必ず突合」 使い分け基準まで定義している GMO: 「Agent Teamsは現状60〜70%品質」とチーム判断基準を明文化 逆指標: エージェント数の能書きだけで出力物がない記事 海外の規模感: Salesforce 全社展開でPR merged/dev +79%、231人日の移行を13日 / Rakuten 新機能デリバリー24→5業務日 28 / 31
29. appendix 3 multi-agent研究タイムライン詳細 日付 出来事 2025-06-12 Cognition「Don't Build Multi-Agents」: 並列の独立意思決定は一貫性を壊す 2025-06-13 Anthropic multi-agent research system: single Opus 4比+90.2%・トークン15倍。有効条件は「並列探索でコンテキス トを超えるbreadth-first問題」 2026-02 Anthropic「C compiler with parallel Claudes」: 16体並列・約2,000セッション・10万行Rust / Opus 4.6: BrowseComp 86.8%（multi-agent harness条件。eval汚染論争あり） 2026-03-19 Cognition「Devin can now Manage Devins」 （実装による転向） 2026-04-04 等トークン予算研究（Tran & Kiela）: 等予算ではsingleが匹敵〜上回る。根拠はData Processing Inequality 2026-04-08 BEI（Texas A&M）: 共有事前学習が誤りの隠れ相関を生む。異アーキテクチャ検証の根拠 2026-05-28 Dynamic Workflows: コードが最大1,000体をオーケストレーション（Opus 4.8と同時発表） 2026-06 Claude Fable 5公式ガイド: 並列subagent積極化・独立検証subagent推奨・harness世代棚卸し 29 / 31
30. appendix 4 チームサイズ・命名の組織科学 3〜7体の収束: Wheelan(2009)メタ分析は3〜8人が生産性最良 / AutoGen等のmulti-agent実験では3〜5体の安定構成が報告 / Anthropic 2026 Agentic Coding Trends Reportは「multi-agentはagent支援開発タスクの95%で不要」 「subagent-heavyは single-threadの約7倍トークン」 協調コスト: ペア間リンクはN(N-1)/2で二次関数的に増加（N=5で10、N=8で28、N=12で66） 命名の効果（TMS、Wegner 1987）: チームは「誰が何を知っているか」の地図で機能する。職能名=検索精度、固有名=記憶定着。目 的が違うため併用が合理的 人間研究→AI転用の限界: AIに「やる気低下」はなく定量値の直接転用は飛躍 / agentの専門性は設計時点で固定されるため、棚卸し （periodic redesign）が人間チーム以上に必要 30 / 31
31. appendix 5 出典一覧 Builder言説 Cherny（Lenny's Podcast 2026-02-19 / Fortune 2026-06-08）/ LinkedIn APB制度化（Lenny's Newsletter）/ Figma「State of the Designer 2026」 公式doc Anthropic Subagents・Agent Teams doc / Claude Fable 5 prompting guide（2026-06）/ Dynamic Workflows（2026-05-28） 研究 PRISM arXiv:2603.18507（2026-03）/ 等トークン arXiv:2604.02460（2026-04）/ BEI arXiv:2604.07650（2026-04）/ EMNLP 2024ペルソナ研究 arXiv:2311.10054 / MAR arXiv:2512.20845（degeneration of thought）/ METR開発者研究 arXiv:2507.09089 （2025-07）/ multi-agentトークン実測 arXiv:2510.26585（ICLR 2026）/ Perspectra arXiv:2509.20553（CHI 2026） 論争 Cognition「Don't Build Multi-Agents」 （2025-06-12） ・ 「Devin can now Manage Devins」 （2026-03-19）/ Anthropic multi-agent research system（2025-06-13） 組織科学 Wegner TMS（1987）/ Wheelan（2009）/ Wu et al. AutoGen（2023） 事例 yamato_snow（Zenn）/ GMO / スパイダープラス / CyberAgent WinTicket / Salesforce / Rakuten 一次データ 自宅Mac・本業Macそれぞれの30日transcript集計（2026-06） 。Data 1〜3の表とagent数値は自宅Mac側、本業MacはSkill中心（slack- watch 17 / sync-claude 15） 。 「+35%」は自宅環境での実測 31 / 31