Tech News JP

AnthropicとAWSは2026年4月、Anthropic史上最高性能のAIモデル「Claude Mythos」をAmazon Bedrockのゲーテッド・リサーチ・プレビューとして公開した。サイバーセキュリティ・コーディング・複雑な推論の3領域で最先端の性能を持つとされるこのモデルは、「Project Glasswing」の一環として、まずインターネット基盤を支える企業とオープンソースプロジェクトのメンテナーに限定提供されている。 Claude Mythosとは何か Claude Mythosは、Anthropicが「根本的に新しいモデルクラス」と位置づける最新の最高性能モデルだ。特に注目すべきはサイバーセキュリティ領域への特化である。 モデルの主な能力は次の通りだ： 高度な脆弱性発見: ソフトウェアに潜む巧妙な脆弱性を特定し、実際の悪用可能性（exploitability）まで評価できる 大規模コードベースの把握: 数百万行規模のコードを理解した上で、実行可能な改善提案を提示 自律的な動作: 従来モデルと比較して人間の介入を大幅に減らしながら診断・提案を完結できる これは単なる「AIによるコードレビュー」の延長ではない。セキュリティチームが攻撃者の視点でシステムを診断し、修正提案まで行うAIエージェントとして機能するものだ。 Project Glasswingの戦略的意図 なぜこれほど慎重なアプローチをとるのか。 Anthropicは強力なサイバーセキュリティ能力を持つモデルを公開するにあたり、意図的に段階的リリースを選択した。最初の対象は以下の2種類に絞られている： インターネット基盤を支える企業（クラウドプロバイダー、金融インフラ等） 数億人のユーザーに影響するオープンソースソフトウェアのメンテナー 理由は明快だ。「攻撃者より先に防御者の手に渡す」という原則だ。同一のモデルが悪意ある者の手に渡れば、大規模な脆弱性悪用に転用されるリスクがある。まず守る側に提供してインターネット全体の安全性を底上げし、その後に公開範囲を広げていくという戦略だ。 AWS CISOのAmy Herzog氏が「脅威が顕在化する前に防御を構築する（Building AI Defenses at Scale: Before the Threats Emerge）」と表現しているのがこの姿勢をよく表している。 現在のアクセス状況 提供状況の概要： 項目 内容 利用可能リージョン 米国東部（バージニア北部）のみ アクセス条件 事前承認（allow-list）制 承認通知方法 AWSアカウントチームから直接連絡 日本からの利用 現時点では不可 日本の企業が直接利用できるのは、当面先の話とみるべきだ。ただし、プレビュー期間中の知見がブログ・論文・ツールの形で公開されることは期待できる。 実務への影響 セキュリティエンジニア・ペネトレーションテスター Claude Mythosのような強力なセキュリティ特化モデルが実用化されれば、脆弱性診断の「調査・列挙フェーズ」を大幅に自動化できる可能性がある。現在は熟練エンジニアが数日かけて行う作業が、AIエージェントとの協働で数時間に短縮されるシナリオは十分リアルだ。 一般的な開発チーム 直接利用できなくても、GitHubのDependabotやSnykのようなセキュリティツールにこうしたモデルが組み込まれ、間接的に恩恵を受けるシナリオが現実的だ。「インフラを持つパートナーを通じてモデルが届く」というAmazon Bedrockの役割がここでも発揮される形になる。 IT管理者・CISO 自社ソフトウェアのサプライチェーン全体のリスクをAIが自動評価する時代が来ることを念頭に、セキュリティ評価プロセスの再設計を今から考えておく価値がある。「毎年1回の脆弱性診断」という従来のペースでは、AIを使いこなす攻撃者のスピードに追いつけなくなるリスクがある。 筆者の見解 サイバーセキュリティ特化のAIモデルが登場すること自体は、技術的必然だと思う。ソフトウェアの複雑性が増すにつれて、人間だけの脆弱性診断には構造的な限界がある。AIがコードベース全体を把握した上で攻撃者視点で診断するアプローチは、防御側に大きな恩恵をもたらすはずだ。 今回特に興味深いのは、リリース戦略の設計だ。「まず防御者に届ける」という順序付けは、強力なAI能力の管理における一つのモデルケースになりそうだ。サイバーセキュリティは「諸刃の剣」性が特に高い領域だけに、このような段階的アプローチは合理的だと評価できる。 日本の企業・エンジニアにとって、直近でClaude Mythosを直接試せる機会は限られるだろう。とはいえ、「AIがセキュリティ診断のパラダイムを変える」というトレンドの方向性は明確だ。情報を追いかけるよりも、オープンソースコミュニティから出てくる知見を実際の自社システムにどう適用するかを考え始めるには、今がちょうどいいタイミングかもしれない。 出典: この記事は Amazon Bedrock now offers Claude Mythos Preview (Gated Research Preview) の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AnthropicはClaude Opus 4.7を2026年4月16日に一般公開した。同社の最高峰モデル「Claude Mythos Preview」より意図的にサイバー能力を抑制した設計で、前世代のClaude Opus 4.6から複数の性能指標で向上しながらも、安全な広域展開を優先した「橋渡しモデル」として位置づけられている。 Claude Opus 4.7の立ち位置——Mythosへの「安全な橋」 Anthropicのモデルファミリーには今、明確な序列がある。最高峰の「Claude Mythos Preview」は今月初め、Project Glasswingという新たなサイバーセキュリティイニシアティブの一環として、選ばれた企業グループにのみ限定公開された。Mythosは強力すぎて現時点での一般公開を想定していない——そこで登場するのがClaude Opus 4.7だ。 Anthropicの公式発表によれば、Opus 4.7はOpus 4.6を以下の点で上回る： エージェント型コーディング（agentic coding）の業界ベンチマーク 多分野推論（multidisciplinary reasoning）の精度 大規模ツール活用（scaled tool use）の安定性 エージェント型コンピュータ操作（agentic computer use）の精度 一方で、サイバー攻撃への応用を可能にする「高度なサイバー能力」は、トレーニング段階から意図的に「差分削減（differentially reduce）」したと同社は説明する。強力だが安全——この設計思想そのものがOpus 4.7の本質だ。 セーフガードと正規申請ルート AnthropicはOpus 4.7に「禁止用途・高リスクなサイバーセキュリティ利用を自動検知・ブロックするセーフガード」を組み込んでいると明示した。ただし正規のセキュリティ専門家に向けては、公式の検証プログラム（formal verification program）への申請という形で合法的な利用経路も確保している。 「禁止で終わらせる」のではなく「安全な経路を設計する」というアプローチが特徴的だ。Project Glasswingと本モデルの広域展開から集まるデータを蓄積し、最終的にMythos級モデルを一般公開することが長期目標だとAnthropicは述べている。 料金・提供チャネル Claude Opus 4.7はClaude Opus 4.6と同価格。AnthropicのAPIおよびClaudeプロダクト群に加え、クラウドプロバイダー経由——Microsoft Azure、Google Cloud、Amazon Bedrock——でも利用可能だ。日本企業がすでにこれらのクラウドを活用しているケースは多く、既存の契約・ガバナンス体制のまま新モデルに移行できる。 実務への影響——日本のエンジニア・IT管理者へ 価格据え置きで性能アップは単純に朗報だ。エージェント型コーディングの向上は、CI/CD自動化・コードレビュー・ドキュメント生成など実業務への直接的な恩恵をもたらす可能性が高い。 Azure経由で利用している企業は、社内のデータガバナンスやコンプライアンス要件を変えることなく新モデルへアクセスできる。データの取り扱いに厳格な日本企業にとって、クラウドプロバイダー経由での継続利用は現実的で安心できる選択肢だ。 セキュリティ担当者には、Project Glasswingの正規申請ルートも注目しておく価値がある。ペネトレーションテストや脆弱性評価への活用を検討しているチームにとって、公式の申請窓口が整備されていること自体、信頼性の指標になる。 筆者の見解 「能力を最大化したモデルをいきなり一般公開するのではなく、実世界のフィードバックを集めながら段階的に商用化の経路を育てていく」——このAnthropicのアプローチは、再現性という観点で評価できる。標準的で堅実な道筋を選ぶ姿勢は、企業がAI導入を検討する際にも参考になる考え方だ。 エージェント型コーディングの性能向上という観点では、AIが「人間に確認を求め続ける設計」から「自律的にタスクをループで回す設計」へと移行しつつある業界の流れと一致している。Opus 4.7の改善点はその方向性を補強するものだ。 ただし、モデルの能力向上だけに注目しすぎるのはもったいない。どのモデルを使うかより「どう使う仕組みを設計するか」の方が、実務では圧倒的に重要だ。新モデルに乗り換えるだけで満足せず、AI活用の仕組み——タスクの渡し方、結果の検証方法、ループの設計——をセットで整備することが本当の意味での活用につながる。 出典: この記事は Anthropic rolls out Claude Opus 4.7, an AI model that is less risky than Mythos の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはWindows 11の2026年5月更新（May 2026 Update）にて、「Xbox Mode」をデスクトップPC・ノートPC・タブレットへ段階的に展開し始めた。以前は「Xbox Full Screen Experience」としてASUS ROG AllyやLenovo Legion Goといったハンドヘルドゲーミングデバイス向けに先行提供されていたが、今回の更新で一般のWindows 11環境にも広がる。 Xbox Modeとは何か Xbox Modeは、Windowsの上に「コンソールライク」なゲームインターフェースを重ねる機能だ。起動すると全画面表示に切り替わり、コントローラーだけで快適に操作できるUIが展開される。 主な特徴は以下のとおり： 統合ゲームライブラリ: Xbox Game Passのタイトルに加え、他のPCゲームストアのゲームも一画面で一元管理できる コントローラー最適化UI: マウス・キーボードが不要な、コンソール感覚の操作体験 Win+F11で即起動: ショートカットキー一発でWindowsデスクトップとXbox Modeを行き来可能 Windowsの開放性を維持: 閉じたエコシステムではなく、Windowsの柔軟性の上に重ねた形 段階的ロールアウト——すぐには届かない場合も 今回の展開は段階的ロールアウト（Staged Rollout）であり、市場・地域・ハードウェア要件によって受け取れる時期が異なる。 早期に入手したい場合は、「Windows Update」設定で「最新の更新プログラムをすぐに入手する」オプションを有効にし、2026年5月セキュリティ更新（プレビュー版）を手動で確認する方法が有効だ。インストール後は「設定」アプリの「ゲーム」セクションからXbox Modeを有効化できる。 なお、旧称の「Full Screen Experience」を強制的に有効化する方法も引き続き機能しており、段階的展開を待てないユーザーはこちらも選択肢となる。 ハンドヘルドからデスクトップへの戦略的拡張 Microsoftがこのモードをハンドヘルド向けに先行提供していた背景には、コンソールに近い操作体験をWindows上で実現する実験的側面があった。今回の一般PC展開は、その実験が一定の成熟を見せたと判断した結果と読み取れる。 「Xbox」ブランドをPCゲーム体験にも積極的に植え付けていく戦略の一環でもあり、PlayStation PCソフト展開やSteam Deckとの競合という業界トレンドへの明確な回答でもある。 日本のIT現場・ゲーマーへの影響 IT管理者目線では、Xbox Modeは管理対象デバイスへの影響がほぼないと考えてよい。Xbox ModeはWindowsのゲーミングレイヤーに限定した機能であり、IntuneやグループポリシーによるWindowsデバイス管理のフレームワークはそのまま機能する。 一方、PCゲーマーにとっては試す価値がある変化だ。複数のストアにゲームを分散管理していた人にとって、一元化されたライブラリUIは実用的な便利機能となる。特にXbox Game Passを契約しているユーザーなら、コンソールとほぼ同じ感覚でゲームを起動できるようになる点は大きい。 筆者の見解 正直に言えば、Windowsを細かく追うこと自体への関心は年々薄れてきている。それでもXbox Modeには、今回いくつかの意味で注目している。 Microsoftがこれまで「PCゲームはSteamに任せる」的な消極的姿勢を続けてきた中で、Windowsの上にゲーム専用UIを重ねるアプローチは、コンソールとPCの橋渡しとして理にかなった方向性だ。閉じたエコシステムを作るのではなく、Windowsの開放性を保ちながら体験を改善するという姿勢は評価できる。 ただし、今後の成否を決めるのは「Game Passコンテンツの充実度」と「他のPCストアとの統合精度」の2点だ。見せ方よりも中身——コンテンツの質と統合の深さ——に力を入れてほしいところだ。中途半端なまま放置されることが一番もったいない。 PCゲームの体験をここまで本気でXboxブランドで引っ張る覚悟があるなら、ぜひ最後まで本気でやりきってほしい。Microsoftにはその力がある。 出典: この記事は Xbox mode rolls out to Windows 11 PCs in May 2026 update, formerly Full Screen Experience の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、Azure Virtual Desktop（AVD）のハイブリッド展開オプションを大幅に強化し、Azure Arcを介してオンプレミスの既存インフラ——Nutanix AHV、VMware vSphere、物理Windowsサーバー——上でAVDセッションホストを稼働させる「Azure Virtual Desktop Hybrid」の技術詳細を公開した。これまでAzure VMまたはAzure Localが前提だったAVD展開の選択肢が、企業の既存資産を活かした構成にまで広がる。 Azure Virtual Desktop Hybridとは何か Azure Virtual Desktop（AVD）はMicrosoftのクラウドベースVDI（仮想デスクトップ基盤）サービスだが、これまでセッションホストはAzure VMかAzure Local（旧Azure Stack HCI）に限られていた。今回のAVD Hybridはこの前提を崩し、Azure Arcを管理プレーンとして使うことで、オンプレミスの任意のインフラ上にAVDセッションホストを配置しつつAzureから一元管理できる構成を実現する。 対応プラットフォームは以下の4種類: Azure Local（旧Azure Stack HCI） Nutanix AHV VMware vSphere 物理Windowsサーバー NutanixとVMwareへの対応は特に注目に値する。日本の大手企業や金融機関ではこれらのハイパーバイザーが広く採用されており、既存資産の有効活用につながる。 Azure Arcが果たす役割 AVD Hybridの核心はAzure Arcだ。Azure Arcはオンプレミスやマルチクラウド環境をAzureの管理プレーンに接続するサービスで、今回の構成ではオンプレミスのAVDセッションホストに対して以下を可能にする: Azure portalからの一元管理 Azure MonitorおよびLog Analyticsによる監視 Microsoft Entra IDとの統合認証の維持 Intuneによるポリシー管理の適用 物理的にはオンプレミスに存在するセッションホストが、管理体験としてはフルクラウドAVDと同等になる点が最大の特徴だ。 なぜこれが重要か AVD Hybridが日本のIT現場で意味を持つ理由は主に2点ある。 規制対応とコスト効率の両立: 金融・医療・公共セクターではデータを国内オンプレミスに置くことが求められる場面がある。一方でVDIの管理コストをクラウド活用で削減したいニーズも強い。AVD Hybridはこの二律背反を解消するアーキテクチャだ。 脱VPNへの近道: 従来のオンプレVDIは社内VPN接続が前提だったが、AVDはReverse Connection方式を採用しユーザー側からの受信接続を不要とする。ゼロトラスト原則に自然に適合するアクセスモデルだ。 実務での活用ポイント 既存Nutanix/VMware環境の段階活用 ハードウェア更改タイミングを待たずに導入できる。まずAzure Arcエージェントを既存VM上に展開してAVD Hybridセッションホストとして登録し、管理をAzureに寄せていくアプローチが現実的だ。 段階的クラウド移行設計 オンプレ資産を維持しながら新規ワークロードはAzure側AVDで受ける構成にすることで、フルクラウド移行への段階的ロードマップを描きやすくなる。 コスト試算の注意点 セッションホスト自体はオンプレのためVM分のAzureコストは発生しないが、Azure ArcのライセンスとAVDアクセスライセンス（SAL）は別途必要になる。導入前にTCOを丁寧に計算することが欠かせない。 ...

