はじめに：「最高モデル」への過信と手痛いしっぺ返し

「よし、一番賢い最高モデルを使って、本気の指示を出そう！」

そう意気込んでAIにデザインやコーディングを依頼し、出てきた成果物にガッカリした経験はないでしょうか？

今回は、私が見事に期待を裏切られたエピソードと、原因を突き止めてプロンプトを修正するまでの一部始終を共有します。

結論から言うと、原因は「AIの性能不足」ではなく「こちらの指示（プロンプト）の解像度」にありました。

この失敗には、AIに何かを「それっぽく」作らせたい人全員に関係する、極めて重要な教訓が含まれています。

目指した理想：複雑で美しい「エグゼクティブ図解」

事の始まりは、銀行の合併・再編の歴史をまとめた「エグゼクティブ図解」を見たことでした。

三菱UFJフィナンシャル・グループの沿革を示すあの図——複数の銀行が時系列に沿って何度も合併・改称を繰り返し、その過程が曲線コネクタで美しく繋がっていく、あの情報密度の高いビジネス資料です。

「これをHTML/CSSの進化史で応用すれば、最強のコンテンツになる！」

HTMLの仕様、CSSの仕様、JSやツールの潮流。それぞれが独自に進化し、時に影響し合いながら、最終的に「現在のビジュアルトレンド」に収束していく。これは銀行の系譜図と全く同じ構造で描けるはずだと確信しました。

そこで、海外の最先端デザイン（ダークモード、グラスモーフィズム、流体グラデーションなど）の情報をインプットした上で、最高モデルのAIにこう発注したのです。

「三菱UFJの歴史図解ぐらい超作り込んだマップを、HTML/CSSの歴史バージョンで作って！触ったら動くぐらいのハイクオリティで！」

かなりの熱量を込めた、本気のプロンプトでした。

現実：AIが逃げた「安全で大味な」タイムライン

数分後、AIから届いたZIPファイルを期待に胸を膨らませて開き……正直、がっかりしました。

出来上がっていたのは、1990s → 2000s → 2010s → 2026年という、たった4つの「駅」を持つ一本道の蛇行タイムラインだったのです。

SVGの光る線で駅と駅を結ぶ演出自体は悪くありません。しかし、私が参考にした系譜図が持っていた「何本もの横並びのレーン」「正確な年表軸」「合併を示す曲線コネクタ」「凡例」といった圧倒的な情報密度は、跡形もありませんでした。

ビジュアルトレンドのサンプル部分はそれなりに良い出来だっただけに、肝心の「図解」部分のひどく大味な作りが余計に悪目立ちします。チープとまでは言いませんが、明らかに手を抜いたような、期待の半分にも届かない仕上がりでした。

なぜAIは期待を裏切ったのか？（原因分析）

実際にコードを解剖してみて、原因がはっきりしました。

AIが作ってきたのは、一本の線を蛇行させて途中に節目のカードを置く「サブウェイ（路線図）パターン」でした。これは、ストーリーテリング系のWebサイトでよく使われる、AIにとって非常に「使い慣れた・書きやすい」テンプレートです。

一方、私が本当に欲しかった「エグゼクティブ図解」は、全く別の設計思想でできています。

• エンティティごとに専用の「横レーン」を持つ
• 正確な「西暦の目盛り（X軸）」に沿って配置される
• レーン同士を結ぶ「曲線コネクタ」と「凡例」がある

これは「雰囲気」の話ではなく、「情報構造」の話です。

つまり私は、プロンプトの中で「ダークモード」「グラスモーフィズム」といったビジュアルの雰囲気は事細かに指定していたのに、「データ構造そのもの」は一切指定していなかったのです。

AIからすれば、雰囲気は指定通りに作れても、構造は「すごいのを作って！」という曖昧な熱量から推測するしかありません。そして構造が曖昧なまま丸投げされたAIは、自分が一番慣れていて、実装コスト（計算量）が最も低い「安全なパターン（＝1本道タイムライン）」へと逃げたのです。これは性能の限界ではなく、私の指示の解像度の問題でした。

【解決策】プロンプトの解像度を上げる3つのポイント

この失敗を踏まえ、プロンプトを以下の3点に絞って徹底的に修正しました。

1. 「雰囲気」より先に「構造」を定義する

「ダークモードで」と指示する前に、「4本の横レーンを設け、年表軸を横方向に固定し、レーンをまたぐ関係は曲線コネクタで結び、凡例を置く」という、絶対に譲れない構造要件を最初に明記しました。

2. 「実データ」は人間が用意して渡す

AIに「何を並べるか」まで考えさせると、必ず楽をします。「HTML・CSS・JS/ツール・ビジュアル潮流」という4レーン分の年表データを、こちらで実際に十数件ずつ調べてリスト化し、インプットとして渡しました。これにより「4駅しかない大味なタイムライン」ではなく、最初から「密度の高い系譜図」を作る土台を強制します。

3. 「実装の方針（ロジック）」まで強制する

「ノードを手作業の絶対座標（absolute）で置くのではなく、データ配列から座標を計算するプログラムとして実装すること」と明記しました。ここを指定しないと、複数レーン×曲線の複雑な構造を組む労力を嫌がり、またしても簡易パターンに逃げられてしまうからです。

まとめ：AIを動かすのは「熱量」ではなく「構造を分解する力」

今回の最大の学びは、「AIに”あの有名な資料みたいに作って”と頼むだけでは、雰囲気は真似できても構造は再現されない」ということです。

質の高いアウトプットを引き出すには、憧れの完成形を見せて熱量で語るだけでなく、その完成形がどういう構造（骨組み）でできているかを自分の言葉で分解し、データとして渡す必要があります。

逆に言えば、この「分解する力」さえ身につければ、AIの実力を今の何倍も引き出せるということです。

次回は、この修正版プロンプトで実際に作成した「HTML/CSS進化史のエグゼクティブ図解」の、驚くべきBefore/Afterを公開します！

覚えていたら多分・・・

まぁめっちゃいい事思いついたと思った時にあまりに結果のギャップがあると悲しいですよねというお話でした