Tech News JP

OpenAI、10代ユーザー保護のためのAI安全ポリシーをオープンソース公開 OpenAIは、10代のユーザーが利用するAIサービスをより安全に構築できるよう、プロンプトベースの安全ポリシーをオープンソースで公開した。このポリシーは gpt-oss-safeguard モデルを通じて提供され、開発者が自社のAIアプリケーションに組み込むことができる。 何が公開されたのか OpenAIが今回リリースしたのは、未成年者（主に10代）向けに特有のリスクを軽減するためのプロンプトテンプレートおよびガードレール機能だ。gpt-oss-safeguard は、年齢層に応じた有害コンテンツのフィルタリングや、不適切な会話の誘導を検出・遮断する仕組みを提供する。 これまでOpenAI自身のサービス（ChatGPTなど）では年齢制限や安全フィルターが実装されていたが、サードパーティ開発者が同等の保護機能を独自サービスに実装するのは容易ではなかった。今回の公開により、OpenAI APIを利用するアプリ開発者も同様の安全機能を手軽に導入できるようになる。 背景：未成年のAI利用リスク 生成AIの急速な普及に伴い、10代の若者がAIチャットボットや生成サービスを日常的に利用するケースが世界中で増加している。日本でも学校教育へのAI導入が進む中、有害コンテンツへの誘導、過度な感情依存、個人情報の無意識な開示といったリスクへの懸念が高まっている。 米国では連邦・州レベルで未成年のオンラインサービス利用規制が強化されており、OpenAIをはじめとするAI企業にも社会的責任が強く求められている状況だ。 開発者への影響 gpt-oss-safeguard をシステムプロンプトに組み込むことで、以下のような制御が可能になる： 年齢に不適切なコンテンツ（暴力・性的表現・薬物関連など）の生成抑制 自傷・メンタルヘルス関連の話題に対するより慎重な応答 個人情報収集を促すような会話パターンの検出 ポリシーがオープンソースで提供されることで、開発者はコードを検証・カスタマイズすることも可能だ。透明性を高めることで、外部監査や規制対応にも活用できる。 今後の展望 OpenAIはこのリリースを「開発者コミュニティと共に、より安全なAI体験を構築するための第一歩」と位置づけている。教育テック企業や子ども向けサービスを手がける開発者にとって、このガードレールの活用は今後の標準的な実装手法となる可能性が高い。 AIの恩恵を若い世代にも届けながら、リスクを最小化する——そのバランスを技術で実現しようとするOpenAIのアプローチは、業界全体の動向を左右するものとして注目される。 元記事: Helping developers build safer AI experiences for teens

Databricks、AI駆動のセキュリティ製品「Lakewatch」を発表 クラウドデータ分析プラットフォームで知られるDatabricksが、新たなセキュリティ製品「Lakewatch」を発表した。同製品は同社のデータ格納能力を活かしつつ、脅威の検知・調査といった従来のSIEM（Security Information and Event Management：セキュリティ情報およびイベント管理）機能を提供するもので、AnthropicのAIモデル「Claude」を搭載したAIエージェントによって処理を高度化している点が特徴だ。 2スタートアップを相次いで買収 Lakewatchの基盤を支えるため、Databricksは2社のスタートアップを買収した。 1つ目はAntimatter。セキュリティ研究者のAndrew Krioukov氏が創業したスタートアップで、2022年にNew Enterprise Associates主導で約1,200万ドルを調達している。Databricksによる買収は昨年すでに完了していたが、今回初めて公式発表された。Antimatterは企業がエージェントを安全に展開しながら機密データを保護できる「データコントロールプレーン」技術を手がけており、2024年のRSA Innovation Sandbox Contestでもその技術が注目を集めた。 2つ目はSiftD.ai。こちらは今回の発表のわずか数週間前に交渉が始まり、月曜日に買収が完了したばかりという電撃的なディールだ。SiftD.aiは2025年11月に製品をローンチしたばかりの新興企業で、人間とAIエージェントが協働できるインタラクティブなノートブック（JupyterノートブックのようなUI）を開発していた。同社の共同創業者でCEOのSteve Zhang氏は、ログ管理・分析ツールで有名なSplunkで長年チーフサイエンティストを務め、「Search Processing Language（SPL）」を開発した人物として業界に知られる。 買収金額はいずれも非公開。Antimatterは50名未満、SiftD.aiは数名という小規模なチームだったが、両社の従業員はDatabricksに合流している。KrioukovはすでにDatabricksに入社しており、Lakewatchチームを率いている。 50億ドル調達を背景に積極買収戦略を継続 Databricksは直近で50億ドル（約7,500億円）の資金調達を完了しており、豊富なキャッシュを背景にスタートアップの買収を加速させている。同社広報は「私たちは常に次の動きを見据えている。市場の先を行き、顧客のニーズのギャップを埋めることが目標だ」とコメントしており、今後も積極的な買収姿勢を維持する方針を示している。 日本市場への影響 国内企業においてもクラウドデータ基盤の整備が進む中、SIEMとAIエージェントを組み合わせたセキュリティ製品への需要は高まっている。Databricksはすでに日本でも多くの企業に導入されており、Lakewatchが国内展開された際には、セキュリティオペレーションセンター（SOC）業務の自動化・効率化における有力な選択肢となる可能性がある。 元記事: Databricks bought two startups to underpin its new AI security product

AIチャットボットが「購買体験」の新戦場に GoogleとOpenAIの両社が、チャットAIをショッピングの起点にする機能を相次いで強化している。AIを介した購買体験をめぐる競争が急速に白熱してきた。 GeminiがGap Inc.と提携——チャットから直接購入が可能に Googleは米アパレル大手**Gap Inc.**との提携を発表し、GeminiのAIアシスタントを通じてGap・Old Navy・Banana Republic・Athletaの各ブランド商品をそのまま購入できる機能を提供する。ユーザーがGeminiに「コーディネートを教えて」などと質問すると、これらブランドの商品が提案され、チャット画面を離れることなく購入まで完了できる。 決済にはGoogle Payが使われ、配送はGap側が担当する仕組みだ。この購買体験を支えるのが、Googleが策定したUniversal Commerce Protocol（UCP）と呼ばれる標準規格。AIアシスタントが小売業者のサイト上で購買操作を行うための共通仕様で、すでにWalmartやTargetもこの仕組みで参加している。日本でも普及が進む「スーパーアプリ」的な発想に近く、チャットと決済の一体化という方向性は今後の主流になる可能性がある。 ChatGPTは「比較購入UI」を刷新——組み込みチェックアウトは撤退 一方のOpenAIは、ChatGPTの商品表示体験を大幅に改善した。複数の商品をサイドバイサイドで視覚的に比較できるようになり、価格・レビュー・スペックを一覧で確認できる。あわせて検索の速度・関連性・カバー率も向上し、より最新の商品情報が表示されるようになった。この機能は今週中にChatGPTの無料・Go・Plus・Proプランへ順次展開される予定だ。 ただし、OpenAIはチャット内で直接購入できる組み込みチェックアウト機能を事実上撤退させた。『The Information』や『CNBC』の報道によれば、今後はWalmartなどの小売業者がChatGPT内に独自アプリを展開する形に移行する方針だという。Walmartの幹部も『Wired』に対し、ChatGPTの組み込みチェックアウト経由の売上は「期待外れだった」と明かしており、AI直販モデルの難しさが浮き彫りになっている。 「AIで買い物したい」ニーズはまだ模索中 AIを通じた商品発見・購買は、検索エンジン依存から脱却したい小売業者にとっての新たなチャネルとして注目を集めている。しかし消費者がAI経由の購買体験を本当に望んでいるかどうかは、まだ答えが出ていない。OpenAIの撤退判断は、技術的な可能性と実際のユーザー行動のギャップを示す象徴的な事例と言えるだろう。 GoogleとOpenAIはそれぞれ異なるアプローチで、AIを「お買い物の相棒」にしようとしている。どちらの戦略が消費者に受け入れられるか、2026年のEC市場から目が離せない。 元記事: ChatGPT and Gemini are fighting to be the AI bot that sells you stuff

