Tech News JP

AIエージェントが「調べて考えてまとめる」を自動で回し続ける時代へ MicrosoftがAzure AI Foundry Agent Serviceに「Deep Research」機能をパブリックプレビューとして公開した。単発の質問応答でもなく、RAGの一回検索でもない。エージェントが自律的に「調査→推論→再調査」を繰り返し、最終的に根拠付きのレポートを生成する——そんなループ型の調査自動化を、API・SDKから直接呼び出せるサービスとして提供するのがこの機能の本質だ。 仕組みとアーキテクチャ Deep Researchの中核を担うのはo3-deep-researchモデル。このモデルが「調査マネージャー」として機能し、以下のようなマルチステップパイプラインを自動で組み立てる。 意図の明確化とスコープ設定 — GPT-4oやGPT-4.1が初期クエリを分析し、調査の範囲と目的を精緻化する Bing Searchによるウェブグラウンディング — スコープが固まったら、Grounding with Bing Searchツールを通じて信頼性の高い最新情報を収集する 合成と要約 — 複数の情報源を統合し、ソース付きの透明性の高いアウトプットを生成する アーキテクチャ上の特徴は「コンポーザビリティ」にある。Deep Research単体で完結するのではなく、Logic AppsやAzure Functionsと組み合わせて、レポート生成→通知→承認ワークフローといった一連の業務プロセス全体を自動化できる。 ChatGPT Deep ResearchとMicrosoft 365 Copilot Researcherとの違い 似たような名前の機能がすでに存在するので整理しておこう。 機能 対象 特徴 ChatGPT Deep Research 個人ユーザー チャットUIから利用 M365 Copilot Researcher ビジネスユーザー Officeワークフロー統合 Azure AI Foundry Deep Research 開発者・企業システム API/SDK経由で自社アプリに組み込み FoundryのDeep Researchは「チャット画面の外」に出ることを前提に設計されている。社内の基幹システム、データパイプライン、承認ワークフローに直接埋め込んで使うための部品だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 法務・コンプライアンス部門との連携: 規制動向の定期モニタリング、ガイドライン変更の影響分析、リスクレポートの自動生成。これまで人手で週次・月次でやっていた調査業務をエージェントに委ねられる現実的な選択肢になる。 競合・市場調査の自動化: 特定の業界・製品カテゴリに関する情報収集を定期ジョブとして設定し、差分レポートをTeams・メールに自動配信するような仕組みが、Azure Functions + Logic AppsとのコンポーズでNo/Low Code寄りに構築できる。 RAGの「一回検索」の限界を超える: 従来のRAGは「クエリ→検索→回答」の一往復が基本。Deep Researchは「クエリ→検索→中間結論→追加クエリ→再検索→最終回答」というループを自動で組み立てる。複雑な調査タスクに対して、従来RAGより精度の高いアウトプットが期待できる。 ガバナンスと監査: Azureの既存のセキュリティ・コンプライアンス基盤がそのまま適用される。どのソースを参照したか、どのような推論ステップを踏んだかがトレース可能なため、金融・医療・公共といったコンプライアンス要件の厳しい業種でも採用しやすい設計になっている。 ...

