L3：「語る」から「動く」へ——Agentにアクション実行と動的ガイダンスの能力を与える

一、L3の本質：重要なアーキテクチャの分岐点

L1〜L5のスペクトラム全体において、L3は重要な分水嶺です。シリーズ導入記事ですでに明確にしているとおり：L3から、LLMは自身の実行パスを主導し始める——これがAgentとしての振る舞いの真の出発点です。

この「出発点」を支える技術的基盤が、Function Calling（AnthropicのAPIドキュメントではTool Useと呼ばれています）です。

Function Callingの動作方式は、LLMに質問して答えを待つのとは根本的に異なります。その流れはこうです：

1. 開発者がモデルに一連のツール定義（構造化された記述：ツール名・機能説明・パラメータスキーマ）を提供する
2. ユーザーがリクエストを送ると、モデルが自律的に判断する：このタスクにはツールの呼び出しが必要か？必要なら、どのツールを呼ぶべきか？
3. モデルは直接テキストの回答を生成するのではなく、構造化された呼び出し意図（ツール名とパラメータを指定したもの）を出力する
4. あなたのアプリケーションがその意図を受け取り、対応する関数またはAPIを実際に実行する
5. 実行結果をモデルに返し、モデルが最終的な自然言語の回答を生成する

このメカニズムの核心は第2ステップにあります：何をするかを決めているのはモデルであり、外部のコードではない。 これはL2のルーティングロジックとは本質的に異なります——L2では、LLMが意図を識別した後に事前設定されたスクリプトを起動し、実行パスは外部にハードコードされています。L3のLLMは、実行時に動的に呼び出しパスを決定します。Anthropicの公式ドキュメントは、この能力をこう表現しています：“Claude decides when to call a tool based on the user’s request and the tool’s description.”¹

この自律的なスケジューリング能力こそが、L3がAgentの出発点である理由です。

二、動作メカニズム：最小実行ループ

L3の完全な動作ロジックを描くために、ひとつの分析フレームワークを導入します——最小実行ループ（Minimal Execution Loop）。これは筆者がエンジニアリングの実践から帰納した記述的フレームワークであり、業界標準の用語ではありません。学術的な対応物としては、Google Researchが2022年に提唱しICLR 2023で発表したReActパラダイム（Reasoning + Acting）があります²——「推論の軌跡」と「行動の実行」を交互に走らせることの有効性を初めて体系的に論証した研究です。

L3の完全なループは以下のとおりです：

          
flowchart LR
  A[意図を理解する] --> B[情報のギャップを識別する]
  B --> C["[追加質問で補完]"]
  C --> D[ツールを選択する]
  D --> E[パラメータを入力する]
  E --> F[実行・呼び出す]
  F --> G[結果を検証する]
  G --> H[成果物を生成する]
  
  G -- "結果に異常があればフィードバック" --> B

        

このループにはいくつかの重要な特性があります。

自律性はどこに現れるか：追加質問の部分ではなく、「ツールを選ぶ」と「パラメータを入力する」この2ステップです。LLMがget_sales_dataを呼ぶかget_competitor_reportを呼ぶかを自律的に決め、対話のコンテキストから正しいパラメータ値をどう抽出するかを判断する——これがL3をL2と区別するコアです。

単ステップ vs. 複数ステップ：L3は単回のツール呼び出し（データを1件取得して回答する）にも、チェーン呼び出し（データ取得→分析→レポート生成）にも対応できます。単回呼び出しはL3の基本形態であり、チェーン呼び出しは「連鎖エラー」のリスクを伴います。詳細は第八節で述べます。

追加質問は機能であり、定義ではない：追加質問（Slot Filling / Clarification）は、情報が不完全なときにループに現れるノードのひとつです。L2でも（事前設定された追加質問スクリプトを通じて）実現できます。追加質問をL3の定義的特徴と見なすのは、アーキテクチャの誤読です。

三、L3の「口」：動的ガイダンスと情報の補完

追加質問はL3の定義的特徴ではありませんが、L3は情報収集においてL2にはない能力を持っています——業務コンテキストに基づく動的な追加質問です。

