AI が開発・運用しやすいクラウド　〜サーバーレスの視点から考える設計原則〜 / serverless-design-principles-for-ai-agent-era

©© 2026, 2026, Amazon Amazon Web Web Services, Services, Inc.
Inc. oror itsits affiliates. affiliates. AllAll rights rights reserved. reserved.

#AWS-49 AI が開発／運⽤しやすいクラウドサーバーレスの視点から考える設計原則 Daisuke Awaji Snr. Solutions Architect Amazon
Web Services Japan G.K. © 2026, Amazon Web © 2026, Services, Amazon Inc. or Web its Services, affiliates. Inc. All rights or itsreserved. affiliates. All rights reserved.

Agenda • コンテキストエンジニアリング • 最適なソフトウェアの構造を考える • 最適なサーバーレスアーキテクチャを考える • まとめ ©
2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Daisuke Awaji Amazon Web Services Japan Solutions Architect @gee0awa Serverless,
Generative AI, Frontend ❤ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5

ソフトウェア開発・運⽤を AI に委譲できるか開発者 CI/CD GitHub AWS Cloud AWS Cloud（A省
Xシステム）本番環境テスト環境 GitHub Issue / PR （機能追加リクエスト）要件定義バックログ管理開発エージェントエンドユーザーヒアリングログ・メトリクス・アラート・・・運⽤エージェント実装・テストセキュリティレビュー GitHub Issue / Pull Request 起票 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 異常検知原因特定是正措置傾向分析

ソフトウェア開発・運⽤を AI に委譲できるか AWS Cloud AWS Cloud（A省 Xシステム） AI エージェントにとって開発・運⽤しやすくするには
クラウドの構成やソフトウェアをどう設計すべきか︖ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Multi-agent Orchestration Chat on AgentCore Bedrock AgentCore で稼働する AI エージェントの
OSS サンプル – 通称 MOCA プロンプトやツールをカスタマイズし、コーディングエージェントや運⽤エージェントも作れるパソコンでもスマホでも（モバイルフレンドリーなチャットUIのサンプルとして） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. AI エージェントを作る（システムプロンプト・ツールを組み合わせて） https://github.com/aws-samples/sample-multi-agent-orchestration-chat-on-agentcore

コンテキストロット（腐敗） T すべての LLM は⼊⼒⻑・プロンプト⻑に応じて性能が劣化する 18 モデル全てで劣化を確認 Claude Sonnet 4,
GPT-4.1, Gemini 2.5 Flash, Qwen3-32B を含むウィンドウに余裕がある場合でも早い段階から劣化が始まる問題は容量ではなく、ノイズの蓄積 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 出典 : Chroma Research (2025) — 18 frontier models evaluation

何トークンから精度の壁を感じますか︖ AWS Japan の SA ロールを対象にアンケートを実施 16 14 12 10
8 6 4 2 0 ~100K 100K~200K 200~300K © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 300K~400K Opus 4.7 Opus 4.6 400K~500K 500K~600K 劣化を感じない ※ Opus 4.7, 4.6 の最⼤コンテキストウィンドウ: 1M Token ※ このアンケートは体感ベースで、ベンチマーク値ではありません。

何トークンから精度の壁を感じますか︖ AWS Japan の SA ロールを対象にアンケートを実施 16 400K トークン 14
程度でも劣化を感じる 12 10 8 6 4 2 0 ~100K 100K~200K 200~300K © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 300K~400K Opus 4.7 Opus 4.6 400K~500K 500K~600K 劣化を感じない ※ Opus 4.7, 4.6 の最⼤コンテキストウィンドウ: 1M Token ※ このアンケートは体感ベースで、ベンチマーク値ではありません。

コンテキストウィンドウ System Prompt AGENTS.md Builtin Tools MCP Tools User message
Read () Search () Read () ソースコードセッションの初期化 ◯◯機能を実装する計画を⽴てて Test () … © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. model view controller infrastructure Assistant message User message Write () Lint () src/ 実装計画を⽴てました docs/ skills/ 実装を開始して︕︕ README.md AGENTS.md

