この記事は前編です

前編：構想〜 MVP(まず動く最小構成のこと)完成
- 属人化した確認から卒業｜Dify×ChatGPTで作るお知らせ文言アシストBot【前編：たたき台が出せるBotを構築】
後編：自社ルール反映 　👈️この記事
- 属人化した確認から卒業｜Dify×ChatGPTで作るお知らせ文言アシストBot【後編：社内ルールをプロンプトで反映】
試運転編
- 属人化した確認から卒業｜Difyで作るお知らせ文言アシストBot【試運転編：チームで試して業務に活かせるか検証する】

自社ルールをBotに反映させる

MVP（実用最小限の製品。まず動く最小構成のこと）が固まったので、社内の運用ガイドラインを反映して「自社仕様」にしたくなりました。

もちろんサンプルですが、以下のようなガイドラインです。

ここで2つ目の大きな分かれ道が来ます。

🔵最初の発想：RAGで取り込めばいいのでは？

以前にRAGを使ったQ&Aボットを触っていたこともあり、最初は自然に「ガイドライン資料をナレッジに入れてRAGで参照させればいい」と考えました。

でも、取り込む資料（運用レギュレーション）を見て、立ち止まりました。

中身は以下です。

タイトル29文字以内・本文180文字以内
「お客さま」はひらがな
タイトルに句読点を使わず強調は【】
本文は「事象→状況→依頼→締句」の順

といった、どのお知らせでも毎回必ず守りたい固定ルールです。
「今回に似た事例を探したい」という性質ではありません。

🔵「辞書」と「校則」で考えると見えてきた😲

ここでRAGとプロンプトの役割を整理し直しました。
「辞書」と「校則」のたとえが分かりやすかったです。

	RAG（ナレッジ）	プロンプト直書き
たとえ	辞書（必要なとき引く）	校則（毎回必ず読む）
得意	大量の事例から関連を探す	全ケースに固定ルールを毎回適用
向くデータ	過去の文例が何百件もある場合	表記・文字数などの絶対ルール
リスク	検索精度次第でルールを引き損ねる	プロンプトが長くなる

今回の資料は明らかに後者（校則） でした。
文字数制限のような厳密なルールをRAGで「検索して引いてくる」方式にすると、検索が外れたときにルールが抜ける事故が起きます。
毎回100%効かせたいルールは、常にプロンプトに書いておく方が確実だと判断しました。

💡 決め手は「手段が目的化していないか」

新しい技術を学ぶと、それを使うこと自体に価値があるように感じます。でも今回の本質は技術を使うことではなく、課題を見つけてどう解決するかを考えること。やりたいこと（社内ルールを守らせる）は正しく、その手段として効果が最大のものを選ぶべき。

念のため⋯
RAGが不要という話ではありません。過去のお知らせ文例が何十件も溜まって「似た事例を参照したい」段になれば、そこではRAGが効きます。「固定ルール→プロンプト」「大量の事例→RAG」の棲み分けで、今回はまだ事例が溜まっていないので、プロンプトから始めるのが妥当と考えました。

🔵ガイドラインをプロンプトに組み込む

判断が決まったら、ガイドラインをシステムプロンプトの方針ブロック直後に追加しました。

手元のガイドライン（PowerPoint資料）の内容を生成AIに渡して、「この内容をBotが守れるプロンプトの形に整理して」と頼んで作りました。
資料の文章をそのままコピペするのではなく、ルールとしてAIが解釈しやすい箇条書きに整形してもらうイメージです。ここでも、人がやるのは「どの資料をどう使いたいか」を伝えることで、整形はAIに任せています。

ガイドラインを生成AIへ渡す際は、情報漏洩にはご注意ください。
参考記事はこちら

見出しを「社内レギュレーション（必ず厳守）」と強い言葉にして、一般的な好みではなく絶対ルールだと認識させるのがポイントです。

# 社内レギュレーション（必ず厳守）
## 文字数
- タイトル：29文字以内（推奨20〜25文字）
- 本文（詳細説明文）：180文字以内（推奨140〜150文字）

## 表記ルール
- 「お客さま」はひらがなで統一する。
- 補助動詞はひらがな化する（「〜して頂く」ではなく「〜していただく」）。
- タイトルに句読点（。、）を使わない。強調は【 】を使う。
- ブランド名・サービス名はカタカナ表記をベースにする。

## 本文の構成（黄金律）
1. 事象：何が起きているか
2. 状況：現在どうなっているか
3. 依頼：お客さまに何をしてほしいか
4. 締句：お詫びと感謝

