Tech News JP

「AIエージェント」という言葉があふれる昨今、実際に明日から使えるプロダクションレディなエージェントはどれだけあるだろうか。Dynatraceは4月3日、開発者・SRE・IT運用チーム向けの「Ready-made AI Agents（既製AIエージェント）」を正式リリースした。概念実証（PoC）でも限定プレビューでもなく、既存のDynatraceワークフローに統合済みで、今日から実稼働環境で動かせる状態での提供だ。 「汎用AI」ではなく「タスク特化オペレーショナルエージェント」 Dynatraceの既製エージェントが興味深いのは、その設計思想にある。多くのAI製品が「何でも聞いてください」という汎用アシスタントモデルをとる中、Dynatraceは各エージェントに明確な役割を与えている。 各エージェントは事前に以下を把握している： どういう入力を期待するか どのDynatraceシグナルとコンテキストを使うべきか 問題の種類に応じてどのような出力が最も有用か たとえばKubernetes Troubleshooting Agentは、障害発生時に9本の並列クエリを実行してデータを収集し、構造化された診断レポートを生成する。プロンプトを自分で設計する必要はなく、Dynatrace Intelligenceがすべての情報を統合して結論を出す。プロンプトエンジニアリングの負荷をシステム側が吸収している点が重要だ。 ワークフロー統合とMCPサーバーの二本柱 エージェントの呼び出し方は2通り用意されている。 Dynatrace Workflows経由では、イベントやスケジュールをトリガーにエージェントが自律的に動作する。問題が発生したら自動で調査→修復提案→人間承認ステップ（必要な場合）→自動修復という一連のフローを組める。既製のアジェンティック・ワークフローテンプレートもプレビューで提供中で、ゼロから設計する必要はない。 Dynatrace MCPサーバー経由では、追加インフラ不要でMCP対応クライアントからDynatraceのデータを自然言語で照会できる。Grail®データストアへのクエリ、システムヘルスチェック、問題分析と修復推奨をDynatrace外の環境から直接呼び出せる。IDEやチャットツールとの統合が数分で完了するのは現場にとって大きい。 実務への影響——日本のSRE・DevOpsチームにとっての意味 日本の現場でDynatraceを利用しているチームにとって、今回のリリースは「ツールを覚える」段階から「エージェントに任せる」段階への移行を後押しする。 即効性のある活用ポイント： 障害対応の初動自動化: Kubernetes環境の障害検知→Troubleshooting Agent起動→Slackへの診断サマリー送信を自動化できる。深夜障害でエンジニアが即時対応しなければならないシーンを大幅に減らせる オンコールの負荷軽減: ワークフローで「まずエージェントに調べさせる」フローを入れることで、アラート疲れを軽減。人間が判断する前に情報が整理された状態で届く MCPサーバーを既存ツールと繋ぐ: MCP対応の開発環境からDynatraceのデータをナチュラルランゲージで照会できるため、IDE上での作業コンテキストが統一される 段階的な導入パスとして、まずアジェンティック・ワークフローテンプレートを試用し、自環境に合わせてカスタマイズするアプローチが現実的だ。Kubernetesの障害対応から始めて、徐々に自動修復まで範囲を広げていく流れが自然だろう。 筆者の見解 AIエージェントを語る上で今最も重要なテーマのひとつが「ハーネスループ」——エージェントが自律的に判断・実行・検証を繰り返すループの設計だ。今回のDynatraceのリリースはまさにその方向性を体現している。 単発の「質問→回答」ではなく、イベントを起点にエージェントが自律的にデータ収集・分析・アクション提案・実行を行うループ。これが「副操縦士型」から「自律エージェント型」への本質的な移行だ。確認・承認を人間に求め続ける設計では、認知負荷の削減という本来の価値を得られない。エージェントが自分でループを回してこそ、人間はより重要な判断に集中できる。 特に評価したいのは「Day Oneから実稼働可能」という宣言を実際に製品で体現している点だ。「コンセプトではなく実稼働」という言葉は業界でよく使われるが、既存ワークフローへの統合・既製テンプレート・MCP経由の即時接続という三点セットで「初日から使える」を具体化している。 Kubernetes環境の運用は複雑さが増す一方で、障害時のコンテキスト収集だけで多くの認知リソースが消費される。エージェントがその「コンテキスト収集と初期診断」を自律的に処理してくれれば、人間は「判断と意思決定」に集中できる。これが本来あるべきAIとの分業だ。 日本のSRE・DevOpsチームの多くはまだAIエージェントを「使ってみたい技術」として捉えている段階かもしれない。ただ、今回のようにプロダクションレディな形でエコシステムに統合されてくると、「使わない選択」のコストが確実に上がっていく。情報を追い続けるよりも、まず一つのエージェントをプロダクション環境で動かしてみる——その実体験を積むことが今最も価値ある投資になるだろう。 出典: この記事は Dynatrace AI agents begin working for you on day one, and are built to grow with you の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windowsの「アクセシビリティ機能」という一見地味な領域から、重大な特権昇格脆弱性「RegPwn」（CVE-2026-24291）が発見された。MDSecのリサーチャーが2025年1月にはすでにレッドチーム演習で実用していた攻撃手法であり、2026年3月のPatch Tuesdayで修正済みながら、GitHubにPoCコードが公開された状態にある。パッチ適用を急ぐとともに、この脆弱性が示す構造的問題を把握しておきたい。 脆弱性の全貌：アクセシビリティとSYSTEM権限の危険な交差点 ナレーター（Narrator）やスクリーンキーボード（On-Screen Keyboard）といったWindowsのアクセシビリティツールは、ユーザーセッション内で動作しながらも高い整合性レベルの権限を必要とする。そのため、Windowsはこれらの設定データをレジストリの特定キーに格納し、ログオン処理においてそのキーへの書き込み権限をユーザーに一時的に付与する設計になっている。利便性のための設計だが、後続の処理との組み合わせが深刻なリスクを生む。 Secure DesktopとATBrokerの役割 攻撃のトリガーとなるのは「セキュアデスクトップ（Secure Desktop）」への切り替えだ。ワークステーションのロックやUACプロンプト表示時に発動するこの分離環境では、atbroker.exeというプロセスが2つ起動する。一方はユーザーコンテキスト、もう一方はSYSTEMアカウントで実行され、後者がユーザー書き込み可能なレジストリパスから設定データを読み取り、保護されたSYSTEMレジストリキーへコピーする。ここに攻撃の本質がある。 レジストリシンボリックリンクによるデータ横取り 攻撃者はユーザー書き込み可能なレジストリキーにシンボリックリンクを仕掛ける。SYSTEMプロセスがデータをコピーしようとした際、そのリンクを経由して攻撃者が制御するデータが任意のレジストリ位置に書き込まれる。たとえばWindows InstallerサービスのImagePathを書き換えることで、SYSTEM権限での任意コード実行が可能になる。 Opportunistic Lock（OpLock）でタイミング問題を克服 攻撃成功にはミリ秒単位の精度が必要だが、MDSecのリサーチャーはアクセシビリティ関連のXMLファイルへのOpLockを活用することで解決した。OpLockにより正規のシステム処理を遅延させ、シンボリックリンクを配置する時間的余裕を確保。競合状態（レースコンディション）の信頼性が大幅に向上し、実用的な攻撃手法として成立している。 実務への影響 今すぐ対応すべきこと 3月のPatch Tuesdayの適用が最優先だ。対象はWindows 10・11およびWindows Serverの全バージョン。GitHubにはPoCコードが公開されており、パッチ適用前に被害を受けた可能性も念頭に以下を確認してほしい。 レジストリの不審な変更を監視する: 特にサービスのImagePathキー周辺 atbroker.exeの異常な起動を検出する: Secure Desktop切り替えのタイミングへの着目 インシデントレスポンスの視点: 「パッチが出た＝修正済み」ではなく「侵害されていなかったか」の確認も 多層防御の観点で考える この脆弱性の本質は「設計の意図（利便性のための書き込み権限付与）」と「セキュリティ要件（SYSTEM昇格の防止）」の衝突だ。パッチ適用は大前提として、さらにエンドポイント特権管理（EPM）を活用したローカル管理者権限の最小化を進めることで、類似の脆弱性による影響範囲を縮小できる。「低権限ユーザーとして侵入されても次のステップを封じる」という考え方——これがゼロトラスト設計の核心だ。 筆者の見解 RegPwnは「ニッチな機能の穴」では決してない。アクセシビリティという広く有効化された機能と、ログオン処理というセキュリティ境界が交差する地点に脆弱性が潜んでいた。こうした設計上の矛盾が長年表面化しなかった背景には「動いているから大丈夫」という慣性があったのではないかと思う。 MDSecが2025年1月から実際の演習で使い続けていたという事実は重い。現実の攻撃者が同様の手法を独自開発・利用していた可能性は十分にある。「修正された＝終わり」ではなく、修正までの1年以上の空白期間を振り返るインシデントレスポンスの視点も持ってほしい。 Windowsのセキュリティ改善——Smart App ControlやカーネルドライバーのEVコード署名要件など——の方向性は間違っていない。だからこそ、こういった設計の古傷が残っているのはもったいない。アクセシビリティとセキュリティは本来トレードオフではないはずだし、その両立を実現する技術力はMicrosoftに十分ある。修正が着実に出てくることへの期待とともに、引き続き注目していく。 出典: この記事は Critical ‘RegPwn’ Vulnerability Lets Attackers Gain SYSTEM Access on Windows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

