この記事は前編です

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

こんにちは、ももっぺです。

今回作ったのは、Difyを使った「お知らせ文言アシストBot」です。

ネットスーパーやECサイト、アプリなどでは、お客様に向けてお知らせを出す場面がたくさんあります。

たとえば、メンテナンスのお知らせ、キャンペーン告知、サービス変更、障害時のお詫び、注文条件の変更などです。

一見すると短い文章に見えますが、実際に作ろうとすると、意外と考えることが多いです。

誰に向けたお知らせなのか。
何を一番伝えたいのか。
どの情報は必ず入れる必要があるのか。
お客様が誤解しそうな表現になっていないか。
アプリやWebの限られた表示エリアに収まるか。

こうしたことを毎回人の感覚だけで考えていると、文言の品質にばらつきが出たり、確認に時間がかかったりします。

そこで今回は、Difyを使って、お知らせ文言のたたき台を作成してくれるチャットボットを作ってみることにしました。

目的は、文章作成を完全にAIへ任せることではありません。

人が判断すべき部分は残しつつ、最初のたたき台作成や、確認観点の洗い出しをAIに手伝ってもらうことで、業務を少し進めやすくすることを目指しました。

作ろうと思った理由

お知らせ文言を作る業務では、文章を書くこと以上に、その後の確認や認識合わせに時間がかかることがあります。

Aさんが作った文言に対して、Bさんが別の観点で修正を入れる。
「この条件は入れた方がよい」「この表現は少し強い」「お客様には伝わりにくいかもしれない」といった確認が入り、何度も調整が発生する。

もちろん、確認すること自体は必要です。
ただ、毎回人の感覚に頼っていると、確認に手間がかかり、文言の品質にもばらつきが出やすくなります。

そこで今回は、お知らせ文言を作るときの観点をある程度そろえるために、Difyで「お知らせ文言アシストBot」を作ってみました。

AIに正解の文章を出してもらうというより、最初のたたき台を作り、確認すべきポイントを整理するためのBotです。

解決したかったこと

お知らせ文言は、短いからこそ難しいです。詰め込むと読みにくく、削ると大事な条件が伝わらない。
狙いは3つでした。

１）たたき台で初動を早めること。

２）確認観点（日付・対象店舗・注意事項など）の抜け漏れを減らすこと。

３）社内用語をお客さま向けのやさしい表現に整えること。

この3つを、Botに手伝ってもらう前提で設計しました。

何を作ったか

必要な情報を入力すると、お知らせに使える文言案一式が返ってくるチャットボットです。

入力（7項目）：

掲載場所
お知らせの種類
伝えたい内容
必ず入れたい情報
対象者
希望するトーン
文字量

出力（7項目）：

タイトル案
ポップ用の短い文言
詳細説明文
CTAボタン文言
誤解されそうなポイント
追加で確認したいこと
社内確認用コメント

単に文章を作るだけでなく、「誤解されそうなポイント」や「追加で確認したいこと」も一緒に出すのがこだわりです。そのまま出して大丈夫かを確認しやすくするためです。

使用したツール

ツール	用途
Dify	チャットボット本体の構築
チャットフロー	開始→LLM→回答のフロー構成
DSL（YAML）	アプリ構成の一括インポート
OpenAI API	文言生成のモデル

全体の流れ

まず全体像です。
今回は前半でMVP（実用最小限の製品。まず動く最小構成のこと）を作り、後半で自社ルールを反映しました。
この記事（前編）は紫の枠の部分です

この記事の範囲

前編：構想〜 MVP完成（紫の枠）　👈️この記事
- 属人化した確認から卒業｜Dify×ChatGPTで作るお知らせ文言アシストBot【前編：たたき台が出せるBotを構築】
後編：自社ルール反映（コーラルの枠）
- 属人化した確認から卒業｜Dify×ChatGPTで作るお知らせ文言アシストBot【後編：社内ルールをプロンプトで反映】

最初の分かれ道：チャットフローか、テキストジェネレーターか🤔

Difyには「テキストジェネレーター（フォーム入力→1回生成で完結）」と「チャットフロー（会話しながら進める）」があります。

今回の「フォームに入れて文言を出す」用途だけ見ると、実はテキストジェネレーターの方が素直です。それでもチャットフローを選びました。

💡 なぜテキストジェネレーターではなくチャットフローを選んだのか

このBotを単発で終わらせず、あとで育てたいと考えたからです。