コンテキストウィンドウ System Prompt AGENTS.md Builtin Tools MCP Tools User message
Assistant message Smart Zone 精度良くコーディングできる領域 400 K token（経験則、⽬安） Dumb Zone 精度が劣化する領域 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

コンテキストウィンドウ System Prompt AGENTS.md 不要なノイズとならないコンテキスト管理を⼼がける Builtin Tools Smart Zone
MCP Tools 精度良くコーディングできる領域 User message Assistant message 400 K token（経験則、⽬安） Dumb Zone 精度が劣化する領域 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

ノイズとして取り込まれる要素の例コンテキストウィンドウに含まれる要素はソースコードだけではない • コードベースの調査において読み込んだファイル • Lint, Build, Test, Deploy の実⾏ログ
• 実装したソフトウェアの起動・実⾏・操作ログ • MCPサーバーから提供されるツールの結果（ウェブ検索など） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

セッションを要約して切り替えるコンテキストウィンドウ新しいセッション System Prompt AGENTS.md Builtin Tools MCP Tools
System Prompt AGENTS.md Builtin Tools MCP Tools User message Assistant message 調査した結果や実装計画圧縮したドキュメント © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. このやり⽅では上⼿くいかなかったからこう実装して User message 調査した結果や実装計画圧縮したドキュメント Assistant message

セッションのコンパクション（圧縮）コンテキストウィンドウの限界に近づいた会話を要約し、新しいウィンドウで再開する実装計画を⽴て、要件を整理した計画書を引き継ぎ、新しいセッションを始める Compacted Documents web_search(…) Build, Lint, Test… grep,
find… read_file(…) か edit_file(…) カオスな会話履歴探索のノイズ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. ノイズのフィルタリング圧縮されたドキュメント・実装計画書

コンテキストエンジニアリング 1M のコンテキストウィンドウがあるからといってすべて精度良く読めるわけではない。 • コンテキストウィンドウは貴重で有限なリソース • 多くの情報を詰め込むだけでは、ノイズになる • 必要最⼩限の⾼品質な情報を厳選するコンテキストウィンドウ
〜400K Token 1M = 1000K Token ノイズが溜まり性能劣化を感じ始める（経験則） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

主要なシステムのコード量 1 LOC（⾏数） = 10 Token 程度ではあるが、実際には１万⾏程度でもコンテキストに収まりずらい⼩規模中規模⼤規模
〜１万⾏１万〜１０万⾏１０万⾏〜部⾨内の⼩さなウェブシステムや単機能の Web API © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⼀般的な部⾨業務システム基幹系の１サブシステム典型的な業務システム本体（受発注、在庫、販売管理など）出典︓IPA「ソフトウェア開発分析データ集」に基づく概算

主要なシステムのコード量 1 LOC（⾏数） = 10 Token 程度ではあるが、実際には１万⾏程度でもコンテキストに収まりずらい１万⾏のコードベースですら完全に意図通りに AI
はコーディングできないことを前提においた戦略が必要 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

全てのコンテキストを凝集するコーディングエージェントが効果的に計画・実装するには全てのコンテキストを１つのリポジトリに凝集することが理想的 • ソースコード • IaC (Infrastructure as Code)
のソースコード • 設定ファイル • 設計ドキュメント • エージェントのステアリングファイル © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. など

Monorepo による解決策の例インフラ定義、各種バックエンド、共有ライブラリ、テスト、CI/CD までを１つのリポジトリで管理します。規模やフェーズに応じて判断が必要です。開発初期においては特にモノレポが⾒通しが良い場合があります。 Polyrepo Monorepo Service A repo
Service A repo Service B repo Shared Library サービスごとにリポジトリを分割して管理する © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Service B repo Shared Library 関連するソースコードを１つのリポジトリに閉じ込める、まとめて管理する ※ AI エージェントから⾒て『近接して読める』ことが重要です。 Polyrepo でも、明⽰的なクロスリポインデックスで実現できます。

