Tech News JP

給与支払いを狙った「ペイロール・パイレート（給与横取り）攻撃」が、カナダで深刻化している。Microsoftのセキュリティチームは、Storm-2755と名付けられた攻撃グループが多要素認証（MFA）すら迂回する高度な手口でカナダ企業の従業員アカウントを乗っ取り、給与振込先を密かに変更していることを警告した。単なるフィッシング詐欺と一線を画す今回の攻撃は、WorkdayやMicrosoft 365を使う日本企業にとっても決して他人事ではない。 AiTM攻撃とは何か——「MFA済みセッション」ごと奪われる この攻撃の核心が「AiTM（Adversary-in-the-Middle、中間者攻撃）」だ。従来のフィッシングがIDとパスワードの窃取を狙うのに対し、AiTMはもっと狡猾な仕組みを使う。 攻撃者はリバースプロキシを用いて、ユーザーと本物のMicrosoft 365サインインページの間に割り込む。マルバタイジング（悪意ある広告）やSEOポイズニングで検索上位に偽サイトを表示させ、ユーザーはMFAを含めた認証を「普通に」完了してしまう。その瞬間、攻撃者はセッションクッキーとOAuthアクセストークンをリアルタイムで横取りする。 つまり被害者は「何も問題なかった」と感じたまま終わるが、攻撃者はその認証済みセッションを持っているため、パスワードもMFAコードも不要でMicrosoft 365にアクセスできてしまう。MicrosoftがこれをSMS・TOTPなどの「フィッシング耐性のないレガシーMFAを事実上バイパスする」と表現しているのはこのためだ。 精巧な「内部工作」——被害者が気づかない仕掛け セッション乗っ取り後の動きが、この攻撃の巧妙さを際立たせている。 Step 1: 視界遮断 まず受信トレイに自動仕分けルールを作成し、「direct deposit」「bank」などのキーワードを含む人事部からのメールを、被害者が気づかない非表示フォルダに自動移動させる。後続の振込先変更に関する連絡が目に触れないようにする布石だ。 Step 2: ソーシャルエンジニアリング 次にHRスタッフへ「直接振込についての質問」という件名のメールを送り、銀行口座情報の更新を誘導する。 Step 3: 直接操作 ソーシャルエンジニアリングが通じない場合は、乗っ取ったセッションでWorkdayなどのHRシステムに直接ログインし、直接預金の設定を手動で変更する。 被害者が異変に気づいた時には、給与はすでに攻撃者の口座に振り込まれた後——というシナリオだ。 日本企業への影響——使っているツールが攻撃経路になる 日本でもWorkday、SAP SuccessFactors、その他の人事系クラウドシステムをMicrosoft 365と連携させて運用している企業は多い。Microsoft 365のセッションを奪われれば、シングルサインオン（SSO）経由で連携する各種システムへのアクセスも可能になるケースがある。 また、日本語環境でも「Microsoft 365 ログイン」などで検索した際の上位結果を無条件に信頼する習慣は危険だ。SEOポイズニングは言語を問わず機能する。 IT管理者が今すぐ取るべき対策 フィッシング耐性のあるMFAへの移行: FIDO2準拠のセキュリティキー（YubiKey等）やWindows Helloによる証明書ベース認証が有効。SMS・TOTPはAiTMに対して無力 条件付きアクセスポリシーの強化: デバイスコンプライアンスチェックや準拠済みデバイスのみ許可する設定を徹底する セッショントークン有効期限の短縮: Microsoft Entra IDのサインイン頻度ポリシーで長時間有効なトークンを制限する HR系操作への追加承認フロー導入: 給与振込先変更などの機密操作は、単一セッション権限だけで完結できない設計にする レガシー認証プロトコルの無効化: 基本認証（Basic Auth）が有効なままの環境は即座にブロックする 侵害が確認された場合は、侵害トークンとセッションの即時失効、悪意のある受信トレイルールの削除、影響アカウントのMFAメソッドと認証情報のリセットが必須だ。 筆者の見解 「MFAを有効にしているから安全」——この認識はもはや通用しない。AiTMが普及した今、それはむしろ「錠前をつけた扉の鍵のコピーを持っている相手と同居している」に近い状態だ。 ゼロトラストの核心は「認証したから信頼する」ではなく「認証しても継続的に検証する」にある。Continuous Access Evaluation（CAE）や条件付きアクセスは、まさにこうした脅威を想定して設計されている。ツールは揃っている。あとはそれを使いきる設計と運用だけだ。 日本の大企業では、旧来の境界防御思想と中途半端なMFA導入が同居しているケースが多い。表面上はセキュリティ強化に見えて、実態は新しい攻撃手法に対してほぼ無防備——という構造が珍しくない。正面からセキュリティに向き合う力も、使えるツールも十分にある。使いきれていないのがもったいない。 給与という最も個人に直結するデータを守れなければ、従業員の信頼は一瞬で崩れる。セキュリティ投資を「コスト」ではなく「組織への信頼の基盤」として捉える視点が、今こそ求められている。 出典: この記事は Microsoft: Canadian employees targeted in payroll pirate attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ハードウェアのスペック確認やシステム監視に欠かせないツールとして、エンジニアやPC愛好家から長年支持されてきた「CPU-Z」「HWMonitor」。その開発元であるCPUID（フランスのソフトウェア会社）の公式サイトが一時的に侵害され、悪意ある実行ファイルが配布されていたことが明らかになった。4月9日から10日にかけて約6時間にわたって発生したこの事件は、「公式サイトからダウンロードすれば安全」という前提が成立しない時代を改めて突きつけるものだ。 何が起きたのか 攻撃者はCPUIDが利用していたサイドAPIに不正アクセスし、CPU-ZおよびHWMonitorのダウンロードリンクをCloudflare R2ストレージ上にホストされた悪意あるファイルへとすり替えた。ダウンロードされた偽ファイルは「HWiNFO_Monitor_Setup」という名前で、実行するとロシア語インターフェースのInno Setupラッパーが起動する仕組みになっていた。 注目すべきはそのマルウェアの高度さだ。マルウェア研究者vxundergroundの分析によると、このマルウェアは以下の特徴を持つ。 多段階（マルチステージ）構造：一度の実行で完結せず、段階的に悪意ある処理を展開する メモリ内動作中心：ディスクへの書き込みを最小限に抑え、フォレンジック調査を困難にする .NETアセンブリ経由のNTDLLプロキシ：カーネルAPIの呼び出しを迂回することでEDR（エンドポイント検出・対応）やウイルス対策ソフトの検知を回避 情報窃取型マルウェア（インフォスティーラー）の疑い VirusTotalでは20のエンジンがこのZIPを検知しているが、明確な識別はできていない。「Tedy Trojan」「Artemis Trojan」と分類するエンジンが混在しており、新種または亜種である可能性を示唆している。 また、同じ脅威グループが先月にはFTP定番ツールのFileZillaユーザーを標的にしていたという報告もある。「広く使われているユーティリティ」を狙うパターンが見え隠れしており、組織的な活動の可能性がある。 なぜこれが重要か この事件が示す本質的なリスクはサプライチェーン攻撃の巧妙さだ。 通常のマルウェア配布と異なり、今回の手口は「公式サイトのURLを踏んだ」「ブラウザのアドレスバーにはcpuid.comと表示されていた」という状況でも被害を受けるというものだ。ダウンロード先URLが動的に書き換えられているため、URLだけを確認する行為には意味がない。 日本のIT現場でも、社内PCのスペック確認やサーバーのハードウェア診断にCPU-ZやHWMonitorを利用しているケースは少なくない。特にIT管理者が展開用にあらかじめダウンロードしたインストーラを社内サーバーに置いている運用では、今回のように「オリジナルのバイナリは無事」であっても侵害されたリンク経由でダウンロードしていれば被害を受けた可能性がある。 実務での活用ポイント 今すぐ確認すべきこと： 4月9日〜10日の間にCPUID製ツールをダウンロードした場合は即座に調査を。ダウンロードしたファイルのハッシュ値を公式が提供する正規のものと突き合わせる。VirusTotalにアップロードして確認するのも有効だ。 ダウンロードインストーラのハッシュ検証を日常化する。公式サイトがSHA-256ハッシュを公開していれば、Get-FileHash（PowerShell）やsha256sum（Linux/Mac）で必ず確認する習慣をつけたい。 エンドポイントのEDR/AV検知ログを遡及確認する。メモリ内動作中心のマルウェアはディスク上の痕跡が薄い。「何かおかしな挙動があったが気づかなかった」ケースがある可能性を念頭に置く。 ソフトウェア配布を社内で一元管理する。Microsoft Intune等を用いてアプリ配布を管理しているならば、「個人が勝手にダウンロードして実行する」行為を制限する構成の有効性を改めて見直すべきだ。禁止一辺倒ではなく、社内承認済みのパッケージ配布基盤を整えることが現実解になる。 筆者の見解 セキュリティの話題は苦手な分野なのだが（細かい話が多すぎるから）、今回の件は技術的な観点から非常に興味深い。 サプライチェーン攻撃は、「正規ルートを通ったから安全」という人間の心理的盲点を正面から突いてくる。今回のCPUID侵害は約6時間で修正されたが、その6時間の間に何人がダウンロードしたかは誰にもわからない。しかも攻撃者の主開発者が休暇中のタイミングを狙ったという点に、組織の隙間を研究していることが透けて見える。 「今動いているから大丈夫」は通用しない——これはSID重複の問題でも繰り返し言ってきた話だが、サプライチェーン攻撃においてはより深刻だ。侵害された入口が「信頼していた場所」なのだから、検知が遅れるのは当然の帰結になってしまう。 ゼロトラストの文脈で言えば、「ダウンロード元のドメインを信頼する」という前提自体を捨てる必要がある。ダウンロードしたファイルのハッシュ検証、EDRによる実行時の振る舞い監視、そして最小権限の原則——これらはこうした高度な攻撃に対して今も有効な3層の防壁だ。 無名のツールではなく、長年多くのエンジニアが使ってきた「信頼されたツール」が標的になったという事実は、改めてすべてのダウンロード行為への注意喚起として受け取ってほしい。 出典: この記事は CPUID hacked to deliver malware via CPU-Z, HWMonitor downloads の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「努力では届かない」という不都合な真実 セキュリティチームは今、これまでにない速度でチケットをこなしている。2022年比で年間4億件以上多くの脆弱性対応イベントをクローズしており、チームとしての「仕事量」は確実に増えている。しかしそれでも、状況は悪化し続けている。 Qualysの脅威リサーチユニットが、10,000以上の組織から収集したCISA KEV（Known Exploited Vulnerabilities）の修正記録10億件超を4年間にわたって分析した結果が公開された。この研究が突きつけるのは、セキュリティ運用の根本的な構造問題だ。 何が起きているのか：数字が語る現実 Time-to-Exploitがマイナスに転じた Google M-Trends 2026によると、重大な脆弱性が「悪用可能な状態」になるまでの平均時間（Time-to-Exploit）はマイナス7日にまで達している。つまり、パッチが存在する前に攻撃者がすでに武器化を完了しているケースが標準になりつつある。 今回追跡された52件の高プロファイル脆弱性のうち、88%は修正よりも先に悪用が始まっていた。半数については、パッチすら存在しない状態で武器化が完了していた。 修正に「季節単位」かかっている現場 代表的な事例をいくつか見てみよう： Spring4Shell: 開示の2日前に悪用開始 → 平均修正日数は266日 Cisco IOS XE: 1ヶ月前に武器化 → 平均修正日数は263日 攻撃者の優位性は「日単位」で測られ、防御側の対応は「季節単位」で測られている。これは情報収集の失敗ではない。運用モデルそのものの失敗だ。 「ヒューマンシーリング」という構造的限界 研究者たちはこの現象を「ヒューマンシーリング（Human Ceiling）」と呼ぶ。人員を増やしてもプロセスを洗練させても越えられない構造的な上限のことだ。 ここで重要な概念として「マニュアルタックス（Manual Tax）」が挙げられている。人間のプロセスが届かない長尾の資産（ネットワーク機器、レガシーインフラ等）が、対応期間を週単位から月単位へと押し上げる「掛け算効果」のことだ。 さらに研究が提案するのが、CVE件数に代わる新指標「リスクマス（Risk Mass）」——脆弱性を抱えた資産数 × 暴露日数で測る累積リスクの概念だ。ダッシュボード上の「クローズ件数」は管理しやすい物語を語るが、ブリーチが狙うのは長尾の尾である。この視点の転換は、CISO・IT管理者が優先度の判断基準を根本から見直すきっかけになる。 実務への影響：日本のIT現場はどう向き合うべきか 日本のエンタープライズ環境は、この問題に対してよりシビアな立場に置かれている。 ネットワーク機器・インフラ系の放置問題は特に深刻だ。エンドポイントの修正中央値が14日以下である一方、Cisco IOS XEのような機器系では中央値でも232日かかっている。「触れない機器には触れない」という慣習がリスクマスを膨大に膨らませている。 明日から実践できるヒント： KPIをCVEクローズ数からリスクマスへ転換する: 「何件直したか」ではなく「どれだけの資産が何日間さらされていたか」を追う。ダッシュボードを経営層に見せる指標も合わせて変える ネットワーク機器・IoTに優先枠を作る: エンドポイント系は速い。遅いのはインフラ系だ。そこに人的リソースを集中投下するか、自動修正の仕組みを先に整える 「ゼロデイ前提」の対応フローを設計する: パッチを待つワークフローは前提として崩れている。ネットワーク分離・アクセス制御など、パッチ以外の軽減策を素早く展開できる体制を持つ Just-In-Time アクセスの整備: 常時アクセス権を持った特権アカウントは、脆弱性が悪用された際の爆発半径を最大化する。権限の最小化・Just-In-Time付与への移行は今すぐ始める 筆者の見解 セキュリティはあまり好きなジャンルではない。細かくなりすぎる議論が多く、木を見て森を見失う傾向がある。しかしこのデータは別格だ。技術的な興味を抑えられない。 この研究が明らかにしたのは、「もっと頑張れ」という話ではないということだ。人間がスプリントを続けても、構造的に勝てない戦い方をしている——これを10億件のデータで証明したことの意義は大きい。 とはいえ、「だから全部AIに任せよう」というのも単純すぎる。「禁止ではなく安全に使える仕組みを」というのが私の基本スタンスだが、セキュリティにも同じことが言える。自律型のリスク対応ループを作るにしても、設計する人間の判断と責任の所在は必ず残る。仕組みを作れる人間が少数いればいい、というのが私の考えだが、そのための設計力が今最も問われている。 インフラ系資産の修正に平均263日かかる状況を「気合でなんとかする」時代は終わった。運用モデルを変える以外に出口はない。この不都合な真実を経営層に伝えるためのデータとして、今回の研究は強力な武器になる。セキュリティ担当者にとっては、予算と体制の刷新を求める根拠として積極的に活用してほしい。 出典: この記事は Analysis of one billion CISA KEV remediation records exposes limits of human-scale security の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows Insider プログラムを大幅に刷新すると発表した。チャンネル数の削減とアクセス簡素化が柱で、「新機能をいち早く試したい」という需要により応えやすくする狙いだ。最近のCanary ビルドの動向を追っていると変化の速さが増している印象があり、このプログラム整理はその流れと無縁ではない。 Windows Insider プログラムの現状 Windows Insider プログラムは、正式リリース前のWindowsの新機能を一般ユーザーが試せるMicrosoft公式のプログラムだ。現在は以下の4チャンネル構成になっている。 Canary チャンネル：最先端の実験的機能。破壊的変更も含む Dev チャンネル：開発中の機能をいち早く試せる Beta チャンネル：比較的安定し、フィードバック重視 Release Preview チャンネル：正式版直前の最終確認向け この構成は一見わかりやすいが、実際には「どのチャンネルを選ぶべきか」「チャンネル間の移動はどうするか」「抜け出せるのか」という混乱が多くのユーザーを悩ませてきた。 今回の刷新内容 今回の刷新の核心は「シンプル化」だ。チャンネル数を削減し、新機能への参加障壁を下げる。より多様なユーザーからフィードバックを集めることが狙いだと見ている。 注目すべき変更の方向性は以下の通り。 チャンネルの統廃合：複数に分散していたチャンネルを整理し、ユーザーが迷わない構成へ 機能アクセスの拡大：「Insider でないと試せない機能」の範囲を見直し、一般提供タイミングを調整 参加・脱退の手続き簡素化：これまで「Insider から抜けると再インストールが必要」といったハードルが存在したが、その改善が期待される なぜこれが重要か 企業のシステム担当者が新機能を事前に確認する手段として、Insider プログラムは実用的なツールだ。参加障壁が下がれば、「正式リリース前に自社環境への影響を把握する」運用がより現実的になる。 また、最近のCanary ビルドは単なる内部改善にとどまらず、エンドユーザーが体感できるレベルの変化が増えてきている。UIの刷新、パフォーマンス改善、新しい操作体験の導入など、「試す価値がある」ものが増えた印象だ。プログラムの簡素化とこの変化の速さが組み合わさると、Insider への参加が「情報感度の高いIT担当者」の標準的な習慣になる可能性がある。 実務での活用ポイント 検証環境への先行導入：本番機ではなく専用の検証VM にInsider ビルドを入れ、新機能の挙動を先行確認する習慣をつける チャンネル選択の見直し：刷新後の新チャンネル構成を確認し、自分の目的（安定性重視 vs. 先行機能重視）に合ったものを選び直す フィードバックを出す：Feedback Hub を使って積極的にフィードバックを送ることで、日本固有の問題（日本語IMEの挙動など）をMicrosoftに伝えられる数少ない機会を活かす 脱退条件の事前確認：参加前に「元に戻す手順」を把握しておく。特に業務用PCでの参加は慎重に 筆者の見解 率直に言うと、Windows Insider プログラムの刷新そのものより、その背景にある「Windowsをもっと積極的に使ってほしい」というMicrosoftのメッセージに注目している。 参加障壁を下げ、チャンネルをシンプルにするというのは正しい方向だ。これまでは「Insider = 人柱」という認識が強く、一般ユーザーや企業担当者が敬遠しがちだった。それを変えようとする意図は評価できる。 一方で、「試しやすくする」環境を整えたとしても、試してもらえる価値ある機能が必要だ。最近のCanary ビルドの動向を見ていると、「これは試したい」と思える変化が確かに増えている。プログラムの改善がこのモメンタムと噛み合えば、Insider の存在感は再び高まるだろう。 Windowsという巨大なプラットフォームを動かす力はMicrosoftにある。今回の刷新が「参加者数を増やすための施策」で終わらず、実際のフィードバックループの質向上につながるかどうか——その点を引き続き注目していきたい。 出典: この記事は Microsoft revamps Windows Insider program with fewer channels, easier access to new features の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIサービスの信頼性を支えるセキュリティ基盤が揺れた。OpenAIは公式ブログにて、Axiosの開発者ツールを経路とするサプライチェーン攻撃への対応を詳細に報告した。同社はmacOS向けコード署名証明書の緊急ローテーションとアプリ更新を実施し、ユーザーデータへの影響はなかったと明言している。技術的な被害は最小限に抑えられたとはいえ、サプライチェーンリスクという根本課題をAI企業ですら抱えていることを改めて示した事例として、日本のエンジニアとIT管理者にとって見過ごせない内容だ。 何が起きたのか 今回の攻撃で悪用されたのは、広く普及しているJavaScript用HTTPクライアントライブラリ「axios」の開発者向けツールチェーンだ。攻撃者はこの経路に侵入し、ビルドプロセスや配布パッケージへの干渉を試みたとされる。OpenAIのmacOSアプリはサードパーティのパッケージ・ツールに依存するソフトウェアサプライチェーンの上に成り立っており、その一部が汚染されたことで、コード署名の信頼性に影響が生じた。 OpenAIが採った対応は迅速だった。 macOSコード署名証明書の緊急ローテーション: 既存の証明書を失効させ、新しい証明書で署名し直したアプリを再配布 アプリの強制アップデート: 旧バージョンを実質的に無効化し、セキュアな新バージョンへ移行を促進 ユーザーデータの保全確認: ユーザーの認証情報・会話データ・個人情報への不正アクセスは確認されず サプライチェーン攻撃とはなにか サプライチェーン攻撃とは、標的のソフトウェアそのものを直接攻撃するのではなく、そのソフトウェアが依存するライブラリ・ツール・ビルドパイプラインを汚染することで間接的に侵入を試みる手法だ。2020年のSolarWinds事件が世界的に注目を浴びたが、その後も規模の大小を問わず類似の攻撃が続いており、axiosのような広く使われるパッケージは特に攻撃者の格好の標的となる。 macOSのコード署名は、アプリが正規の開発者によってビルド・配布されたことを保証する仕組みだ。証明書が第三者に悪用される恐れが生じれば、たとえアプリ本体に直接の改ざんがなくとも、信頼の連鎖（Chain of Trust）が壊れる。OpenAIの判断は、この信頼を素早く再構築するための正攻法といえる。 実務への影響——日本のエンジニア・IT管理者が取るべき行動 今回の事例は「OpenAIだから対岸の火事」ではない。自社のソフトウェア開発・運用に置き換えて考えることが重要だ。 1. 依存ライブラリの棚卸しを今すぐ プロジェクトで利用しているOSSライブラリのメンテナ体制・セキュリティ報告の有無を定期確認する習慣を持つ。GitHub Dependabot や npm audit、pip-audit などのツールを CI/CD パイプラインに組み込んでおくことで、脆弱性の自動検知が可能になる。 2. コード署名・証明書の管理を見直す macOSアプリを配布している組織では、コード署名証明書のライフサイクル管理（有効期限・ローテーション手順・失効ポリシー）を文書化しておく。インシデント発生時に迷わず動けるRunbookの存在が被害拡大防止のカギになる。 3. インシデント対応訓練をしているか OpenAIが評価されるのは、迅速な情報開示と対応の透明性だ。自社でもサプライチェーンが汚染されたと仮定したシナリオでのインシデント対応訓練（Tabletop Exercise）を年1回以上実施することを検討してほしい。 4. エンドユーザーへの影響確認を忘れない OpenAIアプリをMDM（モバイルデバイス管理）経由で組織展開している場合、最新バージョンへの強制更新ポリシーが機能しているかを確認する。古いバージョンが残存すると署名の信頼性を回復できても実態として旧証明書のアプリが動き続けることになる。 筆者の見解 OpenAIの対応は手際よかったと思う。証明書のローテーション、アプリ更新、透明な情報開示——この三点が揃っていれば、サプライチェーン攻撃のインシデントとしては模範的な対応といっていい。ユーザーデータへの影響がなかったことは幸いだったが、それ以上に「影響がなかったと確認できる仕組みを持っていた」ことが重要だ。 一方で、改めて突きつけられる問いがある。AIサービスを日常業務に深く組み込んでいる企業・組織は、そのサービスのサプライチェーンリスクをどこまで把握しているだろうか。SaaS型のAIを使う側としては、プロバイダーがどのようにセキュリティ事故を検知・開示するかを事前に確認しておく責任がある。 日本の企業でAIツールの導入が急速に進む今、「便利さ」の評価と「信頼できるセキュリティ運用をしているか」の評価を分けて議論する成熟が求められている。特に開発ツールチェーンは攻撃者にとって効率の良い侵入経路であることを、今回の事例が改めて示してくれた。自社のパイプラインに同様のリスクがないか、この機会に点検する価値は十分にある。 サプライチェーンの堅牢性は、どれだけ優れたAIモデルを持っていても代替できない。ソフトウェア品質の土台はセキュリティだ——そのことを思い出させてくれる事例だった。 出典: この記事は Our response to the Axios developer tool compromise の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「入室してから気づく」あの地獄、ようやく終わるか Microsoft Teamsに、会議に参加する前にカメラや音声設定を確認できる「入室前プレビュー機能」が追加されることが明らかになった。ZoomやGoogle Meetにはとっくに備わっている機能であり、Teams利用者からは長らく「なぜないのか」と指摘されてきた部分だ。ようやく、Teamsにも当たり前の体験が届こうとしている。 何が変わるのか これまでのTeamsでは、会議リンクをクリックすると即座に参加処理が走り、マイクがミュートになっていなかったり、背景が意図したものと違ったりしても、入室後に気づくしかなかった。特にリモートワーク環境では、自宅の生活音が会議に流れ込んでしまうケースも頻発していた。 今回追加される入室前プレビュー画面では、参加ボタンを押す前に以下の確認ができるようになる。 カメラのオン／オフと映り方の確認 マイクの入力レベルと選択デバイスの確認 背景ぼかし・仮想背景の事前設定 ミュート状態での参加オプション これはZoomが「プレビュー画面」として長年提供してきた体験と基本的に同等のものだ。 なぜこれが重要か ビジネスコミュニケーションツールとして世界中の企業が依存しているTeamsに、この機能が「今まで存在しなかった」という事実は、日本のエンタープライズ現場でも相当な数の「入室即マイクオン事故」を生んできたはずだ。 IT部門の視点から見ると、この機能追加はヘルプデスクへの問い合わせ削減にも直結する。「会議に入ったら自分の声が出ていなかった」「顔が映っていなかった」という初歩的なトラブルは、入室前確認で8割以上は防げる。 また、会議の冒頭で起きる「音が出ない」「映像が映らない」といったトラブルは、参加者全員の時間を奪う。日本の会議文化では特に、最初の数分のトラブルが会議全体の雰囲気に影響することも少なくない。 実務での活用ポイント エンジニア・一般ユーザー向け 入室前画面でマイクの入力レベルを必ず確認する習慣をつける。特に外部スピーカーやBluetooth機器を使っている場合、デバイス切り替えが反映されていないケースが多い 仮想背景を使っている場合、プレビュー画面で実際の背景がどう見えるか事前チェックを怠らない IT管理者向け Teamsポリシーで「ミュート参加をデフォルト」に設定している組織は、この機能追加に伴いユーザー教育の機会にすると良い 入室前画面の活用をオンボーディング資料に組み込み、会議トラブルの自己解決率を上げる施策として使える 筆者の見解 正直に言えば、この機能は「追加」ではなく「ようやく追いついた」と表現するのが正確だ。ZoomもGoogle Meetも、入室前の確認画面は数年前から標準装備していた。Teamsがこれを今のタイミングで追加するというのは、それだけ優先度が後回しになっていたということでもある。 Teamsはエンタープライズ機能の充実度という点では他ツールを圧倒している面も多い。セキュリティ、ガバナンス、Microsoft 365との統合の深さは、競合ツールにはなかなか真似できないレベルだ。だからこそ、こうした「使い始める瞬間」の体験が後回しにされてきたのは、もったいないと感じる。 高度な機能を積み上げる一方で、ユーザーが最初に触れる「参加する」という体験が洗練されていなければ、印象はどうしても損なわれる。Teamsが持つポテンシャルを考えれば、こういった部分こそ先行して磨き込んでほしかった。 とはいえ、今回の対応は評価に値する。地味に見えて、日々の会議を使っているすべてのユーザーに届く改善だ。今後も「使い始め」の体験をきちんと磨いていくことを期待したい。 出典: この記事は Microsoft Teams is getting a crucial feature that has been surprisingly missing so far の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Mozillaが、MicrosoftのCopilotをWindowsおよびエコシステムに静かに組み込んでいく手法について公式に批判声明を出した。「ユーザーをCopilotエコシステムへと気づかないまま誘導し、ロックインを図っている」というのがMozillaの主張だ。AIアシスタントをめぐる主導権争いが、いよいよ表舞台に出てきた形である。 何が問題になっているのか Mozillaが指摘するのは、MicrosoftがWindowsのUI変更やデフォルト設定の変更を通じて、ユーザーの同意を十分に取らないままCopilotの利用を促進しているという点だ。具体的には、Windowsのタスクバーへの組み込み、ウェブブラウザEdgeとの密な統合、Microsoft 365アプリ内での自動有効化などが俎上に載っている。 これはMicrosoftが過去にも経験した構図と重なる。Internet ExplorerのバンドルをめぐってEUが反競争的行為と判断した2000年代の事例、あるいはEdgeをデフォルトブラウザとして強引に設定し直す行為への批判——いずれもプラットフォーム優位性を活かして自社製品の利用を促す戦略だ。今回はそれがAIアシスタントの領域に移ってきた。 「選ぶ権利」の問題として捉えるべき Mozillaの批判の核心は、技術論ではなくユーザーの選択権にある。「良いものなら使ってもらえる」という発想ではなく、「使わざるを得ない状況を作る」という設計になっているとしたら、それはユーザーへの不誠実だ。 特に法人環境での影響は無視できない。IT管理者がグループポリシーやMDMで丁寧に制御していたはずの設定が、Windows Updateや機能更新の中でいつの間にか変わっている、という経験をした方は少なくないだろう。Copilotも同様に、管理外でオンになるケースが増えてきている。 実務への影響——IT管理者が今すぐ確認すべきこと 1. Copilotの展開状況を棚卸しする Microsoft Intune や Microsoft 365 管理センターから、組織内でCopilotがどのユーザー・デバイスで有効になっているかを確認する。想定外のユーザーに展開されていないかチェックが必要だ。 2. グループポリシーで明示的に制御する Copilot関連のポリシー（TurnOffWindowsCopilot など）を明示的に設定し、意図せず有効化されるリスクを排除する。「設定していないから大丈夫」ではなく、「明示的に制御している」状態が正しいゼロトラスト的アプローチだ。 3. データ保護ポリシーとのすり合わせ Copilotが社内データにアクセスできるようになった場合、情報漏洩のリスクが変わる。コンプライアンス担当者とともに、Copilotの利用範囲を改めて定義しておくことを勧める。 4. エンドユーザー教育 禁止するだけでは限界がある。「なぜ管理されているのか」を説明し、公式に整備されたCopilot環境が提供されていれば、そちらを使ってもらう仕組みに誘導することが現実的な管理戦略だ。 筆者の見解 MicrosoftはAI領域において、本来正面から勝負できる力を持っているはずだ。Azure OpenAIのインフラ、Microsoft 365との統合、エンタープライズ市場での圧倒的な地位——これだけのアセットを持ちながら、なぜユーザーに「気づかないうちに使わせる」手法に頼らなければならないのか。もったいないと感じるのが率直なところだ。 Copilotが本当に価値を提供できるのであれば、押しつけなくても使われる。日本の企業でも、Copilot for Microsoft 365の試用後に継続契約につながったケースは実際に存在する。それは機能の価値が伝わったからであって、選択肢を狭めたからではない。 Mozillaの指摘が法的・規制的な議論に発展する可能性もある。特にEUのDMA（デジタル市場法）の文脈では、プラットフォーム事業者によるバンドル行為への目が厳しい。Microsoftにとっては、早期に「ユーザーが自律的に選べる設計」を示すことが、長期的なブランド信頼の観点からもプラスに働くはずだ。 CopilotがいつかAI領域で「これがあってよかった」と言われる存在になることを期待しているからこそ、今の進め方には一言申し上げておきたい。技術力で正々堂々と勝ちにいってほしい。 出典: この記事は Mozilla slams Microsoft’s attempts to force Copilot on customers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「エージェントを作る」から「エージェントを動かす」へ AIエージェントを試作環境で動かすことと、本番環境で安定運用することの間には、想像以上に深い溝がある。サンドボックスの設計、権限管理、状態の永続化、エラー発生時のリカバリ——これらのインフラ整備に数ヶ月かけた末に、「本来やりたかったこと」にようやく着手できる、というのがこれまでの現実だった。 Anthropicが発表した Managed Agents は、その「インフラ地獄」を丸ごと吸収する試みだ。開発者はエージェントが「何をするか」というロジックだけに集中でき、「どう安全に動かすか」の部分はプラットフォーム側が肩代わりする。 何が提供されるのか Managed Agentsが吸収する主な課題は以下の通りだ。 サンドボックス管理: エージェントの実行環境を分離し、意図しない副作用を防ぐ 権限管理: エージェントがアクセスできるリソースの範囲を制御する 状態管理（State Management）: 長時間・多ステップのタスクをまたいで文脈を保持する エラーリカバリ: 失敗時の自動リトライや安全な中断を処理する 内部テストでは、標準的なプロンプティングと比較してタスク成功率が最大10ポイント向上し、特に複雑なタスクで効果が顕著だという。すでにNotion、Sentry、Asanaなどが採用しており、楽天（Rakuten）も導入済み企業として名を連ねている点は日本のエンジニアにとって注目すべき事実だ。 なぜこれが重要なのか ここ数年、「AIエージェント」という言葉はバズワードとして消費されてきた側面がある。しかし本番運用への壁が高すぎるため、多くの組織で「デモは動くが現場には降りてこない」という状況が続いていた。 Managed Agentsが意味するのは、エージェントの本番化コストが大幅に下がるということだ。これはエージェント普及の実質的な加速装置になりうる。 もう一つ重要な視点がある。現在のAI活用の多くは「副操縦士（コパイロット）」モデル、つまり人間が指示を出して、AIが候補や下書きを出す往復運動だ。しかし本来のエージェントは違う。目的を伝えれば、計画・実行・検証を自律的にループし続ける存在だ。このループを本番環境で安定して回すために必要な基盤をプラットフォームが提供してくれるなら、開発者はようやくエージェントの本質的な価値設計に時間を使える。 実務への影響——日本のエンジニア・IT管理者へ エンジニア視点 「エージェントを作りたいが、インフラ構築が怖くて踏み出せない」という組織は、Managed Agentsのような仕組みを試す絶好のタイミングだ PoC（概念実証）から本番化までのギャップが縮まるため、「デモ止まり」で終わるプロジェクトを減らせる可能性がある 楽天のような日本企業がすでに採用している事実は、「海外だけの話」ではないことを示している IT管理者・意思決定者視点 エージェントの権限管理・サンドボックスがプラットフォーム側で整備されることは、ガバナンス面での導入障壁を下げる ただし「管理をプラットフォームに任せる」ことのリスク評価（データ主権、SLAの確認）は必要だ 「まずPoC」ではなく「本番を前提にした設計」から始められる体制が整いつつある 筆者の見解 AIエージェントの議論は長らく「何ができるか」で盛り上がり、「どう本番で動かすか」の現実的な議論は後回しにされてきた。Managed Agentsのような取り組みは、この非対称を埋めようとするものとして率直に評価できる。 特に興味深いのは、エージェントが自律的にループして動き続ける仕組みを本番環境で実現するための基盤が整い始めているという点だ。これは単なる開発効率の話ではない。AIが「1回応答して終わり」の存在から、「継続的に動き続ける存在」へと移行するための、インフラレベルでの前提条件が揃いつつあることを意味する。 もちろん課題もある。フルマネージドは便利な一方、プラットフォームへの依存が生じる。ベンダーロックインのリスクや、データの扱いについては慎重に確認してから採用を判断すべきだ。 それでも全体として、本番AIエージェントが「一部の大企業だけのもの」から「実装できる組織が増えるもの」に変わっていく流れは止まらない。日本のIT現場がこの変化に対して「様子見」を続けている時間的余裕は、思っているより少ないと感じている。 出典: この記事は Anthropic Managed Agents: Infrastructure for Production AI Agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

