Tech News JP

環境活動家のエリン・ブロコビッチが、米国内のデータセンター建設をめぐる情報開示の不透明性を問題視し、全国マップの公開とコミュニティへの影響調査を開始した。生成AIブームで急増するデータセンター建設の「裏側」に、組織的な情報遮断のパターンが浮かび上がっている。 エリン・ブロコビッチとデータセンターマップ エリン・ブロコビッチといえば、電力会社PG&E（パシフィック・ガス・アンド・エレクトリック）による地下水汚染を告発し、2000年にジュリア・ロバーツ主演で映画化された実在の環境活動家だ。大企業と地域住民の情報格差を是正することを長年のテーマとしてきた彼女が、次のターゲットとしてデータセンター業界に照準を当てた。 彼女のチームが公開したウェブサイトには、米国全土のデータセンターを示すインタラクティブマップが掲載されている。このマップは「現在進行形の作業」と位置づけられており、周辺住民からの報告をもとに随時更新される仕組みだ。2026年4月に報告呼びかけを開始してから最初の1カ月だけで、約4000件もの投稿が集まったという。 住民が訴える最大の問題は「透明性」 寄せられた声を分析すると、興味深い事実が浮かんでくる。騒音・水使用量・電気代の高騰といった具体的な被害よりも、「透明性（Transparency）」 という一語が圧倒的に多く報告されたのだ。 ブロコビッチはSubstackへの投稿でこう記している。「許可証がすでに取得された後に発表されるプロジェクト、電話に出ない開発業者、近隣住民が計画を知らされる前にNDAにサインした地方官僚——マップが記録しているのはこのパターンだ」 この発言は重要なニュアンスを含んでいる。彼女はデータセンターやAIそのものを否定しているわけではない。問題視しているのは意思決定のプロセスの閉鎖性だ。 データセンター建設ラッシュの実態 生成AIの普及に伴い、大手テクノロジー企業は世界各地で大規模なデータセンター建設を急ピッチで進めている。米国ではバージニア州、テキサス州、アリゾナ州などが主要な集積地となっており、電力消費量・水使用量・地価上昇などの面で地域社会に多大な影響を与えている。 データセンター1棟あたりの電力消費量は数十MW〜数百MWに及ぶケースもあり、地域の電力グリッドへの負荷は無視できない。また冷却のための水使用量も膨大で、乾燥地帯での建設は水資源問題と直結する。 これらの影響が「許可取得後に初めて住民に伝えられる」構造が各地で横行しているというのが、今回のマップが示す実態だ。 日本のIT現場への影響 「これは米国の話」と片づけるのは早計だ。日本でも生成AIインフラへの投資は急加速しており、大手クラウドベンダーや国内IT企業が国内データセンター建設・拡張を競っている。日本においても以下の点を意識しておく必要がある。 エンジニア・IT管理者が知っておくべきこと： 調達・選定時のサステナビリティ評価: クラウドサービスを選定する際、PUE（電力使用効率）やWUE（水使用効率）などの環境指標を評価軸に加えることが、国際標準では当たり前になりつつある ESGレポーティングへの組み込み: 自社のカーボンフットプリント報告にデータセンター起因の間接排出（Scope 3）を含める企業が増えており、利用クラウドの透明性が問われる場面が増える 地域情報開示への期待値の変化: 住民や自治体が「どこにどのようなデータセンターが建設されるか」を事前に知る権利を主張する動きは、今後日本でも広がる可能性がある 筆者の見解 AIインフラをめぐるサステナビリティの議論は、これまで主に電力・カーボンの観点から語られることが多かった。しかしブロコビッチのアプローチが鋭いのは、「誰が意思決定をしていて、誰が情報を持っていないか」というガバナンスの問題として再定義した点だ。 技術的に最適解を求め続けることと、その恩恵が地域社会にどう分配されるかを考えることは、本来切り離せない。AIモデルの学習に使われる膨大な電力・水は、どこかの地域の資源として現実に消費されている。 日本のエンジニアやIT管理者にとって実践的な問いは、「自分たちが使っているクラウドリソースの環境負荷を把握しているか」という一点に尽きる。コスト最適化の文脈では当然チェックするものを、サステナビリティの文脈でもチェックするだけでいい。ツールもAPIも整備されてきた。情報開示の透明性を求める声が大きくなる前に、自発的に把握・開示する側に立てるかどうかが、今後の企業評価にも関わってくるはずだ。 ブロコビッチのマップがどれだけ広がるかはまだわからないが、4000件という初月の投稿数は、潜在的な問題意識が相当に蓄積されていたことを示している。AI産業の持続的成長のためにも、インフラの透明性確保は避けられないテーマになっていくだろう。 出典: この記事は Erin Brockovich takes aim at data center secrecy の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11の検索機能に長年のユーザー不満を解消する2つの改善を順次展開している。2文字入力でのファイル検出と、複合名ファイルを部分一致で発見できるサブストリング検索の導入だ。 何が変わるのか 2文字でファイルを発見——KB5089573 2026年5月のオプション更新プログラム KB5089573 で展開中の改善では、Windows Searchが「2文字入力でファイルを検出・優先表示できる」ようになった。 これまで「XP」と打っても壁紙ファイルはヒットせず「XPS Viewer」が出るだけ、という体験をしていたユーザーには覚えのある現象だろう。更新適用後は、「XP」と打つだけで関連するローカルファイルが即座に浮かび上がる。 ただし、Microsoftの段階的機能展開（Controlled Feature Rollout）により、KB5089573を適用済みでも全端末に即時反映されるわけではない。しばらく様子を見る必要がある。 複合ファイル名をどこからでも検索——サブストリング検索 もう一方の改善「Search by Substring」は、現在Windows 11 Insider Preview（Build 26300.8553 / Build 26220.8544）で展開中だ。 例として公式が挙げているのが StartMenuComparisonMay のようなファイル名だ。従来は先頭から一致する文字列を入力しなければヒットしなかった。新機能では「May」「Menu」「Comparison」のいずれを打っても正しいファイルが表示される。 Microsoftの説明を引用すると、 「MeetingNotesApril、ProjectStatusReportのような複合名のファイルが、‘april’や’status’と入力するだけで簡単に見つかるようになります」 これは単なる利便性向上ではない。実務では 2024Q3_Draft_v2_final_FINAL.xlsx のような名前が普通に存在する。それを「最初の数文字を思い出さなければ見つからない」検索に合わせてファイル名を付け直す作業は、本末転倒だった。 ローカルファイル優先への方針転換 一連の改善と並行して、MicrosoftはWindows 11の検索結果からBingのウェブ結果をローカルファイルより優先する動作も廃止する方向を示している。この3点セット——2文字検索・サブストリング・ローカル優先——が揃うと、Windows Searchの使用感はかなり変わる。 背景にあるのは2026年3月20日に公開されたMicrosoftのブログ「Our commitment to Windows quality」だ。検索を「アプリ・ファイル・設定を明確に表示して正しい結果に素早くたどり着けるようにする」と明言しており、今回の展開はその約束の具体化にあたる。 実務での活用ポイント すぐ使えるヒント: KB5089573を確認する: 設定 → Windows Update → 詳細オプション → オプションの更新から適用可能か確認する。段階的展開なので表示されない場合もある ファイル名の命名規則を緩められる: サブストリング検索が安定すれば、先頭一致を意識した不自然な命名ルールを見直せる。20260601_MeetingNotes_Product.docx のような自然な複合名が検索で問題なく引っかかるようになる Insider環境での先行確認: Experimental / Betaチャンネルに登録している環境があれば、サブストリング検索は今すぐ評価可能だ IT管理者へ: 段階的展開のため、組織内で体験の差が出る期間がある。ヘルプデスクへの問い合わせ対応として「Search改善は順次展開中」と周知しておくと無用な混乱を避けられる。 筆者の見解 Windowsのデスクトップ検索が「使えない」というのは、もはやIT業界の共通認識と言っていい。ファイルを探すためにわざわざExplorerを開いてフォルダを掘っていく習慣が根付いてしまったのは、検索への不信任票の積み重ねだ。 サブストリング検索と2文字検出は、技術的には決して難しい実装ではない。macOSのSpotlightやLinuxのAnythingが何年も前からやってきたことだ。それがようやく来た、というのが正直なところで、「革新」と呼ぶのは大げさかもしれない。しかし、実際に使えるレベルになることの価値は小さくない。 Microsoftには「Our commitment to Windows quality」で示した約束を着実に実行し続けてほしい。地道な改善こそが、日常の生産性を底上げする。Windowsは今でも何億人ものビジネスパーソンが使う土台だ。その土台が静かに、確実に良くなることは、派手な新機能よりも長期的なインパクトが大きい。口先だけでなく、このペースで実装を続けられるかが問われる。 ...

