NVIDIA NIM と NVIDIA Blueprints で実現する日本語対応対話型エージェントの迅速な構築

顧客との接点が増加する中で、企業は「効率的かつ自然な対話をいかに実現するか」という課題に直面しています。

問い合わせ対応やオンライン手続きの支援、社内外のユーザーへの情報提供など、求められる体験は年々多様化しており、従来の単純な FAQ やチャットボットでは対応が難しくなってきています。従来のシステムは、複雑なフローや膨大なナレッジベースを前提に設計されていることが多く、操作性や情報構造が複雑で、ユーザーにとって使いにくいケースも少なくありません。その結果、サービスの利用離脱や顧客満足度の低下といったリスクが高まっており、より自然で直感的な対話型 UX の実現が強く求められています。

こうした課題を解決する手段として注目されているのが、生成 AI、対話型 AI、ビジュアル AI、デジタル ヒューマンなどの統合のエージェント型 AIです。自然な会話でユーザーを案内し、検索拡張生成 (RAG: Retrieval-Augmented Generation) によって正確な情報に裏付けられた回答を返すことが可能になります。さらに音声、ビジュアル要素を組み合わせることで、より直感的で人間らしい体験を提供できます。

本記事では、NVIDIA NIM マイクロサービスと NVIDIA Blueprints を活用し、日本語環境に対応したBlueprintsのカスタマイズを行うための実践的な手順を紹介します。 NVIDIA NIM は、クラウドからオンプレミスまで幅広い環境に柔軟に展開可能で、企業が独自の対話型アプリケーションを構築と拡張するための基盤となります。

なぜ Pipeline のカスタマイズが必要か

NVIDIA NIM と Blueprints を用いた対話型アプリケーションは、複数の NIM が連携して動作します。音声入力から会話生成、音声出力までを一連のフローとして統合することで、リアルタイムな応答を実現しています。

しかし実際の導入現場では、業務や利用地域に応じた最適化が求められる場面が多くあります。特に日本語の環境では、デフォルト構成のままでは次のような課題が生じがちです。

• 音声認識 (ASR: Automatic Speech Recognition) の精度不足
  英語に最適化されたモデルでは、日本語特有の発音や文法への対応が不十分で誤認識が増える。
• 音声合成 (TTS: Text-to-Speech) の不自然さ
  日本語特有のイントネーションやリズムが表現できず、ユーザー体験が損なわれる。
• 会話応答の自然さと正確性 (LLM、RAG)
  LLM が英語ベースのままだと直訳調になりやすく、日本語ユーザーに違和感を与える。また、業務固有の情報を扱うには日本語の知識データを組み込んだ RAG 連携が不可欠。

こうした課題を解決するには、Tokkio NVIDIA AI Blueprint の Pipeline を拡張と差し替えることが有効です。具体的には、音声認識 / 音声合成 / 知識検索といったコンポーネントを、外部の日本語対応サービスやカスタム モデルと統合し、既存のアーキテクチャ上でシームレスに動作させるといった手順になります。

このような Pipeline のカスタマイズにより、既存アプリケーションを大きく作り直すことなく、ユーザーに最適化された体験を短期間で提供できます。クラウド と オンプレミスを問わず柔軟にこうした拡張を行えることが、NIM マイクロサービスの強みです。

Blueprint カスタマイズの全体像

今回は Tokkio NVIDIA AI Blueprint を基盤として使用しています。基本構成のままでも素早く動作を確認できます。日本語対応や特定業務への最適化を行う際は、この Pipeline の一部を差し替えることで対応可能です。基盤となるアーキテクチャを変更せず、必要な部分だけを拡張と再構成できる点が NVIDIA の Blueprints の大きな特徴です。

前提条件および対象ユーザー

本記事の手順は、すでに Tokkio の基本デプロイメントを完了し、より高度な日本語対応や外部 API 連携を検討している技術者を対象としています。

• Tokkio 5.0.0-GA の標準サーバー デプロイメントが完了していること、ならびに当該 Blueprints に関連する専門用語や技術的内容を理解していること
• サード パーティのストリーミング API サービスの置き換え、デプロイを検討していること
• (推奨) 標準構成の ASR (NVIDIA Riva) および TTS (例: ElevenLabs) を日本語化してデプロイ テストを完了していること

Tokkio は、内部的に pipecat フレームワークを基盤として構築されています。そのため、ASR / TTS / LLM + RAG といった各モジュールの入れ替えや拡張を、開発者自身が柔軟に行うことができます。詳細な実装構成は GitHub: NVIDIA/ace-controller に公開されており、カスタマイズを行う際の参考になります。

