SYNON › 記事 › FAQ Builder
FAQ Builder 計画書 / 01. 事業計画

01. 事業計画

← 目次に戻る

1.1 エグゼクティブサマリ

Chatwork とメールに散在している顧客からの質問を、Claude API で定期的に精査して FAQ に育てる社内サービスを立ち上げます。

vault には既に 14,031 件の Inbox ノートがあり、そのうち 8,954 件（63.8%）が質問を含んでいます。この資産は現在まったく再利用されておらず、同じ質問への回答が担当者ごとに書き起こされている状態です。

FAQ Builder は日次バッチで差分を取り込み、質問抽出 → 名寄せ → 草案生成 → 自動検証までを自動で行い、人は承認だけを行います。定常運用時の Claude API 費用は月 $17.79（約 2,800 円）、人の工数は月 約 12 時間。12 ヶ月後には問い合わせ一次対応の工数を 月 60 時間（月 30 万円相当）削減することを目標とし、投資は通算 22 ヶ月で回収します。

指標 現状 12 ヶ月後の目標
FAQ カバレッジ率 0%（FAQ が存在しない） 30%
公開 FAQ 記事数 0 件 600 件
一次回答リードタイム Q1 に計測して確定 中央値 −30%
一次対応の削減工数 — 月 60 時間

1.2 背景と課題

現状の課題構造
現状の課題構造

データはあるが、使える形になっていない

_meta/schema.md の規約に従って、Chatwork・メール・X の受信メッセージはすべて 1 通 1 ノートで vault に落ちています。案件（3,634 件）と顧客（493 件）も紐付いています。にもかかわらず、過去の回答を検索して再利用する動線がありません。

全文走査した結果は次のとおりです。

ソース ノート数 質問を含むノート 割合
Chatwork 7,873 4,019 51.0%
Email 5,681 4,886 86.0%
X（DM/メンション） 472 48 10.2%
Slack / Gmail 5 1 —
合計 14,031 8,954 63.8%

メールの質問含有率が高い（86.0%）のは、引用と定型フッタを含んだ長文が多いためで、本文の平均長は 7,398 字、中央値は 329 字と分布が大きく偏っています。前処理で引用・署名・免責文を落とす工程が精度の鍵になります。

流入量は月 1,900 件規模で安定している

Inbox の月次流入量と質問件数の推移
Inbox の月次流入量と質問件数の推移

直近 7 ヶ月（2026-01〜07）の平均は 1,882 件/月です。ただし 2026-07 の 4,611 件は Chatwork 連携の一括取り込みを含むため実勢より多く、2026-08 は 17 日時点の途中集計です。

そこで前提値は両側に保守を取ります。

用途 前提値 根拠
コスト試算（処理量） 新規流入 約 1,900 件/月 7 ヶ月平均 1,882 件/月。多めに見積もる方が安全
効果試算（削減量） 質問 約 1,000 件/月 2026-07 を除く 6 ヶ月平均は流入 1,428 件/月・質問 990 件/月。少なめに見積もる方が安全

コストは多く、効果は少なく置くことで、ROI が楽観に振れないようにしています。

質問の内容は 12 カテゴリに収まる

初期カテゴリ体系と出現傾向
初期カテゴリ体系と出現傾向

質問の判定パターンを絞った 7,927 件（上表の 8,954 件より狭い条件での集計）に対してキーワード出現率を取ると、コーディング受託業務に固有の 12 テーマに集約されます。これが FAQ の初期カテゴリ体系の骨格になります。なお 1 件が複数カテゴリに該当するため合計は 100% を超えます。正式なカテゴリ確定は Q1 の質問抽出結果（構造化 JSON）に基づいて行います。

1.3 サービス概要と提供価値

FAQ Builder が提供する価値は 3 つです。

価値 内容 効いてくる場面
一次回答の高速化 受信した質問に対して、既存 FAQ を回答候補として自動提示する Chatwork で質問が来た直後
回答品質の均一化 誰が答えても同じ根拠・同じ粒度になる 担当者が休み・異動したとき
立ち上がりの短縮 新メンバーが過去の判断を検索できる 入社・配置転換の直後

スコープ

対象範囲

