音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション

本ブログは、株式会社アドバンスト・メディア様と Amazon Web Services Japan が共同で執筆いたしました。

1. はじめに

みなさま、こんにちは。AWS ソリューションアーキテクトの本田・戸塚と、アカウントマネージャーの兼子です。

本ブログでは、AWS Summit Japan 2026 で展示した、食品調理現場における業務課題を、音声 AI とマネージドエージェント基盤で解決するアーキテクチャをご紹介します。 Amazon Bedrock AgentCore Runtimeと Strands Agents SDK による AI エージェント、AmiVoice による高精度な日本語音声認識、Amazon DynamoDB や AWS Lambda によるサーバーレスバックエンドを組み合わせ、「手を使わずにレシピを操作できる」ハンズフリーオペレーションを実現しています。

AWS 側ではエージェント設計・クラウドアーキテクチャ・リアルタイム通信の観点から、アドバンスト・メディア社側では音声認識エンジン AmiVoice の技術特性・業界特化チューニング・認識精度向上の観点から、それぞれ解説します。

2. 飲食業界における現場オペレーションの課題

食品調理の現場、特にセントラルキッチン（複数店舗向けの集中調理施設）では、以下の構造的な課題が存在します。

2.1 手が塞がる環境でのデータ入力障壁

調理作業上、両手は鍋・包丁・計量器などで塞がっています。加えて、衛生管理の厳しい調理現場では衛生手袋を着用しながら調理するため、レシピ確認や在庫記録のたびに手袋を外してタブレットを操作する必要があります。セントラルキッチンでは複数ホテル・複数レシピ向けに大量の食材を一括管理する必要があり、在庫記録の重要性がより高い一方で、以下の問題が連鎖的に発生します:

• 手袋着脱による作業中断と衛生リスクの増大。また、食品安全のために中心温度の測定・記録が義務付けられているが、手作業での記録は漏れやすく、コンプライアンス違反のリスクがある
• 紙・Excel 依存によりデータがデジタル化されず、経営判断に活用できない
• 配布されたレシピを調理現場で調整しているが、現場でカスタマイズされ、記録されずに属人化している
• レシピは調理現場に持ち込まず、バックヤードに置いているため、新人や不慣れなメニューの場合は頻繁にバックヤードと調理場を往復することになり、作業効率の低下を招く
• 調理工程の進行状況が在庫管理システムと連動しておらず、食材の消費を都度手入力で記録する必要がある。入力が漏れると在庫の把握精度が下がり、食材切れへの対応が遅れる

2.2 音声認識活用のハードル

音声入力は「手が塞がる環境」の自然な解決策ですが、キッチン特有の課題があります。換気扇・鍋の音などの騒音環境、食材名の専門用語（食品業界固有の表現や略称）、そして方言やイントネーションの多様性です。汎用の音声認識エンジンでは認識精度が業務品質に達しないことが多く、業界特化の音声認識技術が求められます。また、騒音やノイズのある環境下で、正確に発話の意図を把握して操作する精度も求められます。

2.3 レシピ一括管理の困難さ

これらの課題は、「現場で変更された変更がレシピ側に伝達されないこと」につながります。調理器具の違いや材料不足、その日の気温といった外的要因からしばしばレシピの変更が発生しますが、手袋着脱や両手作業による入力障壁がデータ不在を生み、それが管理者の可視性欠如、ひいては経営判断の根拠不足へと連鎖していきます。本ソリューションは、高精度な音声認識とAI エージェントによる入力障壁の解消とオペレーションの容易さを起点に、アプリの利用を通じてデータを構造化して蓄積することでこの課題を解決します。

2.4 調理工程の分担・シフト管理の非効率

セントラルキッチンでは、複数の調理スタッフが並行して異なる工程を担当します。しかし担当者の割り当てやシフトの組み合わせは現状では管理者が手動で判断・調整しており、以下の問題が生じやすい状況です:

