Tech News JP

Google DeepMindが2026年4月2日、オープンソースLLMシリーズの最新作「Gemma 4」を発表した。2B・4B・31B・26B-A4B（Mixture-of-Experts）の4モデルがApache 2.0ライセンスで公開され、いずれも画像・動画に対応したマルチモーダルモデルとして登場している。「パラメータ1バイトあたりの知能が史上最高」というGoogleの主張が本当なら、ローカルLLM界隈は一気に盛り上がる。 Gemma 4の技術的な特徴 「E2B」「E4B」——実効パラメータ数という新概念 小さい2モデルには「E2B」「E4B」という表記が使われている。「E」は「Effective（実効）」の意味で、Per-Layer Embeddings（PLE） という技術によるものだ。 通常のLLMはすべてのパラメータが推論計算に使われるが、PLEではデコーダー層ごとに小さな埋め込みテーブルを持たせ、推論時は「高速なルックアップ」で済ませる。テーブル自体は大きいが計算コストが極めて低い——だから「全パラメータ数」と「実効パラメータ数」が乖離する。オンデバイス展開向けのチューニングとして理にかなった設計だ。 マルチモーダルの広がり：画像・動画・音声すべて対応 全モデルが画像・動画をネイティブに処理でき、解像度も可変対応。OCRや図表理解が得意とされる。さらにE2BとE4BはネイティブAudio入力にも対応しており、音声認識・音声理解もモデル単体で扱える。 ただし現時点ではLM StudioやOllamaで音声入力を動かす方法は未確立で、ローカル実行での音声活用はまだ先になりそうだ。 LM Studioでの動作確認 Simon Willisonが実際にGGUF版で検証した結果： モデル ファイルサイズ 動作 E2B 4.41GB ○ 正常 E4B 6.33GB ○ 正常 26B-A4B 17.99GB ○ 正常 31B 19.89GB × ループ出力で破損 31BモデルはGGUFが壊れているようで、すべてのプロンプトに"---\n"を延々と返し続ける状態だった。大きいモデルほど初期リリースの品質ばらつきが出やすいのはローカルLLM界隈でよくある話だが、APIアクセスはAI Studioから可能になっているので、31Bを試したい場合はそちらが現実的だ。 実務への影響——ローカルLLM実用化の加速 Gemma 4が面白いのは「4.41GBのファイル1つで画像も動画も扱えるモデルが動く」という点だ。普通のPCのVRAMやメモリに収まる。 日本のエンジニアやIT管理者が明日から試せるポイントを整理する： 1. LM Studio経由でゼロコスト検証 E2B（4.41GB）・E4B（6.33GB）はLM StudioのGGUFで即動く。クラウドAPIへのアクセスなし、コストゼロで試せる。社内の機密ドキュメントOCRや図表解析の概念実証（PoC）に最適だ。 2. オフライン・エアギャップ環境への展開 Apache 2.0ライセンスかつローカル完結なので、金融・医療・製造業など外部通信が制限された環境でも使いやすい。従来はクラウドAPIなしでマルチモーダルを扱う手段が限られていたが、選択肢が広がった。 3. 26B-A4BのMoEアーキテクチャに注目 Mixture-of-Experts（MoE）は「推論時に全パラメータを使わず、担当の専門家サブネットワークだけを呼び出す」仕組みだ。26Bの規模感でありながら実効4Bレベルの計算コストで動く。コスト効率を重視する実務ユースケースにはこのモデルが主役になりそうだ。 筆者の見解 Googleの実務系AIには正直まだ様子見の姿勢だが、Gemma 4は注目に値する。「パラメータ効率」という研究方向は本物で、これはGoogleに限らず業界全体のホットテーマになっている。小さくても使えるモデルを作る競争は、ローカルLLMの実用化を直接加速させる。Gemma 4の登場は素直に歓迎したい。 気になるのは31BのGGUFがリリース直後に壊れていた点。「史上最高のパラメータ効率」を謳うリリースでモデルファイルが壊れているのはもったいない。とはいえコミュニティがすぐ修正するのもオープンソースの強みなので、致命的な問題ではない。こういう部分の品質を詰めていけば、GemmaシリーズはローカルLLMの有力な選択肢になるポテンシャルがある。 ローカルLLM派の人は今すぐLM Studioで26B-A4Bを試してほしい。17.99GBさえ積めるなら、ラップトップで動くマルチモーダルモデルとしてかなりおもしろい体験ができるはずだ。ガンガン使ってフィードバックを積み上げていくのが今の正しい動き方だと思っている。 出典: この記事は Gemma 4: Byte for byte, the most capable open models の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが本気を出してきた——そう感じさせる発表が飛び込んできた。同社のAI研究部門「Microsoft AI（MAI）」が2026年4月2日、音声認識・音声生成・画像生成の3つの基盤AIモデルをまとめて公開した。OpenAIへの依存が語られ続けてきたMicrosoftが、独自スタックの構築に本腰を入れ始めたことを示す動きだ。 3モデルの中身を読み解く 今回発表されたのは以下の3モデルだ。 MAI-Transcribe-1（音声認識） 25言語の音声をテキストに変換するモデル。特筆すべきは速度で、既存の「Azure Fast」オファリングと比べて2.5倍高速という。価格は1時間あたり$0.36からで、大量の音声データを処理する業務ユースケースでコスト競争力を持てる数字だ。日本語対応の25言語に入っているかどうかは公式発表で明示されていないが、Microsoftのグローバル展開を考えれば当然含まれているとみていいだろう。 MAI-Voice-1（音声生成） 1秒で60秒分の音声を生成できる、つまり60倍速のリアルタイム生成が可能なモデル。カスタムボイスの作成にも対応しており、企業が独自のブランドボイスを持てる。価格は100万文字あたり$22。 MAI-Image-2（画像・映像生成） 3月19日にMAI Playgroundで先行公開されていたモデルが正式リリース。テキスト入力100万トークンあたり$5、画像出力100万トークンあたり$33という価格設定。Google・OpenAIより安いとMicrosoft自身が主張している。 MAI Superintelligenceチームとは何者か これらのモデルを開発したのは、2025年11月に発足した「MAI Superintelligenceチーム」。トップに立つのはMicrosoft AI CEOのMustafa Suleyman——DeepMindの共同創業者であり、AIの倫理と安全性を重視することで知られる人物だ。 彼が掲げるのは「Humanist AI」というコンセプト。「人間のコミュニケーション様式に最適化し、実践的な使用のためにトレーニングする」という方向性は、スペック競争とは一線を画す差別化軸として機能しうる。 OpenAIとの$130億ドル超の投資関係は維持しつつも、直近のパートナーシップ再交渉によってMicrosoftは独自の超知能研究を本格的に進めることが可能になったとSuleymanは語っている。チップも「自社製造 × 外部調達」の両輪戦略を取るように、AIモデルも「OpenAI依存 × 自社開発」の二本立てへ移行しつつある。 実務への影響——日本のエンジニア・IT管理者に何が変わるか Microsoft Foundry経由での即時利用が可能になった点がまず重要だ。Azure上で動かしている既存ワークロードからMAIモデルへのアクセスは、追加の認証基盤や契約変更なしに始められる可能性が高い。 具体的に使えそなシナリオを挙げると： コールセンター・議事録自動化: MAI-Transcribe-1の速度向上はリアルタイム文字起こしを現実的な選択肢にする。Azure Speech Servicesと比較評価する価値がある eラーニング・コンテンツ制作: MAI-Voice-1のカスタムボイスで、社内教育コンテンツのナレーション自動生成が低コストで実現できる マーケティング素材生成: MAI-Image-2の価格設定は、GPT-4oやGeminiと真剣に比較すべき水準 MAI Playgroundでプロトタイピングして、本番はMicrosoft Foundryで——という開発フローが自然に使える点も見逃せない。 筆者の見解 正直に言う。「がんばれMicrosoft」という気持ちと、「この力をどう活かすかが勝負だぞ」という期待が同時にある。 MAIのモデルは技術的には面白い。価格競争力を前面に出してきた戦略も理解できる。だが問題は価格や性能スペックではなく、「どういう思想でプロダクトに組み込まれるか」だ。 Suleymanが強調する「Humanist AI」が、確認・承認を人間に求め続ける設計に落ちてしまうなら、本質的な価値は出にくい。AIが本当に仕事を変えるのは、目的を伝えれば自律的にタスクをやり遂げる——そういうパラダイムに到達したときだ。Microsoftにはそこまで踏み込む力がある。もったいない使い方をしないでほしい。 Microsoftの強みはプラットフォームとエコシステムだ。Entra ID・M365・Azureと深く統合されたAIスタックが本当の意味で自律エージェントパラダイムで動き始めたとき、ゲームが変わる。AIモデルの性能競争とは別の土俵で勝負できるのがMicrosoftの唯一無二の強みなのだから。 MAIモデルの登場は、その土俵に立つための重要な一歩だ。独自モデルを持つことで、プロダクト設計の自由度が格段に上がる。この自由度を「自律エージェント」の実現に振り向けてくれることを、心から楽しみにしている。 出典: この記事は Microsoft takes on AI rivals with three new foundational models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたか Googleが2026年4月2日、Gemini APIに新しいサービスティア「Flex Inference」と「Priority Inference」を追加した。これまで「バッチ処理か通常APIか」という二択だった開発者の選択肢に、より細かい粒度のコスト・信頼性コントロールが加わることになる。 シンプルに言えば「安さ優先のFlex」と「信頼性最優先のPriority」の2レーンを用意して、同じエンドポイント（service_tierパラメータ1つ）で切り替えられるようにした、というアップデートだ。 技術的な中身を整理する Flex Inference ── 標準APIの半額、ただし遅延あり Flex Inferenceはレイテンシ許容型ワークロード向けの低コストティアだ。価格は標準APIの50%オフ。 ポイントは「バッチAPIと違い、同期エンドポイントをそのまま使える」こと。従来のバッチAPIは入出力ファイルを管理してポーリングで結果を取りに行く非同期設計だったが、Flexは通常のAPIコールと同じ使い方でコストだけ下げられる。代償はリクエストの優先度が下がることによる遅延増加とやや低い信頼性だ。 適するユースケース： CRMのバックグラウンドデータ更新 大規模リサーチのシミュレーション エージェントの「思考」や「ブラウジング」ステップ（即時応答不要なもの） 設定はリクエストパラメータに "service_tier": "flex" を追加するだけ。すべての有料ティアで利用可能。 Priority Inference ── ピーク時も落とさない最高信頼性 Priority Inferenceは逆に最高優先度保証のプレミアムティアだ。ピーク負荷時も他のリクエストに割り込まれない。 「Graceful downgrade」と呼ばれる設計が面白い。Priorityの割当上限を超えたトラフィックは失敗せず自動的にStandardティアへフォールバックする。アプリが落ちるより、少し遅くなっても継続する方が多くのケースでユーザー体験として正しい。レスポンスにはどのティアで処理されたか明示されるので、課金や性能の把握も容易だ。 適するユースケース： リアルタイムカスタマーサポートBot ライブコンテンツモデレーションパイプライン 時間的制約のある処理全般 こちらはTier 2/3の有料プロジェクト向け。 実務への影響 ── 日本のエンジニア・IT管理者にとっての意味 このアップデートで実務的に変わるのは主にAIアーキテクチャのシンプル化とコスト最適化の粒度だ。 これまでGemini APIで大量処理と対話処理を両立しようとすると、バッチAPIと通常APIで別々の実装・ジョブ管理が必要だった。今後は service_tier パラメータ1つで経路を分けられる。コードベースの複雑度が下がるのは素直に良い設計だ。 コスト面では、非同期でよいバックグラウンド処理をFlex Inferenceに移行するだけで料金を半額にできる。AIエージェント系のワークロードは「考える」ステップが多く、そのほとんどは即時応答不要なのでFlexとの相性がいい。すでにGemini APIを使っているプロジェクトは、移行コスト試算から着手する価値がある。 実務でのアクションポイント： 既存のAPIコールを「即時応答が必要か否か」で分類する バックグラウンド系は service_tier: flex に切り替えてコスト比較 対話系・SLA重要系は service_tier: priority（Tier 2/3のみ）の検討 レスポンスのティア情報をログに残してコスト可視化 筆者の見解 技術的には悪くない。同一エンドポイントで粒度の細かいコスト・信頼性制御ができるようになるのは、API設計として正しい方向だ。「バッチか通常か」の二択しかなかった頃よりずっとマシになった。 ただ、率直に言う。Googleのgenerative AI領域での実務信頼性は、筆者の中ではまだかなり低い位置にある。 画像生成はぴか一だと思っているし、インフラの規模感はさすがだ。だが実際のコーディング支援・エージェント系タスクにおいて、現時点でGeminiをメインに使おうとは全く思えていない。このFlexとPriorityのアップデートも、「Googleがまた面白い機能を出した」というよりは、「他社APIに比べてユーザーが少ない中で、価格で差別化しようとしている」という印象が正直なところだ。 とはいえ、こういう動きはAPI市場全体に良い影響を与える。価格競争は開発者にとってはありがたい。GeminiのFlexが普及すれば、他社もコスト最適化ティアの導入を迫られる。その恩恵を間接的に受けるのは我々ユーザーだ。 Geminiを本番で使うかどうかはプロジェクトの要件次第だが、コスト優先のバックグラウンド処理でGemini Flexを「安い選択肢」として組み合わせる戦略は十分あり得る。ひとつのプロバイダーに全賭けせず、ワークロードごとに最適な選択をする時代になっている。Flexはその「安い引き出し」として使える可能性がある。 がんばれGoogle。実務での実績がさらに積み上がれば、有力な選択肢になるポテンシャルは十分にある。 出典: この記事は New ways to balance cost and reliability in the Gemini API の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIは、コーディング支援AIツール「Codex」において、ChatGPT BusinessおよびEnterpriseユーザー向けに従量課金（Pay-as-you-go）方式の料金プランを提供開始した。これまで固定サブスクリプションのみだった課金体系が変わり、使った分だけ支払える選択肢が加わったことで、チーム単位での試験導入や段階的な展開がしやすくなった。 Codex従量課金プランとは何か CodexはOpenAIが提供するAIコーディング支援ツールで、コードの自動補完・生成・レビューなどを担う。今回のアップデートにより、ChatGPT Business/Enterpriseプランの契約組織は、Codexを固定コストなしに利用開始し、利用量に応じてコストを払う形が可能になった。 これは企業IT部門にとってリスクを下げる変化だ。「とりあえず全社展開」ではなく、「一部チームで試して、効果が見えたら拡大する」という現実的なアプローチが取りやすくなる。 実務への影響——日本のIT現場では何が変わるか 日本企業の多くはSaaS系AIツールの導入判断において、コスト予測の難しさを理由に慎重な姿勢を取りがちだ。従量課金モデルの解禁は、その心理的ハードルを下げる効果がある。 具体的に使えるポイントとしては以下が挙げられる： PoC（概念実証）フェーズの低コスト化: 部門単位で小規模にCodexを試せる。月額固定費を払わず、実際の使用量ベースでROIを測定できる 利用量のトラッキング: 従量課金はコストの可視化でもある。どの部門・チームがどれだけ使っているかが把握しやすくなり、導入効果の評価がしやすい 既存M365/Azure環境との親和性: ChatGPT Enterpriseを既に契約している組織であれば、追加のベンダー審査なくCodexを試せる可能性がある IT管理者としては、利用ポリシーと支出上限の設定を先に整備しておくことが重要だ。「使えるようにしたが誰も使わなかった」と「使ったら予算が突き抜けた」の両方を避けるために、使用量アラートとチーム別予算上限の設定を事前に検討しておきたい。 筆者の見解 正直に言う。Codexの価格体系が柔軟になったことは、それ自体は悪いニュースではない。ただ、筆者の今の優先順位には入ってこない。 OpenAIのツールはすごくいい。Codexも技術的には優秀だ。でも今この瞬間、AIコーディング支援ツールに時間と認知資源を注ぐなら、今使い込んでいるツールに集中投資するのが正解だと思っている。ひとつのツールを深く使い倒すことで得られるノウハウは、他のツールへの応用が効く。逆は必ずしも成り立たない。 もう一つ気になるのは、「Codexを導入してAI活用に踏み出した」という感覚で止まってしまう組織が日本には多そうだということだ。AIコーディング支援ツールは、人間が指示を出して都度確認しながら使う「副操縦士」型で使い続けている限り、本来の生産性インパクトは出ない。Codexであれ何であれ、ツールを入れることが目的化した瞬間にプロジェクトは失敗する。 価格モデルの柔軟化は良い。でも「安く使えるようになった」ことより「どう使いこなすか」の方がはるかに重要だ。従量課金で試せるようになったこの機会を、ちゃんと成果を測るPoCの入り口として使えるなら、意味がある一歩になりうる。 出典: この記事は Codex now offers more flexible pricing for teams の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIがポッドキャストネットワーク「TBPN（The Breakdown Podcast Network）」の買収を発表した。技術系スタートアップが独立系メディアを傘下に収めるという、AI業界でも異色の動きだ。「AIに関するグローバルな対話を加速する」「ビルダーや企業、テックコミュニティとの対話を支援する」というのが公式の理由だが、この買収が持つ意味はもっと深いところにある。 TBPNとは何か TBPN（The Breakdown Podcast Network）は、テクノロジー・AI・スタートアップ界隈を中心に扱う独立系ポッドキャストネットワークだ。シリコンバレーの「語り手」たちが集まる場所として、業界内での影響力は小さくない。特にAIやWeb3周辺の議論が盛んなコミュニティで聴かれており、いわゆる「ビルダー層」——自分でサービスやプロダクトを作る技術者・起業家——への訴求力が強い。 なぜOpenAIがメディアを買うのか 表向きは「独立系メディアの支援」と謳っているが、本質は別のところにある。 OpenAIはここ数年、ChatGPTというプロダクトのブランドイメージを中心に成長してきた。しかし今、AI市場はAnthropicのClaude、GoogleのGeminiなど群雄割拠の状態に突入しており、「モデル性能」だけでの差別化が難しくなりつつある。そこでOpenAIが目をつけたのが「ナラティブ（物語）」だ。 AIについての議論が行われる場所、それ自体を自社の影響圏に入れることで、OpenAIに有利な文脈でAIが語られやすくなる。ポッドキャストというメディアは、「信頼できる人が話してくれる」という特性上、広告よりもはるかに深く聴衆に刺さる。これは単なるコンテンツマーケティングではなく、言論空間への直接投資だ。 独立性への懸念 TBPNが「独立系メディア」として機能し続けられるかどうかは、率直に言って疑問だ。OpenAI傘下になったポッドキャストが、OpenAIのライバル企業（Anthropic、Google DeepMindなど）に対して中立的な批評を続けられるだろうか。「独立メディアを支援する」という言葉は美しいが、資本関係が入った瞬間にその独立性は構造的に脅かされる。 過去にもテック企業がメディアや配信プラットフォームを取り込んで「中立性」を主張し続けた例はあるが、長期的に見てうまくいった例はほぼない。 日本のIT現場への影響 直接的な影響は薄いが、構造的な示唆は大きい。 まず、AIに関する「一次情報」の発信源が今後ますます大手AI企業に集約されていく可能性がある。日本の技術者・IT管理者が英語圏の技術情報を追う際、知らず知らずのうちに特定ベンダーの文脈でフィルタリングされた情報を受け取るリスクが高まる。 実務面では、情報ソースの多様性を意識的に維持することが重要だ。特定企業のブログやポッドキャストだけでなく、学術論文、独立系研究者のレポート、競合他社の技術ブログも合わせて参照する習慣を持つべきだろう。 筆者の見解 OpenAIが「話す場所」を買いに行ったという事実は、彼らが技術的優位性だけでは勝てないと感じ始めているサインではないかと思っている。 競合他社は開発者ツールやプラットフォーム統合で着実に存在感を高めており、Googleは膨大なユーザーデータと垂直統合で牙城を築いている。そんな中でOpenAIが取った戦略が「語り口の支配」というのは、ある意味正直な選択だとも言える。 ただ、個人的にはこのアプローチはあまり好きではない。AIのすごさは実際に使って感じるものであって、うまいポッドキャストで語られるものじゃない。現場で動いているコードと出てくるアウトプットだけが真実だ。どんなに巧みなナラティブを作っても、実際に使って「あ、これすごい」と思わせる体験には勝てない。 OpenAIにはTBPN買収より先にやることがある気がするが、まあ、彼らはそういう会社なのだろう。メディアゲームではなく、エンジニアリングで真剣勝負してほしいというのが正直な気持ちだ。 出典: この記事は OpenAI acquires TBPN の内容をもとに、筆者の見解を加えて独自に執筆したものです。

