Tech News JP

欧州から届いた「AI独立宣言」 フランス発のAI企業Mistral AIが2026年4月、「European AI: A playbook to own it（欧州AI——主権を取り戻すプレイブック）」と題した52分読みのホワイトペーパーを公開した。CEOのArthur Mensch氏が序文に立ち、「欧州はもはや競争できるかどうかを問う段階にない。いかに自立したAI大国へと転換するかを問う段階だ」と宣言している。 単なる企業の宣伝文書ではない。これは欧州のAI政策立案者・企業経営者・研究者に向けた、具体的な行動指針の提案だ。 欧州が持つ3つの固有資産 プレイブックが主張する欧州の強みは3点に集約される。 1. 世界水準の学術エコシステム ディープラーニング研究の発祥地の一つがヨーロッパであることは意外と知られていない。パリ、ロンドン、チューリッヒ、ベルリンには今も世界トップクラスの研究者が集中しており、Mistral AI自体がその成果の体現だ。 2. 「人間中心の技術」へのコミットメント GDPRをはじめとする欧州の規制文化は、しばしば「イノベーションの足かせ」として批判される。しかしプレイブックは逆の視点を提示する。プライバシー・透明性・説明責任を設計の中核に据えたAIこそが、長期的な信頼と社会実装において優位性を持つという論理だ。 3. 4億5000万人の単一市場 規模の経済という観点では、欧州連合は米国に匹敵するポテンシャルを持つ。問題は、27加盟国がバラバラに動いているため「単一市場」の恩恵を十分に享受できていないことだ。プレイブックはこの分断を統合することを最重要課題として位置づける。 何が「自立」を妨げているのか Mensch CEOは率直に言う。「このまま何もしなければ、欧州は外国企業のデジタルインフラに依存し続け、監視リスク・経済的衰退・戦略的脆弱性にさらされ続ける」。 米国のビッグテックと中国のAI産業という二極への依存は、単なるビジネスの問題ではない。学習データの管理権、モデルの設計思想、インフラのホスト国——これらがすべて外国に握られる状況は、デジタル主権の喪失を意味する。 プレイブックが提案する具体策は多岐にわたる： 欧州内のAI需要の喚起（官公庁・企業による優先調達） 優秀な人材の欧州回帰と育成 27カ国を横断したスケールアップ支援 規制の簡素化（価値観は守りつつ、スピードを確保） 官民投資の動員によるインフラ自立 実務への影響——日本のIT現場はどう読むか 「欧州の話でしょ」と距離を置くのは早計だ。日本のIT現場にとっても、この動きは無視できない意味を持つ。 AI調達の地政学リスクが現実化している クラウドAIサービスを選定する際、「どの国の企業のモデルを使うか」はもはや技術的な問いと切り離せない。欧州がMistralを選ぶ動機と、日本企業が「どこのAPIを使うか」を判断する動機には、構造的な共通点がある。企業のAI戦略にサプライチェーンリスクの視点を組み込む時代が来ている。 「人間中心AI」は規制対応でもある EUのAI法（AI Act）は2025年から段階的に適用が始まっている。欧州市場に何らかのビジネスを持つ日本企業は、EU規制に準拠したAIシステムの設計が求められる。Mistralが主張する「人間中心の技術設計」は、この文脈での競争優位に直結する。 オープンソース戦略の意義 Mistralはオープンウェイトモデルを積極的に公開してきた。欧州のAI自立戦略において、オープンソースは「依存関係を切る武器」として機能する。日本でもローカル展開やオンプレミス運用のニーズが高い企業にとって、この潮流は選択肢を広げるものだ。 筆者の見解 率直に言えば、このプレイブックは「欧州のMistralが自社利益のために書いた政策提言書」という側面を持つ。それを差し引いても、主張の核心には説得力がある。 AIはいまや、電力や通信インフラと同レベルの「社会基盤」になりつつある。社会基盤を特定の外国企業数社に委ねることのリスクを、欧州は真剣に考え始めた——それ自体は正しい問題意識だ。 日本に引き寄せて考えると、日本はこの問いにまだ正面から向き合えていない。「どのAIが使いやすいか」「コストはいくらか」という個別最適の議論は活発だが、「AIインフラの自立性をどう確保するか」という戦略的な議論は官民ともに希薄だ。 AIが「仕組みを作れる人間が少数いれば、あとはAIが回す」世界に近づいているとすれば、その「仕組み」の根幹をどこに置くかは国家レベルの選択になる。Mistralのプレイブックが問いかけているのは、欧州だけでなく世界中のプレイヤーへの問いでもある。 欧州がこの戦略で本当に自立したAIエコシステムを築けるかどうか、2026年以降の数年が試金石になるだろう。日本がその動向を観察するだけでなく、自国の文脈で同様の問いに答えを出せるかどうかも問われている。 出典: この記事は European AI. A playbook to own it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オープンソースのインタラクティブPythonノートブック環境「Marimo」に、認証なしでリモートコード実行（RCE）が可能な重大な脆弱性（CVE-2026-39987）が発見された。GitHubのスコアリングでは10点満点中9.3という「Critical」評価であり、Sysdigの調査によると開発者アドバイザリの公開からわずか10時間以内に実際の攻撃が始まっている。GitHubスター数2万を誇る比較的メジャーなプロジェクトだけに、影響を受けている環境は決して少なくないはずだ。 脆弱性の仕組み——認証ゼロで「シェル」が渡される 今回の問題の本質はシンプルかつ深刻だ。MarimoはWebSocket経由でインタラクティブなターミナルを提供する /terminal/ws エンドポイントを持っているが、このエンドポイントに一切の認証チェックが存在しない。 接続できさえすれば、Marimoプロセスが持つ権限そのままのフルシェルが手に入る。データサイエンティストやMLエンジニアが日常的に使うツールが、外部からそのまま「踏み台」になる構造だ。 影響を受けるのは以下の条件を満たす環境： バージョン 0.20.4 以前を使用している --host 0.0.0.0 で起動し、編集モードでネットワークに公開している チームで共有するJupyterライクな環境として使っているケースや、社内Wikiサーバー的に外部公開している開発用サーバーが特にリスクが高い。 実際の攻撃の手口——3分以内で完了する認証情報窃取 Sysdigのレポートが記録した攻撃の流れは、驚くほど手際が良い。 /terminal/ws へ接続し、RCEが成立することをすばやく確認して切断 再接続後、pwd・whoami・ls で環境を把握 .env ファイルを直接読み取り、クラウド認証情報やアプリケーションシークレットを抽出 SSHキーの探索も実施 この一連の操作が3分以内に完了している。 攻撃者はマルウェアや永続化ツールを一切インストールしておらず、「静かに盗んで去る」ステルス型の手口だ。暗号通貨マイナーを仕込んで騒ぎを起こすよりも、気づかれにくく高価値な情報を狙う判断をしている。 対応策——修正版への即時アップデートが最優先 開発チームはすでに バージョン 0.23.0 で修正済みのリリースを公開している。 出典: この記事は Critical Marimo pre-auth RCE flaw now under active exploitation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、Android向け軽量メールアプリ「Outlook Lite」の終了日を正式に確定した。これまで「いずれ終了」という曖昧な状態が続いていたが、今回の発表で期限が明確になり、利用者・IT管理者ともに移行対応を迫られる段階に入った。 Outlook Liteとは何だったのか Outlook Liteは、低スペックなAndroid端末や通信帯域が限られた環境向けに設計された軽量版メールアプリだ。APKサイズを抑え、バッテリー消費も最小化した設計で、新興国市場や業務用のエントリー端末を多く抱える企業環境を主なターゲットとしていた。 日本国内では、フル版Outlookが動作するスペックの端末が主流であるため、Outlook Liteの利用者は限定的だ。しかし、コスト重視で低スペックなAndroid端末を現場作業員・店舗スタッフ・配送ドライバー等に配布している企業では、Liteを採用しているケースがある。 なぜ今廃止するのか Microsoftは現在、モバイルのOutlookアプリを「新しいOutlook」に一本化する戦略を進めている。PCのWindows向けに展開されてきたOutlookの刷新と並行して、モバイル体験も統一しようとする動きだ。 複数のアプリを並行維持するコストを削減しつつ、機能・UI・セキュリティポリシーの一貫性を保つという判断は、プラットフォーム管理の観点からは理にかなっている。「部分最適を積み重ねると全体として非効率になる」という原則に照らせば、アプリ統合そのものは正しい方向性だ。 実務への影響と移行の選択肢 移行先の検討 フル版Outlook for Androidが第一候補だが、Lite利用者が使っていた端末がフル版の動作要件を満たすかどうかを事前に確認する必要がある。スペック要件が端末の「使用継続 or 入れ替え」判断にも影響してくる。 Microsoft 365をEntraIDで管理しているなら、条件付きアクセス（Conditional Access）の対象アプリ設定も見直しておきたい。Liteが承認アプリ一覧に含まれていた場合、フル版に切り替えてもポリシーが正しく適用されるかを検証する工程が必要だ。 Intuneユーザーへの注意 Microsoft Intune（MDM）でOutlook Liteを展開していた場合、アプリ割り当てポリシーの更新が必要になる。放置するとアプリが削除されてメール受信ができなくなるリスクがあるため、早めのポリシー更新を推奨する。 移行タイムライン 「まだ時間がある」と後回しにしやすいが、端末のスペック確認→フル版展開テスト→条件付きアクセス検証→エンドユーザー通知という一連のフローには相応の工数がかかる。終了日が確定した今のうちに段取りを組んでおくのが賢明だ。 筆者の見解 アプリの一本化戦略自体は支持できる。複数の「似て非なるアプリ」を並走させることは、セキュリティパッチの適用遅延やサポートコストの増大を招く。その意味でLiteの終了は正しい判断だと思う。 ただ、気になるのは「軽量版が不要な環境をどう整えるか」という問いへの答えが、今のMicrosoftから十分に示されていない点だ。Outlook Liteが求められていた背景——低帯域・低スペック端末の現場利用——は日本でも消えていない。フル版が「重い、遅い」と現場から不満が出たとき、IT部門が取れる選択肢が狭まっていくことには注意しておきたい。 Microsoftにはモバイル体験の全体設計を磨いてきた実績がある。その力を活かして、エントリー端末でも快適に動くフル版の最適化にも力を入れてほしい。Liteを終わらせるなら、その先に「Liteより良い体験」を用意することがセットでなければ、現場のIT管理者は報われない。 出典: この記事は Microsoft locks in final death date for Outlook Lite on Android の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11/10およびOfficeにおける「インターネット接続なしで行える公式ライセンス認証手段」を廃止した。同社はその理由を公式に説明しており、長年にわたり運用されてきたこの仕組みがついに幕を閉じた形だ。オンプレミス中心の環境が多い日本企業にとって、見過ごせない変更である。 何が廃止されたのか Microsoftが廃止したのは、従来「電話認証（Telephone Activation / SLUI 4）」と呼ばれてきた仕組みだ。これはインターネットに接続せずとも、表示されたコードを電話でオペレーターまたは自動応答システムに伝えることで認証を完了できる方法で、Windows Vista時代から存在していた。 オフライン環境や、ネットワーク制限の厳しい環境でWindowsやOfficeを正規に認証するうえで、IT管理者の間では長く重宝されてきた手段だった。 Microsoftの説明によれば、廃止の主な理由は以下の2点に集約される： セキュリティおよび不正利用の防止: 電話認証の仕組みは、ライセンスキーの悪用・転売・不正認証のベクターとして長年利用されてきた。自動応答システムを使った大量認証など、海賊版流通に加担するルートとなっていた実態がある サポートコストの削減: 電話認証に必要なインフラ・オペレーター運用のコストが、実際の正規利用件数に見合わなくなっていた 企業IT管理者が知っておくべきこと この変更によって直接影響を受けるのは、主に以下のシナリオだ： 影響を受けやすい環境： インターネットから切り離されたエアギャップ環境（製造ライン制御・医療機器・セキュリティ機密環境など） ネットワーク制限が厳しく、KMSやMAKによるオンライン認証が困難な拠点 ライセンス管理を手動で行っているオンプレミス中心の組織 代替手段として有効なもの： KMS（Key Management Service）: 社内KMSサーバーを経由した認証。エアギャップ環境でも閉じたネットワーク内で完結できる VAMT（Volume Activation Management Tool）: Microsoftが提供するオフライン対応のボリュームライセンス管理ツール。インターネット接続を持つ別マシンを経由してプロキシ認証が可能 Windows Autopilot + MAK: クラウド管理前提の環境ではMAK（Multiple Activation Key）との組み合わせが現実的 重要なのは、「インターネット不要」のオプションが完全になくなったわけではない点だ。KMSやVAMTは引き続き機能する。電話認証という「最後の砦」がなくなったということであり、設計段階からライセンス認証フローを組み込んでおく重要性がより高まった。 実務での活用ポイント 現在の環境棚卸しを今すぐ: 電話認証に依存しているシステムやプロセスがないか確認する。特に定期的な再認証が発生する環境は要注意 KMSサーバーの有無を確認: ボリュームライセンス契約があればKMSが使える可能性が高い。IT部門内で横断的に棚卸しする機会とすべき VAMTの導入検討: エアギャップ環境が複数ある組織では、VAMTによる一元管理が長期的にも運用コストを下げる ライセンス更新タイミングを活用: 次回のボリュームライセンス更新や契約見直し時に、クラウドベースのライセンス管理（Microsoft 365など）への移行を評価する 筆者の見解 電話認証という仕組みは、率直に言って時代の終わりを迎えるべき技術だった。インフラコストと不正利用リスクの両面から、廃止の判断そのものは理にかなっている。 ただ、引っかかるのは「廃止のタイミングと周知の不足」だ。エアギャップ環境を持つ製造業・医療・金融・官公庁といった業種では、インターネット接続前提の設計変更は一朝一夕では進まない。「廃止した、代替手段はKMSとVAMTです」という説明だけでは、現場の実態にそぐわないケースが出てくる。 Microsoftにはこうした移行が難しい組織に対して、KMS/VAMTの導入支援や移行ガイドをもっと前面に出してほしかった。廃止の意図は正しい。ならば、代替手段への誘導にも同じくらいのエネルギーをかけるべきだ。 日本のエンタープライズIT環境においては、「動いているから問題なし」で来た認証まわりの設計が今回の廃止で初めて問い直される組織も出てくるだろう。これを機に、ライセンス管理の仕組みを一度きちんと整理することを強くお勧めする。「対応するのは問題が起きてから」では遅い変更がここに来た、と受け止めてほしい。 出典: この記事は Microsoft explains why it killed official way to activate Windows 11/10 without internet の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11の展開・管理において、公式ツールでは痒いところに手が届かないと感じているエンジニアは多い。そんな現場のニーズに応え続けてきた人気の非公式インストール構成ユーティリティが最近相次いでアップデートを受け、処理速度とディスク効率の両面で大きく進化した。 何が変わったのか 今回のアップデートの柱は2点だ。 パフォーマンスの大幅向上 インストールや構成処理の内部ロジックが見直され、同じ作業にかかる時間が明確に短縮された。大規模展開時にはこの差が積み重なり、全体の作業工数に直結する。 ディスク容量の節約 新たに追加された機能により、インストールイメージやキャッシュファイルの扱いが最適化され、ストレージの無駄遣いを抑えられるようになった。SSDが当たり前になった現代でも、特に容量制限のある環境やVDI基盤での展開では、この改善は地味に効く。 非公式ツールを使う意味と注意点 「非公式」という言葉には、常に慎重な判断が伴う。Microsoftが提供するWindows展開ツール群（MDT、Windows ADK、Autopilotなど）は公式サポートがあり、エンタープライズ環境ではこれが原則だ。 ただし、現実の現場では「公式ツールだけでは構成が煩雑すぎる」「小規模環境やテスト環境で素早く検証したい」「個人開発機や社内ラボを効率的にセットアップしたい」といったユースケースが存在する。こうしたギャップを埋めるために、コミュニティ製ツールが長年活用されてきた経緯がある。 重要なのはツールのソースコードやリリース履歴を確認し、信頼できる開発者・コミュニティが維持しているものを選ぶことだ。人気があるからといって盲目的に信頼するのではなく、自分で中身を把握した上で使う姿勢が欠かせない。 実務での活用ポイント テスト・検証環境での活用が最適: 本番展開はAutopilotやIntune、MDTなど公式経路を基本とし、非公式ツールはラボや個人端末の素早いセットアップに限定するのが安全な線引き ディスク節約機能は容量制約環境で有効: 古いハードウェアの再活用や、ストレージの少ないデバイスへの展開時に検討する価値がある バージョン管理を徹底する: ツール自体のアップデートで動作が変わる可能性があるため、使用バージョンを記録し、環境ごとに統一しておくと後の検証が楽になる セキュリティ設定を上書きしていないか確認: 一部のユーティリティはデフォルトでセキュリティ機能を無効化する選択肢を提供する。何を変更しているかを必ず把握する 筆者の見解 このようなツールが継続的にアップデートを受け、コミュニティで支持され続けている背景には、「Microsoftの公式ツールが現場の実態に即していない部分がある」という事実がある。 Windowsの展開・管理をめぐるエコシステムは、公式製品だけでは語れない。現場のエンジニアが作ったツールが何年もメンテナンスされ、業務の隙間を埋め続けているのは、ある意味Microsoftへのフィードバックでもある。 公式ツールの改善余地がある領域を非公式ツールが補っているという構図は、Windows展開に限らずよく見られるパターンだ。Microsoftにはこうしたコミュニティのフィードバックを公式製品の改善に積極的に取り込んでほしいと思う。統合プラットフォームとしての強みを持つ企業だからこそ、「公式一本で完結できる」状態を目指し続けてほしい。 とはいえ、今すぐ現場で役立つツールが進化したことは素直にありがたい。特にディスク節約の改善は、古い機材を延命しながらWindows 11への移行を進めている組織にとって現実的な助けになりうる。自分の環境と目的に照らし合わせて、賢く使い分ける判断眼を持っておきたい。 出典: この記事は Unofficial Windows 11 install tool gets faster, can now save you lots of disk space too の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが抱える「永遠の新人問題」に、IBM Researchが正面から取り組んだ。2026年4月に公開されたALTK-Evolveは、エージェントが過去の実行履歴から抽象的な原則を学び取り、新しいタスクに汎用的に適用できる長期記憶システムだ。ベンチマークでは難易度の高いタスクで14.2ポイントの改善を達成しており、AIエージェントの信頼性向上に向けた重要な一歩と言える。 「ログを読み返す」だけでは足りない 現在の多くのAIエージェントは、過去の会話履歴をそのままコンテキストに詰め込む設計になっている。これは「昨日の日報を読み返す新入社員」と同じで、教訓を抽象化して次に生かすことができない。MIT研究によれば、AIエージェントのパイロット導入が失敗する95%の原因は、この「オンザジョブ学習の欠如」にあるという。 ALTK-Evolveが解決しようとするのはまさにこの問題だ。元記事では料理人のメタファーが使われていてわかりやすい。「レシピを暗記したコック」ではなく「酸が脂肪を中和するという原則を理解したシェフ」に育てることが目標だ。具体的な手順を記憶するのではなく、応用可能な知識として蒸留するアプローチである。 仕組み：軌跡から原則へ ALTK-Evolveは2方向のデータフローで動作する。 下方向（観測と抽出）: エージェントの実行軌跡（ユーザー発話・思考プロセス・ツール呼び出し・結果）をLangfuseなどのOpenTelemetryベースのオブザーバビリティツールで捕捉し、構造的なパターンを候補エンティティとして保存する。 上方向（精錬と検索）: バックグラウンドの統合ジョブが重複を排除・低品質ルールを削除し、実績のある戦略を強化する。そして必要なタイミングで関連するガイドラインだけをエージェントのコンテキストにジャストインタイムで注入する。 ポイントは「コンテキストを膨らませない」設計だ。全履歴を詰め込むのではなく、必要なものだけを必要な瞬間に提供するアーキテクチャになっている。これはコスト・レイテンシの観点でも重要な設計判断だ。 ベンチマーク：難しいタスクほど効果が出る AppWorldベンチマーク（平均1.8アプリ・9.5 APIを使う多段階タスク）での評価では、難易度が上がるほどメモリの効果が顕著に現れた。 難易度 ベースライン ＋メモリ 改善幅 Easy 79.0% 84.2% +5.2pt Medium 56.2% 62.5% +6.3pt Hard 19.1% 33.3% +14.2pt 総合 50.0% 58.9% +8.9pt 特に注目すべきは「Hard」カテゴリーだ。19.1%から33.3%への向上は、割合で見れば約74%の改善にあたる。複雑な制御フローが必要な場面でこそ、蓄積されたガイドラインが効果を発揮することが示された。 実務への影響 エンタープライズでAIエージェントを活用する際の最大の課題の一つが「同じ失敗の繰り返し」だ。ALTK-Evolveのようなアプローチは、以下のような形で応用できる可能性がある。 SOP（標準作業手順書）の自動生成: エージェントが繰り返し実行する業務フローから、運用上のガイドラインを自動的に蒸留・蓄積する 環境固有の慣例学習: 社内独自のシステム構成やルール（「このAPIは特定の時間帯に遅い」など）をエージェントが学習・適応する 長期プロジェクトへの応用: 短期タスクではなく、複数週にわたるプロジェクト型エージェントとの相性が特によい 現時点ではLangfuseなどのオブザーバビリティ基盤が前提となるため、すでにMLOps体制を持つ組織が優先的に恩恵を受けやすい。一方、Langfuseのセルフホスト版を活用すれば、中小規模の組織でも比較的低コストで導入を検討できる。 筆者の見解 AIエージェントが「自分で学んで成長する」という方向性は、筆者が強く注目し続けているテーマと完全に合致する。 単発の「指示→実行→終了」ではなく、エージェントが継続的なループの中で経験を積み、次のループで判断の質を高めていく——この設計思想こそが、AIエージェントの本質的な価値を引き出す鍵だと思っている。ALTK-Evolveはその具体的な実装の一例として、非常に参考になる研究だ。 「Hard」タスクで14.2ポイントという数字は特に示唆深い。複雑なタスクほど改善幅が大きいということは、現実の業務に近い状況でこそ記憶システムが意味を持つということでもある。逆に言えば、単純タスクの自動化ではこういった仕組みの効果は限定的で、人間が実際に任せたい「複雑で判断が絡む業務」の方が恩恵が大きい。これはエンタープライズ導入における優先順位付けの観点で重要なポイントだ。 企業がAIエージェントを検討する際、「初回から完璧を求める」のではなく「使いながら学習させる設計を最初から組み込む」という発想の転換が求められる時代になりつつある。今後、こうした「オンザジョブ学習」機能がエージェントフレームワークの標準機能として整備されることを期待したい。 出典: この記事は ALTK‑Evolve: On‑the‑Job Learning for AI Agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが「Windowsの品質」を大きなテーマとして掲げ、2026年中にWindows 11へ18個の改善を届けることを公式確認した。Windows部門トップのPavan Davuluri氏がロードマップを提示し、さらに各チームのエンジニアやデザイナーがXで直接ユーザーのフィードバックに応答。ここ数年では珍しい「全チーム横断での一体感」が生まれている。 主要アップデートの概要 タスクバーがついに自由に動かせる Windows 11リリース当初から最も要望が多かった機能のひとつ、タスクバーの位置変更が復活する。上・左・右への移動が右クリックメニューから操作可能になる予定だ。縦型モニターや複数ディスプレイ環境を使うユーザーには朗報といえる。さらにコンパクトモードなどサイズ変更オプションも提供される見通しで、Windows 10時代の柔軟性が戻ってくる。 スタートメニューがReactを離れ、WinUIへ 現在のスタートメニューはReactベースのコンポーネントが混在しており、それが「もっさり感」の一因だった。MicrosoftはこれをネイティブのWinUI 3に移行させることを確認。プラットフォームレベルでのレイテンシ削減が期待でき、以前のWindowsのような軽快な操作感が戻る可能性がある。 検索結果のランキングも見直され、インストール済みアプリが優先表示されるようになる。「検索したら関係ないウェブ結果ばかり」という不満が解消される方向だ。 Copilotが「必要な場所だけ」に縮小 過去1年で、Notepad・フォト・切り取りツール・エクスプローラーなど多くのアプリにCopilotのエントリーポイントが追加されてきた。これをMicrosoftは見直し、実際に価値を提供できるシナリオに絞る方針を確認した。 Narratorとのクロスデバイス連携など、AI活用自体がなくなるわけではない。「どこでも出てくるAI」から「必要な場所に存在するAI」へのシフトと読める。 その他の主な改善 全18の新機能のうち、大きな方向性として以下が挙げられる： File Explorerの高速化: 動作のパフォーマンス改善 Windows Updateの信頼性向上: アップデート挙動の予測可能性を高める ファーストパーティアプリのネイティブ化: Webラッパーからの段階的な脱却 実務への影響 IT管理者・エンタープライズ担当者への示唆 タスクバーの自由化やコンパクトモードは、「使いにくい」という現場の声に長年向き合ってきた担当者にとって歓迎の変更だ。ただし、Windows Updateの信頼性が実際に改善されるまでは、従来通り慎重な検証フローを維持することを推奨する。「数日様子を見てから展開する」という判断は、引き続き合理的な選択だ。 Copilotエントリーポイントの変更に伴い、グループポリシーやIntuneでの関連設定が変わる可能性もある。現在Copilot関連の制御を行っている環境は、変更内容をあらかじめ把握しておきたい。 開発者・パワーユーザーへの示唆 WinUI 3へのネイティブ移行は、将来的に自社製WindowsアプリをOSのUIに自然に統合しやすくなる方向性を示している。社内向けWindowsアプリを保有する開発チームは、WinUI 3対応の検討を本格化するタイミングかもしれない。 筆者の見解 Windowsを細かく追い続けることに以前ほどの意義を感じにくくなっていた、というのが正直なところだ。しかし今回の動きは少し違う印象を受けた。 「品質優先」というメッセージよりも注目したいのは、複数チームが同じゴールに向かって動いているという現象そのものだ。エンジニアやデザイナーが直接Xでユーザーに応答し、批判に同意し、計画を開示している。これは単なるコミュニケーション施策ではなく、組織内で何かが変わり始めたサインに見える。 タスクバーの自由化やスタートメニューのネイティブ化は、「なぜ最初からそうしなかったのか」という話でもある。ReactやWebラッパーへの傾倒は当時なりの理由があったはずだが、結果としてユーザー体験のコストを払ったのは使う側だった。もったいない回り道だったと思う。 これだけの技術力とユーザーベースを持つプラットフォームだからこそ、本来の実力を正面から発揮してほしい。Copilotの縮小判断も含め、「まず足元を固める」という方向転換は正しいと思う。この路線が2026年を通じて維持されるなら、Windowsに対する評価を少しずつ上方修正することになりそうだ。 出典: この記事は 18 new features coming to Windows 11 in 2026, confirmed by Microsoft の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが「Harrier」と名付けた新しい埋め込みモデル（Embedding Model）ファミリーを電撃リリースした。主要なベンチマークにおいてGoogleのGemini Embedding 2を上回る性能を示しており、オープンソース開発者コミュニティへの本格参入を宣言する動きとして注目を集めている。 埋め込みモデルとは何か——なぜ今これが重要なのか 埋め込みモデル（Embedding Model）は、文章や単語を数値ベクトルに変換する技術であり、RAG（Retrieval-Augmented Generation）、セマンティック検索、ドキュメント類似度判定など、現代のAIアプリケーションの根幹を支えるコンポーネントだ。 LLM（大規模言語モデル）が注目を浴びがちだが、実際のエンタープライズAI実装では「どのモデルで生成するか」よりも「どのモデルで検索・索引化するか」の方が精度に直結することが多い。埋め込みモデルの性能差は、そのままRAGシステムの回答品質の差になって現れる。 Harrierの技術的特徴とベンチマーク結果 MicrosoftのHarrierモデルファミリーは、MTEB（Massive Text Embedding Benchmark）において業界標準の評価を超える結果を示し、Googleの最新埋め込みモデルであるGemini Embedding 2を上回ったと報告されている。 特筆すべきは、このリリースがオープンソース開発者コミュニティを明示的にターゲットにしている点だ。クラウドサービスに閉じた提供ではなく、ローカル環境やセルフホスト構成でも利用できる形での公開は、エンタープライズ利用において重要な意味を持つ。データをクラウドに送らずに高精度な埋め込みを生成できることは、データ主権を重視する日本企業にとって特に響く選択肢になる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 RAG構築の選択肢が広がる 社内文書検索、ナレッジベース、カスタマーサポートAIなどのRAGシステムを構築する際、埋め込みモデルの選択は最初の重要な意思決定だ。Harrierが高精度かつオープンソースで利用可能であれば、AzureやOpenAIのAPIに依存せずに構成を組める。コスト最適化とデータガバナンスの両立を求める現場には朗報だ。 Azure AI Searchとの組み合わせ Microsoftのエコシステムで動く場合、Azure AI SearchのベクトルインデックスとHarrierを組み合わせた構成はほぼ間違いなく動作検証が取りやすい。サポート面での安心感は、他社ベンダーの埋め込みモデルを混在させる構成より高い。 すぐ試せる実践ステップ Hugging Faceで公開されているHarrierモデルをダウンロードし、既存のRAGパイプラインの埋め込み部分だけ差し替えて性能比較する MTEBの日本語タスク（JMTEB）での評価結果が公開されていれば必ず確認する。英語ベンチマークトップでも日本語精度が伴わないモデルは多い ローカルでの推論コストとAPIコールのコストを比較し、スケールに応じた最適解を選ぶ 筆者の見解 このリリースは正直、嬉しいニュースだ。 Microsoftはここ数年、AI領域において「期待したほどではない」と言わざるを得ない場面が続いていた。しかし今回のHarrierは違う。ベンチマークでトップを取り、オープンソースコミュニティに向けてタイミング良く公開する——これは、Microsoftが本気を出せばどこまでやれるかを示すものだ。 埋め込みモデルという地味に見えて実は重要な領域で突き抜けた成果を出せるのは、研究開発投資の厚みがあってこそ。「個別機能では最強ではないが総合力では他の追随を許さない」というMicrosoftの強みが、ここでも発揮されている。 ただし、日本語性能については独自に検証が必要だ。英語中心のベンチマークで高得点を取ることと、日本語コーパスでの実用精度は別の話である。日本のIT現場でHarrierを使うなら、まず自社の実データで評価することを強くすすめる。 Microsoftがこの勢いで基盤モデル層の競争力を高め続けてくれれば、エコシステム全体にとってプラスになる。今回のような動きが続くことを期待したい。 出典: この記事は Microsoft’s new Harrier models top benchmarks, outperforming Google’s Gemini Embedding 2 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界最大手クラスの広告代理店グループ、フランスのPublicis Groupeがビジネスの根幹をMicrosoftクラウドとCopilotに委ねる決断を下した。単なる技術採用の発表ではない。マーケティング・広告という「人間の創造性」が核心だった領域で、自律型AIエージェントが手作業ワークフローを本格的に置き換えようとしている。この動きが示すものは何か、日本のIT現場にとって何を意味するのかを考えてみたい。 Publicisが選んだMicrosoftという選択肢 Publicis Groupeは世界90か国以上で10万人超を擁する広告・コミュニケーション企業グループだ。そのグループが、ブランドコミュニケーション業務全体をMicrosoft Cloudプラットフォーム上に集約し、CopilotおよびAIエージェントで業務フローを再設計する方針を表明した。 注目すべきは「AIをツールとして使う」ではなく、「AIエージェントが自律的に推論・行動することで手作業フローを置き換える」というアーキテクチャ思想だ。これはRPA（ロボティック・プロセス・オートメーション）の延長線上にあるものではなく、コンテキストを理解し、意思決定の一端を担うエージェント型AIの産業応用がついに本格的なフェーズに入ったことを示している。 なぜ広告業界がAIエージェントの最前線になるのか 広告・マーケティング業務の特性が、AIエージェント適用のユースケースとして非常に適している。クリエイティブブリーフの整理、ターゲットセグメントの分析、複数メディアへのコンテンツ最適化、効果測定レポートの生成——こうしたタスクはいずれも「大量のデータを参照しながら定型的な判断を繰り返す」構造を持つ。つまり「人間でなければできない創造性」と「AIが得意な反復・最適化処理」が明確に分離しやすい領域なのだ。 Publicisのような大規模グループが全社的にプラットフォームを統一することで、各クライアントキャンペーンのデータ、過去の成功事例、クリエイティブ素材が一元管理された上でAIエージェントが動作できる。部署ごとにバラバラなツールを使い続ける「部分最適」の積み重ねではなく、統合プラットフォーム上での「全体最適」を目指した判断と言える。 日本のIT現場・エンタープライズへの影響 このニュースを「海外の大企業の話」として流すのはもったいない。日本企業にとって、以下の点で実務的な示唆がある。 1. 「AIエージェント導入の先行事例」として参照できる Publicisのような大規模なグローバル導入事例は、日本の大手エンタープライズが役員・経営層にAIエージェント投資を説明する際の有力な比較事例になる。「競合他社がやっている」論法は日本の意思決定プロセスで依然として強力だ。 2. Microsoft 365 + Copilot環境を持つ企業は「同じ土台」にいる Publicisが使うMicrosoft Cloudは、日本企業の多くがすでに契約しているM365と地続きのプラットフォームだ。AIエージェント機能（Microsoft Copilot Studio、Azure AI Foundryベースのエージェント）は段階的に既存テナントにも展開されてくる。今から社内ユースケースを洗い出して実験しておくことが、来たる波に乗る準備になる。 3. 「禁止」ではなく「仕組み化」が正解 AIエージェントをセキュリティリスクとして全社禁止する企業は今後も出てくるだろう。しかしPublicisの事例が示すように、グローバル競合はAIエージェントで業務効率を指数関数的に高めている。「禁止」で対応できる期間には限りがある。ガバナンスを整えながら安全に使える仕組みを社内に作ることが、IT部門の本来の役割だ。 実務での活用ポイント: Microsoft Copilot Studioで小規模なエージェント（社内FAQ応答、定型レポート生成）から始める まずデータの一元化・ガバナンスを整備する（エージェントの品質はデータ品質に直結する） 「何をAIに任せるか」ではなく「何を人間が最終判断するか」を先に決める 筆者の見解 Microsoftのエンタープライズ戦略として見ると、今回のPublicis案件は「総合力での勝利」という形だ。個々のAI機能の優劣がどうであれ、Azure・M365・Dynamics・Power Platformを統合した「ワンプラットフォーム」の吸引力は本物で、大規模な業務変革を検討するエンタープライズがMicrosoftを選ぶ理由は依然として十分にある。 Copilot単体の能力については、まだ課題があるのは率直に認めるべきだろう。しかしPublicisのような事例が積み重なることで、実際の業務フローに組み込まれた実践知が蓄積されていく。それはいずれCopilotの改善に反映されるはずで、そのサイクルが回り始めていることには素直に期待している。 一方、日本のエンタープライズに目を向けると、「AIが来ている」と頭では理解しながら、現場への展開が全く追いついていない企業がまだ多い。Publicisのような意思決定のスピードと覚悟は、日本の組織文化とは大きなギャップがある。技術の問題というよりも、変化を本気で経営課題として捉えられるかどうかの問題だ。 AIエージェントは「AIに何をやらせるか」という段階をすでに超えつつある。「AIに何を託し、自分はどの抽象度で意志を介在させるか」という問いに向き合える組織だけが、次の5年で生き残れる。Publicisの全面採用は、そのリアルな手触りを示している。 出典: この記事は Global ad agency giant Publicis goes all-in on Microsoft Cloud and Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Apache ActiveMQのClassicエディションに、13年以上にわたって見過ごされてきたリモートコード実行（RCE）脆弱性が発見された。CVSSスコア8.8と高深刻度に分類されるCVE-2026-34197は、エンタープライズ、Webバックエンド、政府系システムなど幅広い現場で稼働するJavaメッセージブローカーを直撃する。パッチはすでにリリースされているが、ActiveMQが過去に実際の攻撃対象となってきた経緯を踏まえると、対応の優先度は極めて高い。 脆弱性の仕組み——「無害なパーツ」が組み合わさると凶器になる この脆弱性の核心は、Jolokia管理API経由で公開されている addNetworkConnector というブローカー関数にある。攻撃者はこの関数を悪用し、外部のSpring XMLファイルをActiveMQに読み込ませることができる。ブローカーは初期化処理の中でそのXMLを解釈・実行するため、結果として任意のシステムコマンドをサーバー上で走らせることが可能になる。 通常、Jolokia APIへのアクセスには認証が必要だ。しかし、バージョン6.0.0〜6.1.1については別の既知の脆弱性（CVE-2024-32114）によってAPIが認証なしで公開されており、この範囲では認証不要のRCEが成立してしまう。 影響を受けるバージョンは以下のとおり： ActiveMQ Classic 5.19.4未満のすべてのバージョン ActiveMQ Classic 6.0.0〜6.2.3 修正済みバージョンは 5.19.4 および 6.2.3。該当バージョンを使っている場合は即刻アップデートを検討してほしい。 なぜ13年間気づかれなかったのか 今回の発見で特筆すべきは、脆弱性そのものと同じくらい「どうやって見つかったか」だ。Horizon3のリサーチャーであるNaveen Sunkavally氏は、AIアシスタントに「いくつかの基本的なプロンプトを投げただけ」でこの問題を特定したと述べている。「80%はAI、残り20%は人間によるラッピング」という表現が印象的だ。 Jolokia、JMX、ネットワークコネクター、VMトランスポートという各コンポーネントは、それぞれ単独では仕様どおりに動作する。問題は「組み合わせたとき」だ。人間のセキュリティ審査では、個々の機能を個別にレビューすることが多く、複数の独立した実装が連鎖して生む危険な相互作用を見落としやすい。AIはこうした「コンポーネント間の文脈横断的な推論」を得意とするため、長年見逃されていたパスを短時間で特定できた。 これは、AIによる脆弱性発見が本格的な実用段階に入りつつあることを示す具体的な事例だ。 攻撃の痕跡を見逃すな——ログで何を見るか CVE-2026-34197は現時点で実際の悪用事例は報告されていないが、Horizon3はブローカーログに攻撃の痕跡が残ると指摘している。確認すべきポイントは以下のとおり： 内部トランスポートプロトコル VM を使用した不審なブローカー接続 クエリパラメーターに brokerConfig=xbean:http:// を含む接続試行 設定に関する警告メッセージ（これが出た時点でペイロードはすでに実行されている） ActiveMQを運用しているチームは、監視ルールにこれらのパターンを追加しておくことを強く勧める。 実務への影響——日本企業が今すぐやるべきこと ActiveMQ Classicは、Artemisブランチへの移行が進む一方で、レガシーJavaシステムや長期稼働のエンタープライズ基盤には今もClassicが根を張っている。特にSIerが構築した大規模システムや、長年改修されていないオンプレミス環境では使用が残っている可能性が高い。 今すぐ確認すべき事項： バージョン棚卸し: 社内・クラウド上で稼働するActiveMQのバージョンを洗い出す パッチ適用: 5.19.4または6.2.3への更新を最優先タスクとして計画する Jolokia APIの公開状況を確認: 外部からのアクセスが遮断されているか確認する CVE-2024-32114の対応状況も合わせて確認: 6.0.0〜6.1.1を使っている場合は認証バイパスの脆弱性も同時に対処する ログ監視ルールの追加: 上記の攻撃シグネチャをSIEMや監視ツールに反映する ActiveMQは過去にCVE-2016-3088やCVE-2023-46604がCISAのKEV（既知の悪用脆弱性リスト）に掲載されており、攻撃者にとって馴染み深いターゲットだ。「まだ攻撃されていないから大丈夫」という判断は通用しない。 筆者の見解 セキュリティの話は正直あまり好きなジャンルではないのだが、今回の件はそれとは別次元で興味深かった。 この脆弱性が「各コンポーネント単体では問題なく動いていた」という点は、ソフトウェアセキュリティの本質的な難しさを突いている。人間のレビューは「書かれた仕様」を検査することに長けているが、「複数の正しく動く部品が組み合わさって生まれる意図しない動作」を見抜くのは苦手だ。今回のAIを活用した発見手法は、その弱点をカバーする新しいアプローチとして現実的な価値を示した。セキュリティ審査にAIを組み込むことは、もはや「試験的な取り組み」ではなくなりつつある。 一方で、こういう脆弱性を見るたびに思うのは、「なぜ13年間も外部からJolokia APIが到達できる状態だったのか」という問いだ。ゼロトラストの観点からは、管理APIは内部ネットワークからも必要最小限のアクセスしか認めるべきではなく、認証の有無にかかわらず外部への露出は設計上排除されているべきだ。脆弱性修正は当然必要だが、それだけで終わらせず、「なぜこの経路が存在していたのか」という構造的な問いにも向き合ってほしい。 ActiveMQを運用しているチームは、今回をきっかけにArtemisへの移行計画も真剣に検討する価値がある。Classic継続利用が技術的負債の積み上げになっていないか、立ち止まって考えるタイミングかもしれない。 出典: この記事は 13-year-old bug in ActiveMQ lets hackers remotely execute commands の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Foundryとモデルコンテキストプロトコル（MCP）の統合が、着実に実用フェーズへ進んでいる。Azure FunctionsでホストしたMCPサーバーをFoundryエージェントのカスタムツールとして接続する手順が、Azure SDK Blogで公開された。単なる実装メモにとどまらず、エンタープライズ規模での「AIエージェントへのツール提供」というアーキテクチャの方向性を示す内容だ。 MCPサーバーをFoundryエージェントに繋ぐ意義 MCPはVS CodeやCursorなどの開発ツールで既に広く使われているプロトコルだ。自社のデータベースクエリやAPI呼び出し、業務ロジックをMCPツールとして実装している組織は少なくない。 ここで注目すべきは「そのMCPサーバーをそのままFoundryエージェントに繋げる」という点だ。開発者向けのツールをエンタープライズ向けのAIエージェントにも提供できる。ツールの実装は1回で済み、消費するクライアント側を増やすだけでよい。 Azure Functionsをホスティング基盤に選ぶ理由も明確だ。サーバーレス課金、スケーラブルなインフラ、そして後述する認証機構の充実——この3点が揃っている。 接続の全体像 接続手順は大きく4ステップだ。 ビルトインMCP認証の有効化: Azure Functionsのデフォルト（キーベース認証）を無効化し、MCP専用の認証に切り替える。サンプルをそのまま使った場合は設定済み。 エンドポイントURLの確認: MCP拡張ベースのサーバーであれば https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp が対象。 認証方式に応じた資格情報を取得: 後述の4方式から選択。 Foundryポータルでエージェントにツールを追加: エンドポイントと資格情報を入力するだけ。 認証方式の選び方 本稿の実務的な核心はここだ。4つの認証方式が提供されており、フェーズに応じて使い分けることができる。 キーベース認証（デフォルト） HTTPリクエストヘッダーに共有のfunctionアクセスキーを含める方式。開発・検証フェーズで手っ取り早く試したいときに向く。ただし本番環境での使用は避けるべきだ。 Microsoft Entra認証 エージェント自身のマネージドID（エージェントID）またはFoundryプロジェクト共有のマネージドIDを使う方式。本番環境ではエージェントIDを使い、プロジェクト共有IDは開発に留める。エンタープライズ環境での標準的な選択肢になる。 OAuthアイデンティティパススルー ユーザーがサインインして認可し、そのトークンをエージェントが使って認証する方式。ユーザーごとのコンテキストが必要な業務シナリオ——たとえばユーザー別のデータアクセス権を持つAPIを呼び出す場合——で必須になる。設定手順は増えるが、本番の多くのケースでこれが正解だ。 未認証アクセス パブリックな情報にのみアクセスするMCPサーバーや、開発環境での動作確認に限定して使う。 実務への影響 日本のエンタープライズ環境で考えると、この構成が刺さる場面はいくつかある。 既存のMCPツール資産の活用: 社内ポータルやERPへのAPIアクセスをMCPツールとして実装している組織は、そのままFoundryエージェントに接続できる。「AIチャットボットのためだけに別のAPI連携を作り直す」という二重投資を避けられる。 認証の段階的強化: 開発初期はキーベース→ステージングはマネージドID→本番はOAuthパススルー、というように段階的に強化できる設計は、実際の開発サイクルに合っている。 Microsoft Entra IDとの自然な統合: エージェントIDやマネージドIDをベースにした認証は、既存のEntra ID管理に乗っかれる。新たなID管理体制を構築する必要がなく、既存のロールベースアクセス制御（RBAC）設計を使い回せる。 Azure Functionsの従量課金モデルも重要だ。MCPサーバーの呼び出しは間欠的になることが多く、常時起動のコンテナより大幅にコストを下げられる可能性がある。 筆者の見解 MCPをAzure Functionsでホストし、Foundryエージェントに繋ぐ——この構成は「AIエージェントの実装において、ツール提供側と消費側を分離する」という設計思想を体現している。 VS CodeやCursorで使っているMCPサーバーを、そのままエンタープライズ向けのFoundryエージェントにも流用できるのは、開発者にとって本質的な効率化だ。「AIの機能を足す」のではなく「既存の業務ロジックをAIが使えるようにする」という発想の転換でもある。 プラットフォームとしてのAzureとFoundryの組み合わせは、こういったエンタープライズ統合において強みを発揮する。特に認証周りをMicrosoft Entra IDに統一できる点は、ゼロトラストアーキテクチャを推進する組織にとって見逃せない。AIエージェントもID管理の対象として既存の統制フレームワークに組み込める。 MCPというプロトコル自体はオープンな仕様だ。Foundryに乗ることで、このエコシステムに広く投資できる。特定のクライアント環境に縛られずにツールを使い回せる設計は、中長期的なメンテナンスコストを下げる。 エンタープライズAIエージェントの実装を検討しているチームには、まずAzure Functionsでシンプルなカスタムツールを1つ作り、Foundryエージェントに繋いで動かしてみることを勧めたい。認証はキーベースから始めて、本番要件に合わせてEntra IDに移行すればいい。ゴールから逆算するより、動く状態を素早く作って反復するほうが、エージェント実装の感触をつかむには早い。 出典: この記事は Give your Foundry Agent Custom Tools with MCP Servers on Azure Functions の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

