Tech News JP

ローカル環境でのGPU活用、ついに現実的な選択肢に Azure Local（旧Azure Stack HCI）の2026年4月アップデートで、NVIDIA RTX PRO 6000 GPUの正式サポートが追加された。Azure Local上のVMおよびAKS on Azure Arc（Kubernetesクラスター）において、GPUアクセラレーションを活用したワークロードを実行できるようになる。 データをクラウドに送らずにローカルまたはエッジで推論処理を完結させたい——そうしたニーズは、製造・医療・金融など機密性の高い業界を中心に急増している。今回のアップデートはそこに正面から応えるものだ。 何が変わったのか NVIDIA RTX PRO 6000 GPUサポートの追加 RTX PRO 6000はプロフェッショナル向けハイエンドGPUで、AI推論・科学計算・大規模レンダリングなどのヘビーなワークロードを安定して処理できる設計になっている。今回のサポート追加により、以下のようなシナリオが現実的になる。 AIモデルのオンプレミス推論: データをクラウドに送出せず、ローカルでLLMや画像認識モデルを動かす 製造ラインでのリアルタイム品質検査: カメラ映像をエッジで処理し、判定遅延をゼロに 医療画像の院内完結処理: 患者データを外部に出さずに高精度な診断支援 SDN管理フラグの導入 個別のネットワークインターフェースに対してSDN（Software Defined Networking）管理の有効・無効を切り替えるフラグも追加された。地味なアップデートだが、既存インフラとの統合を段階的に進める現場では助かる変更だ。全インターフェースを一括でSDN管理下に置くのではなく、「まずここだけ試す」という進め方が選択できるようになった。 同期間のその他の注目アップデート Ephemeral OS Disk with Full Caching（プレビュー）: OSディスク全体をローカルストレージにキャッシュしてI/Oを高速化。AI推論・データ分析向けに有効 Network WatcherのRule Impact Analysis（プレビュー）: セキュリティ管理ルールを本番適用前に影響プレビュー可能に Forrester Wave「Sovereign Cloud Platforms」リーダー選出: Azure LocalとAzure Arcを組み合わせたハイブリッドアプローチが業界から正当に評価された 実務への影響 データ主権とAIの両立 日本では個人情報保護法や金融・医療分野の業界規制により、「データを国内かつ自社管理下に置く」という要件が根強い。Azure LocalのGPUサポートは、こうした制約をクリアしながらAI推論ワークロードをまともに動かすための現実的な選択肢になる。 AKS on Azure ArcでGPUを使う基本の流れ Azure LocalクラスターにNVIDIA RTX PRO 6000を実装 AKS on Azure ArcのノードプールをGPUノードとして設定 Kubernetes Device PluginでGPUリソースを公開 ワークロードのマニフェストにnvidia.com/gpuリソースリクエストを記述 Azure Arcでクラスターを管理しているなら、ポリシー適用・モニタリング・GitOpsの仕組みはそのまま使えるので、クラウドと同じ操作感でGPUノードを管理できる点が大きい。 ...

2026年4月のPatch Tuesdayは、合計167件（一部報道では168件）の脆弱性を修正する大型アップデートとなった。うち2件がゼロデイ脆弱性で、1件はすでに実際の攻撃への悪用が確認されている。クラウド側ではAzure Logic AppsにCVE-2026-32171（権限昇格）が含まれており、Microsoft側での自動修正は完了しているものの、設定確認を怠るべきではない。「クラウドに移ったから安心」という思考停止への、今月らしい警告だ。 修正された脆弱性の全体像 今月のPatch Tuesdayでは167〜168件という大量の脆弱性が修正された。Critical評価が8件、大多数をImportant評価が占める。修正対象はWindows OS、Office、Azure関連サービス、Hyper-Vなど、Microsoftの広範な製品スタックに及ぶ。 毎月恒例とはいえ、100件を超える修正が続く現状は、企業のパッチ管理担当者にとって相当な負荷だ。「今動いているから大丈夫」が通用しないことは、今月のゼロデイ2件が改めて証明している。 注目すべき脆弱性 実際に悪用されているゼロデイ 2件のゼロデイのうち1件はすでに実際の攻撃で使われている（In-the-Wild Exploitation確認済み）。このタイプは、パッチが公開された時点で攻撃者がすでにアドバンテージを持っていたことを意味する。特に、パッチ適用が遅れがちなオンプレミス環境を抱える組織は最優先で対応すべきだ。 もう1件は公開済み（Publicly Disclosed）だが、現時点では悪用は確認されていない。ただし、公開された脆弱性情報を元に攻撃コードが開発されるまでの時間は年々短くなっている。同様に早急な対応が求められる。 Azure Logic Apps — CVE-2026-32171（権限昇格） クラウド側の注目株はAzure Logic AppsのCVE-2026-32171だ。権限昇格（Privilege Escalation）の脆弱性であり、悪用されると攻撃者が本来アクセスすべきでないリソースや操作権限を取得できる可能性がある。 MicrosoftはすでにAzure側で自動デプロイによる修正を適用済みだ。利用者側が意識してパッチを当てる必要はない。しかし、Microsoftが「設定確認を推奨」としている点は見逃せない。自動修正があったとしても、自組織のLogic Appsのアクセス制御や権限設定が適切かを確認することが求められている。 実務への影響 オンプレミス・ハイブリッド環境の担当者へ ゼロデイが含まれる月は、パッチ適用のスピード感がいつも以上に重要だ。テスト環境への適用→本番展開のサイクルを可能な限り短縮する体制を、今月を機に見直したい。 Azure Logic Apps利用者へ CVE-2026-32171はMicrosoft側で自動対応済みだが、以下を確認しておくことを強く勧める： Logic Appsのマネージドアイデンティティに付与された権限スコープの棚卸し 接続先サービス（Azure Storage、Key Vault等）のアクセス制御リストの見直し 最小権限原則（Least Privilege）の実装状況の確認 パッチ管理全般 167件という規模は、手作業での管理に限界を感じさせる数字だ。Microsoft IntuneやWSUSなどのパッチ管理ソリューションによる自動化・優先度付けの仕組みを整備していない組織は、今月を機に検討してほしい。リスクの高いCritical・ゼロデイから優先適用する運用設計が肝だ。 筆者の見解 毎月100件超の修正が続くPatch Tuesdayの現状は、Microsoftの製品規模の大きさを物語ると同時に、複雑さが積み重なったプラットフォームの宿命でもある。批判より先に言うべきことがある——この規模のソフトウェアエコシステムを維持し、毎月これだけの脆弱性を整理・公開・修正し続けるオペレーションは、相当な技術力と組織力の産物だ。そこは素直に評価している。 一方で、Azure Logic AppsのようなPaaS層にも権限昇格の脆弱性が見つかる現実は、「クラウドに移ったから安心」という思考停止を戒めてくれる。Microsoftが自動修正を行うことの恩恵は大きい。だからこそ、その上で自組織の設定が正しいかを問い続ける姿勢が、利用者側の責任として残る。 ゼロトラストは概念ではなく実装だ。常時付与されたアクセス権は特権管理における最大のリスクであり、Just-In-Time・最小権限・継続的な検証を日常業務に組み込むことが本質的なセキュリティになる。今月のPatch Tuesdayは、その実践を改めて問い直すきっかけとしてちょうどいいタイミングだったかもしれない。 出典: この記事は Microsoft April 2026 Patch Tuesday fixes 167 flaws, 2 zero-days の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが企業システムへ次々と展開される時代が到来した。Microsoft社内では「Agent 365」を中核に据えたAIエージェント管理基盤を構築し、EntraによるID統合とDefenderによるセキュリティ監視、そして統合ダッシュボードによる可観測性確保という三位一体のアプローチを実践している。この社内実装事例は、エンタープライズでのAIエージェント展開を検討する日本のIT組織にとって、具体的な設計指針となるはずだ。 Agent 365とは何か Agent 365は、Microsoft 365エコシステム上で動作するAIエージェントを統合管理するためのガバナンスプレーンだ。個々のエージェントにIDを付与し、アクセス権限を制御し、動作ログを記録する。単なるCopilot機能の延長ではなく、「エージェントをNon-Human Identity（NHI）として扱う」という考え方が根底にある。 これは重要な設計思想の転換だ。これまで企業のID管理といえばユーザーアカウントと一部のサービスアカウントが主役だったが、自律的に動作するAIエージェントが増えるにつれ、それらを人間のユーザーと同等の厳密さで管理しなければセキュリティが成立しなくなる。 EntraとDefenderによるID・セキュリティ統合 Microsoft Entraとの統合により、エージェントは通常のユーザーやサービスプリンシパルと同じアイデンティティ管理フレームワーク上に乗る。条件付きアクセスポリシーの適用、アクセスレビューの実施、Privileged Identity Management（PIM）によるJust-In-Timeアクセスなど、既存の制御メカニズムをそのままエージェントに適用できるのは大きな強みだ。 Microsoft Defender for Cloud Appsとの連携では、エージェントの通信パターンや操作ログを継続的に分析し、異常な振る舞いを検出する。エージェントが想定外のデータにアクセスしたり、不審な処理を実行した場合に即座にアラートを発報できる体制であり、インサイダーリスク管理と同じ品質基準をAIエージェントにも適用する姿勢は評価に値する。 統合ダッシュボードによるエージェント可観測性 管理者が全エージェントの状態を一覧できる統合ダッシュボードは、運用現場で特に価値が大きい。どのエージェントがどのユーザーに利用されているか、どのデータソースにアクセスしているか、直近でエラーが発生していないかをリアルタイムで把握できる。 クラウドネイティブシステムでは「可観測性（Observability）」の確保が当たり前になっているが、AIエージェントに対しても同じ品質基準を適用するこの設計は、エージェントを「ブラックボックスとして野放しにしない」という明確なコンセプトの表れだ。 実務への影響 日本のエンタープライズ環境でAIエージェントを展開する際、今すぐ検討すべきポイントが3つある。 1. NHIの棚卸しを今すぐ始める すでに組織内には多数のサービスアカウント、APIキー、自動化スクリプトが存在するはずだ。AIエージェント導入前に現状のNHI全体を把握し、管理台帳を整備しておくことが、後のガバナンス設計を大幅に楽にする。「あとで整理しよう」と後回しにすると、エージェントが増えてから収拾がつかなくなる。 2. Entraへの一元化が前提条件 Agent 365のID統合はEntraを前提とする。オンプレミスのADやサードパーティのIDプロバイダーをそのまま使い続ける環境では、統合管理の恩恵を受けにくい。M365移行の優先度を上げる理由がまた一つ増えたといえる。 3. 「最小権限」を設計段階から組み込む エージェントに広めの権限を与えておいて後から絞るのではなく、設計時点から必要最小限のスコープでロールを定義する。後から権限を絞ることは組織的な摩擦が大きく、現場の反発も生みやすい。最初から絞っておくのがはるかに楽だ。 筆者の見解 今回のAgent 365ガバナンス基盤は、Microsoftが自社の課題をそのまま製品設計に反映させた「社内ユースケース駆動型」の好事例だと思う。エンタープライズ向けプラットフォームを展開する企業が自ら最大の実験場になるのは、技術の信頼性を高める上で非常に効果的なアプローチだ。 特にNon-Human IdentityをEntraのフレームワークに統合した点は理にかなっている。AIエージェントが業務自動化の主役になるほど、そのIDと権限を人間と同じ厳密さで管理する必要が増す。ボトルネックは常に「人間の関与」であり、NHIとしてのエージェントを適切に管理できて初めて、本当の意味での業務自動化が実現する。その現実に正面から向き合った設計だ。 一方で、ガバナンス基盤がどれだけ整っても、エージェント自体が業務の現場で実際に役立つ体験を提供できなければ「形だけの整備」で終わる。管理の仕組みと、エージェントが日々の業務に定着する体験の両方を同時に磨いていく必要がある。その両輪がかみ合ったとき、M365は統合プラットフォームとしての本来の価値を発揮できるはずだ。Microsoftにはその実力が十分にある。今後の展開を期待を込めて注目したい。 出典: この記事は Shaping AI management at Microsoft with Agent 365 and Copilot controls の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MacRumorsが引用したMacworldの報道によると、Appleは今後1年以内に「iPhone Ultra」と「MacBook Ultra」の2製品を投入する計画だ。いずれも各ラインアップの最上位に位置付けられ、「Ultra」ブランドがAppleの製品戦略の中核に据えられることになる。 iPhone Ultra——初の折り畳みiPhoneが最上位へ Macworldの情報筋によると、Appleが長年開発を続けてきた折り畳みiPhoneは「iPhone Ultra」として登場する見通しだ。 主な特徴: iPhoneラインアップ最上位のポジション（iPhone 18 Pro / Pro Maxとは別シリーズ扱い） iPhone 18 Proと同時リリースを目指すが、数週間の遅れが生じる可能性あり 発売当初は供給が限定的になる見込み なお、iPhone UltraがiPhone 18シリーズと別扱いとなる点は注目に値する。iPhone Air（iPhone 17シリーズとは別枠）と同様のポジショニング戦略であり、Appleがフラッグシップラインを複数系統に分岐させていることを示している。 MacBook Ultra——OLEDとタッチスクリーンでMacBook Proの上を行く Macworldの報道によれば、「MacBook Ultra」はOLEDパネルとタッチスクリーンを搭載し、現行のMacBook Proよりも「大幅に高い」価格帯に設定される予定とされている。 主な特徴: OLEDディスプレイ搭載 タッチスクリーン対応 ダイナミックアイランド搭載 C2モデム内蔵 MacBook Pro上位に位置付け（「大幅に高い」価格帯） 当初は2026年内の発売が予定されていたが、メモリのサプライチェーン不足を理由に2027年初頭へのずれ込みが有力となっている。 「Ultra」ブランドの本格展開 Appleはすでに、MシリーズのUltraチップ、Apple Watch Ultra、CarPlay Ultraといった製品群で「Ultra」ブランドを展開している。今回の2製品追加により、「Ultra」はAppleの最上位ラインを横断するプレミアムブランドとして本格的に確立されることになる。Bloombergも以前から両製品への「Ultra」ブランド付与を報じており、さらに「AirPods Ultra」の登場も示唆している。 日本市場での注目点 iPhone Ultra（折り畳み）: 折り畳みスマートフォン市場ではSamsung Galaxy Z FoldシリーズやGoogle Pixel Foldが先行しているが、Appleが参入することで日本市場での認知・普及が一気に加速する可能性がある。Macworldの報道では発売当初の供給制約が予告されており、発売直後は入手困難な状況も想定される。 MacBook Ultra: 「大幅に高い価格帯」という表現から、現行MacBook Pro最上位（約60万円台）を大きく超える価格設定が予想される。OLEDとタッチスクリーンの両立はクリエイター市場やビジネスユーザーの強い関心を集めるだろう。 発売時期: MacBook Ultraは2027年初頭にずれ込む可能性が高く、iPhone Ultraも初期供給は限定的になる見通し。日本での正式発売時期・価格は現時点で未発表。 筆者の見解 「Ultra」ブランドの横断的な展開は、Appleのラインアップ戦略として理にかなっている。既存の「Pro」から一段上の選択肢を設けることで、価格帯の上限を引き上げながらユーザーの選択肢を広げる狙いだ。 iPhone Ultraとして登場する折り畳みiPhoneは、スペックよりも「Appleが出した」という信頼性と完成度そのものが市場を動かす製品になるだろう。折り畳み端末は耐久性や使い勝手の面で成熟段階にあり、後発とも言えるAppleがどこまで独自の解を示してくるかは興味深い。ハードウェア品質とソフトウェア最適化の両面での完成度を見せられれば、市場を塗り替える力を持っていることは疑いようがない。 より注目したいのがMacBook Ultraのタッチスクリーン搭載だ。これまでmacOSがタッチ操作を明確に拒絶してきた歴史を考えると、この判断はかなり大きな転換点を意味する。「タッチで使えるMac」を本当に投入するならば、プロフェッショナル向けコンピューティングの定義が変わりうる。実際の使い勝手はレビューが出てから慎重に判断したいところだが、方向性としては注目に値する動きだ。サプライチェーン起因の遅延で発売が2027年にずれ込む可能性がある点は残念だが、熟成させて出てくることへの期待感は高まる。 関連製品リンク ...

