Tech News JP

ニューヨーク州知事キャシー・ホークル氏が2025年12月19日、フロンティアAIモデルを対象とした透明性・安全性確保法「RAISE Act（S6953B/A6453B）」に署名した。カリフォルニア州のSB 53を超えると評される内容で、米国における州レベルのAI規制競争が本格化している。 RAISE Actの主な要件 大規模AIモデル開発者に課される主な義務は以下の通りだ。 安全プロトコルの公開: 自社のAI安全計画を作成・公開すること インシデント報告: 重大なインシデントが発生したと判断してから72時間以内に州へ報告 監督機関: ニューヨーク州金融サービス局（DFS）内に専門のオーバーサイトオフィスを新設。年次レポートを発行し、大規模フロンティア開発者を評価する。運営費用は開発者からの手数料で賄う 罰則: 司法長官が民事訴訟を提起可能。初回違反で最大100万ドル、以降は最大300万ドルの制裁金 カリフォルニアSB 53との違い 法案を推進したアレックス・ボアーズ議員が「SB 53を複数の点で超えている」と強調するように、RAISE Actはより踏み込んだ開示・報告義務を課している。連邦政府がAI規制に消極的な現状を受け、ニューヨークとカリフォルニアという2大テック州が「統一的なベンチマーク」を形成しつつある。 なぜこれが重要か 日本のIT現場からすると「アメリカの州法の話」と感じるかもしれないが、影響は決して他人事ではない。 OpenAI・Anthropic・Google・Metaのような主要フロンティアAI開発者はいずれもニューヨーク州でビジネスを展開しており、RAISE Actへの準拠が実質的にグローバルな開発プロセスの標準化を促す可能性がある。72時間インシデント報告の義務は、金融業界のサイバーインシデント報告義務（PCI DSS、GDPR等）と同じ方向性であり、AIシステムを「インフラ」として扱う国際的な流れを加速させる。 日本でも経済産業省がAIガバナンスガイドラインを整備しているが、拘束力のある法的義務という点では大きく遅れている。日本企業がグローバルにAIサービスを展開するなら、ニューヨーク州法への対応は避けられない実務課題となる。 実務での活用ポイント AIシステムを利用・開発する企業のIT管理者・エンジニア向け インシデント対応フローの見直し: 自社でAIシステムを開発・提供している場合、72時間以内の報告義務を前提にした障害対応SOP（標準手順書）を今から設計しておく価値がある。EU AIアクト・日本のガイドラインとも方向性が揃いつつあるため、一度整備しておけば転用できる ベンダー評価の新軸: AIサービスを調達する側も、ベンダーが「安全計画を公開しているか」「インシデント報告体制があるか」を評価基準に加えるべきタイミングだ。RAISE Actへの対応状況はベンダーのガバナンス成熟度の代理指標になりうる 社内AIガバナンス文書の整備: 自社でフロンティアモデルを使ったシステムを構築・運用するなら、安全計画に相当するドキュメント（リスク評価・モニタリング体制・エスカレーションパス）を整備しておくと、将来的な法的要件への対応コストを大幅に削減できる 筆者の見解 RAISE Actが示す最も重要なメッセージは、「AI安全規制は連邦政府を待たずに進む」という現実だ。 現在の米連邦政府はAI規制に対して規制緩和路線を取っており、州がその空白を埋める競争が始まっている。これは金融規制・プライバシー規制でも繰り返されてきたパターンで、最終的には州法の集積が事実上の全国基準を形成してきた歴史がある。 72時間インシデント報告という数字に注目したい。これはサイバーセキュリティの世界では既に標準的な要件だ。AIシステムを「セキュリティインフラと同等のガバナンスが必要なシステム」として扱う考え方は、技術的にも運用的にも正しい方向だと思う。AIエージェントが自律的に業務を実行する時代において、インシデント発生時の透明性と報告体制は最低限の社会的な約束として機能すべきものだからだ。 一方で気になるのは、監督オフィスの運営費用を「開発者からの手数料」で賄う構造だ。これは規制機関が被規制者から資金提供を受けるという構造であり、独立性の観点から慎重に設計しないと機能不全を起こすリスクがある。良い仕組みを作ろうとしているのだから、その設計の詰め方次第で評価は大きく変わる。 AI規制の議論は「イノベーションの阻害か安全の確保か」という二項対立で語られがちだが、実際には「透明性があるほうが信頼され、信頼されるほど採用が進む」という正のサイクルを生む。日本企業にとっても、今のうちにガバナンス体制を整えておくことは守りではなく攻めの一手だ。 出典: この記事は Governor Hochul Signs Nation-Leading Legislation to Require AI Frameworks for AI Frontier Models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google が Gemma 4 を Google Cloud で正式提供開始した。Vertex AI・Cloud Run・GKE のいずれからでもデプロイ可能で、Apache 2.0 ライセンスによる商用利用制限なしという点が大きな注目ポイントだ。オープンモデルの実用性が問われる中、企業がどこまで本気で採用を検討できるかが問われる局面に入ってきた。 Gemma 4 の技術仕様：何が変わったか Gemma 4 は Gemini 3 と同じ研究基盤から生まれたモデルファミリーで、以下の主要スペックを持つ。 コンテキストウィンドウ：最大 256K トークン（長文書処理・長い会話履歴の維持が現実的になる） マルチモーダル対応：テキストだけでなく、ネイティブで画像・音声を処理 多言語対応：140 言語以上に対応（日本語も含まれる） モデルサイズ：2B（エッジ向け Effective 2B）から 31B Dense、26B MoE まで複数バリアント ライセンス：Apache 2.0（商用利用に制限なし） 特に実務的に重要なのは 256K トークンのコンテキストと MoE（Mixture of Experts）アーキテクチャの 26B モデルだ。MoE は推論時に全パラメータを使わず必要な「専門家」サブネットワークだけを活性化するため、同規模の Dense モデルより計算効率が高い。 デプロイ先の選択肢 Vertex AI — マネージド環境でのフルコントロール Model Garden からモデルを選択し、自前の Vertex AI エンドポイントへデプロイできる。ファインチューニングは Vertex AI Training Clusters（VTC） で対応。NVIDIA NeMo Megatron を使った SFT（Supervised Fine-Tuning）レシピが用意されており、31B モデルの効率的なファインチューニングガイドも公開されている。 ...

