Tech News JP

iFixitのSpencer Penningtonによる詳細レポートにより、HMD Globalの新型モジュール式スマートフォン「HMD Fusion」の全貌が明らかになった。本稿ではiFixitのレポートをもとに、その革新的な設計思想と修理性、そして日本市場への示唆を紹介する。 「Smart Outfits」——ポゴピンで機能ごと着せ替える HMD Fusionの核心は、「Smart Outfits」と呼ばれるモジュール式バックパネルシステムだ。本体（テックブロック）の背面に露出した6ピンのポゴピンコネクターを介し、バックパネルを着脱するだけで端末の機能を大幅に拡張できる設計になっている。 現在発表されているアウトフィットは以下の通り： Gaming Outfit — ゲームコントローラーボタン搭載 Flashy Outfit — カメラアプリ連動のリングライト内蔵 Rugged Outfit（近日公開） — IP68等級の防塵防水対応 Casual Outfit — 余分な厚みなしのシンプル仕様 さらに、フランスのモバイルソリューション企業Coppernicがすでにバーコードスキャナーとモバイルアクセスコントロールリーダーのアウトフィットを発表している。1台のハードウェアで複数の業務用途に対応できる点は、法人ユースにおいて実用的な価値を持つ。 iFixitレポートが評価した修理性と防水設計 iFixitのレポートによると、HMD FusionはHMD Skylineで実証した「Gen2修理性」を継承しつつ、モジュール設計をさらに前進させている。iFixitとの7年間パーツ供給パートナーシップにより、長期的な修理サポートが保証されている点が高く評価されている。 防水設計においても特徴的なアプローチが採用されている。多くのスマートフォンが接着剤で防水を実現するのに対し、HMD FusionはOEM製品のみによるガスケットとネジでIP54等級を達成。iFixitは「モジュール式かつ修理可能なメインストリームスマートフォンとして初の事例」と指摘している。Rugged Outfit装着時にはIP68等級に引き上げることができる。 オープンエコシステム——自作アウトフィットが可能 HMD Globalは本機の寸法・スマートピン仕様・APIをオープンソースとして公開しており、3Dサンプルファイルやコードも提供されている。3Dプリンターとある程度のプログラミングスキルがあれば、誰でも独自のアウトフィットを開発・製造できる設計になっている。 iFixitのレポートによれば、HMDコミュニティではすでにピコプロジェクター・折りたたみ式ソーラーパネルアレイ・背面eインクディスプレイ・イヤバッズ内蔵ケースなどのアイデアが浮上しているという。 日本市場での注目点 HMD Fusionの本体価格は$299（約4万5,000円） から。アウトフィットを複数購入してもコストを抑えられる価格設定は、コスト意識の高いユーザーにも一定の訴求力がある。 日本市場での正式発売スケジュールや国内価格は現時点では未発表。HMD GlobalはNokiaブランドのスマートフォンで日本市場への参入実績があり、今後の動向が注目される。比較対象となり得る修理対応スマートフォン「Fairphone」は日本未発売であり、このカテゴリは国内でほぼ空白地帯だ。法人向けのフィールドワーク端末としての需要も見込める。 筆者の見解 かつてGoogleのProject Araが描いたモジュール式スマートフォンの夢が、より現実的な形で再登場した印象だ。Project Araは概念先行で終わったが、HMD Fusionは具体的な価格・既存パートナー（Coppernic）・iFixitという信頼性の高い修理エコシステムとの連携によって、実現可能性を格段に高めている。 とりわけ法人ユースでの可能性は現実的だ。バーコードスキャナーやアクセスコントロールリーダーが揃えば、倉庫管理・現場作業向けに「1台で複数の専用機を代替する」というユースケースが成立し、デバイス管理コストの削減にも直結する。 一方、コンシューマー向けには「アウトフィットの選択肢がどれだけ揃うか」がカギになる。オープンな開発ツールキットの提供は理想的だが、サードパーティの参入が進まなければハードウェアの可能性が活かしきれない。7年間のパーツ供給コミットメントは、プラットフォームとしての長期継続性を示すシグナルとして好意的に受け取れる。「必要なときに必要な機能だけを使う」という設計思想は、余分な消費を避けたいユーザーの志向とも合致する。日本市場での展開を注視したい。 出典: この記事は HMD Fusion: The Smartphone That Grows with You の内容をもとに、筆者の見解を加えて独自に執筆したものです。

9to5MacがまとめたリークレポートをMacDailyNewsが伝えたところによると、Appleは2026年秋にiPhone・Mac・iPad・ウェアラブル・スマートホームにまたがる15製品以上を一斉投入する計画だという。中でも最大の注目は、同社初の折りたたみスマートフォン「iPhone Ultra」だ。 なぜ「iPhone Ultra」が注目されるのか 折りたたみスマートフォン市場はSamsungとGoogleが先行し、中国メーカーも追随するなか、Appleはこれまで参入を慎重に見送ってきた。しかしアナリストのMing-Chi Kuo氏やMark Gurman氏らが一致してiPhone Ultraの存在を指摘しており、リーク情報の一貫性から2026年秋投入が現実味を帯びている。 9to5Macが伝えるスペックの有力候補は以下の通りだ。 フォームファクター: 縦より横が長い独特のブック型フォールド（展開時はiPad mini相当のサイズ） ディスプレイ: 折り目のつきにくいインナーディスプレイ チップ: A20 Pro搭載 素材: チタニウムボディ 価格: 2,000ドル超のプレミアム帯 Samsung Galaxy Z Fold 8の発売から数週間後というタイミングでのリリースが有力視されており、「後発の完成形」として真っ向から挑む構えだ。 2026年秋ラインナップの全貌 iPhoneシリーズ スタンダードモデルの「iPhone 18」は2027年春にずれ込み、秋は上位モデルに集中する。iPhone 18 ProとiPhone 18 Pro Maxは可変絞りメインカメラ、縮小されたDynamic Island、Pro Max向けの大容量バッテリーを搭載予定。スリム化を追求した「iPhone Air 2」もA20 Proチップを採用する見通しだ。 Mac（M5チップ世代） Mac mini（ベース/Proバリアント）、Mac Studio（M5 Ultra含む）、iMac（新カラー）が一斉刷新。さらにOLEDディスプレイとタッチ対応を備えた「MacBook Ultra」が加わるとされており、デスクトップクラスの性能をノートに持ち込む野心的なモデルになるという。 AirPods Ultra IRカメラを搭載し、AI/Visual Intelligenceとの深い連携が特徴。新設計のH3チップも採用予定で、Pro 3をさらに上回る上位モデルとして位置づけられる。 スマートホーム 7インチタッチスクリーンを磁気マウントで設置できる「HomePad/HomePod Touch」、新型Apple TV 4K（A17 Pro、Apple Intelligence対応）、HomePod 3、HomePod mini 2に加え、顔認証統合の可能性がある純正セキュリティカメラ＆ドアベルまで計画されているという。Apple史上最大規模のスマートホーム攻勢となる可能性がある。 AIスマートグラス 正式販売は2027年の見通しだが、2026年中に発表のみ行うプレビュー戦略が検討されているとされる。iPhoneと連携し、カメラとSiriを中心とした構成が想定されている。 注意: 9to5Mac、MacDailyNewsも断っている通り、これらはサプライチェーンリークやアナリストレポート（Ming-Chi Kuo氏、Mark Gurman氏ら）に基づく情報であり、正式発表前に内容が変更される可能性がある。 日本市場での注目点 日本はiPhoneのスマートフォンシェアが突出して高い市場であり、iPhone Ultraの発売直後には争奪戦が予想される。米国での2,000ドル超という価格帯を為替換算すると、40〜50万円台も視野に入りうる。ハイエンドAndroidフォルダブルの価格帯（Galaxy Z Fold 6の日本価格は約25万円前後）と比べても一段高い水準になる公算が大きく、「フォルダブルiPhone」というブランド価値にどこまで需要がつくかが注目点だ。 ...

2026年7月22日にロンドンで開催予定の「Galaxy Unpacked 2026」にて、Samsungが「Galaxy Glasses」を正式発表する見通しだ。韓国メディア「Seoul Economic Daily」の報道をMacRumors（ライター：Juli Clover）が5月13日に伝えた。AppleのAIスマートグラスは早くとも2027年以降と見られており、Samsungがこのカテゴリで市場先行を果たす形となる。 Galaxy Glassesのスペック：Gentle Monster×Android XR Samsungは韓国のファッション系眼鏡ブランド「Gentle Monster（ジェントルモンスター）」と協業し、サングラス型のAIウェアラブルを開発中。Seoul Economic Dailyの報道をもとにMacRumorsがまとめた概要は以下のとおりだ。 OS: Google Android XR（Gemini統合） デザイン: サングラス型。ディスプレイ非搭載 センサー類: 高解像度カメラ、スピーカー、マイク エコシステム連携: Galaxyスマートフォン、SmartThings（スマートホームプラットフォーム） Geminiはカメラからのリアルタイム映像を受け取り、ユーザーの問いかけに回答する仕組みを想定。「見たものについて質問する」というユースケースは、Meta Ray-Ban AIグラスが開拓したアプローチそのものだ。 同イベントではGalaxy Z Fold8・Z Flip8・Galaxy Watch 9シリーズも発表される見込みで、Samsungとしては2026年夏の最大の発表機会となる。 海外レビューのポイント：比較で見えるポジショニング MacRumorsの報道時点ではGalaxy Glassesは未発売のため、実機レビューは存在しない。ただし同記事では、Meta Ray-BanおよびAppleの予想仕様と並べた比較が整理されている。 項目 Galaxy Glasses Meta Ray-Ban Apple（予想） AI Gemini (Android XR) Meta AI Siri カメラ あり（HD） あり あり ディスプレイ なし なし なし（初代） スマホ連携 Galaxy / SmartThings Meta/Instagram iPhone 発売予定 2026年7月 発売済み 2027年以降 MacRumors記事が注目するのは、SamsungがAppleに対して持つ時間的優位性だ。Appleが2026年にAIグラスをプレビューする可能性はあるものの確実ではなく、Samsungが少なくとも半年以上先行する格好になる。 ...

