Microsoft (有志)Publicationへの投稿
📈

Satya による Keynote: Leading in the New Age of AI

daka
に公開
Azure
Microsoft
Microsoft Foundry
idea

Igniteにて、Satyaが出てこないなと思っていたら、インドにて Leading in the New Age of AI のイベントで Keynote をしていたので要点をCopilotとともにまとめてみました。

事例や一部インドに注目したコミットメント、アップデートをしているのでそこは参考までに。
類似の日本の事例やコミットメントを補足で入れているのでそちらも参照ください。

Igniteの最新情報を整理するのに、ぴったりの30分セッションです！
https://www.youtube.com/watch?v=n3mdk7wTH5s

Satya Nadella の Microsoft India キーノート解説

AI フルスタックで「アウトカム」を変える。
テーマは一言で言うと 「AI 時代のフルスタックを、インドという現場でどう“成果”に変えるか」 です。

1. 全体テーマ：AI フルスタックで「アウトカム」を変える

まず、このキーノート全体を貫いているメッセージを整理すると、次の 4 点に集約できます。

  1. 技術そのものではなく「アウトカム（成果）」こそがゴール
  2. AI 導入は、従来の IT システム導入とは「前提」がまったく違う
  3. Copilot・IQ Layer・Toolchain・Infrastructure からなる “AI フルスタック” を、組織でどう活かすか
  4. India の人材・現場・インフラを舞台に、すでにこのスタックが具体的な変化を生み始めている

Satya は冒頭、「AI について語るために来たのではなく、AI がすでにこの国で“何を変えているか”を見るために来た」と強調します。
背景には、Microsoft のミッションがあります。

Empower every person and every organization on the planet to achieve more.

このミッションを、AI 時代に India でどう具体的なアウトカムに変えるのか――
そのためのフルスタックな絵を、上から下まで一気に描いたのが今回のキーノートです。

2. Outcome-First：AI で何を「曲げたい」のか

Satya は最初に、AI を語る前に「アウトカムから出発しよう」とメッセージします。
組織が本当に気にするべき指標は次のようなものです。

  1. 顧客・市民・患者の体験が良くなっているか
  2. 従業員のエージェンシー（主体性）が高まっているか
  3. 業務プロセスの効率（コスト・スピード・品質）が改善しているか
  4. 組織内のイノベーションの速度が上がっているか

ここでのポイントは：

  • AI を「導入できたかどうか」ではなく
  • それによって どれだけ成果のカーブ（curve）を曲げられたか

を見よう、ということです。

また、Satya は 「AI はそれ自体が目的になりがちだが、本来は手段でしかない」 と暗に釘を刺しています。
どれだけ立派なモデルやインフラがあっても、上記 4 つが変わらなければ意味がない――その視点が、最後まで一貫しています。

3. AI 導入で最大の鍵となる「マインドセット」

続いて Satya が強調したのが、AI 時代ならではのマインドセットの違いです。

3-1. 「自動化」から「学習するシステム」へのパラダイムシフト

従来の IT 導入は、ざっくり言えば次のような発想でした。

  1. いまある業務プロセスを洗い出す
  2. それをワークフローとしてシステム化する
  3. ルールベースで「自動化」する

しかし AI は、同じやり方では真価を発揮しません。
なぜなら、Satya の言葉を借りれば AI は 「継続的に学習して賢くなっていくシステム」 だからです。

  • 単に「今あるプロセスをそのまま自動化」
    → それでは、AI の学習力を活かしきれない
  • 最初から「学習前提」のプロセスとして再設計する（reimagine）
    → プロセスそのものの形が変わっていく

ここに、AI 時代のビジネスプロセス変革の難しさと面白さがあります。

3-2. リスキリングと「AI 時代の新しいツールチェーン」

Satya は、リスキリングについても特徴的な例えを使いました。

  • 80〜90 年代に、Excel + email + 添付ファイル が
    → 予測やレポーティングの仕事を根本的に変えた
  • それと同じように、今は AI 時代の新しいツールチェーン が必要

ポイントは：

  1. 人は「日常的に使うツール」を通じて考え方を変えていく
  2. 道具が変わらないまま意識だけ変えるのは難しい
  3. だからこそ、AI を組み込んだ日常ツール（Copilot など）と、それに接続するデータセット が重要になる