GoogleがYouTubeに新たなAI検索体験「Ask YouTube」のテストを開始した。通常の検索とは一線を画す会話型UIで、テキスト要約・ロングフォーム動画・Shortsを一画面に統合して提示する。現時点では米国のYouTube Premiumサブスクライバー（18歳以上）向けの実験段階だが、Googleはすでに非Premiumユーザーへの展開を検討中だと表明しており、グローバル展開は時間の問題とみられる。 Ask YouTubeの仕組み 検索バーに「Ask YouTube」ボタンが追加され、クリックすると会話型の検索インターフェースに切り替わる。自然言語でクエリを入力すると、数秒の処理後に以下の3要素で構成されるページが生成される。 AIテキスト要約: クエリに対する概要文と箇条書きのキーポイント テーマ別動画ギャラリー: トピックに沿ったロングフォーム動画をセクションごとに整理 Shortsギャラリー: 短時間で要点を掴めるShorts動画のまとめ 「アポロ11号の月面着陸の短い歴史」というクエリでは、ミッション概要のテキストに続き、打ち上げ映像へのタイムスタンプ付きリンク、「打ち上げから帰還まで」「歴史的映像とメイキング」などのギャラリーが並んで表示された。さらに「アポロ11号の宇宙飛行士は誰？」と続けて尋ねると、ニール・アームストロング、バズ・オルドリン、マイケル・コリンズの3名に関する情報グリッドへと文脈を引き継いだ回答が得られた。会話の文脈を保ちながら深掘りできる設計は、従来の検索とは明確に異なる体験だ。 見逃せない精度問題 一方、実際に試用した記者が重大な事実誤認を発見している。Valveの新型Steamコントローラーについて検索した際、「旧来のSteamコントローラーにはジョイスティックがない」という誤った情報が生成されたのだ（実際には1つのジョイスティックが搭載されている）。 これはAsk YouTubeが回答テキストを構築する際、参照した動画のコンテンツから推測的に情報を抽出している可能性を示唆している。つまり、引用元の動画が不正確だったり古かったりすれば、その誤りが要約に混入するリスクがある。AIが要約を「生成」するのではなく、動画コンテンツを「解釈して再構成」している側面が強い設計の宿命とも言える。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと 日本での展開はまだ先だが、今から知っておくべき実務上のポイントがある。 YouTube Premiumユーザーは展開時に即試す価値あり: 技術解説動画が豊富なYouTubeで会話型検索が使えるようになれば、キャッチアップの効率は大きく変わりうる。特に「あのトピックの全体像を短時間で把握したい」という場面では強力なナビゲーターになり得る。 企業のYouTube活用戦略の見直し: 技術解説や製品デモをYouTubeで発信している組織にとっては、Ask YouTubeの検索結果に適切に引っかかるかどうかが新たなプレゼンス指標になる可能性がある。動画タイトル・説明文・字幕の質がこれまで以上に重要になるだろう。 AI要約は「入口」として使い、一次情報は必ず確認: 特に技術的な正確さが求められる場面——仕様確認、トラブルシューティング、セキュリティ関連——では、AI生成の要約テキストを最終回答として扱わないことが鉄則だ。「どの動画を見るべきかを探すナビゲーター」として割り切った運用が現実的な付き合い方になる。 筆者の見解 「Ask YouTube」が興味深いのは、動画という本質的にマルチモーダルなコンテンツを横断的に整理・案内するという、テキスト検索のAI化とは異なる難しい問題に正面から向き合っている点だ。YouTube上に蓄積された膨大な動画を「会話で探せる」体験にしようというアプローチ自体は、筋が通っていると思う。 課題は精度だ。今回確認された事実誤認が示すとおり、動画コンテンツから推測的にテキストを生成するアーキテクチャには構造的なリスクがある。Googleがこの精度問題をどう解決していくかが、機能の実用性を左右する最大の焦点になるだろう。 より本質的な問いとして感じるのは、こうした「AI統合検索」が主流になっていくなかで、私たちは一次情報に当たり続ける習慣をどう守るか、ということだ。使いやすいUIほど、「AIが要約した概要を読んで理解した気になる」罠にはまりやすい。情報を追うことよりも、実際に手を動かして確かめる経験を積む——その姿勢こそが、AI時代においても変わらず価値を持ち続けると考えている。Ask YouTubeも、便利な「入口」として賢く活用したい。 出典: この記事は Google is testing AI chatbot search for YouTube の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月4日、データ恐喝グループLapsus$がAI人材プラットフォーム「Mercor」から奪った約4TBのデータをリークサイトに公開した。流出したのは単なる個人情報ではない——4万人超のAIコントラクターが提供した「スタジオ品質の音声サンプル」と「政府発行の身分証明書スキャン」のセットだ。この組み合わせは、現在の音声クローニング技術にとってほぼ完璧な素材であり、攻撃者が今すぐ悪用できる状態にある。流出から10日以内に5件の集団訴訟が提起されたことも、事態の深刻さを物語っている。 なぜこれが危険なのか：「声」はパスワードと根本的に違う パスワードは変えられる。声は変えられない。 Wall Street Journalが2026年2月に報じたところによれば、市販ツールで高品質な音声クローンを作成するのに必要なクリーン音声はわずか15秒程度だ。Mercorから流出した音声は一人あたり平均2〜5分——しかもノイズのない「スタジオ品質」である。閾値を大きく上回るどころか、プロ仕様の素材と言っていい。 さらに深刻なのは、Mercorのオンボーディングフローが意図せず「完璧な攻撃素材セット」を1行のデータベースレコードにまとめていた点だ： パスポートまたは運転免許証のスキャン ウェブカメラによる自撮り写真 静かな環境での音声録音（スクリプト朗読） これまでの音声漏洩では「録音はあるが身元がわからない」か「身分証はあるが音声がない」かのどちらかだった。Mercorはその両列を1行に統合してしまった。 攻撃者が今実際にできること 以下はすべて、この流出以前からすでに実際に使われている攻撃手法だ。 銀行の音声認証バイパス 米国・英国の一部の銀行では音声認証が二要素認証の一つとして機能している。クローンした音声でチャレンジフレーズを読み上げればこの関門は突破でき、残る知識ベース認証も多くの場合、同じ流出データセットから補完できる。 社内Vishing（音声フィッシング） HRや経理部門に本人の声で電話し、給与の振込先変更やワイヤー送金を要求する。Krebs on Securityのアーカイブには2023年以降、この手法による確認済み被害が30件以上記録されている。 Arup型ディープフェイクビデオ通話 2024年にHong KongのArup社の経理担当者が、本物そっくりのビデオ通話を信じて約2,500万ドルを送金させられた。あの事件では公開映像から素材を作成していたが、Mercorの流出データはその品質をはるかに上回る。 保険詐欺と高齢者なりすまし Pindropは2025年、保険コールセンターへの合成音声攻撃が前年比475%増加したと報告。FBI Internet Crime Complaint Centerは2026年、60歳以上の被害者損失が23億ドルに達し、最も急成長している手口が「親族の緊急電話を装ったなりすまし」だと記録している。 日本のIT現場への影響 日本でも生成AIブームに乗って「データラベリング副業」「音声録音案件」は急増している。クラウドソーシング各社にも類似案件は大量に存在し、日本人がMercorに登録していた可能性は排除できない。 エンジニアやIT管理者が今すぐ対応すべき項目： 社員の流出プラットフォーム登録確認: 副業を許可している企業は特に要確認。Mercorだけでなく類似プラットフォームも対象に 音声認証の廃止または強化: コールセンター・金融系・VoIPシステムで音声認証を採用しているなら、代替または多要素化を検討する時期だ Vishing訓練の導入: メールフィッシング訓練と同様に、音声によるなりすまし攻撃への対応訓練を組み込む 緊急送金フローの見直し: 電話一本で送金できる設計は今後さらに危険になる。必ず独立した確認チャネル（Teamsチャット等）を並走させる AIデータ収集契約の法的精査: 「音声録音はトレーニング目的」という表記だけでは生体認証識別子としての扱いが不明確。個人情報保護法上のリスクも含め契約書を見直すこと 筆者の見解 今回の流出で改めて痛感するのは、AIトレーニングデータの収集インフラが「セキュリティファースト」で設計されていなかったという根本的な構造問題だ。 音声録音を「トレーニングデータ」と説明しながら、実質的には永続的な生体認証識別子を収集していた——5件の訴訟が主張する通りの構図だとすれば、これは日本の類似サービスにも他人事ではない。何のデータをどのような用途で収集するかを明示しないまま同意を取得する慣行は、AIブームの中で業界全体に広がっている。 声は取り替えられない。パスワードなら全部変えれば済む話だが、声紋は一生ついて回る。この非対称性を本当に理解してデータを提供した人が、何人いただろうか。 AIエージェントが社内システムと連携し、音声指示で業務を自動化する時代は目の前に来ている。その基盤となる「声の信頼性」が揺らぎ始めている今、「利活用が先、セキュリティは後回し」という開発文化を続けることのコストは、Mercorの件で一段と明確になった。Mercorはほんの始まりに過ぎないかもしれない——そう考えて動き始めることが、今できる最善の対策だ。 出典: この記事は 4TB of voice samples just stolen from 40k AI contractors at Mercor の内容をもとに、筆者の見解を加えて独自に執筆したものです。

