スタメンでCTOしております、 @tnir ( X: @takuya_stmn , note: @takuya_stmn ) です。 2023年9月、スタメン技術ブログで次の記事を公開しました。 ドメイン駆動設計は何を解決する手法なのか 記事では、TUNAG の技術的負債解消に向けてドメイン駆動設計（DDD）の導入を検討している、と書きました。その後の対外的な印象として、「スタメンは DDD を積極導入している」と読まれる場面がありました。 本記事の目的は二つです。 当時の検討表明と、いまの実装実態のあいだにある差分を正確に共有すること その後に行った小規模な試験導入（PoC）から得た、Rails 文脈での技術的・組織的な学びを共有すること 結論を先に述べます。私たちの設計の軸は ActiveRecord で、DDD はバックエンドのごく小さな範囲で試しました。その結果、ActiveRecord を軸にする方針を選んでいます。ただしこれは DDD全般の評価ではなく、私たちの文脈での記録です。小さく試し、合うものを残し、合わないものを手放すプロセス自体は、今でも有効なエンジニアリング判断だと考えています。 2023年の記事が書いていたこと 当時の記事の冒頭は、次のとおりです。 株式会社スタメンでは、企業エンゲージメント構築サービス TUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 記事は実装報告ではなく、コアドメインを軸に「DDD が何を解決する手法なのか」を整理する解説でした。実装詳細は扱わない、とも明記しています。締めは、将来に向けた表明です。 つまり本文の事実は「導入を検討している」までであり、「すでに積極導入している」ではありません。ただし、解説の熱量や「邁進していきます」という結びが重なると、読後印象としては積極導入企業のように残りやすい面もありました。このギャップを、いま実装と検証結果に基づいて補正します。 当時の課題提起がなければ、机上の議論で終わっていた可能性もあります。検討を公開し、その後に実コードで検証まで進めたからこそ、本記事で共有するトレードオフが見えました。 何を、どこまで試したか 私たちのプロダクトは、大きくバックエンド（API）とフロントエンドに分かれます。 領域 DDD との関係 フロントエンド 導入なし バックエンド全体 教科書的な全面適用はなし。LoC ベースで全体の 1% を大きく下回る範囲で、部分的・実践的な試験のみ 試験の主例 社内教育・テスト（ナレッジテスト）領域の新規 API 見送り後の比較例 タスク依頼・ToDo 領域の新規 API 本記事では前者を 業務DXサービスA API 、後者を 業務DXサービスB API と呼びます。どちらも TUNAG 本体から独立した形で実装されたグリーンフィールドサービスのバックエンドです。 業務DXサービスA API は、MVC でくくると Model がおおよそ 2,000 LoC 前後、View + Controller がおおよそ数百 LoC 規模でした。期間は 2023年12月からの約3ヶ月です。ここでの DDD は、Evans 流の戦術パターンを全面適用したものではなく、不変条件が重要な箇所に限定した実用主義的な導入（DDD-lite としても呼ばれることがある）でした。設問・選択肢・合格判定・受験セッションなど、「壊れると困るルール」が比較的はっきりしている領域だったため、試験対象として適していました。 実コードでは、たとえば次が確認できます。 ドメイン層を ActiveRecord から分離した pure Ruby のオブジェクトがある 選択肢数・重複・合格ラインなどの不変条件を、生成時や操作時に検証する実装がある 一部の更新経路では、リポジトリ経由で集約を再構成してから永続化する 一方で、次の限界もありました。 単純更新・複製・一部セッション更新は ActiveRecord 直叩きのまま残り、層を迂回した 一部のドメインオブジェクトは、振る舞いに乏しいデータホルダーに近い ドメインイベントや、依存逆転を徹底した古典的構成までは採っていない つまり「DDD を名乗るに足る部分実装はあった」が、「プロダクト全体の標準アーキテクチャになった」わけではありません。 時系列は次のとおりです。 時期 内容 2023年9月 技術ブログで導入検討を表明 2023年12月〜約3ヶ月 業務DXサービスA API で部分的・実践的な DDD を試験導入 2024年3〜4月 PoC 振り返り。本格採用を見送り、業務DXサービスB API では採用しない方針を合意 2024年5月〜約3ヶ月 業務DXサービスB API を、DDD 非採用前提で初期開発 現在 フロント未導入。バックエンドでも局所試験の知見にとどまり、標準は ActiveRecord を軸にした設計 業務DXサービスB API は「DDD 導入の第2弾」ではありません。振り返りの結果、採らないと決めたあとの開発です。境界の分離や外部モデルの漏洩防止など、マイクロサービスとして当然の設計はありますが、それを DDD の戦術導入とは数えません。 なぜ本格採用を見送ったか — 技術的・組織的な理由 ここが本記事の本題です。「やらなければよかった」ではなく、「何が効き、何が合わなかったか」を残します。 1. 本来の課題と手法がずれた 2023年の検討の出発点は、TUNAG の技術的負債解消でした。ところが検証が進むにつれ、 手法の導入そのものが目的化しやすい 局面がありました。 負債解消で本当に解きたかったのは、たとえば次のようなことだと考えています。 変更影響の見通しを良くすること ドメイン知識をコード上で追跡しやすくすること チームが安全に改修できる速度を保つこと 一方で、層分け・用語・パターンの整備が進むと、「DDD らしく書けているか」が評価軸になりやすい。すると、負債解消や変更容易性への寄与より、導入の完成度が議論の中心になります。業務DXサービスA API での試験は、この目的化を本体から切り離して観測するためにも有用でした。振り返りの結論は明確で、 その時点のスタメンの文脈では、DDD の本格導入は TUNAG の技術的負債解消に適していない 、でした。 2. Rails / ActiveRecord との摩擦コストが高かった 業務DXサービスA API は Rails API です。ActiveRecord は永続化だけでなく、クエリ・バリデーション・ライフサイクル・関連の中心でもあります。ここに戦術的 DDD（集約の再構成、リポジトリ、pure ドメインモデル）を部分導入すると、少なくとも次のコストが発生しました。 二重モデル化 : DB 行としての AR と、ドメイン上のオブジェクトを往復させる変換が必要になる 経路の分岐 : 不変条件が強い操作だけドメイン経由、単純 CRUD は AR 直叩き、という二系統が同居する 認知負荷 : 「この変更はどの層に書くべきか」の判断自体が、機能追加のたびに発生する 複雑な採点や、正式版の訂正ルールのように、壊れ方が高い箇所では、pure なドメインオブジェクトに寄せる利点はありました。逆に、大半の更新が CRUD に近い画面・API では、変換と層分けのコストが、得られる安全性を上回りやすかった、というのが率直な感触です。 Rails way（責務を散らさない Model、明確な UseCase、必要なら concern）を主軸にした方が、少人数チームでの変更速度と学習コストのバランスが良かった、というのが本格採用見送りの技術的な中核です。 3. 効く範囲が、プロダクト全体のボトルネックと一致しなかった DDD が相対的に効きやすいのは、ルールが複雑で、不変条件の破壊がそのまま障害になる領域です。業務DXサービスA API でも、設問制約や採点のようにその種の箇所には部分適用の合理性がありました。 しかし TUNAG 本体を含むプロダクト全体の負債の主因が、「集約境界が無いこと」だけだったわけではありません。認証委譲、サービス分割、スキーマ契約、運用、データ整合、画面を含む変更伝播など、別種の複雑性の方が大きい局面も多い。戦術 DDD を局所に厚くしても、プロダクト全体の変更容易性が線形に改善するとは限らない、というのが PoC 後の整理です。 4. 小さく試せたから、大きく間違わずに済んだ 見送り自体を失敗とは捉えていません。新規の小さい API で約3ヶ月試し、振り返り、次の新規 API では使わないと決めた。この切れ方の方が、本体へ先に全面適用するより健全でした。 組織として得られた整理は、次です。 DDD は銀の弾丸ではない 導入を目的化すると、負債解消から離れる Rails 中心のプロダクトでは、戦術 DDD の全面適用より、ActiveRecord を軸に複雑箇所だけ設計を厚くする方が現実的なことが多い 手法の採否は、流行や完成度ではなく、事業成長と開発生産性（保守性・変更容易性を含む）で見る いまの設計方針 PoC 後の標準は、ActiveRecord を軸に置いています。UseCase（アプリケーションサービス）でユースケースの流れとトランザクション境界を担保しつつ、永続化モデル側は ActiveRecord 本来の表現力を活かす。そのうえで、モデルを無秩序に太らせないために、関心事ごとに concern へ閉じる、という形です。 これは「Fat Model に戻した」という意味ではありません。ドメイン層と AR を二重に持つコストを下げつつ、ユースケースのオーケストレーションは UseCase に残し、モデルに散らばりがちな関心事だけを concern で分割する、という選択です。Concern の濫用が神オブジェクトの隠蔽になりうることは認識したうえで、DDD-lite の二重モデルより、この分割の方がチームの認知負荷と変更速度に合う、と判断しています。 対外的な事実関係は、次で足ります。 2023年の記事は導入検討の表明であり、全面採用の報告ではない フロントエンドでは DDD を導入していない バックエンドでも、LoC ベースで全体の 1% を大きく下回る範囲での部分的・実践的な試験にとどまる 主例は業務DXサービスA API（2023年12月〜約3ヶ月） 2024年3〜4月の振り返りで本格採用を見送り、業務DXサービスB API（2024年5月〜約3ヶ月）では非採用前提で開発した 現在のスタメンを「DDD積極導入企業」と呼ぶのは実態に合わない 小さく検証し、合わなければ採用しない、という判断は今後も取りうる 手法の是非を好みで決めず、小さく試し、事業成長と変更容易性を含む生産性、および本来の課題（技術的負債解消）への寄与で採否を決める。業務DXサービスA API での試験と、業務DXサービスB API での見送りは、その一例です。 おわりに この記事は、過去のチャレンジ計画ブログ記事を消すためのものではありません。当時の検討や、その後の試験を否定するものでもありません。むしろ、2023年の記事が課題を言語化し、仮説を外に出したからこそ、机上の空論で終わらせず実コードでトレードオフを検証できました。話題の手法をスローガンで終わらせず、小さなプロダクトに落として確かめ、本格採用を見送った記録です。 エンジニアリングにおいて重要なのは、流行を追うことでも、一度選んだ手法に固執することでもありません。自社のプロダクト特性、フレームワークの前提、チームの認知負荷に照らして、効く設計を残し、効かない設計を手放せることです。今回の PoC は、その判断をコードと振り返りで一度通した事例だと考えています。 設計の話をするときも、採用の話をするときも、「スタメンは DDD を積極導入している」ではなく、「小さく試し、Rails / ActiveRecord を軸に UseCase と concern で整理する設計を主軸として選び直した」と読んでいただけると、実態に近いです。 今現在、主に採用しているシンプルな Rails Way に準じたアーキテクチャに関しては別の記事でコメントできればと思います。