この「新ツールチェーン＋データセット」を、Satya はこの後「Tech Stack」として丁寧に分解していきます。

4. Experience Layer：Copilot がつくるボトムアップ変革

Tech Stack の最上段にあるのが Experience Layer（体験レイヤー）。
ここで Satya が位置づける主役が Copilot ファミリー です。

4-1. PC 時代の生産性革命とのアナロジー

Satya はまず、PC 普及期の変化を振り返ります。

  1. PC が「標準支給」になったことで、知識労働のあり方が変わった
  2. Finance / Supply Chain / Customer Service / Sales / Marketing など、あらゆる業務プロセスがデジタル化
  3. その中核にあったのが、Office などの生産性ツール

今、同じレベルの変化が AI + Copilot を通じて再び起ころうとしている――というのが彼の主張です。

4-2. Copilot ファミリー：AI を「仕事の現場」に直接埋め込む

Satya が挙げた Copilot の例は次の通りです。

  1. Copilot for Consumers – 一般消費者向けの AI アシスタント
  2. DAX Copilot（Healthcare） – 医療現場向けの特化型 Copilot
  3. Microsoft 365 Copilot – 情報ワーク（ドキュメント、メール、会議など）全般
  4. Copilot for Security – セキュリティ運用向け
  5. GitHub Copilot – ソフトウェア開発向け

ここでの共通コンセプトは：

「AI がどこか別サービスとして存在する」のではなく
“仕事をしている場所そのもの” に Copilot を埋め込む

ということです。

  • Word / Excel / PowerPoint / Outlook / Teams など
  • すでに人々が日常的に使っている UI に
  • AI が「同席している」状態 を作ることで、
    → 組織全体の変革が「ボトムアップ」に起こっていく、と Satya は説明します。

4-3. Chat から Agent へ

多くの人にとって、AI との接点といえば Chat UI です。
Satya も、チャットインターフェースは今後も「基本」であり続けると認めつつ、
それ以上のレバレッジを生むのは Agent だと語ります。

Copilot の世界での Agent とは：

  1. 特定の役割を持ち、タスクを継続的に遂行する AI
  2. ユーザーは、その Agent に「仕事を割り当てる」感覚で使う

具体例として Satya が挙げたのは：

  • Researcher Agent
    • あるテーマについてリサーチする役割を持つ
    • 複数のモデルを使い分けて調査し、レポートにまとめて返す
  • Analyst Agent
    • 複数の Excel ファイルやデータソースにアクセス
    • データサイエンティストがやるような分析を実行し、インサイトを返す

さらに、もともと GitHub / VS Code で先行していた Agent モード を、
Excel / Word / PowerPoint といった情報ワークツールにも持ち込む構想も語られました。

これからは「自分ひとりで資料を書く」のではなく、
専門家 Agent と共同でドキュメントやレポートを作る時代 になる。

というのが Satya のビジョンです。

4-4. India での Copilot 採用と「Your Copilot」という考え方

Satya は、India 全土ですでに Copilot の大規模導入が進んでいる と言及しました。

  • 多くの組織が Microsoft 365 Copilot を導入し
  • 自社独自のユースケースに合わせて活用
  • それはもはや「Microsoft の Copilot」ではなく
    → 「その組織の Copilot」になっている

彼はこれを PC 初期の Excel にたとえます。

誰も「Excel を崇拝していた」わけではなく、
ただ「当然の道具」として使っていただけ。
Copilot も、同じような当たり前の存在になっていくはずだ。

5. IQ Layer：Work IQ / Fabric IQ / Foundry IQ の詳細

Experience Layer の次に Satya が語ったのが、IQ Layer です。
これは、組織の「知性」を AI が利用できる形で構造化した層といえます。

背景には、これまでの IT の歴史で生まれた 「データサイロ」の問題があります。

  • それぞれの業務システムが、それぞれに別々のデータベースを持つ
  • 結果として、組織全体で見るとデータがバラバラに散らばる
  • AI を導入しても、コンテキストを理解していない “浮いた AI” になりがち

