Articles
AIと「回答空間」の旅
prompt、review、Skillsを貫くAIの設計思想
はじめに
LLM を使っていると、不思議な現象に気づきます。曖昧な質問をすると、AI はだいたい「それっぽいが凡庸な答え」を返します。
たとえば「良いビジネスアイデアを教えて」と聞くと、AI を使った SaaS、マーケットプレイス、AI コンサル、ノーコードツールのような答えに寄りやすい。どれも間違ってはいませんが、特別新しいわけでもありません。
これは AI が怠けているわけではなく、LLM の構造から自然に起きる現象です。この現象を理解するには、AI の仕組みを少し違う視点で見る必要があります。
LLM は「回答空間」を生成している
LLM は質問に対して正解を計算しているわけではありません。実際には、質問に対してあり得る回答の集合のようなものを内部に生成しています。
たとえば「良いビジネスアイデア」という質問に対して、AI の内部では SaaS、AI ツール、コンサル、マーケットプレイス、教育サービスのような可能性が広がる。この回答の可能性の広がりを、ここでは回答空間と呼びます。厳密な研究用語ではなく、LLM の振る舞いを理解するための説明メタファーです。
LLM はこの回答空間の中から文章を生成しています。そう考えると、prompt や対話や review が何をしているのかを 1 本の線で説明しやすくなります。
なぜ曖昧な質問は凡庸な答えになるのか
質問が曖昧な場合、AI の内部では非常に広い回答空間が生成されます。すると AI は、その中でも最も典型的な回答を出しやすくなります。
広い回答空間
↓
典型的な回答
これが AI が平均的な答えを出す理由です。雑な問いが雑な答えを呼ぶというより、広い問いが典型解を呼ぶと言った方が近いです。
ペルソナは回答空間を移動させる
AI にペルソナを与えると、回答の性質は大きく変わります。たとえば「優秀な Go エンジニアとして答えて」「経験豊富なデザイナーとして答えて」「スタートアップ投資家として評価して」のような指示です。
これを入れると AI の回答はかなり変わります。これは回答空間が移動しているためです。
一般的な回答空間
↓
専門家の回答空間
言い換えると、ペルソナ指定は回答の質感を変えるテクニックではなく、どの空間を見に行くかを変える操作です。
前提情報は回答空間を縮小する
AI に背景、制約、目的、技術スタックを与えると、回答の質は大きく向上します。これは回答空間が狭くなるからです。
広い回答空間
↓
制約追加
↓
狭い回答空間
目的、読者、締切、既存方針、出力形式まで足すと、AI は「何でも答えられる状態」から「この条件で答える状態」に変わります。実務で prompt が効く理由の多くは、ここで説明できます。
AIとの対話は回答空間の探索
Chat UI で AI と対話しているとき、人間は無意識に次のことをしています。AI に回答を生成させる。それを読む。条件を追加する。再度生成する。これは回答空間の探索です。
生成
↓
評価
↓
条件追加
↓
再生成
つまり AI との対話は、回答空間を旅しているとも言えます。対話が長くなるのは失敗ではなく、探索として見ると自然です。
review は回答空間の絞り込みである
ここに review を入れると、構造はさらに明確になります。生成だけでは空間は広がったままですが、批判や差分確認を入れると不要な方向を切り落とせます。review は回答空間の絞り込みです。
これは単一モデルの自己レビューが弱く見えやすい理由の説明にもなります。生成時の偏りとレビュー時の偏りが似やすいからです。だから生成役とレビュー役を分けた方が、別種の欠陥が見えやすくなります。
たとえば「新規事業の案を出して」で始めると、答えは広く、凡庸になりやすい。そこで「日本の B2B SaaS 企業向け」「1 人で 3 か月以内に試作可能」「既存顧客の解約率を下げるテーマ」と条件を足すと、空間はかなり狭まります。そのうえで別の AI に「この案の弱い前提を 3 つ挙げて」とレビューさせれば、さらに不要な案を落とせます。ここまでで、移動、縮小、探索、絞り込みが 1 本の流れとして見えてきます。
マルチモデルで精度が上がる理由
最近の AI 活用で重要なのが、複数モデルの組み合わせです。Codex、Claude、Gemini のように異なるモデルを組み合わせると、前提の違う批判や視点を得やすくなる場面があります。常に精度が上がるわけではありませんが、探索の偏りをずらせることはあります。
一般論として、それぞれのモデルは学習データ、訓練方法、推論スタイルが違います。つまり、生成する回答空間も違います。
Model A → 回答空間 A
Model B → 回答空間 B
Model C → 回答空間 C
複数モデルを使うと、探索できる回答空間が広がる場合があります。だからこそ、単独で閉じるより、別モデルの視点を 1 回挟んだ方が見落としの種類を変えやすい。
AI相互レビューによる収束
さらに重要なのが、異なるモデルによる相互レビューです。たとえば、モデル A が回答を書く。モデル B がレビューする。モデル A が修正する。これは次のような流れになります。
探索
↓
批判
↓
収束
単一モデルでは見えにくい欠陥が見えることがあります。ここで効いているのは、複数モデルを並べること自体ではなく、探索役と批判役を分けることです。
Claude の「Skills」という発想
ここで面白いのが、Anthropic が公開している Skills です。Anthropic の公式 docs では、Skills は「Claude の capabilities を extend する仕組み」として説明されています。同じ docs には subagents もあり、そちらは「specialized AI subagents for task-specific workflows and improved context management」と書かれています。
この 2 つを並べると、Anthropic が前に出しているのは単なる prompt 集ではありません。専門性を分け、仕事ごとの手順を持たせ、再利用可能な形で Claude に追加するという発想です。たとえば pdf、docx、xlsx、pptx、frontend-design、webapp-testing のような名前があります。これらは AI が特定の仕事を安定してこなすためのテンプレートであり、回答空間の操作として読むことができます。
Anthropic Skills を分類してみる
ここから先は、Anthropic が公開している Skill 記述をもとにした自分の整理です。公式分類ではありませんが、何を固定している Skill なのかを見るにはこの方が分かりやすいです。
1 つはドメイン特化型 Skill です。pdf、docx、xlsx、pptx のような Skill では、対象作業、処理方法、出力形式がかなり明示されています。たとえば pdf なら、読む、抽出する、結合する、OCR するといった扱い方が最初から前景化される。つまり作業の回答空間をかなり狭くしています。
もう 1 つはワークフロー型 Skill です。webapp-testing や mcp-builder は、作業手順そのものを固定する型と読めます。webapp-testing なら、まず状況を集めて、次に観察して、問題を切り分けて、最後に報告する、といった順序が前に出てきます。
Context gathering
↓
Observation
↓
Isolation
↓
Report
これは思考プロセスの固定です。回答内容だけでなく、探索の順序まで定義しています。
もう 1 つはスタイル・創造型 Skill です。algorithmic-art や frontend-design は、回答空間を美学の方向へ移動させる Skill と読めます。ここでやっているのは、単に正解を狭めることではなく、どちら側の空間を優先するかを決めることです。
Skill は回答空間の制御装置
Anthropic Skills を見ると、共通した構造があります。Skill は回答空間の移動、回答空間の縮小、思考プロセスの固定を同時に行っています。
回答空間の移動
↓
回答空間の縮小
↓
思考プロセスの固定
つまり Skill は、回答空間を制御するテンプレートです。毎回うまくやってくれる魔法ではなく、自由度を扱いやすい形に整える仕組みだと見た方が実務には合います。
回答空間と Skill と AI の組織化
ここまで整理すると、AI を活用するシステムは役割分担を持つことが必須になってきます。アイデア生成 AI、実装 AI、レビュー AI、判断 AI。これはほとんど組織構造です。
企業でも、企画、開発、レビュー、意思決定という役割分担があります。AI システムも同じ方向に進み始めています。こうした役割分離の発想は、たとえば 単一AIではなく実行基盤で考える AI開発環境とUNIX哲学 で書いた、multi-AI を役割の集合として設計する考え方ともつながります。
つまり、単一の AI ではなく、役割の集合として設計するという発想です。どのモデルが最強かだけを見るより、どこを誰に担当させるかを見る方が実務では効きます。
まとめ
LLM を回答空間生成器として見ると、AI の使い方はかなり整理されます。ペルソナは移動、前提情報は縮小、対話は探索、review は絞り込み、複数モデルは視点の拡張、Skills は制御テンプレートです。だから実務では、単一の最強モデルを探すより、役割分担とレビュー設計を考える方が効きます。もちろんこの比喩だけで全部を説明できるわけではありませんが、AI を実務で扱うにはかなり使いやすい見方です。