Tech News JP

Microsoft、Windows全バージョンから伝統のコマンドラインツールを正式削除 Microsoftは、Windows 11の25H2・24H2・23H2、そしてWindows 10のすべてのサポート対象バージョンとWindowsサーバー製品から、長年にわたり使われてきたコマンドラインツールを正式に削除すると発表した。 廃止の背景 今回の削除は突然の決定ではない。Microsoftは2021年のWindows 10 バージョン21H1の時点で、当該ツールを「非推奨（deprecated）」として公式にアナウンスしていた。それから数年の移行期間を経て、今回ついに全バージョンからの正式削除という最終段階に踏み切った形だ。 非推奨から正式削除までのこうした段階的アプローチは、Microsoftが近年採用する標準的な廃止プロセスであり、企業や開発者に十分な移行時間を確保する目的がある。 影響範囲と代替手段 影響を受けるのはWindows 11の現行サポートバージョン（23H2・24H2・25H2）に加え、Windows 10、さらにWindowsサーバー製品群と広範にわたる。 Microsoftは代替手段として、PowerShellおよびWindows Management Instrumentation（WMI）をPowerShell経由で利用することを推奨している。PowerShellはWMIクラスへのアクセスを Get-WmiObject や Get-CimInstance コマンドレットで提供しており、従来のコマンドラインと同等以上の機能を持つ。 企業IT管理者への影響 日本国内でも多くの企業システムやIT管理スクリプトに組み込まれているケースがあるため、IT部門は以下を早急に確認することが望ましい。 社内スクリプト・バッチファイルでの使用有無の棚卸し 監視・管理ツールによる依存関係の確認 PowerShellベースのスクリプトへの移行計画の策定 Windows合理化の一環 Microsoftは近年、レガシーコンポーネントの整理を積極的に進めている。WordPadの削除（2023年）、Internet Explorerの廃止（2022年）に続き、今回の決定も「Windowsの合理化とセキュリティ強化」という長期方針の一環と見られる。 古いツールへの依存を断ち切り、よりモダンな管理インターフェースへの移行を促すことで、Windowsのセキュリティポスチャー（セキュリティ態勢）の向上を図る狙いがある。 移行を検討している管理者は、Microsoft公式のPowerShell移行ガイドや、Windows管理センター（Windows Admin Center）の活用も選択肢に入れると良いだろう。 元記事: Microsoft formally removes a command line tool from Windows 11 25H2, 24H2, 23H2, Windows 10

英国競争当局がMicrosoftのビジネスソフト市場を調査へ 英国の競争・市場庁（CMA：Competition and Markets Authority）は、Microsoftのビジネスソフトウェア市場における支配的地位について、正式な調査を開始すると発表した。調査の焦点は、Windows、Microsoft Teams、そしてAIアシスタント「Copilot」のライセンス体系と市場慣行にある。 なぜ今、調査が始まるのか Microsoftはここ数年、企業向けソフトウェア市場で圧倒的なシェアを維持している。特に新型コロナウイルス禍以降、リモートワーク需要の急増に伴いTeamsの利用が爆発的に拡大。さらに生成AIブームを追い風に、Microsoft 365スイートへのCopilot統合も加速している。 CMAはこうした動きが、競合他社にとって不公平な障壁となっている可能性があると判断。バンドル販売や契約上の制約が、Slack（Salesforce傘下）やZoom、Google Workspaceといった競合サービスの参入を阻んでいないか検証する方針だ。 ライセンス体系が問題の核心 欧州では2023年、欧州委員会がMicrosoftに対してTeamsをOffice 365/Microsoft 365から分離販売するよう求め、Microsoftはこれに応じた。英国でも類似の懸念が浮上しており、CMAは特にエンタープライズ向けライセンスの構造が市場競争を歪めていないかを精査する。 Copilotについても、AI機能を既存の企業契約にどのように組み込んでいるかが問われる。企業が特定ベンダーのAIサービスに事実上「ロックイン」される構造になっていないかが焦点となりそうだ。 日本企業への示唆 日本でも多くの企業がMicrosoft 365を基幹インフラとして採用しており、今回の調査結果は無縁ではない。欧州・英国での規制強化がライセンス体系の変更につながれば、グローバル展開する企業のIT調達戦略にも影響が及ぶ可能性がある。 CMAの調査は数か月から1年以上かかる見通しで、最終的な勧告次第ではMicrosoftのライセンス販売方法に大きな変更が求められることになる。テック業界全体が注目する調査となりそうだ。 元記事: UK watchdog to probe Microsoft business software over market dominance concerns

Microsoftは2026年3月を通じて、ビジネスコミュニケーションツール「Microsoft Teams」に多数の新機能と改善を順次展開した。今回の更新は単発の大型リリースではなく、月を通じて段階的に適用されたもので、チャット、会議、そして日常的なワークフロー全般にまたがる幅広い改善が含まれている。 チャット機能の強化 チャット周りでは、メッセージの検索性や整理に関する改良が加えられた。スレッドの視認性が向上し、長期にわたるやりとりを追いやすくなった。また、リアクション機能やメッセージの固定表示といった既存機能の使い勝手も細かく磨かれており、日々の情報共有がよりスムーズになっている。 会議体験の向上 オンライン会議に関しては、参加者の管理や発言権（スピーカー制御）に関連する操作が整理された。ノイズキャンセリングや背景フィルターといった既存のAI機能も継続的に精度が高められており、ハイブリッドワーク環境における会議品質の底上げが図られている。日本でも定着しつつあるリモート会議の場面で、その恩恵を実感しやすい改善といえる。 ワークフロー連携の改善 業務フロー全般においては、TeamsとMicrosoft 365の各アプリ（OutlookやSharePoint、Copilotなど）との連携がさらに深化した。タスク管理や承認フローをTeams内で完結させる動きが加速しており、アプリを行き来するコンテキストスイッチを減らす狙いがある。 日本企業への影響 国内でもTeamsはMicrosoft 365ライセンスに標準で含まれることから、多くの企業・組織で導入が進んでいる。今回のアップデートは自動的に適用されるため、ユーザー側での追加作業は基本的に不要だ。ただし、新機能の中には管理者がポリシーで有効化する必要があるものも含まれる場合があるため、IT管理者は変更内容を確認しておくことが推奨される。 Microsoftは毎月このようなアップデートを積み重ねており、Teamsは着実に進化を続けている。競合するZoomやSlackとの差別化を図りながら、Microsoft 365エコシステムの中核プラットフォームとしての地位を強化する姿勢が、今回の更新からも読み取れる。 元記事: Here are all the new features Microsoft added to Teams in March 2026

