事務職はAIに奪われるのか——EC実務の「工程」で数え直す：2021年の予測を2026年に答え合わせする

事務職がまるごと消えるかを予測しても、答えは出ない。判断の単位は職業ではなく工程である。自分の一日を工程に割り、①代替がすでに始まっている ②誰がやっても結果が変わらない ③判断を伴わない、の3つに当てはまる工程を数える。当てはまらない工程が、いま自分に残っている仕事である。

• 2021年の予測で名指しされたのは運転や警備といった現業職だけではなく、事務の仕事も並んで挙げられていた。それでも4年半後のいま不安が残るのは、示されたのが職業名だけで、事務のどの工程が消えるのかは示されなかったからである。
• 代替の速度を決めているのは技術の進歩そのものではない。導入コスト・プラットフォームの都合・移行できる人がいるかという3つのブレーキが決めている。EC実務ではこれが毎年目に見える形で起きる。
• 残る工程は「判断」と「例外処理」に寄る。手当ては判断の材料を自分で作れる状態を保つことに集約される。

結論：職業で不安がるのをやめ、工程で数える

受注一元管理を入れている店舗なら、朝いちで開く画面は1つで済む。全モールの注文が1画面に集約され、ステータスの呼び名もそろっている。入れていない店舗では、楽天RMSの受注管理を開き、Amazonセラーセントラルの注文管理を開き、Shopify Adminの注文一覧を開いて、同じ「今日出す注文の確認」を3回する。同じ職種、同じ職務内容なのに、この時点で作業量が3倍違う。

この差がすでに答えの一部である。3回開いていたその時間は、AIが登場する前から製品として消せる状態にあった。置き換えたのは知能ではなく、ツールの導入という意思決定である。そして一元管理を入れた店舗でも、担当者の仕事は消えていない。1画面になった代わりに、システムが自動で処理できなかった注文——備考欄に要望が書かれたもの、同梱指定のあるもの、住所が明らかに不完全なもの——だけが手元に残る。減ったのは作業で、残ったのは例外処理である。

この状態で「事務職はAIに奪われますか」と検索しても、答えは出ない。問いの立て方が合っていないからだ。職業名は、工程の束につけられたラベルにすぎない。「EC運営担当」という職業が丸ごと消えるか残るかを議論しても、束の中身が1本ずつ違う速度で減っていく現実には届かない。実際に起きているのは、束の中の何本かが静かに抜けていくことである。

だから数える単位を工程に落とす。判定に使う条件は3つでいい。

• ① 代替がすでに始まっている——その作業を肩代わりする製品やサービスが、すでに世の中に存在して売られているか。「将来できそう」ではなく「もう買えるか」で見る
• ② 誰がやっても結果が変わらない——自分がやった場合と、隣の席の人がやった場合と、外注先がやった場合で、出てくるアウトプットが同じになるか
• ③ 判断を伴わない——手順書に書き切れるか。書こうとして「ケースバイケース」と書きたくなったら、それは判断である

3つとも当てはまる工程は、遅かれ早かれ自分の手から離れる。1つでも外れる工程が、いま自分に残っている仕事である。この記事の目的は、その仕分けを読者が自分の業務でやり切れる状態にすることであって、事務職の将来を予測することではない。予測は当たらないし、当たったかどうかを後から確かめることすらできない——これは言葉のあやではなく、次の見出しで実際に確かめて分かったことである。

もうひとつ、先に書いておきたいことがある。この不安には特有のねじれがある。「自分がいなくても回るのでは」と感じているのに、いざ引き継ぎ資料を作ろうとすると書けない。例外処理の判断は画面のどこにも書かれておらず、言語化された形で存在しないからだ。代替されるのが怖いのに、属人化だけが進んでいる。工程で数える作業は、この2つを同時にほどく。何が抜けたかが分かると同時に、抜けなかったものが言語化されるからである。

2021年の「消える仕事」予測を、2026年に答え合わせしてみた