Microsoftは2026年5月1日より、Azure Service Bus PremiumをAvailability Zone（AZ）対応の全リージョンで99.99%のSLAを提供開始した。従来の99.9%から一段階上の信頼性保証へ格上げされ、金融・医療・EC系など厳格なSLA要件を持つシステムへの採用ハードルが大幅に下がる。 99.9% と 99.99% ——たった0.09%が意味する現実 数字だけ見ると微差に見えるが、年間ダウンタイムの許容時間に換算すると話は変わる。 SLA 年間許容ダウンタイム 99.9% 約8時間44分 99.99% 約52分 実に10倍近い差だ。金融機関の決済処理や製造ラインのリアルタイムイベント処理では、1分単位のダウンが直接的な損失につながる。「Service Busは99.9%だから社内規定上採用できない」という判断が覆るケースが出てくるだろう。 Availability Zone冗長化が支える高可用性 Azure Availability Zoneとは、同一リージョン内に存在する物理的に独立したデータセンター群だ。電源・冷却・ネットワークがそれぞれ分離されており、1ゾーンで障害が起きても他のゾーンには影響しない設計になっている。 Service Bus Premiumはこの複数ゾーンにまたがる冗長化を活用し、単一障害点を排除した構成を取る。今回の99.99% SLAはAZ機能が有効なすべてのリージョンで適用される。 Azure Service Bus Premium の主な特徴 StandardとPremiumの2ティアを持つService Busのうち、Premiumが選ばれる理由は可用性だけではない。 専用メッセージングユニット: マルチテナント環境ではなく専用リソースを使用。予測可能なスループットを確保 大規模メッセージ対応: 最大100MBまでのペイロードをサポート VNet統合: プライベートエンドポイントやVNetサービスエンドポイントに対応し、ネットワーク分離を実現 Geo-Disaster Recovery: 別リージョンへのフェイルオーバーをサポート 高スループット: 本番ワークロード向けのパフォーマンス保証 今回のSLA向上は、これらの機能に加えてもう1つの選定理由が追加されたことを意味する。 実務への影響と活用ポイント 既存ユーザーは追加設定不要 見落としてはならない点として、既存のPremiumユーザーはAZ対応リージョンで稼働していれば、追加設定なしで99.99% SLAが自動適用される。移行作業もコスト増もなく信頼性が上がるのは素直にありがたい。 採用を見直す価値があるシステム 以下のようなユースケースでは、今回の変更を機に評価を再検討してほしい。 金融機関の決済・振込メッセージング基盤 ヘルスケア系のアラート・通知パイプライン ECサイトの注文処理・在庫連携フロー 工場・製造現場のリアルタイムイベント処理 StandardからPremiumへの移行ROIを再計算する StandardはPremiumに比べてコストが低いが、99.99% SLAで守られるビジネス価値を加味したROI試算を行う価値がある。特に「障害時の損失コスト × 年間期待ダウンタイム差」で計算すると、多くのミッションクリティカル系システムでPremiumが正当化される。 筆者の見解 SLAの数字を「どうせ大差ない」と流してしまうエンジニアもいるが、エンタープライズ調達の現場では話が違う。要件定義書やベンダー評価シートにSLAの閾値が明記されている案件では、99.9%と99.99%の差が採用の可否を左右することが実際にある。その壁を取り除いたことの意義は小さくない。 Azureのインフラ基盤としての信頼性は引き続き高い。Service Busのような基盤コンポーネントを地道に強化するのは、プラットフォームとしての完成度を高める正しいアプローチだ。華やかなAI系の発表が続く中で、こういった堅実な改善こそが日本の大規模エンタープライズ案件での競争力を支えているという側面もある。 疎結合アーキテクチャへの移行を検討している組織にとって、「メッセージングの土台が99.99%で守られる」という事実は、その設計判断を後押しする材料になる。Event GridやEvent Hubsとの使い分けを再整理しながら、Service Bus Premiumをアーキテクチャの中核に据えるシナリオを検討してみてほしい。 ...