MicrosoftがCopilotを「エンターテインメント目的のみ」と規約に明記 Microsoftの生成AIアシスタント「Microsoft Copilot」の利用規約（Terms of Use）に、サービスが「エンターテインメント目的のみ（for entertainment purposes only）」であるとする文言が含まれていることが注目を集めている。Hacker Newsで366ポイントを獲得し、145件のコメントが寄せられるなど、技術者コミュニティで大きな話題となっている。 利用規約の主なポイント 2025年10月24日付で更新されたCopilotの利用規約は、読みやすさと明確さを重視して全面的に書き直されたと説明されている。今回の改訂では以下の点が明記された。 Copilot Actionsおよびショッピング体験に関する新規条項の追加 行動規範（Code of Conduct）の改訂——できること・できないことの明確化 免責事項の強調——Copilotの回答が不正確・不完全・不適切になり得ることを利用者に明示 規約では「Copilotは良い回答を提供しようとするが、誤りを犯すこともある」と率直に認めており、「説得力があるように見えても、不完全・不正確・不適切な回答が表示される場合がある」と警告している。また、インターネット上の情報を参照して回答を生成するが、その内容をMicrosoftはコントロールできないとも明記している。 「判断は利用者自身で」 規約はさらに、「Copilotから得た情報をもとに意思決定や行動をする前に、必ず自分で判断し情報を確認するように」と求めている。不適切な回答を見た場合は、フィードバック機能を通じて報告することも推奨されている。 日本への影響と背景 日本国内でも、企業や個人がCopilotを業務・学習・情報収集に活用するケースが急増している。こうした中で今回の規約表現は、AIツールを「信頼できる情報源」として扱うことへのリスクを改めて浮き彫りにした形だ。 医療・法律・財務など専門性の高い判断が求められる領域では、AIの出力をそのまま利用することは特に危険を伴う。「エンターテインメント目的」という表現はいわゆる法的免責（ディスクレーマー）の一環とも読めるが、企業としての公式見解がここまで明示された点は見逃せない。 AI時代のリテラシーが問われる ChatGPTやGeminiなど他の主要AIサービスも同様の免責事項を設けているが、「エンターテインメント目的」という表現の強さは異例とも言える。生成AIの爆発的な普及が続く中、利用者一人ひとりが情報の正確性を自ら検証する「AIリテラシー」の重要性が、あらためて問われている。 元記事: Microsoft: Copilot is for entertainment purposes only

Mistral AI、多機能統合モデル「Mistral Small 4」をリリース フランスのAIスタートアップMistral AIは、新モデル「Mistral Small 4」を公開した。同社がこれまで別々に提供していた複数の専門モデルを1つに統合したのが最大の特徴で、Apache 2.0ライセンスのもと商用利用も可能だ。 4つのモデルを1つに Mistral Small 4は、以下の4つの役割を単一モデルで担う。 Mistral Small（命令追従・一般チャット） Magistral（推論・思考） Pixtral（マルチモーダル・画像理解） Devstral（エージェントコーディング） 従来はタスクに応じてモデルを切り替える必要があったが、Small 4ではAPIを変えずにすべてのワークロードを処理できる。システム設計の複雑さを減らし、運用コストを下げることが狙いだ。 アーキテクチャ：MoEで「軽さ」と「賢さ」を両立 アーキテクチャにはMixture-of-Experts（MoE）を採用。総パラメータ数は1,190億（119B）と大規模だが、1トークンあたりの推論に使うアクティブパラメータは約60億（6B）に抑えられている。埋め込み・出力層を含めても80億（8B）程度であり、実際の計算コストは総パラメータ数ほど大きくない。128の専門家（エキスパート）のうち、各トークン処理時に4つだけが有効化されるスパース構造が効率化の鍵だ。 コンテキストウィンドウは256,000トークンと広大で、長文ドキュメントの分析、コードベース全体の探索、複数ファイルにまたがる推論といった実用的なエンジニアリングシナリオで効果を発揮する。 推論の深さをリクエストごとに調整可能 注目の新機能が、推論努力量（reasoning_effort）のリアルタイム制御だ。開発者はAPIリクエストごとにこのパラメータを指定できる。 設定値 挙動 none 高速・簡潔な応答（Mistral Small 3.2相当） high 段階的な深い思考・詳細な回答（Magistral相当） これにより、軽量な質問には素早く、複雑な問題には時間をかけて思考させるという使い分けが、同一モデル・同一エンドポイントで完結する。「高速モデル」と「推論モデル」を別々に管理する必要がなくなり、プロダクト開発の効率が向上する。 処理速度と効率の改善 Mistralによると、Mistral Small 3比でエンド・ツー・エンドの完了時間が40%短縮、スループット最適化構成では1秒あたりの処理リクエスト数が3倍に向上したという。 ベンチマーク結果 Mistralが公開したベンチマーク結果では、Small 4（推論モード）はGPT-OSS 120Bと同等以上のスコアを複数のベンチマーク（AA LCR、LiveCodeBench、AIME 2025）で記録した。特筆すべきは出力効率で、QwenシリーズがAA LCRで同等性能を出すために5,800〜6,100文字の出力を要するのに対し、Small 4は1,600文字程度で同等の精度を達成したとされる。LiveCodeBenchではGPT-OSS 120Bを上回りつつ、出力量を約20%削減している。 ただし、これらはMistral自身が公開した数値であり、第三者による独立した検証は今後に委ねられる部分も多い。 日本の開発者への影響 国内でも、RAGシステムやエージェントAIの開発において「モデルの使い分け」が運用上の課題となっているケースは多い。Small 4のような統合型モデルが実用レベルで機能するなら、マルチモデル管理の負担軽減につながる可能性がある。Apache 2.0ライセンスでの公開により、オンプレミス環境やプライベートクラウドでの自社ホスティングも検討しやすい。 元記事: Mistral AI Releases Mistral Small 4: A 119B-Parameter MoE Model that Unifies Instruct, Reasoning, and Multimodal Workloads

