LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリ組み込み型AIチャットボットとは何か

アプリ組み込み型AIチャットボットとは、モバイルアプリのUI内に対話型のチャット画面を設け、LLM（大規模言語モデル）APIと連携してユーザーの質問や要望にリアルタイムで応答する機能を指します。単にAPIを呼び出すだけでなく、ストリーミング表示・会話履歴管理・入力補助・エラー時の見せ方まで含めたUX（ユーザー体験）全体の設計と実装が対象です。

本記事は、LLM APIそのものの接続方法や料金体系、生成AI運用人材の確保、回答精度の評価基盤構築といったテーマは扱いません。それらは別稿で解説しています。本稿は「モバイルアプリの中にチャットUXをどう作り込むか」という実装層に絞って整理します。

総務省「令和7年版情報通信白書」によれば、個人の生成AI利用経験率は2024年度に26.7%となり、2023年度の9.1%から急増しました^*1。この伸びを背景に、自社アプリへ対話型AI機能を組み込みたいという相談が増えています。あわせて、対話型生成AIチャットボット市場は2028年度に2023年度比6.7倍の規模へ拡大すると報じられており^*2、アプリへの組み込み需要は今後も続くとみられます。

UI・バックエンド・LLM APIで構成する実装の全体像

アプリ組み込み型のAIチャットは、大きく3つの層に分けて設計します。クライアント側のチャットUI、自社が管理するバックエンド、そしてLLMベンダーのAPIです。この3層の役割を理解しておくと、後述する各実装課題の位置づけが把握しやすくなります。

クライアント側（チャットUI）

iOSはSwiftUI、AndroidはJetpack Composeを用いてチャット画面を構築するのが主流です。メッセージリストの表示・入力欄・送信ボタンに加え、生成中であることを示すインジケーターや、途中でキャンセルできる操作の実装が必要になります。

バックエンド（自社管理層）

クライアントからLLM APIへ直接リクエストを送る構成は、APIキーの露出やコスト管理の観点から推奨されません。自社バックエンドを経由させ、認証・利用量制御・ログ記録・ガードレール適用をサーバー側で一元管理する設計が実務上の標準です。

LLM API（推論エンジン）

OpenAI・Anthropic・Googleなどが提供するAPIを呼び出し、テキスト生成を行う層です。モデル選定はコスト・レイテンシ・コンテキストウィンドウ（一度に処理できる文章量）の3点で比較することが多く、複数のモデルを用途別に使い分ける設計も選択肢になります。

ストリーミング表示で体感速度を上げる実装

ストリーミング表示とは、AIの応答を一文字・一単語ずつ順次画面に表示する実装方式です。応答が完成するまで待たせる方式と比較して、ユーザーが感じる待ち時間を大きく縮められます。

SSE（Server-Sent Events）による受信

OpenAIのAPIは`stream=true`を指定するとSSE形式で応答イベントを逐次配信し、生成開始・テキスト差分・完了・エラーといった種類のイベントをクライアント側で判別しながら処理する設計になっています^*3。モバイルアプリ側では、この差分イベントを受信するたびに画面のテキストを更新する処理を実装します。

Anthropicのクロード系APIも同様にストリーミング配信に対応しており、レート制限は1分あたりのリクエスト数（RPM）・入力トークン数（ITPM）・出力トークン数（OTPM）の3種で管理される点が特徴です^*4。プロンプトキャッシュを使った再利用部分は、多くのモデルでITPMの計算対象から外れる仕組みになっており、繰り返し利用するシステムプロンプトが多いチャットボットではスループット改善に活用できます。

モバイル特有の実装留意点

モバイル回線は接続が不安定になりやすく、ストリーミング中の切断・再接続への対応が必須です。通信が途切れた場合に、それまで受信した部分的な応答を保持しつつ再試行するか、エラー表示に切り替えるかをUI設計時に決めておく必要があります。

バックグラウンド遷移時にストリーミング接続がOSによって切断される挙動も、iOS・Android双方で考慮が必要です。アプリがバックグラウンドに移行した際は、いったん接続を閉じて復帰時に応答の続きを取得し直す設計が一般的です。

会話履歴とトークン管理でコンテキストを保つ設計

会話履歴の管理とは、ユーザーとAIのやり取りをセッション単位で保持し、次の発言にも文脈を反映させる仕組みです。履歴の持ち方を誤ると、AIが前の会話を忘れたり、逆にトークン消費が膨らんでコストが増大したりします。

