Tech News JP

ローカルLLMの世界が静かに、しかし確実に変わりつつある。Google が2026年4月に公開した Gemma 4 は、混合エキスパート（MoE）アーキテクチャを採用した新世代のオープンウェイトモデルだ。そして LM Studio 0.4.0 が導入したヘッドレスCLI（lms）との組み合わせにより、クラウドAPIに頼らない本格的なローカル推論環境が、ふつうの開発者のMacBookで成立するようになった。 Gemma 4 ファミリーの構成 Gemma 4 は単一モデルではなく、用途別に設計された4モデルのファミリーとして提供されている。 モデル 特徴 E2B / E4B Per-Layer Embeddingsでオンデバイス最適化。音声入力（認識・翻訳）対応 26B-A4B（MoE） 本稿の主役。総パラメータ26B、前向き計算時の活性化は3.8B相当 31B（Dense） 最高精度。MMLU Pro 85.2% / AIME 2026 89.2%。全パラメータを毎回使用 注目すべきは 26B-A4B のベンチマーク結果だ。MMLU Pro 82.6%、AIME 2026 88.3% と、Dense版の31Bにほぼ肉薄しながら、メモリ消費とトークン生成速度は大幅に優れる。 MoEアーキテクチャが「ローカル推論の壁」を崩す Mixture of Experts（混合エキスパート）の仕組みを簡単に説明しよう。 Denseモデルは推論のたびに全パラメータを使う。26Bのモデルなら毎回26Bぶん計算する。対してMoEは「128人のエキスパート専門家」を持ちつつ、トークンごとに「最適な8人だけを呼ぶ」設計になっている。Gemma 4 26B-A4Bでは、実際の計算量は約3.8B相当で済む。 経験則として、MoEの実効品質は √(総パラメータ × 活性パラメータ) で近似できると言われる。このモデルなら √(26B × 3.8B) ≈ 10B 相当の実力を持つ、ということだ。実際、記事著者の検証では M4 Pro（48GB統合メモリ）のMacBook Proで 51トークン/秒 を達成している。 Eloscoreと総パラメータ数の比較では、Qwen 3.5 397B-A17BやKimi-K2.5（1,000B超）と同等スコアを叩き出しながら、26B-A4Bはその数十分の一のフットプリントで収まる。「クラスターがないと動かない」レベルの性能を、個人のラップトップに落とし込む——これがMoEの本質的な価値だ。 LM Studio 0.4.0 の「headless化」が実用性を一変させた LM Studioはもともとローカルモデルを手軽に動かせるデスクトップアプリとして知られていたが、0.4.0でアーキテクチャ自体が変わった。新たに llmster（コア推論エンジン）と lms（CLIツール）が導入され、GUIなしのヘッドレス運用が可能になった。 ...