Armが数十年の歴史で初の自社製CPU——MetaのAIデータセンターへ今年導入 英国の半導体設計企業Armが、同社史上初となる自社製CPU「Arm AGI CPU」を発表した。これまでArmは自社のチップ設計をライセンスとして他社に提供するビジネスモデルを中心に成長してきたが、今回は自社でチップを製造・販売するという大きな方向転換となる。 AIインフェレンス向けに特化した設計 Arm AGI CPUは、AIエージェントなどのクラウド処理——いわゆるインフェレンス（推論処理）——に特化して設計されている。最大の特徴は1CPUあたり最大136コアを搭載でき、空冷サーバーラック1台に64基のCPUを搭載できる点だ。 Armによると、従来のx86 CPUと比較してワットあたりの性能が2倍となり、メモリボトルネックの軽減にも優れているという。ベースとなるプラットフォームはAWS Graviton、Nvidia Vera、Microsoft向けなどですでに実績のある「Neoverseプラットフォーム」を採用している。 Metaが筆頭パートナー兼共同開発者に 最初の顧客はMetaだ。Metaは「筆頭パートナー兼共同開発者」として、Armとデータセンター向けCPUの複数世代にわたる開発を進めると表明した。MetaはNvidiaやAMDなどのハードウェアと組み合わせてこのCPUを活用する計画を持つ。 Metaはこれまで独自のAIチップ開発に苦戦してきたと報じられており、Armとの協業は同社のAIインフラ強化の重要な一手となりそうだ。 有力企業から相次ぐ支持表明 今回の発表に合わせて、Amazon AWS、Microsoft、Google、Marvell、Nvidia、Samsungなど名だたる企業が祝辞を寄せた。一方、昨秋のライセンス契約をめぐる訴訟でArmとの法廷闘争に「完全勝利」を宣言したQualcommはリストに含まれていない。 また、Cerebras、Cloudflare、F5、OpenAI、SK Telecomなども導入予定企業として名を連ねている。ArmのクラウドAI部門責任者Mohamed Awad氏はCNBCの取材に対し、「自社プロセッサを自前で開発できない企業向けの有力な選択肢になることを目指している」と語っている。 SoftBank傘下のArmが迎える新時代 現在SoftBankが所有するArmにとって、今回の自社CPUビジネスへの参入はビジネスモデルの大きな転換点だ。契約の金額的条件や、Metaが調達するチップ数については非公開とされている。 x86（Intel・AMD）優位が続いてきたデータセンター市場において、省電力性能に優れたArmアーキテクチャのCPUが本格参入することで、AIインフラの競争構図はさらに激しくなりそうだ。 元記事: Arm’s first CPU ever will plug into Meta’s AI datacenters later this year

AIで生産性爆上がりのはずが……PyPIデータが語る現実 「バイブコーディング（vibe coding）」やAIエージェントツールの愛好者たちは、「生産性が2倍、10倍、いや100倍になった！」と声高に主張する。実際、ある開発者はAIを活用してWebブラウザをゼロからフルスクラッチで構築してしまったという話まで出てきた。 しかし、懐疑的な視点を持つ人々はこう問いかける。「では、そのAIアプリとやらはどこにある？」 開発者が保守的に見ても2倍生産的になったとするなら、作られるソフトウェアの量も2倍になっているはずだ。その「AI効果」は一体どこで確認できるのか。 PyPIデータで検証する Answer.AIのAlexis Gallagher氏とRens Dimmendaal氏は、この問いに答えるためPythonの中央パッケージリポジトリ「PyPI（Python Package Index）」のデータを分析した。PyPIは大規模かつ公開データであり、ソフトウェア生産量の変化を観測するのに適した指標と言える。 分析結果は明確だ。ChatGPT登場（2022年11月）前後でパッケージ総数の増加トレンドに明確な変化は見られない。月次の新規パッケージ数にいくつかのスパイクは存在するが、これらはスパムやマルウェアの氾濫によるものであり、genuine（本物の）パッケージ創出ではない。 「本物の」パッケージで見ると？ 単なるパッケージ数では不十分という批判も当然ある。そこで分析チームは別の指標を採用した。2025年12月時点でダウンロード数上位1万5000パッケージを対象に、誕生年ごとのコホートに分け、各コホートの「リリース頻度（update releases）」の中央値を時系列で追跡した。 結果は「まあ……そうかも？」というものだった。 ChatGPT登場後に生まれたパッケージは、最初の1年間のリリース頻度が年13回と、2014年生まれ（年6回）と比較して確かに高い。しかし、この上昇トレンドはChatGPT登場よりも前の2019年頃から始まっており、GitHub ActionsなどのCI（継続的インテグレーション）ツールの普及と時期が一致する。AIの恩恵と断言するには根拠が弱い。 さらに、「パッケージが古くなるほどリリース頻度が下がる」傾向はAI時代になっても変わっていない。AIが長期的なメンテナンスを活性化させているという証拠は見当たらない。 AIパッケージに限れば話は別 興味深いのは、パッケージをAI関連かどうかで分類した場合だ。AIに関連するパッケージには明確な「AI効果」が現れているのに対し、そうでないパッケージにはほとんど変化がない。 これは何を意味するのか。AIはAIそのものを開発するための生産性は押し上げているが、ソフトウェア開発全体のパラダイムシフトにはまだ至っていない可能性が高い。 日本の開発者へのインプリケーション 日本国内でもAIコーディングツール（GitHub Copilot、Cursor等）の活用が急速に広まっている。個々の開発者レベルでの体感的な生産性向上は確かに報告されているが、それが「作られるソフトウェアの総量」という巨視的な指標に反映されるまでには時間がかかるのかもしれない。あるいは、AIによる生産性向上は新たなソフトウェア創出よりも、既存システムの改善・技術的負債の解消に充てられているという解釈も成り立つ。 AIの生産性革命は本当に起きているのか。データが追いつくまで、議論はまだ続きそうだ。 元記事: So where are all the AI apps?

