Tech News JP

Microsoftは、VS Code 1.122においてローカルAIモデルを用いた完全オフライン（エアギャップ）環境でのコーディング支援を正式サポートした。インターネット接続が制限された政府機関・金融機関・医療機関の開発者も、AIを活用した補完・提案機能を利用できるようになる。 エアギャップ対応とは何か これまでVS CodeのAIコーディング支援（GitHub Copilotをはじめとする各種拡張）は、クラウドAPIとの通信を前提としていた。ネットワークが厳格に遮断された「エアギャップ環境」では、こうした機能は事実上使用不可能だった。 VS Code 1.122では、OllamaやLM Studioといったローカル推論サーバー上で動作するオープンソースモデルをVS Codeに直接接続する仕組みが公式に整備された。プロンプトも補完候補も一切インターネットを経由しない。モデルの選択からエンドポイント指定まで、VS Codeの設定画面から完結できる。 モバイルデバイステスト機能も追加 1.122のもう一つの注目点は、エディタ内でWebアプリのモバイル端末テストが行える新機能だ。外部エミュレーターを別途用意せずとも、VS Code内から複数のモバイルデバイスの画面サイズ・操作感を確認できる。Chromeのデベロッパーツールに近い操作感で、フロントエンド開発のコンテキストスイッチを減らせる。 なぜこれが日本のエンタープライズに刺さるのか 日本の大手企業・官公庁では、情報セキュリティポリシーにより開発端末のインターネットアクセスが厳しく制限されているケースが多い。プロキシ経由にとどまらず、完全にクローズドなネットワーク上で開発が行われている現場は決して少なくない。 そうした組織の開発者はこれまで、クラウドベースのAIコーディング支援ツールをほぼ使えない状況に置かれていた。今回の公式対応は、こうした「取り残された開発者」に正規の選択肢を提供するものだ。特に恩恵が大きいのは次の業種だろう： 金融機関：基幹系・取引系システムの閉域開発環境 官公庁・防衛関連：省庁内ネットワーク、機密情報を扱う開発室 医療機関：電子カルテシステム等のネットワーク分離環境 実務での活用ポイント ローカルモデルの選び方 コーディング用途ならDeepSeek-Coder、Codestral、Qwen2.5-Coderといったコーディング特化モデルが実績を持つ。GPU性能が低い環境では量子化モデル（Q4_K_M等）を選択することでレスポンスが大幅に改善する。まずOllamaを導入し、ollama run deepseek-coder等でモデルを起動するところから始めるのが最短ルートだ。 VS Codeとの接続手順 OllamaまたはLM Studioをローカルマシンにインストールし、任意のモデルを起動する VS Codeの拡張機能（GitHub Copilot Chat またはContinue等）のエンドポイント設定でローカルURLを指定する Ollamaの標準は http://localhost:11434 — これを登録するだけで利用開始できる セキュリティレビューの観点では、モデル自体がオンプレミスで動作し通信が発生しない点を明示することで、社内の承認が通りやすくなる。 注意すべき品質差 ローカルモデルの提案精度はクラウドモデルと比べてまだ差がある。チームとして「このモデルの提案をどの程度信頼するか」という評価基準を事前に合わせておくことが重要だ。 筆者の見解 今回の対応で注目したいのは、MicrosoftがVS Code本体に公式機能として組み込んだという事実だ。OllamaとVS Codeの連携自体は以前から技術的に可能だったが、それはあくまで「非公式な設定」だった。公式サポートとなることで、企業のセキュリティ審査や調達フローを通りやすくなるという副次効果が生まれる。「サードパーティが非公式に対応している」と「ベンダーが公式にサポートしている」では、社内承認のハードルがまるで違う。 エアギャップ対応はAIコーディング支援ツールの成熟を示す一つのマイルストーンでもある。「AIはクラウドで使うもの」という暗黙の前提が崩れ始め、エッジでもオフラインでも同等の体験が提供される方向に進んでいる。 日本の規制の厳しい業界にとっては、「やっと来たか」というタイミングだろう。AI活用の恩恵を受けにくかった開発者層に、正規の経路で生産性向上の道が開かれる意義は小さくない。MicrosoftにはVS Code周辺のローカルAI体験をさらに磨いていってほしいところで、その力は十分にある。 出典: この記事は Microsoft just made it possible to use VS Code completely offline with local AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは米国ユーザーを対象に、ヘルスケア特化型AIアシスタント「Copilot Health」の正式提供を開始した。血液検査の数値解読や個人の健康記録の安全な管理を支援する機能を備え、Copilotプラットフォームの医療分野への本格展開が始まった。 Copilot Healthでできること Copilot Healthは、一般ユーザーが医療情報の壁に直面する場面を主なターゲットにしている。主な機能は次のとおりだ。 検査結果の解読: HbA1cやeGFRといった専門用語を含む血液検査レポートを、わかりやすい日常語で説明する 医療データの一元管理: 個人の健康記録（PHR: Personal Health Record）をセキュアに保持し、必要なタイミングで参照できる 受診前の整理支援: 症状や疑問をまとめてAIに問いかけ、「次回の受診で何を医師に聞くべきか」を事前に整理できる 医療情報は専門用語が多く、患者が自分自身の診断結果を正確に理解するのは難しい。AIがこのギャップを埋める役割を担うという方向性は、実用的かつ需要のある設計だ。 セキュリティとプライバシー：最も問われる領域 医療データは個人情報の中でも最高レベルの機密性を持つ。米国ではHIPAA（医療保険の携行性と責任に関する法律）への準拠が必須であり、Microsoftはこれを前提とした設計を行っているとみられる。 ただし、AIに医療データを渡す際は以下の確認を怠らないことを強く推奨する。 データがどのリージョンのサーバーで処理されるか 入力データがモデルの学習に使用されないか（Microsoft 365の商用テナントと同様の保護があるか） 通信・保存時の暗号化が適用されているか ゼロトラスト原則の観点から言えば、医療AIに対しても「常時信頼ではなく都度検証」のアプローチが不可欠だ。 日本のIT現場への影響 現時点でCopilot Healthは米国限定の展開だが、日本のエンジニアや管理者にとっても無関係ではない。 日本ではマイナンバーカードと健康保険証の統合が進み、電子処方箋・電子カルテの普及も加速している。患者が自分の医療データにAIを通じてアクセスするシナリオは、数年以内に現実のものになる可能性が高い。 実務上の視点から整理すると： 医療系SaaSを扱うエンジニア: MicrosoftのCopilot Health設計（HIPAAコンプライアンス対応、データフロー）は、国内の医療DXシステム設計の参考になる M365管理者: Copilotの適用範囲が業務系から個人ヘルスケアへと広がる流れを把握しておくと、将来の社内ポリシー改定に備えられる 情報セキュリティ担当者: 従業員が個人の医療AIサービスに業務端末からアクセスするケースを想定し、利用ガイドラインを事前に整備しておくことを勧める 筆者の見解 Microsoftが医療AIに踏み込んだことは、企業としての実力が素直に活かせる領域への展開だと思う。医療データのプライバシー管理、厳格なコンプライアンス対応、エンタープライズグレードのセキュリティ基盤——これらはMicrosoftが長年磨いてきた強みそのものであり、他のAIプレイヤーが簡単に追いつけない部分だ。 ひとつ率直に言えば、「また名前がCopilot」という点は気になる。Copilot Studioも、Copilot for M365も、Windows Copilotも、そして今度はCopilot Health。ブランドの傘が広がるたびに、ユーザーは「どのCopilotの話をしているのか」という混乱と付き合わされる。医療という真剣なコンテキストでこそ、製品の独自性を明確に伝えるネーミングと設計にしてほしかった、というのが本音だ。 とはいえ、M365エコシステムとの連携という強みをきちんと活かした製品に仕上がっているなら、正面から評価したい。日本展開と実際の医療現場での活用事例が出てくるのを楽しみにしている。 出典: この記事は Microsoft Copilot Health is now available to users in the US の内容をもとに、筆者の見解を加えて独自に執筆したものです。