GoogleのTurboQuant、LLMインフラの常識を覆す圧縮技術を発表 Googleが発表した量子化技術「TurboQuant」が、大規模言語モデル（LLM）のインフラ業界に衝撃を与えている。最大の特徴は、モデルの再学習（ファインチューニング）を一切必要とせず、精度損失ゼロのままKVキャッシュ（Key-Valueキャッシュ）を3ビットへ圧縮できる点だ。 KVキャッシュとは何か KVキャッシュとは、LLMが推論（テキスト生成）を行う際に計算済みの中間状態を保持するメモリ領域のことだ。長い文章を扱うほど、またバッチサイズ（同時処理リクエスト数）が増えるほど、このキャッシュは膨大なGPUメモリを消費する。現在の多くのモデルでは16ビットや8ビットの浮動小数点数で保存されており、これがサーバーコストを押し上げる主要因のひとつになっていた。 TurboQuantが実現すること TurboQuantは、KVキャッシュを3ビットに圧縮することで6倍以上のメモリ削減を実現する。既存の量子化手法では精度劣化や再学習コストが課題だったが、TurboQuantはこの両方を解決したと主張しており、これが業界で注目を集めている最大の理由だ。 メモリ消費が大幅に減少することで、同一ハードウェアで扱えるコンテキスト長の拡大や、同時処理リクエスト数の増加が見込める。クラウドプロバイダーやLLMサービス事業者にとっては、インフラコストの抜本的な見直しにつながる可能性がある。 48時間でllama.cppとApple MLXに移植 技術の影響力を示すように、論文公開から48時間以内に主要なオープンソース実装への移植が報告されている。Meta製の軽量推論ライブラリ「llama.cpp」と、AppleのシリコンチップをターゲットにしたMLフレームワーク「Apple MLX」の両方に対応コードが登場した。 この迅速な移植は、TurboQuantがアルゴリズムとして実装しやすい設計になっていることを示唆している。日本でもローカルLLMの実行にllama.cppを活用しているエンジニアは多く、実用的な恩恵が比較的早期に広がる可能性がある。 インフラ業界への波紋——メモリチップ株が下落 TurboQuantの発表はソフトウェア分野を超えた影響も起こしている。LLMの需要拡大を背景に株価を上げていたメモリチップメーカーの株価が発表後に下落したと報じられており、投資家が「AIのメモリ需要が想定より早く圧縮技術で緩和されるのではないか」と警戒していることをうかがわせる。 今後の展望 現時点ではKVキャッシュの圧縮が対象だが、モデルウェイト全体への応用や、エッジデバイス（スマートフォン、組み込み機器）での推論実行への展開も議論されている。再学習不要という特性は、既にデプロイ済みのモデルにもそのまま適用できることを意味しており、現場への導入ハードルは低い。 LLMの活用が本格化する中、TurboQuantはクラウドインフラのコスト構造と、エッジでのAI実行可能性の両方を同時に変えうる技術として、今後も注目が続きそうだ。 元記事: Google’s TurboQuant: The Compression Breakthrough That Could Reshape LLM Infrastructure

Windows 11が本格的なゲーミングOSへ——「Xbox Mode」が2026年4月に登場 MicrosoftはGDC（ゲーム開発者会議）2026において、Windows 11向けの新機能「Xbox Mode」を2026年4月より段階的に提供開始すると正式発表した。同時に、次世代Xboxコンソールの開発コード「Project Helix」の詳細も初公開され、MicrosoftのゲーミングエコシステムがXbox Game Pass登場以来最大の変革期を迎えようとしている。 Xbox Modeとは何か Xbox Modeを有効にすると、Windows 11がコンソールライクなゲーミング環境に変身する。コントローラー操作に最適化されたフルスクリーンUIが起動し、Xbox本体のダッシュボードに近い操作感でゲームを楽しめる。バックグラウンドで動作する不要なWindowsプロセスを一時停止し、電源設定を自動最適化することで、ゲームパフォーマンスの向上を図る。 ゲームライブラリの管理も大幅に改善される。Xbox Game Pass、Microsoftストア、Steam、Epic Games Storeなど複数のプラットフォームのゲームが一つのインターフェースに統合され、購入先を問わずXbox Liveを通じた実績管理が可能になる。日本でも人気の高いSteamとの統合は、PCゲーマーにとって特に魅力的な機能だろう。 技術の核心——DirectX ML Xbox Modeの技術的な目玉が「DirectX ML」だ。DirectX 12 Ultimateに直接組み込まれたこの機械学習フレームワークは、リアルタイムのアップスケーリング、フレーム生成、AIによるテクスチャフィルタリングを実現する。 NVIDIAのDLSSやAMDのFSR（FidelityFX Super Resolution）と同様の技術だが、決定的な違いがある——プラットフォーム非依存であることだ。DirectML（Direct Machine Learning）を基盤とし、NVIDIAのテンソルコアだけでなく、AMDやIntelの対応GPUでも動作する。GDCでのデモでは、対応タイトルで視覚品質を維持しながら40〜70%のパフォーマンス向上が示された。 ドライバーレベルで動作するため、開発者側の実装コストも低い。DirectX 12 Ultimateを使用するゲームは、Xbox Modeで起動するだけで自動的にDirectX MLの恩恵を受けられる。当初はXbox Mode限定で提供され、通常のWindows環境への展開時期は未定とのことだ。 次世代Xbox「Project Helix」——AIゲーミングに注力 「Project Helix」は次世代Xboxコンソールの開発コード名だ。詳細は限られるが、カスタムAMD SoCを搭載し、Windows PCのゲーミングアーキテクチャと共通の設計思想を持つとされる。「Helix（二重螺旋）」という名称から、業界アナリストは従来型コンソールとクラウドネイティブデバイスの並行展開、もしくはモジュール型ハードウェアの可能性を指摘している。 Microsoftはローカルとクラウドゲーミング間の「シームレスな移行」を強調しており、Xbox Cloud Gamingとの深い統合が予想される。性能目標は非公開だが、「AIで強化されたゲーミングにおける世代的飛躍」という表現からは、単純なテラフロップス競争ではなく、機械学習能力の向上に重点が置かれていることがうかがえる。 PCゲーマーへの影響 Xbox ModeとDirectX MLの組み合わせは、ミドルレンジのGPUユーザーにとって恩恵が大きい。RTX 3060やRX 6700 XTクラスのGPUでも、AI支援によって上位クラスに近い描画品質が期待できる。国内のPCゲーマーにとっても、Steamライブラリとの統合やコントローラー対応の強化は、Xbox GamePassへの移行ハードルを下げる可能性がある。 4月の提供開始は段階的なロールアウトとなる見込みで、まずWindows Insider向けから展開されると予想される。Project Helixの正式発表時期は不明だが、2027年以降のリリースが濃厚とみられる。 元記事: Xbox Mode Launches on Windows 11 in April 2026 with DirectX ML, Project Helix Teased for Next-Gen Xbox ...