対象外（本計画では作らない）

1.4 アーキテクチャと技術選定

FAQ Builder のシステム構成
FAQ Builder のシステム構成

なぜ新しいデータストアを作らないか

既存の synon-cole が vault（Markdown）と SQLite の双方向同期を持っており、note_type でエンティティ種別を判別します。FAQ を note_type: faq の Markdown ノートとして Knowledge/FAQ/ に書き出すだけで、reindex が SQLite に同期し、Obsidian からそのまま閲覧・手編集できます。

新しい DB を立てると同期の整合を自分で持つ必要が出るため、FAQ Builder はステートを持たない worker として実装し、真実は常に vault にあるという構成にします。

技術スタック

synon-ma（MA Suite）で実績のある構成をそのまま流用します。新しい要素を増やさないことを優先しました。

レイヤ 採用技術 備考
実行形態 Docker Compose（worker 1 コンテナ） 画面を持たないため app コンテナは不要
言語 Node.js 22 + TypeScript 既存資産と揃える
データストア vault（Markdown）＋ SQLite（WAL） 真実は vault。SQLite は索引とメトリクス
全文検索 SQLite FTS5（trigram） 日本語の部分一致に trigram が有効
ジョブキュー SQLite jobs テーブル（自前） Redis を増やさない。MA Suite と同方式
質問抽出・判定 Claude Haiku 4.5（Batch API） 大量・単純な構造化抽出に最も安い
草案生成・検証 Claude Sonnet 5（Batch API） 文章品質が要る工程のみ上位モデル
埋め込み ローカル ollama（nomic-embed-text 等） Claude API に埋め込みが無いため。API 費用ゼロ
通知 Chatwork API（既存 connector 経由） 運用ルームへレビュー依頼とアラート

AI 基盤の方針：本計画は「Claude API 中心」を前提にしています。ただし埋め込み（ベクトル化）は Claude API に該当機能がないため、名寄せ工程のみローカル ollama を使います。デバイス上で完結するため追加費用は発生せず、外部送信するテキスト量も減ります。

1.5 自動 FAQ 構築パイプライン

自動 FAQ 構築パイプラインの 7 ステージ
自動 FAQ 構築パイプラインの 7 ステージ
# ステージ 処理内容 実行
① 収集（Ingest） updated_at のウォーターマークで差分ノートのみ抽出 自動
② 前処理（Normalize） 引用行・定型署名・免責フッタの除去、個人情報のマスキング 自動
③ 質問抽出（Extract） Haiku 4.5 で「質問か / 質問文 / 暗黙の前提 / 回答が付いているか」を JSON 抽出 自動
④ 名寄せ（Cluster） ローカル埋め込みのコサイン類似 ＋ FTS5 で、既存 FAQ への紐付けか新規クラスタかを判定 自動
⑤ 草案生成（Draft） Sonnet 5 で Q / A / 根拠リンク / 対象読者 / 注意点を生成 自動
⑥ 自動検証（Verify） 別プロンプトで根拠との整合をチェックし、0〜1 の信頼度スコアを付与 自動
⑦ 承認・公開（Publish） 品質ゲート 4 条件を人が確認して published へ 人

却下・修正の指摘は分類して蓄積し、③ と ⑤ のプロンプト改善に回します（学習ループ）。

個人情報を外に出さないための前処理

前処理とマスキングの流れ
前処理とマスキングの流れ

顧客名・個人名・メールアドレス・電話番号・金額・URL は API に渡す前に伏字化し、原文への参照 ID だけを残します。復元は vault 側の参照 ID でのみ行います。FAQ 本文に顧客固有情報が残っていた場合は品質ゲートで差し戻します。

1.6 FAQ のデータモデル

FAQ ノートのデータモデル
FAQ ノートのデータモデル

_meta/schema.md の規約どおり、YAML フロントマターがそのまま SQLite の行になります。機密カラムは持ちません。

---
note_type: faq
organization_code: demo
id: faq_0001
question: テストアップの公開時刻は？
category: テストアップ/検証環境
status: published        # draft / review / published / stale / archived
confidence: 0.82         # 自動検証が付ける 0-1 のスコア
source_ids:              # 根拠となる原文（2 件以上必須）
  - inbox:2026-01-26-質問です-0235cfcc
  - inbox:2026-02-20-お客様お問合せ担当-小山-さん-399e0817