Windows Insiderの長年の不満が解消されるかもしれない MicrosoftがWindows 11に「Feature Flags」ページを追加することを正式に認めた。ビルド26300.8155に隠しオプションとして存在が確認されており、Windows Insider Program設定画面の「Insider設定の選択」直下に配置される予定だ。Chromeユーザーにはおなじみの chrome://flags と同様の仕組みで、開発中の機能を自分のタイミングで有効・無効に切り替えられるようになる。 Controlled Feature Rollout（CFR）という「運任せ」の問題 ここ数年、MicrosoftはControlled Feature Rollout（CFR）という仕組みで新機能をA/Bテスト的に段階配信してきた。趣旨はシステム安定性の確保という理にかなったものだが、実態としては「Insiderに登録しているのに自分のPCには新機能が来ない」という理不尽な状況を生んでいた。 その解消策として広く使われてきたのがViVeToolだ。CFRで隠されている機能IDを調べて手動で有効化できるサードパーティ製ツールで、Insider界隈では定番中の定番になっていた。便利ではあるが、IDを自力で調査する手間、将来的な動作保証のなさ、そして「公式でないツールを使う」という精神的なハードルがあった。 今回のFeature Flagsは、そのViVeToolが担ってきた役割をMicrosoft公式が引き受けるという意味で、コミュニティへの正面からの回答だと言える。 機能の詳細 現時点で判明している仕様は以下のとおりだ。 Available Flags：現在有効化可能なフラグの一覧。各フラグのオン／オフをトグルで切り替え可能 Inactive Flags：すでにロールアウト完了済み、または削除済みのフラグ。Clearボタンで管理できる Reset all / Apply Changes：一括リセットと変更の適用ボタン 警告表示：「これらの機能はまだ開発中であり、パフォーマンスや安定性に影響を与える可能性があります」 Microsoftは近日中に詳細を共有すると述べており、全Insiderビルドの新機能がフラグ対象になるのか、それとも一部のみかはまだ明確ではない。ただし警告文の表現からは、「新Insiderビルドに含まれる機能はデフォルトでフラグリストに追加される」方向性がうかがえる。 実務への影響 Windows管理者・IT担当者にとって 今回の変更が直接影響するのは主にInsider Program参加者だが、中長期的には企業のWindows展開戦略にも影響しうる。 テスト環境でのUI変更確認が楽になる：新機能が来るかどうかCFR任せにせず、テスト機での検証を計画的に進められる サポートの一貫性：ViVeToolのような非公式ツールを使う必要がなくなれば、「なぜこの機能が有効になっているのか」といったサポート混乱が減る 本番環境は静観が正解：安定性警告が示す通り、本番マシンへの適用は依然として慎重に。機能フラグはあくまでInsiderやテスト環境向けの道具だ 開発者・パワーユーザーにとって 特定のWindowsシェル機能や新UI要素を検証したいアプリ開発者にとっては、再現性の高いテスト環境が公式に整備されることになる。ViVeToolに依存していたワークフローも、公式UIへの移行を検討するタイミングだ。 筆者の見解 Chromeが chrome://flags を提供した頃を振り返ると、「ブラウザがこんなに開発者フレンドリーになるとは」と驚いたものだ。WindowsがそれをOSレベルで実現しようとしているのは、素直に面白い動きだと思う。 一方で、冷静に見ると「なぜこれが今までなかったのか」という疑問も残る。Insider Programは本来「新機能をいち早くテストするプログラム」のはずだ。CFRによってInsiderでも機能が当たらないという状況は、プログラムの趣旨と実態が乖離していた。今回の修正はある意味、その乖離の訂正でもある。 Microsoftがコミュニティの声をきちんと形にしてくれたことは評価したい。ViVeToolというエコシステムが育つほどの需要があった課題に、正面から応えようとしている。Windowsという巨大なプラットフォームを動かし続けながらこうした細部の改善を積み重ねていける組織力は、やはり侮れない。 あとは「全フラグを公開するのか、一部のみか」という肝心な点が今後明らかになる。Insider体験の質を本当に変えるかどうかはそこにかかっている。続報に注目したい。 出典: この記事は Microsoft confirms Windows 11 is getting Chrome-like feature flags to bypass gradual rollouts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Linuxデスクトップの最前線を走るKDE Plasmaが、Waylandの新しいフラクショナルスケーリングプロトコル「xx-fractional-scale-v2」のサポートを進めていることが、KDEチームの「This Week in Plasma」アップデートで明らかになった。HiDPIディスプレイが当たり前になった今、この対応はLinuxデスクトップ環境の実用性を大きく底上げする可能性がある。 Waylandとフラクショナルスケーリング、何が問題だったのか WaylandはX11を置き換えるべく開発が進む次世代ディスプレイサーバープロトコルだ。セキュリティ面やパフォーマンス面でX11を大きく上回るが、長年の課題の一つが「非整数倍スケーリング（Fractional Scaling）」の扱いだった。 4Kや高解像度ディスプレイでは200%（2倍）のスケーリングでは大きすぎ、100%（等倍）では小さすぎる、という場面が多い。150%や125%といった「非整数倍」での表示が求められるわけだが、既存の wp-fractional-scale-v1 プロトコルでは実装ごとに挙動がばらつき、アプリケーションによってはボケた表示やレイアウト崩れが生じるケースがあった。 xx-fractional-scale-v2が解決すること 新プロトコル「xx-fractional-scale-v2」は、この問題に正面から取り組む設計となっている。主な改善点は以下の通りだ。 クライアント側のレンダリング精度向上: アプリケーションが正確なスケール情報を取得できるようになり、自前でシャープな描画ができる コンポジター（KWin等）との連携強化: デスクトップ環境とアプリ間のスケール情報のやり取りが標準化され、実装差異が減る マルチモニター環境での整合性: 異なるDPIのモニターを混在させても、ウィンドウ移動時の再スケーリングがより自然になる KDEのコンポジターであるKWinがこのプロトコルに対応することで、KDE Plasmaアプリだけでなく、GTKアプリやElectronベースのアプリも恩恵を受けられる可能性がある。 実務への影響 — 日本のエンジニア・IT管理者にとって Linux開発環境を業務で使うエンジニアにとって、この変更は無視できない。特に以下のような場面で恩恵が大きい。 開発者向けワークステーション: 4Kモニターや高DPIラップトップでLinuxを使うエンジニアは増えている。IDEやコードエディターの表示がシャープになり、目の疲れ軽減にもつながる。 Dockerデスクトップ・WSL2 GUI: WSL2でLinux GUIアプリをWindows上で動かす構成では、Waylandプロトコルの動作品質がそのままユーザー体験に直結する。Windowsとのインターフェース層が改善されると、この構成の安定性も向上する可能性がある。 Linuxシンクライアント環境: 一部の日本企業では、セキュリティポリシー上Linuxシンクライアントを採用しているところがある。HiDPIディスプレイへの移行が容易になることは、運用コスト面でもプラスだ。 今すぐ試したい場合は、KDE Plasmaの開発版（nightly build）をFlatpakや各ディストリビューションのテストリポジトリから入手して動作確認するのが現実的なアプローチだ。本番環境への適用は安定版リリースを待つのが無難だろう。 筆者の見解 Waylandへの移行は「もうすぐ完成する」と言われ続けて久しいが、フラクショナルスケーリングの標準化という地味ながら本質的な問題にプロトコルレベルで取り組んでいる点は評価に値する。インフラの整備は派手さがないが、それがあってこそ上位レイヤーのアプリが正しく動く。 面白いのは、このような「ディスプレイスケーリングの標準化」という課題は、WindowsのHiDPI対応の歴史とも重なることだ。Windowsも長年、レガシーアプリのDPI非対応問題と格闘してきた。プラットフォームが変わっても、ディスプレイの高解像度化に追いつくのは一筋縄ではいかないということだろう。 KDEは以前から、Wayland対応において他のデスクトップ環境より積極的にプロトコルの拡張・実験を行ってきた。xx-fractional-scale-v2の採用もその延長線上にある。実用的なデスクトップを作るというコミットメントが、こういった地道な取り組みに表れている。引き続き、Plasma 6.x系の完成度が高まっていく過程を注目して見ていきたい。 出典: この記事は KDE is getting support for the xx-fractional-scale-v2 Wayland protocol の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Samsungが、長年Galaxy端末のデフォルトとして親しまれてきた「Samsung Messages」を廃止し、「Google Messages」へ完全移行する方針を発表した。単なるアプリの入れ替えに見えるが、この決定はAndroidエコシステムの構造変化を象徴する出来事として注目に値する。 Samsung Messagesとは何だったのか Samsung Messagesは、Galaxy端末に標準搭載されてきた純正SMSアプリだ。シンプルなSMS/MMSの送受信から始まり、長年にわたってGalaxyユーザーの「当たり前の存在」だった。しかし近年、Google MessagesがRCS（Rich Communication Services）への対応を積極的に進め、既読確認・高画質メディア送信・エンドツーエンド暗号化といった機能を取り込んだことで、Samsung Messagesとの機能差は急速に広がっていった。 なぜ今、廃止なのか SamsungがGoogle Messagesへの統合を選んだ背景には、いくつかの合理的な判断がある。 RCS普及の加速: Appleが2024年にiOS 18でRCSをサポートしたことで、RCSは事実上の次世代SMSとして確立されつつある。Google MessagesはAndroid陣営でのRCS推進役であり、Samsung独自実装を維持するコストよりも、Googleのエコシステムに乗っかる方が利用者体験を向上させやすい。 重複投資の排除: 同じメッセージング機能を二社が並行開発・保守するのは明らかに非効率だ。Samsungとしては、差別化の薄いコモディティ領域から撤退し、リソースをカメラやディスプレイ、Galaxy AIなど競争優位のある領域に集中させる判断は理にかなっている。 ユーザー体験の一貫性: GoogleとSamsungの間に存在した微妙な機能差や互換性の問題が解消されることで、エンドユーザーにとっては混乱が減る。 実務への影響——IT管理者・エンジニアが知っておくべきこと 日本のエンジニアやIT管理者にとって、この変更は以下の点で実務的な意味を持つ。 MDM管理の見直し: 企業向けにGalaxy端末を管理しているIT部門は、Samsung MessagesとGoogle Messagesでポリシーの適用方法が異なる場合がある。Samsung Knox経由での制御とGoogle管理の挙動の違いを事前に確認しておくことを勧める。特にSMS/MMSの送受信制限やデータ保持ポリシーを適用している環境では影響が出やすい。 RCS対応の機会: これを機に、社内コミュニケーションのRCS化を検討するのも一手だ。ただし、RCSはキャリア側の対応状況に依存するため、日本国内の主要キャリアのサポート状況を確認した上で判断してほしい。 移行タイミングの把握: SamsungはGalaxy端末ユーザーに対して移行期限を設けているため、BYOD（私物端末の業務利用）を許可している組織では、ユーザーへの事前周知が必要になる。移行後もSMSの送受信機能自体は継続されるため、業務影響は限定的と考えられるが、設定やデータ移行でのサポート問合わせが増える可能性はある。 セキュリティ面の確認: Google MessagesはRCSチャット使用時にエンドツーエンド暗号化を提供しているが、SMSは従来通り平文送信であることに変わりはない。機密情報を扱う業務では、引き続き専用のセキュアメッセージングツールを使用するポリシーを維持すべきだ。 筆者の見解 この動きを「Samsungの敗北」と見るのは単純すぎる。むしろ、重複した投資を整理してエコシステム全体を効率化するという、健全な判断だと評価したい。プラットフォームの全体最適という観点からも、機能が重複するアプリを並存させ続けるより、一本化して品質を上げる方が利用者にとって良い結果をもたらすことが多い。 一方で、自社アプリを終了してプラットフォーマーのアプリに委ねるという選択には、長期的なコントロールを手放すリスクも伴う。Samsungのような巨大メーカーですら、この種のトレードオフから無縁ではない。 より本質的な示唆は、メッセージングという機能が完全にコモディティ化したということだ。ユーザーが独自SMSアプリにブランドロイヤリティを感じる時代は終わった。今後は「どのメッセージングアプリか」よりも「どのプロトコルで通信しているか」が重要になる。RCSが本格普及すれば、メッセージングの土台はキャリアからインターネット層へと移っていく。その変化の加速を、今回の発表はあらためて教えてくれている。 出典: この記事は End of an era: Samsung is killing Samsung Messages in favor of Google Messages の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Next.jsを使ったWebアプリケーションを狙った、大規模かつ高度に自動化されたクレデンシャル窃取キャンペーンが確認された。Cisco Talosが今週公開したレポートによれば、「UAT-10608」と追跡される脅威クラスターが「NEXUS Listener」と呼ばれる専用フレームワークを駆使し、わずか24時間のうちに766ホストの侵害に成功している。 何が起きているのか——React2Shell（CVE-2025-55182）という「入り口」 今回の攻撃の起点となっているのが、CVE-2025-55182として採番されたReact2Shellという脆弱性だ。Next.jsアプリに存在するこの欠陥を悪用することで、攻撃者はシステム上でコマンドを実行できる状態を作り出す。 攻撃の流れはシンプルかつ効率的に設計されている。 インターネット上の脆弱なNext.jsアプリを自動スキャン React2Shellで初期侵入を確立 システムの一時ディレクトリに多段階クレデンシャル収集スクリプトを配置 収集した機密情報をHTTPポート8080経由でC2サーバー（NEXUS Listener）へ逐次送信 何が盗まれているのか——想像以上に広い収集範囲 Cisco Talosの研究者が実際にNEXUS Listenerの露出インスタンスへアクセスして分析した結果、収集対象は以下のとおりであることが判明した。 環境変数・シークレット: APIキー、データベース認証情報、GitHub/GitLabトークン SSHプライベートキー クラウドクレデンシャル: AWS・GCP・Azureのメタデータ、IAM認証情報 Kubernetesトークン Dockerコンテナ情報 コマンド履歴 プロセス・ランタイムデータ 特筆すべきは、これらが「あったら盗む」ではなく「ありそうな場所を全部狙う」という設計になっている点だ。AWSのインスタンスメタデータから始まりKubernetesのサービスアカウントトークンに至るまで、クラウドネイティブ環境で使われる機密情報のほぼすべてが収集対象に含まれている。 実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと この攻撃が厄介なのは、被害が侵入されたサーバー単体に留まらない点だ。盗まれたSSHキーは横移動（ラテラルムーブメント）に使われ、クラウドのIAM認証情報はアカウント乗っ取りを可能にし、GitHubトークンはサプライチェーン攻撃の扉を開く。さらにCisco Talosは、個人情報の漏洩によるプライバシー法規制上のリスクも指摘している。日本ではGDPR同等の個人情報保護法への対応が求められる組織も多く、他人事ではない。 今すぐ実施すべき対応策： React2Shellのセキュリティアップデートを即時適用する。 対象システムが特定できない場合、Next.jsを使ったアプリをすべてリストアップするところから始める 侵害の疑いがある場合はクレデンシャルをすべてローテーションする。 「たぶん大丈夫」で済ませてはいけない AWSを使っている場合はIMDSv2を強制する。 IMDSv1が有効なままだとメタデータエンドポイントへの不正アクセスリスクが残る コンテナ・クラウドロールの最小権限原則（Least Privilege）を徹底する。 広すぎる権限は、侵害されたときの被害を指数関数的に拡大させる WAF/RASPをNext.jsアプリの前段に配置する。 シグネチャベースの検知だけでは限界があるが、それでも攻撃コストを上げる効果は大きい シークレットスキャンを有効化する。 GitHubであればSecret Scanningが標準で使える。誤ってコードにクレデンシャルを書いてしまった経験は誰にでもある 筆者の見解 この種の攻撃を見るたびに思うのは、「防御の難しさ」より「そもそもの設計」の問題だということだ。Next.jsアプリのサーバー環境に、AWSのIAMクレデンシャルからKubernetesのサービスアカウントトークンまで、なぜそれほど多種多様な機密情報が置かれているのか。利便性を優先して一台のサーバーに何でも詰め込んでしまうと、一点突破で全部持っていかれる。 「Just-In-Time」なアクセス管理と最小権限の原則は、耳にタコができるほど繰り返されてきた話だが、今回の766ホストという数字は、それが実態に落とし込まれていないことを示している。常時発行されているクレデンシャルが多いほど、盗まれたときのダメージは大きい。環境変数に長期有効なAPIキーを何十個も持つ構成は、攻撃者にとって宝の地図をまるごと渡すようなものだ。 ゼロトラストの文脈で言えば、ネットワーク層・認証層・認可層の3層すべてで独立した防御を設計することが正道だ。どこか一層が突破されたとしても、次の層が機能していれば被害を最小化できる。今回のNEXUS Listenerのような自動収集ツールは今後さらに洗練されていく。一度壊れた信頼を取り戻すコストを考えれば、設計段階での投資は決して高くない。 出典: この記事は Hackers exploit React2Shell in automated credential theft campaign の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Fortinetが週末に緊急のセキュリティアップデートを公開した。FortiClient Enterprise Management Server（EMS）に発見された新たな重大脆弱性（CVE-2026-35616）が、すでに実環境での攻撃に悪用されていることが確認されたためだ。影響を受けるバージョンを運用中のIT管理者は、今すぐ対応が必要な状況だ。 脆弱性の概要：認証を完全に素通りされる CVE-2026-35616は、不適切なアクセス制御（Improper Access Control） に分類される脆弱性だ。攻撃者は認証なしで特細工されたリクエストを送信するだけで、サーバー上でコードやコマンドを実行できてしまう。 この脆弱性を発見したセキュリティ企業Defusedは、「プリオーセンティケーション APIアクセスバイパス」と説明している。つまり、ログイン前の段階で認証・認可の仕組みをまるごと迂回できるということだ。しかも同社は、Fortinetへの報告前にすでに攻撃者が悪用しているゼロデイであることを確認している。 影響を受けるバージョンと対処法 今回の脆弱性が影響するのは以下のバージョンだ： FortiClient EMS 7.4.5（ホットフィックス適用が必要） FortiClient EMS 7.4.6（ホットフィックス適用が必要） FortiClient EMS 7.2系は影響を受けない。 Fortinetは各バージョン向けのホットフィックスを公開しており、7.4.7でも修正が含まれる予定となっている。まずは現行バージョン向けのホットフィックスを優先して適用するのが現実的な対応だ。 なお先週も別の重大脆弱性（CVE-2026-21643）が同じFortiClient EMSで報告・悪用されており、同じくDefusedが発見している。短期間に連続して重大な脆弱性が出ている点は注目に値する。 被害規模：インターネット上に2,000台超が露出 インターネットセキュリティ監視組織のShadowserverによると、FortiClient EMSのインスタンスが2,000台超インターネットに露出した状態で確認されている。主な分布は米国とドイツとされているが、日本のエンタープライズ環境でも導入実績のある製品だけに、国内での被害は他人事ではない。 実務への影響 FortiClient EMSはエンドポイントのセキュリティポリシーを一元管理するサーバーだ。ここが侵害されると、管理下のすべてのエンドポイントに対して任意のポリシーを配布できてしまう可能性がある。被害が拡大するまでの時間が短く、侵害の痕跡も残りにくいタイプの脆弱性だ。 IT管理者がまず確認すべき事項を整理する： バージョン確認: FortiClient EMSのバージョンが7.4.5または7.4.6かどうかを即確認する ホットフィックスの適用: 対象バージョンであれば、Fortinet公式のリリースノートからホットフィックスを取得して適用する 外部露出の確認: FortiClient EMSの管理ポートがインターネットに直接露出していないかを確認する。管理系サーバーをインターネットに直接さらすのは、それ自体が設計の問題だ ログの確認: 脆弱性が悪用されるゼロデイ期間中に不審なAPIアクセスがなかったかをログで確認する 筆者の見解 ゼロトラストアーキテクチャを推進する立場からすると、今回の脆弱性が突いているポイントは示唆的だ。「認証を通らなければ安全」という前提が崩れたとき、その先に何の防御もなければ即座に終わりを迎える。 「管理サーバーはVPNの内側にあるから大丈夫」という感覚でいる環境も多いかもしれないが、ゼロトラストの観点では境界防御だけに頼ることは今や十分ではない。エンドポイント管理のような高権限サーバーへのアクセスには、ネットワーク層だけでなく認証層・認可層も多重に重ね、さらにJust-In-Time（JIT）アクセスのような「必要なときだけ権限を与える」仕組みを加えることが理想だ。 FortiClientはエンドポイントセキュリティの有力な選択肢として多くの現場で使われている。だからこそ、今回のような脆弱性が連続して発生することは残念だし、ユーザーとしては適切なパッチ適用サイクルを維持することが引き続き重要になる。「今動いているから大丈夫」は、こうした事態の前では通用しない。週末に緊急パッチが出た事実が、事の重大さを物語っている。 今すぐ自環境のバージョンを確認し、対象であれば業務時間を待たずに対応することを強く勧める。 出典: この記事は New FortiClient EMS flaw exploited in attacks, emergency patch released の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国で、交通違反の「督促通知」を装ったSMSフィッシングが新たな進化を遂げている。従来のリンク付きテキストメッセージから、裁判所通知の画像にQRコードを埋め込む手法へと切り替わり、セキュリティ研究者やフィルタリングシステムによる検知を意図的に回避しようとしている。 何が起きているのか 攻撃者は「ニューヨーク刑事裁判所」などの公的機関を名乗り、「未払いの交通違反がある。今すぐ支払わなければ法廷に出頭せよ」という内容のSMSを送りつける。メッセージには画像ファイルとして偽造された公式通知書が添付されており、その中にQRコードが印刷されている形をとっている。 QRコードをスキャンすると、まずCAPTCHA（人間確認）ページへ誘導される。これをクリアすると今度は州のDMV（車両管理局）を模倣したフィッシングサイトへリダイレクトされ、「未払い残高 $6.99」の支払い手続きを促す。最終的には氏名・住所・電話番号・メールアドレス・クレジットカード情報が盗まれる仕組みだ。 なぜ「画像＋QRコード」なのか この手法が巧妙なのは、セキュリティ対策の盲点を突いている点だ。 ① テキストリンクを含まない 多くのSMSフィルターやメールゲートウェイは、不審なURLを検出してブロックする。しかしQRコードは画像データであり、リンクとして認識されない。 ② CAPTCHAが自動解析を阻む 悪意あるURLを自動的にクロールして評価するサンドボックスや脅威インテリジェンスシステムは、CAPTCHAで足止めを食らう。人間が操作しなければ先に進めない構造にすることで、調査を困難にしている。 ③ 公的機関への擬態が心理的プレッシャーを生む 「裁判所」「法的措置」「最終警告」という言葉は、受信者に焦りを与える。冷静な判断を奪い、確認せずにQRコードをスキャンさせるための社会工学的な仕掛けだ。 日本への示唆——「対岸の火事」ではない この手口は米国固有の話ではない。日本でも宅配便の不在通知、ETC料金未払い、マイナンバー関連通知を装ったSMSフィッシング（スミッシング）はすでに広く観測されている。今後、同様の「QRコード画像添付型」が日本でも使われるのは時間の問題だろう。 特に注意が必要なのは、QRコードをスキャンする行為そのものがリスクという認識が、一般ユーザーにはまだ薄い点だ。URLを直接タップすることへの警戒心は高まっているが、「カメラをかざすだけ」のQRコードは無意識にスキャンしてしまいがちだ。 実務での対策ポイント エンドユーザーへの啓発として伝えるべきこと： 公的機関（裁判所・警察・行政）はSMSで支払いを求めない QRコードをスキャンする前に「誰から来たか」を一度立ち止まって確認する スキャン先のURLを確認し、公式ドメインでなければ閉じる（ny.gov-skd[.]org のような偽ドメインに注意） 少額請求（今回は$6.99、日本なら数百円程度）は心理的ハードルを下げるための罠 IT管理者・セキュリティ担当者として： モバイルデバイス管理（MDM）ポリシーで、業務端末でのQRコードスキャン先URLのフィルタリングを検討する エンドポイントのモバイルブラウザにも、フィッシング対策フィルターが有効かを確認する フィッシングシミュレーション訓練に「QRコード型」シナリオを追加する時期に来ている 筆者の見解 この事例を見て改めて感じるのは、攻撃者の方がセキュリティ対策の仕組みをよく理解しているという現実だ。テキストリンクが検出されるなら画像にする、URLスキャンが走るならCAPTCHAで止める——対策が進化するたびに、攻撃はその隙間を狙ってくる。 セキュリティの世界では「防御側は全部守らないといけないが、攻撃側は一点突破でいい」と言われる。だからこそ、技術的なフィルタリングだけに頼る発想には限界がある。ユーザーが「おかしいな」と感じて立ち止まれる習慣と知識を育てることが、結局は最も強固な防衛線になる。 組織のセキュリティ担当者としては、禁止や制限で固める方向に走りたくなる気持ちはわかる。しかし「QRコードスキャン禁止」のような硬直したポリシーは、業務での正当な利用まで阻害して形骸化する。「使える仕組みを安全に使える状態にする」という発想で、啓発と技術的補助を組み合わせるアプローチが現実的だと思っている。 今後、こうした攻撃がAI生成の精巧な偽通知画像と組み合わされれば、さらに見分けがつきにくくなる。攻撃手口の進化に対し、私たちの対策と啓発も継続的にアップデートし続けるしかない。 出典: この記事は Traffic violation scams switch to QR codes in new phishing texts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

