Windows

Microsoftは、TypeScriptの最新メジャーバージョン「TypeScript 7.0」を正式にリリースした。最大の目玉は、これまでTypeScript自身（JavaScript）で書かれていたコンパイラを、Go言語で全面的に書き直したことだ。この移植により、大規模プロジェクトのビルド時間は最大12倍、エディタ上の型チェックも大幅に高速化し、メモリ使用量も大きく削減されている。 コンパイラをゼロから書き直した理由 従来のtscはNode.js上で動くJavaScript実装で、プロジェクトが大きくなるほど型チェックに数十秒から数分かかることも珍しくなく、開発体験上のボトルネックになっていた。Microsoftはこの問題に対処するため、コンパイラをGoで書き直す取り組み（開発コード名「tsgo」）を進めてきており、TypeScript 7.0はその成果を正式に取り込んだリリースとなる。今後はネイティブバイナリとして配布される新コンパイラがデフォルトになる。 主な性能改善 ビルド速度が最大12倍高速化（プロジェクト規模やハードウェア構成に依存） マルチコアを活用した並列型チェックに対応 メモリ使用量の大幅な削減により、巨大なmonorepoでもメモリ不足になりにくい VS Codeなどの言語サーバーの応答性が向上し、入力中の補完やエラー表示が速くなる 実務への影響 日本のエンジニアやIT管理者にとっては、CI/CDのビルド時間短縮がそのままCI実行コストの削減や開発サイクルの短縮につながる。特にフロントエンドの大規模SPAや、Nx・Turborepoなどでmonorepo構成を運用している現場ほど恩恵は大きいはずだ。 一方で、コンパイラがネイティブバイナリ化されることに伴い、一部のtscプラグインやカスタムトランスフォーマーとの互換性は事前に確認しておきたい。CI環境がOS・アーキテクチャ別のバイナリを問題なく取得できるか、社内のセキュリティスキャンやアーティファクトミラーの登録が必要かどうかも、移行前にチェックしておくべきポイントだ。とはいえ、多くのプロジェクトは「package.json更新→ローカルビルド確認→CI適用」という標準的なアップグレード手順で恩恵を受けられる設計になっている。 筆者の見解 TypeScriptコンパイラのGo移植は、派手さはないが開発現場に確実に効いてくる改善だと感じる。日々の型チェック待ち時間やCIのビルド時間は、エンジニアの体感生産性に直結する部分であり、そこを地道に磨き込んだ今回の取り組みは素直に評価したい。Microsoftには、こうした基盤への投資をもっと前面に出してアピールしてほしいとすら思う。 ただし、コンパイラをネイティブバイナリとして配布する以上、社内のCI環境やセキュリティポリシーとの整合性確認は避けて通れない。標準的なアップグレード手順を踏めば多くの現場が恩恵を受けられる設計になっている点は好感が持てるし、こうした王道の改善を地道に積み重ねる姿勢を、今後も期待したい。 出典: この記事は Microsoft releases TypeScript 7.0, and it’s 10x faster than the previous version の内容をもとに、筆者の見解を加えて独自に執筆したものです。

