【雲栖観察】雲栖大会は答えではない——AI産業がどこに賭けているかを示す地図

今回の雲栖大会（Alibaba Cloudの年次フラッグシップカンファレンス）を回って、私が得た最大の収穫は、また新しいモデルや新しい会社をいくつか覚えたことではなく、展示会そのものを見る目が変わったことだ。

以前、技術系のカンファレンスに出ると、つい次のような前提で判断しがちだった。大手が重点的に語る方向は高い確率で未来を指している、壇上で繰り返し出てくるコンセプトはほぼ業界のコンセンサスだ、ブースに並べられた製品はすでに一定の成熟を経ている——と。

数多くのカンファレンスを経験するようになると、今度は逆の極端に流れやすくなる。カンファレンスは所詮マーケティングイベント、ブースは広告、PPTは包装——そう決め込んでしまう。

どちらの見方も安易にすぎる。

展示会にマーケティングの色が濃いのはもちろんだが、マーケティング自体もまた情報である。あるベンダーが予算、プロダクトマネージャー、エンジニアリングチーム、セールスチーム、ブースのリソースを一つのテーマに投じるなら、そこには少なくとも二つのことが示されている。市場に何を信じさせたいか、そしてどんな問題に対して製品化のアプローチを試みているか。

だからこそ今は、大型技術カンファレンスを高密度の産業サンプリング・フィールドとして捉えたい。答えは出さないが、サンプルも、兆しも、反例も、そして「業界がどんな未来に賭けているか」を示す地図も与えてくれる。

一、まず展示会の「賑わい」をエビデンスの階層に分解する

今回、意識的に、一つの技術テーマを五つの階層に分けて見るようにした：

ナラティブ層 → プロダクト層 → プロダクション層 → ビジネス層 → レベニュー層
（Narrative → Product → Production → Business → Revenue）

最上位はナラティブ層（Narrative）である。ベンダーが市場に対して信じさせたい世界観を指す。たとえば、エージェント（Agent）が新しい仕事の入口になる、企業はAIネイティブ（AI-native）アーキテクチャを備えるべきだ、コンテキスト（Context）が中核資産になる、マルチエージェントがより複雑な業務を引き受ける—こうした言説は、組織の関心と資本がどこへ向かっているかを示してくれる点で重要だ。とはいえ、いずれも判断であり、賭けに過ぎない。

その一段下にあるのがプロダクト層（Product）である。すでに展示でき、呼び出せ、納品できる実体のあるプロダクトが存在する世界だ。完全なUI、API、ワークベンチ、ガバナンス基盤がブースに並んでいれば、その方向性はコンセプト段階を抜け、製品化のフェーズに入っていることを意味する。それでもなお、「デモとして動く」ことと「本番環境で安定稼働する」ことの間には、依然として大きな隔たりがある。

さらに下がプロダクション層（Production）になる。プロダクトが顧客の業務フローに実際に組み込まれ、継続的に稼働し、権限・データ・監査・復旧・コスト・組織間連携といったリアルな課題に直面し始めた段階を指す。ここまで来て初めて、本番運用に入ったと言える。

その下がビジネス層（Business）だ。投入後、何が変わったのかをさらに問い直す。納期の短縮、コンバージョン率の向上、人件費の削減、広告クリエイティブのテスト件数の増加、あるいは以前は実行できなかった業務フローを可能にしたのか。

最下層、そして最も地に足のついた層が、収益層（Revenue）である。顧客が長期的に支払いたいと思うか、どの成果に対価を払うか、繰り返し購買はどんな条件で生じるか。

このフレームワークの意義は、異なるエビデンスをごちゃ混ぜにしない点にある。ブースは「ある方向性を披露する価値がある」ことを示し、フォーラムは「ベンダーが訴求したい認知」があることを示し、実在顧客の事例は生産層とビジネス層の信頼性を高め、そして継続的な収益のみが収益層を裏づける。

つまり、あるテーマがカンファレンスで賑わっているという事実だけでは、「いま投資すべき」という結論には直結しない。

二、今回最も顕著な変化：モデルの上にもう一層、また一層と層が積み上がっている

ここ数年のAIをめぐる議論では、注目はほぼモデルに注がれていた。パラメータ規模、ベンチマーク（Benchmark）、推論能力、価格、コンテキストウィンドウ、画像品質、コーディング能力。

今回、会場を回って痛感したのは、注目点が移行しているということだ。

モデルそのものは依然として重要だが、モデルを取り巻くシステム層は明らかに厚みを増している。データ基盤、モデル連携、Token管理、エージェントランタイム（Agent Runtime）、サンドボックス（Sandbox）、コンテキスト（Context）、メモリ（Memory）、スキル（Skill）、ブラウザ操作（Browser Use）、デスクトップ操作（Computer Use）、検証（Verification）、可観測性（Observability）、権限管理、監査、コスト管理——これまで以上に多くの機能が、独立したプロダクトとして切り出されつつある。