「見るだけのAI」の時代が終わる Oracleが2026年3月24日、ロンドンで開催したOracle AI WorldにおいてFusion Applications向け「AI Agent Studio」の大幅な機能拡張を発表した。目玉は「Agentic Applications Builder」と呼ばれる新機能で、従来のようなコーディングや専門的なアプリケーション開発の知識なしに、自然言語の指示だけでAIエージェントを組み合わせ、業務ワークフローに組み込めるようになる。 地味に見えるが、この発表の本質はプレスリリースの一文に凝縮されている。 「ダッシュボードとコパイロットを超え、実際にビジネスを動かすAI搭載アプリケーションへ」 多くの企業がこの2〜3年、AIを「アシスタント」として導入してきた。要は、人間が質問して、AIが答えを返す。人間が確認して、人間が実行する。この「副操縦士モデル」では、ボトルネックは常に人間だった。Oracleが今回打ち出しているのは、そこからの明確な脱却だ。 今回の主な機能アップデート Agentic Applications Builder Oracleおよびパートナー・外部のエージェントを組み合わせ、業務ワークフローを設計できるAI駆動の開発環境。「どのエージェントに何をさせるか」を自然言語で記述するだけで、複数エージェントの連携フローが構成できる。 ワークフローオーケストレーション 複数ステップ・複数エージェントが絡む複雑な業務プロセスを、ルールベースで制御しながら実行する機能。人間による承認ステップを組み込むことも可能で、完全自動化と人間監督のバランスを調整できる。 コンテキストメモリ エージェントが過去のインタラクションやワークフローの文脈を記憶し、次のタスクに活用する仕組み。これにより「毎回一から説明する」という煩わしさが解消され、連続した業務プロセスを途切れなく自動化できる。 コンテンツインテリジェンス・マルチモーダル対応 構造化トランザクションデータだけでなく、契約書・請求書・音声・画像といった非構造化データもエージェントが処理対象にできる。これはERP領域にとっては大きな拡張で、「人間でなければ読めない書類」をも自動処理のスコープに入れることを意味する。 ROI計測・監査・ガバナンス 企業向けとして重要なのがこの部分。エージェントの動作をリアルタイムで監視し、どのエージェントが何をしたかを監査証跡として残す。また投資対効果（ROI）の計測機能により、「本当に業務効率が上がっているか」を定量的に評価できる。 実務への影響——日本のIT現場で考えるべきこと 日本の多くの企業では、SAP・Oracle・Microsoft Dynamicsといった大規模ERPに業務の中枢を置いている。そこへのAI統合は「どのAIツールを外から連携させるか」という議論になりがちだが、Oracleが今回示したのは別の方向性だ。ERPそのものがエージェントの実行基盤になるというアーキテクチャである。 実務上のポイントをいくつか挙げる。 ① 「PoC疲れ」からの出口として評価する価値がある 日本企業でAIのPoCが終わらない主因の一つは「本番環境への繋ぎ込みが難しい」ことだ。今回のビルダーはFusion Applications（ERPデータ）との接続が前提に設計されており、既存Oracleユーザーにとって統合コストが低い選択肢になりうる。 ② NHI（非人間アイデンティティ）の整備が前提になる エージェントが自律的に業務を実行するには、サービスプリンシパルやAPIキーなど「人間ではないが認可されたID」の管理体制が不可欠だ。エージェントに適切な権限を与え、その行動を監査する仕組みなしには、自律実行はリスクでしかない。AIエージェント導入の前に、自社のNHI管理基盤を整えておくことが急務だ。 ③ ワークフロー設計スキルが新たな競争優位になる 「コーディング不要」と言っても、どのエージェントに何をさせ、どこに人間の判断を挟むかを設計するスキルは依然として人間に求められる。プログラミングより業務プロセスの深い理解と、「どこを自動化できるか」を見極める眼が重要になる。 筆者の見解 今回のOracleの発表で個人的に刺さったのは「ダッシュボードとコパイロットを超える」というフレーズだ。これは業界全体に向けた宣言だと読んでいる。 ここ数年、多くのエンタープライズAIは「人間を補助するツール」として設計されてきた。人間が承認し、人間が最終判断を下す。それ自体は悪くないが、そのモデルでは結局ボトルネックが人間のまま変わらない。確認・承認を人間に求め続ける設計では、AIを入れた意味が薄れてしまう。 Oracleが今回提示しているのは、エージェントが自律的にプロセスを回し続ける「ハーネスループ」的な世界観だ。コンテキストメモリで文脈を保持しながら、複数エージェントが連携し、人間の逐次確認なしに業務を前に進める。これは単なる機能追加ではなく、企業AIの設計思想そのものの転換を意味する。 もっとも、「コーディング不要」の触れ込みは額面通りに受け取りすぎない方がいい。自然言語でエージェントを組めるとしても、それは「設計不要」ではない。ゴミを入れればゴミしか出てこない。業務プロセスを整理し、正しい責任分担を設計し、適切なガバナンスを敷く——その土台となる人間の仕事は、むしろより高度になる。 Oracleのような巨大ERPベンダーがここまで踏み込んできたことは、「エンタープライズAIの本番運用」が2026年の主戦場になることを示している。日本のIT現場も、PoC段階の議論を終わらせ、業務プロセスとエージェント設計を本気で考え始める時期に来ている。 出典: この記事は Oracle Expands AI Agent Studio for Fusion Applications with Agentic Applications Builder の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIが半導体スタートアップCerebrasとの提携により、コーディング特化モデル「GPT-5.3-Codex-Spark」を発表した。Wafer Scale Engine 3（WSE-3）という特殊なチップ上で毎秒1,000トークン超を実現し、従来のCodexモデルと比べて約15倍の高速化を達成している。ChatGPT Proユーザー向けにCodex app・CLI・VS Code拡張機能経由でリサーチプレビューとして提供が始まっている。 Wafer Scale Engine 3とは何か CerebrasのWafer Scale Engine（WSE）は、一般的なGPUと根本的に異なるアーキテクチャを持つAI専用チップだ。通常のGPUがシリコンウェハーを小さなダイに切り出して製造するのに対し、WSEはウェハー1枚をそのままチップとして使う。WSE-3の世代では4兆個のトランジスタを集積しており、オンチップメモリ帯域幅でNVIDIAのH100を大きく上回る。 LLM推論のボトルネックのひとつは「メモリ帯域幅」だ。モデルの重みを高速にロードし続けなければトークン生成速度は頭打ちになる。WSE-3はこの帯域幅問題を正面から解決するアーキテクチャであり、コーディング用途のような「連続した長い出力」で特に効果を発揮する。 なぜリアルタイム速度が重要なのか コーディング支援AIにおいて、応答速度は体験の質に直結する。ファイル1本分のコードを生成するのに数十秒かかるモデルは、どれだけ品質が高くてもワークフローへの組み込みに摩擦が生じる。毎秒1,000トークンという水準は、人間が読み取れる速度を大幅に超えており、エディタ上でのリアルタイム補完や、スクリプト自動生成といったユースケースでほぼ「待ち時間ゼロ」の体験を実現できる。 AIエージェントが自律的にコードを書き・テストし・修正するループを回す際、推論速度がそのままエージェントのサイクルタイムになる。高速なモデルはエージェントの反復回数を増やし、短時間でより多くの試行錯誤を可能にする。この観点から、速度の改善は単なる快適性ではなくエージェント設計の根幹に関わる。 現時点での制約と提供状況 GPT-5.3-Codex-Sparkは現在「リサーチプレビュー」段階であり、ChatGPT Proサブスクリプション（月額20ドル）の契約者のみがアクセスできる。提供チャネルはCodex専用アプリ、CLIツール、VS Code拡張機能の3つで、API経由での一般提供はまだアナウンスされていない。 モデル名に「GPT-5.3」と付いていることから、GPT-5系列の派生モデルとして位置付けられているが、コーディング特化チューニングが施されており汎用用途への適性は限定的とみられる。WSE-3はCerebrasのクラウドサービス上でのみ稼働するため、OpenAI自社インフラへの統合がどのように行われているかは現時点では不明な部分が多い。 実務への影響 VS Codeユーザー: 既にCodex拡張機能を使っている場合、ChatGPT Proへのアップグレードでリサーチプレビューに参加できる。コード補完の体感速度がどの程度変わるか、実際のプロジェクトで試す価値はある。 AIエージェント開発者: 高速推論はエージェントループの設計に大きく影響する。単発の指示→応答モデルではなく、エージェントが自律的に判断・実行・検証を繰り返す設計において、推論速度はループのスループットを決める変数になる。 企業IT担当者: 現時点ではChatGPT Pro個人アカウント向けのため、企業展開を検討するにはAPIの一般提供を待つ必要がある。ただし、この速度水準が標準化されると、コーディング系AIツールの選定基準が変わる可能性がある。 筆者の見解 毎秒1,000トークンという数字は、AIコーディング支援のパラダイムを変えうるインパクトを持っている。これまでの「少し待てば答えが返ってくる」体験から、「エディタ上でほぼリアルタイムに候補が展開される」体験への転換は、単なる高速化以上の意味を持つ。 とはいえ、速度だけがコーディング支援の全てではない。コードの品質、文脈理解の深さ、長いセッションでの一貫性——これらの要素がどう変化するかは、リサーチプレビューのフィードバックが出揃ってから判断すべきだ。速くても的外れなコードを高速で出力されても困る。 OpenAIがCerebrasという外部ハードウェアパートナーに依存する形で速度優位を作ったことは興味深い。NVIDIAのGPUクラスタを前提としないモデル配信が成立するなら、AI推論インフラの多様化が本格的に始まったサインかもしれない。この流れが加速すれば、推論コストと速度の組み合わせが今後のモデル選定で以前より重要な変数になってくるだろう。 日本のエンジニアにとっては、「最高速のモデルを使いこなす」ことよりも「速度が上がった時に何が変わるか」を先に設計しておくことが重要だ。ツールを使いこなす前に、どのようなループ設計・ワークフロー設計でその速度を活かすかを考えておくと、いざ使い始めたときの学習効率が大きく変わる。 出典: この記事は Introducing GPT-5.3-Codex-Spark | OpenAI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたか セキュリティ研究者が「BlueHammer」と名付けたWindowsの権限昇格エクスプロイトが公表された。影響を受けるデバイスは世界で10億台を超えるとされており、規模の大きさから多くのWindowsユーザーが注目している。 BlueHammerの核心は、TOCTOU（Time-of-Check to Time-of-Use）脆弱性とパス混乱（Path Confusion）の組み合わせにある。「確認したときと実際に使用するときの間に状態が変わってしまう」という古典的なレースコンディションと、ファイルパスの解決ロジックを混乱させる手法を組み合わせることで、権限昇格を実現する。 技術的な構造を理解する TOCTOU脆弱性とは TOCTOU攻撃は、アクセス権を「確認する処理」と「実際に実行する処理」の間に存在するわずかな時間窓を突く。たとえば「このファイルに書き込んでいいか？」を確認した後、実際に書き込む前に攻撃者がそのファイルを別の場所へのシンボリックリンクに差し替えると、本来許可されていないパスへの書き込みが発生する。 なぜ「パス混乱」が組み合わさるのか Windowsはファイルパスの解決において、Win32パス（C:\Windows\System32\...）とNTパス（\??\...）という異なる表記体系を持つ。BlueHammerはこの差異を利用し、セキュリティチェックが見る「パス」と実際に操作される「パス」を意図的にずらすことで特権ファイルへの書き込みを誘導するとされている。 「未認証では悪用できない」の意味を正確に読む 重要なのは、BlueHammerは単体では未認証での悪用ができないという点だ。何らかの形で攻撃者がすでにシステム上でコードを実行できる状態（ローカルアクセスや限定的な権限）にある必要がある。 しかし、これを「安全だ」と読んではいけない。現実のインシデントでは、フィッシングメール→資格情報窃取→BlueHammerで特権昇格→横展開、というチェーンが容易に成立する。BlueHammerは「初期侵入」を担うエクスプロイトではなく、「侵入後の被害最大化」を担うピースとして機能する点に脅威の本質がある。 実務への影響 エンジニア・IT管理者が今すぐ確認すべきこと 1. パッチ適用状況の確認 Microsoftが本脆弱性に対応するパッチをリリースしているか、あるいはCVEが割り当てられているかを公式のセキュリティ更新プログラムガイド（MSRC）で確認する。BlueHammerがPoC（概念実証コード）として公開されている場合、悪用までの猶予は短い。 2. 最小権限の徹底 権限昇格エクスプロイトが効果を発揮するのは、昇格した先に「使える権限がある」からだ。ユーザーアカウントに標準ユーザー権限のみを与え、管理作業はJIT（Just-In-Time）で必要な時だけ昇格する構成が基本になる。EntraIDのPIM（Privileged Identity Management）を使ったJIT昇格はこのクラスの攻撃に対して非常に有効だ。 3. EDR・Defender for Endpointの検知ルール確認 TOCTOU攻撃はシンボリックリンク操作や特定のNTパスアクセスパターンを伴う。EDRがこれらの挙動を異常として検知・アラートする設定になっているか確認しておきたい。 4. 資格情報保護の強化 BlueHammerの前段階として資格情報窃取が必要なことを逆手に取り、LAPS（Local Administrator Password Solution）によるローカル管理者パスワードのランダム化、Credential GuardやWindows Helloによる認証強化を優先する。攻撃チェーンの最初のピースを断つことが、権限昇格エクスプロイトへの最も現実的な対策になる。 日本企業特有のリスク 日本の大規模エンタープライズでは、オンプレミス Active Directoryとクラウドが中途半端に混在した環境がいまも多い。そういった環境では「標準ユーザーに見えて実は何らかのローカル管理者権限がある」という状態が発生しやすく、BlueHammerのような権限昇格エクスプロイトの被害が連鎖しやすい。棚卸しは急務だ。 筆者の見解 TOCTOU脆弱性は新しい概念ではない。30年以上前から議論されてきたクラシックな攻撃手法であり、それが2026年にもなって10億台規模の影響を持つエクスプロイトとして登場するという事実には、複雑な思いを抱く。 Windowsのパス解決ロジックは歴史的な経緯から非常に複雑で、Win32・NT・UNC・DOSデバイスパスといった複数の名前空間が混在している。この複雑さ自体が攻撃面を広げてきた。Microsoftがここ数年で取り組んでいるカーネルセキュリティの強化——サードパーティカーネルドライバーの締め出し強化やSmart App Controlの整備——は正しい方向の取り組みだと思っているが、パス解決の根本的な複雑さを整理するのは並大抵ではない。 ひとつ明確にしておきたいのは、「10億台超」という数字に過剰反応しすぎないことだ。BlueHammerが機能するためには攻撃者がすでにある程度の足場を築いている必要があり、それ自体を防ぐ取り組みが優先される。「新しい脆弱性が出た＝全員即アウト」ではない。パッチ適用・最小権限・JIT昇格・EDR監視という基本の積み重ねが、このクラスの脅威に対する最善の盾になる。 Microsoftにはその基盤を整える力が十分あるし、Defender・IntuneといったMDMスタックとの統合で日本企業のセキュリティポスチャを一気に引き上げるポテンシャルもある。BlueHammerへの対応が迅速であれば、それはそのポテンシャルを体現する機会にもなる。正面から勝負できる力があるのだから、速やかな対応を期待したい。 出典: この記事は ‘BlueHammer’ Exploit Targets Windows, Potentially Impacting 1 Billion+ Devices の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年のWindows 11は「体験の細部」に本気を出している 2026年4月上旬のWindows 11 Insider Buildに、注目すべき変更が立て続けに盛り込まれた。Secure Boot証明書の期限切れに対応するUI整備、ハプティックフィードバックの強化、そしてXbox Modeの導入——これらは一見バラバラに見えるが、今年後半のWindows 11が向かう方向性を示す重要な伏線として読み解くことができる。 Insider（Preview）Buildの変更点を追うことの意味が薄れている時代ではある。しかし今回のビルド群は「裏方の改善」だけにとどまらず、エンドユーザーが日常的に触れる場面での体験変化を含んでいる点で、IT管理者にとっても無視できない内容だ。 7つの主要変更点を読み解く 1. Secure Boot証明書の期限切れ対応UI 最も実務的なインパクトがあるのがこれだ。Secure Bootに使われるUEFI証明書が期限切れを起こした際、これまではエラーメッセージが暗号的で原因特定が困難だった。新しいUIでは、証明書の期限切れを明示的に警告し、対処法へのガイダンスが表示されるようになる。 企業環境では、カスタムSecure Bootキーを管理しているケースもある。「なんか起動しない」という問い合わせがIT部門に来たとき、証明書の期限切れがすぐに疑えるかどうかで対応時間が大きく変わる。地味だが、現場の負荷を減らす正しい方向の改善だ。 2. ハプティックフィードバックの強化 Surface等の対応デバイスで、タッチ操作やペン入力時のフィードバックが細かく制御できるようになる。物理キーボードのクリック感に慣れたユーザーが「タブレットモードは使いにくい」と感じる原因の一つがフィードバックの薄さだった。これを埋める取り組みとして評価できる。 3. Xbox Mode Windowsをゲーム用途に最適化する「Xbox Mode」が導入される。バックグラウンドプロセスの制御やリソース割り当ての調整により、ゲームパフォーマンスを向上させる仕組みとみられる。Xbox Game Passとの連携を強化し、PCとコンソールの垣根をさらに下げる狙いがあると考えられる。 4〜7. その他の変更点 その他にも、設定アプリのUX改善、通知管理の強化、Windowsアップデート関連のフィードバック収集UI、そしてアクセシビリティ機能の拡充が確認されている。特にアップデート関連のフィードバックUIは「更新後に問題が起きたときに報告しやすくする」という観点で、品質向上の仕組みづくりとして機能する可能性がある。 実務への影響——IT管理者・エンジニアが注目すべき点 Secure Boot関連は即座に実務インプットとして持っておきたい。特に以下のシナリオで有効だ： オンプレミスのデバイス管理でIntuneやSCCMによる証明書管理を行っている環境 カスタムUEFIキーを使用しているセキュアな企業端末の展開環境 新入社員端末の一括セットアップ時に「なぜか起動しない」案件が頻発している現場 Windows Updateについては依然として「すぐ当てたら壊れた」という報告が散見されるため、Insider Buildの変更内容を事前にウォッチしておくことで、本番適用前のリスク見積もりに役立てることができる。数日様子を見るという判断が今でも合理的な場面はある。 Xbox Modeについては、企業環境での扱いを事前に決めておくことを勧める。ゲーミング用途のPCと業務用PCが混在する環境では、GPOやIntuneポリシーでの制御が必要になる可能性があるため、GAリリース前に動作を把握しておきたい。 筆者の見解 WindowsのInsider Buildを細かく追い続けることの意義は、数年前と比べて確かに薄れている。機能の追加ペースとリリースの質のバランスが崩れていた時期もあった。 ただ、今回の4月ビルド群を見ると、「ユーザーが実際に困っている場面への対応」という姿勢が随所に見える。Secure Boot証明書のUIはその典型で、技術的に難しいことをやっているわけではないが、現場の痛みに向き合った改善だ。こういう地道な積み上げが、長期的な信頼の根拠になる。 Xbox Modeも、PCとコンソールの統合という大きな絵の中で捉えると、単なるゲーミング機能ではない。WindowsというプラットフォームがXboxエコシステムを取り込み、エンターテインメント領域でのユーザー体験を一本化する方向は、正しい戦略だと思う。実行が伴えば、の話だが。 2026年後半のWindows 11がどんな姿で正式リリースされるか、今回のInsider変更群はその輪郭を見せてくれている。Microsoftにはこの調子で「実際に困っている人を助ける」方向の改善を積み重ねていってほしい。それが一番の強みのはずだから。 出典: この記事は The 7 biggest Windows 11 Insider changes from early April — and why they matter for 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Metaが、CEO マーク・ザッカーバーグ自身の外見・声・口調・マナリズムを学習させたAIアバターを開発していると、Financial Timesが報じた。目的は「従業員がCEOとより身近に繋がれるようにするため」。さらにこの実験が成功すれば、一般クリエイターが自分のAIアバターを作れる仕組みにも展開する計画があるという。 何が起きているのか Metaが取り組んでいるのは大きく2本立てだ。 CEOアバターの社内活用: ザッカーバーグ本人が開発に関与しており、映像・音声に加えて過去の発言や意思決定のパターンを学習させている。社内コミュニケーションや従業員へのフィードバックを、本人の代わりにAIが行うことを想定している。 クリエイターへの展開: 2024年にはすでにクリエイターのAIペルソナのデモを公開しており、Instagramでのコメント対応にAIアバターを活用する実験も始まっている。今回のCEOクローン実験はその延長線上にある。 なお、Wall Street Journalが3月に報じた「ザッカーバーグ個人のAIエージェント（タスク補助用）」とは別プロジェクトとされており、Metaとしてもユースケースを複数の軸で平行展開している状況だ。 なぜこれが重要か この動きが示しているのは、「AIが人間を補助する」フェーズから、「AIが人間の代わりに出席・応答・判断する」フェーズへの移行が、トップ経営者レベルで現実のものになってきたという事実だ。 日本のIT現場でよく議論される「AIで業務効率化」は、往々にして「今まで人間がやっていた作業をAIが手伝う」止まりになっている。しかしザッカーバーグが試みているのはそれとは異なる。「CEOの分身が存在することで、CEOが物理的にその場にいなくても組織が動く」という設計思想だ。 これはエンタープライズにおけるNHI（Non-Human Identity）の考え方とも接続する。人間がボトルネックにならない組織設計を本気で実現しようとすれば、意思決定や承認プロセスをどこまでAIに委ねられるかが問われる。今回の報道は、その問いに対するMetaの一つの回答と見ることができる。 実務への影響 企業コミュニケーションの設計が変わる: 「社長メッセージ」「マネージャーの1on1」「全社向けFAQ」など、今は人間がコストをかけてこなしているコミュニケーション業務は、AIアバターが担える領域の候補になり得る。 クリエイターエコノミーへの影響: 日本でもYouTuberやVTuberが「24時間稼働のAI分身」を持てる時代が近づいている。ファンとのエンゲージメントをAIが維持しつつ、本人は創作に集中するモデルは、コンテンツ産業のコスト構造を大きく変える。 倫理・ガバナンスの整備が急務: AIアバターが「本人の見解」として発信した内容が、意図せず誤解を招いたり、法的・倫理的問題に発展したりするリスクは現実的だ。企業がAIアバターを導入する際には、どの範囲の発言を許容するか・どう訂正するかのガバナンス設計が不可欠になる。 筆者の見解 率直に言えば、これは非常に筋の通った実験だと思う。「忙しい人間が全部に対応する」モデルは根本的にスケールしない。ボトルネックは常に人間側にある。AIアバターは、その制約を構造的に取り除こうとする試みだ。 ただ、重要な論点はクオリティではなく「信頼の移転」にある。従業員はそのアバターを「本物のザッカーバーグ」として信頼して動いていいのか。フィードバックを受け取ったとき、それは本人の真意を反映しているのか。こうした問いに正直に答える仕組みがなければ、技術としては成立しても組織としては機能しない。 日本のIT現場では、まだ「AIに判断させる」ことへの心理的ハードルが高い。しかしその「心理的ハードル」自体が、実は根拠の薄い慣習である場合も多い。仕組みを設計し、責任の所在を明確にし、透明性を保てば、AIが「代理で存在する」ことは十分に許容できる。ザッカーバーグ自身がその実験台になる姿勢は、少なくともその意欲においては評価に値する。 「人間がいないと何も決まらない」組織から、「人間が不在でも必要な判断が回る」組織へ。その移行を本気でやろうとしている現場にとっては、今回の報道は参考にする価値のある事例だ。 出典: この記事は Mark Zuckerberg is reportedly building an AI clone to replace him in meetings の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIの最高収益責任者（CRO）Denise Dresserが日曜日に全社員へ送った4ページの社内メモが、The Vergeによって報じられた。その内容は、単なる社内向け激励文書ではなく、現在のエンタープライズAI市場の競争構造を鮮明に映し出すものだった。 メモが語る「プラットフォーム化」という戦略 メモの核心メッセージは一言で言えば「マルチプロダクト化によるスイッチングコストの構築」だ。Dresserはこう書いている。 「マルチプロダクト採用は、私たちを代替しにくくする」 「製品ラインが別々の会社として考えるのをやめよう。複数のエントリーポイントを持つプラットフォーム企業として、統合されたエンタープライズオファリングを提供する会社として考えよう」 これはSaaS企業が成熟期に必ず通る道だ。単一のキラープロダクトで市場に食い込み、その後プラットフォーム化して離脱コストを高める——Microsoftが何十年もかけて磨いた戦略を、OpenAIは急速に学習しようとしている。 実際、メモでは「9桁（1億ドル規模）の複数年・複数プロダクト契約が増加し、既存顧客が組織全体で標準化を進めている」と成果も報告されている。 競合への評価と本音 注目すべきはAnthropicへの言及だ。Dresserは「市場はかつてなく競争激化している」と認めつつ、こう続けた。 「Anthropicのコーディングフォーカスが彼らに初期の足がかりを与えた。しかし、プラットフォーム戦争においてシングルプロダクト企業でいることは望ましくない」 さらに、Anthropicが公表している年間収益レートは「誇張されている」と指摘し、「十分なコンピュートを確保しなかったことは戦略的な失策だった」と断言している。そしてAnthropicのビジネスモデルについて「恐怖・制限・エリートによるAI管理という物語で構築されている」とも評した。 これに対してOpenAIは「民主的なAI」を標榜し、サム・アルトマンCEOも2月に「Anthropicはリッチなユーザーのためにプレミアム製品を売っている」と発言している。 エンタープライズAIの「成熟フェーズ」が意味すること メモの中で特に重要なのは、「Enterprise AIは成熟フェーズに入った」という認識だ。Dresserはこう書く。 「生のモデル性能はまだ重要だが、もはやそれだけでは不十分だ。顧客が求めるのはフィット感——AIがワークフロー・ナレッジ・コントロール・日常業務にいかにうまく組み込まれるか、そしてスケールで展開・信頼・改善できるかだ」 これは日本のIT担当者にも直接関係する話だ。「どのモデルが最も賢いか」という比較軸から、「どのプラットフォームが自社のワークフローに最も深く統合できるか」という軸へのシフトが、すでにグローバルでは始まっている。 実務への影響——日本のエンジニア・IT管理者が今考えるべきこと 1. AI選定の軸を「性能」から「統合性」へ 半年ごとにモデルの序列が入れ替わる現状で、単体のモデル性能だけで選定すると継続的な乗り換えコストを払い続けることになる。既存の業務システム・IDプロバイダー・ガバナンスポリシーとの統合を一次評価軸に置くべきだ。 2. エンタープライズ契約の構造を理解する OpenAIが示した「複数年・複数プロダクト契約」モデルは、コスト予測可能性と優先サポートをセットで提供する。年度ごとの単発契約ではなく、ロードマップを見越した中長期の枠組みで検討する企業が、今後有利なポジションを確保しやすい。 3. NHI（Non-Human Identity）との連携を設計に組み込む AIエージェントが業務に深く入り込むほど、サービスプリンシパルやマネージドIDとの連携設計が重要になる。エージェントが自律的にループで動くアーキテクチャを見据えると、人間の承認を都度挟まずに安全に動ける仕組みをゼロから設計する必要がある。承認フローを後付けで追加しようとすると、後で大きなリファクタリングコストになる。 4. ベンダーロックインを恐れすぎない 「ロックインを避けて抽象化レイヤーを挟む」という判断は一見賢明に見えるが、統合の深さと引き換えに機能の上澄みしか使えなくなるリスクもある。ベンダーの推奨アーキテクチャには理由がある。標準的な道を選ぶことで再現性と保守性が上がる。 筆者の見解 このメモが示すのは、OpenAIが「賢いモデルを作る研究機関」から「エンタープライズプラットフォームベンダー」へと自己認識を転換したということだ。 その方向性自体は正しいと思う。モデル単体で競争しても、毎週どこかから「最強モデル」が登場する世界では持続的な事業にならない。プラットフォームとして根付かせることで初めて、顧客にとっての「インフラ」になれる。 ただし、「民主的なAI」vs「エリート向けAI」という対立軸の設定には少々違和感を覚える。企業が安全・信頼・ガバナンスを重視することは「恐怖と制限」ではなく、当然の要求だ。それを否定する方向でポジショニングするのは、エンタープライズ市場を本気で取りに行く会社の言葉としては奇妙に映る。 競合の戦略的失策を指摘することにエネルギーを使うよりも、プラットフォームの深化に集中した方が長期的には強い。そのことはOpenAI自身が一番よく知っているはずで、だからこそ「サイドクエストをやめてコアに集中せよ」というメッセージが社内に発信されているのだろう。 いずれにせよ、この「プラットフォーム戦争」の帰趨は、日本のエンタープライズIT投資の意思決定にも確実に影響を与える。今年後半にも噂されるIPOを含め、この競争の行方は引き続き注視したい。 出典: この記事は Read OpenAI’s latest internal memo about beating the competition — including Anthropic の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが「大量デプロイ」する時代が来た。そのインフラを誰が担うか——Vercelはその問いに真っ先に手を挙げている企業だ。CEO のギレルモ・ラウチ（Guillermo Rauch）氏が先週サンフランシスコで開催された HumanX カンファレンスに登壇し、同社の IPO 準備が整っていることを力強くアピールした。 ARRが1年で3.4倍——何が起きているのか Vercel の年間経常収益（ARR）は、2024年初頭の1億ドルから、2026年2月末時点で3億4000万ドルの run rate に達した。わずか2年余りで3倍以上という急成長だ。 この背景にあるのは、AIによるアプリ生成の爆発的な拡大である。ラウチ氏によれば、現在 Vercel のプラットフォーム上で稼働しているアプリの 30% はすでにエージェントが生成したもの だという。人間の開発者が書いたコードではなく、AIエージェントが自律的に生成・デプロイしたアプリが全体の3割を占める——この数字はインパクトが大きい。 同氏はこう語る。「この会社を始めた頃、デプロイできる人間は数千万人しかいなかった。今や世界中の誰もがアプリを作れる。」 AIエージェントは人間の開発者より遥かに高い頻度でデプロイを行う。人間なら1日数回のデプロイが、エージェントなら数百回・数千回になりうる。Vercel はその「エージェントの大量生産物」を受け止めるインフラとして位置づけを確立しつつある。 v0とエージェント対応——Vercelの戦略 Vercel は単なるホスティングサービスに留まらない。同社が提供する v0（バイブコーディングツール）は、非エンジニアでも自然言語でウェブアプリを生成できるツールだ。これが「誰でもアプリを作れる時代」のアクセラレーターとなっており、生成されたアプリの受け皿として Vercel 自身のインフラに流れ込む構造を作っている。 ラウチ氏は「エージェントは既存ソフトウェアを購入するより、カスタムソリューションを生成する方が簡単にする」と指摘する。つまり、SaaS購入ではなく「その場で生成して使う」という新しい消費パターンが生まれており、Vercelはそこに賭けている。 TAM（市場規模）に「天井はない」 ウォール街が Vercel に注目すべき点を問われたラウチ氏はこう答えた。「インフラの TAM は拡大した。そしてそこには天井がない。」 これは誇張ではない。従来のソフトウェア開発は「人間が書いた数の分だけデプロイがある」という前提だった。AIエージェント時代は、その前提が崩れる。エージェントが自律的にアプリを生成・デプロイし続けるなら、インフラ需要は人間の開発速度の制約を超えて成長する。 IPO市場は現在、AIによる産業破壊への懸念から冷え込んでおり、多くのスタートアップが上場計画を棚上げにしている。それでもラウチ氏が「準備はできている、より整ってきている」と公言する背景には、この成長軌道への自信があるのだろう。 実務への影響——日本のエンジニア・IT管理者にとっての意味 エンジニア向け Vercel + v0 の組み合わせは、プロトタイピングの速度を劇的に変える。社内ツールや PoC を「作るかどうか検討する」時間が、「とりあえず動かして確認する」時間に置き換わりつつある エージェントが生成したコードのレビュー・品質管理が新たなスキルセットとして浮上する。「書く力」より「評価する力」が問われる時代に備えよ Next.js を使っているチームは Vercel との親和性が高い。CDN・Edge Functions・デプロイパイプラインの統合コストを再評価する価値がある IT管理者・アーキテクト向け 社内でエージェントが自律的にアプリを生成・デプロイするシナリオが現実になりつつある。ガバナンス（どこに何がデプロイされているか）の設計を今から考えておく必要がある Cloudflare・AWS と競合する文脈での Vercel の強みは「フロントエンドとエッジ処理の垂直統合」。用途によって使い分けを検討せよ AIエージェントが生成するアプリのライフサイクル管理（削除・更新・監査）は未解決の課題。ここに管理者の出番がある 筆者の見解 Vercelの躍進が示しているのは、「エージェントが大量に動けるインフラを持っている者が次のラウンドを制する」という命題だ。 筆者が最近感じているのも同じことで、AIエージェントを活かす上でのボトルネックは「計算資源」や「モデル性能」ではなく、エージェントが自律的にループしながら作業を続けられる仕組みにある。人間が逐一承認・確認を求められる設計では、エージェントの本質的な価値を引き出せない。Vercel が「エージェントの大量デプロイを当然のこととして受け止めるインフラ」を整えているのは、この本質を理解しているからだろう。 NHI（Non-Human Identity）の文脈でも同じ話が成立する。サービスプリンシパルやマネージドIDでエージェントが自律動作できる環境を整えることで、初めて「人間のボトルネック」から解放される。Vercel のプラットフォームがエージェントフレンドリーに設計されているのは、この方向性と一致している。 一方で、エージェントが生成するアプリの品質・セキュリティ・ガバナンスはまだ手探り状態だ。「30%がエージェント生成」という数字は成長の証だが、その30%の品質担保をどうするかは次の課題になる。そこに日本のエンジニアが貢献できる余地は十分ある——「動かす」だけでなく「安全に動かし続ける」の部分は、まだ人間の出番が大きい。 IPO市場の冬に臆することなく「準備完了」と言えるだけの数字を積み上げてきたVercel。AIエージェント時代のインフラ競争は、まだ始まったばかりだ。 出典: この記事は Vercel CEO Guillermo Rauch signals IPO readiness as AI agents fuel revenue surge の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