この記事は、YouTubeで「AIに仕事を奪われる 事務職」と検索したとき最上位に出てくる動画を起点にしている。2021年10月22日に公開され、2026年8月11日時点で3,364,458回再生されている（https://www.youtube.com/watch?v=ZpeqlYodR50）。本記事の執筆時点も2026年8月11日で、公開から4年半以上が経った計算になる。予測が当たったかを確かめるには、そろそろ十分な時間である。

そこで公的統計にあたって答え合わせを試みた。結果を先に書くと、年月まで特定できる形で確かめられたのは1件だけだった。残りは「当たっていなかった」のではない。当たったかどうかを判定できる形のデータに、こちらがたどり着けなかった。

確かめられた1件：制度は動いた。職業が消えたとは言えない

運転者が乗っていない状態での自動運転（いわゆるレベル4相当）を許可制で認める「特定自動運行」の規定は、令和5年（2023年）4月に施行されている（警察庁「自動運転」https://www.npa.go.jp/bureau/traffic/selfdriving/index.html）。「技術はあっても法律が許さない」という当時の前提は、少なくとも制度の面では動いた。

ただしここから先は慎重に書く必要がある。制度が施行された年月は公表資料で確認できるが、それによって何人分の仕事が置き換わったかを示す数字は確認できていない。制度施行から数年が経った2026年になっても、路線バスの運転手という職業がなくなったとは言えない状態が続いている。「制度が整った」と「職が消えた」の間には、まだ埋まっていない距離がある。この距離の正体は、後半でEC実務に置き換えて扱う。

確かめられなかったもの：数字が経路によって割れる

以下は調べようとして、数値を書けないと判断したものである。書かない理由まで開示しておく。

調べようとしたこと	何が起きたか	この記事での扱い
事務従事者の就業者数の推移	参照した経路ごとに3通りの値が出て、相互に矛盾した。一方が男女計、他方が男性のみを総数として示していた疑いがある	数値を書かない。確認するなら総務省統計局「労働力調査」（https://www.stat.go.jp/data/roudou/index.html）の職業別集計にあたる必要がある、とだけ示す
「一般事務の職業」の有効求人倍率	複数の値が出たが、「常用（除パート）」なのか「パート含む」なのか「年度計」なのかの区分が特定できなかった。区分を変えれば値は動く	倍率を根拠にしない。確認するなら厚生労働省「一般職業紹介状況」（https://www.mhlw.go.jp/toukei/list/114-1.html）で区分をそろえて突き合わせる
企業の生成AI利用率	複数の割合が流通していたが、一次資料の本文で確認できなかった	割合を断定しない。「企業側の活用方針の策定は前回調査より進んでいる」という方向だけを扱う。確認先は総務省「情報通信白書」（https://www.soumu.go.jp/johotsusintokei/whitepaper/r07.html）と「通信利用動向調査」（https://www.soumu.go.jp/johotsusintokei/statistics/statistics05.html）
警備員数の推移／自動運転の許可件数	参照しようとした公式ページに到達できなかった、または公式ページ本文に件数の記載がなかった	書かない

答え合わせに使える最新の年平均という意味では、労働力調査の2025年平均結果（基本集計）が2026年2月13日に公表されている。2026年8月時点で「最新の年平均」と言えるのは2025年分までで、それより後は月次や四半期の粒度でしか追えない。予測の検証に年単位のデータを求めると、そもそも1年半前までしか見えないという制約がある。

この結果自体が、記事の主張の証拠になっている

4年半経っても、職業単位の予測は検証すらできなかった。調べ方が足りないと言われればそれまでだが、より本質的には、職業という単位が検証に耐えないほど粗いということである。「事務職」という括りの中には、伝票番号を管理画面に貼り戻す作業と、返品を受けるかどうかを決める作業が同居している。前者はすでにほぼ置き換わり、後者は1ミリも置き換わっていない。この2つを合算した数字が上がろうが下がろうが、明日の自分の仕事の説明にはならない。