7年間の開発が規制の壁に砕かれた カリフォルニア拠点のスタートアップ「Kintsugi」が2026年4月、事実上の廃業を発表した。同社は約7年にわたり、音声データからうつ病や不安障害の兆候を検出するAIを開発し続けてきた。しかし米国食品医薬品局（FDA）の承認を得る前に資金が底をつき、技術の大部分をオープンソースとして公開するという形で幕を閉じた。 医療AIスタートアップがいかに規制の壁に弾き飛ばされるか。その典型的なケーススタディがここにある。 「声の分析」で精神疾患を検出するという発想 Kintsugiのアプローチは、従来の精神科診断の盲点を突くものだった。現在の精神疾患スクリーニングの主流は「PHQ-9」に代表される患者自記式質問票や臨床面接であり、いわば「患者が何を言うか」に依存している。 これに対しKintsugiは「どのように話すか」に着目した。話すテンポ、間の取り方、文構造、声のパターン——こうした特徴はうつ病や不安障害の指標として研究でも確認されており、同社のAIはそれを短い音声サンプルから自動検出するものだ。査読済み論文においてもPHQ-9と同等水準の結果を示したと報告されている。 狙いは明快だった。自記式ツールはスクリーニング率が低く、患者が正確に症状を表現できるとは限らない。AIを使えばより客観的なシグナルを大規模に、医療機関や保険会社、企業の健康プログラムに展開できると訴えていた。 FDAの「De Novo」審査経路が牙をむいた 問題は規制だ。この技術を医療用途として展開するにはFDA承認が必要で、Kintsugiは「De Novo」と呼ばれる経路を選んだ。これは前例のない新種・低リスク医療機器向けのルートで、理論上は迅速化を意図している。しかし現実には数年単位のデータ収集と審査が必要だ。 さらに根本的な問題がある。FDA の審査フレームワークはAIのために設計されていない。人工股関節、手術器具、ペースメーカーのような「一度承認されたら設計が固定される」機器を前提としているのだ。AIモデルは継続的に更新・改善されてこそ価値があるが、FDA の枠組みではその「更新」のたびに新たな問題が生じる。 KintsugiのCEO、Grace Chang氏によれば、審査官に対してAI自体の説明から始めなければならない状況が続いたという。さらにトランプ政権による規制緩和の号令があったにもかかわらず、現場の規制専門家からは「上から大声で叫ぶ以外に何も変わっていない」という声が返ってきたとのことだ。連邦政府のシャットダウンも審査を遅らせた。 そして最終的な申請提出を前に、資金が尽きた。 「略奪的」な短期融資を断り、オープンソースへ 追い詰められたKintsugiに、1週間5万ドルを受け取る代わりに100万ドル相当のエクイティを差し出せという提案が届いた。Chang氏は「略奪的」と評してこれを拒否し、代わりに技術の大部分をオープンソース化するという判断を下した。 一部の技術（ディープフェイク音声検出など）は医療以外の用途での活用が期待されており、別の命脈を得る可能性も残されている。 実務への影響：医療AIの規制リスクをどう見るか 日本の医療AIにも同じ壁がある 日本では厚生労働省が医療機器プログラム（SaMD）として医療AIを審査するが、FDA同様にAI特有の「継続学習・更新」への対応は発展途上だ。PMDA（医薬品医療機器総合機構）は近年ガイドラインの整備を進めているが、承認後の性能変化に関するルールはまだ流動的。医療AI開発に関わるエンジニアは、審査サイクルを見越した開発計画が必須になる。 精神科スクリーニングの技術的可能性は失われていない Kintsugiの閉鎖は技術の失敗ではなく規制・ビジネスの失敗だ。オープンソース化された成果物は研究者・開発者に引き継がれる可能性がある。音声ベースの精神疾患スクリーニングの研究は世界的に継続しており、日本の精神科医療（慢性的な人手不足が深刻）への応用期待も高い。 医療以外での応用を先に狙え 規制が重い医療用途と違い、企業のメンタルヘルスプログラムや非診断的なウェルネス用途であれば規制ハードルは大きく下がる。スクリーニング結果を「参考情報」として提供する形であれば、今すぐ展開できる領域がある。 筆者の見解 この話を読んで「規制がひどい」「かわいそうなスタートアップ」という感想で終わるのは浅い。問題の本質は別のところにある。 FDAが変われないのはわかった。だがKintsugiは7年かけて資金を使い果たした末に閉鎖した。その間にビジネスモデルを規制不要の領域にシフトする選択肢はなかったのか。「医療機器として承認を取る」という最もハードルの高い経路に固執し続けた判断は、投資家へのストーリーとしての整合性を優先した結果ではないか、と思えてならない。 AIと規制の相性問題は今に始まったことではない。フレームワークが旧来の物理デバイスを前提に作られているという指摘は正しいが、それは業界全体が5年以上前から言い続けてきたことだ。それを「知ってた」と言いながら正面突破を狙った戦略はギャンブルだった。 むしろ注目すべきは、技術をオープンソース化して手放すという判断だ。略奪的条件の短期資金を断ってオープンソース化を選んだCEOのその決断は評価に値する。技術が死なずに生き続ける可能性を残した。ディープフェイク音声検出への転用含め、本来の医療用途以外で開花する道がある。 日本のIT・ヘルスケア業界への示唆はこうだ。医療AIを「承認を取って売る」という発想から離れ、まずは規制グレーゾーン外の領域で実績を積み、段階的に規制対応を進めるアプローチを取れ。完璧な承認を待っている間に会社が死ぬ。Kintsugiはその最も鮮やかな反面教師になった。 精神疾患のスクリーニングに音声AIが使われる未来は来る。ただしそれを実現するのは、規制に正面から挑んで散ったスタートアップではなく、もっとしたたかな経路を選んだプレイヤーになるだろう。 出典: この記事は It’s not easy to get depression-detecting AI through the FDA の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがコラボレーションツールのLoop（Microsoft Loop）から、Copilotが生成するAIレキャップ（recap）機能を削除することを発表した。「AIをあらゆる場所に」という同社の戦略から見ると、これは異例中の異例——方向転換というよりも、静かな撤退に近い。 Microsoft Loop のAIレキャップとは何だったのか Microsoft LoopはNotion対抗として2023年にGAとなったM365のコラボレーションスペースだ。「ページ」「コンポーネント」「ワークスペース」という概念を使い、チームがリアルタイムに共同作業できる環境を提供する。 AIレキャップ機能は、このLoopワークスペース内の活動を自動的に要約し、「前回から何が変わったか」「誰が何をしたか」をCopilotがまとめて提示するというものだった。会議に出られなかった、しばらく離れていた、という場面で「キャッチアップ」を助けるのが主な用途として想定されていた。 なぜ廃止されるのか Microsoftが公式に詳細な理由を示しているわけではないが、背景として考えられる要因はいくつかある。 利用率の問題: レキャップ機能は使われていなかった可能性が高い。Loop自体がまだユーザーベースを拡大中であり、そのうえAI要約という付加機能はニッチな使われ方にとどまっていたと推測できる。 コスト対効果: CopilotはAzure OpenAIのAPIコストを消費する。利用率が低いまま維持するのは明らかに非効率だ。 品質の問題: AI要約の精度が期待値を下回っていた可能性もある。誤った要約、文脈を無視した要約は、むしろ混乱を招く。 いずれにせよ、「AI機能を追加する」方向だけでなく「使われないAI機能を削除する」という意思決定ができるようになったこと自体は、成熟の証とも言える。 実務への影響——日本のIT現場では まず、Loop自体の普及状況を確認しておきたい。日本でLoopを積極的に導入・活用している企業はまだ少数派だ。M365 E3/E5に含まれているため「使えるが使っていない」状態の組織が多く、今回の変更を意識しているユーザーも限られるだろう。 すでにLoopを活用している組織は、レキャップ機能に依存したワークフローがあれば代替手段を検討する必要がある。Teams のミーティング要約（Intelligent Recap）やOneNoteとの連携、あるいは手動でのサマリー作成に切り替えるのが現実的だ。 これからLoopを検討している組織にとっては、AIレキャップ廃止はほぼ影響なしと考えてよい。Loopの本質的な価値はリアルタイムコラボレーションにあり、AI要約はオマケ機能に過ぎなかった。 IT管理者へのヒント: MicrosoftのM365ロードマップ（Microsoft 365 Roadmap）を定期的に確認する習慣をつけておくこと。今回のような機能廃止は、ユーザーへの事前周知なしに進むことがある。Message Centerアラートの設定は必須だ。 筆者の見解 正直に言う。「Copilotあらゆるところに刺さります！」という数年間のMicrosoftのノリには、ずっと違和感を持っていた。LoopのAIレキャップも、使って感動した人より「要らなかった」と感じた人のほうが多かったんじゃないかと思っている。 だから今回の廃止は、「残念」ではなく「まあそうだよね」という感想だ。使われない機能を削るのは正しい。むしろ遅かった。 ただ、問題はその奥にある。Microsoftはここ数年、「Copilot」という名前を至るところに貼り付けてきた。M365 Copilot、GitHub Copilot、Windows Copilot、Copilot Studio……。機能の中身より名前の統一を優先して、結果として「Copilotって何なの？」という混乱を生んでいる。今回の廃止も、ロードマップの整理というよりは「コッソリ消した」に近い。 Copilotブランドの整理は急務だ。だが、AI基盤としてのMicrosoftの価値は揺るがない。Entra ID・M365・Azureという圧倒的なエコシステムを持っている会社は他にない。だからこそ、個々のAI機能の取捨選択はもっと大胆にやってほしい。今回のように「使われない機能を削る」判断を、もっと早く・もっと広くやれるはずだ。正面から勝負できる力があるのだから、薄く広く貼るより、本当に価値のある体験に集中してほしい。 がんばれ、Microsoft。本当に。 出典: この記事は Microsoft to strip AI-generated recaps from Loop in surprising move の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11上でEdgeへのユーザー誘導を強化する新たな手法を試験導入していることが明らかになり、GoogleをはじめとするブラウザベンダーやNGOで構成されるBrowser Choice Alliance（BCA）が強く反発している。静かに進むこの施策が、ユーザーの「ブラウザを選ぶ権利」を根底から脅かすものだとして、国際的な批判の声が上がっている。 何が起きているのか BCAが問題視しているのは、Windows 11のテスト段階で確認された挙動だ。ユーザーがChromeやFirefoxなどを既定ブラウザとして設定していても、特定の操作をトリガーにEdgeが再び前面に出てくるよう設計されているという。明示的な確認なしに「静かに戻す（quiet nudge）」仕組みであり、ユーザーが気づかないうちに選択が上書きされるリスクがある。 この手法はEUのデジタル市場法（DMA）が義務付ける「真の選択肢の提供」に反する可能性があり、日本を含む非EU圏でも競争法上の観点から問題提起されかねない水準だ。 Microsoftの「Edge推し」の歴史 MicrosoftがEdgeを優遇してきた歴史は長い。Windows 10以降、既定ブラウザの変更UIをわかりにくく設計したり、「Edgeを使ってみますか？」の通知を繰り返し出したりと、ソフトな強制が続いてきた。2022年にはEUの圧力を受けてブラウザ選択画面を復活させたが、今回の「静かな誘導」はその精神を骨抜きにするものだとBCAは主張する。 BCAにはGoogleのほか、Mozilla、Opera、Vivaldi、さらには消費者保護団体も名を連ねており、単純なライバル企業の嫌がらせではなく、ブラウザエコシステム全体の問題として訴えていることがわかる。 実務への影響——IT管理者はどう動くべきか 企業のIT環境では、ブラウザの標準化はセキュリティポリシーや社内システムの動作保証と直結する。ChromeやEdgeをグループポリシーで管理している組織にとって、OSアップデートやテスト機能のロールアウトによって既定ブラウザが意図せず変更されるリスクは無視できない。 今すぐ確認・対応すべきポイント： 既定ブラウザのポリシー固定: Intune や グループポリシー（GPO）で DefaultBrowserSettingEnabled を明示的にFalseに設定し、ユーザー操作・OS側の干渉両方をブロックする Windows 11の段階的ロールアウト監視: Insiderチャネルで確認された挙動が安定版に降りてくる前に、テナントの更新リングを確認しておく ブラウザ変更の監視ログ: Microsoft Entra（Intune）のデバイスコンプライアンスレポートに既定ブラウザの変更トリガーが記録されていないか定期チェック ゼロタッチ展開の見直し: 自動プロビジョニング後のブラウザ設定が期待通りか、テスト環境で確認するステップを追加する 筆者の見解 長年Microsoftの技術を追いかけてきた立場から、率直に言いたい。Edgeは技術的に良いブラウザだ。 Chromiumベースになって以降、安定性もパフォーマンスも着実に向上した。企業向けのセキュリティ機能は充実しているし、M365との統合やIntuneでの一元管理、Entra IDとの認証連携を考えると、エンタープライズ環境でEdgeを選ぶ合理性は十分にある。 だからこそ、こういう「気づかないうちに戻す」やり方はもったいない。Edgeには正面から勝負できるだけの実力がある。それを、ユーザーの選択を静かに上書きするような手法で補おうとする必要はないはずだ。 Microsoftが本来得意としてきたのは、「禁止ではなく便利にして使わせる」アプローチだ。Microsoft Entra IDを使う仕組みを自然に選ばせる、Teamsを使いたくなる環境を整える——そういう「道のド真ん中を歩く」戦略でエコシステムを広げてきた実績がある。今回のEdge誘導は、その自社の哲学と矛盾している。ここは正直に、ダメなものはダメと言わなければいけない。 一方で、企業の現場ではEdgeを軸にした運用を組んでいる組織も多いだろう。M365との統合メリットは大きく、それ自体は正しい判断だ。重要なのは、Intuneやグループポリシーできちんと既定ブラウザを固定し、OSアップデートによる意図しない変更を防ぐ仕組みを整えておくこと。Microsoftのプラットフォームを信頼して使うことと、個別の施策を無条件に受け入れることは別の判断だ。 がんばれMicrosoft。正面から選ばれるブラウザを作る力はあるのだから、それを信じてほしい。 出典: この記事は Browser Choice Alliance slams Microsoft for latest shady Edge tactic の内容をもとに、筆者の見解を加えて独自に執筆したものです。

