この資料のパート分け

オリエン

• 案件の概要とフェーズ

前半

設計や設計に対する考え方レベルやアプローチレベル

後半

より具体的な処理方法に関する評価を元にした改善提案

オリエン

atoneカスタマーセンター向け AI（LLM）活用レビュー・改善支援案件

1. この案件は何だったのか（案件の性質）

本案件は、

ネットプロテクションズ社（以下 NP社）が atone カスタマーセンターにおいて導入・実装を進めていた LLM（生成AI）活用システムに対し、 Pronoun社が第三者視点からレビュー・設計提案・改善助言を行う PoC 支援案件である。

単なる技術検証やプロンプト調整ではなく、

• 実際に Zendesk 上で稼働し始めた AIシステム
• 実オペレーション・実顧客対応に使われる前提
• CS組織・業務プロセス・評価指標に影響を与える領域

を対象にした、**「実運用前提のAI設計レビュー案件」**という位置づけだった。

2. 案件開始時点での背景・前提

NP社側の背景

• 問い合わせ件数の増加
• 初回返信時間が長期化（30時間超）
• 人員増強だけでは解決しない構造的な負荷
• Zendesk 上での LLM 活用 PoC をすでに開始していた

既存のAI活用イメージ（初期状態）

• AIで一次回答を自動化したい
• FAQ・マニュアルを参照して「なるべく正しい回答」を返したい
• 自動化率・工数削減率をKPIとして設定したい
• AIは「人間の代替回答者」として期待されていた

3. Pronoun社の関与の仕方（立ち位置）

Pronoun社は、

• システムを実装する立場ではなく

• NP社のAI活用に対して

  **「レビュー」「壁打ち」「設計の言語化」「改善提案」**を行う立場

として関与した。

特徴的だったのは、

• 技術論だけでなく

• CS現場・顧客心理・業務構造を含めて議論した点

• 「AIをどう賢くするか」ではなく

  **「AIが事故らない設計にどう変えるか」**に焦点を当てた点

である。

4. 案件の進行フェーズ概要

本案件は、大きく 4つのフェーズを経て進行した。

フェーズ①：状況把握・前提のすり合わせ（2025年4月上旬）

主な内容

• NP社が想定している AI活用のゴール・KPI の確認
• 現在の Zendesk × LLM の実装内容の共有
• どこまでAIに任せたいか／任せたくないかの整理

この時点の重要論点

• 「一次回答とは何か？」
• 「AIが解決できないケースをどう扱うか？」
• 「工数50%削減という目標は妥当か？」

Pronoun社の初期指摘

• 正解率や工数削減だけを目標にすると、AIが無理をする
• 問い合わせの多くは情報不足であり、人でも一発解決できない
• まず AIの役割定義を再設計すべきという提起

フェーズ②：設計思想・認識の再定義（2025年4月中旬）

主な内容

• 「一次回答」の再定義
• AIの役割を「正解を出す存在」から「前捌き・整理役」へ変更
• 問い合わせを「カテゴリ」ではなく「解決段階」で捉える整理

具体的に行われたこと

• 解決段階4分類モデルの提示
• 情報不足をAIの主戦場とする考え方の提示
• カテゴリ起点設計の限界の言語化

このフェーズの成果

• AIに対する期待値が現実的になった
• 「AIができないからダメ」という評価軸から脱却
• 後続の具体設計議論の土台が整った

フェーズ③：具体的な処理・出力改善提案（2025年5月）

主な内容

• 実際の一次回答文面のレビュー
• AI明示／非明示、文面構成、返信タイミングの議論
• カテゴリ別に「AIでやる／やらない」の切り分け

特徴的な議論

• 冒頭文面は短くすべき
• 「自動返信」「AIです」は炎上リスクがある
• 情報不足時は答えず、聞く設計にする
• 即時返信が必ずしも最適ではない

成果物的アウトカム

• 一次回答テンプレート案の整理
• 処理タイプ別の出力方針の合意
• 「答えない判断」を含む処理設計の明確化

