0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Miraigent(Kazuya Kirisaki)

AI運用ログから改善バックログをGoogleスプレッドシートとGASで作る

0
Posted at

この記事は、AI問い合わせ対応やAI要約の運用ログから、次に直すべき改善バックログを作るための実装メモです。

AI APIの呼び出し、顧客への自動送信、CRM本番更新は扱いません。GoogleスプレッドシートとGASで、ログに残った「止まった理由」を集計し、FAQ、フォーム、CRM、承認ルールへ戻すための一覧を作ります。

作るもの

Googleスプレッドシートに、次の3枚を作ります。

  • ai_ops_log: AI利用や人間確認の記録
  • improvement_rules: 改善先を決めるルール
  • improvement_backlog: 次に直す候補

完成形は、AIを使った件数を増やすための表ではありません。

同じ理由で止まった対応を見つけ、FAQを直すのか、フォーム項目を直すのか、CRM項目を足すのか、承認ルールを見直すのかを決めるための小さな運用台帳です。

AI運用の入口と確認ゲート

なぜ改善バックログを作るのか

AI運用ログには、成功した処理だけでなく、止まった理由が残ります。

  • 顧客情報が足りず要約できなかった
  • 金額や契約に関わるため人間確認に戻した
  • 同じ質問が多いのにFAQがなかった
  • フォーム項目が自由記述だけで分類できなかった
  • 承認者が未設定で返信下書きが滞留した

このログをそのまま眺めるだけだと、毎週同じ確認作業が増えます。

改善バックログに変換すると、「AIが苦手だった」ではなく「入口の情報が足りない」「ルールが曖昧」「FAQに戻せる」という形で次の作業にできます。

ai_ops_log シート

まず、AI利用や人間確認の記録を残すシートを用意します。

列 項目 例 用途
A logged_at 2026/07/08 10:00 記録日時
B request_id INQ-20260708-001 問い合わせID
C use_case inquiry_summary AI利用の種類
D source_channel form 受付経路
E category pricing 分類
F result hold completed / hold / rejected
G hold_reason missing_required_field 止まった理由
H human_review_required yes 人間確認の有無
I reviewer support_owner 確認者
J next_action update_faq 次の行動
K note 料金条件が未整理 補足

ポイントは、本文や顧客情報を細かく残しすぎないことです。

改善に使いたいのは、個別の問い合わせ本文ではなく、どの理由で止まったか、どの入口を直すべきかです。

improvement_rules シート

次に、止まった理由を改善先へ変換するルールを置きます。

列 項目 例
A rule_id RULE-001
B enabled yes
C hold_reason missing_required_field
D category any
E backlog_type form
F priority high
G owner ops_owner
H title_template フォーム必須項目を見直す

最初から複雑なルールエンジンにしなくて大丈夫です。

まずは hold_reason と category から、改善先を次のように分けます。

backlog_type 意味
faq FAQや定型回答へ戻す
form フォーム項目や選択肢を見直す
crm CRMに残す項目を追加する
approval_rule 承認者や確認条件を見直す
prompt_or_template 要約テンプレートや下書きテンプレートを直す

improvement_backlog シート

改善候補は、次の列で作ります。

列 項目 例
A backlog_id BK-20260708-001
B created_at 2026/07/08
C backlog_type faq
D priority high
E title 料金条件のFAQを追加する
F reason_count 4
G sample_request_ids INQ-001, INQ-007
H owner ops_owner
I status open
J due_date 2026/07/15
K source_reason unclear_pricing

1件ごとにバックログ化すると、細かすぎて運用されません。

同じ hold_reason と category をまとめ、件数が多いものから候補にします。

GASの実装

以下は、ai_ops_log と improvement_rules から improvement_backlog を作る最小例です。

const SHEETS = {
  log: 'ai_ops_log',
  rules: 'improvement_rules',
  backlog: 'improvement_backlog',
};

