Project Solaraとは？エージェントOSの特徴や対応デバイスを徹底解説

Project Solara（プロジェクト・ソラーラ）は、Microsoftが2026年6月2日のMicrosoft Build 2026で発表した、エージェントファーストデバイス向けの新プラットフォームです。
従来のWindowsではなく、Teams会議室ハードで実績のあるMDEP（Microsoft Device Ecosystem Platform：AOSPベースのエンタープライズOS）を採用し、Badge・Deskの2つのコンセプトデバイスを通じて「アプリを開く」から「エージェントを呼び出す」への転換を狙います。
クラウド側はAzure上のAgent Shellで複数エージェントを動的に読み込み、Microsoft 365 CopilotやResearcher・Facilitatorなどが端末・クラウドを横断する「Liminal OS」として設計されています。

本記事では、Project Solaraの全体像とアーキテクチャ、2つのコンセプトデバイス、AccuWeather・Best Buy・CVS Health・Levi's・Targetなどパイロット企業の構成、Microsoft 365 Agents SDK／Microsoft Agent Frameworkとの連動、Windows・Surfaceとの位置関係、Humane AI Pin・Rabbit R1などの先行事例との比較、そして企業が今からProject Solara世代に備えるための実務指針までを、2026年6月時点の最新情報で解説します。

Project Solaraとは？

Project Solara（プロジェクト・ソラーラ）は、Microsoftが2026年6月2日のMicrosoft Build 2026で発表した、エージェントファーストデバイス向けの新プラットフォームです。

公式ブログCommand Lineの発表記事では、Solaraの使命を「アプリからエージェントへ」「ソフトウェアを開くのではなく、知能を呼び出す」プラットフォーム転換と位置づけています。

MicrosoftがBuild 2026で発表したProject Solara（出典：Microsoft Command Line）

Project Solaraが既存のAIエージェント関連製品と決定的に違うのは、チップ・OS・クラウドまでを一気通貫で再設計し、デバイスそのものをエージェント前提に組み直した点です。

Microsoft 365 CopilotやCopilot Studioなどは「既存のWindows・Webアプリ上にエージェントを足す」設計でしたが、Solaraは端末を開いた瞬間にエージェントが立ち上がることを前提に、デバイスの形・OS・認証経路までを再構築しています。

Microsoft Build 2026の中でのProject Solaraの位置づけ

Project Solaraは、Build 2026で発表された一連の「エージェント基盤」群のなかで、エージェントファーストデバイスを前面に出した代表的な発表です。Build 2026では他にもRTX Spark Dev Boxなどハードウェア関連の発表がありましたが、デバイス・OS・クラウド・SDKまでを「エージェントファースト」の前提で一貫して再設計したのはSolaraの特徴です。

以下の表で、Build 2026で発表された主要なエージェント関連プラットフォームのなかでProject Solaraがどこに位置するかを整理しました。

発表名	レイヤー	役割
Project Solara	デバイス＋OS＋クラウド	エージェントファーストデバイスのリファレンスプラットフォーム
Microsoft Foundry	クラウド	エージェント開発・運用基盤（Azure側のエージェントランタイム）
Microsoft Scout	サービス	M365内で動く自律エージェント
Web IQ	API	エージェント向けWebグラウンディングAPI
Microsoft Agent Framework 1.0	SDK	エージェント構築フレームワーク（2026年4月にGA・Build 2026で関連アップデート）
Microsoft 365 Agents SDK	SDK	M365内で動くエージェント開発フレームワーク（ドキュメント公開済み）

表の通り、Solaraは「エージェントが動く場所」自体を作る発表で、他の発表は「エージェントの中身・つなぎ先」を整える発表という構図です。

このレイヤー差を理解すると、Build 2026全体の方向性が見えやすくなります。Microsoftは「エージェントの作り方（SDK）」「エージェントの動かし先（Foundry）」「エージェントから引ける情報源（Web IQ）」「自律エージェントの完成形（Scout）」を整えたうえで、**最後に「そのエージェントが住むデバイス」**としてSolaraを置きました。

Project Solaraが解こうとしている課題

Solaraが解こうとしているのは、**「PCで動くエージェントとモバイルで動くエージェントの分断」**という、これまでAIエージェントが企業現場で広がるうえで最大の制約だった問題です。

現状、Microsoft 365 CopilotやChatGPTのモバイルアプリは、PCと比べてできることが限られています。フロントライン作業者（現場・医療・小売）や、デスクワーカーが移動中に使いたいエージェント用途は、PC用のエージェントをスマホに無理矢理移植する設計ではカバーしきれません。

そこでMicrosoftは、「PCのエージェント体験を縮めたモバイル」ではなく、「エージェント前提で作り直した新しいハードウェア」をリファレンス設計として提示しました。これがSolaraの中心的な発想です。

業界全体としても、エージェント特化デバイスへの挑戦はHumane AI PinやRabbit R1など先行事例がありました。Microsoftはこの領域でエンタープライズ統制（Intune・Entra ID）と既存Copilotエコシステムを武器に、消費者向けスタートアップが取れなかった切り口で参入しています。

---

Project Solaraのアーキテクチャ——MDEP・Agent Shell・Just-in-Time UI・Liminal OS設計

Project Solaraの技術構成は、端末側のMDEPとクラウド側のAgent Shellを、Liminal OSという設計思想で結合する三層構造です。

公式ブログでは、Solaraを「Liminal（境界をまたぐ）OS」と表現し、OSがデバイス単体に閉じず、デバイスとクラウドを横断する設計を強調しています。

Project Solaraプラットフォームの3本柱（出典：Microsoft Command Line）

MDEP——Windowsを使わずAOSPを選んだ理由