Microsoft Agent 365とは何か Microsoftは2026年5月1日、AIエージェント管理の新サービスMicrosoft Agent 365を正式リリース（GA）する。エンタープライズ向けAI活用が加速するなか、IT部門・セキュリティチームにとって準備必須の新プラットフォームだ。 Agent 365は、組織内で稼働するすべてのAIエージェントを一元的に「観測・ガバナンス・セキュリティ管理」するためのコントロールプレーンである。エージェントを構築するツールではない点に注意が必要だ。エージェント構築はCopilot Studio、Microsoft Foundry、またはAgent Builderが担う。Agent 365の役割は、Microsoftプラットフォーム製・サードパーティ製を問わず、テナント上で動作するすべてのエージェントを管理下に置くことにある。 Microsoftはこれを「Microsoft PurviewやEntraがユーザーとデータに対して行ってきたことを、エージェントにも拡張したもの」と説明しており、AIガバナンスの中核インフラとして位置づけている。 2種類の認証フロー：OBOとエージェントIDの違い Agent 365はMicrosoft Entra Agent IDを基盤とした2種類の認証フローをサポートする。この違いを正しく理解することが、設計・ライセンスの両面で極めて重要だ。 On-Behalf-Of（OBO）フロー — 5月1日よりGA GAリリース時の標準モデルはOBO（代理実行）フローだ。エージェントはユーザーの委任トークンを受け取り、ユーザーの権限・コンテキストで処理を実行する。メールや予定表、ファイルなどユーザー固有のデータへのアクセス、明示的なユーザー同意が必要な操作、ユーザーコンテキストの保持が求められるシナリオに最適だ。監査ログも充実しており、コンプライアンス要件に応えやすい。 エージェントID認証 — プレビュー継続 もう一方は、エージェントが自身の認証情報で独立して動作するモデルだ。ユーザーとは切り離された独自のIDと権限を持ち、スケジュールタスク・監視ジョブ・バックグラウンド処理など完全自律型の操作に向いている。エージェント自身のメールボックスからメール送信や会議作成を行うことも可能だ。ただし、こちらは5月1日以降もプレビューのまま継続される。 ライセンス：従来の「エージェント単位」から「ユーザー単位」へ ライセンスモデルの変更も注目点だ。初期のFrontierプログラムではエージェント単位の課金が示唆されていたが、GAに際してユーザー単位のSKU、月額15ドル/ユーザーに刷新された。Microsoft 365 E7ライセンスに同梱されるほか、スタンドアロンでの購入も可能だ。 この変更理由について製品チームはAMA（Ask Me Anything）セッションで「予算の予測可能性」を挙げている。組織はユーザー数を把握しているが、将来的に何台のエージェントが稼働するかを事前に見積もることは困難だ。ユーザー単位に統一することで、IT部門が導入コストを計画しやすくなる。 日本のIT管理者へのポイント 国内企業でもMicrosoft 365の活用が進むなか、Copilot Studioで社内エージェントを構築・展開しているケースが増えている。Agent 365の登場により、これらエージェントの可視化・統制が一段と強化される。5月1日のGA前に、認証フローの設計方針とライセンス要件を社内で確認しておくことが推奨される。 元記事: Microsoft Agent 365 FAQ: What You Need to Know Before May 1st

OneDrive・SharePointでMarkdown編集がネイティブ対応——追加ツール不要に Microsoftは2026年4月中旬から5月下旬にかけて、OneDriveおよびSharePointにおいてMarkdown（.md）ファイルのブラウザ内直接表示・編集機能を順次展開する。これまで.mdファイルをSharePoint/OneDrive上で編集するには、Visual Studio CodeやObsidianなどの外部ツールを別途用意する必要があったが、今後はWebブラウザだけで完結できるようになる。 この機能は開発者やテクニカルライター、ドキュメント管理担当者にとって特に恩恵が大きい。GitHubのREADMEやWikiと同様に、Microsoft 365環境内でもMarkdownが「一級市民」として扱われる形だ。SharePointをナレッジベースやプロジェクトドキュメントの管理基盤として活用している企業では、運用フローの簡素化が期待できる。 同時期に展開される主な関連アップデート 今回の発表はMicrosoft 365全体の2026年3月分アップデートの一環として公開されたもので、他にも注目すべき変更点がいくつか含まれている。 Microsoft 365 Backup のターゲットリストア強化（4月下旬〜5月上旬）: SharePointとOneDriveの復元ポイントから、ファイルやフォルダ単位での個別リストアが可能になる。これまでのサイト全体リストアから細粒度化され、誤削除対応の運用が大幅に改善される。 SharePoint外部共有の認証方式変更（2026年5〜7月）: 現在利用されているSharePoint OTP（ワンタイムパスコード）による外部共有が廃止され、Microsoft Entra B2Bゲストフローへ移行する。5月以降の新規招待から順次切り替わり、7月中に完全移行が完了する予定。既存のOTPリンクは、ユーザーがB2Bゲストフローを完了するまで引き続き一部アクセス可能だが、管理者は早めに移行計画を立てておくことが推奨される。 Teamsにも複数の新機能 Teams関連では、録画ミーティングのハイライトクリップと要点まとめを自動生成する「ビデオ会議リキャップ」機能が4月下旬〜5月上旬に展開される。ただしこの機能はCopilotライセンスが必要なため、広範囲に展開する場合はライセンスコストと管理ポリシーの整備が必要になる。 また、外部の自動参加ボット（ミーティングアシスタントサービスなど）を検出してオーガナイザーや管理者が制御できる機能（6月上旬〜中旬）、1アカウントで最大10番号を扱えるTeams Phone マルチライン対応（4月下旬〜5月中旬）も予定されている。 管理者向けアクションチェックリスト Markdown編集機能を有効化・動作確認する SharePoint OTPからEntra B2Bへの移行計画を7月までに完了させる Copilotライセンスの割り当てと会議リキャップ機能の利用範囲を整理する Teams Phoneマルチライン割り当てを計画する ターゲットリストアのワークフローをバックアップ設定でテストする Markdownのネイティブサポートは一見地味に見えるが、エンジニアリングチームがSharePointをドキュメント基盤として活用する文脈では実用的な価値が高い。既存のMicrosoft 365環境をそのまま活用できる点は、ツール乱立を抑制したい企業にとって評価しやすいアップデートといえるだろう。 元記事: OneDrive and SharePoint Markdown File Editing Support (April 2026 Rollout)

Microsoft 365 Copilot、3月の大型アップデートで企業活用をさらに加速 Microsoftは2026年3月、Microsoft 365 Copilotに複数の新機能を追加した。今回のアップデートは「Copilotが正確な情報を返すか不安」「社内でどれだけ活用されているかわからない」といった、企業のIT管理者や現場が抱える課題に直接応えるものとなっている。 SharePoint管理センターに「権威あるソース」指定機能が登場（4月ロールアウト開始） 最大の目玉は、SharePointの管理センターからCopilot検索の優先情報源（権威あるソース）を指定できる新機能だ。4月より順次展開される。 Copilotは社内のさまざまなドキュメントやサイトを横断して回答を生成するが、情報源の信頼性にはばらつきがある。この機能を使うと、管理者が「このSharePointサイトの情報を優先して参照せよ」と明示的に設定できるため、公式ポリシー文書や最新の製品仕様書など、確度の高い情報をCopilotが優先的に参照するようになる。 日本企業においても、部門ごとにばらばらな情報が散在していることが多い。権威あるソースを明示できるこの機能は、Copilotの回答精度向上と情報ガバナンス強化を同時に実現するものとして注目される。 Teamsにコミュニティエージェントが追加 Microsoft Teamsでは、コミュニティ向けのCopilotエージェントが新たに利用可能になった。Teamsのコミュニティ機能（社外を含む大規模グループ向け）にもAIエージェントを配置できるようになり、Q&Aへの自動応答や情報共有の効率化が期待できる。 コミュニティ運営者がエージェントをカスタマイズし、よくある質問への自動回答や特定ドキュメントへの案内を設定するといった活用が見込まれる。 管理者向け「Readinessページ」で利活用状況を可視化 Copilotの導入後に「実際にどれだけ使われているのか」を把握できていない管理者は多い。今回展開されるReadinessページでは、組織内のCopilot利用状況をダッシュボード形式で確認できる。ライセンス割り当て状況、アクティブユーザー数、機能別の利用傾向などが一目でわかるようになり、ROI（投資対効果）の評価や追加トレーニング計画の立案に活用できる。 日本企業への影響 日本のMicrosoft 365ユーザー企業では、Copilotの段階的導入が進んでいる。特にSharePointの権威あるソース指定は、コンプライアンス要件の厳しい金融・製造・医療業界での活用促進につながる可能性が高い。また、Readinessページによる利活用の可視化は、DX推進担当者が経営層へ効果を報告する際の強力な根拠となるだろう。 各機能のロールアウトスケジュールはテナントによって異なるため、Microsoft 365管理センターのメッセージセンターで最新情報を確認することを推奨する。 元記事: What’s New in Microsoft 365 Copilot | March 2026

