AIエージェント（自律的にタスクを遂行するAIプログラム）を社内システムに組み込もうとしているエンジニアやPMに向けた内容です。ノーコードのビジュアルビルダーで動くものを作ったあと、基盤ごと廃止されて移行作業に追われる、という事象が実際に起きています。今回はその原因を分解し、自分のプロジェクトが該当するかどうかの確認方法まで整理します。
2025年10月6日、OpenAIはDevDayでAgent Builderを発表しました。画面上でボックスをドラッグして繋ぐだけでエージェントが作れる、というビジュアルキャンバス型のツールです。ところが2026年6月3日に非推奨化が発表され、2026年11月30日には完全に終了することが決まっています。発表からわずか8か月弱での方針転換です。
何が起きるか
Agent Builderで業務フローを組んだ企業は、後継として案内されたAgents SDK（コードベースでエージェントを構築するための開発キット）への移行を強いられます。ビジュアルキャンバスで表現していたロジックを、コードとして書き直す作業です。
これは単純な設定の書き換えでは済みません。ノーコードツールの内部では、条件分岐やツール呼び出しの順序がビルダー独自の形式で保存されています。SDKに移すには、そのロジックを一から設計し直す必要があります。
影響が大きいのは、注文処理や在庫確認のように、業務の中核でAgent Builderを使っていたケースです。単なるFAQボットであれば移行コストは小さくて済みますが、複数システムを横断する判断ロジックを組んでいた場合、移行は開発期間全体に匹敵する規模になります。
なぜ起きるか
原因を段階的に見ていきます。
第一に、ビジュアルビルダー型の基盤は「表現力の壁」にすぐ到達します。あるシステムを確認し、その結果に応じて別のシステムへ分岐する、という条件付きの多段処理を組もうとすると、ビルダーはそれを表現できないか、無理に表現しても保守不能な見た目になります。ベンダーはこの壁に社内で先に気づき、方向転換を決めます。
第二に、ノーコード系のAIエージェントツールはまだ製品として若く、機能の差別化が難しい段階です。Chatbase、Lindy、Relevance AI、Gumloopといった競合が並ぶ中、ベンダーごとに「これが正解」という設計思想が固まっていません。Agent Builderの廃止は、OpenAI自身が「ビジュアル操作は正しい方向ではなかった」と判断した結果です。
第三に、これは技術的な失敗というより意思決定の先送りです。調査会社Gartnerは、2027年末までにエージェント型AIプロジェクトの40%以上が中止されると予測し、理由として「コストの増大」「事業価値の不明確さ」「リスク管理の不備」の3点を挙げています。いずれも技術問題ではなく、導入前に詰めるべき判断が後回しになった結果です。
自分のプロジェクトが該当するか確認する
次の観点で、今使っている、あるいは検討中のエージェント基盤を点検してみてください。
- エージェントが何に触れているか: 返信文を作るだけなら失敗しても被害は小さいですが、返金処理のように実際の操作を伴う場合は間違いのコストが二重（誤処理＋取り消し作業）にかかります
- 異常時に誰が気づくか: 「顧客からの苦情で初めて発覚する」状態なら、基盤の種類に関わらずまだ運用に出す段階ではありません
- 業務フローの変更頻度: 半年に1回程度しか変わらない業務なら固定的な基盤でも問題ありませんが、月に何度も変わる業務をコード編集できないビジュアルツールに乗せると、変更のたびに詰まります
- その処理は競争力の源泉か、単なる裏方業務か: 請求書ルーティングのような裏方業務で優位性を競う会社はないので、こうした処理は既製のプラットフォームに任せる判断もあります
さらに、実際に使っている基盤について次を確認してください。ベンダーの料金ページや変更履歴（changelog）に「deprecated」「sunset」「移行期限」といった記載がないか。GitHubのリポジトリであればREADMEのバージョン方針、SDKであれば公式ドキュメントの「Migration guide」の有無を見ます。ノーコードツールなら利用規約に、保存データの取り扱いと契約終了時のエクスポート可否が明記されているかを確認してください。
対策の手順
移行リスクを事前に減らすための具体的な進め方です。
1. ロジックをツール依存の形式で保存しない: ビジュアルビルダーで組んだフローは、そのツール独自の内部表現に依存します。条件分岐やAPI呼び出しの仕様書を、ツールの外（Notionやリポジトリのドキュメント）にも別途残しておきます
2. 中核業務と裏方業務を分けて基盤を選ぶ: 競争力の源泉になる処理はAgents SDKのようなコードベースの基盤で自前管理し、請求書処理のような裏方業務はエンタープライズ型のSalesforce AgentforceやMicrosoft Copilot Studioのような既製サービスに任せます
3. 異常検知の仕組みを先に作る: エージェントを本番投入する前に、誤動作を検知して人間に通知する経路を用意します。これがない状態でのリリースは、基盤の選定以前の問題です
4. ベンダーのロードマップを定期的に確認する: 主要な基盤について、四半期に1回程度は公式ブログや変更履歴を確認する運用を決めておくと、廃止告知から移行完了までの時間を確保できます
まとめ
Agent Builderの廃止は、ノーコード型AIエージェント基盤が抱える構造的な不安定さを示す一例です。
判断の軸は、エージェントが何に触れるか、異常時に誰が気づくか、業務がどれくらい変化するか、その処理が競争力の源泉かどうかの4点に整理できます。
今使っている基盤について、まずはベンダーの変更履歴とデータの契約条件を確認し、業務ロジックの仕様をツールの外にも残す作業から始めてみてください。