Tech News JP

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を定期的に監視し、未承認の接続を検知できる体制を作ること。 ...

Microsoftが長年にわたってサポート担当者やIT管理者に愛用されてきた診断ツール「Microsoft Support and Recovery Assistant（SaRA）」のコマンドライン版を、2026年3月10日以降の全Windowsアップデートから削除した。理由は「環境のセキュリティ強化とハードニング」。後継として推奨されているのは「Get Help」コマンドラインツール（GetHelpCmd.exe）だ。 SaRAとは何だったのか SaRAは、Office・Microsoft 365・Outlook・Windowsに関するよくある問題を自動診断・修復するフリーツールだ。Windows 7から11まで幅広く対応しており、IT管理者がPowerShellスクリプト経由でリモート実行するユースケースでも広く使われてきた。根本原因を特定して自動修復するか、手順ガイドを提示するか、Microsoftサポートへの連絡を支援するか——この3択で問題解決を導く設計は、ヘルプデスク業務の効率化に大きく貢献してきた。 後継ツール「Get Help」は何が違うのか Microsoftが提示した後継ツール「Get Help」は、機能面ではSaRAとほぼ同等だ。Microsoft 365アプリ（OutlookやTeams）の診断、コマンドライン実行、PowerShellからのリモート実行——いずれも対応している。 最大の違いはインフラのセキュリティ強度。Microsoftによれば、Get Helpを支えるバックエンド基盤はSaRAのものよりセキュリティが強化されているという。具体的な技術詳細は公開されていないが、診断ツール自体がセキュリティ上の弱点になりうるという認識の下、インフラを刷新したと読める。 移行手順はシンプルで、GetHelpCmd.exeをダウンロードして実行するだけ。ただし、既存のスクリプトやRMMツールからSaraCmdLine.exeを呼び出している場合は、GetHelpCmdLine.exeへの差し替えが必要になる。 実務への影響 影響を受ける可能性があるケース SaRAのコマンドライン版をPowerShellスクリプトやRMMツールから呼び出している環境 ヘルプデスク手順書にSaraCmdLine.exeの実行手順が記載されている場合 MDMやGroup Policyで配布・実行を管理している場合 移行時の確認ポイント 既存スクリプトの棚卸し — SaraCmdLine や SaRACmd で社内スクリプトを検索し、使用箇所を洗い出す GetHelpCmd.exeの動作確認 — 差し替え後に同等の診断シナリオが再現できるかテストする 手順書・ドキュメントの更新 — ヘルプデスクやサポート担当向けの運用手順書を更新する エンドユーザー向けGUIのSaRAは別物 — 今回廃止されたのはコマンドライン版。GUIのSaRAアプリについては別途確認が必要 筆者の見解 今回の廃止は、セキュリティ強化という観点からは正しい判断だと思う。診断ツールはシステムの深部にアクセスする性質上、そのインフラ自体が攻撃対象になりうる。「動いているから大丈夫」を理由に古い実装を維持し続けることの方が、長い目で見てリスクだ。 ただ、IT管理者の立場から見ると、また一つ「使い慣れたツールが変わる」対応が増えたのも事実だ。SaRA以外にも、Publisher廃止・Lens廃止・Authenticatorのパスワード自動入力廃止と、最近のMicrosoftは廃止ラッシュが続いている。個々の判断には理由があるにせよ、現場の運用担当者が追いつくのが大変になっている現実も見ておきたい。 移行先のGet Helpが、SaRAと同じくらい現場で信頼されるツールに育つかどうか——それはMicrosoftのインフラ品質と、ドキュメント整備の速度にかかっている。セキュリティを強化したバックエンドで動くなら、診断の精度も上がることを期待したい。「セキュリティのために刷新した」という言葉が、実際の改善として実感できるツールになることを願っている。 今動いているSaRAのスクリプトは早めにGet Helpへ移行を。3月10日以降のWindowsアップデートを適用済みの環境では、すでにSaRAが機能しなくなっている可能性がある。 出典: この記事は Microsoft removes Support and Recovery Assistant from Windows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