Microsoftは2026年3月16日、Copilot Chatの提供形態を変更すると発表した。変更は2026年4月15日から順次適用される。 何が変わるのか 最大の変更点は、Word・Excel・PowerPoint・OneNoteにおけるCopilot Chatの利用が、有料の「Microsoft 365 Copilot」ライセンス保有者に限定されることだ。 これまでライセンスなしでも一部利用できていたCopilot Chatは、4月15日以降はOfficeアプリ内から消える。ただし以下の機能は引き続き無償で利用可能だ。 Microsoft 365 Copilotアプリ上でのセキュアなAIチャットおよびチャット起点のコンテンツ作成 OutlookでのCopilot（受信トレイ・カレンダーとの連携を含む） ラベル表記も刷新 ユーザーやIT管理者が自分の利用状況を把握しやすいよう、製品内のラベルも変更される。 ユーザー種別 新ラベル M365 Copilotライセンスなし Copilot Chat (Basic) M365 Copilotライセンスあり M365 Copilot (Premium) すでにライセンスを持つユーザーへの影響はなし Microsoftは「有償ライセンスユーザーには変更はない」と明言しており、Premium利用者は引き続きWord・Excelなど主要Officeアプリでフルのコパイロット機能を使い続けられる。 企業IT担当者への影響 日本国内でもM365を広く導入している企業では、ライセンス体系の見直しが求められる場面が出てくる可能性がある。特に「ライセンスなしでもOffice内でCopilotが使えていた」という認識のまま運用していた組織は、4月15日以降に現場から問い合わせが増えることが予想される。 事前にIT部門から「4月15日以降はOfficeアプリ内のCopilotは有償プラン限定になる」と周知しておくことが望ましい。 今後もMicrosoftはCopilot系機能の提供範囲・ライセンス区分を継続的に見直す方針とみられ、動向を注視する必要がある。 元記事: Copilot Chat Changes - April 2026

1ファイル置くだけでClaudeが「無駄話」をやめる GitHubで公開された「claude-token-efficient」が、Hacker Newsで293ポイントを獲得し話題となっている。このプロジェクトが提供するのは、たった1つのCLAUDE.mdファイル。プロジェクトのルートディレクトリに置くだけで、Claudeが生成する出力の冗長さを平均63%削減できるという。 コードの変更は一切不要。Claude Codeは起動時にCLAUDE.mdを自動で読み込むため、ファイルを配置した瞬間から挙動が変わる。 Claudeのデフォルト出力はなぜ冗長なのか Claudeを使ったことがある開発者なら、こんな出力に心当たりがあるはずだ。 「Sure!」「Great question!」「Absolutely!」で始まるレスポンス 「I hope this helps! Let me know if you need anything!」で締めくくる定型句 質問を答える前に丁寧に言い換えて繰り返す 頼んでもいない追加提案や「改善案」を付け足す 指示していない抽象化レイヤーを盛り込んだコードを生成する 誤った前提に対して「You’re absolutely right!」と同調してしまう こうした振る舞いはすべてトークンを消費する。しかし、ほとんどの場面で実質的な情報価値はゼロだ。 ベンチマーク結果：同じ情報量、63%少ないトークン 5つのプロンプトを使って、CLAUDE.mdあり・なしの出力を比較した結果は以下の通り。 テスト内容 適用前 適用後 削減率 async/awaitの説明 180語 65語 64% コードレビュー 120語 30語 75% REST APIとは 110語 55語 50% 誤情報の訂正 55語 20語 64% 合計 465語 170語 63% 4プロンプトあたり約384出力トークンの節約。情報の欠落はなし、とプロジェクトは主張している。 コスト換算では、1日1,000プロンプトで月額約$8.64（Claude Sonnet基準）、複数プロジェクト合算では月$25超の節約になる計算だ。 正直なトレードオフ：すべての用途に向くわけではない プロジェクトはその効果を素直に認める一方で、適用すべきでないケースについても率直に説明している点が好感を呼んでいる。 効果が高いケース： 大量の出力を扱う自動化パイプライン（エージェントループ、コード生成） 数百回の繰り返し構造タスク チームで一貫したパース可能な出力が必要な場合 効果が薄いケース： 単発・短いクエリ（ファイル自体が入力トークンを消費するため、むしろマイナス） 設計議論やブレインストーミングなど、冗長な応答が価値を持つ用途 幻覚（ハルシネーション）や構造的な誤りの修正（それにはフックやゲートが必要） 確実なJSON出力が必要なケース（APIのJSON modeやツールスキーマのほうが堅牢） 重要な注意点として、CLAUDE.mdは毎メッセージごとに入力トークンとして読み込まれる。そのため、出力量が十分に多い場合にのみ節約効果がプラスになる。低頻度利用では逆にコストが増える可能性があることを、作者は明記している。 ...