多要素認証（MFA）を導入しているから安心、という認識が今まさに崩されようとしている。「EvilTokens」と名付けられた新型フィッシングキットは、MicrosoftのデバイスコードAuthentication Flowという正規の認証メカニズムそのものを武器に変え、AIと自動化を組み合わせて大規模な標的型攻撃を可能にしている。MFAを入れた企業が「対策済み」と油断するなかで、静かに侵害が広がっている点が最も深刻だ。 デバイスコード認証の仕組みと悪用の構造 Microsoftのデバイスコードフロー（Device Authorization Grant）は、ブラウザやキーボードを持たないデバイス——スマートTVやIoT機器、プリンター等——向けに設計された認証方式だ。ユーザーは別のデバイスから microsoft.com/devicelogin にアクセスし、表示されたコードを入力することで認証を完了させる。 EvilTokensはこの仕組みを逆手に取る。攻撃者があらかじめデバイスコードを生成し、それをフィッシングメールやTeamsメッセージなどに埋め込んで標的に送りつける。被害者が「正規のサインインページ」だと思ってコードを入力した瞬間、攻撃者側のセッションに有効なアクセストークンとリフレッシュトークンが払い出される。 ここが重要なポイントだ。 被害者は自分のパスワードとMFAを正しく使って認証を完了している。だからこそMFAが役に立たない。払い出されたトークンは長期有効であることも多く、攻撃者はパスワードを知らなくても長期間にわたって企業メールや各種M365サービスに侵入し続けられる。 さらにEvilTokensはAIによるフィッシング文面の自動生成と、攻撃フロー全体の自動化を組み込んでいる。従来の手動攻撃より大幅にスケールアップが可能で、一人の攻撃者が多数の標的を同時並行で狙える構造になっている。 狙われる情報と被害のシナリオ 主たる標的はExchange Online上の企業メールアカウントだ。侵害に成功した後、攻撃者は受信トレイを監視し、財務情報や契約書、社内決裁フローなどを収集する。BEC（ビジネスメール詐欺）への転用や、他社への横展開も容易に行える。 日本企業においても、M365を全社展開しているケースは珍しくなく、Teamsを業務連絡の主軸に置く組織ではフィッシングメッセージが社内連絡に見せかけて届くリスクがある。 実務での対策ポイント 1. デバイスコードフローを条件付きアクセスでブロックする 最も直接的な対策は、必要のない場面でデバイスコードフローそのものを無効化することだ。Microsoft Entra IDの条件付きアクセスポリシーで、デバイスコードフローを使用できる対象を管理デバイスや特定のIPレンジに限定する、もしくは原則ブロックする設定を適用する。多くの一般従業員にとって、このフローを使う正当な理由はほぼない。 2. 継続的アクセス評価（CAE）とトークン有効期間の見直し アクセストークンのデフォルト有効期間を短縮し、Continuous Access Evaluation（CAE）を有効にする。これにより、不審なセッション変化を検出した際にトークンをリアルタイムで失効させられる。 3. Microsoft Defender for Cloud Apps（MCAS）でトークン利用を監視 異常な地域からのトークン利用や、短時間での大量メール参照などの行動を検出するルールを設定しておく。侵害されていても早期に検知できる体制が欠かせない。 4. 社員教育でデバイスコードフィッシングを周知する 「MFAをきちんと使ったのに侵害された」という事例を共有し、「見覚えのないページにコードを入力しない」という習慣を根付かせる。ITリテラシー研修にこのシナリオを追加することを強く推奨する。 筆者の見解 セキュリティの話題は細かい議論になりがちで、正直あまり得意なジャンルではない——とはいえ、このトピックには技術的に強い関心を持っている。 EvilTokensが突いているのは、Microsoftが「利便性のために設計した正規機能」だ。悪意あるコードが混入したわけでも、脆弱性を突かれたわけでもない。ゼロトラストの観点からすれば、これは「デフォルトで過剰な信頼を与えてしまっているフロー」の問題に他ならない。必要な人だけが、必要なときだけ使える——そのJust-In-Timeの思想が徹底されていれば、攻撃面を大幅に削れる。 MicrosoftはEntra IDに条件付きアクセスやCAEといった強力な制御手段を持っている。問題は、それらの設定が「やろうと思えばできる」状態に留まっていて、多くの組織でデフォルトのまま放置されている点だ。「今動いているから大丈夫」という空気がある限り、こうした攻撃は静かに成功し続ける。 Microsoftにはゼロトラストの理念をより積極的に「デフォルト設定」へ組み込んでいってほしい。設定しなければセキュアにならないのではなく、設定しなくてもある程度セキュアである——そのベースラインを引き上げる力は、Microsoftには十分にあるはずだ。 出典: この記事は EvilTokens Phishing Kit Uses Microsoft Device Codes to Bypass MFA の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Adobeが重大なセキュリティ更新を配信した。CVE-2026-34621として追跡されているこの脆弱性は、攻撃者がユーザーのシステム上のローカルファイルに不正アクセスできるという深刻なものだ。Adobe製品は企業・個人を問わず幅広く使われているだけに、迅速なパッチ適用が強く求められる。 CVE-2026-34621とは何か CVE-2026-34621は、Adobe製品に存在するいわゆる「ローカルファイルインクルージョン（LFI）」系の脆弱性だ。攻撃者はこの欠陥を悪用することで、本来アクセスできないはずのシステム上のファイルを読み取ることができる。 具体的には、悪意を持って細工されたドキュメントやコンテンツをユーザーが開いた際に、攻撃コードが実行され、OSのファイルシステム上にある任意のファイルが漏洩するリスクがある。パスワードファイル、設定ファイル、認証トークンなど、機密性の高い情報が標的になりうる。 どの製品が影響を受けるか Adobeのセキュリティアドバイザリが対象とする製品は、Adobe Acrobat / Reader、Adobe Creative Cloudコンポーネントなど複数にわたる可能性がある。企業環境ではAcrobatが特に広く展開されており、エンドポイントの管理担当者は対象バージョンを速やかに確認すべきだ。 CVSSスコアが高い「クリティカル」評価の脆弱性であることから、Adobeも優先度の高いパッチとして位置付けている。 実務への影響——日本のエンジニア・IT管理者に伝えたいこと 1. パッチ適用の優先順位を上げる ローカルファイルへの不正アクセスを許す脆弱性は、情報漏洩インシデントに直結する。「今すぐ壊れるわけではない」という理由で後回しにしがちだが、攻撃者はこうした隙を見逃さない。Adobe製品をエンドポイント管理ツール（Intune、SCCM等）で配布している環境では、今週中を目標にパッチ展開を計画したい。 2. 影響範囲の棚卸しを シャドーITとして個人インストールされたAdobe製品が存在する環境も少なくない。MDM管理外のデバイスでAdobe製品が使われていないか、この機会に棚卸しする価値がある。 3. LFI脆弱性の本質を理解する LFI系の脆弱性が怖いのは、「アプリケーションの権限でファイルを読み取る」点にある。管理者権限で動作するプロセスに脆弱性があれば、システム全体のファイルが対象になる。最小権限の原則（Least Privilege）で動作環境を設計していれば被害を限定できる——これはゼロトラスト設計の基本中の基本だ。 4. ログ監視と検知ルールの整備 既に悪用されていないかを確認するため、ファイルアクセスログを遡って確認しておきたい。Microsoft Defenderや他のEDRソリューションで、異常なファイルアクセスパターンを検知するルールを今のうちに整えておくことが有効だ。 筆者の見解 セキュリティ系の話題は正直なところ得意分野ではないのだが、こうしたローカルファイルアクセス系の脆弱性は技術的に興味深い。仕組みを理解すると「なぜこんな穴が生まれるのか」という設計上の問題が見えてきて、それはそれで面白い。 ただ、今回改めて思うのは「ゼロトラストアーキテクチャの前提が崩れる問題」だということだ。ネットワーク境界さえ守ればいい時代はとっくに終わった。エンドポイント上で動くアプリケーション一つひとつが、最小権限で動作し、異常なアクセスを即座に検知できる状態を維持することが求められる。VPNを中心に据えた旧来のセキュリティモデルとゼロトラストを中途半端に組み合わせた環境では、こうした脆弱性が致命傷になりやすい。 Adobe製品は企業の業務フローに深く組み込まれている分、「使わない」という選択肢が取りにくい。だからこそ、パッチ管理と最小権限設計を組み合わせた多層防御を地道に積み上げるしかない。地味だが、これが結局は最も確実な道だ。 今すぐAdobeの公式セキュリティアドバイザリを確認し、対象製品のバージョンとパッチ適用状況を把握することから始めてほしい。 出典: この記事は Adobe brings Security Updates to tackle CVE-2026-34621 vulnerability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIは「見て理解する」がまだ苦手——査読論文が突きつけた現実 「マルチモーダル対応」を謳うAIモデルが次々と登場する中、実際の視覚的推論能力はどこまで信頼できるのか。2026年4月号の学術誌『Pattern Recognition』に掲載予定の査読済み論文が、その問いに正面から答えた。 研究チームはOpenAI・Google DeepMind・xAI・DeepSeekを含む計9つの最先端マルチモーダルLLMを、独自設計のベンチマークで評価。結果は「モデルが大きければ賢い」という通俗的な理解を根底から覆すものだった。 何を測ったのか——「エントロピー指標」という新基準 今回の評価が従来と大きく異なる点は、単純な正答率だけでなく一貫性（consistency）を測定したことにある。 研究チームは複数画像を用いた視覚推論タスクを設計し、選択肢の並び順をシャッフルすることで位置バイアス（positional bias）の有無を検出した。さらに「エントロピー」という指標を導入し、モデルが問題の提示形式が変わっても同じ答えを維持できるかを数値化した。 低エントロピー = 形式が変わっても安定して同じ答えを出せる → 真に理解している 高エントロピー = 選択肢の並び方次第で答えが変わる → 表面的なパターンマッチングに依存 この視点は重要だ。実世界でAIを使う場面では、同じ内容をわずかに違う角度から提示することは日常茶飯事。そのたびに答えが変わるようでは、業務への組み込みは難しい。 評価結果：勝者と敗者 ChatGPT-o1が総合首位 OpenAIのChatGPT-o1が全体精度82.5%で首位に立ち、かつエントロピー値も最低——つまり最も安定した推論を示した。話題性では他モデルに劣ることも多いo1だが、地道な推論特化の設計が視覚領域でも効いている。Gemini 2.0 Flash ExperimentalとChatGPT-4oがこれに続いた。 大型モデルの誤算——Grok 3の「過剰棄権」 xAIのGrok 3（推定2.7兆パラメータ）は規模こそ最大級だったが、精度は上位グループを大きく下回った。特徴的だったのは「None of the provided choices（該当なし）」を過剰に選択する傾向——正解が選択肢の中に存在するにもかかわらず。研究者はこれを「過保守的な推論スタイル」と表現している。答えに自信が持てないとき、答えることを拒否してしまうモデルは、実務での信頼性が低い。 DeepSeekビジュアル系の誤算 最も注目すべき発見の一つがDeepSeek Janusシリーズの低評価だ。Janus 1BとJanus 7Bはともにエントロピー値がワースト水準で、選択肢の並び替えによって答えが大きく変動した。テキスト推論で注目を集めたDeepSeekのR1モデルとは対照的に、マルチモーダル・ビジュアル系はまだ成熟していないことが浮き彫りになった。 実務への影響——どこに注意すべきか 自動運転・医療・製造への応用に慎重さが必要 ビジュアル推論が求められる代表的な分野——自動運転の周囲認識、医療画像診断（CTや内視鏡）、製造ラインの外観検査——では、AIの「安定した判断」が不可欠だ。精度が高くても一貫性が低ければ、実装リスクは許容できない水準になる。 IT管理者やシステムアーキテクトにとっての実務ヒントを整理する： 選択したモデルで必ず独自ベンチマークを走らせる: 汎用スコアが高くても、自社データセットで試さなければ意味がない 選択肢の並び順を変えて同一タスクを複数回実行する: 答えがブレるモデルは本番環境で使わない 「棄権率」も評価項目に加える: Grok 3のように「わからない」と言いすぎるモデルはシステム全体の処理効率を下げる マルチモーダルとテキスト専用の評価を分けて考える: 同じプロバイダーでも、テキスト系とビジュアル系で能力差が大きい場合がある 筆者の見解 今回の研究が示すメッセージは明快だ——「何千億パラメータ」という数字は、実用的な推論能力を保証しない。 Grok 3のケースは特に示唆深い。巨大なモデルが「わからないから答えない」という逃げを選ぶのは、ある意味で訓練データや評価指標の問題でもあるが、実世界では致命的な弱点になる。システムが判断を拒否するたびに、人間がカバーしなければならない。それでは自動化の意味がない。 DeepSeekについては、テキスト推論での台頭は本物だったとしても、ビジュアル系が同水準かどうかは別の話だと改めて認識すべきだろう。「あのモデルは凄い」という印象が先行しがちな時代だが、用途ごとの精査なしにAIを業務組み込みするのは危険だ。 一方でChatGPT-o1が安定した首位を取ったことは、「推論に特化した訓練」の有効性を証明している。速さや派手さではなく、一貫した判断力を磨く方向性——これはAIシステムを設計する側にとっても学ぶべき思想だと感じる。 AIが実世界で「使える」ツールになるためには、正確さと一貫性の両立が不可欠だ。この研究が示す評価軸——エントロピー、位置バイアス、棄権率——は、今後のモデル選定基準として業界全体に広まってほしい。ベンチマークが実態を正確に反映するものに進化していくことが、AIへの信頼構築の第一歩になる。 出典: この記事は Study Shows Today’s Top AI Models Struggle With Visual Reasoning — Raising Concerns for Real-World Use の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