MicrosoftはWindows 11のMay 2026 Patch Tuesday更新プログラム（KB5089549）が一部のPCで35〜36%のタイミングで失敗する問題の原因を特定し、修正を含む任意更新プログラムKB5089573（Build 26200.852）を公開した。 何が起きていたのか 2026年5月12日にリリースされたKB5089549は、Windows 11 25H2・24H2・それ以前のバージョンを対象としたPatach Tuesdayアップデートだ。「Xboxモード for デスクトップ」やexplorer.exe関連の修正など実用的な変更を含んでいたが、一部ユーザーからインストール失敗の報告が相次いだ。 症状は以下のとおりだ。 ダウンロード自体は正常に完了する 再起動後の適用フェーズで35〜36%前後でフリーズ スピナー画面が表示されたのち、Windowsが変更のロールバックを開始 「計画どおりに進みませんでした。変更を元に戻しています」というメッセージが表示される Windows Updateの履歴にエラーコード0x800f0922が記録される C:\Windows\Logs\CBS\CBS.logをイベントビューアーで確認すると、EFIシステムパーティションの空き容量不足が記録されている EFIシステムパーティション（ESP）とは何か EFIシステムパーティション（ESP: Extensible Firmware Interface System Partition）は、WindowsがPCを起動するために必要なブートファイルを格納する特殊なパーティションだ。UEFIファームウェアはFAT32フォーマットされたこのパーティションに依存してWindows Boot Managerを読み込む。ESPが存在しなければPCはそもそも起動しないという、ファイルシステム上で最も重要なパーティションのひとつである。 ESPはWindowsセットアップ時に自動生成され、ファイルエクスプローラーからは非表示になっている（意図的に隠されている）。通常は256MB前後が確保されており、Windows本体が継続的に書き込みを行う領域ではないため、通常は60〜80%の空き容量が保たれる。 しかしOEMによるBIOSアップデートなどを繰り返すと、ESPに不要なファイルが蓄積されて空き容量が圧迫されることがある。Microsoftによれば、ESPの空き容量が10MB以下になるとWindows Updateの適用に失敗する可能性がある。 自分のPCのESP空き容量を確認する方法 管理者権限のPowerShellで以下のコマンドを実行することで確認できる。 出典: この記事は Microsoft confirms Windows 11 update is failing on some PCs, explains if you need a workaround の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AMDが台湾・台北で開催されたComputex 2026において、新型GPU「Radeon RX 9070 GRE」を発表した。NvidiaのRTX 5060 Tiがミドルレンジ市場を独走する中、AMDがついに本格的な対抗馬を投入した形だ。 RX 9070 GREとはどんなGPUか GREは「Great Radeon Edition」の略で、中国市場向けに先行投入された経緯を持つが、今回のComputex発表ではグローバル展開が示唆されている。RX 9070シリーズはAMDのRDNA 4アーキテクチャを採用しており、以下の点が注目される： FSR 4対応: AMDの最新アップスケーリング技術で、機械学習ベースの高品質なアップスケーリングをサポート RDNA 4アーキテクチャ: 前世代から大幅に改善されたレイトレーシング性能を搭載 価格帯の競争力: RTX 5060 Tiと同等価格帯でのポジショニングを狙う なぜRTX 5060 Tiがこれほど強かったのか NvidiaのRTX 5060 Tiは、Blackwellアーキテクチャを採用しながら比較的手頃な価格を実現し、ミドルレンジ市場での圧倒的なシェアを確保してきた。特にDLSS 4のクオリティと対応タイトルの多さが、GeForce選択の強い動機となっていた。 一方AMDは、RDNA 3世代でドライバー品質やソフトウェアエコシステムの面での批判を受け、ゲーマーの信頼回復に取り組んできた経緯がある。今世代はその反省を踏まえた投資が実を結びつつある。 FSR 4の急成長が大きな追い風 AMDのFSR 4（FidelityFX Super Resolution 4）はすでに300タイトル超のゲームで対応済みだ。これは単なる数字以上の意味を持つ。ゲーマーがAMD GPUを選ぶ際の「ソフトウェアエコシステムへの不安」が着実に解消されつつある証拠だからだ。 RX 9070 GREはこのモメンタムを活かす絶好のタイミングで投入される。対応タイトルが増え続けるFSR 4と組み合わさることで、製品単体の性能以上の価値を提供できるポジションに立っている。 実務への影響——クリエイターとIT担当者へ ゲーミング用途だけでなく、動画制作・3Dレンダリング・機械学習の推論処理を行うクリエイターやエンジニアにとっても、このGPU競争は注目に値する： 価格競争の恩恵: AMD vs Nvidiaの競争が本格化することで、両社の価格に下押し圧力がかかる可能性がある ROCmエコシステムの拡充: AMDのROCm（GPU向けオープンコンピューティングプラットフォーム）への投資も続いており、推論ワークロードの選択肢が広がりつつある 複数ベンダー調達戦略の現実性: ゲーミングPCやワークステーションの法人調達において、単一ベンダー依存を避ける選択肢として現実味が増してきた 筆者の見解 AMD vs Nvidiaの競争が再び健全な緊張感を取り戻しつつあることは、業界全体にとって歓迎すべき動きだ。独走状態が続くと価格設定やロードマップに緩みが生じるのは市場の必然であり、対抗軸が生まれることで消費者の選択肢が広がる。 RDNA 4世代でAMDはアーキテクチャを大幅に見直し、特にレイトレーシング性能とドライバー安定性の改善に力を入れてきた。その成果とFSR 4という強力なソフトウェア資産が揃った今、「AMDはどうせ……」という固定観念でスキップするのはもったいない局面かもしれない。 とはいえ、Computex発表から実際の発売・サードパーティレビューまでには時間差がある。購入の最終判断は実機ベンチマークが出揃ってからで十分だ。情報を追い続けるよりも、実際に使って成果を出すことに意義がある——まずは発売後のレビューをじっくり確認したい。 出典: この記事は Computex 2026: AMD finally answers Nvidia’s free-ruling 5060 Ti with RX 9070 GRE の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