JetBrainsが、Python開発者やデータサイエンティストに広く使われてきたIDEの提供を終了すると発表した。同社はここ数年でFleet（軽量エディタ）、Aqua（テスト専用IDE）、Code With Meなど複数製品の廃止を進めており、今回の決定はその延長線上にある。 DataSpell終了の背景 JetBrainsはデータサイエンス・機械学習向けに特化したIDE「DataSpell」を2021年に一般公開した。Jupyter Notebookとの統合、インタラクティブなデータ分析環境、Pythonインタープリタとの深い連携が特徴で、データサイエンティストからの評価は高かった。 しかし、JetBrainsの主力Python IDE「PyCharm Professional」が継続的な機能強化によってDataSpellの機能を取り込んでいった結果、DataSpell固有の優位性は薄れていった。JetBrainsは今回の廃止にあたり、DataSpellのすべての機能がPyCharm Professionalに統合・継承される形で引き継がれると説明している。 製品ラインナップ整理の全体像 過去数年のJetBrains製品廃止の動きをまとめると、以下のとおりだ。 Fleet（2024年廃止）: VS Codeに対抗した軽量エディタ。リモート開発・マルチ言語対応を売りにしていたが市場に定着できなかった Aqua（廃止済み）: E2Eテスト専用IDE。テストエンジニア向けのニッチな製品だった Code With Me（廃止済み）: リアルタイム共同コーディングツール DataSpell（今回）: Pythonデータサイエンス特化IDE 共通するパターンが見える。「特化型IDEをリリース → 主力IDEが機能追いつく → 特化型を廃止してProfessionalに統合」という周期だ。 既存ユーザーへの影響と移行パス DataSpellのサブスクリプションを契約しているユーザーは、同等のJetBrains製品への移行が提供される予定だ。実務的な移行先はPyCharm Professionalとなる。 PyCharm Professionalは現在、以下のデータサイエンス向け機能を備えている。 Jupyter Notebookのネイティブ編集・実行 Conda/venv/Poetry等の環境管理 DataFrameのインタラクティブビュー Matplotlibやseabornの出力インライン表示 データベース接続ツール DataSpellユーザーが日常的に使っていた機能のほとんどは、PyCharm Professionalで代替できる状態になっている。 実務への影響——日本のエンジニア・IT管理者にとっての意味 ライセンス管理者向け: JetBrains All Products Packを契約している組織は影響を受けにくいが、DataSpell単体ライセンスを購入・管理していた場合は、PyCharm Professionalへの切り替え申請と社内展開の更新が必要になる。 データサイエンティスト向け: 移行作業自体は軽微だが、DataSpellに慣れたワークフロー（特に起動時のプロジェクト構成やショートカット配置）は若干変わる。PyCharm Professionalでも同等の作業環境を構築できるが、初期設定に数時間は見ておきたい。 VS Code/Cursorへの乗り換え検討: 今回の廃止を契機に、無料で高機能なVS Codeや、AIコーディング統合が進む他エディタへの移行を検討するチームも出てくるだろう。特にデータサイエンス用途ではJupyter拡張が成熟しており、実用上の選択肢は広い。 筆者の見解 JetBrainsのここ数年の製品整理は、ある意味で正直な経営判断だと思う。特化型IDEを量産して広げすぎ、メンテナンスコストが分散し、どれも中途半端になるよりも、主力製品に機能を集約して品質を高める方が長期的にはユーザーのためになる。 ただ、ユーザーから見ると「また廃止か」という疲弊感は否めない。FleetはVS Codeへの対抗として期待された製品だったし、DataSpellもデータサイエンス界隈で着実なファンを持っていた。製品を出して廃止するサイクルが続くと、次の新製品への信頼感が積み上がりにくくなる。 AI統合という点では、PyCharm自体のAI支援機能（JetBrains AI Assistant）の充実がこれからの勝負所だ。データサイエンス領域はとりわけAIコーディング支援との相性が良い。特化型IDEの廃止で生まれたリソースを、PyCharm ProfessionalのAI機能強化に集中させるなら、今回の判断は将来に向けた布石として評価できる。製品を絞り込んだぶん、残った製品を確実に進化させてほしい。 出典: この記事は End of an era: JetBrains is killing this popular IDE used by Python devs の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはComputex 2026およびBuild 2026の開幕を来週に控え、「Windows 12」をめぐる各種憶測に対して公式見解を示すとともに、「PCの新時代（a new era of PC）」の始まりを発表すると予告した。 「Windows 12」の噂、なぜここまで拡散したのか 近年、技術メディアやリーク情報を扱うコミュニティでは「Windows 12」という呼称が独り歩きしていた。その背景には、Windows 11のリリースサイクルが従来より長期化していること、Microsoftが「AI PC」に向けた機能強化を断続的にアップデートで投入してきたこと、そしてCopilot+ PCという新カテゴリの登場がある。これらが積み重なり、「次の大型OSはいつか」という市場の期待感が高まっていた。 Microsoftは今回、こうした憶測を「整理（clarify）」する立場を取った。つまり否定でも全面肯定でもなく、発表のタイミングと文脈をコントロールするための先手を打った形だ。 「PCの新時代」——Computex・Build 2026での発表内容とは Microsoftが予告した「a new era of PC」というフレーズは、単なるOS世代交代以上の意味合いを持つ可能性がある。Computex 2026はIntel・Qualcomm・AMDが次世代チップを競うハードウェアの祭典であり、Build 2026はAI・クラウド・開発者向け機能が発表されるソフトウェアの場だ。この両者を同時期に狙ったMicrosoftの発表は、ハードウェアとソフトウェアを一体で見せる戦略と見るのが自然だ。 具体的に予想されるのは以下のような要素だ： AI PC統合の深化: NPU（ニューラルプロセッシングユニット）を前提としたオンデバイスAI機能の本格展開 Copilot+ PC向け新機能: Recall、Click to Do、Live Captionsなどの追加・強化 UI/UXの刷新: スタートメニュー、タスクバー、設定周りの再設計の可能性 開発者向け機能: WSL（Windows Subsystem for Linux）やDev Drive、GitHub Copilot連携の強化 日本のIT現場への影響 日本企業の多くはWindows 11への移行を進めている最中であり、「また新しいOSが来るのか」という懸念が生まれるのは自然だ。しかし、現時点で確認できることを整理しておこう。 IT管理者・情報システム部門へ Build 2026の発表内容を確認するまで、移行計画を大幅に変更する必要はない 「Windows 12」という呼称が正式に採用される保証はなく、機能アップデートという形で提供される可能性も十分ある Windows 10のサポート終了（2025年10月）は変わらない。この期限から目を離さないことが最優先 エンジニア・開発者へ Build 2026のセッションカタログとデモをリアルタイムで追うことを強く推奨する AI PC向けAPIや新しいWinUIコンポーネントが発表された場合、既存アプリのモダナイズ計画に影響する可能性がある オンデバイスAIを活用したアプリ設計の検討を今から始めておくと、発表後のキャッチアップが圧倒的に速くなる 筆者の見解 正直に言えば、Windowsの発表を以前ほど興奮して追いかけることは少なくなった。それでも今回の発表予告には、一定の期待を持って見ている自分がいる。 「PCの新時代」というフレーズは確かに大げさに聞こえる。Microsoftはこの手の大言壮語を繰り返してきた歴史があり、実際の中身が伴わなかったことも少なくない。しかし今回に限っては、AI PCというハードウェアの波、オンデバイス推論の現実的な性能水準の到達、そして企業向けセキュリティとコンプライアンスの統合という文脈が重なっており、「絵に描いた餅」に終わらない素地はある。 Microsoftには、総合プラットフォームとしての底力が確かにある。Azure・M365・Windows・Copilot Studioが連携するエコシステムは、単体スペックの比較では見えない価値を持つ。来週の発表が、その総合力を「使えるAI PC体験」として具現化できるものであってほしい。 セキュリティ面では特に注目している。Copilot+ PCのオンデバイス処理はデータを外部サービスに送らない設計であり、エンタープライズのコンプライアンス要件に沿いやすい。ここが本当に機能するなら、「AIは使いたいがクラウドには送れない」という日本企業の悩みに対する有力な答えになり得る。 実際の発表内容を見てから改めて評価したい。マーケティング言語ではなく、エンジニアが触れる機能とAPIで語ってほしい。それだけだ。 ...

OpenAIは、コーディング支援AIツール「Codex」のWindowsアプリをバージョン26.527へアップデートし、これまでMacユーザー限定だった「Computer Use（PC自律操作）」と「モバイルアクセス」の2機能をWindowsでも利用可能にした。 Computer Useとは——AIがPCを「使う」機能 Computer Useは、AIがユーザーのPC上でマウス操作・キーボード入力・画面認識を自律的に行える機能だ。コーディング支援の文脈では、コードを書くだけにとどまらず、IDEの操作、ブラウザでのドキュメント参照、コマンド実行まで一連の作業をAIが代行できる。 「コードを貼り付けてもらう」レベルを超え、「開発環境の中でAIが実際に手を動かす」段階に踏み込んだ機能と言える。これまでMac版のみに先行提供されていたが、今回のアップデートでWindows環境でも使えるようになった。 モバイルアクセス——移動中も指示出しが可能に もう一つの新機能はモバイルアクセスだ。スマートフォンからCodexにアクセスし、コーディングタスクの指示出しや進捗確認が行える。複雑な開発作業をスマホで完結させることは現実的でないが、「移動中に次のタスクを仕込んでおく」「作業状況を外出先から確認する」といった使い方は十分に実用的だ。 実務への影響 Windowsメイン環境のエンジニアにとってのメリット 日本のエンタープライズでは、まだWindowsを主要な開発環境として使うチームが多い。PC操作機能の解禁により、繰り返し作業の自動化や、セットアップ手順をAIに口頭で説明しながら実行させるといった利用スタイルが現実的な選択肢になってくる。 Computer Use利用時のリスク管理 PC操作機能は強力な半面、AIが誤操作した場合のリカバリを事前に考慮しておく必要がある。実務での初期導入は、影響範囲が限られた仮想マシンやコンテナ上から始めることを強く勧める。本番環境に直結した状態でいきなり使うのはリスクが高い。 エンタープライズのセキュリティポリシーとの整合性 AIにPC操作を許可するということは、どのアプリやデータへのアクセスを認めるかの管理が必要になることを意味する。ゼロトラスト原則に基づき、Codexに付与する権限は最小限に絞り、ログ取得と定期的な棚卸しをセットで運用するのが理想的だ。 筆者の見解 Mac先行・Windows後追いという流れは、開発ツールの世界でもはや定番になった。このリリースのたびに、開発者の主戦場がどちらに傾いているかを改めて実感させられる。 Computer Use機能が本当に成熟すれば、コーディングの前工程（要件調査・資料確認）から後工程（デプロイ・テスト監視）まで含めた自律サイクルが実現し得る。それはコーディング支援の枠をはるかに超えた話になる。 ただ、機能の充実よりも先に問われるべきは「エラー時の安全策とユーザーへのフィードバックが十分か」という点だ。AIが意図しない操作をしてしまったとき、どこまで被害を最小化できるかが実用性の分かれ目になる。 「使わせない」という判断は現実的に機能しない。「安全に使える仕組みを整える」方向で検討することが、結果的にリスクを下げる近道だ。 出典: この記事は OpenAI rolls out major Codex for Windows update with computer use and mobile access の内容をもとに、筆者の見解を加えて独自に執筆したものです。