例として、標準構成で Tokkio をデプロイすると、すべての Kubernetes Pod が `Running` 状態になります。

# Tokkio 5.0.0-GAが正常に動作しているKubernetesステータスの一例
kubectl get pods -n app

NAME                                                      READY   STATUS
a2f-a2f-deployment-5846b7798f-zs8nj                       1/1     Running
ace-configurator-deployment-85dd955bd8-xlfpq              1/1     Running
ace-controller-ace-controller-deployment-0                1/1     Running
ace-controller-sdr-envoy-sdr-deployment-b7fc9cdd7-7qz7w   4/4     Running
anim-graph-sdr-envoy-sdr-deployment-66565d964d-ckk6n      4/4     Running
ia-animation-graph-microservice-deployment-0              1/1     Running
ia-unreal-renderer-microservice-deployment-0              3/3     Running
redis-timeseries-7dd64d6dc5-94gt2                         1/1     Running
riva-speech-6d9d5b7d4f-zqtx8                              1/1     Running
tokkio-ingress-68d95ccbc6-4jn5s                           2/2     Running
tokkio-ui-54895fd949-qms2l                                1/1     Running
triton0-5f949b6b79-f69kd                                  1/1     Running
ue-renderer-sdr-envoy-sdr-deployment-94cdbfc95-jdpmx      4/4     Running
vms-vms-5b45f6549b-x6jlj                                  1/1     Running

日本語化のカスタマイズを行う場合は、”ace-controller-ace-controller-deployment” Pod における ASR, TTS, LLM, RAG サービスの置き換えと再デプロイが必要です。

また、ASR/TTS をサード パーティのストリーミング API に置き換える場合、該当サービスが必要とする依存ライブラリを Pod 内に組み込む必要があります。

しかし、標準の Tokkio Pipeline が使用するベース Docker イメージには、これらのライブラリが含まれていないため、以下の対応が必要となります。

• 必要ライブラリを含む新しい Docker イメージのビルドと公開
• 関連する Pipeline 設定の更新と再デプロイ

具体的な手順は後述します。

Pipeline の構成イメージ

今回の Tokkio NVIDIA AI Blueprint 日本語化に関して、構成は次のようになります:

[ ASR ] → [ LLM / RAG ] → [ TTS ] → [ Renderer / UI ]

• ASR (Automatic Speech Recognition): 音声をテキストに変換
• LLM / RAG (Large Language Model / Retrieval-Augmented Generation): 文脈理解、応答生成
• TTS (Text-to-Speech): 応答を音声化して出力
• Renderer / UI: デジタル ヒューマン アバターやインターフェイスでの表示

この中で日本語対応が必要になるのは、主に ASR / TTS / LLM+RAG の 3 コンポーネントです。それぞれを外部 API やカスタム モデルに置き換えることで、日本語特有の発音 / 文体 / 文脈に最適化された体験を実現できます。

カスタマイズの基本ステップ と 対象の変更箇所

• Part I, 外部 API を使うためのカスタム イメージ作成
  • 「目的」: サード パーティ サービスに必要な依存ライブラリを含むカスタム Docker イメージを作成。
  • これにより、ローカル環境で動作する API サービス、または外部の日本語 ASR/TTS API と通信可能になる。
• Part II, Pipeline 設定の更新と再デプロイ
  • 「目的」: 既存設定を新しいカスタム イメージに置き換え、再デプロイを実施
  • Helm 設定を編集し、新しいイメージを参照するように変更。Terraform スクリプトを用いて Pipeline を再デプロイ。
• Part III, VS Code の「ace-configurator」Bot 設定をユース ケースに合わせて調整
  • 「目的」: 呼び出し時の設定を変更 (例: デフォルト ASR を Riva から外部 API サービスへ切り替え)
  • ace-configuer 内の config.yaml や bot.py 内で、ASR/TTS/LLM の設定を更新。音声や応答の挙動を、利用シーンに合わせてチューニング。

Part I, 外部 API を使うためのカスタム イメージ作成

Tokkio NVIDIA AI Blueprint の Pipeline に外部の日本語対応 API (例: ASR/TTS サービス) を組み込むには、該当サービスが要求する依存ライブラリを ace-controller に追加する必要があります。しかし、標準の Tokkio イメージにはこれらの依存関係が含まれていません。そのため、本節では 外部 API に対応したカスタム Docker イメージを作成する 方法を紹介します。