だからこの記事の残りは予測をしない。いま自分が触っている工程を1本ずつ判定する手順だけを書く。

名指しはされていた。示されなかったのは「どの工程か」である

ここで一つ、前提を正しておきたい。2021年前後の「なくなる仕事」の予測で挙がっていたのは、運転や警備、工場や倉庫といった現業職だけではない。事務の仕事も並んで挙げられていた。つまり事務職は、名指しされていなかったから不安なのではない。名指しされていた。それでも4年半後のいま、当の事務職が「自分の仕事はどうなるのか」を検索し続けている。

名指しされたのに、何が消えるのか分からないまま時間が過ぎた。この宙ぶらりんには理由がある。示されたのは職業名だけで、その職業の中のどの工程が消えるのかは示されなかったからだ。そして事務の仕事は、この「どの工程か」を抜きにすると、自分の一日に当てはめようがない構造をしている。

現業職は職務が丸ごと消え、事務職は工程が虫食いで消える

現業職の代替は分かりやすい。ハンドルを握る人がいなくなれば、その職務は丸ごと消える。だから予測もしやすいし、消えたかどうかも目で見て分かる。世間の話題になるのはこちらである。

事務職はそうならない。抜けるのは職務ではなく工程で、しかも一度に抜けない。今週から受注データの取り込みだけが自動になり、来月から住所の表記ゆれの直しだけが消え、半年後にレポートの体裁づくりだけが要らなくなる。そのたびに「まだ仕事はある」と確認されるので、危機は起きない。代わりに、残っている作業の密度だけが上がっていく。判断の要らない作業が抜けた分、判断ばかりが残るからだ。

この進み方の厄介なところは、本人の体感が「楽になった」ではなく「なんだか疲れる」になる点である。手を動かす時間は減ったのに、決めなければならない回数は減らない。むしろ増える。ここに気づかないまま「作業時間が減った＝自分の価値が減った」と読み替えてしまうと、不安だけが残る。

不安が消えないのは、抜けた工程を数えていないからである

もう一つ、事務職側の不安が漠然としたまま続く理由がある。抜けた工程を誰も数えていない。現業職なら「この路線は無人運行になった」という形で外から見えるが、事務職の工程は、抜けた瞬間に誰の記録にも残らない。受注データの取り込みが自動になった日を、日報に書いた人はいない。

数えていないので、「自分の仕事のうち何割が置き換わったか」を誰も答えられない。答えられないから、最大値である「全部」を想像してしまう。この記事で工程表を作る目的の半分は、この「全部かもしれない」を「10工程中3つだった」に変えることにある。数えられた不安は、対処できる課題に変わる。

境界線は「どこから人か」で引かれている

虫食いの境界がどこに落ち着くのかについては、すでに一つの型がある。問い合わせ対応の現場では、定型的な一次返信をAIに任せ、苦情・キャンセル・欠品といった案件から人に渡す、という線引きが実際に運用されている。この線が引ける工程は代替が進み、線が引けない工程は残る。「AIが賢いかどうか」ではなく「線が引けるかどうか」で決まっている。問い合わせ対応での線の引き方については問い合わせ対応をAIに任せる範囲の線引きで個別に扱っているので、そちらを先に見てもらってもいい。

そしてこの「線を引く」作業そのものは、代替されていない。誰かが決めなければならず、しかも決めた結果が事故に直結する。虫食いが進むほど、線を引ける人の価値だけが上がる。これが後半の手当ての話につながっていく。

動画が語らなかった4つの前提を、EC実務に置き換える

「この仕事はAIに置き換わる」という話には、たいてい4つの前提が省略されている。省略されたまま読むと、実際より速く・広く・一方向に置き換わるように見える。EC実務の言葉に置き換えると、この4つは全部、日々の運用の中で目に見える形をしている。

前提1：技術の完成日と、自分の仕事から抜ける日は別である

