見出し画像

AIで自動化する前に、何を標準化すべきか？業務を壊さず半自動化する8つの設計

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中

AIを仕事で使い続けていると、少しずつ「毎回、似た作業を繰り返している」と気づき始めます。

会議録から決定事項を抜き出す。問い合わせを分類する。報告書の下書きを作る。資料を決まった形式へ整える。そのたびに同じ資料を渡し、似た指示を書き、出力を修正している。

そこで、Project、Custom GPT、Gem、Skill、ワークフローなどを使えば、この仕事を自動化できるのではないかと考えます。

方向性は間違っていません。ただし、ここで順番を間違えると、業務はかえって不安定になります。

業務を理解し、成功条件、失敗条件、例外を把握する前に自動化すると、曖昧な判断や不要な工程まで繰り返す仕組みができてしまうからです。

先に必要なのは、高度な自動化ツールではありません。

入力、作業、判断、出力、確認、例外を整理し、人間が確認できる半自動運用で安定性を確かめることです。

今回は、AI活用成熟度12フェーズのフェーズ8「業務標準化・半自動化」として、個人のうまいやり方を、別の担当者でも再現できる業務へ変える方法を整理します。

AI活用成熟度12フェーズの記事一覧


フェーズ7で案件知識を整えた次は、作業手順を整える

前回のフェーズ7では、案件の目的、正式資料、過去の判断、未解決事項、禁止事項などを整理し、新しいチャットや別の担当者でも案件の現在状態を再現できる環境を扱いました。

これは重要な前提です。

AIが間違った旧版を参照していたり、案件固有の条件を知らなかったりすれば、どれだけ優れた手順を用意しても正しい成果は出ません。

ただし、正しい情報へアクセスできるだけでは、業務は再現可能になりません。

同じ資料を参照していても、担当者によって次が異なることがあります。

  • どの情報を最初に確認するか

  • どこを重要と判断するか

  • 何をAIへ渡すか

  • どの出力を修正するか

  • どこで上司や専門担当者へ確認するか

  • 何をもって完了とするか

フェーズ7が「何を知っているべきか」を再現する段階だとすれば、フェーズ8は、その知識を使って、どう作業するかを再現する段階です。

一方、既存業務そのものを疑い、前後工程、会議、承認、システム、組織の役割まで組み直すのは、次のフェーズ9です。

フェーズ8では、まず一つの繰り返し業務を取り出し、現在の業務を大きく変えすぎずに、安定して実行できる単位へ整えます。

フェーズ8は、個人の工夫を再現可能な標準手順へ変える段階

フェーズ8の中心は、自動化率を高めることではありません。

目指すのは、次のような状態です。

  • 必要な入力が定義されている

  • 作業の基本順序が整理されている

  • AIへ任せる作業が決まっている

  • 人間が判断する項目が決まっている

  • 出力形式と必須項目がそろっている

  • 通常処理と例外処理が分かれている

  • 失敗した場合に止まり、再開できる

  • 別担当者でも一定品質を再現できる

この状態を、この記事では「業務標準化」と呼びます。

そして、標準化した業務の一部をAIが処理し、人間が必要な箇所を確認・承認する運用を「半自動化」と呼びます。

標準化は、すべての仕事を一つの手順へ押し込むことではない

「標準化」と聞くと、細かいマニュアルを作り、誰もが同じ操作をする状態を想像するかもしれません。

しかし、AIを使う業務で必要なのは、操作を完全に固定することだけではありません。

少なくとも、次を共通化します。

  • どの条件で業務を始めるか

  • どの情報が必要か

  • どの工程までが通常処理か

  • どこから人間判断になるか

  • どの状態を例外とするか

  • 何をもって完了とするか

  • 何が起きたら止めるか

状況に応じた判断が必要な仕事でも、判断へ至るまでの情報整理や、判断を人間へ渡す条件は標準化できます。

標準化の目的は、人間の判断をなくすことではありません。

人によって無意識に違っていた作業や判断境界を外部化し、再現・確認・改善できるようにすることです。

手順書があっても、判断基準が曖昧なら再現できない

「手順を文書にしたから標準化できた」と考えたくなりますが、実際には手順書だけでは足りません。

例えば、「重要な問い合わせは管理者へ報告する」と書かれていても、何を重要と判断するのかが担当者の経験に依存していれば、結果は安定しません。

必要なのは、「重要」という言葉を、確認可能な条件へ変えることです。

  • 金銭的な損失が発生している

  • 法令や契約への抵触が疑われる

  • 顧客が解約の意思を明示している

  • 個人情報や機密情報が含まれる

  • 既存FAQでは回答できない

  • 同じ問題が一定期間内に繰り返されている

すべての判断を完全なルールへ変えられるわけではありません。

しかし、少なくとも、どこまで通常処理で進め、どこから人間判断へ切り替えるかは明確にできます。

AIが一度成功しても、業務として再現できるとは限らない

AIへ議事録を渡し、きれいな要約が一度できたとします。

それだけで、業務に使えるとは判断できません。

