LLM能力の認識格差を埋める：CTOが要件定義で避けるべき「期待値と実装コスト」のミスマッチ設計指針

LLM能力への認識格差：なぜプロジェクトは失敗するのか

Andrej Karpathy氏は、LLM能力に対する共有理解の格差が拡大していることを指摘している（Karpathyのポスト）。この指摘が示唆するのは、技術的な限界そのものではなく、組織内で「LLMに何を期待するか」の基準が合致していないという構造的な問題である。

背景にある数字を整理すると、世界の人口の約75%にあたる60億人がLLMとほとんど接触していない。一方、無料版ChatGPTなどのカジュアルユーザーは10〜20億人（人口の20%）に達し、検索補助や文章生成の延長線上で利用している。対照的に、数学・コード分野で最先端LLMを専門的に使い、大規模プロジェクトをエージェントに委任している層は約2,000万人（0.2%）にとどまるとされる。

この分布がプロジェクト失敗の温床となる理由は明確だ。ステークホルダーが「カジュアルユーザーの体験」を基準に期待値を設定し、実装側が「先進層の成果」を前提に技術選定を行うと、見積もりと実際の工数・品質の間に構造的な乖離が生まれる。具体的には、次のようなパターンが典型的である。

経営層が「数ヶ月かかった処理がプロンプト一発で終わる事例」を聞くと、同様の成果を自社の非構造化業務にも期待する。
開発チームがエージェント連携の設計を始めると、レビュー体制や状態管理の工数が想定を大幅に超える。
結果として、PoCで「それっぽい」結果が出た後に本番移行が頓挫し、技術的負債が蓄積する。

問題の核心は、LLMの能力が「使えるかどうか」の二値ではなく、アクセス権限・専門分野・問題の複雑さという複数の軸で段階的に絞り込まれるという点にある。次のセクションで、この絞り込みの構造を具体的に分解する。

3つのファネル：アクセス・領域・規模による能力の絞り込み

LLMの「実効能力」は、モデルのベンチマークスコアとは別の次元で決まる。Karpathy氏の指摘を設計視点に翻訳すると、能力は3つのフィルターを通じて段階的に縮小されると考えられる。

ファネル1：内部システムへのアクセス権限

最先端層（約5,000人、人口の0.00006%）が巨大な成果を出している背景には、内部で最先端システムへのアクセス権があることが前提にある。外部から公開APIを呼ぶことと、組織内でデータパイプライン・認証基盤・監査ログと一体化して運用することは、実装コストの桁が異なる。アクセス権限が制限されるほど、LLMが参照できるコンテキストの範囲が狭まり、出力の信頼性も低下する可能性がある。

ファネル2：専門領域の限定

LLMの能力は、収益性を駆動する環境混合データに対する検証可能な報酬への強化学習によって現れる。つまり、モデルが「正解を判定できる」領域（数学・コード・構造化データ処理）では能力が最大化し、曖昧な判断が求められる領域では能力が急落する傾向がある。プロジェクトが属する領域が「検証可能」かどうかは、技術スタック選定の第一判断基準となる。

ファネル3：問題の複雑さと規模

数学・コード分野では、数ヶ月かかったプロジェクトがプロンプトで完了する事例が報告されている。しかしこれは、問題が構造化されており、出力の正誤を機械的に検証できる場合に限られる。問題の複雑さが上がるほど、単一プロンプトでは解決できなくなり、エージェント連携や状態管理の基盤が必要になる。この「複雑さの閾値」を要件定義で明示しないことが、後工程の工数爆発の主要原因となり得る。

設計上の判断基準は、自社のプロジェクトがどのファネルの出口に位置するかを最初に定義することだ。以下に、3つのファネルが能力とコストに与える影響を可視化する。

flowchart LR
    A["LLMの理論能力"] --> B{"アクセス権限の制限"}
    B -->|内部システム連携| C["高能力・高コスト"]
    B -->|公開APIのみ| D{"専門領域の適合"}
    D -->|検証可能領域| E["中能力・中コスト"]
    D -->|曖昧・創造的領域| F{"問題の複雑さ"}
    F -->|構造化・小規模| G["低能力・低コスト"]
    F -->|非構造化・大規模| H["能力急落・コスト急増"]

