Tech News JP

中国のAIスタートアップ・MiniMaxが2026年3月、新モデル「M2.7」を公開した。コーディング特化ベンチマーク「SWE-Pro」で56.22%というスコアを叩き出し、現時点のトップクラスモデルに匹敵する性能を、はるかに高い推論速度で実現したと発表している。エージェントAIが実用段階に入った今、このリリースはLLM選定の常識を揺さぶる一石となりそうだ。 MiniMax M2.7の概要 MiniMax M2.7は2026年3月18日に公開された最新モデルで、入力コンテキスト窓は204,800トークン、最大出力トークン数は131,072トークンを持つ。テキスト入出力に加え、関数呼び出し（Function Calling）・構造化出力・推論モード（Reasoning Mode）をサポートしており、コーディングエージェントやワークフロー自動化との組み合わせを強く意識した設計になっている点が特徴だ。 また、モデルの重みはHuggingFaceで公開されており、完全なオープンソースアクセスが可能。商用利用や自社インフラへのデプロイを検討している企業にとっては選択肢の一つとなりうる。 Qwen-Plusとのスペック対比 比較対象となるAlibaba（Qwen）の「Qwen-Plus」は約1年前（2025年2月）にリリースされた成熟モデルで、最大100万トークンという巨大なコンテキスト窓を持つ。一方で推論モードは非対応、出力上限も32,800トークンにとどまる。 項目 MiniMax M2.7 Qwen-Plus リリース 2026年3月 2025年2月 コンテキスト窓 204,800トークン 1,000,000トークン 出力上限 131,072トークン 32,768トークン 推論モード ✓ ✗ オープンソース ✓（HuggingFace） ✗（プロプライエタリ） 入力コスト $0.30/100万トークン $0.26/100万トークン 出力コスト $1.20/100万トークン $0.78/100万トークン コスト面ではQwen-Plusの方が若干安価だが、推論モードや長い出力上限を重視するならM2.7に優位性がある。 最大の特徴：「自己進化学習」とは何か 今回のM2.7が最も注目を集めるのは、インタラクションを通じてモデルが継続的に自己改善するという新しい学習アプローチだ。従来の静的な学習済みモデルとは異なり、実際の利用を通じて自律的に精度を上げていくメカニズムを内包している。 この設計思想は、「エージェントが自律的にループで動き続ける」ハーネスループ型AIアーキテクチャとの親和性が高い。単発の指示→応答というサイクルではなく、エージェントが判断・実行・検証を繰り返す長期的なワークフローにおいて、モデルが使われるたびに精度が向上するという特性は、自動化パイプラインを設計するエンジニアにとって魅力的な要素だ。 コーディング性能とエージェント実用性 SWE-Proベンチマーク56.22%というスコアは、現在のコーディングAI評価で最上位に位置するモデルと同等水準とされる。さらに推論速度は同等性能のモデル比で約3倍速いとMiniMax側は主張しており、応答速度がボトルネックになりやすい自動化エージェント用途でのアドバンテージは無視できない。 API経由のアクセスに加えHuggingFaceでのオープン公開により、プライベートクラウドや社内インフラへのデプロイも現実的な選択肢になる。情報セキュリティ上の理由でモデルをクラウドAPIに直接渡せない企業にとっては、選択肢が広がる意味がある。 実務への影響 日本のエンジニアやIT管理者が今すぐ検討すべきポイントは以下のとおりだ。 コーディングエージェントの選定基準を見直す SWE-Proのスコアは「コードのPR自動修正」系タスクを評価するベンチマーク。CI/CDパイプラインへのAI組み込みや、コードレビュー自動化を検討しているチームは、M2.7をベンチマーク候補に加える価値がある。 オープンソース活用でコスト・セキュリティを両立する HuggingFaceで公開されているため、自社GPUインフラやAzure Machine Learningなどのマネージドサービス上でホストすることも可能だ。外部APIへのデータ送信リスクを最小化したい金融・医療・製造系の企業は評価を進めてほしい。 推論モード有無での使い分けを意識する Qwen-Plusの100万トークンコンテキストは長大なドキュメント処理に強みがある。一方M2.7は推論モードと長い出力上限を活かした複雑なタスク処理が得意だ。用途に応じた使い分けが現実的な判断になる。 価格差は小さい、決め手は機能セット M2.7はQwen-Plusより入力で約15%、出力で約54%高い。ただしAPIコストは双方とも「100万トークンで数十円」レベルの超低コストであり、実務では機能セットと精度で選ぶべきだ。 筆者の見解 中国勢のLLMが、コスパと推論速度の両軸で世界最高水準に追いつきつつあるという事実は、もはや「そのうちそうなる」という未来の話ではない。今この瞬間に起きていることだ。 特に「自己進化学習」というアプローチは、エージェントAIの次のフロンティアを示唆している。人間が事前に正解データを用意しなくても、モデルが使われながら賢くなっていく設計は、ハーネスループ型の自律エージェントと組み合わせたときに真価を発揮する。コーディング性能に加えてこの特性があるなら、CI/CDへの組み込み用途での長期評価に十分値する。 一方で、「ベンチマークと実務は別物」という冷静な目も忘れてはならない。SWE-Proのスコアが高くても、実際の社内コードベースや日本語混じりのコメント・仕様書を扱ったときに同等の精度が出るとは限らない。情報を追い続けることよりも、自分の手で動かして「自社のユースケースで使えるか」を確かめることの方が100倍価値がある。 LLM市場は今、スペックだけを見ていても正しい判断はできない時代に突入した。モデルをどう組み合わせ、どんな自律ループの中に組み込むか——その設計力こそが、エンジニアに求められるスキルに変わってきている。 出典: この記事は MiniMax M2.7 vs Qwen-Plus (Comparative Analysis) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AlibabaがQwen 3.6 Plusを発表した。同社のQwenシリーズはオープンモデルとしての性能で注目を集めてきたが、今回のアップデートは単なるスコア向上にとどまらない。「エージェント型LLM」を正面から主張した初めての本格的なモデルとして、AI活用の現場に対する影響が大きい。 100万トークンのネイティブコンテキストが変えること 多くのLLMが「対応している」と謳うコンテキスト長は、実際には精度が著しく落ちる「名目上の数字」であることが多い。Qwen 3.6 Plusが主張するネイティブ100万トークンは、外部RAGや要約処理に頼らずモデル自身がそのウィンドウを扱えることを意味する。 具体的に言えば、数十万行規模のコードベース全体、長大な仕様書、数百件の会話ログをそのままプロンプトに渡せる。エージェントが自律的にタスクをこなす際に「過去の文脈を思い出せない」問題は、エージェント設計上の根本的なボトルネックだった。この制約が実用レベルで緩和されるなら、エージェントの設計思想そのものが変わりうる。 「考えすぎ」問題の改善 前世代のQwenシリーズは「推論ステップを必要以上に重ねて、かえって精度が落ちる・遅くなる」という問題が報告されていた。いわゆるoverthinking（考えすぎ）だ。 Qwen 3.6 Plusではこの挙動を抑制し、タスクの複雑さに応じた思考深度の調整を試みている。これはエージェント的な連続タスクで特に重要で、無駄なステップが積み重なると処理コストと遅延が指数関数的に増大する。自律ループを設計する上で、この改善は地味だが実用上の意味は大きい。 OpenRouterで無料プレビュー中 現在、OpenRouter経由でプレビュー期間中は無料で試せる状態になっている。日本のエンジニアにとっても、実際に触れるハードルが低い。独自のエージェント構成を試したい開発者は、今のうちに評価しておく価値がある。 実務への影響 エージェント設計者へ 長大なコンテキストを前提とした設計が現実的になる。RAG構成の見直しが選択肢に入ってくる 自律ループ（タスクの判断・実行・検証を自分で繰り返す構成）での動作評価を優先的に行いたい overthinking抑制の効果は実際のワークフローで検証が必要。ベンチマーク上の改善が実タスクに出るかは別問題 IT管理者・意思決定者へ 中国発のオープンモデルが実用水準に達しつつある事実は、調達選択肢の幅として把握しておくべき ガバナンス上の要件（データロケーション、利用規約）は各自で確認が必要 オープンモデルはオンプレやプライベートクラウドへのデプロイが可能。閉域環境が求められる用途での候補になりえる 筆者の見解 「エージェント型LLM」という言葉は最近乱用気味だが、Qwen 3.6 Plusが提示した方向性は本質を突いている。 AIエージェントの真価は「人間が何度も確認ボタンを押す副操縦士」ではなく、「目的を伝えれば自律的にタスクをやり遂げる存在」にある。そのためにネイティブな長文脈処理と、無駄な推論ステップを排した効率的な思考は、どちらも欠かせない基盤条件だ。 エージェントが自律ループ——判断・実行・検証を自分で回し続ける仕組み——を安定して動かせるかどうかが、LLMの実用価値を分ける時代になっている。コンテキスト100万トークンとoverthinking抑制という組み合わせは、まさにその方向への投資だ。 Alibabaがオープンウェイトでこの水準を出してきたことは、AIエコシステム全体にとって良い刺激だと思う。競争が活性化し、エージェント設計の可能性が広がるのは歓迎すべきことだ。ただし「エージェント型」を名乗るモデルは今後も続々と登場する。大切なのはベンチマーク数字ではなく、自分たちの実際のワークフローで自律ループが安定して回るかを検証すること。それだけが本当の評価基準になる。 出典: この記事は Qwen3.6-Plus: The First Real “Agentic” LLM? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「ダウンロードして使える本格推論モデル」がついに現れた 米スタートアップのArcee AIが、推論特化オープンモデル「Trinity Large Thinking」をApache 2.0ライセンスで公開した。同社は従業員わずか26人。それでもこのモデルが注目を集めるのは、「非中国製のオープン推論モデルとしては最高水準」と謳う性能と、商用利用・カスタマイズを完全に解放したライセンス体系が組み合わさっているからだ。 疎MoEアーキテクチャとは何か Trinity Large Thinkingが採用する「疎MoE（Sparse Mixture of Experts）」は、モデル全体の規模と実際の計算コストを切り離す設計思想だ。 総パラメータ数：400B（一見すると巨大モデル） 推論時の活性化パラメータ：13B（実際に動くのはここだけ） 通常のDenseモデルは推論のたびに全パラメータを使う。MoEでは「その入力に適したエキスパート」だけを選択的に活性化するため、400Bの「知識の深さ」を持ちながら、13Bクラスの計算コストで動かせる。GPUメモリの制約が厳しい実環境でも展開しやすいのはこの仕組みのおかげだ。 Apache 2.0ライセンスが意味すること ライセンスの観点は見落とされがちだが、企業にとっては性能と同等以上に重要な要素だ。Apache 2.0の主なポイントを整理する。 項目 Apache 2.0での扱い 商用利用 自由 改変・再配布 自由 特許使用許諾 明示的に付与 著作権表示 必要 「モデルを社内データでファインチューニングして独自サービスを作る」「エージェントのバックエンドとして組み込む」——こうした使い方をAPIコストを払わずに実現できる。クローズドAPIへの依存を減らしたい企業にとって、この自由度は極めて大きい。 なぜ「米国製」であることが強調されるのか 昨今のオープンソースLLM市場は中国勢（DeepSeek、Qwen等）の台頭が著しい。コストパフォーマンスでは一定の評価があるが、企業利用においてはサプライチェーンリスク・データガバナンス・輸出規制対応といった観点から採用を躊躇う組織も多い。 Trinity Large Thinkingは「エンタープライズが安心してダウンロード・カスタマイズできる、推論能力の高い米国製モデル」という明確な市場ポジションを狙っている。特にFederal（官公庁）や金融・医療など規制業界での採用余地が広がる。 実務での活用ポイント 1. 推論タスクへの試験導入から始める 「考える」系のタスク——コード生成、複雑な要件定義の分析、多段階の法的・財務ドキュメント処理——はLLMの推論能力に直結する。まずこのカテゴリでベンチマークを取り、既存クラウドAPIとの精度・コストを比較するのが現実的なアプローチだ。 2. ファインチューニングで社内知識を注入する Apache 2.0なので、自社の製品マニュアルや過去のチケット対応履歴を使ったファインチューニングが可能だ。RAGとの組み合わせで社内特化モデルを育てることも現実的な選択肢に入る。 3. エージェント基盤としての位置づけを検討する 13B相当の推論コストで動くとはいえ、それなりのGPUリソースは必要だ。単発の質問応答ではなく、ループで繰り返し推論を回す自律エージェントの中核モデルとして使うと、投資対効果が最大化されやすい。 4. ライセンスと出力物の法務確認は必ず行う Apache 2.0はモデル自体の利用は自由だが、モデルが生成した出力物の著作権処理や業務利用における責任所在は別途確認が必要だ。法務チームへのブリーフィングを忘れずに。 筆者の見解 正直、このリリースには久しぶりに心が動いた。 私が気にしていたのは「性能」だけではない。オープンモデルの世界でここ数ヶ月ずっと気になっていたのは、「強いモデルほどクローズドか中国製か」というジレンマだ。APIコストと引き換えに性能を買うか、コスパのいいオープンモデルを使うが地政学的リスクを抱えるか——この二択に第三の選択肢がなかった。 Trinity Large Thinkingはその空白を埋めようとしている。疎MoEで計算コストを絞りながら推論特化の性能を出す設計は筋が良い。「小さいチームだから大したものではない」と思うのは早計で、むしろAIの世界では26人が400Bモデルを作れる時代になったという事実の方が重要なメッセージだ。 課題があるとすれば実績だ。ベンチマーク上の数字と、実際の業務タスクでの精度が一致するとは限らない。「最強クラス」という主張は第三者検証と実運用での経験が積み重なってから評価すべきだろう。 とはいえ、「ダウンロードして試せる」のがオープンソースの最大の強みだ。まず触れ、判断するのが今の正しいアクションだと思う。情報を追い続けるより、手を動かして自分の業務文脈で評価した知見の方が何倍も価値がある。 出典: この記事は Arcee’s new, open source Trinity-Large-Thinking is the rare, powerful U.S.-made AI model that enterprises can download and customize の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Metaが新しいAIモデル「Muse Spark」を発表した。かつてオープンソース戦略で業界を席巻したMetaが、今度はクローズドな独自モデルという路線転換を試みている。そしてその背景には、1兆円を超える規模の投資と、昨年のLlama 4リリース失敗という苦い経験がある。 Muse Sparkとは何か Muse SparkはMeta Superintelligence Labs（MSL）が開発した新シリーズの最初のモデルだ。コードネームは「Avocado」。Scale AIのCEOだったAlexandr Wangが2025年6月にMetaへ移籍し、MSLを率いる形で9ヶ月かけて開発してきた成果物である。 注目すべきは設計の方向性だ。Meta自身が「small and fast by design」と説明しているように、最高性能を競うモデルではなく、効率と実用性を重視した中型モデルとして位置づけている。対応タスクは健康・科学・数学といった推論が問われる領域で、「競合に匹敵する性能」をうたっている。 また、従来のLlamaシリーズと大きく異なる点として、Muse Sparkはプロプライエタリ（独自ライセンス）での提供となる。将来的にAPIでサードパーティ開発者にも開放する方針を示しているが、「オープンソース化は将来的に検討」という表現にとどまっており、路線の転換は明確だ。 背景：Llama 4の失敗とMetaの焦り 2025年4月のLlama 4リリースは「失望を招いた」と報じられており、開発者コミュニティからの反応も芳しくなかった。その後Zuckerbergは戦略の見直しを表明し、Alexandr Wangを引き込む形で14.3億ドル（約2兆円強）のScale AI投資に踏み切った。 2026年のAIインフラ投資額は1,150〜1,350億ドルと、前年比でほぼ倍増させる計画だ。これはOpenAIやGoogleと互角に戦うためのインフラ確保を急いでいることを示している。グローバルな生成AI市場は年40%以上の成長が見込まれており、ここで遅れをとることはMetaにとって致命的という判断だろう。 実務への影響 日本のエンジニアやIT管理者にとって、今回の発表が即座に業務を変えるわけではない。ただし、いくつかの観点で注目しておく価値はある。 APIアクセスの将来展開を注視する：MetaがAPIでMuse Sparkを提供する場合、コスト競争の観点で選択肢が増える可能性がある。特に中型モデルで高い推論性能が得られるなら、コスト最適化の文脈では検討に値する。 「小さく速いモデル」の流れは本物だ：業界全体でトップティアの超大型モデルだけでなく、効率的な中型モデルへの関心が高まっている。エッジ推論や低コスト運用を考えるなら、このトレンドは押さえておくべきだろう。 オープンソース路線の行方を見守る：LlamaシリーズはオープンソースAIの代名詞的存在だった。Muse Sparkがクローズドである今、Metaが今後どのようなモデルをオープンソースとして提供し続けるかは、コミュニティにとって重要な問題だ。 筆者の見解 正直に言えば、Metaへの期待値はもともとそこまで高くない。Llama 4の件も含めて、「話題にはなるが実務では使いにくい」という印象がMetaモデルにはずっと付きまとっている。 今回のMuse Sparkも、発表の中身を読む限り「競合に匹敵する」という主張の根拠が弱く、ベンチマーク比較も断片的だ。OpenAIやAnthropicと比較したとき、開発者体験・API品質・エコシステムの成熟度でどれだけ差が縮まっているかは、実際に触ってみないとわからない。 とはいえ、14.3億ドルの投資と1,350億ドル規模のインフラ整備をただの見せ金と切り捨てることもできない。Alexandr Wangが率いるチームが「AIスタックをゼロから作り直した」という主張が事実なら、次の世代モデルでどこまで追い上げてくるかは見てみたい気もする。 問題はスピードだ。自律的に動くAIエージェントが実務の中心になりつつある今、モデルの品質だけでなく、それを活かすエコシステム・ツールチェーン・開発者体験の整備がセットで問われる。Metaがこの三つを揃えられるかどうか——そこが本当の勝負だと思っている。 今の段階では「注目はするが、実務採用はもう少し様子を見る」というスタンスが現実的ではないだろうか。 出典: この記事は Meta debuts new AI model, attempting to catch Google, OpenAI after spending billions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windowsのカーネル（OS核心部）には、長年にわたり悪用され続けてきた「抜け穴」が存在していた。2026年4月、Microsoftはついにその穴を塞ぐ重要なセキュリティ変更を展開する。古いドライバー署名方式への信頼を終了し、公式の Windows Hardware Compatibility Program（WHCP）による認定ドライバーのみをデフォルトで許可するというものだ。地味に見えるが、現場への影響は決して小さくない。 問題の背景——「クロス署名プログラム」とは何だったか 2000年代初頭、Microsoftはサードパーティ製ドライバーをWindowsカーネルに組み込む仕組みとして「クロス署名ルートプログラム（Cross-signed Root Program）」を導入した。外部の認証局（CA）がドライバーの署名を行うこの仕組みは長年の標準だったが、致命的な弱点を抱えていた。セキュリティチェックが緩く、署名鍵が盗まれたり悪用されたりするケースが相次いだのだ。 攻撃者はこの仕組みを利用し、正規の署名をまとった悪意あるドライバーをカーネルに読み込ませることができた。カーネルに侵入されれば、セキュリティソフトウェアすら無効化される。EDR（Endpoint Detection and Response）製品をドライバーレベルで無効化する攻撃は、実際にランサムウェアグループが採用してきた手口だ。 Microsoftは2021年にこのプログラム自体を廃止した。しかし廃止後も、既存の古いドライバーはWindowsで引き続き受け入れられていた。今回の変更はその「遺産」に対する最後の決着となる。 新ポリシーの仕組み——「評価モード」から段階的に移行 新しいカーネル信頼ポリシーでは、WHCPを通じてMicrosoftが直接審査・承認したドライバーのみがデフォルトで信頼される。マルウェアチェックや互換性検証を含む審査プロセスを経ることで、サプライチェーン経由でのカーネル汚染リスクが大幅に低下する。 ただし移行は即時ではなく、段階的に行われる。具体的には次のような「評価モード」が設けられている： 評価期間中：カーネルはすべてのドライバー読み込みを監査・記録するが、ブロックはしない 移行条件：累計100時間の稼働かつ3回以上の再起動が完了すること 条件クリア後：旧クロス署名ドライバーが一切検出されなければ、新ポリシーが自動的に有効化される 非互換が検出された場合：評価モードのままリセットされ、移行は先送りされる Microsoftはこの判断に、過去2年間で数十億件のドライバー読み込みから収集したテレメトリデータを活用しているという。現場の実情を踏まえた段階的なアプローチは、現実的で評価できる。 実務への影響——IT管理者が今確認すべきこと この変更がとくに影響するのは、以下のようなシナリオだ： 古い周辺機器・産業機器を使っている環境：特定のプリンターやスキャナー、工場系の制御機器などで古いドライバーが使われている場合、評価モードが延長されるか、最悪の場合デバイスが利用不能になる可能性がある。今のうちにベンダーに問い合わせ、WHCP対応ドライバーへの更新可否を確認しておくべきだ。 エンドポイントセキュリティ製品：EDRやDLP（データ損失防止）製品の一部はカーネルドライバーを利用する。大手ベンダーは対応済みのケースが多いが、バージョンによっては問題が生じることもある。事前に動作確認を行っておきたい。 Intune / Windows Update for Business 管理環境：管理対象のデバイスで評価期間がどのように扱われるか、マイクロソフトの公式ドキュメントを追っておくことを推奨する。特例ポリシーの設定が可能かどうかも確認ポイントだ。 Windows 11 Home と Pro の差異：記事によれば、今回の変更は Windows 11 を対象としている。Windows 10 環境の扱いについては引き続き情報を確認されたい。 筆者の見解 カーネルドライバーのセキュリティ強化という方向性は、間違いなく正しい。特権アクセスを悪用したドライバーベースの攻撃は、EDRをすら無効化できる手口として長く問題視されてきた。「信頼できると証明されたもの以外は許可しない」というゼロトラストの思想をカーネルレベルに持ち込む今回の対応は、セキュリティアーキテクチャとして筋が通っている。 2021年にプログラムを廃止してから約5年、既存ドライバーへの後方互換性を保ちながら段階的に移行するという判断も現実的だ。「今日すぐ全部ブロックする」ではなく、評価モードを通じて互換性の問題を事前に炙り出すアプローチは、現場への影響を最小化しようという配慮が感じられる。 一方で気になるのは、こういった地道なセキュリティ強化がなかなか目立たないことだ。派手な新機能と違い、カーネル信頼ポリシーの変更は語りにくい。しかし実際のセキュリティリスクを下げる観点では、こうした基盤部分の改善こそ本質的な価値がある。Windowsはこのような地道な強化の積み重ねで着実に堅牢になってきた。その事実は、公平に評価されるべきだと思う。 現場の管理者にとっては、「5月に突然デバイスが動かなくなった」という事態を避けることが最優先だ。古いドライバーを使う機器の棚卸しと、ベンダーへの確認を今のうちに済ませておくことを強くすすめる。 出典: この記事は Windows is finally fixing a years-old security hole in April の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Azure AI Foundry（旧称Foundry Classic）で、gpt-realtime-1.5とgpt-audio-1.5が一般提供（GA）に移行した。昨年プレビューとして登場したリアルタイム音声モデルが正式版となり、エンタープライズ用途での利用が現実的な選択肢になってきた。あわせてPreview APIは2026年4月30日に廃止される予定で、既存の実装を持つ開発者は早急な対応が必要だ。 何が新しくなったか 今回GAになったgpt-realtime-1.5とgpt-audio-1.5は、前世代モデルに対して主に3点が強化されている。 インストラクション追従性の向上: プロンプトで指示した挙動を音声応答でも守りやすくなった 多言語サポートの強化: 日本語を含む複数言語での精度・自然さが改善 ツール呼び出し（Function Calling）対応: 音声会話中に外部APIやシステムを呼び出すエージェント的なユースケースが実装しやすくなった これらすべてを維持しながら低レイテンシーも確保しているのがポイントで、「デモでは動くがビジネス要件を満たせない」という従来の課題をかなり解消してきた印象だ。 同時期に強化された音声関連モデル群 GAと合わせて、音声処理パイプライン全体のモデルも大幅に更新されている。 音声認識（ASR）: gpt-4o-mini-transcribe-2025-12-15は英語ベンチマークで前世代比約50%の誤り率削減を達成。無音時のハルシネーション（誤検知）も最大4分の1に削減され、雑音環境での実用性が大きく向上した。日本語・インド系言語などの多言語精度も改善されている点は、日本語ユーザーにとって朗報だ。 話者分離（Diarization）: gpt-4o-transcribe-diarizeは「誰がいつ発言したか」をリアルタイムで識別できる。会議の議事録自動生成やコールセンター通話分析など、日本の企業現場で即座に活用イメージが湧くユースケースだ。 テキスト読み上げ（TTS）: gpt-4o-mini-tts-2025-12-15は多言語合成の新ベンチマークとなっており、より自然でアーティファクトの少ない音声出力を実現している。 SIP接続サポート: Realtime APIが電話システムの標準プロトコルSIPに対応したことで、既存のPBXやコールセンターシステムとの統合が格段にやりやすくなった。 実務への影響——日本のエンジニア・IT管理者に伝えたいこと まず確認: Preview APIの廃止期限 既存環境でRealtime/Audio系のPreview APIを使っている場合、2026年4月30日が移行期限となる。本番で稼働しているシステムがあれば、今すぐ確認・移行計画を立てること。 音声インターフェース開発の現実的な入口として 「音声AIは面白そうだが、まだ実験フェーズ」と思っているなら、GAへの移行はその認識を改めるタイミングだ。特に以下のユースケースは技術的ハードルが現実的な範囲に入ってきた。 社内ヘルプデスクの音声エージェント: FAQへの回答や社内システム検索をFunction Callingと組み合わせて音声で完結させる 会議・商談の自動議事録: 話者分離付き文字起こしで「誰が何を言ったか」まで記録 コールセンターのリアルタイム支援: オペレーターの会話を並行解析してナレッジを即提示 Microsoft Foundryのエコシステム上で構築することで、Entra IDによる認証・認可管理やAzure Monitorでの監視も既存の運用フローに乗せられる。これが単体APIサービスとの最大の違いだ。 API利用の実装ポイント gpt-realtime-1.5は既存のChat Completion APIを通じて利用できる設計になっており、移行コストは比較的低い。既にAzure OpenAI Serviceを使っているプロジェクトなら、エンドポイントの切り替え+モデル名の変更で試せる範囲に入ってきた。 筆者の見解 MicrosoftがAzure AI Foundryを中心にモデル群を整理・強化し続けているのは、単純にモデル単体の競争ではなく「AIが安全に動作するプラットフォームの競争」に軸足を置いているからだと私は見ている。その戦略は長期的には正しいと思う。 音声AIは「楽しいデモ」から「実業務の基盤」へと変わるフェーズにある。Realtime APIがSIPに対応したことは地味に見えるが、これは日本に無数に存在するレガシー電話システムとの接続口が開いたことを意味する。「AIが使えるのは最新システムだけ」ではなく、既存インフラを活かしながら段階的に導入できる設計思想は、日本の大企業・自治体・医療機関のIT部門にとって非常に重要なポイントだ。 一方で、これだけの機能が揃ってきたにもかかわらず、日本の現場での音声AIへの取り組みはまだ周回遅れの印象がある。「うちはまだ早い」と言っているあいだに、競合が顧客接点を音声AIで刷新してしまうリスクは現実のものとして考えておくべきだろう。GAになった今が、実験を業務試行に格上げするちょうどいいタイミングだ。 出典: この記事は GPT Realtime Audio models now generally available in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