HPは同社PCユーザーの約30%が依然としてWindows 10を使い続けていると明らかにした。Microsoftが精力的にWindows 11への移行を促しているにもかかわらず、PCメーカー大手の顧客の3人に1人がサポート終了済みのOSを使い続けているという、現場の実態が浮き彫りになった。 Windows 10サポート終了から7か月超——それでも3割が残留 MicrosoftはWindows 10のサポートを2025年10月14日に終了した。つまり今日（2026年5月末）時点で、すでにセキュリティ更新プログラムが届かない状態が7か月以上続いている。それでもなお、HP顧客の約3割が移行を完了していないという事実は、企業・個人を問わず「移行の壁」がいかに高いかを示している。 Windows 10のサポート終了は決して突然の話ではなかった。Microsoftは2021年の段階からWindows 11の提供を開始し、数年間にわたって移行を呼びかけてきた。にもかかわらずこの数字が残る背景には、いくつかの構造的な理由がある。 移行を妨げる3つの壁 1. ハードウェア要件の厳格化 Windows 11の最大の関門はTPM 2.0とCPU世代の要件だ。Core第7世代以前のIntel CPU、またはRyzen 1000番台以前のAMD CPUは原則として非対応となる。企業では3〜5年の標準サイクルで机上PCを運用しているケースが多く、更新タイミングが合わなければ機器ごとの入れ替えが必要になる。調達・予算・展開作業のすべてが伴うため、「今期はとりあえずWindows 10のまま」という判断が積み重なりやすい。 2. 業務アプリ・レガシーシステムとの互換性 特に日本のエンタープライズ環境では、古い業務システムや社内開発ツール、セキュリティ製品のサポート状況が移行の判断を左右する。移行前にすべての業務アプリを検証し、問題があれば代替調達するか、例外環境を整備する必要があるため、リソースが限られる中小企業では後回しになりがちだ。 3. 「まだ動いているから大丈夫」という惰性 「サポートが切れても使えるじゃないか」という感覚は根強い。しかし、サポート終了後のWindows 10はセキュリティパッチが届かないため、新たな脆弱性が発見されても修正されない。エンドポイントの一部が穴になると、ネットワーク全体のゼロトラスト設計も台無しになりかねない。 実務への影響——IT管理者が今すぐ確認すべきこと Windows 10残存端末のリスク評価を今すぐ実施する 管理対象端末のOSバージョン分布をMicrosoft Intune（エンドポイント分析）またはMicrosoft Defender for Endpointで確認する。Windows 10端末が残っている場合、そのエンドポイントはパッチ未適用のまま稼働しているリスクが高い。条件付きアクセスポリシーでコンプライアンス非対応端末をネットワークリソースから切り離すことも検討に値する。 移行ロードマップを3か月単位で引き直す 「いつかやる」では進まない。四半期ごとにWindows 10端末の削減目標を設定し、機器更新計画と連動させる。Microsoftが提供するWindows 11互換性チェックツール（PC Health Check）を活用して、更新可能な機器から先行して移行を進めると効率的だ。 拡張セキュリティ更新プログラム（ESU）の購入を検討する MicrosoftはWindows 10向けに有償のESU（Extended Security Updates）プログラムを提供している。2026年10月まで最大3年間、月額料金でセキュリティパッチを受け続けることができる。個人向けには30ドル（年額）、法人向けはデバイス台数・ライセンス形態によって異なる。完全移行までのブリッジとして活用を検討する価値はある。ただし、これはあくまで時間稼ぎであって、根本的な解決ではない。 筆者の見解 「30%が今もWindows 10」という数字は、正直なところ驚かない。むしろ「まだそんなものか」という感覚すらある。Windows 10は完成度が高く、多くのユーザーにとって「不満がない」OSだった。移行の動機が「メリットを感じるから」ではなく「サポートが切れるから仕方なく」では、意思決定のスピードが出ないのは当然だ。 MicrosoftはWindows 11への移行をこれだけ強力に推進してきた。それでも3割が残るということは、ハードウェア要件の設計に課題があったのではないかと思う。セキュリティ強化の方向性は間違いなく正しい——TPM 2.0の必須化もセキュアブートの標準化も、カーネルドライバーの締め出しと並んで意義のある変更だ。ただ、「正しいけれど急ぎすぎた」という印象は否めない。もう少し段階的なアプローチがあれば、移行率は今より高かったはずだ、ともったいなさを感じる。 いずれにしても、IT部門がやるべきことは明確だ。「まだ動いている」を根拠にWindows 10に居続けるのは、今となってはリスク管理の観点から正当化しにくい。移行コストと放置リスクを天秤にかければ、答えはほぼ決まっている。残存端末の棚卸しと具体的なロードマップの策定を、今週中にでも始めてほしい。 出典: この記事は HP: 30% of PC customers are still running Windows 10 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teamsが新機能「Efficiency Mode（効率モード）」を近日中にロールアウトする。低スペックのハードウェアでもTeamsがスムーズに動作するよう、リソース管理をインテリジェントに最適化する仕組みだ。 Efficiency Modeとは何か Efficiency ModeはTeamsがバックグラウンドに回ったとき、あるいはリソースに余裕がない端末上で動作しているとき、CPUやメモリの消費を自動的に抑制する機能だ。Windows 11に実装されている「効率モード」プロセス管理と同様のアプローチをTeams自体に取り込んだ形と言えばイメージしやすいだろう。 具体的には、ミーティングに参加していない待機中の状態でバックグラウンド処理を絞り込み、通知の処理・同期・プレゼンス更新などを必要最低限に制限する。アクティブな会議やチャットには支障が出ないよう、フォアグラウンドに戻った瞬間にフル機能で動作する仕組みになっている。 なぜこれが重要か TeamsはMicrosoft 365環境の中核に位置するが、その代償として常駐プロセスによるリソース消費は長年の課題だった。特に以下の状況で問題が顕在化している。 Celeron・Atom系プロセッサ搭載の廉価ノートPC（教育現場や中小企業で多く使われている） 8GB以下のRAM構成（Teamsと他のOfficeアプリを同時起動するとすぐに逼迫する） バッテリー駆動のモバイル利用（バックグラウンドのTeamsが電池を食い続ける問題） 日本企業のPC更新サイクルは平均5〜7年と言われており、スペックに余裕のない端末が現役稼働しているケースは珍しくない。Efficiency Modeはそうした環境での実用性を底上げする施策として意味がある。 実務への影響——エンジニア・IT管理者が押さえるポイント 管理者側での対応 現時点でEfficiency ModeはTeamsクライアント側で自動的に機能する設計と見られる。Teams管理センター（TAC）でのポリシー制御が可能になる場合は、低スペック端末グループへの強制有効化を検討したい。 ユーザー体験への影響確認 バックグラウンド処理の制限により、プレゼンス更新のタイムラグや通知の若干の遅延が発生する可能性がある。展開後は「自分が離席中に見えているか」「通知は届いているか」を実際に確認してほしい。 端末調達の判断材料として Efficiency ModeがあるからといってRAM 4GBの端末を買い続けていい理由にはならない。あくまで「既存の低スペック端末での延命策」と位置づけ、新規調達ではRAM 16GB以上を標準とするスタンスは変えないほうがよい。 筆者の見解 Teamsのリソース消費問題は、MVPコミュニティでも長年語られてきたテーマだ。Efficiency Modeの登場そのものは歓迎している。ただ、「もっと早くできたはずでは？」という思いは正直ある。 Windowsのプロセスレベルの効率モードが先行して実装され、アプリ側がそれに追いついてきた形だが、TeamsはMicrosoftのフラッグシップ製品だ。OSの機能を自社製品にすばやく取り込む点では、もう少し機敏でいてほしいとは思う。 とはいえ、方向性は正しい。「重いから使わない」という選択肢が許されない業務環境でこそ、こうした最適化が効いてくる。特に1人1台端末が普及しつつある教育現場や、PC更新予算が厳しい中小企業において、実質的な恩恵は小さくない。 Teamsはコミュニケーション基盤としてすでに不可欠な存在だ。その土台をしっかり磨き込んでいく作業は地味に見えるが、現場で使い続けてもらうための本質的な投資だと思っている。今後もこうした「縁の下の力持ち」的な改善を積み重ねてほしい。 出典: この記事は Here is how Efficiency Mode will work in Microsoft Teams の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google は2026年5月、Chrome の新セキュリティ機能「Device Bound Session Credentials（DBSC）」の一般提供を開始し、全ユーザーへの展開を始めた。セッションクッキーをデバイスのTPMやSecure Enclaveに暗号的に紐付けることで、クッキーを盗み出されても攻撃者が悪用できない状態にする仕組みだ。 セッションクッキー盗難の何が問題か 多要素認証（MFA）が普及した今も、「クッキー窃取→アカウント乗っ取り」という攻撃手法は現役で使われ続けている。ブラウザがログイン状態を記憶するために保存するセッションクッキーを入手すれば、攻撃者はパスワードもワンタイムコードも不要でアカウントにアクセスできてしまうからだ。 代表的な情報窃取型マルウェアである Lumma や Rhadamanthys は、Google の OAuth 「MultiLogin」APIエンドポイントを悪用して期限切れのクッキーを再生する機能まで実装していた。これに対してGoogleはこれまで「マルウェアを除去せよ」「Enhanced Safe Browsingを有効にせよ」と呼びかけるしかなかった——DBSC以前は、クッキーが盗まれた時点でほぼ詰みだった。 DBSCの仕組み——鍵はハードウェアの外に出ない DBSCはセッションクッキーを特定デバイスのハードウェアセキュリティチップに暗号的に紐付ける技術だ。 Windowsの場合: TPM（Trusted Platform Module） macOSの場合: Secure Enclave セッション確立時にセキュリティチップが公開鍵・秘密鍵のペアを生成し、クッキーの暗号化・復号に使用する。秘密鍵はチップの外に一切出ないため、マルウェアがクッキーファイルを盗み出しても、対応する秘密鍵なしには使えない状態になる。 Googleは「事後検知から事前防止へのパラダイムシフト」と表現しており、「クッキーが盗まれること自体を防ぐ」のではなく「盗まれたクッキーを使えない状態にする」という設計思想がポイントだ。 展開状況と管理者が知っておくべき制約 DBSCは現在、以下のアカウントへ順次展開中だ。 Google Workspace 企業ユーザー Workspace Individual サブスクライバー 個人Googleアカウント利用者 管理者にとって重要なのは、Google Workspaceでは管理者がDBSCを無効化できない点だ。有効化はデフォルトで行われ、管理コンソールからのオプトアウトは提供されない。ユーザー体験に影響が出た場合でも、設定で戻す手段がないことを事前に把握しておく必要がある。 実務への影響——日本のエンジニア・IT管理者が押さえるべき点 1. TPMの搭載・有効化状況を確認する DBSCはTPM対応デバイスを前提とする。Windows 11がTPM 2.0を必須要件とした背景と整合しているが、古いPCや設定上TPMが無効になっている環境では効果が限定的になる可能性がある。BIOS/UEFIでTPMが有効になっているかを一度確認しておきたい。 2. InfoStealer対策はEDRと組み合わせて多層化する DBSCはクッキー盗難の「悪用」を防ぐが、マルウェアの侵入自体を防ぐわけではない。EDR（エンドポイント検知・対応）によるマルウェアの早期検知と組み合わせることで、多層防御が初めて完成する。 3. ログ監視の重点を移行する準備を クッキー再利用による不審なセッション異常が今後減っていく代わりに、攻撃者はフィッシングやクレデンシャルスタッフィングなど別の初期アクセス手段に移行する可能性が高い。セキュリティ監視の重点を「セッション系の異常」から「認証試行の異常パターン」にシフトさせる準備を始めたい。 4. サードパーティサービスへの普及は時間がかかる 現時点でDBSCが有効に機能するのはGoogleサービス向けに限られている。一般のWebサービスがDBSCのAPIを実装するまでの「過渡期」は相応の時間がかかるため、過信は禁物だ。 筆者の見解 「MFAを突破できるのだからMFAは意味がない」という言説がSNSでたびたび流れるが、これは正確ではない。問題の本質はMFAの弱さではなく、認証後のセッション管理の甘さにある。DBSCはその弱点を、既存のクレデンシャル管理フローを変えずにハードウェア層で塞ぐ設計だ。「禁止」ではなく「仕組みで安全にする」という方向性は、IT現場で機能する本物のセキュリティ対策の正道だと思う。 ゼロトラストの文脈で言えば、「デバイスの信頼性を認証フローに織り込む」という考え方はまさに原則に忠実だ。これまでデバイスの信頼性はネットワーク層やMDM（モバイルデバイス管理）で担保しようとしてきたが、DBSCはブラウザのセッション層でも同じ思想を実現した点が評価できる。 ただし懸念もある。Workspaceの管理者が無効化できない設計は、エンタープライズ環境でのトラブル対応を難しくする可能性がある。新機能の強制展開は互換性問題が出たときの退避策がないという意味でリスクでもある。Googleがこの点についてどう対応するか、引き続き注目したい。 出典: この記事は Google Chrome adds session cookie theft protection for all users の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ企業Flareのリサーチャーが、ダークウェブにおけるDDoS攻撃販売市場の実態調査を発表した。2023年と2026年のデータを比較した結果、高品質なDDoS攻撃サービス広告が約10倍に急増しており、サイバー犯罪の「製品化」が急速に進んでいることが明らかになった。 DDoS攻撃がSaaSモデルへ進化 以前のDDoS攻撃といえば、スクリプトキディが使い捨てのツールを使うか、フォーラムに散在するリーク済みコードを組み合わせるような「手作り感」があった。それが今や、月額プラン・API連携・リセラープログラム・カスタマーサポート付きの「商品」として流通している。 Flareが2023年1〜5月と2026年1〜5月のデータを比較したところ、以下のような変化が確認された。 指標 2023年 2026年 変化 高品質なDDoS攻撃サービス広告数 38件 364件 約10倍 ユニークな広告クラスター数 31 123 約4倍 関与するユニークアクター数 15 41 約3倍 観測ソース数 22 43 約2倍 攻撃パネル・ボットネット連携・Cloudflareバイパス機能・ゲームサーバー特化オプションなど、機能面でも成熟が見られる。文字通り「月額課金で攻撃力を借りる」時代になっている。 現実の被害規模は想像を超える 数字だけでなく、実際の攻撃規模も右肩上がりだ。Cloudflareは2025年に7.3 Tbpsの攻撃をブロックし、同年Q4には31.4 Tbpsという記録的な攻撃の緩和も報告している。 MicrosoftもAzureが2025年10月に15.72 Tbpsの攻撃を緩和したと発表。この攻撃は「Aisuru」ボットネットによるものとされており、攻撃インフラの大規模化・高度化を裏付けている。 なぜいま日本のIT現場に影響するのか DDoS攻撃の「製品化」が進むことで、以前は技術スキルが必要だった攻撃が誰でも購入できるようになる。参入障壁が下がると、攻撃者の層が広がる。競合への嫌がらせ、恐喝目的のランサム的DDoS、政治的動機による攻撃など、動機の多様化も同時に起きる。 日本企業にとっての脅威面では以下の点が特に重要だ： ECサイト・決済系サービス: 売上繁忙期を狙った攻撃が$5〜$10程度で「発注」できる時代になっている SaaS・API基盤: アプリケーション層を狙う攻撃手法が増えており、ネットワーク帯域だけ守れても不十分 ゲームサーバー特化オプション: オンラインゲーム・メタバース系サービスは専用攻撃手法の標的になりやすい 実務での防衛ポイント 1. CDN/DDoS緩和サービスの活用を前提設計に Cloudflare・Azure DDoS Protection・AWS ShieldといったマネージドDDoS緩和サービスは、今やオプションではなく基本インフラとして位置づけるべきだ。緩和サービスなしでテラビット級攻撃を自前で処理しようとするのは現実的でない。 2. レート制限とWAFの多層防御 アプリケーション層（L7）攻撃はログインページやAPIエンドポイントを集中的に狙う。IP単位のレート制限、ボット検知、WAFルールを組み合わせて縦深防御を構成する。 3. インシデント対応計画の事前整備 「攻撃を受けてから考える」では遅い。対応手順・エスカレーション先・ISPへの緊急連絡窓口を事前に整備し、定期的な机上訓練を実施する。 4. 脅威インテリジェンスの活用 Flareのようなダークウェブ監視サービスを活用することで、自社を標的にした攻撃サービスの出回りを事前に察知できる可能性がある。完全な防御はないが、早期警戒は対応時間を生む。 筆者の見解 この調査が示しているのは、サイバー犯罪の「民主化」がいかに速く進んでいるかだ。技術的ハードルが極端に下がったとき、脅威の広がり方は質より量になる。DDoS攻撃サービス広告が3年で10倍になったという数字は、攻撃者コミュニティの活発化を端的に表している。 ゼロトラストの文脈でいえば、DDoS対策も「境界で防ぐ」発想から脱却する必要がある。テラビット級の攻撃を自前の境界機器で止めようとするのは、ゼロトラストが目指す「信頼を前提にしない設計」と同じ方向性の話だ——大規模攻撃を前提として、緩和・分散・回復力の設計を最初から組み込む。 AzureのDDoS Protectionが15.72 Tbpsの攻撃を緩和できたのは、クラウドスケールの緩和インフラあってこそだ。こういう部分はクラウドプロバイダーの強みが素直に発揮される領域で、オンプレミスで同じことをやろうとするのはコスト・技術力ともに無理筋だと思う。 日本のエンタープライズで気になるのは、DDoS対策が「ネットワーク部門の問題」として矮小化されているケースがまだ多いことだ。アプリケーション層攻撃が増えている今、開発・インフラ・セキュリティが連携した設計レビューが欠かせない。攻撃者の側が成熟したサービスモデルで来るなら、守る側も同じくらい組織的に対応する必要がある。 出典: この記事は From $5 Attacks to Botnet-Powered Platforms: Inside the DDoS-as-a- Service Market の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ企業Push Securityは、ChatGPTのコンテンツ共有機能（chatgpt.com/s/）を悪用して偽のOpenAI障害ページを表示し、マルウェアをChatGPTデスクトップアプリに偽装して配布する「LLMShare」キャンペーンを発見した。 攻撃の仕組み — 正規ドメインを盾にした新手のフィッシング 攻撃者はGoogle広告経由でChatGPTを検索するユーザーをchatgpt.comの正規共有リンクへ誘導する。リンクを開くと、チャット会話ではなく「ただいまアクセスが集中しています。ウェブ版は一時的にご利用いただけません。デスクトップアプリをダウンロードしてください」という障害通知が表示される。 驚くべきは、この偽通知がChatGPT自身のHTMLレンダリング機能を使って生成されている点だ。攻撃者はカスタムHTMLとCSSをChatGPTのプロンプトでレンダリングし、それをchatgpt.com/s/リンクとして公開した。ユーザーのブラウザには「chatgpt.com」という正規URLが表示されている。 Push Securityによれば、ページには「コードを表示」「ChatGPTでリミックス」というコントロールが含まれており、コードを確認すれば偽物と判断できる。しかし、一般ユーザーがそこまで確認するケースはほぼない。 ダウンロード先でも二段構えの偽装 「ダウンロード」ボタンをクリックすると、openew[.]appというOpenAIを模したサイトに誘導される。このサイトはクローキング技術を採用しており、URLScanなどのセキュリティスキャンツールからアクセスした場合は無害なAR/VRサービスのページを表示する。ターゲットにのみマルウェアを見せる巧妙な設計だ。 macOS版とWindows版の両方が用意されており、Windows版はAny.Runでの分析で仮想マシン検出コマンドを実行することが確認されている。最終的なペイロードは不明だが、同様の手口を使った過去のキャンペーンではインフォスティーラーが配布されていた。 Claude Artifactsも同様の手口で悪用 Push Securityは、AnthropicのClaude Artifactsも同様に悪用されていることを確認している。こちらはClickFixスタイルの攻撃で、レンダリングされたアプリを使ってユーザーに悪意あるコマンドを実行させる手口だ。 AI共有機能の悪用は今回が初めてではない。今年初めにはClaudeのダウンロードを検索するユーザーをGoogle広告経由で悪意ある共有チャットに誘導する攻撃も確認されており、ChatGPT・Grok・Claude Artifactsと、AIプラットフォームの共有機能全体が攻撃ベクターとして定着しつつある。 実務への影響 — IT管理者とエンドユーザーへの注意点 エンドユーザーへ: ChatGPTをはじめとするAIツールのダウンロードは、必ず公式サイト（openai.com）から直接行う Google広告経由でAIツールを検索・ダウンロードしない chatgpt.com/s/ の共有リンクで障害通知やダウンロードを促す画面が表示されたら即座に離脱する IT管理者へ: DNSフィルタリングやWebプロキシでAIツールの公式ドメイン以外からのバイナリ取得をブロックするポリシーを設定する エンドポイント保護でOpenAI/Anthropic公式サイト以外からのAIツールインストールを制限する セキュリティ意識向上トレーニングで「正規URLでも安全ではない」ケースとして本件を具体例として活用する 筆者の見解 今回の手口で改めて浮き彫りになったのは、「URLの正規性≠コンテンツの安全性」という事実だ。chatgpt.comという完全に正規のドメインから偽の障害ページが配信される——従来の「URLを確認しろ」という啓発では対処できない時代に入っている。 この問題の本質は、AIプラットフォームが提供する「自由なHTMLレンダリング×公開共有リンク」という組み合わせにある。利便性のために設計された機能が、そのまま攻撃インフラに転用されている構図だ。OpenAI・Anthropicともに、共有コンテンツのレンダリング範囲や用途制限について早急に対策を講じる必要がある。 エンタープライズ環境では、AIプラットフォームへのアクセスを「禁止」するのではなく、公式ルートのみを通じてアクセスできる仕組みを整備することが重要だ。禁止アプローチは必ず迂回される。社員が正規の手段でもっとも便利に使える環境を作ることが、結果として攻撃面を狭めることにつながる。 AIツールの急速な普及とともに、こうした攻撃はさらに巧妙化・多様化するだろう。「ChatGPTが落ちているからアプリをダウンロードする」という行動は、AIを日常的に使うユーザーにとって自然な流れだ。技術の進化に合わせたセキュリティ教育の継続的な更新が、いまもっとも急ぎ対処すべき課題の一つだと考える。 出典: この記事は ChatGPT share links abused to host fake outage pages to deliver malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Simon Willison氏が、Python ASGIフレームワーク（FastAPI、Datasette等）をバックエンドサーバーなしでブラウザ上で完全動作させる新しい手法を実証した。PyodideとService Workerを組み合わせることで、従来の課題だった<script>タグの実行問題を解決し、プラグインを含むフル機能のDatasette 1.0a31がブラウザ上で動作することを確認している。 従来のアプローチと課題 Willison氏はDatasette Liteを2022年に公開した際、Web WorkerとPyodide（WebAssembly上のPython実装）を組み合わせてブラウザ上でPythonアプリを動かす手法を採用していた。 ただしこの方法には根本的な制約があった。<script>タグ内のJavaScriptが実行されないため、Datasetteの一部機能やプラグインが正常に動作しないという問題だ。単純なデータ参照には十分だったが、インタラクティブな可視化やプラグインエコシステムの活用は実質的に不可能な状態だった。 Service Workerによる解決策 今回の新手法では、Service WorkerがブラウザとWebの間に立ってリクエストをインターセプトする。/app/以下への同一オリジンのリクエストをすべて捕捉し、ASGIプロトコル経由でPyodide上のPythonアプリに処理を渡す仕組みだ。 重要なのは、ブラウザが返ってきたHTMLレスポンスを通常のページとして描画する点だ。<script>タグも正しく実行されるため、JavaScriptを多用するプラグインやUIコンポーネントが問題なく動作する。FastAPIとDatasette 1.0a31の両方で動作が確認されており、ASGI準拠のアプリであれば原理的に動作するという汎用性の高さも特筆すべき点だ。 Claude Opus 4.8がアーキテクチャ探索を加速 今回の実装では、Claude Code for webからClaude Opus 4.8にアーキテクチャ探索のタスクを依頼したことも公開されている。Willison氏自身が実装の詳細を完全に把握する前に動作するものが完成した——という経緯は、AIを活用した開発スタイルの現在地を象徴している。「実装を理解してから書く」から「動くものを作って理解する」へのシフトが、AIと組む開発では加速している。 実務への影響 この手法が実用化されると、いくつかの用途で大きなメリットが生まれる。 データ分析ツールの配布コスト削減: PandasやSQLiteを使うデータ探索ツールをサーバーなしでホスティングできる。GitHub PagesやCloudflare Pagesなど静的サイトホスティングだけで配布できるため、インフラコストがほぼゼロになる。 フルスタックアプリのプロトタイプ: FastAPIのエンドポイントをブラウザ上でそのまま動かせるため、バックエンド開発者がサーバーなしでUIを試せる環境が整う。デモ作成やハッカソンでの活用が即座に思い浮かぶ。 オフライン対応アプリ: Service Workerはオフラインキャッシュとも相性が良く、ネットワークなしで動作するPythonアプリという選択肢も現実味を帯びてくる。 日本のエンジニアにとっては、PoC（概念実証）やデモ環境を作る際に「サーバーを立てずにPythonのロジックを動かす」という選択肢が一つ増えることになる。 筆者の見解 「ブラウザでPythonが動く」という話はPyodideの登場から続いているが、今回の実証はその実用性を一段と引き上げた。従来のWeb WorkerアプローチはJavaScript実行の制約という壁があり、プラグインエコシステムを持つアプリには不向きだった。Service Workerを活用してその壁を取り除いたのは、技術的に筋のいい解決策だ。 AIを活用した技術探索の加速という側面も興味深い。実装を理解しきる前に動作するものが完成し、後から仕組みを読み解くというスタイルは、AIエージェントと組んで探索的な開発をするときに起きやすい。大切なのは「動いた」で終わらず、その仕組みを自分のものにして次のプロダクトに転用できる状態にすること。その作業は今も人間側の重要な仕事だ。 PyodideとWASMの成熟が続く中、「軽量なPythonツールはサーバーなしで動かす」という選択肢が今後のフロントエンド開発の当たり前になっていく可能性はある。データエンジニアやデータサイエンティストが自作ツールを配布する際に、この仕組みは強力な武器になるだろう。Datasette Liteへの適用が完了したとき、その実用性の評価が本格的に始まる。 出典: この記事は Running Python ASGI apps in the browser via Pyodide + a service worker の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが2026年5月の年次開発者会議（Google I/O）で発表した24時間稼働型AIエージェント「Gemini Spark」が、実際の日常タスクでどこまで使えるかをTechCrunchが検証した。クラウド上の仮想マシンで動作し、ユーザーがPCをシャットダウンしている間もタスクを自律実行するという新設計のアシスタントだが、実用性と課題の両面が明らかになった。 Gemini Sparkとは何か Gemini Sparkは、Gmail・Googleカレンダー・Docs・Sheets・Slidesといった既存のGoogleサービスと統合し、「デジタルライフのナビゲーション」を担うことを目的としたエージェント型AIだ。 CEOのサンダー・ピチャイ氏は発表時に「ラップトップを閉じていい」と表現した。これはタスク実行にPCの常時起動が必要だった従来のAIエージェントとの違いを示すもので、Googleが「技術に詳しくない一般ユーザー向けのエージェントAI」として位置づけていることがわかる。 実際に何ができるのか Sparkが想定するユースケースは主に以下の3つだ： 受信箱の要約と優先タスク抽出: メールとカレンダーを横断スキャンし、当日の必須タスクトップ3をレポート 週末プランナー: カレンダーの空き時間をもとに、無料アクティビティ候補をGoogleドキュメントに下書き 節約リサーチ: 近隣ドラッグストアの週次セールやクーポン情報を調べ、スタック可能なプロモーション組み合わせを提案 TechCrunchの実機テストでは、ドラッグストアのセール商品をリストアップしクーポンの重ね使いまで提案するなど、消費者向けユースケースで一定の実力を発揮した。 テストで浮かび上がった2つの課題 プロモーションコードの精度問題 節約リサーチのテストでは、AIが提示したプロモーションコードの一部が実際には無効だった。「利用条件を満たしている」と説明されたにもかかわらずエラーになるケースがあり、生成AIが持つハルシネーション（事実誤認）リスクが実務でどう現れるかを示す典型例となった。別途見つかったBOGO（一つ買えば一つ無料）等の特典でカバーできたとはいえ、精度面での信頼性は今後の課題だ。 Google Keepとの未統合という見落とし 日帰り旅行の持ち物リスト作成テストで、「最終リストをGoogle Keepに取り込んでほしい」とリクエストしたところ、SparkはGoogle Keepを操作できないことが判明した。Googleのエコシステムをフルカバーするはずのエージェントが、自社の人気ノートアプリを操作できないのは明らかな抜け穴だ。 実務への影響——日本のIT現場はどう向き合うか Gemini Sparkが日本の業務環境で活用されるかどうかは、Google Workspaceを中心に使っているかどうかが分水嶺になる。GmailとGoogleカレンダーを日常的に利用する環境であれば、メール要約やスケジュール管理の自動化はすぐに試せる実用的なユースケースだ。 一方、OutlookやTeamsをメインとする多くの日本企業にとって、現時点ではSparkの恩恵は限定的だ。あくまでGoogleエコシステム内での連携に特化しており、他プラットフォームをまたいだ統合は期待できない。 また、クーポン調査のような消費者向けユースケースは面白いが、企業IT部門が即座に活用できるシナリオではない。Google Workspaceの管理者がまず取り組むべきは、承認済みアプリの範囲でSparkをどこまで許可するかのポリシー策定だろう。エージェントAIが業務データにアクセスする範囲のガバナンス設計は、生産性向上と情報セキュリティのバランスを慎重に見極める必要がある。 筆者の見解 Gemini Sparkの設計思想——「クラウドで常時稼働し、ユーザーがPCを閉じていても動き続ける」——は方向性として正しい。ローカルマシンに依存しないエージェントは、エンタープライズ環境でも個人環境でも運用コストが低く、この点でGoogleのアーキテクチャ判断は評価できる。 ただ、今回の検証で気になるのはGoogle Keepへの未対応だ。他社サービスより先に自社エコシステムを完全カバーするのが先決であり、「デジタルライフを全面的にナビゲートする」という打ち出し方と、実際の連携範囲のギャップが目立つ。ポテンシャルはある製品だけに、こうした抜け穴はもったいない。 もう一点、「なぜ通常のGeminiとは別ブランドなのか」という疑問は残る。機能的な差別化が明確でないまま別製品として立ち上げた印象があり、ユーザーが「これがないと困る」と感じる必須ユースケースをもっと具体的に打ち出せれば、評価は大きく変わるだろう。Googleがデータ連携で持つ強みをフルに活かせる設計に育てていけるかどうかが、今後の分岐点になる。 出典: この記事は I put Google’s 24/7 AI assistant Gemini Spark to work, and it’s actually pretty useful の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月にシアトルで開催されたOpen Source Summit North America 2026において、AIエージェントのガバナンスをオープンに標準化するフレームワーク「Open Agent Governance Framework（OAGF）」を発表した。エージェント間通信・ポリシー適用・監査可能性の仕様をオープンソースとして策定し、ベンダーを超えた相互運用性の実現を目指す取り組みだ。 Open Agent Governance Frameworkとは何か OAGFは、複数のAIエージェントが連携して動作する「マルチエージェント」環境における統制基盤を定義するオープン標準だ。主な仕様は3つの柱で構成される。 エージェント間通信（Agent-to-Agent Communication） 異なるベンダーや異なるプラットフォームで動作するエージェント同士が、安全かつ標準的な方法でメッセージをやり取りできるプロトコルを定義する。現状、エージェント間通信はベンダー独自実装が乱立しており、互換性の問題が実運用の大きな障壁となっている。 ポリシー適用（Policy Enforcement） 組織のセキュリティポリシーやコンプライアンス要件を、エージェントの動作に自動的に反映させる仕組みだ。どのエージェントが何のデータにアクセスできるか、どの操作を許可・拒否するかを一元的に制御できる。 監査可能性（Auditability） エージェントがいつ、何を、誰の指示で実行したかを追跡・記録する仕様だ。AI活用が進む組織でコンプライアンス担当者が最も懸念するのが「AIが何をしたかわからない」問題であり、OAGFはここに直接答える形となっている。 Azure Linux 4.0も同時発表 同イベントではAzure Linux 4.0も発表された。MicrosoftがAzureインフラ向けに開発・メンテナンスしているLinuxディストリビューションの最新版で、コンテナホストやエッジ環境での利用を主眼に置く。CBL-Marinerから改称されたAzure Linuxは、Azureの基盤インフラで実際に使われている実績から、信頼性・セキュリティ・パフォーマンスのバランスに優れた選択肢として評価されている。 なぜこれが重要か——AIエージェントの「野良化」問題 AIエージェントの企業導入が加速する中、最大の課題のひとつが「誰がエージェントを管理するか」という問題だ。部門ごとに異なるエージェントを導入し、それぞれが独自のアクセス権限を持つ状況が生まれれば、従来のITガバナンスは機能しなくなる。 OAGFのようなオープン標準が普及すれば、組織のIT部門は一元的なポリシー管理のもとで複数のエージェントを安全に運用できるようになる。これはゼロトラストの文脈でも重要で、エージェントのアイデンティティ（NHI: Non-Human Identity）管理と組み合わせることで、人間ユーザーと同等のアクセス制御を自動化エージェントにも適用できる。 実務への影響——日本のエンジニア・IT管理者へ NHI管理の設計を今すぐ始める エージェントを導入する前に、そのエージェントのアイデンティティをどう管理するかを設計することが不可欠だ。Microsoft Entra IDを使ったサービスプリンシパルやマネージドIDの仕組みを活用し、エージェントごとに最小権限を割り当てる「Just-In-Time（JIT）アクセス」の設計を早い段階から組み込むべきだ。 監査ログの設計を後回しにしない 「とりあえず動けばいい」でエージェントを本番導入すると、後からガバナンス要件を満たすための改修コストが跳ね上がる。OAGFの監査可能性仕様を参考に、ログの設計は実装と並行して進めよう。 ベンダー標準よりオープン標準を優先する 複数のエージェントを組み合わせる環境では、特定ベンダーのプロプライエタリな通信方式に依存するとロックインリスクが高まる。OAGFのようなオープン標準への対応状況を、エージェント製品選定の評価軸に加えることを推奨する。 筆者の見解 MicrosoftがAIエージェントのガバナンスをオープン標準として推進するこの動きは、長期的に見て正しい方向だと思う。 AIエージェントの時代において、最も賢いモデルを作る競争とは別軸で、最も多くのエージェントが安全に動作するプラットフォームを提供する競争がある。Microsoft Entra IDとAzureという実績あるインフラを持つMicrosoftは、後者の競争で有利な立場にある。OAGFはその強みをさらに活かせる方向への投資だ。 特にNHI管理の標準化は、エンタープライズの自動化推進において本質的なボトルネック解消につながる可能性がある。エージェントのガバナンスが整備されないうちは、IT部門がエージェント導入にブレーキをかけるのは合理的な判断であり、OAGFはそのブレーキを安全に外すための鍵となり得る。 ひとつ注目したいのは、この標準がどこまで「本当にオープン」になれるかだ。Microsoftが主導して策定した標準が業界標準として定着するには、競合他社を含む幅広いエコシステムの参加が欠かせない。「道のド真ん中を歩く」選択肢として多くの組織が採用できる標準になるかどうか、コミュニティの広がりを今後も注視したい。 出典: この記事は From open source to agentic systems: Microsoft at Open Source Summit North America 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft 365 E5およびE7ライセンスに対して、これまで別途購入が必要だったIntune Suiteの主要機能を段階的に統合すると発表した。2026年8月1日までに全機能のロールアウトを完了予定で、エンタープライズのデバイス管理・特権管理の体制が大きく変わる可能性がある。 何が変わるのか これまでIntune Suiteは、Microsoft Intuneの標準ライセンスに加えてユーザーあたり月額約10ドルの追加費用が必要なアドオンだった。今回の統合により、Microsoft 365 E5/E7を保有する組織は以下の機能を追加コストなしで利用できるようになる。 統合される主要機能 Remote Help ヘルプデスク担当者が安全にエンドユーザーのデバイスをリモート操作できるツール。ロールベースのアクセス制御（RBAC）に対応しており、「誰が」「誰のデバイスを」操作できるかを厳密に制限できる。従来のRDPベースのリモートサポートと異なり、Entra IDの認証基盤に乗った管理が可能だ。 Advanced Analytics AIを活用したデバイスの健全性分析機能。異常な動作パターンの検知や、ソフトウェアの互換性問題の事前把握など、従来のエンドポイント管理では見えにくかったインサイトをダッシュボードで提供する。Windowsアップデート展開前のリスク評価にも活用できる。 Cloud PKI オンプレミスの証明機関（CA）サーバーを不要にするクラウドネイティブな証明書管理基盤。デバイス証明書やユーザー証明書の発行・失効・管理をIntune管理コンソール内で完結させられる。Wi-Fi認証やVPN、SCEPプロファイルとの統合が前提設計になっている。 Endpoint Privilege Management（EPM） Windowsのローカル管理者権限を持たない標準ユーザーに対して、特定のアプリケーション実行時だけ一時的に昇格権限を付与するジャストインタイム（JIT）特権管理機能。「常時管理者」という最も危険な運用形態を排除するための機能として位置づけられている。 Microsoft Tunnel for MAM デバイス全体をIntuneに登録することなく、特定のマネージドアプリからだけ社内リソースへのVPNアクセスを実現する機能。BYODデバイスや業務委託先のPCへの対応として有効だ。 段階的ロールアウトのスケジュール Microsoftは「2026年8月1日までに全機能を段階的にロールアウト」としており、機能ごとに提供開始時期が異なる。既存のE5/E7テナント管理者はMicrosoft 365管理センターやIntune管理センターで各機能の提供状況を随時確認することを推奨する。なお、既存のIntune Suite単体ライセンスを購入済みの場合、移行・価格の取り扱いについては担当のMicrosoft営業またはCSPパートナーへの確認が必要だ。 実務への影響 ライセンスコストの見直しが急務 現在Intune Suite（アドオン）を別途契約しているE5/E7組織は、契約更新のタイミングで重複コストが発生しないよう今すぐ契約条件を確認したい。大規模組織では年間コストに数百万円規模の差が出る可能性がある。 Cloud PKIはオンプレミスCA廃止の好機 多くの日本企業では、Active Directory証明書サービス（AD CS）を運用しているケースが今でも多い。Cloud PKIへの移行は一定の作業コストを伴うが、オンプレミスCAサーバーの維持・更新コストや、証明書失効管理の自動化メリットは大きい。2026年中に移行検討を始めるプロジェクトを立ち上げる価値がある。 EPMは「標準ユーザー化」の最後の砦 セキュリティポリシー上「ローカル管理者権限を全廃したい」と思いながらも、業務上必要なソフトウェアのインストールや設定変更のためにやむなく管理者権限を与え続けているケースが多い。EPMはこのジレンマを解消する。展開にはポリシー設計と業務部門との調整が必要だが、セキュリティ成熟度を一段引き上げる施策として今回の統合は大きな後押しになる。 Remote HelpでRDP依存の脱却を 社内ヘルプデスクが今もRDP+VPNでサポートしている組織は、Remote Helpへの移行を検討する価値がある。RBACによる操作権限の分離と、監査ログの自動記録はコンプライアンス要件への対応にも直結する。 筆者の見解 Intune Suiteの統合は、Microsoftが長年推進してきた「統合プラットフォームによる全体最適」という戦略の正しい具現化だと思う。特権管理（EPM）とCloud PKIがE5/E7の標準機能になるのは、ゼロトラスト推進の観点からは歓迎すべき動きだ。「常時管理者権限の付与はゼロトラストの最大の穴」とずっと言い続けてきたが、EPMがコスト障壁なく使えるようになれば、導入に踏み切れる組織は確実に増える。 Cloud PKIも同様で、「オンプレCA廃止は難しい」と言い続けている組織の言い訳がひとつ減る。インフラの複雑さを減らしてクラウドに寄せるのは、運用コストだけでなくセキュリティリスクの低減にも直結する。 一方で、Advanced AnalyticsについてはCopilot系の分析機能との棲み分けがまだ不明確な印象もある。「AIが何かを検知した」というインサイトが、実際に現場のIT担当者にとって使いやすいワークフローに落ちるかどうか——機能の追加より、運用への定着設計の方が難易度は高いと思っている。 Microsoftが持つ統合基盤の強みは、こういうタイミングに改めてよくわかる。バラバラのポイントソリューションを寄せ集めるのではなく、Entra ID・Intune・Defenderが連携した一枚岩の管理基盤として価値を出せるポテンシャルは本物だ。その方向性でぜひ走り続けてほしい。 出典: この記事は Microsoft 365 adds advanced Microsoft Intune solutions at scale の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

