生成AIで自動化したい業務を選んだ。
業務棚卸しシートにも書いた。
では、次に何をするか。
ここでいきなり仕組み化しようとすると、少し危ないです。
「問い合わせ返信をAIで自動化しよう」
「議事録を全部AIに任せよう」
「社内FAQ回答をAIで返せるようにしよう」
方向性としては悪くありません。
でも、最初から完成形を作ろうとすると、設定、権限、例外、確認者、失敗時の戻し方が一気に出てきます。
そして、だいたい止まります。
前回、生成AIの自動化候補は、業務棚卸しシートで小さく分ける で、AIに任せる候補は大きな業務名ではなく、作業の1手、入力情報、成果物、人が見る条件に分けると書きました。
その次は、いきなり本番導入ではなく、1週間の実験です。
1週間だけ、1つの作業で、AIを使ってみる。
使った結果をログに残す。
削減時間だけでなく、確認しやすかったか、手戻りが減ったか、怖くなく使えたかを見る。
このくらい小さく始めた方が、生成AIの自動化は社内に残ります。
中小機構の 中小企業のAI等の利活用に係る実態調査 でも、AI利活用は業務効率化だけでなく、品質向上や付加価値創出とセットで扱われています。
総務省・経済産業省の AI事業者ガイドライン第1.2版 でも、AIの利用状況やリスクを継続的に見直す考え方が整理されています。
IPAの AI利用者のためのセキュリティ豆知識 でも、AI利用時の入力情報や出力確認の注意点がまとめられています。
つまり、AI自動化は「作ったら終わり」ではありません。
使いながら、見直しながら、社内の判断基準にしていくものです。
生成AIの自動化実験は、最初から本番化せず、1週間のログで「続ける・直す・やめる」を判断できる状態にする。
今日は、業務棚卸し後にやる1週間のAI自動化実験ログの作り方を整理します。
自動化実験は「成功」より「判断できる状態」を作る
生成AIの自動化実験というと、成功させることを考えがちです。
もちろん、うまくいった方がいいです。
でも、最初の1週間でいきなり成功を狙いすぎると、判断が曖昧になります。
「なんとなく便利だった」
「思ったより微妙だった」
「結局、人が直した」
「たぶん続けたら良くなる気がする」
このくらいの感想で終わると、次に進めません。
成功したのか。
まだ直せばよいのか。
最初の候補としては重すぎたのか。
この判断が残らないからです。
AI自動化の最初の実験で作りたいのは、完璧な成果物ではありません。
判断できる状態です。
たとえば、問い合わせ返信の下書きをAIで作るとします。
1週間試した結果、返信文が毎回そのまま使える必要はありません。
むしろ、最初からそのまま使おうとする方が危ないです。
見るべきなのは、
- どんな問い合わせなら下書きが使えたか
- どんな問い合わせだと危なかったか
- 何を入力すると精度が上がったか
- 人がどこを直したか
- 社外送信前に必ず見る条件は何か
こういうことです。
ここが分かると、次の判断ができます。
この作業は続けてよさそう。
入力情報を増やせば改善できそう。
クレームや契約が絡むものは外した方がよさそう。
今は自動化より、FAQやサービス説明の整備が先かもしれない。
この判断ができれば、実験としてはかなり前に進んでいます。
逆に、下書きの出来だけを見て「使える」「使えない」で終わると、もったいないです。
生成AIは、魔法の自動化ボタンではありません。
業務の曖昧さを見える化する道具でもあります。
うまくいかなかった出力にも、情報があります。
入力が足りないのか。
判断条件が曖昧なのか。
成果物の形が決まっていないのか。
人が最後に見る場所が決まっていないのか。
ここを見つけるために、最初の1週間を使う。
「成功させる」より「判断できるようにする」。
この考え方に変えると、AI自動化の実験はかなり進めやすくなります。
1週間で見る作業は、入力・出力・確認・手戻りだけに絞る
1週間の実験ログは、項目を増やしすぎない方がいいです。
最初から細かく管理しようとすると、ログを書くこと自体が仕事になります。
そして、続きません。
ログ運用、気づいたらログのためのログになりがちです。ややこしい。
最初は4つで十分です。
入力。
出力。
確認。
手戻り。
この4つです。
入力は、AIに何を渡したかです。
問い合わせ本文、過去のFAQ、サービス説明、ヒアリングメモ、議事録、社内ルールなど。
ここが曖昧だと、出力も曖昧になります。
出力は、AIから何を受け取ったかです。
返信下書き、要約、分類、章立て、チェックリスト、FAQ候補など。
「何を出してほしかったか」と「実際に出てきたもの」がズレているなら、実験の大事な発見です。
確認は、人がどこを見たかです。
事実関係。
金額。
契約条件。
個人情報。
お客様への言い回し。
社外に出してよいか。
この確認ポイントが多すぎるなら、最初の自動化範囲が大きすぎる可能性があります。
手戻りは、どこを直したかです。
文章のトーンだけ直したのか。
事実確認が必要だったのか。
そもそも必要な情報が足りなかったのか。
AIが勝手に補った部分を消したのか。
ここを見ます。
1週間ログは、立派なレポートにしなくていいです。
1日1行でも構いません。
たとえば、こんな形です。
- 入力: 問い合わせ本文とFAQを渡した
- 出力: 返信下書きが出た
- 確認: 金額と納期表現を見た
- 手戻り: 事例表現が強すぎたので弱めた
このくらいで十分です。
大事なのは、毎回同じ観点で残すことです。
AIの出力を見て、その場で直して終わりにしない。
何を渡したか。
何が出たか。
どこを見たか。
どこを直したか。
これだけ残すと、1週間後に見返せます。
見返せるから、改善できます。
改善できるから、社内運用に近づきます。
実験ログには、AIの出来より人の判断理由を残す
AI自動化のログでよくあるのは、出力の評価だけを書くことです。
「良かった」
「微妙」
「使えなかった」
「要修正」
入口としては分かります。
でも、これだけだと次に活きません。
なぜ良かったのか。
なぜ使えなかったのか。
どこを人が見て判断したのか。
ここを残す必要があります。
たとえば、AIが問い合わせ返信の下書きを作ったとします。
文章はきれい。
でも、人が見て使わなかった。
このとき「使えなかった」だけだと、改善できません。
実際には、理由があるはずです。
お客様の状況を読み違えていた。
サービス対象外なのに前向きに書きすぎていた。
金額の表現が断定的だった。
契約前提の話を含んでいた。
過去のやり取りを見ないと返せない内容だった。
こういう判断理由が残ると、次の実験に使えます。
「過去のやり取りが必要な問い合わせは、最初の対象から外そう」
「金額や契約が入る返信は、人が全文確認する」
「FAQ内で答えられる質問だけに絞ろう」
このように、実験範囲が具体的になります。
逆に、人の判断理由が残らないと、担当者の頭の中にだけノウハウが残ります。
その人がいる間は回る。
でも、担当者が変わると戻る。
前に 生成AIの運用担当者が変わる前に、判断ログを引き継ぐ でも書きましたが、AI運用で引き継ぐべきなのはプロンプトだけではありません。
判断理由です。
なぜその出力を使ったのか。
なぜ止めたのか。
どこを人が直したのか。
その理由が残ると、次の人が同じ迷いを繰り返しにくくなります。
AIの出来を採点するだけではなく、人がどう判断したかを残す。
ここが、AI内製化の大事なところです。
失敗ログは、止める条件と次の改善候補に変える
1週間試すと、たぶん失敗も出ます。
思ったより使えなかった。
入力を増やしてもズレた。
確認が大変だった。
人が直す方が早かった。
こういう結果が出ると、がっかりします。
でも、そこで終わらせるのはもったいないです。
失敗ログは、止める条件と改善候補に分けます。
止める条件とは、「この条件ではAIに任せない」と決めるものです。
たとえば、
- 金額や契約条件を含む返信
- クレームやトラブル対応
- 個人情報が多く含まれる相談
- 過去の経緯を読まないと判断できない内容
- 社外送信まで自動で進む処理
こういうものは、最初の実験から外します。
外すことは失敗ではありません。
むしろ、止める条件が見えたなら前進です。
次に、改善候補です。
これは「少し直せば次に試せそう」なものです。
たとえば、
- 入力にFAQを足す
- サービス説明を短くまとめた資料を渡す
- 出力形式を返信文ではなく箇条書きの確認メモに変える
- 最初から社外向け文ではなく、社内確認用の要約にする
- 使ってよい例と使わない例を2つずつ渡す
こういう改善です。
ここで大事なのは、失敗を全部改善しようとしないことです。
1週間実験のあとに、改善案が10個出ることがあります。
でも、次にやるのは1つでいいです。
全部直そうとすると、また重くなります。
AI自動化は、最初から完璧な仕組みに育てるものではありません。
小さく試して、止める条件を決めて、改善を1つ選んで、また試す。
この繰り返しです。
失敗ログは、反省文ではありません。
次に安全に試すための材料です。
「これは危ないから外す」
「これは入力を変えればいけそう」
「これは成果物の形を変えた方がいい」
こう分けられると、AI活用はかなり現実的になります。
1週間後は、削減時間だけでなく安心して使えたかを見る
AI自動化の効果を見るとき、最初に出てくるのは削減時間です。
何分減ったか。
何時間浮いたか。
何件処理できたか。
もちろん大事です。
ただ、最初の1週間では、削減時間だけを見ると判断を間違えることがあります。
たとえば、AIで返信下書きを作った。
文章を書く時間は短くなった。
でも、確認が怖くて何度も読み直した。
結局、心理的には疲れた。
この場合、時間だけ見ると効果ありに見えます。
でも、現場には残りにくいです。
逆に、削減時間はまだ小さい。
でも、毎回ゼロから考える負担が減った。
確認ポイントが見えるようになった。
担当者が「まず下書きを出してから考えられる」と感じた。
この場合、最初の実験としては価値があります。
だから、1週間後に見る項目は時間だけではありません。
僕なら、次の5つを見ます。
- 作業時間は少しでも減ったか
- 手戻りは減ったか
- 確認ポイントは明確になったか
- 担当者が怖がらずに使えたか
- 次も同じ条件で試したいか
ここまで見ます。
特に「怖がらずに使えたか」は大事です。
AI活用は、便利そうに見えても、現場が不安なら止まります。
不安の正体は、AIそのものとは限りません。
何を入力してよいか分からない。
出力をどこまで信じてよいか分からない。
社外に出す前の確認者が決まっていない。
間違ったときに誰が戻すか決まっていない。
こういう運用の曖昧さが不安になります。
1週間ログは、この不安を見つけるためにも使います。
時間が減ったか。
でも、それだけではなく、安心して使えたか。
続けても現場が疲れないか。
この視点を入れると、AI自動化は数字だけの改善ではなく、運用として残りやすくなります。
前に AI活用の効果測定は、成果より先に運用ログから始める でも書いたように、初期の効果測定は売上や大きな成果より、運用ログから始めた方が見えやすいです。
小さな実験でも、ログがあれば次の判断につながります。
続ける・直す・やめるを決めて、次の1業務へ移す
1週間試したら、最後に決めます。
続ける。
直す。
やめる。
この3つです。
曖昧に「また検討します」で終わらせない方がいいです。
また検討します、はだいたい棚に戻ります。
そして、棚の奥で忘れられます。
続ける場合は、条件を決めます。
どの作業で使うのか。
誰が使うのか。
どこまでAIに任せるのか。
人はどこを見るのか。
ログはいつ見返すのか。
これを1ページで残します。
直す場合は、改善を1つだけ選びます。
入力資料を足す。
プロンプトを変える。
成果物を返信文から確認メモに変える。
対象業務をもう少し絞る。
確認者を決める。
どれか1つです。
やめる場合も、理由を残します。
この作業は例外が多すぎた。
個人情報が多く、最初の実験には向かなかった。
入力情報が整っていなかった。
AI以前に業務ルールの整理が必要だった。
こう残しておけば、やめたことも資産になります。
大事なのは、やめることを失敗扱いしすぎないことです。
最初のAI自動化実験は、合格か不合格を決める試験ではありません。
社内に残る使い方を見つける探索です。
だから、やめる判断にも価値があります。
そして、続ける・直す・やめるを決めたら、次の1業務へ移します。
業務棚卸しシートに戻って、次に小さく試せる作業を選びます。
問い合わせ返信下書きの次は、FAQ候補作成かもしれません。
議事録要約の次は、決定事項の抜き出しかもしれません。
提案書の章立ての次は、ヒアリングメモの整理かもしれません。
1つ試して、ログを見て、判断して、次へ移す。
この小さな循環ができると、AI活用は「詳しい人だけの取り組み」から「社内で育てる運用」に変わります。
生成AIの自動化は、大きな仕組みを一気に作るより、小さな実験ログを積み上げる方が強いです。
1週間でいい。
1作業でいい。
1日1行でいい。
その代わり、続ける・直す・やめるを決める。
ここまでやると、AI自動化はかなり現実の仕事に近づきます。
生成AIの自動化を始めるとき、最初に必要なのは大きなシステムではありません。
小さな実験と、見返せるログです。
業務棚卸しで候補を出し、1週間だけ試して、入力・出力・確認・手戻りを残す。
そして、最後に「続ける・直す・やめる」を決める。
この流れができると、AI活用は一度きりの試用ではなく、社内で育つ運用になります。
カタチ舎では、生成AIを導入して終わりにせず、業務整理、入力ルール、実験ログ、改善会議まで含めて、社内で使い続けられる形にする支援をしています。
「AI自動化を試したいけれど、何からログを取ればいいか分からない」
「業務棚卸し後の実験設計を一緒に作りたい」
そんな段階であれば、無料相談 から今の業務状況を聞かせてください。
小さく試せる1週間の実験から、一緒に設計します。
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。