これを解消するのが、Satya のいう Work IQ / Fabric IQ / Foundry IQ の 3 つのレイヤーです。

5-1. Work IQ：コラボレーションの「関係性グラフ」

Work IQ は、簡単に言うと 「Microsoft 365 の中で生まれる、仕事上の関係性のグラフ」 です。

5-1-1. Work IQ が捉えているもの

  1. 人と人の関係
    • 組織図（上司・部下・部門など）
    • プロジェクト単位の関係（誰がどのプロジェクトに属しているか）
  2. 人とコンテンツの関係
    • どのメールが誰の間でやりとりされているか
    • どのファイル（SharePoint / OneDrive）が誰によって作られ、編集され、閲覧されているか
  3. コンテンツ同士の関係
    • 会議メモとスライドとメールスレッドの関連
    • 顧客名やプロジェクト名をキーにしたドキュメント間のつながり

これらをすべてグラフ構造として持っているのが Microsoft 365 Graph であり、
AI にとっての「組織内の文脈データベース」が Work IQ です。

5-1-2. Copilot にとっての Work IQ の価値

Copilot が真に「賢く」なるには、次のようなことができる必要があります。

  1. あるドキュメントの背景にいるステークホルダーを理解する
  2. 「この話題なら、誰が専門家か」を推定できる
  3. ある案件についてのやり取りが、メール・チャット・ドキュメントにまたがっていても、ひとつのストーリーとして辿れる

これらはすべて、Work IQ が裏で関係性をつないでいるから 可能になります。

5-2. Fabric IQ：業務データ全体を束ねる「数値側の知性」

Fabric IQ は、Microsoft Fabric 上の業務データ全体 を束ねるレイヤーです。
Work IQ が「人とコンテンツの関係性」に強いのに対し、Fabric IQ は ビジネスデータそのもの にフォーカスします。

5-2-1. Fabric IQ が扱うデータ

Satya が挙げた例：

  1. Operational Data（オペレーショナルデータ）
    • 受発注データ
    • 在庫・物流データ
    • 生産データ
    • コールセンターのトランザクションなど
  2. Analytical Data（分析用データ）
    • Data Warehouse / Data Lake 上の集計データ
    • Power BI で可視化されている各種 KPI
  3. Time Series Data（時系列データ）
    • センサーからの測定値
    • IoT デバイスのログ
    • マシンの稼働情報 など

これらを、Microsoft Fabric を通じて統合し、
AI から使いやすい形（セマンティクスが整理された形）にしているのが Fabric IQ です。

5-2-2. Work IQ と Fabric IQ の補完関係

  • Work IQ：
    →「誰が」「どのコンテンツを」「どのような関係で」扱っているか
  • Fabric IQ：
    →「ビジネスとして何が起きているか」を数値・時系列で捉える

この 2 つが組み合わさることで、例えば次のようなことが可能になります。

  1. サプライチェーンの KPI（Fabric IQ）悪化の背後にある
    • どのチームのコミュニケーション（Work IQ）が関係しているのかを分析する
  2. ある顧客案件での売上トレンド（Fabric IQ）と
    • その案件に関するメール・会議・提案資料（Work IQ）を紐づけて Copilot に要約させる

このように、人とデータの両方のコンテキストを持った AI を実現する土台と言えます。

5-3. Foundry IQ：非構造データを含む「全社知識の検索エンジン」

Foundry IQ は、さらに一歩踏み込んで 非構造データ を統合するレイヤーです。

5-3-1. Foundry IQ が担う役割

  1. ベストインクラスな検索（Search）を提供
    • 自然言語での検索
    • 類似ドキュメント検索
    • コンテキストを理解したクエリ展開
  2. 非構造データと構造化データを接続
    • 契約書 PDF、レポート、仕様書、チャットログなどの非構造データ
    • それを Fabric IQ にある構造化データ（売上・在庫・センサー値など）と紐づける

これにより、AI Agent は：

「過去 2 年間に同様の障害が発生した案件のレポートと、その際のセンサー値の推移をまとめて教えて」

といった複雑な問いに対しても、Foundry IQ ＋ Fabric IQ ＋ Work IQ を総動員して回答できるようになります。

5-3-2. IQ Layer 全体が Agent の「脳」になる