米フロリダ州が、ChatGPTを開発するOpenAIとCEOのサム・アルトマン氏を相手取った民事訴訟を州裁判所に提起した。Ars Technicaが2026年6月1日に報じた。州政府がOpenAIを提訴するのは全米初となる。 なぜこの訴訟が注目されるのか フロリダ州司法長官ジェームズ・ウスメイヤー氏が提出した訴状は、「OpenAIはフロリダ州民の安全よりも利益を優先している」と指弾するもの。その直接的な引き金は、複数の暴力事件でChatGPTが利用されていたことだ。 Ars Technicaが整理した主な事件 フロリダ州立大学（FSU）銃乱射事件（2026年）: 2名が死亡。容疑者がChatGPTを使って計画を立てていたとされる。フロリダ州は今回の民事訴訟とは別に、OpenAIへの刑事捜査もすでに開始している サウスフロリダ大学（USF）大学院生殺害事件（2026年）: 訴状によると、容疑者は遺体の処理方法・車のVIN番号の変更・犯罪現場での車両確認の有無をChatGPTに問い合わせていた 妻殺害・母親襲撃事件（2026年2月）: 精神的な問題を抱えた男性が「ロボットが世界を支配しようとしている」という思い込みを持つようになり、妻を殺害。1日数時間にわたるChatGPTとの会話が影響したとされる カナダの学校銃乱射事件（2026年2月）: 9名が死亡。アルトマン氏は後に、射手のChatGPTログを当局に通報しなかったことを謝罪した フロリダ州が指摘する設計上の問題点 Ars Technicaの報道によれば、訴状は暴力事件への関与にとどまらず、ChatGPTの設計そのものを問題視している。主な指摘は以下の通り。 ユーザーの主張をひたすら肯定する「過度な迎合（sycophancy）」がユーザーを妄想へと誘い込む 認知機能の低下を示す研究があるにもかかわらず、安全なツールとして宣伝されている 依存性の高い設計が子どもと成人の双方に有害である チャットボットが医師やセラピストを装う行為も問題視。19歳ユーザーがChatGPTの指示でクラトムとキサナックスを混用して死亡したとする別訴訟にも言及 フロリダ州は不公正取引法違反を根拠に最高額の民事損害賠償と、ChatGPTによる被害の差し止めを求めている。 OpenAIの対応 Ars Technicaによれば、OpenAIの声明は司法長官への直接の言及を避け、最近実施した子ども向け安全機能の強化を訴えた。「子どもを失うことは最も深刻な悲劇であり、未成年者保護のために業界最高水準の対策を講じている」としている。 日本市場での注目点 規制立法の先行指標: 全米初の州政府提訴はAI規制立法を加速させる可能性がある。日本でもAI事業者への規制枠組みが議論されており、動向を注視する必要がある 国内でも同様のリスクは存在する: ChatGPTは日本でも広く普及しており、脆弱なユーザーへの影響という観点での社会的議論が高まる可能性がある 企業リスク管理の見直し機会: AIツールを提供・利用する日本企業にとって、安全設計の文書化や利用ポリシーの整備を再点検するきっかけになるだろう 筆者の見解 今回の訴訟で注目すべきは、AI安全をめぐる議論が「技術論」から「法律・社会論」へと本格的に移行しつつあるという事実だ。 「ユーザーの発言を肯定する方向に傾く」というLLMの設計傾向は、AI研究者の間で以前から指摘されてきた問題だ。ユーザー満足度を高めるためにフィードバックを最適化した結果、妄想を強化してしまうという構造的なジレンマは、一事業者だけが解決できるものでもない。だからこそ、業界全体での安全基準づくりが求められていた。 OpenAIには、世界で最も広く使われるAIの一つを作った責任がある。「AIは安全だ」と謳いつつ、安全性に疑問を呈する知見を軽視してきたとすれば、それは問われて当然だろう。ただし今回の訴訟が「AIは危険だ」という短絡的な結論につながることは避けなければならない。問われているのはAIそのものの存在ではなく、「安全設計を後回しにした開発姿勢」だ。 AIが社会インフラとして定着しつつある今、ベンダー・規制当局・ユーザーのそれぞれが「どこまでAIに委ね、どこで人間が介在するか」を真剣に問い直す転換点に来ている。この訴訟はその議論を加速させる一石になるはずだ。 出典: この記事は Florida sues OpenAI, Sam Altman after multiple ChatGPT-linked murders の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Red Hatの公式NPMチャンネルが攻撃者に乗っ取られ、30本以上のパッケージにバックドアが仕込まれたことが明らかになった。Ars TechnicaのDan Goodin記者が2026年6月1日に報じたもので、セキュリティ企業Aikidoの研究者が攻撃を発見した。Red Hatは声明で悪意あるパッケージの削除完了を発表しているが、インストール済みの環境は依然として危険にさらされている可能性がある。 何が起きたのか 標的となったのはNPMリポジトリ上の公式名前空間「@redhat-cloud-services」だ。Red Hatのクラウドサービス向けに使用される正規チャンネルであり、開発者からの信頼度は高い。攻撃者はこの名前空間のアクセス認証情報を何らかの方法で入手し、バックドアを仕込んだパッケージを公開した。 Aikidoの研究者によると攻撃は6月第1週の月曜日に開始されており、記事公開時点でも継続していた。その後数時間以内に大半のパッケージは削除されているが、全部ではなかったという。 悪性ワーム「Shai-Hulud」の動作 セキュリティ企業Socketの分析によると、このマルウェアは以下の認証情報を収集・窃取するよう設計されている。 GitHub Actionsシークレット NPMトークン Kubernetes・Vault認証情報 その他クラウドサービスの認証情報 特に注意すべき点は、ペイロードがnpm installの実行時点——開発者がパッケージをコードにimportする前の段階——で動作することだ。Socketの研究者は「エクスポージャーはランタイムでの使用ではなく、インストールまたはCIの実行に依存する」と警告している。 窃取した認証情報は暗号化されてWebリクエスト経由で外部に送信される。フォールバック機構として、感染マシンが認証情報を持っている侵害済みGitHubリポジトリに暗号化データを書き込む機能も備えている。 さらにこのワームは自己増殖する。感染したデバイスがアクセスできるサードパーティアカウントに対してバックドア入りパッケージを再公開することで、感染が連鎖的に拡大する設計だ。 サプライチェーン攻撃の連鎖構造 「Shai-Hulud」と命名されたこのマルウェアは、先月オープンソースとして無償公開されたコードをベースとしているとArs Technicaは伝えている。TeamPCPというグループが最初に使用し、「このマルウェアで最大規模のサプライチェーン攻撃を実行したハッカーに1000ドルを支払う」というコンテストまで開催していたという。TeamPCPはこれ以前にも複数のサプライチェーン攻撃に関与してきたグループだ。 今回の侵害は、Red HatのCI/CDパイプラインがGitHub Actions OIDC（OpenID Connect）経由で侵害された結果とみられている。Ars Technicaは「Red HatのOIDC侵害は、従業員のマシンが以前のサプライチェーン攻撃で感染したことが発端だった可能性が高い」と推測している——つまり攻撃者が信頼の連鎖を巧みに辿った形だ。 日本市場での注目点 Red HatはOpenShiftをはじめとするエンタープライズLinux・コンテナ基盤として日本の大企業でも広く採用されている。@redhat-cloud-servicesを利用しているプロジェクトは少なくない。 優先的に確認すべきケース: 攻撃発生期間中（6月第1週月曜日以降）にCI/CDパイプラインでnpm installを実行した環境 Red Hatクラウドサービス系パッケージを依存関係に持つリポジトリ 該当パッケージをインストールしたローカル開発環境 Socketの研究者は「影響を受けた@redhat-cloud-servicesパッケージバージョンのいずれかをインストールした組織は、そのシステムが侵害された可能性があるものとして調査すべき」と述べている。GitHubシークレットやKubernetes認証情報が流出していた場合、被害は自組織にとどまらず上流・下流のシステムにも波及するリスクがある。 筆者の見解 今回の事件が示すのは、「公式チャンネルだから安全」という前提がいかに脆いかという現実だ。 開発者の多くはnpm installのたびに依存パッケージの中身を確認しない。合理的な行動だが、攻撃者はまさにその前提を突いてくる。@redhat-cloud-servicesが信頼性の高い公式名前空間であればあるほど、インストール前にスキャンをかける人は少なくなる。 CI/CDパイプラインが攻撃の「ドミノ倒し」の起点になるパターンも今回改めて浮き彫りになった。GitHub Actions OIDCは本来セキュリティを高める仕組みのはずだが、一度侵害されると広範な権限が攻撃者の手に渡ってしまう。GitHubシークレットの最小権限設計と、定期的なローテーションが「道のド真ん中」の対策として現実的だ。 Shai-HulodがオープンソースとしてリリースされたことでTheatアクターの参入障壁が大幅に下がった点も見逃せない。個人開発者から大企業まで、サプライチェーン全体でnpm audit・lock fileの管理・信頼できるパッケージマネージャーの設定を見直す好機だろう。 出典: この記事は Dozens of Red Hat packages backdoored through its offical NPM channel の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Alphabetは2026年、AIインフラとコンピュート能力の拡充を目的とした800億ドル（約12兆4,000億円）規模の株式増資を発表した。Google Cloud・GeminiなどAI関連サービスの基盤強化を目的とした、テック企業による単一資金調達としては業界最大級の規模となる。 今回の発表の概要 注目すべきは調達手法が「株式増資（エクイティ・キャピタル・レイズ）」である点だ。社債や銀行借入ではなく自社株の新規発行で資金を確保する方式は、既存株主の持分希薄化を招く一方で財務的な柔軟性を保ちやすい。Alphabetがこの方法を選んだことは、AI投資を「単なる設備コスト」ではなく「長期的な競争基盤の構築」と位置付けていることを示している。 なぜこれが重要か——AI基盤を押さえる者が勝つゲーム ここ数年、AIインフラへの投資競争は加速の一途をたどっている。 Microsoft: OpenAIとの深い連携を軸に、AzureでのAI基盤投資を積み増し Amazon（AWS）: Anthropicへの出資に加え、自社設計チップ（Trainium / Inferentia）を強化 Meta: 2025年時点で600〜650億ドル規模の設備投資を計画 Alphabet: 今回の800億ドル増資でさらに競争を押し上げる データセンター・GPU・Google独自のAIチップ（TPU）への投資は、生成AIサービスの応答速度・コスト・提供可能なモデル規模に直結する。今回の発表は「お金の多寡」ではなく「AI時代の基盤インフラ争い」の話だ。 実務への影響——日本のエンジニア・IT管理者が見ておくべきポイント Google Cloud利用企業への影響 Vertex AIやGemini APIのパフォーマンス向上・価格競争力の改善が中長期的に期待できる。現在GCP上でMLワークロードを動かしている企業は、今後のサービスロードマップの動向を注視する価値がある。 マルチクラウド戦略の見直し機会 AzureとGCPを使い分けている企業にとっては、大規模投資の後には通常「モデル性能の向上・新機能追加・価格改定」が続くため、今がGCPのAIサービス評価を更新するタイミングかもしれない。 コンプライアンス・データ主権の観点 大規模設備投資は新たなリージョン展開を伴うことが多い。日本国内でのデータ処理要件がある企業は、東京リージョンの拡張動向も合わせて確認しておきたい。 筆者の見解 800億ドルという数字は確かに圧倒的だが、インフラへの投資額がそのまま「優れたAI」に変換されるわけではない。データセンターを積み上げれば自動的に勝てるゲームなら、資本力のある企業が必ず勝つ。しかし実際には、モデルアーキテクチャの改善・開発者エコシステムの充実・エージェント型AIへの実用的な対応——これらが伴わなければ、インフラ投資は大量の電力を消費するだけになりかねない。 Alphabetがこの資金をどう使うかが、今後数年の評価を決める。技術力は間違いなく持っている。その実力を実務の開発者体験として着地させられるかどうかが焦点だ。 日本のIT現場で今すぐすべきことは、特定ベンダーの資金調達ニュースを追い続けることよりも、手元のAIツールを実際に使い倒して成果を積み上げることだ。プラットフォームの盛衰にかかわらず、「AIで具体的な成果を出す経験」こそが個人・組織の競争優位になる。 出典: この記事は Alphabet announces $80B equity capital raise to expand AI infra and compute の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAI製の「ChatGPT for Google Sheets」拡張機能に、間接プロンプトインジェクション（Indirect Prompt Injection）によるデータ流出の脆弱性が発見された。外部シートに仕込まれた悪意ある指示により、ユーザーが「承認を必要とする」設定を有効にしていても攻撃が成立し、アカウント内の複数スプレッドシートが外部サーバーへ流出する。OpenAIは現在、Apps Scriptコード生成機能の無効化により修正済みだ。 何が起きたのか 「ChatGPT for Google Sheets」はOpenAIが提供するGoogle Sheetsアドオンで、リリースから1ヶ月足らずで18.5万件以上のダウンロードを記録した。スプレッドシートのサイドバーでChatGPTと対話しながらデータ操作や計算ができる、業務効率化ツールとして注目を集めていた。 セキュリティ企業PromptArmorが発見したのは、この拡張機能に潜む「間接プロンプトインジェクション」の脆弱性だ。 攻撃チェーンの詳細 攻撃は以下の流れで展開する： 被害者は通常業務を遂行中 — ChatGPT for Google Sheetsを使って財務モデルを作成している 外部データをインポート — 別シートから外部データセットを取り込む 白文字の隠し命令 — インポートしたシートに白色テキスト（不可視）で悪意あるプロンプトが仕込まれている 通常のクエリで攻撃発火 — ユーザーが「このデータを統合して」と入力するだけで攻撃が起動する 外部スクリプトが実行される — 拡張機能に付与された権限を悪用し、攻撃者が用意した外部スクリプトが動作する 財務モデルが流出 — スプレッドシートの内容が外部サーバーへ送信される 芋づる式に拡大 — 盗んだデータ内のURLを辿り、リンクされた他のスプレッドシートも次々と流出 さらに、シートの見た目を偽のChatGPT画面に差し替えるオーバーレイ攻撃や、フィッシングポップアップの表示も同時に実行可能だ。 「承認設定」が機能しない事実 ChatGPT for Google Sheetsには「Apply edits automatically」という設定があり、オフにすると「AIがシートを編集する前に人間の承認を求める」動作になる。多くのユーザーはこれで保護されていると考えていたはずだ。 しかしこの攻撃は承認設定を完全に迂回する。 明示的に人間承認を要求する設定を有効にしていても、外部スクリプトの実行と外部サーバーへのデータ送信は防げなかった。 OpenAIの対応 PromptArmorは責任ある開示（Responsible Disclosure）の手順を踏み、OpenAIに脆弱性を報告した。しかし複数回のフォローアップを行っても、自動返信以外の応答はなかったという。公表後、OpenAIは声明を発表し、Apps Scriptコードの生成機能を無効化することで攻撃ベクターを閉じた。現時点でこの脆弱性は修正済みだ。 実務への影響 Google Workspace管理者がすべきこと 拡張機能の権限スコープを確認する — AIアドオンに与えているGoogle Sheets APIのスコープを見直し、不要な権限は剥奪する 外部データのインポートポリシーを整備する — 信頼できないソースからのデータには、プロンプトインジェクションが仕込まれている可能性がある エンタープライズ利用前にリスク評価を行う — 今後も同様のAIエクステンションが登場するたびに、権限モデルとサンドボックスの設計を確認する習慣が必要だ セキュリティポリシーとしての教訓 「承認設定をオンにしているから安全」という認識は、AI時代における典型的な落とし穴だ。UI上の設定と実際のセキュリティ境界は必ずしも一致しない。重要データへのAIエクステンション接続は、ゼロトラストの視点でリスク評価すべきだ。 ...

