CANDIDATE 01
文書・メールの分類
決まった種類に分ける、必要項目の候補を抜き出す、内容に応じて担当先の候補を提示する工程。原文との照合ができることが前提です。
AI WORKFLOW / DESIGN
AIワークフロー・自動化設計
文書分類や問い合わせの振り分け、定型文の下書き、情報の転記。繰り返し作業をAIや既存ツールと組み合わせるとき、通常処理だけでなく「判断できないときに誰へ戻すか」まで設計します。
AIの候補をそのまま確定結果にするのではなく、入力情報・処理ルール・権限・確認手順をひとつの業務フローとして整理。人が根拠を見て承認、修正、差し戻し、保留を選べる形を目指します。
自動化の設計では、処理候補と確認に使う原文・根拠を切り離さず、担当者が判断できる状態をつくります。
01 / 適した業務
何を自動化候補にできる？
AIが得意そうな作業からではなく、仕事の繰り返し方と確認のしやすさから考えます。
CANDIDATE 02
振り分け・情報転記
複数の窓口や台帳を行き来する作業。転記先、必須項目、二重登録の扱いを明確にし、誤りを見つけた際に戻せる経路を設けます。
CANDIDATE 03
定型文の下書き
既定の情報を使った文案作成など、担当者が内容を確認してから使う工程。顧客への最終回答や重要な判断を自動確定する前提にはしません。
自動化しやすさは、作業が単純に見えるかだけでは決まりません。入力が毎回変わる、正解の基準が曖昧、誤りの影響が大きい工程は、先に手順や責任範囲を整理するほうが適切な場合があります。対象を絞り、照合できる小さな単位から検討します。
02 / FLOW DESIGN
入力から完了まで、通常系と例外系を分けて設計
処理の流れを定義しておくと、どこで自動処理を止め、誰に判断を戻すかが明確になります。
01 INPUT
入力と原本
対象データ、形式、取得元、必要な項目を確認。原本を保持し、試行データと混同しないようにします。
02 PROCESS
候補を作成
分類、抽出、下書きなど、AIに任せる範囲を限定。使うツールや処理ルールも合わせて整理します。
03 HUMAN REVIEW
人が確認・判断
根拠となる情報を見て承認、修正、差し戻し、保留を選ぶ。担当者が何を確認すべきか、画面や手順で示します。
04 RECORD
確定・記録
承認後に所定の処理へ進め、修正や例外を記録。誤りが見つかった場合は停止し、担当者へ引き継ぎます。
通常処理
入力がそろい、決めた条件に沿って処理できる場合でも、どこまでを自動で進めるかは業務の影響に合わせて定めます。確認を省く場合は、その条件と担当責任を明文化します。
例外・処理失敗
情報不足、担当先不明、読み込み失敗、判断に迷う結果は、無理に完了へ進めません。保留先、通知先、再処理や手作業への切り替え、記録方法をあらかじめ決めます。
03 / SCOPE & OUTPUT
設計で確認すること
利用環境やデータの条件を確認したうえで、実現方法を比較します。
自動化ありきで進めず、現在の手順に改善余地があるか、入力の揺れや例外を扱えるか、運用を担う人がいるかを一緒に確認します。実装方法は既存ツール、権限、データの制約によって変わるため、個別の環境を確認して整理します。
SCOPE / 01
入力・出力データと利用ツールの整理
SCOPE / 02
処理ルール、権限、承認箇所の設計
SCOPE / 03
エラー・例外時の停止と引き継ぎ条件の設定
SCOPE / 04
検証用ケースと運用時の確認項目の作成
DELIVERABLES
使い始める前に確認できる設計資料
設計内容を、実務担当者と責任者が確認・議論できる形にまとめます。
- ワークフロー仕様案
- 人による確認・差し戻し条件
- テストケースと運用チェック項目
04 / BEFORE A TRIAL
小さく試す前に、比較できる基準をつくる
試行結果を見て続けるか判断できるよう、開始前に確認方法を決めます。
たとえば問い合わせの分類なら、過去の問い合わせの一部を使い、担当者が正解を確認したうえで、分類候補と実際の振り分けを照合します。候補の正しさだけでなく、見落とし、修正にかかる手間、例外として人へ戻った件数も確認対象です。試行データは原本と分け、利用できる情報とアクセス権を事前に確かめます。
処理候補と正解の照合
修正・差し戻しの傾向
例外時に止まるか
担当者の確認負担
この例は検証の考え方を示すもので、特定のツールや環境での利用可否・効果を保証するものではありません。
05 / よくある質問
自動化設計を検討するときの疑問
どのような反復作業が候補になりますか？
文書やメールの分類、定型文の下書き、情報の転記など、一定の入力と判断ルールがあり、結果を照合できる作業が候補になります。作業頻度だけで選ばず、入力の安定性、例外の割合、誤りが起きた場合の影響、確認方法を合わせて見ます。
情報不足や誤りが起きたらどうなりますか？
必要情報が欠ける、結果の根拠を確認できない、処理が失敗するなどの条件を例外として定義し、自動処理を止めて担当者へ引き継ぐ流れを設計します。担当者が承認・修正・差し戻し・保留を選べること、修正や停止の記録を残せることも重要です。
表計算や今あるツールも対象ですか？
既存の表計算やツールを使う業務も検討対象です。ファイルの役割、列や入力形式、変更・複製の習慣、アクセス権を確認し、原本を保った検証方法や連携の選択肢を整理します。実際の対応範囲は利用環境とデータの条件によって確認が必要です。
06 / 構想例
確認工程を含めた業務フローのイメージ
以下は顧客導入実績ではなく、異なる業務で確認・引き継ぎをどう設計するかを示す構想例です。
構想例 / バックオフィス自動化
請求書処理の確認・振り分け設計例
受領した請求書の情報確認から担当者への振り分けまでを対象にした、導入検討用の構想例です。特定企業への導入実績ではなく、処理手順と人の確認箇所を説明するためのシナリオです。
構想例の流れを見る
構想例 / 顧客対応・タスク委任
問い合わせの初期分類と担当振り分け例
メールやフォームの問い合わせを内容別に整理し、適切な担当へ引き継ぐ業務の構想例です。回答の自動送信を前提とせず、緊急性や判断の難しさに応じて人へつなぐ設計を示します。
構想例の流れを見るNEXT / 関連する読みもの
確認フローと既存業務の見直し
自動化の対象を考えるときは、人が判断する手順や現在のデータの状態も一緒に確認しましょう。
次に読む
START WITH THE WORK
業務と利用ツールから、設計の論点を整理しませんか。
繰り返し作業の内容、現在の手順、利用ツール、気になっている例外を添えてお問い合わせください。条件を確認するためのメール文面を開きます。送信は内容をご確認のうえ、ご自身で行ってください。