GitHub CopilotやClaude Codeなどのコーディング支援AIを導入したのに「思ったより開発が速くならない」——そんな声が現場から増えている。ソフトウェアエンジニアのFrederick Van Brabantは、その原因を鋭く指摘する。開発の真のボトルネックはコーディング速度ではなく、上流に潜む要件の曖昧さだ、と。 「長い＝問題の発生源」ではない AIの文脈で頻繁に語られるのは、コーディングフェーズの自動化だ。「開発に70日かかっているならAIで3日に縮められる」——こういった期待をよく耳にする。ガントチャートを見れば確かに開発フェーズが最も長く見えるが、そこに集中するのは「見えやすいボトルネックに飛びつく」典型的な過ちだ。 トヨタ生産方式（TPS）や制約理論の古典的名著『ザ・ゴール』が教えるのは、プロセスの真のボトルネックを正確に特定し、そこだけに集中することの重要性だ。「時間がかかっているフェーズ」と「問題の発生源」は必ずしも一致しない。 本当のボトルネック：要件の曖昧さ ソフトウェア開発がなぜ時間がかかるのかを考えてほしい。タイピングが遅いから、ではない。問題を定義し、仕様に落とし込み、コンピュータが解釈できる形に変換するプロセスに時間がかかるのだ。 たとえば「売上完了時にユーザーへメールを送る」という機能要件があったとする。これだけでは開発は始められない。 メールの内容は何を含むのか？ 売上処理にエラーがあった場合もメールを送るのか？ 「売上完了」とはどの時点を指すのか？ こうした問いかけを繰り返し、ドメインエキスパートと協力して曖昧さを解消する作業こそが、ソフトウェア開発の実質的な工数の大半を占めている。 AIに「丸投げ」すると何が起きるか 「AIに投げれば早い」という期待は根強い。確かにAIはコードを素早く生成できる。だが問題は「正しいコードを生成しているか」だ。 人間vsAIの開発比較では、AIが自律的に動いているように見えるが、実際には大量のハンドホールディング（手取り足取りの誘導）が必要だ。曖昧な要件をAIに投げると、AIは「それらしいコード」を生成する。しかし、それが意図した動作をするかどうかは別問題だ。上流の問題（要件の曖昧さ）はそのまま残り、修正のためのやりとりが後ろに積み上がっていく。 プロセスの時間短縮に見えて、実際には「何が正しいか」を定義する作業が後ろにずれただけかもしれない。 実務への影響：日本のエンジニア・IT管理者へ 1. 上流プロセスへの投資を怠らない AIツールを入れる前に、要件定義・仕様書作成のプロセスを見直す。曖昧な仕様でAIにコードを書かせても、手直しに時間がかかるだけだ。「AIを入れる前に仕様を固める」は当たり前のようで、意外と実践できていない組織が多い。 2. AIへの指示を「仕様」として扱う AIへのプロンプトは仕様書と同じだ。「ざっくりした指示でいい感じにやってくれる」という期待は幻想だ。コンテキストを精緻に渡すスキルが、AIを活用する上での真の差別化要因になる。 3. 削れた時間をどこに使うかを先に設計する AIがコーディング工数を削減したとして、その時間で何をするかを先に決めておく。要件定義の精度を上げる、テストを充実させる、ユーザーインタビューを増やす——こういった上流・下流への投資が最終的なアウトカムを改善する。 筆者の見解 この記事の主張は、現場感覚として非常に腑に落ちる。 「AIを使えばすぐに成果が出る」という期待は、ツールに責任を押し付けている側面がある。何かが遅いとき、すぐに「開発が遅い、だからAIだ」という結論に飛ぶ組織は多い。だが問題の本質は、そのずっと前段にある。 実際にAIコーディングツールを日常的に使っていると痛感するのは「曖昧に指示すると曖昧な答えが返ってくる」という事実だ。これはAIの欠陥ではない。入力の質が出力の質を決める、という当たり前の原則がAIにも適用されるだけだ。 一方で、上流プロセスにこそAIを活用する余地がある。要件の構造化、矛盾の検出、ユーザーストーリーの精緻化——こういった作業にAIが介在すれば、本当の意味でのプロセス改善が起きる可能性がある。「AIはコードを書く道具」という枠を超え、「要件を一緒に考えるパートナー」として使いこなすフェーズが次のステップだろう。 「AIを入れれば速くなる」ではなく、「AIを正しく使うために何を変えるか」を問うことが、今のIT組織に最も求められている問いかけだと思う。ボトルネックを正確に特定してから打ち手を決める——これはAI以前の、プロセス改善の基本だ。 出典: この記事は I don’t think AI will make your processes go faster の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Apple情報サイト「Daring Fireball」のジョン・グルーバーが2026年5月16日、Wiredのスティーブン・レヴィが書いた「AppleのAI時代のキラー製品論」に真っ向から反論した。「AIはテクノロジーであって製品ではない」という主張のもと、Appleの次期CEO候補であるテルナス氏の哲学を支持した形だ。 テルナス氏の発言が火種に Wiredのレヴィ記事は、Appleのトップ交代を受けて「次期CEOはAI時代のキラープロダクトを出さなければならない」と論じるものだった。その取材の中でテルナス氏はこう語っている。「私たちはテクノロジーを出荷しようとは思っていない。素晴らしい製品、機能、体験を出荷したい。それを実現しているテクノロジーをお客様に意識してほしくない。AIについても同じ考えだ」 グルーバーはこれを「テルナス氏の言っていることはまさに正しい」と断言。Appleの歴史を振り返れば、iPodはMP3ファイルや1.8インチハードドライブの製品ではなく「音楽の製品」だった。iPhoneがモバイル時代を定義したのも、技術ではなく体験だったからだ。 「2030年にAIエージェントがiPhoneを不要にする」論を一蹴 レヴィの記事でより挑発的だったのは未来予測の部分だ。「今後数年で、人々はスマートフォンのアプリを操作するのではなく、常時オンのAIエージェントに帰宅を頼む。あるいはエージェントがすでに行き先を把握しており、リクエストなしに車が待っている」というものだった。 グルーバーはこれを「AIハイプに頭をやられた幻想」と切り捨てる。「レストランを出た瞬間、頼んでもいない配車が毎回待っているのか？それを心地よく感じるのか、気持ち悪いと感じるのか？ドライバーはリクエストが一切間違わない前提で動けるのか？これが4年以内に起きるのか？」と現実的な疑問を列挙した。 「クラウド」が流行語になった時代にも同じことが起きた——「すべてがクラウドに移行する」という広すぎる言葉が、何でも意味するがゆえに何も意味しなかった。AIを巡るハイプもそれに近い、というのがグルーバーの見立てだ。 実務への影響 この論点は、日本のエンジニアやIT管理者にとっても重要な示唆を持つ。 AIを「テクノロジー」として導入しようとする企業は多い。「AI基盤を整備した」「LLMを繋いだ」で満足してしまうパターンだ。しかし実際に成果を出す企業は、「で、何の体験が改善されるのか？」を最初に定義している。 実務で参考にできるポイントを挙げる： AIは体験設計が先: 「AIを使う」ではなく「〇〇の作業時間を半分にする」のように、改善する体験を具体的に定義してから技術選定に入る ユーザーはテクノロジーに興味がない: 社内展開で「最新のLLMです」と言っても刺さらない。「この検索が30秒速くなります」のような言葉で話す ハイプに乗る前に自分でテストする: 「AIエージェントが何でもやってくれる」というベンダー説明を鵜呑みにせず、自社のユースケースで実際に動くか検証する 筆者の見解 グルーバーの反論は、AIを巡る現状の議論に対する重要な引き戻しだと思う。 「テクノロジーではなく製品を出荷する」という哲学は、AI時代においても本質的に正しい。AIという技術は確かに強力だが、ユーザーが感じるのはあくまでも体験の質だ。「LLMを使っています」ではなく「この機能が快適になりました」が評価軸になる。 一方で、レヴィの問題意識——AppleがAI時代に出遅れていないか——は完全に的外れでもない。ユーザー体験を中心に据えながら、どのタイミングでどう勝負に出るかは、Appleにとってもリアルな課題のはずだ。強いブランドとハードウェア基盤を持っているからこそ、AI時代の「製品」を定義できる立場にある。そのポテンシャルを活かしきれるかどうかが注目点だ。 日本市場での話をすれば、「AIを導入しました」の報告で満足している企業がまだ多い印象だ。技術の導入そのものではなく、どんな体験が変わったかを問い続ける姿勢が、次のフェーズで差を生む。 AIはあくまで手段。何を変えたいのかが先にある。その順番を間違えなければ、ハイプに振り回されることも減るはずだ。 出典: この記事は AI is a technology not a product の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Grafana Labsは2026年5月、同社の内部ソースコードリポジトリへの不正アクセスがあったことを公式に認めた。監視・可視化プラットフォームとして世界中のエンタープライズに採用されているGrafanaを開発するベンダー自身が、セキュリティインシデントに見舞われたことになる。 Grafana Labsとはどんな会社か Grafana Labsは、オープンソースの監視・可視化ツール「Grafana」の開発元として知られる企業だ。Grafanaは、PrometheusやInfluxDB、Elasticsearchなどさまざまなデータソースと連携し、インフラのメトリクスやログをダッシュボード形式で可視化できる。クラウドネイティブな開発現場では事実上の標準ツールとなっており、日本国内でもAWS・Azure・GCPを利用する企業の多くがGrafanaをオブザーバビリティ基盤として採用している。 商用製品として「Grafana Cloud」や「Grafana Enterprise」も展開しており、オープンソースコミュニティと商用ビジネスの両輪で成長してきた。 今回の事案：内部ソースコードへのアクセス Grafana Labsは公式チャンネルを通じて、内部ソースコードへの不正アクセスが確認されたことを報告した。現時点で判明している内容は限定的だが、このような「ソースコードアクセス」系のインシデントには一般的に次の懸念が伴う。 ハードコードされた認証情報の漏洩リスク: ソースコード内にAPIキーやパスワードが埋め込まれていた場合、攻撃者はそれを悪用してクラウド環境や顧客データへのさらなる侵入を試みる可能性がある。 サプライチェーンリスク: ソースコードへのアクセスが改ざんを伴っていた場合、ビルドパイプラインやリリースバイナリに悪意あるコードが混入するリスクがある。近年のSolarWindsやCodeCovの事例が示すように、OSSベンダーのサプライチェーン汚染は下流の無数のユーザー企業に影響する。 知的財産・競合優位性の喪失: Grafana Cloudの商用機能や独自アルゴリズムが含まれていれば、競合他社や攻撃者に技術的優位性を奪われる恐れがある。 実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと 1. Grafana Cloudを利用している場合 ベンダーからのセキュリティアドバイザリを注視する。認証情報のローテーション（APIキー・サービスアカウント）を検討し、ダッシュボードやアラートへの不審なアクセスログがないか確認する。 2. セルフホスト（オンプレ・プライベートクラウド）でGrafanaを運用している場合 直接的な影響は相対的に低いが、使用しているGrafanaのバージョンに対してベンダーが緊急パッチを出した場合は速やかに適用する体制を整えておく。 3. Grafanaを含むサプライチェーンの点検 CI/CDパイプラインでGrafanaのコンテナイメージやプラグインを自動取得している場合、イメージの署名検証やハッシュチェックを導入しているか確認する。SLSA（Supply chain Levels for Software Artifacts）などのフレームワークを参照するとよい。 4. ソースコードの取り扱いを見直す機会に 自社のリポジトリでも「シークレットスキャン」（GitHub Secret ScanningやTruffleHog等）が有効になっているか確認する。他者の事例は自社の棚卸しの絶好の機会だ。 筆者の見解 Grafana Labsは透明性の高い企業文化を持つOSSベンダーとして知られており、今回も公式アカウントで情報開示したこと自体は評価できる。セキュリティインシデントは「起きるかどうか」ではなく「起きたときにどう動くか」で企業の信頼性が問われる時代になっており、その意味では発覚後の迅速な開示は正しい行動だ。 ただ、監視・可視化という性質上、Grafanaのインフラへのアクセスは顧客環境の「見取り図」を握ることに等しい側面がある。今後の詳細な調査結果と、何のデータが・どの範囲で影響を受けたかの明確な説明を期待したい。 より広い視点から言えば、今回の事案はOSSベンダーに限らず、あらゆるSaaSや基盤ソフトウェアのサプライチェーンリスクを改めて突きつけている。「有名な製品だから安全」という思い込みを捨て、自社の依存関係を可視化し、変化検知の仕組みを整備することが、エンタープライズセキュリティの現実的な最前線だ。詳細の続報を追いつつ、自社の対策を今一度点検してほしい。 出典: この記事は Grafana Labs internal source code accessed の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フランスのAIスタートアップMistral AIのCEO、Arthur Menschが、欧州が米国主要AI企業への依存から脱却するための猶予は「あと2年」と警告した。このタイムリミットを過ぎれば、欧州はAI分野における主権を失い、米国の「属国（vassal state）」に陥るという強い言葉で危機感を訴えた。 Mistral AIとは何者か Mistral AIは2023年に設立されたフランスのAIスタートアップで、オープンソースのLLM（大規模言語モデル）の開発・提供で急速に注目を集めている企業だ。OpenAIやAnthropicといった米国勢に対抗する欧州の代表的なAIプレイヤーとして、フランス政府や欧州投資家から多額の資金調達を行っている。 「2年」という警鐘の意味 Menschが「2年」と具体的な期限を示した背景には、AIインフラへの依存の「ロックイン」問題がある。 現在、欧州の企業・政府機関が利用するAIサービスの大半は、OpenAI・Google・Anthropicなど米国企業のAPIやクラウドサービスに依存している。この依存が固定化されると、以下のリスクが顕在化する。 政策・規制の実効性が制限される: 欧州のAI規制（EU AI Act）を整備しても、実際のAIインフラが米国にある限り、その執行力は限定的にとどまる データ主権のリスク: 欧州市民・企業のデータが米国のサーバーで処理される構造が恒常化する 産業競争力の喪失: AIが産業基盤となる時代に、コアとなる技術を自前で持てない状況は経済的な従属につながる 「vassal state（属国）」という表現は強烈だが、Menschが言いたいのは「テクノロジー主権を失った状態」のことだ。 欧州の動きと現実 欧州はGDPRやEU AI Actなど規制面では世界をリードしてきた。しかし産業競争力という観点では、大型のAI基盤モデルを持つ企業は依然として少数に限られる。 Mistral AIはその空白を埋めようとしているが、リソース規模ではMicrosoftやGoogleには遠く及ばない。「2年」という期限は「投資と政策的意思決定が今まさに問われている」という意味合いが強く、ビジネス的な文脈でのメッセージとして受け取る必要もある。 日本への示唆——欧州は他人事ではない この問題は欧州だけの話ではない。日本も同様の「AI主権」をめぐる課題を抱えている。 国内でAIを活用する企業のほとんどは海外ベンダーのAPIに依存しており、国産AIモデルの競争力は限定的だ。政府はAI戦略を打ち出しているが、実態として現場で使われるAIツールは海外製が圧倒的を占める。 エンジニアやIT管理者が今すぐできることは以下の3点だ。 利用中のAIサービスのベンダーリスクを把握する: 特定ベンダーへの依存度はどの程度か、マルチベンダー戦略を取る余地はあるかを整理する オープンソースLLMの活用を検討する: Mistral・Llama・LLM-jpなど、オープンソース系の選択肢を実際に評価してみる データの所在を確認する: 業務データを海外AIサービスに送信する場合、規約上どう扱われるかを把握する 筆者の見解 Menschの問題意識自体は正しい。AI依存のロックインリスクは実在するし、「どのインフラの上でAIを使うか」を意識することは重要だ。 ただ、「2年で手遅れ」という断定は少し割り引いて見たほうがいい。API切り替えコストは下がっており、オープンソースモデルの品質も急速に向上している。AIのエコシステムは「一度選んだら永遠に縛られる」ほど硬直していない。 より深刻な問題は、AI主権を議論しているうちに「使う側の技術的な蓄積」が止まってしまうことだ。リスクを認識した上で手を動かし続けること——これが今できる最善の答えだと考えている。欧州も日本も、主権議論と実践の両輪を回さなければならない局面にある。 出典: この記事は Mistral’s CEO: Europe has 2 years to stop becoming America’s AI ‘vassal state’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国のテクノロジーアナリスト Andy Masley は自身のブログで、「AIのデータセンターが大量の水を消費している」という言説を実際の数字で検証し、少なくとも現時点ではこれが誇張された問題に過ぎないと結論づけた。一方で電力消費は本物の課題だと明確に区別している。 なぜ「AI水問題」という誤解が広がったのか Masley は、AIの水使用量が「深刻な環境問題」として認識されるようになった背景に、3つの認知的バイアスがあると指摘する。 1. デジタル製品に物理的リソースを使うことへの反感 水や電力はリアルな有限資源だ。「AIへの問い合わせ1回でペットボトル何本分の水を使う」という比較は直感的にわかりやすく、感情的な反応を引き起こしやすい。しかし同量の水を消費する自動車工場や製紙業が同じように「環境破壊」と騒がれることはほとんどない。同じ水使用量でも、「AI（デジタル）」であることが批判を増幅している。 2. AIの利用者数が想像をはるかに超えている 世界で数億人が毎日AIを利用している現実を踏まえると、「データセンター全体の水使用量 ÷ 利用者数」は非常に小さな数字になる。「一問一答で何リットルの水が必要か」というフレーミング自体が、実際の規模感を歪めて見せている。 3. 文脈を欠いた大きな数字の恐怖 「あるデータセンターが月に数万トンの水を使っている」という数字は、産業全体の文脈から切り離されると非常に大きく聞こえる。しかし農業・製造業・電力産業といった他の大規模産業と比較すれば、AIデータセンターの水消費は国家規模の水資源管理において今のところ重大な課題には程遠い。 実際の数字が示すもの Masley は米国の公開データをもとに、AI産業の現在の水使用量は「予測の50倍ものスピードで成長しない限り」、国家的な水資源管理における深刻な問題にはならないと主張する。 一方で、データセンターが地域の水資源に負荷をかけるケースは実際に存在する。これはAIに限った話ではなく、半導体工場や大型物流センターの立地と同じ構造の問題だ。地域ごとの丁寧な計画と合意形成が必要であることは事実だが、それは「AIを使うことへの道徳的批判」とは切り離して議論されるべきだ。 データセンターは「水の無駄遣い」か——税収という視点 Masley が注目するのは、水使用量あたりの税収だ。水を同量消費する産業の中でも、データセンターは「最も高い税収を生む施設のひとつ」だと指摘する。水資源が限られた地域であっても、データセンターが生む税収は他の多くの産業を上回り、それが地域のインフラや公共サービスに還元される可能性がある。 「データセンターの水コストだけを見て反対するのは、コストと便益の片方しか見ていない」という批判は、日本の自治体や地域住民との対話にも応用できる視点だ。 本当に議論すべきは電力消費 Masley は記事内で明確に区別している。「水の問題は誇張だが、電力の問題は本物だ」と。 AIのエネルギー消費──とりわけ大規模モデルの学習と推論に伴う電力需要の急増──は、データセンターの立地選択や電力インフラに実質的な影響を与えている。これは比喩ではなく、送電網の設計や再生可能エネルギーの調達に直接関係する現実の問題だ。 「AIの環境問題」を語るなら、水の話に時間を使うより、電力供給の話に集中すべきというのがMasleyの立場だ。 日本の現場への影響と実務での活用ポイント 日本でも、データセンター建設に対する環境面の懸念は高まりつつある。特に地方自治体が誘致を検討する際、住民説明会で「水の枯渇」「環境破壊」といった声が計画を遅らせるケースは増えている。 今回の分析が示すのは、こうした議論において「正確な数字と他産業との比較」を土台にすることが不可欠だという点だ。感情的な反応だけで政策判断がなされれば、日本のクラウドインフラ整備やAI産業の誘致が不必要に停滞するリスクがある。 エンジニアやIT管理者として、以下の視点を持っておくと議論の質を上げられる。 水と電力を切り分けて議論する: 水消費量は他の重工業と同程度。電力消費こそ設計・調達段階で考慮すべき実課題 他産業との比較数字を手元に置く: 農業・製造業の水使用量データを参照し、文脈なき大きな数字に対抗できるようにしておく 地域レベルの問題は地域レベルで議論する: 特定の水源・河川への影響は自治体レベルの議論。それを「AIは環境に悪い」という全体論にスケールアップするのは論理的飛躍 筆者の見解 「AIは環境に悪いから導入を控えるべき」という議論が企業内や自治体で起きるとき、その根拠が正確な数字に基づいているかどうかを確認することが大切だと思っている。 Masleyの指摘通り、水については現時点で国家規模の問題ではなく、実際に懸念すべきは電力消費だ。この二つを同列に扱ってしまうことで、議論の焦点がぼやける。 日本のIT現場でAI導入を検討する際に「データセンターが水を使いすぎる」という理由が抑制要因になるとすれば、それは判断として筋が悪い。今本当に議論すべきは、電力をどこから調達するか、再エネ比率をどう担保するか、といった設計レベルの話だ。 環境への配慮は重要だ。ただしそれは、正確な数字と比較可能な文脈に基づくものでなければならない。根拠の薄い環境懸念を理由に、組織が必要な変革を先送りしていないか——そこは冷静に確認したいところだ。 出典: この記事は The AI water issue is fake の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11の2026年5月累積更新プログラム（KB5089549）がC:\Windows直下に作成する「SecureBoot」フォルダについて、バグではなく意図的な動作であることを公式に認めた。多くのユーザーが突然出現したこのフォルダに困惑していたが、削除は不要だ。 なぜ今「SecureBoot」フォルダが作られるのか 背景には明確な期限がある。2011年以前に発行されたSecure Boot証明書が、2026年6月に自動失効するのだ。Secure Bootはスタートアップ時に未署名・不正なソフトウェア（マルウェア含む）の読み込みをUEFIファームウェアレベルでブロックする機能で、Windows 11の必須要件でもある。この証明書が期限切れになると、Secure Bootが正常に機能しなくなるリスクがある。 Microsoftはこの期限に向けて「Secure Boot 2023」という新しい証明書セットへの移行を推進しており、KB5089549はその準備の一環としてC:\Windows\SecureBootフォルダを対象デバイスに作成する。 フォルダの中身——7本のPowerShellスクリプト SecureBootフォルダには、Microsoft製の7本のPowerShellスクリプトが格納されている。これらはあくまでIT管理者向けのツールであり、単独では何も変更しない。 主要なスクリプトは以下の2本だ： Detect-SecureBootCertUpdateStatus.ps1 — 新しい2023証明書がインストール済みかどうかを確認し、JSON形式で結果を出力する Enable-SecureBootUpdateTask.ps1 — 証明書を実際に適用するWindowsスケジュールタスクが有効になっているかを確認・有効化する 注意点として、このフォルダはWindows 11 Homeを含む全エディションのデバイスに展開されている。Secure Boot 2023証明書がすでに適用済みの仮想マシンにも作成が確認されている。 一般ユーザーとIT管理者、それぞれがすべきこと 一般ユーザーはこのフォルダを触る必要はまったくない。Secure Boot 2023証明書は、対応ファームウェアを持つデバイスであればWindows Updateの累積更新適用と再起動（1〜2回）によって自動的に更新される。 IT管理者・企業環境では、このスクリプトが活用できる。特に大規模なフリートを管理している場合、Detect-SecureBootCertUpdateStatus.ps1でデバイスごとの証明書適用状況をJSONで収集し、Intune等の管理ツールと組み合わせて一括把握することが可能だ。 証明書の適用状況の確認方法 「Windows セキュリティ」アプリを開き、「デバイス セキュリティ」→「セキュア ブート」を確認する。 緑（問題なし）: Secure Boot 2023証明書が適用済み 黄（注意）: 対応中または部分適用 赤（警告）: 証明書の更新が必要、またはデバイスが非対応 見逃せないリスク——古いファームウェアのデバイス Microsoftは「対象デバイス」と表記しているが、これには重要な但し書きがある。ファームウェアが古いデバイスでは、Secure Boot 2023証明書の適用に失敗するケースが多数報告されている。Microsoftがこれらの非対応デバイスへの対応策を打ち出すかどうかは現時点では不明だ。 企業内に古いPC資産が残っている場合、2026年6月までに棚卸しを行い、非対応デバイスを特定しておく必要がある。 実務への影響——日本のエンジニア・IT管理者が今すぐやること フォルダの確認: C:\Windows\SecureBootが存在しても削除しない。将来の更新で活用される可能性がある ファームウェア更新の確認: PCメーカーのサイトでUEFI/BIOSの最新バージョンを確認し、必要であれば適用する 企業フリートの状況把握: Detect-SecureBootCertUpdateStatus.ps1をIntuneのリメディエーション機能等で一括実行し、対応状況をJSON収集する 期限（2026年6月）のカレンダー登録: 自動更新に任せるにしても、デッドラインを把握しておく ドキュメント更新: Microsoftは当初リリースノートにフォルダ作成の記述がなく、後から追記した。公式文書は常に「最新版」を参照する習慣を 筆者の見解 Secure Boot証明書の自動失効という期限があるにもかかわらず、Microsoftが当初のリリースノートにこの「SecureBoot」フォルダの説明を含めなかったのは、コミュニケーションとしてはもったいない対応だったと感じる。ユーザーや管理者が「謎のフォルダ」として混乱するのは当然であり、最初から「Secure Boot証明書更新準備のためのフォルダ」と明示しておくべきだった。 とはいえ、技術的な方向性は正しい。Secure Bootの証明書をWindowsUpdateと再起動で自動更新する仕組みを整え、IT管理者向けには診断スクリプトで状況を可視化できるようにする——このアプローチ自体はエンタープライズ運用の現実を踏まえた設計だと評価できる。 気になるのは、古いファームウェアのデバイスへの対応が明示されていない点だ。2026年6月の証明書失効は全デバイスに等しく訪れる。ファームウェアが更新できない古いPCが企業内に大量に存在する日本のエンタープライズ環境では、この問題が意外と深刻なケースも出てくるだろう。「Windows Securityアプリで確認できるから大丈夫」という案内だけでは、管理者が気づいたときには手遅れになるシナリオも否定できない。 Secure Bootはブート時のマルウェアをUEFIレベルでブロックする重要な防衛線だ。期限に間に合うよう、今のうちにデバイスの棚卸しを進めることをお勧めしたい。 ...