そして、この Blueprint の ace-controller は、pipecat を中核としたエージェント制御サービスです。すべての対話フロー (ASR → LLM → TTS) を管理しており、外部 API を組み込む際はこのサービスのソース コードを拡張する形で実装します。

作業ディレクトリの例:

# 作業ディレクトリへ移動
cd /home/nvidia-ace/ACE/workflows/tokkio/5.0.0-ga/src/llm-rag

# 作業用ディレクトリの構成を確認
tree -L 1

llm-rag/
├── Dockerfile                      # 変更される予定
├── LICENSE
├── ace-controller                  # 変更される予定
│   ├── pyproject.toml              # 変更される予定
│   ├── uv.lock                     # 変更される予定
│   ├── ...
├── configs
├── entrypoint.sh
├── nano.166227.save
├── pyproject.toml                  # 変更される予定
├── src
├── third_party_oss_license.txt
└── uv.lock                         # 変更される予定

このディレクトリ内で ace-controller のソースを取得と編集し、新しい Docker イメージとしてビルドします。

手順概要

Step 1：ソースの取得

まず、公式の ace-controller リポジトリを取得します。Tokkio の “llm-rag” ディレクトリに配置し、ここからビルド時に参照されます。

git clone https://github.com/NVIDIA/ace-controller.git

説明: 本ステープでは、`llm-rag` フォルダー内の `Dockerfile` は `ace-controller` をベースにカスタマイズされたビルド定義を持っています。そのため、まず NVIDIA 提供の `ace-controller` を git clone し、必要なライブラリ追加等の編集を行います。

Step 2：依存ライブラリの追加

外部 API 用の依存ライブラリを追加します。例として、”3rd-party-ASR” (ダミー) 外部音声認識 API を使用する場合。`ace-controller` ディレクトリへ移動し、ASR に必要なライブラリを追加します。

cd ace-controller

# ダミーの外部API依存ライブラリを追加
uv add "git+https://github.com/<your_3rd_party_asr_dep_lib>/pipecat.git@feature/asr#egg=pipecat-ai[Trd-party-ASR]"

# ライブラリの依存関係を同期
uv sync
# .venv は不要なため削除
rm -rf .venv

上記の pipecat パッケージは Tokkio の基盤と互換性があり、独自の API 呼び出しクラスを追加するのに利用できます。

Step 3: `llm-rag` の中の Dockerfile ビルド設定確認と pyproject.toml の修正

# Tokkio の llm-rag ディレクトリに戻り、ローカルソースを使用するよう設定します
cd ..

# pyproject.tomlの中で設定を確認、また変更
vi pyproject.toml

########### pyproject.toml ###########
# NOW we are viewing /home/nvidia-ace/ACE/workflows/tokkio/5.0.0-ga/src/llm-rag/pyproject.toml

...
# これにより、PyPI 配布版ではなく、編集したローカル版 ace-controller が利用されます。
# Uncomment this to use local ACE Controller source instead of pypi released nvidia-pipecat wheel
nvidia-pipecat = { path = "./ace-controller", editable = true }
######################################

# 必要な依存をすべて同期します
uv sync

Step 4: Dockerfile の確認と修正

# Dockerfile にローカルソースを反映するよう追記します
vi Dockerfile

# 以下の行を追加し、`ace-controller` フォルダを新しい作った Docker イメージに含めるようにします
############ Dockerfile ##############
# NOW we are viewing  /home/nvidia-ace/ACE/workflows/tokkio/5.0.0-ga/src/llm-rag/Dockerfile

...
# Copy dependency files
COPY --chown=1000:1000 LICENSE third_party_oss_license.txt pyproject.toml uv.lock ./
COPY --chown=1000:1000 ace-controller ./ace-controller
...
######################################

Step 5: Docker イメージのビルドとプッシュ

# まず、古いキャッシュを削除して環境をクリーンにします
docker system prune

# Docker imageビルドを開始します
docker build --no-cache -t ace-controller:5.0.0-jp .

# 完了後、作成したイメージを NGC または 自社のimageレジストリにプッシュします
docker tag ace-controller:5.0.0-jp nvcr.io/<your-org>/ace-controller:5.0.0-jp
# 「注意」：上記の `nvcr.io/<your-org>/...` は NVIDIA 社内用の例です。実際には、自身の NGC レジストリや DockerHub などの適切なリポジトリ名に変更してください

# 最後に、作成したイメージをリポジトリへプッシュ
docker push nvcr.io/<your-org>/ace-controller:5.0.0-jp

ポイントとベスト プラクティス