クラウドが「使えない」現場がある パブリッククラウドは便利だ。しかし現実には、インターネットに常時つながることができない場所で動く重要システムが世界中に存在する。軍・防衛、エネルギーインフラ、公共安全機関、遠隔地の研究施設——こうした環境ではデータをクラウドに送ること自体が規制や安全保障上の要件と衝突する。 MicrosoftとArmadaはこの「ラストマイル問題」に正面から取り組む協業を発表した。Azure Local を Armada の Galleon モジュラーデータセンター（MDC）上に展開し、切断・制限・移動環境でも Azure のクラウド運用モデルをそのまま持ち込める「主権エッジ（Sovereign Edge）」基盤を実現する。 何が新しいのか Azure Local × Galleon MDC の組み合わせ Azure Local は Microsoft のオンプレミスクラウドプラットフォームで、Azure の管理モデルやセキュリティを自前環境に持ち込める製品だ。今回はこれを Armada の Galleon MDC という物理的に展開可能なモジュール型データセンター上で動かす。 Galleon MDC は「運べるデータセンター」として設計されており、衛星・LTE/5G・RF・SD-WAN などの多様な回線に対応した回復性の高いネットワーク接続、ハイパーコンバージドおよび SAN バックストレージ、政府・規制準拠のセキュリティハードニングをパッケージで提供する。完全切断状態でも動作し続ける設計になっている点が最大の特徴だ。 Foundry Local によるオンプレ AI 推論 インフラだけでなく、AI ワークロードもこの環境で完結させられる。Microsoft Sovereign Private Cloud の一部として提供される Foundry Local を使えば、AI 推論・分析処理をパブリッククラウドへの接続なしに自分たちのトラストバウンダリ内だけで完結させることができる。 この構成が対応するユースケースは具体的だ： データ主権要件への対応 — データを自国・自組織のインフラ外に出さない 低遅延のリアルタイム判断 — 分析結果をその場で意思決定に使う 帯域制約・断絶環境での AI 運用 — 接続が不安定な現場でも AI が止まらない 日本のIT現場への影響 「これは海外の防衛案件の話」と思うかもしれないが、日本にとっても無関係ではない。 まず経済安全保障・データ主権の観点。日本の経済安全保障推進法により、重要インフラ事業者（電力・通信・金融・交通等）は外部依存を最小化しながらデジタル化を進めることが求められている。「国産クラウド」という選択肢が現実的でない中、この種の「主権プライベートクラウド」は現実的な落としどころになりえる。 次に地方・離島・災害時の継続性。日本は離島が多く、災害時に回線が切断されるリスクが高い環境だ。このアーキテクチャは「平常時はクラウド接続、断絶時でも AI/データ処理を継続」という運用を可能にする。官公庁・自治体・公共インフラ事業者にとって検討価値は高い。 ...

