Tech News JP

Microsoftは、Microsoft 365デスクトップアプリが導入されたWindows 11搭載PCに対し、Microsoft 365 Copilotアプリを自動インストールする展開を2026年6月中旬から7月中旬にかけて実施すると、管理者向けポータルで静かに告知した。インストールはデフォルトで有効化されており、管理者側で「オプトアウト」しない限り自動的に展開される。 強制展開の仕組み 今回の展開で特筆すべきは、MicrosoftがWindows StoreではなくOfficeアプリに組み込まれたMicrosoft 365 Apps updater（Officeの自動更新機構）を使用している点だ。つまり、Windows側のポリシーやストア制限だけでは防げない。 対象は「Microsoft 365デスクトップアプリが入った対象デバイス」とされており、すべてのOffice搭載PCが対象というわけではない。ただし、具体的な除外条件は公式ドキュメントを確認する必要がある。 欧州経済領域（EEA）は今回の展開から除外される。これはデジタル市場法（DMA）への対応と見られる。 管理者が知っておくべき制御手段 MicrosoftのCopilot関連の管理コントロールは現在、複数の場所に分散している： Microsoft 365 Apps 管理センター 統合アプリ（Integrated Apps） Officeプライバシー設定 アプリごとの個別トグル アプリ単位でCopilotを無効化したい場合は、各Officeアプリの「ファイル → オプション → Copilot」から「Copilotを有効にする」チェックを外す方法がある。ただし、これはアプリごと・デバイスごとに設定が必要なため、組織規模での管理には向いていない。Outlookは設定箇所が異なる（クイック設定または設定 → Copilot）点にも注意が必要だ。 なお、レジストリ直接編集でCopilotを排除しようとするアプローチは、今後の更新で上書きされるリスクがあるためMicrosoftも推奨していない。組織管理にはサポートされた管理ツールを使うべきだ。 実務への影響 日本企業のIT管理者が今すぐ確認すべき対応ポイントは以下の通り： テナントのライセンス・デバイス構成を確認：どのデバイスが自動展開の対象になるか把握する 展開を止めたい場合はM365管理センターでオプトアウト：6月〜7月の展開開始前に設定を完了させておくのが安全 エンドユーザーへの事前案内：突然アプリが出現してサポート問い合わせが増えないよう、先んじて周知する ヘルプデスクへの情報共有：「知らないアプリが入った」という問い合わせへの対応準備 Copilotを活用する方針の組織はそのまま展開を受け入れ、利用促進の機会として使えばよい。問題は「使わない組織」が対応を取らないと自動で展開されてしまう点にある。 筆者の見解 Microsoftが「オプトイン」ではなく「オプトアウト」という形で展開するのは、今回が初めてではない。何度か批判を受けながら同じことを繰り返しているのは残念だ。 Copilotが本当に価値あるツールなら、ユーザーが自然と「使いたい」と思える状況を作ればいい。強制的に存在を見せつける手法は、ユーザーの信頼を積み上げるのではなく、むしろ「また勝手に入ってきた」という拒否感を育てるリスクがある。Microsoftにはそれを地道にやりきるポテンシャルがあるはずなので、もう少し丁寧なアプローチをとってほしいというのが正直なところだ。 IT管理者の立場からすれば、管理コントロールがM365管理センター・統合アプリ・プライバシー設定・アプリ別トグルと四分散しているのは純粋に辛い。「無効化したいなら一箇所で完結させる」という設計を、次のリリースサイクルでぜひ実現してもらいたい。 一方で、Copilotを積極活用する組織にとっては、展開の手間が省けるという意味でメリットでもある。この展開を機にCopilot活用の推進を検討するのも一つの選択肢だ。 出典: この記事は Microsoft says it’ll force install Microsoft 365 Copilot on Windows 11 with MS 365 Business in the next 30 days の内容をもとに、筆者の見解を加えて独自に執筆したものです。