L2の追加質問 vs. L3の追加質問の違い

L2の追加質問は事前設定のロジックに依存しています：システムがユーザーの意図を「売上照会」と識別すると、固定の質問リストが起動します。質問項目は固定で、順序も固定で、対話の内容に応じた調整はできません。

L3の追加質問はLLMが動的に生成します。ユーザーが「A薬の関東エリアでのパフォーマンスを分析して」と言ったとき、L3 Agentはすぐに実行するのではなく、標準的な分析を実行するために必要な構造的なギャップを識別します：

「標準的な分析フローに基づき、いくつか確認させてください。1. 期間は昨年Q4ですか、それとも通年でしょうか？ 2. 競合B薬の同期データとの比較は必要ですか？ 3. 分析の軸は販売数量のみですか、それともカバレッジ率や成長率も含めますか？」

この追加質問の違いは：テンプレートではなく、推論による質問だということです。 ユーザーの説明にすでに期間が含まれていれば、LLMは重ねて聞きません。ユーザーが非標準の分析軸に言及していれば、標準テンプレートに無理やり当てはめるのではなく、追加で確認します。

技術的な実装

この動的な追加質問の実装には、一般的に2つのアプローチがあります：

• システムプロンプトのアプローチ：SOPを構造化されたガイダンスロジックに変換し、システムプロンプト（System Prompt）に書き込む。「どんな状況でどんな追加質問をすべきか」を記述する
• ツール化のアプローチ：情報収集そのものをひとつのツール（例：clarify_analysis_scope）として定義し、LLMが情報不足と判断したときに能動的に呼び出す

前者は実装がシンプルで、後者はより柔軟です。追加質問の記録を監査フローに組み込む必要があるシナリオ（医療・金融など）には後者が適しています。

非技術系ユーザーへのビジネス的価値

入社したばかりのマーケティング担当者にとって、Agentの一つひとつの追加質問は、暗黙の業務規範トレーニングになります——完全な分析を行うにはどんな観点を考慮すべきかを、システムが教えてくれるのです。これは、これまでベテラン社員の頭の中だけにあった経験を、システム的なガイダンスロジックへと変換します。

四、L3の「手」：制御されたツール実行

L3アーキテクチャの中で技術的に最も複雑で、かつ最も落とし穴にはまりやすい部分です。

Function Callingの実行境界

「LLMに何を実行させるか」を議論する前に、よく誤解されるひとつの問題を整理しておく必要があります：Function Callingは、LLMがコードやクエリ文を生成することを禁止することを意味するわけではありません。

Text-to-SQL（LLMにSQLを生成させて実行させる）は、Function Callingフレームワーク下における成熟した広く採用されているパラダイムであり、BIツールやデータ分析プラットフォームですでに大量に実用化されています³。

本当に慎重にすべきなのは「LLMがSQLを書けるかどうか」ではなく、どんな環境で実行するか、レビューの仕組みがあるかどうかです。設計原則はこう整理できます：

この設計の本質は、LLMの能力と本番データの間に適切な粒度のサンドボックスを挟むことです——LLMによるクエリロジックの生成を一律に禁止することではありません。

ツールボックスの設計：見落とされがちな2つの原則

Function Callingの実際の効果は、ツールボックスの設計品質に大きく左右されます。Anthropicエンジニアリングチームは《Writing Effective Tools for AI Agents》⁴にいくつかの知見をまとめており、業務への適用において特に重要な2点を取り上げます：

原則1：ツールの説明文の質が選択精度を決める。 LLMはツールのdescriptionフィールドを読んで呼び出すかどうかを判断します。曖昧な説明（例：get_data: データを取得する）はモデルに判断の迷いを生じさせ、ツールの数が多い場合は特に顕著です。明確な説明では、このツールが何をするか・どんなシナリオに適しているか・どんな場合は適さないかを説明すべきです。Anthropicの内部テストでは、ツール使用例（Tool Use Examples）を追加した後、複雑なパラメータ処理の正確率が72%から90%に向上したことが示されています⁴。

