結論から：AIエージェントを1つ作るのと、複数の工程を繋いで毎日無人で回すのは別の作業です。難しいのはAIの部分ではなく、工程の繋ぎ目にあります。当社はAIメディアを8工程で毎日無人運用していますが、設計で効いたのは技術的な工夫ではなく4つの決め事でした — 各工程を独立させる／1回あたりの件数に上限を置く／使うモデルを固定する／実行環境を明示する。そして実際に壊れた4か所は、すべてエラーを出しませんでした。工程が丸ごと抜けていた期間もあります。

株式会社TOEはAI開発を事業としており、この記事は提供する側が書いています。中立の第三者ではありません。他社の構成は評価せず、自社で毎日動かしているものと、そこで実際に壊れたことだけを書きます。

実際に回している8工程

AIメディア「AIの鬼」を無人で更新している処理の実物です。順に並べると次のようになります。

# 工程 やっていること AIを使うか
1 コード同期 実行機のコードを最新に取り込む 使わない
2 収集 無料の公開API・RSSから記事を集める 使わない
3 本文取得 記事の本文を取ってくる（1回40件まで） 使わない
4 解説生成 約800字の解説を書く（1回35件まで） 使う
5 公開 内部リンク検査 → ビルド → 配信 使わない
6 記録 件数を1行だけ残す 使わない
7 話題の提案 伸びている話題を書き出す 使う
8 データ同期 集めたデータを保管場所へ戻す 使わない

8工程のうち、AIを使うのは2つだけです。残り6つは条件と手順で書けます。ここを取り違えると、集計や配信のような確実に動くべき処理までAIに任せることになり、日によって結果が揺れます。

現在の稼働実数はこうです。

項目 実測（2026年8月1日時点）
保持しているニュース 2,741件
解説が生成済みのもの 445件
公開している記事 216本
運用中のAIの従量課金 0円（AIは手元の端末で動かしているため）

課金ゼロで組んでいる中身はAPI課金ゼロでAIメディアを2本動かすに書きました。

設計で効いた4つの決め事

技術的な工夫ではありません。全部「決めておくこと」です。

# 決め事 決めないとどうなるか
1 各工程を独立させる 1つ落ちると全部止まる。収集が失敗しても、既存データでのビルドと公開は続くべき
2 1回あたりの件数に上限を置く 全件を一度に回して、途中で打ち切られ、保存前に消える。当社は翻訳がこれで止まった
3 使うモデルを固定する 指定を書き忘れると上位モデルが使われ、利用枠を食い潰す。553件中414件が失敗した
4 実行環境を明示する 無人実行は対話時と環境が違う。同じコマンドが「見つからない」で無音失敗する

1番が最も基本で、最も守られていません。 「収集 → 生成 → 公開」を1本の処理として書くと、収集がこけた日は公開まで止まります。当社は各段の失敗を記録して次へ進む形にしており、失敗した分は翌日の実行で取り返します。

2番は事故の大きさを決めます。 上限がないと、事故が起きたとき「全損」になります。当社が2,000件の翻訳を一度に回したときは、打ち切られて保存前に消え、何度回しても進捗が7%のままでした。40件・35件のような上限を置くと、最悪でもその回だけの損失で済みます。

3番は実際に事故になりました。 どのモデルを使うかをスクリプトに書き忘れた結果、上位モデルが使われて利用枠を食い潰し、社長本人の作業と、動いていた分析処理3本まで巻き添えで止まりました（AI処理414件を失敗させた話）。

実際に壊れた4か所

無人運用で壊れたところを、原因ごとに挙げます。4つともエラーを出していません。

# 何が壊れたか 何が起きたか 気づいた経緯
1 工程が丸ごと入っていなかった 解説生成が日次に含まれておらず、新着ページが本文のないまま公開され続けた サイトを点検して発見
2 書き込む先と読み出す先が違った 毎日40件ぶんAIを叩いていたが、サイトが読むのは別の場所。表示に一度も使われていなかった 同上
3 実行機のコードが古いままだった ビルドも公開も成功。中身だけが2日前のもの。改修が本番に出ない 検索の数値が改善しないことから逆算
4 無人実行だけ環境が足りなかった 対話では動くコマンドが、無人実行では見つからない・認証が通らない 全件失敗のログから

3番が特に厄介です。 ビルドは成功し、公開も成功し、ログにも異常が出ません。古い内容が正常に配信されているだけだからです。当社はこれで、検索向けの改修が2日間まったく反映されないまま、順位の変化を待っていました。

この型の壊れ方は他にもあり、当社の12件をAI自動化は「エラーを出さずに止まる」に整理しています。

