第2話 とある現場のおじさん、図になる文字に出会う

今回のテーマ
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は意外と物忘れが激しいことを知る」