はじめてのAIエージェントを作る — 目的・ツール・境界の設計

「エージェント」とただのチャットは何が違うのか

チャットは、人がひとつ質問し、モデルがひとつ答えて終わります。次に何をするかは常に人が決めます。一方でエージェントは、達成すべき目的を渡すと、そこに至る手順を自分で組み立て、途中で外部のツール（検索、ファイル操作、他のサービスの呼び出しなど）を使いながら、結果を確認して次の行動を選び直すところまでを担います。Anthropicの技術ブログは、あらかじめ決められた処理の流れにモデルを1ステップだけ組み込む「ワークフロー」と、モデル自身が次の行動を動的に決めていく「エージェント」を明確に区別しており、多くの「AIエージェント」を名乗る製品は実際には前者に近いと指摘しています。

この区別は、実務上の判断に直結します。ワークフローは手順が固定されているぶん動作を予測しやすく、エージェントは柔軟な反面、想定していなかった手順を自分で選んでしまう可能性があります。最初に作るべきなのは、後者の自由度をできる限り絞り込んだ、小さなエージェントです。

前提 — 始める前に確認すること

着手する前に、次の3点を確認してください。まず、使うモデルがツール呼び出し（function calling / tool use）に対応していることです。ClaudeやChatGPTなど主要なサービスはいずれもこの機能を公式ドキュメントで提供していますが、対応範囲や呼び方はサービスやプランによって異なるため、必ず現行の公式ドキュメントで確認してください。次に、本番データではなくテスト用のアカウントやサンドボックス環境が用意できることです。最後に、エージェントに任せる作業が「失敗しても被害が小さい」範囲に収まっていることです。

手順 — 目的・ツール・境界を設計する

次の順番で設計します。

1. 目的を1文で書く。「メールに返信する」ではなく「未対応の問い合わせメールを分類し、下書きの返信案を作成する」のように、終了条件がわかる粒度にします。
2. 使わせるツールを最小限に絞る。この例であれば「メールを読む」「下書きを保存する」の2つで十分で、「送信する」まで渡す必要はありません。
3. 権限とアクセス範囲を制限する。読み取り専用のAPIキーや、本番と分離したテスト用アカウントを使い、エージェントが触れられる範囲そのものを狭くします。
4. 停止条件を決める。ツール呼び出しの回数上限、処理時間の上限、そして「これ以上は人が確認してから実行する」境界を明文化します。
5. すべてのツール呼び出しと結果をログに残す設定にする。後から挙動を追えないと、次の改善ができません。

確認とつまずきやすい点

設計ができたら、内容の異なる入力を数パターン用意して動かし、ツール呼び出しが想定した範囲に収まっているか、停止条件が実際に働くかを確認します。ログを見て「なぜその行動を選んだか」が説明できない挙動があれば、目的の文章かツールの説明文が曖昧である可能性が高いです。

つまずきやすい点としては、まずツール呼び出しのループが止まらないケースが挙げられます。上限を設定していないと、エージェントが同じ確認作業を繰り返し続けることがあります。次に、権限を広く与えすぎて意図しない操作が実行されるケースです。OWASPが公開しているLLMアプリケーションのリスク一覧でも、モデルに与える権限や自律性の広さそのものがリスク要因として整理されています。もうひとつは、ツール呼び出しがエラーを返した際に、エージェントがそれを無視して誤った前提のまま処理を続けてしまうケースです。エラー時の挙動もあらかじめ決めておく必要があります。

次の一歩 — 小さく動かしてから広げる

最初の一体が安定して動くようになったら、対象範囲を少しずつ広げます。どの定型業務から着手すべきかを見極める考え方は、定型業務をAIで自動化する対象の選び方で扱っています。また、エージェントに外部サービスとのやり取りを任せる段階になったら、認証や呼び出し方式の設計が必要になります。この点は外部ツールと連携する自動ワークフローの作り方で解説しています。もっとも、判断のたびに人間の価値観や責任が絡む業務——採用の合否連絡や返金の可否判断など——は、エージェント化ではなく人の意思決定を支援する範囲にとどめておくのが妥当です。