eVTOL（電動垂直離着陸機）による「空のUber」実現を競う米国スタートアップ群が、相次ぐ法廷闘争に足をすくわれている。The Vergeのコラムニスト Andrew J. Hawkinsが2026年6月21日付けの週刊コラム「The Stepback」で、Joby Aviation・Archer Aviation・英Vertical Aerospaceの三者を巻き込む訴訟の連鎖を詳細に報じた。 三つ巴の訴訟戦争 The Vergeのレポートによると、サンフランシスコ湾岸に拠点を持つJobyとArcherは、お互いが「空のUber」の座を争う宿命のライバルだ。2025年11月、Jobyは元従業員がArcherへ転職する際に技術情報や利害関係者との通信内容を持ち出したとして、企業スパイ行為でArcherを提訴。「Archerはその盗まれた情報を堂々と利用した」とJobyは訴状で主張している。 Archerは2026年3月に反訴に転じ、Jobyが中国から輸入した航空機部品を「ヘアクリップ」「靴下」などの日用品として虚偽申告し、米国政府を欺いたと糾弾した。この反訴が奏功したのか、翌4月には米国際貿易委員会（ITC）がJobyの中国との関係についての調査を開始。Hawkinsのレポートはこの調査が「Jobyが目指す2028年のエアタクシーサービス開始を遅らせる可能性がある」と指摘している。 さらに2026年2月にはArcherが英国のVertical Aerospaceへも訴訟を拡大。Archerの「Midnight」とVerticalの「Valo」が酷似しているとして特許侵害を訴えた。両機ともに4人乗り・チルトロータープロペラ搭載・巡航速度時速150マイル・最大航続距離100マイルという仕様が重なる。 なぜ今、この訴訟が危ういのか Hawkinsが強調するのは、これらの訴訟が業界にとって最も危うい時期に起きているという点だ。eVTOL各社の株価はここ数年で大幅に下落しており、型式証明取得のスケジュールは繰り返し後ろ倒しになっている。予算は縮小し、タイムラインは延びる一方で、投資家は認証取得の困難さに加え、訴訟費用という新たな出費への懸念を強めている。 「潜在的に数十億ドル規模」（Hawkins）とされる新市場を巡る知財・競合・人材争奪戦が激化しており、業界全体の信頼性を傷つけるリスクが現実のものになりつつある。 日本市場での注目点 日本ではJobyがANAホールディングスと提携関係にあり、国内エアタクシー市場への参入を視野に入れている。しかし、ITCの調査が長引けばJobyの日本展開にも影響が及ぶ可能性がある。大阪・関西万博（2025年）でのデモ飛行を経て機運が高まっていた「空飛ぶクルマ」への国内期待感に、水を差す展開になりかねない。 国内勢ではスカイドライブやテトラ・アビエーションが開発を進めており、海外大手の混乱が国内市場の動向にどう影響するかも注目点だ。現時点では日本市場向けの具体的な価格・発売時期は未公表。 筆者の見解 新技術がパイオニア市場を形成する局面で、知的財産を巡る訴訟が頻発するのはある意味必然だ。スマートフォン黎明期のApple対Samsungを見るまでもなく、新市場の争奪戦では法廷が武器になる。 ただしeVTOL業界の難しさは、型式認証という「参加者全員が超えなければならない巨大な壁」が存在する点にある。訴訟に経営資源を注ぎ込む間は、その壁を超えるための開発・試験・認証取得活動が滞る。競合を叩くことに熱心なあまり、業界全体の信頼性醸成という共通課題がおろそかになれば、最終的には誰も「空のUber」を実現できないという皮肉な結末になりかねない。 とりわけJobyの中国部品問題は地政学リスクとして注視に値する。技術的な完成度とは無関係に、認証や事業展開を根底から揺るがしかねない。「2028年サービス開始」というJobyの目標がどこまで現実的なのか、法廷の動向を慎重に見極める必要があるだろう。 出典: この記事は Electric air taxis are stuck in the courtroom の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Tom’s GuideのAmanda Caswell氏が、AIモデルの「引退」後に何が起きるかを詳細に解説する記事を公開した。ChatGPTやClaudeを使い続けていると、慣れ親しんだモデルがある日突然メニューから消える体験をしたことがあるはずだ。しかしCaswell氏によると、実際には「削除」ではなく、「再活用」されているケースがほとんどだという。同氏はこれを「リファービッシュAI（Refurbished AI）」と呼んでいる。 AIモデルのライフサイクル——各社の仕組み Tom’s Guideの解説によれば、主要AIラボのモデルライフサイクルはほぼ共通した構造を持つ。 Anthropicのケースが最もわかりやすい。モデルはまずActive（完全サポート中）として提供され、Legacy（アップデート停止）、Deprecated（推奨停止・退役日設定済み）を経て、最終的にRetired（リクエスト失敗）となる。 OpenAIも同様に「legacy」（更新停止）と「deprecated」（シャットダウン日確定）を区別。Googleは「deprecation」で告知し、「shutdown」でエンドポイントを切断する形だ。 Caswell氏が強調するのは、「ユーザーがアプリからモデルが消えたと気づく頃には、すでに数週間〜数ヶ月間この移行パイプラインが裏で進行している」という点だ。 「引退」後の3つの行き先 1. アプリから消えても、APIで生き続ける Tom’s Guideの取材によると、2026年2月13日にOpenAIがChatGPTからGPT-5・GPT-4o・GPT-4.1・GPT-4.1 mini・o4-miniを削除した際、API側では変更なしと明言した。コンシューマー向けアプリからは消えても、開発者はそのまま呼び出せる状態を維持していた。 同年3月にはGPT-5.1もChatGPTから退役したが、API経由では引き続き利用可能だった。Caswell氏はこの事実から「アプリから消えた＝完全廃止ではない」と結論付けている。ユーザーが「使えなくなった」と感じたモデルが、別のツールやサービスの裏側で今も動いている可能性があるのだ。 2. ユーザーの声で「復活」したケース GPT-4oがChatGPTから置き換えられた際、Redditなどのオンラインフォーラムで反発が起きた事例をCaswell氏は紹介している。OpenAIはPlusおよびProユーザーの一部が「GPT-4oのより温かみのある会話スタイル」を必要としていると判断し、一時的にモデルを棚に戻した（現在は完全退役済み）。同氏はこれを「リファービッシュAI」の象徴的事例と位置付けている。 3. 「冷凍保存」されて将来復活する可能性 Tom’s Guideの記事が特に注目するのが、Anthropicによるモデル重みの保存だ。Anthropicは公開済みモデルの重みを保存することを公式に約束しており、過去モデルを将来再び提供する可能性があると明言している。いわば「廃盤製品の設計図を倉庫に保管」する状態であり、研究や比較目的での再活用も視野に入る。 日本市場での注目点 日本の開発者・企業にとって実務上重要なのは、APIの継続利用可否を常に把握することだ。ChatGPT上でモデルが消えたからといって、それを使ったプロダクトやワークフローがすぐに壊れるわけではない。ただし各社の廃止スケジュールは定期的に更新されるため、早めの移行計画が求められる。 Azure OpenAI Service経由でGPTモデルを利用している日本企業は、Azureポータル上でもライフサイクル情報が提供されており、退役前の移行猶予期間が設けられることが多い点は安心材料だ。 Anthropicの「モデル重みの保存」というアプローチは、AI安全性・学術研究の観点からも注目に値する。現在のモデルが将来どう評価されるかの記録を残す行為でもあり、業界全体のガバナンス成熟を示唆している。 筆者の見解 「AIモデルが引退する」という現象は、私たちがAI時代に直面する新しいエンジニアリング課題を象徴している。 特に注目したいのは、Anthropicが明言した「モデル重みの保存と将来再提供の可能性」というスタンスだ。透明なライフサイクル設計は、企業がAIシステムを長期前提で設計する上で不可欠な条件だ。「どのモデルをいつまで使えるか」が予測可能でなければ、安定したシステム構築は難しい。 一方で日本企業への示唆として強調したいのは、「特定モデルへの依存をシステム設計段階からリスクとして織り込む」という視点だ。モデル選定の際に後継モデルへの移行コストをあらかじめ設計に組み込むことが、これからのAI活用における重要な判断軸になる。 「引退後も異なる形で生き続けるモデル」という実態は、見方によってはAI開発の成熟を示している。使い捨てではなく用途に応じて「転生」させながら価値を最大化する——これは持続可能なAIエコシステムの健全な姿でもある。ユーザーとして、「消えた」と感じたモデルが別の形で動いている可能性を知っておくことは、AI時代のリテラシーの一部となりつつある。 出典: この記事は Where do old AI models go when they die? Welcome to the strange world of ‘refurbished AI’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはWindows 11 バージョン26H2を2026年6月19日にExperimentalチャンネルへリリースした。次期年次機能アップデートとなる26H2は、フルビルドではなく「有効化パッケージ（enablement package）」という軽量な配信方式で届けられ、サポートライフサイクルのリセットをもたらす。IT管理者にとっては、一般提供（GA）に向けた展開計画を今から立てる絶好のタイミングだ。 Windows 11 26H2の正体——eKBとは何か バージョン番号「26H2」は「2026年下半期リリース」を意味し、21H2、22H2、23H2、24H2、25H2と続くMicrosoftの年次リリース慣例に則っている。2025年末にリリースされた25H2が24H2のコードベース上に構築された有効化アップデートだったように、26H2も同じパターンを踏襲する。 注目すべきは「有効化パッケージ（eKB: enablement package）」という配信メカニズムだ。フルビルドアップグレードが数GBの新しいOSファイルを丸ごと置き換えるのに対し、eKBはわずか数百KBのパッケージで、毎月の累積更新プログラムを通じてすでにデバイスに配信済みの機能を「スイッチを入れる」形で有効化する仕組みだ。 技術的には、Windowsのサービシングスタックがレジストリ値または内部設定フラグを変更するのみで、新しいバイナリは一切持ち込まない。インストール後に一度再起動するだけでバージョン番号が26H2に変わる——通常の累積更新プログラムと変わらない軽さだ。このモデルは23H2が22H2のコードベース上に構築された際に実証済みであり、テスト工数の削減・帯域幅消費の最小化・展開摩擦の軽減という3つのメリットをIT管理者にもたらす。 サポートライフサイクルのリセット——エディション別の違いに注意 26H2リリースの実務上の最大の意義は「サポートライフサイクルのリセット」だ。エディション別のサポート期間は以下のとおりとなる。 エディション サポート期間 Home / Pro 24カ月 Enterprise / Education 36カ月 Enterprise/Educationの36カ月サポートは、大規模組織が年次アップグレードのプレッシャーなく安定運用できる余裕を生み出す。一方、Home/Proの24カ月は個人ユーザーや中小企業にとって「ほぼ2年ごとの更新」を意味し、これまでのWindowsサポートサイクルを踏まえると想定の範囲内だ。 26H2へのアップグレードは新しいサービシングブランチへの移行も意味する。今後の累積更新プログラムはこのベースラインに対して配信され、次の年次アップデートまでの最長36カ月間、セキュリティパッチと品質改善が継続提供される。 IT管理者が今すべきこと Experimentalチャンネルでの公開は「本番展開前に問題を発見できる最初の機会」を意味する。GAは2026年後半の予定であり、今から準備を進めることで余裕のある展開計画が立てられる。 今すぐ着手できる3つのアクション： 検証環境でのテスト開始: Insider Preview（Experimentalチャンネル）を検証機に適用し、社内アプリケーションとの互換性を確認する サポートライフサイクルの棚卸し: 現在展開中のWindowsバージョンとエディションのEOL日付を整理し、26H2への移行タイミングを計画する 展開ポリシーの準備: IntuneもしくはWSUS/ConfigMgrで26H2のターゲットバージョン設定を事前に確認し、GA時の適用スコープを決めておく eKBモデルの最大のメリットは「フルOSアップグレードより圧倒的にテストが早く完了する」点だ。新しいシステムファイルの置き換えがないため、アプリケーション互換性のリスクは大幅に低い。とはいえGA直後は数日様子を見てから適用するというリスク管理も、十分に合理的なセキュリティ判断の一つだ。 筆者の見解 Windowsの細かい変更を逐一追う必要性が薄れつつある昨今だが、eKBモデルの成熟は「縁の下の力持ち」として地味に評価したい。 この仕組みが定着したことで、大規模組織のIT部門が抱えていた「年次アップグレードは一大プロジェクト」という固定観念が崩れつつある。展開コストが下がれば、パッチ適用を後回しにする理由も減る。これはセキュリティ態勢の底上げに直結する正しい方向性だ。 ただ率直に言えば、現時点では「26H2で何が変わるのか」という機能面の情報がほぼない。eKBの仕組みとサポートサイクルの話は重要だが、それだけでは「アップグレードする明確な理由」として弱い。MicrosoftにはGA前に機能ロードマップをわかりやすく示してほしいところだ。組織のIT担当者が「何のために移行するのか」を社内で説明するためにも、そのコミュニケーションは欠かせない。 今の判断としては「GAになってから機能一覧を確認して移行計画を立てる」で十分間に合う。今の段階では検証環境でeKBの挙動を確認しておくという準備に時間を使うのが賢明な選択だ。 出典: この記事は Windows 11 26H2 Hits Experimental Channel: Unpacking the Enablement Update and 36-Month Support Cycle の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Windows 11に標準搭載された新しい「メディアプレーヤー」アプリが、旧来の「Windows Media Player」と比べて約3.5倍のRAMを消費することが報告されている。さらに、現代のスマートフォンや動画配信でも主流のHEVC（H.265）コーデックがOS標準では非搭載であり、再生には別途有料の拡張機能購入が必要であることが改めて注目を集めている。 新旧プレーヤーのRAM消費量——何が変わったのか Windows 11では、長年親しまれてきたWindows Media Player（WMP）の後継として、Fluent Designを採用したモダンな「メディアプレーヤー」アプリが標準搭載されている。ExtremeTechの検証によると、同じ動画ファイルを再生した際のRAM消費量が旧WMPの約3.5倍に達するという結果が出た。 モダンアプリとしての統合ライブラリ管理やUIの洗練は評価できるが、レガシーWMPが持っていたリソース効率という強みは失われている。特に低スペックのビジネス向けノートPCや、バッテリー駆動を重視する環境では、このオーバーヘッドが体感レベルで影響する可能性がある。 HEVCコーデックが「有料オプション」という現実 もう一つの問題が動画コーデックの扱いだ。Windows 11では、HEVC（H.265）コーデックはOSに含まれておらず、Microsoft Storeから「HEVC Video Extension」を約120円（0.99ドル）で別途購入する必要がある。 H.265はiPhoneやAndroid端末で撮影した4K動画、NetflixなどのHDRストリーミングコンテンツでも広く使われている、現代の「主流コーデック」だ。それが標準搭載でないという事実は、一般ユーザーには気づかれにくいが、実務では確実にトラブルの種になる。 一部のWindows 11デバイスでは「デバイス製造元からのHEVC Video Extensions」が無償プリインストールされるケースもあるが、提供はメーカー任せであり一貫性がない。 実務への影響——企業IT担当者が知っておくべき対処法 社内動画の再生環境を統一する 社内研修動画や会議録画をH.265形式で配布している組織では、受信側での再生可否が問題になりうる。Windows 11標準のメディアプレーヤーだけでは再生できない可能性があるため、以下の対策を検討したい。 VLCの全社展開: フリー・オープンソースで主要コーデックをほぼ網羅。コーデック課金とは無縁で、管理されたデバイスへのサイレントインストールも容易 IntuneによるHEVC Extensionの一括配布: Microsoft StoreアプリはMicrosoft Intune経由でポリシーベース配布が可能。HEVCコーデック問題をまとめて解決できる 動画の配布形式をH.264に統一: 一時的な回避策として、配布動画をH.264（AVC）にエンコードして提供するのも現実的な選択肢 コーデック管理の不統一がサポート負荷につながる VP9対応の「Web Media Extensions」やAV1対応拡張など、Windowsのコーデック周りは拡張機能が分散しており、管理が複雑になりやすい。ヘルプデスクが「動画が再生できない」という問い合わせを受けた際の診断フローを整備しておくことを推奨する。 筆者の見解 RAMが3.5倍になったという数値はインパクトがあるが、現代のPCが16GB以上のRAMを標準で積んでいる状況を考えると、絶対値として壊滅的というわけではないかもしれない。ただ、「モダン化＝肥大化」という傾向は、特に法人端末のような長期利用・低スペック環境では無視できないシグナルだ。 より気になるのはHEVCの課金モデルのほうだ。H.265は2013年に標準化されて以来、すでに10年以上が経過した枯れた技術だ。スマートフォンで撮影した動画が、PCに標準搭載のプレーヤーでそのまま再生できないというのは、ユーザー体験として明らかに改善の余地がある。コーデックライセンス料の問題があることは理解できるが、その負担をエンドユーザーに120円という形で転嫁するのは、Microsoftが本来持っているプラットフォーム統合力を使えばもっとうまくやれるはずだという思いがある。 OEMのプリインストールに依存した現状の「一貫性のない無償提供」ではなく、より体系的なアプローチで解決してほしい。Windowsプラットフォームに長年関わってきた立場から、この点は正直に申し上げておきたい。 出典: この記事は Windows 11 New Media Player Uses 3.5x More RAM, Charges for Popular Video Codecs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teams の会議 Recap ページに、主催者が録画・トランスクリプト・AI 生成サマリー・会議メモを直接削除できる機能が追加された。機密性の高い会議後のコンテンツ管理が格段に楽になる、実践的なアップデートだ。 何が変わったのか 従来の Teams では、会議終了後に生成される録画・トランスクリプト・Copilot による AI サマリーを削除するには、SharePoint や OneDrive などの保存先に個別にアクセスする必要があった。コンテンツが複数の場所に分散して保存されるため、「削除したつもりなのに一部が残っていた」というリスクも抱えていた。 今回の更新により、会議の Recap ページという一箇所から以下のすべてを削除できるようになる： 会議録画 トランスクリプト（文字起こし） AI 生成サマリー（Copilot による要約・アクションアイテム等） 会議メモ また今後のアップデートとして、録画やトランスクリプトを保存せずに AI 会議レキャップのみを生成するオプションも導入予定だ。サマリーだけ残してローデータは保存しない、というコンプライアンス要件にも対応できる形になる。 なぜこれが重要か 日本企業の Teams 利用において、会議コンテンツの取り扱いは常に悩ましい問題だ。特に以下のシナリオでは、コンテンツの削除操作が煩雑であることがリスクにつながっていた： 役員会・取締役会などの機密性の高い会議 人事評価・採用面接など個人情報を含む会議 M&A 関連の協議など法的機密性のある会議 外部参加者が含まれる顧客提案・パートナー商談 これらの会議では、録画やトランスクリプトが自動生成されることへの懸念から、そもそも録音・文字起こし機能をオフにする対応を取っている企業も少なくない。今回の機能追加により、「必要なものだけ保持し、不要なものはすぐ削除する」という柔軟な運用が可能になる。 実務での活用ポイント IT 管理者向け： 会議ポリシーで「録画・トランスクリプトの保存先」を明確に定義しておくと、Recap ページからの削除がより一貫して機能する 主催者に削除権限があることを全社周知しておく（知らないと活用されない） 部門ごとに録画ポリシーを分けて設定することも検討の余地あり エンジニア・利用者向け： 機密会議後は Recap ページを習慣的にチェックし、不要なコンテンツを整理する運用フローを確立する 「AI サマリーのみ残して録画は削除」という中間的な選択肢が今後使えるようになる Recap 機能を活用しながら、ガバナンスの観点でコンテンツを管理するアプローチが現実解 筆者の見解 Teams の Recap 機能は、使えば確かに便利だ。会議後のフォローアップが楽になり、欠席者へのキャッチアップも効率化される。ただそのぶん、「気づいたら録画が残っていた」「AI サマリーが想定外の範囲に共有されていた」といった問題が発生しやすい側面もある。 今回の削除機能の追加は、その痛点への誠実な回答だと思う。運用の実態に即した改善であり、歓迎できる方向性だ。 ただ一点付け加えると、情報ガバナンスとしての本来の姿は「作ってから消す」ではなく「最初から適切な範囲にしか保存しない」設計だ。Teams にはまだ、会議コンテンツの保存先・共有範囲・保持期間を事前にきめ細かく制御するための設定が十分とは言えない面もある。削除機能の充実とあわせて、ポリシー設定の分かりやすさやデフォルト値の見直しも進めてほしい。使いやすさとガバナンスを両立できる力が Teams にはあるはずで、その完成形を引き続き期待している。 出典: この記事は Teams Meeting Recap: Organizers Can Now Delete Recordings and AI Summaries の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

