AIエージェントを構築すべきでない時（代わりにすべきこと）

目次

Published August 2026.

TL;DR： ほとんどのAIエージェントのアイデアは、その仕事には不適切なツールです。エージェントのコードを書く前に、私は5つの失格シグナルをチェックします——不安定なプロセス、低い頻度、合否テストが書けないこと、すでに機能しているシンプルなツールの存在、または時間内にゲートを設けられない不可逆的な失敗モードです。これらのどれか一つでも当てはまれば、私は構築しません。代わりに、より安価な代替策の階層を降りていき、その階層のどれも通用しない場合にのみカスタムエージェントに戻ります。

[オペレーターの視点] 私はコンサルティングブランドと、テキサス州プフルーグビルにあるピックルボール施設Picklelandを通じて、本番環境で30以上のエージェントを運用しています。世に出した数と同じくらい、あるいはそれ以上のエージェントのアイデアを却下してきましたが、そのほとんどはアイデアが悪かったからではなく、そのエージェントがその特定の仕事には不適切なツールだったからです。この記事は、「これを作るべきか」が「どう作るか」に変わる前に、私がかけているフィルターです。

デフォルトの答えは「ノー」

私が使っているROIフレームワークは、ある自動化が構築費とメンテナンス費を回収できるかどうかを教えてくれます。それは正しい2番目の質問です。1番目の質問はもっとシンプルで、常に飛ばされています——そもそもこれはエージェントである必要があるのか？ということです。

「エージェント」は、LLMが関わるあらゆるものに対するデフォルトのラベルになりました。15年前に「アプリ」が画面が関わるあらゆるものに対するデフォルトのラベルになったのと同じです。モデルに触れるものすべてが、トリガーを監視して自律的に行動を起こす、常設の自律的なツール呼び出しシステムを必要とするわけではありません。人々が「エージェントを構築する」と呼ぶことの多くは、実際には「本当に良いプロンプトを書いて、それを手動で実行する」ことであり、それは失敗モードではなく——むしろ正しい最終形態であることが多いのです。

私は「カスタムエージェントを構築する」を、選択肢の階層の中で最も高コストな選択肢として扱っており、最初の段ではありません。それに手を伸ばす前に、そのタスクが自ら失格するかどうかを確認します。

エージェントが誤ったツールである5つのサイン

これらのうちどれか一つでも、それだけで私を止めるのに十分な場合がほとんどです。

1. プロセスがまだ安定していない。 ビジネス自体がまだ何を望んでいるか模索中で、ワークフローが過去1か月で2回変わったなら、エージェントは今日のバージョンのプロセスを固定してしまいますが、それはまた変わろうとしています。プロセスが変わるたびにプロンプト、ツールスキーマ、評価セットを書き直すことになります——つまり、ビジネスを運営する代わりにエージェントをメンテナンスすることになります。四半期の間安定するまでは手動で運用し、それから落ち着いたバージョンを自動化してください。

2. 頻度が低すぎて元が取れない。 年に2回しか発生しないタスクは、たとえ構築後にどれほどうまく機能しても、構築時間・テスト時間・評価セットを正当化するだけの実行回数が積み上がりません。低頻度で構築の手間が大きいというのは、自動化にとって最悪に近い象限です——構築コストを全額支払いながら、節約分はほとんど得られません。

3. 合否テストが書けない。 正しい出力がどのようなものかを、プログラムでチェックできるほど事前に説明できないなら、そのための評価ハーネスを構築することはできません——そして評価できないエージェントは、目隠しで飛んでいるエージェントです。純粋な好み（「これは自分らしく聞こえるか」）や、一貫したルーブリックの裏付けがない純粋な判断力に依存するタスクは、手動のままにするか、毎回人間によるレビューを挟むしかなく、それでは自動化する意味がなくなります。

4. すでにシンプルなツールがその仕事をこなしている。 エージェントをスコーピングする前に、スプレッドシートの数式、1つのLLMステップを持つZapier/Make/n8nのワークフロー、あるいは保存済みのプロンプトで何が得られるかを問うてください。正直な答えが「9割方そこまで行く」なら、残り1割のために、独自のインフラ・監視・メンテナンス税を伴うエージェントを立ち上げる正当性はまずありません。フィルタービューと定期的なカレンダーリマインダーで同じようにうまく解決できたはずのタスクのために、エージェントをスコーピングしてしまったことが私にもあります。

