Tech News JP

ボタンをクリックしなくていい世界へ Salesforceの共同CEOを務めたBret Taylorが創業したAIスタートアップ・Sierra（シエラ）が、企業向けソフトウェアの使い方を根本から変えようとしている。先月発表された「Ghostwriter」は、ユーザーが自然言語で要件を伝えると、それを実行するための専用エージェントを自動で生成・デプロイするツールだ。「エージェントを作るエージェント」という構造は、従来の「AIがUIを支援する」発想とは一線を画す。 Taylorはサンフランシスコで開催されたHumanXカンファレンスで「ボタンをクリックする時代は終わる」と断言した。その根拠として挙げたのが、企業内ソフトウェアの「使われなさ」問題だ。 「Workdayは入社時と年末調整の時しか開かない」 Taylorの指摘は鋭い。Workday、Salesforce、SAP——これらのエンタープライズSaaSは、導入コストは高くても実際に使いこなしている従業員は一握りだ。複雑なナビゲーション、膨大なオプション、急な仕様変更に誰もついていけない。 Ghostwriterが目指すのはこの構造的問題への解答だ。「使い方を覚えなくていい」「マニュアルを読まなくていい」——ユーザーは目的を自然言語で伝えるだけ。システムがその場で専用エージェントを組み立て、タスクを完遂する。Sierraはすでにこの仕組みを使って、Nordstromのエージェントを4週間で本番導入したと発表している。 「ほとんどの企業はソフトウェアを作りたいわけじゃない。問題を解決したいんだ」——Taylorのこの言葉は、SaaS産業全体への根本的な問いかけでもある。 ただし「完全自律」はまだ先の話 一方で、現実は理想論とのギャップを正直に示している。TechCrunchが複数の投資家・技術者に取材した結果、AIエージェントの実装はまだ完全自律からは程遠いという声が多数挙がった。 Sierra自身も含め、エンタープライズAIエージェントを提供する多くのスタートアップは「フォワードデプロイドエンジニア」と呼ばれる担当者を顧客先に常駐させ、エージェントを継続的にチューニングし続けている。法律AIのHarveyも同様だ。「自律的に動く」と謳いながら、裏側では人間が支えているというのが現状だ。 Sierraは2024年秋に設立から21ヶ月未満でARR（年間経常収益）1億ドルを達成、同年9月には評価額100億ドルで3億5000万ドルを調達している。マーケットの期待値は極めて高いが、「言ったとおりに動く」と「本当に自律している」の間にはまだ大きな溝がある。 実務への影響——日本のエンジニア・IT管理者へ このトレンドが日本の現場に与える示唆は大きい。 1. 「使われないシステム」問題の解決策として評価すべき 日本企業の多くが同じ課題を抱えている。高額のERPやCRMを導入しても、現場への浸透率が低く費用対効果が出ない。自然言語インターフェースがこの問題のバイパスになる可能性は十分にある。 2. エージェントを「設計する人」の価値が爆上がりする Ghostwriterが示す「エージェントを生成するエージェント」の構造は、今後のアーキテクチャ設計の主戦場になる。「どんなエージェントを作らせるか」を設計できる人材の価値は急上昇する。今から意識的にこのスキルを育てておくべきだ。 3. 現状のAIエージェント製品を評価するときは「裏側の人手」を確認する デモが素晴らしいからといって鵜呑みにしない。「フォワードデプロイドエンジニアが何人いるか」「チューニングなしで動くのか」を必ず確認しよう。PoC（概念実証）と本番運用の間には深い溝がある。 4. 自然言語UIへの移行準備として、プロンプト設計スキルを身につける UIの操作手順を覚えることよりも、「何を達成したいか」を正確に言語化する能力が今後の業務スキルの核になる。 筆者の見解 Taylorの主張は正しい方向を向いている。「ソフトウェアのUIを学ぶことへのコストを人間に負わせ続ける」設計は、本質的に無駄だ。企業が求めているのは機能の羅列ではなく、成果への最短経路だ。 ただし、今議論すべき本質はGhostwriterの優劣ではなく、「エージェントが自律的にループで動き続ける」アーキテクチャが本当に実現しているかどうかだと思う。エージェントが人間に都度確認を求め、承認を待ち続ける設計では、認知負荷の削減という本来の目的を達成できない。 「指示→応答→終了」という単発モデルと、「目的を受け取り→計画→実行→検証→再実行」という自律ループモデルの間には、アーキテクチャとして根本的な違いがある。後者が本物のエージェントだ。 Ghostwriterがどちらに近いかは現時点では見極めきれないが、「エージェントがエージェントを作る」という構造は、自律ループ設計に向けた正しい一歩に見える。Nordstromへの4週間導入が本当に「人手なしで動いている」ならば、それは業界全体が注目すべき事例だ。 日本のIT現場では、まだ「AIはサポートツール」という認識が主流だ。しかし、ツールを補助として使うフェーズはもう終わりかけている。自律的に動くエージェントの設計を誰が担えるか——この問いに答えられる組織と人材が、次の競争優位を握る。 出典: この記事は Sierra’s Bret Taylor says the era of clicking buttons is over の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleとIntelが、複数年にわたるパートナーシップの大幅な拡大を発表した。AI時代に「GPUがすべて」という認識が広まる一方で、この提携はCPUとカスタムチップがいかに重要かを改めて突きつけている。AI推論需要の急拡大が生む「見えにくいボトルネック」の実態を解説する。 GPUは「訓練」、CPUは「推論」——役割の違いを整理する AIモデルの開発・学習（トレーニング）にはGPUが不可欠だ。だが、実際にモデルを動かす「推論（インファレンス）」フェーズでは状況が異なる。Webサービスやクラウドアプリケーションでユーザーのリクエストをさばく実務環境では、CPU性能とスループットが直接サービス品質に影響する。 Googleは数十年にわたりIntelのXeonプロセッサをデータセンターで使い続けており、今回の発表では最新のXeon 6チップをAI・クラウド・推論タスクに活用することが明記された。長年の実績をベースにした、着実な深化だ。 IPU（インフラストラクチャ処理ユニット）とは何か 今回の提携でもう一つ注目すべきは、IPU（Infrastructure Processing Unit）のカスタム共同開発の拡大だ。2021年から続くこのプログラムは、ASIC（特定用途向け集積回路）ベースのIPU開発に焦点を当てている。 IPUは、CPUから「ネットワーク処理・ストレージ管理・仮想化処理」などを肩代わりする専用チップだ。これによりCPUはAI推論などの本来の計算処理に集中できる。クラウド規模のAIワークロードを効率よく処理するには、こうした「オフロード」の仕組みが欠かせない。 Intel CEOのリップ＝ブー・タン氏は「AIのスケーリングにはアクセラレーターだけでなく、バランスの取れたシステムが必要だ。CPUとIPUは現代のAIワークロードに必要なパフォーマンス・効率性・柔軟性を実現する中核だ」と述べており、GPU一辺倒のナラティブに対するカウンターメッセージとも読める。 CPU不足という見えにくい現実 業界全体が直面するGPU不足は広く報道されているが、実はCPU不足も深刻化している。SoftBank傘下のArmが自社初となる「Arm AGI CPU」を発表したのも、この文脈からだ。AI推論需要の爆発的な増加が、CPU市場にも強い圧力をかけている。 実務への影響——日本のエンジニア・IT管理者に届けたいポイント Google Cloudを使っている場合 今回の発表は直接的なサービス変更を意味するものではないが、中長期的にXeon 6ベースのインスタンスが推論ワークロードに最適化されていく可能性がある。AIを使ったAPIサービスや推論エンドポイントを運用・計画している担当者は、インスタンスタイプ選定でCPUスペックをより意識する価値がある。 オンプレ・ハイブリッド環境の場合 AI推論をオンプレミスで実施している、または検討している企業にとって、Xeon 6の登場は新たな選択肢になる。GPUなしでも一定の推論処理をCPUとIPUの組み合わせで賄える可能性があり、コスト削減と電力効率の観点から検討の余地がある。 ベンダー多様化リスクの観点から NVIDIA一社への依存度が高い現在のAI市場において、IntelとGoogleによるCPU/IPU路線の強化は、インフラ選択肢の多様化につながる。「NVIDIA GPUが確保できなければAIは始められない」という状況が、徐々に緩和されていく可能性がある。 筆者の見解 Intel CEOが述べた「バランスの取れたシステム」という言葉に、私は深く同意する。 AI熱が高まるにつれ、「GPU = AI」という単純な図式が一人歩きしている。だが実際の企業システムでは、AIはあくまでシステム全体の一部だ。推論・データ転送・ストレージ管理・ネットワーク処理——これらすべてが組み合わさって初めてAIワークロードが動く。特定のチップや特定のベンダーに極端に依存した設計は、どこかで必ず詰まる。 統合プラットフォームとして全体を最適化する視点が、AI時代のインフラ設計では一層重要になる。クラウドプロバイダーを選ぶ際も、GPU性能だけでなくCPU・ネットワーク・ストレージのトータルバランスで評価することを強く勧めたい。 今回のGoogle×Intel提携は、業界にそのことを改めて思い起こさせてくれる、タイムリーな一手だったと思う。 出典: この記事は Google and Intel deepen AI infrastructure partnership の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが新モデル「Mythos」の一般公開を見送り、Amazon Web ServicesやJPモルガン・チェースといった大手企業・機関のみに限定提供すると発表した。公式な理由は「既存ソフトウェアの脆弱性を前モデルより格段に高い精度で発見・悪用できるため、悪意ある行為者に渡れば世界規模のサイバーリスクになる」というものだ。OpenAIも同様のアプローチを検討していると報じられており、フロンティアラボ（先端AI研究機関）全体のトレンドとして注目される。 Mythosとは何か——脆弱性発見AIの新たな次元 Mythosは、セキュリティ上の欠陥を自動的に探索・悪用するタスクにおいて、前世代モデルのOpusを大幅に上回るとされる。AnthropicはMythosを「責任ある大組織」に限定して提供し、インフラを守る側が先に対策を打てる状況を作ることで、リスクを抑えながら活用を進める方針を取っている。 ただし、この能力評価には異論もある。AIサイバーセキュリティスタートアップのAisleは「Mythosが達成したとされる成果の多くは、より小さなオープンウェイトモデルの組み合わせで再現できた」と報告している。つまり、1つの巨大モデルが突出しているというよりも、タスクに応じたモデルの使い分けが重要だという見方だ。 「安全配慮」の裏に潜む経済的動機 ここで疑問が浮かぶ。本当に純粋なセキュリティ上の判断なのか、それとも別の動機があるのか。 ソフトウェアエンジニアでexe.devのCEOであるDavid Crawshaw氏はSNSでこう指摘した。「これはトップエンドモデルが企業契約でゲート化されていることへのマーケティング的な目くらましだ。あなたと私がMythosを使えるころには、また新しいエンタープライズ専用のモデルが出ている。そのトレッドミルが企業収益を維持し、蒸留（ディスティレーション）企業を常に二番手に押しとどめる」。 蒸留（Distillation）とは、大規模モデルの出力を使って、より小さく安価なモデルを訓練する技術だ。これにより、莫大な計算コストをかけずにフロンティアモデルに迫る性能を得ることが可能になる。中国のAI企業もこの手法で追い上げを図っていると見られており、Anthropic・Google・OpenAIの3社が協力して蒸留業者を特定・ブロックする取り組みを進めていると報じられている。 限定公開によって、フロンティアラボは「企業だけが使える最強ツール」というポジションを維持しながら、蒸留の原材料となるモデルアクセスも絞れるという一石二鳥の効果がある。 日本のIT現場への影響 日本のエンジニアやIT管理者にとって、この動向は複数の側面から影響する。 セキュリティ面: Mythosのような高度な脆弱性発見AIが悪用された場合、攻撃の高度化・自動化が加速する。国内のOSSやクラウドサービスも影響を受ける。SIerやセキュリティベンダーは、AI支援の攻撃手法を前提とした脅威モデルの見直しを迫られるだろう。 調達・採用面: フロンティアモデルが「企業契約でゲート化」される流れが続くと、最先端AIへのアクセスは大手企業や研究機関に集中し、中小企業や個人開発者は常に「一世代前」のモデルを使い続けることになる。AI活用の格差が構造的に広がる可能性がある。 実務的なヒント: 限定公開モデルへの依存は避け、オープンな代替手段も常に確認しておく 自社のインフラがAWSやAzureなどの大手クラウド上にある場合、これらのプロバイダーがMythosへのアクセスを得ることで、プラットフォーム側のセキュリティが強化される可能性は高い——これはポジティブな側面として捉えていい AI支援の脆弱性スキャンが高度化するということは、防御側にとっても新たなツールが登場するということ。ペネトレーションテストやバグバウンティの文脈でも注目しておく価値がある 筆者の見解 今回の件で気になるのは、「安全」と「ビジネス」の言葉が混在している点だ。どちらの動機が主かを外から断定することはできないが、「限定公開によって守れるもの」を整理すると、インターネットの安全だけでなくフロンティアラボのビジネスモデルも含まれることは明らかだ。 そのこと自体を責める気にはなれない。莫大な研究開発コストを回収し、次世代モデルに再投資するためには収益が必要であり、それは健全な産業サイクルの一部だ。問題は、「安全配慮」の名の下に最先端技術へのアクセスが構造的に制限されるとき、AIの民主化という大きな流れと逆行しないか、という点だ。 Aisleの検証が示すように、1つの巨大モデルがすべてを決するわけではなく、適切なモデルを組み合わせることで十分な成果が得られる場面も多い。つまり、フロンティアモデルへのアクセスがなければAI活用ができないという前提自体が崩れつつある。 日本のIT現場においては、「どのモデルを使っているか」ではなく「どう使いこなしているか」に注力することが、長期的に競争力を保つ正しいアプローチだと思う。最強モデルを追い続けるより、今手元にあるツールで着実に成果を出す実践の積み重ねこそが、変化の速いこの時代における本質的な強さになる。 出典: この記事は Is Anthropic limiting the release of Mythos to protect the internet — or Anthropic? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

