コールセンターマニュアルの作り方　人もAIも迷わない5つの書き方

コールセンターの応対マニュアルは、1項目に1つの用件だけを書き、その項目だけを切り出して読んでも意味が通るように作ります。新人オペレーターは通話中に検索して該当箇所だけを読みますし、生成AIの回答支援（RAG。社内文書を検索して回答を組み立てるしくみ）も文書を細かく切って一部だけを読みます。どちらも「前のページから順に読む」ことをしない読者です。だから、項目ごとに前提を書き直す重複を嫌わないこと。これが本稿でいちばん言いたいことです。

先に役割の線を引いておきます。トークスクリプトは「何をどの順で話すか」の台本で、作り方はトークスクリプトの作り方の記事で扱いました。マニュアルは「この用件では何を確かめ、何を判断し、何をしてよいか」の規則集です。台本が会話の流れを持ち、マニュアルが判断の根拠を持つ。以下の5つの書き方は、この規則集の側の話です。

1項目に1用件を書き、結論から始める

最初に決めるのは項目の単位です。「解約」「住所変更」「請求額の問い合わせ」のように、顧客が電話してくる用件1つを1項目にします。1つの項目に「住所変更と支払い方法の変更」を同居させると、検索でヒットしても読む側が自分の用件の部分を探し直すことになります。

項目の中は、結論を先に置きます。文化審議会が2022年に建議した公用文作成の考え方は、文書の結論はできれば最初の段落で示し、理由や詳細は次の段落から説明するよう求めています。マニュアルでいえば、項目の1行目は「受け付けてよいか、誰に回すか」の判断です。経緯や制度の背景は後ろに回します。

通話中のオペレーターが読めるのは、最初の数行までと見て設計します。そこに判断がなければ、マニュアルは開かれなくなります。

項目だけを切り出しても読めるように前提を書き直す

ここが人向けの文書作法といちばんぶつかる点です。紙のマニュアルでは「前述のとおり」「上記の条件を満たす場合」と書いて重複を避けるのが行儀のよい書き方でした。検索して読む読者にとって、この書き方は前提を失わせます。

生成AIの検索ではこの問題がはっきり数字に出ています。Anthropicが2024年9月に公開したContextual Retrievalの検証では、「前四半期比で売上が3%伸びた」という一文だけを切り出しても、どの会社のいつの話か分からず検索で拾えない例を挙げています。同社によると、各断片に文書の文脈を書き足してから検索させたところ、上位20件に正解が入らない割合が5.7%から2.9%に下がりました（キーワード検索との併用時、49%減）。検索サービスの側も同じ問題を前提にしています。Microsoftの文書分割の解説は、長い文書の途中から切り出した断片に文書タイトルを付け足して文脈が失われるのを防ぐ方法を挙げ、Google Cloudの文書分割の設定には、各断片に上位の見出しを含める選択肢があります（既定は含めない設定）。

つまり、ツール側で見出しを足してくれる場合もありますが、それは設定次第です。書き手の側でできることは単純で、各項目に「対象の商品・顧客区分」「この項目が使える条件」を1行ずつ書き直すことです。「上記」「前述」「同様に」は使わない。

重複が増えれば、改定のときに直す箇所も増えます。その手間は、項目ごとに版と更新日を持たせて台帳で追うことで引き受けます。更新体制の決め方はFAQ・ナレッジ更新体制の記事にまとめています。

見出しは顧客の言い方で付け、用語を揃える

見出しは、社内の業務名ではなく顧客が口にする言い方で付けます。「契約終了手続き」より「解約したい」。「名義変更」より「契約者を家族に変えたい」。オペレーターは顧客の言葉をそのまま検索窓に打つことが多く、生成AIも顧客の発話から検索語を作ります。社内用語は見出しの下に1行、「社内呼称: 契約終了手続き」と添えれば両方から引けます。

同じものを項目ごとに違う言葉で呼ばないことも、見出しと同じくらい効きます。「解約」「退会」「契約終了」が混在していると、人は同じものか迷い、検索は別物として扱います。公用文作成の考え方は、見出しを追えば全体の内容がつかめるようにすること、略語は元の用語を示してから使うことを挙げています。マニュアルの冒頭に用語表を1枚置き、正式な語と言い換えの語を並べておくと、新しく書く人も揃えやすくなります。

条件分岐は表にし、適用条件を項目の情報として持つ

「会員ランクがゴールド以上で、かつ購入から30日以内なら返品を受ける。ただし開封済みは除く」。この種の条件を文章で書くと、人は読み飛ばし、AIは条件の一部を落として答えます。分岐が2つ以上ある規則は表にします。行が条件の組み合わせ、列が対応です。

条件（例）	未開封	開封済み
購入から30日以内	返品可。返送伝票を案内	返品不可。初期不良なら交換窓口へ転送
購入から31日以降	返品不可。理由を聞きSVへ相談	返品不可

※日数や区分は説明用の例です。

