Tech News JP

AIエージェントを業務で使い始めると、必ず壁にぶつかる。セッションをまたいだ瞬間、エージェントは何も覚えていない。同じミスを繰り返す。ツールを変えれば文脈がゼロリセットされる。この「記憶断絶」問題に、生物学的着想で挑むOSSライブラリ「Hippo」がHacker Newsで注目を集めた。 「もっと覚えさせる」では解決しない Hippoのコア思想は一言で表せる。「記憶の秘訣は、より多く覚えることではない。何を忘れるかを知ることだ」。 既存のアプローチは「とにかく全部保存してあとで検索」が主流だ。しかしそれはファイリングキャビネットであって、脳ではない。情報量が増えるほど検索ノイズも増え、本当に必要な文脈が埋もれていく。 Hippoは生物の海馬（hippocampus）から名前を取り、記憶の「強化・固定・減衰」というサイクルを模倣する。重要度の高い記憶は固定化され、使われない記憶は自動的に減衰する。エラー記憶には高い持続性を与え、過去の失敗が繰り返されにくい設計になっている。 主な技術的特徴 ストレージとポータビリティ SQLiteをバックボーンとし、マークダウン・YAMLでミラーリング。Gitで追跡可能で人間が読める形式を維持する。ChatGPT・Claude・Cursorからのインポートに対応しており、ツール間の記憶断絶を解消する「共通メモリ層」として機能する。 ハイブリッド検索（v0.8.0〜） BM25キーワード検索とコサイン類似度ベクトル検索を組み合わせたハイブリッドサーチを実装。@xenova/transformersを導入してembeddingを生成すると精度が向上し、なければBM25にフォールバックする。 ワーキングメモリとセッション引き継ぎ（v0.9.0〜） 最大20件の有界バッファとして動作する「ワーキングメモリ層」と、セッション終了時にサマリー・次アクション・成果物を永続化する「セッションハンドオフ」機能を追加。後続セッションがトランスクリプトを掘り返さずに文脈を復元できる。 自動スリープ（v0.9.1〜） hippo hook install claude-codeを実行すると、エージェント終了時に自動でHippoのスリープが走る。cronも手動呼び出しも不要。 ベンチマーク結果 公開されたエージェント評価では、Hippoを使用したエージェントが50タスクシーケンスを通じて「過去のトラップ」に引っかかる率を78%から14%まで低減している。 実務への影響 日本のエンジニアにとって最も即効性があるのは、マルチツール開発環境でのコンテキスト継続だろう。 月曜はClaudeベースのエージェントで設計検討、火曜はCursorでコーディング、水曜はCodex系でテスト——このような現実のワークフローでは、ツールをまたぐたびに文脈の再共有コストが発生している。Hippoはこの問題に対して、ベンダーロックインなしの共通レイヤーという解を提示する。 またCLAUDE.mdやcursorrulesが数百行に膨れ上がった経験を持つエンジニアも多いはずだ。タグ・信頼度レベル・自動減衰による構造化は、ルールファイルの管理コストを大幅に削減できる可能性がある。 導入の敷居も低い。Node.js 22.5以上があればゼロランタイム依存で動作し、npm install -g hippo-memory && hippo initの2コマンドで開始できる。 筆者の見解 AIエージェントの分野で長らく軽視されてきた問題が「記憶の設計」だと筆者は感じている。多くの実装が「とりあえず全部渡す」か「毎回ゼロから始める」の二択で済ませてきた。その結果、エージェントは同じ落とし穴を繰り返し、ユーザーはその都度説明し直す負担を強いられてきた。 Hippoのアプローチが示唆するのは、エージェントの自律性は「記憶の質」に直接依存するという視点だ。目的を伝えれば自律的にタスクをこなせる本物のエージェントを実現するためには、単発の指示と応答を繰り返すだけでなく、判断・実行・検証を自己ループさせる仕組みが要る。その仕組みの核となるのが、セッションをまたいで劣化しない記憶基盤だ。 OSSとして公開され、SQLite＋マークダウンで完全に手元管理できる点も評価したい。クラウドサービスに記憶を預けることへの不安がある企業環境では、このポータブル設計は現実的な選択肢になりうる。 v0.9台という成熟途上のライブラリではあるが、「賢い忘却」という設計思想は今後のエージェント開発における重要な参照点になると考える。エージェントに長期記憶を持たせることを検討しているエンジニアは、一度試してみる価値がある。 出典: この記事は Show HN: Hippo, biologically inspired memory for AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GPU Rowhammerという攻撃手法が、データ破壊にとどまらず完全なシステム乗っ取りにまで到達することが実証された。トロント大学の研究チームが発表した「GPUBreach」は、GDDR6メモリへのRowhammer誘発bit flipを起点に特権昇格からrootシェル取得まで至る攻撃チェーンを示すもので、4月13日に開催されるIEEEシンポジウム Security & Privacyで全詳細が公開される。AIトレーニングや推論ワークロードで広く使われるGPUがターゲットになりうるという点で、日本のエンジニアも無視できない内容だ。 GPUBreach の仕組み——ページテーブル破壊からドライバ脆弱性へのチェーン Rowhammer攻撃とは、メモリセルに隣接する行へ高速に繰り返しアクセスし、電気的干渉によって意図しないビット反転（bit flip）を引き起こす手法だ。DRAMではかつてから知られていたが、近年は GPU の GDDR6 メモリにも適用可能であることが示されてきた。 GPUBreach はその延長線上にある。研究チームは GDDR6 上で Rowhammer 誘発 bit flip を起こし、GPU のページテーブル（PTE）を破壊することに成功した。これにより、非特権 CUDA カーネルが任意の GPU メモリへの読み書きアクセスを奪取できる状態になる。 さらにそこで終わらない。この GPU メモリアクセス能力を足がかりに、NVIDIA ドライバに存在するメモリ安全性のバグをチェーンして CPU 側への権限昇格まで到達。最終的に root シェルを取得できることが実証された環境は NVIDIA RTX A6000——AI 開発・学習用途で広く採用されるモデルだ。 IOMMU 保護が機能しない点が最大の驚き DMA（Direct Memory Access）攻撃への主要な防御策として、多くの組織のセキュリティ設計で信頼されてきたのが IOMMU（Input-Output Memory Management Unit） だ。デバイスがアクセスできるメモリ領域をハードウェアレベルで制限する仕組みで、「これがあれば安全」と前提にしているケースは少なくない。 GPUBreach は IOMMU が有効な状態のまま攻撃が成立する。GPU が制御するメモリがドライバの信頼された状態を破壊できる以上、IOMMU 単体での防御は不十分と研究チームは明言している。 ECC 非搭載のコンシューマ GPU は現状で完全に無防備 研究者は NVIDIA・Google・AWS・Microsoft へ 2025 年 11 月 11 日に報告済みだ。NVIDIA はエンタープライズ向けにシステムレベル ECC（Error Correcting Code）の有効化を推奨しており、Hopper および Blackwell アーキテクチャのデータセンター向け GPU ではデフォルト有効になっている。 ...

ドイツ連邦警察（BKA）が、GandCrabおよびREvil（別名：Sodinokibi）というふたつの大型ランサムウェアグループの首謀者を特定した。いずれもロシア国籍で、31歳のダニイル・シュチュキン（別名：UNKN/UNKNOWN）と43歳のアナトリー・クラフチュクの2名だ。2019年初頭から2021年7月まで、両グループを率いてドイツ国内だけで130件以上の恐喝事件を引き起こし、被害総額は4000万ドルを超えるとされている。 GandCrabからREvil——ランサムウェア「業界」の継承構造 GandCrabは2018年初頭に登場し、わずか1年半で2億ドルの稼ぎを主張して「引退宣言」を行った異色のグループだ。リーダーは1億5000万ドルを合法的ビジネスに投資したと述べ、表向きは活動を終えた。 しかしその後すぐに登場したのがREvil（Sodinokibi）だ。GandCrabの元アフィリエイト（加盟者）や運営者が戦術をそのまま引き継ぎ、さらに「リークサイト」や「データオークション」という新たな脅迫手法を加えて進化させた。注目すべき被害事例はテキサス州複数自治体、PC大手Acer、そして約1,500社以上に波及したKaseyaサプライチェーン攻撃など、枚挙にいとまがない。 2022年初頭にロシアが複数のREvil構成員を逮捕したが、2025年には釈放されている。今回特定された2名の現在の動向は不明のままで、BKAはEUの指名手配ポータルへの掲載と、タトゥー写真を含む顔写真の公開によって情報提供を呼びかけている。 実務への影響——「犯人が誰か」より「仕組みがどう機能したか」を見よ この事件が示す最大の教訓は、RaaSモデル（Ransomware-as-a-Service）の強靭さだ。首謀者が逮捕または引退しても、アフィリエイトは戦術と道具を引き継いで次のグループを立ち上げる。今回のGandCrab→REvil継承がまさにその典型だった。 日本のIT管理者が明日から意識すべき実務ポイントは以下のとおりだ。 1. サプライチェーン攻撃への備えを最優先に Kaseya事件では直接の顧客だけでなく、MSPを経由した1,500社超が被害を受けた。自社が直接攻撃されなくても、利用しているSaaSやMSPが踏み台になるリスクを認識し、ベンダーのセキュリティ評価を定期的に実施すること。 2. 特権アクセスの「常時付与」をやめる REvil系の攻撃は、侵入後に特権アカウントを掌握して横展開するパターンが定石だ。Just-In-Time（JIT）アクセスを採用し、必要なときだけ必要な権限を付与する設計に切り替えることが、被害拡大を食い止める最前線になる。 3. バックアップ戦略の再検証 ランサムウェアはバックアップも狙う。オフラインバックアップ、またはイミュータブルストレージへの定期保存は、身代金交渉のテーブルに座らないための唯一の保険だ。 筆者の見解 正直に言えば、セキュリティ分野は細かい議論が多くて得意ではない。だが今回の件は技術的に非常に興味深い。 首謀者が特定された、というニュースは確かに意味がある。ただ、両者がロシアにいる限り実質的な逮捕・訴追は難しいのが現実だ。国際的なサイバー犯罪捜査は、政治的な対立構造の壁を越えられない場面が多い。「顔写真を公開して情報を求める」という段階にとどまっているのが現状を物語っている。 それ以上に重要なのは、RaaSという「フランチャイズモデル」が今も機能し続けているという事実だ。首謀者を追い詰めても、モデルそのものが生き残る。GandCrabがREvil に引き継がれたように、REvil以降もまた別の名前で同じ仕組みが動いている。 日本企業の現場では、「今は攻撃を受けていないから大丈夫」という空気がまだ根強い。しかし被害が表面化していないのと、対策が有効なのはまったく別の話だ。侵入はすでに起きていて、ただまだ発動していないだけかもしれない——そのくらいの前提で設計する姿勢が、これからのセキュリティには必要だと思っている。 出典: この記事は German authorities identify REvil and GandCrab ransomware bosses の内容をもとに、筆者の見解を加えて独自に執筆したものです。

