Tech News JP

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2016年にリリースされた特定のWindowsバージョンが、Microsoftによる公式の延長サポート（Extended Support）対象となった。「10年前のOSが今さら」と思うかもしれないが、日本の企業IT環境においてこれは決して他人事ではない。 何が起きたのか Microsoftは、2016年リリースのWindows 10 バージョン1607（Anniversary Update）系統、特にLTSB/LTSC（Long-Term Servicing Branch/Channel）エディションに対して、公式の延長サポートプログラムを提供することを明らかにした。 LTSCは、ATMや医療機器、製造ラインの制御端末など「頻繁なアップデートができない」環境向けに設計されたエディションだ。通常のHome/Proとは異なるライフサイクルが設定されており、今回の措置はそのユーザー層への配慮といえる。 LTSCとは何か——なぜ今でも使われているのか Windowsには複数のサービスチャネルが存在する。一般家庭や通常のビジネス向けには半年〜年単位でアップデートが配信される「一般提供チャネル」があるが、LTSCは機能アップデートを受け取らず、セキュリティパッチのみを長期間受け続けることを目的としている。 このため、以下のような環境では現在もLTSC 2016が現役稼働していることがある： 産業用制御システム（ICS/SCADA）: OSを更新するたびに動作検証が必要で、簡単には切り替えられない 医療機器・検査機器に接続された端末: 薬事承認の関係で動作環境を固定している 金融・流通のキオスク端末: 安定運用最優先で機能アップデートは不要 こうした環境では「最新OSに上げたくても上げられない」という現実がある。延長サポートの追加は、そうした運用現場へのセーフティネットになる。 実務への影響——IT管理者が押さえるべきポイント 1. 延長サポートは「猶予期間」であり「ゴール」ではない 延長サポートが受けられるからといって、移行計画を後回しにしてよい理由にはならない。延長サポート期間中もセキュリティパッチは提供されるが、新機能や改善は一切入らない。ゼロデイ脆弱性の対応も、通常サポートと比較すると優先度が下がる可能性がある。「しばらく使える」ではなく、「期限を確定して計画的に移行する」という判断軸で見ることが重要だ。 2. ESU（拡張セキュリティ更新プログラム）の費用を把握する Microsoftの延長サポートプログラムは、多くの場合有償だ。台数・エディションによって費用が変わるため、該当端末数の棚卸しと費用試算を早めに行うことを推奨する。特にボリュームライセンスやMicrosoft 365 E3/E5契約との組み合わせで費用が変わるケースがある。 3. ネットワーク分離とゼロトラスト設計の見直しを 古いOSが混在する環境では、ゼロトラストアーキテクチャへの移行が一層重要になる。LTSB/LTSC端末は最新の認証プロトコルや条件付きアクセスに対応していないことも多く、「古いOSはネットワーク的に隔離する」設計が前提になる。VPN境界防御だけに頼るモデルでは、この種の端末がラテラルムーブメントの起点になるリスクがある。 筆者の見解 正直に言えば、Windowsの個別バージョンを細かく追う意義は年々薄れている。しかし今回のような「産業系・特定用途向けの延長サポート措置」は、Microsoftが現実のエンタープライズ現場と真摯に向き合っている証拠として評価したい。 Microsoftには、エンタープライズのリアルを誰よりも深く知っているという強みがある。複雑な制約を抱えた現場を見捨てず、段階的な移行を支援する姿勢は、長年ユーザーベースを支えてきた同社らしい動きだ。 一方で、日本の大手企業のIT現場では「延長サポートが出たから当面このままでいい」という判断になりやすい空気がある。それがいつしか「気づいたら完全に取り残された」状態につながる。延長サポートは出口戦略のバッファであって、出口戦略そのものではない。 今こそ「いつまでに何をどう移行するか」のロードマップを再確認するタイミングだ。Microsoftが用意した猶予期間を、ちゃんと移行への投資期間として使ってほしいと思う。 出典: この記事は A ten-year old Windows version now has official extended support from Microsoft の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIチャットツールを日常的に使っていると、誰もが一度は経験する問題がある。「あの調査、どこに書いたっけ？」「先週Geminiに聞いた内容をまた最初から説明し直す羽目になった」——そういう「デジタルの散乱」だ。Googleはこの問題に対して、すでにNotebookLMで実績を持つ「ノートブック」機能をGemini本体に統合した。 Notebooks機能とは何か GeminiのNotebooks機能は、会話・調査・生成コンテンツをプロジェクト単位でまとめて管理できる仕組みだ。従来のAIチャットは「会話履歴の羅列」に過ぎず、後から目的の内容を探すのが困難だった。ノートブックという概念を導入することで、たとえば「クラウド移行プロジェクト用」「製品調査用」「会議準備用」といった単位で情報を束ねておける。 NotebookLMはもともとGoogleが提供する「ドキュメントを読み込ませてAIと対話するツール」として登場し、情報の構造化と文脈保持を強みとしていた。その設計思想をGeminiのメインUIに持ち込んだ形だ。 なぜこれが重要か 「AIアシスタントが便利」と言われても、実際の業務で使い続けると情報管理の問題が必ず浮上する。特にナレッジワーカーやIT管理者にとって、複数プロジェクトを並行して進める場面では、文脈の切り替えコストが非常に高くなる。 このアップデートが示しているのは、AIツールの競争軸が「回答精度」から「情報管理の体験」へシフトしつつあるということだ。単発の質問に答えるだけでなく、「継続的に使えるワークスペース」としての価値が問われるフェーズに入ってきた。 日本の職場でも、AIツールの導入が「試しに使ってみる」段階から「業務の中心に組み込む」段階へ移行しつつある企業が増えている。そこで壁になるのが情報の一元管理だ。ノートブック機能のような仕組みは、その壁を一つ取り除く実用的な改善と言える。 実務での活用ポイント プロジェクト単位でノートブックを作る習慣を: 「雑多に使う」のではなく、用途を明確にしてノートブックを作ることで、過去の調査内容が資産として蓄積される。 チーム展開を見据えた評価を: 現時点では個人向けの機能だが、こうした情報整理の仕組みが法人向けに展開された場合、ナレッジ共有ツールとして業務フローに組み込めるかを念頭に置いて評価しておくと判断が速くなる。 AIの「文脈記憶」への依存は慎重に: ノートブックは便利だが、AIが前回の会話内容を「完全に記憶している」わけではない点に注意が必要だ。重要な意思決定の根拠は、別途ドキュメントとして残す運用ルールも併せて設計すること。 筆者の見解 正直に言えば、「なぜGemini本体にこれが今まで無かったのか」という疑問の方が先に来る。NotebookLMはかなり前から同種の機能を持っており、ユーザーからの支持も高かった。それをメインのGeminiに統合するまでに時間がかかったのは、Googleのプロダクト間連携の難しさを象徴しているかもしれない。 とはいえ、この方向性自体は正しい。「チャットを打ちっぱなしにしない」「文脈を蓄積して繰り返し参照できる」というのは、AIツールが真に業務効率化に貢献するために欠かせない要件だ。 AIツールを「使いこなせる人」と「使い続けられない人」の差は、情報の整理術にある。どのツールを選ぶかよりも、自分の仕事の流れにどう組み込むかを設計できるかどうかが、これからのナレッジワーカーに問われるスキルになっていく。ノートブック機能はその一歩を支援するものとして、地味だが実用的な前進だと評価している。 出典: この記事は Google Gemini gets a very useful feature NotebookLM has had for years の内容をもとに、筆者の見解を加えて独自に執筆したものです。