原則2：ツールの粒度にはトレードオフがある。 細粒度のツール（各ツールがひとつのことだけを行う）は安全性が高く、制御が失われた場合の範囲も小さく、パラメータもシンプルです。しかし複雑なタスクでは複数回の呼び出しが必要で、コンテキストの消費が大きくなります。粗粒度のツール（ひとつのツールが複数の状況を処理する）は呼び出し回数が少なくなりますが、パラメータが複雑でLLMが誤入力しやすくなります。一般的な推奨は：細粒度から始め、評価データに基づいて統合を判断する——直感でツールの境界を設計しないことです。

ワークフローのオーケストレーション例

複数ステップを連結するツール呼び出しが必要な場合、典型的なL3チェーン型ワークフローは以下のようになります：

各ステップの入力は前のステップの出力から来ており、各ステップは事前定義された制御済みのインターフェースです。LLMの役割はスケジューラーであり、データベースを直接操作するプログラマーではありません。

五、最もビジネス価値の高いL3シナリオ：既存のITアセットを活性化する

これはL3の企業導入において最も低く見積もられがちですが、実際には最も戦略的な価値を持つ方向性です：AIに既存の企業ITシステムの使い方を学ばせること——それらを置き換えるのではなく。

なぜこの方向性が規制業界で特に重要なのか

製薬・金融・保険などの業界は、共通した現実的な課題を抱えています：既存のITシステム（CRM・ERP・BIプラットフォーム・コンプライアンスツール）は長年にわたって検証され、コアとなる業務フローに組み込まれており、置き換えコストは非常に高く、規制当局の認証を取り直すことも容易ではありません。このような環境では、「全く新しいAIシステムの導入」は「AIに既存システムの使い方を学ばせること」よりも、はるかに大きな抵抗に直面することが多いです。

L3のFunction Callingアーキテクチャはこのニーズに自然に適合します：既存ITシステムのAPIをツールとしてラップし、Agentはこれらのツールを呼び出すことで人間のオペレーターの行動を模倣します。

これが意味することは：

• CRMシステムを改修する必要はなく、AgentはすでにあるAPIを通じて顧客データを読み取る
• BIプラットフォームを再構築する必要はなく、Agentはすであるクエリインターフェースを通じてレポートを取得する
• コンプライアンスシステムは影響を受けず、Agentはコンプライアンスインターフェースの権限境界内で操作する
• データの真正性と正確性は引き続き成熟したシステムが保証し、AIはスケジューリングロジックだけを担う

MCP：この方向性のインフラ標準

AIとITアセットの統合における工学的な複雑さを解決するため、Anthropicは2024年11月にModel Context Protocol（MCP）⁵を発表しました——AIシステムと外部データソース・ツールとのやり取りを標準化することを目的としたオープン標準です。

MCP以前は、新しいシステムを接続するたびにカスタムのコネクターコードを書く必要がありました。Anthropicはこれを「N×M統合問題」と呼んでいます——Nのデータソースにかけるぞれと互換性をMのAIシステムと持たせると、メンテナンスコストが指数関数的に増大します。MCPはこの問題を統一されたプロトコルで解決し、「AI統合領域のUSB標準」と呼ばれています⁶。

現在、MCPはOpenAI・Google DeepMindに採用され、2025年12月にはAnthropicによってLinux Foundation傘下のAgentic AI Foundation（AAIF）に寄贈され、事実上の業界標準となっています⁷。Google Drive・Salesforce・Slack・GitHub・Postgresなど主要な企業システム向けの事前構築済みMCPサーバーもすでに存在します。

製薬企業にとってこれが意味するのは：Veeva（業界トップCRM）・社内BIシステム・保険政策データベースをすべて、標準MCPプロトコルを通じて同一のL3 Agentに接続でき、システムごとに統合レイヤーを個別開発する必要がなくなるということです。

変革マネジメントへの戦略的意義

導入を推進する観点から、「既存ITアセットの活性化」という方向性のもうひとつの利点は変革への抵抗を下げることです。IT部門の視点から見れば、「新しいシステムに置き換えられる」のではなく「既存システムがよりインテリジェントな使い手を得た」ということになります。このポジショニングは、部門をまたいだ協力の摩擦を大幅に減らします。

