業務工程ごとにAIエージェントを役割分担させる設計手順

目次

1. 概要：AIエージェントは工程に分けて配置し、担い手・基盤・人の関与・測り方までをまとめて決める
2. 出発点は個別のツール選びではなく、対象業務を工程に分けてどこにAIエージェントを置くかを決めることにある
3. 役割は工程ごとに必要な専門知識の違いで切り分け、手戻りの発生箇所を踏まえて設計する
4. 分けた役割ごとに求められる性能が違うため、担わせるモデルやツールも役割に合わせて選び分ける
5. 役割分担を成立させるには、各エージェントが参照する業務データと既存資産をつなぐ基盤が要る
6. 人が担う範囲は明示して残し、AIの出力を確認・調整する役割を設計に含める
7. 効果は工程単位で測り、全工程の目標へ積み上げる形で確認する
8. 空いた時間の使い道と、使う人の習熟までを設計の一部として決めておく
9. 結論：工程を分けて役割と担い手を割り当て、データ基盤・人の関与・工程別の効果測定まで含めて決めることが設計手順になる

概要：AIエージェントは工程に分けて配置し、担い手・基盤・人の関与・測り方までをまとめて決める

AIエージェントを業務に入れるとき、最初に悩むのは「どのツールを使うか」だと思います。ただ、実際の事例を見ると、先に決まっているのはツールではなく、業務をどの工程に分けて、どの工程に何を任せるかです。

日立製作所は、Agentic AI Integration Platform 日立Agentic AI基盤でSI全工程の生産性を向上 でフロンティアAI・SI資産・企業コンテキストを結び、構想策定から運用までの工程にAIエージェントを配置しています。社内では要件定義で最大240倍、設計〜テストで約200倍の生産性向上を確認し、2027年度には全工程で30％向上を目指すとしています。

博報堂と博報堂テクノロジーズの「マルチエージェント ブレストAI」博報堂のマルチエージェント ブレストAIで商品開発を効率化 は、企画・製造・物流・リテール営業など各フェーズの専門人員の知識をAIに与え、市場ニーズ探索・商品企画から商品開発・デリバリーまでの議論をAI同士が行う仕組みです。Emperor Financial Services Group（EFSG）EFSGのCopilot Studio顧客対応統合 は、Dynamics 365上でCopilot Studioのチャットボット、AI搭載音声認識、感情分析を、それぞれ別の役割として顧客対応に組み込みました。富士通 富士通、Dev BoxとGitHub Copilotで開発負荷20%削減 は、GitHub Copilotに開発者の指示に基づくテスト実施と結果の検証、編集案の提示、エラー支援という反復的なタスクを担わせ、Microsoft Dev Boxとの活用で作業負荷を20%削減しています。

工程に分ける、役割を割り当てる、担い手を選ぶ、データをつなぐ、人の関与を残す、工程ごとに測る。この順番で決めていくと効率的に利用方法を構築できます。

出発点は個別のツール選びではなく、対象業務を工程に分けてどこにAIエージェントを置くかを決めることにある

日立製作所の事例で目を引くのは、AIの種類の話より先に、工程の並びが置かれていることです。構想策定から運用までという工程の順序があり、その各工程にAIエージェントを使う形です。

博報堂テクノロジーズも同じ順序です。「市場ニーズ探索・商品企画」から「商品開発・デリバリー」までを商品開発プロセスとして区切り、そのプロセスに関する議論をAIに担わせています 。工程の区切りが先にあり、そこにAIを入れる形をしています。

最初にやることは、次のように整理できます。

• 対象にする業務の始まりと終わりを決める（どこから手をつけ、どこで終わるか）。
• その間を、実際の仕事の順番に沿って工程へ分ける。
• 各工程で何が作られ、次の工程へ何が渡るかを書き出す。
• そのうえで、どの工程にAIエージェントを置くかを選ぶ。

ツールから入ると、そのツールでできることに業務が引きずられます。工程を先に描いておくと、どこが空いているかが見えます。

役割は工程ごとに必要な専門知識の違いで切り分け、手戻りの発生箇所を踏まえて設計する

工程に分けたら、次は役割の中身です。マルチエージェント ブレストAIは、企画・製造・物流・リテール営業など、各フェーズの専門人員の知識をそれぞれのAIに与えています 。役割の切り分け方が、工程ごとに必要な専門知識の違いに沿っている点がポイントです。