• 各スタッフの習熟レベルや当日の人員状況を考慮した工程分担の最適化が属人化しており、担当管理者の経験と勘に依存している
• 突発的な欠員や工程の遅れが発生した場合の再割り当て判断に時間がかかり、他工程への連鎖遅延が発生する
• 調理実績データ（誰がどの工程に何分かけたか）が記録されないため、シフト最適化のための根拠データが蓄積されない

3. ソリューション概要

本ソリューションは、ハンズフリーで操作できるレシピ管理ソリューションです。調理者が音声だけで指示した内容を汲み取り、レシピ工程を進め、AIエージェントが次の工程へのナビゲーションや原材料チェック、工程メモといった操作を判断します。

AmiVoice が調理スタッフの発話を高精度にテキスト化し、AI エージェント（Amazon Bedrock AgentCore + Strands Agents）が意図を解釈して、レシピナビゲーション・在庫減算・履歴記録を自律的に実行します。調理スタッフは「ちょっと楽になった」と感じるだけですが、裏側では構造化データが自動的に蓄積され、管理者のリアルタイム可視化と意思決定を支援します。

3.1 主要機能

レシピ操作機能

• 音声レシピナビゲーション — 「次へ」「戻る」で工程を進め、工程完了時に使用食材の在庫を自動減算
• AI 代替食材提案 — 「玉ねぎがない」と伝えると、レシピ文脈と在庫を踏まえた代替案を提示
• 原材料チェック — 「原材料チェック、玉ねぎ300グラム」で食材を照合。玉ねぎ/タマネギ/オニオンといった発話の表記ゆれも吸収
• 調理タイマー — 音声で開始・停止・リセット
• 工程メモ — 音声でレシピ工程にメモを追加し、ナレッジの蓄積に繋げる

図1 : 個別レシピ画面

レシピの変換機能

• 現状、Excelで管理しているレシピから、システム管理できる形式への変換
• 紙管理しているレシピを読み取り、システムで管理できる形に変換

図2 : レシピ取り込み画面

ダッシュボード機能

• 調理工程ごとの時間をアプリ側で測っておき、ダッシュボード上で可視化

図3 : ダッシュボード画面

アプリケーションは以下のように動作します。

4. システムアーキテクチャ

4.1 全体構成

図4 : システムアーキテクチャ

システムは以下の 3 層で構成されています。

アーキテクチャはAI Agent基盤をはじめ、フルサーバレス構成を採用しています。そのため、インフラストラクチャの管理をAWSにオフロードすることができ、運用負荷を抑えつつ、使われていない時間帯のコストも低く抑えながら利用できます。

AI エージェントを通さない単純な読み取り操作は Amazon API Gateway から AWS Lambda を介して処理し、レイテンシを数百ミリ秒に抑えています。一方、音声を通じた操作は、AmiVoice API を介して発話内容をテキストに起こしたのち、Amazon Bedrock AgentCore で処理しています。なお、ビジネスロジックは同等の Lambda 関数を呼ぶことで、同じロジックを複数の入口から再利用しています。

4.2 AWS リソース構成

全リソースは AWS CDK で定義しています。

4.3 AI エージェント設計

本システムの核となる AI エージェントは、Amazon Bedrock AgentCore Runtime 上で動作する Strands Agentsで実装しています。

エージェントは、中央のオーケストレーターがいて、ツールを @tool デコレータでラップし、必要に応じて呼ぶ構造です。プログラマが分岐を記載するのではなく、判断そのものを LLM に任せるのが従来との大きな違いです。@tool は Strands SDK のデコレータで、関数の引数名・型とdocstringが自動的に LLM 向けの「ツール仕様」に変換されます。したがって、docstring は人間が読む際のコメントであると同時に、LLM が呼び方を理解するための仕様書にもなります。

■ ツール定義

■ プロンプト設計

システムプロンプトはハイブリッド方式を採用しています:

