Tech News JP

採用プロセスへのAI活用が急速に広がる中、見落とされていたリスクが論文として可視化された。求職者が履歴書作成にLLMを使い、企業側が同じLLMでスクリーニングする——この「AI対AI」の構図が、人間の書いた応募書類を組織的に不利にする可能性が実証された。 何が明らかになったか Jiannan Xuら（2025年8月、arXiv）の研究チームは、大規模な対照実験を設計した。主要な商用・オープンソースLLM複数種を対象に、「同一モデルが生成した履歴書」「人間が書いた履歴書」「別モデルが生成した履歴書」をスクリーニングさせ、合否傾向を比較した。 結果は鮮明だった。 自己優先バイアスは67〜82% ——モデルは人間の書いた履歴書より自分が生成したものを一貫して高く評価した 同一LLM使用者の書類通過率は23〜60%高い ——24職種のシミュレーションで、採用側と同じモデルを使った応募者が等しい能力でも有意に有利だった 最も不利なのは営業・経理など業務系職種 ——技術系より文章表現の比重が高いポジションで格差が大きかった シンプルな介入で50%超の抑制が可能 ——モデルの自己認識能力を狙った介入で、バイアスを大幅に低減できることも示された なぜこのバイアスが生まれるのか LLMは学習データと生成パターンを持つ。自分の出力には「自分らしい語彙・文体・論理構造」が刻まれており、それを評価基準として読み込むと自然に高評価を与える傾向がある。いわば「自分の文章を採点したら甘くなる」という構造的な問題だ。 これは意図的な不正ではなく、モデルアーキテクチャに起因する特性であるため、プロンプトで「公平に評価してください」と指示するだけでは解消されない。 日本の現場への影響 日本では新卒一括採用・ES（エントリーシート）選考という独自の慣行がある。この文化とAIスクリーニングの組み合わせは、海外以上に問題をはらむ可能性がある。 採用担当者が今すぐ確認すべき点： スクリーニングに使うLLMと、求職者が使いやすいLLMが一致していないか確認する ——特定のAIサービスを社内ツールとして案内しているケースは要注意 ESや履歴書の評価基準を明文化する ——「LLMが書いたかどうか」ではなく「どの能力を評価するか」を先に定義すると、バイアスの影響を構造的に抑えられる 複数モデルを評価に組み合わせることを検討する ——単一モデルに一任せず、異なるモデルの評価を並走させて差異を見る方法は現実的な対策になる 定期的な「ヒューマンレビューのサンプリング」を仕組みとして組み込む ——AIスクリーニング後の書類をランダムに人間が再評価し、システム偏差を定点観測する 応募者の立場からは： 自分のESや職務経歴書にAIを使う場合、使うモデルを多様化しておくと特定モデル依存のリスクを分散できる（これは防衛策であり、「AI利用をやめろ」というメッセージではない） 公平性の枠組みを広げる必要性 AI倫理の議論はこれまで「性別・年齢・人種等の属性バイアス」に集中してきた。今回の研究が問うのは、それとは異なる次元の問題だ。「どのツールを使ったか」という選択が、能力と無関係に選考結果を左右するなら、これは新しいデジタルデバイドになりうる。 高価な有料LLMサービスを使えた応募者の方が選考を通りやすい——そういう構造が静かに形成される前に、採用基準の設計とAI選定の見直しが求められる。 筆者の見解 「禁止すれば解決する」という発想は、ここでも通じない。 すでに求職者はAIで履歴書を書いており、企業はAIでスクリーニングしている。この現実を否定するのではなく、「どう設計すれば公平に機能するか」を考えるフェーズに入っている。 この研究が示した「介入によって50%超のバイアス低減が可能」という知見は重要だ。問題は認識されており、技術的な解決策も存在する。あとはそれを実際の採用フローに実装できるかどうか、設計する側の意思次第だ。 もう一つ気になるのが、この問題の「見えにくさ」だ。採用の合否は個人の実力以外の要因が複合するため、バイアスが存在しても統計的に露出しにくい。今回のように大規模な対照実験を設計しなければ可視化できない類の問題だ。 AIを使った意思決定の仕組みを構築する際には、「使っている」だけでなく「どう使っているかを観測し続ける」仕掛けが不可欠だ。採用に限らず、コンテンツモデレーション・ローン審査・人事評価——LLMが評価する側と評価される側の両方に立つ場面では、今回の知見を意識した設計が求められる。 採用AIの公平性は、今後数年で規制と訴訟の焦点になる可能性がある。日本企業も「とりあえず使ってみた」から「説明責任を持って運用する」フェーズへの移行を、早めに進めた方がいい。 出典: この記事は AI Self-preferencing in Algorithmic Hiring: Empirical Evidence and Insights の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたか 2026年4月16日、VS Code の Git 拡張機能に静かな変更がマージされた。git.addAICoAuthor という設定のデフォルト値が "off" から "all" に切り替えられ、Copilot を一切使っていなくても、コミット時に自動で Co-authored-by: GitHub Copilot というトレーラー行が付与されるようになったのだ。 PR（#310226）には説明文すらなく、コミュニティの反応は苛烈だった。投稿から数日で 👎 が 372件に達し、賛成の 👍 はわずか 2件。GitHub の単一PRとしては異例のスコアだ。 技術的な問題点 「使っていないのに名前が入る」問題 git の Co-authored-by トレーラーはもともと、複数人で書いたコードを正直に記録するための仕組みだ。OSS コミュニティでは著作権の帰属を明確にするために使われ、企業の内部開発でも「誰が書いたか」の追跡に使われる。 デフォルト "all" は、Copilot を積極的に使ったかどうかに関わらず、VS Code を起動していれば Co-author として記録する可能性を意味する。たとえ自分でゼロから書いたコードでも、コミットには AI の名前が残る。 実装の不整合も指摘 Copilot によるコードレビューも、この PR の問題を正確に突いている。設定スキーマのデフォルトは "all" に変わったが、extensions/git/src/repository.ts 内のランタイムフォールバックは config.get('addAICoAuthor', 'off') のままだ。スキーマとランタイムが乖離しており、テスト環境などでは意図しない挙動が生じる可能性がある。 オプトアウト設計の本質的な問題 ソフトウェアのデフォルト設定はユーザーの同意を代理する。特にプライバシー・著作権・帰属に関わる設定で「デフォルト有効」を選ぶことは、「ユーザーは気づかなくていい」という設計思想の表明にほかならない。 実務への影響 日本の企業エンジニアが確認すべきこと 1. 設定の明示的な管理 settings.json または devcontainer.json に次を追加し、意図しない挙動を防ぐ。 出典: この記事は VS Code inserting ‘Co-Authored-by Copilot’ into commits regardless of usage の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MFAを導入しているから安全、という前提が通用しなくなりつつある。Azure環境を標的にした新たな攻撃手法「ConsentFix v3」がハッカーフォーラムで出回り始めた。従来の手口をさらに洗練させ、自動化と大規模展開を可能にしたこの攻撃は、Azureを利用する日本のIT管理者が今すぐ注目すべき脅威だ。 ConsentFix とは何か：v1からv3への進化 ConsentFixは、Microsoft AzureのOAuth2認証フローを悪用したフィッシング攻撃手法だ。その歴史は比較的新しい。 v1（2025年12月）: セキュリティ企業Push SecurityがClickFix派生の手法として公開。Azure CLIの正規ログインフローに乗じ、被害者にlocalhostのURLをコピー＆ペーストさせることでOAuth認証コードを盗む v2: セキュリティ研究者のJohn HammondがURLの取得をドラッグ＆ドロップに改良。操作の自然さが増し、被害者が疑問を感じにくい設計に v3（現在）: Pipedreamというサーバーレス統合プラットフォームを核にした自動化インフラを実装。攻撃の大規模展開が可能になった 最大の特徴は、多要素認証（MFA）を回避できる点にある。Microsoftの正規のOAuth認証フローそのものを利用するため、MFAを完了した後でも攻撃が成立する。 v3 の攻撃フロー：自動化が脅威を拡大する フェーズ1：ターゲット調査 まずAzure環境の存在を確認し、有効なテナントIDを検証する。次にLinkedInや公開情報から従業員の名前・役職・メールアドレスを収集し、精度の高いなりすましを準備する。 フェーズ2：攻撃インフラの構築 Outlook、Tutanota、Cloudflare、DocSend、Hunter.io、Pipedreamなど複数の無料サービスを組み合わせ、フィッシング・ホスティング・データ収集・流出の各機能を担う「分散型インフラ」を構築する。特にPipedreamは以下の三役を担う。 OAuth認証コードを受け取るWebhookエンドポイント コードをMicrosoftのAPIでリフレッシュトークンに即座に交換するオートメーションエンジン 奪取したトークンをリアルタイムで収集する中央管理システム フェーズ3：フィッシング実行 Cloudflare Pages上にMicrosoftのインターフェースを模倣したフィッシングページを展開。被害者をMicrosoftの正規ログインエンドポイントへリダイレクトし、MFAを含む通常の認証を完了させる。その後、localhostのURLに含まれるOAuth認証コードをフィッシングページに貼り付けるよう誘導する。 フィッシングメールはDocSend上のPDFに悪意あるリンクを埋め込む形式で、スパムフィルターをすり抜けるよう設計されている。収集した個人情報を活用したパーソナライズにより、被害者が不審に感じにくい仕上がりになっている点は特筆すべきだ。 フェーズ4：アカウント侵害 取得したトークンはSpecter Portalにインポートされ、メール、ファイル、その他のAzureサービスへのアクセスが可能になる。以降の認証は不要であり、侵害された状態が続く。 なぜMFAが無効化されるのか この攻撃の核心は、Microsoftのファーストパーティアプリへの暗黙の信頼を悪用する点にある。 AzureのOAuth2では、Azure CLIなどMicrosoft製の正規アプリは事前に信頼・同意が付与されており、ユーザーが追加の許可を与えなくても動作する仕組みになっている。攻撃者はこの「信頼済みアプリ」の仕組みに乗じるため、ユーザーが不審な権限要求に気づく機会がない。 さらに、FOCI（Family of Client IDs）——Microsoftアプリ間でリフレッシュトークンを共有する仕組み——が悪用されると、単一のトークン奪取が複数サービスへのアクセスに繋がるリスクがある。 実務への影響：管理者が今すぐ取るべき対策 ConsentFix v3は「MFAさえあれば安全」という前提を根底から崩す攻撃だ。日本のAzure管理者が取り組むべき対策を整理する。 検出・防御の強化 トークンバインディングの適用: 信頼済みデバイスへのトークンバインディングにより、奪取したトークンの別端末での利用を防ぐ 条件付きアクセスポリシーの多層化: デバイスコンプライアンス、場所、サインインリスクスコアを組み合わせた複合ポリシーを設定する Microsoft Sentinelによる異常検出: 「通常と異なる場所からのトークン使用」「短時間での複数サービス横断アクセス」等を検出するカスタムルールを実装する 特権管理の見直し JIT（Just-In-Time）アクセスの徹底: 常時アクセス権の付与は最小限に。必要な時だけ権限を付与するJITモデルへ移行することが、侵害時の影響範囲を大幅に縮小する PIM（Privileged Identity Management）の活用: Azure AD PIMで特権ロールの利用を時間制限・承認制にする リフレッシュトークンの有効期間短縮: 長寿命のトークンは侵害の持続を許すリスクがある。組織のポリシーを見直す ユーザー教育 localhostのURLを外部サービスに貼り付けることは、いかなる状況でも正当な操作ではないことを組織全体に周知する DocSend経由のPDF内リンクに対する警戒を徹底する 「Microsoftから来たっぽいメール」への過信をなくす意識づけが重要だ 筆者の見解 ConsentFix v3を見て改めて感じるのは、「今動いているから大丈夫」という考え方の根強さと、その危うさだ。MFAは確かに多くの攻撃を防いできた実績がある。しかし正規の認証フロー自体を武器に変えるこの手法の前では、MFAは通過点にすぎなくなる。 この攻撃が突いているのは、Microsoftのファーストパーティアプリへの暗黙の信頼という「設計上の構造的課題」だ。これはMicrosoftが長年かけて育ててきたエコシステムの裏返しでもあり、一朝一夕には変えられない部分だと理解している。だからこそ、管理者側でできることを積み重ねる姿勢が問われる。 ...

