Tech-News

Windows 11へ意図せず配信された「OneDrive Photos」に対し、MicrosoftがIT管理者の反発を受けて対応を進めている。Microsoft 365ロードマップには関連する項目が2件登録されており、管理者向けの制御が2026年8月、アプリ単体のアンインストールが2026年9月という順で提供される予定だ。どちらも2026年8月7日に登録され、記事執筆時点のステータスは「開発中（In development）」となっている。 何が起きているか OneDrive PhotosはWebView2をベースにしたAIフォトビューアで、ローカルとOneDrive上の写真をまとめて扱い、検索やアルバム、「Moments」によるグループ化といった機能を持つ。問題は機能そのものではなく、配信のされ方だった。 このアプリはMicrosoft Storeからの任意インストールではなく、既にインストール済みのOneDrive同期クライアントを経由して配信された。2026年8月1日以降に広く展開され、コンシューマー機だけでなく、Intuneで管理されている法人端末やWindows 11 Enterpriseにも到達した。管理者からは「Intuneで数百台を管理しているが、全台のスタートメニューに OneDrive Photos が並んだ」といった声が上がっている。 管理者にとって厄介だったのは、次の3点が重なったことだ。 単体で削除できない。Storeの項目もAppXパッケージも独立したインストーラーも無く、消そうとするとOneDrive本体ごとアンインストールすることになる。当然、ファイル同期もエクスプローラー統合も失われる 法人アカウントでは使えない。OneDrive Photosは個人用Microsoftアカウント向けで、職場・学校アカウントでサインインしている端末では機能しない。つまり業務端末では役に立たないアプリだけが増える 消しても復活する。WindowsやOneDriveの更新後に再び現れるため、構成を当て直す作業が繰り返し発生する Microsoftはこの広範な配信が意図的なものではなかったと認め、「OneDriveの新しい写真体験をインキュベート中で、それがWindowsにおいて意図した範囲より広く出てしまった」とコメントしている。 ロードマップは2件ある。8月と9月で中身が違う ここが実務上いちばん重要な点だ。「アンインストールできるようになる」という話として報じられているが、Microsoft 365ロードマップを引くと、登録されている項目は次の2件に分かれている。 ID 内容 提供時期 568931 OneDrive: Manage access to the OneDrive Photos Desktop experience 2026年8月 568934 OneDrive: Uninstall OneDrive Photos without affecting file sync 2026年9月 先に来る568931は「アンインストール」ではない。説明文にあるのは「Windows上のPhotos体験に対する管理者向けコントロールを追加し、組織はユーザーが個人用Microsoftアカウントでサインインするかどうかを管理できる」という内容で、アクセスとデータガバナンスを揃えるための制御だ。アプリそのものは端末に残る。 実際にアプリを消せるようになるのは翌月の568934で、こちらは「Photos体験を削除してもOneDriveアプリはアンインストールされず、ファイル同期は中断されず、写真やファイルも削除されない」と明記されている。現状の「消すならOneDriveごと」という制約が解けるのは、この項目が来てからということになる。 いずれも対象は Worldwide（Standard Multi-Tenant）のデスクトップで、リリースフェーズは一般提供（GA）。プレビュー期間の記載は無い。 実務への影響 日本企業の情シス視点で、いま決めておくべきことは3つある。 1つ目は、8月に何を期待するかを揃えること。 「8月の更新でアプリが消せる」と社内に説明してしまうと、実際に届く機能とずれる。8月に手に入るのは個人アカウントでのサインインを止める制御であり、スタートメニューからアイコンが消えるわけではない。問い合わせを減らしたいなら、この差を先に伝えておく方が早い。 2つ目は、いま強引に消さないという判断。 OneDrive本体ごと削除する回避策は、ファイル同期とエクスプローラー統合を壊すうえ、更新で復活するため作業が繰り返しになる。9月に正規の削除手段が来ることが分かっている以上、恒久策のつもりで構成をいじると、その構成自体が後で不要な負債になる。個人アカウントの利用を止めたいだけなら8月の制御を待つ方が筋がいい。 3つ目は、ヘルプデスクへの事前周知。 業務端末では動かないアプリが並んでいる状態なので、「これは何か」「クリックしたらサインインを求められた」という問い合わせが発生しうる。個人用Microsoftアカウントでのサインインを促す導線がある点は、シャドーIT・データ持ち出しの観点でも一度確認しておきたい。 なお今回の一件は、配信経路の問題としても見ておく価値がある。Storeでもレジストリでもなく、既に入っている同期クライアントが新しいアプリを持ち込んだという形であり、アプリ配布を管理下に置いているつもりでも、この経路は既存の管理策の外にある。同種の配信が今後も起きうる前提で、OneDriveクライアントの更新チャネルとリリースノートを追う担当を決めておくと、次に慌てずに済む。 出典: この記事は Following backlash, Microsoft rushes to add uninstall option for unwanted OneDrive feature の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AnthropicはClaude Fable 5（最新の最上位モデル）について、Pro・Max・Team・プレミアムEnterpriseシートといった有料プラン契約者への「追加課金なし提供」の期限を、2026年7月19日午後11時59分59秒（太平洋時間）まで再延長したと発表した。あわせて、Claude Codeの週次利用上限を50%引き上げる措置も同日まで延長される。 何が起きているか 今回の延長は今年に入って3度目だ。当初Anthropicは「Fable 5の無料提供は7月7日まで」としていたが、それを7月12日まで延長し、今回さらに7月19日まで延ばした形になる。 仕組みとしては、週次のサブスクリプション利用上限のうち最大50%分をFable 5に充てることができ、特別な申請や有効化操作は不要。他のClaudeモデルと同じ利用量プールを共有する形で消費される。ただしAnthropicは「Fable 5は他モデルよりも利用量の消費ペースが速い」と明言しており、上限に達した後は（1）従量課金のクレジットを使って利用を続けるか、（2）他モデルに切り替えて残りの利用枠内で作業を続けるか、の二択になる。 対象となるのはClaude on the Web、Claude Mobile、Claude Desktop、Claude Cowork、Claude Code、Claude Design、Claude for Microsoft 365、Claude for Teams、Claude Tagと幅広い。Claude Codeで利用するにはバージョン2.1.170以降が必要な点は要注意だ。なお、Freeプラン、Enterpriseの標準シート、従量課金Enterprise、API利用はこの無料提供の対象外となっている。 Anthropicは「Fable 5が恒久的に有料プランから外れるわけではなく、計算リソースが十分確保でき次第、標準提供に戻す」ともコメントしている。つまり今回の延長は「サービスの縮小」ではなく「本来の提供形態に戻すタイミングの先送り」という位置づけだ。 実務への影響 Claude Codeを業務で使っている日本のエンジニアにとっては、追加コストなしで最上位モデルを使える期間が単純に1週間延びたという朗報だ。ただし実務上押さえておくべきポイントが3つある。 1つ目はバージョン確認。Claude Codeでの利用にはv2.1.170以降が必須のため、CIやローカル環境のバージョンを一度チェックしておきたい。2つ目は消費ペースの把握。Fable 5は上限消費が速いため、大きめのタスクをまとめて投げる前に、Claudeの設定画面で週次利用状況を確認する習慣をつけておくと、想定外に上限へ到達して作業が止まる事態を避けられる。3つ目はモデル切り替えの運用。上限到達後は自動的に他モデルへフォールバックする設定ではないため、チームで「上限到達時はどのモデルに切り替えるか」をあらかじめ決めておくと、作業の中断を最小限にできる。 筆者の見解 延長が3回続いているという事実は、単なる「太っ腹なキャンペーン」というより、AI業界全体で計算資源（GPU/アクセラレータ）の確保が引き続きボトルネックになっていることの表れだと見ている。最上位モデルを無料開放するには相応の計算コストがかかるはずで、それを何度も延長できているのは、ユーザー獲得競争の激しさとリソース調達の綱引きが同時に起きている証拠だろう。 個人的なスタンスとしては、こうした「いつまで無料か」というニュース自体を逐一追いかけるより、使える期間にとにかく手を動かして自分なりの判断軸を作る方が建設的だと考えている。上限に達した後にどのモデルへ切り替えても業務が回る体制を作っておくことの方が、期限を気にし続けることより価値が高い。次に上限へ達したときにどう動くかを決めておく——それが今回のニュースから拾うべき一番の実務的な教訓だ。 出典: この記事は Claude Fable 5 stays free for paid users until July 19 as Anthropic buys more time の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは2026年6月29日、Amazon BedrockおよびGoogle Cloud経由でClaude Codeを利用する企業向けに、自社インフラ上で運用できる管理基盤「Claude apps gateway」を発表した。開発者ごとにクラウド認証情報を発行し、設定ファイルを各端末へ手作業で配布し、利用状況を個別ツールで追跡するという、これまでの運用負荷の高いやり方を置き換えるものだ。 何が変わるのか これまでBedrockやGoogle Cloud経由でClaude Codeを使う場合、企業は開発者一人ひとりにクラウド認証情報を割り当て、設定を手動で端末に配布し、利用量やコストを可視化する仕組みを別途用意する必要があった。Claude apps gatewayは、この3つの課題を1つのセルフホスト型コンテナに集約する。 Claude apps gatewayの4つの機能 Linux上でPostgreSQLをバックエンドに動くステートレスなコンテナとして提供され、次の役割を持つ。 ID管理: Google Workspace、Microsoft Entra ID、Okta、その他標準準拠のOIDCプロバイダーに対してOpenID Connectのリライング・パーティとして動作し、短命セッションを発行する。開発者の端末に長期間有効な秘密情報を置かない設計だ。 ポリシー: サーバー側で一度定義したmanaged settingsをサインイン時にクライアントへ配布し、以降すべてのリクエストで強制する。利用可能なモデルやデフォルト設定を一元的に調整できる。 テレメトリ: リクエストごとの利用状況をOTLP経由で、自社が管理するコレクターに送信する。 ルーティングと支出上限: Claude API・Amazon Bedrock・Google Cloudへの推論ルーティング(フェイルオーバー可)に加え、組織・グループ・ユーザー単位で日次/週次/月次の支出上限を設定できる。 Claude APIを明示的に使う構成にしない限り、推論トラフィックや利用データがAnthropicに送信されることはない。またAnthropicはゲートウェイが使うプロトコル自体を公開しており、他社が同等機能を独自実装できるようにもしている。 実務への影響 日本企業がAWSやGoogle Cloudをメインクラウドとして選び、そこ経由でClaude Codeを導入する場合、これまでは開発者ごとのAPIキー管理やコスト把握が情シス部門にとって地味に重い運用負担だった。個々人が野良でAPIキーを発行する状態が続くと、退職者の権限剥奪漏れやコスト超過といったリスクが積み上がる。Claude apps gatewayは、これを既存のEntra IDやOktaといったIDプロバイダーにそのまま乗せる形で解消できる点が実務的だ。 活用の入口はシンプルで、gateway.yamlにOIDC発行者とアップストリーム認証情報を設定し、IdP側にOIDCアプリを1つ登録するところから始まる。展開時はクライアント側のmanaged-settings.jsonでforceLoginMethodとforceLoginGatewayUrlを指定すれば、初回起動時に自動的にゲートウェイへ接続する。すでにEntra IDで社内SSO基盤を持つ企業であれば、追加のID基盤を新設せずに展開できる点は評価してよい。 筆者の見解 このアップデートは「禁止ではなく安全に使える仕組みを用意する」という王道の発想で、好感が持てる。開発者が各自でAPIキーを発行して使うシャドーIT状態を放置するより、公式に便利な入り口を用意してそこに乗ってもらう方が、結果的に統制もセキュリティも効きやすい。これは生成AIツール全般に言えることで、Microsoft Entra IDのような既存のID基盤へそのまま統合できる設計は素直に王道だと思う。 Microsoft自身も、EntraやFoundryを軸にした企業向けAIガバナンスの整備を進めている。認証・ポリシー・支出管理を一箇所にまとめるという発想では、これまで積み上げてきた統合力を活かせば正面から勝負できる力があるはずで、他社のこうした動きを一つの刺激として、その強みをもっと前面に出してほしいところだ。 企業のIT管理者にとっての教訓はシンプルで、AIエージェントの利用を個人任せの野良運用にせず、公式に管理された経路を用意することが、結局は一番の近道だということだ。 出典: この記事は Introducing the Claude apps gateway for Amazon Bedrock and Google Cloud の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Exchange Online（Outlook）のメッセージ回収（Message Recall）機能を拡張し、自社テナントの外——取引先や関連会社など「信頼された組織」宛てに送ったメールも回収できるようにする。新機能「Cross-tenant Message Recall」は2026年8月中旬から順次ロールアウトが始まり、9月中旬までに全世界の環境へ展開される予定だ。 何が変わるのか Exchange Onlineのメッセージ回収機能は、長らく「同一テナント内」でしか機能してこなかった。送信者と受信者が同じMicrosoft 365組織に属していれば、未読の誤送信メールを受信者のメールボックスから削除できたが、組織の境界を一歩でも越えると回収は不可能だった。これは長年、ユーザーから最も多く寄せられる不満の一つだったという。 今回の「Cross-tenant Message Recall」はこの壁を取り払う。ただし無条件ではない。回収を許可するかどうかの主導権は受信側の組織にある。A社がB社宛てのメールを回収したい場合、B社側の管理者が事前にA社のテナントを「許可リスト」に登録しておく必要がある——これが記事タイトルにある「catch（落とし穴）」の正体だ。 設定方法とロールアウト時期 管理者はExchange Online PowerShellから制御する。 クロステナント回収そのものを有効化 Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled $true 回収を許可する送信元テナントを許可リストに追加 Set-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add=“テナントID1”,“テナントID2”} 機能は既定で無効になっており、少なくとも1つの外部テナントを許可リストに登録しない限り動作しない。展開はWorldwide（標準マルチテナント）、GCC、GCC High、DoDの各環境が対象で、対応プラットフォームはWindows・Mac・Web・iOS・Androidとなっている。 実務への影響 日本企業の多くはグループ会社や合弁事業ごとに複数のMicrosoft 365テナントを分けて運用している。持株会社と事業会社、あるいはM&Aで統合前の旧テナントが並存しているケースも珍しくない。これまでは「別テナント宛てに誤送信したら回収不能」で泣き寝入りするしかなかったが、この機能が使えるようになれば、グループ内のテナント同士が相互に許可リストへ登録し合うだけで、社内メール同様の安全網を社外にも広げられる。 IT管理者にとっての実務ポイントは3つ。 許可リストの棚卸しを今から準備する：取引先すべてを無条件に許可するのではなく、グループ会社や恒常的に機密情報をやり取りする相手に絞って設計すべきだ。 回収そのものの制約は変わらない：相手が既にメールを開封済みなら、従来通り回収はできない。「回収機能があるから誤送信しても安心」という誤解が広がらないよう、社内啓発は引き続き必要だ。 クロステナントアクセスポリシーとの整合：B2Bコラボレーションや条件付きアクセスで既に信頼関係を設定している相手であれば、許可リストの追加も運用上の負荷は小さいはずだ。既存のテナント間信頼設定と合わせて棚卸しするとよい。 筆者の見解 メッセージ回収が「同一テナント内限定」だったことには、正直ずっと違和感があった。今の企業はM&Aやグループ経営でテナントが分かれているのが当たり前で、社外への誤送信こそ本当に困る場面のはずだ。その意味で、今回の機能追加はようやく実態に追いついた、待望のアップデートだと感じる。 面白いのは、この機能が「禁止」ではなく「安全に使える仕組み」として設計されている点だ。外部への誤送信をゼロにはできないという前提に立ち、代わりに「相手が許可した送信元からの回収だけを受け付ける」という明示的な信頼関係——ホワイトリスト方式——で安全性を担保している。暗黙の信頼に頼らず、必要な範囲だけを明示的に許可するという設計思想は、ゼロトラストの考え方そのもので素直に評価したい。 Microsoftには、こうした地道だが実務に効く改善を今後も着実に積み重ねてほしい。派手なAI機能の発表も結構だが、現場のエンジニアやIT管理者が本当に困っている「痒いところ」を埋める仕事こそ、正面から勝負できる領域のはずだ。 出典: この記事は Exchange Online receiving one of its “most requested” features next month の内容をもとに、筆者の見解を加えて独自に執筆したものです。

