生成AIの問題として広く認知されているもの

生成AIの問題として現在広く認知されているものとして「ハルシネーション」があります。
これは生成AIによる推論の過程で発生しますが、出力された結果を検証すれば良いため、問題としては認知されやすいもので、現在はこのハルシネーションをいかに回避するか、という試みが日々行われています。

しかし、ハルシネーションの問題を解決した後で、次の具体化という問題が発生します。
その具体化の不足が招く問題は広く顕在化しているにも関わらず、それはまだ形式的に認知されていないように思えます。

抽象的な成果物が溢れているという問題

生成AIの登場により、抽象的な成果物を大量生産できるようになりました。概念、フレームワーク、提言などです。
では、それら抽象的な成果物の質はどうなのでしょうか。

現在の生成AIは、基本的に膨大な情報を圧縮したパターンを元に出力を生成します。
つまり、多数の事例に共通するパターンが生成されやすく、その結果として生成される結果は抽象的・汎用的なものになりやすいです。

しかしこれらは「それっぽく見える」だけで、具体化され、実際に運用されない限り「絵に描いた餅」かどうかが判別しにくいという問題を抱えています。
ハルシネーションと違い、それ単体では質の良し悪しを判定しにくく、しかも判定できる段階がどうしても実証段階になってしまうため、問題として認知されにくいのです。

さらに、抽象化の過程では多数の事例が共通パターンへ収束するのに対し、その成果物を現場へ具体化する段階では問題が発散します。
同じ成果物であっても、適用する人、場所、タイミング、文脈によって、直面する課題が変わるからです。

このことから、一見すると現場ごとに異なる問題が起きているように見えてしまい、「原因は具体化の不足(抽象的な状態のまま放置されたこと)にある」という共通の本質が見えにくくなります。

具体化における認知負荷が高すぎる問題

生成AIとの壁打ちよって得られる成果物は、まず「理論的に理想的な形」になります。
当然ながらそのままでは絵にかいた餅の状態ですので、具体的な形に落とし込む必要があります。

しかし、ここで3種類の壁が順に立ちはだかります。

意味付けの壁

抽象的な成果物はまだ実現可能な状態にはなっていません。
具体的な要素に当てはめてようやく実現可能な状態になります。
例えばユーザーインターフェースであったり、KPIであったり、ルーブリックであったり。
これを人間の頭でどのような形にするかを決定し、抽象的な成果物と紐づけていく必要があります。

除去の壁

展開できたその次は、理想的な案から現実的な案に落とし込むため、実現不可能なものや優先度の低い要素を除去していくことになります。
大抵の場合、理想的な案というのは運用が現実的ではないからです。
理想的な案の質を維持しつつ除去していくのは大変な労力を伴います。

調整の壁

最後に待つのは現場と適合させるための調整です。
抽象的な案や理想的な案というのは、基本的に個別の現場の実情に左右されない重要な(抽象的な)要素だからです。
これを現場の運用であったり、市場の実態であったり、所属している会社やチームの実情であったり。
そういった物に適合させていく調整が必要になります。

重要なポイントは、除去と調整は、現場を知る人間にしか主導できないということです。

これは生成AI登場以前から存在した問題である

この問題は生成AI登場によって新しく発生した問題というわけではありません。
「コンサルが理想論を出し、現場が実装できない」という問題と同じ構図です。
生成AIはその「依存先」が変わっただけであり、本質的な問題は変わっていません。

なぜ抽象止まりになるのか

問題の本質は「答えを持たない人間が、答えを持っている何かに依存して、自分が先に踏み出すリスクを回避する」という人間の行動様式にあります。
特に現在は、この問題が生成AIの登場によって、生成AIに答えを出してもらおうという依存性が増幅している面も出てきていると思います。

生成AIが出した成果物をそのまま採用しようとするのも、「自分で最初の一手を出すリスク」を回避しようとしたい心理から来ています。
そして生成AIは現場の実情を知らないため、どうしても具体化が不足した状態の成果物までしか出すことができません。
こうして抽象止まりの成果物が生まれ、具体化の壁に阻まれたままリリースされます。

具体化の足りない成果物が引き起こす問題の実例その1「パイロット病」

AI projects often don’t come past pilot stage, finds Valliance study
https://www.consultancy.uk/news/44391/ai-projects-often-dont-come-past-pilot-stage-finds-valliance-study

AIプロジェクトの約半数がパイロット段階で停滞しており、本番移行できていないという問題です。

PoCは事前の検証として行われるものですが、理想的な状態を想定しての検証でも通過してしまいます。
理想的な状態で通過できても、その後は現場の実情に合わせて何かしらの削減を求められ、除去の壁に直面します。

