属人化した確認から卒業｜Difyで作るお知らせ文言アシストBot【試運転編：チームで試して業務に活かせるか検証する】

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

前編・後編で、Difyを使ってお知らせ文言のたたき台を作る「お知らせ文言アシストBot」を構築し、社内ルールをプロンプトに反映するところまで進めました。

👇️ 「Difyで作るお知らせ文言アシストBot」制作編はこちらです
【前編：たたき台が出せるBotを構築】
【後編：社内ルールをプロンプトで反映】

作ってみて「これは実際にチームで使ってもらいたい」と思ったのですが、
新しいツールをいきなり現場に持ち込んでも、なかなか受け入れてもらえません。
まずは上司やチームメンバーに安心して試してもらうための、説明資料が必要だと考えました。
この記事はそのための資料です。

新しいツールは、効果を説明されるより「何をどこまでやってよいか」の線がはっきり見えたときに、はじめて安心して使えます。
上司にも、一緒に使うチームメンバーにも、その境界が伝わるように整理しました。
同じく「AIで作ったものを業務にどう持ち込むか」で迷っている方の参考になればと思います。

ℹ️ この記事に出てくる人数・期間・回数などの数値は、進め方をイメージしやすくするための仮の目安です。実際の値は、チームの状況に合わせて調整する前提です。

ご相談したいこと（結論から）

先に結論です。お願いしたいのは次の1点です。

Difyで作ったお知らせ文言アシストBotを、限定メンバー・ダミーデータで、期間を区切って試運転させてください。

試運転では個人情報や社外秘は一切入れず、公開済み・外向けに説明できる情報だけを使います。
まず小さく試して効果を見たうえで、本運用に進むかを判断します。
以下は、その判断材料の整理です。

1. この資料の目的

Difyで作成した「お知らせ文言アシストBot」を、チーム内で小さく試運転するための進め方を整理します。

このBotは、お知らせ文言をAIに完全に任せるものではありません。目的は、お知らせ文言のたたき台作成と、確認観点の整理を支援することです。

現時点ではプロトタイプとして、個人のAPIキーで動作確認しています。ただしチームで利用する場合は、APIキーの管理、入力情報の範囲、費用、社内ルールとの整合性を整理する必要があります。最終的には、会社管理のAI基盤が利用できる場合は、そちらに切り替えて本運用することを想定しています。

2. 背景

お知らせ文言の作成では、文章を書くことそのものよりも、その後の確認や調整に時間がかかることがあります。

たとえば、Aさんが作成した文言に、Bさんが別の観点で修正を入れる。「この条件は入れた方がよい」「この表現は少し強い」「お客さまには伝わりにくいかも」「お詫びとしてトーンが弱い（または強すぎる）」——確認する人によって観点が少しずつ違うと、何度も調整が発生します。

もちろん人による確認は必要です。ただ毎回その場の感覚に頼ると、確認に時間がかかり、文言品質にもばらつきが出ます。そこで、お知らせ文言を作るときの観点をある程度そろえ、最初のたたき台と確認ポイントをAIで整理できないかを検証したい、というのが出発点です。

3. 作成したもの

Difyで「お知らせ文言アシストBot」を作成しました。必要な情報を入力すると、お知らせ文言のたたき台を生成します。

入力項目	内容
掲載場所	Web、アプリ、メール、店頭POPなど
お知らせの種類	メンテナンス、注意喚起、障害・お詫びなど
伝えたい内容	お客さまや関係先に伝えたい概要
必須で入れたい情報	日時、対象範囲、影響内容、注意事項など
対象者	お客さま、関係先、社内関係者など
希望するトーン	丁寧、お詫び寄り、簡潔、やわらかめなど
文字量	短め、標準、詳しめなど

出力項目	内容
タイトル案	お知らせの見出し候補
短い文言	ポップやアプリ内表示に使いやすい短文
詳細説明文	Webページやメール等に使える説明文
CTA文言	ボタンやリンクに使える文言
誤解されそうなポイント	ユーザーが迷いやすい点
追加で確認したいこと	入力情報だけでは不足している点
社内確認用コメント	関係者に確認を依頼するための文章

すでに実際の業務に近い5ケース（メンテナンス案内、注意喚起、障害のお詫びなど）で検証済みで、必須情報の抜けがなく、確認観点まで出せることを確認しています。構築・検証の詳細は前編・後編にまとめています。

4. 今回の基本方針

進め方は2本立てです。

