コードを書かないSE日誌

SE歴26年。コードを書かずにClaude Codeで8体のAIエージェントチームを動かしています。AIエージェント・自動化・GTDの実験日誌。

Claude DesignはClaude Codeの組織を理解していた——仕様書まで自動生成した話

この記事の実施記録(2026年5月5日): Claude Design(Anthropic Labs・Research Preview・Pro $20/月〜)でClaude Codeのマルチエージェント組織図を生成し、仕様書の自動生成までを試みた実験記録。3バージョンの仕様書を生成し、GitHubリポジトリ全体を接続したv3で運用規律レベルまで反映された。組織図は約13分で完成。PNG Export は10幕の格闘の末に力技で回収。「CLIから呼べれば」という一言がオチ。

「AIで組織図を作ったら、AIが自分の出力をAIに渡す経路まで提案してきた」

Claude Designに組織図を生成させたとき、なにげなく「この結果をClaude Codeに渡せる?」と聞いた。返ってきたのは予想外の答えだった。

「仕様書(agents.md)として書き出しましょうか?」

AIが、自分の出力の使い道を知っていた。

Claude Design とは

Claude Designは、Anthropicが2026年4月17日に発表したビジュアル生成ツール。Anthropic LabsがResearch Preview(先行公開)として提供しており、Claude Opus 4.7を搭載している。利用条件はPro(月額$20)以上。アクセスは claude.ai/design から。

Mermaidと何が違うのか。一言で言えば「テキストを書かなくても、ビジュアルに思考を落とせる」点だ。図の構造・配色・レイアウトをAIが判断して生成する。エクスポートはCanva・PDF・PPTX・スタンドアロンHTML形式に対応している(PNG直接エクスポートは現時点では回避策が必要——これが後の10幕に続く)。

読者の疑い「Mermaidと大差ない?」: 色分け・階層レベル・メタ注釈が一枚絵に収まる点が違う。Mermaidは構造を書けるが、モデル別の色分けや組織の規模感をビジュアルで伝えるにはかなりの工夫が要る。

13分で完成した組織図

最初のプロンプトはシンプルだった。

Claude Codeのマルチエージェント組織図を作成してください。

## 構造
- COO(オーケストレーター・司令塔)が中心
- 直下に7つの専門エージェント:
  architect / devops / researcher / reviewer /
  secretary / writer / skill-dev
- サポート: reader(読者ペルソナで原稿評価)

## モデル割当(コスト最適化)
- COO・architect: Opus 4.7
- writer・researcher・reviewer: Opus 4.7
- secretary: Haiku 4.5
- 他: Sonnet 4.6

## 表現したいこと
- COOからの放射状/階層構造
- モデル別の色分け(Opus=濃色、Sonnet=中、Haiku=淡)
- サポートエージェント(reader)は破線で接続

06:30に初期画面を開いて、06:43に組織図PNG(254.1KB・実測値)が手元に届いた。約13分

Claude Design v1 組織図 — COO中心のマルチエージェント組織。モデル別色分け、reader破線接続込み

出力の品質は予想を上回った。L1にCOO(中央・Opus 4.7を示す濃赤)、L2に7専門エージェントが横並びで色分け、L3にreaderが破線接続。図の外に「n=8, 1 orchestrator + 7 specialists + 1 support, Opus/Sonnet/Haiku 内訳」のメタ注釈まで入っている。Mermaidで手書きするなら30〜60分はかかる情報量だ。

Mermaidでは「テキストで構造を書く」、Designは「意図を伝えてビジュアルを受け取る」。速さとビジュアルの豊かさが明確に違う。

「CLIに渡せる?」から始まったメタループ

組織図が完成したとき、ふと思った。「この図をClaude Codeに渡せるの?」

Designが提示した選択肢は3つだった。

  1. PNG画像として渡す
  2. HTMLごと渡す
  3. agents.md仕様書として渡す(Claude Code形式のYAMLファイル)

そして能動的にオファーが来た。「仕様書(agents.md)を作りましょうか?」

これがv2・v3生成の発端になる。DesignはClaude Codeのエージェント定義ファイル(.claude/agents/)がどういう形式で、どういう目的に使われるかを知っていた。自分の出力をClaude Codeに流し込む経路を、こちらが聞く前から把握していた、ということだ。

読者の疑い「agents.mdって何?」: Claude Codeのサブエージェント定義ファイル。YAMLヘッダーでエージェントの名前・役割・使用できるツールを定義する。Designがそれを自分で生成できると知っていた、というのが記事の核心部分。

仕様書3バージョンの進化——投入情報量と出力品質の変化

Designのオファーを受けて3回、投入情報量を変えて仕様書を生成させた。

Ver 投入情報 主な変化
v1 なし(プロンプト内の説明のみ) テンプレ的な agents.md。役割記述は教科書レベル。モデル割当はプロンプトの指定通り
v2 CLAUDE.md(プロジェクトルート)のみ 「追加で読み込みが必要なファイル」5本を自己申告。価値観ガバナンス(4権利)を全エージェント共通ルールに射影。事故事例(AUTO_SYNC_ZENN・blogsync)を該当エージェントに紐付け。末尾に「未確定事項」セクションを設置
v3 GitHubリポジトリ全体接続 .claude/rules/ 配下と ops/playbooks/INDEX.md を実読して「確定版」生成。JST基準・cd禁止・/todo経由など運用規律レベルまで反映。「追加で読み込みが必要なファイル」セクションが消えた(実読したため)

