AI業務基盤とは｜チャットと自動処理で共有する情報・手順の設計

社員がAIで回答案を作れるようになった。その使い方を部署へ広げたい。ここで決めるのは、配るアカウントの数に加えて、AIに何を読ませ、どの手順で動かし、誰が結果を確かめるかです。

この記事では、会社で共有する情報・手順と、それを動かして保守する仕組みを「AI業務基盤」と呼びます。社員がチャットから依頼するときも、時間や出来事をきっかけに自動処理するときも、会社が決めた情報と手順を使う設計です。

まず、問い合わせ対応を例に、共通にするものと人が判断する場所を整理します。例は構成を説明するための仮例であり、導入実績ではありません。

個人のAI活用を部署へ広げるとき、何が変わるか

ある担当者が、過去の問い合わせと回答を自分のAIアプリに読み込ませ、回答案を作っているとします。本人は資料の古さや顧客との経緯を知っているため、出力を見て直せます。

同じ使い方を部署全体へ広げると、別の担当者はどの資料が正式版か分かりません。回答してよい範囲や、送る前に確認する人も、そのままでは共有されません。

そこで、次の4点を会社の決めごととしてそろえます。

• 参照する正式な資料と、その更新担当

• 回答してよい条件と、人に確認を求める条件

• 回答案を承認する人と、不在時の引き継ぎ先

• 誰が何を参照し、どう対応したかを残す記録

個人で使う場合にも、権限や情報の管理は必要です。部署で運用する場合は、それを本人の記憶や注意に委ねず、担当者が替わっても同じ手順で進められるようにします。

自社のAI活用がどの段階にあるかを確認したい場合は、AI活用を組織に定着させる方法で、現在地を確かめる考え方を扱っています。

チャットと自動処理で、共通の情報と手順を使う

会社共通の情報と手順は、社員のチャット利用にも、自動処理にも使います。入口によって参照する資料や承認の条件が変わると、同じ問い合わせでも扱いがばらばらになるためです。

チャットから依頼する場合

社員が「この問い合わせの回答案を作って」と依頼したら、会社が定めた資料と対応履歴を参照する手順を呼び出します。AIは問い合わせの要望を整理し、回答案と参照元を担当者に返します。

担当者は根拠を確かめ、必要なら直します。送信は人の承認後に進め、承認した人と対応結果を記録します。

フォーム送信をきっかけに始める場合

同じ問い合わせがフォームから届いた場合は、受付をきっかけに処理を始めます。顧客情報を確認し、同じ正式資料と回答の基準を使って回答案を作ります。

ここでも、送信前の承認と対応記録を省きません。人がチャットで依頼した場合と、フォームから自動で始まった場合で、承認条件を別々に作らない設計にします。

共通にするのは、回答の文面ではなく判断の前提

同じ資料を渡しても、AIが毎回同じ文章を返すとは限りません。そろえる対象は、正式な情報、回答してよい条件、承認の手順、記録の残し方です。

たとえば契約条件について答えるなら、どの版の資料を使ったか、対象顧客に適用される条件か、誰が回答を確認したかをたどれるようにします。AIの出力が正しいかは、共有の仕組みを用意したあとも確かめます。

共有する場所と、見てよい範囲を分けて考える

資料を共有フォルダに集めるだけでは、業務で使える情報はそろいません。正式版を誰が更新するか、古い版を参照させない方法、顧客ごとに異なる条件をどう扱うかも決めます。

問い合わせ対応であれば、製品の説明資料と、個別顧客の契約・対応履歴では、見てよい人が異なります。チャットから依頼した人が参照できる範囲と、その業務の処理に必要な範囲を確認し、手順ごとに権限を設定します。

回答には、参照した資料やデータの時点を添えます。「正式な資料を使ったか」と「その顧客に見せてよい情報か」は、別々の確認項目です。

データの更新も、共有するだけで終わらせません。担当者の変更が記録されていなければ、確認依頼が前任者へ届きます。対応履歴が欠けていれば、すでに回答した問い合わせを未対応として扱ってしまいます。

情報を更新する人と、処理結果を記録する場所まで決めます。

業務を始める起点と、その後の管理を決める

業務の入口は、人の依頼、時間、出来事に分けて整理できます。問い合わせ対応なら、次のように使い分けます。