クラウドにデータを送れない現場が求めていた答えが、Microsoftの公式ブログから提示された。2026年4月7日、AKS Engineeringチームはエッジおよびオンプレミス環境でのAI推論を網羅した4部構成のチュートリアルシリーズを公開した。製造業、医療、小売、物流といった業種の現場エンジニアにとって、読み飛ばせない内容だ。 なぜいまエッジAI推論なのか AI推論をクラウドで完結させるアプローチは、多くの現場で現実的ではない。工場のセンサーデータ、病院内の医療画像、店舗のリアルタイム在庫分析——これらはデータが「現場に生きている」ユースケースだ。レイテンシの問題はもちろん、個人情報保護や業規制によるデータ主権（Data Residency）の要件が、クラウド転送そのものを禁じているケースも珍しくない。 AKS enabled by Azure Arc は、こうした制約に正面から応える構成だ。Azure のガバナンス・監視・セキュリティ機能を保ちながら、Kubernetes クラスターをオンプレミスや離島・工場のエッジ拠点で動かし続けることができる。ネットワーク断絶時もローカル実行が継続する点は、製造業やインフラ系システムで特に価値が高い。 チュートリアルが扱う内容 今回の4部シリーズでは、オープンソースのツールと実モデルを使ったステップバイステップの実装手順が公開されている。 生成AIワークロード: GPU アクセラレーション推論エンジン（Ollama、vLLM 等）を用いたオープンソース LLM のデプロイ 予測AIワークロード: ResNet-50 などの画像認識モデルを統合モデルサーバー（NVIDIA Triton 等）で提供 多様なハードウェア対応: CPU・GPU・NPU それぞれを対象にした推論ワークロードの構成と検証 既存ハードウェアをそのまま活用できるアーキテクチャになっており、後からGPUや専用アクセラレータを追加してスケールアップする経路も示されている。 日本のIT現場への影響 日本では製造業・医療・流通の大手が、クラウド移行の「できる部分」と「できない部分」の線引きに長年頭を抱えてきた。特に工場フロアや医療機関内ネットワークは、閉域網運用が前提のケースが多い。 Azure Arc を採用済みのオンプレ Kubernetes 環境があれば、AI 推論基盤を追加構成として展開できる。Azure ML や Microsoft Foundry とのモデルライフサイクル連携も視野に入るため、実験フェーズのモデルを本番エッジへデプロイするパイプラインが現実的な射程に入る。 IT 管理者・インフラエンジニアが今すぐ確認すべきポイント: 自社のオンプレ Kubernetes が Azure Arc に接続済みかどうか確認する（未接続なら Arc オンボードから始める） 推論ワークロードの種類（生成AI か予測AI か）とハードウェアリソース（CPU のみ / GPU あり / NPU あり）を整理する 公式チュートリアルはオープンソースモデルで検証できるため、PoC コストをほぼゼロに抑えられる データ主権要件が明確に存在するなら、その制約をアーキテクチャ要件として最初から文書化しておく 筆者の見解 AKS enabled by Azure Arc のこのアプローチは、Microsoftが得意とする「標準技術で現場を統合する」方向性そのものだと思う。KubernetesというデファクトスタンダードをベースにしつつAzureガバナンスを被せるやり方は、特定ベンダーに縛られたくない現場とも折り合いがつく現実解だ。 ...

