AI導入戦略

AIエージェントとは｜チャットボットとの違いと、運用で壊れた実例

AIエージェント 生成AI 自動化 運用
AIエージェントの定義と従来のチャットボットとの違いを整理したうえで、編集部が実際の運用で踏んだ失敗を記録する。並列に起動した6体が成果ゼロで終わった事例と、そこから引いた「任せる作業と任せない作業」の線引きを実測つきでまとめた。

目次

この記事の立ち位置

AIエージェントの解説は増えたが、多くは概念の整理と将来の可能性に寄っている。実際に業務へ入れたときに何が起きるかを書いたものは少ない。

編集部は自社で9つのサイトを運用しており、その保守と改善にエージェントを日常的に使っている。対象は記事メディアから業務システムまで幅がある。うまくいった話より、うまくいかなかった話のほうが再現性があるため、本記事は失敗の記録に分量を割く。

本文中の数値は2026年9月20日時点の自社実測である。

なお本記事は「何ができるようになるか」ではなく「何が壊れるか」に重心を置いている。導入の判断で時間を奪われるのは後者だからである。できることの一覧は製品ごとの公式資料が最も正確で、更新も速い。

AIエージェントとは何か

目的を与えられると、そこに至る手段を自分で選び、道具を使い、結果を確かめながら手順を進める仕組みを指す（Anthropicによるエージェント設計の解説でも同様の枠組みが示されている）。

「答える」から「行う」への変化

従来の生成AIは、問いに対して文章を返すものだった。エージェントは、目的に対して行動を返す。

たとえば「このサイトの表示速度が落ちている原因を調べて」と依頼したとき、従来の使い方では原因の候補を列挙した文章が返る。エージェントの場合は、実際にサイトへアクセスし、応答時間を測り、設定ファイルを読み、原因を絞り込んだうえで結果を返す。

一度で終わらない

もう1つの特徴は、反復である。最初の手が外れたら、別の手を試す。結果を見て次を決める。この繰り返しが自動で回る。推論と行動を交互に繰り返すこの方式は、ReAct（推論と行動を組み合わせる手法）として学術的にも整理されている。

この性質が便利さの源であると同時に、問題の源でもある。外れた方向に反復すると、間違った作業が積み上がる。

どこまでが「エージェント」か

明確な線引きはないが、実務上は次の3つが揃っているかで判断すると分かりやすい。

  1. 目的を与えると、手順を自分で決める
  2. 外部の道具（ファイル操作、検索、API呼び出し）を使える
  3. 結果を確認して、次の手を決められる

3つ目が無いものは、手順が固定された自動化に近い。

なお実務では、この3つが揃っていても「使える」とは限らない。揃ったうえで、結果を人が検証できる形になっているかが分かれ目になる。検証できない自律性は、速く進むぶん、間違った方向にも速く進む。

チャットボット・RPAとの違い

チャットボットとの違い

チャットボットは、問いに対して答えを返す。会話が続いても、それぞれの応答は独立している。

エージェントは、目的の達成に向けて状態を持ちながら進む。途中で得た情報を次の判断に使う。

実務上の違いとして大きいのは、失敗の現れ方である。チャットボットの失敗は「誤った答え」として現れ、読めば気づける。エージェントの失敗は「誤った作業が実行された」として現れ、結果を確かめないと気づけない。

RPAとの違い

RPAは、あらかじめ定めた手順を正確に繰り返す仕組みである。画面の特定の位置をクリックし、特定の欄に値を入れる。手順が変わると動かなくなる。

エージェントは手順を自分で決めるため、多少の変化には対応する。一方で、毎回同じ手順を踏む保証は無い。

したがって、再現性が必要な作業はRPAや通常のプログラムのほうが向いている。エージェントが向くのは、手順が事前に決められない作業である。

使い分けの目安

編集部では次のように分けている。

作業の性質 向いている手段
毎回同じ手順で、結果も一定 通常のプログラム
手順は固定だが、画面操作が必要 RPA
手順が対象によって変わる エージェント
判断そのものが目的 人

最後の行が重要である。判断を委ねると、次節で述べる失敗が起きる。