MicrosoftがEdgeブラウザの「シンプル化」方針を正式に宣言した。第一弾としてサイドバー機能の段階的廃止を開始——OutlookやBingなどをミニアプリとして固定表示できる人気機能が消えていく一方で、CopilotはサイドバーのままEdgeに残り続ける。「質の向上とコアユーザーへの対応を優先する」と語るサティア・ナデラCEOの言葉とともに、Edgeの設計思想が大きく転換しようとしている。 サイドバー廃止の概要 Microsoft Edgeのサイドバーは、OutlookやBing検索などのウェブアプリをブラウザ右端にミニアプリとして固定表示できる機能だ。ブラウジング中に別タブへ切り替えることなくメール確認やショッピングが行え、Chromiumベースの他ブラウザとの差別化要素のひとつとして機能してきた。 2026年5月現在、新しいアプリの追加はすでに停止されており、既存のピン留め済みアプリも「近い将来」段階的に削除される予定だ。公式サポートドキュメントには「Edgeをシンプルにしています（We’re simplifying Microsoft Edge）」という一文が明記されており、Microsoftが公式に「機能削減」を認めた初めてのケースとなる。 現時点ではMicrosoftアカウント（MSA）ユーザーから先行して適用が始まっており、企業向けアカウントへの展開スケジュールは未発表の段階だ。 Copilotだけが残る構図 注目すべきは、CopilotはサイドバーのままEdgeに残留するという点だ。 Microsoftのアラートには「Copilotは影響を受けない——これにより、Copilotをさらに改善することに集中できる」と明記されている。サイドバーという器は維持しつつ、OutlookやミニアプリのスロットをCopilot専用パネルに転換していくイメージだ。 「シンプル化」という言葉の裏に、Copilot中心のUI再設計が透けて見える。 Edgeは20四半期連続でシェア拡大——しかし「ファン離れ」が課題 Q3決算説明会でナデラCEOは「Windows、Xbox、Bing、Edgeにわたってファンを取り戻し、エンゲージメントを強化する基礎的な作業を進めている」と発言。EdgeはChromimuベースへの移行以来20四半期連続でシェアを伸ばしているというデータも示した。 ただし、シェアの伸長と「使いたいブラウザとして選ばれている」という評価は別物だ。サイドバー廃止のニュースに対してユーザーからの反発は大きく、「サイドバーがなくなるならEdgeを使わない」という声も多数寄せられている。数字は成長していても、愛着を持って選んでいるユーザーの声が届いていないならば、その成長の質が問われる。 実務への影響——日本のエンジニア・IT管理者が確認すべき3点 1. 企業向け展開スケジュールはまだ不明 現時点でMicrosoftは具体的な廃止日を明示していない。まずMSAユーザーから開始されており、業務利用（Entra ID管理下のアカウント）への適用時期を引き続き注視する必要がある。企業展開前に公式アナウンスが出る可能性は高いが、早めに情報を追っておくべきだ。 2. サイドバー活用フローの棚卸しを サイドバーにOutlookやTeams Webアプリをピン留めして業務フローを組んでいるユーザーは、代替手段の検討が必要になる。スプリットスクリーン機能（2ページ同時表示）が候補だが、使い勝手は異なる。影響範囲の把握を今のうちに行い、ユーザー教育の準備を進めておくと後手を踏まずに済む。 3. グループポリシー設定と実挙動の乖離を確認 企業環境ではEdgeのグループポリシーでUI要素を制御している場合がある。サイドバー廃止に伴い、既存ポリシー設定と実際のブラウザ挙動に乖離が生じないか、テスト環境での事前確認を強く推奨する。 筆者の見解 Edgeがここ数年でChromiumベースの主要ブラウザとして地位を固めたのは確かな事実だ。縦型タブ、サイドバー、スリープタブなど、他ブラウザに先行して実装してきた機能群が「乗り換えの理由」になっていた。 だから今回の「シンプル化」には、率直に言ってもったいないという感覚がある。せっかく積み上げてきた差別化要素の一部を自ら取り除いているからだ。「なぜEdgeを選ぶか」の答えを増やしていく方向ではなく、削ることとのトレードオフが生まれている点は痛い。 一方で、CopilotをEdgeの中核に据える戦略そのものを否定するつもりはない。AIアシスタントをブラウザに深く統合するコンセプトには合理性があるし、本気で磨けば本当に便利なツールに育つ可能性は十分ある。サイドバーをCopilot専用パネルとして再定義し直す、という読み方もできる。 ただ、「シンプル化」という言葉がユーザーの心に響くかどうかは、削った後に何が残り、それが日々の使い勝手をどう変えるかにかかっている。ナデラCEOは「コアユーザーにとことん向き合う」と言っている。Edgeには十分な実力があるし、正面から勝負できるブラウザだ——その力を使い切った姿を見せてほしい。 出典: この記事は Microsoft says it’ll simpilify Windows 11’s Edge browser by removing features like Sidebar, pledges to win back users の内容をもとに、筆者の見解を加えて独自に執筆したものです。