• 依存関係の追加は慎重に: 外部ライブラリのバージョンが Tokkio 標準の Python 環境 (uv ベース) と競合しないよう注意。
• ビルド キャッシュを無効化: --no-cache オプションで古いイメージを引きずらないようにする。
• 再現性の確保: uv.lock を更新、コミットしておくと、チーム間での環境差異を防止できる。

成果として、外部 API に対応したカスタム ace-controller イメージが完成します。このイメージを使うことで、NIM Pipeline 内から日本語 ASR/TTS などの外部サービスを直接呼び出せるようになります。

Part II: Pipeline 設定の更新と再デプロイ

前章で作成したカスタム ace-controller イメージを実際の Blueprint Pipeline に反映させるには、Helm 設定ファイルを更新し、再デプロイを行う必要があります。Tokkio NVIDIA AI Blueprint  のデプロイメントは Helm チャートを中心に構成されており、コンポーネント単位でイメージや環境設定を上書きできる柔軟な仕組みを採用しています。この章では、その仕組みを活かして既存の Pipeline に新しいイメージを適用します。

手順概要

Step 1: 作業ディレクトリの確認

再デプロイに使用するスクリプト群は以下のパスに格納されています。

cd /home/nvidia-ace/ACE/workflows/tokkio/5.0.0-ga/scripts/one-click

# 以下は、この作業に関連するディレクトリ構成
tree

├── aws
├── azure
├── baremetal
│   ├── .env.jp                     # 環境変数設定ファイル
│   ├── my-config-template.yaml     # Pipeline 用 Helm 設定テンプレート
│   ├── envbuild.sh
│   └── …
├── gcp
└── tokkio-1stream-with-ui          # ローカル展開される Helm チャート
    ├── Chart.lock
    ├── Chart.yaml
    ├── charts
    ├── tokkio-app
    │   ├── chart
    │   │   ├── values.yaml         # Docker イメージ指定の更新対象
    │   │   └── …
    └── values.yaml

この中の baremetal/ ディレクトリには、環境変数設定ファイル (.env) と Helm 設定テンプレート (my-config-template.yaml) が含まれています。

Step 2：Helm 設定の更新

カスタム イメージを参照するように Helm の values.yaml を編集します。

cd ./tokkio-1stream-with-ui/charts/tokkio-app
vi values.yaml

該当する ace-controller セクションを以下のように変更します:

## values.yaml
...
ace-controller:
  DEV: '1'
  OTEL_EXPORTER_OTLP_ENDPOINT: http://obs-opentelemetry-collector.platform.svc.cluster.local:4317
  applicationSpecs:
    ace-controller-deployment:
      containers:
        ace-controller-container:
          env:
          ...
          # FROM HERE
          - name: IMAGE_NAME
            value: nvcr.io/<your-org>/ace-controller
          - name: IMAGE_TAG
            value: 5.0.0-jp
          image:
            repository: nvcr.io/<your-org>/ace-controller
            tag: 5.0.0-jp
          # END
  imagePullSecrets:
  - name: ngc-docker-reg-secret
...

ポイント:

• repository と tag は自分のレジストリ名に置き換える。
• imagePullSecrets にはレジストリ アクセス用の secret を指定する

Step 3: Helm ローカル設定を有効化

my-config-template.yaml を開き、ローカル チャート参照を有効にします。

cd /home/nvidia-ace/ACE/workflows/tokkio/5.0.0-ga/scripts/one-click/baremetal
vi my-config-template.yaml

以下のように `helm_chart.local` を有効に設定 (パスはご自身の環境に応じて読み替えてください)

##
  ...
  app:
    configs:
      app_settings:
        helm_chart:
          local:
            enable: true
            path: /home/nvidia-ace/ACE/workflows/tokkio/5.0.0-ga/scripts/one-click/tokkio-1stream-with-ui
  #       repo:
  #         chart_name: 'tokkio-1stream-with-ui'
  ...

これにより、外部リポジトリではなくローカルの Helm チャートを使用してデプロイされます。

Step 4: 再デプロイの実行

設定を反映したら、既存のアプリケーションをアンインストールし、新構成で再デプロイします。

cd /home/nvidia-ace/ACE/workflows/tokkio/5.0.0-ga/scripts/one-click/baremetal
source .env

# 既存アプリケーションのアンインストール（約10分）
./envbuild.sh uninstall --tf-binary terraform --component app --config-file ./my-config-template.yaml

# 新しい構成でインストール（約20分）
./envbuild.sh install --tf-binary terraform --component app --config-file ./my-config-template.yaml