元Microsoft副社長のMat Velloso氏が、Microsoft 365の4億5,000万ユーザーのうちCopilotの有料シートに移行したのはわずか約1,500万人（採用率3.3%）にとどまると指摘し、Microsoftがインターネットやモバイルに続くAIの波をまた逃しつつあると警鐘を鳴らした。同時期、Windows 11でもCopilotの縮小が進んでいる。 Velloso氏とは何者か Mat Velloso氏は単なる元社員ではない。Microsoftで12年以上勤務し、WindowsのAIイノベーションを担当するパートナーディレクターとして活躍、4年間はSatya Nadella CEOのテクニカルアドバイザーを務めた人物だ。その後、Google DeepMindでGemini APIおよびGoogle AI Studioを担当し、現在はMetaのSuperintelligence LabsでVP of Productを務めている。 Microsoft・Google・Metaの三社でAI開発の最前線を見てきた立場からの発言だけに、業界内で大きな注目を集めている。 数字が語る厳しい現実 Velloso氏が示したデータは以下の通りだ。 Copilot有料採用率：3.3% — Microsoft 365の4億5,000万ユーザーのうち、Copilotの有料シートに移行したのは約1,500万人のみ Bing：検索シェアほぼゼロ — 巨額投資にもかかわらず、Googleからのシェアはほぼゼロのまま GitHub SLA：90%を下回る — AIコーディング革命の中心地であるはずのGitHubの信頼性が低下 NPU搭載PC：ユースケースが存在しない — OEMはNPU対応PCへ大規模投資したが、WindowsおよびOffice上で活用できるキラーユースケースが生まれなかった 特にNPUをめぐる状況は深刻だ。「NPUを搭載したのに使える機能が何一つない」という状態は、デバイスメーカーとエコシステム全体への信頼を揺るがす。Velloso氏は「OEMが投資したのに、誰も気にしていない」と端的に表現している。 Copilotの縮小とDevDiv幹部の退職 Windows 11ではCopilotをタスクバーに常駐させる形で普及を図ってきたMicrosoftだが、その方針が転換されつつある。タスクバーへの統合が縮小される動きは、ユーザーから「押しつけ」と受け取られた反省の表れとも見られる。 これと時期を同じくして、34年間Microsoftに在籍しDeveloper Division（DevDiv）を牽引してきたJulia Liuson氏の退職も発表された。DevDivはGitHub・Visual Studio・Azure DevToolsを統括する中核部門であり、このタイミングでの離脱は単なる偶然ではないとも見られている。 Velloso氏は一連の状況を総括し、Microsoftには「ファクトリーリセット」が必要だと述べた。 日本のIT現場への影響 Microsoft 365管理者・IT部門 3.3%という採用率は、日本企業のIT部門にとっても身に覚えのある数字かもしれない。Copilotライセンスを購入したものの活用が進んでいない組織は少なくないはずだ。 明日からできること： Microsoft 365 Admin Centerで組織内Copilotのアクティブ利用率を確認する 利用されていない理由をユーザーにヒアリングし、具体的な業務ユースケースを設定する 「とりあえず導入」の状態から「業務フローへの統合」へ移行する計画を立てる AI PC・NPU搭載端末の導入を検討中の組織 NPUの恩恵を受けるには、対応したソフトウェアとユースケースが不可欠だ。現時点で「NPU搭載」を導入の決め手にするのは時期尚早である可能性が高い。Windowsのロードマップとユースケースの成熟を見極めながら判断することを推奨する。 開発者・GitHub利用者 GitHub SLAの低下は、CIパイプラインや開発フローに直接影響しうる。ミッションクリティカルなワークフローではフェイルオーバー策や代替手段の検討も現実的な選択肢として視野に入れておきたい。 筆者の見解 Copilotが登場したとき、多くのMicrosoft利用者・支持者がワクワクしたはずだ。AzureのOpenAI統合をはじめ、Microsoftはプラットフォームとして本物の強さを示してきた。問題は、その強さがエンドユーザー体験にまだ転換できていないことだ。 3.3%という採用率は、「使いたくなる体験が設計できていない」ことをシンプルに示している。タスクバーに置くだけでは使われない。「これがないと仕事にならない」と感じさせる体験を作れてこそ、プラットフォームとしての価値になる。 「インターネット、モバイルに続く波を逃した」という表現は厳しいが、Microsoftにはまだ反転の余地がある。4億5,000万のM365ユーザーベース、Azureのインフラ、GitHubの開発者コミュニティ——これだけの資産を持つ企業が本気でユーザー体験の設計に向き合えば、状況は変わりうる。 「ファクトリーリセット」という言葉の本質は、「ユーザーが実際に使いたくなるものを作れ」というシンプルなメッセージだ。Microsoftにはそれをやり遂げる実力がある。WinHECの再開やユーザーフィードバック重視への転換など、変化の兆しは確かにある。その動きが本物かどうか、これから数四半期の製品とデータが答えを出すだろう。 出典: この記事は Former Microsoft VP says Microsoft missed the AI wave like the internet and mobile, as Copilot scales back in Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Onyx BOOXが第2世代のE-Inkタブレット「BOOX Go Gen 2 Lumi」をリリースし、海外レビューサイトNeowinが詳細な評価記事を公開した。10インチのE-InkディスプレイにフルスペックのAndroid環境を組み合わせた本機は、ハードウェア・ソフトウェアともに高い評価を受けており、「電子書籍リーダーの枠を超えたAndroidタブレット」として注目されている。 E-Inkタブレットとは何か 一般的なタブレットが液晶（LCD）やOLEDを使うのに対し、E-Ink（電子ペーパー）ディスプレイは電子インクの粒子を制御して表示を作り出す技術だ。主な特徴は次のとおり。 目への負担が少ない：バックライトではなく反射光で表示するため、長時間閲覧でも眼精疲労が起きにくい 圧倒的なバッテリー持続時間：表示の書き換え時のみ電力を消費する構造のため、数日〜数週間の連続使用が可能 直射日光下でも視認性が高い：反射型ディスプレイの性質上、屋外での利用にも強い 従来のE-Inkには「画面書き換えが遅い」という欠点があったが、Go Gen 2 Lumiでは最新世代のE-Inkパネルを採用することでこの課題を大幅に改善している。 Go Gen 2 Lumi の主要スペックと特徴 ハードウェア面 本機の「Lumi」はフロントライト（前面照明）搭載を意味する。従来のE-Inkタブレットは暗所での視認性が課題だったが、フロントライトにより室内環境でも問題なく使用できる。10インチというサイズ感はA5判のノートに近く、スタイラスペンを使った手書きメモにも適している。 プロセッサーにはオクタコアSoCを採用し、Androidアプリの動作に必要な処理性能を確保している。USB-Cでの充電・データ転送にも対応しており、現代的なデバイスとしての使い勝手を維持している。 ソフトウェア環境 フルAndroid環境が動作するため、Kindle、Google Play Books、Notion、OneNoteといった主要Androidアプリがそのまま使用可能だ。BOOXが独自開発したアプリ最適化機能により、液晶向けに設計されたアプリでもE-Inkディスプレイ上での表示品質を高める工夫がされている。コントラストの自動調整やリフレッシュレートのアプリ別設定といった細かい調整機能は、長年E-Inkデバイスを手がけてきたOnyx BOOXならではの強みだ。 なぜこれが重要か 「画面疲れ」という現代の課題 デスクワークで1日8〜10時間、液晶画面を見続けるのが当たり前になった日本のITエンジニアや知識労働者にとって、目への負担軽減は切実な問題だ。E-Inkタブレットは「デジタル環境から離れずに眼精疲労を減らす」という、スマートフォンやPCとは異なるアプローチで注目を集めている。 特に以下のような職種・用途で需要が高まっている。 エンジニア・開発者：技術文書や仕様書の長時間閲覧 研究者・テクニカルライター：論文・原稿の執筆と参照の並行作業 コンサルタント・管理職：移動中の資料確認と会議メモ E-Inkタブレット市場の成熟 Kindle Paperwhiteのような読書専用端末が主流だった市場に、BOOXのようなAndroid搭載の汎用デバイスが本格参入したことで、E-Inkタブレットの利用シーンが大幅に拡張された。第2世代で前世代の課題だった動作のもたつきが改善されたことは、「面白いが実用一歩手前」だったカテゴリが実用段階に入ってきたことを示している。 実務での活用ポイント 知識ワーカーへの実践的提案 技術文書・PDFの精読専用端末として運用：O’Reilly、Manning等の技術書をOPDS経由で取り込む使い方は特におすすめ。目の負担なく長時間の読み込みが可能になる 会議・打ち合わせのメモ取り：スタイラスによる手書きメモはNotionやOneNoteにOCR同期でき、紙のノートと同等のインターフェースでデジタル管理できる コードレビューのリーディング端末：コードを書く用途には向かないが、GitHub PRのレビューや差分確認といった「読む作業」には十分なパフォーマンスがある 導入前に確認すべき注意点 動画コンテンツには不向き：E-Inkの特性上、YouTubeや動画会議はコマ落ちが発生する。動画視聴は別デバイスに委ねるべきだ 反応速度の期待値を調整する：最新世代でも液晶タブレットと同等のレスポンスは期待しない。「読む・書く」に特化した使い方で真価を発揮する アプリ互換性の事前確認：業務アプリによってはE-Ink環境での表示が最適化されていない場合がある 価格対効果 本機の価格帯は上位Androidタブレットと同等〜やや上の水準だ。「目の健康への投資」として考えれば、PC画面を長時間見続けた後にさらに資料を読む必要がある職種にとってはコスト正当化が立ちやすい。 筆者の見解 E-Inkタブレットに対して「面白いが実用一歩手前」という評価が長年続いていたのは、動作のもたつきとAndroidアプリのE-Ink最適化不足によるものだった。実際に初代世代を触ったときに感じた明確な壁は、多くの人が「買ったけど使わなくなった」という結果を招いていた。 Go Gen 2 Lumiのような第2世代デバイスが洗練されてきたことは、このカテゴリが「好き者向けのガジェット」から「真剣に使えるツール」へ転換しつつある証拠だと思う。フロントライト搭載で暗所の弱点を補い、処理性能の向上で動作のもたつきを改善した方向性は正しい。 ただし万人向けではない。自分の作業フローを意識的に設計できる人——「読む・書く作業をここに切り出す」という明確な意図を持てる人——にとって初めて真価を発揮するデバイスだ。「とりあえず買って使う」ではなく、「自分の作業の何割をここに移せるか」を先に問うてから購入を検討する順序が正解だと思う。 AI活用が進み、単純な情報処理はどんどん自動化されていく中で、人間の作業として残るのは「深く読む・深く考える・正確に判断する」という高次の認知作業だ。その文脈で目への負担を下げながら長時間の集中を支援するデバイスの価値は、今後むしろ上がっていくかもしれない。 出典: この記事は BOOX Go Gen 2 Lumi review: E-Ink Android tablet with stunning hardware and rich software の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