理由はシンプルだ。モデルが質問に答えられることと、モデルを本番ワークフローに組み込んで安定的に業務を完遂できることの間には、丸ごと一揃いのエンジニアリングシステムを必要とするからである。

展示会場を一日回ると、全く異なる名前の製品が五つも六つも並んでいるのが見える。だがその実体は、みな同じ構造へと収斂しつつある。QwenWorkが披露したのは、エージェントが隔離環境内で複数のツールを呼び出してタスクをこなすしくみだ。Qoderが語っているのは、コンテキスト、仕様書（Spec）、テストハーネス（Harness）、検証（Verification）、メモリ、そしてマルチモデルのルーティングである。出展していた独立系のTinyFishは、エージェントを実在のWebの世界に送り込んでタスクを実行させる仕組みを作る。WonderClipは動画制作を脚本、絵コンテ、素材、生成、レビュー、バージョン管理、一括量産へと分解する。そしてAlibaba Cloud OpenSearchのAgentic Searchは、検索をPlanning、Reasoning、Memory、Action、Evaluationへとさらに拡張している。

一見まったく異なる分野に見えるこれらの製品だが、底流にある構造は確実に近づいている。

コンテキスト → 計画 → スキル → 実行 → 検証 → メモリ → ビジネス成果
（Context → Planning → Skill → Execution → Verification → Memory → Business Outcome）

モデルはその中核コンポーネントの一つとなりつつあり、製品価値はより上位のシステムに宿る形へと移っています。

三、コンテキスト（Context）が「入力材料」から長期資産へと変わりつつある

Qoderのスライドにあった一文が核心を突いています：

Model power is a commodity. Context is the asset.

この言葉にベンダーの立場が含まれているのは確かですが、本質的な問題を提起しています。モデルの能力が高まるほど、その取得コストが下がるほど、エージェント（Agent）が長期的に機能しうるか否かを決める要因は、「それが結局のところ何を知っているか」に集約されていくのです。

成熟したソフトウェアプロジェクトには、アーキテクチャ上の制約、過去の意思決定、モジュール間の依存関係、コーディング規約、過去の落とし穴、本番運用記録が存在します。一つの企業の中には、組織関係、アクセス権、SOP、ドキュメント、社内チャット、業務ルール、顧客ステータスがあります。ブランド側には、商品情報、ビジュアルガイドライン、過去のクリエイティブ素材、広告配信データ、チャネル制約が蓄積されています。

こうした情報は、より強力なモデルに置き換えたからといって、自動的に涌现してくるものではないのです。

こうした流れの中で、QoderはコードリポジトリWiki（Repo Wiki）、Memory（記憶）、Knowledge Cards（知識カード）を実装し、QwenWorkはEnterprise Context（企業コンテキスト）を強調し、OpenSearchは長期記憶・タスク記憶・コンテキスト圧縮を打ち出しています。いずれもが同じ課題に挑んでいます――エージェントが毎回ゼロから世界を理解し直す必要がないようにすることです。

これはすなわち、かつて多くのチームが丹念に蓄積してきたPrompt Library（プロンプトライブラリ）の長期的な価値が、想定ほど高くない可能性を示唆しています。Prompt（プロンプト）はどちらかといえば単発タスクの呼び出し方式に過ぎず、真にレバレッジを効かせられるのは、業務コンテキスト、意思決定の履歴、検証結果、失敗の原因、そして再利用可能なスキルです。

四、AI製品の競争単位は「単一機能」から「業務完遂」へと移ろいつつある

WonderClipから受けた印象が、とりわけそれを如実に物語っていました。

機能一覧だけを眺めれば、驚くような新しさは感じられません――画像生成、動画生成、翻訳、ナレーション、素材差し替え、量産。個別に切り出してみれば、どの機能も、モデルベンダーや動画編集ソフト、あるいは他のSaaSがいつの間にか代替してしまう可能性を孕んでいます。

それでも、現場で披露されたプロダクトの構造は、すでに一段上の完成された生産システムへと踏み出していました：

スクリプトをアップロード → 構成をレビュー → 素材を用意 → 一括生成

このほかにも Storyboard、Canvas、カスタムスキル、共有アセット、チームコラボレーション、バージョン管理といった機能が並び、このプロダクトは「生成」を再びワークフローの中央に据える設計思想を打ち出しています。

これは AI プロダクト開発者にとって、きわめて直接的な示唆を与えてくれます。

