AIエージェントの管理は誰の仕事？現場・情シス・DX推進の役割分担

株式会社AIworker

2026年9月28日 11:05

AIの回答が間違っていた。作成者は「参照する規程が古い」と言い、規程の担当者は「AIの仕組みは分からない」と言う。情シスへ依頼しても、どの回答を正解にすべきかまでは決められません。

AIエージェントの管理は、業務の判断、技術保守、知識源の更新、基盤管理を分担して行います。 とくにAIでは、アプリを変更しなくても、参照資料やモデルの変化で確認が必要になります。

本記事は、AIを部門で使い始めた企業の責任者向けです。「誰の担当か」で止まりやすい変更・誤回答・再開判断を、具体的な運用場面に沿って整理します。

この記事の要点

✅ システム上の所有者と、業務で使う判断者を分けて記録します。
✅ 誤回答の受付、原因の切り分け、停止、再開を誰が担うか決めます。
✅ 指示・知識源・モデル・権限の変更を、担当者と再評価へつなげます。

「作った人が全部管理する」では、決められないことが残る

作成者は指示文を修正できても、経理規程の解釈や、営業が顧客へ約束してよい条件までは決められません。反対に、業務責任者が正解を知っていても、認証や接続障害の修復は別の技能です。

何を正しいとするかと、どう直すかを分担する必要があります。担当を分ける目的は、責任を薄めることではなく、判断できる人へ問題を届けることです。

Microsoftの運用ガイダンスも、業務側とIT側などの合意を含む体制づくりから、テスト、展開、監視へ進む考え方を示しています。Microsoft：運用・統制の全体指針

以下の役割分担はAIworker独自の設計例です。組織の規程と既存の障害対応を優先し、名称や兼務の仕方を調整してください。

4つの責任を、担当名まで書き分ける

業務責任者：使ってよい範囲と正解を決める。 対象業務、受け入れ条件、例外、人の確認、業務上の再開判断を担います。

技術保守担当：動作を調べ、変更を実装する。 指示、処理、接続、テストの実行と記録を担います。作成者が兼ねる場合も、対応時間を業務として確保します。

知識源の管理担当：参照する内容の正しさと版を管理する。 規程や製品資料の更新、古い文書の扱い、矛盾の解消を担います。AIの作成者が文書の正しさまで引き受ける設計にしません。

基盤管理担当：環境、認証、権限、組織ポリシーを管理する。 情シスなどが担います。業務の正解を代わりに決めるのではなく、許可された条件で動かす役割です。

DX推進は、この4つの責任を部門横断で接続する役割を持てます。共通の様式、優先順位、教育、未解決事項の調整を担い、個々の業務判断をすべて中央へ集めない形にします。

4つの役割に4人の専任者が必要という意味ではありません。 兼務する場合も、どの立場で何を決めたかを記録します。

誤回答が報告された日の流れを、先に決める

架空例として、社内の規程案内AIが古い申請条件を回答した場面を考えます。

受付：利用者が迷わない窓口を1つ置く

まず運用窓口が、発生日時、質問の種類、表示された根拠、影響した業務を受け付けます。利用者自身に「技術の問題か、規程の問題か」を判定させないようにします。

初動：影響を確かめ、必要な範囲を制限する

業務責任者が誤案内の影響を確認し、基盤・保守担当が必要な制限を実施します。重大な漏えいや意図しない実行が疑われる場合は、既存の事故対応手順へ引き継ぎます。

緊急時に誰が一時停止できるかは事前に決めます。停止の判断者が不在で、対応が始められない状態を作らないことが大切です。

切り分け：資料、検索、指示、権限を確認する

知識源担当が現行規程を確定し、技術保守担当が古い資料を参照した理由を調べます。単に指示文へ「最新の資料を使う」と追記して終わらせず、参照範囲と版の扱いを直します。

再開：修正結果を業務の正解と照合する

保守担当がテストを実行し、業務責任者が回答と利用条件を確認します。基盤設定に変更があれば管理担当も確認し、再開範囲と利用者への案内を記録します。

受付、影響判断、原因切り分け、修正と再評価、再開を各担当が連携する図（AIworkerの設計例）

変更の種類によって、確認する相手を変える

AIでは「プログラムを変えていないから再確認不要」とは限りません。次の対応表を、社内の変更手続きへ追加できます。

規程・FAQの更新

内容を決める担当：知識源担当と業務責任者
追加で確認すること：根拠の版、影響する質問の再評価

指示・処理の変更