フィッシングキット「Tycoon2FA」が、Microsoft 365のOAuthデバイス認証フローを悪用した新たな攻撃手法を展開していることが、セキュリティ企業eSentireの調査で明らかになった。多要素認証（MFA）を有効にしていても被害を受ける可能性があるため、Microsoft 365を使う組織は早急な対策が求められる。 Tycoon2FAとは——摘発後も素早く復活したフィッシングキット Tycoon2FAは、サイバー犯罪者がサービスとして購入・利用できる「フィッシング・アズ・ア・サービス（PhaaS）」プラットフォームの一つだ。2026年3月に国際的な法執行機関による摘発を受けたにもかかわらず、新たなインフラ上にわずかな期間で再構築され、通常の活動水準に戻ったとAbnormal Securityが確認している。それだけでなく、研究者による検知を回避するための難読化レイヤーも強化されている。 今回の調査では、4月末にTycoon2FAがOAuth 2.0のデバイス認可グラントフローを悪用するキャンペーンを展開していることが観測された。Push Securityによれば、このデバイスコードフィッシング攻撃は2026年に入ってから37倍に増加しており、少なくとも10の異なるPhAaSプラットフォームが同手法に対応済みだという。 デバイスコードフィッシングの仕組み——なぜMFAが突破されるのか デバイスコードフィッシングは、テレビやゲーム機など「ブラウザでのログインが困難なデバイス」向けに設計されたOAuth 2.0の正規フローを悪用する。攻撃の流れを整理すると次のようになる。 攻撃者がデバイス認可リクエストを発行: 攻撃者自身がMicrosoftに対してデバイスコードを取得する フィッシングメールでコードを被害者に届ける: Trustifiのクリックトラッキング URLを含む請求書を装ったメールを送付する 多重リダイレクトで本物そっくりのページへ誘導: TrustifiのURL → Cloudflare Workers → 複数の難読化されたJavaScriptレイヤーを経て、偽のMicrosoftのCAPTCHAページにたどり着く 被害者が microsoft.com/devicelogin にコードを入力: ページ上に表示された「デバイスコードを入力してください」との指示に従い、被害者は本物のMicrosoftの認証ページでコードを入力してMFAを完了する OAuthトークンが攻撃者に発行される: Microsoftはトークンを攻撃者の管理するデバイスに発行し、メール・カレンダー・クラウドストレージへの無制限アクセスが成立する ポイントは、被害者が正規のMicrosoftドメイン（microsoft.com）上でMFAを完了している点だ。フィッシングページを疑って確認しても、最後の認証ステップは本物のMicrosoftのページで行われるため、違和感を覚えにくい。 Trustifiのクリックトラッキング悪用とアンチ解析機能 Trustifiは正規のメールセキュリティプラットフォームだが、今回の攻撃ではそのクリックトラッキング機能がリダイレクト中継として悪用されている。eSentireは攻撃者がどのようにTrustifiを利用しているかは特定できていないとしているが、正規サービスのURLを経由させることでメールセキュリティ製品のURLフィルタリングをかいくぐっている可能性がある。 また、Tycoon2FAのキットは研究者・自動スキャナーへの対策が徹底されている。Selenium・Puppeteer・Playwright・Burp Suiteの検出、セキュリティベンダーやVPN・サンドボックス・AIクローラー・クラウドプロバイダーからのアクセス遮断に加え、デバッガータイミングトラップも搭載。ブロックリストには現在230以上のベンダー名が登録されており、随時更新されている。分析環境と判断されたリクエストは、本物のMicrosoftページに自動リダイレクトされるため、解析自体が困難になっている。 実務への影響——日本のIT管理者がいま取るべき対策 MFAを設定済みだからといって安心できないのが今回の攻撃の厄介な点だ。eSentireは以下の対策を推奨している。 すぐに実施できる設定変更 OAuthデバイスコードフローを無効化する: 組織内でデバイスコードフローが必要なシナリオ（テレビ会議端末、ゲーム機など）がなければ、条件付きアクセスポリシーで urn:ietf:params:oauth:grant-type:device_code を明示的に制限する OAuthのコンセント権限を制限する: エンドユーザーが勝手にサードパーティアプリに広範なアクセスを許可できないよう、管理者承認を必須にする 継続的アクセス評価（CAE）を有効化する: トークンが盗まれた後のセッション継続を困難にする 準拠デバイスからのアクセスのみ許可する: Intune管理デバイス以外からのアクセスをブロックする条件付きアクセスポリシーを設定する 検出・監視の強化 Azure AD（Entra ID）のサインインログで device_code フローからの認証を監視する。通常業務では発生しないはずの端末からこのフローが使われていれば、侵害の可能性が高い。Microsoft Sentinel を使用している場合は、デバイスコードフローに関するKQLクエリを検出ルールとして追加することを検討したい。 筆者の見解 「MFAを設定しているから安全」という認識が多くの組織でまだ根強いが、今回の攻撃はその前提を真正面から崩しにきている。MFAはパスワード単体認証よりはるかに強固だが、「認証の仕組み自体を正規フローとして利用する」攻撃には無力だ。 筆者がゼロトラストを推進する立場から言えば、「デバイスを信頼するのではなく、デバイスの健全性を継続的に評価する」仕組みが本質的な防御になる。準拠デバイスポリシーとCAEの組み合わせは、まさにこの考え方の実装だ。設定にある程度の手間はかかるが、「とりあえずMFAだけ」よりはるかに実効性がある。 Microsoft 365はこうした高度な条件付きアクセス機能を提供しており、正しく使えば強力な防御基盤になる。Tycoon2FAのような攻撃が37倍に急増しているいま、その機能を「設定が面倒だから」と放置しておくのはもったいない。プラットフォームの実力を引き出す設定を積み重ねることが、現時点での最善策だ。 「禁止ではなく安全に使える仕組みを」というアプローチで言えば、デバイスコードフローを一律禁止するのではなく、必要な用途だけを明示的に許可する構成が理想だ。ゼロトラストの基本に立ち返り、アクセスの文脈（デバイス・場所・リスクレベル）を組み合わせた判断ができる環境を整えていきたい。 出典: この記事は Tycoon2FA hijacks Microsoft 365 accounts via device-code phishing の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