現在あなたが使っているPCのCPUにも、スマートフォンのチップにも、データセンターのGPUにも、1世紀にわたって「なぜそうなるのか」が完全には解明されていなかった物理現象が潜んでいる。それが「量子トンネル効果」だ。今回、科学者たちはこの現象の根本的なメカニズムをついに解き明かした。 量子トンネル効果とは何か 古典物理学の世界では、ボールを壁に投げたらはね返るように、エネルギーが不十分な粒子は障壁を越えられない。これは直感と一致する。ところが量子力学の世界では、電子は「エネルギー的に越えられないはずの障壁」をすり抜けてしまうことがある。これが量子トンネル効果（Quantum Tunneling）だ。 1920年代に理論的に予測され、その後の実験でも観測されてきたが、「なぜ電子がそのタイミングで、その確率でトンネルするのか」という詳細なメカニズムについては長年にわたって議論が続いていた。今回の研究はその核心部分に迫るものだ。 現代チップとの直接的な関係 「量子力学と半導体がなぜ関係するの？」と思う方も多いかもしれない。じつは現代の半導体製造において、量子トンネル効果は無視できない主要因のひとつだ。 トランジスタの微細化が進むにつれて——現在は3nmや2nmプロセスが最前線——ゲート絶縁膜の厚みはわずか数原子層にまで薄くなっている。この極薄の絶縁膜を、電子が「トンネルしてすり抜けてしまう」現象がリーク電流（Leakage Current）として現れる。これはチップの消費電力増加や発熱、ひいては設計限界の壁として半導体エンジニアを長年悩ませてきた課題だ。 量子トンネル効果の正確なメカニズムを理解できれば、このリーク電流をより精密に制御・予測できるようになる。つまり今回の発見は、将来の半導体設計ツールや物理シミュレーターの精度向上に直結する可能性を秘めている。 微細化の「壁」を乗り越えるための理論的基盤 Intelの18Aプロセス、TSMCの2nm、Samsungの次世代ロードマップ——世界の半導体メーカーが微細化の限界に向き合っているいま、物理現象の正確な理解はこれまで以上に重要性を増している。 経験則や近似モデルに頼っていた部分を、より正確な理論で置き換えられれば、EDA（電子設計自動化）ツールのシミュレーション精度が上がり、設計段階でのリーク電流予測や消費電力の見積もりがより信頼できるものになる。 量子効果が無視できないサイズ領域に踏み込んだ現代の半導体設計において、「量子力学を理解した上でチップを設計する」という世界は、もはや研究者だけの話ではない。 実務への影響——エンジニアが注目すべき点 直近の製品や開発環境がすぐ変わるわけではないが、中長期で押さえておくべきポイントがある。 消費電力設計の精度向上: サーバー運用担当者やクラウドアーキテクトにとって、チップの発熱・消費電力の予測精度は設備投資に直結する。将来的に設計精度が上がれば、データセンター全体の冷却コストや電力効率の改善につながる可能性がある。 次世代プロセスの限界点を見定める: 「どこまで微細化できるか」という問いへの答えが、より物理的根拠のある形で語れるようになる。ベンダーの微細化ロードマップを読む際の「解像度」が上がる。 量子コンピューティングへの橋渡し: 量子トンネル効果は量子コンピューターの動作原理とも深く関わる。古典的な半導体の世界と量子情報処理の世界をつなぐ研究としても注目に値する。 筆者の見解 情報追いに疲れやすいこの時代、「100年越しの謎が解けた」という見出しはキャッチーに映るかもしれない。しかし今回の発見は、確かに実用上の意味を持つ。 半導体の微細化競争は「いつか物理の壁に当たる」と言われ続けてきた。その壁のひとつが量子トンネル効果だ。それを経験則で回避するのではなく、正確に理解した上で設計に組み込めるようになることは、エンジニアリングとして本質的に正しいアプローチだと思う。「今動いているから大丈夫」ではなく、「なぜ動くのかを理解した上で設計する」——その姿勢の重要性は、半導体の世界でも変わらない。 道の真ん中を歩くためには、足元の物理現象を正確に理解していることが前提だ。今回のような基礎科学の進展は、華やかなプレスリリースには映らないが、10年後の半導体ロードマップを支える土台になる。地味だが確実に積み上げられていく科学の営みを、エンジニアとして素直に歓迎したい。 出典: この記事は Science solved century old mystery that lies inside every AMD, Intel, Nvidia CPU, GPU の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Adobeが提供するCreative Cloudが、ユーザーの知らないうちにOSのhostsファイルを書き換えていることが明らかになった。その目的は「Creative Cloudがインストール済みかどうかをウェブサイト側で検出するため」というものだ。技術的なトリックとしては理解できるが、やっていいことかどうかは全く別の話である。 何をやっているのか Adobeのウェブサイト（adobe.com/home）を訪問すると、JavaScriptがhttps://detect-ccd.creativecloud.adobe.com/cc.pngという画像を読み込もうとする。 ここで重要なのが、Creative Cloudをインストールすると、hostsファイルにdetect-ccd.creativecloud.adobe.comというエントリが追加されていること。このエントリが存在すれば、ブラウザはそのDNSを解決してAdobeのサーバーに接続する——つまりAdobe側はCreative Cloudがインストール済みであることを把握できる。逆にhostsエントリがなければ接続は失敗し、未インストールと判断される仕組みだ。 なぜこんな手法を採用したのか 以前はもっとシンプルな方法が使われていた。http://localhost:<各種ポート番号>/cc.pngにアクセスして、ローカルで動いているCreative Cloudアプリに問い合わせるというものだ。 しかしGoogleがChrome 130前後から「ローカルネットワークアクセス（Local Network Access）」の制限を強化し、外部サイトがlocalhostへ直接アクセスすることをブロックし始めた。これはセキュリティ観点から正しい制限強化である。その結果、Adobeは代替手段としてhostsファイルの書き換えを選択した——というのが今回の経緯だ。 hostsファイルを第三者ソフトウェアが書き換えることの問題 hostsファイルはOSのネットワーク名前解決において最優先で参照される設定ファイルである。WindowsではC:\Windows\System32\drivers\etc\hosts、macOSでは/etc/hostsにある。本来は管理者が管理するシステムレベルのリソースであり、ユーザーやセキュリティ担当者が意図的に管理するものだ。 このファイルをユーザーへの説明なく書き換える行為には、いくつかの問題がある。 1. 透明性の欠如 Creative Cloudのインストーラーは、hostsファイルを変更することについてユーザーに明示的な説明と同意取得を行っていない。ほとんどの一般ユーザーはhostsファイルの存在すら知らないが、だからこそ管理者や組織にとっては「把握できていない変更」が発生していることになる。 2. セキュリティ監査への影響 エンタープライズ環境では、hostsファイルの変更は不正アクセスやマルウェア感染のインジケーターとして監視されることが多い。サードパーティソフトウェアが正当な理由でこれを書き換えることは、セキュリティ監視のノイズを増やし、本当のインシデント検出を難しくする。 3. ゼロトラストアーキテクチャとの相性 エンドポイントの「既知の良好な状態（Known Good State）」を前提とするゼロトラストモデルでは、システムファイルへの予期しない変更はそれ自体がリスク要因と見なされる。 実務への影響 エンジニア・IT管理者が今すぐ確認すべきこと Creative Cloudがインストールされている端末のhostsファイルを確認し、detect-ccd.creativecloud.adobe.comのエントリが存在するかチェックする SIEMやEDR製品でhostsファイル変更イベントを監視している場合、Adobe関連エントリを誤検知として除外するか、正規の変更として記録に残す 組織のエンドポイント管理ポリシーとして「承認済みソフトウェアによるhostsファイル変更の扱い」を明文化することを検討する 今後のCreative Cloudアップデートでこの仕組みが変更・改善されるかを追跡する Chromeのセキュリティ強化について Googleのローカルネットワークアクセス制限は、WANページからlocalhost/内部ネットワークへの予期しないアクセスを防ぐ正当な措置だ。この制限を「回避」するためにhostsファイルを使うというAdobeの判断は、セキュリティ強化の精神に反している。 筆者の見解 個人的に、このニュースを見て2つのことを感じた。 ひとつは、「禁止すれば問題は解決する」という発想の限界だ。Chromeがlocalhostアクセスをブロックしたことはセキュリティ上正しい決断だった。だがAdobeはそれをまともに受け止めて代替設計を再考するのではなく、「hostsファイルを書き換えれば抜け道がある」という方向に走ってしまった。制限を課せば制限を回避しようとする——これは技術的な話でもあるが、ソフトウェアベンダーの姿勢の問題でもある。 もうひとつは、2005年のSony/BMGルートキット事件との既視感だ。あのとき業界が学んだはずの教訓——「商用ソフトウェアといえどもシステムを勝手に弄るのは越権行為」——が、2026年になってもまだ繰り返されている。Adobe Creative Cloudは世界中のクリエイティブ専門職が使う主力ツールだ。その信頼を、こんな小手先のトリックのために削ることの損失を、もう少し重く受け止めてほしい。 Adobeほどのプラットフォームベンダーであれば、ウェブとデスクトップアプリの状態をサーバーサイドのセッション情報として正攻法で管理する設計は十分できるはずだ。hostsファイルという「意図しない副作用が大きい手段」を使わずとも、もっとクリーンな解法は存在する。正面から問題を解けるだけの技術力があるのだから、こういう形で信頼を傷つける必要はない。 ユーザーがインストールしたソフトウェアに対して「自分のマシンで何をされているかわからない」という状況は、特にエンタープライズITにおいて許容してはならない。今回の件を機に、Creative Cloudをプロビジョニングしている組織のIT担当者は、実際にhostsファイルを確認してほしい。 出典: この記事は Adobe modifies hosts file to detect whether Creative Cloud is installed の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIがResponses APIをエージェントワークフロー向けに大幅強化した。シェルツール、組み込みエージェント実行ループ、ホスト型コンテナワークスペース、コンテキスト圧縮、そして再利用可能なエージェントスキルの5本柱が一気に追加された。AIエージェント開発の実用化を加速させるアップデートとして、開発者コミュニティから大きな注目を集めている。 今回の主な追加機能 シェルツール（Shell Tool） APIから直接シェルコマンドを実行できるようになった。これにより、ファイルの読み書き、スクリプトの実行、外部コマンドの呼び出しといった「手を動かす」操作がエージェントから可能になる。これまではこうした処理をラップする独自実装が必要だったが、APIネイティブでサポートされることでエージェントの行動範囲が大幅に広がる。 組み込みエージェント実行ループ（Built-in Agent Execution Loop） エージェントが「考える→行動する→結果を確認する」というループを自律的に繰り返す仕組みがAPIレベルで組み込まれた。従来はこのループを開発者が自分で実装する必要があったが、それをプラットフォームが引き受けることで、開発者はループの制御ロジックではなく「エージェントに何をさせたいか」に集中できる。 ホスト型コンテナワークスペース コードの実行環境をOpenAIのインフラ上にホストする仕組みも提供された。エージェントがコードを書いて即座に実行し、その結果をフィードバックとして受け取るサイクルを安全な分離環境で動かせる。セキュリティリスクを抑えながらコード生成・実行を組み合わせた用途が一気に現実的になった。 コンテキスト圧縮（Context Compression） 長いエージェント実行が続くとコンテキストウィンドウが膨張し、コストとレイテンシが増大するという従来の課題に対応する機能だ。重要な情報を保持しつつ、不要なやり取りを自動的に圧縮することで、長期タスクでも効率的な動作を維持できる。 再利用可能なエージェントスキル（Reusable Agent Skills） エージェントが習得した手順や能力をスキルとして定義・保存し、他のエージェントや別の実行セッションで再利用できる仕組みだ。組織内での知識共有や、複数エージェントの協調作業に向けた基盤として機能する。 実務への影響——日本のエンジニア・IT管理者にとっての意味 今すぐ試す価値のある用途として、以下が考えられる。 RPA代替の検討: シェルツール＋コンテナワークスペースの組み合わせは、定型処理の自動化において従来のRPAツールの代替候補になりうる。スクリプト保守コストを大幅に削減できる可能性がある 社内ナレッジエージェントの構築: 再利用スキルの仕組みを活用することで、特定部署の業務手順をエージェントスキルとして蓄積し、組織横断で展開するという活用モデルが見えてくる PoC期間の短縮: 組み込みループの存在は、エージェントPoCにかかる実装コストを大幅に削減する。「まず動くものを見せる」ためのハードルが下がった 一方で、コスト管理には引き続き注意が必要だ。自律ループが走り続けるということは、制御が甘ければAPIコールが爆発的に増える。コンテキスト圧縮はコスト軽減に貢献するが、適切なループ終了条件の設計は依然として開発者の責任範囲だ。本番投入前にはトークン消費のシミュレーションを念入りに行うことを強く推奨する。 筆者の見解 AIエージェントの本質は「人間の認知負荷を削減する」ことにある。その観点からすると、今回のResponses API拡張は方向性として正しい。「指示→応答」の1往復で終わる設計ではなく、エージェントが自分で考え・動き・確認するループを組み込むことこそが、真に業務を変える力の源泉だからだ。 組み込みエージェント実行ループの提供は、これまで「わかっている人だけが設計できた」ものをAPI水準に引き下げた点で意義深い。エージェントを「副操縦士として人間を補佐するもの」ではなく「目的を渡せば自律的に動くもの」として設計しようとする姿勢がAPIの思想に現れている。 再利用可能なスキルの概念も興味深い。個人やチームが積み上げた「やり方」をスキルとして形式化・共有できるなら、組織のナレッジマネジメントそのものが変わる。ドキュメントに書いて誰も読まない、というよくある悲劇を回避できる可能性がある。 ただし、ここで冷静に見ておきたいのは、「APIで提供されること」と「現場で使いこなせること」の間にはまだ大きなギャップがある、という現実だ。今回の機能群は強力だが、適切なループ設計・スキル粒度の判断・コスト制御といった実装判断はすべて開発者に委ねられている。プラットフォームが整備されるほど、それを活かす設計力の差が組織間の競争力の差として直接出てくる。 情報を追い続けることよりも、自分の手で動かして成果を出す経験を積むことが今は正しい行動だと思っている。今回の機能群も、まずは小さなユースケースで試してみることをお勧めしたい。 出典: この記事は OpenAI Expands Responses API with Shell Tool, Agent Execution Loop, and Reusable Skills の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11の最新メジャーバージョン「25H2」への強制アップデートが、一般ユーザー向けに始まった。特筆すべきは、その展開タイミングの判定に機械学習（ML）を使う「インテリジェント」な更新システムだ。2026年10月にサポート終了を迎える24H2からの移行促進が目的だが、判定基準の非公開と直前の緊急パッチ騒動が重なり、複雑な印象を与えている。 何が起きているのか Microsoftは、Windows 11 Home・Pro（バージョン24H2）を対象に、25H2への自動アップグレードを開始した。対象はあくまで個人・小規模向けのHome/Proエディションで、Active DirectoryやIntuneで組織管理されているデバイスは現時点では除外されている。 ユーザーには完全なオプトアウト手段は与えられていないが、インストールを一定期間延期するオプションは残されている。また、「設定 → Windows Update → 更新プログラムの確認」から手動で任意のタイミングに適用することも可能だ。 機械学習による「準備完了」判定——その不透明さ 今回の仕組みで最も気になるのが、MLを使った「デバイス準備完了」の判定だ。Microsoftは自動展開のタイミングを機械学習で決定するとしているが、具体的な判定基準——どのデータポイントを使うのか、何をもって「準備完了」と見なすのか——については一切公開していない。 セキュリティや互換性の観点から安全なデバイスを優先展開する意図は十分理解できる。しかし判定ロジックが不透明なままでは、ユーザーも管理者も「いつ、なぜ自分のPCが対象になったのか」を事前に把握できない。透明性を高めることはMicrosoftにとって技術的に難しいことではないはずで、ここは改善を求めたいポイントだ。 企業環境への影響は限定的——ただし確認は必須 現時点では、組織管理下のデバイスは強制アップデートの対象外だ。しかし注意が必要なのは、管理が「ゆるい」環境——たとえばMicrosoft 365 Business BasicでAzure AD参加しているが実質個人管理に近い中小企業のPC——だ。自社デバイスがどのスコープに含まれるかを、この機会に確認しておくことを強く勧める。 また、24H2のサポート期限は2026年10月13日。まだ半年あるように見えるが、全デバイスの移行計画を今から立てておかないと、後半に慌てることになる。 直前の緊急パッチ騒動が示すもの タイミングが悪いことに、Microsoftはつい先日、プレビューアップデート「KB5079391」の不具合対応として緊急パッチ「KB5086672」をリリースしたばかりだ。エラーコード0x80073712（ファイル破損・欠落）が多数報告され、広範なインストール失敗を引き起こした。 「すぐ適用したら壊れた」という報告は近年増えている傾向がある。最終的には修正パッチが来るとはいえ、強制アップデートとの組み合わせで「望まないタイミングに問題が起きる」リスクは現実として存在する。数日様子を見てから適用する判断は、今やれっきとしたエンドポイント管理の一形態だ。 実務への影響 個人・SOHO向け 強制アップグレードが来る前に、手動で25H2の動作確認を済ませておくと安心 延期オプションを活用しながら、まず少数台でテスト→問題なければ順次展開する流れが定石 中小企業・IT管理者向け Intuneやグループポリシーで管理しているデバイスは現時点で対象外——ただし管理スコープの確認を忘れずに 24H2サポート終了（2026年10月）に向けた移行計画を今四半期中に立案する 一般ユーザー向け 「更新を止める」ではなく「タイミングをコントロールする」発想で臨む 強制といっても延期は可能。業務の繁忙期を避けて適用するのが現実解 筆者の見解 Windows Updateの「強制アップデート」という言葉には、どうしてもネガティブな反応が先行する。だが本質を整理すると、24H2のサポート終了まで半年を切った中で、放置されたままの旧バージョンデバイスをまとめて最新化しようという意図自体は正しい方向性だ。エンドポイントが分散したバージョン環境に置かれ続けることのリスクは、サポート切れよりもずっと早く顕在化する。 ただ、直前に緊急パッチ騒動があったタイミングで強制展開を開始するのはスマートではない。「機械学習で判定する」と言いながら基準を非公開のままにするのも、ユーザーの信頼を積み上げていく姿勢とは言い難い。 Microsoftには、この種の展開をユーザーが安心して受け入れられる品質と透明性を実現する力が十分にある。Windows Updateへの信頼性向上は、エンドポイントセキュリティ強化の最短経路でもある。正面から勝負できる力を持っているのだから、品質と説明責任の両面をもう一段上げてほしい——そう、期待を込めて言いたい。 出典: この記事は Microsoft to force updates to Windows 11 25H2 for PCs with older Windows 11 OS versions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年4月1日、Azure Government クラウドにおいて Microsoft Defender for Containers のコンテナセキュリティ機能を一般提供（GA）開始したと発表した。米国国防総省（DoD）や連邦・地方政府機関が利用するAzure Governmentで、商用クラウドと同等水準のKubernetesセキュリティ保護が利用可能になったことを意味する。 何が利用可能になったのか 今回GAとなった機能群は、商用クラウドですでに提供されていたDefender for Containersの主要コンポーネントをそのままAzure Governmentに展開したものだ。具体的には以下の機能が含まれる。 エージェントレスKubernetes検出・インベントリ管理: エージェントの展開なしにクラスター構成を自動検出し、リソースの一元把握が可能 攻撃パス分析（Attack Path Analysis）: クラスター内のリスク連鎖を視覚化し、攻撃者が踏み台にしうるルートを事前に特定 脆弱性評価: コンテナイメージおよび実行中のワークロードに対するCVEベースのスキャン ランタイム脅威保護: 実行中のコンテナ・Kubernetesノードに対するリアルタイム検出 コンプライアンス評価: FedRAMPやNISTなど政府機関が遵守すべき標準への準拠状況の確認 これまでAzure Governmentは商用クラウドに対してセキュリティ機能の提供が遅れがちであり、規制の厳しい政府機関が最新の防御機能を利用できない状況が続いていた。今回のGAにより、その「機能ギャップ」が実質的に解消されたかたちだ。 Defender for SQL Serversの更新も同時進行 あわせて、Azure Government（Fairfax環境）向けのDefender for SQL Servers on machines の刷新も予告されている。2026年4月末にリリース予定の新しいエージェントソリューションでは、従来必須だったAzure Monitor Agent（AMA）の個別展開が不要となる。SQLの既存インフラをそのまま活用する設計に変更され、オンボーディングの複雑さが大幅に軽減される見込みだ。 ただし、2026年4月以前にこのプランを有効化していたFairfax利用者は、設定の手動更新が必要となる。2026年5月以降にはSQL Server インスタンスの保護状況確認も求められる予定で、現在Azure Governmentでこのプランを運用している管理者は早めの対応計画が必要だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 「Azure Governmentの話は日本には関係ない」と思いがちだが、実際にはいくつかの重要な示唆がある。 第一に、国内の規制対応クラウド利用のベンチマークとして参考になる。 日本でも政府調達基準（ISMAP）や金融庁ガイドラインに準拠したクラウド利用が求められる領域が拡大している。Azure Governmentでの機能展開パターンは、国内の規制対応環境（プライベートクラウド・オンプレミスKubernetes）への設計指針として読み替えることができる。 第二に、エージェントレスアーキテクチャの価値を再認識するきっかけになる。 従来のセキュリティ監視はエージェント展開が前提だったが、これはKubernetesの動的なスケールアウト・スケールダウンと相性が悪い。エージェントレス検出はこの課題を根本から解決するアプローチであり、商用クラウドでも積極的に活用すべき機能だ。 実務的なアクション： Azure Security Centerを使用中の組織は、Defender for Cloud（旧名称）への移行状況を確認し、Defender for Containersプランの有効化を検討する 攻撃パス分析を定期的に実行し、「今は大丈夫」という思い込みを定量的なリスク評価に置き換える Fairfax環境を利用している組織（米国系グローバル企業の日本拠点含む）は、Defender for SQL Serversの設定更新期限（2026年4月末）を見落とさないよう注意する 筆者の見解 コンテナセキュリティという分野は、正直なところ「好きか嫌いか」で言えば得意な領域ではない。細部の仕様が次々と変わるし、ツールの習得コストも高い。しかし技術的な興味は別の話で、今回の発表はKubernetesセキュリティのあり方を整理するうえで注目に値すると思っている。 特に「エージェントレスKubernetes検出」は、ゼロトラストの観点から理にかなった方向性だ。エージェントが必要ということは、そのエージェント自体が攻撃面になりうるということでもある。エージェントなしで可視性と脅威検出を両立できるアーキテクチャは、長期的に正しい選択だと感じる。 ...

