---
title: LLM に、このブログの Markdown で答えてもらう
description: SVG の言語指定と記事バンドルを整理し、preview で使える記法と出力形式を伝える。
---

# LLM に、このブログの Markdown で答えてもらう

LLM に図を頼んで SVG が返ってきても、このブログではコードのまま見えることがある。中身が間違っているとは限らない。コードフェンスの言語が空だと、画像として描く経路に入らない。

このブログの tinymarkdown は小さな Markdown の処理系なので、「Markdown で答えて」だけでは、使える書き方が伝わらない。そこで、`/preview` にそのまま渡せる出力形式を伝えるプロンプトと、`slops` を書くエージェント向けの skill を用意した。

## SVG は svg と書いたフェンスに入れる

開始行は ` ```svg `。両端の空白は入れず、バッククォートを三つ、その直後に小文字の `svg` を書く。次の行から `<svg>` の本体を置き、最後はバッククォート三つだけの行で閉じる。

図を埋め込みたいときは、この言語指定が必要になる。言語なしや `xml`、`html`、大文字の `SVG` では画像にならない。

次の図は、実際に `svg` フェンスで埋め込んでいる。

```svg
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 380 264" width="380" height="264" role="img" aria-label="同じSVGでも、svgフェンスなら図になり、言語指定がなければコードになる">
  <g fill="none" stroke="currentColor" stroke-width="1.5">
    <rect x="70" y="8" width="240" height="44" rx="6"/>
    <path d="M190 52V76H92V102m98-26h98v26M86 96l6 6 6-6m184 0 6 6 6-6"/>
    <rect x="10" y="110" width="164" height="48" rx="6"/>
    <rect x="206" y="110" width="164" height="48" rx="6"/>
    <path d="M92 158v36m-6-6 6 6 6-6m190-30v36m-6-6 6 6 6-6"/>
    <rect x="10" y="202" width="164" height="48" rx="6"/>
    <rect x="206" y="202" width="164" height="48" rx="6"/>
  </g>
  <g fill="currentColor" font-size="15" text-anchor="middle">
    <text x="190" y="36">同じ SVG のソース</text>
    <text x="92" y="140">svg フェンス</text>
    <text x="288" y="140">言語指定なし</text>
    <text x="92" y="232">図として表示</text>
    <text x="288" y="232">コードとして表示</text>
  </g>
</svg>
```

一方、次は意図的に言語を指定していない。SVG ではあるが、ブログでは図にならず、ソースを表示するコードブロックになる。

```
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 60">
  <circle cx="50" cy="30" r="20" fill="currentColor"/>
</svg>
```

この違いは、[Go のビュー](../../go/examples/blog/internal/site/views.go)と[MoonBit のビュー](../../moonbit/examples/blog/site/views.mbt)が、フェンスの言語名を `svg` と比較しているために生じる。SVG の内容を見て自動で画像だと判断しているわけではない。`/preview` でも同じ指定が要る。TypeScript 版のビューは現時点ではこの描画に追従していないので、全実装が同じだとは扱わない。

## 図の見栄えより、扱いやすさ

今回は、四角、矢印、普通のテキストで図を作った。文字の大きさと配置は指定したが、フォントデータや外部フォントは使っていない。

[PR #87](https://github.com/podhmo/html-sandbox/pull/87)の図には、生成された SVG に WOFF のデータと `@font-face` が入っている例がある。この書き方をブログの図の標準にする必要はない。図の意味が分かればよく、フォントまで持ち込んで揃えることは今回の目的に含めない。

SVG の直書きを使えるからといって、複雑な描画基盤を用意する必要もない。`viewBox` を付け、小さい画面でもラベルが読める程度に要素を減らす。インラインの線や文字は `currentColor` にすると、ページの明暗にも合わせやすい。

なお、SVG フェンスは中身をそのまま HTML に入れる。[プレビューの記事](../2026-10-25-preview.md)にもあるように、サニタイズ済みの画像形式ではない。ここで使う図は、スクリプトやイベント属性、外部リソースを含まない単純なものにする。

## preview 用の回答形式を、先に伝える

[01-preview-prompt.md](01-preview-prompt.md)に、このブログで使える記法と出力形式を伝えるプロンプトを置いた。自分が使っている創作用プロンプトに、ファイルの原文を追加して併用する。創作の内容や方針は元のプロンプトで指定し、こちらは出力形式の指定として使う。回答された Markdown を `/preview` に貼るか、ファイルとして読み込ませる。

伝えるのは、単に「SVG を使って」だけではない。

- 回答全体は一つの Markdown 文書にする。前置きの挨拶や、文書全体を包むコードフェンスは付けない。
- 図を入れるときは、必ず小文字の `svg` を言語として指定する。図が要らない場合まで、無理に追加しない。
- 見出し、箇条書き、表、コード、リンクといった、このブログで扱える記法を使う。
- 画像記法、強調、番号付きリスト、Mermaid などを、普段の Markdown のつもりで使わない。
- 図は読み取れる簡単なものにし、フォント埋め込みで飾らない。

プレビューで見て、使えない書き方があれば、出力を簡単にするか、処理系に機能を足したいかを考えればよい。この記事では、処理系の対応範囲を広げる変更はしていない。

## 複数ファイルでも、一つの記事になる

もう一つ伝えておきたいのは、一つの記事を一枚のファイルにまとめなくてもよいことだ。この記事自身が、次の四ファイルからなるバンドルになっている。

```text
slops/2026-10-27-writing-slops.md/
  README.md
  01-preview-prompt.md
  02-bundle-prompt.md
  03-svg-pitfalls.md
```

`README.md` を記事の顔として、その後に残りのファイルが名前順のセクションとして並ぶ。ここでは本文と、コピーして使う二つのプロンプト、あとから足した落とし穴のメモを分けた。ファイルを物理的に連結して保存するのではなく、ブログがページを組み立てるときに合わせて表示する。

`README.md` の front matter が記事全体のタイトルや説明を決める。ほかの Markdown は本文の補足、`.svg` ファイルなら画像、それ以外のテキストならコードとして表示され、各ファイルは個別にも取得できる。下位ディレクトリや PNG/JPEG のようなバイナリーファイルは、このバンドルでは扱えない。

[02-bundle-prompt.md](02-bundle-prompt.md)は、その形でファイルを作れるエージェントに渡すための依頼文。本文とは別に補足や異なる説明を残したいときに使う。

## preview で見た目を確認する

`/preview` に Markdown を貼るか、ファイルを読み込んで、文章や図の見た目を確認できる。バンドル全体の並びは、ローカルのブログで確認する。

エージェント向けの詳しい手順は、[write-slops の skill](../../.claude/skills/write-slops/SKILL.md)にまとめた。

その skill に沿って既存の記事の図を描き直したときに出てきた落とし穴は、[03-svg-pitfalls.md](#03-svg-pitfallsmd)に残した。