英国の国民保健サービス（NHS）が、これまで公開していたオープンソースリポジトリの大部分を非公開化する方針を示したと報告されている。世界有数の公共医療システムが培ってきたデジタル資産が、なぜ「鍵のかかった引き出し」に収められようとしているのか。その背景と、日本の公共セクターDXへの示唆を考える。 NHSとオープンソース——これまでの関係 NHSは英国国民に無償で医療を提供する巨大な公共機関だ。2010年代以降、NHS Digital（現在はNHS Englandに統合）を中心にデジタル変革を推進し、GitHubには診療予約システム、電子患者記録連携、APIゲートウェイなど多岐にわたるコードが公開されてきた。 オープンソース化の意義は複数あった。まず納税者への説明責任——公的資金で開発されたコードを国民がレビューできることは、ガバナンスの観点から正当性があった。次に開発コミュニティとの協力——外部の開発者がバグを発見・修正し、NHSの限られたエンジニアリングリソースを補完する効果があった。そして国際的な知見共有——NHSの実装はほかの国の医療システムにとっても参考となる先行事例だった。 なぜ今、非公開化なのか 今回の方針転換には複数の要因が絡んでいるとみられる。 第一に財政的プレッシャー。英国の公共機関は現在、厳しい財政制約下にある。オープンソースリポジトリの維持——Issue対応、セキュリティパッチの適用、ドキュメント整備——には専任のエンジニアリコストが必要だ。「公開しっぱなし」では却ってセキュリティリスクになる。管理できないなら閉じる、という判断はリソース制約の観点では合理的に映る。 第二にセキュリティレビューの強化。医療データに関連するシステムは、コードの公開がアタックサーフェスの増大につながるリスクをはらむ。近年、公共インフラへのサイバー攻撃が増加する中、「公開コードを解析してゼロデイを探す」攻撃者へのフィードポイントを減らす判断は理解できる。 第三に組織再編の影響。NHS Digitalの統合やNHSX廃止を経て、オープンソース戦略を推進してきた担当者や文化が失われた可能性がある。技術的な負債と組織的な記憶喪失が重なると、「ひとまず全部非公開」という消極的な選択肢が浮上しやすい。 オープンソースコミュニティへの影響 この決定に対し、オープンソースコミュニティからは懸念の声が上がっている。NHSのコードをベースに開発していた外部プロジェクトは参照先を失い、改善コントリビューションのルートも閉ざされる。「公共のために作られたものが、公共から見えなくなる」という矛盾は、デジタル公共財の議論において象徴的な事例となりうる。 ただし、全てのリポジトリが非公開になるわけではないとされており、重要度や依存関係を精査した上での段階的対応の可能性も残る。詳細の公式発表が待たれる状況だ。 実務への影響——日本のエンジニア・IT管理者へ 日本の文脈では、デジタル庁・自治体・医療機関のシステム開発において以下の点が参考になる。 オープンソース化は「公開して終わり」ではない: 公開後の維持管理コストを事前にバジェット化しなければ、NHSと同じ状況に陥る。「誰が、いつ、どのコストで維持するか」を最初に決めること。 セキュリティレビューの仕組みを組み込む: 公開リポジトリには定期的なシークレットスキャン、依存関係の脆弱性チェック、不要なリポジトリのアーカイブ化を標準プロセスとして組み込む。 ライセンスと依存関係の把握: 外部が依存しているリポジトリを突然非公開にすると、OSSエコシステム全体に影響を与える。段階的移行計画と十分な事前告知が不可欠だ。 「公開しない」という選択肢も戦略の一つ: 全てをオープンにすることが正解ではない。内部ユースケース特有のロジックや、セキュリティに直結するコンポーネントは非公開のまま管理するほうが賢明な場合もある。 筆者の見解 「オープンソースは善、クローズドは悪」という単純な二項対立に飛びつきたい気持ちはわかる。だが、これは組織のリソースと責任のバランスの問題だ。 公共機関がコードを公開することの価値は本物だ。透明性、再利用性、コミュニティとの協働——いずれも捨てがたい。だが「公開リポジトリを維持する専任チームがいない」状態で公開し続けることは、むしろリスクを積み増す行為になりうる。放置された公開リポジトリは、攻撃者にとってむしろ好都合だ。 私が気になるのは、こうした後退が「戦略的な判断」ではなく「予算削減の副作用」として起きているかもしれないという点だ。オープンソースへの投資を削ることは、短期的には節約に見えて、長期的には再開発コストや外部知見の喪失という形で跳ね返ってくる。 日本の公共DXを見ていても似た構造を感じる。オープン化の方針を掲げながら、維持のための人とお金の手当てが後回しになるケースは少なくない。NHSの今回の決断は、「公開すること」と「責任を持って運用すること」を切り離して考えてはいけないという教訓として、重く受け止めたい。 NHSがオープンソース文化を完全に手放したわけではないことを願う。正面から取り組む体力は、きっとまだあるはずだ。 出典: この記事は Is this the end? NHS is apparently shutting down most of its open source repos. Here’s why の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界中の学校・大学が授業管理に使う学習管理システム（LMS）の最大手、Instructure社が2026年5月、大規模なサイバー攻撃によるデータ侵害を公式に認めた。恐喝グループ「ShinyHunters」が犯行を主張しており、世界9,000校・2億7500万人分の個人情報と数十億件のプライベートメッセージが奪われたとされる。教育機関を狙ったサイバー攻撃としては、近年でも類を見ない規模だ。 Instructure社とCanvas LMSとは Instructureは米国拠点の教育テクノロジー企業で、同社のCanvas LMSは世界中の学校・大学・組織で採用されている。授業の課題管理、オンライン学習、成績管理を一元化するプラットフォームとして高等教育機関を中心に普及しており、日本でも導入している大学がある。SalesforceをCRMとして活用している機関も多く、今回の侵害の影響範囲は想像以上に広い可能性がある。 漏洩データの内容と現在の対応状況 Instructureの公式声明によると、今回露出が確認されている情報は以下の通りだ。 氏名・メールアドレス・学生ID ユーザー間のメッセージ（学生⇔教員、学生⇔学生） パスワード、生年月日、政府発行の識別番号、財務情報については現時点で漏洩の証拠が確認されていないとしているが、調査はまだ継続中だ。 ShinyHuntersはデータリークサイトで次のように主張している。 2億7500万人分の生徒・教員・スタッフのデータ 数十億件のプライベートメッセージ Salesforceインスタンスも侵害済み 約15,000機関にまたがり、北米・欧州・アジア太平洋地域を含む Instructureは脆弱性のパッチ適用、監視体制の強化、APIアプリケーションキーのローテーションを実施済みとのことで、既存顧客にはAPIアクセスの再認可が求められている。 ShinyHuntersという脅威アクターについて ShinyHuntersは2020年ごろから活動を続ける恐喝グループで、Ticketmaster（約5億6000万件）、Santander銀行、Snowflakeを利用する複数企業など、大規模侵害を繰り返してきた実績がある。主張の全てが事実とは限らないが、過去の行動パターンを見れば「単なるブラフ」と片付けられる相手ではない。 実務への影響——日本のIT担当者・教育機関管理者が今すぐすべきこと Canvas利用校は能動的な確認を: Instructureからの公式通知を待つだけでなく、管理コンソールで不審なAPIアクセスや認可済みアプリケーションの一覧を自主的に確認することを強く勧める。 メッセージ機能のリスク認識を改める: Canvas上の教員⇔学生間のメッセージには、成績に関する議論、個人的な事情の開示、相談内容など極めてセンシティブな情報が含まれることが多い。LMS上のメッセージが業務チャット同等のリスクを持つことを、改めてユーザーに周知すべきだ。 Salesforce連携環境は優先確認: ShinyHuntersはSalesforceインスタンスの侵害も主張している。CanvasとSalesforceを連携している機関は、OAuth認可状況と不審アクセスのログを直ちに確認すること。 APIキー更新の確認: Instructureがアプリケーションキーをローテーション済みとのことだが、自組織の連携システムがCanvasのAPIを呼び出している場合、新しいキーへの移行と旧キーの確実な無効化を確認する必要がある。 筆者の見解 今回の件で強く感じるのは、教育機関がサイバーセキュリティの「手薄なターゲット」として長らく扱われてきたという現実だ。病院や金融機関ほど規制も厳しくなく、セキュリティ予算は慢性的に不足しがちだ。しかし扱うデータは未成年者の個人情報、教員との機密なやりとり、そして学習歴全体に及ぶ。「最低限の個人情報保護法対応はしている」という姿勢では、実力ある攻撃者を前にして防ぎようがない。 とくに気になるのは「プライベートメッセージの流出」という側面だ。Canvas上のメッセージは「ちょっとしたやりとり」程度に認識されがちだが、そこには生徒の精神的な状況、成績不満、場合によっては教員への内部告発に近い内容まで含まれている。流出した情報は単純な「名前とメアド」ではなく、人間関係のコンテキストを含む重厚なデータセットだ。これが悪意ある第三者の手に渡ったとき何が起きるか、想像力を働かせてほしい。 Instructureの対応としてパッチ適用とAPIキーのローテーションは評価できるが、侵害発生から公表までのタイムラインや、Salesforceを含む外部連携の管理体制についての透明な情報開示がこれからの信頼回復のカギとなる。規模の大きなベンダーほど沈黙は不信感を増幅させることを認識すべきだ。 教育テックのサプライチェーンに依存する組織には、ベンダーを盲目的に信頼するのではなく、そのセキュリティ体制を継続的に評価・監視する責任がある。「ベンダーに任せている」は言い訳にならない時代になった。「使っている以上は自分事」という当事者意識こそが、今求められている。 出典: この記事は Instructure confirms data breach, ShinyHunters claims attack の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年、企業のAI活用は「試験運用」から「本番稼働」へと本格的に移行しつつある。その転換点において、MicrosoftがIDC MarketScape: Worldwide API Management 2026 Vendor AssessmentでLeaderポジションを獲得した。この評価は単なる表彰ではなく、従来のAPI管理にとどまらずAIモデル・ツール・エージェントまでを統一プラットフォームで統制するという戦略が業界標準として認知されつつあることを意味している。 10年の実績が生んだ信頼基盤 Azure API Management（APIM）は10年以上にわたりグローバル規模でAPIガバナンスの中枢を担ってきた。38,000社以上の顧客、約300万のAPI、月間3兆回を超えるAPIリクエストという稼働規模は、エンタープライズ用途で試されてきた実績の重みそのものだ。こうした基盤の上に、AI専用のゲートウェイ機能が追加されており、すでに2,000社以上の企業がAI運用の管理・可視化に活用している。 APIとAIを同じガバナンス層で扱う意義 従来のAPI管理は「システム間の接続」が主眼だった。しかしAIが本番環境に入り込んだ今、課題の構造が変わった。複数のAIモデルが複数のチャンネルから呼び出され、コスト管理・レート制限・ポリシー適用・ログ取得が複雑に絡み合う。APIMのAIゲートウェイ機能はこれに対する正攻法だ。モデルへのアクセス制御、使用量の監視、コスト管理、セキュリティポリシーの強制適用を既存のAPIインフラと同じ管理層で扱える。 Heineken社の事例はその効果を端的に示している。5か月で世界規模のAPIプラットフォームを構築し、月間5,000万コール処理・稼働開始以来100%アップタイム・API呼び出しコストを最大75%削減という成果だ。Banco Bradesco社も金融サービス全体のAI・APIを集中管理し、セキュリティポリシーの一貫適用と可視性確保を実現している。 日本のIT現場にとっての実務的意味 日本の多くの企業はいま「どうやって安全に、コストを管理しながらAIを組織全体に展開するか」という段階に差し掛かっている。マルチベンダー・マルチモデル構成を選択する企業にとって、各プロバイダーのAPIをバラバラに管理するアプローチは統制不能になる。ポリシーが散在し、コストが見えず、ログが断片化する。APIMのような統合ゲートウェイを挟むことで、アプリケーション側はモデルの差異を意識せずに済み、ガバナンス・可視性・コスト制御を一か所に集約できる。 実務での活用ポイント LLMトラフィックの計測を最初から設計に組み込む: コスト管理の観点から、APIレベルでのトークン使用量の記録は後付けではなく初期設計に含める。プロバイダーごとの応答フォーマットの差異を前提に計測ロジックを設計しないと、後から痛い目を見る レート制限とフォールバックをポリシーで定義する: モデルごとのクォータをAPIMのポリシーで強制適用し、特定モデルの過負荷・障害時の自動フォールバックをインフラ側に持たせる AIトラフィックも既存の監視スタックへ統合する: オブザーバビリティを分断しない。AIトラフィックを既存のダッシュボードに統合することでインシデント対応が格段に早くなる OpenAI標準前提の設定を疑う: 標準ポリシーでは捕捉できない使用量データが存在する場合がある。マルチモデル環境では各プロバイダーのレスポンス仕様を事前に調査しておく 筆者の見解 Microsoftのこの方向性は間違っていない、と断言できる。AIが本番運用に入った瞬間から「どのモデルに何を頼んでいるか」「コストはどうなっているか」「ポリシーに違反していないか」を問われる。個別のSDKにそれぞれのガバナンスを持ち込もうとすれば必ずバラバラになる。統合ガバナンス層としてのAPIMは、この問題への現実的な解だ。 ただ、実際にLLMガバナンスをAPIMで一元化しようとすると、OpenAI標準を前提に設計されたポリシーでは捕捉しきれないケースに直面することがある。マルチモデル運用を進める組織ほど、この問題は早めに顕在化する。プロバイダーごとのストリーミング応答の差異まで考慮した計測実装が必要になる場面があり、「標準ポリシーで全部いける」という楽観は禁物だ。 APIMが「AI管理の標準インフラ」になっていくシナリオは十分に現実的で、Microsoftにはそれを実現する力がある。だからこそ、OpenAI以外のプロバイダーへの対応をより丁寧に作り込んでいくことを期待したい。IDCのLeader認定は出発点であり、真価が問われるのはこれからだ。 出典: この記事は Microsoft named a Leader in the IDC MarketScape: Worldwide API Management 2026 Vendor Assessment の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIの進化が止まらない。2026年4月から5月にかけて、主要AIモデルの新バージョンが相次いでリリースされ、ベンチマーク上の競争は新たな局面を迎えた。特にコーディング支援とエージェント自律実行の両領域で記録が更新され続けており、AIを実務に活用するエンジニアにとって無視できない変化が起きている。 2026年春のモデル最新動向 GPT-5.5（4月23日リリース）が、エージェントのターミナル操作能力を測る「Terminal-Bench 2.0」で82.7%のスコアを記録し、このカテゴリでトップに立った。Terminal-Bench 2.0はシェルコマンドの実行、ファイル操作、ネットワーク診断など実際のシステム管理・DevOpsタスクに近い評価軸を持つ。単なる文章生成ではなく、「実際にシステムを操作して目的を達成できるか」を問う点が特徴だ。 一方、Claude Opus 4.7（4月16日リリース）は「SWE-bench Pro」で64.3%を達成し、コーディング領域の首位を奪還した。SWE-bench ProはGitHubの実際のIssueを自律的に修正する能力を問うベンチマークで、現在もっとも実用的なソフトウェアエンジニアリング能力の指標として信頼されている。前バージョンから大幅な改善が見られ、コードベース理解と修正提案の精度が実用水準に到達したと評価できる。 今回の比較にはGemini 3.1 UltraとDeepSeek V4-Proも含まれており、それぞれ異なる強みを示している。DeepSeek V4-Proはオープン系モデルとして引き続きコストパフォーマンスが高く、セルフホスト運用を検討する組織には引き続き注目株だ。 なぜ今のベンチマークが重要なのか ベンチマーク数値そのものより、評価軸が「テキスト生成品質」から「エージェント自律実行」にシフトしている点が本質的な変化だ。 Terminal-Bench 2.0が問うのは「AIがターミナルを自律的に操作してタスクを完遂できるか」であり、SWE-bench Proが問うのは「コードリポジトリのバグを自律的に特定・修正できるか」だ。どちらも人間が一つひとつ指示を出す副操縦士的なユースケースではなく、目標を与えれば自律的にループを回して完遂するエージェント型ユースケースを想定した設計になっている。 この評価軸の変化は、AIの使われ方の変化と表裏一体だ。単発のプロンプト→応答という使い方から、エージェントが判断・実行・検証を繰り返すループ設計（ハーネスループ）へ。このアーキテクチャをどう設計するかが、AIを実務で本当に使いこなすための中心テーマになりつつある。 実務での活用ポイント エンジニア・開発者向け SWE-bench Proの64%超というスコアは、コード修正タスクをどれだけ任せられるかの目安になる。レビュー前の初稿作成や、既知パターンのバグ修正なら積極的に委譲を検討できる水準だ。ただし「最終判断は人間がする」前提は崩さないこと。自律実行の精度が上がるほど、確認を怠るリスクも増す。 Terminal-Bench系の評価が高いモデルは、CI/CDパイプラインへの組み込みやシェルスクリプト自動化タスクとの相性が良い傾向がある。ハーネスループを組む際のモデル選定は単一タスク精度だけでなく、エラーリカバリ能力とレート制限・コストのバランスで判断することを推奨する。 IT管理者・インフラ担当向け DeepSeek V4-Proはセルフホスト可能なオープンモデルとしてコスト競争力が高く、社内データを外部に出せない用途や大量バッチ処理には引き続き有力な選択肢だ。Azure AI Foundryでのモデルデプロイ環境が整備されてきており、特定ベンダーへのロックインを避けたポータブルなアーキテクチャを今から設計しておくことが賢明だろう。 筆者の見解 AIモデルの比較記事が毎月出るようになってきた。それ自体が「進化速度の異常さ」を示している。 重要なのはベンチマークを追いかけることではなく、ベンチマークが何を測っているかを理解することだ。Terminal-BenchもSWE-benchも「自律的に目標を達成できるか」を問う。これはエージェント設計の本質的な問いと同じだ。数値を眺めるより、実際にエージェントループを一本自分で書いてみることの方が数倍の学びになる。情報を追うより実践を積む。この優先順位は2026年においても変わらない。 「使える仕組みを自分で作れる人間」と「使うだけの人間」の差は、今後さらに広がっていく。モデルのスペックシートを読み込むだけの時間があるなら、その時間でエージェントに任せられる業務フローを一つ設計した方がいい。 一点だけ苦言を。今回の比較にMicrosoftのモデルが明示的に入ってこない状況は少し寂しい。Azureのインフラ力とエンタープライズ実績は本物であり、それを活かして競争のど真ん中で戦える環境は整っているはずだ。Copilotの体験向上に留まらず、エージェント自律実行の領域で正面から勝負してくる姿を期待している。MicrosoftにはAI競争の最前線に立ち続ける力が十分ある。 出典: この記事は Best AI Models: April + May 2026 Leaderboard (GPT-5.5, Claude Opus 4.7, DeepSeek V4) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