Microsoftは2026年5月1日、AIエージェントのガバナンス基盤「Microsoft Agent 365」を正式リリースした。IT部門の承認なく社員が独自に展開した「シャドーAIエージェント」を発見・可視化・制御するコントロールプレーンとして、月額15ドル/ユーザー（またはM365 E7に同梱）での提供が始まった。 シャドーAIという「加速するシャドーIT」 2026年時点で、ナレッジワーカーの78%が週1回以上AIエージェントを利用しているという。2024年の12%からの急増が示すのは、普及とガバナンスの深刻な乖離だ。 MicrosoftのWork Trend Index 2026は、AIの成果に与える影響の67%が「組織側の要因」であり、個人利用の寄与は32%に過ぎないと指摘している。ツールを渡すのは簡単だが、その後の管理こそが本質的な課題だ。 10年前に企業を悩ませた「シャドーIT」——社員が勝手にDropboxを使い、Slackを未承認導入し、個人SaaSを会社デバイスで使う問題——の2026年版が、さらに速いスピードで進行している。エージェントベースツールが社員のラップトップにインストールされ、ITチケット一枚なしにCRM・人事データベース・財務システムと接続されていく。 未承認のAIエージェントが機密データへの読み取りアクセスを持つリスクは、未承認プロジェクト管理ツールとは次元が違う。そしてAIエージェントの採用曲線は指数関数的に伸びる一方、ガバナンス整備は線形——存在しないケースすら多い——という構造問題が根底にある。 Microsoftのデータでは、AI戦略をトップダウンで明確に定めている組織はわずか25%。残り75%は、エージェントがルールなしに本番環境で動いている状態だ。 Agent 365の実態：3つのコア機能 Agent 365はエージェントビルダーではない。すでに組織内で動いているエージェント——社内開発、ベンダー製、誰かが黙って先週インストールしたものも含め——を統制するためのコントロールプレーンだ。 1. 発見とインベントリ管理 管理センターに専用の「Shadow AI」ページが設けられ、ITの監視外で動くエージェントをエンドポイントスキャンで検出できる。サードパーティ製エージェントツールもマネージドデバイス上で検知し、中央レジストリに登録する。多くの組織がまったく手をつけていない「現状把握」がここから始まる。 2. ID・アクセス管理（Microsoft Entra連携） Agent 365はMicrosoft EntraのIDガバナンスをAIエージェントに拡張する。人間ユーザーに適用してきた最小権限の原則が、エージェント（Non-Human Identities）にも適用される。カスタマーサポートのチケットを読むだけのエージェントが、財務データへのアクセスを持つ必要はない——当たり前の話だが、現実には多くのエージェントが作成者と同等の権限を持ったまま動き続けている。 3. データガバナンス（Microsoft Purview連携） Purviewとの統合により、機密タグが付いたデータへのエージェントアクセスをポリシーで制御できる。これはAIエージェントのセキュリティリスクの中で最も頻発するパターン——広範なアクセス権を持つエージェントが機密データを不適切なコンテキストに引き込む問題——を直接解決する。 2026年6月にパブリックプレビュー予定の追加機能 コンテキストマッピング: エージェントとエンタープライズシステム間のデータフローを可視化 ランタイムブロック: 動作中のエージェントをリアルタイムで停止 実務への影響——日本のIT管理者がやるべきこと 今すぐ確認すべき3点: 社内で稼働中のAIエージェントを棚卸しする — おそらく把握していないものが複数存在する M365ライセンスでAgent 365が含まれるか確認する — E7バンドルか、単体購入（$15/ユーザー/月）かを把握する Entra・Purviewの既存ポリシーをエージェント対応で見直す — NHI（Non-Human Identities）の権限設計を人間アカウントと同等の厳しさで整備する 見落としがちなポイント: 「エージェントを禁止する」アプローチは機能しない。シャドーITへの禁止令が失敗し続けてきたのと同じ理由だ。公式ルートで提供されるものが最も便利に使える環境を作ることが、ガバナンスの唯一の正解に近い。 筆者の見解 シャドーAIの問題は、日本企業にとってシャドーITより遥かに速く、遥かに深く侵食する。セキュリティ分野は細かい議論が多くて得意ではないが、この問題の構造は明快だ。 Agent 365のアプローチが評価できるのは、「禁止」ではなく「管理可能にする」方向性を選んでいる点だ。EntraやPurviewという既存のIDガバナンス基盤をエージェントに横展開する設計は、M365を中心に構築してきた企業には素直なメリットがある。バラバラに使うのではなく統合して使うことで価値が出るプラットフォームとしての一貫性がある。 NHI管理はこれまで「面倒な付帯作業」として後回しにされがちだったが、AIエージェントが業務に深く入り込む以上、これを整備しないと自動化も進まない。業務効率向上の観点でも、今こそ向き合うべきタイミングだ。 月額15ドル/ユーザーのコスト正当化は各社の判断になるが、E7を検討している組織には実質的に含まれる。「何体のエージェントが今どんな権限で動いているかわからない」状態を解消するだけで、セキュリティ監査への備えとしての価値は十分ある。M365の統合プラットフォームとしての本領を、AIエージェントのガバナンス領域でも発揮してほしい。そう期待できる製品だ。 出典: この記事は Microsoft Agent 365: The AI Agent Security Gap Enterprises Can’t Ignore の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年3月9日、MicrosoftはMicrosoft 365 CopilotにAnthropicのClaude Sonnetを統合し、約4億人のOfficeユーザーがAIモデルを用途に応じて選択できるようになった。これまでOpenAIのGPT-4oに固定されていたCopilot Chatが初めてマルチモデル選択に対応した、M365の転換点といえる動きだ。 Wave 3アップデートで何が変わったのか Microsoft 365の「Wave 3」アップデートにより、Copilot ChatのFrontierプログラム参加ユーザーが、モデルセレクターからClaude Sonnetを選択できるようになった。対応プラットフォームはWeb・デスクトップ（Windows/macOS）・モバイルと幅広く、2026年3月末をめどにロールアウトが完了する予定だ。 ただし現時点ではEU/EFTA・英国・政府クラウド・ソブリンクラウド環境は対象外となっており、規制対応を段階的に進める姿勢が見てとれる。グローバル拠点を持つ日本企業のIT担当者は、地域ごとの利用可否を事前に確認しておく必要がある。 技術的な背景として、AnthropicはMicrosoftの「サブプロセッサー」として正式認定済みであり、企業データはMicrosoftのクラウドインフラ内で処理される。データプライバシーの責任主体はMicrosoftとなる構造だ。この統合は、Microsoftが約300億ドル（約4.5兆円）規模のAzureコンピュート契約をAnthropicと締結した戦略的連携の実装フェーズにあたる。 新機能「Copilot Cowork」——自律型エージェントが業務を代行 今回の統合で最も注目すべきは、モデル選択機能そのものより「Copilot Cowork」だ。Anthropicのエージェンティックモデルをベースに構築されており、単純なQ&Aを超えたマルチステップの自律タスク実行を担う。 Coworkを支える仕組みが「Work IQ」と呼ばれるコンテキスト理解エンジンだ。メール・ファイル・ドキュメント・Teams会議・チャットを横断的に取り込み、組織の業務背景を把握した上でタスクを実行する。具体的には以下のような複合ワークフローを、単一の指示で処理できる： Teams会議録から要点を抽出→Wordで議事録ドラフト→PowerPointで報告資料を自動生成 Excelの複数ブックにまたがるデータを統合・集計→条件付き計算を適用→経営層向けサマリーを出力 四半期レビュー用資料の作成において、売上データ・会議メモ・過去資料を横断参照しながら一貫した分析レポートを組み立てる 現時点では一部顧客向けのリサーチプレビューであり、Frontierプログラムを通じて2026年3月末以降に順次公開される予定だ。 日本のIT現場への影響 モデル使い分けの実践設計 Word・Excel・PowerPointでの定型業務はCopilotの既存機能で対応できるが、長文ドキュメントの整合性チェックや複雑な分析・要約にはClaude Sonnetが強みを発揮しやすい場面がある。ただし、モデルが増えるほど「どの業務にどのモデルを使うか」という設計が組織内で必要になる。現場に丸投げすると「デフォルトのまま使う」状態に陥りやすいため、利用ガイドラインの整備をIT部門が主導することが望ましい。 データガバナンスの再確認 Anthropicがサブプロセッサー認定されているとはいえ、情報セキュリティ部門・コンプライアンス担当者は自社のデータ取り扱いポリシーとの整合を確認する作業が発生する。機密度の高い文書を扱う場合は、どのモデルにデータが渡るかを明示したポリシーを先行して整備したい。 エージェント活用の事前準備 Copilot Coworkが正式公開されれば、定期的に発生するレポート作成・資料整理・データ集計の自動化が現実的な選択肢になる。今のうちから自部門の定型業務フローを棚卸しし、エージェントに委ねやすい候補を洗い出しておくことが、早期活用の近道だ。 筆者の見解 「Copilotは1モデルに縛られる」という制約が今回の統合で緩和されたことは、率直に評価できる動きだと思う。単一ベンダーのモデルだけでなく、用途に応じて選択できる環境を整えることは、エンタープライズAI活用の成熟度を上げる正しい方向性だ。 Copilot Coworkのようなエージェント機能は、M365の本来の強みである「統合プラットフォームとしての価値」を最大化する方向に動いている。Teamsで話し、Outlookでメールし、Wordで書き、Excelで分析する——その全体をシームレスにつなぐ存在としてエージェントが機能するなら、Microsoft 365の競争力は改めて際立つはずだ。Microsoftにはこのポテンシャルを生かせる力がある。 あとは「使い分けの設計」をどうユーザーに届けるかだ。モデルが増えるほど、現場は選択肢の多さに戸惑う。Microsoftには、マルチモデル環境をユーザーが自然に使いこなせるUX設計と、IT管理者がポリシーを整備しやすい管理ツールの充実に、引き続き注力してほしい。機能の豊かさを使いやすさに変換できれば、このアップデートの意義は大きく跳ね上がる。 出典: この記事は Microsoft 365 Copilot Now Runs Claude Sonnet: How 400 Million Office Users Got Access to Anthropic’s AI — Enterprise Integration Deep Dive の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが SharePoint Online に新たな分析機能「AI citations analytics（AI引用分析）」を追加した。Microsoft 365 Copilot や各種AIエージェントがどの文書・ページを参照したかを可視化できるようになり、サイトオーナーやコンテンツ管理者がAI活用状況をデータで把握できる。2026年5月中旬までに全世界へのロールアウトが完了予定だ。 AI引用分析とは何か AI引用分析とは、Microsoft 365 Copilot や各種AIエージェントが SharePoint 上のコンテンツを参照（引用）した回数を集計・表示する機能だ。 従来の SharePoint サイト統計には「閲覧数（Views）」「閲覧ユーザー数（Viewers）」といった指標しかなかったが、今回の更新でAI起点のアクセスも計測対象となる。 追加される機能は大きく3つある。 1. サイト利用統計への「AI引用ランキング」 「Popular content（人気コンテンツ）」セクションに、Copilot や AIエージェントに最も多く参照された文書・ニュース投稿・ページのランキングが表示される。 2. ページ分析への「Total citations」カード 個別ページやニュース投稿の分析画面に、そのページが Copilot やエージェントの回答で何回引用されたかを示す「Total citations」カードが追加される。 3. 新設の「AI citations analytics」ページ サイト利用統計の配下に独立した分析ページが新設され、以下の情報を確認できる。 Copilot・AIエージェント経由でサイトコンテンツを利用したユーザー数 サイト全体の総引用数 最も引用回数の多い文書・ニュース投稿・ページ一覧 対応エージェントは Microsoft 365 Copilot をはじめ、Word・Excel・PowerPoint・Teams・Loop・Planner 内の Copilot、SharePoint Knowledge Agent、SharePoint カスタムエージェントと幅広い。 前提条件と管理者対応 この機能を利用するには Microsoft Copilot ライセンス が必要。管理者による設定変更は不要で、有効化はデフォルトで行われる（ロードマップID: 480725）。 実務への影響 コンテンツ管理担当者・サイトオーナー 「この文書、本当に使われているの？」という問いに対して、これまでは人間の閲覧数だけが根拠だった。しかしAIエージェントが回答生成に使う文書は、必ずしも人間がよく見るページと一致しない。 AI引用分析が入ることで、「人間にはあまり閲覧されていないが、AIが頻繁に参照している重要文書」が浮かび上がる。情報の鮮度管理や更新優先度の判断材料として活用できる。 ガバナンス・情報管理担当者 「SharePointに上げた文書がCopilotの回答にどう使われているか」を組織として把握する手段が生まれる。機密レベルの高い文書が意図せず広く引用されていないか確認するトリガーとしても使える。アクセス権ポリシーの見直し契機として活用できるだろう。 Copilot 導入推進担当者 CopilotのROI（投資対効果）を問われた際に、「何人がCopilot経由でサイトコンテンツにアクセスしたか」という具体的な数字が使えるようになる。経営層への報告資料にも組み込みやすいデータだ。 筆者の見解 AI引用分析は、Copilot活用が一定程度進んだ組織にとっては実用価値の高い機能だと思う。「AIが参照しやすい文書を整備する」という新しい視点でコンテンツ管理ができる点は面白い発想だ。 一方で率直に言えば、この機能が真に役立つためには「Copilotがまともに動いていること」が前提になる。Copilotライセンスの費用対効果にまだ確信を持てていない組織では、分析データを見る前の段階で議論が詰まっているはずだ。 ...

