AIワークフローツールの乱立から自社所有プラットフォームへ

ワークフローツールは、便利な横道から会社に入ってくることが多いです。

あるチームがn8nフローを作る。別のチームがDifyアプリを作る。さらに誰かがZapierやMakeをつなぐ。気づくと、小さな自動化はたくさん動いているのに、全体像を誰も把握していない状態になります。

これがワークフローの乱立です。これはツール選定の失敗ではありません。個々のツールは、その時点では正しい選択でした。これは構造的失敗です。それらの選択が積み重なって出現した「層」に、誰も責任を持っていなかった、ということです。

ツール層が重くなっているサイン

次の症状が出ていたら注意です。

• 認証情報が複数ワークフローに重複している
• 業務ロジックがビジュアルノード内にしかない
• どのワークフローが正なのか分からない
• エラー対応がチャットで手作業になっている
• テストがない
• 監査ログが不完全
• 1項目を変えると3つの自動化が壊れる

末期に近い具体的症状:

• ステージングと本番のドリフト。 各環境を手で保守、すでに一致していない。
• シャドーワークフロー。 あるチームがフローを「自分のワークスペース」に複製し改変。元チームは知らない。
• ノード内に平文で保管されたシークレット。 ローテーションには数十のエディタを開く必要。
• 顧客影響のある障害が数時間遅れで発覚。 アラートは「誰かが気づく」だけ。
• 権限がワークスペース全体から継承。 「ログイン可能な全員が本番の請求フローを編集可能」。
• バスファクター=1。 全フローのつなぎ方を理解しているのが1人だけ。休暇が本番リスク。
• AI費用が制御不能。 複数ワークフローがOpenAI/Anthropicを、中央のレート制限・再試行・チーム別予算なしに呼ぶ。

問題はツールではありません。ツールがアーキテクチャそのものになってしまうことです。

繰り返しパターンをソフトウェアへ移す

解決策は、繰り返し使われる自動化パターンを見つけ、自社所有ソフトウェアへ移すことです。

• 共通APIアダプター
• 確認キュー
• 管理ダッシュボード
• 再試行サービス
• 定期ジョブ
• 通知サービス
• LLM評価ハーネス

所有プラットフォーム層に有用な構成:

core/
  adapters/         # 外部システムごとの型付きモジュール
                    # (zendesk.ts, salesforce.ts, kintone.ts, ...)
                    # 認証、レート制限、再試行、冪等、観測性
  queues/           # 名前付きトピック、再試行ポリシー、DLQ
  llm/              # プロバイダ抽象、プロンプトレジストリ、
                    # 構造化出力、評価フック、コスト集計
  review-ui/        # 共通管理アプリ:キュー、根拠、上書き、監査
  scheduler/        # cron・トリガー実行を1箇所に
  notifications/    # email / slack / teams、テンプレ・レート制限付き
  audit/            # 追記専用イベントテーブル、クエリ可能
workflows/
  <team>/<workflow> # 業務ワークフロー本体。coreを使う、
                    # またはcoreを呼ぶn8n / Difyフロー

ローコード禁止が要点ではありません。すべてのチームに同じ信頼できるプリミティブを提供し、ビジュアル層が「もともと負うべきでなかった業務重要責任」を背負うのをやめさせる、です。core/ が存在すれば、ワークフローツールは本来の得意分野（オーケストレーション、素早い実験、重要度の低い接着剤）に戻れます。

現実的な移行

すべてを書き換える必要はありません。

灯りを消さない段階的移行:

1. 棚卸。 稼働中の全ワークフロー、所有者、トリガー、出力、接続システム、ボリュームを一覧化。2日仕事。結果はたいてい全員を驚かせる。
2. リスク × ボリュームで順位付け。 顧客・お金・コンプライアンスに触れるものを先に。社内のNice-to-haveは後。
3. 壊れやすく重要なワークフローを1つ選ぶ。 トリガー、データ、ロジック、AIステップ、確認経路、引き渡し先を文書化。最も重要な部分をソフトウェアとして再構築。
4. 必要な core/ の最初のピースを作る。 多くは最初のアダプタ(Zendesk、Salesforce、kintone)、最初のキュー、LLMラッパー。初日から再利用可能に。
5. 並行稼働。 出力を比較。フィーチャーフラグで切替。
6. 次のワークフローで再利用。 各移行が、次の移行が乗れるプラットフォームの一部を残す。

壊れやすいワークフローを1つ選びます。トリガー、データ、ロジック、AIステップ、確認経路、引き渡し先を文書化します。最も重要な部分をソフトウェアとして再構築し、既存ワークフローと並行稼働させ、信頼性を測ります。

これが、ツール乱立からプロフェッショナルな自動化基盤へ進む道です。投資が回収できた証拠は「n8nを消した」ではありません（多くの会社では残すべきです）。証拠は「次に作る重要な自動化が、プラットフォームに必要部品がすでにあったので半分の労力で済んだ」です。それが日常になれば、乱立は消えています。