OSS

概要 Microsoftは2026年8月19日、Visual Studio Codeの月例アップデートとなるバージョン1.134を公開した。今回の目玉は、複数のチャットセッションを同時に扱うためのUI強化だ。関連するチャットやサブエージェントとのやり取りを水平または垂直方向にグループ化して並べて表示できる「Side-by-side chats」が追加され、ドラッグ&ドロップで会話同士を並べて比較検討できるようになった。レイアウトはセッションを再開した際にも保持されるため、複数のタスクを並行してエージェントに依頼するようなワークフローとの親和性が高い。 あわせて、長い会話を素早く見渡せる「Prompt timeline」も導入された。タイムライン上に各プロンプトがドットとして表示され、ファイル変更を伴ったプロンプトについては追加・削除行数がその場で確認できる。これにより、エージェントとの長時間のやり取りの中でも、どの時点でどのような変更が加えられたかを直感的に把握できるようになった。 技術的な詳細 チャット機能ではこのほか、Ctrl+F（Windows/Linux）またはCmd+F（Mac）でチャット全体を検索できる「Find in chat」も追加された。大文字小文字の区別、全文一致、正規表現による検索に対応しており、長い会話履歴から特定のやり取りを探し出す際に有用だ。 エージェント関連では「Agent host」という仕組みが導入され、複数のVS Codeウィンドウから同一のエージェントセッションに接続できるようになった。これはAgent Host Protocol（AHP）という専用プロトコルに基づき、独立したプロセス上でエージェントを動作させる仕組みで、マルチウィンドウでの作業とエージェントの状態管理を切り離して扱えるようにする狙いがある。サイドペインのレイアウトもworkbench.editor.showTabs設定に対応してタブ表示をカスタマイズできるようになり、セッションを切り替えてもレイアウトが保持される。 このほか、エディタ体験の面では、タブをAltクリックすることで他のタブを一括で閉じられる機能や、workbench.editorAssociations設定によりローカルHTMLファイルを統合ブラウザで直接プレビューできる機能が加わった。あわせて複数のメモリリーク修正も行われており、全体的なパフォーマンス向上にもつながっている。 背景と今後 近年のVS Codeのアップデートは、AIコーディングエージェントとの協働を前提としたUI・UX改善に重点が置かれる傾向が強まっている。今回のSide-by-side chatsやPrompt timelineも、単一のチャットで完結しない、複数のサブエージェントが並行してタスクをこなすような開発スタイルを後押しするものだ。Agent Host Protocolの導入により、エディタのウィンドウ管理とエージェントのセッション管理が疎結合になったことで、今後はマルチウィンドウ・マルチデバイスでの継続的なエージェント活用がさらに進むことが見込まれる。

概要 xAIは8月12日に発表した最新の推論モデル「Grok 4.6」を、その2日後の8月14日にGitHub Copilotへ統合したと発表した。エージェント型コーディングや複雑な多段階のワークフローに向けて設計されたモデルで、VS Code、Visual Studio、Copilot CLI、Copilot cloud agent、Copilot app、JetBrains、Xcode、Eclipseの計8つの開発サーフェス全体で利用できる。対象はCopilot Pro、Pro+、Max、Business、Enterpriseの各プランだが、Business・Enterprise管理者はデフォルトで無効になっているGrok 4.6ポリシーを設定画面で有効化する必要がある。ロールアウトは段階的に進められており、ユーザーはモデルピッカーから「Grok 4.6」を選択することで利用できる。 技術的な特徴とベンチマーク xAIはGrok 4.6を「長時間動作するエージェントや、より野心的なインタラクティブ・ビジュアル作業」向けに設計したとしている。推論・エンジニアリングデータでの追加のファインチューニングと、カーネル最適化やWeb開発、CAD(コンピュータ支援設計)といったエージェント型タスクに焦点を当てた強化学習を組み合わせて訓練された。ベンチマークでは、ターミナル環境での長時間コーディングタスクに強みを見せており、Terminal-Bench v3.0で26%を記録した。これはGPT-5.6 Sol Maxの34.6%には及ばないものの、前世代のGrok 4.5の15.7%からほぼ倍増している。またエージェント型コーディングを測るDeepSWE v1.1では65.9%を記録し、Grok 4.5 Highの54%から大きく向上した。 料金体系 Grok 4.6はxAIのAPIを通じて、入力100万トークンあたり2ドル、出力100万トークンあたり6ドルという価格で提供される。これはGPT-5.6 Sol(入力5ドル/出力30ドル)やClaude Opusクラスのモデル(入力5ドル/出力25ドル)と比べて大幅に低い水準であり、性能面では最上位モデルに一歩譲るものの、コスト面での競争力が際立っている。 今後の展望 JetBrains、Xcode、Eclipseまで含めた幅広いIDEサポートは、新モデルのローンチとしては異例の広さであり、VS Code中心の開発者層を超えてエンタープライズ開発者への浸透を狙う姿勢がうかがえる。ロールアウトは順次拡大される見込みで、GitHubコミュニティディスカッションを通じてユーザーからのフィードバックも収集されている。