この設計には理由があります。初期の商品企画段階から多くの専門知識を持つ人材を巻き込んで打合せや検討を重ねることは、人材確保や工数の面で現実的ではない、という課題が前提にありました。そこで商品コンセプト段階から実現性などを考慮したアイデアを創出することで、商品開発で生じる手戻りを大幅に減少させ、プロセス全体の効率化を図る、という狙いが示されています。

つまり役割分担は、単に作業を分けたのではなく、手戻りが起きる場所から逆算して組まれています。後工程の視点が前工程に届いていないから手戻りが起きる。だったら前工程の議論に後工程の知識を持ったAIを混ぜる、という考え方です。

役割を決めるときの観点をまとめると、次のようになります。

• 各工程で必要な専門知識は何かを言葉にする。
• その知識を持つ人を、いつも巻き込めているかを確認する。
• 巻き込めていない工程が、手戻りの発生源になっていないかを見る。
• 足りていない知識を、AIエージェントの役割として置く。

分けた役割ごとに求められる性能が違うため、担わせるモデルやツールも役割に合わせて選び分ける

役割が決まると、次は担い手です。ここで効いてくるのが、役割ごとに求められる性能が違うという点です。

Googleは、AIエージェント向けにGemini 3.6 Flash、Gemini 3.5 Flash-Lite、Gemini 3.5 Flash Cyberの3モデルを公開しています Google Gemini新3モデルでAIエージェントを強化。位置づけは次のように分かれています。

• Gemini 3.6 Flash：トークン使用量の削減と性能改善。
• Gemini 3.5 Flash-Lite：低遅延の大量処理。
• Gemini 3.5 Flash Cyber：CodeMenderでの脆弱性検出・検証・修正案の作成。

Flash Cyberは、政府機関と信頼できる提携先へ限定試験として提供されるものです。つまり、役割によっては誰でもすぐ使えるとは限らない、という前提も含めて選ぶことになります。

EFSGの顧客対応も、機能ごとに別の役割へ割り当てられています 。FAQへの即時回答はチャットボット、通話の自動文字起こしはAI搭載音声認識、管理者が介入の優先順位を判断する支えは感情分析です。同じ「顧客対応のAI」でもひとまとめにはせず、担わせる仕事に合わせて別々の仕組みを当てています。

役割の切り分けと、担い手の選定は別の作業です。役割を決めてから、その役割に合う性能を持つものを選ぶ、という順で考えると迷いにくくなります。

役割分担を成立させるには、各エージェントが参照する業務データと既存資産をつなぐ基盤が要る

役割と担い手が決まっても、それだけでは動きません。各エージェントが仕事をするには、参照する情報が必要だからです。

日立製作所のAgentic AI Integration Platformは、フロンティアAI、SI資産、企業コンテキストを結びつける構成をとっています 。AIモデルだけでなく、これまで積み上げてきたSIの資産と、その企業ならではの文脈を、同じ基盤の上でつないでいる形です。

EFSGは、全チャネルにわたる顧客とのやり取りを管理する単一の統合環境として、Dynamics 365 Contact Center、Dynamics 365 Customer Service、Microsoft Power Platform、Microsoft Copilot Studioを採用しました 。そのうえで、Copilot Studioで作ったチャットボットを顧客データと連携させています。請求に関する問い合わせの電話があったとき、チャットボットが過去のやり取りの概要を自動的に生成できるのは、顧客データにつながっているからです。

富士通の場合は、開発環境そのものが土台になりました。Microsoft Dev Boxでプロジェクト専用のクラウド開発環境を迅速に準備したうえで、GitHub Copilotを日常の開発作業に導入しています 。

役割分担の設計は、データをどうつなぐかの設計とセットです。参照先のない役割は、名前だけの役割になります。

人が担う範囲は明示して残し、AIの出力を確認・調整する役割を設計に含める

工程にAIを置くと、人の仕事がなくなるように見えるかもしれません。ですが事例を見ると、人の役割はむしろ明示的に残されています。

富士通のGitHub Copilotが担うのは、開発者の指示のもとでの反復的なタスクです 。テストの実施やその結果の検証を任せつつ、編集案の提示やエラーのヘルプという、支援の形をとっています。指示を出し、案を受け取って判断するのは開発者です。

EFSGでは、顧客サービスマネージャーがチャットボットのフローに関するフィードバックを確認し、必要な調整を行えるようになっています 。現場の担当者も、システム内で数回のクリック操作でFAQの回答や挨拶メッセージを更新できます。情報を最新に保つ手段が、使う人の側に置かれているわけです。

マルチエージェント ブレストAIも、議論過程や根拠の可視化、人間との対話やフィードバックを通じた学習や改善を特徴として持っています 。AI同士の議論をそのまま結論にするのではなく、中身が見えて手を入れられる形になっています。