サムスンが7月22日に開催する次期「Galaxy Unpacked」を前に、新型折りたたみスマートフォン「Galaxy Z Fold 8」とみられる“公式級”のレンダー画像が流出した。米Tom’s GuideのScott Younker記者が7月8日付で報じたところによると、画像の出所はAndroid Headlinesで、同メディアは公式レンダーを入手したと主張しているという。 なぜこの製品が注目か Galaxy Z Foldシリーズは、今回から製品ラインが二本立てになる点がまず大きな変化だ。Tom’s Guideの整理によれば、「Galaxy Z Fold 8 Ultra」が従来のGalaxy Z Fold 7の後継機にあたり、一方の「Galaxy Z Fold 8」はより幅広で短い、以前「Z Fold 8 Wide」と呼ばれていたモデルを指す。やや紛らわしい命名だが、この幅広タイプは噂される「iPhone Ultra」の折りたたみモデルへの対抗機と位置づけられているとされ、サムスンが折りたたみ市場での主導権をどう守るかという文脈で注目されている。 スペック面では、Qualcomm製Snapdragon 8 Elite Gen 5(Galaxy S26シリーズと同一チップ)の搭載が報じられているほか、今週明らかになった情報として、ディスプレイの折り目(クリース)がついに解消された可能性があるという。以前流出したレンダーによる寸法は、展開時で約123.7×161.3×4.8mm、折りたたみ時で約123.7×82×9.7mm、重量は約200gとGalaxy Z Fold 7よりも軽量になる見込みだ。 海外リークが伝えるポイント Android Headlinesが入手したとする今回のレンダーは、サムスン自身がすでに公開しているティザー画像と一致する、ややずんぐりした本体形状を示している。カラーバリエーションはクリーム、グラファイト、ラベンダーの3色が確認できるとされ、Android Headlinesはこれに加えて、サムスン公式オンラインストア限定色として「ピスタチオ」が用意されると伝えている。 Tom’s Guideは今回のリークを、サムスン自身の予告映像と整合する内容として一定の信頼性を認めつつも、あくまで発表前の情報である点を明記している。Unpacked本番では、Z Fold 8とZ Fold 8 Ultraに加え、Galaxy Z Flip 8、Galaxy Watch 9シリーズ、Galaxy Watch Ultra 2の発表も見込まれるという。開催時刻は日本時間7月22日22時(米東部時間9時/太平洋時間6時/英国時間14時)で、各製品は発表から1〜2週間後に店頭やオンラインストアに並ぶ見通しだ。 日本市場での注目点 日本ではGalaxy Z Foldシリーズはドコモ・au・楽天モバイルおよびサムスン公式オンラインストアで例年扱われており、今回もUnpacked直後に発売時期・価格が発表される可能性が高い。一方でTom’s Guideの別記事では、Z Fold 8やGalaxy Watch 9で前年モデルより最大280ドル程度の値上げがあり得ると指摘されており、円安基調が続く為替環境を踏まえると、日本価格も相応に上振れする可能性は念頭に置いておきたい。 競合という観点では、国内では折りたたみスマホの選択肢自体がまだ限られており、Galaxy Z Fold 7からの正統進化に加え、幅広ボディの新モデルが選べるようになる点は日本の消費者にとってもメリットになりそうだ。ビジネス用途で大画面を使った資料確認やマルチタスクを重視するユーザーにとって、クリース解消の噂と軽量化は、実務での使い勝手を左右する現実的なポイントになる。 筆者の見解 リーク合戦そのものに一喜一憂する必要はないというのが率直なところだ。レンダー画像や寸法の噂は毎年恒例のことで、重要なのは発表後に実機でどこまで裏付けられるかである。とはいえ、今回のクリース解消と軽量化という2点が事実であれば、折りたたみ機を「ギミック」ではなく日常の道具として使う上で意味のあるアップデートになる。画面の折り目は長らく折りたたみ機の弱点として指摘され続けてきた部分であり、そこに正面から手を入れてきたのであれば素直に評価したい。 ...