Satya の描いた全体像をまとめると：

  1. Work IQ：人・組織・コンテンツの関係グラフ
  2. Fabric IQ：業務データ・分析データ・時系列データの統合基盤
  3. Foundry IQ：非構造データを含む全社検索と知識統合

これらを合わせた IQ Layer が、Copilot や独自 Agent の「脳」 となります。
Experience Layer で動くあらゆる AI 体験が、この IQ Layer によって組織固有の知性を持つ――それが Satya の示した構図です。

6. Toolchain Layer：App Builder / Copilot Studio / Microsoft Foundry

Experience Layer と IQ Layer が整えば、次は 「つくる側」に回るためのツールチェーン が必要です。
Satya はここで 3 つの代表的なツールを挙げています。

6-1. App Builder：自然言語からアプリケーションへ

App Builder は、その名の通り「アプリをつくる」ためのツールですが、
Satya はここに長年のコンピュータサイエンスの夢を重ねています。

「なぜ、ドキュメントとアプリケーションと Web サイトは別物として扱われているのか？」
「本当は、それらを自由に行き来できるべきではないか？」

AI 時代の App Builder では：

  1. ドキュメントからアプリへ（レポートをそのままインタラクティブなアプリに）
  2. アプリから Web へ（内製アプリを公開サイトとして展開）
  3. Web からドキュメントへ（サイトの構造をドキュメント化）

といった変換が、自然言語の指示だけで可能になっていきます。

6-2. Copilot Studio：ノーコードで Agent を作る

次が Copilot Studio。
これは、専門の開発者でなくても Agent を構築できるプラットフォーム として紹介されました。

できることは例えば：

  1. Agent に「役割」と「振る舞い」を自然言語で定義
  2. 参照させたいナレッジ（SharePoint, Dataverse など）を指定
  3. それを Copilot の一部として利用可能な独自 Agent として公開

Satya はこれを、「新しい Word / Excel / PowerPoint スキル」として位置づけています。

かつて多くのビジネスパーソンが
Word で文書を書き、Excel で分析し、PowerPoint でプレゼンを作ることを覚えたように、
これからは App Builder と Copilot Studio でアプリと Agent を作る ことが標準スキルになる。

というイメージです。

6-3. Microsoft Foundry：マルチモデル・マルチエージェントの「工場」

そして Toolchain の中核として語られたのが Microsoft Foundry です。

6-3-1. 11,000+ モデルからの選択

Satya は、Foundry 上に 11,000 を超えるモデル が存在すると紹介しました。
重要なのは、「どの 1 つのモデルが最強か」を競うのではなく、用途に応じてモデルを選び分けることです。

選択軸は例えば：

  1. Latency（レイテンシ） – どれくらいの応答速度が必要か
  2. Price（コスト） – トラフィック量に対してどの程度のコストを許容できるか
  3. Domain Performance（ドメイン別性能） – 医療・金融・コード・会話など、用途ごとの得意不得意

6-3-2. モデルだけではなく「評価・ガードレール・統合」まで含める

Foundry は単なる「モデルのカタログ」ではなく、次のような機能まで含んだ 完全なツールチェーン として設計されています。

  1. Evaluation Frameworks –
    • どのモデル構成がユースケースに対して最も良いか評価する仕組み
  2. Guardrails –
    • セキュリティ・コンプライアンス・安全性に関する制約
    • 不適切な応答の抑制、データ流出防止など
  3. Multi-Agent System 構築機能 –
    • 複数モデル・複数 Agent を組み合わせた複雑な AI システムを設計・運用する機能
  4. IQ Layer / Experience Layer との統合 –
    • Work IQ / Fabric IQ / Foundry IQ
    • Copilot / カスタムアプリ / エンタープライズシステム

これにより、お客様や開発者は
「マルチモデル・マルチエージェントの AI システムをエンタープライズ品質で運用できる」 ようになる――
Satya は Foundry をそう位置づけています。

7. GitHub & Developer Ecosystem：Agent HQ としての GitHub

Toolchain の中でも、Developer 向けの中核として Satya が語ったのが GitHub です。

7-1. 2030 年、India は世界最大の Developer コミュニティへ

