第4話 とある現場のおじさん、MermaidでLLMに歩み寄る

今回のテーマ
Mermaidを使って、LLMに処理の流れを伝える。

現場メモ
自由に考えてほしい部分と、手順どおり進めてほしい部分を分けると、Workflowの入口が見えてくる。

はじめに

第2話では、Mermaidを「図として表示できる文字」として見ました。
第3話では、LLMは何でも覚えているわけではなく、渡された文脈や状態に大きく影響されることを見ました。

そう考えると、業務の流れや判断条件をその場の会話だけに任せるのではなく、人間にもLLMにも読める形で外に出しておくことが大事になってきます。

そこで改めて役に立ちそうなのが、Mermaidです。
単に図を描くためではなく、処理の流れをLLMに伝えるための共通言語として使えるのではないか、と思えてきました。

最初は、Mermaidはフローチャートをきれいに描くための便利な記法だと思っていました。
けれど、実際に使ってみると、Mermaidには人間がLLMに歩み寄るためのメリットと、使ううえで気をつけたいデメリットがありました。

Mermaidを使うメリット

1. 処理の順番を矢印で表せる
   業務の流れを上から順に追いやすくなり、人間もLLMも同じ流れを確認しやすくなります。

2. 条件分岐を明示できる
   「〜の場合は〜する」という業務ロジックを書きやすくなり、あいまいな依頼だけで進めるよりも前提をそろえやすくなります。

3. 状態や判断ポイントを外に出せる
   何を前提に進んでいるのか、どこで判断しているのかをノードとして確認しやすくなります。

4. 図として見やすく、テキストとして残せる
   人間には図として見やすく、LLMにはテキストとして渡し直しやすい形になります。

5. 処理全体を渡しやすい
   その場の一問一答だけではなく、全体像をまとめて渡せるため、LLMが途中で横道に逸れにくくなる効果も期待できます。

Mermaidを使うときの注意点

もちろん、良いことばかりではありません。
Mermaidには次のようなデメリットもあります。

1. 記法に慣れる必要がある
   最初は矢印やノードの書き方に少しだけ学習コストがあります。

2. 大きくなると見づらくなる
   処理を詰め込みすぎると、かえって全体像が追いにくくなることがあります。

3. 対応環境に依存する
   対応していないアプリケーションでは、図ではなくただの文字として表示されます。

4. 実行を保証するものではない
   矢印や分岐を書いたからといって、LLMが必ずその通りに実行してくれるわけではありません。
   あくまで前提や流れを伝えるための補助線として考えた方がよさそうです。

それでも、業務処理の流れを人間にもLLMにも伝わりやすい形にできるという点で、Mermaidはかなり使える共通言語なのではないかと思えてきました。

1. まずはChatで、好きな色の豆知識を返してもらう

今回のサンプルは、サポートセンターの業務フローではなく、もっと小さくて試しやすいものにしました。

ユーザに好きな色を入力してもらい、その色に関するちょっとした豆知識をLLMに返してもらうだけのチャットです。

最初は、普通にChatへ次のように頼めば、それっぽく動きます。

好きな色を聞いて、その色に関する豆知識を返すチャットを作ってください。

このくらいの依頼でも、最近のLLMはかなり自然に返してくれます。
ただ、実際に続けて使おうとすると、終了したいときはどうするのか、色ではない入力が来たらどうするのか、何回まで繰り返すのか、といった細かいところが気になってきます。

そこで、LLMに相談しながら、Mermaidで少しずつフローにしてみることにしました。

図としてきれいにするためというより、あとでこのMermaid記法そのものをLLMに渡し、どの順番で処理してほしいのか、どこで判定してほしいのかをガイドするためです。

2. Mermaidで段階的にフロー化してみる

まず、LLMに「最小構成ならどうなるか」と聞いてみました。
返ってきたのは、好きな色を聞き、LLMが豆知識を返し、終わるだけのシンプルな流れでした。

※表示できない方向けに画像も貼っておきます。

これだけでもサンプルとしては動きそうです。
ただし、ユーザが「今日は疲れた」と入力した場合まで考えると、少し不安になります。

次に、「色ではない入力が来たらどうするか」をLLMに相談しました。
ここで意外と大事なのが、「色として扱えるか」という判定です。

単純に色名リストと照合するだけなら、普通のプログラムでもできます。
けれど実際には、「空色」は色なのか、「海のような色」はどう扱うのか、「赤と青を混ぜた色」と言われたら紫系と見なしてよいのか、といった少しあいまいな入力が来るかもしれません。