「障害が起きたとき、どう振る舞うか」から設計する時代 AzureのIaaSチームが、耐障害性設計に関するベストプラクティスシリーズの第2弾を公開した。今回のテーマは「ビルトイン・レジリエンシー」、つまりAzureプラットフォームが標準で提供する可用性・継続性・リカバリーの仕組みを、実際の業務システムにどう組み込むかという実践的な話だ。 技術的な内容に入る前に、一点だけ強調しておきたい。このシリーズが繰り返し述べている「障害はエッジケースではなく現実だ」という一文は、インフラ設計の哲学として非常に本質を突いている。日本のエンタープライズIT現場では、まだ「落ちないようにする」思想が支配的だが、クラウド時代に求められるのは「落ちたときにどう振る舞うか」の設計である。 可用性ゾーンとVM Scale Setsの組み合わせが鍵 物理配置から始まるコンピュート耐障害性 Azureのコンピュート耐障害性は「配置」と「分離」がベースになる。仮想マシン（VM）を一カ所に集中させると、局所的な障害がワークロード全体に波及するリスクが高まる。 Virtual Machine Scale Sets（VMSS） は、スケールと可用性を同時に確保するための機能だ。インスタンスを可用性ゾーンや障害ドメイン（Fault Domain）をまたいで自動的に分散配置し、フロントエンド層・アプリケーション層などの分散サービスを安定稼働させる。スケールアウト/インの自動化だけでなく、障害発生時の影響範囲（ブラストラジウス）を最小化できる点が重要だ。 可用性ゾーン（Availability Zones） はデータセンター単位の分離を提供する。各ゾーンは独立した電源・冷却・ネットワークを持ち、1つのゾーンが影響を受けても他のゾーンが稼働し続ける設計になっている。ゾーンをまたいだアーキテクチャを組むことで、単一拠点障害によるサービス停止を防ぎやすくなる。 ストレージとネットワーク層も同様の考え方で コンピュートだけ冗長化しても、ストレージやネットワークが単一障害点になれば意味がない。IaaSの耐障害性設計は、この3層を一体として考えることが大前提だ。AzureはZone-Redundant Storage（ZRS）やAzure Load Balancerなど、各層で対応する機能を提供している。 実務への影響 — 日本のエンジニア・IT管理者が意識すべきこと 「設計一回きり」では通用しない ブログ内でも触れられているが、「耐障害性設計は一回決めたら終わり」ではない。アーキテクチャが分散・複雑化するにつれ、設計の見直しは継続的に必要になる。MicrosoftはAzure IaaS Resource Centerとして、チュートリアルとベストプラクティスを集約しているので、参照先として押さえておくとよい。 Well-Architectedフレームワークとの接続 Azure Well-Architected Framework（WAF）の信頼性（Reliability）柱と今回の内容は直結している。WAFのレビューを定期的に実施している組織は、今回のシリーズをそのアップデートインプットとして活用できる。未実施であれば、まずWAFレビューから着手するのが「道のド真ん中」だ。 段階的な移行が現実的 既存のオンプレミスワークロードをAzureにリフト&シフトしただけでは、耐障害性の恩恵は限定的だ。VMSSへの移行や可用性ゾーンをまたいだ構成への再設計は、一度に全部やる必要はない。優先度の高いミッションクリティカルなワークロードから順に「クラウドネイティブな耐障害性」を組み込んでいくアプローチが現実的だ。 筆者の見解 AzureのIaaS基盤そのものに対する信頼は揺るがないと私は思っている。可用性ゾーン、VMSSといった機能群は成熟しており、エンタープライズの要件に十分応えられる水準にある。今回のブログシリーズが「基盤から丁寧に語り直す」形式を取っていることも、地に足のついた良い発信だと感じる。 一方で、率直に言えば日本のエンタープライズIT現場との温度差はまだある。「落ちないようにする」から「落ちることを前提に設計する」への思想転換が、まだ浸透しきっていない組織は多い。Azureが正しい設計思想を提供しているのだから、あとはそれを使いこなす側の問題だ。 もう一点加えると、こうした基盤の詳細を追い続けることの意味は、以前と少し変わってきている。AIエージェントが管理タスクを担うようになる未来では、「どの機能をどう組み合わせるか」を人間がすべて把握しなくてよくなる。エンジニアが本当に意識すべきは、「Azureが何を保証し、何を自分たちで設計すべきか」という責任分界点の理解だ。この「共有責任モデル」の本質は、どれだけAIが進化しても変わらない。そこを正しく理解した上で、Azureの耐障害性機能を使い倒してほしい。 出典: この記事は Azure IaaS: Keep critical applications running with built-in resiliency at scale の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが「Copilot」という名前をつけた製品・機能の数が、ついに80種類に達したことが明らかになりました。アプリ、機能、プラットフォーム、ノートPCのカテゴリ名、そして物理的なキーボードキーまで——あらゆるものが「Copilot」を冠しています。この状況は、現場のIT管理者やエンジニアにとって決して他人事ではありません。 「80種類のCopilot」とは何か この数字を掘り起こしたのは、テクノロジーストラテジストのTey Bannerman氏です。「Microsoftのコパイロットとは何か」を誰かに説明しようとして説明できず、全種類をリスト化しようとしたところ、Microsoftの公式サイトや公式ドキュメントにさえ全リストが存在しないことが判明。製品ページ、ローンチアナウンス、マーケティング資料を横断的に調査してようやく地図を作り上げました。 80種類の内訳は大きく次のカテゴリに分類されます： スタンドアロンアプリ（Microsoft Copilot、Copilot+ PC向けアプリなど） Microsoft 365統合機能（Word・Excel・Teams・Outlook各Copilot） Azure・開発者向けプラットフォーム（GitHub Copilot、Azure AI Foundryのエージェント機能群） 業界特化型ソリューション（Security Copilot、Dragon Copilotなど） Copilot Studioおよびその派生（Copilotを作るためのCopilot） ハードウェアカテゴリ（Copilot+ PC、Copilotキー搭載キーボード） さらに今回の公開後、コミュニティから「Gaming Copilot」と「Microsoft Dragon Copilot」の存在が指摘され、即座に80へと更新されました。リストは現在進行形で増え続けています。 なぜこれが重要か——日本のIT現場への影響 日本のエンタープライズ環境では、Microsoft 365のライセンス体系はすでに相当複雑です。「Microsoft 365 Copilot」（月額約4,500円/ユーザー）と「Copilot（無料版）」の違いを正確に説明できる担当者は多くありません。そこへ80種類という現実が重なると、次のような問題が現場で発生します。 ライセンス購買の混乱 「Copilotを導入したい」という経営層の要望に対し、担当者がどのCopilotを指しているのか特定できない事態が起きています。Security CopilotとMicrosoft 365 Copilotでは価格も対象ユーザーも用途もまったく異なります。 サポート・トラブルシュートの困難 エラーが出たとき「Copilotの問題」とだけ書かれた問い合わせでは、どの製品・機能のことか確認するだけで時間を消費します。 社内教育コストの増大 新人や非IT部門のユーザーに「Copilotとは何か」を説明するドキュメントを作成しても、数ヶ月で情報が陳腐化する可能性があります。 実務での活用ポイント 1. 社内では「固有名詞」で呼ぶルールを徹底する 「Copilot」とだけ呼ぶのをやめ、「Microsoft 365 Copilot」「GitHub Copilot」「Security Copilot」と製品名を省略しない運用ルールを設けましょう。ドキュメントや社内チケットシステムへの記載も同様です。 2. 導入前に「どのCopilotか」を必ず確認するゲートを設ける 調達・承認フローに「対象製品の正式名称」を必須項目として追加するだけで、誤購入や重複契約を防げます。 3. Microsoft Learn / Tech Communityを製品名で検索する 「Copilot」単独では検索ノイズが多すぎます。目的の製品名をそのまま検索キーワードに使うことで、正確なドキュメントにたどり着けます。 4. Copilot Studioの位置づけを理解しておく 「Copilotを作るためのCopilot」であるCopilot Studioは、今後の自社エージェント開発の起点になり得ます。80種類の全体像を把握した上で、自社に必要なものだけに絞り込む判断軸として活用できます。 筆者の見解 正直に言えば、これは「命名の失敗」ではなく「命名戦略の迷走」だと思っています。 MicrosoftがAI機能を横断的にブランド統合しようとした意図は理解できます。ユーザーが「Copilotといえばマイクロソフト」とワンブランドで認識してくれれば理想的だったのでしょう。しかし80種類という数字は、その戦略が現場の認知コストを完全に無視した結果です。 Microsoftには、AzureとMicrosoft 365という世界最大規模のプラットフォームがあります。そのインフラの上でAI機能を展開できるポジションは、他社には簡単に真似できない強みです。だからこそ、「Copilotというブランドで全部押し通す」ような力技ではなく、機能の役割と対象が一目でわかる命名体系を整えてほしいと思うのです。 Microsoft Learnのドキュメントチームが日々追いつくのに苦労しているのも、Bannerman氏が独自調査なしにリストを作れなかったのも、すべて同じ根っこの問題です。「統合プラットフォームの全体最適」を掲げる企業が、製品名の体系だけはバラバラという状況は、もったいない。 Microsoftが持つリソースとユーザーベースであれば、この命名カオスを整理することは不可能ではないはずです。Copilotが「混乱のブランド」ではなく「信頼のブランド」として定着する日が来ることを、応援する立場から期待しています。 ...

