Generative-Ai

Appleが次期OS群（iOS 27/iPadOS 27/macOS 27）において、Siriや文章作成ツール（Writing Tools）、画像生成機能を動かすAIエンジンをユーザー自身が選択できる仕組みを検討しているとBloombergが報じた。OpenAI・Google・Anthropicなどサードパーティのモデルをシステムレベルで統合する「Extensions」機能の詳細はWWDC 2026で発表される見込みだ。 Apple Intelligenceの「モジュール化」とは何か 現在のApple Intelligenceは、プライバシー保護を前提に設計された独自アーキテクチャで動作している。処理の多くはA/Mチップ上のオンデバイスで完結し、クラウドに送る場合もApple独自の「Private Cloud Compute」インフラを経由する。外部AIとの連携はOpenAIとの提携に限定されており、それもユーザーが明示的にオプトインする仕組みだ。 今回報じられた変更の核心は、このアーキテクチャを「プラットフォーム化」する点にある。Apple Intelligenceはプライバシー重視・オンデバイス処理のベースラインとして残しつつ、より高度なタスク——長文ライティング、複雑な推論、創造的な画像生成、会話アシスタント——については、ユーザーが選んだ外部AIエンジンに処理を委ねる設計だ。 設定アプリから任意のAIプロバイダーを選択できるUIが実装される見込みで、Siriの音声応答も設定したプロバイダーに応じてルーティングされる可能性がある。 技術的に何が必要か このアーキテクチャを実現するには、異なるAIモデルがiOSのシステムサービスに接続できる標準化されたインターフェース層が不可欠だ。 共通API: タスク種別（テキスト生成・画像生成・音声認識など）ごとに、どのAIモデルも同じ入出力仕様に準拠できるAPI設計 セキュリティ・プライバシー統制: サードパーティモデルがユーザーの許可なしにデータアクセスできないよう、きめ細かな権限管理機構 フォールバック機構: サードパーティが利用不能な場面でApple Intelligenceに自動フォールバックする仕組み Appleが最も得意とする「セキュリティとプライバシーの作り込み」が、この統合をどこまで安全に実現できるかの鍵を握る。同社はAndroidのオープン性を批判しながらも、ビジネス上の合理性からOpenAIとの提携を選んだ経緯がある。今回はその姿勢をさらに踏み込んだ形で拡張することになり、どのようなプライバシー保護設計を提示するか注目だ。 実務への影響 エンジニア・IT管理者が今から考えておくべきこと MDMポリシーへの備え: 企業では使用できるAIプロバイダーを制限したいケースがある。MDM（Mobile Device Management）ソリューション側でこの設定をコントロールできる仕組みが整備されるかどうか、WWDC後の実装詳細を注視したい。AppleのMDM APIはこれまでも機能制限に幅広く対応してきたが、AIプロバイダーの指定・制限まで対応できるかは未知数だ。 セキュリティポリシーの事前策定: サードパーティAIへのデータ送信ルールを組織として検討しておくことを推奨する。特に機密情報を含む文書作業では、どのモデルに何を送信するかをポリシーとして定義しておく必要がある。「iOS 27になったら困った」ではなく、今から議論を始めるべきタイミングだ。 ワークフローの見直し: 現在「Apple Intelligenceは使い物にならない」と評価して別のアプリに移行しているユーザーは、iOS 27で状況が変わる可能性がある。システムレベルで高性能AIが動くなら、Writing Toolsやメモアプリ内での作業効率が大幅に向上するかもしれない。その前提でワークフローを再設計する価値が出てくる。 筆者の見解 AppleがAIをモジュール化して「選べるプラットフォーム」にしようとしているこの動きは、単なる機能追加ではなく、AI時代におけるOSの役割を再定義するものだと感じている。 「禁止ではなく、安全に使える仕組みを」——これはAI活用における最も重要な原則だと常々思っている。AIを制限・禁止するアプローチは必ず失敗する。ユーザーが公式に提供されたものが一番便利と感じられる状況を作ること、それがプラットフォーム事業者の正しい役割だ。Appleが今回目指しているのはまさにその方向性であり、正しい判断だと思う。 一方で課題もある。AIプロバイダーが乱立する中、「どれを使えばいいかわからない」という新たな混乱を生む可能性もある。Appleがどこまでユーザーの選択を支援するUX——たとえばタスク種別に応じたおすすめの使い分けガイドなど——を整備するかが、この機能が真に使われるかどうかの分岐点になるだろう。 日本のIT現場では、いまだに「AIを試してみたけどいまひとつだった」という声が多い。しかし日常使いのデバイスで最高水準のAIをシームレスに体験できる時代が来れば、その評価は一変する。「AIはこういうものか」という固定観念を壊すきっかけになりうる——これが、この機能が持つ最大の意義かもしれない。 WWDC 2026での正式発表を楽しみに待ちたい。 出典: この記事は Apple could allow users to switch between AI providers like OpenAI, Google, and Anthropic in iOS 27 features の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AI時代の「見えないインフラ競争」が、想像をはるかに超えるスケールで動き始めている。大手AI企業のAnthropicがGoogleクラウドとBroadcom製TPUに対し、5年間で総額2000億ドル（約30兆円）を投じる契約を締結したと報じられた。この金額はGoogleが投資家に開示した収益バックログの40%超を占めるという。モデルの性能競争の裏側で、計算インフラを巡る覇権争いが静かに、しかし圧倒的なスケールで進んでいる。 AIは「インフラ産業」になった 2000億ドルという数字をどう読むか。単なる設備投資ではなく、「次世代AIをどこで動かすか」を確定する戦略的な賭けだ。 Anthropicは今年4月、GoogleとBroadcomの間でテンソル処理ユニット（TPU：Googleが独自開発したAI専用チップ）の大容量確保契約を締結。2027年以降に稼働予定の複数ギガワット規模のキャパシティを手配済みだ。さらに同月、CoreWeaveとも複数年契約を結び、Amazon（AWS）チップによる1ギガワット近い容量も年内に確保する予定という。 より注目すべきは、こうした大型インフラ契約の集中ぶりだ。AnthropicとOpenAIの2社だけで、AWS・Microsoft Azure・Google Cloud Platformという主要クラウド3社の合計バックログ（約2兆ドル）の過半数を占めているという。AIモデルの研究開発だけでなく、それを動かすための計算資源争奪が、現在の競争の主戦場になっている実態を如実に示している。 Google・Alphabetへの影響 この報道を受け、Alphabet（Google親会社）の株価は時間外取引で約2%上昇した。AlphabetはAnthropicへ最大400億ドルを出資しているが、今回の契約によりGoogleクラウドの収益基盤がさらに強固になる形だ。Alphabetは現在、時価総額でNvidiaを抜いて世界最大規模に迫りつつある。AI基盤を握ることの経済的価値の大きさが、この株価推移にも現れている。 実務への影響——日本のIT担当者が今すぐ考えるべきこと 1. 「どのクラウドでAIを動かすか」は戦略的意思決定になった 大手AI企業ですらGPU・TPUのキャパシティ確保のために年単位の先行契約を結んでいる現実は、企業のAI戦略にも直接影響する。今後、特定のクラウドプロバイダーとの関係深化が進む可能性は高い。「とりあえずどこでも同じ」という感覚で選んでいる時代は終わりつつある。 2. GPU一択ではない——TPUという選択肢を知る GoogleのTPUはNvidiaのGPUとは異なるアーキテクチャを持つAI専用チップだ。AnthropicはAWS Trainium・Google TPU・Nvidia GPUと複数のAIハードウェアを使い分けている。「AIチップ＝Nvidia GPU」という固定観念を捨て、ワークロードに応じた最適ハードウェアを選ぶ視点が求められる。クラウド選択＝チップ選択という意識を持てると、コスト構造の理解が一段深まる。 3. AIの「安く使える」幻想を捨てる これほどの規模の投資があって初めて最先端のAIモデルは動く。企業が自前でモデルを持つのか、APIで利用するのかを判断する際、コスト・セキュリティ・性能を含めた総合評価が欠かせない。「AIは安い」という前提のまま戦略を立てると、実際の調達局面で痛い目を見る。 筆者の見解 今回の報道で最も印象的だったのは、Anthropic単体の動向ではなく「AI企業2社でクラウド大手3社のバックログ過半を占める」という構造だ。 AIの競争は、モデルの優劣だけでなく「計算資源をどれだけ早く・大量に確保できるか」という次元でも戦われている。この構図はかつてのデータセンター競争やCDN競争に似ているようで、桁が2〜3つ違う。 日本企業が注意すべきは、このインフラ競争を「海外IT大手の話」として傍観していると、使えるAIサービスの質・コスト・可用性において大きな格差が生まれるリスクだ。AI基盤はすでに「企業競争力の源泉」になっている。 自律的に動くAIエージェントが業務を回す時代は着実に近づいている。その時代のインフラを誰が握り、どこで動かすのか。2000億ドルという数字は、答えがすでに動き出していることを示している。日本のIT部門も、AI基盤戦略を「将来の話」から「今期の意思決定」へと格上げする時機が来ていると感じる。 出典: この記事は Anthropic Commits to Spending $200 Billion on Google’s Cloud and Chips の内容をもとに、筆者の見解を加えて独自に執筆したものです。