マーケットインテリジェンスプラットフォームの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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Engadgetが報じたところによると、フランスのゲーム大手Ubisoftの共同創業者の一人であるクロード・ギロー氏（69歳）が、現地時間2026年6月19日午後にフランス西部で発生した小型飛行機の墜落事故により死去した。地元紙Ouest Franceが最初に報道し、Ubisoftが正式に確認した。 事故の概要 フランス西部・大西洋岸に位置するラ・ボール空港近くの農地に、セスナ421型機が墜落した。搭乗していた2名が犠牲となり、現場に駆けつけた消防隊員によると、到着時すでに機体が炎上し、周辺の環境にも延焼していたという。 Ubisoftは声明で「グループの共同設立者であり、ギロー・コーポレーションの会長であるクロード・ギロー氏の事故による死去を、Ubisoftは深く悲しんでいます。この困難な時期に、ご遺族の皆様に哀悼の意を表します」とコメントし、それ以上の声明を出さないとした。 Ubisoftを築いた5兄弟の一人 クロード・ギロー氏は、ブルターニュ出身のギロー家5兄弟の一人として、1986年にUbisoftを設立した創業メンバーだ。同社はフランスを本拠とする世界的なゲームパブリッシャーとして成長し、現在では「アサシン クリード」「ファークライ」など世界的に知名度の高いフランチャイズを多数擁している。 クロード氏自身は、Ubisoftの兄弟会社にあたるギロー・コーポレーションの会長兼CEOを務めていた。同社はDJ機材メーカーのHerculesと、PCゲーマーや航空シミュレーターファンに広く知られるゲーミングデバイスブランドThrustmasterを傘下に持つ持株会社だ。Ubisoftの取締役会にも名を連ねており、兄弟のイヴ・ギロー氏は現在もUbisoftのディレクター・会長兼CEOとして経営の最前線に立っている。 日本市場での注目点 Ubisoftは日本法人「ユービーアイソフト株式会社」を通じて長年日本市場にも参入しており、国内でも根強いファンを持つ。また、ThrustmasterのレーシングホイールやフライトスティックはAmazon.co.jpでも流通しており、PCゲーマー・シミュレーターファン向けに人気が高い。ギロー・コーポレーションはこれらのゲーミング周辺機器事業において、日本市場でも存在感を持つ企業だ。 Ubisoftそのものは近年、経営上の難しい局面が続いており、クロード氏のような創業世代の退場が組織にどのような影響を及ぼすか、ゲーム業界全体として注目が集まる。 筆者の見解 Thrustmasterのフライトスティックやレーシングホイールを使ったことがある人なら、ギロー家の名前が身近に感じられるはずだ。38年前に5人の兄弟がゲーム会社を起こし、世界有数のパブリッシャーへと育て上げた——そのスケールは今の時代に振り返っても圧倒される。 Ubisoftは現在、コンテンツ戦略やスタジオ運営で難しいフェーズにあることも事実だ。だが、こうした創業者たちの「欧州からゲームで世界と戦う」という意志が、業界の多様性を今日につないできたのは間違いない。その一翼を担ったクロード・ギロー氏のご冥福を心よりお祈り申し上げる。 関連製品リンク T300RS GT Edition Racing Wheel 【Xbox公式ライセンス商品】Thrustmaster スラストマスター フライトスティック T Flight Hotas One Xbox Series X|S Xbox One PC 対応 フライトシミュレーター 着脱式スロットル プラグアンドプレイ 国内正規品1年間メーカー保証 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Claude Guillemot, one of Ubisoft’s co-founders, has died in a plane crash の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

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

