Tech News JP

AIベンチマークメディアのTryAIは2026年7月9日、OpenAIの新モデル「GPT-5.6」(Sol・Terra・Lunaの3グレード)、xAIの「Grok 4.5」、AnthropicのClaude(Opus 4.8・Fable 5)、Metaが初めて投入したコーディング特化モデル「Muse Spark 1.1」、さらにQwen・DeepSeek・Kimi・GLMなどオープンウェイト系を加えた合計12種のAIモデルに、同一の4本のアプリ――レイキャスター式3D迷路、3Dルービックキューブ、電卓、ライフゲーム――を作らせる「ビルドオフ」対決の結果を公開した。各モデルにつき5回ずつ試行し、成功率のばらつきとコスト・所要時間を並べて可視化したのが今回の見どころだ。 前回への反応を反映した再検証 TryAIは以前実施した同様の企画がHacker Newsで大きな反響を呼び、「オープンウェイトモデルも入れてほしい」「1回の試行だけでは判断材料として弱い」という指摘を受けていた。そこで今回はQwen 3.7 Plus・DeepSeek V4 Pro・Kimi K2.6・GLM-5.2をFireworks経由で追加し、各タスクを5回ずつ試行する形に改めた。TryAI自身も「これは科学的な検証ではなく、あくまで観察結果の共有」と明言しており、数字を鵜呑みにせず参考情報として捉えるべき性質のものだ。 レイキャスター迷路で見えた明暗 最初の課題「WASDで歩けるレイキャスター式3D迷路」では、GPT-5.6 Sol(5/5成功、$1.35、120秒)とGPT-5.6 Luna(5/5成功、$0.15、23秒)がともに満点を記録した。特にLunaは最安・最速でありながら安定して動くコードを生成しており、軽量タスクでは必ずしも高価格帯のモデルが必要ないことを示した。Grok 4.5も5/5・$0.27というコストパフォーマンスの良さを見せている。一方Claude Opus 4.8は4/5(堅実だが平凡)、上位モデルのClaude Fable 5は最も高コスト($2.35)でありながら3/5にとどまった。MetaのMuse Spark 1.1は2/5と成功率こそ低いものの、成功した回はGPT-5.6 SolやClaude Fable 5に匹敵する完成度だったとTryAIは評価しており、Metaが本気でコーディング領域に参入してきたことをうかがわせる。オープンウェイト勢では、GLM-5.2が見た目の描画は良好ながら一度もキャラクターを動かせず0/5に終わるなど、モデルごとの得意不得意がくっきりと分かれた。 実務への影響 日本のIT現場でも、単一ベンダーのモデルに固定せず用途に応じて複数モデルを使い分ける「マルチモデル運用」が現実的な選択肢になりつつある。今回のようにコスト・所要時間・成功率が同じ土俵で比較できるデータは、社内でモデル選定の基準を作る際の材料になる。特に「最新の上位モデルが常に最善とは限らない」という点は実務上重要で、単純なUI生成やプロトタイピングであれば安価な下位グレード(Lunaのような)で十分なケースは多い。開発チームがモデルを選ぶ際は、公開ベンチマークの数字だけで判断せず、自社の実タスクで同条件の比較を行うことをおすすめしたい。 筆者の見解 筆者は日頃、AIエージェントによる自律的なコーディングをClaude Codeで使い倒しているが、今回のような「1回の指示でどこまで完成度の高いコードを一発生成できるか」というベンチマークは、実際の開発現場で価値を発揮する自律ループ型のエージェント運用とは評価軸が異なる点に注意したい。エージェントが自分でコードを実行し、テストし、失敗したら直すというループを回せるかどうかが今の開発体験を左右する本質であり、単発生成の巧拙とは別の話だ。その意味で、今回Claude系が振るわなかった結果はやや意外ではあるものの、一発勝負のタスクでの数字であることは差し引いて見る必要がある。むしろ興味深いのはMetaのMuse Spark 1.1の健闘で、成功時の完成度が上位モデル並みだったという結果は、コーディング領域の競争がここまで激しくなっていることの表れだろう。ベンチマークの数字を追いかけるより、自分の手元のワークフローで実際に試して確かめるのが結局は一番の近道だと改めて感じさせる企画だった。 出典: この記事は GPT-5.6, Grok 4.5, Claude, and Muse Spark build the same 4 apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Microsoftは、Microsoft 365上でAIが生成・加工した動画および音声コンテンツに「透かし（ウォーターマーク）」を付与する新しいクラウドポリシーを発表した。対象となるのは、動画編集ツールClipchampで生成したAI動画や、Copilotが自動生成する音声概要（Audio Overview）などのコンテンツだ。ポリシーは既定で無効になっており、テナント管理者がMicrosoft 365管理センターから明示的に有効化する必要がある。 何が変わるのか 今回追加されたのは、AIによって生成・加工されたことを示す情報を、動画・音声ファイルに埋め込む仕組みだ。コンテンツの来歴（プロブナンス）を示すという発想自体は目新しいものではなく、業界全体で進むC2PA（Coalition for Content Provenance and Authenticity）のContent Credentialsのような取り組みと軌を一にする。Microsoftも以前からBing Image CreatorやDesignerが生成した画像にC2PAベースの来歴情報を付与しており、今回はその考え方を動画・音声というメディアにも広げた形になる。 管理はテナント単位のクラウドポリシーで行う。管理者がポリシーを有効化すると、対象アプリで生成・加工されたコンテンツに自動的に透かしが付与されるようになる。個々のユーザーが都度オン・オフを選ぶ機能ではなく、組織のガバナンス方針として一括適用する設計だ。 画像の透かしとは別管理 注意したいのは、画像コンテンツにはこのポリシーとは別に、ユーザーが個別に制御できる透かし機能が既に存在する点だ。今回のクラウドポリシーはあくまで動画・音声を対象としており、画像側の仕組みとは管理経路も適用範囲も異なる。両者を混同して「画像も含めて一括で制御できる」と誤解しないよう、社内周知の際は対象範囲を明確にしておく必要がある。 実務への影響 日本企業のIT管理者にとって、この機能は「AI生成コンテンツであることをどう開示するか」という、今後避けて通れない課題への一つの答えになる。生成AIで作った紹介動画や、Copilotが要約した音声資料が社外に出ていく機会は今後確実に増える。透かしという形で来歴を残しておけば、フェイクコンテンツ対策や、受け手への誠実な情報開示という観点で組織を守ることにつながる。特に金融・メディア・広報部門など、対外的な説明責任が重い部署では、開示ルールが法制度で求められる前に自主的に整備しておく価値は大きい。 実務的には、まず自社でClipchampやCopilotの音声概要機能をどの部署がどの程度使っているかを棚卸しし、有効化した場合の影響範囲を確認するところから始めたい。既定が無効のため今すぐ何かが変わるわけではないが、コンプライアンス要件がある組織ほど早めに評価しておく価値がある。 筆者の見解 生成AIコンテンツの透明性確保は、今後あらゆるプラットフォームが避けて通れないテーマだ。MicrosoftがMicrosoft 365という統合プラットフォームの中に、動画・音声の透かしをテナント単位のポリシーとして組み込んだこと自体は、地に足のついた前進だと感じる。派手な新機能ではないが、こうした地道なガバナンス機能の積み重ねこそが、企業がAIを本格的に業務へ組み込んでいくための土台になる。 一方で、今回の仕組みはあくまで「管理者が有効化して初めて動く」オプトイン方式であり、既定オフという設計にはやや物足りなさも残る。Copilotの音声概要のような機能は今後さらに使われる場面が増えていくはずで、AI生成物であることの開示は本来もっと当たり前の標準機能になっていてよいはずだ。透明性確保の仕組みをせっかく作ったのだから、デフォルトで有効にしても違和感がないくらいの立ち位置に、Microsoftには早めに踏み込んでほしい。AIガバナンスの領域で正面から勝負できるだけの力は十分にあるはずなので、そこは素直に期待している。 出典: この記事は Bringing transparency to AI-generated content with watermarks in Microsoft 365 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