サウジアラビアのクラウド本番化が2026年後半に動き出す Microsoftはサウジアラビアの東部州（Eastern Province）に開設予定の新Azureリージョン「Saudi Arabia East」が、2026年第4四半期（Q4）より商用利用可能になると正式に確認した。発表はMicrosoft副会長兼プレジデントのBrad SmithがLinkedIn上で行ったもので、単なる予告にとどまらず、政府機関・企業向けのミッションクリティカルワークロードを念頭に置いた「本番稼働フェーズへの移行」を明確に宣言した内容だ。 リージョンの構成と技術的特徴 3つの可用性ゾーンで高可用性を確保 新リージョンは、それぞれ独立した電源・冷却・ネットワークインフラを持つ3つの可用性ゾーン（Availability Zones）で構成される。これはAzureの標準的なリージョン設計に則ったものであり、単一障害点を排除した99.99%以上の可用性を実現する構成だ。 公共部門・民間部門を問わず、クラウドおよびAIワークロードをサウジアラビア国内で実行できるようになり、主に以下の要件を満たせるようになる： 低レイテンシ: データが国外を経由しないため、応答速度が向上 データレジデンシー: 国内法規制への準拠（データを国境外に出さない要件） 高可用性: マルチゾーン構成による耐障害性 Vision 2030との連動 サウジアラビア政府が掲げる国家変革計画「Vision 2030」は、石油依存からの脱却と知識経済・デジタル経済への転換を目指す大規模な取り組みだ。エネルギー企業のAcwaやエンターテインメント開発のQiddiyaなど、Vision 2030の中核を担う組織がすでにAzure上での実証実験（PoC）から本番環境への移行を進めているという。 サウジアラビア情報通信技術大臣のAbdullah Al-Swaha氏は「AI対応国家への変革を支える信頼性の高いインフラ整備における重要なマイルストーン」と評価しており、政府レベルでの期待値の高さがうかがえる。 ソブリンクラウドへの布石 注目すべきは、Microsoftがサウジアラビア政府系ファンド（PIF：Public Investment Fund）やSiteとともにソブリンクラウドサービスの提供を探索する意向を示した点だ。ソブリンクラウドとは、特定国家の法制度・規制・セキュリティ基準に完全準拠した形で提供されるクラウド環境を指し、政府機関や安全保障関連の機密データを扱う組織にとっては不可欠な要件となっている。 日本のエンジニア・IT管理者にとっての意味 「なぜこれが重要か」——地政学的なクラウド分散が加速する この発表は単にサウジアラビア国内の話ではない。世界各国がデータ主権（Data Sovereignty）を強く意識し、クラウドのリージョン配置を政治・規制上の要件として扱い始めたという大きな潮流の表れだ。 日本でも医療・金融・行政データの取り扱いに関する規制は年々厳格化しており、「クラウドを使うこと」から「どのリージョンで使うか」「どの認証を取得したクラウドで使うか」という議論に移りつつある。Azureが中東でソブリン対応を進める姿勢は、日本の規制対応クラウド要件を議論するうえでも参考になる事例だ。 「実務での活用ポイント」——中東ビジネスに関わるなら今から準備を 中東・アフリカ地域でビジネスを展開する、または展開を検討している日本企業にとっては直接的なインパクトがある。以下の点を今から確認しておくと良い： Azure Well-Architected Frameworkの可用性ゾーン設計を見直す: 新リージョン開設に合わせてアーキテクチャを設計する場合、3ゾーン前提の冗長構成を初期から採り入れる データレジデンシー要件の文書化: サウジ当局はデータのローカル保存を求めるケースがある。契約・コンプライアンス担当と連携して要件を早期に固める Azureの価格・SLAをQ4 2026に向けて確認: 新リージョンは開設直後に既存リージョンと同等の料金体系になるとは限らない。コスト試算は最新情報をもとに行う AI系サービスの展開計画を前倒し: Azure AI ServicesやAzure OpenAI Serviceが新リージョンで使えるようになるタイミングは段階的な場合がある。ロードマップを定期的に確認する 筆者の見解 Microsoftのこの動きを見ていると、「最も賢いAIを作る競争」と「最もAIが安全に動くプラットフォームを提供する競争」を分けて考える必要を改めて感じる。 前者の競争では正直なところ、まだ実力差が埋まっていないと感じることもある。しかし後者——つまりグローバルな規制環境・データ主権・政府要件を満たしたうえでAIインフラを安定提供する競争では、MicrosoftとAzureはほぼ他の追随を許さないポジションにいる。 サウジアラビアでのソブリンクラウド展開、Brad Smithが前面に出て語るガバナンスとコンプライアンスのメッセージ、そして政府系ファンドとの協議——これらは一朝一夕で真似できないものだ。Microsoftが長年かけて積み上げてきた「信頼される企業」としての資産が、AIの商用化フェーズで効いてきていると言えるだろう。 日本のIT現場でも「クラウドを使う」という話は終わり、「どのクラウドで・どの地域で・どの規制準拠レベルで使うか」を設計する段階に移行しつつある。その問いに対して、Azureはかなり具体的な答えを持っている。プラットフォームとしての信頼性を軸にした戦略が、長期的に正しい方向を向いていると筆者は評価している。 その上でAIの選択肢を広げていく——Microsoft Foundry経由で最良のモデルを活用するというアプローチが、現実的な企業戦略として機能し始める環境が整いつつある。Azureの地理的拡大はその土台を着実に広げる動きとして、素直に評価したい。 出典: この記事は Microsoft Confirms Saudi Arabia East Azure Region for Q4 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIエージェントが企業インフラに深く組み込まれるほど、そのセキュリティの穴は命取りになる。2026年4月3日、MicrosoftはAzure MCPサーバー（npmパッケージ @azure-devops/mcp）に重大な脆弱性CVE-2026-32211を開示した。CVSSスコアは9.1。「認証機構が丸ごと存在しない」という、ある意味シンプルすぎる脆弱性だ。 何が起きているのか このパッケージはAIエージェントがAzure DevOpsを操作するためのMCPサーバーだ。ワークアイテムの読み書き、リポジトリ操作、パイプライン実行、プルリクエスト管理など、開発インフラの中枢に触れるツール群が揃っている。 問題の核心は単純だ。認証機構がない。攻撃者は有効な認証情報なしで、このサーバーが保持する設定情報・APIキー・認証トークン・プロジェクトデータにアクセスできる可能性がある。「サブトルなバグ」ではなく、エンタープライズの開発インフラを扱うサーバーに認証レイヤーそのものが欠けているという話だ。 現時点でパッチは未提供。Microsoftはミティゲーションガイダンスを公開しているが、修正プログラムのリリースは待機中となっている。 MCPエコシステムの構造的問題 この脆弱性は孤立した事象ではない。MCP（Model Context Protocol）の仕様自体が認証を「オプション」としていることが根本にある。公式ドキュメントには「MCP SDKには組み込みの認証機構が含まれていない」と明記されており、各MCPサーバーの実装者に責任が委ねられている。 OWASP MCP Top 10ドラフトでも「不十分な認証と認可」（MCP07）をトップリスクの一つとして挙げており、今回のCVEはその懸念が現実になったケースだ。 さらに懸念されるのがサプライチェーンリスクだ。このパッケージにはインストール時に実行される preinstall スクリプトがあり、npm config set registry https://registry.npmjs.org/ を実行してレジストリ設定を上書きする。これ自体は悪意ある動作ではないが、カスタムレジストリを使用している組織ではリスクになりうる。加えて、パッケージはGitHub Actionsによるトラステッドパブリッシングではなく個人アカウントから公開されており、ソースコードから成果物への検証可能なチェーン（プロバナンス）が存在しない。 実務への対応 現在このパッケージを使用している場合、パッチがリリースされるまでの間に以下の対応を講じてほしい。 即時対応 MCPサーバーエンドポイントへのネットワークアクセスをファイアウォールルールで制限する サーバーの前段に認証機能を持つリバースプロキシを配置する アクセスログを確認し、不審なリクエストがなかったかレビューする Microsoftのセキュリティ更新ガイドを継続的に監視し、公式パッチが出次第即座に適用する MCPサーバー全般への点検 使用しているすべてのMCPサーバーで認証が実装されているか確認する 各MCPサーバーが公開しているツールの権限スコープが最小限になっているか見直す パッケージのバージョン変更・依存関係追加・設定変更を継続監視する体制を整える 筆者の見解 正直に言えば、セキュリティはあまり得意な分野ではない。ただ技術的な観点で見ると、今回のCVEは非常に示唆に富んでいる。 MCPという新興エコシステムが急速に広がる中、「とりあえず動く」が優先されて「ちゃんと守る」が後回しになる構図は予測できた範囲ではある。とはいえ、エンタープライズの開発インフラに触れるサーバーで認証が丸ごと欠落していたというのは、さすがに看過できない。 ゼロトラストの観点から言えば、MCPサーバーへのアクセスはデフォルトで信頼しないことが正しい出発点だ。ネットワーク層・認証層・認可層の3層でコントロールを持つのが理想であり、そのうち一層でも欠けていれば残りの層で補うしかない。今回のケースで言えば、認証層がないなら少なくともネットワーク層の制限と認可層での最小権限付与で守るほかない。 Microsoftには、MCPサーバーのセキュリティ要件をもっと前面に出してほしかった。Azure DevOpsというエンタープライズの中枢に接続するツールを、認証がオプション扱いのプロトコルに乗せてリリースするのは、正直もったいない判断だと思う。これだけの技術力とエコシステムを持っているのだから、模範的な実装でMCPコミュニティ全体のセキュリティ水準を引き上げるポジションに立てるはずだ。そういう意味では、今後の対応に期待している。 AIエージェントの本格活用が始まった今、セキュリティの後付けは許されなくなる。このCVEを「他人事」として見るのではなく、自社のエージェントインフラ全体を点検する契機として活用してほしい。 出典: この記事は CVE-2026-32211: What the Azure MCP Server Flaw Means for Your Agent Security の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilotが2026年3月9日に発表した「Wave 3」は、Copilot史上最大規模のアップデートだ。単なる機能追加ではなく、AIが人間の代わりに業務フロー全体を自律的に実行する「デジタル労働力」への転換を宣言する内容である。日本の企業IT担当者にとっても、今すぐ評価と準備に着手すべき変化が詰まっている。 Wave 3の4本柱を整理する Wave 3の核心は以下の4つだ。 Copilot Cowork ── 自律型マルチステップ実行 Coworkは、ユーザーが指示を出したあとにCopilotがバックグラウンドで複数ステップの業務を自律的に進める機能だ。メール・ドキュメント・Teams・カレンダーにまたがる複合タスクを、人間が画面に張り付かなくても完遂する。プロジェクト報告書の下書き作成から関係者への送付スケジュール設定まで、従来は人間が1ステップずつ手動でつないでいた作業が一括委任できるようになる。 Agent 365 ── エージェント管理・ガバナンス基盤 Agent 365は、企業内で動くAIエージェントを一元的に管理・監視・制御するコントロールプレーンだ。どのエージェントが何のデータにアクセスできるか、どのワークフローを実行しているかをIT管理者が可視化・制御できる。Copilotエージェントが組織内に増えるにつれ、このガバナンス基盤の重要性は増す一方だ。 Model Choice ── マルチモデル対応 Wave 3では複数のAIモデルをCopilot基盤上で利用できるようになる。タスクの性質に応じてモデルが自動選択される仕組みで、IT管理者がモデルを意識せずに済む設計になっている。Microsoft 365のデータ保護ポリシーのもとで動作するため、セキュリティ面の責任境界は引き続きMicrosoftが担保する。 Microsoft 365 E7 ── $99/user/monthの新ライセンス E5＋Copilot＋Agent 365をまとめたフロンティアスイートとして「E7」が登場する。個別に積み上げるより割安になる設計で、企業が一括で最上位機能を導入しやすくなる。 展開ロードマップ：2026年前半に集中 今〜4月：現行環境のアセスメント。どの業務フローがCoworkの対象になるか整理 4〜5月：ガバナンスポリシー策定。Agent 365の管理ルール設計 5〜6月：パイロット展開。限定部門でCoworkとAgent 365を試験稼働 7月以降：全社スケールアウト 実務への影響：日本のIT管理者が今すぐやるべきこと 1. データ分類ポリシーの見直しが最優先 Coworkが自律的に動くということは、AIが自社データに能動的にアクセスしながら業務を進めることを意味する。現行のMicrosoft Purviewのデータ分類・ラベリングが不十分な組織では、意図しない範囲のデータがエージェントに渡るリスクがある。Wave 3導入前に、情報保護ラベルの適用状況を棚卸しすることを強くすすめる。 2. Agent 365の管理者ロール設計 「誰がどのエージェントを作れるか」「エージェントがアクセスできるサービスはどこまでか」を設計しないまま展開すると、シャドーITならぬ「シャドーエージェント」が組織内に増殖する。管理者ポリシーは展開前に確定させること。 3. E7ライセンスの費用対効果を試算する E3またはE5＋Copilot Add-onの現行構成からE7への移行コストを試算するタイミングだ。特にCopilotとAgent 365の両方を使う予定があるなら、E7の方がトータルコストで有利になる可能性が高い。Microsoft担当営業に今から試算を依頼しておくと良い。 4. エンドユーザートレーニングの再設計 「アシスタントとして使う」から「エージェントに委任する」へのUXは別物だ。何をどこまで任せていいかの判断基準、結果の確認フロー、承認が必要なタスクの分類など、現場ユーザーへの教育内容をゼロから組み直す必要がある。 筆者の見解 Wave 3を一言で表すなら「Copilotが本気を出してきた」という印象だ。Coworkもマルチモデル対応も、エンタープライズ向けに真面目に設計された機能だと感じる。E7のバンドル戦略も、統合プラットフォームとして全体最適を狙うMicrosoftらしいアプローチだ。 ただし、正直に言う。「今度こそ本物か」という問いに確信を持って答えるには、まだ実動環境での検証が必要だ。発表内容は申し分ない。しかし日本の現場で実際に使えるレベルになるまでのギャップ──日本語精度・コンプライアンス対応・ローカライズの遅れ──を何度か経験してきた身としては、慎重に見極める姿勢を崩せない。 一方で、ガバナンス基盤（Agent 365）を最初からセットで出してきた点は評価したい。エージェントAIが普及する上で最大の障壁は「どこまで信頼して任せていいか分からない」という組織側の不安だ。管理・可視化の仕組みを最初から提供するのは、正しい順序だと思う。 Wave 3は、CopilotをPoC止まりにしていた組織が「本格導入」に踏み出す契機になり得る。ただしその前に、データ分類とガバナンス設計という地味だが重要な土台固めを怠らないことが前提条件だ。Microsoftにはこのまま、エンタープライズとして信頼できるAIプラットフォームの道を歩み続けてほしいと思っている。 出典: この記事は Microsoft 365 Copilot Wave 3: The Complete Enterprise Guide for 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 Copilotを導入している企業にとって、長らく課題だった「Copilotがどこから情報を拾っているか分からない」問題に、ついてMicrosoftが本格的なメスを入れる。SharePointに「AI Citation Analytics（AI引用アナリティクス）」と「Authoritative Sources（権威コンテンツ指定）」という2つの新機能が4月よりロールアウトされる。 AI引用アナリティクス：Copilotが「何を引用したか」がわかる AI Citation Analyticsは、SharePoint上のコンテンツがCopilotによってどの程度引用されているかを可視化する機能だ。SharePoint管理センターから確認できるようになると見られており、「このドキュメントはCopilotの回答に何回使われたか」「このサイトのどのページがよく参照されているか」といったデータが得られる。 これは単純な閲覧数やダウンロード数とは根本的に異なる指標だ。Copilotに「参照された」ということは、その文書が社内の問い合わせに実際に答える情報として機能しているという証拠になる。コンテンツ品質の評価軸が「人が読んだ回数」から「AIが回答に使った回数」へと拡張されることで、情報管理の考え方そのものが変わってくる。 Authoritative Sources：信頼できる情報源を管理者が指定する 「Authoritative Sources」は、SharePoint Onlineの特定サイトをCopilot検索における権威ある情報源として管理者が明示的に指定できる機能だ。ウェブ検索エンジンにおける「信頼性の高いサイトを優先表示する」ロジックを、社内ナレッジ管理に持ち込んだイメージに近い。 指定されたサイトのコンテンツは、Copilotの検索・回答生成において優先的に参照される。例えば、人事部が管理する就業規則のサイト、情報システム部門のセキュリティポリシー集、プロジェクト管理部門の標準手順書などを「権威ある情報源」として指定することで、Copilotの回答の根拠がコントロールしやすくなる。 実務への影響 SharePointのコンテンツ整備が「Copilot品質の投資」になる これまで「SharePointの整備は手間がかかる割に使われない」という声は多かった。しかし、AI引用アナリティクスで「どのコンテンツが実際にCopilotに使われているか」が見えるようになると、整備の優先順位付けが論理的にできるようになる。引用されている文書を最新化することは、そのままCopilotの回答精度向上に直結する。SharePoint管理が「お作法」から「AI品質への投資」へと位置づけが変わる転換点になり得る。 誤情報・古い情報を引用させない「ネガティブコントロール」の重要性 Authoritative Sourcesで「良いコンテンツを優先する」一方で、古い情報や廃止されたポリシー文書が引き続きCopilotに引用されるリスクも存在する。権威ある情報源を指定するだけでなく、「引用させたくないコンテンツ」をどう管理するか—削除・アーカイブ・アクセス制限—の運用ポリシーも同時に整備することが重要だ。 情報ガバナンス担当者のロールが変わる 「SharePoint管理者」という職種の役割が、単なるサイト管理・権限設定からAIの「回答品質管理」へと広がりつつある。特に法務・コンプライアンス関連の文書は、Copilotに誤った根拠として引用されるリスクが高い。Authoritative Sourcesと組み合わせた情報ガバナンスの再設計を、今から検討しておくことを強くすすめる。 筆者の見解 この機能は、Copilotの実用性という観点で評価できる、まっとうな方向性だと思っている。Copilotをせっかく導入しても「どこから引っ張ってきたか分からない回答」が返ってくる状況では、現場の信頼が得られない。管理者がコンテンツの質と引用状況を把握できるようになることは、「管理できるシステムとしてのCopilot」という方向性の第一歩だ。 ただ、正直に言えばもったいないという気持ちが拭えない。この機能自体は正しいが、「なぜ今なのか」という問いが残る。Copilot for Microsoft 365が登場してから長い時間が経っているにもかかわらず、こうした基本的なコンテンツガバナンス機能が今ようやく実装されてきている。実務で導入を推進してきたIT管理者が、どれだけ「どのコンテンツが使われているか分からない」という不安と戦ってきたか。Microsoftにはその経験値を受け止めた上で、さらに踏み込んだ管理機能を早期に届けてほしい。 SharePointという資産を持つ企業にとって、この機能は活用する価値が十分ある。内部ナレッジの整備に力を入れてきた組織ほど、Copilotの回答品質向上という形でリターンが返ってくる仕組みが整いつつある。社内コンテンツを真剣にマネジメントしている担当者は、まずAuthoritative Sourcesで「信頼できるサイト」を洗い出すところから始めるのが現実的な一手だ。 出典: この記事は SharePoint AI Citation Analytics and Authoritative Sources for Copilot Search の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「生存のためのAI」という新しい文脈 日本でロボット・自律AIの話をすると、「仕事を奪われる」という懸念が必ず浮かび上がる。だが現場の実態は真逆だ。今、日本に広がりつつあるフィジカルAI（物理空間で動く自律型ロボットシステム）が向かっているのは、人手不足で「誰もいない」ポジション——工場の夜間ライン、物流センターの仕分け作業、インフラ点検の現場だ。 2026年3月、経済産業省はフィジカルAI国内産業の育成方針を発表し、2040年までにグローバル市場の30%シェア獲得を目標に掲げた。単なる政策スローガンではない。現時点で日本の産業用ロボットメーカーは世界シェアの約70%を握っており、そのハードウェア基盤の上にAIソフトウェアを乗せて競争力を底上げする、という戦略には相当のリアリティがある。 なぜ今、フィジカルAIなのか 人口動態という「構造的な崩壊」 日本の生産年齢人口（15〜64歳）は現在、総人口の59.6%にとどまり、今後20年でさらに約1,500万人が失われる見込みだ。2024年も14年連続で総人口が減少した。ロイター・日経の調査では、AI導入の最大の動機として「人手不足」を挙げた企業が最多を占めた。 グローバルブレインのパートナーは「フィジカルAIは今や効率化の道具ではなく、工場・物流・インフラ・サービスを人手なしで動かし続けるための『継続性ツール』として買われている」と表現する。Salesforce Venturesの担当者は「ドライバーは単純な効率向上から産業の生き残りへとシフトした」と述べている。 ハードの強みをソフトで活かす 日本が長年培ってきたのはアクチュエーター、センサー、制御システムといった「ロボットの筋肉と神経」に相当するハードウェアだ。ここに自律制御ソフトウェアを掛け合わせることで、既存設備をAI化するアプローチが現実的になっている。 日本企業のMujinは、産業ロボットがピッキングや物流作業を自律的にこなせるようにするロボティクス制御プラットフォームを開発している。既存のハードウェアをそのまま活かしながらソフトウェアで自律化するというアーキテクチャは、設備投資を抑えながら高度化を進めたい製造業にとって現実的な選択肢だ。 実務への影響——IT・製造業の現場で何が変わるか 1. 「PoC疲れ」を終わらせるフェーズへ 日本企業のAI導入はPoC（概念実証）止まりになりがちだったが、人手不足という切実な業務圧力が導入を後押しし始めている。IT部門としては「自律化に伴うシステム統合」——生産管理、在庫管理、ERP連携——の要件が一気に増えることを想定しておきたい。 2. ロボット×クラウドの組み合わせが標準に フィジカルAIは単体で動くのではなく、クラウドの推論基盤と常時接続して動く設計が主流になりつつある。Azure IoT HubやAzure AI Servicesを使ったロボット管理基盤の構築事例は今後急増するだろう。ここはエンジニアとして早めに知見を積んでおく価値がある領域だ。 3. 「禁止」ではなく「設計」で乗り越える 労働組合や現場からの「導入反対」が生じたとき、説明のキーワードは「仕事の代替」ではなく「人が集まらないポジションを埋める」という文脈だ。現場の声を無視した押し付け導入は必ず失敗する。ステークホルダーを巻き込んだ設計が、長期的な稼働率に直結する。 筆者の見解 フィジカルAIの日本での広がりを見ていると、「必要は発明の母」という言葉を改めて実感する。圧倒的な人口減少という制約が、かえって日本を世界最前線の実証フィールドに変えつつある。 AIエージェントの文脈で私がずっと言い続けてきたことがある——「自律的に判断・実行・検証を繰り返すループを設計することが本質だ」と。工場やウェアハウスで今起きているのも、まさにその概念の物理空間版だ。ピッキングロボットが状況を認識し、次の行動を決め、実行して結果を確認し、また次の判断へと進む。このループを24時間止めずに回し続けることが価値の源泉になっている。 気になるのは、日本のIT業界全体がこの変化のスケールを本当に理解しているかどうかだ。製造業や物流の現場では確実に変化が始まっているのに、その変化に対応できるシステム設計ができるエンジニアが圧倒的に足りていない。フィジカルAIを「現場のロボット屋さんの話」として距離を置くのではなく、クラウド連携・データ基盤・セキュリティ設計も含めたトータルなシステム問題として捉え直す必要がある。 2040年に30%のグローバルシェアという目標が現実になるかどうかは、ハードの強みをソフトとシステムで繋げられるかにかかっている。日本にはその素地がある。あとは「仕組みを作れる人」が増えるかどうかだ。 出典: この記事は In Japan, the robot isn’t coming for your job; it’s filling the one nobody wants の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがCopilotを法人顧客に積極展開する中、同製品の利用規約に「Copilot is for entertainment purposes only（Copilotは娯楽目的専用です）」という記述が含まれていたことがSNS上で話題となった。マーケティングと法的文言の乖離という一見些細な問題に見えるが、この一件はAIツールを業務導入する際の根本的な問いを私たちに突き付けている。 何が書かれていたのか Copilotの利用規約（2025年10月24日版）には次のような記述が含まれていた。 「Copilot is for entertainment purposes only. It can make mistakes, and it may not work as intended. Don’t rely on Copilot for important advice. Use Copilot at your own risk.」 （Copilotは娯楽目的専用です。誤りを犯すことがあり、意図した通りに動作しない場合があります。重要な判断にCopilotを頼らないでください。Copilotの使用はご自身の責任で行ってください。） Microsoftの広報担当者はPCMagの取材に対し、「製品の進化に伴い、この文言はもはや現在のCopilotの使われ方を反映していない。次回の更新で修正する」とコメントしている。つまり、「古いまま放置されていたレガシー表現」という説明だ。 他社も同様の免責条項を持つ この問題はMicrosoft固有ではない。Tom’s Hardwareが指摘するように、OpenAIは「唯一の事実情報源として依存しないこと」、xAIは「真実として依存しないこと」と利用規約に明記している。 AI企業が免責条項を設ける背景には、現在の大規模言語モデルが持つ本質的な限界がある。ハルシネーション（幻覚）と呼ばれる事実に反する情報の生成は、現時点ではどのモデルにも発生しうる。法的リスクヘッジという観点から、各社が慎重な文言を採用するのは理解できる。 企業導入の文脈で考えるべきこと しかし、問題は「免責条項があること」ではなく、製品のポジショニングと法的文言の間に生じた著しい乖離だ。 MicrosoftはCopilot for Microsoft 365を「業務効率を革新するエンタープライズAIアシスタント」として数千円/月の価格で法人展開している。一方で利用規約には「娯楽目的専用」と記されていた。この矛盾は、企業のIT部門が導入判断を行う上で無視できない情報だ。 日本の企業現場では、AI活用ガイドラインの整備が急務になっている。法務・コンプライアンス部門がAIツールの業務利用可否を審査する際、利用規約の文言は重要な判断材料となる。「娯楽目的専用」と明記されたツールを「業務の重要判断に使用してよいか」という問いに、現場は答えを出しにくくなる。 実務への影響と活用のポイント 今回の件からIT管理者・エンジニアが得るべき実践的な教訓は以下の通りだ。 1. AI出力の最終確認は人間が担う設計を守る どのAIツールであれ、重要な意思決定の最終判断を人間が担う設計を維持すること。これはMicrosoftの利用規約に限らず、業界全体の共通認識だ。 2. 利用規約の定期チェックを習慣化する SaaSツールの利用規約は無告知で更新されることが多い。四半期に一度程度、主要ツールの利用規約を確認するプロセスを組み込むことが望ましい。 3. 用途別にAIツールの「信頼水準」を定義する 社内AI活用ポリシーに、用途別の信頼水準を明文化する。例えば「ドラフト生成：AI利用可、法的文書確認：必ず専門家レビュー」といった形で用途を分類することで、ツールの特性に合った使い方が定着する。 4. ベンダーの文言変更をウォッチする Microsoftは今後利用規約を更新すると表明している。企業のAI利活用ポリシーは、ベンダーの文言変更と連動して見直す仕組みが必要だ。 筆者の見解 今回の騒動で改めて感じるのは、「もったいない」という言葉だ。 Microsoftはエンタープライズ市場を熟知している。セキュリティ、コンプライアンス、ガバナンスという面で法人顧客が何を求めているかを、他のどのテック企業よりも深く理解しているはずだ。だからこそ、「娯楽目的専用」というレガシー文言が長らく放置されていたことが惜しい。 法的免責と製品品質への自信は本来両立できる。重要なのは、免責条項の存在そのものではなく、その内容が製品の実態と整合しているかだ。「AI出力は必ず人間が確認すること」「重要な判断のための唯一の情報源として使わないこと」という趣旨の免責は誠実だし、現段階のAI技術の限界を正直に伝えるものとして評価できる。しかし「娯楽専用」という表現は、法人向けにポジショニングされた製品に対してあまりにも実態とかけ離れている。 ...