LG AI Researchは2026年4月9日、次世代マルチモーダルAI「EXAONE 4.5」を公開した。テキストと画像を同時に処理・推論できるこのモデルは、STEM分野の5種ベンチマークで平均77.3を記録。韓国発のAIがグローバルな競争の最前線に踏み込んできた事実として、日本のエンジニアコミュニティにとっても注目に値するニュースだ。 EXAONE 4.5とは何か EXAONEは、LG AI Researchが開発を続ける大規模言語モデル（LLM）シリーズだ。今回の4.5は、テキストのみを扱う従来型を超え、画像とテキストを統合して理解・推論するマルチモーダル能力を前面に打ち出している。 マルチモーダルというと「画像を見て説明する」程度に捉えがちだが、実際にはもっと深い。図表・グラフ・技術ダイアグラムを読み込み、そこから数学的・論理的な推論を展開できるかどうかが問われる。これがSTEM（科学・技術・工学・数学）系ベンチマークの高スコアに直結している部分だ。 ベンチマーク結果をどう読むか 今回公表されたSTEM系5種ベンチマークの平均スコアは77.3。これは複数の著名なフロンティアモデルを上回る数字として示されており、素直に評価してよい成果だろう。 ただし、ベンチマークと実務での使い勝手は常に別の話だ。STEMテストは特定の問題形式に最適化されやすく、汎用的な思考力や自然言語対話の品質を完全には反映しない。スコアは「ポテンシャルの目安」として参照するのが正しい使い方だ。 日本のIT現場への影響 エンジニアが押さえるべきポイント EXAONE 4.5の登場で、モデル選択の選択肢が実質的に広がる。以下のような場面で恩恵をもたらす可能性がある。 技術文書・仕様書の自動解析: 図表を含むPDF仕様書や回路図を直接入力として処理できるマルチモーダルモデルは、ドキュメント解析ワークフローの自動化に力を発揮する STEMドメインの専門タスク: 数式・化学式・工学図面を扱う製造業・研究開発領域では、マルチモーダル性能が直接的な価値になる マルチモデル戦略の最適化: コストと性能を目的に応じて使い分けるアーキテクチャにおいて、新たな有力な選択肢が加わる IT管理者が確認すべきこと EXAONE 4.5のエンタープライズ向け展開形態は今後の発表次第だ。オンプレミス・プライベートクラウドへの導入を許容するライセンスかどうか、そして日本語処理能力がどの水準かを確認してから評価を進めるのが現実的な手順になる。韓国語・英語中心に最適化されたモデルが日本語タスクでどこまで通用するかは、実際に検証するまで慎重に見ておきたい。 筆者の見解 この発表で最も注目すべきは、スコアの数字そのものではなく「韓国の大手総合電機メーカーが、世界トップクラスのフロンティアAIモデルを継続的にリリースし続けている」という事実だと思う。 AIの競争はもはや米国の数社だけの話ではない。欧州・アジア各地から有力なモデルが次々と登場しており、その多様化は開発者にとって純粋に選択肢の増加を意味する。特定のベンダーに縛られず、タスクに応じて最適なモデルを選ぶ時代が確実に到来している。 一方で私がいつも意識しているのは、「ベンチマークスコアの高さより、自律的なループで動き続けられるか」という視点だ。AIエージェントとして実務に組み込んだとき、人間が細かく指示を出し続けなくても目標に向かって走り続けられるか——これがモデル評価の本質的な軸になりつつある。EXAONE 4.5がその面でどんな実力を見せるか、エージェント統合の実事例が出てくるのを楽しみにしている。 フロンティアモデルの競争が激しくなるほど、エンジニアの武器は増える。LGのこの挑戦は、AI市場全体の多様性を高める意味でも歓迎すべき動きだ。 出典: この記事は LG Reveals Next-Gen Multimodal AI ‘EXAONE 4.5’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIが「GPT-5.2-Codex」を発表した。単なるコード補完ツールの延長ではなく、汎用コーディングエージェントへの「ステップチェンジ」と位置づけたこの発表は、AIによるソフトウェア開発の在り方を根本から問い直す動きとして注目に値する。 GPT-5.2-Codexとは何か GPT-5.2-Codexは、OpenAIの最新大規模言語モデル「GPT-5」のトレーニングスタックと、コーディング特化モデル「Codex」の知見を統合した新モデルだ。主な特徴は以下の通りだ。 処理速度: 従来比約25%の高速化を実現 コンセプトの転換: コード「生成」ツールから、コーディング「エージェント」へ 統合アーキテクチャ: GPT-5の汎用推論能力とCodexのコード特化能力を融合 従来のCodexがコード補完・スニペット生成に特化していたのに対し、GPT-5.2-Codexはタスクを自律的に理解・計画・実行するエージェント動作を目指している。 「コード生成」から「コーディングエージェント」への転換 ここで重要なのは、OpenAIがこの発表を「ステップチェンジ」と表現している点だ。 従来のAIコーディングツールは「人間が指示し、AIがコードを書く」モデルだった。エンジニアがプロンプトを書き、AIがコードを返す——その繰り返しだ。 しかしコーディングエージェントの世界では、ゴールを伝えればエージェントが自律的にコードを書き、テストし、デバッグし、必要に応じて設計を見直す。人間の関与ポイントが根本的に変わる。 この変化は単なる性能向上ではない。開発プロセス全体の再設計を意味する。 日本のエンジニア・IT管理者への影響 実務での活用ポイント エンジニア向け: コーディングエージェントは「補完ツール」ではなく「タスクの委託先」として扱う発想の転換が必要 まずはスコープを明確に限定したタスク（単体テスト生成、リファクタリング、ドキュメント生成など）から試す エージェントの出力をレビューする能力——コードを読む力——は引き続き不可欠であり、むしろ重要性が増す IT管理者・CTO向け: コーディングエージェントの導入は「ツールの追加」ではなく「開発ワークフローの再設計」として捉える セキュリティポリシーとの整合（コードレビュープロセスの維持、機密情報の扱い）を事前に整備する 「禁止」より「安全に使える仕組みの整備」が現実的で効果的なアプローチだ なぜこれが重要か 日本のソフトウェア開発現場では、まだAIコーディングツールを「便利なオートコンプリート」として使っているケースが多い。しかしコーディングエージェントが実用レベルに達すると、開発スピードと品質の非線形な向上が期待できる。 競合他社・海外企業がこのパラダイムを積極活用し始めた場合、従来型の開発フローを続ける組織との差が急速に広がる可能性がある。「いつか導入する」では遅い局面が近づいている。 筆者の見解 「コード生成からコーディングエージェントへ」という転換を、OpenAIが正面から宣言したことの意義は大きい。業界全体が「AIに何をやらせるか」から「AIに何を託し、自分はどの抽象度で判断を介在させるか」という問いへ移行しているという確かなシグナルだ。 私が最も重要と考えるのは、エージェントが「自律的なループで動き続ける」という設計思想だ。人間が逐一指示を与えるのではなく、目的を渡したらエージェントが自律的に計画・実行・検証を繰り返す——この仕組みを設計できるかどうかが、これからのエンジニアの価値を左右する。 GPT-5.2-Codexがどこまでこの理想に近づいているかは、実際に使い込んでみないとわからない。25%の高速化は数字として明確だが、「汎用コーディングエージェント」という看板に実質が伴っているかは冷静に見極める必要がある。 コーディングエージェントの分野は今まさに激しく動いている。どのツールを選ぶにせよ、「エージェントに何を託し、自分はどの抽象度で意志を介在させるか」 を自分の言葉で定義できるエンジニアが、この変革期に価値を発揮できると確信している。情報を追いかけることよりも、実際に手を動かして自分の開発ワークフローの中でエージェントを走らせてみることが、今できる最善の投資だ。 出典: この記事は Introducing GPT-5.2-Codex | OpenAI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

