LoginSignup
8
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@RepKuririn(Daiki Kuribayashi)

Anthropic: 従来のソフトウェア開発手法ではAIエージェントの未来が「終わる」。非確定的システムに対応する、協調型開発へのパラダイムシフト

Posted at

目次

Part 1: AIエージェントとツールの新しい関係

Part 1の要約

このパートでは、AIエージェントの性能が、提供される「ツール」の品質に大きく依存するという事実から話を始めます。そして、エージェントのためのツール開発が、従来のソフトウェア開発と根本的に異なる理由を、「確定的システム」と「非確定的システム」という概念を用いて明らかにします。

Chapter 1.1: はじめに - なぜ今、エージェントのツールが重要なのか

Core Message: AIエージェントの真価は、私たちが与えるツールの質によって決まります。効果的なツールを開発することが、エージェントが複雑な現実世界のタスクを解決するための鍵となります。

  • 結論:
    LLM（大規模言語モデル）を搭載したAIエージェントは、Model Context Protocol (MCP) などを通じて数百ものツールを扱える潜在能力を持っています。しかし、その能力を最大限に引き出すためには、ツール自体をエージェントにとって「使いやすく、効果的」なものにする必要があります。本記事では、エージェント自身と協力してツールを最適化するという、新しい開発アプローチを探求します。

  • 主要なポイント:

    1. プロトタイプの構築とテスト: まずは迅速にツールの試作品を作ります。
    2. 包括的な評価の実行: 作成したツールをエージェントがどれだけうまく使えるかを体系的に評価します。
    3. エージェントとの協調: Claude Code のようなエージェントと協力し、ツールのパフォーマンスを自動的に向上させます。

  • 具体例:
    エージェントは、メール送信、レポート検索、スレッド要約、スパムメール削除といった多様なタスクを実行できます。これらの各タスクの成功率は、対応するツールの設計に大きく左右されます。

Chapter 1.2: 従来開発との違い - 確定的システム vs 非確定的システム

Core Message: エージェントのためのツール開発は、予測可能な結果を生む従来のソフトウェア開発とは異なり、人間のように多様な反応を示す「非確定的システム」を相手にする、新しい種類の契約を結ぶようなものです。

  • 結論:
    従来のソフトウェア開発は、同じ入力に対して常に同じ出力を返す「確定的システム」間の契約でした。一方、AIエージェントは、同じ指示でも状況によって異なる反応を示す「非確定的システム」です。この根本的な違いを理解し、エージェントのためにツールを「設計」し直す必要があります。

  • 主要なポイント:

    1. 確定的システム (Deterministic System): getWeather("NYC") という関数は、いつ呼び出されても常にニューヨーク市の天気を同じ方法で取得します。結果は予測可能です。
    2. 非確定的システム (Non-deterministic System): ユーザーが「今日、傘はいる？」と尋ねた場合、エージェントは天気ツールを呼び出すかもしれませんし、一般的な知識で答えるかもしれません。あるいは、場所を尋ね返すことさえあります。時には、ツールの使い方を誤解することもあります。
    3. 新しいアプローチの必要性: この不確実性のため、私たちは開発者向けのAPIを作るのと同じ感覚でツールを作るのではなく、エージェントが直感的に、かつ効果的に使えるようにツールを設計するという、根本的な思考の転換が求められます。

  • 比喩:
    従来のAPI開発が「自動販売機」を作るようなものだとすれば、エージェントのためのツール開発は「優秀なアシスタントに道具一式を渡す」ようなものです。アシスタントが道具をどう使うかは、その時の状況やアシスタントの判断に委ねられます。私たちの仕事は、アシスタントが迷わず、かつ創造的に仕事を進められるような、最高の道具セットを用意することです。

非確定的システムとは？ 🧠
コンピュータは通常、同じ指示には同じ動作を返します（確定的）。しかし、AIエージェントは、同じ質問をしても、その時の文脈や学習の機微によって、少し違う答えやアプローチを返すことがあります。これが「非確定的」ということです。まるで、同じ質問をしても、その日の気分や考えによって少し答え方が変わる人間と対話しているようなものです。