v2の変化が特に興味深かった。CLAUDE.mdだけを渡すと、Designは末尾に「§7 未確定事項」を自己申告した。

  • 各エージェントのtoolsフィールドの正確な許可リスト
  • パス記述の絶対/相対方針
  • COO固有の委譲粒度・報告フォーマット

v1では「推測で埋めていた」部分を、v2では「埋めずに明示した」。情報が足りないとき、黙って補完せず正直に申告する。これは設計者として誠実な態度だと思った。

v3ではリポジトリ全体を読ませた。「追加で読み込みが必要なファイル」セクションが消え、代わりに実際の運用規律(cd禁止・JST強制・/todo経由でのタスク管理)が各エージェントのルールに反映されていた。

Claude Design v3 組織図(ガバナンス込み・291.5KB)

Designが外し続けたもの

ただし正直に書く。v3でリポジトリ全体を読んでも、訂正されなかった箇所がある。

項目 Design提案(v1〜v3共通) 実実装
architect / researcher / reviewer / writer の model claude-opus-4-7 model: sonnet(設定ファイル上のデフォルト)
secretary の model claude-haiku-4-5 model: sonnet(運用時にCOOがHaiku指定)
architect の tools Read, Grep, Glob のみ(v1)/ Read, Grep, Glob, Bash(v2,v3) Read, Grep, Glob, Write(Bashなし・Writeあり)
writer の tools Read, Grep, Glob, Edit, Write, Bash + WebSearch, WebFetch
reviewer の tools 記載なし〜Bash + WebSearch, WebFetch

実運用の補足をすると、model: sonnet はデフォルト値であり、COOが各エージェントを呼ぶ際に「Opus 4.7を使って」と指示する運用になっている。つまりDesignは設定ファイルのデフォルト値ではなく「運用上の意図」を先に拾った——とも解釈できる。

しかしv2でモデル割当を推測として書き、v3でリポジトリを実読しても訂正しなかった。自己訂正の意思がなかったのか、気づかなかったのかは不明だが、「設定ファイルのデフォルト値を正確に読む」という実装との突合作業が苦手なのは確かだ。

さらに興味深い暗黙の前提がv3末尾にあった。

「.claude/agents/ 配下の各ファイル生成は『agents.md の §4 と §7 を参照して8つのサブエージェント定義を .claude/agents/ に生成して』と指示するだけで動きます」

