Tech News JP

米連邦通信委員会（FCC）は現地時間7月20日、DJIの技術を米国の外国製ドローン規制の網の外へ持ち出そうとしているとみられる「フロント企業」に対し、既存製品の輸入・流通・販売そのものを遡及的に禁止する手続きに着手したと発表した。The VergeのSean Hollister記者が報じた。対象はドローンブランド「Skyrover」やカメラブランド「Xtra」など計9社で、いずれもDJI製品と酷似した製品を米国市場に投入してきた企業だ。 なぜこの規制強化が注目か FCCは昨年10月、一度承認した機器の認可を後から取り消せる「遡及的禁止」の権限を自らに与えていた。今回はその権限を初めて実際に行使しようとする試金石にあたる。2週間前にはSkyroverとXtraの背後にいる8社に対し2万5000ドルの罰金を提案したばかりだったが、今回はそれを大きく上回り、対象企業がドローンやカメラを輸入・流通・マーケティング・販売する行為そのものを禁じる内容に踏み込んだ。Xtra版のDJI Osmo Pocket 3にあたる「Xtra Muse」は、Amazonで翌日配送も可能な現行製品であり、禁止が発効すればこうした主要ECサイトや自社サイトから姿を消し、企業側は倉庫在庫の償却を迫られる可能性がある。 海外メディアの報道ポイント The Vergeによると、対象となるのはCogito Tech、Fixaxo Technology、Lyno Dynamics、Skyhigh Tech、Spatial Hover、SZ Knowact、WaveGo Tech（後者2社はSkyroverの運営元）、Xtra Technology、そして農業用ドローンブランドのXAGの9社。XAG以外はFCCからの情報提供要請に一切応じておらず、対象企業の大半は研究者Konrad Iturbe氏が独自に「FCCフロント企業」を追跡した調査によって特定されたという。FCCは同日、これらの製品の認証を後押ししていた中国の試験機関SGS-CSTC深センとの関係も打ち切ると発表している。 一方でHollister記者は、FCCの姿勢に留保も示している。FCCは今回「国家安全保障上の懸念」があると“暫定的に結論づけた”としつつ、30日間のパブリックコメントを募集し「具体的な証拠」があれば見直すとするが、同記者は過去にFCCがネット中立性を巡るパブリックコメントを事実上無視したり、サイバー攻撃を巡って虚偽の説明をしたりした前例があると指摘する。外国製ドローンが安全保障上の脅威だとする具体的な公開証拠は、米政府からこれまで一度も示されていない点も強調されている。また「認可コード（グランティーコード）を一時的に留保した」という表現についても、元FCC職員が「聞いたことがない言い回し」と証言しており、実際の意味は明確にされていない。 日本市場での注目点 SkyroverやXtraは米国市場向けにDJI製品の外観・仕様を模した廉価ブランドとして展開されており、日本国内で正規に流通しているわけではない。したがって今回の規制が日本の消費者に直接影響することはないが、示唆は小さくない。日本ではDJIの正規品（Mini 4 ProやOsmo Pocket 3など）が家電量販店やAmazon.co.jpで通常どおり購入でき、米国のような安全保障目的の禁輸措置は取られていない。米中対立を背景にした規制が「本家DJI製品」だけでなく「そっくり製品を売る第三者ブランド」まで対象を広げている点は、輸入ドローンや監視カメラを巡る規制論が日本で持ち上がった際の先行事例として参考になるはずだ。価格面では、DJI Osmo Pocket 3は国内でも6万円台から購入可能で、今回の一件は正規ルートで購入することの価格・供給両面での優位性を改めて浮き彫りにした。 筆者の見解 今回のFCCの動きを見て感じるのは、「禁止すれば解決する」という発想の危うさだ。SkyroverやXtraのような迂回ブランドが生まれたこと自体、外国製ドローンを一律禁止する規制が安全保障上の懸念を根本から解消せず、単に供給ルートを複雑化させただけだったことの証左と言える。禁止アプローチは往々にして抜け道を生み、かえって実態把握を難しくする。本当に必要なのは、ユーザーが公式で透明性のあるルートを選ぶことが一番合理的だと感じられる仕組みづくりのはずだ。 日本のエンジニアや消費者にとっての教訓もシンプルだ。奇をてらった迂回ブランドや出所不明の類似品に手を出すより、サポートや部品供給が安定している正規ルートを選ぶという「道のド真ん中を歩く」判断が、結局は一番安全で再現性が高い。今回のニュースは、規制動向そのものを追いかけることよりも、購入前に流通経路と正規性をきちんと確認する習慣の大切さを改めて示してくれた。 関連製品リンク DJI Mini 4 Pro DJI RC-2リモコン付属 4K動画撮影対応 DJI Vlog Camera Osmo Pocket 3 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は The FCC is planning to retroactively ban disguised DJI gadgets の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