次の会議では、発言者が不明かもしれません。決定に見えた発言が、後半で撤回されているかもしれません。期限が明示されず、「なるべく早く」としか言われていないかもしれません。

AIのデモでは、整った入力と分かりやすい事例を使いがちです。

実際の業務には、欠落、矛盾、曖昧さ、例外が含まれます。

そのため、一度の成功ではなく、条件の異なる入力や、失敗しやすい入力でも確認する必要があります。

半自動化は、完全自動化までの未完成状態ではない

「まず半自動化し、いつか完全自動化する」という説明をよく見かけます。

しかし、すべての業務が完全自動化を目指すべきとは限りません。

顧客への重要な回答、契約に関わる判断、人事評価、金銭の支払い、公開情報の送信などは、AIの性能が上がっても、人間が判断や責任を保持すべき場合があります。

半自動化は、自動化への途中段階であるだけではありません。

AIの処理能力と、人間の判断・責任を意図的に組み合わせた完成形になることもあります。

NISTのAI Risk Management Frameworkも、AIリスク管理を、用途や影響を把握し、測定し、管理する継続的な機能として整理しています。すべての用途に同じ自動化・監督方法を適用する考え方ではありません。

どの業務を標準化するかは、効果だけでなく安定性とリスクで決める

繰り返し発生する仕事は、標準化候補になりやすいでしょう。

ただし、頻度が高いという理由だけで選ぶと失敗します。

候補業務は、少なくとも次の10軸から評価します。

1. 繰り返し発生するか

発生頻度が高い業務ほど、改善の累積効果は大きくなります。

ただし、頻度だけでは判断しません。

低頻度でも、一件当たりの負担や重要度が高く、入力・出力が共通しているなら、標準化する価値があります。

2. 入力が似ているか

毎回、同じ種類の資料、フォーム、文字起こし、データを受け取れる業務は標準化しやすくなります。

反対に、入力形式や情報量が毎回大きく違う場合は、まず入力を整える必要があります。

3. 出力の共通項目を定義できるか

報告書の見た目だけではなく、必ず含む情報を定義できるかを確認します。

必須項目を決められなければ、品質の良否も判定できません。

4. 判断基準を説明できるか

担当者が何を見て、どの条件で判断しているかを説明できる業務は、AI支援と人間判断を分けやすくなります。

判断理由をまったく説明できず、結果の良否も確認できない場合は、まだ半自動化へ進むべきではありません。

5. 誤りを発見できるか

AIが間違えるかどうかだけでなく、間違いに気づけるかを確認します。

元資料との照合、必須項目チェック、計算ツールによる再計算など、独立した確認手段がある業務は扱いやすくなります。

6. 誤りを修正できるか

誤った下書きを公開前に直せる仕事と、一度の処理で重大な外部影響が発生する仕事では、必要な統制が異なります。

修正可能な下書き、抽出、分類から始める方が安全です。

7. 失敗時の損失を限定できるか

一件の誤りが、顧客、従業員、契約、金銭、安全へ与える影響を確認します。

損失が大きいほど、人間確認、専門家確認、停止条件を強くします。

8. 必要なデータを取得できるか

必要な情報へアクセスできない業務では、AIの能力を上げても安定しません。

入力資料、過去事例、判断基準、最新情報を適切に取得できるかを確認します。

9. 改善効果を測れるか

処理時間、確認時間、欠落、差し戻し、リードタイム、担当者間のばらつきなど、導入前後を比較できるかを確認します。

利用回数だけでは、業務が改善したか分かりません。

10. 例外が業務の一部か、大半か

標準処理が大半を占め、例外だけを人間へ渡せる業務は半自動化しやすいでしょう。

反対に、ほぼすべての案件で条件が違い、個別判断が中心になる場合は、固定的な自動化に向きません。

業務を観察しなければ、不要な作業まで標準化してしまう

候補業務を選んだら、すぐに理想のフローを作るのではなく、現在の仕事を観察します。

担当者が説明する手順と、実際に行っている手順が違うことは珍しくありません。

手順書を先に書かず、実際の作業を複数回観察する

一度だけ作業を見ても、たまたま正常なケースだった可能性があります。

異なる条件の業務を観察し、次を記録します。

  • 何を受け取ったか

  • 最初に何を確認したか

  • どこで迷ったか

  • 何を調べ直したか

  • どの情報を除外したか

  • どこを修正したか

  • 誰に相談したか

  • どの状態で完了と判断したか

ここでは、担当者の操作だけでなく、判断の理由を確認します。

「いつもこうする」ではなく、「どの条件を見て、なぜそうしたのか」まで掘り下げます。

表向きの手順と、実際に行う判断を分ける

業務には、作業と判断が混在しています。

例えば問い合わせ対応なら、次は主に作業です。

  • メールを開く

  • 顧客情報を確認する

  • 問い合わせ内容を分類する

  • 返信案を作る

  • 対応履歴へ記録する

一方、次は判断です。

  • 緊急対応が必要か

  • 既存FAQで回答してよいか

  • 個別補償の対象か

  • 法務確認が必要か

  • どの表現なら誤解を生まないか