六、役割への適応：同じ分析を「相手によって使い分ける」

製薬業界の内部では役割の差異が非常に大きく、同じ分析データでも役割によって価値の受け取り方は大きく異なります。L3のツール呼び出しアーキテクチャにより、「ひとつの分析ロジックで複数の納品フォーマットを生成する」ことが可能になります。

これはどのように技術的に実現されるのか？

役割適応の実装は、通常Function Callingのツール定義に「出力対象役割」パラメータを導入することで行います。Agentはユーザーの役割タグ（権限システムまたは対話コンテキストから取得）に基づき、異なるフォーマット化ツールを選択して呼び出します：

# ツール定義の例（簡略化）
tools = [
    {
        "name": "generate_report",
        "description": "分析データに基づき、役割に適応したレポートを生成します。同一のKPIデータを異なるフォーマットに変換する際に使用します。",
        "input_schema": {
            "kpi_data": "object",
            "target_role": {
                "type": "string",
                "enum": ["rep", "manager", "executive"],
                "description": "対象ユーザーの役割。出力フォーマットと詳細度を決定します"
            }
        }
    }
]

generate_report(target_role="executive")は3ページのPPTテンプレートを呼び出し、generate_report(target_role="rep")はモバイル向けブリーフのテンプレートを呼び出します。同じデータ、異なるツール呼び出し、まったく異なるフォーマットを出力する——人が手動でレイアウトし直す必要はありません。

七、UI/UXデザインのポイント：非技術系ユーザーのためのL3体験設計

これはL3の実装において最も見落とされがちな部分であり、非技術系ユーザーがシステムを本当に使いこなせるかどうかを決める鍵でもあります。

L3がもたらすL1/L2にはなかったUI上の課題

L1/L2では、ユーザーのインタラクションは比較的シンプルです：質問を入力して、回答を見る。しかしL3は新たな複雑さをもたらします：モデルが舞台裏で一連のアクションを実行しています——ツールを選択し、パラメータを入力し、APIを呼び出し、結果を検証する——ユーザーはこのプロセスをまったく把握していません。

技術系のユーザーにとっては問題でないかもしれませんが、非技術系のビジネスパーソン（マーケティングマネージャー・現場担当者）にとって、この「ブラックボックス感」はふたつの問題を引き起こします：ひとつは不信感（「AIは何をしているの？数字はどこから来たの？」）、もうひとつは修正不能（「結果がおかしいけど、どのステップで間違えたかわからない」）です。

したがって、L3のUI/UXデザインの核心的なタスクは、バックエンドのツール呼び出しプロセスを、業務の言葉でユーザーに視覚的に伝えることです。

4層のUXデザインフレームワーク

ユーザーがプロセスの異なる段階で持つニーズに応じて、L3のUXは4つの層に分けることができます：

第1層：プロセスの透明性（Process Transparency）——最も重要な層であり、L3に固有のデザイン上の課題でもあります。

システムはツール呼び出しのプロセスを、技術的な詳細を露出するのではなく、ユーザーが理解できる言葉に翻訳すべきです：

この「進捗の可視化」デザインにより、ユーザーはAgentが何をしているかを把握でき、システムへの信頼感が生まれます。ユーザーがAPIを理解する必要はなく、「システムが真剣に自分のリクエストを処理している」と感じられれば十分です。

第2層：パラメータ確認画面（Parameter Review）——実行前にAgentの「理解」が正しいかをユーザーが確認できるようにします。

Agentが自然言語の対話からパラメータを抽出した後、軽量な確認ビューをユーザーに提示すべきです：

この画面はL3で最も多く発生するパラメータのハルシネーション問題に対処します：算出リソースを消費する前にパラメータの誤りをユーザーに発見させることは、エラーレポートを事後に見せるよりずっと効率的です。

第3層：下書きレビュー（Draft & Review）——「書き込み操作」（実際の影響を生じさせる操作）に特化した確認メカニズムです。

「書き込み操作」には：メールの送信・データの下流システムへの推送・CRMレコードの更新・正式レポートの生成などが含まれます。これらの操作が実行される前に、必ずプレビュー画面を提供しなければなりません：

