AIエージェントのデメリット｜設計で消えるものと、消えないもの

この記事は、AIエージェントの導入を検討していて、進める前に不利な点も把握しておきたい経営者・AI推進担当に向けたものです。製品ごとの優劣ではなく、エージェントという仕組みに付いてくる不利益を扱います。読み終えたとき、どこまでを設計で潰せて、どこからは受け入れる話になるのかが分かる状態を目指します。

生成AIのデメリットとして語られるのは、誤った内容を書く、情報が外部へ出る、費用がかかる、といった点です。AI導入のデメリットで扱ったとおり、多くは運用で小さくできます。エージェントの場合、ここに実行権限が加わります。誤りが文章の中で止まらず、送信や登録や削除として社外へ出ていきます。

結論：8つのうち5つは設計で消え、3つは残る

エージェント固有の不利益を整理すると8つになります。このうち5つは、権限の切り方・停止手順・記録の取り方で消せます。残る3つは任せるという判断そのものに含まれており、消そうとすれば任せる意味が消えました。先に3つを見て、受け入れられるかどうかを判断するほうが早く済みます。

区分	内容	扱い
消える	権限が広すぎて想定外の操作に届く	読み取り専用から始め、必要になった操作だけ足す
消える	暴走に気づいても止め方が分からない	停止の手順と担当を、動かす前に決める
消える	何をしたのか後から追えない	操作の記録が残る構成を選ぶ
消える	従量課金が読めないまま膨らむ	上限と通知を契約時に設定する
消える	退職者の権限が残り続ける	人の退職手順にエージェントの棚卸しを入れる
残る	誤りが1件で終わらず連鎖する	影響範囲を小さく保つ以外にない
残る	判断の過程を人が完全には再現できない	結果を点検する設計にする
残る	現場が確認をやめて鵜呑みにしていく	点検の担当と頻度を決め続ける

誤りが連鎖する、という性質は消せない

生成AIが誤った文章を書いたとき、被害はその文章1つに留まります。人が読んで気づいた時点で、そこで終わりです。エージェントは次の処理へ進むため、最初の誤認識が後続の操作の前提になります。在庫数を読み違えれば発注が走り、宛先を取り違えれば送信まで到達します。

OWASPはこれを過剰なエージェンシー（Excessive Agency）という項目で整理しており、原因を権限・機能・自律性の3つに分けています（OWASP Top 10 for LLM Applications、確認日 2026年10月5日）。権限と機能は設計で絞れます。自律性だけは、絞りすぎると人が全部確認することになり、導入の目的が消えます。

そこで現実的なのは、連鎖を止めるのではなく、連鎖が届く範囲を狭くする作りです。1回の実行で触れるデータを限定し、金額や件数に上限を置きます。上限に当たったら止まる、という設計であれば、誤りが起きても損害が有限になります。

判断の過程は、人が完全には再現できない

なぜその操作を選んだのかを、エージェントは説明文として出力します。ただしその説明は、内部の計算をそのまま書き起こしたものではないという点に注意が要ります。同じ入力でも別の説明が出ることがあり、説明と実際の挙動が一致している保証もありません。監査で「なぜこの処理をしたのか」を問われたとき、再現できる形で答えられないという状態が起こります。

この点は、過程ではなく結果を点検する設計へ切り替えることで扱えます。どういう判断をしたかではなく、何に触れて何を変えたかを記録しておき、その記録を人が読みます。AIエージェントのログ管理で扱ったとおり、記録は後から足せません。動かす前に、残る構成かどうかを確かめておく必要があります。

現場が確認をやめていく

導入直後は全員が出力を疑って見ます。3か月ほど大きな失敗が出ないと、確認が形だけになります。これはエージェントの欠陥ではなく、人のほうが先に慣れるために起きます。精度が高いほど早く進むという性質があり、品質が良いことが確認の形骸化を早めるという逆転が起こります。

総務省の情報通信白書は、AIの利活用において人が最終的な判断に関与する体制の必要性を繰り返し示しています（令和8年版情報通信白書、確認日 2026年10月5日）。体制を作ること自体より、作った体制が1年後も動いているかのほうが難しい部分です。

対策は点検の仕組み化しかありません。月に一度、無作為に数件を抜き出して人が追い直す時間を業務として置きます。誰かが気づいたら確認する、という形にすると、気づく人がいなくなった時点で止まります。

