「在庫があれば出荷、なければ入荷予定を連絡する」。こんな業務の流れを、AIに図にしてもらいたいことはありませんか。
pretty-mermaidは、図を作るAIに追加するSkillです。手順を文章で渡すと、AIが図を作り、掲載用の画像と、あとから直すための元データを保存します。
後で「在庫がないときは、先に営業担当へ知らせる」というルールが増えたら、元データを指定して変更を頼めます。図形を手で動かす代わりに、手順の変更をAIへ伝えるだけです。
この記事では、同じ受注フローを使って、図の作成、修正、共有までを順に紹介します。作成と修正は、編集部がClaude Codeにこの記事の依頼文を送って試した結果です（2026年10月10日）。共有先への掲載は試していません。後半では、Skillを作る人に向けて、この動きを支える指示の書き方を読み解きます。
こんな図を、文章で頼める
AIへの依頼は、たとえば次のように書きます。
pretty-mermaidを使って、次の手順をフローチャートにしてください。 ・問い合わせを受け付ける ・在庫があれば、出荷を手配する ・在庫がなければ、入荷予定をお客様に連絡する 社内Wiki用に明るいテーマのSVGを作り、修正用の.mmdも残してください。 保存先は diagrams/、ファイル名は order にしてください。内容が不足していれば、補う前に教えてください。 保存したファイルの場所と、確認した点を最後に教えてください。
この依頼で、Claude Codeが描いた図が次のものです。AIは在庫の有無を「在庫があるか」という分岐にし、開始・終了などの手順は足しませんでした。
編集部がClaude Code（v2.1.296、Opus 5.5）に上の依頼文を送り、AIが保存したorder.svg（テーマgithub-light、上から下への配置）を、Skill同梱の変換処理でPNG・幅800ピクセルにしたもの（2026年10月10日、権限モードacceptEdits、Windows・Node.js v24.21.0）。Skillはリポジトリのコミットe234ab7時点の版です。
手元に残るファイルは2つです。
diagrams/order.svg は、Wikiなどに貼るための画像です。SVGは拡大しても文字がぼやけない形式です。ただし、掲載先がSVGを受け付けるかは事前に確かめてください。Skillは、同じ元データからPNG画像も作れます。今回AIは、見た目を確かめるためにPNGを一時的に作っていました。
diagrams/order.mmd は、図の元データです。今回保存された中身は次のとおりです。
flowchart TB A[問い合わせを受け付ける] --> B{在庫があるか} B -->|あり| C[出荷を手配する] B -->|なし| D[入荷予定をお客様に連絡する]
これはMermaid（マーメイド）という、図のつながりを文章で書く記法です。flowchart TBは上から下へ並べるフローチャート、-->が矢印、{ }が分岐、|あり|が矢印に付くラベルを表します。読者がこの書き方を覚える必要はありません。手順を直したいときに、AIへ「このファイルを直して描き直して」と渡すためのものです。
pretty-mermaidは、新しく描く図の元データを.mmdファイルとして保存するようAIに指示しています。今回の依頼でも、AIは画像より先に.mmdを保存していました。画像だけを受け取って終わると、次に直すときの出発点がなくなるからです。描き終えたAIには、ファイルがきちんとできたか、矢印やラベルが依頼と合っているかを確かめさせ、その結果を報告させます。描画側が対応していない書き方があれば、黙って落とさずに伝えるよう求めています。
便利なのは、何度も直す図
AIにMermaidの図を頼むこと自体は、Skillがなくてもできます。Mermaidを表示できるエディターやWikiもありますし、ファイルやコマンドを扱えるAIなら、その場で指示すれば画像の作成まで進めることもできます。
pretty-mermaidを入れると変わるのは、毎回の依頼で説明しなくてよいことが増える点です。元データをファイルで残すこと、画像に変換すること、使う場所に合わせて形式とテーマを選ぶこと、描いた後に確かめて報告すること。これらがSkillに書かれているので、業務の手順と使う場所を中心に依頼できます。
そのため、効果が大きいのは、一度作った図を何度も直す仕事です。
- 業務手順書：経費精算の承認フローなど。承認ルールが変わるたびに、変更点を伝えて描き直す
- 問い合わせ対応の案内：「本人確認は済んでいるか」「契約中か」「どの窓口に回すか」の分岐を1つの元データで管理する
- システムや部署の関係図：担当や連携先が変わるたびに更新する
SKILL.mdが対象として挙げている図は、手順や分岐のフローチャートのほか、システム同士のやり取りを示すシーケンス図、「受付中→対応中→完了」のような状態の移り変わりの図、データベースの項目どうしの関係を示すER図、数字の推移や比較のグラフ（XYチャート）などです。編集部が試したのは、この記事のフローチャートだけです。
一方で、向かない図もあります。配置は記法から自動で決まるため、図形を好きな位置に置きたいイラスト的な図には向きません。また、1回使って捨てる図なら、Skillなしで頼むのと大きな差はありません。
導入して、同じ例を試す
導入の前に知っておくこと
導入には、Claude Code、Cursor、Codex、Gemini CLIなどのAIコーディング環境（READMEに記載）と、Node.js 16以上が必要です。Skill自体はMITライセンスで無料ですが、AIサービスの利用料は別にかかります。
初回の描画で、外部からソフトを取ってくる操作が入ります。 Skillを入れた直後は、描画に必要なライブラリ（beautiful-mermaidなど）が入っていません。編集部の試行（2026年10月10日、Claude Code v2.1.296、権限モードacceptEdits）では、最初の描画が@resvg/resvg-jsが見つからないというエラーで止まりました。AIはSkillのTroubleshootingの指示に従い、Skillのフォルダでnpm installを実行しようとし、Claude Codeが「This command requires approval」と実行の許可を求めました。許可するとインターネットからライブラリが取得され、描画できました。描画スクリプトにも初回に自動でnpm installする処理がありますが、今回はその処理に届く前にエラーで止まったため、取得はAIの操作によるものでした。
Skills.shに表示されるセキュリティの自動監査では、SocketとSnykがこの動きに警告を出しています（2026年8月23日の監査）。一方、Gen Agent Trust HubはPassです。会社のパソコンで外部からのソフト取得に承認が必要な場合は、導入前に、必要な承認と導入方法を社内で確認してください。
画像は、同じ名前のファイルに上書きされます。 Skillは「頼まれていない上書きはしない」とAIに指示しています。ただし描画スクリプト自体は、同じ名前のファイルがあっても確認せずに書き込みます。編集部の試行では、order.svgを描き直すよう頼むと、AIは上書きの確認を求めずに同じ名前で描き直しました（描き直しを頼んだので、指示どおりの動きです）。頼んでいない上書きをAIが避けるかは試していません。古い版を残したい図は、バージョン管理に入れるか、別名で保存しておきます。
画像を描く処理は、手元のパソコンで行われます。 ただし、依頼文や手順の内容は、使っているAIサービスに送られます。社内情報を含む図は、AIサービスの規約と社内ルールに沿って扱ってください。
インストールする
Skills.shに掲載されている次のコマンドを、図を作るプロジェクトのフォルダで実行します。
npx skills add https://github.com/imxv/pretty-mermaid-skills --skill pretty-mermaid
入れる先のAI環境は、実行した環境によって変わることがあります。編集部がAIエージェント（Codex）の中から確認を省く-yを付けて実行したときは、そのエージェント向けの場所（.agents/skills/）にだけ入り、Claude Code用の.claude/skills/には入りませんでした（2026年10月10日）。Claude Code向けに入れたい場合は、末尾に--agent claude-codeを付けると.claude/skills/pretty-mermaid/に入ることを確かめています。
導入後は、プロジェクトのフォルダにSKILL.mdができたか（Claude Codeなら.claude/skills/pretty-mermaid/SKILL.md）を確かめます。入れた直後のSkillは起動中の会話では使えないことがあるため、新しい会話を始めてから冒頭の依頼文を送ります。編集部の試行では、画面にSkill(pretty-mermaid)と表示され、Skillが読み込まれたことが分かりました。最後に、.mmdと画像が実際に保存されたかを確かめます。AIが「使えます」と答えただけでは、導入できた証拠になりません。Skillの読み込み方はAI環境によって違うため、この確認方法も成功を保証するものではなく、確かめる手がかりです。
依頼して、受け取る
冒頭の依頼文をそのまま送ります。この依頼文は「フローチャート」「SVG」と指定しているので、AIが図の種類や形式を自分で選ぶ場面は試していません。SKILL.mdには、手順と分岐ならフローチャート、システム間のやり取りならシーケンス図、Wikiや資料ならSVG、チャットならPNGという選び方の表があります。選んだ結果が意図と違えば、「PNGにして」「シーケンス図で」と言い直します。
「明るいテーマ」については、AIはgithub-lightを選びました。SKILL.mdのテーマの一覧で、GitHubの明るい画面向けとされているテーマです。印刷や発表向けとされるzinc-lightではありませんでした。並べ方は上から下（flowchart TB）でした。SKILL.mdの図の種類の表は左から右（flowchart LR）を書き出しの例にしていますが、別の箇所で「横に広い流れはLR、幅の狭い文書はTB」と使い分けを示しています。
依頼の最後で頼んだとおり、AIは保存したファイルの場所、テーマ、確認した点を報告しました。今回の報告は英語でした（依頼文は日本語です。同じ環境で、ファイル名の指定だけがない依頼文を送った1回目は日本語で答えたため、言語は毎回同じとは限りません）。報告の要約は次のとおりです。全文は試験の記録に残しています。
- 保存したのは
diagrams/order.mmd（修正用の元データ）とdiagrams/order.svg（Wiki用、github-light） - 足したのは「在庫があるか」の分岐と「あり」「なし」のラベルだけで、開始・終了の手順は加えていない。必要なら「完了」などを足すと提案
- 描画がエラーなく終わり、SVGが空でなく
<svgで始まることを確認 - 6つのラベル（手順4つと「あり」「なし」）がSVGに入っていることを確認
- 一時的にPNGを作って開き、日本語が切れていないこと、矢印の向き、分岐ラベルの位置を確認
- 最初の描画はライブラリ不足で失敗し、Skillの指示に従って
npm installを実行した
報告を受けたら、後述の「掲載前に見るのは3点」に沿って画像を見てから使います。
なお、依頼文でファイル名を指定しないと、名前はAIが決めます。ファイル名の指定がない元の依頼文で試した1回目は、inquiry-flow.mmdとinquiry-flow.svgという名前で保存されました。次の節の変更依頼はorder.mmdを指定するため、この記事の依頼文には「ファイル名は order」を加えています。
手順が変わったら、元データから描き直す
数か月後、「在庫がないときは、お客様に連絡する前に営業担当へ知らせる」というルールが加わったとします。AIへの依頼は次のとおりです。
pretty-mermaidを使って、diagrams/order.mmd を更新してください。 在庫がないときは、入荷予定をお客様に連絡する前に、営業担当に知らせる手順を加えます。 order.svg を描き直し、変更した点を教えてください。
編集部の試行では、AIはorder.mmdの「なし」の行を書き換えて手順を1つ加え、同じテーマでorder.svgを描き直しました。更新後の元データは次のとおりです。
flowchart TB A[問い合わせを受け付ける] --> B{在庫があるか} B -->|あり| C[出荷を手配する] B -->|なし| E[営業担当に知らせる] E --> D[入荷予定をお客様に連絡する]
更新後に、AIが描き直したorder.svgを、1枚目と同じ方法でPNG・幅800ピクセルにしたもの（2026年10月10日、Claude Code v2.1.296、Opus 5.5、権限モードacceptEdits）。
変更した点として、AIは次のことを報告しました（英語の報告の要約）。
- 「なし」の分岐に「営業担当に知らせる」を加え、「入荷予定をお客様に連絡する」はその後に来るようにした
- 「あり」の分岐、ほかのラベル、テーマは変えていない
- 描画がエラーなく終わり、SVGが空でないことを確認。一時的なPNGを開き、新しい手順が「なし」とお客様への連絡の間にあること、矢印の順番、日本語の表示を確認
図形の位置や矢印のつなぎ直しは、描き直すたびに自動で決まります。今回も、手順が1つ増えた分だけ図が縦に伸び、配置はAIが手で直さずに決まりました。
依頼文で指定したファイルがないと、AIは勝手に作らずに聞き返しました。ファイル名の指定がない依頼文で試した1回目では、保存名がinquiry-flowだったため、この変更依頼に対して「diagrams/order.mmd が見つかりません」と伝え、「inquiry-flow を更新」「order として新規保存」「order に名前を変更」の3つから選ぶよう求めました。推測でファイルを決めずに、利用者に確認した動きです。
貼ってある古い画像も差し替える
ここで忘れやすいのが、すでに共有した画像は自動では新しくならないことです。元データを直しても、Wikiに貼った画像や、チャットで送ったPNGは古いままです。pretty-mermaidの手順にも、貼った先の画像を差し替える処理は含まれていません。
更新のたびに、次の順で進めます。
- 元データ（
.mmd）を直して、必要な形式の画像を描き直す - 描き直した画像を、下の「掲載前に見るのは3点」で確かめる
- Wikiや資料に貼ってある画像を、新しいものに差し替える
- チャットなどで古い画像を送っていた相手には、更新したことを知らせる
どこに貼ったかを覚えておくのは人の仕事です。元データの横に「掲載先：社内Wiki 受注手順ページ」のようなメモを残しておくと、差し替え漏れを防げます。
修正する場所が元データ1つにまとまるのは大きな利点です。ただ、それで共有先まで揃うわけではありません。そこまで含めて手順にしておくことで、「Wikiとチャットで図が違う」という事態を防げます。
掲載前に見るのは3点
AIは描いた後に確認と報告をしますが、掲載するかどうかを決めるのは人です。次の3点を見てから使います。
1. 分岐と名称が、実際の業務と合っているか。 AIが確かめるのは「図が依頼どおりか」までです。今回の報告でも、確かめた点はラベルがそろっているか、矢印の向きや順番が依頼どおりか、文字が切れていないかで、手順そのものの正しさには触れていませんでした。依頼した手順そのものが古かったり、現場の実態と違っていたりしても、AIには分かりません。社外に出す図や、承認ルールを決める図は、その業務の担当者が最後に見ます。
2. 文字が読めるか。 ラベルが切れていないか、重なっていないかを見ます。編集部がWindows環境で、ターミナル向けの「文字だけの図」を日本語のラベルで試した際には、枠の罫線がずれました（2026年9月26日）。表示環境（フォントなど）の影響は切り分けていないため、文字の図を共有する前には出力を確認してください。2026年10月10日の受注フローでは、AIが描いたSVGと、編集部がそこから作ったPNGの両方で、日本語のラベルが切れずに表示されることを目で確かめました。
3. 掲載先で表示できるか。 SVGを受け付けないWikiやチャットもあります。実際に貼ってみて表示を確かめ、だめならPNGで作り直します。今回は掲載先に貼るところまでは試していません。
テーマ名の指定で失敗したときは、AIにテーマの一覧を出させて、正しい名前で描き直させます（Skill内の説明ファイルに、組み込みテーマにないmonokaiを勧める記述が残っているため、AIがこれを指定してしまう可能性があります）。
このSkillは、AIへの仕事の教え方をどう組み立てているか
ここからは、自分でSkillを書く人に向けた内容です。
前半では、受注フローを作り、変更し、共有するところまで見ました。後半では、その動きを支えているSKILL.mdの書き方を読み解きます。
pretty-mermaidの特徴は、描画コマンドを置くだけで終わらせず、「いつ使うか」「何を選ぶか」「何を読むか」「何を確かめるか」「何を守るか」を分けて書いていることです。以下では、それぞれを同じ受注フローに当てはめて見ていきます。
全体の構造
リポジトリと、利用者の手元にできるファイルの役割は次のとおりです。
SKILL.md … AIが従う手順、選択の基準、確認項目 references/ … 記法・テーマ・APIの詳しい説明（必要なときだけ読む） scripts/ … 図を実際に描くコマンド（render.mjs など） 利用者の .mmd … 修正できる図の元データ SVG・PNG … 掲載・共有する画像
SKILL.mdのWorkflowは、次の7つの手順でできています。
原本があるかを見分ける → 図の種類と形式を選ぶ → 必要な説明だけ読む → 元データを
.mmdで保存する → テーマを指定して描画する → 確かめて直す → 保存場所と選んだ形式・テーマを報告する
4つ目の「元データを保存する」が、前半で見た「あとから直せる」を支えています。原文は、新しい図を.mmdとして保存し、利用者の用語と要素どうしの関係をそのまま残すよう指示しています。画像だけを渡して終わるSkillにしないための一文です。
このSkillには、作業の途中経過をファイルに記録して、中断した作業を次回に再開する仕組みはありません。1回の依頼の中で「選ぶ→描く→確かめて直す」を回す作りです（図の元データは残るので、図そのものは次回に直せます）。
以下の5つの解説は、いずれも「原文の書き方 → 受注フローでどう働くか → 省いたら起こりうること → 自分のSkillへの応用」の順で書きます。「省いたら起こりうること」は設計上の推論で、比べて試した結果ではありません。「応用する指示の例」は編集部の提案で、原文の引用ではありません。
1. descriptionには、機能と「呼ばれる場面」を書く
原文の書き方（frontmatterのdescription）
descriptionは、まず機能を述べます。「アーキテクチャ文書、README、プルリクエスト、ターミナル、チャット、CI向けに、Mermaid図をテーマ付きのSVG・PNG・ASCII/Unicodeの文字図として生成・描画する」。続けて、使う場面を並べます。Mermaidのコードや.mmdファイルを渡されたとき、フローチャート・シーケンス図・ER図などを頼まれたとき、図をきれいにしたい・テーマを付けたい・一括変換したい・ターミナル向けにしたいとき、です。
受注フローでどう働くか
前半の最初の依頼は「文章の手順から新しく図を作る」もの、2回目は「既存のorder.mmdを直して描き直す」ものでした。入力の形が違います。descriptionに両方の場面が書かれていることが、AIがどちらの依頼でもこのSkillを選ぶ手がかりになります。なお、この記事の依頼文はどちらも「pretty-mermaidを使って」とSkill名を書いているため、Skill名なしの依頼でAIがこのSkillを選ぶかは試していません。
省いたら起こりうること
「きれいな図を作る」とだけ書くと、既存のコードの変換やテーマの変更も対象なのかが、AIにも人にも分かりにくくなります。ただし、場面を具体的に書いても、すべての環境で確実に呼ばれる保証にはなりません。呼ばれる判断を助ける書き方、と考えるのが正確です。
応用する指示の例
業務手順の文章からフロー図を作るとき、既存の.mmdを変更するとき、 同じ図をSVGやPNGへ変換するときに使う。
Skillの説明には「何ができるか」に加えて「どんな依頼で使うか」を書きます。新しく作る依頼と、既存のものを直す依頼の両方を挙げると、使う範囲がはっきりします。
2. 「適切に選んで」を、目的から引ける表に変える
原文の書き方（Choose a diagram type、Choose an output、Theme selection）
図の種類は「何を表したいか」から引く表になっています。手順・判断の分岐・システム構成ならフローチャート、APIの呼び出しやメッセージのやり取りならシーケンス図、状態の移り変わりなら状態遷移図、という具合です。出力形式も「どこで使うか」の表で、文書・スライド・WebならSVG、チャットや画像しか扱えないツールならPNG、ターミナルなら文字の図です。テーマは「印刷や発表にはzinc-light」のように、用途から選ぶ一覧になっています。
受注フローでどう働くか
受注フローで行う判断は3つです。編集部の試行（2026年10月10日）で、何が依頼で決まり、何をAIが選んだかを並べます。
| 判断すること | 受注フローでの選択 | 誰が決めたか |
|---|---|---|
| 図の種類 | フローチャート | 依頼文で指定 |
| 出力形式 | SVG（確認用にPNGも一時作成） | 依頼文で指定。PNGはAIが確認のために作った |
| テーマ | github-light | 依頼文は「明るいテーマ」だけで、名前はAIが選んだ |
テーマの選択では、AIはテーマの一覧を出すコマンドも説明ファイルも使わず、SKILL.md本体の一覧にあるgithub-lightを指定しました。印刷向けならzinc-lightのように、用途がはっきりしていれば依頼文に書くと選択が揃いやすくなります（編集部の提案で、試していません）。掲載先がその形式を受け付けるかは、原文の表では確かめません。
省いたら起こりうること
選ぶ基準がないと、AIの選んだ形式が用途に合っているかを、利用者が確かめにくくなります。基準が表になっていれば、「Wiki向けだからSVGを選んだ」と理由付きで報告でき、違えば利用者がすぐ指摘できます。
応用する指示の例
手順と判断の分岐を示すならフローチャートを選ぶ。 掲載先が対応する画像形式を確認し、選んだ形式と理由を報告する。
AIに選ばせる場面があれば、「適切に」と書く代わりに「目的 → 選択肢」の表を置きます。報告に選んだ理由を含めさせると、利用者が確かめやすくなります。
3. 詳しい説明は別ファイルに分け、「いつ読むか」を本体に残す
原文の書き方（Workflow手順3、Reference routing、Core commands）
手順3は「記法、テーマ選び、APIの挙動について詳しく知る必要があるときだけ、該当する参照ファイルを読む」です。末尾のReference routingの表で、どのファイルをいつ読むかを決めています。
references/DIAGRAM_TYPES.md：Mermaidの記法を書くとき、記法の誤りを直すときreferences/THEMES.md：テーマを比べるとき、独自の色を決めるときreferences/api_reference.md：スクリプトを拡張するとき、描画ライブラリを直接呼ぶとき
コマンドの使い方はCore commandsに例を載せたうえで、「正確なオプションの一覧はrender.mjs --helpを見る」と、正しい情報の置き場所をスクリプト側に指定しています。
受注フローでどう働くか
編集部の試行では、AIは参照ファイルを1つも開きませんでした。会話の記録に残っているファイルの読み込みは、確認用に作ったPNG画像だけです。記法のエラーも出ず、テーマもSKILL.md本体の一覧で決まったため、詳しい説明を読む条件に当たらなかったと考えられます。ラベルの書き方で記法のエラーが出たらDIAGRAM_TYPES.mdを、テーマを見比べたいときはTHEMES.mdを読む、という条件は今回は試していません。
省いたら起こりうること
詳しい説明を全部SKILL.mdに書くと、AIは単純な依頼でも関係ない説明まで読むことになります。逆に、別ファイルに分けただけで本体に案内がなければ、AIがそのファイルの存在に気付かない可能性があります。分けることと、読む条件と場所を本体に残すことはセットです。
応用する指示の例
図の書き方で迷ったら references/DIAGRAM_TYPES.md を読む。 テーマを比較する必要があるときは references/THEMES.md を読む。 コマンドの引数は、実行前にスクリプトの --help で確認する。
なお、このリポジトリはSKILL.mdが500行未満かどうかを自動で検査しています。大事なのは行数そのものより、本体には判断と案内を、別ファイルには詳細を、という役割の分け方です。
4. 「描けた」と「内容が正しい」を分けて確かめる
原文の書き方（Workflow手順6、Validation、Troubleshooting）
手順6は「結果を見て、記法の誤り、図の切れ、混み合った配置、分かりにくいラベルを直して描き直す」です。Validationには、描いた後の確認が5項目あります。コマンドが正常に終わり出力が空でないか、SVGが<svgで始まりPNGが画像として開けるか、配置が大事なときは長いラベル・日本語などの文字・つながっていない部分を目で見たか、矢印・関係の数・状態・ラベルが依頼と合っているか、対応していない記法を黙って落とさず報告したか、です。Troubleshootingには、記法の誤りが出たら「失敗している1文まで減らし、少しずつ戻す」という切り分けの手順もあります。
受注フローでどう働くか
この記事では、原文の5項目を3段階に整理して、受注フローの更新に当てはめます（整理の仕方は編集部によるものです）。
| 確かめること | 受注フローの更新で見るもの |
|---|---|
| ファイル | 出力が空ではなく、画像として開ける |
| 見た目 | 日本語が切れず、矢印とラベルが読める |
| 内容 | 「営業担当に知らせる」が「お客様に連絡する」より前にある |
PNGが開けるだけでは、更新が正しく反映されたかは分かりません。追加した手順が依頼どおりの順番で入っているかまで見て、初めて「直せた」と言えます。
編集部の試行（2026年10月10日）で、AIが実際に行った確認は次のとおりです。会話の記録に残ったコマンドと報告から整理しました。
- ファイル：描画コマンドの終了を確かめ、SVGのサイズと、
<svgで始まることを確かめた（原文の1・2項目） - 見た目：確認用のPNGを作って画像として開き、日本語が切れていないこと、矢印と分岐ラベルの位置を見た（3項目）
- 内容：最初の図では6つのラベルがSVGに入っているかを文字列で検索し、更新後は「営業担当に知らせる」が「なし」とお客様への連絡の間にあることを画像で見た（4項目）
5項目めの「対応していない記法の報告」は、対応外の記法を使わなかったため、確かめる場面がありませんでした。
省いたら起こりうること
「確認すること」とだけ書くと、AIは「確認しました」と報告するだけになりがちです。ファイルの確認だけで終わると、見た目は整っているのに、手順の順番が違う図が届くことがあります。
応用する指示の例
画像が開くこと、文字と矢印が読めること、追加した手順の順番が依頼と一致することを確認する。 問題があれば元データを直して再出力する。確認できなかった点は報告する。
ただし、ここでの確認は、図を描いたAI自身による点検です。別の人や別のAIによる独立した評価ではありません。また、依頼した業務ルールそのものが正しいかは、AIには分かりません。原文には、直して描き直す回数の上限もありません。上限や「何回失敗したら止める」という条件が必要なら、自分のSkillに追加します。
5. 「指示で守らせること」と「仕組みで保証すること」を区別する
原文の書き方（Workflow末尾、Working directory）
Workflowの最後に「利用者が置き換えを頼んでいない限り、既存の元データや出力を上書きしない」とあります。Working directoryでは、スクリプトはSKILL.mdのあるフォルダから実行し、利用者の元データと出力は利用者が指定した場所に置き、描画スクリプトを利用者のプロジェクトへコピーしない、と道具と成果物の置き場所を分けています。
一方、描画スクリプトrender.mjs自体は、同じ名前のファイルがあっても確認せずに書き込みます。編集部がスクリプトを直接2回実行した試行（2026年10月9日）でも、同じorder.svgが確認なしで置き換わりました。上書きの禁止は、AIへの指示としては書かれていますが、スクリプトの動きとしては強制されていません。
受注フローでどう働くか
前半の更新の依頼では「order.svgを描き直して」と、置き換える対象をはっきり書きました。編集部の試行では、AIは上書きの確認を求めずにorder.svgを描き直しました。置き換えを頼んだ場合なので、原文の指示どおりの動きです。Claude Codeが求めたのはコマンドを実行してよいかの許可で、上書きの確認ではありませんでした。頼んでいない上書きをAIが避けるかは試していません。一方、更新前の図も残しておきたいなら、別名で保存するよう頼むか、バージョン管理に入れておく必要があります。スクリプトが自動で守ってくれるわけではないからです。
省いたら起こりうること
「上書きしないこと」と書いておけば安全だと考えてしまうと、AIが指示を読み落としたときや、人が直接スクリプトを実行したときに、大事なファイルが置き換わります。指示は守られることが多くても、保証ではありません。
自分でスクリプトも作る場合の応用案
出力先に同じ名前のファイルがある場合は、置き換えの指定がない限り処理を止める。 許可された出力先へ保存し、元データと出力の場所を報告する。
これはpretty-mermaidにある機能ではなく、追加する仕組みの提案です。守らせたいことがあれば、「AIへの指示」「スクリプトでの制御」「確かめ方」の3つのうち、どれで守るのかを決めて書きます。消えると困るものほど、指示だけでなく仕組みでも守ります。
各指示の原文は、SKILL.md原文で確認できます。
補足：Skillの基本情報
- Skill名：
pretty-mermaid（Skills.sh） - 作者・リポジトリ：imxv（GitHub）。リポジトリ名は
Pretty-mermaid-skillsで、Skill名とは異なる - ライセンス：MIT
- 描画エンジン：beautiful-mermaid
- 出力形式：SVG、PNG、文字の図（Unicode罫線／ASCII／色付き）。テーマは15種類
- セキュリティの自動監査（2026年8月23日）：Gen Agent Trust HubはPass、SocketとSnykはWarn。警告の中心は、実行時の自動
npm installと、出力先の上書き。いずれも自動監査の表示で、安全性を保証するものではない。2026年10月10日にインストールしたときの表示は、GenがSafe、Socketが2 alerts、SnykがMed Risk
情報源・参考リンク
