Tech News JP

コード検索といえば長らく正規表現（regex）の独壇場だった。grep、そして高速化したripgrep（rg）——その系譜に真っ向から「オワコン宣言」を突きつけるツールが登場し、Hacker Newsで話題になっている。その名はfff（Fast File Finder）。作者はDmitro Kovalenkoで、「正規表現なし・ripgrepより最大100倍速」を謳う。 ffsとは何が違うのか fff最大の特徴は永続インデックス（Persistent Index）だ。ripgrepはクエリのたびにファイルシステムを全走査する。高速ではあるが、大規模リポジトリになるほどレイテンシが積み重なる。fffは非同期バックグラウンド処理でインデックスを構築・更新し、2回目以降の検索を劇的に高速化する。ベンチマークによればripgrepが6秒前後かかるクエリをほぼ瞬時に返せるという。 もう一つの柱がSmith-Watermanスコアリングだ。これはもともとDNA配列のローカルアラインメントに使われるバイオインフォマティクスのアルゴリズム。コード検索への応用により、タイポや文字の欠落があっても意図したシンボルを高精度で見つけられる。「useEfectと打ってもuseEffectがヒットする」ようなファジーマッチを、正規表現に頼らず実現している。 AIエージェントこそが本命ターゲット 重要なのは、このツールがAI エージェント向けに最適化されている点だ。リポジトリ名もfff.nvimで、Neovimとのインテグレーションを主眼に置いているが、README にはClaude Code・Codex・OpenCodeといったAIコーディングエージェントとの連携を明示している。 AIエージェントがコードを読む際のボトルネックは2つ——時間とトークン数だ。fffは「平均10%の実行時間削減・17%のトークン削減」をfff-aiモードで実現すると主張する。アクセス頻度、Gitステータス、ファイルサイズなどを加味したスマートなソートで、エージェントが最初に見るべきファイルを上位に並べる。 つまりfff は「人間が使う検索ツール」ではなく、「AIが使う検索ツール」として設計されている。この発想の転換が従来の類似ツールと一線を画す。 実務への影響 エンジニアへのヒント 現在のワークフロー評価から始める: rg/fzf で体感速度に不満があるなら試す価値あり。特にモノリポや大規模リポジトリで効果が大きい Neovim利用者は即導入候補: fff.nvimとして提供されており、Neovimとのインテグレーションが最も洗練されている AIエージェントの速度チューニングとして: Claude Codeなどのエージェントがファイル探索に詰まっている場合、fff連携でトークン・時間を節約できる可能性がある IT管理者・アーキテクトへのヒント コード検索の「永続インデックス」はセキュリティ上の注意点も伴う。インデックスファイルの保存先と権限管理は運用前に設計すること ripgrepはリアルタイム性（インデックス不要で最新状態を即座に検索）が強み。fffは繰り返し検索の高速化が強み。用途によって使い分けが現実的 筆者の見解 正直に言う。このツールが今すぐripgrepを置き換えるかといえば、そうは思わない。Hacker Newsのコメント欄でも「34倍という数字はどのベンチマーク条件?」「インデックスの鮮度保証は?」という疑問が相次いでいる。ベンチマーク競争は往々にして恣意的な条件設定になりがちで、鵜呑みにするのは危険だ。 ただ、着眼点は完全に正しい。 AIエージェントが自律的にコードを読み・修正し・検証するループを回す時代において、「ファイル検索のコスト」は無視できない摩擦になっている。人間なら多少遅くても慣れで済む話だが、エージェントが1日に数百回クエリを投げるなら話が違う。検索の遅延とトークン消費は、ハーネスループ全体のスループットに直撃する。 fff が主張する「AIエージェントのためのファイル検索」という方向性は、次の1〜2年で確実に主流になる。バイオインフォマティクスのアルゴリズムをコード検索に応用するという発想も面白い——シンボル名のファジーマッチはDNA配列マッチングと構造的に似ているという観察は鋭い。 ripgrepは当分死なない。正規表現は強力すぎる。だが「正規表現しか選択肢がない」という状況は確実に変わる。fffが標準になるかはともかく、この方向性をウォッチしておくことは必須だ。Claude Codeを使い倒している立場からも、エージェントの検索効率を上げる仕組みには今後もアンテナを張り続けたい。 出典: この記事は The future of code search is not regex – 100x faster than ripgrep の内容をもとに、筆者の見解を加えて独自に執筆したものです。

