L3次の一手はモデルに任せる。ただし、どの一手も人に見えるように

入社したばかりの運営担当者が聞きます。「先月のセールで、ノンフライヤーはどれくらい売れましたか？」

L2なら、この質問を「売上の照会」に分類し、決まった台本どおりに3つの質問を返します。L3はまず、相手がすでに何を言ったかを見て、足りないひとつだけを聞き、それから受注システムとBIのどちらからデータを取るかを自分で決めます。両者の違いは、聞き返すかどうかではなく、次の一手を誰が決めるかにあります。

前回は、問題をいくつかの手順に分ける必要があり、次の手順が前の手順の結果で決まるとき、L1とL2の決まった流れでは受け止めきれない、というところまで書きました。この記事ではL3を扱います。次の一手をモデルに任せること、そして任せたあとで、人が見て止められる場所をどこに残すかです。

この層から、次の一手はモデルが決める

L3を支える技術はFunction Callingと呼ばれ、AnthropicのドキュメントではTool Useと呼ばれています。流れは次のとおりです。

1. 開発者がモデルにツールの一覧を渡す。それぞれのツールの名前、何をするか、どんなパラメータが要るか。
2. ユーザーが依頼を出し、モデルがツールを使うかどうか、使うならどれを使うかを判断する。
3. モデルは答えを直接書くかわりに、構造化された呼び出しの依頼（ツール名とパラメータ）を出す。
4. アプリケーションがその依頼どおりに、実際の処理を実行する。
5. 実行結果をモデルに返し、モデルが最終的な答えを書く。

分かれ目は2番目の手順です。どのツールをいつ使うかを、コードに書き込んでおくのをやめて、モデルが決めるようになります。 Anthropicのドキュメントには、“Claude determines when to call a tool based on the user’s request and the tool’s description.”（ユーザーの依頼とツールの説明をもとに、Claudeがいつツールを呼ぶかを決める）とあります¹。L2も意図を見分けることはできますが、見分けたあとにどの道を進むかは、前もって書かれています。

厳密に言えば、ツールを一度呼ぶだけのL3は、Anthropicの言う「拡張されたLLM（augmented LLM）」に近く、結果を見ながらループの中でツールを呼び続けるものが、彼らの定義するAgentです。これは導入記事でも書きました。

最小のループ

私は、L3が一回ひととおり動くまでを「最小実行ループ（Minimal Execution Loop）」と呼んでいます。これは私がエンジニアリングの実践からまとめた記述的なフレームワークで、業界標準の用語ではありません。学術的にいちばん近いのは、プリンストン大学とGoogle Researchの研究者が2022年に提案したReActです。モデルに推論と行動を交互に行わせるというものです²。

flowchart LR
  A[意図を理解する] --> B[足りない情報を見つける]
  B --> C["[聞き返して補う]"]
  C --> D[ツールを選ぶ]
  D --> E[パラメータを埋める]
  E --> F[呼び出しを実行する]
  F --> G[結果を確かめる]
  G --> H[成果物を作る]
  G -- "結果がおかしければ戻る" --> B

このループの中で、モデルが自分で決めるのは「ツールを選ぶ」と「パラメータを埋める」の2つです。受注システムで調べるか、BIからレポートを引くか。期間を、会話のどの発言から取るか。聞き返しは、情報が足りないときに通る節目のひとつにすぎません。L2もあらかじめ用意した台本で聞き返せるので、聞き返しはL3を定義するものにはなりません。

L3は、ツールを一回だけ呼ぶこともあれば（データを一件調べて答える）、何回も続けて呼ぶこともあります（データを取り、指標を計算し、レポートを書く）。続けて呼ぶと、誤りが連鎖することがあります。これはあとで書きます。

聞き返せるシステム

聞き返すことはL3の定義ではありませんが、L3の聞き返し方はL2とは違います。L2の聞き返しは、決まったチェックリストです。「売上の照会」と判定したら、期間、チャネル、カテゴリーの順に聞きます。L3の聞き返しは、推論から出てきます。冒頭の運営担当者に、L3ならこう聞くかもしれません。