注意：文字数制限はAIが完璧には守らない

実装してみて分かった注意点として、文字数制限（タイトル29字・本文180字）のような厳密な数値ルールは、LLMが完璧に守るのは苦手です。たいていは守りますが、たまに数文字オーバーします。

ただ、このボットはそもそも「たたき台を作る」設計で、最終的に人が確認・調整する前提です。文字数の最終調整を人が行う運用と相性が良いため、ここは許容範囲と整理しました。完璧な自動化ではなく、人とAIの役割分担を前提に設計することが大切だと感じます。

１）プロンプトにレギュレーションを追加

２）公開して検証します

ケースA~Dの各パターンで検証します。
それぞれの回答結果を確認します。

３）ビフォーアフターで4点チェック

前回のケース（ガイドラインなし）と見比べて、以下が変わっていれば成功です。

確認ポイント４点

タイトル … 句読点が消え、【】強調が使われているか（例：【復旧済み】システム障害のお知らせ）
本文構成 … 「事象→状況→依頼→締句」の順になっているか（障害発生→復旧済み→履歴を確認ください→お詫び）
表記 … 「お客さま」がひらがなになっているか
文字数 … 本文が180字程度に収まっているか（多少のオーバーは許容）

ガイドラインのプロンプト反映は成功です🎉🎉

🔵効果検証：障害・お詫びのケースで前後比較🎉

効果がいちばん分かりやすい 「障害・お詫び」のケースで、反映前後を比べました。

反映後は、タイトルが【お詫び】【重要】と隅付き括弧の強調になり、句読点が消えました。
本文は「事象→状況→依頼→締句」の流れになり、反映前にあった「平素より〜」の定型挨拶が消えて、約120字に引き締まりました。
タイトルの【】化・本文の4ステップ構成・文字数の引き締まり、この3点が前後ではっきり効いていました。

実際に作ってみてわかったこと

Difyは「とりあえず動くもの」なら早く作れます。一方、業務で使える状態まで持っていくには、プロンプトの調整と入力項目の設計がかなり効きます。
短いお知らせ文言ほど、どの情報を必ず入れ、どの順で出し、不足にどう気づけるようにするかの設計が、使いやすさを左右しました。

そして今回いちばんの収穫は、出来上がったものより判断の過程でした。
アプリタイプ選びでUXの制約に気づいて発展性とのトレードオフを選んだこと。自社ルールの反映で、最初に考えたRAGから検討の末にプロンプト直書きへ判断を変えたこと。どちらも 「新しい技術を使うこと」ではなく「課題に対して効果が最大の手段を選ぶこと」 を優先した結果となりました。

今後改善したいこと

今回はMVP（実用最小限の製品。まず動く最小構成のこと）の段階なので、実務投入にはまだ改善が要ります。今後は以下を試したいです。

🔵掲載場所ごとの文言ルールを増やす

アプリ内ポップ、Webページ、店頭POP、メールなど、掲載場所によって適切な文言の長さや表現は変わります。

今後は、掲載場所ごとのルールをもう少し細かく設定したいです。

🔵NG表現を管理する

お客様に責任があるように見える表現や、誤解を招きやすい表現は避ける必要があります。

今後は、使わない方がよい表現や、言い換えルールを整理して、プロンプトに反映したいです。

🔵過去のお知らせ文言を参考にできるようにする

過去に使ったお知らせ文言をナレッジとして持たせると、より実務に近い出力ができそうです。

Difyのナレッジ機能を使って、過去文言や表現ルールを参照できる形も試してみたいです。

🔵社内確認フローに近づける

今は文言案と社内確認用コメントを出すところまでですが、将来的には「誰に何を確認するべきか」まで整理できると、より業務に使いやすくなりそうです。

まとめ

今回は、Difyを使って「お知らせ文言アシストBot」を作ってみました。

お知らせ文言は短い文章ですが、実際には考えることが多いです。
毎回ゼロから行うのは、意外と負荷がかかります。

今回のBotでは、AIに文言作成のたたき台と確認観点の整理を手伝ってもらうことで、最初の一歩を少し軽くできる可能性を感じました。

完成度としてはまだ改善の余地があります。

ただ、Difyと生成AIを組み合わせることで、身近な業務課題に対して小さな打ち手を作れることがわかりました。🎉

前編はこちら

前編では、構想〜 MVP(まず動く最小構成のこと)まで完成しています。