Google傘下のGoogle DeepMindが、次世代の主力モデル「Gemini 3.5 Pro」の正式リリースを、当初予定より遅らせて2026年7月17日に設定し直したことが明らかになった。単なる日程調整ではなく、ベースとして使う予定だった「Gemini 2.5 Pro」由来のアーキテクチャを完全に破棄し、「Gemini 3」系列のネイティブな基盤から事前学習をやり直すという、フロンティアモデル開発としては異例の判断だ。 Google I/Oでの予告から一転、土壇場での差し戻し Sundar Pichai CEOはGoogle I/Oの基調講演で、Gemini 3.5 Proを「翌月にはリリースする」と予告していた。ところが関係者によると、DeepMindは投入予定日の数日前になって既存の2.5 Proベースレイヤーを本番パイプラインから引き上げ、Gemini 3のネイティブ基盤による大規模な追加事前学習に切り替えたという。OpenAIの「GPT-5.6 Sol」やAnthropicの「Claude Fable 5」が存在感を増す中、小手先のマイナーアップデートではもはや競争優位を保てないという判断が背景にあるとみられる。 なぜ土台から作り直すのか 理由は大きく二つ語られている。一つは「Pro-to-Flashパラドックス」だ。先行リリースされた軽量版「Gemini 3.5 Flash」が、旧世代の上位モデル「Gemini 3.1 Pro」をTerminal-Bench 2.1で上回る（76.2%）という逆転現象が起きてしまった。この状態のまま旧アーキテクチャの3.5 Proを出しても、価格差に見合う性能差をエンタープライズ顧客に示せず、高単価な上位ティアの存在意義そのものが揺らぐ。 もう一つは推論力そのものの壁だ。リークされた社内評価によれば、複雑で再帰的なツール呼び出しが絡む環境下で、多段階の数学推論やSVGによる複雑なレイアウト生成において構造的な一貫性を保てなかったという。テキスト処理は問題なくこなせても、競合モデルがすでに達成している安定性には届いていなかった。見劣りする状態のまま世に出すより、短期的なPR上のダメージを飲み込んでも基盤から作り直す方を選んだ格好だ。 実務への影響 ― 日本のエンジニア・IT管理者にとっての意味 Proフラグシップが不在の間も、軽量版のGemini 3.5 Flashは1Mトークンあたり入力$1.50／出力$9.00という価格で提供が続く。高頻度・大量呼び出しが必要なエージェントパイプラインは、当面このFlashで組んでおくのが現実的だ。逆に、複雑な数学的推論や込み入ったレイアウト生成が絡む用途は、7月17日のPro正式版を待ってから設計に組み込んだほうが手戻りが少ない。 また、「軽量モデルが上位モデルの性能を食ってしまう」という現象は、Google固有の話ではなく、モデル選定全般に共通するリスクだ。カタログ上のスペックやベンチマークの序列だけでツールチェーンを固定せず、実タスクでの検証結果をもとにモデルを選ぶ姿勢が、今後ますます重要になる。未リリースのモデルを前提にロードマップを組んでいるチームは、代替経路を必ず用意しておきたい。 筆者の見解 今回の延期劇は、フロンティアAI各社の競争が「ベンチマークの数字」から「実タスクでの安定性」の勝負に移っていることを象徴している。見劣りする状態のモデルをスケジュール通りに出すのではなく、土台から作り直す方を選んだこと自体は、誠実な判断だと思う。 一方で筆者は、こうした「今どのモデルが強いか」を逐一追いかける情報収集にはあまり価値を感じていない。数週間単位でランキングが入れ替わる世界で情報を追い続けるより、手元のツール（筆者の場合はClaude Code）を軸に実際に手を動かし、成果を積み上げるほうが費用対効果は高い。Googleは画像生成など強い領域を持っている一方、実務の中心に据えるかどうかは話題性ではなく、自分の現場での検証結果で決めるべきだ。 もう一点、今回の背景にある「軽量モデルが上位モデルを食う」現象は他人事ではない。単発のモデル評価スコアだけでなく、エージェントが自律的に判断・実行・検証を繰り返す「ハーネスループ」の中でどのモデルが安定して動き続けるかを見極めることこそ、これからのエージェント基盤設計における本質的な論点になっていくはずだ。 出典: この記事は Google Delays Gemini 3.5 Pro Launch to July 17 for Full Architectural Rebuild の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Accenture(アクセンチュア)がデータ漏洩を認めた。ハッカー集団「888」が、同社から約35GBのソースコードや認証情報を盗んだと主張し、サイバー犯罪フォーラムで販売を開始したことを受けての対応だ。 何が盗まれたのか 攻撃者「888」の投稿によれば、流出したとされるデータにはソースコードに加え、RSA鍵、SSH鍵、Azure PAT(個人用アクセストークン)、Azureストレージのアクセスキー、各種設定ファイルが含まれるという。証拠として、“121123_AtriasTalentAcademy"という名前のAzure DevOpsリポジトリをクローンする様子のスクリーンショットも公開された。BleepingComputerはこれらの主張の全容を独自には検証できていないとしている。 Accentureは声明で「独立した事案として認識しており、原因はすでに是正済み。事業運営やサービス提供への影響はない」とコメントした一方、漏洩した情報の正確な量や種類、侵入経路、顧客データへの影響有無については言及を避けている。 繰り返される標的 Accentureが漏洩騒動の渦中に立つのはこれが初めてではない。2024年には同じ「888」が委託先経由の漏洩をきっかけに従業員データの販売を試みており、2021年にはランサムウェア集団LockBitによる攻撃で情報が窃取された過去がある。世界で数十万人規模のコンサルタントを抱え、無数の顧客環境やクラウドリソースにアクセスする立場にある以上、こうした攻撃対象領域の広さは今後も付きまとう課題だろう。 実務への影響 今回特に注目すべきは、盗まれたとされる情報がソースコードだけでなく、Azure PATやストレージアクセスキー、SSH鍵といった「人間ではなくシステムが使う認証情報」、いわゆるNon-Human Identities(NHI)である点だ。これらは一度漏洩すると、正規のワークフローに紛れて長期間気づかれずに悪用されるリスクが高い。日本企業でもAzure DevOpsやGitHub Actionsで有効期限のないPATを発行しっぱなしにしているケースは珍しくない。この機会に、自社のリポジトリやCI/CDパイプラインで「失効させていないPAT」「ローテーションされていないストレージキー」が放置されていないか、棚卸しをしておきたい。Accentureのような大手SIerと取引がある企業は、委託先経由の二次被害にも注意が必要だ。 筆者の見解 盗まれたものの中身を見ると、ソースコードそのものよりも、Azure PATやストレージキー、SSH鍵といった「常時有効な認証情報」の漏洩の方が実害として大きくなりやすい。筆者はゼロトラストの立場から、常時アクセス権を持ち続ける資格情報こそが特権アカウント管理における最大のリスクだと考えている。人間が使うパスワードだけでなく、こうした非人間ID(NHI)を誰がいつ発行し、いつ失効させたかを追跡できていない組織は、Accentureに限らず、今回のような漏洩の一歩手前にいると考えた方がいい。 Accentureほどの規模の企業でも「原因は是正済み」という短い説明で済ませてしまう対応には、コンサルティング業界全体の情報開示の物足りなさを感じる。「事業運営への影響はない」という説明を鵜呑みにせず、取引先や委託先が同様の被害に遭った場合に自社へどう波及するかを、日頃から棚卸ししておく姿勢が今の時代には欠かせない。 出典: この記事は Accenture confirms breach after hacker offers stolen data for sale の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Excel上のAIアシスタント「Copilot in Excel」に、業務手順を再利用できる「スキル」機能と、ワークブックごとのルールを定義する「Rulesシート」、さらに財務データコネクタを追加した。いずれもOneDrive上にファイルとして保存でき、毎回同じ指示をチャットに書き込まなくても、Copilotが定型業務を一貫した手順で実行できるようにする狙いだ。 SKILL.mdファイルによる「再利用可能スキル」とは何か 今回追加された目玉機能が、SKILL.mdというテキストファイルの形で保存できる「再利用可能スキル」だ。たとえば「月次売上レポートのフォーマットに整形する」「特定の集計ロジックでピボットを作る」といった一連の作業手順を一度SKILL.mdに書いておけば、以降はそのスキルを呼び出すだけでCopilotが同じ手順を再現してくれる。OneDriveに置いておけばチーム内で共有もできるため、属人化しがちだったExcel作業の「暗黙知」を明文化・資産化できる点が大きい。 手順やルールをMarkdown形式のファイルとして定義し、AIエージェントに読み込ませるという設計自体は、近年のAIエージェント界隈で広がりつつある考え方で、Microsoftもこの流れに追随した形だ。 Rulesシートで書式・命名規則・数式の「お作法」を固定化 もう一つの新機能「Rulesシート」は、ワークブック単位で書式ルール・セルの命名規則・数式の書き方の慣習をあらかじめ定義しておける仕組みだ。「金額セルは常に3桁区切りでカンマ表示」「シート名はプロジェクトコード_年月の形式」といった社内ルールをRulesシートに書いておけば、Copilotがそのワークブックを編集する際に自動的にルールを守るようになる。これまでのように毎回チャットで細かい書式指定をし直す手間が減る。 加えて、財務データを直接取り込める新しいデータコネクタも追加された。会計・財務系のデータソースとExcelの間の橋渡しをCopilotが担うことで、レポート作成のためのデータ収集・整形作業そのものを短縮できる。 実務への影響 日本企業のバックオフィス、特に経理・財務部門にとっては地味だが効きそうな機能強化だ。月次・四半期決算のレポート作成は「同じフォーマットに同じ手順で整える」という反復作業の塊であり、SKILL.mdとRulesシートはまさにこの反復を仕組み化するための道具になる。IT管理者の視点では、誰がどんなスキルをOneDriveに公開しているのか、部門をまたいで共有していいスキルなのかというガバナンス設計が新たな検討課題になるだろう。野良のSKILL.mdが乱立すると、かえって「どのルールが正なのか」が分からなくなる恐れもあるため、テンプレートの管理者を決めて配布する運用ルールを早めに整備しておきたい。 筆者の見解 Copilotについては、これまで機能の割に実務での「効く感」が乏しいという印象を持ってきたが、今回の追加は方向性として素直に評価したい。ルールや手順をファイルとして明文化し、AIに毎回同じ指示を繰り返させない設計は、「禁止ではなく安全に使える仕組みを作る」という考え方そのものだ。属人化した業務ノウハウを個人の頭の中に閉じ込めるのではなく、SKILL.mdやRulesシートという形でチームの資産にできるなら、それはCopilotが「その場しのぎのチャットボット」から「業務基盤の一部」へと一歩進んだことを意味する。 一方で、こうした仕組みは作って終わりではなく、実際に現場で使われて初めて価値が出る。Microsoft 365は本来、統合して使うことで真価を発揮するプラットフォームであり、今回のような地道な機能強化を着実に積み重ねてこそ、Copilotが名実ともに現場の主力ツールになっていく。正面から勝負できるだけの土台は十分にあるはずなので、この路線を粘り強く伸ばしていってほしいというのが率直なところだ。 出典: この記事は Microsoft adds reusable skills and finance data connectors to Copilot in Excel の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIは7月、次期フラッグシップモデル「GPT-5.6 Sol」を、AI半導体スタートアップのCerebras Systems製ウェハースケールチップ上で稼働開始すると明らかにした。想定される出力速度は毎秒750トークン。一般的なGPUクラスタでの応答生成速度（毎秒40〜120トークン程度）と比べておよそ10倍に達する見込みだ。まずは限定的な顧客からの提供となり、Cerebras側の供給能力拡大に応じて対象を広げていく計画という。 ウェハースケール推論という力技 Cerebrasの最大の特徴は、通常のチップのようにシリコンウェハーを切り分けて使うのではなく、ウェハー1枚をまるごと1つの巨大な演算チップとして使う「ウェハースケールエンジン」にある。モデルの重みをオンチップのメモリに載せたまま処理できるため、GPUクラスタで発生しがちなメモリ帯域のボトルネックを回避しやすい。これが毎秒750トークンという桁違いの数字につながっている。 なお今回のCerebras展開は、6月29日に発表されたBroadcom製推論チップ「Jalapeño」とは別ルートだ。OpenAIは同じGPT-5.6 Solを、性格の異なる2種類のカスタムシリコン上で並行して走らせるという、いわば「二正面作戦」を取っている。特定ベンダーへの依存リスクを避けつつ、速度と供給量の両方を確保する狙いが透けて見える。 200億ドル契約とCerebrasのIPO 背景にあるのが、OpenAIとCerebrasの間で以前から明らかになっていた総額200億ドル超・750メガワット規模の複数年推論契約だ。Cerebrasは今年に入りIPO申請も行っており、廉価版の「Terra」や「Luna」ではなく最上位モデルのSolを最初にCerebras上で稼働させるという判断は、上場を控えたCerebrasへのOpenAIからの「お墨付き」としての意味合いも強い。価格はまだ公表されていないが、Sol自体のAPI料金がすでに入力100万トークンあたり5ドル・出力30ドルとされており、高速版はこれより高い価格帯になる可能性が高い。 実務への影響 これまでLLMの性能評価は精度やコンテキスト長が主戦場だったが、ここへきて「レイテンシ」そのものが単独の商品価値として売られ始めている。エンジニアやIT管理者にとって重要なのは、ベンチマークの数字を眺めることではなく、自分たちの実際のワークフローでエンドツーエンドのトークン/秒を計測する習慣を持つことだ。毎秒90トークンと750トークンの差は、単なる速度比較ではない。コーディングエージェントが4000トークンのプルリクエストを6秒で作るか、1分かけて作るかの違いであり、それはエージェントを対話ループの中でリアルタイムに使えるか、一晩バッチで回すしかないかという、ワークフロー設計そのものを左右する差になる。日本企業がAIエージェント導入を検討する際も、精度だけでなく「どれだけ低遅延で回せるか」を評価軸に加えるべきだろう。 筆者の見解 このニュースの本質は、OpenAIとCerebrasの契約金額の大きさよりも、推論速度そのものが競争軸になってきたという点にある。AIエージェントの価値は、人間の認知負荷をどれだけ減らせるかで決まる。逐一確認を求めながらゆっくり動くAIと、目的さえ伝えれば自律的にループを回して結果を返してくるAIとでは、体験としてまったく別物だ。そして自律的なループを気持ちよく回すには、応答速度がボトルネックにならないことが前提になる。その意味で、今回のCerebras採用やBroadcomとの二正面展開は、モデルの賢さの競争だけでなく「エージェントを止めない速度」の競争がいよいよ本格化した合図だと見ている。 日本のエンジニアにとっての教訓はシンプルだ。ベンダー各社の速度競争をニュースとして追いかけるだけでは何も変わらない。自分の手元のエージェントワークフローで実際にトークン/秒を測り、速度が上がったときにどこまで自律実行の範囲を広げられるかを、手を動かして試す。情報を追うより、実際に使って成果を出す経験を積むことが、今この分野で最も価値のある投資だと思う。 出典: この記事は OpenAI to run GPT-5.6 Sol on Cerebras at 750 tokens per second in July の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは6月23日に配信したWindows 11向けプレビュー更新プログラム「KB5095093」について、6月29日付けで追加の修正を適用したと、PC Watchが報じた。修正されたのは、特定のシステムファイルが数十GBから数百GBという規模でストレージを消費し続けるという不具合だ。公式のアナウンスがほとんどないまま静かに直された格好だが、ストレージ容量が限られたPCを使うユーザーにとっては見過ごせない内容だ。 何が起きていたのか 問題の主役は「CapabilityAccessManager.db-wal」というファイル。C:\ProgramData\Microsoft\Windows\CapabilityAccessManager直下に置かれているが、フォルダ自体が隠し属性であるうえ、既定では管理者アカウントでもアクセス権限がない。エクスプローラーでプロパティを見ても「0バイト」と表示されるため、タスクマネージャーやストレージセンサーでは異常の原因を特定できない、いわば見えない大食いの状態になっていた。 ファイル名の「.db-wal」は、SQLiteが更新差分を一時的に書き込む「Write-Ahead Log」であることを示す。本来はメインのデータベースファイルに定期的にチェックポイントされて肥大化しないはずが、その処理がうまく働かず、ログが際限なく積み上がっていたとみられる。CapabilityAccessManagerはカメラやマイク、位置情報といったアプリのアクセス権限履歴を記録するコンポーネントで、日常的に頻繁な書き込みが発生するため、影響が大きくなりやすい。 検証で見えてきたこと PC Watch編集部が実際に手元の環境で観測したところ、プレビューパッチ適用済みの環境では同ファイルのサイズが2.16MB前後で安定していたのに対し、未適用の環境では観測開始時点の410MBから430MBほどまで増加を続けたという。ネット上ではさらに深刻な、数十GBから数百GB規模の消費事例も報告されており、非表示かつアクセス不可という条件が重なったことで、原因究明の難易度を押し上げていたことがうかがえる。 日本市場での注目点 今回の問題はプレビュー版、いわゆるInsiderプログラムやプレビューチャネル経由の更新に限られており、Windows Updateの通常配信を待つ一般ユーザーには直接影響しない可能性が高い。ただし、プレビュー版の内容は今後の正式な月例更新に取り込まれていく土台であるため、この修正が正式リリースにも反映されるかは引き続き確認が必要だ。SSD容量が256GBや512GBといった比較的小容量の構成が主流の日本向けノートPCやタブレットでは、数十GB単位の消費は無視できないインパクトになる。プレビュー更新を試している場合は、設定アプリの「Windows Update」から最新の状態まで適用されているかを確認しておきたい。 筆者の見解 非公開のシステムフォルダの中でひっそりと不具合が進行し、しかもユーザー側からは原因を特定する手段がほとんどないという今回の状況は、Windowsの品質管理として正直もったいないと感じる。SQLiteのWALファイルがチェックポイントされずに肥大化するという現象自体は、原因さえ特定できれば技術的にそれほど珍しい話ではない。むしろ問題は、影響範囲や修正内容についての公式なアナウンスがほぼないまま静かに直されたことだ。ユーザーが自力でファイルサイズの異常に気づき、ネットで検索して原因にたどり着くしかない状況を作ってしまうのは、本来なら情報開示の面でも正面から勝負できる力を持っているMicrosoftにとって惜しい対応だと思う。プレビューチャネルはまさに不具合を早期に洗い出すための仕組みのはずで、今回のような事例こそ「見つかった不具合とその対処」を明確に告知する材料にしてほしいところだ。ストレージ逼迫は特に低価格帯PCのユーザー体験に直結するだけに、今後も同種の問題が起きた際の情報開示のスピードと透明性に注目していきたい。 出典: この記事は Windows 11プレビューパッチ、すぐ適用すべき。SSDが数十GB消費される不具合解消 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

