生成AIの活用が進む企業では、部署やチームごとにAIエージェントが開発され、他部署からは存在も使い方も分からなくなることがある。かといって、すべての機能を1つのエージェントに集約すれば、運用や権限管理が複雑になる。コロプラはこの問題に対し、各チームのエージェントを残したまま、A2Aでつなぐ仕組みを構築した。権限やデータは各チームの管理下に残し、エージェントの呼び出し範囲や記憶の公開範囲も制御したのだ。

Google Cloudが10月29～30日に開催した「Agentic AI Summit’26 Fall」では、コロプラ CIO室 有田裕紀氏が、社内AIアシスタント「William」の設計と運用について紹介した。

エージェントを1つに集約すると生じる問題

モバイルゲームなどを手掛けるコロプラでは、プロダクトごとにチームがあり、仕事の進め方も異なる。ゲームタイトルの創作自体は人が担い、AIはそれを支える業務に活用している。AIの利用は全社に広がっており、社員が自作した業務自動化の仕組みは1,000個を超えたという。

AI活用が進む一方で、組織内にエージェントが増えることによる課題もある。有田氏が挙げたのは「Agent sprawl（エージェントの乱立）」だ。

「各チームのエージェントは、そのチームの中では精度高く業務に使われています。しかし、ほかのチームからは使えず、どこに何があるのかも分からない状態になっていきます」

  • 有田裕紀氏

    コロプラ CIO室 有田裕紀氏

解決策として考えられるのは、複数チームの機能を1つのエージェントにまとめることだ。しかし、有田氏はこの方法にも問題があると指摘する。例えば、あるチームが手順を変更すると、同じエージェントを使うほかのチーム向けの処理まで変わり、修正のたびに全チームで確認する必要が生じる。障害が起きた場合も、原因となった変更や修正の担当が不明確になる。さらに、各チームが持つ権限が1カ所に集中してしまう。

そこでコロプラが選んだのは、各チームのエージェントを統合せず、共通の窓口から呼び出せるようにする方法だった。

「William」がA2Aで各チームのエージェントをつなぐ

コロプラは社内AIアシスタント「William」をハブとして設け、各チームが管理するエージェントと接続した。利用者は、どのエージェントを呼び出すべきかを自分で探して選ぶ必要はなく、SlackやWilliamのWeb画面から仕事を依頼すればよい。

  • WilliamをハブとしてA2Aで接続する

    各チームのエージェントを統合せず、WilliamをハブとしてA2Aで接続する

連携に使うのは、異なるエージェント同士が連携してタスクを実行するためのオープンな標準仕様「A2A（Agent‑to‑Agent）」だ。各チームは従来のエージェントをそのまま運用しながら、A2Aを通じてWilliamにつなげられる。Williamの側に変更があっても、それに合わせて各チームのエージェントを作り直す必要はない。

エージェントが道具やデータを使うための標準仕様「MCP（Model Context Protocol）」でも、別のチームの機能を道具として呼び出すことはできる。ただし、各チームの道具を1つのエージェントに集めれば、結局はエージェントが肥大化してしまう。そこでコロプラは、道具を利用する部分ではMCP、持ち主の異なるエージェント同士の連携ではA2Aを使っている。

「各チームで生まれたエージェントは、お互いの存在を知りません。それでもハブにつながっていれば、協力して仕事を進められます。あるエージェントの結果を別のエージェントに渡すことも、両方に頼んで結果をまとめることもできます」

呼び出せるエージェントは「場」ごとに決める

複数のエージェントをつなぐ際には、権限の扱いも重要だ。他部署が管理するシステムを使うには、権限申請が必要になることがある。しかし、コロプラの構成では、利用者にシステムの権限を直接付与するのではなく、そのシステムを管理するチームのエージェントに仕事を依頼する形をとる。

「持ち主のエージェントが、自分の権限と手順で動きます。返すのは答えだけで、生データは持ち主のチームの外に出ません。使ってよいかどうかの判断も、持ち主のエージェントが行います」

各チームはデータと権限を自分たちの管理下に置いたまま、ほかのチームからの依頼に対応できる。Williamがすべてのシステムの権限を持つわけではない。

ただし、共通の窓口から、どの場でもすべてのエージェントを呼び出せるわけではない。有田氏は、利用者がエージェントと一緒に仕事をするSlackのチャンネルや、1対1のやり取りを「場」と呼ぶ。どのエージェントを呼び出せるかは、この場ごとに制限している。

「1つのエージェントの中で場ごとに権限を分けることもできると思いますが、その切り分けをLLMの判断に任せると、間違いが起きる余地があります。私たちはエージェントをつなぐ部分で、この境界を制御しています」

