Tech News JP

MicrosoftはAI開発基盤「Microsoft Foundry」に新機能「AI Gateway Control Plane」を追加した。App Service上で動くAIエージェントを、Azure API Management（APIM）を裏側の実行基盤としながらFoundryの管理画面から一元的に登録・可視化できるようにするものだ。Foundry以外で動く外部エージェントも同じ管制塔に取り込める点がポイントで、App Service専用のAI基盤を個別に構築・運用する負担を軽減する狙いがある。 AI Gateway Control Planeの正体 API ManagementはこれまでもAzureにおけるAIゲートウェイの定番パターンだった。トークン単位のレート制限、セマンティックキャッシュ、コンテンツセーフティ、バックエンドの負荷分散など、LLM呼び出しを本番運用するうえで必要なガバナンス機能を一手に引き受けてきた実績がある。今回の変更は、この実績あるAPIMの機能を「Foundryの管理画面の裏側」に組み込み、開発者が個別にAPIMインスタンスをプロビジョニングし、ポリシーをゼロから設定する手間をなくした点にある。App Serviceで動くエージェントは、Foundry側の管理画面からエンドポイントを登録するだけで、レート制御や可観測性の恩恵を受けられるようになる。 App Serviceにとっての実質的な変化 これまでApp Service上でAIエージェントを動かす場合、ゲートウェイ機能が欲しければAPIMインスタンスを別途構築し、App Serviceとは別のライフサイクルで運用する必要があった。Control Planeの導入により、Foundry側がその管理レイヤーを肩代わりする形になり、社内で稼働する複数のエージェント（Foundry上で作ったものも、社内の別チームが独自に構築した外部エージェントも）を同じ場所で棚卸しできるようになる。これは「エージェントが増えすぎて誰が何を動かしているか把握できない」という、AIエージェント運用が本格化した組織が必ず直面する課題への回答だ。 実務への影響 日本のIT管理者にとって重要なのは、この機能がガバナンスと可視性の話であるという点だ。エージェントが部門ごとに乱立し始めると、コスト管理、セキュリティレビュー、監査対応のいずれも後手に回る。App Service上で既にAIエージェントを運用しているなら、独自に組んだAPIMポリシーをFoundry Control Plane側に寄せられないか棚卸しする価値がある。現時点ではプレビュー機能の可能性が高いため、リージョン提供状況や既存APIM構成との共存パターンを事前に確認してから移行を検討したい。エージェントの数が今後さらに増えることを前提に、早い段階で登録・可視化の仕組みを整えておく方が、後から棚卸しするより圧倒的に楽になる。 筆者の見解 今回の話は「AIエージェントを禁止するのではなく、安全に使える仕組みを提供する」という発想がそのまま形になった好例だと思う。エージェントの野良運用を止めようとして利用を制限すればするほど、現場は見えないところで独自にエージェントを動かし始める。それよりも、公式に提供された登録・可視化の仕組みが一番便利だと現場が感じる状態を作る方が、結果的にガバナンスは効く。APIMという実績あるコンポーネントを裏側に据え、Foundryという管制塔から個別インフラの面倒を減らすという設計思想は、まさに王道を行く堅実な選択だ。 Azureプラットフォームとしての信頼性や、Microsoft Entra IDを中心とした認証・認可の枠組みは今後も揺るがないと見ている。エージェントの数が指数関数的に増える時代において、「最も賢いAIを作る」競争と「最も多くのエージェントが安全に動作する基盤を提供する」競争は別物であり、後者でMicrosoftが積み上げてきたAPIMやEntra IDの資産は確実に効いてくる。App Serviceのような既存ワークロードにこの管制塔機能を波及させ続けることこそ、Microsoftが正面から勝負できる領域だと思う。 出典: この記事は Microsoft Foundry Now Has an AI Gateway Control Plane — What Changes for App Service の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Bunとは何か、そしてなぜClaude Codeに関係するのか Anthropicのコーディングエージェント「Claude Code」は、単体で動くネイティブバイナリとして配布されている。この中には、JavaScriptランタイム兼バンドラーである「Bun」がまるごと同梱されている。Bunは開発者Jarred Sumner氏が生み出した高速ランタイムで、これまでZig言語で書かれてきた。そのSumner氏本人が「BunをRustで書き直した」と明かし、しかも「Claude Code v2.1.181（2026年6月17日リリース）以降はすでにこのRust版を使っている。Linuxでの起動が10%速くなったが、それ以外はほとんど誰も気づかなかった。地味であることは良いことだ」と投稿した。 stringsコマンドが暴いた証拠 この主張を検証したのが著名開発者Simon Willison氏だ。手元のclaudeバイナリに対しUnixのstringsコマンドを使い、次の2点を確認している。 strings ~/.local/bin/claude | grep -m1 'Bun v1' を実行すると「Bun v1.4.0」が出力される。公開されているBunの最新版はv1.3.14（5月12日リリース）であり、v1.4.0はまだ正式リリースされていないプレビュー版のバージョン番号だった（その後、Bunのcanaryチャンネルbun upgrade --canaryとして公開されたことが判明）。 strings ... | grep -Eo 'src/[[:alnum:]_./-]+\.rs' を実行すると、src/bundler/bundle_v2.rsなど563個のRustソースファイルパスがバイナリ内から見つかった。旧来のZig実装ならこの痕跡は残らない。 さらに別の開発者は、BUN_OPTIONS="--preload=..." claude --version という形でBunに直接バージョンを出力させる手法も示し、同じく1.4.0であることを裏付けた。 静かな入れ替えが意味すること 重要なのは、Anthropicがバージョン発表もなく、しかもBun側でもまだ正式リリース前のcanaryビルドを、何百万台もの端末で動くClaude Codeの本番バイナリに組み込んでいた点だ。API互換性が保たれていれば、内部実装は黙って刷新してよい、というインフラ運用の思想がここに表れている。 実務への影響 日本のエンジニアやIT管理者にとっても示唆がある。第一に、いま配布されるCLIツールは「ただのスクリプト」ではなく、ランタイムごと同梱したネイティブバイナリであることが増えている。stringsのような古典的なUnixコマンドは、依存関係やライセンス、意図しない情報の混入をチェックする手段として今も有効だ。第二に、自社で配布するバイナリについても、想定外の文字列（デバッグ情報、内部パス、まれに秘密情報）が埋め込まれていないか、同じ手法で棚卸ししてみる価値がある。第三に、大手AIベンダーであっても基盤ランタイムのcanaryビルドを先行投入する運用は珍しくなく、破壊的変更を伴わない基盤刷新は積極的に取り込む文化がある、という一例として参考になる。 筆者の見解 今回面白いのは、新機能の話ではなく「中身がいつの間にか差し替わっていた」という運用姿勢そのものだ。派手な発表やメジャーバージョンアップを打たず、互換性を保ったまま土台を強くしていくやり方は、地味だが学びが多い。筆者は日頃からClaude Codeを実務で使い倒しているが、内部実装の細部を逐一追いかけるよりも、実際に使って成果を出すことのほうがずっと重要だと考えている。その意味で、今回の話は「気づかれないくらい自然に速くなっていた」という結果こそが評価に値する。 もう一つ心に留めておきたいのは、Simon Willison氏の姿勢だ。ベンダーの発表を鵜呑みにせず、自分の手元のバイナリを実際にstringsで覗いて検証する。この「自分で確かめる」態度は、AIツールが次々と登場する今の時代にこそエンジニアに求められる基本動作だと思う。 出典: この記事は Claude Code uses Bun written in Rust now の内容をもとに、筆者の見解を加えて独自に執筆したものです。