実務では、1つの業務がこの4行のどれか1つに収まることは少ない。多くは混在しており、工程ごとに分けて考えたほうが現実に合う。たとえば資料の収集はエージェント、内容の採否は人、定型の転記は通常のプログラム、という組み合わせになる。業務単位ではなく工程単位で切ると、任せられる範囲が見えやすくなる。

エージェントを構成する4つの要素

実装の詳細は製品によって異なるが、構成要素は概ね共通している。

1. 目的の理解

与えられた指示を、実行可能な手順に分解する部分である。ここで指示が曖昧だと、分解の段階でずれる。指示を段階的な手順に分解する考え方は、Chain-of-Thoughtプロンプティングの研究でも扱われている。

編集部の経験では、完了の条件が書かれていない指示が最も多く失敗する。「調べて」だけでは、どこまで調べれば終わりかが決まらない。

2. 道具の利用

ファイルの読み書き、コマンドの実行、外部サービスの呼び出しなど、実際に環境へ働きかける部分である。この仕組みを標準化する試みとしてModel Context Protocolがあり、ツール利用の基本的な仕組みも各社の資料で解説されている。

道具の権限設計が運用上の要点になる。編集部の環境では、クラウドサービスの操作権限が用途ごとに分かれており、想定より狭い範囲しか許可されていなかったことが作業中に判明した例がある。権限は事前に確かめておく。

3. 記憶と文脈

作業の経緯を保持する部分である。長い作業では、保持できる量に上限がある。

編集部では、記録を外部のファイルに持つ設計にしている。作業の切れ目で要約し、それ以降は要約を土台にする。全部を抱え続けると、応答のたびに過去すべてを読み直すことになり、費用と時間が増える。

4. 完了の判定

目的が達成されたかを判断する部分である。ここが最も壊れやすい。

達成の基準が指示に含まれていないと、エージェントは「それらしいところ」で止まる。そして「完了しました」と報告する。

運用で壊れた実例

編集部が実際に踏んだものを挙げる。

6体を並列で起動し、成果がゼロだった

47都道府県の公的制度を調べる作業を、並列に起動した6体のエージェントへ分担させた。結果は成果ゼロだった。

原因は、各エージェントがさらに別のエージェントを起動し、その結果を待たずに終了していたことだった。指示に「さらに別のエージェントを起動してはならない」という制約が書かれていなかった。

やり直す際は、エージェントに任せるのをやめ、機械的に検証できるスクリプトに置き換えた。出典のURLが応答を返すか、本文に制度名が含まれるか、公的なドメインか、順位の主張が混ざっていないか、を機械で確かめる形である。この方式で9件の誤りを事前に弾いた。

弾かれた内容には、出典URLが付いていないもの、終了済みのイベント告知を機関案内として提出したもの、二次的なまとめサイトを一次情報として提出したもの、そして2つの県が両方「全国12位」と報告して両立しないもの、が含まれていた。

報告と成果物が一致しない

エージェントが「記録を残した」と報告した作業について、後日ファイルを確認すると0バイトだった。書き込み処理が途中で切れていたが、報告はそのまま完了として返っていた。

ファイル名は存在するため、一覧にも履歴にも現れる。中身だけが無い。存在確認をファイル名で行っていると、この種の欠落は最後まで見つからない。大きさも併せて見る必要がある。

判断を委ねると安全側に倒れない

編集部の記録に、指示の中の禁止事項と条件付きの指示が矛盾していた例がある。このときエージェントは、止めるのではなく実行する側に倒した。

矛盾があった場合にどちらへ倒すかは、指示に書かれていなければ決まらない。危険な操作については、迷ったら止まる、と明示しておく必要がある。人間の担当者であれば常識で止まる場面でも、明文化されていない常識は共有されないと考えたほうが安全である。とくに不可逆な操作では、この差が事故の分かれ目になる。

検証を任せたら、検証が空振りしていた

エージェントに検証まで任せた場合、検証結果そのものが信用できるかという問題が出る。

編集部が2026年9月20日の1日で踏んだ例では、ページの重複を調べる検証が「0群 / 0ページ / 問題なし」と表示して正常終了した。存在しないディレクトリを検査していただけだった。検証は成功を返し、エラーは出ていない。

