エージェントAIは「経営」だ――なぜ普通の人が使いこなすのが難しいのか？そしてAI PCはそれをどう解決するのか

AIを1つのチャット窓で使い続けている人に、はっきり言いたいことがある。

1つのAIに何でもやらせるアプローチは、必ず品質の天井にぶつかる。文脈が混濁し、エラーが蓄積し、品質保証が自分一人の肩にのしかかる。これは能力の問題ではなく、構造の問題だ。

シリコンバレーのUXデザイナーで、元Google・Amazon・Ciscoのりお氏（クウキデザイン代表）は、この問題を「組織論」で解いた。17年にわたってシリコンバレーの一流チームを観察してきた彼が辿り着いたのは、AIエージェントの運用に人間の組織が何千年もかけて発明した知恵をそのまま適用するという発想だった。

1. エージェントAIを「組織」として動かす

1-1. 優れた組織の4原則

りお氏がAIエージェント設計の根拠とした組織原則は以下の4つだ。

1-2. クウキデザインの18体組織

この原則を実装したのが、りお氏が3ヶ月・1000時間以上をかけて構築した実際の運用システムだ。

1-3. コーディネーション層（イントラネット）

全チームの上には「コーディネーション層」が置かれている。これは企業のイントラネットに相当するもので、2つの要素からなる。

1-4. AIエージェント1体の構成要素

個々のAIエージェントは「Manual・Brain・Desk」の3要素で成り立つ。

2. これは「経営者の仕事」だ

ここまで読んでお気づきだろう。

りお氏がやっていることは、AIを使うことではなく、AIを使う組織を設計することだ。組織図を描く。役割の境界を定める。タスクの権限委譲ルールを決める。暗黙の了解を全て文書化する。イントラネットを構築し、引き継ぎのプロトコルを定める。例外が発生したときのエスカレーション経路を設計する。

これは職業経営者・組織設計者の仕事であり、1000時間以上の試行錯誤の産物だ。

さらに深刻なのは、エージェントAI組織はエラーが無音で発生するという特性だ。人間の部下なら「これ、うまく動いていないんですが」と声を上げる。AIエージェントは誤った設定のまま「完了しました」と報告し続ける。システム全体を定期的に観察する「運用監視」の設計まで求められる。

使いこなせる人間は、組織設計ができる人間に限られる。

3. Copilot+とは何だったのか――そして、なぜ失敗したのか

Microsoft Copilot+ PCは2024年5月に発表された。定義はシンプルで、40TOPS以上のNPU（ニューラルプロセッシングユニット）を搭載したPCだ。

失敗の理由①：既存のワークフローに統合されていない
提供された機能はどれも「単発の便利機能」だ。ユーザーが日常的に行う仕事のフローの中に組み込まれていない。Recallはプライバシー問題で炎上し延期を繰り返し、ASRはGPU（DLSS・FSR）で既に解決済みの問題への二番煎じだった。

失敗の理由②：NPUをユーザーに意識させすぎた
「NPU搭載」「40TOPS」という仕様を前面に出したマーケティングは、そのまま「使いこなすにはNPUを理解する必要がある」という印象を与えた。真のインフラはその存在を意識させない。DNSを使うのにDNSの仕組みを理解しているユーザーは一人もいない。

失敗の理由③：エージェントAI時代の設計思想がなかった
Copilot+ PCが設計された時点でMicrosoftが想定していたのは「AI機能を追加したPC」だった。「AIが主体的にタスクをこなし続けるエージェントの基盤」という発想ではなかった。IntelとAMDのNPUはCopilot+という旗のために慌てて搭載された側面が強く、当初はソフトウェアエコシステムが伴っていなかった。

4. AI PCの本来の意義：エッジAIとNPUの役割

4-1. 超小型LLMの登場

この構想を現実に押し上げたのが、2025年以降に登場した超小型のLLMだ。

