生成AIを使う工程と人に残す工程を実際の構成例から切り分ける

入力 → 処理 → 確認 → 出力という4つの区切りで業務を見ると、生成AIに渡してよい部分と、人が最後まで見る部分がはっきり分かれます。以下は、実際に私が受託業務や自社ツールで動かしている構成をもとに、その切り分け方をまとめたものです。

生成AIに向く工程・向かない工程を分けている基準

私が判断しているのは「人がやり直せるか」と「間違えたときに誰が困るか」の2点で済みます。読み取り・下書き・一次回答は生成AIに任せ、金額確定・契約確定・最終判断は人に残しています。

読み取りや下書きは、仮に生成AIが間違えても、元データと照らし合わせればすぐに気づけますし、気づいた時点で止められます。つまり事後にやり直しがきく工程です。一方で金額の確定や契約・予約の確定は、一度外に出てしまうと取引先の予定や支払いがすでに動き出しているため、やり直しが効きにくく、困るのは自分ではなく相手になります。ここが一番の分かれ目です。

このあたりの切り分けはインソース社の解説でも、メール下書きや資料整理といった「人が最後に目を通す前提の作業」が向くとされており、私が現場で感じている線引きと近い内容でした。

入力・処理・確認・出力の4工程で自分の業務を分解する手順

自分の業務を紙に書き出して4つの欄に割り振ると、どこを生成AIに任せてよいかが見えてきます。手書きの点検記録をデータ化する業務を例に、実際の割り振り方を示します。

1. 今やっている業務を一つ選び、入力・処理・確認・出力の4つの欄を紙に書く。点検記録のデータ化なら、入力は「現場から届く手書きの点検表(PDF・写真)」、処理は「OCR+生成AIでの読み取りと項目ごとの整形」、確認は「登録前に担当者が数値と項目名を目視で見る」、出力は「業務ツールへの登録」と書く。
2. 入力の欄には、今使っている媒体をそのまま書く。紙・PDF・写真・メール・口頭など、手を加えずに書く。ここで「将来こうしたい」を書いてしまうと、実際の詰まりどころが見えなくなる。
3. 処理の欄には、生成AIにやらせたい作業を具体的に書く。「読み取り」「分類」「要約」「下書き作成」のように動詞で書く。「よしなに処理」のような曖昧な書き方をすると、どこまで任せたか後で分からなくなる。
4. 確認の欄には、誰が・何と照合して・いつ見るかを書く。点検記録なら「登録前に担当者が、元の手書き票の数値と一致しているかを見る」まで書く。「ダブルチェックする」とだけ書くと、実際には誰も見ない工程になりがちなので避ける。
5. 出力の欄には、最終的にどこへ記録・送信されるかを書く。業務ツールへの登録、請求書の発行、LINE通知など、着地点を具体的に書く。
6. 4つの欄を見直し、確認の欄が空欄のままの工程がないか確認する。空欄のまま自動化を進めると、誤読や誤登録がそのまま外に出る構成になってしまう。

この分解をやってみると、「処理」に見えていた作業の中に、実は人が毎回目で見て判断している部分が混ざっていることに気づきます。その部分だけを確認の欄に切り出すのがこの手順の目的です。

実際に動かしている構成:読み取り系の工程

読み取り系は、生成AIの出力をそのまま業務システムに流し込まず、一度ファイル形式で止めてから人の確認を挟む構成にしています。

自社で公開しているAI転記ツールは、PDFや写真をCSV・TSV形式に変換するもので、ファイルはサーバー側に保存しない構成で動かしています。読み取り結果を直接データベースに登録せず、一度ファイルとして出力しているのは、登録前に人が目視で数値を確認できるようにするためです。読み取り精度が高くても、元の手書き文字が崩れていたり、写真の影で数字が読みにくかったりするケースは必ず出るため、この確認工程を省くと誤登録に直結します。

もう一つの例がシフト表→出勤簿・申請書のサンプルです。シフト表を読み取って出勤簿や申請書に転記する際、転記ミスを検算する処理を間に挟んでいます。合計時間や人数の整合性を機械的に突き合わせ、ずれがあれば転記が止まる構成にすることで、読み取りの誤りを確認工程の手前で機械的に拾えるようにしています。