再デプロイ後は Pod が順次再起動します。完了までに 20 〜 30 分ほどかかります。

Step 5: (任意) デプロイ状況の確認

デプロイ完了後、Pod の状態を確認します。Application Instance 内で Pod の起動ステータスをリアルタイムで監視するには、以下を実行できます。

kubectl get pods -n app -w

# ace-controller Pod がカスタムイメージで立ち上がっていれば成功です
NAME                                           READY   STATUS
ace-controller-ace-controller-deployment-0     1/1     Running

ベスト プラクティス

• Helm と Terraform の整合性を保つ: 複数人で作業する場合、my-config-template.yaml のバージョンを Git 管理をおすすめします。
• 再デプロイ前に Pod の状態を確認: 古い Pod が残っていると衝突する可能性があります。
• 環境変数 .env の再利用: 環境依存パラメーターは .env から統一的に読み込みます。

Part III: Bot 設定をユース ケースに合わせて調整

カスタム イメージと Pipeline の再デプロイが完了したら、最後は NIM マイクロサービス Bot 側の設定を自分のユース ケースに合わせて調整します。Tokkio NVIDIA AI Blueprint  の Bot 設定は VS Code の「ace-configurator」プラグインから編集でき、ASR / TTS / LLM / RAG などの動作を yaml で柔軟に変更できます。本章では、どの部分を変更すれば外部 API が有効になるのかを簡潔に説明します。

設定の流れ

1. VS Code でプロジェクト作成
   • 「ace-configurator」プラグインを起動し、接続先 Tokkio サーバー IPを指定して新規プロジェクトを作成します。
   • プラグイン上で、サーバー側の設定を Download All してローカルに同期します。
2. 設定ファイルの場所
   • ダウンロードされた設定の中で、主に以下の 2 ファイルを編集します:

└── configs
    └── config.yaml    # 会話フロー、LLM、RAG 設定
└── src
    └── bot.py         # ASR/TTS/LLS/RAGなど外部サービスのpipecatでの呼び出し定義

設定ファイルの編集例

「ace-configurator」プラグインを使えば、複数の NIM Pod に対して設定を行い、リアルタイムでデプロイすることができます。ここでは、日本語化対応に必要な ASR/TTS および LLM/RAG に関する設定部分のみを参考としてご紹介します。

そして、外部の日本語 ASR/TTS API を組み込む場合は、以下のようにコードを bot.py 追加また変更できます。例として、ダミーの ASR サービス API をどのように追加するかを示します。

from pipecat.services.Trd-party-ASR.stt import TrdPartyASRService

stt = TrdPartyASRService(
    server="api.example-asr.jp",
    api_key="your_api_key_here",
    language="ja",
    silence_seconds=1.0,
)

TTS を別の外部サービスに変更する場合も同様に、TTSService 部分を差し替えることで対応できます。

基本方針:

• Tokkio NVIDIA AI Blueprint の Bot は Python ベースで拡張可能。
• 外部 API のクラスを import → サービス インスタンスに置き換えるだけで組み込み可能。

カスタマイズと日本語化調整の考え方

NIMとBluerpints設定の内容は、業種やユースケースによって最適解が異なります。たとえば以下のようなカスタマイズが可能です:

これらの部分は独立しており、必要な部分だけ段階的に変更することが可能です。たとえば「ASR だけ日本語化」「TTS だけ自然音声に置き換え」といった段階的な導入も現実的です。

NIM ベースの構成を維持したまま、特定部分をカスタマイズできることで、開発チームはアプリケーション全体を停止させずに改善を進めることができます。これこそが、マイクロサービス アーキテクチャと NIM の柔軟性がもたらす大きな利点です。

まとめ

本記事では、Tokkio NVIDIA AI Blueprint をベースにした日本語対応 Pipeline の構築手順を紹介しました。外部 API と統合するためのカスタム イメージの作成、Helm 設定を用いた再デプロイ、そしてユース ケースに応じた Bot 設定の調整という 3 つのステップを通じて、NIM と Blueprint の柔軟な拡張性を実際に確認しました。

これらのアプローチは、日本語対応だけでなく、各業界やアプリケーション要件に合わせて最適な AI エージェントを構築する際にも活用できます。NVIDIA は今後も、NIM と Blueprints 群を通じて、開発者がより自然で直感的なインテリジェント アプリケーションを構築できるよう支援していきます。

関連情報

• 技術ブログ: NVIDIA NIM Agent Blueprint で AI アプリ向けのデジタル ヒューマン インターフェイスを構築する
• SDK: NVIDIA Tokkio Agent Blueprint