中国が主導する新たな国際AIガバナンス機構「世界人工知能協力機構(WAICO: World Artificial Intelligence Cooperation Organization)」が2026年7月18日、上海で正式に発足した。ロシア、ブラジル、パキスタン、カザフスタン、ラオス、インドネシアなど29カ国が設立協定に署名し、本部を上海に置くことで合意した。式典で習近平国家主席は、途上国向けに5000件のAI研修機会を提供すると表明した。 WAICOとは何か WAICOは、AI技術の国際協力・標準策定・人材育成を掲げる政府間組織だ。これまでAIガバナンスの分野では、英国主催のAI安全サミット（ブレッチリー宣言）に始まり、韓国・ソウル、フランス・パリと続いた「AI Action Summit」の流れや、G7広島プロセス、OECDのAI原則など、欧米主導の枠組みが先行してきた。WAICOはこれに対抗するように、中国と新興国・途上国を中心に据えた新たな極を作ろうとする動きと見てよい。 「本部が上海」の意味するもの AIガバナンスの世界では、どの国が事務局機能や基準策定の主導権を握るかが、そのまま実質的な影響力に直結する。本部を上海に置くという決定は象徴以上の意味を持ち、今後の技術標準・認証制度・人材育成プログラムの設計を中国が主導する体制づくりの一手と読むべきだろう。 実務への影響 日本のエンジニアやIT管理者がWAICOそのものに直接関わる場面は当面考えにくい。ただし、AIガバナンスが欧米ブロックと中国主導ブロックに分かれていく流れは、海外展開する企業にとって無視できない変化だ。東南アジアや中央アジアの政府機関向けにAIソリューションを提供している、あるいはこれから提供しようとしている場合、相手国がWAICO参加国であれば、同機構発の認証・研修制度への対応を将来的に迫られる可能性がある。グローバル展開する製品・サービスは、複数のガバナンス基準に同時対応できる設計を今のうちから検討しておきたい。 筆者の見解 正直なところ、こうした国家間の機構設立のニュースは、現場のエンジニアが日々AIをどう使いこなすかという話とは一旦別のレイヤーにある。政府間の枠組み作りには時間がかかるし、5年後にどちらの陣営が主導権を握っているかは誰にも分からない。むしろ大事なのは、こうした大きな地政学ニュースに気を取られすぎず、今使える生成AIエージェントを実際に手を動かして使い倒し、成果を出す経験を積むことだ。情報を追いかけるコストよりも、実践から得られるリターンの方が今の局面では圧倒的に大きい。 もう一つ付け加えるなら、AIガバナンスの分裂が進むほど、エンタープライズ向けにコンプライアンスやガバナンスを一元管理できるプラットフォームの価値は上がっていく。応援する立場から言わせてもらえば、Azureやディレクトリ・コンプライアンス基盤を持つMicrosoftは、本来こうした複数のガバナンス体制をまたいで顧客を支援できる立ち位置にいるはずだ。その強みを十分に活かしきれていないとしたら、もったいない話だ。正面から勝負できる力があるのだから、遠慮せず存在感を発揮してほしい。 出典: この記事は 29 countries join World AI Cooperation Organization in Shanghai の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国でAI関連の技術標準を担う政府機関「CAISI（Center for AI Standards and Innovation、AI標準革新センター）」のトップがまた辞任した。ディレクターのChris Fall氏が就任からわずか3か月で退任したことを、CAISIが複数の報道機関に確認した。CAISIのトップ交代はこれで3人目、しかも1年に満たない期間での出来事だ。 CAISIとは何か、なぜトップが居着かないのか CAISIは米国立標準技術研究所(NIST)傘下の組織で、AIモデルの技術標準策定やテスト手法の開発、サイバーセキュリティリスクの評価を担う、AI政策の実務を支える機関だ。 その最初のトップは、ベンチャーキャピタリストでホワイトハウスのAI・暗号資産担当「AI czar」だったDavid Sacks氏で、3月に退任。後任のCollin Burns氏は就任から1週間足らずで「更迭」されたとWashington Postが報じている。BurnsはAnthropic出身で、トランプ政権とAnthropicの間の対立が背景にあったとされる。そして4月から3か月務めたChris Fall氏も、明確な理由の説明なく去った。エネルギー省で科学局長やARPA-E局長代理を歴任した人物ですら、この椅子には長く座れなかった。 Anthropicモデル排除と中国オープンモデル規制論争 このポストがこれほど落ち着かない背景には、AI規制を巡る政権内の路線対立がある。6月には商務省が輸出規制の一条項を使い、AnthropicのMythosとFableのモデルを事実上市場から排除する措置を取った。この禁止措置はLutnick商務長官がAnthropicの安全計画に納得したとして月末に解除されている。 さらに今月、ホワイトハウスはサイバーセキュリティ脆弱性の調整を担う新しいAI安全監視プログラム「Gold Eagle」の大統領令に署名したが、CAISIはこのプログラムの参加機関リストに含まれていなかったとCNBCが指摘している。 同じタイミングで、中国Moonshot AI社のオープンモデル「Kimi」の新版がフラッグシップ級のモデルと遜色ない性能を見せたことも波紋を広げた。Axiosの報道によれば、政権内では中国製オープンモデルを何らかの形で禁止する案が検討されているという。これにはSacks氏本人も反対を表明しており、「規制を自国AI企業の保護主義の道具にすべきではない」と主張している。一方でGoogle DeepMindのDemis Hassabis CEOは、FINRA(米金融取引業規制機構)をモデルにした、業界主導の独立した標準策定機関の設立を呼びかけている——まさにCAISIが本来担うはずだった役割だ。 CAISIはこれまでZ.aiのGLM-5.2やDeepSeekのV4 Proなど中国製オープンウェイトモデルの性能評価レポートをいくつか出しているが、その評価プロセスの詳細は明らかにしていない。TechCrunchが7月9日以降、商務省とNISTに複数回問い合わせているが、回答は得られていないという。 実務への影響 日本のIT現場にとって直接の影響は小さく見えるかもしれないが、注意すべき点が2つある。 1つ目は、米国の輸出規制がAIベンダーの提供継続性そのものを揺さぶりうるという事実だ。今回Anthropicのモデルが一時的に市場から消えた一件は、政治判断ひとつでクラウドAIサービスが使えなくなるリスクが現実にあることを示した。特定ベンダー・特定国のモデルに全面依存する構成は、技術的な最適解であっても地政学リスクの面では脆弱になりうる。 2つ目は、中国製オープンウェイトモデル(DeepSeek、GLM、Kimiなど)を評価・検証中の企業は、今後の規制動向を注視する必要があるという点だ。オープンウェイトで自前ホストできる利点があるため国内でも採用例が増えているが、規制強化が輸入・利用そのものに及ぶ可能性はゼロではない。 筆者の見解 正直なところ、この手のニュースを逐一追いかけて一喜一憂する必要はないというのが筆者の基本スタンスだ。米国の政局がどう転んでも、エンジニアが今日やるべきことは変わらない——手元で使えるツールを全力で使い倒し、実際に成果を出す経験を積むことに尽きる。 ただし、AnthropicのモデルがCommerce省の一存で一時的に市場から消えたという事実は見過ごせない。技術標準や安全性評価という本来もっとも政治から距離を置くべき機能が、政権交代のたびにトップごと入れ替わる不安定な状態にあるのは、業界全体にとって望ましいことではない。その意味で、Hassabis氏が提案するFINRA型の業界主導・独立系標準機関という方向性は理にかなっている。技術的な検証は技術のプロが担い、政治的な駆け引きから切り離す仕組みがあった方が、ベンダーにとってもユーザーにとっても予見可能性が高まるはずだ。 日本の開発者にできることは限られているが、「特定の国・特定のベンダーに依存しすぎない」という当たり前のリスク管理を、AIスタックの選定でも徹底することだろう。クラウドもローカルも、複数の選択肢を手元に持っておく。それが、こうした政策の混乱に振り回されないための一番の備えだ。 出典: この記事は Trump’s latest AI czar has already resigned の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ドイツのAIスタートアップPrior Labsが、設立からわずか18カ月でSAPに買収されることが2026年7月17日に発表された。買収額は10億ユーロ超で、SAPは今後4年間にわたり同社のインフラ整備・人材採用・長期研究に資金を投じる。Prior Labsは企業の構造化データ（表形式データ）に特化した「表形式基盤モデル（Tabular Foundation Model、TFM）」の先駆者で、支払い遅延予測や顧客離反予測、サプライヤーリスク評価、需要予測といった企業の予測業務を、データセットごとに個別学習することなく単一の事前学習済みモデルでこなせる技術を開発してきた。 表形式基盤モデルとは何か 生成AIの主戦場はテキストや画像を扱う大規模言語モデル（LLM）だが、企業の基幹業務を支えているデータの大半は、売上・在庫・顧客属性・センサーログといった表形式（テーブル型）の構造化データだ。従来、こうしたデータで予測モデルを作るには、案件ごとに個別の機械学習モデルを一から学習させる必要があった。 Prior Labsの中核技術TabPFNは、この前提を覆す。あらかじめ大量の合成データで事前学習された単一の基盤モデルが、追加学習なし、あるいは軽い適応だけで新しい表形式データに対して予測を行える。最新版「TabPFN-3-Thinking」は、表形式予測タスクにおいて業界最高水準・エンタープライズ級の性能を達成しているという。実際に鉄道車両大手Hitachiは車両故障の予兆検知に、金融機関TDは財務予測にこの技術を採用済みで、膵臓がん診断からワイルドファイア予測、次世代電池材料の探索まで、数百件の研究プロジェクトで応用されている。 SAPの狙いと独立性の維持 SAPのCTOであるPhilipp Herzig氏は、「エンタープライズAIで最も手つかずの機会はLLMではなく、世界中の企業を動かしている構造化データ向けのAIだった」という趣旨のコメントを出している。SAPはERPという形で世界中の企業データを扱ってきた立場を生かし、Prior Labsのモデルと自社の顧客基盤・データ環境を組み合わせることで、このカテゴリーで主導権を握る狙いだ。 一方でPrior Labsは買収後もブランド・経営陣・研究方針・既存顧客との関係を維持し、独立した研究機関として活動を続ける。研究成果の公開やモデルのオープンな提供も継続する方針で、SAPは資金と大規模データ環境の提供に徹する形だ。Yann LeCun氏やBernhard Schölkopf氏といった著名研究者が科学諮問委員会に名を連ねている点も、同社が単なる買収先ではなく独立した研究拠点として扱われていることを裏付けている。 実務への影響 日本でもSAP ERPを基幹システムとして使う企業は多く、需要予測・支払い遅延予測・サプライヤーリスク評価といった業務は経理・調達・生産管理の現場に直結する。表形式基盤モデルが実用段階に入れば、こうした予測業務を「データサイエンティストが個別にモデルを作る」ことから「基盤モデルに業務データを渡すだけ」に近づけていける可能性がある。IT部門にとっては、SAPの標準機能として将来この種のAIが組み込まれることを見越し、自社データの品質・構造化整備を今から進めておく価値がある。バラバラに個別最適なAIツールを導入するより、基幹システムのベンダーが用意する標準的な仕組みに乗る方が、長期的な運用コストは低く済むはずだ。 筆者の見解 今回の買収で興味深いのは、SAPが「LLMで何かをやる」ではなく、地味だが実務に直結する表形式データの予測AIに本気の投資をした点だ。派手なチャットボットや生成AIのデモよりも、経理や調達の現場で実際に数字を動かす技術に賭けるというのは、奇をてらわない王道の選択だと感じる。 生成AIの話題はどうしてもLLMやAIエージェントに集中しがちだが、企業の意思決定の大半は依然として表形式データの上で行われている。そこに特化した基盤モデルという発想は、地に足がついていて好感が持てる。買収後もPrior Labsの独立性を保ち、研究成果とモデルを引き続きオープンにする方針も、目先の囲い込みより長期的な技術力の蓄積を優先する姿勢として評価できる。 日本の企業にとっても、SAPという既に導入済みの基幹システムの延長線上でこの技術に触れられるようになるなら、新しいAI基盤を一から選定する負担なく実務に取り入れやすい。派手さより実利、という今回のSAPの判断は、今後のエンタープライズAIの一つの「王道」になっていくのではないかと見ている。 出典: この記事は SAP acquires Prior Labs just 18 months after launch in €1B+ deal の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ある日の昼下がり、ふと思った。「ターミナルを開かずに、スマホのDiscordからClaude Codeに指示を出したい」続きをみる note.com で続きを読む →