NotebookcheckのシニアテックライターPolly Allcock氏が2026年4月20日に報じたところによると、Huaweiが超薄型スマートウォッチ「Watch Fit 5」および「Watch Fit 5 Pro」を中国で正式発表し、4月29日より販売を開始した。欧州向けの発売日はまだ公表されていないが、業界内の非公式情報では標準モデルが€199、Proモデルが€299になると見られている。 なぜこの製品が注目か Watch Fit 5シリーズが注目を集める理由は、薄型・軽量フォルムとハイエンド機能の両立にある。標準モデルの厚さはわずか9.5mm。Apple Watch Series 11が9.7mmであることを考えると、この数字は素直に評価できる。重量も27.0gに抑えられており、長時間装着時の負担が少ない設計だ。 また、今シリーズから新たに加わったマイクロムーブメントストレッチ機能も特徴的だ。首・背中・肩など10部位に対して30種類のストレッチ動作をガイドするもので、デスクワーカーのフィジカルケアを意識した機能追加といえる。 スペック比較 項目 Watch Fit 5 Watch Fit 5 Pro ディスプレイ 1.82インチ AMOLED / 2,500nit 1.92インチ AMOLED / 3,000nit 厚さ 9.5mm 非公表 重量 27.0g 30.4g ケース素材 アルミニウム合金 チタン合金ベゼル ガラス — サファイアガラス ECG なし あり 防水深度 非公表 40m（ダイビング対応） バッテリー 約7日間 約7日間 中国価格 CNY 1,099〜1,199（約2.3〜2.5万円相当） CNY 2,099〜2,199（約4.4〜4.6万円相当） 欧州噂価格 €199 €299 海外レビューのポイント Notebookcheckの報告は製品ローンチ情報の紹介にとどまり、実機レビューではないため、製品発表内容をもとに整理する。 注目できる点 心拍センサーが前世代より精度向上とHuawei自身が謳っており、スポーツ・日常のヘルストラッキング双方での信頼性向上が期待される Proモデルは40m防水＋ダイビングアクティビティ対応で、アウトドア・ウォータースポーツユーザーへの訴求力が増した 100以上のスポーツモード、GPS、SpO2、睡眠トラッキング、マイク・スピーカー内蔵と機能的には非常に充実している 前世代のWatch Fit 4は欧州で当初€169での提供だったことを踏まえると、Proモデル€299はサファイアガラスとチタンベゼルを考慮しても割安感がある 気になる点 ...

