「エージェント」は今、ソフトウェアの世界でもっとも意味を詰め込まれすぎた言葉だ。ベンダーはこれをチャットボットにも、スケジュール実行されるスクリプトにも、APIキーが1つくっついているものなら何にでも使う。だがそのノイズの下には、学ぶ価値のある本物のパターンがある。今年AIエージェントを作りたいなら、最初の仕事はそのパターンをマーケティングから切り離すことだ。というのも、人々が思い描く「エージェント」プロジェクトのかなりの割合は、素朴な自動化として作ったほうがよいものだからだ——午後半日で、コストもごく一部で済む。
このガイドは3つのことをする。エージェントとは実際に何なのかを、企画会議で使い回せる一文で定義する。あなたのスキルに合わせた3つの構築ルートを示す——ノーコードのプラットフォーム、開発者向けのフレームワーク、そしてそもそもエージェントを作らないという正直な第3の選択肢。そして、受信箱トリアージ・エージェントという1つの具体例を、目標からガードレールまで通しで歩く。
そのどれにも機械学習の素養は要らない。だがそのどれにも、そのものに何をさせたいのかをはっきりさせておくことが要る。
AIエージェントとは本当のところ何なのか
ブランドの装いを剥ぎ取れば、エージェントとはループの中で動く3つの部品だ。
- 次に何をするかを決めるモデル
- 呼び出すことを許されたツールの一式：データベースを検索する、メールを読む、ラベルを付ける、メッセージの下書きを書く
- 停止条件を伴う目標。これがあることでループはいつ終わったのかを知る
エージェントとはループだ——決めるモデル、動くツール、そしていつ止まるかを告げる目標。
肝心なのはループの部分だ。チャットボットはメッセージに答えると待つ。ワークフローは毎回同じ固定の手順を実行する。エージェントは状況を読み、ツールを選び、結果を見て、また決める。これを目標が満たされるか予算が尽きるまで繰り返す。ループの真ん中にあるこの意思決定点こそが、エージェントと、エージェントとして売られている他のすべてとの違いのすべてだ。
これはまた、あなた自身のプロジェクトを見極めるきれいなテストにもなる。何かが動き出す前に、あらゆる手順をフローチャートとして描けるなら、あなたにエージェントは要らない——要るのはワークフローで、それが下の第3のルートであり、恥じることは何もない。エージェントがその複雑さに見合うのは、次の一歩が前の一歩で出てきたものに本当に左右されるときだけだ。
AIエージェントを作る3つの方法
どのルートを取るかは、野心よりも、誰が作るのか、そして問題がどんな形をしているかによる。ToolPotionのディレクトリにはAIエージェントを作るためのツール700件が載っている。この3つのルートの狙いは、そのうちのほんの一握りより多くを評価する必要が決してないようにすることだ。
ルート1：ノーコードのエージェント・プラットフォーム
これは、コードを書く人ではなく、そのプロセスを所有する人（サポートのリード、オペレーションのマネージャー、PM）のためのルートだ。
Microsoft Copilot Studioを使えば、自社の業務データに接続し、自然言語のプロンプトに応答し、Microsoft 365アプリやWebサイトへとデプロイできるエージェントを作れる。会社がすでにMicrosoftの上で動いているなら、これはアイデアからデプロイ済みエージェントまでの最短距離だ——モデルへのアクセスも、データ接続も、チャネルも、すでに同僚たちが働いている場所にある。あなたのスタックがMicrosoftのものから遠ざかるほど、その値打ちは薄れる。
Voiceflowは会話の側からこの問題に取り組む——チャットや音声のエージェントのフローを視覚的に設計し、複数のチャネルにわたって立ち上げ、実際のトランスクリプトをもとに反復する。顧客と向き合うサポート・エージェントには強くはまる。あなたのエージェントが人間と一切話さないなら、形が合っていない。
このルートに共通するトレードオフ：あなたはループを借りている。エージェントがおかしな振る舞いをしたとき、デバッグとは自分のログを読むことではなく、ベンダーのインターフェースをクリックして回ることを意味し、後で別のプラットフォームへ移ることは作り直しを意味する。そもそも自分がエージェントを作っているのかどうかも正直に見よう——このレベルのプロジェクトの多くは実のところチャットボットであり、あなたのものがそれに当てはまるなら、チャットボットを作るためのツールのディレクトリのほうが、より的を射た買い物の場だ。
ルート2：フレームワークとコード、開発者向け
開発者はより多くの制御を、そしてより多くの宿題を手にする。ループは自分で書く——モデルを選び、各ツールを関数として定義し、目標をシステムプロンプトで表現し、反復回数と支出に厳しい上限を設ける。
モデルの選択は、ここでは他のどこよりも重要になる。Claude Opusはまさにこの仕事のために作られている——コーディングとエージェント向けに設計された推論モデルで、100万トークンのコンテキストウィンドウを備え、長時間にわたるタスクを通じてメールボックス1つ分やコードベース1つ分のコンテキストをまるごと保持できる。ただし注意点はコスト規律だ——ループの毎ターンでフロンティアモデルを使うと積み上がっていくので、安価な手順（分類、整形）は小さなモデルに振り、大きなモデルは意思決定のために取っておこう。
最初の構築には、汎用のフレームワークより狭いフレームワークが勝る。Vanna 2.0は良い例だ——社内データベースを平易な言葉で問い合わせるエージェントのためのオープンソースのフレームワークで、複数のLLMプロバイダーとデータベースに対応し、本番運用向けのアクセス制御とエージェント・メモリも備える。最初のエージェントが「自社データから質問に答える」なら、足場の大部分はもう書かれている。どんなオープンソースのフレームワークとも同じく、デプロイと保守は自分持ちだ。
オーケストレーションのライブラリから評価用のハーネスまで、さらなる選択肢はAIフレームワークのディレクトリにある。
ルート3：あなたに必要なのはエージェントではない——ワークフローだ
これはフローチャート・テストのもっとも一般的で正直な結末であり、慰めの賞ではなく本物のルートとして扱われるに値する。
手順が既知なら、曖昧な部分にモデルの手順を1つだけ加えたワークフロー・ツールが、ループの予測不能さを一切伴わずに価値の大半をもたらす。Zapierは9,000を超えるアプリにまたがってAIワークフローとエージェントを構築し、チーム向けのガードレールとアクセス制御を備えるが、タスク単位の料金モデルは量が増えると痛い。Makeはドラッグ＆ドロップの視覚的なキャンバスと3,000以上の連携、そして試作用の無料プランを与えてくれる。大きなシナリオは、そのキャンバス上でスパゲッティ状に化けやすい。n8nは技術チームに一番合う（必要なところはコードで、要らないところはノーコードで、しかも自己ホストできる）が、チームにJSONを苦にせず読める人がいることを前提にする。
よく練られたプロンプトのLLM手順を1つ備えたワークフローは、格下のエージェントではない。それは正しいツールであり、より早く仕上がり、しかも予測できる形で失敗する。
| ルート | 向いている相手 | 立ち上げまで | 落とし穴 |
|---|---|---|---|
| ノーコードのエージェント・プラットフォーム | エンジニアのいないプロセスの所有者 | 数日 | 借り物のループ：不透明なデバッグ、ロックイン |
| フレームワークとコード | 開発者 | 1〜2週間 | 評価、監視、保守は自分持ち |
| ワークフロー＋LLM手順1つ | 定義済みのプロセスを持つ人なら誰でも | 数時間 | 自由度の高いタスクはさばけない |
実例で通してみる：受信箱トリアージ・エージェント
共有のサポート受信箱を運営していて、目標がこうだとしよう——入ってくるすべてのメッセージを種類と緊急度でラベル付けし、正しい担当者にルーティングし、安全なところでは下書きで返信する。これをエージェントとして表すとどう見えるか、どのルートで作るにせよ、以下のとおりだ。
- 書き出した目標。「新着メッセージをそれぞれトリアージせよ。ラベルが付き、割り当てられ、下書きが用意されるかエスカレートされたら止まれ。」停止条件は飾りではない——それこそがループをさまよわせずに保つものだ。
- ツール。メッセージを読む。この送信者について過去のスレッドとCRMを検索する。ラベルを付ける。担当者を割り当てる。返信を下書きする。何が抜けているかに注目——送信だ。これは意図的なものだ。
- 1通のメッセージ上でのループ。返金依頼が届く。モデルはそれを読み、その顧客の履歴を検索し、年間サブスクリプションと3月の苦情を見つけ、それを請求／高としてラベル付けし、請求担当者に割り当て、以前の苦情を参照する返信を下書きして、止まる。
- ガードレール。ループ反復回数の上限、メッセージごとの支出上限、そしてエージェントが確信が持てないときは必ず使わなければならない、人間へエスカレートするためのラベル。
さて正直な部分だ。このパイプラインの大半はエージェントではない。ラベル付けとルーティングは分類器＋ルールであり、Makeやn8nが得意とする居心地のよい領分だ。ループがその値打ちを稼ぐのは第3段だけ——検索結果が、下書きが何と言うべきかを決める場面だ。もしその文脈を踏まえた下書き作りにあなたにとっての価値がないなら、ワークフロー版を作って金曜までに片づけよう。
そしてそもそも作る前に、買う側を調べよう。個人の受信箱なら、Shortwaveはすでに平易なプロンプトから、メールの整理・下書き・検索・スケジュール設定をこなす。自分で作る意味があるのは、既製品には知りようのないルーティング規則を持つ共有メールボックスの場合だけだ。すぐ使えるAIエージェント553件のディレクトリで20分を費やせば、あなたのエージェントがすでに存在するかどうかを、安上がりに確かめられる。
壊れるのはいつか、そしてどうやってそれを知るか
エージェントは礼儀正しく失敗する。モデルが間違ったラベルを付けたり、自信たっぷりにたわ言を下書きしたりしても、スタックトレースは出ない——ループは完了し、成功と報告し、被害は数日後に、困惑した顧客スレッドの中で表面化する。
だからこそ可観測性は構築の一部であって、後回しの付け足しではない。LangSmithはエージェントが踏む各ステップのトレースを記録し、失敗を目立たせ、コストとレイテンシを追跡する。Python、TypeScript、Go、JavaのSDKを備える。姉妹フレームワークを使っていようがいまいが動く。Langfuseはそのオープンソースの対応版で、トレーシング、プロンプト管理、評価をひとまとめにし、自己ホストできる。どちらも、運用するか料金を払うかしなければならないもう1つのインフラだ。エージェントを目隠しで走らせるほうが、確実により高くつく。
そうすると、最初の1週間はこんな具合になる——停止条件を伴う目標の一文を書き、エージェントが触れてよいツールを列挙し、フローチャート・テストを実施し、テストが指し示すルートを選ぶ。構築は簡単なほうの半分だ。人間をループから外せるだけの信頼を勝ち取ること、それがこのプロジェクトだ。
よくある質問
コーディングなしでAIエージェントを作れますか？
作れます。Microsoft Copilot StudioやVoiceflowのようなプラットフォームでは、エージェントの目標、データ接続、チャネルを視覚的なインターフェースで定義できます。とはいえノーコードは「作業なし」ではありません——目標を明確にし、ツールを選び、ガードレールを設け、トランスクリプトを確認する作業は依然として必要なので、設定とテストは日単位で見込んでおきましょう。
AIエージェントとチャットボットの違いは何ですか？
チャットボットはメッセージに応答して次を待ちます。エージェントはループの中でツールを呼び出しながら目標に向かって進み、直前のステップが返したものに基づいて次の一歩を自ら決めます。エージェントとして売られている製品の多くは、API呼び出しを1つくっつけただけのチャットボットです。見分ける基準は、システムが自分で次のアクションを選ぶかどうかです。
AIエージェントを作るのに機械学習のスキルは必要ですか？
いいえ。モデルは訓練するのではなく、APIやプラットフォームを通じて呼び出します。最初のエージェントには、機械学習の理論よりも、明確なプロセス定義、まともなプロンプト、そして自分のデータとツールについての知識のほうがはるかに重要です。
初めてのAIエージェントを作るのにどれくらいかかりますか？
LLM手順を1つ備えたワークフローなら、その日のうちに動かせます。ノーコード・プラットフォームのエージェントは、たいてい設定とテストに数日かかります。フレームワーク上でコードを書いたプロトタイプは1〜2週間かかります。どの場合でも尾を引くのは信頼です——出力を評価し、人間のレビューを外す前にガードレールを締めていく作業は、たいてい構築そのものより時間がかかります。