Tech News JP

会議の音声をリアルタイムでAIが文字起こし・要約してくれる——そんな便利さで人気を集めているAIノートアプリ「Granola」に、見過ごせないプライバシーリスクが潜んでいることが明らかになった。エンジニアやIT管理者はもちろん、機密情報を扱う会議でGranolaを利用しているすべてのビジネスパーソンに向けて、今すぐ確認すべき設定を解説する。 Granolaとは何か Granolaは「連続する会議をこなす人のためのAIノートパッド」を標榜するアプリだ。カレンダーと連携し、会議の音声をキャプチャしてAIが箇条書きのメモを自動生成する。生成されたメモは編集可能で、同僚をコラボレーターとして招待したり、AIアシスタントに会議内容を質問したりもできる。MacのデスクトップアプリとしてUS発で展開されており、特にスタートアップやSaaS企業のビジネスパーソンの間で広く利用されている。 何が問題なのか リンクを知る全員が閲覧可能 Granolaのアプリ設定には、「デフォルトではノートはリンクを持つ誰でも閲覧可能」と明記されている。The Vergeの検証では、自分のノートのリンクをプライベートウィンドウで開いたところ、Granolaアカウントにログインしていない状態でもノートの内容・作成者・作成日時が表示されたという。 さらに、ノート内の箇条書きを選択すると、その根拠となる会議トランスクリプトの引用と、AIが生成したコンテキスト付きサマリーが表示される仕組みだ。完全なトランスクリプトへのアクセスはデスクトップアプリ内のコラボレーターに限定されているようだが、詳細はGranolaが公式に確認していない。 このリンクは検索エンジンにインデックスはされていないが、「誤ってSlackやメールでリンクを共有してしまった」「画面共有中に見えてしまった」といったシナリオで情報が外部に漏れるリスクは十分にある。実際、あるLinkedInユーザーが昨年この問題を指摘しており、大手企業の1社はセキュリティ上の懸念からシニアエグゼクティブへのGranola利用を禁止したと報じられている。 AIトレーニングへのデータ利用もオプトアウト制 もう1つの問題が、AIモデルの改善を目的とした「匿名化データの利用」だ。エンタープライズプランのユーザーはデフォルトでオプトアウトされているが、それ以外のプランではオプトインが前提となっている。GranolaはOpenAIやAnthropicなど第三者企業へのデータ提供は行わないと説明しているが、自社AIモデルの学習には利用される可能性がある。 なお、ノートと文字起こしはAWSのプライベートクラウド上に保存され、暗号化（保存時・転送時）はされている。会議の音声そのものは保存されない点は救いだが、テキスト化された会議内容が残ることに変わりはない。 今すぐできる設定変更 以下の手順でプライバシー設定を変更できる： リンク共有の制限 Granolaを開き、左下のプロフィールアイコンを選択 「Settings」→「Default link sharing」を開く 「Anyone with the link」を「Only my company」または「Private」に変更 AIトレーニングのオプトアウト 同じSettings画面で「Use my data to improve models for everyone」をオフにする なお、ノートを削除すれば既存のリンクからもアクセス不能になる。 実務への影響 日本のIT現場では、リモートワーク普及以降、会議メモの自動化ツールへの関心が急速に高まっている。GranolaのようなAI会議アシスタントは確かに生産性を大幅に向上させるが、今回の問題は「便利さ」の裏に潜むガバナンスリスクを改めて示している。 特に以下のケースでは利用ポリシーの見直しが急務だ： M&A・経営会議など機密性の高い打ち合わせ：リンク漏洩が情報漏洩に直結する 個人情報・顧客情報を扱う会議：GDPRや個人情報保護法の観点でリスクになりうる クライアントとの商談：NDA締結済みの情報をAIに学習させることの是非 IT管理者向けには、社内でGranolaを利用しているユーザーに設定変更を周知するとともに、エンタープライズプランへの移行（AIトレーニングがデフォルトオプトアウト）を検討する価値がある。 筆者の見解 Granolaに限らず、AIを活用した生産性ツールにおいて「デフォルトがオープン寄り」な設定になっている事例は後を絶たない。これはプロダクトの性質上、コラボレーションを促進するために意図された設計であることが多いが、エンタープライズ利用を想定した場合に大きな障壁となる。 今回の問題が示すのは、AI時代における「ゼロトラスト」の考え方をツール選定にも適用すべきという教訓だ。便利だからといって即座に組織展開せず、「デフォルト設定は何か」「データはどこに保存され、何に使われるか」「オプトアウトできるか」を必ずチェックするプロセスを組織に根付かせることが重要だ。 AI会議アシスタント市場はMicrosoft Copilot（Teams）やGoogle Gemini（Meet）など大手も参入しており、競争はさらに激化する。こうした大手プラットフォームはエンタープライズのコンプライアンス要件を満たした設計になっていることが多いが、スタートアップ発のツールでは今回のGranolaのようなケースが起きやすい。ツールの「便利さ」と「セキュリティ成熟度」を天秤にかけながら、組織としての利用判断を下す——そのリテラシーが今のIT部門には求められている。 出典: この記事は PSA: Anyone with a link can view your Granola notes by default の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月、生成AIの競争は新たなフェーズに入った。わずか3ヶ月でフロンティアが何度も塗り替えられ、今月だけでも業界の勢力図を変えかねない出来事が連続して発生している。OpenAIが年換算売上高（ARR）250億ドルを突破しIPO検討に入ったというビジネス面での激変と並行して、モデル性能の競争も前例のない激しさを見せている。 業界を揺るがした「Claude Mythosリーク」 今月最大のニュースは、3月26日に発生したAnthropicの内部文書流出だ。設定ミスのあったデータストアから約3,000件の内部ファイルが一時的に公開状態になり、その中に「Claude Mythos（内部コードネーム：Capybara）」の詳細な製品ドキュメントが含まれていた。 Anthropicは存在を否定せず、「推論・コーディング・サイバーセキュリティにおいて意味のある進歩を遂げた汎用モデルを開発中。能力の強さを鑑み、リリース方法を慎重に検討している。これは当社史上最高性能のモデルで、ステップチェンジと位置づけている」と公式に認めた。 リークされた文書によれば、ClaybearはClaude Opus 4.6を「劇的に」上回るプログラミング性能を持つとされ、現在はサイバーセキュリティパートナー限定の早期アクセス段階にある。公開日は未定だが、市場は4月中の発表可能性を約25%と見積もっている。 現時点のモデル勢力図 総合性能：Gemini 3.1 Pro が首位 16の主要ベンチマーク中13で首位を獲得しているGemini 3.1 Proは、Artificial Analysis Intelligence IndexでGPT-5.4 Proと同率ながら、APIコストは約3分の1という破壊的なコストパフォーマンスを誇る。エンタープライズ採用において価格は重要な変数であり、この差は見逃せない。 コーディング：Claude Sonnet 4.6 が実務首位 実際の専門家レベル作業を評価するGDPval-AA Eloベンチマークでは、Claude Sonnet 4.6がトップに立つ。GitHub CopilotのCodingエージェントがこのモデルで動作していることからも、コード生成の実用性では一歩抜け出した存在だ。 オープンソース：Meta Llama 4 Mavericが台頭 4,000億パラメータ・1,000万トークンのコンテキストウィンドウを持つLlama 4 Mavericは、独自インフラで無償運用できるオープンウェイトモデルとして最強クラスに達した。クローズドモデルとの性能差が急速に縮まっている。 価格破壊：DeepSeek V3.2 DeepSeek V3.2は入力100万トークンあたり約0.28ドルという価格を実現。欧米フラッグシップモデルの2ドル以上と比較すると約7分の1以下であり、コスト重視のユースケースでは無視できない選択肢だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 すぐに動けるアクション： GitHub Copilotを使っているなら今すぐ確認：Claude Sonnet 4.6ベースのCodingエージェントが実務コーディングで最高評価を得ている。エージェントモードが有効になっているか設定を確認し、複雑なリファクタリングや単体テスト生成に積極的に活用したい。 Gemini 3.1 Proのコスパを試算する：Google CloudやVertex AI経由でのAPI利用コストを、現在使っているGPT-4系と比較してほしい。同等性能で3分の1のコストになるなら、高スループットな社内ツールのバックエンドを切り替える価値がある。 オンプレミス・プライベート環境を検討しているなら Llama 4：情報漏洩リスクの観点から外部APIに送れないデータを扱う企業にとって、Llama 4 Mavericは現実的な選択肢になった。ローカルLLM運用のPoC着手タイミングとして今が適切だ。 Claude Mythosの動向を追う：サイバーセキュリティ分野で特段の強みを持つとされており、SOC自動化やペネトレーションテスト支援への活用が期待される。早期アクセス申請の窓口が開いた際は優先的に検討したい。 筆者の見解 2026年の生成AI競争を一言で表すなら「コモディティ化の加速」だ。 Gemini 3.1 ProがGPT-5.4と同等の性能を3分の1のコストで提供し、Llama 4がクローズドモデルの背中を追うこの状況は、「どのモデルを使うか」ではなく「いかに素早く使いこなすか」が企業の競争優位を決める時代が来たことを示している。 Claude Mythosのリークが特に興味深いのは、Anthropicが「サイバーセキュリティ」を特筆した点だ。セキュリティ特化のモデルが登場することで、これまで人手に依存していたインシデント対応や脆弱性評価の自動化が一気に現実解になりうる。日本でもCSIRTやSOCの人材不足は深刻であり、このモデルの公開は国内のセキュリティ運用に大きなインパクトを与えると予想する。 OpenAIのIPO観測が示すように、生成AIはもはや研究フェーズを完全に卒業した。モデル選定はベンダーロックインリスク・コスト・コンプライアンス・性能のバランスで評価する「調達判断」になっている。IT管理者にとっては、クラウドサービスの選定と同じ視点でAIモデルを評価するフレームを今すぐ整備すべき時期に来ている。 出典: この記事は OpenAI Surpasses $25B ARR, Explores IPO as Early as Late 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIはコードを「書く」から「検証する」フェーズへ 「AIはコードが書ける」——この命題はもはや疑う余地がない。GitHub CopilotやClaude Code、Cursor AIが普及し、日々の開発でAIアシストは当たり前になってきた。しかし、もう一段深いところで問いが立ち上がっている。「AIは信頼できるエンジニアリングを、人間の監視なしにできるのか？」 この問いに対して、英国オックスフォード発のスタートアップ・Diffblueが2026年3月24日に衝撃的なデータを叩きつけた。自律型回帰テスト生成エージェント「Diffblue Testing Agent」が一般提供（GA）を開始し、8つの実世界Javaプロジェクトを対象としたベンチマークで平均81%のライン網羅率を自動達成したというのだ。 比較対象は「シニア開発者がClaude Codeと2時間協働した場合」——その結果は平均32%。実に2.5倍の差である。 Diffblue Testing Agentとは何か Diffblue Testing Agentは、既存のAIコーディングプラットフォーム（GitHub Copilot、Claude Code等）の上にオーケストレーション＆検証レイヤーとして機能する専門エージェントだ。既存ツールを置き換えるのではなく、それらを指揮する立場に立つ設計思想が特徴的である。 具体的な動作フローは以下のとおり： コードベースの自律スコーピング — 対象クラス・メソッドを自動特定 テスト計画の作成 — カバレッジ分析をもとに並列テスト生成戦略を立案 テスト生成の委任 — メソッド・クラスレベルのテスト作成をClaude CodeなどのAIに委任 ビルド＆検証 — コンパイルが通り、かつパスするテストのみを採用 ロールバック処理 — 失敗したテストは自動的に除去 プルリクエスト準備 — 数百〜数千クラスを一括処理してPRを自動生成 ベンチマークでは81%のライン網羅率に加え、**ミューテーション網羅率61%**も達成。これは多くのエンタープライズが設定するテスト品質基準を上回る水準だ。 この技術的基盤はオックスフォード大学発の数十年にわたるソフトウェア検証研究から生まれており、単なる「AIにテストを書かせる」ツールとは一線を画す。 なぜこれが重要か——日本のIT現場への影響 日本のエンタープライズIT現場では、アプリケーションモダナイゼーションが最大の課題の一つとなっている。老朽化した基幹システムをクラウドネイティブ化・マイクロサービス化する際、最大のリスクは「リグレッション（既存機能の壊れ）」だ。 テストがない（あるいは少ない）レガシーコードをリファクタリングするのは、目を閉じてロープを渡るようなものである。多くの現場では「テストを書く工数がない」という理由でモダナイゼーションが止まっているか、そもそもテスト工程を省略してリスクを抱えたまま進んでいる。 Diffblue Testing Agentが解決しようとしているのはまさにこの課題だ。「テスト書く人がいない問題」を、エージェントが自律的に解決する。 また、AIコーディングツールの「急速に収穫逓減する」問題も見逃せない。Claude CodeやCopilotにテスト生成を頼み続けると、50%程度の網羅率で詰まり、そこから先は開発者が延々とプロンプトを調整する時間が必要になる。DiffblueのCTO、ピーター・シュラメル博士が「その努力は急速に手が届かないレベルになる」と述べているのは、多くの開発者が実感していることだろう。 実務での活用ポイント Javaレガシーシステムの担当者は今すぐ注目を。Diffblue Testing AgentはJavaプロジェクトを主なターゲットとしており、Spring Boot・JakartaEEベースの業務システムとの相性が良い。モダナイゼーション前の「テスト整備スプリント」に組み込む使い方が現実的だ。 既存のAIコーディング環境への統合がスムーズ。GitHub Copilotや Claude Codeをすでに導入しているチームであれば、Diffblue Testing Agentはそれらを置き換えるのではなくオーケストレーションレイヤーとして乗る。投資を無駄にせず効果を最大化できる。 コードレビューの視点変化。テスト生成が自動化されると、人間のレビュアーは「テストが存在するか」ではなく「テストが意味のある検証をしているか」にフォーカスできる。ミューテーションカバレッジ（61%）をKPIに設定することで、テスト品質の議論が具体的になる。 CI/CDパイプラインへの組み込み。PRを自動生成する機能を活かし、テスト追加をCIの一部として自動化することで、新機能追加のたびにテスト負債が積み上がる悪循環を断ち切れる。 筆者の見解 AI開発ツールの進化を2年以上追ってきて、このDiffblueのアプローチには強い納得感がある。 これまでの「AIにコードを書かせる」フェーズは、いわばAIの「作文能力」を活用する段階だった。しかし実際の開発現場で信頼を得るためには、AIが「品質保証まで含めたエンジニアリング」ができなければならない。 Diffblue Testing Agentが示しているのは、専門特化型エージェントが汎用AIコーディングアシスタントを上回るという事実だ。汎用AIコーディングアシスタントは優秀だが、テスト生成に特化して設計されたエージェントには及ばない——これは当然であり、むしろ健全な分業の形だと思う。今後は「汎用AIコーディングアシスタント ＋ 専門エージェント群」という構成が、エンタープライズ開発の標準になっていくだろう。 気になるのはJava以外への展開だ。日本の現場ではC#やPythonも多く、これらへの対応が進めば採用の障壁はさらに下がる。また、オックスフォード大学の研究ベースという点は信頼性の観点で大きな強みだが、日本語コメントが混在するコードへの対応品質も実際の導入前に検証が必要だろう。 ...

