今回のテーマ
LLMの答えだけでなく、判断の道筋と状態も返してもらう。

現場メモ
失敗したら最初からやり直すのではなく、「ここを直して、ここからもう一度」と言えるようにする。

はじめに

前回は、好きな色を入力すると、その色に関する豆知識を返す小さなフローをMermaidで作りました。
Chatで試し、Mermaidで流れを整理し、その記法をLLMに渡してみると、青や若草色のような入力はほぼ想定どおりに処理できました。

第5話では、この完成したフローを前提に、第4話で工夫した判定、分岐、状態の持たせ方も振り返りながら、LLMの処理を人が追える形にするにはどうすればよいかを考えていきます。

ただ、動いたからといって安心できるわけではありません。
LLMがどの判断をして、どの分岐を通り、どこで止まったのかが見えなければ、業務では少し怖いままです。

そこで今回は、LLMに結果だけでなく「通った道筋」も人に返してもらう話に進みます。

今回のポイントは、LLMの答えだけでなく、判断の道筋と状態を返してもらうと、原因特定・修正・途中再実行ができるようになる、ということです。

うまく動いたら動いたで、次の欲が出てきます。

もし途中で止まったらどうするのか
色ではない入力を色として扱ってしまったら、どこを直せばよいのか
思った分岐に進まなかったとき、何が起きたのかをどう確認すればよいのか

ここから、第5話では「動かす」よりも「人が追えるようにする」ことを考えていきます。

1. 止まったときに、どこで止まったのか分からない

LLMに長めの処理をお願いすると、結果だけが返ってくることがあります。
うまくいっている間はそれで問題ありません。
けれど、失敗したときは困ります。

入力が悪かったのか。
分岐が悪かったのか。
LLMの判断が揺れたのか。
こちらの指示が曖昧だったのか。

これが見えません。

そこで、ふと思いました。

結果だけでなく、通った道筋も返してもらえばよいのではないか。

第4話でMermaidのフローを作ったのなら、処理結果と一緒に、どのノードを通ったか、どこで判断したか、どこでエラーになったかを返してもらえないだろうか、と考えたわけです。

2. Mermaidで通った道筋も返してもらおう

まずは、LLMに次のようにお願いしてみました。

処理で通った道筋もMermaidで返してください。

まずは「見える化」してもらうところから始めようというわけです。

たとえば、入力が「青」だった場合は、次のようなトレースを返してもらうイメージです。

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

これだけでも、かなり見通しがよくなります。

最終回答だけを見ると「青の豆知識が返ってきた」で終わります。
しかし、道筋を見ると、次の途中判断が見えます。

終了指示ではない
色として扱える
青系として分類した
青系の豆知識生成に進んだ

ここが見えるだけで、失敗したときの探し方が少し変わりそうです。

3. エラーもフローで返してもらう

日本語は、色の表現が本当に豊かです。

すみれ色、若草色、暁色、茜色。
こういう言い方があるためか、LLMも色として認識する範囲は、考えていたより広そうでした。

さらに「夏色」のように、一つの言葉が複数の色を連想させる場合もあります。
青空のような青かもしれませんし、強い日差しの黄色かもしれませんし、海や花火のような色かもしれません。

前回は詳しく書きませんでしたが、ここは結構つまずいたところです。
試行錯誤の結果、一つの色名に決めるより、青系、黄色系、赤系、その他のように、ある程度の系統として扱う方が想定の動作になりました。

ただし、試しに「カレー」と入力してみると、今回のサンプルでは色としては扱われず、エラーになりました。

もちろん世の中には「カレーは色だ」「カレー色は認知されている」という熱いご意見もあるかもしれません。
カレー好きとしては、その気持ちは分からなくもありません。
とはいえ、今回は食べ物寄りの判定です。
さて、お腹は少し空きましたが、フローとしては正しい動きに見えました。

この作業でトレースは大いに役立ってくれました！
ただ、通った場所だけでは、情報が少し足りませんでした。

そこで、最終回答だけでなく、エラーや判断結果もMermaidで返してもらうようにしました。

もちろん、LLMに「さっきはなんでこんな判定したの？」と聞けば、それなりの回答が返ってくるかもしれません。
ただ、文字を打ったり読んだりするのは手間です。
視覚的に一瞥できる図に勝るものはなしです。

かなりプロンプトとにらめっこする時間は減ったと思います。

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

4. 状態も含めた色付きスタックトレースにしてみる

もう少し機能を追加してみました。

判定に使った変数的な状態があれば、あわせて表示してもらうようにしました。
また、私が欲しかったのは、単なるトレースログではありませんでした。

全体の処理が見えつつ、その中でどこまで処理したのかを表示してほしかったのです。
そこで、スタックトレースっぽく、各処理の最後の状態のみを記載する方式にしました。