JetBrainsは、コード補完に特化したAIモデル「Mellum 2」をオープンソースとして公開した。前世代の「Mellum」も昨年オープンソース化されており、今回はその後継として12Bパラメータを持つ強化版が登場した形だ。 Mellum 2とは何か Mellumは、JetBrainsが自社IDE（IntelliJ IDEA、PyCharm、GoLandなど）向けに開発したコード補完専用のAIモデルだ。汎用LLMとは異なり、「コードを書く」という単一タスクに絞って最適化されている点が特徴で、前世代モデルから大幅に増えた12Bパラメータにより、より精度の高い補完と文脈把握が可能になったとされる。 オープンソース化により、モデルの重みとアーキテクチャが公開される形となる。これはJetBrainsにとって透明性の向上であると同時に、コミュニティによる改善・応用への道を開くものでもある。 なぜこれが重要か コード補完AIの世界は、GitHub Copilot（OpenAI）、Amazon Q Developer、TabNineなど、大手テックベンダーが覇権を争う激戦区だ。その中でJetBrainsが独自モデルを自社IDEに統合し、さらにオープンソースとして公開するという動きは、エコシステム戦略として注目に値する。 特に注目すべき点は「IDE統合型」であることだ。コード補完の精度は、モデル単体の性能だけでなく、IDEがどれだけ正確なコンテキスト（カーソル位置、型情報、プロジェクト構造など）をモデルに渡せるかに大きく依存する。JetBrains製IDEは静的解析とAST（抽象構文木）処理に強みを持っており、Mellum 2はその情報を活かした補完が期待できる。 また、オープンソース化により、企業がモデルをオンプレミス環境に展開し、コードを外部に送信せずに利用できる可能性も広がる。情報セキュリティ要件が厳しい金融・公共系の現場にとっては、実用上の選択肢が増えることを意味する。 実務への影響 JetBrains IDEユーザーへの直接的な恩恵 すでにIntelliJ IDEAやPyCharmを使っているエンジニアは、Mellum 2の恩恵をIDEのAIアシスタント機能を通じて享受できる。特にJavaやKotlin、Pythonの大規模コードベースで作業している場合、型推論と組み合わせた補完の精度向上は実感しやすいだろう。 オンプレ展開・カスタマイズの検討 オープンソース化されたモデルはHugging Faceなどを通じて入手・利用できるようになる可能性がある。自社データでファインチューニングするか、クラウドサービスとして利用するかは、コンプライアンス要件とコストのバランスで判断したい。特に金融・医療・官公庁案件では、コード補完AIの選定において「社外にコードを送らない」という条件が決め手になるケースが増えている。 導入前に確認すべきこと JetBrains AIサブスクリプションとの関係（どの機能がMellum 2ベースか） ライセンス条件（商用利用・改変の可否） オンプレ展開に必要なハードウェアスペック（12Bパラメータは推論コストも相応） 筆者の見解 コード補完AIは今や開発ツールの「あって当たり前」の機能になりつつある。Mellum 2のオープンソース化は、JetBrainsがモデルの透明性とコミュニティへの関与を重視するという明確なメッセージだと捉えている。 個人的に興味深いのは「汎用か専用か」という設計の選択だ。12Bという規模は汎用LLMとしては小さいが、コード補完という絞られたタスクに集中することで、実用的な速度と精度のバランスを狙っているように見える。情報を追い続けるよりも、自分の開発環境に組み込んで実際に使い比べてみるのが、いまの時代の正しいアプローチだと思う。 セキュリティ意識の高い現場では、コードをクラウドに送らずに補完AIを使えるという選択肢は今後ますます重要になる。Mellum 2がその文脈でどれだけ現実的な選択肢になれるか、引き続き注目したい。 出典: この記事は JetBrains open-sources Mellum 2, featuring 12B total parameters の内容をもとに、筆者の見解を加えて独自に執筆したものです。

サイバーセキュリティ企業 Silent Push の研究チームが、「DriveSurge」と追跡している脅威アクターによる大規模マルウェア配布キャンペーンを公表した。数千件の正規 Web サイトを改ざんし、ClickFix および FakeUpdates（FakeUpdate）という2つのソーシャルエンジニアリング手法を組み合わせて訪問者にマルウェアを感染させる仕組みが明らかになっている。 DriveSurge とはどんな脅威アクターか DriveSurge は Initial Access Broker（IAB）、つまり「侵入口を売る業者」として機能している。自身が最終的な攻撃を仕掛けるのではなく、感染端末へのアクセス権を Pay-Per-Install（PPI）モデルで他の攻撃者に販売するビジネスモデルだ。 踏み台となるのは、評判の高い正規 Web サイト。改ざんされたサイトに埋め込まれた JavaScript（t.js?site=<id> というパターン）が、訪問者を zTDS（Traffic Distribution System） に誘導する。zTDS は 2015 年から存在するオープンソースの TDS で、DriveSurge は少なくとも 2025 年 9 月から使用している。 zTDS は訪問者をプロファイリングし、ClickFix か FakeUpdates のどちらの「罠」が有効かを自動判定して振り分ける点が特徴的だ。 ClickFix と FakeUpdates：それぞれの手口 ClickFix 「技術的な問題を解決するために、このコマンドを実行してください」と誘導し、Windows の PowerShell コマンドをコピー＆実行させる手口。ユーザー自身に悪意あるコマンドを実行させるため、エンドポイントセキュリティをすり抜けやすい。今回のキャンペーンでは macOS をターゲットにした亜種も確認されており、クリップボードを乗っ取る「verification テーマ」のページが macOS ユーザーに表示されていた。Windows だけの問題ではない。 FakeUpdates Chrome・Firefox・Edge・Safari・Opera・Brave・Yandex・Vivaldi・Samsung Internet・UC Browser と、ほぼすべての主要ブラウザーになりすました偽アップデート画面を表示し、悪意あるペイロードをダウンロードさせる。Silent Push が確認した事例では、偽 Firefox アップデートが ZIP ファイル（複数の DLL と Browser Update.exe）を展開していた。 調査で判明したインフラ規模 Silent Push の研究チームは DriveSurge のインフラに関連する 8 つの技術的フィンガープリントを特定。これを起点に 80 以上の悪意ある注入ドメインと、まだ攻撃に使われていない「準備済みドメイン」のセットも発見している。攻撃インフラが計画的に用意されていることを示しており、今後さらなる拡大が懸念される。 ...

