生成AIは自然言語を巧みに操りますが、そのままでは人間にとって理解しやすい形にはなりません。会話としては成立していても、「一覧表」「箇条書き」「グラフ」といった構造が欠けることで、判断や意思決定に使いづらい場面が多く残ります。特にRailsプロジェクトにLlama3:8BのようなローカルLLMを組み込む場合、この問題は顕著です。本稿では、RAGの役割を整理したうえで、AIに“表でまとめさせる”ために不可欠な「出力契約（JSONスキーマ）」という考え方を解説します。さらに、グラフ表示を含む一連の処理を、AIとアプリケーションの役割分担という観点から捉え直します。生成AIを「話す存在」から「整形する存在」へと進化させるための設計思想を、実装経験を踏まえて論じます。
AIは「理解しやすい形」を自動では生まない
Llama3:8Bをはじめとする多くのLLMは高品質な文章を生成できますが、その自由度の高さゆえに、数値や比較軸が曖昧になりやすいという課題があります。これはモデル性能の不足ではなく、出力形式が与えられていないことに起因します。一方、人間は表や箇条書きなど構造化された情報によって初めて内容を正確に理解します。AIを実務で活用するには、文章の流暢さよりも、理解を前提とした構造設計を重視する必要があります。
自然言語生成の限界と曖昧さ
Llama3:8Bを含む多くのLLMは、文章生成には非常に優れています。しかし、自由度の高さは同時に曖昧さも生みます。重要な数値が文中に埋もれたり、比較の軸が不明確になったりすることで、読み手が再解釈を強いられる場面が少なくありません。これはモデルの性能不足ではなく、「出力形式が指定されていない」ことに起因します。
人間は構造で理解する
人間は本来、表や箇条書き、グラフといった構造を通じて情報を把握します。列が揃い、数値が比較可能な状態になることで、初めて意味が立ち上がります。したがってAIを実務で使うには、自然言語の流暢さよりも、構造化された出力を優先する設計が不可欠になります。
出力契約（JSONスキーマ）という発想
LLMは流暢な文章生成を得意としますが、出力形式を指定しなければ、重要な数値や比較軸が曖昧になりがちです。これは性能の問題ではなく、構造が与えられていないことに起因します。一方、人間は表や箇条書きなど整理された形で初めて情報を正確に理解します。実務でAIを活用するには、文章の自然さよりも、構造化された出力を意図的に設計する視点が不可欠です。
LLMに役割を限定する
出力契約とは、「AIはこの形式でしか答えてはいけない」という明示的な取り決めです。JSONスキーマを用いることで、AIの役割は「推論や装飾」ではなく、「与えられた情報を決められた形に整形すること」へと限定されます。これにより出力の再現性と検証可能性が飛躍的に高まります。
表・箇条書き・グラフはJSONから生まれる
JSONには、要約文、箇条書き配列、テーブル用の行データ、グラフ用の数値系列を同時に格納できます。Rails側はそれを検証し、HTMLテーブルやChart.jsなどで描画するだけです。重要なのは、AIに描画させないことです。AIは数値と構造だけを返し、見た目はアプリケーションが責任を持つ。この分離が安定運用の鍵となります。
RAGとRailsが担う「現実との接続」
RAGは“材料係”である
RAG（Retrieval Augmented Generation）は、表やグラフを生み出す魔法ではありません。その役割は、正確な文章や数値をAIに渡すことです。実際の集計や抽出は、可能な限りRails側やDBで行い、AIには「整理」と「要約」だけを任せる方が結果は安定します。
Railsが最終的な理解を作る
JSONを検証し、表として整形し、グラフとして可視化するのはRailsの仕事です。AIはあくまで中間工程に過ぎません。この設計により、AIが多少揺らいでも、ユーザーに提示される情報の品質は保たれます。生成AIを業務システムに組み込むとは、こうした責務分離を設計することに他なりません。
まとめ
生成AIに「表でまとめさせる」ことは、単なるプロンプト技術ではありません。それは、AIとアプリケーションの役割を明確に分離し、情報を構造として扱うという設計思想の問題です。Llama3:8Bは文章生成に優れていますが、自由に語らせるほど実務からは遠ざかります。JSONスキーマという出力契約を設け、RAGで正しい材料を供給し、Railsで検証と描画を行う。この流れを確立して初めて、AIは「会話相手」から「業務を支える整理者」へと変わります。表やグラフが自動的に生まれる仕組みとは、AIを賢くすることではなく、人間側が構造を設計することなのです。