Pure Rustで書かれたAIコーディングエージェント「Zerostack」がバージョン1.0.0としてcrates.ioで公開され、Hacker Newsで522ポイント・287コメントという高い注目を集めた。 Zerostackとは何か Zerostackは、Unix哲学を設計指針に据えた新世代のAIコーディングエージェントだ。言語にRustを選択し、Pythonランタイムや Node.js環境への依存を排除した「Pure Rust」実装が最大の特徴となっている。 バージョン番号が「1.0.0」であることは象徴的だ。多くのAIツールがプレビューやベータを繰り返す中、セマンティックバージョニングに従って安定版を宣言するという姿勢は、システムソフトウェアとしての成熟度を示すシグナルとなる。 Unix哲学をAIエージェントに持ち込む意味 Unix哲学の核心は「一つのことをうまくやれ、そしてつなげろ」という思想だ。Zerostackはこれをコーディングエージェントに適用する。 具体的には以下のような設計思想が反映されている： 標準入出力ベースのインターフェース — シェルのパイプラインと組み合わせて使える コンポーザビリティ — 既存のUnixツール群（grep、sed、jq、gitなど）とシームレスに連携 モジュール型設計 — 機能を小さな単位に分割し、組み合わせて使う シングルバイナリ配布 — Rustの強みを活かし、依存関係なしで動作する単一の実行ファイル PythonベースのAIツールに慣れている開発者には、この「インストールして即使える」体験は新鮮に映るはずだ。pip installや仮想環境の設定が不要で、cargo install zerostackの一行で環境が整う。 Rustで実装することの技術的優位性 AIコーディングエージェントをRustで実装することには複数のメリットがある。 起動時間の短さ: Pythonベースのツールは初期化に数百ミリ秒かかるケースがある。RustバイナリはOSレベルで即座に起動するため、CI/CDパイプラインやシェルスクリプトへの組み込みがしやすい。 メモリ安全性: ガベージコレクターなしでメモリ安全を保証するRustの設計は、長時間動作するエージェントプロセスにとって重要だ。メモリリークが起きにくい設計は、自律ループで連続実行するシナリオで特に効いてくる。 クロスプラットフォーム対応: Linux・macOS・Windowsで同一のコードベースが動作する。特にWindowsのWSL2環境での動作も期待しやすい。 実務への影響 — 日本のエンジニアにとっての意味 DevContainerやCI環境への組み込み：シングルバイナリかつUnix標準IOに準拠しているため、Dockerイメージへの組み込みが容易だ。apt installやpip installより格段に軽量な構成でAIエージェント機能をCI環境に持ち込める可能性がある。 シェルスクリプトとの統合：git log | zerostack summarizeのようなパイプラインが成立するなら、既存の自動化スクリプトにAI機能を後から差し込む改修コストが低い。レガシーなBashスクリプト群に段階的にAI機能を追加するアプローチが現実的になる。 セキュリティ審査の通りやすさ：日本の大手SIerや金融機関では、Python/Node.jsランタイムの持ち込みに慎重なケースがある。静的リンクされたRustバイナリは依存関係が少なく、セキュリティ審査の観点でメリットが生じる場面もある。 Rustエンジニア採用文脈での訴求：Rustが書ける人材を採用・育成しようとしている組織にとって、エコシステムが充実していることを示す事例として紹介しやすい。 筆者の見解 Hacker Newsで500点を超えるスコアは、テクニカルコミュニティが「Pythonに依存しないAIツール」に強い需要を感じていることの表れだと見ている。AIコーディングエージェントの多くは「まずPython環境を用意してください」から始まる。それ自体は悪くないが、Unix的な思想で育ってきた開発者にとって、その前提への違和感は根強い。 Zerostackが採ったアプローチ——シングルバイナリ、パイプライン、コンポーザビリティ——は、AIエージェントを「アプリケーション」ではなく「道具」として位置づける思想だ。この方向性はシステム系エンジニアの直感と合致しやすく、採用のハードルを下げる効果がある。 一方で、コーディングエージェントとして実際にどの程度の精度・実用性があるかは、LLMとの統合方式やプロンプト設計に大きく依存する。設計哲学の良さと実際の使い心地は別物であり、v1.0.0リリース直後の段階では、実務投入には一定の検証期間を置くのが賢明だろう。 「AIエージェントをシェルの一部として使う」という未来は確実に来る。Zerostackがそのエコシステムの一角を担うか、それとも類似ツールに吸収されていくか——Hacker Newsの反響の大きさは、少なくとも問題設定が正しいことを示している。Rustコミュニティの活発さを考えると、このアプローチを採るプロジェクトが今後さらに増えてくるだろう。 出典: この記事は Zerostack – A Unix-inspired coding agent written in pure Rust の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティ研究者「Chaotic Eclipse」が、Windowsの権限昇格ゼロデイ脆弱性「MiniPlasma」の概念実証（PoC）コードをGitHubで公開した。2026年5月のPatch Tuesdayを適用した完全パッチ済みのWindows 11 Pro環境でも動作が確認されており、標準ユーザー権限からSYSTEM権限への昇格が可能になる深刻な問題だ。 何が問題なのか MiniPlasmaが悪用するのは、Windowsの cldflt.sys（Cloud Filter ドライバー）に含まれる HsmOsBlockPlaceholderAccess ルーティンの不具合だ。このドライバーはOneDriveのオンデマンド同期など、クラウドストレージのプレースホルダー管理に使われているコンポーネントである。 具体的には、ドキュメント化されていない CfAbortHydration APIを通じたレジストリキーの生成処理に問題がある。適切なアクセスチェックなしに .DEFAULT ユーザーハイブ配下へ任意のレジストリキーを書き込める状態になっており、これを足がかりに権限昇格が実現する。 BleepingComputerの検証では、標準ユーザーとしてexeを実行するだけで、SYSTEM権限のコマンドプロンプトが開いたことが確認されている。 「修正済み」のはずが、なぜ今？ 実はこの脆弱性は新発見ではない。2020年9月、Google Project ZeroのJames Forshaw氏がMicrosoftに報告し、CVE-2020-17103として同年12月のPatch Tuesdayで修正済みとアナウンスされていた。 Chaotic Eclipse氏が再調査したところ、「パッチが当たっていない状態と同一の問題がそのまま残っていた」という。Forshaw氏が当時公開したオリジナルのPoCコードが修正なしで動作したと述べており、パッチが最初から機能していなかったのか、あるいは何らかの理由でサイレントにロールバックされたのかは不明としている。 Microsoftは本件について現時点でコメントを出していない。 Insider Preview Canaryでは動作しない 脆弱性アナリストのWill Dormann氏が独立した検証を行い、最新の公開版Windows 11では再現を確認した一方、Windows 11 Insider Preview Canaryビルドでは動作しないことも確認している。これはMicrosoftがCanaryチャンネルで何らかの対応を進めている可能性を示唆しており、正式なパッチが近い将来リリースされることへの期待材料となっている。 連続ゼロデイ公開の背景 MiniPlasmaはChaotic Eclipse氏による一連のゼロデイ公開の最新版だ。過去数週間で以下の脆弱性・ツールが公開されており、そのすべてが実際の攻撃への悪用が確認されている： 名称 概要 BlueHammer（CVE-2026-33825） Windowsローカル権限昇格 RedSun 権限昇格（CVE未採番でサイレント修正） UnDefend Windows Defender サービス妨害ツール YellowKey BitLockerバイパス（TPM-only構成に影響） GreenPlasma 権限昇格 Chaotic Eclipse氏はこれらの公開が「Microsoftのバグバウンティおよび脆弱性対応プロセスへの抗議」であると表明しており、Microsoftから個人的な脅迫を受けたと主張している。脆弱性開示の経緯として異例であることは確かだが、公開されたPoCが悪用されているという事実は変わらない。 日本のIT現場への影響 権限昇格の脆弱性は、それ単体では侵入の入口にはならない。しかし「初期侵害 → 権限昇格 → ラテラルムーブメント」という典型的な攻撃チェーンの中間ステップとして極めて有効であり、標準ユーザー権限でフィッシングマルウェアが実行された後の被害拡大を一気に加速させる。 特に日本企業では「一般ユーザーには管理者権限を与えていない」をセキュリティ対策として強調するケースが多い。しかしこの脆弱性が悪用されると、その境界線を突破できてしまうため、過信は禁物だ。 当面の対応指針： エンドポイントEDR・XDRの検知ルールを確認する — 権限昇格の挙動（標準ユーザープロセスからのSYSTEM権限プロセス生成）を検知できる構成になっているか見直す Windows Insider Preview Canaryでの修正を注視する — Canaryで動作しないことが確認されているため、公式パッチのリリースタイミングをMicrosoft Security Response Center（MSRC）で確認し、リリース次第優先適用する 最小権限の徹底を再確認する — 権限昇格脆弱性の被害を限定するうえで、日常業務における不要な権限の棚卸しは依然として有効な対策 BitLocker設定の見直し — YellowKeyとの組み合わせを考慮し、TPM-onlyのBitLocker構成を使っている端末はPINやネットワークアンロックの追加を検討する 筆者の見解 セキュリティネタは正直あまり好きなジャンルではないのだが、今回の件はWindowsを追う立場として看過できない。 ...