概要 Modular（LLVMとSwiftの開発者であるChris Lattner氏が率いる、Qualcommによる買収を経た企業）は8月18日、AI・高性能計算向けプログラミング言語Mojo🔥のコンパイラおよびツールチェイン全体を、Apache 2.0ライセンス（LLVM例外付き）でオープンソース化したと発表した。ソースコードはGitHubの「modular」リポジトリで公開されている。先週リリースされたMojo 1.0のソース安定版に続く動きで、2023年5月以来Modularが約束してきたオープンソース化がここで実現した。標準ライブラリはすでに2024年に公開済みだったが、コンパイラを含む言語全体の公開は今回が初めてとなる。 技術的な詳細 ビルドプロセスにはBazelが採用されており、./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo という単一コマンドでコンパイルおよび実行ができる。開発者は標準ライブラリの修正やテストの実行も容易に行える構成になっている。Mojoは「AI駆動型の世界に向けた本番環境対応の基盤」を掲げ、CPU・GPU・AIアクセラレータなど多様なハードウェアに対応する。Rustなど現代的な言語の影響を受けつつ、Pythonとの相互運用性（PythonからMojoの呼び出し、その逆も可能）を特徴としている。現時点ではmacOSとLinuxに対応し、Windowsサポートも予定されている。なお、現在コンパイラおよびツール自体への外部コントリビューションはまだ受け付けておらず、Modularは「年末までに受け入れ開始を目指す」としている。 背景と方針転換 Mojoは当初、Pythonの完全なスーパーセットとなることを目標に開発されていたが、2025年8月頃に方針を転換した。開発チームは「Mojoが必ずしもPythonの完全なスーパーセットに進化する必要はない」との考えを示し、現在はPythonにインスパイアされた独立した言語として、GPUプログラミングを簡潔に記述できることに最適化する方向にシフトしている。この4年間、Mojoはコミュニティの意見を取り入れながらも非公開のコンパイラで開発が進められてきており、今回の全面公開は段階的なオープン化の集大成といえる。 今後の展望 Simon Willison氏はブログで、AI支援ツールがすでにPythonからMojoへの移行を効果的に助けていると指摘し、今後のツールの成熟とエコシステムの発展によってこの移行がさらに円滑になるとの見方を示している。コンパイラのソースが公開されたことで、外部開発者によるMojoの理解や検証が進むことが期待される一方、実際のコード貢献の受け入れは年末以降となる見通しで、コミュニティとの本格的な協働はこれからが本番となりそうだ。

