本ブログは、株式会社アドバンスト・メディア様と 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 層で構成されています。 層 担当 主要技術 通信プロトコル プレゼンテーション層 ブラウザ画面・音声UI・BLE連携 Amazon S3 + Amazon CloudFront + AmiVoice API HTTPS / WebSocket / Web Bluetooth AI 判断層 音声コマンド解釈・ツール選択・応答生成 Bedrock AgentCore Runtime + Claude Sonnet 4 WebSocket (双方向ストリーミング) データ層 レシピ・在庫・履歴・チェック記録 Amazon DynamoDB + AWS Lambda + API Gateway HTTPS REST アーキテクチャはAI Agent基盤をはじめ、フルサーバレス構成を採用しています。そのため、インフラストラクチャの管理をAWSにオフロードすることができ、運用負荷を抑えつつ、使われていない時間帯のコストも低く抑えながら利用できます。 AI エージェントを通さない単純な読み取り操作は Amazon API Gateway から AWS Lambda を介して処理し、レイテンシを数百ミリ秒に抑えています。一方、音声を通じた操作は、 AmiVoice API を介して発話内容をテキストに起こしたのち、Amazon Bedrock AgentCore で処理しています。なお、ビジネスロジックは同等の Lambda 関数を呼ぶことで、同じロジックを複数の入口から再利用しています。 4.2 AWS リソース構成 全リソースは AWS CDK で定義しています。 カテゴリ リソース 用途 AI エージェント Bedrock AgentCore Runtime (Docker/Python) Strands Agent + Bedrock Claude Sonnet 4 コンピュート AWS Lambda (Python 3.12, ARM64) ビジネスロジックを実行 データベース Amazon DynamoDB Recipes / Inventory / History / IngredientChecks といったデータを保存 API Amazon API Gateway REST API Cognito Authorizer 付きデータ読み取りエンドポイント 認証 Amazon Cognito User Pool + Managed Login OAuth2 PKCE フロー、JWT 発行 CDN Amazon CloudFront, Amazon S3 SPA配信 + AgentCore リバースプロキシ + 画像CDN シークレット AWS Secrets Manager AmiVoice 認証情報を格納 IaC 補助 CloudFront Function SPA フォールバック + AgentCore パス書き換え 音声合成 Amazon Polly レシピ工程の読み上げ音声生成 4.3 AI エージェント設計 本システムの核となる AI エージェントは、Amazon Bedrock AgentCore Runtime 上で動作する Strands Agentsで実装しています。 エージェントは、中央のオーケストレーターがいて、ツールを @tool デコレータ でラップし、必要に応じて呼ぶ構造です。プログラマが分岐を記載するのではなく、判断そのものを LLM に任せるのが従来との大きな違いです。@tool は Strands SDK のデコレータで、関数の引数名・型とdocstringが自動的に LLM 向けの「ツール仕様」に変換されます。したがって、docstring は人間が読む際のコメントであると同時に、LLM が呼び方を理解するための仕様書にもなります。 ■ ツール定義 ツール名 役割 get_recipes レシピ一覧取得 get_recipe レシピ詳細取得 update_step_memo 工程メモ更新 get_inventory 在庫一覧取得 get_inventory_item 食材単品在庫取得 deduct_inventory 在庫減算（工程完了時） rollback_inventory 在庫ロールバック（戻る時） record_history 調理履歴記録 get_history 調理履歴取得 check_ingredient 原材料チェック照合 record_step_time 工程実績時間の記録 clear_ingredient_checks セッション配下の原材料チェックを全削除 invalidate_step_time 「戻る」時に工程の実時間記録を無効化 answer_recipe_question 調理に関する質問をナレッジベースから検索して返答 ■ プロンプト設計 システムプロンプトはハイブリッド方式を採用しています: 指示文（条件分岐、制約、スキーマ定義）: 英語で記載。トークン効率が高い コマンド例、出力メッセージ、食材名 : 日本語。ユーザー体験を優先 message フィールドは必ず日本語で出力するよう明示的に制約 この設計により、日本語のみのプロンプトと比較して入力トークン削減を実現しつつ、日本語での自然な応答品質を維持しています。 ■ 音声認識から画面操作までのフロー 図5:音声の発話からAI Agentが動作するイメージ 発話した内容をもとにページ操作を行うまでのフローは、下記の通りです。 音声入力 マイクまたはテキスト入力で文字列を受け取ります。 コンテキストの付与 発話テキストだけ送っても、LLMは「今どのレシピの何工程目か」という情報を知りません。そのため、コンテキストとしてページの位置情報、工程の調理内容や使用する食材も送付しています。このような構成にすることで、ユーザーが「省略した言葉」を補うことができます。人間同士の会話で「次」と言えば通じるのは、お互いが状況を共有しているからです。LLMにも同じ状況を渡すことで、人間相手のように省略して発話しても操作することができます。また、騒音で音声認識が乱れてユーザーの発話を正確に書き起こしできない場合でも、表記ゆれや誤変換を吸収してLLMが意図を汲んで操作することができます。 LLMが遷移先を判断 システムプロンプトのルールに従い、context を見て遷移先を決定します。JSON形式で返答します。 { "action": "navigate", "page": "recipe", "params": { "recipeId": "recipe-001", "stepNumber": 4 } } しばしばLLMの出力をアプリケーションで扱うとき、プロンプトで「JSON形式で出力して」と指示しても、余分な説明文が付加されていたり、フォーマットが微妙に崩れていたりと出力がぶれることがあります。そこで、Amazon Bedrock の Structured outputs を利用して一貫性のあるJSON出力に強制しています。Structured outputs は、必要な形式を事前に指定してそれに一致するレスポンスを受け取ることができる機能です。 フロントエンド側でページを遷移 フロントエンド側のコードで、返ってきたJSONの action を見て処理を振り分けます。対応するページコンポーネントの再描画や、ページ遷移を実施します。 4.4 AI エージェント設計アプリケーションへの AmiVoice の組み込み 音声の認識には、アドバンスト・メディア社の提供する AmiVoice を採用しています。 マイクの起動 音声認識特化型Bluetoothマイク AmiVoice Front WT01 を介してマイクを起動します。AmiVoice Front WT01は物理ボタン付きのデバイスで、ボタンを押すと Web Bluetooth API を介してブラウザ上のアプリケーションに接続します。Web Bluetooth APIはブラウザからBluetooth機器に接続する仕組みです。 発話内容の読み取りと発話区間の自動検出 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) × 構造化データ自動記録」は、手が塞がる業務環境全般に適用可能です: インダストリー 応用例 期待効果 食品製造全般 外食チェーンのセントラルキッチン、給食センター、食品工場 在庫自動管理、HACCP 準拠記録、熟練者依存の解消 ホテル・宿泊業 ルームメイキング手順ナビ、備品在庫管理、設備点検記録 品質標準化、記録工数削減 医療・介護 手術室での手順確認、投薬チェック、バイタル記録 衛生環境維持しつつ情報アクセス、記録自動化 製造業 組立作業手順ナビ、品質検査記録、設備保全チェック 教育期間短縮、技能伝承のデータ化 物流・倉庫 ピッキング指示、検品記録、入出庫管理 ハンズフリーオペレーション、誤出荷防止 フィットネス・スポーツ トレーニング指示、フォームチェック、セッション記録 指導品質の標準化、データドリブンな改善 技術的な拡張ポイント: 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 エージェントシステムの設計を検討されている方の参考になれば幸いです。 著者について 戸塚 智哉 (Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 本田 光来 (Miku Honda) 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行っているソリューション アーキテクトです。サーバーレス領域が得意で、好きな AWS サービスは AWS Lambda です。 兼子 友里朱 (Yuria Kaneko) AWS Japanのアカウントマネージャーです。主にサービス業・SIer業界のエンタープライズ企業をご支援しています。新規案件創出数アジア太平洋地域1位（FY24 第1四半期・上半期）、生成AI案件創出金額日本1位（FY25 第4四半期）。趣味はクラシックバレエで、コンクールでは第2位を受賞しました。薬剤師免許保有。 吉田 明日香 (Asuka Yoshida) 株式会社アドバンスト・メディアのセールスマネージャーです。音声認識サービス「AmiVoice API」の提案・活用支援・協業推進を担当しています。幅広い業界においてお客様の音声データ活用や生成AI活用をご支援しています。 小出 泰久 (Yasuhisa Koide) 株式会社アドバンスト・メディアのエンジニアです。オフィスソリューションや医療機器開発のプロジェクトマネージャーとしての経験を活かし、現場視点での音声認識技術の活用に注力しています。

こんにちは。SHIFTのプロジェクトマネージャー／エンジニアの髙橋です。

NEC は 2026 年 6 月 1 日、全社員（最大 12 万人）が利用できる Claude Cowork の本番環境を Amazon Bedrock 上で稼働させました。設計着手は 5 月 18 日、要件定義から全社リリースまで 2 週間です。検討を進めていた 2026 年 5 月の時点では、この構成はまだ一般提供（GA）開始前 (*1) でした。前例の少ない構成を採用しながら、国内完結の推論・監査証跡・コスト管理を備えた環境を立ち上げています。本記事では、現場を率いた NEC 野口氏の視点と、AWS が担った役割の両面から振り返ります。 本記事は、日本電気株式会社（以下、NEC）コーポレートIT・AIイノベーション部門 AIプラットフォーム統括部 ディレクター 野口 忠則 氏と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 吉川 晃平の共著です。 はじめに（AWS 吉川） 生成 AI アシスタントの全社導入では、 「使えるようにする」ことと「統制の効いた状態で使えるようにする」ことの間に大きな隔たりがあります。データの所在、認証・認可、監査ログ、コストの可視化といった非機能要件は、利用者が数万人規模になると難易度が跳ね上がり、多くの場合は後から足すことができません。 2026 年 7 月 28 日に開催された AWS Bedrock LLM Day Japan にて、NEC の野口氏が「Anthropic 協業の舞台裏 〜 AI ネイティブ化に向けた Cowork on Bedrock 適用 〜」と題して登壇されました。私は本プロジェクトを担当するソリューションアーキテクトとして、NEC のプロジェクトチームをご支援してきました。そのセッションで語られた内容を軸に、NEC が何に挑み、どう乗り切り、Amazon Bedrock を選んで何を得たのかをお伝えします。 なお、本記事で扱う構成は、Anthropic のデスクトップアプリ Claude Desktop（Chat・Claude Cowork・Claude Code を含みます）の推論を Amazon Bedrock に向けるもので、正式名称は Claude Desktop on Amazon Bedrock です。NEC が全社展開されたのは Claude Cowork の利用であるため、本記事では通称の Claude Cowork on Amazon Bedrock を用い、機能そのものを指す場合は Claude Cowork と表記します。 ここからは、NEC の野口氏にバトンを渡します。 全社が使い始める、その日までに（NEC 野口） NEC は 2026 年 4 月 23 日に Anthropic との協業を発表し、6 月 1 日から社内での利用を開始しました（図 1）。発表から利用開始までの期間は限られており、準備に使える時間は多くありませんでした。ここからお話しするのは、5 月の連休明けから 6 月 1 日のリリースまで、展開の現場で何が起きていたかです。 図 1: 協業発表から全社利用開始、その後の展開までのタイムライン（出典: AWS 作成） Claude Cowork を社内で利用する方式は 2 つあります。Anthropic のサービスプラン Claude Enterprise を契約する方式と、Amazon Bedrock に接続する方式です。5 月中旬の時点で、私たちは社内利用に必要な技術検証を進めていました。プロキシ経由の通信など社内ネットワーク特有の課題は、どちらの方式でも共通の検討事項です。その頃、Amazon Bedrock に接続する方式についても AWS への相談を始めました。ただし 2026 年 5 月の時点では一般提供前であり、このときは「いずれ AWS 上でも構築しよう」という受け止めでした。 その 1 週間後、全社の利用開始に合わせて AWS 上にセキュアな環境を構築する方針が決まりました。期限は 6 月 1 日です。当初の想定より前倒しの判断でしたが、私たちはこれを妥当だと受け止めました。理由は 2 つあります。 1 つは、Amazon Bedrock であれば推論とデータを国内に閉じられることです。これが私たちにとって最も重い要件でした。 もう 1 つは、利用者が自分の手で作り上げていく設定を、後から移すコストです。会話履歴やメモリ、プロジェクトの設定には、方式をまたいで引き継ぐ仕組みがありません。スキルは中身がファイルなので移植そのものは可能ですが、一括で取り出す手段は用意されておらず、どれを登録し有効にしていたかという状態も引き継げません。人手での再構築が必要になります。数万人が使い始めた後にそれをやるのかと考えたとき、答えは決まっていました。利用者にとっての「使い始め」に、その後も使い続ける環境を用意しておく。それが 6 月 1 日という期限の意味でした。 2 週間で本番環境をつくるということ（NEC 野口） 方針が決まっても、それだけで現場が動くわけではありません。セキュリティ設計、動作確認、社内認証連携といった工程は、通常であれば数か月をかけるものです。大規模システムの本番構築を経験された方であれば、2 週間という期間がどれほど過酷かご想像いただけると思います。短い期間で進めることに対して、慎重な意見もありました。当然です。だからこそ、精神論ではなく段取りで通すしかないと考えました。状況を共有しながら一緒に進めるほかありません。私自身、プロジェクトマネジメント（PM）とシステムアーキテクト（SA）の経験はありますが、この部署に来てまだ 1 年。頼れる関係を一から築きながらの 2 週間でもありました。 それでも「一緒にやりましょう」と手を挙げてくれたメンバーが数名いました。この数名がいなければ、6 月 1 日はありませんでした。徹底したのは、 作業の優先順位を明確にすること 、 タスクの範囲を限定すること 、 構築状況を踏まえて次に実施すべきことを判断し共有すること です。加えて、短期間で新しい技術を扱う案件では、経営層の理解と後押しが欠かせません。組織全体が AI 活用に前向きだったことは、成功の要因の一つでした。こうして出来上がったのが図 2 の構成です。 図 2: 完成したアーキテクチャ。推論は日本国内リージョンで完結し、利用者 ID は Microsoft Entra ID で連携する（出典: AWS 作成、NEC 登壇資料に基づく） 技術面で注意したのは 2 点です。1 つは、国内完結の推論を要件としたため、海外リージョンへ推論を分散できないこと。事前に把握していたので、性能設計と負荷テストを 2 週間の中に組み込みました。もう 1 つは外部システムと接続するコネクタ部分で、これが最も工数を要しました。 最も苦労した点 — MCP サーバーの OAuth 実装差異への対応（NEC 野口） Amazon Bedrock 利用時は、管理者が MCP（Model Context Protocol）サーバーの設定を端末へ配布することで、利用者はアプリの UI からコネクタを簡単に追加できます。ところが、簡単に安定稼働させられるかというと、そうではありませんでした。接続先の SaaS ごとに MCP や OAuth の実装が細かく異なるため、接続が成立することと期待どおりに動作することは、それぞれ確認が必要でした。 2026 年 5〜6 月時点では、Claude Desktop on Amazon Bedrock が対応する方式と接続先の実装との間に複数の差異がありました。DCR（Dynamic Client Registration）による OAuth クライアントの動的登録に対応していない接続先では事前の手動登録が必要になり、クライアント認証方式にも違いがありました。そこで NEC は、 これらの差を吸収する認可中継サーバーを独自に設計・構築 しました。このサーバーは 7 月 18 日に社内リリースし、接続可能なサービスを順次広げています。 リリース 1 週間前に判明した認可動作の差異 最初の 1 週間が過ぎた 5 月 22 日金曜の夜、メンバーから、想定と異なる挙動があるという報告が入りました。自社だけでは原因の切り分けができず、その夜のうちに AWS のアカウントチームへ連絡しました。翌日の土曜から調査に入ってもらえることになりましたが、リリースまで 1 週間しかありません。正直に申し上げると、その週末は崖っぷちに立たされた気分で、6 月 1 日のリリースは無理だと思っていました。 それが、日曜の夕方には問題の所在が判明します。AWS の担当チームが全力で入ってくれたおかげでした。原因は、OAuth クライアントの登録と認可フローの動作が私たちの理解と異なっていたことでした。公開情報だけでは判断が難しい部分があり、AWS のエンジニアと一緒に実機で確認して初めて整理できた内容です。 もっとも、分かったのは「なぜ動かないのか」であって、そこから 6 月 1 日までの対応は決して楽ではありませんでした。新しい領域の技術を早い段階で採用するうえでは起こり得ることですが、リリース前に把握できたことは大きかったと考えています。 プロジェクトの目的と体制（NEC 野口） プレスリリースでは「Claude を利用する AI ネイティブエンジニア体制」として発表しましたが、Claude Cowork は全員が業務で使うため、最大 12 万人規模で使える環境を構築しました。目的は単なる AI ツールの導入ではなく、大きく 2 つあります。1 つは 独自構築 で、コアとなる要件まで自ら設計・構築し、環境のコントロールを自社で握ることです。もう 1 つは Client Zero 、つまり自社を最初の顧客として実践し、日本企業共通の課題に対する先駆的なリファレンスを確立することです。 体制は、NEC の 統括チーム （中央官庁の大規模 SI でのプロジェクトマネージャー・システムアーキテクト 経験者）と 社内 SE チーム （社内 IT ・インフラシステムエンジニア）、そして本プロジェクトのために AWS 側で編成した AWS チーム という、3 つの専門性を持ち寄る編成としました（図 3）。これが短納期での実現につながったと考えています。 図 3: 要件定義・設計/構築・テスト・運用を 2 週間に凝縮したスケジュール（出典: NEC 登壇資料） Claude Cowork on Amazon Bedrock の適用価値（NEC 野口） Claude を Amazon Bedrock 経由で利用する以外の選択肢もありましたが、要件を整理した結果、国内利用限定という私たちの要件を満たせると判断できたのは Amazon Bedrock でした。図 4 の 3 つの適用価値のうち、最も重視したのは国内データ保管です。 図 4: ①NEC 基準にカスタマイズ可能なセキュアクラウド、②データを国内に閉じた構成、③早期リリースによる先行利用とノウハウ獲得（出典: NEC 登壇資料） 機能面では、Claude Enterprise（Anthropic のサービスプラン。AWS Marketplace 経由でも調達できます）を契約する方式のほうが先に提供される機能や、Amazon Bedrock 接続では提供されない機能もあり、利用者から要望をいただくこともあります。それでも情報システム部門としては、 国内データ保管とガバナンスを最優先とする要件のため、Claude Cowork を Amazon Bedrock に接続する構成を選びました 。判断にあたっては、AWS から提供を受けた 2 つの方式の整理（図 5）を材料としています。 図 5: NEC が Amazon Bedrock 接続を選んだ理由。左は NEC が優先した要件、右は Claude Enterprise 契約で提供され利用者から要望のあった機能。NEC の要件に照らした整理であり、一般的な優劣を示すものではない（出典: AWS 作成、2026 年 7 月時点の公開情報および NEC 登壇内容に基づく） 成果と成功のポイント（NEC 野口） 綱渡りの連続でした。一つひとつの判断が結果に直結し、退路のない 2 週間でした。無事に立ち上がったと言えるようになったのは、しばらく経ってからです。6 月 1 日のリリースから 2026 年 7 月時点までの約 2 か月間、大きなトラブルなく安定稼働しています。利用者は 8 月 18 日時点で 11,000 名まで広がっています。国内完結の推論・監査証跡・コスト管理を完備し、国内大手 IT ベンダーとして先行事例をつくれたと考えています。業務効果の定量的な測定は今後の課題です。成功のポイントは 3 点です。 組織の後押しと許容 — AI 領域は技術の進化が速く、評価の段階では想定どおりに動かない場面も出てきます。経営層の理解と許容があってこそ、提供スピードは上がります。 大規模システムの PM 力 × アーキテクト力 — 重要タスクを見極め、優先順位をつけて執行し続けること。リード役は細部の完璧さより全体を前に進める判断を優先すべきです。 One Team 体制の推進 — 前例の少ない構築では、地道な検証と改善の繰り返しが必要です。ベンダーと一体で進める体制は、経営層の関与があって初めて成り立ちます。 今後は AI 基盤をさらに進化させ、エージェントの本番活用へ拡張していきます（図 6）。 図 6: 大規模・短納期での構築の成果、成功ポイント、今後の展望をまとめた登壇資料のスライド（出典: NEC 登壇資料） 同じような判断を前にされている方に、少しでも参考になればと思います。 ここからは、AWS の吉川に戻ります。 AWS の支援内容（AWS 吉川） 本プロジェクトで AWS が担った役割は 4 つです。 利用方式の提示と、ご要件に対する事実の回答。 Claude Cowork には Claude Enterprise を契約する方式と Amazon Bedrock に接続する方式があり、いずれも AWS からご利用いただけます。この 2 つの選択肢があることをお伝えしたうえで、NEC からご照会のあった観点について、Amazon Bedrock 接続での構成・運用に関する事実をお答えしました（図 5）。データレジデンシー、閉域網構成、キャパシティ、AI ガードレール、マルチモデル対応、各種のセキュリティ・コンプライアンス認証、MDM による環境設定の大規模展開、MCP サーバーの設定や Agent Skills の利用者への展開などです。Amazon Bedrock 接続では利用できない機能とその代替手段もお伝えしています。両方式の機能差分は Anthropic の公式ドキュメント に一覧が公開されています。要件の定義と優先順位付け、方式の選択はいずれも NEC のご判断です。 国内完結の推論構成の設計支援。 日本国内のリージョン間で推論を完結させるクロスリージョン推論プロファイル（cross-Region inference profile。推論プロファイル ID が jp. で始まるもの。以下、JP-CRIS）を用いた構成をご提案しました。プロンプトと応答は国内にとどまり、リージョン間通信も AWS のプライベートネットワーク内で完結します。認証は Microsoft Entra ID による利用者 ID 連携とし、AWS Identity and Access Management (IAM) による認可など AWS のセキュリティ機能と一体で運用する設計としています。 大規模キャパシティの設計と実測検証。 国内完結の推論を要件とすると、利用できる推論プロファイルが国内に限られ、モデルごとの TPM（Tokens Per Minute）クォータが実効的な上限になります。野口氏が挙げられた「海外リージョンへ推論を分散できない」という制約はこの点を指します。モデル別のクォータ設計とパイロット実測に基づく容量計画をご支援し、リリース後も使用率を継続モニタリングしています。2026 年 7 月時点では、いずれのモデルも上限に十分な余裕があり、スロットリングは発生していません。 週末を含む切り分けの伴走。 5 月 22 日金曜夜のご連絡を受け、本件では土曜の朝からアカウントマネージャーとソリューションアーキテクトでチームを組み、日曜の夕方までに切り分けを完了しました。前例の少ない構成をご採用いただくことは、お客様だけにリスクを負っていただくことではありません。ここは AWS が前に出るべき場面だと考えています。 おわりに（AWS 吉川） 本事例の示唆は技術選定に留まりません。後から足せない要件は何か、後から移すと人手のかかるものは何かを見極め、「使い始めの日」から逆算する。そしてその判断を実行に移せる体制と経営の後押しを確保する。NEC が 2 週間でやり切られたのは、この順序を間違えなかったからだと感じています。 本記事で述べた Claude Desktop の Amazon Bedrock 経由での利用は、 2026 年 7 月 9 日に一般提供が開始されています 。Claude Desktop の機能追加も続いており、例えば 2026 年 6 月 30 日のアップデート では、Amazon Bedrock 接続の構成でも プラグインマーケットプレイス （ベータ）が使えるようになりました。社内の Git リポジトリを配布元として指定し、任意の導入・自動導入・必須指定の 3 段階で配布を統制できます。 NEC でも、こうした機能の追加を踏まえ、統制と利用者の利便性を両立させるスキル配布のあり方について、継続して検討を進められています。一般提供の開始前に始まった取り組みは、早期のリリースを実現した後も社内サービスの改善として続いており、AWS も新機能の評価や運用設計の面で継続して支援しています。 Amazon Bedrock は、Claude をはじめ複数ベンダーの基盤モデルを AWS のセキュリティ・ガバナンス機能と一体で運用できる AWS サービスです。閉域網、ガードレール、監査ログ、支出管理といった運用設計は、将来別の AI エージェントを導入する際にもほぼそのまま再利用できます。NEC が次に注力されるテーマについても、引き続きご一緒していきます。 Claude と Amazon Bedrock のエンタープライズ活用にご関心のある方は、 Amazon Bedrock をご覧いただくか、担当のアカウントチームまでお問い合わせください。 日本電気株式会社について NECは、125年以上の歴史を有する、AIやサイバーセキュリティ、通信などの技術を強みとするグローバルテクノロジー企業です。社会と産業のAIトランスフォーメーションを推進するITサービス事業と、日本をはじめ世界の安全保障に貢献する社会インフラ事業を展開しています。業種横断の先進的な知見と最先端技術を結集し体系化した価値創造モデル「BluStellar(ブルーステラ)」を中核に、世界に革新と安心を届け、誰もが人間性を十分に発揮できる社会の実現を目指します。 著者について 野口 忠則 — 日本電気株式会社 コーポレートIT・AIイノベーション部門 AIプラットフォーム統括部 ディレクター。1999 年 NEC 入社。IP-PBX の開発を経て、19 年間にわたり中央官庁向け SI のプロジェクトマネジメントとシステムアーキテクトを担当（2016 年システム部長）。2025 年より社内 IT の AI 業務変革に従事。 吉川 晃平 — ソフトウェア開発者およびシステムインテグレーターとして 20 年以上従事した後、2020 年から AWS Japan でソリューションアーキテクトとして活動中。日本の多くの製造業や SI 事業のお客様の AWS 活用を支援してきた。最近は AI 開発エージェントを用いた製品開発ライフサイクルの加速に取り組んでおり、お客様との会話のネタが尽きない毎日を送っている。 (*1) : Claude Desktop の推論を Amazon Bedrock などの外部の推論基盤に向ける構成（Claude Desktop on third-party）は、2026 年 7 月 9 日に一般提供が開始されました。詳細は Anthropic の公式ドキュメント Claude Desktop on third-party (3P) の概要 を参照してください。