前回の記事で筆者は、エージェント型アシスタント（自律的にタスクを実行するAIアシスタント）が知識労働をより良い方向へと変化させたものの、依然としてパワーユーザーに最も適した難度の高いツールであると論じた。大手ソフトウェアベンダー各社は、筆者が「エンタープライズのClaude（クロード）化」と呼ぶ動きによってこの現実に対応している。これは、より幅広い層の利用を目指して開発された「Claude Cowork」をモデルとする、似たようなデスクトップ向けエージェントの急増であり、それぞれがナレッジワーカーの主要なインターフェースになることを目指して構築されている。
春先からこのカテゴリーを追跡・検証してきた筆者の見立てでは、マイクロソフトとアマゾンの2社がこの分野で有力な第1弾を投入している。ただし、この第1世代にはまだ明確なギャップが存在する。企業向けのツールが、Claude Coworkのようなパワーユーザー向け製品とどう異なるのか、そしてどこに不足があるのかを理解することが重要だ。
（注：アマゾンとマイクロソフトは、競合他社の多くと同様に、筆者の所属するMoor Insights & Strategyのアドバイザリークライアントである）
Claude Coworkは依然としてパワーユーザー向けの基準
まずベンチマークから見ていこう。Claude Coworkは、「Claude Code」の基盤であるエージェント型アーキテクチャをデスクトップアプリに載せ、指定したローカルフォルダーへのアクセス権を与え、「スキル」やカスタムのMCP（Model Context Protocol、AIモデルとデータソースを接続する標準規格）コネクターによってユーザーが機能を拡張できるようにした。このローカルファイルへのアクセスと深いカスタマイズ性こそがClaude Coworkの真骨頂であり、同時にその上限も定めている。プロフェッショナルな成果を得るには、丹念に整えた個人用コンテキストストア、いわゆる「セカンドブレイン」（筆者はObsidianで管理している）と、アプリのスキルやコネクターを維持する意欲が求められる。ほとんどの従業員はそこまでしない。企業向けの対抗馬各社は、はるかに少ないセットアップと、CIO（最高情報責任者）が求めるガバナンスを備えたうえで、その価値の大半を提供できると賭けているのだ。
何がエージェント型アシスタントを「エンタープライズ対応」たらしめるのか
個別の製品を評価する前に、「エンタープライズ（企業）対応」が何を意味するかを明確にしておくと役立つ。今年筆者がレビューした導入事例から見ると、本格的な企業向けアシスタントを高機能チャットボットから分ける能力は4つある。
- 1. 集中管理型プロビジョニング（システム環境構築） — 企業はエージェント、スキル、フロー、その他のエージェント関連成果物を適切なユーザーに配布し、変更に伴うバージョン管理を行う仕組みを必要とする。これは製品に直接組み込むことも、バックエンドのエージェント制御プレーンを通じて提供することもできる。この点に関する筆者の見方は変わっていない。大規模運用では、この層は必須となり、デスクトップに現れるアシスタントはその氷山の一角にすぎない。
- 2. メモリーと個人用コンテキストストア — これらは異なる2つの能力であり、その違いが重要だ。メモリーはエージェントが管理する。セッションや生成した成果物から学習し、使い込むほど有用になっていく。一方、個人用コンテキストストアはユーザーが管理するデータベースに近く、外部情報源からファイルやメモまで、あらゆる文脈情報を格納する場所である。これは、パワーユーザーが手作業で作り上げるセカンドブレインへの企業向けの答えだ。本格的なアシスタントには両方が必要で、いずれも製品に組み込むことも、外部サービスで補うこともできる。
- 3. 柔軟性 — モデルの選択肢は現時点ではまだ狭いが、企業は今後、自社製モデルや業界特化モデルを持ち込むケースが増えていく。これらへの対応が必要だ。同じくらい重要なのは、MCPやその他のAPIを介して、独自アプリや標準コネクターが未対応のアプリ向けにコネクターを容易に構築できることだ。
- 4. データ保護 — これは包括的な項目であり、セキュリティ、データ主権、言語ガードレール、従業員のプライバシー保護を含む。規制や実際の利用状況に応じて変化し続ける課題でもある。ほとんどの企業にとって、この機能こそが、アシスタントの導入をパイロット段階から先に進められるかどうかを決定付ける要素となる。
この評価軸を手にすると、最も重要な企業向けの挑戦者2社、マイクロソフトとアマゾンの姿がより鮮明に浮かび上がる。
エンタープライズ分野の挑戦者たち
Microsoft Copilot Cowork
マイクロソフトは最も直接的なアプローチを取っている。Anthropic（アンソロピック）の協力を得て3月に発表され、6月に一般提供が開始されたCopilot Coworkは、アプリを横断した自律的な自動化機能をMicrosoft 365にもたらす。上記の4つの基準に照らすと、柔軟性とデータ保護において最も強力である。柔軟性の面では、今回の候補の中で、真のモデル選択肢を提供する唯一のツールだ。ライセンスの権限に応じてClaudeとOpenAIのモデルを切り替えることができ、Copilot Cowork専用モデルの登場も控えている。
マイクロソフトは、Microsoft 365コネクターを使用した場合、Claudeと比較して消費コストを30〜40%削減できると主張している。同社がスタック（技術階層）の多くを保有していることを踏まえれば妥当だが、事実として扱う前に、実際の顧客数値で証明されるのを見たい。
データ保護の面では、Copilot Coworkはプロビジョニングされた包括的な体験を提供し、企業が期待するセキュリティとガバナンスの制御機能を備えている。パワーユーザーにオープンなツールを渡すよりも、シャドーAI（会社に無断でAIを使用する問題）対策としてはるかに優れた回答だ。またマイクロソフトは、プロビジョニングをアプリに組み込むのではなく、バックエンドプラットフォームである「Agent 365」と「Work IQ」を通じて処理している。
Copilot Coworkのトレードオフも同じくらい明確だ。クラウド専用でローカルファイルシステムはなく、個人用コンテキストに関する説明も不明瞭で、価格体系は階層的で、Microsoft 365 Copilotライセンスに加えて消費課金が上乗せされる。ほとんどの企業にとって、これは妥当な取引だ。だがローカルAI（端末内で完結するAI処理）派にとっては、受け入れがたい条件である。
Amazon Quick
アマゾンが投入したのがQuick（クイック）だ。これはAWSが2025年後半にリリースし、機能拡張を続けているものである。コンセプトはCopilot Coworkに近いが、設計思想の違いは興味深い。マイクロソフトがバックエンドプラットフォームに依拠するのに対し、アマゾンはこれらの機能を製品自体に組み込んでいる。プロビジョニングはQuick内部で集中管理される。
Quickもメモリーと個人用コンテキストストアを2つの別個の構成要素として扱っており、これは正しい判断だ。個人用ナレッジグラフは、エージェントが管理するメモリーとして機能し、セッションを越えてユーザーの役割、優先事項、関係性を学習する。一方で、接続されたナレッジベースは、ユーザー自身のファイルや外部情報源を整理して保管するストアとなる。この2つが揃うことで、ユーザーは自ら「セカンドブレイン」を構築する手間から解放される。データ保護もこの製品リリースの大きな目玉であり、セキュリティ、データ主権、プライバシー制御が網羅されている。
1点断っておくと、筆者はQuickは実際に触ったが、Copilot Coworkはまだ触っていない。そのため、両者の使い勝手の比較判断は実機を触るまで控えておく。柔軟性の面では、Quickが今後、より幅広いモデル選択や評価機能を備えたAmazon Bedrock（アマゾン・ベッドロック)のような、アマゾンのよりオープンなAIサービスと同等になることを期待したい。企業の初期の導入コミットメントは大きく、AWSが挙げた事例では、一部の顧客で10万席超のシート（ライセンス）におよぶ展開が計画されている。
エンタープライズ向けAIアシスタント「第1世代」を定義付けるギャップ
これほどの勢いがあるものの、これらはまだ第1世代の製品であり、荒削りな部分も見られる。特に5つのギャップが際立っている。
- 1. エージェントの可搬性 — 人間のアシスタントと同じく、エージェントも一緒に働く期間が長いほど価値が高まり、代替が困難になる。「セカンドブレイン」のような機能を外部化する大きな理由は、それらを異なるエージェントやアシスタント間で持ち運べるからだ。MCPがツールを可搬にしたように、ベンダーはユーザー自身のメモリー、コンテキストストア、成果物を可搬にする仕組みを構築し、新しいエージェントやデバイスの登場に合わせてユーザーと共に移動し、容易にアップグレードできるようにすべきだ。それがなければ、単一の製品に縛り付けられることになる。
- 2. 予算策定を困難にする価格設定 — ユーザー単位のライセンス料金、従量課金、タスクごとの変動コストなどが複雑に絡み合い、支出を予測することは非常に難しい。フルスタックを保有するベンダーはコスト削減を約束するが、顧客が自社の財務分析でそれを確認できるまでは、そうした主張は未実証のものとして扱うべきだ。
- 3. 見せかけではない、本質的なガバナンス — 筆者がERPに関する最近のレポートで論じたように、意思決定プロセスに人間が介入する「ヒューマン・イン・ザ・ループ」という仕組みは、効果的な管理ポイントというよりも、簡単に無視できる単なる通知になってしまっていることが多すぎる。承認者が、適切に評価するための文脈（コンテキスト）を持たずにアラートを受け取ると、反射的に「はい」をクリックしてしまいがちだ。人間の介入を有意義なものにするのはインフラの問題であり、UI（ユーザーインターフェース）のチェックボックスを増やすことではない。そして、現在の製品のほとんどはまだそのレベルに達していない。
- 4. 異なるベンダー間の相互運用性 — A2A（Agent-to-Agent、エージェント間連携）のような標準規格は、机上では魅力的に見えるが、異なるベンダーのエージェント間での実業務レベルでのデータの受け渡しは、まだほとんど実証されていない。マルチベンダー環境を構築している企業にとって、このギャップは無視できない。
- 5. スプロール化と評価 — 導入を促進するノーコードの容易さは、スプロール化（システムの乱立）、セキュリティの形骸化、メンテナンスされない技術的負債といった、かつての「市民開発者（シチズンデベロッパー）」がもたらした病理を再び呼び寄せる。明るい兆しは、エージェントのシミュレーション、異常検知、可観測性の向上により、AI開発者が何を行っているかを今やAI自身が監視できるようになっている点だ。この第1世代の製品が、市民開発を最終的に管理可能なものにできるかどうかは、筆者が最も注視している未解決の課題である。
エンタープライズ向けアシスタントにとって、これらは「出発点」であり「ゴール」ではない
これらは決してテクノロジーを否定しているわけではない。現在の立ち位置を示した地図のようなものだ。「Claude化」のトレンドは、人々がAIとどのように関わるかにおける、持続的な変化であると筆者は信じている。しかし、既存のソフトウェア企業がこれを定着させるには、2つのことを行う必要がある。第一に、パワーユーザーではない90%の一般従業員向けの管理機能を構築すること。第二に、これらのアシスタントを使って、単なるメールの要約やチャットにとどまらない、自社のAIの真の実力を示すことである。マイクロソフトとAWSは、ともに信頼できるスタートラインに立った。だが、スタートラインはゴールではない。
