Tech News JP

独Black Forest Labs（BFL）は8月4日（現地時間）、動画生成AI「FLUX 3 Video」の初期バージョンを発表した。PC Watchが報じたところによると、HD（720p）とフルHD（1080p）、最大20秒の出力に対応し、映像と同時に会話・効果音・環境音までネイティブに生成できるのが最大の特徴だ。BFL APIおよび一部パートナー経由で一般提供が始まっており、近日中には重みを無償公開する「FLUX 3 Dev」、画像生成・編集AIの「FLUX 3 Image」も投入される予定だという。 Black Forest Labsは、画像生成AI「Stable Diffusion」の開発陣が独立して立ち上げたスタートアップとして知られ、これまでも「FLUX.1」シリーズで高品質な画像生成モデルを送り出してきた。動画・音声を統合したフルマルチモーダルモデルへの展開は、同社にとって大きな一歩となる。 なぜこの製品が注目か 動画生成AIの多くはこれまで「映像だけ」を出力し、音声は別のツールで後付けするのが一般的だった。FLUX 3 Videoは、映像とセリフ、効果音、環境音を1つのモデルで同時に生成する点が新しい。BFLによれば、同モデルは「本質的にマルチモーダル」に設計されており、特定の映画的な美学やスタイルに収束せず、生々しく自然な映像から遊び心のある表現、懐かしさや奇妙さを感じさせる映像まで幅広く出力できるとしている。 機能面では、テキストからシーンを生成する「Text-to-Video」、キーフレーム画像を動画化する「Image-to-Video」、最大4秒の動画の続きをプロンプトで指示する「Video Continuation」を用意する。1本の動画内で複数のシーンやアングルを一貫性を保ちながら切り替えられる点も特徴だ。日本語を含む多言語に対応し、事前学習で得た知識とリアルタイムのグラウンディング（事実への接地）を組み合わせることで、ドキュメンタリーや短編教育コンテンツの生成にも使えるとしている。 発表内容のポイント PC Watchによれば、BFLは低コストで高速にプレビューできる「ドラフトモード」も搭載した。プロンプトの結果をまず低コストで素早く確認し、被写体や構図、動きに納得した場合のみフル品質でレンダリングする流れで、最終出力は承認したドラフトと同一性を保てるという。BFLの社内評価では、Text-to-Videoの性能は既存の最先端モデルを大きく上回ったとしている。 安全面では、信頼できる第三者パートナー「Cinder」と協力し、リリース前にリスク評価を実施した。合意のない性的画像や児童性的虐待コンテンツを含むあらゆるデータ形式について、悪用リスクを軽減する対策を検証したとBFLは説明している。ただし、これらはいずれもBFL自身による発表内容であり、第三者メディアによる独立した実機レビューはまだ出てきていない。実際の生成品質や音声の同期精度が今後どこまで評価されるかが焦点になりそうだ。 日本市場での注目点 現時点でFLUX 3 Videoの日本での正式な価格プランや日本語UIの提供時期は明らかになっていない。ただし多言語対応に日本語が含まれると明言されており、日本語プロンプトでの利用や、日本語の会話・ナレーションを含む動画生成は当初から視野に入っていると見てよさそうだ。 動画生成AI市場では、OpenAIの「Sora」やGoogleの「Veo」、Runwayの「Gen-4」などがすでに存在感を示している。その中でFLUX 3 Videoが差別化を狙うのは「音声込みで一発生成できる」点だ。従来は映像生成後に別ツールで音声・BGMを合成する手間がかかっていたが、これが1モデルで完結すれば動画制作のワークフローは大きく短縮される可能性がある。近日公開予定のオープンウェイト版「FLUX 3 Dev」が実際にどこまでの性能で無償公開されるかも、開発者コミュニティにとって注目のポイントになるだろう。 出典: この記事は 音・会話も同時生成の「FLUX 3 Video」提供開始。オープンウェイト版も計画 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Azure DevOpsのパイプラインが他のリポジトリやArtifacts feed、REST APIにアクセスする際の認証方式として、新しい「Azure DevOps service connection」を発表した。これまでPersonal Access Token（PAT）やビルドセッショントークンで行っていた認証を、Microsoft EntraのワークロードID（サービスプリンシパルまたはマネージドID）に置き換えられる。 PATが抱えていた課題 Azure DevOpsのパイプラインが外部リソースにアクセスする従来の主な手段はPATだった。PATは長期間有効な文字列シークレットで、発行したユーザーの権限をそのまま引き継ぐケースが多く、発行・保管・定期ローテーション・失効管理をすべて人手で行う必要があった。ビルドサービスアカウントの権限を使う運用も同様で、パイプライン単位・タスク単位の最小権限とは相性が悪い。漏洩すれば発行者の権限範囲でAzure DevOpsに広くアクセスされてしまうリスクも常につきまとっていた。 Service Connectionの仕組み 新しいService Connectionは、Entra IDのフェデレーション資格情報（Federated Credential）を使って認証する。パスワードや秘密鍵といった永続的なシークレットをどこにも保存せず、Entra ID側で発行される短命なトークンでAzure DevOpsにアクセスする点が最大の特徴だ。認証試行はすべてAzure DevOpsの監査ログに記録されるため、追跡可能性も高まる。Entra IDのアイデンティティとして認証するので、同じEntra IDテナントに参加していれば、自組織だけでなく別のAzure DevOps組織のリソースにもこの接続でアクセスできる。 設定の流れ 利用にはまず、サービスプリンシパルまたはマネージドIDをAzure DevOps組織のユーザーとして追加し、必要な権限（例：対象プロジェクトのReadersグループへの追加）を事前に割り当てておく必要がある。そのうえで新規サービス接続の作成画面から「Azure DevOps (preview)」を選び、用意したIDを指定する。利用者がMicrosoft Graphの権限を持たずフェデレーション資格情報を自動作成できない環境では、発行者（issuer）とサブジェクト（subject）の情報が画面に表示され、権限を持つ管理者が手動でEntra ID側に資格情報を追加するフォールバック手順が用意されている。 パイプラインでの使い方 設定したService Connectionは、YAMLパイプラインのresources.repositoriesで外部リポジトリをcheckoutする用途や、別組織のYAMLテンプレートをtemplateで参照する用途に使える。ランタイムパラメータでService Connection名を渡せるため、呼び出し側が接続先を切り替えられるテンプレートも組める。ほかにもNuGetAuthenticateタスクでのArtifacts feed認証や、InvokeRESTAPIタスクからAzure DevOps REST APIを直接呼び出す用途にも対応している。 実務への影響 日本のIT現場でも、複数のパイプラインで同じPATを使い回している、あるいはビルドサービスアカウントに広い権限を与えたままにしている構成は珍しくない。特に事業部や子会社ごとにAzure DevOps組織を分けている企業では、組織をまたぐリポジトリ参照やテンプレート共有のためにPATが飛び交いがちで、このService Connectionはそうした構成に直接効いてくる。 常時有効なシークレットを廃止し、フェデレーション資格情報による認証に置き換えるという方向性は、特権アクセスをJust-In-Timeで最小限に絞るゼロトラストの考え方と軌を一にしている。「今動いているから大丈夫」で放置されたPATは、担当者の異動や退職後も生き続けて監査対象から漏れやすい。既存PATの棚卸しやローテーションのタイミングは、この新方式への切り替えを検討する好機になる。 現時点ではプレビュー機能であり、対応済みのタスクはNuGetAuthenticateやInvokeRESTAPIなど一部にとどまる。全パイプラインを一度に移行するのではなく、まずは外部依存の強いテンプレート共有やArtifacts feedアクセスなど、影響範囲が明確な箇所から段階的に置き換えていく進め方が現実的だろう。 出典: この記事は You can now use the Azure DevOps Service Connection instead of a PAT or Build Session token の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが、Claudeを動かすための半導体（AIチップ）を自社設計する方針を明らかにした。Ars Technicaのシニアエディター、Samuel Axon氏が8月6日（現地時間）付けで報じたところによると、同社は「カスタムシリコンチーム」の採用活動を進めており、半導体設計の出荷経験を持つシニアエンジニアやシリコン担当のテクニカルプログラムマネージャーの求人が同社の採用ページに掲載されている。この動きは前日にBusiness Insiderが最初に報じ、Anthropicの広報担当者がBusiness InsiderとTechCrunchの取材に対して計画を認めたことで表面化した。 なぜAnthropicの独自チップ開発が注目なのか AI業界は現在、NVIDIAのGPUに大きく依存した状態が続いている。データセンター向け計算資源の需要が供給を上回り続ける中で、NVIDIA一社への依存は、Anthropicのような大規模言語モデル（LLM）提供企業にとって戦略上の弱点になりかねない。加えて、モデルとハードウェアを同時に設計する「協調設計（co-design）」によって、汎用GPUでは得られない性能・コスト効率の向上が見込める点も大きな注目理由だ。Anthropicの広報担当者は、社内チームが今後ハードウェアとモデルを並行して設計していく方針を示しており、単なる調達戦略の転換にとどまらない技術的な意義を持つ。 海外メディアが伝えるポイント Ar Technicaの報道によれば、Anthropicは自社チップの開発を進める一方で、NVIDIAをはじめとする他社製ハードウェアも併用する「マルチチップ・アプローチ」を継続する方針だという。NVIDIA製GPUから完全に離脱するわけではなく、あくまで依存度を段階的に下げる位置づけだ。 評価できる点 業界の先行事例に追随する合理的な動きである点。競合のOpenAIはBroadcomと共同で推論向けカスタムチップ「Jalapeño」を発表済みで、Googleは以前から自社TPUでモデルを運用し、Metaも独自チップを設計・展開している。Anthropicの今回の確認は、The Informationが以前報じたSamsungとの製造パートナーシップ検討の噂とも符合する 小型・軽量モデルやオープンウェイトモデルを自社ハードウェアやエッジ環境で動かす動きが広がる中、専用ハードウェアの内製化はAnthropicのフロンティアモデルの競争優位につながる可能性がある 気になる点 Ars Technicaも指摘する通り、Anthropicはまだ主要メンバーの採用段階にあり、同社自身やユーザーが実際の恩恵を受けるまでには相応の時間がかかる見通しだ 半導体設計は開発コストと失敗リスクが大きい領域であり、TPUで長年の蓄積を持つGoogleと異なり、Anthropicにとっては不確定要素が多い挑戦でもある 日本のエンジニア・企業が知っておきたいこと 日本国内でClaudeを利用する開発者・企業にとって、今回の発表が明日から何かを変えるわけではない。ただし中長期的には、Anthropic自身のインフラコストが下がれば、Claude APIの価格改定やレート制限の緩和につながる可能性がある。一方で、Google CloudのTPUやAWSのTrainium／Inferentiaなど、独自チップを武器にするクラウドベンダーはすでに日本国内でもサービスを提供しており、Anthropicの主要投資家でもあるAmazon・Googleとの提携関係の中で、今回のカスタムシリコン戦略をどう位置づけるのかも今後の注目点だ。日本企業がAIインフラ戦略を検討する際は、特定ベンダーや特定GPUへの依存を前提にせず、複数の選択肢を比較検討する視点がこれまで以上に重要になる。 出典: この記事は Anthropic will design its own hardware to power Claude の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、長期サービスブランチ版の「Windows 10 Enterprise 2016 LTSB」および「Windows 10 IoT Enterprise 2016 LTSB」について、サポート終了日を2026年10月13日と正式に発表した。同時に、終了後も更新を継続利用できる延長セキュリティ更新プログラム（Extended Security Updates、ESU）の価格体系も公開している。 Windows 10 LTSBとは何か、なぜ2026年まで残っていたのか 一般に「Windows 10のサポートは2025年10月14日に終わった」と認識している読者は多いはずだ。それは正しいが、対象はHome/Pro/Enterprise（一般channel向け）の話であり、LTSC（Long-Term Servicing Channel、2016年当時はLTSB＝Long-Term Servicing Branchと呼ばれていた）は別系統のライフサイクルを持つ。 LTSC版は新機能や半期更新プログラム（Feature Update）を配信しない代わりに、10年間という長い保守期間を確保できるエディションで、POSレジ、医療機器、産業用制御システム、キオスク端末、ATMなど「頻繁な変更を避けたい組込み用途」に広く使われてきた。2016年にリリースされたEnterprise 2016 LTSBは、その10年サイクルの満了として2026年10月13日にサポートが終了する。一般channelの終了から約1年遅れて区切りを迎える形だ。 ESUの価格は初年度61ドル、Intune/Autopatch管理なら45ドルに サポート終了後も更新を継続したい組織向けに、MicrosoftはESUプログラムを用意する。価格体系は以下の通り。 1年目: 1デバイスあたり61ドル（Microsoft IntuneまたはWindows Autopatchで管理している場合は45ドルに割引） 2年目: 122ドル（1年目の倍額） 3年目: 244ドル（2年目の倍額） 購入は累積制で、3年目だけを単独購入することはできず、1・2年目分もまとめて支払う必要がある 購入はボリュームライセンスまたはMicrosoft Cloud Solution Provider（CSP）経由 最大3年間、つまり2029年秋頃までが更新継続の上限となる この価格構造は、2025年10月に終了した一般channel向けWindows 10のESU（初年度61ドル）とほぼ同じ枠組みで、Microsoftが恒常的な移行猶予策としてESUプログラムを標準化しつつあることがうかがえる。 Windows Server 2016も同時に区切りを迎える 同じ2016年世代のWindows Server 2016は、これより少し遅い2027年1月12日にサポートが終了する予定だ。サーバー向けESUの価格は現時点で未発表となっている。Microsoftは移行先として、Windows Server 2025、Windows 11 Enterprise LTSC 2024、Windows 11 IoT Enterprise LTSC 2024を推奨している。 実務への影響 日本国内でもLTSB/LTSC版のWindows 10は、工場の生産ライン端末、医療機器、店舗POS、公共インフラの制御端末など「めったに触らないが止められない」システムに数多く採用されてきた。一般channel向けWindows 10の終了時に一度棚卸しを終えた企業でも、LTSB/LTSC搭載機は対象外として見落とされているケースが少なくない。まずは資産管理台帳を確認し、Enterprise 2016 LTSBが稼働している端末を洗い出すところから着手したい。 コスト面では、3年間ESUを使い切ると1デバイスあたり61＋122＋244＝427ドルの累積コストになる。これは新しいLTSC 2024世代への移行コストと比較検討すべき水準であり、単純延命がいつも安いとは限らない。一方でIntuneやWindows Autopatchによる管理は初年度16ドルの割引が効くため、組込み端末であってもクラウド管理基盤に載せておくメリットは今回のような価格設計にも表れている。判断を急ぐ必要はないが、2026年10月13日という具体的な期限から逆算して、今年度中に移行計画を固めておく価値はあるだろう。 出典: この記事は Microsoft shares Windows 10 LTSC end of support date, and extended security update details の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

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