Project Solaraの端末側OSは、Windowsではなく**MDEP（Microsoft Device Ecosystem Platform）**を採用しています。MDEPはAOSP（Android Open Source Project）をベースに、Microsoftが企業向けに作り直したセキュアなAndroid系OSです。

なぜWindowsではなくMDEPなのか——理由は3つあります。

• 低消費電力デバイスへの最適化
  WindowsはPC・ワークステーション級ハードを前提とする設計で、ウェアラブルやコンパクトデスクデバイスには重い。AOSPベースのMDEPはスマートフォン・タブレットで実績があり、小型・常時稼働デバイスに収まる。
  
  

• 既存のシリコン・ドライバエコシステムを活用
  Qualcomm・MediaTek・Rockchip・NXPなどのシリコンベンダーが既にMDEPに対応しており、各社のSoC上で稼働する。ハードウェア選択肢を広く保てる。
  
  

• エンタープライズ統制の確保
  MDEPはMicrosoft PKI・Intune・Entra IDと連動し、ハードウェアレベルのアテステーション（改ざん検出）まで組み込まれている。Teams Rooms on Androidで既に運用されている統制基盤がそのまま使える。

つまりMicrosoftは「AOSPの軽量さ・互換性」と「Microsoftの管理基盤」を両立させたOSとしてMDEPを育ててきており、Solaraはその到達点として位置づけられます。

Agent Shell——クラウド側で複数エージェントを動的に切り替える

Solaraの中核は、Agent Shellと呼ばれるクラウド側のレイヤーです。Agent Shellは、ユーザーが何をしたいかに応じて、適切なエージェント（Microsoft 365 Copilot・Researcher・Facilitator・社内カスタムエージェントなど）を動的に読み込みます。

従来のOSでは、アプリ単位でフォーカスが切り替わり、ユーザーが目的に応じて「どのアプリを開くか」を判断していました。Agent Shellの世界では、ユーザーは「何をしたいか」だけを伝え、適切なエージェントが裏で選ばれます。

「アプリを選ぶ→操作する」という従来の認知負荷を、「目的を伝える→結果を受け取る」に変えるのが、Agent Shellの設計思想です。

Just-in-Time UI——同じエージェントが端末ごとに最適な姿で現れる

Just-in-Time UIは、同じエージェント体験を、端末ごとに最適なUIで自動展開する仕組みです。

Just-in-Time UIで同じエージェントが4種類のデバイスに姿を変えて現れる様子（出典：Microsoft Command Line）

Solaraの発表で、Microsoftはこの機能を「開発者が各フォームファクター（ウェアラブル/デスク/モバイル/PC）に合わせて再設計しなくても、エージェントUIが自動的に適応する」と説明しています。

たとえばBadge型デバイス（小型ウェアラブル）では音声＋指紋ボタン中心のUIに、Desk型デバイス（モニタ接続）ではキーボード＋画面中心のUIに、同じエージェントが姿を変えて出現します。

これにより、開発者は「エージェントの中身」だけを作れば、UI展開は基盤側が引き受けます。エージェント開発の生産性が、フォームファクター単位ではなく機能単位に集約されることが、Just-in-Time UIの実務的価値です。

Liminal OS——端末とクラウドの境界を越える設計

Solaraの一番ユニークな概念が、Liminal OS（境界をまたぐOS）です。

通常のOSは、CPU・メモリ・ストレージといった1台の端末の中で完結する設計です。Liminal OSは違います。端末側には軽量なシェル（窓）だけを置き、状態・履歴・エージェントの本体はAzure側に常駐させ、ユーザーが触れる端末はどこからでも同じ体験の入口になる設計です。

この設計のおかげで、Badgeから始めた作業をDeskで続け、PCのWindows 365に切り替えても、エージェントが状態を引き継いだまま動作します。

「OSはどの端末にあるか」ではなく「OSは端末とクラウドにまたがっている」と捉え直すのが、Liminal OSの発想です。AI総研の支援現場でも、エージェントの状態管理（コンテキスト・履歴・社内ナレッジへのアクセス権）が複数デバイス間で連続することが、現場でエージェントを定着させる前提条件として浮上しているケースが増えています。

---

Project Solaraの2つのコンセプトデバイス——Badge と Desk

Project Solaraと一緒に発表されたのは、リファレンス設計としての2つのコンセプトデバイスです。製品名ではなくリファレンスデザインなので、最終的には複数のOEMから派生製品が出ることが想定されます。

以下の表で、2つのコンセプトデバイスの特徴を整理しました。

項目	Badge（ウェアラブル）	Desk（据え置き型）
形状	社員IDカード型ウェアラブル	デスクに置くコンパニオンハブ
SoC	Qualcommウェアラブル向けSoC	MediaTek IoT向けSoC
認証	指紋ボタン	Hello for Business（顔認証）
主要操作	指紋ボタン→エージェント起動／ワンタップ録音	音声操作／UWBセンサーでの近接検知
拡張性	内蔵カメラ・5G/WiFi/Bluetooth	USB-Cでモニタ接続→Windows 365クライアント化
想定ユーザー	現場作業者・医療従事者・移動の多い情報ワーカー	デスクワーカー・PCコンパニオン・小規模ハドルスペース

2つのデバイスは、用途を分けるのではなく、1人のワーカーが同じエージェントを場面ごとに違う形で呼び出す前提で設計されています。Badgeは現場・移動中、Deskは執務中、Windows 365 PCは集中作業時、というように。

Badge——「AIを社員証に埋め込む」発想

Badge型は、Bloombergが単独で特集したように「社員IDカードを再発明したデバイス」です。

Project Solara Badge コンセプトデバイス（出典：Microsoft Command Line）

社員証としての物理的な機能（オフィスゲート・ロッカー・退館記録）はそのままに、指紋ボタン1つで端末上のエージェントが立ち上がります。録音ワンタップで会話を文字起こしし、内蔵カメラはエージェントが「ユーザーが何を見ているか」を把握する入力デバイスになります。

