Cloud

概要 Nvidiaは、ソフトバンクグループ傘下でデータセンター・電力インフラを手がけるSB Energyに15億ドルを出資し、オハイオ州で建設が進むOpenAI向け大型データセンター「PORTS-Pike Technology Campus」のAIコンピュート基盤を独占的に供給する提携を発表した。当初、The Informationの報道をもとにCNBCなどが伝えたところでは、Nvidiaは最大30億ドルの出資を検討しており、契約締結時に半額、SB EnergyのIPO実施時に残り半額を支払う案が浮上していた。その後8月17日にNvidia・SB Energy・OpenAIの3社が正式に提携を発表し、出資額は15億ドルに確定した。 出資の経緯と支援内容 報道によれば、Nvidiaは出資に加えて、土地取得・電力確保・建屋(シェル)建設に対する信用支援も提供する。当初はオハイオ州プロジェクト向けに最大1,050億ドル規模の信用枠を用意する案が伝えられていたが、その後Wall Street Journalの報道では、当初計画されていた2,500億ドルから縮小し、1,200億ドル未満の保証にとどめる方向だと報じられている。SB Energyはソフトバンクグループおよび顧客であるOpenAIからも出資を受けており、2019年設立の同社は早ければ9月にも新規株式公開(IPO)を計画し、調達額は50億ドル以上になる見通しとされている。なお、ソフトバンクは以前58億ドル相当のNvidia株式を保有していたが、2025年11月に売却済みである。 データセンターの規模と地域への影響 PORTS-Pike Technology Campusは、オハイオ州パイク郡にある米エネルギー省所有の旧ウラン濃縮施設(ポーツマス・ガス拡散プラント)跡地に建設される。初期段階で4.25ギガワット、将来的には最大8ギガワットまで拡張可能な規模を計画しており、OpenAIはまず4.25IT-GW分の容量を利用する予定で、NVIDIAには残る3.75IT-GW分を追加確保するオプションがある。電力供給のためSB Energyとソフトバンクは9.2ギガワット規模の天然ガス発電所を含む10ギガワット超の新規発電設備を建設する計画で、建設費は330億ドル規模になる見通し。施設は2028年以降、段階的に稼働を開始する予定だ。地域社会向けにはSB Energyが4,000万ドル、OpenAIが4,000万ドルを上乗せしたコミュニティ基金(総額8,000万ドル)を設立し、数万人規模の雇用創出が見込まれている。 背景と今後の見通し Nvidia CEOのジェンスン・フアン氏は「AI自体がインフラストラクチャーとなりつつあり、土地・電力・建屋の確保が極めて重要になっている」と述べ、チップ製造にとどまらず物理インフラへ投資領域を広げる戦略的な狙いを強調した。OpenAI側も、数百万人がAIを活用できる大規模拠点になるとの期待を示している。一方で、天然ガス発電プラントの建設費はここ2年で66%上昇しており、複数の巨大データセンターが同時期に稼働すれば天然ガスの需給が逼迫し、一部地域で価格が3倍に高騰する可能性も指摘されている。AIインフラ需要の急拡大を背景に、Nvidiaのような半導体大手が電力・データセンター事業に直接資本を投じる動きは今後さらに広がる可能性がある。