未パッチのWindows権限昇格脆弱性「BlueHammer」のエクスプロイトコードが、Microsoftのセキュリティ対応に不満を持つ研究者によって公開された。現時点で公式パッチは存在せず、攻撃者がSYSTEM権限を取得できる状態が続いている。脆弱性の深刻さもさることながら、開示プロセスをめぐる研究者とMicrosoftの対立という構造的な問題を改めて浮き彫りにした事案だ。 BlueHammerとは何か——技術的な詳細 BlueHammerはローカル権限昇格（LPE: Local Privilege Escalation）の脆弱性で、「TOCTOU（Time-of-Check to Time-of-Use）」と「パス混同（Path Confusion）」という2つの手法を組み合わせて悪用する。 TOCTOUとは、リソースの状態を「確認するタイミング」と「実際に使用するタイミング」の間にずれが生じることを突く古典的な競合状態攻撃だ。BlueHammerはこれにパス混同を組み合わせることで、WindowsのSAM（Security Account Manager）データベースへの読み取りアクセスを得る。SAMにはローカルアカウントのパスワードハッシュが格納されており、これを取得できればSYSTEM権限へのエスカレーションが現実のものとなる。 脆弱性の検証を行ったセキュリティ研究者のWill Dormann氏によれば、「エクスプロイトが成功すれば、攻撃者はSYSTEM権限のシェルを起動するなど、システムを事実上完全に制御できる」という。ただし、公開されたPoCコードにはバグが含まれており、動作が安定しないケースもある。Windows Serverでは完全なSYSTEM奪取ではなく、非管理者から昇格管理者への権限昇格にとどまる挙動も確認されている。 開示の経緯——研究者対MSRCの構図 「Chaotic Eclipse」「Nightmare-Eclipse」というアカウント名を使う研究者は、BlueHammerをMicrosoftに対してプライベートに報告していた。しかしMicrosoftのセキュリティ対応部門（MSRC）の対応に強い不満を抱き、2026年4月3日にGitHubでエクスプロイトコードを公開した。 公開時のコメントには「Microsoftに対してハッタリをかましているわけではない。また同じことをやる」「MSRC幹部に感謝する、こうなることを可能にしてくれた」という皮肉が込められていた。 背景として注目すべきは、MSRCが脆弱性報告の際に「エクスプロイトの動画提供」を要件としている点だ。研究者側からすれば、再現動画の作成は相応の労力を要する。このプロセスへの不満が積み重なった可能性が高い。責任ある開示（Responsible Disclosure）の精神に反する行為である一方で、報告コストの高さという制度的な問題を提起している側面もある。 実務への影響——ローカルアクセスを過小評価するな 「ローカル攻撃者が必要」という条件から、リスクを低く見る向きもあるかもしれない。しかしこの見方は危険だ。 ソーシャルエンジニアリング、メールの添付ファイル、他ソフトウェアの脆弱性、認証情報の窃取——いずれもローカルコードの実行を得るための現実的な経路だ。BlueHammerが刺さるのは、初期侵害に成功した後の「横展開・権限昇格フェーズ」だが、実際の攻撃チェーンではここが最も重要なステップになることが多い。 IT管理者が明日から取れる対策として、以下を検討したい： 最小権限の原則を徹底する: 標準ユーザー権限での業務を原則とし、管理者権限の常時付与を避ける。Just-In-Time（JIT）アクセスの仕組みが理想的だ SAMデータベースへのアクセス監視を強化する: 異常なSAMアクセスをSIEMやMDEで検出できるよう、検出ルールを見直す エンドポイント検出・応答（EDR）の精度を確認する: PoCコードはすでに公開されており、シグネチャが更新されつつある。EDRが最新状態であることを確認する Windowsのパッチ状況を継続監視する: 今後のPatch Tuesdayで修正が提供される可能性が高い。適用可否の判断体制を整えておく 筆者の見解 BlueHammerの技術的な内容そのものは、古典的な手法の組み合わせという意味で「目新しさ」はそれほど高くない。TOCTOU攻撃は十数年前から知られており、SAMデータベースを狙う手法も確立された攻撃パターンだ。 むしろ今回の件で考えさせられるのは、MSRCの開示プロセス設計の問題だ。エクスプロイト動画の提供を義務付けることで、善意の研究者に不必要な負担を強いている面がある。セキュリティ研究者のコミュニティから優秀な人材を遠ざけることになれば、長期的にMicrosoft自身にとって損失だ。 Microsoftにはセキュリティに本気で投資できるリソースがある。Secure Future Initiative（SFI）を掲げ、組織全体のセキュリティ文化変革に取り組もうとしているのは知っている。だからこそ、研究者との関係構築という「人の問題」でつまずいているのはもったいないと感じる。研究者コミュニティを味方につければ、脆弱性情報の流れ方が変わる。 パッチが出るまでの間、ユーザーとしてできることはSAMアクセス監視の強化とEDRの最新化程度だが、それを徹底するだけでもリスクは下げられる。公式修正を待ちながら、自組織の権限管理の棚卸しをするよい機会として捉えてほしい。 出典: この記事は Disgruntled researcher leaks “BlueHammer” Windows zero-day exploit の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントとツール連携の標準規格として急速に普及しつつある MCP（Model Context Protocol）。そのMCPサーバーをAzure Functions上で構築・デプロイするための公式クイックスタートが、TypeScript向けに公開された。単なるサンプルにとどまらず、エンタープライズ向けのOAuth認証やインフラコード（Bicep）まで一式揃っており、本番投入を意識した構成になっている点が注目に値する。 MCPとは何か、なぜ今注目されているのか MCPは、AIエージェント（LLMホスト）がバックエンドのツールやリソースへ標準化された方法でアクセスするためのプロトコルだ。REST APIに例えるなら「AIエージェント専用のOpenAPI仕様」とも言える。Visual Studio Code Copilot・Claude・ChatGPTといった主要なAIホストがすでに対応しており、一度MCPサーバーを作れば複数のAIクライアントから利用できる汎用性がある。 さらに今回のアップデートで注目したいのが MCP Apps という概念だ。従来のMCPがテキストベースのデータ返却に限られていたのに対し、MCP AppsではインタラクティブなHTML/JSウィジェットをAIホストのUI内に直接レンダリングできる。地図・グラフ・承認フォーム・リアルタイムダッシュボードなど、これまでチャットUIの制約上実現できなかったリッチな体験が可能になる。 Azure Functionsがもたらす3つの価値 1. プロトコル実装の複雑さを隠蔽する MCPプロトコルを自前で実装しようとすると、SSE（Server-Sent Events）の管理やJSON-RPCのフォーマット、セッション管理など覚えることが多い。Azure Functionsではapp.mcpTool()という1つの関数呼び出しでツール定義が完結する。ハンドラーを書けばプロトコルの詳細は自動で処理される。 出典: この記事は MCP Apps on Azure Functions: Quickstart with TypeScript の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azure SDK for JavaScript が、2026年7月9日をもって Node.js 20.x のサポートを終了することを正式に発表した。Node.js 20.x 自体のEOL（End of Life）が2026年4月30日に到来することを受けた対応であり、Azure SDK を利用している JavaScript / TypeScript プロジェクトは、それ以前に Node.js 22.x 以降への移行を完了させる必要がある。 Node.js のリリーススケジュールとサポートポリシー Node.js は偶数バージョンのみが LTS（Long Term Support）対象となるリリースモデルを採用している。各 LTS バージョンは「Active LTS」→「Maintenance LTS」→「End-of-Life」という段階を経て廃止される。 現在のバージョン別ステータスは以下の通りだ。 バージョン ステータス EOL 20.x Maintenance LTS → EOL 2026年4月30日 22.x Active LTS 2027年4月30日 24.x 2025年後半リリース予定 — Azure SDK チームは、Maintenance フェーズを終えた Node.js バージョンについてはサポートから順次除外する方針を明確にしている。重要なのは、メジャーバージョンを上げることなく（破壊的変更なしに）このサポート除外を行えるという点だ。つまり、SDK の利用者が気づかないまま状況が変わる可能性がある。 2026年7月9日に何が起きるか 当日以降にリリースされる Azure SDK for JavaScript の各ライブラリは、package.json の engines フィールドに node: >=22.x を指定するようになる。 実際の影響は npm の設定によって異なる。 ...