設計で消える5つは、動かす前にしか決められない

権限・停止・記録・費用・棚卸しの5つは、いずれも後から足そうとすれば作り直しです。動かし始めてから権限を絞ると、既に動いている処理が止まります。記録を後から有効にしても、過去の操作は戻ってきません。

順序としては、読み取り専用で始めて、必要になった操作だけを1つずつ足していく形が扱いやすくなります。具体的な進め方はAIエージェントの導入手順に、権限の切り方はAIエージェントの権限設計にまとめています。止め方を決めていない状態で動かさないという点だけは、AIエージェントの止め方で扱ったとおり、例外を作らないほうが安全です。

費用については、定額の契約でも裏側が従量になっている場合があります。IPAの中小企業向けガイドラインは、委託先や外部サービスの利用条件を契約時に確認する項目を挙げています（中小企業の情報セキュリティ対策ガイドライン 付録、確認日 2026年10月5日）。上限設定ができない製品は、その時点で候補から外すという判断も成り立ちます。

導入しない、という判断が妥当な場合

残る3つを受け入れられない業務があります。誤りが外部の取引先へ直接届く業務、金額が大きく戻せない業務、法令上の記録義務がある業務です。これらは、精度が十分でも向きません。連鎖の範囲を狭くできず、結果の点検が間に合わないためです。

この場合、エージェントではなく生成AIの出力を人が使う形に留めるほうが、同じ効果を安全に得られることがあります。下書きを作らせて人が送る、という作りであれば、実行権限の問題は発生しません。効果が小さく見えても、やり直しの費用を含めると結果的に安く付きます。

費用の増え方が、契約時の見積もりと合わない

エージェントは1回の指示で複数回の処理を走らせます。利用料が処理回数に連動する契約だと、同じ業務量でも月によって請求が変わります。指示の書き方が変われば回数も変わるため、使う人が増えた月に跳ねるという形で出ます。

見積もりの段階では、1件あたりの単価ではなく、1件を処理するのに何回の呼び出しが起きるかを聞いておくと差が小さくなります。答えられない場合、上限設定と通知が用意されているかを確認する順序になります。上限が無い製品を、金額の大きい業務へ当てないという線引きが現実的です。

退職と異動のたびに、棚卸しが要る

人が辞めるとき、社内システムのアカウントは止めます。その人が作ったエージェントが動き続けていることには気づきにくいという性質があります。設定した本人がいなくなると、何のために動いているのか誰も説明できない処理が残りました。

退職手続きの一覧に、その人が作った自動処理の確認を1行足しておくと防げます。手続きの外に置くと、思い出したときだけ確認する運用になり、いずれ止まります。

試す前に、やめる条件を書いておく

エージェントの導入は、動き始めると止めにくくなります。業務が回り始めた後で不具合が見つかっても、戻す先の手作業がもう無いという状態になるためです。開始前に、どの数値がどうなったらやめるかを書いておくと、判断する人が後から困りません。

書く内容は3行で足ります。誤りが月に何件出たら止めるか、確認の作業が何時間を超えたら割に合わないと見るか、誰が止める判断をするか。数値は厳密でなくてかまいません。開始前に決めた線がある、という事実のほうが効きます。

よくあるご質問

メリットとデメリットは、どちらを先に見るべきですか

残る3つを先に見ることをおすすめします。消える5つは設計の話なので、進めると決めてから検討しても間に合います。受け入れられない性質が混ざっていた場合、設計を詰める時間が無駄になります。

小さく試せば、デメリットは小さくなりますか

連鎖の範囲と金額は小さくなります。確認の形骸化は、試行期間が短いぶん表面化しにくいだけで、本番へ移してから現れます。試行の結果だけで判断すると、この点を見落とします。

記録はどこまで残せば十分ですか

何に触れて何を変えたか、いつ、どの指示を受けて実行したかが分かれば、原因は追えます。判断の理由まで残そうとすると量が増え、読まれなくなります。読む人が追える量に抑えるほうが実用的です。

受け入れる範囲が決まれば、残りは設計の作業になります。どこまで任せるかの線引きに迷う場合は、業務ごとの条件を整理するところからご相談ください。