Tech News JP

米国の技術メディア Tom’s Guide のライター、Amanda Caswell 氏が、クラウドAIメールをやめてローカルAI処理に切り替える1週間の実験を行い、その詳細なレポートを公開した。Gmailアドレスはそのままに、AI処理をデバイス上で完結させるメールクライアント「Canary Mail」に乗り換えるという試みで、クラウドAIが日常的に収集・処理しているデータの実態が明らかになった。 なぜこの実験が注目されるのか フライト確認メールを受信すれば自動でカレンダーが更新され、スマートリプライが用意される——こうした便利な体験が成立するには、メールの内容がリモートサーバーで常時処理されていることが前提となる。AIがほぼすべてのサービスに統合された今、「どこかのサーバーで静かに処理されている」という状態が当たり前になっているが、その実態を可視化した点でCaswell氏のレポートは価値がある。 「クラウドが知っていたこと」——レビューで明らかになった実態 Tom’s Guideのレポートによると、Caswell氏が以前使用していたクラウドAIメールのデータダッシュボードを確認したところ、以下のような情報が蓄積・処理されていたという。 購買記録全般：朝のコーヒーのレシートから処方箋の薬の購入まで、カテゴリ別に分類・記録 正確な移動履歴：搭乗フライトだけでなく、Uberの領収書から移動ルートや過去の訪問都市まで 人間関係のダイナミクス：誰に最も頻繁にメールするか、どのようなトーンで話すか、特定の相手への返信速度まで Caswell氏は「単に長いメールスレッドの要約のためにデータを渡しているのではなく、自分の人生の親密な詳細をコーポレートAIモデルに学習させているのだ」と表現している。 Canary Mail——「ゼロ知識」ローカルAIメールの仕組み Caswell氏が切り替え先として選んだのは Canary Mail というプライバシー重視のメールクライアントだ。スパムフィルタリング・フィッシング検知・受信トレイ整理といったAI機能を、外部サーバーに送信せずデバイス上のローカル処理で実行するのが最大の特徴。 Gmailアドレスはそのまま利用でき、新たなメールアカウントを作成する必要もない。レポートによるとセットアップは「驚くほど簡単」だったとのことで、クラウドAIに比べてスピードや利便性が落ちることを覚悟していたCaswell氏は「予想に反して、はるかに安心感を覚えた」と述べている。 日本市場での注目点 プライバシー意識の高まり：日本でも改正個人情報保護法の施行以降、企業・個人のデータ意識は高まっており、オンデバイスAI処理という概念への注目は今後増していく可能性がある。 Canary Mailの入手性：iOS・macOS・Android・Windows向けに提供されており、日本からでもフリープランで試用可能。Google Workspace や一般の Gmail アカウントとの接続に対応している。 競合との比較：Proton Mail や Tutanota のようにサーバー側暗号化でプライバシーを守るアプローチもあるが、AIアシスタント機能をローカル処理で実現するという点では Canary Mail の方向性はユニークだ。Apple Intelligence の普及とともに、端末側AI処理の精度向上が見込まれ、この分野は今後急速に変化する可能性がある。 筆者の見解 Caswell氏のレポートが突きつけるのは「AIの便利さはデータの代償の上に成り立っている」という、シンプルだが重い事実だ。購買履歴・移動パターン・人間関係のダイナミクス——これらが外部サーバーで処理されることを「当然のコスト」として受け入れるか、オルタナティブを探すかは個人の選択だが、少なくとも「何を差し出しているか」を知った上で選択できる状態が理想だろう。 デバイスの演算能力が向上し続ける中で、「すべてをクラウドに送る」という設計が唯一の選択肢ではなくなりつつある。特にメールは、仕事もプライベートも混在する極めて個人的な情報のハブだ。そこでのAI処理をどこで行うかという選択が持つ意味は、SNSの投稿データとはわけが違う。 一方で、ローカル処理には限界もある。学習データの継続的なアップデート、マルチデバイス間の同期、クロスプラットフォームの整合性など、クラウドが解決してきた問題は依然として存在する。「全か無か」ではなく、「何をクラウドに渡し、何をデバイスに留めるか」を意識的に選択できる環境が整いつつあることを、このレポートは示している。 まず「自分のデータが今どこで処理されているか」を確認することが、AIリテラシーを高める上での第一歩になるかもしれない。 出典: この記事は I ditched cloud AI for a Week — I had no idea Gmail knew so much about me の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米メディアTom’s Guideは5月10日、ライターのジョン・ベラスコ（John Velasco）氏によるコラムを掲載し、Samsungの新型折りたたみスマートフォン「Galaxy Z Fold 8 Wide」に関するリーク情報を詳しく分析した。ベラスコ氏は多数の折りたたみスマホを実機テストしてきた経験をもとに、「折りたたみスマホの最大の課題はヒンジ部の折り目ではなく、展開時のほぼ正方形というアスペクト比にある」と主張している。 なぜこの製品が注目か ブックスタイル折りたたみスマートフォンは、展開した際のインナーディスプレイが正方形に近いアスペクト比（約1:1〜7:6前後）になることがほとんどだ。一方、一般的なコンテンツは16:9、映画なら21:9で制作されており、この乖離が「せっかく大きなスクリーンを持っているのに、映像が小さくしか表示されない」という逆説を生む。 今回の注目点は、最新のリーク情報が示す4:3というアスペクト比だ。以前の情報では16:10が有力視されていたが、より新しいリークでは4:3──iPadシリーズと同じ比率──になる可能性が示唆されている。一見地味な数値の変化だが、折りたたみスマホの実用性を根本から変えうる変更だとベラスコ氏は論じる。 海外レビューのポイント Tom’s Guideのベラスコ氏は、現行モデルの実機テストを踏まえた課題として以下を挙げている。 アプリの最適化問題 InstagramやTikTokのリール動画を正方形に近いディスプレイで表示すると、映像がトリミングされ、テキストや字幕が見切れてしまうケースが多い。この問題はGalaxy Z Fold 7やPixel 10 Pro Foldでも共通して発生しており、特定機種の問題ではなくアスペクト比に起因した構造的な課題だとベラスコ氏は指摘する。 4:3であれば、Galaxy Tab S11 Ultraなどタブレット向けにすでに最適化済みのアプリレイアウトをほぼそのまま転用できるため、アプリ開発者側の対応コストも低く、既存の資産が即座に活きると分析している。 動画視聴体験の改善 Tom’s Guideの比較画像では、Galaxy Z Fold 7とiPad Miniの同一コンテンツ表示を並べており、Z Fold 7では上下に大量の黒帯が生じているのが明確に確認できる。結果として、実際に映像が映る領域は通常のスマートフォンとほぼ変わらず「大画面の恩恵を受けられていない」とベラスコ氏は述べている。4:3への移行でこの問題は大幅に緩和されるとみている。 Galaxy Z Trifoldの教訓が背景に ベラスコ氏は、2025年末にSamsungが投入した「Galaxy Z Trifold」にも触れている。同製品は展開するとタブレットに近い使用感を実現していたが、高価格もあって市場に定着しなかった。Z Fold 8 Wideへのアスペクト比変更は、その設計思想──タブレットとしての実用性をフォームファクターに取り込む──を引き継ぎつつ、主力ラインの価格帯で実現しようとする「軌道修正」である可能性が高いと分析している。 日本市場での注目点 Galaxy Z Fold 8 Wideの日本発売・価格については、現時点で公式情報はない。ただし、Galaxy Z Fold 7は国内でもキャリアおよびSIMフリー版が展開されており、Foldシリーズ自体の日本展開は継続している。 正式発表は例年通りであれば2026年夏のSamsung Unpackedで行われる見込みで、国内向け発表は秋以降になる可能性が高い。競合製品としてはGoogle Pixel 9 Pro Fold、OPPO Find N5などが挙げられるが、4:3アスペクト比への移行はいずれも採用していない。プレミアムな折りたたみスマホを検討しているなら、今夏の発表後に比較検討するのが得策だろう。 筆者の見解 折りたたみスマートフォンはここ数年、ヒンジの耐久性向上や折り目の目立ちにくさに開発リソースが集中してきた。一方で「展開した状態での実用性」──特にアスペクト比が生む根本的なユーザー体験の問題──は後回しにされてきた感がある。 4:3への移行は「スマートフォンとタブレットの間を埋める」という折りたたみスマホ本来の価値提案に、より素直に向き合ったアプローチだといえる。タブレット向けアプリの資産がそのまま活きることは、エコシステムの観点でも合理的な選択だ。 一方で、4:3は16:9コンテンツの黒帯を完全には解消しない。映像コンテンツへの没入を最優先にするなら、より横長なフォームファクターの方が理想的であることは変わらない。「万能」はないが、「タブレットとしても自然に使えるスマートフォン」という軸でみれば、このアスペクト比の変更は単なるマイナーチェンジではなく、カテゴリの方向性を示す決断だろう。 実機が市場に出て、日本の消費者がどう評価するか。正式発表後の続報に注目したい。 関連製品リンク ...

米Tom’s GuideのAnthony Spadafora氏が2026年5月10日、Ugreen（ユーグリーン）の新フラッグシップNAS「iDX6011 Pro」のレビューを公開した。単なるストレージ拡張ではなく、ローカルLLM（大規模言語モデル）を内蔵した「ホームオフィスの私的頭脳」として評価されており、NAS市場の新たなステージを感じさせる一台だ。 なぜこの製品が注目か 従来のNASはSynologyやQNAPが長らく市場を独占してきたが、Ugreen・Minisforum・Beelinkといった新興PCメーカーの参入により競争が急速に激化している。その中でiDX6011 Proが一線を画すのは、ChatGPTなどのクラウドAIを使わずに、自分のネットワーク内でLLMを動かせるという点だ。社外秘のドキュメントや個人ファイルをAIで整理・検索したいが、クラウドには渡したくない——そのニーズへの一つの明確な答えがここにある。 主なスペック ドライブベイ: 6ベイ（前面から着脱可能） サイズ・重量: 8.3 × 13.7 × 10.2インチ、約10kg（ドライブ未搭載時） ディスプレイ: 3.71インチ縦型LCD（フロントパネル搭載） 前面ポート: Thunderbolt 4 ×2、高速USB-A、SDカードスロット ケース素材: マットアルミ合金 Thunderbolt 4を前面に2ポート搭載し、外付けHDDやSDカードから直接ファイル転送が可能な設計は実用的だ。 Tom’s Guideのレビューポイント 評価された点 Spadafora氏は「NAS市場に未来が来た」と評価している。特に高く評価されているのがローカルAIの統合だ。プライバシー重視のユーザーや企業にとってクラウド不要でLLMを運用できる意味は大きく、「ファイルストレージからマルチパーパスデバイスへの変革」とレビュー内で表現されている。 アルミ合金製ケースについても「以前テストしたDH4300 Plusのプラスチックケースから大幅なステップアップ」と称賛しており、質感・剛性の向上を評価している。前面LCDパネルや充実したフロントポートも使い勝手の向上に貢献しているようだ。 気になる点 Spadafora氏自身も「ほとんどのユーザーにはオーバースペック」と率直に認めている。重量は約10kgと大型で設置スペースを選ぶ。また、レビュー内で「Behemoth（怪物）」という表現が使われているように、価格はフラッグシップ相応の水準であり、用途に見合うかどうかはユーザーが慎重に判断すべきだ。 日本市場での注目点 2026年5月時点でiDX6011 Proの日本公式発売情報は確認できないが、Ugreen製品はAmazon.co.jpや楽天市場でも扱いが増えている。一段下の「DXP4800 Plus」（4ベイ、AI非搭載）は米国Amazonで619ドルから販売中で、日本市場への展開も期待できる。 ローカルLLM搭載NASの競合としてはQNAPの上位機種も存在するが、「誰でも使える簡便さ」においてUgreenがリードしているとのTom’s Guideの評価だ。日本ではNASをIT部門向けと捉える風潮がまだ根強いが、このような製品の普及により、ホームオフィスや小規模事業者が自前のプライベートAIを持つハードルが大幅に下がる可能性がある。 筆者の見解 ローカルLLMをNAS上で動かすというアプローチは、クラウドへの情報流出を避けたいユーザーにとって非常に理にかなっている。AI活用の本質は「自律的に動き続ける仕組みを作ること」にある。手元のNASにLLMが常駐し、ファイルの整理・検索・生成を自律的に行う環境は、その方向性と見事に重なる。 ただし、「誰でも使えるローカルAI」という訴求には慎重に構えたい。対応モデルのラインナップや実際の推論速度、セットアップの難易度については、さらなる詳細レビューを待ちたいところだ。「どのLLMが動くのか」「トークン速度はどれくらいか」といった具体的なベンチマークが揃ってはじめて、投資対効果を判断できる。 NASが「ストレージ」から「ローカルAIサーバー」へと進化しつつある流れは本物だ。一般ユーザーが躊躇なく手を出せるタイミングはまだ先かもしれないが、先を見据えたホームオフィス環境の構築を考えるなら、このカテゴリは今後も目が離せない。 関連製品リンク UGREEN NASync iDX6011 6-Bay 64GB Desktop NAS UGREEN NAS DXP4800 Plus 4-Bay Desktop NAS ...

