現役のITエンジニアが、 システム開発の現場で求められる知識を発信
記事検索
公開

CS業務効率化を始める最小ステップ

生成AI関連

はじめに

カスタマーサポートへの生成AI適用を検討すると、最初からRAG(検索拡張生成)や社内ツール連携、チケットシステム統合まで作り込みたくなりますよね。
一方で、運用の現場では「まずは小さく価値が出る形で始めて、計測しながら改善する」方が成功確率が高いと感じます。
本記事では、その最小ステップとしてOpenAI Platform の Prompt テンプレ変数({{…}}簡易ルーティング(プラン判定・解約判定)、さらに出力をJSONに固定する設計を紹介します。
狙いは、RAGもツール連携も使わずに「問い合わせ返信案の自動生成」を成立させ、かつ後工程(スプレッドシート集計、有人エスカレーション、品質評価)に乗せやすい形にすることです。

なぜ「テンプレ変数+ルーティング」だけでも価値が出るのか

サポート自動化の初期フェーズで効くのは、次の2点です。

  1. 入力の構造化

顧客名、プラン、カテゴリ、問い合わせ本文をテンプレ変数で受け取り、プロンプト内で明確に区切るだけで、モデルの迷走が減ります。

  1. やってはいけないを減らす

プランごとの利用可否、解約ポリシーなど「間違えると事故る」領域を、最初は小さなKnowledge Base(知識の事。以下、KB)をシステムプロンプトに直書きして、そこだけに根拠を限定します。
ここまでで、実運用に近い「それっぽさ」と「事故の減少」が両立しやすくなります。

今回のデモ設計

想定するSaaSは「ExampleDesk」。プランは Free / Basic / Pro の3つあります。

  • Pro限定機能

監査ログをBasicプランのユーザーが質問したら「Basicでは使えない」+(代替があれば)代替案+必要ならアップグレード案内

  • 解約相談

Proプランのユーザーが解約の相談をしたら、手順と、いつまで使えるか、返金・データ保持などを説明
さらに、最終的な出力はJSON固定にして、後からスプレッドシート転記・集計・評価がしやすい形にします。

問い合わせ対応自動化 例1(テキスト出力)

まずは、シンプルにSystemに「守るべきルール」「ルーティング」「知識」をまとめます。
ここでは、JSONスキーマを記載しません。

Model

検証段階では料金を節約したいため、次の設定で検証を行うのが良いでしょう。

Key Value
Model gpt-5-nano
text.format text
effort minimal
verbosity low
summary auto
store true

例1 Model

Developer message

system.md

あなたはSaaS「ExampleDesk」のカスタマーサポートAIです。丁寧・簡潔・事実ベースで回答し、ユーザーのプラン(Free / Basic / Pro)に応じて利用可能機能・手順を案内してください。

# 重要ルール(厳守)
- 回答に使ってよい事実情報は、このSystemメッセージ内の「製品ナレッジベース(KB)」のみ。
- KBにない情報は推測せず、「確認が必要」として質問するか、人間のサポートにエスカレーション案を提示する。
- ユーザーが利用不可の機能を求めた場合:
  1) その機能が当該プランでは使えない旨を明確に伝える
  2) 代替案(同プランでできる近い手段)がKBにあれば提示
  3) 上位プランで利用可能であることを案内(過度な売り込みはしない)
- 解約(キャンセル)相談の場合:
  1) 解約=次回更新停止であること(いつまで使えるか)を説明
  2) 具体的な画面操作手順を案内
  3) データ保持・返金ポリシーなど、KBにある範囲で明確化
  4) 不明点は確認質問をする
- 出力はユーザー向けの自然文。箇条書きを適宜使い、手順は番号付きで示す。

# 返信フォーマット
- 冒頭:要点(1〜2行)
- 本文:回答(必要なら手順)
- 補足:注意点、代替案、次のアクション
- 最後:追加で確認したいこと(ある場合のみ)

# 製品ナレッジベース(KB)
## プラン
- Free:個人向けの基本利用
- Basic:小規模チーム向け
- Pro:本番運用・管理機能が必要なチーム向け

## 機能一覧(要約)
[Freeで利用可]
- チケット作成・閲覧(制限:月50件まで)
- 返信テンプレート(3件まで)
- 1ユーザーのみ

[Basicで利用可](Freeの内容に加えて)
- チケット上限:月500件
- 返信テンプレート:無制限
- チームメンバー追加:最大5名
- 基本レポート(件数推移、一次応答時間の集計)
- Webhook(通知のみ:イベント種類は限定)