リード EUの最高行政機関である欧州委員会のAWSクラウド環境が、2026年3月10日に侵害された。攻撃を担ったのは「TeamPCP」と呼ばれる脅威グループ。被害はEU機関71クライアントに及び、メールアドレス・氏名・メール本文を含む約90GBのデータが闇ウェブに流出している。CERT-EU（EUサイバーセキュリティサービス）が4月3日に詳細を公表した。 この事件は単なる「大手機関のクラウド侵害」ではない。サプライチェーン攻撃 → クレデンシャル窃取 → クラウド横展開という攻撃チェーンの教科書的な実例であり、日本のIT現場にも直接刺さる話だ。 攻撃の経緯——Trivyが起点だった 攻撃の起点はDevSecOpsツールとして広く使われているコンテナ脆弱性スキャナー「Trivy」のサプライチェーン攻撃だ。TeamPCPはTrivyへの不正コード混入を通じて、欧州委員会のAWSアカウントに対する管理権限を持つAPIキーを事前に入手していた。 3月10日、このAPIキーを使って欧州委員会のAWSクラウド環境に侵入。その後、オープンソースのシークレットスキャンツール「TruffleHog」を使って環境内に残存するさらなる認証情報を探索し、既存ユーザーに新規アクセスキーをアタッチすることで検出回避を図った。 さらに巧妙なのが、この侵入が5日間検知されなかった点だ。欧州委員会のCybersecurity Operations Centerは、APIの不正利用も、アカウント侵害の兆候も、異常なネットワークトラフィックも、3月24日まで気づかなかった。侵入から一週間近くが経過してからの検知だ。 流出データの規模 CERT-EUの分析によると、盗まれたデータは以下の通り： 対象クライアント数: 欧州委員会内部42クライアント＋EU他機関29以上、合計71クライアント 流出ファイル数: 数万件（個人情報含む） メール関連ファイル: 51,992件（合計2.22GB） ダークウェブ公開: ShinyHuntersグループが90GBアーカイブ（非圧縮340GB）として公開済み メール関連ファイルの多くは自動通知メールとのことだが、「バウンスバック通知」にはユーザーが送信した元のメッセージ内容が含まれる場合があり、個人情報漏洩リスクが残る。 なお、Webサイトの改ざんや他のAWSアカウントへの横展開は確認されていない。 実務への影響——日本のIT管理者が今すぐ確認すべきこと 1. TrivyなどのDevSecOpsツールはバージョン固定で使っているか サプライチェーン攻撃の怖さは、信頼しているツールが凶器になる点だ。CIパイプラインで使うスキャナーやCLIツールのバージョンを固定し、ハッシュ検証を行う運用が必要。「最新版を自動取得」はもはや安全ではない。 2. AWSのIAMキー管理を見直せ 今回の攻撃はAWS APIキーの奪取から始まった。IAMポリシーの「最小権限の原則」は当然として、長期有効なアクセスキーの存在そのものがリスクだ。IAMロール＋一時的なクレデンシャル（STS）への移行、使われていないキーの即時削除、アクセスキーのローテーション自動化を今すぐ実施すること。 3. TruffleHogは攻撃者も使う——先に自分でスキャンしろ 皮肉な話だが、TruffleHogは防御側が「リポジトリにシークレットが埋まっていないか」を確認するためのツールでもある。攻撃者に先んじて自分の環境をスキャンし、漏洩したシークレットを先に無効化する運用を入れるべきだ。 4. 検知の遅れをどう縮めるか 5日間気づかなかったのはEUの機関でも起きうる現実だ。SIEM・CSPM（Cloud Security Posture Management）の導入と、異常なIAM操作へのアラート設定が基本中の基本。「CloudTrailは入れてる」だけでなく、アラートが実際に飛ぶ設定になっているかを今日確認してほしい。 筆者の見解 正直に言う。セキュリティは好きじゃない。細かい人が多いし、議論が不毛になりがちだ。でも今回の件は技術的に非常に興味深いし、見逃せない教訓がある。 まず、Trivyというれっきとしたセキュリティツールがサプライチェーン攻撃の入口になったという皮肉。セキュリティを強化しようとしてセキュリティ侵害される——これは「禁止アプローチ」の限界そのものだ。ツールを禁止するより、ツールを安全に使える仕組み（バージョン固定・ハッシュ検証・SBOM管理）を作ることが正解だ。禁止は必ず失敗する。 そして「5日間検知されなかった」という点。欧州委員会レベルの組織でこれが起きる。日本の大手エンタープライズの多くは、もっとひどいことになっているはずだ。「今動いているから大丈夫」は通用しない——これは過去にも何度も言ってきたが、今回はEUレベルの実例が出た。言い訳できなくなった。 IAMキー管理についても一言。「常時有効なAPIキーを発行してどこかに置いておく」という運用は、ゼロトラストの観点から言えば論外だ。Just-In-Timeアクセス、一時クレデンシャル、IAMロール——これらは「難しいからいずれやる」ではなく、今すぐやるべきことのリストの一番上に置くべきだ。 TeamPCPはGitHub・PyPI・NPM・Dockerと幅広いプラットフォームを標的にしているサプライチェーン攻撃の常習犯だ。今回の欧州委員会への侵入で終わりではなく、次のターゲットがどこかにいる。自分の組織が「よりリッチな標的」になっていないか、CIパイプラインの棚卸しを今すぐやってほしい。 出典: この記事は CERT-EU: European Commission hack exposes data of 30 EU entities の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが今週から、IT部門による管理が行われていないWindows 11 24H2（HomeおよびPro）デバイスを対象に、Windows 11 25H2への強制アップグレードを開始した。「気づいたらOSバージョンが上がっていた」という体験をするユーザーが続出するタイミングだ。個人PCでMicrosoft 365を使う業務担当者や、管理外デバイスが混在する組織のIT担当者は状況を把握しておく必要がある。 何が起きているのか MicrosoftはML（機械学習）ベースの「インテリジェントロールアウト」の適用範囲を、IT管理外のWindows 11 24H2 HomeおよびPro 全台 に拡大した。 背景は明確だ。Windows 11 24H2のサポート終了日は 2026年10月13日。残り約6ヶ月。サポート終了後はセキュリティ更新、タイムゾーン更新、テクニカルサポートがすべて止まる。Microsoftの公式表現を借りれば「最新の脅威からの保護を含む月次セキュリティ更新を受け取れなくなる」。 なお、25H2は大きなメジャーアップデートではない。200KB未満の「有効化パッケージ」 で適用されるマイナーアップデートで、2025年9月から段階配信が進んでいた。 アップグレードの流れと対処法 自動更新対象: IT管理（MDM/Intune等）外のHome/Proデバイス全台 手動で先行確認: 設定 → Windows Update → Windows 11 25H2のリンクをクリック 一時停止も可: 設定 → Windows Update → 一時停止（ただし期限後は強制適用） 再起動タイミングは自分で選択可能 Microsoftはアップグレード時のトラブル対応用にサポートドキュメントとステップバイステップガイドを公開している。 背景：立て続けに起きているトラブルとの重なり タイミングが若干不安だ。2026年3月のPatch Tuesday以降、Microsoftは複数の緊急対応を余儀なくされている。 Microsoftアカウントのサインイン失敗（Teams・OneDrive等に影響）→ KB5085516で対処 Bluetoothデバイスが見えなくなる問題（ホットパッチ対応のWindows 11 Enterprise向け） RRAS（Routing and Remote Access Service）のセキュリティ脆弱性 → 帯域外更新で修正 これだけ問題が連続している中で、25H2への強制移行が始まったのが現状だ。 実務への影響 IT管理者・情報システム担当者 最大の課題は 「管理外デバイスの把握」 だ。BYODや在宅勤務者の個人PC、テスト機、来客用端末など、MDM/Intune管理外のデバイスが組織内に混在しているケースは少なくない。確認しておきたいポイントは以下： 管理外デバイスの棚卸し: 何台あり、どのバージョンが走っているか 25H2との互換性チェック: 古い業務アプリ、特にドライバー依存の周辺機器との相性 エンドユーザーへの周知: 一時停止方法を案内するか否かの組織判断 25H2適用後のサインイン問題対策: KB5085516の適用状況を確認しておく 個人・SOHOユーザー 基本的には放置で問題ないケースが大半だ。ただし業務でTeamsやOneDriveを使っている場合、サインイン失敗が起きた際の対処法（緊急更新KB5085516の適用）は頭に入れておこう。 ...

