脱 雰囲気実装！ AgentCoreを良い感じに WEBアプリケーションに組み込むために

1. 1 © 2026 Japan Digital Design, Inc. Takuya Yonezawa 2026.03.19 脱 雰囲気実装！ AgentCoreを良い感じに WEBアプリケーションに組み込むために AgentCore Lunch オンライン 〜本格アプリ開発ノウハウ編！〜
2. 2 © 2026 Japan Digital Design, Inc. 米澤 拓也 Software Engineer Technology & Development Div. and Corporate Culture室 プロフィール 前職ではCCoE、現職ではSoftware Engineer。 フロント/バックエンドの実装からインフラ構築など何でもやってます 証券系→銀行系 と 金融×IT なキャリアを歩んでいます 生息地：大阪 & 奈良 Community Builder (Serverless) 2023~ AgentCore/Strandsは先月入門して趣味でやってます takuya_y0ne
3. 3 © 2026 Japan Digital Design, Inc. 0 お断り
4. 4 © 2026 Japan Digital Design, Inc. アーキテクチャに絶対解は無いし、 あらゆる選択はトレードオフの上に成り立つ アーキテクチャ図も解説しますが あくまで1つの実装例として見てもらえれば幸いです
5. 5 © 2026 Japan Digital Design, Inc. 本日のターゲット - AgentCoreを本格的にアプリケーションへ 組み込んでいく予定の方 - 「とりあえずヌルヌルした画面作って！」 と言われてしまった方 AgentCore自体の話は少なめです。 その辺は神野さんが語ってくれます。
6. 6 © 2026 Japan Digital Design, Inc. 1 とりあえずこれを見てくれ
7. 8 © 2026 Japan Digital Design, Inc. 公開用スクショ
8. 9 © 2026 Japan Digital Design, Inc. 今見せたのは米澤がAgentCore×Strandsで “人力”作成した検証用アプリ ぬるぬる動いてましたよね？
9. 10 © 2026 Japan Digital Design, Inc. 2 ぬるぬるの正体
10. 11 © 2026 Japan Digital Design, Inc. Server Sent Eventは 技術としては昔からあるもの Server Sent Event (SSE) 2004年に初めて仕様化 ※1 ※2 サーバからクライアントに逐次的に データを送信するための仕組み HTTPベースで実現される サーバ→クライアントの単方向通信 ▪ なんで今さら？ LLMの回答生成には時間がかかる。 回答生成が完了してから一発で レスポンスを返すような従来方式だと、 UX的に微妙なので再注目されている。 ※1 https://html.spec.whatwg.org/multipage/server-sent-events.html Client Server https://developer.mozilla.org/ja/docs/ Web/API/Server-sent_events/Using_server-sent_events ※2 HTTPで接続 データ データ データ HTTP接続終了 ・・・
11. 12 © 2026 Japan Digital Design, Inc. WebSocketは？ クライアント側のポーリングは？ 玄人の方向け WebSocketやクライアント側の ポーリングだと、 - 双方向のハンドシェイク - クライアント側の処理負荷増大 などをケアして上げる必要があり、 アプリケーションが複雑になる WebSocketに対応していない プラットフォームもある その点 Server Sent Eventは単方向の HTTPベースなのでトータルすっきりする （ロジックミスで無限Client Pollingとか しちゃったら泣ける） Client Server データ取得 データ取得 データ取得 ・・・ Client Server WebSocketコネクション確立 データ送受信 WebSocket Client Polling
12. 13 © 2026 Japan Digital Design, Inc. Server Sent Eventの中身 https://developer.mozilla.org/ja/docs/Web/API/Server-sent_events/Using_server-sent_events
13. 14 © 2026 Japan Digital Design, Inc. Server Sent Eventの中身 https://developer.mozilla.org/ja/docs/Web/API/Server-sent_events/Using_server-sent_events AgentCoreで特に意識しないといけないのは この”data”という項目
14. 15 © 2026 Japan Digital Design, Inc. 実際に Strands on AgentCore が 返してくるストリーミングデータの中身を眺めてみる
15. 16 © 2026 Japan Digital Design, Inc. AWSドキュメント内のサンプルコード から一部修正したもの
16. 17 © 2026 Japan Digital Design, Inc. 辛い。。
17. 18 © 2026 Japan Digital Design, Inc. すこし整理してみる
18. 19 © 2026 Japan Digital Design, Inc. この細切れのデータを組み立てると 「こんにちは！今日はお手伝いできることはありますか」 になる（＝Strandsの応答） キー名が”event”のデータのみ抽出 Agent実行で消費されたトークン数 キー名が”event”のデータのみ抽出
19. 20 © 2026 Japan Digital Design, Inc. キー名が”event”のテキストを組み合わせれば アプリケーション上でいい感じに表示できそう
20. 21 © 2026 Japan Digital Design, Inc. 3 が、この細切れのデータを組み立てるのが大変。。
21. 22 © 2026 Japan Digital Design, Inc. そもそも event: messageStartとか event: contentBlockDeltaとか って何？
22. 23 © 2026 Japan Digital Design, Inc. https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/ conversation-inference-call.html#conversation-inference-call-response 実態はBedrockのConverseStream
23. 24 © 2026 Japan Digital Design, Inc. messageStart contentBlockStart contentBlockDelta contentBlockStop messageStop metadata ▪ メッセージ開始イベント アプリケーション上は無視してOK ▪ ツール利用時に出力される どのツールを利用するか？等が出力される ▪ 回答生成時/ツール利用時に出力される モデルの回答やツールへのインプットなどが出力される ▪ 回答生成時/ツール利用時に出力される モデルの回答停止やツール利用時の停止イベント ▪ メッセージの停止イベント 各ブロック毎にモデルの回答生成が完了したら出力される ▪ モデル回答が完了する際に出力される トークン利用量やレイテンシーが出力される
24. 25 © 2026 Japan Digital Design, Inc. 参考：Tool利用も含めた際のペイロード
25. 26 © 2026 Japan Digital Design, Inc. フロント側で、前述のように流れてくるデータを イベントタイプに合わせてハンドリングする必要がある
26. 27 © 2026 Japan Digital Design, Inc. targetText という変数の中に「を使用」が格納される
27. 28 © 2026 Japan Digital Design, Inc. サンプルのReact側コード。辛い。。
28. 29 © 2026 Japan Digital Design, Inc. 検証している時の私の叫び
29. 30 © 2026 Japan Digital Design, Inc. 4 ここまでのまとめ
30. 31 © 2026 Japan Digital Design, Inc. AgentCoreのストリーミングレスポンスの特性上、 どんなイベントデータがフロント側に届くかが分からない バックエンド側で担わないといけないデータ整形処理を フロント側に押し付ける形になる （本来フロント側にロジックを多く持たせるべきではない）
31. 32 © 2026 Japan Digital Design, Inc. ぬるぬるした画面表示、本当に必要ですか？ ローディング画面→一括表示 で代替できるなら そちらのほうが遥かにシンプルにできる
32. 33 © 2026 Japan Digital Design, Inc. 5 今回組んだシステム構成
33. 34 © 2026 Japan Digital Design, Inc.
34. 35 © 2026 Japan Digital Design, Inc. 設計の大方針： - インフラの面倒を見たくないのでサーバレス - API-GWの周辺機能に乗っかりたい （APIキーによる流量制御/CognitoによるAPI認証） - CDK（Pipelines）で良い感じにデプロイ回したい - AgentCoreとかAPI-GWがサ終しても移植可能
35. 36 © 2026 Japan Digital Design, Inc. Strandsの中の構成。ただの私の趣味です Master Agent WEB検索Agent （MCP） What’s New 検索Agent AWS環境 調査Agent 不動産情報 取得Agent フロント実装Tips 取得Agent Knowledge Bases Knowledge Bases StrandsTools RSS tavily
36. 37 © 2026 Japan Digital Design, Inc. この辺の話をします
37. 38 © 2026 Japan Digital Design, Inc. 6 Lambdalithというアプローチ
38. 39 © 2026 Japan Digital Design, Inc. Lambdalith - Lambda+Monolith - Lambdalith ? REST APIのルーティング処理を 単一のLambda関数に集約するという 設計アプローチ 非Lambdalithでは、APIのパス毎に Lambda関数を定義し、ミニマムな処理 構成を目指すのが一般的 （HTTPパス×メソッド毎に切るというケースもある） Lambdalisth / 非Lambdalith もちろんどちらもトレードオフである。 非 Lambdalith Lambdalith API-GW API-GW Lambda Lambda /history /search /user /history /user /search Logs Logs
39. 40 © 2026 Japan Digital Design, Inc. Lambdalith - Lambda+Monolith - Lambdalith ? REST APIのルーティング処理を 単一のLambda関数に集約するという 設計アプローチ 非Lambdalithでは、APIのパス毎に Lambda関数を定義し、ミニマムな処理 構成を目指すのが一般的 （HTTPパス×メソッド毎に切るというケースもある） Lambdalisth / 非Lambdalith もちろんどちらもトレードオフである。 API-GW API-GW Lambda Lambda /history /search /user /history /user /search Logs Logs Lambdalith 非 Lambdalith - 各Lambdaごとに関心の分離 ex.) アクセス先リソース/IAM権限 etc… - Lambdaロジックのスリム化 - Lambda関数のバンドルサイズ圧縮 - バグった時の影響範囲が小 良い点 - 付随リソースの集約 ex.) IAMロール/CloudWatch Logs - コールドスタート発動確率の低減 - 移植/開発容易性（シングルソース） - ローカルでの開発体験◦ 良い点
40. 41 © 2026 Japan Digital Design, Inc. ちゃちゃっと開発してTry＆Errorしたかったので 私はLambdalithパターンを採用
41. 42 © 2026 Japan Digital Design, Inc. 7 モノリスなLambda、どう作る？
42. 43 © 2026 Japan Digital Design, Inc. Lambda Web Adapter （LWA） パターン #1 LambdaでWEBフレームワークを 動かすためのOSS。 通常のDockerファイルに1行追加する だけでLambda互換仕様にできる。 実は JAWS DAYS 2025、 JAWS PANKRATION 2024のサイトも LWAで動かしている。 （App Runnerから引っ越した） たまに動き遅いけど許してね いつものDockerfileに魔法のコマンドを1行追加 上記はJAWS PANKRATIONのLWA版Dockerfile （モノレポ構成でのNext.js） もちろんNest.jsやExpress, FastAPIも行ける
43. 44 © 2026 Japan Digital Design, Inc. https://speakerdeck.com/tmokmss/aws-lambda-web-adapterwohuo-yong-suruxin-siisabaresunoshi-zhuang-patan https://speakerdeck.com/tmokmss/aws-lambda-web-adapterwohuo-yong-suruxin-siisabaresunoshi-zhuang-patan パターン #1 LWAの詳細を知りたい方はこちら
44. 45 © 2026 Japan Digital Design, Inc. CDK × パターン #2 CDKプロジェクト配下で組むと最高 CDKのNodejsFunctionを利用すると 丸ごとjsにバンドルしてLambdaへ展開可能 （コンテナイメージを作らなくて良い！） CDKの世界線でロジックを書きつつ、 ローカルでのDevEx向上（後述） https://hono-ja.pages.dev/docs/getting-started/aws-lambda Hono（Lambda）の ロジックコード CDKでの Lambdaリソース定義
45. 46 © 2026 Japan Digital Design, Inc. ローカルでLambda用のHonoを ガシガシ開発/検証したい！ パターン #2 もちろんできます @hono/node-server というパッケージを 利用すればローカルでhonoを動かせる （ホットリロードもできる） ストリーミング処理を簡単に書けるのも嬉 Honoのアプリ定義 Lambda用ハンドラ定義 ローカル起動用サーバ定義 [参考] https://www.youtube.com/watch?v=9tR3dYFFyTQ
46. 47 © 2026 Japan Digital Design, Inc. ローカル開発の体験 デプロイの楽さ LWAよりシンプルに動かせる ※1 の観点でHono on Lambdaを採用した (※1) - LWA上のFWが/tmp以外に書き込もうとして異常終了する - SigV4署名のケアが不要 など
47. 48 © 2026 Japan Digital Design, Inc. Local w/ HotReload （Vite Server） Local w/ HotReload （Hono Server） AWS環境 DynamoDB AgentCore/ KnowledgeBase ローカル開発どんな感じでやってるか？ フロント部分/Hono部分はローカルサーバで ホットリロードを効かせつつ実装を進める HonoはOpenAPIに対応しているのでスキーマ駆動
48. 49 © 2026 Japan Digital Design, Inc. Local w/ HotReload （Vite Server） AWS環境 API-GW＋Lambda（Hono） AWS環境 DynamoDB AgentCore/ KnowledgeBase ローカル開発どんな感じでやってるか？ Hono部分をAWS環境（API-GW+Lambda）に 持っていってもローカル環境時と同じように動くので 環境差分による事故が少なくて済む API-GW Lambda (Hono)
49. 50 © 2026 Japan Digital Design, Inc. 8 ここでも ストリーミング対応で辛くなる
50. 51 © 2026 Japan Digital Design, Inc. この辺の話をします
51. 52 © 2026 Japan Digital Design, Inc. - Streamingでぬるぬる表示 - Bufferedで一括表示 「異なるレスポンスパターンを同居させたい」 誰もがそう思うはず
52. 53 © 2026 Japan Digital Design, Inc. ぬるぬる表示させたい部分 （Streaming） 一括表示させたい部分 （Buffered）
53. 54 © 2026 Japan Digital Design, Inc. API-GWでStreaming、 使えるようになりましたよね Lambdalith構成が裏目に Lambda-lithなHono製Lambdaを動かすた め、API-GWでは /{proxy+} というパスを 利用する必要がある Lambdaプロキシ統合では、 - STREAM（ストリーミング） - BEFFERED（一括レスポンス） が選べるが、パスごとに1:1対応となる Lambdalithなパターンだと 1API-GWで STREAM/BUFFEREDの同居ができない API-GW Lambda (Hono) /{proxy+} Client /history /invoke ▪ Buffered ▪ Streaming /history /invoke /invokeは レスポンス形式の 不一致でエラーになる （Buffered vs Streaming） Buffered/Stramingの択一
54. 55 © 2026 Japan Digital Design, Inc. Cloudfrontでパス毎に振り分け Lambdalith構成が裏目に API-GWはStreaming用、Buffered用の 2本を生やす Cloudfrontのパスパターンを利用して - API-GW（Streaming） - API-GW（Buffered） - S3（アプリケーション） へのルーティングを振り分ける Hono（Lambda）のハンドラ部分にも 工夫を入れる必要がある。 API-GW （Streaming） Client ▪ Buffered ▪ Streaming Cloudfront API-GW （Buffered） S3 （Web App） Lambda (Hono) Lambda (Hono) /api/history /api/invoke /* AgentCore DynamoDB (呼び出し履歴)
55. 56 © 2026 Japan Digital Design, Inc. 漂う悪魔構成感。。 Lambdalith構成が裏目に HonoではLambda用のハンドラとして、 - streamHandle（Streaming用） - handle（Buffered用） の2種類が用意されている Lambdaへのデプロイ時にこの2つのハンド ラを呼び分けることで、シングルソースの Honoアプリで、Streaming/Bufferedに 両対応できるようにしている Hono内 Lambda用ハンドラ定義 （Stream/Bufferd両対応版） CDK Lambda定義抜粋（Streaming） ▪ Buffered ▪ Streaming CDK Lambda定義抜粋（Buffered）
56. 57 © 2026 Japan Digital Design, Inc. ぬるぬるした画面表示、本当に必要ですか？ ローディング画面→一括表示 で代替できるなら そちらのほうが遥かにシンプルにできる
57. Thank you. 58 © 2026 Japan Digital Design, Inc.