同じ日に、計測タグの発火を2.5秒の窓で確認して、正常な3サイトを「発火していない」と誤って判定した例もある。窓を9秒に広げると3サイトとも正常だった。

さらに、管理対象を一覧で取得して10件と数えたが、実際は26件あった。既定のページサイズで打ち切られていたのに、総件数と突き合わせていなかった。見落とした4件に自動デプロイの設定が含まれており、後の操作で予期しないビルドが4本走る原因になった。

1日でこの種の誤りが9件出た。9件のいずれもエラーメッセージが出ていない。 エージェントに検証を任せる場合、検証が対象に届いているかを別に確かめる必要がある。

起動したこと自体を成果と読む

エージェントを起動して待ち、完了通知を受け取ったところまでは確認したが、その中で実行されたはずの処理が例外で落ちていた、という例もあった。記録には問題が残らないため、成功と区別が付かない。

実行ログを直接見て、処理が完走し例外が発生していないことを確認して初めて確定した。

任せる作業と任せない作業

上の失敗から、編集部では線引きを明文化した。

任せて機能する作業

完了の条件が事前に書ける機械作業である。

  • 大量のファイルを読んで要約する
  • 同じ規則にもとづく反復的な編集
  • 公開データの収集
  • 検証コマンドの実行と結果の集約

いずれも「何が揃えば終わりか」を先に書ける。

任せない作業

判断が結果を左右する作業である。

  • 設計の選択
  • 根本原因の特定
  • 二度失敗した問題の再挑戦
  • 仕様が曖昧な部分の解釈

この4つを任せると、それらしい成果物が返ってくるが、方向が違っていることに後で気づく。編集部では、これらは自分で解き、閉じた作業だけを任せる運用にしている。

線引きの基準

抽象的には、行動の可逆性と、検証の安さで決めている。

元に戻せて、正しさを安く確かめられる作業は任せてよい。元に戻せない、あるいは確かめるのに人の判断が要る作業は、人が関与する。

この基準は、相手が人間でも同じである。役割で分けるのではなく、操作の性質で分ける。

完了の確かめ方

報告を完了の証拠として扱わない。編集部で使っている確認手段を挙げる。

成果物の実在を見る

ファイルが存在するか、変更が記録されているか、コマンドが成功を返すか。報告と実在は別の量である。

具体的には、ファイル一覧の表示、変更状態の確認、終了コードの確認を行う。

実行ログを見る

デプロイや処理の実行が成功したという表示だけでは、処理が意図どおり動いたことにならない。ログを取得して、完走したことと例外が発生していないことを確認する。

壊れた対象で試す

検証の仕組みを用意したら、欠陥のある対象に当てて実際に落ちることを確かめる。落ちなければ、その検証は何も見ていない可能性がある。

編集部では、過去に配信した壊れたバージョンを対照として保存している。新しい検証をそれに当てると4件が失敗し、正常なバージョンでは15件すべてが成功した。区別できていることが確認できた。

一度失敗したら再委任しない

同じ作業を同じ相手に投げ直すと、同じ理由で失敗する確率が高い。編集部では、委任先が一度失敗したら、自分で解くか、機械的な手段に置き換えるようにしている。

並列化の判断

複数のエージェントを同時に動かせるが、体数を増やすこと自体に効果は無い。

縮むのは最長経路だけ

全体の所要時間は、最も時間のかかる経路で決まる。その経路が分割できないなら、他をいくら並列にしても全体は縮まない。

編集部では、並列化する前に「最長経路はどれか」「それは分割できるか」を確かめるようにしている。

評価の指標

並列化の良し悪しは、体数ではなく次の2つで見ている。

1つ目は、成功1件あたりの費用である。やり直しを含めて計算する。失敗して再実行した分を除くと、実態より良く見える。

2つ目は、読んだ量と返した量の比である。大量に読んで少量を返すなら、分担の意味がある。読んだ量とほぼ同じ量を返すなら、文脈を圧迫しているだけになる。

依存がある作業は並列にしない

前の結果を次が使う構造では、並列化しても待ちが発生する。この場合は、前段の結果が出た順に後段を始める形にすると、待ちが減る。

費用の構造

エージェントの費用は、出力した文章の量ではなく、読み直した文脈の量で決まる部分が大きい。