リード文 Microsoftは2026年7月14日のセキュリティ更新で、Windows Server ドメインコントローラーにおけるKerberos認証のRC4ハードニングを最終フェーズへ進める。これまで移行期間として提供されてきた「Audit Mode(監査モード)」が廃止され、「Enforcement Mode(強制モード)」だけが残ることで、レガシーな暗号化方式RC4への依存を断ち切る対応が事実上完了する。未対応の環境では認証エラーが発生するリスクがある。 Kerberos RC4ハードニングとは何か Kerberos認証では、チケットやPAC(Privilege Attribute Certificate)の署名にRC4-HMACという古い暗号化方式が長らく使われ続けてきた。RC4はAES(Advanced Encryption Standard)に比べて強度が低く、多くのセキュリティガイドラインで既に非推奨とされている。Microsoftは2022年11月のセキュリティ更新(CVE-2022-37966関連)以降、段階的にRC4依存を排除する取り組みを進めてきた。 具体的には、レジストリキーで制御される3段階の移行スケジュールが組まれていた。 Disabled(デフォルト。従来どおりの挙動を維持) Audit(RC4の使用を検知してイベントログに記録するが、通信そのものはブロックしない) Enforced(RC4を使った署名やチケットを強制的に拒否する) 今回の7月更新は、この最終段階であるEnforcedだけを残し、Audit Modeという「猶予期間」の選択肢そのものを取り除く更新だ。 何が起きるのか これまでAudit Modeで運用していた環境、あるいは特に何も設定していなかった環境は、7月14日の更新適用後にドメインコントローラーの挙動が実質的にEnforcement Mode相当へ切り替わる。RC4しかサポートしないレガシーなクライアントや古いネットワーク機器、サードパーティ製のKerberos実装などが残っている場合、認証エラーが発生する可能性がある。 実務への影響 日本企業のActive Directory環境では、長年稼働し続けている古いプリントサーバーや、基幹システム連携用のサービスアカウントなど、RC4しか対応していない「動いているから触っていない」機器・アカウントが今も残っているケースは珍しくない。IT管理者は更新適用前に、次の点を確認しておきたい。 ドメインコントローラーのKDCイベントログでRC4の使用状況を洗い出す サービスアカウント・コンピューターアカウントのmsDS-SupportedEncryptionTypes属性でAES対応状況を確認する レガシー機器・OSが残っている場合は、更新前にAES256対応へ切り替えるか、代替の認証手段を検討する Auditログを一度も確認しないまま7月更新を適用すると、業務時間中に認証障害という形でしっぺ返しを受ける可能性が高い。 筆者の見解 セキュリティの観点では、Microsoftの今回の判断は正しい方向だと思う。RC4のような古い暗号方式を「動いているから」という理由でいつまでも残しておくのは、認証基盤における技術的負債そのものだ。SID重複問題のときもそうだったが、「今動いているから大丈夫」という発想は、いずれ必ずどこかで牙を剥く。移行期限を明確に区切り、Audit Modeという「言い訳」を制度的に無くしてしまうやり方は、腰の重い現場を動かすために必要な荒療治だと感じる。 Microsoftを応援する立場から言えば、こうした地味だが重要な足元固めをきちんと続けていることは評価したい。派手な機能追加の話題に隠れがちだが、Active Directoryのような基盤部分でのハードニングこそ、エンタープライズの信頼を支えている部分だ。一方で、この手の変更は事前告知から実際の強制適用まで時間が空くぶん、現場が気づかないまま期限だけが過ぎてしまいがちでもある。せっかく正しい方向へ舵を切っているのだから、管理者向けの警告表示やレポート機能をもう一歩踏み込んで用意し、「気づいたら詰んでいた」という事故を減らす工夫にも力を入れてほしいところだ。 出典: この記事は Windows June 2026 Recap: 26H2 Testing, Printing Changes, Kerberos RC4 and More の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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は2026年7月、後継メールクライアント「New Outlook」向けに、定型文・定型フレーズを保存して繰り返し使い回せる「Quick Parts(クイックパーツ)」機能の全展開を開始した。Outlook ClassicやMicrosoft Wordには長年搭載されてきた定番機能で、New Outlookへの実装は2026年2月から段階的に進められていたが、ここへきてようやく全ユーザーに行き渡った形だ。 Quick Partsとは何か メール作成中や返信時に、再利用したい文章の一部を選択して「挿入」タブから「Quick Parts」として登録すると、以降のメールで同じ内容をワンクリックで呼び出せるようになる。よく使う挨拶文、アクセス案内、問い合わせへの定型回答などをテンプレート化しておける機能で、これまでNew Outlookでは「都度コピー&ペースト」か「テンプレート機能で代用」するしかなかった。Microsoftによれば、近くこの登録操作は右クリックメニューからも行えるようになる予定で、Outlook Classic並みの手軽さに近づく見込みだ。 New Outlookで進む機能追加ラッシュ Quick Partsは単発の追加ではなく、New Outlook強化の一環だ。今後数か月で以下の機能も投入される予定という。 統合受信トレイ(Unified Inbox): Gmailの「すべての受信トレイ」のように、複数アカウントのメールを1画面に集約し、削除・移動といった操作も統合ビューから行える 高度な差し込み印刷(Mail Merge): 宛先ごとに氏名や挨拶文を個別化して一括送信 ローカルOfficeファイルの送信: 既に開いているファイルをコピーとして添付可能に 通知のグルーピング: 複数の新着メール通知を1つにまとめ、Windows上の通知過多を緩和 一方で、通知経由でメールを開くと表示まで約10秒かかるという以前から指摘されている遅延バグは、今回のアップデートでも解消されていない。 実務への影響 Quick Parts自体は地味な機能に見えるが、サポート窓口・営業・社内ヘルプデスクなど定型メールを大量にさばく現場では、作業時間の削減に直結する実用機能だ。日本企業では敬語表現やメールの言い回しを組織内で統一したい場面が多く、Quick Partsのテンプレートを部署単位で共有する運用ルールを整備すれば、新人教育や表記ゆれ防止にも効果が見込める。 IT管理者にとっては、Outlook ClassicからNew Outlookへの移行を検討する際の判断材料が一つ増えたことになる。ただし前述の起動遅延など基本動作の不満が残っている以上、全社一斉移行を急ぐのではなく、まずは一部部署でのパイロット運用を通じて実際の使用感を確認してから展開判断をするのが堅実だろう。 筆者の見解 Quick Parts自体はOutlook Classicで20年近く前から当たり前にあった機能で、New Outlookが2026年になってようやく追いついたという点には正直もったいなさを感じる。「軽量で高速」を謳って移行を推進してきた以上、こうした定番機能は後回しにせず最初から用意しておくべきだったはずだ。 とはいえ、Unified InboxやMail MergeといったOutlook Classicにすらなかった機能を並行して開発している姿勢は評価したい。単なる旧機能の移植で終わらせず、New Outlookならではの価値を積み上げようとする方向性自体は正しい。 気になるのは、通知からメールを開くまで約10秒かかるという基本動作の遅延がいまだに放置されている点だ。機能を積み増す前に、まず「メールを開く」という最も基本的な体験を磨き込んでほしい。長年Microsoft製品を使い、応援してきた立場から言えば、こうした基本体験の綻びこそユーザーの信頼を静かに削っていく。New Outlookへの本格移行を進めるなら、機能拡充と並行して土台の作り込みにも本気で向き合ってほしいところだ。 出典: この記事は Microsoft’s New Outlook releases Email snippets, a Outlook Classic feature it should have shipped with の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft SharePoint Serverの深刻なリモートコード実行（RCE）脆弱性「CVE-2026-45659」について、米CISA（サイバーセキュリティ・インフラセキュリティ庁）は2026年7月1日、実際の悪用を確認したとして既知悪用脆弱性（KEV）カタログに追加した。米連邦政府機関（FCEB）には2026年7月4日までのパッチ適用が義務付けられており、対象組織は即座の対応を迫られている。 脆弱性の概要：認証済みユーザーでも突破される CVE-2026-45659はCVSSスコア8.8の高深刻度脆弱性で、信頼できないデータのデシリアライゼーション（逆シリアル化）処理に起因する。対象はSharePoint Server Subscription Edition、SharePoint Server 2019、SharePoint Enterprise Server 2016というオンプレミス版で、クラウドのSharePoint Onlineは影響を受けない。 注目すべきは攻撃条件の低さだ。管理者権限などの高い権限は不要で、「Site Member」レベルの最小限の権限を持つ認証済みユーザーであれば、リモートでコードを実行できてしまう。つまり社内ネットワークにアクセスできる一般社員のアカウントが一つでも侵害されれば、SharePointサーバー全体を掌握される危険がある。 Microsoftは2026年5月の月例パッチでこの脆弱性を修正済みだった。しかしパッチ公開時点では「悪用される可能性は低い（Exploitation Less Likely）」と評価しており、優先度を下げて対応した組織も少なくなかったとみられる。それが今回、実際の悪用が確認されCISAのKEV入りとなったことで、当初の評価が覆った形だ。 実務への影響 日本国内でもオンプレミスのSharePoint Serverは、社内ポータルやドキュメント管理基盤として大企業を中心に根強く使われている。SharePoint Onlineへの移行が進んでいない組織は、まず自社環境が対象バージョンに該当するか、2026年5月のセキュリティ更新プログラムが適用済みかを即座に確認すべきだ。 今回の教訓は2つある。一つは、ベンダーの初期評価（Exploitation Less Likely等）を鵜呑みにせず、月例パッチは原則として速やかに適用する運用を徹底すること。もう一つは、「認証済みかつ最小権限のユーザー」だけで致命的な攻撃が成立する事実が示す通り、社内アカウントであっても無条件に信頼してはならないという点だ。Just-In-Timeアクセスや定期的な権限棚卸しなど、常時アクセス権を極力持たせない運用が、こうした脆弱性の実害を減らす現実的な防御になる。インターネットに直接公開されたオンプレミスSharePointがあれば、WAFや外部からのアクセス制限も合わせて見直したい。 筆者の見解 正直なところ、パッチ公開時点で「悪用される可能性は低い」としていた評価が、2カ月足らずで実際の悪用確認・KEV入りに至ったのは、Microsoftの脆弱性評価プロセスとして改善の余地があると感じる。IT管理者はこの評価を頼りにパッチ適用の優先順位を決めるだけに、評価が外れると現場の判断そのものが揺らいでしまう。オンプレミスSharePointは今も多くの日本企業の情報基盤を支えている製品であり、応援する立場から言えば、ここは慎重側に倒した評価基準にしてほしいところだ。 一方で、今回のCVEが突きつけているのは製品固有の問題だけではない。「認証済みの一般ユーザー権限」だけで重大な侵害が成立するという構造は、ゼロトラストの本質——境界内にいることや認証済みであることを無条件の信頼材料にしない——がなぜ必要かを改めて示している。パッチ適用はもちろん急務だが、それと並行して、平時から標準アカウントに与える権限を最小化し、異常なアクセスを検知できる仕組みを整えておくことが、次の同種インシデントへの本当の備えになる。 出典: この記事は SharePoint RCE CVE-2026-45659 Added to CISA KEV After Active Exploitation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたのか 米連邦捜査局(FBI)は、Googleの協力を得て、住宅用プロキシサービス大手「NetNut」のドメインを差し押さえたと報じられた。押収の理由は、NetNutのインフラが「Popa」と呼ばれるボットネットと結びついていたことにある。Neowinの報道によれば、このボットネットは数百万台規模のデバイスに影響を及ぼしていたとされる。 住宅用プロキシとボットネットの「悪魔合体」 住宅用プロキシサービスとは、一般家庭のインターネット回線のIPアドレスを経由して通信を行う仕組みを指す。本来はマーケティング調査や価格比較、広告の不正検知など正当な用途で使われるサービスだが、「一般家庭のIPアドレスに見える」という性質は、サイバー犯罪者にとっても好都合な隠れ蓑になる。 過去に米国で摘発された「911 S5」のように、マルウェアに感染したデバイスをひそかに「出口ノード」として使い、正規の住宅用プロキシに見せかけて第三者に販売する手口はたびたび報告されてきた。今回のNetNutとPopaボットネットの関係も、同様の構図であった可能性が高い。仮にそうだとすれば、感染に気づかないまま自宅のルーターやPCが犯罪インフラの一部として使われていた利用者が、世界中に数百万人単位で存在していたことになる。 法執行機関単独ではドメインやインフラの技術的な差し押さえは難しく、Googleのような大手プラットフォーマーの技術支援・情報提供が不可欠になっている点も見逃せない。近年のボットネット摘発では、こうした「官民連携」がもはや当たり前になりつつある。 実務への影響 日本のIT管理者にとっても他人事ではない。住宅用プロキシ経由の通信は、一般利用者の正規アクセスと見分けがつきにくく、IPレピュテーションやジオIPブロックだけに頼ったアクセス制御は簡単にすり抜けられる。クレデンシャルスタッフィングやアカウント乗っ取りの試行が、社内から見て「普通の日本国内の家庭用回線」から来ているように見えるケースは、今後さらに増えるだろう。 実務的には次のような対応が現実的だ。 ログ分析で、同一アカウントに対する短時間・多地点からのログイン試行を監視する IPアドレスの評判情報だけでなく、デバイスフィンガープリントや行動パターンによる異常検知を併用する 自社が業務でNetNutのような住宅用プロキシサービスを利用している場合、契約先のセキュリティ体制やコンプライアンスを再確認する 筆者の見解 セキュリティは正直あまり好きな分野ではない。細かい話が多いからだ。それでも今回のような話には強く興味を引かれる。理由は単純で、これは「IPアドレスを信用する」という発想そのものの限界を示す事例だからだ。 筆者はかねてゼロトラストの推進派で、VPNのような境界防御にはあまり期待していない。今回のケースは、まさにその立場を裏付けるものだと感じる。攻撃者が住宅用プロキシを悪用すれば、企業の外形的なIP制御などいくらでもすり抜けられてしまう。守るべきはネットワークの出入り口ではなく、ネットワーク層・認証層・認可層の3層であるという原則に、改めて説得力が増したと言えるだろう。 日本の大企業では、古い境界防御モデルと中途半端なゼロトラストが混在し、かえって複雑で脆弱な構成になっているケースを見かける。今回のような摘発のニュースをきっかけに、自社のアクセス制御が「IPアドレスが日本国内なら安全」という前提に寄りかかっていないか、あらためて点検する機会にしてほしい。FBIとGoogleの連携による摘発は歓迎すべき動きであり、今後も同様の官民連携によるボットネット撲滅が進むことを期待したい。 出典: この記事は FBI seizes NetNut domain with Google’s help after links found to Popa botnet の内容をもとに、筆者の見解を加えて独自に執筆したものです。