エッジコンピューティングの巨人・Cloudflareが、超大規模言語モデル（LLM）をエッジネットワーク上で稼働させるためのインフラ技術を詳細に公開した。Moonshot AIのKimi K2.5（8×H100 GPU構成）やLlama 4 Scout（2×H200 GPU構成）を実際に動かしながら培った知見を惜しみなく開示した内容で、AIエージェント開発に関わるエンジニアなら必読の一報だ。 Rust製推論エンジン「Infire」──vLLM比20%の高スループット Cloudflareが自社開発したのが、Rust製推論エンジン「Infire」だ。既存の代表的な推論フレームワークであるvLLMと比較して最大20%の高スループットを達成したとされる。Rustで書かれている点が特徴的で、メモリ安全性とゼロコスト抽象化というRustの強みをGPU推論の世界に持ち込む設計思想が見える。 テンソル並列（Tensor Parallelism）とパイプライン並列（Pipeline Parallelism）の両方をサポートしており、モデルの規模やユースケースに応じて柔軟な構成が取れる。Kimi K2.5のような巨大モデルでも、リクエスト処理開始まで20秒以内という応答性を実現している。 Prefill-Decode（PD）分離アーキテクチャの意義 技術的に最も注目すべきが、「Prefill-Decode（PD）分離（Disaggregation）」の実装だ。 LLMの推論処理は大きく2つのフェーズに分かれる： Prefill（プリフィル）: 入力トークンを処理してKVキャッシュに保存するフェーズ。演算バウンド Decode（デコード）: KVキャッシュから出力トークンを生成するフェーズ。メモリバウンド 従来は1台のサーバーでこの2フェーズを直列処理していたが、これではGPUリソースを効率的に使えない。Prefillはコンピュートをフル活用する一方、Decodeはメモリ帯域が律速になるためだ。 PD分離では、専用のPrefillサーバーと専用のDecodeサーバーを分けて運用する。KVキャッシュをPrefillサーバーからDecodeサーバーへ転送する仕組みが必要になるが、Cloudflareはそのためのトークン対応ロードバランサーも独自実装している。ストリーミングSSEのレスポンスも書き換える必要があり、実装の難易度は相当高い。結果として、Prefillサーバーはコンピュート最適化ハードウェアに、Decodeサーバーはメモリ帯域最適化ハードウェアに、それぞれ独立してチューニングできる構成が実現する。 エージェントユースケースに特化した設計思想 このインフラがAIエージェント向けに特化して設計されているという点も重要だ。 エージェントの場合、入力トークン数が急増しやすい。システムプロンプト、ツール定義、MCPサーバーの情報、過去の会話履歴──これらすべてが毎ターン入力として渡される。Cloudflareはこの特性を熟知した上で、高速な入力トークン処理と高速なツール呼び出しの2点をWorkers AIの最優先課題として設定している。この「何のために速くするのか」を先に決めてからアーキテクチャを設計する逆算の発想が、今回の技術の本質だと感じる。 実務への影響 日本のエンジニアやIT管理者にとって、このニュースはいくつかの実務的含意を持つ。 1. エッジLLMホスティングの選択肢が広がる AWS BedrockやAzure OpenAI Serviceといったクラウド大手に一極集中していたLLMホスティングの選択肢が増える。Cloudflareのエッジネットワークは日本国内にもPoP（接続拠点）を持っており、低レイテンシが求められるアプリケーションで優位性を持ちうる。 2. オープンソースモデルの本番利用が加速する Kimi K2.5やLlama 4といったオープンソース系モデルの本番環境への道筋が整いつつある。プロプライエタリAPIへの依存を下げたい企業にとって、インフラ面での障壁が確実に低下している。コスト構造の変化にも注目しておく価値がある。 3. AIエージェント設計の前提が変わる Prefillが高速化されることで、長大なコンテキストを持つエージェントの応答性が向上する。「コンテキストウィンドウが大きいと遅い」という制約が緩和されることで、より複雑なエージェント設計が現実的になる。ツール呼び出しを多用するマルチステップエージェントにとっては直接的な恩恵だ。 筆者の見解 AIエージェントが実用に耐えるものになるかどうかは、突き詰めると「インフラが追いつくか」の問題だ。どんなに優れたエージェント設計であっても、リクエストの応答に数十秒かかるようでは実務で使えない。Cloudflareが今回公開した技術──PD分離、Rust製推論エンジン、テンソル並列対応──は、まさにその壁を崩すための地道な工学的努力の結晶だ。 AIエージェントが自律的にループで動き続ける仕組み──単発の指示→応答ではなく、自分で判断・実行・検証を繰り返す真のエージェント動作──こそが次のフロンティアだと思っている。その実現に必要なのは、優れたモデルだけでなく、長大なコンテキストを高速に処理できるインフラだ。今回Cloudflareが見せたのは、その未来への着実な投資である。 エッジでここまでのことができるようになってきたという事実は、日本のエンジニアコミュニティとしても注目し続ける価値がある。オープンソースモデル×エッジインフラという組み合わせが「実用レベル」に達する日は、思っているより早く来るかもしれない。 出典: この記事は Building the foundation for running extra-large language models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