知りたいのは、繰り返し処理の途中経過すべてではありません。
最後にエラーが発生したとき、どこを通って、どの状態だったのかです。

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

上のMermaidを図として見ると、次のようなイメージになります。

緑：通過済み
赤：エラー
青：保持状態
黄色：次に進む場所
グレー：未実行

つまり、エラー時に、どこを通って、どの状態で止まったかを一覧できる図として使えるわけです。

5. 途中からやり直せると、デバッグ環境っぽくなる

ここまで来ると、ただトレースを見るだけではなく、「止まった場所からもう一度走らせる」ことも考えたくなってきます。

たとえば「カレー」で止まった場合、入力を最初からやり直すのではなく、保持状態の一部だけを修正して、そこから再開できないか、という発想です。

具体的には、次の状態を見たとします。

input=カレー
判定=色として不確定

この状態を見たうえで、人が「これはカレー色の意味として扱う」と補正します。
そのうえで、色の系統判定のところから再度実行する。

これは、一般的なプログラム開発で、変数の値を確認し、必要な値を直して、特定の処理から再実行する感覚にかなり近いです。

ここで大きかったのは、止まった場所と状態が分かれば、同じ前提を渡して再実行を試しやすくなることです。

通常のプログラムのように、厳密な意味で一字一句同じ挙動を保証するわけではありません。
それでも、フロー、入力値、判定結果を一緒に渡せば、「ここを直して、ここからもう一度」とかなり具体的に指示できます。

しかも修正内容は、必ずしもコードのように書く必要はありません。

カレーはカレー色として扱って、色の系統判定から再開してください。

このように、自然言語で補正を伝えられるのもLLMらしいところです。

ただし、会話が長くなって前提が怪しくなってきた場合は、当初のMermaidフローもあわせて渡し直した方がよさそうです。
どの処理から再開するのか、どの分岐を通るべきなのかを、自然言語だけでなく図になる文字として一緒に渡す。

これで、LLMが途中で道を忘れかけても、もう一度地図を持たせられます。
おじさんとしては、これは小さなデバッグ環境を手に入れた感覚でした。

6. 仮説検証にも使えそうだった

この考え方は、業務処理だけではなく、仮説検証にも使えそうです。

たとえば、次のような確認です。

ある問い合わせがなぜ特定のカテゴリに分類されたのか
別の条件を足したら結果が変わるのか
参照した情報を一つ減らすと回答がどう変わるのか
どの判断が結果に効いていたのか

こうした確認を、毎回最初からやり直すのではなく、状態や条件を少しだけ変えて再実行できると、検証の手間がかなり減ります。

既存のChatでは、LLMの揺らぎを完全に抑えるのは難しいと思います。
けれど、フロー、状態、通った道筋を外に出し、LLMに分かりやすい形で渡すことで、ある程度コントロールしやすくなります。

ここで大事なのは、LLMそのものを完全に安定化することではありません。
LLMが多少揺らいでも、壊れにくい形にしておくことなのだと思いました。

7. MCPで手が増えるほど、見える化が必要になる

MCPのような仕組みでAIに手足が増えるほど、LLMと外部ツールが何をしたのかは見えにくくなります。

検索したのか。
ファイルを読んだのか。
別の道具を呼んだのか。
どの結果を使って、どの判断に進んだのか。

だからこそ、結果だけでなく、通った道筋も図として返してもらう意味があります。

自然言語でお願いしたことでも、後から原因を特定したり、途中から処理を続けたりしたい場面は出てきます。
そのとき、人が追える形で返してもらえるかどうかが大事になります。

ここは、道具が増えるほど効いてくる一手間だと思いました。

まとめ：AIよし、人よし、現場よし

今回の発見は、LLMを完璧に安定させることではありませんでした。
むしろ、LLMが揺らぐ前提で、フローを出し、状態を出し、途中から直せるようにしておくことです。

これができると、AIは結果を出すだけでなく、人に判断の道筋を伝えられるようになります。

AIよし。
人が結果だけでなく、途中の判断も追えるようになるので、人よし。
そして、原因特定や途中再実行がしやすくなれば、業務にも仮説検証にも組み込みやすくなるので、現場よし。

LLMにすべてを丸投げするのではなく、LLMが揺らいでも壊れにくい形で一緒に進める。
ここに、現場のおじさんなりの次の一歩がありそうです。

LLMのトレースログは取れるようになりました。
次は、おじさん側のログです。
自分まで迷子にならないよう、機会があれば、続編としてブログにも試行錯誤の跡をトレースログとして残していこうと思います。

連載ナビゲーション

連載トップ
前回：第4話「とある現場のおじさん、MermaidでLLMに歩み寄る」
今回：第5話「とある現場のおじさん、LLMにデバッグ環境を持ち込む」
次回：未定