Tech News JP

米連邦通信委員会（FCC）は、外国製の消費者向けルーターを禁止する規制の適用範囲を更新し、ポータブルWi-Fiホットスポット（MiFiデバイス）が禁止対象に含まれることを正式に明確化した。テクノロジーメディア「Ars Technica」が2026年4月24日に報じた。 規制の背景：何が禁じられているのか FCCのルーター禁止令は、トランプ大統領の「安全保障上のリスクがある外国技術の使用削減」指令に基づく措置だ。国防総省または国土安全保障省が安全保障上のリスクなしと判断しない限り、FCCは外国製の新モデルを承認しないというもの。 今回のFAQ更新で明確化された禁止対象デバイスは以下の通りだ。 家庭用のポータブルMiFi／Wi-Fiホットスポット機器 リテール販売でエンドユーザーが自己設置する小規模オフィス向けルーター 住宅用のLTE／5G CPE（顧客宅内設備） ISPや業者が設置する住宅用ルーター モデム・ルーター一体型の住宅用ゲートウェイ 逆に対象外となるのは、スマートフォンのテザリング（モバイルホットスポット）機能、企業・産業・軍用機器、フェムトセル、光回線終端装置（ONU）などだ。 Ars Technicaが指摘する「実質全メーカー対象」という現実 Ars Technicaは、業界団体「グローバル・エレクトロニクス・アソシエーション」のレポートを引用し、「ルーター内部のコンポーネントは台湾・韓国・日本・中国などで製造されており、米国企業であれ外国企業であれ、ほぼすべてのルーターメーカーが何らかの免除を取得しなければならない状況にある」と指摘している。つまり、中国系企業だけを狙い撃ちにしているように見えて、実態はグローバルサプライチェーン全体を巻き込む規制となっている。 その中でNetgearは主要メーカーとして初めてFCCから免除（Exemption）を取得し、Amazon傘下のEeroも今週取得に成功した。Ars Technicaによれば、過去にFCCの承認を受けた既存デバイスは、新たな免除なしに引き続き輸入・販売が可能とのことだ。 日本市場での注目点 日本での直接的な法的影響はないが、グローバルサプライチェーンへの波及という観点では無関係ではない。 注目ポイントは3つ： TP-Linkなど中国系メーカーの動向: 米国市場での継続販売が困難になれば、製品ラインナップや価格戦略がグローバルで変わる可能性がある。日本では引き続き選択肢に残るが、長期的なサポート体制は注視したい。 ポータブルルーターの入手性: SIMフリーのMiFiルーターは日本でも広く使われる。米国向け免除申請のコストが製品価格や発売タイミングに影響する可能性はある。 スマートフォンのテザリングは対象外: 今回の規制でも明確に除外されており、モバイル回線があれば当面の代替手段として問題なく使える点は実用上の重要なポイントだ。 筆者の見解 今回の規制で興味深いのは、「スマートフォンのテザリングは除外」という線引きだ。機能としては同じ「パケット転送」でも、主たる用途と形態によって判断が変わる——この柔軟性は消費者への配慮として現実的な落とし所だと思う。 一方で「道のド真ん中を歩く」観点では、主流メーカーの免除取得済み製品を選んでおけばリスクは最小化できる。ただし、すべてのメーカーが実質的に影響を受けるという現実は、「どこのブランドを買えば安心」という単純な話ではないことを示している。 ネットワーク機器の調達を検討する際、こうした政策的・地政学的リスクを選定基準の一つとして織り込む視点は、企業のIT担当者にとってこれから不可欠になってくるだろう。 関連製品リンク Amazon eero Pro 6E - メッシュwifi ルーター | Wi-Fi 6E | AXE5400 | 2.5Gbpsイーサネット | 最大wifi範囲190m² | 同時接続デバイス約100台 | 1ユニット ...