COMPUTEX 2026に合わせてNVIDIAが台北で開催した「GTC Taipei」の基調講演で、同社CEO ジェンスン・フアン氏が登壇。AIデータセンター向け次世代プラットフォーム「Vera Rubin」のフル生産開始と、AIファクトリー設計をまるごとパッケージ化した「NVIDIA DSX AI Factory Platform」を発表した。PC Watchの笠原一輝氏が現地から詳細をレポートしている。 Vera——AI推論特化の自社設計CPU Vera Rubinは今年1月のCESで発表されたNVIDIAのAIデータセンター向けプラットフォームで、CPU「Vera」とGPU「Rubin」で構成される。フアン氏は「従来のCPUはコア数を増やす設計に特化してきたが、Veraは低遅延に特化した設計」と説明。自社設計「Olympus Core」を採用し、AI推論ワークロードにおいて以下のパフォーマンスをアピールした。 SQLデータ処理: x86比 3倍高速 リアルタイムストリーミング処理: x86比 6倍高速 今回の発表によりVera Rubin NVL72のフル生産が予定通りに開始されたことが確認された形だ。 NVIDIA DSX——データセンター全体の設計をパッケージ化 今回の発表でもう一つの目玉となったのが「NVIDIA DSX AI Factory Platform」だ。NVIDIAが提供するレイヤーは、この数年で段階的に拡大されてきた。 フェーズ 提供範囲 DGX サーバー機器単体 GB200/300 NVL72 ラックレベルの設計 DSX（今回） AIファクトリー（データセンター全体）の設計 AIファクトリーはケースによってはギガワット級の電力を必要とし、800V DC給電・液冷設計・電力安定化のためのバッテリ・キャパシタなど、従来のデータセンターとは根本的に異なる設計思想が求められる。PC Watchの報道によれば、DSXはこうしたノウハウを丸ごとパッケージ化して顧客に提供するものだという。 採用を表明したOEMはDell Technologies、HPE、Lenovo、Supermicro、ASUS、Foxconn、GIGABYTE、Pegatron、Quanta Cloud Technology（QCT）、Wistron、Wiwynnと幅広い。 日本市場での注目点 Vera Rubinはコンシューマー向けGPUではなく、エンタープライズ・データセンター領域の製品だ。ただし、その影響は日本市場にも確実に及ぶ。 国内AIインフラ投資との連動: 政府・民間ともにAIデータセンター投資が急拡大している日本でも、DSXプラットフォーム経由のVera Rubin採用ファクトリー建設が進む見込みだ。採用OEMにはLenovoやSupermicroなど日本での実績が豊富な企業も含まれており、国内調達の選択肢が広がる。 富士通との協業に注目: 昨年のCOMPUTEXではNVLink Fusionに富士通が参画したことが話題になった。今後のDSXエコシステムに日本企業がどう関わるかは引き続き注目ポイントだ。 価格・入手性: Vera Rubin NVL72はコンシューマー向け製品ではないため、一般購入には相応しない。国内でのAIデータセンター需要という観点で注目する製品だ。 筆者の見解 今回の発表で興味深いのは、NVIDIAがハードウェアの売り手から「AIファクトリーの設計・建設を丸ごと支援するプラットフォーム企業」へと軸足を移していることがより鮮明になった点だ。 DSXはNVL72リファレンスデザインの延長線上にある。「NVIDIAの標準スタックに沿って組み立てれば最短経路でAIファクトリーが稼働する」というアプローチは、統合プラットフォームによる全体最適の典型例だろう。部分最適の積み重ねではなく、設計の起点そのものを標準化することでエコシステム全体の効率を底上げする狙いが見える。 フアン氏が今回強調した「使えるAI」というキーワードも示唆的だ。エージェント型AIが常時稼働・リアルタイム推論を前提とするなら、低遅延特化というVeraの設計思想はその流れをしっかり見据えている。自律的に動き続けるAIエージェントを支えるインフラが、今まさに量産ラインに乗ったということになる。 日本市場へのインパクトはエンドユーザーレベルで実感できるのはまだ先だが、AIを活用できる環境の基盤が整いつつあることは確かだ。AIインフラの構築容易化が進めば、大手クラウドプロバイダーでなくても高性能AI推論環境を持てる未来が近づく。その恩恵が日本のエンタープライズにどう届くか、引き続き注視したい。 出典: この記事は NVIDIA、Vera Rubinを量産開始。AIファクトリーの設計もまるっと提供 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ASUSとQualcommは2026年6月2日、Snapdragon X2 Eliteプラットフォームを搭載した世界初のミニPC「Ascent QN10」を発表した。PC Watchが同日報じた。0.7L未満の超コンパクト筐体に最大80TOPSのNPUを内蔵し、ローカルAI処理からエンタープライズ用途まで幅広く対応する意欲的な製品だ。 なぜこの製品が注目か Snapdragon X2 EliteはQualcommのWindows向けSoCの最新フラッグシップで、Ascent QN10はそれを搭載した市場初のミニPCとなる。ARM系アーキテクチャのSnapdragonベースというのは、x86が圧倒的主流のミニPC市場では異色の存在だ。しかし今回注目すべきは単なる「初物」という話ではなく、80TOPSというNPU性能をミニPC筐体に持ち込んできたことにある。 スペックと機能のポイント PC Watchの報道によると、Ascent QN10の主な特徴は以下の通りだ。 超コンパクトでも高性能・静音 容積0.7L未満という小型設計を実現しながら、マルチタスクやAIワークロードを含む複雑なタスクをスムーズに処理できるとされている。長時間の高負荷作業においても静音性と低温を維持できる電力効率の良さが特徴として強調されている。 80TOPSのローカルAI処理と対応エージェント 最大80TOPSのNPUを内蔵し、先進的なAIモデルをローカルで実行できる設計となっている。OpenClawやHermesといったAIエージェントの動作にも対応するとされており、クラウドAPIに依存しないオンデバイスAI処理ワークフローを想定した製品設計が読み取れる。 豊富なUSBポート USB4を3基、USB 3.2 Gen 2を3基、USB 2.0を1基の計7基を装備。ミニPCとしては充実した接続性を備えており、周辺機器の多い開発・業務環境にも対応できる。 エンタープライズグレードのセキュリティ チップレベルからクラウドまで一貫したエンタープライズグレードのセキュリティ機能を組み込み、機密性の高いデータを保護できるとしている。ターゲットユーザーとしてプロシューマー、開発者、小規模事業者、産業用途を挙げている。 日本市場での注目点 現時点では価格・日本発売時期はいずれも未発表だ。Snapdragon X2 Elite自体が発表直後のチップであり、今後の詳細アナウンスに注目が必要だ。 競合製品としては、Intel Core Ultra搭載のASUS NUCシリーズやIntel NUC、AMDプロセッサを搭載したMinisforum・BMAXなどのミニPCが挙げられる。SnapdragonベースのWindows PCはこの1〜2年でノートPCでの採用が広がってきているが、開発ツールチェーンのARM対応やx86エミュレーション時の挙動については引き続き確認が必要な点として残っている。ローカルAI処理を重視する用途であれば、実機レビューが出揃ってから選定するのが現実的な判断だろう。 筆者の見解 80TOPSという数字に注目したい。現行のMacBook Pro（M4 Pro）が約60TOPS、前世代Snapdragon X Eliteが約45TOPSという水準と比べると、このレンジのNPU性能をミニPC筐体に収めてきたことは素直に評価できる。 特に気になるのはローカルAIエージェントへの対応だ。OpenClawやHermesといった具体的なエージェント名が挙がっている点は、「クラウドAPIを叩くだけ」ではなく「手元のハードウェアで完結させる」ワークフローを実現しようとする明確な意図が見える。AIエージェントが自律的にループで動き続ける設計、いわゆるハーネスループ型のワークフローを企業内のオンプレミス環境や、ネットワーク帯域の制約がある現場でも回せるようにしたいというニーズは確実にある。セキュリティポリシーが厳しい企業にとって、ローカルで完結するAI処理は現実的な選択肢になり得る。 一方、SnapdragonとWindowsの組み合わせには、まだ実績の積み上げが求められる部分もある。「世界初」として先陣を切ったことは評価しつつも、実際の開発用途での使い勝手は詳細なベンチマークと実機レビューが揃ってから判断したい。0.7L未満の省スペース設計で80TOPSのNPUを持ち込める方向性は正しい。価格と実性能が見合っているかどうかが、この製品の真価を決める。 出典: この記事は 初のSnapdragon X2 Elite搭載ミニPC、ASUSとQualcommが共同開発 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Tom’s Guideが、情報提供者Debayan Roy氏（X）と韓国メディア「Sisa Journal e」の報告をもとに、Galaxy S27 Ultraのリークスペックを詳報した。まだ公式発表のない段階ではあるが、その内容は長年のSamsungユーザーが待ち望んでいたアップグレードを示唆している。 なぜこのリークが注目されるのか Samsungは2019年発売のGalaxy S20 Ultraから7世代にわたって5,000mAhというバッテリー容量を維持し続けてきた。チップセットの省電力化によって持続時間自体は毎世代改善されてきたが、容量そのものはまったく変わっていなかった。対して競合他社がシリコンカーボン電池で10,000mAh超の製品を投入しつつある中、この「7年間据え置き」はSamsungにとって長年の課題として指摘され続けていた。 リークスペックの詳細 Debayan Roy氏が公開したスペックをTom’s Guideがまとめた比較表は以下の通りだ。 項目 Galaxy S27 Ultra（リーク） Galaxy S26 Ultra ディスプレイ 6.9" LTPO OLED（M16パネル） 6.9" LTPO OLED（M14パネル） プロセッサ Snapdragon 8 Elite Gen 6（2nm） Snapdragon 8 Elite Gen 5（3nm） RAM LPDDR6 LPDDR5X カメラ 200MP広角 / 50MP超広角 / 50MPペリスコープ5倍光学 200MP広角 / 50MP超広角 / 50MPペリスコープ3倍光学 バッテリー 6,000mAh超 5,000mAh 充電 Qi2対応 有線60W / 無線25W その他 アルミフレーム / USB 3.2 / IP68 アルミフレーム / USB 3.2 / IP68 ...