xAIは新しい大規模言語モデル「Grok 4.5」を投入した。コーディングエージェント向けの利用コストを最大80%削減しながら、フロンティアモデル並みの応答速度を実現した一方、第三者ベンチマーク機関Artificial Analysisの検証では、幻覚(ハルシネーション)の発生率が旧モデルの25%から54%へと倍増したことが明らかになった。 Grok 4.5とは何か xAIが提供する最新の大規模言語モデルで、特に「コーディングエージェント」——人間の指示に基づきコードの生成・修正・テスト実行までを自律的に行うAIエージェントの頭脳部分——としての利用を想定して調整されている。 xAIの主張によれば、Grok 4.5をコーディングエージェントのバックエンドとして使った場合、従来モデル比で最大80%のコスト削減が可能で、応答速度も業界最速クラスのモデル群(いわゆる「フロンティアモデル」)に迫る水準に達しているという。 コスト8割減と引き換えの代償 Artificial Analysisは独立系のAIベンチマーク機関で、各社のモデルを共通基準で横並び評価していることで知られる。同社の検証では、Grok 4.5はタスクの正答率(accuracy)についても旧モデルの35%から52%へと大幅に向上したと報告されている。 一方で見過ごせないのが幻覚の発生率だ。同じ検証で、旧モデルの25%から54%へとほぼ倍増したことが確認されている。単に「間違える」だけでなく「自信満々に間違える」傾向が強まっている点が指摘されており、正答率の向上と幻覚率の悪化が同時に進行するという、やや異例のトレードオフとなっている。 実務への影響 日本のエンジニアやIT管理者にとって、この一件が示す教訓は明確だ。コーディングエージェントの導入コストは今後も下がり続ける可能性が高い一方、「速くて安いが、たまに自信満々に嘘をつくモデル」をどう安全に運用するかが、AIエージェント活用の実務上の課題になる。 具体的な対策としては以下が考えられる。 自動テスト・CIとの組み合わせを必須にする: コーディングエージェントが生成したコードは、人間のレビューだけでなくユニットテスト・統合テストを機械的に通過させる仕組みを作る。幻覚率が上がったモデルほど、この「検証ゲート」の重要性が増す 重要度に応じてモデルを使い分ける: コストが安いモデルを定型的なリファクタリングやボイラープレート生成に、精度が求められる設計判断やセキュリティ関連のコードには別モデルや人間のレビューを充てるといった、タスクの重要度に応じた使い分けが有効 ベンチマークの数字を鵜呑みにしない: 正答率や幻覚率は測定条件に強く依存する。自社のユースケースで実際に試し、幻覚がどのパターンで起きやすいかを自分の目で確認するプロセスを省略しない 筆者の見解 筆者はふだんコーディングエージェントの中心にClaude Codeを据えて実務を回している立場だが、xAIやOpenAI、Googleを含め各社がコーディングエージェント向けにモデルを最適化し、価格競争を繰り広げていること自体は歓迎すべき流れだと考えている。コストが下がれば下がるほど、AIエージェントを気軽に、大量に使う選択肢が広がるからだ。 ただし今回のGrok 4.5の件が示すように、コスト削減と精度・信頼性はトレードオフになりやすい。コーディングエージェントの本質は人間の確認作業を減らすことにあるはずで、幻覚率が倍増したモデルは、たとえ処理コストが8割減っても、人間による検証コストがその分増えてしまっては本末転倒になりかねない。トークン単価だけを見て「安くなった」と評価するのではなく、検証コストも含めたトータルの運用コストで判断すべきだろう。 もう一つ強調したいのは、新モデルが出るたびに一喜一憂して追いかけ回す必要はないということだ。次々と登場する新モデルの性能比較を追いかけるより、自分が使い慣れたエージェント環境の中で、テストやCIを組み込んだ検証ループをどれだけ堅牢に作り込めるかの方が、実務上のリターンははるかに大きい。Grok 4.5のニュースも「このモデルに乗り換えるべきか」ではなく、「自分の開発フローの検証ゲートは、幻覚率が多少上下しても壊れない設計になっているか」を点検するきっかけとして受け止めるのがちょうどいい。 出典: この記事は Grok 4.5 Cuts Coding-Agent Cost 80%: Near-Frontier Speed, Higher Hallucinations の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは現地時間7月14日、月例セキュリティ更新プログラム「Patch Tuesday」を公開する。事前予測では修正件数は100〜140件程度とみられ、記録的だった6月の206件からは落ち着くものの、2026年を通じて続く高水準は変わらない見通しだ。さらに同日は、レガシー暗号方式「RC4」を使ったKerberos認証を強制的に無効化する第2フェーズの完了期限とも重なり、ドメイン参加環境で認証エラーが多発するリスクが警告されている。 6月の206件から本来のペースへ、それでも高水準は続く 6月のPatch TuesdayではWindows 11向けに116件、Windows 10向けに104件を含む合計206件のCVEが公開され、Office・SharePoint Server・Visual Studio・.NETなど開発ツール群にも修正が及んだ。これだけの規模にもかかわらず、緊急パッチにあたるOOB(Out-of-Band)リリースは今月発生しておらず、Windows Server 2016の更新不具合修正や、ごみ箱に内部ファイル名が表示される軽微な表示バグへの対応にとどまっている。 もう一つの山場——Kerberos RC4強制廃止の完了期限 7月14日は、老朽化した暗号方式RC4を用いたKerberos認証を段階的に排除する取り組みの第2フェーズが完了する期限でもある。ドメインコントローラーやレガシーアプリケーションでRC4依存が残っている環境では、この期限を境に認証エラーが顕在化する可能性が高い。パッチ適用と認証方式の見直しという2つの作業が同じタイミングで発生するため、IT管理者にとっては負荷の高い1週間になりそうだ。 RoguePlanetゼロデイとランサムウェアに悪用されるBlueHammer 研究者Nightmare-Eclipseが新たに公表したゼロデイ「RoguePlanet」(CVE-2026-50656)は、Microsoft Defenderに存在するレース コンディション型の権限昇格の脆弱性で、GitHub上のPOC(概念実証)コードを使うとSystem権限のシェルを取得できるという。Defenderを標的とした脆弱性報告はここ最近続いており、緊張関係が続いている。加えてCISAは、既に修正済みの脆弱性「BlueHammer」がランサムウェアの攻撃に悪用され始めていると発表しており、次の攻撃対象になる前にパッチ適用状況を再確認しておく必要がある。 Windows 11 26H2がInsiderへ、Windows 10 ESUは無償で1年延長 Microsoftは、次期機能更新版「Windows 11 26H2」をWindows Insiderの開発チャネルで提供開始したと発表した。24H2・25H2と同じサービスチャンネルに属するため、Enablement Package(有効化パッケージ)による軽量な更新が可能で、OS丸ごと入れ替えが必要な23H2以前からの移行に比べて負荷が小さい。なお26H1は同じサービスチャンネルには含まれず、カーネルも異なるため、別途の更新経路が用意される予定だ。また、コンシューマー向けWindows 10の無償ESU(拡張セキュリティ更新プログラム)提供が2027年10月まで1年延長されたが、企業向けは一部例外を除き引き続き有償サブスクリプションが必要となる。 CVE個別追跡はもう限界か——業界全体の潮目 脆弱性発見にAIが本格活用され始めたことで、パッチ管理業界全体の前提が揺らいでいる。Adobeは、月1回だった定例セキュリティリリースを月2回体制に切り替えると発表した。直前にはColdFusionの6件の脆弱性(最大CVSS 10.0)をまとめて修正したばかりで、Adobe自身も「月1回の公開サイクルではもはや攻撃者に追いつけない」と説明している。同様の動きはGoogleにも見られ、Chrome 150では433件ものセキュリティ修正が一度に行われた。AppleもOSの更新頻度を年間を通じて増やす方針へと転換しつつある。もはやCVEを1件ずつ追跡管理する手法自体が現実的でなくなりつつあり、現場では「個別のCVEを追うより、ベンダーの最新リリースを可能な限り早く当てる」という運用へのシフトが進んでいる。 実務への影響 日本企業のIT管理者にとって、今回のPatch Tuesdayは単なる「月例パッチ」以上の重みを持つ。まずKerberos RC4廃止の期限は、レガシーな業務システムやドメインコントローラーを多く抱える大企業ほど影響が大きい。事前に自環境でRC4依存の有無を棚卸ししておかないと、パッチ適用日当日に認証障害という形で表面化しかねない。また、CVE個別追跡が限界を迎えつつあるという指摘は、日本の現場にもそのまま当てはまる。四半期ごとの棚卸し型のパッチ管理では、もはやこのペースについていけない。WSUS・Intune・Azure Update Managerなどを使った自動適用の比率を上げ、「重大な脆弱性を手動で選別してから当てる」運用から、「まず当てて、問題が起きたものだけ手動対応する」運用へと発想を転換すべき局面に来ている。 筆者の見解 CVEを1件ずつ真面目に追いかける時代はもう終わりつつある、というこの記事の指摘には強く同意する。情報を追いかけること自体を目的化しても、脆弱性の発見ペースにAIが本格的に使われ始めた以上、人間が全件を精査して優先順位をつけるやり方は遠からず破綻する。ここは「まず当てる、問題が起きたら対処する」という運用に振り切る勇気が必要な局面だと思う。 Kerberos RC4の強制廃止についても、方向性としては正しい。認証層に古い暗号方式を残しておくこと自体が最大のリスクであり、常時アクセス可能な弱い認証経路をなくしていく取り組みはゼロトラストの発想そのものだ。とはいえ、実際にこの期限で認証障害を出す企業が一定数出てくるだろうことも予想がつく。Microsoftには、廃止の判断自体は応援したいが、影響を受ける環境の可視化ツールやロールバック手順の周知にもう一段の力を入れてほしい。せっかく正しい方向に舵を切っているのだから、現場が混乱せずについていける形で進めてもらいたいところだ。 出典: この記事は July 2026 Patch Tuesday forecast: Is CVE tracking still practical? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ソニーは2026年7月9日（現地時間）、高倍率ズーム一体型カメラ「RX10」シリーズの第5世代モデル「RX10 V」を発表した。PR Newswire経由のプレスリリースによると、前モデルRX10 IVから9年ぶりのフルモデルチェンジで、αミラーレスシリーズ譲りのAI被写体認識AFと操作性を取り込みつつ、24-600mm相当・F2.4-4.0の大口径25倍ズームレンズを1台に凝縮した。発売は2026年8月、価格は2,299.99米ドル（1ドル150円換算で約35万円）。 スペックのポイント：AI認識AFと25倍ズームを凝縮 レンズ: ZEISS Vario-Sonnar T* 24-600mm相当 F2.4-4.0（光学25倍、光学式手ブレ補正内蔵）。マクロは24mm側で約3cm、600mm側で約72cmまで寄れる「望遠マクロ」に対応。 センサー/画像処理: 有効約2010万画素の1.0型積層Exmor RS CMOSセンサーと画像処理エンジンBIONZ XRを組み合わせ、中〜高感度域のノイズを抑制。4K 120p撮影にも対応する。 AF性能: AIプロセッシングユニットが人物・動物・鳥・昆虫・乗り物などを自動認識する「リアルタイム認識AF」を搭載。人物はポーズ推定によりヘルメットやサングラス着用時も追尾できる。ブラックアウトフリーで最高30コマ/秒の連写が可能で、AF/AE演算は最大60回/秒。 EVF・操作性: 従来機より大型化したQuad-VGA OLEDファインダーを採用し、αミラーレスシリーズ譲りのボタン配置・グリップ形状で操作の一貫性を高めた。バッテリーはNP-FZ100で約630枚撮影可能（前モデル比約50%増）。 12種類のクリエイティブルックと、上限をLv8まで拡張したDレンジオプティマイザーも搭載する。 海外レビューのポイント 今回はソニー公式のプレスリリースであり、独立系メディアによる実機レビューは製品発売（2026年8月）以降に出揃う見込みだ。現時点で確認できる評価コメントは、ソニー・エレクトロニクスでImaging Solutions担当バイスプレジデントを務めるYang Cheng氏によるもので、「RX10シリーズは実際の撮影シーンで扱いやすく、コンパクトなボディでこれだけの焦点距離をカバーできる点がカルト的な人気を生んだ」という趣旨のコメントを寄せている。前モデルRX10 IVは海外メディアから「1台で広角から超望遠までこなせる汎用性」を評価される一方、「1.0型センサーゆえの高感度ノイズ」や「APS-C・フルサイズ機と比較した際の価格対性能」を指摘されてきた経緯があり、RX10 Vでも同様の論点が実機レビューの焦点になるとみられる。 日本市場での注目点 日本では歴代RX10シリーズが「DSC-RX10M」の型番で発売されており、RX10 Vも国内投入時は同様の型番になる可能性が高い。前モデルRX10 IVの国内発売時価格は25万円前後だったが、今回の米国価格（2,299.99ドル）から換算すると国内実勢価格は35万円前後になると予想される（為替・税込み価格は国内正式発表待ち）。競合としては、同じ1.0型センサー・25倍ズームを搭載しながら実勢価格が10万円台のパナソニック「LUMIX DC-FZ1000M2」が挙げられ、AI認識AFの精度と価格差をどう評価するかが購入判断の分かれ目になりそうだ。望遠・野鳥・スポーツ撮影用途で複数レンズを持ち歩きたくないユーザーには、依然として有力な選択肢となる。 筆者の見解 今回の目玉は、αミラーレスで培われたリアルタイム認識AFや操作系をそのままRX10シリーズに移植してきた点だ。新しい仕組みをゼロから作るのではなく、すでに実績のある技術を横展開する堅実なやり方で、奇をてらわない「王道」のアップデートだと感じる。レンズ交換の手間や機材の管理コストを減らしたい旅行・野鳥・スポーツ撮影ユーザーにとって、1台で広角から超望遠までこなせる一体型カメラという方向性は理にかなっている。 一方で、35万円前後になりそうな価格は正直軽くはない。APS-Cやフルサイズのミラーレス+望遠レンズという選択肢も視野に入る価格帯であり、「1.0型センサーで画質は十分か」「AF性能はスペック通り実戦投入できるか」は、実機レビューが出揃うまで判断を保留すべきポイントだろう。発表内容だけで評価を確定させず、発売後の第三者レビューでAF追従性やノイズ耐性を見極めてから購入を判断するのが堅実だと思う。 関連製品リンク SONY (ソニー) Cyber-shot RX10IV Compact Digital Camera Black 1.0-inch Stacked CMOS Sensor 25x Optical Zoom (24-600mm) Articulating LCD Monitor 4K Video Recording DSC-RX10M4 ...

