💡 AIモデルは英語のプロンプトで最も高い精度を発揮します。そのため、プロンプト本文は英語のまま掲載しています。英語で入力することで、より正確で詳細な回答が得られます。 最高のサポート体験は、顧客が自分で即座に解決できるものです。これらのプロンプトは、FAQシステムの構築、チャットボットフローの設計、多層型解決エンジンの作成、質問の80%を人手なしで処理するセルフサービスリソースの構築を支援します。GPT-4.1、Gemini 2.5 Pro、Claude Sonnet 4、Grok 3でテスト済みなので、最もスマートなサポート自動化を構築するモデルがわかります。
プロンプト
実際のチケットデータから包括的なFAQページを構築する
Build a comprehensive FAQ section for [product/service/website]. What we do: [describe your offering] Target audience: [who uses your product] Common support tickets: [top 10 questions you receive] Existing FAQ: [paste current FAQ, or 'none'] Tone: [professional / friendly / casual] Create: 1. 20 FAQs organized into 4-5 logical categories 2. Each answer: clear, concise (under 100 words), with a specific action step 3. 5 'hidden' questions customers think but don't ask (and answer those too) 4. Internal links: which FAQ answers should link to other pages 5. A 'still need help?' CTA strategy for each category 6. SEO-optimized question phrasing that matches how people actually search
プロのコツ
サポートチケットを件数順に並べ、上位20%の質問をFAQに載せましょう。その20%が通常チケット量の80%を占めています。AIは優れた回答を書けますが、正しい質問を与えた場合に限ります――推測ではなく実データから始めましょう。
テスト済み Mar 15, 2026
カスタマーサポートのチャットボット会話を設計する
Design a chatbot flow for [purpose: customer support / lead qualification / order status / FAQ]. Platform: [website / app / WhatsApp / Facebook Messenger] Top 5 customer intents: [what people ask most] Escalation needed for: [when should a human take over] Brand personality: [how the bot should 'sound'] Integrations available: [CRM, order system, knowledge base] Build the chatbot: 1. A greeting message that sets expectations (what the bot can and can't do) 2. Intent recognition: 5-7 main conversation branches 3. Full conversation flow for each branch (with decision trees) 4. Fallback responses: what to say when the bot doesn't understand 5. Human handoff triggers and transition messages 6. A personality guide: do's and don'ts for the bot's communication style
プロのコツ
チャットボットで最も重要なメッセージは「理解できませんでした。担当者におつなぎします」です。混乱を潔く認めるボットは、的外れな回答をループさせるボットよりも優れています。まず失敗パスを設計しましょう。
テスト済み Mar 15, 2026
実際に使われるセルフサービスヘルプセンターを設計する
Help me build a customer-facing knowledge base for [product/service]. Current documentation: [what exists now, or nothing] Top support categories: [main topic areas] User technical level: [beginner / intermediate / advanced / mixed] Format preferences: [text, screenshots, video, GIFs] Platform: [Zendesk, Intercom, Notion, custom] Design the knowledge base: 1. Information architecture: categories, subcategories, and article hierarchy 2. 10 must-have articles (titles and outlines for each) 3. Article template: standard format every article should follow 4. Search optimization: how to title and tag articles for findability 5. A feedback mechanism: how to know which articles are actually helpful 6. A maintenance schedule: how often to review and update content
プロのコツ
記事のタイトルはトピックではなく質問形式にしましょう。「パスワードのリセット方法は?」は見つかります。「パスワード管理」は見つかりません。顧客は質問で検索します――タイトルは顧客の言葉そのものに合わせましょう。
テスト済み Mar 15, 2026
ロボットっぽくならない再利用可能なサポート回答を作成する
Build a library of canned responses for our support team. Product/service: [what you support] Channels: [email, chat, social, phone] Team size: [number of agents] Common scenarios: [list 10-15 frequent situations] Brand voice: [professional / casual / empathetic] For each scenario, create: 1. A canned response with [customization brackets] for personalization 2. A shorter version for chat (under 50 words) 3. A longer version for email (100-150 words) 4. Agent instructions: when to use this and when NOT to 5. Personalization tips: what details to add before sending 6. A naming convention so agents can find responses quickly
プロのコツ
エージェントには定型文を送る前に最低1文は変更するよう義務付けましょう。これによりパーソナライズが強制され、異なるエージェントから全く同じ返信が届くという気まずい状況を防げます。
テスト済み Mar 15, 2026
サポートチケットを自動分類しインテリジェントに振り分ける
Help me build a ticket triage system for our support team. Ticket volume: [daily/weekly count] Team structure: [agents, specialists, tiers] Categories: [list current categories, or 'need to define'] Priority levels: [how you currently prioritize, or 'need a system'] SLA requirements: [response and resolution time targets] Design a triage system: 1. Category taxonomy: 6-10 categories with clear definitions 2. Priority matrix: how to assign P1/P2/P3/P4 based on impact and urgency 3. Routing rules: which tickets go to which team/specialist 4. Auto-tagging keywords: patterns that indicate category and priority 5. First-response templates for each priority level 6. A dashboard view: what metrics to track for triage effectiveness
プロのコツ
トリアージカテゴリーは四半期ごとに見直しましょう。製品の変化に伴い顧客の問題も変化します。6ヶ月前に意味があったカテゴリーが、今は統合すべきチケットを分割していたり、直近のリリースで生まれた新しい問題タイプを見落としていたりするかもしれません。
テスト済み Mar 15, 2026
あらゆるレベルで問題を解決する階層型レゾリューションを構築する
Help me build a multi-layer support resolution system. Product/service: [what you support] Current support structure: [tiers, team size, tools] Ticket volume: [daily/weekly] Average resolution time: [current metrics] Top 10 issue types: [list with approximate frequency] Cost per ticket: [if known, by tier] Design a multi-layer resolution engine: 1. Layer 0 (Self-Service): which issues can be fully resolved without human contact? Design the automation for each 2. Layer 1 (Frontline): which issues need a human but can be resolved in one touch? Create resolution scripts 3. Layer 2 (Specialist): which issues require deep expertise? Define routing criteria and knowledge requirements 4. Layer 3 (Engineering/Escalation): which issues need code changes or executive decisions? Build the handoff process 5. Smart routing logic: how to detect which layer an issue belongs to before a human reads it 6. Layer efficiency metrics: target resolution rate, time, and cost for each layer with improvement benchmarks
プロのコツ
最もコストが低いチケットは、そもそも作成されないチケットです。Tier 1で構築するすべての解決策について「これをTier 0(セルフサービス)に落とせないか?」と問いかけましょう。目標は、各解決レイヤーが対応可能な最大数の問題を処理することです。
テスト済み Mar 15, 2026
チケット削減につながるセルフサービス体験を設計する
Help me design a self-service support experience for [product/service]. Current self-service: [what exists now] Top tasks customers need help with: [list 5-10 common tasks] Customer tech savviness: [beginner / intermediate / advanced] Support cost per ticket: [if known] Goal: [reduce ticket volume by X% / improve satisfaction] Design the self-service experience: 1. A self-service homepage layout with smart search and popular topics 2. Interactive troubleshooting wizards for the top 3 issues 3. A decision tree: self-service vs. contact support (when each is appropriate) 4. Video tutorial outlines for visual learners (5 most common tasks) 5. A community forum structure where customers help each other 6. Metrics to measure self-service success: deflection rate, satisfaction, and completion rate
プロのコツ
セルフサービスの「離脱率」を追跡しましょう――セルフサービスフローを開始したのに結局チケットを送信した顧客の割合です。離脱率が高い場合、セルフサービスコンテンツは見つかっているが問題を解決できていないということ。それはトラフィックの問題ではなく、コンテンツ品質の問題です。
テスト済み Mar 15, 2026
実際のテストに基づいています — 推測ではありません。 テスト方法を見る
Gemini 2.5 Pro
チャットボット設計、ナレッジベース構造、チケットトリアージシステムで最も論理的な設計を生成します。チームがすぐに実装できる構造化された自動化フレームワークに最も強いです。
アーキテクチャに最適GPT-4.1
最も自然なFAQ回答と、自動化感のない定型文を作成します。顧客が実際に読みたくなるサポートコピーに最も強いです。
コンテンツに最適Claude Sonnet 4
自身の限界を理解し、適切なタイミングで人間にルーティングする共感的な自動化を構築します。セルフサービスフローと多層型解決設計に最も強いです。
共感力に最適Grok 3
ロボットではなく人間味のある魅力的なチャットボットパーソナリティを設計します。顧客がやり取りを楽しめるウィットに富んだブランドに沿った自動応答を作成します。
ボットの個性に最適自動化すべきは回答であり、共感ではありません。ボットは情報を即座に届けられますが、人の気持ちに寄り添うことはできません。事実に基づく回答(注文状況、料金、使い方)には自動化を、感情的な場面(苦情、返金、謝罪)には人間を使いましょう。
チケット数ではなく、チケット回避率を測定しましょう。チャットボットが質問を「解決」しても顧客がすぐにチケットを起票する場合、それは自動化ではなく遅延です。セルフサービスを利用した顧客が本当にサポート不要になったかを追跡しましょう。
製品をアップデートする前にFAQをアップデートしましょう。新機能がリリースされる日はサポートチケットが急増する日です。ヘルプコンテンツはリリース後ではなくリリース前に書いて公開しましょう。AIなら製品仕様書からリリース前に記事を下書きできます。