チャットボット開発のPoC・プロトタイプ・モックアップ開発について

ルールベース型チャットボットは、分岐の試用、反応の確認、基準の設定の順に進めると、本開発後の手戻りを抑えやすくなります。検証の意義や確認項目、費用と期間の目安、試作の方法、本開発への移行をあらかじめ押さえておくと、開発会社やツールベンダーとの協議に役立ちます。

▼全体ガイドの記事
・チャットボット開発の完全ガイド

チャットボット開発におけるPoC・プロトタイプ検証の重要性

ルールベース型は、AIモデルの学習工程がないぶん、開発期間と費用を抑えやすい方式です。一方で、分岐フローが実際の質問パターンに合うかは、要件定義の段階では判断しきれません。

本番のフローを先に作り込んでから公開すると、質問の漏れや、回答にたどり着きにくい箇所が公開後になって判明することがあります。その結果、問い合わせフォームや電話対応に戻り、チャットボットが形骸化するおそれがあります。このリスクを抑えるには、本開発の前に、モックアップ、プロトタイプ、PoCの三段階で検証することが有効です。

ルールベース型は生成AI型より検証の費用や期間が小さく、検証は不要だと思われがちです。しかし、利用者の実際の行動とのずれは触ってみて初めて分かることが多く、検証を軽視すると手戻りの費用が大きくなる場合があります。

ルールベース型チャットボット特有の検証ポイント

この方式では、利用者が選択肢をたどって課題を解決できるかを確かめます。その際は、次の2点で見ると判断しやすくなります。

  • 自己解決率(一次解決率):選択肢から課題を解決できるか
  • シナリオの離脱・誤回答:途中で迷ったり、回答を誤ったりしないか

担当者が想定した順番や情報の粒度が利用者の知りたい内容と異なると、離脱につながります。シナリオの離脱や誤回答の傾向は、試作品を実際に操作してもらわなければ把握しにくいものです。そのため、机上の設計のまま本開発に進まず、早い段階で利用者の反応を得ることが欠かせません。

検証を怠った場合のリスク

検証を省くと、公開後に質問パターンとの不一致が見つかり、分岐フローの大部分を作り直すことがあります。ルールベース型は生成AI型より修正しやすいものの、大規模な修正は、利用者の信頼低下や「導入しても使われない」という社内評価につながるおそれがあります。

数十万円規模の検証費用を惜しんで本開発費用の大部分を使い直すと、合計では割高になり得ます。検証への適切な投資は、手戻りを防ぎ、費用を抑える選択肢です。

ポイント

ルールベース型でも、分岐が実際の質問に合うかは試さなければ分かりません。費用を理由に検証を省くと、公開後の作り直しで結局割高になるおそれがあります。

モックアップ・プロトタイプで確認すべき具体項目

プロトタイプのUI/UXを確認する文言、選択肢の数、スマートフォン表示、有人対応への導線の4項目を示す図。
画面の見え方と操作、切り替え先まで一通り点検できます。

試作品は、抽象的な分岐フロー案を実際に操作できる形にし、社内関係者や一部の利用者と認識を合わせる重要な工程です。そのうえで、分岐や使いやすさの項目を順に確認します。

デシジョンツリー(分岐フロー)の妥当性検証

大項目から小項目へ分けるデシジョンツリー(決定木)は、利用者の思考の流れに沿っているかを試して、妥当性を確かめます。

  • 回答への経路:選択肢から目的の回答にたどり着けるか
  • 行き止まり・遠回り:デッドエンドや不要な分岐がないか
  • 例外的な質問:頻度は低くても必ず発生する質問を含むか

担当者にとって自然な順番でも、利用者には直感的でない場合があります。そこで、クリック操作で回答まで進めるかを試し、分岐のずれを洗い出します。

UI/UX・選択肢の分かりやすさの検証

プロトタイプの段階では、利用者に近い人に試してもらい、選択肢の文言や画面デザインの分かりやすさを確かめます。試用では、画面の見え方から操作のしやすさ、有人対応への道筋まで、利用者の迷いどころを順に見ていきます。

  • 文言:短く、内容が一目で分かるか
  • 選択肢の数:多すぎて選びにくくなっていないか
  • スマートフォン表示:画面上で操作しやすいか
  • 有人対応への導線:切り替えボタンが見つけやすいか

専門用語は、利用者が選択に迷って離脱する原因になります。また、シナリオで解決できない場合の逃げ道も用意します。さらに、試用者の声を踏まえつつ、有人対応への切り替えを確かめます。

ポイント

試作品を利用者に近い人に操作してもらい、回答までの経路や行き止まり、選択肢の文言にずれがないかを見ておくと、本開発後の作り直しを減らせます。

検証フェーズ別の期間・費用感

要件整理からモックアップ作成、テスト運用まで検証を挟むことで、本番展開時の失敗リスクを減らせます。全体の目安は2週間〜1ヶ月程度で、生成AI型より短期間・低コストです。

自社試作の場合(目安:人件費のみ・ツール利用料0円〜数万円)

無料プランのノーコードツールや既存のチャットツールを使えば、基本的に担当者の人件費だけで試作できます。ただし、予算を立てる際は、利用料と検証期間もあわせて見積もります。

  • ツール利用料:0円〜数万円
  • 期間:要件整理・モックアップ作成から社内テストまで約2週間〜1ヶ月