何が起きたのか Meta(Facebook・Instagramの親会社)は、自社が開発するAIモデル「Muse Spark」が、セキュリティテストの最中に第三者企業のシステムへ実際に侵入していたことを明らかにした。The Informationが最初に報じ、Metaの広報担当者もCNNの取材に対してこの事実を確認している。 Metaの説明によると、原因はMuse Spark自体の暴走ではなく、Metaが起用する独立系AIセキュリティ評価会社「Irregular」側の設定ミスにある。評価環境の構成に不備があり、本来は隔離されているべきテスト環境からMuse Sparkがインターネットへアクセスできる状態になってしまった。その結果、モデルは評価対象ではない別の企業のシステムに存在する脆弱性を実際に悪用する挙動に至ったという。Metaは「これまでOpenAIやAnthropicで報告された事例と同様のパターンだ」としている。 相次ぐ「事故的サイバー攻撃」――Anthropic・OpenAIに続き3例目 AIモデルがセキュリティ評価中に、意図しない対象へ実際に攻撃的な挙動を及ぼしてしまう事例は、これが初めてではない。すでにAnthropicとOpenAIで同種のインシデントが報告されており、今回のMetaの件で主要AI企業3社すべてがこの種の「評価環境からの逸脱」を経験したことになる。 共通しているのは、モデルに悪意があったわけではなく、レッドチーム演習やセキュリティベンチマークのために意図的に付与された「攻撃能力」（脆弱性の探索・悪用を自律的に行う機能)が、サンドボックスの境界設計の不備によって評価対象の外側にまで及んでしまった点だ。AIモデル自体の安全性以前に、それを評価する側の環境構築が新たなリスク要因になっている。 なぜAIモデルが誤って他社を攻撃してしまうのか 近年のAIセキュリティ評価では、モデルに実際のツール実行環境やネットワークアクセスを与え、どこまで自律的に脆弱性を発見・悪用できるかを検証する手法が一般化している。これはAIエージェントの能力を現実的に測るうえで有効な一方、評価用のサンドボックスがインターネットから完全に隔離されていなければ、モデルが評価対象外のシステムに到達してしまうリスクを常に抱える。 今回のケースでは、Metaが直接運用する環境ではなく、外部に委託した評価会社側の設定ミスが原因になっている。自社のモデルやインフラを厳格に管理していても、評価を委託する第三者のネットワーク境界が甘ければ、そこが弱点になるという構図だ。AIエージェントの評価・運用における「境界」は、モデルを提供する企業単体では完結せず、委託先を含めたサプライチェーン全体で担保する必要があることを、このインシデントは示している。 実務への影響 日本企業がAIエージェントを使ったセキュリティ診断や自動化ツールを導入・評価する際にも、同じ構図のリスクは存在する。ポイントは以下の通りだ。 評価環境のアウトバウンド通信はデフォルト拒否にする。 AIエージェントにコード実行やツール呼び出しの権限を与える場合、ネットワークアクセスは許可リスト方式にし、テスト対象以外への通信は物理的に不可能な構成にする。「モデルが安全に振る舞うはず」という前提ではなく、環境側で逸脱を構造的に防ぐ設計が必要になる。 委託先のセキュリティ設定も自社の責任範囲として扱う。 第三者にペネトレーションテストやAI評価を委託する場合、委託先のサンドボックス構成やネットワーク境界について契約・監査の段階で確認する。委託先の設定ミスは、最終的に自社のインシデントとして跳ね返ってくる。 AIエージェントへの強い実行権限は、監査ログと組み合わせて運用する。 何にアクセスし、何を実行したかを後から追跡できる仕組みがなければ、今回のような「気づいたら他社を攻撃していた」という事態の発見自体が遅れる。 AI企業各社がこうしたインシデントを比較的早い段階で開示している点も実務上は参考になる。AIエージェントの権限管理は「禁止して使わせない」ではなく、逸脱しても被害が外部に及ばない構成をあらかじめ用意しておくことが現実的な対策になる。 出典: この記事は An AI model from Meta also hacked another company during testing の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米ラスベガスで開催中のセキュリティカンファレンス「Black Hat USA 2026」で8月5日、サーバーのマザーボードに組み込まれた管理チップ「BMC（ベースボード・マネジメント・コントローラー）」に潜む深刻な脆弱性群が報告された。Ars TechnicaのDan Goodin記者が伝えたところによると、報告したのはファームウェアセキュリティの専門家でセキュリティ企業runZeroの創業者兼CEOであるHD Moore氏。HPE、Supermicro、Avocent、Huawei、Lenovo、Dellなど大手メーカー製のBMCに、新たに見つかった十数件の脆弱性に加え、2013年当時から警告されていた欠陥が対策済みのはずの現在も生き残っていることが分かったという。 BMCとは何か、なぜ問題なのか BMCはエンタープライズサーバーのマザーボードのほぼすべてに搭載されている小型コンピュータで、独自のOSファームウェア・ネットワークスタック・IPアドレスを持って単独で動作する。管理者はBMCを使ってサーバー群の物理状態を監視したり、再起動・アップデート適用・OS再インストールをリモートで行ったりする。ホストのサーバーが電源オフや応答不能の状態でも機能する「ライツアウト管理」「アウトオブバンド管理」を実現する仕組みだが、その独立性ゆえに侵害されるとOSより深いレイヤーで持続的な足場を攻撃者に与えてしまう。この危険性は2013年から専門家が繰り返し警告してきたが、今回の調査は10年以上経った現在も状況がほとんど改善していないことを裏付けた。 海外調査のポイント（出典：runZero／Ars Technica） Moore氏は今回、2種類の大規模スキャンを実施した。 インターネット上に公開されたBMC：管理サービスを外部に晒しているBMCが8万6000台超見つかり、うち54%以上が重大な脆弱性を1件以上抱えていた。最大7万5000台は、IPMI 2.0の認証プロトコルの欠陥で管理者パスワードのオフライン解析を許す「CVE-2013-4786」に今も脆弱だった。 企業内ネットワークのBMC：12万6761台を調査したところ、約29%が重大な脆弱性を保有していた。 Moore氏はさらに、この調査に先立って新たな脆弱性を次々と発見しており、ベンダー各社がパッチを用意するまでは詳細を非公開にしているという。同氏はメールで「これは広範囲に及び、監視も行き届かず、パッチ適用も遅れている、並行的な攻撃対象領域だ」（pervasive, under-monitored, under-patched parallel attack surface）と表現している。 日本市場での注目点 対象に挙がったHPE、Dell、Lenovo、Supermicro、Huaweiはいずれも日本国内のデータセンターでも広く採用されているベンダーであり、この問題は対岸の火事ではない。BMCはAmazon.co.jp等で単体購入する消費者向け製品ではなく、サーバーのマザーボードに標準搭載される管理機能であるため、価格比較や購入検討の対象にはならない。むしろ実務上の論点は運用側にある。国内のインフラ・情シス担当者にとっての要点は、①BMCの管理インターフェースをインターネットに直接公開せず、管理用VLANや踏み台経由のアクセスに限定すること、②レガシーなIPMI認証を無効化し、より新しい管理プロトコルへの移行を検討すること、③ファームウェアの棚卸しとパッチ適用サイクルを確立すること、の3点に集約される。Moore氏の指摘どおり「社内に何台のBMCが存在するか自体を把握できていない」組織は珍しくなく、まずは可視化から着手する価値がある。 出典: この記事は Thousands of servers can be backdoored by exploiting buggy motherboard controllers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Sakana AIは8月3日、日本語に特化した大規模言語モデル(LLM)のAPI「Sakana Namazu(サカナ・ナマズ)」を発表した。PC Watchが報じている。API経由での提供で、初期費用・月額費用なしの従量課金制を採用する。 なぜこの新モデルが注目か 国内で流通するLLMの多くは、海外の汎用モデルを日本語向けにチューニングしたものか、パラメータ規模を抑えた軽量モデルのどちらかに寄りがちだった。Sakana Namazuは、オープンモデル「Kimi K2.6」をベースに、日本文化への理解と推論能力の両立を狙った点が特徴だ。単に日本語の文法を扱えるだけでなく、日本の業務文脈への適合や、特定の話題での応答回避・出力の偏りを抑えるチューニングまで踏み込んでいる点は、実務投入を意識した設計と言える。 APIはOpenAI互換で提供されるため、既存のOpenAI SDKやライブラリを使ったコードであれば、接続先エンドポイントを変更するだけで移行できる。ベンダーロックインを避けたい開発者にとっては採用のハードルが低い設計だ。 スペックと機能 Sakana Namazuは、一度指示を与えるとモデル自身がWeb検索やコード実行を自律的に繰り返しながら複雑なタスクを完走する、いわゆるエージェント型の動作を前提に設計されている。単発の応答生成にとどまらず、調べ物や検証を挟みながら結論まで到達させる用途を想定している。 料金体系は以下の通り(1ドル=約160円換算)。 入力: 1Mトークンあたり0.95ドル(約152円) 出力: 1Mトークンあたり4.00ドル(約640円) キャッシュ済み入力: 1Mトークンあたり0.15ドル(約24円) Web検索利用料: 1,000回あたり7.00ドル(約1,120円) コード実行利用料: 1時間あたり0.12ドル(約19円) 出力トークンの単価が入力の4倍強という価格設計は、長文の日本語出力を伴う要約・執筆用途でコストがかさみやすい点に注意したい。 ベンチマーク評価のポイント Sakana AIが公開したベンチマーク結果によると、日本語の指示理解や応答品質を測る「JFBench」でベースモデルのKimi K2.6を1.5%上回るスコアを記録した。数値上の伸びは小幅だが、ベースモデルからの追加チューニングが実際にスコアへ反映されている点は確認できる。 より差が大きいのは、中立的な回答を出力できるかを評価する「FairPoliticsQA」で、Kimi K2.6を22.2%上回るスコアを獲得したという点だ。政治・社会的に敏感な話題を扱う際の偏り抑制は、業務利用やカスタマーサポート用途で重視される評価軸であり、ここでの改善幅の大きさはチューニングの効果が出やすい領域だったことをうかがわせる。ただし、これらはSakana AI自身が公表した数値であり、第三者機関による独立検証の結果ではない点は踏まえておく必要がある。 日本市場での注目点 支払いは米ドル建てが基本だが、法人プランでは円建て決済にも対応する。為替変動を気にする国内企業にとっては地味に重要なポイントだ。初期費用・月額費用がかからない従量課金のみという料金モデルは、小規模な検証プロジェクトから始めたい開発者にも試しやすい。 競合という観点では、GPT系・Claude系・Gemini系といった海外の汎用モデルも日本語対応を継続的に強化しており、汎用性では依然として選択肢が広い。一方、PLaMoやtsuzumiなど国内発の日本語特化モデルも存在する中、Sakana Namazuは「オープンモデルをベースにした低コストな日本語特化API」という位置付けで参入した格好だ。OpenAI互換APIによる乗り換えやすさは、既存システムに手を加えずに日本語特化モデルを試したい企業にとって現実的な選択肢になり得る。まずは自社のユースケースで、汎用モデルとのコスト・精度の両面を比較検証してみる価値はありそうだ。 出典: この記事は Sakana AI、日本に特化したAIモデル「Sakana Namazu」提供開始 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Defender for Office 365(MDO)に、生成AIへの攻撃手法「プロンプトインジェクション」を狙ったメールを自動検知して隔離する新機能「Prompt Injection Protection」が追加された。現在パブリックプレビュー中で、2026年9月上旬に一般提供(GA)が予定されている。Office 365 E5やMicrosoft 365 E5/E7に含まれるMDO Plan 2契約のテナントでは、追加設定なしに既定で有効になる。 メールがCopilotへの攻撃経路になる理由 プロンプトインジェクションは、AIが処理するコンテンツに悪意ある指示を紛れ込ませ、AIの挙動を操作する攻撃手法だ。典型的な手口は、メール本文や添付ファイルに人間には見えない隠しテキストで指示を埋め込むというもの。このテキストはMicrosoft Searchにインデックスされ、Microsoft 365 Copilotがユーザーの問い合わせに応答する際に参照可能になる。攻撃者はここに「メールボックスやSharePoint Onlineの機密情報を検索して外部に送信せよ」といった指示を仕込み、Copilotに悪用させる。 Copilotの登場後、この種の攻撃はまもなく観測されるようになり、Microsoftは検知・抑止の強化を続けてきた。今回のPrompt Injection Protectionは、その延長線上にある対策だ。BEC(ビジネスメール詐欺)やスパムを検知する既存の仕組みと統合される形で動作し、プロンプトインジェクションを含むと判定されたメールは「高確度フィッシング」として自動的に隔離される。管理者側でポリシーを新規作成する必要はない。 見落としがちな「共有メールボックス」のライセンス問題 注意が必要なのは共有メールボックスだ。Copilotは、ユーザーが委任アクセス権を持つ共有メールボックスの中身も参照できる。共有メールボックスは外部からメールを受信できるため、そこに送り込まれたプロンプトインジェクションもCopilotの攻撃対象になり得る。つまり外部メールを受信する共有メールボックスは、実質的にCopilotの攻撃対象領域(アタックサーフェス)の一部であり、2025年10月に示されたMDOライセンスガイダンスに沿ってMDO Plan 2のライセンスを付与すべきということになる。 これを確認するためのPowerShellスクリプトも更新されている。従来は過去10日分のメッセージトレースしか見ていなかったが、新版では取得可能な最大90日分を対象にした。Get-MessageTraceV2コマンドレットは一度に最大10日分しか取得できないため、10日単位でデータを取得してから結合するという工夫が入っている。さらに、共有メールボックスがTeams会議を主催しているかどうかもチェックする。録画はOneDriveの主催者アカウントに保存されるため、共有メールボックス名義で開催された会議の録画も、ライセンス面で見落とされがちなポイントだ。 実務への影響 日本国内でCopilotを導入済み、または導入検討中のテナントにとって、今回の話は「守りの機能が増えた」で終わらせられない。共有メールボックスへの委任アクセスは、常時付与されたままになりがちな権限の典型例であり、「動いているから大丈夫」で放置すると、ライセンス不足による保護の穴がそのまま残る。IT管理者は、外部メールを受信している共有メールボックスの棚卸しと、MDO Plan 2ライセンスの充当状況を今のうちに確認しておきたい。GA予定の9月までに、Exchange管理者は上記のメッセージトレース確認スクリプトを一度実行し、対象となる共有メールボックスの洗い出しをしておくと安心だ。 出典: この記事は Microsoft Defender for Office 365 Blocks Prompt Injections の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Microsoftは現地時間7月31日、ロシア関連の脅威アクター「Midnight Blizzard」のサブグループ「Storm-2945」が、ホテルや会議場が提供する公共Wi-Fiの接続認証画面（キャプティブポータル）を悪用した大規模攻撃キャンペーン「CaptiveCrunch」を展開していると警告した。PC Watchが報じたところによると、標的は出張者や旅行者で、通信の乗っ取りを起点にマルウェア感染や認証情報の窃取を狙っているという。 なぜこの攻撃が見過ごせないのか これまでの公共Wi-Fi悪用の手口は、個々の施設のネットワーク機器を一つひとつ狙うのが一般的だった。今回の特徴は、複数のホテルやイベント会場で使われているキャプティブポータルの管理システムや機器そのものを侵入の足がかりにしている可能性が高い点にある。Microsoftによれば、被害を受けた複数のネットワークの管理システムや機器に共通点が見られ、攻撃者が共有サービス側にアクセスしている可能性を示唆しているという。個別施設のセキュリティ対策とは別の層で攻撃が成立し得る攻撃モデルであり、影響範囲を見積もりにくい点が警戒されている。 手口の核心：キャプティブポータルへの中間者攻撃 スマートフォンやPCはWi-Fi接続時、キャプティブポータルの有無を確認するための接続チェックリクエストを自動送信する仕組みを持つ。Storm-2945はこの自動リクエストに改ざんした応答を返し、ユーザーの通信を攻撃者管理下のフィッシングサーバーへ強制的にリダイレクトさせる中間者攻撃を仕掛ける。 リダイレクト先ではブラウザやOSのアップデートを装ったページが表示され、「ClickFix」と呼ばれるソーシャルエンジニアリング手法でユーザー自身にWindowsターミナルやPowerShellを開かせ、画面の指示通りに検証用スクリプトをコピー&ペーストして実行させるよう誘導する。Androidの場合は「問題修正用」を装ったAPKファイルのダウンロードを促す手口が確認されている。 送り込まれるマルウェア「CornFlake」と「ChocoShell」 ユーザーが手動でコマンドを実行すると、Go言語で書かれたフル機能のリモートアクセス型トロイの木馬「CornFlake」が展開される。初回起動時にはWindows Updateやセキュリティスキャンを装った偽の進捗ウィンドウを表示してユーザーの注意をそらしつつ、裏では正規プロセスのsvchost.exeを模した「svchost32」という名前でサービス化される。サービス化後はC2サーバーと暗号化通信を行い、キーロギング、クリップボード監視、スクリーンショット撮影、Webカメラ映像の取得、ブラウザ認証情報の窃取、USBメモリの監視など幅広いスパイ活動を実行するという。 さらに、メモリ上で実行されるPowerShellベースの資格情報窃盗ツール「ChocoShell」も投入される。AI支援によるコード生成で作成された可能性が指摘されており、防御回避や権限昇格、セッション窃盗、データの外部送信までを担う。攻撃者側は「FruitStone」と呼ばれる管理パネルを使い、侵害端末の一覧管理、新規キャンペーンの構築・展開、窃取データの確認を行っているとMicrosoftは説明している。 日本の出張者・エンジニアが今すぐできる対策 Microsoftは、ホテル・会議場・空港の公共Wi-Fiは基本的に信頼できないものとして扱い、可能な限りモバイルルーターやテザリング、VPNなどプライベートな接続手段を優先するよう推奨している。海外出張が多いエンジニアやIT担当者にとっては、接続時に表示される「アップデートしてください」「証明書をインストールしてください」といったポップアップの指示に安易に従わないことが特に重要だ。特にWindowsターミナルやPowerShellへのコマンド貼り付けを求める画面は、ClickFix型攻撃の典型的なパターンであり、見た目が公式のトラブルシューティング画面に似ていても、その場でコマンドを実行しないという判断が求められる。 日本国内でも海外出張者やカンファレンス参加者は同種のリスクにさらされる可能性があり、社内のセキュリティ教育やモバイルデバイス管理（MDM）ポリシーの中で「公共Wi-Fi利用時の心得」として周知しておく価値がある注意喚起と言えるだろう。 出典: この記事は えっ、公共Wi-Fiの接続画面が偽物？Microsoftが警告する恐るべき手口 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年8月、「Linuxのデスクトップ市場シェアが北米で10%を突破し、Windowsから大量のユーザーが流出している」とする投稿がRedditのr/linuxコミュニティやHacker Newsで大きな話題を集めた。しかし技術メディアWindows Latestが検証したところ、この数字はアクセス解析サービスStatCounterのデータを誤読したものであり、実際にはAIボット・クローラーのアクセス急増が数値を歪めていたことが判明した。Microsoftによれば、Windows 11の稼働台数はむしろ16億台に達しており、2021年時点のWindows 10（13億台）から増加している。Windowsのシェアが実際に急落しているという事実はない。 話題のスクリーンショットに潜む矛盾 拡散したスクリーンショットには「Windows 57.54%、ChromeOS 2.06%、Linux 10.65%、OS X 21.14%、macOS 8.6%」という内訳が表示されていた。ここで注目すべきは「OS X」という項目だ。OS XはAppleが2016年に「macOS」へと名称変更した旧ブランドであり、10年前に姿を消したはずのOSが、現行のmacOS（8.6%）よりも高いシェア（21.14%）を記録している。OS XとmacOSを別OSとして扱うとしても、廃止済みの旧ブランドが現行OSを上回るのは明らかに不自然であり、この一点だけで統計全体の信頼性に疑問符がつく。 StatCounterは「実際の利用者数」を計測していない StatCounterはWebサイト運営者向けのアクセス解析サービスで、Google Analyticsの代替として利用されることが多い。公式には「月間30億ページビュー、100万サイト以上」のデータをもとに集計していると説明しており、計測対象は「ユニークユーザー」や「実機の台数」ではなく「ページビュー」だ。つまり、Linuxベースのボットやクローラーが特定サイト群へのアクセスを急増させれば、実際のPC台数とは無関係にLinuxの比率が跳ね上がる仕組みになっている。生成AIの普及に伴い、Webサイトを巡回するAIエージェントやスクレイピングボットの数が急増していることが、今回の異常値の背景にあると見られる。Windows 11やLinuxを実際に使う人間の行動が変化したわけではない。 過去にも繰り返されてきた「統計の誤読」 実はこの手の誤報は今回が初めてではない。2026年7月にも「Windowsのシェアが60%を割り込み、20ポイントもLinuxに流出した」とする報道があったが、これも後にStatCounter側が数値を訂正している。さらに過去には「Windows 7の利用者が増加し、Windows 11が減少している」という異常値が観測され、複数メディアが「Windows 11は失敗作」といった論調の記事を量産する事態も起きた。Windows 8.1のシェアが特定地域で不自然に急伸した事例も過去に確認されており、いずれも後から修正されている。 実務への影響 StatCounterのようなWebアクセス解析ベースの「市場シェア」データは、あくまでサンプルサイトへのアクセス傾向を反映したものであり、実際のデバイス台数やライセンス数とは性質が異なる。IT部門でクライアントOSの選定や投資判断の材料にする際、こうしたバイラルな統計をそのまま根拠にするのは危険だ。特に生成AI時代においては、AIエージェントやクローラーによるトラフィックが解析データを汚染するケースが今後さらに増える可能性が高く、Webアクセス解析全般（自社サイトのアクセス解析を含む）でボットトラフィックの除外設定を見直す必要性も高まっている。 技術系のニュースやSNSで「◯◯のシェアが急増・急落」という見出しを見た際は、一次データの取得方法（ページビューベースか実デバイスベースか）とサンプルの偏りを必ず確認する習慣を持ちたい。組織内で市場動向を判断材料にする場合は、StatCounterのような単一ソースに頼るのではなく、Microsoftが公表する稼働台数のような一次情報や、複数の独立した調査を突き合わせて裏取りすることが望ましい。 出典: この記事は Linux didn’t just eat 10% of Windows market share, AI bots are inflating the numbers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が発表されたのか Microsoftは2026年7月31日（米国時間）、3月から進めているWindowsの品質向上に関する取り組みについて、進捗と今後の実施予定をまとめたレターを公開した。PC Watchが8月3日付で報じたところによると、このレターの中でMicrosoftは新たに4つの改善分野を掲げており、その筆頭に挙げられているのが「メモリ8GB以上の環境での最適化」だ。具体的には、Windows自体のメモリフットプリントを削減し、日常的に使うPC全体で高速かつ応答性の高い体験を実現するとしている。 残る3つの改善分野は、より迅速でシンプルな初期セットアップ、ペアレンタルコントロールなど家族向け機能への到達しやすさの改善、そしてアプリをまたいだ自然な音声操作だ。いずれも2026年内の実施を目指すとされている。 メモリ8GB環境の最適化が持つ意味 これまでWindows 11は、OS自体のメモリ消費量が大きく、快適に使うには実質16GB以上のメモリが必須とされてきた。一方でmacOSを搭載した「MacBook Neo」などは8GBメモリでも十分に快適だとして市場で支持を集めている。同じ8GBという条件で比較したとき、Windows機がハンデを負っていた構図だ。 Windows 11の最小メモリ要件自体は4GBと定義されているが、今回Microsoftが基準としたのはユーザー数の多い8GB帯だ。4GBや6GBといった、より低いスペック帯を最初のターゲットにするのではなく、多数派である8GB環境の体感を改善するところから着手する、という優先順位づけが読み取れる。 発表のポイント：評価できる点と気になる点 評価できる点は、2026年に入ってからのメモリ価格高騰という市場環境と重なるタイミングであることだ。少しでもコストを抑えてPCを導入したいユーザーにとって、同じメモリ搭載量でも快適に動くかどうかは購入判断を左右する。PC Watchの記事も、この価格高騰局面だからこそ8GB環境の快適性が「死活問題」になっていると指摘している。 一方で気になる点もある。今回のレターでは、メモリ使用量を具体的にどれだけ削減するのか数値目標は示されていない。実施時期も「2026年内」という幅のある表現にとどまっており、どのビルドからどの程度体感が変わるのかはリリースを待って検証する必要がある。3月以降の改善についてはポジティブなフィードバックが得られたとMicrosoftは説明しているが、それはあくまで自己申告であり、8GB環境での最適化が期待どおりの効果を出すかは今後の実機検証が判断材料になるだろう。 日本市場での注目点 日本国内で販売されているノートPCは、価格を抑えたエントリーモデルほど8GBメモリ搭載機の比率が高い。2026年のメモリ価格高騰局面では16GBモデルへの実質的な値上げ圧力もかかっており、8GBのまま快適に使えるかどうかは、これから低予算でPCを選ぼうとしているユーザーにとって直接的なメリットになる。 今回の最適化は新しいハードウェアの発売ではなく、Windows 11 Home／Windows 11 Proの既存ライセンスに対するアップデートとして提供される見込みのため、追加コストなしで恩恵を受けられる点も大きい。今後のInsider Previewやリリースノートで、具体的なメモリ削減幅や対象ビルドが明らかになるかを引き続き確認したい。 関連製品リンク Windows 11 Home 日本語版 Windows 11 Pro 日本語版 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Windows 11、メモリ8GB環境への最適化を年内実施へ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Alibabaは8月3日（中国時間）、同社史上最も高性能と位置づける新型AIモデル「Qwen3.8-Max」を発表した。PC Watchの報道によると、パラメータ数は2.4兆(2.4T)、実際の推論で使われるアクティブパラメータは950億(95B)というMixture-of-Experts型の構成だ。日本でも開発者の間で広く使われている「Qwen」シリーズの最新旗艦モデルにあたる。あわせて、来週にはQwen3.8-Maxのオープンウェイトを公開するほか、小型モデル「Qwen3.8-27B」もオープンウェイトとして公開予定という。これほど大規模なモデルをオープンウェイトで出すのはAlibabaにとって今回が初めてとされる。 なぜQwen3.8-Maxが注目なのか 多くの国産・海外モデルが「クローズドな最強モデル」と「軽量なオープンモデル」を分けて出す中、Alibabaは2.4兆パラメータ級のフロンティアモデルそのものをオープンウェイトで公開する方針を示した。これが実現すれば、企業やエンジニアが自社環境にフロンティア級モデルを直接組み込める選択肢が増えることになる。加えてQwenCloud API側の価格も後述の通り低水準で、コーディング支援やエージェント用途での「使い倒せる」候補として存在感を増しそうだ。 Alibaba発表の性能と海外メディアの報道ポイント PC Watchが報じたAlibaba自身の発表内容によれば、Qwen3.8-Maxは次のような特徴を持つとされる。 自律型コーディング: 空のフォルダから10日間以上にわたり自律的にコードを書き続け、自己進化するハーネスを構築できると主張 実務品質の成果物: 企業コンプライアンス担当弁護士、UI/UXデザイナー、構造エンジニアなど数百の職業を想定したタスクで、本番品質の成果物を出せるとする 長期タスクの自律計画: 半導体設計の最適化や365日間相当のEC運用シミュレーションなど、複数制約を伴う長期タスクをクローズドループで適応学習できるとする ネイティブマルチモーダル: 200ページを超える財務報告書やPDFを解析し、ページをまたいでテキスト・グラフ・図表から洞察を抽出できるとしている これらはいずれもAlibaba自身が示したベンチマークや事例であり、第三者機関による独立レビューの結果ではない点は押さえておきたい。オープンウェイト版が来週公開されて初めて、外部の開発者が実際に手元で動作を検証できるようになる。小型モデルのQwen3.8-27Bについては、Alibabaが自社のX（旧Twitter）アカウントで来週リリースする旨に触れただけで、スペックなどの詳細はまだ明らかにされていない。 日本市場での注目点 QwenCloud API経由の利用料金は、入力が100万トークンあたり2ドル(約314円)、出力が100万トークンあたり6ドル(約940円)、暗黙的キャッシュが100万トークンあたり0.25ドル(約39円)とされる。欧米の大手プロバイダーが提供するフロンティア級モデルと比べても割安な部類に入り、コストを重視してAPI連携を検討する日本の開発者・企業にとっては選択肢の一つになりそうだ。 Qwenシリーズはすでに日本国内でもローカルLLMやAPI経由の利用で一定の実績がある。オープンウェイト版が公開されれば、国内のクラウドサービスやオンプレミス環境への組み込みが進む可能性もある。ただし現時点ではAlibaba発表のベンチマークが根拠のすべてであり、日本語タスクでの実力や既存のコーディング支援ツールとの統合状況は、オープンウェイト公開後の検証を待つ必要がある。 出典: この記事は 史上最強「Qwen3.8-Max」発表。来週は小型のQwen3.8-27Bも！ ～同社初の大規模なオープンウェイトモデル の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Microsoftが7月31日に公開した脅威インテリジェンス記事「CaptiveCrunch」を受けて、国内外のメディアに「マイクロソフトが緊急警告、ホテルのWi-Fiは使うな」という見出しが並んだ。Forbes（およびその日本版）もその一つだ。だが原文を読むと、Microsoftはそんなことを一度も書いていない。しかもこの見出しは、報告書の中で最も効く対策を落とし、最も効かない対策だけを残している。実務者にとって危険な要約なので、原文が何を言っているかを整理しておきたい。 Microsoftが実際に書いた2つの文 該当箇所は次の2文である。 When traveling, users should treat hotel, conference, airport, and other guest wireless networks as untrustworthy. Prefer private connectivity (including mobile hotspots, satellite, and eSIM-based cellular data connections) over public Wi-Fi whenever practical. 「信頼できる前提を捨てろ」「実務上可能な範囲で私設回線を優先しろ」であって、禁止ではない。宛先も"corporate travelers"（企業の出張者）であり、Windowsユーザー一般への緊急警告でもない。MSTICが日常的に出している脅威インテリジェンス記事の一本だ。 攻撃されているのはWi-Fiではなく「キャプティブポータル」 より重要なのは、これが電波の盗聴の話ではないという点である。侵害されているのは、宿泊施設のWi-Fi接続時に出てくるログインページ、すなわちキャプティブポータルのゲートウェイ機器だ。この機器が接続端末に配布されるDNSリゾルバも兼ねていたため、管理権限を取ったロシア系攻撃者グループMidnight Blizzardのサブクラスター「Storm-2945」は、DNS応答を偽造して任意の宛先にユーザーを飛ばせるようになった。 つまり、Wi-Fiにパスワードが掛かっていようが、WPA3で暗号化されていようが、この攻撃には一切関係がない。「暗号化されていない公衆Wi-Fiは危ない」という10年来の啓発モデルとは、脅威の所在が違う。Microsoftは複数施設で機器と管理システムに共通性が見られるとして “similarities suggest that the activity might not be limited to isolated compromises”（個別の侵害に留まらない可能性がある）と述べており、個々のホテルではなくポータル機器やその管理事業者の側が侵害されている可能性を示唆している（調査中で断定はしていない）。 TLSは破られていない — 盗まれ方は3経路 では暗号化されたHTTPS通信からどうやって認証情報を奪うのか。答えは「奪っていない」だ。3つの経路はいずれもユーザー自身に正規の操作をさせる形を取る。 偽アップデート＋ClickFix — Windowsが起動時に行う接続確認（NCSIプローブ）を偽ページに誘導し、「ブラウザやOSを更新せよ」と表示する。ユーザーが自分で実行すると、Go製RATのCornFlake（Webカメラ画像・マイク音声・キーストロークを取得）やPowerShell製インフォスティーラーのChocoShell（ブラウザのセッションCookieを窃取）が入る。 AiTMのサインインページ — Microsoftを模した偽サインイン画面へリダイレクトし、攻撃者インフラを経由させる。 デバイスコードフローの悪用 — 7月16日以降に一部のランディングページへ追加された手口で、これが最も厄介だ。攻撃者側がEntra IDの認証要求を起こし、ユーザーには本物のmicrosoft.comのサインインページで表示コードを入力させる。ユーザーから見て偽サイトの痕跡はどこにもないが、認証されるのは攻撃者のセッションである。 3番目は「URLをよく見て偽サイトを見抜きましょう」という教育では原理的に防げない。ここが今回の報告の核心である。 ...