これはAnthropicの《Building Effective Agents》⁸が明確に推奨する「Human-in-the-loop」設計原則をUI層で具体化したものです：不可逆な操作を実行する前に、常に人間が最後にコントロールできる余地を残す。

第4層：結果の出典表示（Result Attribution）——データがどこから来たかをユーザーに知らせます。

Agentが分析結論を出力するとき、重要なデータポイントにはソースの注記を付けるべきです：

これは信頼性を高めるだけでなく、データ品質の問題に対する追跡経路も提供します。

非技術系ユーザーへの追加デザイン推奨事項

• 業務の言葉を使い、技術的な詳細を隠す：パラメータ名はdate_rangeではなく「期間」、地区の選択はコード入力欄ではなくクリッカブルな地図にする
• 段階的な情報開示：まず高レベルの「処理中」状態を表示し、ユーザーがクリックして詳細なステップを展開できるようにする
• エラーメッセージのビジネス言語への翻訳：APIタイムアウトはユーザーに”timeout error”と表示するのではなく、「CRMシステムの応答が遅くなっています。リトライ中…」と伝える

八、リスクへの警告：L3における3つの失敗モード

Agentに実行権限を与えることは、エラーが「会話の間違い」にとどまらず、実際の操作ミスになることを意味します。

失敗モード1：パラメータのハルシネーション（Parameter Hallucination）

LLMはパラメータを抽出する際に誤りを犯す可能性があります。よくある例：

• 「昨年Q4」を「2024年Q4」ではなく「2023年Q4」と解釈する（LLMのトレーニングデータの時間的なバイアスが原因）
• エリア名を誤ったエリアコードに対応させる
• 対話に曖昧さがあるとき、誤ったデフォルト値を選択する

対処策：

1. 第2層のUI（パラメータ確認画面）を導入する
2. ツール呼び出しの前にパラメータ検証層を追加し、合理的な範囲を外れた値を自動的にインターセプトする
3. よく使うクエリ条件に「業務用語辞書」を構築し、自然言語の表現を標準パラメータ値にマッピングする

失敗モード2：チェーン呼び出しでのエラー伝播（Error Propagation in Chained Calls）

L3が複数ステップのチェーン型ツール呼び出しを実行するとき、第1ステップのズレが後続ステップで増幅されます。第1ステップでデータの期間を誤って取得すると、第2ステップの成長率計算は誤った基準値に基づくことになり、最終的なPPTの結論は事実から大きく外れる可能性があります——しかも各ステップを単独で見ると「正しい」ように見えます。

特に注記すべきは：この問題は主にチェーン呼び出しのシナリオで発生するものであり、L3のすべての適用場面ではありません。単回のツール呼び出し（1件のデータを取得して回答する）にはこのリスクはありません。

対処策：

1. チェーン呼び出しの重要なノードで中間結果の検証を追加する（例：データ取得後にまずデータのサマリーを表示し、問題がないことを確認してから計算を続ける）
2. 「べき等」なツールを設計する——同じ入力は常に同じ出力を生成し、問題の再現とデバッグを容易にする
3. 完全なツール呼び出しチェーンのログを記録し、事後監査を可能にする

失敗モード3：権限の逸脱（Permission Escalation）

ツールインターフェースの権限設計が広すぎる場合、またはツールの説明が不十分な場合、Agentは（Promptの曖昧さによる無意図的なものであれ、Prompt Injectionによる悪意あるものであれ）アクセスすべきでないデータにアクセスしたり、実行すべきでない操作を実行するよう誘導される可能性があります。

対処策：

1. ツールの権限は最小権限の原則に従う——各ツールはその機能を完了するために必要最小限の権限のみを持つ
2. 読み取り専用ツールと書き込み操作ツールを厳格に分離し、書き込み操作ツールは独立したレビュー層を必ず経る
3. MCPレイヤーでアクセス制御を実装し、アプリケーション層だけで制御しない
4. ツール呼び出しの監査ログを作成し、コンプライアンス要件を満たす

Human-in-the-Loop：高規制業界の標準構成