AIがコードを書いても「見た目」は確認できない問題を解決 AIコーディングエージェント（Claude Code、Cursor、Codex、Gemini CLIなど）を使ったUI開発で、こんな不満を抱えていないだろうか。「エージェントがコードを書いてくれるのはいいが、実際にブラウザでどう表示されるかは毎回自分で確認しなければならない」——そんな悩みを解消するOSSツール「ProofShot」がHacker Newsで注目を集めている。 ProofShotは、AIコーディングエージェントがUIを構築した後、実際のブラウザ上での動作を自動記録・検証するCLIツールだ。エージェントが書いたコードが本当に正しく動いているか、レイアウトが崩れていないか、コンソールにエラーが出ていないかを「目に見える証拠」として残せる。 仕組みはシンプルな3ステップ 使い方は start → test → stop の3ステップで完結する。 元記事: Show HN: ProofShot – Give AI coding agents eyes to verify the UI they build

パッケージマネージャーに「冷却期間」を——サプライチェーン攻撃への新たな防衛策 LiteLLMのサプライチェーン攻撃（2026年3月）を受け、開発者コミュニティで改めて注目を集めているのが「依存関係クールダウン（dependency cooldown）」という考え方だ。これは、パッケージの更新版をすぐにインストールするのではなく、リリースから数日間待機してコミュニティが問題を検出できる時間を設けるという手法である。 オープンソース開発者のAndrew Nesbittが2026年3月にまとめたレポートによると、この機能への対応は予想以上に急速に広まっており、主要ツールが続々と実装を完了させている。 各ツールの対応状況 JavaScript/TypeScript系： pnpm 10.16（2025年9月）— minimumReleaseAge オプションを追加。信頼済みパッケージには minimumReleaseAgeExclude で除外設定が可能 Yarn 4.10.0（2025年9月）— npmMinimalAgeGate（分単位で指定）を実装。npmPreapprovedPackages で承認済みパッケージの除外もサポート Bun 1.3（2025年10月）— bunfig.toml 経由で minimumReleaseAge を設定可能に npm 11.10.0（2026年2月）— min-release-age オプションを追加 JavaScript以外： Deno 2.6（2025年12月）— deno update および deno outdated コマンドに --minimum-dependency-age フラグを追加 uv 0.9.17（2025年12月）— 既存の --exclude-newer に相対期間指定を追加。exclude-newer-package によるパッケージ単位の上書き設定も可能 pip 26.0（2026年1月）— --uploaded-prior-to オプションを追加（現時点では絶対タイムスタンプのみ対応） pip の相対期間指定はまだ未対応 Pythonの標準パッケージマネージャーである pip は現時点で絶対日時のみの指定に限られており、「3日以上経過したものだけ」といった相対的な指定には未対応だ。ただし開発者のSeth LarsonはCronジョブを使って pip.conf 内の日付を定期更新するという回避策を公開しており、相対期間指定のサポートはGitHub Issueで正式に要望されている。 なぜ今、この対策が重要なのか サプライチェーン攻撃とは、正規パッケージの更新に悪意あるコードを混入させる手法で、近年急増している。攻撃者はリリース直後の短い時間帯を狙うことが多く、クールダウン期間を設けることでコミュニティやセキュリティ研究者が問題を発見・報告する時間的余裕が生まれる。 日本の開発者にとっても、本番環境での npm install や pip install を自動化している場合は特に注意が必要だ。CI/CDパイプラインにこれらのオプションを組み込むだけで、ゼロコストに近い形でリスクを大幅に低減できる。 元記事: Package Managers Need to Cool Down ...

Claude Codeに「autoモード」が登場——AIが権限判断を自動化 Anthropicは2026年3月24日、コーディングエージェント「Claude Code」に新しい権限モード「autoモード」を導入した。従来の--dangerously-skip-permissionsフラグの代替として設計されたこのモードでは、Claudeがユーザーに代わって各アクションの実行可否を判断する。 仕組み：Claude Sonnet 4.6が「監視役」として動作 autoモードの核心は、メインセッションとは独立した分類器モデルにある。公式ドキュメントによれば、各アクションが実行される前にClaude Sonnet 4.6が会話全体を解析し、次の3点を検証する。 タスクのスコープを超えたアクションの拡大（スコープエスカレーション） 信頼されていないインフラへのアクセス ファイルやWebページに埋め込まれた悪意あるコンテンツ（プロンプトインジェクション）による操作 注目すべき点は、メインセッションが別のモデルを使用していても、分類器は常にClaude Sonnet 4.6で動作することだ。 デフォルトフィルターの内容 ターミナルでclaude auto-mode defaultsを実行すると、デフォルトのフィルタールールをJSON形式で確認できる。主な内容は以下の通り。 許可（allow）されるアクションの例： テスト用APIキーやプレースホルダー認証情報のハードコード プロジェクトスコープ内でのローカルファイル操作 状態を変更しないGETリクエストや読み取り専用API呼び出し requirements.txtやpackage.json等のマニフェストに既に宣言されているパッケージのインストール（pip install -r requirements.txt、npm install等） 警告付き拒否（soft_deny）の例： git push --forceやリモートブランチの削除 main/masterブランチへの直接プッシュ（PRレビューをバイパスするため） curl | bash等の外部コードの直接実行 S3、GCS、Azure Blobへの一括削除操作 専門家からの懐疑的な見方 Simon Willison氏（著名な技術ブロガー）は、AIに依存したプロンプトインジェクション対策に対して根本的な懸念を示している。AIの判断は本質的に非決定論的であり、公式ドキュメント自身も「ユーザーの意図が曖昧な場合や、環境に関する十分なコンテキストがない場合は、リスクのあるアクションを許可してしまう可能性がある」と認めている。 また、デフォルトのallowリストにpip install -r requirements.txtが含まれていることから、バージョン固定されていない依存関係を悪用したサプライチェーン攻撃には無防備な点も指摘されている。実際、同日にLiteLLMで類似した攻撃事例が報告されており、タイムリーな懸念といえる。 サンドボックスとの比較 Willison氏は「コーディングエージェントには、ファイルアクセスとネットワーク接続を決定論的に制限する堅牢なサンドボックスをデフォルトで使うべきだ」と主張する。autoモードのようなプロンプトベースの保護よりも、OS・コンテナレベルのサンドボックスの方が信頼性が高いという見解だ。 autoモードはフィルタールールをカスタマイズできる柔軟性を持ち、利便性と安全性のバランスを取る実用的なアプローチではある。ただし、セキュリティクリティカルな環境では、AIの判断に全面依存するのではなく、従来型のサンドボックスと組み合わせた多層防御が推奨される。 元記事: Auto mode for Claude Code