3年前、「スマートフォンで言語モデルを動かす」といえば、学会発表用のデモ映像の世界だった。それが今や、数十億パラメータのモデルがフラッグシップスマートフォン上でリアルタイム動作する時代になった。Meta AIリサーチャーのVikas Chandra・Raghuraman Krishnamoorthi両氏による「On-Device LLMs: State of the Union 2026」は、この劇的な変化の背景と現状を実践的な視点から整理した技術レポートだ。 なぜオンデバイスか——4つの根拠 クラウドLLMではなく端末内で推論する理由は4点に集約される。 レイテンシ：クラウド経由だと最初のトークンが返ってくるまでに200〜500msかかる。ARオーバーレイ、リアルタイム翻訳、音声アシスタントでは、この遅延が致命的にユーザー体験を壊す。オンデバイスなら、特に短いコンテキストでは1トークンあたり20ms以下で生成できる。 プライバシー：デバイスから出ないデータは、転送中に盗まれることもサーバーにログされることもない。医療データ、金融情報など機微情報を扱うユースケースでは、これは単なるオプションではなく、規制上の要件になりつつある。 コスト：クラウド推論はクエリ単価が積み重なる。大量のリクエストが発生するアプリケーションでは、ユーザーがすでに持っているハードウェアに推論コストをオフロードできるオンデバイスの経済合理性は圧倒的だ。 可用性：電波の届かない場所、機内、地下でも動き続ける。クラウド依存は接続信頼性への依存と同義だ。 もちろん、フロンティアレベルの推論、広範な世界知識、長い多回話話会話が必要ならクラウドが依然として正解だ。だがレイテンシ重視・プライバシー重視・大量処理が必要なユースケースでは、オンデバイスが「現実的な選択肢」に入ってきた。 技術的ボトルネックは「メモリ帯域幅」 多くの人が誤解しているが、エッジデバイスの制約は「演算性能」ではない。現代のモバイルNPUは相当な性能を持っている。 Apple A19 Pro Neural Engine：約35 TOPS Qualcomm Snapdragon 8 Elite Gen 5：約60 TOPS MediaTek Dimensity 9400+：約50 TOPS これは2017年頃のデータセンターGPU（V100で125 TOPS）に迫る水準だ。 真のボトルネックはメモリ帯域幅にある。モバイルデバイスは50〜90 GB/s、データセンターGPUは2〜3 TB/sと、30〜50倍の差がある。LLM推論のデコードフェーズはメモリバウンドな処理なので、トークンを1つ生成するたびにモデルの重み全体をメモリからロードし直す。演算ユニットはメモリ待ちで遊んでいる状態だ。 だから「量子化」の効果が絶大になる。16ビットから4ビットへの量子化は単に4倍の省ストレージではなく、トークンあたりのメモリトラフィックを4分の1に削減し、それがスループット向上に直結する。さらに「複数トークンの並列予測」も、追加レイテンシなしに実効スループットを向上させる有力な手法として実用化されている。 もう一つの制約はRAM容量だ。ハイエンド端末でも、OSやほかのアプリとの共存を考えると実質的に使えるRAMは4GB未満になる。これはMoE（Mixture of Experts）アーキテクチャの適用に制限をかける要因でもある。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと モバイルアプリ開発者：ユーザーへのAI機能提供において「クラウドAPI呼び出し一択」の時代は終わりつつある。Apple Core MLやQualcomm AI Engineのツールチェーンが成熟してきており、3B〜7Bクラスのモデルなら端末内推論が現実的なアーキテクチャ選択肢になった。ただし「TOPSが高ければ速い」は誤解。アテンション演算や動的形状のサポート、ツールチェーンの成熟度を必ず確認すること。 プライバシー・コンプライアンス担当者：医療・金融・法律など機微情報を扱うシステムで、「ユーザーのデータが端末外に出ない」という設計は規制対応の観点から非常に強力な武器になる。GDPR、個人情報保護法対応のアーキテクチャ設計でオンデバイスLLMを選択肢に加えるべきタイミングだ。 業務アプリ設計者：現場作業員向けアプリ（工場内、建設現場、医療現場）では電波が安定しないケースが多い。オンデバイスLLMによるオフライン推論は、そういった環境での音声入力・要約・分類に有力な解答になる。 コスト設計：クラウドLLMのAPI費用が高騰しているプロジェクトでは、処理をオンデバイスに移すことで劇的なコスト削減が可能な場合がある。ただし開発・デバッグのコストも考慮すること。 筆者の見解 Metaのリサーチャーによるレポートだが、内容はMeta固有の話というより、オンデバイスLLM全体の技術的な見通しをまとめたものとして読む価値がある。現状、ローカルLLMの選択肢は中国勢（Qwen、DeepSeekなど）も含めて急速に広がっており、Metaのモデルがその中でどこまで存在感を出せるかはまだ見えないが、こうした技術レポートを公開してくれること自体はありがたい。 オンデバイスLLM自体のトレンドは本物で、重要だ。 このレポートが指摘している「ボトルネックはコンピュートではなくメモリ帯域幅」という洞察は非常に鋭い。クラウドとの30〜50倍のメモリ帯域幅の差がある以上、モバイル向けLLMの最適化は「クラウドLLMの縮小版」ではなく、まったく別の設計思想が必要になる。量子化・スパース化・マルチトークン予測の組み合わせは、その設計思想の答えの一つだ。 日本のIT業界で気になるのは、「クラウドLLM API呼び出し」か「LLM禁止」の二択で思考停止している企業がまだ多いことだ。オンデバイスはその中間にある第三の選択肢で、プライバシーとコストの両面で合理的なケースが確実にある。「データを外に出したくないからAIは使えない」という理由で諦めていた組織は、今すぐ選択肢を再評価すべきだ。 AIは端末の中に入ってきた。クラウドに頼らず、オフラインで、プライベートに動くAIが現実になりつつある。この変化を「スマホのちょっとした機能向上」と見ているなら、大きく出遅れることになる。 出典: この記事は On-Device LLMs: State of the Union 2026 – Meta AI Research の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年の幕開けとともに、テクノロジー投資の世界が文字通り「別次元」に突入した。Crunchbaseのレポートによると、2026年Q1のベンチャー資金調達額は史上最高を更新し、その80%にあたる約2420億ドル（約36兆円）がAI関連企業に流れ込んだ。1四半期でこの規模というのは、かつてのドットコムバブル全盛期ですら想像できなかった数字だ。 資金はどこに集まったのか 内訳を見ると、集中ぶりが際立っている。 OpenAI: 1220億ドル（単独で全体の40%超） Anthropic: 300億ドル xAI（Elon Musk）: 200億ドル この3社だけで合計1720億ドル。残りの700億ドルがその他すべての世界中のスタートアップに分配された計算になる。フロンティアLab（先端AIモデルを開発する一握りの企業）への資本集中は「加速する勝者総取り」の構造を如実に示している。 なぜこれが重要か 単純に「すごい額だ」で終わらせてはいけない。この資金構造には2つの重要なシグナルが含まれている。 第一に、計算資源の囲い込みが本格化している。 AIモデルの性能競争は今や「誰がより多くのGPUクラスターを持てるか」というゲームになっている。OpenAIへの1220億ドルの大半はMicrosoftをはじめとする戦略的投資家からのもので、インフラへの先行投資という性格が強い。Anthropicへの300億ドルにはAmazon（AWS）からの大型コミットが含まれており、クラウドプロバイダーによる「AIモデルの抱き込み」が着々と進んでいる。 第二に、「AIを使う企業」ではなく「AIそのものを作る企業」への賭けに投資家がシフトした。 これは2021〜2022年のSaaS投資ブームとは本質的に異なる。スタートアップエコシステム全体で見れば、むしろAIインフラレイヤーへの超集中投資の裏で、一般的なスタートアップへの資金は細りつつある可能性がある。 実務での活用ポイント IT調達・戦略担当者へ: OpenAIとAnthropicの財務基盤の強化は、それぞれのAPIサービスの安定性・継続性を意味する。「スタートアップなので突然サービス終了するリスク」という懸念は、今後ますます薄れていく。ガバナンスポリシーを整備したうえで、エンタープライズ契約の交渉に動いていいタイミングだ。 開発チームへ: フロンティアLab同士の競争激化は「モデル性能の急速な向上」と「価格競争」を同時にもたらす。現時点で最適なモデルを選んで固定するより、抽象化レイヤーを設けてモデルを差し替えやすいアーキテクチャを採用することが中長期的に有利になる。 エンジニア個人へ: このスケールの投資が続く限り、「AIは一過性のブームかもしれない」という観測は完全に否定された。今から実際に手を動かして使い倒す経験を積まない人間は、2〜3年後に取り返しのつかない差をつけられる。 筆者の見解 この数字をどう受け止めるか。OpenAIに1220億ドル、Anthropicに300億ドル、xAIに200億ドル——上位3社だけで1720億ドルという集中ぶりは、AI市場が「実験フェーズ」を完全に抜けて「インフラ投資フェーズ」に入ったことを意味している。これだけの資本が動いているのは、投資家がAIの将来価値に本気で賭けている証拠だ。 各社の投資額の違いは、ブランド力・ユーザーベース・クラウドパートナーとの関係など複合的な要素を反映している。重要なのは個別の優劣ではなく、フロンティアLabが軒並み財務基盤を固めたという事実だ。APIサービスの継続性リスクが下がり、エンタープライズ契約の交渉がしやすくなるという実務的なメリットがここにある。 それより深刻なのが日本のIT業界の反応だ。この規模の資本が動いているということは、世界のAI開発スピードが今後さらに加速するということを意味する。なのに、まだ「AIを試してみようか」「社内ガイドラインを整備中」という企業が大多数を占めている。この2〜3年の立ち遅れは、もはや「遅れ」ではなく「別のゲームをやっている」と表現すべきレベルだ。大変革に気づいていない企業が多すぎる。がんばれ、日本のIT業界。 出典: この記事は Q1 2026 Shatters Venture Funding Records As AI Boom Pushes Startup Investment To $300B の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年3月、オープンソースのLLM推論エンジン「vLLM」が大型アップデート Model Runner V2（MRV2） をリリースした。単なる機能追加ではなく、エンジンのコア部分をゼロから書き直すという思い切った刷新だ。既存APIとの互換性は維持しつつ、内部アーキテクチャを根本から再設計した今回のリリースは、本番環境でLLMを運用するエンジニアにとって無視できないアップデートとなっている。 vLLMとは何か——まず押さえておく基礎 vLLMは、UCバークレーのSky Computingラボが2023年に公開したオープンソースのLLM推論エンジン。PagedAttentionという独自のメモリ管理技術によって、GPUのVRAMを効率的に使い回しながら高スループットな推論を実現した。OpenAIの推論APIと互換性のあるインターフェースを備えており、「自前でLLMサーバを立てる」ための事実上のデファクトとして広く使われている。 Hugging FaceのTransformersが「モデルを動かす」ツールだとすれば、vLLMは「モデルを本番スケールで速く動かす」ツール、という位置づけだ。 MRV2の何が変わったのか モジュール性の大幅向上 旧来のvLLMはコードが密結合しており、特定のハードウェア（NVIDIA GPU）や特定のモデルアーキテクチャに最適化するたびに、深いところまで手を入れる必要があった。MRV2ではModel Runnerのレイヤーを明確に分離・抽象化し、ハードウェアバックエンドを差し替え可能な設計に刷新された。 これにより、AMD GPU・Google TPU・各種NPUへの対応コストが大幅に下がる。AWSのTrainium/Inferentiaや、今後登場してくる国産AIチップへの対応も、従来より現実的な工数で実現できるようになった。 推論効率の改善 MRV2ではテンソルの管理方式が見直され、バッチ処理のオーバーヘッドが削減された。特に長コンテキスト推論（100K〜1Mトークン規模）や、マルチモーダルモデル（テキスト＋画像入力）での効率改善が報告されている。実際のスループット改善幅はモデルやハードウェアによって異なるが、ワークロードによっては無視できない差が出る。 既存APIとの互換性は完全維持 「書き直した」と聞くと移行コストを心配するかもしれないが、OpenAI互換API（/v1/chat/completions等）はそのまま使える。既存の呼び出しコードを変更せずにアップグレードできる点は、本番運用者にとってありがたい設計判断だ。 実務への影響——日本のエンジニアが押さえるべきポイント 1. 自前LLM基盤を持ちたい組織には追い風 API料金を気にせずLLMを内部活用したい、データをクラウドに出したくない、という組織でvLLMを使っているケースが国内でも増えている。MRV2のモジュール性向上は、独自の最適化チューニングやカスタムモデルの組み込みをしやすくする。特に金融・医療・官公庁のような情報管理が厳しい業種での採用障壁が下がる。 2. マルチモーダル対応の本番利用が現実に テキストだけでなく画像も扱えるマルチモーダルモデル（LLaVA系・Qwen-VL系等）の推論効率が上がったことで、帳票OCR・製品画像解析・マニュアル読み取りといった業務ユースケースへの本番適用が実用段階に近づいた。 3. ハードウェア選択肢が広がる NVIDIA一択だった推論基盤の選択肢が、今後は広がる可能性がある。国内でもAMD InstinctやIntel Gaudi2を検討している組織があるが、vLLMのバックエンド抽象化が進むことでエコシステム全体の成熟が加速する。 今すぐ使えるアクション pip install vllm でMRV2ベースの最新版を取得し、手持ちのモデルでパフォーマンスを比較する OpenAI SDK互換なので、既存のLangChainやLlamaIndexのコードはそのまま接続できる vllm serve <model_name> --api-key token-abc123 でローカルAPIサーバが立ち上がる。まずここから試せ 筆者の見解 vLLMのMRV2リリースは「地味だけど超重要」なアップデートだ。派手な新機能発表ではないが、コアの再設計というのは相当な決断で、それをやりきったことは素直に評価したい。 LLM推論基盤としてvLLMの地位はほぼ揺るぎない。TGI（Text Generation Inference）やTriton Inference Serverといった競合もあるが、エコシステムの厚さと開発速度ではvLLMが抜けている。今回のMRV2でその差がさらに開いた印象がある。 ただ、日本のIT現場を見ていると、「とりあえずAzure OpenAI ServiceかAWS Bedrockに頼む」という流れが圧倒的で、自前推論基盤の構築に踏み込んでいる組織はまだ少ない。コスト・制御・カスタマイズの観点から、中長期的には自前基盤を持つ価値は確実にある。vLLMはそのための現実的な選択肢として、もっと真剣に評価されるべきだ。 もうひとつ言いたいのは、「オープンソースのLLM推論エンジンがここまで成熟した」という事実の重さだ。2年前は「GPT-4に追いつくにはどれくらいかかるか」という話をしていたのが、今やオープンモデルを本番スケールで動かすインフラが当たり前のように整っている。仕組みを作れる人間が少数いれば、あとはAIが回す時代はもうすぐそこまで来ている。乗り遅れている日本企業は、本当にそろそろ本気を出してほしい。 出典: この記事は vLLM Model Runner V2 (MRV2): A Ground-Up Reimplementation of the Open Source Inference Engine の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

