AgentCore Runtime上にAgentic Coding基盤を構築・展開する際の設計ポイントと限界点 / Design considerations and limitations when building an agentic coding platform on AgentCore Runtime

2026/09/19 (土) ServerlessDays Tokyo 2026 Cトラック 13:30-13:55での登壇資料です

Transcript

1. AgentCore Runtime上に Agentic Coding基盤を構築・展開する際の 設計ポイントと限界点 2026/09/19 (土) ServerlessDays Tokyo 2026 福地開
2. Who am I ? 福地 開 (ふくち はるき) @har1101mony 所属：某Sier子会社 / JAWS-UG東京 業務：AWSエンジニア / エージェントビルダー 実績：AWS Community Builders 2年目 (AI Engineering) 2026 Japan All AWS Certifications Engineers 趣味：筋トレ、クラフトビール 目標：1つでも多くAIにできないことをできるようになる
3. 今日話すこと・話さないこと ◆話すこと • なぜクラウド基盤×コーディングエージェント？ • アーキテクチャ • 設計や実装のポイント • 本構成での限界点 ◆話さないこと • AgentCoreなど各種AWSサービスの詳細 • コーディングエージェントのハーネスの詳細 ※本資料は温かみのある手作業にて作成しました
4. なぜクラウド基盤×コーディングエージェント？
5. これからはクラウドエージェントや！ ◆という時代の潮流に乗ったわけではないです • 一応プロジェクト自体は今年の頭くらいから動いていた • 最近だとこの辺のブログが話題？↓ただこの辺の話は今日はしません https://zenn.dev/sc30gsw/articles/953334f11df507 https://cursor.com/ja/blog/cloud-agent-lessons
6. 環境構築の個人差、認証情報の統制、PC電源の制約、コスト可視化問題 コーディングエージェントをローカルで動かす ◆皆さん手元のコーディングエージェントに指示を出す方が多いはず • PCを閉じても作業継続してくれるように設定している方も多いでしょう • 個人で使う場合やスピードを重視する場合はほとんどこれで問題ない • (もちろんクラウドで動かしている方もいるでしょうが)
7. 環境構築の個人差、認証情報の統制、PC電源の制約、コスト可視化問題 コーディングエージェントをローカルで動かす ◆組織でコーディングエージェントを導入するにはいくつか障壁が… • 端末のスペック問題 • Skillなどハーネスの共有 • 環境構築が個人に委ねられる • 利用者個々人の理解度の差が激しい • 認証情報・コストなどのガバナンス問題 • ツールだけ配っても使われるとは限らない
8. コーディングエージェントはあくまでツール ◆“コーディングエージェントを使うこと”を目的に導入するのではない ◆組織の生産性向上やプロセス変革のために使うはず • 組織の成熟度次第で多少差はあれど目的があるはず • であればツールの導入に時間をかけるのは本質ではない
9. 全員がツールを同じ用に使いこなせるのか？ ◆ツールの使い方は人それぞれ ◆さらにAIエージェントはランダム性を持つ • 使うのが上手い/慣れている人とそうでない人で成果物に差が生まれる • 組織で使う場合、できるだけその差を無くす方向に動きたい
10. 全員がツールを同じ用に使いこなせるのか？ ◆組織向けに作成したハーネスで動くコーディングエージェントを 社員がサクッと使えるようにしたい • そこでWebアプリでコーディングエージェントを使えるようにしてみた • 使い方の統率が取れ、コストも(ある程度)可視化できる • 利用者ごとの環境整備手順が省ける
11. 簡単なデモ 現地のみ
12. アーキテクチャと 設計・実装のポイント
13. アーキテクチャ • 認証：Cognito • フロント： CloudFront+S3 • バック： AppSync+Lambda+ Aurora DSQL+S3 • エージェント： AgentCore Runtime (Claude Agent SDK)+ Bedrock(Claude) ※一部簡略化しています
14. 設計時の考慮ポイント ◆大前提：ローカルで動かす際とは大きく異なる 1. サーバーレスの特性を理解する 2. コーディングエージェントは自律的に長時間動く 3. Human in/on the Loopをどう実現するか 4. 環境分離 5. コスト記録と管理
15. 1. サーバーレスの特性を理解する ◆サーバーレスの特性を理解してコーディングエージェントを動かす • 特にステートレスとイベントドリブン 画像：https://speakerdeck.com/gawa/server-less-code-more?slide=44
16. ステートレスゆえに生成物を外部で保持する ◆コーディングエージェントがドキュメントやコードを生成する • コンピューティングリソースで保持はできない(終了とともに揮発する) • 外部で保持する仕組みが必要 画像：https://speakerdeck.com/gawa/server-less-code-more?slide=63
17. ステートレスゆえに生成物を外部で保持する ◆本構成ではS3とAgentCore Runtimeを連携 • AgentCore Runtime上のClaudeエージェントは成果物をS3へ格納 →アプリ側でこれを画面に表示するようにしている • 成果物がS3内に格納されるので、AgentCore Runtimeが停止しても大丈夫 ※利用者から渡されるコンテキストや使用するハーネスをインプットする役割も
18. 余談：SkillはGitHubから共有 ◆Skill専用リポジトリから最新版を常に共有 • GitHubにPRがマージされるとGitHub Actionsが稼働し、S3へアップロード • エージェントは実行時にこのSkillを読み込んで動く
19. 2.コーディングエージェントは自律的に長時間動く ◆サーバーレスなコンピューティングリソースの実行時間制限 • Lambdaは基本最大15分 • 最近は伸ばす方法も出ている • マネージドインスタンスなら90分までOK • 少し特殊だがdurable functionやMicroVMなどもある • 昨日サーバーレス&AIエージェントめちゃつよSAさんに挟まれる夢のような時間があり、 Lambda MicroVM良いぞと説かれてキャッチアップ不足を晒しました • AgentCore Runtimeも基本は15分 • ECS(Fargate)なら時間はクリアだけどコスト面が少しネック • 環境分離も考慮が必要？ • App Runnerは新規受付停止
20. 2.コーディングエージェントは自律的に長時間動く ◆サーバーレスなコンピューティングリソースの実行時間制限 • AgentCore Runtimeの非同期処理なら、最長8時間稼働できる • また、基本性能としてセッションごとの環境分離が自動的に行われる →他ユーザーの実行環境とは、マイクロVM単位で分離される 引用：https://docs.aws.amazon.com/ja_jp/bedrock-agentcore/latest/devguide/runtime-how-it-works.html
21. AgentCore Runtimeを非同期で動かす ◆本構成ではLambdaからAgentCore Runtimeを起動する • AgentCore Runtimeは非同期実行するようにロジックを書く • これによってサーバーレスアーキテクチャながらコーディングエージェント を長時間動かすことが可能 ※Lambdaリゾルバーは別途DBと接続していたり、 EventBridgeは別経路でのエージェント起動も担っていたりする
22. 処理内容はどうやって画面に表示する？ ◆非同期実行だとAgentCore Runtime内で処理が完結する • 普通にリクエストを送ってレスポンスが返ってくるわけではない • 別途処理内容を画面に描画するための仕組みが必要 • Q.そもそもなぜ画面に処理内容を描画する必要が？ • A.処理完了までの数時間、一切画面が更新されないアプリは 流石に不安じゃないですか…？
23. 処理内容はどうやって画面に表示する？ ◆本構成ではAppSync Eventsを用いている • クライアント/サーバーでの双方向通信を簡単にするサーバーレスサービス • WebSocketベースのPub/Sub機能を提供するサービス • パブリッシャー(AgentCore)がHTTP POSTでチャネルにイベントを送信し、 サブスクライバー(ブラウザ)がWebSocketでチャネルを購読してイベントを リアルタイムに受信する流れ
24. 余談：AppSync Events初めて使いました ◆AppSync Eventsは私のボスとAWSのAさんが使っていて知りました 引用： https://qiita.com/Kota__Sasaki/it ems/a5008e550de8fa01dc61 引用：https://github.com/awssamples/sample-multi-agentorchestration-chat-on-agentcore
25. 余談：ストリーミングレスポンスは奥が深い ◆普通のストリーミングレスポンスはYさんの解説がわかりやすいです 引用： https://speakerdeck.com/takuyay 0ne/20260228-jaws-beginnerkansai 引用： https://speakerdeck.com/takuyay0 ne/tuo-fen-wei-qi-shi-zhuangagentcorewoliang-igan-ziniwebapurikesiyonnizu-miipmutameni
26. 3. Human in/on the Loopをどう実現するか ◆Human in the Loop：プロセスに人間の介入があること(ざっくり) • コーディングエージェントの文脈では… 小さいものだと、「このコマンド実行していい？」→ yes/noで人間が回答 発展して、「設計これでいい？」→ yes/修正
27. 3. Human in/on the Loopをどう実現するか ◆HITLとサーバーレスは相性があまり良くない(と思っている) • 人間に一度確認を促す段階で処理が一度終わる ＝サーバーレスはステートレスなので、普通だと途中からの再開ができない ＝続きはここから、というステート管理(状態管理)をする必要がある (ローカルだと考慮しなくて良いポイント) • Lambda durable function / Step Functionsなら割と楽に実現はできる • AgentCoreは、自分で頑張ろう！！！！！
28. HITLのためのステート管理(一例) ◆AppSync + Lambdaリゾルバー + Aurora DSQLで管理 • LambdaリゾルバーがDSQLにジョブ開始ステータスを登録 • その後、Lambdaからエージェントを非同期で呼び出す (本当はEventBridge+Lambda経由ですが図では簡略化のため省略) • DSQLのステータスは画面表示でも一部用いている
29. HITLのためのステート管理(一例) ◆AppSync + Lambdaリゾルバー + Aurora DSQLで管理 • エージェントがHITLを必要としたら、AppSync → Lambda経由でDSQLに ジョブ中断ステータスを登録する • 会話履歴をS3に保管し、エージェントは一度終了
30. HITLのためのステート管理(一例) ◆AppSync + Lambdaリゾルバー + Aurora DSQLで管理 • ユーザーからの回答を受け取ったら、AppSync→Lambda→DSQLの経路で ジョブ再開ステータスに更新する • 同じセッションIDでエージェントを再度呼び出す • 会話履歴や生成物はS3から再度取得する
31. ステート変更イベントをトリガーにする ◆ジョブが開始/中断/再開/完了/失敗したことがトリガー • それぞれ適切なEventBridgeが起動してエージェントが動いたり、 完了/失敗したらメールが届いたりする
32. 4. 環境分離 ◆他プロジェクト・ジョブの内容を見れないようにする
33. 5. コスト管理 ◆プロジェクト単位でのコストを集計している • Bedrockの入力/出力トークン + SDK由来のリクエスト数をDSQLに集約 • Claude Agent SDKのResultMessageからトークン数を取得している • IAMプリンシパルコスト割り当て、アプリケーション推論プロファイル、 コスト配分タグなどは使用していない
34. 余談：コスト管理MCPも用意している ◆管理者(私)が手元のコーディングエージェントで確認できるように • Claude CodeにAgentCore Gatewayを繋いでいる • AgentCore Gatewayの認証にはSSOでCognito×IIC×Entra IDを連携している (詳細は拙ブログ参照) https://qiita.com/har1101/items/94431fc27776443170e7
35. 本構成での限界点
36. 成果物の検証 ◆現状はまだコードやテストの生成と軽微な検証しかできない • レビューは一応できるが、エディタではないので見にくい • 実際に環境へのデプロイなどをしたい場合はローカルに持っていくしかない • Cursor/Claude Code/Codexのクラウド環境とは異なり、GitHubとの連携が できない、CICDパイプラインなどと繋げない
37. デバッグ・評価でお金が溶ける ◆修正の度、E2Eテストで毎回長いハーネスを通す必要がある • Claude Agent SDK/AgentCore Runtimeの仕様などで アプリがきちんと動かないケースがあったので確認必須 • もちろんハーネス側のテストも兼ねている • 結果、実行のたびにトークンが燃やし尽くされる
38. 車輪の再発明感が否めない ◆既存のコーディングエージェント使えばよくね？ • 特に普段からCodexなどを使っている身としては… • 色々訳あって現在のモノを作っています
39. 上位互換がいっぱいありそう！ ◆MOCA(Multi-agent Orchestration Chat on AgentCore)凄すぎる ◆Codex App Server×Lambda MicroVM良すぎる 引用：https://github.com/awssamples/sample-multi-agentorchestration-chat-on-agentcore 引用： https://note.com/japan_d2/n/n61 8cb3439486
40. まとめ
41. まとめ ◆サーバーレスアプリ×コーディングエージェントのポイント • 個人的には下記を抑えるといい感じ 1. サーバーレスの特性を理解する 2. 長時間動くコンピュートリソースに何を採用するか 3. ステート管理をどうするか ◆コーディングタスクもクラウドへシフトしていく流れがある • このアプリ以外にも色んな方法があるはず • 要件に合わせて最適な方法を選びましょう
42. もうちょっといいかんじにわかりあいたい ◆サーバーレスアプリでもコーディングエージェントは動かせる • ただし、なぜアプリ化するのかはちゃんと考えた方が良い →コーディングエージェントで何でも作れるようになったからこそ… • 色々なハマりどころがあり、評価も大変 • SDKの選定も色んな選択肢があるので難しい ◆それでも色々試してみるのは面白い • AgentCore Runtime×セッションストレージ・S3 Filesを試行錯誤したり AgentCore Runtimeのインタラクティブシェルも試したり • 色んなアーキテクチャを考える力にも繋がる • 次はLambda MicroVMを試してみます
43. AI Builders Day 2026ぜひご参加ください！ ◆Save the Date！10月頃プロポーザルを募集します！