生成AIの競争軸が、「どのモデルが賢いか」から「どれだけのコンピューティングリソースを確保できるか」へと急速にシフトしている。Anthropicが5月6日に発表したSpaceXとの大型インフラ契約は、そのトレンドを象徴する出来事だ。 Colossus 1の規模——22万GPU・300MWとは何を意味するか テネシー州メンフィスに設置されたColossus 1データセンターは、NVIDIA製プロセッサを22万基以上収容する大規模施設だ。Anthropicはここから300メガワット（MW）もの電力容量を確保する。300MWといえば、一般家庭（米国基準）で30万世帯以上をまかなえる電力量だ。しかも、この計算リソースが「1ヶ月以内」に利用可能になるという。計画立案から実装までのスピード感も、この契約の注目点のひとつだろう。 この増強をもとに、AnthropicはClaude ProおよびClaude Maxの有料サブスクライバー向けサービスを大幅改善すると発表した。開発者向けツールのレートリミットを2倍に引き上げ、ピーク時間帯の使用制限を撤廃。上位モデルへのリクエスト量も大幅に増加する。インフラの拡充がそのままエンドユーザー体験の向上に直結するわかりやすい例だ。 「ドリーミング」機能——セッションを超えて自律的に動くAIへ 今回の発表と同時に公開されたリサーチプレビュー機能「dreaming（ドリーミング）」も見逃せない。これは、AIシステムがセッションとセッションの合間に「過去の作業を振り返り、パターンを見つけ、ユーザーの設定ファイルやコンテキスト情報を自律的に更新する」という機能だ。あわせてエージェント管理ソフトウェアも提供され、人間の介入を最小限に抑えたタスク実行の実現を目指している。 単発の「指示→応答」ループを超えて、AIが自ら判断・記録・改善を繰り返す設計に踏み込んできた点は、エージェント活用を考える上で重要なシグナルだ。 MuskがAnthropicとビジネスをする「逆説」 業界で話題になっているのが、Elon Musk自身がOpenAIを相手取って訴訟を継続しながら、競合のAnthropicとビジネスを行っているという構図だ。MuskはX（旧Twitter）上で「Anthropicのリーダーたちと直接会い、彼らの取り組みが人類の利益になっていると確信した」と投稿している。 OpenAI訴訟の背景には、「AI安全性への真摯なコミットメントを失った」という主張がある。Musk自身が「evil detector（悪意センサー）に引っかからなかった」と表現したAnthropicへの評価は、思想的な文脈での選択という側面もある。ただ、AIインフラ争奪が「友好・敵対」の感情を超えた純粋なリソース競争に突入していることを、この「逆説的提携」は端的に示している。 なお、Anthropicは将来的にSpaceXと協力してギガワット規模の宇宙軌道上データセンターの開発も検討していると明かした。これはSpaceXのIPOの主要なドライバーのひとつでもあり、両社の関係が長期的なものになる可能性を示唆している。 実務への影響——日本のエンジニア・IT管理者にとっての意味 コンピューティング確保がサービス品質に直結する時代 日本のエンタープライズがAIをAPIで利用する際、裏側の計算リソースの厚みはレートリミット・レイテンシ・コストに直結する。今回のような大型インフラ契約が締結されれば、その恩恵はAPIを利用するすべての開発者・企業に波及する。特に「思ったより使い切れない」「ピーク時に詰まる」という経験をしている組織には、追い風となりうる。 レートリミット緩和は開発チームに即効性あり 開発者向けツールのレートリミット倍増・ピーク制限撤廃は、チーム単位でAIコーディング支援を並列利用している現場で効果がすぐに出る変化だ。スループットの壁にぶつかっていた開発フローが改善される可能性がある。 「ドリーミング」はエージェント設計に新しい選択肢をもたらす セッションをまたいで自律的に学習・記録するエージェントの実現は、継続的な業務を担わせる企業内エージェント用途に特に有望だ。日本語の品質が実務適用の条件になるが、技術的な方向性として注目しておく価値がある。 筆者の見解 AIの競争がインフラ確保戦に突入したことは、今回の契約規模が端的に示している。「賢いモデルを作る」ことと「そのモデルを世界規模で動かし続けるインフラを持つ」ことは、どちらが欠けても勝てない。Anthropicが今回確保した規模は、現行サービスの安定化に留まらず、次世代モデルのトレーニングと大規模エージェント基盤の構築を視野に入れた先行投資と見るべきだろう。 「ドリーミング」機能が示す方向性は明確だ——人間の確認・承認を繰り返し求めるのではなく、AIが自律的にループを回して仕事を前に進める設計。これが、人間の認知負荷を根本的に削減するエージェントの本来の姿だと私は考えている。単発の指示→応答を繰り返す副操縦士的な設計では、次のフェーズでは通用しなくなる。 日本のIT現場も「どのモデルを使うか」という問いから、「どのインフラ上でどんなエージェントをどう動かすか」という問いへと視点を更新する時期が来ている。特定ベンダーのサービスを使えばいいという話ではなく、自社のAI活用戦略全体をエージェント前提で設計し直す必要がある。インフラ争奪戦の余波は、クラウド上のAPIを使うだけの我々にも確実に届いてくる。 出典: この記事は SpaceX backs Anthropic with data centre deal amidst Musk’s OpenAI lawsuit の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teamsの会議録画をめぐる混乱が、ずいぶん長い間続いている。「録画を有効にしたはずなのに参加者が録画できない」「管理センターの設定を変えたのになぜ反映されない？」——こうした問い合わせは、IT管理者の間で今も後を絶たない。Microsoftはこのほど、この複雑なポリシー構造を改めて公式に説明し、あわせてTeams Premiumが提供する録画関連機能との違いを整理した。 なぜこれほど混乱するのか：「2層」の設計 Teamsの録画ポリシーが混乱を招く最大の理由は、「誰が録画できるか」という1つの問いに対して、少なくとも2つの独立した設定が絡み合っているからだ。 第1層：管理者ポリシー（Teams管理センター） テナント全体やユーザーグループ単位で録画の可否を制御する。AllowCloudRecording が True になっていなければ、そもそも誰も録画できない。これは多くの管理者が把握しているレイヤーだ。 第2層：会議オーガナイザーによる設定 管理者が録画を許可していても、会議のオーガナイザーは「誰が録画できるか」をさらに絞り込める。主な設定値は2種類だ： オーガナイザーと共同オーガナイザーのみ（デフォルト値） 全員（参加者全員が録画可能） ここが多くの管理者が見落とすポイントだ。管理者が「録画を全社に許可した」と思っていても、会議レベルでオーガナイザーのみに絞られていれば参加者は録画ボタンすら表示されない。 Teams Premiumが加わるとさらに複雑に Teams Premiumでは「インテリジェント リキャップ（Intelligent Recap）」という機能が利用できる。これは通常の録画とは完全に別の機能であり、AIによるチャプター自動生成・話者識別・アクションアイテム抽出などを含む。 管理者が見落としやすいのは、標準録画とIntelligent Recapで適用されるポリシーが異なる可能性があるという点だ。録画は許可しているがTeams Premiumライセンスを持たないユーザーにはIntelligent Recapが表示されず、「自分だけ機能が違う」という混乱を生む。今回のMicrosoftの説明は、このTeams Premiumとの境界線を改めて明確化したものでもある。 実務への影響：管理者が今すぐ確認すべきこと この問題は日本のTeams管理者にとっても他人事ではない。特に以下のシナリオで誤解が生じやすい： 「全社員が録画できる」はずなのにできない：管理者ポリシーと会議ポリシーの両方を確認する。Teams管理センターの「会議ポリシー」→「録音とトランスクリプト」セクションで WhoCanRecord の値を確認せよ Teams Premiumの一部機能しか表示されない：ライセンスのアサイン状況と、管理センターでの機能ポリシーの紐付けを確認する 外部参加者の録画可否：外部（フェデレーション）ユーザーの録画権限は別途ポリシーで制御される。デフォルトでは無効なことが多い 実務的なアドバイスとして、会議ポリシーの既定値を変更する前に、現在の設定が何を意図して設定されたものかを確認することを強く勧める。誰かが過去に「問題を回避するため」に設定を変えていることはよくある話だ。 筆者の見解 正直に言えば、Teamsの録画ポリシーはもう少し整理できたはずだ、という気持ちはある。管理者ポリシーと会議オーガナイザーポリシーが独立していること自体は理にかなっている——細かい制御ができるというのは企業向け製品として正しい設計だ。しかしUIやドキュメントがその複雑さに追いついていなかった。 「録画を有効にした＝みんな録画できる」という誤解を管理者が何年も持ち続けてきたということは、設定画面の説明が不親切だったということでもある。複雑さを売りにするのではなく、複雑さを隠しつつ高度な制御を実現するUIこそが本来の姿だろう。Teamsにはその実力が十分にあるのだから、それが正しく伝わらないのはもったいない。 今回の公式説明は遅ればせながらも歓迎したい。混乱が続いていたところに公式の整理が入ることで、現場の管理者が楽になる。こうした地道なドキュメント整備の取り組みを、Microsoftにはぜひ継続してほしい。 出典: この記事は Microsoft explains extremely confusing Teams meeting recording policy の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ファッション大手ZARAを擁するInditexグループのデータベースに不正アクセスが発生し、19万7,400人分の個人情報が流出したことが、Have I Been Pwned（HIBP）の分析により明らかになった。今回の侵害を引き起こしたのはZARA自身のシステムではなく、かつて連携していた外部技術プロバイダーだ。「自社は万全」という安心感の裏側に巨大なリスクが潜んでいたこのケースは、日本企業にとっても決して対岸の火事ではない。 何が起きたのか HIBPの分析によると、流出データには以下が含まれる。 ユニークなメールアドレス（197,400件） 購入履歴・注文ID・商品SKU 地理的ロケーション情報 サポートチケット内容（問い合わせ元マーケット含む） Inditexは「氏名・電話番号・住所・認証情報・支払い情報（クレジットカード等）は含まれていない」と説明しており、顧客の直接的な金銭被害や不正ログインリスクは限定的とみられる。ただしメールアドレスと購入履歴・サポート履歴の組み合わせは、標的型フィッシングやソーシャルエンジニアリングの材料として十分すぎる情報量だ。 攻撃の手口：Anodot認証トークンの悪用 今回の攻撃で注目すべきは侵入経路だ。犯行グループ「ShinyHunters」は、クラウドデータ監視サービスAnodotの認証トークンを不正取得し、そこからBigQueryインスタンスにアクセスして140GBのアーカイブを窃取したと主張している。 Anodotのようなデータ分析・監視ツールは、BigQueryやSnowflake、Redshiftといったデータウェアハウスと幅広く連携するため、サービスアカウントに強力な読み取り権限が付与されていることが多い。この「機械のアカウント（Non-Human Identity / NHI）」が長期間にわたって有効な認証情報を保持し続けることが、攻撃者に格好の標的を提供している。 ShinyHuntersはこの手法で数十社のデータを窃取したと述べており、Microsoft Entra・Okta・Google SSOを標的にしたビッシング（音声フィッシング）キャンペーンとの関連も指摘されている。Salesforce、Microsoft 365、Google Workspace、Slack、Zendesk、Dropboxなど、多くのSaaSサービスが連鎖的に標的にされている点は見逃せない。 「委託先リスク」という本質的な問題 Inditexが強調するように、Inditex自身のシステムは侵害されていない。しかし過去に連携していたベンダーが保持していたデータが盗まれた。これがいわゆる「サードパーティ・サプライチェーン攻撃」の典型だ。 日本企業でも同様のリスクは広く存在する。 SaaSツールに付与したサービスアカウント・APIキーの棚卸しが未実施 契約終了後もアクセス権限が残存するベンダーアカウント 監視ツール・分析ツールへの過剰な権限付与 「いつ誰が作ったかわからないトークン」の長期放置 認証情報には有効期限がないものも多く、適切にローテーション・失効処理しなければ、何年も経ってから攻撃のエントリポイントになりうる。 実務への影響：NHI管理と最小権限の徹底 今回の事例から、エンジニアやIT管理者が直ちに着手すべきポイントを整理する。 1. NHIの棚卸し サービスアカウント、APIキー、OAuthトークン、クラウドIAMロールをすべて一覧化する。特に「誰が作成したか不明なトークン」は最優先で精査する。 2. 最小権限原則の適用 データ分析・監視ツールへのアクセス権は読み取り専用に限定し、BigQueryのデータセットレベルで権限を絞る。不要なリソースへのアクセスは即時削除する。 3. 認証情報のローテーションと有効期限設定 長寿命なAPIキーを廃止し、OAuth 2.0のアクセストークンのような短期トークンに切り替える。Just-In-Time（JIT）アクセスモデルの採用も有力な選択肢だ。 4. ベンダー契約終了時のアクセス権限失効プロセスの確立 委託終了後に認証情報が残存しないよう、オフボーディング手順を文書化・自動化する。「取引終了＝即時アクセス権剥奪」が原則であるべきだ。 5. サプライチェーン全体のセキュリティ評価 主要ベンダーへのSOC 2レポート要求やセキュリティアンケート実施を定期化し、委託先のセキュリティ体制を継続的に評価する。 筆者の見解 今回のZARA侵害が示すのは、「自社のセキュリティ」だけを固めても意味がないという厳しい現実だ。Inditexはおそらく自社インフラのセキュリティに多大な投資をしていたはずだ。しかし、過去に連携していたベンダーに残存していた認証情報が、侵害のエントリポイントになった。 NHI管理は地味なタスクだが、実は業務自動化の根幹でもある。サービスアカウントやAPIトークンの管理が甘ければ、自動化推進のボトルネックになるだけでなく、セキュリティホールにもなる。「常時アクセス権の付与はリスク」という原則は、人間のアカウントだけでなく機械のアカウントにも等しく適用されなければならない。 ゼロトラストを本当に実現するには、人のIDだけでなく「アクセスするすべてのもの」をID管理の対象にする必要がある。ShinyHuntersが今回利用した手法は、まさにその盲点を正確に突いている。残念ながら多くの日本企業でも、機械アカウントの管理は後回しにされているのが現状ではないか。今回のZARAの事例を、自社のNHI棚卸しを始めるきっかけにしてほしい。 出典: この記事は Zara data breach exposed personal information of 197,000 people の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が2026年5月8日、Ivanti Endpoint Manager Mobile（EPMM）に存在する高危険度の脆弱性 CVE-2026-6973 を「悪用が確認された脆弱性リスト（KEV）」に追加し、連邦政府機関に対して日曜日深夜（日本時間2026年5月11日午後1時）までの修正を義務付けた。たった4日間という異例の短さが、この脆弱性の深刻さをよく物語っている。 CVE-2026-6973 — 何が起きているのか この脆弱性は、オンプレミス版 EPMM 12.8.0.0 以前に存在するリモートコード実行（RCE）の欠陥だ。攻撃者が管理者権限を持っている場合、対象システム上で任意のコードを実行できる。「管理者権限が前提なら大した問題ではない」と感じた人がいれば、それは危険な誤解だ。 Ivantiは「現時点では非常に限定的な悪用に留まっている」と述べているが、セキュリティ調査組織 Shadowserver の調査では、インターネットに露出した EPMM アプライアンスが800台以上存在することが確認されている。攻撃者にとっては、管理者アカウントへの侵害という初期ステップさえ踏めれば、あとは組織のエンドポイント全体を掌握できる状態だ。 修正版は 12.6.1.1、12.7.0.1、12.8.0.1 として提供されており、Ivantiは同時に管理者権限を持つアカウントを洗い出し、認証情報のローテーションも推奨している。 「管理者権限前提」は安全ではない この脆弱性の本質的な怖さは、「管理者権限があれば悪用できる」という構造にある。一見すると攻撃ハードルが高いように見えるが、現実はそう単純ではない。 Ivanti EPMMのようなMDM製品の管理者アカウントは、組織内のエンドポイント全体を掌握できる強大な権限を持っている。このアカウントが常時有効な状態で放置されているケースは決して少なくない。仮に管理者アカウントが以前の侵害——たとえば今年1月に悪用された CVE-2026-1281 や CVE-2026-1340 ——で漏洩していれば、今回の脆弱性の悪用ハードルは一気に下がる。 Ivantiは「1月に認証情報をローテーションした組織はリスクが大幅に低下している」と明言している。裏を返せば、ローテーションを後回しにした組織は今この瞬間も危険に晒されているということだ。 「オンプレ製品のみ」が示すもの 今回の脆弱性が影響するのはオンプレミス版のみで、クラウド版「Ivanti Neurons for MDM」には影響しない。この一文には、単なる注意書き以上のメッセージが含まれている。 オンプレミス製品はパッチ適用のタイミングを組織自身がコントロールできる半面、脆弱性発見から修正適用までの時間は、攻撃者に与えられた猶予でもある。クラウド型であれば、ベンダー側が迅速に対処できる部分も多い。 日本のIT現場では、コンプライアンス要件や既存システムとの統合を理由にオンプレミスMDMを維持しているケースが多い。その選択自体を否定するつもりはないが、「オンプレを選んだ以上、パッチ適用を即座に実行できる体制が常にセットになっているか」は真剣に問い直す価値がある。 実務への対応チェックリスト Ivanti EPMMを利用しているIT管理者は今すぐ以下を確認してほしい。 バージョン確認: 12.8.0.1、12.7.0.1、12.6.1.1のいずれかに更新済みか 管理者アカウントの棚卸し: Admin権限を持つアカウントをすべてリストアップ。不要なものは削除または無効化 認証情報のローテーション: 特に1月のCVE悪用後に実施していない場合は即刻対応 アクセスログの精査: 管理者権限での不審なアクセスがなかったか確認 露出面の見直し: EPMMアプライアンスが不必要にインターネットに露出していないか確認。ゼロトラストネットワークアクセス（ZTNA）による保護も検討を CISAの指令は米国連邦機関向けだが、民間企業においても「CISAが4日以内を命じた脆弱性」は最優先対応の目安として活用できる。 筆者の見解 今回の件で改めて痛感したのは、管理者権限を「常時オン」で運用することの危うさだ。 MDM製品の管理者アカウントは組織の全端末に絶大な権限を持つ。にもかかわらず、それが「必要なときだけ有効にする（Just-In-Time アクセス）」ではなく、24時間365日アクティブな状態で放置されているケースが多い。今回のような「管理者権限があれば悪用可能」という脆弱性が出るたびに、この設計の危うさが繰り返し露わになる。 「最小権限の原則」は理念としては広く知られている。だが実務でちゃんと実装できている組織は、日本においてまだ少数派だと感じる。「今動いているから大丈夫」という現状維持バイアスが、次の侵害の種を静かに育てている。 オンプレミス vs クラウドの議論は「どちらが優れているか」ではなく、「選んだ方式のリスクを自社でどれだけ管理できるか」が本質だ。オンプレを続けるなら、パッチ適用の迅速化と特権アカウント管理の厳格化は絶対条件。Shadowserverが追跡する800台超の露出アプライアンスの中に、日本の組織のものが含まれていないことを願うばかりだ。 出典: この記事は CISA gives feds four days to patch Ivanti flaw exploited as zero-day の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ企業が攻撃される——これは単なる皮肉では済まない、業界全体の信頼基盤に関わる重大な現実だ。世界53,000社以上にサイバーセキュリティ製品を提供するTrellixが、自社のソースコードリポジトリへの不正アクセスを受けたことを認めた。データ恐喝グループ「RansomHouse」が犯行を主張しており、ダークウェブのリークサイトにスクリーンショットを証拠として公開している。 Trellixとはどんな企業か Trellixは2022年に、McAfee EnterpriseとFireEyeが統合して誕生した国際的なサイバーセキュリティ企業だ。Fortune 100企業を多数顧客に持ち、185カ国・3,500名以上の従業員を擁する。その企業が攻撃されたという事実は、「セキュリティベンダーなら安全」という幻想を改めて打ち砕く出来事だ。 インシデントの経緯 Trellixは5月1日に侵害を公式確認した。声明によれば「ソースコードリポジトリの一部への不正アクセスを確認。法執行機関への通知と共にフォレンジック専門家と協力して対応中。ソースコードのリリース・配布プロセスへの影響、ならびにソースコードの悪用は現時点で確認されていない」としている。 RansomHouseの主張によると、侵害は4月17日に発生しデータが暗号化されたという。同グループはアプライアンス管理システムのスクリーンショットを恐喝ポータルに公開したが、現時点でその真正性は独立して確認されていない。 RansomHouseの脅威プロファイル RansomHouseは2022年にデータ恐喝オペレーションとして活動を開始したサイバー犯罪グループだ。当初はデータ窃取と恐喝が中心だったが、その後ツールキットを着実に高度化させている。 注目すべきは2つの独自ツールだ： 「Mario」: 2つの異なる鍵でファイルを二重暗号化する独自ツール。復号をより困難にする設計 「MrAgent」: VMware ESXiハイパーバイザー上への暗号化ツール展開を自動化するツール ESXiを標的とする点が特に危険だ。多くの企業が仮想化基盤にESXiを採用しており、ここが侵害されると複数VMが一括で暗号化・停止させられる。単一のエントリーポイントから広範な被害が生じる典型的なパターンだ。 日本との関係——ASKULも被害者 日本の読者に見過ごせない点がある。RansomHouseの最近の高プロファイル攻撃に、日本の大手EC企業アスクル（ASKUL）が含まれているのだ。このケースでは顧客情報74万件を含む大量データが窃取された。 RansomHouseは日本企業をターゲットとした実績を持つグループであり、対岸の火事として見ることはできない。 なぜセキュリティベンダーのソースコード漏洩が深刻か 一般ソフトウェアのソースコード漏洩とは次元が違う。セキュリティ製品のコードが攻撃者の手に渡ると： 検出ロジックの解析: どのように脅威を検出しているかが分かれば、検出を回避するマルウェアの開発が容易になる 脆弱性の先取り: 製品自体のバグや設計上の欠陥を事前に把握できる 正規フォーマットの悪用: 正規の署名・形式を模倣した偽装マルウェアの作成に活用される可能性がある Trellixが「悪用は確認されていない」と述べているが、その確認には構造的な限界がある。攻撃者が静かにコードを解析し、数ヶ月後の別の攻撃に活かすシナリオは排除できない。 実務への影響——IT管理者が今すぐ確認すべきこと Trellixユーザー向け 公式リリースの整合性検証（ハッシュ値・署名確認）を通常より厳格に実施する Trellixからのアドバイザリーを定期的にモニタリングし、推奨パッチを速やかに適用する 製品の異常な挙動や予期しない通信がないか監視を強化する セキュリティ体制全般の見直し VMware ESXi環境の保護強化: 管理インターフェースへのアクセス制御とネットワーク分離を今一度見直す。MrAgentのような攻撃ツールが存在する以上、ESXiへの不要な外部露出は即時排除すべきだ ソースコードリポジトリのアクセス管理: 最小権限・多要素認証・アクセスログの監査を徹底する。今回のような侵害は、リポジトリへのアクセス権が適切に管理されていれば被害を局限できた可能性がある セキュリティツールを「信頼の証」として扱わない: ゼロトラストの原則は「セキュリティ製品自体にも適用する」という意識が今まさに必要だ 筆者の見解 今回の事件で改めて突きつけられるのは、「守る側が守られていない」という厳しい現実だ。 セキュリティベンダー自身が攻撃される構図は、製品選定における「この会社なら安全だろう」という暗黙の前提を根底から揺るがす。だからといって虚無的になる必要はない。むしろ本来あるべき姿に立ち返るきっかけだと受け取りたい。 重要なのは「あらゆる組織・製品は侵害されうる」という前提でセキュリティを設計することだ。これはゼロトラストアーキテクチャが本質的に目指していることと一致する——「信頼しない、常に検証する」。この姿勢はセキュリティツールの選定や運用にも同様に当てはまる。 一つのツールへの過度な依存を排除し、ネットワーク層・認証層・認可層の多層防御を構築する。それが「今動いているから大丈夫」という危険な慢心を防ぐ唯一の道だ。 RansomHouseはASKUL、そしてTrellixを標的にした。次の標的が誰かという問いに「うちは大丈夫」と答えられる根拠を、今すぐ洗い出しておくべき時期に来ている。 出典: この記事は Trellix source code breach claimed by RansomHouse hackers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAは2026年5月、クラウドゲーミングサービス「GeForce NOW」のアルメニア地域パートナーが運営するインフラにおいてデータ漏洩が発生したことを公式に認めた。NVIDIA自身のネットワークへの直接的な影響はなかったとされているが、今回の事件が投げかける問いは単なるゲームサービスのインシデントにとどまらない。「信頼したブランドの裏側で、別の組織がデータを管理していた」という構図は、クラウドサービス全般に共通する構造的リスクとして受け止める必要がある。 何が起きたのか 2026年3月20〜26日の間、GeForce NOWのアルメニア地域オペレーター「GFN.am」が運営するシステムが不正アクセスを受け、利用者の個人情報が外部に流出した。 流出した可能性のある情報は以下のとおりだ。 氏名（Googleアカウント利用者の場合） メールアドレス 電話番号（モバイルキャリア経由で登録した場合） 生年月日 ユーザー名 2FA/TOTPの有効・無効状態 GFN.amはパスワードは流出していないと声明で説明しており、2026年3月9日以降に登録したユーザーは対象外としている。ハッカーフォーラムにこの漏洩情報を投稿した脅威アクターはShinyHuntersを名乗り、数百万件のユーザーレコードをビットコインまたはモネロで10万ドルで販売すると提示した。ただし、このアクターはShinyHuntersの模倣犯（インポスター）である可能性が高いとされており、投稿はすでに削除されている。 アライアンスパートナーモデルの構造 GeForce NOWには、NVIDIAが直接運営するケースと、地域パートナー（アライアンスパートナー）が独自に運営するケースの二形態がある。アルメニアのGFN.amはアゼルバイジャン・グルジア・カザフスタン・モルドバ・ウクライナ・ウズベキスタンにも対応しており、独立した認証システム・顧客データベース・課金プラットフォームを自社で管理している。 ユーザーから見れば「NVIDIAのサービスを使っていたはず」であっても、実際には別の組織が管理するインフラ上にデータが置かれていた、という構図になる。今回の被害はまさにそこで発生した。 実務への影響 日本のIT管理者・エンジニアにとって、今回の事件から得るべき教訓は主に二点ある。 1. サードパーティリスク評価は「書面の確認」だけでは不十分 クラウドサービスを導入する際、ベンダー本体のセキュリティ認証だけでなく、地域パートナーや下請けが管理するシステムのセキュリティ水準も評価対象に含める必要がある。SLA（サービスレベルアグリーメント）にサードパーティの管理基準を明記する条項の整備は、もはや「できれば望ましい」ではなく必須の作業だ。 2. 2FAの有効・無効状態も立派な機密情報 パスワードが流出していなくても、2FA/TOTPの有効・無効状態が漏洩すると、攻撃者にとって有用な情報になる。2FAが無効なアカウントをリスト化して標的を絞り込む用途に使われるためだ。多要素認証の設定状況自体も、保護すべき情報として扱う意識が求められる。 筆者の見解 今回の事件を「NVIDIA本体は無傷だったから大した話ではない」で終わらせてしまうのは、本質を見誤ることになる。 アライアンスパートナーモデル自体は、地域の法規制対応や低コスト展開という観点から合理的な選択だ。だが、パートナー側のセキュリティ水準がベンダー本体と乖離していた場合、そのギャップがそのままリスクになる。ユーザーはブランドを信頼して契約したにもかかわらず、実質的に別組織のセキュリティ管理下に置かれる—この非対称性が今回の問題の核心だ。 この構図はクラウドゲーミングに限らない。日本市場でも、SaaSやIaaSを「地域パートナー経由」で提供するケースは少なくない。委託先を含めたサプライチェーン全体のセキュリティ管理体制を問い直せていない組織は、想像以上に多いのではないか。 ゼロトラストの文脈でいえば、「信頼済みパートナーだから安全」という前提こそが最大の盲点になりうる。委託先も含めた全インフラを「信頼しない」前提でモニタリングする体制—これが今後のクラウド活用における基本姿勢になるだろう。「今動いているから大丈夫」は、もはや通用しない。 出典: この記事は NVIDIA confirms GeForce NOW data breach affecting Armenian users の内容をもとに、筆者の見解を加えて独自に執筆したものです。