Part 2: エージェントと共にツールを育てる反復的開発サイクル

Part 2の要約

このパートでは、効果的なツールを開発するための具体的なステップを解説します。それは、「プロトタイプ構築」→「評価」→「分析」→「エージェントとの協調による改善」という反復的なサイクルです。このプロセスを通じて、ツールを体系的に改善し、エージェントのパフォーマンスを最大化する方法を学びます。

Chapter 2.1: 開発サイクルの全体像

Core Message: 優れたツールは一度では作れません。継続的な「構築、測定、学習」のサイクルを回すことで、エージェントにとって本当に使いやすいツールへと進化させることができます。

  • 結論:
    エージェントのためのツール開発は、直線的なプロセスではなく、反復的な改善サイクルです。このサイクルを効率的に回す鍵は、エージェントを単なるツールの「ユーザー」としてではなく、開発プロセスの「パートナー」として巻き込むことです。

  • 主要なポイント:
    この開発サイクルは、以下の4つの主要なステップで構成されます。

    1. プロトタイプ構築 (Build): 迅速にツールの試作品を作成し、テスト可能な状態にします。
    2. 評価 (Evaluate): 現実的なタスクを用いて、エージェントがツールをどれだけうまく使えるかを測定します。
    3. 分析 (Analyze): 評価結果を分析し、問題点や改善のヒントを見つけ出します。
    4. 改善 (Improve): AIエージェント（例: Claude Code）と協力して、ツールやその説明を改良します。

  • 図解 (PlantUML):
    この反復的なプロセスを視覚的に理解するために、以下のWBS図で全体像を示します。

Chapter 2.2: Step 1 - プロトタイプの構築

Core Message: 完璧な設計図を待つのではなく、まずは動くプロトタイプを作り、実際に触れてみることが、エージェントにとっての「使いやすさ（エルゴノミクス）」を理解する第一歩です。

  • 結論:
    エージェントがどのツールを自然で使いやすいと感じるかを予測するのは困難です。そのため、まずは迅速にプロトタイプを構築し、ローカルでテストすることが重要です。

  • 主要なポイント:

    1. ドキュメントの提供: Claude Code を使ってツールを開発する場合、関連するライブラリやAPIのドキュメント（特にllms.txt形式のファイル）を提供すると、開発がスムーズに進む可能性があります。
    2. 接続とテスト: ツールをローカルのMCPサーバーやDesktop extension (DXT)でラップすることで、Claude Codeやデスクトップアプリから接続してテストできます。
    3. フィードバックの収集: 自身でツールをテストし、ユーザーからのフィードバックを集めることで、ツールの課題やユースケースに関する直感を養うことができます。

Chapter 2.3: Step 2 - 包括的な評価の実行

Core Message: ツールの真価は、現実世界の複雑なタスクを解決できるかどうかで測られます。シンプルすぎる「砂場」環境ではなく、現実に基づいた挑戦的な評価タスクを用意することが不可欠です。

  • 結論:
    ツールの有効性を客観的に測定するためには、現実世界のユースケースに基づいた多数の評価タスクを生成し、評価をプログラムで自動実行することが推奨されます。

  • 主要なポイント:

    1. 質の高い評価タスクの生成:
      • 良い例 (Strong Tasks): 複数のツールコールを必要とする複雑なタスク。
        • 例: 「来週、Janeと最新のAcme Corpプロジェクトについて会議を設定して。前回の議事録を添付し、会議室も予約して。」
        • 例: 「顧客ID 9182が一度の購入で3回課金されたと報告あり。関連ログを全て見つけ、他の顧客にも影響があったか判断して。」
      • 悪い例 (Weaker Tasks): 単純で、単一のツールコールで完結するタスク。
        • 例: 「来週、jane@acme.corpと会議を設定して。」
        • 例: 「顧客ID 45892のキャンセルリクエストを見つけて。」
    2. 評価の自動化:
      • whileループでLLM APIコールとツールコールを交互に実行するような、シンプルなエージェントループを用いて評価を自動化します。
    3. 多様なメトリクスの収集:
      • 正確性だけでなく、ツールコールの総数、総実行時間、トークン消費量、エラー率なども収集することで、より深い洞察が得られます。