編集部が自社の利用状況を集計したところ、消費の大半は新しい生成ではなく、既存の文脈の読み直しだった。長い作業ほど、毎回の応答で過去のやり取り全体を読み直す量が増える。

費用を抑える3つの運用

1つ目は、作業の切れ目で文脈を整理することである。ひとつのまとまりが終わったら要約し、以降はそれを土台にする。

2つ目は、巨大な出力を文脈に入れないことである。画像や長いログをそのまま貼ると、以降すべての応答で読み直される。ファイルに書き出し、必要な部分だけを読む。

3つ目は、読み込みを伴う作業を別の文脈に逃がすことである。要約だけを受け取れば、元の文脈は汚れない。この仕組みはサブエージェントによる委任実行として提供されている製品もある。

使うモデルを作業で分ける

判断を伴う部分と、機械的な部分で同じモデルを使う必要は無い。編集部では、機械的な作業には軽いモデルを明示的に指定している。指定を省くと、上位のモデルが引き継がれて費用が膨らむ。

指示の書き方で結果が変わる

エージェントの成績は、モデルの性能（GPT-4のテクニカルレポートのように性能自体は各社が報告している）より指示の書き方で決まる場面が多い。編集部の実測から、効いたものを挙げる。

抽象語ではなく観測できる語を使う

判定を伴う作業で、抽象的な性質を尋ねると結果が固着する現象がある。編集部の判定層では、「この文章は自己完結しているか」と尋ねたとき、すべての対象に同じ値が返った。判別していない。

「他の箇所を参照させる表現があるか」という、観測できる事実を尋ねる形に変えたところ、対象によって値が変わるようになった。良し悪しではなく、欠陥の有無を尋ねる。

具体名を並べる

作業の対象を探させるとき、抽象的な説明より具体名を並べたほうが当たる。編集部の測定では、問いに対象の名前を並べた場合と抽象語で書いた場合で、正解率が0.473から0.595に変わった。

「認証まわりを調べて」より「この関数がどこから呼ばれているか」のほうが速く、正確である。

禁止事項を明示する

前述の6体が全滅した事例は、「さらに別のエージェントを起動しない」という制約が書かれていなかったことが原因だった。

起きてほしくない挙動は、起きてから直すより先に書いたほうが安い。ただし禁止事項を増やしすぎると、条件付きの指示と矛盾しやすくなる。矛盾したときにどちらへ倒すかも併記しておく。

完了の条件を1行で書く

「調べて」ではなく「このコマンドが成功を返したら完了」と書く。書けない場合は、作業の定義が固まっていない可能性が高い。編集部では、書けない作業は任せずに自分で着手するようにしている。

チームで使うときの取り決め

個人で使う場合と、複数人が同じ環境で使う場合では、必要な取り決めが変わる。

確認が必要な操作を有限で列挙する

編集部では、人の確認を必要とする操作を6つに限定している。共有ブランチへの反映、本番環境への適用、第三者に届く送信、再生成できないデータの削除、費用と権限に関わる操作、対外的な文面の変更である。

有限にしたことが要点である。一覧に載っているかだけで判定でき、載っていないものは進めてよいと決まる。「重要な操作は確認する」という書き方だと、何が重要かの判断が毎回発生して作業が止まる。

他の作業者の変更を壊さない

同じ環境で複数の作業が並行すると、未コミットの変更を巻き込む事故が起きる。編集部でも、変更を記録する際に、別の作業者が編集中のファイルを一緒に含めてしまった例があった。

対策として、記録の対象を明示的に指定し、一括で全部を含めない運用にしている。また、ファイルが読み込み後に変更されていた場合に警告が出る仕組みが、意図しない上書きを実際に防いだ。こうした仕組みはClaude Codeのリポジトリで公開されている実装にも見られる。

記録の置き場を決めておく

誰がどこに記録を書くかを決めていないと、同じ内容が複数の場所に分散する。編集部では、製品固有の知見はその製品の資料に、どこにも属さない横断的な規律だけを共通の置き場に、と分けている。

判断の基準は「その記録を必要とする人がどこを見に来るか」である。

エージェントが向く業務・向かない業務