プロダクトの中核が依然として「何かをアップロード → AI が処理 → 結果をダウンロード」というシンプルな型にとどまっているなら、次のモデルのアップグレードで価値が大きく圧縮されてしまうのは避けられません。より堅実な方向性は、ユーザーが本来やり遂げようとしていた業務プロセスそのものを丸ごと引き受けるプロダクトを作ることです。

たとえば EC コンテンツ制作のシーンを想定してみましょう。商品差し替え、背景変更、翻訳、ナレーション差し替えといった単発機能はいずれも表面的なレイヤーに留まっています。さらに一段上のレイヤーを狙うなら、プロダクトが扱う対象をブランド（Brand）、SKU（単品）、キャンペーン（Campaign）、マーケット（Market）、クリエイティブ戦略（Creative Strategy）、素材バリアント（Variants）、配信チャネル（Distribution）、運用パフォーマンス（Performance）といった粒度へと拡張していくべきです。生成はあくまで実行モジュールに過ぎず、本当の価値はクリエイティブ業務ワークフロー（Creative Operations Workflow）全体から生まれます。

5. エージェント（Agent）は「質問に答える」から「タスクを完遂する」へ

今日はAlibaba Cloud OpenSearchのエージェント型検索に関するセッションを聞いていて、提示された進化の図がなかなか示唆的だった。

初期の検索が解いていたのは、Query（クエリ）からResults（結果リスト）への対応だ。生成AIの登場によって、それはQuestion（問い）からAnswer（答え）への対応へと進んだ。そしてAgentic Searchはさらに一歩踏み込み、Goal（目標）からAction（行動）へと対象そのものを書き換える。

つまり、検索という行為そのものが、その役割の座標を動かし始めている。

近い将来、リサーチエージェント（Research Agent）は、自動で問いを分解し、クエリプランを組み立て、複数の検索ソースを呼び出し、追加検索で補完しながらクロス検証を重ね、中間的な結論を導いたうえで、別のツールを起動して処理を続行する——そんな姿になるはずだ。検索APIは、エージェントが外部コンテキストを取得するためのインフラとして、徐々に別の相貌を帯び始める。

これはSEO（Search Engine Optimization）とGEO（Generative Engine Optimization）の捉え方も変えてしまう。これまではインプレッション（Impression）、クリック（Click）、ランキング（Ranking）が中心だった。これからは、AI可視性（AI Visibility）、引用（Citation）、メンション（Mention）、AIリファラル（AI Referral）まで視野を広げ、さらにそのトラフィックが最終的にサインアップ（Signup）、課金（Paid）、リテンション（Retention）に結びついているかまでを追う必要がある。

検索は消えたのではない。より大きなタスクのループの中に、組み込まれ始めたのだ。

六、企業AIの真の難所、組織層へ

カンファレンスでは、企業AIの技術課題について多くの議論がなされた。データ、権限、セキュリティ、ガバナンス、モデル連携、クラウドアーキテクチャ、Agent基盤。

いずれも重要なテーマだ。しかし複数の企業事例に触れた後、私がより関心を引かれたのは別の問いである。

それを本当に使いこなす動機を、誰が持っているのか。

ある従業員がAIを活用して従来8時間かかっていた業務を5時間に短縮できたとしよう。浮いた3時間は何に充てられるのか。答えが「その分、さらに仕事を任せる」でしかなければ、従業員が自発的にAI活用を推進する意欲はおのずと限られてしまう。

別の例を見てみよう。AIチームのKPIがAgentの本番投入数や呼び出し回数であるなら、機能を次々と積み増す方向にインセンティブが働きがちだ。一方で、業務チームは業務フロー改革のコストを背負い、ITチームやセキュリティチームは障害発生時のリスクを引き受ける。肝心の売上拡大への貢献は、どのチームの成果か曖昧なままだ。このような組織構造では、技術がいくら利用可能でも、実業務への浸透は遅くなりがちである。

企業AIは単なるアーキテクチャ（Architecture）の問題ではない。インセンティブ設計（Incentive Design）こそが、本当の天井を決めるのだ。

技術的な問題は金で解決できる。だが組織の問題は、金をかけたところで必ず解決できるとは限らない。プロジェクトを前に推し進めるからには、最低限これだけは明確にしていただきたい——役割（Role）、評価指標（KPI）、得られる便益（Benefit）、かかるコスト（Cost）、想定リスク（Risk）、そして意思決定権（Decision Right）。利益を得る者がリスクを負担し、意思決定権を持つ者が結果に責任を持つ。このシンプルな原則が抜け落ちたまま走り出すプロジェクトは、ほぼ例外なく、どこかで崩れる。

所谓の「AI実装問題」の多くは、突き詰めれば組織設計の問題に行き着く。

七、最も誤解を招く指標は、かえって一目瞭然に見える指標である

Qoder のスライドの中に、強烈に印象に残っている1ページがある：

Generation rate is a vanity metric.