MicrosoftのGitHub Copilotが2026年6月1日より課金体系を定額制からトークン使用量ベースの従量課金制へ移行し、RedditやX（旧Twitter）で開発者の間に「What a joke（冗談じゃない）」という声が広がっている。 何が変わったのか——定額制からトークン課金制へ これまでGitHub Copilotは月額定額制で提供されており、開発者はコストを気にせずAIとのやり取りを重ねることができた。しかし6月1日付けの新プランでは、消費したトークン量に応じて料金が発生する従量課金制へと移行した。 トークン課金制とは、AIとのやり取り（入力・出力のテキスト量）を「トークン」という単位で計測し、その消費量に比例して課金する仕組みだ。シンプルなコード補完では影響は小さいが、長時間稼働させるエージェントタスクや、複数のサブエージェントが連携して動く複雑な処理では、コストが一気に膨らむ可能性がある。 「冗談だろ」——開発者コミュニティの反応 課金モデルの変更を受け、開発者コミュニティから悲鳴に近い声が上がっている。 あるRedditユーザーは、現在の月額29ドルが新レートでは約750ドルに跳ね上がると主張し、「この新しい使用量モデルは馬鹿げた値段だ。この費用では実用的でも費用対効果があるわけでもない。キャンセルして調整する」と投稿した。 別のユーザーは月額50ドルから約3,000ドルへの急騰を示すスクリーンショットを添えて「新しい料金モデルがこんなに常軌を逸したものになるとは思っていなかった」と発信した。 擁護派の反論——「ヴァイブコーダー問題」 一方で、批判に反論する声も存在する。擁護派の開発者たちが指摘するのは「ヴァイブコーディング」問題だ。 ヴァイブコーディングとは、コードの詳細を理解せず、AIに任せきりで大量のトークンを消費しながら試行錯誤を繰り返すスタイルを指す。擁護派は「一日中作業しても超過分がほとんど出ない開発者もいる。コストが膨らむのは、純粋に膨大なイテレーションでヴァイブコーディングをしているからだ」と主張する。 つまり、AIを適切な道具として使う開発者には、新課金体系は必ずしも壊滅的ではないという見方だ。問題は使い方の習熟度にある、という論点である。 「使えと言ったのはMicrosoftでは？」——最も鋭い批判 しかし最も根本的な批判は別の角度から来ている。「Microsoftがユーザーに積極的な使用を促しておきながら、課金体系を変えて梯子を外した」というものだ。 あるユーザーはこう指摘する。「Microsoftがこの課金方式を提供し、何時間も、場合によっては何日もかけて大量のサブエージェントを生成するプレミアムリクエストをどんどん実行しやすくし続けてきた。その使い方でシステムを使ったユーザーを責めるのはおかしい。責任があるとすれば、それはMicrosoftだけだ」 加えて、以前の定額モデルでMicrosoftがどれほどの損失を出していたかも話題になった。「Copilotはどれほどの赤字だったんだ」というコメントが多くの共感を呼んでいる。 Microsoftにはコメントを求めたが、執筆時点で回答はなかった。 実務への影響——日本の開発者・IT管理者が取るべき対応 コスト予測の仕組みを整える: トークン課金制では月額コストが使い方によって大きく変動する。チームでCopilotを活用している場合、上限設定や使用量モニタリングの仕組みを早急に整える必要がある。 エージェント利用は特に注意: 長時間稼働するエージェントタスクや、複数のサブエージェントが連携して動く処理はトークン消費量が桁違いに大きい。エージェントモードの活用を検討しているチームは、事前にコストシミュレーションを行うことを強く推奨する。 「適切な使い方」の社内定義が急務: 今回の問題の一因は「適切な使い方の共有不足」にある。AIコーディング支援ツールを組織として使いこなすためには、効果的な活用パターンと非効率なパターンを明文化し、チームで共有することが重要だ。 筆者の見解 今回のGitHub Copilotの課金体系変更は、単純な値上げの話ではない。「AIをどう使わせるか」というMicrosoftの設計哲学そのものへの問い直しを迫る出来事だ。 もったいないと感じるのは、Copilotが技術的な進化の方向性——エージェント機能の拡充、サブエージェントの生成、自律的なタスク実行——という意味では、確実に正しい道を歩んでいるからだ。AIが本来提供すべき価値、すなわち人間の認知負荷を削減して仕事を自律的に推進する能力に、少しずつ近づいてはいる。 しかし、「使えば使うほどコストが読めなくなる」料金設計は、そのポテンシャルを自ら封じてしまう。これまでMicrosoftは「もっと使え」とユーザーに言い続けてきた。その言葉に素直に従い、エージェントモードをフル活用したユーザーに高額請求が届くのであれば、失望するのは当然だ。 MicrosoftにはCopilotを真に使い物になるツールへと育てる力がある、というのが筆者の長年の認識だ。課金体系の整備と合わせ、「積極的に使っても怖くない」という安心感をユーザーに取り戻す設計を期待したい。Copilotが「使われることを恐れるAI」ではなく「使い倒されることで価値を発揮するAI」として再評価される日が来ることを願っている。 出典: この記事は ‘What a joke’: Github Copilot’s new token-based billing spurs consternation among devs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Unixの世界で30年以上使われてきたファイル同期ツール「rsync」のバージョン3.4.3において、Anthropicの生成AI「Claude」が関与したコミットが数百件に上ることが明らかになり、オープンソースコミュニティで大きな話題となっている。 rsyncとは何か、なぜこれが重大なのか rsync（Remote Sync）は、LinuxやmacOSをはじめとするUnix系OSで広く使われているファイル同期・転送ツールだ。バックアップ、デプロイ、サーバー間のファイルコピーなど、インフラ運用の現場では今なお欠かせない存在であり、世界中のサーバーで動き続けている。 新機能追加が目立つフロントエンドフレームワークとは異なり、rsyncのような「枯れたツール」への変更は一行一行が慎重に吟味される。そのような成熟したOSSプロジェクトのコミット履歴に、AIが数百件規模で名を連ねているという事実は、単なるトリビアではない。 コミット数百件が意味するもの 「数百件のClaudeコミット」が何を示すのかは、現時点で詳細な内訳の確認が必要だが、いくつかの可能性が考えられる。 コード生成・リファクタリング支援: AIにパッチの草案を書かせ、メンテナーがレビュー・承認するワークフローが採用されている可能性が高い。これはClaude Codeのような対話型AIエージェントの典型的な使い方だ。 テストコードや型注釈の自動生成: 人間が書くと時間のかかる網羅的なテストケースや、レガシーコードへの型定義追加をAIが担当するケースが増えている。 バグ修正・セキュリティパッチ: 特定のパターンに従うバグ修正はAIが得意とする領域だ。コンテキストを与えれば、人間が書いたものと区別がつかないレベルのパッチを生成できる。 重要なのは、これらすべてが「メンテナーのレビューと承認を経た上でマージされている」という点だ。AIが自動でコミットしているのではなく、人間がAIを道具として使いながら開発を進めている。 OSSメンテナンスの持続可能性問題と生成AI オープンソースの世界には長年、「少数のメンテナーが膨大な作業を無償で担い続ける」という持続可能性の問題がある。rsyncのような基盤的ツールでも、コアコミッターは数人という現実がある。 生成AIの登場は、この構造的問題を部分的に解決しうる。ドキュメントの更新、定型的なバグ修正、テストの補完、コードのリファクタリング——これらを人間のメンテナーが逐一書かなくてよくなれば、限られたリソースをより本質的な設計判断に集中できる。 実際、GitHub Copilotの普及やClaude Code・Cursor等のAIコーディング環境の台頭により、個人開発者・企業を問わず「AIと並走してコードを書く」スタイルが標準になりつつある。rsyncのケースはその延長線上にある出来事だ。 実務への影響 — 日本のエンジニア・IT管理者へ 「AI生成コードを信頼してよいか」という問いへの答え: AIが生成し、熟練したメンテナーがレビューしたコードは、人間だけが書いたコードと本質的に異なるわけではない。rsyncという実績あるプロジェクトへの大規模な貢献が、この事実を示している。 コードレビュー文化の重要性: AI活用の前提は「生成したコードを人間が責任を持ってレビューする」ことだ。AIに書かせて無審査でマージするのではなく、AIを高速なドラフト生成ツールとして使い、判断は人間が担うという分業が機能している。 社内ツール・スクリプトのメンテナンスへの応用: rsync規模のプロジェクトでなくとも、社内スクリプトや自社サービスの長期メンテナンスにAIを組み込む発想はすぐに実践できる。コードの意図を説明してAIにパッチを書かせ、自分でレビューするというワークフローは今日から始められる。 コミットメッセージやログへの記録: AIが関与したことを明示的にコミットメッセージ等に記録する慣習が広まりつつある。プロジェクトのトレーサビリティの観点から、チームとして方針を決めておくことが望ましい。 筆者の見解 rsyncのような枯れたツールでこれだけの規模のAI活用が進んでいるという事実は、興味深い示唆を与えてくれる。「AIコーディングは新しいプロジェクトや先端的なフレームワークにしか使えない」という思い込みは、もはや通用しない。 ここで注目したいのは、このアプローチが「確認・承認の仕組みを保ちながら自動化を進めている」点だ。AIが自律的にコミットするのではなく、人間のメンテナーがゲートキーパーとして機能しながらAIの生産性を活用している。これはAIエージェント活用の設計としてひとつの成熟したモデルを示している。 一方で、この流れに対してオープンソースコミュニティが複雑な感情を持つのも理解できる。「コミットの著者は誰か」「AIが生成したコードのライセンスはどう扱うか」「脆弱性混入のリスクはどう評価するか」——これらの問いに対する業界共通の答えはまだない。 AIによるOSS貢献が「数百件」という規模で現実のものとなった今、コミュニティとしてこうした問いに向き合う時期が来ている。rsyncのケースが、その議論を前進させる契機になれば意義深い。 出典: この記事は Rsync 3.4.3 has hundreds of Claude commits の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIの急速な普及を背景に、テックワーカーたちの間で「AI Job Grief（AIによる職の悲嘆）」と呼ぶべき新たな心理的危機が広がっている。まだ職を失っていないエンジニアやデータサイエンティストたちが、すでに喪失感と悲嘆を抱えているという実態が、Redditのコミュニティや学術研究から浮かび上がっている。 知識労働者にとって「仕事」はアイデンティティである 製造業の工場労働者にとって仕事とは「行う活動」だが、知識労働者——特にエンジニアやデータサイエンティスト——にとって専門的な知識や判断力は「自分自身の一部」として機能している。10年かけて培った統計的判断力、コードのアーキテクチャ設計の勘、データから洞察を引き出す能力。これらはスキルセットである以前に、「自分が何者か」を構成するものだ。 生成AIの台頭はその根幹に触れる。単に仕事を奪うのではなく、「自分の価値とは何か」という問いを突きつける。 2025年に『International Journal of Qualitative Studies on Health and Well-being』に掲載された質的研究によれば、AI起因の雇用置換を経験した参加者は「専門的アイデンティティ、自律性、将来展望の象徴的な喪失」を経験していたという。研究者たちは、害の本質が経済的なものではなく、「キャリアの中断」を超えた「個人的アイデンティティの侵食」にあると明確に指摘している。 まだ職を失っていないのに悲嘆する——「予期的悲嘆」という現象 r/datascienceに投稿されたある書き込みは象徴的だ。「5年間データサイエンスに携わってきたが、私たちが届ける『インサイト』のほとんどが完全に無視されていることに気づき始めた」。彼はまだ職を失っていない。にもかかわらず、意味の喪失を悲しんでいる。 これは「予期的悲嘆（Anticipatory Grief）」と呼ばれる心理状態だ。末期疾患の患者家族が死別前から悲嘆を経験するように、テックワーカーたちは雇用喪失が現実になる前から、その喪失感を経験している。 より問題なのは、この悲嘆が「社会的に抑圧される構造」にあることだ。 悲嘆が許されない——構造的抑圧のメカニズム 2025年夏のEpic Gamesのレイオフでは、末期疾患を抱える父親が解雇され、職とともに生命保険も失った。Redditのスレッドは36,687アップボートという驚異的な反響を集めたが、コメント欄に共通していたのは「何か大切なものが失われた」という感覚であり、それを表す言葉がないという困惑だった。 レイオフは「通常のビジネス判断」として処理される。その枠組みには、悲しむための社会的・制度的余地がない。人事部門には対応ポリシーがなく、臨床的なフレームワークも確立していない。悲嘆は個人の問題として処理され、集団的な喪失として認識されない。 これが問題をより深刻にする。喪失を喪失として認識できないとき、回復のプロセスも始まらない。 データサイエンティストの二極化が示す未来 記事が指摘する「ジェネラリスト型データサイエンティストの二極化」は特に注目に値する。機械学習エンジニア側から上を攻められ、AIツールによる自動化で下を攻められ、中間的な役割が消えつつある。 「ダッシュボードが作られ、指標が追跡され、デックが共有される。しかしほとんど何も変わらない」というr/analyticsの投稿は、既存の仕事の「意味」が問われる時代の到来を示している。 実務への影響——日本のIT現場で今すぐ考えるべきこと マネージャー・HR担当者へ： AI導入に伴う心理的影響は「甘え」ではなく、研究で実証された実態だ。1on1やチームミーティングで「AIによる役割変化への不安」を話せる場を意図的に作ることが必要になる。 個人エンジニアへ： 自分のアイデンティティを「特定のスキルセット」に依拠させない思考の転換が急務だ。「Pythonが書ける」よりも「問題を定義し、AIを使って解く設計ができる」というメタ能力への投資が、心理的安定の土台にもなる。 組織全体として： 「AIを導入するか否か」の議論より先に、「AIで役割が変わる人たちをどう支援するか」の設計が必要だ。技術的な移行計画と並行して、心理的サポートの枠組みを作ることが、組織の健全性を維持する鍵になる。 筆者の見解 この記事が描く「AI Job Grief」という現象は、単なる個人の心理問題として片付けるには大きすぎるテーマだと感じる。 AIによる技術的変革は今後さらに加速する。この変化を直視することは必要だし、「AIをどれだけ活用できるか」が個人の生産性と企業競争力を左右する時代はすでに来ている。その意味で、AIを積極活用する流れ自体は正しい方向だ。 しかし問題は、日本のIT現場の多くがこの変化の本質的な深さをまだ掴めていない点にある。「ツールとして便利に使う」段階の話ではなく、知識労働の構造そのものが変わるという認識が、組織レベルでは圧倒的に不足している。 「AIを使え」という圧力だけをかけて、役割が変わる人たちへの支援を設計しない組織は、短期的な生産性向上と引き換えに、長期的な組織の健全性を損なうことになる。変化を急ぎながら、変化の痛みを直視することを怠ることはできない。 新人の一括採用を続け、既存の職務定義に人を当てはめ続けるやり方は、AIが当たり前になった時代にはもう通用しない。「仕組みを作れる人」が少数必要で、あとはAIが回す——そういう組織設計への移行を、心理的サポートも含めて丁寧に設計することが、これからの人事と経営の本質的な仕事になるのではないかと思う。 技術の変化は止まらない。だからこそ、変化の渦中にいる人間をどう支えるかという問いを、後回しにしてはならない。 出典: この記事は AI Job Grief: The Unnamed Psychological Crisis Hitting Tech Workers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが、Claude.ai・Claude Code・Claude Coworkの各製品において実装しているサンドボックス（隔離）技術の詳細を公式ドキュメントとして公開した。AIエージェントが「どこまで何ができるか」の境界線をどう引いているか、技術的な根拠と実装が初めて体系的に示された形だ。 なぜAIエージェントにサンドボックスが必要か AIエージェントは指示に従ってファイルを読み書きし、コマンドを実行し、外部APIを呼び出す。その自律性こそが価値だが、裏返せばリスクでもある。攻撃者がプロンプトインジェクションで意図しない操作を誘導したり、モデル自身が「創造的な抜け道」を発見して想定外の行動を取ったりするリスクが常に存在する。 Anthropicはこの問題に対し、「サンドボックスを正しく設計すれば、認証情報がそもそも内部に存在しないため、たとえモデルが問題ある行動を取っても外部への流出は起きない」という設計思想で対応している。問題行動を検知・阻止するのではなく、そもそも「やれること」の上限を構造的に制約するアプローチだ。 製品別のサンドボックス実装 Claude.ai（Webサービス） クラウド環境で動くClaude.aiには gVisor を採用している。gVisorはGoogleが開発したコンテナセキュリティレイヤーで、カーネルシステムコールをユーザー空間でインターセプトすることでホストOSカーネルへの直接アクセスを遮断する。通常のDockerコンテナより一段上の分離レベルを持ち、マルチテナントのクラウドサービスに適した選択だ。 Claude Code（ローカル実行） 開発者のPCで動くClaude Codeには、OSに応じて異なるサンドボックスを使用する。 macOS: Apple標準の Seatbelt（sandbox-exec）でプロセスのファイルシステムアクセスやネットワーク通信を制限 Linux: Bubblewrap でnamespaceを使ったプロセス分離を実現 ローカルツールという性質上「完全なロックダウンは難しい」ながらも、デフォルトで危険な操作を制限する仕組みが実装されている。ユーザーの作業フォルダ外への書き込みや外部への無制限な通信は、明示的に許可しない限りブロックされる設計だ。 Claude Cowork（高度な自律エージェント） 最も強力な隔離が必要なCoworkには フルVMを採用している。 macOS: Appleの仮想化フレームワーク（Virtualization.framework） Windows: HCS（Host Compute Service） コード実行・ファイル操作・ブラウザ操作などを広範にこなすエージェントに対しては、プロセス分離では不十分として完全な仮想マシンで囲い込む設計だ。自律性が高い分だけ、隔離も厚くするという判断は理にかなっている。 「見落としていたリスク」も公開 今回のドキュメントには失敗事例も含まれており、特に注目すべきは api.anthropic.com/v1/files を経由したファイル流出ベクターだ。2026年1月に発覚した実際のインシデントで、Anthropic自身のAPIエンドポイントがサンドボックス内から誤ってアクセス可能な状態になっており、これを悪用してファイルが外部に流出できる状態だった。 このような失敗事例を隠さずドキュメントに含めた点は、セキュリティコミュニティの慣習（責任ある情報開示）に沿ったものであり、同様の製品を持つ他社と比較しても異例の透明性と言える。 オープンソースツール「srt」にも注目 Anthropicは srt（Anthropic Sandbox Runtime） をOSSとして公開しており、GitHubで入手できる。自社プロダクトにAIエージェントを組み込む際の参考実装として使える成熟度に達してきたとの評価もある。サービス内にセキュアなエージェント実行環境を内製したい開発チームにとっては、有力な出発点になりうる。 日本のエンジニア・IT管理者への実務ポイント エージェント開発者・アーキテクト向け 「認証情報をサンドボックスに入れない」という設計原則はシンプルかつ強力。自社LLMエージェントのセキュリティ設計の基本方針として採用できる クラウド側ではgVisorやFirecrackerのような強化コンテナ技術の選択肢を比較検討する ローカルツールを社内配布する場合は、Seatbelt/Bubblewrapに相当する制限をデフォルトで有効にする設計を検討する Anthropicのsrtを自社エージェント実行環境のベースとして採用するオプションが現実的になってきた セキュリティ担当者向け AIエージェントを評価・選定する際の具体的な技術確認項目（何のサンドボックスを使っているか）として活用できる 「AIエージェントの何ができて何ができないか」をドキュメントで説明できるベンダーを優先的に評価する姿勢を社内で持つ 筆者の見解 AIエージェントのセキュリティは「使わせるか禁止するか」の二択ではなく、「どう安全に動かすか」の設計問題だ。今回のドキュメントはその問いに対する一つの実践的な回答であり、エージェントセキュリティの議論をようやく具体的な技術レベルで行える土台を作ってくれた。 「認証情報をサンドボックスに入れない」というアプローチは、AIによる意図しない誤操作と外部攻撃者によるプロンプトインジェクションの両方を、同一のアーキテクチャで同時に対処できる考え方だ。この発想自体はどのAIエージェントプラットフォームにも応用できる普遍的な設計原則として参考になる。 もう一点、ドキュメントの透明性に触れておきたい。多くのベンダーがサンドボックスの実装詳細を「セキュリティ上の理由」で非公開にする中、失敗事例を含む技術詳細を公開するこの姿勢は業界全体の議論を前進させる。エンタープライズ採用を検討する企業のセキュリティ部門にとって、「何を根拠にこのツールを信頼するか」の具体的な説明材料になるという点で、実際の採用判断に与える影響は小さくないと見ている。 AIエージェントの自律性と安全性はトレードオフではなく、設計次第で両立できる——このドキュメントはその証左として、社内でAI活用の安全性議論をしている方々にぜひ見せてほしい内容だ。 出典: この記事は How we contain Claude across products の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ソフトバンクグループが2026年5月、フランスのデータセンター整備に最大75億ユーロ（約12兆円）を投じる計画を発表した。同社にとって欧州最大規模のAIインフラ投資となり、最終的に5ギガワット（GW）の追加データセンター容量を確保することを目指す。 何を、どこに、どのように建設するのか 第1フェーズとして、フランス北部「オー＝ド＝フランス地域圏」のダンケルク（ロン＝プラージュ）、ボスケル、ブーシャンの3拠点にデータセンターを建設し、2031年までに合計3.1GWの容量を整備する計画だ。最終目標の5GWはその後の拡張フェーズで達成する見込みで、投資総額は最大75億ユーロに上る。 ソフトバンクはOpenAIの主要投資家であり顧客でもある。今回の投資は、AI推論・学習に必要な大規模コンピューティングリソースを欧州で確保する戦略的な動きと見てよい。 フランス政府の戦略と重なる フランスのロラン・レスキュール経済相は、この発表を「フランスをAIバリューチェーン全体でリーディング・デスティネーションとして位置づけるマクロン大統領のアンビションの証明」と表現した。 フランスはここ数年、デジタル主権とAIインフラ誘致に積極的な国家戦略を進めており、今回のソフトバンク案件はその成果の一つと言える。欧州連合（EU）は米系クラウドベンダーへの依存を懸念する声が強く、日本企業による大型投資は政治的にも歓迎されやすい環境にある。 米国とは対照的な状況 対照的に、米国ではデータセンター建設に対する反対運動が高まっている。電力網への影響、電気料金の上昇、環境負荷などを懸念する住民・自治体の声が大きくなっており、立地選定が難しくなりつつある。 ソフトバンクはオハイオ州でもデータセンター建設を計画しているが、こちらは新設する9.2GWの天然ガス発電所と組み合わせる計画で、環境団体からの批判を招いている。フランス案件と比べると、エネルギー源の違いが今後の論点になるかもしれない。 実務への影響——日本のエンジニア・IT管理者の視点 クラウドリージョンの選択肢が増える：ソフトバンクが運営するデータセンターが欧州で5GW規模になれば、将来的にEU圏のデータ主権要件を満たすクラウドサービスの新たな選択肢が生まれる可能性がある。GDPR準拠や欧州向けデータ残置要件を持つシステムを設計する際の検討候補に入ってくる。 AIインフラコストへの中長期的影響：現在、AI推論・学習のコストはコンピューティングリソースの逼迫によって高止まりしている。ソフトバンク規模の大型投資が欧州で複数進めば、中長期的な供給増加を通じてAPIコストやクラウドGPUコストの緩和につながる可能性がある。 OpenAIサービスの冗長性強化：ソフトバンクはOpenAIと密接な関係にあり、今回のインフラがOpenAIのサービス基盤として活用される可能性は高い。OpenAIのAPIを業務システムに組み込んでいる企業にとって、欧州拠点の強化は可用性・レイテンシの観点で朗報となりうる。 筆者の見解 AIエージェントや大規模推論が「使うもの」から「常時動き続けるインフラ」へと変わりつつある今、データセンターの物理的な供給量がサービス品質と価格を直接決める時代に入っている。ソフトバンクの今回の決断は、その流れを正確に読んだ上での動きだ。 面白いのは、日本企業であるソフトバンクが欧州のAIインフラを握ろうとしている構図だ。日本国内のAI基盤整備が世界と比べて出遅れている中で、同じ日本企業が欧州では12兆円規模の投資を行う——この非対称さは日本のIT業界が直視すべき現実を突きつけている。 また、5GW・12兆円という数字は、もはやAIが「実験的な技術」ではなく「電力・通信に並ぶ社会インフラ」として扱われていることを如実に示す。2031年という完成時期に向けて、AIエージェントが自律的にループを回し続ける世界の規模感がどこまで広がるか、インフラの整備速度が鍵を握ることになる。 投資額の大きさに驚くよりも、「この規模のコンピューティングリソースが実際に動き始めたとき、自分たちのシステムやビジネスはそれをどう使い倒すか」を今から考えておくことの方が、エンジニアにとって本質的な問いかけだと思う。 出典: この記事は SoftBank says it will invest up to €75 billion to build French data centers の内容をもとに、筆者の見解を加えて独自に執筆したものです。