マルチエージェント開発の世界に、また一つ大きなツールが加わった。OpenAIが正式公開した「AgentKit」は、複数のAIエージェントが連携するワークフローをビジュアルに構築・デプロイできるエンタープライズ向けプラットフォームだ。コードを書かずともエージェント同士の連携を設計できる環境が整いつつある。 AgentKitとは何か AgentKitは大きく3つのコンポーネントで構成されている。 Agent Builder（ビジュアルキャンバス）では、ノードをドラッグ＆ドロップしてエージェントの役割分担と処理フローを視覚的に設計できる。従来はコードベースで記述していた複雑なオーケストレーションロジックを、直感的な操作で構築可能だ。 Connector Registryは、外部サービスや社内システムとのインテグレーションを一元管理する仕組みだ。APIコネクタのカタログを整備することで、エージェントが利用できるツール・データソースを組織全体で再利用・共有できる。 ChatKitは、構築したエージェントとのインタラクションUIをすばやく作成するためのコンポーネント群だ。フロントエンド開発の手間をかけずに、エージェントと対話するインターフェースをデプロイできる。 これらを組み合わせることで「エージェントの設計 → ツール連携 → UIデプロイ」という一連のフローが、一つのプラットフォームの中で完結する。 なぜこれが重要か ここ1〜2年で「AIエージェント」という言葉は急速に普及したが、実際に業務でマルチエージェントシステムを運用しているチームはまだ少数派だ。最大の障壁は「設計の複雑さ」にある。どのエージェントに何を担当させ、失敗したときどう回復させるかを、コードで管理するのは認知負荷が高い。 AgentKitはその入口を大幅に下げる。とりわけConnector Registryによる「コネクタの組織的共有」は、大規模チームで効いてくる。誰かが一度作ったMicrosoft Graph連携やSalesforce連携を、別のチームが再利用できる仕組みは、企業全体のエージェント開発コストを圧縮する。 日本企業では、まだ「AIチャットボット＝単発のQ&A応答」の域を出ていないケースが多い。AgentKitのような「複数エージェントの分業と協調」を前提にしたツールが普及すれば、業務自動化の粒度が大きく変わる可能性がある。 実務での活用ポイント まず小さく始める: 既存の業務フローを一つ選び、「情報収集エージェント」と「判断・要約エージェント」の2つだけでシンプルなパイプラインを組んでみる。ビジュアルキャンバスで全体像が見えるため、チームへの説明コストも下がる。 Connector Registryを組織資産として育てる: 社内システム（基幹DB、SharePointなど）との接続ロジックを登録・管理する担当を決め、コネクタを共有財産として蓄積していく。これが整うほどエージェント開発の速度が上がる。 エラー回復フローを最初から設計する: マルチエージェントシステムの落とし穴は「一部エージェントが失敗したときの処理」だ。Agent Builderで設計する段階から、失敗パスを明示的にモデリングしておくことを強く勧める。 ChatKitで関係者への見せ方を早期に固める: 経営層や業務部門への説明には動くUIが最も効果的だ。ChatKitで早期にデモ環境を作り、フィードバックを得ながら設計を進めるのが現実的なアプローチだ。 筆者の見解 エージェント開発ツールの本質的な問いは「誰がオーケストレーションを書くか」にある。これまでは開発者がコードで全ての分岐と協調ロジックを記述していた。AgentKitはそこをビジュアル化・テンプレート化することで、開発者以外の担当者も設計に参加できる環境を目指している。 方向性は正しいと思う。エージェントが真に価値を発揮するのは「単発の指示に答える」フェーズではなく、「目標を渡せば自律的にタスクを遂行し続ける」フェーズだ。そのためには、エージェントの設計・修正サイクルを速くすることが不可欠であり、ビジュアルツールはその加速装置になりうる。 ただし、注意すべき点もある。ビジュアルキャンバスは設計の見通しを良くする一方で、「裏側で何が起きているか」がブラックボックス化しやすい。エンタープライズ用途では、エージェントの判断根拠や外部サービスへのアクセスログを追跡できる仕組みが、セキュリティ・コンプライアンスの観点から必須になる。AgentKitがその部分にどう応えるかは、これから問われてくるところだ。 マルチエージェントの設計を「コードを読める人だけのもの」から「目的を持った業務担当者も関われるもの」に変えていく流れは、もう止まらない。AgentKitはその流れを加速する一手として注目していきたい。 出典: この記事は Introducing AgentKit | OpenAI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