5. 失敗モードが不可逆的で、ゲートを適切に構築する時間がない。 一斉メール送信、返金、公開投稿など、一部の行動は取り消せません。Human-in-the-loopゲートはまさにこのために存在しますが、誰も実際にはレビューしない急ごしらえのゲートは、自動化がまったくないよりも悪い結果になります——監督が実体を伴わずに見た目だけ存在することになるからです。ゲートを正しく構築し人員を配置する時間がないなら、それはゲートを省略していい理由ではなく、速度を落とすべきというシグナルです。

5つのどれにも当てはまらない場合——プロセスが安定していて、十分な頻度で実行され、正しさを定義でき、それをカバーするシンプルなツールがなく、失敗モードが可逆的であるか適切にゲートされている場合——それはROIの計算を回してみる価値があります。

構築前に上る階層

タスクが5つのチェックのどれか一つに失敗したとき——あるいはそこまで至る前でも——私はこのリストを順番に降りていき、実際に問題を解決する最初の段で止まります。

1. モデルに直接聞く。 ラッパーなし、ツール呼び出しなし、常設インフラなし。Claudeを開き、コンテキストを貼り付け、質問して、答えを使う。これは人々が思っている以上に多くの単発・時々発生するタスクをこなします。一度きりしか起きないことに対してさえ、「エージェント」の本能が働いてしまうからです。

2. 保存済みプロンプトまたはプロジェクト指示。 同じ種類の依頼が繰り返し発生するが、各回で人間が入力を集めて出力をレビューする必要があるなら、トリガーを自動化するのではなく、プロンプトをテンプレートとして保存してください——プロジェクト指示、カスタム指示セット、スニペットなどです。インフラなしで、エージェントの一貫性というメリットが得られます。

3. 1つのLLMステップを持つノーコード自動化ツール。 本当にトリガー（新しいフォーム送信、シート内の新しい行など）を必要とするが、ロジック自体はシンプルなタスクには、中間に1回のモデル呼び出しを挟んだワークフローツールの方が、カスタムコードよりも構築・維持のコストが劇的に低く済みます。トリガーが標準的で、量が低〜中程度であれば、私はカスタムインフラよりも先にこちらに手を伸ばします。

4. 手動で実行するテンプレート。 一部のプロセスは、自動化よりもチェックリストの恩恵の方が大きいものです。価値がスピードではなく、人間が各ステップを考え抜くことにあるからです。考えること自体が目的であるタスクから、思考を自動化で奪ってはいけません。

5. 外注。 評価セットを構築・維持する時間がない、本物の曖昧さや判断を伴う仕事には、人——VA、専門家、プロダクタイズドサービスの提供者——の方が、まだチューニング中のエージェントよりも早く稼働させられ、途中で修正しやすいことがよくあります。

6. それでも足りない場合にのみ：カスタムエージェント。 階層を降りていってもどれも通用しない場合——負荷下で本物の判断力がトリガーに必要で、手動や外注では処理しきれない量があり、ROIの計算をクリアする場合——それこそが、独自の信頼性スタックを備えた専用エージェントが構築コストに見合うタイミングです。

2週間のシャドウテスト

境界線上にあるもの——5つのチェックは通過するが、まだ確信が持てないもの——については、構築にコミットする前に2週間のシャドウテストを行います。自分自身でそのタスクを行い、モデルを自律システムとしてではなくコパイロットとして使います。最終的にエージェントに与えるのと同じプロンプト、同じ入力を使いますが、どこかに送る前にすべての出力を自分で読みます。

そのテストから2つのことが分かります。第一に、モデルが自分の求める品質基準でそのタスクを実際にうまくこなせるかどうかです——出力の半分を手で書き直しているなら、他のすべての条件に関係なく、そのタスクはまだ自動化する準備ができていません。第二に、本物の評価セットです。2週間分の入力と、自分が正しいと判断した出力は、評価ハーネスに必要なものそのものであり、構築を決める頃には大抵すでに無料でそれを集め終えています。