想定ユーザーは、現場で両手が塞がっている看護師・倉庫作業者・店舗スタッフ、または移動中で重いノートPCを開けない営業職などです。

「PCの前に座らないと使えないエージェント」を、「胸ポケットに常駐しているエージェント」に変えるのが、Badge型のコンセプトです。

Desk——コンパクトハブとしての据え置き型

Desk型は、デスクに置いて使うコンパクトなコンパニオンハブです。

Project Solara Desk コンセプトデバイス（出典：Microsoft Command Line）

顔認証（Windows Hello for Business）でサインインし、音声で当日のタスクをエージェントに依頼します。USB-Cでモニタを接続すると、クラウド上のWindows 365に接続したフル機能のWindows端末として動作するため、1台でエージェントハブとPC両方の役割を兼ねることができます。

UWB（Ultra-Wideband）センサーが搭載されているのも特徴で、ユーザーが近づくと自動的にサインイン状態になります。

想定ユーザーは、デスクワーカーの個人席、小規模のハドルスペース、コンシェルジュ受付、医療カウンセリングルームなどです。

「PCの隣に置く小さなコンパニオン」として始まり、必要に応じて「クラウドPCのフロントエンド」にもなる二段構えが、Desk型の特徴です。

コンセプトデバイスがあくまで「リファレンス」である理由

注意したいのは、BadgeもDeskも**コンセプトデバイス（リファレンス設計）**であり、Microsoftが直接販売する製品ではないという点です。

Microsoftの位置取りは「プラットフォーム提供者」であり、ハードウェア自体はMDEPに対応したOEMが各社の判断で製品化していく構図です。

これは、Microsoftが過去にWindows PhoneやSurface PhoneでOEM主導の市場形成に失敗した経験を踏まえた判断と読めます。Microsoftはハード単独で勝つのではなく、エージェント基盤・クラウド・SDK・統制で勝ち、ハードはOEMとパイロット企業に任せる構図です。

---

Project Solaraのパイロット企業——AccuWeather/Best Buy/CVS Health/Levi's/Target

Project Solaraは現時点で一般販売されていませんが、AccuWeather・Best Buy・CVS Health・Levi's・Targetなど複数社とのパイロットが公式に発表されています。Microsoft公式の表現は「これらの企業などと今後数か月以内にデバイスのテストを開始する」というもので、現時点でパイロットが進行中なわけではなく、開始予定の段階です。

公式発表時点で各社の具体的な実装計画までは公開されていませんが、業種特性から想定される用途を整理することで、Solaraがどんなフロントライン業務に適合するかが見えてきます。

以下の表で、各社の想定用途を業種特性から整理しました。

企業	業種	想定されるSolara活用シナリオ
AccuWeather	気象情報	災害対応現場での気象データ・予測のリアルタイム取得、放送現場でのアナウンサーアシスト
Best Buy	家電量販店	店舗スタッフのBadge装着→顧客の質問にエージェントが商品仕様・在庫を回答
CVS Health	医療・薬局	薬剤師・看護師のBadge装着→処方確認・服薬指導の音声記録と要約
Levi's	アパレル	店舗スタッフの接客サポート、在庫照会、デザイン現場でのコラボレーション支援
Target	小売	店内スタッフのBadge装着→棚卸し・顧客対応・本部指示の双方向連携

代表5社に共通するのは、「PCの前に座らないフロントライン作業者」が多数を占める業種である点です。これがSolaraの主戦場として想定されている領域です。

想定パターン1: 店舗スタッフのBadge装着（Best Buy/Levi's/Target）

家電量販店・アパレル・小売の3社は、共通して「店舗スタッフがBadgeを装着し、接客中にエージェントが業務支援する」シナリオが想定できます。

たとえば家電量販店なら、顧客から「このテレビとあのレコーダーは接続できる？」と聞かれたとき、Badgeのエージェントが商品仕様・互換性情報を即座に返します。スタッフがマニュアルや在庫端末を確認しに離れる必要がなくなり、接客時間を維持できます。

ここで重要なのは、スタッフはエージェントを「操作」していないことです。会話の流れのまま、エージェントが背後で情報を引き、必要なときだけ画面で確認する。これが「アプリからエージェントへ」の店舗版です。

想定パターン2: 医療・薬局でのBadge装着（CVS Health）

CVS Healthは米国最大級の薬局チェーンで、薬剤師・看護師が現場で多数の患者対応を行います。

Badgeのワンタップ録音機能は、薬剤師の服薬指導・処方確認の音声記録と即時要約に直結します。HIPAA等の医療データ規制をクリアするためのIntune・Entra ID連動と、MDEPのハードウェアアテステーションが、エンタープライズグレードの統制を可能にします。

医療現場はDragon Copilotのように既にAIアシスタントの導入実績があるため、Solaraはその延長として現場ワークフローに組み込みやすい領域です。

想定パターン3: 災害・気象現場でのリアルタイム情報取得（AccuWeather）

AccuWeatherは気象データを扱う特殊な業種で、災害対応・テレビ放送・モバイルアプリ配信の現場で動きの速い情報処理が求められます。

Solaraの利用シナリオとしては、災害現場のスタッフがBadgeを装着し、「現在地の予測降水量を教えて」と話しかけるだけで、Agent Shellが社内データ・公開気象データを引いて回答するパターンが想定されます。Just-in-Time UIによって、Badgeでは音声中心、Deskでは地図UI中心、と同じエージェントが場面ごとに違う姿で応えます。

代表5社共通の含意——フロントラインAIの「ハード制約」が外れる