スタンフォード大学が毎年発表するAI Index報告書の最新版が、業界に静かな衝撃を与えている。AI専門家と一般市民の間で、AIに対する期待と不安の温度差が急速に拡大しているというデータが明示されたからだ。日本のIT現場にとっても、この断絶は他人事ではない。 数字が語る「二つの世界」 報告書が引用したPewリサーチのデータによると、AIの普及について「懸念より期待が大きい」と答えた米国一般市民はわずか10%。一方、AI専門家の**56%**は「AIは今後20年間で米国社会にポジティブな影響を与える」と回答している。 医療分野では専門家の84%が楽観的な見方をしているのに対し、一般市民は44%にとどまる。雇用への影響については格差がさらに顕著で、専門家の73%がポジティブと答えるのに対し、一般市民でそう答えたのは23%に過ぎない。 経済全体への影響でも専門家69%対一般市民21%という乖離が確認されており、どの領域を切り取っても同じ構図が繰り返される。 「AGI論争」と「給料の心配」は別の話 この断絶の本質は、専門家と一般市民が「別の問い」を抱えていることにある。 AI業界のリーダーたちはここ数年、AGI（汎用人工知能）の到来というスケールの大きな問いに注力してきた。しかし一般の人々が気にしているのは、来月の給与が維持されるかどうか、電気代が上がらないかどうか、自分の仕事が奪われないかどうかだ。 Gen Z世代においてもこの傾向は顕著で、ギャラップの調査では若い世代がAIに対してより怒りを覚え、希望を失いつつあると報告されている。半数近くが毎日・毎週AIを実際に使っているにもかかわらず、だ。 これは重要な示唆を含む。使っているからこそ不安を感じているという逆説的な構造が生まれている可能性がある。 実務への影響：日本のIT現場が直面すること この認識ギャップは、企業のAI推進担当者にとって非常に実践的な問題だ。 導入側のコミュニケーション設計が問われる。 経営層や技術部門が「生産性向上」「競争力強化」を掲げてAIツールを展開しようとしても、現場の従業員が「自分の仕事がなくなるのでは」という不安を抱えていれば、定着率は上がらない。ROI以前に、心理的安全性の確保が先決になる。 具体的なヒントとして： AI導入の目的を「人員削減」ではなく「単純作業からの解放」として明示化し、実際にそれを実現した事例を社内で積極的に共有する AIに仕事を「奪われた」ケースではなく、AIによって「できることが増えた」ケースをロールモデルとして前面に出す エネルギーコストやデータセンター問題など、AIの「負の外部性」にも正直に向き合う姿勢を組織として示す 日本企業はこうした対話をすることなく、トップダウンでツール導入を進めがちだ。それが現場の消極的抵抗や「使っているふり」につながる。 筆者の見解 この報告書を読んで感じるのは、「当然の結果だ」という冷めた感想だ。 AI業界のリーダーたちは、自分たちが開発しているものが「もし何もしなければ多くの人にとって最悪の結果をもたらす」と公言しながら、なぜ一般市民が不安を持つのかに驚いている——というのは、率直に言って筋が通らない。 重要なのは「AIを使うか使わないか」という二項対立ではない。「誰にとって、どのように役立つのか」を具体的に示せるかどうかだ。生産性が10%上がるという抽象的な数字より、「この業務がなくなった分、あなたはこの業務に集中できる」という具体的な文脈の方がはるかに響く。 技術の優劣を論じる前に、人の不安と向き合う設計が必要だ。その意味で、この断絶を「無知な一般市民の問題」と捉える視点は危うい。むしろ、専門家側のコミュニケーション能力と共感力の欠如として捉え直すべきだろう。 仕組みを作れる人間の数は少なくなっていく。だからこそ、残る人間が担うべき役割は「技術を動かすこと」ではなく「技術と人間の間を橋渡しすること」になっていく。その観点から見ると、この報告書が示す断絶を埋める作業こそ、次世代のIT人材に求められる最重要スキルの一つになるかもしれない。 出典: この記事は Stanford report highlights growing disconnect between AI insiders and everyone else の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがOpenClawに類似した自律エージェント機能をMicrosoft 365 Copilotに統合すべく開発を進めていることが、The Informationの報道で明らかになった。エンタープライズ顧客を主なターゲットとし、オープンソース版OpenClawが抱えるセキュリティリスクを解消する形での提供が検討されている。詳細はMicrosoft Build 2026（6月開催）での発表が予想されている。 OpenClawとは何か、そしてなぜMicrosoftが動くのか OpenClawは、ユーザーのコンピューター上でローカルに動作し、ユーザーに代わってさまざまなタスクを実行するエージェントを生成できるオープンソースツールだ。マルチモデル対応ながら、多くのユーザーに選ばれているモデルは特定のものに集中しており、その人気ぶりはMac Miniの売上急増という形で市場にも影響を与えているほどだ。 Microsoftがこの動きを無視できない理由は明快だ。ユーザーはすでにOpenClawのような自律エージェントの「本物の価値」を体験し始めている。検索して答えを返すだけのアシスタントではなく、長時間にわたるマルチステップタスクを自律的に完遂するエージェントへの需要が、想定より速いペースで高まっている。 Microsoft製エージェントの現状整理 Microsoftはここ数ヶ月で複数のエージェント系機能を発表しており、今回の報道はその流れの一部として理解すると整理しやすい。 Copilot Cowork（3月発表）: M365アプリ上で直接アクションを実行できる設計。チャットウィンドウで回答を返すだけでなく、アプリ内の操作を代行する。「Work IQ」と呼ばれるパーソナライゼーション層を持ち、クラウドで動作する。 Copilot Tasks（2月プレビュー）: メールの整理から旅行・予定の調整まで、Office外のタスクも扱えるエージェント。こちらもクラウド動作。 今回の新エージェント（開発中）: 「常時稼働」が核心コンセプト。いつでもアクションを起こせる状態を維持し、長期間にわたるマルチステップタスクを完遂できるエージェントとして設計されている。ローカル動作かクラウド動作かは現時点では未確定だ。 なぜこれが重要か——「副操縦士」から「自律エージェント」へ これらの動きが示す本質的な変化は、AIの役割モデルのシフトだ。 これまでのCopilotが象徴する「副操縦士（Copilot）」パラダイムは、人間が常にハンドルを握り、AIはあくまで提案・補助に徹するモデルだった。しかしOpenClawのような自律エージェントが普及し始めたことで、ユーザーは別のパラダイムを知ってしまった。目的を伝えれば、確認や承認を求めずに自律的にタスクを遂行するエージェントの体験だ。 企業のIT部門が注目すべき点はセキュリティ設計にある。オープンソースのOpenClawはその柔軟性と引き換えにセキュリティリスクが「famously risky（悪名高いほどリスキー）」と評されている。Microsoftが企業向けに提供するのであれば、条件付きアクセス、監査ログ、権限スコープの制限といったエンタープライズグレードの統制が組み込まれることが期待される。 日本企業においては、情報漏洩リスクへの懸念からローカルLLMや自律エージェントの導入を躊躇しているケースが多い。Microsoftが既存のM365テナント管理・コンプライアンス基盤と統合した形でエージェントを提供できれば、その導入障壁は大きく下がる可能性がある。 実務での活用ポイント 今すぐできること: Copilot Coworkのプレビューが利用可能であれば、まず小さなワークフローで試してみる。メール処理・会議サマリーなど、完全自律でなくてよい用途から始めると現実的 自社のM365管理者は、エージェントに付与する権限スコープの設計を今から検討しておく。「エージェントが何にアクセスできるか」の設計はセキュリティの要 Microsoft Buildに向けて注目すべきポイント: ローカル動作 vs クラウド動作の最終的な仕様 既存のCopilot Tasks・Coworkとの役割分担がどう整理されるか コンプライアンス・監査ログの具体的な仕様 NHI（Non-Human Identity）との統合——サービスプリンシパルやマネージドIDを使ったエージェントの権限管理がどの程度洗練されているかは、エンタープライズ展開の鍵になる 筆者の見解 Microsoftがこの方向に動いているのは正しい。問題は、どれだけ本気でやり切るかだ。 CoworkもTasksも、方向性は間違っていない。しかし「常時稼働で自律的に動くエージェント」というコンセプトは、これまでのCopilot系ツールが慎重に避けてきた「確認なしにアクションを起こす」設計を必要とする。ここに本当のハードルがある。 人間が承認するたびにエージェントが止まる設計では、長時間マルチステップタスクという価値は生まれない。ボトルネックは常に人間の関与にある。NHIを活用してエージェントが人間の承認なしに業務を実行できる範囲を設計・拡大していくことが、エンタープライズにおける自律エージェントの本質的な価値を引き出す道筋だ。 Microsoftにはエンタープライズ向けのガバナンス基盤という唯一無二の強みがある。セキュリティと自律性のバランスを他社より適切に取れる立場にいる。その強みを活かした設計で、6月のBuildに臨んでほしい。今度こそ、「これは本物だ」と言えるものを見せてもらいたいと思っている。 出典: この記事は Microsoft is working on yet another OpenClaw-like agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年初頭、アンダーグラウンドのサイバー犯罪フォーラムに「Storm」と名乗る新型インフォスティーラーが登場した。月額1,000ドル以下というサブスクリプション型で提供されるこのマルウェアは、これまでのクレデンシャル窃取型マルウェアとは一線を画す設計思想を持っている。単なる亜種ではなく、エンドポイントセキュリティの進化に対してマルウェア側が「回答」を出してきた事例として、IT管理者は真剣に向き合う必要がある。 なぜ「サーバー側復号」が危険なのか 従来のインフォスティーラーは、被害者のマシン上でブラウザの認証情報データベース（SQLite）に直接アクセスし、ローカルで復号を行っていた。このアプローチはエンドポイントセキュリティツールに検知されやすく、「ブラウザDBへの不審なアクセス」がシグネチャとして広く知られるようになっていた。 Googleが2024年7月にChrome 127でApp-Bound Encryption（アプリ紐付き暗号化）を導入したことで、ローカル復号はさらに困難になった。しかし攻撃者はこれに対して「ローカルでの復号をやめる」という発想の転換で応じた。 Stormが採用したのは、暗号化されたままのブラウザデータを攻撃者のサーバーに送り、そこで復号するというアーキテクチャだ。エンドポイント側では「暗号化ファイルの転送」しか発生しないため、多くの既存ツールが依存するテレメトリデータが生成されない。ChromiumベースのブラウザだけでなくFirefox、Waterfox、Pale MoonなどGeckoエンジン系も対象にしている点も、より広範な被害を可能にしている。 MFAを無力化するセッションハイジャック Stormが収集するのはパスワードだけではない。セッションクッキー、Googleアカウントトークン、オートフィルデータ、クレジットカード情報、閲覧履歴など、「認証済みセッションを完全再現する」のに必要なものすべてが標的だ。 さらに、収集後の操作を自動化している点が際立っている。Google Refresh TokenとSOCKS5プロキシを組み合わせることで、被害者の認証済みセッションをオペレーターのパネル上でそのまま「復元」できる。パスワードを一切使わず、MFAの検証をスキップして、SaaSツールや社内システム、クラウド環境に侵入できる。 セキュリティリサーチャーのVaronisが以前に公開した「Cookie-Bite」の研究では、Azure Entra IDのセッションクッキーを窃取することでMFAが意味をなさなくなる実態が示されていた。Stormはそのテクニックをサブスクリプション機能として「製品化」したものと見てよい。 収集範囲とインフラ設計 Stormはブラウザ以外にも触手を伸ばしている。Telegram、Signal、Discordのセッションデータ、仮想通貨ウォレット（ブラウザ拡張・デスクトップアプリ両対応）、複数モニターのスクリーンショット、システム情報を含む。処理はすべてメモリ上で実行されるため、ディスクへの痕跡が残りにくい。 インフラ面では、オペレーターが独自のVPS（仮想プライベートサーバー）をStormの中央サーバーに接続する構成を採る。窃取データが共有インフラを経由しないため、法執行機関や不正利用申告があっても中央サーバーへの影響を局所化できる設計だ。 実務への影響 このような脅威に対して、日本のIT管理者・エンジニアが今すぐ見直すべきポイントを整理する。 セッション管理の強化：セッショントークンの有効期間を短く設定し、IPアドレスや地理情報の変化を検知した際に再認証を強制するポリシーを導入する。Conditional Access（条件付きアクセス）でデバイスコンプライアンスを要件にすることも有効だ。 エンドポイント検知だけに頼らない：Stormはエンドポイント側のシグネチャ検知を意識的に回避する設計になっている。ネットワーク層での異常な外部通信の監視、ユーザー行動分析（UEBA）など、多層防御の実践が欠かせない。 フィッシング耐性の高い認証への移行：FIDO2/パスキーはセッションクッキーではなくデバイス紐付きの認証を行うため、クッキー窃取型攻撃に対して本質的に強い。移行コストはあるが、MFAの「次の一手」として優先度を上げるべきだ。 ユーザーディレクトリへのファイルアクセス制限：Stormはドキュメントフォルダも標的にする。機密ファイルを個人の作業領域に放置しない運用、DLPポリシーの見直しも並行して行いたい。 筆者の見解 Stormが示す最大の教訓は、「セキュリティ機能を強化するとマルウェアが設計を変えて回避してくる」というイタチごっこが加速していることだ。GoogleのApp-Bound Encryptionは正しい取り組みだったが、攻撃者は「ローカルで戦わない」という選択肢に移行した。これはセキュリティ対策が無意味だという話ではなく、対策の層を増やすことでそのたびに攻撃コストが上がるという構造をしっかり理解した上で設計する必要があるということだ。 ゼロトラストの観点からすると、今回の手口はまさに「認証済みセッション＝信頼」という前提を崩してくる攻撃だ。ネットワークに入れたからといって、その後のアクセスを無条件に信頼するアーキテクチャは限界を迎えている。セッション継続性そのものを検証し続ける仕組み——IPの変化、デバイス状態の変化、アクセスパターンの異常——を組み込むことが、次の標準になっていくと筆者は見ている。 NHI（Non-Human Identities）の観点でも示唆がある。人間の認証情報を狙う攻撃がここまで洗練されてくると、人間がサービスアカウントやAPIキーを直接扱う運用リスクが改めて浮き彫りになる。マネージドIDやサービスプリンシパルへの移行を進め、人間の介在を減らすことが、こうした攻撃のアタックサーフェスを根本から縮小することにつながる。 月額1,000ドル以下でここまでの機能が「製品」として手に入る時代に、防御側が個別の対策を積み上げるだけでは追いつかない。アーキテクチャレベルでの見直しを、今年の優先課題に据えてほしい。 出典: この記事は The silent “Storm”: New infostealer hijacks sessions, decrypts server-side の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界最大級のオンライン旅行予約プラットフォームであるBooking.comが、第三者による不正アクセスを確認した。同社は既存・過去の予約に紐づくPINを強制リセットし、影響を受けたユーザーへの個別通知を進めている。単なるパスワードリセットで終わる話ではなく、漏洩した情報の組み合わせが後続攻撃の「燃料」になりうる点で、注意が必要だ。 何が漏洩したのか 今回流出が確認されているデータは以下の通りだ。 氏名（フルネーム） メールアドレス 郵便住所 電話番号 宿泊施設とのやり取りメッセージ 決済情報やパスワードの漏洩は現時点では言及されていないが、上記の組み合わせは「なりすましフィッシング」に十分すぎる素材になる。特に「施設とのやり取りメッセージ」が含まれている点が危険で、攻撃者は具体的な予約内容を把握した上で「宿泊施設からの連絡」を装えてしまう。 Booking.comはこの件について「不審なメールやSMSのリンクはクリックしないよう」呼びかけており、同社が銀行振込や機密情報を求めることは絶対にないと明言している。 アプリ通知なしの混乱 今回のインシデントで注目すべき運用上の問題がある。警告メールを受け取ったユーザーが、アプリ側にはまったく通知が届いていないとして、メールの正当性を疑うケースが続出した。 公式ドメイン（noreply@booking.com）からの送信であっても、アプリ内通知と同期されていなければ「フィッシングでは？」と疑われるのは自然な反応だ。セキュリティインシデントの通知設計として、「複数チャネルで同時に伝える」という原則が守られていなかったことが、混乱を増幅させた。 さらにReddit上では、プライベートな予約情報を知っているらしい詐欺師から接触されたとの報告も上がっている。今回の侵害との直接の関連は確認されていないが、タイミングと情報の具体性から見て無関係とは考えにくい。 実務への影響——日本のエンジニア・IT管理者へ 1. 「漏洩情報を使ったフィッシング」への備えを組織に周知せよ 今後数週間〜数ヶ月にわたって、Booking.comの予約内容を詳しく知った攻撃者からのフィッシングメールや電話が増加する可能性がある。組織のセキュリティ担当者は、従業員向けに「公式を装った連絡であっても、リンクのクリックや口頭での情報提供はしない」というリマインドを早急に行うべきだ。特に出張管理担当者や経理は標的になりやすい。 2. 個人情報＋予約情報の組み合わせリスクを理解する 今回のような「個人情報＋コンテキスト情報」の組み合わせ漏洩は、単純なリスト型攻撃より遥かに精度の高いソーシャルエンジニアリングを可能にする。「攻撃者が具体的な日付・施設名・金額を知っている」状況での問い合わせを想定した訓練は今後ますます重要になる。 3. サードパーティSaaSのインシデント対応を評価軸に入れる Booking.comは世界的な大企業でありながら、今回は被害規模・影響ユーザー数すら開示していない。企業として出張やイベントでBooking.comを利用している場合、ベンダーのインシデント対応の透明性は契約評価に含めておくべき観点だ。GDPRやAPPI（個人情報保護法）の観点から、対応の遅さや情報開示の不透明さはリスク評価に直結する。 筆者の見解 セキュリティという分野は個人的に好物とは言えないが、今回のインシデントには技術的な興味を引く構造がある。 漏洩したデータ単体ではなく、「予約という行為に紐づいたコンテキスト情報」が攻撃側に渡った点が本質的な危険だ。氏名とメールアドレスの組み合わせなら今どきさほど珍しくないが、「〇月〇日に〇〇ホテルに泊まることを知っている人間」からの連絡は、普段フィッシングを見破れるリテラシーの高いユーザーでも引っかかりやすい。攻撃の精度が上がっている。 また、通知設計の失敗が「公式通知をフィッシングと誤認させる」という皮肉な結果を生んだことも見逃せない。セキュリティは技術だけでなく、ユーザー体験の設計でもある。どれだけ堅牢なシステムを作っても、通知の届け方を間違えれば「本物が偽物に見える」状況を自ら作り出してしまう。 ゼロトラストの観点から見れば、「予約PINでの本人確認」という設計自体も問いなおす余地がある。予約番号＋PINという組み合わせは、両方が漏洩した瞬間に無効化される。認証要素の多様化と、コンテキストベースのリスク評価を組み合わせた設計への移行は、旅行プラットフォームに限らず、あらゆるBtoCサービスで検討すべき方向性だ。 今回のBooking.comの対応は「発見→封じ込め→通知」という基本ステップは踏んでいる。しかし規模の開示なし、アプリ通知の欠如、詐欺被害との関連不明確——という課題を抱えたまま幕引きにするなら、「対応した」とは言えない。世界規模のプラットフォームだからこそ、インシデント対応の透明性で業界標準を作ってほしいと思う。 出典: この記事は New Booking.com data breach forces reservation PIN resets の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365のビジネスアカウントを狙い、MFA（多要素認証）すら回避するフィッシングキットとして知られていた「W3LL」が、FBIとインドネシア当局の協調捜査によって壊滅させられた。開発者の逮捕と同時にインフラが押収されたこの事件は、単なる犯罪者一人の逮捕にとどまらない——フィッシング攻撃の「フルサービス化」という深刻なトレンドを改めて浮き彫りにしている。 W3LLとは何だったのか W3LLは500ドルで購入できるフィッシングキットで、企業のログインポータルを精巧に模倣したサイトを誰でも作れるようにする仕組みだった。単にパスワードを盗むだけでなく、認証セッショントークンをリアルタイムで傍受できる点が特に危険視されていた。 仕組みはいわゆるAiTM（Adversary-in-the-Middle）攻撃だ。攻撃者のインフラが正規のMicrosoftログインページを中継する形でユーザーを誘導し、入力されたパスワード・ワンタイムMFAコード・セッションクッキーをすべて横取りする。ユーザーは正規サイトにログインしたつもりでいるが、その裏で攻撃者は盗んだセッションクッキーを使い、MFA認証を再度求められることなくアカウントに侵入できる。 一度アカウントを乗っ取ると、攻撃者はメールの監視・転送ルールの設定・なりすまし請求書の送付といったBEC（ビジネスメール詐欺）攻撃へと移行する。2019年から2023年にかけて2万5,000件超の侵害アカウントが売買され、被害額は2,000万ドル（約30億円）以上にのぼるとされている。 MFAを「有効にしているから安全」では終わらない時代 ここで立ち止まって考えたいのが、「MFAを設定しているから問題ない」という認識だ。W3LLはまさにその前提を崩すために設計されていた。 MFAはフィッシングに対して非常に有効な防御策であることは間違いない。しかし、AiTM型の攻撃はMFAの認証成功後に発行されるセッションクッキーを盗む。つまり、「認証の成功」自体を悪用するという発想だ。これに対抗するには、MFAを使いつつも、セッションの継続的な検証を組み合わせる必要がある。 具体的には、Microsoft Entra ID（旧Azure AD）の条件付きアクセスポリシーと継続的アクセス評価（CAE）の活用が有効だ。さらに、パスワードレス認証やフィッシング耐性のあるMFA——具体的にはFIDO2セキュリティキーやWindows Helloを使った認証——はAiTM攻撃に対しても根本的に強い。セッションクッキーを盗んでも、公開鍵ベースの認証は再現できないためだ。 実務での活用ポイント 1. フィッシング耐性MFAへの移行計画を立てる SMS・メール・TOTP（時間ベースのワンタイムパスワード）はAiTM攻撃に対して脆弱だ。まずは特権アカウントからFIDO2キーまたはMicrosoft Authenticatorの「番号照合＋位置情報」機能を有効にすることを検討したい。 2. Microsoft Defender for Office 365 のSimulated Phishing攻撃シミュレーションを実施する ユーザーが実際にどのフィッシング手口に引っかかりやすいかを把握するには、攻撃シミュレーショントレーニングが効果的だ。W3LL型の中継フィッシングパターンもシミュレーション対象に含める。 3. 不審なメールルール・転送設定の自動検知を設定する BEC攻撃は侵入後に静かに行われる。Microsoft 365の監査ログや、Defender for Cloud Appsのアラートで「新しい転送ルールが作成された」通知を有効にしておくと、侵害後の横展開を早期検知できる。 4. NHI（Non-Human Identity）の認証フローも同様に見直す BECはアカウントを踏み台にするが、サービスプリンシパルやAPIキーが同様に盗まれていないかも確認が必要だ。特に長期間有効なシークレットが発行されたままになっている場合は整理の機会だ。 筆者の見解 W3LLの特筆すべき点は、フィッシングを「個人の手作業」から「フルサービスSaaS型の犯罪基盤」へと昇格させたことだ。W3LLは単なるツールではなく、マーケットプレイス・サポート・アップデート提供まで含むプラットフォームだった。犯罪のハードルを下げ、技術力のない攻撃者でもM365アカウントを狙えるようにした。 逆説的に聞こえるかもしれないが、こういうニュースが出るたびに思うのは、ゼロトラストの原則は正しかったということだ。「ネットワーク内にいるから信頼する」「MFAを通過したから信頼する」という静的な前提を壊し、継続的に検証し続ける仕組みこそが求められている。 アメリカとインドネシアの初の協調摘発という側面も見逃せない。サイバー犯罪は国境を越える一方で、これまで法執行機関の協力体制は遅れていた。今回の案件が新しい国際連携の先例になるとすれば、長期的な抑止力として意味がある。 一方で正直に言えば、W3LLを壊滅させても類似のサービスは他にいくつも存在する。Tycoon2FAやEvilTokensなど、同様の仕組みを提供するプラットフォームは今も動いている。根本的な対策は攻撃が成立しにくい認証基盤を作ることにあり、それには地道な設定変更と、ユーザーへの継続的な教育が不可欠だ。 「今の設定で問題が出ていないから大丈夫」は通用しない。W3LLの2万5,000件の被害者の多くも、被害に気づくまでは「問題ない」と思っていたはずだ。 出典: この記事は FBI takedown of W3LL phishing service leads to developer arrest の内容をもとに、筆者の見解を加えて独自に執筆したものです。