具体的には、過去のお知らせ文例をRAGで参照させたり、LINEに繋いだりといった発展は、どちらも会話型（チャットフロー）を前提とします。

今回はその発展性を取って、土台をチャットフローにしました。

この選択が、あとで「UX上の引っかかり」というトレードオフを生むことになります（後述）。

制作手順

🔵Step 1. DSLファイルで土台を一気に作る

Difyの画面で1つずつ組むのではなく、アプリ構成をまとめて定義できるDSL（YAML）ファイルを使って土台を作りました。

理由は、入口の手作業に時間を使いすぎないためです。
今回大事にしたいのは画面操作の説明ではなく、後半の検証と磨き込み。
だから初期構築は効率化して、調整に時間を回す方針にしました。

DSLには、開始ノード（入力7項目）、LLMノード（システムプロンプト）、回答ノードをあらかじめ定義しておき、「DSLファイルをインポート」で取り込みます。

🛠️ DSLファイルはどうやって作る？ → 💡生成AIに作ってもらいました

「DSLを自分で1から書くのは難しそう…」と思うかもしれませんが、
今回は生成AI（Claude）に作ってもらいました。
やったことは、作りたいBotの仕様を言葉で伝えただけです。

具体的には、こんな情報を渡しました。

どんなBotか（お知らせ文言のたたき台を作るチャットボット）
入力したい項目（掲載場所・お知らせの種類・伝えたい内容…の7つ）
出力してほしい項目（タイトル案・本文・CTA…の7つ）
使いたいDifyのバージョン（※ここが意外と重要です⚠️）

特にDifyのバージョンを伝えるのが大事でした。
DifyはバージョンによってDSLの書式が変わるので、自分の環境（今回は v1.14.2）を伝えると、それに合わせたファイルを作ってくれます。
バージョンは、Difyの画面のアカウントメニューなどから確認できます。

できあがったYAMLファイルを保存して、Difyの「DSLファイルをインポート」で読み込めば完了です。

「作成する」ボタンを押します

以下の様なフローが設計できていればインポート成功です🎉

💡 ここでのポイント

DSLの中身を完全に理解していなくても、「何を作りたいか」を具体的に言葉にできれば、土台はAIに任せられます。大事なのは構文を覚えることではなく、作りたいものを正確に言語化すること。これは今回の記事全体のテーマ（AIに任せる部分と、人が判断する部分を分ける）とも繋がっています。

注意
Difyはバージョンで仕様が変わるため、DSLのインポートはこける場合があります。確実なのは手動構築ですが、まずインポートを試して、ダメなら手動に切り替えるのがおすすめ。インポートできても、LLMノードのモデルだけは選び直す前提にしておくと安全です（モデル指定が環境依存になりやすいため）。

🔵Step 2. APIキーを設定してプレビューで動かす

インポート後、OpenAIのAPIキーを設定し、「プレビュー」で入力できる状態にしました。
右上の「公開する」をクリックしてから、「プレビュー」を開きます。

※プレビューの前に、LLMノードのgpt-4oが赤くなっていない（＝エラーが出ていない）かだけ見ておきます。

赤くない／警告なし → OpenAIのキーが設定済み。そのまま進めてOK
赤い／「モデルが見つからない」等が出る → LLMノードをクリックして、OpenAIのキー設定済みのモデルに選び直してください。ここを直さないとプレビューで生成が止まります

※OpenAIキーの設定方法、こちらの記事にまとめました。
Dify×OpenAI APIキーの取得方法と設定手順はこちら

💡 なぜ gpt-4o を初期値にしたか

多くの環境で設定済みで、すぐ動かしやすい無難なデフォルトだからです。日本語が自然で、短い実務文を整えるのに十分な性能があり、速くて安い。今回のように「たたき台を量産して人が直す」用途では、最高性能より速さ・コスト・安定した日本語のバランスが効きます。もちろんモデルはあとから選び直せます。

プレビューを開きます

まずは、以下のケースで出力を確認します

項目	入力値
掲載場所	ネットスーパーWeb
お知らせの種類	メンテナンス
伝えたい内容	システムメンテナンスのため一時的に注文ができなくなる
必須で入れたい情報	6月30日（月）2:00〜5:00、メンテ中は注文・配送状況確認も不可
対象者	（空欄でOK）
希望するトーン	丁寧
文字量	標準

確認項目は以下とします。

１）必須情報 … 日時（6月30日 2:00〜5:00）と「できないこと」が本文に入っているか
２）見出し7つ … タイトル案／ポップ用ショート文言／詳細説明文／CTAボタン文言／誤解されそうなポイント／追加で確認したいこと／社内確認用コメント、が全部出ているか
３）トーン … 硬すぎ・冷たすぎないか