KubeCon Europe 2026でMicrosoftが打ち出したメッセージは明快だった。「Kubernetesはもはやコンテナオーケストレーションツールではない。AIインフラの基盤OSだ」——この宣言は、エンタープライズAI運用の設計思想を根底から変える可能性を持っている。 KubernetesがAI基盤の「コントロールプレーン」になる Microsoftが描くビジョンは、Kubernetesを企業内のあらゆるAI関連ワークロードの管理基盤として位置付けるものだ。Webアプリのコンテナを管理していた同じ kubectl コマンドが、数百台のGPUにまたがる分散学習ジョブをオーケストレーションする——この統合こそが今回の発表の核心である。 従来、AIインフラは「専用の管理システム」として独立して運用されることが多かった。それがKubernetesへの一元化を進めることで、運用チームの学習コストを抑えつつ、既存のCI/CDパイプラインやポリシー管理をそのままAIワークロードに適用できるようになる。 DRAがGPUスケジューリングを変える 三本柱の一つ目がDynamic Resource Allocation（DRA）だ。KubernetesがCPUやメモリをスケジューリングするのと同じ精度で、GPUリソースを割り当てられるようになる仕組みである。 具体的には以下の機能がKubernetes APIを通じて直接利用可能になる。 フラクショナルGPU共有: 1枚のGPUを複数のワークロードで分割利用 タイムスライシング: GPU利用時間を時間割で管理 マルチインスタンスGPUパーティショニング（MIG）: NVIDIAのMIG機能をK8sレイヤーで統制 これまでGPU管理は専用ツールに頼るか、手動設定が必要なケースが多かった。DRAの成熟によって、GPUリソースがCPU/メモリと同様に「Kubernetesが面倒を見る」世界が近づく。 AI Runway：モデルを本番に届ける「最後の1マイル」を短縮 二本目の柱がAI Runwayプラットフォームだ。多くの組織がモデルのトレーニングには成功しているが、それを本番環境に展開することに苦労している。AI Runwayはその「最後の1マイル」問題に正面から取り組む。 VS Codeなどの開発環境と本番Kubernetesクラスターをつなぐ標準化パイプラインを提供し、モデルの特性とリソース要件に基づいてKubernetesマニフェストを自動生成する。モデル検証から本番デプロイまでの時間を「数日から数時間へ」と短縮できることをMicrosoftは示した。 カナリアデプロイやロールバック手順もKubernetesネイティブな仕組みで自動処理されるため、MLOpsの運用負荷を大幅に削減できる。 Cilium統合でAIのネットワーク要件に応える 三本目がCiliumの深いAKS統合だ。AIの分散学習では、ノード間を流れるデータ量が従来のマイクロサービスとは桁違いに大きい。勾配（gradient）のやり取りだけでテラバイト規模のトラフィックが発生する。 CiliumのeBPFベースアーキテクチャはカーネルレベルでこのトラフィックを最適化し、Microsoftの発表によれば分散学習ジョブのネットワークレイテンシを標準Kubernetesネットワーキングと比較して40%削減したという。eBPFはLinuxカーネルのコードを変更せずにカーネル動作を拡張できる技術であり、パフォーマンスと可観測性の両立が可能だ。 実務への影響——日本の現場にとって何が変わるか この発表が日本のエンジニアやインフラ管理者に示す実務的なインパクトは大きく三点ある。 1. GPU管理の標準化が加速する DRAの成熟により、GPUクラスターの管理をKubernetesに集約できる。AIプロジェクトごとに別々のツールや専門家を抱える必要が減り、既存のKubernetes運用チームがGPUワークロードを担える素地が整う。 2. AKS採用組織はCI/CD刷新の好機 AI RunwayはAKSとの統合が前提だ。すでにAzure/AKSを本番で使っている組織は、MLOpsパイプラインをKubernetesネイティブに刷新する絶好のタイミングが来ている。既存のポリシー・RBAC・監査ログがそのままAIワークロードに適用できる点は、ガバナンス上の大きなメリットだ。 3. ただし専門知識の壁は依然として高い DRA、Cilium、AI Runway——どれも強力だが、設定・運用には高度なKubernetes知識が必要だ。「とりあえずAKSを使っている」レベルの組織がそのまま恩恵を受けられるほど簡単ではない。マネージドサービスの成熟と、社内人材のスキルアップを並行して進める計画が必要になる。 筆者の見解 Microsoftが「KubernetesをAI基盤のOSにする」と宣言したことは、アーキテクチャの方向性として筋が通っている。部分最適のツールをバラバラに積み重ねるより、統合されたコントロールプレーンで全体を管理するほうが、長期的には運用コストもリスクも下がる。これはプラットフォームとしてのAzure・Entra ID・AKSに対する信頼が揺るがない理由と同じだ。 DRAによるGPU管理の標準化とCiliumによるネットワーク性能の底上げは、特に評価できる。GPUクラスターの管理が「Kubernetesを知れば何とかなる」世界になることは、日本の現場にとって人材調達の観点からも重要な前進だ。 一方で、AI Runwayの「数日から数時間へ」という効果を実際に得るには、モデル管理・バージョン管理・監視の仕組みが整備されていることが前提になる。ツールを導入すれば自動的に解決する話ではない。MLOpsの文化と基盤を先に作ることが順序として正しい。 Kubernetesを中核に据えたプラットフォーム統合の方向性は歓迎する。ただし「すごい発表があった」で終わらせず、自分たちのKubernetes運用の現在地を棚卸しして、どのコンポーネントから実装するかの優先順位を今すぐ考え始めることが、実務者として取るべき行動だろう。 出典: この記事は Microsoft Declares Kubernetes the AI Infrastructure OS at KubeCon 2026 with DRA, AI Runway & Cilium Integration の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Purviewのデータセキュリティ調査（Data Security Investigations、以下DSI）に、2026年5月中旬から「カスタム検査フォーカスエリア」機能が追加される。AIが調査対象データをどう優先分析するかを管理者が明示的に制御できるようにする機能で、コンプライアンス部門の作業効率と調査精度の両面に直接影響する変更として注目したい。 カスタムフォーカスエリアとは何か 従来のDSIでは、テナント全体のデータに対してAIが一律に深度コンテンツ分析（Deep Content Analysis）を実行していた。マイナンバー、クレジットカード番号、医療記録など、機密情報の種類を問わず同じ優先度で処理されていた。 今回追加されるカスタム検査フォーカスエリアにより、管理者は「今回の調査ではこの種類の情報を優先的に調べてほしい」と指定できるようになる。内部調査であれば「給与・人事情報」を、顧客情報漏洩の疑いがあれば「個人識別情報と金融情報」を優先させる、といった使い方が典型例になるだろう。 ロールアウトスケジュールは以下の通り： パブリックプレビュー: 2026年5月中旬〜6月中旬 一般提供（全世界）: 2026年6月中旬〜6月末 既存のPurviewのパーミッションおよびポリシーはそのまま適用される。管理者が明示的にカスタムフォーカスを設定した調査以外、既存のユーザーワークフローへの影響はない。 日本企業における具体的な活用シナリオ 日本のエンタープライズ環境では、業界ごとに固有の機密情報カテゴリが存在する。金融機関なら顧客の口座情報や取引履歴、医療機関なら診療記録や処方データ、製造業なら設計図や原価情報がそれに相当する。これまでDSIは業界固有の文脈に合わせた調整が難しく、調査担当者から「ノイズが多い」という声が上がりやすかった。 カスタムフォーカスの登場により、「自社にとっての最重要機密」にAIの解析リソースを集中させることができる。本当に重要なリスク信号が浮かび上がりやすくなり、インシデント対応の初動スピードにも効いてくるはずだ。 今から準備しておくべきこと Microsoft自身は「事前の対応は不要」としているが、実務観点では以下の準備を推奨する。 組織の機密情報分類を棚卸しする — カスタムフォーカスを効果的に使うには、組織としてどの情報が最も重要かを事前に整理しておく必要がある。情報保護ポリシーの見直しと合わせて進めると効率が良い 調査プレイブックにフォーカス設定の手順を追記する — セキュリティインシデント対応手順に「DSI実行時のカスタムフォーカス選択基準」を組み込んでおく。担当者が変わっても一貫した調査品質を維持できる コンプライアンスチームへの周知 — IT管理者だけでなく、法務・コンプライアンス担当者にも機能の存在と活用方法を案内しておく。調査の設計段階から関与してもらうことで、フォーカス設定の精度が上がる 筆者の見解 データセキュリティ調査においてAIが「何を重視して調べるか」を管理者が指定できるようになる。地味に聞こえるかもしれないが、実際のインシデント対応現場では大きな変化だ。 これまでのAI分析は「AI任せ」の側面が強く、調査担当者からすると「なぜこれが優先されてこっちが後回しなのか」という不満が出やすかった。カスタムフォーカスエリアはその齟齬を埋める機能として、方向性は正しいと思う。 ただ、本当に意味のある機能になるかどうかは、フォーカスエリアの設定粒度と、AIが実際にどう優先度を変えるかの透明性にかかっている。「設定できる」と「効果が出る」の間には距離があることを、過去の経験から痛感している。パブリックプレビューの段階で実際の調査シナリオで試し、体感としての効果を早めに検証しておきたい。 セキュリティとコンプライアンスの領域こそ、PurviewがMicrosoft 365の中で真価を発揮できる場所だ。AI分析の精度向上と管理者コントロールの両立というこの方向性はぜひ継続的に発展させてほしい。Microsoftが本気でコンプライアンスプラットフォームとして磨いていくのであれば、こういう地道な機能強化こそが長期的な競争力になると信じている。 出典: この記事は Microsoft Purview Data Security Investigations: Introducing new custom examination focus areas の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが業務システムに次々と組み込まれる今、「誰がどのエージェントを動かしているのか」を正確に把握できている組織はどれほどあるだろうか。Microsoftは2026年5月のAgent 365アップデートで、この問題に正面から取り組んだ。全テナントへのダッシュボード展開と、AWS・Google Cloud上のエージェントまで対象に含むマルチクラウド自動検出機能のパブリックプレビュー開始は、AI時代のガバナンス基盤として注目に値する内容だ。 Agent 365ダッシュボードが全テナントへ 今回の大きなアップデートの一つは、Agent 365ダッシュボードの全テナントへの展開だ。これまで限定公開だった管理画面が、ついてすべてのMicrosoft 365テナントで利用可能になる。 ダッシュボードでリアルタイムに確認できる情報は以下の3点だ。 登録済みエージェント数: 組織内で稼働するAIエージェントの全体像 アクティブユーザー数: 実際にエージェントを利用しているユーザーの動向 リスクシグナル: 不審な動作や権限の逸脱など、セキュリティ上の懸念点 この可視化は単なる「管理ツールの追加」ではない。AIエージェントがNon-Human Identity（NHI）として組織内のシステムにアクセスし、タスクを自動実行する時代において、その活動状況を把握することはゼロトラストセキュリティの根幹に関わる問題だ。 マルチクラウドエージェントの自動検出——AWS BedrockとGoogle Cloudも対象に 今回のアップデートでとりわけ注目したいのが、レジストリ同期機能のパブリックプレビューだ。 これはMicrosoft 365テナントの外側、すなわちAWS BedrockやGoogle Cloud上で動作するAIエージェントを自動的に検出し、Microsoft側のインベントリに取り込む機能だ。エンタープライズ環境では、複数のクラウドプラットフォームにまたがってAIエージェントが乱立するケースが増えている。これを一箇所から管理できるようになる意味は大きい。 ライフサイクルガバナンスの観点でも重要だ。エージェントの作成・変更・廃止といった一連のライフサイクルを、自組織内外を問わずMicrosoftのガバナンス基盤で追跡できるようになる。これにより、「どのエージェントが、いつ、誰の権限で動き続けているか」を一元的に管理する体制が整う。 実務への影響 IT管理者にとって 日本の多くのエンタープライズ企業では、AI活用の主導権が各部門に分散しつつある。情報システム部門が把握していないところで、営業や企画部門が独自にAIエージェントを構築・運用しているケースは珍しくない。Agent 365のダッシュボードと自動検出機能は、こうした「シャドーAI」を可視化する第一歩として機能する。 ゼロトラストアーキテクチャを推進する立場から言えば、NHI（人間ではなくシステムやエージェントのアカウント）の管理はこれまで見落とされがちなリスク領域だった。Agent 365がこの領域に正式に踏み込んできたことは、セキュリティ担当者にとっても前向きに受け取れる動きだ。 エンジニアにとって AWS BedrockやGoogle Cloud上でエージェントを開発しているエンジニアも、今後はMicrosoftの管理基盤に接続される可能性を意識した設計が求められる。特にM365環境と連携する業務システムを構築している場合、Agent 365のレジストリ同期が組織のガバナンスポリシーに影響を与えうる点を頭に入れておきたい。 パブリックプレビューの段階から実際に触れておくことで、正式リリース時のポリシー策定や移行計画をスムーズに進められる。今のうちに自組織のエージェントインベントリを棚卸しし、どこに何が動いているかを整理しておくことを勧めたい。 筆者の見解 AIエージェントの乱立は、かつてのSaaSスプロール問題と構造がよく似ている。部門単位で便利なエージェントが増えることそれ自体は悪いことではないが、統制されないまま進むと、最終的にはコスト・セキュリティ・コンプライアンスの三重苦に陥る。Agent 365が目指しているのは、まさにこの問題に対するプラットフォームレベルの答えだ。 NHIの管理を業務効率化の文脈で考えると、エージェントが自律的に動くためには「信頼できるアイデンティティ管理基盤」が不可欠だ。今回のアップデートはその方向に確実に進んでいる。こういった地道な基盤整備こそが、長期的なAI活用の土台になる。 マルチクラウド対応については、Microsoftが自社エコシステムの外側まで視野を広げてきたことを素直に評価したい。M365を使っている組織が必ずしもAzureだけで完結していない現実を受け入れた上での機能設計は、実態に即している。 課題があるとすれば、このガバナンス基盤を実際に機能させるには、組織内での合意形成と運用プロセスの整備が伴わなければならない点だ。ツールの展開だけが先行して、運用文化が追いつかないという状況は避けたい。AIエージェント管理のガバナンス設計を真剣に考えるなら、今がその着手のタイミングだ。 出典: この記事は What’s New in Agent 365: May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

XR専門メディア XR Today（ライター：Alex Cole）は2026年1月、Google I/O 2026（5月19〜20日開催）がAndroid XRスマートグラスの最初の本格的ハードウェア発表の場になるとの見方を報告している。Samsung Galaxy XR（OS）が2025年10月に批評家から高い評価を得て以来、業界の注目はAndroid XR搭載の「グラス型デバイス」へと急速に移りつつある。 なぜ今、Android XRスマートグラスが注目されるのか Samsung Galaxy XRの成功が証明したのは、AndroidベースのXR OSが実用に耐えるエコシステムとして機能するという信頼だ。Meta Ray-Banに代表されるファッション路線のAIグラスがヒットを記録したことで、消費者側のスマートグラスへの心理的ハードルも大幅に下がっている。 ここにGoogleがGeminiというAIエンジンを携えて乗り込んでくる構図だ。XR Todayの報告によれば、複数のブランドが同時期に参入を予定しており、Google I/O 2026は事実上の「Android XRグラス元年」の幕開けとなる可能性が高い。 海外レビューのポイント：注目プレイヤー別の概況 Samsung スマートグラス XR Todayは、SamsungのモバイルVP・Drew Blackard氏の発言を引用している。「もうすぐ来る。遠い未来の話ではなく、実行フェーズに近づいている」——同氏はこれを「ティーザー」と位置づけつつ、2025年内の発売は否定した。 XR Todayの分析によれば、カメラとGemini AIの搭載が確実視されており、特筆すべきは視覚入力への対応だ。Meta Ray-Banが視覚情報を「音声のみ」でフィードバックするのに対し、SamsungグラスはGeminiによる画面情報の提示が可能になるとされる。 Xreal「Project Aura」 2026年中の発売を予定するAndroid XR搭載グラスのコードネーム。現時点では公開画像のみで詳細は未確認だが、XR TodayはXrealの既存ラインから推察して有線テザー接続型による軽量・低コスト設計になる可能性が高いと分析している。 Warby Parker スマートグラス アメリカの眼鏡ブランドが参入。XR Todayによると、GoogleはAndroid XR製品の開発・商業化支援として最大7,500万ドルの投資を表明（マイルストーン達成で追加7,500万ドルの条件付き投資も）。 公開されたプレビュー画像は同ブランドらしいシンプルでミニマルなデザイン。第1世代はレンズ内ディスプレイ技術を省略し、Ray-Ban Meta路線のGemini搭載AI音声グラスとして参入する見通し。処方レンズへの対応も予定されている点は注目に値する。 Gentle Monster・Magic Leap 韓国のアバンギャルド系アイウェアブランドGentle MonsterもAndroid XR陣営への参加が報告されている。一方、Magic LeapはGoogleと共同開発したAndroid XRグラスのプロトタイプを既に公開。Magic Leap独自の導波管光学とGoogleのRaxium microLEDエンジンを組み合わせた設計で、終日使用を想定した高輝度・省電力ARディスプレイを実現するとしており、主にエンタープライズ向けのリファレンスモデルと位置づけられている。 日本市場での注目点 Xrealは国内先行実績あり。 XREAL Air 2シリーズはすでにAmazon.co.jp等で購入可能。Project Auraが発売された際も比較的早い国内展開が期待できるメーカーだ。 Warby Parkerは国内未展開。 日本にサービスがないため、仮に製品発売となっても当面は並行輸入か海外購入が現実的なルートになりそうだ。 処方レンズ対応の重要性。 眼鏡装用率の高い日本市場で、Warby Parkerが謳う「処方レンズ選択可能」は大きな訴求ポイントになりうる。現行スマートグラスの多くが処方レンズ非対応なだけに、ここでの差別化は見逃せない。 価格帯の目安。 現行のMeta Ray-Ban Smart Glasses（国内実売5〜6万円台）が一つの参照点。Android XRグラスがどの価格帯に着地するかが普及を左右する。 ...