英Neowinの論説記事『Welcome to the end of budget smartphones — thanks to AI』が問題提起しているのは、AIデータセンター向けメモリ需要の爆発的増加が、スマートフォン向けの汎用メモリ供給を圧迫しているという構造的なゆがみだ。Samsung、SK hynix、Micronという世界の主要メモリベンダー3社が生産ラインをAIアクセラレータ向けの高付加価値製品に振り向けた結果、DRAMとNANDフラッシュの価格が高騰し、格安・ミドルレンジ帯のスマートフォンが採算割れで市場から姿を消しつつあるという。 HBM生産へのシフトがDRAM供給を圧迫する NVIDIAのH100/H200/B200やAMD Instinctシリーズといった AIアクセラレータには、HBM（High Bandwidth Memory：広帯域幅メモリ）と呼ばれる特殊なDRAMが大量に使われる。HBMは通常のDDR5メモリと同じシリコンウエハーの製造ラインを奪い合う関係にあり、Samsung・SK hynix・MicronはAI向けHBMの方が利益率が高いため、汎用DRAMの生産能力をHBMに振り替えている。 この結果、スマートフォンやノートPCに使われる汎用DRAM・NANDフラッシュの供給が細り、スポット価格が大幅に上昇しているとされる。半導体業界では「AIがメモリの椅子取りゲームに勝った」という表現すら使われ始めている。 直撃するのはローエンド端末 フラッグシップ機はメモリ・ストレージのコストが販売価格に占める比率が小さいため、多少の値上がりは吸収できる。しかし1〜2万円台の格安機や3万円台のミドルレンジ機は、部材費に占めるメモリ・ストレージの比率がもともと高く、わずかな原価上昇でも利益が消し飛ぶ。メーカー各社が低採算モデルを整理し、ラインアップをミドル〜ハイエンド寄りに再編する動きが今後加速すると見られている。 実務への影響 日本のIT現場にとっても他人事ではない。企業が調達するWindows PCも同じDRAM・NANDのサプライチェーンを共有しており、メモリ価格の高騰はノートPCやタブレットの調達コストに跳ね返ってくる。 PC更新計画の前倒しを検討する: 今後さらにメモリ価格が上がる可能性があるなら、大量調達を予定している組織は前倒し発注がコスト面で有利になる場合がある BYOD・現場スマホの選定基準を見直す: 現場作業用に安価な端末を大量配布している企業は、今後同等スペックの機種が値上がりまたは廃番になるリスクを織り込んでおく ストレージ増設・SSD交換の予算を早めに確保する: NAND価格の上昇はサーバー・ストレージ機器の増設コストにも波及する 筆者の見解 この話は「AIが便利になった」という側面の裏で、AI投資の重みが実体経済のハードウェアコストに直接波及し始めているという、地味だが見過ごせない構造変化を示している。クラウドの生成AIサービスは従量課金の話で完結しているように見えがちだが、実際にはGPUを支えるHBM、そのHBMを作るために振り向けられる半導体ウエハー、そしてそのしわ寄せを受ける私たちの手元のスマートフォンやPCまで、一本の線でつながっている。 MicrosoftもAzureのAIインフラ投資で大規模なデータセンター建設を続けており、この需要拡大の当事者の一社だ。応援する立場から言えば、AIの恩恵を語るなら、こうしたサプライチェーン全体への副作用にも正直に向き合ってほしいところだ。ユーザー企業側も「AIは便利」だけでなく、その裏で調達コストがじわじわ上がっていく現実を早めに織り込んで計画を立てる必要がある。 情報を追いかけるだけでは対策にならない。IT管理者は自社のデバイス調達サイクルとメモリ市況を照らし合わせ、今のうちに次の更新計画の予算感を見直しておくのが賢明だろう。 出典: この記事は Welcome to the end of budget smartphones — thanks to AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude Code、OpenAI Codex、Google Gemini CLIといった主要なAIコーディングエージェント、さらにClaude in ChromeやGoogle Antigravity、Nanobrowserといったブラウザ操作エージェントに、ソウル大学とイリノイ大学アーバナ・シャンペーン校の研究チームが共通の弱点を発見した。論文「Agent Data Injection Attacks are Realistic Threats to AI Agents」で報告された新しい攻撃手法「エージェント・データ・インジェクション(ADI)」は、エージェントに読み込ませる外部データそのものを武器に変える。 「指示への割り込み」ではなく「データへのなりすまし」 これまでAIエージェントのセキュリティ研究は、主に「間接プロンプトインジェクション(IPI)」を対象にしてきた。攻撃者が仕込んだ文章を、エージェントが「指示」だと誤認識してしまうタイプの攻撃だ。モデルの堅牢化、入力ガードレール、Dual-LLM構成など、多くの対策が「指示」と「データ」を分離することで防御してきた。 今回のADIは、その防御の隙間を突く。攻撃者が細工したデータを、エージェントが「指示」としてではなく「信頼できるはずのデータ」だと誤認させる。たとえばファイルの出所を示すメタデータ、Webページ上のUI要素を識別するID、ツール呼び出しの実行結果のフォーマットなどになりすまし、エージェントに意図しない操作を実行させる。指示と分離すること自体は正しく機能していても、そのデータの真正性を検証していないために突破されてしまう。 実証された被害:任意クリックからリモートコード実行まで 論文では、Claude in Chrome、Google Antigravity、Nanobrowserに対する「任意クリック攻撃」(意図しない要素を勝手にクリックさせる)、そしてClaude Code、Codex、Gemini CLIに対する「リモートコード実行」や「サプライチェーン攻撃」を実際に成立させたと報告している。特定ベンダー1社の実装ミスではなく、業界の主要なエージェント設計に共通して存在する構造的な欠陥だという点が重い。研究チームは、信頼データと非信頼データを分離するという基本原則を、現行のAIエージェントがまだ実装できていないと結論づけている。 実務への影響 日本国内でもClaude Code、Codex、Gemini CLIといった自律型コーディングエージェントの導入が急速に進んでいる。今回の研究が突きつけるのは、「エージェントが読み込む外部データ(Webページ、リポジトリのREADME、ツールの実行結果など)はすべて汚染されている可能性がある」という前提に立つ必要があるということだ。実務上のポイントは3つ。 エージェントに与えるツール・MCP接続・実行権限を必要最小限に絞る。過剰な権限は攻撃の踏み台になる 外部リポジトリやWebコンテンツを扱わせるタスクでは、コード実行やパッケージインストールを自動承認しない設定にする 各ベンダーからの本件に関するパッチ・緩和策のアナウンスを継続的に確認する 筆者の見解 今回の論文が重いのは、Claude Code、Codex、Gemini CLIという主要な陣営がほぼ同列に脆弱性を指摘されている点だ。特定ベンダーの実装が甘かったという話ではなく、「信頼データと非信頼データを分離する」という、伝統的なシステムセキュリティの世界ではSQLインジェクション対策などを通じて何十年も前に確立されてきた原則を、AIエージェントの世界がまだ実装できていないという構造的な指摘だと受け止めている。 筆者はかねてAIエージェントについて、人間の承認待ちを減らして自律的に動く設計こそが本質的な価値を生むという立場を取ってきた。だが自律性を上げるほど、今回のようにエージェントが騙されて実行してしまう操作の被害も大きくなる。ここで大事なのは「危ないから使うな」という禁止に走ることではない。ユーザーが安心して自律的に使い倒せるように、ベンダー側が信頼境界をきちんと設計し直すことだ。こうした研究が公開され、業界全体で対策が進むのは歓迎したい動きで、各社の次のアップデートで具体的にどう手当てされるかを注視していきたい。 出典: この記事は Agent Data Injection Attacks are Realistic Threats to AI Agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 突然アプリが壊れた続きをみる note.com で続きを読む →