これら複数社のパイロットに共通する含意は、フロントライン業務にAIエージェントを浸透させる際の「ハードウェア制約」をMicrosoftが正面から外そうとしている点です。

これまでフロントラインAIは「スマートフォンに無理矢理ChatGPTアプリを入れる」「スマートウォッチに簡略版を組み込む」など、消費者向けハードの上にエンプラエージェントを乗せる工夫でしのいできました。Solaraは「フロントライン業務に最適化されたエンプラ専用ハード」をリファレンスとして提示することで、この制約を構造的に解消しようとしています。

導入判断で詰まりやすい論点は、「フロントライン業務の中で、エージェント化が最初に効くのはどのタスクか」「Badge型とDesk型をどう組み合わせるか」の2点です。AI総研の支援経験から言えば、まずは「音声で記録・要約する業務」（接客記録・服薬指導・点検報告）から始めるのが現実的で、その後に対話型エージェント、最後に自律型エージェントへと段階展開する方が定着しやすい傾向があります。

---

Project Solara向け開発——Microsoft 365 Agents SDK・Microsoft Agent Framework・Copilot Studio

Project Solaraのデバイスで動くエージェントを作るための開発エコシステムも、Build 2026で同時にアップデートされました。中心となるのはMicrosoft 365 Agents SDKとMicrosoft Agent Framework 1.0の2つです。

このセクションでは、Solara向けに新規SDKを学ぶ必要があるのか、それとも既存のCopilot資産がそのまま使えるのかを整理します。結論を先に言うと、既存のCopilotエコシステムをほぼそのまま延長して使える設計になっています。

Microsoft Agent Framework 1.0——2026年4月GA・Build 2026で関連更新

Microsoft Agent Framework 1.0は、2026年4月3日に正式GA（一般提供開始）し、Build 2026で関連アップデートが紹介されたエージェント構築フレームワークです（公式アナウンスはMicrosoft Agent Framework Blog）。

Microsoft Agent Factoryの3層構成（出典：Microsoft Foundry Blog）

主な特徴は以下のとおりです。

• 対応言語
  Python・.NETの2言語に対応。既存のMicrosoftスタックの開発者がそのまま使える。
  
  

• 対応プロバイダ
  Microsoft Foundry・Anthropic（Claude）・Azure OpenAI・OpenAI・Ollamaに対応。マルチプロバイダ構成が前提。
  
  

• エージェントハーネスの抽象化
  スキル・コンテキスト・メモリ・ミドルウェアを「ファーストクラスの概念」として扱う設計。プロダクションレベルの運用に必要な要素が標準装備。
  
  

• Voice Live統合
  Voice Liveとの統合により、Badgeデバイスのような音声中心UIに直接対応できる。

つまりMicrosoft Agent Frameworkは、Solaraの「エージェントが端末を超えて動く」前提に合わせて、マルチプロバイダ・マルチモーダル・マルチデバイスの3点を最初から組み込んだフレームワークとして提供されています。

Microsoft 365 Agents SDK——M365内エージェントの開発フレームワーク

Microsoft 365 Agents SDKは、Microsoft 365内で動くエージェントを開発するためのSDKです。

Microsoft Agent Frameworkとの違いは、Microsoft 365 Agents SDKがM365のユーザー・データ・ライセンス境界の中で動くエージェントに特化している点です。Teams・Outlook・SharePoint・OneDriveのユーザーコンテキストを引き継いだエージェントを開発できます。

Build 2026でのアナウンスでは、Microsoft 365 Agents SDKはframework-agnostic（フレームワーク非依存）になり、以下のSDKと組み合わせて使えるようになりました。

• Microsoft Agent Framework
• OpenAI Agents SDK
• LangChain
• Semantic Kernel
• Azure AI Foundry

この設計のおかげで、既存のLangChain・Semantic Kernelで作ったエージェントを、Microsoft 365のコンテキストに乗せ直して動かすことが可能です。過去のエージェント資産を捨てずに、Solara・Copilot環境に持ち込めることが、開発者にとっての最大の実務的価値です。

Copilot Studioとの関係——ノーコード／プロコードのレイヤー分担

エージェント開発のもう一方の入口が、ノーコードでエージェントを構築できるCopilot Studioです。

Microsoft 365 Agents SDK・Microsoft Agent Frameworkがプロコード（コード書く）で開発する層なのに対し、Copilot Studioはノーコード／ローコードで業務エージェントを組み立てる層です。

以下の表で、3層の役割分担を整理しました。

ツール	レイヤー	想定ユーザー
Copilot Studio	ノーコード／ローコード	業務部門のIT担当・市民開発者
Microsoft 365 Agents SDK	プロコード（M365コンテキスト）	社内開発者（M365統合のエージェント）
Microsoft Agent Framework	プロコード（汎用）	社内開発者（マルチプロバイダ・複雑なエージェント）

この3層は競合関係ではなく、同じCopilotエコシステムの中で「複雑さ」に応じて選び分ける構成です。簡単な業務エージェントはCopilot Studioで、M365内の業務統合はAgents SDKで、独自要件の高いプロダクト級エージェントはAgent Frameworkで、というレイヤー分担です。

Solara対応のエージェント開発も、この3層から好きな入口を選んで始められます。既にCopilot Studioでエージェントを作ったことがあれば、Solara向けにゼロから学び直す必要はありません。

Solara対応の開発で重要な前提

Solaraデバイス向けにエージェントを作る際に、開発者が押さえておくべき前提は以下のとおりです。

• エージェントの本体はクラウド側（Agent Shell）に置く
  端末側のMDEPは軽量シェルだけで、エージェントロジックはAzure上のAgent Shellに常駐する。デバイスごとに分散実装しない。
  
  

• Just-in-Time UIに依存する設計
  UIをデバイスごとにハードコードしない。エージェントの「機能仕様」だけを記述し、UI展開は基盤側に任せる。
  
  