概要 GitHubは8月17日午前9時40分(米東部時間、日本時間同日22時40分)頃から、世界的な大規模障害に見舞われた。GitHub自身がWebサイト・APIへのリクエストの約2割がエラーとなっていることを報告し、Actions、プルリクエスト、Webhooks、Issues、認証機能(SAML/OIDC)、さらにGitHub Copilotまで幅広いサービスが影響を受けた。障害は3時間19分にわたって続き、開発者のコーディングやCI/CDワークフローに世界規模で支障をきたした。運営元のMicrosoftも障害の発生を確認しており、傘下のCopilotやTeamsでも数百件規模の問題報告が上がった。GitHubは全世界で1億8000万人規模のユーザー(開発者)を抱えるプラットフォームであり、今回の障害はその基盤全体に影響を及ぼした可能性がある。 影響範囲とタイムライン 障害発生直後、第三者の障害追跡サービスDownDetectorには一時ピークで約3000件のダウン報告が寄せられた。エラー率はサービスによって差があり、Webサイト・APIへのアクセスでは約20%、リポジトリのアーカイブダウンロードでは約50%に達した。一方、PackagesとCodespacesは障害の影響を受けずに稼働を続けたが、Git操作やPagesも障害発生からやや遅れて一時的に影響を受けた。米東部時間12時36分、GitHubは「問題のあるコンポーネントを特定した」と発表して修正措置を実施し、同12時45分にはダウン報告が数百件規模まで減少するなど、回復の兆しが見え始めた。GitHubは修正措置の実施後も「強い回復の兆候」を示しているとして、完全復旧に向けた対応を続けた。 背景と今後の課題 今回の障害でGitHubは具体的な根本原因を公表しておらず、記事執筆時点でも調査が継続中とされている。世界中の開発チームが日常的にコード管理、CI/CD、AIコーディング支援を単一プラットフォームに依存している現状において、GitHubのような中核インフラで発生する大規模障害は、開発生産性やリリース作業に直接的な打撃を与える。Microsoft傘下のCopilotやTeamsにも波及したことは、GitHubの基盤がMicrosoftの他サービスとも密接に連携している実態を改めて浮き彫りにした。今後、GitHubから正式な事後分析(ポストモーテム)が公開されるかが注目される。

概要 Cloud Native Computing Foundation(CNCF)は8月17日、Kubernetes上でデータ処理からモデル開発、学習、推論までAI・機械学習のライフサイクル全体を標準化するオープンソースプラットフォーム「Kubeflow」が、CNCFの卒業(Graduation)段階に到達したことを発表した。卒業はCNCFホスティングプロジェクトの中で最も成熟した段階に位置づけられ、技術的な安定性と本番環境での運用実績が公式に認定されたことを意味する。2017年にGoogleで創設され、2023年にインキュベーションプロジェクトとしてCNCFに加わったKubeflowは、6,600人以上の貢献者と1,000を超える組織の参加、33,000以上のGitHubスターを集め、この節目に到達した。 卒業基準と技術的特徴 CNCFの卒業段階に到達するには、第三者機関によるセキュリティ監査の完了、正式なステアリングコミッティの設置、CNCF行動規範の採択、Core Infrastructure Initiative(CII)ベストプラクティスバッジの取得など、複数の厳格な基準を満たす必要がある。Kubeflowはこれらすべてをクリアした。プラットフォームは監視にPrometheus、モデル提供と機能管理にKServeとFeast、ジョブキューイングにKueue、セキュアな通信にIstioといったクラウドネイティブエコシステムの主要コンポーネントと連携し、AI・MLOps運用のための包括的な基盤を構成している。 採用状況と関係者のコメント Bloomberg、NVIDIA、Red Hat、LinkedIn、Spotifyといった大手企業がKubeflowのサブプロジェクトを本番環境で活用しており、PyPI経由での累計ダウンロード数は約2億6,000万に達している。CNCFの最高技術責任者Chris Aniszczykは、Kubeflowが「企業向けAIワークロードの成熟した選択肢を実証した」と評価。共同創設者のDavid Aronchickは、9年前のシンプルなデモから始まったプロジェクトが、今や多くのチームと事業を支える存在へと成長したことに謝意を示した。Red Hatのシニアプリンシパルソフトウェアエンジニアであるフランシスコ・アルセオ氏は、KubeflowがオープンでKubernetesネイティブな基盤の上に本番稼働可能なAIインフラを構築できることを証明したと述べ、特定少数のベンダーに将来を委ねられない組織にとって、その開放性とポータビリティは不可欠だと強調している。 卒業の意義と今後の展望 今回の卒業は3つの側面で意味を持つ。第一に、調達プロセスやリスク評価において「CNCF卒業」というステータスがインキュベーション段階よりも強い信頼性を持つこと。第二に、CNCFのプロジェクトポートフォリオが従来のインフラ領域を超え、エンドツーエンドのAIプラットフォームを提供できる成熟度に達したこと。第三に、ベンダーロックインを避けオープンな基盤を求める規制対応企業にとって、AI主権の実現手段となることだ。今後のロードマップでは、大規模言語モデル(LLM)のオーケストレーション、ファインチューニング機能の強化、大規模データ工学、エージェンティックワークロードへの対応が重点領域として挙げられており、コミュニティは次の成長フェーズを見据えている。