製薬・金融・保険などの業界では、上記のリスクのコストは技術の範囲を超えることが多いです（規制コンプライアンス・患者の安全・資金損失）。そのため、「人在回路」（Human-in-the-Loop）はパッチではなく、アーキテクチャ設計の一部です。

具体的な実装では、2種類の操作を区別することを推奨します：

• 読み取り操作（データ読み取り・分析生成）：Agentに自律的な実行を許可し、事後に確認可能にする
• 書き込み操作（コミュニケーション送信・レコード更新・データ推送）：Draft & Review画面を必ず経て、人による確認後に実行する

九、L3の限界：できないこと

アーキテクチャの限界を理解することは、その能力を理解することと同じくらい重要です。以下はL3の単一Agentアーキテクチャの構造的な制約であり、最適化によって解決できる工学上の問題ではありません。

限界①：複数システムにまたがる並行タスクを自律的に調整できない

あるビジネスリクエストが複数の独立したシステムを同時に呼び出して結果を集約する必要がある場合、L3の単一Agentは効率上の限界に直面します。

「異常な返金ケースを処理する」を例に取ると：財務の記録（財務システム）・配送状況（物流システム）・顧客の履歴（CRM）を同時に確認する必要がある場合、L3は直列処理しかできません——まず財務を照会し、結果を待ち、次に物流を照会し、結果を待ち、それからCRMを照会します。応答時間はタスク数に比例して線形に増加します。

このようなシナリオには、L4のマルチAgent並列オーケストレーションアーキテクチャの方が適しています。

限界②：実行パスを事前に列挙できないタスクを処理できない

L3のツール呼び出しは事前定義されたツールボックスに依存しています。つまり、ツールボックスに対応するツールが存在しない全く新しいビジネスシナリオに直面した場合、Agentはその場で新しい実行パスを「発明」することはできません。

言い換えれば：L3は既知の境界内での柔軟な組み合わせには長けていますが、未知の境界の中での自律的な探索はできません。業務がAgentにこれまで見たことのない問題タイプに自律的に解決策を見つけさせることを求めるとき、L3では力不足です。

限界③：役割と職責の調整の複雑さに限界がある

複雑なタスクが異なる専門的役割の分業と協力を必要とする場合（例：医療情報Agentがデータを担当し、コンプライアンスAgentが審査を担当し、フォーマットAgentが出力を担当するなど）、L3の単一Agentアーキテクチャはこのような職責分担の内在する複雑さを支えることが困難です。すべてのロジックをひとつのAgentに詰め込むと、ツールボックスが肥大化し、システムプロンプトが制御不能になり、デバッグが困難になります。

これら3つの限界は同じひとつの問題を指し示しています：タスクの複雑さが「単一のAgentが事前定義されたツールボックス内で自律的にスケジューリングする」という範囲を超えたとき、新しいアーキテクチャが必要です——複数の専門化されたAgentが分業し、オーケストレーション層が統一的に調整する仕組みです。これがまさにL4の協調オーケストレーションアーキテクチャが解決しようとする問題であり、次の記事で詳しく取り上げます。

十、おわりに

L3は、Agentが「おしゃべりな百科事典」から「制御された境界の中で実際に仕事をこなすデジタルアシスタント」へと進化したことを示しています。しかしこの進歩は、リスクと限界への明確な認識の上に成り立つ必要があります。

本稿で描いたシナリオにおいて、長期的に安定して動作するL3システムとは、往々にして最も「賢く」設計されたものではなく、ツールボックスの境界が明確で、プロセスがユーザーに透明で、高リスクな操作の前には常に人による確認を残し、既存のITアセットとシームレスに統合されているシステムです。

Anthropicエンジニアリングチームが《Building Effective Agents》でまとめているように：成功するLLMアプリケーションは、最も複雑なシステムを構築することにあるのではなく、現在のニーズに適した正しいシステムを構築することにあります。⁸

あなたのビジネスニーズが「単一Agentが事前定義されたツール内でスケジューリングする」能力の範囲を超えたとき——タスクが複数の役割による並列協力を必要とし、複数システムにまたがる動的な調整が必要になったとき——それがL3の限界であり、L4の入口に立っている瞬間です。