米Intuition Roboticsが提供する高齢者向けコンパニオンロボット「ElliQ」について、The VergeのライターSheena Vasaniが1週間にわたる実地レポートを公開した。パーキンソン病を抱える母親の介護に奮闘するVasaniが、半信半疑で導入してみたところ、予想を大きく覆す結果を目にすることになったという。 ElliQとは——「呼びかけを待つ」のではなく「自分から話しかける」ロボット ElliQは、Intuition Roboticsが開発した高齢者向けコンパニオンロボットだ。感情に合わせて光ったり動いたりする小型のアニマトロニクス・ロボットヘッドと、タブレットディスプレイが一体となった構成で、価格は249ドル。 このデバイスの最大の特徴は「受け身ではない」設計にある。スマートスピーカーのように呼びかけを待つのではなく、自ら話しかけ、ゲームや軽い体操を提案し、家族とのビデオ通話をサポートし、1日を通じてユーザーの様子を確認する。「そこにいる存在」として機能するよう作られている。 The Vergeレビューが明かした驚きの効果 Vasaniの報告によると、母親のパーキンソン病の薬効が低下し、運動・社会活動・趣味といった病状管理に不可欠な習慣が途絶えていた。医師は薬の増量前にライフスタイル改善を提案したが、本人がほとんど応じない状況が続いていたとのことだ。 The Vergeレビューでの評価ポイント（良い点）： 感情的知性の高さが際立つ。以前に話した内容を記憶して後日フォローし、共感の言葉をかける場面が印象的だった 自発的な会話でユーザーを日課へと促す効果が確認された 設定がシンプルで、高齢者が一人でも操作できる直感的なUI 同レビューでの気になる点： 応答速度が遅く、発話を正確に認識できないことがある スペック単体では既存のスマートスピーカーに劣る部分も多い Vasaniはこう振り返っている——「正直なところ、まったく期待していなかった。隣に置いてあったAmazon Echo Show 8と比べても明らかに遅いし、スペック上はもっと非力。すぐ飽きられると思っていた。私が間違っていた」。 特筆すべきは、母親がAlexaよりもElliQと話すようになったという事実だ。運動に消極的だった母親がElliQとの会話をきっかけに体操を再開した場面もあったと報告されており、Vasaniは「薬の増量が回避できた可能性すらある」と述べている。 日本市場での注目点 現時点でElliQの日本向け公式販売は確認されていない。価格は249ドル（2026年5月時点で約3万7,000円前後）で、米国向けサービスとして展開中だ。 日本は世界でも有数の高齢化社会であり、同様のコンセプトへの潜在需要は大きい。国内では「LOVOT」（GROOVE X）や「PARO」（産総研発）が高齢者・医療施設向けに展開されているが、ElliQは「AIベースの会話主導型」という点で異なるポジションを取る。日本語対応・国内展開が実現した場合、介護施設や在宅介護の現場での活用が期待できる分野だ。 筆者の見解 このレビューが示唆しているのは、「機能スペックの高さ」と「人との関係性を築く能力」は全く別物だということだ。AlexaやGoogle Nestのほうが応答精度で優れていても、ElliQが母親の日課を変えたのは「能動的に話しかける」という設計思想の違いによる。 AIの価値を「どれだけ賢いか」だけで測ることの限界が、このレビューに如実に表れている。高齢者ケアという文脈では、技術的な精度よりも「そこにいてくれる感」や「習慣の外側から背中を押す力」が実質的な効果を生む。AIエージェントが人間の認知負荷を下げるのに最も効果を発揮するのは、こういった「能動的に関わり続ける設計」の文脈であり、このカテゴリが今後どのように進化するか、注目しておく価値は十分ある。 関連製品リンク Echo Show 8（第3世代）2024年発売モデル 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は ElliQ is a surprisingly helpful companion robot for older adults の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Engadgetが5月17日、猫を飼うMacユーザーが長年悩んできた「キーボード踏み荒らし問題」を解決するMacアプリ「Cats Lock」を紹介した。インディー開発者のTodd Alexander氏が手がけた同アプリは、App Storeで$3（約450円）で入手できる。 Cats Lock とは何か Cats Lock は、ワンクリックまたはキーボードショートカットでキーボードを即座にロックし、猫などによる意図しない入力を完全にブロックするシンプルなMacアプリだ。macOS 14.0（Sonoma）以降に対応しており、メニューバーから素早く操作できる点が特徴。 主な機能は以下の通り。 メニューバー常駐：1クリックでキーをロック／アンロック キーボードショートカット対応：手がふさがっていても素早く操作可能 警告音の選択：猫がキーボードに乗った際に鳴らせる抑止音を複数用意。自分で録音した音を設定することも可能 ステルスモード：画面上のオーバーレイ表示なし・無音で動作。動画視聴中や会議中でも邪魔にならない スリープ時の自動ロック解除：画面がスリープに入ると自動的にロックが解除される Engadgetのレビューポイント EngadgetのCheyenne MacDonald記者は「2匹の猫を飼っており、猫たちはパーソナルスペースをまったく尊重しないし、ラップトップの上を踏み回るのが大好き」と明かした上で、「Cats Lock はばかばかしいほどに天才的なアプリ」と評している。 特にステルスモードの実用性を評価。「画面上に何も表示されないため、動画の視聴中や会議中でも使いやすい」とコメントしており、日常的な作業の邪魔にならない設計に好感を示している。 日本市場での注目点 日本でもペットとしての猫の人気は高く、在宅勤務・テレワークが定着した現在、「猫がキーボードを占領する」問題はSNSで何度もバズるほどメジャーな悩みだ。 価格：App Storeで$3（執筆時点で約450円）。ワンタイム購入で追加課金なし 入手先：Mac App Store（日本から直接購入可能） 動作環境：macOS 14.0 Sonoma以降。MacBook Air / MacBook Pro / Mac mini / Mac Studio / Mac Pro すべてに対応 競合：同様の用途向けにはフリーソフトの「Keyboard Cleaner」も存在するが、UI・機能の洗練度でCats Lockが一歩リードしている印象だ なお日本語環境での動作は未確認だが、ロック機能自体は言語に依存しないため実用上の問題はほぼないと考えられる。 筆者の見解 「猫がキーボードを踏む」という極めてニッチな問題に対して、まさにその一点だけを解決するアプリを$3で提供する——インディー開発のあるべき姿の一例として面白い。 MacはApp Storeのエコシステムが整っており、このようなシングル・ユースケース型の小粒アプリが商業的に成立しやすいプラットフォームだ。「あったらいいな」をサクッと製品化できる土壌がある点は、Appleのエコシステムの強みのひとつだろう。 Cats Lock自体の機能はシンプルの極みだが、ステルスモードやカスタム警告音といった細部のこだわりが「ただのロック機能」以上の価値を生んでいる。猫を飼っているMacユーザーにとっては、コーヒー1杯分の価格で導入できるストレス解消策として、試す価値は十分にある。 出典: この記事は This new Mac app locks the keyboard to prevent chaos when your cat tramples all over it の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