「2030年までに」という言い方の主語は誰なのか。技術が完成する日と、自社が導入を決裁する日と、自分の手からその作業が抜ける日は、それぞれ別の日付である。しかも順番は必ずこの通りで、間隔は会社の体力と優先順位で決まる。

EC実務でいえば、商品説明文の初稿生成はすでにプラットフォームの標準機能に入っている。Shopifyは商品説明文の生成を公式機能として提供している（Shopify Magic のヘルプ）。それでも、自社の全商品ページがそれで書き直されているかというと、そうはなっていない店舗のほうが多い。使える状態にあることと、業務手順が変わることの間には、意思決定という距離がある。「いつ奪われるか」を技術のニュースで測ろうとすると、この距離をゼロと見積もることになる。

前提2：判断基準は「技術的に可能か」ではなく「月いくらか」である

2つ目の省略は費用である。EC運営を2〜3名で回している現場で、ある工程を自動化するかどうかを決める基準は、技術的な実現可能性ではない。月額と、初期設定にかかる人日と、それを回収できる作業時間の3つである。月にわずかしか発生しない作業のために、月額を払って初期設定に数日かける判断は通らない。だからその工程は、技術的にはとっくに代替可能でも、人がやり続ける。

逆もある。反復回数の多い工程は、費用の話が一瞬で通る。1件の注文につき3チャネル分の在庫を手で合わせているなら、それは月に何百回という反復になっていて、回収の計算が誰にでもできる。自分の工程がどちら側かは、後半の表の「反復」の欄を見れば分かる。代替の順番は、難易度順ではなく回数順にやってくる。

前提3：自動化は片道ではない。戻ってくることがある

これが4つの中でいちばん語られない前提である。一度自動化した工程が、人の仕事として戻ってくることがある。技術が退化したからではなく、プラットフォーム側が方針を変えるからだ。

執筆時点の2026年に実際に起きた例がある。Shopifyで割引・送料・決済のロジックをカスタマイズしていた仕組みであるShopify Scriptsは、2026年4月15日以降は編集・公開ができなくなり、2026年6月30日に実行が終了した。移行先はShopify Functionsまたはパブリックアプリとされている（Shopify の Changelog）。

ここで起きるのは、自動化されていたはずの工程に「移行」という人の仕事が新しく生えることである。しかもこの手の変更が怖いのは、切り替わった瞬間に画面が赤くなってエラーが出るとは限らない点だ。エラーが出ないまま、想定と違う割引が適用された注文が普通に通る。気づくのは、テスト注文を流したときか、月末に粗利を見て違和感を持ったときである。

代替する側の仕組みそのものも、継続的に作り替えられている。Shopifyの管理API（Admin API）はGraphQL版が正面になり、バージョンが定期的に切られていく（Shopify Admin API）。楽天RMSのWEB APIやAmazonのSP-APIでも、仕様の追加や変更は同じように起きる。「作って終わり」の自動化は存在せず、作った分だけ保守が生える。

ここは範囲を限定して書く。上に挙げたのはShopifyを使っている店舗の話であって、EC全体の一般則としては書けない。ただし「使っているプラットフォーム側の都合で、自動化した工程が作り直しになることがある」という構造は、モールでも観点として同じように点検する価値がある。点検の仕方は単純で、加盟店向けのお知らせや開発者向けの変更履歴を、月1回でいいので自分の目で見る習慣を持つことである。

前提4：「作った人がもういない」問題は、代替の反対側で起きる

4つ目は移行先とセーフティネットの話である。工程が自動化されると、その工程を理解している人は組織から静かに減る。数年後に仕様変更が来たとき、設定した本人が退職していて、誰も中身を説明できないという状態が普通に起きる。