• 人の依頼：判断が必要な問い合わせについて、担当者が回答案の作成を依頼する

• 時間：毎朝、回答案が未作成の問い合わせを抽出し、回答案の準備を始める

• 出来事：フォームの送信を受けて、受付と回答案の準備を始める

始まり方が違っても、顧客の確認、回答案の準備、承認、記録という手順を共有します。どの入口から始まったかは記録に残し、同じ問い合わせを二重に処理していないかを確かめます。

接続することと、業務を管理することを分ける

MCPは、AIアプリと外部の情報・ツールの間で、情報を受け渡すための共通の決まりです。MCPの公式資料では、受け渡された情報をAIアプリがどう使うかは、規格の範囲に含めないと説明しています。MCPの構成説明

接続を用意したあとも、どの条件で処理を始め、誰が承認し、どこへ記録するかは業務ごとに決めます。MCPを使うかどうかだけで、業務全体の運用は決まりません。

複数のアプリをつなぐiPaaSを使う場合も、設定は必要です。たとえばMakeには、エラーで止まった処理のデータと設定を保存し、再開に使う機能があります。この保存機能は既定で無効です。

保存して再開する運用にするなら、設定と確認手順を用意します。Makeの未完了実行の説明

既存アプリの標準機能で足りる業務もあります。iPaaSや独自のプログラムを使うかは、承認、記録、失敗時の再開など、必要な条件を満たせるかで選びます。詳しい役割分担は、iPaaSとはとAIエージェントとRevOpsの実装方法を参照してください。

止まったときに、誰が何を確かめるか

失敗した処理を再実行する前に、どこまで終わったかを確認します。回答は送信済みなのに記録だけ失敗していた場合、最初からやり直すと二重送信になるためです。

保守の担当者が原因と実行履歴を確認し、業務の担当者が顧客への対応状況を確かめます。そのうえで、どこから再開するかを決めます。費用についても、処理件数や利用量を確認する担当者と、上限に近づいた場合の止め方を決めておきます。

最初の1業務で、5つの項目を決める

最初から全部門の業務をそろえる必要はありません。対象を1つ選び、実際の担当者と保守する人が、次の項目を決めます。

1. AIに任せる作業と、人が決める作業

問い合わせ文の整理と回答案の作成をAIに任せ、根拠の確認と送信の判断を人が担う、といった分け方です。「問い合わせ対応を自動化する」という単位から、誰が何をするかまで具体化します。

2. 共通にする情報と手順

正式資料の置き場所、更新担当、回答の基準、承認する人、対応記録の保存先を決めます。別の担当者が引き継いでも、参照先と確認先を探し直さずに進められるかを確かめます。

3. 自動で進める範囲と、保留する条件

必要な情報が欠けている、適用する契約条件を決められない、といった場合は人へ回します。保留された案件を誰が受け取り、対応が終わるまでどこで管理するかも決めます。

4. 動かし方と、止まった後の引き継ぎ

人の依頼・時間・出来事のどれで始めるかを決め、実行する仕組みを選びます。失敗の通知先と、保守担当が不在の場合の代わりの人を定め、再開の手順を残します。

5. 何を確かめてから、次の業務へ広げるか

処理がエラーなく終わったかに加えて、対象の問い合わせを取りこぼしていないか、回答の根拠が適切か、承認や記録が残ったかを確認します。修正や例外対応にかかった人の作業も見て、手順を見直してから広げます。

図解と確認項目を、社内で共有する

AI業務基盤を整えるときは、使う情報と手順を決め、チャットからの依頼にも自動処理にも適用します。対象の1業務について、参照する資料、承認する人、対応記録の保存先を書き出すところから始めてください。

資料「AIベースの業務基盤構築に向けて」では、共通の情報・手順、業務を始める起点、実行と保守の分担を図解しています。担当者と話し合う際の確認資料として使えます。

AIベースの業務基盤構築に向けて：資料を見る

参照元

• 株式会社Mer「AIベースの業務基盤構築に向けて」（2026年11月）。会社共通の情報・手順と、最初に決める5項目は同資料に基づきます。

• MCP公式：Architecture overview（2026年11月12日確認）

• Make公式：Incomplete executions（2026年11月12日確認）