注文が遅れたことについてチャットボットに質問すると、いくつかのアドバイスが得られます。 AI エージェントに依頼すると、注文を検索し、遅延を確認し、バウチャーを適用してレポートを返します。違いは、エージェントは 1 つの応答だけを生成するのではなく、アクションを実行し、発生したことに反応できることです。

この用語はマーケティングでは拡張されているため、このガイドではこれらのシステムが実際にどのように機能するかについて説明します。具体的にするために、Python 3.13 で小さなエージェント ループを構築して実行しました。以下の出力はそれらの実行から得られます。 私たちの「モデル」はスクリプト化された関数であり、実際の AI モデルではありません。そのため、誰でもループを実行してテストできます。それは知性ではなく、制御構造を示します。基本的なことは初めてですか?最初に大規模言語モデルとはをお読みください。

AIエージェントとは何ですか?

合意された単一の定義はありません。現在の実践では、AI エージェントは、次に何をするかを繰り返し決定し、ツールを使用して世界に作用し、結果に基づいて調整することで目標を追求するソフトウェアです。通常、意思決定は大規模な言語モデルに基づいて行われます。

道案内をする人と使い走りをする人との違いを考えてみましょう。最初の人は一度答えます。 2人目は店を出て、店が閉まっていることに気づき、別の店を試し、仕事が終わってから戻ってきます。

チャットボット、ワークフロー、それともエージェント?

これらはスペクトル上に存在し、多くの便利なシステムが混在しています。重要な問題は、パスのどの程度が実行時に決定されるかということです。

エージェントの内部にあるもの

エージェントループ

1. 決定します。 モデルは目標と履歴を見て、アクションを選択するか、それが終了したかを判断します。
2. 動作 コードは、要求されたツールを実行します。
3. 観察します。 結果は履歴に追加されます。
4. 目標が達成されるか、制限に達するまで繰り返します。

それがほとんどのエージェントの中核です。洗練さは主に、モデル、ツール、およびこのループ周りの安全装置にあります。

実行できるループ

当社の小規模代理店は遅れた注文にも対応します。これには 2 つのツールがあり、そのうちの 1 つはコストがかかるため人間の承認が必要です。

ORDERS = {
    "A100": {"status": "delayed", "days_late": 6},
    "B200": {"status": "shipped", "days_late": 0},
}

def get_order(order_id):
    return ORDERS.get(order_id, {"error": "order not found"})

def issue_voucher(order_id, amount):
    return {"voucher": f"V-{order_id}", "amount": amount}

TOOLS = {"get_order": get_order, "issue_voucher": issue_voucher}
NEEDS_APPROVAL = {"issue_voucher"}

そして、これがループ自体です。これは通常のコードであり、すべての安全ルールはモデル内ではなくここに存在します。

def run_agent(goal, model, approve, max_steps=5):
    history = []
    for step in range(1, max_steps + 1):
        decision = model(goal, history)
        if "finish" in decision:
            return decision["finish"]

        name, args = decision["tool"], decision["args"]
        if name in NEEDS_APPROVAL and not approve(name, args):
            result = {"denied": True}
        else:
            result = TOOLS[name](**args)

        history.append({"tool": name, "result": result})
    return None   # stopped: step limit reached

実際のモデルを使用するには、model 関数を LLM API の呼び出しに置き換え、ツールの目標、履歴、説明を渡します。ループはほぼ同じままです。

私たちのランニングで何が起こったのか

スクリプト化された決定機能を使用して 5 つの状況を試し、各ステップを記録しました。

伝票が承認されたにもかかわらず注文が遅れた

step 1: get_order({'order_id': 'A100'}) -> {'status': 'delayed', 'days_late': 6}
step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'voucher': 'V-A100', 'amount': 200}
step 3: finish -> Sorry for the delay. Voucher V-A100 issued.

各ステップでは、その前のステップの結果が使用されました。バウチャーは遅延が確認されてからのみ考慮されます。

同じ注文で承認が拒否されました

step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'denied': True}
step 3: finish -> Your order is late. A person will review compensation.

人間は「いいえ」と答え、ツールは決して実行されず、エージェントはその応答を調整しました。

不明な注文

step 1: get_order({'order_id': 'Z999'}) -> {'error': 'order not found'}
step 2: finish -> I could not find that order.