Satya は、India の Developer コミュニティが 2030 年には 5,750 万人超 となり、
世界最大になるとの予測に触れ、

その巨大な開発者人口が、社会スケールの課題に対して
マルチエージェントシステムを構築していくポテンシャル

に大きな期待を寄せていました。

※日本は世界で5番目で11.7M！

7-2. GitHub = Agent HQ（エージェント司令部）

彼は GitHub を、単なるコードホスティングや CI/CD の場ではなく、
「Agent HQ」 として再定義しています。

  1. GitHub 上のリポジトリに対して、複数のモデル・エージェントがアクセスできる
  2. GitHub Copilot はその入口のひとつに過ぎない
  3. 開発者は、各 Agent に対して
    • コードの生成
    • リファクタリング
    • セキュリティチェック
    • ドキュメント生成 などのタスクを割り当てる

また、利用フォームファクターも多様です。

  • VS Code / Visual Studio での Agent モード
  • モバイルアプリからのリポジトリアクセス
  • コマンドラインからの操作

朝起きてモバイルからリポジトリを開き、
「エージェントを走らせておく」と、
通勤中にコードベースが改善されていく――

そんな未来の開発スタイルを、Satya はごく自然に語っています。

8. Satya 自作の “Deep Research” プロジェクト：マルチエージェント意思決定の実例

キーノートの中で最も「遊び心」と「実践」が詰まっていたのが、
Satya 自身が Thanksgiving の週末に作ったという “DR（Deep Research）” プロジェクト の紹介です。

8-1. Azure 上で動くマルチエージェント研究システム

  • プロジェクト名：DR（Deep Research）
  • ホスト：Azure 上（北中部カナダリージョンにデプロイ）
  • リポジトリ：自分の GitHub リポジトリ

このシステムでは、Foundry 上の 11,000 以上のモデル を活用して、
新しい意思決定フレームワークを実装しています。

8-2. AI Council：モデルを「選考委員会」に見立てる

最初のフレームワークが AI Council です。
これは、複数モデルを「選考委員会のメンバー」、1 つのモデルを「委員長」として扱う形になっています。

  1. 複数のモデル（GPT-5、Claude、Gemini、Kimi 2、Grok など）を
    「委員（council members）」 として選択
  2. その中から 1 つを 「chairman（委員長）」 として指定
  3. テーマを与えると：
    • 各委員がそれぞれの視点で提案・分析を行う
    • 委員長がそれらを読み込み、統合した結論と議論のポイントをまとめる

人間の会議でいえば：

  • 多様なバックグラウンドを持つメンバーが自由に意見を述べ
  • それを委員長が整理して「最終案」と「論点整理」を出す

というプロセスを、モデル間のマルチエージェント構成で再現した形です。

以下、話題になったものと似てる、
https://github.com/karpathy/llm-council

8-3. DxO（Decision Orchestrator）：役割でチームを組ませる

次に紹介されたのが DxO（Decision Orchestrator） です。
ここでは、モデルには「委員」ではなく 役割（Role） が与えられます。

典型的な構成は：

  1. Lead Researcher
    • テーマ全体を広くカバーする「幅広の一次調査」を担当
  2. Critical Reviewer
    • 調査や分析の手法そのものを批判的に検証
    • 「どのようなバイアスが入りやすいか」「見落としている視点はないか」を指摘
  3. Domain Expert
    • 特定の専門領域から知識を補完
    • 業界特有の文脈や現実的な制約を反映
  4. Data Analyst
    • データに基づく検証・パターン抽出・定量的評価を担当

ここで重要なのは：

モデル同士が「別々の役割でチームを組み、互いのアウトプットを前提にしながら
最終的な意思決定をサポートする」

という構造になっていることです。

DxO の中核コンセプトは、「メタ認知（metacognition）」 に近いものです。

  • Lead Researcher が幅広く集めた情報に対して
  • Critical Reviewer が「手法の偏り」や「情報の偏り」を指摘し
  • Domain Expert が現実の文脈を補正し
  • Data Analyst が定量面からチェックする

こうして、「1 つのモデルに聞いて終わり」よりも、ずっと深い思考プロセス を再現しています。