xAI（イーロン・マスク率いるAI企業）が開発するGrok 4.20が、Microsoft Foundryのモデルカタログにサードパーティモデルとして追加された。Azureのエンタープライズ環境に手を入れることなく、同じインフラ・同じIDプラットフォーム上から直接Grokを呼び出せるようになった。 Microsoft Foundryとは何か Microsoft Foundry（旧Azure AI Foundry）は、Microsoftが提供するAIアプリケーション開発・運用の統合プラットフォームだ。OpenAIのGPTシリーズをはじめ、MetaのLlamaシリーズ、MistralAIのモデルなど、複数のサードパーティモデルをAzure上でホストし、エンタープライズグレードのセキュリティとコンプライアンスを維持しながら利用できる仕組みを提供している。 今回のGrok 4.20の追加は、このモデルカタログのラインナップがさらに充実した形だ。Azureのネットワーク境界内で完結するため、データが外部の独自エンドポイントに流れるリスクも抑えられる。 Grok 4.20の特徴 Grok 4.20はxAIが提供する大規模言語モデルで、リアルタイム情報へのアクセスとX（旧Twitter）のデータを活用する点が特徴的とされてきた。今回のFoundry統合版では、Azureのモデルカタログ経由での提供となるため、エンタープライズ向けの設定・制限が適用されたかたちでの利用が想定される。 APIインターフェースは他のFoundryモデルと統一されており、既存のAzure OpenAI SDK資産を活用しながらモデルを切り替えやすい構造になっている。 実務への影響——日本のエンジニア・IT管理者にとっての意味 ① Entra IDとの統合でIDガバナンスが一本化できる Foundry経由でGrokを利用することで、Microsoft Entra IDによるアクセス制御・条件付きアクセス・監査ログが自動的に適用される。「このモデルはどのIDが使えるか」「どのアプリケーションからのリクエストか」を統一的に管理できる点は、セキュリティ要件の厳しい日本の大手企業・金融・官公庁系SIにとって見逃せないメリットだ。 ② マルチモデル戦略が現実的な選択肢になる ひとつのユースケースに対してひとつのモデルを使い続けるのではなく、タスクの性質に応じてモデルを切り替える「マルチモデル戦略」を採る企業が増えつつある。コード生成・要約・リアルタイム情報が必要なタスクなど、特性に応じて最適なモデルを選べる環境が整いつつある。 ③ 既存のInfraとの親和性を保ちながら最新モデルにアクセスできる Azure Virtual NetworkやPrivate Linkとの組み合わせも可能で、社内システムとの連携時にも外部公開エンドポイントを経由しない設計が維持できる。セキュリティ担当者が承認しやすい構成が取れることは、実際の導入稟議を通す上で大きな差になる。 筆者の見解 Microsoft Foundryがサードパーティモデルを次々とカタログに取り込んでいくこの戦略は、Microsoftが選んだ正しい方向性だと思っている。 「Azure基盤を手放さなくても、その上で動かすモデルは選べる」——この思想は非常に現実的だ。Azureのネットワーク・IDプラットフォーム・コンプライアンス基盤はエンタープライズ向けに長年磨かれてきた資産であり、それを活かしながら各タスクに最適なモデルを選択できる仕組みは、顧客にとっても価値がある。 Microsoftが「最も賢いモデルを自社で作る競争」で全方位に勝つ必要はない。「最も多くの優れたモデルが安全に動作するプラットフォーム」としての地位を確立できれば、それはそれで強固なポジションだ。Grok 4.20の追加はその路線の着実な一歩であり、エンタープライズAI活用の文脈で実力を発揮できると見ている。 日本企業においても、特定ベンダーのモデルにロックインするのではなく、用途ごとにモデルを選びながらもガバナンスは一本化する——そういうアーキテクチャを今から設計しておくことが、変化への対応力を高める近道になるだろう。 出典: この記事は Grok 4.20 is now available in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIにも「筆跡」がある——178モデルの文体を科学的に比較した研究の衝撃 AIが生成するテキストには、人間の筆跡と同様に固有の「クセ」がある。このことは多くのエンジニアが経験的に感じていたことだが、それを定量的に可視化した研究が注目を集めている。 リサーチプロジェクト「rival.tips」が公開したデータは、178のAIモデルから3,095件の標準化された応答を収集し、各応答から32次元の文体フィンガープリント（語彙の豊富さ、文構造、句読点の習慣、フォーマットパターン、談話マーカー）を抽出したものだ。その分析結果が示すのは、AIの「個性」と「均質化」という二つの相反する現実である。 主な発見：クローンクラスターと「家風」の差 9つの「クローンクラスター」が存在する コサイン類似度90%以上という高い閾値で、9つのモデルクラスターが識別された。これは、異なるプロバイダーや製品名を持ちながら、文体的にはほぼ同じ応答を生成するモデルが複数存在することを意味する。 とくに注目すべきは Gemini 2.5 Flash Lite が Claude 3 Opus と78%類似した文体で書く という発見だ。コスト比は185倍の差があるにもかかわらず。つまり、文体レベルでは高価なフラッグシップモデルと安価なモデルの間に大きな差がない領域が存在するということになる。コスト最適化を考えるうえで無視できない知見だ。 Metaが最も強い「家風」を持つ プロバイダーごとの「ハウススタイル」（同一提供者内のモデル間の文体的一貫性）では、Metaが37.5倍の独自性比率で群を抜いている。逆に言えば、Metaのモデルは他社モデルと最も「似ていない」文章を書く。 これは興味深い。オープンソース戦略を取るMetaのモデルが文体的独自性で首位というのは、微調整（ファインチューニング）の哲学の違いが文体にまで影響していることを示唆する。 プロンプトによって「収束」か「発散」かが決まる 全モデルで最も文体が収束するプロンプトは「風刺的フェイクニュースを書け」だった。逆に最も発散するのは「文字を数えろ」という単純なタスクだ。 感情・創作系のタスクほどモデル間の違いが消え、論理・計算タスクほど差が出る——この傾向は、AIを業務に組み込む際のモデル選定に直接影響する実践的知見だ。 実務への影響：IT管理者・エンジニアが知っておくべきこと 1. コスト最適化の再設計機会 「高いモデルの方が良い」という直感は、文体という観点では必ずしも成立しない。特定のユースケース（社内文書生成、メール下書きなど）では、安価なモデルが高価なモデルと実質的に区別できないアウトプットを出せる可能性がある。今後は「タスクごとのモデル適材適所」という設計思想がより重要になる。 2. AI生成コンテンツの品質評価基準を見直す 「このモデルの文体が良い」という主観的評価がどこまで信頼できるか、改めて問われる。文体的には似通ったモデル間でも、推論精度や事実性には大きな差があり得る。文体だけでモデルを選ばず、タスク別のベンチマークと組み合わせて判断する視点が必要だ。 3. AI文章の「出どころ」特定の難易度が上がる 文体フィンガープリントを使えばAI生成文書の大まかな出所（どのモデル群か）を推定できる一方、クローンクラスターの存在はその特定を困難にする。コンプライアンス上AI利用の透明性が求められる組織では、文体に頼らないトレーサビリティの仕組みを別途用意する必要があるだろう。 4. 「風刺フェイクニュース」タスクでの均質化は何を意味するか 全モデルが最も似た文体で書くのがフェイクニュース生成タスク、という事実は、悪意あるコンテンツ生成のリスク評価においても重要な示唆を持つ。どのモデルを使っても結果が似るということは、このカテゴリでのモデル選定による差別化が難しいことを意味する。 筆者の見解 この研究が面白いのは、AIの「個性」を定量化したことで、これまで「なんとなく」語られてきた議論を数字の土台に乗せた点だ。 特に刺さったのは、コストが185倍異なるモデルが文体的には78%類似しているという発見だ。これはユーザーが「高いモデルを使っている安心感」に払っているプレミアムが、少なくとも文体という軸では正当化されない領域があることを示している。 もちろん、文体の類似 ≠ 性能の類似だ。深い推論、事実の正確さ、複雑な指示への追従——これらは文体フィンガープリントには反映されない。だからこそ、「文体が似ているから安いモデルで十分」と短絡せず、タスクの性質に応じた評価軸を組み合わせることが大切になる。 より深く考えると、この研究はAIモデルの「均質化」という潮流を示唆している。多くのモデルが同様のデータで学習され、同様のRLHF（人間フィードバックによる強化学習）プロセスを経れば、文体は収束していく。Metaの突出した独自性は、その流れへの意図的な抵抗なのか、それとも単にトレーニングデータの差なのか——興味深い問いだ。 日本のエンジニアにとっての実践的なメッセージはシンプルだ。モデルを感覚で選ぶ時代は終わりつつある。 文体、コスト、推論精度、レイテンシを組み合わせた多軸評価で最適なモデルを選ぶ能力が、これからのAI活用の競争力になる。「とりあえず一番有名なモデルを使う」という習慣から脱却するきっかけとして、この研究の視点は活かせる。 出典: この記事は Show HN: We fingerprinted 178 AI models’ writing styles and similarity clusters の内容をもとに、筆者の見解を加えて独自に執筆したものです。