Google Mapsに「Ask Maps」という名のAIアシスタントが加わった。地図アプリにAIが組み込まれるのは自然な流れに見えるが、実際のところどこまで使えるのか——The Vergeのライターが1日かけて検証した体験レポートが話題を集めている。 「Ask Maps」とは何か GeminiをGoogle Mapsに統合したこの機能は、アプリ内のテキストボックスから会話形式で質問や依頼ができる。単なる場所検索にとどまらず、ルート上の天気確認や複数スポットを含む行程プランの立案など、複合的なタスクをこなせる設計になっている。データソースはGoogleマップの口コミ・評価が基本だが、必要に応じて外部情報も参照する。 実際の体験：想定外に「自律的」だった ライターは公共交通機関を使い、ランチ・散歩・カフェをめぐる行程を条件として提示した。GeminiはこれをもとにSシアトル市内のルートを組み立て、口コミを踏まえたおすすめ店を提案。途中で時間が余ったときにも「周辺のユニークなショップを探して」と再依頼すると、即座に候補を返してきたという。 注目すべきは、ただ「候補リスト」を並べるのではなく、利用者の条件を理解した上で優先順位をつけて提示した点だ。これはAIエージェントが「副操縦士的なサポート」ではなく、ある程度自律的に行程を判断していることを示している。 ハルシネーションという現実的なリスク ただし、体験は完璧ではなかった。Geminiが「1ブロック東にある」と案内した書店が、実際にはまったく別の場所にあるというハルシネーション（事実誤認）が1件発生した。 地図アプリでのハルシネーションは、文章生成AIのそれより直接的な実害に繋がりやすい。雨の中、間違った場所に向かって歩かされるリスクは、誤った文章を受け取るリスクよりも体感的なダメージが大きい。この点は特に強調しておく必要がある。 実務への影響——IT管理者・エンジニアが今すぐ考えるべきこと 個人ユーザーにとっては「便利なお出かけツール」として完結するが、法人・業務視点でもいくつか考えておく価値がある。 1. サービス統合型AIの精度は「データ品質」に直結する GeminiのMaps統合が機能するのは、Googleが膨大な地図・口コミデータを持っているからだ。企業が内製のナレッジベースとAIを統合する場合も、同じ原理が働く。AIの品質はデータの品質に上限が決まる。 2. ハルシネーションは「許容」ではなく「設計」で対処する 「ハルシネーションが怖いからAIは使わない」は現実的な解ではない。今回の事例で言えば、Geminiが「案内した場所に到着できたか」のフィードバックループを設けることで精度が上がる。業務で使うAIにも、出力結果を検証する仕組みを組み込む設計思想が重要だ。 3. プラットフォーム統合の強みを改めて認識する GeminiのMaps統合が「そこそこ使える」のは、検索・地図・口コミ・天気という複数のデータソースをシームレスに引けるからだ。個別のAIツールをバラバラに組み合わせて運用する場合と比べて、統合されたプラットフォームには全体最適という強みがある。 筆者の見解 AIエージェントの本質的な価値は「人間の認知負荷を削減すること」にある。「どこに行こうか」「どの順番で回るか」という判断コストを外部化できる——今回の体験はその小さな実例だ。 Google MapsへのGemini統合は、AIが「チャットボット」という単体ツールを超えて、日常的に使うサービスの中に溶け込み始めた段階を示している。この方向性自体は正しく、体験の品質も「使えない」レベルではなかった。 ただ、筆者が気になるのはハルシネーションへの対処の仕組みだ。今回は1件だったが、位置情報という「地面に足がついた現実」を扱うドメインで誤りが出たとき、ユーザーが気づけるかどうか。「AIが言ったから正しい」という信頼が高まるほど、気づけないリスクも上がる。利便性と信頼性を両立させるために、正確さの検証ループをどう組み込むかが今後の課題だろう。 地図AIが「道案内するだけ」から「1日のプランを組む」に進化したように、AIは徐々に自律的な判断の範囲を広げている。この進化の方向は止まらない。使う側がその限界を正確に理解した上で、適切に活用する姿勢を持ち続けることが、今もっとも大切なリテラシーだと思う。 出典: この記事は I let Gemini in Google Maps plan my day and it went surprisingly well の内容をもとに、筆者の見解を加えて独自に執筆したものです。

