Tech News JP

Microsoftが音声認識の世界に大きな一石を投じた。同社は新しい音声文字起こしモデル「MAI-Transcribe-1」を公開し、多言語音声認識の標準ベンチマークであるFLEURS（Few-shot Learning Evaluation of Universal Representations of Speech）において、11の主要言語でトップの精度を達成したと発表した。OpenAIの「Whisper-large-v3」やGoogleの「Gemini 2.0 Flash」といった強力な競合を差し置いての首位は、音声AI分野の勢力図に明確な変化をもたらすものだ。 MAI-Transcribe-1とは何か 「MAI」はMicrosoft AIを意味するプレフィックスで、同社が独自に研究開発した基盤モデル群に付けられるブランドだ。MAI-Transcribe-1はその音声認識特化モデルであり、大規模な多言語音声データで訓練されている。 FLEURSベンチマークは、語族や音素体系が異なる多様な言語にわたって精度を測定するため、単一言語チューニングでは太刀打ちできない。11言語での首位は、モデルのアーキテクチャと学習データの双方において競合を凌駕していることを示している。 比較対象のWhisper-large-v3はOpenAIが公開しているオープンソースの文字起こしモデルとして業界標準的な地位を確立しており、多くの日本企業が会議録自動化や字幕生成に採用している。それを超えた精度というのは、実際の導入効果に直結する話だ。 なぜこれが重要か——日本のIT現場への影響 日本語は音声認識において特に難しい言語の一つだ。同音異義語が多く、文脈依存性が高く、敬語・専門用語・固有名詞のバリエーションも膨大にある。国内の会議録自動化ツールや医療・法務分野での音声入力システムが精度の壁に悩まされてきた背景がある。 FLEURSでの好成績が日本語を含む言語で達成されているならば、これは業務用途における文字起こし精度の底上げとして直接的なインパクトをもたらす。特にMicrosoft 365 CopilotやTeamsの会議文字起こし機能との統合が想定されることから、すでにM365環境を利用している日本企業にとっては追加投資なしで恩恵を受けられる可能性が高い。 実務での活用ポイント 1. Azure AI Speechとの連携を確認する MicrosoftはAzure AI Speech（旧Cognitive Services音声系）のバックエンドにMAI系モデルを順次統合している。現在Azure AI Speechを使って文字起こし系のAPIを呼んでいる場合、モデルバージョンのアップデートを追跡し、MAI-Transcribe-1が利用可能になった際に切り替え検証を行う価値がある。 2. Teams Premium / Copilot for M365の会議文字起こしを再評価する 会議の議事録自動生成に「精度が足りない」としてTeamsの文字起こしを使っていない組織は、今後数ヶ月以内に再評価の機会が来る。比較検証のために、代表的な会議シナリオでの文字起こし精度を定期的にスコアリングする仕組みを作っておくと良い。 3. オンプレミス要件がある場合はWhisperとの使い分けを継続検討 Whisper-large-v3はOSSであり、セキュリティポリシー上クラウドAPIを使えない環境でも自前でホスティングできる。MAI-Transcribe-1がAPIのみ提供であれば、機密性の高いデータを扱う金融・医療分野ではWhisperを内製運用するほうが現実的なケースも引き続き存在する。 筆者の見解 音声認識の精度競争は、ここ数年でOpenAIのWhisperが「実用的に使えるレベル」のハードルを一気に引き下げた。それまで専業ベンダーの独占市場だったところに汎用AIが殴り込んだ形だ。今回MicrosoftがMAI-Transcribe-1でWhisperを超えたことは、競合への対抗というよりも「Microsoft製品エコシステムの中で最高水準の音声処理を完結させる」という戦略的な意図を感じる。 特にCopilot統合の流れを見ると、会議の文字起こし→要約→タスク抽出→Plannerへの自動登録、というワークフローをMicrosoftが自社でクローズドループとして完成させようとしていることは明白だ。その基盤として最高精度の文字起こしモデルを持つことは、エコシステム全体の品質を底上げする。 一方で懸念もある。ベンチマーク上の最高精度が、実際の業務環境——騒がしい会議室、アクセントの強い話者、専門用語が飛び交う技術討議——でそのまま発揮されるかは別の話だ。FLEURSは学術的な評価軸であり、ノイズ耐性や話者適応性については別途評価が必要になる。 今後のポイントは、MAIシリーズがAzureのマネージドサービスとして一般提供されるタイミングと価格体系だ。精度がいくら高くても、Whisperの無料OSSという選択肢に対してコスト優位性を示せなければ、エンタープライズ以外での普及は限定的になる。日本市場では特に中堅・中小企業のコスト感度が高く、この点が普及速度を左右するだろう。音声AIの「次のWhisperモーメント」が来るとすれば、MAI-Transcribe-1はその有力候補だ。 出典: この記事は Microsoft releases MAI-Transcribe-1, the most accurate transcription model in the world の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Ciscoのサーバー管理基盤に、認証を一切必要とせず管理者権限を乗っ取れるという非常に深刻な脆弱性が発見された。データセンターやオンプレミス環境でCiscoサーバーを運用している国内の企業・組織にとって、即座の対応が求められる案件だ。 Cisco IMCとは何か——見落とされがちな「隠れた管理経路」 Cisco IMC（Integrated Management Controller）は、Cisco UCS C-SeriesやE-SeriesサーバーのマザーボードにハードウェアとしてビルトインされているOOB（Out-of-Band）管理モジュールだ。OSがクラッシュしていても、電源が切れていても、XMLのAPI・WebUI・CLIを通じてサーバーを遠隔管理できる。 いわばサーバーの「バックドア的な管理口」であり、BMC（Baseboard Management Controller）と同様の役割を果たす。管理の利便性が高い一方、ネットワークに露出していれば攻撃の入り口にもなりうる。 脆弱性の詳細——パスワード変更処理の不具合が致命的 今回発見されたCVE-2026-20093は、Cisco IMCのパスワード変更機能における不適切な処理に起因する。攻撃者は認証なしでHTTPリクエストを細工して送信するだけで、システム上の任意ユーザー（Adminを含む）のパスワードを変更し、そのユーザーとしてシステムにアクセスできてしまう。 CVSSスコアはクリティカル評価であり、現時点でワームやランサムウェアによる実績のある悪用事例やPoCコードは確認されていないものの、Cisco PSIRTは「ワークアラウンドなし・即時アップグレードを強く推奨」と異例の表現で警告している。「ワークアラウンドなし」という点が特に重く、一時的な緩和策が存在しない以上、パッチ適用以外の選択肢がない。 同時公開された他の重大脆弱性も要注意 今回のリリースでは、IMCの問題に加え、もう一つのクリティカル脆弱性も修正されている。 CVE-2026-20160は、Cisco Smart Software Manager On-Prem（SSM On-Prem）のAPIに対して細工されたリクエストを送るだけで、権限なしの攻撃者がOSレベルのroot権限でリモートコード実行（RCE）できるというものだ。ライセンス管理サーバーとしてオンプレ環境に展開している組織は特に影響を受ける。 さらに今月初旬には、Cisco Secure Firewall Management Center（FMC）の最高深刻度RCE脆弱性（CVE-2026-20131）が「Interlockランサムウェア」によるゼロデイ攻撃で悪用されており、CISAが連邦機関に3日以内のパッチ適用を命じる事態にまで発展していた。 実務への影響——国内エンジニアが明日すべきこと 影響範囲の確認（最優先） データセンターやサーバールームでCisco UCS C-Series / E-Seriesを運用しているか確認 IMCのWebUIやAPIポートが外部ネットワークやDMZに露出していないか即座にレビュー 原則としてIMCの管理ポートは専用管理VLANに隔離し、インターネットに直接露出させない構成を徹底する パッチ適用の手順 Cisco Security Advisoryから修正済みバージョンを確認 IMCのファームウェアアップデートはOSと独立して行えるが、メンテナンス窓口の設定が必要 ネットワーク的な隔離ができていない場合は、パッチ適用までの間IMCへのアクセスをACLで制限することを検討（根本解決にはならないが被害軽減に有効） SSM On-Premの対応 CVE-2026-20160の影響を受けるSSM On-Premはエンタープライズ向けライセンス管理サーバーであり、Cisco製品を多数運用している企業ほど導入している可能性が高い。管理コンソールのURL露出状況を確認し、同様に即時パッチを適用すること。 筆者の見解 今回の一連の脆弱性で改めて浮き彫りになったのは、「インフラの管理プレーン」がいかに攻撃者に狙われやすいか、という現実だ。IMCのようなOOB管理機能はOSレイヤーより「下」に存在するため、EDR（Endpoint Detection & Response）などのセキュリティエージェントの監視対象外になることが多い。攻撃者にとっては「見えない経路」から侵入できる絶好の標的といえる。 ゼロトラストの文脈でも、「管理ネットワークの分離」と「BMC/IMC等のファームウェア管理」は優先度の高い課題として位置づけられているが、実態として後回しにされているケースが多い。今回のインシデントはその重要性を再認識させる機会だ。 また、Ciscoの開発環境がサプライチェーン攻撃（Trivyを悪用した認証情報窃取）によって侵害されたという報告も並行してなされており、単なる製品脆弱性の話にとどまらない。サプライチェーンセキュリティとインフラ管理の両面でリスク評価を見直す時期に来ている。 Ciscoを使い続けるエンジニアとしては、今後はIMCやSSM On-Premのようなインフラ管理コンポーネントのパッチ管理を、OSやアプリケーションと同列に扱う運用体制の構築が急務だと感じる。「ハードウェアは一度設定したら触らない」という古い慣習は、今の脅威環境には通用しない。 出典: この記事は Critical Cisco IMC auth bypass gives attackers Admin access の内容をもとに、筆者の見解を加えて独自に執筆したものです。