AIへ任せやすいのは、まず抽出、分類、変換、下書きなどの作業部分です。

判断も支援させられますが、判断基準、例外、人間承認を別に設計する必要があります。

暗黙知は「コツ」ではなく、条件と判断へ翻訳する

熟練者へ質問すると、「文章を見れば分かる」「雰囲気で判断している」と言われることがあります。

そこで終わらず、具体例を比較します。

  • 採用した例と不採用の例は何が違ったか

  • 通常の案件と危険な案件で何を見ているか

  • 新人が間違えやすい場所はどこか

  • 迷ったとき、誰に何を確認するか

  • 最終的に何があれば安心できるか

暗黙知のすべてをルールへ変える必要はありません。

ただし、ルールへ変えられない判断がどこに残るかは明確にします。

例外を通常フローへ押し込むと、標準化が壊れる

例外が出るたびに通常ルールへ条件を追加すると、手順は複雑になります。

「Aならこうする。ただしBなら別。BでもCの場合は元へ戻す」と分岐が増え続け、誰も理解できない仕組みになりかねません。

例外は、通常処理へ無理に組み込まず、別ルートとして分類します。

  • 入力が不足している

  • 情報が矛盾している

  • 標準対象外である

  • 人間判断が必要である

  • 高リスク条件に該当する

  • 外部システムが利用できない

  • 二重処理の可能性がある

通常フローで処理できないときに、正しく止まり、適切な人へ渡せることも標準化の一部です。

業務を半自動化する8段階

業務を観察したら、入力、作業、判断、出力を構造化します。

フェーズ8では、次の8段階で進めます。

1. 対象業務を小さく切り出す

「営業業務を自動化する」「バックオフィスを効率化する」といった広い対象では、必要な入力も判断も定まりません。

例えば、次のように切り出します。

  • 商談メモから次回確認事項を作る

  • 請求書から確認項目を抽出する

  • 会議録からタスク登録候補を作る

  • 問い合わせを一次分類する

  • 研修アンケートからFAQ候補を抽出する

開始点と終了点を明確にすることが重要です。

2. 現在の仕事を観察する

担当者が実際に行っている操作、判断、修正、相談、例外を記録します。

理想の手順ではなく、現状を把握します。

3. 入力・作業・判断・出力を分ける

一連の仕事を、次に分解します。

  • 何を受け取るか

  • 何を処理するか

  • どこで判断するか

  • 何を出力するか

この分解によって、AIへ任せやすい部分と、人間が保持すべき部分が見えてきます。

4. 標準手順と完了条件を決める

作業順、必須項目、禁止事項、出力形式を決めます。

さらに、「何をもって終わりか」を第三者が確認できる形で書きます。

「議事録が完成した」では不十分です。

例えば、次のように定義します。

  • 決定事項と未決事項が分かれている

  • 各タスクに担当者、または担当未定の表示がある

  • 明示された期限だけが記載されている

  • 不確実な項目には確認待ちの表示がある

  • 共有範囲が確認されている

5. AIと人間の担当範囲を決める

AIには、抽出、分類、形式変換、下書きなどを優先して任せます。

人間には、採否、例外、外部影響、責任を伴う判断を残します。

6. 例外・停止・手動復帰を設計する

不足、矛盾、対象外、低信頼、高リスクなどの例外を分類します。

処理を継続してはいけない条件や、AIを利用できない場合の手動手順も残します。

7. 小規模なパイロットで検証する

正常例だけでなく、重要な例外を含む実データや模擬データで試します。

速度だけではなく、修正量、欠落、例外率、担当者差を測ります。

8. 別担当者へ移し、継続・修正・中止を決める

設計者本人ではなく、別の担当者が使えるか確認します。

説明を受けないと使えない、毎回設計者へ質問が来る、出力品質が大きく変わる場合は、まだ標準化できていません。

結果を見て、次のいずれかを選びます。

  • 継続する

  • 手順や入力を修正する

  • 人間確認を強くする

  • 半自動のまま維持する

  • 自動化範囲を狭める

  • 手動へ戻す

  • 対象業務から外す

入力を標準化しなければ、AIの出力は安定しない

AIの出力が不安定なとき、モデルやプロンプトを疑いがちです。

しかし、原因が入力側にあることも少なくありません。

会議録作成であれば、文字起こしだけを渡す場合と、会議目的、参加者、対象案件、既存の課題一覧まで渡す場合では、出力条件が違います。

標準入力では、次を分けます。

  • 必須入力

  • 任意入力

  • 参照資料

  • 入力形式

  • 対象期間や基準日

  • 入力不足時の扱い

  • 入力してはいけない情報

不足した情報をAIが推測で補わないように、「不足として報告する」「確認待ちにする」といった処理も決めます。

出力形式だけでなく、必須項目と禁止事項を固定する

「Markdownで出力」「表で出力」だけでは、業務出力の標準化にはなりません。

必要なのは、内容上の仕様です。

