development-priority-roadmap-2026-05-23

2026-05-23 時点で wiki/ と GitHub current state を突き合わせると、5 月 19 日時点で最優先だった #836 #837 #833 #845 #846 #716 #740 などは 2026-05-21 〜 2026-05-22 にかけて既に close されている。したがって、今後の開発順は CLI / Web の入口整備を続ける というより、残っている user-facing bug と導入障壁を先に減らし、その後で運用基盤と中長期テーマへ進む 形に組み替えるのが妥当である。issue-priority-through-2026-09より meeting-report-draftより

ただしこれは short / mid-term の issue triage であり、CLI / workflow / plugin 計画を含む長期順は別に考える必要がある。長期の順番は strategic-development-order-2026-05-23 を参照。

先に結論

今の順番は次の 4 段がよい。

1. Windows 初回導入を通す
   #731 とその周辺 (#666, #530, #496) は、新規利用者が最初に離脱する箇所であり、いま最も直接的な価値がある。PR #863 は open だが、2026-05-25 時点では確認に必要な Windows 検証環境が整備中で、review / merge は保留になっている。したがって最優先テーマであることは維持しつつ、直近の実作業は「環境整備完了後に PR #863 を再確認して着地させる」と読むのが正確である。windows-distribution-optionsより local-dev-setupより meeting-report-draftより

2. 既に使っている人が困る直接バグを潰す
   #584、#493、#629 は「使えない・誤解する・運用で困る」に直結する。新機能より先に片付ける価値が高い。problem-list-from-open-issues-2026-05-19より

3. 公開・運用・テスト基盤を固める
   #741, #669, #558, #546, #518, #838, #721 は、単体の user-facing feature ではないが、変更を安全に出し続けるための地盤である。refactoring-statusより testingより

4. 説明責務・研究・新機能を進める
   #696, #542, #564, #577, #809, #679, #648 などは重要だが、今の main の安定化より一段後ろでよい。issue-priority-through-2026-09より

推奨順序

Phase 1. 直近 1 週間: Windows 導入経路を閉じる

対象:

• #731 Windows setup 文字化け / 中断
• PR #863 setup_win.bat を ASCII ランチャー、setup_win.ps1 を日本語案内本体に分離
• 関連確認として #666 Windows での API build error

理由:

• これは「改善要望」ではなく 最初の 1 回が完走しない 問題である
• wiki 上でも Windows は継続的な離脱点として観測されている
• PR #863 で実装案自体は既にあるので、Windows 検証環境が整い次第もっとも早く価値に変えやすい

工数目安:

• 実装確認とレビュー反映: 0.5 〜 1.5 人日
• Windows 実機または self-hosted runner での再確認込み: 1 〜 3 日
• #666 まで同時に触るなら追加 1 〜 2 人日

ここで重要なのは、#731 を直したあとに Windows の正規入口をどこまで Docker Desktop 前提で押し通すか を曖昧にしないこと。[[windows-distribution-options]] が示すとおり、当面は段階 1 (setup_win.*) を正規入口に置き、WSL2 + Docker Engine は補助ルートとして docs に残す程度が現実的である。windows-distribution-optionsより

Phase 2. 次の 1 〜 2 週間: user-facing bug を優先度順に潰す

対象候補と順番:

1. #584 レポート編集後に token usage / 推定コストが 0 になる
2. #493 ScatterChart のスクロール誤操作
3. #629 fetch_reports.py が限定公開 / 非公開を backup できない
4. #799 local dev の React version mismatch（再現が取れるなら）

理由:

• #584 は結果の信頼性表示に触るため、単なる見た目の不具合より重い
• #493 は閲覧 UX に直接効き、以前から残っている pain point である
• #629 は運用・保全の問題で、事故時の復旧力に効く
• #799 は contributor 向けだが、current 再現性が弱いなら後ろに下げてよい

工数目安:

• #584: 1 〜 2 人日
• #493: 1 〜 3 人日
  chart UX の preview と実機確認が要る
• #629: 1 〜 2 人日
• #799: 0.5 〜 1.5 人日
  ただし再現待ちなら calendar は伸びる

このフェーズは、まとめて 2 週間で 3 〜 6 人日程度 の束として扱うのがよい。小さめ PR に分けて順にマージした方がレビューしやすい。open-decisionsより

Phase 3. その次の 2 〜 4 週間: 運用基盤と fail-fast を固める

対象候補:

• #741 Azure deploy の intermittent failure
• #669 deploy 処理の最適化
• #558 API をテストしやすい設計へ寄せる
• #546 API エラーハンドリングの共通化
• #518 最新コードの static export を継続確認できるようにする
• #838 output artifact validation の位置づけを決める
• #721 は umbrella として残っているが、旧 path 前提の本文はそのまま実装計画に使わない