EUが来月発表予定のGoogleへの新規制について、米Ars Technicaが2026年6月29日に詳報した。デジタル市場法（DMA）に基づくこの規制案には、Android上でのAI開放と競合への検索データ提供をGoogleに義務付ける内容が含まれる。GoogleはセキュリティVPを通じてプライバシーと安全性への深刻な懸念を表明しており、テック業界とプライバシー研究者から注目を集めている。 規制案の2本柱 AndroidにおけるAI開放 現在、GeminiはAndroidデバイス上でユーザーのファイル・画面コンテンツ・音声などにシステムレベルでアクセスできる特別な地位を与えられている。EUの規制案はこの独占を廃止し、他社AIモデルにも同等のシステムアクセス権限を開放するよう求めるものだ。 Ars TechnicaによればGoogleのセキュリティVP、Heather Adkins氏はWiredの取材に対し、「この変更が実施されれば、数週間以内にEU内での詐欺件数が大幅に増加するだろう」と警告した。深いシステム権限を持つAIサービスを悪意ある第三者が装い、データ窃取やユーザー操作を行うリスクを具体的に指摘している。 匿名化検索データの競合他社への提供 規制案のもう一つの柱は、Googleが保有する検索データ（クエリ内容・ランキング・クリック率など）を匿名化した上で競合他社に提供する義務付けだ。しかしArs Technicaによれば、Googleの社内セキュリティチームはいわゆる「リンケージ攻撃（linkage attack）」を用いて、この匿名化済みデータから個人を特定するのにわずか2時間しかかからなかったという。 「匿名化は難しく、適切な技術的専門家が関与しなければならない」とAdkins氏はWiredに語っている。さらに、強力なAIモデルが広く利用可能になった現在では、こうした再識別化がより容易になっているとも指摘した。 なぜこの問題が重要か Ars Technicaの記事は、Googleの懸念には技術的根拠があると認める一方、検索市場で90%超のシェアを持つ企業が規制に抵抗する利害関係も指摘する。データの匿名化が困難であることはセキュリティ研究の世界では広く認識されており、Googleの主張は一定の正当性を持つ。しかし、絶対的な市場支配力を持つ企業の反論は常にバイアスを考慮して受け止める必要もある。 EUは今回、DMAに基づき「ゲートキーパー」と指定したGoogle・Meta・Amazonなどに対して追加規制を課す権限を行使している。Googleはこの法律自体の見直しを求め公然と反対してきた経緯もある。 日本市場での注目点 このEU規制はDMAに基づく域内規制だが、影響は域外にも広がりうる。日本でも公正取引委員会がGoogleのスマートフォンメーカーへのプリインストール契約について調査を進めており、欧州の規制の帰趨は日本の競争政策の参照事例になる可能性がある。 また、「匿名データの再識別化リスク」は改正個人情報保護法に基づく仮名化データ活用の議論においても重要な論点だ。日本でもデータポータビリティや競合へのデータ提供義務が議論される中、今回のEU事例は技術的・法的な限界を示す生きた参考事例となりうる。現時点での日本ユーザーへの直接的な影響は限定的だが、グローバルプラットフォームのデータ管理透明性への意識を高める契機として注目したい。 筆者の見解 Adkins氏が指摘する「リンケージ攻撃で2時間以内に個人特定が可能」という事実は、技術的に軽視できない。AIの能力向上とともに、匿名化データから個人を特定するハードルは年々下がっている。規制当局がこの現実を正面から受け止めなければ、善意の規制がプライバシーを逆に脅かす皮肉な結果を招く。 ただし「リスクがあるからデータを出すな」という結論に直結させるのも早計だ。競争市場を維持するための情報共有の必要性と、技術的なプライバシー担保の両立は「どちらかを選ぶ」問題ではなく、規制当局・技術者・企業が共同で実装を設計すべき問題だろう。 AndroidにおけるAI開放についても同様だ。Geminiと同等の権限を他社AIに開放する際、適切な審査・認証・権限スコープの厳格化という仕組みを整えることで「開放しつつ安全を確保する」設計は十分に可能なはずだ。禁止で解決しようとするアプローチは必ずどこかで破綻する。安全に使える仕組みを正面から設計することが、最終的にはユーザーの利益につながる。 EUには規制の大義を保ちながら技術的に実現可能な実装を詰める責任があり、Googleにはプライバシーを本当の意味で守れる技術的解決策の提示が求められる。両者の議論が「禁止vs現状維持」の二項対立ではなく、建設的な設計論争へと発展することを期待したい。 出典: この記事は Google warns EU’s plans to weaken its monopoly could expose user data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