この図が示すのは、ファネルを1つ下がるごとに「期待できる精度」が下がるだけでなく、「検証コスト」が相対的に上がるという非対称性である。公開APIのみで曖昧な業務を自動化しようとする場合、実装コストは低くてもレビュー負荷が膨らみ、結果的に内部システム連携方式より総コストが高くなるケースが起き得る。

カジュアル層 vs 先進層：期待値のズレを数値で可視化する

認識格差の具体像を捉えるために、ユーザー層を2つに分離して比較する。カジュアルユーザー層（10〜20億人）は、検索や文章補助を目的にLLMを使用しており、文脈依存の曖昧な指示でも「それっぽい答え」が返ってくれば満足する傾向にある。一方、先進層（約2,000万人）は数学・コードといった検証可能な報酬がある領域で使い、数百のエージェント連携による大規模成果を生み出している。さらにその上位には、内部で最先端システムにアクセスし、数千のエージェントによる連携で巨大な成果を出している約5,000人がいるとされる。

CTOが陥りやすい誤りは、カジュアル層の「手軽さ」の体験と先進層の「成果」のスケールを同一の文脈で語ってしまうことだ。例えば、「プロンプトで数ヶ月分の仕事が完了した」という事例を聞くと、カジュアル層のユーザーは「自分の業務も同じように楽になる」と期待する。しかしその事例が成立した前提（検証可能な報酬・構造化された入力・エージェント連携基盤）を欠くと、同じ期待は実現しない可能性がある。

両層の差異を設計判断に活かすために、以下に比較表をまとめる。

項目	カジュアルユーザー層（10〜20億人）	先進ユーザー層（約2,000万人）
利用目的	検索補助・文章生成	コード生成・数学推論・タスク自動化
期待される精度	「それっぽい」で十分	検証可能な正解率
必要な技術スタック	公開API + プロンプト設計	エージェント連携 + 状態管理 + 監査基盤
リスク許容度	高い（誤答を人間が検知）	低い（自動検証で保証）

要件定義時に重要なのは、顧客や社内ステークホルダーがどちらの層の「語彙」で要件を述べているかを聞き分けることだ。カジュアル層の語彙（「楽にしたい」「自動化したい」）で書かれた要件を、そのまま先進層の技術スタック（エージェント連携・ファインチューニング）で実装しようとすると、過剰設計によるコスト増と、本来の課題（レビュー体制の欠如）が未解決のまま残る。期待値を「文章生成」から「検証可能なタスク自動化」へ誘導し、その前提条件（入力データの構造化・出力の検証方法・失敗時のフォールバック）を要件定義書に明記することが、認識格差を埋める第一歩となる。

要件定義における「能力の可視化」フレームワーク

前節で期待値の層を聞き分ける重要性を述べたが、これを要件定義書の記述に落とし込む具体的な手法が必要だ。「LLMを活用したい」という一行で終わる要件書は、実装チームに判断材料を与えない。代わりに、以下の3つの軸で問題の性質を記述するチェックリストを導入する。

問題の性質を「検証可能性」で分類する

まず、対象タスクの出力が機械的に正誤判定できるかどうかを判定する。数学的計算やコード生成のように、テストケースや数値解で検証可能な領域では、Karpathy氏が指摘する通り、数ヶ月規模のプロジェクトがプロンプト投入で完了する事例が報告されている。この場合、モデルの温度パラメータを低めに設定し、出力の再現性を優先する設計が妥当だ。

一方、文章生成やアイデア出しのように「正解」が存在しない領域では、温度を上げて多様性を確保しつつ、人間によるレビューを前提とする設計になる。この分岐を要件定義時に決めておかないと、実装後に「なぜこの出力なのか」の議論がチーム内で繰り返され、意思決定が停滞する可能性がある。

過剰設計の兆候とコストの無駄