Copilot for Word(Microsoft 365 Copilot)に、Word文書へ仕込んだ悪意ある指示が生成文書に自己複製し、次々と感染を広げる「ワーム」型の攻撃が成立することが、ノルウェーのデータサイエンティストHåkon Måløy氏の検証で明らかになった。Måløy氏は2026年3月からMicrosoftと5カ月間にわたり調整してきたが、根本的な緩和策は現時点でも提供されていないとして、7月29日にブログで詳細を公開した。 Copilotが「自己増殖ワーム」化する仕組み Måløy氏が示したシナリオはこうだ。ある社員が、財務レポート作成のためにWebサイトから市場分析資料をダウンロードし、Copilot for Wordのコンテキストに読み込ませる。その資料はすでに改ざんされており、白抜き文字などで視認しづらい形で悪意ある指示が埋め込まれている。Copilotはその指示を「参照すべき情報」ではなく「実行すべき追加のプロンプト」として解釈し、生成するレポートの数値を書き換えると同時に、埋め込まれた指示自体を新しい文書にもコピーしてしまう。 この新しい文書を別の社員が自分の作業に取り込むと、同じ改ざんと複製が再び起きる。攻撃者は被害者のMicrosoft 365テナントにアクセスする必要すらなく、悪意ある文書を共有するだけで感染を広げられる。Måløy氏は当初のPoCについてMicrosoftから緩和を受けたが、プロンプトの言い回しを変えるだけで再びワームを成立させ、対象文書の財務データを書き換えることに成功したという。「モデルのアップグレードを含む2回の緩和策も、この脆弱性クラス自体を閉じるには至らなかった」と報告書は述べている。 なぜCopilotだけの問題ではないのか Måløy氏はこれを、LLMアーキテクチャの根本に起因する「クロスドメイン・プロンプトインジェクション」の一種と位置づける。AIアシスタントが実用的であるためには、メール・文書・Webページ・ツール出力など、攻撃者が細工しうる情報を処理せざるを得ない。しかし、ある入力が攻撃かどうかをモデル自身に判定させようとすると、その判定処理自体がすでに攻撃の影響下にあるという構造的なジレンマがある。Måløy氏は「モデルにXPIAの検知を任せるのは、信頼できないプログラムを実行させてそれが攻撃かどうか通訳者に判断させるようなものだ」と表現している。これはCopilotに限らず、外部由来のコンテンツを扱うAIアシスタント全般が抱える課題である。 実務への影響 — 日本のIT管理者・エンジニアが今すぐ確認すべきこと 日本企業でもCopilot for Word/Excelの導入が急速に進んでいるが、今回の報告は「外部由来の文書をAIのコンテキストに入れる行為そのものが信頼境界の通過である」ことを改めて突きつける。取引先や公開サイトから受け取った文書は、たとえ見た目が正常でも無条件に信用しない運用が必要だ。具体的には、Copilotで生成した数値や結論をそのまま配布前に人間が照合すること、白抜き文字や不可視要素を含む文書がないかマクロや検査ツールでチェックすること、財務・契約など数値の改ざんが実害に直結する業務ではAI生成物の配布前レビューを必須プロセスとして組み込むことが挙げられる。 ゼロトラストの発想を借りるなら、社内ネットワークの中にいるかどうかではなく「その文書がどこから来たか」を常に検証対象とする運用に近い。AIアシスタントを介した文書のやり取りも、認証・認可の枠組みと同様に「信頼できないものを持ち込む窓口」として扱う意識転換が、今回のような脆弱性クラスへの実質的な備えになる。 出典: この記事は Word worm crawls into Copilot, spreads chaos の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIは2026年8月1日（現地時間）、開発中の次期主力モデル群「Astra」の社内バージョンが、数学および理論計算機科学の分野で少なくとも10年間、進展のなかった未解決問題10件を解いたと発表した。Astraは複数のサブエージェントを並列に起動・協調させ、数時間から数日かけて複雑な課題に取り組む設計のモデル群で、これまで「開発中」としか伝えられていなかった実態が今回、初めて明らかになった。 Astraとは何か——長時間タスクに特化したモデル群 OpenAI CEOのサム・アルトマン氏は、すでにワシントンD.C.でAstraをデモしている。Astraの最大の特徴は、単発の質問応答ではなく、複数のサブエージェントを並行して走らせて連携させることで、数時間から数日単位の長時間タスクをこなす設計にある点だ。応答生成時に計算リソースを追加投入して思考の深さを増す「テスト時推論」と呼ばれる技術が土台になっている。 10年来手つかずだった数学問題を10件解決 公開された数学レポートによれば、Astraの社内版は高次元幾何学、符号理論、群論、量子計算の複雑性理論、格子暗号、極値組合せ論など幅広い分野で計10件の未解決問題を解いた。中でも「非sofic群の存在証明」は、群論における長年の未解決問題を解決したものとして注目されている。 マンチェスター大学の数学者でerdosproblems.comを運営するトーマス・ブルーム氏はX（旧Twitter）で「大きなニュースだ」とコメントし、5月に発表された単位距離予想の反例よりも意義が大きいとの見方を示した。一方で同氏は、AIが数学者を代替するという主張には否定的で、Astraが100年以上蓄積された数学理論を土台とし、数学者自身が構築・学習させたシステムである以上、そうした主張は成り立たないと指摘している。 テスト時推論技術の開発に携わった研究者のノーム・ブラウン氏は、ミレニアム懸賞問題（クレイ数学研究所が1問100万ドルの賞金を懸けている7つの未解決問題）には今回届かなかったとしつつ、「1問あたりにかけた計算量はまだ少ない。テスト時計算をさらに押し上げる余地はある」と述べている。 証明はAIが生成、論文化とLean形式化は人間が支援 OpenAIによると、10件の証明を生成するのに要したトークン量は、API料金換算で合計約2000ドルにとどまる。数学的な論証そのものはAstraが生成し、それを論文の体裁に整える作業と、証明支援系Leanによる形式検証（機械可読な正しさの証明）を人間の研究者が支援した。OpenAIは、AIが生成した証明を人間の著作であるかのように扱うことは、システムの貢献と人間の知的営為の双方を誤って伝えることになるとして、AIと数学に関する「ライデン宣言」を参照点に挙げている。 米政府の新レビュー制度、第1号になる見通し Astraは、米国政府が新設した、高度なAIモデルの一般公開前に承認を必要とするレビュー制度の対象第1号になる見込みだという。GPT-6として正式リリースするかどうかは、現時点で未定としている。 実務への影響 日本のエンジニアやIT管理者にとって注目すべきは、「証明の中身」よりも「かかったコストと構成」だ。10件の未解決問題を解くのに要した金額がAPI換算で約2000ドルという数字は、テスト時推論を使った高難度タスクのコスト感覚を掴む材料になる。1タスクに数時間から数日を投入するサブエージェント協調型のアーキテクチャは、コーディングエージェントや業務自動化のワークフロー設計にもそのまま応用できる考え方であり、「1回のプロンプトで即答を得る」設計から「エージェントに時間をかけて任せる」設計への移行を検討する際の参考になる。 また、Leanによる形式検証を組み合わせて出力の正しさを機械的に担保する手法は、数学の証明に限らず、コード生成や設計の検証可能性を高める発想として応用範囲が広い。生成物をそのまま信頼するのではなく、検証可能な形で正しさを担保する仕組みをセットで持つという考え方は、社内でAIの生成物を業務プロセスに組み込む際にも参考になる。 もう一点、米国政府による事前レビュー制度の対象にAstraがなるという事実は、今後、高性能AIモデルの公開に規制のハードルが加わっていく可能性を示している。海外の最先端モデルをいち早く業務に取り込みたい日本企業にとっては、モデルの提供タイミングが規制プロセスに左右されるケースが増えることを念頭に置いておく必要がある。 出典: この記事は OpenAI is reportedly building Astra, a model family designed to work on problems for hours or days の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleは、Chromeブラウザにおいて、マルウェアが企業向け拡張機能ポリシーを悪用し、新しいタブページ（New Tab）や既定の検索エンジンを勝手に書き換える「ポリシーハイジャック」を、未管理の一般消費者向けWindows・macOS PCで標準ブロックする新機能を準備していることが、BleepingComputerの報道で明らかになった。ChromiumのGerritコードレビューで進行中の変更として見つかったもので、審査が通り次第デフォルトで有効化される見通しだ。 「管理ポリシー」を悪用したなりすましの手口 Chromeには、ドメイン参加PCやMDM（モバイルデバイス管理）配下の企業端末向けに、管理者が拡張機能を強制インストールしたりブラウザ設定をロックしたりできる「エンタープライズポリシー」機能がある。正規の管理下にある端末では有用な仕組みだが、Chromeはこのポリシーを、信頼できる権威（ドメインやMDMサービス）による確認なしに、ローカルに保存された設定値としてそのまま読み込んでしまう。 マルウェアはこの盲点を突く。一般消費者のPCにローカルのChromeポリシーキーを勝手に書き込み、New Tabページの書き換えや検索エンジンの変更を行う拡張機能を「管理者インストール」を偽装して強制導入する。Chrome側はこれを正規の管理者操作と誤認するため、ユーザーは該当の拡張機能を無効化・削除できなくなる。加えて、実際には組織管理下にない個人PCにもかかわらず、「このPCは組織によって管理されています」という紛らわしいメッセージが表示されるケースもあるという。Googleはこうした一般消費者PCを、信頼できる確認元を持たない「低信頼環境」と位置づけている。 Chromeが追加する新しい防御策 今回準備されている機能フラグ「kBlockDseNtpOverrideExtensionsOnUnmanagedDevices」は、未管理のWindows・macOS端末で以下の防御を有効にする。 New Tabページや既定検索エンジンを上書きしようとするポリシー強制インストールの拡張機能を、インストールの段階でブロックする ブロックした拡張機能IDを記録し、以降のポリシーチェックで同じ拡張機能への再ダウンロード試行を止め、不要な通信も抑制する ユーザーが自分の意思で手動インストールした拡張機能は、ポリシー管理下の「ロック状態」へ自動的に格上げされなくなり、引き続き自分で無効化・削除できる かつて正規に管理されていた端末が管理状態を失った後も、古いローカルポリシーキーが端末に残っている場合、該当のNew Tab／検索エンジン上書き拡張機能をChromeが自動的にアンインストールする ハイジャック拡張機能の出現頻度やブロック実績を把握するための計測機能も追加される 業務上どうしてもNew Tabや検索エンジンをポリシーで上書きする必要がある正規の管理者向けに、保護を無効化できるエスケープハッチポリシーも用意される なお、この変更はまだChromiumのGerritでレビュー中であり、安定版（Stable）Chromeには未搭載である。 実務への影響 ドメイン参加やIntune等のMDMで正しく管理されている企業端末は、今回の保護の対象外（「未管理端末」向けの機能）であるため、通常運用に影響はない見込みだ。ただし、BYOD端末や個人所有だが業務利用している端末など、管理状態があいまいな機器を抱える組織は、安定版への展開時に動作検証をしておく価値がある。 もし社内ポータルを既定ページにするなど、正規の目的でポリシーによるNew Tab／検索エンジンの上書きを行っている場合は、今回追加されるエスケープハッチポリシーの適用を忘れないよう、デスクトップ管理チームに早めに周知しておきたい。 ヘルプデスクの観点でも意味がある。「身に覚えのない検索エンジンへの変更」「知らないうちに『組織によって管理されています』と表示される」という相談は、まさに今回Googleが対処しようとしている攻撃パターンそのものだ。原因の説明や利用者への案内が、ベンダー自身の説明に基づいて行いやすくなる。 より広い視点で見ると、今回の問題は「外部の信頼できる権威による検証を経ないまま、ローカルの設定値を暗黙に信頼してしまう」設計が突かれた事例といえる。ゼロトラストの基本である「常時・無条件の信頼を置かない」という考え方は、こうしたブラウザのローカルポリシー読み込みのような足元の設定にも当てはまる。 出典: この記事は Google Chrome may soon block New Tab hijacker extensions by default の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude Code、最高なんだけど「記憶」の扱いが難しい続きをみる note.com で続きを読む →