科学研究において、人間だけが担うと思われてきた「仮説を立て、実験し、論文にまとめる」というサイクルが、AIによって完全に自動化された。Shanda AI Research Tokyoが発表した「AI Scientist-v2」は、研究プロセスのすべてのステップを自律で実行し、その成果論文が学術カンファレンスに採択された。単なる技術デモではなく、査読という第三者評価を通過した点が今回の最大のポイントだ。 AI Scientist-v2とは何をするシステムか AI Scientist-v2は、以下の研究サイクルをエンドツーエンドで自律実行する。 仮説提案 — 既存の文献や知識ベースをもとに、研究上の問いと仮説を生成する 実験設計と実行 — その仮説を検証するための実験を設計し、実際に計算・シミュレーションを走らせる データ分析と解釈 — 実験結果を分析し、統計的に意味のある知見を抽出する 論文執筆 — 研究背景、手法、結果、考察を含む学術論文形式のドキュメントを生成する このうちのどれか一つをAIが補助するツールはすでに多数存在する。しかし、4ステップすべてを連続的に、人間の介入なしに実行して成果を出した事例はこれが初めてだ。 なぜ「査読通過」がそんなに重要なのか 学術論文の査読は、同分野の専門家が匿名で内容の妥当性・新規性・貢献度を評価するプロセスだ。AIが生成したとわかっていれば採択されやすくなるわけではなく、むしろバイアスが逆方向に働くケースもある。そのような環境で採択されたということは、内容の質が「研究として成立している」と認められたことを意味する。 単に「それらしい文章を書いた」のではなく、研究コミュニティが求める水準を満たしていたという事実は重い。 「ハーネスループ」としての科学研究自動化 この事例を技術的に読み解くと、AIエージェントが自分で判断・実行・検証を繰り返す「自律ループ」の構造が見える。仮説を立て → 実験して → 結果を評価して → 論文にまとめる、というサイクルはまさにそのループだ。 重要なのは、各ステップで人間が確認・承認を求められる設計ではないという点だ。エージェントが自分で「次に何をすべきか」を判断しながら前進する。この設計思想こそが、単なるAI補助ツールと真の自律エージェントを分けるラインだ。 日本のIT現場・研究機関への影響 研究者・R&D部門 仮説生成の高速化: 先行研究のサーベイと仮説生成をAIに委ねることで、研究者は「どこに向かうか」の方向性の議論に集中できる 実験イテレーションの加速: 実験→分析→改善のループをAIが回せれば、人間は結果の解釈と意思決定に注力できる ドキュメント生成の効率化: 論文・報告書の初稿生成は、今後急速に自動化が進む領域だ エンジニア・IT管理者 内部R&Dへの応用: 自社製品の改善実験や評価レポートの自動生成に、類似のアーキテクチャを応用できる可能性がある 評価パイプラインの構築: モデル評価、A/Bテスト分析、パフォーマンスレポートの自動生成など、定型的な「実験→報告」ワークフローの自動化が視野に入る AIの出力品質管理: AI生成コンテンツが増える中で、査読に相当する「品質ゲート」を社内にどう設けるかが今後の課題になる 筆者の見解 率直に言って、これは「すごい」という感想より「来るべきものが来た」という感覚の方が強い。AIエージェントが自律ループで動き続ける仕組みの応用先として、科学研究は理想的なフィールドだ。仮説→実験→評価→次の仮説、というサイクルはループとして定式化しやすく、成功・失敗の判定基準（査読通過・不通過）も比較的明確だ。 むしろ今注目すべきは、「科学研究がAIにできるなら、自分の仕事のどのループがAIに任せられるか」という問いだと思う。多くのビジネスプロセスは、研究サイクルと構造的に似た反復ループを持っている。要件定義→実装→テスト→フィードバック、マーケティング施策→効果測定→改善、いずれも同じ構造だ。 一方で、今回の成果を過大評価するのも禁物だ。採択されたのは「AIが書いた論文として評価された」のか、「論文の質そのものが評価された」のかは慎重に見極める必要がある。科学コミュニティが今後どう反応するか――AI生成論文の扱いに関するガイドラインの整備、査読プロセスへの影響――を追うことが、実務的な観点では重要だ。 科学研究の自動化は、研究者の仕事を奪うという方向よりも、人間が「何を問うべきか」というより本質的な問いに集中できる環境を作る方向に進むと見ている。今後2〜3年で、AI生成論文の採択事例は一件の歴史的出来事から「珍しくない日常」へと移行するだろう。その変化の速度を正しく見積もっておくことが、研究機関でもビジネス現場でも戦略的に重要になる。 出典: この記事は AI Scientist-v2: First fully AI-generated paper accepted at academic conference の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが次世代モデル「Mythos」の早期テストを一部顧客と進めており、その性能が「a step change（段階的な飛躍）」と表現されていることが明らかになった。現時点ではリーク情報ベースだが、業界での注目度は高く、AI技術の次フェーズを占ううえで無視できない動きだ。 「段階的な飛躍」とは何を意味するか AI研究の世界で「step change」という表現は慎重に使われる言葉だ。これは単なるベンチマークスコアの数パーセント改善ではなく、定性的に体験が変わる水準のジャンプを意味する。現行のOpusが既にコーディング・推論・長文理解において高い評価を得ているなかで、「それを超える」と評される新モデルが何を指し示すのか。 具体的なアーキテクチャや学習手法は非公開だが、業界関係者の証言には共通するキーワードがある。「より深い多段階推論」「より長い文脈での整合性維持」「自律的なタスク遂行における判断精度の向上」などだ。これらはいずれも、AIが「副操縦士」として人間の指示をその都度待つ従来型の動き方ではなく、目的を伝えれば自律的にループで動き続ける「エージェント型」の設計に直結する要素である。 早期テストのフェーズが持つ意味 注目すべきは、この情報が公式発表ではなく「一部顧客との早期テスト」として出てきている点だ。Anthropicはこれまでも主要APIユーザーや企業パートナーとのクローズドβで品質評価を繰り返してきた。この段階で「段階的な飛躍」という評価が漏れてくるということは、少なくとも実用水準に達しているモデルが存在する可能性が高い。 市場の反応も早く、AI関連株や競合各社の開発ロードマップへの影響を見込む声が出始めている。「Mythosが公開発表される」という前提で次の手を考え始めているプレイヤーが既にいるという状況だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 1. エージェント設計の前提が変わる モデル性能が大幅に上がれば、これまで「人間の確認を挟まないと怖い」と感じていたタスクの自動化範囲が広がる。コードのレビュー・修正・テスト実行を連続して行うようなループ処理、あるいはドキュメント調査から報告書草案生成までを一気通貫で行う処理が、より安定して動くようになる可能性がある。 2. プロンプト設計の見直しタイミング 性能が上がった新モデルに乗り換えるタイミングでは、既存のプロンプトがオーバースペックになることが多い。「失敗しないように細かく指示を書いていた」部分が不要になり、よりシンプルなゴール指定に書き直せる場合がある。リリース後は自社プロンプトの棚卸しを行う価値がある。 3. コスト試算の見直し 「Opusは高いのでSonnetで妥協していた」というユーザーは多い。新世代モデルはリリース当初こそプレミア価格だが、競争圧力でコストが下がるパターンが続いている。Mythosが公開された際は、ユースケースごとの費用対効果を再評価する機会として捉えたい。 4. 「AIは使えない」という先入観の更新 とくに日本の現場では、特定のツールでの体験だけを根拠に「AIは使えない」という結論が固定してしまっているケースが少なくない。新世代モデルの登場は、そうした先入観を再評価する良いきっかけになる。組織として再度評価試験を行う価値がある。 筆者の見解 「ハーネスループ」という概念が今の私の中で最も熱いテーマだ。AIエージェントが自律的にループで動き続ける——指示→実行→検証→次の判断→実行——このサイクルを人間の介在なく回し続ける設計こそが、AIが本当の意味で「仕事をする存在」になる条件だと考えている。 Mythosの「段階的な飛躍」という評価がもし本物だとすれば、それはこのループの信頼性に直結する。単発の問答では既に多くのモデルが実用水準に達している。差が出るのは、複数ステップにわたる推論の整合性、文脈の引き継ぎ精度、そして「やり直す判断」の適切さだ。これらは現行モデルでも動くが、まだ「任せ切れない」感覚が残る場面がある。Mythosがその感覚を消し去るレベルであれば、エージェント型AIの実用化は思ったより早く訪れる。 現時点ではまだリーク段階であり、実際に試してみるまで評価は保留したい。ただ、「段階的な飛躍」という言葉が意味するものが本物かどうかを確かめるために、公開後は真っ先に実務タスクで検証するつもりだ。情報を追いかけるよりも、使ってみて成果を確かめることが今最も価値ある行動だ。 出典: この記事は Anthropic Claude ‘Mythos’ in early testing — described as ‘a step change’ in performance の内容をもとに、筆者の見解を加えて独自に執筆したものです。