以下、3点チェックしました。

１）必須情報 … ⭕

日時（6月30日(月) 2:00〜5:00）も「注文・配送状況確認ができない」も本文に正しく反映されています。

むしろ詳細説明文で日時を独立した行に切り出していて、見落としにくい構成になっているのが良いです。

２）見出し7つ … ⭕

全部出ています。

タイトル案3／ポップ用ショート／詳細説明文／CTA3案／誤解されそうなポイント／追加で確認したいこと／社内確認用コメント。

フォーマット指定がきれいに効いています。

３）トーン …⭕

「平素より〜」「何卒ご理解とご協力を」と丁寧だけど硬すぎず、メンテナンス告知として自然な温度感です。

⇒ 質が高い回答結果でした🎉

ただ...ちょっと気にあるところがあります🤔

つまずき①：社内確認用コメントが毎回ズレる🫠
社内確認用コメントが少し用途とズレています。ここは本来「レビュー依頼するときに添える一文（例：日時と影響範囲を確認してほしい、という依頼文）」を想定していたのですが、出力は"文章の補足説明"になっているような気がします。
つまずき②：動かしてみたらUXが地味に気持ち悪い😳
「毎回フォーム＋ひとことチャット「作成して」が必要」というのは、正直ちょっと使いにくいです。毎回「作成して」と打たなくても、フォーム送信だけで生成が走るようにしたいです。

🔵Step 3. システムプロンプトを設計する

システムプロンプトは、AIへの指示書です。
Difyの編集画面でLLMノードをクリックすると書く欄が開きます（DSLインポートで下地が入っているので、中身を整える作業です）。

書いたのは以下の4ブロック。

役割（ネットスーパーのお知らせを作るUXライター）
方針（後述の勘所）
入力（フォームの7項目を 掲載場所: {{place}} のように変数で渡す）
出力フォーマット（7見出しを固定）

勘所は以下3つ。

勘所１） 出力を「たたき台」と明示して断定させない
勘所２） 入力にない事実（日時・金額・店舗名など）を創作させず、不足は「追加で確認したいこと」に回させる。
勘所３） 掲載場所に応じて文字量を変えさせる（POP・通知は短く、Web・メールは詳しく）。

出力の見出しを固定したのは、自由に答えさせると順番が変わったり項目が抜けたりするためです。
順番が決まっていると、確認もケース比較もしやすくなります！

🔵Step 4. 残り4ケースも検証する

実際の業務で起こりそうなパターンで出力を確認しました。
メンテナンス案内、注意喚起（注文変更）、一部店舗・一部商品が対象外、障害のお詫び2種です。

以下のケースで検証します。

ケースA：注意喚起（注文変更に関する注意）
ケースB：一部店舗・一部商品が対象外
ケースC：障害・お詫び（その1・サービス全体）
ケースD：障害・お詫び（その2・お詫びトーン指定）

アプリ＝短めの指定が効いて、ポップ文言が2文で簡潔。

「確定後は変更不可、ただしキャンセル→再注文で対応できる」という条件を、突き放さずやわらかく書けています。

誤解ポイントの「注文確定後も小さな変更は可能だと誤解される」は、まさに実務で問い合わせが来やすい所です。

誤解ポイントの「全商品・全店舗が送料無料になると誤解される可能性」を真っ先に挙げているのが良いところです。

タイトル案3つ目に「対象外店舗・商品にご注意ください」と注意喚起型を混ぜているのも実務的です。

対象外を箇条書きで構造化している点も読みやすい。

プロンプトの核は信頼できそうです！😳

誤解されがちな「”つながりにくい”だと完全停止と思われる→復旧済みを強調」は、障害告知の典型的な注意点を突いているためGoodです。

「追加で確認したいこと」でお詫びクーポンの有無に触れているのも、実務的です。

Cの「おまかせ」と読み比べると、Dは「深くお詫び申し上げます」「多大なるご迷惑」と謝意の語彙が一段強くなっていて、トーン指定がちゃんと出力に効いているのが確認できました。

トーンの振り幅が機能していることが、CとDのペアで実証できました。

5ケース通して、必須情報の欠落ゼロ・見出し7つ完備・トーン適切💯