GoogleがGoogle I/O 2026（2026年5月19日）にGemini 3.5 Flashを発表し、同日に正式リリース（GA）として提供を開始した。Gemini APIとGoogle AI Studio、Android Studio、Vertex AIなど複数のプラットフォームで即日利用可能となり、特筆すべきはFlashティアのモデルがProティアをコーディング・エージェント系ベンチマークで初めて上回ったという歴史的逆転だ。 FlashがProを超えた：ベンチマークの詳細 これまでAIモデルの世界では「Flashは速いが性能は劣る」「本番ユースケースにはProを」という常識があった。Gemini 3.5 Flashはこの常識を覆した。 主要なベンチマーク比較： ベンチマーク Gemini 3.5 Flash Gemini 3.1 Pro Terminal-Bench 2.1（コーディング） 76.2% 70.3% MCP Atlas（ツール使用評価） 83.6% — GDPval-AA（エージェント作業・Elo） 1656 — Finance Agent v2 57.9% 43.0% 一方、純粋な抽象的推論（Humanity’s Last Exam: 40.2% vs 44.4%）や長文脈リコール（MRCR v2 128k: 77.3% vs 84.9%）ではGemini 3.1 Proに軍配が上がる。Googleは「知識集約型ユースケース向け」として来月リリース予定のGemini 3.5 Proを位置付けており、Flash／Proの役割分担が明確になりつつある。 技術仕様：1Mコンテキスト・マルチモーダル対応 Gemini 3.5 Flashの主要スペック： コンテキストウィンドウ: 入力最大1,048,576トークン（約100万） 最大出力: 65,536トークン 入力形式: テキスト・画像・音声・動画 モデルID: gemini-3.5-flash 知識カットオフ: 2026年1月 デフォルトで「Dynamic Thinking」が有効化されており、関数呼び出し・構造化出力・検索ツール・コード実行などのツール使用機能を内蔵する。 Managed Agents：シングルAPI呼び出しで自律エージェント展開 今回の発表でもう一つ注目すべきは、Gemini APIのManaged Agentsがパブリックプレビューとして開始されたことだ。 ...

NVIDIAとServiceNowは2026年5月、ServiceNow Knowledge 2026において、企業向け自律型AIエージェント「Project Arc」を共同発表した。ローカルファイルシステムやターミナル、インストール済みアプリケーションに直接アクセスし、複雑なマルチステップタスクを自律的に遂行する——本格的なエンタープライズ向け自律エージェント時代の開幕を告げる発表だ。 Project Arcとは何か Project Arcは、ServiceNowが開発する「長期稼働・自己進化型の自律デスクトップエージェント」だ。対象ユーザーは開発者、ITチーム、システム管理者などのナレッジワーカーで、NVIDIAのJensen Huang CEOとServiceNowのBill McDermott CEOが基調講演で共同発表した。 従来のAIツールがチャット形式での質問応答にとどまっていたのに対し、Project Arcはローカルマシン上のファイルシステムやターミナル、アプリケーションに直接アクセスして複数ステップにわたるタスクを完結させる。単一の指示を実行して終わりではなく、長期にわたって自律的に動作し続ける設計が特徴だ。 ガバナンスが企業導入の鍵——ServiceNow AI Control Tower エンタープライズ向けに特筆すべきは、ガバナンス機能との統合だ。Project ArcはServiceNow Action Fabricを介してServiceNow AI Platformとネイティブ接続しており、エージェントが実行するすべての操作に対してガバナンスと監査証跡が付与される。 「何でもやっていいAI」では企業はリスクを取れない。Project Arcが差別化ポイントとして打ち出しているのは、「自律性とガバナンスの両立」だ。 NVIDIA OpenShell——セキュアなエージェント実行環境 セキュリティ面を担うのが、NVIDIAが提供するオープンソースのセキュアランタイム「NVIDIA OpenShell」だ。サンドボックス化されたポリシー準拠の環境でAIエージェントを開発・デプロイするための基盤として機能する。 OpenShellでは次のポリシー定義が可能だ： エージェントが参照できる情報の範囲 使用できるツールの制限 各アクションの影響範囲のコンテインメント ServiceNowはOpenShellへの貢献も表明しており、エンタープライズグレードのエージェント実行基盤としてオープンエコシステムの形成を目指している。 オープンモデルとドメイン特化スキル NVIDIA Agent Toolkitには、NVIDIAの公開モデル「NVIDIA Nemotron」が含まれており、企業は自社ドメインやデータに合わせてカスタマイズが可能だ。 また「NVIDIA AI-Q Blueprint」を活用したServiceNow AI Specialistsは、ディープリサーチエージェントとして文脈収集・情報統合・複雑な意思決定支援を担う。特定業務ドメインに特化したエージェントを組み合わせる形でエンタープライズAIを構成できる設計だ。 実務への影響——日本のITエンジニア・IT管理者に何が変わるか ServiceNow導入済み企業にとって ServiceNowをITSMやITOMで活用している日本企業は、このProject Arcが「次のフェーズ」として届く可能性が高い。従来のワークフロー自動化の延長線上に、自律型エージェントが組み込まれる形だ。 エンタープライズAI導入の判断軸が変わる これまで「AIの精度」「コスト」が導入判断の主軸だったが、今後は「ガバナンス対応」「監査証跡」「ポリシー準拠」が不可欠な要件として加わる。特に金融・医療・公共分野の日本企業にとって、OpenShellのようなポリシーベースのコンテナ化は評価ポイントになるだろう。 明日から使えるヒント ServiceNow環境がある場合：AI Control TowerとAction Fabricの設定を先に理解しておくと、Project Arc導入時に素早く動ける エージェント設計を始める場合：「どの操作をエージェントに委ねてよいか」を先に組織で定義すると、PoC段階での摩擦が減る NVIDIA OpenShellはOSSなので、今のうちにアーキテクチャを把握しておくことで、将来の調達・設計判断の精度が上がる 筆者の見解 AIエージェントの本質的な価値は「人間の確認を求め続ける設計」からの脱却にある。Project Arcが「長期稼働・マルチステップ・ローカル環境操作」を標榜している点は、まさにその方向性に合致している。 注目したいのはガバナンスとの統合だ。「自律性が高い＝リスクが高い」という企業の懸念に対して、ServiceNow AI Control TowerとOpenShellのポリシーエンジンで正面から答えようとしている構造は筋がいい。ハーネスループ型の自律エージェントが企業内で実際に動くためには、この種の「信頼の基盤」が先に整わなければならない。その順序をわかっている設計だと感じる。 一方で、デスクトップエージェントの完成度は実際に動かしてみないとわからない部分が大きい。「ローカルファイルに直接アクセス」「長期稼働」と聞こえはいいが、実際の業務フローに組み込んで機能するかどうかは、PoC段階での検証が欠かせない。発表のスペックと実動作の間には常にギャップがある。 エンタープライズAIが「生成する」「推論する」の次の段階として「自律的に行動する」フェーズに入ったのは確かだ。Project Arcがその先駆けになるか、あるいは別の形で本命が現れるかはまだわからないが、「ガバナンスと自律性の両立」というアプローチ自体は、これからの企業向けエージェント設計の標準的な問いになるだろう。 ...