熾烈な競争の裏で、なぜ「協調」が生まれたのか 競合関係にあるMicrosoft・Google・OpenAI・Anthropicが、Linux Foundationの傘下で「Agentic Artificial Intelligence Foundation」を共同設立したという報告が出た。通常なら火花を散らすはずのプレイヤーたちが、なぜこのタイミングで手を組んだのか。そこには業界全体が抱える切実な課題がある。 AIエージェントは「次世代の主役」と長らく期待されてきたが、現実の評判は芳しくない。ハーバード・ビジネス・レビューも指摘するように、特に顧客対応の場面では「エージェントが期待どおりに完遂できない」事例が続発している。ハルシネーション（幻覚生成）の問題はまだ解消されておらず、一般ユーザーの基本タスクへの期待を裏切ることへの耐性は極めて低い。 それでもAIエージェントへの投資は続く。主要各社が「次はエージェントだ」と宣言している以上、そのレールを整備するインフラ——つまり共通の標準——が急務になっている。これが今回の連合誕生の背景だ。 3つの基盤ツールが業界標準の核心に Alliance発足に際し、最初に取り組む成果物として3つのオープンソースツールが挙げられている。 MCP（Model Context Protocol） Anthropicが開発した、AIエージェントと外部アプリケーションをつなぐ接続標準。ChatGPTを企業のSlackに接続して会話を要約させるような用途がすでに現実のものとなっており、OpenAI・Microsoft・Google・Cursorなど幅広い環境で採用が進んでいる。 ただし、IT管理者の間ではセキュリティへの懸念が高まっている。特に「プロンプトインジェクション攻撃」——悪意ある入力によってエージェントを乗っ取ろうとする攻撃——は現時点で深刻なリスクとされており、脆弱性発見から修正までの合意形成プロセスの標準化が急がれている。 Agents.md OpenAIが整備した、コーディングエージェントへの指示フォーマット。人間がドキュメントを読むように、エージェントがリポジトリの文脈や作業ルールを理解するための約束事を定義する仕組みだ。開発現場での実用性は高く、標準化によって異なるエージェント間の互換性が高まることが期待される。 Goose（Block製） ネットワーク接続なしにローカル環境で動くオープンソースのAIエージェント。クラウドに依存しない自律実行基盤として注目されており、特にプライバシー要件が厳しい環境や、オフライン実行が求められる場面での活用が見込まれる。 実務への影響——日本のエンジニア・IT管理者はどう動くべきか ① MCP対応は今すぐ視野に入れよ MCPはすでに主要プラットフォームへの採用が進んでいる。「様子見」をしているうちに、対応済みのツール・サービスが当たり前になる速度は想像以上に速い。自社のSaaSとAIエージェントをどう連携させるか、今から設計を始める価値がある。 ② セキュリティ評価をエージェント導入と同時に行え MCPのプロンプトインジェクション問題は、日本企業でも他人事ではない。エージェントに外部ツールへのアクセス権を与える構成では、入力検証とアクセス制御の設計が必須。「エージェントを入れたはいいが脆弱性だらけ」という事態を避けるため、導入前にセキュリティ評価を組み込む体制を整えておきたい。 ③ Agents.mdの思想をチームに取り込め 「エージェントがリポジトリのルールを自律的に読んで動く」という設計思想は、今後のソフトウェア開発の常識になっていく可能性が高い。CLAUDE.md・Agents.mdのような「エージェント向けドキュメント」をリポジトリに置く習慣を、今から始めておくと後からスムーズに乗り換えられる。 ④ ローカル実行の選択肢を持っておけ Gooseのようなオフライン動作エージェントの標準化は、クラウドに情報を出せない医療・金融・行政分野にとって福音になりうる。業界規制の厳しい組織ほど、ローカルエージェントの動向を追っておく意味がある。 筆者の見解 今回の連合結成は、AIエージェント業界が「戦国時代の乱立」から「インフラとしての成熟期」へ移行するための重要な一手だと受け止めている。 面白いのは、MCP・Agents.md・Gooseという3ツールの選定だ。それぞれが「エージェントをつなぐ」「エージェントに文脈を与える」「エージェントをローカルで動かす」という異なるレイヤーをカバーしており、これを束ねることで「エージェントが自律的にループで動き続ける仕組み」——いわゆるハーネスループ——の基盤が整う設計になっている。単発の指示に応答するアシスタント型ではなく、判断・実行・検証を繰り返す自律エージェントをまともに動かすために必要な土台が、今まさに業界全体で整備されようとしている。 Microsoftへの期待という観点では、同社がこの連合に参加したこと自体は評価したい。標準化の文脈でLinux Foundationを軸に動くのは、オープン戦略の観点から理にかなっている。ただ、MCPの採用はすでに進んでいるのに、Copilotがこのエコシステムの恩恵をどこまで享受できるか——そこはまだ見えていない。持っているブランドとユーザーベースを活かして、エージェント体験の最前線に立てる力は十分あるはずだ。その潜在力が、標準化という後押しを得てどこまで本領発揮できるか。今後の動きを注視したい。 AIエージェント標準化の本当の意義は「どの企業のエージェントを選んでも、同じ文脈で、同じ安全性で、同じ相互接続性が得られる世界」を作ることだ。その世界が実現すれば、企業のIT担当者がエージェント導入を「特定ベンダーへの賭け」ではなく「インフラの選択」として扱えるようになる。日本のIT現場にとっても、それは歓迎すべき変化のはずだ。 出典: この記事は Microsoft, Google, OpenAI, and Anthropic join forces to form Agentic AI Alliance の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが静かに、しかし重大な一手を打った。自社開発の基盤AIモデル3本——音声認識のMAI-Transcribe-1、音声合成のMAI-Voice-1、画像生成のMAI-Image-2——をMicrosoft Foundry経由でリリースしたのだ。ことさら派手な発表はなかったが、その内容はOpenAIやGoogleへの明確な対抗宣言と読み取れる。 何が変わったのか——「OEM依存」から「自社開発」へのシフト Microsoftはこれまで、AI基盤の多くをOpenAIのモデル群に依存してきた。GPT-4を自社サービスに組み込む形で「Copilot」ブランドを展開し、Azure OpenAI Serviceを通じてエンタープライズに提供する——そのビジネスモデルが中心だった。 今回のリリースはそこからの脱却を意味する。自社モデルを持つことで、OpenAIとの契約に縛られない独自のロードマップを歩み始めた形だ。OpenAIとの資本関係が複雑さを増すなか、この動きはタイミングとしても示唆深い。 MAI-Transcribe-1の意義——Whisperを全25言語で上回る 今回の3モデルの中で最も技術的に注目すべきはMAI-Transcribe-1だ。OpenAIが公開しているWhisper-large-v3は、音声認識モデルとして広く使われているデファクトスタンダードの一つだが、MicrosoftはMAI-Transcribe-1がこれを全25評価言語で上回る精度を達成したと主張している。 日本語も対象言語に含まれており、日本語の音声認識精度が改善されることで、日本語コンテンツへの適用可能性が広がる。字幕生成、議事録作成、コールセンター音声解析——実務でのユースケースは枚挙にいとまがない。 MAI-Voice-1は音声合成（TTS）のモデルで、自然な音声生成に特化している。MAI-Image-2は画像生成モデルとして位置付けられ、既存のDALL-Eラインとの棲み分けが今後どうなるかも注目点だ。 Microsoft Foundryとは何か これらのモデルが提供されるプラットフォーム「Microsoft Foundry」は、Azureを基盤としたAIモデル・ハブだ。従来のAzure AI Studioを発展させたもので、サードパーティを含む多様なモデルをAPIで呼び出せる設計になっている。 自社モデルをFoundryに並べることで、Microsoftは「自社製かサードパーティ製かを問わず、最適なモデルを選んで使えるワンストップ環境」を整えようとしている。開発者がAWSやGoogle CloudではなくAzureに留まる理由を増やす戦略でもある。 実務への影響——日本のエンジニア・IT管理者にとって 音声認識システムの刷新を検討するタイミング コールセンターや会議録音、テレワーク議事録など、音声をテキスト化する業務はすでに広く普及している。現行システムがWhisperベースやAzure Speech Servicesベースであれば、MAI-Transcribe-1への切り替えによる精度向上の恩恵を受けられる可能性が高い。Azureを使っている組織であれば、追加の認証やインフラ変更なしにFoundry経由で試せる点も実用的だ。 マルチモーダルパイプラインの設計に 音声入力→テキスト変換→画像生成といったマルチモーダルなパイプラインを構築するとき、今後はMicrosoftのファーストパーティモデルだけで一連の処理を完結させられるようになる。ベンダーを跨いだAPIキー管理やレイテンシの問題が軽減できる。 コスト・ガバナンスの観点で 自社モデルの強みの一つはコスト設計の自由度だ。Microsoftは今後、Foundry上の自社モデルに競争力のある価格をつけてくることが予想される。エンタープライズ契約でのコスト予測が立てやすくなる可能性もある。 筆者の見解 率直に言おう。このリリースはMicrosoftが正面から勝負する意志を示したものとして評価したい。 ここ数年のCopilotをめぐる混乱——方向感の見えにくさ、競合との体験差——を見てきた者として、「自社で基盤から作る」という判断には素直に期待感を持った。MicrosoftはAzure、M365、Windows、GitHub——これだけの資産とエンタープライズとの信頼関係を持っている。自社モデルを磨き上げる基盤がない会社ではない。だからこそ、「なぜもっと早くやらなかったのか」という気持ちはあるが、いまからでも遅くない。 もちろん「Whisperより精度が高い」という主張は独立した検証が必要で、現時点では自己申告の域を出ない。実際にベンチマークを回して検証するのが次のステップだ。日本語の認識精度については、ぜひ自分の手で確かめてみてほしい。 一方で気になる点もある。今回のリリースが「競合へのカウンター」として設計されたとすれば、それは正しい方向だ。しかし、Microsoftの本来の強みは「競合を意識した単点勝負」ではなく、「全体をつなぐ統合プラットフォームの総合力」にある。Foundryが単なるモデル置き場に終わらず、Azure全体の知識・データ・ワークフローと有機的に結びつく設計に育っていくか——そこが真価を問う分岐点になると見ている。 Microsoftには、まだやれる力がある。このリリースがその証左の一つとなることを期待したい。 出典: この記事は Microsoft launches 3 new AI models in direct shot at OpenAI and Google の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilot Researcherに「Critique Mode（批評モード）」が追加された。AIが自身の調査結果を自己評価・改善するこの機能は、エンタープライズ向けリサーチワークフローに実質的な価値をもたらす可能性を持つ。一見地味なアップデートだが、その意味合いは小さくない。 Critique Modeとは何か Critique Modeは、Copilot Researcherが生成したリサーチ結果に対して「自分自身で批評・検証し、出力を改善する」プロセスを組み込んだ機能だ。 従来のAIリサーチツールは、一度生成した結果をそのまま出力するパターンが多かった。しかしCritique Modeでは、生成後に自己評価のループを設けることで、内容の網羅性・一貫性・根拠の強さを内部でチェックしてから最終出力を返す設計になっている。 これはAI分野で「Self-Critique」または「Reflection」と呼ばれる手法の応用だ。単純な一回生成より精度が上がることは多くの研究で示されており、Microsoftがこのアプローチをエンタープライズ製品に正式統合したことは技術的な進歩として評価できる。 エンタープライズ利用での具体的な変化 リサーチ業務における典型的な課題は「AIが自信満々に不完全な情報を返す」点だ。特に複数の情報源を統合するような複雑な調査では、論点の抜け漏れや根拠の薄い結論が混入しやすい。 Critique Modeはこの問題にアプローチする。市場調査、競合分析、技術評価レポートなど、深い洞察が求められる業務においてアウトプットの品質底上げが期待できる。 実務への影響 日本のエンタープライズ環境でM365 Copilotを活用している組織にとって、実務上の活用ポイントをいくつか挙げておきたい。 活用が期待できるシナリオ 経営層向けの市場動向・競合環境レポート作成 新技術・製品の比較調査と採用判断の補助 規制・コンプライアンス要件の調査整理 運用上の注意点 Critique Modeが有効でも、最終的な検証は人間が担う必要がある。自己評価ループはあくまで品質向上の補助であり、ファクトチェックの代替ではない。また、データソースの品質に依存することは変わらないため、社内ナレッジとの連携設定が実運用の肝になる。 ライセンス面では、Copilot機能はMicrosoft 365 E3/E5に対してアドオンとして追加する形態が多い。既存のMicrosoft 365環境を持つ組織はライセンス構成を確認した上で活用計画を立てると良いだろう。 筆者の見解 Critique Modeの追加は、Copilotの進化方向として「正しい一手」だと率直に思う。 以前からCopilotのリサーチ機能には「もう一段階踏み込んでほしい」という声が多かった。一次情報を収集してまとめるだけであれば、他の選択肢でも十分実現できる。エンタープライズが本当に求めているのは、情報の取捨選択と論理的な精査を伴った「考えるリサーチ」だ。Critique Modeはその方向への一歩として評価できる。 Microsoftはエンタープライズ向けに必要なセキュリティ・コンプライアンス・他サービスとの統合性という、競合がそう簡単には追いつけない基盤を持っている。その強みの上でAIの精度と信頼性を積み上げていく戦略は、本来の持ち味に合致している。正面から勝負できる力があるのだから、そこに集中していってほしいと思う。 もちろん、一機能の追加で全てが変わるわけではない。「これなら信頼できる」と現場が感じる体験が積み重なることこそが、真の価値証明だ。今後のアップデートを引き続き注目して追いかけたい。 出典: この記事は Microsoft Upgrades 365 Copilot Researcher With New Critique Mode の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ファイルを外部に共有する前に、うっかり混入したAPIキーやパスワードを検出する——。そんなシンプルかつ重要な目的のCLIツール「scan-for-secrets」が、バージョン0.2へとアップデートされた。開発者Simon Willisonによるリリースで、大規模ディレクトリへの対応強化とPython APIの追加が目玉だ。AIエージェントやCI/CDパイプラインへの組み込みを見据えた設計が随所に見える。 バージョン0.2の主な変更点 最も注目すべき変更はストリーミング出力への対応だ。従来は全ファイルのスキャンが終わるまで結果が表示されなかったが、0.2からは発見次第リアルタイムで出力される。数千ファイルを抱えるモノリポやレガシーコードベースをスキャンする際、途中で止めて対応できるようになり、実際の開発現場での使い勝手が格段に上がる。 -d/--directoryオプションの複数指定も地味に便利だ。フロントエンドとバックエンドのリポジトリを別ディレクトリで管理しているチームは多いが、これまでは個別に実行する必要があった。複数ディレクトリをまとめてスキャンできることで、リリース前の最終チェックをスクリプト一発で完結させられる。 個別ファイル指定の**-f/--fileオプション**は、Gitのpre-commitフックとの組み合わせで威力を発揮する。コミット対象ファイルだけをピンポイントで検査するフローが簡単に組めるようになった。 Python APIとしてはscan_directory_iter()・scan_file()・scan_file_iter()の3関数が追加された。CLIとしての利用に留まらず、Pythonスクリプトや自動化ツールから組み込める設計は、AIエージェントのツールとして呼び出すユースケースも意識しているように見える。 実務での活用ポイント pre-commitフックへの組み込みが最もすぐに試せる活用法だ。.git/hooks/pre-commitに以下のような記述を追加するだけで、コミット時に自動検査が走る： 出典: この記事は scan-for-secrets 0.2 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIが自分自身をテストする——SFのような話が、実際のプロダクト開発の現場に入り込み始めている。AIスタートアップのImbueが公開したケーススタディは、エージェントオーケストレーションツール「mngr」を使って100体以上のエージェントを並列実行し、mngr自体のデモスクリプトをテストするという、再帰的な自己改善ループの実装例だ。「エージェントをどう動かすか」という議論が活発になる中、具体的なアーキテクチャと知見を惜しみなく公開したこの事例は、今後の設計思想に大きな示唆を与えてくれる。 システム全体像：4ステップの自律ループ Imbueのアプローチはシンプルな4ステップで構成されている。 チュートリアルスクリプト（tutorial.sh）の作成：コマンド群をブロック単位で記述 pytestへの変換：各ブロックから複数のテスト関数を生成（1:N対応） エージェントの並列起動：各テスト関数に対してエージェントを1体割り当て、実行・デバッグ・修正を自律的に実施 成果の統合：全エージェントの実行結果をまとめて反映 注目すべきは「1:N対応」の設計思想だ。チュートリアルのコマンドブロック1つから、正常系・異常系を含む複数のテストケースを生成する。環境やコマンドのわずかな違いで異なる挙動になりうる場合は、それぞれ独立したテストケースとして記述する徹底ぶりだ。 また、テスト関数が「どのチュートリアルブロックに対応しているか」をコード内で宣言させ、スクリプトで整合性を検証する仕組みも設けている。エージェントに「誠実な出力」を促す仕掛けとして興味深い。 「失敗」が設計改善のシグナルになる逆転の発想 このシステムで得られた副産物が、非常に示唆深い。エージェントがチュートリアル例をうまく生成できない場合、それ自体がインターフェース設計の問題を示すフィードバックになるという発見だ。 「エージェントが例を作れない = 人間にとっても使いにくい」 通常のCI/CDではテスト失敗は「バグ」を意味する。しかしこのシステムでは「エージェントが理解できない = 設計が複雑すぎる」という設計品質の指標にもなっている。AIエージェントをユーザーの模擬として機能させるという、新しいUXリサーチの形とも言える。 テストの3フェーズに存在する固有の難しさ エンドツーエンドテストの構造——Arrange（準備）・Act（実行）・Assert（検証）——それぞれに固有の緊張関係があることも正直に認めている。 Arrange：実世界に近いシナリオにしたいが、テストの独立性も保ちたい Act：チュートリアルと同じコマンドを使いたいが、テスト適用のために変形が必要になる Assert：効果を正確に検証したいが、ファイル内容を厳密すぎると脆いテストになる これはAIエージェントに限らず、人間がエンドツーエンドテストを書く際にも直面する普遍的な問題だ。エージェントが最初のステップで不完全なテストしか書けなくても問題ない——重要なのは次のステップで改善されること、つまりループが機能することだ、という設計姿勢が一貫している。 テスト基盤はPythonのsubprocessモジュールを核とした薄いユーティリティ層で構成されており、複雑なフレームワークへの依存を避けているのも特徴的だ。 実務への影響——日本のエンジニアが明日から活かせること まずは「テスト記述の一部をエージェントに任せる」から始める 100体のエージェントを即座に並列実行する必要はない。人間が書いたチュートリアルやドキュメントを入力として与え、エージェントにテストケースのドラフトを生成させるところから始めてみることだ。完璧でなくていい——不完全な出力こそが設計見直しのヒントになる。 「悪い出力は失敗ではなくフィードバック」という視点転換 AIに作業を任せてうまくいかない場合、「AIが使えない」で終わらせるのはもったいない。「なぜうまくいかなかったか」を分析すると、人間にとっても不明確だった仕様や設計の問題が浮き彫りになることがある。これは特にドキュメント整備が後手に回りがちな日本の現場で有効な逆転の視点だ。 エージェントのスケールアウトを前提とした設計を意識する 並列実行を前提とすると、べき等性・状態管理・成果の統合方法を自然と考えることになる。これは従来のクラウドネイティブ設計の知見が直接活きる領域だ。既存のインフラ知識が無駄にならない。 筆者の見解 このケーススタディが示しているのは、「AIに仕事を頼む」という段階から「AIが自律的にループで動き続ける仕組みを設計する」という段階へのシフトだ。 多くの組織では、AIをまだ「質問に答えてくれるアシスタント」として活用している段階だと思う。しかし本当に生産性の限界を突破するには、エージェントが自分で判断・実行・検証を繰り返すループを設計できるかどうかが鍵になる。 Imbueの事例で特に印象的だったのは、「システムが自分自身をテストする」という再帰的な構造だ。テストを書くために人間が逐一介在しない。エージェントが書いたテストをエージェントが実行し、失敗から得たシグナルをシステム設計にフィードバックする。これは単なる効率化ではなく、開発プロセスそのものの再設計だ。 100体超の並列実行はすぐに真似できるものではないかもしれない。しかし「ループで動き続けるエージェントをどう設計するか」という問いは、今すぐ考え始めるべきテーマだと感じている。次の1〜2年で、この設計思想を持つ組織とそうでない組織の間に、埋めがたい差が生まれると思う。ツールの使い方より、ループをどう設計するかに知恵を使おう。 出典: この記事は A case study in testing with 100+ Claude agents in parallel の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIが「被害者」を「加害者」に仕立てた——著作権の逆転劇 AIが音楽アーティストの楽曲ファイルをコピーして学習し、その後そのアーティスト自身に対して著作権侵害を申し立てるという、前代未聞の事態が発生した。技術的には可能であっても、倫理的・法的にありえないと思われてきた「逆転著作権侵害申立」が現実になりつつある。 単なる皮肉な一件として片付けることはできない。この事例は、AIと著作権をめぐる構造的な問題の象徴として、法律家・エンジニア・コンテンツクリエイターの三者に深刻な問いを投げかけている。 何が起きたのか 報告されている構図はこうだ。 あるAIシステム（または関連企業）がアーティストの音楽ファイルを無断でコピー・学習に使用 そのAIが生成した楽曲、あるいはAI側のなんらかの成果物を根拠に、逆に元のアーティストに対して著作権侵害の申し立てを行った 詳細な経緯は現時点で確認中の部分もあるが、Hacker Newsでは56ポイントを集め活発な議論が起きており、「これは氷山の一角にすぎない」との声も多い。 なぜこれが起きてしまうのか——仕組みの問題 現行のデジタルコンテンツ著作権申立の仕組み（YouTubeのContent IDなど）は、申立の「正しさ」よりも「一致の技術的証拠」を優先する設計になっている。 コンテンツの指紋（フィンガープリント）照合は自動化されており、申立主体が人間かAIかを問わない 申立された側は異議申し立てを行う手間と時間を強いられる 悪意ある（あるいは無自覚な）申立であっても、システム上は等価に処理される AIが大量のコンテンツを学習し、そのパターンを再現した成果物を生成する場合、フィンガープリントが元データと「類似」していると判定されるケースが出てくる。そこに著作権申立の自動化が組み合わさると、今回のような逆転劇が技術的に成立してしまう。 実務への影響——エンジニア・IT管理者が今すぐ確認すべきこと 生成AIを使ってコンテンツを生成・公開している組織へ 出力物の著作権リスク評価を行う: 生成AIが学習データから過学習した結果、既存著作物と類似したコンテンツを生成していないか定期的に確認する 著作権申立プロセスの文書化: 万が一申し立てを受けた際に、AI生成であることを証明できる記録（プロンプト・生成日時・使用モデル）を保持する 利用規約・ライセンス確認の徹底: 特に音楽・画像・映像を学習に使う場合、利用元のライセンス条件を必ず確認する クリエイター・コンテンツオーナーへ 自分の著作物の監視を強化: Content IDや類似サービスへの登録、定期的な模倣検索を実施する AIによる申し立てへの異議手順を事前準備: 大手プラットフォームの異議申し立てフローを把握しておく 法的・制度的な空白地帯 日本でも2023年の著作権法改正によりAI学習目的の複製は一定条件下で認められているが、学習済みモデルが生成した成果物の権利帰属については明確な判例が積み上がっていない。欧米も同様で、法整備が技術の速度に追いついていない。 今回の事例が示すのは、「AIが著作権を侵害する」という従来の懸念にとどまらず、「AIが著作権を武器として行使する」 という次のフェーズの問題だ。 筆者の見解 この件を「AIが悪いことをした面白エピソード」として消費するのは勿体ない。本質はプラットフォームの設計にある。 著作権申立の自動処理システムは「申立主体の正当性」ではなく「技術的一致」を根拠に動く。そこにAIという大量生成主体が組み込まれたとき、制度が意図していなかった逆転現象が起きる。 AIエージェントが自律的に動き、人間の確認なしにアクションを起こす世界——これはまさに私が注目しているハーネスループ的な自律動作の拡大と表裏一体だ。自律性が高まるほど、その動作が正当かどうかを監視・制御する仕組みが同時に必要になる。「AIが動ける」と「AIが正しく動く」は別の話だ。 クリエイターを守るプラットフォームが、図らずもクリエイターを傷つける側に回ってしまっている。これは技術の問題ではなく制度設計の問題であり、プラットフォーム企業が真剣に向き合うべきフェーズに来ている。 今後、AIによる著作権申立の急増は避けられないだろう。正直なところ、現行の仕組みは「AIが申立人になる未来」を想定して設計されていない。法整備とプラットフォーム側の対応が追いつかないまま被害者が増えることを、今から懸念している。 出典: この記事は AI that copied musical artist files copyright claim against artist [updated] の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Copilotが「フルEdge同梱」アプリとして再登場 Microsoftが Windows 11 向けに新しい Copilot アプリを展開し始めた。見た目は web.copilot.com とほぼ同一で、動作は滑らか。しかしその裏側を覗いてみると、なかなか驚くべき構成になっている。 アプリのインストールフォルダに 146.0.3856.97 というディレクトリが存在し、中身はほぼ完全な Microsoft Edge のインストールセット——msedge.exe、msedge.dll（315MB）、ffmpeg.dll、Vulkan/SwiftShader、WidevineCDM など、フル Chromium ブラウザエンジンが丸ごと格納されている。合計サイズは約 850MB だ。 仕組みとしては「Edge のフォーク版を WebView2 コンテナ内で専用アプリとして動かすハイブリッド構成」と整理できる。標準的な WebView2 や PWA であれば Windows 11 側に既にある Edge を共用するところを、Copilot は自前の Edge インスタンスを抱え込んで起動する形になっている。 メモリ使用量の現実 状態 RAM使用量 バックグラウンド（新版） 最大 500MB 操作時（新版） 最大 1GB 従来のネイティブ版 100MB 未満 単純比較で 10 倍以上のメモリを消費する計算だ。8GB 搭載マシンでは体感にも影響しうる数字である。 アーキテクチャ遍歴——4回目の設計変更 これが初めての方針転換であれば「戦略的な判断」で済む話だが、経緯を振り返るとそうとも言いにくい。 サイドバー統合型 Copilot（初期） PWA（Progressive Web App） WebView ベース ネイティブ WinUI アプリ（前バージョン） Edge 同梱ハイブリッド Web アプリ（今回）← ネイティブコードへの回帰から1年も経たないうちに、再び Web 技術主体の構成へ戻っている。インストール手順も Microsoft Edge インストーラーと同様の方式に変わり、Microsoft Store 経由でありながら「別ウィンドウで操作が必要」という警告が出る仕様になった。Microsoft Teams の配布方式と同じアプローチだ。 ...