リード Microsoftが2011年以来 Windows PC のブートセキュリティを支えてきた「Secure Boot 2011証明書」が段階的に失効し、Dell・HP・Lenovo・ASUS・Acer・MSI・Samsung・LG・Microsoft Surface の各社が自社製品向けの移行ガイドを相次いで公開した。Windows Updateによる自動適用が基本だが、BIOSアップデートが必要なモデルや企業向けの手動対応が必要なケースも存在する。 Secure Boot証明書とは何か、なぜ今これが問題なのか Secure Boot は UEFI ファームウェアレベルで動作するセキュリティ機能だ。Windows が起動する前に「このソフトウェアは信頼された署名を持つか」を検証し、ルートキットやブートキットによる改ざんを防ぐ。この仕組みの信頼の根拠となっているのが「証明書」であり、今回問題になっているのは 2011年に発行されたルート証明書群だ。 失効スケジュールは以下の3段階に分かれている： 証明書 失効日 Microsoft Corporation KEK CA 2011 2026年6月24日（失効済み） Microsoft UEFI CA 2011 2026年6月27日（失効済み） Microsoft Windows Production PCA 2011 2026年10月19日（予定） 最後の「Windows Production PCA 2011」はまだ失効していないが、今年10月までに対処が必要という意味では猶予は多くない。 Microsoftは2023年版の新証明書を Windows Update 経由で配布中だが、ここで重要なのが「証明書の更新にはBIOSアップデートが必要なモデルがある」という点だ。WindowsだけアップデートしてもBIOSが古ければ完全に対応できないため、OEMごとの対応ガイドの確認が必要になる。 各OEMの対応状況 ASUS ASUSはコンシューマー向けと法人向けで別ページを用意しており、ガイドの完成度はOEM中でも高い。Windows Security に黄色や赤のバッジが表示されている場合、PowerShellコマンドで KEK・DB 証明書の有無を確認し、不足している場合はレジストリ（AvailableUpdatesを0x5944に設定）＋スケジュールタスクの手動実行という手順が示されている。イベントログのエラーコード1801〜1808の意味と対処法も掲載されており、細かいトラブルシューティングまでカバーされている。 Lenovo ThinkPad・ThinkCentre・IdeaPad・Legion・Yogaといった製品ラインごとに対応BIOSバージョンと直接ダウンロードリンクが掲載されており、汎用ドライバーページを探し回る手間が省ける。IntuneおよびSCCMを使った企業展開向けの注記も含まれており、エンタープライズ環境での活用がしやすい。 ただし、End of Service Life（EOSL）を迎えた製品はBIOSアップデートの対象外となる。このあたりはどのOEMも共通の方針だ。 Dell Alienwares・Inspiron・XPS・Latitude・OptiPlex・Precision・Vostro・Wyse・IoTデバイスと、製品ラインごとに整理されたサポート記事を公開。法人向け製品（Latitude・OptiPlex等）については特に詳細な手順が用意されている。 その他 HP・MSI・Acer・Samsung・LG・Microsoft Surfaceもそれぞれのサポートページで対応ガイドを公開済み。基本的には「Windows Updateを適用すれば自動対応される」が、BIOSのバージョンによっては追加手順が必要なケースがある。 実務への影響——日本のエンジニア・IT管理者が今すぐすべきこと 一般ユーザー（個人PC）: Windows Update が有効であれば多くの場合は自動的に対応済み。念のため Windows セキュリティ → デバイスセキュリティ → コアの分離 を開き、警告表示がないかを確認しておこう。 ...

MicrosoftのWSL担当プロダクトマネージャー Craig Loewen氏が「WSL 3などというものは存在しない」と公式に否定し、一部メディアが「WSL 3」と誤報していた機能の正体がWSL Containersであることを明らかにした。Build 2026で発表されたこの機能は、数日以内にWindows 11ユーザーへ提供される予定だ。 「WSL 3」誤報の経緯 Build 2026でMicrosoftが新機能「WSL Containers」を発表した際、略称として「WSLc」という表記が流通したことから、一部の海外メディアがこれを「WSL 3」と誤って報道した。これを受け、Loewen氏はX（旧Twitter）で「PSAとして言っておきますが、WSL 3というものは存在しません。いくつかの記事でそう書かれているのを見かけますが、現時点でそのようなものはありません」と明確に訂正した。 WSL Containersは、WSL 2の後継バージョンではなく、既存のWSLインフラの上に追加された新しいレイヤーである。バージョン番号による後継ではないため「WSL 3」という呼称は誤りだ。 WSL Containersとは何か WSL（Windows Subsystem for Linux）はWindowsに内蔵されたLinux実行環境で、デュアルブートや仮想マシンなしにLinuxのコマンドラインツールやアプリケーションをWindows上で動かせる機能だ。 コンテナはそれとは異なる概念で、アプリケーションと必要な依存関係・ライブラリ・設定をひとまとめにした軽量な隔離実行環境のことを指す。仮想マシン（VM）がOS全体をシミュレートするのに対し、コンテナはホストOSのカーネルを共有しつつ独自のファイルシステムとプロセス空間を持つ。起動が速く、環境の共有・移植が容易な点が最大の利点だ。 WSL Containersはこのコンテナ機能をWSLに直接統合したもので、wslc.exeというCLIツールを使ってWindowsのターミナルから直接コンテナの作成・実行・管理が行える。 WSL 1・WSL 2との違い WSLはこれまで2段階の進化を経てきた。 WSL 1（2016年）: Linuxシステムコールを変換するトランスレーション層。実際のLinuxカーネルが存在しないためコンテナは利用不可 WSL 2（2019年）: 軽量なHyper-V VM上でフルLinuxカーネルを実行。これによりDocker Desktopがバックエンドとして利用可能になった WSL Containers（2026年）: OCI準拠コンテナ専用のHyper-Vエンジンを持つ新しい層。wslc.exeでサードパーティツールなしにコンテナを直接操作できる WSL Containersはバージョン番号の更新ではなく、既存のWSLスタックに追加された独立した機能層として理解するのが正確だ。 Docker Desktopが不要になる意味 これまでWindows上でLinuxコンテナを動かすには、Docker Desktopが事実上の標準ツールだった。Docker DesktopはWSL 2をバックエンドとして利用しており、開発者体験としては優れているが、250名以上の組織では有償ライセンスが必要という制約がある。また、IT管理者側から見れば導入・管理の工数も無視できない。 WSL Containersはこの課題を直接解決する。Windowsに標準搭載された機能として、追加のインストールなしにwslc.exeでコンテナを操作できる。OCI（Open Container Initiative）標準に準拠しているため、既存のコンテナイメージとの互換性も確保されている。 実務への影響 開発者・エンジニア向け 個人PCやチームのWindows環境でDockerライセンスコストを気にせずコンテナ開発が行える wslc.exeは標準のWindowsターミナルから実行できるため、ツールチェーンがシンプルになる Docker Desktop連携の既存ワークフローは引き続き動作する。移行は段階的に行える IT管理者向け Windows 11の標準機能として管理できるため、Docker Desktop用の個別ポリシーが不要になる可能性がある ただし、機能が正式リリースされた後のグループポリシー対応状況やIntune管理可否については、正式ドキュメントで確認が必要だ エンタープライズ環境では「動くから使おう」ではなく、セキュリティポリシーとの整合性確認が先決 リリースタイミング Loewen氏は6月23日の投稿で「1週間以内」と述べており、6月末〜7月上旬にWindows 11のアップデートで提供される見通しだ 筆者の見解 今回のWSL Containersは、Windowsを「開発者にとって使いやすいプラットフォーム」にするという一貫した方向性の延長線上にある取り組みで、評価できる動きだ。Docker Desktopのライセンスコスト問題はエンタープライズで長年のあるある課題だっただけに、これがOS標準機能として解決されるなら実害は小さくない。 ...

