生成AIの出力を確認していると、こんな場面が出てきます。
「ここ、ちょっと違う」
「この表現は強すぎる」
「この情報はまだ出しちゃだめ」
「次は、先に条件を聞いてから返信した方がいい」
確認者が気づいて、文章を直す。
内容を差し戻す。
責任者へ回す。
ここまでは、とても大事です。
ただ、そのあとに何も残さないと、次回も同じところで止まります。
前回、生成AIの確認者は、専門家より業務の違和感に気づける人から育てる で、AIの出力確認は「AIに詳しい人」だけでなく、業務の違和感に気づける人から始められると書きました。
今回は、その次の話です。
確認者が気づいた違和感を、どう残すか。
修正理由を、次回のプロンプトや手順へどう戻すか。
ここが抜けると、生成AI活用は「毎回その場で人が直す作業」になります。
それ、AIを使っているのに、地味に人力が増えるやつです。なんでやねん案件です。
でも逆に、修正理由を1枚の改善ログとして残せると、AI活用は少しずつ育ちます。
プロンプトも直せる。
確認者の見る場所もそろう。
例外対応もたまる。
社内教育や月次レビューにも戻せる。
総務省・経済産業省の AI事業者ガイドライン第1.2版 でも、AIを安全に活用するための体制やリスク対応は、継続的に見直すものとして扱われています。
IPAの AI利用者のためのセキュリティ豆知識 でも、AI利用者やマネージャーが最低限の対策を理解し、今後のユースケースに合わせて更新していく考え方が示されています。
また、中小機構の 中小企業のAI等利活用に係る実態調査 では、AI導入目的として業務効率化や作業時間短縮が大きく扱われています。
ただ、効率化は「AIに投げたら終わり」ではありません。
人が直した理由を、次の運用へ返していくことで初めて、同じ確認を減らせます。
生成AIの改善ログは、失敗を責める記録ではなく、次回のAI活用を少し楽にする記録です。
今日は、小さな会社やひとり社長が、生成AIの出力確認をやりっぱなしにしないために、修正理由を改善ログへ残す方法を整理します。
改善ログは、AIの失敗記録ではなく次回の下書きになる
生成AIの改善ログというと、少しかたい印象があります。
ログ。
記録。
レビュー。
管理表。
この言葉だけで、もうお腹いっぱいになる人もいると思います。
でも、最初から立派な管理表を作る必要はありません。
改善ログの役割は、AIの失敗を並べることではありません。
次回、同じ業務でAIを使うときの下書きを残すことです。
たとえば、問い合わせ返信の下書きをAIに作ってもらったとします。
確認者が見て、こう直しました。
- お客様へ断定しすぎていた
- 先に確認すべき条件が抜けていた
- 金額の話が早すぎた
- 返信トーンが少し冷たかった
- 社内だけで使う言葉が混ざっていた
この修正を、その場で文章だけ直して終わると、次回も同じ確認が必要になります。
でも、改善ログに一言残せば、次回の使い方が変わります。
「問い合わせ返信では、金額を断定する前に条件確認を入れる」
「初回返信では、提案より先に不安の受け止めを入れる」
「社内用語はそのまま出さず、お客様向けの言葉へ置き換える」
こういう一文が、次回のプロンプトや確認チェックに使えます。
つまり改善ログは、過去の失敗帳ではありません。
未来の下書きです。
ここを間違えると、ログが重くなります。
「誰がミスしたか」
「なぜAIが間違えたか」
「どの出力が悪かったか」
そこばかり見ると、現場は記録したくなくなります。
生成AIの運用で大事なのは、犯人探しではなく、次に少し良くすることです。
前に 生成AIの自動化実験後は、プロンプトより業務手順を直す でも書いたように、AI活用はプロンプトだけ直しても安定しません。
入力。
出力。
確認者。
止める条件。
例外。
戻し方。
この業務手順のどこを直すかまで見ないと、また同じところで詰まります。
改善ログは、その手順を直すための材料です。
AIに任せたら何が起きたか。
人がどこで止めたか。
なぜ直したか。
次はどこを変えるか。
これだけ残っていれば、十分に価値があります。
最初の改善ログは、きれいな台帳でなくていいです。
スプレッドシート1枚。
Notionの小さな表。
共有ドキュメントの見出し。
手元の業務メモ。
まずは、確認者が直した理由を1行で残せる場所を作ります。
残す項目は、修正前、修正理由、次に直す場所の3つでいい
改善ログを始めるときに、項目を増やしすぎると続きません。
日時。
担当者。
業務名。
プロンプト。
AI出力。
修正後。
判断者。
リスク分類。
対応状況。
再発防止策。
重要度。
影響範囲。
全部あった方が良さそうに見えます。
でも、小さな会社で最初からここまでやると、ログを書くための業務が生まれます。
それは本末転倒です。
最初は、3つでいいです。
1つ目は、修正前に何が起きたか。
2つ目は、なぜ直したか。
3つ目は、次にどこを直すか。
たとえば、こんな形です。
- 修正前：AIが初回返信で料金を断定した
- 修正理由：条件確認前に金額を出すと誤解が起きる
- 次に直す場所：プロンプトに「初回は条件確認を優先」と追加する
これで十分です。
もう少し余裕があれば、業務名と確認者だけ足します。
- 業務名：問い合わせ返信
- 確認者：営業担当
- 修正前：AIが初回返信で料金を断定した
- 修正理由：条件確認前に金額を出すと誤解が起きる
- 次に直す場所：プロンプトに「初回は条件確認を優先」と追加する
このくらいなら、確認直後に残せます。
ポイントは、AIの出力全文を毎回保存しようとしないことです。
もちろん、重要な業務やリスクがある業務では、証跡として全文を残す設計が必要な場合もあります。
ただ、日常の小さなAI活用では、全文保存から入ると重くなります。
まずは「どんなズレがあり、なぜ直し、次に何を変えるか」を残します。
これなら、3分で書けます。
3分で残せないログは、現場ではだいたい続きません。
あくまで、最初の目的は改善です。
監査資料を完成させることではありません。
責任追跡を完璧にすることでもありません。
次に同じ出力を少し減らすことです。
ここを外さない方がいいです。
改善ログを1枚にするなら、項目はこうです。
- 日付
- 業務名
- 確認者
- 修正前のズレ
- 修正理由
- 次に直す場所
- 対応済みか
これ以上は、必要になってから足せばいいです。
最初から完璧な台帳にしようとすると、台帳が完成する前に運用が止まります。
いや、ほんとに。台帳づくりで燃え尽きるの、あるあるです。
確認者の判断を、プロンプトだけに閉じ込めない
生成AIの改善というと、すぐにプロンプトを直したくなります。
「もっと具体的に書こう」
「禁止事項を追加しよう」
「出力形式を指定しよう」
「参考例を入れよう」
もちろん、プロンプト改善は大事です。
でも、確認者の判断を全部プロンプトに詰め込むと、だんだん使いづらくなります。
プロンプトが長くなる。
誰も読まなくなる。
どこを直したのか分からなくなる。
例外が増えすぎて、毎回コピペするだけになる。
そして最後に、「このプロンプト、誰が管理してるんでしたっけ」となります。
これは避けたいです。
確認者が気づいたことは、プロンプトに入れるもの、手順に入れるもの、確認チェックに入れるものに分けます。
たとえば、AIが毎回お客様名を間違えやすいなら、プロンプトだけでなく入力手順を直すべきかもしれません。
「お客様名は問い合わせフォームの表記をそのまま貼る」
「会社名と担当者名を分けて入力する」
これは、プロンプトより入力手順の話です。
AIが毎回、金額や納期を断定してしまうなら、プロンプトに禁止を入れるだけでなく、確認チェックにも入れます。
「金額、納期、契約条件を断定していないか」
これは、確認者が見る場所です。
AIが毎回、社内用語を混ぜるなら、言い換え表を用意した方がいいかもしれません。
「案件」ではなく「ご相談内容」
「要件」ではなく「必要な内容」
「稼働」ではなく「対応時間」
これは、用語集やテンプレートの話です。
つまり、改善ログに残す「次に直す場所」は、プロンプトだけではありません。
- 入力前の情報整理
- AIへ渡すプロンプト
- 出力形式
- 確認者のチェック項目
- 社内用語の言い換え
- 責任者へ回す条件
- お客様へ追加質問する流れ
この中から、どこを直すかを選びます。
ここを分けられると、生成AI活用が一段安定します。
AIにうまく指示する力だけでなく、業務を整える力に変わるからです。
IPAのデジタルスキル標準ver.2.0でも、AI活用やAIガバナンスに関するスキルの拡充が示されています。
これは大企業だけの話ではありません。
小さな会社でも、AIを使うなら「誰が、どこで、何を見て、どう直すか」を少しずつ形にする必要があります。
改善ログは、そのための接着剤みたいなものです。
接着剤って急に工作っぽいですが、まあ、業務とAIをくっつけるものです。
例外対応は、責めるより分岐として残す
生成AIの運用で地味に大事なのが、例外対応です。
いつもの問い合わせならAIで下書きできる。
でも、少し複雑な相談が来た。
いつものFAQならAIで整理できる。
でも、個人情報が多く含まれていた。
いつもの議事録ならAIで要約できる。
でも、契約条件や責任範囲の話が入っていた。
こういうときに、AIを使うか、人へ戻すか、責任者へ回すかを決めます。
例外対応は、うまくいかなかった記録ではありません。
次回の分岐条件です。
たとえば、改善ログにこう残します。
- 修正前：AIが契約条件に関わる内容まで返信案に入れた
- 修正理由：契約条件は担当者判断だけで外部送信しない
- 次に直す場所：「契約、金額、納期、責任範囲が出たら責任者確認」と手順に追加
これは、AIの失敗というより、業務の分岐です。
「ここから先は人が見る」
「ここはAIに書かせず、質問だけ整理させる」
「ここは社外送信前に責任者へ回す」
そういう分岐が増えると、AI活用は安全になります。
逆に、例外を毎回その場で処理していると、担当者の頭の中だけに判断がたまります。
すると、別の人が同じ業務をしたときに止まります。
また説明する。
また同じ確認をする。
また同じ判断をする。
この繰り返しが、AI活用の属人化です。
生成AIの運用では、成功例より例外の方が学びになることがあります。
なぜなら、例外にはその会社の判断基準が出るからです。
どこまでAIに任せていいか。
どこから人が見るか。
どの表現はお客様に出さないか。
どの情報は社外へ出さないか。
どの案件は責任者へ回すか。
これは、テンプレートだけでは作れません。
実際の確認レビューから拾うしかありません。
だから、例外対応は責めずに残します。
「またAIが変なことをした」ではなく、
「ここは次回から分岐にしよう」
そう見ます。
この見方に変えるだけで、改善ログはかなり使いやすくなります。
1週間分を見て、直す手順を1つだけ選ぶ
改善ログは、書くだけでは意味がありません。
見返して、どこを直すか決めるところまでがセットです。
ただし、毎日完璧にレビューしなくていいです。
最初は1週間分で十分です。
1週間、AIを使った業務で修正理由を残す。
週末か週明けに、10分だけ見返す。
そして、翌週直す手順を1つだけ選ぶ。
これくらいが現実的です。
たとえば、1週間分の改善ログを見ると、同じズレが何度も出ていることがあります。
- 初回返信で金額を早く出しすぎる
- 問い合わせ内容を要約しすぎて、不安の受け止めが抜ける
- 社内用語がそのまま残る
- 確認者が毎回、納期の表現を直している
- 個人情報を含む文章をAIに渡す前の整理がばらつく
この中から、全部直そうとしない方がいいです。
全部直そうとすると、翌週の改善が重くなります。
前に 生成AIの改善タスクは、月次レビュー後に1つだけ実行する でも書いたように、改善案は増やすより、動く形に絞った方が続きます。
1週間レビューでも同じです。
翌週直すのは、1つでいいです。
たとえば、こう決めます。
「問い合わせ返信プロンプトに、初回は金額を断定しない条件を追加する」
「確認チェックに、納期・金額・契約条件の断定確認を足す」
「社内用語の言い換え表を5語だけ作る」
「AIに渡す前に、個人情報を外す欄を作る」
「責任者確認へ回す条件を3つに絞る」
これくらいなら、翌週試せます。
大事なのは、改善ログから具体的な1手に変えることです。
ログを眺めて「いろいろ課題がありますね」で終わると、何も変わりません。
改善会議あるあるです。
課題は見えた。
議事録もできた。
でも、誰も何も変えていない。
いや、会議した意味どこ行った。
そうならないために、改善ログを見る日は、最後に必ず1つ決めます。
来週、どの手順を直すか。
誰が直すか。
いつまでに試すか。
どの業務で試すか。
これだけでいいです。
改善ログは、分析資料ではありません。
翌週の小さな実行を決めるための材料です。
改善ログは、社内教育と月次レビューへ戻す
改善ログが少したまってきたら、社内教育と月次レビューへ戻します。
ここまでやると、AI活用が「担当者だけの工夫」から「社内の運用」に変わります。
たとえば、問い合わせ返信の改善ログがたまったとします。
そこから、社内教育で共有できることがあります。
- AIの下書きをそのまま送らない
- 金額や納期は条件確認前に断定しない
- お客様の不安を受け止めてから説明する
- 社内用語はお客様向けの言葉に直す
- 契約や責任範囲の話は責任者へ回す
これなら、AI研修としても実務に近いです。
ツールの機能説明だけではなく、自社の業務で実際に起きたズレから学べます。
小さな会社では、この方が効きます。
なぜなら、抽象的なAIリテラシーより、「うちの業務ではここを見る」の方がすぐ使えるからです。
月次レビューにも戻せます。
1ヶ月分の改善ログを見て、こう確認します。
- 同じ修正が何度も起きていないか
- プロンプトで直せるものはあるか
- 手順に戻すべきものはあるか
- 確認者の負担が増えすぎていないか
- AIに任せない方がいい業務が混ざっていないか
- 次月に1つだけ改善するなら何か
ここまで見られると、AI活用の月次レビューがかなり実務的になります。
「AIをどれだけ使ったか」だけではなく、
「どこで人が直したか」
「なぜ直したか」
「次はどこを変えるか」
を見られるからです。
生成AIの内製化は、ツールを入れることではありません。
社内で使い方を直せるようになることです。
プロンプトを直せる。
手順を直せる。
確認者を育てられる。
例外対応を増やせる。
教育内容を更新できる。
その積み重ねが、内製化です。
改善ログは、その中心に置けます。
もちろん、最初から全部やる必要はありません。
まずは、確認者が直した理由を1行残す。
次に、1週間分を見て1つ直す。
その後、月次レビューや教育へ戻す。
この順番で十分です。
AI活用を始めたばかりの会社ほど、ログを大げさにしない方がいいです。
小さく残す。
小さく見返す。
小さく直す。
この方が、ちゃんと続きます。
生成AIの確認レビューは、文章を直して終わりではありません。
人が直した理由こそ、次回のAI活用を育てる材料です。
ただし、立派な管理表から始めなくていいです。
まずは、次の3つだけ残します。
- 修正前に何が起きたか
- なぜ直したか
- 次にどこを直すか
これを1週間分見て、翌週直す手順を1つだけ選ぶ。
その積み重ねで、プロンプト、確認チェック、例外対応、社内教育が少しずつ整います。
生成AIの内製化は、AIに詳しい人だけで進めるものではありません。
業務の違和感に気づいた人の判断を、次に使える形で残すこと。
そこから始められます。
カタチ舎では、生成AIの導入や自動化を、ツール選びだけでなく、業務手順、確認者、改善ログ、社内教育まで含めて一緒に整理しています。
「AIを使っているけど、毎回人が直していて楽になっていない」
「確認者の判断が属人化している」
「改善ログや月次レビューの形を作りたい」
そんな状態なら、まずは今のAI活用で人が直している場所を一緒に棚卸しできます。
お問い合わせページ から、今の業務とAI活用の状況を聞かせてください。
最初の1ヶ月で、確認レビュー後に残す改善ログ、翌週直す手順、月次レビューへ戻す流れまで一緒に整えます。
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。