GitHubのプロダクトアナリティクス部門が、GitHub Copilotを活用した社内データ分析AIエージェント「Qubot（クボット）」を開発・運用し、その構築過程で得た知見を公式ブログで公開した。非エンジニアを含む全GitHub社員が、SQLを書かずに自然言語でデータへ問い合わせ、リアルタイムに分析結果を得られる社内ツールだ。 Qubotとは何か Qubotは、GitHub Copilotを中核エンジンとして構築された社内向けデータアナリティクスエージェントだ。「先月のリポジトリ新規作成数は？」「GitHub Actionsの利用が増えているカテゴリは？」といった自然言語の問いかけに対し、エージェントが自律的にデータベースへのクエリを生成・実行し、結果を返す。 このようなText-to-SQL型のエージェントを実用化するには、単にLLMをDBに繋いで終わりというわけにはいかない。GitHubチームが公開した知見の核心は、まさにそこにある。 構築上の主な課題と学び スキーマコンテキストの設計 LLMが「どのテーブルに何のデータがあるか」を正確に理解するためのコンテキスト設計が、精度に直結する。テーブル数が多い大規模DBでは全スキーマをプロンプトに詰め込むとトークン上限に引っかかるため、クエリ内容に合わせて関連スキーマだけを動的に提示する仕組みが必要になる。 SQLの検証と自己修正ループ LLMが生成するSQLは常に正確とは限らない。実行エラーをLLMへフィードバックして再試行させるリフレクションループが、実用レベルの精度を実現するうえで不可欠だ。このループの洗練度が、プロトタイプと実運用ツールの差を決める。 データアクセス制御の統合 「誰でも何でも聞けば答える」構成はセキュリティ上のリスクを孕む。既存のデータアクセスポリシーとの統合、読み取り専用クエリの強制、機密データのマスキングといった制御を、エージェントのレイヤーに透過的に組み込む設計が求められる。 日本の現場への影響——今すぐ参考にできること 日本企業の多くで、データ分析はBIツールを使いこなせるか、SQLが書けるエンジニアだけの特権になっている。Qubotのアプローチは、この「データアクセス格差」を解消する具体的なモデルとして参考になる。 実装の出発点として検討できる選択肢： GitHub Copilot Extensionsを使ったチャット拡張で、社内DBへの自然言語問い合わせBotを試験実装できる Azure OpenAI Service + Azure SQL / Synapse Analyticsの組み合わせで、Microsoft技術スタックのまま同様の構成を実現可能 Semantic Kernelのプラグイン機構は、SQL実行エージェントを組み込む際の標準的な出発点として機能する いずれにせよ、まずは「社内でよく聞かれるデータ的な質問トップ10」をAIに答えさせる小規模なPoC（概念実証）から着手することを勧めたい。データレイクやDWHがすでに存在する企業であれば、AIレイヤーを追加するコストは以前より大幅に低下している。 筆者の見解 GitHubがQubotの構築経験を外部に公開したことは、率直に評価したい。「うまくいった」ことだけでなく「学んだこと」を具体的に語る技術記事は、同じ課題を抱える開発チームにとって価値が高い。 注目したいのは、このエージェントの設計思想だ。毎回人間がSQLを承認・実行するフローではなく、エージェントが問いを受け取り、クエリ生成・検証・実行を自律的に完結させる。AIエージェントが本来もたらすべき価値は認知負荷の削減であり、確認のたびに人間を挟む構成ではその価値は半減する。Qubotはその点で正しい方向に設計されている。 日本企業がこの事例から学べる最大のポイントは、「AIを使わせる」より「AIなしでは回らない仕組みを先に作る」という発想の転換だ。Qubotはデータチームへの依頼待ちというボトルネックを構造的に解消する仕組みとして機能している。ツール導入ではなくワークフローの再設計——この視点こそが、AI活用を組織に根付かせる鍵になる。 出典: この記事は How we built an internal data analytics agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Tom’s GuideのAmanda Caswell氏が「Google Zero」と呼ばれる現象を詳報している。これはGoogleの公式製品名ではなく、出版業界が水面下で語り合う「検索流入がゼロに近づく未来」を指す造語だ。Google AI Overviewsをはじめとするアシスタント型検索体験の普及により、ユーザーがリンクをクリックしないまま疑問が解決されてしまうシナリオが、現実のものとなりつつある。 Google Zeroとは何か 同レポートによると、従来のウェブの基本構造は「出版社がコンテンツを作り、Googleがユーザーを誘導し、出版社は広告収入や購読者を得る」という相互依存関係で成り立っていた。ところがAI Overviewsが拡大した現在、Googleは「リンクの羅列を提示するエンジン」から「答えそのものを出すエンジン」へと変貌しつつある。 「白いスニーカーの洗い方」「ADHDとOCDの違い」のような質問に対し、Googleは今やウェブサイトへ誘導することなく、AIが直接要約して回答してしまう。Tom’s Guideのレポートでは、AI Overviewの検索結果のうち10件に1件は不正確だというデータも指摘されており、利便性と信頼性のトレードオフが問題視されている。 ゼロクリックの潮流：AI以前から始まっていた このトレンドは生成AI登場以前から兆しがあった。Googleのフィーチャースニペットやナレッジパネルが徐々にクリックを奪っていたのだが、AIはその流れを劇的に加速させた。 Caswell氏が紹介した複数の業界調査によると、Googleの検索のうち60%以上がウェブサイトへのクリックなしに完結している。AI搭載の検索体験ではその比率がさらに高くなる可能性があるという。 出版社が受けている打撃 Tom’s Guideの報道では、Googleからの検索流入は多くの出版社で前年比約3分の1減という深刻な水準に達しているとされる。AI Overviewsが引用するコンテンツはまさにジャーナリスト・研究者・ブロガーが作ったものだが、ユーザーが元ソースを訪れなければ作り手は報酬を得られない構造的矛盾がある。 Caswell氏は自身の名前でGoogleを試した実例も紹介している。複数の同姓同名の人物をGoogleが誤って同一人物として表示したケースで、AI要約の精度問題を端的に示す事例として挙げられている。 日本市場での注目点 AI Overviewsは日本の検索体験にも段階的に展開されており、英語圏と同様の問題が日本のメディア・ブロガー・EC事業者にも波及しつつある。SEO対策として長年積み上げてきたコンテンツ資産が、AI要約によってバイパスされるリスクは日本語市場でも現実的だ。 メルマガ・SNS・有料購読といった直接チャネルの強化が急務となっており、検索流入への依存度を見直す動きが国内でも加速するとみられる。 筆者の見解 「Google Zero」は出版業界の脅威として語られるが、本質的にはウェブエコシステムの収益モデルが時代に追いついていないことの問題だ。 AIが答えを直接提示すること自体はユーザー体験として合理的な進化だが、「コンテンツを取り込んで要約するだけで対価が返ってこない」構造は長続きしない。Googleが持続可能なコンテンツエコシステムを維持したいなら、出版社との収益分配モデルの再設計は避けられないだろう。また精度の問題——10件に1件が不正確という数字——は特に医療・法律・教育分野では看過できない水準だ。 AIが「答えエンジン」になる流れ自体は不可逆だ。コンテンツを作る側の生き残り戦略は「AIに引用されやすい一次情報・権威ある発信源になること」ではないか。検索流入が減っても選ばれるブランドを作ることが、次の時代の差別化軸になる。 出典: この記事は What is Google Zero — and why your favorite websites are panicking about AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AnthropicのサイバーセキュリティAI「Mythos」が、ホワイトハウスの輸出規制命令を受けて突然オフラインになった。通知からわずか約90分でアクセスを全面制限するという異例の対応——その背景には、過去30年にわたって繰り返されてきた「危険なサイバー技術を封じ込めようとした政府の試み」と、その失敗の歴史がある。 MythosとFable——なぜこれほど騒ぎになっているのか Anthropicが今年4月にローンチしたMythosは、サイバーセキュリティ特化型の強力なAIモデルだ。同社自身が「広く流通すればインターネットに甚大な被害をもたらしうる」と説明するほどの性能を持つとされており、リリース当初から約150の審査済み企業・政府機関だけに限定提供されていた。 想定用途は防御側のためのもの——悪用者よりも先に脆弱性を発見・修正するための「ホワイトハット側の兵器」だ。 今回の規制対象はMythosに加え、最新モデル「Fable 5」も含まれる。両モデルは先週から米国外のユーザーはもちろん、米国内の外国籍ユーザーにも提供停止となっている。 規制発動の2つのトリガー 今回の輸出規制発動には、2つの具体的なきっかけがあったとされる。 第一：韓国大手通信会社へのアクセス付与 Anthropicは限定パートナープログラムを通じ、韓国の大手通信会社（広く報じられているのはSK Telecom）にMythosへのアクセスを提供した。米当局はこの企業を「中国との関係が疑われる」と判断し問題視した。SK Telecom側は中国との関係を否定している。 第二：Fable 5の安全策回避報告 Amazon CEOのアンディ・ジャシー氏が、Amazon社内の研究者たちがFable 5の安全策を迂回する方法を発見したとして政権に報告した。Anthropicはこれを「ジェイルブレイク」と呼ぶことを否定し、「狭い範囲のすでにパッチ済みの問題」と反論しているが、当局の懸念を払拭するには至らなかった。 歴史が示す「サイバー技術封じ込め」の実績 今回の事態が特に注目されるのは、過去30年で繰り返されてきたパターンと重なるからだ。 PGP暗号化と「クリプトウォーズ」（1990年代） 1990年代初頭、Phil Zimmermann氏は「Pretty Good Privacy（PGP）」という暗号化ソフトウェアを開発した。傍受されても解読不可能な通信を実現したこのソフトに対し、米政府は「武器輸出規制違反」として刑事調査を開始した。 Zimmermann氏の反撃は鮮やかだった。PGPのソースコードを書籍として印刷・出版したのだ。書籍は表現の自由で保護されるため輸出規制の適用外。この抵抗は「クリプトウォーズ」として歴史に刻まれ、調査は最終的に打ち切りとなった。今日のSignalやWhatsAppが使うエンドツーエンド暗号化の礎はこうして築かれた。 ワッセナー協定とスパイウェア規制（2010年代） 2010年代には西側製スパイウェアが中東の反体制派活動家への監視に使われていることが次々と発覚。各国政府は「ワッセナー協定」を拡大し、監視・ハッキングソフトウェアをデュアルユース技術として分類、輸出ライセンスを義務付けた。 結果は規制の形骸化だった。イスラエルのNSO GroupのPegasusスパイウェアは規制後も世界中への拡散を続けた。 日本のエンジニア・IT管理者への実務的影響 現時点で日本の一般ユーザーへの直接的な影響は限定的だ。Mythosはもともと限定提供であり、Claude 3系など他のAnthropicモデルは通常通り利用できる。 ただし以下の点は注視が必要だ： AI輸出規制の前例形成：今回の枠組みが定着すれば、他のAIラボの製品にも同様の規制が波及しうる。特にサイバーセキュリティ用途のAIは今後より厳しい審査対象になる可能性がある 企業のAI調達リスク管理：安全保障分野に近いサービスを活用する企業は、突然のサービス停止リスクを調達戦略・BCP計画に織り込む必要が出てくる 「限定提供」モデルへの規制：公開型ではなく審査制でアクセスを絞る仕組みを採用しているAIサービスが、今後どういった規制の対象になるかは不透明だ 筆者の見解 歴史の教訓は明快だ。PGP、スパイウェア、そして今回のMythos——「危険な技術を輸出規制で封じ込める」試みは30年にわたって繰り返されてきたが、成功例はほとんどない。技術は本質的に拡散する。知識は書籍になり、コードはコピーされ、手法は伝播する。規制は流通を遅らせることはできても、止めることはほぼできない。 とはいえ、今回の規制発動には無視できない背景がある。「中国との関係が疑われる企業へのMythosアクセス付与」という具体的なインシデントが存在するからだ。純粋な予防的規制ではなく、実際の懸念事象への対応という側面がある以上、一概に「的外れ」とも言い切れない。 問題は手段の実効性だ。輸出規制という19世紀的な枠組みが、コードで表現されたフロンティアAIの拡散を本当に止められるのか。それとも、Anthropicのような企業が自主的な安全策として設計してきた「審査制限定提供」という仕組みの方が、現実に即した対策なのか。 今回の「90分以内に全アクセス制限」という対応が示したのは、AIラボと政府の間にある力学の変化だ。この判断の落としどころが、フロンティアAI全体の「輸出ルールブック」を形成することになる。その行方を、日本のIT業界も他人事として見過ごすわけにはいかない。 出典: この記事は Encryption, spyware, and now Mythos: History shows why cyber export control doesn’t work の内容をもとに、筆者の見解を加えて独自に執筆したものです。

