AI エージェントとツールの使用

利益:

• エージェントを「モデル + ツール + ループ」として定義し、それがいつ必要になるかを決定する
• 名前、説明、input_schema を使用したツール定義の作成
• tool_use ループと tools_result ループのフローとエラー処理の監視

これまで、モデルは常に 1 つのジョブ、つまりテキスト入力を受け取り、テキスト応答を生成してきました。しかし、実際の仕事ではテキスト以上のものが必要になることがよくあります。計算を実行し、データベースにクエリを実行し、API を呼び出し、現在の為替レートを調べます。モデルはこれらのことを自分で行うことはできませんが、いつ行う必要があるかを判断して、誰かにやってもらうことはできます。これがツールの使用によってモデルに与えられるものであり、これが AI エージェントの基礎です。この単元では、エージェントとは何か、ツールがどのように定義されるか、tool_use ループがどのように機能するかを学びます。

エージェントとは何ですか?モデル + ツール + ループ

AI エージェントは 3 つの部分で構成されます: モデル (意思決定を行う脳)、ツール (モデルが呼び出すことができる機能: 天気、データベース クエリ、電子メールの送信)、およびループ (ループ。モデルはツールを呼び出し、結果を取得し、何をすべきかを再度決定するなど)。

重要な違い: 単一パターンの呼び出しはエージェントではありません。エージェントは、モデルがステップごとに進み、各ステップでツールの結果に基づいて次の動きを選択するプロセスです。 「人間のように考え、手を動かし、結果を見て、もう一度考える。」

重要な事実: モデル自体は車両を操作しません。モデルは「これらの入力を使用してこのツールを呼び出したい」と言うだけです。アプリケーション (ハーネスと呼ばれます) はツールを実行し、結果をモデルに返します。これはセキュリティにとって非常に重要です。モデルはシステムに直接触れません。すべてのアクションはあなたのコントロール下にあります。

ヒント: エージェントとすべての問題を解決しようとしないでください。エージェント;遅延、コスト、エラーのリスクが増加します。まず「これは 1 回の電話で解決しますか? それとも固定ワークフローで解決しますか?」と尋ねてください。答えが「はい」の場合、エージェントは必要ありません。エージェントは、手順を事前に知ることができない、無制限のタスクに適しています。

ツール定義: 名前、説明、input_schema

モデルにツールを導入するには、次の 3 つのことを指定します。

• name: 車両の ID、例: get_weather。
• 説明: ツールの機能とそれをいつ呼び出すか。これは、モデルが適切なタイミングで適切なツールを選択できるようにする最も重要な領域です。 「何をするか」だけでなく「いつ電話するか」も書きます。
• input_schema (入力スキーマ): ツールがどのパラメーターをどのタイプで予期するかを定義する JSON スキーマ。

# 車両定義 (概念的 — JSON スキーマ){ "name": "get_order_status", "description": "注文の現在の出荷ステータスを取得します。ユーザーが注文番号の場所またはいつ到着するかを尋ねたときに呼び出します。", "input_schema": { "type": "object", "properties": { "order_no": {"type": "string", "description": "注文番号,例: SP-1024"} }、"必須": ["order_no"] }}

適切なツール説明のルール: 明確で簡潔な名前、「いつ使用するか」を含む説明、各パラメータの説明、本当に必須のものを必須に含めます。車両の数に注目してください。驚くべきことに、同様の車両モデルが何十もある。

エリア

それは何をするのですか？

良い例

悪い例

名前

車両ID

order_status_getir

持ってくる

説明

機能 + いつ呼び出すか

「貨物のステータスを返します。ユーザーが注文品がどこにあるか尋ねたら電話します。」

「データを取得します」

入力スキーマ

パラメータのタイプと要件

{order_no: 文字列、注釈付き}

図なし/説明なし

tools_use → tool_result ループ

サイクルは次のように段階的に機能します。

1. ユーザーの質問とツールの説明をモデルに送信します。
2. モデルは直接応答するか、tool_use ブロック「order_no=SP-1024 を指定して order_durumu_getir を呼び出す」を生成します。
3. アプリケーションは実際にツールを実行します (データベースにクエリを実行します)。
4. 結果をtool_resultとしてモデルに送り返します。
5. この結果により、モデルは最終的な答えを生成するか、別のツールを呼び出します。このサイクルは、モデルが「完了」と言うまで続きます。

# エージェント ループ (概念的)messages = [user_question]while True: response = model.uret(messages, tools=tool_settings) if response.tur == "tool_use": result = harness.run(response.tool_name, response.entries) # APPLICATION はメッセージを実行します += [response, tool_result(result)] # 結果を返します else: Break # 最終応答;ループの終了

最新の SDK は、このループを実行するツール ランナーを提供します。ツールの関数を記述するだけです。しかし、それがまさに舞台裏で起こっていることなのです。

エラー管理

