リソースセンター

AI Agent は開発者の標準的なニーズになりつつありますが、開発・デプロイには依然として無視できないハードルがあり、自前で組み合わせなければならないインフラが少なくありません。EdgeOne Makers（EdgeOne Pages の名称変更）は、これまでの Web フルスタック機能に加えて Agent のネイティブサポートを追加し、Agent 開発を Web アプリケーション開発と同じくらい簡単にします。開発者はビジネスロジックに集中し、インフラはプラットフォーム側で一括して引き受けます。同じプロジェクト内で Web と Agent のコードを同時にデプロイでき、ドメインや設定など、デプロイと観測の仕組み一式を共有します。Agent ランタイム。Agent Runtime を提供し、Claude Agent SDK、OpenAI Agents、LangGraph、DeepAgents、CrewAI などの主要フレームワークをそのまま実行できます。handler の書き方は各フレームワークのネイティブな流儀のまま、プラットフォーム側で新たな SDK 抽象は導入しません。セッションストレージ。context.store は各フレームワークのネイティブなセッションストレージ型をそのまま公開します。例：OpenAI Agents では Session、LangGraph では BaseCheckpointSaver が得られます。各フレームワークは標準では抽象プロトコルしか提供せず、永続化実装は通常自分で Postgres などのクラウドストレージを繋ぐ必要があります。Makers は最下層でプラットフォームの Blob ストレージにより一括して受け持つため、別途サービスを有効化する必要はありません。

初期のエージェントは普通のバックエンドとそれほど違いはありませんでした。カスタマーサポート、Q&A、注文照会といったシナリオでは、業務インターフェースを備えた LLM サービスに近い存在でした。しかしモデルの能力が伸びるにつれ、エージェントは本当に「手を動かす」ようになり——ファイルを扱い、コードを書き換え、テストを走らせ、ブラウザを操作し、複雑なシステムを束ねるようになり、これまで人手でやっていた仕事を少しずつ引き取るようになりました。権限境界を絞り、リソース利用をコントロールするうえで、サンドボックスは必須要素となりました。次に直感的に思いつく構成は、エージェントのロジックとツールを同じサンドボックスに詰め込むことです。コールパスが短く、状態の共有もしやすい。構成自体はシンプルですが、マルチテナント、セキュリティ分離、コスト効率といったエンタープライズ級の要件に入った瞬間に綻びが見えてきます。ロジックを一行いじるためにツールチェーンを丸ごと含むイメージを再ビルドする必要があり、並行リクエスト下では会話一つにつきサンドボックスを丸ごと専有するためリソースコストが急速に積み上がります。エージェントのロジックと認証情報、信頼できないコードが同じ環境に同居することで、prompt injection の攻撃面も広がります。状態はサンドボックスに紐づいているため、破棄と同時に消え、復元も難しい。そこで業界は、よりデカップルされたアプローチを模索し始めました——エージェントのロジック、ツールサンドボックス、状態がそれぞれ独立して動き、コンポーネントごとに自身のライフサイクルでスケジュールされ、互いに縛らない構成です。

本日より、EdgeOne Pages は EdgeOne Makers へ正式に名称変更します。今回の名称変更によって既存のプロダクトのロジックが変わることはありません。この1年余り、プロダクトは開発者の実際のニーズに沿って段階的に拡張されてきました：「Pages」は第一印象として依然「フロントエンドホスティング」を想起させ、現在のプロダクトの実態とギャップがあります。 「Makers」は英語圏の技術コミュニティでは Indie Maker — アイデアをコードでプロダクトに仕上げる人 — を指す言葉として広く使われており、それこそが EdgeOne が今後も支え続けたい対象でもあります。

Pages Cloud Functions に Python と Go の 2 つのランタイムが加わりました。同じプロジェクト内でこれらの言語を使ってバックエンド API を作成し、フロントエンドページと一緒にリポジトリへプッシュするだけで、自動的にビルド・デプロイされます。今回のアップデートにより、 cloud-functions  ディレクトリ内の  .py  および  .go  ファイルが認識されるようになりました。プラットフォームが対応するランタイムを自動的にマッチングし、ファイルパスがそのまま API パスになります。Cloud Functions の Python ランタイムには 2 つのモードがあります：