case_ids: [P20240607-1]
customer_specific: false # true の FAQ は公開昇格の対象外
owner: u_mtanaka
review_due: 2027-01-03   # 既定は公開日 + 90 日
used_count: 37
version: 3
created_at: 2026-09-20 04:12:00   # 草案が生成された日時
updated_at: 2026-10-05 10:41:00   # 最終レビューで published にした日時
---

ライフサイクル

FAQ のライフサイクルと品質ゲート
FAQ のライフサイクルと品質ゲート
状態 意味 次の遷移
draft 自動生成直後 レビュー着手で review
review 担当者が根拠を確認中。WIP 上限 20 件 承認で published / 却下で draft
published 社内ナレッジとして検索・提示の対象 90 日経過または元データ更新で stale
stale 要再評価 差分を反映して review へ戻す
archived 参照 0 件が 180 日、または内容が失効 復活は手動のみ

published に進むための品質ゲート（4 項目すべて必須）

  1. 根拠となる原文が 2 件以上ある
  2. 個人情報・顧客固有条件が残っていない
  3. 回答が現行の運用ルールと矛盾しない
  4. 担当オーナーと次回レビュー期日が入っている

1.7 KPI 設計

KPI ツリー
KPI ツリー
階層 指標 定義 12 ヶ月後の目標
事業目標 一次対応の削減工数 FAQ で代替できた回答作成時間 月 60 時間
中間 FAQ カバレッジ率 受信質問のうち既存 FAQ で一次回答できる割合 30%
中間 FAQ 採用率 提示された FAQ が実際に回答へ使われた割合 60%
中間 一次回答リードタイム 受信から一次回答までの中央値 −30%
運用 FAQ 公開記事数 status: published の件数 600 件
運用 自動草案の承認率 承認 ÷（承認＋却下） 70% 以上
運用 鮮度充足率 90 日以内にレビュー済の割合 90%
運用 誤情報による訂正率 公開後の訂正件数 ÷ 公開記事数 2% 以下
運用 レビュー滞留日数 draft → published の中央値 3 日以内
運用 API コスト 月次の Claude API 実費 月 30 USD 以内

ベースライン（現状の一次回答リードタイムと重複質問率）は Q1 の 30 日間で計測して確定させます。ここを測らずに始めると効果を主張できないため、立ち上げ 90 日計画の Day 1-30 に組み込んでいます。

1.8 投資計画とコスト試算

初年度コスト内訳と API 費用
初年度コスト内訳と API 費用

換算レートは 1 USD = 160 円（2026-08-17 の市場レート 約 158.9 円を保守側へ丸め）です。

初年度コスト

項目 金額 内訳
開発工数 3.5 人月 2,800,000 円 設計 1.0 / 実装 2.0 / 検証 0.5 人月（1 人月 80 万円換算）
Q1 準備工数 60 時間 300,000 円 ベースライン計測・ゴールデンセット作成・草案 30 件の手動レビュー（ナレッジオーナー／部門リード）
運用工数 9 ヶ月 540,000 円 月 約 12 時間 × 5,000 円/時 × 9 ヶ月（Q2 以降）
Claude API 実費 58,000 円 初期バックフィル 4,600 円 ＋ 定常 2,800 円 × 9 ヶ月 ＋ 開発期の評価実行 約 28,000 円
予備費 200,000 円 プロンプト再設計・再バックフィルの余裕
合計 3,898,000 円 うち 93%（3,640,000 円）が社内リソースの機会費用で、現金支出ではない

Claude API 費用の内訳（定常時・月次）

Batch API（50% 割引）を前提とした試算です。

工程 モデル 数量/月 入力 出力 月額
質問抽出 Haiku 4.5 / Batch 1,900 件 3.04 M tok 0.48 M tok $2.72
草案生成 Sonnet 5 / Batch 60 クラスタ 0.72 M tok 0.09 M tok $1.17
重複・更新判定 Haiku 4.5 / Batch 60 件 0.26 M tok 0.02 M tok $0.18
既存 FAQ の鮮度再評価 Haiku 4.5 / Batch 130 件 0.78 M tok 0.05 M tok $0.52
社内担当の検索・回答支援 Sonnet 5（同期） 600 回 4.80 M tok 0.36 M tok $13.20
月次合計 $17.79（約 2,800 円）

