AIプロダクトはコードより先に会話を設計する

いま作るべきものは「AI機能」ではなく、「AIとの往復が成立する器」

AIや画像生成を使ったサービスを作ろうとすると、多くの人はまず計算資源やモデル選定に目を向けます。GPUはどこで借りるか、どのクラウドが安いか、画像生成の推論をどうさばくか。もちろん重要です。けれど、もっと見落とされがちな問いがあります。そのAIは、ユーザーとの会話の中で本当に賢く振る舞えるように設計されているか。

ここに、AIプロダクトの本質的な分岐があります。ひとつは、インフラを最適化する視点。もうひとつは、プロンプトを設計する視点です。一見別物ですが、実は同じ問題を別の階層から見ています。前者はAIが走るための「体力」を作り、後者はAIが能力を発揮するための「知性の型」を作る。どちらか片方だけでは、プロダクトは驚くほど脆くなります。

AIサービスの競争力は、モデルの賢さだけでは決まらない。モデルが何をするかを決める会話の設計と、それを破綻なく運ぶ基盤の設計が揃って初めて、体験になる。

---

なぜ「良いモデル」を使っても失敗するのか

多くの人が最初に陥る誤解は、AIの性能はモデルの性能に比例するという考え方です。ところが実際には、同じモデルを使っても、あるサービスでは驚くほど使いやすく、別のサービスではただの気まぐれな自動応答に見えます。その差を生むのは、モデルそのものより、むしろ周辺の設計です。

たとえば画像生成サービスを考えてみてください。ユーザーは「かっこいいロゴを作って」と入力します。ここで必要なのは、単に生成APIを叩くことではありません。色味、用途、ブランドの性格、解像度、禁止事項、出力形式などを整理し、曖昧な願望をモデルが扱える指示に変換する必要があります。つまり、プロンプトは入力欄に見えて、実際には要件定義の圧縮版なのです。

このとき重要なのは、プロンプトエンジニアリングを「小手先の言い換えテクニック」と見なさないことです。明確な指示、コンテキスト追加、例示、ペルソナ、step by step、出力構造、接頭辞、XMLタグ。これらは単なるコツではなく、曖昧な人間の意図を機械が誤解しない形式へ変換するための文法です。

そしてこの文法は、インフラ設計と切り離せません。なぜなら、会話を丁寧に設計するほど、呼び出し回数は増え、状態管理は複雑になり、生成失敗時のリトライや待ち時間も増えるからです。逆に、基盤が貧弱だと、どれだけ優れたプロンプトを組んでも体験は崩れます。良い会話は、安定した実行環境があって初めて持続します。

---

プロンプトは命令文ではなく、UIである

ここで視点をひとつ変えてみましょう。多くの人はプロンプトを「AIへの指示文」と考えます。けれど本質はもっと近いところにあります。プロンプトは、モデルに対するUIです。

人間向けのUIが優れているとは、単に見た目が美しいことではありません。迷わないこと、誤操作しにくいこと、意図した行動を引き出せることです。プロンプトも同じです。よいプロンプトは、モデルに自由を与えるのではなく、自由の輪郭を与えます。

たとえば、次のような違いを考えてみてください。

• 「要約して」
• 「以下の文章を、経営層向けに3点で要約し、各点に数字を含めて、最後に一文で示唆を添えて」

後者はAIに厳しい制約をかけていますが、その分、出力の再現性が上がります。これは単なる指示の細かさではありません。ユーザーが何を期待しているかを、モデルが取り違えないようにするための境界設計です。

この発想をサービス開発に持ち込むと、まったく違う問いが立ち上がります。たとえば「どうしたらモデルを賢くできるか」ではなく、「どうしたらユーザーがプロンプトを書く前に、欲しい結果へ到達できるか」です。入力フォームのラベル、テンプレート、例文、選択肢、事前の質問フロー。これらは全部、プロンプトの一部です。つまり、プロンプトエンジニアリングは入力欄の外側まで含むのです。

この見方をすると、AIサービスの難しさは一気に明瞭になります。LLMは万能な脳ではなく、むしろ非常に高性能な翻訳機です。人間の意図を、機械が動ける形式へ翻訳する。だからこそ、翻訳の前後にあるUI、状態、保存、再実行、フォールバックが重要になります。

---

クラウド選定は「どこで動かすか」ではなく「どう壊れるか」の設計

AIや画像生成サービス向けのクラウド選定を考えるとき、表面的には価格やGPU性能、リージョン、スケーラビリティが比較されます。もちろんそれらは重要です。しかし本当に問うべきなのは、そのシステムはどんな壊れ方をするかです。

AIサービスは、通常のWebアプリよりも失敗の形が複雑です。レスポンスが遅い、トークン上限に達する、画像生成が部分的に崩れる、コンテンツ安全性チェックで止まる、同じ入力でも毎回出力が揺れる。これは単なるバグではなく、確率的な挙動を前提にしたシステム設計が必要だという意味です。

ここでインフラとプロンプトの接続が見えてきます。プロンプト設計は、モデルの出力を安定化させる上流の制御です。クラウド設計は、その制御が失敗したときに体験を守る下流の制御です。たとえば、出力構造を厳密に指定しても、時々JSONが壊れるなら、パースエラーの再試行戦略が必要です。例を与えても意図がぶれるなら、サーバー側で検証し、追加プロンプトを返して再入力を促す必要があります。