• マルチモーダル前提
  Badgeでは音声入力・カメラ入力・指紋ボタン、Deskでは音声・顔認証・UWB近接センサーが入力経路になる。テキスト前提の設計だと、Solaraの強みを活かせない。

これらは従来のCopilot拡張開発とは違う発想が必要な部分です。「特定の画面に張り付くエージェント」から「複数デバイスに姿を変えて出現するエージェント」への発想転換が、Solara対応開発の本質的な学習コストになります。

---

Project SolaraとWindows・Surfaceの関係——競合ではなく補完

Project Solaraが発表されたとき、業界内で最初に問われたのは「Windowsはどうなるのか」という問いでした。

Microsoftの社内資料では、SolaraはWindows・Surfaceと競合する製品ではなく、補完する位置づけと説明されています。このセクションでは、3者の役割分担を整理します。

Windowsの位置づけ——集中作業のメインプラットフォーム

Windowsは引き続き、集中作業・コンテンツ制作・開発・複雑なアプリケーション運用のメインプラットフォームです。

Build 2026のWindows Developer Blogでは、Windowsを「開発者にとっての信頼できるプラットフォーム」と位置づける発表が並行して行われており、Windowsはエージェント時代でも開発・コンテンツ制作の中核として位置づけが強化されています。

Solaraが代替するのはWindowsではなく、「Windowsを開くほどではないが、何かをエージェントに依頼したい瞬間」の方です。会議室で議事録をとる、店舗で顧客対応する、現場で作業報告するといった場面で、PCを開くことが過剰または非現実的なときにSolaraデバイスが入る、という分担です。

Surfaceの位置づけ——プレミアムWindowsデバイスとの併存

Microsoftの自社ハードウェアブランドであるSurfaceも、Solaraと併存します。

Surfaceは引き続き、Windowsをフル機能で動かすプレミアムなノートPC／ハイブリッドデバイスとして展開されます。Surface Pro 12インチ・Surface Laptop 13インチなど、AI機能を内蔵したCopilot+ PC路線が継続される見込みです。

以下の表で、3つのデバイスカテゴリの位置づけを整理しました。

デバイスカテゴリ	OS	主用途	想定ユーザー
Solaraデバイス（Badge/Desk）	MDEP	エージェント呼び出し・現場業務	フロントライン・移動中・短時間タスク
Surface（Copilot+ PC）	Windows	フル機能PC・コンテンツ制作	デスクワーカー・開発者・クリエイター
Windows 365	Windows（クラウド）	場所を選ばないPC体験	リモートワーカー・短期契約者・BYOD環境

3つは競合ではなく、「1人のワーカーが状況に応じて使い分ける」関係です。Solaraデバイスは「日常の呼び出し」、Surfaceは「集中作業」、Windows 365は「クラウドPC」、というように。

特に注目すべきは、SolaraのDeskデバイスはUSB-Cでモニタを接続するとWindows 365クライアントになる点です。1台のハードウェアが、エージェントハブとクラウドPCの二役を兼ねます。

DeskデバイスにモニタとキーボードをつなぐとWindows 365クライアントとして動作する（出典：Microsoft Command Line）

Windows AI Foundryとの接続——ローカル推論との二段構え

Solaraのエージェントはクラウド側で動くのが基本ですが、MicrosoftはWindows AI FoundryでWindowsデバイスでのローカルAI推論も並行して進めています。

Solara（クラウド推論）とWindows AI Foundry（ローカル推論）は対立する選択肢ではなく、遅延・プライバシー・コストの3軸で使い分ける関係です。リアルタイム性が求められる現場操作はローカル推論、複雑な業務エージェントはクラウド推論、というように。

このように、Solaraは「Windowsを置き換える新OS」ではなく、「Windowsだけではカバーしきれなかった瞬間・場面を埋めるエージェント特化基盤」として理解するのが正確です。

---

エージェントOS競争——Humane AI Pin・Rabbit R1・Apple Intelligenceとの位置関係

Project Solaraはエージェント特化デバイスとして注目されていますが、この領域には先行する取り組みがいくつかありました。Microsoftが「消費者向けスタートアップが失敗した領域に、エンプラ統制を武器に入る」という構図は重要です。

このセクションでは、Solaraと先行プレイヤーの位置関係を整理します。

Humane AI Pin——HPに買収され即廃止

Humane AI Pinは、2024年に発売された胸につけるバッジ型AIデバイスで、Solaraの先行事例として最もよく引き合いに出されます。

しかし、$230Mを調達し1万台に満たない販売数のまま、2025年2月にHPに$116Mで買収され、即座に製品廃止されました。失敗要因は、AI処理の遅さ・ハードウェアの不安定さ・$700の本体価格に$24/月のサブスクという料金設計、などが指摘されています。

Humane AI Pinが失敗した最大の理由は、「消費者向けAIデバイス」としてChatGPTやSiriと比較された際に、専用ハードを買う動機を作りきれなかったことです。ChatGPTが既にスマホで動く時代に、AI特化の追加ハードを買う理由が弱かったわけです。

Solaraがこれと違うのは、B2Cではなくエンプラフロントライン向けである点と、1人で完結する体験ではなくクラウド側のエージェント基盤・統制システムとセットである点です。消費者の「スマホがあるのに別ハードを買う理由」を作る必要はなく、企業の「フロントライン業務を効率化する設備投資」として正当化されるロジックになっています。

Rabbit R1——rabbitOS 2で継続中・事業課題が報じられる

Rabbit R1は10万台を販売した後、大量返品と財政懸念の報道が続きました。製品自体は公式に2025年9月リリースのrabbitOS 2へ移行し、販売・更新も継続しています。