8-4. Ensemble Mode：匿名化された多数決＋統合

3 つ目のフレームワークが Ensemble Mode です。

  1. 複数モデルに対して 並列に同じ質問を投げる
  2. 各モデルからの回答を 匿名化（α・β・γ…など） して扱う
  3. それらの答えを比較し、共通点と相違点を整理したうえで統合する

これにより：

  • 個々のモデルのバイアス（文体や好み）を薄め
  • 「多数派が支持する結論」と「少数派の異論」を同時に把握できる

ようになります。

8-5. デモ題材：史上最強の India Test Cricket Team を選ぶ

Satya は、この 3 つのフレームワークを説明するために、
South Asian らしいユーモアを交えて 「史上最強のインド・テストクリケットチーム選出」 を題材に使いました。

AI Council モードでは：

  1. 各モデルがそれぞれ「最強 XI（イレブン）」を提案
  2. Chairman モデルが：
    • どの選手に関して「全会一致」だったか
    • どこで意見が割れたか
    • どのモデルが誰を強く推したか
      を文章として解説
  3. 典型的な論点例：
    • 「VVS Laxman を入れるか、追加のシームボウラーを入れるか」という議論
    • Claude が Laxman を強く推し、Eden Gardens での名場面を根拠に挙げる
    • Gemini が Kohli を強く推す など

DxO モードでは：

  • Lead Researcher が「候補選手とその実績」を幅広く提示
  • Critical Reviewer が「最近の選手に偏る recency bias」「特定の時代に偏る bias」「条件の違い（ピッチ・時代）による比較困難さ」などを指摘
  • それを踏まえて最終 XI を再構成

Ensemble モードでは：

  • 各モデルの回答が α / β / γ… として一覧化され
  • 共通して選ばれた選手・モデルごとに異なる評価をされた選手が整理される

最後に Chairman モデルが、これらを踏まえた 「最終 XI」とその理由 を提示する、という流れが披露されました。

Satya がこのデモを通じて伝えたかったのは：

  1. AI を「Guardian Angel」や「Cognitive Amplifier」として使う発想
  2. Council / DxO / Ensemble といったフレームワークは、遊びではなく
    → サプライチェーン、プロジェクト投資、リスク評価など ビジネスの重要意思決定 にそのまま転用できる

という点です。

9. Agent 365：エージェント時代のランタイムとガバナンス

マルチエージェントが前提になると、次に浮かび上がるのが ガバナンスと可視化 の課題です。

9-1. エージェントが「見えないまま動く」ことのリスク

エージェントは：

  1. 組織の機密データにアクセスし
  2. 意思決定に影響を与え
  3. 新たな成果物（レポート・コード・設定変更など）を生成する

にもかかわらず、

  • 誰がどのエージェントを動かしているのか
  • そのエージェントがどのデータにアクセスしているのか
  • どんなアウトプットをどこに書き出しているのか

が見えない状態のままでは、コンプライアンスもセキュリティも成立しません。

9-2. Satya 自身が体験した DLP のストップ

Satya は、自分の DR システムを Copilot のエージェントとして組み込もうとした際 のエピソードを紹介しました。

  • Azure 上に個人プロジェクトとしてデプロイしていた DR
  • それを Microsoft 365 環境（Work IQ）に接続しようとすると
  • Data Loss Protection（DLP）ポリシー によってブロックされた

理由はシンプルで：

組織のデータにアクセスするエージェントは、
正しく Microsoft テナント内にプロビジョニングされていなければならない。

というルールが存在するからです。

これは、Agent 時代のガバナンスがすでに実装された現実的な課題であることを示す良い例でした。

9-3. Agent 365：エージェントのランタイム＋監視・統制基盤

ここで Satya が紹介したのが Agent 365 です。

  1. 企業・公共機関の内部で動くエージェントの「ランタイム」
  2. すべてのエージェントを一元的に：
    • 可視化（Observability）
    • 管理（Management）
    • ガバナンス（Governance）
    • コンプライアンス（Compliance）
      できる基盤
  3. Work IQ / Fabric IQ / Foundry IQ と接続されることで、
    • 「どのエージェントがどの IQ レイヤーにアクセスしているか」をコントロール可能