組み込みシステムやIoTデバイスに広く使われるTLS/SSLライブラリ「wolfSSL」に、攻撃者が偽造した証明書を正規のものとして受け入れさせてしまう深刻な脆弱性が発見された。影響範囲は世界50億以上のアプリケーション・デバイスに及ぶとされており、特に産業用制御システムや車載システムを扱う国内エンジニアは対応を急ぐ必要がある。 何が問題なのか：ECDSA署名検証の穴 今回の脆弱性はCVE-2026-5194として追跡されており、wolfSSLがECDSA（楕円曲線デジタル署名アルゴリズム）署名を検証する際に、ハッシュアルゴリズムの種類やサイズを適切にチェックしていないことが原因だ。 具体的には、証明書検証の関数が「鍵の種類に対して本来必要なサイズより小さいダイジェスト」を受け入れてしまう。ダイジェストが小さいほど偽造・再現が容易になるため、攻撃者はこの隙を突いて正規CAによって署名されたかのような偽造証明書を対象デバイスに受け入れさせることができる。 影響を受けるアルゴリズムはECDSA/ECCだけにとどまらず、DSA、ML-DSA（Post-Quantum）、Ed25519、Ed448にも及ぶ。特にECCとEdDSAまたはML-DSAを両方有効にしているビルドは最優先でアップデートが必要だ。 wolfSSLの位置づけ：「縁の下」だからこそ怖い wolfSSLはOpenSSLやMbedTLSと並ぶ軽量TLS実装で、Cで書かれた組み込み向けライブラリだ。スマートルーター、産業用センサー、車載ECU、さらには航空宇宙・防衛分野の機器にも採用されている。 問題はその「縁の下の力持ち」的な性質にある。アプリケーション開発者がOpenSSLを直接使っている場合と異なり、wolfSSLはベンダーのSDKやファームウェアの深部に静かに組み込まれていることが多い。自分の組織がwolfSSLを使っているかどうか、IT部門が把握していないケースは珍しくない。 なおRed HatはMariaDBへの影響を「なし」としているが、これはMariaDBがwolfSSLではなくOpenSSLを使っているためだ。ソフトウェアスタックの依存関係の把握がいかに重要かを示す好例だ。 対応バージョンと確認方法 本脆弱性はwolfSSL 5.9.1（2026年4月8日リリース）で修正済みだ。 対応の優先度は以下の通り整理できる： wolfSSLを直接使用している開発者: 5.9.1へ即時アップデート Linuxディストリビューションのパッケージ経由: 各ディストリビューションのセキュリティアドバイザリを確認 組み込み機器・IoTデバイス管理者: デバイスメーカーやSDKベンダーのダウンストリームアドバイザリを待ちつつ、影響範囲の洗い出しを先行して実施 実務への影響：日本のIT現場では何をすべきか エンタープライズのIT管理者にとって、今回の脆弱性は「サーバーのパッチを当てれば終わり」ではない。以下の点を確認してほしい。 SBOMの整備が急務　自社製品・調達システムに使われているオープンソースライブラリを把握するSBOM（Software Bill of Materials）が整備されていなければ、今回のような脆弱性への対応は常に後手に回る。特にOT（運用技術）系システムを持つ製造業・インフラ事業者は、ソフトウェアサプライチェーンの棚卸しを今すぐ始めるべきだ。 証明書の信頼チェーンを過信しない　TLSの証明書検証は「信頼の基盤」だ。今回の脆弱性が示すように、その基盤自体が揺らぐリスクがある。ゼロトラストアーキテクチャの文脈では、「証明書があるから信頼する」ではなく、継続的な検証と最小権限の組み合わせこそが正しいアプローチとなる。 パッチ適用のサプライチェーン追跡　wolfSSLのような組み込みライブラリは、アップストリームのパッチがデバイスに届くまでにメーカー→ODM→SI→ユーザーと複数段階を経る。パッチ適用状況をエンドツーエンドで追跡できる体制を持っているかどうかが問われる。 筆者の見解 wolfSSLはその小さなフットプリントゆえに「見えないところで動いている」ライブラリの典型だ。今回の脆弱性発見で改めて思うのは、NHI（Non-Human Identity）の管理とソフトウェアサプライチェーンの可視化は、実は同じ問題の別側面だということだ。 サービスプリンシパルやマネージドIDを使った自動化が進む一方で、それらの認証基盤を支えるTLSライブラリが適切に管理されていなければ、自動化の恩恵を安全に享受することはできない。NHIが増えれば増えるほど、その通信を保護する暗号基盤の健全性が業務効率と直結する。 組み込みやIoTの世界は「今動いているから大丈夫」という感覚が根強い。しかし暗号の脆弱性は静かに、そして確実に悪用可能な状態で潜んでいる。SBOM整備と定期的なサプライチェーン監査を「コスト」ではなく「インフラ」として位置づける組織だけが、こうしたリスクに先手を打てる時代になった。 出典: この記事は Critical flaw in wolfSSL library enables forged certificate use の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows Updateを装った攻撃は以前から存在するが、今回確認された手口はその精巧さが際立つ。「Windows 11 24H2」の正規アップデートに見せかけたダウンロードが、ユーザーの知らないうちにシステムに侵入し、パスワードやクッキー、個人情報といった機密データを外部に送信するというものだ。正規のWindows Updateに不信感を持つユーザーほど罠にはまりやすいという点で、非常に巧妙な攻撃と言える。 何が起きているのか 攻撃者は「Windows 11 24H2」の公式アップデートに見せかけたインストーラーを配布している。見た目はMicrosoftの公式UIに酷似しており、ダウンロードページのデザインや証明書表示まで本物らしく作り込まれているケースがある。 インストールを実行すると、バックグラウンドでインフォスティーラー型のマルウェアが起動する。主な窃取対象は以下の通りだ。 ブラウザに保存されたパスワード・クッキー・オートフィルデータ 暗号資産ウォレットの認証情報 VPN・リモートデスクトップの接続情報 ローカルに保存されたドキュメント・スクリーンショット 窃取されたデータはC2サーバー（Command & Control）に自動送信される。ユーザーには「アップデートが完了しました」といった偽の完了画面が表示されるため、被害に気づくのが遅れる構造になっている。 どこからダウンロードされているのか 主な配布経路として確認されているのは、検索エンジンの広告枠に表示される偽サイト（SEOポイズニング）、SNSや掲示板に貼られたリンク、そしてスパムメールのリンク先だ。公式の microsoft.com や windowsupdate.com ではなく、紛らわしいドメイン名（例: windows-update-24h2.com のような形式）を使っているケースが多い。 URLを見れば判断できるが、アップデート通知に焦ったり、管理者から「早急に当てるように」と言われたりした場合に確認を省略してしまうのが人間の心理だ。 実務への影響 エンドユーザーへの注意点 最も確実な対策はシンプルだ。Windowsの更新は必ずWindows Update（設定→Windows Update）から行う。 外部サイトからダウンロードしたインストーラーでWindowsを更新することはMicrosoftが想定した使い方ではない。「作り手の意図を理解し、意図された使い方をする」という原則がここでも生きる。 IT管理者・情報システム部門への推奨事項 Windows UpdateのMDM/WSUS管理を徹底する: エンドユーザーが自分でアップデートを検索・ダウンロードする状況を作らない。IntuneやWSUSで配信を制御し、ユーザーが「外からダウンロードする必要がない」環境を整える EDR（Endpoint Detection and Response）の導入確認: インフォスティーラーはブラウザプロセスへのメモリアクセスなど特徴的な振る舞いをする。EDRが有効であれば検知・遮断できるケースが多い MFA（多要素認証）の全面適用: 仮にパスワードが窃取されても、MFAが有効であれば不正ログインを防げる。特にAzure AD（Entra ID）連携のアカウントではMFAは必須と考えるべきだ アプリケーション制御ポリシーの検討: Windows Defender Application ControlやApplocker等で、署名のない実行ファイルの起動をブロックする構成は有効な多層防御となる Windows Update適用タイミングについて 「すぐに当てたら壊れた」という報告が増えている現状では、数日様子を見てから適用するという判断も現場では合理的だ。ただしその「待ち時間」に偽アップデートの誘惑が増す点に注意したい。公式チャンネルのみ利用し、サードパーティからは絶対に取得しないというルールを組織として徹底することが、このリスクに対する最善の答えだ。 筆者の見解 この種の攻撃が繰り返されるたびに感じるのは、「禁止より仕組みで防ぐ」という原則の重要さだ。「怪しいサイトからダウンロードするな」と周知するだけでは不十分で、そもそもユーザーが外部からダウンロードする必要がない状態を作ることが本質的な対策になる。MDMで更新を管理し、MFAで認証を守り、EDRで振る舞いを監視する——この三層が揃っていれば、今回のような攻撃のインパクトは大幅に下がる。 セキュリティ界隈では当たり前の話ではあるが、「今動いているから大丈夫」という感覚で止まっている組織がまだ多い。攻撃の精巧さは年々増している。インフラ側の整備を後回しにするコストは、じわじわと、しかし確実に上がっていく。正面から向き合うなら今だ。 出典: この記事は Beware! This “Windows 11 24H2” update download can quietly steal your sensitive data の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Linus Torvaldsが、長年にわたって牽引してきたLinuxカーネルの最新メジャーバージョン「Linux 7.0」を正式リリースした。今回のリリースで最も注目すべきは、AIをカーネル開発プロセスそのものに取り込む姿勢を明確にした点だ。単なるバージョン番号の刷新ではなく、オープンソース開発の哲学そのものが変わりつつあるサインとも言える。 AI活用で何が変わったのか Linux 7.0では、AIが「コーナーケース（エッジケース）」の発見と修正を補助するかたちで開発に活用されている。カーネル開発において最もコストがかかるのは、ハードウェア依存のバグや特定条件下でのみ再現する不具合の特定だ。熟練エンジニアが何日もかけて追いかけていたような問題を、AIが統計的なパターン分析で候補を絞り込む——この組み合わせが、開発速度と品質の両立に貢献している。 また、パフォーマンス面でも大きな改善が報告されている。スケジューラ、メモリ管理、I/Oサブシステムにわたる最適化は、サーバーワークロードだけでなくデスクトップ環境での体感にも影響する。 なぜこれが重要か——日本のIT現場への影響 日本の大手エンタープライズ環境においても、Linuxカーネルは今やインフラの根幹を担っている。Azureをはじめとするクラウド基盤、コンテナオーケストレーション（Kubernetes）、オンプレミスのサーバー仮想化——いずれもLinuxカーネルの動作に依存している。 Linux 7.0がもたらすパフォーマンス改善は、クラウドインフラのコスト最適化に直接影響する可能性がある。同じワークロードをより少ないリソースで処理できるなら、それはそのままクラウド費用の削減につながる。 さらに注目すべきは、AI活用による開発プロセスの変化だ。「仕組みを作れる少数の人間と、それを回すAI」という構図がオープンソース開発の世界でも現実になってきた。コントリビューターの数ではなく、仕組みの巧みさが開発力を決める時代が近づいている。 実務での活用ポイント カーネルバージョン管理の見直し: Linux 7.0は出たばかりで本番投入を急ぐ必要はないが、開発・検証環境での評価は早めに始めたい。特にスケジューラ改善の恩恵はコンテナ密度に直結するため、Kubernetes環境での計測が有効だ。 ディストリビューションの採用タイミング: RHEL、Ubuntu、SUSEなど主要ディストリビューションが7.0をベースにしたリリースを出すまでには時間がかかる。焦らず、ディストリビューションのサポートサイクルを軸に計画を立てること。 AIによる開発補助の学習機会: カーネル開発チームのAI活用方法は、社内のソフトウェア開発プロセス改善にも応用できる。パターンマッチングによるバグ候補の絞り込みという考え方は、規模を問わず使える。 筆者の見解 Linux 7.0で特に興味深いのは、Torvaldsが「AIは補助ツール」という立場を維持しながらも、開発プロセスへの統合を実用段階に進めた点だ。 「AIに任せれば何でも解決」という過剰な期待でもなく、「AIは所詮ツールに過ぎない」という過小評価でもなく——AI活用による仕組みの進化を、実際に手を動かしながら積み上げている。これは非常に健全なアプローチだと感じる。 道の真ん中を歩くこと、再現性のある仕組みを選ぶこと、標準に則ること。オープンソースコミュニティが何十年もかけて培ってきたこの哲学は、AI時代においても変わらない強さを持っている。むしろ、AIを正しく使いこなすための土台として、この哲学の重要性が増しているように見える。 情報を追いかけることよりも、実際に手を動かして検証し、自分のスタックで何が起きるかを確かめる——Linux 7.0の評価も、そのスタンスで進めていきたい。 出典: この記事は Linux 7.0 arrives as Linus Torvalds embraces a new era of AI-driven kernel development の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11の初回セットアップといえば、PCを起動してから実際に使えるまでに「アップデートのインストール中…」という画面で長々と待たされるのが定番だった。Microsoftはこのペインポイントに手を入れ、初期設定中の必須アップデートをスキップしてデスクトップへ直接進めるオプションを追加した。 何が変わったのか これまでWindows 11の初期セットアップ（OOBE: Out-of-Box Experience）では、インターネット接続が検出されると自動的にWindowsUpdateのダウンロードとインストールが走り、ユーザーはその完了を待つしか選択肢がなかった。今回の変更では、このアップデートを「後で適用する」ことを選べるようになり、セットアップ完了後すぐにデスクトップへたどり着けるようになる。 アップデート自体がキャンセルされるわけではなく、バックグラウンドまたは後のタイミングで適用される仕組みだ。新品PCを開封してすぐ使いたいエンドユーザーにとっても、大量展開を管理するIT管理者にとっても、体感的な待ち時間は大きく短縮される。 実務での活用ポイント 企業展開シナリオでは特に恩恵が大きい。Windows Autopilotやキッティング作業でのOOBE処理時間が削減され、端末のキッティング効率が上がる。ただし、セキュリティポリシーとして「初回ログイン前にパッチ適用を完了させたい」という要件がある組織では、グループポリシーまたはIntuneの構成プロファイルで強制適用を維持するかどうかの判断が必要になる。 一般ユーザー・小規模事業者にとっては、新しいPCを受け取った日にすぐ作業を開始できるというシンプルな改善だ。アップデートは後で適用されるため、セキュリティ的な穴が長期間空くわけではない。 Windows Updateのタイミング管理という観点では、「すぐ当てたら壊れた」という報告が後を絶たない昨今、初期セットアップ時点でのアップデート強制をMicrosoft自身が緩める方向に動いたのは興味深い。本番稼働前の端末で不安定なアップデートを踏まないための緩衝材としても機能しうる。 筆者の見解 正直に言えば、Windowsのセットアップ体験の細かい改善に一喜一憂する時代は終わりつつある。それでもこの変更は「ユーザーの時間を尊重する」という当たり前の設計思想に基づいており、素直に評価したい。 Microsoftにはこれだけの技術力とユーザーベースがある。こういう地道な改善を積み重ねていくことは大切で、「なぜ今まで必須だったのか」と逆に問いたくなるほどだ。セットアップ体験の改善はエンタープライズのキッティングコスト削減にもつながる、実利のある変更だ。 AI機能やCopilotの話題が飛び交う中、こうした基本的なユーザー体験の底上げをきちんとやり続けることこそ、Windowsプラットフォームへの信頼を積み上げる王道だと思う。派手さはないが、正面から勝負できる力がMicrosoftにはあるのだから、こういう取り組みを地道に続けてほしい。 出典: この記事は Microsoft makes Windows 11 setup faster by letting you skip mandatory updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Office LTSC 2021のメインストリームサポートが2026年10月14日に終了する。アプリ自体は引き続き動作するものの、セキュリティ更新プログラムの提供が止まり、Microsoftによる技術サポートも受けられなくなる。同社は移行先としてMicrosoft 365サブスクリプションを明確に推奨しており、企業・官公庁向けに移行ガイドも整備し始めている。 Office LTSCとは何か、なぜ今問題になるのか Office LTSC（Long-Term Servicing Channel）は、常時インターネット接続ができない環境や、ソフトウェアバージョンを厳格に管理しなければならない規制業種向けに提供される永続ライセンス版のOfficeだ。工場のOTネットワーク、医療機関の閉域系端末、政府系の独立したシステムなど、「クラウドに出ていけない理由がある」環境で重宝されてきた。 2021年版はWindows 10/11と同じライフサイクルポリシーに則り、5年のサポート期間が設定されており、2026年10月が節目となる。この日以降もOfficeアプリは動作するが、脆弱性が発見されても修正パッチは提供されない。「動いているから大丈夫」は、セキュリティの観点では通用しなくなる。 Microsoftが強調するMicrosoft 365移行のメリット Microsoftが移行先として提示するMicrosoft 365は、常に最新バージョンが提供されるサブスクリプション型サービスだ。主なメリットとして以下が挙げられる。 常時最新のセキュリティ更新: パッチ適用の遅延リスクがなくなる AIアシスト機能（Copilot）との統合: 文書生成・要約・翻訳などの機能が利用可能になる OneDrive/SharePointとのシームレスな連携: デバイス間でのファイル共有・共同編集が標準化される 管理の一元化: Microsoft 365 管理センターでライセンスやポリシーを集中管理できる 実務への影響——日本のIT管理者が今すぐ確認すべきこと 日本の大企業・官公庁では、Office LTSCを採用しているケースが依然として多い。「サブスクリプションは予算計上しにくい」「調達規則の都合でバージョンを固定したい」という事情もある。それでも、2026年10月は現実として迫っている。 今すぐ着手すべきアクション： インベントリの確認: 社内でOffice LTSC 2021を使用している端末数とユーザーを洗い出す。ライセンス管理ツールがあれば活用する 移行要件の整理: 「本当にオフライン環境が必要な端末はどれか」を精査する。意外と多くの端末がMicrosoft 365へ移行できる状態だったりする 予算サイクルへの組み込み: 2026年度予算に移行コストを計上するなら、今から上申の準備が必要 LTSC 2024という選択肢の検討: どうしてもサブスクリプション移行が難しい場合、Office LTSC 2024（2024年9月リリース）への更新も選択肢になる。ただしこれはあくまでもつなぎの策と捉えるべきだ 筆者の見解 MicrosoftがLTSCからMicrosoft 365への移行を促すのは商業的な動機として当然だが、技術的な観点でも一定の合理性はある。パッチの遅延や適用漏れによるセキュリティリスクは現実の問題であり、クラウドサービスであれば更新が自動化・最適化されやすい。統合プラットフォームとして全体最適を図るという考え方からすれば、Microsoft 365への統一はシンプルで筋が通っている。 ただし、「Microsoftがそう言っているから」という理由だけで飛びつくのは早計だ。特に日本の医療・製造・公共セクターには、法令や調達ルールの壁があり、一律にクラウド移行できない事情がある。「禁止ではなく、安全に使える仕組みを整える」という発想が重要で、オフライン環境が本当に必要なのか、必要だとしてもセキュリティ補完策（ネットワーク分離、エンドポイント保護の強化など）を組み合わせることで移行コストと安全性のバランスをとれないか、丁寧に検討してほしい。 Microsoftには、LTSC利用者が安心して移行できるような移行支援策——コスト面でも技術面でも——をより手厚く用意してほしいところだ。企業のIT環境の多様性を理解した上で、現実的な選択肢を提示できるポジションにMicrosoftはあるはずだ。その力を発揮してもらいたいと思っている。 出典: この記事は Office LTSC 2021 support is ending, and Microsoft wants you to migrate to the cloud の内容をもとに、筆者の見解を加えて独自に執筆したものです。