rabbitOS 2では、当初の「自律エージェント」コンセプトから「AIエージェントアシスタント」へとポジショニングを修正しました。Rabbit CEOのJesse Lyuは2026年に「次世代3-in-1デバイス」のリリースを示唆していますが、財政基盤への懸念報道は続いています。

Rabbit R1が苦戦している構造は、Humane AI Pinと共通する部分があります。消費者向けに自律エージェントを売ろうとしたものの、消費者の生活シーンに自律エージェントが入る具体的な必要性が見えにくいため、製品は継続しているものの「面白いけど使い続ける必然性を確立しきれていない」状態が報じられています。

Apple Intelligence・Google Pixelのエージェント構想

Apple（Apple Intelligence）とGoogle（Pixel + Gemini）も、エージェント機能を既存のスマートフォン・タブレットに統合する方向で動いています。

両社の戦略はSolaraと正反対で、「既存の消費者向けOS（iOS/Android）にエージェント機能を後付けする」アプローチです。新しいハードを作らず、既存ハードを進化させる路線です。

以下の表で、4つの戦略の違いを整理しました。

プラットフォーム	アプローチ	対象市場	統制基盤
Project Solara（Microsoft）	エージェント特化ハード＋クラウド基盤の新規構築	エンプラ（フロントライン中心）	Intune・Entra ID（既存活用）
Apple Intelligence	iOS/macOSへのエージェント統合	コンシューマ＋エンプラ	MDM（既存活用）
Pixel + Gemini（Google）	Android／Pixelへのエージェント統合	コンシューマ中心	Workspace（限定的）
Humane AI Pin（廃止）／Rabbit R1（rabbitOS 2で継続中・財政課題報道あり）	エージェント特化ハード（B2C）	コンシューマ	なし

表の対比から見える重要なポイントは、B2C向けのエージェント特化ハードは継続的な成功例が乏しいこと、B2C向けには「既存OSへの統合」が主流であること、そして大手プラットフォーマーとして、B2Bフロントライン向けエージェント特化ハードを前面に出したMicrosoftの動きが現時点で目立つ位置にあることです。

Solaraの差別化——「エンプラ統制をハード設計から組み込む」発想

業界全体を俯瞰すると、Solaraの差別化軸は「エンプラ統制をハードウェア・OS・クラウドの全レイヤーから設計」という1点に集約されます。

具体的には以下の3点が、消費者向けスタートアップでは到達できない領域です。

• ハードウェアアテステーション
  MDEPはシリコンレベルで改ざん検出可能。エンプラのIT部門が要求する統制水準を満たす。
  
  

• Intune・Entra ID統合
  既存のM365企業ライセンスでデバイス管理・ID統制が可能。新規IDMSの導入が不要。
  
  

• Microsoft Agent Framework・Foundryとの一体運用
  エージェントの中身・つなぎ先・統制が同じMicrosoftエコシステムで完結。マルチベンダー構成の運用負荷がない。

消費者向けスタートアップは、これらをゼロから構築する余力がなく、結果として「面白いハードだが企業のIT部門が承認しない」状態に陥っていました。Microsoftはこの統制の壁を既存基盤で乗り越え、エンプラのフロントライン市場に正面から入る戦略を取っています。

つまりSolaraは「Humane AI PinやRabbit R1の改良版」ではなく、そもそも別市場（B2Bフロントライン）に向けて作られた、別カテゴリの製品として理解する必要があります。

---

企業がProject Solara世代に備える実務指針

Project Solaraは現時点でパイロット段階のリファレンス設計で、日本企業がすぐに導入できる段階ではありません。それでも、Solaraが示す方向性は、すべての日本企業のエージェント戦略に影響します。

本セクションでは、AI総合研究所が支援している企業の傾向を踏まえ、業態別に「いま何をすべきか」を整理します。

「Solaraにすぐ手が届かない企業がいますぐやること」一覧

ほとんどの日本企業はSolaraのパイロット対象にはなりません。だからこそ、業態ごとに「現行Copilot資産で先回りする打ち手」と「Solara世代のエージェント時代に備える判断軸」を整理しておく価値があります。

以下の表で、5タイプ別の優先度の高いアクションをまとめました。

対象企業	いますぐやること	Solara世代の判断基準
大手フロントライン業（小売・医療・物流）	Badge型相当の業務シナリオを社内検討、現行スマホ/タブレット＋CopilotエージェントでPoC	自社の店舗・現場・移動業務にBadge型ハードを入れるROIが描けるか
自社プロダクト開発企業	Microsoft 365 Agents SDK・Microsoft Agent FrameworkでエージェントPoC開始	エージェント本体をクラウド側に置く設計（端末非依存）になっているか
情報システム部門	Intune・Entra IDの企業ライセンス整理、デバイス統制ポリシーの棚卸し	新カテゴリのエンプラデバイス（MDEP対応OEM製品）が出てきたとき即承認できる体制があるか
AIエージェント運用部門	Copilot Studioで部門エージェントを内製、業務別ユースケースの棚卸し	Just-in-Time UI前提の「機能ベース」のエージェント設計に切り替えられているか
経営層・CIO層	エージェント時代のハードウェア投資見込みを中期計画に組み込む	フロントラインAI投資が情報システム費ではなく業務改革予算で正当化できる仕組みがあるか

この表を踏まえ、各業態の背景を以下で深掘りします。

フロントライン業（小売・医療・物流）の場合

Solaraのパイロット対象として公式に挙げられたAccuWeather・Best Buy・CVS Health・Levi's・Targetが示すように、Solaraの最大の主戦場はフロントライン業です。

日本の小売・医療・物流企業も、同じ方向のニーズを抱えています。店舗スタッフが商品仕様を即答できない、看護師が記録と現場対応を両立できない、ドライバーが配送ルート変更を本部に共有しにくい——こうした制約はすべて、「PC前提のIT基盤がフロントラインに届いていない」ことに起因します。

