AI業務自動化を事業部主導で進めるための分業設計｜個人で動かせる「点」、開発が要る「線」

「商談の評価も、問い合わせの一次対応も、レポート作成も、AIで自動化したい。」 事業部でAI活用を任された推進担当者の方から、こうした相談をよく聞くようになりました。

特徴的なのは、やりたいことのイメージがかなり明確に描けている、という点です。
たとえば「問い合わせフォームに届いた内容が自動で記録され、過去のFAQや対応履歴に照らしてAIが一次回答の案を作り、担当者に通知が飛ぶ」のように、こうした一連の流れを、ゴールとして鮮明に思い描けている方はいらっしゃいます。

ところが、いざ自社で実現しようとすると、最後まで止まることなく進むことはできないことが多いです。
「事例記事はいくらでも見つかるのに、自社で具体的にどのツールを使い、どこにAIを組み込めばいいのか、実現の道筋が見えてこない」。
多くの推進担当者が抱えているのは、この「やりたいことは見えているのに、実際の実現するための道筋が見えない」というモヤモヤではないでしょうか。

本記事では、この詰まりの正体を、業務フローを「点」と「線」という2つの見方に分けて解きほぐします。
そのうえで、事業部がどこまで自分たちで進められて、どこから開発の手を借りればよいのか——限られた人数でも描ける「分業の設計図」を、自分の手で引けるようになることを目標に、問い合わせ一次対応の自動化を例に解説していきます。

なぜ「事例はあるのに、自社では手が止まる」のか

既存の自動化事例記事は、その多くが「こんな自動化ができました」という完成形を見せてくれます。
きれいに動いている画面、削減できた工数、喜ぶ現場——どれも魅力的です。

しかし、そこで語られているのは、すでに自動化という一本の道が引き終わった後の景色です。
どの作業が個人レベルのAI活用で片づき、どの作業に開発の手が要るのか。その境目はどこにあって、事業部はどこまで自走でき、どこから・どう開発に頼めばよいのか。多くの事例記事は、この「分業の設計」がありません。

「どこを自分たちでやり、どこを開発に頼むか」という分業の設計がないまま走り出すと、事業部だけで抱え込んで動けなくなるか、逆に何でも開発に投げて足りない開発リソースを奪い合うか、どちらかに振れてしまいます。

業務を「点」と「線」を分けて捉える

AIの実装や自動化を支援する立場から現場を見ていると、つまずく企業の多くに共通する構図が浮かび上がってきます。
それは、業務フロー全体を「ひとかたまり」として捉え、全部を一気に自動化しようとして行き詰まる、というものです。

一本の流れに見える業務も、よく見ると性質の違う作業が混ざっています。
個人のAI活用ですぐにこなせる作業と、開発の手を借りないと再現できない作業が、同じ流れの中に同居しています。 それを区別せずまとめて自動化しようとすと、事業部だけでは対応できない作業が急に必要になって、手が止まってしまいます。

そこで、業務フローをいったん「点」と「線」という2つの見方に分けて捉え直してみます。

点とは、業務フローを工程に分解したときの、個々のタスクのことです。
たとえば「届いた問い合わせの内容を、FAQや過去の対応履歴に照らして、回答の案と緊急度を判定する」という部分。
ChatGPTやClaudeを業務で触ったことのある方なら、「資料を渡して、こういう観点で整理して」と頼んだ経験があるはずです。

実はこうした個々の判断は、対象となるファイルを渡してAIに指示すれば、個人レベルでも十分にこなせてしまいます。
点の正体は、まさにあの作業の延長線上にあります。

最近では、こうした個々の作業をより安定して任せるために、AIエージェント（※1）やSkills（※2）と呼ばれる仕組みも使われ始めています。
ただ、ここではまず「手元のAIに資料を渡して判断させる」イメージを持っていただければ十分です。

※1 AIエージェント：指示を受けて、複数の手順を自分で順に実行していくAIを指します。 ※2 Skills：特定の作業手順や知識をAIにあらかじめ持たせ、必要なときに呼び出せるようにした「得意技」のような機能です。

難易度が跳ね上がるのは、その前後です。
線とは、点と点を、複数のシステムをまたいで、再現性のある一本の流れとしてつなぐことを指します。 「問い合わせが届いたら自動で記録する」「判定が終わったら自動で担当者に通知する」——人が間に入って手で渡すのではなく、毎回同じように、人手を介さずに流れることが求められます。
この瞬間に、急に開発の手が必要になります。

なぜ線になると難しいのでしょうか。
複数のシステムをまたいで処理を流すには、それぞれのシステムをつなぐ土台が要るからです。