概要 テキサス州のグレッグ・アボット知事は8月3日、送電網運営者ERCOT（Electric Reliability Council of Texas）と州公益事業委員会（PUCT）に対し、電力網への接続を申請しているデータセンタープロジェクトを対象とした包括的な監査の実施を指示した。対象は250〜300件、主にデータセンター案件で、その将来的な電力需要の合計は200ギガワットに達する。これは前月に記録されたERCOTのピーク需要の2倍以上に相当する規模であり、AIブームに伴う電力インフラへの圧力がテキサス州で政治問題化していることを示している。ERCOTの接続申請キューには合計1,800件以上（うち9割がデータセンター）が並んでおり、その潜在需要は474ギガワット超と、州のピーク需要の5倍規模に膨れ上がっている。 監査の内容と対象 監査では、開発事業者に対し以下の情報開示が求められる。 受給している税制優遇措置の内容 電力消費計画および自家発電計画 水使用量と冷却設備の運用状況 地域社会への影響を軽減するための取り組み 施設の所有関係 アボット知事は「（データセンター事業者は）テキサスの一般家庭にコストを転嫁したり、生活の質に悪影響を及ぼしたりしてはならない」と述べており、急増するデータセンター需要が既存の電力利用者に負担を強いることのないよう、透明性を確保する狙いがあるとみられる。監査の完了には数か月を要する見込みで、ERCOTは通常の接続検討プロセスに先立ち、この監査を最優先事項として扱うとしている。最初のバッチ調査は2027年4月までの完了を目指すという。 政治的背景と業界の反応 背景には、データセンター開発の急拡大に対する州内の反発の高まりがある。一方で、少なくとも43社のデータセンター関連企業がアボット知事のこの方針を公に支持しており、業界側も一定の理解を示している格好だ。また、ERCOTが計画する765キロボルトの新設送電線についても、土地所有者からの強い反対に直面しており、州議会議員やダン・パトリック副知事は、議会による審査が済むまで許可を出さないよう求めている。データセンターの電力需要問題は、送電インフラ整備を巡る政治的対立とも絡み合いながら、テキサス州の重要な政策課題となりつつある。 今後の見通し 今回の監査は、AI関連投資の急拡大によって電力網への接続要請が実需をはるかに上回る規模で殺到している現状に対し、州が実態把握とコントロールを試みる動きと位置づけられる。監査結果は今後の接続許可の可否やインフラ投資の優先順位付けに影響を与える可能性が高く、テキサス州に限らず、AI向けデータセンターの電力需要が急増する他州・他地域における規制のあり方にも波及する可能性がある。

概要 AWSは2026年8月12日、IAMロールの設定を自動化する新機能「IAM Role Manager」を一般提供開始した。これまでAWSの各サービスを利用する際には、そのサービスが必要とする権限を持つIAMロールを利用者自身が手動で作成・設定する必要があり、権限の過不足や設定ミスが起こりやすいポイントの一つだった。IAM Role Managerはこの作業を自動化し、対応するサービスコンソールでサービスを設定する際に、Role Managerがデフォルトのロールを自動作成するか、既存の適切なロールを再利用する仕組みを提供する。初回ローンチではAWS LambdaやAmazon EventBridgeを含む6つのサービスコンソールに対応している。 仕組みとユーザーによる制御 IAM Role Managerは、AWSが管理するテンプレートを展開して必要な権限を自動構成する。ここで作成されるロールはあくまで標準的なIAMロールであり、利用者が完全にコントロールできる点が特徴だ。Role Managerが作成したロールは他のロールと区別して識別できるようになっており、いつでも機能自体の有効・無効を切り替えたり、展開されたテンプレートの内容を検査したりすることが可能。自動作成後に権限が広すぎると感じた場合は、IAM Access Analyzerを使って権限を必要最小限まで絞り込むこともできる。 利用可能リージョンと今後の展望 IAM Role Managerは、AWS GovCloud (US) RegionsおよびChina Regionsを除くすべてのAWSリージョンで利用可能となっている。手動でのIAMロール設定はAWS利用における定型作業でありながらミスの温床にもなりやすく、今回の自動化により初期構築のハードルが下がるとともに、最小権限の原則に沿った運用がしやすくなることが期待される。対応サービスは現時点では6つにとどまるが、今後の展開でカバー範囲が広がるかが注目される。

