Tech News JP

Azureが2026年4月3日付けで大量のアップデートを公開した。なかでも目を引くのが Azure SQL Managed Instance（SQL MI）のAI搭載PaaS化と、インフラのドリフト検出・修復提案ツールの追加だ。地味に見えて、実はDBとインフラ運用の現場を根本から変えるポテンシャルを持つ変更である。 Azure SQL MI：「AIが入ったマネージドDB」へ 今回のアップデートで、SQL MIは単なる「サーバーレスなSQL Server」から一歩踏み込み、以下の機能がサービスに組み込まれた。 自動チューニング（Automated Tuning）: クエリの実行計画をAIが継続監視し、パフォーマンスが劣化する前に自動で最適化を提案・適用する 異常検知（Anomaly Detection）: 通常のワークロードパターンから逸脱した動作をリアルタイムで検出。障害の予兆を早期に捉えられる モデル駆動インサイト（Model-Driven Insights）: AIが蓄積されたメトリクスを解析し、インデックス設計やリソース配分に関する具体的な改善提案を出す 重要なのは、これらが「外部ツールを組み合わせた拡張機能」ではなく、SQL MIサービスそのものに内包された点だ。アンダーレイのサーバー管理が不要なPaaSの強みと、AIによるインテリジェントな運用支援が一体化した。 インフラのドリフト検出：構成ずれを自動で発見・修復提案 もうひとつの大きな変更が、AIによるインフラ構成ドリフト検出ツールだ。 デプロイしたAzureリソースが「あるべき構成（desired state）」からいつの間にかずれてしまう「ドリフト」は、エンタープライズ環境では慢性的な悩みだ。誰かが緊急対応でポータルから手動変更した、古いスクリプトが残っていた——そういった蓄積が気づかないうちにコンプライアンス違反やセキュリティホールを生む。 新ツールはデプロイ済みリソースと定義済み構成を自動比較し、差異を検出した上で修復提案まで提示する。Infrastructure as Codeを活用していれば特に効果が高く、Bicep・Terraform等との組み合わせで「構成の真実の情報源」を常に守る仕組みが整う。 注意すべき廃止スケジュール 今回のアップデートには、運用担当者が見落としてはいけないサービス廃止通知も含まれている。 App Service / Azure Functions における Python on Windows のサポート終了: 移行期限は2027年まで。既存ワークロードがある場合は早めにLinuxコンテナへの移行計画を立てること Storage向け Azure DNS Endpoints の廃止: こちらも2027年タイムラインで移行が必要。ストレージ関連の接続構成を持つシステムは影響範囲の確認が急務 SRE Agentの課金モデル変更: アクティブフロー単位の従量課金に変更される。利用量の多い環境では想定外のコスト増にならないよう、利用状況の確認を推奨 実務への影響 DBエンジニア・DBA向け: SQL MIの自動チューニングとインサイト機能は、慢性的な人手不足が続く日本のDB運用現場に直結する恩恵だ。「クエリが遅い原因を深夜に調査する」「定期的なインデックス見直しをスケジューリングする」といった作業の多くをAIがカバーしてくれるようになる。ただし、AIの提案をレビューする能力は引き続き必要なので、スキルアップの方向性を「提案を正しく評価できる人材」に転換していくことが求められる。 インフラ担当・クラウドアーキテクト向け: ドリフト検出ツールは、ガバナンスを手動のチェックリストで維持してきた組織に特に刺さる。まずプレビュー環境で試し、自社のIaCリポジトリとの連携フローを設計しておくと本番展開がスムーズになる。Azure PolicyやDefender for Cloudとの組み合わせも検討したい。 廃止対応: 2027年という期限は「まだ先」に見えるが、大企業の移行プロジェクトは承認・設計・テストで1〜2年かかることが珍しくない。今すぐ影響範囲の棚卸しだけでも着手しておくことを強く勧める。 筆者の見解 Azureが今回打ち出した方向性——コアサービスの中にAIを埋め込む——は、プラットフォームとしての正しい進化だと思う。AIを「使うかどうかオプトイン」ではなく「使わないことが選択肢にならない」レベルで基盤に溶け込ませる。この戦略は長期的に見て競争優位になりうる。 SQL MIの自動チューニングやドリフト検出は、技術者が「実行ではなく判断と設計」に集中できる環境を着実に整えてくれている。「仕組みを作れる人だけが価値を出す」という世界が、Azureのマネージドサービスの中でも現実になりつつある。 ひとつ気になるのは、こうした機能が「プレビューで使えます」「ポータルから有効化してください」という案内で終わってしまうケースが多いことだ。せっかく良いものを作っているなら、標準有効・自動展開まで踏み込んでほしいと感じる。Azureの基盤としての力はある。あとはその力を現場が迷わず使いきれるUXへの磨き込みを期待したい。 廃止スケジュールについては、余裕があるうちに動くことが鉄則。「今動いているから大丈夫」という判断が後手に回る最大の原因だ。四半期に一度はAzureのRoadmapとRetirement noticesをチェックする習慣を、チームの文化として根づかせてほしい。 ...

AIエージェントが開発ワークフローの中に「入り込む」時代が静かに始まっている。Microsoft Foundryに新たに統合されたAzure DevOps Remote MCPサーバーは、その象徴的な一歩だ。 MCPとは何か、なぜ今これが重要なのか MCP（Model Context Protocol）は、AIモデルが外部システムのデータやツールに標準化された方法でアクセスするためのプロトコルだ。簡単に言えば、「AIエージェントが使えるAPIの共通規格」と考えてよい。 これまでAIをDevOpsツールと連携させるには、ローカルへのサーバーインストールや複雑な設定が必要だった。今回のアップデートでは、Streamable HTTP方式のリモートMCPサーバーがMicrosoft Foundryに直接統合されたことで、その障壁が大幅に下がった。 何ができるようになるのか 今回の統合により、AIエージェントはAzure DevOps上の以下のデータに直接アクセスできる： ワークアイテム（バックログ・スプリントボード・バグ等） プルリクエスト（PR）（差分・レビューコメント・承認状態等） テスト計画（テストケース・実行結果等） ローカルへのインストールは不要で、Microsoft Foundry上でのセットアップだけで動作する。エージェントがBacklogを読んで次の実装タスクを提案したり、PRの内容を理解してレビューコメントを生成したりするシナリオが、現実的なものになってきた。 Streamable HTTPが意味すること 従来のMCP実装はローカルプロセスとの標準入出力（stdio）通信が主流だった。Streamable HTTPへの移行は、MCPを「クラウドネイティブなプロトコル」へと昇格させる動きだ。認証・スケーリング・監査ログといった企業要件との親和性も高く、エンタープライズ利用に向けた実装として評価できる。 実務への影響——日本のエンジニア・IT管理者へ エンジニア視点：AIエージェントに「今スプリントのバックログを確認して、実装優先度を提案して」と指示するような使い方が近い将来に実用域に入る。今のうちにMCPの概念と、Azure DevOps上のデータ構造（ワークアイテムのフィールド定義等）を整理しておくと、エージェント活用の立ち上がりが速くなる。 IT管理者・アーキテクト視点：重要なのは認証・認可の設計だ。エージェントがDevOpsデータにアクセスする以上、どのエージェントが・どのプロジェクトの・どのスコープにアクセスできるかを明示的に管理する必要がある。Microsoft Entra IDによるアクセス管理が鍵を握る。「とりあえず全部アクセスできる」設定のまま運用するのは、人間のアカウントで同じことをするのと同様にリスクがある。 筆者の見解 MCP対応のRemoteサーバーがFoundryに統合されたことは、方向性として正しいと思う。「AIエージェントが自律的に判断・実行・検証を繰り返すループ」を設計する上で、DevOpsデータへのアクセスは不可欠なピースだ。バックログを読んでコードを書き、PRを作成し、テスト結果を確認して次のアクションを決める——こうしたループをプラットフォームが支えてくれるなら、開発の自動化は一段と現実味を帯びる。 Microsoft Foundryというエコシステムの中でこれが実現されている点も重要だ。エージェントの認証・認可をMicrosoft Entra IDで一元管理できる構造は、エンタープライズ利用において長期的に正しい戦略だと評価している。個々のエージェントが勝手に動き回るのではなく、プラットフォームが「管制塔」として機能する設計思想だ。 あとは、エージェントが「どこまで自律的に動いて良いか」のガバナンス設計が追いつくかどうかが問われる。ツールだけ先行して、運用ルールが空白のまま使い始める組織が出てこないよう、実装と並行してポリシー整備も進めてほしい。 Microsoftはエージェント時代のプラットフォームとして本気で動いている。今後の展開に注目したい。 出典: この記事は Azure DevOps Remote MCP Server Lands in Microsoft Foundry, Giving AI Agents Direct Access to Your DevOps Data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年4月2日、自社開発AIモデル3種——MAI-Transcribe-1（音声認識）・MAI-Voice-1（音声合成）・MAI-Image-2（画像生成・解析）——をAzure AI Foundry経由でリリースした。外部パートナーへの依存を減らし、AIスタック全体を自社でコントロールしようとする戦略的転換として注目される。 3モデルの概要と用途 MAI-Transcribe-1 は高精度な音声テキスト変換に特化したモデル。Officeアプリのディクテーション機能やアクセシビリティ機能、企業の会議録自動化ワークフローへの組み込みが期待される。 MAI-Voice-1 は自然な発音のテキスト読み上げ・音声合成エンジン。Teams会議のリアルタイム翻訳や、Narratorのような支援技術、さらにはオーディオブック生成といった用途を視野に入れている。 MAI-Image-2 は画像生成・編集・解析をカバーするマルチモーダルモデル。Paintやフォトアプリ、EdgeブラウザのAIアシスト機能など、Windowsに組み込まれた形での提供が見込まれる。 いずれも「Microsoft Foundry」イニシアティブの一環として開発されており、Azure APIを通じてエンタープライズ顧客が利用できる形でリリースされる。 なぜこれが重要か これまでMicrosoftのAI機能の多くはOpenAIのモデルに依存していた。この構造はコスト・セキュリティ・カスタマイズの自由度という3つの観点でリスクをはらんでいた。 今回の内製化戦略が意味するのは、Microsoftが「AIを使うプラットフォーム」から「AIを作るプラットフォーム」へ軸足を移すという宣言だ。特に日本企業にとっては、データレジデンシー（データの国内保管）や監査ログの透明性といった規制要件を満たしやすくなる可能性があり、医療・金融・公共分野でのAI活用が加速するきっかけになりうる。 Azureをすでに使っている組織にとっては、「同じテナント内で完結するAIサービス」が増えることはガバナンス面で大きなメリットだ。外部APIへのデータ送信に関する社内承認フローを簡素化できる可能性がある。 実務での活用ポイント Azure AI Foundryをすでに使っている場合: 新モデルはFoundry経由で利用できる。既存のプロジェクトでモデルを差し替えるだけで音声・画像機能を試せる。まずは開発・テスト環境で評価サイクルを回したい。 Teamsや会議録の自動化を検討中の場合: MAI-Transcribe-1はPowerAutomateやAzure Logic Appsと組み合わせることで、会議の文字起こし→要約→Teamsチャンネル投稿のフローを構築できる可能性がある。コスト試算を含めて早めにPoC（概念実証）を計画したい。 セキュリティ担当者・IT管理者向け: 自社モデルになることでデータフローの透明性が上がる。利用するモデルのAPIエンドポイントとログ出力先を確認し、既存のゼロトラスト構成（Microsoft Entra IDベースの条件付きアクセスなど）と整合性を取ること。 筆者の見解 MicrosoftがAIの内製化に本腰を入れるこの動きは、率直に言って「遅かった」という気持ちと「ようやく来た」という気持ちが混ざる。 Azureというプラットフォームの信頼性は揺るがない。Entra IDを軸にしたアイデンティティ管理、Teamsを中心としたコラボレーション基盤、そしてFoundryという統合開発環境——これらを横断して動かすエコシステムは、他のクラウドベンダーが簡単に真似できるものではない。最も多くのエージェントが安全に動作するプラットフォームを提供する競争では、Microsoftには構造的な優位性がある。 一方で、モデルそのものの性能がどこまで仕上がっているかは、今の段階ではまだ見えていない。MAI-Image-2が既存の画像生成AIと比べて実際にどう違うのか、MAI-Transcribe-1が日本語音声にどれだけ対応できるのか——数字と事例が出てきてから判断したい。 Microsoftには、プラットフォームとしての強みを活かして、モデルの良し悪しに関わらず「Azureで動かすのが一番安心」と感じさせる環境を整える力がある。今回の発表がその方向に向かっているなら、大いに歓迎したい。内製モデルがFoundryの中で他のモデルと横並びで比較・選択できる状態になれば、それがいちばん健全な未来だと思っている。 出典: この記事は Microsoft Launches MAI-Transcribe-1, MAI-Voice-1, and MAI-Image-2: A Strategic Shift to In-House AI Models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 の「長年の積み残し」が、いよいよ清算される。2026年4月2日を境に、SharePoint Online のレガシーコンプライアンス機能が一斉に廃止される。「まだ動いているから大丈夫」と先送りしてきた組織にとって、猶予は実質的に尽きた。 何が廃止されるのか 今回の廃止対象は、SharePoint の「旧世代の仕組み」が集中している領域だ。 コンプライアンス・レコード管理の旧機能（4月中） 情報管理ポリシー（Information Management Policies） インプレースレコード管理（In-Place Records Management） 削除専用ポリシー これらは UI からもアクセス不可になり、API 経由での呼び出しも動作しなくなる。移行先は Microsoft Purview の「データライフサイクル管理」および「Purview レコード管理」だ。 SharePoint 2013 ワークフロー（4月2日） かつてはほぼすべての承認フローで使われていたこの仕組みが、延長なしで完全終了する。移行先は Power Automate。複雑なフローを抱えている場合は、設計の見直しも含めた対応が求められる。 SharePoint アドイン（4月2日） 既存テナントでも動作停止となる。Microsoft 365 Assessment ツールでアドインの使用状況をスキャンし、SharePoint Framework (SPFx) への移行、またはベンダーへの対応依頼が必要だ。 Azure ACS（Access Control Service）の M365 サポート終了（4月2日） カスタムアプリや外部アプリが Azure ACS を使って SharePoint Online に接続している場合、4月2日以降は動作しなくなる。移行先は Microsoft Entra ID。特にサードパーティ製品が絡む場合は、ベンダー側の対応も確認が必要だ。 SPFx のドメイン分離 Web パーツ（4月2日） 特定のセキュリティ要件を持つ組織が使っていたこの機能も廃止。既存の Web パーツはエラーを返すようになるため、通常の Web パーツへの変換と再デプロイが必要だ。 実務への影響——日本のエンジニア・IT管理者が今すぐやること ステップ 1: 使用状況の棚卸し Microsoft 365 Assessment ツールを実行して、Azure ACS やアドインの利用状況を確認する。このツールは無料で使えるため、まず現状を把握することが優先だ。 ...

