02. 運用計画
2.1 運用の考え方
FAQ Builder の運用は「自動処理は止まらないようにする」「人の判断は溜めない」の 2 点に集約されます。
FAQ が陳腐化する最大の原因は、生成が止まることではなくレビューが溜まって誰も見なくなることです。そのため本計画では、人の作業を「1 日 15 分の承認」まで細かく割り、WIP 上限と自動エスカレーションで滞留を構造的に防ぎます。
定常運用時の人の総工数は 月 約 12 時間（約 6.0 万円） です。開発担当の工数（Q3 以降 0.2 人月/月）は別枠です。
| 内訳 | 時間/月 | 担当 |
|---|---|---|
| 日次レビュー（15 分 × 20 日） | 5.0 h | ナレッジオーナー ×2 |
| 週次レビュー会（30 分 × 4） | 2.0 h | ナレッジオーナー ×2、開発担当 |
| 月次 KPI レビュー（60 分） | 1.0 h | 全役割 |
| 四半期棚卸（4 h ÷ 3） | 1.3 h | 部門リード |
| 臨時対応・障害対応の見込み | 2.7 h | 全役割 |
| 合計 | 12.0 h | サービスオーナー 1.5 h ／ ナレッジオーナー計 8.0 h ／ 部門リード 2.5 h |
2.2 運用サイクル
| サイクル | 頻度 | 所要 | 実施内容 |
|---|---|---|---|
| 日次 | 毎日 | 自動 ＋ 15 分 | パイプライン自動実行、レビューキュー通知、草案の承認/却下 |
| 週次 | 月曜 | 30 分 | 未処理草案の棚卸、却下理由の分類、新規カテゴリの確認、滞留の強制トリアージ |
| 月次 | 第 1 営業日 | 60 分 | KPI レポート、API コスト実績と上限見直し、訂正事案レビュー、翌月の重点カテゴリ決定 |
| 四半期 | 四半期初 | 半日 | FAQ 全件の鮮度棚卸、カテゴリ体系の再編、ゴールデンセット更新、モデル/プロンプトの版上げ判断 |
日次の自動処理スケジュール
すべて worker コンテナの cron で実行します。Batch API を使うため、投入から結果取得まで時間差があることを前提に組んでいます。
| 時刻 | ジョブ | 内容 | 失敗時 |
|---|---|---|---|
| 02:00 | ingest |
updated_at ウォーターマーク以降の差分ノートを抽出 |
3 回リトライ → Sev2 |
| 02:10 | normalize |
引用・署名除去、個人情報マスキング | 3 回リトライ → Sev2 |
| 02:30 | extract:submit |
Haiku 4.5 の Batch ジョブを投入 | 3 回リトライ → Sev2 |
| 03:30 | extract:collect |
Batch 結果を回収して質問レコードを作成 | 未完なら 30 分後に再試行（最大 4 回） |
| 04:00 | cluster |
ローカル埋め込み ＋ FTS5 で名寄せ | 3 回リトライ → Sev2 |
| 04:30 | draft:submit |
Sonnet 5 の Batch ジョブを投入（新規・更新クラスタのみ） | 3 回リトライ → Sev2 |
| 05:30 | draft:collect ＋ verify |
草案回収、根拠整合チェック、信頼度スコア付与 | 未完なら 30 分後に再試行 |
| 06:00 | freshness |
review_due 到来分を stale に落とす |
3 回リトライ → Sev3 |
| 06:30 | metrics |
KPI とトークン消費を faq_metrics に記録 |
3 回リトライ → Sev3 |
| 09:30 | notify |
レビューキューを Chatwork の運用ルームへ通知 | 通知失敗は Sev2 |
日次バッチが 2 日連続で失敗した場合は Sev1 として即時対応します（§2.7 監視とアラート を参照）。
2.3 レビュー・承認の運用
1 日 15 分の作業内容
09:30 に Chatwork へ届く通知には、信頼度スコアの高い順に草案が並んでいます。担当者は上から順に見て、1 件 3 分を目安に承認・却下・修正を判断します。5 件で 15 分です。
判断は品質ゲートの 4 条件に当てはめるだけで、文章を書き直す必要はありません。書き直しが必要な草案は却下してプロンプト改善の材料に回します。
品質ゲート（4 項目すべて必須）
| # | 条件 | 確認方法 |
|---|---|---|
| ① | 根拠となる原文が 2 件以上ある | source_ids のリンクを開いて元の会話を確認 |
| ② | 個人情報・顧客固有条件が残っていない | 本文に社名・人名・金額・URL が無いか目視 |
| ③ | 回答が現行の運用ルールと矛盾しない | 料金・納期・規約に関わる記述は特に注意 |
| ④ | 担当オーナーと次回レビュー期日が入っている | owner / review_due が空でないこと |
サービスレベル（社内合意）
| 項目 | 水準 |
|---|---|
| 草案の提示 | 受信の翌営業日 09:30 まで |
| 初回レビュー | 提示から 3 営業日以内 |
| 滞留の強制処理 | 7 日超で部門リードへ自動エスカレーション |
| 公開 FAQ の鮮度 | 90 日以内に再評価 |
滞留を防ぐ 3 つの仕掛け
- WIP 上限 20 件 —
review状態が 20 件を超えたら、新規草案の生成を一時停止します。生成を止めてでもキューを空にする方を優先します - 7 日ルール —
draftのまま 7 日を超えた草案は部門リードのキューへ自動で移り、週次会で「公開する / 捨てる」を必ず決めます - 却下も成果 — 却下は失敗ではなくプロンプト改善の入力です。却下理由を 5 分類（根拠不足 / 一般化しすぎ / 顧客固有 / 内容が古い / 重複）で記録し、月次で集計します
2.4 品質管理
ゴールデンセットによる継続評価
Q1 で 質問 100 件に人が正解を付けた固定データセットを作り、以降はプロンプトやモデルを変えるたびにこれで回帰テストします。
| 評価対象 | 指標 | 合格ライン |
|---|---|---|
| 質問抽出（③） | 適合率（抽出したものが実際に質問か） | 80% 以上 |
| 質問抽出（③） | 再現率（質問を取りこぼしていないか） | 70% 以上 |
| 名寄せ（④） | 正しいクラスタに入った割合 | 75% 以上 |
| 草案生成（⑤） | 人が承認できる水準の割合 | 70% 以上 |
| マスキング（②） | 個人情報の除去漏れ | 0 件（1 件でも不合格） |
マスキングの除去漏れは 1 件でも不合格とし、修正するまで本番のバックフィルを再実行しません。
訂正が発生したときの扱い
公開済み FAQ の内容が誤っていたと判明した場合は、次の手順で処理します。
- 該当 FAQ を即時
archivedに落とす（検索・提示の対象から外す） - 誤情報の影響範囲（その FAQ を根拠に回答した案件）を
used_countと回答ログから特定する - 原因を 3 分類（元データが誤り / 生成の誤り / レビューの見落とし）で記録する
- 月次レポートに全件を載せ、レビューの見落としが原因のものは品質ゲートの運用を見直す
訂正率の目標は 公開記事数の 2% 以下です。
2.5 セキュリティと個人情報の取り扱い
| 論点 | 方針 |
|---|---|
| 外部 API に渡すもの | マスキング済みの本文のみ。顧客名・個人名・メール・電話・金額・URL は伏字 |
| 外部 API に渡さないもの | 原文、顧客マスタ、案件の金額、Contacts/ の連絡先 |
| 復元 | vault 内の参照 ID でのみ行う。FAQ 本文に復元情報は書かない |
| 監査ログ | 送信したテキストのハッシュと文字数、モデル、トークン数を jobs テーブルに残す |
| データ保持 | Batch API の入出力は回収後に削除。ローカルには結果の構造化データのみ保持 |
| アクセス制御 | FAQ ノートは vault 内。既存 synon-cole の権限（admin / member）に従う |
| 顧客固有情報 | customer_specific: true の FAQ は社内限定。公開昇格の対象外 |
マスキング規則は Q1 で確定させ、ゴールデンセットの一部として除去漏れゼロを継続的に検証します。
2.6 コスト管理
| 統制 | 内容 |
|---|---|
| 月次上限 | $30。超過時は draft:submit と extract:submit を自動停止し Sev2 アラート |
| 日次記録 | モデル別・工程別のトークン数と概算費用を faq_metrics に記録 |
| 80% 警告 | 上限の 80%（$24）到達で Sev2 通知。残り日数と消費ペースを添える |
| Batch 優先 | バッチ処理可能な工程は必ず Batch API（50% 割引）を使う |
| キャッシュ | 検索・回答支援の FAQ コーパス部分はプロンプトキャッシュを適用（読み出しは基本入力の 0.1 倍） |
| 月次レビュー | 実績と試算の乖離が 1.5 倍を超えたら原因分析と上限見直し |
定常時の想定は月 $17.79、上限は $30。バックフィルの再実行が必要になった月のみ一時的に上限を引き上げます。
2.7 監視とアラート
通知先は Chatwork の運用ルームです。重大度に応じて宛先と初動を変えます。
| 重大度 | 状態 | 検知条件 | 初動 |
|---|---|---|---|
| Sev1 | 止まっている | 日次バッチが 2 日連続で失敗 / vault への書き込みが破損 / 個人情報の流出が疑われる | 即時通知。当日中に一次対応。開発担当＋サービスオーナーへ直接メンション |
| Sev2 | 劣化している | 草案生成の成功率が 80% 未満 / API 月次コストが上限の 80% 超 / レビュー滞留が 7 日超 | 翌営業日に確認。週次会で対応判断 |
| Sev3 | 気づいておく | 承認率が前月比 10pt 以上低下 / 新規カテゴリが 3 件以上発生 / 参照 0 件の FAQ が 50 件超 | 月次レポートに記載。即時対応は不要 |
計測は SQLite の jobs / faq_metrics テーブルから日次で集計します。ダッシュボードは既存 synon-cole の管理画面に 1 タブ追加するだけで済ませ、新しい監視基盤は導入しません。
2.8 障害対応 Runbook
R-01 日次バッチが失敗した
jobsテーブルで失敗ジョブのerrorを確認する- 失敗が
extract:collect/draft:collectの場合、Batch ジョブがまだ処理中の可能性がある → Batch のステータスを確認し、未完なら 30 分待って再実行 - それ以外は該当ジョブのみ手動で再実行する。ウォーターマークは進めていないため二重取り込みは起きない
- 2 日連続で失敗している場合は Sev1。ウォーターマークを手動で巻き戻し、期間を絞って再実行する
R-02 API がレート制限・エラーを返す
- 429 / 529 はジョブキューの指数バックオフ（1 分 → 5 分 → 15 分）で自動リトライされる。3 回失敗したら Sev2
- 401（認証）の場合は API キーの失効。環境設定のキーを更新して再実行
- 400（入力不正）が特定ノートで続く場合は、そのノートを
_errors.mdに記録してスキップし、前処理の不具合として起票する
R-03 埋め込み（ollama）が応答しない
clusterジョブが失敗する。ollama のプロセス稼働を確認- 復旧できない場合は FTS5 のみで名寄せする縮退モードに切り替えて処理を継続する（精度は落ちるが止まらない）
- 縮退モードで生成された草案は
confidenceを 0.1 減点し、レビュー時に注意フラグを立てる
R-04 vault の書き込みが競合した
- Obsidian で同じ FAQ ノートを手編集している最中に FAQ Builder が書き込むと競合する
updated_atが DB の値より進んでいるノートは書き込まずスキップし、reindex の read-repair に任せる（_meta/schema.mdの手編集ルールに従う）- スキップしたノートは日次レポートに列挙する
R-05 個人情報の混入が見つかった
- 該当 FAQ を即時
archivedに落とす - 同じ生成バッチの FAQ 全件を
reviewに戻して再確認する - マスキング規則の穴を特定し、ゴールデンセットにテストケースを追加する
- サービスオーナーへ即時報告（Sev1 扱い）
R-06 API コストが上限に達した
extract:submit/draft:submitが自動停止する。ingestとnormalizeは継続するため、データの取りこぼしは起きない- 消費の内訳を
faq_metricsで確認し、想定外の工程を特定する - 一時的に上限を引き上げるか、翌月まで待つかをサービスオーナーが判断する
2.9 変更管理
| 変更種別 | 手順 | 承認 |
|---|---|---|
| プロンプト改修 | ゴールデンセットで回帰テスト → 合格ラインを満たしたら適用 | 開発担当が実行と承認を兼ねる（RA）。結果を週次会で共有 |
| モデルの版上げ | ゴールデンセットで新旧比較 → コストと精度の両面で評価 | サービスオーナー |
| カテゴリ体系の変更 | 四半期棚卸で提案 → 既存 FAQ の再分類コストを見積もる | 部門リード |
| 品質ゲートの変更 | 訂正事案の分析結果を根拠に提案 | サービスオーナー |
| バックフィルの再実行 | 影響範囲（上書きされる FAQ 件数）を提示 → API コストを見積もる | サービスオーナー |
プロンプトはバージョン管理し、生成された FAQ には使用したプロンプト版を記録します。訂正事案が発生したとき、どの版で生成されたかを追えるようにするためです。
2.10 会議体と報告
| 会議体 | 頻度 | 参加者 | アジェンダ |
|---|---|---|---|
| 週次レビュー会 | 月曜 30 分 | ナレッジオーナー ×2、開発担当 | 未処理草案の棚卸 / 却下理由の共有 / 滞留の裁定 |
| 月次 KPI レビュー | 第 1 営業日 60 分 | 全役割 | KPI 実績 / コスト実績 / 訂正事案 / 翌月の重点 |
| 四半期棚卸 | 四半期初 半日 | 全役割 | FAQ 全件棚卸 / カテゴリ再編 / マイルストーン判定 |
月次レポートの記載項目
- KPI 実績（カバレッジ率・採用率・承認率・鮮度充足率・滞留日数）と前月比
- 公開 FAQ 件数の増減と、状態別の内訳
- API コスト実績（工程別）と上限に対する消費率
- 訂正事案の全件と原因分類
- 却下理由の集計とプロンプト改善の実施内容
- Sev1 / Sev2 の発生件数と対応結果
- 翌月の重点カテゴリと、そこに投じるレビュー工数
2.11 立ち上げ 90 日計画
Q1 の準備作業（ベースライン計測・ゴールデンセット作成・草案 30 件の手動レビュー）は合計 約 60 時間を見込み、事業計画 §1.8 の初年度コストに「Q1 準備工数 300,000 円」として計上しています。
Day 1-30：計測と土台（2026-09）
| # | 作業 | 完了条件 |
|---|---|---|
| 1 | ベースライン計測 | 質問 100 件をサンプリングし、一次回答時間と重複質問率を実測 |
| 2 | マスキング規則の確定と評価 | 規則を文書化し、テスト 100 件で除去漏れ 0 件 |
| 3 | ゴールデンセット 100 件の作成 | 質問・正解カテゴリ・期待する回答要素を人が付与 |
| 4 | カテゴリ初期案 12 分類の合意 | ナレッジオーナー 2 名と部門リードが合意 |
| 5 | ナレッジオーナーの指名 | 2 名確定、週次会の枠を確保 |
Day 31-60：パイプライン疎通（2026-10）
| # | 作業 | 完了条件 |
|---|---|---|
| 1 | 質問抽出〜名寄せの実装と精度評価 | ゴールデンセットで適合率 80% / 再現率 70% |
| 2 | 少量 500 件での試験バックフィル | エラー率 5% 未満、API 実費が試算の 1.5 倍以内 |
| 3 | 草案 30 件を手動レビューし判断基準を言語化 | 品質ゲート 4 条件の運用例が文書化されている |
| 4 | レビュー UI（Obsidian ＋ クエリ）整備 | review 状態の FAQ が 1 クリックで一覧できる |
Day 61-90：初期運用の開始（2026-11）
| # | 作業 | 完了条件 |
|---|---|---|
| 1 | 全 14,031 件のバックフィル実行 | 完走し、質問クラスタが生成されている |
| 2 | 初期 FAQ 100 件を公開 | 品質ゲートを通過した 100 件が published |
| 3 | 日次バッチと Chatwork 通知の本稼働 | 7 日連続で自動実行が成功 |
| 4 | M1 判定 | 下記 4 条件で継続 / 設計見直しを決定 |
M1（Day 90）の判定基準
① 質問抽出の適合率 80% 以上 ② 草案の承認率 50% 以上 ③ 公開 FAQ 100 件 ④ API 実費が試算の 1.5 倍以内
この 4 つを満たさない場合は、Q2 に進まず設計を見直します。判断を先送りしないために、Day 90 の週次会を判定の場としてあらかじめ設定しておきます。
2.12 運用開始後の撤退・縮小基準
投資を続けるかどうかを機械的に判断できるよう、あらかじめ基準を決めておきます。
| 状況 | 判断 |
|---|---|
| M1 の 4 条件のうち 2 つ以上を満たさない | 撤退または設計の全面見直し |
| M2 時点で承認率が 40% 未満 | 生成を止め、プロンプト再設計に 1 ヶ月を充てる |
| 3 ヶ月連続でレビュー滞留の中央値が 10 日超 | 対象カテゴリを絞って規模を縮小する |
| 訂正率が 5% を超える | 品質ゲートを厳格化し、公開ペースを半分に落とす |
| M4 時点でカバレッジ率が 30% 未満 | 内部ナレッジ用途に限定し、公開 FAQ への昇格を次期へ持ち越す。20% 未満の場合は対象カテゴリを絞って縮小運用に切り替える |