フェーズ④：運用・改善サイクル設計への拡張（5月下旬）

主な内容

• 出力が悪かった場合の改善方法の整理
• 文面修正ではなく、知識・判断ロジックの改善が重要という合意
• 内部FAQ・内部注意点の必要性の指摘

議論されたテーマ

• 本番出力レビューのやり方
• 改善サイクルの回し方（短いスプリント）
• 判断理由を残すことの重要性

結果

• 「AIは直しやすい」という前向きな運用認識が形成された
• 将来的に安定運用できる設計思想が共有された

5. この案件で得られた主な成果（アウトカム）

技術的成果ではなく「設計・運用知見」が主成果

本案件の成果は、

コードやモデルそのものではなく、以下のような知見・設計原則である。

• AIに期待してはいけない役割が明確になった
• AIが価値を出しやすい処理領域が定義された
• 一次回答・ヒアリング・人対応の切り分けが明確になった
• 出力事故を防ぐための具体的な処理設計が整理された

NP社側に残ったもの

• AI活用を進めるための共通言語
• PoCから本番に進むための判断軸
• 改善を継続できる運用視点

6. この案件の特徴を一言で言うと

「AIを入れる案件」ではなく、 『AIを入れた結果、CS業務をどう再設計するか』を 言語化し続けた案件」

である。

PoCの成否を決めたのは技術力ではなく、

• 無理な期待を外したこと
• AIが壊れない前提条件を作ったこと
• 人とAIの役割分担を現実的に設計したこと

だった。

7. 今後につながる位置づけ

この案件は、

• atone CC における LLM活用の基盤設計
• NP社内での横展開可能な知見
• 将来の高度化（内部DB参照・チャット化）への土台

として位置づけられる。

• *単発のPoC支援ではなく、

「AIを業務に組み込むための初期設計レビュー案件」**だったと言える。

前半

1. AIの位置づけに関する設計思想の変化

Before｜元々の設計・認識

AIは「問い合わせに正しい回答を返す存在」

• AIの価値は「人間に近い正解を出せるか」
• 一次回答＝できるだけ完全な回答を返すこと
• 正確性・網羅性が主な評価軸

暗黙の前提

• 解決できない回答は「弱いAI」
• 人がやっていることをAIに置き換えるのがゴール
• 正解率が上がれば満足度も上がるはず

Issue｜Pronoun社が指摘した問題

問い合わせ対応の現実とズレている

• 実際の問い合わせは情報不足が多い
• 人間でも一発で解決できないものが多い
• 正解を出すこと自体が不可能なケースが多い

AIに「できない役割」を期待している

• 判断材料が足りないのに断定を求められる
• 結果として

  • ハルシネーション

  • 不自然な長文

  • 顧客不信

    が発生しやすい

After｜変更提案（再定義）

AIは「業務を前に進める装置」

• 正解を出すことが役割ではない
• 状態遷移を起こすことが役割

一次回答の再定義

• 一次回答＝最初に返す「意味のある反応」
• 解決できなくても価値がある
• 人がやらなくていい一次反応をAIが担う

Resulting Design｜形成された設計思想

• AIの価値は「解決率」ではなく「前進率」
• 人とAIは役割分担する存在
• AIは前捌き・整理・仕分け役

2. AI出力の評価軸に関する変化

Before｜元々の評価観

出力の良し悪し＝正しいかどうか

• FAQに沿っているか
• 表現が丁寧か
• 誤情報がないか

評価指標

• 正解率
• 人との一致率

Issue｜Pronoun社の問題提起

正解かどうかを測れない問い合わせが多い

• 情報不足
• 状況不明
• 顧客の言語化不足

人間でも正解が出せないのにAIに求めている

• 評価軸そのものが破綻している
• AIが過剰に喋る原因になっている

After｜変更提案

評価軸を「段階適合性」に変更

• 今その問い合わせはどの段階か
• その段階でやるべき振る舞いをしているか

Resulting Design

