AIエージェントに「シーケンス図を書いて」と頼むと、たいていMermaidコードが返ってきます。
それはそれで正しいんですが、そのコードをそのままクライアントにメールしても、相手がレンダラを持っていなければ図として届きません。
GitHubやNotionの上ならレンダリングされますが、メール添付のテキストファイルとして受け取った相手にとってはただの文字列です。
draw.ioファイルを送ったときも似たような経験があるんじゃないでしょうか。
「このファイル、どうやって開くんですか？」と返信が来て、インストール手順を説明するところから始まった、あのやつです。
archifyはこの摩擦を一点に絞って解決します。
エージェントが生成した図を、相手に何もインストールさせずに届ける、それだけです。
「図を渡す」ではなく「図を開いてもらう」――archify が解く問題
archifyの内部フローはシンプルです。
自然言語の要件かMermaidの構文をインプットとして受け取り、まず typed JSON IR（型付きの中間仕様）に変換します。
この中間仕様には検証ステップが入っていて、ノードの参照切れや不整合を機械的にはじきます。
その後、検証済みのJSONから自己完結したHTMLを出力します。
「自己完結」というのは、外部CDNや追加ランタイムへの依存がゼロということです。
生成されたHTMLファイル1枚をどこかのフォルダに置いて、ブラウザで開けば図が表示されます。
インラインSVGとアニメーション、PNG/SVG/WebMのエクスポート機能、ダーク/ライトテーマの切り替えが全部そのファイルの中に入っています。
ここが、Mermaidコードをそのまま渡す場合との決定的な違いです。
Mermaidはコードを渡します。
archifyはHTMLを渡します。
コードを図として見せるためのレンダラを、archifyは配布物の中に梱包しています。
「開けない」をファイルの構造レベルで防いでいます。
typed JSON IRを経由する設計には、もう一つ意味があります。
エージェントが自然言語からいきなりSVGを生成しようとすると、出力が毎回少しずつブレます。
中間仕様を型で固定して検証を挟むことで、エージェントの出力ゆらぎをある程度吸収できます。
「生成したけど壊れた図が出てきた」という事故を減らす仕組みが最初から入っているわけです。
インストールから最初の HTML 図生成まで
インストールは1コマンドです。
npx skills add tt-a1i/archify -g
Cursor環境で明示的にインストールしたい場合、非インタラクティブなオプションが用意されています。
npx -y skills add tt-a1i/archify --skill archify --agent cursor --global --copy --yes
インストール前にとりあえず動きを確認したい場合は、次のコマンドでインストールなしに試せます。
npx skills use tt-a1i/archify@archify --agent codex
archifyはRaven、Cursor、Claude Code、Codex CLI、OpenCodeで動作します。
エージェント環境さえあれば、あとはプロンプト一発でHTMLが出てきます。
エージェントへのプロンプトはこんな形です。
archify スキルを使って、ユーザー認証のシーケンス図を生成してください。
ステップは「ログイン要求 → 認証サーバー検証 → JWTトークン発行 → クライアント保存」の流れで。
エージェントがJSON仕様を生成したあと、deliverコマンドでHTMLを出力します。
ローカルで確認しながらすぐ開きたいときは、--openオプションを付けます。
archify deliver spec.json --open
deliverと似た用途でpreviewというコマンドもあります。
deliverは「JSON → HTML」のワンショット変換です。
previewはJSONファイルの変更を監視しながら、ブラウザで逐次確認するオーサリングモードで、127.0.0.1のランダムポートにバインドしCtrl-Cで止まります。
図を作り込む段階ではpreview、確認が取れたらdeliverで最終HTMLを生成する、という使い分けになります。
生成されたHTMLを開くと、アニメーション付きで処理フローを順番に追えます。
エクスポートボタンからPNG、SVG、WebMのいずれかで書き出せるので、議事録に貼る用のPNGとプレゼンで使うアニメーション付きHTMLを同じファイルから出せます。
地味ですが、これは実際の納品フローでかなり楽になります。
Mermaid・draw.io と archify――「誰に渡すか・その後どう扱うか」で選ぶ
三つを比べるとき、「どの図が綺麗か」ではなく 配布単位と用途の前提 で考えると使い分けがはっきりします。
Mermaidとarchifyの差は配布単位にあります。
Mermaidが渡すのはコードです。
GitHubのREADMEやNotionのページ上ではレンダリングされますが、それはビューワー側がMermaid対応しているからで、相手の環境に依存しています。
archifyが渡すのはHTMLです。
ブラウザさえあれば開けます。
「相手の環境に何が入っているか」を気にしなくていい点が最大の差です。
draw.ioとarchifyの差は用途の前提にあります。
draw.ioはノードを動かしてレイアウトを整えて、チームで編集・保守することを前提にしています。
archifyはスナップショットです。
編集機能はなく、閲覧と共有に特化しています。
「あとで誰かが図を手直しするかもしれない」ならdraw.io、「この時点の設計をそのまま渡したい」ならarchifyという切り分けです。
三者の使い分けを「誰に渡すか・その後どう扱うか」でまとめるとこうなります。
Mermaidはエンジニア同士でGit管理・コードレビューするときに向いていて、相手の環境がMermaid対応していることが前提です。
draw.ioは設計書として継続的に保守する場合に向いていて、相手がdraw.ioを開ける環境を持っていることが前提です。
archifyはエンジニア以外も含む相手にこの時点の図を届けるときに向いていて、ブラウザだけが前提です。
実務では「Mermaidをソース管理・archifyを納品用レンダリング」という組み合わせが自然に収まります。
ソースとしてのMermaidはリポジトリで差分管理できます。
納品物としてのarchify HTMLは、相手の環境を選びません。
どちらを使うかではなく、フローの中でどう役割分担するかで考えると、迷いが減ります。
クライアント納品・社内レビューで archify が効く具体シーン
シーン①：要件定義後のシーケンス図をクライアントにメール添付する
エージェントで生成したMermaidコードをそのまま貼り付けたテキストファイルを添付しても、非エンジニアのクライアントには「何これ？」になります。
PNGで書き出せば開けますが、図の説明文が小さくなったり、処理の流れを追いにくくなったりします。
archifyのHTMLならブラウザで開くだけです。
アニメーションで処理フローをステップごとに追えるので、クライアントが設計の流れを「読む」のではなく「見る」ことができます。
「インストールしてください」という前置きが要らなくなるのは、地味ですが確実に相手へのハードルを下げます。
シーン②：Slack でファイル共有してレビューしてもらう
Slackにdraw.ioファイルを貼ると、それを開くためにdraw.ioアプリが必要です。
「インストールしてない」「会社のPCに入れられない」というメンバーが一人でもいると、レビューが止まります。
archifyのHTMLはSlackにアップロードして、ダウンロードしてブラウザで開くだけです。
アプリも、アカウントも、プラグインも要りません。
「ちょっと確認してもらえる？」の温度感でファイルを投げて、相手がすぐ開けます。
この「すぐ開ける」という体験の差が、レビューサイクルのテンポに直結します。
シーン③：社内レビュー時にプロジェクタで見せる
設計レビューで図をプロジェクタに映すとき、静止した図を口頭で説明するよりも、アニメーションで処理フローを順番に追えた方が伝わります。
「このリクエストがここに届いて、次にここへ流れて…」という説明をビジュアルが補完してくれます。
レビュー中に「この図をそのまま議事録に貼りたい」となったときも、その場でPNGにエクスポートすれば済みます。
レビュー用のHTMLと議事録用の画像を別々に準備する手間がなくなります。
会議の場でエクスポートしてそのまま貼り付けられるのは、実際の現場ではわりと大きいです。
現時点での限界と、それでも archify を選ぶ判断軸
正直なところ、archifyには向いていないケースがあります。
- 編集・差分管理が必要なとき：生成されるHTMLはスナップショットであり、編集機能はありません。図を更新するたびにエージェントで再生成することになります。Gitで差分管理したいなら、JSON IRかMermaidのソースを別途保持しておく必要があります。
- ノード数が多い大規模な図：複雑な依存関係や多数のコンポーネントを一枚に詰め込むと、自動レイアウトが破綻しやすくなります。手動でレイアウトを調整できるdraw.ioの方が現実的な場面もあります。
- エージェント環境がないとき：archifyはエージェントスキルとして動作します。Cursor、Claude Code、Codex CLIといったエージェント環境が前提で、スタンドアロンのCLIとして単独で使うものではありません。
これらを踏まえた上で、「Mermaidをソース・archifyを納品物」という分業が今のところ一番しっくりきています。
ソースとしてのMermaidはリポジトリで管理できて、差分もとれます。
納品物としてのarchify HTMLは、相手の環境を選びません。
この役割分担を決めておけば、「この図どうやって渡せばいいんだっけ？」という判断を毎回しなくて済みます。
自分のプロジェクトに当てはめるなら、まず「この図を最終的に誰に渡すか」を確認します。
エンジニア同士でGitHub上でやりとりするだけならMermaidで十分です。
非エンジニアへの確認が一つでもあるなら、archifyを挟む価値があります。
「届いてから開いてもらえるか」に摩擦があるうちは、archifyを使う理由があります。
株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援・DX推進に取り組んでいます。
AIエージェントを使った開発フローの整備や、社内外へのドキュメント共有の仕組みづくりについてもご相談いただけます。
お問い合わせはこちら からどうぞ。