OpenAIは2026年7月10日、独自開発のAIブラウザ「Atlas」を2026年8月9日をもって終了すると発表した。米Tom’s Guideのアマンダ・キャスウェル記者が報じたところによると、Atlasが持つWebページ要約やエージェント型のタスク実行機能は消えるわけではなく、ChatGPT Work、ChatGPTデスクトップアプリ、そして新たに投入されるChrome拡張機能へと移植される。ローンチから1年に満たないタイミングでの終了は、「AIブラウザ」というカテゴリー自体の位置づけの転換を象徴する出来事だ。 なぜAtlas終了が注目か Atlasは2025年後半、Webページの要約・質問応答・エージェントによる自動操作までこなす「AIファーストブラウザ」として鳴り物入りで登場した。しかし独立したブラウザとして普及させるには、Google ChromeやApple Safariという巨大な牙城を崩し、ユーザーに「ブラウザそのものを乗り換えさせる」という高いハードルが立ちはだかっていた。OpenAIは今回、ブラウザを置き換えるのではなく、ユーザーがすでに使っているブラウザやアプリをAIで賢くする方向へ舵を切った。今年前半に相次いだ「AIブラウザは次のプラットフォームになる」という業界の熱狂が、実装レベルでは異なる着地点に収束しつつあることを示す象徴的な事例といえる。 Tom’s Guideが伝える報道のポイント Tom’s Guideのキャスウェル記者は、自身もChromeユーザーとしてAtlasへの乗り換えに苦労した経験に触れながら、「技術面よりも習慣を変えることの難しさこそがAtlasの課題だった」と分析している。同記事によると、既存のAtlasユーザーには今後数週間かけて移行案内が行われる予定で、機能自体が失われるわけではない点が強調されている。またこの決定は、AI各社が「専用ブラウザで主導権を握る」戦略から「既存の作業ツールにAIを組み込む」戦略へとシフトしている業界トレンドの一環だとも位置づけられている。 日本市場での注目点 日本ではAtlas自体がまだ広く浸透していなかったこともあり、今回の終了による実害は限定的とみられる。むしろ注目すべきは、ChatGPTデスクトップアプリとChrome拡張機能という、日本のユーザーにとって導入障壁の低い形でエージェント機能が提供される点だ。専用ブラウザへの乗り換えを迫られることなく、普段使いのChrome環境でWeb操作の自動化やページ要約が使えるようになれば、日本語ユーザーの利用率も上がりやすい。Chrome拡張機能の提供時期や日本語対応の詳細は現時点で未発表のため、続報を待ちたい。 筆者の見解 今回の方向転換は、AIエージェントが目指すべき姿を考えるうえで示唆に富む。AIエージェントの本質的な価値は、人間の作業をわざわざ新しい入口に呼び寄せることではなく、すでにある作業導線の中に溶け込み、確認の手間を減らしながら自律的にタスクをこなすことにある。独立したブラウザという新しい「行き先」を作る発想は部分最適に陥りやすく、結果的にユーザーの選択肢を増やすだけに終わりかねない。ChatGPTやChrome拡張という、すでに多くの人が毎日開いているツールにエージェント機能を統合する今回の判断は、その意味で理にかなっている。 とはいえ肝心なのは、移植された機能が「確認を求め続けるだけの補助輪」で終わらず、目的を伝えれば自律的にタスクを遂行できるレベルまで踏み込めるかどうかだ。従来型の「副操縦士」的な体験にとどまるのか、本当の自律エージェントとして機能するのかで評価は大きく分かれる。ニュースの見出しを追うだけで判断せず、Chrome拡張やデスクトップアプリが実際に使えるようになった段階で、自分の作業に組み込んで試してみる価値は十分にある。 出典: この記事は OpenAI is shutting down its AI browser — but ChatGPT users are getting something better の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Metaは2026年7月8日、Instagramの新しい画像生成AIモデル「Muse」に関連する機能として、公開アカウントを「@」でタグ付けするだけでその投稿画像を参照したAI生成画像を作れる仕組みを発表した。しかし公開からわずか数日で「本人の同意なく他人の肖像を使ったディープフェイクを助長する」との強い批判を浴び、Metaは同機能を全面停止した。 何が起きたのか 問題となったのは、Museの画像生成時に公開Instagramアカウントを@メンションすると、そのアカウントが投稿してきたコンテンツを参照した画像を誰でも生成できるという仕様だ。対象は本人が同意した相手に限らず、公開設定のアカウントであれば原則として誰の投稿でも参照可能だった。オプトアウトの手段は用意されていたものの、設定画面の奥深くに埋もれており、機能はデフォルトで有効になっていた。 性的搾取防止に取り組む非営利団体「National Center on Sexual Exploitation」のHaley McNamara氏は「自分自身の肖像に対する権利を明らかに侵害するだけでなく、セクストーションなど詐欺の道具になり得る」と厳しく批判。俳優組合SAG-AFTRAも会員に対しオプトアウトを推奨し、その手順を公式に案内する事態となった。 Metaは公式ブログの更新で「有用な創作ツールを提供する意図だったが、狙いを外したというフィードバックを受け止め、機能の提供を停止した」と説明している。 「オプトアウト任せ」の設計が招いた炎上 今回の本質的な問題は技術力ではなく同意設計（コンセントデザイン）にある。「本人が明示的に許可した場合のみ利用可能」というオプトイン設計ではなく、「デフォルトで利用可能、嫌なら自分で探して止める」というオプトアウト設計を採用したことが炎上の火種になった。生成AIが個人の投稿や肖像を扱う機能では、この設計順序を間違えると影響範囲が一瞬で拡大する。 実務への影響 日本のエンジニア・IT管理者にとっても他人事ではない。生成AIを使って第三者のコンテンツ（写真・投稿・音声など）を参照する機能を設計する際は、必ず「デフォルトはオプトイン」を徹底すべきだ。社内向けツールでも、社員の顔写真やSNS投稿を参照する生成AI機能を安易に実装すると、同様のリスクを抱え込むことになる。 日本には肖像権・パブリシティ権に関する判例の蓄積があり、無断でのAI生成物への肖像利用は法的リスクを伴う。生成AI機能をリリースする前に、悪用シナリオ（なりすまし、誹謗中傷、性的搾取目的の利用など）を想定したレッドチーム的な事前レビューを行う体制を、開発フローに組み込んでおくことが望ましい。 筆者の見解 今回の一件は、生成AIの実装力そのものよりも「安全に使える既定値をどう設計するか」がプロダクトの成否を分けることを改めて示している。禁止で縛るのではなく、最初から安全な既定値の中でユーザーが安心して使える仕組みを用意する——これは生成AI機能を作るすべての企業に共通する基本のはずだ。Metaほどのリソースと規模を持つ企業であれば、公開前にこの種のリスクを潰す体制を敷けたはずで、その意味では「もったいない」対応だったと言わざるを得ない。 生成AIの活用が広がるほど、個人の肖像や投稿を扱う機能の設計には一段と慎重さが求められる。日本企業が同様の機能を検討する際は、今回のInstagramの事例を「デフォルト設計を間違えると信頼を一瞬で失う」という反面教師として活用してほしい。 出典: この記事は Meta turns off the Instagram feature that let users make AI deepfakes of public accounts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Appleは現地時間2026年7月10日、OpenAIおよびJony Ive氏が率いるハードウェアスタートアップIO Productsを相手取り、企業秘密（トレードシークレット）の窃取を理由に提訴した。Appleは訴状で「OpenAIに在籍する元Apple社員による、組織的な企業秘密の窃取パターン」を発見したと主張しており、単なる人材流出ではなく計画的な情報持ち出しがあったとしている。 何が疑われているのか 訴状で名指しされているのは、OpenAIのチーフ・ハードウェア・オフィサーであるTang Tan氏と、2026年1月にAppleからOpenAIへ移ったChang Liu氏の2人だ。 Apple側の主張によれば、Liu氏は退職後もAppleの社内システムにアクセスし、未発表製品の詳細なハードウェア関連ファイル、エンジニアリング資料、技術仕様、独自プロジェクトデータなど数十件の機密ファイルをダウンロードしたとされる。さらに、Apple在籍中の元同僚に対し機密ファイルのコピー方法とセキュリティチームに「トラブルにならない」方法を指南し、検知を避けるためLINE Messengerでやり取りするよう持ちかけたという。 Tan氏についても、退職前にAppleのサプライヤー情報を自分宛にメール送信していたほか、Apple従業員をOpenAIの採用面接に呼ぶ際、Appleの機密情報の提供を求めていたとApple側は主張する。OpenAIは面接に訪れるApple従業員にCAD/デザインデータやプロトタイプの持参を促していたとも指摘されている。 Appleは、400人を超える元Apple従業員が現在OpenAIに在籍しているとし、OpenAIが退職予定のApple従業員に「Appleから何かにサインするよう求められたら教えてほしい」と伝えていたとも主張している。OpenAI広報は「他社の企業秘密に興味はない」とThe Vergeに述べ、疑惑を否定している。 Jony Ive氏のIO Productsも被告に 訴訟でOpenAIと並んで名指しされているのが、Jony Ive氏が設立し、OpenAIが2025年に買収したハードウェアスタートアップIO Productsだ。IveはAppleのデザインを長年率いた人物であり、IO ProductsはOpenAIのAIネイティブなハードウェア製品開発の中核を担うとされる。Appleが「数十年かけて築いた消費者向けハードウェア事業のノウハウを再現しようとする組織的な試み」と表現する背景には、OpenAIがソフトウェア企業の枠を超え、Appleと同じハードウェア市場に本格参入しようとしていることへの強い警戒がある。 実務への影響 — オフボーディングとサプライヤー管理の見直しを 日本のIT現場にとっても他人事ではない。生成AI人材の争奪戦が激化する中、優秀なエンジニアの転職は今後さらに増える。今回のケースが突きつけるのは、退職者のアクセス権限を「退職日にきちんと止める」という、地味だが極めて重要な運用の徹底だ。SaaSアカウント、社内システム、コード管理基盤へのアクセスが退職後も生きていないか、オフボーディングのチェックリストを見直したい。 またApple側は、サプライヤー企業がAppleの独自プロセスを他社のために実行していたとも主張している。委託先を通じた情報流出は日本企業でも起こりうるリスクであり、契約書の秘密保持条項の実効性やパートナー企業側の情報管理体制の点検にも価値がある。日本の不正競争防止法も営業秘密を保護するが、実際に立証まで持ち込むにはAppleのように「持ち出しの証跡」を体系的に押さえる備えが参考になる。 筆者の見解 今回の訴訟は、AI企業がソフトウェアの世界からハードウェアという新しい戦場に踏み出したことで、既存の巨大企業との摩擦が顕在化した典型例だと見ている。OpenAIがIO Productsを買収してまでハードウェアに本気で取り組んでいるのは業界にとって刺激的な動きだ。ただし、今回Appleが主張する内容——退職後のシステムアクセスや検知回避を意図したやり取りの指南——が事実であれば、これは競争の話ではなく単純なコンプライアンス違反であり、擁護のしようがない。 AI業界全体で人材の流動性が高まるのは健全なことだが、それは秘密保持義務や契約上の制約を守った上での話だ。Microsoft周辺でもAI人材の獲得競争は同様に激しく、この種のトラブルは対岸の火事ではない。企業として大事なのは、優秀な人材が正規のルートで移籍しても不利益がない仕組みと、機密情報へのアクセス管理を両立させることだろう。訴訟の行方自体よりも、この一件が各社のオフボーディングや情報管理体制を見直すきっかけになるなら、業界にとって悪くない副産物だと思う。 出典: この記事は Apple sues OpenAI for allegedly stealing hardware secrets の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ソフトウェアエンジニアのAlec Scollon氏は7月8日、自身のブログで「LLM燃え尽き症候群になったかもしれない」と告白した。仕事ではAnthropicのClaude Code、自宅ではOpenAIのCodexを毎日何時間も使い続けてきた同氏は、生産性の向上を実感する一方で、AI生成テキストに特有の「紋切り型の言い回し」や「過剰な絵文字」、そして繰り返される事実誤認（ハルシネーション）に強い疲労を感じ始めたという。この投稿はHacker Newsで328ポイント・266件のコメントを集め、多くの開発者から共感の声が上がっている。 「コーディング」から「LLM出力のレビュー」へ変わった仕事 Scollon氏の日々の仕事は、かつての「設計してコードを書く」というスタイルから、「設計を考え、Claude CodeやCodexに説明し、生成されたコードをレビューし、最後に自分でコードを書く」という流れに変化した。現在の主な取り組みは、社内のコードベースで大規模かつ人手を介さないコード生成の仕組みを構築することだ。Claude Codeでそのためのツールを作る一方、オープンウェイトモデルのQwenを使った自律型エージェントが生成した大量のコードをひたすらレビューする毎日を送っている。検索も同様で、知りたいことがあればまずChatGPTに聞くかGeminiの概要を読み、答えが怪しいときだけ従来型のブラウジングに戻るという。 疲労の正体は「ツールの不安定さ」ではなく「パターンの反復」 Scollon氏が強調するのは、LLMの間違いや癖そのものではなく、その「反復性」が疲労の原因だという点だ。断定的で短く区切られた文体、過剰な絵文字、同じ種類のハルシネーション――これらは個別には気にならなくても、毎日大量に浴び続けると精神的な負荷になる。人間の文章にも癖や間違いはあるが、LLMは無数の他人が生成した文章にも触れる機会が多く、自分では文体をカスタマイズできても、他者が生成したAIコンテンツの「型」までは制御できない。 実務への影響 日本のIT現場でも、Claude CodeやGitHub Copilot、ChatGPTなどを日常的に使うエンジニアやIT管理者が急増している。この記事が示すのは、AI活用の「量」を追いかけるフェーズが一段落し、次は「AI生成物とどう付き合うか」という質のフェーズに入ってきているということだ。具体的には次のような対策が現実的だ。 カスタムインストラクションで文体を制御する: Claude Codeの CLAUDE.md やChatGPTのカスタム指示、Copilotのプロンプト設定などで、絵文字の使用や文体のトーンを事前に指定しておくと、反復疲労をある程度軽減できる レビュー方式を見直す: 生成コードを1行ずつ人間が読む方式のままでは、生成量が増えるほど疲弊が加速する。テストやCIでの自動検証を厚くし、人間のレビューは「設計判断」や「危険な変更」に絞り込む設計に切り替える チームのAI活用ルールを明文化する: 個人の裁量に任せると、生成文章の文体やレビュー負荷がメンバーごとにばらつく。ドキュメントやコミットメッセージの生成ルールをチームで統一すると、読み手の負担も減る 筆者の見解 この告白は率直に「あるある」だと感じた。人間がAIの生成物を一行ずつ検証し続ける限り、いくら生成速度が上がっても人間側のレビュー負荷はむしろ増える。これはAIエージェントの設計思想の問題で、確認や承認を人間に求め続ける「副操縦士」型の使い方をしている限り、燃え尽きは避けられない構造だと考えている。 本来AIエージェントが果たすべき役割は、人間の認知負荷を減らすことのはずだ。Scollon氏自身、Qwenによる自律エージェントの出力をひたすらレビューする作業に時間を取られているというが、これはまさに「人間がまだ確認係から抜け出せていない」状態を象徴している。目的とガードレールを渡したら、あとはエージェントが自律的にループを回して判断・実行・検証まで済ませ、人間は結果とリスクの高い判断だけを見る――そういう「ハーネスループ」的な設計に踏み込むフェーズに来ているはずだ。 情報を追いかけて「あれも試した、これも試した」と広く浅く手を広げるより、自分の手元の仕組みを一つ実際に動かし、そこで見えてきた摩擦（今回でいえば「レビュー疲れ」）を仕組みの改善にフィードバックしていく方が、今の時期は圧倒的に生産的だと思う。Scollon氏の疲労は、AIを使いすぎた結果ではなく、AIの使い方をまだアップデートできていないサインとして受け止めるのが正しい読み方ではないだろうか。 出典: この記事は I think I have LLM burnout の内容をもとに、筆者の見解を加えて独自に執筆したものです。