実際に動かしている構成:一次回答・下書き系の工程

一次回答は、あらかじめ登録した内容の範囲でのみ生成AIに答えさせ、範囲外の質問は人に引き継ぐ構成にすると、確認を挟まずに自動で返してよい境界が決まります。

自社で公開している問い合わせの自動返答(管理画面つき)は、営業時間や料金、対応エリアなど、事前に登録した内容だけを根拠に答える構成です。登録内容に該当しない質問、たとえば個別の値引き交渉や特殊な事情を含む問い合わせは、生成AIが自分で判断して答えを作るのではなく、担当者に転送する仕組みにしています。

ここで重要なのは、「答えられるかどうか」の判断自体を生成AIに任せていない点です。判断を任せると、それらしい答えを作ってしまう可能性が残るため、登録内容に一致する質問かどうかという機械的な線引きだけを生成AIにさせ、一致しない場合は無条件で人に回すようにしています。この境界があるために、確認工程を挟まずに即時返答する範囲を安全に広げられます。

人の確認を外せない工程:確定・判断が絡む場面

金額や対外送信が絡む工程は、計算そのものを自動化しても、最終的に送る・登録するという判断は人が行う構成にしています。

自社で公開している付替表→見積→請求予定のサンプルは、付替表のデータから見積・請求予定を自動で作成しますが、合計の一致を自動で確かめる処理までを生成AIと仕組みに任せ、最終的な送信は人が行う構成にしています。合計が一致しない場合は送信前の画面で警告を出し、人が差分を確認してから進めるようにしています。金額は一度相手に届くと取り消しにくいため、計算の正確さを機械で担保しつつ、送るかどうかの最終判断だけは人に残しています。

受託している点検記録のデータ化も同じ考え方です。これは2026年7月から続けている作業で、週10時間ほどの規模で、手書きの点検記録を読み取って業務ツールへ登録するところまでを担当していますが、読み取り後に人の確認を挟んでから登録する構成にしています。点検記録は現場の安全管理に直結するため、読み取り精度に関わらず、登録前の人の目視確認を外さない方針にしています。

技術構成のテンプレート:入力から出力まで何でつなぐか

私が使っている構成は、Cloudflare Pages Functionsで生成AIを呼び、Supabaseに記録し、LINEで確認・通知を行い、人の承認を経てから出力するという型です。この型は小規模な業務でもそのまま使えます。

流れとしては、まず入力(PDF・写真・フォーム送信など)を受け取り、Cloudflare Pages Functions上で生成AIを呼び出して読み取りや下書きを処理します。処理結果はSupabaseに一旦記録し、確認が必要な内容はLINEに通知を飛ばします。担当者がLINE上、または管理画面で内容を確認し、問題がなければ承認操作をしてから、業務ツールへの登録や取引先への送信といった出力が実行されます。定期的に動かす処理については、Windowsタスクスケジューラ+Pythonで時刻起動する構成にしています。

schtasks /create /tn "TenkiRecordSync" /tr "python C:\batch\sync_tenki.py" /sc DAILY /st 07:00

このコマンドは、毎日午前7時にPythonスクリプトを起動し、前日分の読み取り結果をSupabaseへ同期する処理のスケジュール登録例です。公開や送信といった、外に出る操作の最終判断だけは、この構成のどこにも自動実行を仕込まず、人の承認操作を必ず経由させています。NTTコミュニケーションズの比較解説でも、法人利用では承認フローを人側に残す設計が前提として語られており、小規模な構成でも同じ考え方が成立します。

まとめと試せる場所

自分の業務を入力・処理・確認・出力の4つに書き出し、確認の欄が空欄になっている工程がないかをまず見てください。空欄があれば、そこが本番投入前に埋めるべき場所です。

実際に手を動かして試せる場所として、AI転記ツール、シフト表→出勤簿デモ、付替表→請求予定デモ、問い合わせ自動返答デモを公開しています。自分の業務に近いものがあれば、入力してみて、どこで確認を挟みたくなるかを見てください。