SpotifyがAI楽曲の「なりすまし問題」に本腰——事前承認機能をベータ公開 AIが生成した低品質な楽曲（いわゆる「AIスロップ」）が音楽ストリーミングサービスに溢れかえる中、Spotifyが実在アーティストの保護に向けた新機能「Artist Profile Protection（アーティストプロフィール保護）」のベータテストを開始した。 問題の背景：なぜ楽曲は「別のアーティスト」に紐付くのか メタデータの入力ミス、同名アーティストとの混同、そして悪意ある第三者による意図的な誤帰属——これらの理由から、無関係な楽曲がアーティストのプロフィールページに表示されるケースが以前から問題になっていた。AIで誰でも手軽に楽曲を制作・配信できる時代になったことで、この問題は深刻化の一途をたどっている。 Spotifyは公式ブログで「ストリーミングサービス全体で、楽曲が誤ったアーティストページに届く問題が続いていた。AI楽曲の急増がこの問題をさらに悪化させている」と現状を説明した。 新機能の仕組み：リリース前の「事前承認」制度 ベータに参加したアーティストは、Spotifyに配信される予定の楽曲を公開前にレビューし、承認または拒否できるようになる。承認された楽曲だけが以下の対象となる。 アーティストプロフィールへの表示 再生数・ストリーミング統計への反映 ユーザーへのレコメンド（リリースレーダー等）への登場 機能をオンにすると、自分の名前が付いた楽曲がSpotifyに配信されるタイミングでメール通知が届く。デスクトップおよびモバイルウェブの「Spotify for Artists」設定から操作できる。 業界全体で高まる危機感 この発表の約1週間前、ソニーミュージックは傘下アーティストになりすましたAI生成楽曲13万5,000曲以上の削除をストリーミングサービス各社に要請したと発表している。大手レーベルも対応に動く中、プラットフォーム側でのシステム的な解決策としてSpotifyの取り組みは注目に値する。 Spotify側は「この機能はすべてのアーティストに必要なわけではない」としつつ、以下のケースで特に有効だと説明している。 過去に誤った楽曲が届いた経験がある 同名の別アーティストが存在する プロフィールに表示される楽曲をより厳密に管理したい 「オープン配信」の光と影 インターネットの普及によりインディーズアーティストが自力で世界中に音楽を届けられる時代が到来したが、同時にゲートキーパー（審査機能）が弱体化するという副作用も生んだ。今回の機能はアーティスト自身がそのゲートキーパーになることを可能にするものだ。 Spotifyは2026年の最重要課題として「アーティストアイデンティティの保護」を掲げており、今後の正式リリースと機能拡充が期待される。 元記事: Spotify tests new tool to stop AI slop from being attributed to real artists

OpenAIのSoraアプリがサービス終了——AI専用SNSは6ヶ月で幕を閉じた OpenAIは2026年3月24日（現地時間）、TikTok風のAI動画SNSアプリ「Sora」のサービス終了を発表した。Soraは約6ヶ月前にローンチされたばかりで、終了の具体的な理由や日程はまだ公表されていない。 AI専用SNSへの熱狂はなぜ続かなかったのか Soraは招待制ソーシャルネットワークとして登場した当初、多くのユーザーが招待を求めて殺到した。しかし、Metaのメタバース向けVRプラットフォーム「Horizon Worlds」が一時の注目を集めながらも失速したのと同様に、Soraも長期的なユーザー定着には至らなかった。 基盤技術である「Sora 2」の動画・音声生成モデルは驚異的な品質を誇るが、AI生成コンテンツだけで構成されたフィードに対して、ユーザーの継続的な関心を維持することは難しかったようだ。 「キャメオ」機能が招いた混乱 Soraの目玉機能は「キャメオ（cameo）」と呼ばれるもので、自分の顔をスキャンしてリアルなディープフェイク動画を作れる仕組みだった。この機能は公開設定にすることもでき、他ユーザーが誰でもその人の「キャメオ」を使った動画を生成できる構造になっていた。 なお、芸能人ブッキングサービスの「Cameo」社が名称について法的措置を取り、OpenAIは機能名を「キャラクター（characters）」に変更させられている。 公人のディープフェイク制限があったにもかかわらず、ガードレールをかいくぐったコンテンツが次々と生成された。公民権運動の指導者マーティン・ルーサー・キング・ジュニアや俳優ロビン・ウィリアムズのディープフェイク動画が出回り、それぞれの娘がInstagramで「故人の動画を作るのをやめてほしい」と訴える事態にまで発展した。 また、マリオが大麻を吸ったり、ナルトがクラビーパティを注文したり、ピカチュウがASMRをしたりといった著作権キャラクターを使ったコンテンツも大量に生成され、法的リスクも浮上していた。 ディズニーとの10億ドル契約も白紙に こうした著作権侵害問題に対し、訴訟で知られるディズニーは意外な動きに出た。OpenAIに10億ドル（約1,500億円）の投資を行い、ディズニー・マーベル・ピクサー・スターウォーズのキャラクターを使った動画生成を許諾するライセンス契約を締結したのだ。AI業界にとって歴史的な瞬間とも評されたが、Soraのサービス終了とともにこの契約も消滅する。ただし、実際に資金が動く前に破談となったとみられる。 ディズニーは声明の中で「引き続きAIプラットフォームと連携していく」とコメントしており、今後の動向が注目される。 日本のAI業界への示唆 今回のSora終了は、高度なAI生成技術があってもSNSとして成立させることの難しさを改めて示した。日本でも画像・動画生成AIを活用したコンテンツプラットフォームの構想が増えているが、モデレーション体制の構築とユーザーが継続的に楽しめるコミュニティ設計が、技術力と同様に重要であることを示す事例といえるだろう。 元記事: OpenAI’s Sora was the creepiest app on your phone — now it’s shutting down