• 指示文（条件分岐、制約、スキーマ定義）: 英語で記載。トークン効率が高い
• コマンド例、出力メッセージ、食材名 : 日本語。ユーザー体験を優先
• message フィールドは必ず日本語で出力するよう明示的に制約

この設計により、日本語のみのプロンプトと比較して入力トークン削減を実現しつつ、日本語での自然な応答品質を維持しています。

■ 音声認識から画面操作までのフロー

図5:音声の発話からAI Agentが動作するイメージ

発話した内容をもとにページ操作を行うまでのフローは、下記の通りです。

1. 音声入力 マイクまたはテキスト入力で文字列を受け取ります。
2. コンテキストの付与 発話テキストだけ送っても、LLMは「今どのレシピの何工程目か」という情報を知りません。そのため、コンテキストとしてページの位置情報、工程の調理内容や使用する食材も送付しています。このような構成にすることで、ユーザーが「省略した言葉」を補うことができます。人間同士の会話で「次」と言えば通じるのは、お互いが状況を共有しているからです。LLMにも同じ状況を渡すことで、人間相手のように省略して発話しても操作することができます。また、騒音で音声認識が乱れてユーザーの発話を正確に書き起こしできない場合でも、表記ゆれや誤変換を吸収してLLMが意図を汲んで操作することができます。
3. LLMが遷移先を判断 システムプロンプトのルールに従い、context を見て遷移先を決定します。JSON形式で返答します。

{ "action": "navigate", "page": "recipe", "params": { "recipeId": "recipe-001", "stepNumber": 4 } }

しばしばLLMの出力をアプリケーションで扱うとき、プロンプトで「JSON形式で出力して」と指示しても、余分な説明文が付加されていたり、フォーマットが微妙に崩れていたりと出力がぶれることがあります。そこで、Amazon Bedrock の Structured outputs を利用して一貫性のあるJSON出力に強制しています。Structured outputs は、必要な形式を事前に指定してそれに一致するレスポンスを受け取ることができる機能です。

4. フロントエンド側でページを遷移 フロントエンド側のコードで、返ってきたJSONの action を見て処理を振り分けます。対応するページコンポーネントの再描画や、ページ遷移を実施します。

4.4 AI エージェント設計アプリケーションへの AmiVoice の組み込み

音声の認識には、アドバンスト・メディア社の提供する AmiVoice を採用しています。

1. マイクの起動
   • 音声認識特化型Bluetoothマイク AmiVoice Front WT01 を介してマイクを起動します。AmiVoice Front WT01は物理ボタン付きのデバイスで、ボタンを押すと Web Bluetooth API を介してブラウザ上のアプリケーションに接続します。Web Bluetooth APIはブラウザからBluetooth機器に接続する仕組みです。
2. 発話内容の読み取りと発話区間の自動検出
   • AmiVoice APIを利用して発話した内容をテキスト化します。AmiVoice APIには同期・非同期 HTTP と、WebSocket インタフェースがありますが、WebSocketインタフェースを利用して中間認識結果をリアルタイムで表示しています。ユーザーの体感速度を大きく左右する要因です。 また、音声の中で発話区間を自動検出しているため、話し終えたタイミングでボタンを押すことなく発話の終了を検知しています。AmiVoiceの発話検出では深層学習モデルを使って、人の声とそれ以外を区別していることが特徴です。

最終的に、テキスト化されたコマンドを Amazon Bedrock AgentCore に送信します。

5. 音声認識エンジン: AmiVoice の技術

(1) AmiVoice の技術的特徴

音声認識には、音声から特徴量を抽出する音響分析と、特徴量を入力として認識結果のテキストを得る認識デコーダの二つのステップがあります。様々な周波数で構成されている波形データを音響分析で音の特徴に数値化して、その特徴量を認識デコーダに入力しています。