リード 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は現在テスト中のWindows 11アップデートで、タスクバー自体の高さを変更できる新しい「タスクバーサイズ」設定を追加した。従来のアイコンサイズ変更とは独立した制御が可能になり、結果としてWindows 10にはなかった2段階のカスタマイズ機能が実現しつつある。 Windows 10からWindows 11へ——失われた機能と段階的な復活 Windows 10には「小さいタスクバーボタンを使う」というシンプルなトグルが存在し、タスクバー全体をコンパクトに表示する機能が備わっていた。しかしWindows 11でMicrosoftはタスクバーをゼロから書き直した際、この機能を削除。「リリース初日にWindows 10のすべての機能を搭載するわけではない」と説明し、批判を受けながらも当初は対応しなかった。 昨年になってようやく「小さいアプリアイコンを表示する」オプションが追加されたが、これはあくまでアイコンのサイズを縮小するだけで、タスクバー自体の高さは変わらなかった。「アイコンが小さくなっても、帯の高さが変わらなければ意味がない」という声はユーザーコミュニティで根強かった。 2つのコントロールが共存する新設計 今回テスターに公開されたビルドでは、タスクバーのパーソナライズ設定に「タスクバーサイズ」という新項目が追加された。「小」を選択するとタスクバー全体が細くなり、それに伴ってアイコンも小さくなる。 一方、既存の「小さいアプリアイコンを表示する」オプションは引き続き独立して機能する。タスクバーの高さはそのままに、アイコンだけを縮小したい場合——たとえばタスクバーが混雑してきたときに自動的にアイコンを小さくする「タスクバーがいっぱいのとき」モードなど——に使い分けられる。 この2つを組み合わせることで、Windows 10の単一トグルよりも細かい制御が可能になる。「タスクバーサイズを小に設定した上で、アイコンをさらに縮小する」という使い方もできる設計だ。 タスクバー・スタートメニュー刷新の一環 この機能は単体のマイナーチェンジではなく、Windows 11のタスクバーとスタートメニューに10以上の新機能を追加する大きな取り組みの一部だ。注目すべき変更点をまとめると： タスクバーの移動機能（プレビュー中）: Windows 10同様、タスクバーを画面の任意の辺に移動可能に スタートメニューのサイズ変更: 「ダイナミック」から「小」へのサイズ変更が可能に スタートメニューの広告削除: 「おすすめ」を「最近使ったもの」に改名し、Storeとの連携広告を排除する方向で開発中 実務への影響——マルチモニター環境や縦型タスクバー活用に期待 これらの変更が日本のエンタープライズ環境にもたらす実際の恩恵を考えてみよう。 マルチモニター環境のユーザー: 画面を最大限に使いたい環境では、タスクバーの高さを最小限に抑えたいニーズは根強い。タスクバーサイズを「小」にすることで、縦方向のピクセルを数十ピクセル単位で節約できる。 ラップトップユーザー: 13〜14インチ画面でのドキュメント作業では、タスクバーの占有領域が体感に直結する。小型化オプションの恩恵が最も大きいのはこの層だろう。 IT管理者: まだテスト段階のため、本番環境への展開は数ヶ月先になる見込み。ただし将来的なグループポリシーや構成プロファイルでの制御可否は確認しておく価値がある。Windows 11 24H2以降の管理ポリシーの変化は引き続き追跡が必要だ。 エンドユーザーサポート担当: 設定の選択肢が増えることで「タスクバーが変になった」という問い合わせが増える可能性もある。UIの変化を事前に把握しておくと対応がスムーズになる。 筆者の見解 率直に言えば、タスクバーのサイズ変更はWindows 10の時点で当然あるべき機能だった。それが消え、5年かけて段階的に戻ってくるという経緯は、Windows 11の出発点がいかに「見切り発車」だったかを改めて示している。 ただ、今回の設計を見ると話は少し違う。単に元に戻すのではなく、「タスクバー高さ」と「アイコンサイズ」を独立して制御できる2軸設計にしてきた点は、Windows 10より進歩している。フィードバックを受け止めて、単純な復元以上のものに仕上げようとしている姿勢は評価したい。 タスクバーの移動機能、スタートメニューの広告削除と合わせると、Windows 11はようやく「使いやすいOS」として本来の水準に近づこうとしている。Microsoftにはこの調子でユーザーの声に耳を傾け続けてほしい——細かいUI改善の積み重ねが、長期的な信頼につながるのだから。 Windowsを「細かく追う」必要性は確かに薄れているが、エンドユーザーが毎日触れるタスクバーとスタートメニューの改善は例外だ。ここの完成度がOSへの第一印象を決める。 出典: この記事は Microsoft reveals Windows 11 taskbar feature that Windows 10 never had, two ways to shrink in testing の内容をもとに、筆者の見解を加えて独自に執筆したものです。