コード生成プラットフォームとして知られるReplitが、Agent 4を正式リリースした。従来比10倍の処理速度と、複数のAIエージェントが役割を分担して協調動作する「マルチエージェントワークフロー」が目玉だ。投資家の評価も急上昇しており、わずか半年でバリュエーションが30億ドルから90億ドルへと3倍に膨らんでいる。 Agent 4が変えること——「副操縦士」から「自律艦隊」へ これまでのAIコーディングツールの多くは、いわゆる「副操縦士（Copilot）モデル」だった。人間がコードを書き、AIがその場でサジェストする。確認のたびに人間が承認する構造だ。 Agent 4が提示するのはその先にある設計思想——目的を伝えれば複数のエージェントが自律的に分担・完遂する、という自律艦隊モデルだ。 役割分担の自動化: 設計・実装・テスト・デプロイといった工程を、専用エージェントがそれぞれ並列で担当 10倍の処理速度: 単一エージェントのボトルネックをマルチ化で解消。実際の開発時間を劇的に短縮 コンテキスト共有: エージェント間がタスク状態を共有し、手戻りや重複作業を削減 これはコード補完ツールの延長線上にある話ではない。ソフトウェア開発プロセスそのものをエージェントに委ねるパラダイムシフトだ。 なぜいまこのタイミングか マルチエージェント協調が実用レベルに達した背景には、LLMの推論コスト低下とコンテキストウィンドウの大幅拡張がある。2025年以降、各社の基盤モデルが長大なコードベースを一度に扱えるようになり、「エージェントをたくさん立ててタスクを振る」ことが経済的に成立するようになった。 Replitはその波に乗り、ブラウザベースのIDE環境という強みを活かして、インフラ構築なしに即使えるマルチエージェント環境を一般ユーザーに届けた。スタートアップや個人開発者がターゲットであることも明確だ。 実務への影響——日本のエンジニア・IT管理者は何をすべきか プロトタイピングコストが激減する Agent 4のようなツールは、アイデア検証フェーズのコストを桁違いに下げる。「ちょっと試してみる」のハードルが下がるため、社内PoC（概念実証）を量産できるチームが圧倒的に強くなる。 チーム構成の見直しを今すぐ始めよ エージェントが実装・テスト・デプロイを自動化するとなると、今までの「人数×工数」で見積もる開発モデルは崩壊する。少数の「仕組みを作れる人間」が大量のエージェントを指揮する構造が現実になりつつある。 ガバナンスの設計を先に考えろ マルチエージェントが自律的に動くということは、何をどこまで自動化するかの設計責任が人間に残るということでもある。特にセキュリティ・コンプライアンス要件が厳しい日本企業では、「エージェントがやっていい範囲」の定義を先に整備しておく必要がある。 筆者の見解 ReplitのAgent 4、方向性はド正解だと思う。「複数エージェントが協調して自律的にタスクをこなす」——これこそがAIエージェントの本質的な進化の方向だ。 AIコーディングの分野はいま各社が激しく競っていて、マルチエージェント協調という設計思想自体は他のツールでも実現されつつある。Replitが「10倍速」と言うとき、何と比べているのかは要確認だ。ベンチマークの定義次第で数字は大きくも小さくもなる。 それよりも気になるのはバリュエーションの急膨張だ。半年で3倍というのは投資家の期待値であって、製品実力ではない。生成AI界隈の資金流入は活況だが、プロダクトの実力と投資家の評価額を混同しないことが重要だ。Replitのプロダクト自体は悪くないが、90億ドルという数字は少し前のめりに見える。 日本企業へのメッセージとしては、「Replitを使え」よりも「マルチエージェントの設計思想を学べ」の方が重要だ。ツールは何でもいい。ゴールを渡したら自律的に動くエージェント群をどう設計・管理するか——この問いに答えられる組織が、3年後に圧倒的な差をつける。 AIエージェントの進化は加速している。特定のツールの体験だけで「AIはまだ使えない」と判断してしまうのはもったいない。自分に合ったツールを見つけて、実際に使って成果を出す経験を積むことが、情報を追いかけるよりもずっと価値がある。 出典: この記事は Replit Agent 4 Delivers 10x Speed with Multi-Agent Cooperative Workflows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

