追加AIサービスのサポートはCoreを変えない方式で検討します
現在公式サポート範囲外のAIサービスを追加する際、既存Providerと記憶Coreを汚染しないようにAdapter分離原則に従い拡張可能性を検討しています。
新しいAIサービスが継続的に登場し既存サービスの画面も頻繁に変わります。サポートリストを素早く増やすことだけを目標にすればProvider別の例外がCoreに混ざり既存サービスまで不安定になる可能性があります。5BY.AIは追加サポートを検討する時、検知ロジックをAdapterに隔離する原則を優先します。
新しいProvider一つをサポートするために既存Providerと記憶構造が共に変わってはいけません。
今回のアップデートで変わった点
- 候補AIサービスの対話DOM、conversation識別と完了イベントをread-onlyで調査します。
- Provider-specific selectorと検知ロジックをAdapterオプションとして分離できるか確認します。
- logical pair、Pack、Saved、AnchorとHandoffは既存Core契約をそのまま使います。
- 既存公式サポートProviderに回帰がないか別途検証します。
- 公式サポートとして発表する前に実際の収集、保存と再侵入の流れが安定しているか確認します。
ユーザーが確認する方法
- ユーザーは現在公式サポート範囲に含まれるAIサービスを優先して使います。
- 新しいサービスのサポート要請は/feedbackに使用目的と共に残せます。
- サポート候補が公開されても実験状態と公式サポート状態を区別します。
- 公式サポートとして確定されればホームページと案内ページのProvider契約を共にアップデートします。
実際の使用の流れでの例
例えばユーザーが現在の改善状態を確認する時はユーザーは現在公式サポート範囲に含まれるAIサービスを優先して使います。新しいサービスのサポート要請は/feedbackに使用目的と共に残せます。その後公式サポートとして確定されればホームページと案内ページのProvider契約を共にアップデートします。この過程では次の範囲を現在の完了状態と混同しない必要があります。サポート要請が多いという理由だけで安定性検証なしにProviderを追加しません。このように確認すればすでに提供される機能とまだ安定化中の部分を分離して理解できます。
変更前と以降を区別すれば
改善前は現在提供される範囲とまだ安定化中の部分が一つの文章の中に混ざって見える可能性がありました。今回の整理では現在公式サポート範囲外のAIサービスを追加する際、既存Providerと記憶Coreを汚染しないようにAdapter分離原則に従い拡張可能性を検討しています。すでに提供される機能はそのまま保存し、改善対象だけを別途説明しユーザーが現在の状態を誇張なく理解できるようにしました。
適用範囲と知っておく点
- サポート要請が多いという理由だけで安定性検証なしにProviderを追加しません。
- Coreに特定ProviderのDOM selectorや例外分岐を入れません。
- 非公式実験状態を公開サポートとして表現しません。
- AIサービス自体のポリシー、地域制限とアカウント機能は5BY.AIが制御しません。
5BY.AI全体構造でこの変更が重要な理由
サポート範囲を拡張する目的はProviderの数を増やすことではなくユーザーの思考連続性をより多くの環境で維持することです。Adapter境界を守れば一つのサービスのUI変更が他のサービスとCore記憶構造に影響を与えるリスクを減らせます。
今回のアップデートを確認する基準
- 改善中の範囲とすでに安定的に提供される範囲を同じ文章で混ぜない必要があります。
- UIとProvider互換性の改善が記憶Coreの保存単位とユーザー選択契約を変更しない必要があります。
- 完了していない項目は現在の提供機能のように表現せず後続アップデートで状態を更新する必要があります。