この記事の結論
自社サイトにAIチャットボットを設置するとき、機能と同じくらい先に決めておきたいのが、
「このAIは、何に答えないのか」
です。
応答範囲を決めずに生成AIのAPIをつなぐと、自社と無関係な質問にも普通に答えます。
今回、SolunaProject公式サイトにAIコンシェルジュ「エヴォルナ」を実装したところ、
実際に夕食の相談へ答え、市販のカレールー5商品を比較しておすすめまで返しました。
そこから応答範囲を見直した結果、3つのことが分かりました。
- 範囲外の質問を減らすことで、本来の用途へAPI利用量を集中できる
- 仕事を限定すると、より安価なモデルでも必要な品質を満たせる場合がある
- API料金だけでなく、上限到達時に人間へつなぐ設計まで必要になる
つまり、
「何をやらせるか」の設計は、そのまま「いくらで運用できるか」の設計でもあります。
この記事では、WordPress上で実際に動いているエヴォルナを例に、
応答範囲、モデル選択、利用制限、人間への引き継ぎまで整理します。
なお、AIチャットボットとAIエージェントの違いや、
Project:Evoluna全体の開発方針については前回の記事で整理しています。
▶ AIエージェントの作り方｜チャットボットとの違いと、最初に決める設計
AIコンシェルジュとは
この記事では、
Webサイトを訪れた人と対話し、質問への回答、情報整理、関連ページや人間の窓口への案内を行う生成AI
を「AIコンシェルジュ」と呼びます。
一般的な技術用語として厳密に統一された名称ではありません。
SolunaProjectでは、単純なFAQ回答だけではなく、
訪問者の目的を聞きながら適切な情報へ案内する役割を持たせているため、この呼び方をしています。
従来型のルールベースのチャットボットでは、あらかじめ用意された選択肢や回答を返す設計が中心でした。
生成AIを使う場合は、その場で文章を生成できるため、より柔軟な会話ができます。
ただし、この柔軟性には裏側があります。
何に答えるのかを決めなければ、何にでも答えられてしまう。
そこが今回、最初にぶつかった問題でした。
1｜今回のWordPress実装構成
SolunaProject公式サイトでは、次の構成でエヴォルナを設置しています。
| 項目 | 構成 |
|---|---|
| 設置形態 | WordPressプラグイン |
| フロントエンド | JavaScript / CSS |
| バックエンド | PHP / WordPress REST API |
| 生成AI | OpenAI API |
| UI | 画面右下の開閉式チャット |
| 利用制御 | セッション等の回数制限＋API側の支出管理 |
| 人間への導線 | 問い合わせ・関連ページへの案内 |
着手したのは前日の夜。
翌日の午後には、実際の公開ページ上で会話できるところまで動きました。
丸一日と少しです。
そして今回、実装コードを私は1行も自分で書いていません。
普段使っているChatGPTにコード生成と修正を依頼し、Claudeにも設計のチェックを頼みました。
私はサウンドクリエイター出身で、プログラミングを本業にしてきた人間ではありません。
それでも、生成AIを使うことで公開環境まで実装できました。
ただし、
「コードを書かなかった」と「コードを確認しなくていい」は別です。
生成されたコードを見ながら、
- ここでは何を処理しているのか
- どこにAPIへ送る文章があるのか
- 回数制限はどこで判定しているのか
- エラー時には何が表示されるのか
を一つずつ確認しました。
AIがコードを書けるようになっても、
動くものを作ることと、自分で運用できることは同じではありません。
なお、APIキーはブラウザ側のJavaScriptへ直接埋め込まず、サーバー側で管理する必要があります。
2｜実際に起きた問題：受付AIがカレーをおすすめした
実装後、動くのが嬉しくて、エヴォルナへいろいろ話しかけました。
試しに、
「今日の夕食どうしようかな？」
と聞きました。
すると、
丼もの。
鍋。
スープ。
麺類。
と、普通に献立を提案してくれました。
そこでさらに、
「カレーにしたい。市販のルーなら何がおすすめ？」
と聞いてみました。
すると、
S&Bゴールデンカレー。
ディナーカレー。
ジャワカレー。
バーモントカレー。
ZEPPIN。
5商品を比較して、
「迷ったらゴールデンカレーの中辛」
まで提案してくれました。
……AI導入支援をしているサイトの受付です。
この実際の会話画面や、作った直後に何を考えていたのかはnote版に残しています。
▶ うちの受付嬢AIが、カレーのルーをおすすめしてきた話｜Project:Evoluna 第2話
重要なのは、これがAIの故障ではないということです。
むしろ逆でした。
生成AIとしては正常に動いています。
質問された。
知っている。
だから答えた。
問題は、
「あなたはSolunaProjectの受付なのだから、何には答えないのか」
を十分に設計できていなかったことでした。
名前。
ビジュアル。
挨拶文。
人格。
それらを作っても、担当範囲そのものが決まるわけではありません。
最初のエヴォルナは、
SolunaProjectの衣装を着せた汎用AIに近い状態だった
ということです。
AIへ自社らしい判断基準を渡す考え方については、こちらの記事でも整理しています。
▶ 属人化を解く鍵はマニュアルではなく「判断基準」の言語化だ
3｜範囲外の質問に答えると何が問題なのか
夕食の相談くらいなら、笑い話で終わります。
ただし、公開サイトのAIとして考えると、少なくとも3つの問題があります。
① 本来の目的以外にAPI利用量を使う
APIは従量課金です。
つまり、自社サービスと関係のない会話でも、入力・出力した分だけ利用量が発生します。
雑談で利用量が増え、その結果、本当に相談したい訪問者が使いにくくなれば本末転倒です。
公開型AIでは、
「何人来るか分からない」
だけではありません。
「何を聞かれるかも分からない」
という前提で設計する必要があります。
② サイトが何屋なのか分かりにくくなる
公式サイトに置くAIは、それ自体が会社の説明になります。
AI活用について聞けば答える。
業務改善について相談すれば案内する。
SolunaProjectの記事を探せば紹介する。
ここまでは、事業内容と一致しています。
しかし、
夕食。
旅行。
買い物。
スポーツ。
何でも高品質に答えてしまったら、
「結局、この会社は何をする会社なのか」
という輪郭が薄くなります。
AI導入では機能の多さより、
「この業務に使う」
と一つ決める方が動かしやすい。
③ 責任を持てない領域まで答える
これが一番重要だと考えています。
ユーザーにとって本当の不利益は、
「その質問には答えられません」
と言われることではありません。
むしろ、
その企業が責任を持てない領域について、もっともらしい回答を受け取ること
の方が問題になる場合があります。
たとえば、
- 契約条件
- 見積もり
- 医療
- 法律
- 税務
- 個別事情を伴う重要判断
などです。
そこでエヴォルナでは、
AI活用 業務改善 SolunaProjectのサービス SolunaProjectの記事
を中心に答える。
軽い挨拶や自然な雑談は可能。
しかし担当外の相談なら、それを伝えて本来の案内へ戻る。
という方針へ修正しました。
【関連記事】
・AI導入で最初に決めたい4つの境界線
・AIの答えが一般論になる理由｜プロンプトより先に渡すべき「判断基準」の作り方
・中小企業のAI導入が進まない理由｜地方の商工会議所で聞いた現在地と、全国データが示す構造
4｜応答範囲を絞ったら、安価なモデルへ変更できた
ここからは、設計の話がそのまま経費へつながった部分です。
実装当初は GPT-5.6 Terra を使っていました。
しかし、テストを繰り返していると利用額が増えていきます。
そこで、
GPT-5.6 Luna
へ変更しました。
2026年7月30日の価格改定後、OpenAI APIの料金は次の通りです。
| モデル | 入力 / 100万token | 出力 / 100万token |
|---|---|---|
| GPT-5.6 Sol | $5.00 | $30.00 |
| GPT-5.6 Terra | $2.00 | $12.00 |
| GPT-5.6 Luna | $0.20 | $1.20 |
※価格は変動します。最新の情報は提供元の料金ページをご確認ください。
TerraからLunaへ変更すると、入力・出力ともに単価は10分の1です。
では、品質も10分の1になるのか？
実際に受付用途で試しました。
今回テストした範囲では、必要な品質を維持できました。
もちろん、
Lunaならどんな業務でもTerraと同じ品質になる
という意味ではありません。
今回の用途では、
- 仕事内容が限定されている
- 回答すべきテーマが限定されている
- 複雑な推論をする必要がない
- 最終判断は人間へ渡す
という条件があります。
つまり、
高性能なAIへ何でも答えさせる設計から、軽量なAIへ小さな仕事を任せる設計へ変えた。
これが、モデルを下げても運用できた要因の一つだと考えています。
やらないことを決めたら、必要な性能まで下げられた。
これは思想ではなく、そのままAPI利用料の話です。
reasoning effortも固定費ではない
GPT-5.6系では、モデルだけでなく推論量も調整できます。
複雑な分析なら深く考えさせる意味があります。
一方、
「このサービスについて知りたい」 「関連する記事はどれ？」 「人間に相談したい」
といった受付用途で、毎回最大限の推論を使う必要があるとは限りません。
reasoning effortを下げることで品質が足りるかも含め、実際の用途で比較テストして決めるのが現実的です。
重要なのは、
高性能な設定を選んでから仕事を探すのではなく、仕事を決めてから必要な性能を選ぶこと。
だと思っています。
5｜API利用制限は「回数」と「金額」の二段構えにする
公開サイトでは、モデル単価だけでは十分ではありません。
利用量そのものを制御します。
SolunaProjectでは、
① アプリ側の利用回数制限
と、
② OpenAI API側の支出管理
を組み合わせています。
リクエスト回数を制限する
たとえば、
- セッション単位
- IP単位
- 一定時間単位
- 1日単位
などで回数を制限します。
同じ利用者から大量のリクエストが来ても、際限なくAPIを呼ばないためです。
開発中は自分自身が制限へ引っかかるため、管理者だけ検証用に扱いを分ける方法もあります。
IP等を保存する場合は、保存方法や期間、プライバシー上の扱いも併せて確認します。
支出上限・通知設定も確認する
API提供側にも、予算通知や支出制御の仕組みがあります。
ただし注意が必要です。
「予算として入力した数字」と「APIが必ず停止する強制上限」は、同じとは限りません。
OpenAIの管理画面では、通知用の支出閾値と、強制停止するspend limitなど、設定の種類が分かれています。
自分のOrganization / Projectでどの制御が有効なのかを確認してください。
参考：OpenAI Help Center｜Troubleshooting API usage and spend limits
SolunaProjectでは現在、月20ドルを予算上限の目安として運用を始めています。
ただし、API側の設定だけに頼らず、アプリ側でも利用回数を制御します。
6｜上限に達した後まで設計する
意外と忘れやすいのがここです。
利用制限を作った。
APIも止まった。
それで終わりではありません。
訪問者から見ると、
AIが突然壊れたように見える
からです。
たとえば、
通信に失敗しました。
だけでは理由が分かりません。
そこで、
現在AIコンシェルジュをご利用いただけません。 お急ぎの場合はお問い合わせフォームからご連絡ください。
など、人間の窓口へ逃がします。
つまり必要なのは、
AIを止める仕組みではなく、AIが止まっても事業が止まらない仕組み
です。
ここは契約や見積もりなどを人間へ残す設計とも同じです。
AIは最後まで自力で解決する必要はありません。
「ここから先は人間へ」
と言えることも、業務AIの機能の一つです。
7｜公開型AIチャットボットに最低限入れたいもの
今回の実装を踏まえて、現時点で最低限必要だと考えているものを整理します。
1．応答範囲
何について答えるのか。
何については答えないのか。
2．人間へ渡す条件
契約。
金額。
機密情報。
重要な判断。
利用者本人が人間を希望した場合。
こうした条件を先に決めます。
3．利用量の制限
セッション・時間・日などの回数制限。
API支出の監視。
必要に応じた強制停止。
4．停止時の代替導線
AIが使えなくても、問い合わせフォームや人間の窓口へ移動できる状態を作ります。
5．入力してほしくない情報の案内
氏名、電話番号、パスワード、機密情報など、業務上必要のない情報を不用意に入力しないよう案内します。
6．APIキーをブラウザへ出さない
秘密情報であるAPIキーはサーバー側で管理します。
ここまで決めたうえで、
音声。
長期記憶。
外部サービス連携。
自律処理。
といった機能を追加します。
機能は、その後です。
よくある質問
Q. WordPressにAIチャットボットを設置するには、プログラミングが必要ですか？
今回のProject:Evolunaでは、私は実装コードを自分で書いていません。
生成AIを使ってコードを作りながら実装しました。
ただし、
プログラミング知識が一切不要という意味ではありません。
生成されたコードが、
- 何をしているのか
- どこへデータを送っているのか
- APIキーを安全に扱えているか
- エラー時に何が起きるのか
を確認できる状態は必要だと感じています。
コードを書けることと、運用できることも別です。
Q. AIチャットボットには、どのモデルを使えばいいですか？
用途によります。
最初から最も高性能なモデルを固定するのではなく、
- AIへ任せる仕事を決める
- 答える範囲を決める
- 複数モデルで実際の質問をテストする
- 必要品質を満たす最も費用対効果のよいモデルを選ぶ
という順番が現実的です。
Project:Evolunaでは、TerraからLunaへ変更しても、受付用途のテスト範囲では必要品質を維持できました。
これはあくまで今回の実測結果です。
Q. AIが間違った回答をした場合、誰が責任を負いますか？
法的責任は、利用方法、分野、契約関係、表示内容などによって異なるため、一律には言えません。
だからこそ運用側では、
AIは誤る可能性がある
ことを前提に設計します。
重要な判断をAIだけで確定させない。
担当外の質問へ無理に答えさせない。
必要なら専門家や人間へ確認してもらう。
という境界線を作ります。
Q. API費用はいくらかかりますか？
従量課金なので、
- モデル
- 入力文章量
- 出力文章量
- 推論量
- 利用回数
によって変わります。
そのため、「月○円で必ず足りる」と先に決めるより、
小さく公開 → 実際の利用量を測る → 上限とモデルを調整する
という運用が現実的です。
Project:Evolunaは、月20ドルを予算の目安にスタートしています。
まとめ｜AIの性能より先に、仕事を小さくする
今回、公式サイトにAIを置いて最初に起きた問題は、
コードのバグではありませんでした。
AIの性能不足でもありません。
AIへ仕事を広く渡しすぎていたことです。
その結果、
夕食にも答える。
カレーも比較する。
何でもできるAIになった。
しかし、公式サイトの受付として必要だったのは、
何でもできるAIではなく、担当業務が決まっているAIでした。
そして範囲を絞ると、
利用量を本来の目的へ集中できる。
より安価なモデルを検討できる。
人間へ渡す場所も明確になる。
という変化が起きました。
つまり、
AIの性能を選ぶ前に、AIへ渡す仕事を小さくする。
この順番です。
AIに何ができるのか？
その質問も大切です。
でも、実装前にもう一つ聞いてみてください。
そのAIは、何に答えないと決めますか。
Project:Evolunaについて
Project:Evolunaは、SolunaProject公式サイトで実際に動くAIコンシェルジュ「エヴォルナ」を、
段階的に育てていく開発・実装記録です。
成功した部分だけではなく、
失敗。
設計変更。
コスト。
想定外の挙動。
実際に使った結果。
も公開していきます。
画面右下から、現在のエヴォルナを実際に試せます。
夕食の相談には、もう乗ってくれません。
関連記事
Project:Evoluna 第1回｜設計段階から読む
AIエージェントの作り方｜チャットボットとの違いと、最初に決める設計
自社らしい判断基準をAIへ渡す
今回の失敗を、開発者目線で書いたnote版
AI導入・判断基準の言語化・分身AI構築の相談
「自社でAIを使いたいが、何を任せればいいのか分からない」
「専門家本人の判断基準をAIへ渡せる形にしたい」
「公開するAIの役割や境界線から設計したい」
という場合は、SolunaProjectのサービス内容をご覧ください。
SolunaProject ｜ 人とAIの共創 ｜ 幸福の効率化
AIは義足、才能は本体。
コメント