アリババが2026年4月10日に公開したテキスト→動画生成AIモデル「Happy Horse」が、公開直後にグローバルなランキングでトップに浮上した。日本語メディアではほぼ報じられていないが、動画生成AI領域の勢力図を語るうえで無視できない動きだ。 Happy Horseとは何か 「Happy Horse」はアリババ傘下の研究部門が開発したテキスト→動画（Text-to-Video）生成モデルで、自然言語のプロンプトから高品質な動画クリップを生成する。公開と同時にいくつかの著名なグローバルベンチマークの首位を獲得したと発表されており、その評価速度は「競合を寄せつけない」という表現が大げさでない印象を与えている。 動画生成AIはここ1〜2年で急速に発展した分野だ。テキスト→画像が「静止画を一瞬で作る」技術として定着しつつある一方、テキスト→動画は生成のコスト・時間・品質のバランスがまだ難しく、実務投入に踏み切れていないケースも多い。Happy Horseがその障壁をどこまで下げてくれるかが注目点だ。 中国勢が「動画」でも覇権争いに加わった意味 画像生成AIの世界では、中国発のモデルがコストパフォーマンスと品質の両面で欧米勢を追い上げてきた経緯がある。ローカルLLMの分野でも同様のトレンドが見られ、Happy Horseの登場はそれが動画領域でも始まったことを示している。 グローバルランキングで「即日首位」というのは誇張を含む可能性もあるが、それでも一定の品質評価を経た結果であることは間違いない。OpenAIのSoraが話題を集めてから約1年、動画生成AIの競争がいよいよ本格化してきたタイミングでの参入だ。 実務への影響——エンジニア・クリエイターが今やるべきこと まずは触ってみる: 新しいモデルが出るたびに「情報を追う」だけでは何も変わらない。実際に試してみて、自分の業務・制作フローでどこに使えるかを体感することが先決だ。Happy Horseのアクセス方法（APIかUIか）を確認し、小さなプロジェクトで評価することを勧める。 動画生成AI活用の候補シナリオ: マーケティング素材の試作・プロトタイプ生成 プレゼンテーション用の短尺アニメーション 社内トレーニング動画のたたき台作成 製品デモのモックアップ 注意点: ランキング首位とはいえ、ベンチマーク評価と実務品質は別物だ。商用利用のライセンス条件、日本語プロンプトへの対応状況、生成コスト（APIの場合）を必ず確認してから導入を検討してほしい。 IT管理者向けの視点: 従業員が個人アカウントで外部の動画生成AIサービスを使い始めるのは時間の問題だ。禁止で対応しようとするより、会社として承認済みのツールと利用ガイドラインを整備する方が現実的で、情報漏洩リスクも管理しやすい。 筆者の見解 動画生成AIの競争がここまで速く激しくなるとは、正直1年前には予想できなかった。Happy Horseの「即日首位」という話を聞いて最初に思ったのは「情報だけ追っていたら追いつけない」という実感だ。 中国勢の開発速度と品質向上のペースは、もはや「中国のAI」として軽く見られる段階を完全に超えている。特に動画生成という計算コストが高い領域でこれだけの成果を出してくるのは、相応のリソースと技術力の裏付けがある。 一方で、日本のIT現場における動画生成AIの活用はまだほとんど始まっていない。テキスト→画像でさえ「業務でどう使うか」に悩んでいる企業が多い中、動画はさらにハードルが高く感じられるかもしれない。しかし、考え方を変えれば、今が一番学習コストが低い時期でもある。他の人がまだ「情報を眺めている」段階で自分で使い込んだ人間が、1年後に大きな差をつけることになる。 動画生成AIを「面白そうな技術」で終わらせないために、まず小さな実験を一つ始めてみることを強く勧めたい。大義名分は後からついてくる。 出典: この記事は Alibaba Group Launches Groundbreaking AI Video Model “Happy Horse” の内容をもとに、筆者の見解を加えて独自に執筆したものです。