炎に包まれた部屋でニコニコしながら「これで問題ない」とつぶやく犬のミーム──「This is fine」は、2013年の初出以来10年以上にわたりインターネット文化に根付いてきた。その作者KC Greenが今、自分の作品を無断で商用利用したAIスタートアップへの憤りをSNSで公開し、法的手段を検討している。 何が起きたか 2026年5月、海外SNSに地下鉄の広告写真が投稿された。広告には「This is fine」のキャラクターをほぼそのまま流用した絵が描かれ、セリフだけが「[M]y pipeline is on fire（パイプラインが炎上している）」に改変。その上に「Hire Ava the AI BDR（AI営業担当Avaを採用せよ）」というメッセージが重ねられていた。 この広告を出したのはArtisanというAIスタートアップだ。同社はかつて「Stop hiring humans（人間を採用するな）」というビルボードを展開し、物議を醸したことでも知られている。 KC GreenはBlueskyで即座に反応した。「これは私が同意したものではない。AIが盗むように盗まれた」と明言し、見かけたら「vandalize（破壊・落書き）してほしい」とフォロワーに呼びかけた。TechCrunchの取材に対してArtisanは「Greenに敬意を持っており直接連絡している」と回答したが、事前合意がなかったことは明白で、事後対応に追われる構図となった。 Greenは「法的代理人を探している」としながらも、「漫画を描くという情熱に使うべき時間を、アメリカの法廷に費やさなければならないのは本当につらい」と心境を語った。そして「こういう考えなしのAI企業は無敵ではない。ミームは何もないところから生まれるわけではない」とも述べている。 「ミームの無断利用」が持つ法的・文化的な複雑さ 今回のケースは技術的な著作権侵害の典型だが、ミームという媒体の特性がさらに問題を複雑にしている。 ミームはその性質上、「引用・改変・二次創作」が文化として根付いており、個人間のカジュアルな使用と商業広告での利用は明確に区別される。著作権法上、商業目的の利用には原則として権利者の許諾が必要であり、「有名なミームだから使ってもいい」という解釈は成立しない。 類似の事例として、Pepe the Frogを創作したMatt Furieが、自分のキャラクターを政治的プロパガンダに無断利用したInfowarsを提訴し、最終的に和解に至ったケースがある。今回も同様の法的判断が下される可能性は十分にある。 実務への影響──AIを活用するビジネスが注意すべきこと 今回の件は、AIを使ったマーケティングや広告制作を行う企業にとって、他人事ではない。 確認すべき4つのポイント： 生成物の類似性チェック: AIツールが生成した画像や文章が既存著作物に酷似していないかを確認するプロセスを設ける 商用利用の明示的許諾: 使用するAIサービスのライセンス条件を法務部門と連携して確認する 既存コンテンツの改変: 人気ミームやキャラクターをベースにする場合、たとえ改変であっても原作者への許諾が必要 「有名だから大丈夫」は禁物: 広く普及しているコンテンツほど、訴訟リスクも高い 日本でも文化庁がAI生成物と著作権に関するガイドラインの整備を進めている。商用コンテンツにAIを活用する場合は、法的根拠の確認を怠らないようにしたい。 筆者の見解 今回の件で最も目を引くのは、Artisanという企業の行動の矛盾だ。「人間を雇うな」と社会に訴えながら、人間のクリエイターが何年もかけて育て上げた文化的資産を、その人間に一言も断らず商業利用する──これは技術の問題ではなく、倫理の問題だ。 AIには本物の可能性がある。業務変革のツールとして、創造性を拡張するパートナーとして、多くの場面で実際に価値を発揮している。だからこそ、こういった行動が業界全体の信頼を損なうのが本当にもったいない。「AIは人間の仕事を奪う」「AIは盗む」という不安が社会に広がっているこの時期に、クリエイターの作品を無断利用することは、その不安をみずから正当化させてしまう。 Greenの言葉──「ミームは何もないところから生まれるわけではない」──は核心を突いている。インターネット文化も、AIの学習データも、すべて人間の創造性の積み重ねの上に成り立っている。その事実への敬意なしに、AIを使ったビジネスが社会から長期的な信頼を得ることはできないだろう。 技術的な革新と倫理的な責任を両立させること。それがこれからのAIビジネスに問われている最重要課題のひとつだと思う。 出典: この記事は ‘This is fine’ creator says AI startup stole his art の内容をもとに、筆者の見解を加えて独自に執筆したものです。