本ブログは 2026 年 8 月 11 日に公開された Amazon Science Blog “ A decade of mathematical certainty: Reflections on the Automated Reasoning Group ” を翻訳したものです。 Automated Reasoning Group の設立から 10 年。数学的論理は学術研究の領域を越え、お客様の数百万のワークロードを守る本番サービスにまで広がりました。これは、システムが単に「おそらく正しい」だけでなく、「正しいと証明できる」ものになり得ることを示しています。 2016 年、Amazon の小さな研究チームが Automated Reasoning Group (ARG) の発足とともに、その存在を世界に向けて発信しました。掲げたビジョンは大胆なものでした。数学的論理を用いて AWS のシステムをテストするだけでなく、正しく動作することを数学的な確実性をもって証明する、というものです。 それから 10 年。ARG は、形式的検証の進歩によってこれまで解決困難だった問題を AWS の規模で緩和できるのかを模索する段階から、AWS のセキュリティと信頼性への取り組みの根幹を成すシステムを構築する段階へと進みました。ARG の本番サービスは、1 日あたり数十億件のクエリを処理しています。 本記事では、最先端の形式的検証とプログラム解析の技術を Amazon 特有の課題にどう適用してきたかを振り返ります。この取り組みの原動力となったのは、現実世界のセキュリティとインフラストラクチャの問題を、AWS の規模で数学的な厳密さをもって解決できるという確信でした。実際、当時研究していたようなツールは、Intel や NASA では既に成果を上げていました。ただ、これらの技術がここまで広範に適用できるようになるとは、十分に予測できていませんでした。 デモから大規模な本番環境へ 2016 年に第 1 回 ARG Demo Day を開催したとき、AWS Security に向けていくつもの野心的なプロジェクトを紹介しました。それぞれが、同じ根本的な問い、すなわち「自分たちのシステムが安全かつ正しいことを数学によってどう証明できるのか」に対する異なるアプローチでした。その日に示された答えは、2026 年の今も AWS とお客様にとって重要な役割を果たし続けるシステムの土台となっています。 Sean McLaughlin は「Automatic tools for reasoning about virtual private clouds (VPC)」と題したプレゼンテーションを行いました。VPC ネットワークの拡大に伴い、設定ミスやセキュリティ脆弱性を特定できる自動推論ソリューションへの需要が高まっていると指摘したうえで、その答えとして示したのが「 Tiros というツール で、簡単に言えば、ネットワークに関する質問に答えてくれるもの」でした。 Tiros は、 Amazon Inspector のネットワークセキュリティ分析機能の基盤となりました。Amazon Inspector は、クラウドでアプリケーションを構築する数百万のお客様にご利用いただいています。Tiros は AWS 内部でも、多くの AWS サービスにおけるコンプライアンス認証の確認やセキュリティ不変条件の遵守チェックを自動化する用途で使われています。現在では、Amazon Inspector と Reachability Analyzer の両方を支えています。この取り組みからは Zelkova も派生しました。Zelkova は 自動推論 を用いて、ポリシーとそれが将来もたらす結果を分析します。 S3 Block Public Access や IAM Access Analyzer をはじめ、数多くのツールが Zelkova を基盤としています。 同様に、その日には、重要なインフラストラクチャを対象とする詳細な自動解析の活用をテーマにしたプレゼンテーションも行われました。これが、TLS ハンドシェイクの正しさや、暗号、ストレージ、仮想化のコードが備えるその他の性質を証明する取り組みへとつながりました。 紹介した小規模なプロジェクトの中にも、その規模をはるかに超える影響をもたらしたものがあります。価値の高いインフラストラクチャに対する演繹的検証の取り組みを発表した当時、その適用範囲は主に暗号プロトコルの最も深い部分に限られていました。しかし今日、その重要性は飛躍的に高まっています。これを後押ししたのが、証明支援システム (proof assistant) の台頭です。証明支援システムとは、ユーザーが形式的な証明を作成するのを助ける自動化ツールで、自動推論 (AR) チームの senior principal scientist である Leo de Moura が作成した Lean などがあります。AWS は現在、こうしたツールを言語モデルと組み合わせることで、より多くの、そしてはるかに大規模なシステムの証明を見つけられるようになりました。実際、 Nitro Isolation Engine について発表した証明 は、まさにそれを裏付けるものです。これは、AWS のポリシーインタープリターの証明や、暗号基盤の正しさを証明する近年の取り組みの基礎にもなっています。 お客様が信頼を寄せる数学的保証 この 10 年間で、ARG の研究プロトタイプは、数百万の AWS のお客様が毎日利用するサービスへと発展しました。 IAM Access Analyzer は Zelkova を利用して、USAA や GoTo といったお客様がリソースへの意図しないアクセスを特定できるよう支援します。セキュリティポリシーが正しく設定されていることをただ期待するのではなく、お客様はポリシーが実際に何を許可しているのかを、数学的な証明という形で確認できます。 2016 年にデモを行った Tiros をベースに構築された Reachability Analyzer は、パケットを 1 つも送信することなく、ネットワークの接続性を把握できるよう支援します。設定をテストするのではなく、考えられるすべてのネットワーク経路を数学的に分析し、宛先に到達できるかどうか、到達できない場合はどのコンポーネントが妨げているのかを示します。 Amazon Bedrock Guardrails の 自動推論チェック は、生成 AI に数学的な検証をもたらします。この機能は、モデルの応答が定義されたポリシーに準拠していることを形式論理で検証し、AI のハルシネーションの防止に役立ちます。検証精度は最大 99% に達します。 これらのお客様向けサービスには共通の基盤があります。いずれも 充足可能性モジュロ理論 (satisfiability modulo theories、SMT) ソルバーなどの自動推論技術を用いてシステムの動作に関する数学的保証を提供し、従来のテストで到達できる範囲をはるかに超えています。 クラウドを支えるインフラストラクチャの正しさの証明 お客様向けのツールは自動推論の実用的な価値を示すものですが、最も困難な取り組みの一部は AWS 内部のインフラストラクチャに向けられてきました。数百万のワークロードが依存しているため、正しさが不可欠なシステムです。 AWS は自動推論を用いて、次に挙げるものをはじめ、インフラストラクチャの多くの部分について正しさを証明してきました。 AWS Nitro Isolation Engine s2n-bignum などの暗号実装 AWS データセンターで動作するブートコード S3 などのストレージシステム とりわけ野心的だったプロジェクトでは、1 秒あたり 10 億回の API コールを処理する認可エンジン全体の正しさを証明し、シームレスに置き換えました。仕様と証明を用い、新しいエンジンを数千兆件に及ぶ本番環境の認可判定に対して検証したのです。 こうした内部検証の取り組みは、クラウドインフラストラクチャの最も基礎的な層に対しても、自動推論が数学的確実性をもたらせることを示しています。 予想外の発見 この 10 年の取り組みでおそらく最も意外だったのは、自動推論はシステムをより安全にするだけでなく、多くの場合、より効率的で保守しやすいものにするという発見です。検証のために厳密な仕様を書く必要が生じると、チームはより単純で洗練された解決策に気付くことがよくあります。 その理由の一つは、自動推論によって可能になる、システム全体を対象としたアプローチにあります。自動推論は、特定のシナリオにおけるシステムの動作を検証することに主眼を置くのではなく、論理を用いて 起こり得るあらゆる シナリオでの動作を検証します。考えられるすべての入力シナリオとその失敗のしかたを洗い出すのではなく、システムがどのように動作すべきかを定義し、その動作に必要な条件を特定します。そして、それらの条件が真であることを数学的証明によって検証します。つまり、システムそれ自体が正しいことを検証できるのです。 この発見は、数学的な厳密さと実践的なエンジニアリングは対立するものではなく、互いに補い合うものだという確信を裏付けました。形式的検証に求められる規律は、そうでなければ見えないままだった単純化の機会をしばしば浮かび上がらせます。 エージェンティック AI を支える基盤の構築 10 年前に始めた研究によって、AWS は AI 開発の次の時代に向けた独自の強みを備えることになりました。分散システムや重要なコードの検証で培った成果は、いまや AI が生成したコードの検証に直接活かせる土台となっています。一方、AWS ポリシーや VPC ネットワークの設定ミスに関する研究は、AI が生成したコンテンツの正しさを検証するのに役立っています。 この進化は、近年のいくつかのローンチに表れています。 Amazon Bedrock Guardrails の自動推論チェック は、深い専門知識を必要とするツールから、ビルダーが毎日使うサービスに直接組み込まれた機能へと歩を進めた、重要な節目です。 Amazon Bedrock AgentCore の Policy は、自動推論を用いてエージェントのアクションに明確な境界を設定し、エージェントが自律的に動作しながらも定められたコンプライアンスの境界内にとどまるようにします。チームは自然言語で、エージェントがアクセスできるツールとデータを指定できます。 AgentCore Gateway と統合すれば、システムはミリ秒単位でポリシーをチェックします。 エージェンティックな開発環境である Kiro では、 要件分析機能 をリリースしました。この機能は自動推論を用いて、コードを書く前にソフトウェア要件に矛盾、あいまいさ、抜け漏れがないことを証明し、コードの正確性を高め、後々のデバッグの繰り返しを防ぎます。Kiro を開発しているチーム自身も、機能を公開する前に、その機能を実装する AI 生成コードが正しく動作するかを自動推論で確認しています。 AI エージェントがより自律的になり、より複雑なタスクを担うようになるほど、その動作に関する数学的保証は決定的に重要になります。AI エージェントが形式仕様を備えたシステムへのコード変更を提案すれば、そのシステムは数学的証明に照らして変更を自動的に検証できます。自動推論は、強力であるだけでなく、安全性と信頼性を証明できる AI システムを構築する道筋をもたらします。 10 年にわたるコラボレーション この取り組みは、築き上げてきた優秀なチームと、重要なインフラストラクチャの保護を AWS に託してくださったお客様なしには実現できませんでした。AWS 全体で、各チームが自動推論の能力を拡大し続けています。 Senior principal scientist の Daniel Kroening が率いる Annapurna のチームは、ハードウェア検証を前進させています。Senior applied scientist の Nadia Labai は、自然言語を形式的な数学的証明へ変換することを AI システムに学習させる自動形式化 (auto-formalization) の研究を切り開いています。Principal applied scientist の Tristan Ravitch が率いる AWS Security のチームは、AWS と Amazon の全アカウントにわたるデータフローを自動的に追跡する Peri をローンチしました。サービスチーム側でのオンボーディングは一切不要です。 これらの取り組みによって、AWS は自動推論の次の 10 年を、最初の 10 年と同じくらい、あるいはそれ以上に変革的なものにする態勢を整えています。 証明してきたこと 10 年を経て、これまで達成してきたことに大きな喜びを感じています。設定エラーの防止から AI システムの動作に関する数学的保証の提供まで、自動推論はあらゆる層で測定可能な価値をもたらすことを証明してきました。そして、数学的な厳密さと実践的なエンジニアリングが手を携えて、お客様が実際に抱える課題を大規模に解決できることを示してきました。 2016 年の最初の Demo Day から今日に至るまでの道のりは、学術的な進歩をお客様が日々頼りにするサービスへと変えていくという AWS の姿勢を体現しています。数学的確実性を通じて信頼の基盤を築いてきました。その基盤は、AI イノベーションの次の 10 年を進むうえで欠かせないものとなるでしょう。 次の 10 年に向けて。 著者について Byron Cook Amazon の vice president 兼 distinguished scientist である Byron Cook は、形式的検証分野のリーダーです。SAT、SMT、記号モデル検査への貢献と、それらを生物システム、コンピュータオペレーティングシステム、プログラミング言語、セキュリティへ応用したことで知られています。Amazon での Byron の自動推論の取り組みは、クラウドにおけるより高い水準の保証と、新しいお客様向け機能をもたらしました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

