今回のテーマ
MarkdownやMermaidのような「図になる文字」を、LLMとの共通言語として見る。

現場メモ
自然言語だけでなく、人にもLLMにも扱いやすい形で渡すと、見える世界が少し変わる。

はじめに

前回は、AI時代の文字入力について書きました。

きれいな文章を最初から打とうとすると大変です。
けれど、音声入力で思いついたことをざっと出し、あとからAIと一緒に整えれば、入力そのもののハードルはかなり下がります、というお話でした。

その後、私は習熟のため、AIとのやり取りを続けていました。
すると、別の疑問が出てきました。

私たちは普段、日本語や英語のような自然言語でAIに話しかけています。
けれど、AIと人間のあいだにある表現方法は、それだけなのでしょうか。

もしかしたら、自然言語以外でもいけるのでは。
いや、むしろ自然言語だけで頑張るより、AIにとっても人間にとっても扱いやすい「文字の形」があるのでは。

今回は、そんな試行錯誤の中で見つけた「図になる文字」の話です。

その前に、今回の主役はAIというよりLLM

最近は何でもまとめてAIと呼びがちですが、今回の話では少しだけ対象を絞ります。

ここで扱うのは、ChatGPT、Claude、Gemini、CopilotのようなLLMです。
LLMは Large Language Model、日本語では大規模言語モデルと呼ばれるものです。

ざっくり言えば、文章を読んだり、続きを考えたり、別の形に書き換えたりする仕組みとして理解しています。
今はこれを「AI」として認知されている方が一般的なのではないでしょうか。

Language と聞くと、日本語や英語のことを思い浮かべます。
ところが実際には、Markdown、JSON、Mermaidのような決まった形の文字列もかなり上手に扱います。

インターネット上にもこの形式でのデータが多いので、学習も進んでいるのかもしれません。

特に、現在のAIとのインターフェースの主軸であるChat型の画面でも、Markdown記法の恩恵を知らないうちに受けていることがあります。
見出し、箇条書き、表、コードブロック。
気づけば、AIの返答はかなりMarkdownっぽい形で整っています。

では、その中でも今回の主役になる Mermaid記法 とは、いったいどんなことができるのでしょうか。

図をお願いしたら、文字が返ってきた

ある日、業務の流れを整理したくなり、LLMにこうお願いしました。

この流れを図にしてください。
受付 → 確認 → 回答

ところが、返ってきたのは画像ではありませんでした。
返ってきたのは、次のような文字列でした。

```mermaid
flowchart TD
A[受付] --> B[確認]
B --> C[回答]

最初は少し戸惑いました。

図をお願いしたつもりなのに、返ってきたのは文字です。  
「いや、図を頼んだんですけど……」と、画面に向かって小声でつぶやきました。  
オフィスでやると少し危ない人に見えるので、心の中で言うのがおすすめです。

しかし、対応したプレビュー環境で表示すると、これがちゃんとフローチャートになります。

```Mermaid
flowchart TD
A[受付] --> B[確認]
B --> C[回答]

※表示されない方向けに画像ファイルもUpしておきます。

技術者に確認すると、LLMが図そのものを描いているというより、図に変換できるテキストを出力している、と考える方が近いようです。

ここで、少し楽しくなりました。

もしかすると、AIとの付き合い方は、自然言語で「いい感じにお願いします」と頼むだけではないのかもしれません。
人間にもLLMにも読めて、画面では図にもなる。
そんな中間の表現があるのではないか、と思ったわけです。

Markdownは、文章だけの入れ物ではなかった

QiitaやGitHubで記事を読まれている方なら、Markdownは身近な存在だと思います。
この記事自体もMarkdownで書かれています。

Markdownでは、見出し、箇条書き、表、コードブロックなどを、文字だけで表現できます。

もしMarkdownを単なる文章の書き方として見ているなら、少しもったいないのかもしれません。
技術者に聞いてみると、Markdownには コードフェンス と呼ばれる仕組みがあり、その中に別の記法を書けるそうです。

コードフェンスは、バッククォートを3つ並べた行で囲む、小さな入れ物のようなものです。

たとえば、先頭に mermaid や echarts のような種類を書いておくと、対応しているアプリケーションでは、次のような意味になります。

この中身は、その記法として読んでください。

記載方法としては、だいたい次の形です。

 →``` [識別子]
 →ここに各記法を書く
 →```

→は行の開始位置を表しています。こう表現しないと表示できないためご容赦ください。

代表的な識別子を挙げると、次のようなものがあります。
すべての環境で同じように表示されるわけではありませんが、「コードフェンスの先頭に書くラベル」と考えると分かりやすいです。