ウィキペディア、AI生成コンテンツを正式禁止 インターネット最大の百科事典「ウィキペディア（Wikipedia）」が、ChatGPTなどの大規模言語モデル（LLM）を用いた記事執筆を公式に禁止した。Wikimedia財団のボランティア編集者たちによる投票で40対2という圧倒的多数で承認されたこの新ポリシーは、ウェブ上に「AIスロップ（粗悪なAI生成コンテンツ）」が氾濫する現状への明確な対抗措置だ。 なぜ禁止に至ったのか 新ポリシーが禁止の理由として挙げるのは、AIが生成するテキストが持つ構造的な問題だ。ウィキペディアが長年守り続けてきた検証可能性・中立性という核心的な基準を、AIは満たせないとしている。 具体的にはAIの「ハルシネーション（幻覚）」——存在しない事実の捏造、リンク切れ、実在しない文献の引用——が問題視されている。フランスのボランティア編集者で「WikiProject AI Cleanup」の創設メンバーであるIlyas Lebleuは、「ウィキペディア通常の文体と異なるスタイルで書かれた記事が増えていることに気づき始めた」とNPRのインタビューで述べている。 許可される限定的なAI利用 全面禁止というわけではない。以下の用途に限り、人間の編集者によるレビューを条件としてAIの使用が認められる。 他言語記事の翻訳補助 軽微な文章校正の提案 重要なのは「新しい情報の追加」を伴わないこと。あくまでも補助ツールとしての活用に留まる。 ウィキペディア共同創設者も警鐘 昨年10月、ウィキペディア共同創設者のジミー・ウェールズ（Jimmy Wales）もBBCの取材に対し、現在のAIモデルを「信頼できない」と一刀両断し、「人間編集者の代替としての利用準備はまだ整っていない」と警告していた。 皮肉な構図——育てた子に追い抜かれる この禁止措置には深い皮肉が込められている。ウィキペディアは創設から25年間、インターネット上で最も信頼されてきた情報源の一つだった。そして同時に、ChatGPTを支えるLLMを学習させるデータ源としても大きく貢献してきた。 しかし2025年後半のデータによると、ChatGPTの月間訪問数はウィキペディアをすでに上回り、ウィキペディアの人間によるページビューは2024年比で8%減少している。2023年末から2024年初頭にかけてChatGPTユーザーは36%増加しており、「歴史上ほぼあらゆるプラットフォームより速くインターネットに浸透している」（GWI上席データジャーナリスト Chris Beer氏）という状況だ。 ドミノ効果への期待と不安 Lebleuは「AIバブルへの不安が高まるにつれ、他のプラットフォームのコミュニティが自分たちの条件でAIを受け入れるかどうかを決定する、ドミノ効果を予見している」と述べ、今回の決定がウェブ全体の議論の起点になる可能性を示唆した。 日本のウィキペディアコミュニティも同様の課題に直面しており、今後の動向が注目される。AIと人間が情報の信頼性をめぐって綱引きを続ける中、25年の歴史を持つ百科事典の決断は、オープンな知識共有の未来を問い直す重要な一石となった。 元記事: Wikipedia officially bans AI-generated content

Claude Codeが10分ごとにgit reset –hardを実行？　調査の結果は「自作ツールの誤動作」 GitHubのClaude Code公式リポジトリに、衝撃的なバグレポートが投稿された。「Claude Codeが10分おきに git reset --hard origin/main を実行し、未コミットの変更をすべて消し去っている」というものだ。Hacker Newsでも250ポイント超・195コメントを集め、大きな注目を浴びた。 当初の「証拠」は非常に説得力があった 報告者のjohnmathews氏は、macOS上でClaude Code 2.1.87（--dangerously-skip-permissions モード）を使用中に異変に気づいた。Gitのreflogを確認すると、ちょうど600秒（10分）間隔で reset: moving to origin/main が95件以上記録されていた。 元記事: Claude Code runs Git reset –hard origin/main against project repo every 10 mins

AIはコードを書く。でも「学び」も奪っている AIツールがエンジニアリングの現場に急速に浸透するなか、見落とされがちな問題が静かに広がっている。AIが得意とするタスクの多くが、かつてジュニアエンジニアが「判断力」や「直感」を身につけるために経験してきた仕事そのものだという事実だ。 QCon London 2026でAlasdair Allanが行った講演の内容が、業界関係者の間で大きな反響を呼んでいる。 アモデイ予言の検証 Anthropicの共同創業者でRLHF（人間のフィードバックによる強化学習）の共同発明者でもあるDario Amodeiは、昨年「3〜6ヶ月以内にAIがすべてのコードの90%を書くようになる」と予言した。6ヶ月後、彼は「少なくともAnthropic社内では正しい」と主張した。 しかし実態はどうか。Redwood Researchの詳細な分析によれば、リポジトリにコミットされたコードだけでカウントすると、AI生成コードは約50%にとどまる。90%という数字は、一時的に使われただけの使い捨てスクリプトや探索的なコードを含めた場合にのみ成立する。 実際の企業データでも、Googleは内部コードの約25%、Microsoftは約30%、GitHub Copilotのエンタープライズ向け提案受け入れ率も約30%と報告している。「ほぼすべて」には程遠い数字だ。 生産性の「錯覚」 一方でAIの活用が現場に浸透していることは事実だ。Anthropic社内ではエンジニアの59%が日常業務でClaudeを使用し、50%の生産性向上を実感していると報告。GitHubのパブリックコミットの約4%はすでにClaude Codeが書いたものだという。 ところが昨年7月、業界に衝撃を与えた研究結果がある。METRが実施した無作為対照試験では、AIツールを使用した経験豊富な開発者はタスク完了に19%長い時間がかかったという結果が出た。開発者自身は「24%速くなる」と予測し、終了後も「20%速くなった」と感じていたにもかかわらずだ。知覚と実測値のギャップは43ポイントにもなる。 さらに今年2月、METRがフォローアップ研究を試みたところ、開発者がAIなしでの作業を拒否するケースが増加し、実験自体が困難になったという。 本当の問題：梯子に踏み台がない Allanが最も強調するのは、コードの生成量ではなく「構造的問題」だ。 Amodei自身も「プログラマーは全体的な設計、コードの協調関係、セキュリティの妥当性を判断する必要がある」と述べ、コードを「書くこと」と「エンジニアリング」を切り分けている。しかし問題は、つい最近までコードを書くことこそがエンジニアリングを学ぶ手段だったという点だ。 バグを自分で直し、地味な実装タスクをこなし、コードレビューで叩かれる——そうした経験の積み重ねが、上級エンジニアに必要な「判断力」を育ててきた。AIがその部分を引き受けると、次世代エンジニアはどこでその能力を身につけるのか。 「梯子の踏み台が消えている」というAllanのメタファーは示唆に富む。問題はAIがコードを書くかどうかではなく、梯子を作った人々を生み出したプロセスそのものが失われつつあることだ。日本のIT業界でも若手育成の在り方を根本から見直す議論が急務と言えるだろう。 元記事: The ladder is missing rungs – Engineering Progression When AI Ate the Middle