「あの商品どこ？」というお客様からの一言に、新人スタッフは即答できるでしょうか。 AWS Summit Japan 2026 の流通小売・消費財・飲食ブースで、「スマートグラス × 音声 AI エージェントによる店舗業務支援」デモを展示し、スマートグラスを装着した来場者ご自身が、声で話しかけるだけで AI が音声と AR 表示で即答する体験をお届けしました。 図 1: デモのイメージ。スマートグラスに話しかけると、棚位置・商品名・在庫を視界に表示 このデモは、 Amazon Nova 2 Sonic と Amazon Bedrock AgentCore Gateway を中核とするマネージドサービスの組み合わせで構成されています。 解決したい課題: 新人の「即戦力化」 流通小売・飲食業界のお客様とお話しする中で、必ずと言っていいほど話題に上るのが「人手不足」です。採用が難しいことに加え、パート・アルバイトの入れ替わりや外国人スタッフの増加により、経験の浅いスタッフで現場を回す場面は今後ますます増えていきます。 そこで本デモが着目したのが、「 新人が戦力になるまでの時間 」を縮められないか、という切り口です。ベテランなら 1 秒で答えられる「あの商品どこ？」も新人には答えられず、売り場を覚えるのに数週間、商品知識を身につけるのに数ヶ月かかり、その間の接客品質はシフトの巡り合わせで決まってしまいます。 壁 具体的な場面 ビジネスへの影響 知識の属人化 「あの商品どこ？」にベテランしか即答できない 接客品質がシフト次第でばらつく バックヤード往復 「在庫ありますか？」の確認で往復 2〜3 分 お客様は待ちきれず離脱、販売機会を損失 両手が塞がる 品出し・調理中に端末を取り出せない 情報を調べる行為自体が業務の中断になる タスク管理の断絶 品出し・値札変更等が口頭伝達やメモベース 抜け漏れ・重複対応が発生、連携コストが高い 言語の壁 外国人スタッフがマニュアルにアクセスできない 戦力化がさらに遅れ、業務の偏りが生まれる 生成 AI によるチャットボットの業務活用は一般的になりつつあります。しかし、画面とキーボードを前提とした UI は、品出し中・調理中・接客中など「両手が塞がる」現場では使いにくく、情報を調べる行為自体が業務の中断になってしまいます。 そこで本デモでは、 スマートグラス × 音声 AI エージェント という組み合わせを選びました。声で聞けば、AI がベテランの知識で即答する。新人が初日からベテランの知識にアクセスできる状態を目指したデモです。 使用したスマートグラス: RayNeo X3 Pro RayNeo X3 Pro（製品ページ） 透過型フルカラー MicroLED ディスプレイ（6,000nits ピーク輝度）により、装着した本人にだけ文字やカードが浮かんで見える マイク 3 基（ビームフォーミング対応）+ ステレオスピーカー 2 基を内蔵し、音声入力と再生がグラス単体で完結 スピーカーは耳を塞がない骨伝導方式。AI の音声を聞きながらお客様との会話や店内アナウンスも聞き逃さないため、通常のイヤホンのように業務を阻害しない スナップオン式の度付きインサートレンズに対応。普段メガネをかけている方でも視力を補正した状態で体験可能 図 2: 本デモで使用したスマートグラス RayNeo X3 Pro。見た目は普通のメガネながら、AR ディスプレイ・マイク・スピーカーを内蔵 本デモでは、右フレーム上部の物理ボタンをワンクリックすると音声入力が始まるようアプリを実装し、来場者が迷わず操作できるようにしました。 なお、本ソリューションは特定デバイスに依存しません。「音声を送り、テキスト・画像を受け取って表示する」API を呼び出せるスマートグラスであれば、他機種にも置き換え可能です。 体験シナリオ 来場者には 1〜2 分で、スーパー / アパレル / 飲食の 3 業態から興味のあるシナリオを選んでいただきました。 図 3: ブースに掲示した操作手順と質問例のパネル ここでポイントとなるのが、AI の回答が 音声と AR 表示の 2 チャネルで同時に届く ことです。 音声 : 耳で聞きながら手を止めずに作業を続けられる AR 表示 : エリア番号や在庫数など「聞き逃したら困る情報」が視界に残り続ける 「音声で概要を掴み、詳細は視界のカードで確認する」という組み合わせが、ハンズフリーでも確実な情報アクセスを実現します。それでは、代表的なやり取りをご紹介します。 スーパー: バイト初日でもベテランの案内 入社初日のアルバイトスタッフ。お客様に「コーヒーはどこ？」と聞かれたが、売り場配置をまだ覚えていない。 [スタッフ] 「コーヒーはどこですか？」 [音声] 「有機コーヒー豆 200g は C-02 エリアにあります。在庫は 7 点です」 売り場を覚えていない新人でも、音声で答えを聞きながら、視界に残るエリア番号を頼りにお客様をそのままご案内できます。 図 4: 商品名・棚位置・在庫を AR カードで表示（実際の UI を背景に合成して再現。実機では背景が現実の視界になる） スーパー: 「ありません」で終わらない接客 品出し中のスタッフ。お客様から在庫を聞かれたが、自店舗には在庫がないケース。従来なら「ありません」で終わるところを、AI が在庫システムを参照し近隣店舗の在庫まで提示する。 [スタッフ] 「食パンはありますか？」 [音声] 「食パン 6枚切りは、幕張店には在庫がありませんが、麻布台店には 12 点の在庫があります」 自店舗に在庫がないと判断すると、AI エージェントが指示されなくても近隣店舗の在庫を検索し、代替案を提示します。 図 5: 自店舗に在庫がない場合、近隣店舗の在庫を表示 アパレル: EC へのシームレスな誘導 アパレル店舗の接客スタッフ。お客様が欲しいサイズが店舗に無い場合、近隣店舗や EC サイトの在庫まで自動で探し、売り逃しを防ぐ。 [スタッフ] 「Tシャツの L サイズはありますか？」 [音声] 「L サイズの Tシャツ ベーシック 白は、幕張店には在庫切れですが、EC サイトに 5 点あります」 店舗 → 近隣店舗 → EC と段階的にフォールバックするため、売り逃しが発生しません。この「在庫切れでも終わらない接客」は、来場者に最も驚かれたポイントの一つでした。 図 6: サイズ別在庫を表示。在庫切れサイズは EC 在庫も表示 飲食: 予約確認 飲食店のホールスタッフ。料理を運びながら、次のテーブルの予約状況を確認したい。端末を取りに行かずに声だけで確認できる。 [スタッフ] 「テーブル 5 の予約状況は？」 [音声] 「テーブル 5 は伊藤様、2 名、17 時半から 19 時半です。ラストオーダーは 19 時です」 予約確認も声だけで完結。テーブル番号を聞くだけで予約者名・時間帯・ラストオーダーまで即座に返答します。 図 7: テーブル番号・予約者名・時間帯・ラストオーダーを表示 タスク管理: 声で登録 清掃担当のスタッフ。作業中に気づいたタスクを、手を止めずにその場で登録したい。 [スタッフ] 「トイレ清掃をタスクに追加して」 [音声] 「トイレ清掃をタスクに追加しました」 タスクの登録も声だけで完結。手を止めてメモを書いたり端末を操作する必要がありません。 図 8: 追加されたタスクの内容と優先度を表示 多言語: 英語で聞けば英語で返る 外国人スタッフ、または英語しか話せないお客様への対応。日本語のマニュアルや POS 端末を読めなくても、母国語で質問すれば母国語で回答が返る。 [スタッフ] “Where is the coffee?” [音声] “The Organic Coffee Beans 200g are in area C-02 at the Makuhari Store. We have 7 in stock.” 英語で話しかければ英語で回答し、AR カードの値も英語に切り替わります。 図 9: 英語で質問すると、AR カードも英語で表示 管理者からのプッシュ通知 店長がバックオフィスからフロアスタッフへリマインドを送るケース。ラストオーダーの声かけ忘れを防ぎたい。 管理画面からリマインドを送信すると、スタッフのグラスに音声と AR カードで通知が届きます。 [AR] テーブル 5 ラストオーダー [音声] 「テーブル 5、ラストオーダーの時間です」 インカムのように全員に割り込むのではなく、必要な情報を必要なスタッフへ届けられます。 図 10: プッシュ通知の流れ。上が店長の管理画面（リマインド送信ボタン）、下がスタッフのグラスに届いた通知 Agent Monitor: AI の思考プロセスを「見せる」 音声対話はグラス装着者にしか聞こえません。そこでブースの大型モニターに、AI エージェントが「商品検索 → 在庫確認 → 棚位置取得」と業務システムを呼び出す思考プロセスをリアルタイム表示しました。 図 11: Agent Monitor の動作画面。「コーヒーはどこ？」と聞いた瞬間から、ツール呼び出しの思考プロセスがリアルタイムに表示される 順番待ちの来場者にも楽しんでいただけると同時に、技術的な会話のきっかけとしても機能しました。 ご来場いただいたお客様の声 ブースには約 500 名の方にお立ち寄りいただき、多くのポジティブなフィードバックをいただきました。 図 12: AWS Summit Japan 2026 ブースの様子 最も大きな “Wow” を生んだのは、やはりスマートグラス越しに情報が浮かんで見える AR 体験そのものです。一方で技術者の方が驚かれていたのは別のポイントで、Amazon Nova 2 Sonic の応答の速さと、業務システムと自然に連携する Tool Use でした。 「スタッフがアトラクション・イベント・食事の確認に苦労しているため、導入検討したい」（テーマパーク業界） 「工場の業務が属人化しており、マニュアルを読み込ませて活用したい」（製造業） 「スーパー、ホームセンター、コンビニ、外食、アパレルなど店舗スタッフの業務支援に使いたい」（流通小売業界） 店舗向けに設計したデモにもかかわらず、ご来場いただいた方々には、「手が塞がる現場」「知識が属人化した現場」という共通項で自社の課題に置き換えて受け取っていただきました。私たちが訴求した「店舗業務支援」よりも一段抽象度の高い「現場の知識アクセス」というニーズが存在することは、展示を通じて得られた大きな気づきでした。 システム構成と技術的なポイント ここからは、本デモの技術構成をご紹介します。体験シナリオの裏側では、次の一連の処理が数秒で完結しています。 スタッフの声がスマートグラスからクラウド上の AI モデルに届く AI が発話を理解し、「どの業務システムに問い合わせるべきか」を自律的に判断してツール（商品検索・在庫確認など）を呼び出す ツールの結果を組み立てて、音声と AR 表示の両方で回答を返す この「AI が自分でツールを選んで呼び出す」仕組みは Tool Use と呼ばれ、本デモのアーキテクチャの中核です。以下、この流れを支える各コンポーネントを解説します。 全体アーキテクチャ 図 13: システムアーキテクチャ全体像 レイヤー コンポーネント 実体 役割 クライアント スマートグラス RayNeo X3 Pro (Kotlin + Jetpack Compose) 音声入力・AR 表示 クライアント Agent Monitor Next.js ( Amazon ECS Fargate) 思考プロセスのリアルタイム表示（ AG-UI プロトコル） 音声・推論 Sonic Sidecar ECS Fargate (Python) グラスと AI の橋渡し（WebSocket / SSE） 音声・推論 Amazon Nova 2 Sonic Amazon Bedrock (us-east-1) 音声理解・推論・Tool Use・音声生成を 1 モデルで完結 ツール接続 AgentCore Gateway Amazon Bedrock AgentCore Lambda を MCP ツールとしてエージェントに公開 バックエンド 業務ツール群 AWS Lambda (Python, ARM64) × 5 商品検索・在庫確認・棚位置取得・タスク管理・予約確認 データ 商品マスター Amazon OpenSearch Serverless + Amazon Titan Text Embeddings V2 セマンティック検索 データ 在庫・棚・タスク Amazon DynamoDB トランザクショナルデータ 全リソースは AWS CDK (TypeScript) で定義しています。 Amazon CloudFront による配信を組み合わせたマネージド構成です。 アーキテクチャのポイント 1. Amazon Nova 2 Sonic のネイティブ Tool Use で「1 モデル完結」 Amazon Nova 2 Sonic は、音声を直接入力として受け取り、音声で直接回答を返す Speech-to-Speech モデルです。従来の音声アシスタントでは「音声→テキスト変換 (STT) → テキスト LLM で推論 → テキスト→音声変換 (TTS)」と 3 つのステップを組み合わせる必要がありましたが、Nova 2 Sonic はこれを 1 モデルで完結させます。さらに、推論の途中でバックエンドのツールを呼び出す Tool Use もモデル内で行われるため、レイテンシとシステム複雑性の両方を削減できます。 本デモでは Sonic Sidecar が Nova 2 Sonic と双方向ストリームを張り、モデルから toolUse イベントを受け取るとバックエンドのツールを呼び出し、結果を返します。モデルは必要に応じて複数ツールを連鎖的に呼び出し（商品検索 → 在庫確認 → 棚位置取得）、最終的に音声で回答を生成します。 Amazon Nova 2 Sonic モデルカード（ドキュメント） 2. AG-UI プロトコルによる思考プロセスのリアルタイム可視化 Agent Monitor は AG-UI (Agent-User Interface) というプロトコルでエージェントの実行状態をストリーミング受信しています。AG-UI は「エージェントの中で今何が起きているか」をフロントエンドにリアルタイムに伝えるためのプロトコルです。本デモでは RUN_STARTED 、 TOOL_CALL_START 、 TOOL_CALL_RESULT 、 TEXT_MESSAGE_CONTENT といったイベントを SSE で逐次受け取り、エージェントが「今何を考え、どのツールを呼んでいるか」をリアルタイムに描画しています。フロントエンドのフレームワークを問わず同じイベントストリームを消費できるため、UI を独立して開発・差し替えできます。 3. Amazon Bedrock AgentCore Gateway で既存業務システムを簡単に接続 Amazon Bedrock AgentCore Gateway は、既存の API や Lambda 関数を AI エージェントが呼び出せるツールとして公開するマネージドサービスです。ツールの公開には、AI エージェントとツールをつなぐ共通規格として広く採用されている MCP (Model Context Protocol) を用いており、エージェントのフレームワークを問わず接続できます。本デモでは商品検索・在庫確認・棚位置取得・タスク管理・予約確認の 5 つの Lambda を Gateway に登録し、エージェントから MCP プロトコルで呼び出せるようにしています。 これにより、既存の業務システム（商品マスタ / 在庫マスタ / 基幹 API 等）を Gateway にツールとして登録するだけで、AI エージェントから即座に利用可能になります。Lambda でラップする方法に加え、OpenAPI 仕様に準拠した既存の REST API をそのまま登録することもできます。認証（IAM SigV4）やツールのセマンティック検索も Gateway が管理するため、エージェント側の実装を変更せずにツールの追加・差し替えができます。 Amazon Bedrock AgentCore Gateway（ドキュメント） 他業界への応用 本ソリューションのコアパターン「スマートグラス × Speech-to-Speech × ネイティブ Tool Use」は、手が塞がる業務環境全般に適用可能です。 業界 適用イメージ 製造 設備マニュアル・作業手順の音声照会、点検記録のハンズフリー登録 物流・倉庫 ピッキング位置案内、在庫照会、作業指示の音声受け取り 医療・介護 器材の所在確認、申し送り事項の音声記録 テーマパーク・ホテル 施設情報の即時照会、多言語での接客支援 技術的には AgentCore Gateway にツールを追加登録するだけで異なるドメインに対応できるため、自社の業務システムを Gateway に接続するだけで同様の体験を実現できます。 まとめ 本記事では、AWS Summit Japan 2026 で展示した「スマートグラス × 音声 AI エージェント」によるハンズフリー店舗業務支援デモをご紹介しました。 「あの商品どこ？」に新人が即答できない。この小さな困りごとの裏には、知識の属人化、販売機会の損失、外国人スタッフの戦力化といった、現場が長年抱えてきた課題が積み重なっています。声で聞けば AI がベテランの知識をスマートグラス上に AR + 音声で即答してくれる体験は、これらの課題への一つの答えになり得ると、来場者の皆様の反応を通じて実感しました。 そして、この体験を支える技術は決して特別なものではありません。Amazon Nova 2 Sonic と Amazon Bedrock AgentCore Gateway を中心としたマネージドサービスの組み合わせで構成しており、既存の業務システムをツールとして接続すれば、同様の仕組みをご自身の環境でも実現できます。 「手が塞がっている現場での情報アクセス」は、小売・飲食に限らず、製造、物流、医療、ホスピタリティなど多くの業界に共通する課題です。本記事が、現場業務への音声 AI エージェント活用を検討されている方の参考になれば幸いです。