トランプ前大統領が「アメリカの価値観」を掲げて推進するスマートフォンでさえ、その製造の実態は中国に依存している——この一事実が、スマートフォンの米国内完全生産がいかに困難かを端的に示している。単なるコストの問題ではなく、数十年にわたって積み上げられた製造エコシステムの「厚み」こそが、政治的意志だけでは覆せない壁となっている。 「近くにあるから成り立つ」製造エコシステムの集積効果 現代のスマートフォン1台には、数百から数千種類の部品が使われている。プロセッサ、ディスプレイ、カメラモジュール、バッテリー、各種センサー、回路基板——これらのほぼすべてが、中国・台湾・韓国を中心としたアジアの製造拠点に集約されている。 重要なのは「製造エコシステムの集積効果」だ。部品メーカーA社の工場の隣に組立メーカーB社があり、その近くに検査機器メーカーC社がある。さらに周辺には数十年の現場経験を持つ熟練工が集まっている。この生態系は、1980年代から政府の補助金政策と市場の力が重なって形成されたもので、1〜2年で移植できるものではない。 米国でこれを再現しようとすれば、まず土地と工場を建て、機械を導入し、そして最も難しい「熟練した製造人材」を一から育成しなければならない。業界推計では、この体制を本格稼働させるだけで10〜20年かかるとも言われている。 原材料の段階から依存している：レアアース問題 スマートフォンには希少金属（レアアース）が不可欠だ。振動モーターや小型スピーカーにはネオジム、タッチパネル（ITO）にはインジウムが使われる。現在、中国はレアアースの採掘・精製において世界シェアの60〜80%以上を占める。 米国内でのレアアース採掘自体は技術的には可能だが、精製施設がほぼ存在しない。精製技術は中国が長年の投資で圧倒的な優位を確立しており、つまり「原材料」の段階からすでに依存構造が生まれているのだ。製造拠点を変えようとしても、出発点からすでに詰まっている。 Appleの挑戦と現実：インド生産でも部品は中国から Appleは2019年にMac Proの一部を米国テキサス州で生産し始めたが、これはデスクトップPCという相対的にシンプルな製品での話だ。iPhoneとなると事情はまったく異なる。 Appleは近年、中国への依存度を下げるためにインドでの生産拡大を積極的に進めている。しかしインドの工場でさえ、部品の多くは依然として中国から調達している。製造地を変えても、部品調達の依存は変わらない。 Foxconn（鴻海）の中国工場ではiPhoneの最終組立に数十万人規模の作業員が従事している。米国でこの規模の組立ラインを稼働させた場合、iPhone1台あたりの製造コストは現在の3〜5倍に跳ね上がるとの試算もある。最終的に消費者への販売価格が3,000ドルを超えるスマートフォンを誰が買うか——これが「メイド・イン・USA」の現実だ。 実務への影響：日本のIT管理者が今考えるべきこと 経済安全保障とIT調達の交差点 米中テクノロジー競争の激化は、日本企業・政府機関のIT調達にも直接影響を及ぼしている。経済安全保障推進法では半導体・電子部品のサプライチェーン強靱化が定められており、スマートフォンそのものは直接対象外でも、その部品調達は対象と隣接する問題だ。 TSMCが熊本に建設した工場は、半導体製造の地政学リスク分散という観点から重要な意義を持つ。スマートフォン向けとはいえ、国内で高度半導体製造が可能な体制が整いつつあることは評価できる。 IT管理者が意識すべき実務ポイント 製造地と設計地を分けて評価する：デバイスの設計（知的財産）が米国企業であっても、製造は中国というケースが大半だ。セキュリティ評価は「どこで設計されたか」「どこで製造されたか」「どんなソフトウェアが載っているか」の三軸で行う ハードウェアサプライチェーン攻撃への備え：スマートフォンに限らず、ネットワーク機器・IoTデバイスでも同様の問題が存在する。調達基準にNIAP等のセキュリティ認証を含めることを検討する MDMによるソフトウェア層の管理強化：製造地リスクよりも、プリインストールアプリや製造時のソフトウェア改ざんリスクの方が実務上は対処しやすい。MDMによる検証とポリシー強制を優先する 筆者の見解 「メイド・イン・USA」は政治的には力強いスローガンだが、スマートフォン製造の現実は数十年の経済合理性が作り上げた構造だ。これを短期間で変えようとすれば、膨大なコストと時間が必要になる。 より注目すべきは、この問題がスマートフォン単体の話ではないことだ。AIサーバー向けGPU、産業用IoT機器、データセンターのネットワーク機器——すべてが同じ構造上の問題を抱えている。製造エコシステムの再構築は、国家レベルの長期的な産業政策なしには実現しない。 日本の立場で考えると、TSMC熊本工場の誘致はその意味で正しい方向だと思う。ただ、半導体の製造拠点ができたとしても、それを使った製品の組立・エコシステム構築はまた別の課題だ。一足飛びにはいかない。 「製造回帰」の議論はこれからも続くだろう。重要なのは政治的スローガンではなく、「どこに投資すれば最も効果的か」という冷静な分析だ。少なくとも、「アメリカの価値観」を掲げたスマートフォンが中国製という現実は、この問いの難しさを如実に示している。 出典: この記事は Why it’s almost impossible to produce a smartphone in the United States の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11の2026年6月オプション更新プログラム（KB5095093 / Build 26200.8737）を通じて、File Explorerのパフォーマンスを根本的に改善するアップデートを全ユーザー向けに展開し始めた。今回の改善はプリロード（バックグラウンドでの事前起動）に依存しない、コードレベルの実質的な高速化であることが特徴だ。 「Homeタブ」が原因だった File Explorerの動作が遅い原因として長らく指摘されてきたのが、「Home」タブの処理負荷だ。従来のWindows 10時代の「PC」タブと異なり、Windows 11のHomeタブはクイックアクセスや最近使ったファイル等の情報を表示するために余分な処理が走っており、これがエクスプローラー全体の起動遅延を引き起こしていた。 今回のKB5095093では、このHomeタブの処理が最適化され、起動速度が明確に改善されたとMicrosoftがリリースノートで公式に認めている。 今回の改善点まとめ エクスプローラーの起動速度向上（Homeタブ処理の最適化が主因） アドレスバーの改善：入力補完の表示が速くなり、信頼性も向上 ディスクイメージのマウント時の無応答問題を修正：ISOファイル等のマウント中にエクスプローラーが固まる問題が解消 ファイル・フォルダーのリネームバグ修正：フォルダービューで名前変更時にテキストが意図せず選択される問題、大文字小文字のみの変更が反映されないバグを修正 アドレスバーでのダブルバックスラッシュ・引用符を使ったナビゲーションをサポート このアップデートはオプション扱いのため現時点では自動適用されないが、2026年7月の月例更新に組み込まれる予定だ。 「プリロード」との違い Microsoftはこれとは別に、File Explorerをバックグラウンドで常駐させて見かけ上の起動を速くする「プリロード」機能をInsider Programでテスト中だ。プリロードは確かに体感速度を改善するが、あくまでも「すでに起動している状態を維持するだけ」であり、処理の重さ自体は変わらない。 今回の改善はそれとは異なり、エクスプローラーのコード自体を軽くする根本的なアプローチだ。プリロードが「速く見せる」工夫であるとすれば、今回のアップデートは「実際に速くなった」変更と言える。 右クリックメニューの高速化も計画中 Microsoftはさらに、右クリックのコンテキストメニューの表示速度を大幅に改善するアップデートも準備中だ。現状、「Paint.NETで編集」「Clipchampで編集」などのサードパーティ拡張項目が表示されるまでに1〜2秒かかるケースがあり、メニューのレイアウトが途中で変わってしまうことが操作ミスにつながっていた。今後の更新ではこれが解消されるほか、コンテキストメニューのカスタマイズも可能になる見込みだ。 実務への影響 File Explorerはすべてのエンドユーザーが毎日触るコンポーネントだ。特に多数のファイルを扱う業務環境では、エクスプローラーのもたつきが積み重なって生産性に影響する。7月の月例更新に自動で含まれるため、企業のIT管理者は特別な対応は不要だが、以下の点を確認しておくといいだろう。 早めに確認したい場合は、Windows Update から「オプションの更新プログラム」を手動で適用してKB5095093を導入できる 動作確認のポイント：起動速度の体感だけでなく、ISOマウント時の動作、ファイルリネームの挙動も確認しておくと良い 右クリックメニュー改善は別途展開予定のため、現時点でコンテキストメニューが遅い場合は次回以降のアップデートを待つ 筆者の見解 正直なところ、「エクスプローラーが遅い」というのは何年も前から言われてきた話であり、今回ようやく根本から手が入ったことは素直に評価したい。プリロードで誤魔化すのではなく、コード自体を直すという判断は正しい方向だ。 ただ、Windowsそのものを細かく追いかける必要性が以前より薄れているのも事実で、この改善も「やっと」の感は否めない。エクスプローラーはWindowsの顔とも言える存在であり、動作の重さが長年放置されてきたのはもったいなかった。Microsoftはこうした地道な「品質の底上げ」をもっと早く、もっと継続的にやれる力を持っているはずだ。 右クリックメニューの高速化・カスタマイズについても、サードパーティ拡張の読み込み待ちは昔から操作ミスの温床だった。こちらも早期に展開されることを期待したい。今回のKB5095093は地味ながら、日常業務の快適さに直結する堅実なアップデートだと言えるだろう。 出典: この記事は Microsoft begins rolling out a faster File Explorer on Windows 11, and no, it’s not preloading の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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標準機能として解決されるなら実害は小さくない。 ...

