この記事は、自社開発アプリ 「お喋りAIずんだもん」 の技術事例です。受託案件の情報は含みません。

LLM（ChatGPTなどの大規模言語モデル）を使ったアプリ開発で、私たちが最も重視しているのは、「AIに任せる処理」と「自前で実装する処理」を、機能ごとに切り分けることです。

「お喋りAIずんだもん」では、役割を次のように分けました。

  • 会話の“中身”を考える：ChatGPT（LLM）に任せる
  • キャラクターの“口調”を再現する：自社実装（形態素解析＋ルール）で確実に処理する

この一手で、次の3つを同時に狙える設計にしています。

  • キャラの口調ブレを、AIの揺らぎに任せない
  • 口調変換ぶんのAPI料金をゼロにする
  • 変換を端末内でミリ秒単位に処理し、待ち時間を増やさない

以下、設計の判断ポイントを技術的に解説します。

📝 この記事の要点
① LLMアプリでは、「AIに全部任せる」ほど品質とコストが不安定になります。
② お喋りAIずんだもんでは、ChatGPTは会話内容、自社エンジンは口調・音声・表情を担当します。
③ 確率的でよい処理と、決定論的であるべき処理を分けることが、LLMアプリ設計の肝です。

課題：「LLMにキャラを演じさせる」が、なぜ本番で破綻するのか

対話アプリを作るとき、最も安直な実装はシステムプロンプトでこう指示することです。

あなたはずんだもんです。
語尾は必ず「〜なのだ」にして、楽しく会話してください。

プロトタイプなら、これで十分動きます。しかし製品化を見据えると、3つの問題が出ました。

一貫性の欠如

出力が長くなる、会話が続く、話題が複雑になる。こうした条件が重なると、LLMは指示した語尾を“忘れ”ます。

「〜なのだ」が「〜だよ」「〜です」に揺れる。キャラクターアプリにとって、この口調ブレは致命傷です。

トークン（コスト）の常時上乗せ

「キャラを演じてね」というキャラ指定は、毎リクエストのシステムプロンプトに乗り続けます。

会話のたびに、本質ではない指示文へ課金し続けることになります。

品質がモデル任せになる

キャラの再現度が、モデルの状態やバージョンに依存します。

モデルを差し替えた瞬間に口調の癖が変わる、というのは運用上のリスクです。

つまり「口調の維持」は、LLMが構造的に苦手で、かつ毎回コストがかかる割に、仕様としては決定的であるべき処理です。

ここをAIに委ねるのは、設計判断として筋が悪いと考えました。

設計：処理を「考える」と「演じる」に分解する

そこで、対話のパイプラインを次のように分割しました。

[ユーザー入力]
     │
     ▼
[ ① ChatGPT（LLM）]
     │   会話の“中身”だけを生成。口調はあえて普通のタメ口
     │   出力例：「それは楽しそうだね。ボクもやってみたいな」
     ▼
[ ② 口調変換エンジン（自社実装）]
     │   形態素解析＋ルールで語尾を確実に変換
     │   変換例：「それは楽しそうなのだ。ボクもやってみたいのだ」
     ▼
[ ③ VOICEVOX ]
     │   一文ずつ音声合成
     ▼
[ ④ 表情制御 ]
     │   感情ワードを検出して笑顔／悲しい顔を切替
     ▼
[ ずんだもんが喋る ]

ポイントは、①の段階でLLMにキャラを演じさせないことです。

システムプロンプトでは「性格（楽観的）」「一人称（ボク）」「タメ口」「相手の呼び方」といった、会話の中身に関わる人格設定だけを渡します。

一方で、“なのだ”という語尾そのものはLLMに要求しません。語尾は、後段の自社エンジンが決定論的に付与します。

口調変換エンジンの中身

「ずんだもん語尾」への変換は、AIではなく 日本語の形態素解析＋独自ルール で実装しています。

端末内に辞書（IPADIC）を同梱し、オフラインの解析エンジン（NMeCab）で処理するため、APIコストはかからず、通信待ちもありません。

処理の流れはこうです。

1. 文を区切る

返答テキストを句読点・感嘆符・疑問符・改行（、。！？」など）で分割します。

一文ずつ独立して変換し、後段の音声合成も文単位で行うことで、テンポよく読み上げられます。

2. 文末の種類で分岐する

文末の記号を見て、平叙・疑問・感嘆を判定します。

  • 疑問（？）なら「疑問用の語尾辞書」を優先的に適用
  • 感嘆（！）なら語尾に「なのだ」を付与
  • 読点（、）止まりの節は変換せずそのまま

読点止まりを変換しないのは、途中の節を不自然にしないためです。

3. 特殊ケース辞書を優先マッチする

