一行の指示で仕組みを「動く機械の図」にするAnatomy

README やブログに仕組みの説明図を入れようとして、結局「サーバー」「DB」とラベルを書いた四角を矢印でつないだだけの絵になった経験はないだろうか。自分で描くと、どうしても手数の少ない形に落ち着いてしまう。

2026年10月10日、開発者のRyan氏が公開したエージェントスキル「Anatomy」は、この悩みに一行の指示で応える。公式サイトによれば、Claude Codeなどのコーディングエージェントに対象を伝えるだけで、数十から百以上の部品で組まれた「機械」として仕組みを描き、しかも部品は実際に動く。ラベル付きの箱ではなく、歯車や歯車箱のような実在感のある形を自動で発明する。問題は、具体的にどうやってその形にたどり着き、動く数値が見せかけで終わっていないかだ。

一行の指示で機械の図に

まず、手元で試すのに何がいるのか。導入はnpx skills add wheresryan22/anatomy -g -a claude-codeの1行で済む。公式GitHubリポジトリのREADMEによれば、対応エージェントはClaude Codeが主体で、CodexとOpenCodeでも動く。完成した図をコミュニティギャラリーへ投稿する際は、Antigravityで作った図も受け付ける。料金はかからない。スキル本体はMITライセンスのオープンソースで、生成した図自体の利用条件もMITになる。

使うときは/anatomy explain how a mechanical watch keeps time, interactiveのように、説明したい対象と形式を一文で渡す。interactiveを付ければ操作に反応する図になり、WebGLを足せば炎や水のような表現も扱える。3Dは部品を回転させられるが、READMEは今もベータ版だと明記している。

出力形式も1種類ではない。フレームワークを使わないTypeScript/JavaScriptでSVGや単独で開けるHTMLを書き出す方式と、Next.jsなどのサイトに組み込めるReactコンポーネントの方式がある。Reactコンポーネントではダーク・ライトに加えて紙・設計図・セピア調まで、5種類のテーマを切り替えられる。公開からわずか2日後の10月12日にはv1.1が出て、コミュニティギャラリーへの投稿機能に加え、Claude Codeのセッションログから制作時間とトークン数を自動で読み取る機能が加わった。1週間足らずで更新が続くほど、開発のペースは早い。

この最初の答えだけでは、「結局はきれいなイラストが出てくるだけでは」という疑問が残る。Anatomyの売りは見た目ではなく、その図がどうやって「箱と矢印」を避けているかにある。

四角と矢印を禁じる理由

SKILL.mdを読んでいて、自分は一度手を止めた。このスキルが避けるべき「失敗パターン」として名指ししているのが、ラベル付きの箱や浮いた板、そして線が数本あるだけの平坦な絵だったからだ。当サイトが図の方針で禁じている「同じ大きさの箱を並べて矢印でつなぐ図」と、ほぼ同じ内容を、外部のツールの設計思想が独立に言い当てていた。

SKILL.mdが名指しする失敗パターンは2つある。

• 抽象的すぎる図: ラベルを書いた箱や、宙に浮いた板を並べただけのもの
• 平坦すぎる図: 大きな板に線が数本あるだけのもの

これを避けるため、SKILL.mdは最低40点の部品リストをベース・構造・機構・操作部・主題に分けて書き出すよう求め、どの部品も必ず別の部品の上に載せる構造にする。

掲げる原則は”The object is the explanation.”(物体そのものが説明になる)。抽象的な概念に対して、実在する機械を1つ発明する。作例には、トークンバケット型のレートリミッタや、LRUキャッシュを本棚の抜き差しで表した図がある。棚から本が押し出される位置や速さが、そのままキャッシュの入れ替わりを表す。

機械に見立てる発想はわかった。では、その機械が見せる数値や動きは、説明を分かりやすくするための演出なのか、それとも本当に仕組みを計算した結果なのか。

動きの数字は本物か

SKILL.mdはここを”Truth first.”と呼ぶ。表示される読み取り値・動き・キャプションは、1つの純粋なモデルモジュールから駆動させる決まりになっている。レートリミッタの図なら、バケットの残量を示す数字と、実際にバケットが満ちていく速さは、見た目のために別々に描かれた値ではなく、同じ計算から出ている。

ここが今回いちばん腑に落ちた点だ。数字が本物かどうかは、図を眺めただけでは分からない。Anatomyはそれを検証手順で担保している。scripts/capture.mjsが、デスクトップ表示・幅390pxの携帯表示・ホバー時・動きの途中といった複数の瞬間をスクリーンショットに撮る。scripts/drive.mjsは、連続した操作や分解した姿勢、WebGLを切った状態まで確認する。そのうえでnode build.mjs --auditが「失敗0件」で終わることを求め、部品の線の端点をチェックするscripts/lines.mjsも「line ends: 0」を要求する。

ここまでは機械的なチェックだが、その先に人の目による確認が残る。4倍まで拡大し、ライトとダークの両テーマで、組み立てた状態と分解した状態の両方で、すべての接合部を確認する。最後は生成されたPNGを1枚ずつ、批評家の目で見返す工程まである。

つまり、動いている部品の数値は後付けの演出ではなく、同じモデルが数値・動き・説明文のすべてを決めている。見た目の密度と正確さを両立させているのは、この検証の手間のほうだ。

では、この手間は自分の環境でどれくらいの時間になるのか。

規模ごとの時間の目安

SKILL.mdは図の規模を3段階に分け、部品数と所要時間、作業前の確認の要不要を定めている。

この表から、ちょっとした仕組みの説明ならFigure規模で1時間以内に収まり、気軽に試せることが分かる。規模が大きいEpicは、スキル側が自動では作らず、縮小した代案を返す安全装置になっている。

必要な環境はREADMEによれば、Node.js 20.10以降とChromeまたはChromiumのみ。npm installもAPIキーも要らない。表示にWebGLを使う表現ではシェーダーが必要になるが、WebGLがない環境でもSVG自体は表示され、画面の動きを抑える設定では静止した状態で見える。

向かない場面もある

向く場面が分かったところで、向かない場面も押さえておきたい。READMEが明記している制限は、主に次の3点だ。

• 3Dモードはベータ版。READMEは「作例と1件のテスト図でのみ実証済みで、本番の図ではまだ」としている。実測では、380部品規模の手の3D図が、1440px幅のデスクトップで約20fps、処理能力を絞ったモバイル相当の設定では13〜15fpsまで落ちた
• グラフ作成ライブラリではない。軸やデータ系列を伴う量の比較には向かない
• 描けるのは機械・計測器・道具・家具などに限られる。人物や正確な地図は対象外

動きが多い大規模な3D図を使う記事ではこの速度を見込む必要があり、量を比べたいグラフには、このスキルではなく通常のグラフ作成の手段を使うことになる。

まとめ

Anatomyは、Claude Codeなどへの一行の指示で、仕組みを実在感のある機械として描き、しかも表示する数値や動きを1つの計算モデルから生成するエージェントスキルだ。無料で、Node.jsとChrome/Chromiumさえあれば今日から試せる。Figure規模(部品40〜80)なら1時間以内で形になり、仕組みの説明図を「箱と矢印」で済ませてきた作業を置き換えられる。一方で、3Dモードはまだベータで大規模図は速度が落ち、グラフや人物・地図の表現には向かない。公式の作例集を見てから、自分の手元で試す対象を決めるとよい。