Tech News JP

MicrosoftがWindows 11の目玉AI機能として発表した「Recall（リコール）」が、波乱含みのリリースから約1年を迎えた。しかし現実は厳しく、全Windows 11 PCのうちRecallを有効化できる端末は10%未満にとどまっている。数字だけ見れば「普及率の問題」に映るが、その背景には今なお解消されていない根本的なセキュリティ上の懸念がある。 Recallとは何か、なぜ問題になったのか RecallはPC上のあらゆる操作をスクリーンショットとして継続的に記録し、AIが意味を解釈して後から自然言語で検索できる機能だ。「あのときブラウザで見ていたページを探したい」「数週間前に編集した書類の内容を知りたい」といったユースケースを想定している。 リリース直後から、セキュリティ研究者が重大な懸念を指摘した。PC上のすべての操作履歴が実質的に平文に近い形でローカルに蓄積されるため、マルウェアや攻撃者にとって「ユーザーの全行動ログ」という極めて価値の高い標的になり得るという点だ。Microsoftは機能の有効化にWindows Hello認証（顔認証・指紋認証）を必須にするなどの対策を講じたが、独立した研究者からは「暗号化の設計が不十分」「一度認証を突破すれば履歴データに容易にアクセスできる」との指摘が続いている。 Microsoft側は「脆弱性は存在しない」との立場を崩していない。しかしこの見解の乖離が1年経っても埋まっていないこと自体が、問題の根深さを物語っている。 なぜこれが重要か 日本のIT現場にとって、Recallは「まだ関係ない機能」ではない。企業が管理するWindows 11端末にもRecall対応ハードウェア（Copilot+ PC）が徐々に普及しつつある。デフォルトではオフとはいえ、ユーザーが誤って有効化するリスク、あるいは将来のポリシー変更でデフォルトが変わるリスクを、IT管理者は今から把握しておく必要がある。 とりわけ機密情報を扱う環境——金融、医療、法務、製造の設計部門など——では、業務中の画面操作がすべてローカルに記録され続けるという設計は、情報セキュリティポリシーと根本から矛盾しかねない。 実務での活用ポイント IT管理者向け Microsoft Intune（エンドポイントマネージャー）のポリシーでRecallを組織レベルで無効化するCSP（User Rights: DisableAIDataAnalysis相当の設定）の適用を検討する Copilot+ PC調達時に、Recall関連の設定がデフォルトでどうなっているかをベンダーに確認し、キッティング手順に組み込む 社内のデータ分類ポリシーにRecallの有効化可否を追加し、端末用途によって制御を変える設計を検討する エンジニア向け 開発端末でRecallを使う場合、APIキーやシークレットが画面上に表示される操作は記録対象になり得ることを意識する。ターミナルや認証フローを含む操作の扱いには注意が必要 ゼロトラストの観点で言えば、「ローカルに全操作ログが存在する」状態はラテラルムーブメント（横展開攻撃）の攻撃面を広げる。エンドポイントのEDR設定と組み合わせて考えるべき問題だ 筆者の見解 Recallは、構想自体は面白い。「PCの使用履歴をAIが意味のある形で整理して後から引き出せる」という方向性は、人間の認知限界を補う発想として本質的に正しいと思う。 だから余計にもったいない。設計の根幹にあるべき「この機能によってユーザーのセキュリティリスクが上がってはいけない」という原則が、リリース時点で不十分だったことは明らかだ。そして1年後もセキュリティ研究者との見解の乖離が解消されていないという状況は、設計レベルでの対話が十分にできていないことを示唆している。 企業向けのIT基盤をMicrosoftで統一しているユーザーとして、率直に言う。「脆弱性なし」と言い切るなら、その根拠を独立した第三者が検証できる形で示すべきだ。Microsoftにはその技術力も信頼の蓄積もある。正面から向き合える力があるのだから、研究者コミュニティとの対話を通じて設計の正しさを証明していく姿勢を見せてほしい。 導入率10%未満という数字は、ユーザーの判断が今のところ正常に機能していることを示しているとも読める。だが「あとで有効にすればいい」の積み重ねは、ある日突然セキュリティインシデントに転化する。IT管理者は今のうちに組織としての方針を定めておくことを強くお勧めする。 出典: この記事は One year after its rocky launch, Microsoft’s Windows Recall still raises security red flags の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftがソブリンクラウド戦略を大きく前進させた。Azure Local DisconnectedとMicrosoft 365 Local Disconnectedが正式GA（一般提供開始）となり、完全ネットワーク分離環境でもAzureのガバナンスと生産性スイートをフル活用できるようになった。さらにFoundry Localが大規模マルチモーダルLLMのオフライン実行に対応し、クラウドに繋がらない環境でもエンタープライズグレードのAI推論が可能になった。 Azure Local Disconnectedとは何か Azure Local Disconnectedは、インターネット接続がない完全エアギャップ（air-gapped）環境においても、Azureのポリシー管理・ガバナンス・コンプライアンス機能を維持しながら基幹インフラを運用できるソリューションだ。 Microsoft 365 Local Disconnectedを利用すれば、Exchange Server、SharePoint Server、Skype for Business Serverなどのコアワークロードを少なくとも2035年までサポートを受けながらオンプレミスで継続運用できる。データの管理・アクセス制御・コンプライアンスをすべて自組織の手元で完結させる、まさに「クラウドの恩恵を受けながら外には出さない」という構成が実現する。 Foundry LocalがNVIDIA・AMD GPUで大規模LLMをオフライン実行 今回の発表でもう一つ注目すべきは、Foundry Localの大幅な機能拡張だ。 Foundry Localはこれまでデスクトップ・ラップトップ・IoTデバイス上での小規模言語モデル（SLM）実行を主な用途としていたが、今回からNVIDIAおよびAMDチップを搭載した「ワークステーションクラス」以上のインフラ——エッジやエアギャップ環境を含む——にまで対応範囲を拡大した。これにより、マルチモーダルな大規模LLMをオンプレミスや閉域プライベートクラウド上でオフライン実行できるようになった。 なお、Microsoft独自のAIチップ「Maia 200」についてはFoundry Localでの対応は現時点では予定されていない。Maiaチップはデータセンター内のAzureワークロードに特化して最適化されており、「どこで動いているかを正確に把握できる」精度で制御できるためとのことだ。Foundry LocalはあくまでAMD・NVIDIAエコシステムを中心に展開する方針だ。 規制爆発時代のソブリン要件 MicrosoftのAIインフラ担当GM、アリスター・スピアーズ氏によれば、現在世界では4日に1本のペースでAI・サイバーセキュリティ・データプライバシーに関する新規制が導入されており、69カ国で1,000以上の政策イニシアティブが動いているという。 Satya Nadellaも「あらゆる地域・国でデータ主権の管理をどう確保するかが、今や誰にとっても最前線の課題だ」と明言した。Microsoftはソブリン要件を「パブリッククラウド型主権」「プライベートクラウド型主権」「ソブリンパートナーエコシステム」の3層ポートフォリオとして整理し、顧客がニーズに応じて組み合わせられる設計にしている。 実務への影響——日本のエンジニア・IT管理者が押さえるべきポイント 日本においても、政府・防衛・医療・金融などの分野では「クラウドを使いたいがデータを外に出せない」という制約は根強い。今回のGAはその制約を正面から解決する選択肢となる。 明日から動けるポイントを3つ挙げる： 既存オンプレミス環境の棚卸し: Exchange ServerやSharePoint Serverを「クラウド移行できない負債」として抱えている組織は、2035年サポート延長を前提にAzure Local DisconnectedでAzureガバナンスに統合する設計が現実的な道筋になる。 Foundry LocalをAI PoC環境として評価する: クラウドにデータを送れない機密性の高い業務でも、オンプレミスのGPUラックでLLMを動かせるようになった。まずは社内の検証環境でFoundry Localを試し、どのモデルがどの業務に使えるか感触をつかむのが早道だ。 ソブリン要件をコンプライアンス部門と共に整理する: 「4日に1本」の新規制という環境下では、設計段階からデータ主権・残存場所・アクセス制御の要件を文書化しておかないと後で詰む。Azureのポリシー管理機能を使って制御の証跡を自動で取れる構成にしておくことが、将来の監査対応コストを大幅に下げる。 筆者の見解 Microsoftのソブリンクラウド戦略は、方向性として正しいと思う。AIが実業務に入り込んでいくにつれ、データをクラウドの外に出せない用途は確実に増える。そこに対して「Azureの統合管理はそのまま維持しながら、物理的にはどこにでも置ける」という設計で応えようとしているのは、プラットフォームベンダーとしての強みを生かした正攻法だ。 ただし率直に言うと、AI推論の性能競争という観点ではFoundry Localが対応するモデルの「質」がどこまで上がるかが今後の肝になる。インフラが整うのは大前提として、そこで動くモデルが実際の業務に耐えうる精度を出せるかどうかが問われる。Microsoftには、プラットフォームの整備だけで満足するのではなく、そこで動かせるモデルの選択肢と性能についても手を抜かずに前進してほしい——それができる組織であることは間違いないのだから。 エージェントの管制塔としてのMicrosoft Entra IDと、Foundry Localによるオンプレミス推論の組み合わせは、長期的なアーキテクチャとして筋が良い。日本の大型エンタープライズこそ、この構成を早めに評価しておく価値がある。 出典: この記事は Azure Local Disconnected Generally Available; Foundry Local Supports Large AI Models Offline の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Azure Blob Storageを業務で使っている組織にとって、見逃せないアップデートが正式リリース（GA）された。Microsoft Defender for Storageの「自動マルウェア修復（Automated Malware Remediation）」機能だ。悪意あるファイルを検出した瞬間に自動でソフト削除し、手動対応なしにストレージを清潔に保てる。 何が起きたのか Defender for Storageのマルウェアスキャンは以前から存在していたが、「検出はする、対応は人間」という構図だった。今回GAになった自動修復機能では、アップロード時スキャン（On-Upload）とオンデマンドスキャンの両方で悪意あるBlobが検出されると、即座にソフト削除（Soft Delete）が実行される。 ソフト削除はAzure Blob Storage標準の機能で、削除したデータを一定期間（デフォルト7日、最大365日）保持する。つまり「アクセス遮断」と「証拠保全」が同時に達成できる。 主な仕様 有効化単位: サブスクリプション全体またはストレージアカウント単位で選択可能 Soft Delete未設定の場合: 機能有効化時にDefenderが自動でSoft Deleteを有効にする Blobインデックスタグ: 悪意ありと判定されたBlobには自動でタグが付与され、復元後も追跡可能 コスト: ソフト削除期間中のストレージコストはアクティブデータと同等 なぜこれが重要か 日本のエンタープライズでAzure Storageを使うシーンは多岐にわたる。社内ポータルへのファイルアップロード、Power Automateによる自動処理のステージングエリア、バックアップ先、そして生成AIのRAGデータソース。これらのシナリオではユーザーや外部システムからのBlobアップロードが常時発生し、マルウェア混入のリスクがある。 これまでは「Defenderがアラートを出す→SOCが確認する→削除する」というフローが必要だった。深夜・休日に悪意あるファイルがアップロードされても、翌朝まで誰も動けないというケースは珍しくない。自動修復はその窓を閉じる。 実務への活用ポイント 1. 既存のStorage Account設定を確認する Soft Deleteの保持期間はデフォルト7日だが、コンプライアンス要件やインシデント調査の実績を踏まえて変更を検討する。マルウェアの証跡を30日保持したいなら、Storage AccountのSoft Delete設定で変更しておく。 2. Blob Versioning との組み合わせに注意 Blobバージョン管理を有効にしているStorageアカウントでは、ソフト削除の復元手順が通常と異なる。公式ドキュメント「Manage and restore soft delete for blobs」を事前に確認しておくことを推奨する。 3. サブスクリプション全体 vs アカウント単位 組織内に開発・テスト・本番の複数環境がある場合、テスト環境で誤検知が発生すると全環境で無効化したくなる衝動に駆られる。アカウント単位で有効化できるため、本番環境を優先して適用し、テスト環境は段階的に展開する運用が現実的だ。 4. ログ・アラートパイプラインの見直し 自動修復が動いた場合でも、Defender for Cloudセキュリティアラート・Event Grid・Blobインデックスタグという3つのシグナルが残る。SIEMやAzure Monitor Alertsと連携させることで、「自動で処理されたが、何があったかは把握している」状態を維持できる。 筆者の見解 これは地味だが、実務的な価値が高いアップデートだと評価している。 セキュリティの理想は「人間が関与しなくても安全な状態が維持される仕組み」だ。検出と対応の間に人間のアクションが必要な設計は、その隙間がそのままリスクになる。今回の自動修復は「Non-Human Identityの管理」と同じ文脈で捉えられる——人間のボトルネックを取り除き、システムが自律的に安全を守る方向への一歩だ。 特に評価したいのは、ソフト削除という「後で見直せる」設計にしたことだ。自動的に完全削除してしまうと、誤検知のダメージが大きく、組織が機能を無効化してしまうリスクがある。隔離しつつ復元可能にするアプローチは、セキュリティと運用のバランスとして正しい。 Azure Storageを基盤として使っているのであれば、有効化を検討する理由はほぼない。コスト面でも「Soft Delete期間中のストレージ料金のみ」と明快だ。設定に10分かけるだけで、深夜の悪意あるアップロードに対する自動防衛線が張れる。これがプラットフォームとしてのAzureの強みだと思う。 ...

