# AIエージェントには見張り役が要る：意図ベースのツール選択、WebMCP、検証の仕組み - 番組: [Agentic Conversations (formally mlops.community)](https://ai-curator.jp/podcasts/shows/cmv3z5c0n000l5o10j1ogyu9h)（Demetrios） - 元のタイトル: AI Agents Need a Babysitter - 配信日: 2026年10月24日 - 長さ: 45分 - 要約作成日: 2026年10月24日 - トピック: [#AIエージェント](https://ai-curator.jp/topics/AI%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#MCP](https://ai-curator.jp/topics/MCP) [#WebMCP](https://ai-curator.jp/topics/WebMCP) [#ツール選択](https://ai-curator.jp/topics/%E3%83%84%E3%83%BC%E3%83%AB%E9%81%B8%E6%8A%9E) [#監査性](https://ai-curator.jp/topics/%E7%9B%A3%E6%9F%BB%E6%80%A7) [#QAエージェント](https://ai-curator.jp/topics/QA%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) - URL: https://ai-curator.jp/podcasts/cmvl8efka00004h11xupc06gy ## 要約 AIエージェントに権限を渡すとき、その行動をどう監査し、仕事の出来をどう確かめるかを話した回。エージェントにツール名ではなく「意図」を宣言させ、小型の分類モデル（JEV）がツールを選ぶ案と、WebMCPとの組み合わせを議論する。後半は、ビジネス成果をテストに落とし込むCucumber型の検証、QAサブエージェント、OSSに流れ込むAI生成コードの問題へと進む。 ## ポイント - エージェントに利用可能なツールを見せず、「何を達成したいか」という意図だけを宣言させ、別の仕組みがツールを推薦する案が出た。これなら「なぜそのツールを呼んだか」まで監査できる。 - ビルダーのSteveによるベンチマークでは、JEVのコンピュータ操作の精度は33%にとどまった。しかもリトライ後の数字で、初回は18%だった。コスト面の利点も薄れ、小型モデルへのフォールバックを組み合わせる構成が提案されたという。 - WebMCPで各ページが新しいツールを公開するなら、ツール選択は分岐を進むスキルツリーのようになる。上位の数ツールと検索ツールだけを見せる設計も語られた。 - APIもMCPツールも、データ操作ではなくワークフローや成果を軸に設計すべきだという考え方（Jobs to be done）が示された。 - コードの存在理由をテストで残す手法として、ビジネス成果を記述するCucumber型のテストが紹介された。PR前にQAサブエージェントがスクリーンショット付きで検証する運用も語られた。 - OSSではAI生成コードが大量に届き、既存のCIすら通らないPRも多い。次回はこのテーマを扱う予定。 ## 章立て - [02:00] **意図ベースのツール選択という発想** — エージェントにツール一覧を見せず、達成したい意図だけを宣言させ、別のツール検索の仕組みが選ぶ案。ツール呼び出しの理由まで監査できるという利点が語られる。 - [06:17] **PiのMCP対応とJEVの活用** — Piハーネスがバージョンアップでorigin MCPをコアに取り込んだという話題を受け、JEVによるツール分類やMCP選択への応用を考える。 - [07:19] **ベンチマークで見るJEVの現実** — Builder.ioのSteveが行った検証では精度が33%にとどまり、リトライ込みでコスト優位も薄かった。小型モデルとのハイブリッド構成が提案された。 - [11:33] **WebMCPとツールのスキルツリー** — WebMCPでサイトがツールを公開し、ページ遷移ごとに新しいツールが現れる様子をペットショップの例で説明する。デバッグ専用サーバーでQAエージェントにサイトを試させる事例にも触れる。 - [20:06] **APIはワークフローと成果で設計する** — CRUD中心のAPI設計から、ワークフロー起点の設計への流れを整理し、Jobs to be doneの枠組みと重ねて議論する。 - [24:19] **コーヒー豆とパーソナルアシスタント** — 買い忘れや過剰在庫といった日常の「頭の中のタスク」をAIに任せたいという話から、家事・旅行手配・語学学習を担う個人アシスタントの潮流へ広がる。 - [34:45] **検証者（verifier）とCucumber型テスト** — エージェントが書いたコードの検証方法を議論する。ビジネス成果をテストに符号化するCucumberの考え方で、コードの存在理由を追えるようにする。 - [41:04] **QAサブエージェントとOSSへのAIコード流入** — PR前にサブエージェントがアプリ全体を検証しスクリーンショット付きで報告する運用や、既存テストすら通らないPRの問題、OSSメンテナの負担を話し、次回の予告で締める。 ## 解説記事 AIエージェントにコードを書かせ、ツールを選ばせ、旅行の手配まで任せる時代に、その仕事ぶりを誰がどう確かめるのか。ポッドキャスト「Agentic Conversations」の本回では、2人のホストが、エージェントの監査性、WebMCP、そしてAI生成コードの検証について語った。なお、文字起こしでは小型の分類モデルが「JEV」と表記されているが、正式名称は文字起こしからは確認できないため、本稿ではそのまま記す。 #### ツール名ではなく「意図」を宣言させる 出発点は、ホストの一人が朝の運転中に考えたというアイデアだ。エージェントは自分が使えるツールの一覧を知らず、代わりに「何を達成したいか」という意図とその理由を宣言する。その意図をもとにJEVがツールを推薦する。エージェントは、許可されていないツールを呼べないだけでなく、存在すら知らない。 この設計の利点として、2つが挙げられた。1つは、ツール説明や意図の書き方を評価し、改善できること。もう1つは、どのツールがいつ呼ばれたかだけでなく、なぜ呼ばれたかまで監査できることだ。ただし、エージェントが意図の情報をMCPサーバー側に渡してくれることが前提だと、話者は断っている。関連して、PiというハーネスがMCPをアドオンではなくコアに取り込んだという話題も出た。これにより、JEVによるツール分類をMCPの選択に組み込みやすくなると語られている。 #### JEVの精度は？ベンチマークの冷や水 一方で、話者はBuilder.ioのSteveによる検証を紹介した。コンピュータ操作でのJEVの正答率は33%にとどまり、その数字もリトライを重ねた結果で、初回は18%だったという。速くて安くて同程度に正確という触れ込みは、検証ではそのまま成り立たなかった。Steveが示した現実的な解は、まずJEVを試し、失敗したら小型のLLM（Haikuなど）にフォールバックするハイブリッド構成だという。 また、JEVは分類モデルなので、スクリーンショットのような入力を直接渡せないという制約も指摘された。プロンプトエンジニアリングやコンテキストエンジニアリングと同様に、JEVにも使いこなしの学習曲線があり、「JEVのせいでAI界隈の人々が古典的な機械学習を学び直している」という冗談めいた見方も紹介された。 #### WebMCPで道筋を絞る 話者が有望とみるのは、JEVとWebMCPの組み合わせだ。WebMCPは、Webサイトがエージェント向けにツールを公開する仕組みである。ボタンやリンクを手探りで押すより、サイトが「カートに追加」「カタログを見る」といった主要な経路をツールとして公開し、JEVが意図に基づいて選ぶほうが容易になる、という見立てだ。 ペットショップの例では、トップページで「犬用フード購入」「猫用フード購入」「アクセサリー」と検索ツールだけを見せ、犬用フードのページに進むと新しいツール（サイズや種類の選択、カート追加など）が現れる。ページごとに新しいツールが解放される様子は、ゲームのスキルツリーや決定木に例えられた。さらに、デバッグ専用のWebMCPサーバーを用意し、QAエージェントにサイトを自由に操作させて壊れ方を確かめるという使い方も紹介された。公開用ではなく、サイトの健全性確認のためのものだという。 #### APIは「成果」から設計する 議論はAPI設計にも及んだ。従来のAPIは作成・取得・更新・削除といった素のデータ操作を並べ、組み立ては利用者任せ、いわば「説明書のないレゴ」だった。近年は、システムが何を達成したいのかに沿ったワークフロー型のAPIが広まりつつある。WebMCPの議論は、既存APIをそのままMCPツールに変換するのではなく、ワークフローに焦点を当てる発想への転換を促す、と話者は述べた。ドリルではなく壁の絵が欲しい、掃除機ではなくきれいな床が欲しいという、Jobs to be doneの例えも使われた。 その延長で、「明日までに猫のえさが必要」といった制約や文脈をエージェントが理解できれば、配送が速い高めの商品を選ぶといった判断も任せられる、という話になった。コーヒー豆の買い忘れや定期便の過不足という身近な悩みから、富裕層が人に任せている「在庫管理の頭脳労働」を一般の人にも、という考え方（YC関係者の発言として紹介）や、パーソナル旅行代理店、語学チューターといったアシスタント像につながっている。 #### 検証者をどう作るか 後半は、エージェントが書いたコードをどう検証するかが主題となる。1つの手法として、Cucumberというテストフレームワークの考え方が紹介された。メソッドや機能の単体ではなく、ビジネス上の成果をテストとして記述する。たとえば新規ユーザーの登録は、DB作成だけでなく、権限設定、通知メール、チームへの所属まで含む。こうしたテストがあれば、「なぜエージェントがこのコードを書いたのか」を後から辿れる。話者は、この書き方には開発者自身がビジネスアナリストのように意図を言語化する力が要り、その経験を積んだ人がAI時代に力を発揮している、という見方も示した。 もう1つは、PR提出前にサブエージェントを立ち上げ、変更後のアプリ全体をテストさせる運用だ。ボタンを押して遷移先を確認し、スクリーンショット付きの文書にまとめ、壊れた箇所があれば修正する。人間のレビューを減らす狙いがある。 #### OSSに押し寄せるAI生成コード 最後に、OSSメンテナの視点が語られた。リントや既存テストすら通らないPRが開かれ、PR自体が不具合を示しているのに対応されないことがある。一部に有用な内容が含まれる場合は救うべきか悩む、とも述べられた。次回はAI生成コードの流入にOSSがどう対処しているかを扱う予定で、コード提出前に「なぜ自動的に却下されるか」を説明する検証エージェントというアイデアも出た。 #### まとめ 本回の中心は、エージェントに権限を渡すほど「見張り」の設計が重要になるという点だ。意図の記録による監査、ワークフロー志向のツール設計、成果をテストに残す検証は、いずれも「何をしたか」だけでなく「なぜしたか」を追えるようにする工夫である。一方で、JEVのベンチマーク結果が示すように、見栄えのよいデモが信頼できる自動化を意味するとは限らない。日本の開発者にとっては、ツール選択の前段に意図層を置く設計、成果ベースのテスト、PR前の自動QAは、すぐ試せる論点だろう。ただし本回の内容は雑談形式の議論であり、各手法の効果が実証されたわけではない点には注意したい。 > この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Agentic Conversations (formally mlops.community)「AI Agents Need a Babysitter」