米テクノロジーメディアArs Technicaは2026年6月26日、Netflixがすべてのユーザープロファイルに対して固有のメールアドレスの紐付けを義務化したと報じた。同社は「永久的な変更（permanent change）」と明言しており、2023年のパスワード共有規制に続く大きなポリシー転換となる。 なぜこの変更が注目されるのか これまでNetflixは、1つのアカウントに複数のプロファイルを作成し、家族間で共有する使い方を許容してきた。しかし今回の変更により、各プロファイルに独立したメールアドレスが必要となった。 Netflixが公式に挙げるメリットは以下の通りだ。 個別認証の実現: プロファイルごとに独自のログイン情報を持て、新規デバイスへのサインインや二要素認証の設定が可能になる 設定の独立化: 言語・音声・表示設定をアカウントホルダーを介さず変更できる 子どもプロファイルは対象外: 子ども向けに設定されたプロファイルへのメールアドレス登録は不要 Ars Technicaが報じた現場の混乱 Ars TechnicaのライターScharon Harding氏は、自身が体験した混乱を詳述している。父親がサブプロファイルユーザーとしてアカウントを利用していたが、6月15日の変更後にログアウトされ、MMAの生配信イベント直前に急遽設定変更を迫られたという。 Harding氏のレポートによると、新しいメールアドレスを登録した直後からNetflixの広告メールが届き始めたという副作用も確認されている（配信停止は可能）。 Reddit上では、1人で複数プロファイルを番組ジャンルごとに整理して使っているユーザーからも不満の声が相次いでいる。「ドキュメンタリー用」「映画用」「普段のドラマ用」と使い分けていたユーザーにとっては、全プロファイルに別々のメールアドレスを用意する負担が生じる。 プライバシーへの懸念 Ars Technicaが指摘する最大の問題点はプライバシーだ。Netflixのプライバシーポリシーには「収集したメールアドレスをマーケティング・広告会社と共有する可能性がある」と明記されており、今回の変更が広告ターゲティング拡大を目的とした情報収集ではないかという批判がSNS上で広がっている。 なお、同メディアは7月7日から多要素認証（MFA）が必須化されるという報道も確認しているが、Netflixからの正式発表はなく、続報を追っている段階だ。 日本市場での注目点 日本のNetflixユーザーにとっても、この変更は無縁ではない。確認・対応すべきポイントは以下の通りだ。 サブプロファイルの設定確認: 家族がサブプロファイルを使っている場合、近日中に設定変更を求められる可能性がある。事前に各メンバーのメールアドレスを把握しておくとスムーズだ 広告メールへの対処: Googleの「＋エイリアス」機能（例：yourname+netflix@gmail.com）を活用すれば、Netflixからの広告メールを専用フォルダに振り分けたり、将来的に識別・管理しやすくなる プライバシーポリシーの確認: 日本語版プライバシーポリシーでも同様の条項が含まれる可能性が高い。利用前に内容を把握しておくことを推奨する 筆者の見解 今回の変更を技術的な側面から見ると、プロファイルごとに独立した認証情報を持てるようになることには一定の合理性がある。とりわけ二要素認証の個別設定が可能になる点は、セキュリティの観点からは前進だ。 ただ、懸念を拭えないのはNetflixが自社プライバシーポリシーで「広告会社へのメールアドレス共有」を明示している点だ。「ユーザー体験の向上」と「データ収集の拡大」が同時に達成される設計は、利用者として冷静に見極める必要がある。 ユーザー側の現実的な対応としては、広告メールの仕分けや「エイリアスメール」の活用といった「仕組みで守る」アプローチが有効だ。サービス側のポリシーを嘆くより、自分でコントロールできる手段を整えておく方が建設的だろう。プライバシーは「禁止」で守るより、賢い設定で管理する時代だ。 出典: この記事は Netflix now requires every user profile to be tied to unique email address の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月23日、Windows 11向けの更新プログラムKB5095093（ビルド26200.8737 / 26100.8737）をリリースし、長年ユーザーを悩ませてきたシャットダウン遅延バグを公式に認定・修正した。「ハードウェアが遅いのかも」と諦めていた人も多いはずだが、原因はWindowsそのものにあるバグだったことが明らかになった。 シャットダウン遅延の真犯人はBITS 問題の根本原因はBITS（Background Intelligent Transfer Service）というWindowsの内部サービスだ。BITSはWindows Updateのダウンロード、Microsoft Storeのアプリ更新、その他のバックグラウンド転送タスクを一手に担うコンポーネントで、Windowsの裏方として長年動き続けてきた。 今回Microsoftが認定したバグは、シャットダウン開始後にOSがBITSを停止するまでの待機時間が想定以上に長くなるというものだ。更新プログラムのダウンロード中やMicrosoft Storeの同期が走っているタイミングでシャットダウンしようとすると、「シャットダウン中…」の画面で数十秒から数分間待たされることになっていた。 KB5095093ではシャットダウン時にBITSを停止するまでの待機時間が大幅に短縮された。すべてのPCで劇的な変化があるわけではないが、「シャットダウンに異常に時間がかかる」と感じていたユーザーには明確な改善が期待できる。 タスクバーアイコンが消える問題も解消 もう一つ注目すべき修正がexplorer.exeの信頼性改善だ。サインイン直後にタスクバーのアイコンが灰色のプレースホルダーとして表示され、explorer.exeを手動で再起動しないと正常に戻らない——という問題が多くのユーザーから報告されていた。 Microsoftはリリースノートで「ログイン・ロック画面周辺のサードパーティ製資格情報プロバイダーに関連する問題に対処し、タスクバーアイコンが灰色のプレースホルダーとして表示される確率を低減した」と説明している。 explorer.exeはタスクバーだけでなく、スタートメニュー・右クリックメニュー・ファイルエクスプローラーなどWindowsシェル全体を担うコンポーネントだ。その信頼性が向上することで、今回の恩恵はタスクバーアイコンの問題にとどまらない。 explorer.exe改善がもたらすその他の効果 KB5095093には以下のshell関連改善も含まれている。 ファイルエクスプローラーの「ホーム」タブの表示が高速化（OneDrive同期中でも遅延が減少） 仮想デスクトップの切り替えパフォーマンスの向上 スタートメニューのAcrylicぼかし効果の安定性向上（再表示時のちらつきが解消） シェルエクスペリエンスに依存するアプリの起動速度向上 また今回のリリースにはポイントインタイムリストア（Windowsの動作スナップショットを復元できる機能）や、Windows Updateのより細かい制御機能も含まれており、品質修正以外の面でも注目度が高いアップデートとなっている。 実務への影響 企業のIT管理者やエンジニアにとって、今回の修正は地味ながら影響が大きい。 シャットダウン遅延の改善は、退社時や再起動後の作業再開時のストレスを軽減する。「PCの電源が落ちるまで毎回1〜2分待っていた」というケースは珍しくなく、積み重なると相当な時間ロスだ。 タスクバーアイコン消失は、サードパーティ製の多要素認証クライアントや社内向け認証ツールを使う企業環境で特に頻発しやすい問題だった。IT部門へのヘルプデスク問い合わせが増えていた現場では、今回の修正で件数が減ることが期待できる。 Intune経由でKB5095093のデプロイを管理している組織は、7月のPatch Tuesdayを待たずにオプション更新として適用を検討する価値がある。ただし本番展開前のテスト環境での検証は忘れずに行ってほしい。 筆者の見解 今回の件で個人的に思うのは、「BITSによるシャットダウン遅延」という問題が何年も前からユーザーコミュニティで認識されていたにもかかわらず、公式認定と修正までにこれだけ時間がかかったということだ。正直もったいない。ユーザーが「自分のPCのせいかも」と思い込んで諦め続けていたケースも多かったはずで、そこは素直に反省してほしいポイントだ。 一方で、KB5095093全体を見渡すと、BITSバグやexplorer.exeの信頼性改善にとどまらず、ポイントインタイムリストアやUpdate制御の強化など、地道かつ本質的な品質向上が詰め込まれている。こういうアップデートこそが長期的な信頼の積み重ねになる。 Windowsは今もエンタープライズの基盤として動き続けている。派手な新機能よりも、シャットダウンがちゃんと速く終わる——そういう基本的な体験の品質を丁寧に積み上げる姿勢が、今後も続くことを期待したい。 出典: この記事は Microsoft admits Windows 11’s slow shutdown is a bug, plus blank taskbar icons in a new update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年8月にも、米ニューメキシコ州のSceye（スカイ）社が開発した全長約60メートルの太陽光駆動飛行船が日本の沿岸上空約18キロメートルの成層圏に展開し、SoftBankの5Gネットワークを補完する通信テストを実施する。端末への直接データ送信も含まれるこのテストは、HAPS（高高度プラットフォームシステム）技術の実用化に向けた重要な節目となる。 HAPSとは——地上基地局でも衛星でもない第3の選択肢 通信インフラには大きく分けて、地上の基地局と宇宙の衛星という2つのアプローチがある。HAPSはその中間、高度約18〜20キロメートルの成層圏に「準静止」する飛行体を使った第3の選択肢だ。 成層圏は気象の影響をほぼ受けず、風も比較的安定している。低軌道衛星（LEO）は最低軌道でも地表から約200キロメートル離れているが、HAPSはその10分の1以下の距離にある。信号の遅延が小さく送信に必要な電力も少ない。SceyeのCEO、ミッケル・フェスタガール・フランセン氏は「宇宙のような環境を、宇宙に行くコストなしで、軌道にいる複雑さなしで提供できる」と表現する。 Sceye飛行船の技術的なポイント Sceye機はヘリウムで浮力を得る飛行船型で、外皮には軽量かつ反射性の高い特殊ファブリックを採用。太陽光パネルで昼間に発電し、夜間用に電力を蓄積することで24時間稼働する電動ファンを駆動し、風に押されても定位置に戻る「ステーションキーピング」を実現する。2024年のテストフライトでこの能力を実証済みで、2026年春には南米ブラジル沖への飛行で12日間の滞空と合計88時間以上の定点停滞を達成した。 Airbus傘下のAaltoなど複数の企業もHAPS開発を進めており、災害時の通信確保や地表監視など多目的な活用が構想されている。 SoftBankとの日本テスト——何を検証するのか 今回のテストでは、Sceye機が日本の沿岸上空に展開し、専用アンテナでSoftBankの5Gを補完する。注目すべきは「既存デバイスへの直接データ送信」が含まれる点だ。専用の受信端末を必要とせず、手持ちのスマートフォンへの送信が実現すれば、展開コストが大きく下がる可能性がある。将来的には衛星事業者と連携して、基地局整備が難しい離島・山間部・洋上エリアをカバーする役割も期待されている。 実務への影響——インフラ担当者が今から意識すべきこと 災害対策BCP: 地震・台風で地上インフラが壊滅してもHAPSが成層圏に残れば通信を維持できる。自治体・企業のBCP計画に「成層圏通信」を選択肢として加える議論が現実味を帯びてくる。 農業・物流・海洋分野: 離島や沿岸の広域IoTセンサー、船舶通信、農業用ドローンの制御など、これまで衛星しか選択肢のなかった用途でコスト低減が期待できる。 都市部の容量補完: 大規模イベントや災害時の高密度エリアで一時的なキャパシティ増強に使える可能性もある。 ただし、現時点はテスト段階だ。商用展開に向けたコスト構造・航空規制・運用オペレーションには未解決の課題が多い。中長期のインフラロードマップに「選択肢として存在する」と意識する段階であり、今すぐ発注できる技術ではない。 筆者の見解 地上基地局・低軌道衛星・HAPSと、通信インフラのレイヤーが増えていくのは、全体最適を考えると理にかなった方向性だと思う。どれか一つで全てを解決しようとするのではなく、用途・地域・コストに合わせてレイヤーを使い分ける設計が、結果的に堅牢で経済合理性の高いシステムを生む。 日本は地震・台風と向き合い続ける国であり、基幹通信が止まるリスクは常に存在する。成層圏に常駐できる通信プラットフォームは、レジリエンスという観点で非常に魅力的な選択肢になりうる。特にSoftBankのような大手キャリアがテストパートナーになっているという事実は、単なる研究段階を超えて商用化の道筋を探り始めているサインとして受け取るべきだろう。 今回のテストが成功すれば、国内での実証例として業界全体の議論を加速させるはずだ。「空からの通信」が絵空事ではなくなりつつある現実を、インフラ関係者は今から頭に入れておいてほしい。 出典: この記事は This flying solar-powered platform could deliver better internet from the air の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11のシステム全体を過去の状態に丸ごと巻き戻せる新機能「ポイントインタイムリストア（Point-in-time restore）」を正式提供（GA）開始した。Windows 11 24H2以降のHome・Pro・Enterpriseすべてのエディションで利用可能となり、更新プログラムの失敗やドライバー不具合、設定ミスによるシステム障害からの復旧時間を「数時間」から「数分」へ短縮することを目指す機能だ。 ポイントインタイムリストアとは何か ポイントインタイムリストアは、デバイスを過去の特定時点の状態に「まるごと」戻す機能だ。復元対象は以下の通りで、特にローカルのユーザーファイルが含まれる点が重要な特徴となっている。 Windows OS本体 インストール済みアプリケーション システム・アプリの設定 ユーザー設定 ローカルのユーザーファイル 最大の特徴は「自動・定期的なスナップショット取得」だ。デフォルトでは24時間ごとにシステム全体のスナップショットが自動取得されるため、問題が発生した際にはすでに直近のリストアポイントが確保されている。 従来の「システムの復元」との違い 同じくVSS（Volume Shadow Copy Service）ベースで動作するが、ポイントインタイムリストアは現代のPC管理に合わせて設計し直されている。 比較項目 ポイントインタイムリストア システムの復元 リストアポイント取得 定期自動（設定変更可） イベント契機または手動 ユーザーファイル 含む 含まない 保持期間管理 厳密なポリシー管理 無制限（管理なし） UI システム設定に統合 コントロールパネル リモート管理 CSP対応・Intune連携予定 限定的 旧来のSystem Restoreは取得タイミングが不定で、ユーザーファイルが含まれないため「復元したのに作業中のファイルが消えた」という混乱が起きていた。ポイントインタイムリストアはこの欠点を解消している。 GA版の仕様と設定 デフォルト設定 設定項目 デフォルト 変更可能な値 変更可能エディション リストアポイント取得頻度 24時間ごと 4/6/12/16/24時間 Enterprise限定 リストアポイント保持期間 72時間 4/6/12/16/24/72時間 Enterprise限定 最大ディスク使用量 ディスクの2% 最小2GB〜最大50GB Home/Pro/Enterprise 有効/無効のデフォルト 個人向け（ドメイン未参加・管理対象外のHomeおよびPro）: デフォルトでオン 企業管理下（Enterprise・Education・管理対象Pro）: デフォルトでオフ（Windows 11 26H2まで） なお、OSボリュームが200GB未満のデバイスはデフォルトオフとなる点に注意が必要だ。 復元手順 現時点では、復元はWindows RE（回復環境）からのローカル操作のみとなっている。 Windows REで「トラブルシューティング → ポイントインタイムリストア」を選択 BitLockerの回復キーを入力（BitLocker有効デバイスの場合） 復元したい時点のリストアポイントを選択 リスクと制限事項を確認して「続行」 「復元」を選択して実行 Intuneからのリモートトリガーは将来対応予定としてロードマップに明記されている。 ...