概要 AIコーディングエディタCursorを開発するAnysphereは8月17日、GitHubに対抗するコードホスティング基盤「Origin」の有料ユーザー向けベータを公開した。リポジトリの作成、プルリクエストのレビューやマージ、CI/デプロイ連携までをCursorのインターフェース上に統合し、Vercel・Buildkite・Depotなどのプロバイダとも接続できる。奇しくも同日、GitHubがActionsやプルリクエスト機能に影響する大規模障害を起こしており、フラストレーションを抱えていた開発者の間で一段と注目を集める形となった。 Originの特徴とGitHubとの違い Originの設計思想は、既存のGitHub利用を強制的に置き換えるのではなく、段階的な移行を促す点にある。既存のGitHubリポジトリをOriginに同期させつつ、プッシュは引き続きGitHub側にも反映される仕組みを用意し、チームが低コストで試用できるようにしている。もう一つの特徴は、AIエージェントがファイル単位ではなくリポジトリ全体にアクセスできる点だ。Cursorは、AIエージェントがブランチ作成やマルチファイル編集、プルリクエストの発行と反復を人間の開発者よりもはるかに高い頻度でこなす「エージェントスケール」を前提に、Originのインフラを最適化したと説明している。 SpaceX傘下入り後初の大型プロダクト Origin公開の背景には、AnysphereをめぐるSpaceXの買収がある。SpaceXは2026年4月に600億ドル評価での独占買収オプションとして100億ドルを支払い、6月16日に全株式交換による買収合意を締結、8月14日に約3億9100万株のSpaceXクラスA株式を発行して買収を完了させた。Originのベータ公開はこのわずか3日後にあたり、SpaceXAI傘下でのAnysphere第一弾の主要プロダクトとなった。買収前のAnysphereはAndreessen Horowitz、Nvidia、Thrive Capitalなどの支援を受け500億ドル超の評価額で資金調達を進めていたとされ、今回の統合によりxAIのメンフィスにある「Colossus」スーパークラスターやGrokのモデル群といった、独立系スタートアップでは得られなかったリソースへのアクセスが可能になるとみられている。 データ利用をめぐる懸念 一方で、Originの立ち上げにはコードのデータ利用に関する懸念も伴う。企業向けプランでは管理者設定からベータの対象外とすることができるが、個人ユーザーに対するデータ利用ポリシーの詳細は明らかになっていない。SpaceX傘下となったプラットフォームに有料ユーザーのコードが預けられる形となることから、データ管理の透明性を求める声も出ている。GitHub障害との時期の重なりは、記事によれば「製品公開には通常数週間の準備を要する」ことから偶然の可能性が高いとされるが、GitHubは2025年5月から2026年4月の間に257件ものインシデントを起こしており、Actionsの信頼性問題に不満を持つ開発者にとってOriginの登場は象徴的な出来事として受け止められている。

概要 WordPress向けのフォーム作成プラグイン「Forminator Forms」に、未認証の攻撃者が悪意あるPHPファイルをアップロードし、リモートコード実行(RCE)を引き起こせる深刻な脆弱性が発見された。脆弱性はCVE-2026-15748として採番され、CVSSスコアは最大値に近い9.8(重大)と評価されている。Forminatorは60万件以上のWordPressサイトにインストールされている人気プラグインで、脆弱なバージョン(1.56.1以前)を使用しているサイトは30万件超に上るとされ、パッチ未適用のまま放置されればサイト乗っ取りにつながりかねない。セキュリティ研究者「daroo」氏によって発見・報告され、Wordfenceの開発元であるDefiantが詳細な分析を公表した。同社によれば、本稿執筆時点で実際の悪用は確認されていないものの、脆弱性の深刻度と影響サイト数の多さから早急な対応が求められている。 技術的な詳細 脆弱性の根本原因は、プラグインのファイルアップロード処理を担うhandle_file_upload()関数における検証の不備にある。Forminatorは危険な拡張子を持つファイルのアップロードをブロックリスト方式でチェックしているが、このチェックはパイプ記号(|)区切りの別形式のMIMEタイプキーを使うことでバイパスできる設計上の欠陥を抱えていた。攻撃者はこの弱点に加え、フォームの「セレクト」フィールドの設定値を細工してアップロード関数に渡されるフィールド設定を偽装することで、プラグインの拡張子ブロックリストを回避し、悪意あるPHPファイルをアップロード可能になる。 この攻撃が成立するには、対象サイトのフォームに「ファイルアップロード」フィールドと「セレクト」フィールドの両方が存在する必要がある。また、Forminatorのデフォルト設定ではアップロードされたファイルは.htaccessによってPHPの実行が防止される保護ディレクトリに格納されるため直接の被害は限定的だが、管理者がカスタムのアップロード先ストレージを設定している場合はこの保護が働かず、アップロードしたPHPファイルがそのまま実行されてサイトを完全に制御される恐れがある。 対応状況と今後の対策 本脆弱性は開発元によって修正され、2026年7月31日リリースのバージョン1.56.2で対処済みとなっている。WordPressサイトの管理者はForminatorを直ちに最新版へアップデートすることが強く推奨される。あわせて、ほぼ同時期に報告されたプラグイン「User Profile Builder」の認証バイパス脆弱性(CVE-2026-15826、CVSS 9.8、影響サイト4万件以上)も深刻度が高く、複数のプラグインで重大な欠陥が相次いで公表されている状況を踏まえ、管理者は利用中の全プラグインの更新状況を定期的に確認する体制の見直しが求められる。