Monorepo におけるディレクトリ構成の例典型的なウェブアプリの場合（TypeScript を想定） README.md リポジトリの全体像 AGENTS.md エージェント向けのステアリングファイル skills/ エージェント向けの
Skills （ステアリングファイルとスクリプト） docs/ 設計、特にソフトウェア構造上の意図を残す packages/ libs/ frontend/ backend/ Infra/ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 👍

Monorepo におけるディレクトリ構成の例典型的なウェブアプリの場合（TypeScript を想定） README.md リポジトリの全体像 AGENTS.md エージェント向けのステアリングファイル skills/ エージェント向けの
Skills （ステアリングファイルとスクリプト） docs/ 設計、特にソフトウェア構造上の意図を残す packages/ libs/ 共通的なライブラリ frontend/ フロントエンド backend/ バックエンド（さらに複数のサービスに分割しても良い） Infra/ Infrastructure as Code のソースコードと設定ファイル © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 👍

Monorepo の弱点と考慮するポイント１つのリポジトリで全てのファイルにアクセスできる⼀⽅でコードベースが肥⼤化する。何も⼯夫をしなければ、エージェントは⼤量のファイルを読み込み、コンテキストウィンドウを圧迫する。パッケージの依存関係を最⼩限にし、細部を⾒なくても理解できる構造を作る 💦 © 2026, Amazon
Web Services, Inc. or its affiliates. All rights reserved.

実装の細部を読まずとも理解できる状態を作るドキュメントを詳細に記述し、AI に理解させることはできないか︖ AI が読んだドキュメントドキュメント Repository Package Directory File
実装に必要な領域だけ参照することができる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

ドキュメントは腐る、実装と乖離が進む実装とのズレハルシネーションの数ドキュメントだけに頼らないソフトウェアの構造において⼯夫が必要実装（動くコード） © 2026, Amazon
Web Services, Inc. or its aﬃliates. All rights reserved. コードコメントドキュメント仕様書 ※ドキュメント管理を完全に否定するものではありません。補完的な仕組みが必要です。

インターフェースはシンプルに、機能は深く（複雑な処理を内部に隠蔽する）設計することで、全体の複雑性を減らす John Ousterhout A Philosophy of Software Design,
2nd Edition – ソフトウェア設計の哲学 - © 2026, Amazon Web © 2026, Services, Amazon Inc. or Web its Services, affiliates. Inc. All rights or itsreserved. affiliates. All rights reserved.

Shallow Module と Deep Module 優れたモジュールはシンプルなインターフェースと深い機能をもつ（複雑な処理を内部に隠蔽している）インターフェース（薄く）実装（深く） Deep Module
© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Shallow Module

Shallow Module と Deep Module 優れたモジュールはシンプルなインターフェースと深い機能をもつ（複雑な処理を内部に隠蔽している）インターフェース（薄く）コーディングエージェントがインターフェースだけを読んで意思決定できる状態を⽬指す
Deep Module © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 実装（深く） Shallow Module

Deep Module の良い例 – Unix File I/O 適切に抽象化されたインターフェースは利⽤者の認知負荷が低く、複雑性の低いモジュールフラグ READ/WRITE
を指定ファイルパスどのファイルシステムかは気にしなくて良い © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. ※ mode オプションは省略しています。

アーキテクチャの不変条件を強制する依存できるインターフェース / 型定義だけでは強制できない構造的なルールに対して制約を設ける制約はドキュメントではなく、リンターや構造テストによって機械的に適⽤する例） Node.js
eslint-plugin-boundaries Java ArchUnit など Config Handler Service Repository ❌ データベースや外部の API には Repository から接続する © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

サービスクラスのインターフェースの例問題このインターフェースを読めば、実装の振る舞いが伝わるでしょうか︖ ユーザーの id を指定して、ユーザーを１件取得する・・・︖ 型レベルで警告が出ない ©

型表現の強化（TypeScript の場合）オブジェクト指向プログラミングにおける Value Object でも良い。「ただの string ではなく、検証済みの UserId
だ」と型レベルでコーディングエージェントに伝える © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

