Open10
ServerlessDays Tokyo 2025
くりりんサーバーレスのまわりの技術2025
仲山昌宏 (めもおきば)
サーバーレスのおさらい
- 運用者；自分でサーバーを管理しなくて良い
- 完全従量課金なフルマネージドサービス
- 開発者：個々のサーバーに依存する機能を利用しない
- プロセスメモリやファイルシステムはリクエストをまたいで共有されない
時間軸の加速が速すぎる！
- インプット過多になっていませんか？
- アウトプットを意識して取捨選択しよう
- メモに残そう
- AIと壁打ちしよう
- SNSへのポスト、ブログ
- 様々なアウトプットの形があるよ
- 化学変化を楽しもう
自由と制約のグラデーション
- FaaSとPaaS
- Node sandbox、Lambda Web Adapter + コンテナ、WASM
- 世界のローコード化
- なんちゃらServerless
- プロンプト、RAG、MCP、コンテキストエンジニアリング
Serverless implements Platform Engineering
- プラットフォームによるベストプラクティスの提供
- 開発者が自分で作らない（意識しない）ところを任せる
- 誰もが安全でスケールするソフトウェアを作れるようにしたい
- パブリッククラウドという大規模プラットフォーマー
- ↔︎組織内プラットフォームチーム
AIもソフトウェアを書く時代
- つくらないものづくり
- Vide Coding
- 確率という新しい発想を期待する開発
- Spec-Driven Development
- Vide Coding
ソフトウェアエンジニアリングの重要は不変
- 良いサービスやプラットフォーム、ライブラリを使う
- 「職人芸」ではなく、再現性を求めていく
- 良き制約 = 良いプラットフォームとしてのサーバーレス
セキュリティ
- やられるべきシステムがきちんとやられてしまう時代
- 依存ソフトウェアに対するサプライチェーン管理
- ワークロード間の認証
- 起きていることの監視
- 最強権限の原則、必要な時だけの払い出し
データとコスト
- コンピュートとストレージの分離
Frugal architectであろう
- コスト構造を意識したアーキテクチャ設計
- 例：AIのボトルネック
分断を超えていこう
- ロックイン
- クロスクラウド
- ソブリンクラウド
なにを、つくる？
- AIが伴奏してくれる時代では「つくろうという意志」が重要
- サーバーレスなプラットフォーム
登壇資料
くりりんServer Less, Code More - コードを書かない時代に生きるサーバーレスデザイン
淡路大輔 (Amazon Web Services)
Bedrock Engineer
オープンソースとして公開しているAIエージェントアプリケーション
Bedrock Engineerのアーキテクチャ
クラウドリソースの構築は不要
Amazon Bedrock
AIプロバイダーのさまざまなモデルを利用するための統合APIインターフェースを提供
サーバーレスアプリケーション
- Event source
- Function
- Service
普遍的なサーバーレスデザイン
- 関数単位の設計
- ステートレス
- イベントドリブン
LLMの制約
- 知識の限界
- ナレッジカットオフがある
- 最新の情報、データを取得できない
- 外界とのインタラクション
- システムの操作ができない
- ステートレス
- 会話履歴を保持しない
Kiro & AI-DLC プロセスの再発明
- Kiro / Sped 駆動開発
- AI-DLC（AI駆動開発）
コードを書かない時代の到来
- コーディングエージェントは一般化した
- AIを使ってコードをかけることは重要ではない
- AIの出力を反芻し、でって意的に練り上げていく
- プログラマーの価値はAI Agentによって向上する
Ambient Agent
ユーザーの指示を待つことなく、イベントを監視して必要に応じて通知や質問を行う自律型エージェントのアプローチ
Serverless Code More
- インフラ管理から解放されるServerlessでアプリケーションコードの実装により集中できる
- コードの実装から解放されるAI開発でビジネスロジック自体により集中できる
- アプリケーションエンジニアだからこそ、ビジネスロジックをより安全に、より高速に実装することに立ち向かおう
登壇資料
くりりんあなたの知らない Wasm とキャッシュの世界〜CDNエッジを活用した高コスパサーバレス開発の新常識〜
澤田径 (Fastly)
登壇資料
くりりん「完璧を目指さない」サーバーレス進化論 〜CDKで育てる変化に強いアーキテクチャ〜
志水友輔 (NRIネットコム)
とりあえずLambdaで設計
メリット
- 最初は快適
デメリット
- 15分制限の壁
- 複雑化するYAML
- 構成変更の恐怖
構成変更の現実
- Lambda分割
- Fargate移行
どちらも大変…
- 初期設計では15分で十分だった
- もっと変更しやすくできないか？
アーキテクチャは育てるもの
進化の鍵：構成変更の容易さ
進化的アーキテクチャとは
ビジネス要件や技術の進歩といった変化に適応できるように設計された、柔軟性の高いソフトウェアアーキテクチャ
- 漸進的な変更
- 適応度関数
- 多重な次元
CDKによる進化的アーキテクチャの実現
実践的進化パターン
Lambda → Fargate移行
移行のポイント
- 実行時間制限の解除
- より大きなメモリ・CPUリソース割り当て
- 既存のLambda関数ロジックをそのままコンテナ化可能
CDKはSAMと比べて移行時のコード行数を1/3に
EventBridge + Lambda → Step Functions
移行のポイント
- 分散イベント処理の統合
- 実行履歴の一元管理で状況把握が一目瞭然
- エラーハンドリングの集約化
- 障害調査時間の大幅短縮
- 迅速な処理時間
CDKでStepFunctions移行が楽になった理由
- 既存のgrant()メソッドがそのまま使える
- 堅安全性によりコンパイル時にエラー検出
DynamoDB → Aurora移行
進化的アーキテクチャの観点
- 性能関しによる適応度関数
- DBいこうじの性能劣化を自動検知
- CDKにより簡単に記述可能
セキュリティ要件の移行
進化的アーキテクチャの観点
- cdk diffにより変更点を確認しながら進める漸進的な変更が可能
- 1行の変更でIAMベースからVPCベースのセキュリティへ変更
まとめ
- CDKの価値
- アーキテクチャは「育てるもの」
- 完璧な初期設計は存在しない
登壇資料
くりりん2025年版 サーバーレス Web アプリケーションの作り方
渡辺隼人 (サーバーワークス)
レンダリングとホスティング手法の選択肢
以下のレンダリング手法の分類でホスティング手法も併せてお話しします
- SPA
- SSR
- SSG
- ISR
SPA
- ホスティングにコンピューティング不要
- Webアプリケーションのレンダリングはブラウザで実施
- ただしページ上の動的なデータ取得はバックエンドAPIが必要
- OGP対応が難しい
- SPAとバックエンドAPIでことなる技術選定が可能なためチームを分割できる
- バックエンドAPIの規約を担保する必要がある
SSR
- ホスティングにコンピューティングが必要
- Webアプリケーションのレンダリングは基本的にサーバーサイドで行う
- SPAのようにバックエンドAPIの分割が必須ではないため同一ドメインのコードの凝集度を高めることもできる
- フルスタックフレームワークを用いる
SSG
- ホスティングにコンピューティングが不要
- 比較的静的な情報を扱うWebアプリケーションに向いている
ISR
- SSGの扱いにくさである再ビルド機能をホスティングに組み込んだレンダリング手法
- ホスティング環境の難易度が高い
実例紹介
SPA
- B2BのIoT情報可視化Webアプリケーション
- スキルセットに応じたチーム分けを実現するためにSPAとバックエンドAPIの組み合わせを採用
良かった点
- 当時のスキルセットに応じたメンバー配置によるスムーズな開発
改善したい点
- SPA、バックエンドAPIの両方の担当の稼働が必要
SSR
- B2BのモニタリングWebアプリケーション
- Coding Agentに必要な情報を一元化し、開発者のコンテキストスイッチを減らすため、モノレポ構成でCDKとNext.jsを採用
良かった点
- コンテキストスイッチが減り開発者がアプリケーション全体を把握できるようになった
改善したい点
- Next.jsでは、その機能を十分活用できていないこと
ISR
- SSRと同じアプリケーション
- Webアプリケーション責務のコンストラクトをECSからcdk-nextjs-standaloneコンストラクトに置き換えを決定
良かった点
- CDKのコンストラクトで表現していたため、差し替えが容易だった
- イベント駆動パターンに移行できた
まとめ
- レンダリングとホスティング手法の選択肢を理解する
- SPA、SSR、SSG、ISR、それぞれに対応するホスティング手法が異なる
- 最適な選択を組織とワークロードの目的や特性から考える
- メンバーのスキルセットやチーム構成を考慮する必要がある
- SEOやOGP対応の必要性やトラフィックパターンを考慮する必要がある
- 変更可能なシステムアーキテクチャを取り入れ、継続的に進化させる
- 変更が容易なアーキテクチャを実現する必要が大切
- CDKの抽象化や構造化を活用
登壇資料
くりりんADK と Cloud Run で作る AI エージェント
関本 信太郎 (グーグル・クラウド・ジャパン合同会社)
AIエージェントを支える技術
AIのパラダイムシフト
「指示を待つAI」から「自律的に協調・行動するAI」へ
AIエージェントとは？
ゴールを達成するために、環境を認識し、推論・意思決定を行い、自律的に行動するプログラム
軽々から学習・適応することも可能
エージェントの基本サイクル
- 認識
- 推論
- 行動
- 学習
エージェントの基本構成
- 頭脳：Brain
- Gemini
- 手足：Tools
- API
- 検索
- データベース連携
頭脳と手足の連携プレイ
Geminiが「何をすべきか」を考え、エージェントが「実際に実行」する
AIエージェントのユースケース
- 自動化されたカスタマーサポート
- パーソナル開発アシスタント
- プロアクティブなデータアナリスト
- 高度な旅行プランナー
Gemini
- ネイティブマルチモーダル
- 長大なコンテキスト
- Googleエコシステム連携
Tools
- Function Calling
- 定義：開発者が関数を定義
- 提案：Geminiが呼び出すべき関数を提案
- 実行：アプリが関数を実行
- Grounding
- モデルの出力を検証可能な情報源に紐づける - ハルシネーションを抑制
- Code Execution
- コード生成：GeminiがPythonコードを生成
- 安全な実行：生成コードを隔離された環境で実行
- 結果の出力：実行結果（テキスト、画像等）を出力
開発を加速するフレームアーク：ADK
アイデアを素早く形にし、本番品質のエージェントを構築するためのオープンソースフレームワーク
MCP
AIツール用の「USB-C」
どんなツールも同じお作法で接続できることにより、開発高陸と拡張性が劇的に向上します
MCPの構成要素
- MCPクライアント
- MCPサーバー
なぜ今、MCPが注目されているのか？
AIエージェントが実用段階に入り、ツールの標準化が爆発的な進化の鍵となっている
Agent2Agent（A2A） protocol
AIエージェントのコラボレーションを取り持つ、オープンなプロトコル
A2Aの提供機能
- AIエージェント機能の広告、発見
- 安全なタスクの委譲
- 非同期通信
A2AとMCP
競合するのではなく、補完し合う関係
Agent Payments Protocol（AP2）
これから先、AIが決済まで行う未来がくる
いかに安全に決済ができるかを提案している
サーバレスで作るAIエージェント
エージェントランタイムの選択肢
- Vertex AI
- Cloud Run
- GKE
Agent Engine
AIエージェントを本番環境に簡単にデプロイできるGoogle Cloudのフルマネージドなプラットフォーム
エージェントの行動をどう監視するか？
エージェントの思考プロセスはブラックボックス？
コーディングエージェントを活用する
Gemini CLI
軽量化かつパワフルなCLIとして最新AIをターミナルで利用可能なツール
ターミナルで動作する汎用エージェント
- コーディング
- コード生成からテスト、レビューなど
- ドキュメント作成
- 一般的なドキュメント作成
- README、レビューコメント、リリースノートを自動生成
- タスクの自動化
- 自然言語で複雑なコマンドやスクリプトを実行
- エージェント
- MCPと連携し自律的なタスクを実行
- スライド作成、動作作成など
チャット機能の進化
- 開発者に代わって提案された解決策を実行する
- 開発者ツールとの統合により影響を増幅する
まとめ
- AIエージェントはADKやMCPなどの技術によって開発が加速している
- CloudRunなどのサーバーレスプラットフォームを活用することでAIエージェントやMCPサーバーを迅速かつスケーラブルにデプロイできる
登壇資料
くりりんAIエージェントがアプリケーション開発の未来を変える
草薙昭彦 (Postman)
新しい開発者ってどういう人？
- データアナリスト
- プロダクトマネージャー
- マーケティング担当
- 技術サポートエンジニア
- スタートアップ創業者
- 事業責任者
AIがアプリケーション構築の方法を変えつつある
- これまでのアプリケーション構築手法
- タスクを完了するためのすべての手順を記述
- 新しいアプリケーション構築手法
- AI：手順を置き換えたり追加したり、タスク全体をLLMに委任
- データ：AIがリアルタイムの状況に応じてデータを発見・取得
- API；AIがAPIを探し出し、変化を主導し、成果を達成
質の高いAPIなくしてAIは実現できない
AIモデルとエージェントを用いたアプリケーション構築
- LLM APIを介したチャットボット
- AI駆動のドキュメント分析
- データベースからのデータ抽出
- AIを活用したレコメンデーションエンジン
- メディア生成
- 顧客とのやり取りを自動化
AIを使った開発は速い
でも、アプリ構築は単にコードを書くだけではない…！
AIによるコード開発支援を超えて完全に統合された一体感のある体験へと進化すべき
Postmanのアプローチ
- ビジュアルプログラミング（ローコード） + AIが新しい開発者にとっての障壁を取り除く
- AIプロンプト、APIの利用やデータ変換の複雑さを抽象化
- ロジックを表現し実行するための直感的なビジュアルフロー
- デバック、反復、コラボレーションをより明確に
Postman Flows はAIアプリケーションエージェントを構築するためのビジュアルローコードツール
カスタムコードを書かずにワークフローを構築し、さまざまなパラメータやプロンプトを迅速にテスト
Postman Flows のようなビジュアルプログラミングにより開発者がAI駆動型アプリケーションを構築・実行することが簡単に
モジューラー型のフローはブロックの再利用を促進し保守負担が軽減されてすべての関係者が理解を深めやすくなる
モジューラー型フローはスナップショットにより自動的にバージョン管理される
スナップショット機能により開発者や共同作業者は変更を追跡
シナリオ機能によって開発者や共同作業者は特定のパラメータや入力値の組み合わせでアプリケーションを実行できる
フロー + シナリオですぐに実行可能なアプリケーションに
Postman Flows は、AI時代の開発者向けに、AIアプリケーションの構築、実行、運用を統合したソリューション
まとめ
- AIを活用した新しい方法
- ローコードビジュアルプログラミング IDE
- Ready-To-Runアプリケーションの複製
- 組み込みのスナップショット＆バージョン管理
- オンデマンド生成されるAI支援ツール
- AIによるツール生成
- AIエージェントによる動的ロジックの適用
- 環境をまたいだワンクリックによるデプロイ
- AIプロンプト・API・実行可能ワークフローの共有
登壇資料
くりりん3,000時間／月の業務削減を実現する～Dify × TiDB ServerlessによるAI基盤の裏側～
西悠之 (サイバーエージェント)
部署紹介とミッション
AIオペレーション室について
- 全社横断的に生成AIの取り組みを加速させ、サイバーエージェントの競争力へと繋げていく
- 生成AI活用ガイドラインの策定
Difyとは？
概要
- ノーコード開発フレームワーク
- 外部連携可能
- ドキュメントをRAG利用可能
- 簡単にプロンプトを編集可能
Difyを選んだ背景
- Dify
- 直感的なUI/UXが提供されているローコードなフレームワーク
- n8n
- ワークフロー自動化に強みを持つツール
- LangChain
- LLMの利用に特化した開発ライブラリ
Difyのプラン形態
- クラウド
- すぐに利用開始できる
- 制限がある
- ユーザー数
- アプリ数
- リクエスト数
- ストレージ
- セルフホスト
- オープンソース（コミュニティ版）
- エンタープライズ
セルフホストを選んだ理由
- コスト
- 初期投資としてスケールと運用コストのバランスを考慮
- カスタマイズ性
- OSSであるため拡張可能
- データガバナンス
- 機密情報を扱う前提から、自社で信頼できるストレージを選定できる
システム構成
いんふらを構築する上で求められるパフォーマンス要件を定義
- ユーザー数・アプリ数
- 最大10000名以上
- 1人あたり10個作られると10万超える
- 同時接続・負荷
- 数千・数万のアプリが定期的に実行されてもレイテンシーが落ちないようにしたい
- データ量
- コスパの良いものを利用したい
- セキュリティ・運用
全社展開で見えてきた特徴・性能について
- 利用者の特徴
- ビジネス職の方が主要なユーザーを占める
- 活用パターン
- 定常的な繰り返し作業
- 質問応答システム
- Nontion、Wikiの検索・要約（RAG）
- ベクトルDBに求められる性能
- データ量の急激な増加
TiDBの運用実績
- コスト・ストレージ
- 利用料は数ドル程度にとどまっている
- パフォーマンス
TiDBを選んで良かったポイント
- コスト効率のよさ
- パフォーマンス
- 運用性
まとめ
- 基盤としてTiDBを選択
- コスト効率が高く、コスパの良さを実感している
スタートアップ企業におけるTiDB活用事例
安井岳 (エイターリンク)
所感：よくあるこの構成で結構いける
- クライアント
- MVCフレームワーク
- DB
- TiDB Cloud Starterを利用
TiDBに関して
TiDBの選定理由
- スケールする分散DBで現状の用途ならRDBMSで問題なかった
- 他の時系列データベースが備えていたりするコンパクションなどが不要だった
- RDBMSで完結すると楽
感じている利点
- DBのメンテナンスコスト
- アプリケーションのメンテナンスコンスト
- サポートがしっかりと対応いただけて助かる
TiDB Cloud Starter
ハマった点
insert時に外部キー制約を外す
ある物件でシステム導入時にDB待ちで前段のAPIサーバが全てのスレッドを使い切って繋がりにくくなる
TiFlashを強制する
とある画面が重いが、様々な事情ですぐにクエリやテーブルのリファクタリングができない
コスト削減
- プラン変更
- クエリ改善
- バッチ処理をしたい
- DBへのアクセスを減らす
登壇資料
くりりんCDN Edge Computing上で動くOIDC Identity Aware Proxyのススメ
原田篤 (LIXIL)
スクラッチでOIDCを実装するケース
- 呼び出し元の基本的な実装
- セキュアに組み込めているかのチェック
- ライブラリ等の継続的なアップデート
このようなサービスが100個以上あったら…？
ミドルウェアを使ってOIDCを実装するケース
- ユーザーがALBにアクセス
- ALBが必要においじてOPに
- ユーザーがOP画面で認証
…
考慮事項がある
- オンプレTargetに転送する場合に考慮が必要
- IAPの場合
- IssuerとOPのURLが異なる場合に設定できない
- OP側でユーザーのメールアドレスが変更されたときの挙動が不安定
…
調べてみる
- Lambda@Edge上でOpenID ConnectのRelying Party機能を実装している例がある
CDN認証Proxyの実装上考慮する必要があったこと
- セッションに関する情報保持の話
- 高速なRead、Writeが頻繁に発生する
- Strong Consistencyが求められるユースケースでどこに格納するべきか？
まとめ
- CDN上で稼働するOIDC認証proxyを実装し運用
- Serverlessかつ高速なインフラ運用が可能
- ポータビリティの高い仕組みとして設計が可能
登壇資料
くりりん初手AI―AIエージェント中心の働きかたのための業務システム構築方法とシステム解説
西見公宏 / 大島勇樹 / 遠藤大介 (ジェネラティブエージェンツ)
AIエージェントに「仕事」を任せるにはどうすれば良いのか？
- AIがマネジメントをする組織
- AIエージェントが働く組織
- AIエージェントが稼ぐ組織
イベントトリガーから初手AIへ
AIとの協働スタイル
- スケールアップ
- ChatGPT等
- スケールアウト
- Devin等
- アンビエントエージェント
- Agent Inbox等 → 壮大なピタゴラスイッチが生まれる
なせピタゴラスイッチ感が出てしまうのか？
イベントに対して処理をするだけでは「業務」の遂行になっていない
- 例えば「お問い合わせ」1つ取っても、業務は「返信するだけ」ではない
- つまり、1つのイベントに対して複数のタスクがアドホックに存在しており、人間はそのタスクを上手く管理しながら業務を完遂させている
であれば、AIエージェント自身にタスク管理をさせれば良いのでは…？
コードネーム：タスクゼロ
人間がAIのタスクを管理する時代から、AIが人間のタスクを管理する時代へ = 「初手AI」を実現するためのプロダクト
ケーススタディ：研修サービス運営を初手AIにする
研修実施までのチェックリスト
- 申し込みから受講確定までの対応
- 見積書・請求書の作成・送付
- 参考書の手配するため出版社に連絡
- etc…
やることが漏れないように、チェックリストでのタスク管理が必要
研修の申し込み対応だけをとっても実はかなり大変
- 見積書を作成してだす
- リマインドする
- オンライン会議を調整する
本来、AIがタスクを管理して、AIにできないことは人間がやるべき
汎用エージェントとしてClaudeCodeを活用
モデルの性能向上により、具体的な業務マニュアルとツールがあれば、汎用エージェントがある程度の業務をこなすことが可能に
コーディングエージェントは最も簡単に使える汎用エージェント！
ワークフローを作り続けても業務の完全自動化を達成することはできない
現実の業務には例外対応がある
- カリキュラム前に説明を求められたら？ → オンライン会議を調整する
- 申し込み期限を延長が可能か社内で相談しつつ返信する
AI中心の業務システム
私たちが作っているのはいわば「AI中心の業務システム」
処理だけを考えていても上手く作れない → データ設計が必要
ここまでのまとめ
- AIがタスクを管理してAIに人間より先にタスクに対応させる
- AIが働くだけでなく人間も一緒に働く
- ワークフローを作り続けても業務の完全自動化を達成することはできない
初手AIのための設計思想とその裏側
現状のアーキテクチャの概要
- フロントエンドCloudRun Next.js
- バックエンド：CloudRun FastAPI
- AngentWorker：CloudRunジョブ
AIエージェントようにどんな環境が欲しいか
- AIエージェントごとに隔離されていること
- スケールしやすいこと
- 可能な限りステートフルであること
1と2までならよくあるサーバーレス環境でクリアできる
問題は3の「ステートフルであること」
- 今は既存のコーディングエージェントを利用している
- AIエージェントの作業をリトライさせたい場合がある
- チャットBotではないので、そこまで応答速度は不要
ステートをいかに管理するか
- コーディングエージェントはファイルで状態管理している
- 作業途中の成果物もファイルとして存在したりする
- ただ、タスク内は並列で動かず応答性能も妥協できる
ファイルの状態を世代管理できればリトライも含めて実装できるのではないか？
Google Cloudでどう実装したか
どうやって実装するか
- 仮想マシンをAIエージェントごとに起動させる？
- AgentCore使ってみる？
- なんだかんだCloudRunでは？
- Webアプリもサービスでデプロイできる
- ジョブを使えばいろいろと無茶できそう
CloudRunジョブで実装
- AIエージェントはCloudRunジョブで起動させる
- ステート管理はCloudStorageを利用する
まとめ
- イベントトリガーから「初手AI」へ
- タスク管理そのものをAIエージェントにハンドリングさせよう
- コンテキストエンジニアリングが業務実現のポイント
- タスクをAIエージェントに管理させ、かつ業務のコンテキストを必要十分に理解できるようなデータ設計を行うことが業務実現のポイント
- コーディングエージェントそのものがプロトタイピングに使える
- コーディングエージェントはファイル操作ができて任意のツールもつかえる「汎用エージェント」
- CloudRunジョブで起動すれば、完全に隔離された環境でエージェントを動作させることができる