生成AI（大規模言語モデル）を業務やプロダクト開発に組み込む際、「AIになかなか思い通りの出力をしてもらえない」「指示文（プロンプト）をどう工夫しても、複雑なタスクだとクオリティが安定しない」といった悩みに直面したことはありませんか？
AIを活用して望む結果を得るための技術を「プロンプトエンジニアリング」と呼びます。かつては「いかにAIへの命令文（プロンプt）をうまく書くか」という言葉の選び方が中心でした。しかし最新のAIモデルでは、プロンプトのテキスト表現だけでなく、AIが回答を作成する際に「どれだけ深く内部で思考・計算するか」という設定（推論レベル／Reasoning level）の制御が欠かせないな要素になってきています。
技術ブロガーでありエンジニアのSimon Willison（サイモン・ウィリソン）氏は、最新のAIモデル「GPT-6 Astra」へのアクセス権を得た際、非常に興味深い検証を行いました。それは「自転車に乗るペリカンの絵」を、ベクター画像フォーマットであるSVGコードとして生成させるという実験です。彼はAIの思考レベル（Reasoning level）を「low（低）」「medium（中）」「high（高）」「xhigh（超高）」「max（最大）」の5段階に切り替え、それぞれの出力結果を並べて比較（グリッド表示）しました。
一見すると「ペリカンが自転車に乗る絵を描かせる」というのはユニークで遊び心のある実験に見えるかもしれません。しかし、プログラミングコードで画像を正確に記述させるというタスクは、AIの空間認識力、論理的思考力、コード生成能力を総合的に推し量る絶好のベンチマーク（性能評価）なのです。
本記事では、この「ペリカンSVG比較実験」の背景と知見をベースに、プロンプトエンジニアリングを実務システムへ導入・設計・運用するための具体的なガイドをわかりやすく解説します。専門用語も平易に言い換えてお届けしますので、ぜひ自社のAI活用やプロダクト開発のヒントとしてお役立てください。
1. なぜ「自転車に乗るペリカン」なのか？事例の背景とプロンプトエンジニアリングの最前線
まずは、今回取り上げる検証の一次情報と、プロンプトエンジニアリングにおける最新トレンドの関係について整理しましょう。
Simon Willison氏による検証の概要
Simon Willison氏は、「GPT-6 Astra」において「自転車に乗るペリカン（pelicans riding bicycles）」というテーマでSVG形式の画像コードを生成させました。その際、思考レベル（Reasoning level）をパラメータとして以下のように変動させて出力結果を比較しました。
- low（低）
- medium（中）
- high（高）
- xhigh（超高）
- max（最大）
なお、GPT-6 Astraでは「思考なし（reasoning=none）」という設定はサポートされていません。生成されたコードをブラウザ上で描画し、一覧（グリッド）として比較することで、思考レベルの上昇に伴う出力の精度や表現力の変化を視覚的に観察したのです。
専門用語の解説
ここで登場する重要な専門用語を、実務初心者向けに整理しておきましょう。
- プロンプトエンジニアリング（Prompt Engineering）： 生成AIに対して適切な指示（プロンプト）、背景情報、パラメータ設定を与え、業務や目的に合致した高精度な出力を引き出すための設計手法やアプローチ全般のことです。
- SVG（Scalable Vector Graphics）： 画像を点で塗るピクセル形式（JPEGやPNGなど）ではなく、線や円、色などの計算式（プログラミングコード）で記述する画像フォーマットです。拡大しても画像が荒れない特徴があります。AIにSVGを作らせるということは、文章ではなく「正しく動くコード」を書かせることを意味します。
- 推論レベル／思考レベル（Reasoning Level）： AIがユーザーからの指示に対して、即座に言葉を紡ぎ出すのし、裏側で論理立てて思考ステップを踏んでから回答を出力する強さ・深さの程度を指します。
なぜペリカンと自転車のSVG生成が難関なのか？
AIにとって、「ペリカン」という鳥の特徴（大きなクチバシや丸みのある体）と、「自転車」という複雑な機械の構造（2つの車輪、フレーム、ハンドル、サドル、ペダル）を理解し、それらを「ペリカンがサドルに座り、ペダルに足を乗せている」という正しい位置関係で座標計算を行ってSVGコード化することは非常に高難度なタスクです。
思考レベルが低い場合、車輪と体が分離してしまったり、ペリカンの形が崩れてしまったりすることが少なくありません。しかし思考レベルを上げるにつれて、AIは内部で「まずサドルの位置を計算し、そこにペリカンの胴体を配置し、足からペダルへ線を伸ばす」といった論理的な組み立てを行うようになります。
この事例は、単なる画像描画の実験にとどまらず、「複雑なビジネスロジックや計算、構造化データの生成において、思考レベルの設定がどれほど結果に影響を与えるか」を示す象徴的なケースなのです。
2. 実務で活かすプロンプトエンジニアリングの導入・設計ガイド
この実験で得られた知見を、実際に業務システムやAIプロダクトへ導入・設計する際のガイドラインとして応用してみましょう。プロンプトエンジニアリングを実務で成功させるためには、以下の3つのステップで設計を進めることが重要です。
ステップ1：タスクの難易度に合わせた思考レベルの選定
AIを活用するタスクは、すべてが最高精度の思考を必要とするわけではありません。
- 定型的なタスク（低〜中思考レベルで十分な例）：
- 文章の要約や文法チェック
- 決まったフォーマットへのテキスト変換
- 短い問い合わせに対する一次回答
- メリット： 応答スピードが速く、API利用料金（コスト）を極めて安く抑えられます。
- 複雑・構造化タスク（高〜最大思考レベルが必要な例）：
- SVG画像生成や複雑なプログラミングコードの作成
- 複数の条件が絡み合う契約書の検証・論理チェック
- 複雑な財務データや統計データの多角的分析
- メリット： 破綻のない高度なロジックや正確な構造化出力が得られます。
実務設計では、すべての処理を最高レベル（max）にするのではなく、「処理の複雑さ」に応じて動的に思考レベルを切り替える設計が求められます。
ステップ2：システムプロンプトとパラメータの統合設計
プロンプトエンジニアリングは、プロンプトの「文章」だけでは完結しません。モデルの「設定パラメータ（思考レベルや出力温度など）」とセットで設計します。
- 指示文（プロンプト）の役割： 何を作るか（役割、制約条件、出力フォーマット）を明確に指定する。
- 思考レベル（Reasoning）の役割： 指示を実現するために、どれだけの思考リソースをAIに割かせるかを決定する。
例えば、「複雑なSVGアイコンを生成するプロンプト」を作成する場合、文章でどれほど「正確に描いてください」と強調しても、思考レベルが低ければ限界があります。逆に、プロンプトの文章をシンプルにしつつ、思考レベルを「high」や「xhigh」に設定することで、AIが自律的に整合性を計算して高品質なコードを出力してくれるようになります。
ステップ3：評価グリッド（比較検証環境）の構築
Simon Willison氏がペリカンのSVGをグリッド状（一覧）に並べて評価したように、プロダクト開発においても**「出力結果を比較評価する仕組み」**をあらかじめ用意することが欠かせません。
- 同一のプロンプトに対して、思考レベル（low, medium, high, xhigh, max）ごとの出力を保存する。
- 生成結果の品質、応答時間（レイテンシ）、発生コスト（使用トークン数）をマトリクス（表）にして比較する。
- 自社のサービスとして許容できる「品質・速度・コスト」の最良バランス点（スイートスポット）を特定する。
このような実験・検証環境を自社内に持つことこそが、実務におけるプロンプトエンジニアリングの核となります。
3. 実運用における注意点とトラブルシューティング
AIモデルの思考レベルを活用したシステムを運用するにあたっては、いくつかの落とし穴や注意点が存在します。導入後に慌てないよう、以下のポイントを把握しておきましょう。
注意点1：思考レベルを上げることによる「コスト」と「遅延」の急増
思考レベルを「high」や「max」に設定すると、AIは回答を出力する前に内部で大量の「思考用トークン（思考のプロセス）」を生成します。
- 応答時間の長期化（レイテンシの問題）： ユーザーがWeb画面でボタンを押してから結果が表示されるまでに数秒〜数十秒の待ち時間が発生する可能性があります。リアルタイムなチャットボットなどで「max」を使用すると、ユーザー体験を損なうリスクがあります。
- API利用コストの増加： 多くのAIサービスでは、生成されたトークン数に応じて課金されます。内部での思考プロセスも課金対象となる場合が多いため、思考レベルを「max」に設定し続けると、コストが数倍〜数十倍に跳ね上がることがあります。
【対策】 バックグラウンド処理（非同期処理）が可能なタスク（夜間バッチ処理やレポート自動生成など）には高思考レベルを使い、ユーザーが画面前で待つリアルタイム処理には適切なレベル（low〜medium）を選択する、あるいは進捗インジケーターを表示するなどのUI/UXの工夫が必要です。
注意点2：「思考なし（reasoning=none）」非対応モデルへの配慮
GPT-6 Astraのように「思考なし（reasoning=none）」がサポートされていないモデルを利用する場合、もっとも低い設定である「low」にしても、一定の思考ステップとわずかなオーバーヘッドが発生します。
超高速なレスポンスが求められる極めてシンプルなタスク（例：「はい」「いいえ」の二値判定など）において、こうした思考付きモデルを使用すると、オーバーペック（過剰性能）となり効率が悪くなる可能性があります。
【対策】 タスクの性質に応じて、思考プロセスを持たない軽量な従来型モデルと、思考レベルを調整できる最新モデル（GPT-6 Astraなど）をシステム側でルーティング（振り分け）するアーキテクチャを検討してください。
未確認事項についての注意
なお、一次情報源においては、GPT-6 Astraの内部アーキテクチャの全容や、各思考レベルにおける詳細なアルゴリズムの相違、具体的なSVGコードの行数・トークン数の詳細数値までは公開されておらず、未確認です。実際の導入時には、ご自身が利用する環境の最新公式ドキュメントやAPI仕様を確認のうえ、実測値を計測することをおすすめします。
注意点3：視覚的・構造的成果物の自動テスト化
SVGやプログラミングコード、JSONなどの構造化データを生成させる場合、AIの思考レベルが高くても、稀に文法エラーや表示の崩れが発生することがあります。
運用時には、AIが生成したSVGやコードをそのままエンドユーザーに届けるのし、必ず「レンダリングテスト（描画チェック）」や「構文チェック（バリデーション）」を自動で挟むシステム構成にすることが推奨されます。
4. まとめ：プロンプトエンジニアリングは「パラメータと目的の最適バランス」を探る旅
Simon Willison氏による「GPT-6 Astraを使った自転車に乗るペリカンのSVG比較実験」は、最新AIの性能とプロンプトエンジニアリングの新しいあり方を分かりやすく示してくれました。
今回の要点を改めて振り返りましょう。
- プロンプトエンジニアリングの進化： 指示文（テキスト）の工夫だけでなく、AIの「思考レベル（Reasoning level）」などのパラメータを適切にコントロールすることが成果物の品質を左右します。
- タスクに応じた適切なレベル設定： SVGコード生成のような複雑で空間的・論理的な理解が求められるタスクでは、高い思考レベル（high〜max）が威力を発揮します。一方で、定型処理には低い思考レベル（low〜medium）が適しています。
- コスト・速度・品質のトレードオフ管理： 実務運用では、品質だけでなく「応答時間」や「API利用コスト」とのバランスを見極め、システム構成やUI/UXも含めて設計することが成功の鍵となります。
プロンプトエンジニアリングは、単に「AIに命令する」作業から、「AIの思考能力を正しく見積もり、システム全体として最適なパフォーマンスを引き出す設計技術」へと変化しています。
「ペリカンが自転車に乗る絵」という一見ポップな実験の裏にある本質的な知見を活かし、ぜひ皆さんのプロジェクトでも、AIの思考レベルを意識した実効性の高いプロンプトエンジニアリングに取り組んでみてください。