クラウドで削除したらどこへ行くのか、がついに統一される 長年にわたって「地味に混乱を招いてきた」OneDriveの削除動作が、2026年5月に変わる。これまで、別のデバイスやWebブラウザーからOneDrive上のファイルを削除した場合、そのファイルがPC側のローカルごみ箱に送られることがあった。今後はこの挙動が廃止され、クラウド側で削除されたファイルはOneDriveのクラウドごみ箱のみに保持される仕組みに統一される。 Microsoftが発表したこの変更は、OneDriveの同期エンジンの根幹に関わるものだ。一見すると「ローカルの保護が薄くなった」ように映るが、実態は逆で、動作の整合性が高まったと見るべきだろう。 何がどう変わるのか 従来の動作 OneDriveの同期フォルダーに保存されたファイルを、Web UIや別のデバイスから削除した場合、同期によってローカルの実体ファイルも削除されるが、そのファイルはPC側のローカルごみ箱にも送られていた。つまり、ユーザーは次の2か所でファイルを復元できる状態だった。 OneDriveクラウドごみ箱（30日間保持） ローカルのごみ箱（ユーザーが明示的に空にするまで残る） 変更後の動作 2026年5月以降、クラウド側の操作で削除されたファイルはローカルごみ箱には送られない。復元先はOneDriveクラウドごみ箱のみとなる。ローカルで直接削除（Explorerで選んでDeleteキーを押す等）した場合は引き続きローカルごみ箱に送られる。 「ローカルの安全網がなくなる」は誤解 この変更を見て「危険になった」と感じる人もいるかもしれないが、それは誤解だ。OneDriveのクラウドごみ箱は、個人アカウントで削除後30日間、Microsoft 365 Business/Enterpriseでは最大93日間、ファイルを保持する。これは十分な猶予期間といえる。 むしろ整理すべきは「作り手の意図」だ。OneDriveはクラウドファーストのサービスとして設計されている。クラウドで削除したものはクラウドで管理する、という考え方は一貫しており、今回の変更はその設計思想への回帰だ。ローカルごみ箱を「第2の復元ポイント」として暗黙的に当てにしていた構成は、本来の使い方ではなかった。 実務への影響：IT管理者が今すぐやるべきこと エンドユーザーへの周知が最重要 最も対応が必要なのはエンドユーザーへの啓発だ。「ごみ箱に入ってるはず」と思ってローカルのごみ箱を確認して見つからず、パニックになるケースが増えることが予想される。「クラウドから消したらOneDriveのごみ箱を確認してください」 という一行の周知文でも、ヘルプデスクへの問い合わせを大幅に減らせる。 復元手順のドキュメント更新 社内のファイル復元手順書やFAQにOneDriveクラウドごみ箱の操作方法を追記しておこう。Web版OneDrive（onedrive.com）からごみ箱にアクセスする方法、OneDriveアプリから「ごみ箱を表示」する手順を具体的に示しておくと親切だ。 管理者はごみ箱の保持期間を確認 Microsoft 365管理センターでは、SharePoint/OneDriveのごみ箱保持期間を確認・変更できる。組織のデータ保全ポリシーと照らし合わせ、30日では不足するケースがないか確認しておきたい。コンプライアンス要件が厳しい業種では、Microsoft Purviewのアイテム保持ポリシーと組み合わせることで、さらに長期間の保護が実現できる。 筆者の見解 この変更の方向性は正しいと思う。OneDriveはずっと「クラウドが正」という設計で動いてきたのに、削除動作だけローカルにも副作用を出していたのは、明らかに設計の揺らぎだった。今回の統一化は、その揺らぎを解消するものとして歓迎したい。 ただし、今回改めて考えさせられるのは「OneDriveを正しく理解して使っているユーザーがどれだけいるか」という問題だ。同期フォルダーとクラウドストレージの違い、ファイルオンデマンドの仕組み、削除の伝播——これらをきちんと理解してOneDriveを運用している企業は、体感としてまだ少ない。 「作り手の意図を理解し、意図された使い方をする」。これはOneDriveに限らず、クラウドサービス全般に通じる原則だ。5月の変更を機に、自社のOneDrive利用実態を一度棚卸しする良いきっかけにしてほしい。管理者が能動的に動けるかどうかが、現場の混乱の大きさを左右する。 Microsoftがこうした地道な整合性改善を続けている点は、きちんと評価したい。派手さはないが、長く使われるプロダクトはこういった細部の積み重ねで成熟していく。 出典: この記事は Microsoft to stop sending cloud-deleted OneDrive files to local Recycle Bin の内容をもとに、筆者の見解を加えて独自に執筆したものです。