最上位層（約5,000人規模）で使用されている数千のエージェント連携は、内部システムへのアクセス権限と専門的なオーケストレーション基盤を前提としている。これをカジュアル層の要件（「検索を楽にしたい」程度）に適用しようとすると、エージェント間の状態管理・通信コスト・障害時のリカバリー設計が膨大になる。結果として、本来は公開APIとプロンプト設計で解決できる課題に、数倍のインフラコストと運用負荷が発生する。

さらに、生成物の品質保証が追いつかない現状を無視すると、技術的負債が蓄積する。OpenAI-HF事件の調査や722通の論文精査に時間がかかっている事例が示すように、ブラックボックス化された出力を検証するには、生成側とは異なる専門知識と人的リソースが必要になる。要件定義段階で「出力を誰が・どのように検証するか」を明記しないプロジェクトは、実装完了後にレビュー体制の欠如で立ち往生するリスクが高い。

実装コストとレビュー負荷のトレードオフ

LLMの導入コストは、推論（インフェレンス）のコストだけではない。生成されたコードや文章を人間がレビューし、品質を担保するコストが、規模が拡大するほど実装コストを上回る可能性がある。このトレードオフを定量的に把握しないまま導入規模を拡大すると、レビュー体制がボトルネックとなり、プロジェクト全体の進捗が止まる。

レビュー負荷の構造

レビュー負荷は単に「読む時間」ではない。LLMの出力は文脈依存であり、同じプロンプトでも出力が変化する。そのため、レビュー者は出力の妥当性を判断するために、入力意図・中間推論・最終結果の3層をすべて理解する必要がある。特にコード生成の場合、生成コードが既存コードベースと整合しているか、セキュリティ上の脆弱性を導入していないかを検証するには、ドメイン知識とセキュリティ知識の両方が求められる。

この検証コストは、生成規模が大きいほど線形以上に増える。1日10件の出力なら1人のレビュー担当者が追えるが、1日100件になると専任チームが必要になる。OpenAI-HF事件の調査が示したように、大規模な出力の精査には、通常のレビューとは異なる専門的な調査手法と時間的余裕が必要になる場合がある。

活用規模	推論コスト	検証・レビュー負荷	必要な人的リソース
カジュアル層（10〜20億人規模）	低（公開API課金）	低（人間が随時検知）	利用者自身
業務活用（社内数十人規模）	中（API課金 + 基盤構築）	中（担当者のレビュー）	1〜3名のレビュー担当
先進層（約2,000万人規模）	高（専用モデル + 連携基盤）	高（自動検証 + 専門レビュー）	専任QAチーム + 自動検証パイプライン
最上位層（約5,000人規模）	非常に高（内部システム + 数千エージェント）	非常に高（監査基盤 + 専門調査）	大規模エンジニアリング組織

この表から読み取れるのは、活用規模が上がるほど「推論コスト」と「レビュー負荷」の両方が増大し、後者の増加がより急峻になることだ。CTOが見積もりを行う際は、推論コストの1.5〜2倍をレビュー・品質保証の予算として確保するのが現実的な目安となる。規模が拡大するフェーズでは、レビュー体制の構築を先行投資として計画に含めるべきである。

設計判断：どの層に合わせるべきか

中小企業・スタートアップがLLM導入の設計判断を行う際、まず自組織が前述のユーザー層のどこに位置するかを明確にすべきだ。10〜20億人が利用するカジュアル層（無料版ChatGPTなど）の延長線上で価値を出せるのか、約2,000万人が専門的に使う数学・コード領域で勝負するのか、それとも約5,000人がアクセスする内部システム連携の領域に挑むのか。この選択が、技術スタック・コスト構造・リスクプロファイルを根本から決定する。

現実的な起点：カジュアル層の延長線上