Microsoft が Microsoft 365 Copilot の一環として提供する「Agents in Communities」が、2026年4月より世界展開を開始した。Teams のコミュニティ（Viva Engage を含む）に蓄積された過去の会話・SharePoint サイトの情報をAIが参照し、未回答の質問への返答案を自動生成する機能だ。単なるチャットボットとは一線を画す、「組織の集合知を活用するAIエージェント」という位置づけである。 Teams コミュニティ向けAIエージェントとは何か Agents in Communities は、Viva Engage 上のコミュニティをベースに動作する。これまで「質問を投稿したものの数日間返答がなかった」「同じような質問が何度も繰り返されていた」といった課題は、多くの企業の社内コミュニティが抱える慢性的な問題だった。 このエージェントは、過去の会話ログや関連 SharePoint ドキュメントを参照して、未回答の質問に対して「候補回答」を提示する仕組みを持つ。投稿者やコミュニティ管理者が候補回答を確認・承認することで情報が共有される形式のため、精度の担保と人間の監督が両立している。 同時に、今回の発表では複数のエージェントが正式提供または拡張された： Researcher エージェント: Copilot Chat 内で複雑な調査・情報統合を担当。一般提供済み Analyst エージェント: データを視覚化・洞察に変換。一般提供済み Facilitator エージェント: Teams 会議のノート取得・モデレートを自動化。一般提供済み Interpreter エージェント: Teams 会議での9言語リアルタイム通訳。一般提供済み Project Manager エージェント: Planner 上でのプロジェクト管理を自動化。パブリックプレビュー Agents in Channels: チャンネル専門のAIで過去会話・会議を参照してチームをサポート。パブリックプレビュー 実務への影響——日本のエンジニア・IT管理者にとっての意味 日本企業の社内コミュニティ運用で最も多い悩みは「投稿しても反応がない」「せっかく蓄積した情報が検索されない」という2点に集約される。Agents in Communities はこの両方に対して、コンテンツを能動的に活用するアプローチで応答する。 明日から意識すべき活用ポイント： 既存の SharePoint サイトを整備する: エージェントが参照する情報源の品質が回答品質に直結する。まず社内 FAQ・手順書の整備から始めると費用対効果が高い コミュニティ管理者のワークフローを再設計する: 自動生成された候補回答の承認フローを誰が担うかを事前に定義しておかないと運用が回らない Viva Engage の利用状況を確認する: Agents in Communities は Viva Engage のコミュニティ基盤で動作する。Teams チャンネルと Viva Engage の使い分けを組織として整理する良い機会だ Copilot ライセンスの有無を確認する: これらのエージェントは Microsoft 365 Copilot のライセンスが必要なものが多い。パブリックプレビュー中は確認が必要 筆者の見解 この方向性は、正しい。Microsoft が持つ最大の強みは、Teams・SharePoint・Viva Engage・Planner という「仕事が流れる場所」をすべて統合しているプラットフォーム力だ。そこに蓄積されたデータをAIが活用するというアーキテクチャは、外部サービスでは構造的に再現しにくい。 ...