中国のAI企業DeepSeek（深度求索）が、NvidiaとHuawei Technologiesへの依存度を下げるため、自社設計の推論（インファレンス）用AIチップを開発していることが、Reutersの報道で明らかになった。事情に詳しい関係者3人の話として、DeepSeekはこの1年ほど水面下でチップ設計・製造・メモリ各社と協議を重ね、経験豊富なチップ設計エンジニアの採用も進めているという。取り組みはまだ初期段階とされる。 学習より重視される「推論」の主導権 DeepSeekは2025年1月、低コストかつ高性能な「R1」モデルで一躍脚光を浴び、米国株の一部を急落させたことで知られる。当時同モデルはNvidiaのH800（中国市場向けに性能を制限したチップで、後に米国が禁輸）で学習されていた。その後は主にHuaweiの「Ascend」GPUに軸足を移し、2026年4月に発表した最新モデル「V4」はAscend向けに最適化されている。 今回焦点となっているのは学習用ではなく「推論」用チップだ。学習は話題性を生むが、実際にユーザーがモデルを使うたびに発生する推論コストこそが、AI企業にとって継続的な収益とコストのせめぎ合いの場になる。DeepSeekがここを自社制御下に置こうとするのは、収益化の主導権を握るための合理的な一手といえる。 OpenAI・Anthropicと同じ道、そしてAlibaba・Baiduも 自社推論チップの開発は、DeepSeekが初めてではない。OpenAIはBroadcomと共同設計した推論チップ「Jalapeño」を発表済みで、Anthropicも同様の取り組みを進めているとされる。狙いはNvidia依存の低減に加え、AppleがiPhoneやMacで自社チップを設計するように、ハードウェアからソフトウェアまでを垂直統合し技術スタック全体の主導権を握ることにある。中国国内でもAlibabaやBaiduが独自AIチップの開発を進めており、米国の輸出規制がHuaweiを中国市場の主要サプライヤーに押し上げた一方で、DeepSeekは特定ベンダーへの過度な依存を避けたい考えのようだ。 実務への影響 日本のエンジニアやIT管理者にとって、この動きは対岸の火事ではない。AI活用が学習フェーズから運用フェーズに移るほど、コストの主戦場は推論に移っていく。クラウドAIサービスを選定する際は、モデル精度だけでなく、裏側のチップ供給構造や価格改定リスクにも目を向けたい。特定ベンダー・特定チップへの過度な依存は、地政学リスクや輸出規制の影響を受けやすい。マルチベンダー・マルチクラウドで推論基盤を分散させておく、あるいは推論コストの実測値を継続的にモニタリングする仕組みを社内に持っておくことが、実務上の具体的な備えになる。 筆者の見解 学習コストばかりが話題になりがちだが、AIをビジネスとして回す上で本当に効いてくるのは推論コストだ。DeepSeekがそこに手を伸ばし始めたのは、AIを「作って終わり」ではなく「使い倒して勝つ」フェーズに入った証拠だろう。OpenAIやAnthropicが同じ方向に動いているのも、自律的にタスクをこなすAIエージェントを大量に走らせる時代には、推論の主導権を握った企業が有利になるという読みが働いているはずだ。 日本企業の多くはまだAIを「試す」段階にとどまり、推論コストを本気で最適化する発想自体が薄い。チップまで自作する体力は普通の企業にはないが、「推論コストは経営指標として継続的に見るものだ」という発想だけは今のうちに持っておくべきだ。海外勢がハードウェアレベルで主導権争いを始めているという事実は、AI活用が次のステージに入ったことの一つの証左として受け止めたい。 出典: この記事は Report: China’s DeepSeek follows OpenAI in developing its own custom inference chips の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国の数学者レヴェント・アルポージ（Levent Alpoge）氏は2026年7月20日、X（旧Twitter）で、Anthropicの生成AIモデル「Claude Fable」を使って、1939年の提起から87年間誰も解けなかった数学の超難問「ヤコビアン予想（Jacobian Conjecture）」に対する反例を発見したと投稿した。 「ヤコビアン予想」とは何か ヤコビアン予想は、ドイツの数学者オットー=ハインリッヒ・ケラーが1939年に提起した予想だ。n変数の複素多項式写像 C^n→C^n について、そのヤコビ行列式（各成分の偏微分から作る行列の行列式）がどの点でも0にならない定数であれば、その写像は多項式で書ける逆写像を持つ、つまり全単射であるはずだ、という主張である。 主張自体はシンプルだが、証明も反例もこれまで一切見つからず、著名な数学者が挑んでは跳ね返されてきたことから「クランク（トンデモ）の墓場」とすら呼ばれてきた難問だ。双子素数予想への貢献で知られる張益唐（Yitang Zhang）氏も博士論文でこの問題に取り組み、証明に欠陥が見つかって学位取得が難航したという逸話があり、今回のスレッドでもリプライで言及されている。 ワールドカップ決勝の合間に見つかった反例 アルポージ氏が投稿した反例は、3変数の多項式写像で、ヤコビ行列式がどの点でも-2という定数でありながら、(0, 0, -1/4)、(1, -3/2, 13/2)、(-1, 3/2, 13/2) という3つの異なる点をすべて同じ点 (-1/4, 0, 0) に写してしまう、つまり単射ではないというものだ。予想が正しければ「定数かつ非ゼロのヤコビ行列式を持つ多項式写像は全単射」のはずなので、この反例が正しければ予想そのものが崩れることになる。 氏はこの計算をClaude Fableが「ワールドカップ決勝戦の間に」担ったと明かしており、人間がサッカー観戦をしている間にAIが自律的に計算を進めていたという点が話題を呼んでいる。 現時点では「検証中」というのが実際のところ 投稿ではヤコビ行列式の計算や各点での写像の値をWolfram Alphaで裏付けており、追跡可能な形で示されてはいる。X上のAI「Grok」もこのスレッドに反応し「有効な反例だ」と回答しているが、これはAIによる即答であって、数学コミュニティによる正式な査読ではない。リプライでは、この反例が関連するディクスミア予想（Dixmier Conjecture）やポアソン予想（Poisson Conjecture）の反証にもつながるのではという指摘も出ており、影響範囲の精査はこれからだ。 実務への影響 日本のエンジニアやIT管理者の日常業務に直結する話ではないが、示唆はある。 「答えの正しさを機械的に検証しやすい」領域（数値計算、組み合わせ探索、証明の妥当性チェックなど）では、AIエージェントに自律的な反復探索を任せる余地が着実に広がっている。社内に眠っている検証可能な計算タスクを、AIエージェントに predicate として渡せないか棚卸ししてみる価値がある。 一方で、この件はAIの出力と専門家コミュニティによる検証の間にはまだ距離があることも示している。別のAI（Grok）の即答は査読の代わりにはならない。業務でAIの成果を使う際も、重要な判断ほど独立した検証プロセスを仕組みとして挟んでおくべきだ。 人間はゴール設定と検証手段の用意に徹し、実行そのものはAIエージェントに委ねるという役割分担が、数学の最前線でも実証されつつある点は、開発・検証プロセスの設計を考える上でのヒントになる。 筆者の見解 真偽はさておき、この一件で一番面白いのは「人間がワールドカップ決勝を見ている間にAIが勝手に計算を進めていた」という構図そのものだ。逐一確認や承認を求められるアシスタント型のAIではなく、目的だけ渡して離れても仕事を進めてくれる自律型のエージェントが、こうした専門的な計算領域でも実力を発揮し始めている。この方向性こそ今のAI活用で一番注目すべきところだと感じる。 Anthropicのモデルがこうした形で数学研究の現場に持ち込まれ、話題になっていること自体は素直に興味深い。ただし現時点ではあくまで未査読のX投稿であり、Wolfram Alphaでの部分検証やGrokの回答があるとはいえ、数学的に確定した結果ではない。今後、専門家コミュニティによる正式な検証を経て初めて「ヤコビアン予想は解決された」と言える段階に進む。AIが出した派手な結果に飛びつく前に、誰がどう裏取りしたのかを見極める姿勢は、数学に限らず業務でAIを使うときにも変わらず大事にしたい。 出典: この記事は Claude Fable produced a counterexample to the Jacobian Conjecture の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたのか AIモデルやデータセットの共有プラットフォームとして世界中の開発者に使われているHugging Faceが、サイバー攻撃を受けたことを公表した。同社の説明で注目すべきは、攻撃者が人間ではなく、偵察から侵入までの一連のプロセスをAIエージェントが自律的にやり切ったという点だ。Hugging Faceはこれを受けてシステムを保護し、法執行機関に通報。登録ユーザーに対してもパスワードやAPIトークンの見直しなど、必要な対応を呼びかけている。 どの経路が悪用され、どの範囲のデータが影響を受けたのかについて、現時点で詳細な技術情報は明らかになっていない。ただ「エージェント型AIが攻撃の一連の工程を自動実行した」という事実そのものが、セキュリティ業界にとって重い意味を持つ。 「エージェント型攻撃」が意味すること これまでのサイバー攻撃は、偵察・初期侵入・権限昇格・データ持ち出しといった各段階で、人間の攻撃者が判断を下しながら手を動かすのが一般的だった。ここにAIエージェントが介在するようになると、攻撃者は「攻撃計画を立てて実行させる」だけで済むようになる。攻撃のスピードとスケールが変わるのはもちろん、防御側も「攻撃してきているのは人間かAIエージェントか」を区別できない前提で対策を組む必要が出てくる。 Hugging Faceは大量のオープンソースAIモデルやデータセットが集まる、いわば「AI版のnpm・PyPI」のような立ち位置にある。ここが攻撃対象になったという事実は、一企業のインシデントにとどまらず、AIサプライチェーン全体のリスクとして捉えるべきだろう。 実務への影響 日本の開発現場でHugging Faceのモデルやトークンをパイプラインに組み込んでいる場合、まず点検すべきは以下の点だ。 APIトークンの棚卸しと再発行: CI/CDやMLOpsパイプラインに埋め込んだHugging Faceのアクセストークンは、漏洩の有無にかかわらずローテーションを習慣化する 常時権限を疑う: トークンやサービスアカウントに「使うときだけ」ではなく恒常的な強い権限を与えていないか確認する モデル取得元の検証: 自動化されたパイプラインが取得するモデル・データセットの出所とハッシュ値を検証する仕組みを入れる いずれも「気づいたときに見直す」ではなく、平時から仕組みとして回しておくべき項目だ。 筆者の見解 正直に言うと、セキュリティの細かい話は自分の得意分野ではない。ただ、AIエージェントが攻撃の一連の工程を自律実行したという今回の件は、以前から気になっていた「非人間ID（Non-Human Identities, NHI）」の管理の話と直結していると感じる。 AIエージェントに与えるAPIキーやサービスアカウントは、もはや裏方の設定ではなく、人間の特権アカウントと同じかそれ以上に重く扱うべき対象になった。常時アクセス権を漫然と持たせたNHIが乗っ取られれば、人間の攻撃者を介さずに攻撃が完結してしまう時代に入ったということだ。Just-In-Timeで必要なときだけ権限を発行し、使い終わったら失効させる。ネットワーク層・認証層・認可層で多重に防御する。この基本を、AIエージェントというNHIにも同じように適用できるかどうかが、これからのセキュリティ対応の分かれ目になる。 結局のところボトルネックは人間だ。NHIの管理を仕組み化できない組織は、AIによる自動化のスピードにも、AIを悪用した攻撃のスピードにも追いつけなくなる。今回のHugging Faceの一件は、そのことを静かに突きつけている。 出典: この記事は Hugging Face experienced cyberattack carried out end-to-end by agentic AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft AzureとOracleは、共同提供するマネージドサービス「Oracle Database@Azure」の対応リージョンを、従来の14拠点から33拠点へと拡大したと発表した。これはハイパースケーラー上で提供されるOracle Databaseサービスとしては最多のリージョン数となる。あわせて、データレイクハウス基盤「Oracle Autonomous AI Lakehouse」の一般提供(GA)開始、Microsoft FabricおよびPower BIとの統合強化など、AIとデータ活用を意識した新機能が複数追加された。 Oracle Database@Azureとは Oracle Database@Azureは、Oracle Exadataなどオラクル製のデータベース基盤を、Azureのデータセンター内に物理的に設置し、Azureのネイティブサービスとしてシームレスに利用できるようにしたサービスだ。ネットワーク遅延の少なさに加え、課金・契約窓口・サポートがAzure側に一本化されている点が特徴で、既存のOracle Databaseワークロードをクラウドに移行する際の定番の選択肢になりつつある。 主な新機能 今回の発表で特に注目すべきは以下の3点だ。 リージョン拡大(14→33): 日本を含むアジア太平洋地域でも選択肢が広がり、データ主権やレイテンシ要件を満たしやすくなった Oracle Autonomous AI LakehouseのGA: Oracle上のデータをオブジェクトストレージ上のレイクハウス形式で分析可能にし、AIモデルの学習・推論にそのまま活用できる基盤が正式版になった Fabric/Power BI統合強化: Oracle Database上のデータをMicrosoft Fabricに直接連携し、Power BIでそのまま可視化・分析できる導線が整備された 実務への影響 日本企業の基幹系システムには、いまだにOracle Databaseが数多く残っている。これらをAzureに移行したいが、Oracle DatabaseのライセンスやRAC構成はそのまま維持したい、という要望は根強く、Oracle Database@Azureはその現実的な落としどころになる。 特に今回のリージョン拡大は大きい。これまで対応リージョンが少なく「使いたくても物理的に選べない」という制約があった企業にとって、選択肢が広がったことは移行計画を具体化する後押しになる。またFabric/Power BI統合の強化により、基幹系のOracleデータをAzure側の分析基盤に持ち込みやすくなった点は、レポーティング業務の効率化に直結する。IT管理者は、既存のOracle Databaseワークロードを棚卸しし、対象リージョンに自社拠点が含まれるかを確認しておくとよい。 筆者の見解 Oracle Database@Azureは、Azureが「自前で全部作る」のではなく、強い他社製品をそのままAzure基盤に取り込んで顧客に選択肢を提供する、という戦略の代表例だと見ている。Azure基盤の信頼性はそのままに、その上で動かす技術やサービスを柔軟に選べるようにするというアプローチは、王道であり正しい判断だと思う。 Oracle Databaseの資産を持つ企業からすれば、無理にリプレースせずAzureの運用基盤・ガバナンスに乗せられるのは大きなメリットだ。派手さはないが、こうした「地味だが顧客の実利に直結する」拡張を着実に積み重ねているところに、Azureのプラットフォームとしての底力を感じる。AI関連の話題が先行しがちな昨今だからこそ、こうした基盤サービスの拡充にも引き続き注目していきたい。 出典: この記事は What’s new with Oracle Database@Azure の内容をもとに、筆者の見解を加えて独自に執筆したものです。

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 はじめに続きをみる note.com で続きを読む →