コード生成は「ボトルネック」ではなくなった JetBrainsが2026年3月、AIエージェントによる自律的なソフトウェア開発を統合管理するプラットフォーム「JetBrains Central」を発表した。2026年Q2に限定デザインパートナー向けのEAP（Early Access Program）を開始する予定だ。 この発表が示すのは、単なる「IDEにAIを追加する」という話ではない。ソフトウェア開発そのものの構造的な変容への、JetBrainsなりの回答だ。 なぜ「Central」が必要なのか JetBrainsが2026年1月に実施した「AI Pulse」調査（世界1万1000人のエンジニア対象）によると、すでに90%が業務でAIを活用している。さらに22%がAIコーディングエージェントを利用しており、66%の企業が今後12か月以内に導入を計画している。 しかし問題がある。AIの恩恵が個人の生産性向上に留まっており、開発ライフサイクル全体（コードレビューやリリースパイプラインなど）に活用しているエンジニアはわずか13%に過ぎない。 チームや組織レベルでの改善——デリバリー速度、システム信頼性、コスト効率——にAIが繋がっていないのだ。 JetBrains Centralはこのギャップを埋めることを目指している。Issueの調査、コード生成、テスト実行、マルチステップワークフローをエージェントが自動実行するにあたり、それらを「統一された生産システム」として制御・監視・管理する基盤を提供する。 3つのコアケイパビリティ 1. ガバナンスと制御 ポリシー強制、ID・アクセス管理、可観測性（Observability）、監査証跡、コスト帰属管理。エンタープライズ環境で求められる要件が一通り揃う。一部機能はすでにJetBrains Central Consoleとして提供されている。 2. エージェント実行インフラ クラウドエージェントランタイムとコンピューティングプロビジョニング。エージェントが開発環境をまたいで安定動作できる基盤を提供する。 3. エージェント最適化とコンテキスト リポジトリ・プロジェクトをまたいだ共有セマンティックコンテキスト。エージェントが適切な知識にアクセスし、最適なモデル・ツールへのタスクルーティングを実現する。 注目すべきはオープンなアーキテクチャだ。JetBrains製エージェントだけでなく、Claude Agent、Codex、Gemini CLI、あるいは自社開発のカスタムエージェントも統合可能。特定ベンダーへのロックインを避けながら、既存の開発インフラ投資を活かせる設計になっている。 実務への影響——日本のエンジニア・IT管理者にとっての意味 エンジニアへのヒント： 今すぐ試せるわけではないが、EAPデザインパートナーへの応募を検討する価値がある。特に大規模チームやCI/CDパイプラインへのAI統合を模索している組織は優先度が高い。 JetBrains IDE（IntelliJ IDEA、PyCharm、Rider等）を既に使っている場合、移行コストなく恩恵を受けやすい。 「AIにコードを書かせる」フェーズから「AIエージェントのワークフローを設計・監視する」フェーズへのスキルシフトを意識しておくべきだ。 IT管理者・アーキテクトへのヒント： コスト帰属（Cost Attribution）機能は、エージェント活用によるクラウドコストの増大を管理する上で重要になる。予算管理の観点からガバナンス機能の成熟度を注視したい。 既存のGitHub Actions、Azure DevOps等のパイプラインとの統合性についても、EAP段階で積極的に検証を行うべき局面が来るだろう。 筆者の見解 JetBrains Centralの発表を見て、私が真っ先に思い浮かべたのはAzure DevOpsとGitHub Actionsの進化の歴史だ。かつてCI/CDがエンジニアリング組織に「パイプラインの管理者」という新しい役割をもたらしたように、AIエージェントの普及は「エージェントオーケストレーションの管理者」という役割を生み出しつつある。 JetBrainsの戦略は明快だ。IDEベンダーとしての優位性を「エージェントの制御基盤」にまで拡張すること。 コード生成自体はコモディティ化しつつあるなか（OpenAI、Anthropic、Google、Microsoftが競い合っている）、どのエージェントを使っても統合・管理できる「プレーン（制御層）」を握ることに活路を見出している。 これはMicrosoftが「Copilot Studio」や「Azure AI Foundry」でエージェント基盤を構築しようとしている方向性と本質的に同じだ。異なるのは、JetBrainsが開発者体験（DX）を起点にしているという点。VSCode陣営対JetBrains陣営という旧来の競争軸は、「どのエージェント基盤でソフトウェア生産を管理するか」という競争軸に移行しつつあるのかもしれない。 日本企業にとっては、まだEAPという段階ではあるが、2026年後半にかけてエージェント駆動開発への組織的な準備を始める好機でもある。ツールの選定より先に「どのようにエージェントの成果物を検証し、ガバナンスを効かせるか」というプロセス設計を議論し始めることが、今できる最も価値ある投資だと筆者は考えている。 出典: この記事は JetBrains Central: Open System for Agentic Software Development (EAP Q2 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがGemini 3.1 Flash-Liteを正式リリースした。従来モデル比で応答速度2.5倍・出力速度45%向上を実現しながら、入力トークン100万件あたりわずか$0.25という衝撃的な低価格を打ち出している。生成AIの「高性能＝高コスト」という常識が、いよいよ崩れはじめている。 Gemini 3.1 Flash-Liteとは何者か Gemini 3.1 Flash-Liteは、Googleが「速度とコスト効率」に最適化して設計した軽量モデルだ。Geminiファミリーの中でもFlashシリーズはリアルタイム応答や大量処理に向いた系統であり、Flash-Liteはさらにその方向性を突き詰めたポジショニングになる。 主な特徴は以下の3点に集約される。 ① 応答速度の大幅改善 前世代比で初回応答までのレイテンシが2.5倍短縮。チャットボットや対話型アプリケーションでは「待ち時間」がそのままUXの質に直結するため、この改善は実運用で即効性が高い。 ② 出力スループット45%向上 長文生成や一括処理バッチのスループットが45%改善。大量のドキュメント要約やログ解析といった処理集中型ワークロードのコスト削減に直接効く。 ③ 価格設定の破壊力 入力トークン100万件あたり$0.25、出力は$0.75程度と推定される。GPT-4oのフルモデル（入力$5〜10/M）と比較すると、単純計算で10〜40倍のコスト差が生じる。「試作品でしか使えなかったコスト水準」が、本番環境でも現実的な選択肢になってきた。 なぜこれが重要か——日本のIT現場への影響 日本企業における生成AI導入の最大の障壁の一つは、依然として「コスト」だ。PoC（概念実証）段階では許容できたAPI費用が、本番移行・スケールアウト時に予算を圧迫するケースは多い。特に中小規模のSIerやスタートアップでは、ユーザー数に比例して跳ね上がるトークン費用が事業計画に影響することもある。 Gemini 3.1 Flash-Liteの価格帯は、こうした「コストで諦めていた本番展開」を現実的な選択肢に引き戻す可能性がある。たとえば以下のようなユースケースだ。 カスタマーサポートチャットボットの24時間運用（大量リクエストでもコストが読みやすい） 社内文書の全文要約・インデックス作成（数万ドキュメント規模でも費用が抑えられる） コード補完・レビュー支援ツールのCI/CD統合（パイプライン毎の実行コストが激減） 実務での活用ポイント 1. 用途に応じたモデル分割戦略を採用する すべてのリクエストを高性能モデルに通す「フラット設計」は非効率だ。複雑な推論・創造的タスクはGemini 1.5 ProやGPT-4o、定型的な分類・要約・抽出はFlash-Liteに振り分けるルーティング設計を導入することで、品質を落とさずにコストを50〜70%削減できる可能性がある。 2. Azure AI FoundryやVertex AIとの統合を活かす GeminiモデルはGoogle Cloud Vertex AI経由で利用可能であり、Azure AI Foundryも外部モデルのルーティングに対応しつつある。既存のM365環境やAzure基盤を持つ日本企業であれば、既存の認証・ガバナンスフレームワーク上でFlash-Liteを試せる環境が整いつつある。 3. プロンプト設計でコストをさらに圧縮する Flash系モデルはコンテキスト長が長くなるほどレイテンシが増す傾向がある。System Promptの最適化と、不要なコンテキストの削除（Context Pruning）を組み合わせることで、費用対効果を最大化できる。 筆者の見解 今回のGemini 3.1 Flash-Liteのリリースは、生成AIの「競争軸の変化」を象徴する出来事だと捉えている。 2023年〜2024年はベンチマークスコアの競争が主戦場だった。しかし2025年以降、モデルの性能が「十分に高い」水準に達してきたことで、差別化の軸はコスト・速度・信頼性へと移行しつつある。OpenAI、Anthropic、Googleの3社がいずれも「安価な軽量モデル」のラインナップを強化しているのは、この流れを如実に示している。 日本市場においては、この価格競争は追い風だ。一方で注意すべき点もある。安価なモデルは「ハルシネーション率」や「複雑な指示への追従性」でフルモデルに劣る場面がある。コスト削減の旨みを享受しつつ、品質評価の仕組みを合わせて整備することが不可欠だ。 また、GoogleがこのタイミングでFlash-Liteをリリースした背景には、Anthropicの「Claude 3.5 Haiku」やOpenAIの「GPT-4o mini」との競合があることは明らかだ。価格競争の激化は、エンドユーザーにとっては歓迎すべき話だが、ベンダーロックインのリスクも高まる。「今日の最安モデルが来月には陳腐化する」サイクルに備え、マルチモデル対応のアーキテクチャを設計段階から意識しておくことを強く推奨したい。 出典: この記事は Gemini 3.1 Flash-Lite Delivers 2.5× Faster Response at $0.25 Per Million Tokens の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIが、AIシステムの安全性分類タスクに特化したオープンウェイトモデル「gpt-oss-safeguard」をApache 2.0ライセンスで公開した。120Bと20Bの2サイズを提供し、Hugging Faceからダウンロードして自社環境に展開できる。クラウドAPIに依存せず、自前のAI安全対策インフラを構築できる点が大きな注目ポイントだ。 「deliberative alignment」とは何か gpt-oss-safeguardの核心にあるのが、deliberative alignment（熟慮的アライメント）という新しい手法だ。従来の安全分類モデルは、あらかじめ学習したパターンで有害コンテンツを判別するに留まっていた。これに対し、deliberative alignmentでは推論時（インファレンス時）にポリシーを直接解釈させる。つまり、企業独自の利用規約や業界ルールを自然言語で記述し、それをモデルが理解した上でリアルタイムに判断を下す仕組みだ。 これは実務上、非常に大きな違いをもたらす。これまでは「このコンテンツは有害か否か」という二値判定が主流だったが、deliberative alignmentでは「わが社のポリシーに照らしてどうか」という文脈依存の判断が可能になる。医療・金融・教育といった規制業界で求められる、きめ細かなコンテンツ制御に対応できるポテンシャルがある。 120Bと20Bの使い分け 提供される2サイズには明確な役割分担がある。 120Bモデル: 精度優先。複雑なポリシー解釈や、グレーゾーンの判断が求められるシナリオに適する。GPUリソースは相応に必要だが、クリティカルなコンテンツ審査ワークフローに向く。 20Bモデル: 速度とコストのバランス重視。リアルタイムのチャットモデレーションや、大量のログ分類など、スループットが求められる用途に最適。 エンタープライズ用途では、両モデルを組み合わせて「まず20Bで高速フィルタリング→フラグが立ったものだけ120Bで精査」という二段構えの設計も現実的だ。 なぜこれが重要か——日本のIT現場への影響 日本企業がAIチャットボットや生成AIシステムを本番導入する際の最大の壁のひとつが、コンテンツモデレーションだ。OpenAI APIやAzure OpenAI Serviceを使えばある程度の安全機能は得られるものの、業界固有のポリシーや社内規定に合わせたカスタマイズは難しかった。 gpt-oss-safeguardのオープン公開により、この状況が変わる。特に以下のシナリオで恩恵が大きい。 オンプレミス・プライベートクラウド環境: 機密情報をOpenAIサーバーに送りたくない金融機関・官公庁が、クローズドな環境でAI安全対策を実装できる カスタムポリシーの適用: 医療分野の不適切な医療アドバイスのフィルタリング、EC事業者の広告審査など、業界ルールに合わせた判断基準を自然言語で定義できる コスト削減: 外部APIコールを安全分類に使うコストを内製化により削減できる 実務での活用ポイント 明日から試せる具体的な手順として、まずHugging Faceで20Bモデルをダウンロードし、社内の検証環境（A100×1枚程度で動作可能）で既存の問い合わせログを分類させてみることをお勧めする。自社の「グレーゾーン事例」に対してモデルがどう判断するかを見るだけでも、現行の安全対策の盲点が浮かび上がってくる。 ポリシー記述には工夫が必要だ。deliberative alignmentは「禁止語リスト」ではなく「ポリシーの意図」を理解させる設計なので、「〇〇は禁止」ではなく「なぜ禁止するのか」を含めた文章で記述すると精度が上がる。 Azure上で展開する場合は、Azure Machine Learningのマネージドオンラインエンドポイントにデプロイすることで、スケーリングや監視を既存のAzureインフラに統合できる。 筆者の見解 gpt-oss-safeguardの公開は、AIの安全対策が「ベンダー任せ」から「自社で実装・管理するインフラ」へと転換する流れを加速させると見ている。 これまでOpenAIは商業APIを通じてコンテンツポリシーを一元管理してきた。それが機能する場面も多いが、業界規制が厳しい日本市場では「ブラックボックス」な安全対策に監査が通らないケースも少なくない。今回のオープン化により、「どのようなロジックで何を判断したか」を企業側が説明できる透明性が得られる。これはGDPRや金融庁のAI活用ガイドラインへの対応にも直結する話だ。 一方で、オープンウェイトモデルには「悪用されるリスク」も伴う。安全分類モデルそのものを攻撃者が解析し、検出を回避するプロンプトを作りやすくなる側面は否定できない。OpenAIがこのトレードオフをどう評価した上で公開に踏み切ったかは、今後の同社のオープンソース戦略を読み解く上でも注目に値する。 「安全なAI」を自社で実装できる時代が来た——それはエンジニアにとって自由度と責任の両方が増すことを意味する。gpt-oss-safeguardをきっかけに、AI安全対策を「費用」ではなく「競争優位」として捉え直す組織が増えることを期待したい。 出典: この記事は OpenAI Releases gpt-oss-safeguard: Open-Weight Safety Classification Models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11に搭載されているセキュリティ機能「Smart App Control（SAC）」が、長年の制約をついに乗り越えた。これまでSACを一度でも無効にしてしまうと、OSを再インストールしない限り再有効化できないという仕様が大きな足かせになっていたが、4月14日からの段階的ロールアウトでこの制限が解消される。 Smart App Controlとは何か Smart App Control（SAC）は、Windows 11 22H2で導入されたアプリケーション制御機能だ。Microsoftのクラウドベースの機械学習モデルを使い、信頼されていないアプリや悪意のあるコードの実行をブロックする。Windows Defenderのシグネチャベースの検出とは異なり、アプリの「評判」と「コード署名」を組み合わせてリアルタイムで判断する仕組みで、ゼロデイ攻撃やフィッシング経由のマルウェアに対して特に有効だ。 これまでの問題点 導入以来、SACには致命的なUX上の欠陥があった。新規インストール時や初期状態では「評価モード」として動作し、アプリの互換性を自動判断する。ここで互換性上の問題が発生すると自動的に無効化されるのだが、一度オフになったら二度と元に戻せないという仕様だった。 企業環境ではこの挙動が特に問題視されていた。展開済みのPCにSACを適用しようとすると、全台クリーンインストールが必要という現実離れした要件が障壁となり、多くの組織が導入を断念せざるを得なかった。 4月更新で何が変わるか 4月14日から段階ロールアウトが始まる更新では、Windows Security（Windowsセキュリティ）の設定画面からSACを直接有効化・無効化できるようになる。システムの再インストールは不要だ。 これにより次のようなシナリオが現実的になる： 既存PCへのSAC展開：IT管理者がグループポリシーやIntuneを使って、運用中のPCに一括でSACを有効化できる テスト・検証の容易化：互換性検証環境でSACを一時的に無効にして検証し、問題がなければ再有効化するワークフローが組める 段階的セキュリティ強化：重要システムから順次SACを有効化していくといった柔軟な展開計画が立てられる 実務への影響 — 日本のエンジニア・IT管理者にとっての意味 まず確認すべきこと： 自社のWindows 11端末でSACの現在の状態を把握しよう。「Windowsセキュリティ」→「アプリとブラウザーのコントロール」→「スマートアプリコントロール」から確認できる。 Intune管理者へ： 4月14日以降、Configuration Profileや設定カタログでSACを管理できるかどうかMicrosoftのドキュメント更新を注視すること。エンドポイントセキュリティのベースラインポリシーに組み込める可能性が高い。 業務アプリとの互換性検証： SACは署名されていないアプリや評判スコアが低いアプリをブロックする。社内開発のツールやレガシー業務アプリが影響を受ける可能性があるため、評価モードで動作させながら互換性を事前確認しておくことを強く推奨する。 注意点： 段階的ロールアウトのため、4月14日時点では全端末に即座に反映されない。winverやWindows Updateの状態と合わせてリリースノートを継続確認すること。 筆者の見解 この変更は一見「小さな使い勝手の改善」に見えるが、実態はWindowsのエンタープライズセキュリティ戦略における重要な転換点だと評価している。 Microsoftはここ数年、「Security by Default（デフォルトでセキュア）」を掲げてWindows 11のセキュリティ機能を強化してきた。しかし、どれだけ優れた機能でも「展開できない」では意味がない。クリーンインストール必須という制約は、現実の企業IT運用とのギャップが大きすぎた。この制約解消は、SACを「理論上あるセキュリティ機能」から「実際に使えるセキュリティ機能」へと昇格させるものだ。 日本企業のエンドポイントセキュリティを見ると、まだEDRやXDR導入が進んでいない中堅・中小企業も多い。そういった組織にとって、追加コストなしで利用できるSACは、ランサムウェアや標的型攻撃への有効な第一防衛線になりうる。 今後はIntune経由での一元管理や、Microsoft 365 Defenderダッシュボードとの統合が強化されていくはずだ。Windows 11移行と合わせて、SACを組み込んだエンドポイントセキュリティポリシーの再設計を検討するタイミングが来た。 出典: この記事は This Windows 11 feature no longer requires clean-installing the system to activate it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

クラウドが「外に出られない」組織の福音 Microsoftが2026年2月、政府機関・防衛組織・金融・医療などの規制産業向けに「Sovereign Private Cloud」スタックを正式発表した。従来のソブリンクラウド戦略をさらに一歩進め、インターネット接続を完全に断ち切ったエアギャップ（Air-gap）環境でも、大規模言語モデル（LLM）を含むAIワークロードを安全に稼働できる体制が整った。 Sovereign Private Cloudの3本柱 今回発表されたスタックは、3つのコンポーネントで構成される。 Azure Local（旧Azure Stack HCI）の完全非接続対応 オンプレミスに設置したAzure Localが、ネットワーク接続なしでフルに機能するよう強化された。管理プレーン・課金・更新のすべてがオフライン運用に対応し、物理的に隔離された施設でもAzureサービスのエクスペリエンスを維持できる。 Microsoft 365 Local Teams・Exchange・SharePointなどM365の主要ワークロードをオンプレミスで完結させる構成だ。データが施設外に一切出ないことを保証しながら、M365 Copilotによる生成AI支援も利用可能になる。特筆すべきは、Copilotのデータ処理を自国内で行える国が新たに11か国追加された点で、日本を含む各国の規制要件への対応が加速している。 Foundry Local（旧Azure AI Foundry Local） LLMをオンプレミスのGPUクラスター上で推論・ファインチューニングできるプラットフォーム。GPT-4クラスの大規模モデルも含め、モデルのウェイトは施設内に留まる。外部APIコールは一切発生しないため、機密性の高いドキュメント処理や情報分析にも適用できる。 なぜこれが重要か——日本のIT現場への影響 日本では防衛省・内閣サイバーセキュリティセンター（NISC）・金融庁・医療機関など、クラウドへの移行を検討しながらもデータの国外持ち出し規制や秘密保護法の壁に直面してきた組織が数多く存在する。これまではオンプレミスに独自システムを構築するか、高コストのプライベートクラウドを選択するしかなかった。 今回のSovereign Private Cloudは「Azureと同じUX・同じAPIで、データは外に出さない」という要求を正面から満たす解だ。特に以下の組織にとって意味は大きい。 防衛・安全保障関連: 秘密情報を扱うシステムへのAI導入が現実的な選択肢になる 金融機関: FISC安全対策基準やデータ主権への対応をMicrosoftスタックで一本化できる 医療・自治体: 次世代電子カルテや行政DXでCopilot活用の道が開ける 実務での活用ポイント 1. 既存Azure Stack HCI環境の評価から始める すでにAzure Stack HCIを導入済みの組織は、Azure Localへのブランド統合も含め、エアギャップ対応ファームウェアへのアップグレードパスを確認すること。Microsoftはサポートマトリクスを更新しており、既存ハードウェアが対象になる場合がある。 2. Foundry LocalのGPU要件を早期に見積もる LLMをオンプレで動かすにはNVIDIA H100/A100クラスのGPUが必要になるケースが多い。調達リードタイムが長期化している現状を踏まえると、概念実証（PoC）の段階で機材選定を並行して進めるべきだ。 3. M365 Copilotのデータ処理先を確認する テナント管理者はMicrosoft 365 管理センターで「データ保存場所」と「Copilotのデータ処理地域」を確認し、今回の11か国拡大に日本が含まれているかを検証すること（現時点では順次展開中）。 4. ガバナンスポリシーの整備を先行させる Azure Policyをエアギャップ環境に持ち込む際、ポリシー定義の更新がオフラインになることを考慮したオペレーション手順の設計が必要になる。 筆者の見解 Sovereign Private Cloudの発表を見て、Microsoftがクラウドの定義そのものを拡張しようとしていると感じた。「クラウド＝インターネット経由でリソースを借りる」という常識を覆し、「Azureのオペレーティングモデルを、接続形態に関わらず提供する」という方向性だ。 この戦略はAWSやGoogle Cloudとの差別化において非常に有効だと思う。AWSのOutpostsも同様の方向性を持つが、M365とAzure AIを一体のスタックとして提供できるのはMicrosoftだけだ。特にCopilotというキラーアプリを「完全オンプレで使える」ことのインパクトは、日本の政府・公共セクターにおけるMicrosoft選定の後押しになるだろう。 一方で課題もある。エアギャップ環境ではモデルの更新・脆弱性パッチの適用がすべて手動または計画的なオフライン作業になる。AI安全性の観点から、LLMのモデルウェイト自体に仕込まれたリスクをどう管理するかは、今後の重要な論点になるはずだ。セキュリティと利便性のトレードオフを適切に設計できる人材・体制の整備が、導入組織に求められる次の課題といえる。 出典: この記事は Microsoft Sovereign Cloud adds governance, productivity and support for large AI models securely running even when completely disconnected の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Ignite 2025で発表されたAzure Copilotの大型アップデートが、クラウド運用の常識を塗り替えようとしている。単なる会話AIアシスタントの域を超え、クラウド管理ライフサイクル全体を自律的に調整する「エージェンティッククラウド運用（Agentic Cloud Ops）」という新しい運用モデルが正式に姿を現した。 Azure Copilotとは何か——6つの専門エージェント Azure Copilotは、クラウド管理の各フェーズに特化した6種類のAIエージェントを統合したアジェンティックインターフェースだ。現在ゲートドプレビューとして提供が始まっているこれらのエージェントは以下の通り： 移行エージェント（Migration Agent） — オンプレミスやマルチクラウド環境からAzureへの移行を自律的に支援。現時点でパブリックプレビューが開始済み デプロイエージェント（Deployment Agent） — アプリケーションやインフラのデプロイ作業を自動化 最適化エージェント（Optimization Agent） — コスト・パフォーマンス・リソース利用効率の継続的改善を担当 可観測性エージェント（Observability Agent） — ログ・メトリクス・トレースを横断した統合監視 レジリエンスエージェント（Resiliency Agent） — 障害への耐性評価と自動的な信頼性向上施策の実行 トラブルシューティングエージェント（Troubleshooting Agent） — インシデント発生時の根本原因分析と解決策の提示 重要なのは、これらが単発のコマンドに応答するだけでなく、複数のエージェントが連携して複合的な運用タスクを自律実行できる点だ。 ガバナンスとセキュリティ——現場が一番気にするポイント AIエージェントに自律的な操作権限を与えるとなると、真っ先に懸念されるのがガバナンスとセキュリティだ。Microsoftはこの点を明確に意識しており、Azure CopilotはRBAC（ロールベースアクセス制御）とAzure Policyの制約の範囲内でのみ動作する設計となっている。 さらに、エージェントの操作履歴は完全に記録され、コンプライアンス監査に対応できる。チャット履歴やアーティファクトデータをユーザー自身のストレージに保持できる「Bring Your Own Storage」オプションも提供され、データレジデンシーの要件にも柔軟に対応できる。 Azureインフラの進化——70リージョン体制とAIスケール対応 エージェント機能の基盤となるAzureインフラも大幅に強化されている。世界70以上のリージョン・数百のデータセンターを擁する体制に加え、2025年9月には大規模AIワークロード特化型データセンター「Fairwater」が稼働を開始。Atlanta拠点もこれに続く形で展開が進んでいる。 コンピュート面ではAzure Cobalt（独自Armプロセッサ）とAzure Boost（オフロードシステム）、コンテナ管理ではAKS Automatic、データベースではAzure HorizonDB for PostgreSQLがラインアップに加わり、AIスケールのワークロードに対応したスタックが整いつつある。 日本のIT現場への影響——なぜ今これが重要か 日本企業のAzure活用は急速に拡大しているが、多くの組織でクラウド運用人材の不足が深刻化している。特に中堅企業では、インフラエンジニアが監視・最適化・障害対応のすべてを少人数で回す構造が続いている。 Azure Copilotのエージェント群が本番稼働レベルに達した場合、これらのルーティン運用タスクの相当部分をAIに委任できるようになる。運用コスト削減という直接効果だけでなく、エンジニアがアーキテクチャ設計やビジネス価値創出に集中できる環境が整う点が大きい。 実務での活用ポイント 今すぐできること： 移行エージェントはパブリックプレビュー開始済み。オンプレミスからの移行プロジェクトを抱えている組織は早期評価の価値がある Azure Copilotプレビューへのサインアップページが公開されているため、利用申請を検討したい 準備しておくべきこと： Azure PolicyとRBACの整備が前提条件になる。エージェントはこれらの制約に従って動作するため、ポリシーが未整備だと効果が限定的になる エージェントの操作ログをどう監査プロセスに組み込むかを事前設計しておく 「AIが自律実行する範囲」と「人間が承認する範囲」の境界線を組織として決めておく 筆者の見解 エージェンティッククラウド運用というコンセプト自体は以前から語られていたが、今回のAzure Copilotはそれを具体的な製品として形にした点で一線を画す。6エージェントの役割分担は、従来のITSM（ITサービスマネジメント）プロセスと自然に対応しており、既存の運用フローへの統合を意識した設計だと感じる。 一方で、ゲートドプレビューという段階はまだ「選ばれた組織と一緒に作り込む」フェーズであり、全面的な本番利用までには少なくとも半年から1年の成熟期間が必要だろう。AIエージェントが誤った判断でリソースを削除したり、意図しないコスト増を引き起こすリスクも現実にあるため、慎重なロールアウト計画が不可欠だ。 ...

MicrosoftがAzure AI Foundry（旧Azure OpenAI Service）上で、コーディング特化モデル「GPT-5.2-Codex」を一般提供（GA）開始した。40万トークンという桁違いのコンテキストウィンドウ、50以上のプログラミング言語対応、マルチモーダルによるコーディング支援——この3点が揃ったモデルが、既存のAzureセキュリティ境界の内側でそのまま使えるようになった意義は極めて大きい。 40万トークンのコンテキストウィンドウが変えること 現在広く使われているGPT-4系モデルのコンテキスト上限は最大128Kトークン程度だが、GPT-5.2-Codexはその約3倍にあたる40万トークンを一度の推論に投入できる。これが実務上何を意味するかというと、大規模なモノリシックコードベース全体をプロンプトに含めながら、リファクタリング・脆弱性スキャン・ドキュメント生成を一気通貫で依頼できるということだ。 たとえば、数万行規模のJavaやC#のレガシーシステムであっても、複数ファイルにまたがる依存関係ごとモデルに渡してバグの根本原因を特定させることが現実的になる。これまでは「どのファイルを切り取ってプロンプトに貼るか」という職人技が必要だったが、その手間が大幅に削減される。 セキュアコーディングとインシデント対応への対応 今回のリリースで特筆すべきは、セキュアコーディングパターンの提示・脆弱性調査・インシデント対応という用途を明示的にターゲットにしている点だ。OWASP Top 10やCWE（Common Weakness Enumeration）への対応コードを自動的に提案したり、既存コードにおけるインジェクション脆弱性を検出したりといった用途が想定されている。 セキュリティ観点でさらに重要なのは、Azure OpenAI のVNet統合・プライベートエンドポイント・カスタマーマネージドキー（CMK）といった既存のガバナンス機能をそのまま流用できる点だ。ソースコードは企業の外には一切出ない。これは特に金融・医療・官公庁系の日本企業にとって、「ChatGPTは使えないがAzure経由なら使える」という調達ルールに適合する。 実務での活用ポイント 1. CIパイプラインへのセキュリティレビュー組み込み GitHub ActionsやAzure DevOpsのPRトリガーで、GPT-5.2-Codexを呼び出して差分コードの脆弱性チェックを自動化するアーキテクチャが現実的になった。ローカルSASTツール（Semgrepなど）と組み合わせれば、誤検知を絞り込みながら精度の高いセキュリティゲートを構築できる。 2. レガシーシステムの移行調査に使う 2025年以降、多くの日本企業でオンプレ→Azureへの移行プロジェクトが活発化している。40万トークンのウィンドウを活かして、古いCOBOLやVB6のコードをそのまま入力し「どの処理がAzure Functions化できるか」の分析を依頼することが可能だ。 3. マルチモーダル機能でアーキテクチャ図からコードを生成 画像入力に対応しているため、手書きのシーケンス図やER図をスキャンして「このアーキテクチャをAzure Bicepで記述して」という使い方も有効だ。設計→実装のギャップを縮める新しいワークフローが生まれつつある。 筆者の見解 OpenAIがCodexブランドを復活させた形でこのモデルが登場したことは、Microsoftの戦略を読む上で興味深い。GPT-4oやGPT-4.5のような汎用モデルとは別に、コーディング特化モデルを独立したSKUとして提供する方向性は、Copilot製品群との差別化という観点で理にかなっている。GitHub Copilotが「IDE補完」の文脈で使われる一方、GPT-5.2-Codexは「エージェント型の大規模コード処理」に特化する分業構造が見えてくる。 日本市場においては、AIガバナンス・情報漏洩対策の観点から「クラウドに出せないコード」を抱える企業がまだ多い。そこへAzureセキュリティ境界内での提供という形でMicrosoftが打ち込んだこの一手は、まさに「日本市場向けの現実解」として機能するだろう。2026年後半にかけて、Azure AIを核にしたセキュアなコード生成基盤の整備が日本企業の競争軸になると見ている。早期に評価検証を始めた組織が、次の開発生産性競争で頭一つ抜け出すことになる。 出典: この記事は Announcing GPT‑5.2‑Codex in Microsoft Foundry: Enterprise‑Grade AI for Secure Software Engineering の内容をもとに、筆者の見解を加えて独自に執筆したものです。

E5ユーザーに朗報、Security Copilotが追加コストゼロで使える時代へ Microsoftが2026年4月、M365エコシステムに大きな変化をもたらす発表を相次いで行った。なかでも注目度が高いのが、Microsoft 365 E5ライセンスへのSecurity Copilot自動ロールアウトだ。4月20日から6月30日にかけて段階的に有効化され、追加ライセンスの購入なしにAI駆動のセキュリティ機能を利用できるようになる。 あわせて、AI活用の「次のフェーズ」を見据えたCopilot Wave 3、エージェント管理基盤のMicrosoft Agent 365、そして統合ライセンスMicrosoft 365 E7（Frontier Suite）も正式に発表された。単なる機能追加ではなく、企業がAIを「試す」段階から「組織全体で運用する」段階へ移行するための基盤整備という意味合いが強い。 Copilot Wave 3・Agent 365・E7ライセンスの全体像 Copilot Wave 3 Word・Excel・PowerPoint・OutlookといったMicrosoft 365アプリへのCopilot統合がさらに深化。文書作成・データ分析・要約・コラボレーションがアプリ内で完結するようになる。さらに、バックエンドモデルの選択肢としてOpenAIに加えてAnthropic Claudeも利用可能になるという柔軟性が追加された点は、「特定のタスクに最適なモデルを使い分けたい」という企業ニーズに応えるものだ。 Microsoft Agent 365 AIエージェントの作成・管理・ガバナンスを一元化する新プラットフォーム。部門ごとにバラバラに作られたエージェントが統制なく動き続けるリスクを防ぐ目的で設計されており、IT管理者がエージェントのアクセス権・ログ・ポリシーを横断的に管理できる。 Microsoft 365 E7（Frontier Suite） E5 + Copilot + Agent 365を1ライセンスにバンドルした新SKU。AI活用を本格展開したい企業向けに、ライセンス管理の煩雑さを解消する狙いがある。 Security Copilot in E5 — 何が変わるのか Security Copilotは以下のMicrosoftセキュリティ製品に組み込まれる形で展開される。 Microsoft Defender（脅威検出・EDR） Microsoft Entra（ID・アクセス管理） Microsoft Intune（デバイス管理） Microsoft Purview（データセキュリティ・コンプライアンス） SOCアナリストが日々直面する「アラートの洪水」に対して、AIが優先度付け・根本原因分析・対処手順の提示を自動で行う。これまでSecurity Copilotは有償のアドオンであり、利用企業は限られていたが、E5バンドルに含まれることで日本国内のE5採用企業も自動的にロールアウト対象となる。 実務への影響 — 日本のIT管理者・セキュリティ担当者が今すぐやるべきこと 1. ロールアウトの準備確認 4月20日以降、E5テナントでSecurity Copilotが順次有効化される。突然AIが有効になって戸惑わないよう、Microsoft 365管理センターで有効化スケジュールを確認しておこう。 2. データアクセス権限の棚卸し Security CopilotはDefenderやPurviewのデータを参照する。意図せず機密情報にアクセスされないよう、条件付きアクセス（Conditional Access）・DLPポリシー・監査ログ設定を事前に整備しておくことが重要だ。 3. Agent 365のガバナンス設計 部門主導でPower AutomateやCopilot Studioでエージェントを作っている企業は少なくない。Agent 365の登場を機に、エージェントのオーナーシップ・レビュープロセス・廃止ルールを明文化した社内ポリシーを整備するタイミングだ。 ...

Teams、また値上げか——と思ったら逆だった 「Microsoftのライセンス変更」と聞くと、多くのIT管理者は条件反射的に身構えるだろう。2024〜2025年にかけて相次いだ価格改定の記憶がまだ新しい。しかし今回は違う。2026年1月22日に発表され、4月1日から有効となったこの変更は、追加費用なしで機能が拡充される、珍しいアップサイドの改定だ。 具体的には、これまでTeams Premium（月額約10ドル/ユーザー）が必要だったMicrosoft PlacesのエンドユーザーUI機能と、Town Hall・ウェビナーの高度機能群が、Teams Enterprise（コアライセンス、月額約5.25ドル/ユーザー）に含まれるようになった。日本企業の多くが契約しているMicrosoft 365 E3/E5、Business Standard/Premiumにも適用される。 今回の変更点：3つのポイント 1. Microsoft Places のエンドユーザー機能が全面開放 Places Explorer と Places Finder がTeams Premiumなしで利用可能になる。 Places Finder：フロアマップ、画像、利用可能な設備情報などを元に会議室・デスクを予約できる機能。従来の「Room Finder」から大幅に進化した体験を全ユーザーに提供。 Places Explorer：マップベースでスペースを視覚的に探して予約できる。オフィスのどのエリアに誰がいるか把握しやすくなり、ハイブリッドワークの出社調整にも活用できる。 ただし、スペース・デスクの「登録数」に応じたコストは別途発生する（スペース管理側の課金モデルに変更）。つまり、ユーザー側のライセンスは安くなるが、オフィスリソースの登録数に課金される仕組みに転換された点は注意が必要だ。 2. Town Hall・ウェビナーの高度機能もコアへ eCDN（Enterprise Content Delivery Network）による大規模配信時の帯域最適化、ストリーミングチャット、組織ブランドを用いたメールカスタマイズなどが追加料金なしで利用可能になった。 大規模な全社集会（タウンホール）を定期実施している企業にとっては、これだけでTeams Premiumの費用対効果の見直し材料になり得る。 3. Teams Shared Space ライセンスへの改名と機能追加 「Common Area Phone (CAP)」→「Teams Shared Devices」と変遷してきたライセンスが、今回「Teams Shared Space」に改名。管理者向けのスペース管理・分析機能が追加され、1ライセンスにつき最大4デスクのリソース管理に対応する。 実務への影響：日本のIT管理者・エンジニアはここを見ろ ライセンスの棚卸しタイミング：今回の変更で、Teams Premiumを契約していた主な理由が「Places機能を使いたい」「タウンホールを本格運用したい」だった場合、Teams Premiumの継続購入の必要性を再検討する余地がある。逆に、AIミーティング要約（Intelligent Recap）など引き続きPremiumにしか含まれない機能に依存している場合は変わらない。 Places展開の再評価：コスト障壁が下がったことで、「試験導入で止まっていたPlaces本格展開」を推進するチャンスだ。フロアマップ整備やスペース登録に手間はかかるが、ハイブリッドワークの出社率向上・無駄な会議室予約削減に直結する。特にオフィス回帰を進めている企業は検討価値が高い。 eCDNの恩恵：全社配信イベントで映像品質が安定しなかった組織は、eCDNが標準で使えるようになることで改善が期待できる。配信担当者はTeams管理センターでeCDN設定を確認しておこう。 筆者の見解 今回の改定は、Microsoftが「Teamsコアの価値最大化」と「Premiumの差別化軸の見直し」を同時に行っているサインだと読んでいる。 Teams Premiumが登場した2023年当初は、AI機能・ウェビナー・Placesなど多様な機能を一束にした「盛り合わせ」的な位置づけだった。しかし、M365 Copilotが本命のAIライセンスとして確立されつつある今、Teams Premiumの存在意義は再定義が必要になっている。今回、PlacesとTown Hallをコアに落とし込むことで、PremiumはよりAI特化・インテリジェンス特化のアドオンとして純化させる意図が透けて見える。 日本市場においては、ハイブリッドワークのインフラ整備が欧米と比べてまだ途上の企業が多い。Places機能がコアに含まれることは、「まずは使ってみよう」という組織の背中を押す効果がある。セキュリティやプライバシー観点で慎重な日本企業でも、追加費用なしで試せるなら導入ハードルは格段に下がる。 ライセンスコストを最適化しながら現場のコラボレーション基盤を強化できる今回の変更は、IT部門にとって「良い変化」として素直に歓迎したい。年度更新のタイミングで、契約内容の見直しを強くお勧めする。 出典: この記事は Microsoft Teams April 2026 Licensing Update — Places and Advanced Town Hall Features Move into Core の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Copilot Studioが、単なるチャットボット作成ツールからエンタープライズ向けAIオーケストレーション基盤へと大きく飛躍した。マルチエージェント協調機能が正式GA（一般提供開始）となり、Microsoft Fabric連携・M365 Agents SDK対応・エージェント間通信（A2A）プロトコルの3本柱が出揃った。AIエージェント活用を本番展開へ押し上げる上で、今最も注目すべきアップデートのひとつだ。 マルチエージェントとは何か——なぜ「一体では足りない」のか AIエージェントの初期導入段階では、「ひとつの業務に特化したエージェントを作る」アプローチが有効だった。しかし組織規模での活用が進むにつれ、データチームが作ったエージェント・アプリ開発チームが作ったエージェント・生産性向上チームが作ったエージェントがバラバラに存在し、それらを連携させる際に脆弱な手作りの統合コードが必要になるという壁にぶつかる。 この「エージェントのサイロ化問題」を解消するのが、今回GAとなったマルチエージェントオーケストレーション機能だ。 3つの新機能——それぞれの役割 Microsoft Fabric連携 Copilot StudioのエージェントがFabricエージェントと連携し、企業の大規模データ・分析基盤に直接アクセスできるようになった。これまでデータ集約型のシナリオはそのたびに個別エンジニアリングが必要だったが、ビジネス向けエージェントがFabricのデータ資産と自然につながり、より正確でコンテキストを踏まえた回答を生成できる。 SQL ServerやAzure Synapse等に接続されたFabricレイクハウスのデータを、ビジネスユーザー向けのエージェント体験にシームレスに橋渡しするパイプラインが実現する。 M365 Agents SDK対応 Microsoft 365 Agents SDKを使ってビルドされたエージェントを、Copilot Studioのオーケストレーション下で組み合わせて動かせるようになった。たとえば「データ取得ロジック」「ビジネスルール適用」「承認ワークフロー」など、すでに個別エージェントとして実装済みのロジックを再利用・合成し、クロスアプリのワークフローを組み立てられる。重複実装を減らし、エージェント体験の一貫性を保てる点が大きい。 A2A（Agent-to-Agent）プロトコル 最も将来性が高いのがこのA2A対応だ。Copilot Studioのエージェントが、Microsoft製に限らずサードパーティ製のエージェントともオープンプロトコルで直接通信・委任できるようになった。特定ベンダーのエコシステムに閉じない相互運用性を実現しており、「AIエージェントのAPIエコノミー」とも呼べる時代の基盤となりうる。 実務への影響——日本のIT現場での活用シナリオ IT管理者・ガバナンス担当者へ： 複数エージェントが連携するとなると、どのエージェントが何をしたかのトレーサビリティが経営・コンプライアンス上の課題になる。Copilot Studioは今回のアップデートでガバナンスコントロールも強化されており、本番展開前に権限・ログ設定を整備することを強く推奨する。 アプリ開発チームへ： すでにM365 Agents SDKで作ったエージェントがあるなら、それをCopilot Studioオーケストレーターの「サブエージェント」として組み込む設計への移行を検討する価値がある。スクラッチで再実装するより大幅に工数が削減できる。 データエンジニアリングチームへ： FabricとCopilot Studioの橋渡しが正式サポートになったことで、「データカタログに自然言語でアクセスするエージェント」の本番化ハードルが下がった。まずFabricのデータドメインを整理し、エージェントに公開する範囲を設計する段階から着手するとよい。 筆者の見解 Copilot Studioは以前から「ローコードでチャットボットを作るツール」として認知されてきたが、今回のGA発表で性格が明確に変わった。AIエージェントのオーケストレーション基盤というポジショニングだ。 A2AプロトコルのオープンAPI化は、単なる機能追加以上の意味を持つ。MicrosoftはここでAIエージェントの「相互接続標準」の主導権を握ろうとしている。AWSやGoogle CloudもエージェントフレームワークをGA化しつつある中、A2Aの標準化競争はこれから本格化するだろう。 日本企業にとって現実的なシナリオは、まず社内に散らばった既存エージェント資産の棚卸しから始めることだ。SharePoint連携Bot・Teams通知Bot・Power Automate連携エージェントなど、すでに動いているものをCopilot Studioの傘下で「つなぐ」だけでも、体験の一貫性と管理効率は大幅に向上する。 「エージェントをひとつ作る」から「エージェント群を設計する」へ——この思考の転換が、これからのエンタープライズAI戦略の核心になると確信している。 出典: この記事は Copilot Studio GA Adds Multi-Agent Orchestration with Fabric, M365 SDK and A2A Protocol の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のタスクバー、ついに移動できるようになる Microsoftは、Windows 11においてタスクバーの位置を画面上で自由に変更できる新機能の早期プレビューを公開した。長年にわたるユーザーからの要望がついに実現に向けて動き出した形だ。 Windows 10から続く「タスクバー固定」問題 Windows 10までは、タスクバーを画面の上部・左側・右側・下部のいずれかに配置する設定が標準で提供されていた。しかしWindows 11では刷新されたデザインの影響で、タスクバーは画面下部への固定が必須となり、移動できなくなった。 これに対してユーザーコミュニティでは当初から強い反発があり、Microsoftのフィードバックハブにも多数の要望が寄せられていた。サードパーティ製ツール（「StartAllBack」「ExplorerPatcher」など）を使ってタスクバーを移動させるユーザーも多かったが、公式サポートはなく、Windowsアップデートのたびに動作が壊れるリスクも伴っていた。 公開された早期プレビューの内容 今回Microsoftが公開したのは、タスクバーを画面のさまざまな位置に移動できる機能の初期デモだ。正式な機能仕様や提供時期についての詳細は明らかにされていないが、開発が進んでいることが確認された。 プレビューの段階では、移動先の位置や動作の詳細は流動的とみられ、実際にInsiderプログラム（Windows Insider Program）での配信が始まるまでには変更が加えられる可能性が高い。 日本のユーザーへの影響 タスクバーの位置変更は、特に縦型モニターや超ワイドモニターを使用するユーザー、あるいはmacOSのDockに慣れた環境から移行したユーザーにとって待望の機能だ。複数モニター構成での作業効率向上も期待される。 企業のIT管理者にとっても、グループポリシーやMDM（モバイルデバイス管理）を通じた配置の標準化ができるようになる可能性があり、Windows 11移行を後押しする要因にもなり得る。 今後の展開に注目 MicrosoftはWindows 11の使い勝手に関するフィードバックを継続的に収集しており、このタスクバー移動機能もその成果のひとつといえる。正式な提供開始時期は未定だが、Windows Insiderプログラムを通じて近々テストが行われる見通しだ。最新情報はMicrosoft公式ブログやWindows Insider Blogで随時確認したい。 元記事: Windows 11 is getting movable taskbar, and Microsoft revealed an early look at it

Apple、創業50周年を多彩な企画で祝福 1976年4月1日にスティーブ・ジョブズ、スティーブ・ウォズニアック、ロナルド・ウェインの3人がガレージで立ち上げたAppleが、2026年4月1日についに創業50周年を迎えた。半世紀で世界最大級のテクノロジー企業へと成長したAppleは、この節目を記念してさまざまな形で祝賀イベントを展開している。 従業員への特別ギフト配布 Appleは社内の従業員に向けて特別な記念ギフトを配布した。過去にも節目の周年でカスタムアイテムやボーナスを贈った実績があり、今回も従業員への感謝を形にした施策の一つとなっている。 ティム・クックとアリシア・キーズが登場するライブイベント CEOのティム・クックと、グラミー賞受賞アーティストでAppleの「グローバル・クリエイティブ・ディレクター」としても知られるアリシア・キーズ（Alicia Keys）が共に登場するライブショーが開催された。アリシア・キーズは2013年からAppleとの関係を深めており、同社のクリエイティブ戦略に長年関与してきた人物だ。 半世紀の歩みを振り返る Appleの50年間は、パーソナルコンピュータの普及（Apple II・Macintosh）から始まり、iPodによる音楽業界の変革、iPhoneによるスマートフォン市場の創造、そして近年のApple SiliconやApple Intelligenceによる独自チップ・AI戦略へと続く革新の連続だった。日本市場においても、iPhoneのシェアは長年にわたり首位を維持しており、Apple製品は生活インフラとして深く根付いている。 創業から50年、Appleは次の半世紀に向けて空間コンピューティング（Vision Pro）や生成AIの統合をはじめとする新たな挑戦を続けている。 #Apple50 元記事: Here’s how Apple is celebrating its 50th birthday

Microsoftは、エンドポイント管理ソリューション「Microsoft Intune」の2026年3月分アップデートをまとめて公開した。今回のアップデートでは、コンプライアンス状態の可視性向上とAppleデバイスおよびモバイルアプリケーション管理の強化を中心に、複数の新機能が追加されている。 Windowsデバイスのチェックイン通知が改善 これまでWindowsデバイスへのチェックイン通知はWindows Notification Service（WNS）のみに依存していたが、今回のアップデートでMicrosoft IntuneはWNSに加え新たな通知経路も活用するようになった。これにより、ネットワーク環境の制約などでWNSが届きにくい環境でも、デバイスが確実にポリシーの変更や準拠状態の更新を受け取れるようになる。 企業のIT管理者にとって、デバイスが最新のコンプライアンスポリシーを適時に受信できるかどうかは、セキュリティ管理上の重要な課題だ。特にリモートワークが一般化した現在、オフィス外から接続するデバイスの管理信頼性向上は大きなメリットとなる。 Apple管理機能の強化 今回のリリースではAppleデバイス向けの管理機能も強化されている。iPhoneやiPad、Macをビジネス環境で活用する企業が国内でも増えており、より細かなポリシー制御やコンプライアンス状態の把握が可能になることで、Apple製品を主軸とする職場環境でもIntuneを中心とした一元管理体制を維持しやすくなる。 モバイルアプリ管理（MAM）の新機能 モバイルアプリケーション管理（MAM：Mobile Application Management）の領域でも改善が加えられた。BYODポリシーを採用している組織では、個人端末上の業務アプリとデータを安全に管理するためにMAMが重要な役割を果たしており、今回の機能追加はそのユースケースをさらに広げるものとなっている。 まとめ Microsoft Intuneは、Microsoft 365およびMicrosoft Entraと連携することでゼロトラスト戦略の中核を担うソリューションだ。3月のアップデートは地味ながらも実用的な改善が中心で、特に通知の信頼性向上とクロスプラットフォーム管理の充実という方向性は、多様なデバイスが混在する現代の企業IT環境のニーズに合致している。 各機能の詳細はMicrosoftの公式ドキュメントおよびIntune管理センターで確認できる。 元記事: Microsoft Intune Updates Improve Compliance Visibility and Device Management

Anthropic、GitHub大量テイクダウン騒動——誤操作で8,100件のリポジトリが巻き添えに AI企業Anthropicが、自社の人気CLIツール「Claude Code」のソースコード流出に対処しようとした結果、意図せず数千件のGitHubリポジトリを道連れにする騒動が発生した。 事の発端：Claude Codeのソースコードが流出 4月1日、あるソフトウェアエンジニアが最新リリースにClaude Codeのソースコードが誤って含まれていることを発見した。Claude Codeは、Anthropicが提供するLLM（大規模言語モデル）ベースのコマンドラインアプリケーションで、同カテゴリでトップシェアを誇る製品だ。 流出したコードはすぐにAIコミュニティの注目を集め、Anthropicがどのようにモデルをアプリケーションに組み込んでいるかを解析しようとするユーザーがGitHub上でコードを共有・分析し始めた。 DMCA申請が暴走——8,100件に拡大 Anthropicは米国著作権法のデジタルミレニアム著作権法（DMCA）に基づきGitHubにテイクダウン申請を送付した。しかし、GitHubの記録によれば、この申請は約8,100件のリポジトリに対して執行された。 問題は、削除対象にAnthropicが公式に公開しているClaude Codeリポジトリの正規のフォークまで含まれていた点だ。SNS上では自分のコードが突然ブロックされた開発者たちの怒りの声が相次いだ。 Claude Codeトップが「誤操作」と謝罪 AnthropicのClaude Code部門責任者であるBoris Cherny氏は、今回の大量テイクダウンが誤操作によるものだったと認め、ほとんどの申請を撤回した。最終的な対象は、問題のソースコードを含む1件のリポジトリと96件のフォークに絞られた。 Anthropicの広報担当者はTechCrunchに次のように説明している： 「今回申請されたリポジトリは、弊社の公開Claudeコードリポジトリに紐付くフォークネットワークの一部でした。そのため、テイクダウンが意図した以上の範囲に及んでしまいました。対象1件を除いて申請を撤回し、GitHubは影響を受けたフォークへのアクセスを復元しました。」 その後、GitHubは巻き添えになったリポジトリのアクセスを回復している。 IPO準備中の企業にとって痛手 今回の一連の騒動は、Anthropicが株式公開（IPO）を計画しているとされる時期に重なり、内外から注目されている。ソースコードの流出自体も問題だが、その後の対応ミスが「実行力とコンプライアンス管理能力」への疑問を呼んでいる。上場企業において自社ソースコードが漏洩すれば、株主訴訟に発展するリスクもあると業界関係者は指摘している。 日本の開発者コミュニティにとっても、Claude CodeはAIコーディングツールとして広く利用されている製品だ。今回の事件は、AIツールの急速な普及に伴うセキュリティ管理やリリース運用の難しさを改めて浮き彫りにした。 元記事: Anthropic took down thousands of GitHub repos trying to yank its leaked source code — a move the company says was an accident

Claude AIが完全なカーネルエクスプロイトを自律作成——セキュリティ研究の新局面 セキュリティ研究チームCalifoが公開した調査レポートが、技術コミュニティに大きな波紋を呼んでいる。Anthropicの大規模言語モデル「Claude」が、FreeBSDカーネルの脆弱性（CVE-2026-4747）に対するリモートコード実行（RCE）エクスプロイトをほぼ自律的に完成させ、最終的にroot権限のリバースシェルを取得することに成功したというのだ。 脆弱性の概要 今回問題となったのは、FreeBSDのカーネルモジュール kgssapi.ko に含まれる RPCSEC_GSS認証 の実装だ。具体的には sys/rpc/rpcsec_gss/svc_rpcsec_gss.c 内の svc_rpc_gss_validate() 関数に、古典的なスタックバッファオーバーフローが存在していた。 この関数はGSS-APIの署名検証のためにRPCヘッダーを128バイトのスタックバッファ（rpchdr[]）へ再構築する。先頭32バイトに固定フィールドを書き込んだ後、残り96バイトの領域にRPCSEC_GSSクレデンシャル本体をコピーするが、クレデンシャルのサイズ（oa_length）を一切検証していなかった。 96バイトを超えるクレデンシャルを送りつけるだけで、スタック上のローカル変数、カーネルレジスタの保存領域、さらにはリターンアドレスまで上書きできてしまう。攻撃対象はNFSサーバーとして動作しているホスト（ポート2049/TCP）で、kgssapi.ko がロードされていれば外部からの認証前パケットだけで攻撃が成立する。 影響を受けるバージョン: FreeBSD 13.5（p11未満） FreeBSD 14.3（p10未満） FreeBSD 14.4（p1未満）★テスト環境 FreeBSD 15.0（p5未満） 修正は FreeBSD-SA-26:08.rpcsec_gss として公開されており、コピー前に oa_length がバッファサイズを超えていないかチェックする1行が追加されている。 AIが書いたエクスプロイトの何が驚異的か このCVE自体もさることながら、研究者たちが強調するのはClaudeがエクスプロイト開発の全工程を主導した点だ。スタックレイアウトの解析、De Bruijnパターンによるオフセット特定、ROP（Return-Oriented Programming）ガジェットの探索、最終的なペイロード構築——これらのステップをAIが段階的に推論しながら進めたとされる。 KASLRが無効なGENERICカーネル（FreeBSD 14.4-RELEASE amd64）という前提条件はあるものの、「PoC（概念実証コード）ではなく、実際にroot権限のリバースシェルを取得する完全なエクスプロイト」をAIが書き切ったことは、セキュリティ業界に大きなインパクトを与えている。 日本のサーバー管理者への影響 国内ではFreeBSDはNetflixやさくらインターネットの一部インフラ、組み込みストレージ製品（FreeNAS/TrueNASはFreeBSD派生）などで利用される。NFSをKerberos認証付きで公開しているサーバーが対象となるため、直ちにパッチを適用するとともに、不要であれば kgssapi.ko をアンロードする対策が有効だ。 AIとセキュリティ研究の倫理的問い 今回の発表はAIによるオフェンシブセキュリティ研究の可能性と危うさを同時に示している。エクスプロイト開発の民主化は防御側のコスト削減にも繋がる一方、攻撃能力の裾野を広げるリスクも孕む。AI企業各社のガードレール設計が改めて問われる事例となりそうだ。 パッチ適用が完了するまでの間は、ファイアウォールでポート2049へのアクセスを信頼済みホストのみに制限することを強く推奨する。 元記事: Claude wrote a full FreeBSD remote kernel RCE with root shell

Claude Codeのブラックボックスを「見える化」するツールが登場 Claude Codeを使って複数のAIエージェントを並列実行する際、各エージェントが実際に何をしているかを把握するのは難しい。そうした課題を解決するオープンソースプロジェクト「Agents Observe」がHacker Newsに投稿され、注目を集めている。 Agents Observeとは Agents Observeは、Claude Codeのエージェント活動をリアルタイムでモニタリングするダッシュボードだ。Claude Codeのフック（hooks）機能を活用してすべてのイベントを捕捉し、WebSocketでReact製ダッシュボードにストリーミング配信する。 主な機能は以下のとおり： ツール呼び出しのリアルタイム表示：PreToolUse → PostToolUse の流れで、BashコマンドやファイルI/Oを即時確認 エージェント階層の可視化：どのサブエージェントがどの親エージェントから生成されたかを把握 フィルタリング・検索：エージェント別・ツール種別でのフィルタや全イベント横断検索 セッション履歴の閲覧：「twinkly-hugging-dragon」のような人間が読みやすい名前でセッションを管理 なぜOTELではなくフックを使うのか 開発者は、OpenTelemetry（OTEL）ではなくClaude Codeのフック機能を採用した理由についてこう説明する。「フックはOTELデータよりもはるかに多くの有用な情報を提供し、jsonlファイルと組み合わせることで完全な状況把握が可能になる」。 アーキテクチャはシンプルな4層構成だ： 元記事: Show HN: Real-time dashboard for Claude Code agent teams

Chrome 148で動画・音声のネイティブ遅延読み込みが実現へ GoogleのChromiumプロジェクトに、<video>と<audio>要素のネイティブな遅延読み込み（lazy loading）機能が追加される見通しとなった。EdgeやVivaldiなど、Chromiumベースのブラウザ全般に影響するこの変更は、Chrome 148での安定版リリースが視野に入っている。 遅延読み込みとは 遅延読み込みとは、ページを開いた瞬間にすべてのリソースを取得するのではなく、ユーザーの画面に映るタイミングで初めてリソースを読み込む手法だ。画像や<iframe>については、HTMLにloading="lazy"属性を記述するだけでブラウザがネイティブに対応してきたが、動画や音声はその対象外だった。 そのため、多くのサイトではIntersectionObserverなどを使ったJavaScriptで代替実装を行っていた。しかしこの方法には課題がある。ブラウザが持つ「プリロードスキャナー」との統合が難しく、実装が複雑になりやすい。 開発者による提案がChromiumへ この問題を解決したのが、Chromiumへの貢献で知られる独立開発者のHelmut Januschka氏だ。同氏はChrome Statusへの投稿の中で次のように説明している。 「ネイティブサポートがないため、開発者はIntersectionObserverを使ったカスタムJavaScriptを実装して、メディア要素がビューポートに入るタイミングを検出し、動的にsrc属性を設定しなければなりません。このアプローチはエラーが起きやすく、複雑性を増し、ブラウザのプリロードスキャナーとも統合できません。」 同氏の提案では、<img>や<iframe>と同様に、<video loading="lazy">や<audio loading="lazy">という形でHTMLに直接記述できるようになる。これにより、以下のメリットが生まれる。 ネットワーク状況に応じたしきい値の最適化：ブラウザが通信環境を考慮して読み込みタイミングを調整 autoplayやpreload属性との適切な連携：既存の動画制御属性とも整合的に動作 window.onloadのブロック回避：画面外のメディアがページ全体の読み込み完了を妨げなくなる データ通信量の削減：スクロールしない限り動画を取得しないため、特にモバイル環境で有効 リリースの現状 Chromiumでの実装は2026年1月に開始され、2月に変更がマージ、3月末にはshippingプロセスへ移行した。現在は安定版ビルドでデフォルト有効化するためのCLが提出されており、Chrome 148での正式リリースが濃厚とされている。 日本でもChrome・Edgeは圧倒的なシェアを持つだけに、ウェブサイトのパフォーマンス改善という観点で注目したい機能追加といえる。特にメディアリッチなコンテンツを配信するサービスにとって、JavaScriptの削減とページ速度向上の両立が実現しやすくなる。 元記事: Google Chrome’s new native video and audio lazy loading could make the web faster