Microsoft 365 Copilotの管理機能に、待望のアップデートが届く。2026年4月下旬より、IT管理者はサードパーティAIモデルプロバイダーへのアクセスをテナント全体ではなくEntra IDグループ・ユーザー単位で制御できるようになる。AnthropicやxAIといった外部AIとCopilotを組み合わせて使っている組織、あるいは今後の導入を検討している組織にとって、ガバナンス設計の幅が一気に広がる変更だ。 何が変わるのか これまでの管理コンソールでは、サードパーティモデルプロバイダーの有効/無効はテナント全体での一括切り替えのみだった。つまり、一部の部門・一部のパワーユーザーにだけ外部AIを開放するといった使い分けは仕組み上できなかった。 今回のRoadmap ID 557371で追加されるのは、Microsoft Admin CenterにおけるEntra IDグループ/ユーザーへのプロバイダー割り当て機能だ。主な仕様は以下のとおり。 設定粒度: プロバイダー単位（個別モデルではなくプロバイダーごと） 最大割り当て数: グループ＋ユーザーの組み合わせで最大999まで。ネストされたグループにも対応 適用範囲: Microsoft Admin Center・Power Platform Admin Center（PPAC）・Copilot Studioで設定が一貫して反映される 対象: サブプロセッサーおよびインディペンデントプロセッサーの両方を含む現在・将来のすべてのサードパーティプロバイダー なお本機能は、AnthropicモデルをCopilot体験の一部でデフォルト有効化したMC1193920と連動している。テナント全体で自動有効化されるリスクを懸念していた管理者は、グループ単位で「見えている人だけに開放する」という運用をとれるようになる。 日本の現場への影響 日本企業の多くはMicrosoft 365を中核に据えながら、一方でAI活用の高度化に向けて「Copilot以外の選択肢」を模索している段階だ。この管理機能の登場が現場に与えるインパクトは大きく二つある。 ① 段階的な展開が現実的になる 全社一斉展開ではなく、まずAIリテラシーの高いチームや先行ユーザー数十名だけに外部モデルへのアクセスを開放する——そんなパイロット運用がEntraグループ一つで完結するようになる。変更管理コストが下がり、社内調整がしやすくなる。 ② ガバナンスとコンプライアンスの両立 データ保護の観点から「外部AIとのデータ連携に慎重でなければならない」という組織も多い。今回の変更でサードパーティモデルへのアクセスをEntraの条件付きアクセスポリシーと組み合わせて制御できる道が開ける。情報システム部門が「誰が何を使っているか」を可視化・統制しやすくなる点は、セキュリティポリシーを厳格に運用しているエンタープライズにとって歓迎材料だ。 実務での活用ポイント 4月下旬のロールアウトに備えて、今から準備できることがある。 既存設定の棚卸し: Microsoft Admin Centerで現在のAnthropic・xAI（米国のみ）の有効/無効状態を確認する グループ設計: Entraの既存グループをそのまま使えるか、外部AI利用用の新グループを切るかを設計しておく 影響範囲の特定: 既存のCopilot StudioエージェントやPower Automateフローが外部モデルに依存している場合、アクセス制限によって動作が変わる可能性があるため事前に確認する ヘルプデスクへの共有: アクセス範囲が変わることでエンドユーザーから問い合わせが来る可能性がある。事前に社内周知とサポートシナリオの準備を 筆者の見解 CopilotとサードパーティAIの「併用」は、もはや一部の技術好きだけの話ではなく、多くの組織が現実解として検討しているアプローチだ。Teamsの議事録やOutlookの定型業務はCopilotに任せながら、高度な分析や創造的なタスクには外部AIを活用する——こうした使い分けを組織ポリシーとして制御できる仕組みが整うのは、現場にとって素直にありがたい進化だと思う。 ひとつ注文をつけるとすれば、「プロバイダー単位」の制御に留まっている点だ。同一プロバイダーのモデル間でアクセスレベルを変えたい、というニーズは必ず出てくる。今後のロードマップでモデル単位への粒度の細分化を期待したい。 それ以上に重要なのは、こうした管理機能の整備とCopilot本体の実力向上を、Microsoftが同時並行で進めてほしいという点だ。ガバナンス基盤が整っても、主役のCopilot自体がより使いたいと思えるものになっていかなければ、管理の仕組みだけが空回りする。Microsoftには、この仕組みの拡充と並走するかたちで、Copilot本体のエクスペリエンスを磨き続けてほしい。M365というプラットフォームが持つポテンシャルは、本来それだけの期待に十分応えられるはずだから。 出典: この記事は Microsoft 365 Copilot: Admins will be able to enable third-party model providers for specific users and groups の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