RAGは「それなりに動く」だけだった ドキュメント検索にRAG（Retrieval-Augmented Generation）を使っている開発チームは多い。でも正直なところ、RAGは「クエリに似たチャンクを引っ張ってくる」だけで、答えが複数ページにまたがっていたり、正確な構文が必要だったりすると途端に使い物にならなくなる。 ドキュメントツール「Mintlify」のエンジニアリングチームは、そのRAGの限界を正面から認めて捨てた。そして代わりにバーチャルファイルシステム（ChromaFs）を構築した。このアプローチがAIエージェント設計の考え方として非常に示唆に富んでいる。 エージェントはファイルシステムで育つ そもそも、なぜファイルシステムなのか。 AIエージェントが自律的にドキュメントを探索するとき、grep、cat、ls、find というUNIXの基本コマンドさえあれば事足りる。各ドキュメントページをファイル、各セクションをディレクトリとして扱えば、エージェントは自分で構造を辿りながら必要な情報を探し当てられる。これはRAGの「クエリ→チャンク返却」という受動的な仕組みとは根本的に違う。 エージェントが能動的に探索する——これがポイントだ。 本物のサンドボックスでは使い物にならなかった 「じゃあ本物のコンテナ環境を与えればいいじゃないか」と思うかもしれない。Mintlifyも最初はそのアプローチを試みた。Daytonaなどのサンドボックスを使ってGitHubリポジトリをクローンする方式だ。 しかし結果は散々だった。 P90起動時間：約46秒（ユーザーがローディングスピナーを眺め続ける時間） コスト試算：年間7万ドル超（月85万会話 × 1vCPU/2GiB RAM × 5分セッションの概算） フロントエンドで「ユーザーが待っている」状況で46秒は死刑宣告に等しい。インフラコストも非現実的だ。 ChromaFs：シェルの幻想を作り出す Mintlifyが取った解決策は「本物のファイルシステムは要らない、シェルの幻想を作ればいい」という発想の転換だった。 ChromaFsの仕組みはシンプルかつ巧妙だ： 既存のChromaDBを再利用: RAG向けにすでにインデックス・チャンク化されていたドキュメントDBをそのまま活用 just-bash（Vercel Labs製）上に構築: TypeScriptでbashを再実装したライブラリ。IFileSystemインターフェースをプラガブルに提供 UNIXコマンドをDBクエリに変換: grep → ChromaDBのメタデータクエリ、ls → インメモリのディレクトリツリー参照 ファイルツリーはgzip圧縮JSONで保持: __path_tree__という特殊ドキュメントとしてChromaに格納し、初期化時に展開 結果として達成したのが以下のパフォーマンス改善だ： 指標 サンドボックス方式 ChromaFs P90起動時間 約46秒 約100ms 1会話あたりコスト 約$0.0137 $0（DB再利用） 検索方式 ディスクスキャン DBメタデータクエリ 46秒が100ミリ秒に。460倍の高速化だ。 実務への影響——日本のエンジニアが今日から考えるべきこと 1. RAGの「とりあえず動く」で止まっていないか確認する 社内ドキュメント検索やナレッジベースにRAGを導入している企業は多い。しかし「チャンク返却」モデルの限界——複数ページにまたがる情報、正確な構文の取得——に直面しているなら、このアーキテクチャ転換は真剣に検討する価値がある。 2. エージェントに「探索する手段」を与える設計を意識する RAGは「教える」アーキテクチャ、ファイルシステムは「探索させる」アーキテクチャだ。AIエージェントに自律的な行動を求めるなら、ツールセット（grep/cat/ls相当の操作）を与える設計が本質的に合っている。 3. 既存インフラの再利用を先に考える Mintlifyの肝は「新しいインフラを作らず、すでにあるChromaDBを賢く再利用した」点だ。コスト削減の多くは新規投資ではなく既存資産の見直しから生まれる。 4. ユーザー体験が要件を決める 「46秒待てますか？」という問いに「待てない」と判断したからこそ、この設計変更が生まれた。技術選択はユーザー体験の要件から逆算すべきで、技術の都合をユーザーに押しつけてはいけない。 筆者の見解 この事例、正直かなりアツい。 いま一番面白いのはハーネスループの設計——エージェントが自律的に判断・実行・検証を繰り返す仕組みを作ること——なのだが、そのループを成立させるには「エージェントが探索できる環境」が不可欠だ。ChromaFsはまさにそれを実現している。 RAGは所詮「人間がクエリを投げてチャンクが返ってくる」受動的な仕組みで、エージェントが自律的にループを回す世界には根本的にミスマッチだ。Mintlifyはそれを正しく見抜いた。 「エージェントにはgrep、cat、ls、findで十分」という洞察も素晴らしい。複雑なツールチェーンを渡してエージェントを混乱させるより、UNIXの枯れた道具を仮想的に与えるほうが遥かにシンプルかつ強力——これは多くのエージェント設計にも応用できる考え方だ。 日本の現場でドキュメントAIを検討しているチームはいくつかいるだろうが、RAGを「とりあえず動く」で入れて満足しているところが大半だと思う。正直もったいない。技術的な優位性は「どう取ってくるか」ではなく「どう探索させるか」の設計にかかっている。ChromaFsのコード自体はオープンに公開されているので、まず読んで試してみることをガンガン勧める。 出典: この記事は We replaced RAG with a virtual filesystem for our AI documentation assistant の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIが2026年3月24日、AI動画生成アプリ「Sora」の終了を発表した。アプリは4月26日、APIは9月24日に順次シャットダウンされる。ChatGPT以来最も注目されたプロダクトが、わずか6ヶ月で幕を下ろした理由は、技術の失敗でも競合の圧力でもない。経済的物理法則だ。 計算してみれば一目瞭然の惨状 Cantor Fitzgeraldのアナリスト、Deepak Mathivananが試算した数字が衝撃的だ。 1本の10秒動画の生成コスト: 約1.30ドル（H100 GPU 4基で約40分） ピーク時の推定コスト: 最大1日1,500万ドル Soraアプリの生涯累計収益: わずか210万ドル（6ヶ月分、全プラットフォーム合計） テキスト生成との比率: AI動画はテキストの160倍のコストがかかる構造 WSJが報じた実際の日次バーンレートは「わずか」100万ドルだが、これはOpenAIがスロットリングや品質制限を積極的にかけた後の数字だ。つまり「使えないように抑制してこの数字」。使わせれば使わせるほど赤字が膨らむ設計だった。 OpenAIのSora責任者であるBill Peebles氏が2025年11月にX（旧Twitter）に投稿した一文が全てを物語っている。 「経済性は現在、完全に持続不可能だ」 テック企業のエグゼクティブが自社プロダクトについてこれほど正直に書いた文章は珍しい。 ユーザーは動画を一度見て、二度と戻らなかった コスト構造だけではない。ユーザー行動のデータも壊滅的だった。 a16zのアナリスト、Olivia Mooreが公表したデータによれば、Soraのday-30リテンションは1%。対してTikTokは32%だ。ユーザーは動画を生成して「すごい」と思い、一度見て、二度と戻らなかった。新しいユーザーを獲得すればするほど赤字が加速する、最悪のユニットエコノミクスだ。 Disneyとの10億ドル契約も電話一本で終わり ドラマは財務だけじゃない。OpenAIはSoraシャットダウンの発表1時間前まで、Disneyに何も知らせていなかったとWSJが報じた。10億ドルの提携交渉が進行中だったにもかかわらず。契約は正式調印に至らないまま、電話一本で終わった。 AI動画スタートアップへの波及 Soraの撤退は、業界全体への警告でもある。 企業 財務状況 Runway EBITDAマイナス1億5,500万ドル Pika 8,000万ドル調達に対し収益750万ドル Kling ARR 2億4,000万ドル（利益非公開） 業界で最も健全に見えるKlingですら、収益性を公表できていない。「AI動画で黒字化に成功した企業」は2026年現在、存在しない。 実務への影響 企業のAI動画活用を検討しているIT担当者へ： API提供元の財務健全性を確認せよ: 今後、コスト構造が持続不可能なAI動画APIが次々と終了・価格改定を迫られる可能性が高い。本番プロダクションへの組み込みは慎重に。 ユースケースを絞り込め: 「なんとなく使える」より「ここでしか使えない」価値のある場面に限定する。プロモ動画の試作・内部資料のビジュアライゼーションなど、低頻度・高付加価値な用途に留める。 コスト意識の更新が必要: テキスト系AIとは桁違いのコスト構造を持つ。「AIだから安いはず」という前提は動画では全く通用しない。 代替手段も並行評価: RunwayやKling、Pika等の競合サービスも同様の構造的問題を抱えている。特定サービスへの依存リスクを考慮したマルチベンダー戦略が必要。 筆者の見解 Soraの終了について「OpenAIがまたやらかした」という論調を見かけるが、個人的にはちょっと違う見方をしている。これはOpenAIの失敗というより、AI動画という業態そのものが2026年時点では成立しないという話だ。Runwayも、Pikaも、Klingも、全員が同じ物理法則の下にいる。OpenAIはたまたま最初に「無理です」と手を挙げただけで、むしろ正直だった。 面白いのは、この構造的問題がテキスト系AIとの対比で際立つことだ。テキスト生成はすでにコスト曲線が急降下しており、黒字化が視野に入りつつある。一方、動画は160倍のコスト差がある。半導体の進化がどれほど速くても、この差を埋めるのに相当な年数がかかる。 もう一つ気になるのは、Copilotとの構造的な類似だ。「すごいと思って試したけど、2回目はない」というリテンション1%のパターン。これはSoraに限らず、「新機能として提供されるが実用性が薄いAI体験」全般に共通する問題だ。Microsoftが散々やってきたことと同じ轍を、OpenAIも踏んだ。 AIで本当に価値を出せる領域は、「一発のすごい生成体験」ではなく、繰り返し使われるループの中に組み込まれた自動化だと改めて確信する。エージェントが自律的に判断・実行・検証を繰り返すハーネスループの設計こそが、今投資すべき場所だ。一回見て感動するだけのプロダクトに1500万ドル/日は、どう転んでも割に合わない。 出典: この記事は A $20/month user costs OpenAI $65 in compute. AI video is a money furnace の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