さらに「カレー」のように、食べ物として入力されたのか、本人は「カレー色」のつもりで入力したのか、境界が揺れるものもあります。
こういう文脈込みの判断は、LLMならではの面白いところです。
既存のルールだけで全部をきれいに拾うのは、なかなか大変そうです。

LLMの回答は、入力が色として扱えそうかを確認し、色でなければもう一度入力してもらう分岐を入れるとよい、ということでした。

※表示できない方向けに画像も貼っておきます。

ここで重要だったのは、処理の中で「自由にふくらませてよい部分」と「手順どおりに進めたい部分」が混ざっている、ということです。

色にまつわる文章を自然に作るところは、LLMらしく連想を広げてもらいたい部分です。
また、「空色」「海のような色」「赤と青を混ぜた色」のような入力を、色として扱えるか、どの系統に近いかを判断するところも、LLMの柔らかい判定が活きる部分です。

一方で、終了指示かどうか、判定後に次へ進むか再入力に戻すか、といったロジックは、毎回ぶれずに進めたい部分です。

だんだんとMermaidを、LLMに固定作業を正確に進めてもらうためのガイドとして使えないか、というチャレンジ心が出てきました瞬間でした。

豆知識の回答や柔らかい判定を工夫するあまり、フローを外れてしまっては本末転倒です。
プロンプトとして、フローを絶対準拠する制限は必須ですね。

さらに、「色の種類によって返す豆知識を変えたい」と伝えると、赤系、青系、緑系、それ以外に分ける案が出てきました。
ここから少し、フローらしくなってきます。

※表示できない方向けに画像も貼っておきます。

ここまで来ると、ただの雑談サンプルでも、意外と分岐があります。

色の分類をLLMに任せるのか、事前にルールとして持つのか。
返す文章はどこまで自由にしてよいのか。
小さなサンプルでも、考えることはあります。

最後に、「終了したいときや、もう一度聞きたいときも考えたい」とLLMに追加で相談しました。
終了指示と繰り返しを足すと、少しだけ会話アプリらしい流れになります。

※表示できない方向けに画像も貼っておきます。

3. フローにすると、Workflowの入口が見えてくる

ここまでフローにしてみると、「好きな色を聞いて、豆知識を返す」だけの小さなチャットでも、いくつかの処理に分けられることが分かります。

• 入力を受け取る
• 終了指示かどうかを判定する
• 色として扱えるか確認する
• 色の系統を分類する
• 豆知識を生成する
• 必要ならもう一度聞く

こう並べると、単なる一問一答ではなく、小さな処理の箱を順番につないでいるように見えてきます。

ここで大事なのは、LLMの得意な文章生成を止めることではありません。
色の意味や印象をくみ取り、読み物として自然な文章にするところは、むしろLLMらしさを活かしたい部分です。

その一方で、終了指示、入力チェック、分類、繰り返しといったロジック部分は、自由回答に任せきるのではなく、Mermaidで明示した流れに沿って処理してほしいところです。

つまり今回は、Mermaidを「図として眺めるもの」ではなく、LLMが横道に逸れずに固定作業を進めるためのガイドとして渡してみる試みでした。

ここまで来ると、AgentやWorkflowという言葉も、少しだけ現場の作業に引き寄せて考えやすくなります。
LLMを単体で使うよりも、前後に判定や確認ポイントを置いた方が安心できそうだ、くらいの理解で十分かもしれません。

実際にこのMermaidフローをLLMに渡して試してみると、結果としてはほぼ想定どおりに動きました。

「青」は青系として扱われ、「若草色」は緑系として解釈され、「今日は疲れた」のような入力は色ではないものとして再入力に戻せます。
思ったより素直にフローを読んでくれたので、ここはかなり手応えがありました。

ただし、良いことばかりではありません。
Mermaidのフローをそのまま毎回渡すということは、その分だけ入力が長くなり、トークン数も増えます。

おじさん流に言えば、道順を書いた地図を毎回持たせているようなものです。
迷いにくくなる一方で、荷物は少し重くなります。

このあたりで、Chatの中で全部を頑張るより、決まった流れはWorkflow側に持たせた方がよいのでは、という気持ちが強くなってきました。

4. 話はDifyやつなぎAIのWorkflowにつながる

結果、「餅は餅屋」という話です。