アリババのQwenチームが2026年3月末に公開した「Qwen3.5-Omni」は、テキスト・画像・音声・動画を単一のパイプラインでネイティブ処理する「真のオムニモーダルモデル」だ。215項目の音声・視聴覚ベンチマークでSOTA（最先端）を達成し、Googleのフラッグシップ「Gemini 3.1 Pro」を音声理解の複数カテゴリで上回ったと発表された。日本のエンジニアにとっても無視できないリリースである。 Thinker-Talkerアーキテクチャとは何か 従来のマルチモーダルモデルの多くは「テキストLLMにWhisperなどの外部エンコーダをくっつけた」構成だった。要するに継ぎ接ぎだ。Qwen3.5-Omniはその設計を根本から変えている。 中核はThinkerとTalkerの2コンポーネントからなる統合アーキテクチャ。Thinkerは思考・推論を担い、Talkerはリアルタイムの音声応答を生成する。両者を結ぶのがHybrid-Attention MoE（Mixture of Experts）で、モダリティ（入力種別）ごとにどのエキスパートパラメータを使うかを動的に切り替える。 特筆すべきはAudio Transformer（AuT）エンコーダが1億時間以上の視聴覚データで事前学習されている点だ。人間の「聞いて見て理解する」感覚に近い時系列・音響的なニュアンスをモデルが持つことになる。 スペックのハイライト コンテキスト長: 256kトークン（連続音声10時間超、720p動画400秒超に対応） 音声認識対応言語: 113言語 ベンチマーク: 一般音声理解・推論・認識・翻訳でGemini 3.1 Proを超えたと発表 ラインナップ: Plus（高精度推論）/ Flash（低レイテンシ・高スループット）/ Light（軽量・省コスト）の3段構成 「Audio-Visual Vibe Coding」という新概念 今回のリリースで特に目を引いたのが「Audio-Visual Vibe Coding」という機能だ。動画を見せながら音声で「ここのUIを直して」と指示するだけで、モデルがコードを生成するというもの。テキストと動画と音声を同時に文脈として保持できるネイティブマルチモーダルだからこそ実現できるユースケースであり、従来のCopilotのような「テキスト補完の延長」とは一線を画す。 実務への影響——日本のエンジニア・IT管理者に何が変わるか 1. 議事録・会議解析の精度が跳ね上がる 音声認識で113言語対応、かつ映像も同時処理できるとなれば、Zoom・Teams録画をまるごと投げ込んで「誰がどの資料を見ながら何を言ったか」を構造化するワークフローが現実的になる。日本語対応品質の実測は必須だが、ASR系ベンチマークでの強さは期待を持たせる。 2. ローカルデプロイの選択肢として Qwenシリーズは従来からオープンウェイトモデルの公開が積極的だ。Qwen3.5-Omniも段階的にモデルウェイトの公開が見込まれる。セキュリティポリシーの都合でクラウドAPIを使えないシステムでも、ローカルで動かせる可能性がある。Lightエディションはその筆頭候補だ。 3. 競合圧力がAPIコストを下げる Geminiに対して性能で並んだあるいは超えたと主張するモデルが出てくると、OpenAI・Googleはプライシングで対抗せざるを得ない。最終的にエンドユーザー側のAPIコストが下がる恩恵は計り知れない。 筆者の見解 正直に言う。中国勢のLLMはローカルモデルのコスパで以前から群を抜いていたし、Qwen3.5-Omniはその文脈の延長線上にある。215個のSOTAとか言われても「ベンチマークは自己申告」という skepticism は必要だし、実際に日本語環境で動かして初めて評価できる話だ。 ただ、Thinker-Talkerアーキテクチャの設計思想は本物だと思う。テキストに後付けで音声エンコーダをくっつけたモデルと、最初から音声・映像・テキストを統合設計したモデルは、コンテキスト理解の質が根本から違う。「継ぎ接ぎより一体設計」という方向性は正しい。 Geminiとの比較についてはベンチマーク上の数値は確認できるが、画像生成以外の実務タスクでの性能差がどの程度なのかという点が気になる。さらに言えば、本当に評価したいのは主要なクローズドモデルとの直接比較だが、そこへの言及がないのが物足りない。 とはいえ、「アリババが本気のマルチモーダルを出してきた」という事実は重い。日本企業がまだOpenAI一辺倒で動いている間に、選択肢は急速に広がっている。情報を追い続けるより実際に使って見極めるべきフェーズだ。Flash版でもいいから動かしてみてほしい。 出典: この記事は Alibaba Qwen Team Releases Qwen3.5-Omni: A Native Multimodal Model for Text, Audio, Video, and Realtime Interaction の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GDC 2026（ゲーム開発者会議）にて、MicrosoftはWindowsおよびXboxのゲーム開発者向けに複数のツール強化を発表した。ロード時間短縮・シェーダー配信最適化・アセットパイプライン改善という3本柱で、次世代Xbox「Helix」に向けた開発者エコシステムの整備が本格化している。 発表内容：3つの柱 1. Zstandard（zstd）圧縮サポート WindowsのゲームパッケージングにZstandard圧縮が正式対応した。Zstdはオープンソースの高速圧縮アルゴリズムで、既にChromeやLinuxカーネル、Meta社内インフラ等で広く採用されている実績ある技術だ。従来のzlib系と比べてデコード速度が大幅に速く、ゲームのロード時間短縮に直結する。Xbox GDKを通じてPC・Xbox双方に適用可能なため、一度の対応で両プラットフォームの体験向上が期待できる。 2. Game Asset Conditioning Library（GACL） ゲームアセット（テクスチャ・メッシュ等）をターゲットプラットフォームに最適化された形式に変換するライブラリが提供される。ビルドパイプラインに組み込むことで、プラットフォームごとの手動最適化作業を自動化できる。特にPC/Xboxのマルチターゲット開発において、アセット変換の工数削減効果は大きい。 3. Advanced Shader Delivery の全開発者解放 これまで一部パートナー限定だったAdvanced Shader Deliveryがすべての開発者に開放された。Direct Storage APIと組み合わせることで、ゲーム起動時のシェーダーコンパイル待ちを大幅に削減できる機能だ。「最初の起動が遅い」という長年のDirectX系ゲームの課題に、ようやく本格的な解決策が普及段階に入った。 なぜこれが重要か これらの発表の真の意味は、Xbox GDKを軸としたPC/Xbox統合開発基盤の強化にある。次世代Xbox「Helix」のリリースを控え、Microsoftは「1つのコードベースで両プラットフォームに最適化されたゲームが作れる環境」の整備を急いでいる。 日本のゲーム開発会社にとっても無縁ではない。国内の中堅スタジオがPC/Xboxのマルチ展開を検討する際、これまでは「Xboxのシェアが低いから費用対効果が見えにくい」という判断が多かった。しかし、GDKによる共通化でPC対応の追加コストが下がるなら、Xbox対応のハードルも同時に下がるという構造だ。 実務への影響——エンジニア・IT管理者が押さえるべきポイント ゲームエンジニア向け Advanced Shader Deliveryは今すぐ検証すべき。既存タイトルのロード体験改善に直結するため、まず検証環境で効果を測定する価値がある GACLはCIパイプラインへの組み込みを前提に設計されている。既存のビルドフローを見直す良い機会 Zstd対応は圧縮率とデコード速度のバランスが優秀。パッケージサイズとロード時間のトレードオフを改めて検討したい 技術リード・プロデューサー向け PC版とXbox版の「別物扱い」から「同一コードの設定違い」への移行コストが下がりつつある。中長期のプラットフォーム戦略を見直す契機になる 次世代Xbox「Helix」向けの最適化は今から仕込んでおいたほうが楽になる 筆者の見解 正直に言うと、Microsoftのゲーム開発者向けの動きは久々にまともな方向性に見える。Advanced Shader Deliveryの全開放は「なんで今まで一部限定だったんだ」と言いたくなるが、それが解放されたのは素直に評価していい。 Zstandard対応も、「なぜ今さら」感はあるものの、業界標準のオープン技術をWindowsエコシステムに取り込んでいく姿勢は正しい。独自規格で囲い込むよりも、標準技術で生態系を広げるほうが長期的にはプラットフォームの競争力につながる。道のド真ん中を歩く判断だ。 ただ、冷静に見ると、これらはゲームエンジン側（UnrealやUnity）がとっくに対応してきた問題へのOS/SDK側のキャッチアップでもある。「Microsoftが先行して業界を引っ張っている」というよりは「ようやく現場の要求に追いついてきた」が正確な評価だろう。 次世代Xbox「Helix」に向けて、MicrosoftのゲームプラットフォームがWindowsと一体化していく流れは不可逆だと思う。PC Gamepassの拡大戦略と合わせて考えると、「Xboxというハードウェアブランド」より「Windowsというプラットフォームでゲームをやる体験」への移行を本気で進めているのが透けて見える。それは正しい判断だ。がんばれ、Microsoft。 出典: この記事は GDC 2026: Announcing new tools and platform updates for Windows PC game developers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きているのか 2026年4月15日、MozillaとGoogle ChromeがDigiCert Global Root（G1ルート）の信頼を廃止する。これに合わせて、Azure Instance Metadata Service（IMDS）がパブリックイシュアをMicrosoft G2-XSへ切り替える予定だ。 「証明書の話なんて自分には関係ない」と思ったエンジニア、ちょっと待ってほしい。IMDSはAzure VM上で動くほぼあらゆるアプリケーションが、インスタンス情報の取得・マネージドID認証・アテスティッドデータの検証に利用している基盤APIだ。ここが壊れると、VM上のワークロードが静かに死ぬ。 Azure IMDSとは何か Azure Instance Metadata Service（IMDS）は、Azure VM内から169.254.169.254（リンクローカルアドレス）にHTTPリクエストを投げることで、VMのメタデータや認証トークンを取得できる仕組みだ。マネージドIDを使ったAzureリソースへのアクセス（Key Vault・Storage・Azure OpenAIなど）は内部的にこのエンドポイントを叩いている。 Attestedデータ（改ざん検知用の署名付きメタデータ）を使う場合、クライアント側でその署名を検証するためにルート証明書が必要になる。ここに今回の変更が直撃する。 影響を受けるシステムの条件 以下に該当するシステムは今すぐ確認が必要だ： Attesd Data APIを使っている: ?format=json&api-version=2021-01-01などでAttestedデータを取得し、署名を検証しているコード カスタム証明書ストアを持つ環境: OSのシステムストアを使わず、独自のバンドル証明書でTLS検証しているアプリ（Pythonのcertifi、Javaの独自トラストストアなど） エアギャップ環境・オフライン証明書検証: インターネットに出られないVMでルート証明書を静的にバンドルしているケース 古いOSイメージ: 長期間アップデートしていないLinuxやWindowsイメージはルート証明書ストアが古い可能性がある 逆に、最新のOSイメージを使っており、システムのルートストアに依存し、Attesd Dataを署名検証していない場合は影響を受けない可能性が高い。 対処法 ステップ1：IMDSの利用状況を棚卸しする まずコードベースを検索して、169.254.169.254へのリクエストやManagedIdentityCredentialの利用箇所を洗い出す。Azure SDK（Python・Java・.NET・Go等）を使っている場合、SDKが内部でIMDSを使っているので認識していなくても影響する可能性がある。 ステップ2：Microsoft G2-XSルート証明書を追加する カスタム証明書ストアを使っている環境では、Microsoft G2-XSルート証明書を事前に追加しておく必要がある。Microsoft PKIリポジトリから最新のルート証明書を取得し、各環境のトラストストアに追加する。 ステップ3：4月15日前にテスト環境で動作確認 ステージング環境で新しいルート証明書のみを使う設定でアプリを動かし、TLSエラーが出ないことを確認しておく。本番切り替えは段階的に。 実務への影響 この変更が日本のIT現場に与える影響は意外と大きい。特に以下のシナリオで問題が出やすい： SIer・受託開発案件: 納品後に顧客がメンテナンスしていないVMが大量にある場合、OSのルートストアが更新されていない可能性がある。4月15日以降に突然「認証が通らない」という問い合わせが来るパターンが容易に想像できる。 Pythonアプリ: certifiパッケージは独自のCA束を持っており、pipでアップデートしていない環境では古いルートセットのままだ。pip install --upgrade certifiを今すぐ実行すること。 Java・Spring Bootアプリ: JVMに埋め込まれたトラストストアを使っている場合、JDKのバージョンによってはG2-XSが含まれていない可能性がある。最新のJDK/JREへのアップデートを検討すること。 コンテナ環境: Dockerイメージのベースレイヤーが古い場合も同様。FROM ubuntu:22.04のまま何ヶ月もapt updateしていないイメージは要注意。 筆者の見解 率直に言う。この手のルート証明書ローテーションで毎回思うのは、証明書の有効期限やルートの廃止を「知らなかった」で済ませる日本のエンジニアが多すぎるということだ。 セキュリティの話は嫌いだ。細かい話が多いし、関わる人間もなんか面倒くさい人が多い。でも技術的な興味はめちゃくちゃある。特にこういうインフラレベルの変更は、知らないと本当に静かに死ぬのがタチが悪い。HTTPエラーが出るとかならまだいい。Attesd Data検証のエラーは、ログに出るかどうかもアプリの実装次第で、気づかずにセキュリティ検証をスキップしているケースもある。 Azureのプラットフォームとしての信頼性は揺るがない、と今でも思っている。ただMicrosoftが「重大な変更」をTech Communityのブログポストで告知して終わり、というコミュニケーションスタイルはもう少し改善できるんじゃないかとは思う。Azure Portalのバナーで当該サブスクリプションに直接通知するとか、Service Healthで影響リソースを特定するとか、やりようはいくらでもあるはずだ。 ...