「機械的に変換すると不自然になる言い回し」は、あらかじめ手で対応表を作っています。

LLMの出力（語尾）変換後
〜だね〜なのだ
〜たいな〜たいのだ
〜なんだよ〜なのだ
〜じゃないかな〜だろうなのだ
笑ふふふっ

平叙用・疑問用でそれぞれ辞書を持ち、長い言い回しから順にマッチさせることで誤変換を防いでいます。

4. 辞書に無ければ品詞で判定する

特殊ケースに当たらない文は、形態素解析で文末の品詞を見ます。

  • 文末が動詞・形容詞：文脈に合わせて「なのだ」系の語尾を付与
  • 文末が名詞：平叙なら「のだ」、疑問なら「なのだ」を付与

この 「辞書（例外）＋品詞ルール（一般）」 の二段構えにより、未知の文でも破綻しにくく、キャラクターの語尾に変換できます。

要するに、「どんな入力でも“ずんだもんらしい語尾に寄せる”という仕様を、確率的なAIではなく、決定論的なプログラムで担保している」わけです。

だから崩れにくい。ここが重要です。

コスト設計：LLMアプリを「運用し続ける」ための仕込み

LLMアプリは、作るより運用し続けるほうが難しいです。

ユーザーが使うほどAPI課金が発生するため、設計段階でコストを織り込みました。

出力トークンの上限設定（max_tokens）

返答が無限に長くならないよう上限を設定し、1リクエストあたりの最大コストを予測可能にしました。

会話履歴の圧縮

過去ログを全部送ると、プロンプトが肥大して課金がふくらみます。

直近の文脈だけを保持する設計にして、自然な会話を保ちながら入力トークンを抑制しました。

キャラ表現をLLMから外す

口調・声・表情は自社側で処理します。

LLMに払うのは「考える」ぶんだけにしています。

モデル選定

雑談用途では過剰に高価なモデルを使わず、コスト効率の良いモデルを選択します。

品質要件と単価のバランスを取ることが、継続運用では重要です。

使用量に応じたクレジット制

消費トークン量に重みをつけてアプリ内クレジットを消費する仕組みにし、コストとユーザー体験を連動させています。

私たちは見積もりの段階から、開発費だけでなくランニングコスト（API・サーバ）まで含めて設計します。

「作れる」と「続けられる」は別の問題だからです。

声と表情：“軽い仕組み”で“それっぽさ”を出す

LLMに任せるべきではない処理は、口調だけではありません。

声と表情も、体験としては重要ですが、すべてをAIに投げる必要はありません。

音声合成（VOICEVOX）

高品質な音声合成エンジンを活用し、文単位で逐次合成・再生しています。

長文を一括処理せず小分けにすることで、話し始めまでの待ち時間を短縮しています。

表情制御

返答テキストに「残念」「悲しい」「涙」などの感情ワードが含まれるかを判定し、含まれていれば悲しい顔、そうでなければ笑顔に切り替えます。

表情判断までLLMに投げず、軽量なルールで十分な体験を実現しています。

ここでも設計思想は一貫しています。

手間とコストをかける所と、軽い仕組みで足りる所を見極める。これが限られた予算で“ちゃんと動く”製品を作るコツです。

設計から得られた学び

性質担当理由
発想・対話・要約など、曖昧でよい処理LLM確率的でも価値が出る。AIの主戦場
一貫性・正確性・低コストなど、決定的であるべき処理自前実装揺らぎを許さない／毎回課金したくない

LLM開発でいちばん大事なのは「最新モデルを使うこと」ではなく、「AIの得意・不得意を見極めて、処理を正しく分割すること」です。

この切り分けが、品質・コスト・スピードのバランスを決めます。

「お喋りAIずんだもん」は、この設計のおかげでユーザーから 「ちゃんとずんだもんだ」「キャラが崩れない」 という声をいただけました。

AIに全部任せていたら、まず安定しなかった部分です。

こんな開発のご相談に強いです

  • AIチャットボット／対話アプリを、品質とコストを両立させて本番化したい
  • 自社キャラクターやブランドにAIを組み込みたい
  • キャラクター性を崩さず、AI会話を安定させたい
  • すでにAIで試作したが、料金や安定性で製品化に踏み切れていない
  • AIを使ったスマホアプリ（iOS / Android）を企画からリリースまで進めたい

「うちの場合、どこをAIに任せられる？」という初期の壁打ちだけでも歓迎です。

要件が固まる前の段階から、AIをどう使うのが一番おトクで確実かをご提案します。

開発のご相談・お見積もりはこちら

株式会社Code and DESIGNでは、AIチャット、LLMアプリ、音声合成、キャラクターアプリ、スマホアプリ開発のご相談を承っています。

開発のご相談はこちら