コーディングフォント選びに悩むエンジニア必見のWebツール プログラマーなら一度は悩む「どのコーディングフォントを使うべきか」問題。Fira Code、JetBrains Mono、Cascadia Code、Hack……選択肢は数十種類にのぼり、それぞれ微妙なデザインの違いがある。そんな悩みをゲーム感覚で解決してくれるWebツール「CodingFont」が、Hacker Newsで410ポイントを獲得し、200件以上のコメントが寄せられる大きな反響を呼んでいる。 トーナメント形式で「自分好み」を見つける CodingFontの仕組みはシンプルだ。画面に2つのコードサンプルが並んで表示され、ユーザーは「どちらが読みやすいか」をクリックで選ぶだけ。この選択をトーナメント形式で繰り返すことで、最終的に自分にとって最も見やすいフォントが絞り込まれる仕組みだ。 比較に使われるコードサンプルは実際のプログラミング場面を想定したもので、数字の「0」と文字の「O」の区別、「l」（小文字のL）と「1」（数字）の視認性、リガチャ（!= や => などの合字表現）の有無といった、コーディングフォント選びで重要なポイントが自然に確認できるよう設計されている。 なぜ今、コーディングフォントが注目されるのか 開発者がエディタの前で過ごす時間は膨大だ。1日8時間コードを書くエンジニアにとって、フォントの読みやすさは目の疲労や生産性に直結する。近年、JetBrains Monoのリリースやプログラミング向けフォントのオープンソース化が進んだことで選択肢が一気に増え、「どれが自分に合うのか分からない」という声も多い。 日本のエンジニアコミュニティでも、英数字の視認性だけでなく、コメントやドキュメント用途での日本語フォントとの組み合わせ（いわゆる「英語プログラミング用フォント＋日本語フォント」の合成）が話題になることが多く、まずベースとなる欧文フォントを選ぶ際にCodingFontは有効な出発点になり得る。 Hacker Newsコミュニティの反応 Hacker Newsのコメント欄では「こんなツールをずっと待っていた」「JetBrains Monoに落ち着くと思っていたら意外なフォントが勝った」といった声が相次いだ。一方で「同じコードサンプルが使われているため、フォントの特性よりも慣れ親しんだスタイルに引っ張られる可能性がある」という鋭い指摘も見られた。 またリガチャ（合字）の好みについて意見が割れており、「!= が ≠ のように表示されると直感的」という派と「実際の文字と異なって見えるのは混乱のもと」という派が活発に議論しており、フォント選びの奥深さが改めて浮き彫りになった。 使ってみよう CodingFontはブラウザから即座に利用でき、インストール不要。所要時間は5〜10分程度。エディタの設定を見直すきっかけとしても最適だ。普段使いのフォントに疑問を感じているエンジニアは、一度試してみる価値がある。 元記事: CodingFont: A game to help you pick a coding font

CISA、Citrix NetScaler脆弱性の緊急パッチを連邦機関に命令 米国のサイバーセキュリティ・インフラセキュリティ庁（CISA: Cybersecurity and Infrastructure Security Agency）は、積極的に悪用されているCitrix NetScalerアプライアンスの脆弱性（CVE-2026-3055）に対し、連邦政府機関に対して2026年4月2日（木）までにパッチを適用するよう命令した。 「CitrixBleed」に酷似した新たな脆弱性 Citrixは3月23日にセキュリティアップデートをリリースしたが、複数のサイバーセキュリティ企業がCVE-2026-3055について、過去に広く悪用された「CitrixBleed」および「CitrixBleed2」との技術的類似性を指摘しており、悪用リスクが高いと警告している。 この脆弱性の根本原因は不十分な入力検証にある。認証なしのリモート攻撃者が、SAML IDプロバイダー（IDP）として構成されたCitrix ADCまたはCitrix Gatewayアプライアンスから機密情報を窃取できる。 Citrixがパッチをリリースしてからわずか数日後、セキュリティ企業のWatchtowrはすでに野外での悪用を確認。攻撃者がこの脆弱性を利用して管理者の認証セッションIDを窃取し、未パッチのNetScalerアプライアンスを完全に乗っ取れる可能性があると警告した。 約3万台のNetScalerがインターネット上に露出 Shadowserverの調査によると、現在インターネット上に公開されているNetScaler ADCアプライアンスは約3万台、NetScaler Gatewayは2,300台以上に上る。ただし、脆弱な構成を持つものや未パッチのものがどれだけあるかは不明だ。 KEVカタログへの追加とBOD 22-01に基づく緊急命令 CISAは月曜日にCVE-2026-3055を既知悪用脆弱性（KEV: Known Exploited Vulnerabilities）カタログに追加し、拘束的運用指令（BOD: Binding Operational Directive）22-01に基づき、連邦文民行政府（FCEB）機関に対して4月2日までの対応を義務付けた。 CISAは「この種の脆弱性は悪意あるサイバー攻撃者にとって頻繁な攻撃ベクターであり、連邦政府全体に重大なリスクをもたらす」と警告し、ベンダーの指示に従ったパッチ適用、またはパッチが利用できない場合は製品の使用停止を勧告している。 BOD 22-01は米国連邦機関のみに適用されるが、CISAは民間企業を含むすべての組織に対しても、CVE-2026-3055のパッチ適用を優先するよう強く促している。 Citrix脆弱性の深刻な悪用履歴 Citrixに関連する脆弱性の悪用は今に始まったことではない。2023年10月にパッチが適用された「CitrixBleed」は、ゼロデイとして複数のハッキンググループに悪用され、Boeing（ボーイング）などの大手テック企業や政府機関への侵害につながった。2025年8月にはCitrixBleed2の悪用が確認され、連邦機関はわずか1日でシステムの保護を求められた。 これまでにCISAがCitrix製品の脆弱性を野外での悪用として認定したのは合計23件にのぼり、そのうち6件はランサムウェア攻撃に使用されている。 Citrix NetScalerを利用している日本企業・組織においても、早急なパッチ適用が推奨される。SAMLのIDP構成を持つアプライアンスは特に優先的に確認すべき対象となる。 元記事: CISA orders feds to patch actively exploited Citrix flaw by Thursday

Microsoft の Azure Developer CLI（azd）が2026年3月に7つのリリース（v1.23.7〜v1.23.13）を連続投入し、AIエージェント開発からインフラ管理まで幅広い強化が施された。 AIエージェントをターミナルからエンドツーエンドで操作 最大の目玉は azure.ai.agents 拡張によるAIエージェント対応コマンド群だ。 azd ai agent run — エージェントをローカルで起動 azd ai agent invoke — ローカルまたは Microsoft Foundry にデプロイ済みのエージェントにメッセージを送信 azd ai agent show — コンテナのステータスと健全性を表示 azd ai agent monitor — コンテナログをリアルタイムストリーミング これにより、AIエージェントの開発・テスト・本番デプロイまでの全工程をターミナル一つで完結できる。Microsoft Foundry との統合が前提となっており、Azure AI 基盤に乗る開発者には特に恩恵が大きい。 GitHub Copilot が azd init に統合（プレビュー） azd init 実行時に「GitHub Copilot でセットアップ（プレビュー）」オプションが追加された。Copilot エージェントがプロジェクトのスキャフォールディングを担い、Model Context Protocol（MCP）サーバーへの同意確認も事前に行う設計となっている。 さらに、コマンド失敗時にはAIによる多段階トラブルシューティングフローが起動。「説明」「ガイダンス」「自動修正」「スキップ」の4段階から選択でき、修正適用後にそのまま失敗コマンドを再実行できる。ターミナルを離れずに問題解決できる点は実務での生産性向上に直結する。 Container App Jobs の直接デプロイ対応 これまで Container Apps のみだったデプロイ対象に、Azure Container App Jobs（Microsoft.App/jobs）が加わった。azure.yaml の host: containerapp 設定はそのままで、Bicep テンプレートの内容に応じて自動判別される。追加設定不要で既存ワークフローへの組み込みが容易だ。 ...