Azure Synapse Analyticsを本番運用している組織にとって、Microsoft Fabricへの移行はここ1〜2年の最大の課題の一つだ。その移行作業を自動化・アシストする「Migration Assistant for Fabric Data Warehouse」がパブリックプレビューとして公開された。FabCon Atlanta 2026に合わせたタイミングでの世界展開であり、Microsoftが本格的にSynapse→Fabric移行を後押しする姿勢を明確にした格好だ。 Migration Assistantとは何か Migration Assistantは、既存のAzure Synapse Analyticsワークロードを分析し、Microsoft Fabric Data Warehouseへの移行可能性を評価・実行を支援するツールだ。「アセスメントファースト」アプローチを採用しており、いきなり移行作業に入るのではなく、まず既存のスキーマ・クエリ・ストアドプロシージャの互換性を事前チェックする設計になっている。 具体的には以下のフローで動作する： 互換性スキャン — Synapseの既存オブジェクト（テーブル、ビュー、ストアドプロシージャ等）をスキャンし、Fabricで動作するか否かを判定 リスク分類 — 移行困難な箇所を「高リスク／中リスク／低リスク」に分類し、対処方針を提示 移行実行支援 — 互換性のあるオブジェクトから順次移行を進め、問題箇所は修正ガイダンスを提供 SynapseとFabricではT-SQLの実装に微妙な差異があり、これが移行の最大の落とし穴だった。Migration Assistantはその差異を事前に可視化することで、「移行してみたら動かなかった」という状況を減らすことを目的としている。 なぜいまFabricへの移行が重要か MicrosoftはAzure Synapse Analyticsの新機能開発を事実上フリーズし、投資の軸足をMicrosoft Fabricに移している。Synapseが消えるわけではないが、今後の機能強化・AI統合・パフォーマンス改善はFabricが主戦場だ。 Fabricは単なるDWHの後継ではなく、データレイク・データウェアハウス・リアルタイム分析・Power BIレポートを統合した「オールインワン分析プラットフォーム」として設計されている。OneLakeというストレージ統合レイヤーにより、これまでサイロ化していたデータを一元管理できる点が大きな価値だ。日本でもFabricのトライアルや導入が急増しており、Synapse利用組織にとって「いつ移行するか」は避けられない議題になっている。 日本のIT現場への影響 Synapse Analyticsは2019〜2022年頃にかけてデータ基盤刷新プロジェクトで多く採用された。当時のプロジェクトが本番稼働から3〜5年を経て「次の刷新」フェーズに入りつつある今、Migration Assistantの登場は非常にタイムリーだ。 IT管理者・データエンジニアが明日から取れる行動： まず現状把握から始める: Migration AssistantのAssessment機能だけでも先行実施し、自社のSynapse環境の「移行難易度スコア」を把握する。移行計画の根拠データになる ハイリスク箇所を優先的に調査: Assessment結果で高リスクに分類されたオブジェクトは、Fabric側でどう書き直すか早期に技術検証しておく 段階移行戦略の採用: 全ワークロードを一括移行するのではなく、低リスクのテーブルやシンプルなETLパイプラインから段階的に移行してチームのFabric経験値を積む OneLakeの設計を先に固める: 移行先のストレージ設計（ワークスペース分割・レイクハウスvs.ウェアハウスの使い分け）を先に決めておかないと、移行後の再設計コストが高くつく パブリックプレビュー段階であることを念頭に置き、本番移行は正式GA後のロードマップと品質を確認してから判断することを推奨する。 筆者の見解 率直に言えば、「Migration Assistantが必要になる状況」自体、本来は避けられたはずだという思いがある。SynapseからFabricへの移行は、Microsoftの製品戦略の転換に伴ってユーザーが強制される再移行であり、そのコストをユーザーが負担している構図は変わらない。 とはいえ、Microsoftがツールを用意して移行をアシストする姿勢は評価したい。過去にはオンプレSQLServer→クラウドでも似たような移行支援が整備されてきた歴史があり、Microsoftが大規模プラットフォーム移行においてツール整備を怠らない点は信頼できる。 Microsoft Fabricは統合プラットフォームとしての設計思想が明確で、「分析基盤のOneStop化」という方向性は正しい。データレイク・DWH・BIをバラバラのサービスで維持するコスト（金銭的にも運用的にも）は見た目より大きく、統合によって全体最適を得る発想は「道のど真ん中を歩く」選択だと思う。 Migration Assistantが成熟すれば、Synapse資産を持つ企業の意思決定を後押しする重要なピースになりうる。パブリックプレビューの今こそ、自社環境のAssessmentを回してフィードバックを積み重ねる好機だ。Fabricに本腰を入れるMicrosoftには、このツールをGA時にはさらに磨き上げた状態で届けてほしい。 出典: この記事は Public Preview: Migration Assistant for Fabric Data Warehouse (Synapse Analytics → Microsoft Fabric) の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Teams を音声通信インフラとして本格導入している組織にとって、見過ごせないアップデートが届いた。Microsoft Purview のデータライフサイクル管理（DLM）が、Teams の通話ログ（Call Detail Record：CDR）に対する保持・削除ポリシーの適用に対応する。ロールアウトは2026年4月末から開始予定だ。 これまでの「無期限保存」という盲点 Microsoft Teams は通話のたびに CDR ログを生成し、Exchange Online のメールボックス内に保存してきた。問題は、このデータがこれまでデフォルトで無期限に保存されていた点にある。 多くの組織はこの事実をあまり意識してこなかったかもしれないが、法規制の観点では深刻な問題になりえる。日本国内でも個人情報保護法や電気通信事業法の解釈によっては、通話関連ログの保存期間を明示的に定め、一定期間経過後に削除することが求められるケースがある。EU の GDPR や、金融・医療分野の業界規制はさらに厳格だ。「取っているだけ」「消し方がわからない」という状態は、コンプライアンス上のリスクを静かに積み上げていた。 Purview DLM で何が変わるか 今回の対応により、コンプライアンス管理者は Purview の既存のリテンションポリシー機能を使って、Teams 通話ログの保持期間と削除タイミングを明示的に定義できるようになる。 主なポイントは以下のとおりだ。 既存の Purview ワークフローをそのまま活用：新しいツールや管理画面を覚える必要はない。すでに Exchange メールや SharePoint のデータに設定しているポリシーと同じ仕組みで管理できる ユーザーの通話体験には影響なし：バックエンドのデータライフサイクル制御であり、エンドユーザーが気づく変化はない デフォルトの無期限保存が終了：ポリシー未設定の場合の挙動が変わる可能性があるため、「何もしない」は選択肢にならない 実務への影響——IT管理者・コンプライアンス担当者がすべきこと ロールアウト前に最低限やっておきたい準備が3つある。 1. 自社の規制要件を棚卸しする どの規制が自社に適用されるかを確認し、通話ログの保存期間について法務・コンプライアンス部門と合意を形成しておく。業種によっては「3年保存」「5年保存」のルールが存在するため、安易に削除ポリシーを設定しないよう注意。 2. Purview のリテンションポリシーを作成または更新する 機能がロールアウトされたら、Teams 通話ログを対象スコープに含んだポリシーを作成する。すでに Teams チャットや会議ログ向けのポリシーを持つ組織は、それを拡張する形で対応できる。 3. 内部ドキュメントを更新する コンプライアンス担当者や法務チームへの周知が不可欠だ。「Teams の通話ログはいつまで残るか」という問いへの答えが変わるため、ガイドラインや BCP 文書への反映も検討したい。 日本企業への具体的な示唆 国内の大手エンタープライズ企業では、PBX から Teams Phone への移行が進みつつある。その過程で「通話録音は管理しているが CDR ログは把握していない」というケースが意外と多い。CDR ログには発信先番号・通話時間・参加者情報などが含まれており、個人データとして扱うべき情報が混入している可能性がある。 Purview DLM の対応は、こうした「管理の空白地帯」を埋めるうえで素直に歓迎できる進化だ。Purview を既に使っている組織なら、追加コストなしにガバナンスの網を広げられる。 筆者の見解 Purview がカバーする範囲が着実に広がっていることは評価したい。Teams の通話ログは「存在は知っているが誰も管理していない」データの典型例であり、今回の対応でコンプライアンスの穴がひとつ塞がれる。 ...