理由:

• ここは 1 つ 1 つの issue より、変更を安全に出し、壊れ方を早く知る ための投資
• #741 と #518 は「リリース後に壊れていないか」を見る経路
• #558 と #546 は今後のバグ修正速度を上げる
• #838 は重要だが、wiki 既存分析どおり runtime feature か test helper かを先に決める必要がある。issue-priority-through-2026-09より

工数目安:

• #741 / #669: 2 〜 4 人日
• #558 / #546: 3 〜 5 人日
• #518: 2 〜 3 人日
• #838: 設計判断 0.5 〜 1 人日、実装するなら追加 1 〜 2 人日

このフェーズ全体では 2 〜 4 週間、6 〜 12 人日 を見ておくのが現実的である。純実装より、CI 観測や rerun 待ちで calendar が伸びやすい。testingより

Phase 4. 1 〜 2 か月スパン: 説明責務・受け皿・研究テーマ

対象候補:

• #696 レポートを誤って解釈しないための導線
• #542 責任範囲の明記
• #564 活用事例の収集と公開
• #577 自動クラスタ数調整のベータ評価
• #809 UMAP 並列化
• #513 seed 固定の整理
• #679 任意カテゴリー分類
• #648 一括編集

理由:

• これらは価値が高いが、いまの main の直接不具合より後でよい
• #696 と #542 は書籍や外部公開に向けて重要なので、feature 群よりは前に寄せてもよい
• #577, #809, #513 はアルゴリズム品質・再現性・速度のトレードオフ問題で、短期の bugfix とは別レーンで扱う方がよい

工数目安:

• #696 / #542 / #564: 各 1 〜 3 人日
• #577: 2 〜 5 人日
  実装より観察設計が重い
• #809 / #513: 各 2 〜 5 人日
• #679 / #648: 各 3 〜 7 人日

このフェーズは 1 〜 2 か月 のテーマで、並行に進める前提でよい。problem-list-from-open-issues-2026-05-19より

いま着手しなくてよいもの

2026-05-23 時点では、次は後ろ倒しでよい。

• #721 の本文に書かれた旧 server/broadlistening/... 前提の大計画を、そのまま実装 backlog に戻すこと
• #586 デザインシステム基盤のような中規模リファクタ
• #690 ts-node-dev 置換のような直接価値が薄い保守改善
• #679 #648 のような大型 feature を、Windows 導入や既知バグより先に進めること

理由は、いまの main では analysis-core / workflow default 化がかなり進んでおり、priority は「未来アーキの議論」より「既にある current path を安全に使えるようにすること」へ移っているからである。refactoring-statusより

実務向けの進め方

最も詰まりにくい進め方は次の通り。

1. Windows 検証環境の整備を待って PR #863 を再確認し、その後に片付ける
2. そのブランチ / 実機確認で得た知見を #666 と docs に戻す
3. 次に #584 と #493 を別 PR で並べる
4. その後で #741 / #518 / #558 を基盤改善として着手する
5. 合間に #696 を docs / product copy issue として切り、実装量を小さく保つ

この順番なら、今困っている人を先に助けつつ、次の変更を安全に出す土台も並行で育つ。

Calendar 見積もり

1 人が主担当で、レビュー待ち込みの粗い calendar 見積もりは次の通り。

• 直近着手: Windows 検証環境の整備待ちを解消し、#731 / PR #863 の確認を再開
• 次の 2 週間: #584, #493, #629
• その次の 2 〜 4 週間: #741, #518, #558, #546, #838 の設計判断
• 6 月後半以降: #696, #542, #564, #577, #809 などの中長期テーマ

2 人以上で並行できるなら、

• 人 1: Windows / setup / deploy (#731, #666, #741, #518)
• 人 2: product bug / UX (#584, #493, #629)
• 人 3: docs / responsibility / research framing (#696, #542, #564)

の分け方が衝突しにくい。

Open Questions

• #496 Docker なし経路は、Windows 正規入口の拡張として扱うのか、研究者向け補助ルートとして扱うのか
• #838 output validation は end-user CLI 機能にするのか、maintainer 用 test helper に留めるのか
• #799 は current main でまだ再現するのか、それとも stale issue 化してよいのか
• #696 は docs issue と product issue に分けた方が進めやすいか

Updates

• 2026-05-23: 初版作成。2026-05-23 時点の open issues / open PR と既存 wiki を突き合わせ、5/21 までに close された前提作りタスクを除いた current roadmap に組み替えた
• 2026-05-25: PR #863 がなお open である一方、確認に必要な Windows 検証環境は整備中で review / merge は保留、という current state を反映