履歴の保存範囲

会話履歴はリクエストのたびにメッセージ配列として送信するため、履歴が長くなるほど1回あたりのトークン消費が増えます。直近の発言のみを送る・古い履歴を要約して圧縮する・重要な情報だけ抽出して保持するといった方式を組み合わせ、コンテキストウィンドウの上限内に収める設計が必要です。

端末とサーバーでの保存分担

会話履歴を端末内のみに保存する設計と、サーバー側にも保存する設計があります。複数端末での閲覧やサポート対応時の履歴参照を想定する場合はサーバー保存が必要になりますが、その分だけ個人情報保護・データ保持期間の社内規程整備が求められます。

会話内容に個人情報や機密情報が含まれる可能性がある場合は、保存前のマスキング処理や、保持期間を定めた自動削除の仕組みをあわせて設計することが望ましいです。

プロンプト設計とガードレールで誤回答・逸脱を防ぐ

ガードレールとは、AIが不適切な回答や意図しない挙動をしないよう制御する仕組みの総称です。システムプロンプト（AIの役割・制約を事前に指示する文章）の設計と、出力後のチェック処理の両方で構成します。

システムプロンプトによる制約

チャットボットの役割・回答範囲・禁止事項をシステムプロンプトに明記します。「自社サービスに関する質問以外には回答しない」「医療・法律等の専門的助言を断定的に行わない」といった制約を明示することで、脱線した回答を減らせます。

ただし、システムプロンプトだけで不適切な出力を完全に防ぐことは難しいため、後段のチェック処理と組み合わせる設計が実務上の前提になります。

出力後のコンテンツモデレーション

AIの応答をユーザーに表示する前に、不適切な語句や機微情報が含まれていないかを検査する処理を挟みます。各LLMベンダーが提供するモデレーションAPIを利用する手段と、自社でキーワードベースのフィルタを組む方法があり、両者を併用するケースも見られます。

ユーザー入力側の対策（プロンプトインジェクション）

プロンプトインジェクションとは、ユーザーが意図的にシステムプロンプトの指示を無視させようとする入力を送る攻撃手法です。入力内容の異常なパターンを検知する仕組みや、システムプロンプトと利用者入力を明確に分離する実装（各社APIが提供するロール分離の仕組みを活用する等）で対策します。

レイテンシとAPIコストを抑える設計の勘所

アプリ内チャットは即時性が求められるため、レイテンシ（応答までの遅延）とAPIコストの両立が設計課題になります。この2つはトレードオフの関係になりやすく、優先順位を決めた上で設計する必要があります。

レイテンシを縮める工夫

ストリーミング表示に加え、システムプロンプトなど固定部分をキャッシュする機能を使うと、再計算にかかる時間とコストの両方を抑えられます^*4。用途によっては、複雑な推論が必要な質問だけ高性能モデルに振り分け、単純な定型応答には軽量モデルを使うルーティング設計も有効です。

コスト試算と監視

コストはリクエスト数ではなく入力・出力のトークン数に応じて発生します。日本語は英語と比較してトークン消費が増えやすい傾向があるため、想定利用者数・1セッションあたりの平均往復数をもとに試算し、本番稼働後もダッシュボードで消費量を監視する体制を整えることが望ましいです。

レート制限への対応

各社APIには分単位のリクエスト数・トークン数の上限があり、超過すると429エラーが返ります^*4。エラー発生時に自動で待機・再試行する処理をアプリ側に組み込んでおかないと、利用者数増加時にチャット機能全体が停止するリスクがあります。

Apple・Googleのストア審査で問われるモデレーション要件

AIチャットボットを組み込んだアプリは、通常のアプリにはない審査観点が加わります。事前に対応しておかないと、審査却下による公開遅延を招くおそれがあります。

Appleの審査ガイドライン

AppleのApp Store審査ガイドラインでは、ユーザー生成コンテンツを扱うアプリに対して、不適切なコンテンツをフィルタリングする仕組み・ユーザーが通報できる機能・迅速な対応体制・悪質な利用者をブロックする機能の実装を求めるガイドライン1.2が設けられています^*5。チャットボットを含むアプリ内提供機能を対象とするガイドライン4.7でも、同様のコンテンツモデレーション機能と年齢区分に応じたアクセス制限が求められます^*5。

加えて、利用者の入力データを外部のAIサービスへ送信する場合は、その旨をプライバシーポリシーに明示し、事前に利用者の同意を得ることがガイドライン5.1.2で求められています^*5。