人気AIライブラリ「LiteLLM」がサプライチェーン攻撃に悪用される 複数の大規模言語モデル（LLM）プロバイダーへのアクセスを統一APIで提供するオープンソースPythonライブラリ「LiteLLM」が、悪意あるサプライチェーン攻撃の標的となったことが明らかになった。セキュリティ企業Endor Labsの調査により、ハッカー集団「TeamPCP」がPyPI上に悪意あるバージョンを公開し、インフォスティーラー（情報窃取型マルウェア）を配布していたことが確認されている。 LiteLLMは1日あたり340万回以上、過去1か月で9,500万回以上ダウンロードされている非常に人気の高いパッケージだ。AIアプリケーション開発者の間で広く使われており、その普及度の高さが今回の攻撃の被害規模に直結した。 何が起きたのか 攻撃者はLiteLLMのバージョン1.82.7および1.82.8に悪意あるコードを埋め込み、PyPIへ公開した。問題のコードは litellm/proxy/proxy_server.py にBase64エンコードされたペイロードとして挿入されており、パッケージをインポートするだけで自動実行される仕組みになっていた。 さらに悪質なのがバージョン1.82.8で、Pythonインタープリタが起動するたびに自動読み込みされる .pth ファイルを環境にインストールする機能が追加されていた。これにより、LiteLLMを直接使用していない場合でもマルウェアが実行されるという。 盗まれた情報の範囲 Endor Labsの分析によれば、攻撃は3段階で実行される： 認証情報の収集: SSHキー、AWSやGCP・Azureのクラウド認証情報、Kubernetesのサービスアカウントトークン、.env ファイル、データベース認証情報、TLSプライベートキー、CI/CDシークレット、暗号資産ウォレットなど幅広い情報が対象となる 横展開（ラテラルムーブメント）: Kubernetesクラスタ内で特権ポッドを展開し、全ノードへの侵害を試みる 永続化: systemd ユーザーサービスとして偽装したバックドアをインストールし、checkmarx[.]zone という攻撃者管理のドメインへ定期的に接続して追加ペイロードを受信・実行する 窃取データは tpcp.tar.gz という暗号化アーカイブにまとめられ、攻撃者のインフラに送信される。 TeamPCPとは TeamPCPはサプライチェーン攻撃を繰り返しているハッカー集団で、最近ではセキュリティツール「Trivy」（Aqua Security社）の侵害を引き起こし、Aqua SecurityのDockerイメージやCheckmarxのKICSプロジェクトへの連鎖的な侵害にもつながったとされている。同グループはKubernetesクラスタを標的に、イランと判定されたシステムに対してはマシンを完全にワイプするスクリプトを展開するなど、破壊的な活動も確認されている。 被害規模について、同グループは約50万件のデータ窃取を主張しており、マルウェアリポジトリのVX-Undergroundも同様の数字を報告しているが、現時点でBleepingComputerによる独立した検証はされていない（重複分を多数含む可能性がある）。 日本の開発者への影響と対策 LiteLLMは日本国内でもAI開発の現場で広く利用されているライブラリだ。バージョン1.82.7または1.82.8を使用していた場合は、早急に以下の対応を取ることが推奨される： 該当バージョンを即時アンインストールし、安全なバージョンへアップグレードする SSHキー、AWSアクセスキー、その他のクラウド認証情報をローテーション（再発行）する Kubernetes環境で不審なポッドや systemd サービスが作成されていないか確認する .env ファイルや CI/CD シークレットに不正アクセスの痕跡がないかログを確認する オープンソースパッケージのサプライチェーン攻撃は近年急増しており、依存ライブラリのバージョン管理と監査の重要性が改めて問われている。 元記事: Popular LiteLLM PyPI package backdoored to steal credentials, auth tokens

PTCのPLMソフトに緊急レベルの脆弱性——ドイツ警察が夜中に企業へ警告に駆けつける事態に PTC社は、同社の製品ライフサイクル管理（PLM）ソフトウェア「Windchill」および「FlexPLM」に深刻なリモートコード実行（RCE）の脆弱性が存在すると警告した。識別子は CVE-2026-4681 で、信頼済みデータのデシリアライゼーション処理を悪用することで攻撃が成立する。 ドイツ連邦警察が異例の緊急対応 今回の脆弱性で特筆すべきは、ドイツ当局の異例な動きだ。ドイツ連邦刑事庁（BKA）は週末、捜査官を国内の企業に直接派遣し、この脆弱性に関するPTCの通知文書を手渡した。深夜にシステム管理者を叩き起こしてまで警告に当たったケースもあり、対象製品を使用していない企業にまで連絡が届いたという。各州の州刑事庁（LKA）にも同様の通知が行われており、当局の危機感の高さが窺える。 PTCは顧客向けメールの中で「第三者グループによるこの脆弱性の即時悪用が差し迫っている、という信頼性の高い情報がある」と述べており、現時点での実害報告はないものの、攻撃が極めて近い段階にあると見られている。 未パッチ——今すぐできる緩和策を適用せよ 正式なパッチはまだリリースされていない。PTCは「すべてのサポート対象Windchillバージョン向けにセキュリティパッチを鋭意開発・リリース中」としている。脆弱性はすべての重要パッチセット（CPS）バージョンを含む、ほぼ全バージョンに影響する。 パッチが提供されるまでの緩和策として、PTCはApache/IIS向けのルール設定により、影響を受けるサーブレットパスへのアクセスを拒否することを推奨している。この緩和策は機能に影響しないとされている。 適用対象はインターネット公開インスタンスだけでなく、Windchill・FlexPLM・ファイルサーバー・レプリカサーバーを含むすべての展開環境だ。ただし、インターネットに公開されているインスタンスを優先すること。緩和策の適用が不可能な場合は、該当インスタンスをインターネットから切断するか、サービスを一時停止することを推奨している。 侵害指標（IoC）も公開——既に侵入されていないか確認を PTCは侵害を示す具体的な指標（IoC）も公開した。確認すべき項目は以下の通り。 ファイル: GW.class、payload.bin、dpr_<ランダム文字列>.jsp などのウェブシェル 不審なリクエスト: run?p= や .jsp?c= を含むパターンと、異常なUser-Agent文字列の組み合わせ エラーログ: GW、GW_READY_OK、または予期しないゲートウェイ例外の参照 PTCによれば、GW.class または dpr_<8桁16進数>.jsp がWindchillサーバー上に存在する場合、攻撃者がRCEを実行する前段階の「武器化」をすでに完了していることを意味する。 製造業・防衛産業への影響が懸念される背景 WindchillとFlexPLMは製品設計・製造工程の管理に広く使われており、兵器システムの設計を行う防衛関連企業や重要インフラを担う製造業でも採用されている。当局が異例の対応に踏み切った背景には、産業スパイや国家安全保障上のリスクへの強い懸念があると見られている。 WindchillやFlexPLMを利用している組織は、直ちに緩和策を適用し、IoC確認による侵害チェックを実施することが強く推奨される。 元記事: PTC warns of imminent threat from critical Windchill, FlexPLM RCE bug