※「E」はEffective（実効パラメータ）の略。PLE（Per-Layer Embeddings）技術により各デコーダ層に独自のエンベッディングテーブルが付加されるため、実際のメモリ使用量は実効パラメータ数から想定するより大きくなる。E2Bは実効2.3Bだが総パラメータは5.1B相当。

Raspberry Pi 5でもGemma4 E2Bの動作が確認されており、PC上のNPUであれば、より高いパフォーマンスで常時起動しても電力コストは許容範囲に収まる。

4-2. CPU・GPU・NPUの三者分担

4-3. ソフトウェアスタックの現状（2026年）

Intel側：OpenVINO 2026.0でUnified Runtime Schedulerが実装され、CPU・GPU・NPUをまたぐパイプラインを自動的に分割・最適配置できるようになった。Qwen2.5-1BやMiniCPM-o-2.6などのNPU動作確認済みモデルも拡充中。ただしCore Ultra Series 1（Meteor Lake）では実用的なLLM推論速度は出ておらず、Series 2（Lunar Lake）以降が実用水準だ。

AMD側：XDNA 2アーキテクチャのNPUで最大50TOPSを実現。ONNX RuntimeのVitis AI Execution Providerを通じてエンベッディングモデルのNPU実行が実用化されている。LLM本体の生成部分はCPU・GPUとのハイブリッドが現実的な運用だ。

5. 結論：オーケストレーターによる抽象化

ここで冒頭の問いに戻る。クウキデザインのりお氏が構築したシステムは、エージェントAIの理想的なアーキタイプだ。しかし職業経営者レベルの組織設計能力が前提となる以上、それは一般ユーザーに届かない。では、この壁をどう超えるのか。

答えは「オーケストレーターによる抽象化」だ。

5-1. 現在と目指すべき姿

5-2. オーケストレーターの処理内訳とNPUの役割

5-3. クウキデザインの方法論が「見えなくなる」

6. 「万能の神」という幻想の終わり

OpenAIもAnthropicもGoogleも、AGI――すべての知的タスクをこなせる万能の高性能LLMを作り出し、あらゆる問題を解決するというアプローチで激しい性能競争を繰り広げてきた。ベンチマークのスコアが上がるたびに「これで解決だ」という空気が流れ、次のモデルが出ればまた更新される、その繰り返しだった。

しかしそれとはまったく別のアプローチが静かに台頭してきた。複数のエージェントを並列に稼働させ、組織として問題を解決するエージェントAIという概念だ。

なんでもできる巨大な「神」よりも、複数の自律的に稼働する標準的な性能のAIの組み合わせの方が、結果として役に立つ――この考え方は今後もっと一般的になるだろう。そしてそれは、データセンターへの投資の中身すら変えつつある。GPUクラスタに数百億ドルを注ぎ込む巨大モデル開発競争と並行して、エッジに分散した小型エージェント群をいかに効率よく動かすかという別の軸の競争が始まっている。

7. PCの未来――OSの意味が消える日

オーケストレーターによる抽象化が完成するということは、すべてのタスクをエージェントAIが受け持つということだ。Windows 11で言えば、「設定」を開くこともアプリを起動する必要もなくなる。タスクを実行するのは各エージェントであり、ユーザーはチャットや音声で指示するだけになるからだ。

そこまで来たとき、OSが何であるか、CPUが何であるか、MacかWindowsかChromOSかという問いは、実質的な意味を失う。PCはあくまで道具であり、目的を達成するためにある。Macであっても、ChromeOSであっても、チャットで指示して結果が返ってくるなら、それにこだわる人は少数派になるだろう。

現在Windowsのシェアが圧倒的なのは、Windowsでしか動かないアプリケーションが多いからだ。しかしエージェントがすべての機能を仲介するならば、その優位性は急速に薄れていく。

これが私の考えるパーソナルコンピューターの未来だ。NPUの上で静かに稼働する超小型LLMが、その変化の出発点になる。

本記事はファクトチェック済みの情報を基に執筆しました。（2026年5月）