日本を拠点とするAIスタートアップ「Sakana AI」が、シリーズBラウンドで1億3500万ドル（約200億円）の資金調達を完了した。大手テック企業がモデルの巨大化・高コスト化を競う中、Sakana AIは「進化的アルゴリズム」と「モデル合成（Model Merging）」という独自の研究路線を貫いており、今回の調達でその商業化フェーズが本格化する。 「スケーリング競争」に乗らない戦略 多くのAI企業が莫大なGPUを積み上げて巨大なモデルを訓練する「スケーリング」路線を走る中、Sakana AIはまったく異なるアプローチをとる。自然界の進化プロセス――突然変異・選択・交叉――をアルゴリズムとして模倣し、複数の既存モデルを組み合わせることで、少ない計算コストで高性能なAIを構築しようという発想だ。 この「モデル合成」手法は、圧倒的な計算資源を持たなくても競争力のあるモデルを作り出せる可能性を秘めている。同社が2023年末の設立以来発表してきた研究論文は、既存の大型モデル同士を「マージ」することで、専門タスクにおいて単体モデルを超える性能を引き出せることを示してきた。 KAMEが示す「エージェントループ」の実装 今回の資金調達において特に注目すべきは、応用研究プロダクト「KAME」の商業展開への本格シフトだ。KAMEは科学的発見の自動化を目指すシステムで、AIが自律的に「仮説立案→実験設計→結果解析」のサイクルを繰り返す。これはまさに、現在のAI開発で最もホットなテーマのひとつである「エージェントループ」の具体的な実装だ。 単発の質問に答えるだけのAIではなく、目的を与えれば自律的に判断・実行・検証を繰り返すエージェントの設計――Sakana AIはこのパラダイムを、基礎研究から実用システムへと橋渡しする立場にある。 実務への影響：日本のエンジニアにとっての意味 研究機関・製薬・素材業界は要注目　KAMEが主にターゲットとする科学的発見の自動化は、製薬、新素材開発、化学分析といった研究集約型産業での応用が期待される。日本には世界有数の製造業・研究機関が集積しており、商業化が進めばパートナー候補になりうる企業は国内に多い。 モデル合成技術はコスト削減の切り札になりうる　自社でLLMを利用・ファインチューニングしている企業にとって、モデル合成アプローチは計算コスト削減の有力な選択肢になる可能性がある。Sakana AIの研究成果の多くはオープンに公開されており、技術動向を追っているエンジニアは論文・GitHubを継続的にチェックしておく価値がある。 国内AI人材・投資の試金石として　日本国内のAI企業がシリーズBでこの規模の資金を集めたこと自体、日本のAIエコシステムにとっての重要なシグナルだ。東京をAI研究・開発拠点として選ぶ国際的な人材・投資の流れが、より本格化する可能性を示している。 筆者の見解 Sakana AIの戦略で筆者が最も評価するのは、「勝てる土俵を自分で決めている」点だ。計算資源でGoogleやMetaに正面から挑んでも勝ち目はない。だからこそ、進化的アルゴリズムとモデル合成という独自のニッチを深掘りし、そこで圧倒的な存在感を示す道を選んだ。この姿勢は、リソースに限界のある組織がAI時代を生き抜くためのひとつの手本になりうる。 KAMEが示すエージェントループの実装も、方向性として正しいと思う。AIの本質的な価値は「人間が都度指示しなくても、目的に向かって自律的に動き続けること」にある。確認・承認を人間に求め続ける設計では、そのポテンシャルの一部しか引き出せない。Sakana AIがこのアーキテクチャを商業レベルで実証できれば、業界全体の設計思想に影響を与えるはずだ。 課題があるとすれば、「研究としての面白さ」と「商業としての再現性・スケーラビリティ」のギャップをどう埋めるかだ。モデル合成は特定条件下では強力だが、汎用性や保守性の面ではまだ未知数の部分が多い。今回の調達で得た資金を研究加速に使うのか、商業展開の実績作りに集中させるのか、バランスの舵取りが問われる局面だと思う。 いずれにしても、日本からこれだけ骨太な研究と資金調達を組み合わせたAI企業が生まれたことは素直に喜ばしい。今後の商業化フェーズに注目していきたい。 出典: この記事は Sakana AI Raises $135M in Series B Funding の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIが「The Deployment Company」と呼ばれるジョイントベンチャー（JV）を100億ドルのバリュエーションで正式に確定させ、TPG、ブルックフィールド・アセット・マネジメント、ベイン・キャピタルなど19社の投資家から合計40億ドルを調達した。そして発表の直後、競合AIメーカーもブラックストーンやゴールドマン・サックスとの同種JVを公表した。この動きは、テクノロジー企業が直接サービスを販売する時代から、「プライベートエクイティ（PE）が巨大なAI配送網を担う」という新たなエコシステムへの移行を示している。 PEファームという「AI展開の新インフラ」 これを単なる大型資金調達ニュースと読むと、本質を見誤る。 TPGやブラックストーンのような大手PEファームは、数百社・数千社のポートフォリオ企業を傘下に抱えている。JVを通じてAI企業と組むということは、そのポートフォリオ全体に対してAIを一括展開する「超高速配送ルート」を得ることを意味する。 従来のSaaSビジネスは営業・プリセールス・カスタマーサクセスを積み上げて1社ずつ顧客を獲得する。これに対してPEとのJVは、ファンドレベルの意思決定により傘下企業数百社が一気に顧客になる。スケールのケタが根本的に違う。 「資本市場とAI」の融合という構造的転換 今回の動きには、AI企業側のもう一つの意図が見える。IPOへの布石だ。 OpenAIはここ数年で大型資金調達を繰り返し、エンタープライズ向けの収益基盤を急速に固めてきた。信頼性の高いPEファームとのJVは、機関投資家への強力なシグナルとして機能する——「私たちはただの研究機関ではなく、実際にビジネスを大規模展開できる会社だ」というメッセージだ。今後のIPOに向けた実績作りという文脈でも、この戦略は一貫している。 実務への影響——日本のIT現場はいつ波が来るか 日本のIT部門が受ける波及 日本の大企業・中堅企業の多くは、外資PEファンドからの投資や買収を受けているか、その傘下にある。今後、ファンドレベルでAI基盤の標準化が進む可能性がある。 具体的に想定されるシナリオ： PE傘下の日本法人が親ファンドの方針でOpenAI系ツールの導入を上から指示される 「ファンド推奨AI基盤」として特定ベンダーが事実上の社内標準になる 調達・採用・財務などバックオフィス機能から段階的にAI化が進む IT部門の担当者は「うちにはまだ関係ない」ではなく、「いつこの波が来るか」の想定を今から始めておくべきだ。 エンジニア・IT管理者へのヒント PE経由の展開は汎用性の高いユースケース（財務分析、契約書レビュー、カスタマーサポート自動化）から始まる可能性が高い。これらの領域で実績を作っておくと、トップダウン導入が来たときに現場の受け皿になれる AI展開の意思決定権がIT部門ではなく経営層・ファンド側に移るケースが増える。提案するなら「経営インパクトを定量化した資料」が必須になる 特定ベンダーへのロックインリスクも念頭に置くこと。JV経由の一括展開は乗り換えコストが高くなりやすい構造だ 筆者の見解 AI技術の普及において、「優れたプロダクトが自然に広がる」というモデルは限界を迎えつつあるのかもしれない。 PEとのJVという手法は、言い換えれば「資本力で展開を買う」戦略だ。AI企業が単独で営業力・展開力を積み上げていくよりも、巨大な資本ネットワークを活用することで飛躍的なスケール拡大が実現できる。技術がどれだけ優れていても使われなければ意味がない。その観点では、これは合理的な一手だと思う。 一方で、懸念もある。PEとのJVでの展開はトップダウンになりがちだ。ファンドが決めた基盤を傘下企業が使う構図では、現場エンジニアがその技術を深く理解し、本当に使いこなすまでには相当な時間がかかる。「形だけ導入して成果が出ない」という事態は十分あり得る。過去のDX推進ブームが残した教訓を繰り返さないためにも、現場のキャパシティ構築に投資することが同じくらい重要だ。 そして逆説的だが、AI展開が資本主導になる時代だからこそ、技術を深く理解して「どう使えば本当に価値が出るか」を説明できる人材の価値はむしろ上がる。ツールが上から配られる時代、それを現場で正しく使いこなす人間は絶対に必要だからだ。 このJVモデルが成功すれば、テクノロジー普及の在り方そのものが変わるかもしれない。その変化から目を離さずにいたい。 出典: この記事は OpenAI Finalizes $10 Billion Joint Venture With PE Firms to Deploy AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIチップメーカーのCerebras Systemsが、2026年最大の技術系IPOに向けて最終段階に入った。28百万株を1株115〜125ドルで売り出し、最大35億ドル（約5,000億円）を調達、時価総額266億ドル（約3.7兆円）を目指す。単なる上場ニュースに見えるが、その背景にあるのはAIインフラの構造的な転換点だ。 Wafer-Scale Engine 3とは何者か Cerebrasの主力製品「Wafer-Scale Engine 3（WSE-3）」は、シリコンウェーハ1枚をそのままチップとして使う独自アーキテクチャを採用している。一般的なGPUがウェーハから多数のチップを切り出すのとは発想が正反対だ。 この設計が推論（inference）——ユーザーのプロンプトを処理してレスポンスを返す処理——に特に優位性を発揮すると同社は主張する。データ移動距離の短縮と消費電力の削減が主な訴求点だ。AI推論の需要が爆発的に増加している現在、NVIDIA主導のGPU市場に一石を投じる存在として注目されている。 OpenAIとの複雑な蜜月関係 IPO目論見書（S-1）を読むと、Cerebrasの成長を支えた最大の柱がOpenAIであることが浮かび上がる。 OpenAIがCerebrasの最大顧客の一つ 2025年12月にOpenAIがCerebrasへ10億ドルを貸し付け（ワラント付き） OpenAIはワラント行使で3,300万株超を取得できる権利を持つ Sam AltmanやGreg Brockmanらがエンジェル投資家として名を連ねる かつてOpenAIはCerebrasの買収も検討したと報じられている。その話は流れたが、代わりに「顧客・債権者・潜在的株主」という複合的な関係が構築された。Elon MuskがOpenAIとの訴訟でこの関係を証拠として引用したほど、シリコンバレー特有の入り組んだ利害構造が可視化されている。 「推論専用チップ」が問いかけるもの 現在のAIインフラはほぼNVIDIAが支配している。しかし、学習（training）と推論（inference）では要求されるハードウェア特性が大きく異なる。学習は規模と帯域を必要とするが、推論はレイテンシと電力効率が勝負になる。 Cerebrasが正面から挑んでいるのはこの推論市場だ。ChatGPT・Copilot・各種AIサービスが日常的に使われるようになった今、推論の処理コストは企業のAI投資対効果に直結する。WSE-3の主張が実証されれば、エンタープライズでの導入障壁が一段下がる可能性がある。 実務への影響 AI調達コストの変化を注視せよ：GPU代替の選択肢が増えることで、クラウドプロバイダーの推論コストが長期的に下がる可能性がある。現在AIサービスを従量課金で使っている企業にとっては中長期で朗報になりうる。 OpenAI依存のリスク構造を把握する：OpenAIがCerebrasへの依存度を高めているとすれば、Cerebras側の問題がOpenAI経由でサービスに波及するリスクもある。AIサービスのベンダーリスクを評価する際、この供給サイドの依存関係も考慮に入れておきたい。 IPOの成否がAI市場全体のセンチメントを変える：SpaceXやその他の大型IPO候補が控えるなか、Cerebrasの上場成功は資金調達環境にも好影響を与える。日本企業がAI関連サービスを選定・契約する際の市場環境にも間接的に影響してくる。 筆者の見解 AIチップ市場の話になると「次のNVIDIAを探す」という文脈になりがちだ。しかし筆者がCerebrasの動向で着目するのはチップそのものより、その背景にある「推論需要の爆発」という構造的変化だ。 モデルを作るフェーズから、モデルを24時間回し続けるフェーズへ——この転換が今まさに進行している。AIが自律的にループを回し、人間の確認なしにタスクを実行する設計が広がるにつれて、推論の速度と電力効率は直接コストに跳ね返る。企業がAIに支払う費用の重心が推論コストへと移るのは時間の問題だ。 その意味で、GPU一強体制に疑問を呈する実力ある競合が現れ、大型IPOを狙えるほどの市場評価を得ていること自体は健全だと思う。競争が生まれれば価格は下がり、より多くの企業がAIを実用的なコストで活用できるようになる。 OpenAIとの複合的な利害関係については、IPO後のガバナンスがどう整理されるかを注視したい。顧客・投資家・債権者が重複する構造は、一方に問題が生じたときのリスク集中という懸念を内包している。透明性の高い運営が期待される。 AI推論インフラの競争が本格化することを、一AIの利用者として素直に歓迎する。 出典: この記事は OpenAI’s cozy partner Cerebras is on track for a blockbuster IPO の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界最大級の会計・コンサルティングファームであるPwCが、OpenAIとの戦略的パートナーシップを発表した。財務・経理部門（CFOオフィス）を対象に、AIエージェントを活用した業務自動化を企業に提供するというものだ。単なる「AIアシスタント導入」ではなく、予測・分析・内部統制・ワークフロー全体をAIエージェントが自律的に担う構想であり、CFO機能そのものの再定義を目指している。 CFOオフィスとは何か、なぜ今AIなのか CFOオフィスとは、最高財務責任者（CFO）を中心に、財務計画・予算管理・財務報告・リスク管理・内部統制を担う組織機能の総称だ。従来、これらの業務は膨大なデータ処理と人的判断が必要とされ、ERPシステムやBI（ビジネスインテリジェンス）ツールが補助してきたが、データの統合・解釈・意思決定まで人間が担うことが前提だった。 今回の提携でOpenAIとPwCが目指すのは、このプロセスをAIエージェントが自律的に動かすことだ。財務予測（Forecasting）、内部統制の強化（Strengthened Controls）、ワークフローの自動化が主なターゲットとなる。 技術的ポイント：「補佐型」から「自律型」エージェントへ ここで注目すべきは、このパートナーシップが単なる「AIが提案→人間が確認」というモデルを超えている点だ。複数の専門エージェントが連携し、市場データの収集・予測モデルの実行・異常の検知・レポート生成をループで自律的に処理し、最終判断だけをCFOに渡す——そういった設計が想定されている。 PwCが持つ財務・会計分野の深い知見と規制対応ノウハウが、OpenAIの技術と組み合わさることで、企業が安心して導入できる形になる点も重要だ。ガバナンスや監査対応の観点から、大手ファームが「お墨付き」を与える意味は大きい。 実務への影響：日本のCFO・経理部門が考えるべきこと 日本の大手企業でも、この動向は無視できない。 短期的に確認すべきこと： 現在使っているERP（SAP、Oracle、Microsoft Dynamics等）とAIエージェントの接続性を評価する 財務データのデジタル化・標準化がどこまで進んでいるかを棚卸しする（AIは整備されたデータがなければ機能しない） 自社での完全内製より、専門パートナーとの協業を選択肢に入れる 中期的に変わること： 月次・四半期の財務クローズ作業の大幅短縮が現実的になる 管理会計・予実管理のサイクルが高速化し、意思決定の速度そのものが変わる 財務部門の役割が「データ処理」から「AIエージェントの監督・戦略的判断」にシフトする 直接的な影響は大企業から始まるが、大企業の財務プロセスが変われば、取引先・サプライチェーン全体にも数年以内に波及する。 筆者の見解 財務業務は、AIエージェントが最も高い価値を発揮できる領域の一つだと思っている。ルールが明確で、データが構造化されており、繰り返しのプロセスが多い。そして何より、間違いのコストが極めて高い——だからこそ、単に「提案して確認を求める」だけではなく、自律的にループを回せるエージェントの設計が問われる。 重要なのは、今回のパートナーシップが目指すのは「何かを出力してから人間が判断する」モデルではなく、データを取得して→分析して→異常を検知して→対策案を生成して→担当者に最終判断だけを委ねる、というフローを丸ごと自動化することだという点だ。この違いは小さいようで本質的に大きい。 日本のIT・財務部門は、「AIを導入する」という議論を超えて、「どの業務フローをエージェントが自律的に担えるか」を具体的に設計する段階に入るべき時期に来ている。PwCがこの分野に本腰を入れたことは、AIエージェント活用が実証フェーズから本格実装フェーズへ移行したことを示す明確なシグナルだ。 テクノロジーの変化は常に「一部の先進企業から始まり、2〜3年で業界標準になる」パターンをたどる。CFOオフィスのAI化も、その例外ではないだろう。 出典: この記事は OpenAI and PwC collaborate to reimagine the office of the CFO の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIをめぐる最前線は、いよいよ教室へと移り始めた。米国の民主・共和両党が共同で「LIFT AI法」を提出し、OpenAI、Google、Microsoftという三大AI開発企業が揃って支持を表明した。法案が成立すれば、K-12（幼稚園〜高校）全課程にAIリテラシー教育が組み込まれ、米国の次世代は「AIとともに生きる作法」を学校で体系的に学ぶことになる。 LIFT AI法とは何か LIFT AIとは「Literacy in Future Technologies Artificial Intelligence Act」の略。カリフォルニア州選出の民主党上院議員アダム・シフが超党派で提出した法案だ。 核心はNSF（国立科学財団）へのグラント権限付与にある。大学や非営利団体が「AIリテラシーカリキュラムの研究・開発」「教材作成」「教師向け研修」「評価手法の確立」を申請し、競争的資金を獲得できる仕組みを整備する。 法案が定義する「AIリテラシー」は以下の4軸で構成される： 年齢に合ったかたちでAIを実際に使いこなす能力 AI出力を批判的に解釈する能力 AI時代における問題解決能力 リスクを適切に軽減する能力 単なる「AIを知っている」状態ではなく、「AIと共存して仕事・学びを前進させる実践力」を育てるという方向性が明確だ。 現場には根強い抵抗感がある ここで注目したいのが、元記事の一文だ。「学生も教師もすでにAIの学校導入を嫌っている」——現場の温度差は米国でも深刻なようだ。 この感覚は日本でも無縁ではない。「AIに作文を書かせるな」「思考力が育たない」「著作権はどうなるのか」——こうした声は日本の教育現場でも頻繁に聞こえてくる。大企業がトップダウンで「AIを学べ」と言っても、現場が納得しなければ形骸化する。リテラシー教育の成否は、カリキュラムの質と教師側への十分なサポートにかかっている。 実務への影響 採用基準が変わる予兆 LIFT AI法が実現すれば、2030年代には「AI前提世代」が就職市場に参入してくる。プロンプト設計やAI出力の検証が「当たり前のスキル」として語られる時代が到来する。日本企業の人事・採用部門も、今から対応を考え始めるべきタイミングだ。 社内AIリテラシー研修の設計ヒント LIFT AI法のフレームワーク（使う・解釈する・問題解決・リスク軽減）は、社内研修の設計にそのまま応用できる。「とりあえずAIを触らせる」ではなく、4つの軸に沿ったカリキュラム設計が有効だ。特に「批判的に解釈する」軸は、多くの社内研修で抜け落ちがちな要素でもある。 禁止より整備を 「学校でAIを禁止すべきか」という議論は日本でも起きているが、LIFT AI法の方向性は真逆だ。禁止アプローチは回避行動を生むだけで本質的な解決にはならない。公式に提供されたものが最も便利と感じられる状況を整備することが、正しいアプローチだ。 筆者の見解 AIリテラシーを義務教育に組み込もうという方向性は、基本的に正しいと思う。問題はその中身と設計者だ。 気になるのは、この法案を支持しているのが「AI製品を売る側」の大企業であること。もちろん彼らのリソースと知見は不可欠だが、「自社製品を教育現場に定着させる」という商業的動機が混入しないかは注視が必要だ。良質な教育とビジネス利益が一致していれば問題はないが、カリキュラムの設計者が誰かは常に意識しておきたい。 もう一点、法案が示す4軸の定義は実に的確だと感じる。特に「批判的に解釈する」という軸が含まれているのは重要で、ここが抜け落ちると単なる「AIを使わせる教育」に成り下がる。AIが出した答えを疑い、検証し、修正できる人間を育てることこそが本来の目的のはずだ。 日本でも「AIは怖い・使うな」から「AIと正しく付き合う」へのパラダイムシフトが求められている。ただし、そのシフトを成功させるには「禁止」でも「野放し」でもない、体系的な整備が必要だ。米国の法案がその一つのモデルケースとして成熟していくことを、期待を持って見守りたい。 出典: この記事は OpenAI, Google, and Microsoft Back Bill to Fund ‘AI Literacy’ in Schools の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが提供するブラウザ・Chromeが、ユーザーの許可なく約4GBのAIモデルをデバイスにサイレントインストールしていたことが明らかになった。インストールされるのはGemini Nanoの重みファイルだ。プライバシー研究者によるGDPR違反の指摘、そしてCO2換算で最大6万トンにのぼるとされる環境負荷の試算は、AI機能のブラウザ統合が急速に進む今、業界全体が向き合うべき問題を突きつけている。 ユーザーの知らない場所で起きていること Chromeがインストールされたマシンのユーザープロファイルに、OptGuideOnDeviceModel というディレクトリが作成され、その中に weights.bin という約4GBのファイルが存在する。正体はGemini Nanoの重みファイルだ。「Help me write（文章作成AI補助）」やオンデバイス詐欺検出など、Chromeが推し進めるAI機能のバックエンドとして使われる。 問題の核心は 「同意が存在しない」 という一点だ。 インストール時も使用中も同意ダイアログは表示されない Chrome設定画面にダウンロードを制御するチェックボックスはない ユーザーが手動でファイルを削除しても、Chromeの起動のたびに再ダウンロードされる これはブラウザの通常のアップデートとは性質が異なる。4GBのAIモデルをユーザーのローカルストレージに書き込むという行為は、明らかにその範疇を超えている。 法的リスク：GDPR・ePrivacy指令への抵触 プライバシー専門家Alexander Hanff氏の分析によると、この行為は欧州の複数の規制に抵触する可能性がある。 ePrivacy指令 第5条(3) ユーザーの同意なしにデバイスへ情報を保存・アクセスすることを禁じる。CookieやトラッキングPixelと同じ法的枠組みが適用される。 GDPR 第5条(1) データ処理における適法性・公正性・透明性の原則。ユーザーが知らない場所で行われる処理は透明性原則に反する。 GDPR 第25条 データ保護バイデザインの義務。設計段階からプライバシー保護を組み込む義務があり、事後的な「設定で無効化できます」では不十分とされる。 CSRD（企業サステナビリティ報告指令） 環境負荷の開示義務。後述する環境コストが報告対象となりうる。 日本においても個人情報保護法の観点から注視が必要だ。特に企業のマネージドデバイス管理においては、予期しない大容量ファイルの書き込みはセキュリティポリシーとの整合性問題を生む。 見落とされがちな環境コスト この問題で特に注目したいのが 環境への影響 だ。 Chromeは全世界で20億台を超えるデバイスで使われている。仮に数億台にこの4GBファイルが配信されたとすると、ネットワーク転送と端末処理に要するエネルギーをCO2換算すると 6,000〜60,000トン相当 にのぼると試算されている。 一企業が「ユーザーに聞かずに決めた」配信が、これほどのスケールで環境に影響を及ぼすという事実は重い。ESGが企業評価に直結する時代において、この種の「無断バルク配布」はガバナンス上の問題としても認識されるべきだろう。 実務での対応ポイント ファイルの存在を確認する Windows: %LOCALAPPDATA%\Google\Chrome\User Data\ 以下 macOS: ~/Library/Application Support/Google/Chrome/ 以下 上記パスに OptGuideOnDeviceModel/weights.bin（約4GB）があればインストール済みだ。 企業環境での制御 Chrome管理ポリシーで GenAILocalFoundationalModelSettings を設定することで、オンデバイスAIモデルのダウンロードを無効化または制御できる。Google Admin Console・グループポリシー（GPO）・MDMのいずれでも適用可能だ。大規模展開前にまずパイロット端末で動作を確認することを推奨する。 EDR・DLPアラートへの対応 マネージドデバイスに突然4GBのファイルが生成されるため、EDRやDLPが誤検知するケースがある。除外ルールの見直し、あるいはポリシー配布前に「これは正規ファイルか」を確認するフローを整備しておくとよい。 筆者の見解 今回Chromeがやったことは、「サービス改善のために」という大義名分のもとに行われる一方的なリソース消費の典型例だ。 筆者が特に問題だと感じるのは、削除しても再インストールされるという設計思想だ。これはユーザーの意思決定を無効化するメカニズムであり、「ユーザーが主体的にコントロールできる体験」とは真逆のアプローチと言わざるを得ない。 テクノロジーの進化においては「禁止より安全に使える仕組みを」という考え方が正しいと思っているし、AIのブラウザ統合そのものを否定するつもりはない。オンデバイスで動くAIにはプライバシー保護やレイテンシの面で明確な利点がある。 しかし、利点があるからといって、ユーザーの同意なしに4GBのリソースを消費してよいわけではない。それは技術的なメリット・デメリットの問題ではなく、ユーザーへの敬意の問題だ。「より良いブラウザ体験」を本気で目指す技術力があるなら、透明性のある同意フローを設計する力もあるはずで、今の実装はその力を活かしていないという意味でもったいない。 今後、各国の規制当局がどう判断するかが注目点だ。GDPRの観点での行政指導・制裁が実現すれば、ブラウザベンダー全体がオンデバイスAI機能の配布ポリシーを見直す契機になるだろう。日本のIT管理者も対岸の火事と見ずに、今のうちから自社ポリシーの点検を始めておくことを強く勧める。 出典: この記事は Google Chrome silently installs a 4 GB AI model on your device without consent の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIがゼロデイ脆弱性を「見つけて、実証する」まで人間の介入なしに完結する——その能力がついに実験室の外で具体的な成果として示された。Anthropicが技術レポートを公開し、新モデル「Claude Mythos Preview」が主要OS・ブラウザを横断して数千件の高・致命的脆弱性を自律発見し、複数で動作する悪用コード（PoC）を生成したことが明らかになった。セキュリティ業界に長年あった「脆弱性の発見と実証の間のギャップ」が、AIによって急速に縮まっている。 何がここまで衝撃的なのか 先代モデルとの差は「量的な改善」ではなく「質的な跳躍」に近い。内部ベンチマークでは、Firefoxの脆弱性に対して先代モデルが数百回試行中2回しか有効なエクスプロイトを生成できなかったのに対し、Mythos Previewは181回成功している。約90倍の差だ。 発見された脆弱性の内訳が、さらに驚きをもたらす： OpenBSD（27年前の欠陥）: TCPのSACK実装に潜むDoS脆弱性。リモートからOpenBSDホストをクラッシュさせることができる。約1,000回のスキャン実行・コスト$20,000未満で発見。 FFmpeg（16年前の欠陥）: 2003年に混入し、2010年のリファクタリングで顕在化した整数オーバーフロー。以降のすべてのファザーと人間レビュアーが見逃してきた。 FreeBSD（17年前のRCE）: NFSサーバーに潜む認証不要のroot権限奪取脆弱性（CVE-2026-4747）。初期プロンプト後、一切の人間介入なしに発見・実証を完了。 外部の専門セキュリティコントラクターが198件を手動レビューした結果、89%でモデルの深刻度評価と一致し、98%は1段階以内の差に収まった。人間の専門家に迫る精度だ。 「意図せず生まれた」能力が示す構造的問題 Anthropicの研究者はレポートに重要な一文を記している。「これらの能力はMythos Previewに特化してトレーニングしたわけではない。コーディング・推論・自律性の汎用的な改善の副産物として自然発生した」。 ここが本質だ。脆弱性を修正する能力が高まるほど、脆弱性を発見・悪用する能力も同時に高まる。攻撃と防御の両方の能力を同一モデルが担う構造は、AIセキュリティツールの倫理的・実務的な枠組みを根底から問い直す。 この認識のもと、Anthropicは同研究を「Project Glasswing」と命名し、クリティカルな産業パートナーとオープンソース開発者への限定公開にとどめている。AWS・Apple・Googleなどと連携し、発見済み脆弱性の修正を先行して推進中だ。 実務への影響 「古いコードは安全」という前提を捨てよ これまで「長く実績のあるコードベースは安全」という経験則が現場で通用する場面があった。今回の発見は、10年・20年単位で見逃されてきた欠陥がAIによって系統的に掘り出せることを示した。レガシーシステムを多く抱える日本のエンタープライズは、この前提を今すぐ見直すべきだ。 攻撃の「民主化」リスクを直視する PoC生成の自動化は、高度なスキルを持たない攻撃者でも深刻な脆弱性を実際に悪用できるハードルを下げる。SOCやCSIRTの検知・対応速度を上げる投資が急務になっている。パッチ適用サイクルの短縮と、攻撃インテリジェンスの取得強化を並行して進めたい。 防御側へのチャンスでもある 同じ能力を責任ある形で活用すれば、内部の脆弱性スキャンのコストと精度を大幅に改善できる。OSS依存ライブラリの系統的なリスク評価、Bug Bountyプログラムの補完、レッドチーム演習の効率化——セキュリティチームが「AIを攻撃シミュレーターとして使う」未来は、すでに現実の入口に立っている。 筆者の見解 AIエージェントが「指示待ちの副操縦士」から「目的を与えれば自律遂行する実行者」へと進化する流れは以前から見えていたが、セキュリティドメインでここまで具体的に実証されたことは大きな節目だ。プロンプト1つで17年間人間が見逃した脆弱性を発見し、実証コードまで完成させる——これはもはや「研究の話」ではない。 注目したいのは、責任ある公開（Project Glasswing）という判断だ。能力があるからといって即座に広く展開するのではなく、影響範囲を見極めて段階的に進める姿勢は、技術の成熟度と組織の誠実さを示す。こうしたアプローチが業界標準になっていくことを期待したい。 そして日本のIT組織に問いかけたい。「古いシステムだから実績がある」「専門家が見てきたから大丈夫」という安心感を今日もまだ持っているなら、それは再検討の余地がある。脆弱性の探索コストが劇的に下がった世界では、攻撃者もAIを活用する。防御側が活用しない理由はない。AIをセキュリティプロセスに組み込む議論を、今すぐ社内で始めてほしい。 出典: この記事は Anthropic’s new AI model finds and exploits zero-days across every major OS and browser の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleのGemini APIに、長時間実行ジョブ向けのWebhook機能が追加された。Deep Research、長尺動画生成、大規模バッチ処理といった分〜時間単位で走るAIジョブの完了通知を、ポーリング不要でリアルタイムに受け取れるようになる。これは単なるAPIの利便性向上にとどまらず、エージェント型アプリケーションのアーキテクチャ設計に直接影響する重要なアップデートだ。 ポーリングの何が問題だったのか 従来、Gemini APIで長時間ジョブを扱う場合、開発者は定期的にGETリクエストを送り続けて完了状態を確認するポーリング方式を使うしかなかった。これには明確なコストがある。 サーバー負荷と無駄なネットワーク通信: ジョブが終わっていないのにAPIを叩き続ける レイテンシ: ポーリング間隔によっては、完了からの通知までタイムラグが生まれる コードの複雑さ: 状態管理、タイムアウト処理、バックオフロジックなどを自前で実装する必要がある Webhook方式で何が変わるか Webhookを使えば、AIサービス側がジョブ完了の瞬間にHTTP POSTリクエストを開発者のエンドポイントに送りつけてくる。いわゆる「プッシュ型」の通知だ。 セキュリティ設計もきちんとしており、Standard Webhooks仕様に準拠。webhook-signature、webhook-id、webhook-timestamp の3ヘッダーで署名検証が行われ、リプレイアタック対策と冪等性が担保される。配信保証は「at-least-once（少なくとも1回）」で、最大24時間の自動リトライが行われる。 設定方法は2種類ある。 プロジェクトレベル: HMACで保護されたグローバル設定。すべてのジョブに同じエンドポイントを使う場合に適している リクエストレベル: JWKSで保護された動的設定。ジョブごとに異なるエンドポイントに振り分けたい場合に使う 実務への影響 この変更が最も効くのは、バッチAPIを使って大量のプロンプトを一括処理するケースだ。数千件のプロンプト処理、長尺動画の生成、Deep Research機能など、分〜時間単位で走るジョブに対してポーリングを書かずに済む。 Azureを使っているシステムを設計している読者にとっては、Azure Event GridやService BusのWebhookサブスクリプションと同じ発想だと理解すると馴染みやすい。Azure Functionsをトリガーとして受け口に使えば、外部AIサービスのWebhookとAzureのサーバーレス処理を組み合わせたパイプラインも比較的容易に構築できる。 実装の際に押さえておきたいポイント： 署名検証を必ず実装する: webhook-signatureヘッダーの検証をサボると、なりすましリクエストを処理するリスクがある 冪等な処理を設計する: at-least-once保証なので、同じWebhookが複数回届く可能性がある。webhook-idを使って重複排除のロジックを入れること エンドポイントの応答を素早く返す: Webhook受信後の処理は非同期にし、まず200を即返す設計にする。重い処理を同期で実行すると再送ループに巻き込まれる 筆者の見解 今回のWebhook対応は、技術的には特別目新しいものではない。イベント駆動アーキテクチャは長年Webエンジニアが使い続けてきた標準的なパターンだ。しかし、AIサービスがこのパターンを正式サポートし始めたという点に意味がある。 エージェント型AIアプリケーションが普及するにつれ、「リクエスト→即レスポンス」という同期モデルの限界はどのプラットフォームでも顕在化してくる。複数のAIジョブをオーケストレーションし、その結果に応じて次のアクションを決める——そういう自律的なワークフローを作ろうとすると、ポーリング前提の設計はすぐに破綻する。 この動きは、AIサービスが「呼べば答えるツール」から「自律的に動くエージェントのインフラ」へと移行していることの表れだと読んでいる。「副操縦士」的な確認待ちの設計ではなく、完了を検知してそのまま次のステップを自律実行する——そのためのインフラとして、Webhookは本質的に正しい方向性だ。 開発者として今確認しておくべきは、使っているAIサービスがイベント駆動をどこまでサポートしているかだ。どのサービスを使っていても、自律エージェントの設計でポーリング依存のアーキテクチャは早晩置き換えが必要になる。その設計転換を今のうちに意識しておくことが、エージェント時代に向けた準備になる。 出典: この記事は Reduce friction and latency for long-running jobs with Webhooks in Gemini API の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIとの対話が「テキスト入力」から「会話」へと移行しつつある今、OpenAIが公開した大規模低遅延ボイスAI配信の技術解説は注目に値する。単なる機能紹介にとどまらず、インフラ設計の観点から音声AIの「難しさ」を正直に語っている点が興味深い。 ボイスAIにおける遅延の本質的な課題 テキストベースのAIと音声AIでは、「遅延」に対する人間の感覚が根本的に異なる。テキストなら数秒待てるが、会話では200〜300ms以上の遅延で「不自然さ」を感じ始め、500msを超えると会話のリズムが完全に壊れる。 音声AIのパイプラインは通常、以下の3段階で構成される： 音声認識（STT: Speech-to-Text） — ユーザーの発話をテキスト化 LLM推論 — テキストを解析して応答を生成 音声合成（TTS: Text-to-Speech） — 応答テキストを音声に変換 これらを逐次処理すると各ステップの遅延が積み重なる。大規模サービスではそこに「通信遅延」と「負荷分散」の課題も加わってくる。 OpenAIが実装した低遅延アーキテクチャ OpenAIのRealtime APIは、WebSocketによる双方向ストリーミングを軸に設計されている。ポイントは「すべての処理が終わってから返す」のではなく、各ステージの処理を並列・ストリーミングで進める点だ。 ストリーミング処理: LLMが応答テキストを少しずつ生成しながら、TTS側が並行して音声化を開始する。ユーザーは完全な応答を待つ必要がない VAD（Voice Activity Detection）: ユーザーが話し終えたタイミングをリアルタイムで検出し、エンドポイント検出の精度を高める 割り込み処理（Interruption Handling）: AIが話している最中にユーザーが割り込んだ場合、自然に応答を止めて再開できる仕組み 地理分散インフラ: 推論サーバーを地理的に分散配置し、ユーザーとの物理的な距離から生じるネットワーク遅延を最小化 スケールの面では、同時接続数の急増に対するオートスケーリングと、GPU資源の効率的な割り当てが技術的な核心となっている。 日本のIT現場への影響 日本企業にとって、ボイスAIの実用化は思っている以上に近い未来の話だ。コールセンター自動化、音声入力による業務効率化、多言語対応サポートなど、ユースケースは明確に存在する。 IT管理者・インフラエンジニアへの実務ポイント： Realtime APIの評価を今すぐ始める: すでに一般公開されており、WebSocket経由での音声対話機能をすぐに試せる。まず小規模なPoCから始めることを推奨する 遅延計測の仕組みを用意する: エンドツーエンドの遅延を計測する仕組みなしに音声AIのUXは語れない。P95レイテンシを継続追跡することが品質基準になる WebRTC vs WebSocket の選択: ブラウザクライアントからの音声入力にはWebRTCが有利だが、サーバーサイドとの連携設計が複雑になる。ユースケースに応じた選択が必要だ 倫理・コンプライアンスを設計段階から: 通話録音の同意取得、個人情報の扱いなど、日本の法規制への適合も最初から組み込む必要がある 筆者の見解 音声AIの低遅延配信技術に関するこの種の詳細な技術解説は、業界全体にとって意義深い。私が特に注目しているのは、ボイスAIがAIエージェントの「ループ」にどう組み込まれるかという点だ。 単なる質問応答ではなく、音声コマンドを受けたエージェントが自律的に複数のタスクを実行し、結果を音声でフィードバックするという構成——そこに実用的な価値がある。遅延の最小化は、その実現可能性を高める基盤技術であり、200ms以下の応答があって初めて音声AIは本当に「使える」インタフェースになる。 情報を追いかけることよりも、実際に動かしてみることを勧めたい。Realtime APIは今すぐ試せる環境が整っている。1時間のPoCで、テキストAIとは質的に異なる体験が得られるはずだ。それが実感できれば、自分のプロダクトやサービスへの応用アイデアは自然と湧いてくる。「音声で話しかけたら、AIが自律的に動いて結果を返す」——その体験設計を、今から考え始めるべき時期に来ている。 出典: この記事は How OpenAI delivers low-latency voice AI at scale の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年初頭、中国AI各社が相次いで大型オープンウェイトモデルを公開した。AlibabaのQwen3.5シリーズ（最大397Bパラメータ）、ZhipuのGLM-5（744B）、MiniMaxのM2.5、StepFunのStep-3.5-Flashと、一ヶ月足らずの間に複数の最前線モデルが登場した。「オープンウェイト界隈はもう中国勢が主役」という声が現実味を帯びてきた。 Qwen3.5──幅広い用途に使えるラインナップ Alibabaが公開したQwen3.5は、0.8Bから27B（密結合）と35B-A3Bから397B-A17B（MoE）まで揃う大型ラインナップだ。全モデルがマルチモーダル対応で、デフォルトで推論（リーズニング）機能を有効化している。 前バージョンから顕著に改善された点は以下の通り： 指示追従性の向上：より自然で意図に沿った応答が得られる 多言語性能の向上：日本語を含む多言語タスクでの精度改善 Qwen-Nextアーキテクチャ：GDN（Gated Dynamic Normalization）レイヤーを採用 一方で注意点もある。特に小規模モデルは「考えすぎ（overthinking）」傾向が残る。チャットテンプレートでリーズニングをオフにすることで抑制できるため、用途に応じた設定調整が必要だ。 GLM-5──需要急増で価格改定という異例の事態 ZhipuのGLM-5は744B-A40BのMoEモデルで、公開直後にコーディングプランの料金が値上がりする事態になった。需要が供給を上回った結果であり、実際に使われているモデルだという証明でもある。技術レポートも同時公開されており、アーキテクチャの詳細を確認できる。 MiniMax M2.5──小さくても侮れない MiniMax M2.5は相対的に小さなモデルながら、GLM-5やKimi K2.5と競合できる性能を示している。コミュニティでの評価も高く、コスト効率を重視するユースケースで有力な選択肢となっている。 RAM指標が示す「話題性と採用率の乖離」 今号から導入された「Relative Adoption Metrics（RAM）」は、同クラスのモデル間でダウンロード数を正規化する指標だ。興味深いことにDeepSeek V3.2が過去のリリースと比べて大幅に低いスコアを記録している。話題性と実際の採用率は必ずしも一致しない、という現実を数字が示している。 実務への影響 オープンウェイトモデルの実務活用において、判断軸は主に3点だ。 ①コスト構造の変化 大規模MoEモデルはAPIコストではなくインフラコストで勝負する。自社で運用できるエンジニアリング力があるか、クラウドのマネージドサービスで回すか。この選択が実コストを左右する。 ②用途に合ったモデルを自分で確かめる RAMスコアが示す通り、話題のモデルが自分のユースケースに合うとは限らない。手元で動かして確かめるプロセスを省略しないことが重要だ。 ③日本語性能の個別検証 Qwen3.5は多言語対応の強化を明示しているが、日本語での品質は用途ごとに検証が必要だ。専門用語や敬語・丁寧語の扱いは特に要確認ポイントとなる。 筆者の見解 中国AI勢のオープンウェイト攻勢は、もはや「キャッチアップ」ではなく「フロンティアそのもの」になりつつある。多様なモデルが使えるほどエンジニアの選択肢は広がり、競争が健全に機能しているという意味で歓迎すべき状況だ。 ただ、情報を追いかけることと実際に成果を出すことは全くの別物だ。毎月のように大型リリースが続く今、「最新モデルに乗り換え続ける」よりも「手元のワークフローで実際に動かして成果を出す」ことに集中するほうが、長期的には大きなリターンをもたらすと筆者は考えている。 今号で特筆したいのがOpenThinker-Agent-v1の登場だ。SFTとRLデータを公開し、ターミナルベースのエージェントタスクに本格的に取り組んでいる。単発の質問・回答ではなく、エージェントが自律的にループで判断・実行・検証を繰り返す設計。これこそが次のフロンティアの核心であり、モデルサイズ競争よりも一段注目に値すると思っている。 日本のIT現場では、オープンウェイトモデルの自社運用に本格着手できている組織はまだ少ない。しかし規制業種でのデータ主権要件やクラウドコスト削減の観点から、この選択肢は着実に現実味を増している。最前線の動向を横目で追いながら、「自社に適用できる形」を今から模索し始めるタイミングが来ている。 出典: この記事は Latest open artifacts (#19): Qwen 3.5, GLM 5, MiniMax 2.5 — Chinese labs’ latest push of the frontier の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MandiantのM-Trends 2026レポートが示した数字は、セキュリティ担当者にとって穏やかではない。CVE（共通脆弱性識別子）が公式に開示されてから**24時間以内に実際の攻撃に悪用されたケースが28.3%**に達した。そしてさらに深刻な事例として、パッチのリリースよりも前にエクスプロイトが出回る「タイム・トゥ・エクスプロイト（TTE）がマイナスに転じる」現象まで確認されている。攻撃の速度を根本から変えているのが、AIによる自動化だ。 脅威のスピードが「人間の対応限界」を超えた M-Trends 2026はMandiantがインシデント対応の最前線から毎年まとめる業界屈指の調査報告だ。今年の中心メッセージは一言で言えばこうだ。「攻撃の速度が、人間の対応速度を構造的に上回った」。 28.3%という数字が意味するのは、新しい脆弱性が公開された翌日には、すでに3件に1件近い割合で実際の攻撃が始まっているということだ。 パッチより先にエクスプロイトが届く「マイナスTTE」の衝撃 TTEがマイナスになるとは何か。脆弱性の公開や修正パッチのリリースより前に、エクスプロイトコードが実戦投入されていることを意味する。 かつてこれは「ゼロデイ攻撃」と呼ばれ、国家支援型のAPTグループや一部の高度な攻撃者だけに許された技術的領域だった。しかし今、AIが脆弱性の解析・エクスプロイトコードの生成・攻撃手法の最適化を支援することで、より低い技術コストでこれを実現できる環境が整いつつある。 AIは攻撃の「量産体制」を整えた AI支援型攻撃の本質は「天才ハッカーがさらに賢くなった」ではない。「そこそこの技術力の攻撃者が、大量かつ高速に動けるようになった」という攻撃能力の民主化だ。 脆弱性スキャン、エクスプロイトコードの生成、標的環境への適応、セキュリティ製品の回避——これらすべてがAIによって加速・自動化されつつある。攻撃側が「自律的に判断→実行→検証を繰り返すループ」を事実上獲得しつつある中、防御側が従来の「人間が検知して手動で対応する」モデルのままでは、スピードの非対称性は広がる一方だ。 日本のIT現場への直接的な影響 日本企業のパッチ管理は構造的に遅い。月次の変更管理サイクル、ベンダーへの動作確認依頼、社内承認フロー——どれも必要なプロセスだが、「24時間以内に悪用が始まる脆弱性が3割を超える」という現実とは完全に乖離している。 今すぐ取り組める実務ポイントを整理する。 パッチ優先度の再設計 — CVSSスコアだけでなく「エクスプロイトが実際に流通しているか」を判断基準に加える。EPSS（Exploit Prediction Scoring System）の活用が現実的な選択肢だ ネットワークセグメンテーションの強化 — パッチ適用までの「露出窓（Window of Exposure）」を最小化するためのアクセス制御を見直す EDR/XDRの振る舞い検知への移行 — 既知シグネチャへの依存から脱却し、異常な振る舞いそのものを捉える仕組みに切り替える クラウドの自動パッチ機能を積極活用 — Azure Update ManagementやDefender for Cloudの脆弱性管理を使い、手動対応の工数を削減する 筆者の見解 AIが攻撃を加速しているまさに同じロジックで、防御側にもAIを使う責務が生まれている。「AIによる攻撃に人間が手動で対応する」という構図は、もはや成立しない。 これは日本のIT業界にとって「セキュリティ人材が足りない」という人材問題ではなく、「仕組みが根本的に変わった」という構造問題だ。人を増やして解決しようとするアプローチでは方向が違う。自動検知・自動対応・自動修復のパイプラインを、今すぐ設計し始めることが正しい一手だ。 Microsoftのセキュリティ製品群（Defender XDR、Microsoft Sentinel、Security Copilot）はこの方向に向かって着実に整備されており、その点は素直に評価したい。特にSentinelのPlaybookによる自動インシデント対応は、実務レベルで使える水準になってきた。一方で、製品間の連携設定の複雑さやライセンス体系の分かりにくさは引き続き改善してほしい。これだけの製品ラインナップと実力があるのだから、全体をもっとシンプルに使えるようにできるはずだ。 「AIが攻撃するなら、AIで守る」。この当たり前の原則を実装する年が2026年だ。脅威の速度はすでに人間の対応限界を超えている。技術は存在する。あとは組織が本気で動くかどうか、それだけだ。 出典: この記事は 2026: The Year of AI-Assisted Attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

音声で会話するAIには、根本的なジレンマがある。「速く答えてくれないと会話にならない」と「正確で深い知識に基づいて答えてほしい」——この二つの要求は、従来のアーキテクチャでは両立が難しかった。日本のAIスタートアップ・Sakana AIが公開したKAME（カメ）は、このジレンマを「タンデムアーキテクチャ」という発想で突破しようとする意欲的な研究だ。 そもそも何が問題だったのか 現在の音声対話AIには大きく2つのアプローチがある。 Speech-to-Speech（S2S）モデルは、音声を直接音声に変換する。レイテンシが低く自然な会話が可能だが、LLMほどの知識や推論能力を持たない。 LLMベースの音声システムは、高い知識・推論力を持つが、テキスト変換を挟むため応答に時間がかかり、リアルタイム感が損なわれる。 Moshiなど既存のS2Sモデルは速さを優先した結果、複雑な推論問題でつまずくケースが多い。論文のデモでは「Davidには3人の姉妹がいる。それぞれに兄弟が1人いる。Davidの兄弟は何人か？」という問いに対して、Moshiは全く無関係なJerryとその孫の話を始めてしまった。正解は「0人（Davidが唯一の兄弟であり、兄弟を持つわけではない）」だが、KAMEはこの論理を正確に導き出している。 タンデムアーキテクチャの仕組み KAMEが採用するタンデムアーキテクチャは、S2Sモデルの「速さ」とLLMの「知識」を並走させる設計だ。 S2Sモデルが主役として音声を受け取り、リアルタイムで応答を生成する LLM（GPT-4.1等）が非同期で並走し、質問の意図・必要な知識を推論する LLMの出力をS2Sへ非同期注入することで、会話の自然な流れを保ちながら知識を補強する 「亀（カメ）」という名前は、着実に目的地へ到達する寓話を想起させる。速さだけでなく、確実性も重視するというコンセプトがよく表れている。 性能評価 GPT-4.1をバックエンドに用いた場合、知識・推論ベンチマークでMoshiの3倍以上のスコアを記録している。これは単純な流暢さの改善ではなく、推論ロジックそのものが向上していることを示す数字だ。 モデルはMITライセンスでHugging FaceおよびGitHubに公開されており、誰でも試せる環境が整っている。 実務への影響 このアーキテクチャが実用化されると、いくつかの領域に具体的な変化が見込まれる。 コールセンター・カスタマーサポート: 現在「複雑な問い合わせはオペレーターへ」という設計が多いのは、音声AIの推論能力に限界があるためだ。KAMEのように推論を持つ音声AIが普及すれば、自動対応の範囲が大きく広がる。 医療・法律などの専門領域: 高い知識精度が求められる分野でも、音声インターフェースの応用が現実味を帯びてくる。 アクセシビリティ: 文字入力が難しいユーザーに対して、より正確な音声インターフェースを提供できる可能性がある。 日本語への対応状況は今後の情報を待つ必要があるが、Sakana AIが日本を拠点とするスタートアップであることを考えると、日本語対応への意識は高いと期待できる。 筆者の見解 音声AIの難しさは、「会話の自然さ」と「内容の正確さ」が相反することにあった。KAMEのアプローチは、この二律背反を「どちらかを諦める」のではなく「アーキテクチャで解決する」という発想であり、技術的に非常に示唆に富む。 特に、LLMを非同期で並走させる設計は、AIシステム全般の設計思想に通じるものがある。単一のモデルで全てをこなそうとするのではなく、役割を分担させてそれぞれの強みを活かす——これは音声AIに限らず、エージェント設計全般に応用できる考え方だ。タスクの種類に応じて最適なモデルを組み合わせる「分業」の思想が、今後のAIアーキテクチャの主流になっていくと筆者は見ている。 Sakana AIがオープンソース戦略を採り、研究者やエンジニアがすぐに試せる環境を整えている点も評価したい。日本発の研究が国際的な土俵で存在感を示せているという事実は、素直に喜ばしい。 実務応用はまだこれからの段階だが、KAMEのようなアーキテクチャの登場は、音声AIが急速に進化していることの証でもある。エンジニアとしては、今のうちに基本的な仕組みを理解し、自分のユースケースで小さく試してみることをお勧めしたい。 出典: この記事は Sakana AI Introduces KAME: A Tandem Speech-to-Speech Architecture That Injects LLM Knowledge in Real Time の内容をもとに、筆者の見解を加えて独自に執筆したものです。

映画界最高峰の栄誉、アカデミー賞が動いた。米映画芸術科学アカデミー（AMPAS）が先週発表した新たな資格要件は、演技部門と脚本部門から生成AIを明確に除外するものだ。AIが急速に進化し、バーチャル俳優や故人の「復活」が現実のものとなりつつある今、エンターテインメント産業が「人間の創造性とは何か」という問いに公式に向き合った瞬間として記憶されるだろう。 何が変わったのか 新ルールによると、演技部門の対象となるのは「映画のクレジットに記載され、人間が同意の上で実演したことが証明できる演技」のみ。脚本部門では「人間が執筆した脚本のみが対象」と明記された。 この背景には、AI技術を活用して生成された架空の俳優「Tilly Norwood」の業界デビューや、故ヴァル・キルマーのAI生成パフォーマンスを使用した映画が物議を醸したことがある。アカデミーは「制作でのAI利用は止められないが、それを賞の対象にはしない」という立場を明確にした形だ。 なお現時点では、視覚効果（VFX）・衣装デザイン・音楽といった他カテゴリーへのAI制限は設けられていない。今回の措置は、人間性が直接問われる「演技」と「脚本」の二領域に絞られている点が重要だ。 なぜこれが重要か このルール変更が持つ意義の核心は、「consent（同意）」という概念の明示化にある。俳優が自身の肖像や演技データをAIに学習させることへの同意を要件化したことで、無断使用やディープフェイク問題に対する業界の姿勢が明確になった。 また、アカデミー賞は映画産業における事実上の国際標準を形成する。今回のルールは、他の映画賞にとどまらず、音楽・小説・ゲームといった創作産業全般が「AI利用の境界線」を引く際の参照点となりうる。 実務への影響 映像・コンテンツ制作の現場 日本の映像制作・広告・ゲーム業界にとっても、この流れは対岸の火事ではない。国内の映画賞や放送コンテンツ賞でも、近いうちに類似した基準設定の議論が浮上すると予想される。 制作現場のエンジニアやプロデューサーは今のうちに「どの工程にAIを使い、どの工程は人間が担うか」を文書化しておくことが重要だ。後から証明を求められたとき、プロセスの記録がなければ対応できない。特に受賞を目指す作品においては、制作フローの透明性が競争力に直結する時代が来る。 IT・エンジニアリング領域への波及 より広い視点では、「AIが生成したコードやドキュメントの帰属」という問いがソフトウェア業界でも本格化する前兆として読める。今はエンターテインメント産業が先行しているが、SIerや開発会社においても「AIを使って書いたコードの著作権は誰のものか」という議論が、顧客契約や内部規定に影響を与え始めるだろう。 筆者の見解 アカデミーのこの決断を、私は基本的に支持する立場だ。 ただ、この議論の本質は「AIを排除するかどうか」ではなく、「人間の主体性をどう定義するか」にある。現行ルールは「人間が演じたか・書いたか」という行為に着目しているが、それはあくまで出発点にすぎない。AIをフル活用しながらも、明確な人間の意図と判断が作品の核に存在する──そういう創作の在り方をどう評価するかという問いは、まだ答えが出ていない。 生成AIが「ツール」の段階では、人間とAIの境界線は比較的明確だ。しかし、AIが自律的に企画を立て、脚本の骨格を組み、演技プランを提案するような水準に近づくにつれ、「人間が書いた」という基準は必然的に揺らぎ始める。そのとき問われるのは、「どのくらい人間が関与したか」という量的な問いではなく、「誰が創造的な意思決定の責任を持ったか」という質的な問いになるはずだ。 「AIを禁じる」のではなく「人間性を再定義する」という視点でこの問いに向き合い続けることが、これからのクリエイターにもエンジニアにも等しく求められていると感じている。 出典: この記事は The Oscars just banned AI from winning acting and writing awards の内容をもとに、筆者の見解を加えて独自に執筆したものです。

海外エンジニアコミュニティで注目を集めている論考がある。「Agentic Coding Is a Trap（エージェントコーディングは罠だ）」と題されたこの記事が、Hacker Newsで350点以上のポイントを集め、250件超のコメントが寄せられた。「AIにコードを書かせ、人間はオーケストレーターになる」という現在の流行に対して、見逃せないリスクを丁寧に指摘している。軽視すべき内容ではない。 エージェントコーディングとは何か 「エージェントコーディング」とは、人間が仕様や要件を定義し、AIエージェントが実際のコードを生成・実装するアプローチだ。近年「Spec Driven Development（SDD）」とも呼ばれ、エンジニアは「良いセンスを持ったオーケストレーター」として、AIの出力をレビューしながら方向修正する役割に変わっていく——というビジョンが現在盛んに語られている。 見落とせない4つのリスク 原著の論考は、定量的なトレードオフとして4点を挙げている。 1. システムの複雑性増大 AIの非決定的な振る舞いを補うために、周辺の仕組みがどうしても複雑化していく。 スキルの劣化（Cognitive Atrophy） これが最も深刻な問題だ。コードを「書く」経験が減少することで、思考能力そのものが鈍化するというリスク。複数の研究でも裏付けられており、特に若手エンジニアへの影響は大きい。コードを読んでレビューすることは学習の半分に過ぎない——書く経験なしには、深い理解は育まれない。 3. ベンダーロックインとサービス依存リスク 特定のAIツールが障害を起こしただけで、チーム全体の作業が止まるという事態はすでに起きている。人的リソースのコストが固定費であるのに対し、APIトークンのコストは変動費かつ上昇傾向にある。 4. コスト変動リスク エンジニア雇用の費用は予測可能だが、AIのトークンコストは常に変動し、将来の価格設定はベンダーの意思決定に左右される。 「抽象化のステップアップ」論への反論 「プログラマーはFORTRANからJavaへ移ったように、AIへ移行するだけ」という反論もある。しかし原著はこれを正面から退ける。FORTRANやコンパイラへの移行は、「もしかしたらスキルが失われるかもしれない」という懸念——つまり将来への不安だった。今起きていることは実証済みの現象だ、というのが論旨だ。 C++からPythonに移ったとき、開発者たちはブレインフォグを訴えなかった。AWSを使い始めたSysadminがネットワーク理解力の低下を報告したわけでもなかった。だが、AIエージェントへの高い依存度が、認知的な変化をもたらしているという報告は現実に増えている。 日本のIT現場への示唆 日本では人材不足を補う手段としてAIコーディングへの期待が高まっており、特に若手育成に課題を抱えるチームほど、エージェントへの依存に傾きやすい。その気持ちは理解できる。 しかし、ここで冷静に考えておく必要がある。エージェントが生成した数千行のコードを適切にレビューできるのは、その技術を深く理解した人間だけだ。「誰でもオーケストレーターになれる」は幻想であり、アーキテクチャレベルで思考できる上流スキルこそが、今後ますます重要になる。 実務での活用ポイント： AIエージェントは補助ツールとして活用しつつ、コアロジックの設計・思考は自分の手で行う習慣を維持する 若手エンジニアには、AIなしでの基礎実装演習の機会を意識的に設ける 特定ツールへの依存度を管理し、代替手段を常に持っておく APIコストをモニタリングし、エスカレーション閾値を設定しておく 筆者の見解 この議論は重要だが、「だからエージェントコーディングはやめよう」という方向に解釈するのは違うと思う。 自律的に動くAIエージェントが持つ本質的な価値は、人間の認知負荷を削減し、より高次の思考に集中させることだ。問題は「エージェントを使うかどうか」ではなく、「どういう設計でエージェントを使うか」にある。 確かにスキル劣化のリスクは実在する。だからこそ、エージェントへの依存を意識的にコントロールし、自分のスキルを維持・発展させる姿勢が求められる。「AIがやってくれるから、自分は理解しなくていい」という考え方こそが、本物の罠だ。 そして原著が指摘する「本当に価値あるエンジニア像」は興味深い。「生成されたコードを批判的に読み解き、問題をアーキテクチャレベルで発見できる人間」——これはつまり、これまで以上に高い技術力を持つエンジニアだ。AIの時代に求められるのは技術的理解の放棄ではなく、その深化だ。 エージェントコーディングが「罠」になるかどうかは、使う人間の姿勢次第だ。ツールに振り回されず、設計の主導権を持ち続ける——それができる人間こそが、今後のソフトウェア開発の核になる。その視点を忘れずにいたい。 出典: この記事は Agentic Coding Is a Trap の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MITテクノロジーレビューが「2026年に本当に注目すべきAIの10テーマ」を発表した。毎年恒例の「10 Breakthrough Technologies」に触発された新企画として今年初めて公開されたリストであり、長年AIの進化を追ってきた編集者・レポーターたちが厳選した実質的なテーマが並ぶ。バズワードの羅列ではない。日本のIT現場に直結する内容を、実務目線で読み解く。 エージェントが「群れ」で動く時代へ：最大の注目点 今回のリストの中で最も実務的なインパクトが大きいのが、エージェントオーケストレーション（Agent Orchestration）だ。 第一世代のAIエージェントは、ブラウザを操作したりコードの断片を生成したりと、「単独で」動くものだった。次の波は根本的に異なる。複数のエージェントが協調し、はるかに複雑なゴールを達成するチームとして機能する設計だ。 これは概念的な話ではない。リサーチ・設計・テスト・デプロイをそれぞれ専門のエージェントが分担し、人間が承認を挟む頻度を最小化しながら大きなタスクを自律的に完遂する——そういった仕組みが実装段階に入りつつある。 「AIを使った詐欺」は現実の脅威になった スーパーチャージドスキャム（Supercharged Scams）という表現でMITが取り上げたのは、AIが詐欺・ハッキングの参入障壁を劇的に下げているという事実だ。フィッシングメールの文章品質向上、標的調査の自動化、音声・映像のディープフェイク悪用——それぞれ単独でも危険だが、組み合わさることで被害規模が跳ね上がる。 ディープフェイクの兵器化（Weaponized Deepfakes）も別項目として取り上げられており、非同意の性的画像生成や政治的プロパガンダへの利用が加速している現状が指摘されている。日本では「AIを使った詐欺への対策」がまだ机上の話として扱われる傾向があるが、現実はすでに動いている。ビジネスメール詐欺（BEC）の巧妙化はその最たる例だ。 LLMはまだ終わらない、世界モデルへの投資も加速 「大規模言語モデルは飽和した」という声もあるが、MITは**LLMs+**として「まだ絞れるジュースがある」と明確に述べている。新しいアーキテクチャへの移行よりも、現行LLMの改良・拡張・特化が今後数年の主流になる可能性が高い。 一方で世界モデル（World Models）への投資も加速している。LLMが「言語の世界」を学んだとすれば、世界モデルは「物理的な現実」の理解を目指す。ロボティクスやヒューマノイドロボット（Humanoid Data）との接点として注目される。人間の動作を大量に収集してロボット訓練に使うアプローチは、かつてLLMが人間の言語を学んだプロセスと構造的に似ている。 中国のオープンソース戦略が世界の地図を変えつつある 中国のオープンソース賭け（China’s Open-Source Bet）は地政学的に見逃せない。フロンティアモデルを無償公開することで、中国のAIラボはグローバルな開発者コミュニティに支持を広げている。財務的持続可能性は不明確だが、世界中のシステムが中国発の基盤の上に構築され始めているのは事実だ。 AIへの抵抗運動も静かに広がる レジスタンス（Resistance）——保守・リベラル・アーティスト・労働組合が連携してAI規制を求める運動——も確かに勢いを増している。また人工科学者（Artificial Scientists）として、AIが研究タスクを自律的にこなし科学者の真のコラボレーターとなる未来も描かれている。 実務への影響 日本のエンジニア・IT管理者がこのリストから直接持ち帰れるポイントを整理する。 1. エージェント設計のキャッチアップを急げ 単発の「AIに聞く」から「エージェントに任せる」へのシフトは、設計思想のレベルから変わる。今のうちにオーケストレーションの概念を実務に持ち込む実験を始めておきたい。 2. セキュリティ訓練をAI前提に作り直す フィッシングメールの品質が急上昇している現状を踏まえ、「変な日本語」で見抜けた時代は終わった。組織のセキュリティ教育を今すぐ見直す必要がある。 3. 「LLMはもう古い」という誤解に注意 アーキテクチャの新鮮さを追いかけるより、現行の高性能LLMをいかに業務に組み込むかを実践する方が、少なくとも2026年中は正解に近い。 4. 中国モデルの台頭を自社リスクとして評価する オープンソースモデル利用においてサプライチェーンの把握が重要になる。どの基盤モデルを使っているか・なぜかを説明できる状態を作っておきたい。 筆者の見解 今回のMITのリストを見て、真っ先に「エージェントオーケストレーション」に目が止まった。 個人的に最もアツいと感じているのは、エージェントがループで自律的に動き続ける仕組みだ。人間が都度承認を求められる設計では、AIの本質的な価値——認知負荷の削減——は得られない。「何をしたいか」を伝えれば、エージェントが判断・実行・検証を繰り返しながらゴールに向かう。その仕組みを設計・実装できる人間と、そうでない人間の差は今後指数的に広がると確信している。 一方で「AIへの抵抗」も軽視はできない。技術の普及に対する社会的な摩擦は必ず生じる。それ自体は健全な民主主義の機能だと思うが、規制の議論は「どう止めるか」より「どう安全に使えるようにするか」を軸にすべきだ。禁止アプローチは必ず失敗する。ユーザーが公式に提供されたものを最も便利と感じられる状況を作ることが、本質的な解決策になる。 日本のIT業界は、これらのトレンドに乗り遅れている企業がまだ多い。情報を追いかけることより、手を動かして実際に使い、成果を出す経験を積む方が今は正しい行動だと確信している。MITのリストは「何を実験すべきか」の優先順位を考える良い出発点になる。 出典: この記事は 10 AI Artificial Intelligence Trends Technologies Research 2026 | MIT Technology Review の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MetaがLlama 4シリーズの最初の2モデル、Llama 4 ScoutとLlama 4 Maverickを正式に公開した。いずれもテキスト・画像・音声・動画をゼロから統合して扱う「ネイティブマルチモーダル」設計で、しかもオープンウェイトとして提供される。llama.comおよびHugging Faceからダウンロード可能になっており、WhatsApp・Messenger・Instagram DirectなどのMeta製アプリでも利用できる。 Llama 4の3モデル構成 Llama 4 Scout（17Bアクティブパラメータ、16エキスパート） Int4量子化を行えば単体のNVIDIA H100 GPUで動作する軽量モデル。業界最長クラスの1000万トークン（10M tokens）コンテキストウィンドウを持ち、Gemma 3・Gemini 2.0 Flash-Lite・Mistral 3.1を複数のベンチマークで上回ると主張されている。 Llama 4 Maverick（17Bアクティブパラメータ、128エキスパート） 128のエキスパートを持つMoE（Mixture of Experts）アーキテクチャを採用。GPT-4oやGemini 2.0 Flashを複数のベンチマークで上回るとされ、コスト対性能比でも競争力を主張する。LMArenaでのELOスコアは1417。 Llama 4 Behemoth（2880億アクティブパラメータ、16エキスパート／未リリース） 前2モデルへの蒸留に使われた「教師モデル」。MATH-500やGPQA DiamondなどSTEMベンチマークで主要モデルを上回るとされているが、現時点ではまだ学習中であり一般公開はされていない。 ネイティブマルチモーダルが従来と何が違うか 従来のマルチモーダルモデルの多くは、テキスト基盤のLLMにビジョンモジュールを後付けする設計だった。Llama 4は最初からテキスト・画像・音声・動画すべてを同一アーキテクチャで処理するよう訓練されている。この「ネイティブ」設計の優位性は、モダリティ間の文脈理解が統一されている点にある。画像の内容を参照しながら音声で質問を受け付け、一貫した応答を返すといった処理が、継ぎ接ぎのない形で扱える。 実務への3つの影響 1. オンプレミス・プライベートクラウドでの展開可能性 ScoutがシングルH100で動くという点は実務的に重要だ。データを外部クラウドに送れない業種（医療・金融・製造業）でも、自前のGPUサーバー上にマルチモーダルAIを展開できる選択肢が生まれる。オープンウェイトであるため商用利用の検討もしやすい。 2. 長大コンテキストを要する業務フロー 1000万トークンのコンテキストウィンドウは、長大な契約書・技術仕様書・コードベース全体を一度に渡せる規模感だ。長文処理のワークフローを組む場合のベース候補として、実際に試してみる価値がある。 3. MoEアーキテクチャによるコスト設計 アクティブパラメータを17Bに抑えながらエキスパート数で機能を担保するMoE設計は、推論コストを抑えつつ総合的な性能を引き出す設計思想だ。クラウドAPIコストが課題になっているシステムでは、セルフホスト選択肢のコスト比較に組み込む意義がある。 筆者の見解 Llama 4の公開は、オープンウェイトAIの世界における技術的前進として客観的に評価できる。ネイティブマルチモーダル・MoE・超長コンテキストという設計を同時に実装してリリースしたことは、技術的チャレンジとして注目に値する一手だ。 ただし、ベンチマーク数値の解釈には慎重であるべきだと筆者は思っている。「〇〇を上回る」という主張は各社が互いに競い合って出している状況で、実業務での使い勝手はベンチマーク上の数字と必ずしも一致しない。発表文の威勢の良さに引きずられず、実際のユースケースで何ができて何ができないかを自分の手で確かめるのが正しいアプローチだ。 オープンウェイトという提供形態は、日本のIT現場にとってプライベートAI展開の選択肢を確実に広げてくれる。特に規制産業でのローカル実行ニーズは高く、技術的に追いかける価値のある選択肢が増えたことは素直に歓迎したい。情報を追いかけることよりも、実際に手を動かして自分の業務文脈で試すこと。それが今のAI時代で差をつける最短経路だと筆者は考えている。 出典: この記事は The Llama 4 herd: The beginning of a new era of natively multimodal AI innovation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

採用プロセスへのAI活用が急速に広がる中、見落とされていたリスクが論文として可視化された。求職者が履歴書作成にLLMを使い、企業側が同じLLMでスクリーニングする——この「AI対AI」の構図が、人間の書いた応募書類を組織的に不利にする可能性が実証された。 何が明らかになったか Jiannan Xuら（2025年8月、arXiv）の研究チームは、大規模な対照実験を設計した。主要な商用・オープンソースLLM複数種を対象に、「同一モデルが生成した履歴書」「人間が書いた履歴書」「別モデルが生成した履歴書」をスクリーニングさせ、合否傾向を比較した。 結果は鮮明だった。 自己優先バイアスは67〜82% ——モデルは人間の書いた履歴書より自分が生成したものを一貫して高く評価した 同一LLM使用者の書類通過率は23〜60%高い ——24職種のシミュレーションで、採用側と同じモデルを使った応募者が等しい能力でも有意に有利だった 最も不利なのは営業・経理など業務系職種 ——技術系より文章表現の比重が高いポジションで格差が大きかった シンプルな介入で50%超の抑制が可能 ——モデルの自己認識能力を狙った介入で、バイアスを大幅に低減できることも示された なぜこのバイアスが生まれるのか LLMは学習データと生成パターンを持つ。自分の出力には「自分らしい語彙・文体・論理構造」が刻まれており、それを評価基準として読み込むと自然に高評価を与える傾向がある。いわば「自分の文章を採点したら甘くなる」という構造的な問題だ。 これは意図的な不正ではなく、モデルアーキテクチャに起因する特性であるため、プロンプトで「公平に評価してください」と指示するだけでは解消されない。 日本の現場への影響 日本では新卒一括採用・ES（エントリーシート）選考という独自の慣行がある。この文化とAIスクリーニングの組み合わせは、海外以上に問題をはらむ可能性がある。 採用担当者が今すぐ確認すべき点： スクリーニングに使うLLMと、求職者が使いやすいLLMが一致していないか確認する ——特定のAIサービスを社内ツールとして案内しているケースは要注意 ESや履歴書の評価基準を明文化する ——「LLMが書いたかどうか」ではなく「どの能力を評価するか」を先に定義すると、バイアスの影響を構造的に抑えられる 複数モデルを評価に組み合わせることを検討する ——単一モデルに一任せず、異なるモデルの評価を並走させて差異を見る方法は現実的な対策になる 定期的な「ヒューマンレビューのサンプリング」を仕組みとして組み込む ——AIスクリーニング後の書類をランダムに人間が再評価し、システム偏差を定点観測する 応募者の立場からは： 自分のESや職務経歴書にAIを使う場合、使うモデルを多様化しておくと特定モデル依存のリスクを分散できる（これは防衛策であり、「AI利用をやめろ」というメッセージではない） 公平性の枠組みを広げる必要性 AI倫理の議論はこれまで「性別・年齢・人種等の属性バイアス」に集中してきた。今回の研究が問うのは、それとは異なる次元の問題だ。「どのツールを使ったか」という選択が、能力と無関係に選考結果を左右するなら、これは新しいデジタルデバイドになりうる。 高価な有料LLMサービスを使えた応募者の方が選考を通りやすい——そういう構造が静かに形成される前に、採用基準の設計とAI選定の見直しが求められる。 筆者の見解 「禁止すれば解決する」という発想は、ここでも通じない。 すでに求職者はAIで履歴書を書いており、企業はAIでスクリーニングしている。この現実を否定するのではなく、「どう設計すれば公平に機能するか」を考えるフェーズに入っている。 この研究が示した「介入によって50%超のバイアス低減が可能」という知見は重要だ。問題は認識されており、技術的な解決策も存在する。あとはそれを実際の採用フローに実装できるかどうか、設計する側の意思次第だ。 もう一つ気になるのが、この問題の「見えにくさ」だ。採用の合否は個人の実力以外の要因が複合するため、バイアスが存在しても統計的に露出しにくい。今回のように大規模な対照実験を設計しなければ可視化できない類の問題だ。 AIを使った意思決定の仕組みを構築する際には、「使っている」だけでなく「どう使っているかを観測し続ける」仕掛けが不可欠だ。採用に限らず、コンテンツモデレーション・ローン審査・人事評価——LLMが評価する側と評価される側の両方に立つ場面では、今回の知見を意識した設計が求められる。 採用AIの公平性は、今後数年で規制と訴訟の焦点になる可能性がある。日本企業も「とりあえず使ってみた」から「説明責任を持って運用する」フェーズへの移行を、早めに進めた方がいい。 出典: この記事は AI Self-preferencing in Algorithmic Hiring: Empirical Evidence and Insights の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたか 2026年4月16日、VS Code の Git 拡張機能に静かな変更がマージされた。git.addAICoAuthor という設定のデフォルト値が "off" から "all" に切り替えられ、Copilot を一切使っていなくても、コミット時に自動で Co-authored-by: GitHub Copilot というトレーラー行が付与されるようになったのだ。 PR（#310226）には説明文すらなく、コミュニティの反応は苛烈だった。投稿から数日で 👎 が 372件に達し、賛成の 👍 はわずか 2件。GitHub の単一PRとしては異例のスコアだ。 技術的な問題点 「使っていないのに名前が入る」問題 git の Co-authored-by トレーラーはもともと、複数人で書いたコードを正直に記録するための仕組みだ。OSS コミュニティでは著作権の帰属を明確にするために使われ、企業の内部開発でも「誰が書いたか」の追跡に使われる。 デフォルト "all" は、Copilot を積極的に使ったかどうかに関わらず、VS Code を起動していれば Co-author として記録する可能性を意味する。たとえ自分でゼロから書いたコードでも、コミットには AI の名前が残る。 実装の不整合も指摘 Copilot によるコードレビューも、この PR の問題を正確に突いている。設定スキーマのデフォルトは "all" に変わったが、extensions/git/src/repository.ts 内のランタイムフォールバックは config.get('addAICoAuthor', 'off') のままだ。スキーマとランタイムが乖離しており、テスト環境などでは意図しない挙動が生じる可能性がある。 オプトアウト設計の本質的な問題 ソフトウェアのデフォルト設定はユーザーの同意を代理する。特にプライバシー・著作権・帰属に関わる設定で「デフォルト有効」を選ぶことは、「ユーザーは気づかなくていい」という設計思想の表明にほかならない。 実務への影響 日本の企業エンジニアが確認すべきこと 1. 設定の明示的な管理 settings.json または devcontainer.json に次を追加し、意図しない挙動を防ぐ。 出典: この記事は VS Code inserting ‘Co-Authored-by Copilot’ into commits regardless of usage の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...