この関係を一言で表すなら、プロンプトは精度を作り、クラウドは信頼を作るです。精度だけでは、たまたま当たる賢さに留まります。信頼だけでは、丁寧だが賢くない体験になります。価値あるAIプロダクトは、その両方が交差する場所にしか生まれません。

具体例を挙げましょう。画像生成のSaaSで、ユーザーがブランドガイドラインに沿ったビジュアルを作るとします。プロンプトで「高級感」「ミニマル」「青系」を指定しても、出力がぶれることはあります。そのとき、単に再生成ボタンを置くだけでは不十分です。直前の入力条件を保存し、生成のバージョンを記録し、失敗時には部分修正できるUIを用意し、計算資源が逼迫したら待機列を見せる。こうした仕組みは、表向きは運用の話に見えますが、実際には会話体験の一部です。

---

真の競争力は「会話の再現性」を作れるかで決まる

ここで、AIプロダクトの設計を考えるうえで役立つフレームを提案したいと思います。それは、サービスを三層に分けて見ることです。

1. 意図層: ユーザーが本当に欲しいものは何か
2. 変換層: その意図をモデルが扱えるプロンプトや構造にどう落とすか
3. 実行層: 結果を安定して返し、失敗を吸収する基盤をどう作るか

多くの開発は、実行層だけを頑張るか、変換層だけを工夫するかのどちらかに偏ります。けれど、価値が出るのは三層が連動したときです。意図層が曖昧なら、どれだけ高性能なGPUを積んでも結果はぶれます。変換層が弱ければ、モデルは十分賢くても使いこなせません。実行層が脆いと、体験はすぐ信頼を失います。

この三層モデルの面白いところは、プロンプトエンジニアリングとクラウド選定を別々のスキルにしないことです。むしろ、同じ目的に対する異なるレバーとして扱うのです。例えば、出力フォーマットをXMLタグで厳密に指定するのは変換層の仕事ですが、その結果を検証し、崩れたときに再試行するのは実行層の仕事です。ペルソナを与えて応答のトーンを安定させるのも変換層、モデル呼び出しを分離してキャッシュするのは実行層です。

良いAIプロダクトは、モデルを賢くするのではなく、意図を失わない経路を作る。

この視点を持つと、いわゆる「プロンプトの工夫」は、実はシステム設計の一部だと分かります。逆に、クラウドの比較表も単なるコスト比較ではなく、会話品質をどこまで守れるかの比較に見えてきます。安い基盤を選んでレスポンスが不安定になるなら、ユーザーはAIが賢くないと感じるでしょう。実際にはモデルの問題ではなく、体験の途切れが知性の欠如として知覚されているだけです。

---

すぐ実践できる設計原則

最後に、今日から使える形に落とし込みます。AIサービスを作るときは、次の問いを順番にチェックするとよいでしょう。

1. ユーザーの入力を、そのままモデルに渡していないか

曖昧な自然文を直接投げるのではなく、目的、制約、例、出力形式に分解する。入力欄は単なるフォームではなく、要件を構造化する装置です。

2. モデルの出力に失敗がある前提で設計しているか

JSON破損、長すぎる応答、トーンのブレ、安全性フィルタの発動を前提に、再試行や修正導線を用意する。AIは完璧に当てるより、失敗しても戻れることのほうが重要です。

3. プロンプトを一回限りの文字列として扱っていないか

優れたプロンプトは、テンプレート、バージョン管理、評価指標とセットで育てるべきです。プロンプトはコードと同じく、試作物ではなく資産です。

4. 基盤の選定が、UXの選定になっているか

GPUやクラウドの比較はコストだけでなく、遅延、ピーク時の安定性、観測性、障害復旧まで見て判断する。基盤は裏方ではなく、体験の速度と信頼を決める表の設計です。

5. ユーザーに何度も書かせるより、システム側で補完できないか

事前入力、履歴、推定、テンプレート、選択肢提示を使い、ユーザーの認知負荷を下げる。良いAIサービスは、ユーザーに賢さを要求するのではなく、ユーザーの曖昧さを吸収するべきです。

---

Key Takeaways

• AIプロダクトの核心はモデル単体ではなく、会話と基盤の設計にある。
• プロンプトは命令文ではなく、モデルに対するUIであり、要件定義の圧縮版でもある。
• クラウド選定はコスト比較ではなく、失敗時に体験をどう守るかの設計。
• 再現性のあるAI体験は、意図層、変換層、実行層の三層を揃えることで生まれる。
• ユーザーに良い入力を求める前に、システム側で曖昧さを吸収する設計を考えるべき。

---

結論: AI時代の競争は、賢いモデルを持つことではなく、賢さが発揮される状況を作ること

AIサービスを作る人は、しばしば「どのモデルを使うか」に引き寄せられます。けれど、真の差別化はそこではありません。どれだけ良いモデルでも、入力が曖昧で、出力形式が乱れていて、失敗時の復旧が弱ければ、ユーザーは賢さを感じません。

逆に、平凡に見えるモデルでも、明確な指示、適切な文脈、丁寧な出力設計、安定した実行基盤が揃えば、驚くほど頼れる体験になります。つまりAIプロダクトの本質は、知能そのものより、知能が働くための環境づくりです。

これからの競争は、「AIを使っているか」ではなく、「AIが迷わず働ける形に、どれだけ世界を整えられるか」で決まります。モデルを選ぶ前に、まず会話を設計する。クラウドを選ぶ前に、まず失敗の形を定義する。そこから初めて、AIは機能ではなく、体験になります。