これは属人化が解消されたのではなく、属人化の置き場所が人からツールへ移っただけである。しかも人なら聞けるが、ツールは聞いても答えない。自動化を進めた組織ほど、この負債を抱える。逆に言えば、「その自動化が何をしているか説明できる人」という役割が、代替の進行と同じ速度で新しく生まれている。これは動画にも、多くの予測記事にも出てこない。消える仕事を数える人は多いが、生える仕事を数える人は少ないからである。

4つまとめると、代替の速度を決めているのは技術の性能ではない。費用・プラットフォームの都合・移行できる人がいるかどうかという、きわめて散文的な3つのブレーキである。そしてこのブレーキは、EC実務者の目の前に毎年現れる。

EC実務10工程の仕分け表：自分の一日をこの手順で数える

ここからが本題である。手順は4ステップで、紙とペンでもスプレッドシートでもいい。一度腰を据えれば、その日のうちに終わる分量である。

1. 昨日の自分の一日を工程に割る。「受注処理」のような大きな括りにしない。「保留になった注文を目視で確認する」「住所の表記ゆれを直す」まで割る。ひと続きの操作で終わる程度の粒度が目安になる
2. 各工程の右に、昨日それを何回やったかを書く。モール別に繰り返しているなら、その回数を書く。この欄が着手の優先順位そのものになる
3. 3条件を当てる。①代替する製品がすでに売られているか ②誰がやっても結果が同じか ③手順書に書き切れるか
4. 3つとも当てはまれば「代替済み寄り」、1〜2個なら「半分」、0〜1個なら「残る」。これだけである

判定に入る前に、一つ先に確認しておいたほうがいいことがある。この10工程のうち代替が進んだものの多くは、生成AIが来る前に、すでに一元管理SaaSによって商品化されていた。受注・在庫・商品登録をモール横断で扱うサービスは、生成AIが話題になるずっと前から存在し、多数のモール・カートに対応することを掲げている（たとえばネクストエンジン）。事務工程を最初に削ったのは生成AIではなく、その前の世代のSaaSである。この順番を取り違えると、「AIで効率化しよう」と言い出したその工程が、実はもう何年も前から製品として売られていた、という空回りが起きる。

10工程の仕分け（たたき台）

下の表はそのまま自分の環境に上書きして使う前提で作ってある。判定は複数チャネルを少人数で運用する形を想定したもので、自社の体制や導入済みツールによって変わる。「代替済み」は「自社がもう導入している」ではなく「もう買える状態にある」という意味である点に注意してほしい。この2つがずれている工程が、いちばん先に消える工程である。

工程	判定	判断が要るか	例外が出るか
1. 受注確認・保留注文の目視	半分	備考欄だけ要る	出る（自由記述）
2. 住所・氏名の整形	代替済み寄り	不要	ほぼ出ない
3. 在庫引当・在庫更新	代替済み。ただし設計は人	「どこを正本にするか」だけ要る	出る（同時受注・予約在庫）
4. 出荷指示・伝票番号登録	代替済み寄り	不要	ほぼ出ない
5. 問い合わせ一次対応	半分	案件による	出る（苦情・欠品）
6. 返品・交換の可否判断	残る	要る	ほぼ例外だけ
7. 商品登録・モール別のページ調整	半分（初稿は代替済み）	仕様適合と最適化は要る	出る（モール固有の規定）
8. 価格改定	決定は残る／反映は代替済み	要る	出る（原価・販促の変動）
9. レビュー対応	残る	要る	ほぼ例外だけ
10. 定例レポート作成	代替済み。ただし読むのは人	「何を異常と見るか」だけ要る	ほぼ出ない

代替済みの列に並んだ工程の共通点

2・4・10、そして3の実行部分。この4つに共通しているのは、AIが賢くなったことではない。判断が1ミリも含まれていないことである。住所の全角半角をそろえるのに、担当者の裁量が入る余地はない。伝票番号を元の受注画面に戻して登録する作業も、番号を打ち間違えないこと以外に価値がない。当サイトでも、受注メールから必要項目を機械的に抜き出す処理と、レポートの定型集計を自動化する処理は実際に手を動かして試している（受発注メールからのデータ抽出／受注処理をAIに投げる前のマスキング）。そこで難所になったのは精度そのものより、個人情報を渡さない前処理と、間違ったときにどう気づくかの設計だった。この2つはどちらも判断であり、代替されていない部分である。