つなぎ方の一つに、AI自身に複数のシステムをまたがせる、という方向があります。 近年広がっているMCP（Model Context Protocol）が、その代表です。
MCPは「AIアプリケーションを外部システムに接続するためのオープンソースの標準規格」と説明されていて、ClaudeやChatGPTといったAIを、データやツールにつなぐ共通の差込口のような役割を果たします（出典: What is the Model Context Protocol (MCP)? — 公式）。
これを使えば、AIが自分で複数のシステムをまたいで処理する、ということもできるようになってきました。

関連記事：MCPとは何か？｜AIと業務システムをつなぐ接続規格を、どの業務から試すか

ただ、これを社内の業務として部署内で展開し、毎日安定して回そうとすると、話は変わってきます。
AIが自分で判断して動く自律性の高いやり方は、柔軟である反面、毎回まったく同じ手順・同じ結果を返すとは限りません。
決まった業務を安定して再現したい用途では、動作が読みにくく不安定になりやすい、という難しさに直面します。

そこで、決まった一本を毎回同じように流すには、ClaudeやChatGPT単体ではなく、ワークフロー自動化ツールと呼ばれるものが必要になります。
代表例のn8nは、複数のアプリやサービスを部品のようにつなぎ、一本の処理の流れを視覚的に組み立てられるツールで、500を超えるサービスとの連携に対応しています（出典: n8n — AI Workflow Automation Platform（公式））。

システム同士の受け渡しには、API連携やWebhookと呼ばれる仕組みも登場します。Webhookは、あるシステムで起きた出来事（問い合わせが届いた、など）を、別のシステムに自動で知らせる仕組みだと考えてください（出典: Webhookとは？仕組みやメリット、APIとの違い — blastengine）。

問題は、こうした土台が「つなげばすぐ安定して動く」ものではない、という点にあります。
複数ツールの連携は、情報が反映されない、通知が届かない、データが重複したり欠けたりする、といったトラブルと隣り合わせで、設計と運用の経験が必要になります（出典: Webhookとは〜ツール連携を止めない設計・運用の要点〜 — バディマーケティング）。

しかも、こうしたツールでワークフローを組み上げるには、ある程度のコーディングの力や、開発に関する知見も欠かせません。
個人でAIに指示を出すのとは、必要な技術の質がまるで違います。

つまり、再現性のある一本の線を引くとなると、最終的には開発側の助けが必要になってきます。事業部側だけで、この線のベースを一から設計するのは、率直に言って難しいと言わざるを得ません。

問い合わせの一次対応を例に工程を分解して、点と線を見極める

冒頭でも触れた「問い合わせの一次対応を自動化したい」という題材を取り上げます。

思い描くゴールは、おおむね次のような流れです。
問い合わせフォームに内容が届く、その内容が自動で記録される、FAQや製品資料・過去の対応履歴に照らしてAIが回答の案と緊急度を判定する、案を所定のフォーマットに整えて格納する、担当者に通知が飛び、緊急なら即エスカレーションされる——。

この流れを工程に分け、一つずつ「点なのか、線なのか」のラベルを貼っていきます。
工程の区切り方に厳密な決まりはありませんが、扱うツールやシステムが切り替わるところ、担当する人や役割が変わるところ、そして「ここでひとつの判断や処理が完結する」と感じるところで線を引くと、ちょうどよい粒度になります。
最初は粗くても構いません。あとから細かく割っていけます。

最初の工程、フォームに届いた内容を自動で記録する部分は、線にあたります。
フォームと記録先という別々のシステムをまたいで、データを自動で受け渡すからです。
ただし、フォームの内容を表計算ソフトに書き写すような一方向のシンプルな連携は、線の中でも比較的やさしい部類に入ります。

次の工程、記録された内容をFAQや資料・履歴に照らして、AIが回答案と緊急度を判定する部分。ここは点です。
参照してほしい資料を渡して「この問い合わせに、これらの資料をもとに回答案を作ってほしい。緊急度も3段階で添えてほしい」と頼めば、個人のAI活用でも十分にこなせます。

念のため補足すると、「記録を取る」工程自体が必ず線になるとは限りません。
たとえば会議の場面では、Google Meetが録画と文字起こしを自動で主催者のドライブに保存できますし、自動メモ生成も用意されています（出典: Google Meet で文字起こしを使用する — Google Meet ヘルプ（公式））。
つまり「記録を残す」こと自体は標準機能で点に近いところまで来ています。線になるのは、その記録を「決まった場所に、毎回自動で格納し、次の工程へ渡す」とつなげようとしたときです。

回答案を所定のフォーマットに整えて格納する工程も、毎回自動でとなると連携が要る線になります。

最後の、担当者への通知と緊急時のエスカレーションは、複数のシステムを人手なしでまたぐので、線です。

