生成AIの自動化を1週間だけ試した。
ログも残した。
使えた場面と、怖かった場面も少し見えてきた。
では、次に何を直すか。
ここでよく起きるのが、プロンプトだけを直してしまうことです。
「もっと詳しく指示を書こう」
「禁止事項を足そう」
「出力形式を決めよう」
もちろん、プロンプトを直すのは大事です。
でも、生成AIの自動化実験で見えた問題は、プロンプトだけの問題とは限りません。
入力情報が足りなかったのか。
出力の使い道が曖昧だったのか。
確認者が決まっていなかったのか。
例外が出たときの戻し方がなかったのか。
ここを見ないままプロンプトだけ整えると、文章はきれいになります。
でも、業務はあまり安定しません。
前回、生成AIの自動化実験は、1週間のログで小さく検証する で、最初は「続ける・直す・やめる」を判断できる状態にすると書きました。
今回は、その次の話です。
1週間試して見えたことを、どう業務手順へ戻すか。
プロンプトを磨くだけで終わらせず、社内で使い続けられる小さな手順書に変える方法を整理します。
経済産業省・総務省の AI事業者ガイドライン第1.2版 でも、AIの利用状況やリスクを継続的に見直す考え方が示されています。
IPAの AI利用者のためのセキュリティ豆知識 でも、入力情報や出力確認の注意点が整理されています。
つまり、AI活用は「よいプロンプトを作ったら終わり」ではありません。
使った結果を見て、業務側の手順を直していくものです。
生成AIの自動化実験後に直すべきなのは、プロンプト単体ではなく、入力・出力・確認・例外対応を含む業務手順です。
今日は、小さな会社やひとり社長が、生成AIの自動化を本番運用へ近づけるための手順化を考えます。
実験後に直すのは、プロンプトだけではない
生成AIの出力が思った通りにならないと、まずプロンプトを直したくなります。
これは自然です。
指示が曖昧だった。
前提条件を書き忘れた。
出力形式を指定していなかった。
こういう問題はたしかにあります。
ただ、1週間の自動化実験を見返すと、プロンプト以前の問題も出てきます。
たとえば、問い合わせ返信の下書きをAIに作らせたとします。
返信文の文章は悪くない。
でも、人が使うときに迷った。
その理由が、
- どのFAQを参考にしてよいか分からなかった
- サービス対象外の問い合わせをどう扱うか決まっていなかった
- 金額や納期の表現を誰が確認するか曖昧だった
- 過去のやり取りを見ないと判断できない内容が混ざっていた
- 急ぎのときにAI下書きを使ってよいか分からなかった
こういうものだったら、プロンプトだけを直しても足りません。
業務の前提が曖昧だからです。
ここでプロンプトに全部書き込もうとすると、長くなります。
禁止事項も増えます。
例外も増えます。
気づいたら、誰も読まないプロンプトになります。
説明書が巻物みたいになるやつです。開いた瞬間にそっと閉じるやつ。
だから、実験後に見る順番を変えます。
まず、プロンプトが悪かったのか。
それとも、業務手順が決まっていなかったのか。
ここを分けます。
プロンプトで直すものは、AIへの指示です。
業務手順で直すものは、人がどこまで準備し、どこを見るかです。
入力する資料。
使ってよい範囲。
人が確認する条件。
止める条件。
戻し方。
このあたりは、プロンプトの中に隠すより、業務手順として外に出した方が運用しやすいです。
AIに任せる前に、人が何を整えるか。
AIが出した後に、人がどこを見るか。
うまくいかなかったときに、どこへ戻すか。
ここまで見えると、生成AIの自動化は「担当者の勘」から少し離れます。
プロンプトを直す前に、業務手順を見直す。
この順番が大事です。
手順書には、入力・出力・確認者・止める条件を1枚で残す
生成AIの自動化手順書と聞くと、立派なマニュアルを想像するかもしれません。
でも、最初から分厚い手順書はいりません。
むしろ、最初は1枚で十分です。
1週間実験の後に作るなら、入れる項目はまず4つです。
入力。
出力。
確認者。
止める条件。
この4つです。
入力は、AIに渡す材料です。
問い合わせ本文だけなのか。
FAQも渡すのか。
サービス説明も渡すのか。
過去の対応履歴は渡してよいのか。
ここを決めます。
入力が決まっていないと、毎回その場の担当者判断になります。
すると、ある日は精度がよく、別の日は大きく外れます。
AIの性能というより、渡している材料が毎回違うからです。
次に出力です。
AIに何を出してほしいのかを決めます。
返信文そのものなのか。
返信前の確認メモなのか。
分類だけなのか。
FAQ候補なのか。
ここも大事です。
最初から社外送信用の完成文を出すより、社内確認用の下書きや要点整理にした方が安全な場面は多いです。
次に確認者です。
誰が最後に見るのか。
どの条件なら担当者だけでよいのか。
どの条件なら責任者へ回すのか。
確認者を決めるのは、責任を押し付けるためではありません。
現場が迷わず止まれるようにするためです。
最後に止める条件です。
たとえば、
- 金額や契約条件が含まれる
- クレームやトラブルが含まれる
- 個人情報が多い
- 過去の経緯を知らないと判断できない
- 社外送信まで自動で進めたくなる
こういう条件なら、AI活用を止める。
または、下書きまでで止める。
人の確認へ回す。
これを先に決めておきます。
この4つが1枚にあるだけで、AI自動化はかなり扱いやすくなります。
「このプロンプトを使ってください」だけではなく、
「何を入れ、何を出し、誰が見て、どこで止めるか」
ここまでセットにする。
これが、実験後の手順化です。
プロンプトは、業務手順の一部として扱う
プロンプトは大事です。
でも、プロンプトだけを特別扱いしすぎると、運用が属人化します。
「この人が作ったプロンプトならうまくいく」
「でも、他の人は触れない」
「少し業務が変わると直せない」
こうなると、AI内製化というより、プロンプト職人化です。
それはそれで技術としては面白いです。
でも、社内運用としては少し危うい。
小さな会社で続くAI活用にしたいなら、プロンプトは業務手順の一部として扱った方がいいです。
たとえば、問い合わせ返信の下書きなら、手順はこうです。
まず、問い合わせ本文を読む。
FAQにある内容か確認する。
サービス対象内かを見る。
AIに渡す材料をそろえる。
プロンプトを使って下書きを出す。
金額、納期、契約、個人情報を確認する。
必要なら責任者へ回す。
最後に送信する。
この流れの中に、プロンプトがあります。
プロンプトは真ん中の1工程です。
全部ではありません。
前に 生成AIの業務自動化は、いきなり連携より社内メモの型化から始める でも書きましたが、AIに渡す前のメモの型が整っていないと、出力も安定しにくくなります。
プロンプトだけが良くても、入力が毎回バラバラなら結果も揺れます。
確認の観点が決まっていなければ、出力後に迷います。
だから、プロンプトを直すときは、手順書の中で直します。
このプロンプトは、どの入力を前提にしているのか。
どの成果物を出すためのものか。
どこまで人が確認するのか。
どの条件では使わないのか。
ここを一緒に残します。
プロンプトを単体で保存するのではなく、業務名、入力、成果物、確認条件とセットで保存する。
そうすると、別の人が見ても使いやすくなります。
担当者が休んだ日にも、代理の人が判断しやすくなります。
プロンプトを磨くことは大事です。
でも、プロンプトを業務から切り離さない。
ここが、生成AIを社内に残すための現実的なコツです。
本番化の前に、例外と戻し方を通常業務へ入れる
1週間実験がうまくいくと、すぐ本番化したくなります。
「これ、毎日使えそう」
「もうこの業務はAIで回せそう」
「次は連携して自動で流したい」
気持ちは分かります。
ただ、本番化の前に必ず見たいものがあります。
例外と戻し方です。
実験中は、担当者がそばで見ています。
おかしな出力が出たら、その場で止められます。
分からない内容があれば、今まで通り人が処理できます。
でも、本番運用に近づくほど、処理は流れます。
流れると、止めるタイミングを逃しやすくなります。
だから、通常業務の中に例外ルートを入れておきます。
たとえば、問い合わせ返信の下書きなら、
- FAQにない内容は人が最初から書く
- 金額や契約条件がある場合はAI下書き後に責任者確認へ回す
- クレーム表現がある場合はAIに返信文を書かせず、要点整理だけにする
- 個人情報が多い場合は匿名化しても投入しない
- 過去の経緯が必要な場合は、履歴確認後に手作業へ戻す
こういうルートです。
ここで大事なのは、「例外をなくす」ことではありません。
例外が出ても戻れることです。
AI自動化は、全部を一直線に流すほど便利に見えます。
でも、小さな会社の最初の運用では、戻れる道がある方が強いです。
人が確認する。
手作業に戻す。
責任者へ回す。
いったん保留する。
この選択肢を、通常業務の中に入れておきます。
戻し方が決まっていない自動化は、うまくいっている間だけ動きます。
一度例外が出ると、現場が怖くなります。
「これ、次も使って大丈夫なんかな」
この不安が出ると、AI活用は止まります。
逆に、戻し方が決まっていれば、現場は試しやすくなります。
失敗しても戻せる。
止める条件がある。
確認者へ回せる。
だから、安心して使える。
本番化の前に見るべきなのは、成功した流れだけではありません。
失敗したときに、通常業務へ戻れるかです。
更新担当と見直し日を決めると、手順書は古くなりにくい
手順書を作っても、放っておくと古くなります。
生成AIの使い方は変わります。
社内のサービス説明も変わります。
問い合わせ内容も変わります。
担当者も変わります。
だから、手順書は完成物ではなく、更新物として扱った方がいいです。
ここで必要なのが、更新担当と見直し日です。
難しく考えなくて大丈夫です。
最初は、担当者名ではなく役割で決めても構いません。
「問い合わせ対応の責任者」
「営業資料を最終確認する人」
「AI活用の運用メモを見ている人」
このくらいで十分です。
大事なのは、誰かが「気づいたら直す」状態にしないことです。
気づいた人が直す運用は、最初は軽く見えます。
でも、だいたい誰も直さなくなります。
みんな忙しいので。人類、だいたい目の前の仕事に追われます。
だから、見直し日を入れます。
毎週でなくていいです。
最初は2週間後。
その後は月1回。
月次レビューのタイミングで見る。
このくらいで十分です。
見る項目も絞ります。
- この手順で使われたか
- 迷った場面はあったか
- 確認者へ回した場面はあったか
- 止める条件に追加すべき例外はあったか
- プロンプトではなく入力や確認手順を直す必要はあるか
これだけ見ます。
前に 生成AIの運用担当者が変わる前に、判断ログを引き継ぐ でも書いたように、担当者が変わるときに困るのは、手順そのものより判断理由です。
なぜこの確認者を入れたのか。
なぜこの条件ではAIに任せないのか。
なぜこの入力資料を使うのか。
こういう理由が手順書に少し残っているだけで、次の人は動きやすくなります。
手順書は、作って終わりではありません。
使って、迷って、直す。
更新担当と見直し日があると、この流れが止まりにくくなります。
小さな手順書から始めるほど、AI内製化は社内に残る
生成AIの自動化を社内に入れようとすると、つい大きく考えたくなります。
全社導入。
業務フロー刷新。
AIエージェント化。
システム連携。
言葉としてはかっこいいです。
でも、最初からそこを狙うと、決めることが多すぎて止まりやすいです。
対象業務。
権限。
入力情報。
確認者。
例外対応。
教育。
費用。
セキュリティ。
全部まとめて考えると、前に進める前に疲れます。
小さな会社やひとり社長が最初に作るべきなのは、完璧なAI運用規程ではありません。
1つの業務で使える、小さな手順書です。
問い合わせ返信の下書き手順。
議事録から決定事項を抜き出す手順。
営業資料の構成案を作る手順。
FAQ候補を出す手順。
社内メモを要約する手順。
こういう小さな単位で十分です。
小さな手順書が1つできると、次の業務にも応用できます。
入力を決める。
出力を決める。
確認者を決める。
止める条件を決める。
戻し方を決める。
見直し日を決める。
この型が見えてきます。
型が見えると、AI活用は担当者の頭の中だけに残りません。
社内の共有資産になります。
「あの人しか使えない」から、「この手順なら他の人も試せる」へ変わります。
ここまで来ると、生成AIの自動化は少しずつ内製化に近づきます。
AI内製化は、すごいプロンプトを1つ作ることではありません。
小さく試した結果を、次の人も使える手順へ戻すことです。
プロンプトは、その中の大事な部品です。
でも、部品だけでは業務は回りません。
入力。
出力。
確認。
例外。
戻し方。
見直し。
ここまで含めて、ようやく運用になります。
もし、生成AIの自動化を試したけれど、次に何を整えればよいか分からない場合は、まず1つの業務だけを選んでください。
その業務について、1週間ログを見返し、プロンプトではなく手順として何を直すべきかを一緒に整理できます。
カタチ舎では、生成AIの導入そのものよりも、現場で無理なく続く形に落とし込む支援をしています。
相談してみる から、今の業務、試したAI活用、止まっている理由を教えてください。
小さな手順書から、社内に残るAI活用へ変えていきましょう。
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。