ひとつは、制限つきで小さく試運転すること。会社管理のAI基盤がすぐ使えるとは限らないため、まずは個人のAPIキーを使う場合でも、入力ルールや利用範囲を決めたうえで限定的に検証します。

もうひとつは、並行して会社管理のAI基盤が利用できるかを社内確認すること。会社のAI利用方針に沿って本運用するには、会社管理の基盤を使えるかの確認が必要です。

フェーズ	内容	目的
Step 1	個人APIキーで制限つき試運転	Botが業務に役立つか小さく検証する
Step 2	会社管理AI基盤の利用可否を社内確認	会社の基盤で運用できるか確認する
Step 3	試運転結果を評価	文言品質・確認負荷・使いやすさを見る
Step 4	本運用判断	好評かつ基盤が利用可なら本運用を検討する

5. 試運転の位置づけ

今回は本運用ではありません。以下を確かめる小さな検証です。お知らせ文言のたたき台作成に使えるか。確認観点の整理に役立つか。人による修正・確認の負担を減らせそうか。入力項目やプロンプトに不足がないか。実務で使う場合にどんなルールが必要か。試運転段階では、利用範囲と入力情報を制限します。

6. 試運転の「やってよい範囲」（ここが一番大事）

新しいツールを使うとき、いちばん不安なのは「どこまでやっていいか分からない」ことです。そこで、試運転の境界をはっきり決めておきます。

⚠️ 以下の人数・期間・回数は、進め方をイメージするための仮の目安です。実際の運用に合わせて調整します。

誰が使う（仮）
チーム内の3〜4名程度から。まず顔の見える限られたメンバーで始めます。いきなり全員ではなく、小さく試します。

いつまで（仮）
まず2週間で一区切り。区切りで振り返り、続ける・広げる・やめるを判断します。「いつ終わるか分からない」状態を作らないため、期限を先に決めます。

1日どれくらい（仮）
1人あたり1日10件程度を目安の上限に。使いすぎ（費用・想定外の動き）を防ぎつつ、実務で試すには十分な回数です。

困ったときの窓口
使い方や判断に迷ったら、ももっぺ（作成者）に聞いてください。「分からなくなったら誰に聞けばいいか」を決めておくことで、安心して踏み出せます。

やめる基準（撤退ライン）
次のいずれかが起きたら、いったん試運転を止めて見直します。禁止情報が入りそうな運用になっている、出力の品質が実務に耐えない、費用が想定を超えそう、現場の負担がむしろ増えている。うまくいかなくても小さく引き返せる設計にしておきます。

7. 試運転時の利用ルール案

項目	ルール案
利用範囲	UI/UXチーム内など、限定メンバーで実施
利用目的	お知らせ文言のたたき台作成、確認観点の整理
利用期間	2週間〜1か月程度（数値は仮）
APIキー	暫定的に個人APIキーを使用する場合あり
入力データ	ダミー情報、公開済み情報、外向けに説明可能な情報
禁止データ	個人情報、認証情報、内部ログ、未公開数値、社外秘情報
出力の扱い	そのまま掲載せず、必ず人が確認する
費用管理	月額上限を決め、利用状況を確認する
評価方法	利用者のフィードバック、作成時間、修正回数、品質感で確認する

8. 入力してよい情報・避ける情報

障害やメンテナンスのお知らせを作る場合、一定の情報は必要になります。ただしBotに入れる情報は「お客さまや関係先に説明してよい粒度」まで丸めることを前提とします。

入力してよい情報

情報	例
発生日時	7月5日 10:00頃から
影響範囲	一部店舗、一部サービス、一部決済手段
お客さまへの影響	注文が完了しづらい、配送状況が確認できない
現在の状態	対応中、復旧済み、原因確認中
案内したい内容	時間をおいて再度お試しいただきたい
関係先向け補足	問い合わせ時の案内方針、確認依頼事項

入力を避ける情報

情報	理由
個人情報	氏名、電話番号、メールアドレス、会員ID、注文番号など
認証情報	APIキー、トークン、パスワード、シークレットなど
内部ログ	エラーログ、スタックトレース、DBログなど
システム構成情報	サーバー名、IPアドレス、内部URL、APIエンドポイントなど
未確定の原因	誤った説明文が生成される可能性がある
未公開の影響数値	影響件数、売上影響、損害額など
社内責任情報	担当部署、個人名、取引先責任など

試運転時は、障害情報を完全に禁止するのではなく、外向けに説明できる粒度に要約して入力します。