Microsoftは2026年7月のWindows 11定例アップデートで、Copilot+やAI機能を一切必要としない実用的な新機能5つを全ユーザー向けに展開する。6月末のオプション更新で先行入手することも可能だ。 1. ポイントインタイムリストア（PITR）— 72時間以内ならシステム全体を巻き戻せる 従来の「システム復元」との最大の違いは、アプリ・設定・個人ファイルをまとめて復元できる点だ。旧来のシステム復元はWindowsのシステムファイルや設定は戻せるものの、個人ドキュメントや後からインストールしたアプリは対象外だった。 PITRは有効化後、Windows側が自動的に復元ポイントを作成し、最大72時間（設定で変更可能）分のスナップショットを保持する。OS・設定・データを一括で巻き戻せるため、「アップデート後に動作がおかしくなった」「誤ってファイルを消してしまった」といった場面で強力な保険となる。 2. アップデート一時停止カレンダー — 最大35日間、日付指定で管理 Windows Updateの一時停止機能は従来から存在していたが、今回はカレンダーUIで終了日を指定できる形式に刷新される。停止期間は最大35日間で、終了日を変更することで延長も可能だ。4月からテストが続けられており、7月の更新で全ユーザーへ展開される。 3. スクリーンティント — カラーオーバーレイで目の負担を軽減 既存の「夜間モード（Night Light）」は画面の色温度を暖色・寒色の範囲で調整するだけだったが、スクリーンティントは好みの色と強度をフルコントロールできる。ディスプレイ全体に色フィルターを重ねる方式で、長時間PC作業による目の疲れ軽減を狙う。 4. Bluetooth接続の改善 — AirPods・Beats Studio Proも対象 AirPodsがペアリングモードに移行するまでの時間を短縮 Beats Studio ProのマイクがWindowsで安定動作 Bluetooth LEオーディオがドロップアウト後に接続を素早く再確立 マイク使用中も音楽再生がスムーズに開始 Apple製ヘッドセットをWindowsとMacで使い回しているエンジニアにとっても恩恵を受けやすい改善だ。 5. タスクバーウィジェットのホバー誤展開を抑制 マウスカーソルが誤ってタスクバーのウィジェットに触れただけで展開されていた問題が解消される。通知アイコンの数も削減され、アクセントカラーへのアイコン色対応も追加される。 入手方法 タイミング 方法 6月末（先行） Windows Update → 手動で「オプション更新」を検索してインストール 7月Patch Tuesday 自動適用（操作不要） 実務への影響 システム管理者・IT部門 PITRはソフトウェア展開・設定変更後のロールバック手段として現場で重宝されそうだ。72時間以内であれば端末を丸ごと以前の状態に戻せるため、展開ミスや不具合発生時の復旧コストを大幅に削減できる可能性がある。ただしPITRはあくまでローカルスナップショットであり、企業の正式バックアップ・DR戦略の代替にはならない点は明確にしておく必要がある。 アップデート一時停止の強化は、業務クリティカルな端末を抱える現場にとって朗報だ。Patch Tuesdayが来てすぐに適用するのをためらっているチームは、このカレンダーUIを使って検証期間を計画的に設けやすくなる。 エンジニア・開発者 Bluetooth LEオーディオの改善は、複数デバイスで同じヘッドセットを使い回す開発者にとって地道ながら大きなストレス軽減になる。スクリーンティントも、長時間ディスプレイを見続ける職種には見逃せない機能だ。 筆者の見解 正直なところ、Windows単体の機能を細かく追うことに以前ほどの意義を感じなくなっている。しかし今回の5機能を見ると、「ユーザーが本当に困っていたことを直す」という原点回帰が感じられて、素直に評価したいと思った。 特にPITRは、Windowsが長年抱えてきた「回復手段が貧弱」という弱点へのまともな回答だ。macOSのTime Machineに相当する機能をOSレイヤーで用意することで、「Windowsは壊れると怖い」という印象を少しずつ和らげられるかもしれない。 アップデート管理のUI改善も地味だが重要だ。「すぐ適用したら壊れた」という報告が現場で増えている今、数日様子を見る選択肢をより使いやすくすることは正しい方向だと思う。日付指定で停止できるのは、IT管理者が計画的に運用しやすい設計だ。 「AIを使えばすごいことができる」という方向性ももちろん大切だが、こうして地道に使い勝手を改善し続ける姿勢こそがプラットフォームへの信頼を積み重ねるのだということを、今回のアップデートは改めて示してくれている。Microsoftにはこの原点を大切にしながら、高みを目指す挑戦の両輪を維持してほしい。 出典: この記事は Here are 5 Windows 11 features coming in July. None of them require AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Anthropicは2026年6月、米国政府が同社の大規模言語モデル「Claude Mythos 5」について、重要インフラの運用・防衛を担う米国内の特定組織に対して使用を条件付きで解禁したと発表した。一方、上位モデル「Claude Fable 5」については引き続き規制が維持されており、今回の措置は「部分的な解禁」にとどまっている。 何が起きているのか 米国政府は一時期、Anthropicが開発する特定のAIモデルに対して使用規制を課していた。今回の発表によると、その規制が一部緩和され、「重要インフラ（Critical Infrastructure）を運用・防衛する米国の組織」に限定して、Claude Mythos 5の利用が認められることになった。 重要インフラとは、電力網・水道・金融システム・通信インフラ・医療機関など、社会の基盤となる施設・システムを指す。これらはサイバー攻撃の主要ターゲットでもあり、AI支援によるセキュリティ強化や運用効率化への需要が特に高い領域だ。 一方、Claude Fable 5については規制解除が見送られた。Fable 5がMythos 5より高性能な上位モデルであることを踏まえると、政府側が「モデルの能力水準」に比例してリスク評価を行っている、という判断の枠組みが透けて見える。 規制の背景と能力閾値による差別化 今回の規制の具体的根拠は公表されていないが、背景として複数の要因が考えられる。 輸出規制・国家安全保障の観点: 近年、米国政府は先端AI技術を半導体輸出規制と同様の安全保障上の懸念事項として位置付けている。高度な推論能力・コード生成能力を持つモデルが、サイバー兵器開発や敵対的用途に転用されるリスクを政府が意識していることは間違いない。 段階的規制の枠組み形成: Mythos 5は解禁、Fable 5は継続規制という判断は、「能力レベルに対応した段階的な使用許可制度」の先例となる可能性がある。今後、同様のアプローチが他社モデルにも適用される展開も考えられる。 実務への影響 米国内の重要インフラ事業者 Claude Mythos 5の解禁により、電力・通信・金融分野のセキュリティチームは、脅威分析・インシデント対応支援・ログ解析といった用途でのAI活用が現実的な選択肢になる。ただし「限定された組織向け」という条件があるため、利用開始前に適格性の確認手続きが必要になる点に注意が必要だ。 日本企業が今から考えておくべきこと 今回の規制はあくまで米国内の措置だが、日本にとっても対岸の火事では済まない。 API経由での間接的影響: AnthropicのAPIを利用している日本企業は、モデルの提供状況変化に直接影響を受ける可能性がある 日本版規制の先行指標: 米国のAI規制の枠組みは、日本政府の政策立案においても参照されることが多い。重要インフラ向けAI利用に関するガイドラインが国内で策定される際の雛形になりうる 調達・ベンダー選定への新たな評価軸: 政府・公共セクターや重要インフラ企業がAIツールを選定する際、「政府承認の有無」が将来的に評価項目として加わる可能性がある 筆者の見解 AI規制が「モデル単位」「能力水準単位」で行われるようになってきた、という点が今回の件で最も注目すべき変化だと思う。 従来の技術規制といえば輸出先国を制限するEARの枠組みが主だったが、今回の動きは国内使用について「何のモデルを、誰が、どんな用途で使えるか」という許可制度の萌芽を示している。セキュリティの観点から言えば、重要インフラへのAI組み込みにあたってリスク評価を政府が主導すること自体は悪い方向ではない。 ただし気になるのは透明性だ。なぜMythos 5は解禁でFable 5はダメなのか、その根拠が公開されなければ、民間企業は何を基準に自社のリスクを評価すればよいのか判断できない。規制の正当性は、その根拠の明確さによって担保される。 日本のIT現場においても「どのAIをどの用途に使っていいのか」という問いはいまだ答えが出ていない。米国の動向を先行事例として学びながら、日本独自の判断基準を早急に整備することが求められる局面に差し掛かっている。 出典: この記事は U.S. partially reverses Anthropic AI ban for Mythos but keeps Fable 5 off the market の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11のアップデート一時停止機能を従来の固定週数ドロップダウンからカレンダー日付選択式に刷新した。最大35日先の日付を指定でき、期限到達後に再設定することで事実上の繰り返し延長も可能になった。同時に、ドライバー・.NETランタイム・ファームウェアの更新をPatch Tuesday（月例品質更新）に統合し、月1回の再起動へと集約する取り組みも開始している。 カレンダー形式の一時停止へ刷新 これまでのWindows Update一時停止機能は「1週間」「2週間」「4週間」といった固定週数から選ぶドロップダウン方式だった。新しい方式では、カレンダーから具体的な終了日を直接選択できる。最大35日という上限は変わらないが、「出張が終わる○月○日まで」「システム検証期間が明ける○月○日まで」といった実務のスケジュールに合わせた設定が直感的に行えるようになった。 設定手順: Windowsキーで設定（Settings）を開く Windows Update に移動 Pause Updates を選択 カレンダーから一時停止の終了日を選択 一時停止中の動作 一時停止が有効な間は、再起動が必要な更新プログラムのダウンロード・インストールは行われない。自動再起動もスキップされる。一時停止設定前にダウンロード中だった更新はキャンセルされ、一時停止終了後に即座に最新の更新を確認・ダウンロード・インストールする。 繰り返し延長で事実上の無期限延長が可能に 35日の期限が近づいた時点で同じ手順で再設定することで、さらに35日延長できる仕組みになっている。Microsoftはセキュリティ上の理由からこれを推奨していないと明示しているが、技術的にはこの繰り返しで更新を長期間回避することも可能だ。 ドライバー・.NET・ファームウェアの月次統合 Windowsチームが発表したもう一つの変更が、更新プログラムの統合による再起動回数の削減だ。 従来はPatch Tuesdayの累積更新に加え、ドライバー・.NETランタイム・ファームウェアがそれぞれ別タイミングでリリースされることがあり、月に複数回の再起動が発生するケースがあった。新しい方式では以下を目指す: ドライバー・.NET・ファームウェアを月例品質更新（Patch Tuesday）に統合 緊急の帯域外（OOB）更新や非セキュリティ更新も同じ統合フレームワークへ組み込み 一般ユーザーは月1回の再起動で更新が完了する体験へ Windows InsiderのExperimentalおよびBetaチャンネルでは引き続き週次更新が提供され、「Persistent Seekers」向けリテールユーザーは2ヶ月ごとの更新となる。 実務への影響 IT管理者の観点 管理ポリシーとの整合性確認が必要: エンドユーザーが35日延長を繰り返せる場合、管理されたパッチ適用サイクルが形骸化するリスクがある。GPOやIntune構成プロファイルによる上限設定の検討を推奨する 月次統合はメンテナンスウィンドウ見直しのタイミング: 再起動スケジュールが月1回に収束するなら、一斉パッチ適用のウィンドウ設計が大幅に簡略化できる 緊急パッチへの対応は引き続き必要: 重大な脆弱性に対する帯域外（OOB）更新は月次統合の枠外でリリースされる。月次統合はあくまで通常運用の合理化であり、緊急対応が不要になるわけではない エンジニア個人の観点 本番デプロイ前やシステム検証期間中に更新を制御したい場面で、カレンダー形式の一時停止は実用的な選択肢になる ただし、ゼロデイ脆弱性が活発に悪用されている時期は長期延期を避けること。数日様子を見る判断は合理的だが、35日以上にわたる放置はリスクが高い 月1回統合は在宅勤務環境でのユーザー体験改善に直結する。「作業中に突然再起動」という最もユーザーに嫌われる体験を減らせる 筆者の見解 率直に言って、今回の変更は地味ながらよくできた改善だ。 「更新したら壊れた」という報告が絶えない現状で、少し様子を見てから当てたいと思うのは合理的な判断だ。固定週数のドロップダウンより実際のスケジュールに合わせて日付を指定できる方が、現場の感覚にずっと合っている。「出張から戻ったらすぐ更新」という使い方が自然にできるのは地味に大きい。 再起動の月次統合も地道ながら重要な改善だ。ドライバー更新のたびに「もう一度再起動してください」とポップアップが出る体験は、ユーザーをアップデート嫌いに育てる大きな原因だった。月1回に収束するなら、「定期メンテナンス」という意識が定着しやすくなる。 一方で、35日を繰り返し延長することで実質的な無期限延長が可能な点には注意が必要だ。Microsoftが利便性と安全性のバランスを取って「繰り返し設定自体は可能だが推奨しない」という設計にしたのは理解できる。ただし、組織の運用現場でこれが「全部先送り」の言い訳に使われないよう、IT管理者はGPOやIntuneで適切な上限を設けておくことを強く勧める。 WindowsのUX改善をこつこつ積み重ねているチームには、こういった実務感覚に根ざした改善を引き続き期待したい。セキュリティを損なわずに使い勝手を上げるのは、言うのは簡単だが実装は難しい。その方向性は正しい。 出典: この記事は Microsoft now lets you pause Windows updates indefinitely and cuts restarts down to one a month の内容をもとに、筆者の見解を加えて独自に執筆したものです。

