AIに開発計画を頼むと、長い文章は出てくるのに、画面の姿や処理の分岐が見えにくい。blueprint4llmは、その確認を助ける新しいCLIツールです。Markdownに書いた処理図や画面案を、ブラウザーで読めるHTMLなどへ変換します。今回は日本語の問い合わせ受付を題材に、公開済みのnpm版をMacで試しました。
blueprint4llmは、用意された設計文書を描画するツールです。CLIでの変換にLLMやAPIキーは使いません。一方、AIに原稿を書かせる場合は、そのAIの料金・送信先・取り扱い条件が別に適用されます。画面案を描けても、送信処理や認証が実装されるわけではありません。
確認日：2026年10月23日。npmの配布記録では、試用した0.16.1は10月22日13:16:42 UTC、日本時間22:16:42に公開されています。翌日の夕方に検証しました。GitHubにはそれ以前の開発履歴があり、これはプロジェクトの初公開日を断定する記述ではありません。
何を解決する道具なのか
Markdownは、見出しや箇条書きを文字で書ける文書形式です。その中にMermaidの処理図とWiremarkの画面案を書けば、AIは文字として編集でき、人は図として確認できます。blueprint4llmは、この2つの見方を同じ原稿から作るための変換役です。HTMLを別々に手直しし続けるより、Markdownを正本として再生成する運用に向いています。
| 要素 | 役割 | この教材での例 |
|---|---|---|
| Markdown | 目的・条件・未決事項を書く | 問い合わせ受付で何を決めるか |
| Mermaid | 箱と矢印、条件分岐などを書く | 必須項目が不足したら入力へ戻る |
| Wiremark | 画面の部品や配置を書く | 件名・内容・確認ボタンの下書き |
| blueprint4llm | 図を描画し、文書としてまとめる | 同じplan.mdからplan.htmlを生成 |
公式READMEは、設計を自分またはエージェントで書き、実装前にシステムと画面をレビューする使い方を示しています。図を増やせば必ず品質が上がるという意味ではありません。認証、権限、入力エラー、再送などの条件が抜けていないかは、文書を見た人が判断します。
最初に注意：npm版とGitHubのmainは同じ版ではなかった
2026年10月23日の確認では、npmのlatestは0.16.1、GitHubのmainにあるpackage.jsonは0.16.15でした。番号が似ていますが、同じものとして扱えません。本記事の実測はnpmで配布されている0.16.1に固定しました。新しいREADMEに書かれた機能を、そのまま配布版で試した結果と混ぜないためです。
| 確認対象 | 確認した版・条件 | 読み方 |
|---|---|---|
| npmの公開パッケージ | blueprint4llm 0.16.1 | この記事の導入と変換の実測対象 |
| GitHubのmain | package.jsonは0.16.15。確認コミット2557e329870b | 開発中の状態。npmから同じ版を取得できるとは限らない |
| 必要な実行環境 | Node.js 22.13.0以上、npm、Puppeteer用Chrome | LLMを動かすGPUは不要。ブラウザー描画の依存は必要 |
| 利用条件 | コードはMIT License | CLIの利用料は設定されていない。利用するAIや外部サービスの費用は別 |
版と導入要件はnpmの0.16.1、ソース側の状態は固定コミットのpackage.jsonを参照してください。今回はmacOS 27.0・Apple Silicon・Node.js 23.11.0で確認しました。WindowsやLinuxでの動作は実測していません。公式はLinuxでChrome用のシステムライブラリが必要な点も案内しています。
日本語の処理図と画面案を、1つの原稿にする
教材は、実在の顧客情報を含まない架空の問い合わせ受付です。処理の流れと入力画面を同じ文書に置きます。実装前に「入力不足のときはどこへ戻るか」「誰が内容を確認するか」を話し合うための下書きです。
# 問い合わせ受付の設計案
これは架空の教材です。顧客情報や実在の接続先は含みません。
## 処理の流れ
```mermaidflowchart TD A[問い合わせを入力] --> B{必須項目がそろっている?} B -->|いいえ| C[入力画面で不足を表示] C --> A B -->|はい| D[担当者が内容を確認] D --> E[受付番号を発行]```
## 入力画面の案
```wireframeWireframe #request w=480 h=340 Stack column gap=2 padding=2 Typography h4 "問い合わせ受付" TextField "件名（必須）" TextField "問い合わせ内容（必須）" Button "確認へ進む" contained```
## レビューで決めること
- 個人情報をどこまで入力してよいか。- 担当者が不在のときに誰が引き継ぐか。- 二重送信をどこで防ぐか。
画面のボタンは図です。実際の送信機能や入力検証は実装していません。
WiremarkのWireframeは画面の枠、Stack columnは部品の縦並びです。Typographyは文字、TextFieldは入力欄の見た目、Buttonはボタンの見た目を指定します。インデントで内側に置く部品を表現します。日本語ラベルを引用符に入れ、画面名や部品の記法は英語で書いています。Wiremarkの公式説明では、このようにテキストから手描き風の画面案を作る形式として紹介されています。
「必須」と図に書いただけでは、ブラウザーの必須入力チェックやサーバーの検証は追加されません。画面に注意文を置くことと、実際にその制約を守るコードを実装することを分けてレビューしてください。
試す手順：専用フォルダーで版を固定する
Node.jsとnpmが使える端末で、作業用フォルダーを1つ作ります。以下はグローバル環境へコマンドを増やさず、そのフォルダーへ導入する例です。前の教材をplan.mdとして保存してから、チェックとHTML出力を行います。
mkdir blueprint-democd blueprint-demonpm init -ynpm install --save-exact blueprint4llm@0.16.1npx blueprint4llm --versionnpx blueprint4llm plan.md --checknpx blueprint4llm plan.md --out=plan.htmlPuppeteer用のChromeは通常のインストールでダウンロードされます。組織の方針などでインストール時のスクリプトが止められている場合は、管理方針を確認したうえで公式のChrome導入手順へ進みます。検査回避のためにブラウザーのサンドボックスを無効化する設定を、本記事の手順には加えていません。
今回の実測では、依存パッケージを一時フォルダーへ--ignore-scriptsで導入し、PUPPETEER_EXECUTABLE_PATHで端末に入っていたGoogle Chromeを指定しました。上の標準的な導入経路とはChromeの用意の仕方が異なります。既存Chromeを使う方式を、すべての環境で互換性がある方法として保証するものではありません。
npx blueprint4llm plan.md --serve --port=8080公式のライブプレビューは通常127.0.0.1で開き、Markdownや参照するローカル画像の保存に合わせて表示を更新します。本記事で実測したのはチェック・ファイル出力と、その生成HTMLの表示です。ライブ更新やPDF出力の成功を実測した、とはしていません。
実測結果：日本語表示と「失敗してほしい例」を確認
| 確認したこと | 0.16.1での結果 | 分かること・分からないこと |
|---|---|---|
| 正常なplan.mdの--check | 終了コード0、OK表示 | 記法と描画を通せた。設計の正しさの証明ではない |
| Mermaid＋WiremarkからHTML出力 | 成功。日本語ラベルと分岐をブラウザーで目視確認 | 日本語教材を表示できた。全記号・全フォントの互換性は未評価 |
| 閉じ括弧を欠いたMermaidの--check | 終了コード1 | 今回の構文エラーを検出できた |
| 2つの図を含む原稿を1枚のSVGへ出力 | 終了コード1、図が2つある旨を表示 | 画像出力は対応図ブロックがちょうど1つ必要 |
| 図を1つずつに分けたSVG出力 | 処理図・画面案とも成功 | 本文掲載の画面案も、この出力を使用 |
この確認では、変換時間の優劣、トークン消費削減、設計レビューの所要時間短縮は測っていません。AIが原稿を自動生成する部分も評価していません。日本語のラベルは表示できましたが、処理図の長い文字列は自動で折り返されます。見た目だけでなく、矢印の向きと分岐ラベルも確認します。
教材のMarkdownと変換済みHTMLを用意しました。HTMLはこの教材の静的な変換結果です。公開サイトへ入力情報を送るフォームではありません。処理図だけの原稿と画面案だけの原稿も、画像出力を試す際に使えます。
npx blueprint4llm flow.md --out=flow.svg --format=svgnpx blueprint4llm screen.md --out=screen.svg --format=svg業務では、実装する前の確認に使う
| 場面 | AIに用意させるもの | 人が確認する点 |
|---|---|---|
| 社内申請フォームの追加 | 入力画面案と、差し戻しを含む処理図 | 入力項目、承認者、必須条件、例外時の戻り先 |
| 既存業務の改修相談 | 現状と変更後の処理を分けた2つの図 | 既存処理を消していないか。担当部署が変わるか |
| 小さな開発依頼の合意形成 | 画面案と未決事項の一覧を含むHTML | どこまで作るか、作らない範囲、受け入れ条件 |
これらは編集部の活用案で、導入済み企業の成果ではありません。最初は画面1つ・処理1つに絞り、関係者が説明なしで読めるかを試すと評価しやすくなります。文章を全部図へ置き換えるより、図では表しにくい制約と未決事項を短い文で残す方が、確認の抜けを減らせます。
次の要件から、実装前にレビューするplan.mdを作ってください。
目的：社内の問い合わせ受付を見直す。出力：目的、Mermaidの処理図、Wiremarkの画面案、未決事項。
ルール：- ラベルは日本語。画面案はwireframeブロックで、1画面につき1ブロック。- 正常系だけでなく、入力不足のときの戻り先を描く。- 認証・権限・二重送信・担当者不在など、要件がない点は推測で決めず未決事項へ。- MermaidとWiremarkの記法に従い、説明文と図の名称をそろえる。- 実在の顧客情報、トークン、社内URLを含めない。- blueprint4llm 0.16.1でチェックする前提とし、未対応の機能を仮定しない。- 実装や本番変更はしない。設計案の作成まで。AIにツール実行を任せる場合でも、最初に生成原稿と使うコマンドを確認します。変換の終了コードが0であっても、「権限が適切か」「データを保存してよいか」「本当にその業務フローか」は別の確認事項です。図を読んで未決事項を解消し、合意してから実装へ進めます。
Figmaやdraw.ioも使えるが、丸ごと互換ではない
公式の対応表にはMermaid、PlantUML、Wiremarkに加えて、draw.io、Pencil、Balsamiq、Figmaが載っています。ただし、名前が載っているだけで既存ファイルを無加工で読み込めるとは限りません。今回の実測範囲はMermaidとWiremarkだけです。
| 形式 | 公式資料で確認した制約 |
|---|---|
| draw.io | 構造を表すJSON。既存のXML形式ではなく、新しくレイアウトするため元の座標や装飾を保持しない |
| Pencil | 対応する.pen JSONCの一部。画像・コンポーネント・グラデーションなどに制限がある |
| Balsamiq | Mockups 3 JSONの一部。.bmprや.bmmlをそのまま扱うものではない |
| Figma | REST API JSONのローカル描画、またはフレームURL経由。URL方式にはトークンとAPIアクセスが必要 |
特にFigmaのURL方式を使う場合は、ローカルだけで完結するとは言えません。Figma APIへアクセスするためのトークンを、Markdownや共有HTMLへ貼り付けないでください。今回の教材は外部画像・Figma URL・資格情報を含めていません。初回のパッケージ取得と、導入後のローカル変換も別の工程として捉えます。
今あるMermaid環境で足りるかも、先に考える
処理図を1枚表示するだけなら、すでに使っているMarkdownプレビューで足りることがあります。blueprint4llmの試しどころは、画面案と処理図、説明を同じ原稿から配布用の文書にまとめたい場面です。既存ツールの置き換えを急がず、「日本語の画面1つと分岐図1つが、相手に渡せる形になったか」で判断できます。
採用を決める前には、版を固定し、共有相手の端末でも表示を確認し、Markdownと生成物をセットで管理します。生成物だけを手直しすると、次の変換で修正が消えます。図の見栄えに加えて、原稿を直す場所が明確であることが、この方式の実務上のポイントです。