AI 社会 ≒ 生成 AI を相手にする ≒ LLM を相手にする、というわけで、LLM に対するコミュニケーション能力が求められる時代だと思います。
しかし、LLM は人間とはまるで違っており、クセが強いです。人間向けのコミュニケーションをそのままぶつけても上手くいきませんし、なぜか上手くいかない → そんな役に立たないよね、となってしまいがちです。これは新しい「コミュ障」の形なのかなと思いました。
本記事では、コミュ障から脱するのに使える汎用的な原理原則を、端的に整理します。
背景：「人間」だけではなく「AI」とも向き合う時代
言うまでもなく、現代は AI と も 向き合う時代です。
AI、もっというと LLM 向けのコミュニケーション術が必要です。今のところ読み書きベースなので、伝える≒書く、となります。つまり 書き方を知る必要があります。
本記事では原理原則を紹介します
理由は単純で、ツールやテクニックよりも応用しやすいだろうからです。
おことわり
この後紹介する LLM Readable、LLM Friendly はどちらも確立された用語ではありません。しかし、分かる人には分かる言葉ではあると思います。本記事の解説は私の認識と考えてください。
では、本題に入りましょう
LLM Readable と LLM Friendly という２つの概念を紹介します。
LLM Readable とは、内容の話
LLM Readable とは、LLM にとって読みやすい内容であることを指します。
Readability は人間で言えば「認知負荷が小さい」、LLM 向けに言えば「意味的に理解しやすい」ということです。
例:
- 具体的である
- 定量的である
- 定義的である（定義が存在する）
- 説明的である（意味を理解するためのヒントが多く存在する）
- 区分的である（情報が適切に区切られている）
ただし、人間が結果を見て追加指示を出して、のようなループを回したい場合は、あえて Readable から逆行することもあります。特にとっかかりが欲しいときは、それこそコピペした後に「論じてみて」とか「どう？」などと尋ねるだけでも違います。あるいは AI 自身に「あなたにとって Readable にしたいんだけど何が足りない？」のように聞いてもいいでしょう。
LLM Friendly とは、形式の話
次に LLM Friendly とは、LLM にとってパース（走査）しやすい形式であることを指します。
例:
- パワポよりもプレーンテキスト
- チャットに書いた乱雑なテキストよりも、Markdown で構造化されたテキスト
- 図表よりもDSLや擬似コード、DSLや擬似コードよりもコード
Friendly は 装飾（デバフ）と構造（バフ） を考えると良いと思います。
装飾とは、主に人間向けのビジュアルをいじくるものであり、パワポその他 Office でつくるような文書はほぼ装飾です。LLM にとっては邪魔以外の何者でもありません。装飾は取り除く。これだけでもだいぶ変わります。
次に構造は、論理や強弱を与えるものです。たとえば本記事の見出し構造は以下のようになっていて、
- 「LLMコミュ障」から脱する 2つの原則：LLM Readable と LLM Friendly
- 背景：「人間」だけではなく「AI」とも向き合う時代
- ...
- では、本題に入りましょう
- LLM Readable とは、内容の話
- ...
- ...
私が意図的に構造化したものです。まず背景から与えて、その後本題に入っており、本題の中に小見出し（話題の塊）が並んでいるとの構造になっています。チャットのような非構造な長文を貼り付けるよりも、この方が LLM に意図が通じやすくなります。これらの構造は Markdown 記法で書いており、もっと言えば見出し記法を使っています。ちなみに、見出しという概念は基本的な文章術であり、本や記事などでは見かけると思いますが、書くのは案外難しいです。慣れたら書けます。
と、この単純な構造にも、これだけの意図が詰まっています。LLM に指示を与えるときも、この構造を踏まえてくれるので思い通りの修正がしやすいです。少なくとも「手で直した方が早い」というあるあるからは脱せるようになります。構造は 作者自身が込める意図 であり、適切な文法や定義とともに指定できたら、LLM にも比較的正確に伝わります。構造は無いよりはあったほうが（より正確に意図が伝わるという意味で）良いです。
FAQ
FAQ を生成 AI につくってもらい、私が回答してみました。
- Q1: プロンプトエンジニアリングと何が違うの？
- Ans: Readable も Friendly もプロンプトエンジニアリングの一種と思っていい
- 強いて言えば、Readable も Friendly も「状態」の話であって、目指すものである、くらいか。具体的なテクニックや技法ではない（なので冒頭でも原理原則と書いた）
- Q2: 結局、人間にとっての分かりやすさと同じでは？
- Ans: いいえ
- たとえば LLM 目線では「図表が一つもない設計書」が Friendly かつ Readable だが、人間目線だと理解しづらい。エンジニアでも Mermaid 図や Markdown Table で表を書いたり、はしがち。これらは人間向けのビジュアルを指定するものであって、ロジックそのものを記述する用途には向いていない。ただし、完全に向いていないわけではなく、ロジックを記述する用途としても優れていたり、人間側が書くのに慣れていて書きやすいこともある
- Q3: LLM のモデルやバージョンによって変わるのでは？
- Ans: もちろん変わりうる
- たとえば今のところ LLM というテキストベースのモデルが優勢だが、将来的には VLM も発達してビジュアルも扱えるかもしれない
- Q4: Readable や Friendly は本当に有効なの？
- Ans: 厳密な効果測定は難しい（人間のコミュニケーションと一緒）。繰り返し試してみて効果を感じてほしい。経験的には、人間寄りの書き方を AI に通じさせるよりも、この LLM Readable と Friendly を心がける方が早いと思う（心がけて書けるようにこちらがリスキリングする事も含めて）
おわりに
LLM コミュ障から脱するために、LLM Readable と LLM Friendly、と２つの概念を紹介しました。
この２つをぜひ意識して、AI を使ってみてください。体感の良さが変わってくると思います。
また、よくわからなければ、この内容を AI に与えて壁打ちしてみても良いでしょう。どちらの概念も巷で広く知られているものであり、LLM はすでに十分に学習しています。