条件付きアクセス（Conditional Access、以下CA）は、Microsoft Entra ID（旧Azure AD）が提供するゼロトラストセキュリティの中核機能だ。その中でも「準拠済みデバイスまたはハイブリッド参加デバイスを必要とする」テンプレートは、一見シンプルに見えて、適用した瞬間から想定外の問題を引き起こしやすいことで知られている。 Petri.comが指摘したのは、より本質的な問題だ。Microsoftは「ポリシー」ではなく「デフォルト値」という形で、組織のセキュリティ上の重要な判断を代わりに下している──という構造的な問題である。 「準拠済みデバイス必須」とは何か CAテンプレートの「準拠済みデバイスまたはハイブリッド参加デバイスを必要とする」とは、端的に言えば「IntuneなどのMDMで管理・コンプライアンス確認ができたデバイスからのみアクセスを許可する」というポリシーだ。 ゼロトラストの観点から見れば、これは理にかなっている。OSのパッチ状態・ディスク暗号化・ウイルス対策の有効性を確認してからリソースへのアクセスを許可する。紙の上では完璧なゼロトラストアーキテクチャだ。 「シンプル」が「複雑」に変わる瞬間 このポリシーを組織全体に適用すると、以下のようなケースで即座に問題が噴出する。 ゲストユーザー・外部パートナー 取引先のユーザーは、自社Intuneに登録されていない。当然「準拠済み」判定は不可能。ゲストアクセスが一切できなくなるケースが頻発する。 BYOD（個人所有デバイス） 国内でも増えているBYOD環境では、個人所有PCやスマートフォンはIntuneに登録されていないことが多い。登録しようとすれば、プライバシー上の問題も生じる。 自動化・サービスアカウント バッチ処理やRPA、スクリプト実行に使うサービスアカウントは、特定のデバイスから動かない場合がある。デバイスベースの条件を適用すると、既存の自動化処理が軒並み止まる。 緊急アクセス（Break Glass）アカウント 障害時に使う緊急管理アカウントは、このポリシーの例外設定を忘れると、本当に必要なときに使えなくなる。 Microsoftが「ルールブック」を書いている問題 記事が本質的に指摘しているのは、Microsoftがデフォルト設定や推奨テンプレートを通じて、組織のセキュリティポリシーを事実上「代筆」しているという構造だ。 Microsoftの推奨テンプレートは「ベストプラクティス」として提示される。IT担当者はその信頼性を前提に適用しがちだ。しかしそのテンプレートは、あらゆる組織の個別事情を考慮していない。エンタープライズのオンプレミス資産との連携、ゲストユーザーの比率、BYODポリシー、規制対応要件──これらはすべて組織ごとに異なる。 「Microsoftが推奨しているから安全」は正確ではない。「Microsoftの想定する組織に当てはまる場合に限り安全」が正確な表現だ。 実務への影響：IT管理者が今すぐ確認すべき5点 日本のエンタープライズ環境には固有の事情もある。国内の多くの大企業では、レガシーなオンプレミスADとAzure ADのハイブリッド構成が混在している。「ハイブリッド参加デバイス」の条件が正しく機能するかどうかは、ADのドメイン構成やDevice Writeback設定次第であり、一筋縄ではいかない。 以下の点を即座に確認したい。 ゲストユーザー向けの例外ポリシーが存在するか ─ ゲスト向けに別のCAポリシーを用意し、準拠済みデバイス要件を免除または緩和する設計になっているか 緊急アクセスアカウントがCAの対象外になっているか ─ Break Glassアカウントを例外グループに確実に含める サービスプリンシパル・マネージドIDへの影響確認 ─ ユーザーIDとワークロードIDのCAポリシーは別々に設計する Report-onlyモードでの事前検証 ─ いきなり適用せず、まずReport-onlyで影響範囲をシミュレーションする Named Locationsとの組み合わせ ─ 社内IPからのアクセスに条件を緩和するポリシー設計の検討 筆者の見解 条件付きアクセスはゼロトラスト実装の王道であり、「準拠済みデバイス必須」はその中でも特に効果的な制御だ。方向性としては正しい。だからこそ、中途半端な適用が危ない。 Microsoftがテンプレートを提供すること自体は歓迎する。セキュリティ上の「最低水準」を組織全体で引き上げる効果があるからだ。しかし、テンプレートはあくまで「出発点」であり「答え」ではない。 日本のエンタープライズ現場を見ていると、レガシーなセキュリティモデルと最新のゼロトラスト設定が混在した状態が多い。「Microsoft推奨テンプレートを適用したら、翌朝から数百人がTeamsに入れなくなった」という話は珍しくない。それは技術の問題ではなく、自組織のアーキテクチャを理解せずにテンプレートを信じきったことへの代償だ。 Microsoftには、テンプレートの前提条件と対象外ケースをもっと明確にドキュメント化してほしい。「このポリシーはどういう組織には適用できないか」を明示することが、本当の意味でのユーザー支援になる。Microsoftが持つ技術力とエコシステムの強さを考えれば、それは十分できるはずだ──だからこそ「もったいない」と感じる。 ゼロトラストの文脈でこのCAポリシーを使う場合、「適用する・しない」の二択ではなく、「どのユーザー・デバイス・アプリ・リスクレベルの組み合わせに適用するか」という設計思考が不可欠だ。Microsoftのテンプレートはその思考の起点として活用し、自組織の実情に合わせてカスタマイズする──これが正しい付き合い方だ。 出典: この記事は Microsoft Security Without a Rulebook: The Problem with “Require Compliant Device” の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Engadgetが2026年5月8日に報じたところによると、ソニーはTSMC（台湾積体電路製造）と日本国内で合弁会社を設立し、次世代イメージセンサーの共同製造に乗り出すことが明らかになった。拠点となるのはソニーが熊本県合志市に新たに建設した施設で、TSMCの「プロセス技術と製造の卓越性」を活用する構想だという。両社はあわせて日本政府への財政的支援も求めていると報じられている。 なぜこの提携が注目されるのか この動きの背景にあるのは、ソニーCEO・十時裕樹氏が推進する「ファブライト（fab-light）」戦略だ。製造設備への固定資産を削減し、知的財産（IP）を中心としたビジネスモデルへ転換することが狙いで、Engadgetによればブラビア（Bravia）ブランドのテレビ製造をすでにTCLへ移管済みであり、今回はその延長線上にある。 ソニーのイメージセンサーは現在、最新のiPhone・Pixel・OnePlusに採用されているほか、ニコン・富士フイルム・ライカ・DJI・Blackmagicといったカメラ・映像業界にも広く供給されている。Engadgetが「ゴールドスタンダード」と評するほど、業界のインフラとして定着している製品だ。 スタッキング技術が製造難易度を引き上げている Engadgetの記事では、イメージセンサーの製造が「スタッキング技術」の台頭により急速に複雑化していると指摘している。複数の半導体層を積層することで処理速度や画質を向上させるこの技術は、最先端プロセスを持つTSMCなしでは対応が困難になりつつある。ソニーが単独で技術競争の最前線に立ち続けるための選択として、今回の提携を位置づけることができる。 海外レビューのポイント：提携の期待とリスク Engadgetのレポートは、提携の意義とリスクを両面から評価している。 期待できる点 カメラ・車載・産業向けイメージセンサーの性能向上 TSMCの最先端プロセス技術とソニーの設計力の融合 日本国内製造拠点の強化（政府補助の期待も込みで） 懸念される点 Engadgetが指摘する最大のリスクは、TSMCがイメージセンサー製造のノウハウを直接習得することで、ニコンや富士フイルムなどソニーの顧客企業が「ソニーを経由せずにTSMCへ直接発注する」選択肢を得てしまう点だ。ソニーが自らTSMCに製造を教え込み、結果として既存顧客を失いかねないという皮肉な構図がある。 日本市場での注目点 合志市はTSMCのJASM（Japan Advanced Semiconductor Manufacturing）工場が立地する菊陽町に隣接しており、熊本地域は今や日本の半導体産業の核として急速に整備が進んでいる。日本政府は半導体産業への補助金投入を積極化しており、今回の合弁会社にも財政支援が入る公算が高い。 消費者への影響はすぐに現れるものではないが、中長期的にはiPhoneをはじめとするスマートフォンや、日本製カメラの画質向上につながる基盤投資として捉えることができる。 筆者の見解 ソニーの「ファブライト」戦略は、製造業からの単純な撤退ではなく、「製造の外部化による設計への集中」と読み解くべきだろう。設備コストをTSMCに委ねながら、センサー設計という付加価値の高い領域に経営資源を集中させる——という方向性は理にかなっている。 一方で、Engadgetが指摘するリスクは軽視できない。TSMCはすでに世界中のファブレス企業の製造を担っており、業界ノウハウの蓄積が凄まじい。イメージセンサーの製造技術がTSMCに移転されれば、将来的にはソニー抜きのバリューチェーンが形成されるシナリオも否定はできない。 問われるのは、ソニーが知財とブランドをどこまで守り続けられるかだ。TSMCとの共存関係を維持しながら設計力で差別化し続けられるなら、この戦略は長期的に機能する。自前主義にこだわって技術競争に乗り遅れるよりも、業界最強のファウンドリと組んで水準を維持する判断は現実的だ。ただし、「ファブライト」の先に何が残るのかを、ソニーは今から明確に描いておく必要がある。 出典: この記事は Sony wants TSMC’s help to make image sensors の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米Engadgetのテクノロジーライター、Steve Dent氏が2026年5月8日に公開したハンズオンレポートによると、Blackmagic Designは人気の無料カメラアプリ「Blackmagic Camera」のバージョン3.3をリリースし、Apple Watchからのリモートコントロール機能を追加した。ソロクリエイターの撮影ワークフローを大きく変える可能性がある注目のアップデートだ。 なぜBlackmagic Cameraが注目されるのか iPhoneの純正カメラアプリは高性能だが、シャッタースピードやホワイトバランスの手動調整、多彩なビデオフォーマット対応、スコープやLUT（ルックアップテーブル）といったプロ向け機能を欠く。Blackmagic CameraはVSCOやAdobeのライバルアプリが有料サブスクリプションを必要とする中、業務グレードの機能を完全無料で提供している点が最大の差別化ポイントだ。 主な機能・スペック 映像フォーマット: 10-bit ProRes 422、ProRes RAW（iPhone 17 Pro/Pro Max＋高速USB-C外付けSSD使用時）、H.264、H.265 手ブレ補正: スタンダード／シネマティック／エクストリームの3モード（撮影後に適用） スコープ: フォルスカラー、グリッド、ゼブラ、フォーカスピーキング、ヒストグラム、ステレオ音声メーター その他: オープンゲートキャプチャ（縦横同時出力対応）、スレート機能（プロジェクト情報記録） v3.3ではiOS 26.1以上でのProRes RAW撮影時の手ブレ補正サポートも追加された。旧バージョンで欠けていた機能が補完された形だ。 海外レビューのポイント：Apple Watch連携の実力 EngadgetのSteve Dent氏はiPhone 16 Pro Max（iOS 26.4）とApple Watch Series 10で実際に検証している。Blackmagic Camera 3.3をインストールするとWatch側にコンパニオンアプリが自動導入され、手首から映像モニタリング・録画の開始停止・LUT切り替えが操作できる。 レビューによると「三脚にiPhoneを固定した状態で、手首でリアルタイムプレビューを確認しながら録画を制御できた」とのこと。カメラクルーなしで一人撮影を行うVloggerにとって実用的な価値が高いと評価されている。映像品質については「ProRes 422 Logで撮影したフッテージはポストプロダクションでの色補正の自由度が非常に高い」と好評だ。 一方、Watch側の画面が小さいため確認できる情報量に限界があることも指摘されており、精細なフレーミング確認には向かない点は念頭に置く必要がある。 日本市場での注目点 Blackmagic Camera自体はApp Storeで無料配布されており、日本でもすぐに利用できる。Apple Watch連携にはiOS 26以降が必要なため、対応デバイスのOSアップデートが前提となる。 ProRes RAW撮影を目指す場合は高速USB-C外付けSSDが別途必要で、ProRes RAW自体はiPhone 17 Pro以降の専用機能となる点にも注意したい。iPhone 16 Proまでは10-bit ProRes 422が上限だ。 国内で使われているFiLMiC ProやHalideと比較すると、Blackmagic Cameraは完全無料でありながら機能面で引けを取らない。サブスクを整理したいクリエイターが改めて見直す価値がある選択肢だ。 筆者の見解 「カメラクルーがいなければ一人でなんとかするしかない」という課題は、YouTube・SNS全盛の今に限らず以前からあった。Blackmagic DesignがApple Watch連携でその答えを示したことは、完全自律ではないにしても「仕組みで代替する」という方向性として筋が通っている。 無料でここまでの機能を揃えられるのは、同社がカメラ本体やDaVinci Resolveのエコシステムへの入口として位置づけているビジネスモデルあってのことだ。使う側としてはそのモデルを素直に活用すればいい。Engadgetのレビュー結果を見る限り、映像品質・操作性ともに実用レベルに達しており、iPhoneをメインカメラとして使う動画クリエイターにとってApple Watch連携は試さない理由がないアップデートといえる。 関連製品リンク ...