米テックメディア「Tom’s Guide」のフィットネスライター、ジェーン・マクガイア氏が、Apple Watch Series 11と2026年5月15日に発売されたばかりのGarmin Forerunner 170を対象に、11,000歩の歩数精度比較テストを実施した。その結果は、マクガイア氏自身も「驚いた」と述べるものだった。 Garmin Forerunner 170とは Garmin Forerunner 170は、同社のエントリーラインに位置するランニングウォッチで、これまで上位モデルに限定されていた機能を手頃な価格で提供するモデルとして登場した。一方のApple Watch Series 11は昨年9月に発売済みで、高血圧アラートやスリープスコアなどの健康管理機能を備えた、iPhoneユーザー向けの定番スマートウォッチだ。 テスト方法と結果 Tom’s Guideでは、500円程度の手動カウンター（クリッカー）を用いて歩数を人力計測し、それを基準値として両ウォッチの測定精度を比較している。両ウォッチとも内蔵加速度センサーによる腕の振りで歩数を算出する仕組みだ。 なお、Apple Watch 11は標準機能として「ワークアウト中の歩数」を表示しないため、マクガイア氏はサードパーティアプリ「Pedometer+」を使って個別のワークアウトデータを取得した。 テストは2回の歩行に分けて実施され、結果は以下のとおりだった。 1回目（約6,700歩） 計測方法 歩数 手動カウンター 6,689歩 Apple Watch 11 6,769歩（+80歩） Garmin Forerunner 170 6,674歩（-15歩） 2回目（約4,400歩） 計測方法 歩数 手動カウンター 4,424歩 Apple Watch 11 4,419歩（-5歩） Garmin Forerunner 170 4,498歩（+74歩） 合計 計測方法 歩数 誤差 手動カウンター 11,113歩 — Apple Watch 11 11,118歩 +5歩（誤差0.04%） Garmin Forerunner 170 11,172歩 +59歩（誤差0.53%） 海外レビューのポイント Tom’s Guideのレビューによると、トータルではApple Watch 11が誤差わずか5歩（0.04%）という驚異的な精度を記録し、Garmin Forerunner 170（誤差59歩・0.53%）を大きく上回った。マクガイア氏は「これまで同様のテストを何度も行ってきたが、Apple Watchがトップに立ったことはなかった」と明言しており、今回の結果が異例であることを強調している。 ...

