Dify×Google Forms IT問い合わせRAG設計ガイド

Google Forms で受け付けたIT問い合わせを Dify（LLMアプリ開発プラットフォーム）の RAG（Retrieval-Augmented Generation：検索拡張型生成）で自動回答しながら、未解決の質問を BigQuery に蓄積してナレッジを自動育成する設計パターンがあります。この記事では、Dify Google Forms 問い合わせ自動化の閉ループ設計を検討する情シス担当者向けに、フロー設計・閾値判断・失敗ケースの観点を整理します。

この記事を読んだほうが良い人

• 月100件以上のIT問い合わせを Google Forms や共有メールで受け付けており、手動対応の負荷を減らしたい情シス担当者
• Dify を社内にすでに導入済みか導入を検討していて、Google Forms との連携設計を考えている方
• 過去の Q&A が蓄積できておらず、ナレッジベースを自動育成する仕組みを構築したい方

自己拡張型RAGとはどんな設計か

通常のRAG構成は「素材文書を事前にインデックス化し、質問が来たら検索して回答する」静的な仕組みです。自己拡張型RAGはここに一段加えたもので、問い合わせの過程で生まれた Q&A ペアを定期的にナレッジへ投入し、次の問い合わせの自動対応率を高めていく閉ループを実現します。

Forms で入ってきた問い合わせそのものが FAQ データベースを育てる素材になるため、運用を続けるほど自動化率が上がる点が従来の静的RAGとの違いです。ただし、この仕組みを機能させるには「どの問い合わせを自動回答するか、どこで人間に渡すか」の境界を適切に設計する必要があります。

Forms→Dify→BigQueryの連携フロー

全体の情報の流れを整理すると、以下のようになります。

[1] Google Forms 送信（質問者）
         ↓ フォーム送信トリガ
[2] GAS（Google Apps Script）Webhook
         ↓ HTTP POST（質問テキスト）
[3] Dify ナレッジ検索ノード（RAG）
         ↓ 類似度スコア計算
     ┌────────────────┐
  スコア ≥ 閾値      スコア < 閾値
     ↓                   ↓
[4A] 自動回答メール   [4B] 担当者へメール転送
（回答テキスト添付）   （質問内容を通知）
     ↓                   ↓ 担当者が手動回答
    完了            [5] Q&A ペアを BigQuery に書き込み
                          ↓（一定件数または月次バッチ）
                    [6] Dify ナレッジ更新
                          ↓
                    （次回から自動回答の対象になる）

フローの要点は3点あります。

まず [2] の GAS による Webhook 送信です。Google Forms にはネイティブのWebhook機能がないため、フォーム送信を GAS の onFormSubmit トリガーで受け取り、Dify の API エンドポイントへ POST リクエストを送る形になります。

次に [3] の判定です。Dify のナレッジ検索ノードは、検索にヒットした文書チャンクとクエリの類似度スコア（0〜1 の値）を返します。このスコアを閾値で切り分けることで、「自動回答する／人間に渡す」を分岐させます。

最後に [5]→[6] の閉ループです。手動対応が必要だった質問と担当者の回答をセットで BigQuery に書き込み、一定量がたまったタイミングで Dify のナレッジへ投入します。次回以降は同種の質問に自動回答できるようになります。

信頼度スコアの閾値設計：どこで線を引くか

Dify のナレッジ検索ノードには、類似度スコアの下限閾値（Score Threshold）を設定する機能があります。公式ドキュメントによると、閾値なし設定の場合は関連度が低いチャンクも上位 K 件として返されるため、閾値の設定が推奨されています。閾値の設定ミスが最も直接的に自動化の品質に影響するため、ここの設計を丁寧に考えます。

閾値の区切り方には主に3つのパターンがあります。

スコア 0.7 以上だけ自動回答にする（保守型）

既存ナレッジとの一致精度が高い質問だけを自動回答するため、誤回答リスクは低くなります。一方で自動対応できる範囲が狭くなり、多くが担当者転送になります。ナレッジ量が少ない運用初期や、回答ミスが重大な影響を持つ問い合わせ種別（アカウント権限・セキュリティ設定など）に向いています。

スコア 0.4〜0.7 を中間帯（Human-in-the-Loop＝人間が最終判断に介在する設計）として扱う

この帯域を「自動送信はしないが、AI が生成したドラフトを担当者に提示する」ゾーンとして設計します。担当者の確認コストを下げながら誤回答を防げるため、専門性が高い問い合わせ対応に有効です。完全自動化への移行前のステップとしても機能します。

スコア 0.4 未満を未解決として扱う

ナレッジ未収録の質問と判断し、担当者が一から回答します。この回答が BigQuery への蓄積対象となり、将来のナレッジ更新素材になります。

出発点として、閾値 0.55 前後で自動回答／中間帯／未解決の3段階に区切る設計が扱いやすいことが多いです（筆者の推測を含む判断軸です）。最終的な数値はナレッジの質と量、問い合わせの文体のばらつきに依存するため、運用開始後のログを見ながら調整していくことになります。