ソニーが2026年5月8日の決算・経営戦略説明会において、バンダイナムコホールディングスとの生成AI共同パイロットイニシアチブを発表した。Engadgetが報じたこの動きは、エンターテインメント産業における生成AI活用の本格化を示すとともに、PlayStation事業全体のAI戦略が初めて体系的に語られた注目の場となった。 ソニー×バンダイナムコ：生成AI共同パイロットの概要 ソニーの代表執行役社長兼CEO・十時裕樹氏は、バンダイナムコホールディングスとの共同パイロットについて「スピードと一人当たりの生産性で大幅な改善が見られた」と述べた。AIを「人間の想像力を増幅させ、新たな可能性を生み出す触媒」と表現する一方、「アーティストやクリエイターの代替にはならない」と強調した。 ただしEngadgetの報道が指摘するように、この発表の内容は「かなり曖昧」であり、具体的な製品・サービスへの展開は現時点では明示されていない。バンダイナムコがゲーム企業である以上、ゲーム開発への応用が自然に想定されるが、十時氏はゲームとの直接的な関連については言及を避けた。これは生成AIがゲーム業界においてセンシティブなテーマであることを示唆している。 PlayStation開発現場へのAI活用：具体的なツールと方針 ソニー・インタラクティブエンタテインメントCEOの西野秀明氏は、PlayStation事業へのAI活用について具体的なビジョンを語った。Engadgetの報道によると、主な活用領域は以下の通りだ。 開発サイクルの短縮: PS5のファーストパーティタイトルは開発期間が一世代をまたぐケースが増加しており、AIによる効率化が急務となっている。西野氏は「より多くのクリエイターが市場に参入できる環境」をAIが実現すると語った。 Mockingbird（フェイシャルアニメーションツール）: Naughty DogやソニーのSan Diego Studioが採用済みのAIツール。パフォーマンスキャプチャ後の3Dモデルに自動でアニメーションを適用する。 ヘアアニメーション: 実際のヘアスタイルの映像をモデルに学習させ、「数百本のストランド」を再現する高精度なアニメーション生成を実現。 PSSR（PlayStation Spectral Super Resolution）: PS5 Proに搭載されているAIアップスケーリング技術。最近アップデートが実施され、多数のサードパーティ・ファーストパーティタイトルへの対応が拡充された。PS6でも主要機能として搭載されることが確実視されている。 「コンテンツ氾濫」への率直な懸念 最も注目すべきは、西野氏自身が「AIによってコンテンツの量が意味のある形で増加する」と認めた点だ。Engadgetはこれを率直に「スロップ（粗悪コンテンツ）」と表現している。西野氏はソニーのスタジオとIPが「高品質なゲームのみをリリースする方針」だと述べたが、プラットフォーム全体が大量のAI生成コンテンツで溢れるリスクは現実的に存在する。NVIDIAのDLSS 5発表時のコミュニティの強い反発が示すように、AIの「やりすぎ」に対するユーザーの目は厳しい。 日本市場での注目点 バンダイナムコホールディングスは日本企業であり、この提携は日本発の生成AI活用事例として重要な注目事例となる ソニーはPS5を含むコンソールラインアップを直近12ヶ月で2回値上げしており、日本市場での価格負担が増している。第4四半期のPS5販売台数は前年比46%減の150万台にとどまった PSSRはPS5 Pro限定機能だが、PS6への搭載が有力視されており、次世代機の購入検討時に重要な判断材料となる Mockingbird等の制作支援AIツールは現時点では内製開発向けだが、将来的に外部の開発スタジオへ提供される可能性もある 筆者の見解 ソニーとバンダイナムコのAI提携、そしてPlayStationにおけるAI活用方針は、今のゲーム業界が直面している本質的な問いを浮き彫りにしている。 「AIはクリエイターを代替しない」という言葉はよく聞く。西野氏も十時氏も同じことを述べている。方向性として正しいと思う。だがそれより重要なのは、AIをどう設計・統合するかという問題だ。 Mockingbirdのようなツールは評価できる。クリエイターが繰り返し作業から解放され、本来の創造性に集中できる設計になっているからだ。単なる自動化ではなく、人間の判断を尊重しながら負荷を削減するアプローチは、AI活用の一つの理想形に近い。 一方で、「コンテンツ量が意味のある形で増加する」という発言は、そのまま受け止める必要がある。高品質なファーストパーティタイトルを守ると言っても、プラットフォーム全体に粗悪なAI生成ゲームが溢れれば、ユーザー体験は損なわれる。ソニーにはその実力があるだけに、プラットフォームの「質的な守り」をどう設計するか、具体策を示してほしいところだ。 PSSRについては、継続的なアップデートと対応タイトルの拡充は着実な取り組みとして評価したい。AIアップスケーリングの進化をユーザー体験と結びつける努力を地道に続けることが、次世代機への信頼につながる。生成AIの「量的拡大」より「質的深化」を選べるかどうか――それがソニーのAI戦略の真価を問う試金石になるだろう。 関連製品リンク PlayStation 5 Pro(CFI-7000B01) ゲーム機本体 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Sony and Bandai get into bed with generative AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