エンタープライズ向けのセキュアファイル転送製品「Progress ShareFile」に、認証なしでリモートコード実行（RCE）まで到達できる深刻な脆弱性チェーンが発見された。既にPoCの詳細が公開されており、パッチ未適用環境への攻撃が現実的な脅威となっている。 何が見つかったのか オフェンシブセキュリティ企業のwatchTowrは、Progress ShareFile の Storage Zones Controller（SZC）コンポーネント（ブランチ5.x）に2つの脆弱性を発見した。 CVE-2026-2699（認証バイパス）: HTTPリダイレクトの不正な処理により、未認証のままShareFile管理インターフェースへアクセスできる。 CVE-2026-2701（リモートコード実行）: ファイルアップロード・展開機能を悪用し、アプリケーションのWebルートに悪意のあるASPX Webシェルを設置できる。 この2つを連鎖させた攻撃シナリオでは、攻撃者はまずCVE-2026-2699で管理画面に侵入し、ストレージゾーンの設定変更やパスフレーズ関連のシークレット値を制御下に置く。次にその情報を使って有効なHMAC署名を生成し、CVE-2026-2701でWebシェルを展開してサーバー上での任意コード実行を達成する。 認証なしでここまで到達できる「pre-auth RCE」という点が、このチェーンの最大の危険性だ。 なぜこれが重要か — ファイル転送製品は標的にされやすい ファイル転送・共有製品はランサムウェア集団や国家系脅威アクターが好んで狙うカテゴリだ。過去を振り返れば、Accellion FTA、GoAnywhere MFT、MOVEit Transfer、Cleo といった製品の脆弱性が相次いでClopをはじめとするランサムウェアグループに悪用され、大規模なデータ漏洩につながっている。 ShareFileも同様に、大企業・中堅企業が機密文書をやり取りするために使う製品であり、一度侵害されると内部の重要ファイルへのアクセスが容易になる。watchTowrのスキャンによれば、Storage Zone Controllerはインターネット上に約3万台が公開露出しており、ShadowServer Foundationも700台のインスタンスを観測している（多くが米国・欧州）。 日本国内での利用実態は公表されていないが、グローバルなSaaSやハイブリッドクラウド環境を持つ企業では、SZCをオンプレミスまたはプライベートクラウドに構築しているケースが存在する。自社環境でShareFile SZCを運用している場合は即刻確認が必要だ。 実務での対応ポイント 1. バージョン確認と即時パッチ適用 Progress は2026年3月10日に修正版「ShareFile 5.12.4」をリリース済みだ。SZCのバージョンが5.12.4未満であれば、最優先でアップデートする。 2. ネットワーク露出の最小化 SZCをインターネットに直接公開している場合は、VPNやプライベートネットワーク経由のアクセスに限定する。公開が必要な場合もWAF・IPホワイトリストで防御層を追加する。 3. 侵害痕跡（IoC）の確認 Webルート配下に不審なASPXファイルが存在しないか確認する。管理画面へのアクセスログや設定変更履歴を遡り、異常なアクセスがないかチェックする。 4. HMAC関連シークレットの再生成 パッチ適用後、ゾーンパスフレーズや関連シークレットを新しい値にローテーションする。攻撃者が侵害前に値を取得している可能性を考慮するためだ。 筆者の見解 今回の脆弱性は「個別の欠陥が軽微に見えても、組み合わせると壊滅的になる」という脆弱性チェーンの典型例だ。CVE-2026-2699単体では情報漏洩止まりのように見えるが、CVE-2026-2701と組み合わせることでサーバー完全掌握まで一直線に繋がる。 ファイル転送製品の脆弱性が繰り返し大規模攻撃に悪用されている現状を見ると、これらの製品に対するセキュリティ成熟度の低さが業界全体の課題として浮かび上がる。「ファイルを安全に送れればいい」というプロダクト観から、「常時攻撃にさらされている前提でハードニングする」発想への転換が求められている。 幸い今回は公開前にResponsible Disclosureが機能し、修正版が先にリリースされている。しかしwatchTowrが技術詳細を公開した以上、攻撃者がエクスプロイトを実装するのは時間の問題だ。「パッチが出ている」という安心感で対応を先送りにするのではなく、72時間以内の適用を目標に動いてほしい。 MOVEit、Cleo、そして今回のShareFile——この系譜を見るたびに、エンタープライズのファイル転送インフラがいかに攻撃面として見逃されてきたかを痛感する。次のターゲットが何かは分からないが、「自社で使っているファイル転送製品の脆弱性を定期的にトラッキングする」習慣を今すぐ組織に根付かせるべきだろう。 出典: この記事は New Progress ShareFile flaws can be chained in pre-auth RCE attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「コードは安全だった」——それでも280億円が消えた 2026年4月1日、Solanaブロックチェーン上のDeFi取引プラットフォーム「Drift Protocol」が、少なくとも約280億円（285百万ドル）もの資金流出を受けた。驚くべきは、攻撃者がスマートコントラクトの脆弱性を一切利用しなかったという点だ。プログラムに欠陥はなく、シードフレーズも漏洩していない。破られたのは「コード」ではなく「ガバナンスの信頼構造」そのものだった。 攻撃の手口——8日間かけて仕込まれた時限爆弾 攻撃は3月23日から30日にかけて入念に準備された。攻撃者はまず「Durable Nonce Account（耐久ナンスアカウント）」と呼ばれるSolanaの機能を活用した。 通常、ブロックチェーンのトランザクションにはブロックハッシュが使われるため、署名からおよそ2分以内に実行しなければ無効になる。Durable Nonceはこの制約を取り除き、署名済みトランザクションを任意のタイミングまで保持・実行できる機能だ。正規のユースケースとして設計されたこの機能が、今回は悪用された。 次に攻撃者は、Driftの「Security Council（セキュリティ評議会）」——プロトコルの管理権限を持つマルチシグ委員会——のメンバーから、必要閾値である5人中2人の署名（2/5マルチシグ）を取得した。この署名取得プロセスの詳細は公開されていないが、ソーシャルエンジニアリングや何らかの偽装が使われた可能性が高い。 4月1日、攻撃者は正規のトランザクションをひとつ実行した直後、準備していた悪意ある署名済みトランザクションを矢継ぎ早に実行。数分のうちに管理者権限を自身に移転させた。その後、悪意あるアセットの導入、出金制限の撤廃、そして資金の抜き取りへと一気に進んだ。 なぜこれが重要か——「ガバナンス攻撃」という新たな脅威 Web3セキュリティの文脈では、スマートコントラクトの脆弱性（バグ、ロジックエラー、再入攻撃など）が主要な攻撃ベクターとして語られることが多い。しかし今回のDrift事案は、ガバナンス機構そのものを標的にする「ガバナンス攻撃」が現実の脅威であることを証明した。 DeFiプロトコルの多くは、プロトコルのアップグレードや緊急停止などの権限を「マルチシグ委員会」や「DAO投票」に委ねている。これはコードの単一障害点を減らす設計だが、裏を返せば委員会メンバーへのアクセスを確保することで、コードを触らずにシステムを掌握できるということでもある。 日本のIT現場に直接影響はないと思われるかもしれないが、この攻撃手法の本質——「正規の権限委譲フローを悪用し、タイミングを計って実行する」——はブロックチェーン以外の世界でも通用する。クラウドのIAMロール委譲、Active Directoryの管理者委任、SaaSのOAuth連携など、どこにでもある「信頼ベースの権限モデル」が持つリスクとして読み替えられる。 実務への影響——エンジニア・IT管理者が今すぐ確認すべきこと 1. マルチシグ・管理者委任の閾値設計を見直す 今回の2/5という閾値が十分だったかを問い直したい。Web3に限らず、Azure AD PIMやAWS Organizations SCPなど、特権操作に必要な承認者数と承認プロセスの堅牢性を確認しよう。 2. 「事前署名」や「委任」の有効期限を管理する Durable Nonceに相当する「後から実行できる権限の付与」が自社環境にないか確認する。具体的には、長期有効なSAMLアサーション、無期限のAPIトークン、期限なしのOAuthスコープなどが該当する。 3. 異常なアクティビティの早期検知体制を整える Driftは「異常を検知してからユーザーに警告」したが、時すでに遅しだった。管理操作のログを集約し、予期しない権限変更を即座に通知するアラートを設定しておくべきだ。Azure MonitorやAWS CloudTrailを使った特権操作の監視が典型的な対策になる。 4. ゼロ信頼（Zero Trust）原則の徹底 マルチシグの署名者が「信頼できる人物」であっても、その操作内容は常に検証する仕組みが必要だ。「Verify explicitly, assume breach」の原則は、Web3のガバナンス設計にも応用できる。 筆者の見解 今回の事件が示す最も重要な教訓は、「セキュリティの最弱点は常に人間だ」という普遍的な事実だ。Driftのスマートコントラクト自体は機能通りに動いた。バグはなかった。しかし人間で構成されたガバナンス層が破られた。 ブロックチェーン業界は「コードは嘘をつかない」「信頼が不要なシステム（Trustless）」をセールスポイントとしてきたが、現実のプロトコルはどこかで「人間の信頼」に依存している。そのギャップを突かれたのが今回の攻撃だ。 より広い視点で見ると、DeFiセキュリティの成熟は、スマートコントラクト監査だけでなくガバナンス設計の監査まで含む段階に入ったと言えるだろう。タイムロック（権限変更に意図的な遅延を設ける仕組み）やオンチェーンガバナンスの透明化、あるいは2/5より高い閾値の採用など、構造的な対策が業界標準になっていくことが予想される。 日本の企業が直接DeFiに関わるケースはまだ限定的だが、Web3を活用したB2Bサービスや、NFTを使ったロイヤリティプログラムを展開しようとする企業は増えている。「スマートコントラクトが安全なら大丈夫」という過信は禁物だ。今後は「ガバナンスの堅牢性」を問われる時代が来る——Driftの事件はそのことを、280億円という代償とともに証明した。 出典: この記事は Drift loses $280 million as hackers seize Security Council powers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「漏洩コード」への好奇心を狙った巧妙な攻撃 2026年3月31日、Anthropicが開発するターミナル型AIエージェント「Claude Code」のソースコードが、npmパッケージへの誤ったファイル同梱により外部に流出した。59.8MBのJavaScriptソースマップに含まれた51万3,000行にわたる未難読化TypeScriptコードは、わずか数時間でGitHub上に拡散し、数千回フォークされるほど注目を集めた。 この事故からわずか数日後、クラウドセキュリティ企業Zscalerの研究チームが危険な動きを確認した。「idbzoomh」というユーザーがGitHub上に偽の漏洩リポジトリを作成し、「エンタープライズ機能を解除済み・使用制限なし」と謳って訪問者を引き込んでいたのだ。 攻撃の仕組み——SEO最適化からVidar投下まで 攻撃者の手口は周到だった。偽リポジトリはSEO（検索エンジン最適化）が施されており、Googleで「leaked Claude Code」などと検索すると上位に表示される仕掛けになっていた。流出コードに興味を持った開発者がリポジトリにたどり着くと、7-Zip形式の圧縮アーカイブをダウンロードするよう誘導される。 アーカイブ内にはClaudeCode_x64.exeというRust製の実行ファイルが入っており、起動するとコモディティ型の情報窃取マルウェアVidarと、ネットワークトラフィックをプロキシするGhostSocksが展開される。 VidarはStealer系マルウェアの定番ツールで、ブラウザの保存パスワード、クッキー、暗号資産ウォレット、ファイルなどを幅広く収集してC2サーバーへ送信する。GhostSocksと組み合わせることで、感染端末を踏み台にした二次攻撃への準備も整う。 Zscalerはさらに、同一の攻撃者とみられる別のリポジトリも発見している。こちらは「Download ZIP」ボタンを設置しているが調査時点では機能していなかったため、配信戦略を実験中と推測されている。悪意あるアーカイブ自体も頻繁に更新されており、将来的に別ペイロードが追加される可能性がある。 なぜこれが重要か——日本のIT現場への影響 この攻撃が示すのは、セキュリティインシデントの「情報格差」を突く手法が高度化しているという事実だ。 開発者やエンジニアは、著名ツールのソースコードが流出したと聞けば当然興味を持つ。「隠し機能があるかもしれない」「普段使えない機能が見られるかもしれない」という好奇心は、セキュリティ意識の高い人材であっても生まれ得る。攻撃者はこの心理を巧みに利用している。 日本国内でもClaude Codeの流出は広く報じられ、GitHubで公開されたコードを参照したエンジニアは多い。偽リポジトリにたどり着いてしまった人がいないとは言い切れない状況だ。 実務での活用ポイント エンジニア・開発者向け GitHubで「話題になっているコード」を検索する際は、アカウントの作成日・コントリビュート履歴・Star数の伸び方を確認する習慣を持つ。突然現れた新規アカウントの高トラフィックリポジトリは要注意。 実行ファイル（.exe）が含まれるアーカイブは、たとえ開発ツールを装っていても絶対に実行しない。公式npmパッケージや公式GitHubリリースページのみを信頼する。 EDR（Endpoint Detection and Response）やウイルス対策ツールが最新の定義ファイルに更新されているか定期確認する。 IT管理者・セキュリティ担当者向け 社内エンジニアに「Claude Code漏洩」に関するフィッシング・マルウェアキャンペーンが存在することをアナウンスする。 プロキシやEDRのログでClaudeCode_x64.exeや7-Zipアーカイブ経由の実行ファイル起動を監視する。 GhostSocksによるSocksプロキシ通信の兆候（異常な外部向けトラフィック）を検知ルールに追加する。 筆者の見解 今回の事例は、「AIツールへの高い関心」と「情報流出への好奇心」という2つの要因が重なったタイミングを巧みに狙ったものだ。攻撃者はAnthropicの事故を受けてほぼリアルタイムで偽リポジトリを立ち上げており、その対応速度には改めて脅威を感じる。 特に注目したいのは、攻撃の「入り口」がGoogle検索であるという点だ。これまでフィッシングメールやSNS広告が主流だった初期侵入経路が、SEOを悪用した検索結果汚染へとシフトしてきている。GitHubはオープンプラットフォームの性質上、こうした悪用を完全に防ぐことが難しく、エンドユーザー側のリテラシー向上が不可欠となっている。 生成AIツールへの注目度が高まるほど、関連する「偽情報・偽ツール」を使った攻撃も増加する。Claude Codeに限らず、Copilot・Gemini・Codexといったコーディングエージェントの動向に関する検索でも同様の手口が使われる可能性が高い。「公式以外からは絶対に入手しない」という原則を組織全体に徹底させることが、今後ますます重要になると確信している。 出典: この記事は Claude Code leak used to push infostealer malware on GitHub の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのOS展開ツール「Microsoft Deployment Toolkit（MDT）」がついに廃止される。長年にわたり無償で提供されてきたこのツールは、日本の多くのIT現場でも静かに、しかし確実に稼働し続けてきた。今回の廃止宣言は、単なるツールの終焉ではなく、モダンIT管理への移行が抱える「見えない前提の崩壊」を突きつけている。 MDTとは何だったのか MDT（Microsoft Deployment Toolkit）は、Windowsのクリーンインストールや企業展開を効率化するための無償ユーティリティだ。IT管理者はMDTを使ってカスタムWinPE環境を構築し、タスクシーケンスと呼ばれる自動化スクリプトでOS・アプリ・設定を一括展開していた。 特に日本の中小〜中堅企業では、高額なSCCM（Microsoft Endpoint Configuration Manager）を導入する予算がない中でも、MDTを活用することで数十〜数百台規模のPC展開を自前で回してきた現場は少なくない。ゼロコストで使えるにもかかわらず、機能の柔軟性は非常に高く、カスタムドライバーの注入、オフライン展開、WIM形式のイメージ管理など、企業ニーズに細かく対応できた。 「クラウド移行すればいい」では済まない理由 MicrosoftはMDTの後継として、Windows AutopilotとMicrosoft Intuneの組み合わせを推奨している。確かにこのモダン管理ソリューションは、インターネット経由でデバイスをゼロタッチプロビジョニングできる点で革新的だ。 しかし現実には、すべての企業がこのクラウド移行に追随できるわけではない。 オフライン・閉域環境の問題：製造業や官公庁、医療機関など、セキュリティポリシーによりインターネット接続が制限された環境では、Autopilotはそもそも動作しない。MDTはLAN内で完結する展開が得意だったが、その代替がない。 複雑なタスクシーケンスの再現：MDTは数百ステップに及ぶカスタムタスクシーケンスを組める。IntuneのWindows Autopilot + ESP（Enrollment Status Page）では同等の制御を実現するのは難しく、移行に多大な工数がかかる。 ライセンスコストの壁：AutopilotをフルActivateするにはMicrosoft Intune（旧Endpoint Manager）のライセンスが必要で、これはMicrosoft 365 Business Premiumや別途EMS E3以上のライセンスが前提となる。既存のMicrosoft 365 Business Basicユーザーには、追加コストが発生する。 実務への影響と対応策 短期的な対応 MDTは現時点でまだ利用可能だが、新機能追加はなくセキュリティ修正のみとなる。既存のMDT環境は当面動作するものの、将来のWindows更新への追随性が低下していく。今すぐ代替を探す必要はないが、ロードマップを立てておくことが急務だ。 WDS（Windows Deployment Services）との組み合わせを維持しつつ、IntuneベースのAutopilotへの段階移行を計画する Microsoft Configuration Manager（SCCM）へのアップグレードを検討する。共同管理（Co-management）機能でIntuneとの並存が可能 オープンソース代替の評価：OSDeploy、FOG Project、WindowsAutoPilot with HYBRIDなどのツールも視野に入れる 中長期的な移行戦略 2025〜2026年にかけて、日本企業のIT担当者はデバイス管理の再設計を迫られるだろう。MDTに依存した「オンプレ完結型」の展開フローから、クラウド活用を前提とした「ゼロタッチ展開」への転換は避けられない方向性だ。ただし、そのペースと深度は組織ごとに異なる。 Intuneへの移行チェックリストとして以下を推奨する： 現在のMDTタスクシーケンスの棚卸し（何がカスタム実装されているか） デバイスのAAD Join（Microsoft Entra ID参加）または Hybrid Azure AD Join の対応状況確認 アプリのWin32パッケージング（.intunewin形式）への変換作業の見積もり ネットワーク環境のAutopilot対応確認（プロキシ・ファイアウォール設定） 筆者の見解 MDTの廃止は、Microsoftが長年推進してきた「クラウドファースト」戦略の帰結であり、ある意味で予告されていた出来事だ。しかし私が懸念するのは、移行の「速度感のミスマッチ」だ。 Microsoftはモダン管理への移行を「シンプルで速い」と説明するが、現場のIT担当者——特に数人で数百台を管理している中小企業の兼任担当者——にとって、MDTで構築した展開インフラをゼロから再設計する工数は決して軽くない。ツールが廃止されても、現場の課題は消えないのだ。 一方で、Autopilot + Intuneの組み合わせが成熟しつつあることも事実だ。Windows Autopilot Device Preparationの登場や、Intune Suite（Advanced Endpoint Analyticsなど）の充実は、クラウド移行のメリットを確実に押し上げている。 ...

