PythonでAIチャットボットを作るなら、まずは一つの質問をAPIへ送り、回答を受け取る小さな構成から始めましょう。Web公開まで進める場合は、会話画面だけでなく、秘密情報の管理、会話の分離、失敗時の案内も必要です。この記事では、企業の案内ボットを想定して、実装する順序と確認点を整理します。
最初は、公式SDKで一往復の応答を確かめる
開発環境を用意したら、OpenAIの公式Pythonリファレンスにある最小のサンプルで、サーバー側から応答を取得できることを確認します。利用できるモデルやSDKの呼び出し方は変更されるため、導入時点の公式サンプルと対応バージョンを確認してください。最初から複数のライブラリや外部サービスを組み合わせないほうが、問題を切り分けやすくなります。
次に、想定する質問を数件送り、回答の長さと内容を確認します。この段階では、会話が成立することと、業務の窓口として使えることを分けて考えましょう。資料にない答えを作っていないかも、早めに試します。
実装する機能を四つに分ける
| 機能 | 確認すること |
|---|---|
| 入力の受付 | 空欄、長すぎる質問、連続送信をどう扱うか |
| 回答の生成 | 役割、回答範囲、参照する情報をどう渡すか |
| 画面への返却 | 送信中、成功、失敗を利用者へどう示すか |
| 記録と管理 | 会話、エラー、利用量を何のために記録するか |
問い合わせ対応なら、回答の最後にどこへ案内するかも仕様に含めます。個別見積もりや契約条件など、AIだけで完結させない内容を決めると、回答ルールと有人対応の境界を作れます。
法人プラン 月額19,800円〜（税別・税込21,780円〜）
次の一歩は、接客の体験から。
自社のサービスやよくある質問を、キャラクターが案内するピタリー。どんな接客ができるのか、利用ページでご覧ください。
APIキーと会話履歴はサーバー側で管理する
APIキーはブラウザーへ配信するコードや公開リポジトリに書かず、サーバー側の環境変数やキー管理サービスから読み込みます。ローカル開発用の設定ファイルも、そのまま共有・公開しないようにします。キーを漏らした可能性がある場合の交換手順と担当者も用意してください。
複数の利用者が使う場合は、会話を利用者やセッションごとに分けます。ある人の質問や回答が、別の人の応答に混ざらないかを確認しましょう。履歴の保存とモデルの追加学習は異なります。履歴を保存するなら、目的、項目、保存期間、アクセスできる人を決めて、不要な個人情報を残さない設計を検討します。
エラーは内容を見て対処する
通信の失敗、認証の問題、入力の問題、利用制限は、同じ扱いにしません。例えば429でも、リクエストの頻度制限による場合と、利用枠や支出上限などによる場合があります。エラーコードと内容を確認し、待って再試行できるものと、設定や契約状態の確認が必要なものを分けます。
再試行する場合も、回数や待ち時間に上限を設けます。SDKの自動再試行設定と重複していないか、公式のエラー資料も確認してください。失敗したまま無制限に呼び続ける実装は避けます。画面には内部情報をそのまま出さず、「時間を置いて再送する」「別の窓口を使う」など、利用者が選べる行動を示します。
公開判断には、質問集と期待する対応を用意する
- よくある質問と、同じ意味の言い換え。
- 資料に答えがない質問や、誤った前提を含む質問。
- 複数回のやり取りが必要な相談。
- 別の利用者の情報を求める質問。
- 通信失敗、APIエラー、連続送信が起きた場合。
各質問について、正しい答えだけでなく、確認を求める、回答を控える、窓口を案内する、といった期待する対応を書きます。回答内容、案内先、操作の分かりやすさを点検し、設定やモデルの変更後にも同じ質問で比較します。一度通ったテストだけで、以後の安全性が保証されるわけではありません。
公開後の担当と、開発しない選択肢も決める
公開前に、FAQの更新、エラーの確認、利用量の管理、停止と復旧を誰が行うか決めましょう。限定したページから始め、必要に応じて対象を広げる方法もあります。開発担当だけが設定を理解している状態を避け、運用担当に確認手順を渡しておくと引き継ぎに役立ちます。
目的が自社サイトのキャラクター接客なら、すべてをPythonで開発する以外に、ピタリーのような既存サービスも比較できます。自作プログラムとの自動連携を前提にせず、必要な回答設定、設置方法、保守範囲が合うかを確認してください。
参照した情報
参考資料・関連情報
執筆・編集：aivy ／ 最終確認：2026.10.23