Microsoft（マイクロソフト）は、旧称Azure AI FoundryをMicrosoft Foundryとしてリブランドし、GPT-5・GPT-5-mini・GPT-5-nanoを含む新世代モデルへの移行戦略を公式ブログで詳細に公開した。単なるモデル追加ではなく、既存デプロイの自動アップグレードポリシーやPTU（Provisioned Throughput Units）への移行パスまで踏み込んだガイドラインであり、実際にAzure OpenAIを本番運用している組織は内容を把握しておく必要がある。 モデル自動アップグレードとは何か Microsoft Foundryでは、デプロイ設定において「自動アップグレード」を有効にすると、マイクロソフトが指定したタイミングで基盤モデルが新バージョンに切り替わる。たとえばGPT-4oデプロイが自動的にGPT-4o-latestへ更新されるような仕組みだ。 これはコスト効率やパフォーマンス向上の恩恵を自動的に受けられる反面、出力の一貫性が失われるリスクがある。プロンプトとモデルの組み合わせで動作を保証している本番システムでは、意図しないモデル切り替えが品質劣化や動作変化として現れることがある。 今回の公式ガイドラインでは、GPT-5世代への移行に際しても同様のポリシーが適用されることが明示され、ピン留め（特定バージョン固定） とアップグレードのどちらを選ぶかを明確に意識して運用設計する必要があることが改めて強調されている。 PTUとは——消費課金との違いと移行パス PTU（Provisioned Throughput Units）は、一定のスループットをあらかじめ確保する予約型の課金モデルだ。消費量に応じた従量課金（Pay-as-you-go）とは異なり、レスポンス遅延のばらつきが小さく、大量リクエストを安定的に処理できる。 今回の移行戦略では、GPT-5系モデルへの移行にあたり既存のPTUデプロイをどう扱うかのパスが示されている。具体的には： 現行PTUデプロイは廃止スケジュールに従い段階的に終了 新モデルへの移行は事前通知期間を設けてガイド GPT-5-mini・GPT-5-nanoはコスト最適化向けの軽量オプションとして位置付け GPT-5本体はハイエンドタスク向け、miniとnanoはコストを抑えつつ大量処理したいユースケース向けという棲み分けが明確になっている。 実務への影響 日本のエンジニア・IT管理者へ 今すぐ確認すべきこと： 自社のデプロイが自動アップグレード設定になっているか確認する — Azure PortalまたはREST APIでデプロイ設定を確認し、意図せず自動アップグレードが有効になっていないか点検する モデルの非推奨（Retirement）スケジュールを把握する — Microsoft Foundryには各モデルのRetirementページがある。把握していないとある日突然APIが動かなくなる 本番とステージングでモデルバージョンを揃える — ピン留め運用にしているつもりでも環境間でバージョンがずれているケースがある PTU契約中の企業は移行パスを早めに確認する — 特に年間コミットメントで予約しているケースは、GPT-5世代へのPTU移行タイミングの見積もりが必要になる コスト観点での実務ヒント： GPT-5-nanoはトークン単価が大幅に安くなると予想される。分類・要約・フィルタリングなど「重い判断は不要だが大量処理したい」タスクをnanoに切り出す設計を検討する価値がある。 筆者の見解 正直に言う。GPT-5が出るのは間違いなく重要なマイルストーンだ。でも今回の発表で一番注目すべきは、モデルのスペックではなく「移行管理の複雑さが上がり続けている」という現実だと思っている。 モデルが半年〜1年周期で世代交代し、PTUの予約スキームも更新され、プロンプトの動作保証はモデルバージョンに依存する——これを全部自社でハンドリングしながら本番運用し続けるのは、正直かなりしんどい。 そして、ここが核心だが、マイクロソフトは「最も賢いAIを作る競争」では今のところ後れを取っている。GPT-5がどこまで他社の最新モデルに迫れるかはまだわからない。だから筆者が推している構成は変わらない——Microsoft Foundry基盤の上でタスクに最適なモデルを動かすというアーキテクチャだ。Foundry経由でAnthropicモデルも使えるようになっている今、Azureを捨てる必要はない。プラットフォームはMicrosoftのまま、頭脳を選ぶ自由を使えばいい。 PTU移行についてはコスト最適化の観点でガンガン活用すべきだが、特定モデルへの深い依存は避ける設計を心がけたほうがいい。今後も移行は繰り返される。モデルをすぐ交換できる疎結合なアーキテクチャが、長期的には正解だ。 がんばれマイクロソフト。GPT-5で巻き返してくれることを本当に期待している。この批評が「古い批評」になる日を待っている。 出典: この記事は Model Upgrade and Migration Strategy for Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Entra IDに新たなGAアップデートが届いた。「External Multifactor Authentication（外部MFA）」が正式リリースとなり、組織が現在使っているサードパーティMFAプロバイダーをそのまま活かしながら、Entraの条件付きアクセスポリシーに準拠できるようになった。ゼロトラスト移行を検討している日本企業にとって、これは無視できない選択肢だ。 外部MFAとは何か Microsoft Entra IDの「外部MFA（External Multifactor Authentication）」は、Entra ID内蔵のMFA（Microsoft Authenticatorなど）ではなく、DuoやOkta、RSA SecurIDといったサードパーティのMFAソリューションを使いながら、Entraの多要素認証要件を満たせる仕組みだ。 従来は「外部認証方式（External Authentication Methods）」という名称だったが、今回のGA昇格にあわせて機能が拡充・整理された。 仕組みとしては、条件付きアクセスポリシーで「MFA必須」と設定した場合でも、外部プロバイダーによる認証が完了していれば要件を満たしたものとして扱われる。Entra IDが発行するトークンに対して、外部MFAの完了を示すクレームが付与される形だ。 同時に押さえておきたい2026年3月のアップデート群 今回のリリースノートには外部MFAのGA以外にも注目すべき動きがある。 パスキー同期がGA FIDO2ベースの同期パスキー（Synced Passkeys）がGAとなった。iCloudキーチェーンや1Passwordなどのサードパーティパスキープロバイダーに保存したパスキーを、複数デバイス間で同期しながらEntra IDの認証に使えるようになった。デバイス紐付けパスキーと同期パスキーは、管理者がポリシーで使い分けを制御できる。 Entraバックアップ＆リカバリーがPublic Preview 誤操作やセキュリティインシデントによるテナント設定の破損を自動復元する「Entra Backup and Recovery」がPublic Previewに入った。ユーザー・グループ・アプリ・条件付きアクセスポリシーなどの重要オブジェクトを日次バックアップ（P1/P2ライセンスで5日間保持）し、差分レポートと復元ジョブで元に戻せる。 Entra Kerberos によるハイブリッド参加がPublic Preview Entra Connectの同期やAD FSを待たずに、プロビジョニング時点でWindowsデバイスをすぐにHybrid Entra Joinできる新機能。レガシーなフェデレーション依存から脱却する道筋が見えてきた。 実務への影響 日本の大企業・官公庁では、RSAトークンやDuoをすでに全社展開しているケースが多い。これまでは「Entra IDに完全移行しないと条件付きアクセスのMFA要件を満たせない」というハードルが移行の足かせになっていた。外部MFAのGAにより、既存のMFA基盤を維持したまま段階的なゼロトラスト移行が現実的な選択肢になる。 エンジニア・IT管理者が今すぐ確認すべきこと： 現行MFAプロバイダーが外部MFAに対応しているか確認 — Microsoftの認定外部プロバイダーリストを確認し、現用製品がサポートされているか確認する 条件付きアクセスポリシーの見直し — 外部MFAを活用するには、ポリシー側で「認証強度（Authentication Strength）」の設定を正しく構成する必要がある パスキーの試験導入 — 同期パスキーGAを機に、パスワードレス認証のPoC開始を検討する好機だ Entraバックアップの有効化確認 — Public Previewだが即日オンにしておく価値はある。テナント設定を壊した後悔をする前に 筆者の見解 正直に言う。この外部MFA対応は、Microsoftが「現実を認めた」アップデートだ。 日本の大企業が「Entraに移行したいけどDuoの契約が3年残ってる」「RSAトークンを全社員に配り直す予算がない」という現実に直面しながらゼロトラスト移行を止めていた状況は、ずっとおかしかった。認証基盤の刷新を「一気にやらなければならない」という強迫観念が、むしろセキュリティ改善を遅らせてきた。 ゼロトラストの本質はネットワーク境界への依存をやめることだ。MFAプロバイダーがどこのベンダーかは本質じゃない。条件付きアクセスが正しく動いているか、Just-In-Timeで適切な認可が下りているか——そこが問われる。外部MFAはその実現を「今持っている資産で」始めるための現実解だ。 ただし、勘違いしてほしくないのは、これが「VPNとオンプレADを延命させるための言い訳」になってはダメだということ。外部MFAを使いながらも、中長期では認証基盤をEntra IDに集約していく方向性は変えるべきではない。移行の入口として使うのか、現状維持の口実にするのかで、3年後の姿が全然違ってくる。 Entraバックアップの話は別で純粋に嬉しい。テナント設定を管理コンソールで誰かが誤操作してぶっ壊す事故、一度でも経験した人なら分かるはず。「神頼みの手動復元」から「定期スナップショットからの差分復元」に変わるのは、運用品質の話として本当に重要だ。Public Previewとはいえ今すぐ有効化しておくべきだと思う。 Microsoftへの辛口コメントも続けるが、このEntraまわりのアップデートの着実さは評価している。エージェントの管制塔としてのEntra IDという方向性は正しい。がんばれマイクロソフト。 出典: この記事は External Multifactor Authentication (External MFA) Now Generally Available in Microsoft Entra の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