サービスクラスのインターフェースの例 Before After （型表現の強化）強化された型表現実装時に型レベルで警告が出る状態を⽬指し、 AI にフィードバックする〜〜〜〜〜〜〜
© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Web API としてのインターフェース Web API = Web Application Programming “Interface”
Client © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Web API Backend

Web API における Deep Module の例 – S3 適切に抽象化されたインターフェースは、認知負荷の低い複雑性の低いモジュール S3
API s3.put_object( Bucket=“yourbucket”, Key=“key”, Body=data ) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 認証 + TLS 終端ルーティング + ロードバランシングデータ分割、整合性検証暗号化（SSE）複製、耐久性保証メタデータの更新イベント発⽕など

OpenAPI Specification REST 形式の API 仕様を定義する標準的な規格 JSON/YAML 形式のファイルから、API ドキュメントや、クライアントコード、バリデーション⽤のサーバーサイドコードを⽣成することも可能に
© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Git 管理するドキュメントには何を書くべきか︖ ソフトウェアの構造を⼯夫して、AI の可読性を向上させる。特に、読んでわからない⽂脈や意思決定の背景をドキュメントに残す。 WHAT 現在の振る舞い HOW どう動くか WHEN,
WHO いつ誰が WHY, WHY NOT なぜそうなっているか情報の種類 Source of Truth 型・API・スキーマ・テーブル定義インターフェース、型、 OpenAPI Spec、テストコードアルゴリズム・実装の詳細コード変更の事実 Git のログ意思決定の⽂脈、棄却された選択肢コードコメント、ドキュメント © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. （特にアーキテクチャ決定レコードなど）

インターフェースは「認知できて、制御できる」境界各インターフェースで隠蔽してきたもの関数命令と⼿続きクラス状態と振る舞いモジュール内部実装と依存 Web API
プロセス・⾔語・インフラストラクチャ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

インターフェースは「認知できて、制御できる」境界各インターフェースで隠蔽してきたものサーバーレスは AI の認知的な資源 “コンテキスト” を命令と⼿続き本質的な設計判断に使わせる状態と振る舞い
関数クラスモジュール内部実装と依存 Web API プロセス・⾔語・インフラストラクチャ © 2026, Amazon Web Services, Inc. or its affiliates. aﬃliates. All rights reserved.

各パッケージにおいて考慮するポイントここまでのまとめ – “インターフェースは最⼤のコンパクション” • “薄い”インターフェースと、”深い”実装適切なモジュール境界を⾒極めて分割する。ドキュメントには WHY, WHY
NOT を記す。 • モジュール単位に機能凝集されたテストコード不必要なモックを避け、外部依存度の低いロジックをテストする。 • 決定論的な仕掛けで AI にフィードバックするアーキテクチャの不変条件、依存の向き、強化された型情報を検証する。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

AI エージェントから⾒た開発者体験の要件 AI が「⾃律的にフィードバックループを回せるか」を起点に考える ① 依存関係のあるコード・パッケージが適切に分割されていること ② ローカル環境での動作確認、テストが素早く実⾏できること ③
インフラをコードとして管理し、デプロイができること © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

サーバーレスの開発者体験を考える単⼀の Lambda Function にはどれくらいのコード量を載せるべきか Amazon API Gateway ©
2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Lambda Amazon DynamoDB

サーバーレスの開発者体験を考える単⼀の Lambda Function にはどれくらいのコード量を載せるべきか event Amazon API Gateway
© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Lambda Amazon DynamoDB handler 関数をどのようにテストするか︖

サーバーレスの開発者体験を考える単⼀の Lambda Function にはどれくらいのコード量を載せるべきか event Amazon API Gateway
AWS Lambda Amazon DynamoDB 外部依存するコードはどうユニットテストするか︖ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. handler 関数をどのようにテストするか︖