サムスンが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点が事実であれば、折りたたみ機を「ギミック」ではなく日常の道具として使う上で意味のあるアップデートになる。画面の折り目は長らく折りたたみ機の弱点として指摘され続けてきた部分であり、そこに正面から手を入れてきたのであれば素直に評価したい。 ...

Microsoft Teams meetingsに、外部AIボットを自動検知してロビー（待機室）に留め置く新しい保護機能が追加される。Microsoftが2026年7月9日(米国時間)に公式ブログで発表したもので、Otter.aiやFireflies、Read.aiといった外部の会議録音・文字起こしボットが会議に参加しようとした際、既定で待機室に足止めし、ホストが明示的に許可するまで参加させない仕組みになる。管理者は「外部ボット管理」ポリシーをユーザー単位・グループ単位で個別に割り当てられる。 何が起きるのか これまでTeams会議は、リンクさえ知っていれば外部の録音・文字起こしボットが会議室に「参加者」として入り込むことができた。会議主催者が気づかないまま、社外のAIサービスに会議内容が送信され、要約・保存されるケースも珍しくない。今回の機能は、こうした外部ボットを自動的に識別し、既定で「ロビー」に足止めする。人間の参加者と同様に、ホストが個別に入室を許可しない限り会議には参加できない。 管理者向けにはTeams管理センターに新しい「外部ボット管理」ポリシーが追加される。既存の会議ポリシーと同様、テナント全体・特定グループ・特定ユーザー単位で挙動を変更できるため、たとえば営業部門には特定の議事録ボットの利用を許可しつつ、それ以外の部門では原則ブロックする、といった柔軟な運用が可能になる。 展開スケジュール 2026年7月にロールアウトが始まり、8月に一般提供(GA)、9月にはポリシー未設定のテナントにも既定で適用される。つまり管理者が何もしなければ、9月以降は自動的に外部ボットがロビー待機の対象になる。 実務への影響 日本企業でも、AI議事録ツールは会議の生産性を大きく高める一方、統制のかからない形で普及していることが多い。会議参加者の一人が個人契約のAIボットを招待し、社外秘の会議内容が海外のクラウドサービスに送信されているケースは、情報漏えいのリスクとして見過ごせない。今回の機能は、こうした「野良ボット」の混入を防ぐ最初の一歩になる。 IT管理者は9月の既定適用を待たず、まず社内でどの議事録ボットが実際に使われているかを棚卸しすることをお勧めする。そのうえで、業務上必要なツールだけをグループ単位で許可リストに載せ、それ以外は原則ブロックする設計にすれば、利便性を損なわずに統制を効かせられる。会議主催者にも、ロビーに知らないボットが現れたときの対応方針(安易に許可しない)を周知しておく必要がある。 筆者の見解 この機能は、ゼロトラストの発想を会議室という身近な場所に持ち込んだ好例だと感じる。ボットやAIエージェントのような「人間ではない身分(Non-Human Identity)」に常時アクセス権を与えるのではなく、既定は拒否、必要なときだけ明示的に許可するというJust-In-Time的な設計は、筆者が普段から重要だと考えている考え方そのものだ。 なにより評価したいのは、「外部ボットを一律禁止」にしなかった点だ。禁止だけのアプローチは必ずどこかで抜け道が生まれ、結局はシャドーIT化する。今回のように、既定は安全側に倒しつつ、管理者が業務に必要なツールを個別に許可できる仕組みにしたことで、現場の利便性を落とさずに統制できる。Microsoftのセキュリティ機能は地味に映ることも多いが、こうした「安全に使える仕組み」を丁寧に積み上げていく姿勢は、もっと評価されてよいと思う。 出典: この記事は Introducing smarter bot protection in Microsoft Teams meetings の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年7月9日、Teamsに7つの新機能をロールアウトすると発表した。プライベートチャンネルでのアプリ対応、Teamsイベント向けの新しい表示レイアウト、クラウドファイル検索の強化などが含まれる一方、ミーティングを最小化した状態でも挙手やリアクションができるようにする新機能については、不具合修正のためロールアウトを一時停止したことも明らかにした。 プライベートチャンネルでもアプリが使えるように これまでTeamsの「プライベートチャンネル」では、ボットやメッセージ拡張機能、タブといったアプリ機能が制限されていた。共有チャンネルでは利用できたこの機能が、ようやくプライベートチャンネルにも解禁される。2026年1月から段階的に展開されてきたが、6月末以降に対象ユーザーが大きく拡大し、7月末までに全ユーザーへの展開が完了する見込みだ。 Teamsイベントは「話者中心」レイアウトへ ウェビナーやライブイベント機能「Teams イベント」にも変更が入る。従来は画面共有時に発表者の映像が小さくなりがちだったが、新しい「Speaker-focused（話者中心）」レイアウトでは、発表者の映像と共有コンテンツの両方を強調する表示に切り替えられる。主催者は「参加者に表示する内容の管理」から設定できる。 ファイル共有・ダウンロード周りの改善 添付ファイルピッカーに「クラウドファイルを添付」という新しい選択肢が加わり、SharePoint上のファイルを検索して直接添付できるようになる。また、チャットやチャネルの画像を右クリック（またはホバー）すると新しい「クイック共有」ボタンが表示され、既存の閲覧権限を維持したまま画像リンクをコピーできる。地味だが、ダウンロードマネージャーの刷新（通知の扱い改善、保存先の分かりやすさ向上）も含め、日常業務で効いてくる改善が多い。 一時停止されたマルチタスキング改善機能 一方で注目されていたのが、ミーティングウィンドウを最小化した状態でも、フルウィンドウを開かずに挙手やリアクションができるようにする機能だ。会議をしながら他の作業を並行して行う「マルチタスキング」の使い勝手を大きく改善するはずだった機能だが、一部ユーザーからの評判が芳しくなく、Microsoftはバグ修正のため展開を一時停止したという。 実務への影響 日本企業のTeams管理者にとって、まず確認すべきはプライベートチャンネルでのアプリ許可だ。共有チャンネルとは別に、テナントやチームの管理者ポリシーでアプリ利用を制御している場合、想定外のアプリが利用可能になる、あるいは逆に必要なアプリが使えないといった問い合わせが増える可能性がある。展開は7月末までに段階的に進むため、ロールアウト時期のばらつきをあらかじめ社内に周知しておくと混乱を防げる。 クラウドファイル検索やクイック共有は、SharePoint・OneDrive中心のファイル運用を徹底している組織ほど恩恵が大きい。逆に言えば、ローカル保存やメール添付での共有が残っている現場では、この機会にファイル共有ルールを整理する良いタイミングとも言える。 筆者の見解 Teamsはここ数年、数週間おきに機能を積み重ねる開発スタイルを続けている。クラウドサービスとして継続的に改善し続けること自体は正しい姿勢だ。ただ、今回のように目玉機能を一度出してからロールバックする場面がたびたび見られるのは気になるところだ。ユーザーの反応を見て素早く引っ込める判断力自体は評価できるが、そもそも社内テストの段階でもう少し磨き込んでから世に出してほしいと感じる。 Teamsはビジネスチャットのデファクトスタンダードと言える立場にあり、正面から勝負できる実力を十分に持っているはずだ。だからこそ、一つひとつの機能を丁寧に仕上げて出せば、もっと安心して新機能を使えるプラットフォームとして評価が上がるはずだと思う。今回一時停止されたマルチタスキング改善機能も、完成度を高めたうえで戻ってくることを期待したい。 出典: この記事は Microsoft Teams just added 7 new features, but paused the one that fixed multitasking in meetings の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAとセガは、両社が築いてきた30年にわたる関係を記念するゲリラ的なイベントを、2026年7月15日17時から18時まで、東京・秋葉原の「GiGO秋葉原3号館」で開催する。PC Watchが報じたところによると、イベントにはNVIDIAの創業者兼CEOであるジェンスン・フアン氏が来日して登壇し、新製品「NVIDIA RTX Spark」を披露するほか、来場者の中から抽選でハイエンドGPU「GeForce RTX 5090 Founders Edition(FE)」がプレゼントされる。 なぜこのイベントが注目か NVIDIAのCEOがゲームファン向けのイベントに直接足を運ぶこと自体が異例だ。フアン氏はここ数年、AI関連の基調講演で世界を飛び回っているが、今回はセガという日本のゲーム文化を象徴するパートナーとの節目を祝う場に立つ。ラインナップも象徴的で、ゲーミングの頂点である「RTX 5090」と、名称からAI寄りの用途が想起される新製品「RTX Spark」を同じ会場で並べることで、NVIDIAが「ゲーミングGPUの会社」から「AIコンピューティングの会社」へと軸足を広げていることを、ファンの目の前で体現しようとしているように見える。 GeForce RTX 5090 FEはどんなGPU RTX 5090はNVIDIAの最新世代「Blackwell」アーキテクチャを採用するフラッグシップGPUで、2025年1月に発売済みだ。CUDAコアは21,760基、メモリは32GB GDDR7(512bitバス)を搭載し、消費電力(TDP)は575Wに達する。4KはもとよりAI処理を活用したDLSS 4により、8K解像度でも実用的なフレームレートを狙える性能が特徴で、国内の実勢価格は発売時点で40万円前後だった。 海外レビューが伝える評価 海外メディアのレビューでは、レイトレーシングやAI推論を含む総合性能で「文句なしに世界最速」という評価が一致していた一方、575Wという消費電力の大きさや、カード単体で2kg近くになるサイズ・重量、そして高価格帯であることを繰り返し指摘する声も多かった。発売直後には一部のRTX 5090・RTX 5070 Ti搭載カードでROP(描画処理ユニット)の欠損が見つかり、海外メディアが一斉に報じる一幕もあった。性能と代償(価格・電力・サイズ)のトレードオフが大きいカードであることは、押さえておきたいポイントだ。 NVIDIA RTX Sparkは何者か 今回の会場で初披露されるという「NVIDIA RTX Spark」については、現時点で公式な仕様が公開されていない。名称から、2025年に登場した小型AIコンピュータ「DGX Spark」系統の製品、あるいはGeForceブランド向けにAI処理能力を強化した派生機である可能性が考えられるが、詳細はイベント当日の発表を待つ必要がある。 日本市場での注目点 参加には事前応募が必要で、X(旧Twitter)にNVIDIAやセガにまつわる思い出を写真・動画付きで投稿し、7月12日までにエントリーする形式だ。当選者には7月13日、公式アカウント(@NVIDIAGeForceJP)からDMで連絡が届く。つまり当日ふらっと秋葉原に行っても入場できるとは限らず、完全招待制である点は要注意だ。RTX 5090 FEは国内では品薄・プレミア価格になりがちな製品でもあり、抽選とはいえ実質的な価値は大きい。CEOが直接来場するイベントは日本では極めて稀で、AI PCシフトの最前線を肌で感じられる貴重な機会と言えるだろう。 筆者の見解 ニュースを追いかけているだけでは、こうした技術の変化の実感はなかなか湧いてこない。RTX 5090のようなハイエンドGPUや、AI処理に振った新製品「RTX Spark」が同じ場に並ぶというのは、ゲーミングとAIコンピューティングがもはや別々の話ではなくなっていることの表れだ。ローカルで動かせる計算資源が強化されていくことは、クラウドだけに頼らずAIを24時間自由に使い倒したい身としても歓迎したい流れで、今回お披露目される新製品がどこまでその期待に応えるかは注目したい。情報として眺めるだけでなく、実際に手を動かして試す経験の価値が増しているタイミングだからこそ、こうしたイベントに足を運んで自分の目で確かめる人が一人でも増えるとよいと思う。 関連製品リンク ASUS NVIDIA GeForce RTX 5090 Video Card 32GB GDDR7 PCI Express 5.0 / ROG-ASTRAL-RTX5090-O32G-GAMING Domestic Authorized Dealer Product ...