AIが社会インフラになりつつある今、「誰がAIの安全性を担保するのか」という問いに正面から向き合う動きが加速している。OpenAIが発表した「Safety Fellowship」は、社外の独立研究者がAI安全性・アライメント研究に専念できる環境を整備する試みだ。単なる自社研究の延長ではなく、外部エコシステム全体を育てようとしている点が注目に値する。 Safety Fellowshipとは何か このプログラムは、AIの安全性・整合性（アライメント）に関する研究を行う独立した研究者を経済的・組織的に支援するパイロットプログラムだ。OpenAI内部の研究者を増やすのではなく、外部の優秀な人材が安全性研究に専念できる環境を作ることで、次世代の研究人材を育成する狙いがある。 AI安全性研究の世界では、有望な研究者が資金難や雇用の不安定さから産業界（AI企業）に流れやすい構造的課題がある。アカデミアで安全性の基礎研究を続けたくても、リソース面での壁が高い。フェローシップという形で独立研究者を支援することは、この課題への一つの回答でもある。 アライメント研究が今なぜ重要か 「アライメント（Alignment）」とは、AIシステムが人間の意図・価値観に沿って動作するよう設計・調整することを指す。能力が高いAIほど、設計者の想定を超えた行動を取るリスクも増す。これを事前に理解・制御するための理論的・実証的な研究が安全性研究の核心だ。 特にここ2〜3年、AI能力の向上スピードが安全性研究の進歩を上回っているという懸念が研究者の間で高まっている。大手AI企業が研究開発に多額を投じる一方、安全性研究への投資は相対的に薄かった時期もある。そうした文脈でOpenAIが独立研究者支援を打ち出したことは、業界全体へのシグナルとしても意味が大きい。 なぜこれが重要か——日本のIT現場への示唆 日本では現在、生成AIの急速な導入が進む一方で、安全性やリスク評価の体制整備が後手に回っているケースが少なくない。「とりあえず使ってみる」段階から「責任ある運用体制を構築する」段階に移行しなければならない時期に来ている。 Safety Fellowshipのような取り組みは、日本のIT組織にとっても他人事ではない。社外の安全性研究の成果がOpenAIのモデルや製品に反映されれば、その上で動く業務システムの信頼性にも直接影響する。また、日本国内でもAI安全性を専門とする人材の育成が急務であり、こうした国際的な取り組みを参照しながら人材・組織づくりを進める必要がある。 実務での活用ポイント 1. 自社のAI利用ポリシーにリスク評価を組み込む OpenAIが安全性研究に外部リソースを投じるほど、AIのリスクは多面的だという認識が業界内に広がっている。生成AIを業務に組み込む際は、出力の品質チェックだけでなく、意図しない用途への転用リスクや情報漏洩リスクの評価プロセスを設けることが実践的な第一歩だ。 2. 安全性研究の動向をキャッチアップする アライメント研究の成果はモデルの改良として製品に反映される。主要なAI安全性研究機関（Anthropic Constitutional AI、DeepMind安全性チーム等）の動向を定期的に確認することで、利用しているAIツールの限界と可能性をより正確に把握できる。 3. 自律型AIエージェント導入時は安全性設計を最初から組む AIが自律的にタスクを実行するエージェント構成を導入する場合、安全装置（承認フロー、実行範囲の制限、ログ監査）を後付けではなく設計段階から組み込むことが不可欠だ。自律性が高まるほど、安全性設計の重要性は指数的に増す。 筆者の見解 OpenAIがフェローシップという形で外部研究者の育成に乗り出したことは、正しい方向への一歩だと評価している。AI能力の競争と安全性研究は、どちらかを選ぶものではなく、並走させなければならない。その認識を行動で示した点は素直に歓迎したい。 ただ、気になるのはパイロットプログラムという性格だ。継続性と規模感が伴わなければ、業界全体の安全性研究エコシステムを底上げする効果は限定的になる。一時的な取り組みに終わらせず、構造的な投資として定着させられるかどうかが問われる。 より根本的な論点として、AI安全性研究と製品開発の間にある「翻訳の壁」を誰が埋めるかという課題がある。研究成果が優れていても、それが実装レベルの改善に転換されなければ意味がない。フェローシップが生み出す研究が製品のアーキテクチャに実際に影響を与えるサイクルを作れるかどうか——そこまで踏み込んでこそ、真の意義が生まれると筆者は考える。 AIが私たちの仕事や生活に深く組み込まれていくほど、「速く動く」ことと「安全に動く」ことを両立させる技術的な知見が社会の基盤になる。そのための人材と知識の蓄積を今始めることの価値は、数年後に確実に現れるはずだ。 出典: この記事は Announcing the OpenAI Safety Fellowship の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIが、ChatGPTから直接外部サービスを操作できる「アプリ統合（App Integrations）」機能を本格展開している。Spotify、Canva、Figma、Booking.com、Angi、Expedia、DoorDash、Uberなど複数のサービスと連携し、ユーザーはチャット内で「プレイリストを作って」「ホテルを探して」と話しかけるだけで、実際のアプリ上に結果が反映される。単なる情報提供にとどまらず、AIが外部サービスのアクションを直接実行するという、次のパラダイムへの移行を象徴するアップデートだ。 何ができるのか 設定方法はシンプルで、ChatGPTにログインした状態でプロンプトの冒頭にアプリ名を入力するか、Settings → Apps and Connectorsから一括設定する。アカウントを連携すると、そのサービスのAPIを通じてChatGPTが操作を実行できるようになる。 主な活用例を整理すると次のようになる。 Spotify: 「最近の気分に合ったプレイリストを作って」と頼むと、Spotifyアプリ内にプレイリストが生成される。リスニング履歴や好みのアーティスト情報を参照して個人化されたものになる。 Canva: 「Q4ロードマップ用の16:9スライドデッキを作って」「犬の散歩ビジネス向けのポスター、フォントはこれで」と指定すると、デザイン案がCanva上に生成される。フォント・配色・サイズ・SNSフォーマットなど細かく指定可能だ。 Booking.com: 「東京に3泊、2名、朝食込みで公共交通機関に近いホテルを探して」と話しかけると、条件に合った候補が提示される。Booking.comのサイトで直接検索するより自然な会話で絞り込める。 Angi（ホームサービス）: 家のリフォームや修理に関する質問をして、そのまま専門業者とのマッチングリクエストを送れる。 プライバシーへの注意点は必須 便利な反面、見落としてはいけないのが権限設定だ。例えばSpotifyと連携すると、ChatGPTはプレイリスト、再生履歴、その他の個人情報にアクセスできるようになる。記事中でも「共有する情報の内容を事前に確認すること」と明記されており、ビジネス利用においては情報漏洩リスクの観点から社内ポリシーとの整合確認が不可欠だ。連携の解除はいつでもSettings menuから行える。 実務への影響 日本のエンジニア・IT管理者にとって、この機能が示す意味は2層構造で理解するのが良い。 短期的な実務活用の観点では、CreativeチームによるCanva活用、営業チームによる出張手配の効率化（Booking.com/Expedia）、社内イベント企画でのSpotify活用などが現実的な用途として挙げられる。特にCanvaは中小企業やスタートアップでデザインリソースが手薄な現場で即効性が高い。 中長期的なアーキテクチャの観点では、「AIがAPIを通じて外部サービスのアクションを実行する」という設計パターンが標準化されつつあることを示している。これはいわゆる「Function Calling」や「MCP（Model Context Protocol）」の延長線上にある動きであり、自社システムとAIを統合しようとしているエンジニアにとっては、インターフェース設計の参考事例として価値がある。 また、企業のIT管理者は「AIが社員の代わりに業務アプリを操作できる状態をどう管理するか」という新たなガバナンス課題に直面し始めている。今後はSSOや条件付きアクセスポリシーの整備だけでなく、「AIエージェントに対してどこまでの権限を与えるか」という設計判断が重要になってくるだろう。 筆者の見解 このアップデートで注目すべきは、機能の便利さよりもパラダイムの変化だ。「AIに聞く」から「AIにやってもらう」への転換——これが今起きていることの本質だと思う。 従来の会話型AIは情報を提供し、ユーザーが実際の操作を行うという役割分担だった。しかし今回のような外部アプリ統合は、AIが人間の代わりに実際のサービスAPIを呼び出し、結果を届けるという設計だ。これは「副操縦士」ではなく「代行者」に近い。 AIの真の価値は、人間の認知負荷を削減することにあると考えている。「確認しますか？」「次はどうしますか？」と都度聞いてくるアシスタントでは、認知負荷はむしろ増える。目的を伝えれば結果を出してくれる設計こそが、ビジネスに本物の生産性向上をもたらす。 その意味で、今回のChatGPTのアプリ統合は正しい方向性の一歩だと評価している。もっとも、AIが生成したデザインに誤りが生じたり、旅行予約で条件の解釈がズレたりするケースはまだあるだろう。完璧ではない。だが「方向性は正しい」と「完成度はまだ低い」は別の話で、両方を同時に評価するのが正直なところだ。 この波は確実に日本の職場にも届く。問題は「どう禁止するか」ではなく、「どう安全に使える仕組みを整えるか」だ。禁止アプローチは歴史的に必ず失敗する。公式に提供されたルートが最も安全で便利に見える環境をIT部門が設計することが、今求められている役割だと思っている。 出典: この記事は How to use the new ChatGPT app integrations, including DoorDash, Spotify, Uber, and others の内容をもとに、筆者の見解を加えて独自に執筆したものです。