独学のAIエンジニアでアマチュア言語学者のTom Di Minoが、100年以上にわたって世界中の言語学者を悩ませてきた古代ミノア文明の文字体系「線文字A（Linear A）」の解読に成功したと主張している。この主張は現在、ラトガーズ大学とケンブリッジ大学の言語学専門家によって検証が進められている。 線文字Aとは何か 線文字Aは紀元前1800年頃から紀元前1450年頃まで使われた古代ミノア文明の文字体系だ。クレタ島がミケーネ・ギリシャ人に征服された際に使用が途絶え、ミケーネ人はこれをベースに「線文字B（Linear B）」を作り上げた。 線文字Bは1952年に英国人建築家・暗号解読者のMichael Ventrisによって解読され、古代ギリシャ語であることが判明した（ニューヨーク・タイムズの一面を飾るほどの快挙だった）。Brooklyn CollegeのAlice Koberが積み上げた文法・統計的分析の功績なしに、Ventrisの解読は実現しなかったともいわれる。 線文字Aと線文字Bは60個のコア音節を共有しているため、線文字Aの文字がどんな「音」を表すかはある程度推測できていた。しかし「その音が何を意味するか」が完全に不明で、さらに線文字Bに存在しない13個の追加記号が含まれているため、解読は長年の難題であり続けた。 Di Minoが辿り着いたブレークスルー Di Minoは18歳から古典史・言語学を独学で研究し、線文字Aを7年間学んできた。クレタ島を2度訪れ、2026年1月に解読作業を本格開始。5月22日に決定的な洞察を得たという。 ブレークスルーのきっかけは、クレタ島内の5か所の神殿遺跡に共通する「祈祷定型文」の分析だった。各行の冒頭に現れる動詞が線文字B由来の既知記号5文字と線文字A固有の「*301」という記号で構成され、かつ地域ごとに異なる変化形を持つことに気づいた。このパターンを手がかりに言語の構造を解析し、「線文字Aは古代セム語族の言語を記したものであり、聖書ヘブライ語の前身にあたる——ちょうどラテン語がイタリア語の前身であるように」という結論に至った。 セム語族説は1957年にCyrus Gordonが学術誌で主張したことがあるが、実際の翻訳を導くには至らず、学界での受け入れは限定的だった。Di Minoの解読が翻訳として機能するかどうかは、現在進行中の専門家検証の結果を待つ必要がある。 実務への影響——AIが変えたアマチュアの可能性 このニュースが示唆するのは、「AIと深いドメイン知識の掛け合わせ」が専門家集団を超えるアウトカムを生み出し得るという現実だ。日本のITエンジニアにとって実感しやすいポイントをまとめる。 ドメイン知識×AIが最強の組み合わせ: Di Minoは7年間の蓄積なしにAIを使っても解読に至らなかったはず。「AIだけ使えばいい」ではなく、深い専門知識があってこそAIが武器になる パターン認識タスクへのAI活用: 大量の碑文から統計的パターンを見つける作業は機械学習が得意とする領域。考古学・歴史言語学での応用は今後加速するだろう 検証プロセスの設計が鍵: Di Minoの主張は現在ラトガーズ・ケンブリッジで検証中。AIの出力を適切に評価・検証する仕組みを整えることの重要性を改めて示している 筆者の見解 このニュースを読んで真っ先に感じたのは「これはAI時代の縮図だ」という感覚だ。 世界最高水準の言語学者たちが100年以上解けなかった謎を、独学エンジニアが半年で突破した（主張が正しければ）。ここにあるのは「AIがすごい」というシンプルな話ではなく、「一つのテーマに7年間深く潜り続けた人間が、適切なタイミングでAIを武器として使うと何が起きるか」という問いへの示唆だ。 情報の表面を広く追いかけるよりも、一点に集中して深く掘り下げること。そしてその深みのある文脈の中でAIを道具として活かすこと。Di Minoのアプローチはその典型に見える。 もちろん、この解読主張が専門家の検証を通過するかどうかは全くの別問題だ。過去のセム語族説がそうだったように、「翻訳として機能する」ことを証明するハードルは高い。解読の真偽はしばらく注目し続けたい。 出典: この記事は AI Engineer Claims to Have Cracked Linear A の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Microsoftは2026年6月、Windows 11の年次アップデート「26H2」を2026年秋（10月前後）に提供予定であることを公式ドキュメントで確認した。ただし今回も昨年の25H2と同様、約200KBの「有効化パッケージ（eKB）」として配布される超軽量な更新であり、実質的な新機能の追加はない。 Windows 11 26H2の正体——「バージョン番号を上げる」だけのアップデート 今回のWindows 11 26H2は、Microsoftが「eKB（enablement package）」と呼ぶ有効化パッケージとして提供される。ファイルサイズはわずか200KB程度で、インストールにかかる時間は再起動込みでも5分未満、場合によっては2分以内で完了する。 eKBの役割はシンプルだ。OSの内部バージョン番号とビルド番号を切り替えるだけであり、UIの変化や新機能の追加は一切ない。すでにWindows 11 24H2または25H2を使用しているPCは、外見上まったく同じ状態のまま「26H2」になる。 Microsoftはこのアプローチについて「組織やITプロフェッショナルに向けた、予測可能で低干渉な更新体験の継続」と説明している。 なぜ2年連続で「大型更新なし」なのか Windows 11の最後の大型機能アップデートは2024年10月1日リリースのWindows 11 24H2だった。25H2（2025年）、そして今回の26H2（2026年）は、いずれも24H2と同一のプラットフォームコードをベースにしており、新しいソフトウェア基盤は持ち込まれない。 Microsoftの方針として注目すべきは、大型機能を年次アップデートから月次の累積アップデート（Patch Tuesday）に分散配布する戦略への移行だ。たとえば近々のPatch Tuesdayでは「移動可能なタスクバー」のサポートが追加予定であり、先ごろの更新では「Low Latency Profile」という重要な機能が搭載された。以前はこうした機能変更が年次アップデートで一挙に届いていたが、今後は毎月の更新に組み込まれていく形に変わっている。 サポート期限とシステム要件 26H2へのアップグレードにおける最大の実益はサポート期間の延長にある。 エディション サポート終了日 Home / Pro / Pro EDU / Pro for Workstations 2028年10月 Enterprise / Education / IoT Enterprise 2029年10月 参考として、現行バージョンのサポート期限は以下のとおり： Windows 11 24H2：2026年10月13日終了 Windows 11 25H2：2027年10月12日終了 ハードウェア要件に変更はなく、4GB RAM・64GBストレージ・1GHz以上の64ビットデュアルコアプロセッサーというWindows 11の既存要件がそのまま適用される。 別ライン「Windows 11 26H1」との違い 混乱を避けるために触れておくと、Windows 11 26H1という別系統も存在する。こちらはNvidia N1（RTX Spark）やSnapdragon X2など次世代シリコン向けの新プラットフォームリリースだ。ただし26H1も現時点では排他的な新機能があるわけではなく、既存PCのユーザーが気にするのは26H2のみで問題ない。 実務への影響——IT管理者が今すべきこと 1. Windows 11 24H2ユーザーはサポート期限を確認 24H2のサポートは2026年10月13日に終了する。企業環境では計画的な26H2への移行スケジュールを策定すべき時期だ。 ...