ツールが失敗する可能性があります: 注文が見つからない、API タイムアウト、入力が無効です。ツールを実行できない場合は、説明的な tool_result (「エラー: 注文番号 SP-9999 が見つかりません」) およびエラー フラグとしてモデルにエラーを返します。モデルはこれを見てユーザーに優しく説明したり、別の方法を試したりすることができます。エラーを鵜呑みにして空の結果を返さないでください。モデルは何が問題だったのかを知っている必要があります。

弱い/強い車両の説明

弱い (不定名詞、「いつ」なし):

名前: "データ"、説明: "データをフェッチ"# モデルは、いつ、どのように呼び出すかがわかりません。まったく電話をかけないか、間違って電話をかけます。

Strong (ネット名 + when + パラメーターの説明):

name: "musteri_bakiyesi_getir"description: "顧客の現在の口座残高を返します。ユーザーがデビット、クレジット、または残高を要求したときに呼び出します。支払いは行われません。"input_schema: {custeri_id: string ("Customer ID")}# モデルは、制限を認識しながら、適切なパラメーターを使用して適切なタイミングで呼び出します。

ミニケース3個

ケース 1 — 不要なエージェント。あるチームは、マルチツール エージェントを使用して「テキストの要約」ビジネスを構築しました。各要約には 4 つのモデル呼び出しと 9 秒かかります。この仕事は実際にはワンコールの仕事でした。エージェントを削除して 1 回の通話に減らしたところ、時間は 1.5 秒に短縮され、コストは 4 分の 1 に減少しました。教訓: 本当に必要な場合にはエージェントを使用してください。

ケース 2 — 不十分な説明、間違い電話。サポート エージェントでは、fetch と呼ばれるあいまいなツールが残高の質問と配送の質問の両方でモデルによってランダムに呼び出されていました。車両を Balance_getir と Cargo_durumu_getir に分割し、「いつ連絡するか」の説明を追加すると、車両選択の間違いは 18 件から 50 件に 1 件に減少しました。

ケース 3 — エラーが飲み込まれた。注文が見つからなかった場合、エージェントは空の結果を返していました。モデルはこれを「注文が配達された」と解釈し、顧客を誤解させました。エラー メッセージがtool_result (「注文が見つかりません」) に明示的に書き込まれると、モデルは「この番号が見つかりませんでした。確認してもらえますか?」と正しく伝えます。彼は言い​​始めた。

よくある間違い

• すべてをエージェントに任せる: 1 回の通話で十分ですが、エージェントはコストと遅延を追加します。
• 曖昧な車両の説明: モデルは、いつ電話をかけるべきかを知りません。間違った選択をします。
• モデルが車両を動かすと考える: ハーネスが車両を動かす。モデルはただ望んでいます。
• エラーを飲み込む: モデルは何が間違っていたのかを知っている必要があります。エラーを open tool_result として返します。
• 似たような車両が多すぎる: モデルが混乱します。ツールセットは焦点を絞って最小限に抑えてください。

注意: モデルに「その車両を呼び出してください」と表示されているからといって、アクションを実行する必要があるというわけではありません。破壊的なツール (削除、チェックアウト、電子メール) では、アプリケーションは呼び出しを盲目的に実行してはなりません。これが次の単元のセキュリティに関するトピックの核心です。

要約すると

• エージェント = モデル (決定) + ツール (機能) + ループ (ツールを呼び出し、結果を取得し、再度決定)。
• 単一パターンの呼び出しはエージェントではありません。エージェントは段階的なプロセスです。
• モデルは車両を動かしません。アプリケーションが実行され (ハーネス)、結果が tools_result として返されます。
• ツールは、名前、説明 (具体的には「call when」)、および input_schema によって識別されます。
• ループは、tool_use → harness の実行 → tool_result → model と続き、モデルが「完了」と表示されるまで続行されます。エラーはモデルに明示的に報告されます。

アプリケーションタスク

エージェントに提供できる自分のビジネスのツールを 3 つデザインします。 (1) それぞれに名前、「call when」による説明、input_schema を記述します。少なくとも 1 つは非破壊読み取りツール、もう 1 つは計算ツールとします。 (2) 現実的なユーザーの質問を選択し、モデルがどの入力を使用してどのツールを呼び出すか、tool_result が到着した後に何を行うかを段階的に (ループ内で) 手動で記述します。 (3) いずれかのツールが失敗した場合のシナリオを設定し、エラー メッセージがどのようにモデルに返されるかを示します。

チェックリスト

• [ ] エージェントを「モデル + ツール + ループ」として定義し、それがいつ必要になるかを決定できます。
• [ ] ハーネスが車両を動かすことはわかっていますが、モデルはそれを望んでいるだけです。
• [ ] 名、説明 (「いつ呼び出すか」)、および input_schema を使用して、しっかりとした車両の説明を書くことができます。
• [ ] ツールの使用 → ツールの結果のサイクルを段階的に実行できます。
• [ ] ツール エラーを open tool_result としてモデルに報告します。