Chapter 2.4: Step 3 - 結果の分析

Core Message: エージェントは、何が問題かを直接言葉にするとは限りません。エージェントの行動記録（ログ）や思考の過程を深く読み解き、「言外の意図」を汲み取ることが、真の問題発見につながります。

  • 結論:
    評価結果の分析では、エージェントがどこで戸惑い、混乱したのかを観察することが重要です。エージェントの思考プロセス（Chain-of-Thought）や生のトランスクリプトをレビューすることで、ツールの記述や実装における根本的な問題を発見できます。

  • 主要なポイント:

    1. 思考プロセス(CoT)のレビュー: エージェントがなぜ特定のツールを呼び出したのか（あるいは呼び出さなかったのか）を理解するために、その推論過程を読み解きます。
    2. 生のトランスクリプトの確認: ツールコールとツールからの応答を直接確認し、CoTには現れない予期せぬ振る舞いを発見します。
    3. メトリクスの分析:
      • 冗長なツールコール: ページネーションやトークン制限のパラメータ調整が必要なサインかもしれません。
      • パラメータエラーの多発: ツールの説明や例が不明確である可能性を示唆します。

  • 具体例:
    AnthropicがClaudeのWeb検索ツールをローンチした際、エージェントが不要な年号「2025」をクエリに付加してしまう問題が見つかりました。これは、評価結果の分析を通じて発見され、ツールの説明文を改善することで修正されました。

Chapter 2.5: エージェントとの協調による改善

Core Message: AIエージェントは、もはや単なる評価対象ではありません。評価結果を分析し、ツール自体を改善するための、強力な協力者（コラボレーター）となり得ます。

  • 結論:
    評価エージェントから得られたトランスクリプトを、Claude Codeのような開発支援エージェントに渡すことで、ツールのリファクタリングや説明文の改善を自動的に行わせることが可能です。

  • 主要なポイント:

    1. トランスクリプトの活用: 評価プロセスで生成された一連のやり取り（トランスクリプト）をそのままClaude Codeに入力します。
    2. 専門家としてのClaude Code: Claude Codeは、トランスクリプトを分析し、複数のツールにまたがる問題点を一度に修正・リファクタリングすることに長けています。
    3. 人間とAIの協調: このプロセスにより、人間が書いたツールでも、AIが生成したツールでも、専門家の実装を超えるパフォーマンス改善が達成可能であることが示されています。下のグラフは、人間が書いたツール（Human-written）よりも、Claudeが最適化したツール（Claude-optimized）の方が精度が向上したことを示しています。
ツール 人間による実装 (精度) Claudeによる最適化後 (精度) 改善率
Slack tools 67.4% 80.1% +12.7%
Asana tools 79.6% 85.7% +6.1%
  • 図解 (PlantUML):
    開発者、評価エージェント、そしてClaude Codeがどのように連携してツールを改善していくのかをシーケンス図で示します。

Part 3: 効果的なツール設計のための5つの基本原則

Part 3の要約

このパートでは、これまでの開発サイクルから得られた知見を、効果的なツールを設計するための5つの具体的な基本原則にまとめます。これらの原則は、エージェントの思考方法や制約を考慮した、真に「エージェント中心」のツール設計を行うための指針となります。

Chapter 3.1: 原則の概要

Core Message: 効果的なツールは、意図が明確で、エージェントのコンテキストを賢く利用し、直感的なワークフローを可能にするという共通のパターンを持っています。

  • 結論:
    反復的な評価主導のプロセスを通じて、ツールを成功に導く一貫したパターンが明らかになりました。ここでは、その核心となる5つの原則を紹介します。

  • 図解 (PlantUML):
    5つの原則の関係性をマインドマップで示します。

Chapter 3.2: 原則1 - 適切なツールを選択する