化粧品大手エスティローダー（Estée Lauder）は、人事（HR）管理に使っていたOracle E-Business Suite（EBS）の脆弱性を突かれ、氏名や社会保障番号（SSN）、パスポート番号、健康情報などの個人情報が外部に流出したとして、対象者への通知を開始した。侵害が発生したのは2025年8月9日だが、社内で確認できたのは2026年6月19日で、実に10カ月以上のタイムラグがあったことになる。 侵害の詳細——侵入口はBI Publisherの脆弱性 エスティローダーの通知文によれば、侵入経路はOracle E-Business SuiteのBI Publisher Integrationコンポーネントに存在した脆弱性、CVE-2025-61882とみられる。このCVEはEBSバージョン12.2.3〜12.2.14に影響し、認証を経ずにリモートコード実行が可能になる深刻な欠陥で、Oracleは2025年10月4日に緊急パッチを公開した。GoogleとMandiantの調査によれば、ランサムウェアグループ「Clop」はパッチ公開前の2025年8月上旬から、この脆弱性をゼロデイとして悪用する大規模攻撃キャンペーンをすでに展開していた。 流出したとされる情報は、氏名・住所・メールアドレス・生年月日・社会保障番号（SSN）・パスポート番号・銀行口座情報を含む金融情報・健康情報・給与や人事評価を含む雇用情報と、極めて機微なデータが揃っている。エスティローダーは対象者にKroll社による24カ月間の無料ID監視サービスを提供すると発表した。 Clopによる連続被害と「2度目」という事実 同じ攻撃キャンペーンでは、ハーバード大学、ペンシルベニア大学、ダートマス大学、University of Phoenix、ワシントン・ポスト、Logitech、GlobalLogic、Cox Enterprises、アメリカン航空傘下のEnvoy Airなど、著名な組織が軒並み被害に遭っている。基幹ERPをインターネットに公開している組織がいかに多いかを物語る事例だ。 さらに見逃せないのは、エスティローダーがClopの被害に遭うのはこれが初めてではないという点だ。2023年にもMOVEit Transferのゼロデイ脆弱性を突かれて情報を窃取されている。同じ攻撃グループに、異なるベンダー製品の脆弱性経由で繰り返し侵害される——この構図は他の大企業でも十分起こり得る。 実務への影響 日本国内でもOracle E-Business Suiteを人事・会計の基幹系として使う大企業は少なくない。今回のケースから、IT管理者が見直すべきポイントは以下の通りだ。 インターネット公開資産の棚卸し: 基幹ERPは「社内システムだから安全」という思い込みで、外部公開状況が正確に把握されていないケースが多い。External Attack Surface Management（EASM）による定期的な棚卸しが必須。 パッチ適用サイクルの見直し: 業務影響を恐れて基幹系のパッチ適用が後回しにされがちだが、ゼロデイで大規模悪用される脆弱性ほど、緊急パッチの適用速度が被害の大きさを分ける。 HRシステムのデータ分類と権限の最小化: SSN・パスポート番号・健康情報のような機微データを扱うシステムには、通常業務とは別に、より厳格な認可レイヤーを設けるべき。 侵害検知までの時間短縮: 侵入から発覚まで10カ月というギャップは、ログ監視・異常検知の甘さを示している。SIEM/EDRのルールが実際に機能しているかを定期的に検証する仕組みが必要。 筆者の見解 正直なところセキュリティ分野は細かい話が多く得意領域とは言えないが、こうした事例には技術的にとても興味を惹かれる。BI Publisherという「業務に必須だが目立たないコンポーネント」が侵入口になった点は象徴的で、境界防御・多層防御の考え方がいかに大事かを改めて示している。 筆者は以前からゼロトラストを強く推進する立場で、ネットワーク層・認証層・認可層の3層で守る発想を大事にしている。今回のEBS侵害は、インターネットに公開された基幹システムを「境界の内側にあるから」と過信していた典型例に見える。「今動いているから大丈夫」という判断がどれほど危ういかは、過去の教訓からも明らかだ。基幹ERPだからこそ、常時アクセス可能な状態を極力減らし、必要なときだけアクセスを許可するJust-In-Timeの発想を当てはめるべきだと思う。 もう一つ気になるのは、エスティローダーが2023年のMOVEit事件に続いて再びClopの被害に遭った点だ。同じ攻撃者に繰り返し狙われるということは、防御側の学習が生かされていないか、サプライチェーン全体のリスク管理が追いついていないことを意味する。1つのベンダー製品への対応にとどまらず、「基幹系ソフトウェア全体をどう守るか」という視点への切り替えが、日本企業にとっても急務だと感じる。 出典: この記事は Estée Lauder discloses data breach via Oracle E-Business flaw の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティベンダーのSonicWallが提供するVPNアプライアンス「SMA1000」シリーズで、公表前の未知の脆弱性2件が少なくとも1ヶ月にわたり悪用され、攻撃者が専用開発したマルウェアを機器内部に埋め込んでいたことが、インシデント対応会社Volexityの調査で明らかになった。 脆弱性の中身と攻撃の流れ 対象は6210、7210、8200vの3機種。悪用されたのはCVE-2026-15409（サーバーサイドリクエストフォージェリ、深刻度Critical）とCVE-2026-15410（コマンドインジェクション、深刻度High）の2件だ。SonicWallは先週この2件を「実際に悪用されている」として緊急告知し、12.4.3-03453／12.5.0-02835でパッチを配布したが、悪用の技術的な詳細までは開示していなかった。 Volexityの報告によれば、同社が「UTA0533」と名付けた未知の攻撃グループは、今年6月22日の時点ですでに侵入を開始していた。SonicWallが脆弱性を公表するより数週間前だ。攻撃の手口は次の通り整理できる。 CVE-2026-15409を突き、本来は機器内部からしかアクセスできないはずの/wsproxyエンドポイントを悪用して、認証なしのWebSocketトンネルを確立。内部で動くCouchDBや管理サービスに到達する CouchDBから機器固有のproduct_uuidを取得する（具体的な取得手口はVolexityも「不明」としている） そのUUIDを使い、管理コンソールのsysCtrl.execRemoveHotfixというRPCメソッド経由でCVE-2026-15410のコマンドインジェクションを実行し、root権限を奪取する root権限を得た後は「KNUCKLEBALL」というPython製ドロッパー（deploy_new.py）を設置し、Java製の常駐マルウェア2種を展開する。「Sou5」は侵害機器を踏み台にするリバースプロキシ、「ORANGETAIL」は暗号化したJavaペイロードを外部から送り込んで実行できるWebシェルだ。さらにnginx設定を書き換えてWebシェルを外部に公開し、root権限昇格ツール「ROOTRUN」まで仕込んでいた。Volexityは技術的な巧妙さを認めつつ、内部ネットワークへの横展開には至らなかったケースも多かったとしている。 実務への影響 日本企業にとってもSMA1000のようなSSL-VPN／リモートアクセス機器はリモートワークの生命線であり、他人事ではない。対応の優先順位は次の3点だ。 該当機種（6210／7210／8200v）を使っている場合は12.4.3-03453／12.5.0-02835への即時パッチ適用 パッチ後も、6月22日以降のログ・設定変更履歴を遡って侵害有無を確認する（パッチは新規侵入を防ぐだけで、既存の侵害を消してはくれない） nginx設定の改ざん痕跡や、不審なJavaプロセス（agent_wp8.jar／agent_wp9.jar相当のファイル）の有無をチェックする 境界に置かれたVPN機器は、一度突破されると内部ネットワークへの入口になる。パッチ適用だけでなく、管理インターフェースを本当にインターネットへ露出させる必要があるか、外部公開範囲そのものを見直すきっかけにしたい。 筆者の見解 VPNアプライアンスがゼロデイで突かれる事件は、もう「たまに起きる例外」ではなく、境界防御に依存する構成そのものが抱える構造的なリスクだと捉えている。今回のケースも、正規のエンドポイントの実装ミスから始まり、内部サービスへの横移動、そしてroot権限奪取まで一直線につながった。境界の一箇所が破られると内部を総取りされる構図は、VPN機器のインシデントで繰り返し見てきたパターンだ。 だからこそ、ネットワーク層だけに頼らず、認証層・認可層まで含めた多層防御と、常時アクセス権を持たせないJust-In-Timeの権限管理へ切り替えていく発想が要る。境界の内側にいること自体を信頼の根拠にしない、いわゆるゼロトラストの考え方は、こうした事件が起きるたびに正しさが裏付けられていく。VPN機器の運用担当者には、パッチ適用と並行して「この機器が破られたら次に何が起きるか」を一度棚卸ししてみることを勧めたい。 出典: この記事は SonicWall SMA1000 flaws exploited as zero-days to push custom malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAのジェンスン・フアンCEOが7月15日から16日にかけて来日し、経済産業省主催の「我が国のフィジカルAI政策に関する対外発信イベント」など、分刻みのスケジュールで複数のイベントに参加した。PC Watchのコラム「笠原一輝のユビキタス情報局」(執筆:笠原一輝氏)によると、フアン氏は滞在中一貫して「日本のメカトロニクス産業にはフィジカルAI時代の大きなチャンスがある」と強調し、国産ファウンドリ「Rapidus」の可能性についても前向きな見方を示したという。 なぜこの来日が注目なのか フィジカルAIとは、AIをクラウドやチャットの中だけでなく、ロボットや自動車、工場設備といった物理的な機械に組み込む考え方だ。NVIDIAはこれまでデータセンター向けGPUで急成長してきたが、次の成長領域として、ロボットや自動運転などハードウェアと一体化したAI市場を強く意識している。そこで焦点になるのが、川崎重工・安川電機・ファナックといった産業用ロボットメーカーや、トヨタ自動車・本田技研工業・日産自動車といった自動車メーカー、さらにそれを支える中小企業まで含めた裾野の広いサプライチェーンをすでに持つ日本だ。フアン氏の今回の来日は、この日本の「ものづくりの厚み」にAIを組み合わせる戦略を、経産省や日本企業と共に本格的に打ち出す場になったと言える。 現地報道が伝えたポイント 笠原氏の報告では、フアン氏は16日夕方のぶら下がり会見で、海外記者による対中国向け「H200」に関する質問を「ここは日本だ、日本向けの質問をお願いしたい」と遮る一幕があった。COMPUTEXやGTCなど国際的なイベントでは記者の質問を遮ることはほとんどないといい、笠原氏はこれを異例な対応だったと分析している。 また「日本はすでにこの分野で負けつつあるのでは」という記者の質問に対しては、フアン氏は「日本人だけが日本のメカトロニクスの価値を理解していない」と応じ、AIを取り込むことでさらに進化できるとの見方を強調したと報じられている。 具体的な提携としては、富士通とNVIDIAが川崎重工・安川電機・ファナックの3社にAIソリューションを提供する枠組みが発表された。さらに経産省主導の「FRONTia」計画では、産業技術総合研究所やソニーグループ・ソフトバンク・NEC・本田技研工業などが出資する新会社Noetraが、Vera Rubin NVL72ラックを計算上382台、Vera CPU 13,750基以上・Rubin GPU 27,500基以上を搭載する140MW級のAIデータセンターを構築する計画が明らかにされた。完成すれば国内最大規模のAIデータセンターになるという。 一方で笠原氏は、ソフトバンクグループ・Oracle・OpenAIなどが進める米国の「Stargate」計画(1拠点あたり1〜1.5GW級)と比較すると、FRONTiaは規模で約10分の1にとどまる点も冷静に指摘しており、手放しの礼賛ではない記事になっている。 日本市場での注目点 Rapidusは次世代半導体の量産を目指す国産ファウンドリだが、量産実績がまだない段階にある。フアン氏が可能性を前向きに評価したと報じられたことは、Rapidusにとって追い風となる材料と言える。 FRONTiaは個人が購入・体験できる製品ではなく国家プロジェクトだが、ここで開発される国産フィジカルAI基盤モデルは、将来的に川崎重工・安川電機・ファナックの産業用ロボットや、トヨタ・ホンダ・日産の車両システムに組み込まれていく可能性がある。日本の製造業がAIをどう取り込んでいくかを占う試金石として、今後の展開を追う価値がある。 筆者の見解 フィジカルAIは、逐一人間の確認を求める「副操縦士」型ではなく、目的さえ伝えれば自律的に動く「自律エージェント」型でこそ本来の価値を発揮する分野だと考えている。工場のロボットや自動運転が、あらゆる場面で人間の承認を待つ設計のままでは、AIを組み込む意味は半減してしまう。日本のメカトロニクス産業がフィジカルAI時代で勝ち残れるかどうかは、この自律性をどこまで実装できるかにかかっている。 FRONTiaの規模がStargateの10分の1にとどまるという指摘は率直に受け止めるべきだが、規模で張り合うことよりも、小さくてもまず実際に動かして経験を積むことの方が今は重要だと思う。情報を追いかけることに時間を使うより、実際に使い倒して成果を出す経験を積む方が、結局は正しい近道になる。 日本の産業界は、フアン氏が指摘する通り、自らの強みに無自覚なまま変革のスピードに乗り遅れるリスクを抱えている。ロボットや自動車という「ハードの強み」を持つ日本だからこそ、AIを大胆に、遠慮なく使い倒す側に回るべきタイミングだと感じる。 出典: この記事は 【笠原一輝のユビキタス情報局】NVIDIAフアンCEO「日本に勝機」、フィジカルAIとRapidusの可能性 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Grok Buildとは何か xAI（現在はSpaceXとの統合で「SpaceXAI」ブランドに移行）が、自社のコーディングエージェント「Grok Build」の中核をなすエージェントループとTUI（ターミナルUI）を、Apache 2.0ライセンスでオープンソース化した。公開されたのは、コードの読み書き・検索、シェルコマンド実行、長時間タスクの管理までを担う一式で、Rustで書かれたコードは84万行超に及ぶ。GitHub（xai-org/grok-build）で誰でも閲覧・ビルドできる。 エージェントの中身は「ハーネス」と呼ばれる仕組みだ。モデルに渡すコンテキストを組み立て、モデルを呼び出し、返答を解析し、ツール呼び出しを実行に落とし込む——このループ自体を公開したことで、Claude CodeやCodex CLI、Gemini CLIといった競合ツールの内部構造を推測する手がかりにもなる。またAgent Client Protocol（ACP）に対応しており、Zedなどこの規格をサポートするエディタへの組み込みも可能。config.tomlの設定でOpenAI Chat Completions・OpenAI Responses・Anthropic Messages各プロトコルのカスタムエンドポイントを指定でき、Ollama等のローカル推論に接続してフルローカルで動かすこともできる。 なぜ「今」なのか このタイミングには裏がある。7月12日、セキュリティ研究者がGrok Buildの通信を解析し、ユーザーの手元のGitリポジトリ全体（追跡ファイルとコミット履歴一式）が、xAI側のクラウドストレージに無断でバンドル送信されていたことを公表した。ユーザーが個別にオフにできるはずの「プライバシートグル」は実質機能していなかったという指摘も出た。批判が広がった直後の7月15日、xAIはこの機能をデフォルト無効化し、過去に収集したデータの削除を発表。そのわずか72時間後にソースコード一式を公開した——という時系列だ。 なお「オープンソース」とはいえ、外部からのコントリビューションは受け付けず、GitHub Issueも無効化されている。コミュニティで育てる形の一般的なOSSとは違い、「監査できる状態で公開する」ことに主眼を置いた措置だと見た方がよい。 実務への影響 日本のエンジニア・IT管理者にとっての教訓は明確だ。エージェント型コーディングツールを導入する際、「どこまでの情報が、どこに、いつ送られるか」を仕様書やプライバシーポリシーの記述だけで信じず、通信内容を実際に確認する運用が必要になる。特にGitリポジトリには顧客コードや機密設計が含まれることが多く、「禁止」で済ませず、ネットワーク監査やローカル実行オプションの有無を評価基準に組み込むべきだ。今回Grok Buildが示したような「モデルとハーネスを分離し、ローカルLLMや他社APIにも接続できる」設計は、社内データを外に出したくない企業にとって参考になる選択肢の一つになる。 筆者の見解 エージェントの中身、つまり「ハーネスループ」を丸ごと読める形で出してきたこと自体は歓迎したい。コンテキスト組み立てからツール呼び出しまでの一連の設計は、まさに今どのAIエージェントを作る人にとっても最前線のテーマであり、実装例が一つ増えることには素直に価値がある。 ただし、今回の「オープンソース化」を額面通りの太っ腹な決断として受け取るのは早計だろう。リポジトリを無断でクラウドに送っていた問題が発覚してから公開まで72時間、しかも外部からの修正提案は受け付けないという運用を見る限り、これは「信頼を取り戻すための見せ方」としての側面が強い。エージェントに何を預けるかを判断するのは結局のところ、開発者一人ひとりが「実際に何が送信されているか」を自分の目で確認する姿勢であって、ベンダーの発表文だけを信じないことに尽きる。 出典: この記事は Grok Build is Now Open Source の内容をもとに、筆者の見解を加えて独自に執筆したものです。