2026年4月、世界の数学界に衝撃が走った。数学の専門的訓練を受けたことのない23歳の青年・リアム・プライス氏が、ChatGPT Proを使って60年間にわたって世界トップクラスの数学者たちが解けなかった「エルデシュ問題」を解いたのだ。しかも、AIが採用したアプローチは人間がかつて試みたことのない完全に新しい手法だった。 エルデシュ問題とは何か この問題の主役は、20世紀最多の共著論文を持つ奇才数学者ポール・エルデシュが残した未解決問題群の1つだ。対象は「原始集合（primitive sets）」と呼ばれる整数の集合——集合内のどの数も他の数の約数にならないという性質を持つ。素数の集合はすべて自動的に原始集合になる（素数は1と自身以外に約数を持たないため）。 エルデシュはこの集合に「エルデシュ和」というスコアを定義し、2つの予想を立てた。1つ目は「このスコアの最大値は素数の集合が達成する」という予想で、スタンフォード大学のジャレッド・リヒトマン氏が2022年に博士論文で証明した。 問題になったのは2つ目だ。「集合の数が大きくなるほどスコアは下がり、最下限は1に近づく」という予想——この証明にリヒトマン氏を含む多くの著名数学者が挑んだが、誰も突破できなかった。 1プロンプトで突破した23歳 プライス氏がGPT-5.4 Proに送ったのはたった1つのプロンプトだった。AIが返したアプローチは、人間の数学者たちが全員見落としていた全く新しい手法だった。 フィールズ賞受賞者でカリフォルニア大学ロサンゼルス校のテレンス・タオ教授はこう語った。「人間の研究者たちは全員、最初の一手で微妙に間違った方向に進んでいた。ある種の思考の固定化があったようだ」 これはAIが「単に既存の知識を組み合わせた」のではなく、人間が踏み込まなかった領域へ踏み込んだことを意味する。専門家たちがこの問題について持っていた「常識的なアプローチ」こそが、60年間の障壁だったのだ。 AIが数学において示す本当の強み この出来事が特別な理由は2つある。 第一に、問題の「難しさの種類」だ。AIがこれまで解いてきたエルデシュ問題の多くは「AI実力の不完全なベンチマーク」と批判されてきた。しかし今回の問題は複数の著名数学者が本気で取り組んでいたもので、その重要性は別格だ。 第二に、「方法の新規性」だ。AIが見つけた手法は今後の同種の問題全般に応用できる可能性を秘めているとされる。単発の解答ではなく、新しい数学的道具を発見したかもしれない。 実務への影響——「先入観を持たない問題解決者」としてのAI この事例は、日本のエンジニアやIT管理者にも直接的な示唆を持つ。 AIを「確認ツール」ではなく「探索ツール」として使う: 多くの現場でAIは既存の実装の確認や文書作成に活用されている。しかし今回の事例が示すのは、AIに「自分たちが長年解けていない問題」を持ち込む価値だ。組織の中で「なぜか解決しないボトルネック」「誰も良い答えを出せない課題」こそ、AIに投げてみる価値がある。 プロンプトの技術より「持ち込む問題の質」: プライス氏は高度な数学訓練なしに成功した。重要だったのは洗練されたプロンプト技術ではなく、「解くべき問題を明確に定義してAIに委ねた」という姿勢だ。実務でも、問題の構造をきちんと整理してAIに持ち込むことが鍵になる。 「新人の目線」を意図的に作り出す: 専門家の先入観がボトルネックになるなら、あえて「その分野の文脈を持たないAI」に問いかけることで、専門家が見えなくなっていた解法が浮かび上がることがある。チームの中で長年解けていない問題があれば、試してみる価値は十分ある。 筆者の見解 今回の事例で最も印象的だったのは、タオ教授の言葉——「人間たちは最初の一手で微妙に間違えていた」という観察だ。 人間の専門性は強力だが、それ自体が「こう考えるべき」という固定された地図を作り出す。AIはその地図を持たない。これはバグではなくフィーチャーだ。「先入観のなさ」がAIを強力な問題探索エンジンにしている。 一方で、この事例をもって「AIが数学者に取って代わる」と結論づけるのは早計だ。プライス氏の成果はAIが生成したものだが、それが「本当に正しいのか」を検証し、数学界に適切に提示したのは人間だ。問題を選び、提示し、検証し、意味を解釈するループは依然として人間が担っている。 ただ、そのループの中に「AIに問題を委ねる」ステップが加わった意味は大きい。研究者にとっても、ビジネスの問題解決にとっても、「解き方を自分で考える前にAIに投げてみる」という習慣が、長年突破できなかった壁を崩す可能性を持っている。 AI活用の最前線は、「どう指示するか」から「どんな問題を持ち込むか」へとシフトしつつある。その視点の転換こそが、次のブレークスルーを生む鍵になるだろう。 出典: この記事は Amateur armed with ChatGPT solves an Erdős problem の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIが書いた論文が、人間の研究者と同じ土俵で査読を通過した。Sakana AI・UBC・ベクター研究所・オックスフォード大学の共同チームが発表した「AI Scientist v2」の話だ。単なるAI支援ツールではなく、仮説立案・実験設計・コード実行・データ分析・論文執筆まで、科学研究のすべてのフェーズを自律的に担うエンドツーエンドのエージェントシステム——その論文がICLRワークショップの査読をパスした。これは単なる技術的進歩ではなく、「AIが科学者になりうる」という概念実証だ。 AI Scientist v2とは何か 前バージョン（v1）との最大の違いは2点ある。 1. 人間作成のコードテンプレートへの依存をゼロにした v1では、実験を動かすための雛形コードを人間が用意する必要があった。v2ではその制約を撤廃し、多様な機械学習ドメインに汎化できる設計になった。特定分野に縛られず、幅広いテーマで研究を自律実行できる点が大きな進歩だ。 2. 「プログレッシブ・エージェンティック・ツリーサーチ」の導入 ここがv2の技術的核心だ。専用の「実験管理エージェント（Experiment Manager Agent）」がツリー構造で探索を管理し、仮説の優先度付け・実験の枝刈り・有望なアプローチへのリソース集中を自律的に判断する。モンテカルロ木探索（MCTS）の思想を科学的発見プロセスに応用したものと理解すると分かりやすい。さらに、図表の品質向上のためにVLM（Vision-Language Model）によるフィードバックループも統合されており、論文の「読みやすさ」まで自律的に改善するサイクルが組み込まれている。 実績：3本投稿して1本がICLR基準超え 研究チームはv2を使って3本の論文を完全自律生成し、ICLRの査読付きワークショップに投稿した。うち1本が「平均的な人間の採択スコアを超えた」という結果を残した。完全AI生成の論文がピアレビューを突破したのは、これが初めての事例とされており、Natureにも取り上げられるなど研究コミュニティでの注目度は高い。コードはオープンソース化されており、再現・拡張が可能な状態になっている。 日本の研究・開発現場への影響 日本ではまだ「AIに論文は書けない」という感覚が根強いが、この成果はその前提を覆す。実務的な観点で整理すると： 研究加速の可能性: 同じリソースで実験サイクルを何倍も回せる。PoC段階のアイデアを短期間で検証し、有望なものを人間の研究者が深掘りする分業体制が現実的になる 技術文書生成への転用: ICLRレベルの論文を自律生成できる仕組みなら、技術レポートや設計ドキュメントの草案生成への応用は現時点でも十分視野に入る 査読・信頼性の議論: AI生成研究が増加した場合の査読プロセスの信頼性確保は、日本のアカデミアでも早急に議論が必要なテーマだ。品質保証の仕組みをどう設計するかは、受け入れ側の課題として顕在化してくるだろう 筆者の見解 このシステムが面白いのは、「AIが論文を書いた」という事実そのものより、その設計思想にある。 ツリーサーチで仮説を展開し、実験を回し、結果を評価し、より有望な枝に投資する——これは自律エージェントが「判断・実行・検証」のサイクルを繰り返す構造そのものだ。途中で人間が確認を求められることなく、エージェント自身がループを回し続ける。これが、指示に対して一回答えを返す「副操縦士型」との本質的な違いだ。 AI Scientist v2は、この「自律ループ型」アーキテクチャが研究分野でも機能することを実証した。今後このアプローチが機械学習研究の外——法規制の調査、市場分析、バグの自律修正——へと展開されていくことは想像に難くない。研究者でなくても、エンジニアやアーキテクトとして「このループ構造を自分の仕事にどう持ち込むか」という視点で読むと、得られるものが多い論文だ。 科学的発見の自動化という壮大なビジョンが、少しずつ現実の輪郭を帯びてきた。 出典: この記事は The AI Scientist-v2: Workshop-Level Automated Scientific Discovery via Agentic Tree Search の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のセキュリティに関わる重要な変更が、2026年4月のアップデートで静かに入っている。Windows Securityアプリに、Secure Boot証明書の有効期限状態を視覚的に確認できる新UIが追加されたのだ。6月という期限まで残り約2ヶ月。把握していないシステム管理者は今すぐ確認したい。 Secure Bootとは、なぜ証明書が重要なのか Secure Bootは、PCの起動時にデジタル署名を検証し、正規のブートローダーとOSのみを実行させるセキュリティ機能だ。Windowsが読み込まれる前の段階で悪意あるソフトウェア（ブートキット・ルートキット）の侵入を防ぐ、セキュリティの最初の防壁といえる。Windows 11はSecure Bootを必須要件としており、すべてのWindows 11デバイスが影響を受ける。 このSecure Bootの正常動作に必要なデジタル証明書が、2026年6月に有効期限を迎える。Microsoftは以前から告知してきたが、対応確認の手段がPowerShellコマンドという、一般ユーザーには敷居が高い方法だった。 4月アップデートで何が変わったか 今回追加されたのは、Windows Securityアプリ内でSecure Bootの証明書状態を一目で把握できるUIだ。 確認手順はシンプルだ。Windowsの検索バーに「Windows Security」と入力して起動し、「デバイスセキュリティ」→「セキュア ブート」のセクションを確認する。 表示されるメッセージで状態がわかる： 「Secure Bootが有効になっています。起動時に悪意のあるソフトウェアが読み込まれないよう保護されています」 → 証明書は最新。6月以降も問題なし 「Secure Bootは有効ですが、更新が必要な古い起動信頼構成を使用しています」 → 証明書がまだ古い状態。更新が必要 従来はPowerShellで証明書ストアを直接確認するしかなかったが、このUIによって技術的な知識がないユーザーでも状態確認が可能になった。 証明書の更新方法 証明書の更新は、Windows Updateを通じて自動的に適用される。Microsoftは6月までに対象のすべてのWindows 11 PCへ証明書アップデートを配布する予定だ。 対応のために確認しておくべきこと： 自動更新を有効にする — Windows Updateが手動になっている環境では、自動更新へ切り替えるか、定期的な手動更新を確実に実施する 診断データの送信を許可する — 「設定 > プライバシーとセキュリティ > 診断とフィードバック」から有効化。システムが適切な証明書を判断するために使われる Microsoftは今後、5月のPatch Tuesdayまでにさらなる通知機能の追加も予定しており、セキュリティ可視化の強化が続く見込みだ。 日本のIT現場への影響 日本の企業環境で特に注意したいのは、WSUSや社内パッチ管理ツールを使用している環境だ。自動更新を意図的に無効化し、管理された手順で更新を適用している場合、担当者がこの証明書アップデートを認識していないと、6月以降に問題が表面化する可能性がある。 個人ユーザーは自動更新を有効にしていれば基本的に問題ないが、企業の管理者は以下を今すぐ確認しておきたい： 管理下のWindows 11デバイスで証明書の状態を把握しているか パッチ管理の仕組みが、この証明書更新を適切に配信するよう設定されているか エンドユーザーがWindows Securityのメッセージを見たとき、自己対処または問い合わせができる案内が整備されているか 「今起動できているから大丈夫」という判断は、このケースでは通用しない。証明書の有効期限は静かにカウントダウンしている。 筆者の見解 率直に言って、今回の変更は正しい方向性だと思う。セキュリティ情報をエンドユーザーが視認できる形で提供する姿勢は評価したい。PowerShellを叩けなければ状態確認できません、では守れるものも守れない。 ただ、もう少し早くこのUIを用意しておいてほしかった、というのが正直なところだ。6月の期限が迫ってからの追加では、周知が行き届かないデバイスが出てくる可能性を否定できない。証明書管理は本質的に「気づいたときには期限切れ」になりやすい性質を持っている。 それでも、こうした「ユーザーが状態を把握できる仕組み」を積み重ねていくことには意義がある。セキュリティはわかりにくいから避けられる、という構造を少しずつ変えていく取り組みとして、引き続き注目していきたい。この調子で、セキュリティの可視化をもっと積極的に進めてほしいと思う。 出典: この記事は Windows 11 now shows if your Secure Boot certificates are ready for June の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが2026年5月1日より、Windows 365 Businessの価格を一律20%引き下げることを発表した。円安・物価高によるPC調達コスト増に悩む日本の中小企業（SMB）にとって、クラウドデスクトップ移行を本格的に検討する現実的な機会になりうる。 Windows 365 Businessとは Windows 365 Businessは、MicrosoftがSMB向けに提供するクラウドPC（Cloud PC）サービスだ。ブラウザや専用アプリ経由でWindows環境にどこからでもアクセスでき、物理PCの調達・管理コストを削減できる。Azure Virtual Desktop（AVD）と異なり、管理がシンプルで、専任IT担当者が少ない中小企業でも導入しやすい設計になっている。 今回の変更点 変更は主に2点だ。 20%の価格引き下げ 2026年5月1日以降、新規サブスクリプションには新価格が即時適用される。既存ユーザーは次回の契約更新タイミングで自動的に新価格へ移行するため、今すぐ手続きは不要だ。すべてのWindows 365 Businessプランが対象とされている。 オンデマンド起動体験の導入 あわせて「オンデマンド起動（On-Demand Start Experience）」が新たに導入される。一定期間使用されていないCloud PCを自動的に休止状態へ移行させ、次回接続時に起動する仕組みだ。再起動に若干の待ち時間が生じる可能性があるが、影響は軽微とされている。 この機能の背景にあるのは、常時起動による非効率なコスト構造だ。稼働していないCloud PCにも課金が発生するという従来の問題に対し、実際の利用パターンに合わせた自動休止で緩和しようとしている。Azureの「使った分だけ払う」原則をWindows 365にも持ち込んだ、成熟の証といえる改善だ。 なぜこれが重要か 日本のSMBにとって、PCのライフサイクル管理は慢性的なコスト課題だ。円安・物価高の影響で新規PC調達コストは上昇しており、「壊れるまで使い続ける」現場も少なくない。Windows 365 Businessは初期投資ゼロで最新Windows環境をサブスクリプションで使えるモデルであり、20%の値下げはそのハードルをさらに下げる。 また、IntuneとEntra IDを軸に運用しているMicrosoft基盤の組織には親和性が特に高い。特定ユーザーだけCloud PCに移行し、残りはオンプレPCのままという段階的なハイブリッド移行も現実的な選択肢になる。 実務での活用ポイント IT担当者・管理者へのヒント: コスト試算を今すぐ行う: 現行のPC調達・保守コスト（ハードウェア費＋サポート費＋IT工数）とWindows 365 Businessの年間コストを比較しよう。20%引き下げ後の価格ベースで試算すれば、損益分岐点が以前より見えやすくなる オンデマンド起動の対象ユーザーを設計する: 週数回しかアクセスしないパートタイムスタッフや、プロジェクト期間限定の外部委託者はオンデマンド起動と相性がいい。フルタイムのヘビーユーザーとは分けて設計するのが合理的だ 更新タイミングを把握しておく: 既存ユーザーは次回更新時に自動で新価格が適用される。年単位のサブスクリプションであれば更新日を予算計画に組み込んでおこう IntuneでCloud PCとオンプレPCを統一管理: 同一のIntuneポリシーを適用できる点を活かし、「少人数のPoC導入」から始めるのが失敗の少ない進め方だ 筆者の見解 Windows 365 Businessの20%値下げは、単なる価格調整ではなく、MicrosoftのSMB市場への本気度を示すシグナルだと受け取っている。 ここ数年、クラウドPCの概念自体は広まったが、コストを理由に採用を見送るケースが多かった。特に日本のSMBでは「高い・難しい・必要性がわからない」という三重の壁があった。今回の値下げとオンデマンド起動の組み合わせは、その壁の一つを確実に崩す動きだ。 オンデマンド起動については、Azureで培ってきたコスト最適化の思想がWindows 365にも染み出してきた証と見ている。止まっているものには払わない——これはクラウドの基本原則であり、ようやくCloud PCサービスとしての成熟を感じられる改善だ。 ただし、コストだけが採用障壁ではない。「Cloud PCで本当に業務が回るのか」という運用上の不安、ネットワーク品質への懸念、既存システムとの接続要件など、実装レベルの課題は引き続き残る。値下げで背中を押されても、PoCを経ずに全社展開するのはリスクが高い。 Microsoftにはこの価格改定をきっかけに、SMB向けの導入支援・国内事例の公開もセットで強化してほしい。価格を下げた後に何を見せるか——そこで初めて、真の意味でのSMB市場への浸透が始まると思っている。Microsoftには、その力が十分にあるはずだ。 出典: この記事は Microsoft Cuts Windows 365 Business Prices by 20% Starting May 1, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 Copilotに大きな機能追加が入った。Adobe Express、Figma、Optimizely、Dynamics 365など、現場で日常的に使われているビジネスアプリをCopilot Chat内でエージェント経由で直接操作できる新機能だ。「会話の流れを止めずに業務を完結させる」という思想が、プラットフォームとしての姿かたちを変えつつある。 エージェントが「コンテキストの橋」になる これまでのCopilot連携は、あくまでMicrosoft製品の枠内にとどまっていた。SharePointのドキュメントを要約する、Outlookのメール文面を生成する——便利ではあるが、それはあくまで「Microsoftの中で完結する便利さ」だった。 今回の発表は、その壁を外部アプリとの連携まで広げるものだ。たとえばマーケティング担当者がCopilot Chatでキャンペーンの方向性を議論しながら、その場でAdobe Express上のアセット生成を指示し、同じ会話の中でOptimizelyのA/Bテスト設定まで完結させる——という使い方が想定されている。Figma連携ではデザインコンテキストを保ったままフィードバックや変更依頼ができるようになる。 Dynamics 365との連携は特に営業・CRM系の業務で効果が大きいだろう。商談状況の更新や顧客レコードの参照を、TeamsやOutlook上の会話フローを離れずに行えるようになる。 「ツールの切り替え」が生産性を奪っていた 業務効率が上がらない原因の一つに「コンテキストスイッチング」がある。メールを書いていてCRMを開き、データを確認してチャットに貼り、デザインツールに切り替えて……というサイクルは、実は非常に高コストだ。認知負荷のみならず、ツール間での情報の断絶が「抜け漏れ」や「整合性の崩れ」を生む。 今回のエージェント連携は、この問題に正面から向き合う設計思想を持っている。Copilot Chatを「中心軸」として、そこから各アプリへの操作を統合することで、ユーザーが意識するコンテキストを一本化しようとしている。 実務への影響──日本のエンジニア・IT管理者へ まず確認すべき点は「ライセンスとロールアウトのタイミング」だ。 現時点ではMicrosoft 365 Copilotライセンスが前提で、各アプリ連携はMicrosoft AppSource経由で展開される。日本テナントへの展開スケジュールは公式ドキュメントを必ず確認してほしい。 エージェントの「信頼境界」設計も重要だ。 外部アプリとCopilot Chatをエージェントでつなぐということは、データの流れも外部に及ぶことを意味する。特にDynamics 365のような顧客データを扱うケースでは、どのデータがCopilotのコンテキストに渡るかを情報セキュリティの観点でレビューすることが必須になる。管理者向けのポリシー制御が十分に用意されているかも確認しておきたい。 Power Platformとの住み分けも整理が必要だ。 すでにPower AutomateやPower Appsで業務フローを構築している企業では、「Copilotエージェント連携」と「既存の自動化フロー」が重複するシナリオが出てくる可能性がある。二重管理にならないよう、事前に整合性を計画したい。 筆者の見解 M365がバラバラに使われる現場を多く見てきた立場から言うと、この方向性は正しい。Microsoft 365はそもそも「統合して使うことで価値が出るプラットフォーム」であり、チームによってツールの使い方が完全にバラバラという状況は、コスト対効果として見ると本来の価値をまったく引き出せていない。 今回のエージェント連携は、その「統合のご利益」を外部アプリにまで広げる試みとして、理念としては評価できる。Adobe ExpressやFigmaといった現場でのデファクト級ツールをCopilotから操作できるようになれば、「Copilotを開く動機」が確実に増える。ここ数年のCopilotをめぐる議論では「結局、単独で使う価値をどこで示せるか」という問いが繰り返されてきた。外部エコシステムとの連携強化は、その回答の一つになりうる。 ただ、正直に言えば「機能の発表」から「現場で当たり前に使われる状態」までにはまだ距離がある。エージェントの設定のしやすさ、動作の安定性、管理者からのガバナンス制御——この辺りが実運用の鍵を握る。素材は揃ってきた。それをどれだけ洗練された体験に磨き上げられるか、今後の実装に期待したい。 M365の統合プラットフォームとしての底力は本物だ。この方向性を着実に進化させてほしいと思う。 出典: この記事は Bring your everyday business apps into the flow of work with agents in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365の中核アプリであるWord・Excel・PowerPointにおいて、Copilotのエージェント機能（Agentic Capabilities）が正式にGA（General Availability）となった。単に「文章を補完する」「数式を提案する」という段階を超え、複数ステップの操作をドキュメント内で自律的に実行できるようになったことは、Officeの使い方そのものを問い直すターニングポイントだ。Word週次利用52%増、Excel67%増という数字も、単なるバズワードではなく実際の職場での受け入れを示している。 エージェント機能とは何か これまでのCopilotはどちらかといえば「サジェスト型」だった。ユーザーが指示を出し、AIが結果を返し、ユーザーが確認してOKを出す——この一往復を繰り返す構造だ。エージェント機能はここが根本的に違う。 アプリネイティブな操作を、複数ステップにわたって自律的に実行する。たとえばWordなら、「この報告書のすべての数字を最新データに更新して、エグゼクティブサマリーを書き直して、目次も整えて」という指示を一度出せば、Copilotが順番にそれをこなしていく。Excelなら「このデータを分析して傾向を特定し、グラフを作成して、ピボットテーブルを更新して」といった一連の作業フローを自律実行できる。 実務への影響 反復作業からの解放 日本のOfficeユーザーが日常的に行っている「テンプレートへの転記」「月次レポートの数字更新」「プレゼン資料のフォーマット統一」といった作業は、エージェント機能の主戦場だ。技術的には難しくないが時間がかかり、ミスも生じやすい——まさにAIが得意とする領域だ。 IT管理者が押さえるべきポイント エンタープライズ環境では、Copilotのエージェント機能にどこまでの権限を与えるかが重要な管理ポイントになる。エージェントが「自律的に動く」ということは、それだけアクセス権設計が重要になるということでもある。Microsoft Purviewとの連携でデータ保護は担保されているが、最小権限の原則（Principle of Least Privilege）の再確認と、機密ラベルの適切な設定を改めて確認しておくことを強くお勧めする。 アプリ別・活用のヒント Word: 定型報告書の自動更新・リサーチ情報の統合に最適。スタイルや書式の統一作業を丸ごと委ねると効果が出やすい Excel: データクレンジングと分析の組み合わせ、ダッシュボード更新の自動化が狙い目。手作業で繰り返していたVBA的な処理を自然言語で代替できるケースが増える PowerPoint: ブランドガイドラインに沿ったスライドの再フォーマットは、人手でやる必然性がほぼなくなりつつある 筆者の見解 エージェント機能という方向性そのものは、正しいと思っている。「一言指示して、あとは任せる」——これがAI活用の本来の姿であり、Copilotがその路線に舵を切ったことは素直に評価したい。 ただ、率直に言うと「これがCopilotの真の実力の発揮場所なのか」という問いは残る。WordとExcelとPowerPointというMicrosoftが20年以上かけて構築した牙城で動くのは、当然といえば当然の話だ。もったいないのはその先——TeamsのミーティングデータとOutlookのコミュニケーション履歴とSharePointのドキュメントが有機的に連携し、ビジネスの文脈を理解した上で提案・実行できる状態——にまだ十分に踏み込めていないことだ。 Microsoft 365は個別アプリの集合体ではなく、統合プラットフォームとして使ってこそ真価を発揮する。エージェント機能がOfficeアプリ内で完結するだけでなく、TeamsやOutlookとシームレスに連携し、M365全体を跨いだ業務自律化につながる日が来れば、「Copilotで業務が変わった」と心から言えるようになるだろう。 Microsoftにはその力が確かにある。だからこそ、まずはWord・Excel・PowerPointで確実にエージェントを使い倒しながら、次のフェーズを期待を込めて待ちたいと思っている。 出典: この記事は Copilot’s agentic capabilities in Word, Excel, and PowerPoint are generally available の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Meta（メタ）が2026年にスマートウォッチを発売する計画を進めていると、Huawei Centralをはじめとする複数の海外テックメディアが報じている。同社がスマートウォッチの開発計画をキャンセルしてから約4年——新世代「Ray-Ban Display」スマートグラスとの同時発表も視野に入れた、ウェアラブル戦略の本格的な再始動として業界の注目を集めている。 4年ぶりの復帰——Metaのウェアラブル戦略とは Metaは2022年、カメラを内蔵するなど独自設計のスマートウォッチプロトタイプを開発しながらも、市場投入を断念した経緯がある。今回の計画は、同社がRay-Banシリーズで実証したスマートグラス市場での成功を足がかりに、ウェアラブル全体のエコシステムを構築する意図が透けて見える。 特に注目されるのは、次世代「Ray-Ban Display」との連携だ。現行のRay-Ban Metaスマートグラスはすでに音楽再生・通話・AIアシスタント機能を搭載し、一定の市場を獲得している。スマートウォッチをその中核に据えることで、グラスとの通知管理・フィットネストラッキング・決済機能などを連携させるプラットフォームとしての役割が想定されている。 海外メディアが伝える注目ポイント Huawei Centralの報道によると、現時点でスペック・価格・発売時期の詳細は未公表だ。ただし、業界関係者の間では以下の点が議論されている。 期待される差別化ポイント Apple Watch・Galaxy Watchという二大勢力とは異なる、AR/VRエコシステムとの連携による独自体験 Ray-Ban Displayとのペアリングによる「グラス＋ウォッチ」のシームレスな情報連携 Meta AIを中核に据えたウェアラブルAIアシスタントとしての機能 懸念される課題 4年間のブランクを経た再挑戦であり、完成度と継続性への信頼構築が必要 Ray-Banグラスが未展開の地域では、連携体験の訴求が難しい Meta AIの実力が競合AIアシスタントと比較してどこまで到達しているか 日本市場での注目点 MetaのRay-Banスマートグラスは現時点で日本では正式展開されておらず、スマートウォッチの日本発売についても具体的なスケジュールは不明だ。スマートウォッチ市場においては、日本でもApple Watchが圧倒的なシェアを持ち、Samsung Galaxy Watchシリーズがそれを追う構図が続いている。 Metaが日本市場に本格参入する場合、以下が焦点となる。 価格帯: Apple Watch SEに対抗できる競争力ある設定かどうか 決済対応: Suica・iD等、国内キャッシュレス決済への対応有無 Ray-Banグラスとのセット展開: グラス未展開のままでは連携体験の訴求が難しく、同時上陸が理想 筆者の見解 MetaがスマートウォッチをRay-Banエコシステムの「ハブ」として位置づけようとしている点は、戦略的な整合性がある。単体デバイスとしてApple Watchに正面から挑むのではなく、グラスと組み合わせることで独自の体験軸を設計する——Apple WatchがiPhoneエコシステムで圧倒的な強さを発揮してきたのと同じ構造だ。 ただし、この戦略が機能するかは、Meta AIが「副操縦士」にとどまるか、「自律的に動くエージェント」になれるかにかかっている。通知を横から差し込み続けるだけでは、ウェアラブルならではの「手を動かさなくていい」体験は生まれない。ハードウェアのフォームファクターを攻める力はRay-Banの実績が証明している。あとはAIレイヤーがそれに見合うものになるかどうか——2026年の正式発表が待たれる。 関連製品リンク Apple Watch SE 2nd Generation, GPS Model, 1.6 inches (40 mm), Starlight Aluminum Case with Starlight Sport Band, Refurbished ...