• 良い出力＝
  • 情報不足なら聞き返す
  • 明確なら答える
• 悪い出力＝
  • 情報不足なのに断定する

3. 問い合わせ処理モデルの変化（アルゴリズム設計）

Before｜元々の処理イメージ

カテゴリごとに回答を出す

• ログイン
• 請求
• キャンセル

想定フロー

• カテゴリ判定
• 該当FAQ参照
• 回答生成

Issue｜Pronoun社の指摘

カテゴリは「建具」にすぎない

• 同じカテゴリでも状況はバラバラ
• 温度感・緊急度・情報量が違う

カテゴリ起点だと事故る

• 高温度の顧客に機械的回答
• 情報不足に断定回答

After｜変更提案

問い合わせを「解決段階」で捉える

解決段階①

• 情報明確 → 完全回答

解決段階②

• 情報不足 → ヒアリング

解決段階③

• 内部情報必要 → 内部参照

解決段階④

• 緊急性あり → 人へ通知

Resulting Design

• カテゴリは補助情報
• 主軸は「状態」と「段階」

4. 情報不足に対する認識の転換

Before｜元の認識

情報不足＝難しい・面倒

• 人でも時間がかかる
• AIには向いていない

Issue｜Pronoun社の再解釈

情報不足はAIが最も得意

• 聞き返しは機械的でよい
• 聞きすぎてもリスクが低い
• 人より心理的負担が少ない

After｜変更提案

情報不足はAIの主戦場

• 不足検知ロジックを最重要に
• 足りなければ即ヒアリング

Resulting Design

• AI＝前捌き・準備役
• 人＝判断・説明役

5. 出力文面設計に関する変化

Before｜元の方針

丁寧で網羅的な文章

• 冒頭説明が長い
• AIであることを明示
• 責任回避的な文言

Issue｜Pronoun社の指摘

読まれない・燃える

• 冒頭が長いと読まれない
• 「自動返信」「AIです」は炎上ワード
• 顧客の感情を刺激する

After｜変更提案

文面設計の原則

• 冒頭は短く
• 要件確認から入る
• AI明示は目的に応じて出し分け

Resulting Design

• 「独自のシステムによる状況判断」という表現
• 次アクションを明示
• 感情を悪化させない構成

6. 改善アプローチに関する変化

Before｜元の改善観

出力が悪い → 文面修正

• プロンプトを直す
• 表現を調整する

Issue｜Pronoun社の指摘

根本原因は知識不足

• FAQが悪い
• 暗黙知が共有されていない
• AIはそれを正直に反映しているだけ

After｜変更提案

改善の正しい順序

1. 本番出力を眺める
2. 共通欠損を抽出
3. ナレッジ補強
4. 最後に文面調整

Resulting Design

• 出力改善＝知識構造改善
• 文面修正は最終手段

7. AIと人の役割分担の変化

Before｜元の前提

AIができない＝人がやる

• 振り分けは人の仕事
• 経験者の勘に依存

Issue｜Pronoun社の提案

AIは判断材料を作れる

• 難易度判定
• 緊急度判定
• 情報充足度判定

After｜変更提案

AI出力を業務制御に使う

• 人への割り当て
• 優先度制御

Resulting Design

• AI＝業務オーケストレーター
• 人＝責任主体

後半

問い合わせ受信直後の処理方法の変更

Before｜元の処理

• 問い合わせ文面を受信
• カテゴリ判定
• 該当FAQを参照
• 回答生成

After｜変更提案

• 問い合わせ文面を受信
• 情報充足度判定
• 緊急度・温度感判定
• その結果に応じて

  • 回答生成

  • ヒアリング生成

  • 人アサイン判定

    を分岐

Why

• カテゴリだけでは処理判断ができない
• 情報不足や高温度を無視した処理は事故る

Effect

• 不適切な即答の減少
• 初手ミスによるラリー増加の防止

情報不足時の処理方法の変更

Before

• 情報不足でも可能な限り回答を生成
• 不足情報があっても断定的な文面になりがち

After