音声でAIと自然にやり取りするリアルタイムアプリ開発が、ついに「本番向け」のステージに入った。MicrosoftがAzure OpenAI GPT Realtime APIの正式GA（一般提供）を発表し、これまでプレビューで試してきた開発者には移行の期限が迫っている。2026年4月30日——それがプレビュー版の廃止日だ。 GPT Realtime API GAで何が変わるのか 今回のGA移行で変わるポイントは大きく4つある。 SDKの差し替え: MicrosoftがプレビューSDKとして独自にリリースしていたものはGAプロトコル非対応。OpenAI公式のSDK（openai-node、openai-python、openai-dotnet等）への移行が必須 エンドポイントURLの変更: /openai/v1/ 形式に統一。2025-04-01-preview のようなAPIバージョン指定はもう含めない WebRTCエンドポイントの更新: ブラウザベースのリアルタイム音声を使っている場合、エフェメラルキー発行エンドポイント（POST /openai/v1/realtime/client_secrets）と接続URL（/openai/v1/realtime/calls）が変わる session.updateイベントの統合: 音声会話（realtime）とリアルタイム文字起こし（transcription）が同一イベントに統合され、typeフィールドで区別するようになった 逆に変わらないことも把握しておきたい。コア機能・音声フォーマットのサポート・モデル能力は引き継がれる。移行コストは想定より小さく、Microsoftは「ほとんどのケースで30〜60分」と明言している。 移行の前提条件を確認する 移行前に以下を確認しておくこと。 プレビュー（Beta）プロトコルを使った既存のAzure OpenAIリソースとデプロイがあること Azureポータルへのアクセス権限（OpenAIリソース管理が可能なロール） SDK依存関係を更新できる開発環境 本番デプロイ前に検証できるテスト環境 現在の実装がWebSocketかWebRTCかの把握 特に注意したいのが**.NET SDK**だ。OpenAI .NET v2.9.0以降でないとGAプロトコルに対応していない。バージョンを固定していたプロジェクトでは要確認。 日本の実務への影響 リアルタイム音声AIは、コールセンター自動化・音声インタフェース付きの業務アプリ・議事録リアルタイム生成など、日本の現場でもニーズが高い領域だ。これがGAになったことで、PoC止まりだったプロジェクトが本番検討のテーブルに乗ってくる。 エンジニア・IT管理者が明日から使える実践ポイント： 既存プレビューアプリの棚卸しをすぐやれ: 4月30日まで時間がない。社内でRealtime APIを試験導入しているチームがあれば、今週中にリストアップして移行計画を立てる 新規開発はGAのクイックスタートから始める: 移行ガイドではなく公式のRealtime API Quickstartが起点。プレビューの癖を引きずらない WebRTCを使っているプロジェクトは特に注意: エンドポイントが2か所変わるので、ブラウザ側とサーバー側で漏れなくテストすること OpenAI公式SDKのバージョン管理を見直す: MicrosoftのプレビューSDKとOpenAI公式SDKが混在しているプロジェクトは、依存関係の整理から始める 筆者の見解 Realtime APIのGAそのものは素直に評価できる。音声AIが「本番で使える」フェーズに入ったのは意義があるし、Azure基盤の上でこれが動くというのは、セキュリティ・コンプライアンス要件の厳しい日本の大企業にとってはむしろ歓迎だろう。 ただ、今回の移行で一つ気になることがある。MicrosoftのプレビューSDKはGAプロトコル非対応、つまりOpenAI公式SDKを使えという話だ。これ、地味にMicrosoftの「自社SDKのリードを取れない」状況を象徴していないか。AzureでOpenAIモデルを使うのにOpenAIのSDKを使えという構造は、Microsoftがプラットフォームとして機能しているのかAPIプロキシとして機能しているのか、少し曖昧に見える。 個人的にはMicrosoft Foundry経由でモデルを選んで動かすという方向性が正しいと思っている。Azureの基盤・認証・ガバナンスはそのまま使いながら、動かすAIモデルは状況に応じて選ぶ。Realtime APIが重要なユースケースではGPT-4oを使えばいい。ただし他のユースケースで別のモデルが優れているなら、そちらを選べばいい。Azureを捨てる必要はない。その上で動くAIを選ぶ自由を使えばいいだけだ。 とにかく今すべきことは明確で、4月30日までに移行を完了させること。30〜60分で終わる作業をギリギリまで放置して障害を起こすのは笑えない。 出典: この記事は Azure OpenAI GPT Realtime API is Now Generally Available の内容をもとに、筆者の見解を加えて独自に執筆したものです。