EdgeOne Pages Beta 版のリリースから1年、開発者の皆様から多くのフィードバックをいただき、数十回のバージョンアップを重ねてまいりました。本日、EdgeOne Pages 正式版のリリースを発表できることを嬉しく思います。今回のアップデートは、開発者が最も関心を持つインフラ性能、セキュリティ機能、オブザーバビリティに焦点を当てています。以下はアップデートの詳細内容です：正式版では、基盤となる CDN ネットワークを全面的にアップグレードし、インテリジェントなネットワークスケジューリング、リンク最適化、高度な設定機能を追加しました。これにより、アクセス遅延の低減とサービス安定性の向上を実現しています。ユーザーがどこにいても、より高速なロード体験を提供します。

EdgeOne Pages がミドルウェア機能を正式にサポートしたことをお知らせいたします。これにより、エッジノードでユーザーリクエストをインターセプトして処理し、ページの読み込み前にカスタムロジックを実行できるようになり、アプリケーションの応答性が向上し、アーキテクチャがより柔軟になります。ミドルウェアとは、リクエストが最終目的地に到達する前に実行されるコードです。ユーザーリクエストをインターセプトし、リダイレクト、リライト、リクエストヘッダーの変更などの操作を実行できます。これはリクエストの「門番」のようなもので、本格的な処理の前にフィルタリングと前処理を行います。従来のアーキテクチャでは、これらの処理ロジックはオリジンサーバーに戻して実行する必要があり、レイテンシが増加するだけでなく、オリジンサーバーに追加の負担がかかっていました。EdgeOne Pages のミドルウェアはエッジノードで実行され、これらの軽量な処理ロジックをユーザーに最も近い場所に前置します。リクエストはオリジンサーバーに到達する前に判断と処理を完了できます。

EdgeOne Pages は、TanStack Start と Vike フレームワークのデプロイを正式にサポートしました。これら2つのフレームワークは近年、ますます多くの開発者から注目を集めています。TanStack Start はエンドツーエンドの型安全機能を提供し、Vike は高度にカスタマイズ可能なアーキテクチャで知られています。今回のサポートにより、開発者は技術スタックの選択においてより柔軟性を得られ、モダンなフルスタックアプリケーションをより簡単に構築・デプロイできるようになります。TanStack Start は、TanStack チームが開発したフルスタック Web フレームワークです。TanStack Router と Vite をベースに構築されており、完全なサーバーサイドレンダリング（SSR）、ストリーミングレンダリング、サーバー関数、API ルート、バンドル・デプロイ機能を提供します。エンドツーエンドの型安全により開発体験を最適化し、あらゆる JavaScript ランタイム環境にデプロイ可能な、モダンなフルスタックアプリケーション開発のための統合ソリューションを提供します。

TanStack は、モダンな Web アプリケーションのために設計された高品質なオープンソースのツールスイートです。現在までに、各モジュールは GitHub 上で累計 10 万以上のスターと 9,500 人のフォロワーを獲得しています。最大の強みは、Web 開発において特に難易度の高い領域をモジュール化・標準化し、それらを本番環境で利用できる包括的なエコシステムへと昇華している点にあります。 TanStack の目標は、単に便利なツールライブラリになることではありません。モダンなフルスタックアプリケーションに内在する、システムレベルの複雑性そのものを解決することを目指しています。ルーティング、データ取得、SSR（サーバーサイドレンダリング）といった、これまで分散していたプロセスをシームレスに統合し、統一された一貫性のあるワークフローとして提供します。大規模なデータセットや複雑なフォームインタラクションを扱う場面では、TanStack が提供するのは単なる近道ではなく、岩盤のように堅牢な基盤であることが分かります。これにより、「高性能」と「高信頼性」は開発者が背負う負担ではなく、フレームワークの DNA として組み込まれていきます。

認証は、ほぼすべての Web アプリケーションにおいて重要な機能です。SaaS 製品、個人プロジェクト、社内ツールのいずれを構築する場合でも、ユーザーのサインイン機能が必要になることがほとんどです。しかし、認証をゼロから実装するのは簡単ではありません。パスワードの安全なハッシュ化、セッション管理、OAuth フロー、トークンの更新など、問題が発生しやすい要素が数多くあります。認証は重要ですが、アプリを差別化する機能ではありません。他の部分に時間を使いたいと思うのが自然です。そこで Better Auth の出番です。