「AIでカスタマーサポートを自動化したい」という課題に向き合う際、まず考えるべき重要な問いがあります。
「顧客が一番怒っているときの対応を、本当にそのAIに任せられますか？」
特にECや物流の現場において、「置き配したはずの荷物がない」というトラブルは、顧客の不安と怒りがピークに達する瞬間です。ここで「よくわかりません」と繰り返すルールベースのボットや、逆に「すぐに返金します！」と勝手に約束してしまう未熟なLLM（大規模言語モデル）を配置するのは、火災現場にガソリンを持ち込むようなものです。
海外の物流テック業界の事例では、AIの不適切な対応がSNSで拡散され、ブランド毀損に直結したケースが報告されています。しかし、適切に設計されたAIエージェントは、逆にこのピンチを信頼構築のチャンスに変えることができます。
今回は、汎用的なチャットボットの作り方ではなく、「置き配トラブル」という最も難易度が高く、かつ自動化の価値が高いユースケースに絞って、Pythonによる実装パターンを解説します。経営的なリスク管理の観点と、エンジニアとしての「まず動くものを作る」プロトタイプ思考を融合させ、状況の特定からAPI連携、そして絶対に超えてはいけない「ガードレール」の設置まで、コードベースで深掘りしていきましょう。
1. なぜ「置き配トラブル」に特化したAIエージェントが必要なのか
多くのエンジニアやプロジェクトが直面する課題は、カスタマーサポート（CS）対応を単なる「Q&Aタスク」として捉えてしまうことです。「荷物が届かない」という問い合わせに対して、ナレッジベースから類似の回答を検索して提示する（従来の単純なRAGアプローチ）だけでは、複雑な置き配トラブルは解決しません。
なぜなら、トラブル対応において顧客が求めているのは「一般的な配送ルールの説明」ではなく、「私の荷物が今どこにあり、どうすれば手元に届くのか」という個別具体的な解決策だからです。静的な情報検索にとどまらず、状況を推論し、システムと連携して行動する「エージェント型」のアプローチが不可欠です。
ルールベースでは対応しきれない「曖昧な状況報告」
顧客からの第一報は、多くの場合、非常に曖昧です。「届いてないんですけど」という短い一言の裏には、多岐にわたる可能性が潜んでいます。
- 盗難の疑い: 配達完了通知は来ているが、玄関前に荷物がない。
- 誤配の疑い: 通知の添付写真が、自分の家の玄関ではない。
- 勘違い: 同居家族が既に回収していた。
- 単なる遅延: まだ配達予定時刻前である。
これらを従来のルールベース（フローチャート型チャットボット）で処理しようとすると、ユーザーに「通知は届いていますか？」「写真は確認しましたか？」といった質問を延々と繰り返すことになり、まるで尋問のような体験を強いることになります。これでは顧客満足度（CS）を下げる要因となりかねません。
LLM（大規模言語モデル）の高度な推論能力を活用すれば、自然な会話の文脈からこれらの可能性を絞り込み、必要な情報だけをピンポイントで確認することが可能になります。
顧客の焦りに寄り添う「共感」と「事実確認」のバランス
トラブル対応システムにおいて最も設計が難しいのが、「解決能力（Fact）」と「共感（Empathy）」の両立です。
人間であれば「それはご心配ですね、すぐに確認いたします」と自然に寄り添えますが、システムは冷徹に「追跡番号を入力してください」と要求しがちです。一方で、AIが共感に偏りすぎて「大変申し訳ありません、すぐに新しい商品を送ります」と、在庫や配送状況の確認もなしに約束してしまうのは、ビジネスとして許容できないハルシネーション（事実に基づかない生成）のリスクとなります。
したがって、今回のエージェントには「顧客の感情を受け止めつつ、裏側では冷静に事実確認を行う」という二重の役割が求められます。
本記事で実装するシステムの全体像
今回構築するのは、単に回答を生成するだけでなく、外部システムと連携してタスクを遂行するエージェントです。以下の3つのステップで処理を行います。
- 意図分類と情報抽出: 顧客の曖昧な発話から「何が起きているか（盗難、誤配、遅延など）」を特定し、必要なパラメータ（注文番号など）を抽出する。
- API連携と事実確認: 配送管理システム（今回はモックを使用）とAPI連携し、実際のステータスを照合する。
- 解決策の提示とガードレール: 権限の範囲内で解決策（再送手配、調査依頼など）を提示し、リスクの高い判断は人間のオペレーターへエスカレーションする。
目指すゴールは、定型的な問い合わせの約60%をAIのみで完全解決し、残りの40%を状況整理された状態でスムーズに人間へ引き継ぐハイブリッドなシステムの構築です。
2. 開発環境のセットアップと設計思想
まずはシステムの足回りとなる開発環境を固めましょう。プロトタイプを素早く構築し、仮説を即座に検証するためには、ツールの選定が重要です。今回は OpenAI の公式SDKをコアにしつつ、構造化データの取り扱いに Pydantic を使用します。
LangChain などのオーケストレーションフレームワークもエコシステムが充実していますが、頻繁な破壊的変更やパッケージ構成の複雑化（Core/Community分割など）を考慮し、今回はメンテナンス性と制御の透明性を最優先します。そのため、OpenAI純正のSDKと Pydantic を組み合わせた、シンプルかつ堅牢な構成を採用します。これにより、ブラックボックス化を防ぎ、AIの挙動を細部までコントロールすることが可能になります。
必要なライブラリとAPIキーの準備
以下のコマンドで、必要なPythonライブラリをインストールします。
pip install openai pydantic python-dotenv colorama
次に、ベースとなるコードを記述します。APIキーの管理には .env ファイルを使用し、セキュリティを確保します。
import os
import json
from datetime import datetime
from openai import OpenAI
from pydantic import BaseModel, Field
from typing import Optional, Literal
from dotenv import load_dotenv
# 環境変数の読み込み
load_dotenv()
# OpenAIクライアントの初期化（最新のSDK仕様準拠）
client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))
# ログを見やすくするための設定（開発時の可読性向上）
from colorama import Fore, Style
def print_ai(msg): print(f"{Fore.GREEN}AI: {msg}{Style.RESET_ALL}")
def print_user(msg): print(f"{Fore.BLUE}User: {msg}{Style.RESET_ALL}")
def print_sys(msg): print(f"{Fore.YELLOW}System: {msg}{Style.RESET_ALL}")
トラブル分類のためのスキーマ定義
AIに自然言語で「なんとなく」判断させるのではなく、明確な型（スキーマ）に落とし込ませることが、信頼性の高いエージェントを作る第一歩です。ここでは Pydantic を使用して、AIが抽出・分類すべき情報の構造を厳密に定義します。
class DeliveryIssue(BaseModel):
"""顧客の報告内容から抽出するトラブル情報の構造"""
issue_type: Literal['not_received', 'damaged', 'wrong_item', 'other'] = Field(
..., description="トラブルの主要カテゴリ（未着、破損、誤配、その他）"
)
tracking_number: Optional[str] = Field(
None, description="会話に含まれる追跡番号や注文番号"
)
has_photo_evidence: bool = Field(
False, description="顧客が証拠写真を持っている、またはアップロードしたか"
)
searched_around: bool = Field(
False, description="玄関周辺やガスメーターボックスなどを既に探したか"
)
customer_sentiment: Literal['calm', 'anxious', 'angry'] = Field(
'calm', description="顧客の感情状態（冷静、不安、怒り）"
)
この構造を定義しておくことで、OpenAIの Tools（Function Calling）や最新の Structured Outputs 機能を利用する際に、AIがこのフォーマットに強制従属したJSONデータを出力してくれるようになります。これにより、後続のプログラムでの条件分岐やデータベースへの保存が飛躍的に安定します。
3. 実装Step 1：状況ヒアリングとトラブル分類ロジック
顧客がいきなり全ての情報を話してくれることは稀です。AIは不足している情報を自律的に質問する必要があります。
Function Callingによる情報の抽出
OpenAIの tools パラメータを使って、会話の中から DeliveryIssue オブジェクトを埋めていくプロセスを実装します。
def extract_issue_details(conversation_history):
"""会話履歴からトラブル詳細を抽出する"""
# PydanticモデルからJSONスキーマを生成
schema = {
"type": "function",
"function": {
"name": "record_issue_details",
"description": "顧客との会話から配送トラブルの詳細を記録・更新する",
"parameters": DeliveryIssue.model_json_schema()
}
}
response = client.chat.completions.create(
model="ChatGPT",
messages=conversation_history,
tools=[schema],
tool_choice={"type": "function", "function": {"name": "record_issue_details"}}
)
tool_call = response.choices[0].message.tool_calls[0]
return json.loads(tool_call.function.arguments)
# テスト用対話シミュレーション
history = [
{"role": "system", "content": "あなたは配送トラブル対応AIです。"},
{"role": "user", "content": "あの、置き配完了になってるんですけど、荷物がないんです。周辺も探したんですけど..."}
]
# 抽出実行
extracted_data = extract_issue_details(history)
print_sys(f"抽出データ: {json.dumps(extracted_data, indent=2, ensure_ascii=False)}")
実行結果のイメージ:
{
"issue_type": "not_received",
"tracking_number": null,
"has_photo_evidence": false,
"searched_around": true,
"customer_sentiment": "anxious"
}
ここでのポイントは、AIが「周辺も探した」という文脈を理解し、searched_around: true をセットしている点です。しかし、tracking_number は null です。これが次のアクション（追跡番号のヒアリング）のトリガーになります。
4. 実装Step 2：配送ステータス連携と解決策の提示
状況が整理できたら、次は事実確認です。ここでは外部の配送管理システム（WMSやTMS）への問い合わせを模したモック関数を作成します。
配送DB（モック）との照合ロジック
# 配送システムのモックデータ
MOCK_DELIVERY_DB = {
"12345": {
"status": "delivered",
"timestamp": "2023-10-27T14:30:00",
"location": "front_door",
"photo_url": "http://example.com/photo.jpg"
},
"67890": {
"status": "in_transit",
"timestamp": "2023-10-27T09:00:00",
"location": "truck"
}
}
def check_delivery_status(tracking_number: str):
"""追跡番号からステータスを確認するAPIモック"""
data = MOCK_DELIVERY_DB.get(tracking_number)
if not data:
return {"error": "not_found"}
return data
状況に応じた条件分岐の実装
AIがステータスを確認した後、どのような判断を下すべきか。ここはビジネスロジックとしてコードで記述する方が安全です。AIに全て判断させると、誤配の可能性があるのに「探してください」と突っぱねるリスクがあるからです。
def determine_next_action(issue_data: dict, delivery_data: dict):
"""ビジネスロジックによるアクション決定"""
# 1. データが見つからない場合
if delivery_data.get("error"):
return "ask_retry_tracking_number"
status = delivery_data["status"]
# 2. まだ配達されていない場合
if status == "in_transit":
return "inform_in_transit"
# 3. 配達完了済みだが、顧客が無いと言っている場合
if status == "delivered" and issue_data["issue_type"] == "not_received":
# 既に周辺を探している場合 -> 盗難や誤配の可能性が高い -> 有人対応へ
if issue_data.get("searched_around"):
return "escalate_to_human"
# まだ探していない場合 -> 探すよう促す
else:
return "suggest_search"
return "escalate_to_human" # デフォルトは安全側に倒す
この determine_next_action の戻り値に基づいて、AIへの次の指示（System Prompt）を動的に切り替えます。
5. 安全な運用のためのガードレール実装
ここが最も重要です。AIに自由な作文を許すと、「ご迷惑をおかけしたので、全額返金いたします」と勝手に言い出すことがあります（ハルシネーション）。これを防ぐための「ガードレール」を実装します。
「勝手な返金約束」を防ぐプロンプト制御
システムプロンプト内に、明確な禁止事項（Negative Constraints）を埋め込みます。
SYSTEM_PROMPT_TEMPLATE = """
あなたは物流会社のカスタマーサポートAIです。
現在、顧客は配送トラブルを抱えています。
【現在の状況】
アクション: {action}
配送データ: {delivery_info}
【禁止事項】
1. あなたには「返金」や「再送」を決定する権限はありません。絶対に約束しないでください。
2. 「担当者に確認します」と言う代わりに、「担当部門にこの件を報告し、調査を依頼します」と伝えてください。
3. 顧客の個人情報（住所、電話番号）をチャットに入力させないでください。必要な場合は専用フォームのURLを案内してください。
【振る舞い】
- 顧客は不安を感じています。事務的になりすぎず、共感を示してください。
- アクションが 'escalate_to_human' の場合は、これ以上AIでは解決できないことを認め、速やかに有人チャットへの切り替えを案内してください。
"""
エスカレーション（有人対応）への切り替え
コード内で「有人対応フラグ」が立った場合、無理にAIに対応を続けさせず、スムーズにハンドオーバーするフローを作ります。
def generate_response(history, action, delivery_info):
# アクションに応じたシステムプロンプトの構築
system_prompt = SYSTEM_PROMPT_TEMPLATE.format(
action=action,
delivery_info=json.dumps(delivery_info, ensure_ascii=False)
)
messages = [{"role": "system", "content": system_prompt}] + history
response = client.chat.completions.create(
model="ChatGPT",
messages=messages,
temperature=0.3 # 創造性を抑えて堅実に
)
return response.choices[0].message.content
このように、「状況判断（ロジック）」と「回答生成（LLM）」を分離することが、CS自動化成功の鍵です。LLMはあくまで「インターフェース」として使い、意思決定のコアはPythonのロジックで制御するのです。
6. まとめと次のステップ
今回実装したプロトタイプは、単なるチャットボットではなく、状況を構造化し、外部データと照合し、リスクを回避しながら解決策を提示する「エージェント」です。
本番環境へのデプロイに向けた課題
実際の運用では、以下の点を考慮する必要があります。
- レイテンシー: Function Callingと回答生成で2回のLLMコールが発生するため、応答に数秒かかる場合があります。UX向上のため、ストリーミング表示（
stream=True）の実装が必須です。 - 音声対応: 電話対応の自動化を目指すなら、Whisperなどの音声認識モデルとのパイプライン統合が必要です。
- 継続的な改善: エスカレーションされた（AIが解決できなかった）ログを分析し、プロンプトや分類ロジックを微調整するMLOpsのサイクルを回しましょう。
AIは魔法の杖ではありませんが、技術の本質を見抜き、適切な設計とガードレールを設けることで、CSチームを疲弊させる「定型的なトラブル対応」から解放する強力なパートナーになります。まずは、このコードをベースに「実際にどう動くか」を試し、自社の配送フローに合わせたPoC（概念実証）をスピーディーに始めてみてください。
コメント