FBI（米連邦捜査局）とCISA（サイバーセキュリティ・インフラセキュリティ庁）が2026年6月26日、ロシア諜報機関に関連するフィッシングキャンペーンが新たな段階に進化したと警告した。標的となっているのはSignalユーザーで、エンド・ツー・エンド（E2E）暗号化を正面突破するのではなく、バックアップ回復キー（Backup Recovery Key）を騙し取ることで過去の会話履歴すべてを復元するという手口が確認されている。 「暗号化を破らなくていい」——攻撃者の発想転換 Signalは強固なE2E暗号化で知られ、通信経路を盗み見ても内容を解読できない。しかし攻撃者はその前提をひっくり返した。Signalには「セキュアバックアップ（Secure Backups）」という機能があり、会話データを暗号化してクラウドに保存できる。この暗号化を解くのがバックアップ回復キーだ。このキーさえ手に入れれば、攻撃者は自分のデバイスにバックアップを復元し、被害者の過去メッセージをすべて閲覧できる。 FBIは、攻撃者がSignalサポートチームになりすまして以下のようなフィッシングメッセージを送付していると報告している。 「イランや旧ソ連諸国のハッカーによるアカウント乗っ取り攻撃が急増しているため、Signalは利用規約を更新し、強制的な2段階認証を導入します。メッセージや添付ファイルを失わないよう、バックアップ設定を行ってください」 メッセージには「設定 → バックアップ → バックアップを有効化 → 回復キーを表示 → クリップボードにコピー → 次へ」という具体的な手順が添えられている。 2段階の心理的誘導 攻撃はワンステップで終わらない。 第1段階：上記のフィッシングメッセージで被害者にバックアップを設定させる。この時点では回復キーをコピーしただけで、まだ攻撃者には届いていない。 第2段階：少し間を置いて、再度Signalサポートを装ったメッセージを送る。「同期の問題でデータが永久に失われる危険があります。バックアップ設定を開き、回復キーを貼り付けて確認してください」と指示する。 この2段階構造が巧妙で、1通目で被害者を「バックアップを設定した状態」にした上で、2通目で「サポートへの確認作業」と思わせてキーを送信させる。一連の流れが「作業の続き」に見えるため、疑いを持ちにくい。 誰が狙われているか FBIによれば、標的は一般ユーザーではなく「高い諜報的価値を持つ個人」に絞られている。 現・元の米国および海外政府高官 軍関係者 政治家・政治関係者 ジャーナリスト ウクライナに所在する重要人物 攻撃はロシア連邦保安庁（FSB）や関連組織によるもので、UNC5792およびUNC4221として追跡されている。2026年3月の初報から手口が進化した形だ。 実務への影響 一般の日本企業においてこのキャンペーンの直接被害を受ける可能性は低いが、手口の汎用性に注目すべきだ。「公式サポートを装い、正規の機能操作を誘導して秘密情報を引き出す」というパターンは、Signal以外のサービスにも応用できる。 IT管理者・エンジニアへの具体的な対策： 回復キーは絶対に他者に渡さない：バックアップ回復キーはパスワードと同等の機密情報。Signalはサポート目的でこのキーを要求することは一切ない。これはSignalに限らず、どのサービスでも同じ原則 「サポートからの連絡」には疑念を持つ：メッセージアプリ内に届く「公式サポート」を自動的に信頼しない。本物のサポート連絡はアプリ内メッセージとは別チャネルで行われることが多い 組織内のSignal利用ポリシーを見直す：機密性の高い業務通信にSignalを使っている場合、バックアップ機能の有効化状況と回復キーの管理を棚卸しする フィッシング訓練の題材に使う：2段階誘導という手口はメールフィッシングとは異なるパターン。社内訓練のシナリオとして採用する価値がある 筆者の見解 セキュリティ分野は「細かい人が多くて正直得意ではない」と常々思っているが、この手口には技術的な面白さと恐ろしさが同居していて、思わず引き込まれた。 暗号化という堅牢な壁を正面から崩すのではなく、「正規の機能を使わせる」という発想で迂回する。「鍵を渡してください」と言うのではなく、「鍵を確認する手順を実行してください」と誘導する。技術的な脆弱性ではなく、人間の認知の隙間を突いている。 ゼロトラストの考え方では「検証なき信頼はない（Never trust, always verify）」が原則だが、この攻撃はその逆——検証そのものを偽装する。「サポートが確認している」という文脈を作り出すことで、被害者は自ら鍵を開けてしまう。 より根本的なことを言えば、「バックアップ回復キーの漏洩 = 会話履歴の完全露出」という設計のリスクは、利便性とのトレードオフとして避けがたい。クラウドバックアップを有効にする以上、回復キーの管理責任はユーザー側に帰属する。この構造を理解した上で使うかどうかを選ぶのが、今の技術リテラシーとして求められている。 攻撃の高度化に伴い、「疑うことを習慣化する」という古典的な対策が改めて重要になっている。新しいツールや機能の話ではなく、メッセージを受け取ったときの判断力こそが最後の防壁だ。 出典: この記事は FBI: Russian hackers now target Signal backup recovery keys の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