もう1つ、項目そのものに「いつから・いつまで有効か」「どの商品・地域・顧客区分に効くか」を情報として持たせます。旧料金の項目と新料金の項目が同じ重みで並んでいると、人もAIも古いほうを拾います。AWSは2024年3月にナレッジベースのメタデータ絞り込みを発表し、特定の州に関する文書だけを検索対象にする例を示しました。製品によって呼び方は違いますが、有効期間と対象を項目の外枠に書いておけば、後から絞り込みに使えます。書いていない情報では絞り込めません。

言い回しは型と禁止事項だけを書き、全文の台本にしない

応対マニュアルに一字一句の言い回しまで書き込むと、項目が長くなり、判断の部分が埋もれます。文化審議会の敬語の指針は、いわゆる「マニュアル敬語」について、接客マニュアルは不慣れな人の手引として有効だとしたうえで、示した表現を唯一絶対のものとして扱うことは避けるよう求めています。いつでも誰にでも同じ表現を使うと、かえって顧客に不快な思いをさせやすいという指摘です。

マニュアルに書くのは、言い回しの型を1つか2つと、言ってはいけないことです。「お約束はできかねます」の型を置き、「必ず」「絶対に」「すぐに届きます」は使わない、と書く。言ってはいけないことのほうは、AIに下書きを作らせるときの指示としてもそのまま使えます。全文の台本が要る用件は、トークスクリプトの側に分けます。

5つを1項目に当てはめたテンプレート

5つの書き方を1項目に当てはめると、次の形になります。各社の様式に合わせて欄名は変えてかまいません。

【見出し】解約したい（社内呼称: 契約終了手続き）
【結論】本人確認のうえ電話で受付可。違約金が発生する契約は受付前に金額を伝える
【対象】個人契約の月額プラン（法人契約は「法人の解約」項目へ）
【有効期間】2026年4月1日〜（改定時に更新）
【確認すること】契約者本人か／契約期間の残り／未払いの有無
【判断の表】（条件分岐がある場合のみ）
【してはいけないこと】引き止め特典をこちらから提示しない／解約日を確約しない
【転送先】未払いがある場合は料金担当へ
【版・更新日・責任者】v3／2026-04-01／品質管理チーム

※項目の中身はすべて説明用の例です。

書き換え前と後も並べておきます。

• 書き換え前: 「前述の条件を満たす場合は、上記と同様に手続きを行う。ただし例外あり（別紙参照）。」
• 書き換え後: 「個人契約の月額プランで、契約者本人と確認できた場合は、電話で解約を受け付けます。法人契約は『法人の解約』の項目に従います。」

書き換え後の文は、この1文だけが検索で出てきても、誰が・何を・どの条件でしてよいかが分かります。AIに読ませる準備ができたかどうかは、正解の項目に検索が届くかで確かめます。確かめ方はRAGの検索精度を評価する記事で手順にしました。

まとめ

• 1項目に1用件。1行目に判断を書き、背景は後ろに回す
• 「前述」「上記」を使わず、対象と条件を項目ごとに書き直す。重複の手間は版管理で引き受ける
• 見出しは顧客の言い方で付け、用語表で言葉を揃える
• 分岐は表にし、有効期間と対象を項目の情報として持つ
• 言い回しは型と禁止事項にとどめ、台本はトークスクリプトに分ける

いまのマニュアルから1項目を選び、その項目だけを新人に渡したとき、誰に何をしてよいかが伝わるでしょうか。

よくある質問

マニュアルとトークスクリプトは1つの文書にまとめてもよいですか。

分けます。マニュアルは判断の根拠、トークスクリプトは話す順番を持つ文書で、更新のきっかけも頻度も違うためです。項目から対応するスクリプトへリンクを張れば、行き来はできます。

AIに読ませるために、人向けとは別のマニュアルを作るべきですか。

作らなくてよいと考えています。1項目1用件、結論が先、前提を項目内に書く、という書き方は、検索して読む人にもAIにも同じように効きます。2つ持つと、片方だけが更新される事故が起きます。

PDFやExcelの既存マニュアルはそのままAIに読ませられますか。

読み込み自体はできる製品が多いものの、表の結合セルや「別紙参照」は分割の段階で意味を失いやすくなります。見出し付きのテキストや表の形に直してから入れるほうが、検索で拾われる精度を確かめやすくなります。

1項目はどのくらいの長さが目安ですか。

決まった字数はありません。目安は、通話中に1画面でスクロールせず判断までたどり着けることです。長くなった項目は、用件が2つ混ざっていないかを先に疑います。

注記

確認日: 2026年10月16日。本稿は公開情報にもとづく編集部の実務整理で、本文中のテンプレート・表・書き換え例の数字や条件は説明用の例です。Anthropicの検索精度の数字は同社が自社の検証条件で測った値で、どの環境でも同じ改善幅になるとは限りません。各社の検索サービスの機能名や既定値は確認日時点の公式ドキュメントによります。特定の製品を推奨するものではありません。

---

出典

• 文化審議会「公用文作成の考え方（建議）」
• 文化審議会「敬語の指針（答申）」
• Anthropic「Introducing Contextual Retrieval」
• Microsoft Learn「Chunk Documents - Azure AI Search」
• Google Cloud「Parse and chunk documents」
• AWS「Knowledge Bases for Amazon Bedrock now supports metadata filtering」

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。