最新AIモデルがサイバー攻撃に悪用される懸念が急浮上 Anthropicが開発する次世代AIモデル「Claude Mythos」やOpenAIの最新モデルが、高度なサイバー攻撃の自動化・拡張に悪用できるとして、セキュリティ業界やAI安全性コミュニティで警戒感が高まっている。 AIが攻撃者に「非対称な優位性」をもたらす これまでのサイバーセキュリティの世界では、攻撃側と防御側がほぼ対等な技術競争を繰り広げてきた。しかし最新世代のAIモデルは、その均衡を崩す可能性があると専門家たちは指摘する。 懸念されているのは、高度な推論能力と自律的なタスク実行力を持つ「AIエージェント」の登場だ。従来の攻撃ツールは人間のハッカーが細かく操作する必要があったが、最新のAIモデルはターゲットの脆弱性調査からエクスプロイト（脆弱性を突くコード）の生成、実行計画の立案までを自律的にこなせる段階に近づいている。 こうした能力は、これまで高度な技術スキルを持つ攻撃者にしか不可能だった攻撃を、スキルの低い「スクリプトキディ」レベルの攻撃者でも実行可能にしてしまうリスクをはらんでいる。 防御側が追いつけない構造的問題 セキュリティ研究者たちが特に危惧するのは、攻撃者と防御者の間に存在する「非対称性」だ。攻撃者は一度の攻撃が成功すれば目的を達成できるが、防御側はすべての攻撃を防ぎ続けなければならない。AIがこの非対称性をさらに拡大するという構図だ。 AIを使えば攻撃者は24時間365日、大量のターゲットに対して自動的にスキャンや侵入試行を繰り返せる。一方、防御側も同様にAIを活用した検知・対応システムを整備しつつあるが、攻撃側の進化スピードに追いつくのは容易ではない。 AI安全性コミュニティで新たな論争 AnthropicやOpenAIといったAI企業は、モデルに対してサイバー攻撃への直接的な協力を拒否するよう「ガードレール」を設けている。しかし研究者たちは、こうした安全策が巧妙なプロンプトエンジニアリングや多段階の迂回手法によって回避される可能性を繰り返し示してきた。 今回の懸念はAI安全性コミュニティ内でも新たな議論を呼んでいる。「能力の公開」と「悪用リスクの抑制」のバランスをどう取るかという問いは、モデルの強化とともにより切実さを増している。 日本への影響 日本でもサイバー攻撃の件数は年々増加しており、特に重要インフラや製造業を狙ったランサムウェア攻撃が深刻化している。AIを活用した攻撃の高度化・低コスト化は、国内企業にとっても対岸の火事ではない。経済産業省やIPAが推進するサイバーセキュリティ対策の強化と並行して、AIを活用した防御側の能力向上も急務となっている。 最新AIモデルの能力向上は技術の進歩を象徴する一方で、その「両刃の剣」としての側面に、業界全体が真剣に向き合う時期に来ている。 元記事: Everyone’s worried that AI’s newest models are a hacker’s dream weapon

中国製AIがオープンソース市場を席巻——Qwen 3.5の全貌 半年前、開発者にオープンソースLLMを尋ねれば「Llama一択、軽量ならMistral」という答えが返ってきた。中国製モデルは欧米の開発者コミュニティにほとんど存在感がなかった。その常識が2026年に入って大きく変わった。 AlibabaのQwen（通義千問）チームが2026年3月初旬までに全パラメータサイズのリリースを完了した「Qwen 3.5」ファミリーは、コーディング・数学・指示追従・長文推論といった実務直結のベンチマークで欧米のオープンソースモデルを上回る結果を出している。 3段階でリリースされた全ラインナップ Qwen 3.5は2月〜3月にかけて3波に分けてリリースされた。 第1波（2月16日）——フラッグシップ Qwen3.5-397B-A17B：総パラメータ数397B、推論時に実際に活性化するのは17BのみというハイブリッドなMoE（Mixture-of-Experts）アーキテクチャを採用。Llama 4 MaverickやGPT-4oと正面から競合するモデル。 第2波（2月24日）——ミドルレンジ Qwen3.5-122B-A10B（MoE） Qwen3.5-35B-A3B（MoE） Qwen3.5-27B（Dense） 第3波（3月2日）——エッジ向け小型モデル Qwen3.5-9B / 4B / 2B / 0.8B：モバイルや組み込み環境向けに設計されており、MacBook上で5.5トークン/秒以上の速度で動作することが確認されている。 すべてのモデルがApache 2.0ライセンスで公開されており、商用利用も制限なく可能。 Qwen 3からの主な進化点 Qwen 3.5は単なるマイナーアップデートではない。注目すべき改善点は以下の通りだ。 MoEアーキテクチャの拡大：35Bと122Bモデルもシリーズ化し、推論コストを大幅削減しながら品質を維持 思考モードの切り替え：すべてのモデルで「thinking（拡張推論あり）」と「non-thinking（高速応答）」をタスクに応じて切り替え可能 エージェント機能の強化：関数呼び出し（Function Calling）、ツール利用、マルチステップ処理が大幅に改善 多言語対応：100以上の言語をサポートし、日本語を含むCJK（中国語・日本語・韓国語）での精度が特に高い。日本語ユーザーにとっては欧米モデルより実用的な場面も多いだろう 長文コンテキスト対応：大規模リポジトリ全体を横断したコード推論や文書解析に対応 中国製オープンソースAIが急加速している背景 Qwen 3.5は単独の出来事ではない。2025年後半から中国のAI開発は急加速しており、DeepSeek V3.2は推論タスクでGPT-5に匹敵するという評価も出ている。さらにHuaweiは米国製半導体に依存しない独自シリコンの開発を進めており、米国の輸出規制が想定ほどの足かせになっていないことが示されつつある。 Hugging Faceのダウンロードランキングでも、Qwenシリーズは2025年中頃から継続的に上位に入っており、開発者コミュニティへの浸透は着実に進んでいる。 オープンソースAIの競争は、MetaとMistralの2強から、QwenとDeepSeekを加えた4強へと移行した。日本の開発者にとっても、選択肢として中国製モデルを無視できない時代が到来している。 元記事: Qwen 3.5 vs Llama vs Mistral: China’s Open-Source AI Is Catching Up Faster Than You Think