1984年に任天堂へ入社し、世界中で愛される名作タイトルを数多く手がけてきたゲームデザイナーの手塚卓志氏が、40年以上のキャリアに幕を閉じることが明らかになった。米メディアEngadgetが2026年5月8日に報じた。任天堂の四半期決算に合わせて公表された人事変更の公式文書により退職が確認されており、現在は同社のエグゼクティブ・オフィサーを務めていた。 なぜこのニュースが注目されるのか 手塚氏の退職は、単一クリエイターの引退にとどまらず、任天堂における「創業期クリエイター世代の交代」という大きな潮流を象徴するできごとだ。宮本茂氏（73歳）、近藤浩治氏、青沼英二氏など、同社を長年支えてきたレジェンドたちが軒並み60代中盤を迎えており、任天堂がどのようにノウハウと文化を次世代へ引き継ぐかが業界全体の関心事となっている。 手塚卓志氏のキャリアと代表作 Engadgetの報道によると、手塚氏は1984年にパートタイムとして任天堂に入社し、当初は『パンチアウト!!』の開発に携わった。当時はゲームをあまりやり込んでいなかったといい、入社時点では『パックマン』すら知らなかったとされる。しかしその後すぐに宮本茂氏のもとで『スーパーマリオブラザーズ』（NES）の開発に参加し、二人の長年にわたる創造的パートナーシップが始まった。 手塚氏が監督・共同開発に携わった主な作品は以下の通りだ。 『スーパーマリオブラザーズ』（1985年） 『ゼルダの伝説』（1986年）— 監督・脚本 『スーパーマリオブラザーズ3』（1988年）— 監督 『スーパーマリオワールド』（1990年）— 監督 『ゼルダの伝説 神々のトライフォース』（1991年）— 監督 『ヨッシーアイランド』（1995年）— 監督 『スーパーマリオ64』（1996年）— アシスタントディレクター 『スーパーマリオブラザーズ ワンダー』（2023年）および2026年DLC「ベラベルパーク あつまれ！」 『プリンセスピーチ Showtime!』（2024年） 『マリオ＆ルイージRPG ブラザーシップ！』（2024年） 2018年には取締役に就任。現在65歳で、退職後に何らかの形で任天堂と関わるかどうかは現時点では不明だとEngadgetは伝えている。 日本市場での注目点 手塚氏が携わった作品群はいずれも国内外で何千万本もの販売を記録した歴史的タイトルばかりだ。直近では2023年の『スーパーマリオブラザーズ ワンダー』や2024年の複数タイトルに名を連ねており、現役クリエイターとしての存在感は退職直前まで続いていた。 国内ゲームファンとしては、今後の任天堂タイトルにおいて手塚氏の関与がなくなることが作品の質や方向性にどう影響するかが気になるところだろう。任天堂はNintendo Switch 2の国内発売（2025年）に向けた新ラインアップを展開中であり、次世代クリエイターが旗手としてどのような作品を打ち出すかが注目される。 筆者の見解 手塚氏のような長年のクリエイターが持つ「暗黙知」の量と深さを考えると、この退職は任天堂にとって決して軽い話ではない。宮本茂氏をはじめ創業世代が一線を退いていく流れの中で、任天堂がどのような形で「ゲームデザインの哲学」を組織として継承するかは、経営戦略上の最重要課題の一つだ。 日本の多くのソフトウェア企業と同様、任天堂でも「人に依存したノウハウ」を仕組みとして次世代へ引き継ぐことは容易ではない。しかし任天堂はこれまでも時代ごとに新しい才能を世に送り出してきた。Nintendo Switch 2世代でもコンテンツのクオリティを維持できれば、世代交代は成功したと評価できるだろう。 手塚氏の40年超にわたる功績に最大限の敬意を表しつつ、任天堂の次章がどのように描かれるかを注目して見守りたい。 関連製品リンク スーパーマリオブラザーズ ワンダー -Switch プリンセスピーチ Showtime! -Switch マリオ&ルイージRPG ブラザーシップ! - Switch 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Legendary Nintendo designer Takashi Tezuka is seemingly retiring from the company の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AI開発プラットフォームのHugging Faceで、OpenAIの公式プロジェクトに偽装した悪意あるリポジトリが約24万4,000回のダウンロードを記録しながらトレンド1位に到達し、Windowsユーザーへ情報窃取マルウェアを配布していた事実が判明した。npmやPyPIで何年も繰り返されてきたサプライチェーン攻撃が、いよいよAIモデルの世界でも本格化している。 偽装の手口――「本物そっくり」のリポジトリ セキュリティ企業HiddenLayerの研究者が2026年5月7日に発見したのは、Open-OSS/privacy-filterという名称のリポジトリだ。OpenAIが公開している正規の「Privacy Filter」プロジェクトをタイポスクワッティング（類似名称による偽装）し、モデルカードの説明文まで原文をほぼそのままコピーして本物らしさを演出していた。 問題のloader.pyは、AIモデルを読み込むための正規コードに見せかけながら、裏ではSSL検証を無効化し、Base64エンコードされたURLを復号して外部サーバーに接続。PowerShellコマンドを含むJSONペイロードを取得・実行する仕組みが組み込まれていた。 攻撃チェーンと窃取対象 実際の攻撃の流れを整理すると次のようになる。 loader.pyが不可視ウィンドウでPowerShellを実行 バッチファイル（start.bat）をダウンロードして特権昇格を実行 最終ペイロード（sefirah）を取得し、Microsoft Defenderの除外リストに自動登録 Rust実装のインフォスティーラーが起動 マルウェアが狙う情報は幅広い。ChromiumやGeckoベースのブラウザに保存されたパスワード・Cookie・セッショントークン、Discordトークンとローカルデータベース、暗号資産ウォレットとシードフレーズ、SSH・FTP・VPN設定ファイル（FileZillaを含む）、マルチモニターのスクリーンショットなど、実務端末に存在しうる重要資産がほぼ網羅されている。盗み取ったデータはrecargapopular[.]comに送信される。 さらにこのマルウェアは、VM検出・サンドボックス検出・デバッガー検出など複数のアンチ分析機能を内蔵しており、自動解析システムによる検知を積極的に回避する設計だ。 「244,000 downloads」の重さ HiddenLayerは、244,000というダウンロード数が人為的に水増しされている可能性を指摘している。リポジトリに「いいね」した667アカウントの多くも自動生成と見られる。それでも、Hugging Faceのトレンド1位に到達したという事実は、「人気があるから安全」というソーシャルシグナルへの信頼がいかに容易に操作できるかを示している。 また調査の過程で、同じローダーインフラを使用する別リポジトリも複数発見された。npmエコシステムでWinOS 4.0インプラントを配布するタイポスクワッティングキャンペーンとの重複も確認されており、組織的な攻撃グループが複数の攻撃ベクターを並行展開している可能性がある。 実務への影響 開発者・MLエンジニア向け リポジトリ名・組織名の差異を確認する習慣を: OpenAIではなくOpen-OSSという微妙な違いを見逃さない 実行前にソースコードを必ず読む: AIモデルのサンプルコードであっても、loader.pyの類は実行前に内容を確認する 未知のリポジトリはサンドボックスで検証: Hugging Faceから取得したモデルは隔離環境で動作確認してから本番利用へ IT管理者・セキュリティ担当者向け Microsoft Defender除外リスト変更をアラート対象に: 今回の攻撃はDefenderの除外機能を悪用する。除外リスト変更イベント（Event ID 5007等）の監視を整備する Hugging FaceへのアクセスをEndpoint DLPでポリシー化: 業務端末からの無制限アクセスを見直し、承認済みリポジトリのみに絞る NHI（Non-Human Identity）のシークレットを定期ローテーション: SSH鍵やFTPパスワードが漏洩した際の被害を最小化するため、シークレットローテーションの自動化を整備する 感染が疑われる場合は、端末の再イメージング、全保存認証情報のローテーション、暗号資産ウォレットとシードフレーズの差し替え、ブラウザセッションの無効化が必要だ。 筆者の見解 正直なところ、セキュリティ系は得意なジャンルではない。それでも今回の件は技術的に非常に興味深いと感じた。 AIツールが「インフラ化」しつつある今、Hugging FaceはnpmやPyPIと同等のサプライチェーンリスクを持つプラットフォームになりつつある。npmのタイポスクワッティング事件は何年も前から繰り返されてきたが、同じ問題がAIモデルの世界でも起きるのは時間の問題だった。そしてその「時間」が来た。 注目したいのは攻撃の精巧さだ。Pythonファイルに正規のAI処理コードを混在させてサンドボックスをすり抜け、PowerShellを不可視ウィンドウで実行してDefender除外まで自動設定する。これだけの手順を踏んでいることからも、標的が開発者やMLエンジニアという「権限を持ったユーザー」であることは明白だ。彼らの端末には、ビジネスに直結する認証情報が集中している。 「トレンド入りしているから安全」「多くの人がダウンロードしているから大丈夫」という心理的バイアスは今や危険だ。エンゲージメント指標が簡単に操作できる時代において、ソーシャルシグナルは信頼の根拠にならない。AIエコシステムを活用する組織には、コードを読むという当たり前の習慣をAIモデルにも適用することが、今すぐ求められている。 出典: この記事は Fake OpenAI repository on Hugging Face pushes infostealer malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