導入の検討段階で、対象業務の見極めに使える観点を挙げる。

向く業務の条件

3つ揃うと成果が出やすい。

1つ目は、完了が機械で判定できること。テストが通る、ファイルが生成される、値が一定の範囲に入る、といった形で終わりが決まる。

2つ目は、やり直しが安いこと。間違えても元に戻せる、あるいは捨てて作り直せる。

3つ目は、手順が対象ごとに変わること。毎回同じ手順なら通常のプログラムのほうが速く安い。

向かない業務

逆に、次のいずれかに当たる業務は慎重に扱う。

結果が外部に届く業務。 送信してしまえば取り消せない。編集部では、対外的に届く操作は人の確認を必須にしている。

判断そのものが成果物である業務。 方針の決定、優先順位の決定、トレードオフの選択。それらしい答えは返るが、根拠の検証に人の時間が同じだけかかる。

正解が事後にしか分からない業務。 完了を判定できないため、作業が終わったかどうかも分からない。

段階的に広げる

いきなり広い範囲を任せるより、完了条件が明確な作業から始めて、実績を見ながら広げるほうが安全である。編集部でも、失敗のたびに範囲を狭め、検証手段を足してから再び広げる、という進め方をしている。

範囲を広げる判断材料は、成功率ではなく失敗したときに気づけたかである。気づけない失敗が出た場合、範囲より先に検証手段を直す。

実際の配分

参考として、編集部の1日の作業配分を挙げる。2026年9月20日に行った作業のうち、エージェントに任せたのは大量のファイル読み込みと、8キーワード分62ページの構造分析、225語の需要測定だった。いずれも完了条件が機械で判定できる。

一方、どのキーワードを狙うか、記事の構成をどうするか、対外的な文面に何を書くかは任せていない。文面については、公開前に人が確認する工程を必ず挟んでいる。

結果として、作業量の多い部分は自動化しつつ、方向を決める部分は人が持つ形になった。この配分は業務によって変わるが、判断の総量は減らないという前提で設計すると見積もりがずれにくい。

導入前に決めておくこと

着手前に決めておくと手戻りが減るものを挙げる。

1つ目、完了の条件。何が揃えば終わりかを、作業ごとに1行で書く。

2つ目、人の確認を残す操作の一覧。有限の列挙にする。「重要なものは確認」という書き方だと毎回判断が発生する。

3つ目、矛盾したときにどちらへ倒すか。危険な操作は、迷ったら止まる側に倒すと明示する。

4つ目、任せない作業の一覧。設計判断、根本原因の特定、二度失敗した問題は、任せない側に置く。

5つ目、失敗の記録をどこに書くか。同じ失敗を繰り返さないための材料になる。書く内容は、何が起きたかと、なぜ最初に気づけなかったかの2つで足りる。

同じ並列でも、仕様が閉じていれば成功する

前述の「成果ゼロで終わった6体」と対照になる記録がある。

編集部が公開済みの記事へ外部の出典を追加する作業で、5体を並列に起動した。結果は5体すべてが完了し、目標としていたリンク数をすべて満たした。1体あたりの消費は7.1万から7.9万トークン、所要時間は97秒から190秒だった。

成果ゼロで終わったときとの違いは、体数でも模型でもない。渡した仕様が閉じていたかどうかである。

閉じた仕様に含めた3つ

使ってよい材料を列挙した。 使用してよい出典を14本、すべて事前に到達を確認したものだけ列挙し、「これ以外は使わない。創作しない」と明記した。判断の余地を残さなかった。エージェントに材料を探させると、存在しないものを作る危険が生じる。探させないことが、この作業では正解だった。

やってはいけないことを否定形で書いた。 「既存の本文の主張・数値・段落構成を変えない。リンクを足すだけ」。禁止事項は、肯定形の指示より確実に効く。「丁寧に作業すること」は解釈の幅が広すぎて機能しない。

完了の確かめ方を指定した。 検証に使うコマンドをそのまま書き、その出力を報告に含めさせた。報告が主観にならず、こちらで検算できる。

失敗した側に欠けていたもの

成果ゼロで終わった側は、この3つがいずれも欠けていた。材料を自分で探させ、達成すべき状態を言葉で説明し、完了の判定を相手に委ねていた。