アップルは2026年7月8日、半導体大手ブロードコム（Broadcom）と300億ドル規模の契約を締結したと発表した。Engadgetのダニエル・クーパー記者が報じたところによると、この契約はブロードコムが「幅広いアップル製品向け」にカスタム無線チップを設計・製造するというもので、うち15億ドルはコロラド州フォートコリンズにあるブロードコムの工場の増強に充てられる。 300億ドル契約の中身 アップルとブロードコムの発表では、具体的なチップの型番までは明らかにされていないが、「先進的な無線周波数（RF）コンポーネント」の製造に触れられており、最終的に「150億個の米国製チップ」の生産につながるとされている。名指しされている技術は一つだけで、FBARフィルター（Bulk Acoustic Wave方式のフィルタリング技術）だ。これはスマートフォンが特定の無線帯域を分離・選別するために使う部品で、Wi-FiやBluetooth、5G通信の裏側を支える地味だが欠かせないコンポーネントである。 アップルとブロードコムは長年の取引関係にあり、ブロードコムはこれまでもRF・Wi-Fi・Bluetooth関連のチップをアップル製品に供給してきた。ただしブロードコムは自社に大規模な製造拠点を持たず、TSMCなど第三者ファウンドリーに生産を委託している点は留意しておきたい。 なぜこの契約が注目されるのか 背景にあるのは、トランプ政権が関税をちらつかせて米国内の技術サプライチェーンへの投資を迫った経緯だ。アップルは昨年、政権2期目の4年間で最大6000億ドルを米国内に投資すると表明しており、今回の300億ドル契約はその中でも単発では最大の規模となる。今後3年間で同様の大型契約がさらに発表される可能性が高い。 海外メディアの報道が指摘するポイント Engadgetの報道が指摘しているのは、発表内容の具体性の乏しさだ。「15億ドル」「150億個」といった数字は示されているものの、どの製品にどのチップが使われるのかは明言されていない。またブロードコム自身が製造能力をTSMCなど外部に依存している以上、「米国製」と言えるのは設計・一部工程にとどまる可能性がある点も、額面通りには受け取れない要素として指摘されている。政治的な関税圧力への対応という側面が強く、実際の生産能力拡大がどこまで実質を伴うかは今後の検証が必要というのが海外メディアの論調だ。 日本市場での注目点 この契約自体は法人間の部品調達契約であり、日本の消費者が直接購入できる製品ではない。ただし、ブロードコム製のRFチップやWi-Fi/Bluetoothチップは、すでに日本国内で販売されているiPhoneやiPadにも組み込まれている。米国内生産へのシフトが進めば、将来的な部品コストや供給の安定性に影響する可能性があり、円安局面が続く中では為替・関税動向とあわせて注視する価値がある。日本国内では半導体の国産化戦略としてRapidusなどの動きがあるが、今回のアップル・ブロードコム契約はその対極にある「米国回帰」の代表例であり、比較対象として押さえておくとよい。 筆者の見解 今回の契約は、発表の華やかさに反して中身の検証が難しい典型例だと感じる。数字は大きいが、どの製品にどう反映されるかが見えない発表は、政治的な圧力に応えるための「アリバイ作り」と実質的な供給網強化との見分けがつきにくい。大事なのは発表そのものより、実際に量産チップが出荷され、製品に搭載されるところまで追いかけることだ。情報を追いかけて一喜一憂するよりも、こうした発表は「実際に何が変わったか」が確認できてから評価するのが実務的には正しい姿勢だと思う。日本の技術者や調達担当者にとっても、地政学リスクを理由にしたサプライチェーンの再編は今後も繰り返されるテーマであり、特定のベンダーや生産地に依存しすぎない、王道の分散調達を淡々と続けることが結局は一番安全な選択になるはずだ。 出典: この記事は Apple pledges to buy $30 billion of Broadcom’s US-made chips の内容をもとに、筆者の見解を加えて独自に執筆したものです。