さらに問題になるのは、生成AIは後からの調整が非常に難しいという点です。

従来のプロダクトであれば機能の削除に対する影響範囲の追跡が構造的に可能でした。
(もちろん簡単な作業ではないが……)

生成AIは、精度を落とす代わりに推論速度を向上させる、コンテキスト長を制限するといった調整が直感的に行いにくいです。
そのため、現場の「これじゃ使えない」というフィードバックに対して、システム側を柔軟に微修正していくことが難しく、これがコスト増とパイロット止まりの原因になっていると思われます。

このパイロット病という概念は、企業レベルで具体化の壁の存在を証明していると解釈できます。

具体化の足りない成果物が引き起こす問題の実例その2「GenAIの低ROI」

MIT NANDA The GenAI Divide: State of AI in Business 2025
https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf

生成AIを導入した、あるいはパイロット版を導入した企業の内、数百万単位の価値を生み出しているのはわずか5％に過ぎず、その一方で、大多数は測定可能な損益への影響をもたらさないまま停滞したままです。という恐ろしいレポートです。
このレポートからは、現場への適合、つまり調整の壁が問題となっていると解釈できます。

重要な部分を以下に引用します。日本語訳にはDeepl翻訳を利用しました。

Just 5% of integrated AI pilots are extracting
millions in value, while the vast majority remain stuck with no measurable P&L impact. This
divide does not seem to be driven by model quality or regulation, but seems to be
determined by approach.

Most fail due to brittle workflows, lack of contextual learning, and misalignment with day-to-day operations

The core barrier to scaling is not infrastructure, regulation, or talent. It is learning

統合型AIのパイロットプロジェクトのうち、数百万単位の価値を生み出しているのはわずか5％に過ぎず、その一方で、大多数は測定可能な損益への影響をもたらさないまま停滞したままです。この格差は、モデルの品質や規制によるものではなく、アプローチによって決まっているようです
その多くは、非柔軟なワークフロー、文脈に応じた学習の欠如、そして日常業務との整合性の欠如が原因で失敗に終わっています
規模拡大における最大の障壁は、インフラや規制、人材ではありません。それは「学び」なのです

なぜ具体化の不足が繰り返されるのか

前述の通り、まず具体化の不足が問題であるということに気が付くのが難しいというところから始まります。
そして問題の要点に気が付いたとしても、具体化された事柄は体系化が困難である。という性質があります。

抽象化は解が収束するため体系化しやすく、研究・言語化を進めることができました。
一方、具体化は与える条件によって解が発散していくため、共通項を見出すことが難しく、体系化が困難という問題があります。

そして抽象化が進むほど具体化から遠のくというパラドックスもあります。
皮肉なことに、生成AIの推論能力が具体化を遠ざけているのです。

解決のための一つの方向性：粒度の限定と帰納的抽象化

具体化の発散問題への解は、体系化ではなく粒度の限定ではないかと考えています。

全体を解こうとするから発散する。しかし「この文脈で、この一手だけ」に絞れば発散しない。

実践的な手順としては以下を考えています。

生成AIに最小の具体化候補を複数出させる
人間が一つ選び実行手順と評価方法を検討する
それを実行し結果を記録する
いくつか結果が溜まったら生成AIに帰納的抽象化をさせる(得られた結果の成功パターンの共通点を抽出してもらう)

思想としてはリーンスタートアップの「Build-Measure-Learn」と似ているのではないかと思います。
違いとしては、生成AIを人間の補助役として使う点です。

尚、MIT NANDA The GenAI Divide: State of AI in Business 2025でも成功企業の特徴が提示されています。

「CROSSING THE GENAI DIVIDE: HOW THE BEST BUILDERS SUCCEED」で検索すると出てきます。

概ね以下のような内容です。要約はChatGPTに依頼しました。

小さく試す（PoCではなく業務埋め込み型の試行）
ワークフローに組み込む
KPIベースで改善する
現場主導で反復する
早い意思決定と撤退・修正

現時点での結論

当然ながらこの記事も、本記事で触れている「抽象的な状態」にあります。
しかしながら、まずは1つ試すという観点で、問題提起として記事を作成しました。

今後はこの手順を実際に試し、結果を判定するところまで達成して初めて合格点になります。
それを今後の記事で積み上げていけたらいいな、と思います。

生成AIが抽象的な成果物をひたすら生産できる時代となりましたが、今後は一層、実行した人間だけが持つ具体知が希少資源となり、大きな価値を持つ時代になっていくのかもしれません。