「あと2点確認させてください。直販だけを見ますか、それとも出店ストアも含めますか？　昨年の同じセールと比べますか？」

期間は相手がもう言っているので、聞き直しません。相手がふだん使わない分析の切り口を出してきたら、決まったテンプレートに無理に当てはめず、一言確認します。

作り方は2通りあります。ひとつは、どんなときに何を聞き返すかという運用の決まりを、システムプロンプトに書いておくこと。もうひとつは、「分析の範囲をはっきりさせる」こと自体をツールにして、情報が足りないときにモデルが自分から呼べるようにすることです。後者のほうが柔軟で、聞き返した記録も、あとで確かめられるように残せます。

入社したばかりの人にとって、こうした聞き返しにはもうひとつ使い道があります。聞き返されるたびに、ひとつの分析をきちんとやるにはどんな観点を考えればよいかを教わることになるからです。ベテランの頭の中にしかなかった経験が、システムの中の手引きになります。

モデルにツールを使わせるとき、境界をどこに置くか

まず、よくある誤解を解いておきます。Function Callingを使うからといって、モデルが自分でクエリを書くことが禁じられるわけではありません。Text-to-SQL（モデルにSQLを書かせて実行する）は、Function Callingの枠組みでよく使われるやり方のひとつです。気をつけるべきなのは、どんな環境で実行するか、人の審査があるかどうかです。

ツールそのものをどう設計するかも、結果を大きく左右します。Anthropicのエンジニアリングチームがいくつかの経験をまとめていますが³、業務に落とし込むうえで特に効くと私が思うのは2つです。

一つ目。ツールの説明の良し悪しで、モデルが正しく選べるかどうかが決まります。モデルは、ツールの説明を読んで使うかどうかを決めるからです。「get_data：データを取得」のような説明ではモデルが迷い、ツールが増えるほどそれがはっきり出ます。良い説明には、そのツールが何をするか、いつ使うか、いつ使うべきでないかを書いておきます。Anthropicの別の記事では、ツールの定義に呼び出しの例を添えたところ、社内のテストで複雑なパラメータの正確さが72%から90%に上がったと書かれています⁴。

二つ目。ツールはワークフローに沿って少なめに設計し、インターフェースごとに一つずつ包むことはしない。必要なら何段階かの操作をひとつのツールにまとめ、評価データで効果を確かめます。Anthropicが挙げている例では、list_users、list_events、create_eventを別々に用意するより、空いている時間を探して予定まで入れてくれるschedule_eventをひとつ用意するほうがよい、とされています³。

いちばん過小評価されている使い方：既存のシステムをAIに使いこなさせる

企業でのL3の使い方でいちばん過小評価されているのは、既存のシステムを置き換えずに、AIにそれを使いこなさせる方向だと私は思っています。

長く続いてきたECプラットフォームでは、受注、物流、問い合わせ管理、会員、BIと、どのシステムも何年も使われ、その裏に実際の業務の流れがつながっています。置き換えるコストは非常に高い。こういう環境では、「まったく新しいAIシステムを入れる」ことへの抵抗は、「AIに既存のシステムを使いこなさせる」ことへの抵抗よりはるかに大きくなります。

L3は、これにちょうど合っています。既存のシステムのインターフェースをツールとして包み、Agentがそのツールを呼び出して、熟練したオペレーターのように働く。システムを改修する必要はなく、データの正確さはこれまでどおり成熟したシステムが守り、AIは段取りだけを受け持ちます。IT部門から見れば、既存のシステムに賢い使い手がひとり増えるようなもので、話を進めるときの抵抗もずっと小さくなります。