知識は「検索するもの」から「育てるもの」へ AIによる文書検索といえばRAG（Retrieval-Augmented Generation）が定番だ。ファイルをアップロードしてクエリを投げれば、関連チャンクを拾って回答を生成する。NotebookLM、ChatGPTのファイルアップロード、多くのRAGシステムがこの方式をとっている。 OpenAIの元研究者でAI界の著名人であるAndrej Karpathyが先日公開したアイデアファイル「LLM Wiki」は、このパラダイムに正面から疑問を投げかけている。彼の主張はシンプルで力強い。「毎回ゼロから知識を再導出するのは非効率だ。LLMに知識を積み上げさせよ」。 RAGとLLM Wikiの本質的な違い RAGの根本的な問題は「蓄積しない」ことだ。同じ資料を何度聞かれても、LLMは毎回フラグメントをかき集めて推論する。5つの文書を横断した微妙な問いに答えるには、毎回その5文書を探して文脈をつなぎ合わせなければならない。知識は積み重ならない。 LLM Wikiはこの問題を構造から解決する。アーキテクチャは3層だ。 第1層：生の情報源（Raw Sources） 論文、記事、画像、データファイルなど。これらは不変。LLMは読み取るだけで書き込まない。 第2層：LLMが維持するWiki 相互リンクされたMarkdownファイル群。新しい情報源を追加するたびに、LLMはそれを読み込み、既存のWikiに統合する——エンティティページを更新し、トピックサマリーを改訂し、矛盾する記述を明記し、合成知識を更新する。 第3層：人間とのインタラクション ユーザーは探索と「良い問いを立てること」だけに集中する。要約、相互参照、ファイリング、整合性の維持はLLMが担う。 Karpathyの表現は示唆に富む。「ObsidianがIDE、LLMがプログラマー、WikiがCodebaseだ」。彼は実際にLLMエージェントとObsidianを並べて使い、エージェントが編集したノートをグラフビューでリアルタイムに確認しながら作業しているという。 ユースケース：個人から企業まで Karpathyが挙げるユースケースは多岐にわたる。 個人のセルフマネジメント：目標、健康、自己分析——日記、記事、ポッドキャストのノートを蓄積して自分自身の構造化された像を作る リサーチ：数週間・数ヶ月かけてトピックを深堀りし、進化する論文を持つ包括的なWikiを構築 読書の深化：章ごとにファイリングしてキャラクター・テーマ・伏線ページを構築。ファンWikiのTolkien Gatewayのような richness を一人で作れる ビジネス・チーム：Slackスレッド、議事録、プロジェクト文書、顧客との通話を継続的にWikiに統合。誰もやりたくないメンテナンスをLLMが担う 日本のIT現場への影響 日本企業のナレッジマネジメントは、長年「書く人がいない問題」に悩んできた。Confluenceを導入してもページが更新されない、Wikiを作っても陳腐化する——これは「書くコストが高すぎる」という構造問題だ。 LLM Wiki的アプローチはこの問題に直撃する。人間が「書く」のではなく「話す・質問する」だけでWikiが育つ設計であれば、メンテナンスコストは劇的に下がる。 特に注目すべきは会議・コミュニケーションとの統合だ。Teamsの議事録やSlack的なチャットログを継続的にLLMに流し込んで、チームの知識ベースを自動的に更新し続ける構成は、今すぐ実装可能な現実解として検討に値する。 明日から試せる実践ポイント： まず個人で試す：Obsidian（またはMarkdownが扱えるツール）＋LLMエージェントで、自分の読んだ技術記事や調査メモを蓄積するWikiを作り始める。週1回インプット→Wiki更新のサイクルを回すだけでも効果は出る 情報源の分離を徹底する：Raw Sourcesは絶対に上書きしない設計にする。これがWikiの信頼性の根幹 矛盾の明示化を活用する：「この文書は既存のWikiのどこと矛盾するか」を明示させるプロンプトを入れる。知識のアップデートで最もコストが高い作業をLLMに委ねる チームWikiの試験導入：まず特定プロジェクトの議事録だけを対象に試す。全社展開より小さく始めて効果を測る 筆者の見解 このアイデアが刺さる理由は、「情報を追いかける」から「知識を育てる」へのパラダイムシフトを、具体的なアーキテクチャとして提示している点にある。 私が最近強く感じているのは、AIエージェントの真価は「一回の応答の質」ではなく「継続的なループの中でどれだけ知識と成果を積み上げられるか」にある、ということだ。LLM WikiはそのアイデアをKnowledge Managementの文脈で具現化したものといえる。エージェントが自律的に動き、判断し、構造を更新し続ける——これは単なるチャットボットとは根本的に異なる。 RAGが「図書館に都度行って調べる」なら、LLM Wikiは「賢い秘書が常に百科事典を最新状態に保ち続ける」に近い。情報量が増えるほど、一回一回の再発見コストが下がり、洞察の質が上がっていく。コンパウンド（複利）効果だ。 日本のIT現場でこれを活かすとすれば、まずチームの暗黙知の構造化だと思う。「なぜこの設計にしたのか」「あのトラブルをどう解決したか」——こうした情報は会議や1on1に埋まったまま消えていく。それをLLMが拾い上げ、構造化し、検索可能にする仕組みは、技術移転と属人化解消に直結する。 Karpathyは「自分ではWikiをほとんど書かない」と言う。これは理想の分業だと思う。人間は「何を学ぶか」「何を問うか」「何を信頼するか」という判断に集中し、ファイリングと整合性維持はエージェントに任せる。その分、考えることに使える時間と脳のリソースが増える。 ツールとしてはObsidianとLLMエージェントの組み合わせが今すぐ現実解だが、重要なのは特定ツールへの依存より「3層構造の思想」そのものだ。Raw Sourcesを不変に保つ、Wikiを永続的コンパウンドアーティファクトとして扱う——この設計原則さえ守れば、手元のツールで始められる。 情報を追いかけ続けることに疲弊しているエンジニアにとって、「蓄積する仕組みを作る」という視点の転換は、働き方そのものを変えうる可能性を秘めている。 出典: この記事は LLM Wiki – example of an “idea file” の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SQLiteは世界で最も広く使われているデータベースエンジンだ。スマートフォン、ブラウザ、組み込みシステム——あらゆる場所で動いている。にもかかわらず、その開発体験を改善するツール（フォーマッター、リンター、エディタ拡張）は長年貧弱なままだった。なぜか？　それには理由がある。そして今、AIコーディングエージェントがその壁を突き破った。 8年間の「積み残し」 GoogleのエンジニアであるLalit Maganti氏は、Perfettoというパフォーマンストレースツールのメンテナーとして、SQLiteベースのクエリ言語「PerfettoSQL」を長年管理してきた。社内に10万行超のPerfettoSQLコードがあり、フォーマッターやリンターの必要性を痛感しつつも、既存のオープンソースツールはどれも精度・速度・柔軟性の面で不十分だった。 「自分で作ればいい」——そう思い続けて8年が経過した。なぜ着手できなかったのか。答えは「難しくかつ退屈だから」だ。 SQLiteパーサが難しい本当の理由 言語系ツールの核心はパーサ（構文解析器）だ。ソースコードを「パースツリー」と呼ばれるデータ構造に変換し、その上にフォーマッターやリンターが乗る。パーサの精度が低ければ、すべての上位ツールがその誤りを引き継ぐ。 SQLiteのパーサ実装には、他言語にはない特殊事情がある： 公式の文法仕様書が存在しない — 多くのプログラミング言語と異なり、SQLiteはBNF等の正式な仕様を公開していない パーサAPIが公開されていない — 内部のパーサを外部から呼び出す安定したAPIがない 実装上、パースツリーを構築しない — SQLiteの内部実装は実はパースツリーを作らずにそのままコードを生成する設計になっている これは単なる「実装が大変」ではなく、「正解にたどり着くルートが極めて限られている」という構造的な難しさだ。SQLiteのソースコードを慎重に読み解き、パーサ部分を抽出・再実装するしかない。 AIエージェントが変えたもの Maganti氏は今年、夜間・週末・休暇を使った約250時間、3ヶ月の作業で「syntaqlite」をリリースした。彼が強調するのは「AIが一発でコードを生成してくれた」ではなく、AIコーディングエージェントとの協働がプロジェクトを持続可能にしたという点だ。 従来、このようなプロジェクトの最大の障壁は2つあった。一つは純粋な技術的難度、もう一つは「難しい＋退屈な作業の組み合わせ」による心理的コスト——仕様のない言語を地道にリバースエンジニアリングし続ける忍耐力だ。AIエージェントはその両方を緩和した。 実務への影響 SQLiteを直接使う開発者へ： syntaqliteはフォーマッター・リンター・エディタ拡張を提供するオープンソースプロジェクトだ。特にSQLiteを本格的に使うプロダクトや組み込みシステムを開発しているチームには、コードレビュー効率向上・クエリの標準化に役立つツールになりえる。 AIエージェント活用を考えるエンジニアへ： このプロジェクトが示す最も重要な示唆は「8年間手をつけられなかったものが3ヶ月で完成した」という事実だ。決定的な変化は単なるコード生成速度ではなく、「難しくて退屈なタスクの心理的コスト」が下がったことにある。仕様書の読み込み・試行錯誤・反復作業——これらをエージェントと分担することで、個人開発者の可能性の天井が実質的に上がっている。 IT管理者・アーキテクトへ： 「このプロジェクトは難しすぎる」「人手が足りない」という理由で積み残してきたものを棚卸しするタイミングかもしれない。AIエージェントを使いこなせるエンジニアが1人いれば、以前なら小チーム規模が必要だった仕事が動き始める。採用計画や外注判断の前提を見直す価値がある。 筆者の見解 この話を読んで「すごいな」で終わらせるのは、もったいない。 重要なのは、Maganti氏が「AIを使って楽をした」のではなく、「AIを使ってやっと本来やりたかった仕事に集中できた」という点だ。彼は8年間、プロジェクトの価値は分かっていた。技術力もあった。足りなかったのは「難しい＋退屈」という組み合わせを乗り越えるためのバッファだ。 AIコーディングエージェントの本質的な価値はここにある——高速なコード補完でも、テンプレートの自動生成でもなく、人間の認知負荷を削減して、本来の仕事に集中させることだ。 日本のIT現場でも、「技術的には可能だが誰も手をつけていない」積み残しは無数にあるはずだ。社内ツールの整備、レガシーコードのドキュメント化、品質基準の自動チェック——8年越しの夢が3ヶ月で形になる時代に、「人手不足だからできない」という言い訳の賞味期限は、静かに切れつつある。 AIエージェントが自律的に判断・実行・検証を繰り返す設計——いわゆるループ型のエージェント活用——が本格化するにつれ、「指示を出せる人間が一人いれば、以前は小チーム規模が必要だった仕事が動く」という状況は、今後さらに加速するだろう。syntaqliteは、そのことを静かに、しかし確実に証明している。 出典: この記事は Eight years of wanting, three months of building with AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