「保存してから守る」時代が終わる Microsoft PurviewのEndpoint DLP（データ損失防止）に、2026年4月から重要なアップデートが加わった。これまでEndpoint DLPが保護できるのは「ディスクに保存済みのファイル」に限られていたが、新機能によりまだ保存されていない状態のファイルに対しても、印刷・外部転送などのエグレス（流出）アクティビティを検知・ブロックできるようになった。 これは地味に見えて、実は相当大きな変化だ。 何が変わるのか 従来の限界 これまでのEndpoint DLPは「ファイルが保存されたタイミング」からしか保護を開始できなかった。つまり、ユーザーがWordやメモ帳で機密情報を入力し、保存する前にスクリーンショット印刷やクラウドストレージへドラッグした場合、DLPポリシーが発動しないという抜け穴が存在していた。 新機能の仕組み 新しい「未保存ファイルへのDLP保護」が有効になると、ポリシーの評価がファイル書き込みより前の段階から始まる。具体的には以下の2つの制御が可能になる： 監査モード: 未保存ファイルの印刷・転送アクティビティをログに記録する ブロックモード: 未保存ファイルの印刷・転送アクティビティを実際に遮断する 有効化の条件 この機能はデフォルトでは無効であり、管理者が明示的に設定する必要がある。また、対象デバイスが以下の要件を満たしていることが前提となる： マルウェア対策クライアント バージョン 4.18.26020 以降が稼働していること Microsoft PurviewのコンプライアンスポータルからEndpoint DLPが構成済みであること 既存のDLPポリシーは変更なくそのまま動作する。新設定を追加した場合のみ挙動が変わる。 実務への影響——IT管理者が今すぐやること 1. デバイスのクライアントバージョン確認 まず社内エンドポイントのマルウェア対策クライアントが 4.18.26020以降であることを確認しよう。Microsoft Defender for Endpointの管理コンソール、またはIntune経由でデバイスコンプライアンス状況を一括確認できる。古いバージョンのデバイスは今回の機能が適用されないため、展開ロードマップに組み込む必要がある。 2. 既存ポリシーの見直し 既存のEndpoint DLPポリシーが「どのシナリオをカバーしていたか」を棚卸しし、今回の「未保存ファイル制御」を有効化すべきユースケースを洗い出す。特に、以下の業務シーンは優先的に検討を推奨する： 個人情報・機密情報を扱うアプリケーション（医療・金融・人事系） 外部転送リスクが高い部門（営業・経営企画等） BYODや共用PCが混在する環境 3. まずは監査モードで運用開始 いきなりブロックモードを有効化すると業務影響が出る可能性がある。最初は監査モードで運用し、ログを分析してから徐々にブロックモードへ移行するフェーズドアプローチが無難だ。 4. ヘルプデスク・社内周知 ブロックモードを有効化した場合、ユーザーが「ファイルを保存もしていないのに印刷できない」という体験をすることになる。混乱を防ぐため、事前に社内アナウンスと問い合わせ窓口の準備が必要だ。 筆者の見解 「保存前のファイル」に対してDLPを効かせるというのは、セキュリティの時間軸を根本から変える取り組みだ。従来型のDLPは「データが定着してから守る」という発想だったが、今回の機能は「データが生まれた瞬間から守る」という方向に踏み込んでいる。これはゼロトラストの思想——「アクセスを許可したあとも継続的に評価する」——のエンドポイント版とも言える。 個人的に注目しているのは、この機能がNHI（Non-Human Identity）や自動化フローとの相互作用だ。RPA・マクロ・スクリプト類が「未保存の一時ファイル」を経由してデータを移送するパターンは珍しくない。今回の機能がそういった自動化プロセスをどう扱うか、ポリシー設計次第では意図せず業務自動化を止めてしまうリスクもある。展開前にテスト環境での検証を強く勧めたい。 Microsoft Purviewはここ数年でコンプライアンス基盤としての完成度を着実に高めている。今回のアップデートもその延長線上にあり、正しく設計・運用すれば実際の情報漏洩リスクを大きく下げられる。デフォルトがオフになっていることから、運用インパクトへの配慮も感じられる。あとは管理者側がこの機能をどれだけ迅速に実戦投入できるか——機能があっても使われなければ意味がない。ぜひ積極的に活用してほしい。 出典: この記事は Microsoft Purview compliance portal: Enforce DLP protection on new content before it’s saved - M365 Admin の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 Copilotの宣言型エージェント（Declarative Agents）に、まとめて3つの大きなアップデートが降ってきた。なかでも注目すべきはMCP Appsのサポートだ。2026年4月7日に正式アナウンスされたこの機能は、Copilotチャットの性格を根本から変える可能性を持っている。 何が変わったのか——3つの制約が同時に崩れた これまでの宣言型エージェントには、開発者なら誰でも痛感してきた3つの壁があった。 テキスト応答しかできない 知識ソースがSharePoint・OneDrive・一部URLなどに限定されている 開発ループがポータルとJSONとエディタをまたぐ煩雑なもの 今回のアップデートはこの3つを一気に崩した。MCP Appsが「壁その1」を、埋め込み知識（Embedded Knowledge）が「壁その2」を、Microsoft 365 Agents Toolkitの新プラグインが「壁その3」をそれぞれ解決する構成だ。 MCP Appsとは何か——チャットの中に「生きたUI」を置く Model Context Protocol（MCP）は、もともとAIクライアントとサーバー間でデータをやり取りするための仕様として広まった。その拡張として最近追加されたのが、データだけでなくフルUIもクライアント側に返せる仕組みだ。 Copilotではこれに対応した形式が2種類サポートされている。 MCP Apps：MCPの仕様を拡張したもの OpenAI Apps SDK：OpenAIが同時期にリリースした同様の仕組み 実際にどう見えるかというと、チャット内に「経費承認フォーム」「プロジェクトステータスダッシュボード」「並列ドキュメント比較ビュー」といったインタラクティブなUIが出現する。リンクではない。カードでもない。ユーザーが操作できるライブな作業面がそのままチャットの中に埋め込まれる。 表示モードは2種類ある。 モード 特徴 用途例 インライン（Inline） モデルの応答より前に表示される軽量ウィジェット 承認フロー、クイック確認、プルリクレビュー サイドバイサイド（Side-by-side） メインエリアを占有する没入型ワークスペース 複数ステップの編集作業、レイアウト確認、比較作業 インラインモードはチャットの流れを邪魔しない軽い操作に向いており、サイドバイサイドはCopilotチャットを横に追いやって「本格的な作業台」として使う構成だ。 開発者にとって重要な設計上のポイント この機能設計で評価したいのは後方互換性だ。UIコンポーネントはMCPレスポンスのmetaプロパティに乗せる形で追加され、既存のMCPサーバー実装を壊さない。認証・インテグレーション・既存ロジックはそのままに、UI層だけを後乗せできる。 過去のMicrosoftが得意としてきた「壊さずに積む」設計の良い例だ。既にエージェントを本番運用している開発者にとっては、リアーキテクチャなしで対応できる点がありがたい。 ローンチパートナーにはAdobe Express・Coursera・Figma・monday.comといった名前が並び、Outlookの作成・スケジュール機能も対象に含まれる。4月中旬からMicrosoft 365 Agent Storeに順次登場する予定だ。 実務への影響——IT管理者・エンジニアが押さえるべきこと エージェント開発者向け 既存のMCPサーバーがある場合、metaプロパティにUI定義を追加するだけで対応可能。フルリライトは不要 インラインとサイドバイサイドの使い分けを先に設計してから実装に入ると無駄が少ない 承認フロー系の業務（稟議・経費・購買）は即座にユースケースの候補になる IT管理者向け Copilotチャット内で「アプリが動く」体験が始まることで、ユーザーのCopilot利用時間が増加する可能性がある。ガバナンスポリシーの見直しが必要になるかもしれない Agent Storeからインストールされるサードパーティエージェントの管理方針を今から整備しておくと後が楽になる Adobe Express・Figmaといったクリエイティブ系ツールとのCopilot統合が進むことで、M365の外にあったワークフローが内側に取り込まれる流れが加速しそうだ 筆者の見解 Copilotがテキスト応答の外に出始めたこと自体は、正直なところ歓迎したい変化だ。チャットで返ってくるのが文字だけというのはいつまでも「頭のいい検索」の域を出られず、業務ツールとして本当の意味で使いものになるには、これくらいのUIリッチ化は必要だった。 ただ、率直に言えば「遅い」という感想も拭えない。チャット内に作業UIを持ち込むというコンセプト自体は技術的に新しいわけではなく、それが2026年春にようやく宣言型エージェントで使えるようになったというのは、Microsoftが持っているブランドと開発者コミュニティの規模を考えると、もったいないスピード感だ。 とはいえ、ここで重要なのは「後方互換を保って積み上げた」という実装の筋の良さだ。この設計判断は正しい。Microsoftが本気でエコシステムを育てようとするなら、既存投資を無駄にさせないアーキテクチャが不可欠で、その点は今回しっかりやりきっている。 MCPという業界共通の仕様をベースに据えたことも長期的には有利に働くはずだ。独自規格に閉じず、OpenAI Apps SDKも並列サポートする姿勢は、エコシステムの裾野を広げる上で現実的な判断だと思う。 日本のM365環境でCopilotを展開している企業には、まずはAdobe ExpressやFigmaといった既導入ツールとのインテグレーションを試しにいくのが最初の一手として手堅い。承認フロー系の業務をインライン対応させるだけでも、「Copilotを開かない理由」が一つ減る。それが積み重なると、利用定着率の数字は変わってくる。 Copilotが実力を発揮できる土台が少しずつ整ってきたのは確かだ。この方向性でのアップデートが続くことを期待したい。 出典: この記事は M365 Copilot Declarative Agents: What’s New April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AI推論の速度競争が新たな局面を迎えている。シリコンバレー発のAIチップスタートアップ、Cerebras Systemsが2026年4月、米証券取引委員会（SEC）に上場申請書を提出した。同社はかつて2024年にも上場を試みたが、アブダビ系投資ファンドG42からの出資をめぐる連邦審査によって申請を取り下げた経緯がある。今回の再挑戦は、AWSおよびOpenAIとの大型契約という強力な追い風を受けてのものだ。 Cerebrasとは何者か——ウェーハースケール統合という異端の発想 一般的なAI用GPU（例：NvidiaのH100）は、数センチ角のダイをパッケージングした構成をとる。一方、Cerebrasが採用するのは「ウェーハースケール・エンジン（WSE）」と呼ばれる設計で、シリコンウェーハ1枚まるごとを単一チップとして使用する。ダイ間の通信遅延を排除し、きわめて高いメモリ帯域幅を実現することで、特に推論（インファレンス）フェーズにおける速度で際立った性能を発揮する。 CEOのアンドリュー・フェルドマン氏は、この優位性をこう表現した。「OpenAIの高速推論ビジネスをNvidiaから奪った」——挑発的な言い回しだが、実態を伴う発言だ。 資金調達と財務の現状 直近の資金調達では、2025年にシリーズGで11億ドル、2026年2月にはシリーズHで10億ドルを調達し、評価額は230億ドルに達した（Wall Street Journal報道）。 2025年通期の売上高は5億1,000万ドル。GAAPベースの純利益は2億3,780万ドルと黒字計上だが、一時的項目を除いた非GAAPベースでは7,570万ドルの純損失となる。スタートアップとしては異例なほど大きな売上規模であり、事業の実態は着実に育っている。IPOでの調達希望額は未公表。上場は5月中旬を計画している。 AWSとOpenAIとの契約が示す意味 今回の申請で注目すべきは財務数値だけではない。AmazonのクラウドインフラAWSがCerebrasチップをデータセンターに採用する契約、そしてOpenAIとの総額100億ドル超とされる契約の2件は、市場構造に対するシグナルとして重要だ。 AWS・Azure・Google Cloudといった大手クラウドは、Nvidiaへの依存度を下げるべく複数のAIチップ調達先を探している。Cerebrasはその候補として本命に浮上した。AIハードウェアの独占状態に変化が生じ始めたと見ていい。 実務への影響——日本のエンジニア・IT管理者が押さえるべきこと クラウド経由のアクセスが現実的な選択肢に: Cerebrasのチップを直接購入・運用するのは現状、大規模データセンターを持つ事業者に限られる。しかし、AWSを通じた利用が可能になれば、日本のエンジニアもAWSコンソールからCerebras推論エンドポイントにアクセスできる日が来る可能性がある。現時点でAWS上の提供形態の詳細は未公開だが、動向を注視しておく価値は十分ある。 推論速度が要件になるユースケースを洗い出す: トークン生成速度が速いほど有利なシナリオとして、リアルタイム音声対話、大量文書の一括処理、自律的なループ実行（エージェント処理）などが挙げられる。現在のワークロードでレイテンシがボトルネックになっているかどうか、今のうちに確認しておくと判断材料が増える。 Nvidiaの代替を検討するタイミング: Nvidiaが市場を支配していることに変わりはないが、調達リスクの観点から複数ベンダー体制を検討している企業にとって、CerebrasのIPOは市場の選択肢が広がるサインだ。 筆者の見解 Cerebrasの上場申請を見て率直に思うのは、AIの速度競争がハードウェア層でも本格化してきたという事実だ。 AIエージェントが自律的に判断・実行・検証を繰り返すループ（いわゆるハーネスループ）を設計するとき、推論速度の遅さは直接的な制約になる。トークン生成に時間がかかるほど、エージェントが一周するのに時間がかかる。速いチップはそれだけでエージェントの設計自由度を広げる。Cerebrasが「高速推論」を軸に据えているのは、この潮流と正確に合致している。 一方で、23億ドルの評価額と、GAAPベースでは黒字に見えるが非GAAPでは赤字という財務構造には冷静な目が必要だ。主要顧客がOpenAI・AWSに集中しており、契約が一部でも想定と違う結果になれば業績への影響は大きい。IPO後の株価形成は、こうした集中リスクをどう織り込むかにかかっている。 Nvidiaというインフラ独占企業に真正面から挑む企業が実際に大型契約を取り、黒字ベースの売上を積んでIPOを迎える——これが現実になっていること自体、AI時代のハードウェア市場が固定化されたものではないことを示している。日本のIT現場でも、AIが当たり前のインフラになっていくにつれ、どのチップ・どのクラウドで推論するかは、コストとパフォーマンスに直結する選択になっていく。今のうちに自分のユースケースと照らし合わせて整理しておくことをお勧めしたい。 出典: この記事は AI chip startup Cerebras files for IPO の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIインフラの需給バランスが急速に崩れている。GPU価格の急騰、大手プロバイダーによるアクセス制限——「誰でも使えるAI」という前提が、静かに、しかし確実に書き換えられようとしている。 GPU価格が2か月で48%上昇という現実 Nvidiaの最新アーキテクチャ「Blackwell」搭載GPUのクラウドレンタル価格が、2026年4月時点で1時間あたり$4.08に達した。わずか2か月前の$2.75から48%の急騰だ。大手クラウドGPUプロバイダーのCoreWeaveはさらに価格を20%引き上げ、最低契約期間を従来の1年から3年に延長した。 この状況を象徴するのがOpenAIのCFO、Sarah Friar氏の発言だ。「今この瞬間も、コンピュートが足りないために追求できていないものがある。非常に厳しいトレードオフを迫られている」——世界最大規模のAI企業のCFOがこう言わざるを得ない状況は、問題の深刻さを如実に示している。 アクセスが「特権」になりつつある Anthropicは最新モデルへのアクセスをわずか約40組織に限定していると報じられている。最先端モデルは「誰でも使えるAPI」ではなく、戦略的パートナー向けの限定リソースになり始めているのだ。 この流れを踏まえ、AI業界リサーチャーのTom Tunguz氏は「コンピュート不足時代」を定義する5つの特徴を整理している。 1. リレーションシップ・ベースの販売へ 最先端モデルは誰にでも開かれた存在でなくなりつつある。プロバイダーにとって最も収益性が高い、あるいは戦略的に重要な顧客が優先される。 2. AI資源は「最高入札者」のもとへ 大規模な資本調達や高い収益性を持つ企業が有利になる。資金力がAI活用の質を左右する時代が来る。 3. 「使えるが遅い」状態の常態化 アクセスできたとしても、応答速度の保証はない。レイテンシが業務の質に直結するユースケースでは深刻な問題になりえる。 4. インフレする「AIコモディティ」 需要が複利的に伸び続ける一方で供給の伸びには限界がある。AIのコストが経営上の重要指標として浮上する。 5. 強制的な分散化 開発者はより小さなモデルやオンプレミスデプロイに目を向けざるを得なくなる。エネルギーインフラとデータセンター整備が追いつくまで、この状況は数年単位で続く可能性がある。 日本のIT現場への影響 この状況は、日本のエンジニアやIT管理者にも直接影響する。特に意識しておきたいポイントが3つある。 コスト管理を「後回し」にしない これまで「とにかく使ってみる」フェーズだったAI利用が、確実に「コストとROIを意識する」フェーズに移行する。API呼び出しのトークン最適化、モデルの使い分け（高精度タスク vs 軽量タスク）、キャッシュ戦略の導入を今から習得しておきたい。 単一プロバイダー依存リスクの再評価 アクセス制限や価格変動リスクを考えると、特定のモデルやプロバイダーに依存した設計は危うくなる。ローカルLLMの活用も含めたマルチモデル戦略を検討する価値が高まっている。 調達・契約の長期視点 CoreWeaveが示したように、AI計算資源の契約は「必要なときに買う」から「戦略的に確保する」へとパラダイムが変わりつつある。企業のIT調達担当者は、AI計算資源を従来のクラウドリソースとは異なる視点で扱う必要がある。 筆者の見解 正直に言えば、この「コンピュート不足」は驚きではない。2024年から2025年にかけての爆発的なAI需要の拡大を見ていれば、インフラ側がいつか追いつかなくなる日は来ると思っていた。問題は「いつ」ではなく「どう対応するか」だ。 今この瞬間に最も価値があるのは、計算資源の量ではなくそれを効率的に使いこなすノウハウだと思っている。潤沢に使えた時代に「とにかく投げてみる」使い方を続けていた組織と、タスク設計・プロンプト構造・エージェント設計を真剣に磨いてきた組織とでは、リソースが制約される時代に決定的な差が出る。 自律的に判断・実行・検証を繰り返すエージェント設計——このアーキテクチャへの理解と実装経験が、今後のAI活用の核心になると確信している。人間が逐一確認・承認する設計では、計算資源が貴重になればなるほど投資対効果が下がる。適切な粒度でエージェントに判断を委ねる設計こそが、コンピュート不足時代を生き抜く鍵だ。 データセンターの建設やエネルギーインフラの整備には時間がかかる。Tunguz氏の言う通り「数年単位」という見通しは現実的だ。この期間を「制約の中でどれだけ高度な使い方を習得できるか」の鍛錬期間として捉えたい。日本のIT現場がAI活用の実力を本当に問われるのは、むしろこれからだ。 出典: この記事は The beginning of scarcity in AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ソフトウェア開発の世界でAIエージェントの実用化が加速する中、ハードウェア設計の領域にも本格的な波が押し寄せてきた。エンジニアのLucas Geradts氏が公開したデモが、Hacker Newsで100ポイント超の注目を集めている。オシロスコープとSPICEシミュレーターをAIエージェントに直接接続し、「シミュレーション→実機測定→検証」のループを自律的に回す——その仕組みが明快で、かつ拡張性に優れているという点が評価されている。 MCPサーバーがハードウェアとAIを繋ぐ Geradts氏が構築したのは2つのMCPサーバーだ。 lecroy-mcp: LeCroy製オシロスコープを制御するMCPサーバー spicelib-mcp: SPICEシミュレーター（spicelib）をラップするMCPサーバー MCP（Model Context Protocol）はAIエージェントが外部ツールやデータソースと通信するための標準プロトコルだ。これまではファイルシステム、ブラウザ、APIなどへの接続が主流だったが、今回は物理的な測定機器までその対象を広げた。 デモの流れはシンプルだ。AIエージェントがSPICEシミュレーターでRCフィルター回路を解析し、その結果をもとにマイコン（MCU）のコードを生成してビルド・フラッシュ。実際の回路からオシロスコープで波形を取得し、シミュレーション結果と照合する。これがすべて自律的に行われる。 「自然言語で回路を指定する」より賢いアプローチ Geradts氏が強調する重要な気づきがある。「AIエージェントに自然言語で回路を書かせる」アプローチは、単純な回路なら機能するが複雑になると途端に難しくなる。問題は自然言語で設計意図を正確に伝えることの難しさだ。 そこで氏が選んだのは、AIエージェントに「ツール」を渡してフィードバックループを形成するという方針だ。エンジニアが回路設計の意図を持ち、エージェントはシミュレーションと測定を通じて検証と調整を繰り返す。これはソフトウェア開発でエージェントにビルドツールやテストランナーを渡す構成と本質的に同じ発想だ。 実践から得た設計上の教訓 デモを通じてGeradts氏が得た知見は、実際にこの構成を試みるエンジニアにとって価値が高い。 オシロスコープ接続の注意点 エージェントは物理的な接続を「見ていない」。どこに何が繋がっているかを明示的に伝えること 古いデータをキャッシュさせない設計にすること（測定のたびに必ずフレッシュなデータを渡す） 生データをコンテキストに直接流し込まず、ファイルに保存してエージェントが間接的に参照する形にする マイコン制御の注意点 ピンアサインやピンマックスの情報を明示的に渡す build、flash、ping、erase などの操作をMakefileにまとめ、エージェントがそれを呼び出す形にする。コマンドをその場で生成させない これらの教訓の根底にある原則は明快だ。エージェントに「推測」させるな、「確認できる仕組み」を渡せ。 実務への影響——日本の組み込みエンジニアへ 日本の組み込み開発・ハードウェア設計の現場にとって、このアプローチは見過ごせない。 SPICEシミュレーションと実機検証の往復は、経験豊富なエンジニアでも時間を要するプロセスだ。特にデータ整理（時間軸の正規化、複数チャンネルのアライメントなど）は氏自身が「目分量でごまかしていた」と述べるほど煩雑な作業だ。AIエージェントにこのデータ解析を任せることができれば、エンジニアはより高次の設計判断に集中できる。 明日から試せることとしては： 既存のSPICEシミュレーター環境にMCPサーバーを被せることから始める（lecroy-mcpやspicelib-mcpのコードはOSSとして公開済み） Makefileで操作を抽象化する習慣はAIエージェントがいない環境でも再現性向上に効く 「自然言語で設計を指示する」より「検証ループに組み込む」発想のシフトを意識する 筆者の見解 このデモが示したことは、AIエージェント活用における本質的な原則の実証だと思う。 フィードバックなきエージェントは機能しない。 これはソフトウェアでも、ハードウェアでも変わらない。エージェントがリアルな環境から測定データを受け取り、それをもとに次の判断を下し、また測定する——このループを設計できているかどうかが、エージェント活用の成否を決める。 今回のアプローチが特に優れているのは、物理世界との接点をMCPという標準プロトコルで設計している点だ。オシロスコープが変わっても、シミュレーターが変わっても、エージェント側のロジックはほぼそのまま使える。この抽象化のレイヤーが、スケールを可能にする。 ハードウェアエンジニアリングの世界に「自律検証ループ」が根付き始めれば、設計の反復速度は根本から変わる。「試して、測って、直して、また試す」というサイクルがAIによって高速化されるとき、エンジニアに求められるスキルも変容する。測定自体より、検証ループを正しく設計する能力——これが次に問われる力だろう。 まだ実験段階ではあるが、この方向性は正しい。ハードウェア開発者には、ぜひ自分の環境でこのアーキテクチャを試してほしい。 出典: この記事は Show HN: SPICE simulation → oscilloscope → verification with Claude Code の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが自律的にWebを巡回し、情報を取得し、APIを呼び出し、場合によっては決済まで行う時代が現実のものになりつつある。そうした「エージェントネイティブなWeb」に自分たちのサイトがどれだけ備えているかを5カテゴリで即座に診断してくれる無料ツール「Is It Agent Ready?」が公開され、Hacker News上で100点超のスコアを獲得し注目を集めている。 AIエージェントが求める「新しいWeb標準」とは 従来のWebは「人間が目で見てクリックする」前提で設計されてきた。しかしAIエージェントが自律的に動くようになると、その前提が根本から崩れる。 「Is It Agent Ready?」が診断する5カテゴリは、この新しい前提への対応状況を測るものだ。 1. 発見可能性（Discoverability） robots.txt、サイトマップ、Linkレスポンスヘッダーを確認する。AIエージェントが「どこに何があるか」を理解するための基礎インフラだ。 2. コンテンツアクセシビリティ（Content Accessibility） Markdownコンテンツネゴシエーションの対応状況を確認する。AIはHTMLよりMarkdownの方がはるかに処理しやすく、APIとしてtext/markdownを返せるかどうかが問われる。 3. ボットアクセス制御（Bot Access Control） robots.txt内のAIボット固有のルールやWebボット認証（Web Bot Auth）などを確認する。「誰に何を許可するか」を明示的にコントロールできているかの問題だ。 4. プロトコル発見（Protocol Discovery） MCP（Model Context Protocol）サーバーカード、エージェントスキル、WebMCP、OAuthディスカバリーなど、エージェントが「このサービスをどう使うか」を自動的に発見するための仕組みが整っているかを確認する。 5. コマース（Commerce） x402、UCP、ACPといった新興のエージェント決済プロトコルへの対応状況を確認する。エージェントが人間の介在なしに決済を行うための新世代プロトコルだ。 まず何から手をつけるべきか ツールが「最も簡単な改善策」として挙げているのは以下の2点だ。 AIボットルールを含む有効なrobots.txtを公開する: どのAIクローラーに何を許可・禁止するかを明示する サイトマップと発見ヘッダーを整備する: エージェントがサイト構造を効率的に把握できるようにする この2点は既存のWebサイトでも数時間以内に対応可能なレベルだ。 実務への影響 日本のIT現場では「エージェント対応」という観点でWebサービスを整備するという発想はまだ一般的ではない。しかし現実には、AIエージェントを使ってWebブラウジング・情報収集・自動処理を組む実装が増えている。その際、「エージェントが扱いやすい設計」になっているかどうかが情報収集の精度や自動化の成否を左右する。 IT管理者・エンジニアへの具体的なアクション： 自社サイトとAPIを今すぐ診断ツールでスキャン: 現状把握が第一歩 robots.txtのAIボットポリシーを整備: 公開情報は積極的に開放し、非公開情報は適切に制限する MCPサーバーの導入検討: 自社サービスをAIエージェントから呼び出せるAPIとして整備することで、将来のエージェントエコシステムへの参加が容易になる 社内システムのエージェント対応ロードマップを策定: 今すぐすべてに対応する必要はないが、方向性を持って整備を進める 筆者の見解 MCPサーバーカード、エージェントスキル、x402決済——これらは現時点では「尖った人だけが使うもの」に見えるかもしれない。だがrobots.txtがかつてSEOの基礎として普及したように、これらもいずれWebの当たり前になる可能性が高い。 日本の開発チームに特に意識してほしいのは「Markdown対応」だ。日本語コンテンツをAIが処理する際、HTMLタグが混在した状態より構造化されたMarkdownの方が圧倒的に扱いやすい。コンテンツのAPIをMarkdownで返せる設計にしておくことは、将来のエージェント連携を容易にする地味だが重要な投資となる。 エージェントが自律的に判断・実行・検証を繰り返すループ構造こそが次のフロンティアだとすれば、そのエージェントが「使いやすい」Web環境を整備することは提供側の責任でもある。自社サイトをまだ診断していないなら、今日中にスキャンしてみてほしい。現状を知るだけでも、次の打ち手が見えてくるはずだ。 出典: この記事は Scan your website to see how ready it is for AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIコーディングツールが標準装備となりつつある今、あえて3ヶ月間「手書きコーディング」に立ち返った開発者の実験記録がHacker Newsで大きな反響を呼んでいる（スコア324点、315コメント）。AIエージェント構築の最前線にいた人物だからこそ気づいた、コーディングの本質的な価値とは何か。 「AIの時代」にあえて逆張りした理由 Barcelonaのスタートアップ・Aily Labsで2年間AIエージェントを構築してきたMiguel Conner氏は、2026年3月にニューヨーク・ブルックリンのRecurse Center（RC）というプログラミングリトリートに参加した。RCは無料で6〜12週間、自由にプログラミングに集中できる環境で、多様なバックグラウンドを持つ参加者とのコラボレーションが特徴だ。 Conner氏はCursorをいち早く採用し、DeepSeek R1やMeta Llama 3の論文を輪読してきたAIヘビーユーザーである。そんな彼が「AIをほぼ使わずに」コーディングに集中する時間を取ったのはなぜか。 手書きコーディングで実は「2つのことを同時に」やっていた Conner氏が気づいたのは、手書きでコードを書くとき、実は二つのことを並行してやっているということだ。 「何を書きたいかを明確化する」 ── 目的の言語化 「コードベースを学ぶ」 ── 理解の深化 AIコーディングエージェントを使うと、プロンプトに書いた通りのコードは確かに生成される。しかし「何を書きたいかが曖昧なまま」指示を出すと、エージェントが多くの仮定を自動的に埋める。コードは動くが、自分がそのコードベースを深く理解しているとは言いにくい状態が生まれやすい。 これは生産性書籍『Deep Work』で知られるコンピュータサイエンス教授Cal Newportが指摘する「思考の筋トレ」の喩えとも重なる。明確なメモや報告書を書く苦労はアスリートのジムトレーニングに相当し、排除すべき「面倒」ではなく、その仕事の本質的なスキルだという視点だ。コーディングも同じで、その「苦労」の中に学びがある。 「すごいAIユーザー」は「すごいプログラマー」でもあった Conner氏が職場で気づいた、もう一つの重要な観察がある。彼の職場で「すごいプログラマー」だった人たちは、同時に「すごいAIユーザー」でもあったというのだ。 深い技術知識があるからこそ、AIツールを高度にレバレッジできる。逆に言えば、基礎的な理解が薄いまま「AIに任せる」を繰り返すと、AIの出力を正しく評価する力も育ちにくい。AIは優秀なチューターにもなり得るが、学習者側に問いかける力がなければ、その恩恵は限られる。 実務への影響——日本の開発現場で考えること AIコーディングツールが日本の開発現場にも急速に普及している今、このアプローチにはいくつかの実践的な示唆がある。 コードレビューの質が問われる時代 AIが生成したコードをレビューする際、「なぜこの実装になっているか」を理解できなければ、バグや設計上の問題を見逃すリスクが高まる。生成コードを「承認するだけ」のレビューは形骸化しやすい。 新しいコードベースへのオンボーディング 既存プロジェクトに参加するとき、AIに「全部やってもらう」と理解が追いつかない場面がある。意図的に手書きで追いかける時間を部分的に設けることで、コードベースへの理解が速まるケースもある。 生産性と学習のバランス設計 チームとして「速く出す」と「深く学ぶ」を意識的に設計することが、長期的な技術力の維持につながる。特に若手エンジニアの育成方針は、今一度見直す価値がある。 筆者の見解 この記事を読んで「やっぱり手書きが大事、AIは使いすぎ注意」という結論に飛びつくのは少し早計だと思う。 Conner氏の本質的な気づきは「AIを使うな」ではなく、「AIを高度に使いこなす力の正体は、深い技術理解だ」という点にある。これは重要な観察で、「AIがあれば誰でも同じ成果が出る」という誤解を解いてくれる。 筆者が大切だと感じるのは、「何をAIに任せ、何を自分で理解すべきか」という設計力だ。AIエージェントが自律的に動き続ける仕組みを構築できる人の価値は今後さらに高まるが、その仕組みを正しく設計するには、中で何が起きているかを把握している必要がある。 Conner氏のリトリートは、その「把握する力」を鍛えるための意図的な投資だ。情報を追いかけ続けるより、実際に手を動かして深く理解する経験を積む——この姿勢は、AIの進化が速い今だからこそ、むしろ価値が増している。 表面的な操作スキルよりも「何が起きているかを理解する力」こそが、AI時代の技術者としての真の競争力になる。それはAI礼賛でも手書き回帰でもなく、両者を使い分けられる「設計力」の話だ。 出典: この記事は I’m spending months coding the old way の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ファイルエクスプローラーで「ダウンロードフォルダーを特大アイコン表示に設定したのに、Edgeから『フォルダーを開く』で開くと詳細表示に戻っている」——この現象に何年も悩まされてきた方は多いはずだ。Microsoftがついにこの長年の挙動を修正した。Build 26200.8313（KB5083631）がRelease Previewチャンネルに展開され、フォルダービューの一貫性が大きく改善された。 何が変わったのか 今回の修正により、ファイルエクスプローラーで設定したフォルダービューの設定——並び順、グループ化の有無、アイコンサイズ、レイアウト——が、フォルダーの開き方にかかわらず維持されるようになった。 これまでの挙動では、ファイルエクスプローラー上で「名前順・グループ化なし・特大アイコン」と設定したダウンロードフォルダーを、ブラウザや別のアプリから「フォルダーを表示」で開くと、設定が別の状態に戻ってしまうことがあった。毎回手動で直すのが当たり前になっている人も少なくないだろう。 なぜ今まで直らなかったのか 技術的な背景として、ファイルエクスプローラーはフォルダービューの設定を「Shell Bags」と呼ばれるレジストリの仕組み（BagsキーおよびBagMRUキー）に保存している。この設定は「フォルダーそのもの」ではなく、「どの経路でそのフォルダーにアクセスしたか」に紐付けられている点が問題だった。 ファイルエクスプローラー上から直接開く場合と、別のアプリから「Show in folder」などのシェル呼び出しで開く場合では、Windowsが内部的に異なるシェルコンテキストとして扱うことがあった。その結果、同じフォルダーでも異なる「Bag」が参照され、ビュー設定が食い違う——これが根本的な原因だ。バグではなく設計上の限界だったわけで、修正に時間がかかったのも納得できる。 その他の改善点 KB5083631にはビュー一貫性の修正以外にも実用的な改善が含まれている。 起動パフォーマンスの向上: エクスプローラーの立ち上がりが高速化 ダークモードの白フラッシュ軽減: 長年報告されていたダークモード時の一瞬の白画面が改善 対応アーカイブ形式の追加: uu、cpio、xar、nupkgが新たにサポート explorer.exe の安定性向上: ウィンドウを閉じる際の信頼性が改善 なお、モダンな検索バーのUIリニューアルはCanaryビルドで先行テスト中であり、正式展開時期は未定だ。 実務への影響 日常的にエクスプローラーを使う一般ユーザーはもちろん、複数のアプリケーション間でファイル操作を行う機会が多い開発者・エンジニアにとっても恩恵は大きい。 特に以下のシナリオで差を実感しやすい： ダウンロードマネージャーや開発ツールからのフォルダー参照: IDEやビルドツールの「出力フォルダーを開く」ボタン経由でエクスプローラーを開いても、設定通りのビューが保たれる 複数ウィンドウ・マルチタスク環境: 異なるアプリから同じフォルダーを開くたびにビューが変わるストレスがなくなる チームへの展開: 標準化したフォルダービューが意図した通り保持されるようになり、操作手順書やサポート対応が簡略化できる可能性がある Release Previewチャンネルでの提供が始まったことから、2026年5月中には通常のWindows 11環境への展開が見込まれる。企業環境で急いで適用する必要はないが、動作確認の優先度は低くて構わないだろう。 筆者の見解 正直に言えば、Windowsをかつてのように細かく追いかける意味は薄れてきている。しかし今回の修正は、地味ながら「これを直してほしかった」という声が長年上がり続けていたものだ。技術的にはShell Bagsの設計に起因する根深い問題だっただけに、修正コストは決して小さくなかったはずで、その判断と実行は素直に評価したい。 この種の「細かいけれど毎日引っかかるUI改善」は、Microsoftが本来得意としてきた領域だ。派手な新機能だけでなく、こういった積み重ねがプラットフォームとしての信頼につながる。正面から勝負できる地力はMicrosoftには間違いなくある。基本体験を着実に磨いてほしい——そう思う。 なお、「ちょっと様子を見てから適用する」判断も依然として有効だ。Windows Updateは数日待ってから適用する慎重さが、結果的にリスクを下げることも多い。焦って当てる必要はない。 出典: この記事は Windows 11 finally fixes inconsistent folder views in File Explorer の内容をもとに、筆者の見解を加えて独自に執筆したものです。