地政学的な不確実性が、ITインフラの「当たり前」を書き換えつつある。ヨーロッパや政府機関を中心に「ソブリンクラウド（主権的クラウド）」への関心が急速に高まっており、Microsoftもその需要に応える形でAzure LocalとAzure Linuxを軸とした戦略を本格化している。単なるオンプレミス回帰ではなく、クラウドの柔軟性を維持しながらデータ主権を確保するという新しい選択肢の登場だ。 ソブリンクラウドとは何か 「ソブリンクラウド」とは、特定の国家・地域の法律や規制に完全準拠する形でデータを管理・保管できるクラウドインフラを指す。その形態は幅広く、「国内リージョンのパブリッククラウド」から「完全に切り離されたオンプレミス展開」まで、スペクトラムはさまざまだ。 背景にあるのは地政学リスクだ。EUではフランスが2027年までに政府省庁のビデオ会議ツールをフランス製の「Visio」に切り替える方針を発表。オランダ軍は独自のソブリンクラウドを構築中で、オーストリア軍はMicrosoft OfficeからLibreOfficeへの移行を進めている。「クラウドは誰かのコンピュータ」という言葉が、かつてないほどリアルな意味を持つ時代になった。 Microsoftの階層型アプローチ Microsoftは以下の複数レイヤーでソブリンクラウド対応を実現している。 データレジデンシー（Data Residency）: 特定国・地域内にデータを保持する保証 カスタマーロックボックス（Customer Lockbox）: Microsoftがデータにアクセスする際に顧客承認を必須とする 機密コンピューティング（Confidential Computing）: 処理中のデータも暗号化して保護 外部キー管理: Azure Key Vault Managed HSMによる顧客管理の暗号鍵 これらを組み合わせることで、規制が厳しい業界や政府系顧客でも要件を満たせる構成が実現できる。 注目のアーキテクチャ：Azure Local + Azure Linux 今回特に注目すべきは、Azure Localのマルチラック構成がAzure Linux上で稼働するという点だ。従来のWindows Serverではなく、Linuxをベアメタルインフラの基盤として採用するというMicrosoftの明確な戦略転換を示している。 Azure Localは、エンタープライズ向けプライベートクラウドオプションとして、完全オフラインのオンプレミス環境でもAzureの管理体験を提供する。Azure Arcを組み合わせることで、オンプレミスとパブリッククラウドを統一されたコントロールプレーンで管理することが可能になる。 アーキテクチャとしては： 物理インフラ層: 顧客データセンター内のAzure Local（Azure Linux稼働） 管理レイヤー: Azure Arc（ハイブリッド統合管理） ポリシー・認証層: Microsoft Entra ID＋Azure Policy クラウドから切り離しつつも、クラウド管理の体験を損なわないアーキテクチャだ。 日本のIT現場への影響 日本において、ソブリンクラウドへの関心はまだ欧州ほど表立っていないが、以下の領域では確実に議論が始まりつつある。 金融・医療・行政系システム: データの所在要件が強化される動きが出ている 防衛関連サプライチェーン: クラウド調達要件に伴い、データ管理の厳格化が求められつつある 重要インフラ事業者: 外国政府によるデータアクセスへの懸念が一部の業界で高まっている IT管理者・エンジニアへのアクションポイント： 現在のAzure利用において「データはどこに保存されているか」を改めて棚卸しする Customer Lockboxが有効化されているか確認する（デフォルト無効のリソースが多い） 規制要件がある部門について、Azure Policyでのデータレジデンシー制御を検討する オンプレミス資産がある場合は、Azure Arcによるハイブリッド管理への移行を評価する 筆者の見解 ソブリンクラウドの議論を整理するうえで、まず押さえておきたいのは「これは単なるオンプレミス回帰ではない」という点だ。 Azure LocalがAzure Linux上で稼働するという事実は、Microsoftのインフラ戦略における重要な転換点を意味する。かつては「MicrosoftといえばWindows Server」だったが、クラウドネイティブの時代においてMicrosoftが最も効率的で安定したインフラを追求した結果、Linuxに行き着いた。この柔軟性と実用主義はMicrosoftの強みであり、正しい方向性だと思う。 ...