概要 GitLabは8月17日、CVSSスコア9.4(Critical)と評価される重大な脆弱性CVE-2026-19478を修正する緊急パッチをリリースした。この脆弱性は、認証されていない攻撃者がGraphQL APIの特定のディレクティブを悪用することで、リモートから公開プロジェクトやユーザーデータを改ざん・削除できてしまうというもので、自己管理(self-managed)インスタンスが影響を受ける。GitLab.comなどのクラウド版利用者は対応不要とされている。2026年に入ってからGraphQL層で発見された重大な脆弱性としては3件目であり、GitLabのGraphQL実装に関するセキュリティ課題が繰り返し表面化している格好だ。 技術的な詳細 CVE-2026-19478は、GraphQLディレクティブを通じたコード注入に起因する脆弱性とされている。具体的にどのディレクティブが悪用されるのか、また攻撃を成立させる条件については、GitLabの開示ポリシーに従い2026年11月中旬まで技術詳細が非公開とされている。影響を受けるバージョンはCommunity Edition(CE)・Enterprise Edition(EE)ともに18.2から18.11.10まで、19.0から19.0.7まで、19.1から19.1.5まで、19.2から19.2.3までの範囲で、修正版として19.2.4、19.1.6、19.0.8、18.11.11がリリースされた。なお、影響範囲に含まれる18.2から18.10までのブランチには直接の修正パッチが提供されておらず、これらのバージョンを利用している場合は18.11.11以降への完全なアップグレードが必要になる。 同時に、GraphQLの多重化(multiplex)クエリハンドラに存在するCSRF脆弱性CVE-2026-19650(CVSS 7.1)も修正されている。こちらは認証されていない攻撃者がGETリクエスト経由でミューテーションを実行できてしまう問題だが、悪用にはユーザーの操作(被害者が悪意あるページにアクセスするなど)を必要とする点でCVE-2026-19478とは異なる。両脆弱性はいずれもGitLabのHackerOneバグバウンティプログラムを通じて報告されたもので、CVE-2026-19478の報告者は「hiimguardian」というハンドル名で識別されている。現時点で野生における悪用や概念実証(PoC)コードの公開は確認されていない。 背景と今後の対応 GitLabはCVSS 9.4という評価の高さから、自己管理インスタンスの管理者に対して「immediately」つまり直ちにアップグレードを行うよう強く呼びかけている。認証を必要とせず、公開プロジェクトのデータを外部から改ざん・削除できてしまう性質上、悪用された場合の影響範囲は大きい。GraphQL APIは近年多くのSaaS製品でREST APIに代わる主要なインターフェースとして採用が進んでいるが、柔軟なクエリ構造ゆえにディレクティブや多重化クエリなど特有の攻撃面を持つことも知られており、今回の一連の脆弱性はその典型例といえる。技術詳細の全面公開は11月中旬を予定しており、それまでは公開されている修正バージョンへの更新を優先することが推奨される。

概要 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から正式な事後分析(ポストモーテム)が公開されるかが注目される。