時価総額8,500億ドル超の企業が「AIで仕事を奪ったら税金を払え」と自ら主張する——これはなかなか異様な光景だ。OpenAIが公表した経済政策提言は、生成AIが引き起こす富の偏在と雇用破壊に企業自身がどう向き合うべきかを問う、一つの時代の節目を示している。 提言の骨子：三本柱とその狙い OpenAIが打ち出したフレームワークは大きく三つの柱で構成される。 ① 課税の軸足を「労働」から「資本」へ 現在の税制は給与所得・社会保障税を主な財源とする。しかしAIが生産の中心になれば、企業利益や資本利得は膨らむ一方、給与所得から徴収するPayroll Tax（米国の社会保障財源）は縮小する。OpenAIはこの構造変化を明示し、法人税や資本利得税の引き上げを示唆した。具体的な税率には踏み込んでいないが、ビル・ゲイツが2017年に提唱した「ロボット税（人間と同等の税を自動化設備が払う）」の考え方も選択肢として明記している。 ② 公的富裕基金（Public Wealth Fund）の創設 AI企業の株式や基盤インフラへの公的持ち分を確保し、その配当を国民に直接還元する仕組みだ。いわゆる「主権ファンド」の個人版に近い発想で、株式市場に参加していない市民にもAIブームの恩恵を届けようとする。ノルウェー政府系ファンドを連想させるモデルだが、民間主導のAI経済に公的株式を組み込む点は、従来の米国資本主義とは一線を画す。 ③ 週4日制・社会安全網の拡充 生産性向上分をそのまま資本に集中させるのではなく、労働者の労働時間削減と賃金維持という形で還元する提案だ。政府がその差分を補助する形で週4日制を後押しするというアイデアは、「AIは人間を助けるもの」という命題を制度設計で実現しようとする試みとも言える。 政治的文脈を読む 提言はトランプ政権が「国家AI戦略」を策定しようとしている時期に合わせて公表された。OpenAIのグレッグ・ブロックマン社長をはじめとするシリコンバレーの経営者層は、AIの軽規制を主張するPACに億単位の資金を投じてもいる。 つまりこの提言は純粋な政策論文ではなく、「我々は再分配にも真剣だが、重規制は望まない」という政治的ポジション取りの側面を持つ。左派的な再分配メカニズムと、右派的な市場優先の組み合わせは、意図的に二項対立を回避したバランス取りと見るのが自然だ。 実務への影響——日本のエンジニア・IT管理者へ 「米国の政策論争が自分に関係あるのか」と思うかもしれないが、以下の点は今すぐ意識すべきだ。 「AIが仕事を変える」は理念ではなく制度設計の話になった: OpenAIのような企業が雇用影響を正面から認め、税制・社会保障への言及を始めたことは、企業内のAI導入戦略を「コスト削減」だけで語れない局面が来ることを示唆する。経営陣へのAI提案には「人員への影響シナリオ」を添えるべき時代が近い 週4日制の議論が再燃する可能性: 国内でも生産性向上を週休3日の実現に結びつける動きが出てくるだろう。人事・IT部門は「AIによる業務自動化→余剰工数の再配分」という流れを先手で設計しておくと、組織の合意形成がスムーズになる 公的・規制当局の介入リスクを注視: EUはAI法を施行済み、米国も政策形成が加速している。グローバルにサービスを展開する企業は、AI活用に関する情報開示・説明責任の強化を早めに織り込んでおく必要がある 筆者の見解 正直に言えば、この提言が即座に法制化される可能性は高くない。しかしOpenAIが自らの事業モデルと矛盾しうる再分配論を公言したことには、それ自体に大きな意味がある。 私がより本質的だと感じるのは、提言の裏にある前提——「AIは大量の人間の仕事を本当に代替する」という認識が、もはや業界内部の確信として定着しつつある——という事実だ。AIエージェントが自律的にループを回し、判断・実行・検証を繰り返す世界では、必要とされる人間の役割は「仕組みを設計できる少数」に収束していく。これは脅かしでも夢物語でもなく、すでに現実のプロジェクト現場で起きていることだ。 日本のIT業界は、この変化の規模をまだ正確に捉えられていない企業が多い。「AIを使った業務効率化PoC」を繰り返している間に、競合はAIエージェントで組織構造ごと変えてくる。新卒一括採用で人員を積み増す戦略は、この文脈では再考を迫られる。 OpenAIの提言が「絵に描いた餅」で終わるかどうかは、政治と市場の力学次第だ。ただ、企業として・エンジニアとして今動いておくべきことは明確にある。制度が整備されるのを待っていては遅い。仕組みを自分で作れる側にいることが、これからの時代の最大の保険になる。 出典: この記事は OpenAI’s vision for the AI economy: public wealth funds, robot taxes, and a four-day workweek の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIインフラをめぐる地政学リスクが、もはや「仮定の話」ではなくなった。イランが2026年4月、OpenAI・SoftBank・Oracleの共同出資による巨大AIデータセンタープロジェクト「Stargate」を名指しで攻撃対象に挙げた。すでにAWSやOracleの実際の施設がミサイルの被害を受けており、この警告は単なるブラフとは言い切れない状況だ。 Stargateとは何か——なぜ標的になったか Stargateは2025年1月に発表された、総投資額5,000億ドル規模のAIデータセンター建設計画だ。OpenAI・SoftBank・Oracleが組んだジョイントベンチャーで、AIモデルの学習・推論に必要な大規模コンピューティングリソースを整備することを目的としている。アメリカ国内だけでなく、中東を含む国際展開も進めていた。 イラン軍報道官Ebrahim Zolfaghariのビデオには、UAEのStargateデータセンターを映した地球儀の映像が映し出され、「どれだけ隠しても我々の視界に入る」とのメッセージが添えられていた。「Googleを使っても隠せない」という挑発的な一文は、オープンソースインテリジェンス（OSINT）の活用を示唆しており、物理的な偵察能力だけでなく、デジタル情報を活用した標的特定が行われていることを意味する。 すでに現実化している被害 今回の警告が深刻なのは、すでに実被害が出ているからだ。バーレーンのAWS（Amazon Web Services）データセンター、ドバイのOracleデータセンターがすでにミサイルの直撃を受けている。NvidiaやAppleも名指しで脅迫を受けており、大手テクノロジー企業が軍事的な標的として扱われるという、これまでの常識を覆す事態が起きている。 発端は2026年2月に始まった米・イラン間の軍事的対立だ。ホルムズ海峡の封鎖が世界のサプライチェーンに影響を及ぼし、トランプ大統領が「期限までに再開しなければ民間インフラを攻撃する」と警告したことへの応報として、イランはクラウドインフラを標的に挙げた。 実務への影響——日本のIT部門が今日から考えるべきこと 「うちは中東のデータセンターなんて使っていない」と思う方も多いかもしれない。しかし注意が必要な点がいくつかある。 依存関係の可視化が急務：利用しているSaaSやクラウドサービスが、どのリージョンのインフラに依存しているかを把握しているだろうか。一見無関係に見えるサービスが、中東リージョンのバックボーンやCDNノードを経由しているケースがある。 マルチリージョン・マルチクラウドの再評価：「コスト最適化」の文脈でシングルリージョン集約が進んでいる企業も多い。地政学リスクの観点から、これを見直すタイミングかもしれない。 BCPにサイバー物理攻撃を含める：これまでのBCP（事業継続計画）はサイバー攻撃や自然災害を想定していた。物理的な軍事攻撃によるデータセンター停止も、大規模クラウドプロバイダーを使う以上は考慮対象になりつつある。 SoftBankの立ち位置に注目：Stargateの主要出資者であるSoftBankは日本企業だ。プロジェクトが地政学的混乱で遅延・縮小した場合、日本のAIインフラ整備計画にも波及する可能性がある。 筆者の見解 AIインフラの集中化が進めば進むほど、そのインフラを攻撃することが最大の戦略的効果を生む——今回の事態は、その冷徹な論理を突きつけている。 かつて「クラウドは安全」という言説は、主にサイバーセキュリティの文脈で語られてきた。しかし今、物理的・軍事的な意味での「インフラの安全保障」が問われている。特定地域に巨大なAIコンピューティングリソースを集中させることのリスクは、電力コストや通信レイテンシだけで議論できる話ではなくなった。 より根本的な問いとして、「AIの計算資源をどこに置くか」という判断は、今後のグローバルITインフラ設計において戦略的な次元を持つようになる。分散配置はコスト増につながるが、単一の地政学的リスクが全体に影響しない設計の価値が再評価されるはずだ。 また、今回のイランの行動が示す最も重要な点は「インフラの見える化＝攻撃可能性の向上」という現実だ。公開情報やOSINTだけで商業データセンターの位置を特定し、軍事作戦の標的に組み込む——この手口は今後も踏襲されうる。クラウドプロバイダーが施設の物理的な詳細を公開する文化は、平時には透明性として歓迎されるが、有事においては別の意味を持つ。 日本のIT担当者にとって、今すぐ変えられることは多くない。しかし「自分たちが依存しているクラウドはどこにあり、何に支えられているか」を把握しておくことは、平時から続けるべき地道な取り組みだ。このニュースをきっかけに、クラウド利用の依存関係を棚卸しする機会にしてほしい。 出典: この記事は Iran threatens ‘Stargate’ AI data centers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが「Google AI Edge Eloquent」という名のAI音声入力アプリをiOSのApp Storeで静かにリリースした。リリース時の派手な発表はなく、ひっそりと公開されたこのアプリだが、その設計思想はなかなか興味深い。Gemmaベースのモデルをデバイス上に落とし込み、インターネット接続なしに音声認識を完結させるという「オフラインファースト」を徹底している点だ。 Gemmaモデルが支えるオンデバイス処理 Eloquentの最大の特徴は、Googleの軽量LLMファミリー「Gemma」をベースにした自動音声認識（ASR）モデルを端末内で動作させる点にある。モデルを一度ダウンロードしてしまえば、あとはオフラインで完全に動く。 一般的な音声入力との最大の違いは、単なる音声→テキスト変換にとどまらない後処理にある。「えー」「あの」「うーん」といったフィラーワードを自動除去し、言い直しや途中修正も含めて「話者が言いたかったこと」をきれいな文章として出力する。これが地味に強力で、議事録やメール下書きを声で書くワークフローとの相性がいい。 アプリ内には「Key points」「Formal」「Short」「Long」などのテキスト変換オプションも用意されており、同じ音声入力から用途に応じた形式で出力を切り替えられる。 クラウドとローカルを使い分けるハイブリッド設計 Eloquentはクラウドモードをオンにすることもできる。その場合はGemini（クラウド版）がテキストの後処理を担い、より精度の高い仕上がりが期待できる。オフとオンを目的に応じて切り替えられる設計は、プライバシー重視の場面と品質重視の場面の両方に対応できる柔軟さがある。 さらにGmailアカウントから業界用語や固有名詞をインポートする機能も持つ。技術系の単語や人名など、汎用モデルが苦手とする語彙をカスタムワードとして登録できる点は、日常的に専門用語を使うエンジニアにとって実用的だ。 なお現時点ではiOS限定だが、App Storeの説明文にはAndroid版への言及があり、システム全体のデフォルトキーボードとして設定できるフローティングボタン機能も予告されている。 実務への影響 日本のIT現場、特に情報セキュリティやデータ取り扱いに厳しい業種（医療・金融・公共）にとって、「クラウドに音声データを送らない」という選択肢は単なる機能の一つではない。データ主権の観点から、オンデバイス処理は要件を満たすための前提条件になることがある。 エンジニアやIT管理者が明日から試せる活用ポイントを挙げておく。 議事録の下書き生成: 会議中にスマートフォンで口述 → フィラー除去済みテキストをそのまま議事録の素材にする メール・Slack文面の口述: キーボードを打つより早く下書きを作り、最後に微修正するフローへの転換 オフライン環境での利用: 工場フロアや地下施設など、ネット接続が不安定な現場での音声メモに カスタム語彙の活用: 社内略語や製品名を登録しておくことで誤認識を減らす Wispr FlowやSuperWhisperなど先行アプリがすでにこの領域で実績を積んでいるが、Googleが「AI Edge」というエッジAIブランドのもとで本格参入してきたことで、競合環境が一段と激しくなる。 筆者の見解 個人的にこのアプリで最も評価したいのは、オフライン処理を「制約への妥協」ではなく「設計の中心」として据えた姿勢だ。エッジAI（端末上でのAI処理）は、クラウドとの比較でどうしても「性能が落ちるもの」として語られがちだが、EloquentはGemmaモデルを用いることで実用的な品質をオンデバイスで実現しようとしている。 AIを「常時使えるインフラ」として位置づけると、ネット回線の有無や通信コストを問わず動くことは本質的な価値になる。AIは24時間どこでも自由に使えてはじめて生産性に織り込める。その意味で、オフラインファーストという設計選択は正しい方向を向いている。 一方で、このジャンルで本当に価値が爆発するのは「入力 → 文字起こし」という単発のフローを超えたときだ。音声でタスクを指示し、AIが自律的に次のアクションを判断・実行するループへと発展すれば、話は大きく変わる。Eloquentは現状まだ「精度の高いメモツール」の域にあるが、Googleがこのアプリを実験台にして何を検証しようとしているのかを注視したい。 Android版が出れば日本国内での利用ハードルも下がる。まずはiOSユーザーが実際に試して、業務フローに組み込めるかどうかを評価してみることをおすすめする。 出典: この記事は Google quietly launched an AI dictation app that works offline の内容をもとに、筆者の見解を加えて独自に執筆したものです。