このための基盤が、Anthropicが2024年11月に公開したModel Context Protocol（MCP）です⁵。AIアプリケーションが外部のデータやツールにどうつながるかを決めた、オープンな標準です。それまでは、システムをひとつつなぐたびに、専用の接続コードを書く必要がありました。システムがN個、AIアプリがM個あれば、保守すべきコネクタの数はN×Mになります。MCPは、これをひとつの共通のプロトコルで解決します。公式ドキュメントは、これを「AIアプリケーションのUSB-Cポート」にたとえています⁶。2025年12月には、ChatGPT、Gemini、Microsoft Copilotなど主要なAI製品がすでにMCPに対応していて、Anthropicはこのとき、Linux Foundationのもとに新しく設立されたAgentic AI FoundationにMCPを寄贈しました⁷。

ECプラットフォームに当てはめれば、受注、物流、問い合わせ管理、会員といったシステムを、同じプロトコルで同じL3 Agentにつなげられるということです。システムごとに統合の層を別々に開発する必要はありません。

ユーザーに見えて、止められるように

L1とL2のやりとりは単純です。質問を入れて、答えを見る。L3にはもう一層あります。モデルは裏で、ツールを選び、パラメータを埋め、インターフェースを呼び、結果を確かめるという一連の動作をしているのに、ユーザーにはまったく見えません。コードを書かない業務の担当者にとっては、ここから2つの問題が生まれます。信頼できないこと（「何をしているのか？　この数字はどこから来たのか？」）、そして直しようがないこと（「結果がおかしいが、どの段階で間違えたのか分からない」）です。

だからL3の画面がやるべきなのは、裏でのツールの呼び出しを、業務の言葉でユーザーの前に並べることです。 私は4つの層に分けて作ります。

一つ目の層は、過程を見せることです。インターフェースやパラメータを表示するかわりに、「受注システムから、先月のセール期間中のノンフライヤーの販売数を取得しています……」と伝えます。ユーザーはインターフェースを理解する必要はありません。システムがきちんと処理していることが分かれば十分です。

二つ目の層は、パラメータの確認です。モデルが会話からパラメータを取り出したら、実行する前に、ユーザーに一度見せます。

計算資源を使う前にパラメータの誤りに気づければ、あとで間違ったレポートを見つけるよりずっと手間が少なくてすみます。

三つ目の層は、下書きの確認です。これは書き込みの操作のためのものです。メールの送信、下流のシステムへのデータの送出、会員記録の変更、正式なレポートの作成。実行する前に、まずプレビューを人に見せます。

これは、Anthropicの『Building Effective Agents』の勧めとも重なります。Agentはチェックポイントで止まり、人のフィードバックを待てる、というものです⁸。画面に落とし込めば、取り消せない操作の前には、必ず人が最後に確認する場所を残しておく、ということです。

四つ目の層は、結果の出どころを示すことです。主な数字の横に、出典と時点を書きます。たとえば「セール期間中のノンフライヤーの販売数は前年同期比18%増（出典：受注システム、9月15日時点）」。これで人は安心できますし、データに誤りがあったときにたどる道も残ります。

同じ結果でも、読む人に合わせて形を変えられます。店舗の運営担当者には、スマートフォンの一画面で読み切れる速報を。カテゴリーの責任者には、比較グラフ付きのレポートを。やり方は、レポートを作るツールに「誰が読むか」というパラメータを加え、ユーザーの立場に応じてモデルに選ばせることです。

よくある3つの失敗

Agentに手を動かす権限を渡すと、誤りは「言い間違い」から、実際の操作ミスに変わります。

• パラメータのハルシネーション：モデルがパラメータを取り出すときに間違えます。たとえば「昨年の第4四半期」を違う年に当てはめる、地域名を違うコードに当てはめる、など。いちばん効く対策は、上の二つ目の層、つまり実行前に人がパラメータを確認することです。
• 連鎖する誤り：いくつかのツールを続けて呼ぶとき、最初の段階でデータの期間を取り違えると、その後の伸び率はすべて誤った基準の上に立ちます。最後のレポートの結論は事実から大きく外れているかもしれないのに、各段階を単独で見ると「間違っていない」。対策は、要所でいったん止まり、途中の結果を人に見せて、問題がないと確かめてから先に進むことです。ツールを一回しか呼ばないなら、この問題は起きません。
• 権限の踏み越え：ツールの権限が広すぎたり、説明があいまいすぎたりすると、Agentが誘導されて（意図しないあいまいさによって、あるいは悪意のあるプロンプトインジェクションによって）、触れてはいけないデータに触れることがあります。対策は最小権限です。各ツールには必要な権限だけを与え、読み取り用のツールと書き込み用のツールを分け、書き込みには必ず独立した審査を通します。