例えば次を定義します。

  • 必ず含める項目

  • 記載してはいけない項目

  • 不明な場合の表示方法

  • 引用や根拠の示し方

  • 日付の形式

  • 担当者未定時の表記

  • 保存先

  • ファイル名

  • 更新者

  • 承認状態

AIが見栄えのよい文章を作っても、必要な項目が欠けていれば業務では使えません。

完了条件は「それらしい」ではなく、確認可能な状態で書く

「高品質なレポート」「分かりやすい議事録」「適切な回答」といった表現は、そのままでは完了条件になりません。

評価者が確認できる条件へ変えます。

  • 必須項目の欠落がない

  • 元資料にない事実を追加していない

  • 数値と日付が元資料と一致している

  • 未確認事項が明示されている

  • 承認者が記録されている

  • 指定先へ一度だけ保存されている

  • エラーや例外が未処理で残っていない

完了条件を先に決めると、人間がどこを確認するかも明確になります。

AIと人間の分担は、作業量ではなく誤りの影響で決める

「AIが8割、人間が2割」のような比率は分かりやすい一方で、設計基準としては弱いものです。

重要なのは量ではなく、誤りが起きたときの影響です。

AIが長い文章の初稿を作り、人間が短時間で重要箇所だけ確認する業務もあります。

反対に、AIが数項目を抽出するだけでも、その項目が支払いや契約を左右するなら、人間の確認責任は重くなります。

AIには、抽出・分類・変換・下書きを優先して任せる

比較的始めやすいのは、次の仕事です。

  • 指定資料から項目を抜き出す

  • 既定カテゴリへ分類する

  • 形式を変換する

  • 文章の下書きを作る

  • 重複や不足候補を示す

  • 確認すべき論点を列挙する

これらは、元情報や評価基準との照合がしやすいためです。

ただし、抽出であっても重要項目を見落とす可能性はあります。

低リスクであっても、パイロット段階では結果を確認します。

人間には、採否・例外・外部影響・責任を残す

人間が保持すべき代表的な判断は次です。

  • この出力を採用するか

  • 通常ルールでは処理できないか

  • 誰かへ重大な影響を与えるか

  • 公開、送信、登録してよいか

  • 法的・倫理的な確認が必要か

  • どの損失を許容するか

  • いつ停止するか

AIが候補を提示しても、最終的な責任の所在は別に設計する必要があります。

Human-in-the-loopは、最後に人間が全部読むことではない

「最後に人間が確認する」とだけ決めると、人間はすべてを読み直すことになります。

これでは、AIによる作成と人間による再作成が重なり、効率化になりません。

人間確認では、見る場所と判断内容を指定します。

例えば議事録なら、次に限定できます。

  • 決定事項と提案が混同されていないか

  • 担当者と期限が明示された発言に基づくか

  • 未確定事項が確定表現になっていないか

  • 機密情報の共有範囲は正しいか

  • タスク登録対象として適切か

必要に応じて、AIに根拠となる発言箇所を付けさせれば、確認負担を減らせます。

人間介入は、高リスクな処理や、テストで十分に扱えていない状況へ重点的に置く方が合理的です。

承認ゲートは外部操作の直前だけとは限らない

一般的には、メール送信、公開、システム登録、支払いなどの直前に承認を置きます。

しかし、途中の判断が後工程全体を大きく変える場合は、中間承認も必要です。

例えば、問い合わせを「通常」「重大」「法務確認」のどれに分類するかによって、その後の担当部署や対応期限が変わるなら、分類直後に人間確認を置く選択があります。

承認箇所は多ければ安全というわけではありません。

影響が大きく、後から戻すコストが高い場所へ置きます。

人間確認を省略できる条件も事前に決める

すべての出力を永続的に人間確認する必要があるとは限りません。

十分な検証後、次を満たす一部の処理については、事後監査へ移せる可能性があります。

  • 低リスクである

  • 入力条件が明確である

  • 出力が定型的である

  • 誤りを後から検出できる

  • 修正可能である

  • 例外時には停止する

  • 一定割合を継続監査できる

ただし、確認省略は「面倒だから」ではなく、利用結果とリスク評価に基づいて決めます。

Template、Project、GPT・Gem、Skill、Workflowは何が違うのか

現在は、反復業務を支援する仕組みが数多くあります。

ChatGPTでは、Projects、カスタムGPT、Skillsなどを利用できます。

ClaudeではProjectsやSkillsが提供され、Claude Skillsは指示、スクリプト、資料などをまとめ、専門的な反復作業へ利用する仕組みとして説明されています。

GeminiのGemsも、反復タスクや特定の目的に合わせたカスタマイズ機能として提供されています。

ただし、製品や機能の高度さと、業務の成熟度を混同してはいけません。

手順を試している段階では、Templateとチェックリストから始める

業務を試している途中であれば、入力テンプレート、出力テンプレート、確認チェックリストの方が適しています。

修正しやすく、どの条件が不足していたかも見えやすいからです。

いきなり複雑な仕組みへ埋め込むと、変更のたびに設定や実装を直すことになります。

案件ごとの資料や履歴が重要なら、Projectを使う