Googleの開発者ポリシー

Google PlayのAI生成コンテンツポリシーでは、生成AI機能を持つアプリが不快なコンテンツ（危険行為の助長、いじめ・嫌がらせにつながる内容等）を生成しないことに加え、アプリ内から離脱せずに不適切な出力を通報・報告できる仕組みを備えることを求めています^*6。開発者には、採用するAIモデルの挙動を理解し、悪用を意図した入力への耐性を事前に検証する責任があるとされています^*6。

審査を見据えた実装ポイント

これらの要件を踏まえると、開発初期の段階で「通報ボタンの設置」「不適切ユーザーのブロック機能」「出力のモデレーション処理」の3点を実装計画に組み込んでおくことが、審査での手戻りを防ぐ近道になります。審査却下による公開スケジュールの遅延は、リリース計画全体に影響するため、軽視できない論点です。

内製と外注 — 判断の分岐点と外注の進め方

ここまで見た通り、アプリ組み込み型AIチャットの実装には、モバイル開発・バックエンド設計・LLM API連携・審査対応という複数領域の知見が同時に求められます。この作業を内製で行うには、iOS/Androidそれぞれのストリーミング実装経験・プロンプト設計スキル・審査ガイドラインの知識を持つ人員を、少なくとも3〜4名規模でチームに揃える必要があります。

内製が向くケース

既存の開発チームがモバイルアプリ開発とサーバーサイド開発の両方を経験しており、LLM API連携の実装経験者が社内にいる場合は、内製での対応が現実的です。ただし、ガードレール設計やストア審査対応まで含めて品質を担保するには、これらの実務経験が求められます。

外注が有効なケース

開発期限が明確に決まっている場合、ストア審査で却下された経験がありその対応ノウハウが社内にない場合、あるいはコア事業の開発リソースを割けない場合は、外注による並行開発が選択肢になります。実装を誤ると、審査却下によるリリース遅延や、ガードレール不足による不適切な応答の公開といった事業リスクに直結するため、専門知見を持つ外部パートナーに委ねる判断は合理的です。

外注時の進め方

外注を進める際は、まず要件定義とPoC（概念検証）で小規模な実装を先行させ、レスポンス品質とトークン消費量を実測してから本開発に移ることが望ましいです。委託先の評価では、モバイルアプリでのストリーミング実装経験・LLM API連携の実績・ストア審査対応の経験・運用保守体制の4点を確認することが重要です。

契約形態は、成果物を明確にしたい場合は請負契約、プロンプト改善を反復しながら進めたい場合は準委任契約が選ばれる傾向があります。モデルのバージョンアップやAPI仕様変更への追随を契約範囲にどこまで含めるかも、事前に取り決めておく必要があります。

まとめ：アプリAIチャット実装の3つの判断軸

本稿では、モバイルアプリにAIチャットボットを組み込む実装に絞って、ストリーミング表示・会話履歴管理・ガードレール・レイテンシ/コスト設計・ストア審査対応・外注の進め方を整理しました。要点を3つに集約します。

第一に、UI・バックエンド・LLM APIという3つの層の役割を理解し、ストリーミングと会話履歴の設計を最初に固めることが手戻りを防ぐ前提になります。第二に、プロンプト設計とガードレールは公開後の事業リスクに直結するため、設計段階から組み込む必要があります。第三に、Apple・Googleそれぞれの審査要件は早期に把握し、通報・ブロック・モデレーション機能を開発計画に含めておくことが、リリース遅延を避ける鍵になります。

これらを同時に満たす実装は難易度が高く、社内に経験者がいない場合は外注によって審査対応まで含めた品質を担保する選択肢が有効です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：総務省「令和7年版情報通信白書」（2025年、個人の生成AI利用経験率調査）
2. *2　出典：株式会社富士キメラ総研「2025 生成AI/LLMで飛躍するAI市場総調査」（2024年12月発表、対話型生成AIチャットボット市場予測。Impress DIGITAL Xの報道による）
3. *3　出典：OpenAI「Streaming API responses」（公式ドキュメント）
4. *4　出典：Anthropic「Rate limits」（公式ドキュメント）
5. *5　出典：Apple「App Store Review Guidelines」（ガイドライン1.2・4.7・5.1.2）
6. *6　出典：Google「AI-Generated Content policy」（Google Play開発者ポリシー）

Tweet