【作成推奨】『自社固有データに答えるBot』は作るべき — 作成推奨／不要の判断フレーム

3行まとめ#

• 『自社固有データに答える』『外部システムに副作用を起こす』『監査ログが要る』の3条件のどれかに該当するなら、ツール化（=Lovableで内製）する価値がある。
• 逆に該当しないなら、汎用AIチャットを社員が直接使う方が速く安い。
• 判断フレームを共有することが、Buyer to Builder への第一歩。

判断フレーム（4つの問い）#

1. Q1 再現性: 同じ手順を週10回以上、複数人が繰り返すか？
2. Q2 社内文脈: 自社固有データ（顧客DB・規程・過去案件）が必須か？
3. Q3 統制: 監査ログ・権限管理が必要か？
4. Q4 連携: 別システムへの副作用（Slack通知・CRM起票・帳票出力）が要るか？

2つ以上Yesなら作成推奨、1つ以下なら作成不要（汎用AIで十分）。

実例マトリクス#

• 見積書チェック → Q1◯ Q2◯ Q3◯ Q4◯ → 作成推奨（社内事例の本命）。
• 議事録要約＋タスク起票 → Q1◯ Q2△ Q3△ Q4◯ → 作成推奨。
• 社内FAQ検索 → Q1◯ Q2◯ Q3◯ Q4△ → 作成推奨。
• 営業メール下書き → Q1△ Q2× Q3× Q4× → 作成不要。
• 英語翻訳 → Q1◯ Q2× Q3× Q4× → 作成不要。
• 顧客向け請求書生成 → Q1◯ Q2◯ Q3◯ Q4◯ → 作成推奨（責任設計を慎重に）。

作る場合の最小構成テンプレ（Lovable）#

• Lovable Cloud: 自社固有データを保管（DB＋ベクター検索）。
• Lovable AI: GeminiまたはGPTで判断・要約・抽出（用途別に使い分け）。
• Connector: Slack / Google Drive / Gmail / HubSpot 等で入出力を繋ぐ。
• Server Function: 上記をオーケストレーション＋監査ログ書き込み。

プロンプト設計の共通ルール#

# 社内ツール共通プロンプト規約

1. 出典・根拠を必ず明示する（参照したドキュメント名や行を列挙）。
2. 確信度が低い場合は推測せず「要人手確認」と返す。
3. 個人情報・人事評価・契約条件の確定は出力しない（人にエスカレーション）。
4. 出力は構造化（JSON or Markdownの表）を優先し、後工程で機械処理できる形にする。
5. 監査用に「いつ・誰の質問に・どのモデルが・どのデータで答えたか」をDBに保存する。

人がやる vs AIがやる（再掲）#

• AIがやる: 検索・要約・抽出・突合・選択肢の列挙・下書き作成。
• 人がやる: 最終判断・承認・社外への発信・例外条件の解釈・ナレッジ更新。
• 境界の鉄則: 『金額・契約・人事』に関わる確定アクションは必ず人を通す。

次に読む#