エージェント設計レシピ:Tool Use・Sub-agent・制御フロー

AI Navigate Original / 2026/4/27

💬 オピニオンDeveloper Stack & InfrastructureTools & Practical Usage
共有:

要点

  • 自分の業務に合う Agent を 3 パターンで作る
  • Tool Use(関数)・Sub-agent(役割分担)・制御フロー(コード)
  • 実務は 3 つ併用、ループ上限・ログ・承認・テスト
  • 過剰設計を避け、Sub-agent でコスト増、最小から育てる

既製のエージェント(Claude のエージェント機能や Manus など)を「使う」のは入口にすぎません。自分の業務に合わせたエージェントを「作る」には、設計の型を知る必要があります。本記事では、土台になる 3 つのパターン――ツール使用(Tool Use)・サブエージェント(役割分担)・制御フロー(ワークフロー)――を、実際の製品名や数字を交えながら、初めての人でも順に組み立てられるよう整理します。

Tool Use 道具を呼び出す Sub-agent 役割で分ける Control Flow 分岐・承認を組む

FIG.1 3 つの型は対立しない。実務では重ねて使う

01パターン1:ツール使用(Tool Use)

LLM は文章を生成するのは得意ですが、それ単独では「今の天気」を知らず、Slack に投稿することもできません。そこで、外の世界とつなぐ関数をツールとして渡し、AI に必要なときだけ呼ばせます。これがエージェントの最小単位です。

ツールは「名前・説明・入力スキーマ」の 3 点セットで定義します。AI は会話の途中で「このツールをこの引数で呼びたい」と構造化して返し、アプリ側が実際に実行して結果を会話に戻す――この往復を繰り返します。

tools: [
  {
    name: "get_weather",
    description: "指定した都市の今日の天気を返す",
    input_schema: {
      type: "object",
      properties: { city: { type: "string" } },
      required: ["city"],
    },
  },
  {
    name: "post_slack",
    description: "指定チャンネルにメッセージを送る",
    input_schema: {
      type: "object",
      properties: {
        channel: { type: "string" },
        text: { type: "string" },
      },
      required: ["channel", "text"],
    },
  },
]

「東京の天気を #general に投稿して」と頼むと、AI は自分で get_weather(city:"東京") → その結果を受けて post_slack(...) の順に呼びます。どのツールをいつ使うかは AI が判断します。

続きを読むには無料登録が必要です

アカウントを作成すると、オリジナル記事の全文をお読みいただけます。