内部システムへのアクセス権限を持つ最上位層の設計は、堅牢なオーケストレーション基盤・状態管理・監査ログの整備を前提としており、小規模チームが短期間で構築するのは困難だ。したがって、導入の起点はカジュアル層の延長線上、すなわち「公開API + 構造化されたプロンプト設計 + 人間によるレビュー」で価値を出せる領域に置くのが現実的である。この段階で重要なのは、業務プロセスのどの部分にLLMを埋め込むかではなく、埋め込んだ後に出力を誰が検証するかの設計を先に固めることだ。

検証可能な領域に限定する戦略

業務効率化を本気で目指す場合、「創造的・曖昧」な領域ではなく、数学・コードなど検証可能な報酬が存在する領域に限定して導入する設計が有効だ。この領域では、出力の正誤が機械的に判定できるため、レビュー負荷が相対的に低く抑えられ、エラー発生時の手戻りも最小化できる。具体的には、テストケース付きのコード生成、数値計算の自動化、構造化データの変換といったタスクに焦点を当てる。検証可能な領域で信頼を積み上げ、徐々に適用範囲を広げる段階的戦略が、長期的なAI導入の成功確率を高める。

さらに、アクセス権限を意図的に制限するハイブリッド戦略も検討すべきだ。内部システムへの完全アクセスではなく、特定APIへの限定アクセスのみ許可し、その範囲内で専門モデルを活用する。これにより、最上位層のような広範なシステム連携がもたらすセキュリティリスクを下げつつ、専門的な推論能力を業務に活用できる。設計の核心は、「何ができるか」ではなく「何を検証できるか」を起点に、自組織のリソースとリスク許容度に合った層を選択することにある。

具体的な実装パターン：エージェント連携の限界と活用法

前節で「何を検証できるか」を起点に層を選択すると述べたが、実際にエージェント連携を設計する際、まず理解すべき制約がある。最上位層（約5,000人）で実現されている数千のエージェントによる連携は、単一のプロンプト投入では達成しにくい。これは、各エージェントの出力を次のエージェントの入力として安全に転送するための堅牢なオーケストレーション基盤と、全工程にわたる状態管理が前提となるためである。状態管理が不十分な場合、ある工程で生成された中間成果物が破損・欠落すると、以降の全工程が無意味になる可能性がある。このため、大規模連携は基盤投資なしには実現が困難である。

小規模チーム向けの現実的な設計

中小企業・スタートアップの文脈では、2〜3つのエージェントを限定的に連携させる設計が現実的だ。数学・コード分野では、数ヶ月かかったプロジェクトがプロンプトで完了する事例が報告されているが、これは単一エージェントの能力というより、生成→検証→修正という有限のループを回すことで実現されている場合が多い。重要なのは、エージェント数を増やすことではなく、各工程の出力を検証可能な形式に強制し、次の工程への入力品質を保証する仕組みを設計することである。

sequenceDiagram
    participant U as 入力（プロンプト）
    participant A1 as エージェント1（生成）
    participant V as 検証ゲート
    participant A2 as エージェント2（精査）
    participant O as 最終出力

    U->>A1: タスク指定と制約条件
    A1->>V: 生成結果（JSON形式）
    alt スキーマ検証とテストケース合格
        V->>A2: 構造化データを転送
        A2->>O: 最終成果物
    else 検証失敗
        V->>A1: エラー情報と再試行指示
        A1->>V: 再生成結果
    end

上記のシーケンスで示す「検証ゲート」が設計上の核心となる。各エージェントの出力をJSONスキーマで強制し、テストケースのパス/フェイルを機械的に判定することで、人間が介入する箇所を最小限に抑えられる可能性がある。例えば、エージェント1がコードを生成した場合、出力は「コード本体＋実行可能なテストケース＋期待される出力」のJSON構造に収める。検証ゲートはスキーマの整合性とテストのパスを確認し、失敗時はエラーメッセージを添えてエージェント1に再試行させる。このフィードバックループの回数を上限（例えば3回）で制限し、超過時は人間レビューにエスカレーションする設計が、コストと品質のバランスを維持する場合がある。

運用フェーズ：認識ギャップを埋めるための組織対応