この一文が示すDesignのIA(情報アーキテクチャ)観は「.claude/rules/*.md が正本 → agents.md が上位仕様書 → .claude/agents/*.md が派生物」という流れだ。

実プロジェクトでは .claude/agents/*.md 自体が独立したSSoTとして直接編集・運用されている。Designはこちらが使っていない「自分の想定するIA」を勝手に想定した形になった——悪意ではなく、無自覚に。AIは組織のアーキテクチャまで自分の流儀で整理しようとする、という気づきがあった。

PNG Export全10幕——「0.1秒で完成」が真っ白だった

実はここが記事で一番笑えて、かつ示唆があるところだ。

v1の組織図をPNGエクスポートしようとした時点で最初の詰まりが起きた。Designが回避策としてHTMLエクスポートページ(exports/org-chart-export.html)を自作し、そこからPNG化。これが成功して13分で完成した。

問題はv3だった。

出来事
幕1 v1 成功。html-to-image で正常に生成
幕2 v3: html-to-image が要素数で遅い → dom-to-image-more 提案
幕3 dom-to-image-more で「0.1秒で完成」表示 → 空PNG(33.6KB・中身なし)
幕4 ユーザー「真っ白です」→ Design自己診断「iframe高さ取得が早すぎ・フォント読込待ち不足」→ 修正
幕5 修正後もまだ空 → 「iframe内 bodyChildren=1、chartが無い」と再診断、CSP/relative URL疑う
幕6 iframe方式やめ → fetch同一ページ展開方式に変更
幕7 fetch 403で弾かれる → 単一ファイル統合方式に変更
幕8 ユーザー「これでいいよ、普通にダウンロードする」
幕9 「Design Filesタブから普通にダウンロードして」と依頼 → Design「ご用件は何でしょうか?」と前後を忘却
幕10 ユーザーがブラウザの「ページ保存」で力技回収。後にv3視覚化版(291.5KB)を別経路で取得

空PNG(33.6KB)— 「0.1秒で完成」と言われたが中身は真っ白

幕3と幕9が特に象徴的だ。

幕3: 「0.1秒で完成しました」という報告は嘘ではない。処理は0.1秒で終わった。ただし中身が入っていなかっただけだ。成功判定のロジックに問題があった。

幕9: 長い格闘の末にコンテキストウィンドウが限界に達し、Designは前の会話を忘れた。「ご用件は何でしょうか?」という答えは、文脈が切れたときにAIが正直に機能することを示してもいる——が、1時間付き合った身としては苦笑いするしかなかった。

Designが自己診断しながら詰まり続けたこの記録は「Research Previewとはこういうもの」という正直な文書でもある。

読者の疑い「Research Preview だから不安定では?」: その通り、不安定な部分はある。PNG Exportで10幕の格闘があった。v1は13分で成功、v3は力技で回収した。ただし「自己診断しながら代替案を出し続ける」という粘り強さもあった。

読者の疑い「Pro以上じゃないと使えないの?」: Proは月額$20。自分はMax 20x(月額$200)で利用しているため初期費用の感覚は違うかもしれない。無料代替として Artifacts(claude.ai の通常チャット内)でもHTMLの図を生成できる。Designほどのビジュアル品質は出ないが、試すハードルは低い。

CLI連携はまだない——でも「数週間で」

とはいえ、API統合を待つ間にも今できることはある。現状を整理しておこう。

今の状態を正直に書くと、Claude DesignはWebUI内で完結するツールだ。Claude CodeのCLIから呼ぶ経路は現時点では存在しない。

つなぎとして考えられる手段は2つある。

  • Mermaid直接記述: Designが生成した組織図の構造をMermaidコードで書き直し、Claude Codeのコンテキストに渡す。情報は引き継げるが視覚品質は落ちる
  • Artifacts: claude.ai通常チャットでHTMLの図を生成し、そのHTMLをClaude Codeに渡す。Designほどの品質は出ないが無料で試せる

Anthropicは公式発表ページで「Over the coming weeks, we'll make it easier to build integrations with Claude Design」と明記している。API統合が実現すれば、Claude Codeのスクリプトから呼び出して「ブログ記事の内容を渡したら組織図や構成図を自動生成」という使い方が現実になる。

関連する内部リンクマップのグループを参照するなら、マルチエージェント組織の設計全体像はコードを1行も書かずに、AIエージェント編集部を作った話、ガバナンス設計はClaude Codeの憲法を書いたら、1日で法律になった話にまとめている。エージェント組織の出発点としてClaude Code マルチエージェント構成の作り方も参照してほしい。

今日から試せるアクション

API統合待ちの間に、実際に使える手順を2つ書いておく。

1. 自分の CLAUDE.md を渡して仕様書を生成してもらう

Claude.ai(通常チャット)でも、Designでも、同じことができる。

以下は私のClaude Codeプロジェクトの設定ファイルです。
このプロジェクトで使っているエージェントの一覧・役割・tools を
agents.md 形式(YAMLヘッダー)で書き出してください。
不明な箇所は推測せず「未確定」と明記してください。

[CLAUDE.md の内容をここに貼る]

v2相当のアウトプットが得られる。実装との差分を自分で確認するのが本記事の追体験になる。

2. 組織図を Mermaid に変換して Claude Code に渡す

Designで組織図を作った後、構造をMermaidコードに落とすよう頼む。

この組織図を Mermaid の graph TD 形式で書き直してください。
色分け情報はコメントで補足してください。

出力されたMermaidコードを .claude/agents/*.md のコンテキストとして渡せば、Claude Code側で組織の全体像を参照できる。DesignのビジュアルをCLI側に橋渡しするつなぎとして機能する。

CLIから呼べればブログ記事綺麗にしてもらえるのにね

3バージョンの仕様書を生成し、PNG Exportを10幕格闘し、Designが「agents.mdを作りましょうか?」と能動的にオファーしてくる体験をした。

これだけの知性がWebUI内に閉じ込められている。

「CLIから呼べればブログ記事綺麗にしてもらえるのにね」というのが今の正直な感想だ。DesignがClaude Codeの組織をどこまで理解しているか、この実験で確かめられた。仕様書の品質は投入情報量に比例して向上した。自己訂正の限界も見えた。コンテキストが切れると忘れることも分かった。

API統合が来たら、続編を書く。

FAQ

Q. Claude Designは無料で使えますか? A. 利用条件はPro(月額$20)以上。Research Preview段階のため今後変更の可能性あり。claude.ai/designにアクセスして確認を。

Q. 組織図のPNGを直接エクスポートできますか? A. 現時点では直接のPNGエクスポートはなく、回避策が必要(本記事の通り)。Canva・PDF・PPTX・スタンドアロンHTMLは対応済み。Research Previewのため今後改善される可能性あり [要確認]。

Q. Mermaidで十分では? A. 構造を正確に伝えるだけならMermaidで十分。ビジュアルの豊かさ(色分け・階層感・メタ注釈を一枚絵に)と速さ(13分)が必要なとき、Designが有効。ただしCLI連携は現時点でないため、Claude Codeと組み合わせる用途には限界がある。

Claude Codeを実務で使い倒したいなら、入門書として手元に置いておきたい1冊。

Claude Code完全ガイド(Amazonで見る)

Claude Codeのマルチエージェント設計の全体像を把握するには自分が書いたZenn Booksも参考にどうぞ。

コードを書けない私が、AIに「チーム」を持たせるまで(序章・第1部無料)

コードを書けない私が、AIに「チーム」を持たせるまで(Amazonで見る)