AIエージェントを実務で使い続けているエンジニアなら、一度は感じた不満があるはずだ。「昨日教えた内容を、今日またゼロから説明しなければならない」。セッションをまたぐたびにコンテキストを貼り直す作業が日常化している現場は少なくない。この根本的な課題に正面から向き合ったオープンソースプロジェクト「WUPHF」がHacker Newsで216ポイントを獲得し、議論を呼んでいる。 Karpathyのビジョンを、シンプルな技術スタックで実装 WUPHF（GitHub: nex-crm/wuphf）は、複数のAIエージェントが協調して働く「AIオフィス」フレームワークだ。その核心にあるのが、エージェントが読み書きを繰り返すことで文脈が蓄積し続ける知識基盤の仕組みである。 Andrej Karpathyがかねてから言及してきた「LLMネイティブな知識基盤」のビジョン——エージェントが自律的に知識を書き込み・参照し・更新するサイクルを回す——を実装したものだが、注目すべきはその技術スタックの選択にある。 多くの実装がPostgres、pgvector、Neo4j、Kafkaなどの重厚な構成を選択するなか、WUPHFはあえてMarkdown + Gitに立ち返った。 なぜMarkdown+Gitなのか 設計の根底にある思想は「ウィキはランタイムより長く生き続ける」というものだ。 Markdown: ツールが変わっても人間が読める。耐久性の高いフォーマット Git: 変更履歴が完全に残る。「誰がいつ何を知ったか」の来歴（プロベナンス）を追跡できる BM25（Bleve）+ SQLite: ベクトル検索なしで、500件・50クエリのベンチマークで再現率85%を達成 ベクトルDBは「特定のクエリクラスで再現率が閾値を下回ったときの事前決定フォールバック」として温存しており、最初から重い技術を持ち込まない設計思想が一貫している。 ノートブック→ウィキへの「昇格フロー」 WUPHFのアーキテクチャで特に興味深いのが昇格フロー（promotion flow）だ。 ノートブック: 各エージェントが作業中の観察・仮説・暫定的な結論を書き込む（エージェントごとのプライベート領域） 昇格: 繰り返し使えるプレイブック・検証済みファクト・確定した設定など、「永続する価値がある情報」を正規ウィキへ昇格。バックリンクが自動付与される エンティティファクトログ: team/entities/{kind}-{slug}.facts.jsonl に追記型で蓄積。N件ごとに合成ワーカーがエンティティサマリーを再生成 さらに、コミット履歴には「Pam the Archivist」という専用のgitアイデンティティが使われる。git log を見るだけで「AIエージェントが書いた記録」と「人間が書いた記録」が一目で区別できる。来歴管理として、シンプルながらエレガントなアプローチだ。 毎日実行されるlintクロンが矛盾・陳腐化エントリ・壊れたウィキリンクを検出し、知識ベースの品質を維持する仕組みも備わっている。 実務への影響 「1タスク=1セッション」という前提を超える 現在、多くの現場でAIエージェントを活用する場合「1タスク=1セッション」が暗黙の前提になっている。しかしWUPHFが示すように、エージェントが共有知識基盤を持つことで「前のエージェントが学んだことを次のエージェントが活用する」ループが成立する。これはエージェントの実用性を根本から変えうる変化だ。 軽量スタックからの出発 「AIのバックエンドには高性能ベクトルDBが必要」という思い込みを再考させる実装だ。Markdown + Git + SQLiteという手元にあるツールで出発し、必要になったらベクトル検索を追加するという順序は、多くのプロジェクトで参考になる。 セルフホスト・BYOKの選択肢 WUPHFはMITライセンスのセルフホスト型で「Bring Your Own Keys（BYOK）」方式だ。企業データをクラウドサービスに送らずに運用できるこのアーキテクチャは、セキュリティ要件が厳しい金融・製造・医療分野の日本企業にとって特に重要な選択肢となる。 筆者の見解 AIエージェントを「単発の指示→応答」で使い続ける限り、その能力は半分も引き出せない。エージェントが自律的にループで動き続けるためには、文脈を蓄積できる知識基盤が必要だ——これはごく当たり前の命題に見えるが、実装したシステムはまだ驚くほど少ない。 WUPHFのMarkdown+Gitという選択は一見古風に映るかもしれないが、筆者はむしろこれが本質に近いと見ている。耐久性・可搬性・来歴管理——これらは10年後も価値を保つ性質だ。pgvectorもNeo4jも、5年後に同じ場所にいるかどうかはわからない。シンプルな選択が長期的に強い、というのはソフトウェア設計の普遍的な教訓でもある。 「毎朝コンテキストを貼り直す」という現実から、「前回の続きから始める」世界への移行。その移行を支える知識基盤の設計が、これからのエージェント活用の重要テーマになると確信している。WUPHFはその方向性を示した一つの実装として、追いかける価値がある。 出典: この記事は Show HN: A Karpathy-style LLM wiki your agents maintain (Markdown and Git) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIを日常的に使い込んでいる人なら誰もが経験したことがあるはずだ。前回のセッションで詳しく説明したプロジェクトの背景、繰り返し伝えた自分の好みや制約——次のセッションを開くと、AIはまるで初対面のように「改めて教えてください」と言ってくる。この「AIの記憶喪失問題」に真正面から向き合うオープンソースプロジェクト「Stash」がHacker Newsで注目を集めている（158ポイント、67件のコメント）。単なるメモ機能の話ではない。エージェントが本当に「育つ」ための基盤インフラの話だ。 AIエージェントが抱える構造的な課題 現在のLLM（大規模言語モデル）は、セッションをまたいで記憶を保持する仕組みを標準では持っていない。毎回ゼロから始まる会話は、単なる不便さではなく、AIエージェントをビジネス用途で活用する上での根本的な障壁になっている。 プロジェクトの意思決定経緯、ユーザーの技術的背景、過去に試みて失敗したアプローチ——こういった文脈がセッションをまたいで消えてしまうと、エージェントはいつまでも「新人」のままだ。何百時間対話しても積み上がるものがない。 Stashのアーキテクチャ：記憶を構造化する6段階パイプライン StashはMCPネイティブ（Model Context Protocol）として設計された永続記憶レイヤーで、バックエンドにはPostgreSQLとpgvector拡張を採用している。バトルテスト済みの信頼性の高いインフラに乗せた点は、実運用を強く意識した現実的な選択だ。 記憶の処理は6つのパイプラインステージを経る： Episodes（エピソード）: 生の観察・会話ログをAppend-onlyで蓄積 Facts（ファクト）: エピソードから信頼度付きで合成された「信念」 Relationships（関係性）: エンティティ間の知識グラフ Patterns（パターン）: 高次元の抽象化・行動傾向 Goals / Failures / Hypotheses: 意図・学習・不確実性の管理 「エピソードが積み重なって事実になり、事実がパターンになり、パターンが知恵になる」——このコンセプトは人間の学習プロセスに近い設計思想であり、単純なログ保存とは一線を画す。 RAGとの決定的な違い 「RAGとどう違うの？」という疑問を持った人も多いだろう。Stashの説明は明快だ——「RAGはAIに高速な司書を与える。Stashは人生経験を与える」。 RAGはあくまで「検索エンジン」だ。事前に用意したドキュメントから関連情報を引き出すが、会話を通じてリアルタイムに学習することはなく、ユーザーのことを「知る」こともない。Stashはセッションをまたいで進行中の文脈を蓄積し、次の起動時に自動的に活用できるよう設計されている。目的が根本的に異なる。 ネームスペースによる記憶の組織化 実装上の特徴的な設計がネームスペースだ。/users/alice（ユーザーの情報）、/projects/restaurant-saas（プロジェクト固有の知識）、/self（エージェント自身の能力・限界）のように、記憶を階層的なパスで整理する。 読み取りは再帰的で、/projectsを参照すれば配下の全プロジェクトの情報が自動的に含まれる。書き込みは常に1つの正確なネームスペースへのみ行われ、意図しない情報の混入を防ぐ。 そして重要な点として、記憶はモデル非依存だ。あるモデルで蓄積した知識を別のモデルで利用できる。モデルを切り替えても記憶が消えない設計は、今後のモデル乗り換えを見据えると現実的に大きな価値がある。28種類のMCPツールとして公開されており、MCP対応のエージェント環境であればそのまま組み込める。 実務への影響 AIエージェント開発に取り組んでいるチームにとって、永続記憶は今後の必須インフラになる。Stashのようなオープンソース実装が登場したことで、独自実装のコストなしにメモリ機能を組み込める選択肢ができた。PostgreSQL + pgvectorというスタックは多くのチームが扱い慣れており、導入ハードルは比較的低い。 社内AIアシスタントを構築・運用している組織では、ユーザーごとの設定・好みの記憶、プロジェクト固有の業務知識の継続的な蓄積が実現できる。「毎回同じことを説明させる」ストレスは、現場のAI定着率に直結する問題だ。PostgreSQLを自前でホストできる点は、データガバナンスやセキュリティを重視する日本企業にとっても評価できる。 MCP対応エージェント環境を採用しているチームは特に恩恵が大きい。既存のエージェント構成に大きな変更を加えずに記憶レイヤーだけを追加できるアーキテクチャになっている。 筆者の見解 AIエージェントの実用性を決める要素は何かと問われれば、私は「記憶」と「自律性」の2つを挙げる。Stashはその前者に本質的な解を提供するプロジェクトだ。 エージェントが本当に価値を発揮するのは、単発の指示に応答するときではなく、継続的なタスクを自律的にループしながら遂行するときだ。そのループを支えるためには、前回の実行結果・学んだ知識・試みた失敗が次のイテレーションに引き継がれる仕組みが不可欠になる。セッションをまたいで文脈が消えるエージェントは、どれだけ優秀なモデルを乗せても「自律」とは呼べない——毎回リセットされる新人が何人いても組織は育たないのと同じだ。 実は私自身、日々AIエージェントを使い倒す中で、翌日起動したら昨日の文脈が消えている問題に何度もぶつかってきた。そのたびに「この10分の再説明は本当に無駄だ」と感じてきた。Stashのようなアプローチはまさにその痛点を直撃している。 MCPエコシステムの成熟とともに、こういった周辺インフラが急速に整備されていく流れは、エージェント開発者にとって強い追い風だ。日本のIT現場ではまだ「AIを試してみる」フェーズにいる企業が多いが、こういったインフラが揃い始めた今こそ、「自律的に動き続けるエージェント」を本気で設計するタイミングだと思っている。情報を追い続けるよりも、実際に動くものを作る経験に投資する——そのための土台が、確実に整ってきている。 出典: この記事は Open source memory layer so any AI agent can do what Claude.ai and ChatGPT do の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが「あなたの代わりに仕事をしてくれる」という謳い文句が溢れている。だが、そのエージェントは本当に「あなたの」ために動いているのだろうか。HTTPの標準化で長年貢献してきたMark Nottingham氏がこの問いを正面から取り上げ、技術コミュニティで注目を集めている。 コンピューターへの「無意識の信頼」の正体 人類がコンピューターを信頼してきたのには、それなりの歴史的根拠がある。かつてのソフトウェアはローカルで動き、「スプレッドシートはスプレッドシートの計算をする」「ワードプロセッサは文書を書く」という単純な一対一対応があった。機能しなければそれは「マルウェア」であり、別扱いだった。 スクリュードライバーはネジを回す。それ以外のことはしない。そういう道具の概念がそのままコンピューターにも投影されてきた。「私のスマートフォン＝私のために動く機械」という直感は、こうした長年の経験から染みついた認知バイアスだ。 インターネット接続が「信頼の構造」を複雑にした 問題はインターネット接続によって、機器・ソフトウェアが複数の主人に仕える構造になったことだ。あなたの「スマートウォッチ」は時刻を表示すると同時に、位置情報・活動データ・睡眠パターンをメーカーに送信しているかもしれない。アプリは「あなたのためのツール」でありながら、広告主のためのデータ収集装置でもある。 Notttingham氏はこれを「現代のビジネスはこの構造の隙間を利用することに長けている」と表現する。市場競争や法規制がある程度これを抑止するが、完全ではない。そしてほとんどのユーザーはその複雑さを認識しないまま使い続ける。 AIエージェント時代における「誰のエージェントか」問題 ここに自律型AIエージェントが加わると、問題は一段と複雑になる。 エージェントはあなたの代わりにメールを送り、スケジュールを組み、ファイルを操作する。その行動の連鎖は人間が一つひとつ確認するには速すぎる。だからこそ「自律型」の価値があるのだが、裏を返せば、エージェントが誰の利益に従って動いているかをユーザーが把握しづらい構造になる。 Webの世界には「User-Agent」という概念がある。ブラウザはユーザーの代理として振る舞う。しかし現在のAIエージェントには、こうした「ユーザーエージェントとしての役割を明確に定義する仕様」が存在しない。エージェントを提供するサービス事業者は、ユーザーの指示を優先するのか、自社のサービス利用規約を優先するのか、規制当局の要求に応じるのか——その優先順位が明示されていない。 Notttingham氏が提起するのはまさにここだ。自律型AIがWebやインターネットのインフラと深く統合される時代において、「誰のための自律性か」を技術的・制度的に定義するレイヤーが必要だという主張である。 実務への影響——エンジニア・IT管理者が今すぐ考えるべきこと 1. 導入するエージェントの「委任構造」を確認する どのエージェントにどこまでの権限を与えるかを設計する際、「このエージェントはユーザーの指示と事業者の利益が衝突したとき、どちらに従うか」を利用規約レベルで把握しておくことが重要だ。特にメールの送信・ファイル操作・外部API呼び出しといった副作用を持つ操作には注意が必要になる。 2. 「確認を求めない設計」と「説明責任」のバランス 自律型エージェントの価値は人間の確認を減らすことにある。しかし、何を実行したかのログと監査証跡を確保することは、組織として必須だ。エージェントが何をしたかを後から検証できる設計を標準化しておく。 3. 企業でのAIエージェント導入ガバナンス Microsoft 365 環境でCopilot系エージェントを展開する際も、「このエージェントは社内データをどこに送るか」「どのリソースに対してどの権限を持つか」をMicrosoft Entra・Purviewのポリシーと合わせて設計することが求められる。AIガバナンスは「禁止するか否か」ではなく、「安全に使える仕組みを先に作る」という発想で臨むべきだ。 4. 標準化動向のウォッチ Model Context Protocol（MCP）やAgent-to-Agentプロトコルなど、AIエージェント間の通信を標準化する動きが加速している。Nottingham氏のような標準化の第一人者がこの問題を提起している意味は大きく、IETFやW3Cレベルの議論に注目しておく価値がある。 筆者の見解 この記事が提起する問いは、AIエージェントの「本質的な価値」をどこに置くかという議論と直結している。 「副操縦士（Copilot）」モデルの限界は、まさにここにある。エージェントが逐一ユーザーに確認を求め、承認を得てから動くモデルは、ユーザーの認知負荷を減らさない。しかし一方で、確認をすべて省いたまま「誰のために動くか」の定義が曖昧なエージェントは、ユーザーの信頼に値しない。 本当に意味のある自律型エージェントとは、ユーザーの目的を理解し、ユーザーの利益を最優先に、自律的に判断・実行・検証を繰り返すものだ。それを実現するには、技術的な実装の前に「ユーザーエージェントとしての役割定義」という概念設計が必要になる。 MicrosoftはAzure AI Foundry・Copilot Studioなどを通じてエンタープライズ向けエージェント基盤を急速に整備している。これは評価できる方向性だ。ただ、エージェントの「信頼構造」——誰の命令を最優先に扱うか、どこまで自律的に動くか——の設計指針を、もっと明確にユーザー・管理者に提示してほしい。強大なプラットフォームと広大なユーザーベースを持つMicrosoftだからこそ、業界標準となる信頼モデルを率先して示せる立場にある。そのポテンシャルを存分に発揮してほしいと思う。 AIエージェントが「あなたのエージェント」として機能する世界は、まだ設計途上だ。今こそ、その設計に声を上げるべき時期である。 出典: この記事は What’s missing in the ‘agentic’ story: a well-defined user agent role の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teamsを通じたヘルプデスクなりすまし攻撃が、新たなフェーズに入った。Google傘下のセキュリティ機関Mandiantは、脅威グループ「UNC6692」が独自開発のマルウェアスイート「Snow」を用いた標的型攻撃を展開していることを報告した。メール爆撃→Teamsなりすまし→マルウェア展開→Active Directory奪取という一連の攻撃チェーンは、組織の信頼構造そのものを武器に使う。 攻撃の全体像——4段階で組織を内側から崩す 攻撃は「メール爆撃（email bombing）」から始まる。標的に大量のスパムメールを送りつけて混乱させ、「スパムをブロックするパッチがある、サポートに連絡を」という心理的誘導を作り出す。そこに現れるのが、Microsoft Teams上でIT担当者を装った攻撃者だ。 被害者はパッチのインストールリンクをクリックするよう誘導される。実際に実行されるのはドロッパーであり、AutoHotkeyスクリプト経由で悪意あるChromeエクステンション「SnowBelt」がロードされる。この拡張はヘッドレスのMicrosoft Edgeインスタンス上で動作するため、被害者の画面には何も表示されない。同時にスケジュールタスクとスタートアップフォルダへのショートカットが作成され、再起動後も継続する。 Snowスイートの3層構造 「Snow」は互いに連携する3つのコンポーネントで構成されている。 SnowBelt（Chromeエクステンション）: 持続性の確保と、オペレーターからのコマンドをバックドアへ中継する役割を担う。 SnowGlaze（トンネラー）: WebSocketトンネルを確立してC2（コマンド＆コントロール）インフラとの通信を隠蔽する。さらにSOCKSプロキシ機能により、感染ホストを経由した任意のTCPトラフィックのルーティングも可能にする。 SnowBasin（Pythonバックドア）: ローカルHTTPサーバーを起動し、CMDまたはPowerShellコマンドを実行する。リモートシェルアクセス、データ窃取、スクリーンショット取得、ファイル管理、さらに自己消滅コマンドをサポートする。 侵害後の動き——Active Directoryの完全掌握へ マルウェア展開後、攻撃者はSMBやRDPをスキャンして内部偵察を開始する。LSASS（Local Security Authority Subsystem Service）メモリのダンプで認証情報を抜き出し、パス・ザ・ハッシュ（Pass-the-Hash）で横移動を実行、最終的にドメインコントローラーへ到達する。 侵害の締めくくりとして、フォレンジックツール「FTK Imager」を使ってActive Directoryデータベース（NTDS.dit）とSYSTEM/SAM/SECURITYレジストリハイブを抽出。これによりドメイン全体の認証情報が攻撃者の手に渡る。 実務への影響——日本のIT管理者が今すぐ確認すべき5点 この攻撃が厄介なのは、Teamsという正規のコミュニケーション基盤を入り口として使う点だ。「知らない番号からの電話」なら警戒できるが、日常的に使うTeamsのチャットは心理的な防衛が薄れやすい。 Teamsの外部アクセスポリシー見直し: 外部組織・未管理デバイスからのTeamsチャット要求を制限する。テナント設定で外部ドメインのアクセスを許可リスト管理に切り替える Quick Assist・リモートアクセスツールの制御: Intuneまたはグループポリシーで、IT部門承認のない遠隔操作ツールの実行をブロックする LSASS保護の強化: Windows Credential GuardおよびLSASS Protected Process Light（PPL）を有効化する IoCs・YARAルールの展開: Mandiantが公開しているインジケーターをSIEMおよびEDRに投入して検知ルールを更新する 特権アカウントのJust-In-Time管理: 常時付与されたドメイン管理者権限は、侵害時の被害を指数的に拡大する。Microsoft Entra Privileged Identity Management（PIM）を活用した時限付き昇格に切り替えることを強く推奨する 筆者の見解 今回の攻撃が示しているのは、「信頼されているもの」が最も危険な攻撃ベクターになるという現実だ。Teamsは組織のコミュニケーション基盤として深く根付いており、だからこそ攻撃者にとって「最も疑われにくい入り口」になっている。 ゼロトラストの文脈では、これは教科書通りの事例だ。「社内ツールだから安全」「IT担当者からの連絡だから信頼できる」という前提が崩れたとき、ネットワーク境界だけを守る従来型のモデルはほぼ無力になる。認証・認可・デバイス状態を常時検証する構えがなければ、この手口を正面から止めることはできない。 LSASSダンプからのパス・ザ・ハッシュ、FTK Imagerによるドメインデータベース抽出——どれも既知の技術だ。それでもこの攻撃が成立するのは、多くの組織でいまだ「特権アカウントが常時使える状態」になっているからだ。Just-In-Timeアクセスと最小権限の徹底だけで、侵害後の横展開は大幅に制限できる。 MicrosoftはTeamsのセキュリティ強化を継続しており、今回のような手口を自ら積極的に警告していることは評価したい。防御オプションをもっとデフォルトで安全側に倒してくれれば、それだけで救われる組織が相当数ある。設定を知っている管理者だけが守られる状況は、そろそろ卒業してほしいところだ。 出典: この記事は Threat actor uses Microsoft Teams to deploy new “Snow” malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが人間の代わりに売買交渉を行い、実際のお金が動く——そんな実証実験をAnthropicが先日公開した。単なるデモではなく、24時間以内に186件の取引・総額4,000ドル超が成立した「本物の市場」だ。この実験が示すのは、エージェント・コマースの可能性だけではない。「モデル品質の差を当事者が気づけない」という、今後のエンタープライズAI活用において見過ごせないリスクも同時に浮かび上がった。 Project Deal とは——エージェントが代理交渉する分類広告市場 Anthropicが「Project Deal」と名付けたこの実験は、社員69名を対象に行われた。各自に100ドルの予算（ギフトカード形式）が配布され、AIエージェントが代理人として売買交渉を担当。参加者は自分の不用品などを出品し、AIが相手方のAIと値段交渉・取引成立まで自律的に行う形式だ。 4つの異なる条件でマーケットプレイスが並行稼働し、うち1つは「リアル市場」（取引が実際に履行される）、残り3つは比較研究用として設定された。最先端モデルで代理された参加者は「客観的により良い条件」で取引を終えたという結果が出た。 また、エージェントへの初期指示の詳細度は、取引成立率や交渉価格にほとんど影響しなかった。これは直感に反する発見だ。AIエージェントは指示の「文面」の細かさよりも、モデル自体の判断能力に依存しているという可能性を強く示唆している。 最大の発見——「エージェント品質格差」に当事者が気づかない この実験で最も重要な示唆は、技術的な成功率ではない。ユーザーが格差の存在に気づかなかったという事実だ。 高性能モデルで代理された参加者は良い取引を得た。一方、性能の低いモデルで代理された参加者は不利な条件で取引したにもかかわらず、その差を認識していなかった。Anthropicはこれを「エージェント品質格差（agent quality gap）」と呼んでいる。 将来、B2Bや消費者取引でAIエージェントが普及したとき、利用するモデルや設定の品質によって交渉力に大きな非対称性が生まれる可能性がある。しかも当事者はその不利を自覚できない。これは情報格差・所得格差と同じ構造を持ちながら、より「見えにくい」格差だ。 実務への影響——日本のエンジニア・IT管理者に届けたいこと 現時点でエージェント間取引が日本のビジネスに直接導入されることはないだろうが、この実験が示す構造は「すでに起きていること」の延長線上にある。調達・契約サポート・カスタマー対応など、すでに自律的なAIエージェントが業務の一部を担い始めている現場も増えている。 今から準備すべき3つのポイント： 「AIを使う」ではなく「どのモデルをどう使うか」まで設計する: 今回の実験が示したように、同じ「AI活用」でもモデル品質が成果に直結する。調達・交渉・判断に関わるタスクをエージェントに委ねるなら、モデル選定の基準を組織として持つべきだ エージェントのアウトカムを定期的に監査する仕組みを早期に作る: 人間が「気づかない格差」が生まれるリスクはエンタープライズ利用でも同様に存在する。エージェントの判断結果を定期レビューし、意図した目標に沿っているかを検証するプロセスをパイプラインに組み込むことが重要だ プロンプトの精緻化より、ループ全体の設計に投資する: 今回の実験では初期指示の内容が結果にほぼ影響しなかった。プロンプトエンジニアリングへの過度な傾注より、エージェントが自律的に判断・実行・検証を繰り返す「行動ループ」全体の設計に注力するほうが本質的な価値を生む 筆者の見解 AIエージェントが人間の「代理」として意思決定し、相手方エージェントと交渉し、合意を形成する——Project Dealはその縮小実験だが、構造の本質は現実のビジネスに確実に広がってくる。 個人的に最も気になるのは「エージェント品質格差」の問題だ。良いエージェントを使える組織と、そうでない組織の間に非対称な競争優位が生まれ、しかも当事者にはその差が見えにくい。これは単なる技術格差ではなく、ビジネスの公正性に関わる問いだ。 「禁止すれば解決する」という発想はここでも通用しない。むしろ組織全員が性能の高いエージェントにアクセスできる環境を整備することが、次のIT管理者・リーダー層の重要テーマになるはずだ。エージェント同士が交渉し、人間はその結果を享受する時代は着実に近づいている。準備を始めるなら、いまがそのタイミングだ。 出典: この記事は Anthropic created a test marketplace for agent-on-agent commerce の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIに対する社会的反発が、もはや無視できないレベルに達している。2026年4月、OpenAIのSam Altman CEOの自宅に火炎瓶が投げ込まれ、インディアナポリスでは地元議員の自宅に「No Data Centers（データセンターはいらない）」と書かれたメモとともに13発の銃弾が撃ち込まれる事件が立て続けに起きた。死傷者こそなかったが、いずれも深刻な政治的暴力だ。 これを「孤立した過激者の行為」と片付けることはできない。その背景には、見過ごせないデータが積み重なっている。 専門家と市民の認識ギャップ：73% vs 23% 2026年4月に発表されたStanford大学の年次「AI Index」報告書は、衝撃的な数字を示した。 設問 AI専門家 一般市民 AIは長期的に雇用に良い影響をもたらす 73% 23% AIは長期的に経済に良い影響をもたらす 69% 21% 50ポイントを超えるこの乖離は、技術者が真剣に受け止めるべき現実だ。同時期のGallup調査では、Z世代でAIに「興奮している」と答える割合が36%から22%に低下し、「怒りを感じる」と答える割合が22%から31%に増加した。世論は確実にAIへの反発を強めている。 「お前たちの仕事は消える」というメッセージの代償 なぜここまで乖離が生まれたのか。AI業界のリーダーたちは長年、「AIが人類を脅かすかもしれない」または「AIがあなたの仕事を完全に奪う」という二択のメッセージを発信し続けてきた。 こうしたメッセージは、カンファレンスや投資家向けの場では「注目を集める」手段として機能したかもしれない。だが実際の生活者の視点では何も解決していない。新卒の就職市場が厳しく、食料・住居コストが上昇し、経済的恩恵が上位0.1%に集中する環境の中で、AI業界は「データセンター構築のために数千億ドルの投資が必要だ」と声高に訴え続けた。バージニア州ではデータセンターの急増が家庭の電力料金を押し上げているという報告まである。 一般市民の目に映るAIは、「自分たちの生活を脅かす、富裕層が作った代物」になりつつある。テックジャーナリストのJasmine Sun氏が定義したように、「AIは通常のテクノロジーではなく、エリートの政治的プロジェクトだ」というナラティブが社会に浸透し始めている。 実務への影響：日本のIT現場が考えるべきこと 日本でもこのバックラッシュは他人事ではない。職場でのAI導入を進める際、以下の点を意識したい。 AI導入を推進する立場の方へ：「AIで業務効率化」という掛け声だけでは、従業員に「自分が不要になる」という不安を与えかねない。どのように仕事の内容が変わるか、どんなスキルが今後価値を持つかを具体的に示す「伴走設計」が不可欠だ。 経営者・IT管理者の方へ：AI利用を「禁止」で対応しようとすると、必ず抜け道が生まれ統制も失う。「安全に使える環境を整備し、現場が公式ルートを一番便利と感じる状況を作る」アプローチの方が長期的に有効だ。 現場エンジニアの方へ：同僚のAIへの抵抗感を「理解不足」と片付けないでほしい。それは多くの場合、業界全体のメッセージングが信頼を積み上げてこなかった結果だ。技術的な正しさより、心理的安全性を先に整える場面もある。 筆者の見解 率直に言えば、今回のバックラッシュはある程度、業界が自ら招いたものだと感じている。 「AIがあなたの仕事を奪う」「AIが世界を終わらせるかもしれない」——これらのメッセージは資金調達の文脈では「緊急性」を演出する手段として機能したのかもしれないが、社会には深刻なアレルギーを植え付けた。長い目で見れば、業界全体にとって大きなコストになっている。 AIを日々の実務で活用している立場から言えば、現在のAIが生み出している価値は本物だ。以前なら半日かかった作業が数分で終わり、考える時間が増え、仕事の質が上がる体験は、統計上の「専門家楽観論」ではなく、手で触れた実感だ。 問題は、その実感がまだ一般市民に届いていないことだ。業界は今、「どれだけすごいか」を語る段階から、「あなたのこの具体的な問題を、これで解決できる」という実証の段階へ移行する必要がある。派手な発表より、地味でも日常に根ざした成功事例の積み重ねこそが信頼を取り戻す道だ。 AIがいつか社会に当たり前のインフラとして受け入れられる日のために、今は「どう使うか」と同時に「どう伝えるか」を業界全体で根本から見直すフェーズに入っていると思う。 出典: この記事は The AI industry is discovering that the public hates it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11標準搭載の「Notepad（メモ帳）」から、「Copilot」という名称が姿を消した。2026年4月26日、この変更がMicrosoftストア経由で一般ユーザー向けへの展開が完了したことが確認された。新しい名称は「Writing Tools（ライティングツール）」。ただし、AI機能そのものは継続して提供されており、実態は「ブランド名の変更」だ。 「Copilot」の看板を下ろした背景 Microsoftは2026年3月20日、Windows 11への大規模な方針変更を発表した際、「Copilotのプレゼンスをより意図的に管理する」と宣言し、Snipping Tool・Photos・Widgets・Notepadを例に挙げて「不要なCopilotエントリーポイントを削減する」と明言した。 今回のNotepadの変更はその方針に沿ったものだ。UIからは「Copilot」という文言が完全に取り除かれ、機能説明も「Smarter writing tools（よりスマートなライティングツール）」という表現に刷新された。テキストを選択すると「書き直し（Rewrite）」「要約（Summarise）」「新規テキスト生成（Write）」へのアクセスが可能であることは変わらない。 MicrosoftはWriting ToolsがAIによって動作していることを、機能起動時に一応開示している。ただし、UIの主要な箇所からAIであることへの言及は大きく後退している。 Snipping ToolはAI機能ごと削除 対照的に、Snipping Tool（切り取りツール）はより踏み込んだ対応を取った。AI統合そのものが完全に削除され、Copilotボタンも一般チャンネルのユーザーには表示されなくなった。 NotepadがAI機能を維持しつつブランドだけを変えたのに対し、Snipping Toolはシンプルさを優先してAI機能ごと取り除くという、異なる判断をした。この2つのアプリの扱いの差が、今回の方針変更の本質を物語っている。 なぜ今、Copilotブランドを縮小するのか 「Copilot」の名称がWindowsの標準アプリに広く展開されて以来、ユーザーからは「本当に使いたい場面で役立たない」「押しつけがましい」という声が増えていた。Microsoftは今回の変更で、AI機能が「本当に価値を発揮できる場所」に絞り込む姿勢を示している。 なお同社は今後、タスクバーへのAIエージェント追加も計画中であり、WindowsからAIを撤退させる意図は一切ない。方針は「縮小」ではなく「選択と集中」だ。 実務への影響 企業のIT管理者にとって、今回の変更の実務インパクトは軽微だ。AI機能はSettings（設定）から引き続きオン・オフが可能であり、グループポリシーやMDMポリシーで制御している場合も挙動に変化はない。 注意点が一つある。社内向けのマニュアルや教育資料に「NotepadのCopilot機能」を記載していた場合、名称を「Writing Tools」に更新する必要がある。ヘルプデスクへの問い合わせが増える可能性も念頭に置いて、先手で周知しておきたい。 エンドユーザー視点では、「Copilot」というブランドに抵抗感を持っていた層が、「Writing Tools」という機能本位の名称の下でAI支援の文章編集を自然に使い始める可能性がある。機能の実態は変わっていないが、名称の変更が心理的ハードルを下げることはある。 筆者の見解 正直に言えば、今回の変更は「もったいない」という印象だ。 AI機能が本来持つ価値を損なっていた要因のひとつは、「Copilot」というブランドが実力以上に広げられすぎた結果、ユーザーの期待と現実がかけ離れてしまった点にあると思う。名称を「Writing Tools」に変えることで機能の実態を素直に伝えようとする姿勢は評価できる。Snipping Toolでの完全削除も、使われない機能を抱えるよりシンプルさを優先した判断として正しい。 ただ、名前を変えるだけでは根本的な課題は解決しない。MicrosoftにはAI統合を本当に輝かせるポテンシャルがあるし、そのための技術力もブランドも持っている。ユーザーが「AIのおかげで作業がはかどった」と実感できる場所を見極め、そこに力を注ぐことが今後の課題だ。今回の「整理」が、より良い体験への布石になることを期待したい。 Windowsの標準アプリにおけるAI体験の再整備は始まったばかりだ。今後の展開で、ブランド変更だけでなく実質的な使い勝手の向上が伴うかどうかが、真の評価軸になるだろう。 出典: この記事は Microsoft drops Copilot branding in Notepad for Windows 11 for everyone, but it’s really just a rename の内容をもとに、筆者の見解を加えて独自に執筆したものです。