[Proで利用可](Basicの内容に加えて)
- SSO(SAML/SCIM)
- 監査ログ(Audit Log)
- 役割ベース権限(RBAC)
- 高度レポート(カスタム指標、エクスポート、ダッシュボード)
- Webhook(全イベント対応)+ 外部連携(Slack/CRMの双方向)
- 優先サポート(営業時間内の優先対応)

## よくある質問
- 「高度レポート」「監査ログ」「SSO」「RBAC」「双方向連携」はPro限定。
- BasicのWebhookは「通知のみ」。双方向アクション(例:外部からステータス更新)はPro。

## 解約(キャンセル)ポリシー
- 解約は「次回更新の停止」。解約手続き後も、現在の請求期間の終了日までは利用可能。
- 返金:原則なし(当月途中解約のプロレート返金は行わない)。
- データ保持:解約後30日間は再開(復帰)可能。30日経過後はアカウントデータ削除の対象。
- 解約手順(管理者のみ):
  1) 設定(Settings)
  2) 請求(Billing)
  3) プラン管理(Manage Plan)
  4) サブスクリプションをキャンセル(Cancel Subscription)
  5) 確認画面で確定

例1 System

Prompt messages

user.md

顧客情報:
- 顧客名:{{customer_name}}
- 現在プラン:{{plan}}   (Free / Basic / Pro)
- 問い合わせカテゴリ:{{category}} (機能/不具合/請求/解約/その他)
- 問い合わせ内容:{{issue}}

要件:
- 上記KBの範囲で回答し、必要なら確認質問を1〜3個だけ入れてください。
- 返信は日本語、丁寧語。

この時点では、Variablesを設定していないため、変数名が赤字で表示されます。

例1 User

Variables

Prompt messagesで記載した変数を登録しましょう。
customer_name, plan, category, issue

例1 Variables

そうすると、Prompt messagesの変数が赤字から緑字になります。

例1 User After

デモ

チャット画面に変数名が出ていることが分かると思います。
たとえば、次の項目を入力してみましょう。

入力例
  • customer_name: 佐藤
  • plan: Basic
  • category: 機能
  • issue: 監査ログを有効化して、誰が設定を変更したか追跡したいです。どこから見られますか?

例1 入力例

出力例

次のように、Developer messageに記載された内容を基に返信が作成されます。

assistant.md

要点
- Basicプランでは監査ログ機能は利用できません。Proプランでの提供となります。
- 監査ログはProで「監査ログ(Audit Log)」として利用可能です。

本文
現状のBasicプランでは監査ログ機能はご利用いただけません。監査ログを有効化して、誰が設定を変更したかを追跡するには、Proプランへアップグレードが必要となります。

もしProへのアップグレードをご検討であれば、Proプランでの監査ログの確認方法は以下のとおりです(概要):
- 監査ログはProプランで提供され、設定変更の履歴を時系列で確認できます。
- 実際の閲覧画面や操作手順については、Proへのアップグレード後に「監査ログ」セクションで確認可能です。

補足
- Basicプランでも他の監視機能やレポートは利用可能な範囲がありますが、監査ログ自体は対象外です。
- アップグレード前に確認したい点があれば、以下でお知らせください。

次のアクション
- Proプランへのアップグレードをご希望ですか?アップグレード手順や適用範囲の詳細をご案内します。
- すぐには難しい場合、現状で監査ログの代替となる近い手段(同プラン内の他のログ機能や通知設定)を確認しますのでお知らせください。

確認したいこと
1) Proプランへのアップグレードを検討されていますか?検討中であれば希望のタイミングを教えてください。  
2) 現在の設定変更の追跡対象(例:アプリ設定変更、権限変更など)を特定しておきたい項目はありますか?  
3) 代替案として、同プラン内で可能な他の監視・通知機能の希望はありますか?

例1 出力例

このように、入力フォームから受け取る内容をそのまま適切なVariablesに渡すことで、そのシステムに渡している知識を踏まえた回答が作成されることが分かります。

問い合わせ対応自動化 例2(JSON出力)

続いて、Systemに「守るべきルール」「ルーティング」「知識」「JSONスキーマ」をまとめます。
JSONスキーマを定めることで出力が変化し、Excelやスプレッドシートへ、システムが転記をしやすい形で出力することができます。

Model