Microsoft 365 Copilot のアナリティクス機能が、2026年4月下旬から5月下旬にかけて大幅に拡張される。これまで限定的だったアプリ別の利用データが統合され、管理者が組織全体のAI活用状況を一元的に把握できるようになる。ライセンス管理・投資対効果の可視化を求める声が多かっただけに、実務上の意義は小さくない。 何が追加されるのか 今回の更新（ロードマップID: 557981）では、Copilot Dashboard と Copilot Analytics の Advanced Analysis に新しいメトリクスが追加される。具体的には以下の3方向に強化される。 1. 新アプリのカバレッジ追加 これまでトラッキングが薄かった Microsoft Edge と OneNote、そして Microsoft 365 Copilot アプリ（旧 Copilot.microsoft.com）での操作が新たに計測対象となる。EdgeへのCopilot統合は企業での利用が増えているが、その実態がほとんど見えなかった。 2. インテントベースのシナリオ計測 Outlook・Word・Excel・PowerPointでは、単なる「Copilotを開いた回数」ではなく、何をしようとして使ったかという意図別の計測が加わる。具体的には以下が対象： 返信の提案（Suggested replies） 翻訳（Translation） 文章コーチング（Coaching） データクレンジング（Clean data） これにより「Copilotは導入したが、実際に何に使われているか分からない」という管理者の悩みに応える形となる。 3. 展開はテナント自動有効化 設定変更・ポリシー更新は不要で、ライセンス保持ユーザーのいる全テナントに自動展開される。ロールバックも用意されており、フライトコントロール経由で管理できる。 実務への影響 IT管理者・Copilotオーナーの方へ 5月上旬に予定されているオンラインドキュメントの更新を確認し、社内のCopilot利用レポートを作成しているチームに変更を周知しておくこと インテントベースのデータが取れるようになると、「使われているが効果が出ていない機能」の特定が容易になる。ユーザートレーニングの優先順位付けに直接活かせる 翻訳・コーチングの利用頻度が可視化されることで、ROI報告をより具体的な数字で構成できるようになる グローバル展開・多言語環境の企業 翻訳機能のインテント計測は、海外拠点との連携が多い日本企業にとって特に有益なデータになりうる。実際にどれだけ翻訳用途で使われているかが数値化される。 筆者の見解 Copilot Analytics の強化は、管理者として歓迎すべきアップデートだ。特にインテントベースの計測は「何となく使った件数」から「何のために使われたか」へと分析の質が変わる点で意義がある。 ただ、正直に言えば、データが増えることと、そのデータが活用されることは別の話だ。メトリクスが充実しても、それを見て「じゃあトレーニングを改善しよう」「この機能は使われていないから導入方法を見直そう」という次のアクションに繋げられている組織がどれだけあるか。ダッシュボードが増えるほど、かえって「見ている」だけで終わるリスクもある。 M365 Copilotへの投資効果を最大化したいなら、このアナリティクスを「報告用の数字」ではなく「改善のトリガー」として使う文化を組織内に根付かせることが先決だと思う。インテントデータは、ユーザーが実際に何を求めているかを正直に映す鏡でもある。その鏡を見て、次の一手を打てるかどうかが、AI活用の差を生む。 4〜5月にかけて自動展開されるので、展開後にCopilot Dashboardを確認し、新しいメトリクスの意味を理解しておくことをお勧めする。 出典: この記事は MC1266023 - Microsoft 365 Copilot: Comprehensive Copilot metrics in Copilot Analytics の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Adobe Readerにゼロデイ脆弱性が存在し、少なくとも2025年12月から現在に至るまで、実際の攻撃に使われ続けていることが明らかになった。サンドボックス型エクスプロイト検出プラットフォーム「EXPMON」の創設者であるセキュリティ研究者Haifei Li氏が発見し、公表したもので、現時点でAdobe側からのパッチはまだリリースされていない。 何が起きているのか 今回の脆弱性の最も恐ろしい点は、ユーザーがPDFを開く以外の操作を一切必要としないことだ。リンクをクリックする必要も、マクロを有効にする必要もない。ただ、メールに添付されたPDFをいつもどおり開くだけで感染が成立しうる。 この攻撃は「フィンガープリント型エクスプロイト」と呼ばれる高度な手法を採用している。まず被害者の環境情報を収集・識別し、その後に追加の攻撃（リモートコード実行＝RCE、サンドボックス脱出＝SBX）へと展開する多段階の仕組みになっている。情報収集に使われているのはAcrobat内部の特権API（util.readFileIntoStreamおよびRSS.addFeed）であり、本来PDFアプリケーションに用意されている機能が悪用されているのが技術的な肝だ。 ロシア語のおとり文書と標的 脅威インテリジェンスアナリストのGi7w0rm氏が分析したところ、攻撃に使われたPDF文書にはロシア語の内容が含まれており、ロシアの石油・ガス産業に関連する時事的な話題を装っていることが確認されている。これは標的が比較的絞り込まれていることを示唆しており、無差別なばら撒きではなく、特定の組織や業界を狙ったターゲット型攻撃の可能性が高い。 とはいえ、脆弱性の仕組み自体はAdobe Readerの最新バージョンで動作するものであるため、攻撃が転用・拡散される前に対策を取ることが重要だ。 実務での対応ポイント パッチがまだない以上、今すぐ取れる対策は以下の通りだ。 エンドユーザー向け 信頼できない送信元からのPDFは、パッチリリースまで絶対に開かない 特に、業務上覚えのないPDFメールには最大限の警戒を Adobe Readerの自動アップデートを有効にしておき、パッチが出たら即座に適用できる状態にしておく IT管理者・ネットワーク担当者向け HTTPおよびHTTPSトラフィックのUser-Agentヘッダーに "Adobe Synchronizer" という文字列が含まれる通信を監視・ブロックする（Li氏が推奨する緩和策） プロキシやエンドポイント保護製品でこのシグネチャを追加設定することで、通信段階での遮断が可能 EDR（エンドポイント検知・対応）製品のアラートを強化し、Adobe Readerプロセスから不審なネットワーク接続や外部ファイルアクセスが発生していないか監視する ゼロトラスト観点での補足：今回の攻撃はネットワーク境界を突破するものではなく、信頼された内部アプリケーション（Adobe Reader）を踏み台にする手法だ。境界型セキュリティだけでは検知が難しく、アプリケーション層・プロセス層での振る舞い監視が有効性を発揮する場面だ。 筆者の見解 ゼロデイ脆弱性の4ヶ月間放置という事実は、改めてパッチ管理の難しさを突きつける。Adobeの対応スピードについては、公表後の動向を引き続き注視したい。 それ以上に気になるのは構造的な問題だ。「PDFを開く」という日常業務の動作が攻撃面になる以上、ユーザー教育だけでの防御には限界がある。エンドポイント上でのアプリケーション挙動監視と、ネットワーク通信ログの突合による異常検知の組み合わせが、こうした未知の脅威に対して実効性を持つ。 今回の「フィンガープリント型」という手口も興味深い。攻撃者は被害者を識別してから次の段階に進む——つまり、単に悪意あるコードを実行するだけでなく、標的の価値を確認した上で追加投資するかどうかを判断している。高度なAPT（持続的標的型攻撃）に見られる特徴で、無差別ばら撒きとは一線を画す。 パッチが出るまでの間、Haifei Li氏が公開した緩和情報は現時点での最善策だ。「今動いているから大丈夫」ではなく、「まだ動いているが今日はやられるかもしれない」という感覚で臨みたい。 出典: この記事は Hackers exploiting Acrobat Reader zero-day flaw since December の内容をもとに、筆者の見解を加えて独自に執筆したものです。