シャドウテストは、本番環境に入る前にエッジケースを表面化させる効果もあります。入力の15%が特別な処理を必要とすることを、手動トライアルの間に発見する方が、エージェントをリリースした後に顧客からのクレームで発見するよりもはるかに安く済みます。

アイデアを却下した後に適用するルール

エージェントのアイデアを却下することは、根底にある問題を消し去ることとは違います。タスクが今のところ自ら失格している場合——プロセスがまだ変化中である、量がまだ少なすぎるなど——私はその理由を書き留め、大まかな再確認のタイミングを設定します（通常は単なる日付ではなく、「予約が週50件を超えたら再確認する」のような具体的なトリガーに紐づけます）。一度却下されて二度と見直されないエージェントのアイデアは、誰も二度評価したことを覚えていない恒久的な手作業へと静かに変わっていきます。

逆方向の規律も同じくらい重要です。5つのチェックとROIの計算をクリアしたアイデアが、自動的に今日構築されるわけではありません。それは他のすべてのものと同じキューに入り、すでに元が取れると証明されている自動化と比較して優先順位付けされます。フィルターを通過することは、タスクが列に並ぶ権利を得ることであり、優先順位付けの免除ではありません。

FAQ

これは単なる自動化への反論ではないのですか？

いいえ——これは、最もコストの高い形の自動化をデフォルトにすることへの反論です。上記の階層にある代替策のほとんどは、それでも自動化です。ただ、より軽量なだけです。私自身、数十のエージェントを本番環境で運用しています。要点は構築を避けることではなく、保存済みプロンプトやノーコードワークフローが、構築・メンテナンスコストのほんの一部で同じ結果を得られるときに、いきなり「カスタムエージェントを構築する」に飛びつくのをやめることです。

タスクの量が後で明らかに増える場合はどうすればいいですか？

それは、現在の数字より先回りして構築する正当な理由です——この例外はROIフレームワークで扱っています。ただし、それが上記の5つのシグナルを覆すわけではありません。プロセスがまだ不安定だったり、正しい出力をまだ定義できていなかったりするなら、量が増えることは、より大きな規模で壊れたエージェントをメンテナンスすることを意味するだけです。まず不安定さとテスト可能性を解決してください。スケールは、それらが解決された後により早く構築する理由にはなりますが、それらを飛ばす理由にはなりません。

ノーコードツールのステップが「十分に良い」のか、カスタムコードが必要なのか、どう判断すればいいですか？

まずは試してみて、たとえ非公式なものであっても評価セットに照らして測定してください。ノーコードのLLMステップは、単一目的・単一入力のタスクをうまくこなします。複数ステップのツール利用、実行をまたぐ永続的な状態、あるいはツールのビルダーがきれいに表現できない条件分岐が必要になると、途端に無理が出てきます。その壁にぶつかったら、それこそがカスタムインフラに移行すべき本物のシグナルであり、最初からそこに手を出す理由にはなりません。

内部ツールと顧客向けツールとで、これは違う適用のされ方をしますか？

5つのシグナルは同じように適用されますが、リスクの大きさが異なります。プロセスが不安定な内部ツールは、壊れたときに自分のチームの時間を無駄にするだけです。プロセスが不安定な顧客向けツールは、あなたの評価セットになるつもりなどなかった人々からの信頼を損ないます。私は特にシグナル5について、顧客向けの自動化にはより厳しいバージョンを適用しています——ミスの向こう側にいるのが同僚ではなく見知らぬ人である場合、「適切にゲートされている」の基準はより高くなります。

エージェントのアイデアを却下する最も多い理由は何ですか？

シグナル3——きれいな合否テストが書けないことです。これはスコーピング中に最も見落としやすいものです。正しい出力が実際にどのようなものかを事前に書き出そうとするまでは、タスクがよく定義されているように感じられるからです。それを一文か二文で言い表せないなら、そのエージェントは評価不能であり、つまり改善不能であり、つまりまだ構築すべきではないと分かります。