Lambda 特有のコード例 Lambda 特有のコード例クエリパラメータから userId を受け取り、データを取得して返すエントリポイントが handler event
の構造が独⾃外部に依存するコードをベタ書きしがち © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

テストコードはどうなるか︖ Lambda 特有のコード例 DynamoDB クライアントのモック APIGatewayProxyEvent を丸ごと⼿組みしなければいけない関⼼度のあるプロパティに絞りたい⽂字列を再度
パースしなければいけない © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Lambda Web Adapter Lambda で Web アプリを実⾏するための OSS ツール、 Rust
製の Lambda Extension 2026/03/28 に v1.0.0 がリリース • Lambda ランタイム API の汎⽤アダプター event http • 関数本体コードの依存関係はない • あらゆる Web フレームワークをサポート • あらゆるプログラミング⾔語をサポート Lambda Web Adapter • 既存のツールを使⽤して • ローカルで開発 https://github.com/awslabs/aws-lambda-web-adapter © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. • ローカルでテスト

Node.js アプリでの使⽤例 Lambda Web Adapter をインストールするには Dockerfile に１⾏追加するだけコンテナイメージは Lambda
以外の環境でもそのまま利⽤できる Install lambda web adapter を追加するだけ︕ ※ Docker 形式に限らず、 Zip 形式のアップロードでも Lambda Web Adapter を使⽤できます。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. https://github.com/aws/aws-lambda-web-adapter