すぐ取り組めるのは、現行のスマートフォン・タブレット＋Microsoft 365 Copilotエージェントで「Solara世代でやりたいこと」のPoCを始めることです。Badge型ハードはまだ手に入りませんが、エージェントロジック・業務シナリオ・効果測定は今から検証できます。

数年後にSolara対応ハードが市場に出てきたとき、業務シナリオがゼロベースの企業と、PoC経験を持つ企業では、立ち上がりのスピードに圧倒的な差がつきます。

自社プロダクト開発企業の場合

自社でSaaS・モバイルアプリ・社内システムを開発している企業は、エージェントの設計思想自体をSolara前提に切り替える段階に来ています。

具体的には、エージェントの本体をクラウド側（Microsoft Foundry / Agent Frameworkなど）に置き、UIは端末ごとに薄く再展開する設計に揃えることです。「この画面に張り付くエージェント」ではなく「この機能を提供するエージェント」として定義し、UI展開を後段に分離する発想転換が必要になります。

Microsoft 365 Agents SDKはドキュメント公開済み、Microsoft Agent Frameworkは2026年4月にGA済みのため、Solaraハードが届く前から開発を始められます。既存のLangChain・Semantic Kernelで作ったエージェントも、Microsoft 365 Agents SDKで包み直してM365コンテキストに乗せられます。

情報システム部門の場合

情報システム部門は、Solara対応OEM製品が市場に出てきたときに即承認できる体制を整えることが、いま取り組める一番の準備です。

具体的には以下の3点が優先度の高い棚卸しです。

• Microsoft 365企業ライセンスの統合状態
  Intune・Entra IDが企業全体に展開されているか。一部部門のみカバーだとSolara導入時に追加コストが発生する。
  
  

• モバイルデバイス統制ポリシー
  ハードウェアアテステーション・ゼロタッチプロビジョニング等、MDEPデバイスを受け入れる際の運用基準が決まっているか。
  
  

• 業務部門との連携体制
  新カテゴリのデバイスを業務部門が試したいと言ったときに、評価・承認・展開のプロセスが回るか。

これらは「Solaraが来てから整える」と間に合わない領域です。エージェントデバイスは2026〜2027年にかけて急速に拡大する可能性があるため、その前のリードタイムをこの数か月で稼ぐ意味は大きくなります。

エージェント運用部門の場合

すでにCopilot Studio・Microsoft 365 Copilotエージェントを運用している部門は、設計思想をJust-in-Time UI前提に切り替える準備を始められます。

具体的には、エージェントの仕様書を「画面の構造」ではなく「機能・トリガー・出力フォーマット」で記述する習慣に切り替えることです。同じエージェントがTeams・Outlook・モバイル・将来のSolaraデバイスで姿を変えて出現することを前提に、UI記述を後段に分離します。

Microsoft 365 Copilotエージェント活用事例で整理されている業務別ユースケースは、Solara時代でも引き続き有効です。エージェントの中身が変わるのではなく、その入口（デバイス）が増えるだけだからです。

経営層・CIO層の場合

経営層・CIO層が押さえるべきは、エージェント時代のハードウェア投資が「情報システム費」ではなく「業務改革予算」として正当化される構造を作ることです。

Solaraデバイスは、PCの置き換えではなく業務プロセスの置き換えです。1人にBadge型を渡すことで、店舗業務の接客時間が伸び、医療業務の記録工数が減り、現場業務の本部連携速度が上がる——こうした効果は業務KPIで測られるべき投資であり、IT部門単独で正当化するのは難しい領域です。

中期計画の中で「フロントラインAI投資」「エージェントデバイス予算」を明示的な項目として置くことが、Solara世代の到来に備える経営層の最初の打ち手になります。

---

Project Solaraの料金・提供開始時期・パイロット参加方法

Project Solaraは現時点でMicrosoftが直接販売する製品ではなく、料金もパイロット参加方法も限定的にしか公表されていません。本セクションでは、現時点で分かっている情報と、企業が今後ウォッチすべきポイントを整理します。

現時点で公表されている情報

公式発表で確定している情報は以下のとおりです。

• コンセプトデバイスの料金は未公表
  BadgeおよびDeskは「リファレンスデザイン」であり、最終販売価格はOEMが個別に決める想定。Microsoft直接販売は予定されていない。
  
  

• パイロット参加企業は複数社
  AccuWeather・Best Buy・CVS Health・Levi's・Targetなどとのパイロットが公式発表。「coming months（数か月以内）」にデバイスのテストを開始する見込みで、現時点で進行中ではない。
  
  

• 一般販売・日本市場展開のタイムラインは未公表
  Microsoftは「アーリーアクセスを希望する組織はパートナー経由で問い合わせ」と案内しているが、具体的な提供開始日は出ていない。

つまり、現時点では「料金・販売時期・地域展開はすべて未確定」が正確な状態です。企業として確実に分かっているのは、隣接基盤であるMDEPが既に運用済み、Microsoft Agent Framework 1.0は2026年4月にGA、Microsoft 365 Agents SDKはドキュメントが公開済みである点までです（Agent Shell本体の提供状況はMicrosoft公式から明確には示されていません）。

関連する既存料金——「Solara専用の料金体系は未確定」が前提

Solaraデバイス自体の料金は未公表で、Solara上で動くエージェントの課金体系もMicrosoft公式は確定情報を出していません。

ただしSolaraは既存のMicrosoft Foundry・Microsoft 365 CopilotエコシステムにつながるエージェントOSであるため、参考までに現行のMicrosoft 365 Copilot／Azure系の料金が関係する可能性のある領域を以下に整理します。