技術的な設計が整っても、組織内の認識ギャップが埋まらなければプロジェクトは失敗する可能性がある。人間によるレビューや理解がLLMの出力速度に追いついていない現状がある。具体的には、OpenAI-HF事件の調査や722通の論文精査に膨大な時間を要した事例が示すように、ブラックボックス化された出力を検証するには、専門知識と時間をかけた体系的なプロセスが不可欠である場合が多い。この現実を組織全体が共有していない場合、ビジネス側は「AIなら何でもできる」という期待を持ち、技術側は「レビューが追いつかない」という限界を抱え、双方の乖離がプロジェクトの遅延と不信感を生む可能性がある。

共通言語の構築と期待値管理

技術チームとビジネスチームの間に「LLMが何ができるか、何ができないか」の共通言語を作ることが、運用フェーズの最初の課題である。この共通言語は、抽象的な説明ではなく、具体的なPoC（概念実証）の結果として示すのが最も効果的だ。例えば、「この種の文書分類タスクでは、検証可能な領域に限定すれば精度90%以上で運用できるが、創造的な文章生成では人間レビューなしに品質を保証できない」という形で、能力の境界を数値と具体例で示す。定期的なデモでは、成功例だけでなく失敗例も提示し、カジュアル層の「それっぽい答え」への期待を「検証可能な成果」への期待に転換する。このフィードバックループを四半期ごとに回すことで、期待値のズレが蓄積するのを防げる可能性がある。

責任所在の設計

LLMの出力に対する責任所在を、設計段階で明確に定義する必要がある。「誰がレビューし、誰が最終承認するか」をプロセスに組み込まなければ、出力の品質問題が発生した際に責任が曖昧になり、改善サイクルが回らなくなる可能性がある。検証可能な領域（コード、数値計算、構造化データ変換）では、自動テストのパスが一次レビューとなり、人間は例外ケースのみを精査する二段階構造が有効だ。創造的・曖昧な領域では、人間レビューが必須プロセスとして設計に組み込まれ、レビューの所要時間をプロジェクト見積もりに含める。レビュー体制の構築コストが実装コストを上回る可能性がある規模では、この見積もりの精度がプロジェクト成立の分岐点となる。

まとめ：格差を「リスク」として管理するCTOの視点

Karpathyが指摘したように、LLM能力への共有理解の格差は拡大し続けている。約60億人がLLMとほとんど接触していない中、10〜20億人のカジュアルユーザー、約2,000万人の先進ユーザー、そして約5,000人の最上位層という階層構造が存在する。この格差は技術的な問題ではなく、ビジネスリソース配分の問題として捉える必要がある。CTOが直面する真の課題は「LLMが何ができるか」を正確に理解することではなく、自組織がどのユーザー層に該当し、その層に合った期待値とコスト構造で設計できるかである。

要件定義段階で、顧客や社内ステークホルダーがカジュアル層の延長線上にあるのか、先進層の領域に踏み込もうとしているのかを聞き分けることが最初の判断基準となる。カジュアル層の延長線上にある場合、検索補助や文章生成のような文脈依存の曖昧なタスクにLLMを使う設計となり、検証可能な報酬が得られないため、品質保証の設計が中心になる。一方、先進層の領域に踏み込む場合、数学・コードなどの検証可能な報酬がある領域に限定し、エージェント連携の規模を自組織のリソースに合わせた有限なものに設計する。どちらの場合も、最上位層の成功体験をそのまま投影して過剰設計を行うことが、見積もり不足と技術的負債の主要因となる可能性がある。

長期的なAI導入の成功確率を高める設計思考は、過大な期待を抱かせず、検証可能な成果を出し続けることにある。能力の分布データに基づいて自組織の位置を自覚し、それに適した技術選定とコスト見積もりを行う。レビュー負荷を過小評価せず、期待値のズれを定量的に管理し、段階的に適用範囲を広げる。この「格差をリスクとして管理する」視点を持つことで、LLM導入は単なる技術実験ではなく、持続可能な業務変革の基盤となる可能性がある。

参考

本記事は海外の技術トレンド「The gap in shared understanding of LLM capability is widening」（Hacker News）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。