Microsoftが、Microsoft EdgeブラウザへのGoogleアカウントでのサインイン機能を2026年7月から段階的にリリースすることをMicrosoft 365ロードマップ（ID: 565860）で公式確認した。さらに、Windows 11のセットアップ時にMicrosoftアカウント（MSA）を強制する要件についても廃止を検討していることが明らかになっている。長年続けてきたアカウント囲い込み戦略からの方針転換として注目を集めている。 EdgeにGoogleアカウントサインインが追加される 先行ビルドではすでに機能が確認されており、Edgeのプロフィールメニューに「Or sign in with」セクションが追加され、Googleボタンが表示されるようになっている。クリックするとGoogleの標準ログインページに遷移し、Edgeにサインインできる。 サインイン後はGmailアドレスがEdgeプロフィールのIDとして表示され、ブックマーク・パスワード・履歴などの同期も有効になる。MicrosoftアカウントなしでEdgeの同期機能が使えるようになるわけだ。対応OSはWindowsとmacOSの両方。 なお、エンタープライズ管理者はNonMicrosoftAccountSignInEnabledポリシーを使ってこの機能の有効・無効をコントロールできる。 Windows 11のローカルアカウント復活も視野に Edgeの変更と並行して、Windows 11のセットアップ時に要求されるMicrosoftアカウントのサインインを廃止する方向で、Microsoftの内部チームが作業を進めているとも報じられている。Windows 11がリリースされた2021年以来、ホームエディションでのローカルアカウントへの道は着実に狭められてきた。その流れが逆転するとすれば、約5年ぶりの大きな方針転換となる。 なぜこれが重要か MicrosoftがここまでMSAへの強制サインインにこだわってきた背景には、明確なビジネス上の理由があった。Bing Rewards、OneDriveのストレージ連携、Copilotの個別化、広告配信のターゲティング——これらはすべてMSAへのサインインが前提となっている。 その方針を転換し始めた最大の動機は、Chromeユーザーを取り込む現実的な判断を優先したからとみるのが自然だ。Googleアカウントと結びついた数億人のユーザーに対し「あなたのGoogleデータはそのままEdgeに移行できます」と言える体制を整えることで、スイッチングコストを大幅に下げる戦略だ。 EdgeはすでにChromeのブックマークやパスワードを継続的にインポートする機能を持っているが、「アカウント自体がGoogleのまま使える」というのは次元が異なる。 実務への影響 エンタープライズ管理者向け: NonMicrosoftAccountSignInEnabledポリシーで非MSAサインインを無効化できる。BYODや個人アカウントの混入を懸念する企業は、ロールアウト前にポリシーを確認・設定しておくことを推奨する Entra IDで管理されているデバイスでは、従来のMSAサインイン要件と今回の変更との相互作用を早期に検証しておきたい 個人ユーザー向け: ChromeからEdgeへの移行を試みたものの「Googleアカウントとの断絶」がネックになっていた場合、今回の変更でその障壁は大きく下がる Windows 11のローカルアカウント対応が実現すれば、法人PCのセットアップフローが大幅にシンプルになる可能性がある 筆者の見解 この変更は、Microsoftにとっての現実的な後退ではなく、むしろ賢い戦略転換だと見ている。 MSAへの強制サインインは、正直なところユーザーにとって摩擦でしかなかった。Windowsのセットアップ中にアカウント登録を迫られ、Edgeを使うたびにサインインを促されて辟易した人は少なくないだろう。その「囲い込み」がChromeやFirefoxへの流出を後押しした側面は否定できない。 今回の変更は、「囲い込まなくても選ばれるブラウザになれる」という姿勢への転換と読むこともできる。垂直タブ、没入型リーダー、AIタブオーガナイザーなど、EdgeにはChromeにない独自の価値がある。その強みで正面から勝負する方向に舵を切ったとすれば、遅きに失した感はあるが正しい判断だ。 Windows 11のローカルアカウント対応も同様だ。「MSAへの依存でユーザーをつなぎとめる」のではなく、「OSの使い勝手そのもので選んでもらう」方向性は、長期的に見てMicrosoftのブランド価値を高める。その力が十分あることは、長くMicrosoftを追いかけてきた立場からも疑いがない。 もちろん、Copilotや各種AIサービスとのシームレスな連携にはMSAが引き続き重要であり、完全なアカウント不要にはならないし、そうする必要もない。「使いたい人が使えばより便利になる」という本来あるべき設計に近づいているとすれば、大いに歓迎したい動きだ。 出典: この記事は Microsoft is killing the Microsoft account lock-in across products, Windows 11 may be next の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Elastic（Elasticsearch開発元）は、AIエージェントに本物の長期記憶を持たせるための永続メモリ層をElasticsearchで構築し、その設計思想と実装の詳細を公開した。168問のQA評価でR@10が平均0.89に達し、かつユーザー間のデータ漏洩ゼロを達成したこのアーキテクチャは、エージェント開発者が直面する「記憶問題」に対して実践的な解を示している。 コンテキストウィンドウは「記憶」ではない 多くのAIエージェント実装では、過去の会話履歴をそのままコンテキストウィンドウに詰め込む手法が採られている。しかしこのアプローチには3つの根本的な問題がある。 まずコスト——長い履歴はそのままトークンコストに直結する。次にレイテンシ——大量のコンテキストは推論速度を落とす。そして「中間消失（Lost in the Middle）」効果——研究で示されているように、モデルはプロンプトの端（冒頭・末尾）に近い情報は拾うが、中間に埋もれた情報は無視しがちだ。 100万トークンのコンテキストウィンドウは「作業メモ」であって「記憶」ではない。セッションをまたいで生き残り、年単位でスケールし、内容・時刻・ユーザーで検索できる永続ストアこそが本物の長期記憶だ、というのが本実装の出発点である。 3種類の記憶：認知科学からの借用 Elasticのチームは認知科学の知見（COALAフレームワーク）を参照し、記憶をエピソード・意味・手続きの3種類に分類。それぞれをElasticsearchの独立したインデックスにマッピングした。 エピソード記憶（Episodic Memory）: タイムスタンプ付きの生イベント。各ユーザーターンをそのまま蓄積する。短命なものが多く、後で重要な事実を抽出するための素材となる。 意味記憶（Semantic Memory）: ユーザーに関する安定した事実。「Sarah は Lumio Hub v2 を所有している」「Sarah の iOS バージョンは 17.4」のような蒸留済みのアサーション。セッションをまたいで永続し、エージェントが推論の根拠とする情報がここに入る。 手続き記憶（Procedural Memory）: 複数ステップのプレイブック。「Zigbee接続切断のトラブルシュート手順」のような、事実ではなくプロセスを保存する。 この分類の重要な点は、書き込み頻度とエイジング（鮮度の扱い）がタイプごとに異なることだ。単一の記憶モデルで混在させるとハイスタック化する。タイプ別管理により、検索精度と更新コストを両立させている。 ハイブリッド想起・上書き処理・ユーザー分離 想起クエリにはRRF（Reciprocal Rank Fusion）とクロスエンコーダー再ランカーを組み合わせたハイブリッド検索を採用している。ベクター検索によるセマンティックマッチと全文検索によるキーワードマッチを融合させ、どちらか一方に頼るより精度を高めている。 矛盾する事実が生じた場合は「削除」ではなく「上書き（Supersession）」で処理する。旧バージョンを残しつつステータスを変更するため、監査証跡が完全に保たれる。 マルチユーザー展開では、ElasticsearchのDLS（Document Level Security）をユーザーID単位で適用することでテナント間のデータ漏洩を防ぐ。168問の評価でクロステナント漏洩ゼロという結果は、本実装が単なるプロトタイプではないことを示している。 また、このメモリ層はMCP（Model Context Protocol）対応クライアントであれば何でも接続できる設計になっており、特定のエージェントフレームワークに依存しない。 実務への影響 日本のエンジニアにとって、このアーキテクチャが示す教訓はいくつかある。 「専用ベクターDBでなくてよい」という選択肢: Elasticsearch（またはOpenSearch）がすでに自社インフラにあるなら、それをエージェントメモリとして転用できる。新たなマネージドサービスを増やさずにアーキテクチャをシンプルに保てる点は、運用コストの観点からも現実的だ。 エイジングと鮮度管理の設計思想: 記憶が古くなれば重みを下げ、よく参照される記憶は沈まないようにする——時間とアクセス頻度に基づくスコアリングは、RAGシステム設計全般に応用できる考え方だ。 DLSによるマルチテナント分離: 企業向けSaaSやB2B SaaSを構築する際に即座に参考にできるパターンだ。エージェントが複数ユーザーの記憶を混同するリスクは、セキュリティインシデントとして深刻なものになりうる。 実装はGitHubで公開されており、Agent BuilderとしてElastic CloudでもGA（一般提供）済みだ。 筆者の見解 今回のElasticのアーキテクチャは、「エージェントに本物の記憶を持たせる」という課題に対して、認知科学の分類を実装レベルで具体化した点で評価できる。 私が特に注目するのは「上書き（Supersession）」と「エイジング」の組み合わせだ。記憶は単に保存するだけでは意味がない。矛盾を処理し、鮮度を管理し、重要度の下がった情報を静かに沈め、必要なものを浮かび上がらせる——この仕組みなしに、エージェントは長期間使うほど「ゴミ屋敷化」する。 エージェントが自律的にループで動き続ける「ハーネスループ」の設計においても、セッションをまたぐ文脈保持は最大のボトルネックのひとつだ。毎回コンテキストをゼロから渡し直すモデルでは、エージェントが真の意味で「学習する」ことができない。ループが本当に賢くなるには、今回のような永続記憶層が前提条件になる。 Elasticsearchをすでに使っていない環境では導入コストも無視できないが、「新しいベクターDBを追加するか、既存の検索インフラを転用するか」という問いに後者で答えられる可能性を示したことは実践的だ。3つのインデックス構造・ハイブリッド検索・DLSは、それぞれ単独では枯れた技術。組み合わせ方にこそノウハウがある。エージェントに「セッションをまたいだ文脈」を持たせたいすべての開発者に一読を勧めたい内容だ。 出典: この記事は We built a persistent agent memory layer on Elasticsearch with 0.89 recall の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIが開発した内部AIモデルが、数学者Paul Erdősが1946年に提唱した「単位距離予想（Unit Distance Conjecture）」を反証し、80年来の未解決問題に終止符を打った。AIが核心的なアイデアと証明草案を生成し、フィールズ賞受賞者のTim Gowers氏（ケンブリッジ大学教授）を含む9名の数学者チームがそれを検証・精緻化して論文として発表した。 Erdős単位距離予想とは何か Paul Erdős（1913〜1996）は20世紀を代表するハンガリー出身の数学者で、組合せ論・グラフ理論・数論など広範な分野で1500本以上の論文を残した。彼が1946年に提唱した「単位距離予想」は、平面上のn個の点の間で、ちょうど距離1（単位距離）となる点対の最大数に関する問題だ。 Erdősは点の配置をどれだけ工夫しても、単位距離を持つ点対の数には厳しい上界があると予想していた。この問題は直感的な明快さの裏に深い組合せ論的構造を持ち、多くの一流数学者が取り組みながらも80年間決着がつかないまま残り続けた、数学史上の著名な未解決問題の一つだ。 AIが核心アイデアを生成、人間の専門家が精緻化 今回の突破口を開いたのはOpenAIの内部AIモデルだ。このモデルが予想の反証となる核心的なアイデアと証明の初期草案を生成し、それをTim Gowers氏らの数学者チームが厳密に検証・発展させた。 従来のAI活用は「既知の証明を検索する」「計算を高速化する」といった支援に留まっていた。今回の特徴は、AIが「新しい数学的アイデアを能動的に生み出す」役割を担った点にある。フィールズ賞受賞者という数学の最高峰がAIの出力を「検証に値する」と判断し、共同作業として論文を完成させたことは、AIの知的能力についての認識を根本から塗り替える出来事だ。 なぜこれが重要か AIが「発見者」になった これまでのAIは人間が積み上げた知識を整理・言語化する能力に秀でていた。今回の成果は、既存知識の組み合わせでは届かない「新しい思考の跳躍」をAIが実現できることを示唆している。数学の証明という、曖昧さが一切許されない最も厳格な知的活動の場で、この能力が実証された意味は大きい。 人間とAIの協働モデルの実証 「AIがアイデアを出し、人間の専門家が検証・精緻化する」という分業が最高レベルの数学で機能することが証明された。このワークフローはソフトウェア開発・新薬設計・材料探索など、数学的推論を基盤とする多くの分野に応用可能だ。 数学以外への波及 暗号理論・量子アルゴリズム・AI安全性など、未解決の数学的問題が実用上の障壁となっている領域で、同様のアプローチが加速する可能性がある。 実務への影響——エンジニア・IT管理者が押さえるべきポイント 「補助ツール」から「共同研究者」へのパラダイム転換 この実績を受け、企業のR&D部門や学術研究機関でAIを研究プロセスへ統合する動きが一段と加速するだろう。社内でAI活用戦略を策定する際、「チャットボット的なAI」と「自律的に問題を探索するAIエージェント」は別物として位置付ける必要がある。 検証プロセスの設計が成否を分ける 今回の成果も、AIが単独で完結したのではない。9名の専門家が検証・精緻化するプロセスがあって初めて論文になった。AIが生成したアウトプットを専門家が精査するワークフローを組織として設計することが、AI活用の質を左右する。「AIが出したアイデアを人間が判断する」という役割分担を意識的に組み込む必要がある。 AIエージェントの自律的問題解決能力への注目 単発の質疑応答ではなく、AIが複雑な問題空間を自律的に探索し続けるエージェント的な動作が今回の成果の背景にある。この能力をどう業務プロセスに組み込むかが、これからの組織の競争力に直結する。 筆者の見解 AIが80年来の数学的難問を突破するアイデアを生み出した事実は、素直に驚きをもって受け止めたい。 興味深いのは、今回の成果が「AIが一人で全部やった」という話ではない点だ。AIが方向性を示し、フィールズ賞受賞者レベルの専門家が検証・完成させた。この構造は、AIが得意な「広い空間を高速に探索すること」と、人間が得意な「数学的厳密性の担保」が組み合わさったものだ。どちらが欠けても今回の成果はなかった。 数学という「答えが完全に正しいか間違いかしかない」領域でこの協働が機能したことは、より曖昧さが混じる実務領域への応用に自信を与えてくれる。ただし、実務では「何が正しい検証か」自体が難しいケースも多い。AIが出した答えをどう評価するかの基準設計こそが、組織にとって最初の本質的な仕事になる。 AIが「仮説生成装置」として機能し、人間の専門家が「検証・判断装置」として機能するモデルは、今後あらゆる知的産業に広がっていくだろう。日本のエンジニアやIT組織が問うべきは「うちの現場でAIはどんなアイデアを出せるか」ではなく、「AIが出したアイデアを誰がどう評価する体制を作るか」だ。この問いに答えられた組織が、次のフェーズで差をつける。 出典: この記事は OpenAI’s AI Model Disproves 80-Year-Old Erdős Unit Distance Conjecture, Verified by Fields Medalist Tim Gowers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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