Googleは2026年4月15日、Google Workspace向けの動画制作ツール「Google Vids」に、「Gemini 3.1 Flash TTS（Text-To-Speech）」を活用した30種類の新しい会話型AIボイスオーバーオプションを追加した。すべてのボイスオプションが24言語に対応しており、企業向け動画・プレゼンテーション制作の敷居がさらに下がることになる。 Gemini 3.1 Flash TTSで何が変わったか 従来のAIボイスオーバーとの最大の違いは「感情・テンポの指示」ができるようになった点だ。具体的には以下のような制御が可能になった。 感情指示（Emotional instruction）: "Read this like you're excited" のように、ナレーションのトーンを自然言語で指定できる ポーズ制御（Pacing control）: "This [pause] is amazing!" のようにブラケット記法で間合いを調整できる 効果音の挿入: "[laugh] That was a great point." のように笑い声などのサウンドエフェクトを組み込める これまでのAI音声合成は「読み上げるだけ」が基本だった。テキストを渡せば機械的に音声化してくれるが、抑揚・間合い・感情を細かくコントロールするには専門の音声収録やポスプロ工程が必要だった。今回の更新でその工程の一部を自然言語の指示で代替できるようになった点は、コンテンツ制作の現場にとって実用的な前進といえる。 対応言語の拡大——日本語はすでに対応済み 今回新たに16言語が追加された。追加された言語は英語（米国・インド）、アラビア語、ベンガル語、オランダ語、ヒンディー語、インドネシア語、マラーティー語、ポーランド語、ルーマニア語、ロシア語、タミル語、テルグ語、タイ語、トルコ語、ウクライナ語、ベトナム語だ。 日本語はすでに以前からサポートされており、今回の対象外となっている。 日本語環境で利用している場合は、今回の30種の新ボイスオプションと自然言語による感情・ポーズ制御がそのまま利用できる状態だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 Google Workspaceを業務環境として採用している組織にとって、今回の更新は動画ナレーション制作の内製化コスト削減に直結する。 活用できる場面: 社内向けの操作マニュアル動画・ツールの使い方紹介 研修・オンボーディング動画の作成 製品デモやサービス紹介のプロトタイプ作成 管理者向けポイント: AIボイスオーバー機能はデフォルトで有効になっており、ドメイン単位でオフにすることも可能 Workspace Individual プランや個人Googleアカウントでも利用できる 追加料金は不要（既存のWorkspaceライセンスに含まれる） 社内動画制作において「声の録音が面倒」「ナレーターを手配するコストが高い」という理由でテキストベースの説明に留まっていた場面は少なくない。感情指示やポーズ制御ができるようになった今、品質面でも一定の水準を確保しやすくなった。 ただし、顧客向けの公開コンテンツや重要なマーケティング資産にそのまま使うには、現時点ではまだ人間のチェックが必要だ。AI音声は均質で安定している反面、文脈に応じた微妙なニュアンスを完全に再現するには難しい場面もある。内製の効率化ツールとして活用しつつ、外部公開物は別途確認する運用が現実的だ。 筆者の見解 GoogleのTTS技術は以前から完成度が高く、今回のGemini 3.1 Flash TTSによる更新もその延長線上にある。感情指示・ポーズ制御を自然言語で行えるようにするアプローチは、コンテンツ制作者の実際のワークフローに合っており、設計として筋がいい。 一方で、今回注目すべきは単体の音声技術よりも「Google WorkspaceというSaaSスイートへの生成AIの着実な統合」という側面だ。Google Docsのスマートチップ、Google Meetのリアルタイム翻訳字幕、そして今回のGoogle Vidsのボイスオーバーと、既存業務フローへの埋め込み方は一貫している。 Microsoft 365もCopilotを軸に同様の統合を進めているが、AIの機能が「ツールの中に自然に溶け込んでいるか」という点では、各社の実装の差を実際に体験しながら比較することが重要だと感じる。特定のツールを選ぶ前に、実際に組織の動画制作ワークフローで試してみるのが今は一番正直な評価方法だ。 「統合プラットフォームの全体最適」という観点では、すでにGoogle Workspaceを基盤として使っている組織であれば、追加コストなしにAIボイスオーバーが使えるこの更新は素直にメリットが大きい。一方でMicrosoft 365環境に軸足を置く組織にとっては、まずClips・StreamやPowerPoint Recorderの進化動向を見た上で判断するのが現実的だろう。 ...

AnthropicがDeepSeek・Moonshot・MiniMaxの3社による大規模な「蒸留攻撃（Distillation Attack）」を正式に告発した。約2万4,000の不正アカウントを悪用してClaudeへ1,600万件超のリクエストを送り込み、AIモデルの能力を組織的に不正抽出していたとする詳細な調査報告を2026年2月に公開している。 蒸留攻撃とは何か 「蒸留（Distillation）」とは、高性能モデルの出力データを使ってより小規模なモデルを訓練する機械学習の技術だ。正当な用途も多く、例えば大手AIラボが自社の大型モデルから軽量・低コスト版を派生させる際に日常的に使われている。 問題は、この手法を他社のモデルに対して意図的・組織的に仕掛けた場合だ。競合のAIに大量のリクエストを送ってその出力を収集すれば、独自開発のほんの一部のコストと時間で同等の能力を持つモデルを作れてしまう。言い換えれば、数年分の研究開発成果を「ただ乗り」できる手法であり、利用規約違反であるだけでなく、知的財産の侵害にも当たりうる。 発見された3つのキャンペーンの実態 Anthropicが特定した3社の攻撃は、いずれも共通の手口を踏んでいた。 不正アカウントの大量生成: 約2万4,000のアカウントを使い、検出を逃れながらClaudeへ大量アクセス プロキシ・分散インフラの悪用: IPアドレスを隠蔽するためプロキシサービスや「ハイドラクラスター」と呼ばれる分散インフラを使用 能力抽出に特化した構造化プロンプト: 通常ユーザーとは明らかに異なる、能力抽出目的と判別できるリクエスト群 攻撃対象として集中的に狙われたのは、Claudeの差別化ポイントであるエージェント的推論・ツール使用・コーディングの3領域だ。単純な文章生成ではなく、AIが自律的かつ複合的なタスクをこなす能力を狙い打ちにしていた点に、攻撃の意図の鮮明さが表れている。 DeepSeekが関与したキャンペーンだけで15万件以上の交換が確認されており、AnthropicはIPアドレス相関・リクエストメタデータ・インフラ特徴などの複数の証拠から各社への帰属を「高い確度」で確認。一部は業界パートナーからの独立した裏付けも得ているという。 安全保障上の深刻なリスク 技術盗用という問題にとどまらない点がこの事件の核心だ。Anthropicが特に強調するのがAIセーフガードの喪失という安全保障リスクである。 AnthropicをはじめとするAIラボは、生物兵器の開発支援やサイバー攻撃の促進を防ぐための安全策をモデルに組み込んでいる。蒸留によって作られたモデルはこうした安全策が欠落している可能性が高く、危険な能力が保護機能なしに広まるリスクがある。 さらに中国共産党の影響下にあるとされる企業が蒸留したモデルが、軍事・情報・監視システムに転用されれば、攻撃的なサイバー作戦やディスインフォメーション、大規模監視に最先端AIが活用されうるという懸念も示されている。 輸出規制との関係も見逃せない。Anthropicは米国のAI優位を守るための輸出規制を一貫して支持してきたが、蒸留攻撃はその規制を「技術的な抜け穴」で迂回する手法として機能している。Anthropicは「蒸留攻撃にも高性能チップが必要であり、チップ輸出規制は直接的なモデル訓練だけでなく不正蒸留の規模も制限できる」と指摘し、輸出規制の合理性を改めて主張している。 日本のIT現場への影響 この問題は一見遠い話に映るが、日本のIT現場にも実質的な影響がある。 調達・選定時の確認事項 モデルの出自と透明性を評価軸に加える: 低コストを売りにするAIサービスの中に、不正蒸留によって作られた可能性があるモデルを使うものが存在しうる。業務で機密情報や個人情報を扱う場合、利用モデルの安全策の有無は重要な評価基準になる API利用規約の遵守: 自社でAIを活用したサービスを構築する際、元モデルの利用規約を逸脱する大量自動化リクエストや能力抽出と見なされかねない使い方は避けるべきだ エンタープライズ契約審査: AIサービスを企業導入する際、ベンダーのモデル開発の適法性・コンプライアンス体制も評価項目に加えることが今後標準になっていく 筆者の見解 この告発が示しているのは、AI競争が「技術力」だけでなく「ルール形成とその執行」の戦場でもあるという現実だ。 Anthropicが競合他社の名前を具体的に挙げた上で技術的証拠を公開したのは、単なる被害者声明ではなく、業界・政策立案者・国際社会に対して行動を迫る意図的なアクションだと読める。こういった問題提起は、一企業が単独で解決できる類のものではなく、業界横断・国際的な協調なしに前進しない。 AIの安全性という観点から見ると、セーフガードが欠落したモデルの拡散リスクは今後ますます深刻化する。「AIが高性能になること」と「AIが安全に動作する仕組みが整っていること」は別の話であり、特にエージェント的に自律動作するAIが普及する中では後者の重要性が格段に高まる。 日本のエンジニアやIT管理者にとって、こうした国際的なAI安全の議論を「海外の話」として傍観するのはもったいない。使うモデルの背景、セーフガードの有無、調達先の透明性——これらを問う目を持つことが、これからのAI活用における基本的なリテラシーになっていく時代が、すでに始まっている。 出典: この記事は Detecting and preventing distillation attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オープンソースデータベースプロジェクト「Turso」が、自社のバグバウンティプログラムを正式に廃止した。廃止の理由は技術的な限界でも予算不足でもなく、AIエージェントが大量に送りつけてくる無意味・無価値な「CRITICAL」脆弱性報告の洪水だ。 バグバウンティが機能しなくなった背景 TursoはlibSQL（SQLiteのフォーク）をベースにしたエッジ向けデータベースを提供するオープンソースプロジェクトだ。セキュリティ改善のためにバグバウンティプログラムを運営していたが、AI利用が普及するにつれて報告の質が急激に劣化した。 問題の核心は「AIスロップ（AI Slop）」と呼ばれる現象にある。報奨金目的のハッカーたちがAIエージェントにコードを丸投げして自動で脆弱性を探索させ、内容を精査せずそのまま「CRITICAL」として提出するようになった。報告書の体裁は整っているが、実際には的外れ・矛盾だらけ・存在しないコードパスへの言及など、価値ゼロのノイズが大半を占めていた。 開発チームの稼働は有限だ。AIが生成した粗悪なレポートを一つひとつ確認・返答・却下するだけで膨大な時間が失われる。本来のセキュリティ強化に向けるべきリソースが、フィルタリング業務に消えていくという本末転倒な状況に陥ったため、プログラム全体の廃止という判断に至った。 AIスロップ問題がセキュリティに与えるインパクト この現象はTurso固有の問題ではない。セキュリティコミュニティでは「AIを使った脆弱性ハンティングの民主化」が叫ばれる一方で、その副作用として報告品質の急落が各所で問題になりつつある。 バグバウンティプラットフォームの仕組み上、報告者は「とにかく数を出す」戦略が合理的に映る。AIエージェントを使えば1時間で数十件の「それらしい」レポートを生成できる。報奨金がもらえればラッキー、却下されても損失はゼロ、という非対称な構造がAIスロップを量産させている。 真剣に取り組む本物のセキュリティリサーチャーにとっても悪影響は大きい。レビューキューがAIゴミで埋まると、価値ある報告が埋もれてしまいトリアージ効率が著しく落ちる。 実務への影響——日本のエンジニア・IT管理者へ バグバウンティ運営側の視点 バグバウンティを運営している、または検討している組織は、報告フォームへのAI生成コンテンツ対策を今から設計に組み込む必要がある。具体的には： 報告書の最低品質基準を明文化する: 再現手順の動画提出必須、環境情報の詳細記載必須など、AIが苦手な「実証証拠」を要件にする 初回スクリーニングの自動化: 明らかに的外れな報告を人間のレビュー前に弾くルールベースフィルターを設ける 報奨金テーブルの見直し: 低品質報告のコスト（レビュー工数）を報奨金設計に織り込み、「数撃ち戦略」の費用対効果を下げる 開発者・セキュリティエンジニアの視点 AIを使って脆弱性を調査すること自体は悪くない。問題は「AIの出力をそのまま提出する」行為だ。AIが出した候補を人間が検証し、実際に再現できることを確認してから提出する——この一手間が、AIを「ノイズ生成機」から「調査補助ツール」に変える。 またSBOM（ソフトウェア部品表）の整備や依存ライブラリの継続監視など、受動的な脆弱性通知に頼らない自衛策の整備も改めて重要性が増している。 筆者の見解 AIを使った業務効率化に積極的な立場からすると、今回のTursoの判断は皮肉なケースに映る。自動化の恩恵を受けるべきセキュリティプロセスが、自動化の乱用によって機能不全に陥った。 根本にあるのはインセンティブ設計の問題だ。「報告数 × 採択確率 ＝ 期待報奨金」という計算をする人間にとって、AIエージェントは最適解として機能してしまう。これを防ぐには、技術的なフィルタリングだけでなく、構造そのものを変えなければならない。 Non-Human Identity（NHI）の管理や自動化推進の観点でも示唆がある。AIエージェントが外部に向けてアクションを起こす際のガバナンス——何を送信してよいか、品質チェックはどこが担うか——は、セキュリティ報告に限らず普遍的な課題だ。「AIが動ける仕組みを作る」と同時に「AIの出力を人間が検証するゲートをどこに置くか」を設計に組み込まなければ、似たような問題が別の文脈でも繰り返される。 バグバウンティというエコシステム全体が、AI時代の新しい設計に迫られているということだろう。Tursoの撤退を「AIに負けた」と見るのではなく、「次の仕組みを作るためのデータポイント」として業界が学ぶ機会にしてほしい。 出典: この記事は Turso retires bug bounty program because most “CRITICAL” issues are just AI slop の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、ブラウザ「Microsoft Edge」が内部メモリ上にパスワードを平文（暗号化されていない状態）で保持していた問題を公式に認め、修正を最優先課題として対応中であることを発表した。 メモリ上の平文パスワードとはどういう問題か 「平文でメモリに保存」とは、Edgeのプロセスが動作中にパスワードを暗号化せずRAM上に展開していた状態を指す。通常、認証情報はメモリ上でも暗号化された状態で扱うのがセキュリティのベストプラクティスであり、使用後は即座にメモリをゼロクリアすることが推奨されている。 この状態が続くと、以下のような攻撃シナリオが現実的なリスクになる。 メモリダンプ攻撃: ローカル管理者権限や特権プロセスからEdgeのメモリダンプを取得することで、保存済みパスワードが丸ごと読み取れる 悪意あるソフトウェアによる窃取: マルウェアがEDRをすり抜けてプロセスメモリを直接スキャンした場合に認証情報が流出するリスクがある クラッシュダンプへの混入: アプリケーションがクラッシュした際に生成されるダンプファイルにパスワードが含まれ、ダンプを回収できた攻撃者に悪用される可能性がある 実際のところ、この問題は以前からセキュリティ研究者の間で指摘されていた。Microsoftが正式に認め、優先修正として動いた意義は決して小さくない。 修正の方向性と技術的対処 Microsoftは具体的な実装手法を公開していないが、一般的な対処としては以下が考えられる。 Windows Data Protection API（DPAPI）によるメモリ上の暗号化: WindowsがネイティブにサポートするAPIで、ユーザーコンテキストに紐付いた鍵でメモリ上のデータを保護できる 使用後の即時ゼロクリア: パスワード入力や自動入力後にメモリ領域を即座にクリアし、平文データが残存しないようにする SecureString相当の管理: .NETではSecureStringという仕組みがあり、同様のアプローチをEdgeのC++実装に取り込む選択肢もある 修正版はEdgeの通常アップデートサイクルで配信される見込みだ。 実務への影響 — エンタープライズ担当者が今すぐやること アップデート管理の見直し EdgeはMicrosoft Updateを通じて自動更新されるが、グループポリシーや Intune でバージョンを固定している環境では手動対応が必要になる。修正バージョンがリリースされた後、以下を確認すること。 Intuneのデバイスコンプライアンスポリシー: 最低限必要なEdgeバージョンを条件付きアクセスのコンプライアンス要件に組み込む 古いEdgeバージョンの棚卸し: MicrosoftEdge/Update/ レジストリや Intune レポートで組織内のバージョン分布を把握する ASR（Attack Surface Reduction）ルールの活用: Microsoft Defender for Endpointの Block credential stealing from the Windows local security authority subsystem などのルールを有効化し、メモリベースの資格情報窃取を多層防御する Edgeパスワードマネージャーの利用状況を把握せよ 今回の問題はEdge組み込みのパスワードマネージャーを使っているユーザーに直接影響する。エンタープライズ環境では「なんとなくEdgeにパスワードを保存している」社員が相当数いるはずで、IT部門がそれを把握できていないケースも多い。 今回を機に、組織内のパスワード管理ポリシーを見直す絶好の機会だ。業務用パスワードは管理者が制御できるエンタープライズ向けパスワードマネージャーに集約し、Edgeのローカル保存は禁止する方向を検討したい。グループポリシーの PasswordManagerEnabled を無効化するだけで、組み込みマネージャーへの保存を禁止できる。 筆者の見解 2026年のブラウザがパスワードをメモリ上に平文で扱っていたというのは、Microsoft Defenderや Entra ID といった幅広いセキュリティ製品群を持つ同社としては「もったいない」と感じてしまう。セキュリティへの投資をあれだけ打ち出してきた会社が、ブラウザというエンドポイントの最前線でこの実装が残っていたのは素直に惜しい。 ただし、正直に認めて修正に動いた点は評価したい。「知らなかった」「問題ない」で押し切るベンダーより、誠実な対応を選んだMicrosoftの姿勢は信頼の回復につながる。 気になるのは、この問題がいつから存在し、なぜ今まで内部で検出されなかったかという点だ。外部の研究者に指摘されるまで気づかなかったとすれば、メモリ安全性に関する内部レビューフローに改善余地があることになる。MicrosoftはこれをEdge単体の修正で終わらせず、同様の実装が他製品に残っていないかを組織横断でレビューする機会にしてほしい。 ...