概要 ドイツのセキュリティ企業QUIRSOの調査により、中国語圏の攻撃者とみられるハッカー集団がVMware vCenterの重大な脆弱性を悪用し、世界47カ国361件のIPアドレスでroot権限を奪取したうえ、一部の環境でBabuk派生のランサムウェアを展開していたことが明らかになった。悪用対象となったのは、ディレクトリトラバーサルの脆弱性であるCVE-2026-59310(CVSSスコア9.8)で、Broadcomは2026年7月29日にパッチをリリースしていた。しかし公開開示からわずか5日後には実際の攻撃キャンペーンが始まっており、パッチ適用前の環境が広範囲で悪用された形だ。あわせて認証回避の脆弱性CVE-2026-59309の悪用も8月1日時点で確認されている。 攻撃の手口 攻撃者はvCenterの脆弱性を突くことで、rootコンテキストでの即座の非対話的コード実行を獲得した。侵害は段階的に進み、まず「zz-poc59310-syslog.log」という名の不正なcronファイルを介して初期アクセスを確立し、続いてcurlやwgetで外部サーバー(5.34.177[.]38:9861)から「linuxFile」というバックドアインプラントを取得、systemdやcronを使って永続化させている。このlinuxFileインプラントはWebSocketチャネル(ws://intel.se9ly9upbhay.shop:8080/ws)を通じてC2サーバーと通信し、C2アドレスはXOR難読化された状態で保持されていた。 このほかにも、攻撃者はSSH公開鍵を追加して遠隔アクセスを確立したり、「vmware-perf-update.jsp」というJSP形式のWebシェルを設置したうえでvSphere SSO管理者グループへ不正アカウントを追加するなど、複数の手法を組み合わせて侵害を拡大させていた。最終段階では、ファイルを".babyk"拡張子で暗号化するBabuk派生のランサムウェアが展開されたケースも確認されている。QUIRSOは、このランサムウェア展開が防御側の目を本来の侵入活動からそらす「煙幕」として機能した可能性を指摘しており、単なる金銭目的の攻撃ではなく、より深い偵察や情報窃取が並行して行われていた可能性を示唆している。 攻撃者の特定と被害範囲 QUIRSOは、攻撃者作成スクリプト内に残された中国語のアーティファクトや、中国のセキュリティ研究成果の再利用とみられる痕跡、UTC+08:00タイムゾーンでの活動パターンなどを根拠に、「中程度の確信度」で中国語話者の脅威行為者による関与と評価している。被害は47カ国361件のIPアドレスに及び、国別ではドイツ(55件)、米国(41件)、トルコ(38件)、イラン(26件)、フランス(25件)の順に多かった。また8月14日には、侵害の痕跡を系統的に消去する目的とみられるツールを含むGitHubリポジトリ「pikpak0066/tmpclean」も発見されており、攻撃者が痕跡隠蔽にも注力していたことがうかがえる。 対策と今後の展望 Broadcomは7月29日の時点でCVE-2026-59310に対するパッチを既にリリースしており、未適用の環境では早急な適用が強く推奨される。パッチ公開からわずか5日で実際の悪用が始まった事実は、公開されたパッチ情報から攻撃者が脆弱性の詳細を迅速に解析し武器化する能力を持つことを改めて示している。vCenterを運用する組織は、パッチ適用だけでなく、不審なcronジョブやSSH鍵の追加、未知のWebシェルの有無など、侵害の兆候を個別に確認することが求められる。

概要 マクドナルドやVodafone、Kyndrylなど大手企業9社が、侵害されたAzure認証情報を悪用した大規模なデータ窃取キャンペーンの被害を受けたことが判明した。攻撃者は「TheHatman」というハンドルネームでダークウェブフォーラムに出没しており、侵害した認証情報を使ってAzure/Entraポータルから直接従業員データをダウンロードしたと主張している。被害企業と流出件数は、マクドナルドが約170万件、Tata Consultancy Services(TCS)が約80万件、Vodafoneが約42万5,000件、HCL Technologiesが約25万件、IHGが約18万5,000件、Kyndrylが約17万件、Gap Inc.が約8万件、Hexawareが約2万件、Wyndham Hotelsが約9,000件と、合計で数百万件規模の企業内部データが対象になったとされる。 窃取されたデータと悪用リスク 流出したデータには、従業員の氏名、企業メールアドレス、電話番号、物理住所に加え、従業員ID、職務、所属部門、マネージャー情報といった組織構造を示す情報が含まれる。特に懸念されているのは、サービスアカウントやグローバル管理者アカウントに関する情報が含まれている点で、これが悪用されれば単なる個人情報漏えいにとどまらず、企業システムへの不正アクセスや権限昇格につながる可能性がある。セキュリティ企業Hudson Rockの調査によれば、今回の侵害は情報窃取型マルウェア(インフォスティーラー)によるセッショントークンの窃取と関連している可能性が指摘されているほか、フィッシングキャンペーン、多要素認証(MFA)の未導入、APIの悪用といった侵入経路の可能性も挙げられているが、具体的な侵入手法は依然として特定されていない。 想定される影響 窃取された組織構造データや従業員の連絡先情報は、ビジネスメール詐欺(BEC)やスピアフィッシングキャンペーンの実行に直接利用される恐れがある。攻撃者が従業員の役職やマネージャー関係を把握していることで、なりすましメールの説得力が増し、標的型攻撃の成功率が高まる可能性がある。またサービスアカウントやグローバル管理者情報の流出は、クラウド環境における権限昇格攻撃の足がかりとなりうるため、影響を受けた各社は認証情報のローテーションやアクセス権限の見直しといった追加的な対応を迫られている。 今後の対策 Hudson Rockは、インフォスティーラー感染によって侵害された認証情報を早期に検出する仕組みや、サイバー犯罪インテリジェンスの活用を組織に推奨している。今回の事案は、クラウド管理ポータルへのアクセスにおいて多要素認証を徹底することや、エンドポイントでのマルウェア感染対策、セッショントークンの適切な管理がいかに重要かを改めて示す事例となった。攻撃者による具体的な侵入経路の特定と、被害企業側の詳細な調査結果の公表が今後注目される。

概要 Google Cloudは8月11日、耐量子計算機暗号(Post-Quantum Cryptography, PQC)への移行に関する詳細なロードマップを公開した。ブログ記事はJai Haridas氏(VP/GM, Regulated and Sovereign Cloud)とMichael Bachman氏(VP/GM, Cloud Foundations)が執筆し、2029年までの完全対応を目標に、「Store Now, Decrypt Later(SNDL)対策」「完全性・否認防止」「暗号的敏捷性を備えた基盤・鍵管理」という3つの領域に分けた段階的な移行計画を示している。背景にあるのは「Harvest Now, Decrypt Later(HNDL)」と呼ばれる脅威で、攻撃者が現在のうちに暗号化通信を記録・保存しておき、将来量子コンピュータが実用化された時点でまとめて復号するリスクへの対応が急務となっている。 すでに実装済みの機能も多い。google.comおよび*.googleapis.comのAPIエンドポイントはFIPS 203として標準化されたML-KEMのハイブリッドモードに対応し、Application/Proxy Load BalancerではX25519MLKEM768によるTLS 1.3の量子安全な鍵交換をオプトインで提供している。またCloud KMSでは鍵カプセル化のML-KEM、署名用のML-DSA(FIPS 204)・SLH-DSA(FIPS 205)が一般提供(GA)済みで、Google内部のサービス間通信を暗号化するALTS(Application Layer Transport Security)についても2025年にPQC対応を完了したという。 技術的な詳細 Google CloudはPQCアルゴリズムとして、NISTが標準化した鍵カプセル化メカニズムのML-KEM(FIPS 203)、デジタル署名のML-DSA(FIPS 204)とSLH-DSA(FIPS 205)を採用する。現行のX25519と組み合わせるハイブリッドモード(X25519MLKEM768)を採用することで、既存システムとの互換性を保ちながら段階的にPQCを導入できる設計になっている。またPQC署名はサイズが大きく証明書チェーンの検証に影響を与えるため、ChromeやCloudflareと連携してMerkle Tree Certificatesの実験に取り組んでおり、IETFのPLANTSワーキンググループでの標準化にも関与しているという。 ハードウェア面では、チップレベルの検証を行うCaliptra v2.1、オープンソースのRoot of TrustであるOpenTitan(量子安全ブートは2025年に対応完了)、TPM 2.0 v185などを組み合わせ、2028年までにConfidential ComputingやFIPS 140-3 Level 3準拠のQuantum-Safe Cloud HSMを整備する計画としている。 ロードマップと責任分担 3つの領域それぞれに達成目標年が設定されている。SNDL対策(顧客ワークロード、管理者・開発者フロー、データパイプラインの保護)は2027年完了を目標に、Cloud VPNやCloud Interconnect、GKE Service Mesh、Tinkなどが2026〜2027年にかけて順次対応する。完全性・否認防止(ソフトウェアサプライチェーン保護、証明書発行、Cloud IAM)と、基盤・鍵管理(EKM、Google Workspace Client-Side Encryptionなど)はいずれも2028年完了を目標としている。 移行にあたってはGoogleと顧客の責任分担が明確化されており、Googleはネットワークの量子安全化や転送中暗号化、ハードウェアの完全性保証を担う一方、顧客側はアプリケーションのPQCハンドシェイク対応や鍵のライフサイクル管理、サービス設定の更新を担う「責任共有モデル」となる。この動きは、2030〜2035年に従来型アルゴリズムの段階的廃止を求めるNSAのCNSA 2.0や、移行パスを定めるNIST IR 8547といった規制動向とも歩調を合わせたものだ。 顧客への推奨事項 Google Cloudは顧客に対し、(1) Cloud Asset InventoryやWizの暗号資産評価ツールを用いた暗号資源のインベントリ把握、(2) BoringSSLやChrome、各種SDKなどPQC対応ソフトウェアへの更新、(3) 量子安全なAPIやロードバランサーを用いた検証、という3段階での準備を推奨している。今後数年で主要クラウドサービスの量子安全化が段階的に進む見通しであり、企業側も自社システムの暗号資産棚卸しを早期に始めることが求められそうだ。

概要 AWSは2026年8月13日、AWS Client VPN用クライアントソフトウェア「AWS VPN Client」のv6.0.xを公開した。今回のアップデートでは、コマンドラインインターフェース(CLI)のサポートに加え、企業向けの管理機能強化、そしてOpenVPN3をベースとした再構築による接続確立の高速化が図られている。既存のAWS Client VPNエンドポイントとの互換性は維持されており、エンドポイント側の変更は不要で、追加料金なしに標準のAWS Client VPN料金の範囲内で利用できる。 技術的な詳細 新たに追加されたCLIは、GUI(グラフィカルインターフェース)と機能的に同等であり、スクリプトによるVPN接続の自動化やInfrastructure as Code(IaC)ワークフローへの組み込みが可能になった。AWSは「AWS VPN Client CLIはGUIと完全な機能パリティを提供し、自動化ワークフローにVPN接続をスクリプト化できるようになった」としている。GUIとCLIは同時に起動して独立したVPN接続を維持できるため、運用担当者の手作業と自動化スクリプトを併用する環境でも支障なく利用できる。対応プラットフォームはWindows(x64/ARM)、macOS(x64/ARM)、Linux(x64)。 管理機能面では、特定ユーザーに限定したプロファイルや、デバイス単位で適用されるグローバルプロファイルの設定など、組織全体でポリシーを一元的に適用できる仕組みが加わった。従来、組織内でのVPNプロファイル配布はきめ細かなアクセス制御に乏しかったが、今回のアップデートによりエンタープライズ規模での管理がしやすくなる。 背景と今後の展望 これまでVPN接続の自動化には、サードパーティ製ツールの利用や手動での操作が必要だった。今回のCLI対応とOpenVPN3ベースへの刷新により、CI/CDパイプラインや構成管理ツールとの連携、多数の拠点・デバイスを抱える企業でのVPN運用効率化が期待される。既存環境からの移行に伴う設定変更が不要な点も、導入のハードルを下げる要素といえる。

概要 Node.jsおよびDenoの生みの親であるRyan Dahl氏が、Cloudflare WorkersのDurable Objectsおよび関連JavaScript APIと互換性を持つ、自己ホスト型・分散型の実装「celld」を公開した。Dahl氏自身はこれを「セルフホスト可能な分散Durable ObjectsおよびWorkers実装」と説明しており、Cloudflareのインフラに縛られずに同様のアーキテクチャを独自のバックエンド上で運用できる点が最大の特徴となっている。celldはApache 2ライセンスで公開されており、JavaScriptおよびTypeScriptで書かれたコードを実行できる。 技術的な詳細 celldはRustとJavaScriptで実装されており、非同期ランタイムにはTokio Rustを採用している。ストレージバックエンドにはAmazon S3互換のオブジェクトストレージを利用する設計で、各celldオブジェクトはそれぞれ独自のSQLiteコピーを保持する。オブジェクトごとに単一スレッドで処理を行うことで、複雑な同時実行制御の問題を回避しているという。API面ではCloudflare WorkersおよびDurable ObjectsのJavaScript APIと互換性があり、理論上はWebAssemblyを介してRust、C/C++、Go、Zigで書かれたコードも実行可能とされる。 Durable Objectsのアーキテクチャは、Cloudflareのエンジニアであるケントン・ヴァーダ氏が考案したもので、celldの開発チームはこれを「分散システムに近年もたらされた最良のプリミティブの一つ」と高く評価し、自らの実装を同アーキテクチャへの「ラブレター」と表現している。従来のAWS Lambdaのようなサーバーレスモデルとは異なり、Durable Objectsのモデルは計算とデータを同じ場所に共存させることで、WebSocket APIを活用した低遅延の分散Webアプリケーションを可能にする。リアルタイムの共同編集やマルチプレイヤーゲーム、AIエージェントの構築といった用途に適しているとされる。 コストを巡る主張の対立 Dahl氏の試算によれば、Cloudflare上で100個のアクティブなDurable Objectセルを稼働させると月額415ドルかかるのに対し、celldをDigitalOceanのS3互換バケットと8GBの仮想マシンで運用した場合は月額49ドルで実現できるという。これに対してCloudflareは異論を唱えており、オブジェクトが休止状態であれば月額コストは20.65ドルまで下がると反論している。 開発方針と今後の展望 celldのGitHubリポジトリでは、AI生成コードによるコントリビューションが禁止されている点も特徴的だ。開発チームは「コーディングエージェントは、大規模かつコンテキストの乏しい変更を送りやすくしてしまう」ことを理由に挙げている。記事では、Neonをはじめとする他のデータベースサービスプロバイダーも計算とデータを同じ場所に配置する同様のアプローチを進めていることに触れており、celldの登場はこうした実行環境の次の潮流を象徴する動きとも位置づけられている。