サービスアカウント、APIキー、マネージドID、そしてAIエージェント——企業のシステムには今、人間のユーザーをはるかに超える数の「非人間ID（Non-Human Identities / NHI）」が存在している。SANS Instituteが2026年に実施した「State of Identity Threats & Defenses」調査によれば、こうしたNHIがサイバー攻撃者の主要ターゲットになりつつあることが改めて浮き彫りになった。 NHIとは何か、なぜ今問題なのか NHIとは、人間ではなくシステムやアプリケーション、自動化スクリプト、AIエージェントが使用するIDのことだ。具体的には以下が該当する。 サービスプリンシパル（Azure AD / Entra IDに登録されたアプリID） マネージドID（Azure VMやFunctionsに付与されるID） サービスアカウント（Active Directoryの従来型） APIキー・OAuthトークン CI/CDパイプラインのシークレット AIエージェントに付与された権限 問題の核心は「数の爆発」と「管理の放置」が同時進行していることだ。デジタル化・自動化の加速で、エンタープライズ環境のNHI数は人間アカウントの数十倍に達していることも珍しくない。しかし人間のアカウントと違い、NHIには多要素認証（MFA）が使えず、パスワードローテーションは手作業で後回しにされがちで、誰が何の目的で作ったかすら不明になっているケースも多い。 攻撃者はどう悪用するのか 攻撃者が好むのは「不正侵入」よりも「正規ログイン」だ。漏洩したAPIキーや長期有効なサービスアカウントのクレデンシャルを入手すれば、侵入検知をすり抜けながら長期間にわたって環境内を横移動できる。NHIは往々にして過剰な権限（必要以上のロール割り当て）を持ち、アクセスログの監視も甘いため、侵害されても発見が遅れやすい。 さらにAIエージェントの台頭が新たなリスクを生んでいる。自律的にAPIを呼び出し、データにアクセスし、外部サービスと連携するAIエージェントは、正しく管理されなければ攻撃者にとって「特権を持つ踏み台」になりうる。エージェントに付与した権限の棚卸しは、多くの組織でまだ手つかずだ。 実務での対策ポイント 1. 棚卸しから始める まず自社のNHIを把握せずして対策はできない。Entra IDの「エンタープライズアプリケーション」と「アプリ登録」の一覧、Active Directoryのサービスアカウント、各クラウドサービスのAPIキー発行履歴を洗い出し、「誰が・何のために・いつ作ったか」を記録する。 2. 最小権限の徹底 既存のNHIが必要以上のロールを持っていないか確認する。Azure環境であればMicrosoft Entra ID Governanceのアクセスレビュー機能を活用し、定期的に権限を見直す仕組みを作ることが重要だ。 3. Just-In-Time（JIT）アクセスの導入 常時アクセス権を付与するのではなく、必要なときだけ一時的に権限を昇格させるJITモデルへの移行を検討する。Microsoft Entra Privileged Identity Management（PIM）はNHIにも対応範囲が広がっており、サービスプリンシパルへの適用も進めるべきだ。 4. シークレットの自動ローテーション APIキーやクライアントシークレットの有効期限を短く設定し、Azure Key VaultやGitHub Actionsのシークレット管理機能を使った自動ローテーションを実装する。「手動でやるから後回し」が最大の脆弱性になる。 5. 異常検知の設定 NHIの通常の行動パターンを把握し、異常なAPIコール・深夜アクセス・普段と異なるリソースへのアクセスをMicrosoft Sentinel等でアラートする。 日本のIT現場への影響 日本の大手エンタープライズ環境では、オンプレミスのActive Directoryにサービスアカウントが山のように積み重なっている光景がいまだに珍しくない。クラウド移行の文脈でNHI管理のモダン化を後回しにした結果、ハイブリッド環境の「悪魔合体」状態が生まれ、攻撃サーフェスが見えにくくなっている。特にCI/CDパイプラインの普及で、GitHubリポジトリやAzure DevOpsに長期有効なシークレットが埋め込まれたままのケースは要注意だ。 筆者の見解 NHIの重要性は、単なるセキュリティリスクの話ではないと筆者は考えている。これは業務自動化の根幹に関わる問題だ。 ボトルネックは常に「人間」にある。承認フローが人間依存である限り、どれだけAIや自動化ツールを導入しても処理速度には限界がある。NHIをきちんと管理し、サービスプリンシパルやマネージドIDに適切な権限を与えて自律的に動かせる環境を作ることが、真の業務効率化の前提条件になる。NHI管理ができない組織は、自動化も進まない。 一方でセキュリティの観点から言えば、「今動いているから大丈夫」という発想は通用しない。10年前に作ったサービスアカウントが今もフルアクセス権限で生きていることは珍しくなく、それが侵害の入り口になる。ゼロトラストの文脈では、NHIも人間アカウントと同じレベルの「検証・最小権限・継続監視」が求められる。 AIエージェントに権限を与えてビジネスプロセスを動かすことへの期待は今後さらに高まる。だからこそ、今のうちにNHI管理の基盤を整えておくことが、次の自動化フェーズへの最短経路になる。「セキュリティ対策」ではなく「自動化投資」として取り組む視点が、組織の動き方を変えるはずだ。 出典: この記事は Non‑Human Identities Are Becoming a Prime Target in Identity Attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...