Microsoftが公開した最新の「Digital Defense Report」に、見過ごせない数字が載っている。IDへの攻撃の97%は、パスワードスプレーによるものだ。 高度な解析ツールや量子コンピューターではない。ごく単純な手法——多数のアカウントに対し、ありがちなパスワードを少しずつ試し続けるだけ——が、現代のほぼすべてのID侵害を引き起こしている。これは、多くの現場が信じている「複雑なパスワードルールを設定すれば守られる」という前提そのものへの反証だ。 パスワードスプレー攻撃とは何か パスワードスプレーは、ブルートフォース攻撃の進化系だ。従来型のブルートフォースは「1つのアカウントに大量のパスワードを試す」ため、アカウントロックアウトで検知・ブロックされやすかった。これに対しスプレー攻撃は発想を逆転させる。 「多数のアカウントに対し、1〜3種類だけパスワードを試す」 たとえば Welcome2024! や Spring2026@ のような「複雑性要件を満たしつつ誰もが思いつく」文字列を、数千〜数万のアカウントに1回ずつ試すだけだ。ロックアウトのしきい値に引っかからず、ログ上でも「散発的な認証失敗」に見えるため、従来の監視体制では素通りしてしまう。 LinkedInや過去のデータ侵害から入手した実在のユーザー名リストと、「よく使われるパスワードTOP100」を組み合わせるだけで成立する、参入障壁の低い攻撃手法でもある。 従来のADパスワードポリシーが機能しない理由 Active Directoryの既定のパスワードポリシーは、こうした攻撃を想定して設計されていない。最小文字数・複雑性要件・有効期限・パスワード履歴——これらはすべて「ブルートフォース対策」や「内部からの単純な推測」を念頭に置いた設計だ。 問題は何を守れないかにある。 既知の侵害パスワードのチェック機能がない: Password1! は複雑性を満たすが、すでに数百万件の侵害リストに存在する スプレーパターンの横断検知ができない: ADは「このアカウントが何回失敗したか」は見るが、「組織全体で同じパスワードが何アカウントに試されたか」は見ない コンテキスト（場所・デバイス・時間帯）を考慮しない: 深夜に海外IPからのアクセスでも、パスワードが正しければ通ってしまう つまり、複雑なルールを設けてもスプレー攻撃には無力という構造的な問題がある。 管理者が今すぐ導入すべき対策 1. Microsoft Entra Password Protection オンプレミスのADにも展開できるMicrosoftの仕組みで、Microsoftが管理するグローバルの禁止パスワードリストと、組織独自のカスタム禁止リストを組み合わせてパスワード設定時点でブロックできる。「複雑なのに侵害済み」というパスワードを排除する最初のラインだ。 2. MFA（多要素認証）の全員展開 パスワードが漏れた前提で考える。Microsoft Authenticatorのプッシュ通知 + 番号一致（Number Matching）を有効化すれば、正しいパスワードを持っていても突破できない壁になる。「管理者だけMFA」は今や論外で、全ユーザーが対象だ。 3. Conditional Access（条件付きアクセス）による文脈評価 IP・デバイス・場所・サインインリスクスコアを組み合わせてアクセスを制御する。Entra ID Protectionのリスクベースポリシーと組み合わせれば、スプレー攻撃で正しいパスワードを入力された瞬間に「高リスクサインイン」として検知し、MFAを強制または遮断できる。 4. 特権アカウントへのJust-In-Time（JIT）アクセス ドメイン管理者やグローバル管理者の権限を「常時付与」している組織はまだ多い。常時付与は特権アカウント管理における最大のリスクだ。Microsoft Entra Privileged Identity Management（PIM）を使えば、必要なときだけ、承認ベースで一時的に昇格できる仕組みを作れる。攻撃者がパスワードを入手しても、権限が無効化された状態であれば実害は大幅に限定される。 5. パスワードレス認証への移行 根本的な解決策はパスワードをなくすことだ。FIDO2セキュリティキーやWindows Hello for Businessは、パスワード自体が存在しないためスプレー攻撃の対象にならない。段階的に高リスクユーザー（管理者・リモート接続ユーザー）から展開を始めるのが現実的だ。 日本のIT現場への影響 日本の大企業・中堅企業のオンプレAD環境では、グループポリシーによるパスワードポリシーを「セキュリティ対策済みの証拠」として扱っている現場が今でも少なくない。Entra IDへのハイブリッド移行途上で、認証周りの設定が中途半端なまま止まっているケースも多い。 「今まで大きな事故がなかった」は、「今まで攻撃者に見つかっていなかっただけ」の可能性が高い。侵害の多くは侵入から数ヶ月後に発覚する。 筆者の見解 セキュリティ全般は決して得意分野とは言えないが、認証・認可の設計には技術的な面白さを強く感じる領域でもある。 今回の「97%がパスワードスプレー」という数字は、正直に言って驚きではない。洗練された攻撃より、「普通の人が使いそうなパスワードを片っ端から試す」だけで9割以上が決まってしまうというのは、むしろ現在のID管理のあり方への問いかけだ。 MicrosoftはEntra IDにパスワードスプレー対策のための技術を揃えている。Password Protection、Entra ID Protection、Conditional Access、PIM——これらは単体ではなく組み合わせて使って初めて意味を持つ。M365やEntra IDを使いながら、パスワードポリシーだけ昔のままという状態は、道具を持っているのに使っていないのと同じだ。 ...