残る列に並んだ工程の共通点

6・9、そして8の決定部分。こちらの共通点は、正解が1つに決まらないことである。同じ返品依頼でも、担当者によって受けるか受けないかが変わる。変わってよい。むしろ全部同じ答えを返すなら、それは判断ではなくルールなので、条件②に当てはまって代替側に落ちる。

価格改定が分かりやすい。売価を各チャネルへ反映する作業は代替できるが、その売価をいくらにするかは、原価・モールの手数料・ポイント原価・クーポン原価・送料無料ラインを全部足し引きして決めている。お買い物マラソンやスーパーSALEの期間中は、ポイント倍率の負担が乗る前提で粗利を見なければならず、平常時と同じ判断は使えない。ここを外すと、売上は伸びたのに粗利が減るという結果になる。この計算をしている限り、その工程は自分の手元に残る。

もう一つ、残る工程には「間違えたときのコストが非対称」という特徴がある。低評価レビューへの公開返信を1回まずい書き方で出せば、それは検索結果に残り続ける。返品の可否を誤れば、粗利とブランドの両方が傷つく。コストが非対称な工程を、監督なしで自動化する会社は少ない。これは技術ではなく、リスクの引き受け手の問題である。

いちばん危ないのは「半分」の列である

1・5・7の「半分」は、判定としては中間だが、実務上いちばん注意が要る。自動化した部分と人が見る部分の境目に事故が溜まるからだ。受注確認の備考欄がその典型である。「◯日以降に届けてほしい」「熨斗を付けてほしい」「置き配は不可」といった自由記述は、受注データの構造化された項目には入らず、備考欄というただのテキストにだけ存在する。ここを読み飛ばす仕組みを作ると、他がどれだけ自動化されていても出荷事故になる。

商品登録も同じ構造である。マスタとなる商品データから各モールへ書き出す仕組みがあっても、そこで終わらない。説明文の初稿は生成できるようになった一方で、モールごとの規定に合わせる作業と、売れるように整える作業は残っている。画像の規定、商品名の文字数、カテゴリや属性の選び方、禁止表現の扱いは、モールによって別物として運用されている。前者は仕様適合、後者は売上に直結するチューニングで、どちらも「同じ文章をコピーする」では終わらない。ここを「AIで商品ページが作れる」の一言で片付けると、公開後に売れない理由が分からなくなる。

表を埋め終わったら、右端にもう1列足す

ここが仕分けの本当の出口になる。「残る」と判定された工程の横に、その工程を続けるために自分に足りていないものを1行だけ書く。「価格改定の決定」なら、たとえば「ポイント原価とクーポン原価を含めた実質粗利を、自分で出せない」。「返品・交換」なら「返品率を商品別に出せていないので、判断の基準を数字で持てていない」。

この1行が、次に何を身につけるかの答えである。世の中の「AI時代に必要なスキル」の一覧から選ぶより、はるかに外れが少ない。自分の残った工程から逆算しているからだ。どんな力の付け方があるかはEC担当者がAI時代に積むべきスキルで具体的に整理しているので、書き出した1行を持った状態で読むと選びやすくなる。

残った工程に何を積むか：手当て3つを条件で比べる

ここで心構えの話はしない。「AIを触る習慣があるかどうか」という論点は「AIに仕事を奪われる人」に共通する習慣の記事で扱っている。こちらで書くのは、前の見出しで書き出した「足りていない1行」を、どの手段で埋めるかという選び方だけである。

手段は大きく3つしかない。独学、社内の実務に混ぜる、人に教わる。どれが優れているという話ではなく、費用の出どころと、時間の確保のしやすさが違う。EC実務者の場合、ここに1つ固有の事情が乗る。セールの時期に学習時間が消えることである。