function buildImprovementBacklog() {
  const ss = SpreadsheetApp.getActive();
  const logs = readObjects_(ss.getSheetByName(SHEETS.log));
  const rules = readObjects_(ss.getSheetByName(SHEETS.rules))
    .filter((rule) => String(rule.enabled).toLowerCase() === 'yes');
  const backlogSheet = ss.getSheetByName(SHEETS.backlog);

  const groups = new Map();

  logs
    .filter((log) => ['hold', 'rejected'].includes(String(log.result)))
    .forEach((log) => {
      const rule = findRule_(rules, log);
      if (!rule) return;

      const key = [
        rule.backlog_type,
        rule.priority,
        rule.owner,
        log.hold_reason,
        log.category || 'any',
      ].join('|');

      const current = groups.get(key) || {
        backlog_type: rule.backlog_type,
        priority: rule.priority,
        owner: rule.owner,
        title: renderTitle_(rule.title_template, log),
        source_reason: log.hold_reason,
        request_ids: [],
      };

      current.request_ids.push(log.request_id);
      groups.set(key, current);
    });

  const now = new Date();
  const rows = [...groups.values()]
    .filter((item) => item.request_ids.length >= 2)
    .map((item, index) => [
      makeBacklogId_(now, index + 1),
      now,
      item.backlog_type,
      item.priority,
      item.title,
      item.request_ids.length,
      item.request_ids.slice(0, 5).join(', '),
      item.owner,
      'open',
      addDays_(now, item.priority === 'high' ? 7 : 14),
      item.source_reason,
    ]);

  if (rows.length === 0) return;

  backlogSheet
    .getRange(backlogSheet.getLastRow() + 1, 1, rows.length, rows[0].length)
    .setValues(rows);
}

function findRule_(rules, log) {
  return rules.find((rule) => {
    const reasonMatches = rule.hold_reason === log.hold_reason;
    const categoryMatches = rule.category === 'any' || rule.category === log.category;
    return reasonMatches && categoryMatches;
  });
}

function readObjects_(sheet) {
  const values = sheet.getDataRange().getValues();
  const headers = values.shift();
  return values
    .filter((row) => row.some((cell) => cell !== ''))
    .map((row) =>
      Object.fromEntries(headers.map((header, index) => [header, row[index]]))
    );
}

function renderTitle_(template, log) {
  return String(template || '改善候補を確認する')
    .replace('{category}', log.category || '未分類')
    .replace('{hold_reason}', log.hold_reason || '未設定');
}

function makeBacklogId_(date, number) {
  const ymd = Utilities.formatDate(date, 'Asia/Tokyo', 'yyyyMMdd');
  return `BK-${ymd}-${String(number).padStart(3, '0')}`;
}

function addDays_(date, days) {
  const copied = new Date(date.getTime());
  copied.setDate(copied.getDate() + days);
  return copied;
}

重複登録を防ぐ

実運用では、同じ改善候補を毎週作らないようにします。

最小構成なら、backlog_type、source_reason、category、status を見て、open のものがあれば件数だけ更新します。

function upsertBacklogRows_(sheet, newRows) {
  const existing = readObjects_(sheet);
  const openKeys = new Set(
    existing
      .filter((row) => row.status === 'open')
      .map((row) => [row.backlog_type, row.source_reason, row.title].join('|'))
  );

  const rowsToAppend = newRows.filter((row) => {
    const key = [row[2], row[10], row[4]].join('|');
    return !openKeys.has(key);
  });

  if (rowsToAppend.length === 0) return;

  sheet
    .getRange(sheet.getLastRow() + 1, 1, rowsToAppend.length, rowsToAppend[0].length)
    .setValues(rowsToAppend);
}

上の例は、既存行の更新までは行いません。まずは重複作成を防ぎ、必要になったら reason_count を更新する処理を足します。

週次レビューの見方

改善バックログは、作っただけでは意味がありません。

週に1回、次の順番で見ます。

  1. priority が high の open 行を見る
  2. reason_count が多いものを見る
  3. FAQ、フォーム、CRM、承認ルールのどこを直すか決める
  4. 修正したら status を done にする
  5. 次週の hold_reason が減ったか確認する

AIの精度だけを見ても、運用の詰まりは消えません。

問い合わせフォームの項目が足りないならフォームを直します。毎回同じ質問が来るならFAQへ戻します。承認者が曖昧なら承認ルールを直します。

入れてはいけないもの

改善バックログには、次の情報を入れない方が安全です。

  • 顧客名、個人名、メールアドレス、電話番号
  • 問い合わせ本文の原文
  • 契約、返金、法務判断の詳細
  • APIキー、Cookie、トークン、内部URL
  • 未確認の成果保証や売上効果

バックログに必要なのは、改善すべき型です。個別の顧客情報ではありません。

まとめ

AI運用ログは、利用件数を数えるだけだとすぐに形骸化します。

止まった理由を集計し、FAQ、フォーム、CRM、承認ルールへ戻せる改善バックログにすると、AI導入後の確認作業を減らしやすくなります。

Miraigentでは、AIを入れる前後の業務設計、問い合わせ導線、確認ルール、運用ログの整理をまとめて確認しています。まずは1週間分の hold_reason を集め、同じ理由が2件以上あるものから改善候補にするのがおすすめです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?