MicrosoftがAzure AI Foundry（旧称：Azure AI Studio）を通じて、自社開発の機械学習モデル3本をパブリックプレビューとして公開した。音声認識・音声生成・画像生成という、OpenAIが得意とするド真ん中の領域に自社モデルを投入したことで、両社の関係性に新たな局面が生まれている。 何が公開されたのか 今回発表されたモデルは以下の3つだ。 MAI-Transcribe-1：25言語に対応した音声認識モデル。エンタープライズグレードの精度を持ちながら、GPU コストを競合比約50%削減できるとされる MAI-Voice-1：音声合成モデル。シングルGPUで60秒の音声を1秒未満で生成できるというスピードが売り MAI-Image-2：テキストから画像を生成するモデル 注目すべきは、これらが「新たに作られた実験的モデル」ではなく、すでにCopilot・Bing・PowerPoint・Azure Speechを裏側で動かしている本番モデルと同一であるという点だ。Microsoft Azure AI Foundry ModelsプロダクトチームのNaomi Moneypenny氏がブログで明言している。 CopilotのAudio ExpressionはMAI-Voice-1上で動作し、Copilot Voice Modeの文字起こしにはMAI-Transcribe-1が使われている。つまりMicrosoftは、自社製品で実戦投入済みのモデルを今回初めて外部開発者向けに開放したわけだ。 OpenAIとの関係はどう変わる MicrosoftはOpenAIに約1,350億ドル相当（昨年10月時点）の出資を行っており、少なくとも2032年まで提携を継続する方針を示している。しかしOpenAIは今年140億ドルの赤字が見込まれるとも報じられており、Microsoft投資家からも懸念の声が上がっていた。 Microsoftが提携再交渉の際に「OpenAI抜きで単独あるいは第三者と共にAGI研究を追求できる」と明言したのは象徴的だ。今回の自社モデル公開は、その言葉を具体的な行動で裏付けるものと言える。パートナーシップを維持しつつも、技術的自律性を着実に高めている。 なぜこれが重要か Azureをプラットフォームとして採用している日本企業にとって、この動きが持つ意味は小さくない。 これまで音声・画像系のAI機能をAzure上で実装しようとすると、OpenAI APIを経由するケースが多かった。その場合、コスト・レイテンシ・データ主権（どこでデータが処理されるか）の3点が懸念材料になりやすかった。 自社モデルがFoundryから直接利用できるようになれば、Azure環境内でデータを完結させながら、GPU コストも抑えた音声・画像処理パイプラインを組める。コールセンターの会話解析、会議の自動議事録生成、多言語キャプション対応といった用途は、日本企業でも今すぐ検討に値する。 実務での活用ポイント 1. 音声系ユースケースから着手せよ MAI-Transcribe-1の25言語対応・低コストという特性は、グローバル対応が求められる日系多国籍企業のミーティング文字起こしや、コンタクトセンター品質監査への転用が現実的だ。既存のAzure Speechを使っているなら、まず開発者テナントでモデルを切り替えて精度・コストを比較するところから始めたい。 2. Foundryをエージェント基盤として捉え直す 今回の公開は「モデル単体」の話ではない。Foundryは音声・画像・テキスト処理をワンプラットフォームで統合できる場になりつつある。AIエージェントを構築する際、入力チャネルの一つとして音声を組み込む設計が、以前より格段に組みやすくなった。 3. データ主権の観点でOpenAI APIと比較検討する 金融・医療・公共分野など、データのリージョン外流出に敏感な業界では、Microsoftの自社モデルを選ぶことでデータガバナンス上の説明責任が果たしやすくなる。コンプライアンス要件との整合を確認した上で採用判断したい。 筆者の見解 MicrosoftがOpenAI依存を薄めながら技術的自律性を確立しようとしている方向性は、プラットフォーム企業として正しい戦略だと思う。「最も多くのエージェントが安全に動作する基盤を提供する」という競争において、自社モデルラインナップの充実は欠かせない一手だ。 一方で、正直なところを言えば「このくらいやれるはずだよね」という印象もある。Microsoftには世界最大規模のインフラと、OpenAIとの長年の共同研究で蓄積された知見がある。それだけのリソースを持つ企業が、自社製品に使っているモデルを開発者向けに開放するまでにここまで時間がかかったのは、もったいなかった。 Copilotが一部ユーザーから信頼を取り戻せていない現状も正直に見ている。だからこそ、今回のようにFoundryを開発者にとって本当に使いやすいプラットフォームとして育てていく姿勢を継続してほしい。Microsoftには正面から勝負できる力がある。その力を着実に形にしていくことが、長期的な信頼回復につながると思う。 Foundryを「AIモデルのマーケットプレイス」として進化させ、自社モデルも他社モデルも最適なものを選んで組み合わせられる環境を作ることで、Microsoft基盤を選ぶ理由はより強くなる。この方向は間違っていない。 出典: この記事は Microsoft shivs OpenAI with new AI models for speech, images の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界最大級のセキュリティカンファレンス「RSA Conference 2026」に合わせ、MicrosoftがMicrosoft Purviewの大規模なアップデートを発表した。AI活用が急速に広がるエンタープライズ環境において、「データを守る」という基本命題がいかに複雑化しているか——今回の発表はその課題に正面から向き合った内容だ。 AIが広がるほど、データの「出口」が増える ここ数年で業務におけるAI活用は一般化した。だが、それはデータの「流れ道」が爆発的に増えたことを意味する。社内文書をAIに渡す、会話ログにセンシティブ情報が混入する、外部AIサービスへのデータ転送が発生する——こうした経路のひとつひとつが、従来のデータ損失防止（DLP）の管理範囲を超えてしまっている。 Microsoft PurviewはもともとMicrosoft 365環境のデータガバナンスを担うプラットフォームだが、今回のRSA 2026での発表ではAIワークロードに特化したデータセキュリティポスチャ管理（DSPM） の強化が中心テーマとなっている。具体的には、AIアプリケーションがどのデータにアクセスしているかを可視化し、感度ラベル（Sensitivity Labels）をAIインタラクションの文脈にも適用できるよう拡張する方向性が示された。 データ保護とAIガバナンスの統合という方向性 注目すべきは、Purviewが単なるDLPツールから「AIガバナンス基盤」へと役割を広げようとしている点だ。 AIアクティビティの監査ログ: どのユーザーがどのAIツールに何を入力したかを記録・分析 感度ラベルのAI連携強化: 機密ラベルが付いたドキュメントをAIが参照した際のアラートや制限 コンプライアンスレポートの自動化: 規制対応（GDPR、業界固有規制等）に対するAI利用状況の証跡管理 これらをEntra IDやMicrosoft Defender for Cloud Appsとシームレスに連携させることで、ゼロトラスト原則に基づいた多層防御の中にAIを組み込む設計思想が見える。 実務への影響——日本のIT管理者が今すぐ確認すべきこと 日本のエンタープライズ環境では、Microsoft 365をすでに展開しているケースが多い。であれば、今回のPurview強化は「追加コストゼロで恩恵を受けられる可能性がある」領域でもある。 確認・対応ポイント： 感度ラベルの整備状況を見直す — ラベルが整備されていないとAI連携機能が機能しない。まずここから手をつけるべきだ AIアプリの棚卸し — 社員が業務で使っているAIツールをすべてリストアップし、Purviewの監視対象に含めているか確認する DSPMのスコープ設定 — OneDrive・SharePoint・Teamsに加え、Copilot経由のアクセスも対象に含めているか 条件付きアクセスポリシーとの整合性確認 — AIツールを「アプリ」として認識し、Entraの条件付きアクセスに組み込む とりわけ「AIを禁止する」方向で動いている組織は、ここで戦略を見直してほしい。禁止は必ず回避される。公式ルートが一番便利と感じられる仕組みを作ることが、現実的な安全策だ。 筆者の見解 Microsoft Purviewは地味だが、本質を突いたプラットフォームだと思っている。「データがどこにあって、誰が触れて、どう動いているか」を把握することは、AIが広がる時代においてセキュリティの根幹だ。その観点で今回の方向性は正しい。 ただ、正直に言えば「もったいない」とも感じる。Purviewのような統合ガバナンス基盤は、M365全体を本気で活かすための土台になり得る。それだけの実力があるプラットフォームだからこそ、AI対応の速度をもっと上げてほしいし、UIや運用性の改善も期待したい。概念は正しい、あとは実装と体験の磨き込みだ。 AI時代のセキュリティは「AIを止めること」ではなく「AIを安全に通すこと」に移行している。Purviewがその交通整理役として機能するかどうか——RSA 2026の発表がその試金石になる。 出典: この記事は Secure data as AI scales: New Microsoft Purview innovations at RSA 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIのトップ層がまた動いた。2026年4月、同社の組織再編が内部メモを通じて明らかになり、主要幹部3名が同時に役割を変えることが判明した。単なる人事ニュースに見えるが、その背景にはOpenAIが直面しているいくつかの構造的な課題が透けて見える。 何が起きたのか 今回の主な人事変動は3点。 Fidji Simo（CEO of AGI Deployment）が医療休暇へ 自己免疫神経系疾患（neuroimmune condition）のため、数週間の医療休暇を取ると本人が社内メモで発表。彼女の不在中は、OpenAI社長のGreg Brockmanが製品部門全体を統括する。スーパーアプリ開発を含むプロダクト戦略を一手に引き受けることになる。 Brad Lightcap（COO）が役割変更 COOを離れ、「特別プロジェクト」に専念する新ポジションへ移行。今後はSam Altman CEOに直接報告する体制に。COOの主業務はCRO（最高収益責任者）のDenise Dresserが引き継ぐ形となった。DresserはSalesforceでSlack CEOを務めた人物で、エンタープライズ領域に深い知見を持つ。 Kate Rouch（CMO）が退任 がん治療に専念するための退任。回復後はより限定的なスコープの役割で復帰する意向とのこと。暫定CMOとしてGary Briggsが就任する。 なぜこれが重要か この人事を表面だけ見ると「体調不良による一時的な交代」に映るが、文脈を加えると別の顔が浮かぶ。 2026年初頭、OpenAIは複数の逆風に晒されていた。米国防総省との新契約締結は社内外で物議を醸した。AI動画生成ツール「Sora」はリソース不足を理由に一時的に縮小。エンタープライズやコーディングツール分野での競合キャッチアップに追われ、広報責任者（CCO）のHannah Wongも1月に退任している。 そこに今回の3名同時変動。「組織の求心力がどこにあるか」という問いへの回答として、Greg BrockmanとDenise Dresserという2人への権限集中が図られた格好だ。特にBrockmanは、一度はOpenAIを離れた後に復帰した人物であり、Altman体制の核心的なビジョンを共有している。 もう一つ注目すべきは「AGI Deployment」というポジション名そのものだ。かつては「Applications担当CEO」だったSimoの肩書きが、いつの間にか「AGI Deployment担当CEO」に変わっている。OpenAIが製品戦略をAGIの実用展開として位置づけ始めた意図が読み取れる。 実務への影響——日本のIT現場への示唆 日本のエンタープライズでOpenAIのAPIやChatGPT Enterpriseを採用している組織にとって、今回の変動がすぐに影響を与えることはないだろう。しかし、以下の点は注視しておく価値がある。 Denise DresserのSlack CEO経験はエンタープライズ向けプロダクト強化に直結する可能性が高い。Slack同様の企業向けコミュニケーション統合が加速するかもしれない COO機能をCSO・CFO・CROに分散させた構造は、OpenAIが「プロダクト単体の企業」から「複合的なエンタープライズ企業」へと変容しようとしているサインとも読める Greg Brockmanがスーパーアプリ戦略を直接指揮する体制になったことで、ChatGPTアプリの方向性が大きく動く可能性がある。日本でも法人・個人ともにChatGPTを中心とした業務フローを組んでいる企業は多く、UIや機能の大幅な変更には備えておきたい 筆者の見解 このニュースが気になるのは、「OpenAIがどこへ向かおうとしているか」のヒントが見えるからだ。Sora縮小、国防総省契約問題、そして今回の幹部大移動——これだけのことが数ヶ月で起きているのに、巨大ユーザーベースを抱える組織としての推進力は衰えていない。それはそれで凄みがある。 「AGI Deployment」という肩書きを本気で使い始めた組織の重力は、AI業界全体に影響してくるだろう。競争は激化するほど技術者にとっては良いことだ。ガンガン戦ってほしい。 注目したいのは、OpenAIが今後どの方向にプロダクトを振るかだ。AIエージェントが自律的にタスクを遂行する世界に本気で舵を切るなら、エンタープライズ市場での存在感はさらに増す。Denise DresserのSlack CEO経験がそこにどう効いてくるか、楽しみに見守りたい。 出典: この記事は OpenAI’s AGI boss is taking a leave of absence の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AMDが支援するオープンソースプロジェクト「Lemonade」が、ローカルAI界隈で急速に注目を集めている。GitHubのスター数はすでに2,100超。「ローカルAIは無料で、オープンで、速く、プライベートであるべき」というコンセプトを掲げ、GPU・NPUの両方を活用する本格的なローカルLLMサーバーとして登場した。 Lemonadeとは何か LemonadeはAMDのRyzen AI環境を中心に設計された、ローカルPC向けのLLMサーバーだ。バックエンドはネイティブC++で書かれており、サービス本体はわずか2MBという驚異的な軽量さ。インストーラーが依存関係を自動セットアップし、概ね1分以内に起動できる設計になっている。 主な特徴 GPU・NPU自動認識: 搭載ハードウェアに応じて最適な依存関係を自動設定。RyzenのNPUにも対応 マルチエンジン: llama.cpp、Ryzen AI SW、FastFlowLMなど複数の推論エンジンに対応 複数モデルの同時実行: 用途に応じて複数のモデルを並走させられる OpenAI API互換: 既存のアプリやツールをほぼそのまま接続できる マルチモーダル対応: チャット・ビジョン・画像生成・音声認識・音声合成をAPIで統一提供 連携済みアプリも豊富で、Open WebUI、n8n、Continue（VS Code拡張）、OpenHands、Difyなど、開発者に馴染みのある主要ツールが名を連ねている。GitHub Copilotとの連携も記載されている点が目を引く。 NPUとは何か——Ryzen AIが持つ第3の演算ユニット 「NPU（Neural Processing Unit）」という言葉に聞き慣れない方も多いかもしれない。CPUがあらゆる処理を担い、GPUが並列演算を担うのに対し、NPUはAI推論に特化した専用演算器だ。AMDのRyzen AIシリーズ（Ryzen 8000番台以降）に搭載されており、低電力でAI処理をこなせるのが特徴。 これまでローカルLLMといえばGPUメモリの量がボトルネックだったが、NPUを活用することでバッテリー駆動のノートPCでも実用的なLLM推論が可能になる方向性が開けてきた。Lemonadeはこの流れに正面から乗っかったプロジェクトだ。 実務への影響——日本のエンジニア・IT管理者に何が変わるか プライバシー要件の厳しい現場に刺さる 医療・法務・金融など、データをクラウドに送れない業種でも、OpenAI API互換のローカルサーバーがあれば既存のAIアプリをそのままオンプレ運用に切り替えられる。LangChainやLlamaIndexで書いたコードのAPIエンドポイントをLocalhostに変えるだけ、というシナリオが現実的になる。 開発・検証コストを下げるローカルサンドボックス Claude APIやAzure OpenAIを呼びながら開発していると、テスト段階でもAPIコストがかさむ。Lemonadeをローカルに立ててOpenAI互換エンドポイントを生やしておけば、開発・デバッグ段階はコストゼロで回せる。本番だけクラウドモデルに切り替える構成も容易だ。 AIエージェント・ハーネスループの自前インフラとして n8nとの連携が明記されている点が特に面白い。ワークフロー自動化ツールと組み合わせて、完全ローカルのAIエージェントパイプラインを構築できる。クラウドに一切データを出さないまま、LLMが自律的にタスクを繰り返し実行するループを設計できるわけだ。 明日から試せる手順： Ryzen AI対応PCまたはNVIDIA GPU搭載PCにLemonadeをインストール http://localhost:8000 のOpenAI互換エンドポイントをお気に入りのAIツールに向ける Continue（VS Codeプラグイン）を接続してローカルコード補完環境を試す n8nと組み合わせてRAGパイプラインの試作を始める 筆者の見解 正直に言う。MetaのLlamaシリーズには期待していない。コスパで見ると中国勢（Qwen、DeepSeekなど）の方がはるかに上だし、ローカルLLM界のメインストリームはもうそちらにシフトしている。 その文脈でLemonadeを見ると、AMD自身がNPUを活かした推論スタックを本気で整備してきたという点が重要だ。これはハードウェアベンダーとしてのAMDが「Ryzen AIを買えばAIがすぐ動く体験」を本気で作りにきたサインである。IntelもNPUを搭載しているが、ソフトウェアエコシステムの整備速度ではAMDに軍配が上がりそうな雰囲気がある。 そして何より、ローカルLLMとハーネスループの組み合わせこそが今一番アツいフロンティアだ。エージェントが自律的にタスクを繰り返し実行するループを設計しようとしたとき、クラウドLLMでやると推論コストが積み上がって採算が合わなくなる。ローカルで推論コストゼロのモデルを動かし続けられるなら、ループを回しまくる設計が成立する。 もちろん、モデルの品質はクラウドの大規模モデルに及ばない。でも「ループを高速に何十回も回す」用途ではローカルモデルの速度・コストの優位性が品質差を上回るケースは確実にある。Lemonadeがそのインフラとして機能するなら、使わない手はない。 PCを買い替えるなら、今後はNPU搭載の有無を確認する時代に入った。Lemonadeのようなエコシステムが育ってくれば、それが購入基準の一つになるだろう。ガンガン試してほしい。 出典: この記事は Lemonade by AMD: a fast and open source local LLM server using GPU and NPU の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

あなたのMacにはすでにAIが入っている Apple Siliconを搭載したMacには、macOS Tahoe（macOS 26）からAppleが独自に開発した約30億パラメータのオンデバイスLLMが標準搭載されている。Siriの音声応答や「Writing Tools」の文章補助に使われているあのモデルだ。しかしAppleはこのモデルをFoundationModelsフレームワーク経由のSwift APIとしてしか公開しておらず、ターミナルから直接呼び出す手段も、HTTPエンドポイントも、シェルスクリプトで活用する方法も用意していなかった。 そこに登場したのが、OSSプロジェクトapfel（MIT ライセンス）だ。GitHubで1,100以上のスターを集めており、Hacker Newsでも600ポイント超の話題となっている。 apfelが提供する3つのインターフェース 1. UNIXコマンドラインツール 出典: この記事は Show HN: Apfel – The free AI already on your Mac の内容をもとに、筆者の見解を加えて独自に執筆したものです。

コード検索といえば長らく正規表現（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へ ...