カナダ・ブリティッシュコロンビア州タンブラーリッジで発生した銃乱射事件から約2ヶ月、OpenAIのCEO Sam Altmanが2026年4月25日、容疑者のChatGPTアカウントに関する情報を警察に通報しなかったとして正式に謝罪した。Engadgetが書簡全文とともに報じた。 事件の経緯と謝罪の背景 銃乱射事件の容疑者とされるJesse Van Rootselaar氏は、事件前にChatGPTを利用していた。OpenAIは同アカウントが「現実世界での暴力を引き起こす可能性がある」として利用規約違反でアカウントを停止していたが、その情報を警察には通報していなかった。 Altman氏はタンブラーリッジの地域メディア「Tumbler RidgeLines」が全文公開した書簡の中で「6月に停止したアカウントについて、法執行機関に通知しなかったことを深くお詫び申し上げます」と述べた。「言葉では取り返しのつかない損害を埋めることはできませんが、コミュニティが受けた害と不可逆的な損失を認識するためにも謝罪が必要だと考えています」とも記している。 Engadgetによれば、Altman氏はタンブラーリッジのDarryl Krakowa市長とブリティッシュコロンビア州のDavid Eby首相と話し合い、「公式謝罪は必要だが、コミュニティが悲しみに向き合う時間も必要だ」との認識を共有していたという。 政府・州の反応と今後の方針 Eby首相はXへの投稿でAltman氏の書簡に触れ、「謝罪は必要だ」としながらも「タンブラーリッジの遺族に与えた壊滅的な被害には到底不十分だ」と述べた。 今後の対応としてAltman氏は、「今後こうした悲劇を防ぐ方法を見つけ、すべてのレベルの政府と協力していく」と表明した。これはEngadgetが先に報じたOpenAI副社長（グローバルポリシー担当）Ann O’Leary氏の声明——ChatGPT上で「切迫した・信頼性の高い脅威」を発見した場合は当局に通知する——をさらに強化する姿勢だ。 なぜこの問題がAI業界全体の課題か 今回の件が浮き彫りにするのは、AIサービス企業が持つ「情報の非対称性」だ。OpenAIは利用規約違反の早期警戒シグナルをつかんでいながら、それを公共の安全に活かす仕組みを持っていなかった。 技術的に可能なこと（危険なアカウントの検知・停止）と、社会的責任として求められること（関係当局への連携）のギャップは、OpenAI固有の問題ではなく、ユーザーの日常会話を扱うすべてのAIサービスが向き合うべき構造的課題でもある。 日本市場での注目点 日本においても、AIサービス運営会社が公共安全においてどこまで責任を負うかは未整備な領域だ。欧州ではAI法（EU AI Act）が施行され、高リスクAIシステムへの義務が法制化されつつあるが、日本はガイドライン策定が中心で法的義務化には至っていない。 今後、類似事案が日本で起きた場合に海外AIサービス企業がどう対応するか、また国内企業がどこまでの対応義務を負うかについて、規制論議が加速する可能性がある。企業のAI活用担当者は、利用しているAIサービスのコンプライアンスとインシデント対応ポリシーを改めて確認するタイミングと言えるだろう。 筆者の見解 今回の謝罪は、OpenAIが一企業の判断でアカウント停止をしながら、社会的なセーフガードとして機能しきれなかった事実を示す出来事だ。 AIが日常会話を収集し続ける時代において、安全シグナルの検知と当局連携をどう設計するかは、技術的課題であると同時に倫理的な問いでもある。「切迫した・信頼性の高い脅威なら通報する」という方針は出発点に過ぎない。どのラインを「切迫」とみなし、誰がその判断を下し、どう検証するかまで含めたフレームワークが不可欠だ。 OpenAIに限らず、AIサービスを持つすべての企業にとって、謝罪から実効的な仕組みへの昇華が問われている。今後の動向を注視したい。 出典: この記事は OpenAI’s Sam Altman apologizes for not reporting ChatGPT account of Tumbler Ridge suspect to police の内容をもとに、筆者の見解を加えて独自に執筆したものです。