分類	識別子の例	用途
プレーンテキスト	`text` / `plaintext`	そのままの文字として表示
文書・マークアップ	`markdown` / `html` / `xml` / `latex`	Markdown、HTML、XML、LaTeX
構造化データ・設定	`json` / `yaml` / `toml` / `csv` / `ini`	設定、表データ、構造化データ
プログラム言語系	`javascript` / `js` / `typescript` / `ts` / `python` / `powershell` / `bash` / `sh` / `sql` / `java` / `c` / `cpp` / `csharp` / `go` / `rust` / `php` / `ruby` / `swift` / `kotlin`	ソースコードやスクリプトの表示
開発・運用系	`dockerfile` / `diff` / `nginx` / `http`	Docker、差分表示、Nginx設定、HTTPメッセージ
図・フロー	`mermaid` / `plantuml`	Mermaid図、UML図
グラフ・可視化	`vega` / `vega-lite` / `echarts`	グラフ、可視化
その他の表現	`abc` / `wavedrom` / `mindmap`	ABC記譜法、波形図、マインドマップなど

先ほどLLMが返してきたものは、Mermaid記法と呼ばれる、テキストで図を描くための記法です。
Markdownのコードフェンスに mermaid と指定して書くことで、対応している環境ではフローチャートなどとして表示できます。

ただし、利用している環境がMermaid表示に対応していない場合は、そのままテキストとして表示されます。
同じLLMの出力でも、受け取る画面やアプリケーションによって「ただの文字」にも「図」にもなるということです。

このあたりで、私は少し考えました。

LLMだけが賢ければよいわけではなく、LLMの出力をどう見せるかも大事なのでは？

グラフも文字から作れる

数値の比較をLLMに頼むと、リストで返ってくることがあります。

Aは10、Bは20、Cは15です。

もちろん読めます。
読めますが、ぱっと見でどれが大きいかは少し分かりにくい。

そんなとき、対応環境であればEChartsのような記法を使って、グラフとして表示できることがあります。

{
  "title": { "text": "ECharts 入門例" },
  "tooltip": {},
  "legend": { "data": ["売上"] },
  "xAxis": { "data": ["シャツ", "カーディガン", "シフォン", "ズボン", "ヒール", "靴下"] },
  "yAxis": {},
  "series": [{
    "name": "売上",
    "type": "bar",
    "data": [5, 20, 36, 10, 10, 20]
  }]
}

※うまく表示されない方のために、画像も張っておきます。

同じデータでも、箇条書きで見るのと、棒グラフで見るのでは受け取り方が変わります。
数字を読むのが得意な人もいれば、グラフで見た方が一瞬で分かる人もいます。

サポートセンターや現場支援の仕事でも、これは大事です。
情報が正しいだけではなく、人が理解しやすい形で届くかどうか が重要だからです。

ただし、ここでも注意があります。
LLMと、受け取る側のアプリケーションがそろって初めて利用できます。

同じLLMを使っていても、接続するアプリケーションや表示環境によって、できることが変わります。
このあたりは、思ったより大きなポイントでした。

探してみたら、身近にあった

筆者の環境では、社内でサポートにも関わっている「つなぎAI」を利用することにしました。
OSS版としてはDifyという名前がよく知られているものです。

この環境では、Markdownや各種記法の対応がよく、ブラウザ上で完結するので、余計なインストールも必要ありませんでした。

もちろん、どの環境で何が使えるかは組織や設定によって変わります。
業務で利用する場合は、所属組織のルールや利用可能なサービス範囲を確認する必要があります。

ただ、試してみて感じたのは、次のことです。

LLMの性能だけでなく、LLMと人間の間にある画面やアプリケーションも、かなり大事。

これは、現場で使う側としては見逃せないポイントでした。

楽譜までテキストで表せる

もう一つ、個人的に面白かったのが ABC記譜法 です。

ABC記譜法は、楽譜をテキストで表すための記法です。
短いメロディや伝統音楽の譜面を、文字だけで書けます。

最初に見たときは、正直なところ暗号のように見えました。

C2 C2 G2 G2 | A2 A2 G4 |

「これは楽譜です」と言われても、楽譜が読めないおじさんには、ほぼ古代文字です。
しかし、対応した環境で開くと五線譜として表示されます。

たとえば、ABC記譜法では曲名、拍子、キー、音符の並びなどをテキストで書きます。人間には楽譜として見えるものを、LLMには文字列として渡せるわけです。
例として、今回は童謡としてなじみのある「きらきら星」を使ってみます。公開用の記事なので、ここでは説明用の短いメロディ例として扱います。最初はただの英数字の並びに見えますが、対応環境では楽譜として読めるようになります。

