4段階ライフサイクル判定手法 & 公式ベンダー情報源
LLMEOLは、公開・検証可能なベンダー公式の非推奨化およびモデルライフサイクル専用ドキュメントのみを集約し、厳密なUTC日付計算、優先順位付きの安全なカタログ統合、フェイルクローズな配信ガードを適用しています。
日付に基づく厳密な4段階分類
各ベンダーは不統一な用語(Legacy、Preview、Deprecating、Retired、EOL)を使用しています。LLMEOLは曖昧な独自警告ステータスを作るのではなく、ベンダー固有のラベルを sourceLifecycle に保持したまま、確定したUTC提供終了日から客観的な4段階のライフサイクルステータスを厳密に算出します:
- RETIRED (
days <= 0): 確定した提供終了日がUTCで到来または経過した状態です。API呼び出しは通常HTTP 404/410で失敗するか、後継モデルへ自動ルーティングされます。 - EXPIRING (
1 <= days <= 90): 確定した提供終了日が今後90暦日以内に到来する状態です。本番開発スプリントで移行作業に着手すべき期間を示します。 - DEPRECATED (
days > 90): 確定した提供終了日が90日超の将来に予定されている状態(または終了日未公表のままMoonshot AIの公式Deprecated Models一覧に掲載されている状態)です。新規ワークロードでの採用は避け、アップグレードを計画してください。 - ACTIVE (確定した
eolDateなし): 日単位の確定した提供終了日が発表されていない状態です。"no earlier than" や "no sooner than" といった最低サポート期限の表現は、確定日が公表されるまで意図的に除外されます。
定期同期は12時間ごとに実行されます。同一の (provider, modelId) ペアに対しては、補助的なサポート対象モデル一覧よりも公式の非推奨スケジュールが常に優先されます。また、データソース単位のフェイルクローズ保持により、上流の一時的なHTTPエラーで検証済みレコードが消去されるのを防ぎます。
CodeAP Studio 3つの柱によるワークフロー
LLMEOL、DevToken、ToMarkdownはどのように連携しますか?
CodeAP Studio は3つの専門AIエンジニアリングスタジオで構成されています。LLMEOL はモデルの非推奨化を追跡して .env 設定を監査し、DevToken は後継モデルのトークン料金比較とMCP/Zodスキーマ生成を行い、ToMarkdown はPDF/DOCX/HTMLドキュメントをRAG対応のMarkdownに変換します。
公開EOL一覧を持たないアグリゲーターが除外されているのはなぜですか?
LLMEOLは、すべての提供終了日が検証可能な一次情報にリンクするよう、認証不要で公開されている専用のモデル非推奨化・ライフサイクル一覧を維持しているプロバイダーのみを収録しています。