気づいたときには手遅れかもしれない——BPO経由の侵入という盲点 Googleの脅威インテリジェンスグループ（GTIG）が2026年4月に公表した調査報告は、多くの企業が自覚すらしていないリスクを白日のもとにさらした。脅威アクター「UNC6783」は、企業の業務委託先（BPO）を踏み台として、本来の標的企業のZendeskサポートシステムに侵入し、大量の機密チケットデータを窃取・恐喝するという手口を繰り返している。GTIGの主任脅威アナリスト、オースティン・ラーセン氏によると、すでに数十の企業が被害を受けており、その被害範囲は複数業種に及ぶという。 この攻撃が厄介なのは、標的企業の社内ネットワークを直接狙うのではなく、「委託関係で正当なアクセス権を持つBPO」を経由する点だ。正規の業者に見えるパスを通ってくるため、従来の境界型セキュリティでは検知が極めて難しい。 攻撃の流れ——ソーシャルエンジニアリングからMFAバイパスまで ①BPOのサポート担当者を騙す UNC6783はまず、標的企業のBPOプロバイダーに対してフィッシングや生チャット経由のソーシャルエンジニアリングを仕掛ける。攻撃者は会話の流れの中でサポート担当者を偽のOktaログインページへ誘導する。このページのドメインは <組織名>.zendesk-support<番号>.com というパターンで生成され、一見すると本物の業務ポータルに見える。 ②クリップボード窃取でMFAを突破 使用されるフィッシングキットは単純なパスワード窃取にとどまらない。クリップボードの内容を盗み取ることで、担当者がMFAコードをコピー&ペーストした瞬間にそれを横取りする仕組みだ。これにより、多要素認証が設定されていても突破が可能になる。さらに攻撃者は自分のデバイスを組織に登録することで、持続的なアクセスを確立する。 ③偽セキュリティ更新でRAT配布 一部のケースでは、偽のセキュリティアップデートを配布し、リモートアクセス型トロイの木馬（RAT）を感染させる手口も確認されている。一般従業員から感染させた後、その上司や管理職を次のフィッシング標的にするという「縦横断型」の手口は、Adobeを対象とした可能性のある事案（「Mr. Raccoon」を名乗る攻撃者が1300万件のサポートチケット窃取を主張）でも確認されている。 ④恐喝——ProtonMailからの支払要求 データ窃取後は、ProtonMailアドレスを通じて被害企業に接触し、金銭を要求する。サポートチケットには個人情報・社内文書・場合によってはバグレポートまで含まれており、その情報価値は高い。 日本のIT現場への影響——「委託先のセキュリティ」は自分のセキュリティ 日本企業の多くは、コスト最適化の観点からIT系の問い合わせ対応・ヘルプデスク業務をBPOや海外拠点に委託している。この構造が今回の攻撃手法と完全に噛み合う。 特に注意すべき点を挙げる： Zendeskを使っているだけでリスクがある——Zendesk自体に脆弱性があるわけではないが、そのドメインを模倣した偽ページへの誘導が横行している。委託先の担当者がどのURLを踏むか、企業は管理しきれていない 「委託したから責任は向こう」は通用しない——個人情報が含まれるサポートチケットが漏洩した場合、規制上の責任は委託元企業に帰属する MFAを導入しているからといって安心できない——クリップボード窃取型の攻撃には、TOTP（時刻ベースワンタイムパスワード）やSMS認証では不十分。FIDO2ベースのパスキーへの移行が現実的な対策になる 具体的な防衛策 GoogleのMandiantは以下の対策を推奨している。実務ですぐ動けるものから優先したい： FIDO2セキュリティキーの導入（フィッシング耐性MFAへの移行） ライブチャットチャネルの監視強化（ソーシャルエンジニアリング検知） Zendeskパターンを模倣する疑似ドメインのDNS/プロキシブロック MFAデバイス登録の定期棚卸し（不審なデバイスの早期検知） BPO契約にセキュリティ要件を明記し、定期的に監査する 筆者の見解 この攻撃手法を見て真っ先に思うのは、「なぜゼロトラストがまだ言葉だけで終わっている企業がこんなにも多いのか」という問いだ。 ゼロトラストの本質は「誰も信じない、常に検証する」ではなく、「アクセスの文脈を常に評価し、必要な権限を必要なときだけ渡す」ことにある。今回の攻撃が機能するのは、BPOの担当者が常時広範なアクセス権を持っているからだ。Just-In-Time（JIT）アクセスが徹底されていれば、認証を奪われても攻撃者が持ち出せるデータは大幅に限定される。 日本の大手エンタープライズでよく見るのは、古い境界型セキュリティと中途半端なゼロトラスト対応が共存している状態だ。VPNは残り、Entra IDも入り、条件付きアクセスはなんとなく設定されている——でも設計の哲学が統一されていない。こういう状態が、今回のようなサプライチェーン型攻撃に対して特に無防備になる。 MFAを入れたから安全だと思っているうちは、攻撃者は常に一歩先を行く。FIDO2パスキーへの移行が「いつかやること」のリストに入ったまま何年も経過している組織は、今回の事例を契機に本気でロードマップを引き直してほしい。 サポートチケットというのは、企業の「生の悩み」が詰まっている。セキュリティ上の問題も、顧客情報も、未修正の脆弱性情報も含まれうる。そこを狙ってくる攻撃者の目線は合理的だ。私たちも同じくらい合理的に、本当に効く対策を選んでいく必要がある。 出典: この記事は Google: New UNC6783 hackers steal corporate Zendesk support tickets の内容をもとに、筆者の見解を加えて独自に執筆したものです。