AIエージェントにSNS運用を丸ごと任せて2週間、問題は20件近く出ました。ただ、一番怖かったのは文章の質ではなく、システムが嘘の成功を報告した日でした。自動化でまず作るべきは賢い書き手ではなく、正直な通知と、記録された事実。これがこの記事の結論です。
想定読者は、AIエージェントで発信やコンテンツ運用を自動化しようとしている実務者です。私が実際に運用しているシステムで起きた問題から、上位10個を「症状 → なぜ厄介か → 対処」の型で解説します。固有のツール名や構成には依存させず、症状の型と対処の型として書くので、自分の環境に読み替えて使ってください。
全工程を任せる構成にした。誤爆ゼロ、でも内側では毎日何かが起きていた
前提を短く説明します。私が動かしているのは、あるSNS運用の自動化システムです。題材の調査、下書き、公開前審査、予約と公開、計測、改善案の起票まで、全工程をAIエージェントに任せています。人間の承認ボタンは置いていません。代わりに、公開回数の上限や書き込み先の制限といった境界だけをコードで強制する設計です。
結果から言うと、外向きの事故、つまり「出してはいけないものが公開される」誤爆はゼロでした。この点は設計どおり。ところが内側では、初週から毎日のように何かが起きていました。公開が止まる、修正が反映されない、報告と実態がずれる。運用ログに残った問題を数えたら、2週間で20件近くありました。
20件を並べ替えたら、上位は全部「観測」と「事実」の問題だった
20件を眺めると、性質は2種類に分かれました。作る前に決めておくべきだった設計の問題と、動かして初めて表面化した運用の問題です。
そして厄介さで順位をつけたとき、予想と違うことが起きました。上位に来たのは、文章の出来でも、モデルの性能でもなく、すべて「観測」と「事実」の問題だったんです。成功したという報告は本当か。書かれた体験は実在するか。2週間で、文章の巧拙で困ったことは1件もありませんでした。
なので、この10選も「観測と事実」を軸に読んでもらうのが正しいと思います。設計編5つ、運用編5つ。順番に行きます。
設計編: 作る前に決めておくべきだった5つ
1. 通知が嘘をつく
最悪の事故はこれでした。「公開に成功しました」という通知が届いたのに、実際には想定と違う場所へ配信されていた。公開処理の一部だけが成功し、システムはそれを全体の成功として報告していました。
なぜ厄介か。監視の土台が崩れるからです。通知が信用できないと、成功の通知も失敗の通知も全部を疑って目視確認する羽目になり、自動化の意味がなくなります。誤報が1回あるだけで、以後の全通知の信頼が消える。
対処: 成功通知には検証済みの事実だけを載せる、というルールにしました。具体的には、公開APIの応答をそのまま信じず、公開後に実体を取得し直して確認し、通知には実際に公開されたURLと識別子を含めます。「URLが貼ってある成功通知だけが本物」という運用です。
2. 設定と手順書が揃って古い
エージェントの参照する設定ファイルと手順書が、両方とも古いままになっていたことがありました。人間が仕様変更を一方にしか反映せず、しかも今回はどちらにも反映し忘れていた、という状況です。
これが厄介なのは、AIが照合しても矛盾を検知できないからです。2つの参照先が「同じように古い」と、突き合わせた結果は一致になってしまう。新旧の矛盾なら気づけますが、揃って古い情報はエージェントにとって正しい情報と区別がつきません。人間の更新漏れは、最も見つけにくい事故になります。
対処: 正本を1箇所に決めました。同じ情報を2箇所に書かず、片方は正本へのポインタだけを持つ。更新箇所が1つなら、更新漏れは「古い」か「新しい」かのどちらかにしかならず、揃って古いという状態が構造的に起きなくなります。
3. 事実の空白に創作が湧く
公開前の原稿に、記録のどこにもない「体験談」が書かれていたことがありました。既存の事実と矛盾はしない、それらしい体験です。矛盾チェックの審査は素通りしていました。
厄介なのは、この嘘が検査に引っかからない形をしているところです。「台帳と矛盾する記述を落とす」という審査は、台帳に書かれていないことを語る記述を落とせません。事実の空白は、生成モデルにとって創作の余地に見えるようです。
対処: 審査基準の書き方を変えました。禁止するのは「矛盾」ではなく「記録に無い体験を語ること」。実体験として書いてよいのは、事実の台帳か、記事ごとの発注メモに実在する素材だけ、と明文化しました。空白は空白のまま残し、埋めたければ人間が台帳に事実を書き足す。この一方通行を守らせるだけで、創作は止まりました。
4. 審査基準の未整備で全工程が止まる
公開前審査には「判定できない場合はFAIL」という原則を入れていました。安全側に倒す正しい設計のはずが、これが公開を3日間止めました。審査の参照する基準ファイルの一部が、人間の記入待ちで空欄のままだったからです。エージェントは毎日律儀に原稿を書き、審査は毎日律儀に「判定不能によりFAIL」を返し続けました。
厄介なのは、どちらのプログラムも正しく動いている点です。壊れている箇所がないのに、システム全体としては何も生産していない。しかも報告は「審査FAIL」なので、原稿の品質問題に見えてしまい、本当の原因である「人間の宿題」が浮かび上がりません。
対処: FAILを2種類に分けました。「原稿を直せば通る」と「人間の対応が必要」です。後者は担当と期日をつけて別枠で報告する。自動化の停止要因が機械側にあるのか人間側にあるのかを、報告の時点で区別できるようにしました。
5. 供給と消費の算数が合わない
稼働3日目に、書き手のエージェントが題材切れを起こしました。1つの調査結果を1回使ったら消費済みにする設計だったため、複数の媒体が題材を取り合い、調査の供給が追いつかなくなったんです。
これは「詰まる」のではなく「枯れる」タイプの停止で、意外と設計時に見落とします。処理が失敗するわけではないので、エラーはどこにも出ません。ただ、書くものがないから書けない、という静かな停止です。
対処: 題材の消費フラグを媒体別にしました。同じ調査結果でも、媒体が違えば読者も切り口も違うので、別々に使ってよい。加えて、1日に消費される題材数と供給される題材数を設計段階で数え合わせるようにしました。自動化のパイプラインは、詰まる場所だけでなく枯れる場所を先に探すべきです。
運用編: 動かして初めて出た5つ
6. 二段階APIの間欠エラー
SNSの公開APIには「コンテナを作成してから公開する」という二段階の型がよくあります。作成の直後に公開を呼ぶと、「対象がまだ存在しない」というエラーで弾かれることがありました。少し待って呼ぶと成功する。しかも複数の媒体で、同じ型の症状が出ました。
厄介なのは間欠性です。再現したりしなかったりするので、コードのバグなのか相手側の仕様なのか、切り分けに時間を食います。そして「とりあえず全部リトライ」で雑に潰すと、今度は本物の障害までリトライで隠してしまう。
対処: 再試行に条件をつけました。作成後に状態を確認してから公開を呼ぶ。それでも弾かれた場合だけ、「まだ存在しない」系のエラーに限定して、1回だけ再試行する。何でも再試行しない、回数を増やさない。再試行は失敗を隠す道具にもなるので、狭く使うのが正解だと思っています。
7. 依頼が着弾していない
「昨日の失敗の原因を修正した」と報告があったのに、翌日同じ理由で同じ処理が落ちました。調べると、修正はされていたものの、実際に参照されるファイルとは別の場所に入っていた。つまり修正は存在するが、効いていない。
これが厄介なのは、「実装した」という報告自体は嘘ではないところです。問題1の「通知が嘘をつく」の親戚ですが、こちらは悪意なき正直な報告で、それでも実態とずれる。「実装した」と「効いている」は別物なんです。
対処: エージェントへの修正依頼に受け入れ基準をつけるようにしました。「次回の実行でこのケースが成功すること」まで書いて、翌日の実行結果で検収する。人間のチーム運営と同じで、done の定義を実行結果に置くと、着弾していない修正がその日のうちに見つかります。
8. 検査同士がトレードオフ
公開前審査に「実践を主語にすること」と「直近の投稿と重複しないこと」という2つの基準を入れていたら、この2つが両立不能になりました。実践を語れる題材は限られているので、実践を主語にするほど過去の投稿と似てしまう。審査は重複でFAILを返し、書き直すと今度は一般論に寄って実践性でFAILになる。
厄介なのは、原稿をいくら書き直しても解決しないところです。エージェントは無限に書き直せてしまうので、放っておくと修正ループだけが回り続けます。問題は原稿ではなく基準の側にあるのに、システムの報告上は「原稿が2回FAILした」としか見えません。
対処: 基準の側を直しました。重複の判定対象を「主題と結論が同じか」に限定し、文体や構成が似ていることは警告に留めてFAIL理由から外す。審査が連続で落ち続けるときは、原稿ではなく基準同士の衝突を疑う。これはチェック機構を自作する人ほど踏む罠だと思います。
9. 設計語がそのまま出力される
執筆手順書に「起承転結で構成する」と書いていたら、公開された記事の見出しに「起:」「承:」というラベルがそのまま現れたことがありました。構成の指示を、見出し文の指示だと解釈したわけです。
小さい事故に見えますが、公開物に舞台裏の言葉が漏れるのは読者への信頼問題です。そして防ぎにくい。人間なら言わなくても分かる「これは内部用語」という区別を、エージェントは明示されない限り持ちません。
対処: 手順書に「構成ラベルを見出しに使わない」と明記し、公開前審査の検査項目にも同じ1行を入れました。舞台裏の言葉は舞台裏に置く、と書いて初めて舞台裏に留まる。指示書の言葉は全部出力に漏れうる前提で書くようになりました。
10. 逃げ道が塞がれている／自分の足跡が数字に混ざる
最後は環境の問題を2つまとめて。1つ目、エージェントの実行環境には通信制限をかけていましたが、その制限が正規の回避策まで塞いでいて、障害時の代替手段が使えませんでした。2つ目、計測データに開発中の自分のアクセスが混ざり、公開直後の反応がどれだけ本物か分からなくなりました。
どちらも本体のコードは無傷なのに、運用の判断を狂わせます。特に計測汚染は、そのまま気づかず改善サイクルを回すと、自分のアクセスを「読者の反応」として学習してしまう。
対処: 実行環境の許可リストを「正規の回避策を含めて」整備し直し、計測側は内部トラフィックを除外しました。地味ですが、「動かす環境」と「測る環境」の整備は本体の機能と同じくらい効きます。
全部、公開前に内側で止まった。止めたのは賢さではない
10個並べて分かるとおり、困りごとの主役はモデルの知能ではありませんでした。通知は正直か。事実はどこに記録されているか。審査は独立しているか。失敗したとき何回まで再試行し、どこで隔離するか。全部、地味な運用設計の話です。
そして強調したいのは、これらの問題はすべて公開前・社外に出る前に、システムの内側で止まったことです。止めたのは賢さではなく、次の3つの地味な仕組みでした。
- 境界の明文化: 書き込んでよい場所、公開してよい回数、使ってよい事実を、プロンプトではなくコードと基準ファイルで強制する
- 独立した審査: 書き手とは別のエージェントが、固定のルーブリックで公開可否だけを判定する
- 失敗時の規則: 再試行の上限、2回落ちたら隔離、人間対応が必要な停止の別枠報告
このあたりの実装は、それぞれ別の記事に切り出してあります。審査の分離と、禁止ラインをコードで強制する仕組みは、この記事の10選の多くと直接つながっています。
Claude Codeのサブエージェントで公開前レビューを分離する｜critic実装記録Claude Codeのサブエージェントで、公開前レビューを執筆エージェントから分離した実装記録。読み取り専用のcritic定義、判定基準のファイル固定、PASS/FAILの機械判定、修正2回上限と隔離まで、実際に運用している構成を解説します。www.tentspace.net Claude Codeのhooksで自動運用に禁止ラインを引く｜Bashガード実装記録Claude Codeのhooksで、エージェントに破らせたくない操作をコードとして強制する実装記録。PreToolUseフックの設定、Bashコマンドを検査するガードスクリプト、exit code 2でブロックする仕組み、正規表現ルールの設計と限界まで、実運用中の構成をそのまま解説します。www.tentspace.net
AIエージェントの自動化を始めるとき、つい「どれだけ賢く書けるか」から作りたくなります。でも2週間の記録が示したのは逆でした。先に作るべきは、正直な通知と、記録された事実の台帳。書く力はその上に載せるものです。この10個を先に潰しておけば、少なくとも同じ轍は踏まずに済むと思います。