ある人気AIコーディングツールのソースコードが先日誤って流出し、開発者コミュニティに大きな波紋を呼んだ。話題の中心は「流出」という事実よりも、コードの中身──端的に言えば、驚くほど雑に書かれていたという点だ。「バイブコーディング（vibe coding）の産物」と揶揄する声も上がったが、このツールは年間経常収益（ARR）25億ドル（約3750億円）を1年未満で達成した超ヒット製品。この矛盾が、ソフトウェア開発の根本を問い直す議論に発展している。 「ゴミコード」が数千億円規模のプロダクトを生む時代 流出コードを見た開発者たちの第一反応は「これは酷い」だった。コードレビューなら即リジェクト案件、と言う声もあった。しかし冷静に考えれば、これは単純に「雑なコードでも売れる」という話ではない。 核心にあるのは製品市場適合（Product-Market Fit / PMF）だ。このツールは開発者・デザイナー・プロダクトマネージャー・マーケター、さらにはCEOまでが熱狂して使っている。ユーザーが評価するのは「コードがどう書かれているか」ではなく「何が解決されるか」だ。 この現実は、SaaSに限った話でもない。すべてのソフトウェアに当てはまる原則だ。コードが美しいかどうかより、ユーザーが抱える課題を本当に解決できているか──それが製品の価値を決める。 品質担保の哲学が根本から変わりつつある このツールの開発者インタビューが非常に示唆に富んでいた。チームが重視しているのはオブザーバビリティ（可観測性）とセルフヒーリング（自己修復）システムだという。 従来のQAは「コードを読んでバグを見つける」だった。しかし新しいアプローチはこうだ。 「ユーザーが今ログインできない」とシステムが検知し、問題を引き起こしたコードを自動で変更・リバートする コードを文字レベルで完璧にするのではなく、変化の影響を素早く検知し自動対応できる仕組みを設計することで開発速度を最大化する発想だ。多少のリスクを受け入れながら高速でイテレーションし、問題はシステムが拾う──この設計思想が「汚いコードでも高品質なプロダクト」を実現している。 著作権という皮肉なブーメラン 今回の騒動にはもうひとつ見逃せない側面がある。著作権の問題だ。 AIのトレーニングデータと著作権をめぐる訴訟の当事者として名が上がることもある企業が、今度は自社コードの流出・無断利用を気にしなければならない立場になった。著作権という問題がAI時代においていかに複雑で双方向的かを象徴するエピソードだ。この議論はまだ決着がつかず、今後も業界全体に影響を与え続けるだろう。 実務への影響──日本のエンジニア・IT管理者へ 1. コードレビューの優先度を問い直す 全コードを完璧に仕上げることにリソースを注ぐより、本当にリスクが高い領域（セキュリティ・認証・課金処理等）に集中する配分の見直しを検討したい。全量精査は限界に来ている。 2. オブザーバビリティへの先行投資 Application InsightsやDatadogのような監視ツールを、コードを書いた後ではなく最初から設計に組み込む姿勢が重要だ。問題を素早く検知できる仕組みは、きれいなコード以上の価値を持つ。 3. 「動くものを出してループを回す」サイクルへ 日本企業は品質へのこだわりが強い。それは美徳だが、AIが書いたコードを人間が全て精査するフローはスケールしない。「自動検知→自動修正→再デプロイ」のループを設計することで、品質担保の考え方自体を更新するタイミングが来ている。 筆者の見解 「雑なコードでも大成功した」という文脈で語られがちなこの話だが、本質はそこではないと思っている。 本当のポイントは、品質担保の責任がコードの丁寧さから、システムの自律的な修復能力へと移行しつつあるという構造変化だ。コードを書く人間の腕前ではなく、そのコードが動く環境と「監視→修正→検証のループ」の設計品質が、ソフトウェアの信頼性を決める時代になりつつある。 AIエージェントが自律的に判断・実行・検証を繰り返すループを設計する──そのアーキテクチャこそが次のソフトウェア開発の主戦場だ。コードの品質論から、システムの自律性と回復力の議論へ。今回の流出騒動は、その転換点を象徴するエピソードとして記憶されるかもしれない。 日本のエンジニア文化においては「美しいコード＝良いエンジニア」という価値観が根強い。それ自体は悪くない。だが、その美学を追い求めるあまりリリースが遅れ、PMFの検証が後回しになるなら本末転倒だ。コードへのこだわりは大切にしながらも、「何を担保するための品質なのか」を今一度問い直すことが、AI時代のエンジニアに求められているのではないだろうか。 出典: この記事は The Claude Code Leak の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「DoSだから少し待って」が命取りに 2025年10月に公開されたF5 BIG-IP APMの脆弱性（CVE-2025-53521）が、2026年3月に入り「リモートコード実行（RCE）が可能」と再分類された。当初はサービス拒否（DoS）扱いだったため、パッチ適用を後回しにした組織も少なくないだろう。しかし状況は一変している。認証なしのリモートコード実行——これはセキュリティ上の最高水準のリスクだ。 インターネット脅威監視団体のShadowserverによると、2026年4月時点でBIG-IP APMのフィンガープリントを持つIPが17,100件以上確認されており、そのうち1万4千台以上が依然としてCVE-2025-53521の攻撃にさらされた状態にある。米国土安全保障省のCISAが連邦機関に対し月曜日深夜までのパッチ適用を義務付けるほどの緊急事態にもかかわらず、だ。 BIG-IP APMとは何か、なぜ狙われるのか F5 BIG-IP APM（Access Policy Manager）は、組織のネットワーク・クラウド・アプリケーション・APIへのアクセスを一元管理するプロキシ製品だ。Fortune 50企業の48社を含む世界2万3千社以上が採用する、エンタープライズセキュリティの要衝といえる。 この製品の性質上、BIG-IP APMが侵害されれば組織全体のアクセス制御が崩壊する。過去にも国家支援型のAPTグループやサイバー犯罪集団が、BIG-IPの脆弱性を悪用して企業ネットワーク侵入・データ窃取・マルウェア展開を行ってきた。今回のRCE再分類を受けF5は、侵害の証拠（IOC）を公開するとともに「感染が確認された場合はシステムを一から再構築することを強く推奨する」と明言している。 特に注意が必要なのは、UCS（ユーザー設定バックアップ）ファイルだ。F5は「侵害後に作成されたUCSファイルにはマルウェアが混入している可能性がある」と警告しており、信頼できるソースからの設定再構築を求めている。侵害タイミングが不明な場合、バックアップ自体が汚染されているリスクがある。 日本企業へのリスク BIG-IP APMは日本の大手エンタープライズでも広く採用されている。金融・製造・通信など、アクセス管理基盤にF5製品を使っている組織は少なくない。今回の問題でとりわけ重要なのは以下3点だ。 1. 仮想サーバーにアクセスポリシーを設定しているか確認 今回の脆弱性は「仮想サーバーにアクセスポリシーが設定されている構成」で悪用可能とされる。自組織の構成がこれに該当するかを即座に確認すること。 2. ディスク・ログ・ターミナル履歴を精査 F5が公開したIOCを参照し、すでに侵害されていないかをチェックする。「今動いているから大丈夫」という判断は禁物だ。 3. パッチ未適用なら今すぐ適用 F5が修正済みバージョンを提供済み。オリジナルのCVEに対するパッチがRCEにも有効であることが確認されている。テスト後、速やかに適用する。 筆者の見解 セキュリティを生業にしているわけではないが、こうした「後になって深刻度が上がる脆弱性」の問題には構造的な課題を感じる。「DoSだからすぐには死なない」という心理は理解できる。しかし攻撃者はその猶予の間に足場を築く。今回のケースは、脆弱性の最初の開示情報だけで判断するリスクを端的に示している。 アクセス管理製品は「すべての扉の鍵束」を握っている。そこが侵害されれば、背後にある多層防御の多くが無意味になる。ゼロトラストアーキテクチャを整備していても、その認証・認可の入り口自体が突破されれば設計思想ごと崩れる。 日本の大エンタープライズでは、「ベンダーのサポート範囲外の古いバージョンが生き続けている」「本番への変更は四半期に一度の変更管理」という現場も珍しくない。残念ながらこの種のケースで「間に合わなかった」という話が後から出てくることは珍しくない。攻撃者はそのペースに合わせてくれない。 対応は複雑ではない。パッチを当て、IOCを確認し、疑わしければ再構築する。それだけだ。「今週末に」「来月の変更管理で」という判断が、どれだけのリスクを生んでいるかを、今一度チームで確認してほしい。 出典: この記事は Over 14,000 F5 BIG-IP APM instances still exposed to RCE attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