• 情報不足フラグを立てる
• 回答生成を行わず
• ヒアリング専用プロンプトで質問生成
• 選択肢形式・箇条書きを優先

Why

• 情報が足りない状態での回答は精度が出ない
• 聞き返しはAIが最も安全にできる処理

Effect

• ハルシネーション抑制
• 人の再確認工数削減

一次回答生成ロジックの変更

Before

• 一次回答＝なるべく完全な回答を生成

After

• 一次回答を以下に分離
  • 即答型一次回答
  • ヒアリング型一次回答
  • 前捌き型一次回答（人対応前提）

Why

• 一次回答に「完全解決」を求めると無理が出る
• 処理目的に応じた出力が必要

Effect

• 一次回答の成功率向上
• 不自然な長文の減少

出力生成前の「答える／答えない」判定追加

Before

• 回答生成が基本動作
• 出さない判断は人が行う

After

• 出力前に以下を判定
  • 答えられるか
  • 聞くべきか
  • 人に渡すべきか
• 「答えない」という出力判断をAIに持たせる

Why

• すべてに答えようとするのが事故の原因
• 答えない判断も重要な処理

Effect

• 誤回答の削減
• クレーム抑制

出力文面構成ロジックの変更

Before

• 1つのテンプレートで全ケース対応
• 冒頭説明が長くなりがち

After

• 文面を以下で分解
  • 冒頭（要件確認）
  • 本文（回答 or ヒアリング）
  • 次アクション案内
• 処理タイプごとに文面構成を切り替える

Why

• 同じ構成だと読まれない
• 処理目的によって最適な文章構造は異なる

Effect

• 読了率向上
• 次アクション実行率向上

AI明示／非明示の処理切り替え

Before

• 一律でAI／自動返信を明示 or 非明示

After

• 処理タイプで切り替え
  • ヒアリング型 → 明示
  • 完全回答型 → 非明示
• 文面生成時にフラグで制御

Why

• 明示が有効なケースと逆効果なケースがある

Effect

• 不信感・炎上リスク低下

回答生成タイミングの制御追加

Before

• 即時返信が基本

After

• 処理タイプに応じて

  • 即時

  • 数分遅延

  • バッチ的送信

    を制御

Why

• 早すぎる返信はAI感が強い
• UXとして違和感が出る

Effect

• 顧客心理の安定
• AI検知による反発軽減

カテゴリ依存処理の縮小

Before

• カテゴリごとに処理・回答を定義

After

• カテゴリは補助情報
• 実処理は

  • 状態（情報量・温度感・緊急度）

    を主軸に分岐

Why

• カテゴリ内のばらつきが大きい
• 状態ベースの方が再利用性が高い

Effect

• 処理ロジックの単純化
• 新カテゴリ追加時の負荷低減

AI出力結果の二次利用（ルーティング）

Before

• 出力文面のみを生成
• 担当者割当は人手

After

• 出力と同時に

  • 難易度スコア

  • 緊急度フラグ

    を生成

• Zendeskのルーティングに利用

Why

• AIは仕分けが得意
• 人がやると属人化する

Effect

• ベテラン工数の最適配分
• 対応遅延の防止

出力失敗時の改善フロー変更

Before

• 出力が悪い → 文面修正・プロンプト修正

After

• 出力が悪い →

  ① 情報不足か？

  ② ナレッジ欠損か？

  ③ 処理判断ミスか？

  を切り分け

• 文面修正は最後

Why

• 文面修正は対症療法
• 根本原因は知識・処理設計にあることが多い

Effect

• 改善サイクル短縮
• 無駄なチューニング削減

内部・外部出力の分離処理

Before

• 同一知識をそのまま出力に使用

After

• 内部用ナレッジと外部出力を分離
• 出力前に
  • 外部OK情報のみ抽出
• 内部注意点はAIの判断材料にのみ使用

Why

• 顧客に見せてはいけない情報がある
• 事故防止のため

Effect

• 表現事故・説明過多の防止
• 将来的な安定運用