最近は、何でもAIにやらせる流れがあります。
- メール返信
- 問い合わせ対応
- 営業支援
- 議事録作成
- 調査
- レポート作成
- etc…
少し大げさに言えば、あらゆる業務が「AIで自動化できる」と語られる時代です。
しかし、この言い方には少し雑なところがあります。
実際には、多くの「AI自動化」は、AIが最初から最後まで仕事をしているわけではありません。現場で起きていることを冷静に分解すると、ほとんどのケースは通常のプログラムによる自動化の一部に、AIを部品として差し込んでいるだけです。
この点を曖昧にしたまま「AIが全部やる時代だ」と語ると、議論がずれます。設計もぶれますし、過剰な期待や誤解も生まれます。そして何よりAIのコストが爆増します。
本当に整理すべきなのは、もっと単純なことです。
どの部分は通常のプログラムで実装できて、どの部分だけAIが必要なのか。
この記事では、その切り分けをしてみます。
AI自動化の実態は「AI + プログラム自動化」である
「AI自動化」と聞くと、AIが状況を理解し、考え、必要な処理を選び、最後まで自律的に実行しているようなイメージを持つかもしれません。
もちろん、そうした構成もあります。ただし、実務で多いのはそこまで強い自律性を持った仕組みではありません。
多くの業務システムは、次のような流れで動いています。
- 何かを検知する
- 必要なデータを取得する
- 条件分岐する
- 必要ならAIに判断や生成を依頼する
- 結果を保存する
- メール送信や登録処理などのアクションを実行する
- 失敗時は再試行し、ログを残す
このうち、AIが本当に必要なのはどこでしょうか。
答えは、たいてい人間の言葉や曖昧な状況を解釈する部分です。
それ以外の多くは、従来どおりのプログラムで処理できます。むしろ、そこはプログラムで固定したほうが安定します。
つまり、AI自動化の中心は「AIが全部やること」ではなく、決定的な処理はプログラムで固め、非決定的な処理だけをAIに委ねることにあります。
メール返信を分解すると、AIが必要なのは一部だけ
例として、メール返信の自動化を考えてみます。
一見すると、これは「AIで自動返信する仕組み」に見えます。けれども、処理を分解するとAIが担う部分は意外と限られています。
まず、プログラムで実装できる部分があります。
- 新着メールを検知する
- 差出人、件名、本文、添付ファイルを取得する
- 返信対象かどうかを判定する
- 顧客情報や注文情報など、必要な社内データを取得する
- AIに渡すための入力を整形する
- AIが生成した文面を下書きに入れる
- 承認フローに回す、または送信する
- ログを残す
- 失敗時に再試行する
これらは、基本的に通常のプログラムで対応できます。トリガー設定、API連携、条件分岐、DB参照、送信処理、監査ログ。どれも昔からあるシステム開発の世界です。
では、AIが必要な部分は何か。
- 相手が何を求めているのかを読む
- 長い本文から要点を抽出する
- 問い合わせの種類を判断する
- 適切なトーンで返信文を作る
- 曖昧な依頼に対して自然な文面を返す
こちらは、ルールベースだけでは扱いにくい領域です。自然言語の解釈や生成が必要になるため、AIの価値が出ます。
この分解を見ると、「メール返信の自動化」は正確にはメール返信ワークフローの一部にAIを使っているのであって、全体がAIでできているわけではありません。
多くのAI活用は「AI補助の自動化」である
この見方を広げると、今「AI自動化」と呼ばれているものの多くは、次の三つに分類できます。
1. AI不要の自動化
手順が明確で、入力に対して何をすべきかが決まっているものです。
たとえば、次のような処理です。
- 特定条件で通知を送る
- フォーム送信を受けてデータベースに登録する
- 定型メールを送る
- ファイルを所定の場所に保存する
- 承認依頼を回す
- 日次で集計してレポートを配信する
これらは従来型の自動化で十分です。AIを使ってもよいですが、必須ではありません。
2. AI補助の自動化
全体の流れはプログラムで制御しつつ、一部だけAIを使うものです。
たとえば、次のようなものです。
- メールの返信案を生成する
- 問い合わせ内容を分類する
- 議事録を要約する
- 自由記述を構造化する
- 文書から必要項目を抽出する
- FAQ候補を作る
これは現在もっとも広く使われている形です。言い換えれば、世の中で「AIで自動化」と呼ばれているものの中心はここにあります。
3. 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にやらせる」発想ではありません。
必要なのは、どこまでを決定的な処理として固定し、どこからをAIに委ねるかを見極めることです。
AI自動化の本質は、AIの万能感ではなく、責務の切り分けにあります。
言い換えれば、AI時代の自動化とは、
AIで全部やることではなく、AIが必要なところだけを正しくAIにやらせることなのです。