Chatは使いやすく、試行錯誤には便利です。
ただ、決まった順番で進めたい処理を毎回会話の中で説明するのは、業務利用としては少し不安が残ります。

入力受付、終了判定、分岐、繰り返しのようなロジック部分は、アプリケーション側やWorkflow側に持たせた方が、現場としては安心です。

一方で、色として扱えるかの柔らかい判定や、豆知識の文章生成のような部分は、LLMらしさを活かしたいところです。

そう考えると、つなぎAIやDifyのWorkflowのように、処理をいくつかの箱に分けてつなぎ、必要なところでLLMを呼び出す形は、納得の仕組みです。

今回Mermaidで書いたフローは、完成した業務アプリそのものではありません。
むしろ、LLMに「この条件に合ったら、こう動いてほしい」と伝えるための、小さなガイド、あるいはマクロのような使い方に近いと感じました。

Chatで試し、Mermaidで流れを整理し、必要ならWorkflowへ移す。
この順番が、現場で扱うにはちょうどよさそうです。

ただし、モデルの進化は思ったより早かった

ここまで、Mermaidでフローを整理し、状態を外に出し、LLMが迷わないように道筋を作る話を書いてきました。
ところが、試行錯誤している途中で、利用しているLLM側のバージョンアップがありました。

すると、Mermaidで細かくフローを示さないと不安定だった処理が、自然言語の長めの指示だけでも、それなりに安定して通るようになっていました。

複雑で長い処理でも、思ったより自然言語の指示だけで、間違わずに進めてくれる場面が増えたのです。

正直に言うと、少し泣きました。
フローを分解し、記法を整え、どこで状態を持たせるかを考えていた苦労が、水の泡に見えたからです。

おじさんがせっせと交通整理していたら、道路の方が勝手に信号機を立て始めたような感覚でした。

人間がLLMに歩み寄るのが先なのか、AIの方が人間や業務に歩み寄ってくるのが先なのか。
そこは大半の人はAIが歩み寄るべきと思うところだと思います。
自分もその方が楽なので、そう思います。

ただ、今回の取り組みは決して無駄ではありませんでした。

Mermaidでフローを描き、状態を外に出し、どこで人が確認するかを考えたことで、LLMにどう頼めば伝わりやすいか、どこを自由に任せて、どこを手順として固定した方がよいか、少しずつ分かるようになりました。

つまり、苦労は少し水の泡になったかもしれませんが、AIとの会話のセンスは磨けました。

モデルが進化しても、人が何をしたいのかを整理し、業務の流れとして伝える力は残ります。
むしろモデルが賢くなるほど、その指示の出し方や確認の仕方が効いてくるのかもしれません。

次回は、LLMに処理させるだけでなく、LLMがどのように判断し、どこを通って、どこで止まったのかを人に伝えてもらう話に進めてみます。

LLMに一般的なプログラム開発で利用する、トレースログ機能やデバッグ環境を追加できないか試行錯誤した話です。

まとめ：これから大事になりそうな、情報の渡し方

今回の話を通して、これからは「どのモデルが賢いか」だけでなく、「どの情報を、どれくらいの量で、どのタイミングで渡すか」を調整できる道具が重要になるのではないかと感じました。

これは、まさに「現場よし」に関わる話だと思います。

現場では、毎回最高性能のモデルに全部の情報を投げればよい、というわけにはいきません。
費用、速度、説明しやすさのバランスがあります。

だからこそ、業務の流れに合わせて、必要な情報だけを必要な形で渡せることが大事になりそうです。

将来的には、トークン数やコンテキストウィンドウをあまり気にしなくてよい世界が来るかもしれません。
それでも、必要な情報をどう選び、どう渡すかという設計は、しばらく残る気がします。

情報を全部渡すのではなく、人が確認できる形で整理し、費用、速度、精度のバランスを取りながら業務に組み込む。

AIよし。
人よし。
現場よし。

この調整ができるツールや設計思想が、これからますます求められていくのではないかと感じています。

次回は、LLMがどのように判断し、どこを通って、どこで止まったのかを人に伝えてもらう話に進めてみます。

連載ナビゲーション

• 連載トップ
• 前回：第3話「とある現場のおじさん、LLMは意外と物忘れが激しいことを知る」
• 今回：第4話「とある現場のおじさん、MermaidでLLMに歩み寄る」
• 次回：第5話「とある現場のおじさん、LLMにデバッグ環境を持ち込む」