わずか半年前、3億5,000万ドルのシリーズCラウンドを完了し時価総額100億ドル（約1兆5,000億円）を突破したAIデータ訓練スタートアップMercor。しかし2026年3月31日のデータ侵害公表以降、そのブランドは急速に傷つきつつある。判明した被害規模は4TBという膨大なものであり、AIモデル開発の裏側を担うサードパーティ企業のセキュリティリスクを改めて業界全体に突きつけた事件となった。 何が起きたのか——オープンソースツールを起点にした連鎖侵害 侵害の入口となったのは、1日に数百万回ダウンロードされる人気オープンソースライブラリ「LiteLLM」だ。このツールに40分間だけクレデンシャル収集マルウェアが混入し、Mercorの認証情報が盗み出された。攻撃者はそこで得た認証情報を使ってさらに別のシステムやアカウントへアクセスし、次の認証情報を入手するという連鎖的な侵害を繰り返した。 40分間という短さに驚く読者も多いだろうが、サプライチェーン攻撃の恐ろしさはここにある。入口となるツールが広く使われているほど、攻撃者は一度の侵害で複数ターゲットを同時に狙える。LiteLLMのように大規模なエコシステムを持つツールであれば、40分あれば十分に致命的なアクセスを確立できてしまう。 流出したとされるデータには候補者プロフィール、個人識別情報（PII）、クライアント企業データ、ソースコード、APIキーが含まれる。Mercorは現時点でデータの真正性についてはコメントせず、調査継続中の立場を維持している。 MetaやOpenAIへの波及——AI訓練データの機密性リスクが顕在化 Mercorが担う事業の本質は「AIモデルを賢くするためのカスタムデータセットと訓練プロセスの管理」だ。これはモデルメーカーにとって最大の企業秘密とも言える領域である。 MetaはMercorとの契約を無期限停止したと複数のメディアが報じている。MetaがMercorの競合であるScale AIに約2兆円を投じた後も、Mercorとの取引を継続していたという事実が、その信頼の深さを物語っている。その関係が今回の侵害で揺らいだ意味は小さくない。 OpenAIも自社の露出状況を調査中と認めたが、現時点では契約の停止・終了はないとしている。ただし業界内では、他の大手モデルメーカーも関係見直しを検討しているとの情報がある。 「認定証」への過信という落とし穴——DelveとLiteLLMの責任論 今回の訴訟で興味深いのは、LiteLLMそのものとAIコンプライアンス企業「Delve」が被告に名を連ねた点だ。LiteLLMはセキュリティ認定取得にDelveを利用していたが、DelveはAIコンプライアンス認定の水増しや形式的な審査を行ったとして内部告発を受けている。Delveはこれを否定しつつも、運営上の変更を実施中だという。 セキュリティ認定証は「ハッカーを撃退する盾」ではなく、「リスク管理プロセスが機能しているかの確認」に過ぎない。認定取得プロセス自体が形骸化していたとすれば、その土台に立つ企業のリスクは認定証の有無と無関係に存在し続ける。 実務への影響——日本のエンジニア・IT管理者が明日から取るべき行動 この事件は決して「海外のスタートアップの話」で終わらない。日本のIT現場でも以下のリスクが直接関係する。 1. オープンソースのサプライチェーン監視を強化する LiteLLMのように広く使われるライブラリほど攻撃対象になりやすい。依存ライブラリの更新履歴や異常なコミットを監視する仕組み（例：Dependabot、Socket.dev、Sigstore等）を導入済みか見直す機会だ。 2. AIサービスの委託先評価にセキュリティ審査を組み込む AIデータ訓練や推論処理をSaaS・スタートアップに委託する場合、そのベンダーが何を保持しているかを把握せずに契約するのはリスクだ。「SOC 2認定あり」の一点だけを信頼するのではなく、認定取得プロセスの実態やインシデント対応の実績も評価項目に加えるべきだ。 3. APIキーの最小権限・ローテーション運用を徹底する 今回の流出物にAPIキーが含まれる点は見逃せない。複数サービス共通のキーを使いまわしていると、1か所の侵害が連鎖する。最小権限の原則と定期ローテーションを改めて徹底したい。 4. 個人情報取り扱い業者の委託先管理を点検する 個人情報保護法の観点から、委託先が実際にどのようなセキュリティ管理をしているかの確認義務が委託元にも生じる。AI活用を進める過程でこの視点が抜け落ちていないか確認を。 筆者の見解 AIモデルを訓練するためのデータを扱う企業は、ある意味でモデルメーカー以上に「高価値なターゲット」だ。完成品よりも「完成品を作るための型と材料」の方が狙われやすいのは製造業の世界でも同じ原理だろう。Mercorがその典型となってしまった。 気になるのは、根本原因がオープンソースツールの40分間の汚染だったという点だ。開発の生産性を高めるためにオープンソースエコシステムを活用するのは正しい選択だが、そのエコシステム自体のセキュリティを誰が担保するかという問いは、今なお業界全体への宿題として残っている。 今回の件は、単なる一企業のセキュリティ事故ではなく、AI時代のソフトウェアサプライチェーン全体が抱える構造的な脆弱性の問題だ。「AIを使えば生産性が上がる」という議論と同じ重みで、「AIサービスのサプライチェーンをどう信頼するか」を議論すべき時期に来ている。認定証や資金調達額は安全の証明にはならない——この教訓を、日本のIT業界が自分事として受け取ってほしい。 出典: この記事は After data breach, $10B-valued startup Mercor is having a month の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがYouTube Shortsに「AIアバター」機能の展開を開始した。自分の顔と声をAIに学習させ、プロンプトを入力するだけで最大8秒の動画クリップを生成できる——いわば「自分のデジタルクローン」を手軽に作れる時代が、プラットフォームの公式機能として幕を開けた。 クリエイターとしての可能性を広げる技術であることは間違いないが、この機能の登場は単純に喜ばしい話だけではない。生成AIコンテンツの氾濫、ディープフェイク詐欺、なりすまし問題と格闘し続けているYouTubeが、あえて「誰でも使えるディープフェイクツール」を自ら提供するという構図には、プラットフォームとしての姿勢が問われる重さがある。 AIアバターの仕組み 作成プロセスは比較的シンプルだ。ユーザーはまず「ライブセルフィー」と呼ばれる撮影を行い、顔と声をAIが学習できる形式で記録する。YouTubeは良い結果を得るために、明るい照明・静かな環境・背景に他の人物が映り込まないこと・カメラをアイレベルで保持することを推奨している。 一度アバターが作成されると、動画制作時に「アバターで動画を作成」を選択し、テキストプロンプトからクリップを生成できる。また、自分の既存のShortsにアバターを挿入する機能も用意される。 ガバナンスの設計 YouTubeは悪用を防ぐためのいくつかの制限を設けている。 自分のオリジナル動画にのみ使用可能（他者の動画への無断挿入は不可） AI生成コンテンツの明示：SynthIDデジタル透かしとC2PAメタデータによる識別情報が付与される 年齢制限：18歳以上、かつ既存のYouTubeチャンネル保有者のみ 自動削除：3年間未使用のアバターは自動的に削除される 利用者の管理権限：クリエイターはいつでもアバターや関連動画を削除できる C2PAは現在多くのプラットフォームが採用する認証マーカーだが、「広く採用されてはいるが実効性には疑問符がつく」とVergeも指摘する通り、万能ではない。悪意のある利用者がメタデータを除去したり、スクリーンキャプチャで回避したりすることは技術的に難しくない。 競合の動向：SoraのサンセットとYouTubeの判断 今回の機能展開のタイミングとして無視できないのが、OpenAIが先月Soraの提供を終了したことだ。著作権問題、ディープフェイク論争、コンテンツの質の低下、そして投資家向けのIPO準備を前にしたリスク回避——複合的な要因でSoraは撤退した。 そのタイミングでGoogleがAIアバター機能を拡充するのは、YouTube Shortsがクリエイター向けAIツールのハブとして主導権を握ろうとする意図が見える。 日本のクリエイター・IT担当者への実務インパクト クリエイターへの示唆: 顔出しに抵抗があるクリエイターにとって、アバターを使った動画制作は新しい選択肢になりうる。ただし「見た目だけのクローン」ではなく、視聴者との信頼関係という問題は別途考える必要がある 多言語展開の文脈では、自動吹き替え機能と組み合わせることで、日本語コンテンツを英語圏向けに効率的に展開する可能性もある 現時点では8秒という制限があり、本格的なロングフォームコンテンツには使えない。ショート動画の補完ツールとして位置づけるのが現実的 企業・ブランド担当者への示唆: 社内の公式情報発信に自社社員のアバターが使われた場合の対応ポリシーを、今のうちに整備しておく必要がある YouTube上でのなりすましリスクが高まる可能性があり、ブランド監視の強化が求められる IT管理者・セキュリティ担当者への示唆: SynthIDやC2PAによる識別情報は参考にはなるが、完全な検知手段ではない。組織内でのメディアリテラシー教育の重要性が増している フィッシング攻撃にAIアバターが使われるシナリオ（「経営者になりすました動画メッセージ」など）のリスクが現実味を帯びてきた。ゼロトラスト的な視点で、動画コンテンツの真正性確認プロセスを見直す時期かもしれない 筆者の見解 この機能を見て感じるのは、技術的な面白さと、プラットフォームとしての責任の重さが同時に存在するという複雑さだ。 「禁止ではなく、安全に使える仕組みを」という考え方は正しいと思っている。ディープフェイク技術そのものを禁じることは現実的ではないし、プラットフォームが管理された形で提供することで、むしろ悪用のリスクを下げられる面はある。その意味でYouTubeのアプローチには一定の合理性がある。 ただ、気になるのはAIアバターという技術の「方向性」だ。今回の機能はあくまで「クリエイターが自分の動画をより効率よく作る」ためのツールとして設計されており、それ自体は筋が通っている。問題は、この技術が普及するにつれて「本物の顔出し動画」と「AIアバター動画」の境界が視聴者にとってますます曖昧になることだ。SynthIDのような技術的なラベリングが機能するのは、ツールを使う側に善意がある場合に限られる。 AIエージェントの文脈でこの機能を見ると、「表現の自動化」という点では興味深い進化だが、まだ「人間の意図をAIが表現する」段階に留まっている。次のフロンティアはエージェントが自律的にループで動き続ける設計——単発の指示と応答ではなく、判断・実行・検証を繰り返すアーキテクチャだ。AIアバターはその一部ではあるが、本質的な変革はその先にある。 今後数年で「動画コンテンツの真正性」はIT業界における重要なテーマになっていくだろう。日本企業もこの流れを「海外のトレンド」として傍観している余裕はない。 出典: この記事は Google makes it easy to deepfake yourself の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIブームの熱狂が続く一方で、その裏側では静かに、しかし確実に「マネタイズの崖」が近づいている。AnthropicとOpenAIという生成AI界の二大巨頭が、数百億ドル規模の資本投資と目も眩むような計算コストの狭間で、「本物のビジネスになれるか否か」という生存を賭けた局面を迎えた。 なぜ今「収益化の崖」なのか 両社の最大の課題は、収入より速い速度で資金が溶けていく構造にある。データセンター、GPU、電力——生成AIインフラの維持費は桁外れだ。そこにAIエージェントの普及という新たな変数が加わった。 エージェントは単純な質問応答と根本的に異なる。タスクを自律的に分解し、検索・コード実行・ファイル操作を何十ステップも繰り返す。当然、消費トークン数は従来のチャット利用の数十倍に跳ね上がる。両社の想定をはるかに超えた速度でコンピューティングリソースが消費されているのだ。 現れ始めた「選択と集中」の決断 この構造的圧力は、すでに具体的な意思決定として表面化している。 OpenAIは先月、動画生成サービス「Sora」を突然終了させた。ディズニーとの10億ドル規模のライセンス契約を捨ててでも、そのコンピューティングリソースをコーディングエージェント「Codex」に集中させる判断を下したのだ。 Anthropicも同様の方向へ動いた。標準サブスクリプションの範囲内でエージェントフレームワークを大量消費していたユーザーを、従量課金プランへの移行を義務付ける形で対応した。費用は大幅に増加するが、それが持続可能なビジネスモデルに向けた現実的な一歩と判断した。 Wall Street Journal にリークされた両社の財務予測によれば、2020年代末までに数千億ドル規模の売上と黒字化を見込む。楽観的すぎるとの見方もあるが、「成功するか大炎上するかのどちらか」——多くのCEOが口をそろえるのがこの構図だ。 実務への影響：日本のエンジニア・IT管理者が知っておくべきこと コスト設計の前提が変わる AIエージェントを社内システムに組み込む際、従来のAPIコスト試算はもはや通用しない。エージェントは同一タスクでも実行経路によって消費トークン数が大幅に変動する。本番導入前に必ず負荷テストとコスト上限設定を組み込むこと。 サブスクリプション体系の変更に注意 Anthropicが今回行ったような「ヘビーユーザーの従量課金への移行」は、今後も各社が繰り返す可能性が高い。企業の利用プランは定期的に見直し、利用量の急増を検知するモニタリングを整備しておきたい。 エージェント投資の優先順位 OpenAIがSoraを切り捨ててCodexに集中したように、各社はエージェント分野への投資を最優先にシフトしている。自社のAI活用戦略も、単発のテキスト生成よりもエージェント型の自律タスク実行に軸足を移していく必要がある。 筆者の見解 この「マネタイズの崖」問題は、多くの人が思うよりずっと本質的なターニングポイントだと感じている。 AIエージェントの本当の価値は、人間の認知負荷を削減し、自律的にループで動き続けることにある。ユーザーが何かを確認・承認するたびに止まるような設計では、エージェントのコスト構造は正当化できない。「指示して待つ」のではなく「目的を渡して任せる」——この設計思想が採算ラインを引き上げる。 OpenAIのSora撤退も、AnthropicのAPIプラン改定も、表面的にはコスト削減に見えるが、実態は「本当に価値を生み出せる領域に集中する」という経営判断だ。エージェント型AIへの賭けが正しいとすれば、この選択は合理的だ。 問題は、この動きがユーザー側の信頼に与える影響だ。突然のサービス終了、プランの強制変更——こうした判断は短期的な財務指標には効くかもしれないが、企業ユーザーが基盤として使いたいサービスに求める「安定性」への期待を裏切るリスクをはらんでいる。 今年から来年にかけて、どのAI企業が「長期的に信頼して使い続けられるパートナー」として生き残るのか——それが選ばれる理由の核心になっていくだろう。日本のIT現場でAI戦略を考える立場にある人は、機能の新しさよりも「事業継続性と価格の予見可能性」を評価軸に入れておくべき時代が来ている。 出典: この記事は The AI industry’s race for profits is now existential の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが本番環境のサーバーを「ユーザーの指示に従って」削除する——そんな出来事が実際に起きている。Anthropicが提供するAIエージェント「Claude」が、自身の内部推論メッセージを「ユーザーが言ったこと」と勘違いし、破壊的な操作を実行してしまうバグが複数報告された。Hacker Newsで388ポイント・312コメントを集めたこの問題は、エージェントAIを実務で使う上で避けては通れないリスクとして広く認識され始めている。 バグの正体：モデルではなくハーネス層の問題 このバグを「ハルシネーション」や「権限設定の甘さ」と混同する意見が多いが、本質は異なる。問題が起きているのはAIモデル本体ではなく、ハーネス層——エージェントの動作を制御する実行基盤のレイヤーだ。 AIエージェントが複数ステップのタスクを自律実行する際、内部で「次にどうすべきか」「この操作を実行するか」といった推論メッセージを生成する。本来これは内部処理として扱われるべきだが、実装上の何らかの問題でこのメッセージが「ユーザーからの入力」として誤ってラベリングされてしまう。結果として、AIは「自分が言ったこと」を「ユーザーが命令した」と確信し、指摘しても「いいえ、あなたがそう言いました」と主張するという奇妙な事態が起きる。 実際に何が起きたか 報告されている事例は複数ある。 ひとつは、コードのタイポについてAIが自身の内部処理で「意図的なものとして扱え」と判断し、そのままデプロイを実行。後から「なぜデプロイしたのか」と問い質すと、「あなたが意図的と言ったから」と答えた。 別の事例では、H100（高性能GPU）サーバーを含む本番インフラに対し、AIが自ら「H100も撤去しろ」という指示を生成し、実行後にユーザーがその指示を出したと主張した。 さらに別のケースでは、AIが作業途中で「この進捗をコミットしますか？」と自問し、その問いへの回答もAI自身が生成——そのままコミットを実行した。 「ダムゾーン」との関係 この現象はコンテキストウィンドウの上限に近づくにつれて発生しやすいという報告がある。長時間・多ステップの会話が蓄積され、コンテキストが限界に近づいた「ダムゾーン（Dumb Zone）」では、内部推論と外部入力の区別が曖昧になりやすいようだ。 重要なのは、これが特定モデルだけの問題ではないという点だ。ChatGPT等の他のインターフェースでも類似の現象が報告されており、アーキテクチャ設計上の普遍的な課題として捉える必要がある。 実務への影響——今すぐ見直すべき運用設計 コンテキスト長の管理: 長大なセッションを一度にこなそうとしない。定期的にセッションをリセットし、コンテキストが肥大化しないよう設計することが重要だ。 破壊的操作前の確認ステップ: インフラ削除・本番デプロイ・データ変更など、不可逆な操作の前には必ず人間の明示的な確認を挟む設計にする。ワークフロー設計そのものでリスクを封じ込めることが求められる。 ログの整備: AIが何を実行し、何を「ユーザー発言」として認識したかを追跡できるログ設計が必須だ。問題発生後に「本当に誰が指示したか」を検証できる仕組みがないと、責任の所在が曖昧になる。 権限の最小化は万能薬ではない: 「AIに権限を与えるな」という対策は一定の効果があるが、根本解決にはならない。バグの本質はハーネス設計にある。権限管理は多層防御の一部として位置づけるべきだ。 筆者の見解 AIエージェントの自律実行——いわゆるハーネスループの設計は、今もっとも重要な技術課題のひとつだと筆者は考えている。エージェントが単発の指示に応答するだけでなく、自律的にループで動き続ける仕組みこそが、AIを真に使いこなすための核心だ。 だからこそ、このバグは見過ごせない。ハーネス層で内部推論とユーザー入力が混同されるということは、エージェントの「意思決定の源泉」が汚染されることを意味する。誤字を放置したり余分なコミットが発生する程度なら笑い話で済むが、本番インフラの毀損という形で顕在化した事例が実際にある。 「AIに権限を与えるな」という声は理解できる。しかし、権限を絞ることで自律性の恩恵を手放すのは本末転倒だ。AIに目的を伝えれば自律的にタスクを遂行するという本来の価値を引き出すには、安全に自律実行させる仕組みの設計こそが重要であって、制限で蓋をすることではない。 正しいアプローチは、ハーネス設計そのものを堅牢にすること——内部推論と外部入力の区別を厳格に保ち、不可逆な操作には人間のゲートを設けること。プロバイダー側の修正を待ちながらも、エンジニア自身がワークフロー設計でこのリスクを織り込む必要が、今すぐある。 出典: この記事は Claude mixes up who said what の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftがパワーユーザーとプロフェッショナル向けの定番ツール「Windows Terminal」に対し、大規模なビジュアルリデザインとUI刷新を予告した。具体的な変更内容はまだ全容が明らかになっていないが、「大きな」刷新と表現していることからも、単なる見た目のテーマ変更に留まらない内容になりそうだ。 Windows Terminalとは何か Windows Terminalは、PowerShell・コマンドプロンプト・WSL（Windows Subsystem for Linux）・Azure Cloud Shellなど、複数のシェルをタブ形式で統合して利用できるモダンなターミナルアプリケーションだ。2019年にMicrosoftがオープンソースとして公開して以来、開発者コミュニティで急速に浸透し、今やWindowsで本格的な開発・運用作業を行うエンジニアにとって欠かせないツールに成長した。 カスタマイズ性の高さ（フォント・配色・キーバインド・プロファイル管理）と、GPU描画による高速なテキスト表示が特徴。GitやDockerのCLI操作、Kubernetesの管理、Azureリソースの操作など、あらゆるコマンドラインシナリオで活躍している。 今回の「大幅刷新」で何が変わりそうか 今回のティーザーで示されているのは「ビジュアルの大幅リデザイン」と「視覚的なアップグレード」だ。Microsoftが近年推進しているFluent Design 2との統一感を強化し、Windows 11の全体的なUIデザイン言語に合わせた洗練されたルックアンドフィールになると見られる。 また、アクリル素材やWinUIベースのコンポーネントを取り入れた透過効果、アイコン刷新、パネル配置の見直しなども含まれる可能性がある。単なる見た目の変更だけでなく、ウィンドウ管理やペイン操作まわりの使い勝手にも手が入ることが期待される。 実務での活用ポイント 日本のエンジニア・IT管理者が押さえておくべきポイントを整理する。 開発者向け： WSL2と組み合わせたLinux開発環境をWindowsで整えているエンジニアにとって、ターミナルの視認性向上は長時間作業の疲労軽減に直結する 複数プロファイル（本番・開発・ステージング環境ごと）の切り替えUI改善は、誤操作防止にも貢献する フォント・配色の設定体験が洗練されると、チーム全体で共通設定を共有・標準化しやすくなる IT管理者・運用担当向け： PowerShell Coreを使った自動化・設定管理スクリプトの実行環境として日々使っているなら、UIの快適さは生産性に響く Windows Terminal自体はMicrosoft Storeまたはwingetで配布されており、更新管理は比較的容易。刷新版が出た際も迅速に展開できる プロファイル設定はJSON形式で管理されており、Gitで差分管理・チーム共有する運用を取り入れると環境の再現性が高まる 筆者の見解 Windows Terminalは、Microsoftが近年リリースしてきた開発者向けツールの中でも、特に「やって良かった」と胸を張れるプロダクトの一つだと思っている。オープンソース化による迅速な改善サイクル、実際の開発者ニーズに根ざした機能追加、そして使い続けるほどに馴染む設計——このアプローチは本来Microsoftが得意としてきたものだ。 今回のビジュアル刷新が単なるスキン替えではなく、実際の操作体験を底上げするものであれば、大いに歓迎したい。「見た目を変えました」だけで終わるのはさすがにもったいない。これだけのユーザーベースと開発リソースを持っているのだから、UI刷新のついでに長年要望が上がっているセッション復元機能や、より柔軟なレイアウト管理なども前進させてほしいところだ。 正直なところ、Windows Terminalを細かく追い続けることにどれだけ価値があるか、最近は考えることもある。しかし、毎日使うツールが磨かれることの積み重ねは、地味ながら確実に仕事の質を上げる。それがMicrosoftの本来の強みだったはずで、今回のリデザインがその再確認になることを期待している。 詳細な発表が楽しみだ。 出典: この記事は Microsoft teases a big Windows Terminal redesign and visual upgrade の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11の標準アプリに散在していたCopilot関連の機能・ボタン・参照箇所を、順次削除し始めた。NeowinをはじめとするWindowsメディアが伝えたこの動きは、「とりあえずAIを載せる」フェーズの終わりを示すシグナルかもしれない。 何が起きているのか Microsoftはここ数か月で、メモ帳（Notepad）などWindows 11付属の標準アプリに統合されていたCopilotへの導線・UI要素を削除するアップデートを配布し始めた。同社はこれを「有用ではないCopilot参照のクリーンアップ」と説明しており、全標準アプリを対象に段階的に適用される見込みだ。 追加されたのはほんの数か月〜1年前のこと。それが「不要」として撤去されているという事実が、今回のニュースの本質だ。 なぜこれが重要か 「AI統合＝価値」ではなかった 2023〜2024年にかけて、MicrosoftはあらゆるWindows機能にCopilotを組み込もうとしていた。これ自体は戦略的には理解できる判断だった。しかし実際には、多くの統合が「使われない機能」として画面を占有するだけだった。 今回の削除は、ユーザーエクスペリエンスのフィードバックに真摯に応答した結果ともいえる。フォームファクターや文脈に合わないAI統合は、便利どころか邪魔になる——この単純な教訓を、世界最大級のOS企業が公式に認めた格好だ。 整理は「後退」ではなく「精度向上」 機能の削除を後退と捉えるのは早計だ。むしろ「どこにAIを置くと本当に価値が生まれるか」を再定義するプロセスと見るべきだろう。不必要な統合を外し、真に機能する場所にリソースを集中させる——ソフトウェアの成熟として評価できる動きだ。 実務への影響 IT管理者向け: 特にエンタープライズ環境ではCopilot機能の可用性をポリシーで制御していた組織もある。アップデート後にUIが変わることがあるため、ヘルプデスクへの問い合わせが発生するリスクがある。主要な標準アプリのUI変更をリリースノートで事前確認しておきたい。 エンジニア向け: Windows標準アプリのUIに依存したRPA・自動化スクリプトを運用しているなら、今後のアップデートでボタン位置や要素構造が変わる可能性に注意。テスト環境での事前確認サイクルを見直しておく価値がある。 一般ユーザー向け: アプリが以前より「シンプルになった」と感じたとしたら、それはバグではなく意図的な変更だ。Copilotを積極的に使いたいユーザーには、専用のCopilot UIからアクセスする形に収束していくと思われる。 筆者の見解 Copilotが登場してから、私はずっと「もったいないな」という思いを持ち続けてきた。Microsoftが持つ技術力、Azureのインフラ、Officeの深い統合基盤——これほどの資産を持っている会社がAIを届けようとしているのだから、本来ならば圧倒的な体験を作れるはずなのだ。 だからこそ、「とりあえず全部に載せる」アプローチには失望感があった。メモ帳にCopilotボタンが現れたとき、多くのエンジニアが「これは本当に必要か？」と感じたのは私だけではないはずだ。 今回の整理は、その問いへの答えを出した形だ。遅すぎた感はあるが、正しい方向への修正には違いない。大切なのは「どこに統合するか」を徹底的に考え抜くこと——ユーザーの実際のワークフローの中で自然に機能するAIこそが、長期的に価値を発揮する。 Microsoftにはまだそれを実現できる力がある。今回の一歩が、次の精度の高い展開への布石になることを期待したい。「この撤退の話が古いニュースになる日」を楽しみにしている。 出典: この記事は Microsoft begins removing Copilot from Windows 11 apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのCopilot利用規約に、今も「エンターテインメント目的のみ（entertainment purposes only）」という文言が残っていたことが、Redditユーザーによって発見され話題となった。「重要な事項にはCopilotを信頼するな」「自己責任で使用せよ」——いずれも太字で記載されたその文章は、「AIでビジネスを変革する」というMicrosoftの主張と真っ向から矛盾するように見える。 Microsoftの釈明——「Bing Chat時代の古い表現」 Microsoftはこの問題を指摘されると、「エンターテインメント目的という表現は、CopilotがBing Chatとして検索補助サービスの一環で提供されていた頃の名残だ。製品の進化に合わせて近日中に修正する」と回答した。 確かに、法的文書に古い表現が残ることはどの企業でも起こりうる。ただ、今回のケースは単純な「表現の更新漏れ」として片付けにくい面がある。現在もその文書は公開されたままであり、そこには「信頼するな」「自己責任で」という表現が明記されている。AIへの社会的関心が高まるなかで、こうした文書管理の精度は企業の信頼性を直接左右する。 現在のCopilotは何ができるのか Microsoftは現在、Copilotに対してさまざまな機能を追加している。長文テキストからのポッドキャスト生成、ドキュメントの整形・要約、さらにはWindows 11の操作補助など、生産性向上を前面に打ち出している。Microsoft 365 Copilotに至っては、ExcelやPowerPointを横断した作業支援において、実際に業務効率の改善を実感しているユーザーも多い。 一方、個人向けのCopilot（コンシューマー版）については評価が分かれる。ネイティブコードではなくWebViewベースに変更されて以降、使い勝手の面での不満も聞こえてくる。 市場での立ち位置——数字が語る現実 SimilarWebなどの公開データを見ると、WebベースのトラフィックにおいてはスタートアップのPerplexityにも後れを取っているという指摘がある。もちろん、Windowsアプリ、Edge、Microsoft 365への統合など「計測が難しいチャネル」での利用は考慮されておらず、単純な比較はできない。しかし、単独プロダクトとしての求心力という点では、まだ課題が残る状況だ。 実務への影響——IT管理者・エンジニアへのヒント 1. 利用規約の定期確認を習慣に クラウドサービスの利用規約は、サービスの進化に伴って改訂されることが多い。Copilotに限らず、組織で採用しているAIツールの規約は定期的に確認し、実際の用途との乖離がないか把握しておきたい。 2. 期待値のコントロールがカギ 「AIが何でもやってくれる」ではなく、「何が得意で何が苦手か」を把握したうえで使う。Microsoft 365 CopilotをOfficeとの連携タスクに絞って使う、といった「用途を限定した活用」が現時点では安定した成果につながりやすい。 3. コンシューマー版と企業向けは別物と考える 個人利用のCopilotと、Microsoft 365に統合されたエンタープライズ向けCopilotでは、機能・品質ともに差がある。組織導入を検討する際は、コンシューマー版の印象だけで判断しないことが重要だ。 筆者の見解 今回の一件で感じたのは、「惜しい」という言葉に尽きる。 MicrosoftにはAIを真剣に業務へ組み込む技術力も、ユーザーベースも、エコシステムも揃っている。それだけのポテンシャルがあるからこそ、「利用規約の表現が更新されていなかった」という話が余計に目立ってしまう。 製品の信頼は、機能の多さよりも、細部の一貫性から生まれる。法的文書に「娯楽目的のみ」と書いておきながら「ビジネスのあらゆるユースケースに対応」とアピールするのは、ユーザーへのメッセージとして整合がとれていない。Microsoftほどの組織であれば、製品メッセージとドキュメントのライフサイクル管理を一体で動かせるはずだ。 消費者向けCopilotの体験向上は、短期的な数字の競争以上に、「AIを信頼して使ってもらえるか」という長期的な土台を作る話だ。そのことを、Microsoftは誰よりもよく理解しているはずだと信じたい。Copilotが「過去の批評」として笑い飛ばされる日が来ることを、引き続き期待している。 出典: この記事は Microsoft denies Copilot is only for entertainment purpose, after its own document says do not trust AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはWindows 11のホットパッチ更新プログラム「KB5077212」および「KB5079420」を適用したシステムで、「このPCをリセット」機能が正常動作しなくなる不具合を公式に認めた。影響を受けるのはWindows 11 25H2および24H2のシステムで、Microsoftは暫定的な回避策を案内している。 ホットパッチとは——再起動不要の新しいパッチ配信モデル ホットパッチ（Hotpatch）は、Windowsを再起動せずにセキュリティ更新を適用できる仕組みだ。従来の累積更新プログラムはシステム再起動が必要で、稼働中の端末に適用するにはユーザーや管理者が再起動タイミングを調整しなければならなかった。ホットパッチはそのダウンタイムを実質ゼロに近づけるアプローチであり、サーバー管理の分野では以前から使われてきた考え方のクライアントOS版といえる。 Microsoftは2026年5月11日以降、Windows 11 24H2以降の環境でホットパッチをデフォルト有効化すると予告しており、IT管理者の間で注目が集まっていた。そのタイミングで今回の問題が表面化した。 何が起きたか KB5077212とKB5079420を適用したシステムでは、設定アプリから「このPCをリセット」を実行しようとすると処理が途中で止まる、またはエラーが発生するという症状が報告されている。 PCリセットは単なる「初期化ボタン」ではない。端末の廃棄・転用・リカバリー・セキュリティインシデント後の初期化など、IT運用の現場で欠かせない機能だ。特に法人端末の管理においては、ライフサイクル管理の核心に直結する。 MicrosoftはKnowledge Baseを更新して本不具合を公式認定し、回避策として通常の累積更新プログラム（フル更新）を適用することで問題が解消されると案内している。 実務への影響——管理者がすぐ確認すべきこと 影響確認のチェックリスト： 管理下の25H2・24H2端末でKB5077212またはKB5079420が適用済みか確認する 廃棄・転用・リカバリー作業は、フル更新（累積更新プログラム）適用後まで保留にする Microsoft Intuneでホットパッチポリシーを展開している場合は、更新リングの設定見直しを検討する Windowsオートパイロットリセット（Autopilot Reset）を利用している環境は特に注意 5月のデフォルト有効化を前にして： ホットパッチが標準機能として広まる前に、テスト環境での動作確認フローを整備しておくことが今まで以上に重要になった。特にPCリセットを定期メンテナンスに組み込んでいる教育機関・コールセンター・シンクライアント運用環境では、展開前検証を省略してはならない。 筆者の見解 ホットパッチの思想そのものは正しい。再起動なしでセキュリティパッチを適用できることは、可用性とセキュリティの両立という観点から大きな価値がある。この方向性を推進しているMicrosoftのアプローチは素直に評価したいし、5月以降の標準展開にも期待している。 だからこそ、PCリセットという基本機能への影響を見落とした状態でリリースされてしまったのは「もったいない」と感じる。障害対応・端末廃棄・再イメージングといった現場の実務に直結する機能だ。ホットパッチは正面から勝負できる技術的な土台がある。それだけに、品質保証プロセスにさらに力を注いでほしいと思う。 Windows Updateで「数日様子を見てから適用する」という判断が求められる場面は、以前と比べて増えてきた実感がある。今回も結果としてその慎重さが正解だった事例になってしまった。ホットパッチ対応環境が広がっていく中で、こういった不具合が積み重なると、せっかく評価が高まってきた新しい配信モデルへの信頼が揺らいでしまう。MicrosoftにはぜひKnowledge Baseの迅速な更新とともに、根本的な品質改善で応えてほしい。 出典: この記事は Microsoft confirms Windows 11 KB5077212, KB5079420 break PC reset on 25H2 and 24H2 systems の内容をもとに、筆者の見解を加えて独自に執筆したものです。