社内RAGを育てるBigQuery蓄積設計

BigQuery への書き込み設計は、将来のナレッジ更新の品質を左右します。最低限蓄積すべき情報は以下の通りです。

• 質問テキスト（Forms 回答のまま）
• 担当者が送信した回答テキスト
• 問い合わせカテゴリ（ネットワーク・アカウント・ソフトウェア等、Forms の選択肢から引き継ぐ）
• 対応日時
• 対応者識別子（匿名化可）
• Dify が返したスコア（閾値を下回った値）

スコアも記録しておくと、「閾値をどこに設定すればよかったか」の事後検証に使えます。問い合わせカテゴリがあると、特定カテゴリだけナレッジ更新を先行させるといった優先度制御も可能になります。BigQuery は Google Cloud のマネージドデータウェアハウスであり、Google Workspace とは別サービスですが、GAS や Cloud Functions からの書き込みと相性がよく、Google Cloud を使っている組織であれば追加コストを抑えて導入できます。

失敗ケースと回避策

設計段階で想定しておくべき代表的な失敗パターンを挙げます。

ケース1: Forms 回答が短すぎて検索精度が出ない

質問テキストが「パスワード」「動かない」など一語・二語だと、RAG の検索クエリとして機能せず、スコアが閾値を超えません。対策は Forms の設計側で「どのシステムのパスワードか」「どんな状況で動かないのか」を誘導する必須入力フィールドを設けることです。自由記述だけに頼らず、構造化されたフォームが前提になります。

ケース2: 中間帯スコアで誤った自動回答が送信される

運用初期はナレッジの精度が低いため、0.6 前後のスコアでも実際には別の質問への回答が引っかかるケースがあります。初期段階では閾値を高めに（0.7 以上）設定し、自動回答件数が少なくても誤回答ゼロを優先する設計にしておくことを勧めます。ナレッジが充実してきたタイミングで徐々に閾値を下げて効果を検証します。

ケース3: BigQuery への書き込みが漏れて蓄積ループが機能しない

担当者の手動回答が Slack やメールで行われても、GAS や連携スクリプトへのトリガーが接続されていなければ回答は蓄積されません。「担当者がどのチャネルで回答するか」を設計段階で決め、そのチャネルからの書き込みを BigQuery への連携トリガーとして組み込む必要があります。Gmail の送信済みフォルダ監視や Slack Events API を利用した Slack アプリ、または Slack ワークフロービルダーを活用する方法が考えられます。

ケース4: ナレッジ更新タイミングが遅すぎてRAGの鮮度が下がる

月次更新では新しい問い合わせへの対応が遅れます。BigQuery への蓄積件数が一定のしきい値（例: 20〜30 件）を超えたタイミングでナレッジ更新をトリガーする仕組みを検討してください。件数ベースとスケジュールベースを組み合わせるのが安定しやすい運用です。

設計を始める前に確認すべきこと

この閉ループ設計を導入する前に、現在の問い合わせ状況を把握しておくことが前提になります。

まず確認するのは、月間問い合わせ件数のうち繰り返し発生している質問の比率です。繰り返し質問が全体の30〜40%程度あれば、RAG による自動化の効果が出やすい状況とみることができます（筆者の目安であり出典のある数値ではありません）。

次に、既存のナレッジ素材（過去のQ&Aや手順書）がどれだけあるかを確認します。ナレッジが不十分な状態でRAGを動かすと、スコアが低く担当者転送ばかりになります。まず過去Q&Aをテキストで整理してインデックス化することが先決です。

最後に、「誤回答が出たときの影響範囲」を考えます。アカウントロック解除やセキュリティ設定に関わる回答は誤回答の影響が大きいため、自動化対象から外すか人間確認を必須にする判断が必要になります。

IT問い合わせ自動応答で何が変わるか

自己拡張型RAGの閉ループが機能すると、問い合わせ対応の自動化率は時間とともに高まります。担当者が「同じ質問への回答」に使っていた時間を別の業務に充てられるようになる点が第一の変化です。

もう一つの変化は可視化です。BigQuery に蓄積した Q&A は、問い合わせ傾向の分析素材になります。「どの機能についての問い合わせが多いか」「どの部署からが多いか」といった傾向をデータで把握できるようになると、社内システムの改善優先度を決める根拠にもなります。

一方で、ナレッジの鮮度管理とスコア閾値のチューニングには継続的な運用コストがかかります。完全自動化の前に「半自動化（ドラフト提示＋人間確認）」で運用を始め、誤回答の発生傾向をつかんでから移行するステップが現実的な進め方です。問い合わせ件数が多い組織ほど閉ループの恩恵が大きくなるため、まず月50〜100件程度の問い合わせを対象に小さく始めて効果を測定することを勧めます。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。