導入
月次報告を開く。報告上は、ほぼ全社員がAIを使っている。全社導入から半年。まず触ってもらう段階は越えたように見える。
それなのに、手応えが薄い。
文章を整える。資料を要約する。メールの下書きを作る。便利ではあるが、「仕事の流れが変わった」「この作業は手を離れた」と言えるところまでは届いていない。推進する側にも、使う側にも、「もっとやれるはずなのに」という違和感が残る。

この違和感の原因は、まだ決めつけられない。教え方が足りないのかもしれない。対象業務とAIの相性が悪いのかもしれない。社内情報や権限が足りない可能性もある。AIを入れた後の確認作業が重いことも考えられる。
だから必要なのは、「活用が浅い」と社員を評価することではない。どの原因が詰まりを起こしているのか、実在する業務を一つ選んで切り分けることだ。この記事では、その調べ方と、AIを今の手順へ足す段階から、AIを前提に手順を組み直す段階へ進む条件を考える。
作戦会議




クロスヘアは利用率だけを成果にする甘さを突き、テクは時間だけに置き換える危険を止めた。そこへレッカーが、測定そのものにも手間がかかると引き戻す。三者の指摘を合わせると、全社一斉の細かな調査ではなく、対象を絞った試行が必要だと分かる。
ここで本稿の二段階を先に説明しておこう。レベル1は、今の手順へAIを足し、人が出力を確認しながら試す段階。レベル2は、AIを使う前提で手順を組み直し、人が見る場所を決め直した段階だ。これは一般の共通規格ではなく、今回の問題を整理するための呼び名である。




全件確認を外した瞬間に完成するわけではない。通常案件へ流したものも抜き取りで確かめ、見逃しが増えたら全件確認へ戻す。ツールが止まったときは、途中の案件を特定し、二重処理を防いで旧手順へ切り替える。そこまで決めて初めて、人が見る範囲を安全に狭められる。

結論は全員一致ではない。オメガが求めた他社比較は採用するが、順位づけには使わない。テクが求める測定も採用するが、全業務には広げない。レッカーが警戒する現場負担を避けるため、推進側が同時に支援できる件数を先に決める。これが今回の進め方だ。
ミッションの核心
月次報告が示すことと、示さないこと
今回分かっているのは、月次報告上ではほぼ全社員がAIを使っているということだ。ただし、対象人数、集計期間、利用と数える操作は示されていない。月に一度の実行と、毎日の業務利用が同じ一人として数えられている可能性もある。
したがって、この数字から言えるのは利用が広がったことまでだ。仕事への定着や成果までは判断できない。一方で、利用率が無価値なわけでもない。誰にも触られていない段階を越えたからこそ、次は「誰が使ったか」ではなく「どの仕事がどう変わったか」を調べられる。
調べる軸は一つではない。時間を減らしたい業務なら、人が手を動かした時間を見る。ミスを減らしたい業務なら、差し戻しや見逃しの割合を見る。依頼を多く処理したいなら、同じ期間の処理件数を見る。以前はできなかった分析や提案が可能になったなら、それ自体が成果候補になる。
つまり、AI活用の深さを時間削減だけで決めない。業務ごとに何を良くしたいのかを先に一つ決め、目的に合う数字で確かめる。利用率の次に変えるべきなのは、答えではなく測る問いだ。
他社比較は、候補を探すときだけ使う
他社、同業他社、身近な詳しい人がどこまで進んでいるかを知ることは、選択肢を増やす助けになる。ただし、「利用者が何人いるか」「ツールを何本作ったか」だけを並べても、自社が次に何をすべきかは決まらない。
比較するなら、同じような業務について、何をAIへ渡し、何を人に残し、どの変化を成果としたのかを見る。間違えたときの影響や、社内情報へ接続できる範囲が違えば、同じ方法をそのまま移すことはできない。
他社調査を常設の仕事にする必要もない。候補業務を選ぶときだけ、担当者と確認期限を決めて調べる。参照日を記録し、候補が決まったら調査を終える。比較表を永遠に更新する仕事を推進担当へ背負わせないためだ。