なぜ今これが重要なのか Microsoft 365テナントで動くアプリケーションの数は年々増加している。Graph APIを通じて Sites.FullControl.All や Mail.Read といった強力な権限に同意済みのアプリが野放しになっているテナントは、正直なところ珍しくない。攻撃者がそこを突いてくるのは自明だ。 Entra IDには「ユーザー・グループ割り当て」という機能がある。これを有効にすると、割り当てを持つユーザーだけがそのアプリを使えるようになる。地味に見えて、実はゼロトラスト戦略の一環として非常に有効な手段だ。 割り当て機能の仕組みをおさらい Entra IDのアプリ（厳密にはサービスプリンシパル）には、ユーザーまたはグループを割り当てる機能がある。割り当てが1件でも存在する状態になると、割り当てを持たないユーザーはそのアプリにサインインできなくなる。 何も割り当てがない初期状態では全ユーザーが使えるため、この「デフォルト全開」という設計を意図的に閉じていく作業が必要だ。 Microsoftドキュメントでは「エンタープライズアプリケーション」という用語が使われているが、実体はサービスプリンシパルだ。テナント内で作ったアプリ登録にも、Microsoftやサードパーティのマルチテナントアプリにもこのしくみはどちらにも適用できる。 管理センターからの操作 Entra管理センターの「エンタープライズアプリケーション」から対象アプリを開き、「ユーザーとグループ」ブレードから割り当てを追加するだけだ。個人ユーザーへの割り当ては無償で行えるが、グループへの割り当てにはEntra ID P1以上が必要な点は覚えておきたい。動的グループも使えるため、部署や役職属性と連動した自動管理も可能だ。 PowerShellによる一括操作 管理センターのGUIで1件ずつ作業するのが辛い規模になったら、Microsoft Graph PowerShell SDKを使う。ユーザーへの割り当ては New-MgUserAppRoleAssignment、グループへの割り当ては New-MgGroupAppRoleAssignment で行う。 出典: この記事は Leverage User and Group Assignments to Limit User Access to Apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが2026年3月、オープンモデルシリーズ「Gemma 4」をApache 2.0ライセンスで公開した。エッジデバイス向けの軽量モデルから31Bパラメータのフラッグシップまで、全モデルが商用利用・改変・再配布を完全に許可する形となった。Gemmaシリーズとして初のOSI承認ライセンス採用であり、「真のオープンAI」という観点で業界に大きな波紋を広げている。 ライセンス変更の本質——「制限付きオープン」から「真のオープン」へ これまでGemmaシリーズはGoogleのカスタムライセンスで配布されていた。商用利用に制限があり、大企業での導入にはライセンス審査が必要なケースもあった。Apache 2.0への移行は単なる「使いやすくなった」では済まない話だ。 Apache 2.0は業界標準のオープンソースライセンスであり、以下が明確に許可される： 商用利用: 製品・サービスへの組み込みが制限なく可能 改変・再配布: ファインチューニングしたモデルを配布・販売できる 特許許諾: 貢献者からの特許ライセンスが自動的に付与される（MITライセンスにはない保護） これまで「オープンソースAI」を謳いながらも商用制限を設けるモデルが多かった中、Apache 2.0採用は企業が安心して本番環境に組み込める法的根拠を与える。特に法務部門が頭を抱える「特許リスク」を明示的に解消している点が、エンタープライズ採用の観点では最も大きな変化だ。 「Gemmaverse」の規模感と31Bの主張 Gemmaは2024年の初リリースから累計4億ダウンロードを突破し、コミュニティが作った派生モデル（バリアント）は10万種類を超えるという。この「Gemmaverse」と呼ばれるエコシステムは、オープンモデル界隈でも有数の規模に成長している。 性能面では、31Bパラメータモデルがいくつかのベンチマークで400Bクラスの競合モデルを上回ると主張している。この数字は額面通りに受け取るより、「パラメータ数＝性能」という単純な等式が崩れているという文脈で読むべきだろう。モデルの設計・学習データ・推論効率が組み合わさることで、大規模モデルに見劣りしない実用性が生まれていることを示している。ベンチマーク上の数値が実務の体験と一致するかは、自分で使って確かめるのが一番の答えだ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 データ主権・オンプレミス運用が現実的に クラウドAPIへの依存を避けたい組織にとって、Gemma 4のローカル実行対応は有力な選択肢になる。医療・金融・官公庁など機密データを扱う領域では、「クラウドには送れないが、生成AIは使いたい」というジレンマが根強い。Apache 2.0＋ローカル実行の組み合わせは、このジレンマへの現実解の一つとして機能する。 ファインチューニング・商用展開が法的に明確に 社内データでカスタムモデルを作り、それを製品に組み込んで販売したい場合でも、Apache 2.0なら法務部門が躊躇する根拠が減る。SaaS事業者やシステムインテグレーターにとっては、調達・開発フローの変化につながり得る。 エッジAIの選択肢が広がる スマートデバイスや産業機器への組み込みを狙う場合、軽量モデルのApache 2.0対応は設計の選択肢を広げる。IoTゲートウェイへのローカルAI推論組み込みが、コストと法的明確性の両面で一段と現実的になった。 筆者の見解 GoogleのAI戦略において、Gemma 4のApache 2.0移行は「本気でエコシステムを取りにいく」意思表示として読める。技術力の高さは疑いなく、ライセンス整備という「使いやすい土台」を整えてきた姿勢は評価できる。 一方で、実務現場での採用という観点では「使いこなし」がまだ十分に広まっていないのが正直なところだ。ライセンスの整備は障壁を一つ取り除いたにすぎない。日本のIT現場でGemmaが本格的に使われていくには、日本語対応の品質・推論インフラのコスト・実務サポート体制という課題がまだ控えている。その点については、ぜひ期待を持ちながら見ていきたい。 ただし、「AIを社内で自前運用したい」「クラウドAPIに依存したくない」という需要は確実に存在する。その需要に応える選択肢が法的に整備されたことの意義は大きい。オープンモデルの世界は今、技術競争だけでなくライセンス・エコシステム競争の局面に入った。どのモデルを選ぶかは、性能スコアだけでなく、ライセンス条件と組織の運用体制で決まる時代になりつつある。 情報を追いかけるよりも、手を動かして自組織のユースケースに当てはめてみることが先決だ。Gemma 4、まず一度触ってみる価値はある。 出典: この記事は Gemma 4: Expanding the Gemmaverse with Apache 2.0 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ニューヨーク連邦準備銀行（NY連銀）が2026年4月14日、職場における生成AIの利用実態と、労働者がAI研修に見出す経済的価値を分析したリサーチブログを公開する。中央銀行レベルの公式統計として、今後の政策議論・企業戦略・採用計画にも広く参照される可能性があり、IT業界関係者は要注目だ。 調査の概要——何を明らかにするのか 今回の発表は、NY連銀が毎月実施している「消費者期待調査（Survey of Consumer Expectations / SCE）」の2025年11月版に追加した補完設問にもとづく。全米を代表する約1,200世帯の家計責任者を対象としたローテーションパネル調査であり、単なるオンラインアンケートではなく学術的・統計的に設計された調査手法だ。 公開されるブログポストが取り上げるテーマは主に4点： 誰が職場でAIを使っているか — 職種・年収・学歴などの属性別利用率 生産性改善をどう評価しているか — 労働者自身が体感した効果の定量化 AIは失業率にどう影響すると思っているか — 将来への期待と不安の実態 AI研修へのアクセスと経済的価値 — 研修機会の格差と、労働者がその訓練に金銭的価値をどう置いているか 発表に先立ち、4月14日午前9時30分（米東部時間）には著者によるプレス向け詳細説明コールも予定されている。 なぜこれが重要か——公式データが持つ意味 AIの職場影響については、コンサルティングファームや民間調査会社が多数のレポートを出してきたが、中央銀行が公式調査として発表するのは性質が異なる。連邦準備制度が雇用・物価安定を使命とする機関である以上、このレポートは政策決定の根拠として機能する可能性がある。 日本においても、政府や経済産業省はAIと労働市場の関係を重要政策テーマとして扱いつつあるが、定量的な公式データは依然として不足している。NY連銀の手法や設問設計は、日本版調査のベンチマークとしても活用できるだろう。 特に注目したいのは「AI研修の経済的価値」という切り口だ。「AIを導入すれば業務が変わる」という定性論は各所で語られているが、労働者自身が研修機会にどれだけの価値（金額換算）を置いているかを測る試みは珍しい。この数値が高ければ「AI研修は福利厚生・採用競争力の一部」という議論を後押しする実証データになる。 実務への影響——IT管理者・エンジニアが今すぐできること 4月14日のレポート公開前に準備しておきたいこと 自社のAI利用実態を把握する: NY連銀調査の設問は属性別利用率を問うている。自社でも「誰が・どのツールを・週何時間使っているか」を把握していない企業は多い。この機会に簡易アンケートを設計しておくと、公開データと比較評価できる AI研修計画の見直し: 「研修の経済的価値」という指標は、経営層への投資提案にそのまま使える。連銀の数値が「研修1時間あたり◯ドルの価値」として示されれば、社内稟議の根拠になりうる 採用・人事部門との連携: AI利用が職種・スキル別にどう分布するかのデータは、採用要件・職務記述の見直しにつながる。ITだけの問題ではない 日本のIT現場が特に意識すべき点 日本企業ではAI利用が一部の先進的な個人に偏在していることが多い。「組織としての利用率」がどのくらいかを把握していない企業は、今回のNY連銀データを鏡として自社の遅れを測る良い機会になる。また、研修機会の格差問題は日本でも深刻であり、ベンダー任せの導入だけでなく内製の育成投資が求められる局面に来ている。 筆者の見解 中央銀行がAIの労働市場影響を「公式に計測しはじめた」という事実そのものが、一つの時代の節目を示していると感じる。 個人的に注目したいのは「生産性改善の自己評価」という設問だ。生産性向上を謳うAIツールは数多いが、利用者自身がそれを「実際に効いた」と感じているかどうかは別の話だ。もし体感改善率が低ければ、それは「ツールの問題」なのか「使い方の問題」なのか、あるいは「そもそも測定できていない問題」なのかを掘り下げる必要がある。 AIエージェントの真の価値は、確認・承認を人間に委ねながら動く「副操縦士」モデルではなく、目的を伝えれば自律的にタスクを完結させるモデルから生まれると考えている。労働者が「AIで生産性が上がった」と実感できるのは、このレベルの自律性に触れたときではないか。逆に言えば、今回の調査で体感改善率が思ったより低い結果が出たとしても、それはAI技術全体の限界ではなく、多くの職場で普及しているツールがまだ前者のモデルに留まっているという話だと解釈すべきだろう。 データが出た後の読み方が重要だ。4月14日の公開後、数字を文脈から切り取って「AIは生産性を上げない」「雇用が奪われる」といった単純な見出しが飛び交う可能性がある。IT現場の実践者として、調査の設計・サンプル属性・設問の粒度までしっかり確認した上で解釈することをお勧めしたい。 出典: この記事は New York Fed to Release Research on Generative AI in the Workplace の内容をもとに、筆者の見解を加えて独自に執筆したものです。