海外のIT業者が書いたブログ記事が、Hacker Newsで381ポイントを集めて話題になっている。内容を一言でまとめると「MicrosoftはOneDriveのデフォルト設定を使って、ユーザーを有償プランへ誘導している」というものだ。実際に現場で何が起きているのか、そして本当の問題はどこにあるのかを改めて整理したい。 何が起きたのか 記事の著者はIT業者として、近所の住人（非技術者）のPCサポートを依頼された。症状はOutlookでメールが受信できなくなったというもの。調査した結果、原因はOneDriveの空き容量ゼロだった。 ポイントは3つある。 Outlookのメールデータが保存先としてOneDriveを使う設計になっている Windows 11はデフォルトでデスクトップ・ドキュメント・ピクチャフォルダーをOneDriveに同期する（デスクトップフォルダーのバックアップ機能） 容量超過のエラーメッセージには、有償ストレージへのアップグレードリンクが表示される このユーザーは自分でそのような設定をした覚えはなく、OneDriveに何かが同期されているという認識すらなかった。エラーを消そうとファイルを手動削除した結果、家族写真を失った可能性があるという。 技術的な背景：設計の「意図」と「結果」のズレ WindowsのOneDriveデフォルト同期は、本来はユーザーデータをクラウドにバックアップするための善意の機能として設計されている。PCが壊れても大切なデータが守られる——その思想自体は否定されるものではない。 ただ、問題になるのは次の点だ。 セットアップ時の同意取得フローが「次へ連打」で完了してしまう設計 同期が有効であることをユーザーが日常的に把握しにくい 容量超過時のメッセージが「問題の説明」ではなく「有償プランへの誘導」として機能している 「OneDriveを使ってデータを守っています」という状態から始まり、「ストレージが足りないので課金してください」で終わる体験は、技術的な事情を知らないユーザーには確かに「罠」に見える。 実務への影響：IT管理者が今すぐ確認すべきこと 企業環境でのリスク 法人端末でも同様の問題は起きうる。特にMicrosoft 365 Business BasicなどOneDriveを含まないライセンスや、5GBの無料枠を使っているケースでは要注意だ。 確認・対処すべき設定 Intuneによる一括管理（推奨） Microsoft Intuneを使っている環境であれば、以下のポリシーでデスクトップバックアップの有効/無効を一括制御できる。 OneDrive CSP: KFMBlockOptIn（既知フォルダー移動の無効化） または KFMSilentOptIn（自動有効化）を組み合わせて意図的に制御する 個別端末での確認 出典: この記事は Microsoft is employing dark patterns to goad users into paying for storage? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フランス政府が、一部の政府機関のコンピューターをWindowsからオープンソースOS「Linux」へ移行する方針を発表した。デジタル担当大臣のダヴィッド・アミエル氏は「我々のデジタルの運命を自らの手に取り戻す」と表明。単なるコスト削減ではなく、デジタル主権（Digital Sovereignty）という国家戦略の一環として位置づけている。 何が起きているのか 移行はまず、フランス政府のデジタル機関であるDINUM（Direction interministérielle du numérique）のコンピューターから開始される。具体的な移行タイムラインやLinuxディストリビューションの選定については未発表だが、フランスはすでに昨年、ビデオ会議ツールをMicrosoft TeamsからフランスViso（Jitsi OSS基盤）に切り替えており、今回の発表はその延長線上にある。 背景にあるのは、トランプ政権発足以降の地政学的緊張だ。米国政府が国際刑事裁判所の判事らに制裁を科し、米国のテクノロジーサービスへのアクセスを遮断したことは、「外国政府が米国クラウドに依存した場合のリスク」を欧州の政策立案者たちに強烈に意識させた。2025年1月には欧州議会も、外国プロバイダーへの依存度低減を欧州委員会に指示する報告書を採択している。 Linuxへの移行は現実的か 「政府がLinuxへ移行」という話は過去にも幾度となく出ては消えてきた。独ミュンヘン市の「LiMux」プロジェクトが典型例で、2003年に開始し2013年に完了したものの、2017年にWindowsへ戻るという結末を迎えた。 今回のフランスの動きが過去と異なるのは、地政学的プレッシャーがドライバーになっている点だ。「Windowsの方が使いやすい」という議論を超えて、国家安全保障と主権の問題として捉えられている。政府機関のデータが外国企業のサーバーやOSに依存することへのリスクヘッジは、純粋な技術選定ではなく政治・外交判断に近い。 また、近年のLinuxデスクトップ環境は実用性が大幅に向上している。Ubuntu・Fedora・Debian系のディストリビューションは、一般的なオフィス業務であればLibreOfficeとWebブラウザで相当部分をカバーできる。特にDINUMのような技術力の高い機関であれば、移行のハードルは一般的な企業より低い。 実務への影響——日本のIT管理者が今すぐ考えるべきこと フランスの動きは遠い話ではない。日本でも以下の観点で実務的な影響が想定される。 1. 調達・契約リスクの再評価 特定ベンダーのクラウドやOSへの集中依存は、政治・外交リスクとセットで評価する時代に入った。BCPの観点からも、主要ツールの代替可能性を定期的にレビューする習慣を持ちたい。 2. SaaS選定におけるデータ所在の確認 欧州のGDPR対応として「データのEU域外移転制限」が厳格化されているが、日本でも重要インフラや官公庁向けシステムでは、データ主権の観点からオンプレミス・国内クラウド優先の議論が出てくる可能性がある。 3. オープンソース基盤のリスク管理能力 Linux移行の成否は技術よりも運用体制で決まる。OSS活用を推進するなら、社内または委託先でのLinuxサポート体制を整備しておくことが重要だ。 筆者の見解 正直に言うと、この話を「Microsoftへの逆風」として単純に読むのは表面的すぎると思っている。 フランスの動きの本質は「Microsoftが嫌いだからLinuxへ」ではなく、「特定の国家に依存したデジタルインフラは国家リスクになりうる」という認識の変化だ。これはMicrosoftに限らず、あらゆる外国テクノロジーベンダーに向けられた問いかけでもある。 Microsoftの立場で考えると、これはもったいない状況だ。AzureはEU内データセンターで主権クラウドオプションを提供しており、Microsoft Cloud for Sovereigntyという専用製品まで用意している。Windows自体もセキュリティ強化の方向で着実に進化してきた。それでも「OSのソースコードが公開されていない」という点は、政府機関にとって最終的な信頼の壁になりうる。オープンソースであれば、少なくとも理論上はコードレベルでの検証が可能だ。 日本のIT業界はこの動きをどう受け止めるか。「欧州は極端だ」と距離を置くのか、それとも「自分たちのデジタルインフラの依存構造を点検するきっかけ」と捉えるのか。大変革が静かに進んでいる中で、後者の姿勢が問われている。 フランスの移行が成功するかどうかはまだわからない。だが「デジタル主権」という概念が欧州の政策文書から実際の調達決定に降りてきた事実は、技術者として注目しておく価値がある。 出典: この記事は France to ditch Windows for Linux to reduce reliance on US tech の内容をもとに、筆者の見解を加えて独自に執筆したものです。