欧州旅行者に人気の鉄道パスサービス「Eurail」が、2025年12月末に発生した不正アクセスの詳細を明らかにした。被害を受けた個人は308,777人に上り、氏名・パスポート番号・銀行口座IBAN・健康情報・連絡先など、本来なら最も厳重に保護すべき情報が根こそぎ持ち出されたことが確認されている。 何が起きたのか 2025年12月26日、攻撃者がEurailのネットワークに侵入し、ファイルを外部に転送した。Eurailが侵害の事実を公表したのは2026年2月、そして影響を受けた個人への通知が行われたのは3月27日のことだ。発覚から通知まで約3か月を要したことになる。 窃取されたとされる情報の内訳は以下のとおりだ。 氏名・パスポート番号 銀行口座のIBAN（国際銀行口座番号） 健康情報 メールアドレス・電話番号 Eurailは「財務情報やパスポートの写真コピーは侵害されたシステムには保存していなかった」と説明しているが、欧州委員会（European Commission）は別途アラートを発出。EU の「DiscoverEU」プログラム経由でパスを取得した若い旅行者については、健康情報を含む一段広い情報が露出した可能性があると警告している。 窃取されたデータはTelegramで一部サンプルが公開され、ダークウェブ上での売買も試みられていることが確認された。 被害の深刻さはどこにあるか この件で特に問題なのは、「組み合わせの凶悪さ」だ。氏名単体、あるいはメールアドレス単体が漏れた程度であれば、スパムへの警戒程度で済む。だが、氏名＋パスポート番号＋IBANが一組で揃ってしまうと話が変わる。 IBANはEU圏の銀行送金で使う口座識別子であり、不正なダイレクトデビット（口座引落）の試みに悪用されうる。パスポート番号と組み合わせれば、本人確認を伴う詐欺や、フィッシング攻撃の精度向上に使われる可能性が高い。健康情報が加われば、医療保険詐欺への応用も現実的な脅威となる。 実務への影響——エンジニア・IT管理者が取るべき行動 この事案は欧州の事業者が関係しているが、日本のIT現場にも直接的な示唆がある。 ユーザー向け（該当者） Rail Plannerアプリのパスワードを直ちに変更し、同じパスワードを使い回しているサービスでも同様に対処する 銀行口座の明細を定期的に確認し、身に覚えのない引落がないかモニタリングする 件名に「Eurail」「DiscoverEU」「鉄道パス」などを含むメールは、リンクをクリックする前に発信元を厳密に確認する システム設計・運用側の視点 「旅行者の健康情報や旅券情報を同一DBに平文で格納していた」という構造自体が今回の被害を拡大させた。センシティビティに応じたデータ分離と暗号化は、設計段階での必須要件だ DiscoverEUのような政府連携プログラムに個人情報を提供している場合、そのデータが第三者事業者のシステムにどのような形で保管されるかを契約・設計レベルで確認しておく必要がある 侵害検知から被影響者通知まで3か月を要したことは、インシデントレスポンス計画の成熟度を問う事例として参照する価値がある。日本企業でも「発覚したけど何をどの順番でやればいいかわからない」という状態のまま時間が経過するケースは少なくない 筆者の見解 セキュリティの話は細かい議論になりがちで、どちらかというと専門家同士の言い合いになってしまうことも多い。だが、今回のような事案は「技術論」に入る前に、「なぜ不要なデータを持ち続けていたのか」という根本的な問いに立ち戻る必要がある。 IBANや健康情報は、鉄道パスを販売するサービスとして本当に長期保管が必要なデータだったのだろうか。購入処理が完了した後も持ち続ける合理的な理由がなければ、そもそも保持しないというのが最善の防御だ。「攻撃者が盗めないデータは存在しないデータだけ」という原則は、ゼロトラストの文脈でも繰り返し語られてきた基本中の基本である。 日本のエンタープライズでも、気がつけば「いつか使うかもしれない」という理由で個人情報や認証情報がシステムのあちこちに散在しているケースは珍しくない。今回のEurailの事案を、自社のデータ棚卸しを見直す契機として活用することを強くお勧めしたい。 攻撃者が最初のアクセスを得た後、実際にファイルを転送するまでの間に何らかの制御が機能していれば被害は異なっていた可能性がある。ネットワーク層・認証層・認可層を複数重ねた多層防御と、異常なデータ転送を即座に検知するモニタリングの組み合わせ——地味ではあるが、それが「今動いているから大丈夫」という油断に対する唯一の現実的な答えだと思っている。 出典: この記事は Eurail says December data breach impacts 300,000 individuals の内容をもとに、筆者の見解を加えて独自に執筆したものです。

