ほとんどのAIフレームワークが運用担当者の役に立たない理由
ジェームズをご紹介します。彼は米国中西部で90名規模の物流会社を経営しています。売上は堅調です。先月、彼のオペレーションリードが、カスタマーサポートメールの半分はおそらくAIで対応できると指摘し、そのアイデアが頭に残り続けました。何かしなければとは感じていましたが、何をすべきかを言葉にできませんでした。
彼はどんな合理的な人間もするであろうことをしました：「AI変革フレームワーク」でGoogle検索しました。3時間後、彼はノートパソコンを閉じました。
見つかったのは、McKinseyの47ページPDF「Rewiring the Organization for Generative AI」、Harvard Business Reviewの「AIレディネス成熟度」に関する記事、サブスクリプションがなければ読めないGartnerのクワドラント、そしてLinkedInのカルーセル「AI成功の5つのP」（Potential、People、Process、Platform、Performance）でした。彼の実際の問いに答えるページは一つも見つかりませんでした：カスタマーサポートチームが最初に試すべきAIツールは何で、何が問題になりやすいか？
これが運用担当者の問題です。そしてほとんどのAIフレームワークが失敗する理由です。
4種類のフレームワーク（そしてそれぞれの限界）
現在流通しているAIフレームワークは数百あります。それらは4つの大まかなカテゴリーに分類され、それぞれ固有の失敗モードを持っています。
コンサルティングフレームワーク：役員室のために作られた
McKinseyは「Steer-Scale-Institutionalize」のようなフレームワークを公表しています。BCGには「AI変革ロードマップ」と有名な10-20-70ルール（10%技術、20%ビジネス再設計、70%人材と文化）があります。Deloitteは成熟度ステージと能力マップを含む詳細な「AIの現状」レポートを公表しています。
これらは8桁の予算と3年間の変革ロードマップを持つFortune 500のCIOには本当に役立ちます。フレームワークは専任のAI卓越性センター、多年度のプログラムオフィス、変更管理チーム、そしてROIシグナルを4四半期待てる忍耐力を持つ取締役会を前提としています。
サポートメールにAIを試したいオペレーションリードを持つ90名規模の物流会社のジェームズにとって、BCGの10-20-70フレームワークは彼の課題の70%が人材と文化の変革であると教えてくれます。それはおそらく正しいです。実行可能ではありません。彼には文化変革プログラムは必要ありません。Intercom Fin、Zendesk AI、または他の何かを試すべきか、そして失敗モードがどのようなものかを知る必要があります。
コンサルティングフレームワークは戦略的な意味での「能力」のレベルで書かれており、AIの能力という運用上の意味ではありません。McKinseyが「GenAI能力」について語る場合、それはジェネレーティブAIを組織的に展開する能力を意味します。Generate出力（下書きメール）とExecuteアクション（実際に送信すること）の区別を議論しているわけではありません。その粒度は役員室のスライドには収まりません。
つまりコンサルティングフレームワークは大きな絵については正確ですが、細部では役に立ちません。変革が完成したときにどのようなものかを描写します。開始する助けはしてくれません。
学術フレームワーク：厳密だが遅い
MITスローン、HBR、研究グループからの学術フレームワークは証拠に対してより慎重で、不確実性に対してより正直です。また通常、ツールの現在の状態から2〜3年遅れています。なぜならピアレビューに時間がかかるからです。2024年初頭に公表された学術フレームワークは、おそらく2022年時代のLLM能力を基準として設計されています：GPT-4クラスのモデルがコモディティAPIになる前、マルチモーダルがデファクトスタンダードになる前、予測と生成の分割がすべてのSaaSベンダーが話すようになる前です。
学術フレームワークはビジネスコンテキストで適用しにくいものを測定する傾向があります：「AIの吸収能力」「組織学習文化」「ダイナミック能力開発」。これらは実際の概念です。四半期OKRに翻訳するのは難しいです。
そして学術フレームワークは、素材とともに座り、実験を行い、データを収集し、18ヶ月かけて反復することを前提としています。運用担当者には18ヶ月はありません。木曜日にベンダーのデモがあって、金曜日までに決定を下す必要があります。
ベンダーフレームワーク：製品マップを偽装したもの
すべての主要なAIソフトウェア企業は独自のフレームワークを公表しています。Salesforceには「Trusted AI Principles」があります。Microsoftには「AI変革Playbook」があります。SAP、Oracle、ServiceNow、HubSpotすべてが持っています。Google CloudはAIレディネス評価を公表しています。
これらは製品を売るために存在します。それは彼らの誠実さへの批判ではありません。単にインセンティブ構造についての真実です。SalesforceがAIレディネスの「4つの柱」を描写するとき、4つの柱は驚くことなくSalesforce製品にマッピングされます。MicrosoftのAIフレームワークがMicrosoft 365 Copilotの統合を強調するとき、それは偶然ではありません。
ベンダーフレームワークは一つのことに役立ちます：ベンダーがAIスタックにおける自社製品の役割をどのように考えているかを理解すること。しかしビジネスAIが実際に何であるかの客観的な地図ではありません。フレームワークの形をした営業ツールです。
見分ける方法：ベンダーフレームワークは競合他社の名前をほぼ決して挙げません。良いフレームワークは他の人のツールをいつ使うべきかを教えてくれるはずです。ベンダーフレームワークにはそれができません。
ハイプフレームワーク：AIの空虚な5つのP
4番目のカテゴリーは実際にはフレームワークではありません。コンテンツのフォーマットです。LinkedInのカルーセル、ニュースレターの投稿、YouTubeのサムネイルが「AIフレームワーク」の無限のストリームを生み出しています。確認すると、それらはビジネスの陳腐な表現に「AI」が加わったものです。
「AI成功のためのADAPTモデル」（Assess、Design、Adopt、Pilot、Transform）。「AIリーダーシップの6つのC」（Clarity、Context、Curiosity、Culture、Capability、Commitment）。これらは完全に間違っているわけではありません。AIに特定のものでもありません。「AI」を「デジタル変革」「アジャイル」「クラウド」に置き換えても同様に適用可能で、これは独自のことを何も説明していないことを意味します。
ハイプフレームワークの失敗モードはコンサルティングフレームワークの反対です。コンサルティングフレームワークは正確だが近づきにくい。ハイプフレームワークは近づきやすいが空虚。どちらも運用担当者が実際にいる場所で彼らに会いません。
運用担当者が実際に必要とするもの
実際のビジネスでAIフレームワークを適用する人は変革プログラムを管理するCIOではありません。担当者のワークフローのどれにAIが実際に役立つかを把握しようとしているSales Ops責任者です。あるいは月末締めをAIで加速できるかどうかを考えている60名規模の会社の財務責任者です。あるいはジェームズ、一つの問いに答えようとしている：カスタマーサポートで最初に試すべきAIツールは何か？
フレームワークから運用担当者が実際に必要とするものがあります。短いリストです。
語彙。 他のビジネスツールを描写するのに使うのと同じ用語でAIツールが何をするかを説明できるようにする言葉。「インテリジェントオートメーション」や「認知企業」ではなく動詞。これは何を受け取るか？何を出力するか？それが動いたとき世界で何が変わるか？ACEの5つの能力のような語彙を使えば、どんなAIツールも一貫した用語で描写できます。
意思決定支援。 12ステップのロードマップではありません。一つの問い：達成しようとしていることを踏まえると、どの能力または能力の組み合わせが必要か？カスタマーサポートメールを分類する必要があるなら、それはAnalyzeです。優先度に基づいて自動ルーティングする必要があるなら、PredictとExecuteを追加します。これは決定であり、成熟度モデルではありません。
正直な失敗モード。 コンサルティングフレームワークは「リスク」を抽象的な用語で文書化します（「変更管理の課題」「データガバナンスのギャップ」）。運用担当者には具体的なことが必要です。人間によるレビューなしにアクションを実行するAIツールをデプロイすると、典型的に何がうまくいかないか？悪いデータ準備の仮定が失敗したとき何が起きるか？Generate-to-Executeの境界は下書きメールと送信済みメールの違いです。これが誰かの四半期を終わらせる種類の失敗モードです。
コンサルタントを必要としない道。 このフレームワークを必要とするほとんどの運用担当者はMcKinseyを雇いません。「このワークフローにAIを試したい」から「ツールを評価し、パイロットを実施し、次に何をするかを決める方法」へ、6桁のエンゲージメントなしに至る道が必要です。その道は記事のライブラリから学べるべきであり、コンサルティング関係の後ろに隠れていてはいけません。
フレームワークが間違う場所：4つの一般的な間違い
ほとんどのフレームワークは、意図が良くても予測可能な罠に落ちます。
抽象的すぎる。 AI成熟度ステージや変革の旅を示す戦略図は月曜日に何をすべきかを教えてくれません。3万フィートでは正確ですが地上では役に立ちません。フレームワークは概念的なものと具体的なものを結びつける必要があり、ほとんどはそうしていません。
汎用的すぎる。 医療AIは小売AIでも物流AIでもありません。データタイプが異なり、コンプライアンス要件が異なり、失敗の結果が異なります。その違いを認めないフレームワークは間違いではありませんが、難しい仕事を運用担当者に残します：汎用的な原則を業界固有の実践に翻訳すること。良いフレームワークは業界中立な基盤を持ち、その後具体的になる権利を得ます。
技術特定的すぎる。 「GPT-4」や「LangChainエコシステム」や「Stable Diffusion」を中心に構築されたフレームワークは18ヶ月以内に部分的に時代遅れになります。ビジネスAIの進化は、フレームワークが特定のツールやモデルより長持ちする能力とパターンに根ざす必要があるほど速いです。動詞はプロダクト名より長く生き残ります。
エンタープライズ向けすぎる。 これが最大の問題です。CIO、専任データチーム、多年度ロードマップを持つ企業のために構築されたフレームワークは、従業員30〜500名の企業には転用できません。SMBは異なる制約を持っています：より厳しい予算、より少ない技術的深さ、より低いデータ準備、そしてより速い意思決定サイクル。価値を見るまでに6ヶ月のパイロットを負担できません。このギャップに対応しないフレームワークはほとんどのビジネスのためのフレームワークではありません。それほど助けを必要としていない一部のビジネスのためのフレームワークです。
AIフレームワークで機能するもの
フレームワークが実際に運用担当者のために機能するには、ほとんどのフレームワークが欠いているいくつかの特性が必要です。
シンプルな語彙。 50ではなく5〜7の概念。フレームワークにベンダーデモ中のワーキングメモリで保持できる以上の用語があるなら、最も重要な瞬間に役立っていません。
組み合わせ可能な設計。 概念はあらゆるものに組み合わさるべきです。データタイプは能力と組み合わさります。能力はパターンに組み合わさります。パターンはエージェントワークフローに組み合わさります。組み合わせ可能なフレームワークは固定されたマップではなくツールキットです。フレームワークが書かれた後に生まれたものも描写できます。
限界について正直。 すべてを解決すると主張するフレームワークは何も解決しません。最良のフレームワークは何を扱わないかを明確に示し、他のところを見るべき時がわかるようにします。
業界中立な基盤、業界固有の応用。 コアの語彙はあらゆるビジネスで機能すべきです。しかし良いフレームワークは「あなたの業界ではここが異なります」と言える意欲を持つことで信頼を得ます。汎用コア、具体的な例。
定期的に更新。 AIは2023年公表のどんなフレームワークも2026年にはギャップを持つほど速く動きます。四半期ごとのレビューと正直なバージョン管理にコミットするフレームワークは、永続的な真実として自分を提示するものより信頼できます。
ACEフレームワークがより良くしようとすること
ACEフレームワークはこれらの失敗モードを念頭に置いて構築されました。異なるアプローチを試みている点を示します。
27ではなく5つの能力を使います：Ingest、Analyze、Predict、Generate、Execute。すべてのAIツールはこれらの一つ以上を実行します。この語彙を使えばどんなAIユースケースも5分で読むことができます。
組み合わせ可能です。5つの能力は約10の繰り返しパターンに組み合わさります（RAGアシスタント、スコアリングとルーティング、会議インテリジェンス、その他）。パターンはロールレベルのAIエージェントに組み合わさります。スタックは構築されますが、基盤は覚えるのに十分小さいです。
実際の製品とその失敗モードに名前を挙げます。「主要なAIベンダー」ではなくGong、Intercom Fin、Salesforce Einstein、Stripe Radar。「AIリスク」ではなく具体的な失敗事例：人間のレビューゲートなしにExecuteを使うと何が起きるか、悪いデータ品質がAIデプロイメントに実際に何をするか。
Fortune 500のCIOではなく中規模市場の運用担当者のために構築されています。例は30名、90名、500名規模の企業で動きます。意思決定支援は独自モデルを構築するのではなくSaaSツールを評価していることを前提としています。
定期的な更新にコミットします。AIは進化します。フレームワークも進化すべきです。それは修正が必要な部分について正直になることを意味します。印刷されているからという理由で時代遅れの主張を守ることはしません。
ACEフレームワークが失敗する可能性がある場所
これはほとんどのフレームワークが省略する部分です。しかし残りのことを信頼できるものにする部分です。
新しく実績がない。 ACEフレームワークは2026年に公表されました。私たちが批評したコンサルティング会社は考え方を精緻化するための数十年のクライアントエンゲージメントを持っています。私たちには健全な設計と明確な最初の原則があります。それは実証的検証とは同じではありません。時間が経てばどの部分が証明されるかがわかります。
処方箋ではなく語彙。 誰かが正確にどの3つのツールをどの順序で購入すべきかを教えてくれることを望むなら、ACEフレームワークはそれではありません。ツールを評価しワークフローを設計するためのメンタルモデルを提供します。まだ判断はあなたが下す必要があります。「XYZをやる」を探しているなら、この基盤の上に構築されたPlaybookが必要であり、基盤自体ではありません。
能力が分割または統合されるかもしれない。 現時点では5つについて確信しています。しかし自律型エージェントがより一般的になるにつれて「Execute」は細分化が必要になるかもしれません。単一パスでパーセプションと理解が起きるシステムでは「Ingest」は「Analyze」と統合されるかもしれません。フレームワークは進化すべきです。最終的な答えを持っているとは主張しません。
すべての業界をカバーできない。 中規模市場の物流、SaaS、医療、製造、プロフェッショナルサービス：それぞれ汎用フレームワークが見逃す何か重要なことがあるほど固有の制約を持っています。業界固有の記事を公表しますが、常に部分的です。私たちがまだカバーしていない業界の運用担当者はいくらかの翻訳作業が必要です。
依然としてコンテンツ。 フレームワーク記事を読んでもAI採用が上手くなるわけではありません。実践が上手くします。ACEフレームワークは仕事についてより明確に考えるための語彙を与えます。しかし仕事は仕事です。
フレームワークとの正しい関係
フレームワークはツールです。ハンマーは家を建てません。ACEフレームワークもAI戦略を構築しません。しかしハンマーが何かを理解しない大工は何も建てられません。
どの能力を実際にデプロイしているかという観点でAIツールが何をするかを説明でき、下書きとアクションの違いを知り、ベンダーのピッチを読んで「ここで実際にアクティブな能力はどれか？」と問える運用担当者は、そうでない人より良い決定を下します。フレームワークを読んだからではなく、適切な問いを問うための語彙を持っているからです。
ACEフレームワークは、より良い問いを立てる助けをするときに使ってください。フレームワークが対応しない問いのときは置いてください。そして証明されていない部分を見つけた場合、私たちに知らせてください。
ACEフレームワークは生きているドキュメントです。この批評はその一部です。