Linuxカーネルの生みの親Linus Torvaldsが、AIツールを使った質の低いバグレポートが急増しセキュリティチームを圧迫していると強く非難し、「ドライブバイコントリビューター（駆け込み貢献者）」に対して大きな変革を要求した。 AI生成バグレポートの洪水が開発を麻痺させる Linuxカーネル開発において、AIツールを活用した低品質なバグレポートが大量に流入し、セキュリティチームが限界に近づいている。Torvaldsはこの状況を深刻な問題として公式に取り上げ、強い言葉で改善を求めた。 かつてバグレポートを提出するためには、コードを深く読み込み、再現手順を確認し、環境情報を整理するという「コスト」があった。そのコストが貢献の品質を担保する自然なフィルターとして機能していた。しかしAIツールの登場により、コードを精読しなくても「それらしいレポート」を量産できる環境が生まれてしまった。 何が問題なのか AI生成バグレポートの主な問題点は以下の通りだ： 偽陽性の急増: 実際には存在しない問題を「バグ」として報告するケースが多発 文脈の無視: コードのロジックや設計意図を理解しない表面的なスキャン結果をそのまま提出 判断不能なレポート: レビュワーが読んでも実害の有無を判断できない低品質な内容 こうしたノイズが大量に流入することで、信号対雑音比（SNR）が下がり、本当に重要な脆弱性が埋もれるリスクが高まる。セキュリティチームのレビュー負荷は激増し、開発のスループット自体が落ちる悪循環に陥る。 ドライブバイコントリビューターとAIの組み合わせが生む構造問題 オープンソースコミュニティには「一度だけ貢献して去っていく」参加者が常に存在する。本来は健全な貢献の形のひとつだ。しかしAIツールがその参入コストをほぼゼロにしたことで、量的・質的なバランスが崩れた。 本物のセキュリティ研究者がコードを深く読み込んで提出するレポートと、AIがコード表面を自動スキャンして生成したレポートは、見た目は似ていても質は天と地ほど異なる。レビュワーはその差を見分けるためにさらに時間を割かなければならない。 実務への影響——日本のエンジニア・IT管理者が注視すべきこと エンタープライズ環境でLinuxを運用する日本のIT管理者にとって、この問題は対岸の火事ではない。 CVEの信頼性低下リスク: AI生成レポートが増えることで、脆弱性情報（CVE）の精度が下がる可能性がある。「CVEが出たから即パッチ」という判断にノイズが混じり込む パッチ優先順位の判断コスト増大: ノイズが多い中で本物のリスクを見極める作業が増え、セキュリティ担当者の工数が増加する パッチリリースの遅延懸念: レビューチームの疲弊は、正式なパッチリリースまでのリードタイムを延ばしかねない Linuxセキュリティアドバイザリの動向を、今後は例年以上に注視する必要があるだろう。 筆者の見解 AIがコードを「それらしく読める」ようになったことで参入コストが下がり、貢献者層が広がるのは本来歓迎すべき変化だ。しかしTorvaldsが声を上げているのは、「量が質を駆逐している」という本質的な問題があるからだ。 AIツールを使うことと、AIの出力を検証せずそのまま流すこととの間には、大きな差がある。生成結果を人間がレビューせず提出するのは、責任を放棄しているに等しい。ツールの出力は「下書き」であり「完成品」ではないという認識が、利用者側に求められる。 この問題はLinuxカーネルに限らない。GitHubやGitLabを使うあらゆるOSSプロジェクトで起きうる構造的な課題であり、今後はバグレポート提出プロセスへの「人間の関与を担保する仕組み」の整備が議論になるだろう。AI活用のルールを早期に設計しないと、オープンソース開発の文化そのものが変質するリスクがある。 AIを「量産ツール」として扱うのではなく、「思考を補助するツール」として使いこなす——その使い手としての成熟が、今まさに問われている。 出典: この記事は Linus Torvalds slams AI-generated bug reports for breaking Linux kernel development の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teamsのビデオ会議機能「Together Mode（トゥギャザーモード）」が廃止されることが明らかになった。The Verge のウィークエンドエディター Terrence O’Brien 氏が2026年5月17日に報じた。 Together Mode とはどんな機能だったのか Together Mode は、新型コロナウイルスのパンデミックが本格化した2020年にMicrosoftがTeamsに追加したビデオ会議機能だ。AIを用いて参加者の頭部と肩をリアルタイムで切り抜き、全員が同一の仮想空間（カフェ、講堂、会議室など選択可能なシーン）に集まっているように見せるという演出機能である。 「自宅でパンツもはかずに座っているのに、同じ会議室にいるような雰囲気を演出できる」——The Verge の記事はこの機能をそう表現している。肩を叩いたりバーチャルハイタッチをする演出も備えており、リモートワーク期の孤立感を和らげるチームビルディングツールとして活用する企業も一定数あった。 なぜ今廃止されるのか Microsoftが挙げる廃止理由は主に3点だ。 1. プラットフォーム間のフラグメンテーション削減 デスクトップ・モバイル・Webと複数環境にまたがる機能の一貫性を高めるため、共通化できない機能を整理する。 2. インターフェースの簡素化 クリック数を減らし、選択肢による混乱を省いたシンプルなUIへ移行する。 3. 動画品質・安定性・パフォーマンスへの集中 Together Mode に割いていた開発リソースを、会議の基本品質向上に再投資する。 The Verge の報道によれば、廃止は段階的に展開される。対象ユーザーのTeamsのビューメニューから「Together Mode」のトグルが順次消え、シーン選択や座席割り当てといったTogether Mode 固有の機能も同時に廃止される予定だという。 海外レビューのポイント The Verge の Terrence O’Brien 氏は、今回の廃止についてMicrosoftが「ギミックではなく動画品質とパフォーマンスの改善に注力したい」という明確な意図を示した点を強調している。 O’Brien 氏の評価では、Together Mode は「視覚的な散漫さを抑える効果は確かにあった」としながらも、「ギミック感が否めない機能でもあった」と指摘。パンデミック期には一定の需要と話題性があったものの、現在のリモートワーク環境では演出よりも映像・音声の安定性が優先されるという市場の変化が廃止の背景にあると読み解いている。 日本市場での注目点 日本においてTeamsは、大手企業から中小企業、教育機関まで広く導入されているビデオ会議プラットフォームだ。M365との統合という強みを軸に、法人市場では圧倒的なシェアを持っている。 Together Mode を研修・授業・オンラインイベントに活用していた組織は代替手法の検討が必要になるが、日本企業の多くはTogether Mode をあまり常用していなかったとみられ、実務への影響は限定的だろう。 むしろ注目すべきは、廃止によって浮いた開発リソースが動画品質・安定性の改善に向かう点だ。大規模会議や長時間会議における映像の乱れや接続の不安定さは日本の法人ユーザーが長年抱えてきた課題であり、ここへの投資集中は歓迎される可能性が高い。 筆者の見解 Together Mode はパンデミックという特殊な時代に生まれた、時代なりのアイデアだったと思う。全員がバラバラの場所にいながら「同じ空間にいる」という感覚を演出しようとした発想は面白かったし、当時の需要に応えるものでもあった。 廃止の理由のひとつに「プラットフォーム間のフラグメンテーション削減」が挙げられている点は少し気になる。一度作った機能を磨いて一貫性を持たせるのではなく、廃止で対応するという判断だからだ。TeamsにはM365との深い統合というZoomやGoogle Meetにはない強みがある。その強みを活かした会議体験の差別化という観点からすれば、もう少し磨き込んでほしかったという気持ちも正直ある。 とはいえ、動画品質・安定性の向上に注力するという方向性自体は正しい。基本が強ければ、その上に何でも乗せられる。Together Mode の終幕が、Teamsが本来持っている実力を正面から発揮するための転換点になることを期待したい。 出典: この記事は Microsoft is retiring Teams’ Together Mode の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

