「ローカルLLMなら無料でAI使い放題」——この言葉に惹かれて、Ollamaで日本の交通情報を96ページ分一括生成しようとした。結果、存在しない駅を案内され、所要時間は3倍に膨らみ、ありもしない路線を自信満々に提示された。
この記事は、外国人観光客向けの旅行ガイドサイトを運営する中で、各観光地への「Getting There（交通アクセス）」セクションをAIで一括生成しようとした実体験の記録だ。ローカルLLM（Ollama）とクラウドAPI（Gemini）を比較し、どのタスクにローカルLLMが使えて、どこで使えないのかを具体的なデータで示す。
やろうとしたこと
運営している旅行ガイドサイトには、日本各地の観光スポットを紹介する子ページが96ページある。それぞれに「空港からのアクセス」「主要駅からのルート」「所要時間」を含む交通情報セクションを追加したかった。
手作業で96ページ書くのは現実的ではない。そこでAIに一括生成させようと考えた。
[入力] 観光地名 + テンプレート（HTMLフォーマット指示）
│
▼
[LLM] 交通情報を生成（路線名・乗換・所要時間）
│
▼
[出力] HTMLフォーマットの交通アクセスセクション × 96ページ
要求品質は高い。路線名・乗換駅・所要時間が正確でなければ、旅行者を誤った駅や路線に誘導してしまう。「形式が整っていれば中身はそこそこでいい」というタスクではない。
Ollama（ローカル）
7-8B〜70B / 無料
Gemini API（クラウド）
Flash / 96ページで約7円
テスト環境
| 項目 | 内容 |
|---|---|
| マシン | MacBook Pro M Max / 統合メモリ64GB |
| ローカルLLMエンジン | Ollama |
| テストしたローカルモデル | llama3.1:8b / qwen2.5:7b / mistral:latest / llama3.1:70b / llama3.3:70b |
| クラウドAPI | Gemini 2.0 Flash / Gemini 2.5 Flash |
| テストケース | 嵐山（Arashiyama）への交通アクセス |
嵐山を選んだ理由は、アクセス手段が複数あり（JR・阪急・嵐電の3駅）、空港からのルートも複雑で、LLMの「知識の正確さ」を測るのに最適だからだ。
嵐山への正しいルート（検証用の正解データ）
- 関西空港(KIX) → JR特急はるか → 京都駅 → JR嵯峨野線 → 嵯峨嵐山駅（約90分）
- 伊丹空港(ITM) → 大阪モノレール → 蛍池 → 阪急宝塚線で乗換（JRではない）
- 京都駅 → JR嵯峨野線 → 嵯峨嵐山駅（約15分）
- 嵐山には3つの駅がある: JR嵯峨嵐山、阪急嵐山、嵐電（京福）嵐山
- 伊丹空港には鉄道駅が直結していない（モノレールで蛍池まで行く必要がある）
これらの事実を正しく出力できるかどうかが、各モデルの評価基準になる。
具体例1: 伊丹空港に架空の鉄道路線が生えた
まず最初に衝撃を受けたのがこれだ。テストした全ての7-8Bモデルが、伊丹空港の交通アクセスを捏造した。
| モデル | 伊丹空港からのアクセス（AIの出力） | 判定 |
|---|---|---|
| llama3.1:8b | 「北大阪急行で伊丹空港駅」 | ❌ 捏造 |
| qwen2.5:7b | 「京阪本線で伊丹空港から」 | ❌ 捏造 |
| mistral:latest | 「南海空港急行で伊丹駅」 | ❌ 捏造 |
| 正解 | 大阪モノレール → 蛍池 → 阪急宝塚線 | ✔ |
全滅だ。
北大阪急行は御堂筋線の延伸で、伊丹空港には行かない。京阪本線は京阪間の路線で、空港とは無関係。南海空港急行は関西空港（KIX）専用で、伊丹（ITM）には対応していない。
どのモデルも「それっぽい鉄道会社名」を使って、存在しない接続を自信満々に生成している。HTMLフォーマットは完璧に守っているのが余計にタチが悪い。形式が整っているから、一見すると正しい情報に見えてしまう。
「形式は完璧だが内容が虚偽」——もしこのまま公開していたら、外国人旅行者が存在しない「伊丹空港駅」を探して途方に暮れることになる。AIが生成した情報を人間がチェックせずに公開する怖さを実感した瞬間だった。
ちなみに、70Bモデル（llama3.1:70b, llama3.3:70b）は「モノレール → 蛍池」まで正解したが、蛍池からの乗換先を阪急ではなく「JR神戸線」と誤記した。大幅に改善はするが、100%は信頼できない。
具体例2: 大阪から嵐山へ「嵯峨野線で直通」——地理を理解していない
llama3.1:8bは、大阪駅から嵐山へのルートとして「JR嵯峨野線で直通」と出力した。
これは完全に間違いだ。JR嵯峨野線は京都駅が始発で、大阪駅からは乗れない。大阪から嵐山に行くには、まずJR京都線で京都駅に行き、そこで嵯峨野線に乗り換える必要がある。
大阪駅 ──JR嵯峨野線で直通──→ 嵯峨嵐山駅
// 実際の正しいルート
大阪駅 ──JR京都線──→ 京都駅 ──JR嵯峨野線──→ 嵯峨嵐山駅
さらにひどいのはqwen2.5:7bだ。「御堂筋線で大阪から京都駅」と出力したが、御堂筋線は大阪市内の地下鉄であり、京都には行かない。
mistral:latestは「新幹線で新大阪から京都」を提案した。たった1駅の移動に新幹線を勧めるのは、間違いではないが非現実的だ（JR京都線で30分、新幹線で15分。特急料金を考えると合理的ではない）。
| モデル | 大阪→嵐山のルート | 判定 |
|---|---|---|
| llama3.1:8b | JR嵯峨野線で直通 | ❌ |
| qwen2.5:7b | 御堂筋線で京都駅 | ❌ |
| mistral:latest | 新幹線で新大阪→京都 | ⚠️ |
| llama3.1:70b | ルートは正解（ただしJR神戸線と誤記） | ⚠️ |
この例が示しているのは、7-8Bモデルには「どの路線がどこを走っているか」という空間的・地理的な知識が欠落しているということだ。「嵯峨野線」「御堂筋線」という路線名自体は知っているが、それがどの区間を走る路線なのかを正確に把握していない。
具体例3: 京都→嵐山15分を「45分」——最もシンプルなルートすら間違える
3つ目の例は、より衝撃的かもしれない。
京都駅からJR嵯峨野線で嵯峨嵐山駅まで、実際の所要時間は約15分だ。嵐山観光で最も基本的なルートであり、乗換なしの直通。これを間違えるモデルがあるとは思わなかった。
| モデル | サイズ | 京都→嵐山の所要時間 | 実際との乖離 |
|---|---|---|---|
| llama3.1:8b | 4.6GB | 30〜40分 | 2〜2.7倍 |
| llama3.1:70b | 42GB | 15〜20分 | ほぼ正確 |
| llama3.3:70b | 42GB | 45分 | 3倍 |
| Gemini 2.5 Flash | クラウド | 15〜20分 | ほぼ正確 |
| 正解 | — | 約15分 | — |
特に注目すべきはllama3.3:70bだ。llama3.1:70bの後継モデルであり、多くのベンチマークで改善が報告されている。にもかかわらず、京都→嵐山という最も基本的なルートの所要時間を実際の3倍に誤記した。
llama3.3:70bは嵯峨野線の別名（山陰本線）を正しく記載するなど、情報量は3.1より多い面もあった。しかし最も基本的な所要時間で致命的な誤りを出した。モデル選定はベンチマークスコアではなく、自分のタスクでの実測が必須だという教訓。
70Bモデルで劇的改善、しかし代償が大きい
7-8Bモデルの惨状を見て、42GBのllama3.1:70bを試した。結果は別次元の改善だった。
- 関西空港 → はるか → 京都 → 嵯峨野線: 正確
- 伊丹空港 → モノレール → 蛍池: ほぼ正確（乗換先の路線名に誤りあり）
- 京都→嵐山: 15〜20分で正確
捏造の質が「存在しない駅の創作」から「路線の通称ズレ」レベルに低下した。しかし代償も大きい。
| 項目 | 7-8Bモデル | 70Bモデル |
|---|---|---|
| メモリ使用量 | 4〜5GB | 42GB（64GB中の66%を占有） |
| 生成速度 | 10〜41秒/ページ | 約165秒（約3分）/ページ |
| 96ページ処理時間 | 16分〜1時間 | 約4.5時間 |
| 他の作業への影響 | ほぼなし | ブラウザ数タブでスワップ発生 |
| 阪急嵐山線・嵐電の記載 | なし（0/3駅） | なし（0/3駅） |
42GBのモデルが常時メモリに居座るため、70Bモデルの推論中はブラウザのタブを数枚開くだけでスワップが発生する。64GBのMacBook Proですらこの状態だ。
そして精度面では、70Bモデルでも嵐山の3つの駅（JR嵯峨嵐山・阪急嵐山・嵐電嵐山）を網羅できなかった。JRのルートは正確に生成できるが、私鉄（阪急）やローカル鉄道（嵐電）の情報が欠落する。旅行ガイドとしては不十分だ。
Gemini APIの圧勝——速度・精度・コスト全てで上回る
ローカルLLMの限界を感じ、クラウドAPIに切り替えた。まずGemini 2.0 Flash、次にGemini 2.5 Flashをテストした。
Gemini 2.5 Flashの出力品質
- 関西空港→嵐山: はるか→京都→嵯峨野線、約90〜100分 ✔
- 伊丹空港→嵐山: リムジンバス→京都駅→嵯峨野線 ✔（有効な代替ルート）
- 京都→嵐山: 15〜20分 ✔
- 阪急嵐山線: 難波→梅田→桂→阪急嵐山 ✔
- 嵐電（京福）: 嵐電嵐山駅を記載 ✔——全テストモデルで唯一
- 難波からのルート: あり ✔
Gemini 2.5 Flashは嵐山の3駅全て（JR嵯峨嵐山・阪急嵐山・嵐電嵐山）を記載した唯一のモデルだった。しかも生成時間はわずか9秒。
総合比較
| モデル | サイズ | 速度 | コスト/ページ | ITM正確性 | 京都→嵐山 | 3駅網羅 | 捏造リスク |
|---|---|---|---|---|---|---|---|
| llama3.1:8b | 4.6GB | 10.6s | $0 | ❌ 捏造 | ❌ 30-40分 | 0/3 | 極めて高 |
| qwen2.5:7b | 4.4GB | 25.4s | $0 | ❌ 捏造 | ⚠️ 路線名違い | 0/3 | 極めて高 |
| mistral:latest | 4.1GB | 41.0s | $0 | ❌ 捏造 | ✔ 20分 | 1/3 | 高 |
| llama3.1:70b | 42GB | 164s | $0 | ⚠️ 乗換先誤り | ✔ 15-20分 | 0/3 | 低 |
| llama3.3:70b | 42GB | 164s | $0 | ✔ バス代替案 | ❌ 45分 | 0/3 | 低〜中 |
| Gemini 2.0 Flash | クラウド | 5s | $0.0004 | ✔ 正確 | △ 20分 | 2/3 | 極めて低 |
| Gemini 2.5 Flash | クラウド | 9s | $0.0005 | ✔ 正確 | ✔ 15-20分 | 3/3 | 極めて低 |
96ページ全量のコスト比較
96ページ × 164秒 = 約4.5時間
メモリ42GB常時占有 + 品質チェック必須
コスト: $0（ただし電気代・時間・メモリ占有の隠れコスト）
// Gemini 2.5 Flash
96ページ × 9秒 = 約15分
コスト: 96 × $0.0005 = $0.048（約7円）
4.5時間+品質不安 vs 15分+高品質で7円。この比較を見れば、日本の交通情報というタスクにおいてクラウドAPIを選ばない理由はない。
なぜローカルLLMは交通情報で失敗するのか
ここまでの結果を踏まえて、なぜローカルLLMが日本の交通情報生成で惨敗したのかを整理する。
1. 事実知識の圧縮限界
7-8Bモデルのパラメータ数（70〜80億）は、世界中の知識を圧縮するには少なすぎる。日本の鉄道網は世界でも最も複雑な部類に入り、関西だけでJR・阪急・阪神・京阪・近鉄・南海・大阪メトロ・京都市営地下鉄・モノレール・嵐電と10以上の事業者が入り乱れる。この複雑さを4〜5GBのモデルに正確に保持するのは原理的に難しい。
2. 推論・計算が必要
交通情報の生成は単純な事実の出力ではない。「関西空港から嵐山」と言われたら、空港→都心部→目的地のルートを組み立てる必要がある。乗換の論理、路線の接続関係、所要時間の加算——これは推論タスクであり、小さなモデルが苦手とする領域だ。
3. 「もっともらしさ」の罠
LLMは次のトークンを予測する仕組みで動いている。「伊丹空港から…」の次に「北大阪急行で」と続けるのは、統計的にはそこそこ自然に見える。しかし事実として間違っている。小さなモデルほど「もっともらしい嘘」を生成しやすい。そしてそれがHTMLの中に埋め込まれると、人間が目視で発見するのが非常に難しくなる。
逆に、ローカルLLMが活躍するタスク
ここまでローカルLLMの限界ばかり書いてきたが、使いどころを間違えなければローカルLLMは十分に実用的だ。ポイントは「事実の正確さ」が求められるかどうか。
✔ 翻訳（元テキストに事実が含まれている）
翻訳タスクでは、正しい情報は入力テキストの中にすでに存在する。LLMがやるべきことは言語を変換することだけで、事実を「知っている」必要がない。
入力: 「嵐山へのアクセスを書いて」
→ LLMが路線名・所要時間を自力で生成する必要がある
→ 捏造リスクあり
// 翻訳（事実は入力に含まれる）
入力: 「京都駅からJR嵯峨野線で約15分」を英訳して
→ LLMは言語を変換するだけ。事実は入力にある
→ 捏造リスクが低い
実際、同じ旅行サイトの多言語化（日本語→英語翻訳）では、7-8Bモデルでも実用的な品質が得られた。原文に含まれる路線名や所要時間はそのまま保持され、文体だけが英語に変換される。翻訳こそローカルLLMの最適な活用領域の一つだ。
✔ HTML整形・フォーマット変換
「このテキストをこのHTMLテンプレートに当てはめて」というタスクは、事実知識を一切必要としない。テンプレートのルールに従って構造を変換するだけだ。
今回のテストでも、全てのモデルがHTMLフォーマットの指示を正確に守っていた。問題は中身の事実が嘘だっただけで、HTMLの構造自体は完璧だった。つまり、正しいデータをあらかじめ用意しておき、それをHTMLに整形するだけなら、7-8Bモデルで十分だ。
✔ プライバシー重視のタスク
クラウドAPIにデータを送信したくない場面は確実に存在する。社内文書の要約、個人情報を含むテキストの処理、機密データの分析——これらはローカルLLMの独壇場だ。精度が多少落ちても、データが外部に出ないことの方が重要な場面は少なくない。
使い分け早見表
| タスク | ローカル 7-8B | ローカル 70B | クラウドAPI |
|---|---|---|---|
| 事実知識が必要な生成（交通・施設） | ❌ | △ 要チェック | ✔ 推奨 |
| 翻訳（事実が元テキストにある） | ○ 検証価値あり | ✔ 十分 | ✔ |
| HTML整形・フォーマット変換 | ✔ 十分 | ✔ | ✔ |
| プライバシー重視のタスク | ✔ | ✔ | ❌ データ送信 |
| オフライン環境 | ✔ | ✔ | ❌ |
Google Routes APIという幻——RAGアプローチの壁
「ローカルLLMの知識が不正確なら、正確なデータをAPIで取得してLLMに整形させればいいのでは？」——いわゆるRAG（Retrieval-Augmented Generation）アプローチだ。
Google Routes API / Directions API で正確な乗換情報を取得し、それをLLMでHTMLに整形する構成を検討した。しかし調査の結果、Google Routes APIは日本の公共交通機関を明示的にサポートしていないことが判明した。
Google Mapsアプリ上では日本の乗換検索が問題なく機能する。しかし開発者向けAPIでは日本の公共交通機関（電車・バス）のルート検索が利用できない。アプリで見えるからといってAPIでも使えるとは限らない——これは盲点だった。
結果として、RAGアプローチは日本の交通情報では実現できなかった。クラウドLLMの内部知識に頼るしかないのが現状だ。
まとめ——「無料」の隠れたコスト
「ローカルLLMは無料」は技術的には正しい。API利用料は発生しない。しかし実際には以下の隠れたコストがある。
- 時間コスト: 70Bモデルで96ページ処理に4.5時間。Geminiなら15分
- 品質コスト: 全出力を人間がファクトチェックする工数。特に7-8Bモデルの出力は事実上ゼロから書き直し
- メモリコスト: 42GBモデルが常駐し、他の作業に支障
- 電気代: M Maxチップが数時間フル稼働する電力消費
一方、Gemini 2.5 Flashは96ページ全量で$0.048（約7円）。缶コーヒー1本より安い。
ローカルLLMとクラウドAPIは敵ではなく、使い分けるものだ。事実の正確さが求められるタスク（交通情報・施設情報・地理データ）はクラウドAPIに任せ、翻訳・HTML整形・プライバシー重視のタスクはローカルLLMで処理する。タスクの性質を見極めて、適材適所で使うのが正解。
| 判断基準 | 推奨 |
|---|---|
| 正確な事実知識が必要 | クラウドAPI（Gemini Flash等） |
| 大量の翻訳・テキスト変換 | ローカルLLM 70B（コスト重視なら7-8Bも可） |
| HTMLテンプレート整形 | ローカルLLM 7-8Bで十分 |
| 機密データの処理 | ローカルLLM一択 |
| 96ページの一括生成 | クラウドAPI（15分 vs 4.5時間） |
ローカルLLMの導入方法や主要ツール（Ollama, LM Studio等）の比較は「ローカルLLM完全ガイド【2026年版】」、AI開発ツールの全体像は「AI開発ツール徹底比較【2026年版】16選」も参考にしてほしい。
この記事の続編として、Geminiのモデルティア別比較（2.5 Flash/Pro、3世代）を「Geminiモデル比較 — 96ページの旅行サイトで2.5 Flash/Pro/3世代を検証した結果」にまとめている。最新情報の反映状況やコスト戦略について詳しく知りたい方はあわせてどうぞ。
コメント