数ヶ月の作業が、1回の会話に あなたが小さなEC事業者だとして、新商品を出そうと思ったとき、何から始めるだろうか。トレンド調査、競合調査、サプライヤーの比較検討、サンプル取り寄せ、価格交渉——これらをすべてこなして商品を棚に並べるまで、早くて数週間、普通は数ヶ月かかる。 Alibaba.comが2024年にリリースしたAIソーシングツール「Accio」は、この流れを根本から変えつつある。2026年3月時点で月間アクティブユーザーが1000万人を突破し、Alibabaユーザーの約5人に1人が商品調達にAIを活用するまでになった。 Accioは「ChatGPTに似た見た目」でまったく違うことをしている インターフェースはChatGPTやその他の対話型AIと見た目は似ている。テキストボックスに質問を入力し、「Fast」か「Thinking」モードを選ぶだけだ。 しかし返ってくるものが違う。テキストだけでなく、市場トレンドのグラフ、サプライヤーへのリンク、ビジュアル資料が組み合わさって返ってくる。さらにAIが追加質問をしながらニーズを絞り込み、最終的に「このサプライヤーに当たれ」という具体的な候補を提示する。 イリノイ州で小規模アウトドアブランドを運営するMike McClaryの事例が象徴的だ。彼は2017年に製造を止めた懐中電灯の復活を検討した際、まずAccioに旧モデルの設計・原価・利益率を伝えた。するとAccioはサイズの最適化、輝度調整、充電方式の変更を提案した上で、中国・寧波の製造工場を特定。製造コストを17ドルから約2.5ドルまで圧縮できる見通しを示した。 その後の交渉はMcClaryが自分で行い、1ヶ月後には新バージョンがAmazonに並んだ。 なぜこれが重要か——「調査」という認知負荷の解消 この事例で注目すべきは価格交渉の結果だけではない。「何をどこで作るか」という意思決定プロセス全体の構造が変わっている点だ。 従来、中小EC事業者が新商品を出す際のボトルネックは資金よりも「調査にかかる時間と労力」だった。情報収集・比較・絞り込みという認知負荷の高い作業が、参入障壁として機能していた。 Accioはこの部分を代替することで、「アイデアを持っているが動けない人」を「実際に動ける人」に変えている。これはAIエージェントの本質的な価値——人間の認知負荷を削減し、より本質的な判断に人間のリソースを集中させること——を実務レベルで実現した好例だ。 実務への影響——日本のEC事業者・IT管理者へのヒント EC事業者・商品企画担当者へ： 国内の小規模ECでも、海外サプライヤー探しにAccioは試す価値がある。Alibaba.com上で動作するため、既存のAlibaba.comアカウントがあればすぐ使える 「AIに丸投げ」ではなく「AIが絞り込み→人間が最終判断と交渉」という分業設計が現実的で再現性も高い 競合がAIで商品開発サイクルを圧縮し始めた今、従来の手作業プロセスを維持することは相対的な遅れを意味する IT管理者・DX推進担当者へ： Accioのアーキテクチャは参考になる。社内ツールに「質問→絞り込み→具体的候補提示」という流れをAIで設計する際のヒントが詰まっている 複数のフロンティアモデル（自社開発のQwenシリーズ含む）を組み合わせて動いている点も見逃せない。単一モデルへの依存を避け、タスクに応じてモデルを使い分ける設計は、企業AIの実装でも今後の標準になるだろう 筆者の見解 Accioの事例を見て改めて感じるのは、AIの価値が「賢い回答を返すこと」よりも「人間が実際に行動できる状態に持っていくこと」に移ってきているという実感だ。 数週間かかっていた調査を1回の会話で終わらせるというのは、単なる効率化ではない。これまでコストや時間の壁で参入できなかった人が市場に入れるようになる、構造的な変化だ。 一方で、AIが提示したサプライヤー候補の品質評価、サンプル確認、契約交渉——これらは依然として人間の目と判断が必要な部分として残っている。「AIが全部やってくれる」ではなく「AIが準備を整え、人間が意思決定する」という役割分担の明確化こそ、今のAI活用の正しい設計思想だと思う。 日本の中小企業やEC事業者にとっても、こうしたツールの存在を知っているかどうかで、今後の競争力に差が出てくる局面が近づいている。「情報を追うより実際に使って成果を出す」——この姿勢が、これから最も重要な差別化要因になるはずだ。 AIエージェントが自律的に判断・実行するループを設計できる側と、そのループを動かしてもらう側——その分岐点は、思っているよりずっと早く来ている。 出典: この記事は AI is changing how small online sellers decide what to make の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIと雇用の議論が迷走している本当の理由 シリコンバレーでは「AIによる雇用壊滅」がすでに既定路線として語られている。著名なAI企業のCEOが「5年以内にAIがすべての仕事をこなせる」と発言し、研究者が「早期キャリアラダーの崩壊」を予言する——そんな言説が飛び交う中、多くの働く人々が漠然とした不安を抱えている。 しかし、シカゴ大学の経済学者アレックス・イマス（Alex Imas）氏は、こうした議論に根本的な欠陥があると指摘する。問題は「AIと仕事の将来を予測するツールが壊滅的に貧弱」なことだ、と。 「露出度」という幻想 現在、AIと雇用の研究で広く使われているのが、米国政府が1998年に開始した職業情報データベース「O*NET」だ。数千もの職業について、それぞれが含む具体的なタスクを詳細に記録したもので、研究機関はこのデータをもとに「各職業がどれだけAIに代替される可能性があるか（露出度）」を算出してきた。 たとえばある分析では、不動産エージェントの業務の28%がAIによって処理可能と算出されている。しかしイマス氏は言う。「露出度だけでは雇用喪失を予測するまったく無意味な指標だ」と。 確かに、すべてのタスクをAIが人間の指示なしに実行でき、かつAIのコストが人件費を下回るならば、その職種は消滅しうる。だが大多数の仕事は、そこまで単純ではない。 本当に問われるべき問い：補完か代替か より重要な問いはこうだ。AIが入ることで、その労働者の生産性は上がるのか？ そして生産性が上がったとき、雇用主は人をもっと雇うのか、それとも減らすのか？ たとえばコーディングを考えてみよう。AIツールを使いこなすエンジニアが、以前は3日かかっていた実装を1日でこなせるようになったとする。同じコストでより多くのアウトプットが得られる雇用主は——同じ予算でより多く雇うだろうか、それとも人数を削減するだろうか？ その答えは産業によって、企業によって、仕事の性質によって大きく異なる。ある業界では「AIで生産性が上がったから、もっと積極的に開発を進めよう」と採用を増やすかもしれない。別の業界では「同じアウトプットが少ない人数で出るなら人件費を削れる」となるかもしれない。 この「補完性（complementarity）」のデータが今の研究には決定的に欠けている、とイマス氏は主張する。だから「マンハッタン計画レベルの努力が必要だ」と経済学者たちに呼びかけているのだ。 実務への影響——日本のエンジニア・IT管理者に向けて 日本のIT現場でも、この議論は直接的に関わってくる。特に注目すべき点がいくつかある。 「早期キャリアラダーの崩壊」リスク：研修中のジュニアエンジニアや新卒がAIで補完されてきた「入門タスク」をこなす機会が減れば、スキル習得の経路そのものが変わる。OJTの設計を根本から見直すタイミングが来ている。 生産性向上の果実をどこに再投資するか：AIで工数が削減されたとき、「コスト削減」にのみ使うのか「より高度なプロダクト開発」に使うのかで、チームの将来は大きく変わる。経営層との合意形成が今から必要だ。 露出度の高い単純タスクに頼り切っている構造の見直し：もし自分の業務の大半がAIによって高品質に処理できるタスクで占められているなら、それは「危機」ではなく「変革の好機」だ。人間にしか担えない判断・創造・調整の領域へシフトする計画を立てよう。 筆者の見解 この記事で最も重要なのは、著名なAI企業幹部たちの「5年で人類の仕事を全部やる」という発言が、単なる過剰な楽観主義（あるいは意図的なナラティブ形成）である可能性を、経済学の視点から冷静に解体している点だ。 「露出度」という単一指標に依存した議論は、確かに直感的でわかりやすい。だがイマス氏が言うように、その仕事が「消える」かどうかは補完性——つまり、そのタスクをAIが担えるようになったとき、残りの人間的部分の価値がどう変わるか——で決まる。 私が日々感じるのも、「AIが得意なことを全部AIに渡した後、自分の価値はどこにあるか」という問いこそが本質だということだ。AIが処理できるタスクはAIに渡し、人間は判断・設計・関係構築・文脈の読解に集中する。この構造を自分の職能として確立できれば、補完性は高く保たれる。 一方で、この構造転換を「自分には関係ない」と静観している企業や個人には、静かに足元が崩れるリスクがある。日本のIT業界は全体として、この変化のスピードを過小評価している傾向がある。「うちはSIerだから」「業界が特殊だから」という安心感が最も危ういかもしれない。 イマス氏が「マンハッタン計画が必要」と述べるほど危機感を持つのも、データがなければ政策も打てない、という危機感からだ。日本でも政府・学術・産業界が連携してこの実態データを収集しなければ、気づいたときには手遅れという可能性は排除できない。 単純に「AIに仕事が奪われる/奪われない」の二択で考えるのは、今すぐやめよう。問うべきは「自分の仕事の中でAIと補完関係を築けるものはどこか」だ。その問いを持って行動した人が、変化の波を乗りこなす側に立てる。 出典: この記事は The one piece of data that could actually shed light on your job and AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11がリリースされて5年近くが経とうとしているいま、Microsoftはようやく「デザイン」という問題に正面から向き合い始めた。Partner Director of DesignであるMarch Rogers氏がXで発表した内容は地味に見えるが、長年のUIの負債に手を入れようとする意思表示として受け止めるべきだ。 何が変わるのか——4月更新の具体的な内容 今回の4月更新で予告されている変更の柱は以下のとおりだ。 Settingsページの再設計: 情報が詰め込まれすぎた現行レイアウトを整理し、視認性・操作性を改善 アカウントダイアログのダークモード対応: 「その他のユーザー」追加時に表示されるダイアログが、なぜかダークモード設定を無視して白背景で表示される——誰もが一度は違和感を覚えたはずの問題が解消される ペン設定・ナレーター・音声入力の改善: ファイルエクスプローラーでのファイル名変更に音声入力が使えるようになるなど、アクセシビリティ周りの強化も含む March氏自身が「まだ多くの作業が残っている」と認めており、これはゴールではなくスタートだ。 「一貫性のなさ」という根本問題 Windows 11のUI問題の核心は、単に「見た目が古い」ことではない。一貫したUIフレームワークが存在しないことだ。Win32時代のコントロール、UWP、WinUI 3、そしてWebベースのコンポーネントが混在しており、同じOSの中に複数の「時代」が同居している。ダークモード対応のダイアログとそうでないダイアログが混在するのは、この構造的問題の症状に過ぎない。 これはアプリ開発者にも悪影響を与えている。一貫したネイティブUIフレームワークが整備されていないため、Windows向けのデスクトップアプリをElectronやWebviewベースで実装する選択を取る開発者が増えている。macOSのほうがWindows比較でずっと小さい市場シェアであるにもかかわらず、macOS向けにネイティブアプリを提供しているケースが珍しくない。 実務への影響——エンジニア・IT管理者が知っておくべきこと エンドユーザーサポートの観点: Settingsアプリのレイアウトが変わるため、社内ヘルプデスク向けのマニュアルやFAQは更新が必要になる。特にアカウント管理操作のスクリーンショットを使った手順書は要確認。 展開管理の観点: 今回の変更はWindows 11の4月オプション更新として配信される予定。Insider Previewで先行確認できるため、IT管理者はIntune/Windows Update for Businessの除外設定を活用しつつ、テスト環境での先行検証を行うことを推奨する。UIの変更は軽微でも、MDMポリシーの動作が意図通りかを確認する習慣は維持すべきだ。 開発者の観点: WinUI 3への移行が進む今、今後のWindow向けアプリ開発はWinUI 3を基準に設計するのが正しい方向性だ。Win32コントロールへの依存を減らし、テーマ対応・アクセシビリティ対応を最初から組み込む構成を検討したい。 筆者の見解 スティーブ・ジョブズが「Microsoftにはセンスがない」と言ったのは30年前だ。この言葉が今も繰り返し引用されるということは、それだけMicrosoftのデザインに対するイメージが固定されてきたということでもある。 正直に言えば、これは「もったいない」の一言に尽きる。Microsoftのマーケティング素材——製品発表のビジュアルや広告映像——を見ると、デザインセンスがないわけではないことは明らかだ。製品そのものに、そのクオリティが反映されてこなかっただけで。 今回の発表が単発で終わらないことを期待したい。Settingsアプリ一つを取っても、WinRT APIからWin32、MDMポリシーとの連携まで複雑な依存関係があり、デザインの刷新は技術的負債の整理と切り離せない。「デザインに本腰を入れる」という宣言が、組織としての優先度変更を伴うものであることを願う。 Windowsはいまもグローバルで圧倒的なデスクトップシェアを持つ。それだけの基盤とユーザーベースがあるのだから、腰を据えてUIの一貫性に取り組む余力はあるはずだ。4月の更新はその第一歩として、まずは着実に積み重ねてほしい。 出典: この記事は Microsoft says it’s finally focusing on Windows 11’s design, starting with Settings (Control Panel’s replacement) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365（M365）の更新チャネル体系が静かに、しかし確実に変わろうとしている。Microsoftはこのたび、管理外（アンマネージド）の新規デバイスに対して「Semi-Annual Enterprise Channel（半期エンタープライズチャネル）」の選択肢を廃止すると発表した。既存のデバイスへの影響はないが、これから新たにM365を展開する現場では、この変更を見落とすと思わぬ混乱を招く可能性がある。 M365の更新チャネルとは Microsoft 365 Appsには、更新頻度と安定性のバランスをコントロールするための複数の「更新チャネル」が存在する。代表的なものを整理しておこう。 チャネル名 更新頻度 主な用途 Current Channel 月複数回 最新機能を即座に使いたいユーザー Monthly Enterprise Channel 月1回（火曜日定例） 月次で安定的に更新したいエンタープライズ Semi-Annual Enterprise Channel 年2回（1月・7月） 徹底した検証が必要な大規模環境 特に「Semi-Annual Enterprise Channel（SAEC）」は、製造業や金融など、更新前に厳密な動作検証を必要とする業種・業態で長らく重宝されてきたチャネルだ。年2回しか機能更新が入らないため、安定性重視の環境では頼りになる選択肢だった。 何が変わるのか 今回の変更の核心は「管理外デバイスの新規展開時」に限定されている点だ。 既存デバイス: 影響なし。現在SAECを使っているデバイスはそのまま継続できる 新規の管理外デバイス: SAECが選択肢から消える。Current ChannelまたはMonthly Enterprise Channelのいずれかになる Intune・GPO等で管理されているデバイス: 今回の変更の対象外 「管理外（アンマネージド）」とは、MDM（Intune等）やグループポリシーによる管理が行われていない状態を指す。つまり、個人所有のPC（BYOD）や、きちんとした管理基盤が整っていない小規模環境が主な影響を受ける。 なぜこれが重要か Microsoftがこの変更に踏み切った背景には、セキュリティパッチの届きが遅いデバイスをなくしたいという意図がある。SAECは安定性に優れる反面、セキュリティ修正も年2回のサイクルに縛られてしまう側面があった（セキュリティ更新自体は月次で配信されるが、機能更新と紐付いた修正が遅延するケースがある）。 管理が行き届いていない「野良デバイス」が旧バージョンのM365 Appsを長期間使い続けるリスクを低減するという観点では、この方針は理にかなっている。 また、Microsoftとしては更新チャネルの種類を整理・簡素化し、運用コストを下げたい意図もあるだろう。チャネルの選択肢が多すぎると、エンドユーザーにとっても管理者にとっても意思決定が複雑になる。 実務への影響——日本のIT管理者が注意すべきポイント 1. 新規展開前にチャネル設計を見直す 特に中小規模の組織で「管理ツールを使わずにM365を展開している」ケースは要注意だ。これまで何となくSAECを選んでいた場合、新規PCへの展開時に同じ設定が踏襲できなくなる。 2. アンマネージド環境こそIntuneへの移行を検討する好機 逆説的ではあるが、今回の変更は「管理基盤を整えるきっかけ」として捉えられる。Intuneによる管理下に置けば、引き続きSAECを選択できる。「管理が面倒だから放置」という環境があれば、今回の変更を機に整備を進めるのが建設的だ。 3. Monthly Enterprise Channelへの移行準備 新規デバイスでSAECが使えなくなる場合、最も安定した代替はMonthly Enterprise Channelだ。月1回・定例火曜日の更新サイクルは予測可能性が高く、エンタープライズ向けとしても十分な安定性がある。更新検証のプロセスを月次サイクルに合わせて再設計しておきたい。 4. 既存デバイスの棚卸しを 今回は既存デバイスへの影響はないが、「どのデバイスがSAECで動いているか」を把握できていない環境は要注意だ。将来的なチャネル変更に備えて、今のうちに管理台帳を整備しておくべきだろう。 筆者の見解 この変更、個人的には「正しい方向への一歩」だと思っている。 管理基盤のないデバイスが半年に一度しか更新されない状態で放置されるのは、セキュリティの観点から見ると相当リスクが高い。「安定性のためにSAEC」という判断自体は理解できるのだが、それが「更新を先送りにする言い訳」として機能してしまっているケースを日本の現場でも少なくない頻度で見かける。 ただ、この変更には一つ懸念もある。「管理外デバイスを管理下に置く」という方向性は正しいのだが、それをするためのコスト・工数が日本の中小企業には決して小さくない。Intuneのライセンスコスト、設定工数、社内の理解を得るための調整——これらのハードルが高くて身動きが取れないまま、気づいたら「Current Channelで毎月バタバタ更新」という状況になるケースも出てくるだろう。 Microsoftにお願いしたいのは、こういった移行をスムーズにするためのガイダンスや、中小企業向けの移行支援を充実させることだ。変更の方向性は応援しているからこそ、ランディングをうまくやってほしいという気持ちがある。チャネル戦略を整理する力はある。あとはユーザーを連れていく伴走力の問題だ。 出典: この記事は Microsoft removes Semi-Annual Enterprise Channel option for new unmanaged M365 devices の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Solanaベースの分散型取引プラットフォーム「Drift Protocol」が2026年4月1日に受けた約2億8,000万ドル（日本円換算で約400億円超）の暗号資産窃盗事件の調査が進み、その全貌が明らかになってきた。単なるゼロデイ攻撃ではなく、半年以上にわたる周到な人間工作（ヒューマン・オペレーション）が組み合わさった、現代のサイバー攻撃の新しい教科書とも言える事案だ。 「量的取引会社」を装った6ヶ月の潜伏工作 攻撃者グループは、正規のクオンツ（量的取引）企業として偽装し、複数の国際的な暗号資産カンファレンスでDriftのコントリビューターと対面接触を繰り返した。ブロックチェーン情報企業のEllipticおよびTRM Labsの調査により、北朝鮮系のサイバー攻撃グループ「UNC4736」（AppleJeus、Labyrinth Chollimaとも呼ばれる）の関与が中高度の信頼性で示されている。 注目すべきは、カンファレンス会場で直接接触してきた人物は「非韓国系」の仲介者だったとDriftが明記している点だ。多国籍の中間者を使い、帰属追跡を困難にする手法は、同グループの典型的な手口と合致する。 対面接触後は、TelegramグループでDriftの技術仕様や取引戦略について継続的にコミュニケーションを取り、「普通のオンボーディング交渉」を演じ続けた。犯行直後にそのTelegramグループは削除されている。 開発者ツールチェーンを標的にした2つの攻撃ベクター Drift Protocolが現在調査中とする侵入経路のうち、技術的に見てとりわけ重要なのが次の2点だ。 1. 悪意あるコードリポジトリ（VSCode/Cursor脆弱性の悪用） 攻撃者はコントリビューターにコードリポジトリを共有し、VSCodeまたはCursorの脆弱性を利用してサイレント（無音）コード実行を行った可能性がある。AIコーディング支援ツールとして急速に普及したCursorが攻撃ベクターとして名指しされている点は、開発者にとって看過できない警告だ。 2. 偽TestFlightアプリ（ウォレット製品と称したiOSアプリ) AppleのTestFlightは開発者向けのベータテストプラットフォームであり、通常のApp Storeレビューを経ない。攻撃者はこれを活用し、悪意あるiOSアプリをウォレット製品として提示した。TestFlightを経由した攻撃は以前から報告されており、特に暗号資産関連コミュニティで有効な手法となっている。 SecurityCouncilの管理権限ハイジャックと12分での資産流出 侵入後、攻撃者はDriftのSecurity Council（セキュリティ評議会）の管理者権限を乗っ取り、わずか12分でユーザー資産を引き出した。現在、全機能が凍結され、侵害されたウォレットはマルチシグプロセスから除外されている。取引所やブリッジオペレーターに対して攻撃者のウォレットアドレスが共有され、資金移動の阻止が試みられている。 UNC4736は2023年の3CXサプライチェーン攻撃、2024年のRadiant暗号資産5,000万ドル窃盗、Chromeゼロデイ悪用事案など多数の大規模攻撃に関与しており、MandiantはLazarusグループとの関連性も指摘している。 実務への影響：日本のエンジニア・IT管理者が明日から取るべきアクション この事案は暗号資産業界だけの問題ではない。開発ツールチェーンと信頼関係を武器化した攻撃は、あらゆるソフトウェア開発組織に刺さる教訓を持っている。 開発環境のセキュリティ見直し VSCode/CursorなどのIDEに対する拡張機能・スクリプトの自動実行を制限する 外部から共有されたリポジトリをサンドボックス環境で開く運用ルールを策定する .vscode/settings.json や launch.json の tasks 設定を必ずレビューする習慣をつける TestFlight・ベータ配布経由のアプリへの警戒 社内外から「試してみて」と共有されるテストアプリは、必ず出所確認を行う 特に秘密鍵やシード情報を扱うウォレット系ツールは、公式ストア以外からの取得を原則禁止にする コントリビューター・管理者の権限管理 常時付与された特権アカウントをなくし、Just-In-Time（JIT）アクセスモデルに移行する 多要素認証はもちろん、Security Councilのような重要権限グループはマルチシグ構成で守る Telegramなどの非公式チャネルで技術的に機微な情報を共有しない運用ルールを徹底する カンファレンス参加時の意識 名刺を渡してきた相手がすぐにコラボ提案や「コード見せて」という流れになる場合は一度立ち止まる 特定のロールを持つ開発者は、所属・担当範囲の公開情報を最小化することも選択肢に入れてよい 筆者の見解 今回の事案が示しているのは、ゼロデイ脆弱性よりも「人の信頼」を攻撃するコストが下がっているという現実だ。6ヶ月間、複数カ国でカンファレンスに出没し、専門知識を持った人物が技術的に自然な会話を続けて侵入口を作った。このレベルの持続的な工作は、テクニカルなセキュリティ対策だけでは防ぎきれない。 特に気になるのが、VSCode/Cursorが攻撃ベクターとして挙げられていること。AIコーディングツールとして急速に普及しているエディタ環境が標的になるという構造は、開発者コミュニティ全体に対する警告だ。便利なツールが普及すれば、当然そこを狙う攻撃者も出てくる。ツールの採用と同時にそのリスクプロファイルを理解し、組織として何らかの緩和策を持つことが求められる。 日本の大手エンタープライズ環境で「外部との接触はすべて禁止」という方向に走りたくなる気持ちはわかる。だが禁止アプローチは必ず失敗する。外部リポジトリを一切cloneできない環境では開発が止まるし、TestFlightの利用を一律禁止すれば業務に支障が出る。大事なのは「安全に使える仕組みを用意する」こと。開発者が公式・安全な方法を選べる環境を作り、それが一番便利に感じる状態にすることだ。 特権アカウントの常時付与をやめ、Just-In-Timeアクセスを徹底する。これは今回の事案に限らず、あらゆる組織に適用できる原則だ。今動いているから大丈夫、という判断が一番危ない。この事案もまた、そのことを証明している。 出典: この記事は Drift $280M crypto theft linked to 6-month in-person operation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「パッチより先に来る攻撃者」という現実 Microsoftが公開したレポートは、日本のIT現場にとっても他人事では済まされない内容だ。中国を拠点とする金銭目的のサイバー犯罪グループ「Storm-1175」が、Medusaランサムウェアを用いた高速攻撃を展開しており、一部のゼロデイ脆弱性をパッチ公開の1週間前から悪用していたことが確認されている。 「パッチを当てればいい」という発想が前提にしている「パッチが先に来る」という常識が、このグループには通用しない。防御側の想定を根本から見直す必要がある。 Storm-1175の攻撃手口——速さと多様性が武器 初期侵入から被害発生まで「最短24時間」 Microsoftによれば、Storm-1175は初期アクセスを確立してからデータ窃取・ランサムウェア展開まで、数日以内、場合によっては24時間以内に完了させる。この「高い作戦テンポ」が最大の特徴だ。 攻撃チェーンは以下のように進む： 初期アクセス: ゼロデイやNデイ（既知だが未パッチ）の脆弱性を悪用して境界設備に侵入 永続化: 新規ユーザーアカウントの作成、RMM（リモート監視管理）ソフトのインストール 横展開と情報収集: 資格情報の窃取、ネットワーク内部の探索 防御の無効化: セキュリティソフトを無効化 最終目的の達成: Medusaランサムウェアの投下とデータ流出 標的にされた製品リスト 2023年以降だけで、以下を含む10製品・16以上の脆弱性が悪用されている： 製品 CVE Microsoft Exchange CVE-2023-21529 Ivanti Connect/Policy Secure CVE-2023-46805 / CVE-2024-21887 ConnectWise ScreenConnect CVE-2024-1709 / CVE-2024-1708 JetBrains TeamCity CVE-2024-27198 / CVE-2024-27199 SimpleHelp CVE-2024-57726 ほか BeyondTrust CVE-2026-1731 SmarterMail CVE-2025-52691 / CVE-2026-23760 CrushFTP CVE-2025-31161 PaperCut CVE-2023-27350 / CVE-2023-27351 GoAnywhere MFT CVE-2025-10035 注目すべきは、Microsoft Exchangeも標的製品の一つだという点だ。日本企業でオンプレミスExchangeをまだ維持しているケースは少なくなく、特に注意が必要だ。 また、BeyondTrustやSimpleHelpなどの特権アクセス管理ツールやリモート監視ツールが攻撃対象になっていることは、皮肉な構図でもある。セキュリティや運用効率化のために入れたツールが、逆に侵入経路になりうる。 医療・教育・金融が重点標的 Microsoftは最近の侵害が「医療機関」に大きな影響を与えたと強調している。CISAもFBIと共同で、Medusaグループが米国内の300以上の重要インフラ組織に被害を与えたと警告している。業種を問わず、境界に露出した資産を持つ組織はすべてターゲットになりうる。 実務への影響——日本のエンジニア・IT管理者が今すぐやるべきこと 1. インターネット公開資産の「棚卸し」を今すぐやれ Storm-1175が得意とするのは「露出した境界資産の特定」だ。攻撃者はスキャンツールで公開IPを継続的に探索しており、自組織の公開サービスが何かを把握していないことは致命的なリスクになる。Shodan的な視点で自分たちの外部からの見え方を確認する習慣をつけること。 2. RMMツールの利用実態を把握・監視する Storm-1175はScreenConnect、SimpleHelp、BeyondTrustなどのRMM/特権管理ツールを悪用している。自組織で利用しているRMMツールの認証ログ・接続元IPを定期的に監視し、未承認の接続を検知できる体制を作ること。 ...