Appleは、対象となるすべてのiPhoneおよびiPad向けにiOS 26.4とiPadOS 26.4の正式配信を開始した。 アップデートの概要 iOS 26.4はiOS 26系のマイナーアップデートにあたり、セキュリティパッチやバグ修正、システム全体の安定性向上が主な内容とみられる。Appleはリリースごとに既存機能の改善を積み重ねており、今回のアップデートもその流れを踏襲したものだ。 アップデート方法 iOS 26.4へのアップデートは、以下の手順で行える。 設定 アプリを開く 一般 → ソフトウェア・アップデート をタップ アップデートが表示されたら 今すぐインストール を選択 アップデートの適用にはWi-Fi接続と十分なバッテリー残量（または電源接続）が推奨される。 セキュリティアップデートの重要性 AppleはiOSのマイナーアップデートであっても、重要なセキュリティ脆弱性の修正を含むことが多い。特に企業環境でiPhoneを業務利用している場合は、IT管理者のポリシーに従いつつも、できるだけ早期の適用が望ましい。 日本国内でも多くのユーザーがiPhoneを利用しており、キャリア（docomo・au・SoftBank・楽天モバイル）を問わず、ソフトウェア・アップデートから最新版を適用できる。 対象デバイス iOS 26はiPhone 16シリーズをはじめ、iPhone 15・14・13・12・11、iPhone SE（第2世代以降）などの比較的新しいモデルが対象となっている。iPadOS 26も同様に、現行ラインナップの多くのiPadモデルに対応している。 詳細なリリースノートはAppleの公式サポートページで確認できる。 元記事: Apple releases iOS 26.4 and iPadOS 26.4 to the public

開発者の約8割が生成AIを毎日活用——大規模調査が示す現場の実態 ベルリン・フンボルト大学の研究チームがarXivに発表した論文「The State of Generative AI in Software Development」（arXiv:2603.16975）は、システマティック・レビューと65名の開発者へのアンケート調査を組み合わせ、生成AI（GenAI）がソフトウェア開発現場に与える影響を包括的に分析した。 驚異の利用率——79%が毎日使う 調査の最も目を引く結果のひとつが、利用頻度だ。回答者の**79%**が生成AIツールを「毎日」使用していると答えた。日本国内でもGitHub CopilotやChatGPTを業務利用する開発者が急増していることを考えると、この数字は現場の肌感覚とも一致する。 利用ツールの傾向としては、IDEに直接統合された開発支援ツールよりも、ブラウザベースの大規模言語モデル（LLM）——ChatGPT、Gemini、Claudeなど——を好む傾向が確認された。手軽にプロンプトを試せる柔軟性が支持される理由と考えられる。 効果が大きい領域と小さい領域 生成AIのインパクトが特に顕著だったのは以下の4領域だ： 設計（Design）：アーキテクチャ案の生成や設計ドキュメントの整備 実装（Implementation）：ボイラープレートコードの自動生成 テスト（Testing）：テストケース・テストコードの生成 ドキュメント（Documentation）：コメントやAPIドキュメントの自動作成 特にボイラープレートとドキュメント作業については、回答者の70%超が作業時間を半減以上削減できたと報告している。 一方で、計画（Planning）や要件定義（Requirements Analysis）といった初期フェーズへの貢献は相対的に低く評価されていた。あいまいな要件を整理したり、ステークホルダーと合意形成を図ったりする業務は、依然として人間の判断が不可欠であることが示唆されている。 ガバナンスの成熟——3分の2の組織がガイドラインを整備 組織レベルでも変化が起きている。調査対象組織の3分の2が、生成AIの利用に関する公式または非公式のガイドラインを持つと回答した。日本企業でもAI利用ポリシーの整備が進む中、この数字はグローバルな傾向と一致している。 研究が警告するリスク——スキル劣化と技術的負債 研究チームは、生成AIの普及がもたらすリスクについても明確に言及している。 批判的思考の欠如：AIの出力を無批判に受け入れる「鵜呑み採用」 スキルエロージョン（技術力の劣化）：AIへの過度な依存による基礎的なコーディング能力の低下 技術的負債の蓄積：生成コードの品質が低い場合、長期的なメンテナンスコストが増大 これらのリスクに対応するには、Human-in-the-Loop（人間の監督を組み込んだ設計）と強固なガバナンス体制が不可欠だと論文は強調する。 価値創出の重心がシフトしている 論文の核心的な主張はシンプルだ。生成AIの普及により、開発者の価値創出の重心が「ルーティンなコーディング」から「仕様の品質向上」「アーキテクチャ的思考」「AIアウトプットの監督・評価」へと移行しつつある。 ツールを使いこなすだけでなく、AIが生成したものを適切に評価・修正できる能力こそが、これからのエンジニアに求められるコアスキルになっていくだろう。 元記事: The State of Generative AI in Software Development: Developer Survey Insights

AIエージェント時代の幕開け——2026年3月に起きたパラダイムシフト 2026年3月は、AI支援ソフトウェア開発における決定的な転換点として記録されることになるだろう。これまでAIツールといえばコード補完が主役だったが、今月の動向は「コードを提案するAI」から「自律的に判断・実行するAIエージェント」へと業界の重心が完全に移ったことを示している。 Dapr Agents v1.0 GA——エンタープライズ品質の基盤がついに整う 最大の注目株は、Dapr Agents v1.0の一般提供（GA）開始だ。Cloud Native Computing Foundation（CNCF）が2026年3月23日に発表したこのフレームワークは、マイクロサービス向け分散アプリケーションランタイム「Dapr」の堅牢な基盤の上に構築されている。 主な特徴は次の通りだ。 セキュアなマルチエージェント連携: 複数のAIエージェントが安全に協調して動作できる仕組みを標準提供 状態管理（State Management）: エージェントの実行状態を永続化し、再起動後も処理を継続できる 障害復旧（Failure Recovery）: 耐障害性の高いワークフローを実現し、本番環境での信頼性を担保 Pythonベース: データサイエンティストや機械学習エンジニアが親しみやすい言語で実装可能 これまでAIエージェントは「デモは動くが本番には使えない」という「エージェント信頼性ギャップ」が課題だった。Dapr Agents v1.0はこのギャップを埋める最初のプロダクショングレードなフレームワークの一つとして、エンタープライズ採用を検討する組織から強い関心を集めている。 AIコーディングアシスタントの進化も加速 エージェント系ツールが注目を集める一方、従来型のAIコーディング支援ツールも進化を続けている。 GitHub CopilotはGPT-4oアーキテクチャを搭載し、コード補完を超えて関数丸ごとの生成・バグ修正・ユニットテスト作成まで対応。40以上のプログラミング言語をカバーし、「Agent Mode」でのマルチファイル理解も強化されている。 Cursorはリポジトリ全体のコンテキストを把握するAIネイティブなコードエディタとして差別化を図り、アーキテクチャレベルの意思決定支援まで踏み込んでいる。 Amazon CodeWhispererはAWS特化の強みを活かし、Lambda関数やクラウドインフラのコード生成で引き続き存在感を示している。 セキュリティ課題も顕在化 急速な普及と同時に、セキュリティ面のリスクも表面化している。オープンソースのエージェントツールでは、プロンプトインジェクション（悪意ある入力でエージェントを誤動作させる攻撃）や、未検証のプラグインが自律システムに組み込まれるリスクが指摘されている。AIガバナンスプラットフォームへの注目が高まっているのも、こうした背景からだ。 AIエージェントが「実験的な技術」から「本番稼働するデジタルワーカー」へと脱皮しつつある今、開発組織には技術的な期待と同時に、適切なリスク管理の視点が求められている。 元記事: Dapr Agents v1.0 GA: Cloud-Native AI Agent Runtime Reaches Production Milestone