CadenceとNVIDIAは、Computex 2026（台湾・台北）において、半導体業界初となる完全自律型AIチップ設計エンジニア「ChipStack™ AI Super Agent」の最新版を共同発表した。NVIDIA Nemotronモデルを基盤に据え、EDA（電子設計自動化）ツール群と深く統合することで、RTL検証サイクルを最大40倍高速化。従来5週間を要していた検証ループを1日未満に圧縮するという具体的な成果が示されている。 Level-5自律性とは何を意味するのか Cadenceは今回の発表で「Level-5自律性」という表現を使った。従来のAIアシスタントが「次に何をすべきか」を人間に問い続けていたのに対し、ChipStack AI Super Agentは仕様の理解・RTL生成・検証計画・フォーマル解析・シミュレーション・デバッグ・設計収束という一連のワークフローを、エンジニアの逐次指示なしに自ら判断・実行・反復する。 NVIDIAの社内では数千人のエンジニアが年間数十億計算時間を消費し、膨大な数のテストを実施して設計を検証している。ChipStack導入後、各エンジニアは1エージェントあたり数百回の動的シミュレーションをCadence Xcelium Logic SimulationおよびJasper Formal Verificationと組み合わせて実行できるようになるという。 セキュリティと「物理的真実」への接地 自律エージェントが高度化するほど避けられない問題がセキュリティと信頼性だ。Cadenceはこの点を「Grounded in Engineering Truth」として明示的に訴求している。エージェントの挙動は、同社が長年培ってきた物理ベースの設計・検証エンジンと密結合されており、AIが生成するアクションは常にサインオフ精度のある計算モデルによって検証される。 実行環境にはNVIDIAの「OpenShell」ランタイムを採用。エージェントをサンドボックス内で動作させ、ポリシー制御・アイソレーション・アクセス管理によって設計IPを保護する。「実験的パイロット」から「本番グレードの自律フロー」へ移行するための現実的な道筋を提供している点は、エンタープライズ採用を見据えた構成として評価できる。 なお、ChipStackはClaude CodeやOpenAI Codexなどの外部ツールとの統合にも対応しており、エンジニアが自律的な処理の進捗や意思決定を透過的に確認できるインターフェースを備える。 日本の半導体・自動車・航空宇宙分野への影響 日本国内においては、自動車半導体（ルネサス、ソニーセミコンダクタ等）や防衛・航空宇宙向けのカスタムASIC開発で、EDA検証の工数削減は長年の課題だった。RTL検証5週間→1日未満という数字が現実になれば、設計サイクル全体の短縮と開発コスト削減の両方に直結する。特にEVや自動運転向けSoC設計では検証ループの反復コストが開発ボトルネックの主因になっているケースが多く、この領域への即効性は大きい。 また「エンジニア不足」が深刻な日本では、熟練エンジニアの認知負荷を下げて1人あたりの担当設計数を増やせることが、採用難に対する現実的な回答になり得る。 実務での活用ポイント まずNVIDIA内部導入事例の詳細を追う: NVIDIAのエンジニアが実際にどのワークフローをどの程度自動化できたかの事例が今後公開されるはず。それが最も信頼できるベンチマークになる OpenShell環境のポリシー設計から着手する: 本番投入で最初の壁になるのはセキュリティポリシーと社内IP管理だ。エージェントに渡すツール・データの範囲を先に決めておくことが導入成否を左右する Claude CodeやCodeexとの統合: ChipStackが明示的に互換性を謳っている以上、既存のAIコーディングツールチェーンと組み合わせた「監視ループ」の構築が現実的な第一歩になる 筆者の見解 「副操縦士が提案し、人間が承認する」という設計思想では、工数削減の上限はせいぜい20〜30%に留まる。ChipStack AI Super Agentが示したLevel-5自律性——エージェントが自ら評価・判断・反復しながらタスクをクローズするまでループし続けるアーキテクチャ——は、AIが本来持つポテンシャルを正しく引き出す方向性だと思う。 半導体設計という「正解が物理法則によって厳密に定まる」ドメインは、自律エージェントの信頼性担保がしやすい最良のフィールドの一つだ。「物理ベースのエンジンに接地する」というCadenceのアプローチは、AI出力の幻覚リスクを構造的に抑制する設計として筋がいい。 今後注目したいのは、このような自律ループアーキテクチャがEDA以外の設計領域——ファームウェア・クラウドインフラ・業務システム——へどのように横展開されていくかだ。Computex 2026は、その転換点を象徴する発表が複数出た週として記憶されることになるかもしれない。 出典: この記事は Cadence Unveils Industry’s First Fully Autonomous Virtual Engineer for Chip Design, powered by NVIDIA の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年6月1日、MicrosoftはCopilot製品群の課金モデルを定額制から従量制へと移行した。AIクレジットとトークン消費量に基づく新しい計算方式が導入され、企業ユーザーの間では想定外の請求額、いわゆる「メーターショック」への警戒感が高まっている。特にCopilot Studioを活用したエージェント自動化を進めていた組織では、早急なコスト管理体制の見直しが求められる。 何が変わったのか：定額制から消費ベースへ 従来のMicrosoft 365 Copilotは、ユーザーあたり月額固定料金で提供されていた。しかし今回の変更により、Copilot Studioを中心とした機能群が「利用した分だけ支払う」方式に移行した。 メッセージの送受信、AIエージェントの実行、外部システムとの連携、ドキュメント処理といった各操作が消費ユニットとしてカウントされ、月次の利用量によって請求額が変動する。従来の「ライセンスを買えば使い放題」という感覚で運用を続けると、思わぬ請求額が届くことになる。 AIクレジットとトークンコストの仕組み 新課金体系の主な構成要素は以下の通りだ。 AIクレジット アクション単位で消費される仮想通貨のような存在。Copilot Studioでのエージェント呼び出しや外部コネクタとの連携操作1回ごとに消費される。多くのM365ライセンスには月間一定量のクレジットが付属しているが、それを超えた分は追加請求となる。 トークンコスト 入出力テキストの長さに比例して課金される。長い会議録の要約、大量のメール整理、複雑なプロンプトを使ったドキュメント生成などは、それだけトークン消費が増える。「ちょっと試しに」の積み重ねが月末に大きなコストになることがある。 利用状況の確認方法 Microsoft 365管理センター内の「Copilot使用状況レポート」や、Azureコストマネジメントポータルのメーター表示でリアルタイムの消費状況を確認できる。まずはここを開いて現状を把握することが第一歩だ。 メーターショックが起きやすい3つのシナリオ 1. SharePoint/Teamsでの大量ドキュメント処理 長い議事録や添付ファイルを繰り返しCopilotに要約させると、トークン消費が急速に積み上がる。特に全社展開で「全員が毎日使う」運用になっているケースは要注意だ。 2. 外部コネクタ連携 SalesforceやSAPなど外部システムとのCopilot統合は、CRM/ERPへのAPI呼び出しのたびにクレジットを消費する。連携数が多い企業ほどベースラインコストが高くなる。 3. エージェントのバックグラウンド自動実行 Power Automateと連動してエージェントが夜間・週末に自動動作するシナリオでは、誰も気づかないうちに大量消費が発生しうる。スケジュール実行のエージェントは特に使用量上限の設定が必須だ。 実務への影響：IT管理者が今すぐ取るべき行動 即時対応 M365管理センターで「Copilot利用状況レポート」を確認し、現在の消費ペースと予測コストを把握する Copilot Studioの管理コンソールでテナントレベルの月間クレジット上限を設定する 自動実行エージェントの一覧を洗い出し、不要なものは停止・削除する 中期的な対応 エンドユーザーへの周知：「長い文書をそのまま貼り付けるとコストがかかる」という意識を浸透させる プロンプト標準化：部門ごとに効果的な短いプロンプトをテンプレート化し、無駄なトークン消費を削減する ユースケース別ROI評価：実際に業務価値を生んでいないCopilot利用を特定し、コスト削減対象とする 筆者の見解 Copilotの従量制移行は、「使った分だけ支払う」という原則を徹底する動きであり、方向性としては理解できる。定額制では利用実態と収益が乖離しやすく、ヘビーユーザーが全体のコスト構造を圧迫するという課題が実際にあった。 ただし、正直なところ気になるのはコストの透明性だ。Copilotはチャットのような直感的なUIで操作できる設計になっているが、「この操作でクレジットがいくら消費されたか」がリアルタイムで把握しにくい。Azureのコストマネジメントは後からしか確認できないケースも多く、メーターショックが起きてから対応するのでは遅い。 Microsoftには優れたエンタープライズ管理基盤がある。Cost Management、Entra、Intuneを組み合わせれば、本来は細粒度なコスト制御ができるはずだ。その力をCopilotのコスト可視化にも正面から活かしてほしい。従量制への移行を機に、「費用対効果を定量的に示せるCopilot」として生まれ変わる契機にしてもらえることを期待したい。コストが明確になれば、ROIの出るユースケースと出ないユースケースがはっきりする。それはむしろ、正しい使い方が広がるチャンスでもある。 出典: この記事は Copilot to Usage Billing June 1, 2026: AI Credits, Token Costs, and Meter Shock の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月24日を期限として、Windows 11を含む対象PCユーザーに対しSecure Boot証明書を新しい2023年版へ更新するよう緊急呼びかけを行った。期限切れ後もPCは通常起動できるが、ブートレベルのセキュリティ保護が受けられなくなるリスクが生じる。 Secure Boot証明書とは何か Secure Bootは2011年にWindows 8とともに登場したセキュリティ機能だ。OSが起動する前にブートローダーやドライバーが正規のデジタル署名を持つかどうかを確認し、改ざんされた悪意あるコードの実行を防ぐ。この署名の正当性を保証するのが「Secure Boot証明書」であり、当初から使われてきた証明書が2026年6月24日に失効する。 期限切れで何が起きるのか 証明書が失効しても、PCが即座に起動不能になるわけではない。しかし次のリスクが現実のものとなる。 新しいブートレベルのセキュリティ更新が適用されなくなる：以後リリースされるSecure Boot関連の保護が機能しない状態になる Secure Boot依存の機能が動作しなくなる可能性：BitLockerや一部のTPM連携機能、セキュリティソフトウェアに影響が出るケースがある ブートキット攻撃への脆弱性が高まる：攻撃者がブートプロセスを改ざんするリスクが相対的に増す Microsoftはフリート内の全デバイスを6月26日までに移行させることを推奨している。 対応方法 Windows Updateで対応できるケース ほとんどのWindows 11ユーザーはWindows Updateを実行するだけで新しいSecure Boot証明書が自動適用される。設定アプリから「Windows Update」を開き、最新の更新プログラムを確認・適用すればよい。 手動対応が必要になるケース 以下の環境では、手動でのBIOSアップデートが別途必要になる場合がある。 Windows 10でESU（Extended Security Updates）に加入していないユーザー 初期のWindows Update配信波に含まれなかった一部のWindows 11ユーザー 古いUEFIファームウェアを搭載したレガシーハードウェア Microsoftはこの問題に関して1時間のAMAセッションを開催しており、エンタープライズや旧型ハードウェアの具体的なシナリオについても詳細情報を提供している。 実務への影響 企業のIT管理者にとって、6月26日というデッドラインは即応を求めるものだ。 フリート管理のポイント IntuneやGroup Policyを使い、Windows Updateの適用状況を一括確認する 未適用デバイスをコンプライアンスポリシーで検出し、優先度をつけて対応する 古いハードウェアはBIOSアップデートの提供有無を各メーカーサイト（ASUS・Dell・HP・Lenovo等）で個別確認する Windows 10ユーザーへの注意 Windows 10は2025年10月にメインストリームサポートが終了しており、ESUに加入していない端末は証明書更新も受け取れない。この機会をWindows 11移行計画加速のきっかけとして捉えるべきだ。 仮想化環境の確認 Hyper-VやAzure VM上でSecure Bootが有効なゲストOSも影響を受ける可能性がある。仮想マシンのテンプレートや展開済みイメージの設定も合わせて見直しておきたい。 筆者の見解 Secure Bootそのものの仕組みは、ブートキットやルートキットに対する有効な防御ラインであり、正しい方向性だと評価している。ただ今回気になるのは、証明書の失効がわかっていた問題であるにもかかわらず、デッドライン1か月前になって改めて警告を発しなければならなかった点だ。 エンタープライズ環境では変更管理のリードタイムが長く、1か月で全デバイスを更新するのが現実的に厳しい組織も少なくない。もう少し早い段階からの積極的な情報発信と、管理ツールへの組み込みがあれば現場の負担を減らせたはずで、そこはもったいなかったと感じる。 Microsoftほどのリソースがあれば、Intuneと連携して「証明書更新が必要なデバイス一覧」をダッシュボードで可視化するといった仕組みを提供できるはずだ。セキュリティの底上げを本気で進めるなら、警告を出すだけでなく「管理者が何もしなくても安全になる」方向への投資を期待したい。 当面の対応として、まず自社フリートのWindows Update適用状況を確認し、6月24日前に更新を完了させることを最優先にしてほしい。 出典: この記事は Microsoft Warns Unpatched Windows 11 PCs Face June 2026 Secure Boot Block の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはExchange Online上のExchange Web Services（EWS）について、2026年10月1日よりブロックを段階的に開始し、2027年4月1日に完全廃止することを正式に発表した。長年にわたりメール・予定表・連絡先の自動処理を支えてきたEWSが、ついに終焉を迎える。 EWS廃止のスケジュールと何が起きるか 今回発表されたタイムラインは以下のとおりだ。 2026年8月末まで: AppID AllowListおよびEWSEnabled=Trueの設定が必要（猶予期間） 2026年10月1日: EWSの段階的ブロック開始。管理者が明示的に許可リストを設定していない限り、EWSリクエストはすべて拒否される 2027年4月1日: 完全廃止。再有効化は不可 重要な点として、Exchange Server（オンプレミス）はこの変更の対象外だ。影響を受けるのはExchange Onlineのみである。 管理者が何もしなければ、MicrosoftがテナントのEWS設定を自動的にEWSEnabled=Falseに変更する。その結果、EWSに依存するカスタムアプリやベンダー製品がサイレントに動作停止する。 「スクリームテスト」——気づかせるための仕掛け 興味深いのが「Scream Test（悲鳴テスト）」という手法だ。Microsoftは2026年10月より前に、一時的にEWSを無効化するテストを実施する可能性があるとしている。これはEWSへの依存関係を炙り出すための意図的な障害演出であり、管理者が事前に依存アプリを把握できるよう設計されている。 これを逆手に取って「テストが来る前に自分でEWS利用状況を洗い出す」ことが、今すぐ動くべき最大の理由だ。 移行先はMicrosoft Graph一択 代替APIとなるMicrosoft Graphは、EWSが提供していたほぼすべての機能をカバーしている。メール送受信・予定表操作・連絡先管理・添付ファイル処理——EWSで実現していたユースケースはGraph APIで置き換えられる。 さらにGraph APIはモダン認証（OAuth 2.0 / Azure AD）を前提としており、セキュリティ面でも旧来のEWS＋Basic認証の組み合わせより大幅に強固だ。 実務での対応ステップ IT管理者がすぐに着手すべきことを整理する。 Step 1: EWS利用状況の棚卸し Microsoft 365管理センターの診断ツール、またはMicrosoftが提供するPowerShellスクリプトを使い、テナント内のEWSリクエスト発生元（AppID）を特定する。見落としやすいのはレガシーな社内ツール、サードパーティのシステム連携アダプター、古いバックアップソフトなどだ。 Step 2: 移行可否の判断 EWSを使っているアプリをGraph API対応版にアップデートできるか確認する。ベンダー製品の場合は、対応版リリース予定をサポートに問い合わせること。自社開発ツールはGraph SDKへの書き換えが必要だ。 Step 3: どうしても移行できないアプリの一時延命 2026年10月以降も一時的にEWSが必要な場合は、AppID AllowListに対象アプリを登録し、EWSEnabled=Trueを設定する。この設定は2026年8月末までに完了させておくこと。2027年4月以降はこの延命措置も使えなくなる。 Step 4: 内部への周知 特に「知らないうちに誰かが使っていた」パターンが一番危険だ。IT部門だけでなく、業務部門が独自に導入しているRPA・マクロ・連携ツールにEWSが含まれていないか確認を依頼する。 筆者の見解 EWSは2009年にExchange 2007向けに登場した古いAPIであり、廃止そのものは遅すぎるくらいだ。Basic認証廃止に続くモダン認証への移行の流れとしても、方向性は正しい。Graph APIへの一本化によって、セキュリティ管理の煩雑さは確実に減る。 ただし問題は「10月」という期限の切迫感だ。現時点（2026年6月）から猶予は実質2ヶ月しかない。EWSへの依存状況を棚卸しして、ベンダーへの問い合わせをして、移行計画を立てて——これを2ヶ月でこなすのは、規模の大きな組織ほどきつい。 Microsoftがこのタイミングでスクリームテストを予告しているのは、ある種の親切心でもある。「先に気づかせてあげる」というアプローチ自体は評価できる。ただ、もう少し早い段階でより大きな声でアナウンスしてほしかった、というのが正直なところだ。同様の移行（Basic認証廃止など）で何度も痛い目を見た企業が、今回も「知らなかった」となる前に、管理者は今すぐ動くべきだ。 Graph APIへの移行は手間がかかるが、一度やりきれば認証・権限管理・監査ログが統一されて運用が楽になる。この機会を「コスト」ではなく「技術的負債の返済」として捉え、前向きに対処することを強くお勧めする。 出典: この記事は Exchange Web Services (EWS) Retirement Update – October 2026 Block Begins の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年6月1日より、SharePoint Online（Plan 1・2）およびOneDrive for Businessの単体プランの新規購入を終了した。今後は「Microsoft 365 Business Basic」や「E1」などのスイート製品への移行が必要となり、規模や用途によっては大幅なコスト増が避けられない。 廃止されるプランと背景 対象プラン 今回廃止となるスタンドアロンプランは以下の通りだ。 SharePoint Online Plan 1：$5/ユーザー/月（ドキュメント管理・1TBプールストレージ） SharePoint Online Plan 2：$10/ユーザー/月（無制限ストレージ＋コンプライアンス機能） OneDrive for Business Plan 1・2：同様の料金体系 「月数百円で使えるクラウドストレージ」として中小企業を中心に重宝されてきたプランが、ここで幕を閉じる。 Microsoftが示す廃止理由 Microsoftは主に3点を廃止理由として挙げている。 需要の減少 — 多くの企業がすでにMicrosoft 365スイートを契約しており、単体プランの利用者は年々減少してきた 維持コストの増大 — 独立プランを維持し続けるための開発・サポートコストが経済的に見合わなくなった 「想定外の利用」への対応 — コラボレーションツールとして設計されたにもかかわらず、単純な安価ストレージとして利用されるケースが増加していたことが背景にあるとみられる 移行先と費用の現実 代替となるMicrosoft 365プラン プラン 月額（ユーザーあたり） Microsoft 365 Business Basic $7 Microsoft 365 Business Standard $14 Microsoft 365 Business Premium $22 Microsoft 365 E1 $10 Microsoft 365 E3 $39 Microsoft 365 E5 $60+ MicrosoftはBusiness BasicやE1を代替として提示しているが、実際にSharePointやOneDriveの機能をフル活用するには、Business PremiumまたはE3が現実的なラインになるケースが多い。 ...