会議の音声をリアルタイムでAIが文字起こし・要約してくれる——そんな便利さで人気を集めているAIノートアプリ「Granola」に、見過ごせないプライバシーリスクが潜んでいることが明らかになった。エンジニアやIT管理者はもちろん、機密情報を扱う会議でGranolaを利用しているすべてのビジネスパーソンに向けて、今すぐ確認すべき設定を解説する。 Granolaとは何か Granolaは「連続する会議をこなす人のためのAIノートパッド」を標榜するアプリだ。カレンダーと連携し、会議の音声をキャプチャしてAIが箇条書きのメモを自動生成する。生成されたメモは編集可能で、同僚をコラボレーターとして招待したり、AIアシスタントに会議内容を質問したりもできる。MacのデスクトップアプリとしてUS発で展開されており、特にスタートアップやSaaS企業のビジネスパーソンの間で広く利用されている。 何が問題なのか リンクを知る全員が閲覧可能 Granolaのアプリ設定には、「デフォルトではノートはリンクを持つ誰でも閲覧可能」と明記されている。The Vergeの検証では、自分のノートのリンクをプライベートウィンドウで開いたところ、Granolaアカウントにログインしていない状態でもノートの内容・作成者・作成日時が表示されたという。 さらに、ノート内の箇条書きを選択すると、その根拠となる会議トランスクリプトの引用と、AIが生成したコンテキスト付きサマリーが表示される仕組みだ。完全なトランスクリプトへのアクセスはデスクトップアプリ内のコラボレーターに限定されているようだが、詳細はGranolaが公式に確認していない。 このリンクは検索エンジンにインデックスはされていないが、「誤ってSlackやメールでリンクを共有してしまった」「画面共有中に見えてしまった」といったシナリオで情報が外部に漏れるリスクは十分にある。実際、あるLinkedInユーザーが昨年この問題を指摘しており、大手企業の1社はセキュリティ上の懸念からシニアエグゼクティブへのGranola利用を禁止したと報じられている。 AIトレーニングへのデータ利用もオプトアウト制 もう1つの問題が、AIモデルの改善を目的とした「匿名化データの利用」だ。エンタープライズプランのユーザーはデフォルトでオプトアウトされているが、それ以外のプランではオプトインが前提となっている。GranolaはOpenAIやAnthropicなど第三者企業へのデータ提供は行わないと説明しているが、自社AIモデルの学習には利用される可能性がある。 なお、ノートと文字起こしはAWSのプライベートクラウド上に保存され、暗号化（保存時・転送時）はされている。会議の音声そのものは保存されない点は救いだが、テキスト化された会議内容が残ることに変わりはない。 今すぐできる設定変更 以下の手順でプライバシー設定を変更できる： リンク共有の制限 Granolaを開き、左下のプロフィールアイコンを選択 「Settings」→「Default link sharing」を開く 「Anyone with the link」を「Only my company」または「Private」に変更 AIトレーニングのオプトアウト 同じSettings画面で「Use my data to improve models for everyone」をオフにする なお、ノートを削除すれば既存のリンクからもアクセス不能になる。 実務への影響 日本のIT現場では、リモートワーク普及以降、会議メモの自動化ツールへの関心が急速に高まっている。GranolaのようなAI会議アシスタントは確かに生産性を大幅に向上させるが、今回の問題は「便利さ」の裏に潜むガバナンスリスクを改めて示している。 特に以下のケースでは利用ポリシーの見直しが急務だ： M&A・経営会議など機密性の高い打ち合わせ：リンク漏洩が情報漏洩に直結する 個人情報・顧客情報を扱う会議：GDPRや個人情報保護法の観点でリスクになりうる クライアントとの商談：NDA締結済みの情報をAIに学習させることの是非 IT管理者向けには、社内でGranolaを利用しているユーザーに設定変更を周知するとともに、エンタープライズプランへの移行（AIトレーニングがデフォルトオプトアウト）を検討する価値がある。 筆者の見解 Granolaに限らず、AIを活用した生産性ツールにおいて「デフォルトがオープン寄り」な設定になっている事例は後を絶たない。これはプロダクトの性質上、コラボレーションを促進するために意図された設計であることが多いが、エンタープライズ利用を想定した場合に大きな障壁となる。 今回の問題が示すのは、AI時代における「ゼロトラスト」の考え方をツール選定にも適用すべきという教訓だ。便利だからといって即座に組織展開せず、「デフォルト設定は何か」「データはどこに保存され、何に使われるか」「オプトアウトできるか」を必ずチェックするプロセスを組織に根付かせることが重要だ。 AI会議アシスタント市場はMicrosoft Copilot（Teams）やGoogle Gemini（Meet）など大手も参入しており、競争はさらに激化する。こうした大手プラットフォームはエンタープライズのコンプライアンス要件を満たした設計になっていることが多いが、スタートアップ発のツールでは今回のGranolaのようなケースが起きやすい。ツールの「便利さ」と「セキュリティ成熟度」を天秤にかけながら、組織としての利用判断を下す——そのリテラシーが今のIT部門には求められている。 出典: この記事は PSA: Anyone with a link can view your Granola notes by default の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月、生成AIの競争は新たなフェーズに入った。わずか3ヶ月でフロンティアが何度も塗り替えられ、今月だけでも業界の勢力図を変えかねない出来事が連続して発生している。OpenAIが年換算売上高（ARR）250億ドルを突破しIPO検討に入ったというビジネス面での激変と並行して、モデル性能の競争も前例のない激しさを見せている。 業界を揺るがした「Claude Mythosリーク」 今月最大のニュースは、3月26日に発生したAnthropicの内部文書流出だ。設定ミスのあったデータストアから約3,000件の内部ファイルが一時的に公開状態になり、その中に「Claude Mythos（内部コードネーム：Capybara）」の詳細な製品ドキュメントが含まれていた。 Anthropicは存在を否定せず、「推論・コーディング・サイバーセキュリティにおいて意味のある進歩を遂げた汎用モデルを開発中。能力の強さを鑑み、リリース方法を慎重に検討している。これは当社史上最高性能のモデルで、ステップチェンジと位置づけている」と公式に認めた。 リークされた文書によれば、ClaybearはClaude Opus 4.6を「劇的に」上回るプログラミング性能を持つとされ、現在はサイバーセキュリティパートナー限定の早期アクセス段階にある。公開日は未定だが、市場は4月中の発表可能性を約25%と見積もっている。 現時点のモデル勢力図 総合性能：Gemini 3.1 Pro が首位 16の主要ベンチマーク中13で首位を獲得しているGemini 3.1 Proは、Artificial Analysis Intelligence IndexでGPT-5.4 Proと同率ながら、APIコストは約3分の1という破壊的なコストパフォーマンスを誇る。エンタープライズ採用において価格は重要な変数であり、この差は見逃せない。 コーディング：Claude Sonnet 4.6 が実務首位 実際の専門家レベル作業を評価するGDPval-AA Eloベンチマークでは、Claude Sonnet 4.6がトップに立つ。GitHub CopilotのCodingエージェントがこのモデルで動作していることからも、コード生成の実用性では一歩抜け出した存在だ。 オープンソース：Meta Llama 4 Mavericが台頭 4,000億パラメータ・1,000万トークンのコンテキストウィンドウを持つLlama 4 Mavericは、独自インフラで無償運用できるオープンウェイトモデルとして最強クラスに達した。クローズドモデルとの性能差が急速に縮まっている。 価格破壊：DeepSeek V3.2 DeepSeek V3.2は入力100万トークンあたり約0.28ドルという価格を実現。欧米フラッグシップモデルの2ドル以上と比較すると約7分の1以下であり、コスト重視のユースケースでは無視できない選択肢だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 すぐに動けるアクション： GitHub Copilotを使っているなら今すぐ確認：Claude Sonnet 4.6ベースのCodingエージェントが実務コーディングで最高評価を得ている。エージェントモードが有効になっているか設定を確認し、複雑なリファクタリングや単体テスト生成に積極的に活用したい。 Gemini 3.1 Proのコスパを試算する：Google CloudやVertex AI経由でのAPI利用コストを、現在使っているGPT-4系と比較してほしい。同等性能で3分の1のコストになるなら、高スループットな社内ツールのバックエンドを切り替える価値がある。 オンプレミス・プライベート環境を検討しているなら Llama 4：情報漏洩リスクの観点から外部APIに送れないデータを扱う企業にとって、Llama 4 Mavericは現実的な選択肢になった。ローカルLLM運用のPoC着手タイミングとして今が適切だ。 Claude Mythosの動向を追う：サイバーセキュリティ分野で特段の強みを持つとされており、SOC自動化やペネトレーションテスト支援への活用が期待される。早期アクセス申請の窓口が開いた際は優先的に検討したい。 筆者の見解 2026年の生成AI競争を一言で表すなら「コモディティ化の加速」だ。 Gemini 3.1 ProがGPT-5.4と同等の性能を3分の1のコストで提供し、Llama 4がクローズドモデルの背中を追うこの状況は、「どのモデルを使うか」ではなく「いかに素早く使いこなすか」が企業の競争優位を決める時代が来たことを示している。 Claude Mythosのリークが特に興味深いのは、Anthropicが「サイバーセキュリティ」を特筆した点だ。セキュリティ特化のモデルが登場することで、これまで人手に依存していたインシデント対応や脆弱性評価の自動化が一気に現実解になりうる。日本でもCSIRTやSOCの人材不足は深刻であり、このモデルの公開は国内のセキュリティ運用に大きなインパクトを与えると予想する。 OpenAIのIPO観測が示すように、生成AIはもはや研究フェーズを完全に卒業した。モデル選定はベンダーロックインリスク・コスト・コンプライアンス・性能のバランスで評価する「調達判断」になっている。IT管理者にとっては、クラウドサービスの選定と同じ視点でAIモデルを評価するフレームを今すぐ整備すべき時期に来ている。 出典: この記事は OpenAI Surpasses $25B ARR, Explores IPO as Early as Late 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIはコードを「書く」から「検証する」フェーズへ 「AIはコードが書ける」——この命題はもはや疑う余地がない。GitHub CopilotやClaude Code、Cursor AIが普及し、日々の開発でAIアシストは当たり前になってきた。しかし、もう一段深いところで問いが立ち上がっている。「AIは信頼できるエンジニアリングを、人間の監視なしにできるのか？」 この問いに対して、英国オックスフォード発のスタートアップ・Diffblueが2026年3月24日に衝撃的なデータを叩きつけた。自律型回帰テスト生成エージェント「Diffblue Testing Agent」が一般提供（GA）を開始し、8つの実世界Javaプロジェクトを対象としたベンチマークで平均81%のライン網羅率を自動達成したというのだ。 比較対象は「シニア開発者がClaude Codeと2時間協働した場合」——その結果は平均32%。実に2.5倍の差である。 Diffblue Testing Agentとは何か Diffblue Testing Agentは、既存のAIコーディングプラットフォーム（GitHub Copilot、Claude Code等）の上にオーケストレーション＆検証レイヤーとして機能する専門エージェントだ。既存ツールを置き換えるのではなく、それらを指揮する立場に立つ設計思想が特徴的である。 具体的な動作フローは以下のとおり： コードベースの自律スコーピング — 対象クラス・メソッドを自動特定 テスト計画の作成 — カバレッジ分析をもとに並列テスト生成戦略を立案 テスト生成の委任 — メソッド・クラスレベルのテスト作成をClaude CodeなどのAIに委任 ビルド＆検証 — コンパイルが通り、かつパスするテストのみを採用 ロールバック処理 — 失敗したテストは自動的に除去 プルリクエスト準備 — 数百〜数千クラスを一括処理してPRを自動生成 ベンチマークでは81%のライン網羅率に加え、**ミューテーション網羅率61%**も達成。これは多くのエンタープライズが設定するテスト品質基準を上回る水準だ。 この技術的基盤はオックスフォード大学発の数十年にわたるソフトウェア検証研究から生まれており、単なる「AIにテストを書かせる」ツールとは一線を画す。 なぜこれが重要か——日本のIT現場への影響 日本のエンタープライズIT現場では、アプリケーションモダナイゼーションが最大の課題の一つとなっている。老朽化した基幹システムをクラウドネイティブ化・マイクロサービス化する際、最大のリスクは「リグレッション（既存機能の壊れ）」だ。 テストがない（あるいは少ない）レガシーコードをリファクタリングするのは、目を閉じてロープを渡るようなものである。多くの現場では「テストを書く工数がない」という理由でモダナイゼーションが止まっているか、そもそもテスト工程を省略してリスクを抱えたまま進んでいる。 Diffblue Testing Agentが解決しようとしているのはまさにこの課題だ。「テスト書く人がいない問題」を、エージェントが自律的に解決する。 また、AIコーディングツールの「急速に収穫逓減する」問題も見逃せない。Claude CodeやCopilotにテスト生成を頼み続けると、50%程度の網羅率で詰まり、そこから先は開発者が延々とプロンプトを調整する時間が必要になる。DiffblueのCTO、ピーター・シュラメル博士が「その努力は急速に手が届かないレベルになる」と述べているのは、多くの開発者が実感していることだろう。 実務での活用ポイント Javaレガシーシステムの担当者は今すぐ注目を。Diffblue Testing AgentはJavaプロジェクトを主なターゲットとしており、Spring Boot・JakartaEEベースの業務システムとの相性が良い。モダナイゼーション前の「テスト整備スプリント」に組み込む使い方が現実的だ。 既存のAIコーディング環境への統合がスムーズ。GitHub Copilotや Claude Codeをすでに導入しているチームであれば、Diffblue Testing Agentはそれらを置き換えるのではなくオーケストレーションレイヤーとして乗る。投資を無駄にせず効果を最大化できる。 コードレビューの視点変化。テスト生成が自動化されると、人間のレビュアーは「テストが存在するか」ではなく「テストが意味のある検証をしているか」にフォーカスできる。ミューテーションカバレッジ（61%）をKPIに設定することで、テスト品質の議論が具体的になる。 CI/CDパイプラインへの組み込み。PRを自動生成する機能を活かし、テスト追加をCIの一部として自動化することで、新機能追加のたびにテスト負債が積み上がる悪循環を断ち切れる。 筆者の見解 AI開発ツールの進化を2年以上追ってきて、このDiffblueのアプローチには強い納得感がある。 これまでの「AIにコードを書かせる」フェーズは、いわばAIの「作文能力」を活用する段階だった。しかし実際の開発現場で信頼を得るためには、AIが「品質保証まで含めたエンジニアリング」ができなければならない。 Diffblue Testing Agentが示しているのは、専門特化型エージェントが汎用AIコーディングアシスタントを上回るという事実だ。汎用AIコーディングアシスタントは優秀だが、テスト生成に特化して設計されたエージェントには及ばない——これは当然であり、むしろ健全な分業の形だと思う。今後は「汎用AIコーディングアシスタント ＋ 専門エージェント群」という構成が、エンタープライズ開発の標準になっていくだろう。 気になるのはJava以外への展開だ。日本の現場ではC#やPythonも多く、これらへの対応が進めば採用の障壁はさらに下がる。また、オックスフォード大学の研究ベースという点は信頼性の観点で大きな強みだが、日本語コメントが混在するコードへの対応品質も実際の導入前に検証が必要だろう。 ...