こんな経験ありませんか続きをみる note.com で続きを読む →

セキュリティ企業Sysdigは2026年7月20日、自律的にランサムウェア攻撃の全工程を実行する「エージェント型脅威（Agentic Threat Actor）」であるJadePufferが、AI・機械学習基盤に特化した新型マルウェア「EncForge」を投入し、モデルのチェックポイントやベクトルデータベース、学習データセットを暗号化する攻撃を確認したと報告した。JadePuffer自体は今月すでに、初期侵入からデータ暗号化まで人手を介さず完遂できる脅威として公表されていたが、今回はその攻撃対象がAI/MLインフラそのものに絞り込まれている点が新しい。 Langflowの既知脆弱性を再利用した侵入 今回の攻撃では、攻撃者は以前にも侵入していたLangflowインスタンス（CVE-2025-3248の脆弱性が未修正のまま残っていたもの）に再度アクセスした。侵入後、クラウド認証情報やAPIトークン、到達可能な内部サービスを探索する過程で、root権限を持つ「公開されたDockerソケット」を発見している。 興味深いのは、最初のペイロード配布が失敗した際の挙動だ。SysdigによればJadePufferは、わずか5分間で6本のPythonスクリプトを反復的に開発・投入し、procfs経由でコンテナの名前空間境界を越えてEncForgeをコピーする配布パイプラインを完成させた。人間のオペレーターが介在せず、エラーを見て自分でコードを書き直し、1分足らずで修正案にたどり着いたという。 EncForge：AI/MLスタックだけを狙う暗号化ロジック EncForge（バイナリ名lockd）はGo言語で書かれUPXで圧縮された実行ファイルで、約180種類の拡張子を標的にする。対象にはHugging FaceのSafeTensors、PyTorch/TensorFlowのモデルファイル、GGUF/GGML形式の重み、FAISSのベクトルインデックス、Parquet・Arrow・TFRecord・NumPy・DuckDBといった学習データ形式が含まれる。コマンドラインのヘルプ表示にLoRAアダプタや旧世代のGGMLまで例示されていたことから、Sysdigは「汎用の暗号化ツールではなく、明確にAI環境向けに設計されたランサムウェア」と結論づけている。 暗号化方式はAES-256（CTRモード）による対称鍵暗号と、その鍵をRSA-2048公開鍵で保護するハイブリッド方式。処理速度を優先し、ファイル全体ではなく一部分のみを暗号化する点も特徴だ。暗号化されたファイルには.locked拡張子が付与され、被害者向けの識別子を記載した身代金要求メモが残される。データの外部窃取を示す痕跡は確認されておらず、EncForge自体にも情報窃取機能は見当たらないという。なお、Linux版にはWindowsのシャドウコピー削除やブート復旧無効化といった、本来Windows環境向けの復旧妨害機能がそのまま含まれていた。macOS版の存在もコード内に示唆されているが、実物は未確認とされている。 Sysdigは、モデルの重みや学習データセット、ベクトルインデックスの暗号化は再学習・再チューニングに数週間から数か月を要する可能性があるとし、モデル1件あたりの被害額を規模や用途に応じて7万5000〜50万ドルと試算している。 実務への影響 日本国内でもLangflowのような「ノーコードでAIエージェントを組めるツール」の採用が急速に進んでいるが、今回の事例はそうしたツールが本番運用に近い形でインターネットに露出しやすい構造上の弱点を突かれた形だ。実務担当者が明日から確認すべきポイントは次の3つ。 Langflowを含むAIエージェント基盤のパッチ適用状況を棚卸しする。CVE-2025-3248が修正されたv1.3.0以降へのアップデートは最優先。 Dockerソケットの露出をゼロにする。ホスト側のDockerソケットをコンテナにマウントすると、それだけでroot権限相当のホスト制御を渡すことになる。コンテナはnon-rootユーザーで実行し、ソケットへのアクセスは原則禁止とする。 モデル資産用ディレクトリにファイルシステムレベルのアクセス制御を敷く。チェックポイントやベクトルDB、学習データセットの保存先を、他の業務データと同じ権限モデルで扱わない。 筆者の見解 正直なところ、この事例が一番刺さるのは暗号化ロジックの巧妙さではなく「公開されたDockerソケット＝root権限相当のアクセスがそのまま放置されていた」という部分だ。ゼロトラストの原則からすれば、常時有効な特権アクセスの放置は特権アカウント管理における最大級のリスクであり、今回もそれが侵入の決め手になっている。Just-In-Timeで必要な時だけ権限を発行する仕組みがあれば、Dockerソケットの露出だけでroot権限を奪われる展開は防げたはずだ。 もう一点、今回の攻撃者自身が「人間の判断を介さず自律的に動くエージェント」だったという点も見過ごせない。防御側でもAIエージェントやサービスアカウントといったNon-Human Identities（NHI）の管理が業務効率化のボトルネックを解消する鍵になりつつあるが、その裏返しとして、攻撃者側もNHIとして自律的に動き、人間よりも速く試行錯誤して侵入経路を修正してくる時代に入ったということだ。守る側のNHI管理が甘ければ、攻撃する側のNHIに速度で負ける。AIエージェント基盤を本番導入する組織は、便利さと同じスピードでアクセス権限の設計を見直す必要がある。 出典: この記事は JadePuffer agentic attacks now target AI model data with ransomware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは7月20日（米国時間）、AIアシスタント「Claude」のTeamプランについて契約条件を見直し、最小契約人数を従来の5名から2名へ引き下げたと発表した。PC Watchが7月21日付で報じている。「大きなプロジェクトを持つ小さなチーム」（Anthropic公式Xアカウント@ClaudeDevsの投稿より）でも、Team向けの管理機能を使いやすくする狙いだ。 Teamプラン見直しの中身 契約開始時にアカウントを作成する担当者は、ビジネス用メールアドレスの使用が必須となる。@gmail.comや@yahoo.comのようなパブリックドメインのメールアドレスでは契約できない。一方、組織内のほかのメンバーについては、許可ドメインとして追加登録すれば参加できる仕組みになっている。支払いは月払い・年払いのいずれかを選択可能で、すでに職場のメールアドレスで個人アカウントを使っている場合は、そのままTeamプランへアップグレードすることもできる。 Teamプランには、プロジェクトの共有、管理者による権限コントロール、請求の一元管理、SSO（シングルサインオン）、チームが利用する各種ツールを横断したエンタープライズ検索といった機能が含まれる。従来はこれらの機能を使うために最低5名分のシート契約が必要だったが、今回の変更で2名からでも同じ機能セットにアクセスできるようになった。 なぜこの変更が注目されるのか 生成AIやAIコーディングツールの導入は、全社一括導入だけでなく、部門やプロジェクト単位の小規模チームから始めるケースが急速に増えている。従来の「最低5名」という条件は、概念実証（PoC）段階の小さなチームやスタートアップにとって、地味ながら確実な参入障壁になっていた。管理機能やSSOを使いたくても、実際に使うのは2〜3人という現場は珍しくない。 2名からの契約解禁は、単なる価格改定ではなく、「小さく始めて公式に管理する」という導入パターンを正面から後押しする変更といえる。個人契約の乱立や、無秘密でSaaSアカウントを使い回すようなシャドーIT化を防ぎながら、組織として安全にAIを使い始められる入り口を広げた格好だ。 日本市場での注目点 ClaudeはAnthropic公式サイトから日本国内でも直接契約でき、Team・Enterpriseプランも国内から利用可能だ。今回の変更は料金体系そのものの改定ではなく、契約に必要な人数要件のみが緩和された点に注意したい。最新の正確な料金は、契約前にAnthropic公式サイトで確認する必要がある。 日本国内でも、Microsoft 365 CopilotやGoogle Workspaceの生成AIアドオンなど、チーム単位で契約するAIプランは一定のシート数要件を設けているものが多い。今回の緩和により、日本の中小企業やスタートアップにとっても「まず小さなチームで試してから広げる」という選択肢が一つ増えたことになる。 筆者の見解 組織のAI活用度をどう高めるかという観点で見ると、今回のような契約条件の緩和は地味だが効果の大きい部分にある。導入のハードルが高いままだと、現場は結局、個人のアカウントをこっそり使うといった形に流れがちだ。「使うな」ではなく「公式に使える状態を用意する」ことこそが、AI活用を組織に根付かせる近道になる。 2名から契約できるようになったこと自体を過大評価するつもりはないが、少人数のチームが管理・セキュリティ機能を伴った形でAIを使い始められる仕組みが整ったことは、日本企業がAI活用を検討する際にも参考にしたいポイントだ。まずは小さなチームで公式に試し、成果が見えたら広げる——そうした段階的な導入設計を後押しする動きとして注目しておきたい。 出典: この記事は ClaudeのTeamプラン、最小2名から契約可能に の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米xAIは7月20日（現地時間）、Excel向けAIアドイン「Grok for Excel」を公開した。Microsoft 365マーケットプレイスからワンクリックで導入でき、対話型AI「Grok 4.5」を使って自然言語だけで財務モデルの構築や市場データの分析、チャート・グラフの自動作成が行える。国内では「PC Watch」（劉尭氏）が7月21日付で報じている。 何ができるアドインか Grok for Excelは、シート上でチャット形式の指示を出すだけで、次のような作業をAIが代行するアドインだ。 自然言語の指示から財務モデルを構築する 市場データを分析し、変動の理由を説明する チャート・グラフを自動生成する 欲しい結果を得るための数式を自動記入する 条件を変えたシナリオを再構築する これまでアナリストが手作業で行ってきた「関数を調べる」「範囲を選ぶ」「書式を整える」といった定型作業を、AIとの対話に置き換える設計だ。xAI公式のXアカウント（@grok）も「Grok 4.5を使って財務モデルの構築、市場データの分析、チャートやグラフの生成ができる」と紹介している。 海外の反応・現時点でわかっていること 今回の情報源はxAIの公式発表とX上の告知であり、PC Watchの報道も同発表をベースにしたものだ。第三者メディアによる詳細なハンズオンレビューは本稿執筆時点でまだ出そろっておらず、実際の分析精度や複雑な財務モデルでの安定性については、今後公開される検証記事を待つ必要がある。 注目すべきは配布の形だ。Grok for ExcelはMicrosoft 365マーケットプレイス経由で配布される、いわゆる公式Officeアドインとして提供されている。Office向けアドインの仕組みそのものは以前からサードパーティに開放されており、Copilot以外のAIツールも同じ入り口からExcelに組み込めることを、今回の事例が改めて示した形だ。 日本市場での注目点 現時点でGrok for Excel単体の日本語対応状況や国内での提供時期について、公式なアナウンスは出ていない。Microsoft 365マーケットプレイス経由のアドインである以上、利用には有効なMicrosoft 365サブスクリプションと、xAI側のGrokアカウント（有料プランが必要になる可能性がある）が前提になるとみられる。 競合という観点では、Excelには標準搭載のMicrosoft Copilotをはじめ、表計算ソフトとAIを組み合わせる選択肢がすでに複数存在する。日本のビジネスユーザーにとっては、今のCopilotライセンスの範囲で十分なのか、外部アドインを追加導入する価値があるのかを、実際の業務タスクで比較検討する段階に入ったと言えるだろう。 筆者の見解 表計算ソフトに自然言語でエージェント的なAIを組み込む発想自体は、正しい方向だと考えている。指示を出すたびに確認を求められるのではなく、目的を伝えれば財務モデルの構築までひとまとまりで進めてくれる。これは「人間の確認・承認を挟み続ける設計」から「目的を伝えれば自律的にタスクをこなす設計」への移行そのものであり、AIエージェントの価値が最も出やすい領域のひとつだ。 Microsoft 365のマーケットプレイスを通じて、Copilot以外のAIも公式にExcelへ組み込める仕組みが用意されていること自体は、プラットフォームとして正しい姿勢だと思う。禁止するのではなく、ユーザーが一番便利だと感じるものを選べる状態を作る。これは個々のAIツールの優劣以前に、土台としてもっと評価されていい部分だ。 一方で、Excel標準のCopilotが「外部アドインを検討する価値がある」と思わせてしまっている状況は、正直もったいない。Microsoftほどの開発力とOffice全体のデータ・コンテキストへのアクセスがあれば、外部アドインに頼らなくても同等以上の体験を標準機能だけで提供できるはずだ。応援する立場から言えば、Copilotにはその力を正面から発揮してほしい。 日本の読者にとっての実務的な結論はシンプルだ。今使っているMicrosoft 365環境の中で、Copilotであれ外部アドインであれ、実際に手を動かして自分のタスクで試してみること。AIを使うかどうかで足踏みするより、目の前にある選択肢を実際に使って成果につなげる経験を積む方が、今の時期には確実に価値がある。 関連製品リンク 【自動更新】Microsoft 365 Personal AI機能搭載 1か月版 サブスクリプション Microsoft 365 Family(最新 1年版)|カード版|Win/Mac/iPad|利用可能人数最大6人 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は 「Grok for Excel」無償公開、データ分析やチャート/グラフ作成をAIが代行 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたのか Microsoftは2026年7月、Microsoft 365 Copilotに存在した権限昇格の脆弱性「CVE-2026-41106」を公開した。深刻度はCVSS 9.3と緊急対応レベルの一歩手前まで達する高さで、原因はCopilotが処理するURLリダイレクトの検証不備にあった。悪用されると、未認証の第三者が本来到達できないはずのテナント境界を越え、他組織のCopilotが扱うデータにアクセスできてしまう可能性があった。 Microsoft 365 CopilotはSharePoint、Exchange、Teamsなど組織内のあらゆるデータを横断して要約・検索・生成を行うことが強みだが、裏を返せばそのアクセス範囲の広さがそのままリスクの大きさになる。今回の脆弱性はCopilot自体のクラウド側処理に存在していたため、Microsoftはサーバー側で修正を完了させ、利用者側での追加対応は不要としている。 テナント境界を越えるとはどういうことか M365は、テナントという単位で顧客企業ごとにデータを完全に分離するマルチテナント設計が前提になっている。今回のCVEは、この「壁」をURLリダイレクトの不備を突くことで越えられてしまう構造だった。認証すら不要だったという点が深刻度を押し上げている。パッチはクラウド側で完結しているため実害の有無は公表情報からは分からないが、CVSS 9.3という数字は、Microsoft自身がこの脆弱性を相当に重く見ていたことを示している。 実務への影響 利用者側の追加パッチ作業は不要だが、IT管理者がやるべきことがゼロになったわけではない。 Copilotの権限棚卸し: Copilotがアクセスできるデータ範囲（SharePointサイト、メールボックス、Teamsチャネルなど）を、業務上必要な最小限に絞れているか再確認する 監査ログの確認: Purview監査ログやEntra IDのサインインログで、該当期間に不審なアクセスパターンがなかったかを遡って確認する コネクタの棚卸し: Copilot Studioで作成した独自エージェントやコネクタが、同様のURLリダイレクト依存の設計になっていないか点検する クラウドサービス側の脆弱性は「気づいたときには直っている」ことが多いが、それに安心しきってCopilotの権限設計を放置するのは危険だ。 筆者の見解 Copilotは実質的に、人間の代わりに組織内の広範なデータへ自動的にアクセスする「Non-Human Identity（NHI）」だ。今回の脆弱性が突いたのは、まさにこのNHIが常時どこまでアクセスできる状態になっているかという設計そのものだった。長年ゼロトラストを推進してきた立場から見ると、AIエージェントに対しても「常時アクセス権」ではなく、必要なときだけ必要な範囲にアクセスするJust-In-Timeの発想を徹底すべき局面に来ている。 Microsoftがクラウド側で迅速にパッチを適用し、利用者に追加対応を求めなかった点は率直に評価したい。ただし、Copilotが業務の中心に食い込めば食い込むほど、この種の脆弱性のインパクトは大きくなる。せっかくM365という強力な統合プラットフォームを持っているのだから、Copilotの権限管理やNHIガバナンスの領域でも他社の一歩先を行く姿勢を見せてほしい。応援しているからこそ、ここは正面から取り組んでもらいたいテーマだ。 出典: この記事は CVE-2026-41106 - Microsoft 365 Copilot Elevation of Privilege Vulnerability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