価格は Claude Platform の料金表（Haiku 4.5: 入力 $1 / 出力 $5、Sonnet 5: 入力 $2 / 出力 $10、Batch は 50% 割引）に基づく 2026-08 時点の試算です。モデルの版上げ時に再計算します。

1.9 効果試算と投資回収

累積損益と投資回収
累積損益と投資回収

効果は「質問 約 1,000 件/月 × カバレッジ率 × 12 分 × 5,000 円/時」で金額換算しました。カバレッジ率の立ち上がりを Q2: 10% → Q3: 20% → Q4: 30% と段階的に置いています。

期間 カバレッジ FAQ で代替できる件数 削減時間 月あたり効果
Q1（26/09-11） 0%（開発期間） — — —
Q2（26/12-27/02） 10% 100 件/月 20 時間/月 10 万円
Q3（27/03-05） 20% 200 件/月 40 時間/月 20 万円
Q4（27/06-08） 30% 300 件/月 60 時間/月 30 万円

削減時間は「質問 1 件あたり、過去の経緯調査と回答文の作成に 12 分かかっている」という前提です。この 12 分は Q1 のベースライン計測で検証し、実測値に置き換えます。

期 効果 コスト 単年損益 期末の累積損益
初年度（12 ヶ月） 180 万円 369 万円 −189 万円 −189 万円
2 年目（単年） 360 万円 119 万円（運用 79 万 ＋ 保守 40 万） +241 万円 +52 万円

ROI の基本ケースには予備費 20 万円を含めていません（初年度コスト 369 万円 ＝ 開発 280 万 ＋ Q1 準備 30 万 ＋ 運用・API 等 6.6 万円 × 9 ヶ月）。2 年目は運用・API に月 6.6 万円、保守改善に月 3.3 万円（年 0.5 人月）を見込んでいます。

損益分岐は通算 22 ヶ月目です。初年度は開発投資が先行するため赤字ですが、2 年目以降は運用コストが月 10 万円弱まで下がるため、単年で +241 万円の純効果になります。

保守側の前提を積み上げた結果として回収は 2 年目後半になります。前提を実勢寄りに戻す（質問 1,200 件/月・プロンプトキャッシュ適用）と回収は 18 ヶ月前後まで縮まりますが、判断は保守ケースで行うことを推奨します。

金額に載せていない副次効果

1.10 12 ヶ月ロードマップ

12 ヶ月ロードマップ
12 ヶ月ロードマップ
四半期 期間 テーマ 主な成果物 マイルストーン
Q1 2026-09 〜 11 基盤構築 ベースライン計測結果 / マスキング規則 / 質問抽出・名寄せの実装 / ゴールデンセット 100 件 M1 パイプライン疎通（Day 90）
Q2 2026-12 〜 2027-02 初期 FAQ 立上げ 草案生成・自動検証 / 全 14,031 件バックフィル / 初期 FAQ 400 件公開 M2 初期 FAQ 公開
Q3 2027-03 〜 05 運用定着 Inbox AI / Hermes への提示統合 / 日次バッチ本番運用 / KPI 改善サイクル M3 運用 KPI 達成
Q4 2027-06 〜 08 拡張・横展開 カテゴリ体系の再編・重複統合 / 顧客向け公開 FAQ の昇格検討 M4 横展開判断

マイルストーンの判定基準

# 時期 判定基準（すべて満たすこと）
M1 2026-11 末 ① 質問抽出の適合率 80% 以上　② 草案の承認率 50% 以上　③ 公開 FAQ 100 件　④ API 実費が試算の 1.5 倍以内
M2 2027-02 末 ① 公開 FAQ 400 件　② 承認率 60% 以上　③ 誤情報による訂正 5 件以内
M3 2027-05 末 ① カバレッジ率 20% 以上　② 採用率 50% 以上　③ レビュー滞留 中央値 5 日以内
M4 2027-08 末 ① カバレッジ率 30% 以上　② 鮮度充足率 90%　③ 公開 FAQ 昇格の可否を判断（20〜29% の場合は内部ナレッジ用途で継続し、公開昇格は次期へ持ち越す）