継続案件で、資料、過去判断、用語、関係者、品質基準などを共有する必要があるなら、Project型の環境が向いています。

ただし、Projectが主に保持するのは案件コンテキストです。

作業手順、例外、承認、完了条件は別に設計する必要があります。

対話形式の定型業務なら、GPTやGemを使う

Custom GPTやGemのような目的別AIは、毎回同じ長い指示を入力する負担を減らせます。

例えば、次を固定できます。

  • 対象業務

  • 参照知識

  • 出力形式

  • 確認項目

  • 禁止事項

  • 不足情報の扱い

ただし、利用者が自由な形式で入力すれば、出力は安定しません。

入力テンプレートや利用手順も合わせて用意します。

また、作成画面のPreviewで一度成功しただけでは、業務上の再現性は確認できません。

Previewは設定確認の手段であり、実データ、例外、別担当者によるパイロットの代わりにはなりません。

複数案件へ持ち運ぶ専門手順なら、Skillを使う

特定案件だけでなく、複数案件や複数担当者で使う専門手順なら、Skillのような再利用単位が適します。

良いSkillには、具体的で反復するタスク、明確な指示、必要に応じた例、使用条件、単一のワークフローへの集中が必要です。

ただし、Skillへした時点で完成ではありません。

実際の利用結果、失敗、例外をもとに内容を更新します。

工程と分岐が安定し、外部システムへ接続するならWorkflowを検討する

入力、処理順、分岐、例外、承認が十分に安定したら、Workflowやシステム連携を検討できます。

外部サービスを操作する場合は、最初から実行まで一体化せず、次の順序で試す方が安全です。

読み取り
→ 候補・下書き作成
→ 人間確認
→ 承認
→ 外部実行
→ 実行結果確認

これによって、AI出力の品質と、外部操作の権限を別々に検証できます。

API、MCP、エージェント基盤、状態管理などの技術構成は、フェーズ10で詳しく扱います。

例外・停止・手動復帰を決めてから、パイロットを始める

自動化の設計で見落とされやすいのが、正常に動かなかった場合です。

実務では、失敗しない仕組みよりも、失敗を検知し、安全に止まり、復帰できる仕組みの方が重要になることがあります。

例外を「AIが失敗した」でまとめない

失敗原因が違えば、対応も変わります。

代表的な例外は次です。

  • 入力不足：必須情報がない

  • 入力矛盾：資料間で日付や数値が違う

  • 対象外：標準手順の適用範囲ではない

  • 判断不能：基準だけでは確定できない

  • 低信頼：音声品質などの理由で抽出が不安定

  • 禁止事項：個人情報や機密情報を含む

  • システム障害：接続先を利用できない

  • 二重処理リスク：すでに登録や送信が済んでいる可能性がある

  • 承認待ち：人間判断が完了していない

例外を分類すると、再実行すべきもの、人間へ渡すもの、処理を中止するものを分けられます。

再試行すれば解決する失敗と、解決しない失敗を分ける

一時的なネットワーク障害や接続先の混雑は、時間を置いて再試行すれば解決する可能性があります。

一方、必須入力の欠落、権限不足、対象外データ、不正な形式は、同じ条件で再試行しても解決しません。

技術的なワークフロー基盤でも、一時的な失敗と再試行不能な失敗を区別し、再試行回数、間隔、上限を設定する設計が使われます。

フェーズ8では、少なくとも業務上の停止条件を決めます。

  • 必須入力がない

  • 重要情報が矛盾している

  • 対象外カテゴリである

  • 高リスク条件に該当する

  • 同じ処理が一定回数失敗した

  • 二重実行の可能性がある

  • 承認期限を超えた

  • 人間が中止を指示した

再実行しても、同じ外部操作を繰り返さないようにする

メール送信、顧客データ更新、タスク登録、支払いなどでは、処理の途中まで成功した後に失敗することがあります。

その状態で全工程を最初から再実行すると、二重送信や二重登録が起きる可能性があります。

再実行前に、次を記録・確認します。

  • どの工程まで完了したか

  • 外部操作はすでに実行されたか

  • 何が失敗したか

  • 入力や条件をどう変更したか

  • 誰が再実行を承認したか

  • 同じ処理を識別するIDや記録があるか

ワークフロー設計では、同じ処理を複数回実行しても結果が重複しない「冪等性」が重要になります。

技術的な実装はフェーズ10の範囲ですが、フェーズ8でも「再実行時に二重処理が起きないか」という業務要件は定義しておく必要があります。

AIを使えないときの手動手順を残す

AIサービス、連携先、ネットワークが常に利用できるとは限りません。

AIが停止しただけで業務全体が止まる設計は、安定した標準業務とはいえません。

最低限、次を残します。

  • 手動処理の担当者

  • 手動時に必要な入力

  • 手動時の手順

  • 一時保存場所

  • 後から通常運用へ戻す方法

  • 手動処理済みであることの記録

手動復帰は、AI導入前の非効率な手順を永久保存するという意味ではありません。

障害時にも最低限の業務を続けられる経路を持つということです。

自動化しない方がよい例外を明示する