WireGuardのWindows向けクライアントが長い沈黙を破り、大幅なアップデートを届けた。2026年4月10日に公開されたWireGuardNT v0.11およびWireGuard for Windows v0.6は、一時話題を呼んだMicrosoftの署名アカウント停止問題を経て届いた、待望のリリースだ。セキュリティコミュニティを中心に注目を集めている。 何が変わったのか 今回のアップデートの本質は「新機能の追加」よりも「内部品質の抜本的な向上」にある。 新機能としては、パケットをドロップせずに許可IPアドレスを個別削除できる機能（LinuxやFreeBSDでは既に対応済み）と、IPv4接続での超低MTU設定のサポートが加わった。 しかし開発者のJason Donenfeld氏が最も強調するのはコードの近代化だ。サポート対象Windowsの最低バージョンを引き上げたことで、長年にわたって積み重なった互換性ハック・代替コードパス・複雑な動的ディスパッチ処理を一掃できた。ツールチェーンも全面更新されており、ドライバービルドに用いるEWDK、ユーザースペースのClang/LLVM/MingW、メインUIのGoバージョン、さらにEV証明書と署名インフラまで刷新されている。これらの積み重ねが性能改善と安定性の向上につながっている。 Microsoftの署名騒動——「陰謀」ではなく「官僚主義」 今回のリリースに前後して、「MicrosoftがWireGuardの署名アカウントを停止した」というニュースが一部で波紋を呼んだ。Donenfeld氏はこの点を明確に説明している。アカウントが一時停止されたのは事実だが、Hacker NewsやX（旧Twitter）での話題がMicrosoftの目に留まり、翌日にはアカウントが復活して問題は解決済みだという。「陰謀でも悪意でもない。官僚的なプロセスが少し暴走しただけで、Microsoftはすぐに対処してくれた」——これがDonenfeld氏の見解だ。 現在も出回っている一部の報道はこの解決を反映していないため、「署名が停止されたままなのに新バージョンが出た?」と疑問に思った人もいるだろうが、その答えはシンプルだ：アカウントはもう開放されている。 なお今回もWindows 10 1507（Build 10240）という最古のビルドまで対応は継続されている。Microsoftのサポート期限を超えた環境にまで気を配るのは、オープンソースプロジェクトらしい姿勢だ。 実務への影響 WireGuardはLinux・macOS・iOS・Androidで既に成熟した実績があるが、Windows版はこれまで更新頻度が低く、導入に慎重な組織も多かった。今回の刷新で、Windowsを中心とした環境でも安心して採用できる水準に引き上げられた。 IT管理者・エンジニアへの具体的な推奨事項： 既存ユーザー：内蔵のオートアップデーターが署名検証付きで安全に更新を促す。通知に従って更新するだけでよい 新規導入を検討中の組織：従来のIPSec/OpenVPNと比較してコンフィグが圧倒的にシンプルで、障害時の切り分けもしやすい。今がWindowsインフラに組み込む好タイミングだ 古いWindowsが残っている環境：Windows 10 1507まで対応しているが、そこまで古い環境はWireGuardのバージョンより先にOSのライフサイクル管理を優先すべきだ 筆者の見解 率直に言えば、「VPNを使い続ける」という選択肢自体には複雑な思いがある。ゼロトラストアーキテクチャへの移行を推進する立場から見ると、VPNはネットワーク境界への依存を温存する設計であり、長期的には置き換えていくべき技術だと考えている。 ただし、WireGuardはその中でも際立ってクリーンなアプローチをとっている。プロトコル設計がシンプルで監査しやすく、コードベースは小さく、暗号化ライブラリの選択もモダンだ。「今すぐゼロトラストに全面移行できない」という現実の制約の中で選ぶなら、WireGuardは合理的な選択肢の一つといえる。 Microsoft署名騒動については、コミュニティからの声が迅速に届いて翌日には解決されたという経緯は好ましい。官僚的なプロセスの暴走は起きうるものだが、それへの対応速度がその組織の実力を示す。今回はきちんと機能した。 技術的負債の返済という観点で言えば、古いWindowsへの対応クラッドを一掃しながら品質を上げていく今回の方針は正しい方向だ。互換性のためにコードを膨らませ続けることはセキュリティリスクにもなる。こうした「ちゃんと地ならしをしてから走る」姿勢は、長く使われるインフラソフトウェアとして評価できる。 出典: この記事は WireGuard makes new Windows release following Microsoft signing resolution の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2025年、AI エージェントとクラウドリソースをつなぐオープンソースの橋渡し役として Azure MCP Server を公開したが、このたびその 2.0 安定版がリリースされた。276 のMCPツールを 57 の Azure サービスにわたって提供するこのプラットフォームは、今回のリリースで「個人の開発環境で試す」段階から「チームやエンタープライズ全体で本番運用する」段階へと大きく踏み出した。 Azure MCP Server とは何か MCP（Model Context Protocol）は、AIエージェントや開発ツールが外部システムと対話するための標準仕様だ。Azure MCP Server はこの仕様を実装し、Azure のリソース操作——プロビジョニング、デプロイ、監視、運用診断——を構造化されたツールとしてエージェントに提供する。 重要なのは、これがベンダーロックインのための独自プロトコルではなく、オープンな仕様に乗っている点だ。MCPに対応した任意のエージェントフレームワークや IDE から利用できる。 2.0 の核心：セルフホスト型リモートサーバー 1.0 はローカル開発環境での利用が中心だった。2.0 の最大の変化は、Azure MCP Server をリモートサーバーとして組織内に自前でホストできるようになったことだ。 これが意味するのは以下のようなシナリオだ： 開発チーム全員が共通の MCP エンドポイントを使う（設定の一元管理） CI/CD パイプラインや社内自動化システムから MCP 経由で Azure を操作する テナントコンテキストやサブスクリプションのデフォルト値を組織レベルで制御する エンタープライズのネットワークポリシーの境界内に閉じ込めて運用する 認証についても柔軟に対応している。Microsoft Foundry と組み合わせる場合はマネージドIDを利用でき、ユーザーの署名済みコンテキストを安全に引き渡す On-Behalf-Of（OBO）フローにも対応する。 セキュリティ強化の具体的な内容 2.0 ではセキュリティと運用安全性が設計の中心に据えられた。主な改善点は： エンドポイントのバリデーション強化：不正なリクエストをより早い段階で弾く インジェクション攻撃への対策：クエリ系ツールへの一般的なインジェクションパターンを検出・ブロック 開発環境の分離強化：ローカル実行時の環境汚染リスクを低減 AI エージェントがクラウドリソースを直接操作する世界では、従来の「人間がコマンドを打つ」前提のセキュリティモデルでは不十分だ。エージェントが生成したクエリやパラメータは予測不能な形を取りうる。この方向性での投資は当然必要だし、2.0 での対応は評価できる。 ソブリンクラウドへの対応 日本の大企業・公共機関にとって見逃せないのがソブリンクラウド対応の強化だ。Azure Government や国内のリージョン要件を持つ環境でも利用できる体制が整いつつある。規制業種への展開を検討している組織は、この点を確認しておくと良いだろう。 実務への影響——日本のエンジニア・IT管理者にとっての意味 いま考えておくべきこと： 中央管理型 MCP エンドポイントの設計: 野良エージェントが各自の認証情報で Azure を触る状況は避けたい。チームの MCP サーバーを一箇所に立て、アクセス制御と設定を一元化する設計を今から考えておく価値がある。 ...