IntelとAMDが中心となって設立したx86 Ecosystem Advisory Group（EAG）は2026年4月27日（米国時間）、AI向け行列演算拡張命令「AI Compute Extensions (ACE) for x86」に関するホワイトペーパーをリリースした。PC Watchの大原雄介氏がその技術的詳細を解説しており、長らく概要しか明かされていなかったACEの設計思想が初めて明確になった。 なぜACEが注目されるのか ACEは、EAGが2025年10月に標準化すると発表した4命令群（FRED／AVX10／ChkTag／ACE）の中で、唯一詳細が伏せられていた最後のピースだ。「ノートPCからデータセンターサーバーまで、あらゆるx86デバイスで統一された行列演算を実現する」という目標を掲げており、特定ベンダーのGPUアクセラレーターなしでもCPU単体でAI推論を効率的に処理できる基盤を整えることを狙う。EAGにはAdobeとNutanixが新たに加入し、現在12社＋アドバイザー2名の体制となっている。 海外解説のポイント——「外積」採用が最大の特徴 PC Watchの大原氏の解説によると、ACE最大の技術的特徴は積和演算（FMA）ではなく外積（Outer Product）ベースの演算アーキテクチャを採用している点だという。 NVIDIA GPUのTensor Core、IntelのAMX（Advanced Matrix Extensions）、ArmのSME/SME2といった主要なAI行列演算ユニットはいずれも積和演算ベースだ。GEMMの高速化に積和演算が効率的であるうえ、回路もコンパクトに収まるためだ。 これに対しACEが採用する外積演算の先例としては、IBMのPOWER10に搭載されたMMA（Matrix Math Assist）がある。大原氏の解説によれば、積和演算ユニットで外積を計算しようとすると「積和演算→外積変換」の余分な処理ステップが発生するのに対し、外積アクセラレーターを用いると直接処理できる分だけ高速化が見込めるという。 演算構造の概要 ACEはAVX512用の512bitレジスタ（ZMMレジスタ）を活用して外積を計算する。 8bit入力時: 1つのZMMレジスタに16×4の64値を格納し、1回の外積演算で乗算換算1,024回分の処理を実行 16bit入力時: 8×4の32値を格納 演算結果の格納のためにSub Tile Register（サブタイルレジスタ）という新レジスタ群が追加される。512bitレジスタ2個を1セットとした8組（合計16個）が用意される設計だ。 現時点での留意点 今回はあくまでホワイトペーパーの段階であり、具体的な命令仕様は未公開だ。たとえば「積和演算のみが必要な場合のオプションがあるか」といった実装上の詳細は明らかになっていない。関連するAVX10.2については、IntelのDiamond RapidsおよびNova Lakeが最初の対応製品になると見られているが、現時点では未実装だ。 日本市場での注目点 ACEはまだ仕様策定段階であり、消費者向け製品への搭載は先の話だ。ただし以下の観点で注目に値する。 企業・データセンター向け: CPUでの推論効率が上がれば、クラウドGPUコストへの依存を下げる選択肢が広がる 開発者向け: ACEが普及すれば、特定ハードウェア依存なしにx86環境でAI推論を最適化するコードが書けるようになる 競合との位置づけ: NVIDIA Tensor CoreやApple Neural Engineに対し、x86 CPUでの推論効率底上げを狙う標準化の動きとして、今後の進展を追いたい 筆者の見解 ACEで注目するのは、外積演算という設計選択がどこまで実ワークロードで優位性を発揮するかという点だ。理論上は積和演算からの変換ステップを省ける分だけ効率的だが、実際のモデル推論でのゲインは実装の品質次第でもある。まずはホワイトペーパーから正式な仕様公開、そして実装済みシリコンへ——というロードマップが見えてきたら、改めて評価できる材料が揃う。 「ノートPCからデータセンターまで同一命令」という思想自体は筋がいい。特定のアクセラレーターがなければAIが動かないという前提は、システム設計の制約になりやすく、x86 CPUである程度の推論が回せるようになれば選択肢の幅が実質的に広がる。現時点でAI推論の最適化を急ぐのであれば既存のGPU・NPUで対応しつつ、ACEの仕様公開と実チップへの搭載を辛抱強く待つのが現実的な判断だろう。 出典: この記事は 【大原雄介の半導体業界こぼれ話】IntelとAMD主導のx86向けAI拡張命令「ACE」、その詳細が判明 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

PC Watchのコラム「福田昭のセミコン業界最前線」で、福田昭氏が現地ベルギー・ルーベンから「2026 IEEE 18th International Memory Workshop（IMW 2026）」の詳細レポートを届けた。今回の学会で浮き彫りになったのは、単純な積層技術だけでは今後のDRAMやNANDの大容量化が困難という、業界に共通する認識だ。 なぜ今、メモリ技術が注目されるのか AIの急速な普及が、メモリサブシステムへの要求を根本から塗り替えつつある。PC Watchの福田氏が伝えるMicron TechnologyのNirmal Ramaswamy氏の基調講演によると、AIプロセッサの性能は2年で3倍のペースで向上しているのに対し、メモリアクセスの帯域幅は2年で2倍のペースでしか伸びていない。この「メモリギャップ」は特にGPUで深刻となっており、AIシステム全体の性能を制限する「メモリボトルネック」として業界全体の共通課題となっている。 IMW 2026のポイント：過去最多の投稿、次世代メモリが最大分野に 福田氏のレポートによると、今回の投稿論文数は127件と過去最多を記録した（前年71件から約79%増）。口頭講演の採択率はわずか17%と過去最低水準で、研究競争の激化が際立っている。 分野別では「次世代メモリ（強誘電体メモリ・抵抗変化メモリ・磁気メモリ等）」が24%で最大分野となり前年比3ポイント上昇。続いて「フラッシュメモリ」が20%、「DRAM」が18%を占める。地域別ではアジアが58%でトップ、欧州が30%と続き、米国は11%にとどまった。 現状の打開策HBMと、その先にある3D DRAM Micronの講演が示す現状の打開策がHBM（High Bandwidth Memory）だ。きわめて高い帯域幅を実現するHBMは、ハイエンドAIシステムにおけるGPU向け主記憶として不可欠な存在となっている。 より長期的な解決策として研究が加速しているのが3次元DRAM（3D DRAM）技術だ。1T1C（1トランジスタ＋1キャパシタ）メモリセルを垂直方向に積み重ねることで記憶密度を高める方式で、福田氏のレポートによるとMicronはシリコン（Si）とシリコンゲルマニウム（SiGe）を交互に重ねた超格子構造の実現可能性を示した。ただし3D DRAMの実現には、メモリセルアレイと周辺回路を異なるウェハに形成して接合するという複雑なプロセスが不可欠であり、量産化への道のりはまだ遠い。 NANDフラッシュ側では、Samsung ElectronicsのChris Kang氏が技術展望を講演した。こちらも単純な積層では容量拡大に限界が生じているという認識が示されており、次世代へのアーキテクチャ刷新が避けられない段階に来ている。 なお、中国のCXMT（ChangXin Memory Technologies）のRobert Liu氏がDRAM技術展望の基調講演に登壇した点も注目される。Micron・Samsungと並ぶ場での発表は、地政学的な観点からも意味を持つ。 日本市場での注目点 HBMはすでにNVIDIAのH100・H200・B200系GPUに搭載されており、国内クラウドサービスやAI基盤の整備コストに直結する。AIサーバーの調達・設計において、メモリ帯域幅の制約を正確に把握した上での選定が求められる時代になっている。 日本の半導体産業の観点では、Rapidusをはじめとするプレイヤーがこのメモリ技術トレンドの文脈でどのポジションを狙うかが問われる。IMW 2026のような国際学会で示される技術ロードマップは、今後数年の投資判断や人材育成の方向性に直結する情報だ。 筆者の見解 AIエージェントが自律的にタスクをこなし続けるためには、膨大なデータを高速に読み書きするメモリ性能が欠かせない。「メモリギャップ」という表現が業界の共通語として定着しつつある現状は、AIシステムの性能向上がすでにプロセッサの問題ではなくメモリの問題になっていることを端的に示している。 IMW 2026への投稿論文が過去最多となった事実は、業界全体がこの問題の深刻さを直視し始めた証左だろう。3D DRAMや次世代不揮発性メモリへの研究投資が加速する一方、現実のAIシステムを今支えているのはHBMという構図だ。HBMの動向と3D DRAMの実用化タイムラインは、今後のAIインフラ計画において必ず押さえておくべきポイントといえる。 日本のエンジニア・企業にとって、メモリボトルネックへの理解はもはや「半導体専門家の話」では済まない。AIシステムの選定・コスト設計・将来ロードマップに直接響いてくる話として、業種を問わず注目しておく価値がある。 出典: この記事は 【福田昭のセミコン業界最前線】単純な積層だけでは、もうDRAMやNANDの容量が拡大しない。次世代メモリの課題 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

PC Watchが2026年5月18日に報じたところによると、5月19日発売予定のオープンワールドレーシングゲーム「Forza Horizon 6」が、初回起動時のシェーダーコンパイルをスキップできる「Advanced Shader Delivery」に対応した。AMD製GPUを搭載するWindows 11 PCとXbox Insiderプログラムの組み合わせで、起動時間が約1分半から約4秒へと劇的に短縮されるという。 シェーダーコンパイルとは——PCゲーミングの長年の課題 シェーダーコンパイルとは、GPU上で映像描画を行うプログラム（シェーダー）を、実行時にGPUアーキテクチャ向けにコンパイルする処理だ。PS5やXbox Series Xといったコンソールと異なり、PC上のGPUは多種多様なアーキテクチャが混在するため、事前配布したコンパイル済みシェーダーがそのまま使えない。結果として、初回起動時や場面によってはゲームプレイ中にリアルタイムでコンパイルが走る。 この「ジャストインタイムコンパイル」が引き起こす問題は2つある。1つは初回起動時の長い待ち時間（数分に及ぶこともある）、もう1つはゲームプレイ中のカクつき（シェーダーコンパイルスタッター）だ。後者は特に、せっかくのゲーム体験を著しく損なう。 Advanced Shader Deliveryの仕組みと効果 MicrosoftのAdvanced Shader Deliveryは、この問題を根本から解決するアプローチを取る。仕組みはシンプルで、ゲーム本編と一緒にコンパイル済みシェーダーを配信するというものだ。GPU側でのリアルタイムコンパイルが不要になることで、起動ロード時間を最大90%短縮できるほか、プレイ中のカクつきも低減される。 PC Watchの報道によれば、Microsoftは5月15日に、これまでROG Xbox Allyシリーズに限定してきたAdvanced Shader Deliveryのパブリックプレビューを、AMD製ディスクリートGPU・統合GPU搭載のWindows 11 PCに拡大すると発表。Forza Horizon 6での発売日サポートも同時に実現している。 利用要件 項目 要件 OS Windows 11 バージョン24H2以降 GPU RDNA 3/3.5/4ベースのAMD製GPU GPUドライバー Radeon Adrenalin 26.5.2以降 Xbox Gaming Services バージョン37.113.11003.0以降 Xbox Insider Hub PC Gaming Previewを選択 実測値 PC Watchの記事では、Ryzen 7 5800 + Radeon RX 7600構成での実測が紹介されている。通常約1分半かかっていた起動時間が約4秒にまで短縮。Advanced Shader Deliveryが有効になっている場合、起動ウィンドウに「プリコンパイル済みシェーダーがインストールされました」と表示される。 日本市場での注目点 Forza Horizon 6は5月19日に国内でも発売（Xbox Game Pass加入者はPlay Dayから利用可能）。Advanced Shader Deliveryの利用にはXbox Insiderへの参加が必要だが、PC Gaming Previewへの登録は無料だ。 ...