X:1
T:きらきら星
M:4/4
L:1/8
Q:1/4=100
K:C
% メロディ（基本形）
C2 C2 G2 G2 | A2 A2 G4 |
F2 F2 E2 E2 | D2 D2 C4 |
G2 G2 F2 F2 | E2 E2 D4 |
G2 G2 F2 F2 | E2 E2 D4 |
C2 C2 G2 G2 | A2 A2 G4 |
F2 F2 E2 E2 | D2 D2 C4 ||

人間には楽譜として見えるものを、LLMには文字列として渡せるわけです。
私の環境では、表示だけでなく再生までできました。

当然、LLMの作曲センスをいろいろ試して遊んでしまいました。
「これは検証です」と言いながら、しばらく遊びました。
現場のおじさんにも、そういう日があります。

その結果、こう考えるようになりました。

クライアントが変わるだけで、LLMはもっと色々なことができるポテンシャルがあるのでは？

LLM活用では、GPT-◯◯のようなモデルの性能だけでなく、結果を受け取る画面やアプリケーションも大事です。

LLMが出したテキストを、ただの文字として読むのか。
図として見るのか。
表として見るのか。
楽譜として見るのか。

同じ出力でも、受け取り方が変わると、人間に伝わる情報量も変わります。

楽譜が読めない私には、音符やドレミの並びを見ても曲のニュアンスは分かりません。
でも、対応環境で再生できれば、「ああ、こういう感じか」と分かります。

つまり、LLMと人間の間にある表示環境は、単なるおまけではありません。
むしろ、現場で理解しやすくするための大事な橋なのだと思います。

「図になる文字」も渡せるということ

ここまで試してみて、ようやく少し腹落ちしました。

LLMに「図を作って」と頼んだつもりでも、実際に返ってくるのは、図そのものではなく 図になる文字 です。

人間は自然言語で頼みます。
LLMはその内容を、MermaidやABC記譜法のようなテキスト記法に変換します。
最後に、表示側のアプリケーションがそれを図や楽譜として見せてくれます。

つまり、自然言語でやり取りできることはLLMの大きな魅力です。
ただ、それだけにこだわる必要はないのかもしれません。

人間にも読めて、LLMにも扱いやすく、画面では図や楽譜にもなる中間表現。
これを活用しない手はありません。

詳しい人には当たり前かもしれません。
でも、現場で使う側としては、この見方はかなり大きな発見でした。

AIに丸投げするよりも、少し歩み寄って、共通言語として扱いやすい形で渡してあげる。
そうすれば、もっといろいろなことができるようになるかもしれません。

AIよし、人よし、現場よしへ

ここで大事なのは、LLMがすごい、という話だけで終わらせないことだと思っています。

LLMがMermaidを書ける。
ABC記譜法を書ける。
Markdownの中にいろいろ入れられる。

それ自体も面白いのですが、現場で大事なのは、その結果を人が分かりやすく受け取れるかどうかです。

ただの文字列として見ると分かりにくいものでも、図になれば流れが見えます。
表になれば比較できます。
楽譜になれば音のイメージが湧きます。

LLMの出力を、人が理解しやすい形に変換できるなら、それは現場の助けになります。

その先にあるのは、AIを目立たせることではありません。
人が迷わず使えること。
業務の中に自然に組み込めること。

この連載の合言葉で言えば、こうです。

AIよし：LLMがテキスト記法を作れる
人よし：人が図や表として理解しやすくなる
現場よし：業務の流れや説明に乗せやすくなる

MarkdownやMermaidのような記法は、ただの小技ではありません。
LLMを現場に近づけるための橋渡しにもなりそうです。

次回予告：LLMは全部覚えているわけではない

ここまで来ると、LLMはかなり便利に見えてきます。

自然言語で頼めば、図になる文字や、楽譜になる文字まで書いてくれる。
では、LLMにどんどん任せればよいのでしょうか。

実際に使い続けると、次は別の壁に当たります。

昨日はうまくいったのに、今日は少し違う。
さっきまで分かっていたはずなのに、前提がずれる。
「いや、さっき言いましたよね？」と、画面に向かって言いたくなる瞬間が出てきます。

次回は、LLMが意外と物忘れをするように見える理由、つまりステートレスやコンテキストの話に進みます。

連載ナビゲーション

連載トップ
前回：第1話「AI時代の文字入力は、『正確に質問しなくちゃ！』を捨てるところから始まる」
今回：第2話「とある現場のおじさん、図になる文字に出会う」
次回：第3話「とある現場のおじさん、LLMは意外と物忘れが激しいことを知る」