WordPressサイトの運営者・開発者にとって、プラグインのアップデートは「信頼できる行為」のはずだった。その前提が4月7日、根底から崩れた。 スライダー作成プラグイン「Smart Slider 3 Pro」の更新配信システムが第三者に乗っ取られ、バックドアを複数埋め込んだ悪意あるバージョン（3.5.1.35）が正規の更新として配布されたのだ。WordPress向けの無料版だけでも90万以上のサイトで使われているプラグインだけに、影響の広がりは無視できない。 何が起きたのか WordPressおよびJoomlaのセキュリティを専門とするPatchStackの分析によると、問題のバージョンに仕込まれたマルウェアは「完全機能を持つ多層型ツールキット」だという。プラグイン本体の機能は正常に動作したまま、バックドアだけが静かに動き続ける設計になっている点が特に悪質だ。 確認された攻撃機能 1. 認証なしリモートコード実行 HTTPヘッダーを細工するだけで、攻撃者はWordPressにログインすることなくPHPコードやOSコマンドを実行できる。これが最も危険な入口となる。 2. 隠し管理者アカウントの自動生成 wpsvc_というプレフィックスを持つ管理者権限ユーザーがデータベースに作成される。通常の管理画面には表示されない設計になっており、気づきにくい。 3. 多層的な永続化機構 攻撃の巧妙さが際立つのが、この永続化の仕組みだ。 mu-pluginsディレクトリにキャッシュコンポーネントを装ったファイルを設置。「Must-Use Plugin（必須プラグイン）」は管理画面から無効化できず、プラグイン一覧にも表示されない テーマのfunctions.phpに埋め込まれるため、テーマが有効な限り生き続ける wp-includesディレクトリにWordPressコアクラスを偽装したPHPファイルを設置。このバックドアは.cache_keyファイルから認証キーを読み込むため、データベースのパスワードを変えても無効化されない 4. 認証情報の窃取 サイト情報とログイン情報が自動的に外部へ送信される。 影響を受けるバージョンと推奨対応 ベンダーはバージョン3.5.1.35のみが対象と発表。対応は以下の通り。 汚染バージョンを使用していない場合: 3.5.1.36へ更新（または3.5.1.34以前のまま維持） 汚染バージョンを使用していた場合: サイト全体が侵害されたと仮定して行動する 侵害時の対応手順（必須）: 不正ユーザー・ファイル・データベースエントリの削除 WordPressコア・プラグイン・テーマを信頼できるソースから再インストール 全認証情報のローテーション（WordPress管理者・DB・FTP/SSH・ホスティング・メール） WordPressセキュリティキー（ソルト）の再生成 マルウェアスキャンとログレビュー バックアップ復元を行う場合は、タイムゾーンの差異を考慮して4月5日以前のバックアップを使用するようベンダーは推奨している。 実務への影響 IT担当者がすぐ確認すべきこと まず自社・顧客サイトで管理しているWordPress/JoomlaにSmart Slider 3 Proが導入されているか確認する。バージョンが3.5.1.35であれば、即座に侵害対応モードに入る必要がある。 管理しているサイトが多い場合は、WP-CLIで一括確認するのが効率的だ: 出典: この記事は Smart Slider updates hijacked to push malicious WordPress, Joomla versions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セッション盗難という「静かな脅威」に、Googleがハードウェアで応答した Googleは2026年4月、Chrome 146（Windows版）にDevice Bound Session Credentials（DBSC）を正式実装した。狙いはシンプルだ——インフォスティーラーと呼ばれるマルウェアによるセッションクッキーの窃取を、ソフトウェアではなくハードウェアの力で原理的に無効化すること。macOS版は追って対応予定とされており、今後のアップデートで順次展開される。 これはセキュリティ界隈の地味なアップデートに見えるかもしれないが、実際には「パスワードを知らなくてもアカウントに侵入できる」という長年の攻撃手法に対する、構造的な回答である。 なぜセッションクッキーが狙われるのか Webアプリケーションでは、ログイン後にサーバーが発行するセッションクッキーが認証トークンとして機能する。有効期限が来るまでの間、このクッキーさえあればパスワードなしで認証が通る。 問題は、このクッキーがローカルのファイルやメモリに保存される点だ。LummaC2をはじめとするインフォスティーラー型マルウェアは、こうしたデータを組織的に収集してC2サーバーへ送信する手口を洗練させてきた。多要素認証（MFA）を突破しなくても、セッションを「そのまま使い回す」ことで正規ユーザーになりすませてしまう。 Googleが公式見解として「ソフトウェアだけではクッキーの流出を防ぐ信頼できる手段がない」と明言しているのは、この構造的な弱さへの正直な認識である。 DBSCが解決する仕組み DBSCは、セッションをデバイスのセキュリティチップに暗号的にバインドするプロトコルだ。WindowsではTPM（Trusted Platform Module）、macOSではSecure Enclaveが使われる。 仕組みの要点は以下のとおり： セッションごとに固有の公開鍵/秘密鍵ペアをセキュリティチップが生成する 秘密鍵はチップ外にエクスポートできない 新しいセッションクッキーの発行には、Chromeがサーバーに対して「この秘密鍵を保持している」ことを証明する必要がある 秘密鍵を持たない攻撃者がクッキーを盗み出しても、すぐに無効化される 設計上、プライバシーへの配慮もある。セッションごとに異なる鍵を使うことで、複数サービス間での行動追跡に利用されない構造になっている。サーバー側へ送信されるのはセッションごとの公開鍵のみで、デバイス識別情報は含まれない。 このプロトコルはGoogleとMicrosoftが共同開発し、W3Cでオープン標準として策定が進む。Okta等との実証実験では、セッション盗難の件数が顕著に減少したとGoogleは報告している。 日本のエンジニア・IT管理者にとっての実務的意味 管理者が今すぐやるべきこと Chrome 146以降への更新管理を確認する: Intune・GPO等でバージョンポリシーを管理している組織では、DBSC有効化のためにChrome 146以降を対象バージョンに含める必要がある TPMの有効化状態を棚卸しする: DBSCはTPMに依存する。TPMが無効・未搭載のデバイスではこの保護が効かない。特に古い社用PCが混在する環境では要注意だ SaaSのDBSC対応状況を把握する: ウェブアプリ側もバックエンドに登録・リフレッシュ用エンドポイントを追加する必要がある。主要SaaSベンダーの対応ロードマップを確認しておきたい 開発者向けの視点 自社サービスでDBSCを実装する場合、GoogleのDBSC実装ガイドとW3Cの仕様書が公開されている。既存フロントエンドとの互換性を維持しつつ、バックエンドにエンドポイントを追加するだけで対応できる設計になっており、段階的な導入が可能だ。 注意点 DBSCはあくまでセッション盗難後の横展開を防ぐ仕組みであり、マルウェア感染そのものを防ぐものではない。エンドポイント保護（EDR等）との組み合わせが前提となる。「Chromeがアップデートされたから安心」という過信は禁物だ。 筆者の見解 セキュリティの話は正直に言えば得意分野ではないが、このDBSCのアプローチは技術的に筋が通っていると感じる。「ソフトウェアだけではクッキー流出を防げない」というGoogleの認識は、ゼロトラストの文脈で語られてきた「ネットワーク境界では守れない」と同じ構造的な問いへの誠実な回答だ。 TPMやSecure Enclaveといったハードウェアの信頼の根（Root of Trust）を利用してセッションをバインドする発想は、Just-In-Timeアクセスと同じ方向性を持つ。「常時使えるトークンではなく、特定の文脈でのみ有効な証明」という考え方は、特権アカウント管理の理想形に近い。 GoogleとMicrosoftがこのプロトコルを共同で開発し、W3Cで標準化を進めているのも重要な点だ。ベンダー固有の実装ではなくオープン標準として育てることで、SaaSエコシステム全体への普及が現実的になる。 一方で、展開には時間がかかる。TPMが普及していない古いデバイスが残存する環境、DBSCに未対応のSaaS、macOS版の対応待ち——現実の企業環境は「理想の状態」からはほど遠い。この技術が「当たり前の防御層」として機能するには、サーバーサイドの対応が広がるまで数年単位の時間軸で考える必要がある。 その間も、インフォスティーラーの攻撃は止まらない。DBSCを「将来の保険」として認識しつつ、今日できるEDRの強化・TPMの有効化・セッション有効期限の短縮といった対策を地道に積み上げることが、現実的な判断だと思う。 出典: この記事は Google Chrome adds infostealer protection against session cookie theft の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オランダの医療ITソリューション大手ChipSoftが、ランサムウェア攻撃の被害を受けた。同社の電子カルテ（EHR）プラットフォーム「HiX」はオランダ国内の多数の病院で採用されており、患者向けポータルやモバイルアプリを含む主要サービスが緊急停止を余儀なくされた。複数病院で業務への影響が確認されており、医療分野を狙ったサプライチェーン攻撃の典型的な事例として世界中の医療IT関係者に衝撃を与えている。 何が起きたのか ChipSoftは電子カルテシステム「HiX」をオランダ国内の病院に広く提供している。今回の攻撃で同社は「不正アクセスの可能性」を記載した内部メモを医療機関向けに配布し、接続を一時切断するよう呼びかけた。 対応措置として以下のサービスが停止された： Zorgportaal（患者向けポータル） HiX Mobile（モバイルアプリ） Zorgplatform（医療連携プラットフォーム） オランダの医療サイバーセキュリティ対応チーム「Z-CERT」がランサムウェア感染を公式確認し、ChipSoftおよび関係医療機関と連携して影響範囲の特定と復旧支援にあたっている。Sint Jans Gasthuis、Laurentius、VieCuri、Flevo Hospitalなど複数の病院でシステム障害が報告されている。 なぜこれが重要か——医療ITは格好の標的 この種の攻撃が繰り返されるのには明確な理由がある。医療ITベンダーは単なるソフトウェア企業ではなく、複数の医療機関にまたがる情報ハブとして機能している。一点を突破するだけで、契約している全病院の患者データや業務システムへのアクセス経路を得られる可能性があるのだ。 先月も米国のCareCloudで同様のデータ侵害が発生し、3月にはCognizant傘下のTriZetto Provider Solutionsで340万人超の個人情報が流出した。医療IT分野でのサプライチェーン攻撃は、もはや「例外的な事件」ではなく常態化したリスクとして認識すべき段階に入っている。 実務への影響——日本の医療IT担当者が今すぐ確認すべきこと 日本においても、電子カルテや医療情報システムのクラウド化・SaaS化が急速に進んでいる。今回のChipSoft事案から学べる教訓は多い。 ベンダー接続のアクセス制御を見直す ベンダー側システムとの接続は、常時開放しているケースが少なくない。障害発生時に「切断してください」と言われてから対応するのでは遅い。Just-In-Time（JIT）アクセスの概念を取り入れ、必要なときだけ接続を許可する仕組みを構築しておくことが重要だ。 影響範囲を事前に把握しておく ベンダーのシステムが停止したとき、自組織のどの業務が止まるかを事前にマッピングしておく。BCP（事業継続計画）にSaaS・クラウドベンダーの障害シナリオを明示的に含めているか確認したい。 インシデント発生時の通知ルートを整備する ChipSoftは内部メモを医療機関に送付したが、情報到達に時間がかかった病院もあった。契約ベンダーからのインシデント通知を受け取るための連絡経路と、それを受けた際の初動手順を文書化しておこう。 ネットワーク・認証・認可の3層を独立させる ベンダー接続部分だけでも、ネットワーク層（セグメンテーション）、認証層（多要素認証）、認可層（最小権限）の3つを独立して制御できる構成にすることが、被害の横展開を防ぐ上で不可欠だ。 筆者の見解 医療分野でのサイバー攻撃報告が相次いでいる状況を見ていると、問題の本質は「個々の病院のセキュリティ意識」ではなく、SaaS依存のアーキテクチャにおけるリスク設計の甘さにあると感じる。 ベンダーを信頼すること自体は間違いではない。しかし「ベンダーが安全なら自分たちも安全」という前提は、現代の脅威モデルでは通用しない。ゼロトラストの考え方を突き詰めれば、「信頼できるネットワーク」も「信頼できるベンダー接続」も存在しない。すべての接続は疑ってかかり、最小限の権限で、必要な時間だけ許可する——その原則を医療IT分野でも本気で実装する時期が来ている。 日本の大規模医療機関では、レガシーなオンプレミス環境と新しいクラウドサービスが混在する複雑な構成が多い。その状況で「とりあえず動いているから大丈夫」という運用を続けるのは、リスクを積み上げているに等しい。今回のChipSoft事案を対岸の火事と見ずに、ベンダー接続の棚卸しと接続制御の見直しに着手するきっかけにしてほしい。 医療データは人命に直結する。それを預かる責任の重さに見合った防御をするのは、技術の問題である前に、姿勢の問題だと思う。 出典: この記事は Healthcare IT solutions provider ChipSoft hit by ransomware attack の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フロリダ州司法長官ジェームズ・ウスマイアー氏が、OpenAIに対する正式な調査を開始した。公衆安全と国家安全保障上のリスクを理由に挙げており、サブポエナ（強制的な情報開示命令）の発行も予告している。技術的な話題が多い中、今回の件は「生成AIはどこまで許容されるのか」という問いを法執行機関が正面から突きつけた点で、業界全体にとって見過ごせない動きだ。 調査の三本柱：何が問われているのか 今回の調査は、大きく三つの論点から成る。 第一の論点：国家安全保障 司法長官は「OpenAIのデータと技術が中国共産党など米国の敵対勢力の手に渡る恐れがある」と述べた。これはOpenAI固有の問題というよりも、テクノロジー企業全体が直面するデータ主権の問題だ。クラウドサービスやAI APIを介した学習データ・利用データの流れが、安全保障上の脅威になりうるという懸念は、米国に限らず日本でも政府・防衛・インフラ分野で真剣に議論されてきたテーマである。 第二の論点：子どもの安全 ChatGPTが児童性的虐待コンテンツ（CSAM）の生成・流通に関与した可能性と、自傷行為の「奨励」に使われた疑惑が挙げられている。米連邦取引委員会（FTC）も昨年10月、OpenAIを含む複数のテック大手に対し、チャットボットが子どもに与える影響についての情報提供を命じている。 第三の論点：犯罪との関連疑惑 2025年4月にフロリダ州立大学で発生した銃乱射事件の容疑者が、ChatGPTと「常時接続状態」にあったとされ、被害者家族がOpenAIを提訴した件も本調査に絡んでいる。AIがいかなる文脈で「共犯者」と見なされうるのかという極めて難しい問いが、司法の場に持ち込まれた形だ。 IPO直前という絶妙なタイミング OpenAIは今年中にIPO（新規株式公開）を予定している。そのタイミングでの調査開始は偶然ではないだろう。上場企業となれば規制当局の目はさらに厳しくなり、コンプライアンス体制の透明性が問われる。投資家からしても、規制リスクは株価評価に直結する。今後のOpenAIの対応——開示姿勢、安全対策の具体的な内容、法的な反論の論旨——は注目に値する。 日本のIT現場への影響 この調査が日本のエンジニアやIT管理者にとって「他人事」かといえば、まったくそうではない。 企業でのAI利用ポリシー見直しのトリガーになる: 生成AIツールの業務利用を検討・推進している企業は、国家安全保障・データ主権・有害コンテンツ対策の観点からの審査基準を社内で明文化する必要がある。今は「とりあえず使ってみよう」で動いている組織が多いが、規制環境が変われば後追いの整備が急に必要になる。 「禁止」ではなく「安全に使える仕組み」を作れ: 規制強化の流れを受けて「生成AIは禁止」に動く組織も出てくるだろう。しかしそれは根本的な解決にならない。公式に提供されたツールを管理された形で使えるように整備することが、リスクを最小化する現実的なアプローチだ。禁止すれば社員はシャドーITで使う。リスクは見えなくなるだけで消えない。 APIレイヤーでのガバナンスが重要になる: 特に開発者が生成AIのAPIを自社サービスや内部ツールに組み込む場合、データをどこに送っているか・学習に使われているかを把握できていないケースがある。今後は利用規約・データ処理契約（DPA）の確認と、ログ保持・監査対応が標準要件になっていくと考えておくべきだ。 筆者の見解 この種の調査が持つ意味は、OpenAIを叩くことではなく、「AIサービス提供者が果たすべき責任の輪郭を社会が引き直そうとしている」という事実にある。 今はどのAIプロバイダーも、規模が大きくなれば同じ問いに直面する。子どもの安全、データの国外流出リスク、犯罪への間接的な関与——これらはどれも技術で一発解決できる問題ではなく、ポリシー・設計・法的枠組みが組み合わさって初めて対処できる。 筆者が気になるのは「AIを使うな」という方向ではなく、「誰が何の責任を持つのか」の整理が世界的にまだできていないことだ。銃を製造した会社が銃犯罪の責任を負わないのと同様、AIツールの提供者が利用者の行為すべてに責任を負うわけにはいかない。しかし同時に、明らかに危険な使われ方を誘発するような設計や運用を放置していいわけでもない。 この問いに答えを出す作業は、2026年以降のAI業界の最重要課題の一つになる。エンジニアとして「自分には関係ない規制の話」と流すのでなく、自分が作るサービス・組み込む機能がどのようなリスクを内包しているかを設計段階から考える習慣を持つことが、今まさに求められている。AIの力を最大限に引き出しながら、その力が社会に害をもたらさない仕組みを作ること——それはエンジニアリングの問題であり、今の時代の倫理の問題でもある。 出典: この記事は Florida launches investigation into OpenAI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたか OpenAIは2026年4月9日、ChatGPTの新サブスクリプションプランとして月額100ドルの「Pro」ティアを発表した。月額20ドルの「Plus」プランと比べ、コーディング特化ツール「Codex」の利用枠が5倍に拡大されており、「長時間・高負荷なCodexセッションに最適」とOpenAIは説明している。 注意が必要なのは、「Pro」という名前が現在2種類存在するという点だ。今回の100ドルプランは新設された下位の「Pro」であり、従来の200ドルプランも引き続き「Pro」として提供される。200ドル版はさらに高い利用上限を持つ。つまりOpenAIの有料プランは現在、以下のような構成になっている。 プラン 月額 主な用途 Free 0ドル 試用・ライトユース Go 8ドル 軽量な日常使い Plus 20ドル 安定した日常使い Pro（新） 100ドル 重度なCodexセッション Pro（従来） 200ドル 最高利用上限 なぜこのタイミングか 今回の価格帯設定は明らかに意識した競合が存在する。AIコーディングツール市場で急速に存在感を高めているサービスのトップティアが同じく月額100ドル前後で展開されており、OpenAIはその価格帯に直接ぶつける形でプランを追加した。 これはOpenAIにとって珍しい「守り」の動きとも読める。ChatGPTはコンシューマー向けAIチャットボットとして圧倒的な知名度を持ちながら、コーディング用途では後発のポジションに置かれるシーンが増えていた。今回の施策は、ヘビーユーザーが競合へ流れることを食い止めるための「価格の受け皿づくり」として機能するだろう。 Codexとは何か CodexはOpenAIが提供するコーディング特化のAIエンジンで、ChatGPTのインターフェイスから利用できる。コード補完・生成・デバッグなど、エンジニアの日常業務を支援することを主眼に設計されている。GitHub Copilotのバックエンドとして長く採用されていたことで業界内での認知度は高い。 今回の新プランはこのCodexの「使い放題に近い体験」を100ドルという価格で提供することで、エンジニアリング用途のヘビーユーザー層を明確に狙い撃ちしている。 実務への影響——日本のエンジニア・IT管理者にとっての意味 個人エンジニアへの示唆 月額100ドル（約1万5000円）という価格帯は、AIコーディングツールに本気で投資するエンジニアにとってはむしろ「値ごろ感」のある水準になりつつある。複数のサービスを試しながら自分の開発スタイルに合うものを選ぶ時代が来ている。まずは20ドルのPlusプランでCodexを試し、使い切れるほど活用できているなら100ドル版へのアップグレードを検討するのが合理的なアプローチだ。 IT管理者・調達担当者への示唆 法人での採用を検討する際は「月額単価」だけでなく「1人あたり何時間のCodexセッションが発生するか」を見積もることが重要になる。Codexをガンガン使う開発職と、主にチャットで使う非エンジニア職では最適なプランが異なる。部門ごとのユースケースを整理した上で、プランを使い分ける設計が求められる。 またAPIでのアクセスが必要な用途（社内ツールへの組み込みなど）は、サブスクリプションプランとは別にAPIクレジットの契約が必要な点も変わらず注意が必要だ。 筆者の見解 OpenAIが100ドルという価格帯に正面から参入してきたことは、AIコーディングツール市場が「試用フェーズ」を終えて「本格活用フェーズ」へ移行しつつあることの証左だと思う。 市場全体として見れば、この競争激化はエンジニアにとって歓迎すべき動きだ。各社が利用上限を増やしながら価格を据え置く方向で競争してくれれば、現場での活用が進みやすくなる。 ただ、個人的に気になるのは「プラン名の混乱」だ。「Pro」が2種類存在するというのは、ユーザーにとって分かりにくい。20ドルと200ドルの間を埋めることは戦略的に正しいとしても、命名を整理しなければ「自分がどのプランを契約しているのか分からない」という問い合わせが増えるだけだ。OpenAIほどの規模の会社であれば、ユーザー体験の細部にもっと丁寧でいられるはずだし、だからこそもったいないと感じる。 AIコーディングツールの本質的な価値は、エンジニアの認知負荷を下げ、より本質的な設計・判断に集中させることにある。価格競争はその入り口に過ぎない。各社がツールの質・自律性・エコシステムの充実で競い合う段階が、次のフェーズとして到来するだろう。日本のエンジニアには、価格だけで選ぶのではなく「自分の開発スタイルが実際に変わるか」を基準に評価することをお勧めしたい。 出典: この記事は ChatGPT has a new $100 per month Pro subscription の内容をもとに、筆者の見解を加えて独自に執筆したものです。