プレゼンでは、開発フェーズ別の AI コード生成比率を並べたうえで、ソフトウェアのデリバリ―サイクル（Delivery Cycle）が同じ比率では短縮されていない点を強調していた。ここに示されている具体的な数字はベンダー側の一事例にすぎず、業界全体のベンチマーク（Benchmark）としてそのまま流用できるものではない。ただ、そこで語られている論理そのものは、十分に筋が通っている。

AI がコーディング（Coding）のコストを押し下げると、ボトルネックは要件定義（Requirement）、コンテキスト（Context）、アーキテクチャ（Architecture）、レビュー（Review）、テスト（Test）、統合（Integration）、デプロイ（Deployment）、受入検証（Validation）へと移っていく。

したがって、コード生成率、Token 数、エージェント数、呼び出し回数、画像生成量といった指標は、いずれも局所的な効率指標に過ぎない。本当に見るべきは、エンドツーエンドの結果である。リードタイム（Lead Time）は短縮されたか、人手による作業時間（Human Minutes）は減ったか、初回通過率（First-pass Acceptance Rate）は上がったか、検証済みタスク一件あたりのコスト（Cost per Accepted Task）は下がったか、そして最終的なビジネス指標は動いたか——この一点に尽きる。

今回のカンファレンスで改めて痛感したのは、「AI が何を成したか」という量に目を奪われてはならない、「システム全体として何が変ったか」を見極めなければならない、ということであった。

八、カンファレンスは賭けの場を提供する。だが判断権はあくまで自分の手元に残すべきである

カンファレンスに参加して最も起こりやすいのは、外部の潮流が自分の優先順位を勝手に決めてしまうことだ。

壇上で何度も語られるテーマがあると「うちも研究すべきだ」と感じるし、有力ベンダーが巨額に投資していれば「うちも追従すべきだ」と感じるし、あるプロダクトが一見先進的に見えれば「うちも同じ仕組みを整えるべきだ」と感じる。

今回は、こうした情報をもっとシンプルな問いに落とし込んでみたい。

その情報は、自分のどの Decision を変えるのか？

「面白い」と感じただけで終わるなら、それは単なる入力でしかない。

Build（自前構築）／Buy（購入）／Ignore（無視）の判断を揺さぶり、产品の境界線を引き直し、低価値な開発を止め、ワークフローを組み直し、实验指標を再定義する──そんな変化を引き起こす情報だけが、本当の意味で意思決定に届く。

云栖大会そのものが答えではない。

それはむしろ、产业全体の「賭け」が見える地図だ。その地図は、他社がどこへ进もうとしているか、どの道が混み始めているか、どんなインフラが形を成し始めているか、どの课题が大规模にプロダクト化されつつあるかを教えてくれる。

最終的にどの道を選ぶかは、やはり自分たちの 목표・制約・リソース・エビデンスに立ち返るしかない。

これが、今の私が技术カンファレンスに参加するうえで最も手放したくない姿勢だ──さまざまな賭けを目にし、同時にジャッジメントは自分の手元に残しておくこと。

エンタープライズ AI の切入点をどこにするか、どの领域に投下すべきか、どの話がナラティブだけで膨らんだ泡沫か──そうした见極めを進めているなら、ぜひ话し合いましょう。弊所では、企业 AI 转型専项コンサルテーションを提供しています。技术选型から组织设计、メトリクス体系の构筑まで、「カンファレンスの热気」を「あなた自身の判断」に着地させるお手伝いをします。连携メール：[email protected]。

延伸阅读：『AI 转型七步框架』で、企业における AI 落地の完全なパスを体系的に解説しています。

本シリーズについて

「雲棲観察」は IAIUSE が贈る産業現場のレポート・シリーズです。2026年の雲棲大会 (Alibaba Cloud Summit) を起点に、研究者の目で AI 産業にいま起きている本質的な変化を解きほぐしていきます。バズを追わず、巨額の投資がどこに流れているのか、そしてそれを支える根拠はどこまで強いか——その二点だけを丁寧に見る連載です。

扱うトピックは、モデルより上位のシステム層、Agent の実装、Context としての資産、企業の AI 組織設計、AI プロダクトの競争単位のシフトなどで、合計でおよそ10本を予定しています。

私は大企業向けのコンサルティングとビジネス分析で約8年の経験があります。IBM に在籍していた時期には、通信、金融、保険、製造業のプロジェクトに参加しました。その後は通信事業者のプロダクト、インターネットプロダクト、そして AI アプリ開発の前線で、要件定義、プロダクト設計、部門横断での実装に取り組んできました。本シリーズでの判断は現場での観察と業界横断での検証にもとづくものであり、著者としての立場は明確に打ち出していますが、いずれのベンダー寄りの見解でもないことを明記しておきます。