数ヶ月にわたるベータテストを経て、AI機能を搭載したGoogle Financeがいよいよグローバル展開を開始した。個人投資家や金融情報のリサーチに日常的に触れるビジネスパーソンにとって、情報収集のスタイルが変わる可能性がある動きだ。 Google FinanceのAI機能とは Google Financeは以前から株価・ファンド・為替情報を一覧できるサービスとして知られていたが、今回の展開ではAIによる自然言語での情報照会や、企業・市場に関するサマリー生成機能が大幅に強化されている。単なる数値の羅列から脱却し、「この銘柄が今日なぜ動いたのか」「競合他社との業績比較を要約してほしい」といった問いかけに対して、AIが文脈を踏まえた形で回答できるようになってきた。 これまで金融情報の読み解きには相応のリテラシーが要求されていた。決算資料を読む、アナリストレポートを追う、ニュースを横断的に確認する——こうした作業をAIが補助することで、専門家でなくとも一定水準の情報把握が可能になる点がポイントだ。 なぜこれが重要か 日本のビジネス現場でも、投資判断や市場調査は経営層だけでなく、事業企画・IR担当・財務部門など幅広い職種に関わるテーマだ。従来は「投資の専門家ではないから詳しく分からない」という壁があったが、AIが自然言語で要約・解説できるようになれば、その壁は急速に低くなる。 また、情報収集の効率という観点でも見逃せない。複数のニュースソースや財務データを横断的にまとめる作業は、これまで相当な時間を要していた。AIがそのアグリゲーション作業を担うことで、人間はより本質的な判断・解釈に時間を使えるようになる。 実務への影響 IR・事業企画担当者: 競合企業の業績動向や市場のセンチメントを素早くキャッチアップする用途に向いている。ただし、AIが生成した要約は必ず一次ソース（決算資料・開示情報）で確認する習慣を維持すること。AIの出力を鵜呑みにするリスクは常にある。 情報システム・IT管理者: 社内でこの種のAI金融ツールの利用が広がると、情報セキュリティポリシーとの整合性を確認する必要が出てくる。業務上の機密情報を外部AIサービスに入力しないよう、利用ガイドラインの整備が現実的な課題になってくる。 個人投資家・一般ユーザー: 無料でアクセスできるツールとしての敷居の低さは魅力だ。ただし「AIが言ったから」という理由だけで投資判断をしないことは大前提。情報補助ツールとして位置づけ、最終判断は自分で行う姿勢が不可欠だ。 筆者の見解 AIが金融情報の世界に本格的に入り込んできたことで、「情報にアクセスできること」と「情報を読み解けること」の差がかつてないほど縮まろうとしている。これ自体は歓迎すべき変化だ。 一方で、気になるのは「AIが要約してくれるなら、元の情報を読まなくていい」という発想が広がることだ。要約は要約であり、文脈の取捨選択が必ず発生する。AIが何を選んで何を落としたか——そこを問い続ける批判的思考は、ツールが便利になればなるほどむしろ重要になる。 情報追いに時間を費やすより、実際に使って自分なりの判断軸を育てる方が今の時代には合っている。Google FinanceのAI機能も、「使って自分で確かめる」ところから始めてほしい。グローバル展開によって日本のユーザーも本格的に試せる環境が整いつつあるいま、まず触れてみることが一番の近道だ。 出典: この記事は The AI-powered version of Google Finance got a major expansion の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ゲーム業界最大の話題作であるGTA VI（Grand Theft Auto VI）を開発するRockstar Gamesが、また内部データへの不正アクセスを確認した。同社は声明を発表し、ハッカーグループが内部データを入手した上で金銭を要求、応じなければデータを公開すると脅迫していることを認めた。Rockstarといえば、2022年にもGTA VI開発中の映像が大量流出するという深刻なインシデントを経験している。繰り返される侵害は、単なる不運ではなく構造的な課題を示唆している。 何が起きたか ハッカーグループはRockstar Gamesの内部システムに侵入し、機密性の高い社内データを窃取。その後、金銭的な要求を行い、「支払わなければ情報をリリースする」と脅迫した。同社は要求に応じる姿勢を示していないとされており、現時点でどの範囲のデータが取られたかの詳細は明かされていない。 ゲーム業界は近年、こうした恐喝型サイバー攻撃（ランサムウェア・データ強要型）の格好の標的になっている。Insomniac Games（Sony傘下）やCD Projekt REDも過去に同様の被害を受けており、高額のIP（知的財産）を抱えるスタジオは攻撃者にとって「高価値ターゲット」として認識されている。 なぜこれが重要か ゲーム会社の話、と他人事に見てはいけない。この事件が示す問題構造は、あらゆる業種・規模の企業に共通する。 ポイント1: 繰り返す侵害は「防御の設計」の問題 2022年に大規模漏洩を経験し、膨大なコストをかけて対応したはずのRockstarが再び侵害を受けた。これは「パッチ当てて終わり」の発想では根本解決にならないことを如実に示している。内部システムへのアクセス設計そのものを見直さない限り、同じことが繰り返される。 ポイント2: 脅迫型攻撃は「暗号化して身代金」から「盗んで恐喝」へ進化 いわゆる「二重脅迫（Double Extortion）」はすでに標準的な攻撃手法となった。バックアップがあっても無意味で、「データを公開されたくなければ払え」という構造は、防御の設計を根底から変える必要がある。 ポイント3: 高価値資産の内部管理が問われている GTA VIのソースコードや開発資料は、ゲーム業界における最高機密に類する。こうした資産が「誰でもアクセスできる内部ネットワーク」上に存在していたとすれば、特権アクセス管理（PAM）の設計が甘かったと言わざるを得ない。 実務への影響——日本のエンジニア・IT管理者が取るべき行動 1. 常時アクセス権の棚卸しをいますぐやれ 「業務上必要だから」と付与し続けた権限が、いつの間にか過剰になっているケースは非常に多い。特に特権アカウント（管理者権限）については、Just-In-Time（JIT）アクセスモデルへの移行を検討する価値がある。必要な時だけ、必要な権限だけを付与する——これが特権管理の正しいあり方だ。 2. 「脅迫型」を前提としたインシデントプランを持つ バックアップ体制だけを整えても、データ公開脅迫には対応できない。インシデント発生時の「何を公開して何を秘匿するか」「法執行機関や弁護士をいつ巻き込むか」の意思決定フローを事前に用意しておくことが重要だ。 3. ネットワークセグメンテーションと最小権限原則の徹底 侵入されることを前提に、「侵入されても被害を最小化できる構造」を目指す。ゼロトラストの考え方に基づき、内部ネットワークでも認証・認可を段階的に設ける。VPN一本で「中に入ったら信頼」という旧来モデルは、今や攻撃者にとって理想の環境だ。 4. 高価値データの分類と保護レベルの差別化 「全部同じように守る」は現実的ではない。自社にとって流出した場合のダメージが最大のデータを特定し、そこだけ特別なアクセス制御・監査ログ・アラートを設ける優先度付けが必要だ。 筆者の見解 Rockstarほどの規模と資金力を持つ企業が、2年間で繰り返し内部侵害を受けるというのは、正直に言って「もったいない」としか言いようがない。技術力も資金もある。にもかかわらず、なぜ繰り返すのか。 答えはおそらく「インシデント対応」と「セキュリティ設計の根本見直し」を混同しているからだ。漏洩が起きたあとにパッチを当て、体制を整えたように見えても、アクセス設計の思想が変わっていなければ同じ穴が残り続ける。 日本のエンタープライズでも同じ構図をしばしば見かける。昔ながらの境界防御モデルに、部分的なゼロトラスト対策を継ぎ足した結果、どちらの思想も中途半端になってしまうケースだ。「今動いているから大丈夫」という感覚は最も危険な思い込みで、攻撃者はその「動いている状態」に付け入る。 脅迫型攻撃が主流になったいま、セキュリティの投資判断は「防げるか」だけでなく「やられたときに何をどこまで守れるか」という視点で考える必要がある。被害の最小化設計——これが、次の10年のセキュリティ思想の中心になる。 出典: この記事は GTA VI developer Rockstar confirms another data breach as hackers threaten leaks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界で最も厳格なコードレビュープロセスを持つとされるLinuxカーネル開発コミュニティが、AIアシスト開発に関する公式ガイドラインを整備した。Linus Torvalds自身が承認した内容であり、AI生成コードの取り込みを認めながらも、明確な条件を設けている。オープンソースの最前線がAIとどう向き合うかの回答として、業界全体が注目している。 AI生成コード、条件付きでカーネルへの貢献が可能に 今回のガイドラインでは、AIツールを使ったコード生成や補完を開発者が活用することを認めている。ただし、条件は厳しい。 開発者は提出するすべてのコードを完全に理解し、自分の言葉で説明できなければならない。 「AIが書いたから」は一切の免責にならない。コードの動作、意図、副作用——これらを把握していない行は1行たりとも受け入れられない、というのがコミュニティの立場だ。 Linuxカーネルは数十年にわたって積み上げられた数千万行のコードで構成されており、バグ1つがシステムクラッシュや深刻なセキュリティ脆弱性につながりうる。それゆえ、コードレビューの厳密さはオープンソース界でもトップクラスだ。そのコミュニティが「AIの助けを借りていい、ただし責任は人間が持て」というルールを明文化した意味は大きい。 ガイドラインが示す3つのポイント 1. 開発者の理解が最低条件 AIが生成したコードをコピー＆ペーストしてプルリクエストを送るだけ、というアプローチは許容されない。各コードブロックがなぜその実装になっているのかを、自分で答えられるレベルの理解が求められる。 2. 品質基準に例外はない AI生成かどうかにかかわらず、既存のコーディング規約・セキュリティ要件・パフォーマンス基準をすべて満たす必要がある。「AIが出したから品質は保証済み」という論理は通用しない。 3. コントリビューター・サイン・オフの重さ Linuxカーネルの Signed-off-by: 行は、開発者がコードに対して法的・倫理的責任を取るという宣言だ。AI生成コードにもこれが求められ、その意味が変わることはない。 実務への影響——日本のエンジニアが今考えるべきこと このガイドラインは、Linuxカーネルだけの話ではない。企業の内部開発、OSSへの貢献、プロダクトコードのレビュー体制など、あらゆる場面での示唆を含んでいる。 AIアシストは「速度」であって「理解の代替」ではない。 AIがコードを生成するスピードは確かに飛躍的だが、それを導入・レビュー・保守する人間の理解が追いついていなければ、技術的負債は加速度的に積み上がる。 レビュー体制の見直しを。 「AIが書いたコード」がチームに混入するシナリオは、もはや仮定の話ではない。AIアシストを前提とした上で、レビュー観点をどこに絞るかを明確にしておく必要がある。特に、コードの動作を「説明できるか」を問うレビューは有効だ。 コントリビューションの敷居が下がる一方で、責任の所在が問われる。 OSSへの貢献を考えているエンジニアにとっては、AIを使って貢献の質を上げるチャンスが広がった。ただし、Linuxコミュニティの基準はあくまで「人間が責任を持つ」であり、これは企業内OSSポリシーを策定する際の参考基準にもなりうる。 筆者の見解 AIがコードを書けるようになったことで「誰でも開発者になれる」という期待が高まっているが、今回のLinus Torvaldsチームの判断はそれとは逆のメッセージを発している。AIを使っていい、ただし理解なき貢献は認めない。 これは正しいと思う。AIは確かに「何か動くコード」を高速で生成できる。だが、それが「正しいコード」かどうかを判断できるのは、そのドメインを深く理解した人間だけだ。ツールがいかに賢くなっても、その出力に責任を持てる人間がいなければ、品質は維持できない。 日本のエンジニアリング現場でも、同様の議論が進み始めている。AI活用の加速に比べて、「AIが出したものに誰がどう責任を持つか」という体制整備は遅れている印象がある。Linuxカーネルのガイドラインは、その問いへの実践的な回答の一つとして参照する価値がある。 「AIを使う人間の理解と責任が、ツールの能力より重要だ」——この原則は、カーネル開発だけでなく、あらゆる開発現場に適用できる。仕組みを作る側の人間に求められるレベルは、AIが進化するほど上がっていく。それを直視しているコミュニティの姿勢は、率直に清々しい。 出典: この記事は Linux kernel allows AI-assisted code, as long as you follow these rules の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコードエディタが「チームメンバー」になる日が来た AIコードエディタとして急速に存在感を高めてきたCursorが、2026年4月に「Cursor 3」を発表した。単なる機能追加ではない。開発哲学そのものが転換するアップデートだ。キーワードは「自律型エージェント」——開発者がAIに指示を出して待つ時代から、エージェントが自律的にコードを書き・修正し・テストするループを回し続ける時代への移行宣言である。 日本のIT現場でも「AIに何をやらせるか」を議論する機会が増えてきたが、Cursor 3が提示する世界観はすでにその議論を一段階超えている。 Cursor 3の技術的なポイント エージェントワークスペース：複数リポジトリを一元管理 Cursor 3の最大の変更点は、インターフェース設計の根本的な見直しだ。これまで開発者はプロジェクトごとにワークスペースを切り替え、ツールや設定を個別に管理する必要があった。新バージョンでは複数のリポジトリとワークスペースが統合された単一ビューに集約され、AIエージェントと人間の両方が複数プロジェクトを横断して作業できる。 「フラグメンテーション（断片化）の解消」という表現がCursor社のリリースに登場するが、これは開発現場でよく聞く課題——「ツールが多すぎて認知負荷が高い」——に正面から答えるものだ。 クラウドとローカルの柔軟な組み合わせ Cursor 3では、クラウド上で動作するエージェントとローカルで動作するエージェントを状況に応じて切り替えられる。たとえば、クラウド側で並列処理によって大量のコードを生成し、その結果をローカルで即座に確認・修正する、といったハイブリッドな運用が可能になった。ユーザーがオフラインになった場合もクラウド側で処理を継続できる点は、長時間タスクを抱える開発現場にとって実用的な改善だ。 独自モデル「Composer 2」はこうした分散ワークフローに最適化されているとされており、外部モデルとの組み合わせで幅広いタスクに対応する。 自然言語によるUI編集「Design Mode」 新機能の中でも注目すべきは「Design Mode」だ。開発者がUI要素を選択し、変更内容を自然言語で記述するだけで、エージェントが実装を自動的に行う。フロントエンド開発の「デザイン意図をコードに落とす」作業は従来から時間を要するボトルネックだったが、この機能が成熟すればデザイナーと開発者の境界がさらに曖昧になっていく可能性がある。 マルチモデル並列実行と差分レビューの改善 複数のAIモデルに同時にコマンドを送り、最良の出力を選択できる機能も追加された。また、コード差分のレビュー画面が刷新され、変更箇所の把握が素早くできるようになった。タスクごとにステップの概要・エラーメッセージ・ビジュアルフィードバックが表示される点も、開発者がエージェントの挙動を把握しやすくする工夫だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 個人開発者・少人数チームへの恩恵が大きい Cursor 3が目指す「複数エージェントが並行してタスクを進める」モデルは、開発リソースが限られた環境でこそ真価を発揮する。大企業よりも、数名規模のスタートアップや個人開発者がいち早く恩恵を受ける構図になりやすい。 「調整」の仕事が変わる Cursor社自身が「開発者はいまやシステムの調整に多くの時間を費やしている」と認めている通り、エージェント時代の開発者の役割は「コードを書く人」から「エージェントを設計・管理する人」にシフトする。この移行は日本でも避けられない。今のうちに「エージェントに何を任せ、どの判断を人間が担うか」を考える習慣を身につけることが重要だ。 セキュリティとコードレビューの重要性は増す エージェントが自律的にコードを生成・変更するほど、人間によるレビューの品質が問われる。「エージェントが出した結果だから大丈夫」という判断を避け、セキュリティレビューや静的解析ツールの自動組み込みを検討したい。 ライセンスと費用対効果の把握を CursorはNvidiaやGoogleなどから30億ドル超の資金調達を受けており、現時点では積極的な機能投資フェーズにある。ただし商用利用時のライセンス条件やデータ取り扱いポリシーは組織ごとに確認が必要だ。特にソースコードをクラウド上のエージェントに渡す際の情報セキュリティポリシーについては、事前にIT部門と合意しておくことを勧める。 筆者の見解 Cursor 3が体現しているのは、私がここ最近ずっと重要だと言い続けてきた考え方——「AIに何をやらせるか」の段階はすでに終わっており、次は「AIに何を託し、自分はどの抽象度で意志を介在させるか」が問われる——とほぼ一致している。 自律型エージェントが自分で判断し・実行し・検証するループを設計すること、これこそが開発者として今最もリターンの大きい投資だと確信している。Cursor 3はそのビジョンを製品として具体化した一例だ。 一方で、「エージェントが自律的に動く」ことと「開発者が関与しなくてよい」ことは別の話だ。むしろ、エージェントを正しく設計・監視・修正できる人間の価値はこれから急激に上がる。コードを書く技術よりも、「どんなループを回すか」を設計する思考力が差をつける時代になっていく。 日本のIT現場では、まだ「AIはペアプログラミングのアシスタント」という認識が多数派だと感じる。Cursor 3のようなアップデートが示す方向性——目標を渡せば自律的に動く、確認を求め続けない設計——を理解しているかどうかで、これからの2〜3年の差は相当大きくなるだろう。情報を追うより、実際に自分でエージェントを動かして感覚をつかむことを優先してほしい。 出典: この記事は Cursor updates its platform with a focus on autonomous AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。