大規模言語モデル（LLM）というと、数千億パラメータ・数百億円のコスト・謎めいたアーキテクチャ——そんなイメージを持つエンジニアは多い。しかし「それは思い込みだ」と静かに示す教育プロジェクトが、Hacker Newsで425ポイントを集めて話題になっている。その名もGuppyLM——金魚のような小さなLLMだ。 GuppyLMとは何か GuppyLMは、約870万（8.7M）パラメータのトランスフォーマーモデルをゼロから実装したオープンソースの教育プロジェクトだ。学習データは6万件の合成会話、PyTorchのコードはわずか約130行。Google ColabのT4 GPU（無料枠）でわずか5分で学習が完了する。 生成されるのは「グッピー（熱帯魚）」というキャラクターの会話で、水温・えさ・泡などの話題で小さく応答する。これは意図的な設計で、「人間の抽象概念を理解しないモデル」という制約のなかで、トークナイザから学習ループ、推論まですべての仕組みが透明に見えるようになっている。 アーキテクチャの「飾らなさ」が価値 モデルの仕様はシンプルの一言に尽きる。 項目 値 パラメータ数 8.7M レイヤー数 6 隠れ次元 384 アテンションヘッド 6 語彙サイズ 4,096（BPE） 最大シーケンス長 128トークン GQA（Grouped-Query Attention）もRoPE（Rotary Positional Embedding）もSwiGLUも使わない。バニラトランスフォーマーそのままだ。GPT-4やClaudeが内部で使うような最適化技術は一切ない。 この「飾らなさ」こそが意図的なポイントで、最新技術のノイズを排除して「トランスフォーマーの本質的な動作」だけを学べる設計になっている。 60トピックの合成データセットで個性を作る 学習データはHuggingFaceで公開されているarman-bd/guppylm-60k-generic。挨拶・感情・温度・食べ物・光・水・孤独・夢・人生の意味など60カテゴリ、6万件の合成会話が含まれる。 データの形式は {"input": "...", "output": "...", "category": "..."} とシンプルで、自前のキャラクター設定に差し替えれば自分だけの「個性あるミニLLM」をほぼ同じ手順で作れる。 プロジェクト構造も明快だ。config.py（ハイパーパラメータ）、model.py（トランスフォーマー本体）、dataset.py（データローディング）、train.py（学習ループ）、generate_data.py（会話データ生成）に綺麗に分割されており、どのファイルがどの役割を担うか一目でわかる。 実務への影響——なぜエンジニアはLLMの内部を知るべきか LLMをAPIとしてのみ使うエンジニアにとって、内部構造の理解は「趣味の話」に見えるかもしれない。しかし実際には、構造への理解がプロンプト設計の質を根本的に変える。 たとえばコンテキストウィンドウの制約、トークン化の落とし穴、温度パラメータの意味、ファインチューニングと数ショット学習の使い分け——これらはモデルがどう動くかを知らないと、「なんとなく試行錯誤」から抜け出せない。 GuppyLMを手元で動かすことで得られる実践的なヒントをまとめる。 トークナイザを自分で実装する体験: BPE（Byte Pair Encoding）の動作を自力で追うと、なぜ日本語トークン数が英語より多くなりやすいかが腑に落ちる 学習ループの全体像を把握する: コサイン学習率スケジューリングやAMP（自動混合精度）の意味がコードレベルで見える 「どこで何が決まるか」を知る: ハイパーパラメータを変えてすぐに再学習できるため、感覚ではなくデータで設計判断できるようになる ファインチューニングの入門台として最適: 自社データで試したいが大規模モデルは難しい——という場合に、GuppyLMで手順を先に身につけると実際の作業がスムーズになる 筆者の見解 「LLMは魔法じゃない」——この一言に尽きると思っている。 AIエージェントや自律ループを設計する立場から言えば、モデルの挙動を予測できるかどうかは実装の品質に直結する。ブラックボックスとして扱い続ける限り、想定外の出力への対処は「プロンプトをいじる」という勘頼みになりがちだ。 GuppyLMのような小さなプロジェクトを一度手で動かすと、トークン化・アテンション・サンプリングのそれぞれが何を担っているかが体で理解できる。その感覚は、大規模モデルのAPIを呼ぶときも確実に活きる。 日本のIT現場では「とりあえずAPIを叩いてみる」層と「論文を読み込む」層に二極化しがちだが、GuppyLMはその間を埋める絶好の入口だ。5分で動くモデルを1本手元で作ったことがある人とそうでない人では、AI技術の議論の解像度が明らかに違ってくる。 情報を追い続けることよりも、一度手を動かして自分の感覚を作る——そのコストが「Colabで5分」まで下がったことの意義は、思っている以上に大きい。 出典: この記事は Show HN: I built a tiny LLM to demystify how language models work の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...