Core Message: ツールの数を増やせば良いというものではありません。エージェントの思考プロセスに沿った、少数の「賢い」ツールを thoughtfully に構築することが、結果的に高いパフォーマンスにつながります。

  • 結論:
    既存のソフトウェア機能やAPIエンドポイントを単にラップするだけのツールは、エージェントにとって最適でないことが多いです。エージェントがタスクを分割し、解決する方法を考慮して、複数のステップを一つのツールに統合することが推奨されます。

  • 主要なポイント:

    1. コンテキストの限界を考慮する: LLMエージェントは一度に処理できる情報量（コンテキスト）に限りがあります。全連絡先を返すlist_contactsツールは、エージェントの貴重なコンテキストを無駄遣いします。
    2. ワークフローの統合: 人間が自然に行うであろう一連の作業を、一つのツールにまとめることを検討します。
    3. 明確な目的: 各ツールが明確で区別された目的を持つようにします。ツールの重複はエージェントを混乱させる可能性があります。

  • 具体例:

    • list_users, list_events, create_event を個別に実装する代わりに、空き時間を見つけてイベントをスケジュールする schedule_event ツールを実装します。
    • get_customer_by_id, list_transactions, list_notes を個別に実装する代わりに、顧客の関連情報をまとめて取得する get_customer_context ツールを実装します。

Chapter 3.3: 原則2 - 名前空間でツールを整理する

Core Message: ツール名に一貫した命名規則（名前空間）を導入することで、エージェントは多数のツールの中から適切なものを、より迅速かつ正確に選択できるようになります。

  • 結論:
    ツールが数十、数百と増えてくると、機能が重複したり目的が曖昧なツールによってエージェントが混乱する可能性があります。関連するツールを共通のプレフィックスでグループ化する「名前空間」は、この問題を解決するのに役立ちます。

  • 主要なポイント:

    1. 境界の明確化: 名前空間は、ツール間の機能的な境界を明確にします。
    2. 適切なツールの選択支援: 例えば、asana_search, jira_search のようにサービスでグループ化したり、asana_projects_search, asana_users_search のようにリソースでグループ化することで、エージェントが適切なツールを選びやすくなります。
    3. コンテキストの削減: タスクを自然に分割するようなツール名を選択することで、エージェントのコンテキストにロードされるツール記述の総数を減らし、エージェント自身の計算負荷をツール側にオフロードできます。

Chapter 3.4: 原則3 - 有意義なコンテキストを返す

Core Message: ツールがエージェントに返す情報は、人間が読んでも理解しやすく、次のアクションに直接つながるものであるべきです。機械的なIDよりも、意味のある名前の方がエージェントにとっては価値があります。

  • 結論:
    ツールの実装では、エージェントに高シグナルな情報のみを返すように注意を払うべきです。柔軟性よりも文脈的な関連性を優先し、uuidのような低レベルな技術的識別子の使用は避けるべきです。

  • 主要なポイント:

    1. 高シグナルな情報を優先: name, image_url, file_type のようなフィールドは、エージェントの次の行動に直接つながりやすいです。
    2. 自然言語を好む傾向: エージェントは、暗号のような識別子よりも、自然言語の名前や用語、IDを扱う方がはるかに得意です。
    3. 柔軟性の提供: response_format のようなパラメータを公開し、エージェントが「簡潔(concise)」な応答と「詳細(detailed)」な応答を選べるようにすることで、柔軟性を提供できます。詳細モードでは後続のツールコールに必要なIDを含み、簡潔モードでは人間が読むための要約を提供します。

Chapter 3.5: 原則4 - トークン効率を最適化する

Core Message: エージェントの「短期記憶」であるコンテキストは有限です。返す情報の「質」だけでなく、「量」を最適化することが、エージェントのパフォーマンスを維持するために不可欠です。

  • 結論:
    ツールが返すコンテキストの量を最適化することも重要です。多くのコンテキストを消費する可能性のあるツールには、ページネーション、範囲選択、フィルタリング、または切り捨て（truncation）の組み合わせを実装することが推奨されます。

  • 主要なポイント:

    1. デフォルト値の設定: Claude Codeでは、ツール応答はデフォルトで25,000トークンに制限されています。このような賢明なデフォルト値を持つことが重要です。
    2. エージェントの誘導: 応答を切り捨てる場合は、よりトークン効率の良い戦略（例：一度に広範な検索をするのではなく、小さく的を絞った検索を複数回行う）を追求するよう、役立つ指示でエージェントを導くことが重要です。
    3. 有益なエラー応答: 不透明なエラーコードやトレースバックではなく、具体的で実行可能な改善策を明確に伝えるエラー応答を設計します。これにより、エージェントは自己修正しやすくなります。

  • 具体例:

    • 悪いエラー応答: {"error": {"code": "RESOURCE_NOT_FOUND", ...}}
    • 良いエラー応答: 
      # Resource Not Found: Invalid `userId`