AmiVoice APIは、認識デコーダのタイプにより、「DNN-HMMハイブリッド型（以下、ハイブリッド型）」「End-to-End型」の2つのタイプがあります。伝統的な統計モデルである、「発音辞書」「音響モデル」「言語モデル」を組み合わせて音声認識を行うハイブリッド型に対して、End-to-End型は音声入力から直接文字列を出力する一体型の処理という大きな違いがあるのですが、どちらのタイプでもDNNというディープラーニングモデルが使われています。

図6 : ハイブリッド型認識デコーダのイメージ

DNN（Deep Neural Network：ディープニューラルネットワーク）は、多層構造を持つニューラルネットワークです。ニューラルネットワークは、生物の神経回路網を計算機上で模した技術であり、音声認識の分野ではDNNを用いた音響モデルが、音声特徴量から音素を推定する仕組みとして従来のGMM-HMMに代わって主流となりました。その後、音声認識技術は、時系列データを扱いやすいLSTMやBiLSTM、さらに広範囲の文脈を効率的に学習できるTransformerへと発展してきました。これらのモデルは構造こそ異なりますが、いずれも音声と発話内容の関係を学習し、入力音声から発話内容を推定するという基本原理は共通しています。

AmiVoice APIは、音声認識技術をシンプルにご利用いただけるAPIサービスです。インターネットからの簡単な登録だけで、すぐに利用を開始できるため、音声認識機能を手軽かつスピーディーにアプリケーションやサービスへ組み込むことができます。日本語に対する高い認識精度を特長とし、ビジネス利用を想定した言語モデルにより誤認識の低減を実現しています。また、医療・金融・保険・コンタクトセンターなどの業界特有の専門用語に強く、製品名や固有名詞の登録にも対応しています。特別な知識や発声の訓練を必要とせず、普段どおりの自然な会話を高精度に認識できます。また、話者による発音の傾向やイントネーションの違いの影響を受けにくく、騒音環境や電話音声でも安定した認識性能を発揮します。国内で開発・運用されているため、音声データを国内環境で安全に管理できる点も大きな特長で、セキュリティを重要視するお客様にも多数選ばれています。

図7 : AmiVoiceの音声認識技術

AmiVoice APIを選んでいただいたお客様に高く評価されているのがリアルタイム性を追求したWebSocket API のストリーミング型音声認識です。AmiVoice APIのWebSocketインタフェースでは、クライアントが開始s・音声送信p・終了eの各コマンドを段階的に送る一方、サーバーは発話開始S、終話E、認識開始C、途中結果U、確定結果Aをイベントとして逐次返します。これにより、音声を最後まで送り切ってから一括変換するのではなく、発話区間ごとに認識を進めながらテキストを即時更新できます。さらに、発話検出で無音と発話を細かく切り分け、resultUpdatedIntervalなどの設定で途中結果の返却タイミングを制御できるため、ユーザー画面には短い間隔で認識文が反映されます。結果として、リアルタイム音声送信に対して遅延のない逐次テキスト化を実現できる点が大きな特長です。

3つの発話区間を検出した場合の、コマンドとイベントのシーケンスは以下のようになります。

図8 : コマンドとイベントのシーケンス

(2) 食品製造現場への適用と認識精度の向上

アプリケーションはキッチン等の騒音の多い環境で利用されることが想定されるため、人の声と不要音を分別して認識できる精度が必要不可欠です。AmiVoice APIは、セグメンタ（VAD）により人の発話区間を高精度に検出し、調理場などノイズの多い環境でも不要音の影響を抑制。背景音・機械音・保留音などを認識対象から適切に除外し、必要な音声だけをテキスト化します。さらに利用シーンに応じたパラメータ調整も可能で、現場で使える安定した音声認識を実現します。