人気ダウンロードマネージャー「JDownloader」の公式Webサイトが攻撃者によって改ざんされ、2026年5月6日から7日の間に同サイトからWindowsまたはLinux向けインストーラーをダウンロードしたユーザーは、マルウェアに感染した可能性がある。開発チームは事態を確認後、サイトを一時オフラインにして調査を進めた。JDownloaderは10年以上の歴史を持ち、世界中で数百万人が利用するフリーのダウンロード管理ツールだ。その公式サイトが狙われたという事実は、ソフトウェアのダウンロードというごく日常的な行為にひそむリスクを改めて浮き彫りにする。 何が起きたのか 攻撃者はJDownloaderの公式サイトが利用しているCMS（コンテンツ管理システム）の未パッチの脆弱性を悪用。認証なしにWebサイトのアクセス制御リスト（ACL）やコンテンツを変更できる状態を作り出し、正規のダウンロードリンクを悪意のある第三者のペイロードへのリンクに差し替えた。 開発チームの報告によれば、攻撃者がアクセスできたのはCMSが管理するWebコンテンツの範囲のみで、サーバーのファイルシステムやOS層への侵入は確認されていない。いわゆる「サプライチェーン攻撃」と呼ばれる手法だが、ソースコードや開発パイプラインへの侵害ではなく、配布インフラ（公式Webサイト）を狙った点が今回の特徴だ。 攻撃の手口——配布インフラへの直接介入 Windowsの「Download Alternative Installer」リンクとLinuxのシェルインストーラーリンクが書き換えられた。一方で、アプリ内アップデート、macOSダウンロード、Flatpak、Winget、Snap、そして主要なJDownloader JARパッケージは改ざんの対象外だった。 この選択は攻撃者が意図的に狙いを絞ったことを示唆している。最も利用されやすいWebサイト上の「インストーラー」リンクだけを書き換え、検出リスクが高いパッケージマネージャー経由の配布やアプリ内更新は触らなかった。検出回避を意識した巧妙な設計と言える。 配布されたマルウェアの正体 セキュリティ研究者のThomas Klemencが分析した結果、Windows向け悪意のある実行ファイルは「ローダー（loader）」として機能し、高度に難読化されたPythonベースのRAT（Remote Access Trojan、遠隔操作ツール）を展開することが判明した。 このPythonペイロードはモジュール型のボット＆RATフレームワークとして動作し、C2（コマンド＆コントロール）サーバーから送り込まれたPythonコードを実行できる設計になっている。感染後、攻撃者が任意のコードを被害者のマシンで実行できる状態が作られてしまうわけだ。 Linux向けには、正規のシェルインストーラーに悪意のあるコードが注入され、SVGファイルに偽装したアーカイブを外部サーバーからダウンロードする仕組みが仕込まれていた。 影響範囲と自己確認の方法 5月6日または7日にJDownloaderのインストーラーをダウンロードした場合は、以下の手順で正規品かどうかを確認できる。 インストーラーファイルを右クリックし「プロパティ」を開く 「デジタル署名」タブを確認する 署名者が 「AppWork GmbH」 であれば正規品 署名なし、または別の名前（「Zipline LLC」「The Water Team」など）が表示される場合は偽物 一人のユーザーがMicrosoft Defenderによる検出を報告したことが今回の発覚の発端となった。エンドポイント保護が実際に機能した事例として記録しておく価値がある。 日本のIT現場への影響 JDownloaderは動画配信サイトや各種ファイルホスティングサービスからのダウンロードを自動化できるツールとして、日本でもコンテンツクリエイターやIT担当者に幅広く使われている。 今回のインシデントが示すのは、「公式サイトからダウンロードしたから安心」という前提が崩れてしまうリスクだ。企業のIT管理者として明日から取れるアクションを整理する。 デジタル署名の検証を習慣化する インストーラーのデジタル署名確認は数秒でできる。導入前の確認を社内ルールに組み込んでほしい。 パッケージマネージャー経由の調達を優先する WingetやChocolatey（Windows）、AptやSnap（Linux）など、パッケージマネージャーを経由したインストールは今回の攻撃の対象外だった。エンドポイントへのソフトウェア配布はパッケージマネージャーを通じて一元管理する体制を検討したい。 エンドポイント保護の有効性を再確認する Microsoft Defenderが今回の偽インストーラーを検出できたことは重要だ。定義ファイルの更新状況と検出・対応設定を定期的に確認してほしい。 筆者の見解 今回の事件で注目すべきは、攻撃者がソースコードやビルドパイプラインには手を付けず、WebサイトのCMS脆弱性だけで配布インフラを乗っ取ったという点だ。技術的には「小さな侵入」だが、影響はサプライチェーン攻撃と同等の被害をもたらしうる。 開発チームがCMSの脆弱性を未パッチのまま放置していたことは、オープンソースプロジェクトが抱える共通の課題を映し出している。メンテナンスリソースが限られる中で、Webサイト運用のセキュリティまで手が回らないケースは珍しくない。それ自体は理解できる事情だが、だからこそ利用者側が「配布元を盲信しない」姿勢を持つことが大切になる。 ゼロトラストの観点から言えば、「公式サイト」という権威を自動的に信頼するモデルは根本から見直す必要がある。ダウンロードしたバイナリを信頼するかどうかの判断は、配布元のブランドではなく、デジタル署名・ハッシュ値・取得経路に基づくべきだ。この教訓はJDownloaderに限らず、すべてのソフトウェア調達プロセスに当てはまる。 PythonベースのRATがモジュール型で任意のコードを実行できる設計になっている点も技術的に興味深い。初期感染ペイロードを軽量に保てるため検出が難しく、感染後の攻撃者の自由度が非常に高い。このアーキテクチャのマルウェアは今後も増えていくと見ている。 「信頼は稼ぐものであり、付与するものではない」——この原則をソフトウェア調達にも適用する時代が来ている。 出典: この記事は JDownloader site hacked to replace installers with Python RAT malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Metaが、InstagramのDM（ダイレクトメッセージ）に適用していたエンドツーエンド暗号化（E2EE）を廃止した。導入からわずか数年での撤回は、「プライバシー優先のSNS」を標榜してきた同社の姿勢を根本から揺さぶるものだ。 E2EEとは何か、なぜ重要だったのか エンドツーエンド暗号化とは、送受信者だけがメッセージを復号できる仕組みだ。通信を中継するサーバー上でも内容は暗号化されたままであるため、仮にサーバーが侵害されても、あるいはプラットフォーム企業が政府機関から情報開示を求められても、メッセージの中身は原則として読み出せない。 MetaはWhatsAppでのE2EEをベースに、段階的にInstagramのDMへも同機能を展開。2023年末にはデフォルト有効化を完了させ、プライバシー強化をアピールしていた。それがわずか数年で廃止されることになった。 なぜ廃止されたのか 公式な説明は現時点で詳細が出ていないが、背景として考えられる要因はいくつかある。 規制当局からの圧力: EUや英国など各国政府は長年、E2EEが児童性的虐待コンテンツ（CSAM）の検出を困難にするとして批判してきた。英国のオンライン安全法（Online Safety Act）はその代表例で、プラットフォームにコンテンツスキャン義務を課す方向で立法が進んでいる。 コンテンツモデレーションとの根本的なトレードオフ: E2EEされたメッセージは、AIによるスパム・詐欺・ハラスメントの検出が事実上できなくなる。プラットフォームの安全維持とユーザーのプライバシー保護は、本質的に緊張関係にある。 政治・ビジネス的判断: 大手テック企業が規制当局との対立を避けるべく方針を軟化させる動きが、近年目立つようになっている。E2EE廃止もその文脈で捉えることができる。 実務への影響 個人ユーザーへの対応 InstagramのDMを「プライベートな連絡手段」として使っていたユーザーは、メッセージ内容がMetaのサーバー上で読めるようになったと認識する必要がある。機微な情報のやり取りにInstagramを使っていたなら、現時点でE2EEを維持しているSignalやWhatsApp（同じMeta傘下ではあるが）への切り替えを検討すべきだ。 企業・IT管理者が今すべきこと 業務での連絡ツールとしてInstagram DMを直接使うケースは少ないかもしれないが、従業員が個人スマートフォンで顧客や取引先とやり取りをしているシナリオは意外に多い。「業務に関わるやり取りがE2EEなしのコンシューマーSNSに流れていないか」を棚卸しするよい機会だ。 従業員教育の観点でも、「SNSのDMは本質的に安全ではない」という前提を改めて周知することが重要になる。利便性の高いコンシューマーアプリをそのまま業務利用するリスクを、今一度確認してほしい。 ゼロトラストの観点から 「通信経路が安全かどうかに依存したセキュリティ設計」は、今回のような方針転換の前で簡単に崩れる。「プラットフォームが提供する暗号化に頼る」のではなく、「どの通信路を使っても機密情報は別途保護されている」という設計思想——これがゼロトラストの本質であり、今回の件はその重要性を改めて示している。 筆者の見解 正直、この件でMetaに驚きはない。 E2EEの廃止は技術的な後退というより、ビジネス・規制・政治的判断の結果だ。「ユーザーのプライバシーを守る」と宣言した機能であっても、状況が変われば方針転換できる——これはMetaに限った話ではなく、プラットフォーム全体に共通するリスクだ。 気になるのは、ユーザー側の「慣れ」である。E2EEが廃止されても、多くの人がそのままInstagramを使い続けるだろう。利便性の前ではプライバシーへの意識がすぐに霞んでしまう。そしてプラットフォーム側はそれを知っている。 セキュリティとプライバシーの問題は、技術的な解決策だけでは永続しない。提供企業の商業的利益と、ユーザーの安全・プライバシーが常に一致するとは限らない。「このプラットフォームはE2EEを維持する経済的インセンティブがあるか」まで考えることが、今後はますます重要になる。 通信手段の選択は、技術仕様を読むだけでなく、提供企業のビジネスモデルそのものと向き合う問いでもある。今回の件は、その現実をはっきりと示した。 出典: この記事は Meta has killed end-to-end encryption on Instagram の内容をもとに、筆者の見解を加えて独自に執筆したものです。