Luma AI、画像理解と生成を一つに統合した「Uni-1」を発表 AIスタートアップのLuma AIは、画像の「理解（Understanding）」と「生成（Generation）」という従来は別々のモデルが担っていた2つの機能を、単一のアーキテクチャに統合した新モデル「Uni-1」を発表した。 従来モデルとの違い これまでのマルチモーダルAIは、画像を認識・解析するモデルと、テキストや指示から画像を生成するモデルが分離されているのが一般的だった。たとえば、GPT-4oのビジョン機能は画像理解に優れる一方、画像生成にはDALL-Eなど別モデルが必要だ。 Uni-1はこの境界を取り払い、一つのモデルがプロンプトを受け取りながらリアルタイムで推論しつつ、画像を生成するという仕組みを実現している。理解と生成を同一のパラメータ空間で処理することで、文脈理解の精度を保ちながら高品質な画像出力が可能になるという。 マルチモーダルモデルの新しいアプローチ Uni-1が注目される理由の一つは、そのアーキテクチャの設計思想にある。既存のモデルでは「理解」と「生成」のタスクを切り分けてパイプライン処理するのが主流だったが、Uni-1はこれを統一的な表現空間（Unified Representation Space） で処理する。 このアプローチにより、以下のメリットが期待される： 文脈の一貫性向上：画像を理解しながら生成するため、指示内容との整合性が高まる モデルの軽量化：2つのモデルを別々に維持する必要がなくなる リアルタイム性：推論と生成が同時進行するため、レイテンシの改善が見込める 日本市場への影響と今後の展開 Luma AIはこれまでも動画生成AI「Dream Machine」で注目を集めており、クリエイティブ分野への影響力を持つ企業だ。Uni-1の登場は、画像編集・コンテンツ制作ツールを開発する国内のスタートアップや、広告・メディア業界にとっても見逃せない動向といえる。 マルチモーダルAIの統合化は、Google（Gemini）やAnthropicをはじめとする大手も取り組む方向性であり、Uni-1はその競争に新たな一石を投じる可能性がある。詳細なベンチマークや商用APIの提供時期については、今後の続報が待たれる。 元記事: Luma AI Unveils Uni-1: Unified Image Understanding and Generation Model

Mistral 3登場——オープンソースAIの新時代へ フランスのAIスタートアップMistralは、第3世代モデルファミリー「Mistral 3」を発表した。エッジ・ローカル向けの小型モデル3種（3B・8B・14B）と、フロンティア級の大規模モデル「Mistral Large 3」で構成され、すべてApache 2.0ライセンスで公開される。商用利用・改変・再配布が自由なオープンウェイトモデルとして、開発者コミュニティから大きな注目を集めている。 Mistral Large 3：675B MoEの実力 「Mistral Large 3」は、アクティブパラメータ41B・総パラメータ675BというMixture-of-Experts（MoE）アーキテクチャを採用したMistral初のMoE大規模モデルだ。NVIDIA製H200 GPU 3,000基を使ってスクラッチから学習されており、画像理解や英語・中国語以外の多言語会話において最高水準の性能を発揮するとされる。 性能面では、LMArenaリーダーボードのOSSノン推論モデル部門で2位（OSS全体では6位）を記録。GPT-5.2比で約92%の性能を約15%のコストで実現するというコスト効率の高さが特に注目される。ベースモデルとインストラクション・ファインチューニング済みモデルの両方が公開されており、推論特化バージョンも近日リリース予定だ。 NVIDIA・vLLM・Red Hatとの協業による推論最適化 Mistral Large 3は、NVIDIAのBlackwell世代向けアテンション・MoEカーネルをはじめ、TensorRT-LLMおよびSGLangによる低精度高速推論に対応している。NVFP4フォーマットのチェックポイントも提供され、Blackwell NVL72システムや単一の8×A100・8×H100ノードでもvLLMを使って効率的に動かせる。 プリフィル/デコードの分離サービングや投機的デコード（Speculative Decoding）のサポートも追加されており、長コンテキスト・高スループットなワークロードへの対応が強化されている。 Ministral 3：エッジAIの新基準 エッジ・ローカル向けの「Ministral 3」シリーズは3B・8B・14Bの3サイズ展開で、各サイズにベース・インストラクト・推論の3バリアントを用意。すべてのモデルが画像理解と多言語対応を標準搭載する。 NVIDIAのDGX Spark、RTX搭載PC・ノートPC、Jetsonデバイスといったエッジ環境への最適化も進められており、データセンターからロボティクスまで一貫した推論パスを提供する。OSS小型モデルの中でも最高水準のコストパフォーマンス比を実現するとMistralは主張している。 日本語対応への期待 多言語性能を強調している点は、英語・中国語以外の言語ユーザーにとって朗報だ。日本語を含む非英語圏での実運用での性能検証が今後の焦点となる。Apache 2.0ライセンスにより、日本企業や個人開発者も自社環境への組み込みや追加学習が容易に行えるため、オンプレミスAI活用の選択肢として有力な候補になりそうだ。 元記事: Introducing Mistral 3 — Including Large 3 (675B MoE)

