LLM機能が急速に進化するにつれて、エンジニアリング努力をどこに投資し、どこで待つべきかを決定するフレームワークが必要です。
意思決定
LLMの進歩との関係性に基づいてすべての機能を分類し、それに応じて努力を配分します。
経験則: 機能が*「モデルをより賢くする方法」を解決する場合、それは吸収されています。「モデルを安全に現実世界に接続する方法」*を解決する場合、それは直交しています。
分析
Connector Platform が完全に直交している理由
モデルは決してネイティブに以下を行いません：- API 認証情報を保存・暗号化する (AES-GCM)
- OAuth フローを管理する (認可ページ → コールバック → リフレッシュトークン)
- クライアントの Kingdee/金蝶 ERP データベースに接続する
- Lark/飞书 または WeCom/企微 に通知をプッシュする
- どのコネクタを使用できるかについて RBAC を実施する
- コンプライアンス監査のためにすべてのツール呼び出しをログに記録する
AI コネクタビルダーが「順調」である理由は「吸収されている」のではなく
ビルダーエージェントはモデルインテリジェンスを使用して管理された永続的なコネクタエンティティを作成します — DB に保存され、エージェント全体で再利用可能で、認証情報管理と監査証跡を備えています。モデルの API 理解の向上により、ビルダーはより優れたコネクタを生成するようになり、ビルダーが不要になるわけではありません。 類似例：Cursor は Claude を使用してコードを書きます。Claude がより高度になることで Cursor はより優れたものになり、冗長になるのではありません。なぜなら Cursor はモデルが置き換えられないエンジニアリング価値（プロジェクト管理、ファイル整理、バージョン管理）を提供するからです。v0.1～v0.5の機能が「凍結」されている理由
これらの機能は悪くない — 実装され、機能し、今日の製品を実用的にしている。決定は単に、これらへの追加を停止し、努力を他にリダイレクトすることである。
マルチエージェント オーケストレーションが延期された理由
LLM プロバイダーがオーケストレーションをネイティブに構築しています:- OpenAI Swarm: ハンドオフプロトコルを備えたマルチエージェント フレームワーク
- Anthropic Claude Code Teams: タスク グラフを備えたリーダー/ワーカー エージェント プール
- Google A2A (Agent-to-Agent): エージェント間通信プロトコル
セマンティックメモリとメモリライフサイクルが延期された理由
- コンテキストウィンドウが急速に拡大しており、セッション間のメモリ検索の必要性が減少している
- プロバイダーがネイティブメモリ機能を追加している（ChatGPT Memory、Claude Projects）
- 信頼性の高いメモリシステム（TTL、重要度スコアリング、セマンティック検索）を構築するエンジニアリングコストが、それが埋める縮小するギャップに比べて高い
機能レベルの分類
直交性 (v0.6+)
Tailwind
Frozen (shipped, maintain only)
検討中（無期限延期）
含意
- 不要回到v0.5的功能。 可以进行错误修复，但不能添加新功能。
- コネクタプラットフォームはコア投資です。 v0.6–v0.8は大多数のエンジニアリング時間を受け取るべきです。
- エンタープライズエンジニアリング（RBAC、監査、セキュリティ、デプロイメント）は競争優位性です。 これらは退屈ですが、防御可能です。
- 年1回再評価してください。 モデルの進歩が停滞するか、「凍結」された機能にまだ大きなギャップがある場合は、再検討してください。