ここまでを一覧にすると、点と線の振り分けと、それぞれを主に誰が担うのかが見えてきます。

こうして並べてみると、点と線を見極める基準が浮かび上がります。
「人がファイルを渡して一度指示すれば終わるのか（点）」、それとも「複数のシステムをまたいで、きっかけから処理、次への受け渡しまでを、人手を介さず毎回再現する必要があるのか（線）」。
境目は、再現性をもってシステムをまたぐ瞬間に現れる、と整理できます。
AIに賢く判断させること自体が難しいのではなく、その判断を毎回同じように呼び出し、前後とつなぐことが難しいのです。

ここで一つ、押さえておきたいことがあります。
毎回自動で動く線であっても、その途中でAIに判断させる部分、つまり点が消えてなくなるわけではない、という点です。
多くの場合、自動化したい業務はほとんどが「毎回自動」なので、「では結局ほとんどが線で、開発頼みになるのでは」と感じるかもしれません。
けれども、線をつなぐ土台は開発に任せても、AIに何をどう判断させるか（点）は、業務をいちばん知る事業部が握り続けます。

線と点は対立するものではなく、線という流れの中に点が埋め込まれている、という入れ子の関係だと捉えていただくと、線引きがぶれません。

「線」を開発チームに依頼する際の準備

線と一口に言っても、その全部が開発の領域というわけではありません。
線をさらに分けて見ると、事業部主導で進められる部分と、開発の手を借りるべき部分が分かれてきます。
ここが、本記事でいちばんお伝えしたい分業点の見極めにあたります。

事業部主導で進められるのは、線を引くための「準備」と「検証」です。
具体的には、一連の業務を工程に分解すること、各工程の点の部分を個人のAI活用で先に試して回答ロジックを固めること（たとえば過去の問い合わせをいくつか手元のAIに渡し、出てきた回答案や緊急度を、人が実際に出した判断と突き合わせて、業務で使える精度かどうかを確かめます）、

そして「どのシステムとどのシステムをつなぎたいのか」「それぞれで何をきっかけに、何を受け取り、何を渡したいのか」を言葉にすること。

ここまでは、技術というより業務の理解そのものなので、現場をいちばんよく知る事業部にこそ向いています。

開発側に「ベースを組んでほしい」と具体的に依頼できる状態にする

では、何が揃っていれば、開発は線をもとにベースを組み始められるのでしょうか。
依頼の前に、次のチェックリストで自分たちの準備度合いを確かめてみてください。

□ 自動化したい業務フローを、工程に分解して書き出している
□ 各工程に「点」「線」のラベルを貼っている
□ 点の部分（AIの判断ロジック）を、個人のAI活用で先に試し、動くことを確かめている
□ つなぎたいシステムを具体的に挙げている（フォーム・記録先・通知先など）
□ 各システムについて「何をきっかけに、何を受け取り、何を次へ渡すか」を書いている
□ まず動かす最小の一本（最初に通すフロー）を決めている

これらが埋まっていれば、開発に頼む範囲は「線を引くベースの設計」にぐっと絞り込めます。

点の部分は事業部側ですでに検証済みなので、開発はそのロジックを呼び出してシステム同士をつなぐ仕事に集中できます。

何をきっかけに動き、どこへ何を渡すのかが書き出されていれば、設計の手戻りも減ります。
そして、最初から全工程をいっぺんに自動化しようとせず、まず一本だけ通すと決めておくことが、限られた開発リソースで着手する現実的な進め方になります。

ベースが組み上がったら、そこからは事業部の出番です。
回答の精度を見て判定の指示を調整し、緊急度の線引きを現場の感覚に合わせていく。この検証と改善のサイクルは、業務を知る事業部だからこそ回せます。
開発に渡しっぱなしにせず、ベースを土台に自分たちで育てていく——この往復が回り始めて初めて、「使える仕組み」になっていきます。

まとめ

個々のタスク（点）は個人のAI活用でこなせても、再現性をもって複数のシステムをつなぐ自動化（線）は別物です。
だから、業務フローを点と線に分けて捉え、そのうえで開発との分業点を見極めることが、自動化をスムーズに前に進める鍵になります。

つまずく多くの企業は、この区別をしないまま全部を一気に自動化しようとして行き詰まります。
けれども、業務フローを工程に分解して一つずつ点と線のラベルを貼れば、どこが個人のAI活用で自走でき、どこから開発の手が要るのかが見えてきます。

さらに線の中を分ければ、工程分解・点の検証・つなぎたいシステムの言語化は事業部主導で進められ、ベースの設計やシステム同士の接続は開発に任せる、という分担が描けます。

頭の中にあった自動化のイメージが、誰が何をやるかの分業設計へと姿を変えると、開発との会話がスムーズになっているのではないでしょうか。