1. はじめに 以前、以下の記事でAWS AI Leagueについて紹介しました。 https://zenn.dev/nttdata_tech/articles/a907eb00cbbe4b AWS AI Leagueは、競技形式で生成AIの技術を学ぶプログラムです。主に、次の2つのテーマが用意されています。 Amazon SageMaker AIを利用したモデルのファインチューニング Amazon Bedrock AgentCoreを利用したAgentic AI Agentic AIチャレンジでは、AIエージェントがマップ上を移動し、コインの取得や質問への回答などを行いながら、

こんにちは。開発本部の河野です。 このたび、社内の運用チームから寄せられる問い合わせに一次対応する Bot を、Claude Managed Agents を使って構築しました。本記事では、アーキテクチャ・ツールの使い分け・設計上の判断を中心に、検討の過程を紹介します。これから導入を検討される方の参考になれば幸いです。 本記事について 　Claude Managed Agents は、本記事の執筆時点（2026 年 7 月）では パブリックベータ です。今後の正式提供（GA）に向けて、仕様や挙動が変わる可能性がある点にご留意ください。最新の情報は公式ドキュメント（ Claude Managed Agents overview ）をご確認ください。 背景：実データを確認しないと答えられない問い合わせ はじめに、前提を簡単に共有します。 社内には、キャンペーン応募の運用を担う管理画面つきの業務ツールがあります。ビジネス職はこの画面から、応募フォームの設問や表示条件を組み立て、集まった応募データの変換ルールを定義し、クライアントへ送付するデータの形式を設定します。 このツールは、案件ごとに設問や変換ルールを自由に組み合わせられるぶん、設定次第で挙動が変わり、意図どおり動くかの判断が難しくなります。そのため開発チームには、次のような問い合わせが日々寄せられていました。 設定方法や仕様の質問 ：「この設問に回答した人にだけ画像を表示するには？」「この項目は設定できない認識で合っているか」 エラーやデータ不整合の調査 ：「テスト時に出力データの件数が想定と合わない」「応募フォームを修正して公開したが、修正前の内容が表示される」 前者はドキュメントや仕様を調べれば答えられますが、後者は設定の内容・変換処理の実行状況・出力されたデータを、その都度確認しなければ答えられません。 つまり、あらかじめ用意した FAQ を返すだけでは、後者のような問い合わせに一般論しか返せません。そこで求めていたのが、実データまで確認したうえで一次回答を返すエージェントでした。これが今回の出発点です。 なぜ Claude Managed Agents を選んだか この問い合わせは、どこか一箇所を検索すれば済むものではありません。回答を組み立てるには、管理画面の設定、その裏側で変換処理を動かしている AWS、ドキュメント、ソースコードといった複数の情報源を横断しながら考える必要があります。 自前でエージェントのループ（モデルに推論させ、ツールを呼び出し、その結果を再び渡す、という処理を繰り返す仕組み）を実装する選択肢もありました。しかし、そのループの実行をマネージド側に任せられれば、私たちは「どのようなツールを持たせるか」「プロンプトをどう設計するか」に集中できます。今回の課題ではこの点が最も効くと考え、Claude Managed Agents を採用しました。あわせて、この取り組みは新しい技術に挑戦する社内の機会「挑戦WEEK」の中で始まったもので、当時登場して間もなかった Claude Managed Agents を実地で使ってみたい、という動機もありました。 補足 　同様のことは、Amazon Bedrock AgentCore をはじめとする他のマネージドなエージェント基盤でも実現できます。今回は「新しい技術を試す」という挑戦WEEK の主旨から Claude Managed Agents を選びましたが、これから腰を据えて構築するのであれば、こうした選択肢も比較検討に加える価値があります。 Claude Managed Agents とは 本題に入る前に、前提となる部分だけ簡単に整理します。 Claude Managed Agents は、大まかに言うと、プロンプト・ツール・スキルをまとめた "Agent" を定義しておくと、推論ループの実行自体はマネージド側が担ってくれる仕組みです。 自前でループを実装する場合と比べると、開発側が担う範囲は次の3つに絞られます。 Agent 定義 （プロンプト・利用するツール・スキル・MCP の接続設定のまとまり） custom tool の実装 （自社システムを呼び出すコード） セッションの運用 （会話やイベントのハンドリング） 主なプリミティブは以下のとおりです。まずは名称だけ挙げておきます。 Agent ：バージョン管理される Agent 定義 Session ：会話の単位（Sessions API） custom tool ：自前で実装するツール MCP ：外部サービスとの既製の連携 skill / memory store ：手順やナレッジ、過去事例の蓄積先 custom tool と MCP について補足 このあと繰り返し登場するため、この2つだけ先に補足します。 custom tool は、モデルに持たせる「道具」です。モデルが「この道具をこの引数で使いたい」と判断すると、実際に動作するのは開発側が実装したコードで、その結果を返すとモデルが推論を続けます。定義は name / description / input_schema からなり、とりわけ description （その道具が何をするものか）の記述が精度を大きく左右します。 一方の MCP は、外部サービスやデータ源をエージェントに接続するための標準的な仕組みです。Confluence や Slack のように公式の MCP サーバがすでに提供されているものは、それを繋ぐだけで使えます。ただし MCP サーバは自作することもできるため、「MCP か custom tool か」は "既製か自前か" という単純な対立ではありません。 では、この2つをどう使い分けたのか。ここが本記事の中心となるため、次章でまとめて扱います。 構成と、ツールの使い分け・設計上の判断 ここからが本題です。 全体の流れ Bot の動作自体はシンプルです。 運用担当が Slack でメンションして質問する 実行環境がセッションを開始し、イベントを受け取る Agent が必要な custom tool / MCP を呼び出しながら、実データを集めて推論する まとまった一次回答を Slack のスレッドに返す 図で示すと、Slack を入口として、実行環境がセッションとツール実行を担い、サーバ側の Agent が custom tool と MCP を使い分けながら回答を組み立てる、という構成です。 持たせているツールと、その使い分け Bot に持たせているツールは、現時点ではすべて read-only（参照のみ）です。設定の書き換えやジョブの再実行は行いません。まずは「調べて答える」ことに用途を絞りました。 情報源ごとに、custom tool にするか・MCP にするか・リポジトリを参照させるかを分けています。 情報源 参照するもの 実現方法 社内管理画面 現在の設定（案件・変換・送付設定など） custom tool（管理画面 API を呼び出す） AWS のジョブ実行状況 ジョブが成功したか、どこで失敗したか custom tool AWS の出力データ 出力データ（テーブル・カラム）が実在するか custom tool Confluence 運用手順・仕様のドキュメント MCP Slack 問い合わせ元スレッドの文脈 MCP GitHub 設定や画面では分からない「実際の挙動」 リポジトリをマウントして参照 AWS 側では、変換ジョブとその出力データを確認しています。内部的には一般的な構成ですが、本記事では「AWS 上のジョブと出力データを custom tool 経由で確認している」程度の粒度にとどめます。 設計上の判断①：custom tool と MCP をどう使い分けたか ツールを整理するうえで最も悩んだのが、「この情報源は custom tool と MCP のどちらにすべきか」という使い分けでした。一般論としての比較ではなく、今回の Bot で実際にどう判断したかを述べます。 判断は、大きく2段階でした。 まず、 公式の MCP サーバがすでにある情報源は、MCP で繋ぐ ことにしました。Confluence や Slack がこれにあたります。既製のものがあるのに、わざわざ自作する理由はありません。 問題は、管理画面や AWS のように 既製の連携が存在しない情報源 です。これらはエージェントから触れるようにするために、何かしら自分たちで実装する必要があります。ここで MCP サーバを自作する道もありましたが、 MCP サーバを立てるよりも、custom tool として実装するほうがコストが低く、早く動かせます 。まずは動くものを優先したかったので、これらは custom tool にしました。 公式の MCP がある（Confluence / Slack）→ MCP で繋ぐ 既製の連携がない（管理画面 / AWS）→ 実装が必要。より軽い custom tool を選択 コードを事実として参照させたい（GitHub）→ リポジトリをマウントして参照 （後述） ここで大事なのは、「MCP か custom tool か」は "既製か自前か" では決まらない、という点です。MCP サーバも自作できるので、実際に効いてくるのは "どちらのほうが軽く・早く目的を果たせるか" でした。 なお、GitHub には公式の MCP も用意されています。それでもリポジトリをマウントする方式にしたのは、用途がソースコードの読解だったためです。MCP 経由ではファイルを API で1つずつ取得する形になりがちですが、リポジトリをマウントしてしまえば、エージェントがコード全体を grep や横断参照でたどれます。「実際の挙動をコードで確認する」という用途には、こちらのほうが向いていました。MCP が力を発揮するのは、issue や PR の操作といった場面です。ここでも、「MCP があるかどうか」だけで機械的に決めるのではなく、その情報源に対して何をしたいかで選ぶ、という判断でした。 設計上の判断②：調べる範囲を先に絞る 情報源を渡す際には、範囲を絞ってから渡すことを徹底しました。 Confluence は「正典」とするページに限定する ：関連しそうなページを無制限に参照させると、古い記述や書きかけのページに引きずられ、誤った回答につながります。「これが正である」と定めたページのみを参照先とすることで、誤読を防いでいます。あわせて、その正典ページ自体を最新に保ち続ける運用も欠かせません。参照先を絞るほど、そのページの正しさがそのまま回答の質に直結するためです。 ツールは read-only に限定する ：前述のとおり、書き込み系の操作はまだ持たせていません。参照に用途を絞ることで、安心して社内に展開できる状態を先に整えました。 範囲をあとから広げるのは容易ですが、広げすぎたものを絞り込むのは困難です。そのため、先に狭く定めておく方針としました。 設計上の判断③：self-hosted 型ではなく Cloud 型を選んだ Claude Managed Agents には、実行基盤を自前で持つ self-hosted 型 と、マネージドな Cloud 型があります。当初は self-hosted 型を検討していましたが、最終的に Cloud 型を選びました。その経緯を書きます。 self-hosted 型では、マネージド側のエージェントが「このツールを実行してほしい」と判断したとき、その実行を受け取って処理するワーカーを、自社の環境で常時動かしておく必要があります。ワーカーというプロセスを一つ立て、接続を保ち、動き続けているかを監視する。エージェントのループ自体はマネージドに任せられても、その足回りは自分たちで抱えることになります。 さらに決め手になったのは、運用負荷そのものよりも、私たちが最も頼りにしたかった機能との噛み合わせでした。過去事例を蓄積する memory store や、マウントしたソースコードをエージェント自身に読ませる仕組みは、いずれもマネージドな環境の中で動くことを前提に設計されています。self-hosted 型ではその実行が自前ワーカー側に委譲され、期待どおりに動かない場面がありました。活かしたい機能ほど、実質的に Cloud 型を前提としていたのです。 結局 self-hosted 型は、「ワーカーの運用という手間が増える」一方で「使いたかったマネージド機能は活かしきれない」という、狙いと逆向きの選択になっていました。「実行を任せて設計に集中する」という当初の目的からすると本末転倒です。そこで Cloud 型に切り替えました。ワーカーは不要になり、構成は Bot 本体ひとつに単純化され、サーバ側の機能もそのまま利用できるようになりました。 補足：self-hosted 型が適する場面もあります。 たとえばツールの実行を自社ネットワーク内に閉じ込めたい、といった要件がある場合です。今回はそうした制約がなく、マネージドの利点が上回ったため Cloud 型を選びました。要件次第で判断は変わる、という点は添えておきます。 設計上の判断④：デプロイを2種類に分ける 運用する中で、変更には性質の異なる2種類があることが分かってきました。 プロンプトやツール定義のみの変更 → agents.update で新しいバージョンを作成すれば反映される（コンテナの再ビルドは不要） custom tool のコードの変更 → コンテナの更新が必要になる この2つを分けて扱うようにしたことで、「プロンプトを少し修正したいだけ」という場合にコンテナのデプロイを待たずに済み、改善のサイクルを回しやすくなりました。 実際にできるようになったこと ここまでの構成により、Bot は実際に次のような回答を返せるようになりました。 設定の確認：「この案件の現在の設定はこうなっています」 エラーの一次切り分け：ジョブの実行状況を確認し「ここで失敗しています」 出力データの確認：「データは生成されています／されていません」 手順の案内：Confluence の正典ページを参照して手順を返す 挙動の確認：GitHub のソースコードを参照し「実際の動作はこうです」 文脈の把握：Slack のやり取りから状況を把握する そして、この Bot の最大の強みは合わせ技にあると考えています。たとえば「一般的な手順（Confluence）」と「その案件の現在の状態（管理画面・AWS）」を突き合わせ、1回の回答としてまとめて返すことができます。 固定的な FAQ との最大の違いはここにあります。ドキュメント・ソースコード・実データを組み合わせ、その案件に固有の一次回答を返せることが、実データを確認しにいくエージェントとして構築した狙いそのものでした。 運用して効果を感じた工夫 description を丁寧に書く ：custom tool の説明が不十分だと、モデルが道具を適切に選べません。「どのような場合に使うツールか」まで記述すると精度が向上しました。 参照範囲を固定する ：前述の「正典」ページの例と同様に、参照させる範囲を絞るほど誤読が減ります。 read-only の境界を保つ ：安全に展開できるため、社内に広げる際のハードルが下がります。 skill / memory store に過去事例を蓄積する ：類似の問い合わせに関するナレッジを蓄積し、次回以降の回答に活かしています。 成果 まだ試運転の段階ですが、当初ねらっていた形は実現できています。 一次調査の負荷が下がった ：これまで開発チームが都度、管理画面や AWS を確認して切り分けていた類型的な問い合わせについて、その最初の調査をエージェントが肩代わりできるようになりました。試運転として開発チームのチャンネルで運用し、これまでに約30件の実際の問い合わせへ一次回答を返しています。件数は多いが定型的な「まず状況を調べる」部分を任せられるようになったのが、大きな変化です。 回答が推測ではなく実データにもとづくものになった ：固定的な FAQ では「一般的にはこうです」までしか言えませんでしたが、6つの情報源（管理画面・AWS のジョブ実行状況・AWS の出力データ・Confluence・Slack・GitHub）を横断し、その案件の現在の状態まで確認したうえで回答できるようになりました。 回答品質を数値で追えるようになった ：実際の問い合わせを集めた32件の評価用データセットを用意し、回答を5つの観点・計10点満点で自動採点する仕組みを整えました。現時点の平均は8.1点／10点（32件中21件が合格ライン）です。この仕組みがあることで、「プロンプトやツールを直す → 同じデータセットで測り直す」という改善ループを、感覚ではなく数値で回せるようになりました。実際、点数の内訳を見ると「原因の特定」が弱点として表れており、次に何を直すべきかが具体的に分かります。 補足：採点の仕組み。 採点そのものも Claude に担わせています（いわゆる LLM-as-a-judge）。各問い合わせにはあらかじめ「期待される原因・対処」を正解として添えてあり、採点役はそれと Bot の回答を突き合わせて、次の5つの観点に各0〜2点をつけます。(1) 原因を特定できているか、(2) 対処が管理画面の正式な操作まで具体的か、(3) 申告した確信度は妥当か、(4) 開発へエスカレーションすべき場面を正しく見極められているか、(5) 読み手に伝わる構成か。合計10点満点で、8点以上を「合格」としています。単発のスコアは多少ぶれるため、絶対値そのものより「どの観点が弱いか」という傾向を読み、改善の的を絞るのに使っています。 散在していた知見が集約された（副次的な効果） ：エージェントに正しく答えさせるには、担当者の頭の中や個別のやり取りに散らばっていた運用知識を、参照可能な形に整える必要がありました。正典ページの整備や過去事例の蓄積を進めた結果、Bot のためだけでなく、人が参照する資産としても知見がまとまりました。 課題とこれから もちろん、まだ発展途上です。 対象範囲は、安全に広げられるところから段階的に拡大しています。本番データを扱う範囲については、アクセス制御の設計を前提に、慎重に進めていきます。 回答精度や確信度の調整は、引き続きの課題です。「自信がない場合にどう振る舞うか」の扱いは、今後詰めていきます。 そもそも Managed Agents 自体の事例がまだ少なく、運用しながら整備している状況です。 今後目指しているのは、確信度によって振り分けを行い、ビジネス職が自ら一次回答にたどり着ける状態です。「自信のある回答はそのまま返し、不確かなものは人へエスカレーションする」といった振り分けが実現できれば、より安心して任せられるようになると考えています。 最後に。Claude Managed Agents は、うまく活用すれば「実データを調べて答える」エージェントを現実的な工数で構築できる仕組みだと感じています。本記事が、これから導入を検討される方の一助になれば幸いです。

はじめに この記事で学べること 前提知識・条件 Kiro for iOS / Kiro for Web とは？ やってみた 準備: GitHub と接続する Step 1: Web 版でブランチを指定して開発を依頼する Step 2: iOS アプリで空き時間に Spec モードで開発する Step 3: 待っていたら PR ができる Step 4: GitHub Copilot でレビューしてもらう Step 5: 動作確認と Issue のループ まとめ はじめに こんにちは、アプリケーションサービス本部ディベロップメントサービス 1 課の森山です。３連休ですね！ 今回は2026 年 6 …