「あの商品どこ？」というお客様からの一言に、新人スタッフは即答できるでしょうか。 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 エージェント活用を検討されている方の参考になれば幸いです。

こんにちは、エス・エム・エスでカイポケコネクトのSREをしている 小笠原翔太 です。 2026年7月10日に開催された SRE NEXT 2026 のスポンサーセッションで、「 PR単位で使い捨てるカイポケコネクトのpreview環境の設計と運用 」というタイトルで発表しました。 発表スライドも公開していますが、せっかく取り組みについて文章をまとめたのでテックブログにも展開しようと思い、まとめ直したものがこちらの記事となります。発表内容に加えて、ブースで展示していた現在のpreview環境のアーキテクチャについての補足説明も加筆しているので、そちらは発表との差分となっています。 はじめに 全体の話はひとことでいうと、 既存プロダクトにPR単位で使い捨てられるpreview環境を導入し、1年間運用してきた話 です。 目次 はじめに 目次 カイポケコネクトと開発フェーズ カイポケコネクトとは システムアーキテクチャ 開発フェーズ 当時のリリースフロー リリーストレインの課題 1. リリース周期が長い 2. QA環境の利用が詰まる 3. 担当者の負担が大きい 解決策： 検証作業を分離して並列化する preview環境をどう設計したか 必須要件 インターフェース設計 アーキテクチャ デプロイフロー サービス構成 設計時に考えたこと 運用してどうだったか 狙いどおりリリース頻度を高められた 段階的に改善しながら育てた 結果的に利用が伸びた 運用してわかったこと 1. 複製機構の利用技術についてわかったこと 2. 複製「できない」外部サービスとの付き合い方が難しい 3. preview環境の想定外な需要が見えた まとめ 付録: 現在のアーキテクチャの紹介 カイポケコネクトと開発フェーズ カイポケコネクトとは 最初に、私たちが扱っているシステム「カイポケコネクト」は、介護/障害福祉事業者向け経営支援を行うSaaSプロダクトです。 システムアーキテクチャ カイポケコネクトのシステムアーキテクチャは、拡張性と独立性を保つためドメインごとにアプリとDBを分割して設計しています。 利用されている技術スタックと本番系の基盤構成は次のとおりです。 レイヤー 技術スタック 本番系の基盤構成 フロントエンド React / Next.jsによるSPA CloudFront + S3 バックエンド Kotlin / Spring Boot / GraphQL ECS Fargateでホスティング。5つのタスクでGraphQL APIを構成 DB PostgreSQL RDS Aurora PostgreSQL また、本体サービスとは別の複数の社内サービスとも連携しており、バックエンドのコンテナ数から考えると中規模サイズのシステムと捉えてもらうと良さそうです。 開発フェーズ プロダクトは初期の開発フェーズが完了し、プロダクトの価値を拡大する「機能追加・サービス拡大フェーズ」へ移行しようとしているタイミングでした。 そのため、 プロダクト開発の生産性を支えるために機能開発を加速させる必要があった というのが背景です。 当時のリリースフロー そのような開発の事情があるなかで、当時のリリースフローは以下のようになっていました。 当時のリリースフロー デプロイ先のAWS環境はDev, QA, Staging, Productionの4つ用意してそれぞれ使い分けていました。 まず開発フェーズでは、開発者がPRを用意してテストが通ればmainにマージしてDev環境にデプロイしていました。Dev環境は開発者が最初にデプロイするAWS環境で、少し壊れやすいのですがアプリの動作検証や基盤の構成変更の検証を行う用途で利用されていました。 一方で、本番系へのリリースフェーズでは、それとは別で リリース担当やリリースマネジャーが主導してデプロイする方式 を取っていました。 具体的には以下の流れでリリースが行われていました。 リリース担当がリリースするrevisionを決めてコードフリーズを行い、そのrevisionでQA環境へデプロイする 全QAメンバーがQA環境を占有して検証作業を実施 リリース担当がリリースタグを作成し、Staging環境へデプロイする リリース担当がテストランナーでE2Eテストを実行する リリース担当がリリースタグを作成し、Production環境へデプロイする QA環境はバージョンを固定して検証を行うための専用環境、Staging環境はE2Eテストを実行して意図しないデグレが発生しないことを保証するための環境という建付けでした。 つまり、いわゆる リリーストレイン方式でリリース していました。 リリーストレインの課題 このプロジェクトにおけるリリーストレインには大きく以下3つの課題がありました。 1. リリース周期が長い 最も大きな課題はリリース周期が長いこと です。このプロジェクトのリリースサイクルは2週間に一度でした。 開発スピードに対してリリースサイクルが長いため、価値提供の大きなボトルネックになっていました。またリリース時には2週間分の差分がまとめて本番へ反映されます。そのためリリースのタイミングで事故が起きやすく、問題発生時の切り分けも難しい状態でした。 2. QA環境の利用が詰まる 次の課題としてはQA環境の利用が詰まるという問題がありました。QA環境は検証用の占有環境として利用され、かつ 全QAメンバーが直列に検証作業を行うためどうしても長期間ロックされてしまいます 。結果的に検証期間が長引き、当時は1週間ほど環境を確保するようになっていました。 検証作業を効率的に実施できず、その間は新しいリリースもブロックされる構造になっていました。 そのため、 今後開発を加速させようとしたときに、ここの詰まりによってスケールできなくなることが容易に想像できました 。 3. 担当者の負担が大きい リリーストレインのもう1つの問題として、取りまとめを行う人の負担が大きいという人的な問題もありました。リリース担当やリリースマネージャーがリリースを主導する必要があるのですが、そこに 運用作業とリスク管理の負荷が集中 していました。 ミスを防ぐための手動プロセスや手順も増えがちで、運用が重厚になっていました。さらに、リリースされる差分のすべてを把握することが困難でした。そのため、問題発生時の対応に手間取ったり、チームをまたいだ調整コストが増えたりして、担当者を疲弊させていました。 解決策： 検証作業を分離して並列化する 解決策として考えたのは「 リリースフローから検証作業を分離して並列化する 」ことです。 以下の図は検証作業を分離・並列化したときのリリースフローの概念図です。 検証作業を分離・並列化したリリースフロー これまでリリースフェーズで行っていた QA環境での検証作業をすべて開発フェーズに移行 しています。 開発フェーズで開発者がPRを作成したあとに専用の検証環境を立ち上げ、QAメンバーがPRごとに検証作業を並列で実施できるようにします。 そして、リリースフェーズでは、Dev環境にデプロイした後は毎日定時にGitHub Actionsのscheduled workflowを起動します。このジョブはStaging環境へのデプロイからE2Eテストの実行、production環境へのデプロイまでを連続して実行する軽量なワークフローです。 また、リリースフラグを導入することで、PO（プロダクトオーナー）が任意のタイミングで新機能をリリースできるようにします。 この方式に変更することで次の効果を狙います。 リリースが毎日できる ：隔週から毎日へと頻度が上がり、価値提供が高速化。デプロイごとの変更差分が小さくなり、原因特定も容易になる QAのシフトレフトと並列化 ：検証作業を開発フェーズに移すことでリリースを安定化させ、チームや機能ごとに検証作業を並列化することで詰まりを解消する プロセスの軽量化 ：重厚なリリース手順を廃止し、リリースフローを自動化・軽量化する。リリースフラグを導入することでデプロイと新機能の有効化（機能リリース）を分離する 先ほど紹介したリリーストレインの主要課題をすべて解決できるようになっています。 preview環境をどう設計したか 先ほど述べた、リリース改善施策実現に必要な構成要素の1つが、検証作業を行うための環境（私たちはこれをpreview環境と命名）でした。 この章ではそのpreview環境をどう設計したかについて説明します。 必須要件 まずQAプロセスで必要な要件は以下3つでした。 十分な数の環境を 容易に 作れること 利用チームが 任意のバージョンをデプロイできる こと DBを使い捨てできること ーデータが汚れることを気にせず占有して使えること インターフェース設計 次に利用者のインターフェースの設計についてですが、こちらはVercel等のSaaSの開発者体験を参考にして以下のように設計しました。 GitHubのイベントをトリガー に、preview環境を自動で構築・更新・破棄する PRのコメントに自動で 各種アクセス情報を付与 する 以下はpreview環境を立てたPRのサンプルです。 preview環境を立てるPRのサンプル PRにラベルを付けると環境構築が始まり、完了するとbotがコメントでアクセス方法を案内する、という開発者体験になっています。 このようにインターフェースを作った理由は、以下を狙ったためです。 開発者とQAのスムーズな連携 ：開発者がPRに実装をまとめ、それをQA担当者へ渡すことでスムーズに検証作業に移ることができる ライフサイクル管理のしやすさ ：環境がPRに紐づくため、不要な環境の消し忘れを防いだり、クリーンな環境管理が可能になる アーキテクチャ 次にpreview環境のアーキテクチャを紹介します。全体像は以下のようになっています。 preview環境のアーキテクチャ全体図 デプロイフロー まず、preview環境のライフサイクルはGitHub Actionsのワークフローで以下のように管理します。 PRにpreviewラベルを付与 : PRの先頭のコミットハッシュを利用して環境を構築する PRにコミットをプッシュ : 差分が入ったコンポーネント（FE/BE/DB）のみ更新処理を行う PRをマージ、クローズまたはpreviewラベルを外す : 環境を削除する サービス構成 次にサービス構成ですが、 preview環境ごとにフロントエンド/API/DBを1セットずつ用意する ようになっています。 ドメインは https://preview-N.kaipoke.com （NはPR番号）を環境ごとに払い出しており、そこからアクセスできます。 フロントエンドはSPAなので、シンプルにCloudFrontとS3で配信しています。リクエストのホスト名に応じてアセットを出し分けるようにLambda（CloudFunction）を挟んでいます。 APIへのアクセスはCloudFrontとALBを介してmirage-ecsコンテナのproxy機能でハンドリングされ、ホスト名ごとにリクエストを各環境に振り分けています。環境ごとにバックエンドとDBが1セットずつ用意されており、バックエンドのECSタスクは mirage-ecs で、DBはSaaSの Neon でそれぞれ構築・管理しています。 なお、バックエンドは一環境あたりECSタスクが全部で5個動いており、内部でGraphQLのfederationを組む構成です。 モニタリングは本番系と同じくDataDogを利用して、トレースやログ、基盤のメトリクスを確認できるようにしています。 このような仕組みによって、 PRごとの環境をAPIやDBまで独立した形で複数個準備できるように作っています 。 参考情報ですが、環境の初期構築にかかる時間は2026/07/14時点で 10分程度 です。 設計時に考えたこと 設計にあたっては、以下3つの原則を守るようにしていました。 要件が不明確なうちから作り込まない ：初期段階での過剰な設計や実装を避けるため 運用・開発の負担が少ない技術を選ぶ ：当時は アプリ開発者のリソースが逼迫 しており、開発者の負担を極力抑える必要がありました 最初から完璧を目指すのではなく継続的に提供価値を高めていく ： 仕組み作りに使えるSREのリソースが当時少なかった ため、小さく作って継続的に提供価値を高めていく方針を採用 運用してどうだったか 実際に1年ほど運用してどうだったか、振り返っていきます。 狙いどおりリリース頻度を高められた まず 当初の狙いにしていたリリース頻度を高めることには成功 しました。 以下は月別のデプロイ回数の推移を表したグラフです。 月別デプロイ回数の推移 リリース方式を切り替えた2025年10月ごろから、 月2回だったデプロイが月20回前後まで増えました 。営業日は毎日リリースできるようになったことがわかります。 これはpreview環境以外の施策との合わせ技による成果ではありますが、 サービス拡大期の開発効率の向上に貢献できた と考えています。 段階的に改善しながら育てた そして、設計方針に従ってpreview環境は導入後に要件を適宜見直しながら改善しました。 以下のグラフはpreview環境に関するPRの月別件数推移を表しています。 preview環境に関するPRの月別件数 全体のタスク量は多く、PR総数も結果的に 200件超となっていた のですが、対応を段階的に行うことで少人数（設計から導入初期までは担当一人）でも早期に仕組みを開発に展開でき、その後の改善も継続することができました。 設計時に置いた「小さく作って継続的に改善する」という原則が、うまく機能した と感じています。 結果的に利用が伸びた 結果的にpreview環境の利用数は順調に伸びました。以下は月別のpreview環境を利用したPRの件数推移のグラフです。 preview環境を利用したPRの月別件数 導入当初は80件ほどだった利用件数が2026年6月は160件程度まで利用が伸びている ことがわかります。 あとでも触れますがこれは当初想定の用途以外の利用が増えたことも理由となっています。 運用してわかったこと 次に運用してわかったことや気付きについて大きく3つ紹介します。 1. 複製機構の利用技術についてわかったこと 今回、バックエンドの複製には mirage-ecs というコンテナ管理の軽量なOSS、DBの複製にはSaaSの Neon を使いました。 まずmirage-ecsは、既存のECS Fargate構成とデプロイの仕組み（ecspresso）にアドオンする形で導入できました。ecspressoの作者が作ったツールのため、 親和性が高くデプロイの仕組みをそのまま維持することができました 。 ツール導入で学習すべき新しい概念が少なく、メンテナンスも簡単で、開発チームへの負担を最小限に抑えながら導入できたのは非常によかったです。現在まで、他ソリューションへの置き換え検討が必要となる問題も出ておらず、安定して運用できています。 次にNeonですが、直感的で扱いやすいWeb UIや高速なブランチ機能、各種管理機能が充実しており、 DB複製機能の初期導入にかかる工数を大幅に削減できた のは良かったです。 一方で、サーバ配置先の制約による性能課題がありました。DBの配置先は最寄りでもSingaporeリージョンのため、SQL実行時のレイテンシーが大きくなり、 結果として一部のページで表示に時間を要する点が課題として残ってしまいました 。 機能検証においては無視しても問題ないということでしばらくはそのまま利用していましたが、動作がもっさりするのでなんとかしたいという声が多く出る状況でした。 そのため、現在はtokyoリージョンに立てたAurora Serverless v2（RDS）を利用する方式をメインに運用しています。付録にてそちらのアーキテクチャについては補足します。 2. 複製「できない」外部サービスとの付き合い方が難しい 2つ目の気づきですが運用してみて実感したのは、 プロダクト本体の複製よりも、複製できない外部サービスの扱いが難しい 、ということです。 本体の複製は開発チームでコントロールできるのですが、利用している外部サービス（連携する社内サービス含む）には様々な制約があり、それぞれ妥協案を作って運用していく必要がありました。 例えば認証基盤については契約プランの制約でテナントを新規作成できなかったため、既存テナントに相乗りする形で対応しました。 結果的に（特に不便なく運用できているものの）Dev環境のDBをコピーする方式を選択せざるを得なくなりました 。 ある社内サービスではアーキテクチャ上の制約により、環境複製の難易度が高くすぐには実現できませんでした。 結果的に既存環境に相乗りし、preview環境向けのデータを識別できるようにアプリを改修してもらい、運用でカバーする形になりました 。 また他の社内サービスでは、契約プランや予算管理上の制約があるため環境の複製ができないため、特定のpreview環境にのみ期間限定で連携するというような運用になりました。 これらの外部サービスに共通する課題は2つあります。1つは、 連携が増えるたびに運用の取り決めや調整を個別に行う必要があり、対応コストの増加につながる 点です。もう1つは、 自チームだけではコントロール・解決できない他部署・他チームの仕様や予算制約が絡むケースも多く、難易度を引き上げている点 です。 preview環境を有用な状態で維持するためには外部のサービスをうまく検証用途で動かし続けるための工夫という、技術以外の課題をクリアしていく必要がある点に注意が必要だと強く感じました。 3. preview環境の想定外な需要が見えた 3つ目の気づきはpreview環境の想定外な需要が見えたことです。 当初はQAプロセスでの利用を想定していたのですが、実際は 全体の8割が開発チームの自主的な動作確認・検証目的で利用 されていました。QA引き渡しでの利用は予想に反して全体の20%にとどまっていたのです。 開発者のユースケースには例えば以下がありました。 リスク回避 ：Dev環境へのデプロイ前の早期リスク検知 DB migrationの確認 ：DB migrationの簡単で安全な検証に利用 AIを活用した並列開発 ：複数PRを互いに影響させず同時に検証 ローカル代替 ：一時的にローカルがうまく起動できない場合などに代替の検証環境に利用 つまり 「容易に立てられる検証環境」の存在自体が、開発体験（DX）にとって実は大きな価値になっている ことが運用してから初めてわかりました。設計時は実際にどのくらい使われるか見えておらず、これは運用後の一番大きな気付きでした。 まとめ 既存プロダクトにpreview環境を導入・運用して見えてきたことは、次の3点です。 環境運用の実現性 ：今回の技術スタックでも、中規模システムのpreview環境は十分に運用できることがわかりました。少人数で運用でき、開発負担も小さく抑えることができました 外部連携の課題 ：本体の複製以上に、複製できない外部サービスとの連携設計が重要になることがわかりました 導入後の進化が大切 ：今回のように導入してから改善していくアプローチでは、運用に乗ってからの継続的な改善こそが本番となります。プロダクトの成長に合わせて育てていくことが重要です preview環境というコンセプト自体は目新しくありませんが、既存プロダクトへ導入して1年間運用してきた知見が、読んでいただいた方の参考になれば嬉しいです。 なお、発表資料は Speaker Deck で公開していますのでそちらも適宜参照してください。 付録: 現在のアーキテクチャの紹介 当日の発表スライドではお見せできなかったのですが、ブースで展示・紹介していた現在のアーキテクチャは以下のようになっています。 現在のアーキテクチャ全体図 先に紹介したアーキテクチャとの違いは DBの複製機構がNeonからAurora Serverless v2（RDS）を利用した形に変わっている ところです。 サービスごとに1つインスタンスを用意し、preview環境ごとに内部的にPostgreSQLのデータベースを作り、dump/restoreでDev環境のデータを流し込んで作っています。 Neonで利用者によく使われていたWeb UIについては、自作して提供しています。 Web UIの画面サンプル（接続ページ） Web UIの画面サンプル（テーブルビュー） データベースの中身を気軽に閲覧したり、テーブルの値をGUIで編集する、SQLを実行するなどの機能を持った軽量なDBのwrapperツールとなっています。以前は自力でこのようなツールを作るのは工数的に難しかったのですが、生成AIの力を借りることで要件の緩い社内ツールであれば数日で作成できるようになっていて大変ありがたい限りです。 なお、RDS方式はNeonと比較すると新しいデータベースを作るのにかかる時間は少し大きくなっています。これはdump/restoreで複製を行っているためで、現状は最大4分程度かかっています。データ量が増えるとCopy on Write方式でクローンするNeonに優位性が出る可能性もあり、このあたりは利用実体を確認しながら都度調整していく必要があると考えています。

こんにちは。LINEアプリ開発SBU AIディベロッパーエクスペリエンスチームの onevcat（王 巍）です。最近は、AI エージェントを開発・検証のループに組み込むためのツールづくりに取り組んでい...