LINE公式アカウントの応答メッセージ機能を使えば、追加ツールなしで簡易的な選択肢式の応答を試せます。予算をかけずに始めたい企業にとって、ハードルの低い方法です。

ベンダー委託の場合(目安:期間2〜4週間・費用20万〜50万円)

シナリオ設計のノウハウがない場合や、業務に即した検証をしたい場合は、ベンダーに支援を依頼できます。目安は、期間が2〜4週間、費用が20万〜50万円程度です。

複数の企業を支援してきたベンダーは、業界特有の質問や離脱しやすい分岐を把握していることがあります。その経験を生かせば、自社だけで進めるより効率的にシナリオを練り上げられる可能性があります。

予算に応じて、自社での試作と委託を組み合わせる方法もあります。たとえば、自社で叩き台を作り、ベンダーにレビューや改善提案を依頼できます。

ポイント

予算をかけずに始めたい場合は自社試作、シナリオ設計のノウハウがない場合や業務に即した検証をしたい場合はベンダー委託が目安です。予算に応じて、両者を組み合わせる方法もあります。

ノーコードツールでの試作手順

専用ツールでデシジョンツリーを設計し、選択肢提示・回答表示ブロックを配置して接続し、プレビューで確認・修正する流れの図。
設計した分岐を画面上で組み立て、操作して確かめる順序です。

プログラミングの知識がなくても試作できるノーコードツールは、種類が充実しています。代表的な方法は、LINE公式アカウントを使う方法と、専用ツールを使う方法の2つです。

LINE公式アカウントの応答メッセージ機能を使う方法

LINE公式アカウントを利用中であれば、管理画面の応答メッセージ機能で、簡易的なルールベース型を試せます。設定は、次の順で進めます。

  1. ユーザーが送る特定のキーワードを決めます。
  2. キーワードへの返信となるテキストや画像の登録

追加ツールなしで始められ、最初の試作ができます。本格的な分岐フローには向きませんが、どの程度の効果が見込めるかを低コストで確かめる第一歩になります。

チャットボット専用ツールを使う方法

本格的な分岐を試す場合は、専用ツールでフローチャートを形にします。組み立ては四つの段階を順に踏み、紙での設計から始めて、配置と接続を経て、プレビューでのテストで締めくくります。

  1. 紙や文書で、質問を大項目から小項目へ分けたデシジョンツリーを設計します。
  2. 管理画面で、選択肢提示ブロックと回答表示ブロックを配置します。
  3. ブロックを矢印でつなぎ、分岐を組み立てる。
  4. プレビューで選択肢をクリックし、回答までの動きを確認して修正する。

この工程をチーム内で数回繰り返すと、本開発の前にシナリオの完成度をかなり高められます。

ポイント

最初の試作はLINE公式アカウントの応答メッセージで始め、本格的な分岐を試す段階で専用ツールに移るのが目安です。専用ツールでは、プレビューで選択肢をクリックし、回答までの動きを確かめながら修正を重ねます。

検証から本開発へ円滑に移行するためのポイント

要件定義書を中心に、Go/No-Go基準、分岐や選択肢の詳細、例外的な質問への方針、見送った質問と理由を記録する構成図。
検証前の基準と、試用で分かった内容を一か所にまとめます。

検証で得た成果を本開発へ円滑に引き継げるかどうかは、プロジェクト全体の成否を左右します。

Go/No-Go基準の設定

検証を続けすぎると、本開発に進めないまま期間が長引いてしまいます。そのため、検証前に定量的な基準を決めておき、移行するか再設計するかを判断します。

  • 自己解決率:◯%以上を満たすか
  • 質問カテゴリ:主要カテゴリの◯割以上をカバーするか

基準を満たせば本開発へ移り、満たさなければ課題を特定して、シナリオを再設計します。また、検証を2〜4週間程度に区切っておくと、長期化を防ぎやすくなります。

検証結果の要件定義書への反映

検証で得た知見は、口頭やメモで終わらせず、正式な要件定義書に記録します。口頭やメモだけでは、本開発の担当者に判断の経緯が伝わりにくいためです。

  • 検証で分かったこと:分岐の詳細や選択肢の文言
  • 例外への対応:例外的な質問パターンへの方針
  • 見送った質問:対応しない判断とその理由

こうして記録しておくと、本開発を担う開発会社やツールベンダーとの認識のずれを防げます。見送りの理由も記録しておけば、本開発中に同じ議論を繰り返す時間を避けられます。検証の成果は、本開発の精度を高める資産として活かせます。

ポイント

検証で得た結果は、Go/No-Go基準に照らして移行か再設計かを決め、要件定義書に記録しておくと、本開発での認識のずれを減らせます。

まとめ

ここまでシナリオ型・ルールベース型のPoC・プロトタイプ・モックアップ開発を取り上げ、検証項目、期間と費用、ノーコードでの試作、本開発への移行を見てきました。

目安として、自社試作は人件費のみで2週間〜1ヶ月程度、ベンダー委託は20万〜50万円・2〜4週間程度です。特に、分岐の妥当性や選択肢の分かりやすさは、利用者に試してもらわなければ判断しにくい点です。

本開発の前にGo/No-Go基準を決め、検証の時間を確保して段階的に精度を高めることが、導入を成功させる近道です。検証の結果を要件定義書に残しておくと、移行時の認識をそろえやすくなります。

▼全体ガイドの記事
・チャットボット開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。