すべての例外を処理できる万能ルールを目指すと、仕組みは複雑になります。

低頻度かつ高リスクの例外は、人間へ渡した方が合理的です。

例えば次です。

  • 顧客との重大な紛争

  • 契約解釈が分かれる案件

  • 異例の金額や取引

  • 本人へ重大な不利益を与える判断

  • 前例のない障害

  • 経営判断を必要とする案件

例外を人間へ渡せることは、自動化の失敗ではありません。

通常処理と例外処理の境界を正しく設計できている状態です。

パイロットでは、速度だけでなく修正量と例外率を見る

標準手順を作ったら、本格展開前にパイロットを行います。

ここで重要なのは、成功しやすい事例だけを選ばないことです。

正常例に加えて、入力不足、曖昧な判断、対象外など、実際に起こり得る重要な例外を含めます。

件数だけでなく、必要なケースを含んでいるかを確認する

必要なパイロット件数は、業務頻度、入力の種類、リスク、例外の多さによって変わります。

「10件試したから十分」とは限りません。

少なくとも次を含むか確認します。

  • 代表的な正常例

  • よくある入力不足

  • 判断が分かれやすい例

  • 重要な例外

  • 高リスク条件

  • 別担当者が作成した入力

低頻度・高リスクの業務では、多数の実例を待つだけでなく、過去事例や模擬事例を使う必要もあります。

Before／Afterは処理時間だけで評価しない

AI導入で処理時間が短くなっても、品質が下がったり、確認者の負担が増えたりすれば成功とはいえません。

測定候補は次です。

  • 総処理時間

  • AI処理時間

  • 人間確認時間

  • 修正箇所数

  • 必須項目の欠落率

  • 例外率

  • 差し戻し率

  • 担当者間のばらつき

  • 外部実行後の訂正数

  • 利用者の負担

  • 最終成果の採用率

初期段階では、すべてを厳密に測定する必要はありません。

ただし、「なんとなく便利」という感想だけで本格展開しないことが重要です。

失敗と人間の修正を、次の改善材料として残す

生成AIの運用では、実利用者のフィードバック、人間による修正、出力と評価の記録を、改善へ戻すループが重要です。

フィードバックは、元の処理や入力へ追跡できる状態で残す必要があります。

記録する候補は次です。

  • 使用した入力

  • AIの出力

  • 人間が修正した箇所

  • 修正理由

  • 発生した例外

  • 最終的な採否

  • 使用した手順やSkillの版

  • 処理日時

  • 承認者

ただし、これはすでにフェーズ11の高度な評価基盤を構築するという意味ではありません。

フェーズ8では、失敗を再現し、次の標準手順へ反映できる最低限の記録を残します。

別担当者が使えなければ、まだ個人技である

設計者本人は、手順の不足を頭の中で補えます。

だからこそ、別担当者による利用テストが必要です。

次を観察します。

  • 説明なしで入力を準備できるか

  • どこで迷うか

  • 何を誤解するか

  • 確認項目を正しく見られるか

  • 例外時に止まれるか

  • 完了状態を判断できるか

  • 設計者へ何回質問するか

別担当者が再現できない場合、AIの問題とは限りません。

手順、入力、用語、例、完了条件が不足している可能性があります。

改善しない場合は、入力・手順・AI能力を切り分ける

結果が悪いとき、すぐにモデルを変更するのは早計です。

原因を次に分けます。

  • 入力情報が足りない

  • 入力形式が安定していない

  • 手順が曖昧

  • 判断基準が曖昧

  • 例外の扱いがない

  • 確認方法が弱い

  • AIの能力が足りない

  • そもそも対象業務が不適切

原因によって、改善策は変わります。

高性能モデルへ替える前に、業務設計側の問題を確認します。

効果が弱ければ、標準化や自動化を中止する

パイロットの目的は、導入を成功したことにすることではありません。

継続すべきかを判断することです。

次の場合は、修正または中止を検討します。

  • 確認時間を含めると速くならない

  • 修正量が減らない

  • 重要な欠落を検知できない

  • 例外が多すぎる

  • 担当者の負担が増える

  • 手動より品質が安定しない

  • 標準化コストに見合わない

  • 現場が継続して使わない

  • リスクを十分に抑えられない

自動化しないという判断も、成熟したAI活用の一部です。

ケース：会議録からタスク台帳への反映を半自動化する

ここまでの考え方を、会議後の業務へ当てはめてみます。

会議録はAI活用が広がりやすい仕事ですが、「文字起こしを要約する」だけでは、業務改善にならない場合があります。

会議後に必要なのは、きれいな文章だけではありません。

  • 何が決まったか

  • 何が決まっていないか

  • 誰が何をするか

  • 期限はいつか

  • 次回まで何を追跡するか

これらを確実に実務へ接続する必要があります。

As-Isでは、決定とタスクが複数の場所へ分散する

従来の運用では、次のようになりがちです。

会議
→ 参加者が個別にメモ
→ 担当者が議事録を作成
→ メールやチャットで共有
→ タスクは各自の管理方法へ分散
→ 次回会議まで追跡されない