生成AIが音楽制作を民主化したことで、ストリーミングプラットフォームに前例のない規模の「コンテンツ洪水」が押し寄せている。2023年末に登場したSuno、2024年のUdioがテキストプロンプトだけで楽曲を生成できるサービスを一般公開し、AI楽曲の制作は技術者の専有物ではなくなった。その結果は数字が雄弁に語る。 「5万曲/日」から「7.5万曲/日」へ——加速する流入 Deezerのデータが問題の深刻さをリアルタイムで示している。2025年9月時点でAI生成楽曲はアップロードの28%を占めていたが、同年末には1日5万曲・全体の34%に拡大。2026年春には1日7万5000曲にまで膨らんでおり、人間が制作した楽曲のアップロード数を数で上回る日も視野に入ってきた。 Spotifyも無縁ではない。過去12ヵ月で7500万曲以上のスパムトラックを削除したと報告されている。ロイヤリティを稀釈するスパム的なAI楽曲の大量投入は、正当なアーティストへの収益分配を蚕食する構造問題に発展しつつある。 各社の対策——「ラベリング」という妥協点 これを受けて各プラットフォームは動き始めた。ただし「全面禁止」という強硬手段は誰も選んでいない。 Deezer: 業界に先駆けてAI生成コンテンツの自動検出・ラベリングシステムを導入。アルゴリズムによるレコメンデーション対象から除外し、ストリームの85%をデモネタイズ（収益化停止）している。現時点で最も踏み込んだ対応だ。 Qobuz: 独自の「AIチャーター」を公表し、編集・キュレーションコンテンツには一切AIを使わないと約束。「Qobuzの心臓部は今も、これからも人間のもの」という立場を鮮明にした。 Apple Music: ラベリングを「要件」として定めているが、実態は自己申告制。ラベルを付けなかった場合のペナルティについてAppleはコメントを避け、「コンテンツプロバイダーの判断に委ねる」という姿勢に終始している。 Spotify: AI楽曲に「AIクレジット」表示を始め、業界標準団体DDEXと協力して標準化を進めている。ただしこちらも自己申告ベースだ。 自己申告制の致命的な矛盾 ここで根本的な問いが浮かぶ。ロイヤリティを荒稼ぎしようとスパムAI楽曲を大量投入しているアクターが、自発的に「これはAI生成です」とラベルを付けるだろうか。答えは明白だ。 自己申告制は誠実なクリエイターにだけ機能する。悪意ある利用者には何の制約にもならない。Appleがペナルティについて回答を避けたことは、この矛盾を暗黙に認めているようにも見える。技術的な自動検出と業界横断の標準ルールの両輪がなければ、この問題に実効的に対処することはできない。 実務への影響——ITエンジニア・コンテンツ担当者が押さえるべき点 この問題は音楽業界だけの話ではない。コンテンツプラットフォームを運営するエンジニアやIT管理者にとって、AI生成コンテンツのガバナンスは今後あらゆる領域で直面する普遍的課題だ。 検出技術の限界を前提にする: 現状のAI生成検出は精度100%ではない。単一の技術に頼らず多層防御が必要であり、「検出と回避のいたちごっこ」を織り込んだ運用設計が求められる 自己申告は補助手段と割り切る: コンプライアンス遵守を前提にした設計は、悪意ある利用者を排除できない。ペナルティと技術的強制をセットで設計することが実効性の条件になる 日本の文脈で考える: JASRACをはじめとする著作権管理団体がAI生成楽曲への対応を模索しているが、グローバルプラットフォームへのアップロードは国内からも現実に行われる。国内アーティストのロイヤリティ保護という観点でも、対岸の火事では済まない 筆者の見解 AIが音楽制作の入口を誰にでも開いたことは、技術の民主化として本来歓迎すべき変化だ。問題はツールそのものではなく、プラットフォームが「大量生産された低品質コンテンツ」への備えを持たずにドアを開けてしまったことにある。 今起きていることは、強力な技術を社会インフラとして使いこなすための「ガバナンスの空白期」だ。禁止というアプローチでは必ず失敗する——禁止されたクリエイターが地下に潜るだけで、問題は見えにくくなるだけだ。プラットフォームが取るべき道は、AI楽曲を安全に扱える仕組みを整備しながら共存することである。 自己申告制で済ませている大手プラットフォームの現在地は、率直に言ってもったいない。Deezerが先鞭をつけた自動検出の仕組みを業界全体で共有・改善し、DDEXの標準化を速やかに実装に結びつけるアプローチが現時点での最善策ではないか。技術力も影響力も十分持っているプレイヤーが揃っているのだから、正面から取り組める力はあるはずだ。 AIが生み出すコンテンツ量は今後さらに増加する。この問題を「音楽業界の特殊事例」として眺めていると、次は自分たちのプラットフォームで同じことが起きる。コンテンツガバナンスの設計を今から考えておく価値は十分にある。 出典: この記事は AI music is flooding streaming services — but who wants it? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年3月20日に「Windows 11品質改善への取り組み」を正式に宣言したが、あれから約2ヶ月──Windowsインサイダープログラムの新リード、Marcus Ash氏が具体的な進捗レポートを公開した。「どうせ口だけ」と懐疑的だったユーザーも少なくなかったが、実際の変更内容を見ると、これまでとは明らかに姿勢が変わっている。現時点ではExperimentalチャネル（Insiders向け）への展開だが、変更の方向性は注目に値する。 Insiderチャネルが4つから2つに整理 これまでWindowsインサイダーはCanary・Dev・Beta・Release Previewの4チャネルを使い分ける必要があり、検証環境を複数維持していたユーザーも多かった。この複雑さが解消され、「Experimental」（旧CanaryとDevの統合）と「Beta」の2チャネルに集約された。 さらに、Experimentalチャネルの参加者はFeature Flagsにアクセスできるようになった。試したい機能を選択して個別に有効化できるこの仕組みは、フィードバックの質と粒度を大幅に向上させる可能性がある。チャネルの切り替えやプログラムからの離脱も、以前のようなクリーンインストールなしで行えるようになった。 更新プログラムの頻度とタイミングが抜本的に変わる 長年の不満だった「頻繁すぎる再起動」問題にも手が入った。OS本体・.NET・ドライバーの更新が月1回のタイミングに統合され、再起動も月1回で済む設計に移行する。シャットダウン・再起動時に更新インストールをスキップするオプションも追加され、「今すぐ終了したいだけなのに強制更新」という体験が改善される。 更に重要なのが無期限の更新一時停止だ。新設されたカレンダーUIから最大35日間の一時停止が可能で、期限が来ても繰り返し延長できる。「すぐ適用したら壊れた」という事例が増えている現状を踏まえると、これは実質的に管理者がセキュリティ判断の余地を持てる仕組みへの転換だ。 OOBE（初期セットアップ）中の更新スキップも追加された。これまでセットアップに約1時間かかっていた大きな要因のひとつが解消される。 パフォーマンス改善とAI存在感の縮小 File Explorerの高速化とウィジェットのメモリ使用量削減も並行して進められている。「重い・遅い」という声が多かった部分の改善だ。 今回の変更でもうひとつ注目すべきなのが、Copilot AIの存在感を意図的に縮小したことだ。レポートでは「ダイヤルバックされたAI体験」「静かなデフォルト設定」という表現が使われており、ユーザーへの押し付けを減らす方針が明確に示されている。 日本のIT管理者・エンジニアへの実務的な影響 更新展開サイクルの再設計機会: 月1回の統合更新は、WSUS・Intune経由でWindowsパッチを管理している部門にとって展開設計を整理するタイミングになる。OS・.NET・ドライバーが個別に動いていた煩雑さが減れば、展開リングの設計もシンプルにできる可能性がある。 「様子見」が公式戦略になる: 無期限一時停止の実装は、Microsoftが「即時適用が唯一の正解」とは見なしていないことを示している。数日から数週間様子を見てから展開する運用を、組織のポリシーとして堂々と設計できる環境が整いつつある。 Insiderへの参加障壁が下がった: 2チャネル制とチャネル切り替えの簡便化は、テスト環境でInsiderを評価する敷居を下げる。新機能の先行検証に関心がある組織には参入しやすいタイミングだ。 筆者の見解 ここ数年のWindowsは、ユーザーが求めていなかったものを次々と押し込み、求めていたものはなかなか改善されない──そういう状況が続いていた。今回の変更は、ユーザーの声に真摯に向き合おうとした跡が見える。素直に「ようやくここまで来たか」と感じる。 ただし、まだ「Insiderチャネルの一部」にしか届いていない。これが一般リリースでどこまで実現されるかが本当の評価軸だ。発表と実装の間に差が生じることも珍しくない。引き続き注視する必要がある。 Microsoftにはエンタープライズから一般ユーザーまで包括する膨大なユーザーベースがあり、Windowsを世界標準として維持してきた実績もある。その力があるのだから、AIを無理に詰め込んで主役を奪わせるよりも、OS本来の信頼性と快適さを磨き続ける方向で勝負してほしいと個人的には思っている。今回のような「地味だけど確実な改善」の積み重ねが、Windowsへの信頼を取り戻す最短経路だ。 出典: この記事は Microsoft says it’s keeping its promise to fix Windows 11, shares everything that’s changed since March の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティ研究機関CTM360が、Telegramの「Mini App」機能を組織的に悪用した詐欺プラットフォーム「FEMITBOT」を発見した。Apple、NVIDIA、Disney、eBayといった世界的ブランドになりすまし、仮想通貨詐欺とAndroidマルウェアを同時展開するこの組織は、再利用可能なインフラを備えた「詐欺のSaaS（Software as a Service）」とも言うべき構造を持っている。プラットフォームの利便性が攻撃の温床になった典型例として、日本のIT現場でも無視できない話題だ。 Telegram Mini Appとは何か Telegramには「Mini App（ミニアプリ）」と呼ばれる機能があり、Telegreamアプリ内の組み込みブラウザ（WebView）上で動作する軽量なWebアプリケーションを実行できる。決済、アカウント管理、インタラクティブなツールなどをTelegramの外に出ることなく利用できるため、ユーザーの利便性は高い。 しかし、この「アプリから出なくていい」という特性が諸刃の剣になった。通常のブラウザなら気づきやすいフィッシングサイトの違和感が、アプリ内UIに溶け込んでしまうため、ユーザーが「Telegramの一部のサービスを使っている」と誤認しやすい環境が生まれる。 FEMITBOTの攻撃構造 CTM360の報告によると、FEMITBOTは以下のフローで被害者を誘い込む。 ボットとの接触: 攻撃者が用意したTelegramボットに被害者が接触し「Start」をタップする Mini Appの起動: ボットがMini Appを起動し、有名ブランドに偽装したフィッシングページをWebView内に表示 偽ダッシュボードで信頼を演出: 「残高」「収益」「ボーナス」などを表示する精巧なダッシュボードと、カウントダウンタイマーによる限定感で心理的プレッシャーをかける 入金要求: 出金しようとすると「入金が必要」または「紹介タスクの完了が必要」と言われ、資金を巻き上げる マルウェアAPKの配布: 一部キャンペーンでは、BBC・NVIDIA・Claro等のブランドになりすましたAndroid APKをダウンロードさせる 特筆すべきは、このプラットフォームが共通バックエンドインフラを採用している点だ。複数のフィッシングドメインが同じAPIを使い回しており、APIレスポンスに含まれる文字列「Welcome to join the FEMITBOT platform」がその証拠として発見された。ブランド・言語・テーマだけを差し替えて異なるキャンペーンを量産できる構造は、まさにサービス型の詐欺基盤だ。 また、Meta（Facebook）やTikTokのトラッキングピクセルを埋め込んでいることも確認されており、詐欺の「コンバージョン最適化」まで行っていることが分かる。マーケティングのノウハウを詐欺に転用している点は寒気がする。 なぜ今、Telegramが狙われるのか Telegramは世界で9億人以上のユーザーを抱え、プライバシー重視・低規制のプラットフォームとして知られている。運営側による監視や削除が遅いことが、攻撃者にとって活動しやすい環境を提供している。 加えて、Mini AppはWebベースのため開発コストが低く、一度インフラを構築すれば新しい詐欺サイトの量産が容易だ。TLSを正規取得したドメイン上にAPKをホストしているため、「証明書があるから安全」という誤った判断を誘導できる点も巧妙だ。 日本のIT現場への影響と対策 日本でもTelegramのビジネス活用や仮想通貨関連コミュニティでの利用は増えている。組織として以下の点を確認・周知しておく必要がある。 エンドユーザー向け Telegram経由で「投資・仮想通貨・稼げる」系のボットに誘導された場合は即座に疑う Mini Appからダウンロードを促されるAPKファイルは絶対にインストールしない Googleアカウントや金融情報の入力を求められた場合はURLを必ず確認する IT管理者・セキュリティ担当者向け AndroidデバイスのMDM（モバイルデバイス管理）で「提供元不明アプリ」のインストールをポリシーで禁止する Telegramを業務利用している場合、Mini Appのアクセス許可設定を見直す エンドユーザーへのフィッシング訓練にTelegram経由のシナリオを追加することを検討する ゼロトラスト観点では、業務端末上でのTelegram利用を用途別に分離する（個人利用・業務利用の端末分離） APKのサイドロード（Google Play以外からのインストール）はAndroidマルウェアの主要な流入経路であり、MDMポリシーで制御できるにもかかわらず設定されていない企業が多い。これはすぐに対処できる実務的な改善点だ。 筆者の見解 今回のFEMITBOTが示したのは、詐欺そのものの「プラットフォーム化」が進んでいるという事実だ。かつての詐欺は個人やグループが手作りで運営するものだったが、今や再利用可能なインフラを持つ「詐欺基盤」が存在し、それを借りるだけで誰でも大規模な詐欺キャンペーンを展開できる時代になっている。 これはフィッシング対策の難易度が根本的に変わったことを意味する。「このドメインをブロックすれば終わり」ではなく、インフラを丸ごと把握しなければ止まらない。CTI（サイバー脅威インテリジェンス）として共通インフラの特徴（APIレスポンスの文字列・証明書のパターン等）を追う重要性が改めて浮き彫りになった。 そしてこの件は、プラットフォームの利便性とセキュリティのトレードオフを改めて考えさせる。「アプリを離れず使える」はユーザー体験として価値があるが、それがそのまま攻撃面（アタックサーフェス）の拡大につながる。Telegramに限らず、LINEやSlackのアプリ内ブラウザも同じリスク構造を持つ。 「禁止すれば解決」という発想は現実的ではない。ユーザーはより便利な手段を常に選ぶ。組織としてできることは、デバイス管理・ポリシー・教育の組み合わせで「安全に使える仕組み」を用意し、攻撃の機会を減らすことだ。今回の攻撃でいえば、MDMによるサイドロード禁止は「明日すぐ設定できる対策」として真っ先に取り組む価値がある。 AIを使ったマーケティング最適化まで組み込んだ詐欺基盤が登場している以上、防御側もAIを活用した異常検知や脅威インテリジェンスの導入を真剣に検討すべき時期に来ている。 出典: この記事は Telegram Mini Apps abused for crypto scams, Android malware delivery の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Defenderが、世界中で広く信頼されているDigiCertのルート証明書を「Trojan:Win32/Cerdigent.A!dha」として誤検知し、一部のシステムではWindowsの信頼ストアから証明書を削除するという事態が発生した。セキュリティ製品がむしろシステムを壊す側に回るという皮肉な状況は、エンタープライズ環境の管理者にとって決して他人事ではない。 何が起きたか 4月30日に配信されたDefenderのシグネチャ更新以降、以下の2つのDigiCertルート証明書が誤ってマルウェアと判定された。 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 DDFB16CD4931C973A2037D3FC83A4D7D775D05E4 問題の深刻さは「アラートが出た」だけでは終わらなかった点にある。影響を受けたシステムでは、これらの証明書がWindowsの証明書ストア（HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\）から実際に削除されたのだ。 ルート証明書が消えると、そのCAが発行した証明書を信頼する経路が断ち切られる。TLS通信のエラー、コード署名の検証失敗、アプリケーションの起動拒否など、影響は連鎖的に広がりうる。一部のユーザーは「ウイルスに感染した」と誤解しOSを再インストールしたという報告もあり、混乱の大きさがうかがえる。 MicrosoftはSecurity Intelligence更新バージョン1.449.430.0で修正を適用しており、現時点での最新版は1.449.431.0。修正版では誤検知の解消に加え、削除された証明書の復元も行われると報告されている。 手動での更新確認手順 自動更新を待たずに対処したい場合は以下の手順で強制確認できる。 「Windowsセキュリティ」を開く 「ウイルスと脅威の防止」→「保護の更新」 「更新プログラムの確認」をクリック エンタープライズ環境ではWSUS/Microsoft Updateのポリシーにより自動適用が遅延している場合もある。管理下のデバイスのシグネチャバージョンを一括確認し、影響範囲を把握することが急務だ。 背景：DigiCertで起きていたセキュリティインシデント この誤検知騒動と時期を同じくして、DigiCert自身がセキュリティインシデントを公表している。4月初旬、攻撃者がサポート担当者にマルウェア入りZIPファイルを送付するソーシャルエンジニアリングを試み、複数回のブロックの末に1台の端末への侵入に成功。さらに別のシステムも一時的に侵害された。 侵害されたサポート環境では、承認済みのEVコード署名証明書の「初期化コード」へのアクセスが可能だったため、攻撃者は正規の証明書を取得し、マルウェアの署名に悪用した。DigiCertは60件のコード署名証明書を失効させており、うち27件は「Zhong Stealer」と呼ばれるマルウェアキャンペーンに関連するものだった。 今回のDefenderによる誤検知は、このインシデントへの対応としてMicrosoftが追加したシグネチャが、悪用された証明書と正規のルート証明書の指紋を取り違えたことが原因と見られる。 実務への影響——IT管理者が今すぐやるべきこと 1. シグネチャバージョンの確認 管理下の全Windowsデバイスのシグネチャバージョンを確認し、1.449.430.0以降に更新されているかをチェックする。Microsoft Defenderのバージョン情報はPowerShellで Get-MpComputerStatus コマンドから確認できる。 2. 証明書ストアの確認 影響を受けた可能性があるシステムでは、以下のサムプリントを持つ証明書がAuthRootストアに存在するか確認する。修正版適用後でも復元されていない場合は、certlm.mscやPowerShellで手動インポートが必要になりうる。 3. アプリケーション動作確認 TLS証明書の検証やコード署名に依存するアプリケーションの動作を確認する。特にDigiCertのルートCAを信頼チェーンの起点として使っているサービスは影響を受けている可能性がある。 4. WSUSポリシーの一時緩和を検討 今回のケースでは「すぐにシグネチャを当てる」よりも、逆に「修正版の展開を急ぐ」という状況になった。緊急時の展開パスが整備されているかを確認する良い機会でもある。 筆者の見解 セキュリティ製品がルート証明書を誤って削除するという今回の出来事は、「誤検知で済んだ」では片付けられない問題をはらんでいる。証明書の信頼チェーンは、TLS通信からコード署名まで、現代のWindowsエコシステムのあちこちに組み込まれたインフラの基盤だ。そこを守るはずのセキュリティ製品が、一度のシグネチャミスでその基盤を削り取りうるという構造的なリスクが今回はっきりと示された。 MicrosoftのDefenderチームが迅速に修正版を展開し、削除された証明書を復元する動きを取ったことは評価したい。しかし率直に言えば、AuthRootのような信頼ストアを管理するコンポーネントは、誤検知時の処理にもっと慎重さが必要だったはずだ。「削除」という不可逆な操作を伴う場合には、少なくとも管理者への確認プロセスや猶予期間が設けられていてよかった。 Defenderはエンタープライズにとって事実上必須のセキュリティ基盤になっている。それだけにシグネチャの品質管理と、万一の際のロールバック設計には一層の投資が求められる。こういった問題が繰り返されないよう、Microsoftにはシグネチャ更新のリグレッションテストプロセスを強化することを期待したい。 DigiCert側のインシデントも教訓が多い。サポートスタッフへのソーシャルエンジニアリング、エンドポイント保護の「センサーギャップ」、サポートポータルの過剰な権限付与——どれも日本のエンタープライズ環境で同様の問題が起きていないとは言い切れない。Just-In-Timeアクセスの考え方をサポートツールにも適用し、常時アクセス権を持つアカウントを極力排除することが、こうした侵害の被害を抑えることに直結する。 「今動いているから大丈夫」という現状維持バイアスがセキュリティ最大の敵だということを、今回の件は改めて思い知らせてくれた。 出典: この記事は Microsoft Defender wrongly flags DigiCert certs as Trojan:Win32/Cerdigent.A!dha の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Valveが毎月公開するSteam ハードウェア＆ソフトウェア調査（Steam Hardware & Software Survey）の最新データで、Steamユーザーの67.74%がWindows 11を使用していることが明らかになった。ゲーミングPCは一般的なビジネスPCよりもハードウェアのリフレッシュサイクルが早く、OS普及の先行指標として機能することが多い。Windows 10のサポートがすでに終了している現在（2025年10月末）、この数字が示す意味をIT現場の視点から紐解く。 なぜゲーマーはWindows 11へ移行したのか ゲーミングPCユーザーは、パフォーマンス向上を求めて定期的にハードウェアを刷新する傾向にある。Windows 11の前提要件であるTPM 2.0は2018年以降の多くのPCで満たされており、Direct Storage（高速NVMe SSDによるロード時間の大幅短縮）やAuto HDRといったゲーム向け最適化機能が移行の動機となってきた。「新しいハードを買ったら自然にWindows 11になっていた」というケースも多く、ゲーマーはある意味で自然な流れとしてアップグレードを消化してきたと言える。 残り約32%のWindows 10ユーザーは、旧ハードウェアの継続使用、互換性問題、あるいは単純な「変えたくない惰性」が理由と思われる。EOL後のOSでオンラインゲームを続けることはセキュリティリスクだが、ゲーマーコミュニティでの実利的な判断力は概して高く、徐々に移行が進むだろう。 Windows 11の「本当の価値」はセキュリティアーキテクチャ Windows 11で注目すべき変化は、ビジュアルの刷新よりもセキュリティ基盤の強化だ。カーネルモードドライバーの締め出し強化、Smart App Control、VBS（Virtualization-Based Security）のデフォルト有効化——これらは地味だが、マルウェアの侵入経路を根本から変えるレベルの変化だ。 Steamユーザーという実利的なユーザー層がこの「セキュアな基盤」へ先行移行しているという事実は、Windows 11の持つ本質的な価値を改めて証明していると言っていい。 実務への影響——IT管理者が今すべきこと 法人IT部門にとって、Steam調査データは「コンシューマーの話」と思われがちだ。しかし在宅勤務やBYOD端末の実態把握に、こうした外部データは有用な参考値になる。現場で考えるべきポイントは以下の通りだ。 Windows 10 EOL後の棚卸し: 管理端末でWindows 10が残っているなら、ESU（有償延長サポート）のコスト対効果を再評価し、移行計画を前倒しにすることを検討する 互換性の事前調査: 移行を阻んでいる業務アプリやドライバーを特定し、ベンダーへのアップデート要求またはアプリ入れ替えを具体的に進める ユーザー認識のアップデート: 「まだ動いているから大丈夫」という思考を変える。EOL後のOSはセキュリティパッチが供給されない状態が続くという事実を組織内で周知する 筆者の見解 67.74%という数字は「やっとここまで来たか」という感慨と、「残り約32%をどう動かすか」という課題を同時に示している。 Windowsのバージョンを細かく追うこと自体に以前ほどの意味はなくなってきたが、「セキュアな基盤に乗っているかどうか」は依然として重要な問いだ。Windows 11への移行は、新機能の享受というより、セキュリティリスクを回避するための「衛生行動」として捉えるべきだろう。 Microsoftには、移行の摩擦——特に古いハードウェア要件の壁や業務アプリ互換性の問題——をもっと積極的に取り除いてほしい。Windows 11に正面から取り組める力を十分に持っているのだから、移行を阻む障壁を減らす取り組みにもっと力を入れることを期待している。この67.74%がやがて90%を超えるとき、それが真の意味での「Windows 11の時代」の到来になる。 出典: この記事は Valve: 67.74% of Steam users run Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Engadgetが伝えたところによると、かつて「Ask Jeeves（アスク・ジーブス）」として親しまれた検索エンジンAsk.comが、2026年5月1日をもって正式にサービスを終了した。親会社InterActiveCorp（IAC）はサイト上に「25年間にわたって世界の質問に答えてきたAsk.comは、2026年5月1日に正式に閉鎖しました」という声明を掲載。検索事業全体を廃止する決定を下したと説明している。 Jeevesとは何者だったか Ask Jeevesは1996年に誕生した検索エンジンで、P・G・ウッドハウスの小説に登場するイギリス人執事「Reginald Jeeves」をモチーフにしたキャラクターが象徴だった。当時の検索エンジンがキーワードの羅列を前提としていたのに対し、Ask Jeevesは「What is the capital of France?（フランスの首都は？）」のような自然言語の質問文をそのまま入力できる設計を持っていた。 2006年、IACによってAsk.comへリブランドされ、執事キャラクターのJeevesは表舞台から退いた。しかしEngadgetのJackson Chen記者が指摘するように、Jeevesが育てた「フルセンテンスで検索する」習慣は今もGoogle検索ユーザーに受け継がれている。 なぜ今注目されるのか——現代AIとの意外な接点 Engadgetの報道では、Ask Jeevesの「自然言語による詳細回答」アプローチは、ChatGPTに代表される現代AIチャットボットの先駆けと言えるかもしれないと論じられている。キーワードマッチングではなく「意図を理解して答える」というコンセプトは、当時の技術的限界から十分には実現できなかった。しかし2022年以降に爆発的に普及したLLMベースのAIチャットボットは、まさにその理想を現代の技術で実現している。 インターネット初期を彩った仲間たちも次々と退場 Engadgetの記事が感傷的に指摘するように、Ask.comの閉鎖はひとつの時代の終わりを象徴する出来事だ。2013年にはAltaVistaが閉鎖し、AIM（AOLインスタントメッセンジャー）やAOLのダイヤルアップサービスも歴史の幕を下ろした。1990年代から2000年代にかけてインターネットに親しんだ世代には、懐かしさと寂しさが入り混じるニュースだろう。IACの声明は「Jeevesの精神は永続する（Jeeves’ spirit endures）」という言葉で締めくくられている。 日本市場での注目点 日本国内では、Ask Jeeves / Ask.comのブランド認知度はもともと限定的で、実際の利用者も少なかった。日本の検索市場はGoogleとYahoo! Japanが圧倒的シェアを占め続けており、今回の閉鎖が国内ユーザーに直接影響を与えることはほぼない。 ただしインターネットの歴史という観点では話が変わる。「自然言語で検索する」文化の素地を作ったパイオニアのひとつがAsk Jeevesであり、その思想は現在のAI検索体験に確実に受け継がれている。ChatGPTやPerplexity AIに日本語で気軽に質問を投げかけられる今日の環境は、こうした先達の試行錯誤の上に成り立っている。 筆者の見解 Ask Jeevesが示した「自然言語で質問する」というコンセプトは、当時の技術では理想論に過ぎなかった。検索エンジンとしての完成度ではGoogleに大きく劣り、市場から忘れ去られていった。しかしあの発想が間違っていたわけではない——単に30年早すぎただけだ。 今や誰もがAIアシスタントにフルセンテンスの質問を投げ込む。Ask Jeevesが夢見た世界は、まったく異なる技術的経路を経て、ようやく現実のものになった。 考えさせられるのは、「早すぎたアイデア」のほとんどは当時の技術的制約によって潰されてきたという事実だ。LLMの登場は、過去に「不可能」と諦められた多くのコンセプトを一気に「可能」に引き上げた。Ask Jeevesの閉鎖と現代AIの台頭を同時に眺めると、この30年のテクノロジーの進化がいかに非線形で劇的だったかを改めて実感する。 Jeevesよ、安らかに。あなたが追い求めたものは、形を変えて今の世界に生きている。 出典: この記事は Ask.com has shut down, marking the official farewell to the Internet’s favorite butler の内容をもとに、筆者の見解を加えて独自に執筆したものです。