「作ったもの」が8ヶ月で畳まれる——ノーコードAI基盤の賞味期限
homulaは、エンタープライズ企業のAIエージェント導入を、特定のベンダーやモデルに縛られない構成で設計し、最終的に自社で回せる状態（内製化）まで支援するAIインテグレーターです。だからこそ、今回のニュースは「便利な機能が一つ消えた」では済まない論点を含んでいると考えています。
2025年10月6日、OpenAIはDevDayで AgentKit を華々しく発表しました。その目玉が、ドラッグ&ドロップでエージェントの処理フローを組める Agent Builder です。OpenAIはこれを「エージェント版Canva」と表現し、ノーコードでエージェントを量産できる世界を打ち出しました（TechCrunch、OpenAI: Introducing AgentKit）。
ところが、それからわずか約8ヶ月後の 2026年6月3日、OpenAIは Agent Builder と評価ツール Evals の終了（非推奨・サンセット）を予告しました（OpenAI: Deprecations、OpenAI Developer Community）。GUIでせっせと作り込んだエージェントは、行き場を探すことになります。本記事では、この一件を「OpenAIの方針転換」として消費するのではなく、ノーコードのベンダー基盤に業務ロジックを預けることの構造的リスクとして整理し、エンタープライズの選定軸に落とし込みます。
何が終わるのか——日付で押さえる
まず一次情報で事実関係を確定します。
| 時点 | 出来事 |
|---|---|
| 2025-10-06 | DevDayで AgentKit（Agent Builder / ChatKit / Evals / Connector Registry）を発表 |
| 2026-06-03 | Agent Builder と Evals の 非推奨（deprecation） を告知 |
| 2026-10-31 | Evals が既存ユーザー向けに 読み取り専用 化 |
| 2026-11-30 | Agent Builder と Evals が サンセット（稼働停止） |
サンセット後は、Agent Builderで組んだフローはプラットフォーム上で動かなくなります。一方で埋め込みチャットUIの ChatKit は継続します。移行先としてOpenAIが案内しているのは、コードで書く Agents SDK と、自然言語で作る ChatGPT Workspace Agents の2つです（OpenAI Developer Community）。評価側の Evals については、OSSの Promptfoo への移行を推奨し、既存の評価を「実行可能なPromptfoo設定」としてエクスポートする経路を用意しています（OpenAI Cookbook: Moving from OpenAI Evals to Promptfoo）。
ポイントは「機能が消えた」ことではなく、提供元自身が示した逃げ道がすべて『コード』と『標準』と『OSS』だったことです。Agents SDK（コード）、Workspace Agents、Promptfoo（OSS）——移植可能な形に避難させてください、というメッセージに読めます。
なぜ「GUIで作った資産」は消えやすいのか
8ヶ月という短さは極端に見えますが、構造的に見ると驚くべきことではありません。
第一に、ノーコードGUIはロジックをベンダー固有の内部表現に閉じ込めます。画面上のノードと接続線は、そのプラットフォームの独自フォーマットで保存されます。エクスポートやコード化の経路が用意されていなければ、別の基盤へ持ち出す手段が乏しく、「作り直し」が事実上の移行コストになります。
第二に、GUIレイヤーはベンダーの戦略転換で畳まれやすい位置にあります。モデルやAPIは収益と直結する基盤ですが、その上に乗る作成ツールは「開発者をどう誘導するか」という流動的な戦術の産物です。OpenAIの今回の動きも、ノーコードのビジュアル編集よりコード（Agents SDK）と自然言語（Workspace Agents）に開発者を寄せ直す再編と読めます。AI業界では製品の早期終了が珍しくなく、提供開始から1年未満での撤退も起きています。
第三に、この脆さは「シチズン開発」で増幅します。現場の非エンジニアがGUIで量産したエージェントほど、コードによる管理やバージョン履歴を持たず、ベンダー撤退時に何がどう動いていたのかを復元しづらい。便利さの裏で、組織は「ベンダーのGUIが存続する限りでしか動かない業務ロジック」を静かに積み増していきます。
移行先が教える「正解」——コードと標準に沈める
逆説的ですが、今回もっとも実務的な示唆は、OpenAI自身が指し示した移行先にあります。
- オーケストレーションは Agents SDK（コード）へ。コードであればGit管理・レビュー・観測性が効き、ロジックは自社リポジトリに残る。ベンダーがGUIを畳んでも、コードは手元から消えません。
- 接続は標準プロトコル（MCP）へ。ツール・データ接続をベンダー独自コネクタではなく MCP（Model Context Protocol） のような標準で抽象化しておけば、実行基盤を載せ替えても接続定義を使い回せます。MCPの基礎はMCP（Model Context Protocol）入門を参照してください。
- 評価はOSSでCIに組み込む。Evalsの移行先Promptfooはローカルやパイプライン上で回せるOSSです。評価をベンダーのダッシュボードに閉じ込めず、コードとして自社CIに持てば、基盤を変えても品質の物差しは生き残ります。
実務の型は「速さと移植可能性を分けて持つ」こと。試作・PoCはノーコードGUIで素早く回し、本番に残す 業務ロジック・評価・接続定義 はコードと標準（Agents SDK・MCP・Promptfoo・LangGraph など）に“沈めて”おく。GUIは入口、コードは資産、と割り切ります。
選定軸：ベンダーGUIに何を預け、何を手元に残すか
「ノーコードは悪、コードは善」という話ではありません。立ち上げの速さはGUIの圧倒的な利点です。問われるのは どの資産をどちらに置くか の切り分けです。
| 観点 | ベンダーGUIに寄せる | コード/標準に保つ |
|---|---|---|
| 立ち上げ速度 | ◎ 速い | △ 初期は遅い |
| 移植可能性 | × 低い | ◎ 高い |
| 観測性・評価のCI化 | ベンダー依存 | OSS（Promptfoo等）で内製 |
| 撤退・終了への耐性 | 低い | 高い |
| 向く用途 | 試作・PoC・短命な業務 | 本番・長期・基幹に近い業務 |
判断の原則はシンプルです。寿命の長い業務、止まると困る業務ほど、ロジックと評価をコード/標準で持つ。逆に、使い捨ての検証や短命なキャンペーン処理はGUIで割り切って速く回す。終了予告が来てから慌てるのではなく、最初に「これはどちらに置く資産か」を決めておくことが、移行コストを設計段階で削る唯一の方法です。
homulaの観点——「内製化」とは移植可能性を握ること
homulaが支援の軸に「内製化」を置くのは、まさにこの移植可能性を企業の手元に残すためです。
- ベンダー非依存の実装：homulaは n8n / Dify / LangGraph を中心に、特定ベンダーのGUIに業務ロジックを閉じ込めない構成を組みます。基盤を載せ替えても、ロジックと評価は自社に残ります。
- 接続は標準で：MCPを活用した統合プラットフォーム Agens は、200以上のツールと構築ゼロで接続できます。接続定義を標準側に置くことで、実行基盤の入れ替えに強い土台を作ります（接続の標準化はMCP活用支援で設計します）。
- 統制はランタイムで：誰が・どの権限で動かすかは、プロンプトやGUI設定ではなくランタイムで縛るべき領域です。Agens Control は 承認フロー・DLP・5年分の監査ログ・RBAC を提供し、基盤が変わっても一貫した統制を効かせます（Agens Control）。
- 入口はブートキャンプ：業務棚卸し・プロトタイプ構築・ROI試算を 3〜5日 で完結させ、「どこをGUIで速く回し、どこをコード/標準で資産化するか」を小さく見極めてから広げます。
ベンダー基盤の早期終了は、これからも繰り返されます。重要なのは個々のニュースに一喜一憂することではなく、終了予告が来ても作り直しにならない設計を最初から選ぶことです。
まとめ
- OpenAIは2025年10月にAgent Builder/Evalsを発表し、2026年6月3日に終了を予告、サンセットは 11月30日。提供開始から約8ヶ月という短命だった。
- ノーコードGUIは ロジックをベンダー固有形式に閉じ込め、戦略転換で畳まれやすい。シチズン開発で量産された資産ほど脆い。
- OpenAI自身の移行先が Agents SDK（コード）・Workspace Agents・Promptfoo（OSS） だった事実が、避難先の正解を示している。
- 選定の原則は「速さと移植可能性を分けて持つ」。試作はGUI、本番のロジック・評価・接続定義はコードと標準（Agents SDK・MCP・Promptfoo・LangGraph）へ。
エージェント基盤の評価軸は「どれだけ速く作れるか」から「作ったものがベンダー都合で消えないか」へと一段深まりました。移植可能性を自社の手に残せる企業が、ツールの世代交代を生き延びます。
「どの業務をノーコードで速く回し、どこをコードと標準で資産化するか」を自社の業務に落とし込みたい方は、まず小さく切り分けるところから始めましょう。