これにより、組織は：

  • 「エージェントに仕事を任せる」ことと「ガバナンスを維持する」ことを両立 できるようになります。

10. India で既に動き出しているリアルユースケース

Satya は理論だけでなく、India での具体的な事例をいくつも紹介しました。

10-1. Apollo Hospitals：Clinician Copilot と Root Cause Analysis Agent

  1. Clinician Copilot

    • 医師の手元で動く Copilot
    • ドキュメント作成や情報検索に時間を取られるのではなく、
      → 医師が患者と向き合う時間を増やすことを目的に設計
    • 「情報システムが医師を支える」構図への再設計

  2. Root Cause Analysis Agent

    • Apollo グループ全体で発生する課題を解析し、
    • システム的な問題やパターンを発見し、
    • 改善アクションを提案・支援する Agent

これらは、Healthcare という最もクリティカルな分野 において、
AI とエージェントがアウトカムを直接動かしている例として紹介されました。

10-2. Kushi Baby ＋ ASHA ワーカー ＋ Microsoft Research

次に紹介されたのが、Kushi Baby と村のヘルスワーカー（ASHA）、そして Microsoft Research の協業です。

  • 辺境の村で、新生児や母親のケアを行う ASHA ワーカー
  • その手元に AI を搭載したツールがあることで：
    1. ケアの品質のばらつきを減らし
    2. 記録とフォローアップを確実に行い
    3. 早期にリスクを検知し介入できる

Satya はこれを、

「村のヘルスワーカーが AI の力を手にしている」
その瞬間に、AI が本当に “meaningful” になったと感じる。

と語りました。

10-3. ONGC：Upstream Analysis の知見を現場へつなぐ複数エージェント

エネルギー分野では、ONGC の事例が紹介されました。

  • 上流解析（upstream analysis）の高度な専門知識を
  • フィールドエンジニアの手元に届けるための 複数のエージェント を構築
  • これにより：
    1. 現場での意思決定が迅速に
    2. 本社・専門チームとの知識の断絶が縮まる

まさに IQ Layer と Experience Layer をエージェント経由で接続した例 といえます。

10-4. Tech Mahindra：マルチエージェントと地域言語対応での民主化

Tech Mahindra は、自社で マルチエージェントフレームワーク を構築した例として紹介されました。

  1. 複数のモデルと Agent を組み合わせた独自のフレームワークを開発
  2. それをベースに、実際の顧客課題に対してマルチエージェントシステムを展開
  3. さらに、それらを India の各地域言語 に対応させることで、
    • 英語話者だけでなく
    • より広い層のユーザーが AI の力を使えるようにした

Satya はこれを “Democratizing sophisticated AI systems” と表現し、
高度なエージェント技術が 地域言語で使えることの意義 を強調していました。

※日本のユースケースについては以下にて一部紹介しております。

https://www.microsoft.com/ja-jp/customers/search?filters=language%3Ajapanese

11. Infrastructure Layer：Tokens / Rupees / Watt と Sovereignty & Cybersecurity

Tech Stack の最下段に位置するのが インフラストラクチャ（Azure） です。
ここで Satya が提示した象徴的な指標が：

Tokens / Rupees / Watt

という式です。

11-1. Tokens / Rupees / Watt の意味

  1. Tokens – 生成 AI が出力するトークン（言語モデルの出力量）
  2. Rupees – そのためにかかるコスト（インド通貨単位）
  3. Watt – 消費電力（エネルギー）

この式で表現したかったのは：

  • AI が社会全体の生産性や GDP を押し上げるには
  • 「どれだけ効率よくトークンを生み出せるか」 が重要であり
  • その効率は
    → コスト（Rupees）とエネルギー（Watt）によって規定される

という視点です。

Satya は、

「GDP 成長とこの Tokens / Rupees / Watt の式は、強い相関を持つだろう」

とまで言い切っています。

11-2. India における Azure データセンター投資とサステナビリティ

この文脈で紹介されたのが、India における Azure データセンターリージョン の拡充です。

  1. 既存リージョン：Pune, Chennai, Mumbai
  2. 新リージョン：India South Central（Hyderabad） – 2026 年に本格稼働予定
  3. 特徴：
    • 100% 再生可能エネルギー（renewable power） による運用を目指す
    • 大規模な AI ワークロードに対応できるよう急速にスケール