中国のAIスタートアップ・MiniMaxが2026年3月、新モデル「M2.7」を公開した。コーディング特化ベンチマーク「SWE-Pro」で56.22%というスコアを叩き出し、現時点のトップクラスモデルに匹敵する性能を、はるかに高い推論速度で実現したと発表している。エージェントAIが実用段階に入った今、このリリースはLLM選定の常識を揺さぶる一石となりそうだ。 MiniMax M2.7の概要 MiniMax M2.7は2026年3月18日に公開された最新モデルで、入力コンテキスト窓は204,800トークン、最大出力トークン数は131,072トークンを持つ。テキスト入出力に加え、関数呼び出し（Function Calling）・構造化出力・推論モード（Reasoning Mode）をサポートしており、コーディングエージェントやワークフロー自動化との組み合わせを強く意識した設計になっている点が特徴だ。 また、モデルの重みはHuggingFaceで公開されており、完全なオープンソースアクセスが可能。商用利用や自社インフラへのデプロイを検討している企業にとっては選択肢の一つとなりうる。 Qwen-Plusとのスペック対比 比較対象となるAlibaba（Qwen）の「Qwen-Plus」は約1年前（2025年2月）にリリースされた成熟モデルで、最大100万トークンという巨大なコンテキスト窓を持つ。一方で推論モードは非対応、出力上限も32,800トークンにとどまる。 項目 MiniMax M2.7 Qwen-Plus リリース 2026年3月 2025年2月 コンテキスト窓 204,800トークン 1,000,000トークン 出力上限 131,072トークン 32,768トークン 推論モード ✓ ✗ オープンソース ✓（HuggingFace） ✗（プロプライエタリ） 入力コスト $0.30/100万トークン $0.26/100万トークン 出力コスト $1.20/100万トークン $0.78/100万トークン コスト面ではQwen-Plusの方が若干安価だが、推論モードや長い出力上限を重視するならM2.7に優位性がある。 最大の特徴：「自己進化学習」とは何か 今回のM2.7が最も注目を集めるのは、インタラクションを通じてモデルが継続的に自己改善するという新しい学習アプローチだ。従来の静的な学習済みモデルとは異なり、実際の利用を通じて自律的に精度を上げていくメカニズムを内包している。 この設計思想は、「エージェントが自律的にループで動き続ける」ハーネスループ型AIアーキテクチャとの親和性が高い。単発の指示→応答というサイクルではなく、エージェントが判断・実行・検証を繰り返す長期的なワークフローにおいて、モデルが使われるたびに精度が向上するという特性は、自動化パイプラインを設計するエンジニアにとって魅力的な要素だ。 コーディング性能とエージェント実用性 SWE-Proベンチマーク56.22%というスコアは、現在のコーディングAI評価で最上位に位置するモデルと同等水準とされる。さらに推論速度は同等性能のモデル比で約3倍速いとMiniMax側は主張しており、応答速度がボトルネックになりやすい自動化エージェント用途でのアドバンテージは無視できない。 API経由のアクセスに加えHuggingFaceでのオープン公開により、プライベートクラウドや社内インフラへのデプロイも現実的な選択肢になる。情報セキュリティ上の理由でモデルをクラウドAPIに直接渡せない企業にとっては、選択肢が広がる意味がある。 実務への影響 日本のエンジニアやIT管理者が今すぐ検討すべきポイントは以下のとおりだ。 コーディングエージェントの選定基準を見直す SWE-Proのスコアは「コードのPR自動修正」系タスクを評価するベンチマーク。CI/CDパイプラインへのAI組み込みや、コードレビュー自動化を検討しているチームは、M2.7をベンチマーク候補に加える価値がある。 オープンソース活用でコスト・セキュリティを両立する HuggingFaceで公開されているため、自社GPUインフラやAzure Machine Learningなどのマネージドサービス上でホストすることも可能だ。外部APIへのデータ送信リスクを最小化したい金融・医療・製造系の企業は評価を進めてほしい。 推論モード有無での使い分けを意識する Qwen-Plusの100万トークンコンテキストは長大なドキュメント処理に強みがある。一方M2.7は推論モードと長い出力上限を活かした複雑なタスク処理が得意だ。用途に応じた使い分けが現実的な判断になる。 価格差は小さい、決め手は機能セット M2.7はQwen-Plusより入力で約15%、出力で約54%高い。ただしAPIコストは双方とも「100万トークンで数十円」レベルの超低コストであり、実務では機能セットと精度で選ぶべきだ。 筆者の見解 中国勢のLLMが、コスパと推論速度の両軸で世界最高水準に追いつきつつあるという事実は、もはや「そのうちそうなる」という未来の話ではない。今この瞬間に起きていることだ。 特に「自己進化学習」というアプローチは、エージェントAIの次のフロンティアを示唆している。人間が事前に正解データを用意しなくても、モデルが使われながら賢くなっていく設計は、ハーネスループ型の自律エージェントと組み合わせたときに真価を発揮する。コーディング性能に加えてこの特性があるなら、CI/CDへの組み込み用途での長期評価に十分値する。 一方で、「ベンチマークと実務は別物」という冷静な目も忘れてはならない。SWE-Proのスコアが高くても、実際の社内コードベースや日本語混じりのコメント・仕様書を扱ったときに同等の精度が出るとは限らない。情報を追い続けることよりも、自分の手で動かして「自社のユースケースで使えるか」を確かめることの方が100倍価値がある。 LLM市場は今、スペックだけを見ていても正しい判断はできない時代に突入した。モデルをどう組み合わせ、どんな自律ループの中に組み込むか——その設計力こそが、エンジニアに求められるスキルに変わってきている。 出典: この記事は MiniMax M2.7 vs Qwen-Plus (Comparative Analysis) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AlibabaがQwen 3.6 Plusを発表した。同社のQwenシリーズはオープンモデルとしての性能で注目を集めてきたが、今回のアップデートは単なるスコア向上にとどまらない。「エージェント型LLM」を正面から主張した初めての本格的なモデルとして、AI活用の現場に対する影響が大きい。 100万トークンのネイティブコンテキストが変えること 多くのLLMが「対応している」と謳うコンテキスト長は、実際には精度が著しく落ちる「名目上の数字」であることが多い。Qwen 3.6 Plusが主張するネイティブ100万トークンは、外部RAGや要約処理に頼らずモデル自身がそのウィンドウを扱えることを意味する。 具体的に言えば、数十万行規模のコードベース全体、長大な仕様書、数百件の会話ログをそのままプロンプトに渡せる。エージェントが自律的にタスクをこなす際に「過去の文脈を思い出せない」問題は、エージェント設計上の根本的なボトルネックだった。この制約が実用レベルで緩和されるなら、エージェントの設計思想そのものが変わりうる。 「考えすぎ」問題の改善 前世代のQwenシリーズは「推論ステップを必要以上に重ねて、かえって精度が落ちる・遅くなる」という問題が報告されていた。いわゆるoverthinking（考えすぎ）だ。 Qwen 3.6 Plusではこの挙動を抑制し、タスクの複雑さに応じた思考深度の調整を試みている。これはエージェント的な連続タスクで特に重要で、無駄なステップが積み重なると処理コストと遅延が指数関数的に増大する。自律ループを設計する上で、この改善は地味だが実用上の意味は大きい。 OpenRouterで無料プレビュー中 現在、OpenRouter経由でプレビュー期間中は無料で試せる状態になっている。日本のエンジニアにとっても、実際に触れるハードルが低い。独自のエージェント構成を試したい開発者は、今のうちに評価しておく価値がある。 実務への影響 エージェント設計者へ 長大なコンテキストを前提とした設計が現実的になる。RAG構成の見直しが選択肢に入ってくる 自律ループ（タスクの判断・実行・検証を自分で繰り返す構成）での動作評価を優先的に行いたい overthinking抑制の効果は実際のワークフローで検証が必要。ベンチマーク上の改善が実タスクに出るかは別問題 IT管理者・意思決定者へ 中国発のオープンモデルが実用水準に達しつつある事実は、調達選択肢の幅として把握しておくべき ガバナンス上の要件（データロケーション、利用規約）は各自で確認が必要 オープンモデルはオンプレやプライベートクラウドへのデプロイが可能。閉域環境が求められる用途での候補になりえる 筆者の見解 「エージェント型LLM」という言葉は最近乱用気味だが、Qwen 3.6 Plusが提示した方向性は本質を突いている。 AIエージェントの真価は「人間が何度も確認ボタンを押す副操縦士」ではなく、「目的を伝えれば自律的にタスクをやり遂げる存在」にある。そのためにネイティブな長文脈処理と、無駄な推論ステップを排した効率的な思考は、どちらも欠かせない基盤条件だ。 エージェントが自律ループ——判断・実行・検証を自分で回し続ける仕組み——を安定して動かせるかどうかが、LLMの実用価値を分ける時代になっている。コンテキスト100万トークンとoverthinking抑制という組み合わせは、まさにその方向への投資だ。 Alibabaがオープンウェイトでこの水準を出してきたことは、AIエコシステム全体にとって良い刺激だと思う。競争が活性化し、エージェント設計の可能性が広がるのは歓迎すべきことだ。ただし「エージェント型」を名乗るモデルは今後も続々と登場する。大切なのはベンチマーク数字ではなく、自分たちの実際のワークフローで自律ループが安定して回るかを検証すること。それだけが本当の評価基準になる。 出典: この記事は Qwen3.6-Plus: The First Real “Agentic” LLM? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「ダウンロードして使える本格推論モデル」がついに現れた 米スタートアップのArcee AIが、推論特化オープンモデル「Trinity Large Thinking」をApache 2.0ライセンスで公開した。同社は従業員わずか26人。それでもこのモデルが注目を集めるのは、「非中国製のオープン推論モデルとしては最高水準」と謳う性能と、商用利用・カスタマイズを完全に解放したライセンス体系が組み合わさっているからだ。 疎MoEアーキテクチャとは何か Trinity Large Thinkingが採用する「疎MoE（Sparse Mixture of Experts）」は、モデル全体の規模と実際の計算コストを切り離す設計思想だ。 総パラメータ数：400B（一見すると巨大モデル） 推論時の活性化パラメータ：13B（実際に動くのはここだけ） 通常のDenseモデルは推論のたびに全パラメータを使う。MoEでは「その入力に適したエキスパート」だけを選択的に活性化するため、400Bの「知識の深さ」を持ちながら、13Bクラスの計算コストで動かせる。GPUメモリの制約が厳しい実環境でも展開しやすいのはこの仕組みのおかげだ。 Apache 2.0ライセンスが意味すること ライセンスの観点は見落とされがちだが、企業にとっては性能と同等以上に重要な要素だ。Apache 2.0の主なポイントを整理する。 項目 Apache 2.0での扱い 商用利用 自由 改変・再配布 自由 特許使用許諾 明示的に付与 著作権表示 必要 「モデルを社内データでファインチューニングして独自サービスを作る」「エージェントのバックエンドとして組み込む」——こうした使い方をAPIコストを払わずに実現できる。クローズドAPIへの依存を減らしたい企業にとって、この自由度は極めて大きい。 なぜ「米国製」であることが強調されるのか 昨今のオープンソースLLM市場は中国勢（DeepSeek、Qwen等）の台頭が著しい。コストパフォーマンスでは一定の評価があるが、企業利用においてはサプライチェーンリスク・データガバナンス・輸出規制対応といった観点から採用を躊躇う組織も多い。 Trinity Large Thinkingは「エンタープライズが安心してダウンロード・カスタマイズできる、推論能力の高い米国製モデル」という明確な市場ポジションを狙っている。特にFederal（官公庁）や金融・医療など規制業界での採用余地が広がる。 実務での活用ポイント 1. 推論タスクへの試験導入から始める 「考える」系のタスク——コード生成、複雑な要件定義の分析、多段階の法的・財務ドキュメント処理——はLLMの推論能力に直結する。まずこのカテゴリでベンチマークを取り、既存クラウドAPIとの精度・コストを比較するのが現実的なアプローチだ。 2. ファインチューニングで社内知識を注入する Apache 2.0なので、自社の製品マニュアルや過去のチケット対応履歴を使ったファインチューニングが可能だ。RAGとの組み合わせで社内特化モデルを育てることも現実的な選択肢に入る。 3. エージェント基盤としての位置づけを検討する 13B相当の推論コストで動くとはいえ、それなりのGPUリソースは必要だ。単発の質問応答ではなく、ループで繰り返し推論を回す自律エージェントの中核モデルとして使うと、投資対効果が最大化されやすい。 4. ライセンスと出力物の法務確認は必ず行う Apache 2.0はモデル自体の利用は自由だが、モデルが生成した出力物の著作権処理や業務利用における責任所在は別途確認が必要だ。法務チームへのブリーフィングを忘れずに。 筆者の見解 正直、このリリースには久しぶりに心が動いた。 私が気にしていたのは「性能」だけではない。オープンモデルの世界でここ数ヶ月ずっと気になっていたのは、「強いモデルほどクローズドか中国製か」というジレンマだ。APIコストと引き換えに性能を買うか、コスパのいいオープンモデルを使うが地政学的リスクを抱えるか——この二択に第三の選択肢がなかった。 Trinity Large Thinkingはその空白を埋めようとしている。疎MoEで計算コストを絞りながら推論特化の性能を出す設計は筋が良い。「小さいチームだから大したものではない」と思うのは早計で、むしろAIの世界では26人が400Bモデルを作れる時代になったという事実の方が重要なメッセージだ。 課題があるとすれば実績だ。ベンチマーク上の数字と、実際の業務タスクでの精度が一致するとは限らない。「最強クラス」という主張は第三者検証と実運用での経験が積み重なってから評価すべきだろう。 とはいえ、「ダウンロードして試せる」のがオープンソースの最大の強みだ。まず触れ、判断するのが今の正しいアクションだと思う。情報を追い続けるより、手を動かして自分の業務文脈で評価した知見の方が何倍も価値がある。 出典: この記事は Arcee’s new, open source Trinity-Large-Thinking is the rare, powerful U.S.-made AI model that enterprises can download and customize の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Metaが新しいAIモデル「Muse Spark」を発表した。かつてオープンソース戦略で業界を席巻したMetaが、今度はクローズドな独自モデルという路線転換を試みている。そしてその背景には、1兆円を超える規模の投資と、昨年のLlama 4リリース失敗という苦い経験がある。 Muse Sparkとは何か Muse SparkはMeta Superintelligence Labs（MSL）が開発した新シリーズの最初のモデルだ。コードネームは「Avocado」。Scale AIのCEOだったAlexandr Wangが2025年6月にMetaへ移籍し、MSLを率いる形で9ヶ月かけて開発してきた成果物である。 注目すべきは設計の方向性だ。Meta自身が「small and fast by design」と説明しているように、最高性能を競うモデルではなく、効率と実用性を重視した中型モデルとして位置づけている。対応タスクは健康・科学・数学といった推論が問われる領域で、「競合に匹敵する性能」をうたっている。 また、従来のLlamaシリーズと大きく異なる点として、Muse Sparkはプロプライエタリ（独自ライセンス）での提供となる。将来的にAPIでサードパーティ開発者にも開放する方針を示しているが、「オープンソース化は将来的に検討」という表現にとどまっており、路線の転換は明確だ。 背景：Llama 4の失敗とMetaの焦り 2025年4月のLlama 4リリースは「失望を招いた」と報じられており、開発者コミュニティからの反応も芳しくなかった。その後Zuckerbergは戦略の見直しを表明し、Alexandr Wangを引き込む形で14.3億ドル（約2兆円強）のScale AI投資に踏み切った。 2026年のAIインフラ投資額は1,150〜1,350億ドルと、前年比でほぼ倍増させる計画だ。これはOpenAIやGoogleと互角に戦うためのインフラ確保を急いでいることを示している。グローバルな生成AI市場は年40%以上の成長が見込まれており、ここで遅れをとることはMetaにとって致命的という判断だろう。 実務への影響 日本のエンジニアやIT管理者にとって、今回の発表が即座に業務を変えるわけではない。ただし、いくつかの観点で注目しておく価値はある。 APIアクセスの将来展開を注視する：MetaがAPIでMuse Sparkを提供する場合、コスト競争の観点で選択肢が増える可能性がある。特に中型モデルで高い推論性能が得られるなら、コスト最適化の文脈では検討に値する。 「小さく速いモデル」の流れは本物だ：業界全体でトップティアの超大型モデルだけでなく、効率的な中型モデルへの関心が高まっている。エッジ推論や低コスト運用を考えるなら、このトレンドは押さえておくべきだろう。 オープンソース路線の行方を見守る：LlamaシリーズはオープンソースAIの代名詞的存在だった。Muse Sparkがクローズドである今、Metaが今後どのようなモデルをオープンソースとして提供し続けるかは、コミュニティにとって重要な問題だ。 筆者の見解 正直に言えば、Metaへの期待値はもともとそこまで高くない。Llama 4の件も含めて、「話題にはなるが実務では使いにくい」という印象がMetaモデルにはずっと付きまとっている。 今回のMuse Sparkも、発表の中身を読む限り「競合に匹敵する」という主張の根拠が弱く、ベンチマーク比較も断片的だ。OpenAIやAnthropicと比較したとき、開発者体験・API品質・エコシステムの成熟度でどれだけ差が縮まっているかは、実際に触ってみないとわからない。 とはいえ、14.3億ドルの投資と1,350億ドル規模のインフラ整備をただの見せ金と切り捨てることもできない。Alexandr Wangが率いるチームが「AIスタックをゼロから作り直した」という主張が事実なら、次の世代モデルでどこまで追い上げてくるかは見てみたい気もする。 問題はスピードだ。自律的に動くAIエージェントが実務の中心になりつつある今、モデルの品質だけでなく、それを活かすエコシステム・ツールチェーン・開発者体験の整備がセットで問われる。Metaがこの三つを揃えられるかどうか——そこが本当の勝負だと思っている。 今の段階では「注目はするが、実務採用はもう少し様子を見る」というスタンスが現実的ではないだろうか。 出典: この記事は Meta debuts new AI model, attempting to catch Google, OpenAI after spending billions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windowsのカーネル（OS核心部）には、長年にわたり悪用され続けてきた「抜け穴」が存在していた。2026年4月、Microsoftはついにその穴を塞ぐ重要なセキュリティ変更を展開する。古いドライバー署名方式への信頼を終了し、公式の Windows Hardware Compatibility Program（WHCP）による認定ドライバーのみをデフォルトで許可するというものだ。地味に見えるが、現場への影響は決して小さくない。 問題の背景——「クロス署名プログラム」とは何だったか 2000年代初頭、Microsoftはサードパーティ製ドライバーをWindowsカーネルに組み込む仕組みとして「クロス署名ルートプログラム（Cross-signed Root Program）」を導入した。外部の認証局（CA）がドライバーの署名を行うこの仕組みは長年の標準だったが、致命的な弱点を抱えていた。セキュリティチェックが緩く、署名鍵が盗まれたり悪用されたりするケースが相次いだのだ。 攻撃者はこの仕組みを利用し、正規の署名をまとった悪意あるドライバーをカーネルに読み込ませることができた。カーネルに侵入されれば、セキュリティソフトウェアすら無効化される。EDR（Endpoint Detection and Response）製品をドライバーレベルで無効化する攻撃は、実際にランサムウェアグループが採用してきた手口だ。 Microsoftは2021年にこのプログラム自体を廃止した。しかし廃止後も、既存の古いドライバーはWindowsで引き続き受け入れられていた。今回の変更はその「遺産」に対する最後の決着となる。 新ポリシーの仕組み——「評価モード」から段階的に移行 新しいカーネル信頼ポリシーでは、WHCPを通じてMicrosoftが直接審査・承認したドライバーのみがデフォルトで信頼される。マルウェアチェックや互換性検証を含む審査プロセスを経ることで、サプライチェーン経由でのカーネル汚染リスクが大幅に低下する。 ただし移行は即時ではなく、段階的に行われる。具体的には次のような「評価モード」が設けられている： 評価期間中：カーネルはすべてのドライバー読み込みを監査・記録するが、ブロックはしない 移行条件：累計100時間の稼働かつ3回以上の再起動が完了すること 条件クリア後：旧クロス署名ドライバーが一切検出されなければ、新ポリシーが自動的に有効化される 非互換が検出された場合：評価モードのままリセットされ、移行は先送りされる Microsoftはこの判断に、過去2年間で数十億件のドライバー読み込みから収集したテレメトリデータを活用しているという。現場の実情を踏まえた段階的なアプローチは、現実的で評価できる。 実務への影響——IT管理者が今確認すべきこと この変更がとくに影響するのは、以下のようなシナリオだ： 古い周辺機器・産業機器を使っている環境：特定のプリンターやスキャナー、工場系の制御機器などで古いドライバーが使われている場合、評価モードが延長されるか、最悪の場合デバイスが利用不能になる可能性がある。今のうちにベンダーに問い合わせ、WHCP対応ドライバーへの更新可否を確認しておくべきだ。 エンドポイントセキュリティ製品：EDRやDLP（データ損失防止）製品の一部はカーネルドライバーを利用する。大手ベンダーは対応済みのケースが多いが、バージョンによっては問題が生じることもある。事前に動作確認を行っておきたい。 Intune / Windows Update for Business 管理環境：管理対象のデバイスで評価期間がどのように扱われるか、マイクロソフトの公式ドキュメントを追っておくことを推奨する。特例ポリシーの設定が可能かどうかも確認ポイントだ。 Windows 11 Home と Pro の差異：記事によれば、今回の変更は Windows 11 を対象としている。Windows 10 環境の扱いについては引き続き情報を確認されたい。 筆者の見解 カーネルドライバーのセキュリティ強化という方向性は、間違いなく正しい。特権アクセスを悪用したドライバーベースの攻撃は、EDRをすら無効化できる手口として長く問題視されてきた。「信頼できると証明されたもの以外は許可しない」というゼロトラストの思想をカーネルレベルに持ち込む今回の対応は、セキュリティアーキテクチャとして筋が通っている。 2021年にプログラムを廃止してから約5年、既存ドライバーへの後方互換性を保ちながら段階的に移行するという判断も現実的だ。「今日すぐ全部ブロックする」ではなく、評価モードを通じて互換性の問題を事前に炙り出すアプローチは、現場への影響を最小化しようという配慮が感じられる。 一方で気になるのは、こういった地道なセキュリティ強化がなかなか目立たないことだ。派手な新機能と違い、カーネル信頼ポリシーの変更は語りにくい。しかし実際のセキュリティリスクを下げる観点では、こうした基盤部分の改善こそ本質的な価値がある。Windowsはこのような地道な強化の積み重ねで着実に堅牢になってきた。その事実は、公平に評価されるべきだと思う。 現場の管理者にとっては、「5月に突然デバイスが動かなくなった」という事態を避けることが最優先だ。古いドライバーを使う機器の棚卸しと、ベンダーへの確認を今のうちに済ませておくことを強くすすめる。 出典: この記事は Windows is finally fixing a years-old security hole in April の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Azure AI Foundry（旧称Foundry Classic）で、gpt-realtime-1.5とgpt-audio-1.5が一般提供（GA）に移行した。昨年プレビューとして登場したリアルタイム音声モデルが正式版となり、エンタープライズ用途での利用が現実的な選択肢になってきた。あわせてPreview APIは2026年4月30日に廃止される予定で、既存の実装を持つ開発者は早急な対応が必要だ。 何が新しくなったか 今回GAになったgpt-realtime-1.5とgpt-audio-1.5は、前世代モデルに対して主に3点が強化されている。 インストラクション追従性の向上: プロンプトで指示した挙動を音声応答でも守りやすくなった 多言語サポートの強化: 日本語を含む複数言語での精度・自然さが改善 ツール呼び出し（Function Calling）対応: 音声会話中に外部APIやシステムを呼び出すエージェント的なユースケースが実装しやすくなった これらすべてを維持しながら低レイテンシーも確保しているのがポイントで、「デモでは動くがビジネス要件を満たせない」という従来の課題をかなり解消してきた印象だ。 同時期に強化された音声関連モデル群 GAと合わせて、音声処理パイプライン全体のモデルも大幅に更新されている。 音声認識（ASR）: gpt-4o-mini-transcribe-2025-12-15は英語ベンチマークで前世代比約50%の誤り率削減を達成。無音時のハルシネーション（誤検知）も最大4分の1に削減され、雑音環境での実用性が大きく向上した。日本語・インド系言語などの多言語精度も改善されている点は、日本語ユーザーにとって朗報だ。 話者分離（Diarization）: gpt-4o-transcribe-diarizeは「誰がいつ発言したか」をリアルタイムで識別できる。会議の議事録自動生成やコールセンター通話分析など、日本の企業現場で即座に活用イメージが湧くユースケースだ。 テキスト読み上げ（TTS）: gpt-4o-mini-tts-2025-12-15は多言語合成の新ベンチマークとなっており、より自然でアーティファクトの少ない音声出力を実現している。 SIP接続サポート: Realtime APIが電話システムの標準プロトコルSIPに対応したことで、既存のPBXやコールセンターシステムとの統合が格段にやりやすくなった。 実務への影響——日本のエンジニア・IT管理者に伝えたいこと まず確認: Preview APIの廃止期限 既存環境でRealtime/Audio系のPreview APIを使っている場合、2026年4月30日が移行期限となる。本番で稼働しているシステムがあれば、今すぐ確認・移行計画を立てること。 音声インターフェース開発の現実的な入口として 「音声AIは面白そうだが、まだ実験フェーズ」と思っているなら、GAへの移行はその認識を改めるタイミングだ。特に以下のユースケースは技術的ハードルが現実的な範囲に入ってきた。 社内ヘルプデスクの音声エージェント: FAQへの回答や社内システム検索をFunction Callingと組み合わせて音声で完結させる 会議・商談の自動議事録: 話者分離付き文字起こしで「誰が何を言ったか」まで記録 コールセンターのリアルタイム支援: オペレーターの会話を並行解析してナレッジを即提示 Microsoft Foundryのエコシステム上で構築することで、Entra IDによる認証・認可管理やAzure Monitorでの監視も既存の運用フローに乗せられる。これが単体APIサービスとの最大の違いだ。 API利用の実装ポイント gpt-realtime-1.5は既存のChat Completion APIを通じて利用できる設計になっており、移行コストは比較的低い。既にAzure OpenAI Serviceを使っているプロジェクトなら、エンドポイントの切り替え+モデル名の変更で試せる範囲に入ってきた。 筆者の見解 MicrosoftがAzure AI Foundryを中心にモデル群を整理・強化し続けているのは、単純にモデル単体の競争ではなく「AIが安全に動作するプラットフォームの競争」に軸足を置いているからだと私は見ている。その戦略は長期的には正しいと思う。 音声AIは「楽しいデモ」から「実業務の基盤」へと変わるフェーズにある。Realtime APIがSIPに対応したことは地味に見えるが、これは日本に無数に存在するレガシー電話システムとの接続口が開いたことを意味する。「AIが使えるのは最新システムだけ」ではなく、既存インフラを活かしながら段階的に導入できる設計思想は、日本の大企業・自治体・医療機関のIT部門にとって非常に重要なポイントだ。 一方で、これだけの機能が揃ってきたにもかかわらず、日本の現場での音声AIへの取り組みはまだ周回遅れの印象がある。「うちはまだ早い」と言っているあいだに、競合が顧客接点を音声AIで刷新してしまうリスクは現実のものとして考えておくべきだろう。GAになった今が、実験を業務試行に格上げするちょうどいいタイミングだ。 出典: この記事は GPT Realtime Audio models now generally available in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...