内容を決める担当：技術保守担当と業務責任者
追加で確認すること：対象外の動作、以前のケースの再確認

モデルの切り替え

内容を決める担当：技術保守担当
追加で確認すること：品質・費用・動作の変化と業務受け入れ

接続先・権限の追加

内容を決める担当：基盤管理担当と業務責任者
追加で確認すること：実行できる操作と対象データ

他部門への展開

内容を決める担当：受け入れ側の業務責任者
追加で確認すること：規程・利用者・問い合わせ体制の差

変更を実施する担当と、結果を受け入れる担当を対応づけると、依頼がたらい回しになりにくくなります。

製品上の所有者・編集権限も、その分担と整合させます。Agent Builderには複数の編集可能な所有者や管理者による再割り当ての仕組みがあるため、担当者退職で必ず管理不能になるわけではありません。ただし、権限を移しても業務知識まで移るわけではありません。Microsoft：共有と所有者の管理

担当者の異動前に、後任が実際に操作する

引き継ぎでは、連絡先と手順書に加えて、判断の根拠を渡します。なぜこの資料だけを参照するのか、なぜこの質問は差し戻すのかが分からないと、後任の改善で制約が消える可能性があります。

次の様式はAIworkerの提案です。

対象エージェント／製品／環境／識別子：
業務責任者／技術保守／知識源管理／基盤管理：
問い合わせ受付／不在時の代行：
公開版と、現在の利用条件：
評価ケースと期待結果の置き場：
知識源と更新手続き：
接続先・認証の管理方法（秘密情報そのものは記載しない）：
既知の制約と、対象外にした理由：
停止・代替・再開の手順：
後任による操作確認日／残った不明点：

後任には、通常の操作だけでなく、参照不能やエラー時の確認、停止手順も試してもらいます。前任者へ質問せずに、どこまで対応できたかで引き継ぎの不足を見つけます。

担当分担が決まらず運用が止まっている場合は、現在の問い合わせの流れをもとにご相談いただけます。

▶️ AIエージェントの運用体制について問い合わせる

ページ下部の「お問い合わせ」にある「ご相談・ご質問」欄に「役割分担の記事を見た」と、判断が止まる場面をご記入ください。

外部へ委託しても、業務の受け入れ判断は社内に残す

外部パートナーへ技術保守や評価支援を委託することはできます。その場合も、対象業務の正解、利用範囲、優先順位を決める社内担当は必要です。

契約前には、監視、問い合わせ受付、修正、再評価、知識源更新のどこまでを含むか確認します。対応時間帯、緊急時の連絡、改修費の扱い、終了時に受け取る資産も具体化します。

「保守あり」だけでは、AIの何を維持するのかが分かりません。 プロンプトやコードに加え、評価ケース、変更履歴、接続構成、未解決事項を引き継げる条件を整えます。

アプリ全般の体制は、市民開発の運用・権限・引き継ぎでも扱っています。本記事の分担は、AIの誤回答、知識源の変更、再評価と再開の判断に焦点を当てています。

よくある質問（FAQ）

Q. 情シスがすべて管理すべきですか？

基盤管理は担えても、業務の正解まで一括で判断するのは難しい場合があります。業務責任者と知識源担当を明確にします。

Q. DX推進室がない会社はどうすればよいですか？

既存の部門責任者とIT管理担当で役割を分担できます。専任組織を作る前に、判断と連絡の相手を決めます。

Q. 作成者が異動すると使えなくなりますか？

必ず使えなくなるわけではありません。製品上の所有者・認証・接続の移管と、業務知識・テスト・手順の引き継ぎを確認します。

Q. 保守担当は利用者の質問にもすべて答えるのですか？

技術的な不具合と、業務内容への質問を切り分けます。受付は一本化し、業務判断が必要なものを業務側へつなぐ方法があります。

Q. 外注先が修正したら、すぐ利用を再開してよいですか？

変更の影響に応じて再評価し、社内の受け入れ判断者が確認します。再開の条件と権限は事前に合意しておきます。

作成者に依存しない運用体制を作りたい方へ

AIworkerは、研修、業務設計、AI開発、運用定着を支援しています。社内の業務担当者と技術担当者の間で止まる課題を整理し、運用できる責任分担をご相談いただけます。

相談時は、「誤回答の判断」「資料の更新」「異動時の引き継ぎ」など、止まっている場面を1つお伝えください。 体制図が完成していなくても構いません。

▶️ AIの運用体制・伴走支援を相談する

運用設計を具体化する関連記事

著者情報