誰でもアプリを作れる時代が、数字で証明された Apple App Storeへの新規アプリ登録数が前年比84%増という急成長を記録した。この数字の背景にあるのは、AIコーディングツールの急速な普及だ。かつては「プログラミングができなければ無理」だったアプリ開発が、いま大きな転換点を迎えている。 何が起きているのか AIコーディングツールの進化により、コードを書いた経験がほとんどない人でも、アイデアを形にしてアプリとしてリリースできるようになった。「コードを書く」という行為から「何を作りたいかを伝える」という行為へのシフトが、開発の民主化を加速させている。 従来のアプリ開発には、Swift/Kotlinなどの言語習得、Xcodeなどの開発環境の理解、UIデザインの知識、App Storeの審査対応など、多岐にわたるスキルが必要だった。AIツールはこれらのハードルを一気に引き下げた。 重要なのは、84%という数字が単なる「ツール利用者の増加」ではないという点だ。実際にApp Storeの審査を通過してリリースされたアプリが増えているということは、AIが生成するコードの品質が実用レベルに達しつつあることを示している。 アプリ開発の「量的変化」が「質的変化」へ アプリ数の急増は、開発者コミュニティにいくつかの重要な変化をもたらす。 開発者の多様化：これまでアプリ開発者といえば専業エンジニアが中心だったが、今後はドメイン専門家（医療従事者、教育者、業務改善担当者など）が直接アプリを作るケースが増える。特定業界の深い知識とAIツールを組み合わせれば、汎用エンジニアよりも優れたアプリが生まれる可能性がある。 プロトタイピングの高速化：アイデア検証のコストが極限まで下がる。「作ってみて、使ってみて、改善する」サイクルが圧倒的に速くなるため、市場テストの性質そのものが変わる。 ストアの競争激化：App Store上での競争は、かつては「作れる人が少ない」という自然な参入障壁があった。その障壁が低下することで、差別化の軸がコードの質から体験設計やマーケティングに移行する。 日本のIT現場への影響 日本では「エンジニア不足」が長年の課題として議論されてきた。しかしこの数字が示すのは、問題の構造が変わりつつあるということだ。 エンジニアの絶対数が不足しているのではなく、「従来の開発手法に熟練したエンジニア」が不足しているに過ぎない可能性がある。AIツールを前提に組織設計を見直せば、少数の設計・アーキテクチャを担えるエンジニアと、AIを活用して実装を進める多様な人材の組み合わせで、以前よりはるかに多くのアウトプットを出せる体制が構築できる。 一方で、「誰でも作れる」ことへの安易な楽観は禁物だ。AIが生成したコードのセキュリティレビュー、アーキテクチャ設計の妥当性検証、パフォーマンスの最適化——これらは依然として専門的な知見が不可欠だ。増加するアプリの品質担保をどうするかは、次の課題として浮上するだろう。 IT管理者・情報システム部門の視点からは、社員が業務改善のためにAIツールでアプリを作り始めるシナリオへの備えが必要になる。「禁止」ではなく、セキュリティガイドラインを整備した上で安全に活用できる仕組みを先手で作ることが、この局面での正しい対応だ。 筆者の見解 84%増という数字は、私には驚きよりも「ついに来た」という感覚で響いた。AIコーディングツールが実用レベルを超えたことは、日々の実務で身をもって感じていたが、App Storeという巨大なプラットフォームの統計として出てきたことで、それが個人の感覚ではなく産業全体のトレンドだと確認できた。 この変化が日本のIT業界に突きつけるのは厳しい問いだ。「エンジニアが足りない」と言い続けてきた組織は、本当に足りなかったのはエンジニアの頭数ではなく、AIを前提にした開発プロセスの設計だったと気づく必要がある。新卒エンジニアを一括採用して数年かけて育成するモデルが、この変化のスピードに追いつけるとは到底思えない。 同時に、「AIがあれば何でもできる」という誤解も危険だ。アプリの数が増えることと、社会に価値をもたらすアプリが増えることはイコールではない。品質の低いアプリが大量に溢れる「AI汚染」のリスクも現実にある。 重要なのは、AIツールを活用して「設計・検証・改善の速度を上げる」こと。生成されたコードをそのまま信頼するのではなく、人間の判断を高速に挟み込むループを設計することが、今この時期の実践的な正解だと考えている。開発の民主化が進む分、「何を作るべきか」「なぜそれが必要か」を問い続ける人間の役割は、むしろ重くなっていく。 出典: この記事は App Store sees 84% surge in new apps as AI coding tools take off の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコーディングツールにプラグインを追加する際、私たちはどこまで信頼を預けているのか。Vercelが提供するAIコーディングツール向けプラグインが、Vercelと無関係なプロジェクトでもすべてのプロンプトを読み取ろうとしていた——そんな事例が開発者コミュニティで波紋を呼んでいる。プラグインエコシステムのプライバシーガバナンスを問い直す、重要な事例だ。 Vercelプラグインは何をしているのか あるエンジニアが気づいたのは、Vercelと一切関係のないプロジェクトで作業中に表示された一文だった。 「Vercelプラグインは匿名の使用状況データを収集します。プロンプトテキストも共有しますか？」 vercel.jsonもnext.configもVercel依存も存在しないプロジェクトで、なぜこの質問が出るのか。ソースコードを深堀りした結果、いくつかの深刻な問題が浮かび上がった。 問題1：「同意画面」の正体はプロンプトインジェクション この同意確認は、CLIの標準ダイアログでもネイティブなUI要素でもない。プラグインがAIのシステムコンテキストに自然言語の指示を直接注入し、AIがその指示を読んでユーザーへ質問を表示する——という仕組みだ。 ユーザーが「はい」と答えると、AIがecho 'enabled'をシェルで実行してファイルシステムに設定を書き込む。第三者プラグインの指示でAIがシェルコマンドを実行しているにもかかわらず、見た目はツール本体のネイティブな動作と完全に区別がつかない。 GitHubのIssueでこの問題が指摘されると、Vercel側は「マーケットプレイス上では一回限りのCLIプロンプトを作れない制約がある。より良い解決策を模索したい」と回答した。制約の存在は理解できる。しかし、「適切な同意が実装できないから代わりにプロンプトインジェクションを使う」という判断は問題だ。制約の中でも「この質問はVercelプラグインからです」という一文を加える、設定ファイルの書き込みをJavaScriptから直接行うといった対応は十分に可能だったはずだ。 問題2：「匿名データ」の中身 同意画面には「スキルインジェクションパターンやデフォルトで使われるツール等の匿名使用データ」とある。しかし実際に収集されているのは次の通りだ： 収集内容 タイミング 同意の有無 デバイスID・OS・フレームワーク情報 セッション開始時 なし（常時） フルのbashコマンド文字列 bashコマンド実行後 なし（常時） プロンプトテキスト 毎プロンプト オプトイン制 中段が特に看過できない。ファイルパス、プロジェクト名、環境変数名、インフラ構成の詳細——bashコマンドに含まれるあらゆる情報がtelemetry.vercel.comに送信される。同意を求めることなく、常時だ。 さらにこのプラグインはVercel関連プロジェクトかどうかを判定するフレームワーク検出機能を内部に持ちながら、テレメトリの対象絞り込みには使っていない。Vercelと無関係なすべてのプロジェクトでデータが収集される設計になっている。 実務への影響：今すぐ確認すべきポイント 日本のエンジニア・IT管理者が取るべき行動は以下の通りだ。 AIコーディングツールのプラグイン一覧を棚卸しする — 自分が導入したプラグインが何を収集しているか、ソースコードまたは公式ドキュメントで確認する 企業環境での利用ポリシーを見直す — 社内システムやコードベースへアクセスがある環境でAIツールを使っている場合、プラグインのテレメトリ設定もレビュー対象に含める 「匿名データ」の文言を鵜呑みにしない — 「匿名」は「無害」を意味しない。bashコマンドのフル文字列はプロジェクト構成やインフラの詳細を含む プラグインのパーミッションモデルを理解する — AIエージェントツールのプラグインは、コンテキスト注入だけでなくシェルコマンド実行権限を持つ場合がある。インストール前にその範囲を把握しておく 筆者の見解 AIコーディングツールのプラグインエコシステムは、急速な普及の陰でガバナンスが追いついていない。今回の事例はその課題を象徴している。 問題の本質は2つある。一つは「適切な同意が実装できないならその機能は出すべきではない」という判断ができなかったこと。もう一つはプラグインのスコープ逸脱だ。Vercelプラグインの本来の役割はデプロイ支援とフレームワークガイダンスのはず。非Vercelプロジェクトのプロンプトまで収集する必要性について、合理的な説明は難しい。 AIエージェントの本来の価値は、目的を伝えれば自律的にタスクを遂行し、人間の認知負荷を削減することにある。そのためにはユーザーとの信頼関係が土台だ。気づかないうちにデータを収集する設計は、ツールへの信頼を損ない、エコシステム全体の価値を毀損する。 プラグインを提供するベンダー各社には、「ユーザーが安心して使える仕組みを作る」という原則に立ち返ってほしい。AIツールが日常的な開発インフラになりつつある今、プラグインのプライバシー設計は業界全体が真剣に取り組むべきテーマだ。 出典: この記事は The Vercel plugin on Claude Code wants to read your prompts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

