クラウドネイティブとは何かを問われたとき、従来の開発手法との本質的な違いや具体的な定義をうまく説明できずに悩んでしまった経験はないでしょうか。クラウドネイティブの設計思想や技術を正しく理解することによって、システムの俊敏性やスケーラビリティ、回復力を最大限に引き出したアプリケーション開発を実現できます。
この記事では、クラウドネイティブの基本的な定義に加え、従来型システムとの相違点や導入メリット、さらにはコンテナといった中核的な技術まで詳しく解説します。自社でDX推進やモダンなクラウド設計への移行を検討している経営者やエンジニアの方は、ぜひ参考にしてください。
目次
- クラウドネイティブの定義とは
- 従来手法に対するクラウドネイティブの相違点
- 既存の仕組みをそのまま載せるクラウド対応から脱却する
- 全体が密結合した従来型のモノリシック開発から移行する
- クラウドネイティブを導入するメリット
- 需要の変化に合わせてリソースを自動で拡張する
- 障害が発生してもシステム全体を停止させずに復旧する
- 新機能のリリースを迅速に実施する
- クラウドネイティブが抱える導入時の課題
- 高度な専門知識を持つITエンジニアを確保する
- 共有責任モデルに基づいたセキュリティ対策を確立する
- クラウドネイティブを構成する中核的な技術
- アプリケーションの動作環境を仮想化するコンテナ
- サービスごとにシステムを細分化するマイクロサービス
- サービス間の通信を適切に制御するサービスメッシュ
- インフラ環境の変更を自動化する宣言型API
- クラウドネイティブに関するよくある質問
- CNCFが定義するクラウドネイティブの基準とは何ですか？
- クラウドネイティブの導入を成功させる組織の特徴はありますか？
- 専門エンジニアを育成するための有効な方法はありますか？
クラウドネイティブの定義とは
クラウドネイティブとは、パブリッククラウドやプライベートクラウド、ハイブリッドクラウドといった動的なクラウド環境の特性を活かして、システムの柔軟性や拡張性を最大限に引き出すようにアプリケーションを設計・運用する考え方です。
クラウドネイティブが目指すのは、既存のシステムをクラウド上のサーバーへ移し替えるだけの移行ではありません。クラウドが備える自動化や伸縮性といった利点を、設計の段階から全面的に取り込む点に本質があります。
CNCF(Cloud Native Computing Foundation)の公式定義で基準とされているのは、回復性・管理性・可観測性、そして堅牢な自動化をシステムにもたらす技術です。
このアプローチを採用すると、変化の激しい市場環境においても、迅速に新しい価値をユーザーへ届けられます。
ビジネスの観点で整理すると、クラウドネイティブによって「俊敏性」「スケーラビリティ」「回復力」という3つの代表的な価値を得やすくなります。
具体的な価値を整理した表は、以下の通りです。
| 代表的なビジネス価値 | 具体的な概要 |
|---|---|
| 俊敏性 | 新機能の開発やリリースを迅速に実施する能力 |
| スケーラビリティ | 需要の変化に合わせてリソースを自動で拡張する能力 |
| 回復力 | 障害の発生時に影響範囲を抑えながら復旧を図る能力 |
これらのビジネス価値を追求することが、DXの推進や新規事業の立ち上げを成功に導く強固な土台となります。
クラウド環境の特性を活かしてシステムを最適化すれば、新規構築だけではなく既存システムの段階的なモダナイゼーションでも、企業の競争力を長期的に支えるインフラを確立できます。
「クラウドネイティブ」の検索需要・市場動向トレンド
データ自動更新日: 2026-06-04過去1年間で最も検索されたピーク時を100とした現在の相対数値
直近4週間と前月の検索ボリュームの平均比較増減値
47都道府県別の関心度一覧
| 地域名 | 関心度指数 |
|---|---|
| 東京都 | 100 |
| 滋賀県 | 90 |
| 神奈川県 | 55 |
| 群馬県 | 52 |
| 福岡県 | 43 |
| 愛知県 | 41 |
| 千葉県 | 34 |
| 大阪府 | 33 |
| 北海道 | 27 |
| 埼玉県 | 26 |
| 京都府 | 26 |
| 長野県 | 3 |
| 兵庫県 | 1 |
| 福島県 | 0 |
| 熊本県 | 0 |
| 石川県 | 0 |
| 福井県 | 0 |
| 三重県 | 0 |
| 秋田県 | 0 |
| 茨城県 | 0 |
| 沖縄県 | 0 |
| 青森県 | 0 |
| 静岡県 | 0 |
| 香川県 | 0 |
| 高知県 | 0 |
| 鳥取県 | 0 |
| 長崎県 | 0 |
| 愛媛県 | 0 |
| 栃木県 | 0 |
| 山口県 | 0 |
| 佐賀県 | 0 |
| 和歌山県 | 0 |
| 大分県 | 0 |
| 奈良県 | 0 |
| 宮城県 | 0 |
| 宮崎県 | 0 |
| 富山県 | 0 |
| 山形県 | 0 |
| 新潟県 | 0 |
| 山梨県 | 0 |
| 岐阜県 | 0 |
| 岡山県 | 0 |
| 岩手県 | 0 |
| 島根県 | 0 |
| 広島県 | 0 |
| 徳島県 | 0 |
| 鹿児島県 | 0 |
すべての関連急上昇キーワード
| 関連クエリ | 伸長率 |
|---|---|
| 直近の急上昇クエリはありません | |
📚 「クラウドネイティブ」の人気書籍5選（楽天ブックス · 2026-06-04時点）
想定年収と求人倍率（2026年6月4日時点）
クラウドネイティブの想定年収・求人倍率の市場観測
- 求人倍率 5.24 倍。求人倍率が極めて高く、慢性的な人材不足が続いている領域です。応募者にとっては選択肢が広く、企業側の競争が強い市況です。
- 想定年収はカテゴリ平均（537万円）より約62万円低く、入門〜中堅層が中心の領域と考えられます。
- 本キーワード単体の市場統計が限定的なため、最も近い関連職種の数値を参考値として表示しています。実際の数値とは差が出る可能性があります。
数字の読み方について
求人倍率＝ 求人数 ÷ 求職者数（その職種で転職活動をしている人数）。
1.0 を超えると「求職者 1 人に対して 1 件以上の求人がある」状態で、数字が大きいほど企業側が人材を求めている状況を示します。
IT・デジタル領域は全体平均より高い水準で推移する傾向があり、目安として 2.0 倍を超える職種は人材不足が顕在化していると言われます。
このページの想定年収は、転職市場で公開されている職種別年収統計に基づく中央値水準を表示しています。
実年収は経験年数・地域・企業規模・スキル深度・担当範囲によって大きく変動します。
関連職種からの推計値の場合は、より近しい職種の値を参考として掲載しています。
クラウドネイティブの想定年収・求人倍率の月次推移
各月の最終週時点のデータです。前月比は直前の月との差分を示します。
| 月 | 想定年収 | 前月比 | 求人倍率 | 前月比 |
|---|---|---|---|---|
| 2026年5月 | 475万円 | — | 5.24倍 | — |
| 2026年6月 | 475万円 | 前月比 ±0 | 5.24倍 | 前月比 ±0 |
従来手法に対するクラウドネイティブの相違点
クラウドネイティブへの移行を成功させる前提となるのが、従来のシステム構築手法や単なるクラウド移行との違いを正しく理解しておくことです。ここでは、インフラ設計やアプリケーション開発手法における根本的な相違点を明確にします。
従来システムとクラウドネイティブにおける傾向の違いを比較した表は、以下の通りです。
| 比較項目 | 従来手法で多い傾向 | クラウドネイティブで選ばれやすい傾向 |
|---|---|---|
| インフラの運用方針 | 物理・仮想サーバーを固定的に構築し保守する | コンテナなどを活用し環境に応じて柔軟に構成する |
| 設計思想 | 既存システムの仕様を維持することを優先する | 自動化・疎結合・可観測性・回復性を重視する |
| 開発スタイル | 全体が一体となったモノリシック開発が主流 | サービスごとに疎結合へ分割する分散開発が選ばれやすい |
ここで示したコンテナやマイクロサービスは代表的な選択肢であり、クラウドネイティブに必須の技術要素ではありません。サーバーレスやモジュラーモノリスなど要件に応じた構成を選びながら、自動化や可観測性、回復性といった設計原則を満たすことが出発点です。
このように、インフラの利用形態から開発プロセスまで、あらゆるレイヤーで設計思想を見直す視点が求められます。具体的にどのような違いがあるのか、2つの側面から順に確認していきます。
既存の仕組みをそのまま載せるクラウド対応から脱却する
クラウドネイティブと混同しやすい概念が「クラウド対応(リフト＆シフト)」です。既存のオンプレミス環境で稼働していたシステムを、そのままクラウドの仮想サーバーへ移し替えるアプローチを指します。
なお「クラウドファースト」は、新規開発やシステム更新の際にクラウド利用を優先的に検討する調達・戦略上の方針であり、アーキテクチャの設計思想を指すクラウドネイティブとは別の軸の概念です。
リフト＆シフトでクラウドへ移行した後は、必要に応じてクラウド環境の特性を活かした設計へ見直すことによって、俊敏性を高めやすくなります。
クラウドに最適化されたモダンなアプリケーション開発の基準として、代表的なガイドラインが公開されています。
The twelve-factor app is a methodology for building software-as-a-service apps
出典:The Twelve-Factor App
この設計手法に則ることは、クラウド上で効率的に動作するアプリケーションを開発するうえでの実践的な指針です。
クラウド対応とクラウドネイティブにおける具体的な運用上の相違点は、以下の通りです。
- インフラの管理手法が手動からコードによる自動管理へと変化する点
- ハードウェアの制約から解放されて需要に応じた伸縮性が得られる点
- システムの障害を自動で検知して自己修復する仕組みが整う点
単にサーバーの場所を変えるだけではなく、クラウドの恩恵を最大限に受けるための再設計が求められます。この変化を正しく捉えることによって、日々の運用にかかる手間の削減にもつながります。
全体が密結合した従来型のモノリシック開発から移行する
従来のシステム開発では、多くの機能を1つの巨大なプログラムにまとめるモノリシック開発が長らく主流でした。
しかし、この手法では一部の機能を修正するだけでもシステム全体に影響が及んでしまいます。そこで、機能ごとにサービスを細分化して疎結合にするマイクロサービスへの移行が有効な選択肢となります。
変化に強いシステムを構築するうえでは、開発手法そのものを見直す視点も押さえておきたいポイントです。モノリシック開発からクラウドネイティブな開発へ移行する主なメリットは、以下の通りです。
- サービスごとに独立して開発やデプロイを迅速に進められる点
- 一部で障害が起きた場合でも他のサービスへの波及を防げる点
- 特定の機能だけをピンポイントで拡張して負荷に対応できる点
このように、システムが密結合した状態から疎結合へと移行することによって、開発効率が飛躍的に向上します。
アプリケーションの価値をユーザーへ素早く届けるためにも、疎結合なアプローチを標準に据える必要があります。
クラウドネイティブを導入するメリット
クラウドネイティブの設計思想を自社のシステム開発へ取り入れ、サービス選定や監視体制、デプロイ戦略まで適切に設計・運用したときに得られるのが、ビジネスの成長を加速させる複数のメリットです。
ここでは、従来の開発手法では実現が困難であった3つの主要な導入メリットを詳しく紹介します。本章で解説する具体的なメリットの一覧は、以下の通りです。
- 需要の変化に合わせてリソースを自動で拡張する
- 障害が発生してもシステム全体を停止させずに復旧する
- 新機能のリリースを迅速に実施する
これらのメリットを組み合わせて享受することによって、市場の変化へ素早く追随しながら企業の競争力を高められる点が、クラウドネイティブを選ぶ大きな理由です。
需要の変化に合わせてリソースを自動で拡張する
クラウドネイティブなシステムでは、監視指標や閾値を適切に設定することによって、アクセス数の急増といった需要の変化に対して自動的にリソースを増減させる仕組みを構築できます。
この自動拡張(オートスケーリング)によって、需要変動のたびに手動でリソースを増減させる作業は削減できますが、監視指標の設計や上限値の設定、基盤側の容量計画は引き続き必要です。
アクセス増加時におけるリソースの拡張フローは、以下の通りです。
- 負荷状況の監視システムがCPUやメモリの利用率上昇を検知する点
- あらかじめ設定した閾値を超えた場合に自動でコンテナが追加される点
- アクセスが減少した時間帯には自動で不要なコンテナが削減される点
適切な指標・閾値・上限値を設計しておくことによって、需要変動に応じた可用性とコストの最適化を図りやすくなります。ただし効果は設計内容や負荷特性によって変わるため、運用しながら継続的に調整していく必要があります。
アクセス数の予測が難しい新規事業やキャンペーンを頻繁に実施するWebサービスの運用では、特に効果を実感しやすい仕組みです。
障害が発生してもシステム全体を停止させずに復旧する
適切な障害分離や冗長化を設計したクラウドネイティブ環境では、一部の機能にトラブルが生じてもシステム全体の停止を防ぎやすくなります。
マイクロサービスやコンテナを活用して各機能を独立させ、監視や自己修復の仕組みを組み合わせることによって、局所的なエラーに留めやすくなります。
障害発生時の影響範囲と復旧フローの比較は、以下の通りです。
| 比較項目 | 従来のモノリシックシステム | クラウドネイティブシステム |
|---|---|---|
| 障害時の影響範囲 | システム全体に影響が及びやすい | 設計次第で局所的な影響に抑えやすい |
| 復旧の手法 | 手動での原因究明と再起動 | コンテナの自動再起動による自己修復 |
この表のように、障害分離や冗長化、監視の設計を適切に行うことによって、影響を最小限に抑えながら迅速な復旧を目指せます。ただし、自己修復の仕組みはコンテナの再起動などを自動化するものであり、可用性そのものを保証するわけではありません。
24時間365日止めることが許されない社会インフラや大規模なECサイトの運用において、大きな効果を発揮する設計です。
新機能のリリースを迅速に実施する
競合他社に先駆けて新しいサービスを提供するためには、開発からデプロイまでのサイクルを高速化する必要があります。
クラウドネイティブな開発スタイルを導入すれば、各機能を個別にアップデートできるため、リリースの頻度を高めやすくなります。
リリースの迅速化を支える具体的な要素は、以下の通りです。
- 開発したコードを自動で検証・デプロイするCI/CD環境が整う点
- 他の機能への影響を懸念することなく、独立してアップデートが可能な点
- デプロイ戦略やロールバック手順をあらかじめ設計しておくことで、不具合が見つかった場合でも以前のバージョンへ迅速に切り戻せる点
このように、テストやデプロイのプロセスを自動化することによって、エンジニアの作業負担を大きく削減できます。市場の反応を見ながら、スピーディーに機能追加を繰り返すモダンなアプローチを実現しやすくなります。
クラウドネイティブが抱える導入時の課題
クラウドネイティブの導入は多くのメリットをもたらす一方で、解決すべきハードルもいくつか存在するのが実情です。事前に課題を正しく把握しておくことが、スムーズなシステム移行の第一歩となります。
高度な専門知識を持つITエンジニアを確保する
クラウドネイティブ環境を構築・運用するためには、従来のシステム開発とは異なる先端技術への深い理解が必要です。コンテナやマイクロサービスの設計、自動化ツールの操作など、習得すべき技術領域は多岐にわたります。
このような高度な技術スタックを乗りこなせる専門人材は、多くの企業の採用現場で不足感が指摘されやすい領域です。そのため、外部からの採用だけではなく、社内での継続的な教育体制の整備が求められます。
人材不足に対応するための具体的な育成・確保のアプローチは、以下の通りです。
- 最新技術に関する社内研修や勉強会を定期的に開催する点
- 資格取得支援制度を設けて学習の動機付けを図る点
- 外部の専門会社と提携してノウハウの共有を受ける点
自社で内製化を進めるためにも、中長期的な視点での人材投資が成功への近道となります。スキル向上を後押しする文化を築く取り組みは、エンジニアの定着やモチベーション維持にも役立ちます。
共有責任モデルに基づいたセキュリティ対策を確立する
クラウド環境のセキュリティを考えるうえで避けて通れないのが、クラウド事業者と利用者の責任範囲を明確にする考え方です。この原則は「共有責任モデル」と呼ばれ、双方が協力して安全な環境を維持する枠組みです。
IaaS・PaaS・SaaSなど利用するサービスの形態によって、責任の境界は変わります。一般的にはインフラ層の安全性を事業者に任せられる一方で、データやアプリケーションの安全確保は利用者側の責任範囲が大きくなります。
共有責任モデルにおける一般的な責任境界を整理した表は、以下の通りです。
| 責任の主体 | 担当するセキュリティ範囲 |
|---|---|
| クラウド事業者 | 物理サーバー、ハイパーバイザー、データセンターの物理的保護 |
| サービス利用者 | データの暗号化、アクセス権限管理、アプリケーションの脆弱性対策 |
この表の通り、利用者が管理すべき領域をあらかじめ明確にして対策を施す姿勢が欠かせません。ただし、実際の責任範囲は採用するクラウドサービスの種類や設定によって変動します。
事業者の提供する強固なインフラを過信せず、契約するサービスごとの共有責任モデルを必ず確認したうえで設計を進める必要があります。
クラウドネイティブを構成する中核的な技術
クラウドネイティブを実現するアプローチとしては、複数の技術・設計パターンが代表的な選択肢です。これらの技術を適切に採用することによって、開発のスピードやインフラの柔軟性が高まります。
クラウドネイティブなシステムを支える代表的な4つの中核技術を比較した表は、以下の通りです。
| 中核技術 | 主な役割 |
|---|---|
| コンテナ | OS上に独立した実行環境を構築してアプリケーションを仮想化する技術 |
| マイクロサービス | システム全体を複数の小さな独立したサービスに分割して開発する手法 |
| サービスメッシュ | 細分化されたサービス同士の複雑な通信やセキュリティを制御する仕組み |
| 宣言型API | インフラのあるべき状態を定義して変更適用を自動化するインターフェース |
これらの技術はすべてが必須というわけではなく、自動化や可観測性、回復性といった設計原則を満たすために、課題や要件に応じて選択・組み合わせることが求められます。ここからは、それぞれの技術が持つ具体的な特徴や果たす役割について、詳しく解説します。
アプリケーションの動作環境を仮想化するコンテナ
コンテナとは、アプリケーションの実行に必要なプログラムや設定ファイルを1つにまとめる軽量な仮想化技術です。
従来の仮想マシンと比較してホストOSのカーネルを共有するため、起動が高速で消費するリソースも抑えられます。
開発環境と本番環境の差異をなくすコンテナの主なメリットは、以下の通りです。
- 環境差異を減らし、同じ設定であれば動作の一貫性を保ちやすいポータビリティの高さ
- イメージや基盤構成によっては数秒単位での起動・停止も可能な運用の俊敏性
- 1台のサーバー上で多数の実行環境を高密度に稼働できる効率性
このポータビリティの高さによって、開発者は環境依存のトラブルを減らせます。コンテナの規格や実行環境を管理するデファクトスタンダードとしては、DockerやKubernetesなどのオープンソースソフトウェアが世界中で広く利用されています。
サービスごとにシステムを細分化するマイクロサービス
マイクロサービスとは、システムを機能ごとに分割し、それぞれをAPIで連携させる設計手法です。各サービスが独立しているため、特定の機能だけを修正してデプロイする作業も容易になりました。
システムをマイクロサービス化して得られる具体的な効果は、以下の通りです。
- 機能ごとに最適なプログラミング言語やデータベースを自由に選択できる点
- 開発チームをサービスごとに細分化して並行開発を加速できる点
- 一部のサービスに障害が発生してもシステム全体の停止を防げる点
独立したサービスが相互に連携することによって、変化の激しいビジネス要件にも柔軟に対応できるアーキテクチャを確立できます。
ただし、サービス間のネットワーク通信が急増するため、システム全体の複雑性が増すという側面も十分に理解しておかなければなりません。
サービス間の通信を適切に制御するサービスメッシュ
サービスメッシュとは、マイクロサービス間のネットワーク通信を可視化して制御する専用のシステムインフラ層です。アプリケーションのコードを変更することなく、通信の暗号化やトラフィックの制御を自動で適用できます。
サービスメッシュが提供する代表的な管理機能は、以下の通りです。
- 特定のサービスに通信を偏らせないための高度なロードバランシング機能
- 障害が発生したサービスを自動で切り離して被害を防ぐサーキットブレーカー機能
- どのサービス間で遅延が発生しているかを瞬時に視覚化するトレース機能
これらの機能を活用することによって、複雑になりがちなマイクロサービス全体の運用管理コストを大きく低減できます。製品としてはIstioやLinkerdが有名であり、大規模なクラウドネイティブシステムを中心に導入が進んでいます。
ただし、サービスメッシュは必須の構成要素ではありません。システムの規模や通信要件を踏まえて採否を判断する任意の基盤として位置づけられます。
インフラ環境の変更を自動化する宣言型API
宣言型APIとは、インフラの最終的な「あるべき姿(Desired State)」を定義形式で指定する仕組みです。Kubernetesなど対応する基盤では、これを継続的に監視するコントローラーが実際の構成とのズレを検知し、自動で修正します。
IaC(Infrastructure as Code)は、インフラ構成をコードとして管理する手法全般を指す言葉です。宣言型だけではなく、命令型の記述方式も含む点で宣言型APIとは対象の範囲が異なります。
宣言型APIとIaCを組み合わせて活用するメリットは、以下の通りです。
- インフラの構成がコードとして記述されるため、バージョン管理や変更差分の把握がしやすくなる点
- 対応するコントローラーを導入していれば、あるべき状態と現実の構成にズレが生じた際に自動で修正が走る点
- 構成管理ツールとの連携によってデプロイプロセス全体の自動化を進めやすくなる点
ただし、依存するコンテナイメージのバージョンや外部サービス、秘密情報の管理状況によって、再現性は左右されます。バージョン固定や外部依存の管理といった前提を整えたうえで運用する姿勢が欠かせません。
これらの4つの中核的な技術を深く理解し、自社の要件に適合する形で組み合わせることが、クラウドネイティブの真価を引き出す鍵となります。
クラウドネイティブに関するよくある質問
クラウドネイティブの導入や検討を進めるにあたり、多くの企業が抱きやすい代表的な疑問と、その回答をまとめました。
CNCFが定義するクラウドネイティブの基準とは何ですか？
CNCFの公式定義では、パブリッククラウドなどの動的な環境において、スケーラブルなアプリケーションを構築・実行する能力が重視されます。システムに回復性・管理性・可観測性をもたらし、堅牢な自動化を実現する設計思想が基準とされています。
具体的な技術例として、コンテナやサービスメッシュ、マイクロサービス、宣言型APIが挙げられますが、これらは定義を満たすための例示であり、個別技術の一律採用が基準ではありません。詳細な定義文はCNCF公式のCloud Native Definitionで確認できます。
クラウドネイティブの導入を成功させる組織の特徴はありますか？
クラウドネイティブの導入を成功させる組織は、失敗を恐れずに新しい変化を柔軟に受け入れる文化を共通して持っているのが特徴です。従来の硬直した役割分担から脱却し、開発と運用が緊密に連携する体制の整備が不可欠です。
また、意思決定の権限を現場のチームに委譲し、自律的なサービス開発を促進する仕組み作りも進められています。このような組織的な変革への取り組みが、技術の真価を引き出す強固な土台です。
専門エンジニアを育成するための有効な方法はありますか？
コンテナやマイクロサービスなどの広範な技術体系を学ぶため、資格取得の支援制度や社内研修を整備する手法が有効です。これに加えて、座学だけに留まらず、実際のプロジェクトで手を動かす機会の提供が求められます。
さらに、技術の習得だけではなく、システム運用の現場で自律的に課題を設定して解決に導く能力を養う方針が推奨されます。ユーザーを深く理解し、迅速な価値提供を追求するマインドを育むアプローチが効果的です。
ITやプログラミングに関するコラム
【Python】FastAPIで料金プラン見積もりシミュレーターを作ってみた
【Python】pandasとmatplotlibで在庫データのABC分析と構成比を可視化してみた
【Python】Flaskで社内FAQをカテゴリ検索できるWebアプリを作ってみた
【Python】argparseでJSON整形・構文検証・キー検索CLIを試してみた
【Python】NumPyとmatplotlibでモンテカルロ法による円周率推定と収束過程の可視化を試してみた
【Python】Playwrightでスクレイピングを試してみた
【CSS】notで複数の件を除外する方法
【Git】remote設定を変更する方法
【VBA】コメントアウトを設定する方法
x86とx64の違いを分かりやすく解説
ITやプログラミングに関するニュース
VercelがAI GatewayにSeedream 5.0 Proを追加、AI SDKのモデル指定で画像生成と編集が可能に
AWSがAmazon LocationのPlaces APIを強化、住所表記の指定と移動手段別の検索が可能に
VercelがトレースにTree・Waterfallビューを追加、ログ画面で処理の階層と所要時間を確認可能に
Googleがエージェント評価の再考を提唱、難易度を情報量で測るDiscovery Benchを解説
Google CloudがCloud Runサンドボックスを公開プレビューで提供、サービスヘルスは一般提供に
Google Cloud EMEAが英国金融の重要第三者に指定、イングランド銀行・PRA・FCAの直接監督下に
AWS DMS Schema ConversionがSQL Serverのオフライン変換に対応、ソースDBへ接続せずスキーマを変換可能に
EC2 G7インスタンスが米国東部（バージニア北部）で利用可能に、G6比でAI推論性能が最大4.6倍
SageMaker HyperPodが継続プロビジョニングでのAMIベース構成に対応、S3のスクリプト管理なしでSlurmクラスターを作成可能に
AWSがEMR on EKSでSparkトラブルシューティングエージェントに対応、失敗ジョブの原因分析を自然言語で依頼可能に