手当て	費用の出どころ	時間の確保	EC実務者との相性
独学	自費（教材代のみで済むことが多い）	自分で確保する必要がある	繁忙期に真っ先に消える。中断しても再開できる教材を選べるかが分かれ目
社内の実務に混ぜる	会社の業務時間	業務としてやるので消えにくい	成果がそのまま社内に残る。ただし失敗が業務事故になるため、対象工程の選び方に注意が要る
人に教わる（講座・スクール等）	自費または会社の教育費	日程が先に決まるので確保しやすい	会社の費用や制度で通せるかを先に確認する価値がある。カリキュラムが自分の残った工程に接続するかは個別に見る必要がある

独学は「中断できるか」で選ぶ

EC実務者の学習が止まる原因は、意志ではなく暦である。月末の締めと、セールの準備期間と、その後の出荷の山で、平日の夜は消える。だから独学の教材は、内容の良し悪しより「しばらく空けても再開できるか」で選ぶほうが続く。手を動かす対象も、いま自分が毎日触っているデータにする。売上CSVを結合する、商品別の返品率を出す、といった題材なら、中断しても文脈を忘れない。

社内の実務に混ぜるのがいちばん安いが、対象を選ぶ

費用も時間も会社が持つという意味で、これが最も有利な手当てである。ただし1つだけ条件がある。最初の対象に、事故ったときのコストが非対称な工程を選ばないこと。返品可否や価格の決定を練習台にしてはいけない。前の見出しの表でいえば、「代替済み」と「半分」の列から選ぶ。定例レポートの集計、住所整形の前処理、問い合わせ定型文の下書きあたりが現実的である。失敗しても差し戻せるからだ。

人に教わる場合、選ぶ前に自分で確認しておくこと

独学と社内実務で埋まらない範囲が残ったとき、外部の講座やスクールに頼るという選択肢が出てくる。ここでは特定の事業者を勧めない。受講料も期間も条件によって変わり、当サイトで比較できる実測値を持っていないからである。代わりに、問い合わせや相談に行く前に自分で用意しておくべきことを書く。用意せずに行くと、比較の軸が相手側の説明の順番で決まってしまう。

• 前の見出しで書き出した「足りていない1行」を持っていく。「AIを学びたい」ではなく「ポイント原価込みの実質粗利を自分で出せるようになりたい」と言えるかどうかで、返ってくる説明の粒度が変わる
• 働きながらのペースで、どこまで進むのかを聞く。標準的な期間ではなく、繁忙期にしばらく空けた場合にどうなるかを聞く
• 費用と期間の条件が、自分のケースで当てはまるかを確認する。給付制度や割引の対象になるかは個別の条件で決まる。一般論として説明された条件を、自分に当てはまるものとして持ち帰らない
• 社内の教育費・資格支援の制度を先に確認しておく。自費前提で検討を始めると、会社で通せた可能性に気づかないまま終わる

3つのどれを選んでも、目的は変わらない。判断の材料を、自分で作れる状態を保つことである。残る工程の中身は判断であり、判断は材料がないと下せない。材料を人に出してもらっている限り、その工程も遅れて代替側へ動く。

なお、3つのうち「独学」を選んだ場合にどこで壊れるかは、暦・詰まりの言語化・題材の3つに分かれる。切り分けの手順は独学の限界の断点で別に扱っている。

工数を減らした人が損をしないために：削った時間を評価に翻訳する

最後に、実務上いちばん理不尽な問題を扱う。工程を減らした人が、社内で損をすることがある。作業時間が減ると、外からは「担当業務が減った人」に見えるからだ。自動化を提案した本人が、次の期に人員配置の見直し対象になる、という順番は現実に起こりうる。