設計に含めておきたい人の役割は、次のあたりです。

• AIに何を指示するかを決める人。
• 出てきた案や結果を確認し、採用の可否を判断する人。
• 動きがずれてきたときに、設定や文面を調整する人。
• 判断の根拠が見える状態を保つ仕組み。

効果は工程単位で測り、全工程の目標へ積み上げる形で確認する

役割分担の効果は、まとめて「便利になった」では確認できません。工程に分けたのだから、測るのも工程単位になります。

日立製作所は、要件定義で最大240倍、設計〜テストで約200倍という工程別の生産性向上を社内で確認しました 。そのうえで、2027年度には全工程で30％向上を目指すとしています。工程ごとの数字が先にあり、全工程の目標はそこから先に置かれている構造です。工程単位の大きな数字と、全工程の目標が別の数字になっている点も、そのまま読んでおきたいところです。

富士通は、Microsoft Dev BoxとGitHub Copilotの活用で作業負荷を20%削減し、2025年には375,000時間の節約を見込んでいます 。EFSGは、チャットボットによる即時回答、会話要約、案件記録の更新の支援を通じて、顧客対応の迅速化と顧客満足度向上につなげました 。

確認済みの効果と、これから目指す目標は分けて扱います。工程ごとに測っておくと、どの役割が効いていて、どこがまだかが見えます。

空いた時間の使い道と、使う人の習熟までを設計の一部として決めておく

工程からAIに任せた分、時間が空きます。その使い道まで決めておくかどうかで、結果は変わります。

博報堂は、効率化により創出された時間を、強みである「クリエイティビティ」を発揮できる業務に注力することで、品質向上も実現するとしています 。富士通も、開発者の才能を創造的な問題解決に集中させることを狙いに置き、ハードウェア設定に費やしていた時間を削減しました 。空いた時間を何に充てるかが、あらかじめ決まっています。

もう一つが、使う人の習熟です。ABCash Technologiesとx3dが提供するAIZUS AIZUSで13種AIを業務へ定着する研修 は、「使い方は理解していても業務で活用できない」という課題を背景に作られたプログラムです。2カ月・全8回のワークショップで13種類以上の主要AIツールを横断的に扱い、プロンプト設計から業務への実装まで、さらにAIエージェントに業務を任せる進め方までを学ぶ構成になっています。

EFSGのDynamics 365導入でも、パートナーのItopia Limitedがシステムアーキテクチャの設計やワークフローの開発に加え、顧客サービス担当者向けの包括的なトレーニングセッションを実施しました 。仕組みを入れることと、使えるようにすることが、同じプロジェクトの中に並んでいます。

• 空いた時間を何に充てるかを、導入前に決めておく。
• 使う人が扱えるようになる機会を、導入計画に入れておく。
• 学ぶ範囲に、ツールの操作だけでなく業務への組み込み方を含める。

結論：工程を分けて役割と担い手を割り当て、データ基盤・人の関与・工程別の効果測定まで含めて決めることが設計手順になる

ここまでの事例をまとめると、AIエージェントの役割分担の設計は、次の手順として読み取れます。

• 対象業務を工程に分け、どの工程にAIエージェントを置くかを決める。
• 工程ごとに必要な専門知識の違いで役割を切り分け、手戻りの発生箇所から逆算する。
• 役割ごとに求められる性能に合わせて、担わせるモデルやツールを選ぶ。
• 各エージェントが参照する業務データと既存資産をつなぐ基盤を用意する。
• 人が指示・確認・調整を担う範囲を明示して残す。
• 工程単位で効果を測り、全工程の目標へ積み上げる。
• 空いた時間の使い道と、使う人の習熟までを計画に含める。

日立製作所は、工程の並びに沿ってAIエージェントを配置し、工程別の生産性向上を確認したうえで全工程の目標を掲げています 。博報堂の事例は、工程ごとの専門知識を役割としてAIに与えることで、手戻りの減少とプロセス全体の効率化を狙う形を示しています 。EFSGの事例は、役割ごとに機能を割り当てたうえで、統合環境と顧客データへの接続、管理者による調整、担当者へのトレーニングをそろえた構成です 。そしてGoogleは、役割ごとに性能特性の異なるモデルを用意しており、役割と担い手の対応づけそのものが選択の対象になっていることが分かります 。

難しい発想は要りません。自分の仕事を工程に分けて書き出し、どこに誰（何）を置くかを一つずつ決めていく。事例が示しているのは、その積み重ねです。