LinkedInを開いた瞬間、あなたのブラウザは静かにスキャンされている。インストールされている拡張機能、CPU数、メモリ量、画面解像度、タイムゾーン、バッテリー残量……。これはSFではなく、BleepingComputerが独自検証で確認した現在進行形の話だ。 何が起きているか 「BrowserGate」と名付けられたこの問題は、商業的LinkedInユーザーの団体「Fairlinked e.V.」が告発したもの。LinkedInはランダムなファイル名のJavaScriptをユーザーセッションに注入し、6,236個のブラウザ拡張機能の有無を検出しているという。 手法はシンプルかつ確立されたものだ。各拡張機能には固有のIDがあり、そのIDに紐づく静的リソース（画像やJSファイル）へのアクセスを試みることで、インストールされているかどうかを判定できる。Chrome DevToolsを開けば確認できるレベルの話なので、完全な「隠蔽」ではないが、一般ユーザーが気づくことはほぼない。 何のために使っているか 特に問題視されているのが競合製品の把握だ。LinkedInは自社の営業ツール（Sales Navigator等）と直接競合するApollo、Lusha、ZoomInfoを含む200以上の製品を監視対象に含めている。LinkedInはユーザーの氏名・企業・役職を把握しているため、「どの会社がどの競合ツールを使っているか」を高精度にマッピングできる。これは事実上、競合SaaSのカスタマーリストをユーザーのブラウザから無断で抜き取っているに等しい。 さらに収集されるデバイス情報（CPUコア数、メモリ容量、画面解像度、タイムゾーン、言語設定、バッテリー状態、オーディオ情報、ストレージ）は、組み合わせることでブラウザフィンガープリントを形成できる。これはCookieを削除しても追跡可能な識別手法だ。 BleepingComputerは競合ツール使用データの活用や第三者提供については独自検証できていない。ただ、Fairlinkedはこのデータが「利用規約違反ユーザーへの警告・制限に既に使われている」と主張している。 LinkedInの反論 LinkedInは拡張機能の検出自体は認めつつ、「メンバーのプライバシー保護とサイトの安定性のため」だと説明している。また告発者がコンテンツスクレイピング等によりアカウント制限を受けているとも述べており、報告書の信頼性を疑わせる姿勢を見せている。 とはいえ、拡張機能検出の対象には税務専門家向けツールや文法校正ツールも含まれており、「競合スクレイパーの検出」だけでは説明がつかない範囲の監視が行われていることは事実だ。 実務への影響 エンジニア・セキュリティ担当者へ 業務用PCでLinkedInを開く際のリスクを再認識する。インストールされている拡張機能から、社内で使用しているSaaSツールの種類が推測される可能性がある ブラウザプロファイルの分離を検討する。LinkedInなどSNS系は専用プロファイルで開き、業務用拡張機能との混在を避ける 社内ポリシーの見直し。「業務PCのブラウザ管理」にLinkedIn経由の情報漏洩リスクを追加すべきタイミングかもしれない フィンガープリンティング対策として、Privacy BadgerやuBlock Originといった拡張機能が有効だが、皮肉なことにそれらもLinkedInのスキャン対象に含まれている IT管理者へ 業務端末のブラウザ拡張機能管理は以前から重要だったが、この件はその理由に新たな側面を加えた。従来は「悪意ある拡張機能によるデータ漏洩」が主な懸念だったが、今後は「訪問先Webサービスによる拡張機能スキャン」も管理対象に含める必要がある。 筆者の見解 率直に言う。Microsoftへの失望が、またひとつ積み重なった。 LinkedInはMicrosoftが2016年に262億ドルで買収したサービスだ。そのLinkedInが、競合他社のユーザーリストをサイレントスキャンで構築し、違反者の摘発に使っているとしたら——これは「プライバシー保護のため」という説明とは到底相容れない。 セキュリティの文脈で言えば、このフィンガープリンティング手法は昔からあるし、技術的に「違法」とは言い切れない。LinkedInのTOS（利用規約）には収集に関する条項があるし、企業がユーザーのブラウザ環境を把握しようとするのは珍しいことでもない。 だがLinkedInはリアルアイデンティティと紐づいている点が決定的に異なる。Twitterやnoteでフィンガープリンティングされるのと、本名・所属会社・職種が紐づいた状態でフィンガープリンティングされるのでは、リスクの次元が違う。競合ツール使用状況のマッピングに至っては、もはや個人プライバシーを超えた企業競争上の情報収集と見るべきだ。 Copilotで散々やらかし、Recallで炎上し、そしてLinkedInでBrowserGate。Microsoftは「信頼されるテクノロジー企業」という看板をゆっくりと、しかし確実に外してきている。 対策としては、業務でLinkedInを使うならブラウザプロファイルを分離するのが現実的な一手。MicrosoftがEdgeとLinkedInを「統合」させていく方向に進むとすれば、その統合がどんな情報収集を内包するか——今後も目を離せない。 出典: この記事は LinkedIn secretely scans for 6,000+ Chrome extensions, collects data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11の強制アップデートに踏み切った。Windows 11 24H2以前のバージョンを使っているPCは、ユーザーの意思にかかわらず最新リリースへと自動移行させられる流れが始まっている。「また強制か」という声も上がりそうだが、背景と実務的な意味を整理しておこう。 何が起きているのか MicrosoftはWindows Updateを通じて、サポートライフサイクルの終わりが近いバージョンのユーザーを自動的に最新のWindows 11へ移行させる「強制アップグレード」を順次展開している。今回対象となるのはWindows 11の旧バージョンを継続利用しているPC群だ。 この施策自体は突然のことではなく、Microsoftが長年繰り返してきた「サポート終了前の強制移行」ポリシーの延長線上にある。Windows 10に対してもかつて同様の手法が使われた。仕組みとしてはWindows Update経由での自動適用であり、ユーザーが意図的にアップデートを延期していても、一定の猶予期間を過ぎると強制的に処理が走る。 対象と影響範囲 強制アップデートの対象は、現時点でWindows 11の旧バージョン（24H2より前のビルド）を使っているコンシューマー向けデバイスが中心とみられる。企業環境では、Intune・WSUS・Windows Update for Business などの管理ツールを使えばアップデートのタイミングをコントロールできる。完全にシャットアウトはできないが、猶予期間を稼ぐことは可能だ。 重要なのは「強制」とはいっても即日適用されるわけではなく、段階的なロールアウトが前提であるという点。Microsoftは通常、パッチの品質問題が報告された場合にロールアウトを一時停止するセーフガードを持っている（実際には機能しなかったケースもあるが）。 実務への影響——エンジニア・IT管理者はどう動くべきか コンシューマー環境（個人PC） に関しては、率直に言って受け入れるのが現実的だ。最新バージョンへの移行を遅らせるための手間と、セキュリティパッチを最新に保つメリットを比較すれば、後者のほうが圧倒的に合理的である。 企業・組織環境 では以下の点を確認しておきたい： Intuneの機能更新ポリシー（Feature Update Policy）を設定しているか確認する。 設定していない管理対象デバイスは強制アップデートの対象になりうる Windows Update for Business のターゲットバージョン設定を再確認する。 古い設定のまま放置しているケースが意外と多い アプリ互換性テストのサイクルを見直す。 強制アップグレードが走る前に、主要業務アプリが最新Windows 11で動くか確認しておくこと エンドユーザーへの事前周知。 「突然再起動が走った」「デスクトップが変わった」という問い合わせを減らすための先手を打つ WSUSを使っているオンプレ環境は別途設定確認が必要だが、いずれにせよ「Microsoftの管理下にある以上、最終的には移行は避けられない」という前提でロードマップを組むのが正解だ。 筆者の見解 正直なところ、Windowsを細かく追いかける意味がどんどん薄れている。強制アップデートへの反発はわかるが、そもそも「古いバージョンをいつまでも使い続けたい」という発想自体が時代に逆行している。 セキュリティの観点からは、むしろ強制してでも最新に保たせるMicrosoftの姿勢は正しい。問題は「すぐ当てたら壊れた」という報告が増えていて、アップデートの品質が安定しないこと。Microsoftはここに本気でコミットしてほしい。強制するならそれ相応の品質保証をセットで出すべきだ。 企業のIT担当者へ一言言わせてもらうと、「Windowsのアップデート管理をちゃんとやってない」会社がまだ多すぎる。IntuneもWSUSも設定しっぱなし・放置はいい加減やめろ。強制アップグレードで現場が混乱するのは、ツールを正しく使ってこなかった結果でもある。 Microsoftへの失望は正直尽きないが、Windowsのプラットフォームとしての強さは依然として現実だ。文句を言いながらも、きちんと管理しながら付き合っていくしかない。それが今の正しい判断だと思う。 出典: この記事は Microsoft begins force-updating users to the latest Windows 11 version の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「Windows 11が重くて動かないからLinuxに逃げる」——そのつもりで調べたら、乗り換え先のLinuxディストロの方が要件が高かった。そんな皮肉な事態が現実になりつつある。 何が起きたか ある人気Linuxディストロが最低システム要件を大幅に引き上げ、Microsoft が定めるWindows 11の最低要件（RAM 4GB・ストレージ 64GB・TPM 2.0など）を上回る水準に達した。「Linuxは古いマシンでも動く軽量OS」という長年のイメージが、少なくともメインストリームのデスクトップ向けディストロに限っては過去のものになりつつある。 なぜ要件が上がっているのか Linuxディストロの要件引き上げには、いくつかの技術的背景がある。 モダンUIフレームワークの重量化：GNOMEやKDEといったデスクトップ環境は、ここ数年でWaylandへの完全移行を進めつつあり、GPU支援・アニメーション・高DPI対応などが標準になった。これらはメモリとGPU性能を以前より要求する。 セキュリティ機能の強化：セキュアブート対応・カーネル整合性チェック・メモリ保護機能などが有効化されると、それなりのハードウェアが必要になる。 64ビット専用化：32ビットアーキテクチャのサポートが切られ、古い低スペックマシンがそもそも対象外になっている。 「Windowsが重いからLinux」という逃げ道はもう機能しない 日本のIT現場でも、「古いPCにLinuxを入れて延命する」という運用は一定数存在する。特に学校・中小企業・非営利団体では、予算制約からWindows 11非対応のPCを生かし続けようとするケースがある。しかし今回のような要件引き上げが続くと、その選択肢は急速に狭まる。 現実的な代替としては次の選択肢が残る： 軽量ディストロへの移行（Linux Mint XFCE、Lubuntu、MX Linuxなど）：デスクトップ向けフラグシップ版でなければ、まだ低スペック対応のものは存在する Chrome OS Flex：Googleが提供する古いPC向けOS。管理ツールも整備されており企業向けにも現実的 仮想デスクトップ（VDI/クラウドPC）への移行：クライアント側スペックを問わない設計にシフトする ただし、どの選択肢も「古いPCを無償で延命できる万能解」ではなく、それぞれにコストと管理負担が伴う点を理解しておく必要がある。 実務での活用ポイント PC延命計画を立てている場合は要件を再確認：「Linuxなら動く」前提で計画している組織は、対象ディストロの最新最低要件を必ず確認せよ IT資産管理でスペック情報を最新化：RAM・CPU・GPU情報がないと今後の移行判断が困難になる 軽量ディストロのLTSバージョンを選ぶことで、要件変化の頻度を下げられる Windows 365やAVD（Azure Virtual Desktop）の費用対効果を再試算：クライアント延命コストと比較して意外に合理的なケースが増えている 筆者の見解 Linuxが「弱者の避難所」であり続けられた時代は終わったと思っている。それ自体は悪いことではない。Linuxがデスクトップとして本気でWindows・macOSと勝負しようとした結果として、要件が上がるのは自然な進化だ。 ただ、「古いPC延命のためにLinux」という幻想を今も信じているIT担当者には、現実を直視してほしい。軽量ディストロを適切に運用するのは、素のWindowsより管理コストが高いことも多い。タダより高いものはない。 一方でWindowsについていえば、TPM 2.0要件や最低スペック制限でWindows 11に移行できないPCをMicrosoftが大量に生み出したのは事実で、そのツケをLinuxコミュニティに押し付けてきた構図もある。今回の話は、その「受け皿」も消えつつあるというシグナルでもある。 結局のところ、ハードウェアを更新するか、クラウドに逃げるか、使うのをやめるか——この3択が本当の選択肢だ。「OS乗り換えで延命」という第4の選択肢には、もはやあまり期待しない方がいい。 出典: この記事は A popular Linux distro now has higher system hardware requirements than Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米AIスタートアップPerplexityが、エージェント型AI機能「Perplexity Computer」を大幅強化した。Pro会員向けに提供されるこの機能、なんと米国連邦税申告書の自動作成と、税理士が作成した申告書のエラー検出まで対応するようになった。「税務はプロに任せるもの」という常識が、静かに崩れ始めている。 Perplexity Computerとは何か Perplexity Computerは、単なるQ&A型AIではなく、ユーザーの代わりに実際の「作業」を自律的にこなすエージェント型AIだ。ブラウザを操作したり、フォームを記入したり、複数ステップにわたるタスクを連続して実行できる。今回の税務対応では以下のことが可能になった： IRS申告書の下書き作成: 米国の連邦税申告書（Form 1040等）を自動でドラフト プロの申告書監査: 税理士・会計士が作成した申告書を読み込み、数千ドル（数十万円）規模のエラーや見落としを検出 節税機会の発見: 見逃しやすい控除や税優遇の適用漏れを指摘 Pro（月額20ドル）プランの機能として提供されており、アクセスしやすい価格設定も注目点だ。 なぜこれが重要か 税務申告は「専門家の領域」の代表格だった。法律知識、数値の正確性、最新の税制改正への対応——この3つが求められるため、一般人が自力でこなすには敷居が高く、税理士や会計士への依頼が常識だった。 だが今回のPerplexityの発表が示すのは、エージェント型AIが「知識×実行×検証」を自律ループで回せるようになったという事実だ。単に「答える」だけでなく、書類を読み込み、計算し、エラーを見つけ、修正案を提案する——これはまさに「仕事を代行する」AIだ。 税務という高度に規制された複雑な領域でこれが動くなら、他の専門職領域（法務書類、医療診断補助、財務分析）への展開も時間の問題だろう。 日本への示唆——直接適用は無理でも、流れは読め 現時点でこの機能は米国の税制（IRS）に特化しており、日本の確定申告や法人税申告には直接対応していない。しかし「対岸の火事」と思ったら大間違いだ。 日本のe-Tax・マイナポータル連携での確定申告自動化はすでに進んでいるが、「入力補助」レベルに留まっている。今後、日本語対応の税務エージェントが登場したとき、何が起きるかは明白だ。 IT管理者・エンジニア向けの実務ポイント： エージェント型AIの評価を今すぐ始めよ: Perplexity Computer、Microsoft Copilot、Google Geminiのエージェント機能を実際に触ってみる。来年の話ではない 社内の「専門家頼み」プロセスをリストアップせよ: 税務・法務・購買・採用——これらはすべてエージェントAI化の候補だ 「AIが下書き、人間がレビュー」モデルに移行せよ: 税理士への依頼方法そのものを再設計する時期に来ている 筆者の見解 正直に言う。これは来るものが来た、という感じだ。 私がいま一番気になっているのは「ハーネスループ」——エージェントが自律的にタスクを判断・実行・検証を繰り返すアーキテクチャだ。Perplexity Computerが税務申告でやっていることは、まさにそれだ。フォームを読む→計算する→エラーをチェックする→修正案を出す。このループが税務で動くなら、設計次第でどんな業務にも展開できる。 日本のIT業界はこの変化に気づいていない企業が多すぎる。「専門家の仕事はAIに奪われない」という幻想、そろそろ本気で捨てる時期に来ている。仕組みを作れる人間が少数いれば、あとはAIが回す——これが現実になりつつある。 「禁止ではなく安全に使える仕組みを」が私の基本スタンスだ。AIが下書きを作り、人間が最終確認する——そのモデルの方が、人間だけでやるより精度が高く、コストも低い。抵抗するより、乗りこなせ。 ただし一点だけ強調したい。税務申告書には所得・資産・家族情報など極めてセンシティブなデータが含まれる。Perplexityがそのデータをどう扱うか、プライバシーポリシーを必ず確認してほしい。「便利だから使う」の前に、「何を渡しているか」を把握するのは最低限のリテラシーだ。ゼロトラストの観点からも、外部AIサービスへのデータ送信ポリシーを社内で整備しておくことを強く勧める。 出典: この記事は Perplexity Computer can now draft IRS returns and audit tax professionals の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは本当に「1兆ドル」を消し飛ばしたのか かつてAzure Coreの中枢を担ったシニアエンジニアが、衝撃的な告発記事を公開した。Axel Rietschinという人物だ。彼はWindowsカーネルエンジニアとして、DockerやAzure Kubernetes、Azure Container Instances、Windows Sandboxを支えるコンテナプラットフォームの発明・出荷に携わり、複数の特許も持つ。2010年からAzureを使い続け、2023年にAzure Coreに再入社した「日本で言えば生き字引」的な存在だ。 その彼が「21世紀で最もバカバカしく、最も防げたはずのミス」と断言する失敗の話を書き始めた。シリーズの第1回として公開されたこの記事が、Hacker Newsで1000ポイントを超えた。 初日から見えた組織の病巣 記事の冒頭は衝撃的だ。Rietschinが再入社初日——まだIDバッジも受け取っていない段階——に出席した月次計画会議での出来事から始まる。 会議室のスクリーンには、COM、WMI、パフォーマンスカウンター、VHDX、NTFS、ETWなど、Windowsの中核を担うコンポーネント群を示すアーキテクチャ図が映し出されていた。議題は「これらをOverlakeアクセラレーターカードに移植する計画」だという。 Overlakeとは、Azureのネットワーク処理を高速化するオフロードカード。FPGAが搭載されたそのチップは「爪の大きさ」で、Linuxが動く省電力設計だ。デュアルポートメモリはたった4KB。通常サーバーCPUのTDPのごく一部しか使えない。 そんなハードウェアに「Windowsの半分を移植しよう」と大真面目に議論していたのだ。しかも「ジュニアエンジニア数人に調べさせればいい」という発言まで飛び出した。 Rietschinはこの光景を「complacency（慢心）」と表現する。技術的な実現可能性を正しく評価できる人間が議論の中心にいない、あるいはいても声が届かない組織になっていた——それがこの話の本質だ。 Azureの根幹に潜む技術的負債 Rietschinが問題視しているのは単なる一会議ではない。Azure CoreというAzure全体のインフラ基盤を担うチームでこうした意思決定が行われていたという事実だ。 Azure Boostオフロードカードは、ネットワーク・ストレージ処理をホストCPUから分離し、テナントVMにリソースを最大限渡すための重要技術だ。AWSのNitroカードに相当する存在で、クラウドの競争力を決定づけるハードウェアレイヤーである。 そのチームが、ハードウェア制約を正しく理解しないまま、Windowsの複雑なユーザーモード・カーネルコンポーネントの移植を検討していた。これがシリーズ全体のテーマである「信頼の侵食」の出発点だ。 なぜこれが重要か 日本のエンタープライズIT界隈にとって、Azureはもはやインフラの基盤だ。多くの組織がMicrosoft 365、Azure AD（Entra ID）、Teams、そしてAzure上のワークロードを組み合わせて運用している。 その根幹部分——ハイパーバイザー、ネットワーク、ストレージI/O——の設計と実装に慢心があったとすれば、信頼性・セキュリティ・性能すべてに影響が及ぶ。 AzureがOpenAIの大規模トレーニングクラスターを支えているという事実は、今や広く知られている。そしてRietschinが示唆するのは、そのような最重要顧客との関係すら危うくなりかねない意思決定が組織の内部で起きていたという話だ。第1回の記事だけで全貌は明らかではないが、続報が非常に気になる。 実務への影響 アーキテクチャレビューの「技術力担保」を確認せよ Microsoftに限らず、大組織のクラウドサービスを使う際に重要なのは「そのサービスの技術的品質をどう検証するか」だ。SLAの文字面だけを信じるのではなく、可用性ゾーン設計、障害ドメインの分離、ネットワークパスの冗長性などを実際に問い合わせるクセをつけたい。 マルチクラウドの保険価値を再評価する Azureへの全乗りはリスクが高い。AWS、GCP、あるいはオンプレミスとのハイブリッドによる保険的な分散を、コストではなくリスク管理として再評価する価値がある。 内部告発的な情報ソースを監視する Rietschinのようなインサイダーによる告発記事はHacker Newsに集まりやすい。日本語の技術メディアに翻訳が出回る頃には対応が遅れる。英語の一次情報を定期的に確認する習慣が、IT戦略判断の質を高める。 筆者の見解 ぶっちゃけ、この記事を読んで「やっぱりな」という気持ちが強かった。 Azureのプラットフォームとしての基盤は今でも信頼している。Entra IDは正しい選択だし、Teamsや基盤サービスの総合力はまだ他に代替がない。しかし、Microsoftという会社が「最も賢いAIを作る競争」でどんどん後れを取っている一方で、その根幹のインフラ部分でもこういう意思決定が行われていたとすれば、話は深刻だ。 個人的に一番ヤバいと思うのは「ジュニアエンジニア数人に調べさせればいい」というセリフだ。技術的判断の重みを理解していない人間が会議を仕切っている。これは単なるAzureの問題じゃなく、大企業病の典型症状だ。日本のSIerと構造が変わらない。 Microsoftはいま光を失っている——そう感じていたが、この元エンジニアの告発はその感覚を数字と実体験で裏付けてくれた。OpenAIを危うく失いかけた話、米政府の信頼を損なった話は、このシリーズの続回で明かされるようだが、正直なところ続きが怖い。 それでも、Microsoftが最終的に勝つシナリオはまだあると思っている。ユーザーベースとブランド力は本物だ。Copilotがいつか最前線に並ぶ日が来ることを、心から期待している。この批判が「古い批評」になることを願いながら、しかし今は目を逸らさずに見続けるしかない。 出典: この記事は Decisions that eroded trust in Azure – by a former Azure Core engineer の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAがオープンモデル「Nemotron 3」ファミリーを発表した。Nano・Super・Ultraの3種構成で、エージェント型AIアプリケーションの構築に特化して設計されている。SuperとUltraは2026年前半にも提供開始予定だ。GPUの覇者がLLM本体にも本気で手を伸ばしてきた——その意味は小さくない。 Nemotron 3とは何者か NemotronはNVIDIAが独自開発・チューニングしたオープンLLMファミリーだ。今回の第3世代は3つのサイズで展開される。 Nemotron 3 Nano: エッジ・オンデバイス向けの軽量モデル。推論コストを極限まで下げながら実用精度を維持することを目標とする Nemotron 3 Super: バランス型。エンタープライズでのエージェント用途を想定 Nemotron 3 Ultra: フラッグシップ。ベンチマークではオープンソース最高水準を主張しており、クローズドモデルにも迫る性能を謳う ベースアーキテクチャにはLlama系をベースに独自のポストトレーニングとRLHFを重ねたものが採用されていると見られる。NVIDIAはモデル自体の提供と同時に、NIM（NVIDIA Inference Microservices）でのデプロイ最適化も提供し、「NVIDIA上で動かすと速い」エコシステムを一気通貫で押さえにきている。 エージェント向け設計という文脈 今回の発表で注目すべきは「エージェント型AIアプリ構築向けに設計」という一文だ。単に賢いチャットボットを作るためではなく、自律的に判断・行動・検証を繰り返すループ型エージェントの基盤として使うことを想定している。 ツール呼び出し（function calling）、複数エージェントの連携、長コンテキストでの推論といった能力が重点強化されているとされており、単発Q&Aではなく継続的なタスク遂行に向いた設計になっている。 Marvell社がNVLink Fusion経由でNVIDIAのエコシステムに参加したことも同時に発表されており、インフラ〜モデル〜アプリケーション全体をNVIDIAプラットフォームで完結させる戦略が着々と進んでいることがわかる。 実務への影響——日本のエンジニアはどう動くべきか Nemotron 3がオープンモデルである点は実務上の大きなメリットだ。以下のような活用シナリオが現実的になる。 1. 社内データを扱うエージェントの構築 クローズドAPIにデータを送れない用途（医療・法務・金融など）でも、オンプレやプライベートクラウド上でNemotron 3を動かせれば自律型エージェントの構築が現実的になる。 2. ハーネスループの基盤として使う コード生成→テスト実行→修正→再テストのような自律ループを回すエージェントには、高速・低コストな推論が欠かせない。Nano〜Superサイズは特にこの用途にフィットする可能性がある。 3. コスト試算の見直し APIコスト試算をOpenAIやAnthropicのみで行っている現場は、オープンモデルのセルフホスティングとのコスト比較を今のうちに始めるべきだ。規模が大きくなるほどオープンモデルが有利になるケースは多い。 筆者の見解 NVIDIAがモデル自体の競争に本格参入してきたことは評価するが、「エージェント向け設計」という言葉を額面通りに受け取るのはまだ早い。ベンチマーク数値はあくまで参考であり、実際のエージェントループ耐性——長時間タスク中の幻覚率、ツール呼び出しの安定性、多段指示への追従性——は実際に動かして検証しないとわからない。 とはいえ方向性は完全に正しい。今一番アツいテーマはまさにハーネスループだ。エージェントが自律的にループで動き続ける仕組みの設計こそ、2026年に最も投資すべき領域だと思っている。単発の「指示→応答」パターンは役割を終えつつある。「目的を渡せば自分で判断・実行・検証を繰り返す」という設計が本物のAI活用であり、その基盤モデルが複数プレイヤーから出てくることは業界全体にとってプラスだ。 NVIDIAの強みはハードウェアとの一体最適化にある。Nemotron 3をNIM経由でH100/H200上で動かせばトークンあたりのコストと速度が他の追随を許さないレベルになる可能性が高い。この「インフラ込みのパッケージ」こそNVIDIAが他のオープンモデル勢に対して持つ本質的な差別化だ。 AnthropicのClaude Code一択で走っている筆者としては、今すぐ乗り換える理由はないが、エージェントのサブコンポーネント——特にコスト最適化が必要な大量処理パート——にNemotron 3 Nanoを組み込むシナリオは近い将来に十分ありうると思っている。SuperとUltraのリリース後に改めて実測する価値はある。 出典: この記事は NVIDIA Debuts Nemotron 3 Family of Open Models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