トランプ政権のホワイトハウスが、OpenAIに対して次期大規模言語モデル「GPT-5.6」の展開を段階的に行うよう要求していることが明らかになった。政府の承認なしに一般公開することを認めない姿勢を示しており、AI開発への政府介入という新たな局面が始まりつつある。 GPT-5.6とはどのようなモデルか GPT-5.6はOpenAIが開発中の次世代モデルで、Anthropicが開発する「Mythos」と肩を並べる性能を持つと報じられている。Mythosは現時点では広く知られていないが、AI性能評価の最前線に位置するとされており、GPT-5.6がそれに匹敵するとなれば、現在一般に利用可能なモデルを大幅に上回る能力を持つ可能性が高い。 OpenAIはこれまでGPT-4系モデルから継続的に性能向上を図ってきたが、GPT-5.6は質的な飛躍を伴うモデルになると見られており、ホワイトハウスが早い段階から関与しようとしている背景もそこにある。 なぜ政権はリリースに介入するのか 政府がAIモデルの展開に直接介入するのは異例の動きだが、その背景にはいくつかの要因が考えられる。 国家安全保障上のリスク管理：高性能なAIが悪意ある主体によって悪用されるリスク、特に軍事応用や大規模な情報操作への利用可能性が懸念されている。バイデン政権が2023年に大統領令でAI安全基準を求めたのと同様に、方法論は変わっても「制御したい」という政府の意図は一貫している。 中国との技術覇権争いの文脈：AIを単なる民間技術ではなく国家競争力の中核と見なす動きが加速している。最先端モデルがどの国に先に普及するかは、外交・安全保障上の問題とも直結する。 「後追い規制」の失敗への警戒：高性能モデルが先に広まってから規制しようとしても手遅れになるという教訓が、今回の「先行管理」アプローチにつながっていると考えられる。 実務への影響——日本のエンジニア・IT管理者が今すべき対応 この動きは一見遠い話に見えるが、日本のIT現場にも具体的な影響が及ぶ可能性がある。 リリーススケジュールの不確実性に備える：GPT-5.6が予定通りに公開されない場合、APIを活用した製品開発のタイムラインに直接影響が出る。「最新モデル前提の設計」をしているチームは特に注意が必要だ。プロダクトロードマップには「モデルが予定通り使えない」シナリオを織り込んでおくべきだろう。 マルチモデル戦略の設計を今のうちに：特定のAIプロバイダーに強く依存した設計は、今回のようなリリース遅延や利用制限によってビジネスリスクになる。OpenAI、Anthropic、Googleなど複数のプロバイダーAPIを抽象化レイヤー経由で切り替えられる設計が、今後のレジリエントなシステムの基本要件になる。 業務利用しているSaaSの契約条件を再確認：ChatGPT EnterpriseやAzure OpenAI Serviceを業務利用している組織は、政府規制によるサービス変更リスクをどこまで契約でカバーしているか確認する良い機会だ。SLAや利用規約の変更通知ポリシーも把握しておきたい。 規制リスクをAI活用計画に織り込む：「規制されないことを前提とした設計」は今後通用しなくなる。AI活用ロードマップには、政府規制やプロバイダーのポリシー変更による影響シナリオを組み込んだリスク管理の視点が必要だ。 筆者の見解 政府がAIモデルのリリースに関与するという流れは、今後の世界標準となる可能性がある。EUのAI Actがすでに高リスクAIに規制を課しているように、各国が独自の管理体制を構築しようとするのは想定の範囲内だ。 ただ、気になるのは「承認プロセス」の中身が見えないことだ。どのような基準でGOサインが出るのか、そのプロセスが不透明なままでは、規制は技術の進歩を不当に遅らせるだけになりかねない。本来の目的が安全性の確保であるなら、「禁止や遅延」ではなく「安全に使える枠組みを整えながら展開する」という方向で設計されるべきだろう。プロセスの透明性が問われることになる。 日本のIT現場への示唆としては、「特定ベンダーへの依存リスク」を改めて意識するきっかけになるはずだ。AIツールはもはやインフラに近い存在になりつつあるが、インフラだからこそ、政治・規制リスクも含めた可用性評価が不可欠になる。今後は「性能がいいから使う」だけでなく、「政府規制の影響を受けにくいか」「代替手段はあるか」という観点もベンダー選定の重要な軸になっていくだろう。 出典: この記事は The Trump administration doesn’t want you to use OpenAI’s GPT-5.6 without its approval の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フォード（Ford）の経営幹部が公式に認めた。自動車設計に携わる人間エンジニアをAIで置き換えようとした取り組みは「失敗だった」——その事実が今、テック業界に波紋を広げている。フォードはエンジニアの再雇用に踏み切ったことも明らかにした。 何が起きたのか AIエージェントへの期待が急騰する中、フォードは人間エンジニアの一部をAIに代替させるという判断を下した。コスト削減と開発効率の向上が目的だったとみられる。しかし実際に運用してみると、AIは人間エンジニアが担っていた複雑な判断や創造的な問題解決を代替するには至らなかった。結果としてフォードはエンジニアを再雇用する事態になった。 多くの企業がAI導入の失敗を社内にとどめる中、フォードが幹部レベルで公の場にこれを認めたことは注目に値する。 なぜ失敗したのか 自動車エンジニアリングには、車両の安全性・信頼性・法規適合性に関わる高度な専門判断が要求される。たとえば以下のようなタスクが挙げられる。 クラッシュテスト解析: シミュレーション結果を実際の安全基準に照らして評価する判断 製造プロセスの例外対応: 現場で起きる想定外の事象への臨機応変な対処 法規対応: 各国の排ガス規制や安全規格への適合判断 サプライチェーン調整: 部品調達の問題が設計全体にどう波及するかの総合的な読み 現時点のAIは定型的・反復的なタスクでは高い性能を発揮するが、複数の制約が絡み合う複雑な判断や、過去に事例のない問題への対処では、まだ人間の経験知に頼らざるを得ない部分が大きい。 AI活用と人間の役割——自動車産業の現在地 フォードに限らず、GM・Stellantis・トヨタ・ホンダも製造・設計プロセスへのAI統合を積極的に進めている。ただし各社のアプローチには差がある。 うまくいっているケースに共通するのは「AIが人間を補助する」構造を維持していることだ。 設計CADとAIを組み合わせ、候補を複数生成した上で人間が最終選定する 製造ラインの異常検知はAIが担い、対処方法の判断は人間が下す テストデータの解析はAIが高速化し、最終的な合否判定は人間エンジニアが行う フォードの失敗は、この「補助」から「代替」への線引きを誤ったことにある。 日本の製造業・IT業界への示唆 日本の製造業は品質管理における職人的な暗黙知をどう扱うかという固有の課題を抱えている。「このビビりは材料の問題ではなく加工速度の設定が合っていない」という現場の経験的な直感は、まだAIには難しい領域だ。 だからこそAI導入においては「どの業務をAIに任せ、どの業務に人間の関与を残すか」を事前に丁寧に設計することが不可欠になる。 IT部門においても同様だ。「AIにコードを書かせれば開発者はいらない」という発想で人員削減を進めると、フォードと同じ轍を踏む可能性がある。今のフェーズでは、AIをうまく動かすための設計・監督・検証ができる人材こそが価値を持つ。 筆者の見解 フォードがこの失敗をオープンにしたことは誠実だと思う。多くの企業が同じ失敗をしても黙っている中、公式に認めたことには学習の価値がある。 ただ、ここで「AIにはまだ限界がある」という結論を急ぐのは早計だ。フォードが直面した問題の本質は、AIそのものの限界より「AIに何を任せるかの設計を怠ったこと」にある。人間エンジニアをゼロにして全部をAIに任せることと、AIが最も得意な部分——大量データ処理・パターン認識・シミュレーションの高速化——に特化させ、人間はその結果を統合・判断することに役割を絞ることは、まったく別の話だ。 「仕組みを作れる人さえいれば、あとはAIが回す」という方向性は中長期では正しいと思う。ただしその「仕組みを作れる人」を正しく定義できているかどうかが問われる。フォードが再雇用したエンジニアたちは、従来業務をこなすための人員ではなく、AIと協働するための設計者として位置づけられなければ意味がない。 日本でも今後「AI導入で人を減らしたが、やっぱり戻した」という話が増えてくるだろう。そのときに「AIは使えない」という結論につながってしまうことが一番もったいない。焦って一気に代替しようとするのではなく、「何を、どう任せるか」を段階的に設計しながら任せる範囲を広げていく——それが今のフェーズでの現実的な道筋だと思う。 出典: この記事は Ford execs say they made a mistake when they replaced human engineers with AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleの大規模言語モデル「Gemini」の開発とDeepMindの研究に深く関わった2名の研究者が、競合のAnthropicへ転職する予定であると米Neowinが報じた。具体的な氏名や担当領域の詳細は現時点で明らかになっていないが、両社ともに今回の報道についてコメントを出していない。 Gemini × DeepMind — Googleの中枢を担った人材 GoogleにとってGeminiは、ChatGPTへの対抗軸として全社を挙げて投入したフラッグシップモデルだ。その開発を支えた研究者、そして同社の研究部門DeepMindの専門家が同時にAnthropicへ向かうという構図は、単なる転職ではなく知的資産の移動として業界全体に波紋を広げている。 DeepMindはAlphaGoやAlphaFoldで世界的な名声を持つ研究機関であり、そこで培われた手法がLLM開発にも応用されている。こうした研究者がGoogleの競合に加わることは、技術的な影響という意味で無視できない。 AI業界で続く「頭脳流出」の連鎖 今回の動きはAnthropicに限った話ではない。OpenAI、Meta、xAI、Mistral、Cohere——主要プレイヤーのほぼすべてが、Google・Microsoft・Amazon・DeepMindといった大企業から継続的に研究者を引き抜いている。この「AI人材争奪戦」の背景には以下の要因がある。 スタートアップの評価額急騰: AnthropicはAmazonとGoogleから計数十億ドルの出資を受け、評価額が急速に上昇している。ストックオプションの魅力が大企業の安定性を上回るケースが増えている 研究の自由度: 大組織では製品化の優先順位に縛られがちな研究も、スタートアップでは方向性を自らコントロールしやすい 影響範囲: 少人数の組織であるほど、一人の研究者が製品・技術全体に与えるインパクトが大きい 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと こうした人材移動は、中長期的に利用するAIサービスの性能格差として現れてくる可能性がある。実務的な視点でいくつか整理しておきたい。 LLMの使い分けは「今の性能」だけで判断しない モデルを選定する際、現時点の性能ベンチマークだけでなく「背後にいる研究陣がどこを向いているか」を参照することが重要だ。人材の流入・流出はモデルの6〜12ヶ月後の競争力を左右する。 特定ベンダーへの過度な依存リスク AI研究者の移動が頻繁に起きるということは、「今年最強」のモデルが来年も最強とは限らないということでもある。ガバナンスポリシー、API互換性、コストも含めたマルチモデル戦略を検討する時期に来ている。 社内AI活用においてはモデルより仕組みを優先 どのLLMを使うかより、プロンプト管理・ログ取得・承認フロー・コスト監視といった「仕組み」を整備する方が、長期的な費用対効果は高い。モデルは乗り換えられるが、内製した仕組みはすぐには変えられない。 筆者の見解 この手のニュースを見るたびに思うのは、「情報を追いかけることに意味があるか？」という問いだ。AIの研究者が何人どこへ移籍したかを追いかけても、自分の仕事に明日から使えるものは何もない。 それよりも重要なのは、今手元にあるツールを実際に使い倒して、成果を出す経験を積むことだ。GeminiもClaudeもGPTも、正直なところどれも十分に高性能で、多くの業務ユースケースはすでにカバーできている。「最強モデルはどれか」を議論するより「今のツールでどこまでできるか」を試す方が、現場のエンジニアにとってよほど価値がある。 とはいえ、研究者の流動という現象そのものには目を向けておく価値がある。AIは「完成した技術」ではなく、まだ人材の集中度が性能を直接左右するフェーズにある。Googleが今後どのような形でGeminiの開発体制を立て直すかは、企業としての真価を問われる場面だ。大きなブランドと豊富な計算資源を持つGoogleが、正面から研究開発競争に向き合ってくれることを期待したい。AI領域の競争が激しくなればなるほど、エンドユーザーが使えるツールの品質は上がるのだから。 出典: この記事は Google reportedly set to lose two key Gemini and DeepMind researchers to Anthropic の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、Ubiquiti Networks の UniFi OS および Lantronix の serial-to-ethernet サーバーに存在する最大深刻度の脆弱性が、実際の攻撃で悪用されていることを確認し、緊急警告を発した。 Ubiquiti UniFi OS に連鎖可能な3件の脆弱性 今回 CISA が「既知の悪用済み脆弱性（KEV）カタログ」に追加した Ubiquiti 関連の CVE は以下の3件だ。 CVE-2026-34908 — アクセス制御バイパス 認証なしの攻撃者が UniFi OS に不正な変更を加えられる脆弱性。最悪の場合、システム全体の完全侵害につながる。 CVE-2026-34909 — ディレクトリ/パストラバーサル 攻撃者が OS 上の任意ファイルにアクセスできる。設定ファイルや認証情報の漏洩を経由して、アカウント乗っ取りへの踏み台になる。 CVE-2026-34910 — 不適切な入力検証によるコマンドインジェクション 任意の OS コマンドを注入・実行できる脆弱性。リモートコード実行（RCE）とシステムの完全掌握につながる。 Ubiquiti は5月にこれら3件のアップデートをリリース済みで「権限なしにリモートから悪用可能」と警告していた。その後、セキュリティ研究機関 Bishop Fox がこの3つを連鎖させることで昇格された権限を持つ完全な RCE が達成できることを実証した。Bishop Fox は同時に、脆弱なインスタンスを検出するための無料スクリプトを GitHub で公開している。 Lantronix EDS5000 にもルートレベルのコマンドインジェクション Lantronix の EDS5000（ファームウェア 2.1.0.0R3）では CVE-2025-67038 が確認されている。HTTP RPC モジュールが認証失敗ログを記録する際に実行するシェルコマンドへ、ユーザー名をサニタイズなしで直接連結しているという古典的な設計ミスだ。ルートレベルの任意コマンド実行が可能で、深刻度は最大クラス（CVSS 9.6 相当）に達する。Lantronix はバージョン 2.2.0.0R1 へのアップグレードを推奨している。 実務への影響 BOD 26-04 指令により、米国連邦機関はアップデート適用まで3日以内という期限が設けられている。民間企業にこの義務はないが、KEV カタログへの掲載は「すでに攻撃者が武器化している」ことを意味する指標であり、日本の企業環境でも同等の緊迫感で対応すべきだ。 ...