職場でのAIチャットが「筒抜け」になる時代が、静かに始まっている。Microsoftがセキュリティ・コンプライアンスチームに対し、従業員のAIプロンプトとその応答を平文（プレーンテキスト）で閲覧できる機能を提供していることが明らかになった。企業のAIガバナンス整備が急務となる中、このニュースは日本のIT現場にとっても対岸の火事では済まない。 何が変わったのか Microsoftは企業向けコンプライアンス基盤であるMicrosoft Purviewを通じて、IT管理者やセキュリティ担当者がCopilot for Microsoft 365などのAIツールとのやり取りを監視できる仕組みを提供している。対象となるのはチャット形式で送受信されたプロンプトとレスポンスで、暗号化された状態ではなく平文として管理者側のダッシュボードに表示される。 この機能はeDiscovery（電子証拠開示）やCommunication Compliance（コミュニケーションコンプライアンス）の文脈で実装されており、法的対応・内部統制・情報漏洩防止といった用途が想定されている。つまり「AIに投げた質問も業務コミュニケーションの一部」として扱われるということだ。 企業コンプライアンスの観点からは「正しい方向」 AIの企業利用が急拡大する中で、「従業員が何をAIに聞いているか分からない」という状況は、コンプライアンス部門にとって悪夢に等しい。機密情報の外部AI流出、インサイダー脅威、不適切なコンテンツの生成——こうしたリスクに対して、ログと監視の仕組みを持つことは企業統治の基本だ。 Microsoftがこの機能をMicrosoft Purviewという既存のコンプライアンス基盤に統合したのは、理に適っている。メールや Teams チャットと同じ枠組みでAI会話も管理できるようにすることで、IT管理者は新たなツールを覚えずに対応できる。統合プラットフォームの強みが活きる場面だ。 「プライバシーの問題」を直視する 一方で、従業員の立場から見れば話は単純ではない。AIアシスタントに相談する内容は、通常のメールやチャットよりも踏み込んだものになりがちだ。業務上の悩み、上司への愚痴、まだ確定していないアイデアのブレインストーミング——こういった「思考の途中」を管理者が平文で見られるとなれば、従業員の心理的安全性に影響が出る可能性がある。 GDPRや個人情報保護法の観点からも、この種の監視データの取り扱いは慎重に設計しなければならない。「できる」と「すべき」は別の話だ。 実務への影響——日本のIT管理者が今すぐやるべきこと 1. ポリシーの明文化を急げ まず社内AIツールの利用規定に「会話ログは監査目的で管理者が閲覧しうる」旨を明記し、従業員へ周知する。欧米では就業規則への記載が法的要件になるケースが増えており、日本でも先手を打つべきだ。 2. 監視の「目的限定」を設計に組み込む 技術的に「見られる」状態であっても、「何のために見るか」を組織として定義しておかなければ、プライバシーリスクが生じる。eDiscovery目的に限定するのか、日常的なコンプライアンス監視まで行うのか、スコープを明確にした上でアクセス権を絞るべきだ。 3. Microsoft Purview の設定を棚卸しする すでにPurviewを導入済みの組織であれば、Communication Compliance ポリシーにAI会話が対象として含まれているかを確認する。意図せず広範な監視が走っている可能性もあるし、逆にガバナンス上の穴になっている可能性もある。 4. ユーザー教育も並行して 「禁止する」のではなく「安全に使える環境を整える」アプローチを取るべきだ。AIに入力してはいけない情報の例示、社外AI利用時との違いなどを分かりやすく伝えることで、従業員は安心して業務効率を上げられる。 筆者の見解 AI会話の監視機能そのものは、セキュリティ・コンプライアンスの観点から見れば必要な機能だと思う。メールが監査対象になるのと同じロジックで、AIとのやり取りも業務記録として扱われるのは自然な流れだ。 ただ、気になるのはこの機能が「使えるようになった」という事実が、多くの日本企業でほとんど認識されていない点だ。管理者側も「そんな機能があったのか」と知らずに放置しているケースが多いだろうし、従業員側は「AIに話しかけた内容は誰にも見えていない」と思い込んでいるかもしれない。 Microsoftがこういった機能を整備してくれているのは、企業統治の観点から本来ありがたいことだ。だからこそ、その強力な機能を適切に運用する責任は組織側にある。「ツールがある」だけでは半分しか意味がない。使い方のポリシーを整備し、従業員に透明性を持って伝える——その部分を丁寧にやり切れる組織が、AI時代のガバナンスで一歩先に行ける。 技術的な仕組みを入れることより、人が信頼して使える環境を設計することの方が、実は何倍も難しい。それが今、日本のIT現場に突きつけられている本当の課題だと思っている。 出典: この記事は Microsoft is allowing IT admins to monitor your AI prompts and responses in plaintext の内容をもとに、筆者の見解を加えて独自に執筆したものです。

