diff --git a/.claude/hooks/check_sync.sh b/.claude/hooks/check_sync.sh deleted file mode 100644 index 3d05aa3..0000000 --- a/.claude/hooks/check_sync.sh +++ /dev/null @@ -1,65 +0,0 @@ -#!/usr/bin/env bash -# SessionStart hook: ローカルブランチが origin と同期しているかをチェックし, -# JSON で systemMessage (UI 表示) と additionalContext (モデルに注入) を出力する. -# 読み取り専用 (git fetch のみ). 失敗してもセッション開始は阻害しない. -# -# GUIDE_03「直列運用」「main を常に動作可能」を補助する目的で, -# 古い main から作業を始めるミスをセッション開始時に可視化する. - -# JSON 整形は Python に任せる (jq 非依存. 既存 hook も Python を利用). -# python3 / python / py の差は run_python.sh が吸収する (見つからなければ非ブロックで失敗). -emit() { - local msg="$1" - PYTHONIOENCODING=utf-8 bash "$(dirname "$0")/run_python.sh" - "$msg" <<'PY' -import json, sys -msg = sys.argv[1] -print(json.dumps({ - "systemMessage": msg, - "hookSpecificOutput": { - "hookEventName": "SessionStart", - "additionalContext": msg, - }, -}, ensure_ascii=False)) -PY -} - -# git リポジトリ外なら静かに終了 -git rev-parse --is-inside-work-tree >/dev/null 2>&1 || exit 0 - -# origin が未設定なら静かにスキップ (個人 clone・ローカル実験用途) -git remote get-url origin >/dev/null 2>&1 || exit 0 - -# fetch (5 秒で打ち切り). 失敗 = オフライン等. 警告だけ出して継続. -if ! timeout 5 git fetch --quiet origin 2>/dev/null; then - emit "[sync-check] origin への fetch に失敗 — オフラインの可能性" - exit 0 -fi - -BRANCH=$(git branch --show-current) -# detached HEAD は判定できないので静かに終了 -[ -z "$BRANCH" ] && exit 0 - -LOCAL=$(git rev-parse HEAD 2>/dev/null) || exit 0 -REMOTE=$(git rev-parse "@{u}" 2>/dev/null) -if [ -z "$REMOTE" ]; then - emit "[sync-check] $BRANCH は upstream 未設定" - exit 0 -fi -BASE=$(git merge-base HEAD "@{u}") - -DIRTY="" -[ -n "$(git status --porcelain)" ] && DIRTY=" / 未コミット変更あり" - -if [ "$LOCAL" = "$REMOTE" ]; then - emit "[sync-check] ✓ $BRANCH は origin と同期${DIRTY}" -elif [ "$LOCAL" = "$BASE" ]; then - AHEAD=$(git rev-list --count "HEAD..@{u}") - emit "[sync-check] ⚠ $BRANCH は origin より ${AHEAD} コミット遅れ — \`git pull\` 推奨${DIRTY}" -elif [ "$REMOTE" = "$BASE" ]; then - AHEAD=$(git rev-list --count "@{u}..HEAD") - emit "[sync-check] ℹ $BRANCH は origin より ${AHEAD} コミット先行${DIRTY}" -else - AHEAD=$(git rev-list --count "@{u}..HEAD") - BEHIND=$(git rev-list --count "HEAD..@{u}") - emit "[sync-check] ⚠ $BRANCH は origin と分岐 (先行 ${AHEAD} / 遅れ ${BEHIND}) — rebase/merge が必要${DIRTY}" -fi diff --git a/.claude/project-mode b/.claude/project-mode new file mode 100644 index 0000000..ceeec84 --- /dev/null +++ b/.claude/project-mode @@ -0,0 +1 @@ +solo diff --git a/CLAUDE.md b/CLAUDE.md index fd8c40c..a05992e 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,10 +1,11 @@ -# プロジェクト名 +# TIASJudgeModel - +舌領域をセグメンテーション済みの舌画像から舌色 5 分類（紫・暗赤・紅・淡紅・淡白）を推定する機械学習モデルの研究開発． +学習は研究室の計算サーバで行い，臨床データは手元 PC に置かない． ## 開発進捗 -最新: GUIDE_01 に従いプロジェクト立ち上げ中 +最新: 立ち上げフェーズ 1（方針決定）完了．PLAN_01 要件定義書を作成 ※ 本欄は**最新ステップ 1 行のみ上書き更新**．詳細な進捗履歴（動機・設計判断・失敗パターン）は [docs/PROGRESS.md](docs/PROGRESS.md) に追記する．運用ルールは `.claude/rules/progress-log.md` を参照（該当ファイル編集時に自動ロードされる）． ## 必須ルール（コード実装時） @@ -73,6 +74,8 @@ ### 03_PLAN（計画） +- 要件定義書: docs/03_PLAN/PLAN_01_要件定義書.md + ### 04_SPEC（仕様・設計） diff --git "a/docs/01_GUIDE/GUIDE_03_\343\203\201\343\203\274\343\203\240\351\226\213\347\231\272\343\203\253\343\203\274\343\203\253.md" "b/docs/01_GUIDE/GUIDE_03_\343\203\201\343\203\274\343\203\240\351\226\213\347\231\272\343\203\253\343\203\274\343\203\253.md" deleted file mode 100644 index 7561097..0000000 --- "a/docs/01_GUIDE/GUIDE_03_\343\203\201\343\203\274\343\203\240\351\226\213\347\231\272\343\203\253\343\203\274\343\203\253.md" +++ /dev/null @@ -1,152 +0,0 @@ -# チーム開発ルール (Team Development Rules) - -チーム全員が Claude Code を用い，人間が直接コードを書くことはほぼない前提で，並行開発を破綻させずに進めるための協調ルールを定義する． - -> 本ガイドは**チーム開発モード**（`/setup` で team を選択したプロジェクト）でのみ有効．個人開発モード（solo）のプロジェクトには本ファイルは配置されない．なお `/task-create`・`/task-start`・`/task-handoff` は共通層の skill であり，solo でも Issue ベースのタスク管理に使用できる（その場合，本ガイドのチーム協調ルールは適用されない）． - -Git の規約は `.claude/rules/git-conventions.md`（push・PR・マージ手順は `.claude/skills/commit/reference.md`），1 タスクの実装パイプラインは [GUIDE_02](GUIDE_02_エージェント運用ルール.md) に従う．本ガイドはそれらの上に立つ「複数人が同時に動くときの調整」を扱う． - -## 基本方針 (Basic Policy) - -- 全員が Claude Code で開発し，実装はエージェントが行う（チーム規模はプロジェクトによる）． -- 原則として並行作業を行わず，1 人ずつ直列で開発する．急ぎではないため，スループットより単純さと `main` の整合性を優先する．これは禁止ではなく既定のスタンスであり，状況に応じた判断は妨げない（詳細は「作業の直列化」）． -- 人間の本質的な役割は「AI にできない判断と確認」（GUIDE_02 と同じ）．加えて「共有設定の番人」を担う． -- 進捗・タスクは GitHub Issues と git 履歴で追う．`CLAUDE.md` には進捗を書かない（この点は solo 既定の進捗記録ルール `.claude/rules/progress-log.md` を**上書き**する）． -- `main` は常に動作可能な状態を保つ（`.claude/rules/git-conventions.md`）．壊れたら他の作業より優先して直す． - -## タスク管理 (Task Management) - -進捗管理の補助として GitHub Issues と Projects を用いる．`gh` コマンドでの具体的な操作手順（スコープ・Projects 操作・トラブル対応）は `.claude/skills/task-start/reference.md` を参照． - -### Issue (Issue) - -Issue は**進捗管理の補助**として使う．追跡したい作業に対して立て，PR と紐付けてボードで可視化する． - -- 作業 1 単位 = 1 Issue を推奨する．既に Issue がある作業は，新たに作らずそれに従って進める（重複 Issue を作らない）． -- **Issue は着手・PR 作成・マージのいずれの段階でも必須としない**．小さい変更（typo・1 行修正等）や試験的・探索的な作業は Issue 無しで進めてよい． -- ただし**追跡する価値のある作業には Issue を立てるのが望ましい**（後追いと進捗可視化のため）．特に複数回の `/implement` に跨る作業や，他メンバーに見えていてほしい作業は Issue を作る． -- PR と Issue を紐付ける場合は本文に `Closes #` を記載する．マージ時に Issue が自動クローズされ，ボードのカードも `Done` へ移る． -- Issue 本文には少なくとも「やること」を書く．「完了条件（受け入れ基準）」は非自明な作業のみで構わない． -- 担当者は明確にしておくのが望ましい（重複着手を避けるため）． -- Issue は最初に書き切らなくてよい．作業途中の進捗・確定事項は `/task-handoff` の進捗メモとして Issue に集約し，完了は PR の `Closes #<番号>` によるマージ時の自動クローズで反映する（`/implement` のフローでは Issue を更新しない）． - -### Project ボード (Project Board) - -> ⚠ **既定では未使用**．タスク管理は Issue ベース（`gh issue list`）で運用する．Project ボードはチームが拡大したり Issue が常時 10 件超になった等の局面で再導入する想定．以下は将来導入時の参考． - -- 列: `Todo` / `In Progress` / `In Review` / `Done`． -- Issue をカードとして配置し，状態を移動して可視化する． -- マージ連動の自動化を設定し，カード移動の手作業を最小化する（設定は管理者作業．「管理者の初期設定」参照）． - -### タスクの流れ (Task Flow) - -Issue を立てる場合の標準フロー（小さい変更や探索的作業はこの限りでない）． - -```text -1. Issue 起票（完了条件を明記） -2. 自分にアサイン（ボード未使用のためアサインのみ．ボード運用復活時は In Progress へ移動） -3. main から作業ブランチ作成（git-conventions ルール） -4. /implement に Issue の内容を渡して実装（GUIDE_02） -5. PR 作成，本文に "Closes #<番号>" -6. セルフマージ条件を確認 → マージ -7. マージで Issue 自動クローズ → カード自動 Done -``` - -- 上記 1 は `/task-create`（事前定義用），2 と 3 は `/task-start `（既存 Issue から着手）で半自動化できる．Issue 無しで進める場合はどちらも不要． -- Claude へのタスク文脈は `CLAUDE.md` ではなく Issue から渡す．`gh issue view ` で取得する． - -## ブランチと PR (Branch & PR) - -`.claude/rules/git-conventions.md` に従う．チーム運用上の追加事項のみ以下に定める． - -- ブランチ命名は git-conventions ルールの基本形式（`[プレフィックス][概要]`）に従う．ブランチ名に Issue 番号は含めなくてよい． -- branch↔Issue の紐付けは PR 本文の `Closes #<番号>` で行う．マージ時に Issue が自動クローズされる．既存 Issue からブランチを作る場合は `gh issue develop` でネイティブにリンクできる（`.claude/skills/task-start/reference.md`）． -- PR の `--title` はコミットメッセージと同じ書式（`[タグ] 内容`，`.claude/rules/git-conventions.md`）． - -## レビューとマージ (Review & Merge) - -誰も手書きしない体制では，マージ条件が唯一の品質ゲートとなる．本プロジェクトは**条件付きセルフマージ**を採用する．他メンバーの Approve 待ちは原則作らない代わりに，作者自身が満たすべき条件を実質的なゲートとして定める． - -### 通常の機能 PR (Feature PR) - -次を全て満たせば，作者がセルフマージしてよい． - -- CI で全テストが緑である． -- 作者自身が Phase 1 の動作確認（実機・ブラウザ等，AI にできない確認）を済ませている（GUIDE_02）． -- `/implement` のパイプラインをスキップせず完走している． -- 対応 Issue がある場合は完了条件を満たしている（Issue 無しの PR は不要）． -- 共有設定（`CLAUDE.md` のルール部・`.claude/`）の変更を含まない． - -※ レビューは任意．他メンバーはコメントしてよいが，マージをブロックしない． - -### 共有設定を変更する PR (Shared Config PR) - -`CLAUDE.md` のルール部や `.claude/` を変更する PR は，全員の Claude の挙動を変えるため例外とする． - -- 機能 PR に混ぜず，専用 PR とする（「共有設定の扱い」参照）． -- 他メンバー 1 名の Approve を必須とする（セルフマージ不可）． - -### Dependabot の依存更新 PR (Dependabot PR) - -Dependabot が作成する依存更新 PR（security updates / version updates）は，人間が書いた PR ではないため上記の「`/implement` 完走」「Phase 1 動作確認」を満たせない．代わりに `/deps-update` のゲートを品質ゲートとする（`.claude/skills/deps-update/SKILL.md`）． - -- **`/deps-update` がマージしてよいもの**: メジャー更新でなく，競合が無く，CI 緑（CI 未構築ならローカル検証緑）の PR．`gh pr merge --merge` で取り込む．これは「AI が `main` へマージする」唯一の例外である（GUIDE_02「コミットルール」）． -- **人間が判断するもの**: メジャー更新（`0.x` のマイナー更新を含む），CI 赤，修正版の無い alert，Dependabot が PR を作れなかった alert．`/deps-update` が影響分析と推奨（そのままマージ／`/implement` で追従／`@dependabot ignore` で見送り）を PR コメントと完了報告に出すので，それを見て決める． -- 依存更新 PR は共有設定（`CLAUDE.md`・`.claude/`）を変更しないため，他メンバーの Approve は不要．`main` にブランチ保護（必須レビュー）を設定している場合は `/deps-update` はマージできないので，マージ可と判定した一覧を提示するにとどまり，人間がマージする． -- `/deps-update` を実行するのは原則 1 名（管理者またはその週の担当）とし，マージ後はチームに周知して全員が `git pull` する（直列運用のため，他メンバーの作業ブランチは次の rebase で追従する）． - -### CI 構築までの暫定ゲート (Interim Gate) - -CI が未構築の間は「CI 緑」を以下で代替する．CI 構築後はこの節を削除する． - -- `/implement` を完走している． -- ローカルで全テストが緑である． -- 作者自身が Phase 1 の動作確認を済ませている． - -## 共有設定の扱い (Shared Configuration) - -`CLAUDE.md` と `.claude/`（agents・skills・rules・hooks・settings.json・template-overrides.md）は全員の Claude の挙動を決める共有インフラである． - -- **git 追跡を継続する**．untrack や `.gitignore` 化はしない（履歴の保全と挙動の統一のため）． -- **進捗は `CLAUDE.md` に書かない**．進捗は Issues と git 履歴で追う（「タスク管理」参照）． -- **変更は「チームルール変更」カテゴリ**として扱う． - - 機能 PR に混ぜない．専用 PR とする（ブランチは `chore/` または `docs/`）． - - 他メンバー 1 名の Approve を必須とする． - - マージ後はチームに周知し，全員が `git pull` して Claude セッションを再起動する． - - ※ Claude はセッション開始時に `CLAUDE.md` を読むため，古いまま動くと文脈がずれる． -- **例外: ドキュメント一覧への追記**は，そのドキュメントを追加する PR と同じ PR で行ってよい．衝突しても両方の行を残せば解決できる． -- **個人・マシン固有の設定**は `.claude/settings.local.json` に置く．これは `.gitignore` 対象とし，共有の `settings.json` を個人都合で汚さない． - -## 作業の直列化 (Serialized Work) - -- 原則として，同時に進行中のコード作業は 1 件とする（進行中の Issue は原則 1 件．Project ボード運用復活時は `In Progress` 列も同様）． -- 次の作業に着手してよいのは，前の作業の PR が `main` にマージされた後とする（マージ条件は「レビューとマージ」参照）． -- タスクは小さく保つ．直列運用では，1 単位が小さいほど次の人の待ち時間が短くなる． -- 直列運用により並行コンフリクトと共有設定のドリフトは原理的にほぼ発生しない．例外的に並行が生じてコンフリクトした場合は `.claude/skills/commit/reference.md` の rebase 手順をフォールバックとして用いる． -- `main` を壊した場合は他作業より優先して復旧する．自分で対処できない場合は直ちにチームへ報告する（`.claude/skills/commit/reference.md`「間違えて main にコミットしてしまった場合」）． - -## メンバーのオンボーディング (Onboarding) - -新メンバー参加時の手順． - -1. リポジトリへのコラボレーター招待を承認する（GitHub の通知，または `https://github.com///invitations`）． -2. リポジトリを clone する． -3. `ENV_02_環境構築手順.md`（GUIDE_01 参照，立ち上げ時に作成）に従い開発環境を構築する． -4. `gh auth login` で GitHub CLI を認証する．Projects も操作する場合は `project` スコープを含める（`.claude/skills/task-start/reference.md`「必要なスコープ」）． -5. 必要なら `.claude/settings.local.json` を用意する（個人設定．git 追跡されない）． -6. 最初に `CLAUDE.md` と `docs/01_GUIDE/` を読む（特に本ガイドと GUIDE_02）．Git 規約は `.claude/rules/git-conventions.md` にある． -7. `.gitignore` が整備されていることを確認する（`.claude/rules/git-conventions.md`）． - -## 管理者の初期設定 (Admin Setup) - -以下は外部サービス操作を含み，原則として AI には実施できない（`gh` で操作できる設定のみ例外として注記する）．ルール確定後に管理者（人間）が一度だけ行う． - -- GitHub リポジトリの作成，メンバー招待． - - リポジトリ作成後，**GitHub リポジトリのセキュリティ設定**（Dependabot alerts / security updates の有効化）は AI が `gh api` で行う（`/setup` の Phase 3・7 で実行．コマンド・検証・トラブル対応は `.claude/skills/setup/reference.md`「GitHub リポジトリのセキュリティ設定」，背景は GUIDE_01「環境構築」）．`/setup` 完了後にリポジトリを作成した場合は，同 `reference.md` または `ENV_03_管理者用環境構築手順.md` に転記したコマンドを実行する（管理者が直接実行してもよい）． -- （既定では未使用）GitHub Project の作成，列（`Todo` / `In Progress` / `In Review` / `Done`）の定義． -- （既定では未使用）マージ連動の自動化設定（PR マージ時に Issue クローズ・カードを `Done` へ移動）． -- Issue テンプレートの用意（「やること」「完了条件」欄）． -- 共有設定変更 PR に他メンバー Approve を求める運用の周知（必要なら `main` のブランチ保護設定）． -- CI の構築（全テストを実行し，緑をマージ条件にできる状態にする）． - -※ 完了するまでは本ガイドの「CI 構築までの暫定ゲート」を適用する． diff --git "a/docs/03_PLAN/PLAN_01_\350\246\201\344\273\266\345\256\232\347\276\251\346\233\270.md" "b/docs/03_PLAN/PLAN_01_\350\246\201\344\273\266\345\256\232\347\276\251\346\233\270.md" new file mode 100644 index 0000000..7b62e8d --- /dev/null +++ "b/docs/03_PLAN/PLAN_01_\350\246\201\344\273\266\345\256\232\347\276\251\346\233\270.md" @@ -0,0 +1,83 @@ +# 要件定義書 (Requirements) + +## プロジェクトの目的 (Purpose) + +舌診支援システム [TIASjudge](https://github.com/rintoHasegawa/TIASjudge) の舌色 5 分類（紫・暗赤・紅・淡紅・淡白）を，機械学習で推定できるかを検証する．現行の TIASjudge は Lab 色空間のルールベースで分類しており，本プロジェクトでは機械学習版の到達点を把握して，将来 TIASjudge に組み込む判断材料を得る． + +本フェーズのゴールは**現状把握**である．「このデータで機械学習がどこまでできるか」を，信頼できる評価基盤の上で数値として示すことを目的とし，精度の絶対値目標は置かない． + +## 対象ユーザー (Target Users) + +- **直接**: 開発者本人（研究用途） +- **間接**: TIASjudge を使う臨床側（将来，モデルが組み込まれた場合） + +## スコープ (Scope) + +### やること (In Scope) + +- 舌領域セグメンテーション済み画像から舌色 5 分類を推定するモデルの学習・評価 +- 研究室の計算サーバでの学習基盤（コード転送・リモート実行・結果回収） +- **手元 PC に臨床データを置かずに開発できる仕組み**（合成データでの実装確認，リモート側での集計） +- 既存ルールベース（TIASjudge）との同一テストセットでの比較 +- 実験記録と評価レポート + +### やらないこと (Out of Scope) + +- 舌領域セグメンテーションモデルの学習（既にセグメンテーション済みのデータを使う） +- 舌色 5 分類以外の所見（舌苔・舌形・歯痕等） +- TIASjudge 本体への組み込み実装（別リポジトリの作業） +- 撮影条件の色補正・キャリブレーション（SmTIAS 側の課題） +- 臨床データを手元 PC に配置すること + +## データ (Data) + +| 項目 | 内容 | +| --- | --- | +| 入力 | 舌領域のみをセグメンテーションした舌画像 | +| 規模 | 1000 枚以上（正確な枚数・患者数・クラス分布は研究室 PC で確認して確定する） | +| 正解ラベル | 医師・専門家の診断記録による舌色 5 分類 | +| 保管場所 | 原本は研究室 PC．一度だけ計算サーバへコピーし，以降は再転送しない | +| 手元 PC | 一切置かない | + +## 制約 (Constraints) + +- **データ取り扱い**: 臨床データを手元 PC に置かない．リポジトリにも含めない．手元へ持ち帰るのは非個人情報の派生物のみ（集計指標・学習曲線・混同行列・ログ・モデル重み） +- **計算資源**: 研究室の GPU サーバ（共用．他ユーザーが GPU を使っていることがある） +- **接続経路**: 学外からは研究室 PC を SSH の踏み台（ProxyJump）として経由する +- **認証情報**: 計算サーバに GitHub の認証情報は置かない（コードは常に手元から送る） +- **人間の作業**: 倫理審査・データ利用許諾の確認，研究室 PC での SSH サーバ運用の可否確認 + +## 成功基準 (Success Criteria) + +本フェーズは現状把握のため，以下を満たせば成功とする． + +1. 患者単位の分割で，再現可能な評価基盤ができている +2. 同一テストセットで，既存ルールベースと機械学習モデルの性能を並べて比較できる +3. 機械学習モデルの到達点がクラス別の数値（混同行列・クラス別性能）で示され，次の判断（組み込むか・手法を変えるか）ができる +4. 手元に臨床データを置かないまま実験を回せ，その手順が文書化されている + +※ 精度の絶対値目標は本フェーズでは設定しない．ベースライン確立後に別途決める． + +## 評価の方針 (Evaluation Policy) + +- **患者単位で分割する**．画像単位のランダム分割は行わない（同一患者の画像が train / test に跨ると精度が過大に出る） +- クラス不均衡が想定されるため，accuracy だけで判断せず macro F1・混同行列・クラス別 recall を併せて見る +- 医師ラベルの評価者間のばらつきが性能の上限を決めるため，把握できる範囲で確認する +- 既存ルールベースを同一テストセットで実行し，比較のベースラインとする + +## 成果物 (Deliverables) + +- 学習・評価コード（本リポジトリ） +- リモート実行ツール（コード送信・実行・結果回収） +- 学習済みモデルの重み（研究室側に保管．必要に応じて手元へ回収） +- 実験記録・評価レポート（実装フェーズで `06_TEST` 配下に作成） + +## 前提・未確定事項 (Assumptions & Open Questions) + +研究室 PC でデータを確認してから確定する項目． + +- 画像の枚数・患者数・クラスごとの分布 +- 画像形式・解像度・マスク外領域の扱い（黒塗りか透明か） +- 患者 ID がファイル名等から辿れるか（患者単位分割の前提） +- ラベルの保存形式（CSV・アプリのデータ等），1 画像に複数評価者のラベルがあるか +- 倫理審査・データ利用許諾の状況 diff --git a/docs/PROGRESS.md b/docs/PROGRESS.md index 68e9e62..c81abf3 100644 --- a/docs/PROGRESS.md +++ b/docs/PROGRESS.md @@ -9,3 +9,12 @@ - 書式・運用ルールは .claude/rules/progress-log.md を参照 （本ファイルの編集時に自動ロードされる） --> + +## 立ち上げ（フェーズ 1: 方針決定） + +- [x] **プロジェクト方針の確定と要件定義書の作成**: TIASjudge（ルールベースの舌診支援アプリ）の舌色 5 分類を機械学習で推定する研究プロジェクトとして，目的・スコープ・成功基準を確定し [PLAN_01 要件定義書](03_PLAN/PLAN_01_要件定義書.md) を作成した．開発モードは solo． + - 前提（データ取り扱い）: 臨床データは手元 PC に置かない．原本は研究室 PC に保管し，研究室 LAN 内で計算サーバへ一度だけコピーする．手元へ持ち帰るのは非個人情報の派生物（集計指標・ログ・モデル重み）のみ．リモート実行の構成は SmTIAS-LightSim の方式（コードを手元から送り，結果を回収）を踏襲する + - 設計判断: 本フェーズのゴールを「現状把握」とし精度の絶対値目標を置かない．評価は**患者単位分割を必須**とし（画像単位のランダム分割は同一患者が train / test に跨り過大評価になる），既存ルールベースを同一テストセットのベースラインとして並べて比較する + - スコープ外: セグメンテーションの学習・5 分類以外の所見・TIASjudge への組み込み実装・撮影条件の色補正 + - 未確定: 画像枚数・患者数・クラス分布・ラベル形式・患者 ID の追跡可否は研究室 PC で実データを確認して確定する +