四国遍路の行程設計で生成AIを競わせたら、勝敗を分けたのは「賢さ」ではなかった
Nick/野村です。四国八十八ヶ所を、クルマで回っています。事情があって8月中に残り58ヶ寺を打ち切る行程が必要になり、その計画をAIと一緒に詰めていたのですが、ふと思いつきました。同じ課題を、他の生成AIに投げたらどうなるのか。
やってみたら、思いのほか綺麗に差が出ました。しかもその差は「モデルの賢さ」の差ではなかった、という話です。
課題：58ヶ寺の区切り打ち計画
お題は実在の、私自身の計画です。四国八十八ヶ所のうち、参拝回数が揃っていない58ヶ寺を、8月11日開始で打ち切る。制約も全部本物です。
・納経所の受付は8:00〜17:00
・車は全長5,080mm×全高2,285mmのハイルーフ（平面駐車場しか入れない）
・実績ペースは1日7〜8ヶ寺、朝8時に打ち始めてだんだん加速するタイプ
・夜間の移動は可
・巡拝完了後、X番札所で公認先達の推薦相談。申請期限は8月末
このお題をプロンプトに固めて、ChatGPT、Gemini、Kimiに同一条件で投げました。ひとつだけ意地悪を仕込んであります。この時期・この土地に固有のリスク——お盆、山の日、そして高知のよさこい祭り——は、プロンプトに一切書かない。 自力で気づけるか、というテストです。
なお比較対象として、私と数週間この計画を詰めてきたClaude（公式の札所間距離データ、私の過去の実走ログ、難所の運用実績を全部持っている状態）がいます。条件が違いすぎるので同列の順位付けはしませんが、「コンテクストの有無で何が変わるか」の対照群として置きました。
結果：全員、検算だけは満点だった
まず面白かったのはここです。58ヶ寺の集合演算——「対象は10〜21、23、24〜39、53、61〜65、66〜88で、合計58。対象外の30ヶ寺は含まない」——は、3モデルとも完璧でした。 番号の足し算で間違えたモデルはひとつもない。5年前の生成AIを知っている身としては、隔世の感があります。
差が出たのは、その先でした。
ChatGPTは、堅牢でした。9日間というやや保守的な構成を選び、破綻する日を作らない。特筆すべきは、35番清瀧寺——最後の1kmが極狭で、5m超の車では入るべきでない札所——について「自走を推奨しない。麓に駐めてタクシー往復」と正しく判断したこと。これは私が実際にやっている運用と同じです。さらに「8月11日は山の日で混雑する」を自力で検出し（私も見落としていました）、申請書類が寺経由で霊場会に回付される時間を見込んで「実質締切を8月24日に置く」という実務の裏読みまでやってのけた。汎用知識だけでここまで来るのか、というのが正直な感想です。
Geminiは、文書としては一番立派でした。検算の体裁、難所対策の表、リスク整理。ただし2日目に、徳島の5ヶ寺と山岳2ヶ所を消化した後、75km先の室戸岬まで走って夕方に3ヶ寺打つ、という行程が入っていました。この区間は実測で約2時間。計画のまま走ると、最後の札所で納経受付17:00に間に合いません。つまり、綺麗な計画書の中に、実走すると破綻する一日が埋まっている。 清瀧寺も「離合信号に従って自走」でした。5m車では、たぶん泣きます。
Kimiは、一番考えました。推論の途中経過を見ていると中国語と英語と日本語が混ざり、札所のことを「八十八駅」と呼んだりする。そして唯一、自分でWeb検索をかけて「2026年のよさこい祭りの日程」を取りに行きました。固有リスクの発見という点では検出率最高です。ところが、組み上がった行程は地理が歪んでいました。土佐市から足摺岬を回って愛媛の西条まで、走行だけで9時間かかる区間を1日に押し込む。宿泊地が進行方向と逆に戻る日が2回。存在しないアクセスルートをひとつ発明。情報は取れたのに、それを載せる地図の骨格が壊れていた。 ちなみに山の日は8月15日と誤記していました（正しくは8月11日、行程の初日です）。
勝敗を分けたもの
整理すると、こうなります。
・番号の集合演算、文書構成、自己検算 → 全員できる
・「土佐市と安芸市の位置関係」「その道に5m車で入れるか」「その日その町で祭りがあるか」 → ここで全員転んだ（転び方に個性はあれど）
そしてClaudeが私の計画で上記を全部回避できていたのは、Claudeが賢いからでは、たぶんありません。公式の札所間距離表、6月に私が実走したときのペース記録、「清瀧寺はタクシー」という過去の意思決定、車検証の実寸——私のコンテクストを持っていたからです。逆に言えば、それを持たないモデルに同じ結果を期待するのは酷で、冷静に考えれば「ま、こんなもん」なのです。
（利益相反の開示：この採点をやったのはClaude本人です。適宜割り引いてお読みください。）
ビジネスへの翻訳
この実験、遍路の話に見えて、実は仕事でAIを使うときの構図の縮図だと思っています。
汎用性能の差は、もう小さい。どのモデルも計算し、構成し、検算します。成果を分けるのは、距離表にあたる社内データ、実走ログにあたる業務実績、「あの道は入れない」にあたる過去の意思決定を、AIに渡せているか。つまり「どのモデルを選ぶか」より「どこにコンテクストを蓄積し、どう渡すか」の設計のほうが、成果への寄与がずっと大きい。
モデルは代替可能になりつつあります。代替が利かないのは、あなたの組織の距離表と実走ログのほうです。
え、それで結局どのAIと契約すべきかって？——コンテクストを渡せる仕組みを作ってから考えましょう、が私の答えです。
（この記事の行程計画は実際に8月に走る予定です。結果はまた書きます。）