AMDが最新グラフィックスドライバー「Radeon Software 26.6.2」（Adrenalin Edition）において、独自のアップスケーリング技術「FidelityFX Super Resolution（FSR）」が正常に動作しなくなる重大な不具合を公式に認めた。影響は多数のWindows PCユーザーに及んでおり、修正ドライバーの提供まで旧バージョンへのロールバックが推奨される状況だ。 FSRとは何か FSR（FidelityFX Super Resolution）は、AMDが開発したゲーム向けアップスケーリング技術だ。低解像度でレンダリングした映像を高品質なアルゴリズムで拡大表示することで、描画負荷を抑えながら高フレームレートを実現する。NVIDIAのDLSSに対抗する技術として位置付けられており、AMDのRadeonシリーズだけでなくNVIDIA GeForceやIntel Arcシリーズでも動作するオープンな設計が特徴だ。 FSR 3以降ではフレーム生成技術も統合されており、多くの最新ゲームタイトルで標準機能として組み込まれている。これが使えなくなると、ゲームのパフォーマンスへの影響は直接的かつ深刻だ。 26.6.2ドライバーで何が起きているか 26.6.2へのアップデート後、FSRを有効にしているゲームで映像が乱れる、フレームレートが大幅に低下する、FSR設定が反映されないといった問題が多数報告されている。AMDは問題の存在を把握・確認しており、修正ドライバーのリリースに向けて対応中であると表明した。 影響はRadeonシリーズを搭載したWindows PC全般で広範囲に確認されており、特定のゲームタイトルや構成に限らず多くの環境で再現している点が深刻さを増している。 回避策と対処法 現時点での推奨される対処法は以下の通りだ： ドライバーをロールバックする: デバイスマネージャーまたはRadeon Softwareから26.6.1以前に戻す。Radeon Softwareには「以前のドライバーに戻す」機能が標準搭載されており、設定画面から数クリックで完了する FSRを一時的に無効化する: ゲーム内設定でFSRをオフにし、ネイティブ解像度でプレイする（パフォーマンスは下がるが動作は安定する） 修正版ドライバーの公開を待つ: AMDの公式チャンネル（AMD.com / Adrenalinのリリースノート）でアナウンスを確認する 日本のゲーマー・エンジニアへの影響 国内でもAMD Radeonシリーズを搭載したゲーミングPCは広く普及しており、コストパフォーマンスを重視するユーザーに特に支持されている。FSRはPC版の多くの主要タイトルで組み込まれているため、26.6.2へのアップデート後に「突然ゲームのパフォーマンスが落ちた」と感じているユーザーはこの不具合を疑うべきだろう。 ゲーム開発・映像制作環境でFSRを活用しているプロフェッショナルも影響を受ける可能性がある。修正ドライバーが出るまでは26.6.2への更新は控えることを強く推奨する。エンタープライズ環境やゲームスタジオでAMD GPUを運用している担当者は、展開前のテスト環境での動作確認フローをあらためて見直す機会にしてほしい。 筆者の見解 今回の件で改めて感じるのは、「最新ドライバーが出たらすぐ当てる」がベストとは限らないという事実だ。 Windowsのセキュリティパッチでさえ「数日様子を見る判断も立派なリスク管理」と言われる時代だが、グラフィックスドライバーはさらにその傾向が強い。ゲームや映像制作のような専門用途では、新機能より安定性が優先されることがほとんどだ。 AMDはここ数年でドライバー品質の改善に着実に取り組んできており、Radeonエコシステムへの信頼は少しずつ積み上がっていた。今回の26.6.2の件はその意味で惜しい一歩後退だが、公式に問題を認め修正対応を明言した対応は適切だ。早期の修正ドライバーリリースで信頼を速やかに回復してほしいところだ。 「アップデートは即座に当てるもの」という慣習を見直し、特に業務クリティカルな環境では「検証してから展開」のフローを徹底することが、今回のような事案への最も現実的な備えになる。 出典: この記事は AMD confirms 26.6.2 FSR driver breaks on many Windows PCs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米テックメディアTom’s GuideのKaycee Hill記者が、iOS 27がApple CarPlayにもたらす5つの大幅アップグレードを詳細に解説する記事を公開した。ワイヤレス接続の安定化からネイティブビデオ対応まで、日常的な使い勝手を根本から変えうる内容が揃っている。 なぜこの発表が注目されるのか Apple CarPlayは国内外問わず普及が進む車載インフォテインメントの標準インターフェースだ。しかし「ワイヤレス接続が頻繁に切れる」「音楽操作するとナビ画面が隠れる」「トンネルでGPSが迷走する」といった不満は長年のユーザー共通の悩みだった。iOS 27はこれらの課題に正面から向き合った改善パッケージとして注目に値する。 海外レビューのポイント：5つの新機能 1. ワイヤレスCarPlayの安定性が向上 Tom’s Guideの解説によると、iOS 27ではiPhoneと車載システム間の通信ロジックが刷新され、接続の維持がより安定するという。外観の変化はないが、万が一切断が発生した場合も自動的に素早く再接続される仕組みが組み込まれる。「すべてのグリッチを完全に解消するわけではないが、毎日の通勤でのイライラを大幅に減らせる」とHill記者は評価している。 2. ナビ画面上に常駐する音楽ミニプレーヤー これまでCarPlayで音楽を操作しようとすると、アプリ画面が地図を完全に覆ってしまうという問題があった。iOS 27では地図上に浮かぶ「オーディオミニプレーヤー」が常駐し、Apple Music・Spotify・ポッドキャスト・オーディオブックを問わず、ナビを見ながら一時停止やスキップが可能になる。同乗者が音楽を操作しやすくなる点も実用的な改善だ。 3. トンネル・地下駐車場でのGPS精度向上 GPS信号が途絶えた際に、iPhoneの内蔵センサー（加速度計・ジャイロ等）を用いた推測航法（デッドレコニング）が活用されるようになる。同記事によれば、Apple Maps・Google Maps・Wazeの全主要ナビアプリでこの恩恵を受けられるという。 4. ポッドキャスト・オーディオブックのスクラビング操作 「現在再生中」画面にタッチ操作で任意の再生位置に移動できるスクラビングスライダーが追加される。スポンサー読みを飛ばしたい、気に入った一節を聞き返したいといったニーズに、スマートフォンを手に取らず対応できるようになる。 5. ビデオ視聴がネイティブ対応へ Tom’s Guideによると、iOS 26でCarPlayへのビデオ対応が始まったものの、AirPlayキャスト経由の限定的なものに留まっていた。iOS 27ではネイティブ対応に昇格し、より柔軟な動画再生が可能になる見込みだ。安全上の観点から駐車中のみの利用に限定される。 日本市場での注目点 iOS 27は2026年秋のリリースが予定されており、CarPlayのアップデートも既存iPhoneへ順次配信される見通しだ。追加費用は不要で、CarPlay対応車載システムを持つ国内ユーザーがそのまま恩恵を受けられる。 特にGPS精度の改善は、地下を走る路線や高層ビルが密集する都市部を日常的に運転するドライバーにとって直接的なメリットとなりうる。東京・大阪・名古屋などの都市部ドライバーには実感しやすい改善点といえる。 国内でCarPlay対応の社外カーナビを導入済みのユーザーも対象となるため、カーオーディオ市場全体への波及効果も大きい。 筆者の見解 AppleがiOS 27でCarPlayに手を入れてきた5つの改善は、いずれも「使っている人が毎日感じている不満」に直球で応える内容だ。ワイヤレス接続の安定化もGPS精度の向上も、地味に見えて日常使いの体験を底上げする実直な改善であり、こういった「当たり前をきちんと機能させる」アップデートの価値は高い。 音楽ミニプレーヤーの常駐化は、ナビと音楽を同時に使いたいというドライバーの素朴な要求に応えたものだ。スクラビングスライダーの追加も同様で、「こんなことも今までできなかったのか」と思わせる類の機能だが、使い始めれば手放せなくなる。 CarPlayが単なるスマートフォンの画面ミラーリングではなく、車内体験を一元管理するプラットフォームとして着実に成熟しつつあることを、今回の改善群は示している。ネイティブビデオ対応が今後どこまで拡張されるかも含め、次のアップデートサイクルを注視したい。 出典: この記事は What these 5 new iOS 27 Apple CarPlay features mean for your car の内容をもとに、筆者の見解を加えて独自に執筆したものです。