9. 費用の考え方

APIの費用は、基本的に「入力した文章量」と「AIが生成した文章量」に応じて発生します（トークンという単位で計算されます）。試運転レベルの利用であれば実費はごくわずかで、まとまったコストが先に発生するものではありません。

試運転段階では、コストそのものより次の管理が重要です。利用回数を限定する、利用メンバーを限定する、月額上限を決める、利用ログを定期的に確認する、本運用前に会社管理の課金方法へ切り替える。

費用は大きな懸念ではないものの、個人APIキーのままチーム利用すると、請求や管理責任が個人に紐づいてしまいます。そのため試運転は暫定対応とし、本運用では会社管理のAPIキーまたは会社管理のAI基盤の利用を前提にします。

10. 会社管理のAI基盤について（確認が必要な理由）

会社としてAI活用を進めるなら、個人契約のAPIキーではなく、会社管理のAI基盤で運用できることが望ましいです。

ここで整理しておきたい点があります。会社で推奨されているCopilotのような「製品・サービス」は、Difyのような外部ツールからAPIで直接呼び出す使い方を想定していません。一方、同じ系統のモデルをAPI経由で呼び出せる会社管理の基盤であれば、Difyから利用できる可能性があります。つまり「会社推奨のAIに寄せる」意図は、製品をそのまま繋ぐのではなく、会社管理のAI基盤（API）に載せる形で実現するのが筋です。

ただし、それがすぐ使えるとは限りません。会社として契約しているか、利用申請が必要か、Difyから接続してよいか、APIキーを誰が管理するか、入力してよい情報の範囲、ログや監査の扱い——これらは個人判断ではなく、管理部門への確認が必要です。

11. 社内で確認したいこと

会社管理のAI基盤の利用可否について、以下を確認したいです。

確認項目	確認したい内容
基盤の利用可否	会社契約として利用できるか
Dify接続可否	DifyからAPIを呼び出してよいか
APIキー管理	どの部署・誰が管理するか
利用申請	利用にあたって申請や承認が必要か
入力可能な情報	お知らせ文言作成で入力してよい情報の範囲
入力禁止情報	個人情報、社外秘、障害詳細などの扱い
ログ管理	入力内容・出力内容・利用履歴の確認方法
費用管理	どの予算で負担するか、月額上限を設定できるか
本運用条件	どの状態になれば正式利用できるか

12. 本運用判断の考え方

試運転結果と会社管理AI基盤の利用可否をもとに、本運用するかを判断します。

試運転結果	基盤の利用可否	判断
好評	利用可	本運用を検討
好評	利用不可・未定	制限つき試運転を延長、または別の会社管理基盤を検討
課題あり	利用可	Botやプロンプトを改善して再検証
課題あり	利用不可・未定	試運転終了またはテーマ見直し

本運用に進める条件は、チーム内で一定の効果が確認できた・お知らせ文言のたたき台として使える・確認観点の整理に役立つ・入力ルールが整理できている・会社管理のAI基盤で運用できる・APIキーやログの管理方法が明確になっている、を想定します。

13. 試運転で確認する評価ポイント

文言品質：お客さま向けにわかりやすいか。表現が強すぎ・弱すぎないか。社内用語がそのまま出ていないか。必須情報が抜けていないか。

確認負荷：たたき台作成の時間が短くなるか。確認観点が整理されるか。修正のやり取りが減りそうか。担当者による品質のばらつきが減りそうか。

業務適合性：実際の業務フローに組み込めそうか。入力項目は使いやすいか。出力形式は確認しやすいか。社内確認用コメントは使えるか。

安全性：入力禁止情報を入れずに使えるか。外向け説明レベルに丸めて入力できるか。出力を人が確認する運用にできるか。個人キー利用のリスクを限定できているか。

14. まとめ

今回の取り組みは、AIを使うこと自体が目的ではありません。お知らせ文言作成時の確認負荷や、担当者ごとの品質のばらつきを減らすために、小さなプロトタイプで業務改善の可能性を検証するものです。

大事にしたのは、「どこまでやってよいか」の線を先に決めることです。誰が・いつまで・どれくらい・困ったら誰に聞くか・どうなったらやめるか。この境界があると、上司も、一緒に使うメンバーも、安心して試せます。

まずは制限つきで小さく試し、並行して会社のAI基盤で運用できるかを確認する。試運転で手応えがあり、運用の見込みが立った場合に、本運用へ進める——という順序で進めたいと考えています。