この問題に対し、議事録作成だけをAI化しても、タスクの分散や未完了追跡は残ります。

フェーズ8では、まず「会議録からタスク登録候補を作る」という個別業務を標準化します。

業務全体の再設計は、次のフェーズ9で扱います。

標準入力をそろえる

最低限、次を用意します。

  • 会議名

  • 開催日時

  • 参加者

  • 会議目的

  • 対象案件

  • 音声または文字起こし

  • 既存の未完了タスク

  • 共有範囲

音声や文字起こしだけを渡すより、会議の目的と対象案件がある方が、何を重要と見るべきかが明確になります。

AIには、候補と根拠を出させる

AIの出力は、次の候補に分けます。

  • 決定事項候補

  • 未決事項候補

  • 課題候補

  • タスク候補

  • 担当者候補

  • 期限候補

  • 根拠となる発言箇所

  • 要確認事項

ここで「候補」とするのが重要です。

会議中の提案や希望を、正式な決定として扱わないようにします。

人間は、決定、担当、期限、共有範囲を確認する

人間確認を次に限定します。

  • 決定と提案が混同されていないか

  • 担当者は正式に引き受けたか

  • 期限は明示されたか

  • 既存タスクと重複していないか

  • 機密情報を含まないか

  • タスク台帳へ登録してよいか

根拠発言を付けることで、全文を最初から読み直す負担を減らせます。

ただし、音声品質が低い場合や議論が複雑な場合は、周辺文脈を確認します。

例外は登録せず、確認待ちへ分ける

次のケースは自動登録しません。

  • 発言者を特定できない

  • 担当者が未定

  • 期限が「早めに」など曖昧

  • 決定が後から撤回された

  • 複数の期限が出ている

  • 機密事項が含まれる

  • 文字起こしの品質が低い

  • 既存タスクと重複する可能性がある

これらは「確認待ち」として別に出力します。

完了条件を定義する

この業務の完了条件は次です。

  • 決定事項と未決事項が分かれている

  • タスク候補ごとに根拠発言がある

  • 担当者と期限が確定、または未定表示になっている

  • 人間が確認・承認している

  • 重複登録がない

  • 例外が未処理のまま隠れていない

  • 指定した台帳へ一度だけ登録されている

  • 承認者と登録日時が残っている

ここまで決めることで、単なる要約から、再現可能な半自動業務へ変わります。

実務テンプレート：業務標準化・半自動化キャンバス

実際に一つの業務を選び、次のテンプレートを埋めてみてください。

業務名：

1. 目的
この業務によって、誰のどの状態を変えるか：

2. 対象範囲
今回標準化する開始点：
今回標準化する終了点：
対象外：

3. 発生条件
いつ、何をきっかけに始まるか：

4. 標準入力
必須入力：
任意入力：
参照資料：
入力形式：
対象期間・基準日：
入力不足時の扱い：
入力してはいけない情報：

5. 現在の工程
工程1：
工程2：
工程3：
迷いやすい場所：
手戻りが起きる場所：
人によって違う場所：

6. AIへ任せる作業
抽出：
分類：
変換：
下書き：
不足・矛盾の検出：
その他：

7. 人間が保持する判断
採否：
例外：
外部影響：
高リスク判断：
最終承認：

8. 標準出力
形式：
必須項目：
禁止事項：
未確認事項の表記：
保存先：
共有先：
ファイル名：
承認状態の表記：

9. 完了条件
第三者が完了を判断できる条件：

10. 例外
想定例外：
例外の分類：
エスカレーション先：
処理を止める条件：

11. 再実行
再実行できる条件：
再実行してはいけない条件：
再実行前に確認すること：
二重処理を防ぐ方法：
前回の処理状態を確認する方法：

12. 手動復帰
AIが使えない場合の担当者：
手動手順：
一時保存先：
手動処理済みの記録方法：
通常運用へ戻す方法：

13. 承認と記録
承認者：
処理日時：
使用した入力：
生成した出力：
人間が修正した箇所：
修正理由：
発生した例外：
使用した手順・Skillの版：
最終結果：

14. パイロット評価
総処理時間：
人間確認時間：
修正量：
必須項目の欠落：
例外率：
差し戻し率：
担当者間の差：
現場負担：
継続／修正／半自動維持／手動復帰／中止：

すべてを最初から詳細に埋める必要はありません。

まず一つの業務を手動または半自動で試し、実際に起きた失敗や例外をもとに更新します。

標準化・半自動化に向かない業務もある

ここまで標準化の方法を説明してきましたが、すべての仕事を同じ手順へ変えるべきではありません。

毎回、目的や前提が大きく変わる仕事

新規事業の重要判断、危機対応、複雑な交渉などは、毎回の条件が大きく異なります。

情報整理や論点抽出は標準化できても、結論まで固定手順にしすぎると、重要な違いを見落とします。

人間関係や交渉そのものが価値になる仕事

採用面談、顧客との重大な対話、部下へのフィードバックなどでは、文章候補や論点整理にAIを使えても、相手の反応を受けた判断まで固定できないことがあります。