マーケットインテリジェンスプラットフォームのKlueは2026年6月19日、同社の統合インフラを標的とした不正アクセスを受け、顧客のSalesforce環境に接続するOAuthトークンが窃取されたことを公式に認めた。恐喝グループ「Icarus」が犯行を声明し、被害組織のリストはセキュリティ企業を含む複数の著名ITベンダーに広がっている。 何が起きたか Klue CEOのJason Smith氏は6月12日に統合インフラの一部で不正活動を検知したことを明らかにした。調査の結果、攻撃者はレガシー認証情報（旧来の認証情報）から侵入し、KlueとSalesforceなどサードパーティプラットフォームを接続するOAuthトークンを入手。これを使ってKlueと連携している顧客のSalesforce環境に直接アクセスした。 Klueプラットフォーム内に直接保存されている顧客コンテンツへの影響はないとしているが、連携先を経由した被害は深刻な規模に達した。 攻撃の手口：Salesforce APIへの大規模クエリ セキュリティ企業ReliaQuestとHuntressが独立した調査でこの攻撃の詳細を明らかにした。攻撃者はKlue連携に紐付いたOAuth認証情報を使ってSalesforce APIを長時間にわたってクエリし、Pythonスクリプトを駆使して大量データを抽出した。 Huntress自身もKlue経由でSalesforceが侵害されており、ビジネスコンタクト情報・営業コミュニケーション・価格情報などが盗まれたことを認めている。 被害組織が拡大 Icarusはデータリークサイトで犯行を認め、被害組織に対してSession Messengerでの接触を要求している。現在までに被害を公表した組織は以下のとおりだ。 Recorded Future（脅威インテリジェンス企業） Tanium（エンドポイント管理） Jamf（Appleデバイス管理） Sprout Social（SNS管理） Gong（セールスインテリジェンス） Insurity（保険業向けソフトウェア） Huntress（セキュリティ企業） 各社ともSalesforceインスタンスのデータが盗まれたが、自社プラットフォームや決済情報には影響がないと説明している。また、盗まれたビジネスコンタクト情報を使ったフィッシング・ソーシャルエンジニアリング攻撃への警戒を呼びかけている。 KlueはCrowdStrikeと連携して対応にあたり、影響を受けた認証情報とトークンを即座に失効させ、不正コードを削除、当局へ通報済みだ。 日本のIT現場への影響 SaaS間連携を積極的に進めてきた組織ほど、今回のような「連携サービスを経由した横断的な侵害」のリスクを抱えている。日本企業でも以下のチェックを今すぐ行うべきだ。 OAuthアプリ・Connected Appsの棚卸し — 退職者が設定した、または試験的に設定したまま放置された連携はないか 統合サービスの認証情報ローテーション — Klueのような統合サービスが使う認証情報を定期的に更新しているか Salesforce APIアクセスログの監視 — 通常と異なるクエリパターン（大量・長時間・Pythonスクリプト）を検知できるか 連携スコープの最小権限確認 — サードパーティ連携に必要以上の権限を与えていないか 筆者の見解 今回の攻撃で最も注目すべきは、侵害の入口が「レガシー認証情報」だった点だ。ゼロトラストアーキテクチャをどれほど丁寧に構築しても、古い認証情報が一本残っていれば攻撃者はそこから入ってくる。「今動いているから大丈夫」は通用しない——これは何度でも繰り返す価値がある教訓だ。 もう一つの核心はNon-Human Identity（NHI）の管理だ。OAuthトークン・APIキー・サービスアカウントといった「人間ではない主体」のアイデンティティは、人間のアカウント管理に比べて圧倒的に後回しにされやすい。今回のKlueのケースはまさにその典型だ。SaaS連携のNHI管理こそが、業務自動化・効率化のボトルネックを解消しながら安全を保つ鍵になる。 ゼロトラストの観点では、常時アクセス権を持つ統合サービスの認証情報こそが最大のリスクだ。Just-In-Time（JIT）アクセスの考え方をサービス間連携にも適用し、必要なときだけ権限を与え、使い終わったら失効させる仕組みが求められる。VPNの時代が終わりを告げているのと同様に、「設定したらずっと有効」なOAuth連携の運用も見直しどきだ。 日本の多くの企業ではSaaS導入が先行し、連携管理が追いついていないケースが目立つ。今回の事案を「海外の話」で終わらせず、自社のSaaS連携を棚卸しするきっかけにしてほしい。 出典: この記事は Klue OAuth breach victim list grows as Icarus hackers claim attack の内容をもとに、筆者の見解を加えて独自に執筆したものです。