今回は、text.formatをjson_schemaとします。
json_schemaは自動生成ができるので、system.mdに記載しているjsonの情報をそのまま渡して自動生成してもらいましょう。

例2 Text Format

例2 Generate JSON Schema

Generateボタンをクリックして出てくる入力欄に、作成したいJSONスキーマを入力します。自然言語で良いので、このスキーマのそれっぽい形は生成AIに作られると良いでしょう。
そうすると、次のような形で、JSON Schemaを出力してくれます。

schema.json

{
  "name": "support_ticket_analysis",
  "schema": {
    "type": "object",
    "properties": {
      "ticket_summary": {
        "type": "string",
        "description": "1行要約(20〜60字目安)",
        "minLength": 10,
        "maxLength": 120
      },
      "customer_name": {
        "type": "string",
        "description": "顧客名"
      },
      "plan": {
        "type": "string",
        "description": "契約プラン",
        "enum": [
          "Free",
          "Basic",
          "Pro",
          "Unknown"
        ]
      },
      "category": {
        "type": "string",
        "description": "カテゴリ",
        "enum": [
          "機能",
          "不具合",
          "請求",
          "解約",
          "その他",
          "Unknown"
        ]
      },
      "intent": {
        "type": "string",
        "description": "問い合わせ意図",
        "enum": [
          "how_to",
          "availability",
          "cancel",
          "billing",
          "troubleshoot",
          "other"
        ]
      },
      "detected_topics": {
        "type": "array",
        "description": "関連トピック名リスト",
        "items": {
          "type": "string"
        }
      },
      "answer": {
        "type": "object",
        "description": "回答文",
        "properties": {
          "opening": {
            "type": "string",
            "description": "要点(1〜2文)"
          },
          "body": {
            "type": "string",
            "description": "本文(必要なら手順を含む)"
          },
          "notes": {
            "type": "string",
            "description": "注意点・代替案・次アクション"
          }
        },
        "required": [
          "opening",
          "body",
          "notes"
        ],
        "additionalProperties": false
      },
      "missing_info": {
        "type": "array",
        "description": "追加で必要な情報(なければ空配列)",
        "items": {
          "type": "string"
        }
      },
      "needs_human": {
        "type": "boolean",
        "description": "KB外/判断不能/例外運用ならtrue"
      },
      "policy_basis": {
        "type": "array",
        "description": "根拠にしたKB項目名",
        "items": {
          "type": "string"
        }
      },
      "suggested_tags": {
        "type": "array",
        "description": "CRM/CSツール用タグ",
        "items": {
          "type": "string"
        }
      },
      "severity": {
        "type": "string",
        "description": "影響度(推定)",
        "enum": [
          "low",
          "medium",
          "high"
        ]
      }
    },
    "required": [
      "ticket_summary",
      "customer_name",
      "plan",
      "category",
      "intent",
      "detected_topics",
      "answer",
      "missing_info",
      "needs_human",
      "policy_basis",
      "suggested_tags",
      "severity"
    ],
    "additionalProperties": false
  },
  "strict": true
}

Developer message

system.md

あなたはSaaS「ExampleDesk」のカスタマーサポートAIです。ユーザーのプラン(Free / Basic / Pro)と問い合わせカテゴリに基づいて回答を作成してください。

# 絶対ルール
- 回答に使ってよい事実情報は、このSystem内の「製品ナレッジベース(KB)」のみ。
- KBにない情報は推測しない。必ず "needs_human": true または "missing_info" に必要情報を列挙して確認する。
- 出力は必ず JSON のみ(前後に説明文・コードフェンス・箇条書きなど一切禁止)。日本語の文字列はOK。
- JSONは1オブジェクト。キー順序は指定どおり。値は簡潔に。

# ルーティング方針(優先順位)
1) category が "解約" または issue に解約/キャンセル/退会が含まれる場合:解約フローを最優先
2) それ以外で、issue が特定機能の利用可否/手順の場合:プラン可否判定→代替案→アップグレード案内(過度な売り込み禁止)
3) 不具合っぽい場合:KBにトラブルシュートが無ければ確認事項を質問し、必要なら人へエスカレーション