人気HTTPライブラリ「Axios」で発生したサプライチェーン攻撃のポストモーテムが公式に公開された。今回特に注目すべきは、単なる無差別攻撃ではなく、特定のメンテナを徹底的に調査した上で仕掛けられた「個別ターゲティング型」のソーシャルエンジニアリングだった点だ。OSSエコシステムに関わるすべての開発者が知っておくべき手口が、克明に記録されている。 攻撃の全手順：精巧すぎる罠 メンテナのJason Saayman氏への攻撃は、以下のステップで実行された。 1. 企業・人物の完全クローン 攻撃者はある実在企業を模倣し、その創設者の外見までなりすまし、Saayman氏に接触してきた。単なるメール詐欺ではなく、企業ブランドと人物像を丸ごと模倣した精巧な偽装だ。 2. 説得力のある偽Slackワークスペース 本物の企業名・CIブランドを冠したSlackワークスペースに招待。LinkedInの投稿シェア、他のOSSメンテナの（おそらく偽の）プロフィールまで用意され、非常に自然な「業界コミュニティ」の雰囲気が演出されていた。 3. Microsoft TeamsでのミーティングとRAT投下 複数の「参加者」が揃ったTeamsミーティングを設定。ミーティング中に「お使いのシステムが古い」と表示され、Teamsの動作に必要なものだと思い込んでインストールしたのがRAT（Remote Access Trojan）だった。この罠で認証情報が窃取され、攻撃者はAxiosのリポジトリに悪意ある依存パッケージを公開することに成功した。 この手口はGoogleのThreat IntelligenceチームがUNC1069として文書化している攻撃グループのパターンと一致しており、暗号資産・AI関連企業を標的にした活動として知られる。 なぜこれが重要か 「ソーシャルエンジニアリングに注意」は耳タコな話だ。しかし今回の攻撃は次元が違う。本物そっくりのSlackワークスペース、実在企業の精巧なクローン、複数人が関与するTeamsミーティング——ここまでの工数と精度で特定個人を攻撃するケースは、以前は国家レベルのAPT攻撃でしか見られなかった。それが今やnpmパッケージのメンテナを標的に実行されている。 日本企業でも多数のプロダクトがAxiosに依存しており、悪意あるバージョンがインストールされた環境があればリスクは無視できない。サプライチェーンセキュリティはもはや「大企業だけの話」ではない。 実務での活用ポイント OSSメンテナ・開発者向け ミーティング直前の「ソフトウェアインストール要求」は即座に疑え。時間的プレッシャーは攻撃者が意図的に作り出すものだ 初回コンタクトで別のチャンネルへ誘導してくる相手は要注意 LinkedInや企業サイトが本物そっくりでも、それだけでは信頼の根拠にならない npmやGitHubのリリース権限は多要素認証＋物理セキュリティキーで保護する IT管理者・セキュリティ担当者向け 依存ライブラリの整合性チェック（npm audit、SBOMの活用）を自動化する 新バージョンリリース直後の依存アップデートに対し、短時間の検証フェーズを設ける 開発者向けセキュリティトレーニングにサプライチェーン攻撃の具体的シナリオを組み込む 筆者の見解 今回の攻撃でTeamsが最後の一手として使われた点は気になる。攻撃者はTeamsの普及度と「ミーティング直前に何かインストールしなければ」という心理的プレッシャーを巧みに利用している。Teamsそのものの問題ではないが、正規のインストール要求と偽物を区別しにくい現状は課題だ。Microsoftには、こうした手口を踏まえたセキュリティアドバイザリの強化や、インストール要求をより明確に識別できるUX改善を期待したい。ブランドとエコシステムを持つMicrosoftだからこそ、こういう部分で業界をリードしてほしい。 より根本的な問題として、OSSエコシステムはごく少数のメンテナが巨大なサプライチェーンの鍵を握る構造的脆弱性を抱えている。Axiosは週次ダウンロード数が数千万件規模のライブラリだ。一人のメンテナへのソーシャルエンジニアリングが世界中のシステムに影響し得る。 「禁止」や「ゼロトラスト」だけでは解決しない。メンテナが安全に作業できる環境、二人以上のレビューが必要なリリースフロー、そして実例を具体的に共有するコミュニティの文化こそが必要だ。今回Axiosチームが詳細なポストモーテムを公開したことは、その意味で業界全体への貴重な貢献だと思う。 出典: この記事は The Axios supply chain attack used individually targeted social engineering の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIの競争は、チャットボットや開発者ツールの領域を超えて、いよいよ「科学研究そのもの」へと踏み込み始めた。Anthropicが米バイオテックスタートアップ「Coefficient Bio」を約4億ドル（約590億円）の株式取引で買収したと報じられた。生成AIが創薬や生命科学の現場をどう変えるか、その輪郭が一気に鮮明になってきた。 Coefficient Bioとは何者か Coefficient Bioは、創業わずか8か月のステルス系スタートアップだ。創業者のSamuel StantonとNathan C. Freyはいずれも、大手製薬グループ・Genentechの計算創薬部門「Prescient Design」出身。AIを活用して創薬プロセスや生物学的研究の効率化を目指しており、従業員は約10名という小規模な組織だった。 その規模でこの買収額が意味することは大きい。1人当たり換算で40億円超。テクノロジー業界でも屈指の「才能への賭け」といえる。 なぜ今、創薬×AIなのか 従来の創薬プロセスは、1つの新薬を市場に出すまでに平均10〜15年、費用は2,000〜3,000億円に上るとも言われてきた。失敗率も非常に高く、製薬業界全体として効率化は長年の悲願だった。 AIは、この「効率の壁」を突破する有力な手段として注目されている。具体的には以下のような場面での活用が進んでいる： タンパク質構造予測：創薬ターゲットとなる分子の立体構造を高速に推定 候補化合物の絞り込み：膨大な化学空間から有望な分子を事前スクリーニング 臨床試験の設計最適化：過去のデータからより効率的な試験設計を提案 論文・データの大規模解析：最新の研究知見をリアルタイムで統合 Anthropicは昨年10月に「Claude for Life Sciences」を発表。科学研究者が発見を加速するためのツールとして医療・生命科学分野への本格参入を宣言していた。今回の買収はその続きであり、単なるツール提供にとどまらず、専門人材と研究ノウハウを取り込む形で垂直統合を進めている。 日本のエンジニア・IT管理者への影響 このトレンドは、日本の医療・製薬・バイオ業界のIT部門にとっても他人事ではない。 製薬・ヘルスケア企業のIT部門向け ライフサイエンス向け生成AIの導入検討サイクルが想定より早まる可能性がある。既存の研究情報システム（ELN：電子実験ノートなど）との統合シナリオを今から描いておくことが重要 データガバナンス・プライバシーの観点から、どのデータをクラウドAIに流せるかを整理する作業が急務になる エンジニア・開発者向け バイオインフォマティクス（生物情報学）とLLM（大規模言語モデル）の融合領域は、次の数年で需要が急拡大する可能性がある。PyMOL、RDKit、Biopython等の生命科学系ライブラリとAI APIの組み合わせを試しておく価値がある 「研究データを扱うエージェント設計」の知見は、製薬だけでなく食品・農業・素材など幅広い産業に転用できる 筆者の見解 今回の動きを見て思うのは、AIがいよいよ「知識労働の自動化」から「発見プロセスの自動化」へと踏み出したということだ。 単に文書を要約したり、コードを補完したりする段階は、振り返ればウォーミングアップに過ぎなかった。これからのAIエージェントに求められるのは、目的を与えれば自律的に実験を計画し、結果を検証し、次の仮説を立てて繰り返すループを回せる能力だ。創薬とはまさにそのループを何千回・何万回と繰り返す営みであり、AIとの親和性は極めて高い。 日本の視点で言えば、製薬分野では武田薬品や第一三共が海外のAIスタートアップとの連携をすでに加速している。こうした動きに「ITシステム側」がついていけるかどうかが、今後5年の競争力を左右すると思う。ライフサイエンス領域でのAI活用は「やるかやらないか」の段階をとっくに過ぎており、「どう本格展開するか」のフェーズに入りつつある。 一方で懸念もある。創薬AIには膨大な実験データと専門知識が不可欠だ。データの品質や科学的妥当性の担保なしに「AIが薬を作った」という誇大な期待が先行すると、のちに大きな反動が来る。技術の可能性を信じつつも、地道に科学的検証を積み重ねるプロセスを省略しないことが、この分野の長期的な信頼構築には欠かせない。今回の買収が、そうした誠実なアプローチの上に成り立つものであることを期待したい。 出典: この記事は Anthropic buys biotech startup Coefficient Bio in $400M deal: Reports の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIで相次ぐ幹部異動が明らかになった。急成長を続けるAI企業が「組織の成熟化」という避けられない課題に直面する中、それでも推進力を失わない体制づくりを見せた形だ。 何が起きたか Fidji Simo（AGI開発担当CEO）が社内向けメモで発表した内容によると、主な変更点は以下の通りだ。 Brad Lightcap（COO） は「特別プロジェクト（Special Projects）」担当の新役職へ移行する。複雑なディールや投資案件を横断的に担当し、Sam Altman CEOに直接報告する体制となる。COOとしての商業業務は後任に引き継がれる。 Denise Dresser は元SlackのCEOで、最近OpenAIに最高収益責任者（CRO）として参画した人物。Lightcapが担っていたビジネス面の職責を引き継ぐ。 Fidji Simo本人 は神経免疫疾患の治療のため、数週間の医療休暇に入る。「避けられる限りのことはすべて試みたが、残念ながら体が言うことを聞かない」とメモに記した。休暇期間中は共同創業者でもあるGreg Brockman会長が製品部門を管轄する。 Kate Rouch（CMO） はがんの治療に専念するため退任。体調が回復した段階で「より範囲を絞った別の役職」に復帰する予定で、新CMOの採用活動も始まる。 なぜこれが重要か OpenAIは現在、世界で約10億人のユーザーを抱えると発表している。スタートアップとして産声を上げた組織が、事実上のグローバルテクノロジー企業として機能し始めた時に起きがちな変化がまさに今起きている。 注目すべきは「特別プロジェクト」という新設ポジションの意味だ。COOという執行機能からAltman CEOの直轄ラインへのシフトは、戦略的なディールや投資判断を最高権力層に集約しようとする意図を示している。Lightcapが培ってきた幅広いビジネスネットワークを「攻め」に活用する布石と読むことができる。 Denise DresserはSlack CEO時代に大企業向けコラボレーション文化を根付かせた実績を持つ。エンタープライズ展開を本格加速させたいOpenAIにとって、彼女の起用は理にかなった人事だ。 実務への影響 — 日本のエンジニア・IT管理者にとって 短期的な影響は限定的だ。OpenAI自身が「継続性と推進力を持って実行できる体制が整っている」とコメントしており、API・製品のロードマップに直接的な変更は見込みにくい。 ただし、エンタープライズ契約を検討・交渉中の組織は以下の点を注視しておく価値がある。 商業部門の刷新：Dresserの就任により、エンタープライズ向けの価格体系やサポート体制が変化する可能性がある。現在交渉中・更新時期が近い契約は動向を確認しておきたい 製品判断権の一時的な変化：Brockmanが製品を管轄する期間中、研究寄りの判断が強まる可能性もある。新機能リリースのタイミングへの影響は軽微だろうが、念頭に置いておきたい CMO交代の余波：マーケティング・コミュニケーション戦略が一時的に不安定になりうるが、中長期の事業影響は軽微とみている 筆者の見解 この種の幹部異動は、「成長企業が成熟する証」として概ねポジティブに捉えていい。 COOを特別プロジェクト担当にシフトし、元Slack CEOを収益責任者に据える——これは、製品・研究優先のカルチャーが強かったOpenAIが、本格的にエンタープライズ市場を取りにいくという意思表示だ。Fidji SimoとKate Rouchの健康問題については、ただ回復を願うばかりだ。 気になるのは「特別プロジェクト」の具体的な中身だ。「複雑なディールや投資」という言葉は意図的に曖昧に書かれている。大型パートナーシップ、M&A、政府・規制当局との折衝——何が含まれるのかによって、OpenAIの次のフェーズが見えてくる。2026年後半の動きに注目したい。 AIの世界は今、製品そのものの優劣を競う段階から、いかに大規模に普及・定着させるかという段階に移行しつつある。今回の体制変更はその文脈で読むべきだろう。どのAIツールを活用する立場であっても、OpenAIが安定した組織として長期的に研究と製品開発を続けることは業界全体の底上げにつながる。その意味で、この組織変更が円滑に機能し、ロードマップが着実に前進することを期待している。 出典: この記事は OpenAI executive shuffle includes new role for COO Brad Lightcap to lead ‘special projects’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米ユタ州が、AIチャットボットに精神科薬の処方更新を認める1年間のパイロットプログラムを開始した。医師の関与なしにAIが臨床判断の一端を担うという前例のない試みは、医療アクセスの拡大という希望と、安全性への懸念を同時に呼び起こしている。 何が起きているのか サンフランシスコのスタートアップ「Legion Health」が開発したAIチャットボットが、ユタ州の規制当局との合意のもと、一定条件を満たす患者に対して精神科薬の処方更新を行えるようになった。月額19ドル（約2,900円）のサブスクリプションで、「迅速でシンプルな処方更新」を提供するという。 重要なのはそのスコープの狭さだ。対象となるのはフルオキセチン（プロザック）、セルトラリン（ゾロフト）、ブプロピオン（ウェルブトリン）など、すでに医師から処方されている15種類の低リスク維持薬のみ。新規処方や血液検査が必要な薬、ベンゾジアゼピン系薬（抗不安薬）、抗精神病薬、リチウム（双極性障害の標準治療薬）は対象外だ。 患者側の条件も厳格で、「安定している」と判断された既存患者のみが対象。直近1年以内に入院歴があったり、用量変更があった場合は除外される。10回の更新ごと、または6カ月ごとに医師との確認が義務付けられており、「AIが全部やる」わけでは決してない。 なぜこの試みが生まれたのか 背景にあるのは深刻な医療アクセス問題だ。ユタ州だけで50万人もの住民がメンタルヘルスケアを受けられていないという。精神科医や心療内科医の絶対数が足りない。地方や低所得層は特に深刻で、診療予約まで数カ月待ちという状況は珍しくない。 この問題は日本でも無縁ではない。精神科・心療内科の初診待ち期間は都市部でも数週間〜数カ月に及ぶことが多く、「クリニックに繋がれれば御の字」という現実がある。維持処方のためだけに月1回の通院を繰り返すという構造的非効率は日本でも同様だ。 医師コミュニティの懸念 これに対し、精神科医たちは複数の問題点を指摘している。 システムの不透明性がまず挙げられる。AIがどのような基準で「更新可」と判断するのかが外部から検証しにくい。精神状態のアセスメントは非常に繊細で、テキストや定型質問だけでは捉えきれないニュアンスがある。 また「本当に必要な人に届くか」という疑問もある。$19/月というコスト、スマートフォン操作の必要性、英語でのやりとり——これらのハードルを越えられる人はすでにある程度のリソースを持っている人だ。最も支援が必要な層にリーチできるかは不明確だと批判する声もある。 実務への影響：IT・医療DX担当者の視点で このパイロットが示すのは、AIを「補助ツール」ではなく「プロセスの一部として組み込む」設計への転換だ。以下のポイントはITや医療DXに関わるエンジニア・管理者にとって参考になる。 スコープの厳密な定義が鍵 AIに委譲するタスクを「維持薬の更新のみ」「安定患者のみ」と極限まで絞っている。これはAI導入設計の基本だが、特に安全性が求められる業務では「何をやらせないか」の定義が「何をやらせるか」と同等かそれ以上に重要になる。 エスカレーションパスの設計 リスクサインを検知した場合に人間のクリニシャンへ引き渡す仕組みが明確に定義されている。AI自律化のデザインパターンとして、「完全自律」ではなく「条件付きエスカレーション」モデルはエンタープライズ導入においても参考になる。 規制サンドボックスの活用 ユタ州は「AI政策局（Office of Artificial Intelligence Policy）」という専門組織を持ち、法整備より先に実証できる仕組みを用意している。日本でも規制のサンドボックス制度は存在するが、医療AIへの適用は遅れており、制度設計の議論が急がれる。 筆者の見解 「これが大丈夫なのか」という直感的な不安は理解できる。精神科の薬は効果も副作用も個人差が大きく、「安定しているかどうか」の判断はそれ自体が高度な臨床スキルだ。だからこそ今回の設計があえてスコープを極限まで絞ったことは、むしろ誠実だと思う。 重要なのは「AIが精神科医を代替する」ではなく、「精神科医にしかできない仕事に精神科医の時間を集中させる」という発想だ。維持薬の更新確認という、ある種の定型タスクをAIが担うことで、医師が複雑なケースに集中できる——その全体最適の発想は正しい方向性だと感じる。 AI自律化の設計において、「人間の承認を都度求め続ける副操縦士型」と「条件定義の中で自律的に動き続けるエージェント型」の間には大きな差がある。今回のモデルはその中間に位置するが、「安定患者×低リスク維持薬×定期エスカレーション」という条件設計は、自律性と安全性を両立しようとした真剣な試みとして評価できる。 ただし、「このパイロットが成功する」ことと「このモデルが広がる」ことは別の話だ。50万人のアクセス問題は本物だが、その解決策がAI処方更新の普及である必要はない。遠隔診療の整備、保険適用の見直し、精神科医の養成——AIが医療格差を解消する手段になりうるとすれば、それは処方権限の委譲よりも、診断支援・トリアージ支援という形の方が当面は現実的かもしれない。 世界初の試みが安全に完走できるかどうか。この1年のデータが、医療AIの未来地図を大きく書き換える可能性がある。 出典: この記事は Chatbots are now prescribing psychiatric drugs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「ゼロデイを探せ」——そう指示するだけでよくなる日が来る セキュリティ研究の世界に、静かだが根本的な地殻変動が起きている。著名なセキュリティ研究者 Thomas Ptacek が発表した考察「Vulnerability Research Is Cooked（脆弱性研究は終わった）」は、最前線の大規模言語モデル（LLM）エージェントが、脆弱性探索の実践と経済性を「段階的にではなく、階段関数的に」変えようとしていると主張している。 「ソースツリーにエージェントを向けて『ゼロデイを探してくれ』と入力するだけで、大量の高インパクトな脆弱性研究が成立する時代がくる」——この一文は、セキュリティコミュニティに大きな波紋を呼んでいる。 なぜエージェントは脆弱性探索が得意なのか LLMはすでに膨大な「バグ知識」を内包している フロンティアモデルと呼ばれる最高性能の LLM は、学習済みの重みの中に、これまで文書化されてきたほぼすべての「バグクラス（bug classes）」を内包している。 ステールポインタ（stale pointer）: 解放済みメモリへの参照 整数ミスハンドリング（integer mishandling）: オーバーフローや符号の扱いミス 型混乱（type confusion）: 異なる型として誤解釈されるオブジェクト アロケータグルーミング（allocator grooming）: ヒープ配置を意図的に操作する手法 Linux KVM ハイパーバイザーが hrtimer サブシステムや workqueue、perf_event とどう接続されているか——そういった深い依存関係の知識も、すでにモデルの重みに焼き込まれている。 脆弱性探索はLLMが最も得意な問題と一致する Ptacek が指摘する核心はここだ。脆弱性の発見とは本質的に、「パターンマッチング（バグクラスの照合）＋制約解決（到達可能性・悪用可能性の検証）」の組み合わせだ。これはまさに LLM エージェントが最も得意とする暗黙的な探索問題である。 さらに重要な点として、エクスプロイト検証の成否は「動くか・動かないか」という明確なフィードバックで返ってくる。エージェントは疲れることなく、指示する限り探索し続けられる。 実務への影響——攻撃者も防御者も同じツールを使う 日本のセキュリティチームへの示唆 この変化は、攻撃側と防御側の双方に等しく影響する。 攻撃側：これまで熟練した研究者が数週間かけて行っていた脆弱性探索が、エージェントによる自動化で劇的に短縮される。「既知脆弱性のパッチ未適用」という日本企業に多いリスクは、これまで以上に危険な状態になりうる。 防御側（Defender）：同じツールを使えば、自社システムの脆弱点を攻撃者より先に見つけることができる。ペネトレーションテスト（侵入テスト）の在り方が大きく変わり、より広いカバレッジを低コストで実現できる可能性がある。 実務で今すぐ考えるべきポイント 自動脆弱性スキャンの戦略を見直す: 従来の SAST/DAST ツールに加え、LLM エージェントを活用したコードレビューの試験的導入を検討する時期に来ている パッチ適用の優先度と速度を上げる: エージェントによる発見・悪用のサイクルが加速する前提で、パッチ管理の SLA を再設定する セキュリティ研究者の役割を再定義する: 手動での脆弱性調査から、エージェントの指示設計・出力検証・倫理的判断という上位レイヤーへのシフトを今から準備する Bug Bounty の経済性変化に備える: 脆弱性発見の参入障壁が下がると、プログラムへの報告数が急増する可能性がある 筆者の見解 この話を読んで真っ先に思ったのは、「これはまさにエージェントの本質が問われる分野だ」ということだ。 AIエージェントが真に価値を発揮するのは、人間への確認・承認を繰り返す「副操縦士」的な設計ではなく、自律的に判断・実行・検証のループを回し続ける設計においてだ。脆弱性研究はその典型で、「コードを解析 → バグクラスと照合 → 到達可能性を検証 → 試行する → 結果を確認 → 次を試す」という繰り返しのループこそがエクスプロイトの本質だ。エージェントが疲れを知らずにこのループを回し続けられるという特性が、まさにここで爆発的な威力を発揮する。 ...