マサチューセッツ工科大学（MIT）の研究チームが、大規模言語モデル（LLM）のトレーニング効率を70〜210%改善できる新手法「TLT（Training with Learning Trajectories）」を発表した。学習精度を落とさずに計算コストを大幅に削減できるとされ、AI開発の経済性を根本から変える可能性を持つ研究として注目されている。 TLTとは何か——「学習の軌跡」を活用する新発想 TLTは、モデルがトレーニング中にたどる「学習の軌跡（Learning Trajectory）」を明示的に追跡・活用するアプローチだ。 従来のLLMトレーニングでは、膨大なデータを均一にモデルに与え続けることが基本だった。この方式は実装がシンプルな反面、すでに十分に学習できている知識や、現在のモデルの能力に対して難易度が合っていないサンプルにも同じ計算リソースを費やしてしまう非効率さを抱えていた。 TLTはこの問題を解決するために、モデルが「今どの段階にいるか」「どの方向に学習が進んでいるか」を動的に把握し、次に与えるべきデータや学習量を適応的に調整する。人間の教育に例えるなら、「理解できていることを何度も繰り返す」のではなく、「いまの理解度に合った問題を選んで出す」家庭教師のようなアプローチだ。 この工夫により、同じ精度のモデルをより少ないステップ・より少ない計算で達成できるとMITは主張している。 70〜210%という数字の意味 「効率70〜210%改善」という数値は、条件によって振れ幅が大きい。モデルのアーキテクチャ、タスクの種類、データセットの特性によって効果の大きさが変わるためだ。 ただし保守的に見ても70%の改善は無視できない。現状、GPT-4クラスのモデルを1回トレーニングするには数百万ドル規模のコストがかかるとされており、その70%削減は金額にすると数億円単位の節約を意味する。最良条件での210%改善が広く実現できるなら、今まで大企業・国家機関にしか手が届かなかった大規模モデル開発が、より小規模な研究機関やスタートアップにも現実的な選択肢となる。 なぜこれが重要か——日本のIT現場への影響 日本においてLLM開発はまだ一部の大手企業や国立研究機関に限られているが、TLTのような効率化技術が普及すれば状況は変わりうる。 直接的にモデル開発を行わない企業にとっても影響は他人事ではない。学習コストが下がれば、ファインチューニング（特定業務向けのモデル調整）のコストも下がる。自社データでモデルを調整することが今より気軽にできるようになれば、カスタムAIの内製化が加速する可能性がある。 また、クラウドAIサービスを提供するAzure OpenAI ServiceやAmazon Bedrockなどのプラットフォームも、バックエンドのモデル更新コストが下がれば価格競争力が上がる。エンドユーザーにとっては間接的にAPIコストの低下として恩恵を受けることになる。 実務への活用ポイント 現時点でTLTは研究論文の段階であり、実装を今すぐ業務に取り込めるわけではない。しかし、エンジニアやIT管理者が今から意識しておくべき点はある。 ファインチューニングコストの再評価タイミングを見極める: TLTが主要なMLフレームワーク（PyTorch、JAXなど）に取り込まれるまでには時間がかかる。ただし、2〜3年以内には業界全体のトレーニングコスト感覚が変わる可能性が高い。現在「コストが高すぎてできない」と諦めているモデル調整の計画を、今から温めておく価値がある。 カリキュラム学習・動的データ選択の概念を理解しておく: TLTはカリキュラム学習（難易度を段階的に上げる学習設計）の流れを汲む。この考え方はすでにHugging FaceのTrainerなど既存ツールでも部分的にサポートされており、今すぐ試せる類似手法もある。 Azure ML・SageMakerなどのマネージドサービスの動向を追う: 学術的な効率化手法は、クラウドのマネージドMLサービスに数ヶ月〜1年遅れで実装されることが多い。TLTが注目を集めれば、Azure Machine Learningへの統合も検討されるだろう。 筆者の見解 TLTが示す方向性は非常に正しいと感じる。LLMの進化競争において「より大きなモデルをより多くのデータで回す」というスケール至上主義は、物理的・経済的な限界に近づきつつある。そこで「同じリソースでどれだけ賢く学ばせるか」という効率の競争に軸足が移っていくのは自然な流れだ。 個人的に興味深いのは、この手法が「量より質」「均一処理より適応処理」という思想を学習プロセス自体に持ち込んでいる点だ。AIに人間の学習理論を応用するアプローチは以前からあるが、TLTはそれを大規模モデルのトレーニングに実装できる形で提示した点で一歩進んでいる。 一方で、論文の数値を額面通りに受け取るのは早計だ。研究環境での成果が実際のプロダクションワークロードにどこまでスケールするかは、再現実験や第三者検証を待つ必要がある。「70〜210%」という幅の広さ自体が、条件依存性の高さを示唆している。 実務者として見るなら、TLTそのものより「学習効率化の研究が活発化している」というトレンドに注目したい。MITだけでなく、GoogleのDeepMind、中国の研究機関も同方向の研究を進めている。この競争が加速するほど、AIを使う側のコストは下がり、活用の裾野は広がる。それは日本のIT業界にとっても、変革に乗り遅れないための「時間的猶予」が多少広がることを意味するかもしれない。 とはいえ、猶予があっても使わなければ意味はない。計算コストが下がる未来を待つより、今ある環境でAIを実際に動かし、成果を積み重ねる側にいることの方が、はるかに重要だと思っている。 出典: この記事は MIT New Method Could Increase LLM Training Efficiency 70–210% の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AppleがiOS 27・iPadOS 27・macOS 27において、Apple IntelligenceのAIバックエンドとして動作するモデルをGoogle GeminiやAnthropic Claudeなどサードパーティ製から選択できる仕組みを計画していることが明らかになった。AI分野のプラットフォーム競争に新たな局面をもたらす動きだ。 Apple Intelligenceの現状と何が変わるか Apple Intelligenceは2024年のWWDCで発表されたAppleのAI基盤機能で、文章生成・画像生成・通知要約・Siriの強化などをiPhone・iPad・Mac上で提供している。現行バージョンでは、一部のクラウド処理にOpenAI（ChatGPT）を利用しているが、ユーザーがモデルを選択する余地はほぼない。 iOS 27以降では、Google GeminiやAnthropic Claudeを含む複数のサードパーティモデルをユーザー自身が選べる仕組みへと拡張する計画が報じられている。Appleが「自社製AIで完結させる」アプローチから、「AIモデルのプラットフォームを提供する」方向へ軸足を移すことを意味する。 Appleらしい戦略——プラットフォーム設計の妙 AppleがAIモデルの開発で最前線を走るのではなく、「最良のモデルを選べるハードウェア・OSプラットフォーム」として機能するという発想は、同社の強みを活かした合理的な判断だ。 ユーザーのロックインはハードウェア・OSレイヤーで確保しながら、AIモデルは特定ベンダーへの依存を避けてオープンに保つ——この構図はAppleがAppStoreで確立したプラットフォームビジネスの応用ともいえる。 実務への影響 企業のMDM・デバイス管理 iPhone・iPadを業務利用している企業のIT部門にとって重要なのは、モデル選択をMDMポリシーで制御できるかどうかだ。GDPRや日本の個人情報保護法への準拠、あるいは機密情報の外部送信リスクを管理するためには、使用できるAIモデルを組織側でコントロールする仕組みが必要になる。iOS 27のリリースに合わせて、Apple Business Manager側の対応がどこまで進むかに注目したい。 開発者の新たな可能性 ユーザーが選択したAIモデルをアプリ内から呼び出せるAPIが整備されれば、「ユーザーの好みのモデルで動く」アプリの設計が可能になる。現状のCoreMLやCreate MLとは異なる、オンデバイス／クラウドハイブリッドのAIアプリ開発パターンが生まれる可能性がある。 ユーザー体験とAIリテラシー 「どのモデルが自分の用途に合うか」を実際に試せる環境は、AIリテラシーの底上げにも貢献する。特定の1社のAIだけを使い続ける状況から、目的に応じて使い分ける習慣への移行が、一般ユーザー層にも広がるかもしれない。 筆者の見解 AppleがAIモデルの選択肢をユーザーに開放するという方向性は、プラットフォーム設計として興味深い。ハードウェア・OS・エコシステムに圧倒的な強みを持つAppleが「モデル競争には直接参加しない」という判断をするのは、長期的に見て賢い布石になりうる。 ただ、選択肢が増えることの副作用も忘れてはならない。モデルを選べるようになればなるほど、企業のIT部門は「何を使わせるか」「何を禁止するか」の判断を迫られる。禁止アプローチはたいてい失敗する。「公式に認定されたモデルを使う方が便利な状況」を設計できるかどうかが、IT部門の腕の見せ所になるだろう。 また、「どのモデルを使うか」という選択よりも本質的な問いがある。そのモデルをどんなワークフローに組み込むかだ。単発の質問への回答をどのモデルでやるかよりも、自律的にループで動くエージェントとしてどう設計するかを考える方が、現時点では重要度がずっと高い。 WWDC 2026でAppleがどんな形でこれを実装・発表するかに注目したい。モデルの多様化が進む中、「選べること」ではなく「使いこなせること」が価値の源泉になる時代に向けて、日本のエンジニアとIT部門も今から備えておく価値がある。 出典: この記事は Apple Plans to Let Users Choose Third-Party AI Models Including Google and Anthropic for Apple Intelligence の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Azure上の旧世代VM（仮想マシン）系列を対象としたReserved VM Instances（リザーブドインスタンス）の新規購入および更新を、2026年7月1日をもって終了すると発表した。Av2・Bv1・Dv2・Fsv2・Gシリーズなどのレガシー系列を予約割引で利用している企業は、移行計画を早急に立てる必要がある。 廃止されるVM系列と影響範囲 今回の廃止対象となる主なVM系列は以下の通りだ。 Av2シリーズ（汎用、旧世代） Bv1シリーズ（バースト可能） Dv2 / Dsv2シリーズ（汎用） Dv3 / Dsv3シリーズ（汎用） Fsv2シリーズ（コンピューティング最適化） Gシリーズ（メモリ・ストレージ最適化） 2026年7月1日以降、これらの系列に対するReserved VM Instancesの新規購入と既存予約の更新が停止される。ただし、すでに購入済みの予約は契約期間終了まで継続して有効となるため、即座にすべての割引が失われるわけではない。 移行先として推奨される最新VM系列 Microsoftが推奨する移行先は、最新世代のVM系列だ。 旧系列 推奨移行先 Dv2 / Dv3 Dv5 / Dsv5シリーズ Bv1 Bsv2シリーズ Fsv2 Fasv6 / Falsv6シリーズ Gシリーズ Mv3シリーズ 最新世代のVMは旧世代と比較してコストパフォーマンスが大幅に向上しており、同等またはそれ以上のスペックをより低いコストで提供できるケースも多い。特にDv5・Ev5系列はIntelの第3世代もしくはAMD EPYCプロセッサを採用し、ネットワーク帯域やストレージスループットでも世代間の差は顕著だ。 実務への影響：日本のエンジニア・IT管理者が今やるべきこと 1. 現在のリザーブドインスタンス棚卸し Azureポータルの「予約」ブレード、またはAzure Cost Management + Billingから、対象VM系列のReserved Instancesを確認しよう。有効期限と系列名を一覧化し、7月1日以前に期限切れを迎えるものを優先的に対応する。 2. 更新前に移行を完了させる 既存の予約が2026年7月1日以降に満了する場合、更新が不可能になるため、期限到来前に新世代VMへのリソース移行と新規予約の購入を完了させる計画が必要だ。 3. Azure Migrate・Azure Advisorを活用する Azure Advisorは旧世代VMに対して自動的に移行提案を出すことがある。Azure Migrateを使えば、依存関係のマッピングや移行後のコスト見積もりも自動化できる。これらを活用して影響範囲と工数を早めに把握しよう。 4. Savings Planとの使い分けを検討 Reserved VM Instancesは特定のVM系列・リージョンに縛られるが、Azure Savings Planはより柔軟に適用できる。今後も頻繁にVMサイズを変更する予定があるなら、Savings Planへの切り替えも選択肢の一つだ。 筆者の見解 Azureを長く使っていると、こうしたVM世代交代のアナウンスは定期的に届く。2026年7月という期日は一見余裕があるように見えるが、本番環境のVM移行は検証・承認・メンテナンスウィンドウの確保など多くのステップが必要で、実際に動き出してみると時間はあっという間に過ぎる。 正直なところ、レガシーVM系列を今も使い続けている企業の中には、「動いているから触らない」という判断でここまで来たケースも少なくないだろう。だが今回のようなReserved Instancesの廃止は、コスト最適化の恩恵が受けられなくなるだけでなく、将来的なVM系列廃止の予告でもある。Azureはこういったアナウンスを段階的に行う傾向があり、今動いている計算機が突然使えなくなるわけではないが、「標準的で再現性のある構成」を維持するためにも、推奨世代のVMに揃えておくのが正しい道だ。 ...