フィードバックループを⾼速化する LWA コーディングエージェントは Lambda を意識する必要がなくなり、ビジネスロジックの実装に集中できます。（Lambda 特有の event, context など）
• エミュレータ不要のローカル起動ホットリロードもフレームワークの仕組みで⾃由に構築できる • テスト⽣成・実⾏ HTTP リクエストを介するテストフレームワークが採⽤できる Node.js なら supertest, ⼈が実⾏するなら Postman など • イテレーションの⾃律化ローカル起動、リクエスト送信、結果確認のループをエージェントが単独で回せるフロントエンドもローカルで起動すれば UI の操作を含めてエージェントに委譲できる ※ ⼩さなコードや軽量な処理、関数単位にデプロイしたい場合、ウェブフレームワークに対する依存を嫌う場合は LWA は推奨しません。 AWS SAM Local なども併⽤して軽量な構成で実装しても同様の開発しやすい構造が⼿に⼊ります。全てはトレードオフ、私は AWS SAM が⼤好きです。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Lambda 関数に何を含めるべきか /* Client /getuser /getusers /getproduct /getproducts /createuser /createproduct
/updateuser /updatepoduct /deleteuser /deleteproduct DynamoDB API Gateway Routing logic in function “Lambda-lith” © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Lambda 関数に何を含めるべきか /* Client /getusers /getproduct /getuser /getusers /getproduct /getproducts
/createuser /createproduct /updateuser /updatepoduct /deleteuser /deleteproduct /getproducts /createuser /createproduct DynamoDB API Gateway /getuser Client API Gateway /updateuser DynamoDB /updateproduct Routing logic in function /deleteuser /deleteproduct “Lambda-lith” © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. “Micro Lambda”

Lambda 関数に何を含めるべきか /getuser /getusers /createuser /updateuser /deleteuser グループ化の例 • •
• • • • • 境界付けられたコンテキスト開発組織の構造 IAMパーミッションのスコープ共通的なコードの依存関係配下のリソースとの依存関係初期化時間とコールドスタートメモリ割り当て Client API Gateway /getproduct /getproducts /createproduct /updateproduct /deleteproduct DynamoDB （User） DynamoDB （Product） “Pragmatic Lambda” © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. ※境界づけられたコンテキストで分割した例

Monorepo の package 単位でデプロイする README.md / AGENTS.md packages/ user-service/ /getuser
/getusers /createuser /updateuser /deleteuser src/ index.ts etc.. product-service/ src/ index.ts etc.. /getproduct /getproducts /createproduct /updateproduct /deleteproduct DynamoDB （User） types/ libs/ ・・・ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. DynamoDB （Product）

Monorepo の package 単位でデプロイする README.md / AGENTS.md packages/ user-service/ マイクロサービスとして
独⽴したデプロイできる Deploy /getuser /getusers /createuser /updateuser /deleteuser src/ index.ts etc.. import product-service/ src/ index.ts etc.. /getproduct /getproducts /createproduct /updateproduct /deleteproduct DynamoDB （User） types/ libs/ ・・・ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. DynamoDB （Product）

Monorepo の package 単位でデプロイする README.md / AGENTS.md packages/ user-service/ マイクロサービスとして
独⽴したデプロイできる Deploy /getuser /getusers /createuser /updateuser /deleteuser src/ index.ts etc.. product-service/ src/ import Deploy index.ts etc.. types/ libs/ ・・・ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. モノレポの利点を活かすインターフェースや共通処理を参照して実装可能 /getproduct /getproducts /createproduct /updateproduct /deleteproduct DynamoDB （User） DynamoDB （Product）

HTTP 以外のトリガーにも対応 Lambda Web Adapter は、SQS、SNS、S3、DynamoDB、Kinesis、Kafka、EventBridge など、 HTTP 以外のすべてのイベントトリガーをサポートしています。 event
環境変数 AWS_LWA_PASS_THROUGH_PATH=/events AWS Lambda Amazon SQS event Amazon S3 AWS Lambda event Amazon DynamoDB AWS Lambda © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. HTTP POSTリクエストを使⽤して、設定可能なパス（デフォルト /events）に⽣のイベントペイロードを Webアプリケーションに転送します。

DynamoDB Local Docker や JVM で起動する DynamoDB のローカルエミュレータロジックの検証は DynamoDB
Local で⾼速にテストする。 IAM 認可など、統合テストはクラウド環境の DynamoDB も併⽤する。 const client = new DynamoDBClient({ endpoint: "http://localhost:8000", … }); クラウドの DynamoDB にアクセスせずにローカル / CI環境で⾼速にテスト可能に例）http://localhost:8000 で起動アプリケーション（ローカル環境） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon DynamoDB Local （ローカル環境） https://hub.docker.com/r/amazon/dynamodb-local

サーバーレスの開発者体験を考える単⼀の Lambda Function にはどれくらいのコード量を載せるべきか “Pragmatic Lambda” コンテキスト境界やリソース権限など Amazon
API Gateway LWA で Web フレームワークと同様のテスト戦略を適⽤する AWS Lambda Amazon DynamoDB DynamoDB Local でモックテストの乱⽴を防ぐ外部依存するコードはどうユニットテストするか︖ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. handler 関数をどのようにテストするか︖

クラウドを運⽤する AI エージェント従来の運⽤⾃動化（Runbook や監視ツール）を超えて、⾃律的に観測・判断・実⾏・学習し、運⽤業務を担う観測判断実⾏
学習クラウドリソースのテレメトリの収集仮説⽣成と検証根本原因の特定インフラ設定の変更コードの修正過去のインシデント対処履歴 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

機械的な運⽤と、⾃律的な運⽤考えなくても即座に反応すべき事はクラウドネイティブな仕組みに任せ、運⽤エージェントは「⼈間の判断が必要な領域を、⼈間より先に準備する」担当クラウドの機械的運⽤マネージドサービス⾃律的運⽤運⽤エージェント ©
2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 動作例決定論的即時反応オートスケーリング、フェイルオーバー、レート制限など推論的⼈間の介在を求めるログ、メトリクスなどの各種テレメトリを観測、判断し、設定変更の Pull Request を起票する

運⽤エージェントが必要とするコンテキスト • ランタイムテレメトリ AWS Cloud AWS Cloud（A省 Xシステム）ログ・メトリクス・トレース・アラート •
アーキテクチャ情報サービス境界・依存関係・IaC（CDK） • 設計意図 SLO・アラートの閾値・リトライ戦略 • 運⽤の記憶過去のインシデント履歴・ランブックログ・メトリクス・アラート運⽤エージェント異常検知原因特定傾向分析 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

現実世界のサーバーレスアーキテクチャ分散されたログが CloudWatch Logs/Metrics Amazon API Gateway AWS Lambda 全てのテレメトリを
調査するとコンテキストウィンドウが⾜りない 💦 CloudWatch Logs/Metrics CloudWatch Logs/Metrics Amazon DynamoDB Lambda の⾔語が違うとログの構造もバラバラに AWS Lambda 運⽤エージェント © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon SQS CloudWatch Logs/Metrics トレースできない Amazon S3 サービスの境界はどこ︖ AWS Lambda CloudWatch Logs/Metrics CloudWatch Logs/Metrics

運⽤エージェントが必要とするコンテキスト • ランタイムテレメトリ AWS Cloud AWS Cloud（A省 Xシステム）ログ・メトリクス・トレース・アラート •
アーキテクチャ情報サービス境界・依存関係・IaC（CDK） • 設計意図 SLO・アラートの閾値・リトライ戦略 • 運⽤の記憶過去のインシデント履歴・ランブックログ・メトリクス・アラート運⽤エージェント異常検知原因特定傾向分析 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

運⽤エージェントが必要とするコンテキスト運⽤しやすい構造や仕組みを整える必要がある • ランタイムテレメトリ AWS Cloud AWS Cloud（A省 Xシステム）
ログ・メトリクス・トレース・アラート • アーキテクチャ情報サービス境界・依存関係・IaC（CDK） • 設計意図 SLO・アラートの閾値・リトライ戦略 • 運⽤の記憶過去のインシデント履歴・ランブックログ・メトリクス・アラート運⽤エージェント異常検知原因特定傾向分析 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

サーバーレスにおける可観測性の勘所 Logs / Metrics / Traces をトレースID でつなぐ Logs
を構造化して相関 ID でつなぐサービス境界ごとに CloudWatch Log グループを分離する JSON 形式に構造化し、トレースID、ユーザーIDを含める Metrics をビジネス指標に CloudWatch 標準メトリクスに加えて、 EMF（Embedded Metric Format）でビジネス的な KPI も出⼒する Traces でボトルネックを可視化分散されたコンポーネントをトレースし、コールドスタート、スロットリング、ダウンストリームのレイテンシのボトルネックを特定する（CloudWatch / AWS X-Ray の機能を集約した CloudWatch Application Signals などを活⽤） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

ソフトウェア開発・運⽤を AI に委譲できるか開発者 CI/CD AWS Cloud AWS Cloud（A省 Xシステム）
GitHub 本番環境テスト環境 GitHub Issue / PR （機能追加リクエスト）要件定義バックログ管理開発エージェントエンドユーザーヒアリングログ・メトリクス・アラート・・・運⽤エージェント実装・テストセキュリティレビュー GitHub Issue / Pull Request 起票 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 異常検知原因特定是正措置傾向分析

AI が開発／運⽤しやすいクラウドの設計原則 Key Takeaway - コンテキストの圧縮を、ドキュメントだけでなく、アーキテクチャで実現する • コンテキストロットノイズの蓄積により精度は落ちる前提を受け⼊れる •
Pragmatic Lambda / Architecture Package や Lambda を実⽤的で AI が管理可能な粒度で分割する • インターフェース・コンパクションサービス間の境界をインターフェースだけを読めばわかる状態を設計する • エージェント・オブザーバビリティ運⽤エージェントの⽬線でログ・メトリクスのサービス境界を設計する © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.

AI が開発・運用しやすいクラウド 〜サーバーレスの視点から考える設計原則〜 / server...

AI が開発・運用しやすいクラウド 〜サーバーレスの視点から考える設計原則〜 / serverless-design-principles-for-ai-agent-era

More Decks by geeawa

Featured

Transcript

AI が開発・運用しやすいクラウド　〜サーバーレスの視点から考える設計原則〜 / server...

AI が開発・運用しやすいクラウド　〜サーバーレスの視点から考える設計原則〜 / serverless-design-principles-for-ai-agent-era