こうした対策の上に置く私の原則は、単純です。データを読む、分析するところまではAgentに任せてよく、あとから確かめられます。メッセージを送る、記録を変える、データを送り出すときは、必ず先に下書きを出し、人が確認してから実行します。

L3にできないこと

限界1：すべての途中結果が、ひとつのコンテキストに詰め込まれる

ひとつの依頼で、互いに独立したいくつかのシステムを同時に調べる必要があるとき、L3の単一Agentは、一回のやりとりの中で複数のツール呼び出しを出し、アプリケーションに並行して実行させることができます。2026年10月時点で、ClaudeとOpenAIのAPIはどちらも、標準でこれを許しています⁹。ですから、「順番にしか処理できない」ことはL3のボトルネックとは言えません。

L3の本当のボトルネックは、すべての途中結果がひとつのコンテキストに詰め込まれることです。「異常のある返金の案件をひとつ処理する」場合を例にとります。財務の入出金記録を確かめ、配送状況を確認し、顧客の履歴を見る。どの線も何段階もの調査とそれぞれの判断が必要なら、コンテキストはあっという間に膨らみ、いくつもの手がかりが互いに干渉し合います。

ここで初めて、L4のやり方のほうが合うようになります。サブAgentにそれぞれ独立したコンテキストで作業を進めさせ、オーケストレーションの層がまとめる。Anthropicが自社でマルチエージェントの調査システムを作った理由のひとつも、サブAgentがそれぞれ自分のコンテキストウィンドウを持って、並行して働けることでした¹⁰。

限界2：実行の経路を前もって並べられないタスク

L3のツールは、どれも前もって用意されたものです。まったく新しい状況で、道具箱に合うツールがないとき、Agentはその場で新しい実行の経路を「発明」することはできません。L3が得意なのは、分かっている境界の中で柔軟に組み合わせることです。未知の場所を自分で探索するのは得意ではありません。

限界3：目標がぶつかるとき、牽制する者も、裁定する者もいない

ひとつのタスクに互いに衝突する複数の目標があるとき（たとえばセールの商品ページで、マーケティングは売りをもっと強く打ち出したいが、法務は断定的な表現をすべて削りたい）、単一のAgentは、ひとつのプロンプトの中で両方の立場を同時に代弁するしかありません。衝突はAgentの中で黙って処理され、どちらが譲ったのか、なぜ譲ったのかが見えなくなります。

限界2はL5の話題です。限界1と限界3はL4につながります。いくつかのAgentにそれぞれのコンテキストで作業を進めさせ、それぞれにひとつの目標を代弁させ、オーケストレーションの層がまとめて、最後にルールか人が裁定する。これは次回、詳しく書きます。

おわりに

冒頭の、入社したばかりの運営担当者に戻ります。L3は本人に代わって足りなかったひとつを聞き返し、受注システムとBIから自分でデータを取り、速報を書き上げました。それでも送る前には手を止めて、本人に一度見せました。

L3が使えるものになるかどうかは、多くの場合3つのことで決まります。ツールの境界がはっきりしているか、過程が見えるか、書き込みの前に人の確認を挟んでいるか。Anthropicが『Building Effective Agents』で勧めていることも同じです。問題を解決できるいちばん簡単な方法をまず探し、本当に必要になったときだけ複雑さを足す⁸。

ひとつのタスクに互いに衝突する複数の目標があり、異なる視点で牽制し合い、最後に誰かが裁定する必要が出てきたら、そこがL3の境界で、L4の入り口です。並列呼び出しや複数システムをまたぐだけなら、L3でもまだ続けられます。