JavaScriptエコシステムの根幹を担うライブラリに、見過ごしてはいけない重大な欠陥が発見された。npmで週平均約5000万回ダウンロードされる protobuf.js に、任意コード実行（RCE）を可能にする脆弱性が存在することが明らかになった。しかもPoC（概念実証コード）はすでに公開されており、攻撃の敷居は決して高くない。 protobuf.jsとは何か Protocol Buffers（Protobuf）はGoogleが開発したバイナリシリアライズ形式で、マイクロサービス間通信やリアルタイムアプリ、クラウド環境でのデータ格納に広く使われている。protobuf.js はそのJavaScript/TypeScript実装であり、Node.jsベースのバックエンドや各種クラウドファンクションに深く組み込まれているケースが多い。「使ってるつもりのないライブラリ」として依存関係の奥底に潜んでいることも珍しくない。 脆弱性の仕組み 今回の脆弱性はGitHub Security Advisory ID GHSA-xq3m-2v4x-88gg として追跡されている（CVE番号は未採番）。アプリケーションセキュリティ企業Endor Labsが4月18日に詳細レポートを公開した。 問題の本質は 動的コード生成の不備 だ。protobuf.js はprotobufスキーマからJavaScript関数を生成する際、文字列を連結した上で Function() コンストラクタを通じてそのまま実行する設計になっている。ここでメッセージ名などのスキーマ由来の識別子をサニタイズしていないため、攻撃者が細工したスキーマを与えると任意のコードを生成関数に埋め込むことができる。 具体的な攻撃シナリオはこうだ： 攻撃者が悪意あるスキーマを用意する アプリケーションがそのスキーマを読み込む スキーマ処理時に埋め込まれたコードが実行される 環境変数・認証情報・内部データベースへのアクセスが可能になり、インフラ内の横展開（ラテラルムーブメント）にまで至る サーバーサイドだけでなく、開発者のローカルマシンが攻撃対象になるケースも想定されている。信頼できないスキーマをローカルでデコードする習慣がある開発環境は要注意だ。 影響バージョンと修正版 ブランチ 影響バージョン 修正版 npm反映日 8.x 8.0.0以下 8.0.1 2026-04-04 7.x 7.5.4以下 7.5.5 2026-04-15 脆弱性報告は3月2日、パッチのGitHub公開が3月11日、npmへの反映が4月4日（8.x）と4月15日（7.x）だ。npm反映まで最大6週間のラグがあった点は覚えておいてほしい。 修正の内容はスキーマ識別子から英数字以外の文字を除去するサニタイズ処理の追加だが、Endor Labsは「長期的には Function() に攻撃者が到達できる識別子を通さない設計に変えることが根本対策」と指摘している。現在のパッチは「有効だが暫定的」と見るべきだろう。 実務への影響 今すぐやること： npm list protobuf または npm ls protobufjs で直接・間接の依存を確認する 使用中なら 8.0.1 または 7.5.5 に即時アップグレード 直接依存でなくても推移的依存（transitive dependency）として含まれている可能性があるため、npm audit でのスキャンも実施する 中期的に取り組むこと： スキーマのロードを「信頼できない入力」として扱う設計に見直す。外部から受け取ったスキーマを動的に読み込む構成は本質的にリスクを持つ 本番環境では コンパイル済み・静的スキーマを優先する（Endor Labsも同様に推奨） 依存ライブラリの定期監査をCI/CDパイプラインに組み込む。今回のようにPoC公開後に初めて気づく状況は避けたい サプライチェーンリスクの観点： ...