例えば、全社向けのエージェントはどの場からも呼び出せる。一方、部署Bのエージェントは部署Bのチャンネルからしか呼び出せない。プロダクトチームAのエージェントは、同チームのチャンネルに加え、部署Bとの横断チャンネルからも呼び出せるといった具合だ。場の持ち主とエージェントの持ち主の双方が認めれば、別の場にも接続できる。どの場から何を呼び出せるかは事前の設定で決まり、LLMには判断させない。

WilliamのWeb画面では、チャンネルごとに利用するエージェントの設定が可能だ。エージェントの種類によって、チャンネルのメンバーが接続・解除できるものと、管理者だけが接続できるものがあるという。また、予定の確認など、利用者本人の権限で動くエージェントは、1対1のダイレクトメッセージでのみ利用できる。

有田氏は、障害の再発防止策を尋ねる例も紹介した。全社向けの場では、障害報告書を管理するエージェントは呼び出せても、特定プロダクトの稼働状況を確認するエージェントは呼び出せない。そのため、具体的な設定や数値は確認できない。一方、そのプロダクトのエージェントが接続された場では、同じ質問でも設定や稼働状況を踏まえた回答が可能になる。窓口が同じWilliamでも、回答できる範囲は場によって異なるわけだ。

会話の「記憶」をどう管理するか?

エージェントには、過去の会話や覚えた内容を後から参照するための「記憶」もある。そこで必要になるのは、どのエージェントを呼び出せるかという制御とは別の、情報の公開範囲の管理だ。有田氏は「記憶の境界は、エージェントが働く場の境界とは分けて考えるべきだ」と語る。

「場の境界にそのまま従えば、記憶が漏れることはありません。ただ、それでは全員が見てよい公開チャンネルの話まで、その場に閉じてしまいます。記憶は別の場所で使えてこそ価値があります。エージェントは場の中で働きますが、記憶は情報です。私たちは社内検索と同じように、見てよい人の範囲で分けています」

コロプラでは、エージェントの記憶に関する4つの分類を社内の仕組みに当てはめ、「進行中の会話」「過去の会話記録」「会話から覚えた内容」「手順に当たるスキル」として整理している。進行中の会話は、やり取りしているスレッドの中だけで使う。公開チャンネルの会話記録は、閲覧を認められた範囲で別の場からも参照できる。

一方、非公開の場の記録は原則としてその場に閉じ、共有範囲を広げる場合は関係する場のメンバーが判断する。また、会話から覚えた内容は場ごとに扱い、共有範囲を広げる場合は持ち主が判断する。スキルも場ごとに設定し、利用範囲を広げるかはメンバーが決めるといった具合だ。

Agent Platformで動かし、Gemini Enterpriseからも利用する

Williamの実装には、Google CloudのAgent Platformが使われている。ハブとなるエージェントはオープンソースの開発フレームワーク「Agent Development Kit（ADK）」で作り、Agent Runtimeで動かす。Slackとの連携などにはCloud Runを使い、会話や記憶の管理にはSessionsやMemory Bank、Spannerなどを組み合わせ、利用者本人の権限で動くエージェントとの連携には、Agent Identityを利用しているという。

  • Agent Platformと周辺サービスの構成

    Williamを動かすAgent Platformと周辺サービスの構成

各チームのA2A対応エージェントは、Williamを介してSlackやWilliamのWeb画面から利用できるほか、Google Cloudの企業向けAIサービス「Gemini Enterprise」からも直接呼び出せる。利用者は、Williamで複数のエージェントを組み合わせるか、Gemini Enterpriseから特定のエージェントに直接仕事を頼むかを選択可能だ。

Gemini Enterpriseから直接利用する例として、有田氏は、コロプラのオウンドメディア「ピンマーク」の記事を案内するエージェントを披露した。このエージェントでは、画面の構成要素を受け渡すためのプロトコル「A2UI（Agent to UI）」を使い、Gemini Enterprise上でカードなどを表示する。

「AIの記事を読みたいと頼むと、エージェントが依頼に合うテーマを選んで、記事を3本のカードで返します。カードのボタンを押すと、本文から要点を3つにまとめてくれます。下のチップからテーマを選び直すこともできます」

*　*　*

有田氏は、コロプラがそろえたのは「頼み方と境界だけ」だと総括した。各チームがエージェントを自由に作り続けられるようにするためだという。一連の解説を終えた同氏は、すでに社内でエージェントを動かしている企業に向けて、次のように呼びかけた。

「皆さんの会社に、稼働中のカスタムエージェントはありますか。もしあるなら、その中から1つ、A2Aで呼べるようにしてみてください。作り方は特に変える必要がありません。それだけでGemini Enterpriseに登録して使えるようになり、ほかのエージェントと組み合わせる材料にもなります」