海外のセキュリティ専門家が書いた一本の記事が、HackerNewsで大きな反響を呼んでいる。自称「最もAI否定派に近い立場」の筆者が、業務上の必要性からAIコーディングツールを使い、見事に動くシステムを完成させた。そして深く落胆した——この逆説的な体験報告だ。 「使わなければならなかった」という文脈 著者は現在、AI対応アプリケーションのセキュリティテストと、社内AI専門家としての立ち回りを担う職種に就いている。皮肉なことに、AIの危険性を最もよく知る立場の人間が、AIを深く理解しなければ仕事にならない状況に置かれている。 「これらのツールが存在しなければいい」と思いながらも、安全なAI活用を守るためには使いこなさなければならない——この矛盾を正直に告白した上で、著者は今回のプロジェクトを語る。 Discourseへの移行と「証明書生成」という難題 きっかけは、学習プラットフォームのTeachableとDiscordからDiscourseへの移行プロジェクトだ。Discourseはフォーラムソフトウェアとして非常に優秀だが、コース修了証明書の生成機能は標準では備わっていない。LinkedInで受講証明を公開したい学習者のニーズに応えるため、独自の証明書生成システムが必要だった。 育児、他の移行作業、新プロジェクトが重なる中、「動けば証明書ソリューションが手に入る。動かなければ、少なくともこの技術への理解が深まる」という計算でAIコーディングツールを使う決断をした。 結果：「動いた。でも嫌だった」 システムはWebhookインターセプターを核とし、コース修了データを受信してPDF証明書を生成するアーキテクチャで構築された。セキュリティ的にも概ね問題なく動作し、自分でゼロから書くより速く完成した。 それでも著者は「作ること自体が不快だった」と明言する。AIが生成したコードへの違和感、「自分が完全には理解していないものを世に出している」という不安——技術者としての誇りと現実の効率性の間で引き裂かれた体験だ。 実務への影響 「嫌いだけど使う」という層が急速に拡大している 今回のケースが示すのは、AI肯定派だけでなく懐疑派・否定派のエンジニアも、実用性の前に使い始めているという現実だ。日本のIT現場でも同様の動きは着実に起きている。「試さずに語る」から「使いながら評価する」フェーズへの移行が加速している。 セキュリティ観点からの示唆 著者がAIセキュリティ専門家であることは重要だ。「AIが生成したコードを自分が完全に理解していない」という懸念は、セキュリティレビューの文脈で無視できない。AIが生成したコードへのコードレビューをどう設計するか——これは日本のエンジニアリングチームが今すぐ向き合うべき実務課題だ。 「速いが腑に落ちない」感情のケアも導入の鍵 開発速度と精神的な満足感のトレードオフは、チームへの導入判断にも影響する。「速いが嫌だった」という体験を経た開発者が、チームに戻ってAI活用を推進できるかどうか——組織的な導入では、この感情面のケアも無視できない。 筆者の見解 この記事を読んで「やっぱりそうか」と思う部分と、「もったいないな」と感じる部分が混在した。 「動いたが嫌だった」という感情は、決して珍しくない。長年コードと向き合ってきた技術者にとって、自分が把握しきれていないコードをリリースすることへの不快感は本物だ。その感覚は正しいし、大切にすべきものだと思う。 ただ一点、見方を変えたいのは——「AIに書かせた＝理解していない」という前提だ。AIが生成したコードを自分で読み解き、セキュリティ観点でレビューし、必要に応じて修正する。その過程で生まれる理解は、ゼロから書くときと質は違えど、決して薄いものではない。 AIを使いこなすということは「コードを書かせる」だけでなく「書いたコードを批判的に評価する眼を持つ」ことでもある。著者はセキュリティ専門家として、実はその眼をすでに持っている。「嫌だった」と言いながら「セキュリティ的に概ね問題ない」と評価できていること——これはむしろ、AIとの健全な付き合い方の好例ではないか。 道具を嫌いながらも使いこなし、その限界を見極める。それはある種の誠実さだ。「使って嫌いになった」という正直な声こそ、AIと技術者の関係が成熟しつつある証拠でもある。 出典: この記事は I used AI. It worked. I hated it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ローカルLLMの世界が静かに、しかし確実に変わりつつある。Google が2026年4月に公開した Gemma 4 は、混合エキスパート（MoE）アーキテクチャを採用した新世代のオープンウェイトモデルだ。そして LM Studio 0.4.0 が導入したヘッドレスCLI（lms）との組み合わせにより、クラウドAPIに頼らない本格的なローカル推論環境が、ふつうの開発者のMacBookで成立するようになった。 Gemma 4 ファミリーの構成 Gemma 4 は単一モデルではなく、用途別に設計された4モデルのファミリーとして提供されている。 モデル 特徴 E2B / E4B Per-Layer Embeddingsでオンデバイス最適化。音声入力（認識・翻訳）対応 26B-A4B（MoE） 本稿の主役。総パラメータ26B、前向き計算時の活性化は3.8B相当 31B（Dense） 最高精度。MMLU Pro 85.2% / AIME 2026 89.2%。全パラメータを毎回使用 注目すべきは 26B-A4B のベンチマーク結果だ。MMLU Pro 82.6%、AIME 2026 88.3% と、Dense版の31Bにほぼ肉薄しながら、メモリ消費とトークン生成速度は大幅に優れる。 MoEアーキテクチャが「ローカル推論の壁」を崩す Mixture of Experts（混合エキスパート）の仕組みを簡単に説明しよう。 Denseモデルは推論のたびに全パラメータを使う。26Bのモデルなら毎回26Bぶん計算する。対してMoEは「128人のエキスパート専門家」を持ちつつ、トークンごとに「最適な8人だけを呼ぶ」設計になっている。Gemma 4 26B-A4Bでは、実際の計算量は約3.8B相当で済む。 経験則として、MoEの実効品質は √(総パラメータ × 活性パラメータ) で近似できると言われる。このモデルなら √(26B × 3.8B) ≈ 10B 相当の実力を持つ、ということだ。実際、記事著者の検証では M4 Pro（48GB統合メモリ）のMacBook Proで 51トークン/秒 を達成している。 Eloscoreと総パラメータ数の比較では、Qwen 3.5 397B-A17BやKimi-K2.5（1,000B超）と同等スコアを叩き出しながら、26B-A4Bはその数十分の一のフットプリントで収まる。「クラスターがないと動かない」レベルの性能を、個人のラップトップに落とし込む——これがMoEの本質的な価値だ。 LM Studio 0.4.0 の「headless化」が実用性を一変させた LM Studioはもともとローカルモデルを手軽に動かせるデスクトップアプリとして知られていたが、0.4.0でアーキテクチャ自体が変わった。新たに llmster（コア推論エンジン）と lms（CLIツール）が導入され、GUIなしのヘッドレス運用が可能になった。 ...