Broadcomは2026年5月、macOS向け仮想化ソフトウェア「VMware Fusion Pro 26H1」をリリースした。Apple Silicon（ARM）環境でのESXiゲストOSサポートの追加、Linux系ゲストOSの互換性拡張、そして深刻なセキュリティ脆弱性の修正が今回の主な変更点だ。 ARM ESXiゲストサポートが意味すること 今回の目玉機能は、Apple Silicon Mac上でVMware ESXiをゲストOSとして動作させる「ARM ESXサポート」だ。これはvSphereやESXiを扱うインフラエンジニアにとって重大なアップデートとなる。 これまでApple SiliconのMacユーザーがESXiの検証をしようとすると、x86ベースのマシンを別途用意するか、クラウド上に環境を構築するしかなかった。ARM ESXIゲスト対応により、M1/M2/M3/M4チップを搭載したMacBook ProやMac miniの上で、直接ESXiの動作検証やラボ環境構築が可能になる。 ただし注意点がある。ARM版ESXiはIntel版と完全に同じではなく、ゲスト側のARMネイティブ対応状況やNIC・ストレージドライバーの差異が存在する。あくまで「ラボ・検証用途」として捉えるのが現実的な使い方だ。 拡充されたLinuxゲスト互換性 26H1では、Linuxゲストの互換性リストが更新された。具体的に対応が強化されたのは以下のディストリビューションだ（Fusionのリリースノートに基づく）： Ubuntu 24.04 LTS（Noble Numbat）の正式サポート強化 Debian 13（Trixie）系列の追加対応 RHEL/AlmaLinux/Rocky Linux 9.x 系の最新マイナーバージョン追従 Kubernetesやコンテナ開発用途でmacOSをメインに使いながらLinux VMを日常的に動かしているエンジニアには、アップデートの恩恵を感じやすい変更だ。 重大なセキュリティ修正 今回のリリースで特に注目すべきは「major security fix」の存在だ。BroadcomのセキュリティアドバイザリによりCVEが割り当てられている場合、VMインスタンスの隔離境界に関わるホスト側への影響（VM Escape系）の可能性もある。 Fusion Proを業務環境で使っているユーザーは、セキュリティ修正の詳細をBroadcomのリリースノートで確認し、できるだけ早期にアップデートを適用することを強く推奨する。「VMはゲストだから安全」という発想はVM Escapeの脅威を考えれば成立しない。ホストOS同様の感度でパッチ適用を習慣にしたい。 実務への影響と活用ポイント インフラ・VMwareエンジニア向け: Apple Siliconが普及した現在、開発マシンがARMアーキテクチャに移行している組織では、「Mac上でESXiをテストしたい」というニーズは確実に増えている。ARM ESXiゲスト対応はそのギャップを埋める現実的な手段になる。vSphere環境の設計検証や新機能の事前確認に活用できる。 開発者向け: Docker Desktopと比較してもVMware Fusionはネットワーク構成の自由度が高く、複数VMでのネットワークトポロジー再現が得意だ。マルチノード構成の検証や、本番に近い環境でのテストが必要な場面ではFusionが有利なシーンも多い。 IT管理者向け: Fusion Proはライセンス形態がBroadcomの再編以降に変化しており、無料化された個人利用枠と有償の商用枠が整理されている。社内への展開を検討している場合は、最新のライセンス条件を確認した上で計画を立てることを勧める。 筆者の見解 VMware FusionはmacOS上の仮想化ソリューションとして、長年の実績を持つ信頼性の高いツールだ。BroadcomによるVMware買収後、価格体系や製品ラインアップが大きく変わったことで一時は混乱もあったが、Fusion Proの継続的な機能強化は歓迎できる。 ARM ESXIゲスト対応は、Apple Siliconへの移行が進む国内のIT現場でも実用的な価値がある。ただし、VMの検証環境はあくまで「道具」であって、本番相当の構成テストは相応のハードウェアで行うという基本は変わらない。 セキュリティ修正については、多くのエンジニアが「仮想マシン環境だから」と過信しがちな点でもある。ホストとゲストの境界は完全無敵ではない。パッチ適用の優先度はホストマシンと同等に扱うべきだというのが個人的な一貫したスタンスだ。アップデートを後回しにしないこと、これに尽きる。 出典: この記事は VMware Fusion Pro 26H1 released with support for more guest OSes の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...