Microsoftが5月1日より、クラウドPC サービス「Windows 365」の価格を一律20%引き下げると、チャネルパートナーへの通知を通じて明らかにした。主なターゲットは中小企業（SMB）であり、クラウドベースのデスクトップ環境をより多くの組織に届けようという意図が透けて見える。 Windows 365とは何か——改めて整理する Windows 365はフル機能のWindowsデスクトップをクラウド上に展開し、任意のデバイスからブラウザ経由でストリーミングできるサービスだ。Azure Virtual Desktop（AVD）と混同されることが多いが、AVDが仮想化基盤の構築・管理を伴うエンタープライズ向けであるのに対し、Windows 365はPC1台分のリソースをそのままクラウドに置き換えるイメージに近い。ライセンス体系もシンプルで、ユーザー単位の固定月額という分かりやすさが特徴だ。 なぜ今、20%値下げなのか ここ数年でクラウドデスクトップ市場には競合が増えた。AWSのWorkSpaces、Google ChromeOSの企業展開など、選択肢が広がる中でMicrosoftが価格競争力を高める動きは自然な流れといえる。特にSMBセグメントは、初期投資の少なさと運用の簡便さを重視する傾向が強く、月額コストの20%削減はIT担当者の稟議を通りやすくする上で十分な効果がある。 一方で、この値下げには別の文脈もある。端末更新サイクルと絡めた提案だ。Windows 10のサポートが2025年10月に終了を迎え、多くの中小企業が端末リプレースの判断を迫られている。老朽化したハードウェアをそのまま使いながらWindows 11のクラウド環境へ移行するシナリオは、CapExを削減したい企業にとって魅力的な選択肢になりうる。 実務への影響——日本の中小企業IT担当者へのヒント 今が見直しのタイミングとして押さえておきたいポイントを整理する。 Windows 10 EOS対応と組み合わせる: ハードウェアの買い替えコストとWindows 365の月額を5年総コストで比較すると、特に少数台数（10〜50台程度）の環境ではクラウドPC移行が有利になるケースが増える。5月1日の価格改定後の試算を必ず行うこと。 ゼロトラスト推進と相性が良い: Windows 365はデータがエンドポイントに残らない構造であるため、デバイス紛失・盗難時のデータ漏洩リスクが大幅に下がる。ゼロトラスト移行を検討している組織には特に有効な一手となる。 ライセンス体系の整理を忘れずに: Microsoft 365との組み合わせ次第でEntitlementが変わることがある。CSP経由の購入であれば、パートナーに最新の価格表と推奨構成を確認してほしい。 AVDとの使い分けを明確に: ユーザー数が増えるほどAVDの方がコスト効率が上がる場合がある。50名を超える規模なら、両者の比較検討が必要だ。 筆者の見解 この価格改定を見て、正直「やっとここに踏み込んだか」という感想を持った。Windows 365は技術的には完成度の高いサービスだが、価格のせいで中小企業への訴求力が弱かった。ハードウェアの買い替えコストとの比較試算で「高い」と弾かれてきた案件が、この値下げによって再評価されるケースは少なくないはずだ。 Microsoftの総合力——Azure、Entra ID、Intune、Microsoft 365との統合——は他のクラウドデスクトップサービスにはない強みだ。この「プラットフォームの一部として機能するクラウドPC」という価値は、バラバラなポイント製品を組み合わせるコストを考えると、十分に競争力がある。その強さを、もっと多くの企業に届けられる価格帯になったことは素直に評価したい。 あとはパートナーエコシステムが適切な提案活動を行えるかどうか。技術的な優位性があっても、現場に届く言葉で伝えられなければ選ばれない。日本のIT企業・SIerがこの価格改定を機に、クラウドPC移行提案を本格的に始動させる契機になることを期待している。 出典: この記事は Microsoft Cuts Windows 365 Prices by 20% to Attract SMBs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年の最初の3ヶ月で、ベンチャーキャピタルがAI企業に投じた資金は2420億ドルに達した。これは全世界のVC投資総額のおよそ80%に相当する数字だ。一年前の同時期（596億ドル）と比較すると約4倍。「AIブーム」という言葉では追いつかない規模の資本移動が、いま静かに——しかし確実に——業界の地図を塗り替えている。 資金調達が示す「AIは選択肢ではなく前提」という現実 OpenAIは2026年3月時点で累計1200億ドル超を調達し、評価額は8520億ドルに達した。AIの基盤モデルを開発する企業への投資集中は、単なる期待感ではなく「次のインフラ争いに乗り遅れるな」という投資家の本能から来ている。 グローバルなAI市場規模は2025年時点で3909億ドル、2026年は5394億ドルへの拡大が見込まれている（Grand View Research）。2025年時点ですでに78%以上の企業が少なくとも1つのコア業務でAIを活用しており、「まだ様子見」という選択肢はほぼ消滅しつつある。 日本でも大手SIerや製造業を中心にAI導入が加速しているが、「導入率」と「業務変革の深度」の間には依然として大きなギャップがある。この資金の波が何を意味するかを正確に読み解くことが、今後2〜3年の競争力に直結する。 最大のトレンド：「副操縦士」から「自律エージェント」へ 今回の最も重要なシフトは、AIのパラダイム転換だ。これまでのAIアシスタントは「提案する」存在だった。フライト検索を手伝ってくれるが、予約はあなたがする。メール文章を提案してくれるが、送信ボタンを押すのはあなただ。 2026年のAIエージェントは違う。ウェブを横断してフライトを比較し、最適なものを予約し、カレンダーに登録し、関係者に通知を送るまでを一気通貫で実行する。人間が関与するのは「目的を伝える」ときだけだ。 注目すべき動きとして： Microsoft Copilot Cowork — 複数アプリをまたいでタスクを自動化するエージェント機能 Anthropicの「Conway」 — 常時稼働型の自律エージェント（実験段階） Salesforce Slackbot — 自律的な業務アシスタントへの進化 投資家のMarc Andreessen氏は「80年越しの一夜漬けの成功」と表現した。数十年の研究が結実し、エージェントAIという形で一気に花開いているというわけだ。 マルチモーダルが「当たり前」になった もう一つの大きな変化はマルチモーダルAIの実用化だ。テキスト・画像・音声・動画を統合して理解・生成できるAIは、2025年前半にはまだ「すごいデモ」の域を出なかったが、今は実務で使われる機能になっている。 テキストと図表が混在するビジネス文書の解析、音声指示からのドキュメント生成、短尺動画の自動作成——これらが単一のプラットフォームで動く時代が来た。情報処理の粒度が一段上がったことで、AIがより「文脈を理解している」ように感じられる体験が増えている。 実務への影響——日本のエンジニア・IT管理者は何をすべきか 1. 「AIで何ができるか」ではなく「何をさせるか」を定義する ツールの機能を追いかける段階は終わった。自社業務のどのフローを自律エージェントに委ねるかを設計する力が、これからのITアーキテクトに求められる。 2. ガバナンスと自律性のバランスを設計する エージェントが自律的に動くほど、権限管理・ログ・承認フローの設計が重要になる。Microsoft Entra IDやPurviewとの連携を前提に、「エージェントを管理する仕組み」を今から考えておくべきだ。 3. マルチモーダルを業務分析に組み込む 会議の音声録音、図面・設計書のOCR、動画マニュアルの自動テキスト化——これらを組み合わせた知識管理の再設計が、製造・建設・医療などのドメインで実は最もインパクトが大きい。 4. 小さく動かして学ぶ 情報を追いかけることに時間を使うより、実際に動かして成果を出す経験を積む方が圧倒的に価値がある。1つのユースケースで「エージェントが自律的にループを回す」体験をすると、その後の判断軸が劇的に変わる。 筆者の見解 2420億ドルという数字を見て「バブルでは？」と感じる人もいるかもしれない。だが、今回の投資集中は2000年代のドットコムバブルとは質が違う。あの時は「繋がることで何かが起きるはず」という期待だった。今は「実際に業務が変わった、だからもっと投資する」という実績に基づくサイクルだ。 特に「エージェントAI」のパラダイム転換は、筆者が最も注目しているテーマだ。AIが「確認を求め続ける副操縦士」である間は、本質的な価値を得られない。目的を伝えれば自律的にループを回し続ける設計——これが次の競争軸になる。 MicrosoftはCopilot Coworkでこの方向に踏み出しており、正しいベクトルを向いていると感じる。統合プラットフォームとしての強みを活かした全体最適は、Microsoft以外には難しい。だからこそ、エージェントの「自律度」をもう一段引き上げることを期待したい。確認・承認の頻度を下げ、ユーザーが「任せられる」と感じる体験を作れるかどうか——それがMicrosoftの次のチャレンジだと思っている。 日本のIT業界にとっては、この変化に「気づいていない」企業と「すでに動いている」企業の差が、今後2年で取り返しのつかない格差になる。新しい採用・育成・組織設計のパラダイムを、今すぐ本気で考える時期に来ている。 出典: この記事は OpenAI Acquires TBPN, Daily Live Tech and Business Show の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google DeepMindが発表した「AlphaEvolve」は、大規模言語モデル（LLM）と進化的アルゴリズム（Evolutionary Algorithm）を組み合わせた自律型コーディングエージェントだ。単なるコード補完ツールではなく、AIが自ら仮説を立て・実行し・評価し・改良するというループを継続的に回し続けるアーキテクチャとして、エージェント設計の観点から非常に示唆に富む内容になっている。 AlphaEvolveの仕組み：「指示待ち」から「自律ループ」へ AlphaEvolveの核心は、AIが人間の逐一の指示を待たずに動き続ける点にある。その動作フローはシンプルだが強力だ： 候補コードの生成 — GeminiベースのLLMが複数のコードバリアントを並列生成 自動評価 — 各候補のパフォーマンスを定量的に計測・スコアリング 選択と変異 — 優秀な候補を残し、次世代の改良版を生成 ループの継続 — このサイクルを人間の介入なしに繰り返す この設計により、AlphaEvolveはGoogleの世界規模コンピューティングリソースから継続的に約0.7%を回収することに成功した。これはGoogleのスケールを考えると膨大な節約額に相当する。また、GeminiモデルのTPUカーネルの重要部分を23%高速化したとも報告されており、AIが自分自身の基盤インフラを改善するという自己参照的な成果として注目に値する。 科学的発見のエンジンとしての可能性 AlphaEvolveは最適化ツールにとどまらず、計算量理論（アルゴリズム複雑性理論）の未解決問題にもアプローチできることが示されている。長年数学者・計算機科学者が取り組んできた「効率的なアルゴリズムの限界」という問いに対して、進化的探索によって人間の直感が届きにくい解空間を探索できるというわけだ。 人間の研究者が「こう解けるはず」という先入観から脱却できない問題に対して、評価関数さえ適切に設計すれば、アルゴリズムは先入観なく広大な解空間を探索し続ける。これは理論計算機科学・最適化・素材開発など、評価関数を定式化できる分野全般に応用できるアプローチだ。 実務への影響：日本のエンジニア・IT管理者に届けたい視点 今すぐAlphaEvolveを業務に組み込める企業は限られるが、このシステムが示す設計思想はすでに実践可能だ。 注目すべきポイント： 評価関数の設計こそが鍵: AIエージェントに「自律的に動き続ける能力」を持たせるためには、何をもって「良い結果」とするかを定式化できなければならない。テスト通過率・レイテンシ・コードカバレッジなど、自動計測できる指標があれば即座にループ型の最適化が設計できる インフラ最適化への応用: Googleが自社のTPUカーネル最適化に使ったように、CI/CDパイプラインの自動チューニングやクラウドリソースの自動最適化に同様のアプローチを応用するロードマップは十分現実的だ 「評価できないものは最適化できない」: これは逆に言えば、評価できない曖昧な目標を持つタスクには自律ループは機能しないことを意味する。要件定義・目標設定を厳密にする習慣が、AIを有効に動かせるかどうかの分水嶺になる 筆者の見解 AlphaEvolveが示したもっとも重要な事実は、技術的な性能指標そのものよりも「AIエージェントが自律ループで動き続けることの威力」を実例で証明した点だと筆者は見ている。 「何かを頼んだら答えが返ってくる」という一問一答型のAI利用と、「目的を伝えれば自律的にループして解を探し続ける」エージェント型AIとの間には、本質的な能力差がある。AlphaEvolveはそのギャップを、Googleの世界最大級のインフラ上で可視化したという意味で価値がある。 このアーキテクチャが示す方向性——LLMを推論エンジンとして使いつつ、外側のループ構造でその出力を評価・改良し続ける設計——は、これからのAIシステム設計の基本パターンになると考えている。単発の指示で動くのではなく、評価・選択・再生成のサイクルを自律的に回し続けるアーキテクチャこそが、真の意味でのAIエージェントだ。 日本のIT現場でも「AIに頼んだけど微妙な結果しか出なかった」という経験をした方は多いだろう。その多くは、実はAI自体の限界ではなく「一問一答で使い捨て」という使い方の限界に過ぎない。自律ループ型の設計思想を少しでも取り込めれば、同じモデルでも成果は大きく変わる。AlphaEvolveはその可能性を、誰にでも伝わるかたちで証明してみせた。実装と評価関数の設計を、今から考えておく価値は十分にある。 出典: この記事は Google DeepMind’s AlphaEvolve: A Gemini-Powered Coding Agent for Scientific Discovery の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIの覇権争いが激化する中、ライバル関係にあるOpenAI・Anthropic・Googleが手を組んだ。対象は中国企業が仕掛ける「敵対的蒸留（adversarial distillation）」——フロンティアモデルの出力を大量に収集し、自社モデルの強化に利用する行為だ。競争相手同士が安全保障の観点から協調するという、業界史上でも異例の展開となっている。 「敵対的蒸留」とは何か 蒸留（distillation）とは本来、大規模モデルの知識を小規模モデルへ転移させる正当な機械学習技法だ。しかし「敵対的蒸留」はこの概念を悪用する。具体的には、利用規約を無視して大量のAPIアクセスを行い、高性能モデルの応答パターンを組織的に収集。その出力データをもとに自社モデルをファインチューニングすることで、本来であれば数年かかるR&D投資を迂回する手法だ。 いわば「技術の不正コピー」ともいえるが、単なる著作権侵害とは次元が異なる。AIモデルの能力そのものを抽出・移植しようとする行為であり、知的財産の観点でも、安全保障の観点でも深刻な問題をはらんでいる。 攻撃の実態——2万4000アカウント、1600万件超の交換 今回の報告によれば、DeepSeek・Moonshot AI・MiniMaxの3社が関与したとされる攻撃では、約2万4000の不正アカウントを使って1600万件以上のAPIリクエストが実行されたという。これは単発の探索的アクセスではなく、組織的・継続的に設計された収集活動だ。 3社はこうした攻撃パターンの情報を、2023年にOpenAI・Anthropic・Google・Microsoftが共同設立した業界非営利団体「Frontier Model Forum」を通じて共有することで合意した。競合他社間でも脅威インテリジェンスを交換するという、このスキームの意義は小さくない。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと この動きは日本のIT現場にも直接関係する。 API利用規約の再確認が急務。企業として外部のAI APIを利用する場合、利用規約の中に「出力データの再利用禁止」条項が含まれているケースは多い。今回の事案を受け、各社が規約監視と違反検知を強化することは確実だ。業務利用の範囲が規約に準拠しているか、今一度確認しておくべきだろう。 自社モデルやファインチューニング戦略への影響。外部モデルのAPIを使って独自のデータセットを生成し、社内モデルをトレーニングするというアプローチは、規約によっては違反に該当する場合がある。「グレーゾーンだった慣行」がより明確にNGと判定されるケースが増えていく可能性を念頭に置いておきたい。 フロンティアモデルの品質保護が進む。今回の協調枠組みは、逆にいえばフロンティアモデルの品質が今後より厳重に保護されることを意味する。企業がAIに投資すべき対象として、「適切な契約に基づく高品質モデルへのアクセス」がますます重要性を増すだろう。 筆者の見解 AI産業でここまで直接的に競合する企業が、安全保障という共通の利益のもとで情報を共有するという構図は、実に興味深い。これを「敵の敵は味方」と見るのか、それとも「技術の民主化に対する既存プレーヤーの囲い込み」と見るのかは、立場によって分かれるだろう。 私自身は、この協調を「必然的な自己防衛」として肯定的に捉えている。AIモデルの開発には途方もないコンピューティングリソースと研究投資が伴う。その成果を不正に収奪されるのであれば、研究開発のインセンティブ自体が損なわれる。その意味で、今回の動きはAIエコシステムの健全性を守るための合理的な選択だ。 一方で、「蒸留攻撃」という手法の存在そのものが示す事実は重い。AIの能力が出力データから再現可能である——これはモデルの堅牢性や差別化戦略に根本的な問いを投げかける。圧倒的な計算資源とデータを持ち続けることが差別化の源泉であり続けるのか、それともアーキテクチャや学習手法の革新こそが本質的な競争優位になるのか。この問いへの答えは、これからのAI産業の構造を大きく規定するだろう。 日本のIT業界にとってこの話題が示唆するのは、「AIを使いこなす側」に留まるのか「AIの仕組みを深く理解して戦略的に活用する側」に移行するのか、という判断を迫られているということだ。今起きている変化の規模と速度を正確に認識している組織と、そうでない組織の差は、この数年でさらに広がっていく。 出典: この記事は OpenAI, Anthropic, Google Unite to Combat Model Copying in China の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 10のサポート終了（EOL）が2025年10月に完了してから約4か月。StatCounterが公開したデータによると、2026年2月時点でWindows 11のデスクトップシェアは約72.7%に達した。Windows 10は約26.3%まで後退しており、ここ数年で最大のプラットフォーム移行が一気に進んだ形だ。数字だけ見れば「移行はほぼ完了」に映るが、残り約26%の中には対応が間に合っていない中小企業が相当数含まれており、状況は楽観できない。 なぜこれが重要か EOLを迎えたWindows 10は、現在セキュリティパッチが提供されない状態だ。ただし、Microsoftは有償の「ESU（延長セキュリティアップデート）」プログラムを提供しており、2026年10月13日まで延命できる。この「猶予期間」がまだ残っているため、移行を先送りしている組織も少なくない。 問題は、ESU期限を過ぎた瞬間に「無保護のWindows 10端末」がネットワーク上に残ることだ。セキュリティインシデントの観点から見れば、EOL端末が1台でもあればそこが侵入経路になりうる。「今は動いているから大丈夫」という判断は、セキュリティの文脈では危険な先送りに他ならない。 移行を妨げている現実的な障壁 Windows 11への移行を阻む最大の要因のひとつがハードウェア要件だ。TPM 2.0とCPU世代の制約により、2017年以前に購入した端末の多くは正規のアップグレード対象外となっている。中小企業では「まだ動いているから買い替えない」という端末が多く残りがちで、これがシェア移行の足かせになっている。 また、社内システムの互換性確認に時間がかかっているケースもある。基幹業務システムや独自開発ツールがWindows 11で動作するかの検証を後回しにしているうちに、EOL期限を迎えてしまった組織も見受けられる。 実務での対応ポイント まず現状把握から始める: Microsoft Intune や Windows Admin Center を使えば、社内端末のOS分布を即座に可視化できる。どの端末がWindows 10のままで、TPM要件を満たしているかどうかを棚卸しするのが第一歩だ。 ESUの活用は「移行準備期間の確保」として使う: ESUは延命のための手段ではなく、移行計画を整えるための「橋渡し」として位置づけるべきだ。ESU期限である2026年10月13日を締め切りとして逆算したプロジェクト計画を立てることを強く勧める。 ハード買い替えが必要な端末はMicrosoft Intuneで一元管理: 新端末を調達するタイミングで、Intuneによるクラウド管理体制への移行もセットで検討したい。手動セットアップのコストを大幅に削減でき、ゼロトラスト構成との親和性も高い。 互換性検証の自動化: Application Compatibility Toolkit や Windows Autopilot を活用し、アプリ検証を手作業に頼らない仕組みを作ることで、スケールアウト時のボトルネックを解消できる。 筆者の見解 正直なところ、2026年の今になってWindows 11の移行率を追うこと自体、少し時代錯誤な感じがある。クライアントOSのバージョンを「いかに早く上げるか」に注力するより、端末管理をいかにクラウドネイティブに変えるか、IDとデバイスをどう統合するかという問いに向き合う方が本質的だ。 ただ、セキュリティの観点は別の話だ。EOL端末をネットワーク上に放置することの危険性は、どれだけ強調しても足りない。特に日本の中小企業は、エンドポイント管理が属人的になっているケースが多く、「気づいたらEOL端末が残っていた」という状況が十分ありうる。72.7%という数字が示す「移行の波」は本物だが、残る26%に対するプレッシャーは今後さらに強まる。 MicrosoftはWindows 11への移行を通じて、TPMベースのセキュアブートやカーネルドライバーの制限強化など、正しい方向の施策を着実に積み上げてきた。この努力は評価したい。ハードウェア要件の厳格化は多くの現場で不満を生んだが、セキュリティ基盤を底上げするには必要なコストだったと、今なら言える。2026年10月のESU期限を前に、まだ動けていない組織はこれを機に腰を上げてほしい。 出典: この記事は Windows 11 Dominates Desktop Share in 2026: ~73% of Windows PCs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