その通りだ。なお、進み方を見えるようにすれば取り残され感が消える、とはまだ断定できない。試すなら、社員が「自部署の次の行動を説明できるか」など観察する項目を一つ決め、施策の前後で変化を見る。他社比較は安心を約束する薬ではなく、候補を探すための地図である。
一つの業務を、最初から最後まで追う
話を抽象語だけで終わらせないため、分類作業を例に流れを追ってみよう。これは説明用の仮定であり、今回の会社で実際に行われている業務だと断定するものではない。
レベル1では、担当者が案件の文章をAIへ渡し、AIが分類案を返す。その後、担当者が一件ずつ元の基準と照らし、誤りを直して登録する。AIの返答が速くても、読む時間と直す時間が大きければ、担当者は仕事が減ったと感じにくい。
次に、業務責任者と現場担当が、どの条件ならAIに続けさせず人へ戻すかを言葉にする。情報不足、複数分類への該当、顧客への影響が大きい案件など、業務に応じた条件を決める。推進担当は、その条件を入力画面やツールの動きへ落とし込む。
ただし、AI自身に「これは通常案件だ」と判定させるだけでは危ない。例外を通常と誤判定した案件は、人の画面に上がってこないからだ。そこで試行中は、通常へ流れた案件からも一定の範囲を抜き取り、同じ合格条件で人が確かめる。どれだけ抜き取るか、どの状態なら全件確認へ戻すかは、実測前に業務責任者が決める。今回の材料には基準値がないため、ここで数字は作れない。
この試行で、確認を減らしても品質を保てると確認できた範囲だけ、手順を組み直す。逆に見逃しが許容できない業務なら、全件確認を残す。それでも情報収集や入力が減り、目的としていた品質や処理量が良くなれば、価値はあり得る。

レベル2とは無人化の別名ではない。誰が何を見るかを、失敗の影響と実測結果に合わせて決め直した状態だ。
AIへ仕事を覚えさせる前に、仕事を説明できるか
「AIに業務を覚えさせてツール化する」とは、必ずしもAIモデルを追加で学習させることではない。入力する情報、判断の順序、期待する出力、禁止事項、人へ戻す条件をそろえ、繰り返し使える形にすることだ。
指示文で足りる場合もあれば、ひな型、社内情報の検索、入力画面、プログラムが必要な場合もある。しかし、元の手順が担当者ごとに違えば、ツールへ固定する内容も揺れる。AIは仕事を消す魔法ではなく、仕事の曖昧さを映す鏡だ。
ただし、鏡に映るのは現場の曖昧さだけではない。AIの性能不足、必要な情報へつながらないこと、権限不足、入力画面の使いにくさも同じように確かめる。「現場がきちんと説明できないから悪い」と原因を押し戻してはいけない。

この節での判断は一つだ。ツールを作る前に、元の手順と人へ戻す条件を複数の担当者が同じように説明できるか確かめる。できなければ、先に仕事の手順をそろえる。
楽になったかと、利益が出たかは分ける
人の負担を見るときは、人が実際に手を動かした時間を比べる。AIが無人で処理している経過時間は別に記録する。AIが動く間、担当者が画面の前で待たなければならない場合だけ、その待ち時間を人の時間へ加える。
品質を見るなら、差し戻し、やり直し、見逃しなど、その業務の合格条件を先に決める。導入前後で同じ程度の難しさを持つ案件を比べ、処理件数を分母にした割合も見る。確認の方法が違えば発見できるミスの数も変わるため、共通の抜き取り確認など、同じ物差しが必要だ。
ここまでで分かるのは、主に負担、速さ、品質、処理量の変化までである。利益は別の判断だ。利益を見るには、AIやツールの利用料、作成費、保守費、障害による損失、増えた処理や売上の価値まで比べなければならない。今回、それらの実測値はないため、利益が出ているとは断定できない。
また、最初に作る手間と、普段の保守にかかる手間を混ぜない。導入直後だけを見れば有望な仕組みを早く捨てる恐れがあり、平常月だけを見れば更新や障害の負担を隠してしまう。比較する期間、対象件数、通常時と臨時対応の分け方を、測定開始前にそろえる。

時間が減っても、それだけで利益や新しい価値が生まれるわけではない。細切れの時間が別の雑務へ消えることもある。何をやめ、空いた時間で何を始めるかは、業務責任者が別に決める必要がある。
全社で競争せず、支援できる件数から始める
各部署へ一斉に候補を出させると、推進側へ棚卸し、作成、教育、問い合わせ、保守が集中する。だから「各部署から一件」ではなく、推進側が同時に支援できる件数を先に決める。実際の上限は担当人数や既存業務が不明なため、ここでは決め打ちしない。
進め方は、候補の受付、選定、試行、判定の順に区切る。優先順位は、繰り返しの多さだけでなく、目的の明確さ、手順を説明できるか、失敗時に元へ戻せるか、支援に必要な手間で決める。保留した部署には、誰が結果と次の受付時期を返すかも決めておく。
現場担当は、AIを使った後に残る確認や手直しを記録する。推進担当は、支援する候補を絞り、測定の仕組みを軽くする。業務責任者は、合格条件、人へ戻す条件、試行を続けるか止めるかを決める。決定権のない一般利用者でも、「毎回ここを直している」という事実なら出せる。
ツールの主担当だけを決めても足りない。代わりに直せる人を置き、入力条件、例外条件、変更履歴、権限、問い合わせ先を共有の場所へ残す。代行者が手順を再現できることまで確かめて、初めて属人化を減らせる。

