――生成AIが普及した未来、仕事は本当に楽になるのか？面倒な仕事を奪ってくれるのか？
※ この記事は元々note用に書いたのですが、どちらかといえば夢を壊して現実を見よう系の話なので、AIを使いこなしている人が多いCDLE向けかな？と思い、こちらに移動しました。私の考えを詰め込んだような内容ですので、ご意見などいただければと思います。あくまでも「会社の日常業務の効率化」がテーマなので、エンターテイメント関係やパッケージ開発のような終わりが見えるものだと違った内容になるかとは思います。
効率化＝楽になる、ではないのでは？
AIが普及した未来は「つまらない面倒な仕事はAIが全てやってくれて、楽しい仕事だけが残る」というイメージを持っている人は多いと思います。
ですが…果たしてそうでしょうか？
経営者でなく、社員として働いている場合、基本的には「成果」ではなく「時間」で働いています。月給も、勤務時間も、会議の予定も、基本は時間を単位に回っています。
すると、たとえ作業が効率化されても、働く時間が減るとは限りません。むしろ、同じ時間の中でより仕事の濃度が上がり、しんどくなる可能性も考えられます。
効率化は、会社にとっては正しいと思います。少子化で人が減るなら、なおさら正しいでしょう。でも、個人の働く大変さとは別問題に感じます。
「つまらない仕事」は本当に、つまらないのか？
仕事の中には、入力、整形、転記、体裁を整える、といった「単純作業」があります。普通に考えると「AIに任せたい」「なくしたい」と考えられる作業です。
しかし、ここには人にとっての“楽しさ”も混じっているのでは？とも考えられます。
例えばプラモデルやパズルは、完成形が分かっているのに作るのが楽しい。工程があり、少しずつ形になり、手を動かせば進む。失敗してもやり直せる。「できた！」という感触が残る。
仕事にも似た部分があります。
資料を整える、報告をまとめる、情報を集めて形にする。成果が同じでも、工程には工程の気持ちよさがあるのです。
これらの工程は、特殊な能力は必要とせず、誰がやっても…多少結果がブレても…大して問題にならない仕事になります。つまり…曖昧で、責任が薄く、正解が一つに定まらない作業は…言い方は難しいですが、「ダラダラできる余地」があり、その緩さが安心と充実感を与え、仕事が楽しいと感じさせる気がします。
それがないと、おそらく息がつまるような働き方になりそうです。
AIが奪うのは「面倒」より「工程」
AIが得意なのは、曖昧な情報を集めて形にすることです。要約、下書き、候補出し、文章の整形、表の作成。
つまり「結果に至る工程」を圧縮します。
この性質は強力です。
ただし、圧縮されるのが“人が手を動かして進める工程”であるとき、仕事の感触は変わります。
残りやすいのは、次のような部分です。
・最終判断
・例外対応
・説明責任
・調整と衝突の引き取り
これは、楽しいというより精神的に重い作業です。
そしてここで「時間で働く」構造がジャブのように効いてきます。
工程が減っても勤務時間は減らない…と、すると空いた時間は「余白」ではなく「追加の判断」で埋まります。仕事は楽になるのではなく、圧縮されて濃度が上がるのです。
会社にとっては、効率化され処理量が増え、生産性が上がる。非常に良いことです。
少ない人数で回る。少子化には合っています。
でも個人にとっては…同じ8時間がよりしんどくなる、という結果にならないでしょうか？
業務システムをAIが置き換えるという誤解
企業で働く人の中には、生成AIを 「簡単な指示だけで、整合性の取れた“正しい答え”を出しつつ自動処理してくれるコンピュータ」 として捉えてしまうことがあります。
画面で指示すれば、決められたルールに従って処理が進み、最後には正しい結果を残してくれる――そんな業務システムの延長のようなイメージです。
そうなると「今、人が行ってる仕事をAIが代わりにやってくれる」というイメージが具体的に浮かんできません。むしろこう考えがちです。
・面倒な画面操作がなくなる
・手続きが自動で流れる
・例外も含めて整合性が保たれる
・結果は“正しい答え”として返ってくる
つまり、日常的に業務システム上で行っている一連の業務フローを、AIが“丸ごと代行”してくれるのではないか、という期待です。
でも、業務システムの価値は“操作画面”ではありません。価値は「確定」と「整合性」と「追跡可能性」です。
・金額を確定する
・在庫を更新する
・契約状態を進める
・対外的に正式送信する
会社の意思決定として“確定”が入る仕事で、後から説明責任が発生します。ここを曖昧にすると、短期的には楽でも、長期的には必ず事故が発生します。事故が起こった瞬間、責任は人に戻ってきます。
AIはハルシネーションに代表されるように、常に正解だと確信できるアウトプットを返すわけではありません。思い違いや取り違えが起きる点では、人間と同じように間違うこともあります。
そう考えると、業務システムが絡む業務フローを安易にすべてAIに任せることは、非常に危険だと言えるのです。
AIに任せてよいかの線引きはどこか？
AIに任せてよいかの線引きはどこか？
私は、その仕事が 「会社の記録や取引の結果を確定させるかどうか」 だと考えています。
確定しない仕事：
情報収集、整理、要約、下書き、候補出し、リスク洗い出し
→ AIが強い。やり直せる。人が最後に決めればいい。
確定する仕事：
請求確定、会計計上、在庫更新、契約確定、対外送信
→ ここは簡単に任せてはいけない。監査・責任・再現性が要る。
AIは提案者にはなれても、確定処理の責任者にはなりにくいのです。この線を引けるかどうかで、AI活用は成功と失敗が分かれると思います。
効率化の解決の鍵は「AI×プログラミング」
ここまで見てきたように、請求の確定や在庫の更新、契約の成立といった「結果を確定させる仕事」は、正しさと説明責任が前提になるため、AIにそのまま任せることはできません。
しかし同時に、こうした仕事の多くは、
・手順が決まっている
・ルールが明文化されている
・例外パターンもある程度は整理できる
という性質を持っています。
つまり、「責任が重いから最終的に人が判断している」だけで、そこに至るまでの過程は、かなりの部分が手順化できます。ここで効いてくるのが、従来からのプログラミングです。
プログラムは、決められた手続きを正確に繰り返し、整合性を保ち、ログを残し、後から検証できる形で処理を進めることができます。
・確定処理はプログラミングで堅牢に作り込む
・人は最終判断と責任を引き受ける
という分業は、これまでずっと現実的な解でした。
そしてここに、AIを組み合わせる余地が生まれます。AIが得意なのは、
・情報の整理
・入力データの前処理
・例外の候補提示
・判断材料の収集や要約
といった、確定の「前段階」です。ここをAIに任せることで、人が見るべき情報を減らし、判断に集中できる形を作ることができます。
重要なのは、AIに確定処理まで丸投げするのではなく、プログラミングで作った業務の骨格の中に、AIを部品として組み込むという設計です。
AIだけを導入しても、この設計がなければ仕事は効率化されません。むしろ間違う可能性のあるAIの出力に対し、必要な判断の範囲が広がり、それが全て人に押し付けられ、仕事の時間も密度も両方が上がっていく可能性すらあります。
だからこそ、これからの業務効率化の中心に来るのは、AIそのものではなく、AIとプログラミングを組み合わせて業務を再設計できる人間だと、私は考えています。
まとめ ： 効率化の「先」で起きること
AIで効率化が進むと、まず手を動かして整えるような作業や、途中で人が調整していた曖昧な工程が短縮されていきます。
ところが、請求の確定や在庫の更新のように「結果を確定させる処理」をAIに任せ切ろうとすると、誤りがそのまま処理に入り込み、後で取り返しがつかない形になりやすいです。
ここで大事なのは、AIは万能ではない、という前提を理解し共有することです。生成AIは曖昧な情報の整理や案出しに強い一方で、正しさ・再現性・追跡可能性が前提になる処理を、そのまま保証してくれるわけではありません。だからこそ、従来のITやプログラム技術が必要になるのです。確定処理や整合性の担保といった領域は、AIでは代替出来ないのです。
その上で、AIとプログラミングを組み合わせたときに、効率化は最も伸びます。
AIは前段（情報の整理、下準備、候補の提示）を加速し、プログラムは後段（確定処理、整合性、記録）を効率化します。この役割分担を明確にしたとき、無駄な作業と無駄な待ち時間の両方を減らす事が可能となります。
そして、その役割分担は自然に決まるものではありません。業務をAIとプログラミングの役割や範囲に適切に切り分け、設計し、実装まで落とし込める人材が必要です。ツールの導入だけで成果が出るのではなく、業務全体を作り直す人材が必要なのです。
ただし、ここまでやって効率を最大化しても…残るのは重たい仕事です。判断と責任は消えません。今のような時間で働く前提が変わらないまま効率化だけを進めれば、短縮された分は別の判断や対応で埋まり、仕事は減るというより密度が上がっていきます。
こうした「密度が上がった仕事」の負荷は、過去の働き方の感覚のままだと理解されにくい面があります。世代間の感覚差がその負荷を見えにくくする可能性も考えられます。
AIが業務を効率化した未来では「時間」＝「お金」の価値観では成り立たなくなると言えます。その時必要なのは、新たなる評価軸であり、たくさんの時間働いてるから「頑張っている」という認識を改めなくてはならないと思うのです。