読み取り
slack-issues-2026-09-07より、直近の中心は実データ利用で見えた「生成完了の意味」とモデル選択・更新の問題。次の順序は調査からの提案であり、チームが決めた優先順位ではない。
- #905: 分析対象が欠けていないことを分かるようにする。 抽出意見数の違いをモデル品質差と解釈する前に、入力回答ごとの成功・正常な0件・失敗を区別する。workers削減は追試での回避策であり原因特定ではない。
- #908: UIの選択と実際の呼び出しを一致させる。 モデル比較の前提でもある。環境固有情報を公開せず、UIとproviderの契約として整理する。
- #906 / 907と909: 個別追加と継続保守を接続する。 必要モデルを追加する作業とモデル管理全体の設計を切り分けつつ、一覧・料金・説明・対応機能の不整合を増やさない。モデル名とAPI互換性は実装時に別途確認する。
- #884: 作成前の確認と実行後の完全性を別々に扱う。 事前APIチェックが成功しても、実行中の全呼び出し成功を保証しない。#905をpreflightだけで解決した扱いにしない。
serverless版の移管・デモ簡素化・横断戦略会議は、中期の運用と製品方針として別途追う。観測したSlackから採用や移管完了は断定できない。
Open Questions
- 部分失敗の数だけでなく、影響した入力や処理段階をどう利用者へ伝えるか。
- モデル比較を再開する際、処理完全性の確認と同一条件のラベル比較をどう組み合わせるか。
Updates
- 2026-09-07: SlackとIssueを照合。実装着手・assign・対人連絡は行っていない。