GitHubのCOOであるKyle Daigle氏が公開した統計が、開発者コミュニティに波紋を広げている。2025年の年間コミット数は10億件だったが、2026年に入って週2.75億件ペースにまで急騰。このまま成長が続けば年間140億件に達する計算だ。同時にGitHub Actionsの実行時間も2023年の週5億分から2025年に週10億分、そして現在は週21億分と、わずか数年で4倍以上に膨れ上がっている。 何がコミット数を爆発的に増やしているのか 数字だけを見れば「何かの誤りでは」と思うほどの急増だが、現場の肌感覚と照合すると辻褄が合う。AIアシスタントを使ったコーディングが当たり前になるにつれ、1人のエンジニアが1日に書けるコード量・コミット頻度は飛躍的に上がっている。以前なら「大きな機能ブロックをまとめてコミット」が普通だったが、今は細かい反復サイクルで何度もコミットを積み上げるスタイルが定着しつつある。 加えて、AIエージェントが自律的にリポジトリを操作するケースも増えている。人間が書くのではなく、エージェントがブランチを作り、コードを生成し、テストを実行してプルリクエストを投げる——そうしたワークフローが普及すれば、コミット数が人間の頭数に比例しなくなるのは当然だ。 GitHub Actionsの急成長が示すもの コミット数と並んで注目したいのがGitHub Actionsの数字だ。週21億分という実行時間は、単に「CI/CDを使う人が増えた」では説明がつかない水準に達している。 背景にあるのは、AIが生成したコードを自動検証するパイプラインの拡大だろう。コードがAIによって大量生成される世界では、それを検証・テスト・デプロイするための自動化基盤の需要も比例して増える。GitHub Actionsはその受け皿として機能している。 日本企業の多くはまだCI/CDの導入率そのものが低く、「GitHub Actionsをフル活用している」という現場は限られる。だが海外では、AIコーディング→自動テスト→自動デプロイのサイクルが当たり前のインフラになりつつある。この差は今後のエンジニアリング生産性に直結する。 実務への影響——日本のエンジニア・IT管理者へ ① コスト設計を見直す GitHub ActionsはPublicリポジトリなら無料だが、Privateリポジトリでは実行時間に応じた課金が発生する。AIエージェントが自律的にActionsを起動するようになると、想定外の課金増が起きやすい。Actionsの実行時間を定期モニタリングする習慣と、月次予算アラートの設定を今すぐ確認しておくべきだ。 ② セルフホストランナーの検討タイミング 実行時間が増えるほど、GitHub-hosted runnerよりセルフホストランナーのコスパが良くなる閾値に近づく。Azure VMやAzure Container Instancesでセルフホストランナーを動かす構成は、特にEnterpriseプランを使う日本企業には現実的な選択肢だ。 ③ ブランチ戦略・コードレビュー体制の再設計 AIが大量のコミットを積み上げる世界では、従来の「人間がすべてのコードをレビューする」前提が崩れる。レビュー自動化・品質ゲートの自動化をどこまで進めるか、組織のポリシーとして明文化する必要がある。 筆者の見解 GitHubはMicrosoftが2018年に買収して以来、開発者プラットフォームとして着実に成長を続けてきた。今回のデータはその集大成とも言える数字で、素直に評価していい。 ただ、ここで大事なのは数字の裏にある構造変化だ。「コミットが増えた」のではなく「AIエージェントがコードを書く量が増えた」と読み替えたとき、開発現場のあり方は根本から変わる。自分でコードを書くことよりも、AIが回すループを設計・管理する能力が問われる時代になってきた。 個人的に今一番注目しているのは、AIエージェントが自律的に判断・実行・検証を繰り返すハーネスループの設計だ。単発の指示と応答を繰り返すだけでは、この数字の伸びについていけない。エージェントが連続して動き続ける仕組みをどう構築するか——それが今のエンジニアリングの最前線だと感じている。 日本の多くの現場ではまだAIコーディングの導入すら遅れているが、海外の数字はもうここまで来ている。「うちはまだそこまで」と思っているうちに、気づけば取り返しのつかない差が開く——そういうフェーズに入ってきた、というのが正直な実感だ。 出典: この記事は Quoting Kyle Daigle の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが2026年4月4日より、Claudeの定額プランをOpenClawなどのサードパーティ製「ハーネスツール」から利用できないよう変更した。AIエージェントが日常業務を自律的に代行するツールが急成長する中、プラットフォーム側の容量管理と利用者の自由の間に、初めて本格的な摩擦が生じた形だ。 何が変わったのか 変更の核心は「サブスクリプションの利用枠をサードパーティハーネスに使えなくなる」という点だ。これまでOpenClawユーザーはClaude Proなどの定額プランのリクエスト枠をそのまま流用できたが、今後は別途「従量課金バンドル」を購入するか、Claude APIキーを直接使う必要がある。 Anthropic側は既存ユーザーへの配慮として、月額プランと同額の一時クレジットを付与。割引バンドルの提供と全額返金の選択肢も用意している。同社Claude Code担当エグゼクティブのBoris Cherny氏は「急増する需要に対応するため、自社製品とAPIを優先する必要がある」と説明した。 OpenClawとは何か、なぜここまで広がったか OpenClawは受信トレイの管理・カレンダー調整・フライトチェックインといった「人間がやっている反復タスク」をAIが自律的に代行するツールとして、今年初めに爆発的に普及した。AIモデルの前後に処理を差し込み、自律ループを実現する「ハーネス」の先駆的な実装として注目を集めた。 シンプルな使い勝手と強力な自動化能力が口コミで広がり、Anthropicのインフラに想定外の負荷をかける規模にまで成長した。 競合ダイナミクスも背景に 今回の変更には、もう一つ見逃せない文脈がある。OpenClawを開発したPeter Steinberger氏がすでにOpenAIへ転職済みという事実だ。Steinberger氏は「Anthropicを説得しようとしたが、せめて1週間の猶予を得るのが精一杯だった」とコメントしている。 競合他社に人材を渡した製品のインフラ負荷を、自社の定額料金で支え続けることへの合理的な判断——とも読めるだろう。Anthropicが自社の統合ツール群へユーザーを誘導したい意図もにじむ。 実務への影響 — 日本のエンジニア・IT管理者にとって 日本でOpenClawを直接利用しているユーザーはまだ少ないが、この変更が示すメッセージは明確だ。「個人向けサブスクリプション」と「業務用エージェント基盤」は、根本的に別の設計思想が必要ということだ。 すぐに取れる行動： 試用・個人利用ならサブスクリプションで引き続き問題ない 業務用の自動化・エージェントを構築するなら、最初からAPIキーベースで設計する 従量課金への移行は「コストが増える」という側面だけでなく、「AIの稼働量を可視化・管理しやすくなる」という面もある サードパーティハーネスを業務フローに組み込む際は、プラットフォーム側のポリシー変更リスクを織り込んだ設計を意識する クリティカルな業務フローを外部ツール依存で構築する場合、APIの直接利用か、複数モデルへのフォールバックを検討したい。 筆者の見解 OpenClawの急成長は、「ハーネスループ」——AIエージェントが自律的に判断・実行・検証を繰り返すループ型の設計——がついに一般ユーザーの実生活に浸透し始めたことを象徴している。単発の質問に答えるだけのAIから、自分で動き続けるエージェントへ。その移行が静かに、しかし確実に進んでいる。 Anthropicの今回の判断は、ビジネス上の合理性は十分理解できる。急増するハーネスツールの負荷を定額料金で無制限に吸収するのは、長期的に持続可能ではない。熱心なパワーユーザーに追加コストを求めることになるのは痛みを伴うが、インフラの健全性を保つための必要な一手と見ることもできる。 より本質的な示唆は、ハーネスツールがここまで普及したという事実そのものだ。メールの返信・予定調整・手続き処理——これらを人間が手作業でこなしている時代は、終わりに近づいている。日本のIT現場でも、「AIに単発の質問をする」フェーズから「AIが自律的に動く仕組みを設計する」フェーズへのシフトを、本気で考える時期に来ている。今回の騒動は、そのことを改めて教えてくれた。 出典: この記事は Anthropic essentially bans OpenClaw from Claude by making subscribers pay extra の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AI電力争奪戦の新局面——大手テック各社が天然ガスに殺到 AIブームは今、データセンターの電力需要という形で地面の上に降り立ちつつある。Microsoft、Google、Metaの3社が相次いで天然ガス発電所の建設計画を発表し、業界全体が電力インフラの確保に血眼になっている。これはもはや「AI競争」ではなく「エネルギー競争」の様相を呈している。 3社が競って発表した巨大プロジェクト MicrosoftはChevronおよびEngine No. 1と連携し、テキサス州西部に最大5ギガワット（GW）規模の天然ガス発電所を建設すると発表した。Googleはテキサス州北部にCrusoeと共同で933メガワット（MW）の発電所を整備する。そしてMetaはルイジアナ州のHyperionデータセンターに天然ガス発電所を7基追加し、合計容量を7.46GWにまで引き上げる計画だ。この数字はサウスダコタ州全体の電力消費量に相当するという。 天然ガスが選ばれた理由は単純で、テキサス州やルイジアナ州などアメリカ南部地域には世界有数の天然ガス埋蔵量があるからだ。米地質調査所（USGS）によれば、ある1つの地域だけでもアメリカ全土の10カ月分のエネルギー供給が賄えるほどの埋蔵量がある。 なぜこれが重要か——見えてきたリスク構造 これらの投資が単純な「設備増強」とは異なる点が2つある。 タービン不足と価格高騰: エネルギーコンサルタントのWood Mackenzieによると、発電所用ガスタービンの価格は2019年比で今年末までに195%上昇する見込みで、新規発注は2028年まで受け付けられない状態だ。納品には6年かかる。つまり各社は「今すぐ確保しなければ永遠に出遅れる」という焦りの中でこの賭けに出ている。 電力価格への波及: アメリカの発電量の約40%を天然ガスが担っている（米エネルギー情報局）。各社は発電所をグリッド（電力網）に接続せず、データセンターに直結させる「メーター裏（behind the meter）」方式で外部の電力価格上昇の影響を回避しようとしている。しかし需要が際限なく膨らめば、それでも周辺の電力価格を押し上げる可能性がある。過去にも似たような状況が起きている。 供給の有限性: 天然ガスが豊富とはいえ無限ではない。近年、米国内の主要シェールガス3地域の生産増加ペースが著しく鈍化していることも懸念材料だ。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと この動向が日本のIT現場に与える影響は、以下の点で具体的だ。 クラウドコスト上昇の可能性: Azure・AWS・Google Cloudはいずれも電力コストをクラウド料金に転嫁する。エネルギーコストの上昇はサービス料金の値上げ圧力につながる。 AI利用コストの試算見直し: 生成AIをフル活用したシステム設計を検討している場合、中長期のランニングコストは現在の試算より高くなるシナリオを想定しておく必要がある。 グリーンIT目標との矛盾: 多くの日本企業が掲げるカーボンニュートラルへの取り組みと、天然ガス依存のAIクラウドの利用が矛盾を生む可能性がある。CSR・ESG報告においてこの観点を整理しておくことが求められる。 オンプレ・ハイブリッド戦略の再評価: エネルギーコスト上昇を理由に、一部ワークロードをオンプレミスやエッジに寄せるアーキテクチャを再評価する動きが加速するかもしれない。 筆者の見解 MicrosoftがChevronと組んでテキサスに5GW規模の発電所を建設する——この規模感だけでも、今のAI競争がいかに「フィジカルな戦い」に変容しているかがわかる。 ただ、正直に言えばこの状況には「FOMOが孫の代まで増殖している」という記事の表現が的を射ている気がしてならない。タービンは不足し、納期は6年、価格は倍以上——それでも各社が走り続けるのは、出遅れた場合のリスクを誰も取れないからだ。 Microsoftにはこの賭けに勝つだけの資本力もインフラ運営の実績もある。それは間違いない。問題は「電力を確保すれば勝てる」という前提がどこまで正しいかだ。エネルギーは必要条件であって十分条件ではない。AIの競争優位はモデルの質、エコシステム、開発者体験の総体で決まる。そこに本来の注力ポイントがある。 AIの電力消費が増え続けるという前提の下で天然ガスに張るのは、一面では合理的な判断だ。だが「AIが今後も指数関数的に電力を必要とし続ける」という前提そのものが崩れるリスクも見ておく必要がある。モデルの効率化が進めば、数年後には今ほどの電力を必要としない可能性もある。長い納期で発注したタービンが届く頃に市場がどうなっているか、誰にも断言できない。 インフラへの大胆な先行投資はMicrosoftの強みでもある。その強みを生かしながら、電力確保だけでなくエネルギー効率の改善にも同じくらい本気で取り組む姿を見せてほしい——そう期待している。 出典: この記事は AI companies are building huge natural gas plants to power data centers. What could go wrong? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIの覇権争いは、技術の優劣だけでなく「資本市場での証明」へと舞台を移しつつある。Anthropic と OpenAI という生成AI業界の二大プレイヤーが、いずれも2026年後半のIPO（新規株式公開）を目標に動いていることが明らかになった。しかも両社は互いに「先を越されたくない」という意識を持ちながら、上場のタイミングを競い合っているという。 このニュースは単なる財務イベントの予告ではない。生成AIが「実験的なテクノロジー」から「巨大産業」へと脱皮する歴史的な転換点を象徴している。 両社の現在地——数字が語るスケール Anthropicは直近のシリーズGラウンドで300億ドル（約4兆5000億円）の資金調達を完了しており、IPO前の企業評価額はすでに天文学的な水準に達している。 OpenAIは年間売上高が250億ドル（約3兆7500億円）を突破。ChatGPTのリリースからわずか3年ほどでここまで来たのだから、成長速度としては異常値と言っていい。 両社に共通するのは「研究機関から始まったが、いまや巨大ビジネスになった」という文脈だ。Anthropicは安全性重視の非営利的な理念を持ちつつ、Amazonなど大企業からの巨額投資を受け入れてきた。OpenAIはMicrosoftとの深い提携関係を持ちながら独立性を模索し続けてきた。IPOはその複雑な資本構造に一定の答えを出すプロセスでもある。 なぜいまIPOなのか 「競合に先を越されたくない」というプレッシャーに加え、いくつかの構造的な理由がある。 第一に、投資家の「EXIT」ニーズ。 両社には初期から資金を投じてきたVC（ベンチャーキャピタル）や機関投資家が多数いる。成長フェーズが一段落した現在、IPOによる流動性確保は自然な流れだ。 第二に、企業顧客への信頼性向上。 上場企業であることは、大企業・官公庁・金融機関との契約において「ガバナンスの透明性」を示す重要なシグナルになる。特に規制産業では「上場しているかどうか」が調達条件に関わるケースすらある。 第三に、人材確保のためのストックオプション設計。 AI人材の争奪戦は熾烈を極めており、上場後の株式報酬設計を明確にすることは採用競争力に直結する。 日本のIT現場への影響 このIPO競争が示す最大のメッセージは「生成AIはもはや一過性のブームではない」という資本市場からの宣言だ。日本のIT業界にとっていくつかの実務的な含意がある。 調達・契約の安定性が増す。 上場企業になることで財務開示が義務化され、サービスの継続性や企業の健全性を客観的に評価できるようになる。「このAIスタートアップ、突然消えないか？」という不安を抱えてきた企業にとっては追い風だ。 エンタープライズ向け機能・コンプライアンス対応が加速する。 IPO後は機関投資家の目が向くため、ガバナンスや規制対応（SOC2、ISO27001等）の強化が促進される。日本企業が求めるセキュリティ要件を満たすソリューションの充実が期待できる。 競争激化によるコスト低下。 上場で調達した資金はインフラ拡充・研究開発に投じられ、APIの低価格化・高性能化が続く可能性が高い。生成AIを使い倒すコストは今後も下がっていく方向だ。 実務での活用ポイント 今のうちに両社のエンタープライズプランを評価しておく: IPO後は利用規約・価格体系・SLAが変わる可能性がある。現在の条件でPoCを始めておくのが得策 ベンダーロックインへの備えを: 上場後は株主利益のためにAPIの仕様変更・値上げが起こりうる。抽象化レイヤーの設計やマルチベンダー戦略を今のうちに検討する 調達・情報システム部門との連携を: IPO後は「上場企業との取引」として稟議が通りやすくなるケースがある。社内説得の文脈で活用できる 筆者の見解 個人的には、このIPO競争を「生成AI第一章の幕引き」として捉えている。技術が実証され、市場が形成され、資本市場がそれを評価する——これはひとつのサイクルの完成だ。 一方で、IPOによって両社に新たな重力が生まれることも忘れてはならない。四半期ごとの業績開示が求められれば、長期的な安全性研究よりも短期収益が優先されるプレッシャーが増す。とりわけ安全性研究を存在意義の核に据えてきたAnthropicにとって、この圧力とどう向き合うかは大きな試練になりうる。 技術は間違いなく前進している。いま最も重要なのは、AIを単発の質疑応答ツールとして使う段階から、自律的に判断・実行・検証を繰り返すエージェント的な仕組みを組織に埋め込む段階へとシフトすることだ。IPOによる資金調達がその方向への投資を加速させるなら、それ自体は歓迎すべきことだと思っている。 日本企業にとって危ういのは、このニュースを「海外の大きな話」として距離を置いてしまうことだ。生成AIが産業インフラになる速度は、多くの経営者が想定しているより格段に速い。「まだ様子見」のポジションを取り続けることのリスクは、今年後半からさらに高まっていく。 出典: この記事は Why Anthropic and OpenAI want to go public の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIが生み出すサイバー脅威の議論は以前からあった。しかし今回は話が違う。Anthropicが社内で「Mythos」と呼ぶ次世代モデルの詳細が、誤って公開されてしまったドキュメントを通じて外部に漏れ出し、「サイバーセキュリティにおける分水嶺（ウォーターシェッド）」という表現を専門家が口にするほどの反響を呼んでいる。 何が漏れたのか Anthropic社の未公開ブログ投稿がFortune誌によって報じられ、その内容に業界が色めき立った。同社の説明によれば、漏洩はコンテンツ管理システムの「人為的ミス」によるもの。ただし内容そのものは否定していない。 文書には「Mythosは現時点で他のいかなるAIモデルよりもサイバー能力で大幅に先行しており、防御側の取り組みをはるかに上回るペースで脆弱性を悪用できる次世代モデルの波を予兆するものだ」と記されていた。 リリースは2026年第2四半期が見込まれており、Anthropicは一部の組織に先行テストへのアクセスを許可。「迫り来るAI主導の悪用に対し、自組織のシステムを強化する」目的とされている。また米政府当局者にも非公式の警告を行っているとAxiosが報じている。 AIエージェントが「攻撃者」になるとき これまでのAIを使った攻撃は、人間ハッカーが使うツールの一つとしてAIを活用するものだった。だが「AIエージェント」の登場はその前提を壊す。 エージェントとは、人間の指示を待たずに自律的にタスクを実行するAIのことだ。脆弱性のスキャン、悪用コードの生成、攻撃の実行という一連の流れを、人間が介在しないままループで繰り返せるとしたら——単独のエージェントが数百人の人間ハッカーより素早く、しつこく動き続けることになる。 ネットワーキング企業Cato Networksの創業者・CEOであるシュロモ・クレイマー氏はCNNに「エージェント型攻撃者が来る。これはサイバーセキュリティの歴史における転換点だ」と語った。 OpenAIも昨年12月、自社の次期モデルについて「高い」サイバーセキュリティリスクをもたらすと公式に警告しており、こうした流れは一社だけの話ではない。 すでに現実化している「AI活用型攻撃」 理論の話だけではない。2026年1月、技術的なスキルが限られたロシア語圏のサイバー犯罪者が複数のAIツールを組み合わせ、55カ国以上で人気のファイアウォールソフトを実行する600台超のデバイスをハッキングした事例をAmazon Web Servicesのセキュリティチームが報告している。 AWSによれば、この攻撃者は「限られた技術能力にもかかわらず、生成AIサービスを使って攻撃の全フェーズにわたって既知の手法を実装・スケールさせた」という。複数のAIモデルが組み合わせて使われた点も注目に値する。 AI活用型攻撃が「高度なハッカー限定」ではなく、スキルの低い攻撃者の「能力増幅装置」になっているという現実が、ここに示されている。 「人間が消える」わけではない ただし、現時点では万能ではないことも専門家は指摘する。サイバーセキュリティ企業Armadin社のエバン・ペーニャ氏によれば、高度なAIモデルは脆弱性のリサーチやエクスプロイトコードの開発には優れているが、「その組織にとって最も価値ある情報が何か」を判断するコンテキストは人間ハッカーに劣るという。 米政府に攻撃的サイバー能力を提供するTwenty社のジョー・リン氏は「AIが実行を担う一方で、その結果に責任を持つのは常に人間でなければならない」と述べており、少なくとも当面は「人間＋AI」のハイブリッドモデルが攻撃・防御の双方で続くとみられる。 実務への影響——日本のエンジニア・IT管理者が今すぐやるべきこと この状況を「海外の話」と見ていると危うい。日本企業も無縁ではなく、むしろ対応が遅れやすい環境だからこそ早期の準備が重要だ。 1. 脆弱性管理のサイクルを短縮する AIによる攻撃は脆弱性公開から悪用までの時間を著しく短縮する。「月次パッチ」では追いつかない場面が増える。CVEの監視自動化と優先順位付けに今すぐ投資を。 2. AIを防御側にも組み込む SIEM/SOARへのAI統合、異常検知の強化を検討する。攻撃者がAIを使うなら、守る側もAIで応戦するのが現実的な対策になる。 3. 「スキルの低い攻撃者」を甘く見ない AIによる能力増幅は、標的になるリスクの分布を変える。中小規模の組織も例外ではない。フィッシング・ソーシャルエンジニアリング訓練の見直しも合わせて行うべきだ。 4. ゼロトラスト原則の再確認 「入ってきた相手を信頼しない」という設計原則は、AI活用型攻撃が高速化する世界でより重要になる。ネットワークセグメンテーションや最小権限の実装を改めて点検したい。 筆者の見解 この話題で最も気になるのは、攻撃側が「エージェントのループ」を使い始めているという点だ。単発の指示・応答ではなく、エージェントが自律的に判断・実行・検証を繰り返す仕組みが攻撃に転用されれば、人間の反応速度では対応不可能な局面が出てくる。 逆に言えば、同じアーキテクチャを防御側にも導入しなければ非対称な戦いが続くということでもある。「AIエージェントを自律的にループさせる」技術は攻撃でも防御でも同じ原理で動く。防御側が先手を打って仕組み化できるかどうかが、これからの数年で明暗を分けるだろう。 AIによるサイバーリスクの高まりは、AIを「便利ツール」としてだけ捉えていた段階の終わりを意味する。脅威インテリジェンスとAIの組み合わせ、そして自律的に回り続ける防御エージェントの設計——これを「将来の課題」と先送りできる余裕は、もうないかもしれない。 出典: この記事は Anthropic’s next model could be a ‘watershed moment’ for cybersecurity. Experts say that could also be a concern の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが長らく物議を醸してきた「Windows Recall」の正式展開をついに開始した。2024年6月のCopilot+ PC発売時に華々しくデビューするはずだった機能が、セキュリティ・プライバシー上の問題から2度の延期を経て、ようやくWindows Insider向けにプレビュー提供が始まった。今回の展開では従来の反省を踏まえた設計変更が加えられているが、注目すべき点は技術的な改善だけではない。 Windows Recallとは何か Recallは、PCの画面を定期的にスクリーンショットとして保存し、AIを使って「あの時見ていたあのWebページ」や「先週編集していたあの資料」を自然言語で検索できるようにする機能だ。概念としては非常に魅力的で、「デジタル記憶の拡張」とも呼べるアプローチである。 処理はすべてデバイス上のNPU（Neural Processing Unit）で完結するため、クラウドにデータを送信しない点が特徴だ。ただし動作にはCopilot+ PCの認定を受けたハードウェアが必要で、最低16GBのRAM、256GBのストレージ、およびデバイス暗号化が有効であることが条件となる。現行の多くのビジネスPCでは動作しないことも念頭に置いておく必要がある。 2度の延期を経た改善点 最初の公開プレビュー当時、セキュリティ研究者たちが指摘したのは深刻な問題だった。パスワード、クレジットカード番号、社会保障番号といった機密情報が暗号化されていないテキストファイルとして保存されていたのだ。「AIが見てくれる便利な機能」のはずが、「攻撃者に全履歴を渡す機能」になりかねないと批判が殺到した。 今回の展開では、この反省が設計に反映されている： 完全オプトイン制：デフォルトは無効。自分で有効化しない限り、スクリーンショットは一切保存されない ローカル暗号化：スナップショットはデバイス上で暗号化。Microsoftもアクセス不可 Windows Hello認証：生体認証でのみアクセス可能。第三者が覗けない仕組み 一時停止機能：いつでもスナップショット保存を止められる また今回は「Click to Do」機能も同梱されており、スクリーンショット内の画像から背景削除や物体消去をPhotoアプリやPaintで直接実行できるなど、より実用的な連携が加わった。 対応言語と提供地域 現時点での対応言語は英語・中国語（簡体字）・フランス語・ドイツ語・日本語・スペイン語の6言語。日本語が含まれている点は、日本市場への正式展開を見据えた動きとして注目に値する。ただし欧州経済領域（EEA）向けの提供は今年後半に予定されており、GDPR対応の複雑さが影響していると見られる。 実務への影響——日本のエンジニア・IT管理者へ 導入前に確認すべき3点： ハードウェア要件の確認：現在の社内PCがCopilot+ PC認定を受けているか確認する。多くの既存機では動作しない MDM/Intune設定の見直し：Recallは管理者側でポリシー制御が可能。業務PCへの展開可否は組織のセキュリティポリシーと照らし合わせて判断すること 情報セキュリティルールとの整合性：画面を自動記録するという性質上、機密情報を扱う業務での利用可否を事前に整理する必要がある 特に、医療・金融・法務など機密度の高い業務環境では、たとえローカル暗号化であっても「スクリーンショットを自動保存する仕組みが動いている」という事実に対してコンプライアンス上の確認が必要になるケースがある。IT管理者は早期にポリシー検討を始めておくことを勧める。 個人・開発者向けには、日本語対応が確認できたらまずWindows Insiderプログラムで試してみる価値はある。AIによるPC操作履歴の検索は、実際に使ってみると「あれ、これはちゃんと便利かもしれない」と感じられる場面が出てくるはずだ。 筆者の見解 正直に言えば、このRecallには複雑な思いがある。 機能のコンセプト自体は面白い。「あの時見ていたあれを探したい」という体験は誰もが感じる課題であり、それをNPUとAIで解決しようという発想は正しい方向だ。デフォルト無効・ローカル暗号化・Windows Hello認証という今回の設計変更も、最初からこうなっていればよかったと思えるほど筋が通っている。 だが、ここまでの経緯が気になる。最初のプレビューで出た問題——パスワードや金融情報がそのまま平文で保存されていた——は、セキュリティの基本的な感覚があれば事前に防げたはずのものだった。「なぜ最初にそれをやらなかったのか」という問いに対して、明確な答えがないまま時間が過ぎてしまった。 Microsoftには、Windowsというプラットフォームと数億台のエンドポイントという圧倒的な強みがある。その規模でAI機能を展開できる企業は他にない。だからこそ、「3度目の正直」という言葉で片付けてほしくない出来事でもある。もったいないという気持ちが正直なところだ。 今後、Recallが日本市場で正式展開されたとき、ユーザーが「安心して使える」と感じられる実績をきちんと積み上げていくことが、信頼回復への唯一の道だろう。技術的な土台は今回で整いつつある。あとはその土台の上で、地道に実績を示してもらうことを期待したい。 出典: この記事は Third time lucky? Microsoft finally begins roll-out of controversial Recall feature の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年4月第1週にリリースしたWindows 11向けオプションプレビュー更新プログラム「KB5079391」を、インストールエラーが相次いだとして配信を一時停止した。同社は原因の詳細や修正版のリリース時期を明示していないが、4月14日のPatch Tuesdayまでには正式版が提供される見込みとされている。 KB5079391とは何だったか KB5079391はWindows 11バージョン24H2および25H2を対象とした任意適用のプレビュー更新で、計29件の変更を含んでいた。主な内容は以下のとおり。 Smart App Controlの改善 ディスプレイパフォーマンスの向上 Windows Helloの指紋認証信頼性の強化 ARM64デバイス上でx64アプリを実行する際のWindows Recovery Environment安定化 生体認証サインインの信頼性向上 機能面では有益な変更が多く含まれていただけに、配信停止は残念な結果となった。 エラー0x80073712が意味すること 報告されたエラーコード「0x80073712」は「更新ファイルが見つからないか破損している」ことを示すもので、更新コンポーネントのキャッシュや配信ファイル自体に問題があった可能性が高い。MicrosoftはWindowsUpdate経由での提供を一時的に制限し、追加の影響が出るのを防ぐ対応を取っている。 繰り返す品質問題——2026年の記録 今回の件は決して孤立した事例ではない。ここ数ヶ月で見ても： 2026年1月: Patch Tuesday後にリモートデスクトップ接続障害、再起動ループ、Outlookクラッシュが発生。WindowsクライアントからServer 2019〜2025まで6件の帯外更新で対処 2026年3月: Patch Tuesday後、Teams・Edge・Microsoft 365でサインインが失敗する障害が発生。端末がオフラインと誤判定するバグが原因で緊急修正 2026年3月〜4月: Bluetooth接続問題やエンタープライズ向けセキュリティ脆弱性にも緊急対応 Windows担当チーフのPavan Davuluri氏は「高い基準を求め続けてくれてありがとう。Windowsはみなさんのものでもある。基盤を強化し、本当に重要なイノベーションを届けることにコミットする」とユーザーに約束しているが、その約束が試される状況が続いている。 実務への影響——今すぐできる対応 エンタープライズIT管理者向け Intune・WSUS・Windows Update for Business等の管理ツールで、KB5079391の配信状況を確認し、展開ポリシーが停止済み更新を誤って適用しようとしていないか確認する 既に展開キューに入っている場合は手動でブロックリストに追加することを検討 4月14日Patch Tuesday後、正式な累積更新として再リリースされる見込みのため、タイミングを待つのが現実的な対応 個人・SMB環境向け Windows Updateの「任意（オプション）」更新は、Patch Tuesdayの必須更新に統合されるまで待つのが原則として安全 今回のような障害情報はMicrosoftのKnown Issues一覧で確認できる。更新前に必ず参照したい エラー0x80073712が出た場合は、DISM /Online /Cleanup-Image /RestoreHealth コマンドで更新コンポーネントの修復を試みる価値がある 筆者の見解 Smart App Controlの改善やWindows Hello強化など、今回のKB5079391に含まれていた変更は方向性として正しいものが揃っていた。セキュリティ基盤の堅牢化はMicrosoftが継続して取り組むべき最重要課題であり、その姿勢自体は支持したい。だからこそ、品質管理で躓くのがもったいない。 更新の品質問題はもはや「たまにある話」ではなく、毎月の定例行事のようになってきているのが率直なところだ。1月、3月、4月と連続して緊急対応が発生している現状は、テストプロセスか配信インフラのどこかに構造的な課題があることを示唆している。 現場のエンジニアとしては「更新を即日当てず数日様子を見る」という選択が、もはや単なる慎重さではなく合理的なリスク管理になっている。これが当たり前になってしまっている現状は、Microsoftが本来目指している「信頼性の高いプラットフォーム」とは逆方向に進んでいる。 4月14日のPatch Tuesdayでこの問題が安定した形で解消され、今後の更新品質向上への足がかりになることを期待したい。Pavan Davuluri氏の「基盤を強化する」という約束を、ぜひ行動で示してほしい。Microsoftには、それができる技術力と組織力が間違いなくある。 出典: この記事は Microsoft pulls Windows update after installation failures の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftがAzure AI Foundryの新機能として「Microsoft Agent Framework」をパブリックプレビューで正式発表した。これまで研究プロジェクトとして独立していたAutoGenと、エンタープライズ向け基盤として発展してきたSemantic Kernelを一つのフレームワークに統合するという、長らく待望されていた動きだ。 AutoGenとSemantic Kernelが、ついに一本化 Microsoft Agent Frameworkの核心は「統合」にある。AutoGenはMicrosoft Researchが開発した実験的なマルチエージェントライブラリで、エージェント同士の会話ループや役割分担に強みがあった。一方のSemantic Kernelは.NET・Python・Java向けのエンタープライズ対応SDKとして、RAGやプラグイン管理を得意としていた。 この2つを並行して使いこなすことは、これまでのAIエージェント開発者にとって相当なコンテキストスイッチを要した。今回の統合により、開発者は一つのSDKで研究最前線のマルチエージェントパターンと商用グレードの信頼性・ガバナンスを同時に得られる。 実装の3本柱——MCP・A2A・OpenAPI Microsoft Agent Frameworkは以下の3つのインターフェース連携を中心に設計されている。 Model Context Protocol（MCP）対応 外部ツールやデータソースとの動的な接続をMCPで実現する。MCPはAnthropicが提案し業界全体で採用が広がるオープンプロトコルで、エージェントがリアルタイムにツールを「発見して使う」仕組みの標準となりつつある。MicrosoftがMCPをネイティブサポートしたことは、エコシステム互換性の観点から重要な判断だ。 Agent2Agent（A2A） Googleが主導するエージェント間通信プロトコルA2Aにも対応し、異なるランタイムやプラットフォームをまたいだエージェント協調が可能になる。自社システムだけでなく、外部パートナーのエージェントとも接続できる設計だ。 OpenAPIによるAPI統合 OpenAPI仕様に準拠したAPIであれば、追加のアダプター実装なしにエージェントのツールとして組み込める。既存のバックエンドAPIを即座にエージェント対応にできる点は、実務での移行コストを大きく下げる。 Azure AI Foundryとの統合——ガバナンスと可観測性 ローカルで実験したエージェントをAzure AI Foundryに持ち込むと、可観測性・耐久性・コンプライアンスが自動的に付いてくる設計になっている。さらに「マルチエージェントワークフロー（プライベートプレビュー）」では、永続的な状態管理・エラーリカバリー・ビジュアルデバッグが加わり、長時間稼働するビジネスプロセス自動化に耐える構成を組める。 KPMGはこのフレームワークをグローバル監査プラットフォーム「KPMG Clara AI」に採用しており、規制産業での実績としての重みは小さくない。 実務への影響——日本のエンジニアが今やるべきこと Azure AI Foundryを試せる環境があるなら今すぐ手を動かす パブリックプレビューは本番投入の前哨戦だ。ローカルでAutoGenをいじっていた開発者は、そのコードをベースにFoundryへの移行を試す絶好のタイミングになった。 ツール統合の入口としてMCPを覚える MCPはAIエージェントとツールを繋ぐ新しい標準として急速に普及している。REST APIの設計スキルがそのまま活かせるため、バックエンドエンジニアにとって参入障壁は低い。社内の既存APIをMCP対応ツールとして公開する設計を今のうちから考えておくと良い。 Semantic Kernelの学習コストが将来に繋がる 日本では.NETエンタープライズ案件でSemantic Kernelの採用が増えている。今回の統合で「Semantic Kernelを学ぶ＝Microsoft Agent Frameworkを学ぶ」という構図になったため、既存の学習投資がそのまま有効になった。 ガバナンス設計を後回しにしない エージェントが複数連携する構成では、どのエージェントが何をしたかのトレーサビリティが必須になる。Foundryのガバナンス機能はその回答の一つだが、設計段階からエージェントの権限範囲・ログ取得・人間によるチェックポイントを組み込む習慣を今から持つべきだ。 筆者の見解 正直に言えば、この発表を見て「やっと来た」という気持ちが強い。AutoGenとSemantic Kernelが別々に存在し続けていた状況は、Microsoftのエコシステムを愛する開発者にとってずっと気持ち悪かった。ユーザーを分断させる理由がなかったはずで、今回の統合はその意味で遅すぎたくらいだ。 とはいえ、やるべきことを正面から整理してきた点は評価したい。MCPへの対応、A2Aへの対応、OpenAPI統合——これらはどれも「自社だけで完結させない」という姿勢の表れであり、エコシステムを広げる正しい方向性だ。 私が今最も注目しているのは「ハーネスループ」の設計、つまりAIエージェントが自律的に判断・実行・検証を繰り返し回り続ける仕組みだ。Microsoft Agent Frameworkのマルチエージェントワークフローは、まさにそのループを企業システムの中で安全に回すためのインフラになりうる。 Microsoftの強みはAIモデルの性能競争ではなく、「最も多くのエージェントが安全に動作するプラットフォームを提供する競争」にある。Entra IDによるID管理、Foundryのガバナンス基盤、M365との連携——これらが本当に繋がり始めたとき、エンタープライズAIエージェントの管制塔としてのMicrosoftの地位は揺るぎないものになる。 今回の発表はその布石として、十分に意味がある一手だ。 出典: この記事は Introducing Microsoft Agent Framework の内容をもとに、筆者の見解を加えて独自に執筆したものです。