「できるAI」ほど、勝手にやらかす

AIエージェントに仕事を任せて、放っておいたら終わっている。そんな未来を期待している人は多い。だが最新の研究が突きつけているのは、スキルが高いエージェントほど、想定外の壊れ方をするという不都合な事実だ。

しかも厄介なのは、「できないから失敗する」のではなく、「できるから失敗する」という構造にある。中小企業がAIエージェントを導入するとき、この構造を知らずに突っ込むと、取り返しのつかないことになる。

3つの最新研究から、AIエージェントが「勝手に失敗する」パターンを整理する。

—

パターン1：スキルを足すほど壊れる——「スキル誘発失敗」の正体

論文「Agent Skills Can Be Harmful」が報告した数字がえぐい。307件のスキル誘発失敗。内訳は、機能的失敗125件、効率性低下182件。

ここで直感に反するのは、失敗の原因が「無関係なスキル」ではなく「関連性のあるスキル」だったという点だ。

どういうことか。たとえば、メール対応エージェントに「文章要約スキル」を追加したとする。関連性は高い。だが、このスキルが「顧客からの問い合わせメール」に対しても要約を優先してしまい、本来必要だった詳細な回答をすっ飛ばす。結果、顧客対応が破綻する。

これは人間の組織でも起きる話だ。「優秀な人を入れたら、かえってチームが回らなくなった」。あの現象のAI版だと思えばいい。

中小企業にとっての教訓は明確だ。AIエージェントに「あれもこれも」とスキルを盛るのは、リスクを盛っているのと同じ。やるべきは逆で、1つのタスクに対して必要最小限のスキルだけ持たせる。「引き算の設計」が生死を分ける。

具体的には、エージェントにスキルを追加する前に、こう問うべきだ。

• そのスキルは「このタスク」に本当に必要か？
• 追加した結果、既存の動作が変わるリスクはないか？
• スキル追加前後で、同じテストケースの結果は変わらないか？

このチェックを飛ばして「高機能なエージェント」を作ろうとすると、307件の失敗パターンの仲間入りをすることになる。

—

パターン2：訓練時に安全でも、実行時に暴走する——「安全性は契約にしろ」

「Agent Safety Should Be a Runtime Contract」という論文が指摘しているのは、もっと根本的な問題だ。

従来のAI安全性は「モデルの訓練段階で安全にする」というアプローチだった。つまり、出荷前に品質検査をして、OKなら市場に出す。だがエージェントは違う。実行時にコードを書き、ファイルを変更し、外部APIを叩く。訓練時には想定していなかった行動を、現場で勝手にやる。

出荷前の品質検査がいくら完璧でも、現場で勝手に改造を始める機械は危ない。当たり前の話だ。

この論文が提案するのは、安全性を「実行時の契約」として設計するという考え方。2つの側面がある。

予防的契約：やってはいけないことを事前に縛る

• サンドボックス（隔離環境での実行）
• 権限ゲート（ファイル削除やDB書き込みは人間の承認が必要）
• 出力フィルタ（個人情報や機密情報の外部送信をブロック）

証拠的契約：やったことの証拠を残させる

• タスク完了時にテスト結果を提出させる
• 操作ログを自動キャプチャする
• 「何をやって、何が変わったか」の差分レポートを生成させる

これ、中小企業にとって何がありがたいかというと、高度なAI知識がなくても「契約」として安全性を管理できる点だ。

たとえば、経理業務をエージェントに任せるとする。「請求書データの読み取りはOK。だが銀行APIへの送金実行は人間の承認なしにやるな」。これが権限ゲートだ。「処理した請求書の一覧と、元データとの突合結果をレポートとして出せ」。これが証拠的契約だ。

AIの中身がブラックボックスでも、入口と出口を契約で縛れば、暴走は防げる。この発想は、中小企業が今すぐ使える。

—

パターン3：過去の成功体験が、次の失敗を生む——記憶の劣化問題

3つ目は「EvoGraph-Mem: Failure-Aware Editable Graph Memory for Long-Term Language Agents」の研究。これが扱うのは、エージェントの「記憶」が腐る問題だ。