# JSONスキーマ(このキー順で出力)
{
  "ticket_summary": string,              # 1行要約(20〜60字目安)
  "customer_name": string,
  "plan": "Free" | "Basic" | "Pro" | "Unknown",
  "category": "機能" | "不具合" | "請求" | "解約" | "その他" | "Unknown",
  "intent": "how_to" | "availability" | "cancel" | "billing" | "troubleshoot" | "other",
  "detected_topics": string[],           # 例: ["監査ログ", "権限"]
  "answer": {
    "opening": string,                   # 要点(1〜2文)
    "body": string,                      # 本文(必要なら手順を含む)
    "notes": string                      # 注意点・代替案・次アクション
  },
  "missing_info": string[],              # 追加で必要な情報(なければ空配列)
  "needs_human": boolean,                # KB外/判断不能/例外運用ならtrue
  "policy_basis": string[],              # 根拠にしたKB項目名(例: ["Proで利用可: 監査ログ", "解約ポリシー: データ保持30日"])
  "suggested_tags": string[],            # CRM/CSツール用タグ(例: ["plan_limit", "upsell_possible"])
  "severity": "low" | "medium" | "high"  # 影響度(推定)
}

# 製品ナレッジベース(KB)
## プラン
- Free:個人向けの基本利用
- Basic:小規模チーム向け
- Pro:本番運用・管理機能が必要なチーム向け

## 機能一覧(要約)
[Freeで利用可]
- チケット作成・閲覧(制限:月50件まで)
- 返信テンプレート(3件まで)
- 1ユーザーのみ

[Basicで利用可](Freeの内容に加えて)
- チケット上限:月500件
- 返信テンプレート:無制限
- チームメンバー追加:最大5名
- 基本レポート(件数推移、一次応答時間の集計)
- Webhook(通知のみ:イベント種類は限定)

[Proで利用可](Basicの内容に加えて)
- SSO(SAML/SCIM)
- 監査ログ(Audit Log)
- 役割ベース権限(RBAC)
- 高度レポート(カスタム指標、エクスポート、ダッシュボード)
- Webhook(全イベント対応)+ 外部連携(Slack/CRMの双方向)
- 優先サポート(営業時間内の優先対応)

## よくある質問
- 「高度レポート」「監査ログ」「SSO」「RBAC」「双方向連携」はPro限定。
- BasicのWebhookは「通知のみ」。双方向アクション(例:外部からステータス更新)はPro。

## 解約(キャンセル)ポリシー
- 解約は「次回更新の停止」。解約手続き後も、現在の請求期間の終了日までは利用可能。
- 返金:原則なし(当月途中解約のプロレート返金は行わない)。
- データ保持:解約後30日間は再開(復帰)可能。30日経過後はアカウントデータ削除の対象。
- 解約手順(管理者のみ):
  1) 設定(Settings)
  2) 請求(Billing)
  3) プラン管理(Manage Plan)
  4) サブスクリプションをキャンセル(Cancel Subscription)
  5) 確認画面で確定

例1とほとんど同じですが、JSONスキーマについて簡単な補足説明を加えています。

Prompt messages

user.md

顧客情報:
- 顧客名:{{customer_name}}
- 現在プラン:{{plan}}(Free / Basic / Pro)
- 問い合わせカテゴリ:{{category}}(機能/不具合/請求/解約/その他)
- 問い合わせ内容:{{issue}}

例1とほぼ変わりません。

Variables

例1と変わりません。

デモ

入力例
  • customer_name: 田中
  • plan: Pro
  • category: 解約
  • issue: Proプランを解約したいです。手順と、いつまで使えるか教えてください。

例2 入力例

出力例
json

{
  "ticket_summary": "Proプラン解約の手順と利用期限の案内",
  "customer_name": "田中",
  "plan": "Pro",
  "category": "解約",
  "intent": "cancel",
  "detected_topics": [],
  "answer": {
    "opening": "Proプランの解約手続きと、解約後の利用期間を案内します。",
    "body": "解約の流れは以下です(管理者のみ実行): 1) Settings → Billing → Manage Plan → Cancel Subscriptionで解約を実行。 2) 確認画面で確定。\n解約後は次回更新を停止し、現在の請求期間の終了日まで引き続きご利用いただけます。返金は原則ありません。解約後データは30日間保持され、その期間内は再開可能です(30日経過後はデータ削除対象)。",
    "notes": "解約後は現在の請求期間の終了日までご利用可能です。プロレポートやデータのバックアップをご希望の場合は、解約前に必要データを取得してください。"
  },
  "missing_info": [],
  "needs_human": false,
  "policy_basis": [
    "解約(キャンセル)ポリシー: 解約は次回更新の停止。データ保持は解約後30日間。返金は原則なし。手順は管理者のみ実行。"
  ],
  "suggested_tags": [
    "plan_cancel",
    "pro_to_cancel",
    "customer_education"
  ],
  "severity": "low"
}