重大で不可逆な判断

解雇、与信停止、大規模な資金移動、医療上の最終判断などは、効率だけで完全自動化を目指すべきではありません。

AIの利用が本人や第三者へ重大な影響を与える場合、人間による実質的な監督と、責任者の明確化が必要です。

低頻度で、標準化コストが高い仕事

年に一度しか起きず、条件も毎回異なる仕事なら、詳細な仕組みを保守するより、案件ごとに構造化して対応した方がよい場合があります。

例外が仕事の中心になっている業務

通常処理より例外判断の方が多い業務は、例外を無理に標準化しない方がよいでしょう。

この場合、AIの役割を、資料整理、過去事例検索、論点候補、確認事項の提示などに限定します。

フェーズ8の到達条件

次を満たせれば、フェーズ8の実践が進んでいると判断できます。

  • 対象業務の目的と範囲を説明できる

  • 入力・作業・判断・出力が分かれている

  • 標準手順がある

  • 完了条件が確認可能である

  • AIと人間の責任が明確である

  • 人間の確認項目が限定されている

  • 例外が分類されている

  • 停止条件がある

  • 再実行と二重処理防止を考えている

  • AI停止時の手動手順がある

  • 失敗と修正が記録されている

  • 別担当者が一定品質で再現できる

  • Before／Afterを確認している

  • 自動化しない判断もできる

ここで最も重要なのは、別担当者による再現です。

自分だけが使いこなせるGPTやSkillは、便利な個人ツールではあっても、まだチームの標準業務ではありません。

個別業務が安定したら、業務全体の流れを見直す

フェーズ8では、一つの繰り返し業務を標準化し、人間確認付きで安定させました。

複数の業務を標準化していくと、別の問題が見えてきます。

  • 同じ情報を複数回入力している

  • 承認待ちが長い

  • AI処理は速いのに、人間の引き継ぎで止まる

  • 不要な帳票を作り続けている

  • 前工程の入力品質が低い

  • 複数のツールへ同じ内容を登録している

  • 会議と報告が重複している

ここから先は、既存工程の一部を速くするだけでは足りません。

業務の目的へ戻り、不要工程、役割、データ、承認、例外、KPIを含めて全体を組み直す必要があります。

それが次のフェーズ9「AI前提の業務フロー再設計」です。

ただし、フェーズ8を飛ばして大規模な業務改革へ進むと、現場で何が成功し、何が失敗するかを把握できないまま設計することになります。

反対に、不要な業務を精緻に標準化しすぎるのも問題です。

フェーズ8では再現可能性を作り、フェーズ9ではその業務自体が必要かを改めて問う。

この二つを分けて考えると、AIによる業務改善を、単なる作業の高速化で終わらせずに済みます。

まとめ：自動化の前に、仕事を説明できる状態を作る

AI活用が進むと、毎回の依頼をテンプレートへ変え、目的別AI、Skill、Workflowへ発展させたくなります。

その方向は妥当です。

ただし、ツールへ実装する前に、次を説明できる必要があります。

  • 何のための業務か

  • どこからどこまでを扱うか

  • 何を入力するか

  • 何をAIへ任せるか

  • 何を人間が判断するか

  • 何をもって完了とするか

  • どんな例外があるか

  • どこで止めるか

  • 失敗後にどう戻すか

  • 再実行時に二重処理が起きないか

  • 別担当者でも再現できるか

  • 本当に自動化する価値があるか

AI活用の成熟とは、AIへ多くを任せることではありません。

目的、情報、判断、工程、評価、権限、責任を設計し、AIと人間が安定して成果を出せる状態へ進むことです。

フェーズ8で最初に取り組むなら、最も大きな業務を選ぶ必要はありません。

毎月、毎週、あるいは毎日繰り返している仕事から、一つだけ選んでください。

現在の仕事を観察し、入力、作業、判断、出力を分ける。AIには下書きや抽出から任せ、人間の確認箇所を限定する。例外を記録し、別の担当者で試す。

その小さな半自動化が、個人のAI活用を、再現可能なチームの能力へ変える起点になります。

関連記事

同じ指示や修正を、その場限りの会話で終わらせず、ルール、Skill、テスト、テンプレートなどの組織知へ変える方法を整理しています。

プロンプトだけでなく、コンテキスト、ツール、状態、評価、権限まで設計対象が広がった背景はこちらで解説しています。

AIへ任せる範囲と、人間が保持すべき採否、停止、回復、責任の境界はこちらで詳しく考察しています。

企業で実行する場合

この記事で扱った業務標準化や半自動化を、自社の研修、業務設計、AIエージェント開発、導入後の改善運用へ落とし込みたい場合は、支援内容を以下の記事にまとめています。

生成AIを導入した。でも、業務は変わらなかった。そんな企業へ研修から業務設計・開発・改善運用まで支援します

AI活用成熟度12フェーズの記事一覧

出典・参考資料

いいなと思ったら応援しよう！

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中 社会問題×マーケティングが好き / ㍿小さな一歩（前澤ファンド出資先）で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。