コード生成は「ボトルネック」ではなくなった JetBrainsが2026年3月、AIエージェントによる自律的なソフトウェア開発を統合管理するプラットフォーム「JetBrains Central」を発表した。2026年Q2に限定デザインパートナー向けのEAP（Early Access Program）を開始する予定だ。 この発表が示すのは、単なる「IDEにAIを追加する」という話ではない。ソフトウェア開発そのものの構造的な変容への、JetBrainsなりの回答だ。 なぜ「Central」が必要なのか JetBrainsが2026年1月に実施した「AI Pulse」調査（世界1万1000人のエンジニア対象）によると、すでに90%が業務でAIを活用している。さらに22%がAIコーディングエージェントを利用しており、66%の企業が今後12か月以内に導入を計画している。 しかし問題がある。AIの恩恵が個人の生産性向上に留まっており、開発ライフサイクル全体（コードレビューやリリースパイプラインなど）に活用しているエンジニアはわずか13%に過ぎない。 チームや組織レベルでの改善——デリバリー速度、システム信頼性、コスト効率——にAIが繋がっていないのだ。 JetBrains Centralはこのギャップを埋めることを目指している。Issueの調査、コード生成、テスト実行、マルチステップワークフローをエージェントが自動実行するにあたり、それらを「統一された生産システム」として制御・監視・管理する基盤を提供する。 3つのコアケイパビリティ 1. ガバナンスと制御 ポリシー強制、ID・アクセス管理、可観測性（Observability）、監査証跡、コスト帰属管理。エンタープライズ環境で求められる要件が一通り揃う。一部機能はすでにJetBrains Central Consoleとして提供されている。 2. エージェント実行インフラ クラウドエージェントランタイムとコンピューティングプロビジョニング。エージェントが開発環境をまたいで安定動作できる基盤を提供する。 3. エージェント最適化とコンテキスト リポジトリ・プロジェクトをまたいだ共有セマンティックコンテキスト。エージェントが適切な知識にアクセスし、最適なモデル・ツールへのタスクルーティングを実現する。 注目すべきはオープンなアーキテクチャだ。JetBrains製エージェントだけでなく、Claude Agent、Codex、Gemini CLI、あるいは自社開発のカスタムエージェントも統合可能。特定ベンダーへのロックインを避けながら、既存の開発インフラ投資を活かせる設計になっている。 実務への影響——日本のエンジニア・IT管理者にとっての意味 エンジニアへのヒント： 今すぐ試せるわけではないが、EAPデザインパートナーへの応募を検討する価値がある。特に大規模チームやCI/CDパイプラインへのAI統合を模索している組織は優先度が高い。 JetBrains IDE（IntelliJ IDEA、PyCharm、Rider等）を既に使っている場合、移行コストなく恩恵を受けやすい。 「AIにコードを書かせる」フェーズから「AIエージェントのワークフローを設計・監視する」フェーズへのスキルシフトを意識しておくべきだ。 IT管理者・アーキテクトへのヒント： コスト帰属（Cost Attribution）機能は、エージェント活用によるクラウドコストの増大を管理する上で重要になる。予算管理の観点からガバナンス機能の成熟度を注視したい。 既存のGitHub Actions、Azure DevOps等のパイプラインとの統合性についても、EAP段階で積極的に検証を行うべき局面が来るだろう。 筆者の見解 JetBrains Centralの発表を見て、私が真っ先に思い浮かべたのはAzure DevOpsとGitHub Actionsの進化の歴史だ。かつてCI/CDがエンジニアリング組織に「パイプラインの管理者」という新しい役割をもたらしたように、AIエージェントの普及は「エージェントオーケストレーションの管理者」という役割を生み出しつつある。 JetBrainsの戦略は明快だ。IDEベンダーとしての優位性を「エージェントの制御基盤」にまで拡張すること。 コード生成自体はコモディティ化しつつあるなか（OpenAI、Anthropic、Google、Microsoftが競い合っている）、どのエージェントを使っても統合・管理できる「プレーン（制御層）」を握ることに活路を見出している。 これはMicrosoftが「Copilot Studio」や「Azure AI Foundry」でエージェント基盤を構築しようとしている方向性と本質的に同じだ。異なるのは、JetBrainsが開発者体験（DX）を起点にしているという点。VSCode陣営対JetBrains陣営という旧来の競争軸は、「どのエージェント基盤でソフトウェア生産を管理するか」という競争軸に移行しつつあるのかもしれない。 日本企業にとっては、まだEAPという段階ではあるが、2026年後半にかけてエージェント駆動開発への組織的な準備を始める好機でもある。ツールの選定より先に「どのようにエージェントの成果物を検証し、ガバナンスを効かせるか」というプロセス設計を議論し始めることが、今できる最も価値ある投資だと筆者は考えている。 出典: この記事は JetBrains Central: Open System for Agentic Software Development (EAP Q2 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがGemini 3.1 Flash-Liteを正式リリースした。従来モデル比で応答速度2.5倍・出力速度45%向上を実現しながら、入力トークン100万件あたりわずか$0.25という衝撃的な低価格を打ち出している。生成AIの「高性能＝高コスト」という常識が、いよいよ崩れはじめている。 Gemini 3.1 Flash-Liteとは何者か Gemini 3.1 Flash-Liteは、Googleが「速度とコスト効率」に最適化して設計した軽量モデルだ。Geminiファミリーの中でもFlashシリーズはリアルタイム応答や大量処理に向いた系統であり、Flash-Liteはさらにその方向性を突き詰めたポジショニングになる。 主な特徴は以下の3点に集約される。 ① 応答速度の大幅改善 前世代比で初回応答までのレイテンシが2.5倍短縮。チャットボットや対話型アプリケーションでは「待ち時間」がそのままUXの質に直結するため、この改善は実運用で即効性が高い。 ② 出力スループット45%向上 長文生成や一括処理バッチのスループットが45%改善。大量のドキュメント要約やログ解析といった処理集中型ワークロードのコスト削減に直接効く。 ③ 価格設定の破壊力 入力トークン100万件あたり$0.25、出力は$0.75程度と推定される。GPT-4oのフルモデル（入力$5〜10/M）と比較すると、単純計算で10〜40倍のコスト差が生じる。「試作品でしか使えなかったコスト水準」が、本番環境でも現実的な選択肢になってきた。 なぜこれが重要か——日本のIT現場への影響 日本企業における生成AI導入の最大の障壁の一つは、依然として「コスト」だ。PoC（概念実証）段階では許容できたAPI費用が、本番移行・スケールアウト時に予算を圧迫するケースは多い。特に中小規模のSIerやスタートアップでは、ユーザー数に比例して跳ね上がるトークン費用が事業計画に影響することもある。 Gemini 3.1 Flash-Liteの価格帯は、こうした「コストで諦めていた本番展開」を現実的な選択肢に引き戻す可能性がある。たとえば以下のようなユースケースだ。 カスタマーサポートチャットボットの24時間運用（大量リクエストでもコストが読みやすい） 社内文書の全文要約・インデックス作成（数万ドキュメント規模でも費用が抑えられる） コード補完・レビュー支援ツールのCI/CD統合（パイプライン毎の実行コストが激減） 実務での活用ポイント 1. 用途に応じたモデル分割戦略を採用する すべてのリクエストを高性能モデルに通す「フラット設計」は非効率だ。複雑な推論・創造的タスクはGemini 1.5 ProやGPT-4o、定型的な分類・要約・抽出はFlash-Liteに振り分けるルーティング設計を導入することで、品質を落とさずにコストを50〜70%削減できる可能性がある。 2. Azure AI FoundryやVertex AIとの統合を活かす GeminiモデルはGoogle Cloud Vertex AI経由で利用可能であり、Azure AI Foundryも外部モデルのルーティングに対応しつつある。既存のM365環境やAzure基盤を持つ日本企業であれば、既存の認証・ガバナンスフレームワーク上でFlash-Liteを試せる環境が整いつつある。 3. プロンプト設計でコストをさらに圧縮する Flash系モデルはコンテキスト長が長くなるほどレイテンシが増す傾向がある。System Promptの最適化と、不要なコンテキストの削除（Context Pruning）を組み合わせることで、費用対効果を最大化できる。 筆者の見解 今回のGemini 3.1 Flash-Liteのリリースは、生成AIの「競争軸の変化」を象徴する出来事だと捉えている。 2023年〜2024年はベンチマークスコアの競争が主戦場だった。しかし2025年以降、モデルの性能が「十分に高い」水準に達してきたことで、差別化の軸はコスト・速度・信頼性へと移行しつつある。OpenAI、Anthropic、Googleの3社がいずれも「安価な軽量モデル」のラインナップを強化しているのは、この流れを如実に示している。 日本市場においては、この価格競争は追い風だ。一方で注意すべき点もある。安価なモデルは「ハルシネーション率」や「複雑な指示への追従性」でフルモデルに劣る場面がある。コスト削減の旨みを享受しつつ、品質評価の仕組みを合わせて整備することが不可欠だ。 また、GoogleがこのタイミングでFlash-Liteをリリースした背景には、Anthropicの「Claude 3.5 Haiku」やOpenAIの「GPT-4o mini」との競合があることは明らかだ。価格競争の激化は、エンドユーザーにとっては歓迎すべき話だが、ベンダーロックインのリスクも高まる。「今日の最安モデルが来月には陳腐化する」サイクルに備え、マルチモデル対応のアーキテクチャを設計段階から意識しておくことを強く推奨したい。 出典: この記事は Gemini 3.1 Flash-Lite Delivers 2.5× Faster Response at $0.25 Per Million Tokens の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIが、AIシステムの安全性分類タスクに特化したオープンウェイトモデル「gpt-oss-safeguard」をApache 2.0ライセンスで公開した。120Bと20Bの2サイズを提供し、Hugging Faceからダウンロードして自社環境に展開できる。クラウドAPIに依存せず、自前のAI安全対策インフラを構築できる点が大きな注目ポイントだ。 「deliberative alignment」とは何か gpt-oss-safeguardの核心にあるのが、deliberative alignment（熟慮的アライメント）という新しい手法だ。従来の安全分類モデルは、あらかじめ学習したパターンで有害コンテンツを判別するに留まっていた。これに対し、deliberative alignmentでは推論時（インファレンス時）にポリシーを直接解釈させる。つまり、企業独自の利用規約や業界ルールを自然言語で記述し、それをモデルが理解した上でリアルタイムに判断を下す仕組みだ。 これは実務上、非常に大きな違いをもたらす。これまでは「このコンテンツは有害か否か」という二値判定が主流だったが、deliberative alignmentでは「わが社のポリシーに照らしてどうか」という文脈依存の判断が可能になる。医療・金融・教育といった規制業界で求められる、きめ細かなコンテンツ制御に対応できるポテンシャルがある。 120Bと20Bの使い分け 提供される2サイズには明確な役割分担がある。 120Bモデル: 精度優先。複雑なポリシー解釈や、グレーゾーンの判断が求められるシナリオに適する。GPUリソースは相応に必要だが、クリティカルなコンテンツ審査ワークフローに向く。 20Bモデル: 速度とコストのバランス重視。リアルタイムのチャットモデレーションや、大量のログ分類など、スループットが求められる用途に最適。 エンタープライズ用途では、両モデルを組み合わせて「まず20Bで高速フィルタリング→フラグが立ったものだけ120Bで精査」という二段構えの設計も現実的だ。 なぜこれが重要か——日本のIT現場への影響 日本企業がAIチャットボットや生成AIシステムを本番導入する際の最大の壁のひとつが、コンテンツモデレーションだ。OpenAI APIやAzure OpenAI Serviceを使えばある程度の安全機能は得られるものの、業界固有のポリシーや社内規定に合わせたカスタマイズは難しかった。 gpt-oss-safeguardのオープン公開により、この状況が変わる。特に以下のシナリオで恩恵が大きい。 オンプレミス・プライベートクラウド環境: 機密情報をOpenAIサーバーに送りたくない金融機関・官公庁が、クローズドな環境でAI安全対策を実装できる カスタムポリシーの適用: 医療分野の不適切な医療アドバイスのフィルタリング、EC事業者の広告審査など、業界ルールに合わせた判断基準を自然言語で定義できる コスト削減: 外部APIコールを安全分類に使うコストを内製化により削減できる 実務での活用ポイント 明日から試せる具体的な手順として、まずHugging Faceで20Bモデルをダウンロードし、社内の検証環境（A100×1枚程度で動作可能）で既存の問い合わせログを分類させてみることをお勧めする。自社の「グレーゾーン事例」に対してモデルがどう判断するかを見るだけでも、現行の安全対策の盲点が浮かび上がってくる。 ポリシー記述には工夫が必要だ。deliberative alignmentは「禁止語リスト」ではなく「ポリシーの意図」を理解させる設計なので、「〇〇は禁止」ではなく「なぜ禁止するのか」を含めた文章で記述すると精度が上がる。 Azure上で展開する場合は、Azure Machine Learningのマネージドオンラインエンドポイントにデプロイすることで、スケーリングや監視を既存のAzureインフラに統合できる。 筆者の見解 gpt-oss-safeguardの公開は、AIの安全対策が「ベンダー任せ」から「自社で実装・管理するインフラ」へと転換する流れを加速させると見ている。 これまでOpenAIは商業APIを通じてコンテンツポリシーを一元管理してきた。それが機能する場面も多いが、業界規制が厳しい日本市場では「ブラックボックス」な安全対策に監査が通らないケースも少なくない。今回のオープン化により、「どのようなロジックで何を判断したか」を企業側が説明できる透明性が得られる。これはGDPRや金融庁のAI活用ガイドラインへの対応にも直結する話だ。 一方で、オープンウェイトモデルには「悪用されるリスク」も伴う。安全分類モデルそのものを攻撃者が解析し、検出を回避するプロンプトを作りやすくなる側面は否定できない。OpenAIがこのトレードオフをどう評価した上で公開に踏み切ったかは、今後の同社のオープンソース戦略を読み解く上でも注目に値する。 「安全なAI」を自社で実装できる時代が来た——それはエンジニアにとって自由度と責任の両方が増すことを意味する。gpt-oss-safeguardをきっかけに、AI安全対策を「費用」ではなく「競争優位」として捉え直す組織が増えることを期待したい。 出典: この記事は OpenAI Releases gpt-oss-safeguard: Open-Weight Safety Classification Models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11に搭載されているセキュリティ機能「Smart App Control（SAC）」が、長年の制約をついに乗り越えた。これまでSACを一度でも無効にしてしまうと、OSを再インストールしない限り再有効化できないという仕様が大きな足かせになっていたが、4月14日からの段階的ロールアウトでこの制限が解消される。 Smart App Controlとは何か Smart App Control（SAC）は、Windows 11 22H2で導入されたアプリケーション制御機能だ。Microsoftのクラウドベースの機械学習モデルを使い、信頼されていないアプリや悪意のあるコードの実行をブロックする。Windows Defenderのシグネチャベースの検出とは異なり、アプリの「評判」と「コード署名」を組み合わせてリアルタイムで判断する仕組みで、ゼロデイ攻撃やフィッシング経由のマルウェアに対して特に有効だ。 これまでの問題点 導入以来、SACには致命的なUX上の欠陥があった。新規インストール時や初期状態では「評価モード」として動作し、アプリの互換性を自動判断する。ここで互換性上の問題が発生すると自動的に無効化されるのだが、一度オフになったら二度と元に戻せないという仕様だった。 企業環境ではこの挙動が特に問題視されていた。展開済みのPCにSACを適用しようとすると、全台クリーンインストールが必要という現実離れした要件が障壁となり、多くの組織が導入を断念せざるを得なかった。 4月更新で何が変わるか 4月14日から段階ロールアウトが始まる更新では、Windows Security（Windowsセキュリティ）の設定画面からSACを直接有効化・無効化できるようになる。システムの再インストールは不要だ。 これにより次のようなシナリオが現実的になる： 既存PCへのSAC展開：IT管理者がグループポリシーやIntuneを使って、運用中のPCに一括でSACを有効化できる テスト・検証の容易化：互換性検証環境でSACを一時的に無効にして検証し、問題がなければ再有効化するワークフローが組める 段階的セキュリティ強化：重要システムから順次SACを有効化していくといった柔軟な展開計画が立てられる 実務への影響 — 日本のエンジニア・IT管理者にとっての意味 まず確認すべきこと： 自社のWindows 11端末でSACの現在の状態を把握しよう。「Windowsセキュリティ」→「アプリとブラウザーのコントロール」→「スマートアプリコントロール」から確認できる。 Intune管理者へ： 4月14日以降、Configuration Profileや設定カタログでSACを管理できるかどうかMicrosoftのドキュメント更新を注視すること。エンドポイントセキュリティのベースラインポリシーに組み込める可能性が高い。 業務アプリとの互換性検証： SACは署名されていないアプリや評判スコアが低いアプリをブロックする。社内開発のツールやレガシー業務アプリが影響を受ける可能性があるため、評価モードで動作させながら互換性を事前確認しておくことを強く推奨する。 注意点： 段階的ロールアウトのため、4月14日時点では全端末に即座に反映されない。winverやWindows Updateの状態と合わせてリリースノートを継続確認すること。 筆者の見解 この変更は一見「小さな使い勝手の改善」に見えるが、実態はWindowsのエンタープライズセキュリティ戦略における重要な転換点だと評価している。 Microsoftはここ数年、「Security by Default（デフォルトでセキュア）」を掲げてWindows 11のセキュリティ機能を強化してきた。しかし、どれだけ優れた機能でも「展開できない」では意味がない。クリーンインストール必須という制約は、現実の企業IT運用とのギャップが大きすぎた。この制約解消は、SACを「理論上あるセキュリティ機能」から「実際に使えるセキュリティ機能」へと昇格させるものだ。 日本企業のエンドポイントセキュリティを見ると、まだEDRやXDR導入が進んでいない中堅・中小企業も多い。そういった組織にとって、追加コストなしで利用できるSACは、ランサムウェアや標的型攻撃への有効な第一防衛線になりうる。 今後はIntune経由での一元管理や、Microsoft 365 Defenderダッシュボードとの統合が強化されていくはずだ。Windows 11移行と合わせて、SACを組み込んだエンドポイントセキュリティポリシーの再設計を検討するタイミングが来た。 出典: この記事は This Windows 11 feature no longer requires clean-installing the system to activate it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

クラウドが「外に出られない」組織の福音 Microsoftが2026年2月、政府機関・防衛組織・金融・医療などの規制産業向けに「Sovereign Private Cloud」スタックを正式発表した。従来のソブリンクラウド戦略をさらに一歩進め、インターネット接続を完全に断ち切ったエアギャップ（Air-gap）環境でも、大規模言語モデル（LLM）を含むAIワークロードを安全に稼働できる体制が整った。 Sovereign Private Cloudの3本柱 今回発表されたスタックは、3つのコンポーネントで構成される。 Azure Local（旧Azure Stack HCI）の完全非接続対応 オンプレミスに設置したAzure Localが、ネットワーク接続なしでフルに機能するよう強化された。管理プレーン・課金・更新のすべてがオフライン運用に対応し、物理的に隔離された施設でもAzureサービスのエクスペリエンスを維持できる。 Microsoft 365 Local Teams・Exchange・SharePointなどM365の主要ワークロードをオンプレミスで完結させる構成だ。データが施設外に一切出ないことを保証しながら、M365 Copilotによる生成AI支援も利用可能になる。特筆すべきは、Copilotのデータ処理を自国内で行える国が新たに11か国追加された点で、日本を含む各国の規制要件への対応が加速している。 Foundry Local（旧Azure AI Foundry Local） LLMをオンプレミスのGPUクラスター上で推論・ファインチューニングできるプラットフォーム。GPT-4クラスの大規模モデルも含め、モデルのウェイトは施設内に留まる。外部APIコールは一切発生しないため、機密性の高いドキュメント処理や情報分析にも適用できる。 なぜこれが重要か——日本のIT現場への影響 日本では防衛省・内閣サイバーセキュリティセンター（NISC）・金融庁・医療機関など、クラウドへの移行を検討しながらもデータの国外持ち出し規制や秘密保護法の壁に直面してきた組織が数多く存在する。これまではオンプレミスに独自システムを構築するか、高コストのプライベートクラウドを選択するしかなかった。 今回のSovereign Private Cloudは「Azureと同じUX・同じAPIで、データは外に出さない」という要求を正面から満たす解だ。特に以下の組織にとって意味は大きい。 防衛・安全保障関連: 秘密情報を扱うシステムへのAI導入が現実的な選択肢になる 金融機関: FISC安全対策基準やデータ主権への対応をMicrosoftスタックで一本化できる 医療・自治体: 次世代電子カルテや行政DXでCopilot活用の道が開ける 実務での活用ポイント 1. 既存Azure Stack HCI環境の評価から始める すでにAzure Stack HCIを導入済みの組織は、Azure Localへのブランド統合も含め、エアギャップ対応ファームウェアへのアップグレードパスを確認すること。Microsoftはサポートマトリクスを更新しており、既存ハードウェアが対象になる場合がある。 2. Foundry LocalのGPU要件を早期に見積もる LLMをオンプレで動かすにはNVIDIA H100/A100クラスのGPUが必要になるケースが多い。調達リードタイムが長期化している現状を踏まえると、概念実証（PoC）の段階で機材選定を並行して進めるべきだ。 3. M365 Copilotのデータ処理先を確認する テナント管理者はMicrosoft 365 管理センターで「データ保存場所」と「Copilotのデータ処理地域」を確認し、今回の11か国拡大に日本が含まれているかを検証すること（現時点では順次展開中）。 4. ガバナンスポリシーの整備を先行させる Azure Policyをエアギャップ環境に持ち込む際、ポリシー定義の更新がオフラインになることを考慮したオペレーション手順の設計が必要になる。 筆者の見解 Sovereign Private Cloudの発表を見て、Microsoftがクラウドの定義そのものを拡張しようとしていると感じた。「クラウド＝インターネット経由でリソースを借りる」という常識を覆し、「Azureのオペレーティングモデルを、接続形態に関わらず提供する」という方向性だ。 この戦略はAWSやGoogle Cloudとの差別化において非常に有効だと思う。AWSのOutpostsも同様の方向性を持つが、M365とAzure AIを一体のスタックとして提供できるのはMicrosoftだけだ。特にCopilotというキラーアプリを「完全オンプレで使える」ことのインパクトは、日本の政府・公共セクターにおけるMicrosoft選定の後押しになるだろう。 一方で課題もある。エアギャップ環境ではモデルの更新・脆弱性パッチの適用がすべて手動または計画的なオフライン作業になる。AI安全性の観点から、LLMのモデルウェイト自体に仕込まれたリスクをどう管理するかは、今後の重要な論点になるはずだ。セキュリティと利便性のトレードオフを適切に設計できる人材・体制の整備が、導入組織に求められる次の課題といえる。 出典: この記事は Microsoft Sovereign Cloud adds governance, productivity and support for large AI models securely running even when completely disconnected の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Ignite 2025で発表されたAzure Copilotの大型アップデートが、クラウド運用の常識を塗り替えようとしている。単なる会話AIアシスタントの域を超え、クラウド管理ライフサイクル全体を自律的に調整する「エージェンティッククラウド運用（Agentic Cloud Ops）」という新しい運用モデルが正式に姿を現した。 Azure Copilotとは何か——6つの専門エージェント Azure Copilotは、クラウド管理の各フェーズに特化した6種類のAIエージェントを統合したアジェンティックインターフェースだ。現在ゲートドプレビューとして提供が始まっているこれらのエージェントは以下の通り： 移行エージェント（Migration Agent） — オンプレミスやマルチクラウド環境からAzureへの移行を自律的に支援。現時点でパブリックプレビューが開始済み デプロイエージェント（Deployment Agent） — アプリケーションやインフラのデプロイ作業を自動化 最適化エージェント（Optimization Agent） — コスト・パフォーマンス・リソース利用効率の継続的改善を担当 可観測性エージェント（Observability Agent） — ログ・メトリクス・トレースを横断した統合監視 レジリエンスエージェント（Resiliency Agent） — 障害への耐性評価と自動的な信頼性向上施策の実行 トラブルシューティングエージェント（Troubleshooting Agent） — インシデント発生時の根本原因分析と解決策の提示 重要なのは、これらが単発のコマンドに応答するだけでなく、複数のエージェントが連携して複合的な運用タスクを自律実行できる点だ。 ガバナンスとセキュリティ——現場が一番気にするポイント AIエージェントに自律的な操作権限を与えるとなると、真っ先に懸念されるのがガバナンスとセキュリティだ。Microsoftはこの点を明確に意識しており、Azure CopilotはRBAC（ロールベースアクセス制御）とAzure Policyの制約の範囲内でのみ動作する設計となっている。 さらに、エージェントの操作履歴は完全に記録され、コンプライアンス監査に対応できる。チャット履歴やアーティファクトデータをユーザー自身のストレージに保持できる「Bring Your Own Storage」オプションも提供され、データレジデンシーの要件にも柔軟に対応できる。 Azureインフラの進化——70リージョン体制とAIスケール対応 エージェント機能の基盤となるAzureインフラも大幅に強化されている。世界70以上のリージョン・数百のデータセンターを擁する体制に加え、2025年9月には大規模AIワークロード特化型データセンター「Fairwater」が稼働を開始。Atlanta拠点もこれに続く形で展開が進んでいる。 コンピュート面ではAzure Cobalt（独自Armプロセッサ）とAzure Boost（オフロードシステム）、コンテナ管理ではAKS Automatic、データベースではAzure HorizonDB for PostgreSQLがラインアップに加わり、AIスケールのワークロードに対応したスタックが整いつつある。 日本のIT現場への影響——なぜ今これが重要か 日本企業のAzure活用は急速に拡大しているが、多くの組織でクラウド運用人材の不足が深刻化している。特に中堅企業では、インフラエンジニアが監視・最適化・障害対応のすべてを少人数で回す構造が続いている。 Azure Copilotのエージェント群が本番稼働レベルに達した場合、これらのルーティン運用タスクの相当部分をAIに委任できるようになる。運用コスト削減という直接効果だけでなく、エンジニアがアーキテクチャ設計やビジネス価値創出に集中できる環境が整う点が大きい。 実務での活用ポイント 今すぐできること： 移行エージェントはパブリックプレビュー開始済み。オンプレミスからの移行プロジェクトを抱えている組織は早期評価の価値がある Azure Copilotプレビューへのサインアップページが公開されているため、利用申請を検討したい 準備しておくべきこと： Azure PolicyとRBACの整備が前提条件になる。エージェントはこれらの制約に従って動作するため、ポリシーが未整備だと効果が限定的になる エージェントの操作ログをどう監査プロセスに組み込むかを事前設計しておく 「AIが自律実行する範囲」と「人間が承認する範囲」の境界線を組織として決めておく 筆者の見解 エージェンティッククラウド運用というコンセプト自体は以前から語られていたが、今回のAzure Copilotはそれを具体的な製品として形にした点で一線を画す。6エージェントの役割分担は、従来のITSM（ITサービスマネジメント）プロセスと自然に対応しており、既存の運用フローへの統合を意識した設計だと感じる。 一方で、ゲートドプレビューという段階はまだ「選ばれた組織と一緒に作り込む」フェーズであり、全面的な本番利用までには少なくとも半年から1年の成熟期間が必要だろう。AIエージェントが誤った判断でリソースを削除したり、意図しないコスト増を引き起こすリスクも現実にあるため、慎重なロールアウト計画が不可欠だ。 ...

MicrosoftがAzure AI Foundry（旧Azure OpenAI Service）上で、コーディング特化モデル「GPT-5.2-Codex」を一般提供（GA）開始した。40万トークンという桁違いのコンテキストウィンドウ、50以上のプログラミング言語対応、マルチモーダルによるコーディング支援——この3点が揃ったモデルが、既存のAzureセキュリティ境界の内側でそのまま使えるようになった意義は極めて大きい。 40万トークンのコンテキストウィンドウが変えること 現在広く使われているGPT-4系モデルのコンテキスト上限は最大128Kトークン程度だが、GPT-5.2-Codexはその約3倍にあたる40万トークンを一度の推論に投入できる。これが実務上何を意味するかというと、大規模なモノリシックコードベース全体をプロンプトに含めながら、リファクタリング・脆弱性スキャン・ドキュメント生成を一気通貫で依頼できるということだ。 たとえば、数万行規模のJavaやC#のレガシーシステムであっても、複数ファイルにまたがる依存関係ごとモデルに渡してバグの根本原因を特定させることが現実的になる。これまでは「どのファイルを切り取ってプロンプトに貼るか」という職人技が必要だったが、その手間が大幅に削減される。 セキュアコーディングとインシデント対応への対応 今回のリリースで特筆すべきは、セキュアコーディングパターンの提示・脆弱性調査・インシデント対応という用途を明示的にターゲットにしている点だ。OWASP Top 10やCWE（Common Weakness Enumeration）への対応コードを自動的に提案したり、既存コードにおけるインジェクション脆弱性を検出したりといった用途が想定されている。 セキュリティ観点でさらに重要なのは、Azure OpenAI のVNet統合・プライベートエンドポイント・カスタマーマネージドキー（CMK）といった既存のガバナンス機能をそのまま流用できる点だ。ソースコードは企業の外には一切出ない。これは特に金融・医療・官公庁系の日本企業にとって、「ChatGPTは使えないがAzure経由なら使える」という調達ルールに適合する。 実務での活用ポイント 1. CIパイプラインへのセキュリティレビュー組み込み GitHub ActionsやAzure DevOpsのPRトリガーで、GPT-5.2-Codexを呼び出して差分コードの脆弱性チェックを自動化するアーキテクチャが現実的になった。ローカルSASTツール（Semgrepなど）と組み合わせれば、誤検知を絞り込みながら精度の高いセキュリティゲートを構築できる。 2. レガシーシステムの移行調査に使う 2025年以降、多くの日本企業でオンプレ→Azureへの移行プロジェクトが活発化している。40万トークンのウィンドウを活かして、古いCOBOLやVB6のコードをそのまま入力し「どの処理がAzure Functions化できるか」の分析を依頼することが可能だ。 3. マルチモーダル機能でアーキテクチャ図からコードを生成 画像入力に対応しているため、手書きのシーケンス図やER図をスキャンして「このアーキテクチャをAzure Bicepで記述して」という使い方も有効だ。設計→実装のギャップを縮める新しいワークフローが生まれつつある。 筆者の見解 OpenAIがCodexブランドを復活させた形でこのモデルが登場したことは、Microsoftの戦略を読む上で興味深い。GPT-4oやGPT-4.5のような汎用モデルとは別に、コーディング特化モデルを独立したSKUとして提供する方向性は、Copilot製品群との差別化という観点で理にかなっている。GitHub Copilotが「IDE補完」の文脈で使われる一方、GPT-5.2-Codexは「エージェント型の大規模コード処理」に特化する分業構造が見えてくる。 日本市場においては、AIガバナンス・情報漏洩対策の観点から「クラウドに出せないコード」を抱える企業がまだ多い。そこへAzureセキュリティ境界内での提供という形でMicrosoftが打ち込んだこの一手は、まさに「日本市場向けの現実解」として機能するだろう。2026年後半にかけて、Azure AIを核にしたセキュアなコード生成基盤の整備が日本企業の競争軸になると見ている。早期に評価検証を始めた組織が、次の開発生産性競争で頭一つ抜け出すことになる。 出典: この記事は Announcing GPT‑5.2‑Codex in Microsoft Foundry: Enterprise‑Grade AI for Secure Software Engineering の内容をもとに、筆者の見解を加えて独自に執筆したものです。

E5ユーザーに朗報、Security Copilotが追加コストゼロで使える時代へ Microsoftが2026年4月、M365エコシステムに大きな変化をもたらす発表を相次いで行った。なかでも注目度が高いのが、Microsoft 365 E5ライセンスへのSecurity Copilot自動ロールアウトだ。4月20日から6月30日にかけて段階的に有効化され、追加ライセンスの購入なしにAI駆動のセキュリティ機能を利用できるようになる。 あわせて、AI活用の「次のフェーズ」を見据えたCopilot Wave 3、エージェント管理基盤のMicrosoft Agent 365、そして統合ライセンスMicrosoft 365 E7（Frontier Suite）も正式に発表された。単なる機能追加ではなく、企業がAIを「試す」段階から「組織全体で運用する」段階へ移行するための基盤整備という意味合いが強い。 Copilot Wave 3・Agent 365・E7ライセンスの全体像 Copilot Wave 3 Word・Excel・PowerPoint・OutlookといったMicrosoft 365アプリへのCopilot統合がさらに深化。文書作成・データ分析・要約・コラボレーションがアプリ内で完結するようになる。さらに、バックエンドモデルの選択肢としてOpenAIに加えてAnthropic Claudeも利用可能になるという柔軟性が追加された点は、「特定のタスクに最適なモデルを使い分けたい」という企業ニーズに応えるものだ。 Microsoft Agent 365 AIエージェントの作成・管理・ガバナンスを一元化する新プラットフォーム。部門ごとにバラバラに作られたエージェントが統制なく動き続けるリスクを防ぐ目的で設計されており、IT管理者がエージェントのアクセス権・ログ・ポリシーを横断的に管理できる。 Microsoft 365 E7（Frontier Suite） E5 + Copilot + Agent 365を1ライセンスにバンドルした新SKU。AI活用を本格展開したい企業向けに、ライセンス管理の煩雑さを解消する狙いがある。 Security Copilot in E5 — 何が変わるのか Security Copilotは以下のMicrosoftセキュリティ製品に組み込まれる形で展開される。 Microsoft Defender（脅威検出・EDR） Microsoft Entra（ID・アクセス管理） Microsoft Intune（デバイス管理） Microsoft Purview（データセキュリティ・コンプライアンス） SOCアナリストが日々直面する「アラートの洪水」に対して、AIが優先度付け・根本原因分析・対処手順の提示を自動で行う。これまでSecurity Copilotは有償のアドオンであり、利用企業は限られていたが、E5バンドルに含まれることで日本国内のE5採用企業も自動的にロールアウト対象となる。 実務への影響 — 日本のIT管理者・セキュリティ担当者が今すぐやるべきこと 1. ロールアウトの準備確認 4月20日以降、E5テナントでSecurity Copilotが順次有効化される。突然AIが有効になって戸惑わないよう、Microsoft 365管理センターで有効化スケジュールを確認しておこう。 2. データアクセス権限の棚卸し Security CopilotはDefenderやPurviewのデータを参照する。意図せず機密情報にアクセスされないよう、条件付きアクセス（Conditional Access）・DLPポリシー・監査ログ設定を事前に整備しておくことが重要だ。 3. Agent 365のガバナンス設計 部門主導でPower AutomateやCopilot Studioでエージェントを作っている企業は少なくない。Agent 365の登場を機に、エージェントのオーナーシップ・レビュープロセス・廃止ルールを明文化した社内ポリシーを整備するタイミングだ。 ...

Teams、また値上げか——と思ったら逆だった 「Microsoftのライセンス変更」と聞くと、多くのIT管理者は条件反射的に身構えるだろう。2024〜2025年にかけて相次いだ価格改定の記憶がまだ新しい。しかし今回は違う。2026年1月22日に発表され、4月1日から有効となったこの変更は、追加費用なしで機能が拡充される、珍しいアップサイドの改定だ。 具体的には、これまでTeams Premium（月額約10ドル/ユーザー）が必要だったMicrosoft PlacesのエンドユーザーUI機能と、Town Hall・ウェビナーの高度機能群が、Teams Enterprise（コアライセンス、月額約5.25ドル/ユーザー）に含まれるようになった。日本企業の多くが契約しているMicrosoft 365 E3/E5、Business Standard/Premiumにも適用される。 今回の変更点：3つのポイント 1. Microsoft Places のエンドユーザー機能が全面開放 Places Explorer と Places Finder がTeams Premiumなしで利用可能になる。 Places Finder：フロアマップ、画像、利用可能な設備情報などを元に会議室・デスクを予約できる機能。従来の「Room Finder」から大幅に進化した体験を全ユーザーに提供。 Places Explorer：マップベースでスペースを視覚的に探して予約できる。オフィスのどのエリアに誰がいるか把握しやすくなり、ハイブリッドワークの出社調整にも活用できる。 ただし、スペース・デスクの「登録数」に応じたコストは別途発生する（スペース管理側の課金モデルに変更）。つまり、ユーザー側のライセンスは安くなるが、オフィスリソースの登録数に課金される仕組みに転換された点は注意が必要だ。 2. Town Hall・ウェビナーの高度機能もコアへ eCDN（Enterprise Content Delivery Network）による大規模配信時の帯域最適化、ストリーミングチャット、組織ブランドを用いたメールカスタマイズなどが追加料金なしで利用可能になった。 大規模な全社集会（タウンホール）を定期実施している企業にとっては、これだけでTeams Premiumの費用対効果の見直し材料になり得る。 3. Teams Shared Space ライセンスへの改名と機能追加 「Common Area Phone (CAP)」→「Teams Shared Devices」と変遷してきたライセンスが、今回「Teams Shared Space」に改名。管理者向けのスペース管理・分析機能が追加され、1ライセンスにつき最大4デスクのリソース管理に対応する。 実務への影響：日本のIT管理者・エンジニアはここを見ろ ライセンスの棚卸しタイミング：今回の変更で、Teams Premiumを契約していた主な理由が「Places機能を使いたい」「タウンホールを本格運用したい」だった場合、Teams Premiumの継続購入の必要性を再検討する余地がある。逆に、AIミーティング要約（Intelligent Recap）など引き続きPremiumにしか含まれない機能に依存している場合は変わらない。 Places展開の再評価：コスト障壁が下がったことで、「試験導入で止まっていたPlaces本格展開」を推進するチャンスだ。フロアマップ整備やスペース登録に手間はかかるが、ハイブリッドワークの出社率向上・無駄な会議室予約削減に直結する。特にオフィス回帰を進めている企業は検討価値が高い。 eCDNの恩恵：全社配信イベントで映像品質が安定しなかった組織は、eCDNが標準で使えるようになることで改善が期待できる。配信担当者はTeams管理センターでeCDN設定を確認しておこう。 筆者の見解 今回の改定は、Microsoftが「Teamsコアの価値最大化」と「Premiumの差別化軸の見直し」を同時に行っているサインだと読んでいる。 Teams Premiumが登場した2023年当初は、AI機能・ウェビナー・Placesなど多様な機能を一束にした「盛り合わせ」的な位置づけだった。しかし、M365 Copilotが本命のAIライセンスとして確立されつつある今、Teams Premiumの存在意義は再定義が必要になっている。今回、PlacesとTown Hallをコアに落とし込むことで、PremiumはよりAI特化・インテリジェンス特化のアドオンとして純化させる意図が透けて見える。 日本市場においては、ハイブリッドワークのインフラ整備が欧米と比べてまだ途上の企業が多い。Places機能がコアに含まれることは、「まずは使ってみよう」という組織の背中を押す効果がある。セキュリティやプライバシー観点で慎重な日本企業でも、追加費用なしで試せるなら導入ハードルは格段に下がる。 ライセンスコストを最適化しながら現場のコラボレーション基盤を強化できる今回の変更は、IT部門にとって「良い変化」として素直に歓迎したい。年度更新のタイミングで、契約内容の見直しを強くお勧めする。 出典: この記事は Microsoft Teams April 2026 Licensing Update — Places and Advanced Town Hall Features Move into Core の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Copilot Studioが、単なるチャットボット作成ツールからエンタープライズ向けAIオーケストレーション基盤へと大きく飛躍した。マルチエージェント協調機能が正式GA（一般提供開始）となり、Microsoft Fabric連携・M365 Agents SDK対応・エージェント間通信（A2A）プロトコルの3本柱が出揃った。AIエージェント活用を本番展開へ押し上げる上で、今最も注目すべきアップデートのひとつだ。 マルチエージェントとは何か——なぜ「一体では足りない」のか AIエージェントの初期導入段階では、「ひとつの業務に特化したエージェントを作る」アプローチが有効だった。しかし組織規模での活用が進むにつれ、データチームが作ったエージェント・アプリ開発チームが作ったエージェント・生産性向上チームが作ったエージェントがバラバラに存在し、それらを連携させる際に脆弱な手作りの統合コードが必要になるという壁にぶつかる。 この「エージェントのサイロ化問題」を解消するのが、今回GAとなったマルチエージェントオーケストレーション機能だ。 3つの新機能——それぞれの役割 Microsoft Fabric連携 Copilot StudioのエージェントがFabricエージェントと連携し、企業の大規模データ・分析基盤に直接アクセスできるようになった。これまでデータ集約型のシナリオはそのたびに個別エンジニアリングが必要だったが、ビジネス向けエージェントがFabricのデータ資産と自然につながり、より正確でコンテキストを踏まえた回答を生成できる。 SQL ServerやAzure Synapse等に接続されたFabricレイクハウスのデータを、ビジネスユーザー向けのエージェント体験にシームレスに橋渡しするパイプラインが実現する。 M365 Agents SDK対応 Microsoft 365 Agents SDKを使ってビルドされたエージェントを、Copilot Studioのオーケストレーション下で組み合わせて動かせるようになった。たとえば「データ取得ロジック」「ビジネスルール適用」「承認ワークフロー」など、すでに個別エージェントとして実装済みのロジックを再利用・合成し、クロスアプリのワークフローを組み立てられる。重複実装を減らし、エージェント体験の一貫性を保てる点が大きい。 A2A（Agent-to-Agent）プロトコル 最も将来性が高いのがこのA2A対応だ。Copilot Studioのエージェントが、Microsoft製に限らずサードパーティ製のエージェントともオープンプロトコルで直接通信・委任できるようになった。特定ベンダーのエコシステムに閉じない相互運用性を実現しており、「AIエージェントのAPIエコノミー」とも呼べる時代の基盤となりうる。 実務への影響——日本のIT現場での活用シナリオ IT管理者・ガバナンス担当者へ： 複数エージェントが連携するとなると、どのエージェントが何をしたかのトレーサビリティが経営・コンプライアンス上の課題になる。Copilot Studioは今回のアップデートでガバナンスコントロールも強化されており、本番展開前に権限・ログ設定を整備することを強く推奨する。 アプリ開発チームへ： すでにM365 Agents SDKで作ったエージェントがあるなら、それをCopilot Studioオーケストレーターの「サブエージェント」として組み込む設計への移行を検討する価値がある。スクラッチで再実装するより大幅に工数が削減できる。 データエンジニアリングチームへ： FabricとCopilot Studioの橋渡しが正式サポートになったことで、「データカタログに自然言語でアクセスするエージェント」の本番化ハードルが下がった。まずFabricのデータドメインを整理し、エージェントに公開する範囲を設計する段階から着手するとよい。 筆者の見解 Copilot Studioは以前から「ローコードでチャットボットを作るツール」として認知されてきたが、今回のGA発表で性格が明確に変わった。AIエージェントのオーケストレーション基盤というポジショニングだ。 A2AプロトコルのオープンAPI化は、単なる機能追加以上の意味を持つ。MicrosoftはここでAIエージェントの「相互接続標準」の主導権を握ろうとしている。AWSやGoogle CloudもエージェントフレームワークをGA化しつつある中、A2Aの標準化競争はこれから本格化するだろう。 日本企業にとって現実的なシナリオは、まず社内に散らばった既存エージェント資産の棚卸しから始めることだ。SharePoint連携Bot・Teams通知Bot・Power Automate連携エージェントなど、すでに動いているものをCopilot Studioの傘下で「つなぐ」だけでも、体験の一貫性と管理効率は大幅に向上する。 「エージェントをひとつ作る」から「エージェント群を設計する」へ——この思考の転換が、これからのエンタープライズAI戦略の核心になると確信している。 出典: この記事は Copilot Studio GA Adds Multi-Agent Orchestration with Fabric, M365 SDK and A2A Protocol の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のタスクバー、ついに移動できるようになる Microsoftは、Windows 11においてタスクバーの位置を画面上で自由に変更できる新機能の早期プレビューを公開した。長年にわたるユーザーからの要望がついに実現に向けて動き出した形だ。 Windows 10から続く「タスクバー固定」問題 Windows 10までは、タスクバーを画面の上部・左側・右側・下部のいずれかに配置する設定が標準で提供されていた。しかしWindows 11では刷新されたデザインの影響で、タスクバーは画面下部への固定が必須となり、移動できなくなった。 これに対してユーザーコミュニティでは当初から強い反発があり、Microsoftのフィードバックハブにも多数の要望が寄せられていた。サードパーティ製ツール（「StartAllBack」「ExplorerPatcher」など）を使ってタスクバーを移動させるユーザーも多かったが、公式サポートはなく、Windowsアップデートのたびに動作が壊れるリスクも伴っていた。 公開された早期プレビューの内容 今回Microsoftが公開したのは、タスクバーを画面のさまざまな位置に移動できる機能の初期デモだ。正式な機能仕様や提供時期についての詳細は明らかにされていないが、開発が進んでいることが確認された。 プレビューの段階では、移動先の位置や動作の詳細は流動的とみられ、実際にInsiderプログラム（Windows Insider Program）での配信が始まるまでには変更が加えられる可能性が高い。 日本のユーザーへの影響 タスクバーの位置変更は、特に縦型モニターや超ワイドモニターを使用するユーザー、あるいはmacOSのDockに慣れた環境から移行したユーザーにとって待望の機能だ。複数モニター構成での作業効率向上も期待される。 企業のIT管理者にとっても、グループポリシーやMDM（モバイルデバイス管理）を通じた配置の標準化ができるようになる可能性があり、Windows 11移行を後押しする要因にもなり得る。 今後の展開に注目 MicrosoftはWindows 11の使い勝手に関するフィードバックを継続的に収集しており、このタスクバー移動機能もその成果のひとつといえる。正式な提供開始時期は未定だが、Windows Insiderプログラムを通じて近々テストが行われる見通しだ。最新情報はMicrosoft公式ブログやWindows Insider Blogで随時確認したい。 元記事: Windows 11 is getting movable taskbar, and Microsoft revealed an early look at it