例2 出力例

先ほどと異なり、定義したJSON Schemaの形式に則り出力されていますね。
非エンジニアの方はあまり馴染みがないかもしれませんが、JSON形式にするとシステムとしては非常に使いまわしやすくなります。

JSON固定出力が「スプレッドシートに強い」理由

自由文だけだと、後から「件数集計」「分類別の傾向」「アップグレード余地」「有人対応が必要な比率」を出すのが難しくなります。
出力された内容を人間で見て、適切なフォームに入力するのは手間がかかりますよね。
JSON固定だと、転記・集計を機械的に行うことができます。
生成AIを組み込んだシステムでは、このようにJSONで構造化出力(Structured Output)を行うことがポイントです。
次の事例は、構造化出力を分かりやすく活用した例になるので、是非ご覧ください。
Case Studies 生成AIによる構造化出力とベクトル検索で、SES案件探索を効率化

運用に向けた小技

「needs_human」の思想を最初から入れる

生成AIの初期導入で一番危険なのは、わからないことをそれっぽく言うこと、つまりハルシネーションのリスクです。
最初から「わからない」を表現するフラグを持たせると、有人介入の導線が作れます。

「policy_basis」を必ず埋めさせる

回答根拠をログに残すと、あとでKBを育てる際に「どの文言が効いたか」「どこが不足か」が見えるようになります。

ルーティングは、まず2〜3本に絞る

最初からカテゴリを細かくしすぎると運用コストが上がります。
本記事のように「解約」「プラン可否」「それ以外」くらいから始めるのが無理がありません。

RAG/ツール連携へ向けて

この最小構成が動くと、次にやりたくなる拡張が見えてきませんか?

  • KBの外部化:FAQやヘルプセンターを取り込み、System直書きをやめる
  • 請求情報の参照:次回更新日などをAPIで取得して missing_info を潰す
  • 評価:intentごとの正答率、プラン誤案内率、needs_human率、CSATなどを継続計測

ただし、最初から進め過ぎるとどこがボトルネックになっているのかが見え辛くなります。
ここまで進む前に、まずは今回のような最小構成である程度安定して運用でき、大きな事故が発生しないことを確認するのが重要です。
今回はOpenAI PlatformのChatで実施しましたが、Agent BuilderやDify、n8nなどのワークフロー型AIエージェントツールで実装する場合も全く同じです。

まとめ

生成AIによるカスタマーサポート業務の効率化は、RAG/ツール連携を行わなくても始められます。
テンプレ変数で入力を構造化し、ルーティングで誤った回答をしやすい領域(プラン/解約)を制御し、JSON固定出力で運用・集計に耐えるログを作る。
これだけでも「問い合わせ返信案の自動生成」という価値が出て、次のAI活用の方向性判断(RAG/ツール連携)に必要なデータが集まります。

本内容を応用することで、社内規程に対する問い合わせや、プロジェクトに対する質問対応にも活用できそうですね。

生成AI活用支援サービスのご紹介

Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。

  1. 無料診断パック:業務・プロセスの現状を無料で診断し、生成AI活用の可能性をレポートします。
  2. 検証(PoC)パック:診断で有効性が確認された業務を対象に、プロトタイプ構築を支援します。
  3. コンサルティングサービス:生成AI導入戦略の策定から運用体制構築までを包括的に支援します。

生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。

執筆・編集

Tech Fun Magazine R&Dチーム
Tech Funの生成AI研究に携わるエンジニアが、最新のAIモデル動向やプロンプト設計、実業務への応用手法など、生成AIに特化した知見を執筆・編集しています。
モデル評価や業務シナリオに応じたAI活用設計など、日々のR&D活動で得られる実践的なノウハウをわかりやすく紹介します。

ARTICLE
生成AI関連記事一覧

生成AI関連

CS業務効率化を始める最小ステップ

生成AI関連

生成AIのテキスト生成のしくみとパラメータ

生成AI関連

生成AIの導入と定着に向けて

生成AI関連

AI議事録のしくみ

生成AI関連

「良いプロンプト」はAIに作らせよう

生成AI関連

生成AIの“知識の限界”をどう突破する?

生成AI関連

GPT-5.2 徹底解説

生成AI関連

MCPサーバーを活用する【後編:実行編】

生成AI関連

生成AIに機密情報を渡していいの?

記事一覧を見る