TerminalBench 2.0というAIエージェントのベンチマーク競技で、無名のオープンソースコーディングエージェント「Dirac」が65.2%というスコアを記録した。同じモデル（Gemini 3 Flash Preview）を使ったGoogle公式実装（47.6%）はもちろん、有力なクローズドソースエージェント「Junie CLI」（64.3%）をも上回る結果だ。モデルの性能ではなくエージェントの設計が勝敗を左右する——この事実を、改めて数字で突きつけた出来事として注目に値する。 Diracとは何者か Diracは、コンテキスト長の最適化を核に据えたオープンソースのコーディングエージェントだ。開発者が強調するのは「コンテキストを絞ることで、精度・コスト・速度のすべてが改善する」という設計思想。長大なコンテキストウィンドウに情報を詰め込み続けるアプローチとは真逆の発想から生まれている。 技術的な3つの柱 ハッシュアンカー付き編集（Hash-Anchored Edits） 行番号ではなくハッシュ値でターゲット行を特定することで、コード変更の精度を大幅に向上。「行番号がずれて全く関係ない箇所を書き換えてしまう」という古典的な誤動作を根本から排除している。 AST（抽象構文木）ネイティブ操作 TypeScript、Python、C++などの言語構造をエージェント自身が理解した上で、関数抽出やクラスリファクタリングといった構造的変更を実施する。「テキストの文字列一致」ではなく「コードの意味」で操作するため、複雑なリファクタリングでも高い精度を維持する。 マルチファイル並列処理 複数ファイルへの変更を1回のLLMラウンドトリップで完了させることで、レイテンシとAPIコストを同時に削減。処理の効率化とコスト抑制を両立している。 コスト削減が圧倒的 他の主要エージェントと比較して平均64.8%のコスト削減（約2.8倍の費用対効果）を実現している。タスクあたりの平均コストが$0.18と、競合の$0.38〜$0.73を大きく下回る。同じ精度でより安く——これは企業展開を検討する際に無視できない数字だ。 TerminalBenchの「不正疑惑」という文脈 同ベンチマークでは最近、AGENTS.mdファイルを使ったズル（ベンチ固有情報をエージェントに事前注入する手法）の報告が相次いでいる。Diracのチームはこれを明確に否定しており、「ベンチ固有情報の注入は一切なし」「公開OSSそのままで実行」と説明している。リーダーボードへのPRが8日間放置されているという状況も含め、現在のコミュニティの混乱を示す背景として押さえておきたい。 実務への影響——日本のエンジニアが注目すべき点 Diracが日本の現場に示す示唆は大きく3点だ。 コスト試算が現実的になる: APIコストが大幅に削減されるため、自社プロジェクトへのAIエージェント導入の費用感が変わる。大規模リファクタリングや定期的なコード品質改善タスクの自動化を検討するなら、まず試算してみる価値がある MCPを使わないシンプルな構成: MCPサーバーの設定・管理コストを省けるため、複雑な依存関係を避けたい現場との相性がいい OSSゆえに設計が学べる: ハーネス設計の参考として、コードを直接読んで学べる。自社エージェントの設計に転用できる知見が詰まっており、「動かすだけ」でなく「設計思想を盗む」使い方ができる 筆者の見解 「どのモデルを使うか」よりも「どうやってモデルを動かすか」の方が重要——AIエージェントの世界では繰り返し証明されてきた原則だが、Diracの結果は改めてそれを鮮明にした。 Gemini Flash Previewという廉価なモデルを使いながら、モデルプロバイダー自身の公式実装を大幅に上回るスコアを出したという事実の重みは大きい。同じモデル、同じリソース制約の下で、コンテキスト管理・ツールの組み合わせ・処理ループの設計が本当の差別化要因になっている。 ここから学べることは明確だ。最新・最高性能のモデルを追いかけるよりも、手元にあるモデルを最大限に活かすハーネス設計を磨くことに時間を使う方が、実務的なリターンはずっと大きい。「何を使うか」ではなく「どう動かすか」で結果が決まる段階に入っている以上、設計力こそが今問われているスキルだ。 オープンソースコミュニティがこの設計ノウハウを蓄積・共有し始めているいま、日本のエンジニアも「ツールを使う側」から「エージェントを設計する側」へシフトする絶好のタイミングだと感じている。 出典: この記事は Show HN: OSS Agent I built topped the TerminalBench on Gemini-3-flash-preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国の個人向け証券取引プラットフォーム「Robinhood」で、アカウント作成フローのHTML注入脆弱性が攻撃者に悪用された。送信元は本物の noreply@robinhood.com、SPFとDKIMの検証も通過済み——にもかかわらずフィッシングメールが大量配送されたこの事件は、「メール認証さえ通っていれば安全」という思い込みを正面から崩す。 何が起きたのか 2026年4月27日の夜、Robinhoodの利用者のもとに「認識されていないデバイスからのログイン」を警告するメールが届き始めた。メール内の「Review Activity Now」ボタンをクリックすると robinhood[.]casevaultreview[.]com というフィッシングサイトへ誘導され、認証情報の窃取が試みられた。 Robinhoodは後にX（旧Twitter）上で公式声明を投稿し、「アカウント作成フローの悪用によるものであり、システムや顧客口座への侵害ではない」と認めた。問題のフィールドは既に削除され、現時点で脆弱性は修正済みだ。 攻撃の仕組み：入力サニタイズの欠如が招いたHTML注入 技術的な攻撃経路は明快だ。Robinhoodでは新規アカウント作成時、登録したメールアドレス宛に確認メールを自動送信する。このメールには登録時刻・IPアドレス・デバイス情報・おおよその位置情報が含まれていた。 問題はデバイス情報フィールド（Device: フィールド）にあった。攻撃者はHTTPリクエストのデバイス関連メタデータを改ざんし、任意のHTMLを埋め込んだ。Robinhoodのバックエンドがこの値を適切にサニタイズせずそのままメール本文にレンダリングしたため、攻撃者が仕込んだ「アカウント不審活動」の偽警告セクションが正規メールの一部として表示された。 加えて攻撃者はGmailのドット別名（Dot Aliasing）動作も利用した。Gmailでは user.name@gmail.com と username@gmail.com は同一の受信箱に届く。この仕様を使い、既知の被害者メールアドレス（2021年のRobinhood情報漏洩で流出した700万件以上のデータが利用されたとみられる）の変形バリエーションを使って偽アカウントを量産。正規の確認メールをターゲットに届けることが可能だった。 SPF/DKIMを通過した理由 ここが重要なポイントだ。SPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）は、「そのドメインの正規サーバーから送信されたか」を検証する仕組みであり、「メール本文の内容に不正な要素が含まれていないか」は検証しない。 今回のメールは確かにRobinhoodの正規サーバーから noreply@robinhood.com として送信されたため、両チェックをクリアした。メール認証の合格が「メールの安全性」を保証しないことを、この事件は改めて示している。DMARC（Domain-based Message Authentication, Reporting & Conformance）も同様で、ドメインなりすましへの対策にはなるが、今回のような「正規フロー内への悪意ある注入」には無力だ。 実務への影響：日本のエンジニア・IT管理者が今日から見直すべきこと この事件は遠い海外のサービスの話ではない。ユーザー入力をシステムメールに含める設計は、あらゆるWebサービスで同様のリスクを内包している。 1. メール生成時のテンプレートエスケープを必ず確認する デバイス情報・ユーザーエージェント・住所・姓名など「ユーザーが制御できる文字列」をメール本文に挿入するすべての箇所で、HTMLエスケープ（またはプレーンテキスト強制）が実装されているか確認する。HTMLメール生成ライブラリのオートエスケープ設定は「有効か」だけでなく「抜け穴がないか」まで見ること。 2. トランザクションメールをセキュリティレビューの対象に含める 「ユーザーへの通知メール」はビジネスロジックの一部として機能するが、セキュリティレビューの対象から外れやすい。コードレビューのチェックリストに「メール本文への可変値挿入」を明示的に追加する。 3. 2021年のRobinhood漏洩データが今も悪用されていることを念頭に置く 今回の攻撃者は旧来の漏洩データをターゲットリスト作成に流用したとみられる。自社サービスユーザーのメールアドレスが過去のリスト流出に含まれている可能性を前提に、フィッシング耐性（パスキー導入・MFA必須化）の強化を検討する。 4. 「正規アドレス発のメールでも疑う」教育を従業員・ユーザーに SPF/DKIM通過・正規ドメイン発という条件が「安全の証明」にならないことを、社内セキュリティ教育のアップデートに盛り込む。特に金融系・ECサービス利用者への啓発が急務だ。 筆者の見解 正直に言うと、セキュリティ案件は細かい話が多くて得意分野とは言いにくい。ただ、今回のような「根本的な入力サニタイズの欠如」が実際の攻撃に使われた事例は、技術的に非常に興味深い。 見方を変えれば、これは「高度な攻撃」ではない。攻撃手法としては古典的なHTML注入だ。それが2026年に、上場企業のトランザクションメールフローで発動した。「今動いているから大丈夫」の姿勢がいかに危険かを示す事例として、教科書に載せられるレベルだと思う。 Gmailのドット別名を使ったアカウント量産も、長年知られている仕様だ。「既知の仕様が攻撃に組み合わされる」パターンは今後も増える。新しい脆弱性を追うより、基本的な防御の穴をふさぐことの方が、多くの現場で今すぐ優先されるべきだと感じる。 Robinhoodは迅速に修正しており、対応自体は評価できる。ただ、700万件の漏洩から5年後に、その漏洩データを使った攻撃を受けているという事実は重い。一度流出した情報は永続的に攻撃リストとして機能する——この現実を、サービス運営者もユーザーも改めて認識する機会にしてほしい。 出典: この記事は Robinhood account creation flaw abused to send phishing emails の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがExchange Onlineにおけるレガシー TLS（Transport Layer Security）接続のブロックを近く開始する。TLS 1.0およびTLS 1.1を使ってExchange Onlineと通信しているシステムやアプリケーションは、対応しなければある日突然メールの送受信ができなくなる。日本企業でも広く影響が及ぶ可能性があり、今すぐ確認と準備が必要だ。 なぜ今、TLSが問題になるのか TLS（Transport Layer Security）は、Exchange Onlineとメールクライアントやアプリケーションとの通信を暗号化するプロトコルだ。TLS 1.0は1999年、TLS 1.1は2006年に策定された古い規格であり、POODLE・BEAST・RC4攻撃など複数の深刻な脆弱性が長年にわたって発見されている。 業界全体でTLS 1.2（2008年）やTLS 1.3（2018年）への移行が進んでいるが、日本の企業環境では依然として古い接続が残存しているケースが多い。Microsoftはこれまでも繰り返し廃止を予告してきたが、今回はいよいよ実際のブロックに踏み切る段階に入る。 影響を受ける可能性があるもの 以下のシステムやアプリケーションは要注意だ： 古いメールクライアント: TLS 1.2未対応の旧バージョンのOutlookやサードパーティクライアント 複合機・スキャナー: SMTPでメールを送信するネットワーク機器（特に古い機種） 業務アプリケーション: ERP・CRM・基幹システムなどからのSMTPリレー接続 自動化スクリプト: PowerShellや各種スクリプトからのExchange Online接続 外部サービス連携: サードパーティのメール配信サービスや連携システム 日本企業で特に見落とされがちなのが、複合機やレガシー業務システムからのSMTPリレーだ。「今日も使えているから大丈夫」と放置されている機器が、ある朝突然メール送信できなくなる——そういうケースが現実になる。 実務での確認・対応ポイント ステップ1: 影響を受けるシステムを特定する Microsoft 365管理センターやExchange Online PowerShellから、現在レガシーTLSで接続しているシステムを特定できる。まず「どこから古いプロトコルで接続しているか」を把握することが出発点だ。 MicrosoftはAzure Monitor・Microsoft Defender for Cloudなど複数の経路でレガシー接続の検出を支援している。これらのツールを活用して棚卸しを進めてほしい。 ステップ2: 各システムの対応方針を固める メールクライアント: TLS 1.2以上に対応した最新バージョンへ更新 複合機: ファームウェアアップデートを確認し、対応できない場合はSMTPリレー構成を見直す 業務アプリケーション: ベンダーへ問い合わせ、または接続ライブラリのアップデートを実施 スクリプト・自動化: [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 のような明示的な指定を追加 ステップ3: テスト環境・少数アカウントで事前確認 本番でブロックされる前に、テスト環境または限られたアカウントで影響範囲を確認しておくことが理想的だ。 日本のIT現場への影響 日本企業特有の課題として、「動いているから触らない」という運用文化がある。セキュリティプロトコルの更新よりも既存システムの安定稼働を優先する傾向が強く、古いTLS接続が長年放置されているケースは決して珍しくない。 さらに、複合機や基幹システムの更新には社内稟議・予算確保・ベンダー調整が必要で、迅速な対応が難しい事情もある。だからこそ、今すぐ影響範囲を把握し、経営層や関係部署への報告・調整を始めることが重要だ。「ブロックが始まってから初めて気づく」では遅い。 筆者の見解 レガシーTLSのブロックは、Microsoftが取るべき当然の判断だ。TLS 1.0/1.1は攻撃者にとって既知の標的であり、これを使い続けることはリスクを意図的に放置しているのと変わらない。むしろ「なぜここまで時間がかかったのか」という気持ちすらある。 ゼロトラストの考え方に立てば、通信経路の暗号化品質は妥協すべきラインではない。プロトコルの老朽化を「業務上の都合」で先送りにする理由はない。 一方で、今回の変更は「急な話」ではない。Microsoftは長期にわたって廃止を予告してきた。それでも対応できていない組織があるとすれば、問題はプロトコルではなく、IT管理の仕組みそのものにある。セキュリティの変化に追随できる運用体制を持つこと——それが本当の意味での「対応」だ。 ...

Ars TechnicaのDan Goodin記者が2026年4月27日に報じたところによると、月間100万以上のダウンロードを誇るオープンソースの機械学習モニタリングツール「elementary-data（element-data）」がサプライチェーン攻撃により汚染された。悪意あるバージョン0.23.3がPyPIおよびDockerイメージとして公開され、実行した環境から幅広い認証情報が窃取された可能性がある。 なぜこのパッケージが狙われたのか element-dataは、dbtを中心とするデータエンジニアリングスタックのパフォーマンスや異常を監視するCLIツールだ。データウェアハウスやML基盤を運用するエンジニアに広く使われており、月間100万ダウンロードという規模がそのまま攻撃のインパクトを示す。 攻撃者が直接パッケージを改ざんしたわけではない。開発チームのGitHub Actionsワークフローに存在した脆弱性を突いて開発者アカウントに侵入し、正規の署名プロセスを通じて悪意あるバージョンを公開したのが今回の手口だ。外見上は正規のパッケージと区別がつかないため、ユーザー側からの検知は事実上不可能だった。 海外レビューのポイント：攻撃の全容と対応 Ars Technicaの報道によると、攻撃者はプルリクエストに悪意あるコードを混入させ、GitHub Actions内でbashスクリプトを実行させることに成功。署名キーとアカウントトークンを入手した後、それらを使って悪意あるelement-data 0.23.3を公開した。 窃取された可能性のある情報： ユーザープロファイル データウェアハウス認証情報（dbt profilesなど） クラウドプロバイダーキー（AWS・Azure・GCPなど） APIトークン・SSHキー .envファイルの内容 同報告書の中でHD Moore氏（runZero CEO・40年以上のキャリアを持つハッカー）は「オープンリポジトリを持つOSSプロジェクトにとって構造的な大問題」と指摘している。悪意あるバージョンは約12時間後に削除されたが、その間にインストール・実行したユーザーはすでに危険にさらされている。 即刻確認すべき対応手順 開発チームは以下の対応を強く呼びかけている。 ステップ1：バージョン確認 出典: この記事は Open source package with 1 million monthly downloads stole user credentials の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米航空宇宙局（NASA）のジャレッド・アイザックマン長官は2026年4月27日、米下院予算公聴会で証言し、アルテミスIIIミッションが早くても2027年後半の打ち上げになると明らかにした。Ars Technicaが報じた。 なぜこのミッションが注目か アルテミスIIIは当初、人類の月面再着陸を実現する歴史的なミッションとして計画されていた。しかし今年2月、NASAは計画を大幅に見直し、月面着陸なしの地球軌道周回ミッションへと変更した。この判断の背景には「安全と確実性の優先」という明確な意図がある。 元の計画では、宇宙飛行士が初めてスターシップや Blue Moon に乗り込む場所が「月面近傍（約40万km彼方）」になる予定だった。何か問題が起きても、地球に戻るまで数日かかる状況だ。 海外レビューのポイント Ars Technicaの報道によると、NASAはアルテミスIIIをアポロ9号に相当するミッションと位置づけている。アポロ9号は1969年3月、アポロ11号による月面着陸の4か月前に地球軌道で月着陸船のドッキングテストを実施した歴史的なミッションだ。 今回のアルテミスIIIでは、Orion宇宙船が宇宙飛行士を乗せて打ち上げられ、地球低軌道上でSpaceXのStarship Human Landing System（HLS） および Blue Origin のBlue Moonの一方または両方とランデブー・ドッキングを試みる。問題が起きても、地球まで数時間以内に帰還できる安全な環境だ。 Ars Technicaによれば、打ち上げ軌道の高度やSLSロケットの上段構成はまだ検討中とのこと。低軌道なら既存の上段を温存して次のミッションに使えるが、高軌道の方が月環境に近い条件でテストできるというトレードオフがある。 スケジュールの現状 2026年4月初旬：アルテミスIIがほぼ完璧な飛行を完了（記事執筆時点の「今月」） 2027年後半（予定）：アルテミスIII打ち上げ（地球軌道ミッション） 2028年（目標）：アルテミスIV・V相当として月面着陸を最大2回実施 背景に中国の有人月面着陸計画との競争があり、トランプ政権任期内の実績作りも意識されている 日本市場での注目点 アルテミス計画にはJAXAも参加しており、日本人宇宙飛行士の月面着陸が公式に約束されている。今回のスケジュール延期はJAXAの計画にも影響が及ぶ可能性があり、関係者の動向に注目が必要だ。 また、SpaceX Starshipの開発は日本の宇宙スタートアップ業界や衛星打ち上げビジネスにも間接的な影響を与えるため、宇宙関連分野のエンジニアや投資家にとっても他人事ではない。 月着陸機2社体制（SpaceX + Blue Origin）の競争環境は、長期的なコスト低減と技術革新の観点で評価されており、日本企業が参画するビジネス機会を生む可能性もある。 筆者の見解 今回のアルテミスIII計画変更は、一見すると「後退」に見えるかもしれないが、筆者には正しいエンジニアリング判断に映る。 「初めて乗り込むのが月面近傍」という元の計画は、確かに野心的すぎた。アポロ計画が9号で地球軌道テストを挟んでから11号で月面着陸に臨んだように、未知のシステムを段階的に検証するアプローチは宇宙工学の定石だ。「道の真ん中を歩く」——標準的で再現性のある手順を踏むことが、最終的に最速・最確実への近道になる。 SpaceX Starshipも Blue Moon も、まだ人間を乗せた本番飛行の実績がない。地球軌道でドッキングを実証してから月へ向かう判断は、リスク管理として極めて合理的だ。 2027年後半というタイムラインは決して余裕のあるスケジュールではなく、中国との月面競争を意識した上での圧縮案でもある。NASAが「急ぎながらも急がない」バランスをどこで取るのか、次の公式発表を注視したい。 出典: この記事は Put it in pencil: NASA’s Artemis III mission will launch no earlier than late 2027 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

PC Watch（2026年4月28日付）の報道によると、エレコムが「世界初のナトリウムイオンモバイルバッテリ」として販売していた製品群が、国土交通省の規則改訂を受けて航空機への持ち込み・預け入れともに全面禁止となった。エレコムは公式サイトにお詫びと注意喚起を掲載している。 ナトリウムイオンバッテリとは——「安全」が売りだったはず エレコムは2025年3月、一般向けの「世界初ナトリウムイオンモバイルバッテリ」を発売した。従来のリチウムイオン電池と比較した主な特徴は以下の通り。 難燃性・発火リスクの低さ: 釘を刺しても発火しにくい構造 長寿命: 5,000回の充放電サイクルを実現（リチウムイオンの一般的な製品は500〜1,000回程度） 環境負荷の低さ: レアメタル（コバルト・ニッケル等）を使用しない これらの特長から、エレコムはパッケージおよびWebサイトに「機内持ち込み可能」と明記して販売していた。 なぜ禁止になったのか——規制改訂の経緯 国土交通省は2026年4月24日、「機内への持込み又はお預け手荷物に制限がある品目の代表例」を更新。この改訂により、ナトリウムイオン電池が航空機への持ち込みおよび預かり入れの両方が不可として明記された。 エレコムはこの行政ルール変更を受けてお詫びを掲載。Webサイトの表記を順次修正するとともに、市場流通中の製品パッケージについても順次改訂するとしている。ただし、切り替え期間中は「機内持ち込み可」と表記された旧パッケージが流通し続けるため、購入済みの方は特に注意が必要だ。 保安検査時に対象製品が発見された場合、破棄または没収の可能性があるとエレコムは明記している。 対象製品一覧 今回の規制対象となるエレコム製品は以下の通り。 ナトリウムイオン電池モバイルバッテリー DE-C55L-9000BK DE-C55L-9000LGY EC-C27LBK ナトリウムイオン電池搭載 ハンディファン 冷却プレート付き FAN-U264BE / FAN-U264GN / FAN-U264WH ナトリウムイオン電池搭載 コンパクトハンディファン FAN-U265BK / FAN-U265GN / FAN-U265WH 日本市場での注目点 「安全だから機内に持ち込める」という前提が崩れたことは、今夏の旅行・出張シーズンを前に日本の消費者が把握しておくべき情報だ。 エレコムのナトリウムイオンバッテリ製品はAmazon.co.jpや家電量販店で「長寿命・安全」というセールスポイントで販売されており、旅行用途を意識して購入したユーザーも少なくないと思われる。購入済みの方は今後の航空機利用において持ち込み不可となる点に留意が必要だ。 なお、既存のリチウムイオンモバイルバッテリの機内持ち込みルール（100Wh以下なら原則持ち込み可）に変更はない。ナトリウムイオン製品のみが新たに規制対象となった点を改めて確認しておきたい。 筆者の見解 今回の件は、技術の革新と規制の整合性というテーマを浮き彫りにしている。 エレコムのナトリウムイオンバッテリが「発火しにくい」という特性を持つことは技術的な事実だ。にもかかわらず規制の網がかかったのは、安全性の検証・認証体制が電池技術の進化スピードに追いついていない構造的な問題を示している。国際航空規制は原則として実績ある技術を前提に設計されており、新技術は安全性が広く証明されるまで「グレーゾーン」か「禁止」に分類されやすい。これは技術側の問題というより、制度設計の問題だ。 気になるのは、「安全性が高い」という訴求が主要な購買動機になっていた点だ。旅行・出張ユーザーが「機内に持ち込める安全なバッテリ」として選んでいたとすれば、今回の禁止措置は製品価値の大部分を失わせることになる。旧パッケージが市場に残り続ける切り替え期間中の混乱も避けられず、エレコムにとっても痛手は大きい。 一方で、ナトリウムイオン電池が有望な技術であることは変わらない。正面から航空安全の認証プロセスに取り組み、規制当局と連携して「機内持ち込み可」という価値を取り戻す道を期待したい。禁止で終わらせるのではなく、安全に使える仕組みを整える——それが技術者としても消費者としても望ましい着地点だろう。 すでに購入済みの方は、出発前に必ずバッグの中身を確認してほしい。 関連製品リンク エレコム モバイルバッテリー 9000mAh 45W ナトリウムイオン電池 ブラック EC-C27LBK エレコム モバイルバッテリー DE-C55L-9000BK 9000mAh 45W ナトリウムイオン電池 ...

米連邦取引委員会（FTC）が2026年4月に公表した新報告書によると、2025年にソーシャルメディア経由の詐欺で米国人が失った金額は21億ドル（約3,000億円）にのぼり、2020年比でじつに8倍超の急増を記録した。Tom’s Guideが詳報したこの数字は、SNS詐欺がもはや「特定層が注意すべき問題」から「社会インフラ全体のリスク」へと変質しつつあることを如実に示している。 FTC報告書が示す3大詐欺の構造 投資詐欺（被害額：約11億ドル） FTCのデータでは、SNS詐欺被害総額のうち11億ドルが偽投資案件によるものだった。広告や投稿で「投資の極意を教える」と誘い込み、「友好的なアドバイザー」を装った詐欺師や、「成功した投資家」ばかりが集まる偽グループへ誘導する手口が横行した。実態のない投資プログラムに金を注ぎ込ませる、古典的かつ精巧な構造だ。 ショッピング詐欺（報告者の40%が経験） SNS広告を経由して衣類・化粧品・カーパーツ・ペットに至るまで多岐にわたる商品を注文したものの、商品が届かないか情報を搾取される被害が続出。有名ブランドの大幅割引を謳うフィッシングサイトも数多く確認されており、ランディングページの見た目のクオリティが上がっていることも被害拡大の一因とされる。 ロマンス詐欺（報告者の60%がSNS起点） 金銭的な被害を報告した人のうち60%がSNSで知り合った相手から被害を受けたと回答。詐欺師はターゲットのプロフィールを分析し、好みや関心に合わせたペルソナを作り込む。親密な関係を築いた後に「緊急事態」を演出して送金させる手口は変わらないが、AIを活用したプロフィール生成・会話生成の精度向上が背景にあると推察される。 プラットフォーム別の被害規模 FTCの報告では、Metaが運営するプラットフォームが被害の中心を占めた。 Facebook：詐欺起点として約7億9,400万ドルの被害 WhatsApp・Instagram：合計約6億2,900万ドル（FTCは「遠く離れた2位・3位」と表現） FTCは「2025年において、Facebook単独での詐欺被害額は、テキストや電子メール詐欺の合計を上回った」と指摘。プラットフォームの広告エコシステムと詐欺の親和性の高さが改めて浮き彫りになった形だ。 FTCが推奨する自衛策 FTCはレポートの中で、以下の具体的な対策を呼びかけている。 SNS経由での投資判断を絶対に行わない——特にパブリックアカウントを運用している場合は詐欺師のターゲットになりやすい プライバシー設定を見直す——投稿・連絡先の公開範囲を最小化し、詐欺師が参照できる情報を減らす オンライン広告で商品を購入する前に検索する——企業名＋「詐欺」「苦情」で必ず確認する 身元情報保護サービスやウイルス対策ソフトを活用する——被害発生後のリカバリーにも有効 日本市場での注目点 日本でも状況は対岸の火事ではない。国民生活センターや警察庁の統計でも、SNS型投資詐欺・ロマンス詐欺の被害額は年々増加しており、2024年には過去最高水準を更新している。特にMeta系プラットフォームの広告から誘導される投資詐欺は日本でも多発しており、構造は米国のFTC報告書とほぼ一致する。 日本語に巧みな詐欺グループの参入や、生成AIを活用した自然な日本語テキスト生成の容易化を背景に、今後さらなる被害拡大が懸念される。プラットフォーム側のモデレーション強化に期待する一方、ユーザー側のリテラシー向上が現実的な第一防衛線となる。 筆者の見解 今回のFTCデータが示す最も重要な示唆は、「知識があれば防げる」という前提が崩れ始めているという点だ。ロマンス詐欺の60%がSNS起点、投資詐欺でAI生成の偽グループが動員されている現状は、「怪しいと感じる力」だけでは不十分になってきていることを意味する。 FTCが推奨する「プライバシー設定の見直し」と「購入前の企業名検索」は今すぐ実践できる対策として有効だが、より本質的にはプラットフォーム側が詐欺広告を出稿させない仕組みの整備が急務だ。個別のユーザーに防御の全責任を負わせるアプローチは、悪意ある行為者がAIでスケールしている現在の非対称な戦いには対応できない。 「禁止ではなく安全に使える仕組みを」という観点でいえば、SNSプラットフォームが本来の機能を維持しながら詐欺を構造的に排除できるかが問われている。8倍超という急増カーブを見れば、現状のモデレーションがまったく追いついていないことは明らかで、規制当局と事業者の双方にとって待ったなしの課題といえる。 出典: この記事は Social media scams cost Americans more than $2.1 billion last year, according to the FTC の内容をもとに、筆者の見解を加えて独自に執筆したものです。

中国のAIスタートアップMiniMaxが、229億パラメーターのMixture of Experts（MoE）モデル「M2.7」をオープンソースで公開した。このモデルが業界で注目を集めているのは、スペックの大きさだけではない。モデル自身が失敗を分析し、100回以上の反復ループを経てコードを自律修正する「自己進化」機構——その設計思想こそが、今後のAIエージェント開発に大きな示唆を与えている。 M2.7の基本スペック：MoEアーキテクチャとは M2.7はMixture of Experts（MoE）アーキテクチャを採用した大規模モデルだ。MoEとは、推論時に全229Bパラメーターを起動せず、入力の性質に応じて必要な「エキスパートモジュール」のみをアクティブにする設計で、計算コストを抑えながら高い表現力を実現できる。 コーディングエージェントの実用的評価指標として定着しつつあるSWE-Proベンチマークでは**56.22%**を達成。現時点のオープンソースモデルとして上位水準に位置する数字だ。 「自己進化」の仕組み：ループが全てを変える M2.7の本質は自己進化メカニズムにある。従来のLLMは、学習データで訓練後にパラメーターが固定される。M2.7はそこに踏み込んだ。 そのプロセスは以下のとおりだ： モデルがコーディングタスクを実行する 実行結果を自ら評価し、失敗パターンを分析する 修正案を生成して再実行する このループを100回以上繰り返す この反復を通じて、初期状態から30%の性能向上を自律的に達成したとMiniMaxは主張している。 重要なのはループ構造そのものだ。単発の「質問→回答」ではなく、エージェントが自律的に判断・実行・検証を繰り返すアーキテクチャ——これがAIエージェントの本質的な進化方向だと筆者は考えている。 オープンソース公開が意味するもの MiniMaxがM2.7をオープンソースで公開した点も見逃せない。 これにより日本のエンジニアにとっては： ローカル環境での高性能コーディングエージェント構築が現実的になる 自社データでのファインチューニングが可能になる APIコストを抑えた自律エージェントの実装ができる 229Bモデルの実行にはH100クラスのGPUが必要になるが、GGUF形式などの量子化技術を組み合わせることで推論コストを下げる工夫も進んでいる。プライバシー上の制約からクラウドAPIが使えない企業環境では、こうしたオープンソースモデルの選択肢は実用上の重要な切り札になる。 実務への影響 ループ設計のノウハウを今から積む M2.7の自己進化機構が示す通り、これからのAIシステムは反復ループによる自律改善が競争力の源泉になる。エージェントが自分で試行・評価・修正を繰り返すループを設計できるかどうかが、エンジニアの腕の見せ所だ。 今からループ型エージェント設計のノウハウを積んでおくことが、1〜2年後の実務で大きな差を生む。 SWE-Proベンチマークを評価軸として活用する 自社でAIコーディングツールを選定・評価する際は、SWE-bench系の指標が実用に近い判断材料になる。M2.7が56.22%を達成したことは、オープンソースモデルのコーディング性能が実用水準に確実に近づいていることを示している。 クラウドAPIへの一極依存を見直すタイミング 「高性能なAIは高価なクラウドAPIでしか使えない」という前提は、もはや成立しない。日本企業も、内製ツールのアーキテクチャ設計においてオープンソースモデルを本格的な選択肢として検討する段階に来ている。 筆者の見解 M2.7が体現する「自己進化ループ」は、AIエージェント設計の本質を突いていると思う。 AIが真の価値を発揮するのは、単発の質問に答えるときではない。目標を与えられ、自律的に試行・評価・修正を繰り返し、最終的に成果を出す——そのループを設計できるかどうかだ。M2.7はそのループをモデルの学習フェーズ自体に組み込んだ点が革新的であり、「自律エージェントとはどうあるべきか」というアーキテクチャの問いへの一つの回答でもある。 一方で、中国発オープンソースモデルの台頭はグローバルなAI競争の構図を急速に変えつつある。コスト面でも性能面でも、選択肢の幅は広がる一方だ。日本の現場でも、特定のプロプライエタリAPIに依存した設計を漫然と続けるのではなく、ループ型エージェントの思想を軸に据えた設計を真剣に検討する時期に来ていると感じる。 ローカルで動く自律エージェントが実用普及する未来は、多くの人が想定するより早くやってくる。そのときに備えて、ループ型エージェントの設計思想を今から自分のものにしておくことを強くお勧めしたい。 出典: この記事は MiniMax Just Open-Sourced M2.7 (The AI Model That Trains Itself) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコーディング支援の世界に、また注目すべき選択肢が加わった。Alibabaの研究チームが2026年4月27日にリリースしたQwen3-Coder-Nextは、総800億パラメーターを持ちながら、推論時に動作するパラメーターはわずか30億という「Mixture of Experts（MoE）」アーキテクチャを採用。従来比10倍のスループットを実現し、Apache 2.0ライセンスで公開された。単なる性能向上にとどまらず、エージェント的なコーディング支援に特化した設計思想が技術的な興味を引く。 MoEアーキテクチャが実現する「効率の革命」 Qwen3-Coder-Nextの最大の特徴は、Mixture of Experts（MoE）と呼ばれるアーキテクチャだ。総パラメーター数は80B（800億）だが、推論時に実際に動作するのは3B（30億）のみ。これにより、従来の密なモデル（Dense Model）と比べてスループットが約10倍に向上している。 MoEの仕組みを簡単に説明すると、モデル内部に複数の「専門家（エキスパート）」ネットワークを持ち、入力に応じて必要なエキスパートだけを選択して動作させる。すべての料理人を同時に働かせるのではなく、その料理に最適な担当者だけをアサインするイメージだ。GPUメモリの効率的な活用と高速推論が両立でき、運用コストの観点でも大きな利点がある。 GitHubのリアルなPRデータで「エージェント的訓練」 もう一つの注目点が訓練データの質だ。GitHubの実際のプルリクエスト（PR）データ80万件を用いて、エージェント的な訓練（Agentic Training）を施している。 単なるコード補完ではなく、リポジトリ全体の文脈を理解し、PRレビュー・修正・コミットといった一連の作業フローを学習させている点が従来のコーディングモデルとの違いだ。「コード1行を書く」ではなく「PRを通す」という粒度で能力を鍛えている。この設計方針は、自律的にタスクをこなすエージェント用途との相性を意識したものだ。 Apache 2.0ライセンスの意味——商用利用も自社ホスティングも可能 Apache 2.0ライセンスで公開されている点は実務観点から見逃せない。商用利用が許可されているため、自社製品への組み込みやAPIサービスとしての提供も法的に問題ない。 自社インフラ上でモデルをホスティングすれば、ソースコードが外部サービスに送信されないため、機密性の高い社内プロジェクトにも適用しやすい。コード系AIツールに対してセキュリティポリシー上の制約を抱える日本企業にとって、この点は重要な評価軸となる。 実務への影響——日本のエンジニアが押さえるべきポイント セルフホスティングの現実的な選択肢として 推論時のアクティブパラメーターが3Bという規模は、A100/H100クラスのGPUがあれば自社サーバーでの運用が現実的な範囲だ。クラウドGPUインスタンス（Azure NCシリーズ等）を使えば、従量課金でのホスティングも検討できる。 CI/CDパイプラインへの統合を見据えて GitHubのPRデータで訓練されているということは、コードレビューの自動化やPRの品質チェックとの相性が良い。既存のCI/CDパイプラインに組み込んでコードレビューを補完する用途は、比較的早期に実現できるユースケースだ。 まずはHugging Faceで試す Apache 2.0で公開されているため、Hugging Face上からモデルウェイトをダウンロードしてローカル環境での検証が可能だ。自社の実際のコードベースでどの程度の品質が出るか、小規模な実験から始めるのが現実的なアプローチだ。 筆者の見解 MoEアーキテクチャが今後のAIモデル設計の主流になりつつあることは、もはや疑いようがない。「大きければ良い」という時代から「効率が正義」という時代へのシフトは、実務において非常に重要な意味を持つ。自社で運用可能な規模のモデルが商業品質に近づくことで、AIの「内製化」という選択肢が現実のものになってくる。 また、このモデルがリポジトリ単位でのタスク理解を前提に訓練されている点は、コーディングAIの設計思想の進化を示している。「1行補完」から「PR単位での自律作業」へという方向性は、筆者がずっと重要だと考えてきたエージェント的な動作モデルと一致する。単発の指示に応答するだけでなく、目的を理解して自律的にタスクを進める能力こそが、AIの実務価値を大きく左右する。 オープンソースのエコシステムがここまで成熟してきたことは、選択肢の多様化という意味で健全な状況だ。特定のプロバイダーに依存しない構成を検討できる環境が整いつつある。各組織が自分たちのセキュリティポリシーや運用コストの観点から最適な選択ができる時代に近づいている。 実際に試してみることがすべてに優先する。スペックシートで判断するより、自分のプロジェクトのコードで動かしてみる——それが今一番正しい行動だ。 出典: この記事は Qwen3-Coder-Next offers vibe coders a powerful open source, ultra-sparse model with 10x higher throughput for repo tasks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azure AI Foundryが2026年4月、強化学習ファインチューニング（RFT: Reinforcement Fine-Tuning）に関する3つの重要なアップデートを発表した。o4-miniのグローバルトレーニング対応、GPT-4.1を活用した新しいグレーダー機能、そしてRFTベストプラクティスガイドの整備——企業が独自の専門モデルをより低コスト・高品質で開発できる環境が着実に整いつつある。 強化学習ファインチューニング（RFT）とは何か RFTは、従来の教師あり学習（SFT）とは異なる手法でモデルを特化させる技術だ。正解データのペアを大量に用意するのではなく、モデルの出力に「報酬シグナル」を与えて強化学習で最適化する。コーディング、数学的推論、法律文書のレビューなど、「答えの質を自動評価できる」タスクに特に威力を発揮する。 企業が自社業務に特化したモデルを作る際、教師データの収集・ラベリングコストがボトルネックになることが多い。RFTはそのコストを大幅に削減できるため、エンタープライズAI活用における重要な技術として注目度が高まっている。 3つのアップデートの内容 1. o4-miniのグローバルトレーニング——12リージョン以上で低単価提供 o4-miniのRFTトレーニングが、世界12リージョン以上で利用可能になった。より低いトークン単価での提供が特徴で、本番運用規模のトレーニングをコスト効率よく実行できる。アジアパシフィックリージョンでの提供が広がることは、データレジデンシーや遅延要件を持つ日本企業にとって実用上の大きな意味を持つ。 2. GPT-4.1グレーダーによる報酬シグナルの強化 RFTの要となる「報酬モデル（グレーダー）」にGPT-4.1が利用できるようになった。グレーダーはモデルの出力を評価して報酬シグナルを生成する役割を担う。GPT-4.1はコンテキスト長と指示追従性能が向上しているため、長文の品質評価や構造化出力の正確性チェックなど、複雑な評価基準を持つ業務タスクにおいてより精細な評価が可能になる。 3. RFTベストプラクティスガイドの整備 「どうやって使えばいいかわからない」という声に応える形で、包括的なベストプラクティスガイドが追加された。専門モデルをより速くリリースするための知見が整理されており、RFTを初めて試す開発者の入門ハードルが下がった。 Foundryエコシステムの急速な充実 RFTと並行して、Foundry全体のエコシステムも急速に整備されている。注目すべき動きをいくつか挙げる。 Toolbox（パブリックプレビュー）: エージェントが使うツールを一元管理し、異なるフレームワーク・ランタイム間での重複実装と認証情報の散乱を排除 Microsoft Agent Framework v1.0: 本番グレードのエージェント開発フレームワークの正式版がリリース Foundry Agent Serviceのホスト型エージェント: セキュアかつスケーラブルなエージェント実行環境がプレビューで提供 Foundry Local GA: オンデバイス推論が正式公開。ネット接続なし・トークン課金なしで推論を実行可能 実務への影響 エンジニアへ: RFTの実用化を検討する際、まず「報酬関数を定義できるか」から考えるとよい。「この出力は良い/悪い」を自動評価できるタスクかどうかがRFT活用の条件だ。コード生成（テストが通るか）、構造化データ抽出（スキーマへの準拠率）、数値計算（答えの正誤）などが典型的なユースケースになる。 IT管理者へ: Toolboxの一元管理機能は、複数のエージェントを運用している組織に特に刺さる。「認証情報をエージェントごとに埋め込んで管理が散乱している」という状況を解消するための正しいアーキテクチャが、プラットフォーム側から提供された形だ。また、Foundry Agent Serviceのプライベートネットワーキング対応により、Azure VNet内にエージェントのトラフィックを閉じ込めたい組織がエンタープライズセキュリティポリシーと整合しながら本番投入できる選択肢が増えた。 筆者の見解 Microsoft Foundryは、AIプラットフォームとして確実に実用レベルに近づいていると感じる。RFTの低コスト化、ツール管理の一元化、本番向けエージェント実行環境の整備——これらは「なんとなく試してみる」フェーズを超えて、業務に組み込むための基盤が整ってきたことを示している。 Foundryの本質的な強みは、AIモデルそのものの最前線を争うことではなく、「AIを組織の中で安全に動かし続けるプラットフォーム」を提供することにある。Microsoft Entra IDとの認証統合、Azureプライベートネットワーキング、組織のガバナンスポリシーとの整合——これらはMicrosoftが長年培ってきた強みであり、他が簡単に追随できる領域ではない。 筆者が特に注目しているのはToolboxだ。エージェントが組織内で増殖するにつれて、ツールの認証・認可をどう管理するかが実務上の最大の頭痛の種になる。Non-Human Identities（NHI）管理と直結するこの課題に、プラットフォームとして正面から答えを出してきたことは評価したい。エージェントを「作れる」だけでなく「安全に運用できる」仕組みを整えているかどうかが、企業導入の成否を分ける。 RFT自体はまだ玄人向けの技術ではあるが、ベストプラクティスガイドの整備は現場エンジニアが実践できる土台を着実に広げていく取り組みだ。今すぐ全社展開するのではなく、「報酬関数を定義しやすいタスク」からパイロット的に試してみる価値はある。Foundryが真に評価されるのは、個々のモデルの性能よりも、組織全体でAIを安全・効率的に動かし続けられる仕組みを提供できるかどうかだ——その方向性は、間違っていないと思っている。 出典: この記事は Microsoft Foundry Blog — Reinforcement Fine-Tuning Updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。

アクセンチュアがMicrosoft 365 Copilotを全従業員74万3,000人に展開したと発表した。ロールアウトを開始した2023年8月から約3年で、グローバル120カ国に展開するコンサルティング大手の全社員がAIアシスタントを使う環境が整ったことになる。Microsoftが公式に認めた史上最大規模のCopilot企業導入事例だ。 驚異の数字——何が本当に起きたのか 発表された数値は印象的だ。 月次アクティブ利用率：89%（約20万人の調査ベース） 97%の従業員が定型業務を最大15倍速く完了できると回答 53%増加した「生産性に顕著な改善を感じた」という回答割合 **84%**が「ツールが消えたら深刻に困る」と回答 数字だけ見ると理想的な展開事例だ。ただし注目すべきは、この数値が「ライセンスを配布しただけ」で得られたものではないという点だ。 成功の鍵は「段階的展開」と「役割別カスタマイズ」 アクセンチュアのCIOであるトニー・ルラリス氏が強調したのは、展開プロセスへの徹底的な投資だ。 まず2023年8月に数百名のシニアリーダーへの限定テストから始め、数カ月で2万人規模に拡大。全社展開にあたっては以下の仕組みを構築した。 シニアリーダー向け1on1トレーニング: 「どう使うか」ではなく「どう価値を出すか」を具体的に示す Viva Engageを活用した社内ナレッジシェア: 成功事例を横展開し、自己実験を促進 部門ごとの活用ブループリント作成: 一律の使い方を押し付けず、職種ごとの最適解を定義 特に注目すべきは「一律メッセージは通用しない」という教訓だ。マーケティング部門ではブランドコンシステンシーチェックと新コンセプトのドラフト作成に活用。営業部門では、MicrosoftとのJV「Avanade」が開発したD3ツールを通じてCopilotが8-K・10-Kレポートを集約分析し、平均43%多くの商談機会創出に貢献したという。 日本企業にとっての現実的な教訓 このスケールのロールアウトを、日本企業がそのまま真似できるかというと、正直難しい。アクセンチュアは自社がコンサル会社であることを活かし、チェンジマネジメントを自前で設計・実行できた。変革管理の専門家が社内にいる強みだ。 とはいえ、以下の教訓は規模を問わず活用できる。 ライセンス配布≠AI活用: 購入した翌日から成果が出るツールではない。使い方を教える仕組みが必要 成功事例の横展開が最大の推進力: 研修よりも「隣の人が使ってうまくいった」という体験の共有が効く リーダーが使っていないと広まらない: シニアリーダーへの先行展開は必須。リーダーが使わないツールは現場も使わない 部門別のユースケースを作れ: 「便利そう」ではなく「この業務のこの部分に使う」まで落とし込まないと定着しない 筆者の見解 74万人への展開という数字は確かにインパクトがある。ただ、この事例を「Copilotはすごい」という文脈だけで読むのは少しもったいない。 注目すべきは、これだけの成果を出すために、アクセンチュアがどれほど巨大な投資をしたかという点だ。チェンジマネジメント、データガバナンスの再設計、アクセス制御の整備、部門別のブループリント作成——これらすべてがセットになって初めてあの数字が出た。 「ライセンスさえ買えばDX完了」という発想が今も日本のIT現場に根強くある中で、アクセンチュアの事例はむしろ正反対のメッセージを発信している。ツールの価値は、それを使いこなすための仕組みへの投資に比例する。 CopilotはTeams議事録、Outlookの要約、会議の文字起こしといった定型業務において安定した価値を提供できる領域で実績を積み始めている。一方で、より高度な分析・創造的タスクには、M365エコシステムの内側だけに閉じないアーキテクチャを並行して検討する価値もある。アクセンチュアの事例はCopilotの可能性を示すと同時に、AI活用の本質が「ライセンス管理ではなく業務変革」であることを改めて教えてくれる。 Copilotが今後どんな進化を見せるか。実力はある。あとはその実力に見合った、ユーザーが「使い続けたい」と感じられるプロダクトへの磨き込みに期待したい。 出典: この記事は Accenture to roll out Copilot to all 743,000 employees in boost for Microsoft の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月、OneDriveの同期クライアントが静かに、しかし確実に変わる。削除されたクラウドファイルがPCのごみ箱に自動コピーされる現在の挙動が廃止され、サイトのごみ箱のみで管理されるシンプルな仕組みへ移行する。強制ロールアウトなので管理者の選択肢はないが、これは「知らずに困る」より「知っていれば得をする」変更だ。 現状の問題：ごみ箱が2か所存在するカオス SharePoint OnlineやOneDrive for Businessのドキュメントライブラリからファイルが削除されると、現在の同期クライアントはローカルに同期されていたコピーをPCのごみ箱（macOSではTrash）に移動する。つまり、削除されたファイルは「サイトのごみ箱」と「PCのごみ箱」の2か所に存在するという、直感に反した状態になっていた。 さらに問題をこじらせるのが、サイトのごみ箱からファイルを復元しても、PC側のコピーはそのまま孤立した状態で残り続けること。サーバーとの接続が切れた「幽霊ファイル」として残り、ユーザーを混乱させてきた。ヘルプデスクに「ファイルが消えた」と問い合わせが来て、調べてみたらサイトのごみ箱には存在するのにPCのごみ箱にも別コピーがある——こういう事例に心当たりのある管理者も多いだろう。 5月以降の新しい動作 Microsoftのメッセージセンター（MC1269861、2026年4月3日告知）に記載された変更は明快だ。クラウド側でファイルが削除されたとき、OneDrive同期クライアントはローカルコピーをPCのごみ箱に移動する処理をやめる。代わりに、ローカルフォルダから単純に削除するだけになる。 削除されたファイルの「権威あるコピー」はサイトのごみ箱のみに一本化される。復元が必要なときは、SharePoint/OneDriveのサイトのごみ箱だけを確認すればいい。シンプルだ。 混乱しやすい2つの例外 この変更で影響を受けない重要なケースが2つある。 Files On-Demand（オンデマンドファイル）は対象外。 ローカルに実体を持たず、アクセス時にダウンロードする方式のため、同期クライアントが処理するローカルコピー自体が存在しない。この変更は無関係だ。 ユーザーがローカルコピーを手動削除する場合は従来通り。 ユーザーがローカルファイルをごみ箱に送ると、OSがPCのごみ箱に移動し、OneDrive同期クライアントがサーバー側をサイトのごみ箱に移動する。この動作は変わらない。 今回変わるのは「クラウド側でファイルが削除されたとき、ローカルコピーをどう処理するか」という点だけだ。 実務への影響 IT管理者へ： この変更はテナント設定でブロックできない。展開は2026年5月初旬から始まり、5月末までに全テナントへ完了予定だ。事前に社内ユーザーへのアナウンスを検討してほしい。特に「削除したファイルをPCのごみ箱で探す」習慣が定着しているユーザーがいる環境では、説明なしに「ファイルが消えた」問い合わせが増える恐れがある。 ヘルプデスク・エンジニアへ： ファイル復元の問い合わせ対応がシンプルになる。今後は「SharePointサイトのごみ箱を確認してください」の一言で完結する。PCのごみ箱とサイトのごみ箱の両方を確認させる二度手間がなくなるため、サポートフローの見直しを検討する好機だ。 大規模ドキュメントライブラリを抱える組織へ： Microsoftは同期パフォーマンスの向上も明言している。ファイル数が多いライブラリほど削除オペレーションの頻度が高く、ローカルコピーの移動処理が不要になることで同期クライアントの負荷が軽減される。体感できる改善があるかは環境次第だが、期待していい変更だ。 筆者の見解 OneDrive同期クライアントは、Microsoft 365の中で「本当に地道に良くなった」プロダクトのひとつだと評価している。2020年の差分同期（Differential Sync）導入以降、着実に改善を重ねてきた実績がある。今回の変更もその延長線上にあり、方向性は正しい。 「ごみ箱が2か所に分散する」という挙動は、技術的な経緯はわかっても、エンドユーザー視点では混乱の種にしかならなかった。「正しいコピーはどこか」という問いに対して「1か所だけ」と言い切れる設計に移行することは、シンプルに正解だ。 管理者がブロックできない強制ロールアウトである点は賛否あるかもしれないが、ユーザーの混乱を生む根本的な問題を直す変更であれば、設定オプションを増やすより「デフォルトで正しく動く」ほうがずっといい。設定項目が増えるほど、知らない管理者が損をする世界になる。 「禁止で対処するより、正しく安全に使える仕組みを整える」――IT管理の本筋はそこにある。今回の変更はその哲学と一致している。OneDriveがこういう地道な改善を続けている点は、素直に評価したい。 出典: この記事は OneDrive Sync Client Changes How It Processes Deleted Files の内容をもとに、筆者の見解を加えて独自に執筆したものです。

PC Watchの「やじうまPC Watch」コーナー（劉 尭氏、2026年4月27日付）が、驚異的なDIYプロジェクトを紹介している。YouTuber「Dr.Semiconductor」が自宅の裏庭にある納屋をクラス100のクリーンルームに改造し、そこでDRAMを製造したという動画を4月21日に公開した。 なぜこの取り組みが注目されるのか このプロジェクトの出発点は、現在進行中のDRAM価格高騰だ。生成AIブームによる爆発的な需要増に対し、DRAM市場はMicron・Samsung・SK hynixの3社による寡占体制が続いており、新規工場建設には数十億ドル規模の投資と数年の期間が必要なため、供給不足がすぐには解消されない構造的な問題がある。 「ならば自分で作る」というDr.Semiconductor氏の発想は、エンジニアリング的アプローチとして非常に示唆に富む。通常、半導体製造は巨大なファブが必要とされるが、個人が限られた設備で実際の製造プロセスを再現したことは、教育的・技術的な意義が極めて高い。 クリーンルームの構築と製造プロセス PC Watchの紹介によると、Dr.Semiconductor氏は約2カ月前に納屋のクリーンルーム化動画を公開しており、水性エポキシコーティングによる壁面の粒子遮断とHEPAフィルタシステムの導入によってクラス100（1立方フィートあたり0.5μm以上の粒子が100個以下）を実現した。 DRAMの製造プロセスも本格的だ。シリコンウェハの洗浄・1,100℃での酸化膜形成から始まり、紫外線露光によるフォトリソグラフィ、ドライエッチング、有機物を徹底除去する「ピラニア洗浄」、950℃での20nm薄膜ゲート酸化膜形成、そしてアルゴンガスを使ったアルミニウム蒸着によるゲート・電気接点・キャパシタ形成まで、商業DRAMと同等の基本工程を踏んでいる。 海外レビューのポイント：達成できたこととこれからの課題 PC Watchの記事が伝えるテスト結果は以下の通りだ。 成果として確認された点: ゲート電圧による電流出力レベルの制御を確認 最大12.3ピコファラドという理論値に近い静電容量を実現 数百nsでのキャパシタ急速充電（3Vまで）に成功 残存する技術的課題: ソースとドレインの距離が短いことによる「パンチスルー」効果が発生し、高電圧での電流飽和が不完全 電荷保持時間が約2ms（市販DRAMの64ms以上と比べ大幅に短く、高頻度リフレッシュが必要） 同氏は「自宅でもDRAMを製造できることは証明できたが、DOOMのようなゲームを動かすには至っていない」とまとめており、今後はセルを連結してより大きなアレイを構築し、PCへの接続を目指すとしている。 日本市場での注目点 このプロジェクトは特定の市販製品ではないため購入はできないが、日本のエンジニアや半導体業界関係者にとって以下の点が興味深い。 DRAM価格動向の直撃: AI需要によるメモリ価格高騰は日本国内のサーバー・PC市場にも影響が及んでおり、DDR5メモリの価格高止まりがデータセンター投資コストを押し上げている 半導体人材育成への示唆: 日本でも半導体人材の育成が急務となっているが、製造工程を動画で可視化するこのアプローチは、次世代エンジニアへの技術継承コンテンツとして価値がある サプライチェーンリスクの再認識: 3社寡占が生む供給脆弱性は、AIインフラ投資を計画する企業が真剣に考慮すべきリスク要因だ 筆者の見解 AI需要がDRAM価格を押し上げているという現実は、今まさに肌で感じているところだ。大規模なGPUクラスターにはHBM（高帯域幅メモリ）が不可欠で、その需要がDRAM全体の供給を逼迫させている。この構造的な問題に対して「じゃあ自分で作る」と踏み出したDr.Semiconductor氏の行動力には素直に敬服する。 技術的には、電荷保持2msという結果は市販品の64ms以上と比較すると大きなギャップがある。しかしそれは当然だ。現代のDRAMが到達した精度は、何十年もの研究開発と数十億ドルの設備投資の産物であり、個人が納屋で同等の性能を出せたら逆に問題だろう。重要なのは「基本的なDRAMを作れた」という事実であり、商業プロセスの本質を個人規模で再現したことの意義は計り知れない。 「情報を追うより実際に手を動かして試してみる」——このYouTuberのアプローチはまさにそれを体現している。半導体製造という最も高い壁の一つに、手製の道具で真正面から挑んだこの姿勢は、エンジニアとして見習うべきものがある。 また、このプロジェクトが暗示するDRAMの3社寡占問題は、日本のIT業界にとっても他人事ではない。AIインフラへの投資計画を立てる際、サプライチェーンの脆弱性を織り込んでおくことは、今後ますます重要な視点になるだろう。 出典: この記事は 【やじうまPC Watch】DRAMが高いので自作。納屋にクリーンルームまで構築したYouTuber現る の内容をもとに、筆者の見解を加えて独自に執筆したものです。

欧州連合（EU）の欧州委員会が、GoogleのAndroid OSにおけるGemini AIの優遇措置を問題視し、第三者AIサービスへの開放を求める調査結果を公表した。Ars TechnicaのライターRyan Whitwam氏が2026年4月27日に報じている。欧州委員会は今夏にも正式な変更命令を出す可能性があり、業界が注目している。 なぜこの問題が注目されるのか Android端末を起動すると、GeminiはOSのシステムレベルで特権的な扱いを受けている。デフォルトメールアプリへのメール送信補助や写真共有など、Geminiを介してのみ実現できる体験が複数存在することが問題視されている。 DMA（デジタル市場法）は、Google・Apple・Meta・Amazonなど7社の巨大テック企業を「ゲートキーパー」に指定し、公正な競争環境を確保するための欧州の法律だ。2024年の本格施行以降、Googleはすでに検索選択画面の導入やPlay Storeでの代替決済許可など、複数の変更を実施している。AI分野への本格適用は今回が最大規模となる。 海外レポートのポイント：EUが求める具体的な変更 Ars TechnicaのRyan Whitwam氏の報告によると、欧州委員会が提案する変更は多岐にわたる。 開放が求められる主な機能 ホットワードやボタン操作による、サードパーティAIのシステム全体からの呼び出し AIツール起動時の画面コンテキストへのアクセス許可 代替AIシステムが利用できる標準的なAPIの整備 欧州委員会テック主権担当副委員長のHenna Virkkunen氏は声明で「相互運用性こそがAI技術の潜在能力を引き出す鍵だ。ユーザーは機能を犠牲にすることなく、自分のニーズや価値観に合ったAIサービスを自由に選べるようになるべきだ」と述べている。 Googleの強い反論 Googleのシニアコンペティションカウンセル、Claire Kelly氏は「この不当な介入により、センシティブなハードウェアやデバイス権限への強制アクセスが必要となり、ヨーロッパユーザーのプライバシーとセキュリティ保護を損なう」と反論している。端末メーカーがAIサービスをカスタマイズする自律性が失われる点も問題視する。 Ryan Whitwam氏が指摘するとおり、ChatGPTやGrokはすでにAndroid上でインストール可能だ。EUが問題視しているのは「インストールの可否」ではなく、「Geminiだけがシステム深部と連携できる非対称性」だ。この非対称性こそが規制の核心といえる。 日本市場での注目点 DMAは欧州域内にのみ適用される規制であり、日本市場への直接的な影響はない。ただし過去の事例を見ると、欧州向け対応がグローバルなAndroid仕様変更に波及するケースは珍しくない。今夏以降に欧州委員会が正式命令を出した場合、その内容次第では日本向けAndroid端末の仕様にも間接的な影響が及ぶ可能性がある。 AI選択の自由という観点では、日本の消費者・エンジニアにとっても決して他人事ではない論点だ。 筆者の見解 「AndroidにはGeminiしかない」という状況ではないものの、「GeminiとChatGPTが対等な条件で競える」状況でもなかったというのが実情だ。EUがこの非対称性に切り込んだことは、理解できる動きだと思う。 AIサービスを「自由に選んで、深く使える」環境を整えることはユーザー本位のあり方として筋が通っている。特定のAIサービスだけがシステムと深く連携できる環境では、ユーザーが他のサービスの真の価値を体験できないまま終わってしまう。 ただし、Googleが指摘するプライバシーとセキュリティの懸念は正当な側面もある。画面コンテキストへのアクセスや深いシステム統合を広く開放すれば、悪意あるアプリのリスクも現実的に高まる。「禁止ではなく、安全に使える仕組みを作る」という設計思想——適切なAPIと権限モデルの標準化——が問われることになるだろう。 この規制の結果が欧州のユーザー体験をどう変えるか、日本市場への波及はあるか。先行事例として注視する価値は十分ある。 出典: この記事は EU tells Google to open up AI on Android; Google says that’s “unwarranted intervention” の内容をもとに、筆者の見解を加えて独自に執筆したものです。