スウェーデン発のvibe（バイブ）コーディングスタートアップLovableが、Menlo Venturesを主要投資家として3億ドル（約450億円）の新規調達交渉に入っていると、欧州メディアのSiftedが報じた。実現すれば評価額は2025年12月時点の66億ドルから倍増し、132億ドル（約2兆円）に達する見通しだ。 創業3年未満でARR500億円規模に急成長 Lovableは自然言語で「作りたいもの」を説明するだけでWebサイトやECサイトを生成できるvibeコーディングツールを提供する。創業からまだ3年に満たないが、2026年6月時点の年間経常収益（ARR）はすでに5億ドル（約750億円）に達したという。個人の起業家・デザイナー・営業担当者向けの手軽なサイト構築ツールとしてだけでなく、Workday、Asana、NVIDIAといった大企業への導入も進んでおり、コンシューマー向けとエンタープライズ向けの両輪で収益を伸ばしている点が特徴だ。 過熱するvibeコーディング市場 資金が集まっているのはLovableだけではない。Replitは2026年3月に90億ドルの評価額をつけ、AIエージェント開発を支援するFactoryも4月に15億ドルの評価額で1.5億ドルを調達した。極めつけは、開発者向けvibeコーディングツールを手がけるCursorが先月SpaceXに600億ドルで買収された一件だ。「説明するだけでコードが書ける」という生成AIの体験は、もはや実験段階のニッチな機能ではなく、数十億〜数百億ドル規模の資金が集中する主戦場になっている。 実務への影響 日本のIT現場にとっても他人事ではない。vibeコーディングはプロトタイピングやMVP開発のスピードを劇的に引き上げる一方、生成されたコードの保守性やセキュリティレビュー体制をどう整えるかが実務上の課題になる。WorkdayやAsanaのような大企業がすでにLovableを業務に組み込んでいる事実は、こうしたツールが「お試し」の段階を超えてエンタープライズの実運用フェーズに入りつつあることを示している。IT管理者は、私的なツール利用を禁止する方向で対処しようとしても長続きしない。公式に安全な形で使える標準ワークフローとレビュー体制を早めに用意しておく方が、結局は現場にとっても管理側にとっても近道になる。エンジニア個人としても、実際に触れて生成コードの品質や限界を体感しておくことが、今後の技術選定や社内提案の説得力につながるはずだ。 筆者の見解 評価額の数字だけを追うと「バブルではないか」という声が出るのも無理はないが、筆者はこの資金の流れそのものより、その根底にある変化の方が重要だと見ている。「目的を説明すればコードやアプリが形になる」という体験は、AIエージェントが人間による逐一の確認・承認を肩代わりし、認知負荷を下げる方向に技術が進んでいることの表れだ。Lovable、Replit、買収されたCursorに共通するのは、ユーザーが細かく指示を出し続けなくても、目的さえ伝えれば自律的に形にしていくという設計思想だろう。この「自律型エージェント」への流れは今後さらに強まっていくはずで、日本の開発現場でも「指示を出して待つ」から「目的を渡して任せる」への発想転換が求められる局面が近づいている。個々のツールの優劣を追いかけて情報収集に時間を使うより、まずは実際に業務で触ってどこまで任せられるかを体感しておくことが、今この瞬間にできる一番の投資だと筆者は考えている。 出典: この記事は Lovable reportedly in talks to double its valuation to $13.2B の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国の自動車保険会社AssuranceAmericaは、2026年3月に発生した不正アクセスにより、顧客ら698万8886人分の個人情報が流出したことを明らかにした。同社はメイン州司法長官府への届け出で被害規模を公表し、対象者への通知レターを近く発送するとしている。 何が起きたのか AssuranceAmericaは9,500以上の独立系代理店ネットワークを通じて、米国14州で自動車保険・賃貸保険・商用自動車保険を提供する保険会社だ。同社は2026年3月17日、社内システムで不審な挙動を検知した。調査の結果、その前日にあたる3月16日に従業員1名を狙った攻撃が発生しており、これが侵入の起点になっていたことが判明した。 攻撃者は同社のIT環境の一部に不正アクセスし、データファイルをコピーして持ち出していた。流出した情報には、氏名、連絡先、自動車保険の契約・口座情報、運転者・車両情報、保険金請求関連情報、そして運転免許証番号が含まれる。クレジットカード番号や社会保障番号への言及は今回の届け出にはないが、保険契約情報と免許証番号の組み合わせは、なりすまし被害につながりやすい情報セットだ。 被害範囲の特定には3ヶ月以上を要した。同社は「流出したファイルの性質と、確認すべき範囲の大きさから、ファイルの精査が完了したのは6月15日だった」と説明している。検知から通知までに約4ヶ月を要したことになる。 対応としては、侵害された認証情報の無効化、不正セッションの強制切断、影響を受けたシステムの隔離、法執行機関への通報、パスワードのリセット、監視・検知ツールの強化、従業員向けセキュリティ教育の追加を実施したとしている。オーソドックスで一通りそろった対応であり、特段の問題は見当たらない。 なお先月には、米保険大手Aflacの日本法人（アフラック生命）子会社のシステムが侵害され、438万人分の顧客情報が流出したことも公表されている。保険業界は個人情報・医療情報・金融情報が一体で蓄積される業種であり、攻撃者にとって費用対効果の高い標的になり続けている。 実務への影響 日本のIT管理者にとって注目すべきは、侵入の起点が「従業員1名」だったという点だ。ネットワーク境界の防御をどれだけ固めても、正規の資格情報を持つ1アカウントが乗っ取られれば、そこから水平展開されてしまう。典型的なID侵害（Identity Compromise）のパターンであり、境界防御だけに頼るモデルの限界を改めて示す事例といえる。 特に代理店ネットワークのような分散型の組織構造を持つ企業では、外部委託先や代理店経由のアクセス経路も含めて「誰が」「いつ」「何に」アクセスできるかを常時把握する仕組みが欠かせない。常時有効な広範な権限を持つアカウントが1つでも残っていれば、それが最初の突破口になり得る。Just-In-Time（JIT）でのアクセス許可、多要素認証の徹底、異常なセッションを即座に検知する仕組みは、もはや大企業だけの課題ではない。 保険・金融業界に限らず、顧客の個人情報や契約情報を大量に保持する業種であれば、同種の攻撃はいつ自社に向いてもおかしくない。Aflacの事例と合わせて、自社が保有するPII（個人を特定できる情報）の棚卸しと、それを扱うアカウント・アプリケーションのアクセス権を見直す機会にしたい。 筆者の見解 正直に言うと、セキュリティのニュースを追うのはあまり好きではない。似たような手口、似たような後手の対応が繰り返されるからだ。ただ今回のケースには、技術的に見て考えさせられる点がある。侵入の起点が「従業員1名」という、ごくありふれた形だったことだ。 こうした事例を見るたびに思うのは、常時有効な広い権限を持つアカウントを減らし、必要なときだけ必要な範囲でアクセスを許可する仕組み（Just-In-Time）を徹底することの重要性だ。VPNや境界防御に頼るモデルは、正規の認証情報を持つ1アカウントが乗っ取られた瞬間に意味を失う。「今動いているから大丈夫」ではなく常にアクセスを検証するゼロトラストの考え方が、こうした事件のたびに正しさを証明していく。 もう一つ気になるのは、人間のアカウントだけでなく、自動化されたプロセスやサービスアカウントといった非人間アイデンティティ（NHI）の管理だ。業務の自動化が進むほど、人間以外が保持する権限の総量は増えていく。そこを適切に棚卸しできない組織は、結局「便利だから」という理由で常時アクセス権を配りすぎてしまう。セキュリティは細かい話の積み重ねで好きになれないという人は多いだろうが、こうした基本の徹底こそが、690万人分もの情報が流出するような事態を防ぐ一番の近道なのだと思う。 出典: この記事は AssuranceAmerica data breach exposes records of 6.9 million drivers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、AIエージェントを安全に実行する管理型クラウドPC環境「Windows 365 for Agents」を発表した。Microsoft Entra・Intune・Defender・Purview・Agent 365と統合し、人間の従業員に適用してきたのと同じセキュリティ統制を、業務を代行するAIエージェントにも拡張できる仕組みだ。 Windows 365 for Agentsとは何か 本番運用フェーズに入ったAIエージェントは、ローカルPCや共有仮想マシン、管理の行き届かないクラウド環境で動くことが多く、ID管理・ポリシー適用・監査の一貫性を保つのが難しかった。Windows 365 for Agentsはエージェント専用の「Cloud PC」を用意することでこれに応える。人間向けのWindows 365と同様、Entra参加・Intune登録済みの管理対象デバイスとしてエージェントを稼働させる発想だ。 セキュリティの核となる仕組み 核となるのが、エージェントごとに割り当てられる独立ID(Agent ID)だ。人間のアカウントとは切り離され、エージェントの「雇用」と同時にEntraに一意のIDが自動発行される。操作はすべて特定のエージェントに紐づき権限を厳密にスコープでき、Entra Conditional Accessと組み合わせればコンプライアンス要件を満たしたCloud PCからしかリソースにアクセスできないよう強制できる。 Cloud PC自体は隔離された企業管理下の環境で稼働し、人間との混在によるアカウント越境や権限昇格リスクを構造的に排除する。Entra参加・Intune登録済みのため、人間の従業員と同じセキュリティベースラインとコンプライアンスポリシーをプロビジョニング時点から適用できる。ネットワークの出入り口にはID主導型のセキュアWebゲートウェイMicrosoft Entra Global Secure Access(GSA)が入り、Webフィルタリングや脅威対策をエージェント通信にも適用する。 さらにMicrosoft Agent 365との統合でガバナンスと可視性を確保する。Windows 365 for AgentsはAgent 365上でMCP(Model Context Protocol)サーバーとして公開され、テレメトリはMicrosoft DefenderのAIエージェントインベントリや脅威検知、Microsoft PurviewのDSPM for AI・DLPに流れ込む。エージェントが「何にアクセスし何を扱ったか」を人間と同じ枠組みで追跡できる。 実務への影響 日本企業の多くはRPAやローカルスクリプトの延長線上でAIエージェントの実験的導入を進めてきたが、実運用フェーズでは「誰が」「どの権限で」「どこから」エージェントを動かしたか説明できないことが監査や内部統制上の大きな穴になる。Windows 365 for Agentsのような専用実行基盤は、この説明責任のギャップを埋める現実的な選択肢だ。 IT管理者にとって重要なのは、新しい管理体系をゼロから作らなくてよい点だ。既存のConditional AccessポリシーやIntuneのコンプライアンスベースライン、Purviewの機密ラベル・DLPルールをそのままエージェントにも適用拡張できる。人間向けに整備してきたゼロトラスト基盤への投資が、そのまま活きる設計だ。なおEntra・Intune・Defender・Purview・Agent 365には個別のライセンス要件があり、導入前にコストと契約範囲の確認は必須だ。 筆者の見解 エージェントのID(Agent ID)を人間から切り離して管理する設計思想は、Non-Human Identity(NHI)管理の実践そのものであり、素直に評価したい。NHIを統制できなければ「人間が確認しないと動かせない」ボトルネックが残り、自動化は掛け声だけで終わる。エージェントに個別のライフサイクル管理とロールベースアクセス制御を与える方向性は、AI活用を本気で広げるうえで避けて通れない一歩だ。 ネットワーク層でも、Global Secure AccessによってID主導のゼロトラストをエージェント通信にまで広げた点は評価できる。境界防御やVPN頼みのモデルはとっくに限界を迎えており、常時稼働する非人間の通信こそID・デバイス・ネットワークの3層で見る発想が要る。 一方で気になるのは、エージェント専用Cloud PCの権限が「常時オン」のまま運用されないかという点だ。特権アカウント管理では常時アクセス権の付与こそ最大のリスクであり、Just-In-Timeでの権限昇格が本来あるべき姿。エージェントが増えるほど常時稼働する高権限アカウントがなし崩し的に量産される懸念は残る。権限をタスク単位で必要最小限かつ時間制限付きに絞り込む仕組みまで踏み込めるかが次の見どころだ。 とはいえ、既存の統合プラットフォームにそのまま乗せられる設計は、部分最適の寄せ集めになりがちなエージェント基盤の中では正攻法だと思う。Microsoftを応援する立場から言えば、この分野は正面から勝負できる強みのはずで、あとは企業がどこまで安全に、現場の負担なく使い倒せるかにかかっている。 出典: この記事は Windows 365 for Agents: A secured execution environment for AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年7月8日（現地時間）、Windows標準のセキュリティ機能であるMicrosoft Defenderのゼロデイ脆弱性「RoguePlanet」（CVE-2026-50656）を修正した。完全にパッチ適用済みのWindows 10・Windows 11環境でも、レースコンディション（競合状態）を突くことでSYSTEM権限のコマンドプロンプトを起動できるというもので、セキュリティ研究者「Nightmare Eclipse」がMicrosoftの脆弱性開示プログラムへの不満から、正式な修正提供前に検証コード（PoC）を自らホストするGitリポジトリで公開していた。 RoguePlanetの正体 ― Defender自身の「隙」を突く攻撃 RoguePlanetは、Defenderのスキャン処理に潜む競合状態を悪用する。成功率は環境依存で「マシンによっては100%成功するが、別のマシンでは失敗しやすい」とNightmare Eclipse自身が説明している。注目すべきは、リアルタイム保護の有効・無効に関わらずPoCが動作した点だ。防御機能そのものが攻撃の足がかりになるという、皮肉な構図である。 Microsoftは6月16日時点で修正作業に着手していることを認めていたが、Nightmare Eclipseを発見者として公式にクレジットはしていない。今回の修正は、通常のPatch Tuesdayとは別系統である「Microsoft Malware Protection Engine」（バージョン1.1.26060.3008）の更新として配布された。Defenderのシグネチャ更新と同じ経路で自動配信されるため、多くの環境では気づかないうちに適用されている可能性が高い。 研究者との根深い対立 今回の開示は単発ではない。Nightmare Eclipseはここ数カ月、BlueHammer、RedSun、GreenPlasma、MiniPlasma、YellowKey、UnDefendと、Defender・BitLocker・Windowsコンポーネントにまたがる複数のゼロデイを次々と公開してきた（GreenPlasma・MiniPlasma・YellowKeyは6月のPatch Tuesdayで修正済み）。 背景にはMicrosoftのバグバウンティ・脆弱性開示プロセスへの不満がある。Nightmare EclipseはGitHub・GitLabでホストしていたPoCリポジトリをMicrosoftに削除されたと主張し、以降は自前のGitサーバーで公開する方針に転じた。さらにMicrosoftは「顧客に実害を与える悪意ある行為」への法的措置も辞さないとする声明を出しており、セキュリティ専門家の間ではこれが実質的に研究者本人への警告と受け止められている。 実務への影響 日本のIT管理者にとって重要なのは、この修正がWindows Updateの通常サイクルではなく、Malware Protection Engineの自動更新で配布されている点だ。多くの環境では自動適用済みだが、次のコマンドで現在のエンジンバージョンを確認しておきたい。 Get-MpComputerStatus | Select-Object AMEngineVersion, AntivirusSignatureVersion WSUSやIntune、SCCMでDefenderの更新配信を制御している場合、シグネチャ更新だけでなくエンジン本体の更新もブロックされていないか確認する価値がある。またNightmare Eclipseの開示ペースからすると、Defender・BitLocker関連のゼロデイは今後も続く可能性が高く、継続的なウォッチをお勧めする。 筆者の見解 セキュリティ分野は正直、得意というより「技術的に気になるから追いかけている」領域に近いが、今回は技術面よりガバナンス面で考えさせられた。 Defenderは全Windows環境に標準搭載される、いわば最後の砦だ。その防御機構自体に競合状態の欠陥が見つかり、しかも「保護が有効でも無効でも突破できる」というのは、単一レイヤーを過信せず、ネットワーク・認証・認可の多層防御を前提に設計すべきだという普段の主張を改めて裏付ける事例だと感じる。 一方でMicrosoftの対応には、応援する立場から見てももったいなさを感じる部分がある。研究者との関係がこじれてPoCが正式パッチ前に公開されてしまう状況は、脆弱性開示プログラムの運用に改善の余地があることを示している。法的措置をちらつかせる姿勢よりも、研究者が正規のルートを使いたくなるような公正で迅速な開示プロセスを整えることの方が、結果的にユーザーを守ることにつながるはずだ。Microsoftほどの規模とブランド力があれば、業界標準となる開示プログラムを作れる力は十分にあるのだから、そこは正面から向き合ってほしい。 出典: この記事は Microsoft patches RoguePlanet Defender zero-day vulnerability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIは2026年7月8日（米国時間）、AIのコーディング能力を測る代表的なベンチマークの一つである「SWE-Bench Pro」について、フロンティアモデルの実力を信頼性高く測定できなくなっているとして、主要な評価基準としての推奨を撤回したと発表した。PC Watchが7月9日付で報じている。 なぜこの発表が注目か SWE-Bench Proは、実際のソフトウェア開発タスクをAIエージェントに解かせて正答率を競わせる形式のベンチマークで、Claude Code・Codex・Gemini CLIといった主要なAIコーディングエージェントの性能比較指標として広く引用されてきた。開発各社が「ベンチマークで何位か」を競うように新モデルを発表する状況が続く中、その物差し自体の信頼性に疑義が生じたことは、AIコーディング業界全体にとって見過ごせない出来事だ。 とりわけ、このベンチマークを主要な推奨指標として使ってきた当のOpenAIが自ら監査を行い、非を認めて撤回に踏み切った点は注目に値する。モデル開発競争が過熱するほど、評価指標自体が「勝つための道具」として形骸化しやすいという業界共通の課題を、名指しで浮き彫りにした形だ。 海外レビューのポイント OpenAIの監査によると、SWE-Bench Proに含まれる問題の約30%に欠陥があり、AIが実質的に正しい解決策を提示していてもテストに不合格と判定されるケースが確認されたという。具体的には、隠れた条件や矛盾する指示、過度に厳格すぎるテスト、評価基準（ルーブリック）の不備などが原因として挙げられている。 検証プロセスにも特徴がある。AIエージェントによる自動チェックだけでなく、5人の経験豊富なソフトウェアエンジニアによる独立レビューを組み合わせ、専門家の判断を核にしながら大規模にタスクを検証する体制を取ったという。「AIによる効率化」と「人間の専門知による裏付け」を両立させるこの手法自体、ベンチマーク監査のあり方として参考になる部分が大きい。 OpenAIは声明の中で、AIのコーディング能力が向上するのに合わせて、それを測るテストもより難しく、より公平で、より信頼できるものへ進化させる必要があると強調。この分野の本当の進歩や最先端の実力を理解するには、より優れた評価基準が不可欠だと結んでいる。 日本市場での注目点 今回の一件は特定のハードウェアやアプリの発売情報ではないが、日本の開発現場にとっても実務的な示唆がある。GitHub Copilot、Codex、Claude Code、Gemini CLIなど複数のAIコーディングエージェントを比較検討している企業・エンジニアは少なくないはずだが、その判断材料としてベンチマークのスコアだけを鵜呑みにするリスクが、今回の件で改めて明確になった。 日本語圏ではSWE-Bench Pro自体の知名度はまだ限定的だが、海外の大手ベンダーが自社の看板ベンチマークを自己監査して撤回するという事例は、今後国内でAI導入の意思決定を行う際にも「評価指標をどう選び、どう検証するか」という視点を持つきっかけになるだろう。特に開発組織のマネジメント層は、ベンチマーク順位よりも自社のユースケースに即した検証を優先すべき局面に来ている。 筆者の見解 ベンチマークのスコアや順位は、ツール選定の出発点としては便利だが、今回の一件はその数字を鵜呑みにする危うさを改めて示した。テストの約3割に欠陥があったという事実は、正しい答えを出したAIが不合格判定を受けていた可能性を意味しており、ランキング上の差が実力差をそのまま反映していたとは限らないことになる。 これは筆者が普段から感じていることとも重なる。AIエージェントの世界は動きが速く、次々と新しいベンチマークやスコアが話題になるが、それを全部追いかけて一喜一憂するより、実際に自分の手元のタスクで使ってみて成果が出るかどうかを確かめるほうが、よほど確実な判断材料になる。組織でAI活用度を測る際も同様で、トークン消費量やベンチマーク順位のような分かりやすい数字だけを追う「KPIハック」に陥ると、本質を見失いかねない。 OpenAIが自らの看板ベンチマークに疑義を呈し、撤回という形で誠実に対応した姿勢自体は評価できる。日本の開発現場も、この機会に「何を根拠にAIツールを選んでいるか」を一度点検してみる価値があるだろう。 出典: この記事は コーディング評価「SWE-Bench Pro」は役に立たない。OpenAIが非推奨に の内容をもとに、筆者の見解を加えて独自に執筆したものです。