BYDのサブブランド「Denza（騰勢）」が、2026年4月に開催された北京モーターショーで電動ハイパーカー「Denza Z」を正式公開した。米テック・ガジェットメディアのEngadgetが報じており、電動モーターで1,000馬力以上を発生し、0〜96km/h（0〜60mph）加速を2秒未満で達成するスペックが明らかになっている。 なぜこの製品が注目か BYDといえば手頃な価格帯のEVメーカーというイメージが強いが、近年はハイエンド・ハイパーカー市場への参入を本格化している。Denza Zはそのシンボル的存在だ。 1,000馬力超・2秒未満の0〜96km/h加速は、CarNewsChina の報道によるとクロアチアの電動ハイパーカーメーカーRimac Neveraに匹敵するスペックだという。単なるコンセプトカーではなく、量産を前提とした4人乗りの実用ハイパーカーとして設計されている点が特筆される。 さらに注目すべきは「欧州先行発売」という戦略だ。BYDが欧州市場をハイエンドEVの主戦場と位置づけていることがうかがえる。 海外レビューのポイント 現時点では発売前のため実機レビューは存在しないが、Engadget、CarNewsChina、AutoExpressなど複数の海外メディアが公開情報をもとにポイントを報じている。 技術面のハイライト DiSus-M インテリジェントサスペンション: Engadgetによると、シボレー・コルベットの「マグネティック・ライド・コントロール」に類似した電子制御サスペンションシステム。路面状況に応じてリアルタイムで減衰力を最適化する仕組みだ フラッシュチャージング: BYD独自の超急速充電技術。同社の他モデルでも採用されており、ハイパーカーにもこの利便性が引き継がれる 自律走行・タンクターン: AutoExpressの報道では、BYD YangWang U9と同様に自律走行機能と、その場で車体を旋回させる「タンクターン」機能も搭載予定とされている ボディバリエーション Engadgetによると、ハードトップ、コンバーチブル、トラック（サーキット特化）の3種類が予定されている。ただし、トラック仕様の詳細スペックはまだ明らかにされていない点は留意が必要だ。 気になる点 フルスペックの非公開が続いており、価格・航続距離・最高速度などの主要諸元が不明なままだ。欧州発売を控えた時点でここまで情報が限られているのは、発表タイミングを計算したメディア戦略とも読める。 日本市場での注目点 Denzaブランドは現時点で日本に上陸していない。BYD JAPANは「Atto 3」「Dolphin」「Seal」といった普及価格帯のEVを展開しているが、Denzaのようなプレミアムラインの日本投入時期は未定だ。 参考として、BYDの別ハイパーカーブランドYangWang U9は生産台数30台限定の超希少モデルだった。Engadgetは「Denza ZはYangWang U9より入手しやすくなる」と報じているが、具体的な価格帯はまだ発表されていない。 欧州のGoodwood Festival of Speed（2026年7月予定）がグローバルデビューの場になる見通しで、そこで価格・スペックの詳細が明らかになる可能性が高い。日本市場への関心がある方は7月の発表に注目しておきたい。 筆者の見解 BYD Denza Zが示しているのは、「EVは安くて実用的なもの」という従来のイメージを塗り替えようとする中国EV産業の変容だ。1,000馬力超・2秒未満の加速は、テクノロジーのショーケースとして明確なメッセージを持つ。 興味深いのは「欧州ファースト」という販売戦略だ。EV補助金の見直しや関税問題で欧州市場が複雑さを増しているなかで、あえてプレミアムセグメントから欧州に切り込む姿勢は計算された動きに見える。ハイパーカーはブランドイメージを高めるための投資でもあり、「BYD＝高性能」という認知を欧州市場で先に確立しようとしているのだろう。 技術面では、DiSus-Mサスペンションやフラッシュチャージングなど、BYDの自社技術スタックをフル活用している点は注目に値する。垂直統合型のものづくりが高性能領域でも機能することを証明しようとしている意図が読める。 タンクターンや自律走行機能の実装がどの程度成熟しているかは、Goodwoodでの公式デビュー後に実機インプレッションが出そろった段階で改めて評価したい。 出典: この記事は BYD’s next all-electric hypercar is a convertible that’s coming to Europe first の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIがGPT-5.5のリリースに合わせ、モデルの安全性評価をまとめた「システムカード」を公開した。単なるモデル性能の紹介ではなく、サイバーセキュリティや生物兵器悪用といった高リスク領域について、約200名の早期アクセスパートナーと連携した事前レッドチームテストの結果が詳述されている。 システムカードとは何か システムカードとは、OpenAIが主要モデルリリース時に発行する安全性評価文書だ。モデルの能力範囲と潜在的リスク、その緩和策をまとめたもので、企業の透明性への姿勢を示す重要な指標として業界内で参照されてきた。GPT-4以降、リリースのたびに発行が続いており、今回のGPT-5.5版ではその内容がさらに充実している。 自律エージェント設計への転換が評価軸を変えた 今回のシステムカードで特に注目すべきは、評価項目が「自律的にタスクを完了する」設計への移行を前提として組み直されている点だ。 従来のモデル評価は主に「何を生成できるか」に焦点を当てていた。しかしGPT-5.5では、自己管理（モデルが自分自身のリソース使用をどう制御するか）とツール利用の監査（外部ツールをどう呼び出し、その結果をどう処理するか）が新たな評価軸として加わった。 これはAIの設計思想そのものの転換を意味する。指示を受けて応答する「対話型AI」から、目標を与えられれば一連の行動を自律的に実行する「エージェント型AI」へのシフトが、安全評価の枠組みにも反映されてきた。 レッドチームテストの規模と方法論 約200名のパートナーによる事前テストは、OpenAIとして過去最大規模の部類に入る。特に以下の観点での評価が実施された： サイバー攻撃への悪用可能性: 脆弱性発見・エクスプロイト生成への利用シナリオ CBRN（化学・生物・放射線・核）リスク: 生物兵器設計への悪用シナリオ 自律行動のエスカレーション: 指示なしに外部リソースを獲得しようとする行動パターン 「能力強化と安全確保のトレードオフ」について従来より詳細な説明が提供されており、この透明性への姿勢は業界全体のスタンダード形成に影響を与えうる。 日本のIT現場への影響 エンタープライズ導入の判断材料として GPT-5.5のような大規模言語モデルを業務に導入する際、セキュリティ部門から問われるのは「何ができるか」だけでなく「何が起きないか」だ。システムカードはその答えを提供する公式文書として機能する。特にAzure OpenAI Serviceを通じてMicrosoftのクラウドで同モデルを利用する日本企業にとって、このシステムカードは契約・ガバナンス文書の一部として参照されるケースが増えるだろう。 AIエージェント実装への具体的ヒント 自律エージェントの設計において「ツール利用の監査」が公式評価項目に加わったことは、開発者にとって重要なシグナルだ。エージェントがどのAPIを叩き、何のデータにアクセスし、どういう判断で次のステップに進むかを記録・検証できる実装が、今後の業務適用の前提条件になっていく。 設計時のチェックポイントとして： エージェントの行動ログを全件取得できる構成になっているか 外部ツール呼び出しに最低限の承認フローが組み込まれているか（過剰な確認要求は自律性を損なう点に注意） 異常な行動パターンを検知する監視機構があるか 筆者の見解 システムカードの定期公開という文化は、AI開発における重要なインフラになりつつある。今回OpenAIが自律エージェント設計への移行を前提とした評価軸を追加したことは、この分野の成熟を示す一歩として素直に評価したい。 ただ、ここで立ち止まって考えたいことがある。「自律的にタスクを完了する」設計を謳いながらも、実際の運用で「すべての操作に人間の承認を求める」体験になっていないか。安全性のための制約が、結果的にユーザーに常時確認を求め続けるインターフェースを生み出していないか。真の自律エージェントとは、目的を伝えれば判断・実行・検証をループで回し続けられるものだ。安全確保はその前提として不可欠だが、安全確保のために自律性を犠牲にしては本末転倒になる。 OpenAIがシステムカードで示した透明性のアプローチは、他のプラットフォームや開発者が模倣すべきものだ。どのAIツールを選ぶかに関わらず、「何が起きているかを説明できる構造」こそが企業向けAI導入の最低ラインになっていく。今回の公開がその文化を業界全体に広げる一助になるとすれば、意義は小さくない。 出典: この記事は GPT-5.5 System Card | OpenAI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azure Cosmos DB for NoSQLに、Dynamic Data Masking（DDM）が正式リリース（General Availability）された。機密データの保護をアプリケーションコードへの変更なしにDB層から一元的に実現できる点が最大の特徴だ。コンプライアンス対応の工数を大幅に削減できる機能として、エンタープライズ利用を見据えたチームには見逃せない進化だ。 Dynamic Data Masking（DDM）とは DDMはサーバー側で動作するポリシーベースのセキュリティ機能だ。クエリ実行時にリアルタイムでマスキングを適用するが、データベースに保存された実データ自体は変更されない。 権限を持つユーザーには元の値がそのまま返り、権限のないユーザーにはマスクされた値が返る。この制御はCosmos DB側で一元管理されるため、アプリケーションに条件分岐ロジックを実装する必要がない。すべてのクライアントとSDKに対して一貫してポリシーが適用される点も重要だ。 対応するマスキング戦略 DDMは複数のマスキング戦略をサポートしており、データ型やシナリオに合わせて選択できる。 種類 説明 例 デフォルト 文字列→XXXX、数値→0、真偽値→false Redmond → XXXX カスタム文字列 開始位置と長さを指定した部分マスク Washington → WasXXXXXon メール ユーザー名先頭1文字とドメイン末尾（.com等）のみ表示 j***@example.com 設定の流れ 設定はコードを書かずにAzure Portalから完結できる。 Azure Portal → Settings > Features でDDMを有効化 データプレーンRBACでロールと権限を定義 ユーザー（または サービスアカウント）をロールに割り当て（特権ユーザーにはアンマスク権限を付与） コンテナレベルでマスキングポリシーを適用（対象フィールドとマスク戦略を指定） 実務への影響 日本企業においても、個人情報保護法や各種業界規制の観点からPII（個人識別情報）・PHI（医療情報）の取り扱いは年々厳格化している。特に「開発チームやサポートチームに本番DBのどこまでアクセスを許すか」という問題は、現場で頻繁に議論されるテーマだ。 これまでの対策は実質二択だった。「本番DBへのアクセス自体を禁止する」か、「アプリケーション層にマスキングロジックを実装する」か。前者はオペレーションの障壁になりやすく、後者はサービスやバッチが増えるたびに実装漏れが起きやすい。DDMはその中間の現実的な第三の選択肢になりうる。 もう一点、特に注目したいのがNon-Human Identities（NHI）——サービスアカウントや自動化エージェント——への対応だ。AIエージェントやCI/CDパイプラインがDBに直接アクセスするアーキテクチャが急増している中、人間のユーザー管理と同じ粒度でNHIのアクセス権を制御できるかどうかが、安全な自動化の鍵になる。DDMのRBACベースの設計はこのユースケースにも有効に機能する。 筆者の見解 セキュリティ実装でよくある失敗パターンは「アプリケーション層に散らばったアドホックな実装」だと思っている。チームAのサービスはPIIをマスクしているが、チームBのバッチは素通しだった——という事故は珍しくない。アクセス経路が多様化するほど、アプリ層での管理は破綻しやすくなる。 DDMがDB層で一元管理するアプローチは、最小権限の原則を技術的に強制するという意味で、筋が良い設計だ。「今動いているから大丈夫」という楽観論は、組織が拡大してチームが増えた瞬間に崩れる。アクセス制御をコードではなくプラットフォーム側に押し出す設計こそが、スケールしてもセキュリティが崩れないアーキテクチャの基盤になる。 NoSQLデータベースでここまできめ細かいRBACベースのデータ保護が実現したことは、エンタープライズ向けCosmos DB採用の敷居をさらに下げる前進だ。コンプライアンス要件が厳しい金融・医療・公共分野でのCosmos DB活用を検討しているチームは、今回のGAを機に改めて評価してみる価値がある。 出典: この記事は General Availability: Dynamic Data Masking for Azure Cosmos DB の内容をもとに、筆者の見解を加えて独自に執筆したものです。