Microsoftは2026年3月のパッチ火曜日（Patch Tuesday）において、83件のCVE（Common Vulnerabilities and Exposures）に対処するセキュリティ更新プログラムをリリースした。深刻度の内訳は「Critical（緊急）」が8件、「Important（重要）」が75件となっている。 Azure MCPサーバーのSSRF脆弱性が要注意 今月のアップデートで特に注目すべきは、Azure MCP（Model Context Protocol）サーバーに存在するSSRF（Server-Side Request Forgery）脆弱性（CVE-2026-26118）だ。CVSSv3スコアは8.8と高く、MCPサーバーを活用したAI開発環境を運用している組織には優先的な適用が推奨される。MCPはAnthropicが主導する標準プロトコルで、AIエージェントと外部ツール・データソースを繋ぐ仕組みとして急速に普及しており、その普及に伴い攻撃対象面も広がっている点に留意が必要だ。 ゼロデイを含むSQL Server特権昇格（EoP） CVE-2026-21262、CVE-2026-26115、CVE-2026-26116は、Microsoft SQL Serverに影響する特権昇格（EoP）脆弱性で、いずれもCVSSv3スコア8.8。このうちCVE-2026-21262はパッチ公開前にゼロデイとして公開されていた。悪用に成功すると攻撃者はSQL Serverのsysadmin権限を取得できるため、データベース管理者は早急な対応が求められる。 .NETのDoS脆弱性もパッチ公開前に情報漏洩 CVE-2026-26127は、.NET 9.0および10.0（Windows・macOS・Linux対応）に影響するサービス拒否（DoS）脆弱性で、CVSSv3スコアは7.5。こちらもパッチ公開前に情報が公開されたが、Microsoftは「悪用の可能性は低い」と評価している。同時に、Linux上の.NET 10に存在するEoP脆弱性（CVE-2026-26131）も修正された。 Windowsカーネルの特権昇格にも複数の修正 Windowsカーネルに影響するEoP脆弱性として、CVE-2026-24287、CVE-2026-24289、CVE-2026-26132の3件が修正された（各CVSSv3スコア7.8）。ローカルの認証済み攻撃者がSYSTEM権限を取得できる可能性があり、CVE-2026-24289とCVE-2026-26132は「悪用の可能性が高い（Exploitation More Likely）」とMicrosoftが評価している。2026年に入りWindowsカーネルのEoPパッチは累計6件に達した。 今月の傾向 今月修正された脆弱性の種類別では、**特権昇格（EoP）が55.4%**と最多で、リモートコード実行（RCE）の20.5%がこれに続く。MCPサーバーやAzure関連サービスを利用している環境では特に早急な適用を検討されたい。 元記事: Microsoft March 2026 Patch Tuesday: 83 CVEs including Azure MCP Server SSRF (CVE-2026-26118)

Azure AI Foundry、gpt-4oファインチューニングのサポート期間を延長 Microsoftは、Azure AI Foundry上で提供しているgpt-4oおよびgpt-4o-miniのファインチューニング（Fine Tuning）機能について、サポート終了（EOL）の日程を延期することを発表した。すでに本番環境でカスタムモデルを稼働させている企業に対し、移行作業の猶予期間が与えられた形となる。 ファインチューニングとは ファインチューニングとは、汎用的な大規模言語モデル（LLM）を特定のタスクやドメインに特化させるための追加学習手法だ。自社の業界用語・文体・業務フローに最適化したモデルを構築できるため、カスタマーサポートや社内ドキュメント検索、コード補完など多様な用途で活用されている。 企業への影響 今回のサポート延長は、すでにgpt-4oまたはgpt-4o-miniのファインチューニング済みモデルを本番パイプラインに組み込んでいる企業にとって特に重要な意味を持つ。EOLが近づく中でモデルの切り替えを余儀なくされていた場合、予期せぬ動作変化やリグレッションのリスクを抱えながらの対応を迫られていた。今回の延期によってその時間的プレッシャーが緩和され、段階的かつ計画的なモデル移行が可能になる。 日本企業においても、Azure OpenAI Serviceを通じてファインチューニング機能を採用する事例は増加傾向にあり、特に製造・金融・医療分野での活用が広がっている。サポート期間の延長は、これらのワークフローの安定稼働を後押しする。 今後の移行に向けて Microsoftは引き続き次世代モデルへの移行を推奨しており、今回の延期はあくまで「移行のための猶予」と位置づけている。企業側は、新しいEOL日程を確認した上で、モデルの再評価やファインチューニングデータの移植計画を進めることが求められる。 Azure AI Foundryのポータルまたは公式ドキュメントから、各モデルの最新のライフサイクル情報を定期的に確認することを推奨する。 元記事: Announcing extended support for Fine Tuning gpt-4o and gpt-4o-mini

Azure SQL Managed Instance、SQL Server 2025更新ポリシーが正式GA Microsoftは、Azure SQL Managed Instance（以下、SQL MI）において「SQL Server 2025更新ポリシー」が一般提供（GA）に達したことを発表した。これにより、Azure SQL MIユーザーは最新のSQLエンジン機能とAzure統合機能を継続的に受け取れる環境が正式に整った。 更新ポリシーとは何か Azure SQL Managed Instanceの「更新ポリシー」とは、インスタンスがどのタイミングでどのバージョンのSQLエンジン機能を受け取るかを制御する設定だ。従来は「SQL Server 2022」ポリシーがデフォルトだったが、今回のGAにより「SQL Server 2025」ポリシーがAzureポータルの新規インスタンス作成時のデフォルトとなった。 SQL Server 2025ポリシーを選択することで、以下のような恩恵を受けられる： 最新のSQLエンジン機能を継続的に受信（新しいT-SQL構文、クエリオプティマイザーの改善など） Azure固有の統合機能（Azure AI、Fabric連携など）をいち早く利用可能 Microsoftが今後リリースするSQL Server 2025相当の新機能が自動的に適用される 既存インスタンスの移行手順 既存のSQL MIインスタンスをSQL Server 2022ポリシーからSQL Server 2025ポリシーに変更する場合、Azureポータルの「コンピューティング + ストレージ」設定画面から更新ポリシーを切り替えることができる。Azure CLI（az sql mi update）やPowerShellからの変更も可能だ。 ただし、移行にあたっては以下の点に注意が必要だ： ポリシー変更は一方通行：SQL Server 2025ポリシーに変更後、SQL Server 2022ポリシーに戻すことはできない アプリケーションの互換性確認：新機能の一部が既存アプリケーションの動作に影響を与える可能性があるため、開発環境での事前検証を推奨 フェイルオーバー：ポリシー変更時に短時間のフェイルオーバーが発生する場合がある 日本のユーザーへの影響 日本国内でも多くの企業がAzure SQL Managed Instanceをオンプレミスから移行する際の選択肢として活用している。SQL Server 2025更新ポリシーのGAにより、今後新規にSQL MIを採用する案件では自動的にこのポリシーが適用されることになる。既存の運用システムを持つ企業は、アップグレードのタイミングと互換性を慎重に評価した上で移行計画を立てることを推奨する。 Microsoftは今後もSQL Server 2025ポリシーを通じて、AIや大規模データ処理に対応した新機能を順次展開していく方針を示している。クラウドネイティブなSQL環境への移行を検討している企業にとって、今回のGAは重要なマイルストーンと言えるだろう。 元記事: GA of update policy SQL Server 2025 for Azure SQL Managed Instance ...