## Error Summary
Your request failed because the `userId` `john.doe@acme.corp` does not exist or is in the wrong format.
## Valid User IDs
Examples: `1928298149291729`
## Resolving a User ID
Call user_search()

Chapter 3.6: 原則5 - プロンプトエンジニアリングでツール記述を磨く

Core Message: ツールの「説明書」である記述文は、エージェントの振る舞いを方向づける最も強力なレバーの一つです。明確で、曖昧さがなく、具体的な記述が、ツールの成功率を劇的に改善します。

  • 結論:
    ツールを改善する最も効果的な方法の一つが、その説明と仕様をプロンプトエンジニアリングすることです。これらの記述はエージェントのコンテキストにロードされるため、エージェントを効果的なツール呼び出し行動へと集合的に導くことができます。

  • 主要なポイント:

    1. 新人に説明するように書く: チームの新人メンバーにツールを説明する場面を想像してください。専門用語の定義やリソース間の関係性など、暗黙の前提知識をすべて明文化します。
    2. 曖昧さを排除する: 期待される入力と出力を明確に記述し、厳密なデータモデルでそれを強制します。
    3. パラメータ名の具体化: user のような曖昧なパラメータ名ではなく、user_id のように unambiguous な名前を使用します。

  • 具体例:
    Claude Sonnet 3.5 は、SWE-bench Verified評価において、ツールの説明を精密に改良した結果、エラー率を劇的に削減し、タスク完了率を向上させ、最先端のパフォーマンスを達成しました。

プロンプトエンジニアリングとは？ ✍️
AIに対して、より望ましい出力を得られるように、入力（プロンプト）を工夫することです。ツール開発の文脈では、AIエージェントがツールの目的や使い方を正確に理解できるように、ツールの説明文やパラメータ名を最適化する作業を指します。

Part 4: まとめと今後の展望

Part 4の要約

最後に、本記事で解説した「エージェント中心のツール開発」の要点を振り返り、このアプローチが今後のAIエージェントの進化においてどのような役割を果たすのか、その未来像を提示します。

Chapter 4.1: 本記事の要約

Core Message: 効果的なエージェントツールの開発は、従来の開発プラクティスから、非決定的な性質を持つエージェントとの対話を中心とした、反復的で評価主導のプロセスへと移行する必要があります。

  • 結論:
    本記事で紹介した反復的で評価主導のプロセスを通じて、成功するツールに共通するパターンを特定しました。
    • 意図的かつ明確に定義されている。
    • エージェントのコンテキストを賢く利用する。
    • 多様なワークフローで組み合わせることができる。
    • エージェントが直感的に現実世界のタスクを解決できるようにする。

Chapter 4.2: 未来への視点

  • 結論:
    将来的には、エージェントが世界と対話する具体的なメカニズムは、MCPプロトコルの更新から、基盤となるLLM自体のアップグレードまで、進化していくことが予想されます。エージェントのためのツールを改善するための体系的で評価主導のアプローチを持つことで、エージェントがより有能になるにつれて、彼らが使用するツールも共に進化していくことを確実にできます。

  • 比喩:
    私たちは今、優秀な職人（AIエージェント）のために、全く新しい種類の道具（ツール）を作っています。職人のスキルが向上するにつれて、より高度で専門的な道具が必要になるでしょう。私たちの役割は、職人と対話を続け、彼らの成長に合わせて最高の道具を提供し続けることです。この協調的なプロセスこそが、AIエージェントがその潜在能力を完全に発揮するための道筋となるでしょう。

8
14
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
8
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?