コードだけ読んでも「浅い仮説」しか生まれない AIコーディングエージェントの活用が進む中、ひとつの本質的な問いが浮かび上がっている。「エージェントにコードを読ませるだけで、本当に深い最適化ができるのか？」 SkyPilotチームが公開した実験レポートは、この問いに対して明確な答えを突きつける。コードだけを読んで実験を繰り返すエージェントは、知識の天井に早々に当たる。しかし論文・競合フォーク・他バックエンドの実装を先に調査させる「リサーチフェーズ」を加えると、コード単独では絶対に気づけなかった最適化を発見できる。 実証対象はCPU向けLLM推論ライブラリとして広く使われるllama.cpp。そこにAIエージェントのループ実行フレームワーク「pi-autoresearch」を組み合わせ、4台のクラウドVMで約3時間動かした結果、5つの最適化を実装しx86環境でのテキスト生成速度を**+15%（ARM環境で+5%）向上させた。総コストはわずか約4,300円**（API代＋VM代）。 リサーチフェーズで何が変わったか コードのみのアプローチの限界 リサーチなしの初期フェーズで、エージェントはllama.cpp内のAVX2プリフェッチや量子化ドット積のループアンロールといった「目に見える部分」を最適化しようとした。効果は+0.8%程度。コードを読めばわかる範囲の改善しか生み出せなかった。 研究論文・競合実装を読ませたことで得た洞察 リサーチフェーズを追加したエージェントは以下を調査した： arxivの関連論文（カーネルフュージョン、メモリアクセスパターン） ik_llama.cpp（人気の競合フォーク） llama.cppのCUDA/Metalバックエンド実装 結果として得たキーインサイトは「このワークロードはコンピュート律速ではなくメモリ律速」という認識の転換だった。これにより最適化の方向が変わり、5つの具体的な改善が着地した。 着地した5つの最適化 Softmaxフュージョン — 複数パスをAVX2 FMAループに統合 RMS Normフュージョン — 正規化計算の多重パスを削減 from_floatの適応的並列化 — データサイズに応じた動的なスレッド割り当て グラフレベルのRMS_NORM + MULフュージョン — 演算グラフ全体の最適化 Flash AttentionのKQフュージョン — QKタイルに対する3パスを1つのAVX2 FMAループに統合（最大の成果） 研究フォーク（ik_llama.cpp）とCUDAバックエンドが直接ヒントを与えた最適化は、実に5件中2件に上る。「他人がすでに解いた問題」を参照させることの威力が鮮明に出ている。 実務への影響 エージェント設計の発想を変える 日本のエンジニアがAIエージェントを設計する際、多くの場合は「タスクを渡せば動く」という前提で組む。しかしこの実験が示すのは、タスク前の情報収集フェーズの設計こそが成果を左右するという事実だ。 実装上の示唆を整理すると： ベンチマークとテストスイートを必ず用意する — エージェントが仮説を検証するには測定基盤が不可欠 競合実装・フォークをコンテキストに含める — 論文より先に「すでに動いているコード」が役に立つことが多い コンピュート律速かメモリ律速かを先に分析させる — 最適化戦略の前提が変わる コスト感覚の更新を 「エージェントに3時間動かして4,300円」というコスト感は、従来のエンジニアリング工数感覚と比べると破格だ。シニアエンジニアが数日かけて探索するような最適化空間を、低コストで自動探索できる時代に入りつつある。この感覚を持っておくことは、今後のプロジェクト見積もりや技術選定においても重要になる。 筆者の見解 この実験が面白いのは、最適化の成果そのものよりも「エージェントに何を読ませるかの設計が結果を決定する」という知見にある。 これはAIエージェント活用の本質に関わる問いだ。コードを渡してループを回せば自動的に賢くなる、という幻想を捨てて、エージェントが思考する前の「インプット設計」に人間の知恵を使う——これが次のフェーズのエージェント活用だと思う。 AIエージェントが自律的にループで動き、仮説→実験→検証を繰り返す仕組みは、今まさに実用段階に入っている。pi-autoresearchのフレームワークはGitHubで公開されており、「ベンチマークとテストスイートがあれば任意のプロジェクトに適用できる」とされている。まずは自分の手元にある小さなプロジェクトで試してみる価値は十分にある。 「30件以上の実験を走らせて5件が着地」というエラーレートを、失敗と見るか成功と見るかも重要な視点だ。人間のエンジニアが5件の最適化を3時間・4,300円で見つけられるかと考えれば、答えは明らかだろう。完璧なエージェントを待つより、今すぐ動かして学ぶ方が圧倒的に速い。 出典: この記事は Research-Driven Agents: When an agent reads before it codes の内容をもとに、筆者の見解を加えて独自に執筆したものです。