MicrosoftがFintoolを買収し、Officeプロダクトグループへの統合を進めると発表した。Fintoolは財務データの分析・解釈に特化したAIツールを提供してきたスタートアップで、今回の買収によってExcelをはじめとするMicrosoft 365アプリに「財務AIエージェント」機能が組み込まれることが期待されている。 これはMicrosoftがCopilotブランドの外側でも、領域特化型AIを着実に取り込もうとしている動きとして注目に値する。 Fintoolとは何者か Fintoolは財務レポートや決算情報をAIで読み解き、自然言語で質問・分析できるツールとして一部の金融・投資プロフェッショナルの間で評価されていたサービスだ。単なるデータ可視化ツールではなく、決算短信や有価証券報告書のような非構造化テキストを含む財務情報を横断的に解析できる点が特徴だった。 ExcelにAIエージェントが統合されると何が変わるか これまでのExcel Copilotは「セル範囲を選択して要約して」「グラフを作って」といったUIアシスタント的な機能が中心だった。Fintoolの技術が統合されれば、以下のようなユースケースが現実的になってくる。 財務諸表の自動読み解き: PDFやWebから取得した決算情報をExcel上で直接解析し、前年比・業界比較などを自動生成 エージェント的な自律処理: 「Q2の営業利益率が低下した原因を調べて」という指示に対して、複数シートや外部データを横断しながら仮説を提示 CFO・経理担当者向けの自然言語インターフェース: 数式やVBAを知らなくても、財務分析の専門的な問いに答えられる環境 MicrosoftはこれをOfficeプロダクトグループ直轄で開発するとしており、Copilot Studioやその他の外部向けツールとしてではなく、Excelネイティブの機能として届けることを示唆している。 実務への影響——日本のエンジニア・IT管理者にとっての意味 日本企業における財務業務のIT化は、ERPやBIツール導入が進んでいる一方で、現場では依然としてExcelが中心だ。「Excelで管理する文化」は批判されることも多いが、現実的にはExcelがデータのハブになっているケースが大多数だろう。 その意味で、今回の機能強化は「Excelをやめる」ではなく「Excelのまま高度な分析ができる」という方向性で、日本の現場親和性は高い。 実務担当者として押さえておきたいポイントは以下の通りだ。 ライセンス要件の確認: 財務AIエージェント機能がどのCopilotライセンス層に含まれるかは現時点で未公表。M365 Copilotの上位SKUやアドオンになる可能性がある データガバナンスへの対応: 財務データをAIが参照する際のテナント境界・コンプライアンス対応は必須。Microsoft 365のデータ主権設定を今のうちに整備しておくことを勧める 経理・財務担当者へのキャッチアップ支援: ツールが来てから「使い方がわからない」とならないよう、IT部門が先行してユースケースを把握しておくと展開がスムーズになる 筆者の見解 正直なところ、ExcelはMicrosoftの中でいまも最強のプロダクトだと思っている。WordもPowerPointも侮れないが、「Excelなしではビジネスが回らない」という現場の重力は他の追随を許さない。 そのExcelに財務特化のAIエージェントを組み込む——この方向性は正しいと思う。汎用のCopilotに何でもやらせようとするよりも、領域に精通した専門AIをプラットフォームに乗せていく戦略のほうが、実務使用に耐えられるレベルに早く届く。Fintoolの買収はその具体的な一手だ。 課題があるとすれば、「機能が来ても使われない」というMicrosoft 365のCopilot機能全般に共通する展開の難しさだ。財務部門はIT部門とは文化が異なり、新しいツールへの抵抗感も強い場合が多い。技術的な統合の品質と同じくらい、「現場が自然に使い始めるUX」と「ITが安心して展開できるガバナンス」の両立がこの機能の成否を分けると見ている。 Microsoftはこういう縦深のある買収を積み重ねられる力を持っている。その力をプラットフォームの一貫性に注いでいけば、M365は「使い続ける理由のある環境」としての地位をさらに確固たるものにできるはずだ。 出典: この記事は Microsoft acquires Fintool to supercharge Excel with financial AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが「Agent Framework 1.0」を正式にリリースした。安定版API、長期サポート（LTS）コミットメント、そしてModel Context Protocol（MCP）のネイティブ統合を一体化した構成で、エンタープライズ向けAIエージェント開発の基盤として位置づけられている。これは単なるバージョンアップではなく、AIエージェントを「実験的な取り組み」から「本番運用可能な仕組み」へと引き上げる節目のリリースだ。 Agent Framework 1.0の主な特徴 安定API＋LTSによる「信頼できる基盤」 これまでAIエージェント関連のフレームワークはAPIの変更が頻繁で、プロダクション導入をためらう要因になっていた。Agent Framework 1.0では安定版APIとLTSコミットメントを明示することで、「PoC止まり」にならない長期運用前提の設計を打ち出している。企業のシステム部門が最も懸念する「サポート継続性」に正面から応えた形だ。 MCPのネイティブ統合 Model Context Protocol（MCP）は、AIエージェントが外部ツールやデータソースと標準的なインターフェースで連携するためのプロトコルだ。Agent Framework 1.0ではこれをネイティブでサポートしており、ツール呼び出しの設計を一から作り込む必要がない。MicrosoftはA2A（Agent-to-Agent）アーキテクチャとMCPの組み合わせを本番エージェントの標準構成として明確に位置づけており、エコシステム全体での一貫性が高まる。 ブラウザベースのDevUI Agent Framework 1.0には、エージェントの実行フローとツール呼び出しをリアルタイムで可視化するブラウザベースのDevUIが同梱されている。AIエージェント開発の難しさの一つは「何が起きているかわからない」というブラックボックス問題だ。このDevUIはデバッグと監視の両面で実用価値が高く、開発チームの生産性に直接効いてくる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 エンタープライズ導入の現実的な出発点になる Azureを既に活用している企業にとって、Agent Framework 1.0はAIエージェント導入の「最初の一歩」として検討しやすい選択肢だ。AzureのIDやロール管理、既存のM365基盤との連携が前提に設計されており、セキュリティポリシーや監査要件をゼロから組み立てる手間を省ける。 MCP対応ツールとの相互運用が進む 現時点でMCPに対応するクライアントやツールは急速に増えており、Agent Framework 1.0を使えばそれらとの連携を標準的な方法で実装できる。「どのツールとどう組み合わせるか」を都度調査・実装する工数が大幅に下がる。 DevUIはPoC検証フェーズで特に有効 エージェントが意図したとおりに動作しているかを人間が確認・記録するには、可視化ツールが不可欠だ。社内承認のためのデモ資料作りにも使える。PoC段階の説明コストを下げる手段として、DevUIを積極的に活用したい。 「禁止」より「管理できる公式手段を提供する」アプローチ 情報システム部門がAIエージェントを「危険だから禁止」とするのではなく、Agent Framework 1.0のような管理機構を持つ公式基盤の上で安全に運用できる仕組みを提供することが、現実的かつ有効な戦略になる。ユーザーは便利で安全な公式手段があれば、そちらを選ぶ。 筆者の見解 Agent Framework 1.0は、Microsoftが「エージェント時代」に向けてきちんと本気を出してきたリリースだと受け止めている。安定API・LTS・MCP・DevUIというラインナップは、「試しに動かす」ではなく「本番で使い切る」ことを見据えた構成であり、エンタープライズ向けのAIエージェント基盤としては筋の通った設計だ。 AIエージェントの本質的な価値は、人間の認知負荷を下げ、繰り返しの判断・実行ループを自律的に回すことにある。その観点でいえば、今回のリリースで最も重要なのはLTSコミットメントだ。「来年またAPIが変わる」では企業は動けない。長期運用を前提に設計されているという宣言は、IT部門が稟議を通すうえで意外なほど重要な要素になる。 一方で、「框組みが整った」のと「現場でちゃんと使えるエージェントが作れる」は別の話だ。DevUIによる可視化やMCPによる標準化が整っても、「どんなエージェントを作るか」「何をAIに任せて何を人間が判断するか」の設計力は人間側に求められる。フレームワークは道具であり、それを使いこなすための実践経験の蓄積こそが、これからの差になる。 Microsoftのブランドとエンタープライズ基盤は、AIエージェントを組織全体に広げるうえで唯一無二の強みになりうる。そのポテンシャルを活かす方向に力が向かっているのであれば、今回のAgent Framework 1.0はその第一歩として評価できる。今後のバージョンアップと実際の採用事例に注目したい。 出典: この記事は Microsoft ships Agent Framework 1.0 with stable APIs, LTS commitment, and full MCP support built-in の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google CloudがVertex AIプラットフォームに大量のアップデートを投入してきた。言語モデル・動画生成・RAGエンジン・音声生成と、複数の領域を同時に進化させる今回のリリース群は、単なる機能追加にとどまらず、企業がAIを「使ってみる」段階から「本番で回し続ける」段階へ移行するための布石として読み解くべきだ。 Gemini 3.1 Flash-Lite：「安く・速く・大量に」を企業向けに 今回の目玉のひとつがGemini 3.1 Flash-Liteのパブリックプレビュー開始だ。位置づけは「低レイテンシ・高ボリューム向け」。つまり、推論精度よりも処理速度とコストを優先したい用途——ログ分析、大量ドキュメントのサマリー生成、リアルタイムチャットボット——に最適化されたモデルだ。 エンタープライズAI導入において、「使いたいが費用対効果が合わない」という声は根強い。GPT-4クラスの高性能モデルをすべてのリクエストに投入すると、従量課金のコストは想定外に膨らむ。ここにFlash-Liteのような「軽量・安価・高速」な選択肢が加わることで、モデルの使い分け戦略——高精度が必要な場面には上位モデル、大量処理はLiteモデル——が現実的に設計できるようになる。 Veo 3.1 Lite：動画生成をコスト現実的に Veo 3.1 Liteは「Vertex AI上で最もコスト効率の高い動画生成モデル」と位置づけられている。動画生成は計算コストが非常に高く、これまで大規模活用は限られた用途にしか現実的でなかった。Liteモデルの投入は、プロトタイプ製作・マーケティング素材の量産・e-learningコンテンツ生成など、品質よりも量とコストを重視する用途での本格活用を後押しする。 Google Cloudは画像・動画生成の分野において技術的な強みを持つ。その強みをエンタープライズ顧客が実際に使える価格帯で提供しようとする姿勢は、評価に値する方向性だ。 RAG Engine のサーバーレス化：インフラ管理の呪縛からの解放 地味だが実務インパクトが大きいのがVertex AI RAG Engine のサーバーレスモードのパブリックプレビューだ。 これまでのRAG（Retrieval-Augmented Generation）構築では、データベースのプロビジョニングとスケーリング管理が常に課題だった。Spannerモードでは専用インスタンスが必要で、運用コストとインフラ管理の負荷がつきまとう。サーバーレスモードでは、この部分が完全マネージドになり、開発者はRAGのロジックとプロンプト設計に集中できる。 さらにRAGクロスコーパス検索（Cross Corpus Retrieval）も同時にパブリックプレビュー入りした。複数のRAGコーパスを横断して同時に検索・回答生成できるこの機能は、社内ナレッジベースが複数のシステムに分散している大企業での活用シナリオを一気に広げる。 既存ユーザーへの重要警告：Imagen旧エンドポイントの廃止期限 新機能の陰に隠れがちだが、既存ユーザーが必ず確認すべき変更がある。Imagen生成GAエンドポイントの廃止だ。 imagegeneration@002 から imagen-4.0-ultra-generate-001 まで、旧世代の画像生成エンドポイント群が2026年6月30日をもって廃止される。移行先は gemini-2.5-flash-image に一本化される。Vertex AIを使って画像生成APIを呼んでいるシステムがあれば、今すぐ移行計画を立てる必要がある。6月末まで約2ヶ月しかない。見落とすとサービス停止につながる。 実務への影響 エンジニア・開発者向け Flash-LiteはAPIの呼び出しコストを大幅に削減できる可能性がある。既存ワークロードのモデルをLiteに切り替えてベンチマークを取ることを推奨する RAG Engine サーバーレスモードは「RAGを試したいが、Spanner管理に工数を割きたくない」チームに即効性がある。プロトタイプの立ち上げ速度が格段に上がる クロスコーパス検索は複数のSharePoint/Confluence/社内DBを横断検索するシステムへの応用が現実的になった Imagen旧エンドポイントの移行を今すぐスケジュールに入れること。6月30日期限を絶対に忘れるな IT管理者・アーキテクト向け モデルの階層化（高精度 vs コスト重視）はコスト管理の観点から設計必須の視点になった サーバーレスRAGはインフラ管理工数の削減と、小規模チームでのAI活用加速の両方に効く Anthropicの Claude Opus 4.7もModel Gardenで利用可能になっており、マルチモデル戦略を検討している場合は選択肢が広がっている 筆者の見解 GoogleのVertex AIへのこのアップデート群を見て感じるのは、「コスト現実主義」へのシフトだ。高性能なモデルを作ること自体はAI各社どこも当然やっている。しかし企業が実際に大規模展開するとき、ネックになるのは性能ではなくコストとオペレーション負荷だ。Flash-LiteやVeo Liteの投入、RAGエンジンのサーバーレス化はすべてこの方向に向いている。 ただ、正直に言えば「発表」と「実際に使える品質」の間にはまだ確認が必要だ。パブリックプレビューはあくまで試験段階。言語モデルの実務品質については、実際にワークロードを流してみなければわからない。特に日本語での精度や、複雑なビジネス文書への対応力は、英語圏と同等には期待しすぎないほうがいい。 AIプラットフォームの競争が本格化している今、Google Cloudが「使いやすさとコスト」の軸を強化してきたのは戦略として理に適っている。Vertex AIを既に使っている組織は、今回のアップデートで設計を見直す価値が十分にある。まだ様子見をしている組織は、RAGのサーバーレス化というエントリーポイントから試し始めるのがもっとも低リスクだろう。 動画生成については、Googleの技術力は本物だ。Veo 3.1 Liteが品質的に実用水準に達しているなら、マーケティングや研修コンテンツへの応用が加速する可能性がある。こちらはプレビュー期間中に積極的に試してみる価値がある。 ...