ツールに明確なエラー メッセージを表示すると効果的です。実際のモデルは、推測ではなく、それらを読み取り、賢明に応答できます。

行き詰まったモデル

また、同じアクションを永遠に繰り返す欠陥のある決定関数も置き換えました。

step 1: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 2: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 3: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
stopped: step limit reached

エージェントは実際にこのようなループに陥る可能性があり、実際のモデルを使用する各ステップにはコストがかかります。 max_steps がなければ、この作品は決して終わることはなかったでしょう。

ツールの仕組み

これが最も誤解されている部分です。言語モデルはそれ自体では何も実行できません。どのツールがどのような引数とともに必要かを示す構造化テキストを生成します。 コード​​によって、それを実行するかどうかが決まります。このため、ループは権限、検証、ログ記録に適した場所となります。

モデルプロバイダーは、このためのツールまたは関数呼び出しを提供します。モデル コンテキスト プロトコル (MCP) は、モデルをツールやデータに接続するためのオープン スタンダードであり、Playwright MCP に関する記事で 1 つの使用方法が示されています。モデルはツール名と説明に依存して正しく選択されるため、明確なツール名と説明を記述します。

記憶

長いタスクはモデルのコンテキスト ウィンドウを超える可能性があるため、システムは古いステップを要約することがよくあります。概要では詳細が失われる可能性があり、これが、長期にわたって実行されるエージェントがコースから外れてしまう原因の 1 つです。

マルチエージェントシステム

一部のシステムでは、プランナー、研究者、レビュー担当者など、複数の専門エージェント間で作業を分割します。これは、きれいに分割された大規模なタスクに役立ちます。また、コストがかかり、失敗する可能性が増え、デバッグが難しくなります。最初は優れたツールを備えた 1 つのエージェントを試し、明確な理由がある場合にのみ分割します。

リスクと限界

• 間違ったアクション。 チャットボットの間違いは悪い文章です。エージェントの間違いは、電子メールの送信やレコードの削除である可能性があります。
• プロンプト挿入。 エージェントが読む Web ページまたは電子メールには、隠された指示が含まれている可能性があります。すべてのツール出力をコマンドとしてではなく、信頼できないデータとして扱います。
• 複合的なエラー。 初期段階で小さなエラーが発生すると、その後のすべてのステップが間違った方向に進む可能性があります。
• コストとレイテンシ。 各ステップは別のモデル呼び出しになる可能性があるため、タスクは単一のプロンプトよりもはるかに遅くなり、コストが高くなる可能性があります。
• 矛盾。 同じ目標でも実行ごとに異なるパスをたどる可能性があり、テストが困難になります。
• 説明責任。 ユーザーはシステムの動作に対して引き続き責任を負うため、記録を保管してください。

重要なガードレール

1. 最小限の権限。 各エージェントに必要なツールとアクセスのみを与えます。
2. 私たちのデモのように、コストがかかるもの、取り消しできないもの、外部のものに対する人間の承認。
3. 歩数、時間、支出に対する厳しい制限。
4. コード内でツール入力を検証し、モデルへの指示に依存しません。
5. すべてのステップを記録し、何かが起こった理由を確認できるようにします。 モニタリングと可観測性を参照してください。
6. 失敗を含む実際のシナリオでテストします。最終結果と個別の返信を確認します。 AI エージェントのベスト プラクティス に関するガイドでは、展開についてさらに詳しく説明します。

エージェントを使用する場合

コーディング アシスタントは、ファイルを読み取り、テストを実行し、失敗を確認して再試行し、人間が結果をレビューすることができるため、現在最も成熟した例の 1 つです。テストスイートは、成功の明確なシグナルを与えます。 迅速なエンジニアリングに関するガイドは、エージェントに適切な指示を作成する場合にも当てはまります。適切にプロンプ​​トされた 1 回の電話は、複雑なエージェントよりも優れていることが多いため、効果的な最も単純なことから始めてください。

まとめ

AI エージェントは、思っているほど神秘的ではありません。モデル、いくつかのツール、および制限のあるループです。難しいのはコードではなく信頼です。それらがどのように動作するかを知るには、小さなループを取得し、読み取り専用ツールを使用して実際のモデルに接続し、動作するログを観察します。それがどこで輝いているのか、どこに人間が必要なのかがすぐにわかるでしょう。

よくある質問

学び続ける