Tech News JP

Microsoftは2026年6月のWindows 11更新から、「セキュリティパッチ適用済み（最新状態）」と「新機能が有効化済み」を公式に分離する新サービシングモデルを導入する。Controlled Feature Rollout（CFR）と呼ばれるAI駆動の段階展開メカニズムが、デバイスごとの機能有効化タイミングを制御し、IT管理者と一般ユーザーの両方にとって「最新状態」の意味が変わることになる。 Windows 11サービシングモデルの変革 これまでのWindows Updateは、シンプルな「最新の状態です」というメッセージを表示してきた。しかし6月以降は、このステータスが持つ意味が大きく変わる。 インストール済みの更新プログラムには2つの独立したステージが存在するようになる： インストールステージ: セキュリティパッチ・品質修正・機能ペイロードの適用 有効化ステージ: CFRによる機能のオンオフ切り替え つまり、デバイスが全更新プログラムをインストール済みであっても、Microsoftのクラウドベースシステムが「準備完了」の判定を下すまで、新機能は有効化されない。 Controlled Feature Rollout（CFR）とは何か CFRは今回初めて導入された仕組みではない。Microsoftは数年前からこのメカニズムを活用してきた。機械学習モデルを使って「スムーズな体験が見込まれるデバイス」を特定し、数週間〜数ヶ月かけて段階的に展開を広げていく。 変遷をたどると、Windows 10時代の「Current Branch for Business」による展開遅延から始まり、2019年の「Semi-Annual Channel」移行、そして2022年のWindows 11「Moments」（年次アップデート間の小規模機能追加）までCFRが段階的に活用されてきた。今回の変更で、すべての機能がCFRゲートの対象となる。この仕組みはMicrosoft EdgeやGoogle Chromeがリモートで機能フラグを切り替える手法と同様のアプローチだ。 企業IT管理者への影響 今回の変更は、IT管理者にとっては管理の精度が上がるポジティブな変化だ。 メリット： 機能の有効化タイミングをセキュリティパッチとは独立してコントロール可能 問題発生時のロールバックや一時停止の判断が明確化 段階展開の粒度が増し、大規模障害のリスクを低減 課題： エンドユーザーへの説明コストが増加 「最新状態なのに同僚にはある機能が自分にはない」という問い合わせが増える可能性 Windows Updateの状態表示が複雑化し、ヘルプデスクの負担増 実務での活用ポイント エンジニア・IT管理者向け： CFRが公式分離されることで、IntuneやWindows Update for Businessを使った管理ポリシーの再整備が必要になる。今から準備しておきたいポイントを挙げる。 更新リングの再設計: セキュリティパッチリングと機能展開リングを分けて管理する構成を検討する テレメトリ設定の確認: CFRの判定はデバイスのテレメトリデータに依存する。テレメトリを制限している組織では機能展開が遅延する可能性があり、設定の見直しが必要になる ユーザー向け案内の準備: 「最新状態」と「機能有効化」は別物であることをヘルプデスクチームに周知し、問い合わせ対応フローを整備する パイロット運用の設計: 少数の検証端末でセキュリティパッチのみを先行適用し、安定確認後に機能展開を広げる運用が現実的になる 筆者の見解 正直に言えば、この変更はWindowsサービシングの方向性として悪くない。 「更新を当てたら壊れた」という話はここ数年で本当に増えた。セキュリティパッチと機能展開を公式に分離することは、その懸念に正面から応えるアプローチだ。更新プログラムを躊躇なく適用できる環境づくりは、セキュリティ態勢の底上げにも直結する。 ただ、一般ユーザーにとっての混乱は避けられないだろう。「最新状態です」と表示されているのに、なぜ隣の同僚のPCには新機能があるのか——このギャップを直感的に理解できるUIの整備は、Microsoftに引き続き期待したいところだ。機能の有効化ステータスを可視化する専用の画面や、展開予定タイムラインの開示があれば、現場の混乱は大きく減らせる。 変化するサービシングモデルを「面倒が増える」と受け取るか、「管理の選択肢が増えた」と捉えるかで、組織の対応は大きく変わる。IT管理者としては、このモデルを最大限に活かす管理設計に今から備えておきたい。 出典: この記事は Windows 11 June 2026 Servicing Change: How Controlled Feature Rollout Separates ‘Up to Date’ from ‘Feature Enabled’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、科学・工学分野のR&Dワークフローに自律AIエージェントチームを展開するAzureベースのプラットフォーム「Microsoft Discovery」を正式提供（GA）開始した。同時に発表された次世代トポロジカル量子チップ「Majorana 2」は前世代比で信頼性が1,000倍向上しており、その実現にDiscoveryのエージェント機能が大きく貢献している。 Microsoft Discoveryとは何か Microsoft Discoveryは、組織が専門化されたAIエージェントのチームをデプロイできるプラットフォームだ。各エージェントは大規模な知識ベースを推論し、仮説を生成し、実験を最適化し、結果を検証し、継続的なループで学習する。 アーキテクチャの核心は以下の4要素で構成される： Discovery Engine：マルチエージェントの研究ワークフロー全体を統合管理 Azure HPC連携：計算負荷の高いシミュレーションを処理 信頼スコアリングと引用機能：エージェントの出力を追跡可能・レビュー可能にする エンタープライズセキュリティ・ガバナンス：知的財産の保護と規制準拠を担保 Microsoftが設計上の4要件として掲げているのは、ワークフローの再現性、出力のレビュー可能性、独自知識のガバナンス、既存R&D組織への適合性だ。「ブラックボックスではなく説明可能なエージェント」という姿勢は、企業での実採用に向けた現実的な解答といえる。 Majorana 2——AIエージェントが実現した量子チップの飛躍 今回の最大のハイライトは、Discoveryの実績として同時発表されたMajorana 2だ。量子チームはDiscoveryのエージェントを活用して以下を実現した： 製造ワークフローの管理自動化 測定作業の自動化 材料スタックの最適化 キュービット製造における未発見の欠陥の特定 約20年分の異なるフォーマットの実験データにわたるパターン相関分析 技術面では、アルミニウムから鉛の超伝導体への転換により、宇宙線由来のノイズからキュービットを遮蔽することに成功。平均量子ビット寿命20秒（最長1分）を達成した。他のアプローチで典型的なマイクロ秒単位の寿命と比べると、桁違いの改善だ。演算時間は1マイクロ秒、量子ビットサイズは0.1ミリメートルの100分の1という高集積度を実現している。 Microsoftはこれにより、スケーラブルな量子コンピュータの実現を2029年と見込んでおり、当初計画から半分のタイムラインに前倒しとなる。 個人研究者・小規模チームへの間口も開放 エンタープライズ向けのAzure GAと並行して、無料のデスクトップアプリがEarly Previewで公開された。GitHub Copilotアカウントがあればローカル実行が可能で、大学研究者や小規模チームも敷居低くDiscoveryを試せる。 早期顧客には、エネルギー貯蔵・バイオシステム工学でセルフドライブ型科学ワークフローを構築するPacific Northwest National Laboratory（PNNL）や、半導体向け次世代流体の開発を進めるSyensqoなどが含まれる。 日本のIT現場への影響 日本の製造業・素材産業・医薬品分野の企業にとって、Microsoft Discoveryは今後注目すべきプラットフォームだ。 R&Dチームへの示唆： 既存のAzure環境を持つ企業は、追加インフラなしにアクセスできる 「20年分のデータを横断分析」というユースケースは、製造業の品質管理や失敗事例の学習に直結する GitHub Copilotの法人契約があれば、まずデスクトップアプリで小規模実験が可能 IT管理者・アーキテクトへの示唆： エージェントの出力に信頼スコアと引用が付くことで、コンプライアンス対応がしやすくなる Azure HPC連携は既存のAzureガバナンスポリシーが適用されるため、セキュリティチームの負担が比較的小さい Non-Human Identity（NHI）管理の観点から、エージェントに対してもMicrosoft Entra IDの条件付きアクセスをどう適用するかを早期に設計しておく価値がある 筆者の見解 Microsoft Discoveryの正式提供が持つ意味は、単に「もう一つのAIサービスが増えた」ではない。これはMicrosoftが「最も賢いAIを作る競争」ではなく、「最も多くのエージェントが安全かつ追跡可能に動作するプラットフォームを提供する競争」に軸足を置いていることの表れだ。 Majorana 2の開発でAIエージェントが「20年分の実験データを横断的に相関分析し、未発見の欠陥を特定した」という事実は、単なる業務効率化の話ではない。「AIが研究の主要なプレイヤーになった」という現実を示している。 エージェントの管制塔としてのAzure基盤——Entra IDによる認証・認可、HPC連携、ガバナンスコントロール——という構成は、長期的に見て筋が通っている。信頼スコアリングと引用機能を標準装備にしている点も評価できる。「エージェントが何をしたか説明できない」という問題は企業導入の最大の障壁の一つであり、ここに正面から答えを出していることは意味が大きい。 日本の製造業・研究機関にとって、自社の10年・20年分の実験データや製造ログがAIエージェントによって体系的に活用される日は、想像より近いかもしれない。Azure上でのエージェント基盤構築を今から設計し始めるのが、現実的な次の一手だろう。 出典: この記事は Microsoft Discovery Reaches GA on Azure, Powering the Agentic AI behind Majorana 2 Quantum Chip の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、Copilotをチャット型アシスタントから自律的に動く「委任エージェント（Delegated Agent）」へと進化させる「Scout Autopilot」構想を発表した。エンタープライズIDや権限管理、記憶機能、監査証跡を持つ「常駐ソフトウェア同僚」として設計されており、ユーザーが指示を出さなくても権限の範囲内でプロアクティブにタスクを実行する新しいCopilotの姿が明らかになった。 Scout Autopilotとは何か 従来のCopilotは「聞かれたら答える」リアクティブなアシスタントだった。Scout Autopilotはこのモデルを根本から変える。ユーザーからの指示を待つのではなく、委任された権限の範囲内でプロアクティブにタスクを見つけ、実行し、報告するエージェントとして機能する。 Microsoftが描くのは、まるで新しい同僚が入社したような存在だ。「常駐ソフトウェア同僚（Resident Software Colleague）」という表現は単なる比喩ではなく、設計思想そのものを反映している。 エンタープライズ統制との統合 Scout Autopilotが注目される最大の理由は、企業が最も懸念するガバナンス面への対応だ。 エンタープライズID管理 Entra ID（旧Azure AD）と統合し、エージェントが「誰として」動作するかを明確に定義できる。これは従来のCopilotにはなかった概念だ。 権限（Permission）の明示的な委任 エージェントに付与する権限を細かく制御できる。「このエージェントにはメール閲覧と下書き作成のみ許可」のような粒度での権限設定が可能になる。 メモリ（Memory）機能 会話をまたいだ文脈の保持が可能になる。「先週議論した件を踏まえて」という形での継続的な作業支援が実現する。 監査証跡（Audit Trail） エージェントが何を実行したかをログとして残す仕組みが組み込まれており、コンプライアンス要件が厳しい金融・医療・公共セクターでも活用できる土台が整う。 日本のエンタープライズIT管理者が今押さえるべきポイント 短期的に確認・準備すべきこと： Entra IDの整備が前提: Scout Autopilotの恩恵を受けるには、Entra IDによる認証・認可の管理が整っていることが大前提。既存のAD環境からのハイブリッド移行状況を確認しておく 最小権限の原則をエージェントにも適用する: エージェントに過剰な権限を与えない。Just-In-Timeアクセスの概念をエージェント管理にも適用し、「常時アクセス権の付与」という最大のリスクを避ける 監査ログの活用計画を立てる: ただログを収集するだけでなく、Microsoft SentinelやPurviewとの連携・アラート設定まで設計しておく M365管理者がいま確認すべき設定： Purview（コンプライアンスセンター）の監査機能の現状 Microsoft 365管理センターのAIアプリポリシー設定 Copilot利用ログの取得状況 エンジニア・開発者向け： Scout AutopilotはMicrosoft 365の外にも展開できる可能性がある。Azure AI FoundryやPower Automateとの連携が示唆されており、業務アプリケーションへのエージェント統合を検討しているチームは今からアーキテクチャを考え始めておくべきだ。 筆者の見解 Scout Autopilotの方向性は、Copilotが抱えてきた根本的な課題──「結局、何をやってくれるのかわからない」という問題──への回答として読める。チャットで答えを返すだけのアシスタントから、実際に業務を動かすエージェントへ。この転換の方向性は正しい。 とはいえ、正直に言う必要もある。権限管理・監査・ID統合という要素が揃ってきたのは事実だが、「現場で安心して任せられる品質」になるかどうかは、実際のロールアウトの実装次第だ。発表の段階では良さそうに聞こえても、現場に届いたときに期待通りだったためしがどれほどあるか——それはCopilotを追いかけてきた人間なら誰もが知っている。 ただ、Microsoftにはこのエージェント機能を「ちゃんと動くもの」として出し切る力が間違いなくある。エンタープライズITの核心に位置するプラットフォームとしての強みは他に代えがたい。Scout Autopilotが描くビジョンを、発表止まりにせず現場が信頼できる品質で届けることを、応援を込めて強く期待したい。 出典: この記事は Microsoft Scout Autopilot: Copilot Shifts From Chat Helper to Delegated Agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Purview Insider Risk Managementが、2026年5月〜6月のロールアウトで、AIとのやり取りを平文（プレーンテキスト）で確認できる機能を追加する。リスクポリシーがトリガーされた際に、ユーザーの匿名性を保ちながら、AIプロンプトとその応答の全文をセキュリティアナリストが直接確認できるようになる。 Microsoft Purview Insider Risk Managementとは Microsoft Purview Insider Risk Management（IRM）は、社内の人間——従業員・請負業者・パートナー——によるリスク行動を検出・調査・対応するためのコンプライアンスソリューションだ。Microsoft 365 E5ライセンスに含まれるほか、アドオンとしても購入できる。 ファイルの大量ダウンロード、メール転送、異常なサインインといったアクティビティをリスク指標と照合し、閾値を超えるとアラートを生成、調査ケースが自動作成される。これまでSharePoint・OneDrive・Exchange・Teamsといった従来型データソースが対象だったが、生成AIの普及で「AIチャットボックス」という新たなリスク経路が生まれた。 AIプロンプトの「中身」が見えなかった問題 従来のIRMは「AIとのやり取りが発生した」という事実ログは残せても、その内容——具体的に何を入力し、AIが何を返したか——を把握できなかった。これが大きな死角だった。 社員が機密コードをCopilotに貼り付けて解析を依頼した場合、あるいは非公開の財務情報をプロンプトに含めた場合、セキュリティチームはそれを後から読むことができなかったのだ。 新機能の仕組み：平文レビューと匿名化の両立 今回の機能拡張でIRMは、クレジットカード番号・社会保障番号・カスタム分類子といったセンシティブ情報タイプが含まれるプロンプトを検出すると、そのやり取り全文をキャプチャする。調査アナリストは、ケース画面から実際の会話を平文で確認できるようになる。 一方で、プライバシーへの配慮も盛り込まれている。調査段階ではユーザーの匿名化が維持される設計で、必要な権限を持つ担当者だけが氏名を確認できる段階的開示の仕組みが提供される。 また、監視対象とする生成AIアプリを管理者が選択できる機能も追加される。Microsoft 365 Copilotだけでなく、組織が業務で使用する外部AIサービスも対象に加えられるため、シャドーAIのリスク管理にも使える可能性がある。 実務への影響——日本のIT管理者・セキュリティ担当者へ 即座に確認すべきこと： ライセンス確認: M365 E5を持っているか、IRMのアドオンが有効になっているかを確認する。この機能は上位ライセンス限定だ 既存のDLPポリシーとの整合性: 従来のデータ損失防止（DLP）ポリシーに「AIプロンプト経由の情報流出」のシナリオが抜けていないか見直すタイミングだ 利用規程の更新: 「AIツールへの業務データ入力ルール」を就業規則・情報セキュリティポリシーに明文化する。監視される事実を従業員に適切に周知しなければ、従業員の信頼を損なう可能性がある（欧州のGDPR対応も要注意） 段階的展開の計画: まずは特定の部門・職種だけを対象にパイロット運用し、アラートの精度と業務への影響を評価してから全社展開を検討するのが現実解だ 長期的な視点では： Copilot・外部AI・社内構築LLMと複数のAIが混在する環境では、一元的なガバナンス基盤が不可欠になる。IRMとMicrosoft Purview全体（DLP・情報保護・コンプライアンスマネージャー）を統合して使う設計が、長期的にコストと複雑性を下げる。 筆者の見解 この機能追加は、Purviewとして「当然やるべきことをついにやった」という印象だ。生成AIの業務利用が急拡大するなか、AIとのやり取りだけがセキュリティの視野外に置かれていた状況は、どう考えても無理があった。 ゼロトラストの文脈でいえば、「可視化なきアクセス制御はゼロトラストではない」。AIへのプロンプトという行動が可視化されることで、ようやくIRMがAI時代のリスク管理ツールとして機能し始める。これはMicrosoftのセキュリティ統合プラットフォームとしての地力が発揮される場面であり、素直に評価したい。 一方で、正直に言えば「遅い」とも感じる。Copilotが本格展開されたのは2023年後半。それから2年以上、AIプロンプトの中身が見えないままリスク管理ツールとして販売されていたわけで、そこは「もったいなかった」と言わざるを得ない。M365のセキュリティ機能は確かに統合度が高く、使いこなせば強力なのだから、こういうギャップは早めに埋めてほしい——それが長年のM365ユーザーとしての率直な声だ。 今後の課題は「何をAIプロンプトのリスク指標と定義するか」のチューニングだ。センシティブ情報の検出精度が低ければ誤検知が増えてアナリストの業務を圧迫し、高すぎれば見落としが増える。この「閾値設計」こそ、管理者に問われる本当の専門性になる。 出典: この記事は Microsoft Purview Insider Risk to Review AI Prompts in Plaintext (May–Jun 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年第1四半期（Q1）のスマートウォッチ世界出荷台数が3,700万台に達したと、TechTimesが市場調査データをもとに報じた。市場全体では拡大傾向が続く一方、かつて人気を集めたフィットネスバンド（フィットネストラッカー）カテゴリは縮小傾向にある。こうした市況のなか、Samsungは次世代モデル「Galaxy Watch 9」シリーズを7月22日のGalaxy Unpacked（ロンドン開催予定）で発表することが見込まれている。 なぜこの市場動向が注目されるのか 3,700万台という数字は、ウェアラブルデバイスが「健康管理ツール」として日常に定着しつつあることを示している。注目すべきはカテゴリの二極化だ。スマートウォッチへの需要は拡大しているが、シンプルな歩数・心拍計測に特化したフィットネスバンドは縮小傾向を見せている。 この背景には、スマートウォッチ自体の価格帯が下がり、フィットネスバンドとの価格差が縮小してきたことが一因として挙げられる。機能が充実したスマートウォッチを選んだほうが「元が取れる」という消費者判断が市場に反映されている。 Samsung Galaxy Watch 9——7月22日ロンドンで何が明らかになるか TechTimesの報道によると、SamsungはGalaxy Watch 9を2026年7月22日にロンドンで開催される「Galaxy Unpacked」イベントで発表する見通しだ。Galaxy Z Fold 8・Galaxy Z Flip 8といった折りたたみスマートフォン新モデルとの同時発表が予想されている。 現時点で公式スペックは非公開だが、市場が期待する主なポイントは以下のとおりだ。 Galaxy AIの深化: 健康データの解析・アドバイス機能へのAI統合強化 健康モニタリングの拡充: 血圧測定精度の向上や新たなバイオメトリクス機能の追加 バッテリー性能: Galaxy Watch 7比での持続時間改善 プロセッサ刷新: 最新チップセットへの移行によるパフォーマンス向上 日本市場での注目点 日本でのGalaxy Watch販売はサムスン公式サイトおよび主要キャリアを通じて行われており、過去モデルの実績からグローバル発表後2〜4週間での国内発売が見込まれる。 価格帯については、Galaxy Watch 7が国内市場で4万円台後半〜5万円台で展開されていたことを踏まえると、Galaxy Watch 9も同水準が予想される。Apple Watch Series 10が4万5,800円〜（国内参考価格）という点と比較すると、ミッドレンジからハイエンドでの競争が続く見通しだ。 2026年後半はGoogle Pixel Watch 4や秋のApple Watch Series 11（予想）も控えており、ウェアラブル市場の競争が一気に激化する。Android利用者にとっては、Galaxy Watch 9とPixel Watch 4の比較検討が購入判断の焦点になるだろう。 筆者の見解 「スマートウォッチ拡大・フィットネスバンド縮小」というトレンドは、ウェアラブル市場が「単機能デバイス」から「統合プラットフォーム」へと移行している構造変化を象徴している。 着目したいのは、AIとウェアラブルの融合だ。スマートウォッチが常時収集する生体データと生成AIを組み合わせることで、「健康管理の自動化」という新たな価値軸が生まれつつある。Galaxy Watch 9が「Galaxy AI」をウォッチ体験にどこまで組み込めるかは、Samsungがこの流れをリードできるかの試金石になる。 Samsungはウェアラブル領域において技術的な底力を持つメーカーだ。7月22日のGalaxy Unpacked後の正式スペック公開を注視したい。フィットネスバンドからの乗り換えを取り込めるような価格・機能設計を実現できれば、Q2以降のさらなる市場拡大に貢献できるはずだ。 関連製品リンク ...

MetaのApplied AI（応用AI）チームが、発足からわずか3ヶ月で深刻な組織崩壊の危機に直面している。Wiredの報道によれば、約6,500人のエンジニア・プロダクトマネージャーが強制的に配属されたこの部門では、現場の不満が臨界点に達しつつある。 何が起きているのか 発端は今週、社内限定のライブストリーム発表会に何者かが侵入し、MetaのAI幹部を罵倒する言葉を流したことだ。発表者の一人は顔を両手で覆ったとされる。この出来事は、3ヶ月前に突然の「驚きメール」で異動を告げられた従業員たちに渦巻く怒りの爆発点に過ぎなかった。 配属を告げられた従業員たちは、自らを「徴兵された者（draftee）」と呼ぶ。選択肢は「参加するか、辞めるか」の二択だったという。彼らに与えられた仕事は、AIモデルを訓練するためのパズルやコーディング問題を大量生成すること。ある従業員はWiredに「ここは本物のグラーグ（強制労働収容所）だ」と語り、別の従業員は「ほとんどの人が魂の抜けるような作業だと感じている」と述べた。 なぜMetaはこうしたのか CEOのマーク・ザッカーバーグは、社外の請負業者ではなく自社エンジニアを動員した理由をこう説明している。「Meta社員の平均的な知性は、外部請負業者より明らかに高い」。AIモデルが「コーディングのような技術タスクで人間を上回る」レベルに達していないため、実際の作業例でモデルを訓練する必要があるというのだ。 この部門を率いるのはMetaで12年のキャリアを持つMaher Saba氏。またデータラベリング企業Scale AIを143億ドル（約2兆円）でMetaに売却し、最高AI責任者に就任したAlexandr Wang氏が、こうしたデータ収集の仕組みに深く関わっている。 当初、この部門では最大50人が1人のマネージャーに報告する体制だったとされており、管理構造の設計自体にも問題があったことがうかがえる。 社内の空気は部門を超えて悪化 問題はApplied AIチームにとどまらない。社内全体で1,600人以上の従業員が、AIトレーニングデータ収集のためにクリックやキーストロークを監視するプログラムに抗議する請願書に署名したという。Meta最高製品責任者のChris Cox氏は、今週の社員向け通話で「過酷な（brutal）」職場環境について言及せざるを得ない状況に追い込まれた。 ザッカーバーグ自身も金曜日の社内メモで「最近の変化が社員に苦痛をもたらした」と認め、会社が誤りを犯したことを認めた。とはいえ「Metaのノーススターは、世界で最も優秀な人材がインパクトを生み出すための最高の場所になること」という言葉は、現場の怒りを収めるには到底届かないように見える。 実務への影響——AI開発の「データ問題」は他人事ではない この件が示す本質的な課題は、高品質なAI学習データの調達コストだ。 企業がAI導入を検討する際の示唆として： データ品質の担保は人力に依存する段階が続く: 現状のAIモデルは、特に技術系タスクにおいて人間のデモンストレーションデータを大量に必要としている。「高品質な訓練データ」の裏には、必ず人間の労働がある 社内データ活用の倫理設計: 自社従業員の業務データをAI訓練に使う場合、透明性・同意・インセンティブ設計を怠ると、今回のような組織的反発を招く 組織変更のコミュニケーション: サプライズメールでの強制異動という手法は、たとえ理由が正当であっても人材の信頼を一瞬で壊す。AI推進のための組織再編は、丁寧な事前説明と選択肢の提示がセットでなければならない 日本企業がAI活用を加速させる中、「社内のリソースを効率的に使う」という発想自体は理解できる。しかし透明性を欠いた動員は、優秀な人材の離反と組織の生産性低下というブーメランになって返ってくる。 筆者の見解 Metaのこの騒動、「やらかし方」がいかにも同社らしいと感じてしまう。 AIモデルの訓練に高品質なデータが必要なことは自明だ。自社エンジニアを活用するという発想自体が突飛なわけではない。しかし「驚きメールで通告」「参加か退職かの二択」「50人に1人のマネージャー」という実装の仕方は、エンジニアを「資源」として見ているとしか言いようがない。 AIの競争において、優秀なエンジニアの確保と定着はモデル品質と同等に重要な経営課題だ。143億ドルのScale AI買収資金があるなら、データ収集の仕組みをもう少しましに設計できたはずだと感じる。「平均的なMeta社員の知性は請負業者より高い」というザッカーバーグの発言は事実としても、それをこういう形で活用することへの合意を取らずに動いたのは、経営判断としてかなり粗い。 メタバースに83億ドルを溶かした教訓を生かし切れていないように見えるのが、正直なところだ。AI競争でのポジションを争う今こそ、内部の人材を大切にすることが外部へのシグナルにもなる。優秀なエンジニアは選択肢を持っている。 一方でこの件を「だからMetaは」と片づけるのは早計でもある。AIモデルの訓練データ問題は業界全体が直面している構造的な課題であり、どの企業もいずれ「誰がデータを作るのか」という問いに向き合わなければならない。Metaの失敗事例は、その問いへの答えを模索する他社にとって、反面教師としての価値がある。 出典: この記事は Meta’s months-old AI unit is a soul-crushing gulag, say the engineers stuck inside it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米政府（商務省）は2026年6月12日（現地時間）、Anthropicに対し最新AIモデル「Claude Fable 5」と「Claude Mythos 5」への即時アクセス停止を命令した。Anthropicはこの命令に従いながらも、公式ブログで「この判断は誤りだ」と異例の反論を展開している。 Claude Mythos 5 ——「公開するには危険すぎる」として限定運用されてきたモデル Mythos 5はAnthropicが4月に概要を公開した最上位モデルだ。「ソフトウェアの脆弱性を特定する能力が突出して高い」ことを理由に一般公開を見送り、Amazon・Apple・Google・Microsoft・CrowdStrikeを含む約50の審査済み組織に限定提供する「Project Glasswing（プロジェクト・グラスウィング）」という管理プログラムで運用してきた。用途は防衛的なサイバーセキュリティ目的に限定されていた。 Claude Fable 5 ——商用向けにガードレールを追加した「妥協点」 Fable 5はMythos 5をベースに、サイバーセキュリティや生物学など高リスク分野のレスポンスをブロックするガードレールを追加した商用モデルだ。停止命令のわずか3日前にリリースされたばかりで、AIパフォーマンス計測企業Vals AIのベンチマーク評価では「公開AIモデルの中で最も能力の高いモデル」と評価されていた。 政府命令の内容と「ジェイルブレイク」の実態 今回の命令は輸出規制という形式をとっているが、外国籍ユーザーだけでなく全世界のユーザーに対してアクセスを遮断する内容だ。 Anthropicによると、政府が懸念したのはFable 5の「潜在的な狭義のジェイルブレイク」。その実態は、「モデルに特定のコードベースを読み込ませ、ソフトウェアの欠陥を特定させる」という操作だという。同社はこれについて次の点を指摘している： 同等の能力はすでに広く存在: OpenAIの「GPT-5.5」を含む他の公開モデルにも同等の能力がある セキュリティ専門家の標準的手法: サイバーセキュリティの防衛目的で日常的に使われる手法であり、本質的に禁じる理由がない 独立した保護システムが別途稼働: モデル本体とは独立した分類器（クラシファイアー）システムが最も危険な出力を別途ブロックしており、モデルがジェイルブレイクされても深刻なアウトプットは遮断される Anthropicは公式ブログで次のように述べている。「数億人に展開された商用モデルをリコールする理由として、狭義の潜在的ジェイルブレイクを採用することに我々は同意しない。この基準が業界全体に適用されれば、フロンティアモデルの新規デプロイが事実上すべて停止するだろう」 日本のエンジニア・IT管理者への影響 直接的な影響として、Fable 5をAPIや業務フローに組み込んでいたユーザーは即時に代替手段を検討する必要がある。停止対象はFable 5とMythos 5のみで、他のAnthropicモデルへのアクセスは維持されている。 より重要なのは、この件が示す政策的な示唆だ。AIの輸出規制という制度的枠組みが、「脆弱性特定能力を持つモデル」への規制手段として機能しうることが実証された。日本でも類似の規制議論が起きる可能性がある。 企業のAI活用において「特定モデルへの過度な依存を避け、代替切り替え計画を持つ」ことが実務上のリスク管理として重要になってくる。単一ベンダー・単一モデルに業務の核心部分を依存させる設計は、今後再考を迫られる局面が増えるかもしれない。 筆者の見解 今回の件にはなんとも皮肉な構造がある。Anthropicが「Mythos 5は強力すぎて一般公開できない」と透明性をもって発信し、防衛目的に限定しながらも管理された形で一部組織と共有したこと——この誠実な安全性重視のアプローチが、結果として政府の厳しい目を引き寄せた。 「禁止ではなく安全に使える仕組みを」が筆者の基本スタンスだ。高度なサイバーセキュリティ能力を持つAIを正しく使えば、悪意ある攻撃者よりもはるかに速く脆弱性を発見・修正できる。同等の能力がすでに公開モデルで利用可能な中、特定の一社のモデルを停止するだけでは安全保障上の問題は解決しない。防衛利用の道まで閉ざすような規制は、かえってセキュリティ水準を下げるリスクがある。 とはいえ、政府が懸念を持ったこと自体を頭ごなしに否定するのも違う。AI規制のフレームワークが現実の技術能力に追いついていない状況で、行政が手探りで判断を下している側面もある。「脆弱性を見つける能力」は攻撃にも防衛にも使えるデュアルユースの典型であり、その扱いに関する社会的合意形成はまだ端緒についたばかりだ。 Anthropicがこの件をどう乗り越えるかは、AI企業全体への問いでもある。「安全性を正直に訴えること」と「商業的な継続性」を両立させる道を、業界全体が今まさに模索しなければならない段階に入ってきた。 出典: この記事は Anthropic’s safety warnings may have just backfired — the government has pulled the plug on its most powerful AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GitHubは、GitHub Copilot CLIにおけるエージェント「委譲（delegation）」の判断精度を大幅に改善したと発表した。ユーザーが新たな設定を触ることなく、オーケストレーションが自動的に最適化され、無駄なハンドオフが減り、処理が速くなる。 「委譲」とは何か——CLIにおけるエージェント分業の仕組み GitHub Copilot CLIは、ターミナル上でユーザーのリクエストを受け取り、それを処理するアーキテクチャを持っている。単純なコマンド補完から複雑なコード生成まで、リクエストの性質によって「自分で処理する」か「専門の下位エージェント（ツール）に委ねる」かを判断する——これが委譲の仕組みだ。 問題は、この委譲判断が過剰になりやすいことにある。「念のためサブツールに投げておこう」という判断が積み重なると、余計なラウンドトリップが発生し、待ち時間が増え、場合によってはノイズが混入してむしろ精度が落ちる。 今回の改善ポイント GitHubのPrincipal Applied ScientistであるPingping Lin氏が主導したこの取り組みの核心は、「委譲すべきでないケースを正しく見極める」精度の向上だ。 ハンドオフの削減: 委譲の必要がないリクエストをCLI自身が処理するケースが増え、往復コストが減少 処理速度の向上: サブエージェントへの受け渡しが発生しない分、応答が速くなる 設定不要（No new knob）: ユーザー側の設定変更なしに恩恵を受けられる。エンジニアが「チューニングのための設定項目を覚える」コストが発生しない このアプローチは、データドリブンな分析によって「どのリクエストパターンが過剰委譲を引き起こしているか」を特定し、ルーティングロジックを改善するものだ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 即時の恩恵はアップデート後すぐ得られる。 Copilot CLIを日常的に使っているエンジニアは、gh copilot suggest や gh copilot explain コマンドの応答が体感的に速くなる可能性がある。 企業導入の文脈では「透明性」に注目したい。 委譲ロジックの改善は、エージェントが何をどう判断しているかの予測可能性を高める。エンタープライズ環境でCopilot CLIを試験導入しているチームにとって、動作の一貫性向上は評価しやすくなるメリットだ。 「設定不要」の価値を再評価すべきだ。 AIツールに設定項目が増えると、チームの習熟コストが膨らみ、展開が遅れる。今回のように「内部ロジックを改善してユーザーに恩恵を届ける」アプローチは、エンタープライズ展開においても歓迎される方向性といえる。 ターミナル作業の多い開発チームでは効果が出やすい。 CI/CDパイプラインのデバッグ、Bashスクリプトの生成、エラーメッセージの解説など、Copilot CLIが活躍する場面は多い。頻度が高いほど積み重なる改善効果も大きい。 筆者の見解 今回の改善が面白いのは、「機能追加」でも「モデル更新」でもなく、オーケストレーションの設計見直しによって価値を出した点だ。 AIエージェントの世界では、「どのモデルを使うか」よりも「どうタスクを分解し、どう制御フローを設計するか」が実際の品質を左右する。「委譲しすぎない」という判断の精度を上げることは、地味に見えて本質的な改善だ。 GitHub Copilotがこういったオーケストレーション層の緻密な改善に取り組んでいること自体は、正しい方向だと思う。CLIはIDEと違って、エンジニアが自分の作業フローに直接組み込むツールだ。「たまに遅くなる」「なぜか別ツールに回される」という体験が積み重なると、使わなくなる。その摩擦を取り除く地道な作業の積み重ねが、ツールへの信頼につながる。 MicrosoftとGitHubには、統合プラットフォームとしての圧倒的な強みがある。Azure DevOps、GitHub Actions、VS Code、Copilot——これだけのエコシステムを持ちながら、開発者の日常ワークフローに深く入り込める立場にある企業はほかにない。今回のような「エンジニアの体験を細部から磨く」取り組みこそが、その強みを活かす道だ。正面から真剣に勝負できる力があるのだから、その姿勢を続けてほしい。 出典: この記事は How we made GitHub Copilot CLI more selective about delegation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft PlacesおよびMicrosoft Teamsにおいて、社内Wi-Fiネットワークへの接続を利用してオフィスへの出社を自動検知する「Wi-Fiチェックイン」機能を発表した。従業員が手動でワークプレイスロケーションを更新しなくても、ノートPCが社内ネットワークに接続した瞬間にTeamsが検知し、勤務場所を自動更新する。 「今日、誰がオフィスにいるか」を自動で可視化 ハイブリッドワークが定着した現在、チームメンバーの物理的な居場所を把握するのは意外と手間だ。Outlookのカレンダーを見ても「在宅か出社か」までは分からないことが多く、Teamsのプレゼンスは「オンライン中」かどうかは示しても「今日どこから働いているか」は示さない。 Microsoft Placesのワークプレイスプレゼンスはこのギャップを埋める機能だ。そして今回の「Wi-Fiチェックイン」は、その情報を手動入力なしで常に最新状態に保つ仕組みである。 技術的な仕組みはシンプルだ。各オフィスのWi-FiアクセスポイントのBSSID（基地局識別子）をMicrosoft Placesのディレクトリに登録しておくと、従業員のノートPCがそのネットワークに接続したタイミングでTeamsクライアントがそれを検知し、その日の勤務場所を「オフィス」に自動更新する。既存の「周辺機器チェックイン」（ディスプレイやドックへの接続で検知）と同じコンセプトをWi-Fiに拡張したものと考えると理解しやすい。 プライバシーへの配慮：3層の同意モデル こうした「位置検知」機能には、常に監視懸念がつきまとう。Microsoftはその点を意識してか、3層の同意モデルを設計している。 第1層：組織レベルの有効化 テナント管理者が機能そのものを有効にするかどうかを決める。有効にしない限り、従業員のデバイスでは機能しない。 第2層：設定方式の選択 組織がオプトイン（従業員が明示的に有効化）かオプトアウト（デフォルト有効だが個人が無効化可）かを選択できる。 第3層：個人レベルの制御 最終的には個人がいつでも設定を変更でき、手動でロケーションを上書きすることも可能。デバイスの位置情報設定がオフであれば、組織が有効にしていても機能しない。 また、過去の行動履歴は保存されない。「現時点でどこにいるか」だけを示す現在進行形のシグナルであり、「いつ何時間オフィスにいたか」のような追跡には利用されない点は明記されている。 実務への影響 IT管理者の準備事項 今年後半のロールアウトに備えて、以下の準備が求められる。 Microsoft Placesのセットアップ確認: Placesディレクトリにビルディング情報が登録されているかを確認する BSSIDの収集と登録: 対象オフィスのWi-FiアクセスポイントすべてのBSSIDを収集し、Placesディレクトリに登録する Teamsの作業場所検出ポリシーの有効化: 管理センターで該当ポリシーを設定する 従業員への周知: 機能の概要・できないこと（履歴は保存されないなど）・個人での制御方法を事前に説明する BSSIDの収集は、フロアごとに多数のアクセスポイントが存在する大規模オフィスでは一定の手間がかかる。ネットワーク担当部門と連携して、AP一覧のエクスポート方法を事前に確認しておくとスムーズだ。また、オフィスの移転・増設・Wi-Fiリプレイス時には「Placesのディレクトリも更新が必要」という新たな運用タスクが発生することを、ネットワーク管理のライフサイクルに組み込んでおく必要がある。 エンジニア・ビジネスユーザーへの恩恵 Teamsやカレンダーから「今日誰がオフィスにいるか」がリアルタイムで確認できる 「せっかく出社したのに全員リモートだった」という状況を事前に回避できる フリーアドレスのデスク予約と連携し、チームメンバーの近くに席を取りやすくなる 筆者の見解 Microsoft Placesは、ハイブリッドワーク時代の「コラボレーション基盤」として地道に機能を積み上げている印象だ。カレンダーの空き状況・Teamsのアクティビティプレゼンス・ワークプレイスプレゼンスを組み合わせた多層的な可視化は、M365を統合プラットフォームとして活用することの具体的な価値を示している。バラバラに導入していては得られないメリットだ。 プライバシー設計については、オプトイン/オプトアウトを組織が選択できる構造は実際的だと思う。日本企業の文化的な背景を考えると、「オプトイン」から始めて従業員の理解を得ながら段階的に展開するアプローチが現実的だろう。 一方で、BSSIDベースの設定管理は運用負荷の観点でやや気になる。Wi-Fiインフラの更新サイクルとPlaces管理のサイクルを意識的に連携させなければ、気づかないうちにチェックインが機能しなくなるケースが出てくるかもしれない。Microsoftには、ネットワーク管理ツールとの統合や自動同期の仕組みを将来的に検討してほしいところだ。 とはいえ、M365エコシステムをフル活用できている組織にとっては、すぐに「あって当然」の機能になるポテンシャルがある。まだMicrosoft Placesを導入していない組織にとっては、今回の機能を評価のきっかけにしてみる価値は十分あるだろう。 出典: この記事は Workplace presence, made effortless: Workplace check-in via Wi-Fi for Microsoft Places and Teams の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米Ars TechnicaのKyle Orland氏が報じたところによると、Anthropicは2026年6月12日（金）夜、リリースしたばかりのFable 5およびMythos 5モデルへのアクセスを全面停止した。停止はわずか数日で行われた異例の措置であり、その背景には米商務省からの輸出規制指令がある。 何が起きたのか 停止の直接的な引き金は、同日夕方にAnthropicが受け取った米商務省の指令だ。Fable 5とMythos 5を米国外での使用を制限する輸出規制の対象とするというもので、Anthropicは「この政府指令にただちに準拠する唯一の手段は、全顧客に対してFable 5とMythos 5を即刻無効化することだ」と金曜夜の声明で述べた。他のAnthropicモデルへのアクセスには影響がない。 「ジェイルブレイク」が引き金——その実態は Axiosの報道によれば、当局が懸念したのはFable 5に対する「ジェイルブレイク」の存在だ。サイバーセキュリティ・化学・生物に関するプロンプトをブロックするはずの「分類器ベースのセーフガード」を回避する手法が報告されており、政府はこれを国家安全保障上の脅威と位置付けた。政府関係者によれば、国家安全保障体制を「強化」するための一時停止を求めており、数週間以内に作業が完了する可能性があるという。 Anthropicの反論 Anthropicは声明のなかで、政府が提示したのは「特定のコードベースの軟弱性をFable 5にレビューさせる、局所的・非普遍的なジェイルブレイク」の口頭による証拠のみだったと明かした。同社が強調したポイントは三点ある。 確認された悪用事例は「軽微」かつ「比較的単純な」脆弱性の発見に留まる GPT-5.5など他社の公開モデルも同等の能力を持つ 「この基準が業界全体に適用されれば、すべてのフロンティアモデルプロバイダーの新規デプロイが実質的に停止する」 政府の指令には従いながらも、その判断の妥当性には明確に異議を唱えている。 背景にあるトランプ政権のAI安全保障政策 今月初め、トランプ大統領はAIモデルメーカーに対し自発的な政府セキュリティテストへの参加を促す大統領令に署名した。当初は先月の署名式が直前に中止されるなど、政権内部での意見の不一致も取り沙汰されていた経緯がある。今回の措置はその延長線上にあると見られており、AIの能力をめぐる官民の緊張関係が改めて浮き彫りになった。 日本市場での注目点 日本ユーザーへの直接影響 輸出規制の対象となっているため、日本のユーザーはすでにFable 5・Mythos 5にアクセスできない状態にある。API経由でAnthropicのサービスを活用している日本企業は、Fable 5への移行計画を一時的に見直す必要が生じる。 先例となるリスク 今回の「輸出規制」という手法が先例となれば、他のフロンティアモデルにも同様の規制が課せられる可能性がある。単一プロバイダーへの依存リスクが可視化されたタイミングとも言える。 回復の見通し Anthropicは「24時間以内に詳細を公開する」と述べており、数週間以内に状況が改善される可能性は残っている。業務でFable 5の活用を計画していた場合でも、まずは公式アナウンスを待つのが賢明だ。 筆者の見解 今回最も気になるのは、政府が示した証拠の薄さだ。Anthropicが「口頭による証拠のみ」と指摘している通り、「軽微な脆弱性発見」がなぜ突然の全面停止に値するのか、その論理的根拠は外部からまったく見えていない。 Anthropicが指摘した点も重要だ。「同等の能力を持つGPT-5.5は規制を受けていない」——この非対称性が放置されるなら、特定のプレイヤーだけが一方的なコストを負わされることになる。公平な競争環境の観点からも、透明性のある説明が政府には求められる。 より本質的な懸念は、この種の前例が「フロンティアモデルの新規デプロイを事実上止める道具」になりかねないことだ。Anthropic自身が言うように、今回のような基準が業界横断で適用されれば、モデルの進化そのものにブレーキがかかる。政府のAI安全保障への関与は必要だが、「疑わしきは止める」という粗い手法では、長期的にイノベーションの芽を摘むことになりかねない。 今後数週間のAnthropicと政府の交渉の行方は、AI規制の国際的な議論にも影響を与えるはずだ。日本を含む各国のAI政策立案者も、この事例を注視しておく価値がある。 出典: この記事は Anthropic shuts down Fable, Mythos models following Trump admin directive の内容をもとに、筆者の見解を加えて独自に執筆したものです。

PC Watch（2026年6月13日付、竹元かつみ氏報告）によると、中国のAIスタートアップMiniMaxが6月12日、約4,280億パラメータのオープンウェイトLLM「MiniMax M3」のモデルウェイトをHugging Faceで公開した。同モデルはすでに6月1日よりAPIとして提供を開始しており、今回はウェイト自体の一般公開となる。 MoE設計と独自アテンション機構「MSA」 MiniMax M3はエキスパート混合モデル（MoE）アーキテクチャを採用しており、総パラメータ数は約4,280億ながら、推論時にアクティブとなるパラメータ数は約230億に抑えられている。大規模モデルの表現力と推論コストの両立を図った設計だ。 最大の技術的特徴は独自開発の「MiniMax Sparse Attention（MSA）」。これにより最大100万トークンのコンテキストウィンドウを実現しつつ、前世代MiniMax M2と比べてプリフィル速度を約9倍、デコード速度を約15倍に向上。1Mトークン処理時のトークンあたり計算量も20分の1に削減したとされる。入力モダリティはテキスト・画像・動画に対応しており、追加アダプタなしにネイティブで処理できるマルチモーダルモデルでもある。 海外レビューのポイント：主要ベンチマーク結果 PC Watchの報告によると、MiniMax M3の主なベンチマーク結果は以下のとおり。 ベンチマーク MiniMax M3 Gemini 3.1 Pro SWE-Bench Pro（コーディング） 59.0% 54.2% MCP Atlas（MCPサーバーエージェント連携） 74.2% 69.2% BrowseComp（ウェブ自律閲覧） 83.5% 85.9% OSWorld-Verified（OS操作） 75.2% 76.2% ソフトウェアエンジニアリング評価「SWE-Bench Pro」ではGemini 3.1 Proを約5ポイント上回る。一方、ウェブ自律閲覧（BrowseComp）やOS操作（OSWorld-Verified）ではわずかに届かず、全体として拮抗した水準にある。 注目点の一つは、MCPサーバーとのエージェント連携を測る「MCP Atlas」で74.2%を記録し、Gemini 3.1 Pro（69.2%）を5ポイント超えている点だ。 ライセンスとモデルサイズ ライセンスは非商用であれば無償利用が可能。年間売上2,000万ドル未満の企業・個人による商用利用も、MiniMaxへの届け出と「Build with MiniMax」の表記のみで認められる。モデルウェイトはbf16フォーマットで約855GBだが、1-bit GGUFに圧縮すると約128GBまで削減できる。MiniMaxはより手頃なハードウェアでの動作を目指して、意図的にパラメータ規模を抑えた設計にしたと説明している。 日本市場での注目点 現時点で日本語公式サポートに関する情報は限られているが、オープンウェイトで研究・開発への転用が可能な点から、国内の研究機関・AIスタートアップ・個人開発者にとって注目に値する選択肢だ。 圧縮後128GBでも動作させるには高スペックのGPUを要するため、ローカル運用のハードルは依然として高い。現実的にはクラウドGPUサービス（Azure Machine LearningやAWS）上での活用が主流となるだろう。まず試すならAPIが先決で、すでに商用提供が始まっている。 筆者の見解 MiniMax M3で最も気になるのが、MCP Atlasにおけるエージェント連携性能だ。MCPはAIエージェントが外部ツールを呼び出しながら自律的にタスクを進めるための標準プロトコルであり、この指標の優位性は単なるコーディング能力とは別の実用価値を示す。エージェントループ——AIが判断・実行・検証を繰り返しながら自律駆動する仕組み——を設計・運用する文脈で、外部ツールとの連携性能は核心的なファクターになってきている。 オープンウェイトという点も重要だ。特定ベンダーのクローズドAPIに依存せず、自前の環境でチューニング・制御できることを求める企業や研究者にとって、トップクラスの性能をオープンウェイトで使えることは選択肢を実質的に広げる。 一点確認しておきたいのはライセンスだ。小規模商用利用には届け出のみで対応できるが、大規模商用用途には別途MiniMaxとの契約が必要になる。エンタープライズ導入を本格検討する前に、ライセンス条件を精査しておくことを勧める。 出典: この記事は Gemini 3.1 Proと互角、4,280億パラメータLLM「MiniMax M3」公開 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年6月、エンタープライズAI市場の競争軸が根本的に変わった。Microsoft、Snowflake、Databricks、Google、Anthropic、Salesforce、SAPが「エージェントクライアント」という新たな戦場に集結し、企業AIの「記憶・文脈・自律行動」を誰がコントロールするかをめぐる熾烈な争いが本格化している。 エージェントクライアントとは何か 従来のチャットボットは「質問に答える」受動的なツールだった。しかし2026年のエンタープライズAIは、プロアクティブに推論・計画・実行できる「エージェント」へと進化している。その核心となるのがエージェントクライアント——AIが組織の知識グラフにアクセスし、複数ステップのタスクを自律実行する際のインターフェース層だ。 このクライアントを押さえた企業が、ガバナンスポリシーの定義、業務ワークフローの自動化、そして組織全体のメモリ層の設計権を握ることになる。コパイロット画面、データサイエンスノートブック、APIオーケストレーションハブが融合したこの新カテゴリこそが、現在最大の争奪対象だ。 MicrosoftのフルスタックCopilot戦略 Microsoftは圧倒的な配布力を持つ。CopilotフレームワークはWindows、Edge、Microsoft 365、Azure AI Studioに深く統合されており、数百万人の情報ワーカーが日常的に触れる環境に組み込まれている。 2026年の大きなアップデートがRecall Vaultだ。Microsoft Graphによるセマンティックインデックスと組み合わせることで、エージェントはセッションやデバイスをまたいでタスクを継続できる長期メモリを獲得した。さらにWindows 12（コードネーム「Hudson Valley」）ではネイティブエージェントランタイムAPIが導入され、あらゆるWindowsアプリケーションがCopilotランタイムに対してアクションとコンテキストを公開できるようになった。 M365をすでに導入している企業にとって、この統合の敷居は極めて低い。組織のデジタル資産全体を把握するエージェントを、追加開発なしで有効化できる構造は他社には真似できない強みだ。ただし、EU規制当局がこの垂直統合に対して独占禁止法上の懸念を示しており、Microsoftは外部API公開などで対応を迫られている。 データプラットフォーム勢の反撃 SnowflakeとDatabricksは「真の企業記憶はUIシェルではなく、ガバナンスの効いた構造化データウェアハウスにある」という論理でエージェント層をデータ基盤に直接統合する戦略で対抗している。 データの重力（Data Gravity）——大量のデータが存在する場所にサービスが引き寄せられる現象——は侮れない。機械学習モデルの学習データ、業務トランザクション、顧客データがすでにこれらのプラットフォームにある企業では、エージェントの「文脈」もここから提供される方が自然という論理は説得力を持つ。 ガバナンスと可観測性が差別化要因に 各社が共通して強化しているのがガバナンスと可観測性だ。エージェントが自律的にアクションを実行する以上、「何をしたか」「なぜその判断をしたか」を追跡・監査できる仕組みが不可欠になる。特に金融・医療・公共領域では、コンプライアンスや監査要件への対応が本格採用の前提条件となる。この点でデータウェアハウス系ベンダーは従来から強みを持っており、エージェント統合でもその優位を活かそうとしている。 実務への影響 日本のIT管理者・エンジニアが今すぐ考えるべき点を整理する。 M365導入済み企業は今が評価のタイミング：Recall VaultやGraph連携の機能は既存環境への追加コストが低い。まずスモールスタートでROIを測定することを推奨する。エージェント機能の試験導入を本格的に計画に入れる時期だ。 データ基盤の「エージェント対応」を確認せよ：SnowflakeやDatabricksを使っているチームは、各プラットフォームのエージェントSDKやAPIを今のうちに確認しておくこと。データウェアハウスとエージェントが統合される方向に業界全体が動いている。 ガバナンス設計は後回しにするな：エージェントが自律行動する前提でログ設計・監査トレール設計を今のうちに行う。「あとでやる」では対応できない規制要件が近い将来確実に出てくる。 独自エージェント開発チームは標準APIに乗れ：Windows 12のネイティブエージェントランタイムAPIなど、プラットフォームが提供する標準への準拠を優先する。独自実装を積み重ねると後のコストが跳ね上がる。 筆者の見解 エージェントクライアントという概念が業界のキーワードになったこと自体は、正しい方向への進化だと思う。「副操縦士が質問に答える」モデルから「自律的にタスクを実行するエージェント」モデルへの移行は、AIの本来の価値を引き出すために不可欠な転換だ。 Microsoftについて言えば、Recall VaultやWindows 12のネイティブエージェントAPIは技術的に興味深い取り組みだ。エンタープライズの文脈では、すでに全従業員のデジタル活動がMicrosoft Graphに蓄積されている企業が多い。その資産を使ってエージェントに「組織の記憶」を持たせるという発想は筋がよく、他社にはない強みだ。 ただ一点、「エージェントクライアントを押さえれば勝てる」という発想だけでは不十分だと感じる。エージェントの価値はループの質——目的を受け取り、自律的に判断・実行・検証を繰り返し、本当に仕事を終わらせられるか——にある。UIや統合の深さよりも、そのループが信頼に足るかどうかが企業採用の鍵になるはずだ。 Microsoftにはそのループを実現する技術力も、エコシステムも揃っている。M365という世界最大のビジネス基盤という武器を持っている。競争が激しいからこそ、その力を正面からぶつける製品体験を作り上げてほしいと期待している。 出典: この記事は Agentic AI Platform War: Who Controls Enterprise Memory, Context, and Action in June 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月、Windows 11 25H2のインストールメディアをビルド26200.8655に静かに更新した。Media Creation Tool（MCT）から作成するUSBメモリやISOファイルに、6月10日のPatch Tuesdayで配信されたセキュリティ修正と品質改善がすべて組み込まれており、クリーンインストール直後に大量のアップデートをダウンロードする手間が省けるようになった。 何が変わったのか 今回の「メディアリフレッシュ」とは、Windowsのインストールメディアそのものに最新の累積アップデートを焼き込む作業だ。従来、MCTで作成したUSBメモリは初期ビルドのまま配布されることが多く、インストール直後にWindows Updateが何GBもの差分を落とし、複数回の再起動を要求するという状況が日常だった。 新しいビルド26200.8655には以下が含まれている： 2026年2月〜6月分のPatch Tuesdayセキュリティ修正（カーネル・ネットワークスタック・グラフィクスサブシステム等の脆弱性対応） Secure Boot証明書の失効更新（KB5036210）——BootkitマルウェアBlackLotusへの対抗措置として、脆弱なブートマネージャーを初期状態からリボークする Intel・AMDプロセッサ向けマイクロコードアップデート（サイドチャネル攻撃対策） File Explorerの表示不具合やマルチモニター時のスタッタリング等の品質修正 ITエンジニア・管理者への実務的な意味 クリーンインストール運用の効率化 PCの初期セットアップを複数台まとめて実施するIT管理者にとって、メディアのベースラインが古いことは「見えないコスト」として蓄積する。1台あたり30〜60分かかっていたWindows Update待ちが、最新メディアを使うことで大幅に短縮できる。 とくに企業のPC入れ替え・オンボーディング作業が集中する時期には、このリフレッシュの恩恵が現れやすい。 Secure Bootの重要性 BlackLotusが示したように、Secure Bootの証明書失効が古いままのメディアからインストールすると、セットアップ完了直後から「保護されていない状態」が生じる。KB5036210の同梱は、この空白時間を潰す意味で正しい判断だ。 Secure Bootを「デフォルトで有効化する方向」に持っていくための地道な施策として評価できる。 メディアの取得方法 Microsoftの公式ダウンロードページからMCTを再ダウンロードするだけで自動的に最新ビルドが作成される。すでにUSBメモリを手元に持っている場合は、作り直しを推奨する。既存メディアのビルド番号は、ブート後のwinverまたはインストールISOのプロパティで確認できる。 実務での活用ポイント 展開用ゴールデンイメージの更新タイミングとして活用: 毎月のPatch Tuesdayの翌週にMCTを再実行し、ゴールデンISOを刷新するサイクルを確立すると、差分更新の手間が最小化できる USB作成後にビルド番号を必ず記録: 複数のUSBが混在する現場では、インストール後にwinverで確認するよりも、ラベルや管理台帳にビルド番号を記しておくほうが確実 Secure Boot有効化の社内標準化をこの機会に: 新しいメディアはSecure Boot前提の構成がより整合的になっている。まだSecure Bootをオフにしている端末が残っていれば、棚卸しのきっかけにしたい 筆者の見解 Windowsの細かい動向を毎回追うことの意義が問われる時代になったとはいえ、メディアリフレッシュのような地味な改善は着実にIT現場の生産性に効いてくる。こういう「裏方の丁寧な仕事」こそ、Microsoftが積み上げてきた運用品質の真骨頂だと思っている。 とくにSecure Bootの証明書失効をメディアに同梱する動きは、セキュリティを後付けではなくデフォルトに組み込むという正しい方向性だ。ゼロトラスト的な発想でいえば、「インストール直後が最も無防備な瞬間」を潰していくこのアプローチは評価したい。 欲を言えば、このメディアリフレッシュのタイミングと内容を、もう少し明示的にアナウンスしてほしい。今回も「静かに更新」されており、IT管理者が気づかず古いメディアを使い続けるケースは十分に起こりうる。Microsoftには、こういう地道な改善をもっと堂々と伝える発信力が必要だと感じる。良いものを作っているのだから、正面から伝えてほしい。 出典: この記事は Windows 11 June 2026 Media Refresh: New USB Install Baseline 25H2 (26200.8655) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11 Insiderプログラムにおいて、Beta・Experimental・Release Previewの全チャンネルを対象に1日で計7本のビルドをリリースした。これはInsiderプログラム史上最多の同日リリース数であり、現在進行中のチャンネル再編の複雑さを象徴している。 7本のビルド——何がどこに？ 今回同時リリースされたビルドは以下の通りだ。 チャンネル バージョン ビルド番号 Experimental (Future Platforms) — 29610.1000 Experimental 26H1 28120.2302 Experimental 25H2 26300.8687 Beta 26H1 28020.2298 Beta 25H2 26220.8680 Release Preview 26H1 28000.2333 Release Preview 24H2/25H2 26100.8728/26200.8728 3つのチャンネルそれぞれに複数バージョンが存在するこの構成は、正直わかりにくい。本質的に今回の更新で最も重要な変更が含まれているのは 25H2系のビルド群であり、26H1のビルドはその25H2で既出の機能を後追い移植しているにすぎない。 注目の新機能5選 1. Windows Updateの再起動が月1回に（Experimentalチャンネル） ドライバー・.NET・ファームウェアの更新を毎月の「Patch Tuesday」に集約することで、再起動を月1回に削減する仕組みが試験中だ。業務PCでのアップデート運用を担うIT管理者にとって、最も実用的な変更と言える。 2. Windows Searchがタイポに強くなる（Experimentalチャンネル） 「utlook」と打っても「Outlook」を検索できるようになるなど、タイプミスや文字抜け・文字追加への耐性が向上。Windows Settingsの検索精度もランキング改善により向上する。 3. Bluetooth接続の改善（Release Preview 25H2/24H2） Apple AirPodsのペアリング表示が高速化し、Beats Studio Proのマイク信頼性も改善。スリープ復帰後のBluetooth再接続速度も向上する。BYOD環境で個人用イヤホンを業務に使う場面が増えた昨今、実務への影響は小さくない。 4. Widgetが静かになる（Beta 25H2、Release Preview） ホバーで自動展開しなくなり、通知バッジの挙動も整理される。加えて、低メモリデバイスでのメモリフットプリントが削減される。「Widgetの通知がうるさい」という声は日本のユーザーからも多く聞こえており、実用改善だ。 5. アクセシビリティ強化（各チャンネル） 画面全体に色フィルターを重ねる「スクリーンティント」機能（目の疲れ軽減）、拡大鏡のズームプリセット追加、さらに音声アクセス・音声入力がフランス語・ドイツ語・スペイン語に対応した。日本語は今回未対応だが、グローバル展開の足固めが進んでいる。 「26H1はARMの踏み台」という重要な注意点 Microsoftはすでに明言しているが、Windows 11 26H1は次バージョン（26H2）へのインプレースアップグレードに対応しない。これはARM Siliconを搭載した新型PCに初期搭載する「ターゲット向けリリース」という位置づけだからだ。 企業のPC展開計画を担うIT管理者は、26H1の扱いに注意が必要だ。26H1搭載の新型ARMデバイスを調達する場合、将来の更新パスが通常と異なることを把握した上で管理設計を行うべきだ。 実務への影響——日本のIT管理者が今知っておくべきこと Windows Update運用の変化に備える: 再起動を月1回に集約する機能はExperimentalチャンネルで試験中であり、実際の一般提供まで数カ月かかる見込みだ。ただし方向性が固まってきたため、社内のパッチ管理ポリシーを「週次再起動前提」から「月次集約前提」へと段階的に検討し始める時期に入っている。 ...

MicrosoftはAKS（Azure Kubernetes Service）の2026年5月29日付リリースノートを公開し、AKS AutomaticのマネージドシステムノードプールがGA（一般提供）に昇格した。LocalDNSが新クラスターでデフォルト必須となるなど運用自動化が前進した一方、Flatcar Container Linuxの廃止期限が目前に迫っており、既存利用者には早急な移行対応が求められる。 マネージドシステムノードプール GA化の何が変わるか AKS AutomaticにおけるマネージドシステムノードプールがGAとなり、システムコンポーネント（kube-system 等）が動作するノードプールをAzureが完全管理する形が標準化された。 セキュリティ観点での変更点は大きい。GAとともに以下の制限が自動適用される： 新クラスターでは顧客提供のSSHキーをブロック（既存クラスターは保持するが追加不可） 複数レイヤーのセキュリティ制限が自動的に有効化 ノードへの直接アクセス経路が制限される 重要な注意点：マネージドシステムノードプールを持たない既存のAKS Automaticクラスターは、インプレースアップグレードで対応できない。クラスターを再作成してワークロードを移行する必要があるため、移行計画の立案が必須だ。 LocalDNS が新クラスターで必須化 新規作成するAKS Automaticクラスター、および既存クラスターへ追加する新ノードプールでは、LocalDNSモードが Required にデフォルト設定される。 LocalDNSはノードローカルのDNSキャッシュを利用して名前解決を行う。kube-dnsやCoreDNSのPodへの依存を削減し、クラスター内DNS応答速度と信頼性が向上する。マイクロサービス環境でDNS解決がボトルネックになるケースへの現実的な対処だ。 既存ノードプールへの変更はなく、新クラスター・新ノードプール追加時から有効となる。 Microsoft Defender for Containers にマルウェアスキャンが追加 Microsoft Defender for Containersにマルウェアスキャン機能が追加された。コンテナイメージや実行中ワークロードへの悪意あるコード混入を検知する。 サプライチェーン攻撃がKubernetes環境でも現実的な脅威となっている今、コンテナレイヤーでのスキャンは多層防御の重要な一手だ。Defender for Containersを既に有効化している環境では、ポリシーへの組み込みを検討したい。 廃止タイムライン：今すぐ対応が必要なもの ノードOS / 機能 廃止開始 完全削除 移行先 Flatcar Container Linux 2026年6月8日 2026年9月8日 Azure Container Linux for AKS Windows Server Annual Channel 2026年5月15日 2027年5月15日 LTSC（Long Term Servicing Channel） Windows Server 2019 2026年3月1日 2027年4月1日 Windows Server 2022以降 ...

Microsoftは、AIエージェント向け統合プラットフォーム「Microsoft Foundry」を正式提供（GA）開始し、Build 2026においてFireworks AIとの連携強化を発表した。「最も賢いモデル」を作る競争ではなく、「最も信頼できるプラットフォーム」を構築することで、エンタープライズAI市場の主導権を握ろうという大きな戦略転換だ。 Microsoft Foundryとは何か Microsoft Foundryは、Azure上でAIエージェントを構築・管理・監視するための統合基盤だ。単一のAzureエンドポイントから複数のAIモデル（オープンモデルを含む）にアクセスでき、モデルの選定・切り替え・コスト管理をひとまとめに行える。 今回のGAに合わせて特に注目されるのが、Fireworks AIとの統合だ。Fireworks AIは高性能な推論特化インフラを提供するスタートアップで、Foundryとの連携によりエンタープライズグレードのSLA（サービス品質保証）とSOC 2コンプライアンス対応のオープンモデル推論が、単一のAzureエンドポイントから利用できるようになった。 「能力競争」ではなく「信頼性競争」 Microsoftのこの戦略を端的に示すのが、「AIの能力よりも、AIを安全・確実・低コストで運用できる仕組みこそが企業採用の決め手になる」という読みだ。 現在のAI市場はGPT-4o、Claude、Geminiなど各社が最高性能を競い合う状況にある。しかしMicrosoftは、大企業が実際にAIを本番導入する際の課題は「どのモデルが賢いか」ではなく、次の3点だと見切っている。 コンプライアンスと監査対応 — 金融・医療・官公庁では、SOC 2やISO 27001、GDPRへの対応が必須条件 コスト可視化と管理 — 開発・検証環境のAIコストが予算超過するリスクへの対応 ガバナンスとアクセス制御 — 誰が何のエージェントを何に使ったかを追跡・制御する仕組み Foundryはこの3つを一元的に解決するプラットフォームとして設計されている。 Fireworks AI統合が実務にもたらすもの Fireworks AIの推論インフラは、LlamaやMixtralなどオープンソースLLMを商用グレードで動かすことに特化している。今回のFoundry統合により、以下が実現する。 Azure環境を離れることなく、最新のオープンモデルを本番グレードのSLAで利用できる コスト効率の高いオープンモデルと高性能なクローズドモデルを、同一のAPIで柔軟に切り替えられる セキュリティ監査・ログ記録もAzure標準のツールチェーンで完結する 「AIモデルの選択肢を広げながら、運用基盤はAzureに統一できる」という実践的なメリットは、特にマルチモデル戦略を検討している組織に刺さる提案だ。 日本のIT現場への影響 日本の金融・製造・公共セクターでは、クラウドやAIの採用においてコンプライアンス要件が非常に厳しい。「オープンモデルを使いたいがSOC 2対応ができないためプライベートモデルに限定せざるを得ない」という状況は、IT部門からよく聞く話だ。 Microsoft Foundryの正式提供により、この制約が一部緩和される可能性がある。Fireworks AI経由のオープンモデル推論がAzureのコンプライアンス傘下に入ることで、IT部門が経営層や法務部門へ説明しやすくなる。 また、Azure OpenAI Serviceで管理基盤を標準化している組織にとっては、追加の学習コストなしに利用可能モデルの幅を広げられる点も評価ポイントになるだろう。エージェント管理においてMicrosoft Entra IDを中心に据えている構成とも親和性が高い。 筆者の見解 Microsoftのこの戦略には、一定の説得力がある。「最強のモデルを作る競争」では厳しい場面があっても、「エンタープライズが安心してエージェントを大量に動かせるプラットフォーム」という土俵なら、長年の実績と信頼を武器に戦える。 Foundry経由で他社AIモデルを統一基盤で使えるようにした判断は賢明だと思う。「Azureを使いながら最適なモデルを選べる自由度」を提供することで、プラットフォームの価値を高め、Azure離れを防ぐ有力な手段になりうる。エージェントの管制塔としてMicrosoft Entra IDが機能し、実行モデルは状況に応じて最適なものを選ぶ——この構成は、筆者が実務で推奨しているアーキテクチャと合致している。 一方、「信頼性で勝負」という戦略が「能力競争から降りた」と受け取られるリスクも否定できない。プラットフォームとしての強みは本物であり、Microsoftが勝てる土俵だ。そこに加えて、Copilotをはじめとした自社AIサービスの品質も地道に磨き続けてほしい。強固なプラットフォームと優れた自社モデルが揃ったとき、Microsoftの本当の強みが発揮される。その日が来ることを楽しみにしている。 出典: この記事は With Foundry, Microsoft bets the enterprise AI battle is about reliability, not capability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は2026年6月のBuild 2026（サンフランシスコ）において、Microsoft Foundryに対してエンタープライズ向けAIエージェントの本番運用を支える大規模な機能拡張を発表した。単なる「新しいモデルエンドポイントの追加」ではなく、ランタイム・ツール管理・メモリ・知識検索・ガバナンスまでを一体で提供する「AIエージェント工場」へと進化した形だ。 Foundryとは何か——改めて整理する Microsoft Foundryは、Azureを基盤とした統合AIアプリ・エージェント開発プラットフォームだ。Azure サービスとのネイティブ連携、Microsoft 365データソースへのアクセス、そしてフレームワーク間の相互運用を特徴とする。今回のアップデートは、2025年にGA（一般提供）となったAzure AI Foundry Agent Serviceをさらに拡張するものとなっている。 今回追加された主要機能 ホスト型エージェントインフラ（Foundry Agent Service） マネージドなサンドボックスセッションが提供され、エージェントは状態・ファイルシステムアクセス・複数フレームワーク対応を持ったまま動作できる。APIはステートフルな「Responses API」と軽量な「Invocations Protocol」の2種類が用意され、用途に応じて使い分けが可能だ。 注目すべきはルーティン（Routines）機能がパブリックプレビューに入ったことだ。エージェントをスケジュール実行できるようになり、「夜間のチケットトリアージ」「日次レポート生成」といったバッチ的な自動化がFoundry上で完結する。OpenClawやHermesといった長時間稼働エージェントも、永続的な状態とファイルを持ったまま動作できる。 Toolbox——ツール管理の一元化 ツール・スキル・MCPクライアント・エンタープライズデータ統合を一本のマネージドエンドポイントに集約する「Toolbox」がパブリックプレビューになった。これまでは各エージェントにツールをハードコードする必要があったが、Toolboxでは登録したツールをランタイムに動的に検索・呼び出せる。 特に重要なのがTool Search機能だ。モデルに全ツールを渡すのではなく、タスクに関連する少数のツールだけを選択してモデルに提示する。これはコストとレイテンシの両方に効く実用的な設計だ。 また、Microsoft TeamsおよびMicrosoft 365 Copilotへの直接パブリッシュが2026年6月にGA予定となった。Foundryで構築したエージェントを、IDやポリシーが自動適用された状態で従業員の日常作業環境に展開できる。 メモリ機能——「何を話したか」から「どうやるか」へ Foundry Agent Serviceのメモリは、手続き記憶（Procedural Memory）・ユーザー記憶・セッション記憶の3種類に体系化された。 中でも手続き記憶はBuild 2026での新機能だ。従来のメモリが「何を話したか」を記録するものだったのに対し、手続き記憶は「どうやって仕事をこなすか」をエージェントが学習し次回以降に活かす機能だ。初期ベンチマーク（Tau bench）では、タスク成功率が7〜14ポイント改善したと報告されている。コストはほぼ変わらない水準での改善だという点も評価できる。 メモリストアはMicrosoft Entra IDをスコープ識別子として使い、保持期間や内容の検査も制御できる。 Foundry IQ——知識レイヤーの統一 Work IQ・Fabric IQ・Azure SQL・ファイル検索など複数の情報源を単一のSLA付きナレッジレイヤー「Foundry IQ」として統合した。グラウンディング（文脈付与）と検索を一元化することで、エージェントが参照すべき情報源を個別に実装する手間をなくす設計だ。 日本のエンジニア・IT管理者への影響 AIエージェント導入の「本番稼働」ハードルが下がる これまで日本企業がAIエージェントの本番導入を躊躇する理由の一つは、「ガバナンスや監査対応をどうするか」という問題だった。今回のFoundry強化により、Entra IDと統合した権限管理・ポリシー適用・オブザーバビリティがプラットフォームレベルで提供される。セキュリティポリシーの実装をエージェントごとにゼロから作る必要がなくなる。 Toolboxは「AIエージェントのマイクロサービス化」 Toolboxの思想は、エンタープライズ内の業務機能をMCPスキルとして登録し、複数エージェントから再利用するアーキテクチャを促進する。日本企業で多い「部署ごとに似たようなツールを個別実装」という状況を、組織横断で共有するツールカタログへと変えていく布石になり得る。 ルーティン機能で既存の自動化ニーズを取り込む 「夜間バッチで稼働するAgentにする」という需要は日本のSI現場でも強い。Foundry上でスケジュール実行が完結するようになれば、既存の定時ジョブをAIエージェントとして再設計する際の移行コストが下がる。 筆者の見解 Microsoft Foundryの今回の発表を見て、「ここにいた」と感じた。モデルをAPIで呼ぶだけなら誰でもできる。難しいのは、エンタープライズがAIエージェントを安全に、監査可能な形で、既存のIDインフラと統合して動かすことだ。その「難しい部分」をプラットフォームが引き受けるという方向性は、正しいと思う。 Entra IDをエージェントの管制塔として使う設計は長期的に見ても筋が良い。ゼロトラストの観点からも、エージェントのアイデンティティ管理は人間と同じ仕組みに統合されるべきであり、Foundryはその方向に向かっている。 一方で、手続き記憶の「7〜14ポイント改善」という数字はベンチマーク環境での話だ。実運用での再現性はこれから問われる。日本企業が本番導入を進めるには、ガバナンス設定の複雑さや既存システムとの統合コストをどう下げるか、ドキュメントとサポート体制がカギになるだろう。 ツールチェーン全体を統合し、エージェントが安全に動ける場所を作るというのはMicrosoftが最も強みを持てる勝負だ。その力を存分に発揮できるよう、実装の細部まで丁寧に仕上げてほしいと思う。 出典: この記事は Microsoft Foundry Adds Runtime, Tooling, and Governance for Production Agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが、職場内で稼働する自律型AIエージェントを一元管理・追跡するプラットフォーム「Microsoft Agent 365」を発表した。2028年までに企業の業務自動化を担うエージェントが13億個に達すると予測する同社が、ガバナンス基盤の整備に本格的に乗り出した形だ。 AIエージェント管理という新しい課題 コード生成やデータ分析、サプライチェーン管理など、業務の自動化を担うAIエージェントの導入が企業で加速している。個別に便利なエージェントを次々と導入した結果、「社内に何個のエージェントが動いているのかわからない」という状況は、すでに多くの企業で現実になりつつある。 Microsoft商業部門CEOのジャドソン・オルソフ氏は「棚卸エージェント」「在庫不足エージェント」など複数のエージェントが並走する環境を例に挙げ、「ツールなしに、それらがプロセス全体でどう組み合わさっているかを把握するのは非常に困難」と述べた。このコメントは、現場の痛みをそのまま言語化したものとして説得力がある。 Microsoft Agent 365の主な機能 Microsoft Agent 365は、IT管理者がネットワーク上のユーザー管理と同じ感覚でAIエージェントを管理できるプラットフォームとして設計されている。主な機能は以下のとおりだ： エージェントの可視化・追跡: 社内で稼働するすべてのエージェントをダッシュボード上で一覧把握 不正エージェントの隔離: 想定外の動作をするエージェントをシステムから切り離す「検疫」機能 生産性ツールの付与: 承認済みエージェントに必要なツールセットを割り当て サイバー攻撃からの保護: エージェントを経由したセキュリティリスクへの対応 ROI計測: AIエージェントへの投資対効果を定量的に可視化 特筆すべきは、Microsoft製だけでなくSalesforceなど他社製エージェントも管理対象に含まれる点だ。マルチベンダー環境を前提とした設計は、実際の企業ITの現実に正直に向き合った判断といえる。 同時に発表された「Work IQ」は、Microsoft 365 Copilotを動かすインテリジェンスとビジネスデータを活用して独自エージェントを構築できるサービスで、企業独自のAIカスタマイズ需要にも対応する。現在、Microsoft 365ライセンス保有者向けの早期アクセスプログラムへの申請が可能だ。 実務への影響——「エージェントも人間と同じように管理する」発想の転換 日本のエンジニア・IT管理者にとって、このプラットフォームが突きつけるのは根本的な認識の転換だ。AIエージェントも、人間のユーザーアカウントと同様にアイデンティティ管理の対象になる。 明日から意識すべきポイントは3つある： エージェントのインベントリ化を今すぐ始める: 社内に何個のエージェントが稼働しているかを把握できていない時点でリスクがある。まず現状把握から着手すること Non-Human Identity（NHI）管理の設計を見直す: AIエージェントはサービスアカウントやAPIキーと同じく「人間ではないアイデンティティ」として管理が必要になる。既存のIAMフレームワークにエージェントをどう組み込むかを今から検討しておく 最小権限の原則を徹底する: エージェントに「必要以上のアクセス権」を与えないことがリスク低減の基本。Just-In-Timeアクセス制御をエージェントにも適用する設計を標準にすべきだ 監視なしのエージェントがどれほどの被害をもたらすか——AIエージェントが意図せずAWSで多額の費用を発生させた事例が話題になったように、エージェントの暴走コストは甚大だ。ガバナンス基盤の整備は「あったら便利」ではなく「必須インフラ」の問題になってきている。 筆者の見解 AIエージェントのガバナンス基盤は、これから1〜2年で企業ITの最重要課題になると見ている。「エージェントを使いこなす前に、管理できる状態を作る」——この順序は間違いなく正しい。 Microsoftがこの問題に本腰を入れてきたこと自体は評価したい。他社製エージェントも管理対象に含めるオープンな設計は、プラットフォームとしての全体最適を志向するMicrosoftらしいアプローチだ。Microsoft 365が持つ深いデータ統合と認証基盤との組み合わせで、エージェントガバナンスに強力な土台を提供できるポテンシャルは確かにある。 正直に言えば、「もう少し早く来てほしかった」という思いもある。エージェント市場が爆発的に拡大している今、ガバナンス側が後追いになってしまっているのはもったいない。これだけのインフラ資産を持っているのだから、先行してこの問題を定義できる立場にいたはずだ。 とはいえ、「早くて中途半端」よりも「しっかりとした仕組みが遅れて来る」方が長期的には価値がある。NHI管理の観点から、エージェントに最小権限を付与しJust-In-Timeでアクセスを制御する仕組みがMicrosoftの標準プラットフォームとして整備されれば、日本企業の自動化推進は大きく前進するはずだ。その期待を込めて、今後の展開を注視していきたい。 出典: この記事は Microsoft launches tracker to manage autonomous AI in the workplace の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月11日、Power Platformの大型月次アップデートを公開し、AIエージェントの「クローズドループ学習」機能をはじめ、コネクタガバナンスの強化、インベントリAPI、RPAデバッガーのバージョン比較対応など、エンタープライズ向けの機能が一挙に追加された。 今回のアップデートの主要機能 クローズドループエージェント学習 今回の目玉機能が「クローズドループエージェント学習（Closed-loop Agent Learning）」だ。AIエージェントが実行した処理の結果をフィードバックとして取り込み、次回以降の意思決定に反映させる仕組みである。 従来のPower Automateフローは「設計者が明示的に定義したロジックを実行する」だけだったが、クローズドループ学習を組み込んだエージェントは実行結果を自分で評価して改善していく。受注データの分類精度を自ら向上させたり、異常検知のしきい値をビジネスの実態に合わせて動的に調整したりするユースケースが想定される。 コネクタガバナンスとインベントリAPI Power Platformではサードパーティ製「コネクタ」を通じて数百のサービスと連携できるが、企業IT管理者の長年の悩みは「どのコネクタが使われているか把握できない」「未承認のコネクタがセキュリティリスクになる」という点だった。 今回追加されたコネクタガバナンス機能とインベントリAPIにより、テナント内で使用中のコネクタを一覧化し、承認・禁止のポリシーをAPIレベルで制御できるようになった。さらにCMDB（構成管理データベース）との連携により、コネクタの使用状況を既存の資産管理ツールに統合できる。ServiceNowやその他のITSMツールと組み合わせれば、Power Platform全体のガバナンスを一元管理する基盤になりえる。 RPAデバッガーのバージョン比較対応 Desktop Flow（デスクトップ自動化）のデバッガーが強化され、フローの異なるバージョン間での差分をビジュアルに比較できるようになった。更新後に挙動が変わった際の原因特定が大幅に効率化される。 実務では「誰かが修正したフローで別の担当者のワークフローが動かなくなった」というトラブルが頻繁に発生する。バージョン比較機能はそうした現場課題を直接解決する実践的な強化だ。 実務への影響 IT管理者へ: コネクタガバナンスのAPIとCMDB連携は、ゼロトラスト戦略の観点でも重要だ。使用中のコネクタが把握できていない状態は、認可されていない接続経路が存在するリスクと同義である。今回の機能を活用して、まず「現状の棚卸し」から着手することを強く推奨する。 開発者・市民開発者へ: クローズドループ学習を活用するには、エージェントに「何を正解とするか」を明確に定義するフィードバックループの設計が不可欠だ。「なんとなくAIに任せる」ではなく、ビジネスロジックの評価軸を先に定義してからエージェントを構築する順番が重要になる。 全社展開を検討している企業へ: インベントリAPIはPower Platformガバナンスの「見える化」に直結する。CISOや情報システム部門が全社展開に慎重なケースの多くは「何が動いているかわからない」という不安からきている。このAPIがその心理的障壁を下げる可能性がある。 筆者の見解 Power Platformのアップデートサイクルは一貫して速く、今月も企業が実際に困っているポイントを正面から突いた機能が揃った印象だ。特にコネクタガバナンスとCMDB連携は「自動化を広げたいが統制が怖い」というIT部門の典型的なジレンマに対する、現実的な回答になりえる。 クローズドループ学習については、「エージェントが自ら学習する」という言葉のインパクトに対して、実際の運用設計は丁寧に行う必要がある。学習の方向性を定義するのは結局人間であり、フィードバックループの品質がエージェントの品質を決める。「AIに任せたら勝手に良くなる」という期待値のズレは、現場でしっかり管理しなければならない。 もったいないと感じるのは、これだけ実用的な機能が揃っているにもかかわらず、日本の大企業では「Power Platform＝市民開発のおもちゃ」という認識がまだ残っているケースがあることだ。エンタープライズグレードのガバナンス機能が整ってきた今、その認識をアップデートする絶好のタイミングに来ている。Microsoftはこの領域できちんとした実力を持っているのだから、現場がその実力を正当に評価できる環境を作っていくことが重要だ。 出典: この記事は What’s New in Power Platform: June 2026 Feature Update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

The Vergeのシニアコレスポンデント、トム・ウォーレン氏が2026年5月6日に独占報道したところによると、マイクロソフトが米国の長期勤務社員を対象に初めて実施する「自発的退職（Voluntary Retirement）」プログラムの詳細が、社内HRサイトに予定より早く掲載されたという。 なぜこのプログラムが注目されるのか 創業から50年が経つマイクロソフトが、その歴史の中で一度も実施したことのない希望退職プログラムを打ち出した——この事実だけでも異例といえる。今四半期に計上する9億ドル（約1,350億円）の費用は、The Vergeも引用するGeekWireの試算では「同社の1日分の売上にほぼ相当する」。それだけの原価を積んで組織を刷新しようとする背景には、AI時代への本格的な移行という文脈がある。 希望退職パッケージの詳細 The Vergeの報道によれば、対象となるのは「勤続年数＋年齢が70以上」の米国従業員で、全米国従業員の約7%・約8,750人が該当する見込みだ。 医療保険 医療・歯科・視力・ウェルネス保険が5年間提供される 1年目はマイクロソフトが全額負担（完全無償） 2〜5年目は月額保険料を本人が負担 現金一時給付（職位レベル別） レベル64（中堅上位）：勤続6ヶ月ごとに1週間分の基本給、最大39週分 レベル65〜67（シニア職）：勤続6ヶ月ごとに2週間分の基本給、最大39週分 未確定株式（RSU）の追加ベスティング 退職後6ヶ月分の未確定株式が付与される 勤続24年以上の社員は12ヶ月分に延長 判断期間は申し込み開始から30日間。 日本市場での注目点 現時点でこのプログラムは米国従業員のみが対象であり、日本法人への展開は発表されていない。ただし、日本のITエンジニア・経営者にとって示唆する点はいくつかある。 まず制度面では、日本では労働契約法・整理解雇の4要件があるため、米国型の「At-will雇用」を前提とした希望退職スキームをそのまま持ち込むことは難しい。仮に日本法人で同様の施策を行う場合、より手厚い条件設計と丁寧な合意形成プロセスが必要になる。 次に業界トレンドとして、マイクロソフト・アマゾン・メタなど大手テクノロジー企業がAI投資と並行して組織のスリム化を進めている事実は重い。日本のIT企業も「一括新卒採用→長期雇用」モデルを前提に設計された人事制度が、このスピード感に対応できるかを問われる局面に入りつつある。 筆者の見解 創業50年で初という事実が示すとおり、これはマイクロソフトにとって並々ならぬ決断だ。9億ドルという大きな一時費用を計上してでも、組織の構造を変えに行く姿勢はむしろ評価したい。 一方で、「もったいない」という感想も正直なところだ。Windowsの世界普及期、Azureの黎明期、Officeエコシステムの構築期を知る長期在籍社員が持つ知識と文化は、数字では測れない価値がある。その層がまとめて外に出てしまうリスクは、短期的なコスト改善と単純には引き換えにできない。 マイクロソフトにはCopilot Studio、Azure AI Foundry、GitHub Copilotと、AI領域の布陣は着実に整いつつある。この再編を経て、同社が本来持っている「総合プラットフォームとしての強み」をAI時代に正面から発揮できるかどうか——それが問われている局面だ。今回の投資が1〜2年後に実を結ぶかどうか、注目して見ていきたい。 出典: この記事は Here’s what Microsoft is offering long-serving employees to voluntarily retire の内容をもとに、筆者の見解を加えて独自に執筆したものです。