Windows Insiderの長年の不満が解消されるかもしれない MicrosoftがWindows 11に「Feature Flags」ページを追加することを正式に認めた。ビルド26300.8155に隠しオプションとして存在が確認されており、Windows Insider Program設定画面の「Insider設定の選択」直下に配置される予定だ。Chromeユーザーにはおなじみの chrome://flags と同様の仕組みで、開発中の機能を自分のタイミングで有効・無効に切り替えられるようになる。 Controlled Feature Rollout（CFR）という「運任せ」の問題 ここ数年、MicrosoftはControlled Feature Rollout（CFR）という仕組みで新機能をA/Bテスト的に段階配信してきた。趣旨はシステム安定性の確保という理にかなったものだが、実態としては「Insiderに登録しているのに自分のPCには新機能が来ない」という理不尽な状況を生んでいた。 その解消策として広く使われてきたのがViVeToolだ。CFRで隠されている機能IDを調べて手動で有効化できるサードパーティ製ツールで、Insider界隈では定番中の定番になっていた。便利ではあるが、IDを自力で調査する手間、将来的な動作保証のなさ、そして「公式でないツールを使う」という精神的なハードルがあった。 今回のFeature Flagsは、そのViVeToolが担ってきた役割をMicrosoft公式が引き受けるという意味で、コミュニティへの正面からの回答だと言える。 機能の詳細 現時点で判明している仕様は以下のとおりだ。 Available Flags：現在有効化可能なフラグの一覧。各フラグのオン／オフをトグルで切り替え可能 Inactive Flags：すでにロールアウト完了済み、または削除済みのフラグ。Clearボタンで管理できる Reset all / Apply Changes：一括リセットと変更の適用ボタン 警告表示：「これらの機能はまだ開発中であり、パフォーマンスや安定性に影響を与える可能性があります」 Microsoftは近日中に詳細を共有すると述べており、全Insiderビルドの新機能がフラグ対象になるのか、それとも一部のみかはまだ明確ではない。ただし警告文の表現からは、「新Insiderビルドに含まれる機能はデフォルトでフラグリストに追加される」方向性がうかがえる。 実務への影響 Windows管理者・IT担当者にとって 今回の変更が直接影響するのは主にInsider Program参加者だが、中長期的には企業のWindows展開戦略にも影響しうる。 テスト環境でのUI変更確認が楽になる：新機能が来るかどうかCFR任せにせず、テスト機での検証を計画的に進められる サポートの一貫性：ViVeToolのような非公式ツールを使う必要がなくなれば、「なぜこの機能が有効になっているのか」といったサポート混乱が減る 本番環境は静観が正解：安定性警告が示す通り、本番マシンへの適用は依然として慎重に。機能フラグはあくまでInsiderやテスト環境向けの道具だ 開発者・パワーユーザーにとって 特定のWindowsシェル機能や新UI要素を検証したいアプリ開発者にとっては、再現性の高いテスト環境が公式に整備されることになる。ViVeToolに依存していたワークフローも、公式UIへの移行を検討するタイミングだ。 筆者の見解 Chromeが chrome://flags を提供した頃を振り返ると、「ブラウザがこんなに開発者フレンドリーになるとは」と驚いたものだ。WindowsがそれをOSレベルで実現しようとしているのは、素直に面白い動きだと思う。 一方で、冷静に見ると「なぜこれが今までなかったのか」という疑問も残る。Insider Programは本来「新機能をいち早くテストするプログラム」のはずだ。CFRによってInsiderでも機能が当たらないという状況は、プログラムの趣旨と実態が乖離していた。今回の修正はある意味、その乖離の訂正でもある。 Microsoftがコミュニティの声をきちんと形にしてくれたことは評価したい。ViVeToolというエコシステムが育つほどの需要があった課題に、正面から応えようとしている。Windowsという巨大なプラットフォームを動かし続けながらこうした細部の改善を積み重ねていける組織力は、やはり侮れない。 あとは「全フラグを公開するのか、一部のみか」という肝心な点が今後明らかになる。Insider体験の質を本当に変えるかどうかはそこにかかっている。続報に注目したい。 出典: この記事は Microsoft confirms Windows 11 is getting Chrome-like feature flags to bypass gradual rollouts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Linuxデスクトップの最前線を走るKDE Plasmaが、Waylandの新しいフラクショナルスケーリングプロトコル「xx-fractional-scale-v2」のサポートを進めていることが、KDEチームの「This Week in Plasma」アップデートで明らかになった。HiDPIディスプレイが当たり前になった今、この対応はLinuxデスクトップ環境の実用性を大きく底上げする可能性がある。 Waylandとフラクショナルスケーリング、何が問題だったのか WaylandはX11を置き換えるべく開発が進む次世代ディスプレイサーバープロトコルだ。セキュリティ面やパフォーマンス面でX11を大きく上回るが、長年の課題の一つが「非整数倍スケーリング（Fractional Scaling）」の扱いだった。 4Kや高解像度ディスプレイでは200%（2倍）のスケーリングでは大きすぎ、100%（等倍）では小さすぎる、という場面が多い。150%や125%といった「非整数倍」での表示が求められるわけだが、既存の wp-fractional-scale-v1 プロトコルでは実装ごとに挙動がばらつき、アプリケーションによってはボケた表示やレイアウト崩れが生じるケースがあった。 xx-fractional-scale-v2が解決すること 新プロトコル「xx-fractional-scale-v2」は、この問題に正面から取り組む設計となっている。主な改善点は以下の通りだ。 クライアント側のレンダリング精度向上: アプリケーションが正確なスケール情報を取得できるようになり、自前でシャープな描画ができる コンポジター（KWin等）との連携強化: デスクトップ環境とアプリ間のスケール情報のやり取りが標準化され、実装差異が減る マルチモニター環境での整合性: 異なるDPIのモニターを混在させても、ウィンドウ移動時の再スケーリングがより自然になる KDEのコンポジターであるKWinがこのプロトコルに対応することで、KDE Plasmaアプリだけでなく、GTKアプリやElectronベースのアプリも恩恵を受けられる可能性がある。 実務への影響 — 日本のエンジニア・IT管理者にとって Linux開発環境を業務で使うエンジニアにとって、この変更は無視できない。特に以下のような場面で恩恵が大きい。 開発者向けワークステーション: 4Kモニターや高DPIラップトップでLinuxを使うエンジニアは増えている。IDEやコードエディターの表示がシャープになり、目の疲れ軽減にもつながる。 Dockerデスクトップ・WSL2 GUI: WSL2でLinux GUIアプリをWindows上で動かす構成では、Waylandプロトコルの動作品質がそのままユーザー体験に直結する。Windowsとのインターフェース層が改善されると、この構成の安定性も向上する可能性がある。 Linuxシンクライアント環境: 一部の日本企業では、セキュリティポリシー上Linuxシンクライアントを採用しているところがある。HiDPIディスプレイへの移行が容易になることは、運用コスト面でもプラスだ。 今すぐ試したい場合は、KDE Plasmaの開発版（nightly build）をFlatpakや各ディストリビューションのテストリポジトリから入手して動作確認するのが現実的なアプローチだ。本番環境への適用は安定版リリースを待つのが無難だろう。 筆者の見解 Waylandへの移行は「もうすぐ完成する」と言われ続けて久しいが、フラクショナルスケーリングの標準化という地味ながら本質的な問題にプロトコルレベルで取り組んでいる点は評価に値する。インフラの整備は派手さがないが、それがあってこそ上位レイヤーのアプリが正しく動く。 面白いのは、このような「ディスプレイスケーリングの標準化」という課題は、WindowsのHiDPI対応の歴史とも重なることだ。Windowsも長年、レガシーアプリのDPI非対応問題と格闘してきた。プラットフォームが変わっても、ディスプレイの高解像度化に追いつくのは一筋縄ではいかないということだろう。 KDEは以前から、Wayland対応において他のデスクトップ環境より積極的にプロトコルの拡張・実験を行ってきた。xx-fractional-scale-v2の採用もその延長線上にある。実用的なデスクトップを作るというコミットメントが、こういった地道な取り組みに表れている。引き続き、Plasma 6.x系の完成度が高まっていく過程を注目して見ていきたい。 出典: この記事は KDE is getting support for the xx-fractional-scale-v2 Wayland protocol の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Samsungが、長年Galaxy端末のデフォルトとして親しまれてきた「Samsung Messages」を廃止し、「Google Messages」へ完全移行する方針を発表した。単なるアプリの入れ替えに見えるが、この決定はAndroidエコシステムの構造変化を象徴する出来事として注目に値する。 Samsung Messagesとは何だったのか Samsung Messagesは、Galaxy端末に標準搭載されてきた純正SMSアプリだ。シンプルなSMS/MMSの送受信から始まり、長年にわたってGalaxyユーザーの「当たり前の存在」だった。しかし近年、Google MessagesがRCS（Rich Communication Services）への対応を積極的に進め、既読確認・高画質メディア送信・エンドツーエンド暗号化といった機能を取り込んだことで、Samsung Messagesとの機能差は急速に広がっていった。 なぜ今、廃止なのか SamsungがGoogle Messagesへの統合を選んだ背景には、いくつかの合理的な判断がある。 RCS普及の加速: Appleが2024年にiOS 18でRCSをサポートしたことで、RCSは事実上の次世代SMSとして確立されつつある。Google MessagesはAndroid陣営でのRCS推進役であり、Samsung独自実装を維持するコストよりも、Googleのエコシステムに乗っかる方が利用者体験を向上させやすい。 重複投資の排除: 同じメッセージング機能を二社が並行開発・保守するのは明らかに非効率だ。Samsungとしては、差別化の薄いコモディティ領域から撤退し、リソースをカメラやディスプレイ、Galaxy AIなど競争優位のある領域に集中させる判断は理にかなっている。 ユーザー体験の一貫性: GoogleとSamsungの間に存在した微妙な機能差や互換性の問題が解消されることで、エンドユーザーにとっては混乱が減る。 実務への影響——IT管理者・エンジニアが知っておくべきこと 日本のエンジニアやIT管理者にとって、この変更は以下の点で実務的な意味を持つ。 MDM管理の見直し: 企業向けにGalaxy端末を管理しているIT部門は、Samsung MessagesとGoogle Messagesでポリシーの適用方法が異なる場合がある。Samsung Knox経由での制御とGoogle管理の挙動の違いを事前に確認しておくことを勧める。特にSMS/MMSの送受信制限やデータ保持ポリシーを適用している環境では影響が出やすい。 RCS対応の機会: これを機に、社内コミュニケーションのRCS化を検討するのも一手だ。ただし、RCSはキャリア側の対応状況に依存するため、日本国内の主要キャリアのサポート状況を確認した上で判断してほしい。 移行タイミングの把握: SamsungはGalaxy端末ユーザーに対して移行期限を設けているため、BYOD（私物端末の業務利用）を許可している組織では、ユーザーへの事前周知が必要になる。移行後もSMSの送受信機能自体は継続されるため、業務影響は限定的と考えられるが、設定やデータ移行でのサポート問合わせが増える可能性はある。 セキュリティ面の確認: Google MessagesはRCSチャット使用時にエンドツーエンド暗号化を提供しているが、SMSは従来通り平文送信であることに変わりはない。機密情報を扱う業務では、引き続き専用のセキュアメッセージングツールを使用するポリシーを維持すべきだ。 筆者の見解 この動きを「Samsungの敗北」と見るのは単純すぎる。むしろ、重複した投資を整理してエコシステム全体を効率化するという、健全な判断だと評価したい。プラットフォームの全体最適という観点からも、機能が重複するアプリを並存させ続けるより、一本化して品質を上げる方が利用者にとって良い結果をもたらすことが多い。 一方で、自社アプリを終了してプラットフォーマーのアプリに委ねるという選択には、長期的なコントロールを手放すリスクも伴う。Samsungのような巨大メーカーですら、この種のトレードオフから無縁ではない。 より本質的な示唆は、メッセージングという機能が完全にコモディティ化したということだ。ユーザーが独自SMSアプリにブランドロイヤリティを感じる時代は終わった。今後は「どのメッセージングアプリか」よりも「どのプロトコルで通信しているか」が重要になる。RCSが本格普及すれば、メッセージングの土台はキャリアからインターネット層へと移っていく。その変化の加速を、今回の発表はあらためて教えてくれている。 出典: この記事は End of an era: Samsung is killing Samsung Messages in favor of Google Messages の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Next.jsを使ったWebアプリケーションを狙った、大規模かつ高度に自動化されたクレデンシャル窃取キャンペーンが確認された。Cisco Talosが今週公開したレポートによれば、「UAT-10608」と追跡される脅威クラスターが「NEXUS Listener」と呼ばれる専用フレームワークを駆使し、わずか24時間のうちに766ホストの侵害に成功している。 何が起きているのか——React2Shell（CVE-2025-55182）という「入り口」 今回の攻撃の起点となっているのが、CVE-2025-55182として採番されたReact2Shellという脆弱性だ。Next.jsアプリに存在するこの欠陥を悪用することで、攻撃者はシステム上でコマンドを実行できる状態を作り出す。 攻撃の流れはシンプルかつ効率的に設計されている。 インターネット上の脆弱なNext.jsアプリを自動スキャン React2Shellで初期侵入を確立 システムの一時ディレクトリに多段階クレデンシャル収集スクリプトを配置 収集した機密情報をHTTPポート8080経由でC2サーバー（NEXUS Listener）へ逐次送信 何が盗まれているのか——想像以上に広い収集範囲 Cisco Talosの研究者が実際にNEXUS Listenerの露出インスタンスへアクセスして分析した結果、収集対象は以下のとおりであることが判明した。 環境変数・シークレット: APIキー、データベース認証情報、GitHub/GitLabトークン SSHプライベートキー クラウドクレデンシャル: AWS・GCP・Azureのメタデータ、IAM認証情報 Kubernetesトークン Dockerコンテナ情報 コマンド履歴 プロセス・ランタイムデータ 特筆すべきは、これらが「あったら盗む」ではなく「ありそうな場所を全部狙う」という設計になっている点だ。AWSのインスタンスメタデータから始まりKubernetesのサービスアカウントトークンに至るまで、クラウドネイティブ環境で使われる機密情報のほぼすべてが収集対象に含まれている。 実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと この攻撃が厄介なのは、被害が侵入されたサーバー単体に留まらない点だ。盗まれたSSHキーは横移動（ラテラルムーブメント）に使われ、クラウドのIAM認証情報はアカウント乗っ取りを可能にし、GitHubトークンはサプライチェーン攻撃の扉を開く。さらにCisco Talosは、個人情報の漏洩によるプライバシー法規制上のリスクも指摘している。日本ではGDPR同等の個人情報保護法への対応が求められる組織も多く、他人事ではない。 今すぐ実施すべき対応策： React2Shellのセキュリティアップデートを即時適用する。 対象システムが特定できない場合、Next.jsを使ったアプリをすべてリストアップするところから始める 侵害の疑いがある場合はクレデンシャルをすべてローテーションする。 「たぶん大丈夫」で済ませてはいけない AWSを使っている場合はIMDSv2を強制する。 IMDSv1が有効なままだとメタデータエンドポイントへの不正アクセスリスクが残る コンテナ・クラウドロールの最小権限原則（Least Privilege）を徹底する。 広すぎる権限は、侵害されたときの被害を指数関数的に拡大させる WAF/RASPをNext.jsアプリの前段に配置する。 シグネチャベースの検知だけでは限界があるが、それでも攻撃コストを上げる効果は大きい シークレットスキャンを有効化する。 GitHubであればSecret Scanningが標準で使える。誤ってコードにクレデンシャルを書いてしまった経験は誰にでもある 筆者の見解 この種の攻撃を見るたびに思うのは、「防御の難しさ」より「そもそもの設計」の問題だということだ。Next.jsアプリのサーバー環境に、AWSのIAMクレデンシャルからKubernetesのサービスアカウントトークンまで、なぜそれほど多種多様な機密情報が置かれているのか。利便性を優先して一台のサーバーに何でも詰め込んでしまうと、一点突破で全部持っていかれる。 「Just-In-Time」なアクセス管理と最小権限の原則は、耳にタコができるほど繰り返されてきた話だが、今回の766ホストという数字は、それが実態に落とし込まれていないことを示している。常時発行されているクレデンシャルが多いほど、盗まれたときのダメージは大きい。環境変数に長期有効なAPIキーを何十個も持つ構成は、攻撃者にとって宝の地図をまるごと渡すようなものだ。 ゼロトラストの文脈で言えば、ネットワーク層・認証層・認可層の3層すべてで独立した防御を設計することが正道だ。どこか一層が突破されたとしても、次の層が機能していれば被害を最小化できる。今回のNEXUS Listenerのような自動収集ツールは今後さらに洗練されていく。一度壊れた信頼を取り戻すコストを考えれば、設計段階での投資は決して高くない。 出典: この記事は Hackers exploit React2Shell in automated credential theft campaign の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Fortinetが週末に緊急のセキュリティアップデートを公開した。FortiClient Enterprise Management Server（EMS）に発見された新たな重大脆弱性（CVE-2026-35616）が、すでに実環境での攻撃に悪用されていることが確認されたためだ。影響を受けるバージョンを運用中のIT管理者は、今すぐ対応が必要な状況だ。 脆弱性の概要：認証を完全に素通りされる CVE-2026-35616は、不適切なアクセス制御（Improper Access Control） に分類される脆弱性だ。攻撃者は認証なしで特細工されたリクエストを送信するだけで、サーバー上でコードやコマンドを実行できてしまう。 この脆弱性を発見したセキュリティ企業Defusedは、「プリオーセンティケーション APIアクセスバイパス」と説明している。つまり、ログイン前の段階で認証・認可の仕組みをまるごと迂回できるということだ。しかも同社は、Fortinetへの報告前にすでに攻撃者が悪用しているゼロデイであることを確認している。 影響を受けるバージョンと対処法 今回の脆弱性が影響するのは以下のバージョンだ： FortiClient EMS 7.4.5（ホットフィックス適用が必要） FortiClient EMS 7.4.6（ホットフィックス適用が必要） FortiClient EMS 7.2系は影響を受けない。 Fortinetは各バージョン向けのホットフィックスを公開しており、7.4.7でも修正が含まれる予定となっている。まずは現行バージョン向けのホットフィックスを優先して適用するのが現実的な対応だ。 なお先週も別の重大脆弱性（CVE-2026-21643）が同じFortiClient EMSで報告・悪用されており、同じくDefusedが発見している。短期間に連続して重大な脆弱性が出ている点は注目に値する。 被害規模：インターネット上に2,000台超が露出 インターネットセキュリティ監視組織のShadowserverによると、FortiClient EMSのインスタンスが2,000台超インターネットに露出した状態で確認されている。主な分布は米国とドイツとされているが、日本のエンタープライズ環境でも導入実績のある製品だけに、国内での被害は他人事ではない。 実務への影響 FortiClient EMSはエンドポイントのセキュリティポリシーを一元管理するサーバーだ。ここが侵害されると、管理下のすべてのエンドポイントに対して任意のポリシーを配布できてしまう可能性がある。被害が拡大するまでの時間が短く、侵害の痕跡も残りにくいタイプの脆弱性だ。 IT管理者がまず確認すべき事項を整理する： バージョン確認: FortiClient EMSのバージョンが7.4.5または7.4.6かどうかを即確認する ホットフィックスの適用: 対象バージョンであれば、Fortinet公式のリリースノートからホットフィックスを取得して適用する 外部露出の確認: FortiClient EMSの管理ポートがインターネットに直接露出していないかを確認する。管理系サーバーをインターネットに直接さらすのは、それ自体が設計の問題だ ログの確認: 脆弱性が悪用されるゼロデイ期間中に不審なAPIアクセスがなかったかをログで確認する 筆者の見解 ゼロトラストアーキテクチャを推進する立場からすると、今回の脆弱性が突いているポイントは示唆的だ。「認証を通らなければ安全」という前提が崩れたとき、その先に何の防御もなければ即座に終わりを迎える。 「管理サーバーはVPNの内側にあるから大丈夫」という感覚でいる環境も多いかもしれないが、ゼロトラストの観点では境界防御だけに頼ることは今や十分ではない。エンドポイント管理のような高権限サーバーへのアクセスには、ネットワーク層だけでなく認証層・認可層も多重に重ね、さらにJust-In-Time（JIT）アクセスのような「必要なときだけ権限を与える」仕組みを加えることが理想だ。 FortiClientはエンドポイントセキュリティの有力な選択肢として多くの現場で使われている。だからこそ、今回のような脆弱性が連続して発生することは残念だし、ユーザーとしては適切なパッチ適用サイクルを維持することが引き続き重要になる。「今動いているから大丈夫」は、こうした事態の前では通用しない。週末に緊急パッチが出た事実が、事の重大さを物語っている。 今すぐ自環境のバージョンを確認し、対象であれば業務時間を待たずに対応することを強く勧める。 出典: この記事は New FortiClient EMS flaw exploited in attacks, emergency patch released の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国で、交通違反の「督促通知」を装ったSMSフィッシングが新たな進化を遂げている。従来のリンク付きテキストメッセージから、裁判所通知の画像にQRコードを埋め込む手法へと切り替わり、セキュリティ研究者やフィルタリングシステムによる検知を意図的に回避しようとしている。 何が起きているのか 攻撃者は「ニューヨーク刑事裁判所」などの公的機関を名乗り、「未払いの交通違反がある。今すぐ支払わなければ法廷に出頭せよ」という内容のSMSを送りつける。メッセージには画像ファイルとして偽造された公式通知書が添付されており、その中にQRコードが印刷されている形をとっている。 QRコードをスキャンすると、まずCAPTCHA（人間確認）ページへ誘導される。これをクリアすると今度は州のDMV（車両管理局）を模倣したフィッシングサイトへリダイレクトされ、「未払い残高 $6.99」の支払い手続きを促す。最終的には氏名・住所・電話番号・メールアドレス・クレジットカード情報が盗まれる仕組みだ。 なぜ「画像＋QRコード」なのか この手法が巧妙なのは、セキュリティ対策の盲点を突いている点だ。 ① テキストリンクを含まない 多くのSMSフィルターやメールゲートウェイは、不審なURLを検出してブロックする。しかしQRコードは画像データであり、リンクとして認識されない。 ② CAPTCHAが自動解析を阻む 悪意あるURLを自動的にクロールして評価するサンドボックスや脅威インテリジェンスシステムは、CAPTCHAで足止めを食らう。人間が操作しなければ先に進めない構造にすることで、調査を困難にしている。 ③ 公的機関への擬態が心理的プレッシャーを生む 「裁判所」「法的措置」「最終警告」という言葉は、受信者に焦りを与える。冷静な判断を奪い、確認せずにQRコードをスキャンさせるための社会工学的な仕掛けだ。 日本への示唆——「対岸の火事」ではない この手口は米国固有の話ではない。日本でも宅配便の不在通知、ETC料金未払い、マイナンバー関連通知を装ったSMSフィッシング（スミッシング）はすでに広く観測されている。今後、同様の「QRコード画像添付型」が日本でも使われるのは時間の問題だろう。 特に注意が必要なのは、QRコードをスキャンする行為そのものがリスクという認識が、一般ユーザーにはまだ薄い点だ。URLを直接タップすることへの警戒心は高まっているが、「カメラをかざすだけ」のQRコードは無意識にスキャンしてしまいがちだ。 実務での対策ポイント エンドユーザーへの啓発として伝えるべきこと： 公的機関（裁判所・警察・行政）はSMSで支払いを求めない QRコードをスキャンする前に「誰から来たか」を一度立ち止まって確認する スキャン先のURLを確認し、公式ドメインでなければ閉じる（ny.gov-skd[.]org のような偽ドメインに注意） 少額請求（今回は$6.99、日本なら数百円程度）は心理的ハードルを下げるための罠 IT管理者・セキュリティ担当者として： モバイルデバイス管理（MDM）ポリシーで、業務端末でのQRコードスキャン先URLのフィルタリングを検討する エンドポイントのモバイルブラウザにも、フィッシング対策フィルターが有効かを確認する フィッシングシミュレーション訓練に「QRコード型」シナリオを追加する時期に来ている 筆者の見解 この事例を見て改めて感じるのは、攻撃者の方がセキュリティ対策の仕組みをよく理解しているという現実だ。テキストリンクが検出されるなら画像にする、URLスキャンが走るならCAPTCHAで止める——対策が進化するたびに、攻撃はその隙間を狙ってくる。 セキュリティの世界では「防御側は全部守らないといけないが、攻撃側は一点突破でいい」と言われる。だからこそ、技術的なフィルタリングだけに頼る発想には限界がある。ユーザーが「おかしいな」と感じて立ち止まれる習慣と知識を育てることが、結局は最も強固な防衛線になる。 組織のセキュリティ担当者としては、禁止や制限で固める方向に走りたくなる気持ちはわかる。しかし「QRコードスキャン禁止」のような硬直したポリシーは、業務での正当な利用まで阻害して形骸化する。「使える仕組みを安全に使える状態にする」という発想で、啓発と技術的補助を組み合わせるアプローチが現実的だと思っている。 今後、こうした攻撃がAI生成の精巧な偽通知画像と組み合わされれば、さらに見分けがつきにくくなる。攻撃手口の進化に対し、私たちの対策と啓発も継続的にアップデートし続けるしかない。 出典: この記事は Traffic violation scams switch to QR codes in new phishing texts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