クロスプラットフォームC++/QML開発のデファクトスタンダードIDEであるQt Creatorが、メジャーバージョン20のベータ版をリリースした。AI統合の強化、集中作業向けの「Zen Mode」など実用的な改善が詰め込まれており、Qt開発者にとって見逃せないアップデートとなっている。 AI補完が実用フェーズへ Qt Creator 20 BetaでもっともインパクトがあるのがAIサポートの強化だ。従来からGitHub CopilotなどのAIコード補完を接続できる仕組みは持っていたが、今回のアップデートでは補完の精度と応答速度が大幅に向上し、Qt固有のAPI・シグナル/スロット構文・QMLのプロパティバインディングといった「Qtらしい書き方」をAIがより正確に提案できるようになっている。 C++はAIコーディング支援と相性が難しい言語の一つとされてきた。テンプレートの多用、マクロ展開、ヘッダ/実装分離といった構造上、コンテキスト理解が複雑になりやすいからだ。Qt Creatorはクランスタティック解析やClangdとの深い統合を活かし、AIが「正しいコンテキストで補完を出せる環境」を整えている点がポイントだ。 Zen Mode——「割り込みゼロ」の開発体験 新機能として注目されるのがZen Modeだ。VS CodeやJetBrains IDEでも採用が進む「集中モード」の思想をQt Creatorに持ち込んだ形で、ツールバー・サイドバー・ステータスバーなどを一括非表示にし、エディタだけがモニター全体に広がるフルスクリーン環境を一発で呼び出せる。 これは小さな機能に見えて、実は開発者の認知負荷軽減において効果が高い。通知やパネルが目に入るたびに注意が分散する問題は実験的にも検証されており、Zen Modeはその対策として理にかなっている。組み込み・自動車・産業機器向けのQt開発では「1画面で長時間集中」するシーンが多く、特に有効活用できる場面が多そうだ。 その他の主な改善点 CMakeインテグレーションのさらなる洗練。CMake 3.xとの連携がよりスムーズになり、大規模プロジェクトでのビルド設定変更が軽快に QMLデバッガの強化。QMLはJavaScriptベースのため動的型付けによるデバッグの難しさがあるが、今バージョンで変数ウォッチと状態検査が改善 Language Server Protocol（LSP）対応の拡充。Rustなど周辺言語のLSP連携が改善され、Qtプロジェクト内でRust製ライブラリを扱うケースにも対応しやすくなった UIはダークモードとライトモードの切替品質が向上し、HiDPI環境での表示崩れも修正されている 実務への影響——日本のエンジニアにとっての意味 日本のQt開発案件は産業機器・医療機器・車載HMI・工場FAの領域に集中している。これらの現場では「長期サポート・安定性・クロスプラットフォーム対応」がIDEに求める最優先事項であり、Qt Creator 20の改善はそのニーズに直接応えるものだ。 特にAI補完の強化は注目に値する。組み込み向けC++は独自のコーディング規約や制約（動的メモリ割り当て禁止、例外禁止など）を持つプロジェクトが多く、汎用AIが的外れな提案を出しやすい弱点があった。Qt Creator内で完結するAI統合が進むことで、プロジェクト固有のルールをIDEが把握した状態で補完が動く将来像に近づいている。 即実践できるアクションとしては以下を挙げておく： Qt Online InstallerでBeta版を別環境に導入して動作確認。本番環境には入れず、開発機のサブ環境で試すのが定石 Zen Modeをショートカットキーに割り当てておく。設定→キーバインドで登録しておくだけで作業効率が上がる AIプラグイン設定を見直す。以前設定してそのままになっているケースが多い。今回の強化を機に再設定・チューニングを CMakeを使っているプロジェクトはCMakeキャッシュの再生成を試みると、新バージョンの恩恵を最大限に受けやすい 筆者の見解 Qt Creator 20 Betaを見て率直に感じるのは、「IDEのAI統合は『付けました』から『ちゃんと使える』フェーズに入ってきた」ということだ。 C++というAIにとって難しい言語を扱い、かつQtという独自フレームワークのコンテキストを持ちながら、それでも実用的な補完を出せる環境を整えようとしているQt Groupの姿勢は真剣だ。AI補完を「単なるボーナス機能」ではなく、開発体験の中核に据えようとしている設計思想が感じられる。 一方でZen Modeのような「地味だが本質的な生産性向上」にも手を抜いていない。こういった細かな改善の積み重ねがIDEの成熟度を決める。情報追いよりも「実際に使って成果を出す」ことが大事だという持論からすれば、まずBeta版を手元で動かして感触を確かめることを強くすすめたい。 Qt自体は日本でも産業システムの長期運用基盤として使われ続けており、そのエコシステムの中核IDEがAI時代にしっかりアップデートされていることは喜ばしい。正式リリースが楽しみなアップデートだ。 出典: この記事は Qt Creator 20 Beta released with improved AI support, Zen Mode, and more の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Engadgetが2026年5月9日に報じたところによると、XboxファーストパーティスタジオのDouble Fineが労働組合の結成に向け動き出した。Psychonautsシリーズで知られる同スタジオの正規パートタイム・フルタイム従業員42名全員が、通信労働者組合（CWA：Communications Workers of America）への加盟を目的に、全米労働関係局（NLRB）へ申請書を提出したとのことだ。 なぜいまDouble Fineで組合なのか Aftermath経由でEngadgetがまとめた情報によれば、組合結成の目的は「創造的卓越性、多様性と包摂、そして労働者の生活の質への取り組みを維持・強化するため」とされている。Double Fineは2019年にMicrosoftに買収されてから7年が経過しており、Psychonauts 2（2021年）、Keeper、Kilnといった作品をXbox Game Studiosの傘下でリリースしてきた。小規模・個性派スタジオとして長年知られてきた同スタジオが組合化に踏み切った背景には、大企業傘下に入ったことで生じる組織的変化への対応という側面もあると考えられる。 Microsoft傘下で広がる組合化の波 Engadgetの報道が指摘するように、Double Fineの動きはMicrosoft傘下スタジオにおける組合化の流れの一部だ。 2024年: World of WarcraftチームがBlizzard社内でCWAと組合を結成（500名以上） 2024〜2025年: OverwatchチームがBlizzardで全員参加型組合を結成（約200名） 2025年: ZeniMax Studios（The Elder Scrolls Onlineで知られる）のQAスタッフがMicrosoftと組合協定を締結 2025年8月: BlizzardのDiablo開発チーム450名以上がCWAへの加盟を選択 2026年5月: Double Fineの42名がNLRBに申請 CWAは「Microsoftが中立的立場をとり、労働者の組合結成権に一切干渉しないことに同意した」と評価している。 日本市場での注目点 日本国内では任天堂・ソニー・カプコン・スクウェア・エニックスなど大手ゲームスタジオが多数存在するが、こうした欧米型の組合活動はほぼ前例がない。日本の労働組合制度は欧米と構造が大きく異なり、企業別組合が主流であることが背景にある。一方で、ゲーム業界特有の「クランチ」（リリース前の過酷な残業）問題は国内外を問わず議論が続いており、開発者の労働環境を可視化・改善するムーブメントとして日本のゲーム業界も無視できない動きと言えるだろう。 Xbox Game Pass加入者の観点では、Double Fineのタイトルは引き続きGame Pass経由でプレイ可能であり、組合化が短期的にコンテンツ供給に影響するとは考えにくい。 筆者の見解 Microsoftが傘下スタジオの組合化に対して中立姿勢を貫いていることは、率直に評価したい。交渉の失敗や人材流出は長期的にプラットフォームの魅力を損なう。真正面から向き合う姿勢は正しい判断だ。 気になるのは、これだけの規模でユニオン化が連鎖していること自体が、Microsoft傘下に入ったことで生じた組織的・文化的な緊張感を映している点だ。Double Fineのような個性派スタジオの強みは、小さなチームが高い自律性を持って作品を作り上げる文化にある。それが揺らいでいるとすれば、「もったいない」と感じる。Microsoftにはその文化を守ったまま規模の恩恵を与えられる力があるはずで、正面から勝負できるポテンシャルは間違いなくある。 組合化が必ずしも対立を意味するわけではなく、透明性のある労使関係が創造性の土台になるという視点は、日本のゲーム・IT企業も参考にしてよい考え方だろう。 出典: この記事は Workers for Xbox studio Double Fine are forming a union の内容をもとに、筆者の見解を加えて独自に執筆したものです。