中国Alibaba傘下のAI開発チームは7月19日、パラメータ数2.4兆という超大規模なマルチモーダルAIモデル「Qwen3.8-Max」のプレビュー版を発表した。テキストに加えて画像・動画・文書の理解にも対応し、性能はAnthropicの「Fable 5」に次ぐ水準だと自社は主張している。オープンウェイト版も近日公開予定で、中国のAIスタートアップMoonshot AIが「Kimi K3」をオープンウェイトで公開してからわずか数日というタイミングでの投入となった。 Qwen3.8-Maxとは何か AlibabaのQwen（通義千問）シリーズは、Qwen、Qwen2、Qwen2.5、Qwen3とバージョンを重ねてきた大規模言語モデル群で、オープンウェイトモデルとしてHugging Face等で広く公開され、世界中の開発者やエンタープライズに採用されてきた実績がある。今回発表された「Qwen3.8-Max」はそのフラッグシップにあたる位置づけで、パラメータ数は2.4兆と、これまでのQwenシリーズの中でも突出した規模になる。現時点ではプレビュー版の発表であり、詳細な技術レポートや第三者機関によるベンチマーク検証はこれからという段階だ。 2.4兆パラメータとマルチモーダル対応の中身 2.4兆パラメータという規模は、単一の巨大な密なモデルとして運用するには推論コストが現実的ではない水準だ。近年の兆パラメータ級モデルの多くはMixture-of-Experts(MoE)構成を採用し、1トークンあたりの計算に使う「アクティブパラメータ」を絞ることで推論コストを抑える設計になっている。Qwen3.8-Maxも同様のアプローチを取っている可能性が高い。マルチモーダル対応としてはテキスト・画像・動画・文書理解が挙げられており、OCRや契約書・請求書などの文書処理、動画コンテンツの要約・検索といった実務ユースケースへの応用が見込まれる。 Moonshot AIのKimi K3からわずか数日という投入タイミング 今回特筆すべきは投入のタイミングだ。中国のAIスタートアップMoonshot AIが大規模言語モデル「Kimi K3」をオープンウェイトで公開した直後に、AlibabaがQwen3.8-Maxのプレビューをぶつけてきた形になる。DeepSeekも含め、中国のAI開発陣営はここ数週間、大規模モデルをたたみかけるように発表しており、パラメータ規模・投入速度の両面で競争が過熱している。「Anthropicの Fable 5 に次ぐ性能」というAlibabaの主張は、あくまで自社発表段階のものであり、独立した第三者評価が出そろうまでは参考情報として受け止めるのが妥当だろう。 実務への影響 日本のエンジニアやIT管理者にとっての論点は主に3つある。第一に、2.4兆パラメータ級のモデルを自前でホストするインフラコストは非常に大きく、オープンウェイト版が公開されても、多くの企業にとっては現実的な選択肢はAPI経由での利用になる。第二に、中国発のモデルは中国語・英語を中心にチューニングされることが多く、日本語での実務精度は個別の検証が欠かせない。第三に、海外のAI基盤を業務に組み込む際は、データがどこを経由し、どこに保存されるかというデータ主権・セキュリティ要件の確認を怠らないことが重要だ。ベンダーの自己申告ベンチマークをそのまま鵜呑みにせず、自組織の実際のユースケースで小さく試してから判断する姿勢が、これまで以上に求められる。 筆者の見解 中国発の大規模モデルは、Moonshot AIのKimi K3に続いて今回のQwen3.8-Maxと立て続けに発表されており、パラメータ規模でも投入速度でも競争が明らかに過熱している。ただ、筆者はこの手の新モデル発表を逐一追いかけることにはあまり価値を感じていない。「Anthropicの次点」という自社評価は、第三者検証を経るまでは参考程度に留めておくのが健全な受け止め方だろう。ベンダーの主張の真偽を追いかけるよりも大事なのは、今すでに使えるツールを実際の業務で使い倒し、そこから成果を出す経験を積むことだと考えている。筆者自身は目下、Claude Codeを軸にAIエージェント活用のノウハウを蓄積することに時間を割いており、次々登場する新モデルの一つひとつを深追いする余裕はない。とはいえ、オープンウェイト版が実際に公開されれば、コストやデータ主権の観点から選択肢の一つとして手元で検証する価値はある。中国勢の技術力の高さは侮れず、今後も動向はウォッチしておきたい。 出典: この記事は Alibaba Previews Qwen3.8-Max, a 2.4 Trillion-Parameter Multimodal Model, Days After Moonshot’s Kimi K3 Open-Weight Launch の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ソニー・ミュージック・エンタテインメント（Sony Music Entertainment、SME）は現地時間7月20日、AI音楽生成サービス「Udio」を著作権侵害でニューヨーク連邦地方裁判所に新たに提訴した。対象となる楽曲はエルヴィス・プレスリーの「Hound Dog」からビヨンセの「Say My Name」、ハリー・スタイルズの「As It Was」まで3万曲を超える。 発端は2024年の共同訴訟、開示手続きで対象が急拡大 話は2024年にさかのぼる。SMEはユニバーサル ミュージック グループ（UMG）、ワーナー・レコードとともに、Udioと競合の音楽生成AI「Suno」を著作権侵害で提訴した。この時点での対象楽曲は333曲だった。 その後の開示（ディスカバリー）手続きでUdioの学習データへのアクセスが認められたことで状況が一変する。SMEは「オーディオ・フィンガープリンティング」という技術を用いて、Udioが無断で学習データに取り込んだとみられる楽曲をさらに3万曲以上特定したと主張している。SMEは当初、この3万曲分を既存の訴訟に追加する形で申し立てたが、裁判所はこの拡大申請を却下した。そこでSMEは新たに単独の訴訟を起こす形をとった。 訴状でSMEは、Udio自身が「学習用プログラムに大量の多様な音源を見せることで（モデルを）構築した」と認めており、その音源にはYouTube由来のものも含まれると主張している。SMEは差止命令に加え、侵害1曲あたり最大15万ドルの法定損害賠償を求めている。対象曲の全リストは訴状に添付されており、SMEは今後さらに対象を拡大する可能性があるとしている。 興味深いのは、同じ2024年の共同原告だったUMGとワーナー・ミュージック・グループはすでにUdioと和解し、現在はパートナーとしてAI音楽生成を業界に取り込む方向に舵を切っている点だ。音楽業界全体が「訴訟か協業か」の分岐点に立たされている中で、SMEだけが訴訟継続という強硬路線を選んでいる。 日本のIT現場にとっての意味 この訴訟は音楽業界だけの話に見えるが、実際は生成AI全般が抱える「学習データの出所問題」の縮図だ。テキスト生成AIの世界でも、ニュース出版社や作家団体が大手AI企業を相手取った訴訟が続いており、音楽・画像・コード・文章、あらゆるモダリティで同じ構図の争いが起きている。 日本企業がAI生成コンテンツ（音楽・画像・BGM等）を製品やマーケティング素材に組み込む際は、「そのAIツールの学習データが適法にライセンスされているか」を確認することが今後ますます重要になる。特にUdioのように訴訟が係属中のサービスを商用利用に組み込むと、後から差止命令や損害賠償請求の巻き添えを食うリスクがある。IT管理者は、社内でAI生成ツールを導入する際のガイドラインに「学習データのライセンス状況の確認」を項目として加えておくべきだろう。 筆者の見解 今回の訴訟で象徴的なのは、同じ原告陣営だったUMGとワーナーがすでにUdioと和解し協業に転じている一方、SMEだけが訴訟を続けているという対比だ。これは「AIを禁止するか、安全に使える仕組みを作るか」という選択そのものを体現していると感じる。禁止だけを続けるアプローチは長期的にはうまくいかない。ユーザーやクリエイターにとって「公式に提供された、ライセンスがクリアな仕組みが一番便利」という状態を作れた側が、結局は市場を取ることになる。 UMGとワーナーの動きは、まさにそうした「安全に使える仕組み」への転換だろう。学習データのライセンス問題を解決し、アーティストへの還元の仕組みを組み込んだ上でAI音楽生成を受け入れる——このアプローチのほうが、訴訟を延々と続けるより実利があるはずだ。SMEの今回の提訴も、Udioとの協業合意に向けた交渉材料としての側面を持っているとしても不思議ではない。 日本の音楽・エンタメ業界も、AI生成コンテンツとの向き合い方を「様子見」から「仕組み作り」へ移す時期に来ている。技術を止めることはできない以上、ライセンスと収益還元の設計を先にやった者が主導権を握る。それは生成AIのあらゆる領域に共通する教訓だと思う。 出典: この記事は Here are the 30,000 songs Sony is suing Udio’s AI music generator over の内容をもとに、筆者の見解を加えて独自に執筆したものです。