MicrosoftはEntra IDのパスキープロファイル機能を、2026年5月より米国政府クラウド（GCC・GCC High・DoD）向けに一般提供（GA）開始した。既存のパスキー（FIDO2）認証が有効なテナントは同年8月以降に自動移行の対象となり、管理者は事前確認と準備が求められる。 パスキープロファイルとは何か パスキープロファイルは、組織内のパスキー認証設定をグループ単位できめ細かく管理するための新しい構成単位だ。従来のFIDO2認証方法ポリシーが組織全体への一律適用しかできなかったのに対し、パスキープロファイルを使えば部署やセキュリティグループごとに異なるポリシーを適用できる。 パブリッククラウド（Worldwide）では2026年3月にGA済みであり、今回のロールアウトで政府クラウドが追いつく形となった： GCC（Government Community Cloud） GCC High DoD（Department of Defense） USNat・USSecへのロールアウトは2026年7月以降の予定だ。 端末固定型 vs 同期型：passkeyTypeプロパティの役割 今回の主要な新機能が passkeyType プロパティだ。管理者はパスキーの種類を以下の3パターンから選択して制御できる： 設定 説明 デバイスバウンド（端末固定型） 特定端末にのみ紐付け。他端末への同期は行わない 同期型（Synced Passkeys） Apple Keychain・Google Password Manager・1Passwordなどを通じてデバイス間で同期可能 両方許可 上記いずれも受け入れる セキュリティ要件の高い組織では「端末固定型のみ」を選択することで、フィッシング耐性を維持しつつパスキー盗用リスクを低減できる。一方、利便性を優先する組織では同期型を許可することで、複数デバイスでのシームレスな認証が実現する。 既存テナントへの自動移行：何が変わるか すでにパスキー（FIDO2）を有効化しているテナントは、以下のスケジュールで自動移行が実施される。 GCC / GCC High / DoD の場合： GAロールアウト：2026年5月初旬〜5月末 自動移行：2026年8月初旬〜8月末 移行後に起きること： 既存のFIDO2認証方法設定は「デフォルトパスキープロファイル」に自動変換される passkeyTypeの値は現在のAttestation設定に基づいて決定される Attestation強制が無効のテナント → 同期型パスキーが有効化 Attestation強制が有効のテナント → 端末固定型のみ 新たな認証方法が自動追加されることはない 「設定が変わっても、新機能が突然有効になるわけではない」という点は重要だ。移行はあくまでスキーマの変換であり、既存の認証フローに即時の破壊的影響は与えない。 登録キャンペーンへの影響（Microsoft管理テナント） 「Microsoft管理」状態に設定されている認証方法登録キャンペーンを持つテナントは追加の注意が必要だ。以下の条件がすべて揃う場合、ユーザーへのパスキー登録促進（ナッジ）の挙動が変わる： パスキー（FIDO2）が有効 登録キャンペーンが「Microsoft管理」状態 セルフサービスセットアップが有効 AAGUIDによる制限なし 少なくとも1人のユーザーが同期型・端末固定型の両方で有効化されている この条件を満たすテナントでは、自動移行完了後に登録キャンペーン設定が更新され、対象ユーザーはサインイン時にパスキー登録を促されるようになる。 実務への影響 GCC/DoD環境の直接利用者は限られるが、以下の観点から国内のIT管理者にも参考になる。 グローバル展開企業のIT管理者へ： 米国政府機関・国防関連とのパートナーシップを持つ組織では、パートナーテナント側の設定変更に伴う認証フローの変化に注意が必要だ。 passkeyTypeポリシーの設計はIntuneと連動させる： 「同期型を許可するか否か」の判断は、デバイス管理ポリシー（Intuneによる端末管理）や情報資産のリスク分類と連動して設計すべきだ。端末管理が整備されていない状態で同期型を解放するのはリスクが高い。 ...

Microsoftは、Copilot StudioとAzure AI Foundryを横断したAIエージェントの管理・ガバナンスベストプラクティスをまとめた公式ホワイトペーパーを最新版「v3.2」に更新し、IT管理者・セキュリティ担当者向けの統制指針を刷新した。 エージェントガバナンスホワイトペーパー v3.2 とは MicrosoftのCopilot Studio Blogで公開された本ホワイトペーパーは、企業がMicrosoft 365環境にAIエージェントを展開する際のガバナンス課題に正面から向き合ったドキュメントだ。バージョン3.2の更新では、以下の領域が体系的にカバーされている。 Copilot Studioエージェントの管理ポリシーとアクセス制御 Azure AI Foundryで構築されたカスタムエージェントの統制指針 両プラットフォームを横断したエージェントのライフサイクル管理 Microsoft PurviewのDLP（データ損失防止）ポリシーとの統合 監査・ログ記録のベストプラクティス なぜいまガバナンスフレームワークが必要なのか AIエージェントは「使って終わり」の単機能ツールではない。外部サービスと連携し、ユーザーの代わりに操作を実行し、機密データにアクセスする「Non-Human Identity（NHI）」として動作する。従来のSaaSアプリ管理とは根本的に異なる性質を持っており、既存のITガバナンスの枠組みをそのまま適用しても機能しない。 具体的には以下のリスクが顕在化しやすい。 エージェントに付与されたアクセス権限の範囲が管理者に把握されていない 誰がどのエージェントを作成・展開したかの追跡が困難 エージェントが参照するデータソースと機密分類の整合性が取れていない インシデント発生時に原因を追跡する手段がない v3.2はこれらの課題に対し、Microsoft Entra IDやMicrosoft Purviewとの連携を軸にした実践的な対応策を示している。 Copilot Studio と Azure AI Foundry の二層構造に対応した設計 今回の更新で特筆すべきは、2つのプラットフォームの違いを意識した「段階的なガバナンス設計」が明示された点だ。 Copilot Studioはビジネスユーザー向けのローコード環境で、Teamsやブラウザから手軽にエージェントを作れる。その手軽さゆえ、IT部門の管理が届かない場所でエージェントが増殖する「シャドーAI」が起きやすい。 Azure AI Foundryは開発者向けのフルスタック環境で、カスタムモデルの呼び出しや複雑なオーケストレーションが可能だ。その分、アクセス権限の設計が複雑になり、ミス時の影響範囲も大きい。 両者を同一ポリシーで管理しようとすると、オーバーキルになる部分と穴が生じる部分が混在する。ホワイトペーパーでは利用シナリオとリスクレベルに応じた段階的な適用を推奨しており、この整理は現場感覚に合っている。 実務での活用ポイント 1. まず現状の棚卸しから Microsoft 365管理センターとEntra管理センターで、現在組織内に存在するCopilot Studioエージェントの一覧を取得する。把握されていないエージェントが稼働しているケースは想像以上に多い。 2. Minimum Privilege原則をエージェントにも徹底 エージェントに付与するアクセス権は業務上必要な最小限に絞る。「広めに設定しておけば後で困らない」という発想がリスクの温床になる。 3. 既存DLPポリシーのエージェント対応確認 現行のDLPポリシーがAIエージェントの操作をカバーしているかを確認する。外部コネクタを使うCopilot Studioエージェントは特に要注意だ。 4. Purviewで監査ログを確保 エージェントの操作ログを一定期間保持する設定を事前に入れておく。インシデント時の初動対応で天と地の差が出る。 5. ホワイトペーパーをチームで共有する IT管理者だけが把握しても機能しない。エージェントを展開するビジネスユーザーやPower Platform担当者にも共有し、組織全体のリテラシーを底上げすることが不可欠だ。 筆者の見解 AIエージェントのガバナンスは、「気づいたら手遅れ」になりやすい領域だ。Copilot Studioのローコード性はAI普及を加速させる一方、IT部門の管理が届かない場所でエージェントが増え続けるリスクを同時に生む。 ...