委任が失敗したとき、疑うべきは委任先ではなく仕様である。 同じ模型、同じ体数で、仕様の書き方だけを変えると結果が変わる。

この線引きは、作業を任せる相手が人間でも同じである。何を使ってよいか、何をしてはいけないか、どうなったら終わりか。この3つが決まっていない作業は、誰に渡しても戻ってこない。

まとめ

AIエージェントは、答えを返す仕組みではなく、行動して結果を返す仕組みである。チャットボットとの差は、失敗が「誤った答え」ではなく「誤った作業」として現れる点にある。読めば気づけるものから、確かめないと気づけないものへ変わる。

編集部の運用で最も効いたのは、任せる範囲を狭めたことだった。完了の条件が事前に書ける機械作業は任せ、判断は任せない。並列に6体を起動して成果ゼロだった経験が、その線引きの出発点になっている。

報告は完了の証拠にならない。成果物の実在、実行ログ、壊れた対象での検証で確かめる。この3つは特別な道具を必要としない。

明日から試せる3つ

本記事を一度に取り入れる必要はない。効果が出やすい順に3つ挙げる。

1つ目は、完了の条件を1行で書くことである。任せる作業ごとに「何が揃えば終わりか」を書く。書けない作業は、まだ任せる段階に無い。

2つ目は、報告ではなく成果物を見る習慣をつけることである。ファイルの実在、変更の記録、終了コード。どれも数秒で確認できる。

3つ目は、失敗したときに気づけたかを記録することである。成功率より、気づけなかった失敗の件数のほうが、範囲を広げてよいかの判断に効く。

3年後を待たずに始められること

エージェントの能力は今後も変わる。ただし本記事で挙げた失敗の多くは、モデルの性能が上がっても消えない種類のものである。完了条件が書かれていない、検証が対象に届いていない、報告を実在と取り違える。いずれも運用側の設計に属する。

逆に言えば、この部分を先に整えておけば、モデルが良くなったときにそのまま恩恵を受けられる。検証の仕組みは、モデルを乗り換えても再利用できる資産になる。

編集部では、AI導入の相談や、導入後に効果が測れているかの点検も行っている。エージェントを入れたが成果が見えない、という段階の相談については、サービス案内を参照してほしい。

参考にした一次資料

よくある質問

AIエージェントとチャットボットは何が違いますか。

答えを返すか、行動して結果を返すかの違いです。チャットボットは問いに対して文章を返しますが、エージェントは目的を与えられると、必要な手段を自分で選び、道具を使い、結果を確かめて次の手を決めます。一度の応答で終わらず、目的が達成されるまで複数の手順を回す点が本質的な差です。

AIエージェントに業務を任せると品質は落ちませんか。

任せる作業の性質によります。編集部の運用では、完了の条件を事前に書ける機械作業（大量の読み込み、反復編集、データ収集、検証の実行）は任せ、設計判断や根本原因の特定は任せない、という線を引いています。実際に判断を伴う調査を並列の6体に任せて成果ゼロで終わった記録があり、その後は範囲を狭めました。

エージェントを並列で動かせば速くなりますか。

分けられる作業であれば速くなりますが、体数を増やすこと自体には効果がありません。編集部では、作業時間の最も長い経路が縮むかどうかで並列化を判断しています。縮まない並列化は、費用と管理の手間だけが増えます。

エージェントが「完了しました」と報告したら、終わっていますか。

報告は完了の証拠になりません。編集部の実測では、報告を受け取った作業の成果物が存在しなかった事例があります。完了はファイルの実在、変更の記録、コマンドの終了コードで確認します。本記事の「完了の確かめ方」で具体的な手順を挙げています。

関連する取り組み

CONNECTED SERIES
AIで投資の壁を越える
18 本の実装記録。AI 投資の「予測不能」と言われる 9 つの壁を、コードと実データで検証した連載。
note で読む →
CONSULTING
AI導入の無料相談
ALLFORCES が、本記事のような失敗パターンを回避する AI 導入支援を提供しています。まずは課題を聞かせてください。
問い合わせる →

AI導入・AIO実装のご相談は無料相談へ。支援内容はサービス概要をご覧ください。