欧州委員会は2026年7月17日、デジタル市場法（DMA: Digital Markets Act）に基づき、GoogleにAndroidの音声AIアシスタントを競合他社に開放するよう命じた。これまでAndroid端末には自社AI「Gemini」が標準搭載され、他のAIアシスタントへの切り替えが事実上困難だったが、今後はAnthropicやOpenAI、フランスのMistral AIといった競合のチャットボットも、音声起動でスマートフォンを直接操作できるようになる見通しだ。 何が問題視されたのか 欧州委員会が問題視したのは、GeminiのAndroidへのプリインストールが、EU域内の成人の60%を占めるAndroidユーザーにとって、サードパーティ製AIモデルの魅力を実質的に削いでいた点だ。OSレベルで特定のAIアシスタントが有利な立場を占め続けると、ユーザーが本当に使いたいAIを自由に選べなくなる。これはDMAが定める「ゲートキーパー」規制の典型的な対象であり、検索エンジンやブラウザの既定設定を巡る過去の規制と同じ構図といえる。 実際、EUは2010年前後にもWindowsの既定ブラウザ選択画面（ブラウザ・チョイス）を巡って同様の是正措置を求めた前例がある。プラットフォーム標準搭載アプリの独占状態を規制で崩すというアプローチ自体は、EUにとって目新しいものではない。 誰が恩恵を受けるのか 直接の恩恵を受けるのはAnthropicやOpenAIだ。両社のチャットボットは今後、Android端末の音声起動経由でスマートフォンを操作できるようになる可能性がある。もう一つの注目株がフランスのMistral AIだ。同社の共同創業者はEconomist誌の取材に対し、米国が先端AIモデルへのアクセスを制限する中で「欧州は自前のAIエコシステムを持つ必要がある」と述べている。EU域内での主権的AI基盤の育成という文脈からも、今回の命令の意味は大きい。 実務への影響 日本のエンジニアやIT管理者にとっても、この動きは他人事ではない。Googleはグローバルでポリシーを統一する傾向が強く、GDPR同様、DMA対応の仕組みがEU域外にも波及することは珍しくない。Android Enterpriseで社用端末を管理している情シス担当者は、既定AIアシスタントの選択肢がOSレベルで増える可能性を見越し、MDM（モバイルデバイス管理）ポリシーの見直しを今のうちに検討しておく価値がある。 特に重要なのは、音声起動でスマートフォンを直接操作できるAIアシスタントが増えるということは、それだけ端末レベルでの攻撃対象領域（アタックサーフェス）が広がるということだ。管理対象デバイスでどのAIアシスタントの利用を許可するか、単純に禁止で対応するのではなく、安全に使える仕組みとして設計しておくことが、結局は現場の摩擦を減らす近道になる。 筆者の見解 今回の命令の面白さは、単なる独禁法上の是正にとどまらず、「AIアシスタントがOSレベルでスマートフォンを直接操作する」という前提そのものを規制が後押ししている点にある。確認・承認をいちいち人間に求める「副操縦士」型ではなく、目的を伝えれば自律的にタスクをこなす自律エージェント型のAIこそ本質的な価値を生む、というのが筆者の一貫した立場だ。今回の措置でAndroidという巨大なプラットフォーム上に複数のAIエージェントが並び立つ状況が生まれれば、その競争を通じて自律型エージェントの実用化が加速する可能性がある。 一方で、企業のIT管理者からすれば、選択肢が増えることは歓迎すべきだが、無条件に手放しで喜べる話でもない。管理対象デバイスでどのAIエージェントに何を許可するかというガバナンス設計を怠れば、単に管理コストが増えるだけに終わる。「禁止すれば安全」という発想では現場は回らない。安全に使える仕組みを作った上で、ユーザーが自然と使いたくなる選択肢を用意する。これは生成AI活用全般に通じる原則であり、今回のEUの措置はその実践の場を広げる好機と捉えたい。 出典: この記事は EU orders Google to open Android AI system to rivals の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Alphabet（Google親会社）が、自社のGeminiモデルをより効率的に動かすための新型サーバー向けAIチップ「Frozen v2」を開発していることが、The Informationの報道で明らかになった。報道によれば、投入時期は2028年ごろとされ、消費電力あたりのトークン生成数で見た効率は、Googleの既存AIチップと比べて6〜10倍に達する可能性があるという。GoogleはTechCrunchの取材に対し、報道内容を直接肯定も否定もせず、「チームは常に新しい技術革新を研究・実験している」「ハードウェアとソフトウェアを一体で設計することが実世界のワークロードに最適化する鍵」とコメントするにとどめている。 自社チップ開発が業界標準になりつつある Googleは長年、TPU（Tensor Processing Unit）と呼ばれる独自AIチップを開発してきたが、Frozen v2はその後継にあたる存在とみられる。背景にあるのは、AI業界全体で進む「脱Nvidia」の動きだ。OpenAIは6月、初の独自推論チップ「Jalapeño」を発表しており、Anthropicもサムスンとの新たなチップ製造提携を協議していると報じられている。GPUの供給不足とNvidiaへの依存リスクを解消しつつ、AI投資に見合うリターンを示す必要に迫られていることが、各社を自社シリコン開発へと駆り立てている。Googleは今年、AI関連投資に1800億〜1900億ドルを投じる計画を示しており、投資家からは「その巨額投資が本当に回収できるのか」という懸念が根強い。Frozen v2の報道後、Alphabet株は月曜朝に約3%上昇しており、今週予定される決算発表を前に市場の期待をつなぎとめた形だ。 実務への影響 日本のIT現場にとって重要なのは、これが「Googleだけの話」ではないという点だ。Microsoftも独自AIチップ「Maia」やサーバー向けCPU「Cobalt」の開発を進めており、Azure上のAIワークロードのコスト構造は今後、ハイパースケーラー各社の自社シリコン戦略に左右される度合いを強めていく。IT管理者にとっての実務ポイントは、①クラウドベンダーのAIチップ戦略はAPI価格・SLA・リージョン展開に数年単位で影響すること、②特定ベンダー・特定モデルへの依存を前提にせず、コスト効率で乗り換えられる設計を保つこと、③目先の性能比較だけでなく「電力あたりの効率」という指標が今後の調達判断の軸になっていくこと、の3つだ。今すぐ現場の実装が変わるニュースではないが、2〜3年先のクラウドAI予算計画を立てる際の前提情報として押さえておきたい。 筆者の見解 Nvidia一強からの脱却を各社が急ぐのは、極めて筋の通った動きだと見ている。GPU調達の不確実性とコストを考えれば、電力効率を自社チップで作り込むのは「道のド真ん中」の合理的な選択だ。MicrosoftもMaia／Cobaltで同じ方向に進んでおり、応援する立場から見れば、ここは正面から勝負できる領域のはずだ。ハイパースケーラー同士の自社シリコン競争が本格化すれば、最終的にコスト効率という形でユーザー側にも恩恵が及ぶ。1つの指標（トークン単価）だけを追いかけて一喜一憂するのではなく、数年先を見据えたインフラ戦略として各社の動きを淡々と観察していきたい。 出典: この記事は Google is working on a new AI chip designed to make Gemini more efficient の内容をもとに、筆者の見解を加えて独自に執筆したものです。

検証やお客様対応などで複数のMicrosoft Entra ID（旧Azure AD）テナントを行き来している方、毎回 az login していませんか？「またログインか…」続きをみる note.com で続きを読む →