AIに社内業務を任せるとき、いちばん困るのは「どこまで人が確認すべきか」が決まらないことです。全部確認すれば自動化した意味がなく、全部任せれば間違いに気づけません。
この記事では、ExcelやNotionの表1枚で作れる承認の仕組みと、任せる範囲を決めるための3つの質問を扱います。ワークフローツールを買う必要はありません。
この記事でわかること
- AIに任せる範囲を決める3つの質問
- 表1枚で作る承認フローの具体的な作り方（4つの状態）
- 却下理由を1行残すだけで、改善が回り出す理由
- 全自動に移していい2つの条件
「どこまで任せるか」を決める3つの質問
ある業務をAIに任せてよいかどうかは、この3つを順に聞けば決まります。ツールを選ぶ前に、紙の上でできる作業です。
| 質問 | Yesなら | Noなら |
|---|---|---|
| ① 間違えても取り返しがつくか | 任せてよい | 人が確認する |
| ② 間違いに誰かが気づくか | 任せてよい | 確認する人を決める |
| ③ 社内で完結するか | 任せてよい | 必ず人が確認する |
① 間違えても取り返しがつくか
作成・分類・要約は、間違っていても作り直せます。削除・送信・支払いは戻せません。この違いだけで、任せてよい範囲はかなり絞れます。
同じ原則をファイル操作に当てはめた例は Claude Codeでファイル整理を自動化｜Macのダウンロードフォルダ編 に書きました。「移動はさせるが削除はさせない」という線の引き方です。
② 間違いに誰かが気づくか
ここが最も見落とされます。「担当者が見るはず」は答えになりません。いつ、誰が、何を見て気づくのかを具体的に決めてください。
ここが決められないとしても、その業務を任せられないという意味ではありません。まず決めるべきことが1つ見つかった、という意味です。確認する人を決めるのは、AIツールを選ぶよりずっと簡単です。
③ 社内で完結するか
顧客への返信、SNSへの投稿、見積書、採用の連絡。社外に出るものは、内容の正しさとは別に「誰が責任を持つか」の問題になります。ここは人が確認する、と最初に決めてしまうのが結局いちばん速い。
その「誰が責任を持つか」の答えは単純です。承認した人が持ちます。AIが書いたかどうかは関係ありません。だからこそ「誰が承認したか」が記録に残る形にしておく必要があります。次に説明する表は、品質を守る仕組みであると同時に、この記録を残す仕組みでもあります。
逆に言えば、社内で完結し、取り返しがつき、気づく人がいる業務は、かなり大胆に任せて構いません。この3つを満たす業務は、どの会社にも必ずあります。
承認フローは表1枚で作れる｜4つの状態と却下理由の残し方
「承認フロー」と聞くとワークフローツールの導入を想像しますが、最小構成は表が1枚あれば足ります。私が使っているのも、状態を表す列を1つ持った表だけです。
| 状態 | 意味 | 次にやること |
|---|---|---|
| 下書き | AIが作った直後 | 人が読む |
| 承認待ち | 人の確認を待っている | OKか却下かを決める |
| 承認済み | 公開してよい | 送信・投稿する |
| 却下 | 使わないと判断した | 理由を1行書く |
NotionでもExcelでもスプレッドシートでも作れます。大事なのはツールではなく、「承認済み」以外は外に出ないという一点です。
最低限そろえる列は4つ
凝る必要はありません。内容・状態・承認者・却下理由の4列があれば機能します。
- 内容 — AIが作った文章そのもの
- 状態 — 上の4つから選ぶ。ここが「承認済み」でなければ外に出さない
- 承認者 — 誰が確認したか。責任の所在がここに残る
- 却下理由 — 却下したときだけ1行
日付や案件名は、必要になってから足せば十分です。最初から作り込むと、運用が始まる前に力尽きます。
「却下の理由を1行書く」がいちばん効く
この欄は面倒ですが、ここだけは省かないでください。却下の理由が溜まると、AIへの指示をどう直せばいいかが見えてきます。「毎回同じ理由で却下している」と気づけば、そこが改善点です。
たとえば「専門用語が多すぎる」が3回続いたなら、指示に「中学生にも分かる言葉で」と足せば済みます。理由を書かないと、この気づきが得られません。いつまでも同じ間違いを直し続けることになります。
承認フローは品質を守る仕組みであると同時に、改善のためのデータを貯める仕組みでもあります。
承認する人がいない、という場合
承認は専任である必要はありません。作った本人が翌朝もう一度読む、でも機能します。重要なのは「作る」と「出す」の間に一拍置くことであって、別人であることではありません。
全自動に移していい2つの条件
「人が確認する」は永久に手動でやり続けるという意味ではありません。ここを誤解すると、AIを入れる意味が薄れます。
次の2つが揃ったら、その業務は全自動に移して構いません。
- 却下がほとんど出なくなった。先ほどの表に却下の記録が残っていれば、そのまま判断材料になります。目安として、直近50件で却下が数件に収まっているか
- おかしくなったときに気づく仕組みが、確認作業とは別にある。週に一度まとめて見る、件数が急に増減したら気づく、など
順番が重要です。まず承認を挟んで動かし、実績が溜まってから外す。最初から全自動にして、問題が起きてから承認を足すのは順序が逆です。信用を落としてからでは遅い。
なお、線を引いたあとに実際どう回すかは MCPを繋いだ後の使い方｜Claudeを毎朝動く秘書にする設計 に書きました。この記事が「範囲を決める」話で、あちらが「決めた範囲を毎日動かす」話です。
私が自分の自動化を全自動にしなかった理由
私はSNS投稿の自動化を自分で設計しました。文章を生成して投稿するところまで、技術的には自動化できます。それでも承認を挟む設計にしました。理由は1つです。
生成物の質が落ちたとき、気づかないまま公開され続けるのを防ぐため。事業紹介の内容は、誤情報がそのまま信用に響く。
質は静かに落ちます。ある日突然おかしくなるなら気づけますが、少しずつズレていく場合、毎日見ていない限り分かりません。そして自動化した瞬間から、人は毎日見なくなります。
私の場合はSNS投稿でしたが、社内の文書作成でも、問い合わせへの返信でも、同じことが起きます。「外に出ていくもの」という一点で共通しています。
ここで誤解されやすいのですが、承認を挟んでも、楽になった部分はほとんど戻ってきません。減らせるのは「白紙から書く時間」で、承認で使うのは「読んで判断する時間」です。この2つは別物で、前者のほうがはるかに重い。「作る」と「決める」を分けて考えると、どこを自動化すべきかが見えてきます。
着手前に、手続きの待ち時間を工程表に入れる
もう1つ、実際にやってみて分かったことがあります。技術より段取りで詰まります。私の場合、外部サービスの公式APIを使うために事業者審査が必要で、そこに2〜4週間かかりました。コードを書く前に1ヶ月近く待つ工程があったわけです。
皆さんの現場でこれに当たるのは、外部サービスの審査ではなく、社内の合意形成、アカウントの発行、そして「どのファイルを読ませていいか」の仕分けでしょう。いずれもコードを書く前の作業で、いずれも着手前に日程を見積もれます。工程表に入れておけば、そのぶん想定どおりに進みます。
補足：よく引用される2つの数字の読み方
AI導入の記事でよく見る数字を2つ挙げます。どちらも読み方に注意が要るので、そこも含めて書きます。
| 調査 | 数字 | 読むときの注意 |
|---|---|---|
| MIT Project NANDA 『The GenAI Divide』2025年7月 |
企業の生成AI導入の95%が損益への影響を測定できなかった | 「95%が失敗した」ではありません。「効果を数字で確認できなかった」という意味です。対象もチャットアシスタント等の導入事例に限られます。調査規模は数百件規模で、公開後に手法への批判もありました。傾向を示す参考値として読むのが妥当です |
| Gartner 2025年6月 |
2027年末までにエージェント型AIプロジェクトの40%超が中止される | 実績ではなく予測です。理由として挙がっているのはコストの膨張、価値の不明確さ、そしてリスク管理の不十分さ |
数字そのものより、Gartnerが挙げた3つの理由がすべて「技術以外」である点に注目してください。コスト、価値の見えなさ、リスク管理。止まる原因は、モデルの性能ではありません。だからこそ、承認の設計が効きます。
よくある質問
Q. 承認を挟むと、結局手間が減らないのでは？
A. ゼロから作る手間と、できているものを読む手間は別物です。白紙から書くより、下書きを読んで直すほうが速い業務は多くあります。ただし「読むだけで済む品質」に達していない段階では、確かに手間が増えます。その場合は自動化そのものを見直すべきで、承認を外す方向に進んではいけません。
Q. 小さく始めるなら、最初の1つは何がいいですか？
A. 3つの質問すべてで「任せてよい」に振れる業務を選んでください。社内で完結し、間違えても作り直せて、毎日誰かが目を通すもの。具体的には、議事メモの整形、問い合わせ内容の分類、定型的な報告書の下書きあたりが該当します。
Q. どのくらいの精度なら任せていいですか？
A. 精度の数字で決めないでください。同じ90%でも、取り返しのつく業務なら十分ですし、社外に出るものなら足りません。判断の軸は精度ではなく、間違えたときに何が起きるかです。
Q. 承認の記録は、どのくらい残せばよいですか？
A. 却下の理由は消さずに全部残してください。これは改善のためのデータです。承認済みのものは、外に出した後であれば整理して構いません。ただし社外に出した内容については、誰がいつ承認したかだけは残しておくと、後から問い合わせがあったときに困りません。
まとめ
- 任せる範囲は「取り返しがつくか」「誰が気づくか」「社内で完結するか」の3つで決まる
- 承認フローは表1枚で作れる。内容・状態・承認者・却下理由の4列があれば足りる
- 却下の理由を1行書く。ここが改善のデータになる
- 社外に出るものの責任は承認した人が持つ。だから記録に残す
- 実績が溜まったら全自動に移してよい。順番を逆にしない
- 技術より段取りで詰まる。手続きと待ち時間を工程表に入れる
AIは危ないから使わない、という話ではありません。範囲を決めれば、安全に、確実に効きます。そして範囲を決める作業は、ツールを選ぶ前に、紙の上でできます。
なお、この3つの質問はベンダーの提案を評価するときにも使えます。「この仕組みでは、どこに人の確認が入りますか」と聞いてみてください。運用まで設計している会社なら即答します。答えが出てこない提案は、動くものは作れても、動き続ける仕組みにはなりません。
なお、決めた運用が実際に効いているかを数字で確かめる側の話は 順位が高いのにクリックされない原因｜タイトルの長さを疑う に書きました。手を打ったあと、それが当たったかどうかを見る手順です。
なお、「任せる範囲を先に決めてルール化する」という考え方は資料作成にも応用できます。デザインや構成のルールを1回固定してAIに参照させる具体例は python-pptxでAIスライド自動生成｜数式もデザインも崩さない にまとめました。また、この承認フローと組み合わせる前提のルールブックづくりは 中小企業がAIに指示を安定させる「ルールブック」の作り方 で解説しています。
frural では、まずお手持ちの業務をこの3つの質問に通すところからご一緒しています。ベンダーからの提案があるなら、その内容の評価も含めて構いません。サービスの詳細はこちら、ご相談は お問い合わせ からどうぞ。