4月14日に80〜100件超のパッチが降ってくる前に確認すべきこと 2026年4月のパッチチューズデー（4月14日）が迫ってきた。今月は単純な脆弱性修正にとどまらず、起動不能リスクを伴う証明書更新やドライバ信頼モデルの大きな転換が含まれる可能性があり、特にエンタープライズのIT管理者にとっては見逃せない月になりそうだ。 Windows 11 プレビューパッチの混乱と修正 今月初旬、Windows 11 24H2・25H2 向けのOSプレビューパッチ（KB5079391）が問題を起こした。インストール後に「ファイルが見つからない」などのエラーが多発し、Microsoftは一度このKBを取り下げ、アウトオブバンド（OOB）パッチ KB5086672 として再発行している。 「プレビューで問題を潰しておいて、本番リリース時にはクリーンな状態で届ける」というMicrosoftの姿勢は評価できる。プレビューチャンネルを使っている組織は、このOOBパッチの適用状況を確認しておきたい。 Outlookに2件のOOB修正——Teams連携とGmail同期 今月のOOBリリースにはOutlook Classic関連の修正も2件含まれている。 1件目: 3月パッチチューズデーで更新されたTeams会議アドインが、旧バージョンのOutlook Classicと競合するケース。MicrosoftはTeams側を修正済みで、あわせてOutlookを最新版へアップデートするよう案内している。 2件目: 2月26日から発生していたOutlook ClassicのGmail・Yahooアカウント同期停止の問題。Microsoft 365側での修正は完了しているが、パスワード更新後も症状が続く場合は公式サポートページを参照のこと。 最重要: Secure Boot証明書の期限切れ（6月26日） 今月最大のトピックはここだ。Secure Boot用のMicrosoft Windows Production PCA 2011証明書が2026年6月26日に期限切れを迎える。 この証明書の更新パッチを適用していないデバイスは、最悪の場合起動不能になるリスクがある。「そのうち当てればいい」と先送りにしていると手遅れになる。4月のパッチチューズデーで配信される更新が含まれていた場合、優先的に適用すること。 あわせて、クロス署名ドライバの信頼廃止も進んでいる。古いドライバ署名モデルへの依存が残っている環境では、デバイスドライバが突然動作しなくなる可能性があるため、使用しているドライバの署名状況を今のうちに棚卸ししておきたい。 Windows 11 24H2 のEOLは2026年10月13日 Microsoftは3月27日、Windows 11 24H2 Home/Pro が 2026年10月13日 にサポート終了（EOL）を迎えると発表した。IT管理によるコントロール下にないデバイスは自動的に25H2へアップグレードされる。 組織内に「野良デバイス」が存在する場合は、今すぐ管理下に置いてアップグレードポリシーを適用しないと、意図しないタイミングでOSが変わる可能性がある。棚卸しを急ぎたい。 SaRAツールが廃止——後継は「Get Help」 長年使われてきたサポートツール SaRA（Support and Recovery Assistant） が、3月のパッチチューズデーをもってすべての現行OSから廃止された。 後継ツールの Get Help は、GUIバージョンとPowerShellから呼び出せるCLI・スクリプトバージョンの両方が用意されており、Microsoft Office・Microsoft 365・Outlookのトラブルシューティングが主な用途だ。社内ヘルプデスクやチェックリストにSaRAが記載されている場合は、今すぐGet Helpに差し替えておこう。 Chrome 4月のゼロデイ更新（2026年4件目） Googleが今年4件目となるChrome緊急更新を公開した（146.0.7680.177/178）。CVE 21件のうちHighが19件とかなり重い内容だ。Windowsデバイスへの4月パッチ適用と同時に、Chromeの更新も必ず確認したい。 実務への影響 対応項目 期限・重要度 推奨アクション Secure Boot証明書更新 6月26日（必須） 4月PTで配信予定、優先適用 ...