これにより、India 国内で：

  • Tokens を生み出す 計算資源
  • それを支える 持続可能なエネルギー

の両面を拡大していく構図が示されました。

11-3. Sovereignty（主権）とデータローカリティ

インフラの話とセットで、デジタル主権（Sovereignty） も重要なテーマとして挙がりました。

Satya が示したオプションは：

  1. Public Cloud with Sovereignty Options
    • パブリッククラウド上のワークロードに対し、主権要件を満たすための追加機能を提供
  2. Private Cloud
    • 特定の事業者（パートナー）が運用する専用クラウド環境
    • 利用者のコントロールをより強化
  3. Geo Azure Region（インドパートナー運営リージョン）
    • インドのパートナーが運営する Azure リージョン
    • 主権要件に特化した形で構成

また、Copilot のデータ処理を India 国内で完結させている ことにも触れ、
機密性の高いデータが国境を越えないような設計を強化していると説明しました。

※日本もCopilot のデータ処理を日本国内で完結させる発表をしている👇
https://azure.microsoft.com/en-us/blog/microsoft-strengthens-sovereign-cloud-capabilities-with-new-services/

11-4. Sovereignty と Cyber Resilience の両立

しかし Satya は、主権だけを追求することの危うさにも言及します。

サイバーセキュリティは「インテリジェンスのゲーム」である。

  • Microsoft は世界中の脅威インテリジェンスを収集・分析しており
  • それを各国・各組織の防御に活かしている

もし、Sovereign Cloud を追求するあまり、

  • グローバルな脅威インテリジェンスとの接続を失ってしまうと
  • 一見「主権的で安全そう」に見えても、実際には
    → 攻撃に非常に弱い環境になってしまう

というリスクがあります。

Satya はここを非常に強いトーンで指摘し、

  1. Workload ごとにリスクベースで配置先（Public / Private / Sovereign）を選び
  2. それでも グローバルなセキュリティインテリジェンスへのアクセスを維持すること が重要

だと訴えました。

「グローバルインテリジェンスなしでサイバー戦を戦いたい国などないはずだ。」

この言葉は、特に政策決定者に向けた強いメッセージとなっています。

12. ミッションの再確認と India へのコミットメント：投資とスキリング

キーノートの最後に Satya は、再び Microsoft のミッション に立ち返ります。

Empower every person and every organization in this country to achieve more.

この文脈で語られたのが、投資（Investment）とスキリング（Skilling） への具体的コミットメントです。（ここは割愛しますが、興味ある方はセッションを参照ください。）

結び：AI フルスタックを「現場目線」で捉える

このキーノートは、単に「AI はすごい」という話ではなく、

  1. Experience Layer（Copilot / Agents）
  2. IQ Layer（Work IQ / Fabric IQ / Foundry IQ）
  3. Toolchain Layer（App Builder / Copilot Studio / Microsoft Foundry / GitHub）
  4. Infrastructure Layer（Azure, Tokens / Rupees / Watt, Sovereignty & Security）

という フルスタックな構造 を、
India という具体的な現場を舞台に語り尽くした内容でした。

そして、そのどのレイヤーにも一貫していたのは：

  • 「AI を導入すること」ではなく
  • 「AI を使ってアウトカムをどこまで曲げられるか」 を問う姿勢

でした！

今後の私たちの仕事は、このフルスタックを自分の組織・自分の現場に当てはめ、

  • どのレイヤーから取り組むか
  • どのプロセスを「学習前提」で再設計するか
  • どのデータを IQ Layer に乗せるか

を、考えていければと思いながら、年末まで過ごそうと思います！

最後に

日本では、AI Tour Tokyo 3月24日にイベント開催します。

去年は Satya が来ていたが、今年はどうなるのか。お楽しみに！
https://aitour.microsoft.com/flow/microsoft/aitour/landing/page/home?filter=event%2FlogicalValue>Tokyo

Microsoft (有志)
Microsoft (有志)Publication

メンバーが選んだMicrosoft製品の最新技術情報・知見をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。

Discussion