AWS Summit Japan 2026 Builders' Fair 人気投票第 1 位「ペン字見ます ! ~ AI Agent 先生の辛口査定 ~」の裏側 !

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

ここに、実は体験設計の小さな秘密があります。この「先生紹介」の画面、来場者を楽しませるためだけのものではありません。この裏側では、書いた字を 1 画ずつ解析するストローク検出 (GPU を使う、そこそこ重い処理) がこっそり走っています。処理が終わるのをただ眺めて待つのではなく、その待ち時間を先生紹介にあてることで、来場者には「待たされている」感覚をほとんど与えずに、必要な処理時間を稼いでいるのです。

しかも、この「査定会議を傍聴する」ボタンは、裏のストローク検出が終わってはじめて押せるようになります。つまり、スタッフが説明を終えるころには処理もちょうど完了していて、ボタンを押せば待たずにそのまま議論へ進める、という寸法です。

裏の重い処理を、表の楽しい演出で覆い隠す。地味ですが、体験を途切れさせないための大事な工夫でした。

ここでも、ひとつ体験設計の仕掛けがあります。この 4 人、実は単に役割を割り振っただけではなく、思わずクスッとくるような濃いめのキャラクターを一人ひとりに設定しています。元ネタは…ここでは内緒ですが、「いかにも実在しそうな、おなじみの語り口」を意識して、口調や性格をプロンプトに作り込みました。役割 (褒める・辛口・バランス・統括) に加えて話し方のクセまで指定することで、同じ査定結果でも「その先生が言いそうな言い回し」で話してくれる。査定が無機質な講評ではなく、人情味のある会話劇になっているのは、この味付けのおかげです。

ここにも、体験設計のこだわりがあります。この赤ペン添削、実は「いかにも人間の先生が手で添削したように見せる」ことにかなり気を使っています。

AI が出したコメントをそのまま貼り付けると、位置が重なったり、指し示す線がぐちゃぐちゃになったりして、機械的で冷たい印象になってしまう。そこで、コメントは文字まわりの余白を探して置き、対象の画へは矢印で結ぶ。しかもその矢印は、隣のコメントとぶつからないように向き (上向き・下向き) を自動で調整し、コメント同士が重なりそうなら反対側やさらに外側へ置き直します。色も、機械的な純赤ではなく温かみのある赤にして、線には少しだけ手書きのゆらぎを加えています。

こうした地味な処理の積み重ねで、「AI の出力」ではなく「先生に赤ペンで直してもらった一枚」に見えるようにしているのです。

大まかな流れは次のとおりです。

1. フロントエンドは Amazon CloudFront + Amazon S3 (SPA) で配信。撮影した画像は S3 にアップロードされる。
2. S3 へのアップロードをトリガーに、AWS Lambda Durable Functions がパイプライン全体を起動。
3. パイプラインは「ストローク検出 (ECS on EC2 の GPU) → マルチエージェント査定 (Amazon Bedrock AgentCore + Strands Agent) → 結果生成」と遷移。
4. 各ステップの進捗は Amazon API Gateway WebSocket 経由でリアルタイムに画面へ push。

「撮影 → ストローク検出 → 査定 → 結果生成」は、GPU 推論やマルチエージェントをまたぐ長時間ワークフローです。これを 1 本の AWS Lambda Durable Functions で管理し、状態の保持やリトライ・途中再開を任せることで、素直な順次処理として書けます。

選んだ一番の理由は「待つ」の扱いやすさでした。先生紹介の裏で走るストローク検出や「会議をはじめる」ボタン待ちなど、いつ終わるか読めない「待ち」が何度も登場します。ここで効くのが waitForCallback で、パイプラインを待機させ、コールバックが届いた瞬間に再開できます。待機中の Lambda は停止状態になり、その間コンピュートの課金は発生しません。

AWS Lambda Durable Functions の基本的な仕組みや API は、 AWS 公式ブログ を参照してください。

来場者の字を査定するには、まず「どこにどの画 (ストローク) が書かれているか」を認識する必要があります。ここは自前のセグメンテーションモデルで処理しています。汎用モデル 1 つで全文字をこなすのではなく、文字ごとに専用モデルを Amazon SageMaker AI で学習させ、お題の 4 文字にそれぞれ担当モデルを当てる作りです。

複数の学習済みモデルを同時に GPU に載せて推論するにはパワーが要るため、ここだけはサーバーレスで割り切らず、ECS on EC2 の Python コンテナで動かしています。お題の画像を 1 文字ずつに分割し、担当モデルでセグメンテーション → 特徴量計算 → Amazon DynamoDB 保存、という流れです。数十秒かかるこの検出こそ、「先生紹介」で覆い隠していた待ち時間の正体です。

Amazon SageMaker AI のセマンティックセグメンテーションアルゴリズムついては  AWS 公式ドキュメント を参照してください。

検出したストロークの特徴量をもとに、性格の違う 4 体のエージェント (褒め型・バランス型・辛口型・統括) が査定を議論します。

各エージェントの役割や性格は Strands Agents で実装し、 その協調 (swarm)  を Amazon Bedrock AgentCore のランタイム上でオーケストレーションしています。推論エンジンは Amazon Bedrock の Claude Opus モデルです。褒め型・バランス型・辛口型が 4 文字 × 4 観点 = 16 セットを評価して意見を出し合い、最後に統括エージェントがまとめて総合ランクを決定します。

この議論ログをそのまま大画面にストリーミングしているのが、「AI が考える過程を観戦できる」体験の裏側です。

Strands Agents については  Strands Agents 公式サイト を参照してください。

Amazon Bedrock AgentCore については  Amazon Bedrock AgentCore 公式サイト を参照してください。

最後に、開発そのものの話です。この展示は、AWS CDK、複数の Lambda、GPU コンテナ、React フロントと多岐にわたるスタックを、AI 開発環境 Kiro で作りました。Spec (要件 → 設計 → タスク) で機能ごとに設計・実装を進め、Steering に命名規則や規約を書いておくことで、言語やコンポーネントをまたいでも一貫したコードを保てました。結果として、4 人・3 ヶ月でフルスタックを作り切れました。

Kiro での仕様駆動型開発については  AWS公式ブログ を参照してください。

「ペン字見ます ! ~ AI Agent 先生の辛口査定 ~」は、書いたペン字を 4 体の AI エージェントが辛口に査定する、という一見シンプルな展示です。ですがその裏側では、たくさんの技術が体験を支えていました。

この記事を通して一番お伝えしたかったのは、私たちがこだわり抜いた「体験設計」と、それを支える技術がぴったり噛み合っていた、ということです。「ゲームセンターに遊びにくる感覚でブースに来てほしい」。この一点から逆算して演出を積み重ね、それを成立させるために技術を一つずつ選んでいきました。体験の工夫と技術の工夫は、どちらか片方では成り立たない両輪だったと思っています。

しかもこだわったのは、機能そのものだけではありません。画面のデザイン、要所で鳴る効果音、来場者の迎え方やブーススタッフの立ち位置まで。細部の一つひとつが、すべて「遊びにきた人に楽しんで帰ってもらう」ためのものでした。

本展示が、AI エージェントや体験設計を組み合わせた「作ってみた」のヒントになればうれしいです。みなさんもぜひ、面白いアプリケーションを作ってみてください !