悪意あるエクスポートファイル一つでシステムを掌握される ビジネスコミュニケーションツール「Stackfield」のデスクトップアプリ（macOS・Windows両対応）に、CVSSスコア9.6という極めて深刻なパストラバーサル脆弱性（CVE-2026-28373）が発見された。2026年4月3日に公開されたこの脆弱性は、バージョン1.10.2未満のアプリを使っているユーザー全員が対象となる。 Stackfieldは欧州を中心に利用されているセキュアビジネスチャットツールで、エンドツーエンド暗号化を売りにしている。それだけに、暗号化絡みの処理に深刻な穴が開いていたというのは皮肉としか言いようがない。 脆弱性の技術的詳細 パストラバーサルとは何か パストラバーサル（Path Traversal）とは、ファイルパスの検証が不十分な場合に ../../ などのシーケンスを使って意図されたディレクトリの外にアクセスする攻撃手法だ。今回の脆弱性はStackfieldのエクスポートファイルを処理する復号機能の中に存在する。 具体的には、エクスポートファイル内の filePath プロパティに対してサニタイズ・バリデーションが行われていない。攻撃者はここに細工されたパスを埋め込んだ悪意あるエクスポートファイルを作成することで、被害者のシステム上の任意の場所に任意の内容を書き込める。 攻撃に必要な条件 認証不要（PR:N）: 攻撃者はアプリ内で認証を必要としない ユーザーインタラクション必要（UI:R）: 被害者が悪意あるエクスポートファイルを開く必要あり 対象プラットフォーム: macOS・Windows両方 対象バージョン: 1.10.2未満のすべて CVSSが9.6という数字が示すとおり、「ファイルを開くだけでシステムを乗っ取られる」可能性があるクリティカルな問題だ。公開時点でPoC（実証コード）は確認されていないが、エクスポートファイルのフォーマットを解析すれば攻撃者が再現できるレベルの情報はすでに公開されている。 実務への影響とアクション IT管理者がまず確認すること 使用バージョンの確認: 組織内でStackfield Desktop App を使っているユーザーのバージョンを棚卸しする 即時アップデート: v1.10.2以降へのアップグレードを最優先で実施 エクスポートファイルの扱い: 社外から受け取ったStackfieldエクスポートファイルを不用意に開かないよう周知 エンジニア向け注意点 パストラバーサルはOWASP Top 10にも長年ランクインしている古典的な脆弱性だ。今回の教訓は「暗号化・復号処理においても入力値のバリデーションは必須」という当たり前のことを再確認させてくれる。自社アプリでファイルパスを扱っている箇所は、改めて見直す機会にしてほしい。 筆者の見解 セキュリティ関連の話は正直得意じゃない。細かいことを気にしすぎる人たちが集まる分野だし、個人的にはあまり好きではない。でも技術的な興味はある。 で、今回の件で言いたいのはこういうことだ。CVSSスコア9.6はガチのやばい数字。これを「いや、PoC出てないし様子見」で放置するのは、IT管理者として失格だと思う。アップデートは今すぐやれ。 もう一点、今回の脆弱性がエクスポートファイル経由なのがポイントだ。「信頼できるアプリの機能を通じた攻撃」というのがゼロトラストの観点では特に厄介で、「外から来たファイルだから怪しい」という直感がない人を簡単にだます。エンドポイントのファイル操作をモニタリングする仕組みがない組織は本当に危険だ。 VPNで「境界の中は安全」と信じ込んでいるような旧来のセキュリティモデルでは、こういった攻撃に全く歯が立たない。ファイルを開く、ファイルを書き込む——そのレベルの挙動まで監視できるゼロトラスト構成への移行をいい加減本気で考えてほしい。「今動いているから大丈夫」は通用しない、という話は何度でも言い続ける。 出典: この記事は Critical Path Traversal in Stackfield Desktop App (CVE-2026-28373) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年4月1日、Windows 11デバイス向けの「ホットパッチ（Hotpatch）」更新をデフォルト有効化すると正式発表した。Intune管理環境では同日よりテナントレベルのオプトアウト設定が可能になっており、IT管理者は5月11日までに自組織の方針を確定させる必要がある。 ホットパッチとは何か ホットパッチとは、OSを再起動させることなくセキュリティパッチを適用できる技術だ。従来のWindowsアップデートは「ダウンロード→インストール→再起動」という流れが基本で、特に業務時間中の再起動は生産性への影響が大きかった。 ホットパッチはカーネルやシステムコンポーネントのコードをメモリ上でライブパッチする仕組みで、AzureのWindows Server仮想マシンでは以前から提供されていた技術をクライアントOSに展開したものだ。年4回の「ベースライン更新（要再起動）」と、その間を埋める「ホットパッチ月（再起動なし）」が交互に来るサイクルで運用される。 Intune管理者が把握すべき設定変更 2026年4月1日以降、IntuneのWindows Update設定画面に「ホットパッチの許可/ブロック」トグルが追加されている。デフォルトは有効（Allow）のため、特に何もしなければテナント配下の対応デバイスに順次ホットパッチが適用されていく。 5月11日がデッドラインである点に注意が必要だ。この日以降はMicrosoftがデフォルト設定を強制適用する可能性があるため、ブロックしたい場合は事前にポリシーを設定しておくこと。 対応要件は以下の通り： Windows 11 Enterprise（バージョン24H2以降） Intune管理下のデバイス MicrosoftまたはWindows 365のライセンス（Business/Enterprise Premium等） なぜこれが重要か パッチ適用の最大の障壁のひとつが「再起動のタイミング問題」だった。「今業務中だから後で」「今週は重要な案件があるから来週」という先送りが積み重なり、既知の脆弱性を放置したまま何週間も経過するケースは珍しくない。 ホットパッチはこの摩擦をほぼゼロにする。特にゼロデイ脆弱性のような緊急パッチを業務への影響なく当日中に展開できるのは、セキュリティ運用の観点から見て大きな前進だ。 また、VDI（仮想デスクトップ）環境やシフト勤務が常態化している製造・物流・医療現場では「全デバイスの再起動ウィンドウをどう確保するか」という調整コストが馬鹿にならなかった。この課題を構造的に解消できる。 実務での活用ポイント まずIntuneのレポートを確認する：「レポート → Windows Update → ホットパッチレポート」でどのデバイスが対応済みか、パッチ適用状況を可視化できる。導入前にベースラインを取っておくと後の比較が楽になる。 ベースライン更新月（再起動あり）を把握する：ホットパッチ月でも年4回は再起動が必要なベースライン更新が来る。メンテナンスウィンドウの設定は引き続き必要であり「再起動が完全になくなる」と勘違いしないよう社内への説明が重要だ。 段階的ロールアウトを使え：Inuneの更新リングを使ってパイロットグループから展開するのが鉄則。全社一斉適用は何かあったとき影響範囲が広すぎる。 ブロックが必要なケース：高度にカスタマイズされたカーネルドライバーや特殊な業務アプリケーションが存在する環境では、ライブパッチとの相性問題が起きる可能性がある。検証環境で先行確認してからのロールアウトを強く推奨する。 筆者の見解 セキュリティは正直あまり好きなジャンルではないが（細かい人が多すぎる）、この機能は技術的に純粋に正しい方向だと思う。 Windowsアップデートを巡って最近「すぐ当てたら壊れた」報告が増えていて、「数日様子を見る」という判断も立派なセキュリティリスク管理だという話をしてきた。ホットパッチはその葛藤に対して一つの答えを出している——「ベースライン更新は慎重に、でもその間のセキュリティパッチは再起動なしで速攻で当てろ」という棲み分けだ。これは合理的だ。 ただし正直に言う。Microsoftの最近のデフォルト有効化ラッシュには少し辟易している。「オプトアウトは5月11日まで」という期限設定はIT管理者への圧力に他ならず、大規模テナントほど検証時間が取れない。もう少し余裕を持たせてほしかった。 とはいえ、ホットパッチ自体の技術的価値は本物だ。Azure VMではすでに実績があり、概念自体は枯れている。Linuxのkpatchやkspliceと同等の仕組みをWindowsクライアントに持ち込んだという意味で、エンタープライズWindowsの成熟を感じる。 日本のIT現場ではまだパッチ管理をSCCMやWSUSで手動運用しているところが多い。この機能を使いこなすにはIntuneへの移行が前提になるが、その移行自体が「面倒だから後回し」になっている組織が多すぎる。ホットパッチを導入できる環境を整えること自体が、実は最大の課題かもしれない。 Microsoftへの期待が下がっている今でも、こういう地に足のついた改善は素直に評価したい。Copilotよりこっちを先にやれよとは思うけど。 出典: この記事は Securing devices faster with hotpatch updates on by default - Windows IT Pro Blog の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GitHub Actionsの2026年4月アップデートで、Azure Private Networkingを使うホステッドランナーにVNETフェールオーバー機能がパブリックプレビューとして追加された。地味なアップデートに見えて、エンタープライズのCI/CD可用性にとっては結構デカい話だ。 何が変わったのか Azure Private Networking に VNET フェールオーバーが来た これまでGitHub ActionsのAzureプライベートネットワーク接続は、プライマリのAzureサブネットに障害が発生すると、その時点でワークフローが止まる仕組みだった。今回のアップデートで、セカンダリサブネット（別リージョンも可）をあらかじめ設定しておくことができるようになり、プライマリが落ちたときに自動または手動でフェールオーバーできるようになった。 フェールオーバーのトリガーは2種類: 手動: ネットワーク設定UIまたはREST APIから明示的に切り替える 自動: GitHubがリージョン障害を検知した際に自動で切り替え フェールオーバーが発生すると、エンタープライズ・組織管理者に対して監査ログイベントとメールで通知が届く。手動フェールオーバーを実施した場合は、プライマリリージョンが復旧したあとの切り戻しも手動で行う必要がある点は覚えておきたい。 対象はAzureプライベートネットワークを使用しているエンタープライズ・組織アカウント。 OIDC トークンにリポジトリカスタムプロパティが正式対応（GA） パブリックプレビューだったGitHub Actions OIDCトークンのリポジトリカスタムプロパティ対応がGAになった。 これによって、クラウドプロバイダー側のOIDCトラストポリシーを、個別のリポジトリ名やIDではなく「環境タイプ」「チームオーナーシップ」「コンプライアンスティア」のようなカスタムプロパティの値で制御できるようになる。リポジトリが増えるたびにクラウド側のロール設定を更新する手間が減り、組織のガバナンスモデルとクラウドアクセス制御を一致させやすくなる。 サービスコンテナのエントリポイント・コマンドのオーバーライドも追加 サービスコンテナのエントリポイントとコマンドをワークフローYAML内から上書きできるようになった。entrypointとcommandキーを使い、記法はDocker Composeと同様なので、馴染みのある書き方でそのまま使える。地道だが、今まで無理やりな回避策を取っていたユーザーには嬉しいアップデートだろう。 実務への影響 エンタープライズCI/CDの可用性要件が現実的に満たせる Azureプライベートネットワーク経由でGitHub Actionsを動かしている環境は、セキュリティ要件上どうしてもパブリックランナーが使えない場面が多い。金融・官公庁・大手製造業などでは、このフェールオーバー機能があるかないかで、DR（ディザスタリカバリ）要件の充足度が変わってくる。 実務的には以下の点を押さえておきたい: セカンダリサブネットのリージョン選択: プライマリと同一リージョンに置くのか別リージョンにするかで、RTO（目標復旧時間）が大きく変わる。コスト増を許容してでも別リージョンを選ぶ判断が必要な場合がある 監査ログの設計: フェールオーバーイベントが監査ログに記録されるので、SIEMへの連携設計を事前にやっておく 切り戻し手順の文書化: 手動フェールオーバー時の切り戻しは自動ではない。手順書とRunbookを今のうちに用意する OIDC カスタムプロパティは今すぐ採用を検討すべき リポジトリ数が多い組織では、個別リポジトリをクラウドロールにマッピングする運用がそのうち破綻する。OIDCカスタムプロパティの仕組みを使えば、リポジトリのタグ付け（例: env=production, team=platform）をそのままアクセス制御ポリシーに反映できる。スケーラブルなアクセス管理の基盤として、早めに設計を見直す価値がある。 筆者の見解 VNETフェールオーバー機能そのものは技術的に特別新しい概念ではない。Azure Load BalancerやTraffic Managerで散々やってきたことをGitHub Actionsのランナー基盤に持ち込んだというだけだ。ただ、これが「ようやく来た」という感覚は正直ある。 エンタープライズ導入の文脈でGitHub Actionsを提案するとき、必ずCI/CDパイプラインの可用性を問われる。「Azureリージョンが落ちたらビルドも止まるんですか？」という質問に対して、今まではフェールオーバーの仕組みがなかったので、正直に「止まります」と言うしかなかった。それが今後は「セカンダリ設定しておけば継続します」と答えられる。地味だが導入のハードルを下げる効果は大きい。 OIDCカスタムプロパティのGA化については、これが本当に正しい方向性だと思っている。「禁止ではなく安全に使える仕組みを」という観点から言えば、個別リポジトリを列挙してアクセス制御するのはスケールしないし、結局管理できなくなって「全部禁止」に振れる組織が出てくる。組織のガバナンスモデルを軸にアクセス制御を設計できる仕組みが整うことで、GitHub Actionsをガンガン使い倒せる組織が増えるはずだ。 AzureとGitHubの統合がじわじわと深まっているのを感じるアップデートだった。Microsoftがプラットフォームとしての安全な基盤を着実に固めている、その一端として評価している。 出典: この記事は Azure private networking for GitHub Actions hosted runners: failover networks in public preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Copilotがついにセキュリティ領域へ本気で踏み込んだ Microsoftは2026年4月20日から6月30日にかけて、Microsoft 365 E5ユーザーに対してSecurity Copilot機能の段階展開を開始すると発表した。注目すべき点は「追加ライセンス不要」という一点に尽きる。これまでSecurity CopilotはE5とは別のアドオン製品として提供されており、導入にはそれなりのコスト増を伴った。今回の変更でそのハードルが一気に消える。 何が変わるのか 対象ユーザーと展開タイムライン 対象: Microsoft 365 E5ライセンス保有者 展開開始: 2026年4月20日（段階的ロールアウト） 展開完了予定: 2026年6月30日 追加費用: なし（E5ライセンス内で提供） Security Copilotでできること Security Copilotは、Microsoft Defenderやセンチネル（Microsoft Sentinel）と連携し、インシデント分析・脅威ハンティング・セキュリティインサイトの生成をAIが支援する機能群だ。具体的には以下のような用途が想定される： インシデントの自動サマリー生成: アラートの文脈を整理してSOCアナリストに提示 KQLクエリの自然言語支援: 「過去24時間で不審なサインインは？」を日本語で聞けば対応するクエリを生成 脅威インテリジェンスのリアルタイム解説: 最新のCVEや攻撃手法をその場で説明 インシデント対応レポートの自動生成: 対応完了後の報告書作成を半自動化 日本のIT現場への影響 日本のエンタープライズでE5ライセンスを契約している組織は、実はそれなりの数に上る。M365 E5はコンプライアンスやAdvanced Threat Protection目当てで導入している企業も多い。そういった組織にとって「追加コストゼロでセキュリティAIが使える」という変化は、SOC（セキュリティオペレーションセンター）の生産性向上という観点で無視できない。 ただし、過去にE5を「とりあえず契約したが使いこなせていない」という組織も多い。Security Copilotが機能するには、Defender for Endpointやログの適切な収集体制がすでに整っていることが前提だ。インフラが整っていないままAIを被せても意味はない。まず基盤を固めるのが先決である。 実務での活用ポイント テナントの展開状況を4月20日以降に確認する: 段階ロールアウトのため、すぐに全テナントで有効化されるわけではない。管理者はMicrosoft 365管理センターでの提供状況を定期チェックすること Microsoft Sentinelとの連携を先に整備する: Security CopilotはSentinelのデータを読む。ログ収集が不完全だと機能が活かせない SOCメンバーへのトレーニングを事前に計画する: ツールが揃っても使う人が使い方を知らなければ宝の持ち腐れ。プロンプト設計の基礎くらいは学ばせておく セキュリティポリシーとの整合性確認: AI生成コンテンツをインシデント対応プロセスに組み込む前に、社内のセキュリティポリシーやコンプライアンス要件と照合する 筆者の見解 ぶっちゃけた話をすると、Copilotには今もかなり失望している。Copilot for Microsoft 365がリリースされてからこの数年、「これで変わる」という期待を何度裏切られたことか。MVP Global Summitすら最近は見ていない。それくらいテンションが下がっている。 ただ、今回のSecurity Copilot統合は少し違う角度から見ている。生産性系Copilotと違って、セキュリティ領域のAI支援は「アナリストの作業速度を上げる」という明確なROIが測りやすい。インシデント対応時間が30%短縮されれば、それは実績として数字に残る。そういう意味では、セキュリティ用途のCopilotには若干の期待を持っている。 セキュリティって正直、細かい人が多くて好きじゃない領域なんだが（笑）、技術的な面白さはある。特にゼロトラスト文脈で考えると、Security CopilotがJust-In-Timeアクセス制御の判断補助や、不審なアクセスパターンの早期検知に使えるなら価値がある。VPNとか昔のペリメータ型セキュリティはもう滅んでいいと本気で思っているので、ゼロトラストを加速させる方向でAIが機能するなら歓迎だ。 日本の大企業のセキュリティ運用は今、昔のモデルと中途半端なゼロトラストが「悪魔合体」しているやばい状態のところが多い。Security Copilotが普及して、少なくとも「現状の可視化」ができるようになれば、その悪魔合体状態に気づくきっかけになるかもしれない。そういう意味では、E5への無償統合という判断は正しい。ガンガン使って、現実を直視してほしい。 Microsoftへの失望は続いているが、「ブランドとユーザーベースがある」という現実は変わらない。Copilotがいつか本当に最前線に並ぶ日が来ることを、まだ少しは願っている。 出典: この記事は Security Copilot Rolling Out to Microsoft 365 E5 (April 20 – June 30, 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年4月2日、Microsoftはとうとう引き金を引いた。SharePoint Add-Ins、ACS（Azure Access Control Services）、ドメイン分離Webパーツ（Domain Isolated Web Parts）、そしてSharePoint 2013ワークフローの4コンポーネントが正式廃止となった。予告は何年も前から出ていたが、それでも対応が追いついていないテナントはまだある。今回の廃止はもはや「予告」ではなく「実行」だ。 廃止された4コンポーネントの概要 SharePoint Add-Ins（旧称 Apps for SharePoint） SharePoint 2013時代に導入されたアドインモデル。サードパーティ製のカスタム機能をSharePointに追加する仕組みとして広く使われてきたが、クラウド時代には明らかに設計が古すぎた。後継はSharePoint Framework（SPFx）。 ACS（Azure Access Control Services） SharePointと外部サービスを連携させるための認証基盤。「高信頼アドイン」と呼ばれるServer-to-Server認証で長年使われてきた。今後はMicrosoft Entra ID（旧Azure AD） を使ったOAuth 2.0ベースの認証に完全移行する必要がある。 ドメイン分離Webパーツ（Domain Isolated Web Parts） SPFxのWebパーツを独立ドメインのiframeで分離実行する機能。セキュリティ上の理由で設計されたが、複雑さの割にメリットが限定的だったためMicrosoft自身が廃止を決断した。 SharePoint 2013ワークフロー 2013年当時のワークフローエンジン。オンプレミス時代の産物であり、クラウドネイティブなフローとは根本的に設計が異なる。移行先はPower Automate一択。 移行先と実務での作業ポイント 1. Add-Ins → SPFx移行 まず現環境のアドイン一覧を棚卸しする（SharePoint管理センター→アプリカタログで確認可能） カスタム開発したアドインはSPFxのReactベースWebパーツへ再実装 サードパーティ製アドインはベンダーにSPFx版への移行確認を取る SPFx 1.18以降を使う場合はNode.js 18のLTS環境が必要 2. ACS → Entra ID（旧Azure AD）移行 Get-SPOTenantコマンドレットでDisableCustomAppAuthenticationの状態を確認 アプリ登録をEntra IDに移し、クライアントシークレットまたは証明書で認証するよう変更 .NETやCSOMを使っている場合はPnP.PowerShellまたはMicrosoft Graph SDKへの切り替えを検討 3. 2013ワークフロー → Power Automate移行 Power Automateの「SharePointリストのアイテムが作成されたとき」トリガーを起点に再設計 承認フローは承認アクションを使うとほぼそのまま再現できる 移行ツール「SharePoint Migration Tool（SPMT）」はワークフロー移行には使えない点に注意。手動での再設計が必要 4. 情報保護関連はPurviewへ ...

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