これは自動化が悪いのではなく、減らした事実が誰の記録にも残らないことが原因である。前半で「抜けた工程を誰も数えていない」と書いたのと同じ構造が、今度は評価の側で効いてくる。だから記録を残す。残し方は3つでいい。

1. 着手前に、反復回数と所要時間を書いておく

自動化した後では測れない。着手前の状態を、1行でいいから書き留めておく。「この作業は1日◯回、1回◯分」で足りる。厳密である必要はなく、桁が合っていればいい。これがないと、後から「元々そんなに時間かかってなかったよね」という会話になり、反論する材料がなくなる。

2. 削減した時間ではなく、その時間を何に使ったかを書く

「月◯時間削減しました」で止めると、削減した時間の分だけ仕事がなくなったという読まれ方をする。「空いた時間で、商品別の返品率を出して、返品の多い3商品のページを直した」まで書く。減らした話ではなく、増やした話になる。評価の対象が工数削減から成果に移る。

3. 「何を異常と見るか」を言語化して残す

これがいちばん効く。定例レポートの集計は自動化できるが、出てきた数字のどれを異常と見るかは自動化されていない。「CVRが前週比で大きく落ちたら、まず広告の配信面を見る」「返品率が上がった週は、直近で商品ページを触ったかを確認する」といった判断の型を書いて残す。これは引き継ぎ資料でもあり、同時に自分の判断が組織の資産になった証拠でもある。前半で触れた「作った人がもういない」問題への手当てにもなる。

3つとも、やることは同じである。自分が下していた判断を、目に見える形に外へ出す。判断を隠したまま作業だけ減らすと、価値も一緒に見えなくなる。社内で数字を根拠に何かを通す進め方についてはECのデータを社内提案に変える手順にまとめてあるので、記録が溜まってきたら次はそちらを使ってほしい。

よくある質問

自分の工程が代替されるのは、いつですか

時期は予測できない。ただし順番は予測できる。反復回数の多い工程から先に来る。難しい工程からではなく、回数の多い工程からである。自分の工程表で反復回数の上位にあり、かつ判断を含まないものが、次に手を離れる候補になる。時期を決めているのは技術の進歩ではなく、自社がその費用を承認する日である。

いまから学び直して間に合いますか

間に合う・間に合わないという言い方自体が、職業単位の発想である。工程単位で見れば、残っている工程は今日も自分が回している。その工程を続けるために足りない1行を埋める、という具体の作業に落ちるので、期限の問題にはならない。ただし、成果が出るまでの期間や到達点は個人の状況で大きく変わるため、「◯ヶ月で身につく」といった一般化はしない。

AIに任せて事故らないか心配です

事故る場所はある程度決まっている。自動化した部分と人が見る部分の境目である。受注の備考欄、返品の可否、価格の決定、レビューへの公開返信。この記事の表で「残る」「半分」に入った工程がそれにあたる。任せる範囲を決めるときは、精度の高さではなく「間違えたときのコストが対称かどうか」で線を引くほうが安全である。取り返しがつく工程から任せる。

統計の数字が出てこないのは、根拠が弱いということでは

逆である。数字を書かなかったのは、確かめられなかったからである。この記事では、事務従事者の就業者数も、有効求人倍率も、企業のAI利用率も、参照経路によって値が割れたり区分が特定できなかったりしたため、意図的に書いていない。確かめられない数字を根拠にした予測より、自分の手元で数えられる工程のほうが根拠として強い。それがこの記事の主張そのものである。

この記事を読んだあと、最初にやることは何ですか

昨日の自分の一日を工程に割り、反復回数を書き、3条件を当てる。一度腰を据えれば終わる。「残る」と判定された工程の横に、足りていないものを1行書いたところで、この記事の役目は終わる。その後の進め方は、日々の習慣の側から書いた記事と、実際に受注処理をAIに投げてみた記録のどちらかに続く。前者は考え方、後者は手を動かす側である。

あわせて読みたい：EC実務者がAI時代を生き残るために、今日から変えるべき4つの動き