最初のメンテナンス案内は、必須情報（日時・できないこと）が本文に入り、7見出しがすべて出て、トーンも丁寧すぎず冷たすぎない、という良好な結果でした🎉
とくに、入力した必須情報を「注文だけでなく配送状況確認もできない」と誤解ポイントとして拾えていたのが良かったです。
ただの清書ではなく、確認観点を出せている証拠です。

重点的に見たかったのは以下の2か所。

「一部対象外」のケースで、お得情報に対象外が埋もれず誤解ポイントとして前面に出るか。
- 「全商品・全店舗が対象と誤解される可能性」を真っ先に挙げて合格ですね。
障害のお詫びで、トーンが過剰に重くならないか。
- 「おまかせ」と「お詫び寄り」を比べると、後者で謝意の語彙が一段強まり、トーン指定が効いていることも確認できました。

🔵Step 5. つまずき①：社内確認用コメントが毎回ズレる🫠

5ケース通して、ひとつだけ共通の弱点が出ました。
「社内確認用コメント」が、毎回「この文章はこういう意図で書きました」という 出力の自己解説になっていて、
本来欲しかった 「レビュー依頼に添える申し送り」になっていなかったのです。

原因は、プロンプトでこの項目の役割を見出ししか書いていなかったこと。

そこで定義を具体化しました。

## 社内確認用コメント
（この文言案をレビュー依頼する際に、担当者へ添える申し送りを1〜2文で書く。
「どの情報を確認・確定してほしいか」を具体的に示す。出力内容の自己解説は書かない。）

ポイント

欄の役割を明示し、何を書くかを具体的に指定し、やってはいけないこと（自己解説）を名指しで禁止したことです。

修正後は4ケースとも「日時と対象範囲が確定情報か、公開前にご確認ください」のような申し送り調に変わり、ズレが解消しました！🎉
1ケースの偶然ではなくプロンプト定義の曖昧さが原因だと特定できたのが、検証の収穫でした。

各ケースの修正前後を比較したものは以下です。

🔵Step 6. つまずき②：動かしてみたらUXが地味に気持ち悪い😳

一通り動くようになって、UX的な引っかかりに気づきました。

チャットフローは会話のターンで動くため、フォームを全部埋めても、そのあとチャット欄に一度送信しないと生成が始まりません。「フォーム埋めたのに、まだ何か入れるの？何を？」という迷いが生まれます💦

ここで一度立ち止まりました。
これはプロンプトでは直せません。アプリタイプ（チャットフロー）の構造上の制約だからです。
選択肢は、テキストジェネレーターに作り直してこの1手間を構造的に消すか、チャットフローのまま導線で補うか。

最終的に「チャットフローのまま受け入れる」を選びました。
理由は、発展性（RAG・LINE）を取るために最初からチャットフローを選んでいたから。
1手間を消すために発展の道を閉じるのは本末転倒です。代わりに「会話の開始（あいさつ文）」をオンにして、最初の画面に「フォーム入力後、チャット欄に『作成』と送ると文言を作成します」という案内を出し、迷子をなくしました。

修正ポイントは２つです

１）チャット欄に「作成して」でも「.」でも何を送っても、必ず文言が生成されるように修正する
２）開始メッセージで何を送ればいいか明示する、案内文を掲載する。

１）チャット欄に「作成して」でも「.」でも何を送っても、必ず文言が生成されるように修正する

LLMノード、システムプロンプトの # 入力 ブロックと # 出力フォーマット ブロックの間に、
下の2行を挿入します。

# 指示
ユーザーからのメッセージ（{{#sys.query#}}）の内容にかかわらず、上記の入力条件に基づいて、ただちにお知らせ文言一式を作成してください。挨拶や確認の返答はせず、必ず出力フォーマットに沿った文言案のみを出力します。

*チャット欄に「あ」と入れて送信しても回答が返ってくるようになりました。

２）開始メッセージで何を送ればいいか明示する、案内文を掲載する。

空欄に「Talk to お知らせ文言ボット」とだけ出ていて迷子になりやすいため、はっきり導線を示すように修正します。
右上の「機能」を開いて、「会話の開始」（オープニング・あいさつ）をオンにし、文面を以下に設定します。

フォームに条件を入力して「Start Chat」を押したあと、
チャット欄に「作成」と送ると、お知らせ文言一式を作成します。

保存してプレビューで確認すると、以下のようにチャット画面に設定した文言が反映されております。

これで設定完了です🎉

次の記事につづきます

ここまでで、構想〜 MVP(まず動く最小構成のこと)まで完成しました。
次の記事では、作ったBotに社内ルールを覚えさせる工程を実施します。