Microsoftが2026年春の定例大型アップデートとして「Windows 11 April 2026 Update」を展開中だ。セキュリティパッチとしか認識されがちな月例更新とは異なり、今回はパフォーマンス最適化とユーザー体験（UX）の刷新が中心テーマとなっている。日常的に使うSettingsアプリやFile Explorerから、アクセシビリティ機能のNarratorまで、幅広い領域に手が入っており、地味ながら実務への影響は小さくない。 パフォーマンス最適化の中身 今回のアップデートで最も数字として明確なのが、メモリ使用量の最大15%削減だ。メモリ管理アルゴリズムを刷新し、典型的な利用シナリオでのRAMフットプリントを減らす設計になっている。これは特にメモリ搭載量が限られるエントリークラスのノートPCや、複数VDI（仮想デスクトップ）セッションを同時稼働させるエンタープライズ環境で効いてくる。 合わせてCPUスケジューリングも改良されており、フォアグラウンドアプリへの優先度割り当てが改善された。ブラウザで調べ物をしながらExcelを操作するような「並行作業」での応答性向上が期待できる。統合GPU（iGPU）を持つシステムでは、グラフィックスサブシステムの改善によりアプリのレンダリングも滑らかになるとされており、ハイエンドGPUを積んでいない法人PCでもメリットが出やすい。 UX改善：Settingsとファイル管理が中心 Settingsアプリは起動速度の大幅改善に加え、UI構造の再編成が実施された。「あの設定項目、どこにあるんだっけ」という状況が減るよう、よく使う設定へのアクセスが合理化されている。サポートデスクに問い合わせが来やすい設定変更のフローが短縮されれば、ヘルプデスクコストの削減にもつながる。 File Explorerではバグ修正が中心で、大量ファイルを含むフォルダのブラウジング時のパフォーマンスが向上した。加えてナビゲーション機能が拡張されており、深い階層のフォルダ構造を扱う際の使いやすさが増している。 スタートメニューの検索機能も改善対象となっており、アプリやファイルの発見速度が上がっている。「Windows検索で出てこないからデスクトップに全部並べる」という運用を改善する足がかりになりそうだ。 アクセシビリティ強化：Narrator × Copilot連携 今回の注目機能のひとつがNarrator（ナレーター）へのCopilotサポート追加だ。スクリーンリーダーにAI支援を組み合わせることで、画面読み上げの文脈理解精度が向上する。障害を持つユーザーへの配慮として正しい方向だし、多様性・包括性（DE&I）を重視する企業のIT調達方針にも合致する。 エンタープライズ向け管理機能の拡充 IT管理者にとって押さえておくべき変更がグループポリシーとWindows Update for Businessの強化だ。アップデート展開のスケジューリング柔軟性が増し、段階的なロールアウトの制御がより細かくできるようになる。また、Windows DefenderとMicrosoftのクラウドセキュリティサービスとの統合が改善されており、セキュリティ運用の負荷軽減が見込まれる。 実務への影響 展開判断のポイントとして、まず自組織のWindows Update for Businessポリシーを確認しておきたい。今回のアップデートはHome/Pro/Enterprise全エディションが対象で、順次配信される。Insiderプログラムや展開リングでの動作確認を先行させ、業務クリティカルな端末への適用は1〜2週間様子を見るのが現実的だ。「即適用して壊れた」という報告が増えている昨今、数日待つという判断もれっきとしたセキュリティ・安定性管理のひとつだ。 メモリ削減の恩恵を最も受けるのは、8GB RAM機・複数アプリ並行利用・VDI環境の3パターン。端末更改コストを先送りしたい組織には特に注目したい更新だ。 Narratorの強化は障害を持つ従業員へのIT環境整備という観点でも評価材料になる。アクセシビリティ対応をコンプライアンス要件として整理している組織は、リリースノートの該当箇所を確認しておこう。 筆者の見解 正直なところ、Windowsの個々の機能アップデートを詳細に追いかけること自体の意味は以前より薄れていると感じている。とはいえ、今回のアップデートは評価できる内容だ。メモリ効率の改善やCPUスケジューリングの最適化は地味だが確実に体験を底上げするものだし、Narratorの強化はアクセシビリティへの本気度が見える。 Microsoftはこういう「縁の下の力持ち」的な改善を積み重ねることができる組織だ。それだけの技術力と規模がある。だからこそ、UX改善の地道な積み重ねをもっと前面に出して評価されてほしいと思う。日本のIT現場では「Windowsアップデート＝セキュリティパッチ」という認識が強く、パフォーマンスやUXの改善は見落とされがちだ。今回のような変更を正しく評価して展開の意思決定に活かすことが、IT管理者の腕の見せどころでもある。 展開タイミングの判断については、組織規模や業務特性によって正解が異なる。大規模な段階的展開インフラを持たない中小企業は、MicrosoftのWindows Update for Business機能を使った展開リングの仕組みを今から整えておくと、今後のアップデート管理が格段に楽になる。 出典: この記事は Windows 11 April 2026 Update Brings Performance Boosts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが業務システムに組み込まれつつある今、「エージェントそのものをどう守るか」という問いが現実的な課題として浮上している。Microsoftはこの問いに対し、既存のセキュリティ製品群——Entra、Purview、Defender——を組み合わせた4層の統合アーキテクチャで答えようとしている。日本語メディアでほとんど取り上げられていない技術詳細を、今回は実務の文脈で読み解く。 AIエージェントは「新しいID」を持つ存在である まず押さえておきたいのは、AIエージェントはユーザーでも従来のサービスアカウントでもない、第三のID種別だという点だ。Microsoftはこれを「Workload Identity（ワークロードID）」としてMicrosoft Entra上で管理する設計を取っている。 具体的には以下のメカニズムが働く： マネージドID / サービスプリンシパルによるエージェントのID発行 条件付きアクセス（Conditional Access）でエージェントのアクセス元・スコープを制限 Just-In-Time（JIT）アクセスにより、必要なときだけ必要な権限を付与 特にJITは重要だ。「常時アクセス権の付与は特権アカウント管理における最大のリスク」——これはAIエージェントにもそのまま当てはまる。エージェントに広い権限を常時持たせる設計は、侵害時の爆発半径（blast radius）を最大化する最悪のパターンだ。 データ保護層：PurviewがエージェントのI/Oを監視する エージェントが触れる情報の機密性を制御するのがMicrosoft Purviewの役割だ。 情報保護ラベル（Sensitivity Labels）がエージェントの入出力にも適用される エージェントが「機密」ラベルの付いたデータにアクセスしようとした場合、ポリシーに基づいてブロックまたは監査 データ損失防止（DLP）ポリシーはエージェントの応答にも適用可能 ここで注目すべきは、Purviewがエージェントの「振る舞い」をログとして残す点だ。「何を入力し、何を出力したか」の監査証跡は、インシデント発生時の調査はもちろん、コンプライアンス対応においても不可欠になる。 脅威検出層：Defenderがプロンプトインジェクションを検知 Microsoft DefenderはAIエージェント特有の脅威に対応するための拡張が進んでいる。注目すべきはプロンプトインジェクション攻撃への対応だ。 悪意ある外部コンテンツ（メール本文、Webページ等）にエージェントを操作する命令を埋め込む攻撃は、従来のマルウェアとは異なるベクトルであり、既存のエンドポイント保護では検知できない。Defenderはこのような間接プロンプトインジェクションを検知するシグネチャを持ち始めている。 さらに： エージェントの異常な動作パターン（通常より大量のデータアクセス等）をアラート Microsoft Sentinel連携によるSIEM/SOARへの統合 コンプライアンス層：エージェントの「行動記録」を残す 4層目はコンプライアンスだ。規制対応の観点から、エージェントの判断根拠と実行ログをどこまで記録・保全できるかが問われる。Purviewの監査ログとDefenderのインシデントログを組み合わせることで、エージェントの行動を事後検証できる体制を構築できる。 実務への影響——日本のIT管理者が今すぐ動くべきこと このアーキテクチャを踏まえ、実務で取るべき行動を整理する。 1. AIエージェントを「人間のアカウント」で動かすのを今すぐやめる Copilot StudioやAzure AI Foundryで作成したエージェントに、個人アカウントや共有サービスアカウントを使い回している構成は即刻見直しだ。マネージドIDを使ったEntra統合が正解。 2. 最小権限の原則を徹底する エージェントに付与する権限は「実際に必要な最小限」に絞る。SharePoint全サイトの読み取り権限を付与したエージェントが侵害されたときのリスクを想像してほしい。 3. Purviewの情報保護ラベルをAIワークロードにも適用する ラベルが整備されていないと、Purviewによるエージェント制御は機能しない。ラベル整備が先決。 4. プロンプトインジェクションを「新しい攻撃ベクトル」として認識する セキュリティ研修やインシデント対応プレイブックに、AIエージェント固有の攻撃シナリオを追加する時期に来ている。 筆者の見解 MicrosoftがAIエージェントセキュリティに対してEntra・Purview・Defenderの既存資産を統合して使う設計を選んだことは、技術的に理にかなっていると思う。ゼロから作るのではなく、実績のある製品群を組み合わせて対応する——これはMicrosoftらしい、そして正しいアプローチだ。 とりわけNon-Human Identity（NHI）の管理をEntraの枠組みで統一しようとしている点は評価したい。AIエージェントの普及で、NHIの数は今後人間のIDを大幅に上回るようになる。NHI管理の基盤ができていない組織は、自動化を進めようとするたびにボトルネックに直面することになる。 一方で、率直に言えば、これらの機能が「使える状態」になるまでの道のりはまだ長い。条件付きアクセスのエージェント対応、Defenderのプロンプトインジェクション検知精度、Purviewのエージェントログ保全——どれも完成形には程遠く、プレビュー段階の機能が多い。 それでも、統合プラットフォームとして全体最適を目指す方向性は変わっていない。M365・Azure・Defenderのエコシステム内でこれらが統合されれば、バラバラのポイントソリューションを寄せ集めるよりも確実に運用しやすくなる。これがMicrosoftの強みであり、AI時代においてもその強みは有効だ。 日本企業の多くはまだAIエージェントのセキュリティを「先の話」と捉えているかもしれない。だが、Copilot Studioで作ったエージェントが社内SharePointに接続された瞬間から、この話は「今の話」になる。アーキテクチャの理解は、導入の前に必要だ。 出典: この記事は How Microsoft Is Securing AI Agents Across Identity, Data, Threats, and Compliance の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 E5ライセンスを持つ組織にとって、見逃せないアナウンスが届いた。Security Copilotのエージェント機能が2026年4月20日から6月30日にかけて段階的にロールアウトされ、追加費用なしで利用できるようになる。セキュリティ運用の自動化に一歩踏み込む機会として、IT管理者はこのタイミングをきちんと把握しておきたい。 Security Copilotとは何か Microsoft Security Copilotは、セキュリティ運用・IT運用の日常業務を支援する生成AI＆エージェント型AIアシスタントだ。脅威インテリジェンス、業界ベストプラクティス、組織固有のデータを統合し、インシデント対応の高速化や見落とし防止を支援する。単なる検索・回答型AIではなく、自律的に判断して行動するエージェントとして動作する点が特徴だ。 処理量は「SCU（Security Compute Units）」という単位で管理される。今回のE5向け特典では、1000ユーザーライセンスあたり月400 SCU（上限1万SCU/月）が無償で付与される。 具体例で確認しよう： 400席の組織 → 月160 SCU 4,000席の組織 → 月1,600 SCU 4つのコアエージェント 今回含まれるエージェントは、日常的なセキュリティ運用の「重労働」を引き受けてくれる構成になっている。 Phishing Triage Agent（Microsoft Defender） ユーザーから報告されたフィッシングアラートを分析し、自然言語で「これは本物か、無害か」を判定する。SOCアナリストが1件ずつ目視確認していた作業を、エージェントが優先度付きで整理してくれる。 Conditional Access Optimization Agent（Microsoft Entra） 条件付きアクセス（CA）ポリシーのギャップを検出し、最適化の提案を行う。CAポリシーは組織の規模が大きくなるほど複雑化しやすく、「気づいたら穴が開いていた」という状況になりがちだ。このエージェントが定期的にチェックする仕組みを持てるのは心強い。 Threat Intelligence Briefing Agent（Microsoft Defender） 組織の環境に合わせた脅威インテリジェンスのブリーフィングレポートを自動生成する。「最新の脅威を把握したいが、レポート作成に時間がかかる」という課題をAIが肩代わりしてくれる。 Data Security Triage Agent（Microsoft Purview） DLP（データ損失防止）やインサイダーリスクのアラートを優先度付きで整理する。Purviewのアラートは膨大になりがちで、真に対処すべき案件が埋もれてしまう問題がある。このエージェントが「本当に見るべきもの」を浮かび上がらせてくれる。 実務への影響 すでにM365 E5を持っている組織は、4月20日以降に有効化通知が届き次第、即座に試せる状態になる（2025年11月18日以前からSecurity Copilotを利用中の組織はすでに適用済み）。 IT管理者として押さえておくべきポイントを整理する。 SCU消費量を把握する: 無償枠は「典型的な利用シナリオ」をカバーする設計とされているが、組織の規模や利用頻度によっては上限に達する可能性がある。初期はエージェントの稼働状況と消費量をモニタリングしながら使うのが賢明だ。 CAポリシーの棚卸しに活用する: Conditional Access Optimization Agentは、長年放置されてきたCAポリシーの見直しに絶好のきっかけになる。ゼロトラスト推進の文脈でも、「今のポリシーが本当に意図通りか」を定期的に検証する仕組みを持つことは重要だ。 SOC担当者の負荷軽減に焦点を当てる: フィッシングトリアージやデータセキュリティトリアージは、人が時間をかけていた定型的な判断業務をAIに任せることを意味する。担当者が本当に判断すべき案件に集中できる体制を作る一歩として位置付けよう。 Entra・Intune・Purview・Defenderの連携を前提に考える: これら4製品を連携して使っている組織でこそ、エージェントが真価を発揮する。バラバラに導入している場合は、統合活用の見直し時期かもしれない。 筆者の見解 セキュリティ運用における「人間のボトルネック」は深刻だ。アラートは溢れ、対応できる人材は限られ、見逃しが重大インシデントに繋がる——この構図はどの組織でも変わらない。Security CopilotのエージェントがEntraやDefender、Purviewに直接組み込まれ、日常業務のなかで自律的に動く設計は、この問題への現実的なアプローチとして評価できる。 M365 E5ライセンスの利用者にとって、この無償提供は使わない理由がない。ただし、「入れたら終わり」ではなく、エージェントが何をどう判断しているかを継続的に確認し、組織の運用フローに組み込んでいくことが大切だ。AIエージェントは自動化の入り口であり、人間の判断を完全に置き換えるものではない——少なくとも現時点では。 Copilot全体への評価はさておき、このSecurity Copilotエージェントのアプローチは方向性として正しいと思っている。セキュリティという領域は「速さ」と「網羅性」の両立が求められる。人間だけでは絶対に追いつけない規模・速度の脅威環境において、AIエージェントが最前線で動く仕組みを育てていく——MicrosoftがE5という上位ライセンスでこのアプローチに本気で取り組んでいること自体は、素直に歓迎したい。 ...