長期運用するエージェントは、過去の経験を記憶として蓄積する。「このパターンの問い合わせにはこう対応すればうまくいった」という知見をため込む。一見、賢くなっていくように見える。

だが現実には、時間が経つと記憶の前提条件が変わる。半年前に有効だった対応が、今は規約変更で使えなくなっている。商品ラインナップが変わって、過去の提案テンプレートが的外れになっている。

人間なら「あ、これもう古いな」と気づく。だがエージェントは、過去の成功体験をそのまま再利用する。しかも自信満々に。結果、「前はうまくいったのに、なぜか最近おかしい」という、原因特定が困難な失敗が起きる。

この研究が提案する「失敗認識可能なグラフメモリ」は、各記憶ノードに正の証拠（うまくいった回数）と負の証拠（失敗した回数）を紐づける仕組みだ。負の証拠が増えた記憶は自動的に信頼度が下がり、再利用されにくくなる。

中小企業の現場で言えば、こういうことだ。

• エージェントが過去の対応パターンを使って失敗したら、その記録が自動で残る
• 同じパターンで3回失敗したら、そのパターンは自動的に「要注意」に格下げされる
• 人間が確認して、更新するか削除するか判断する

「記憶のメンテナンス」をシステム化するという発想だ。これがないと、長く使えば使うほどエージェントの品質が劣化するという、直感に反する現象が起きる。

—

3つのパターンに共通する構造

ここまでの3パターンを整理すると、共通する構造が見える。

すべてに共通するのは、「良かれと思ってやったことが裏目に出る」という構造だ。スキルを足す、自律性を上げる、経験を積ませる。どれも「AIを賢くする」方向の施策だが、それ自体がリスクの源泉になる。

—

中小企業は結局どうすればいいのか

「じゃあAIエージェント使うなってこと？」——そうじゃない。使い方の設計を変えろ、という話だ。

1. スキルは最小限にする

エージェントに「あれもこれも」させない。1エージェント1タスクが原則。複雑なことをやらせたければ、シンプルなエージェントを複数組み合わせる。スキルを足すたびに、既存タスクのテストを回す。

2. 実行時の契約を設計する

「何をやっていいか、何をやってはいけないか」を明文化する。特に、データの書き込み・削除・外部送信には必ず人間の承認ゲートを入れる。エージェントの出力には必ずログと証跡を残させる。

3. 記憶のメンテナンスを仕組み化する

月に1回、エージェントの記憶（ナレッジベース、対応テンプレート等）を棚卸しする。失敗が増えているパターンを特定し、更新または削除する。これを人間の運用ルールとして定着させる。

4. 「任せてはいけない業務」を先に決める

全部を自動化しようとしない。失敗したときの損害が大きい業務（顧客対応の最終判断、契約書の作成、資金移動など）は、エージェントに「下書き」までやらせて、最終判断は人間がやる。この線引きを最初に決めておく。

これらは、大企業が数千万円かけてAIガバナンス体制を構築するような話ではない。中小企業が明日からできる、実務レベルの防御策だ。

—

本当に怖いのは「静かな失敗」

最後に1つ。AIエージェントの失敗で最も怖いのは、派手にエラーを出して止まることではない。一見うまくいっているように見えて、実は少しずつズレた対応を続けている「静かな失敗」だ。

顧客対応の質が微妙に下がっている。データの精度が少しずつ落ちている。だがエージェントはエラーを出さないから、誰も気づかない。気づいたときには、顧客が離れている。

307件のスキル誘発失敗のうち、182件は「効率性の低下」だった。つまり、エラーにならないが、じわじわ悪化する失敗が過半数だ。

AIエージェントを導入するなら、「動いているか」ではなく「正しく動いているか」を定期的に検証する仕組みが必須になる。それは高度なAI技術の話ではなく、業務の品質チェックという、中小企業が昔からやってきたことの延長線上にある。

AIの導入は「入れて終わり」ではない。入れた後の運用設計こそが、成果とリスクを分ける。

—