米国のITコンサルタント、Nik Suresh氏が、自身がコンサルティングで関わる大企業の内部で目撃した「AI狂騒（AI mania）」の実態を赤裸々に綴ったブログ記事が話題になっている。著名な開発者ブロガーのSimon Willison氏がこの記事をリンクブログで紹介し、Hacker Newsでも大きな議論を呼んだ。登場するのは、ChatGPTすら使ったことのない役員が数千億円規模の会社のAI戦略を丸ごと主導する話や、社内の「トークン消費量リーダーボード」に怯えてコードを無意味に書き換え続ける技術者の話だ。 ChatGPTを触ったことのない役員が「AI戦略」を書く Suresh氏が明かした最も強烈な事例は、年商20億ドル（約3000億円）超の企業で、ChatGPTはおろかどんなAIツールも一度も使ったことがないと自ら認めた役員が、その直後に会社全体の技術戦略──しかも中身は丸ごとAI中心──を発表していたというものだ。使ったことのない道具を前提に会社の未来を賭ける計画を作る。笑い話のようだが、これが複数の大企業で実際に起きているとSuresh氏は指摘する。 「トークンリーダーボード」のためにGoをZigへ書き換える技術者 もう一つの象徴的な逸話が、「トークン消費量リーダーボード」を導入しているある企業のエンジニアの告白だ。「クビにならないために、Goのリポジトリをまるごとコピーして、別の作業をしている間にAIにZigへの丸ごと書き換えを指示している」という。生産性の実態ではなく、AIにどれだけトークンを使わせたかという見せかけの数字が評価基準になった結果、技術的に何の意味もない書き換え作業が「実績」として生み出されている。 なぜ誰も「それは無理です」と言えないのか Suresh氏が特に興味深いと語るのが、AIベンダー側の役員へのインタビューだ。顧客企業の役員が「生産性が100倍になった」といった非現実的な数字を吹聴しているとき、ベンダー側の役員がその場で「それは非現実的だ」と正直に指摘すると、顧客役員の面子を潰す「攻撃」と受け取られ、契約解除につながりかねない。自社の本質的な事業に関係のない話で契約を切られれば、指摘した役員自身が解雇される可能性すらある。損得抜きに正直な評価を口にできない構造が、AI狂騒を加速させているというわけだ。 実務への影響 日本のIT現場にとっても他人事ではない話だ。生成AI活用を測る「AI活用度」という指標そのものは方向性として正しい。しかし測り方を間違えると、この記事のトークンリーダーボードのように目的と手段が入れ替わる。「AIをどれだけ使ったか」の代理指標としてトークン消費量や利用回数だけを追うと、社員は評価のために無意味な作業を作り出してしまう。IT管理者は、実際の業務改善や成果に紐づいた指標を設計し、数字だけがひとり歩きしないよう注意する必要がある。また、経営層がツールを実際に使わずに戦略だけを語る状態も危険信号だ。技術戦略を作る立場の人間ほど、自分の手でAIエージェントを日常的に使い、失敗も含めて肌感覚を持っておくべきだろう。 筆者の見解 このエピソード集を読んで真っ先に思ったのは、「AI活用度を測ろうとする発想自体は間違っていない」ということだ。企業が生成AIをどれだけ効果的に使いこなしているかを可視化する試みは、方向性としては筋がいい。問題は、その物差しが「トークン消費量」のような安直な数字にすり替わった瞬間に起きる。Zigへの書き換えの逸話は、まさに人間が変なKPIにぶら下がって数字をハックし始める典型例で、経営がAIを本気で導入したいなら、こういう副作用込みで指標設計をしなければならない。 一方で、「役員がAIを一度も使わずに戦略だけ語る」という話には、もっと根深い問題を感じる。今の時代、意思決定をする立場の人間が生成AIを積極的に使わないこと自体が、もう相当まずい状態だと思っている。使ったことがないから的外れな戦略しか作れないし、現場の技術者がその歪みのしわ寄せを受ける。かといって「使わなくていい」を強調しすぎるのも間違いで、必要なのは「どう使えば効果的か」を組織としてきちんと定義し、支援する仕組みだ。禁止でも放任でもなく、正直な評価と地に足のついた指標を伴った活用を経営から現場まで一貫して作れるかどうか。この記事に出てくる笑い話のような光景は、日本の会社でも十分に起こり得る話だと思っている。 出典: この記事は AI Mania Is Eviscerating Global Decision-Making の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、オンプレミス環境で完結するAI推論基盤「Foundry Local on Azure Local」の機能を強化し、複数ノードで構成するKubernetesクラスタ上での推論スケーリングと、高速推論ランタイム「vLLM」への対応を追加したと発表した。GPUリソースを自動的に最適化するチューニングプランナーや、複数レプリカ間でリクエストを振り分けるルーティング機能も新たに加わり、金融・医療・官公庁など機密データを外部に出せない業種向けの「ソブリンAI」基盤としての完成度を高めている。 Foundry LocalとAzure Localとは何か Azure Localは、旧Azure Stack HCIの後継にあたるオンプレミス向けハイパーコンバージド基盤で、Azure Arcを通じてクラウドと同じ管理体験をデータセンター内で実現する製品だ。Foundry Localは、その上でAzure AI Foundryと同等のモデルカタログ・推論APIをインターネット接続なしで動かせるようにしたコンポーネントで、小規模言語モデル（SLM）やオープンウェイトモデルをオンプレミスのGPUサーバー上で運用できる。 今回の機能強化のポイント マルチノードKubernetesクラスタでの推論スケーリング: 従来は1台のGPUサーバーの能力に縛られていた推論処理を、複数ノードに分散して負荷に応じて拡張できるようになった vLLMランタイム対応: PagedAttentionなどの技術で高スループットを実現するOSSの推論エンジンvLLMを、Foundry Local上で選択できるようになった GPU向け自動チューニングプランナー: 搭載GPUとモデルの組み合わせに応じて、バッチサイズやメモリ配分などのパラメータを自動的に最適化する マルチレプリカ向けリクエストルーティング: 複数のモデルレプリカにリクエストを適切に振り分け、可用性とスループットを両立させる いずれも、単体サーバーでの検証段階から、本番運用に耐えるスケールアウト構成への橋渡しとなる機能群だ。 なぜ「ソブリンAI」が必要なのか 生成AIの業務活用が進むほど、金融業界のガイドラインや医療情報の外部持ち出し制限、防衛・自治体の機密情報保護など、データを国内・自社ネットワーク境界の外に出せない要件との衝突が表面化している。Foundry Local on Azure Localは、推論処理そのものをオンプレミスで完結させることで、この種の規制要件と生成AI活用の両立を狙った基盤だ。 実務への影響 日本のIT管理者にとって重要なのは、この強化がAzure ArcやMicrosoft Entra IDによる一元管理を維持したまま、オンプレミスでのAI推論をスケールできる点だ。クラウドとオンプレミスで別々の管理体系を持つ必要がなく、ガバナンスの一貫性を保てる。 PoC段階では単一ノードで十分でも、本番投入後にユーザー数やモデルサイズが増えるケースは多い。マルチノード構成への移行はネットワーク設計やGPUキャパシティプランニングを後から作り直すコストが大きいため、要件定義の段階からスケールアウトを見込んだ設計を検討しておくことを勧める。また、vLLM対応により、Llama・Phi・Mistralといったオープンウェイトモデルをオンプレミスで効率よく動かす選択肢が広がる点も、コスト最適化を検討する材料になる。 筆者の見解 Azureというプラットフォームへの信頼は、この手の機能強化を見るたびに揺らがないと感じる。Foundry Local on Azure Localは、AIモデルそのものの優劣を競う土俵ではなく、「どのAIを、どこまで安全に、どこで動かすか」を統制する基盤としての価値を積み上げる動きだ。Entra IDやArcによる一元管理を保ったまま、オンプレミスでもクラウドと同じ運用体験を提供できる点は、地に足の着いた正攻法だと思う。 一方で、こうした細かい機能を逐一追いかける意味は正直薄れてきているとも感じる。マルチノード対応やvLLM対応といった個々の機能よりも、「オンプレミスでも安全にAIを回せる基盤がある」という大枠を押さえておき、あとは実際に手を動かして試す方が学びが早い。 この基盤の価値をさらに引き出せるかどうかは、今後どこまでモデル選択の自由度を広げられるかにかかっている。オープンウェイトモデルへの対応だけで終わらせるのはもったいない。プラットフォームとしての力があるのだから、そこにもう一段踏み込んでこそ、ソブリンAI要件を抱える企業から正面から選ばれる基盤になるはずだ。 出典: この記事は Build, deploy, and govern sovereign AI with Foundry Local on Azure Local の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIコーディングツールの普及以降、Q&AサイトStack Overflowへの質問投稿数がどれだけ落ち込んだかを示すグラフが公開され、Hacker Newsで407ポイント・495件のコメントを集める大きな話題になった。作成に使われたのはStack Exchange公式の「Stack Exchange Data Explorer（SEDE）」。誰でもStack Overflowの公開データセットに対して自分でSQLクエリを書き、結果をグラフとして可視化できる無料ツールだ。 「集合知の広場」で何が起きているのか 公開されたクエリは、月別・年別の新規質問数の推移を折れ線グラフにしたものだ。Stack Overflowの質問数は2014年前後をピークにすでに緩やかな減少局面に入っていたが、2022年11月のChatGPT登場、そして2023年以降のGitHub Copilotなどコーディング支援ツールの普及を境に、下落カーブが明らかに急になっている——これが多くの開発者の共感と危機感を呼んだ理由だ。SEDEは誰でも同じ公開データに対して検証クエリを書けるため、「本当にそうなのか」を各自が手元で再現できる点も拡散を後押しした。 なぜ質問数が減ったのか 理由は単純だ。以前は「検索してStack Overflowの回答を探す」のが定番の手順だったが、今はIDEやターミナルに常駐する生成AIに直接聞けば、その場でコードベースの文脈を踏まえた回答が返ってくる。検索し、複数の回答を読み比べ、自分のコードに合わせて書き換える——という一連の作業そのものが不要になりつつある。Stack Overflow側もこの傾向を認めており、コミュニティ機能に生成AIを統合する「OverflowAI」を2023年に発表したほか、2024年にはGoogleやOpenAIとデータライセンス契約を結び、自社の質問・回答データをAIモデルの学習・参照用に提供する道を選んだ。皮肉なことに、Stack Overflowの膨大な蓄積データこそが、今その存在意義を脅かす生成AIを育てた「教材」でもある。 実務への影響 この変化は日本のエンジニアやIT管理者にとっても他人事ではない。 新人教育のやり方を見直す: 以前は「似た質問と回答」を読み比べる過程自体が学びになっていた。AIが一発で正解に近いコードを出す今、若手には「なぜその実装を選んだのか」を説明させる場を意識的に別途用意する必要がある。 社内ナレッジをAIが参照できる形に整える: 公開Q&Aの新規投稿が先細るなら、社内Wikiや過去の障害対応、設計判断の記録をAIエージェントが読み込める形で残しておくことの価値がこれまで以上に上がる。 「情報の鮮度」への依存を見直す: 公開コミュニティの投稿が減れば、AIの学習データも徐々に古くなっていく。特定バージョンの挙動や最新API仕様は、公式ドキュメントの確認とAIエージェントに実際にコードを書かせて検証する運用を組み合わせるのが現実的だ。 筆者の見解 このグラフを見て「Stack Overflowが可哀想」で終わらせるのは早計だと思う。開発者が検索して回答を探す手間そのものが要らなくなったのは、目的さえ伝えれば自律的にタスクをこなすAIエージェントへとパラダイムが移行している証拠であり、人間の認知負荷を減らすというAIエージェント本来の価値がそのまま表れた結果だ。「質問して、待って、回答を評価する」という工程が減ったこと自体は歓迎していい変化だと考えている。 一方で気になるのはこの先だ。公開コミュニティへの新規投稿が細っていけば、次世代のAIモデルが参照できる「生きた知識」も先細っていく。Stack Overflow社がAI企業とデータ提供契約を結んだのは、皮肉ではあるが理にかなった生き残り策だろう。ただしこれは一企業の問題にとどまらず、エンジニアコミュニティ全体が知見を公開・共有する動機をどう保つかという、もう一段大きな課題でもある。 現場のエンジニアに伝えたいのは、こうした構造変化を追いかけて一喜一憂するより、今使えるAIエージェントを実際に手を動かして使い倒し、そこで得た経験を自分の武器にする方が確実だということだ。Stack Overflowの衰退を嘆く時間があるなら、その分をAIとの実践に充てた方がいい。開発の現場は、それくらい後戻りしないところまで来ている。 出典: この記事は What AI did to stackoverflow in a graph の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAの研究チームが、自己回帰型（オートリグレッシブ）と拡散型（ディフュージョン）という2つの生成方式を1つのモデルの中で切り替えられる新手法「Nemotron-Labs-Diffusion」を発表した。LLM推論を高速化する「投機的デコーディング」において、これまで必須とされてきた別建ての小型「ドラフトモデル」を自分自身で代替する仕組みで、1ステップあたり平均6.82トークンを受理できるという。既存手法Eagle3の2.75トークンを大きく上回る数値で、3B・8B・14Bの3サイズが商用利用可能なライセンスでHugging Faceに無料公開されている。 投機的デコーディングとドラフトモデルの限界 LLMの生成は本来、1トークンずつ計算するため遅い。これを高速化する定番手法が「投機的デコーディング」だ。軽量な「ドラフトモデル」に先回りで複数トークンを予測させ、本体（ターゲットモデル）がまとめて検証・受理することで、GPUの1回の呼び出しあたりの進み幅を稼ぐ。ただしドラフトモデルは別途訓練・保守するコストがかかり、ターゲットモデルとの「相性」が悪いと予測が外れて恩恵が薄れるという欠点があった。 自分自身でドラフトを作るという発想 Nemotron-Labs-Diffusionは、この構図そのものを変える。1つのモデルに自己回帰的な生成モードと拡散型の生成モードを持たせ、拡散モード側が自分自身の「ドラフト」を並行して生成する仕組みだ。別モデルを訓練・保守する必要がなくなり、モデルとドラフトの整合性問題も原理的に解消される。結果として1ステップあたりの受理トークン数がEagle3比で2倍以上に伸びた、というのが今回の要点である。 実務への影響 推論コストはトークン単価だけでなく「1回のGPU呼び出しでどれだけ進むか」にも大きく左右される。ドラフトモデルの管理・チューニングが不要になれば、社内でLLM推論基盤を運用するIT管理者にとっては構成要素が1つ減り、監視対象・障害点も減ることになる。3B/8B/14Bという扱いやすいサイズが商用利用可能なライセンスで公開されている点も実務的で、オンプレミスやエッジでの推論高速化を検証したいチームは、まず8Bあたりから自社ワークロードでベンチマークを取ってみる価値がある。 筆者の見解 AIの話題は派手なチャットモデルの発表に注目が集まりがちだが、推論を1ステップでも多く進める地味な高速化こそ、現場でAIをガンガン使い倒すための土台になる。ドラフトモデルという「もう1つ余分なパーツ」を用意・保守する手間そのものを消してしまう発想は、禁止や制約を積み増すのではなく、使う側にとって一番シンプルで便利な形に仕組みを作り直すという、筆者が普段大事にしている考え方と重なる。しかも3B/8B/14Bというサイズ感で、商用利用可能なライセンスとしてすぐ試せる形で公開している点がNVIDIAらしく手堅い。日本のIT現場はモデルの「賢さ」の議論に偏りがちだが、こうした推論効率の進化にも同じくらい目を向けて、実際に自分の環境で動かして確かめる経験を積んでいくべきだろう。 出典: この記事は NVIDIA’s New LLM Decodes 6x More Tokens Without an Auxiliary Draft Model の内容をもとに、筆者の見解を加えて独自に執筆したものです。

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 はじめに続きをみる note.com で続きを読む →