M1 で基準を満たさない場合は撤退または設計見直しを行います。これは意図的な判断ポイントで、Q1 までの投資（約 170 万円の機会費用 ＝ 開発 140 万 ＋ Q1 準備 30 万）で止められる設計にしています。

1.11 体制と役割

体制と役割分担（RACI）
体制と役割分担（RACI）

専任は置かず、既存メンバーの兼務で回します。ナレッジオーナーのみ 2 名体制にして属人化を避けます。

役割 工数 責務
サービスオーナー 1.5 時間/月 投資判断・KPI 責任・月次レポートの承認
開発担当 Q1-Q2 は 約 0.6 人月/月（3.5 人月 ÷ 6 ヶ月）、Q3 以降 0.2 人月/月 パイプライン実装・監視・障害対応
ナレッジオーナー ×2 合計 8.0 時間/月（各 4.0 時間） 草案レビューと承認、カテゴリ体系の維持
部門リード 2.5 時間/月 滞留の裁定・四半期棚卸・月次サンプル監査

運用側 3 役割の合計は 月 12.0 時間で、運用計画 §2.1 の総工数と一致します（開発担当の工数は別枠）。

RACI は上図の下段のとおりです（R=実行、A=承認責任、C=相談、I=報告、RA=実行と承認を兼ねる）。公開判断の A（承認責任）はサービスオーナー、R（実行）はナレッジオーナーに置き、実行と承認を分離しています。プロンプト改修だけは影響範囲が限定されるため、開発担当が実行と承認を兼ねます（RA）。

1.12 リスクと対策

リスクマップ
リスクマップ
# リスク 影響 可能性 対策
R1 誤った FAQ が流通し、顧客への誤回答につながる 高 中 根拠 2 件必須 ＋ 人の承認ゲート。自動公開は行わない。月次で公開分の 10% をサンプル監査
R2 個人情報・顧客固有情報が FAQ に混入する 高 中 API 送信前マスキング ＋ 公開前検査。customer_specific: true は公開昇格の対象外
R3 レビューが滞留し FAQ が陳腐化する 中 高 WIP 上限 20 件、7 日超で部門リードへ自動エスカレーション、週次会で強制トリアージ
R4 API コストが想定を超える 低 中 月次上限 $30 で自動停止。トークンメーターを日次で記録
R5 顧客固有の条件を過度に一般化してしまう 中 中 案件・顧客の紐付けを見て「顧客固有」タグを付与。公開対象外にする
R6 抽出精度が低く、草案が使い物にならない 中 低 ゴールデンセット 100 件で継続評価。M1 で適合率 80% を判定基準にする
R7 Chatwork 連携が停止しデータが供給されない 低 低 既存 connector のリトライと遅延アラートに相乗り
R8 ナレッジオーナーが属人化する 中 低 オーナー 2 名体制 ＋ 判断基準の手順書化

最大のリスクは R1・R2 です。この 2 つは「自動公開しない」という設計上の決定で封じます。全 FAQ は人の承認を経て初めて published になります。

1.13 意思決定を求める事項

# 事項 選択肢 推奨
D1 開発リソースの確保 Q1-Q2 の 6 ヶ月で計 3.5 人月（約 0.6 人月/月）を確保できるか 確保。できない場合は Q1 を 4 ヶ月に延ばす
D2 ナレッジオーナーの指名 誰を 2 名立てるか Chatwork の回答頻度が高い 2 名。Q1 中に指名
D3 ベースライン計測の方法 手動サンプリング / ログからの自動集計 Day 1-30 は手動サンプリング 100 件で十分
D4 顧客向け公開 FAQ の扱い Q4 に判断 / 最初から視野に入れる Q4 に判断。M4 の判定項目に含める
D5 月次 API 上限 $30 / $50 / 上限なし $30。プロンプトキャッシュ適用後に見直す

← 目次に戻る　|　02. 運用計画 →