最終更新:

AIエージェントの仕組み — 道具を使い、結果を見て次を決める


提案を確かめて、実際の結果を受け取る

モデル:在庫を調べたいアプリ:道具と入力を確認実行の結果りんご:3個結果をモデルへ返し、次を判断「提案」と「調べ終えた」は別
本文では提案を固定したアプリ側の検査と実行だけを試します。実エージェントでは結果をモデルへ返し、回答や次の操作・停止を判断します。
ひよこ ひよこ
AIが在庫を調べるって、どう動くの?
ペンギン先生 ペンギン先生
モデルが必要な道具と入力を提案し、アプリが許可を確認して道具を実行する構成があるよ。結果をモデルへ返し、次の処理や回答を決める。こうした目標に向けたループが、エージェントの基本的な形の一つだね。
ひよこ ひよこ
モデルが提案したら、もう在庫を調べたことになる?
ペンギン先生 ペンギン先生
まだだよ。実際のプログラムがDBやAPI等へ問い合わせて、その結果を受け取る必要がある。「調べます」と文章に書くことと、調べる操作の完了は別なんだ。
ひよこ ひよこ
モデルは、自分で目標も勝手に決める?
ペンギン先生 ペンギン先生
通常は利用者やアプリが目標と使える道具を与える。任せる範囲を設計するんだ。ChatGPT等の製品にも道具を使う機能があるので、チャット画面かどうかだけではエージェントかを区別できないよ。
ひよこ ひよこ
決まった順番で動くプログラムと、何が違う?
ペンギン先生 ペンギン先生
固定したワークフローは、順番や分岐をコードで決める。エージェントではモデルが状況から次の道具や手順を選ぶ構成がある。ただし呼び方は広く、固定と動的を組み合わせることもあるよ。
ひよこ ひよこ
計画と記憶は、必ず必要?
ペンギン先生 ペンギン先生
構成によるよ。毎回大きな計画を作るとは限らず、会話やツールの結果を入力へ残す場合もある。外部DBやログも選択肢だけど、記憶が必ず3種類に分かれるわけではないんだ。
ひよこ ひよこ
間違った道具を選んだら、どうする?
ペンギン先生 ペンギン先生
許す道具、入力の形式、操作の対象をアプリが検査する。外部への変更には必要な承認を設け、処理回数や時間、費用の上限も決める。モデルの提案をそのまま何でも実行しないよ。
ひよこ ひよこ
失敗しても、自分で直して最後まで進む?
ペンギン先生 ペンギン先生
結果を見て別の方法を選ぶことはあるけれど、成功は保証できないよ。繰り返しても進まない場合や、根拠が不足する場合は停止する。ReActは推論と行動を組み合わせるパターンの一つで、全エージェントが使う必須方式ではないんだ。
ひよこ ひよこ
たくさんのエージェントを使う方がいい?
ペンギン先生 ペンギン先生
役割分担が役立つ場合はあるけれど、連携や確認の手間、時間と費用も増える。まずは小さな仕事を1つ、実際の結果で評価する。道具の成功と、利用者の目標が達成されたことも分けて確かめよう。

まずは、提案と実行結果を分ける

「りんごの在庫を調べたい」という仕事なら、モデルからlookup_stockという道具の呼び出し提案を受け、アプリが在庫の記録を読みます。Python 3で次をagent-tool-demo.pyへ保存し、python agent-tool-demo.pyで試しましょう。

stock = {"りんご": 3, "みかん": 0}
proposal = {"name": "lookup_stock", "item": "りんご"}

if proposal["name"] != "lookup_stock":
    raise ValueError("許可していない道具です")
if proposal["item"] not in stock:
    raise ValueError("扱っていない商品です")
result = {"item": proposal["item"], "count": stock[proposal["item"]]}
print("道具の結果:", result["item"], result["count"])
道具の結果: りんご 3

これは提案を固定した、アプリ側の検査と道具の実行の練習です。生成モデルへ接続しておらず、完全なエージェントではありません。実際の構成では、モデルから提案を受け、アプリが実行した結果をモデルへ返します。モデルが呼び出しを出しただけで、実行成功とは扱いません。

目標・道具・結果をつなぐ

  1. 目標と、使える道具を与える。
  2. モデルが次の操作を提案する。
  3. アプリが権限・入力・対象を確かめ、実行する。
  4. 実際の結果をモデルへ返す。
  5. 次の操作、回答、停止を判断する。

在庫を読む道具と、注文を確定する道具は別の権限にします。在庫が3個という応答だけでは、注文が予約されたことにはなりません。再試行した変更が二重になる場合も、アプリで対処します。

固定したワークフローと、動的な判断

順番が明確な仕事はコードで組み立てる方が分かりやすい場合があります。状況に応じた検索や道具の選択をモデルへ任せる場合に、エージェントの構成を検討します。道具や記憶の種類を固定した数で覚える必要はありません。

会話の入力へ結果を残す方法、外部DBで関連情報を取り出す方法、実行ログを保存する方法等があります。保存したからいつでも正しく思い出せるわけではなく、何を次の判断へ渡すかも設計します。

停止と、完了の確認

ReActは推論と行動を組み合わせ、外部の結果を使う提案です。必ずエラーを修復したり、必ず利用者へ適切に報告したりする保証ではありません。呼び出し回数・時間・費用の上限、進まない場合の停止、必要な人の判断を用意します。

評価では、道具の呼び出しが成功したかだけでなく、元の目標が達成されたか、根拠と結果が一致するかを確認します。資料中の命令等の信頼できない入力で、許す操作が広がらないことも確かめます。

🐧 ペンギン先生のまとめ:「AIエージェント」って出てきたら「目標に向け、道具の結果を見ながら次の動きを選ぶ仕組み」と思えばだいたいOK!

資料の参照はRAGの仕組み、役割分担はマルチエージェントの仕組みで学べます。

参考資料