経営幹部を狙うフィッシング攻撃は年々高度化しているが、2025年末から活動が確認されている「VENOM」は、従来の防御策の前提を根底から崩す仕組みを持つ。MFAを設定しているから安心——そう思っている企業のセキュリティ担当者に、今すぐ読んでほしい話だ。 VENOMとは何か：クローズドな攻撃基盤という厄介な特徴 VENOMはPhaaS（Phishing-as-a-Service）基盤、すなわち「フィッシング攻撃を外注できるサービス」として設計されている。ただし、よくある地下フォーラムでの公開販売は行っておらず、クローズドアクセスで運用されている点が研究者にとって厄介だ。アンダーグラウンドコミュニティへの露出が少ないため、通常の脅威インテリジェンスで捕捉しにくく、発覚が遅れやすい。 攻撃対象はCEO・CFO・VP等のC-Suiteに限定されている。ランダムなばらまきではなく、特定個人をピンポイントで狙う「スピアフィッシング」に分類される。 攻撃チェーンの解剖：3つの巧妙な回避技術 1. UnicodeレンダリングのQRコード 攻撃メールはMicrosoft SharePointの共有通知を装い、高度にパーソナライズされている。QRコードをUnicode文字で描画することでスキャンツールによる検出を回避しつつ、攻撃をPCからモバイルデバイスへ移行させる。モバイルのブラウザはデスクトップに比べてURLバーの視認性が低く、フィッシングページを見分けにくいという特性を悪用している。 2. URLフラグメントへのターゲット情報隠蔽 ターゲットのメールアドレスはURLの#以降（フラグメント部分）にダブルBase64エンコードで格納されている。HTTPリクエストではフラグメントはサーバーに送信されない仕様のため、サーバーサイドのログやURL評価フィードには残らない。ログベースのセキュリティ監視を静かに回避する設計だ。 3. AiTM（Adversary-in-the-Middle）によるMFA突破 本攻撃の核心がここにある。フィッシングページはMicrosoftのログインフローをリアルタイムでプロキシし、入力された認証情報とMFAコードを即座にMicrosoft APIへ中継する。その結果、攻撃者はセッショントークンを取得する。MFAは「パスワード＋ワンタイムコード」を保護するが、このトークンはログイン完了後に発行されるため、MFAを通過した後の「正規のセッション」を横取りできる。 また、デバイスコードフィッシング手法も確認されている。被害者を騙して不正デバイスへのアクセス承認をさせることで、パスワードリセット後も有効なトークンを入手する。この手法は過去1年で37倍に増加しており、VENOMもそのトレンドを取り込んでいる。 実務への影響：「MFAで十分」という時代の終わり VENOMが示すのは、TOTP・SMS・認証アプリといった従来型MFAだけでは、AiTMフィッシングに対して防御不十分という現実だ。実務担当者が今すぐ検討すべき対策を以下に整理する。 ① FIDO2認証への移行 FIDO2（パスキー・YubiKey等）はフィッシングに対してフィジカルに耐性を持つ。デバイスとドメインが紐づく仕組みのため、偽サイトでは認証が成立しない。経営幹部・特権アカウントから優先的に移行を進めることを強く推奨する。 ② デバイスコードフローの無効化 利用していない場合は、Microsoft Entra ID（旧Azure AD）の条件付きアクセスポリシーでデバイスコードフローを無効化する。設定は 条件付きアクセス → 認証フロー → デバイスコードフロー から制御可能だ。 ③ 条件付きアクセスによるトークン悪用防止 トークン発行後の横展開を防ぐには、継続的アクセス評価（Continuous Access Evaluation）やサインイン頻度ポリシーの強化が有効だ。また、準拠済みデバイスからのアクセスのみを許可するデバイスコンプライアンスポリシーも合わせて設定したい。 ④ 経営幹部を対象としたセキュリティ意識トレーニング VENOMはC-Suiteを意図的に狙っている。高度にパーソナライズされたメールを経営幹部が見分けるのは難しいが、「QRコードを使ったMicrosoft認証要求には特別な注意を払う」という啓発は最低限実施しておきたい。 筆者の見解 ゼロトラストの文脈で言えば、「認証済みだから信頼する」という発想がそもそも危うい。VENOMのようなAiTM攻撃は、認証プロセス自体を通過してしまうため、認証後のセッションをいかに継続監視するかが問われる。継続的なアクセス評価と最小権限の徹底、そしてJust-In-Time（JIT）アクセス制御こそが、この種の攻撃に対する根本的な答えだ。 Microsoftのアイデンティティ基盤は、条件付きアクセスの柔軟性やFIDO2サポートなど、対策を打てる素材は揃っている。組織側が「MFAを入れたから終わり」と思考停止するのではなく、その先の一手を打つかどうかが分かれ目になる。デバイスコードフローの無効化などは設定1つでできる話なので、後回しにする理由はない。 クローズドな基盤で活動するVENOMは今後も静かに範囲を広げる可能性がある。「今のところ被害報告がない」で安心している組織ほど、気づかないまま標的にされているリスクを再確認してほしい。 出典: この記事は New VENOM phishing attacks steal senior executives’ Microsoft logins の内容をもとに、筆者の見解を加えて独自に執筆したものです。

台湾のNGO（非政府組織）や大学を標的にした、これまでにない設計思想を持つマルウェアが確認された。Cisco Talosが解析した「LucidRook」は、Lua言語のインタープリタを本体に内蔵するという構造上の工夫によって、高い隠蔽性と柔軟な攻撃能力を両立している。単なる情報窃取ツールにとどまらない、成熟した脅威アクターによる組織的な標的型攻撃（APT）として注目に値する。 LucidRookとはどんなマルウェアか LucidRookの最大の特徴は、Luaインタープリタを丸ごと内蔵したモジュラー設計にある。通常のマルウェアはバイナリ本体に機能を実装するが、LucidRookはLuaバイトコード形式で「第2ステージのペイロード」をC2（コマンド＆コントロール）サーバーから取得・実行する。これにより、攻撃者はコアのDLLを変更することなく、攻撃内容をターゲットごとに柔軟に差し替えられる。 また、LuaバイトコードはC2への配信後すぐに削除できるため、インシデントレスポンス時に「ローダーは入手できたがペイロードが回収できない」という状況を意図的に作り出せる。フォレンジック妨害を設計段階から組み込んでいる点が、このマルウェアを「成熟した脅威アクター」たらしめている。 感染チェーンの2パターン Cisco Talosは2025年10月の攻撃において、2系統の感染経路を確認している。 ① LNKファイル経由 パスワード付きアーカイブを添付したフィッシングメールから始まり、LNKショートカットファイルがドロッパー「LucidPawn」を展開。LucidPawnは正規のMicrosoft Edgeに見せかけた実行ファイルと悪意あるDLL（DismCore.dll）を配置し、DLLサイドローディングの手法でLucidRookを起動する。台湾政府からの文書を模した「おとりドキュメント」を同時表示することで、ユーザーの注意をそらす。 ② 偽セキュリティソフト経由 Trend Micro Worry-Free Business Security Servicesを偽装したEXEファイルを入口とするルート。セキュリティ製品そのものを騙ることで、ユーザーの警戒心を意図的に下げる設計だ。 偵察とデータ窃取の手口 感染後、LucidRookはユーザー名・コンピュータ名・インストール済みアプリ・実行中プロセスといったシステム情報を収集する。収集データはRSAで暗号化されパスワード付きアーカイブに格納されたうえで、FTP経由で攻撃者インフラへ送出される。 関連ツール「LucidKnight」も確認されており、こちらはGmailのGMTPプロトコルを悪用してデータを外部送信する。正規サービスをC2の代替として使う戦術は、ファイアウォールやプロキシによる検知を困難にする。 なぜこれが重要か 台湾のNGOや大学が標的となっているが、日本のIT現場にとっても対岸の火事ではない。 第一に、攻撃グループUAT-10362の「成熟した作戦能力（mature operational tradecraft）」という評価は、標的を絞った持続的な侵入を得意とするタイプであることを示す。研究機関・公益団体・サプライチェーン上流の企業は等しくリスクを負っている。 第二に、Luaバイトコードというアプローチは「ペイロードレス・アーキテクチャ」の一形態であり、従来のシグネチャベース検知が効きにくい。EDR（エンドポイント検出・対応）ソリューションの振る舞い検知に頼ざるを得ない状況を作り出している。 第三に、偽セキュリティソフトによる感染経路は、セキュリティ意識の高いユーザーほど騙されやすいという逆説を突く。「ウイルス対策ソフトのインストール画面だから安全」という先入観が仇となる。 実務での活用ポイント IT管理者・セキュリティ担当者向け LNKファイルの実行制限: グループポリシーまたはMicrosoft Intune（AppLocker/WDAC）でLNKファイルの外部からの実行をブロックする。メールやWebからのLNKは即座に疑うよう啓発する DLLサイドローディング対策: Windowsの「COMオブジェクト登録チェック」や、Defender for Endpointの攻撃面縮小（ASR）ルールでサイドローディングに対する検知精度を上げる FTPアウトバウンドのブロック: 多くの日本企業はFTP送信を許可したままにしがちだが、業務上の必要性がなければ全面遮断が望ましい パスワード付きアーカイブの扱い: ゲートウェイで自動展開できないアーカイブはサンドボックス解析に送るフローを整備する 正規サービス（Gmail等）経由の通信監視: DLP（データ損失防止）ポリシーとCASBを組み合わせ、クラウドサービス経由の大容量データ送信を検知する 筆者の見解 LucidRookが示す最も重要な教訓は、「現在動いているから安全」という前提がいかに危ういかだ。Luaバイトコードをオンデマンドで取得・削除する設計は、ペイロードを常駐させないことで痕跡を最小化する。感染後しばらくは何も起きていないように見える可能性すらある。 ゼロトラスト原則でいう「Never trust, always verify」をエンドポイント内部のプロセス動作にも適用する時代がきている。境界型防御で外からの侵入を防ぐ思想ではなく、内部での異常な振る舞い——たとえば「Microsoft Edge」を名乗るプロセスが意図しないDLLを読み込む動作——を検知するアーキテクチャへの移行が急務だ。 日本の大手エンタープライズを見ると、旧来のネットワーク境界防御と部分的なゼロトラスト実装が中途半端に混在している環境がいまだ多い。LucidRookのようなツールはそのギャップを正確に突いてくる。「層の薄いところを探して入る」のが高度な攻撃者の常套手段だからだ。 セキュリティは好き嫌いの話ではない。インフラを守るための設計思想として、全体最適で見直す機会を今こそ作ってほしい。部分的な対策の積み上げが全体としての脆弱性を生む——これはコストの問題である前に、設計哲学の問題だ。 出典: この記事は New ‘LucidRook’ malware used in targeted attacks on NGOs, universities の内容をもとに、筆者の見解を加えて独自に執筆したものです。