4月末、Microsoft 365 CopilotのAPIエンドポイントがoffice.comからcloud.microsoftドメインへ静かに切り替わる。ユーザーには何も見えない変更だが、ファイアウォールやプロキシを管理している担当者には看過できない話だ。設定の対応漏れが接続障害に直結するため、今週中に確認を済ませておきたい。 何が変わるか——インフラ層での静かな移行 MicrosoftはM365全体で「cloud.microsoft」への統一ドメイン移行を段階的に進めており、今回のCopilot APIエンドポイント変更はその一環だ。変更点を整理すると次のとおりになる。 CopilotのAPI通信先が office.com → cloud.microsoft に変更 ユーザー画面・ワークフローへの変更は一切なし デフォルト有効化で、無効化オプションなし WebSocket（WSS）接続を使用する点が重要 サービス基盤レベルの変更なのでエンドユーザーは何も気づかないが、ネットワーク制御を持つ組織では対応が必要になる。 管理者が今週中にやること 対応が求められるのは「独自のファイアウォール・プロキシ・エンドポイントフィルタリング設定を持つ組織」だ。Microsoft 365のネットワーク要件に既に準拠していれば追加対応は不要とされているが、念のため以下のチェックリストで確認しておくことを強く推奨する。 対応チェックリスト *.cloud.microsoft をエンドポイント許可リストに追加する *.cloud.microsoft 宛のWSS（WebSocket）接続が遮断・干渉されていないか確認する 以下の処理を cloud.microsoft トラフィックから除外する TLS復号（SSL Inspection） パケットインスペクション ネットワーク層のDLP ネットワーク担当チームとヘルプデスクへ事前に周知する Microsoftが提供するCopilotネットワーク接続テストツールで検証する 日本の現場への影響——見落としやすい落とし穴 日本の大企業・官公庁系では、UTMやプロキシによるSSL Inspectionを全トラフィックに対して適用している環境がいまだに多い。「cloud.microsoft宛ての通信もTLS復号対象に含まれていた」というケースは決して珍しくないはずだ。 Copilotが突然応答しなくなった、極端に遅くなったという障害報告が4月末前後に増えた場合、真っ先にこのネットワーク設定を疑うべきだ。ヘルプデスクには「Copilotの動作不良はネットワーク設定が原因である可能性がある」と事前に情報共有しておくだけで、トリアージのスピードが格段に変わる。 実務での活用ポイント 今すぐ確認: *.cloud.microsoft のエンドポイントをMicrosoftの最新公開リストと照合する ゼロトラスト環境: Conditional Accessのポリシーがcloud.microsoftドメインを考慮しているか再確認する SASEやCASB製品利用組織: ベンダーに「cloud.microsoft対応状況」を問い合わせておく 移行後のモニタリング: Copilotの利用ログやネットワーク監視で、4月末前後の異常を検知できる体制を整える 構成ドキュメントの更新: 許可リストを変更したら、必ずネットワーク構成ドキュメントに反映しておく 筆者の見解 ドメイン統一自体は正しい方向性だ。office.com、microsoft.com、microsoftonline.com と分散していたエンドポイントが cloud.microsoft に集約されていくことで、ネットワーク管理の見通しは確実に良くなる。長期的には管理者の負担軽減につながる流れであり、この取り組みは歓迎したい。 ただし「デフォルト有効、無効化不可」という実装スタイルは、現場の管理者に一方的な変更コストを押しつける形になっている点はもったいない。Microsoftほどのプラットフォームであれば、こういった基盤移行を「段階的推奨」から「完全切替」に持っていくまでの猶予とサポートをより手厚くできるはずで、その部分をぜひ改善してほしいところだ。 今回のような変更は今後も続く。M365のメッセージセンター（Message Center）を定期的にウォッチする運用体制の有無が、安定稼働とトラブル多発の分かれ目になってくる。cloud.microsoftへの統合が完成したとき、Copilotを含むM365サービス全体のパフォーマンスと信頼性が向上し、このプラットフォームが本来持つポテンシャルをきちんと発揮できる基盤になることを期待している。 出典: この記事は Microsoft 365 Copilot transition to the cloud.microsoft domain の内容をもとに、筆者の見解を加えて独自に執筆したものです。