工程を繋ぐときに決めること

上の4つの事故から、繋ぎ目ごとに決めておくべきことが分かりました。

繋ぎ目で決めること 具体的に
前の工程が失敗したら、次はどうするか 止めるか、進むか。当社は「進んで記録する」を既定にしている
書き込む場所と読み出す場所は同じか ここがずれると、処理は成功するのに何も反映されない
1回に何件処理するか 上限を数字で決める。「全件」は上限ではない
途中まで終わったら保存するか 保存しないと、打ち切られた瞬間に全部消える
実行環境で使えるものは揃っているか 無人実行は対話時と環境が違う。先に確認する処理を1つ入れる

最後の項目は工程として入れられます。 当社は日次の冒頭で、AIが実際に応答するかを1回だけ試し、駄目なら記録に残します。空のまま公開し続けるより、気づける方がよいためです。

検証環境の成功率を、そのまま信じない

工程を設計するとき、公表されている成功率をそのまま前提に置くと外します。

画面を操作するAIエージェントの研究では、整備済みの検証環境で82.6%の成功率だったものが、実機の本物アプリでは42%まで落ちました。差は40.6ポイントです。

さらに、失敗の大半は「押す位置がずれた」ではなく、そのボタンが何なのかを取り違えたことに起因すると論文自身が認めています。そして学習に使えた実アプリは30本だけで、理由はログイン・SMS認証・実名認証の壁でした。日本の業務システムが学習対象になりにくい構造が、そのまま説明されています（画面操作AIは、ベンチマークで82.6%成功しても実機では42%まで落ちるのか）。

工程を組むときは、検証環境の数字ではなく実機の数字で見積もってください。 そして落ちたときに人へ回す経路を、最初から入れておくことです。

AIを使う工程と、使わない工程を分ける

冒頭の表のとおり、8工程のうちAIを使うのは2つだけです。この線引きは他のエージェントでも同じでした。

見積依頼メールを処理するエージェントを作って10件流したとき、AIがやったのはメールを読むことと返信の下書きを書くことだけで、受注できるかどうかの判断はAIを使っていません。板厚・材質・数量を条件表と突き合わせるだけなので、条件式の方が速く、確実で、理由も説明できます（判断にかかった時間は1件あたり0.001秒）。

部署ごとの向き不向きは総務・バックオフィスにAIエージェントを入れるに、業務フローへの組み込み方は業務フローにAIを組み込むときの設計に書いています。

この記事で言えないこと

  • 他社の構成は評価していません。 当社は提供する側で、その立場にありません
  • どのツールや基盤を使うべきかも書けません。 当社の構成は「課金ゼロ」を絶対条件にしており、前提が違えば選択も変わります
  • 完成した設計ではありません。 上の4か所は、当社が壊してから直したものです

まとめ

  • エージェントを1つ作ることと、工程を繋いで毎日無人で回すことは別の作業。難しいのは繋ぎ目
  • 当社は8工程で無人運用しているが、AIを使うのは2工程だけ。残りは条件と手順で書ける
  • 効いた決め事は4つ — 各工程を独立させる／1回の件数に上限／使うモデルを固定／実行環境を明示
  • 上限を置かないと事故が「全損」になる。 2,000件を一度に回して、保存前に消え、進捗が7%のまま止まった
  • モデルの指定を書き忘れて553件中414件が失敗し、無関係な処理3本まで巻き添えで止まった
  • 実際に壊れた4か所はすべてエラーを出さなかった。工程が丸ごと抜けていた／書き込み先と読み出し先が違った／コードが2日前のまま／無人実行だけ環境が足りない
  • 繋ぎ目で決めるのは5つ — 失敗時の挙動／書き先と読み先の一致／1回の件数／途中保存／実行環境の確認
  • 判断はAIに渡さない。見積エージェントも受注可否は条件式で、1件0.001秒

この記事の立場 株式会社TOEはAI開発を事業としており、提供する側が書いています。中立の第三者ではありません。他社の構成やツールは評価せず、自社で毎日動かしているものと、そこで実際に壊れたことだけを材料にしています。設計は完成しておらず、挙げた4か所はいずれも壊してから直したものです。

実測値の出所 - 8工程の構成・件数上限: 株式会社TOEが運用する ai-oni.com の日次処理スクリプト（2026年8月1日時点） - ニュース2,741件・解説445件・記事216本: 同リポジトリのデータを集計（同日） - 553件中414件の失敗、翻訳の進捗7%: 実行ログ（2026年7月） - 見積エージェント10件・1件0.001秒: 実行ログ