Microsoftは2026年7月のWindowsセキュリティ更新プログラムで、Active DirectoryドメインコントローラーがKerberos認証において脆弱な暗号方式RC4を許容する「Auditモード」を完全に廃止した。これにより、情報漏えいの脆弱性CVE-2026-20833への対応は最終段階である「強制適用フェーズ」に入り、サービスチケットの発行はAESベースの暗号化が事実上必須となる。 Auditモードとロールバック設定の消滅 Kerberos認証では、ドメインコントローラー上のKDC(Key Distribution Center)がサービスチケットを発行する際、伝統的にRC4-HMACとAES(128/256)の両方の暗号方式に対応してきた。しかしRC4はパスワードハッシュから直接鍵を導出する古い方式で、オフラインでの解析(いわゆるKerberoasting)に対する耐性が低い。 Microsoftはこの弱点を段階的に締め出すため、これまで「Auditモードでまず影響を可視化し、問題があればレジストリキー(RC4DefaultDisablementPhase)でロールバックできる」という猶予期間を設けてきた。今回の7月更新ではこのAuditモードとロールバック設定そのものが削除され、Enforcementモードのみが残る。RC4をどうしても使わざるを得ない場合は明示的な設定変更で維持できるが、その構成はCVE-2026-20833に対して脆弱なままになる。 影響を受けやすい環境 影響が出やすいのは、レガシーな業務アプリケーション、Windows以外のKerberos実装(Linux/Unix系サーバーやネットワーク機器、複合機など)で、RC4を明示的に指定しているケースだ。これまでAuditモードで警告が出ていても放置していた環境は、7月更新の適用と同時にサービスチケット要求が失敗し、認証エラーとして表面化する。 実務への影響 日本企業の多くは長年運用されてきたActive Directory環境に、更新が止まった古いアプライアンスや自社開発の基幹システムを抱えている。今回のように「猶予期間そのものがなくなる」変更は、こうした資産ほど直撃しやすい。 対応の勘所は3つ。まず、セキュリティイベントログのイベントID 4769(Kerberosサービスチケット要求)を確認し、Ticket Encryption Typeフィールドが0x17(RC4-HMAC)になっているアカウントを洗い出すこと。次に、それらのサービスアカウントやアプリケーションがAESに対応できるか個別に検証すること。最後に、本番環境へのパッチ適用前に、検証環境で非Windows実装との相互運用性を必ず確認することだ。ロールバックの逃げ道が消えた以上、事前検証の重要性は格段に上がっている。 筆者の見解 RC4の締め出しという方向性自体は、Windowsのセキュリティ強化施策の中でも一貫して正しい判断だと思う。Smart App Controlやカーネルドライバーの締め出しと同じで、地味だが効く改善だ。サービスアカウントという「人間ではないID(Non-Human Identity)」が、パスワード管理も棚卸しもされないまま何年も同じ暗号設定で動き続けているケースは、ゼロトラストの観点から見ても最大級のリスクだ。「今動いているから触らない」という発想が一番危ない、というのはSID重複問題などでも繰り返し学んできたはずの教訓のはずだ。 ただ、応援する立場から一つ苦言を呈するなら、Auditモードという猶予期間が長く続いたことが、逆に「そのうちまた延期されるだろう」という油断を組織側に生んでしまった面は否めない。せっかく何年もかけて移行期間を用意したのだから、棚卸しが済んでいないアカウントを事前に可視化し、管理者に直接アラートを送るような支援ツールをもっと手厚く用意してほしかった。正面から勝負できるだけの技術力と影響力を持っているのだから、移行の「最後の一押し」こそ丁寧にやってほしいところだ。 出典: この記事は Enforcement phase for Kerberos RC4 protections begins with the July 2026 Windows security update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Valveのゲーム機「Steam Machine」向けに、GPU・Bluetooth・無線LAN・SDカードリーダーに対応した公式Windows 11ドライバーが公開された。同社はこれによりGame Passや、SteamOS/Linux環境では動作しない一部のアンチチート対応タイトルが遊べるようになるとしつつも、Windows 11の導入そのものについては「自己責任」であり公式サポート対象外だと明言している。 SteamOSとの共存はまだ実現していない Steam MachineはValve独自のLinuxベースOS「SteamOS」を前提に設計された専用機だ。今回公開されたのはあくまで周辺デバイスをWindows 11上で動かすためのドライバー群であり、SteamOSとのデュアルブート（1台の端末に両OSを共存させ、起動時に選択する運用）にはまだ対応していない。 Windows 11を導入したいユーザーは、現在インストール済みのSteamOSを完全に削除した上で、まっさらな状態からWindows 11をクリーンインストールする必要がある。つまり「試しに入れてみて、ダメならSteamOSに戻す」という気軽な運用はできず、後戻りのコストが高い作業になる。 なぜWindows 11対応が必要になるのか SteamOSはLinuxカーネル上で動作するため、Windows専用に設計されたアンチチート機構を持つ一部のオンライン対戦タイトルは、そのままでは動作しない。またMicrosoftのサブスクリプション型サービスGame Passも、SteamOS単体では利用できないタイトルがある。Windows 11ドライバーの提供は、こうした「SteamOSでは遊べないゲーム」を遊びたいユーザーの受け皿として用意されたものだ。 実務への影響 日本のIT現場でも、Linuxベースの専用端末にWindowsを載せ替えるニーズは根強い。Steam Deckでも同様にWindows導入コミュニティが存在してきた経緯がある。検証機やデモ機としてSteam Machineの調達を検討する場合は、初期状態でSteamOSとWindows 11のどちらを標準運用にするか、事前に決めておいた方がいい。「公式ドライバーが出ている」という事実と「メーカーが動作保証している」ことはイコールではない、という点は、コンシューマー向けデバイス全般でIT管理者が意識すべき基本だ。 筆者の見解 正直、Valveの今回の対応は好感が持てる。ユーザーが求める機能（Windows 11対応）は用意しつつ、「サポート対象外」であることをはっきり明言する姿勢は誠実だ。禁止するのではなく、選択肢を用意した上でリスクを正直に伝える——これは筆者が普段から大事にしている「禁止ではなく安全に使える仕組みを作る」という考え方にも通じる。 Windows陣営としては、こうしたサードパーティ製ゲーム機にWindows 11の公式サポートが広がっていくこと自体は歓迎したい流れだ。ただしデュアルブート未対応で「Windows 11を入れるにはSteamOSを消せ」という設計は、ユーザーの選択の自由と気軽な試行錯誤を犠牲にしている。Steam MachineはあくまでSteamOSでの体験を前提に設計された端末であり、そこにWindows 11を載せるのは“想定外の改造”に近い。「作り手の意図を理解し、意図された使い方をする」のが基本だとすれば、Windows 11導入を検討するユーザーは、この非対称なリスクを理解した上で踏み込むべきだろう。デュアルブート対応が実現すれば、この判断はもっと気軽にできるようになるはずで、その日を楽しみにしている。 出典: この記事は Valve warns about installing Windows 11 on Steam Machine despite new official drivers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft(マイクロソフト)は2026年7月8日、月例セキュリティ更新「Patch Tuesday」で過去最多となる569件のCVE(共通脆弱性識別子)を公開した。この中でも仮想化基盤の運用担当者が特に注意すべきなのが、Hyper-VのVMSwitchコンポーネントに存在するUse-After-Free(解放後使用)型の脆弱性「CVE-2026-57092」だ。 VMSwitchのUse-After-Freeが招く権限昇格リスク VMSwitchはHyper-V環境で仮想マシン(VM)間、およびVMとホスト間のネットワーク通信を仲介する中核コンポーネントだ。Use-After-Freeは、解放済みのメモリ領域への参照が残ったまま使い続けてしまうバグで、攻撃者がそのタイミングを制御できると、解放された領域に任意のデータを送り込んで実行フローを乗っ取ることができる。 CVE-2026-57092の場合、ゲストOS内で低い権限しか持たない攻撃者が、このバグを突いてホスト側で権限を昇格させられる可能性がある。マルチテナントで複数の顧客のVMを同じHyper-Vホスト上に同居させているクラウド事業者やホスティング事業者にとっては、「VMの中は隔離されているはず」という前提そのものが崩れる、影響度の大きい脆弱性だ。 570件近い脆弱性の陰で見過ごされやすい 今回のPatch Tuesdayは569件中56件がCritical(緊急)、510件がImportant(重要)と、6月の198件を大きく上回る過去最大規模になった。Microsoftは事前に、脆弱性の発見を高速化する「MDASH(multi-model agentic scanning harness)」という複数AIモデルによるエージェント型スキャン基盤の運用を開始したと発表しており、「今後のセキュリティリリースでは更新件数がさらに増える」と予告していた。今回の記録的な件数は、その予告通りの結果と言える。 これだけの件数が一度に公開されると、個々の脆弱性の技術的な深刻度が埋もれてしまいがちだ。CVE-2026-57092のようにハイパーバイザーの権限境界に関わる脆弱性は、件数の多さに紛れて見落とされないよう、優先度を上げて確認する必要がある。 実務への影響 Hyper-Vは単体のWindows Serverだけでなく、Azure Stack HCIやAzure Local、S2D(Storage Spaces Direct)クラスタなど、日本企業のオンプレミス仮想化基盤でも広く使われている。VM内からホストへの権限昇格が可能になれば、同一ホスト上の他社・他部門のVMへの横展開や、ホスト管理者権限の窃取につながりかねない。 実務担当者は以下を優先して対応したい。 Hyper-Vホストの棚卸しと、VMSwitch関連パッチの適用状況の即時確認 マルチテナント環境(ホスティング事業者・社内共用基盤)では優先度を最高に設定 パッチ適用前にステージング環境での動作確認を行いつつも、権限昇格系の重大CVEは「様子見」の対象から外し、迅速に適用する Hyper-Vホストへのアクセス権をJust-In-Timeで付与し、常時付与された管理者権限を持つアカウントを洗い出す 筆者の見解 Windows個別の機能追加を逐一追う優先度は下がっている一方、こうしたハイパーバイザーレベルの脆弱性は話が別だ。仮想化基盤はネットワーク層・認証層・認可層という多層防御の一番土台にあたる部分であり、ここが崩れると上に積んだゼロトラストの仕組みも意味をなさなくなる。VM間分離を過信せず、ホストへのアクセス権をJust-In-Timeで最小化しておくことが、こうした脆弱性が出た際の実害を左右する。 569件という数字自体は驚くが、MicrosoftがAIエージェントによるスキャン基盤(MDASH)で脆弱性発見を加速させたと公表している点は素直に評価したい。指摘される脆弱性が増えるのは短期的には運用負荷の増加に見えるが、見つからずに放置されるより遥かにましだ。あとは、これだけの件数を運用現場が実際に検証・適用しきれるかという別の課題が残る。件数を増やす仕組みを作ったなら、優先度付けや影響範囲の可視化までセットで提供してほしい。そこまでやり切ってこそ、AIを使った脆弱性発見の取り組みが本当に現場の役に立つ。 出典: この記事は Use-After-Free vulnerability CVE-2026-57092 in Hyper-V’s VMSwitch (Microsoft’s July 2026 Patch Tuesday) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Outlook Classic（旧来のデスクトップ版Outlook）を含む全バージョンのOutlookに、Copilotを使った「メール下書き作成」機能を強制的に有効化すると発表した。管理ポータルの告知によれば、対象はOutlook Classic、New Outlook、Web版、モバイル版のすべてで、2026年末までにOutlook Classicへの展開が完了する見込みだ。機能を使いたくないユーザーは、自らオプトアウトするか、有効化後に手動で無効にする必要がある。 Outlook Classicにも年内展開 New Outlookでは既に展開が始まっているか、数週間以内に届く見込み。一方Outlook Classicは、機能追加がほぼ止まりバグ修正中心になっていたにもかかわらず、Copilot搭載のコンポーズボックスが年末までに既定でオンになる。管理者側の作業は不要で、ユーザーは新規メール作成や下書き編集の際、コンポーズボックス内からCopilotを呼び出し、文章の書き直しや拡張ができるようになる。 なお、この新しいCopilot搭載コンポーズ機能はMicrosoft 365 Copilotライセンスを必要とし、通常のMicrosoft 365サブスクリプションより高額だ。そしてMicrosoftの新しい料金ページは、Microsoft 365 Copilotライセンスを新標準として前面に押し出しており、Copilotなしの従来サブスクリプションを見つけにくくしている。既にMicrosoft 365 Copilotへアップグレード済みの組織では、この機能は自動的にオンになる。 なお政府機関向け環境(GCC High・DoD)では、New Outlookが9月からロールアウトされるが、Outlook Classicの強制置き換えは行わず、既定オフ・オプトインのまま管理者がポリシーとレジストリキーで制御できる状態が維持される。同時にMicrosoftは、添付ファイルと紛らわしいと不評だった「Meeting Insights」機能を廃止し、Copilotによる要約に置き換える方針も明らかにしている。 実務への影響 日本企業の多くは、COMアドインやVBAマクロとの互換性、あるいは単に慣れの問題からOutlook Classicを使い続けている。今回の変更は「機能追加」ではなく「既定オン」という形で来るため、IT管理者は年末までにグループポリシーまたはCloud Policyサービスで、Copilotコンポーズ機能の可否をあらかじめ決めておく必要がある。特にMicrosoft 365 Copilotライセンスを持たない組織では機能自体が表示されないはずだが、ライセンス保有ユーザーが混在する環境では、意図せず一部の社員だけに機能が現れる状況も想定される。情報漏洩や誤送信のリスクを避けるためにも、展開前の周知と、必要なら無効化の手順書を準備しておきたい。またNew Outlookへの移行計画がある組織は、この機会にCOMアドインからWebアドインへの移行スケジュールを見直す好機でもある。 筆者の見解 Copilotの企業向け展開はここ数年、機能の中身よりも「どう既定値を動かすか」で語られることが多くなっている。今回も、Outlook Classicの新機能追加をほぼ止めておきながら、Copilotだけは強制的に既定オンにするという判断には違和感がある。しかも料金ページでCopilotライセンスをさりげなく標準扱いにする見せ方は、応援する立場から見ても正直あまり褒められたやり方ではない。ユーザーが自分の意思で選べる余地をきちんと残してこそ、Copilotは「使われる機能」になっていくはずだ。 メールの下書き支援そのものは使いどころが分かりやすく、素直に実用性を評価しやすい機能だと思う。だからこそ、既定オンで押し付けるのではなく、管理者にもエンドユーザーにも透明性のある形で選ばせてほしい。正面から評価されるだけの実力を伸ばせる領域のはずなので、こうした細かい見せ方でユーザーの不信を買うのはもったいない。 出典: この記事は Microsoft to force enable Copilot in Outlook Classic, even though it wants you on New Outlook の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude Code、最高なんだけど「記憶」の扱いが難しい続きをみる note.com で続きを読む →