AmiVoice APIは、長年にわたって蓄積した音声認識のノウハウをもとに、高精度な言語モデルを構築しています。最新のニュースや業界文書などのテキストコーパスを活用し、新語や業界特有の用語にも迅速に対応します。また、不要データの除去、専門用語の読み登録、表記統一、誤認識分析、パラメータチューニングなどを継続的に実施することで、変化する言語環境に適応しながら高い認識精度を維持します。これにより、食材名・調理用語など業界特化の語彙への対応も可能です。

同じ用語の表記ゆれに対応する際、音声認識だけでなく生成AI（LLM）を活用する方が効果的な場合があります。例えば、品種名である「ヒノヒカリ」を単語登録し、”ひのひかり”の認識精度を上げることは有用と思われます。しかし、”なす”を「茄子」や「ナス」に変換する目的で単語登録すると、意図しない箇所で「茄子」や「ナス」が誤って出現する可能性があります。このような場合の表記ゆれの統一は、単語登録ではなく、文脈を理解できるLLMに任せることで副作用を抑えながら「なす」「茄子」「ナス」を同じ食材として柔軟に扱うことができ、より高い効果が期待できます。

(3) 今後の展望

AmiVoiceは、クラウド環境だけでなく、スマートフォンやタブレット上で動作するオンデバイス型、お客様環境内で音声認識を完結できるオンプレミス型SDKも提供しています*1。音声データを外部へ送信できないセキュリティ要件の厳しい環境や、ネットワーク帯域が限られる現場でも、高精度な音声認識を実現します。利用環境や運用ポリシーに応じて最適な構成を選択できるため、製造、物流、医療、食品業界など幅広い業務シーンにおいて、安心・安全な音声活用による業務効率化を支援します。

今後は、これまで進めてきた業種・業務に特化したSaaSソリューションとの連携・組み込みをさらに拡大し、音声認識技術の活用シーンを広げていきます。加えて、新たな取り組みとして、AIエージェントが業務プロセスの中で音声認識を活用し、自律的に業務を遂行できる次世代ワークフローの実現を目指していきます。

*1 AWSMarketPlaceではクラウド型AmiVoiceAPI(AmiVoiceCloud Platform)のみの提供となっております

6. 他インダストリーへの応用可能性

本ソリューションのコアパターン「音声認識 (AmiVoice) × AI エージェント (Bedrock AgentCore) × 構造化データ自動記録」は、手が塞がる業務環境全般に適用可能です:

技術的な拡張ポイント:

• Strands Agents のツール定義 (@tool デコレータ) を差し替えるだけで異なるドメインのエージェントを構築可能
• AmiVoice の単語登録を実施することで、医療用語・製造用語などの独自の用語にも精度改善が期待できる
• AgentCore Runtime のマネージド環境でスケーラブルに運用でき、マルチテナント化も容易

7. まとめ

本ブログでは、セントラルキッチンの業務課題を、AmiVoice による高精度音声認識と Amazon Bedrock AgentCore による AI エージェントの組み合わせで解決するアーキテクチャを紹介しました:

• AmiVoice — 騒音環境・食品業界用語に対応した高精度な日本語音声認識で、現場の「声」を確実にテキスト化
• Amazon Bedrock AgentCore Runtime + Strands Agents SDK — マネージド環境で AI エージェントを運用し、WebSocket ストリーミングによるリアルタイム対話を実現
• Claude Sonnet 4 の Tool Use — 14 個のツールを自律的に使い分け、曖昧な音声コマンドから適切なアクションを導出
• 構造化 JSON レスポンス設計 — エージェントとフロントエンドの明確なインターフェース契約により、UI 制御の信頼性を確保
• サーバーレス従量課金構成 — DynamoDB On-Demand + Lambda ARM64 + CloudFront でコスト効率を最大化

「手が塞がっている環境でのデータ入力障壁」は、食品製造に限らず多くの業界で共通する課題です。高精度な音声認識と AI エージェントの組み合わせは、この課題に対する有力なソリューションパターンです。本アーキテクチャが、音声 AI エージェントシステムの設計を検討されている方の参考になれば幸いです。

著者について