クラウドが「使えない」現場がある パブリッククラウドは便利だ。しかし現実には、インターネットに常時つながることができない場所で動く重要システムが世界中に存在する。軍・防衛、エネルギーインフラ、公共安全機関、遠隔地の研究施設——こうした環境ではデータをクラウドに送ること自体が規制や安全保障上の要件と衝突する。 MicrosoftとArmadaはこの「ラストマイル問題」に正面から取り組む協業を発表した。Azure Local を Armada の Galleon モジュラーデータセンター（MDC）上に展開し、切断・制限・移動環境でも Azure のクラウド運用モデルをそのまま持ち込める「主権エッジ（Sovereign Edge）」基盤を実現する。 何が新しいのか Azure Local × Galleon MDC の組み合わせ Azure Local は Microsoft のオンプレミスクラウドプラットフォームで、Azure の管理モデルやセキュリティを自前環境に持ち込める製品だ。今回はこれを Armada の Galleon MDC という物理的に展開可能なモジュール型データセンター上で動かす。 Galleon MDC は「運べるデータセンター」として設計されており、衛星・LTE/5G・RF・SD-WAN などの多様な回線に対応した回復性の高いネットワーク接続、ハイパーコンバージドおよび SAN バックストレージ、政府・規制準拠のセキュリティハードニングをパッケージで提供する。完全切断状態でも動作し続ける設計になっている点が最大の特徴だ。 Foundry Local によるオンプレ AI 推論 インフラだけでなく、AI ワークロードもこの環境で完結させられる。Microsoft Sovereign Private Cloud の一部として提供される Foundry Local を使えば、AI 推論・分析処理をパブリッククラウドへの接続なしに自分たちのトラストバウンダリ内だけで完結させることができる。 この構成が対応するユースケースは具体的だ： データ主権要件への対応 — データを自国・自組織のインフラ外に出さない 低遅延のリアルタイム判断 — 分析結果をその場で意思決定に使う 帯域制約・断絶環境での AI 運用 — 接続が不安定な現場でも AI が止まらない 日本のIT現場への影響 「これは海外の防衛案件の話」と思うかもしれないが、日本にとっても無関係ではない。 まず経済安全保障・データ主権の観点。日本の経済安全保障推進法により、重要インフラ事業者（電力・通信・金融・交通等）は外部依存を最小化しながらデジタル化を進めることが求められている。「国産クラウド」という選択肢が現実的でない中、この種の「主権プライベートクラウド」は現実的な落としどころになりえる。 次に地方・離島・災害時の継続性。日本は離島が多く、災害時に回線が切断されるリスクが高い環境だ。このアーキテクチャは「平常時はクラウド接続、断絶時でも AI/データ処理を継続」という運用を可能にする。官公庁・自治体・公共インフラ事業者にとって検討価値は高い。 ...