概要 Linus Torvaldsは8月16日、Linuxカーネル7.2を正式にリリースした。今回のリリースはUbuntu 26.10をはじめとする今後のディストリビューションに採用される見込みで、AMD EPYCおよびIntel Xeon系サーバーを中心にI/O性能の向上が図られているのが特徴だ。BPFシステムコールでの共通属性対応、CPUスケジューラのキャッシュ認識型負荷分散、Btrfsのラージフォリオ対応、Landlockセキュリティモジュールの強化なども盛り込まれている。Torvaldsは今回のサイクルについて「小さな修正がドライバを中心に至るところにあり、最終週もネットワーキング周りの活動が活発だった」と述べており、例年より変更規模が大きくなったことを認めている。 主な新機能とパフォーマンス改善 目玉機能の一つがAMD EPYC 5およびIntel Xeon 6世代プロセッサ向けの「キャッシュ認識型スケジューリング(Cache Aware Scheduling)」で、CPUキャッシュの局所性を意識したタスク配置によりマルチソケット・多コア環境での処理効率を高める。ハードウェア対応では、Intelが開発したUSB4STREAMプロトコルや、AMDGPUにおけるHDMI 2.1 FRL(Fixed Rate Link)サポートが追加されたほか、Intel Arc B390グラフィックスの機能拡張、ThreadRipper環境でのpoll性能向上など、AMD・Intel双方のプラットフォームで細かな改善が積み重ねられている。またApple M3デバイスのサポートや、ゲーミングコントローラ「Zenaim Leverless」への対応など、コンシューマ向けハードウェアの取り込みも進んだ。一方でAppleTalkサポートや、ARCNetネットワーク向けの古いISA・PCMCIAアダプタドライバなど、レガシーコードの削除も行われている。 開発終盤ではDRMスケジューラを巡るトラブルも発生した。新しい「fair」ポリシーが性能低下を引き起こしたため、従来のFIFOスケジューラへの回帰(revert)が土壇場で行われたほか、サウンドデバイスのクイーク追加やtlbi=ipiブートオプションの実装といった修正も最終週に滑り込んだ。Torvaldsはこの対応について「『あのコードはまだ準備ができておらず問題を起こした』という事態に対処する正しいやり方だ」と説明している。 開発体制の変化と今後の展望 Torvaldsは今回のリリース規模が例年より大きくなった背景として、AIコーディングツールの活用拡大による開発者からの貢献量増加を挙げ、これを開発における「新しい常態(new normal)」と表現した。その上で「その理由でリリースを遅らせていたら、おそらく永遠にリリースできなくなるだろう」と述べ、増加する変更量を受け入れつつ従来通りのペースでリリースを続ける方針を示した。品質維持とAI支援による貢献増加のペースのバランストレードオフが、今後のカーネル開発における課題として浮かび上がっている。 Linux 7.2のリリースと同時に次期バージョン7.3のマージウィンドウが開き、すでに40件のプルリクエストが提出されているという。AMD・Intel・Nvidiaの次世代チップへの対応準備も進められており、次サイクルでもハードウェア関連の変更が続く見通しだ。

概要 David Heinemeier Hansson(DHH)氏が主導するLinuxディストリビューション「Omarchy」が、次期メジャーリリース「Quattro」(v4.0)でAIエージェントをOSの標準機能として組み込むことを発表した。Omarchyは「Beautiful, Modern & Opinionated Linux」を掲げるディストリビューションで、今回の方針転換はそのコンセプトを延長する形で位置づけられている。Rustやgcc、Codebergなど主要なオープンソースプロジェクトがAIによるコード生成を制限する動きを見せる中、Omarchyはあえて逆の方向に舵を切った格好で、コミュニティ内で賛否両論を呼んでいる。 新機能の詳細 Quattroの目玉となるのが「クラッシュウォッチャー」機能だ。systemd-coredumpのジャーナルを監視してプロセスクラッシュを検出すると、「diagnose-crash」スキルを通じてバックトレース情報をAIエージェントに渡し、ユーザーの確認を得たうえでレポートを送信する仕組みになっている。 もう一つの柱がエージェント選択システムで、Claude、Codex、Gemini、Grok、Copilotなど9種類のAIエージェントから利用するものを選べるようになる。初回起動時には通知でエージェント選択を促すが、スキップも可能で、デフォルトでは未選択の状態が保たれる。このほか、週単位の利用制限を追跡できる「モデル使用状況ウィジェット」や、コーディングエージェントとの統合機能も新たに加わる。 業界内での位置づけとコミュニティの反応 記事は今回の決定を、Linus Torvalds氏が自身のプロジェクトについて「反AIの立場は取らない(“is not one of those anti-AI projects”)」と述べたこととあわせて紹介し、オープンソースコミュニティ内でAIへのスタンスが分裂している状況を指摘している。一方で、開発者IroncladDev氏はOmarchyがmacOSからの移行先として気に入っていたものの、「AI/エージェント関連の機能追加」には関心がないとして、v4へのアップグレードを見送る意向を表明するなど、既存ユーザーの間でも受け止め方は割れている。 記事の著者は、DHH氏の今回の判断について、以前Hyprlandをウィンドウマネージャーとして採用した際と同様の「先制的な決定」と評価し、時機を得た選択だとしている。この方向性により、Omarchyは他の主要ディストリビューションとの差別化を図り、「AI Linuxディストリビューション」としての立ち位置を確立しようとしていると分析している。

概要 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の登場はこうした実行環境の次の潮流を象徴する動きとも位置づけられている。