全社でそろえるのは同じレベルではない。候補の選び方、確かめ方、やめ方である。部署ごとに「続ける」「作り直す」「今はやらない」が違ってよい。
まとめ
月次報告上でAI利用が広がったことは、入口を通過した印だ。ただし、成果を感じられない原因はまだ特定できていない。教育、対象業務、情報、権限、AIの出力、確認の重さを、実在する業務一件から切り分ける必要がある。
成功の物差しも一つではない。時間を減らすのか、品質を上げるのか、処理量を増やすのか、新しい仕事を可能にするのか。目的を先に決め、その目的に合う変化を導入前後で比べる。利用率だけを目標にした施策では不足するが、部署によっては基本的な使い方や権限の改善が先になる場合もある。
AIを今の手順へ足すレベル1から、AI前提で手順を組み直すレベル2へ進むときも、確認ゼロを目標にしない。例外の見逃しを確かめる抜き取り確認、全件確認へ戻す条件、停止時の切り替え、保守の代行者まで決める。

明日からの一歩は、立場によって違う。現場なら、毎回残る確認や手直しを一つ記録する。推進担当なら、同時に支援できる件数を決め、最初の候補を絞る。業務責任者なら、その業務で守る品質と、人へ戻す条件を決める。
詳細な記録項目は、この後の技術付録にまとめた。最初から全欄を埋める必要はない。試行の判断に必要な項目だけ選び、記録に使った時間も忘れずに数える。
技術付録
試行前に決めること
| 項目 | 決める内容 |
|---|---|
| 目的 | 時間、品質、処理量、新しく可能になる仕事のうち、主に何を見るか |
| 対象 | 比較する業務、案件の範囲、難しさ、処理件数 |
| 期間 | 導入前後を比べる期間。通常時と更新・障害時は分ける |
| 記録 | 現場担当、集計担当、判断する業務責任者を分ける |
| 記録負担 | 記録回数と、記録自体に使った人の時間 |
| 品質 | 合格条件、判定者、分母となる処理件数、確認方法 |
| 例外 | 人へ戻す条件、判定する人または仕組み、見逃しの調べ方 |
| 中止条件 | 全件確認へ戻す条件、作り直す条件、試行を止める条件 |
| 費用 | 利用料、初期作成費、平常保守費、臨時対応費の分け方 |
| 担当 | 主担当、代行者、記録の保管場所、問い合わせ先 |
人の負担、処理の速さ、費用は混ぜずに記録する。
- 人の作業時間:入力、確認、修正、転記、記録、保守、復旧で人が拘束された時間
- 経過時間:処理開始から完了までの時間。無人の処理時間を含む
- 品質:合格条件を外れた件数と、全処理件数に対する割合
- 処理量:同じ条件と期間で完了した件数
- 費用:利用料、作成費、保守費、障害対応費、失敗による損失
利益は、これらの費用と、増えた売上や処理価値、別の仕事へ使えた時間の価値を比べて初めて判断する。人の作業時間が減っただけで、利益が確定したとは扱わない。
全件確認を外す前の確認
例外だけを人へ戻す場合は、例外の判定そのものを試す。通常処理へ流れた案件からも決めた範囲を抜き取り、人へ戻すべき案件が混ざっていないか確かめる。見逃しの件数と割合を記録し、事前に決めた条件を超えたら全件確認へ戻す。
許容できる割合や抜き取り範囲は、失敗時の影響と実測結果によって業務ごとに決める。今回の材料には基準値がないため、他社の数字や根拠のない目標値をそのまま置かない。
停止時に戻れる状態を保つ
旧手順は、説明書を保存するだけでは動かない。次の内容を試行前に決める。
- どの状態になったら手作業へ切り替えるか
- 切り替えを決める業務責任者と代行者
- 旧手順と必要な様式の保管場所
- 停止中の案件と処理途中の案件を記録する方法
- 二重処理を防ぐ印と、復旧後に照合する担当
- 旧手順を代行者が試す時期
- 復旧後に未処理案件を再投入する順序

技術付録の項目は、報告書を立派にするためのものではない。どの原因を確かめ、誰が次の判断をするのかをそろえるための道具だ。記録の手間が改善効果を上回りそうなら、項目を減らすか試行を止める。その判断まで含めて、AI活用の次の段階である。

コメント