• エージェント開発・運用: Microsoft Foundry Agent Serviceの料金（Azure上のエージェントランタイム料金）
• エンドユーザーのCopilotライセンス: Microsoft 365 Copilotエージェントのメッセージ単位課金（Pay-as-you-go）
• Intune・Entra IDのデバイス管理: 既存のEMS／Microsoft 365 E5ライセンス
• Microsoft Agent Framework・Microsoft 365 Agents SDK: フレームワーク自体は無料、実行時はAzure・OpenAI等のAPI料金が発生

ただしこれらはあくまで「Solara運用に関係する可能性のある既存料金」であって、Solara固有の料金体系・販売条件はMicrosoft公式から発表されていません。Solara専用の課金構造(デバイス本体価格・Agent Shellの利用権・MDEP管理ライセンス等)は、Microsoftの追加発表を待つ必要があります。

パイロット参加・アーリーアクセスの問い合わせ方法

Solaraのアーリーアクセスを検討する企業は、現時点では以下のチャネルからMicrosoftに問い合わせるのが現実的です。

• Microsoftの担当アカウントチーム経由（既存M365契約があれば最短ルート）
• Microsoftパートナー経由（AI総合研究所のようなMicrosoftパートナー企業を通じた問い合わせ）
• Microsoft Build 2026関連の公式チャネル（commandline.microsoft.com等での公式アップデートの定点観測）

パイロット参加が即承認される領域は限定的ですが、業務適合性が高い企業（フロントライン業務が多い／既存のM365 E5契約がある／Copilot活用実績がある）は、早めに相談しておく価値があります。

中期で見えている提供拡大の方向性

公式発表段階の情報を踏まえると、提供拡大の方向性は以下のように整理できます。

区分	状態	想定タイミング
パイロット企業（AccuWeather・Best Buy・CVS Health・Levi's・Target等）	開始予定	2026年下半期（coming months）
OEM経由のリファレンスデバイス販売	計画段階	未公表
日本市場展開	計画段階	未公表
MDEP・Microsoft Agent Framework等のSDK系	利用可能	MDEPは運用済み・Agent Framework 1.0は2026年4月GA・Agent Shell本体の提供状況は未確認

つまり、ハードウェアもSolara固有の料金・販売条件も「待ち」ですが、周辺のエージェント開発基盤(MDEP・Microsoft Agent Framework等)は既に利用可能な状態になっています。日本企業として現実的な打ち手は、ハードウェアと料金続報を待ちつつ、隣接基盤側で開発・運用準備を進めておくことです。

---

AI Agent Hubでエージェント時代の業務基盤を整える

Project Solaraのようなエージェントファーストデバイスが本格的に普及するまでには、まだ数年の時間があります。

その間に多くの日本企業が直面するのは、「Solaraの登場を待つ」のではなく、「現行のMicrosoft 365 CopilotやAzureのエージェント基盤を、自社の業務にどう組み込み・定着させるか」という、もっと足元の課題です。

AI総合研究所では、エージェント時代の社内基盤設計を体系的に整理した「AI Agent Hub資料」を公開しています。Project Solara世代を見据えて、自社のエージェント運用を今から設計するための第一歩として活用ください。

---

まとめ

本記事では、Microsoftが2026年6月のBuild 2026で発表したProject Solaraについて、全体像とアーキテクチャ・2つのコンセプトデバイス・パイロット企業・開発エコシステム・Windows/Surfaceとの関係・先行事例との比較・企業の備えまで、2026年6月時点の最新情報で解説しました。要点を改めて整理します。

• Project Solaraは「アプリからエージェントへ」のプラットフォーム転換を狙うMicrosoftの新基盤であり、WindowsではなくMDEP（AOSPベース）を採用し、Agent Shell・Just-in-Time UI・Liminal OSという独自の設計思想で端末とクラウドを横断する設計になっている
  
  

• コンセプトデバイスはBadge（ウェアラブル）とDesk（据え置き型）の2種類で、Qualcomm／MediaTekのSoCを採用し、フロントライン業務・医療・小売・気象現場など「PCの前に座らないワーカー」を主戦場として想定している
  
  

• パイロット対象として公式に挙げられたAccuWeather・Best Buy・CVS Health・Levi's・Targetなどの企業群は、フロントライン業務が多い業種に集中しており、店舗スタッフのBadge装着・医療現場の記録支援・災害現場の情報取得など、消費者向けスマホで対応しきれなかった用途が想定されている
  
  

• 開発はMicrosoft 365 Agents SDKと2026年4月にGAしたMicrosoft Agent Framework 1.0が中心で、Copilot Studio・LangChain・Semantic Kernel等の既存資産を捨てずにSolara対応エージェントへ延長できる
  
  

• Humane AI Pin（HP買収・即廃止）/Rabbit R1（rabbitOS 2で継続中・財政課題報道あり）の苦戦を踏まえ、エンプラ統制をハード設計から組み込んだ点が差別化軸で、消費者向けスタートアップが到達できなかったB2Bフロントライン市場に正面から入る戦略を取っている

企業のIT担当・CIO層にとってProject Solaraは、「すぐ導入できるかどうか」よりも「エージェント時代のデバイス・運用基盤を、今から設計し直すきっかけ」として捉えるべき発表です。まずは現行のMicrosoft 365 Copilotエージェント・Microsoft Agent Framework・Copilot Studioで業務PoCを始め、Just-in-Time UI前提のエージェント設計に切り替えておくことが、Solara世代の到来を「待つ」のではなく「使いこなす」側に回るための最も実用的な準備になります。

エージェント時代のフロントライン業務に、ハードウェアからプラットフォーム、クラウド、SDKまでが一気通貫で再設計される——Project Solaraはその転換点を象徴する発表でした。自社のエージェント戦略を整理し直すタイミングとして、まさに2026年下半期が決定的な時期になります。