title: Umaru 仕様書⇔実装 乖離調査レポート
version: 1.0
date: 2026-06-10
project: Umaru
Umaru 仕様書⇔実装 乖離調査レポート
docs 配下の全仕様書群（規範系 docs/spec/、機能別 docs/ 直下、完了棚 docs/end/）と、実装コード（src/ / backend/ / src-tauri/、main ブランチ 9ec07b1 = v1.3.0）を突合し、**「仕様にあるが未実装」「実装にあるが仕様に無い」「Philosophy / Guideline からの逸脱」**を洗い出した結果である。
0. 調査範囲と判定区分
0.1 突合に使ったドキュメント
| 区分 | ドキュメント | 扱い |
|---|
| 規範（正典） | spec/Philosophy.md、PHILOSOPHY_ALIGNMENT_REVIEW.md、CODING_GUIDELINES.md、REQUIREMENTS.md、ARCHITECTURE.md、API_SPEC.md、DESIGN.md、UX_FLOW.md、TDD_WORKFLOW.md、ONBOARDING_SETUP.md、IMPLEMENTATION_BASE.md、TODO.md | 「あるべき姿」の基準。実装との差を厳密に判定 |
| 機能仕様 | spec_umaru_v0.2_features.md（v1.1 機能追加）、spec_umaru_pose_editor_v1.md、spec_controlnet_nf4_vram8gb_v1.md | 機能単位の仕様。スコープ宣言（In/Out）を尊重 |
| 完了棚 | docs/end/ の SPEC_・STATE_・SPEC_REVIEW_（差し戻し/未達）・TECH_DEBT_ | 「実装済みとして退役した仕様」。未達指摘の解消確認に使用 |
| 統合版 | Umaru仕様書_完全版.md（v3）、Umaru_機能説明.md、QAシート | 参考（正典比較の基準には使わない） |
| 実装版 | Umaru全機能仕様書_v1.3.0_実装版.md（2026-06-10 作成） | 実装側の写し。今回の調査で誤記 3 箇所を訂正済み（§6） |
0.2 判定区分
| マーク | 意味 |
|---|
| [未実装] | 仕様書に明記されているが、コードに存在しない |
| [導線欠落] | バックエンド等に実装はあるが、UI から到達できない |
| [仕様外実装] | 実装にあるが、正典仕様書に記載がない（いわゆるバイブコーディング由来の先行実装。docs/end の個別仕様にだけ存在するものを含む） |
| [実バグ] | 仕様と実装の食い違いが実際の不具合として発現するもの |
| [逸脱] | Philosophy / CODING_GUIDELINES の原則に反する実装 |
| [Doc未更新] | 実装が正で、仕様書側の更新漏れ |
| [解消済み] | 過去の未達指摘が現在は解消されていることを確認 |
0.3 総括
| 区分 | 件数 | 深刻度の高いもの |
|---|
| 未実装 / 導線欠落 | 9 件 | お祈り「最終候補生成」UI 欠落、成長アルバムのナビ導線消失 |
| 実バグ | 1 件 | ControlNet ライセンス URL が許可リスト外で開けない |
| 逸脱（Guideline / Philosophy） | 4 件 | 外部 DL の sha256 検証なし（ControlNet モデル / 軽量 VAE） |
| 仕様外実装（正典未反映） | 約 40 API + 主要 4 機能 | API_SPEC への ControlNet DL / お気に入りの種 / 成長アルバム等の未反映 |
| Doc 未更新 | 広範（API_SPEC / ARCHITECTURE / DESIGN / UX_FLOW / TODO） | CODING_GUIDELINES §9 のドキュメント運用ルール自体が破られている状態 |
| 過去未達の解消確認 | 6 件すべて解消 | Zip Slip 対策、manifest 固定ゲート、CUDA 必須化ほか |
全体所見: 実装品質そのもの（セキュリティ境界・テスト・エラー処理・同意制）は規範に概ね忠実で、思想（Philosophy）からの本質的逸脱は見られない。最大の問題は**「実装が仕様書より 2〜3 周先に進んでおり、正典ドキュメント群が 2026-05-25〜27 で止まっている」**ことに集約される。docs/end の個別仕様は充実しているため、機能ごとの根拠は追えるが、正典（API_SPEC / REQUIREMENTS / DESIGN / UX_FLOW）だけを読んだ人は現在のアプリ像を把握できない。
1. カテゴリ A: 仕様書にあるが未実装・導線欠落
A-1. VRAM モード設定 [未実装]
| 項目 | 内容 |
|---|
| 仕様の出典 | REQUIREMENTS 4.3「VRAMモード: auto / 4gb / 8gb / 12gb_plus」、API_SPEC §3（GET /api/settings レスポンス例に "vram_mode": "auto"）、DESIGN 5.11「VRAMモード、NSFW警告、EXIF削除を明確にする」 |
| 実装の現状 | AppSettings（backend/models.py・src/types.ts）に vram_mode キー自体が存在しない。設定画面にも項目なし |
| 補足 | ControlNet 経路は VRAM 量の自動検出（<6GB: sequential offload / NF4+≥6GB: フル GPU / <12GB: model offload / ≥12GB: フル GPU）で代替されており、ユーザーが手動で上書きする手段が無い。通常生成経路にはオフロード自体が無い |
| 推奨 | 自動判定で足りるなら REQUIREMENTS / API_SPEC / DESIGN から項目を削除し「自動判定」と明記。手動上書きが必要なら設定として実装 |
A-2. お祈りラボの比較テーマ「seed」「steps」 [未実装]
| 項目 | 内容 |
|---|
| 仕様の出典 | docs/end/SPEC_SDWebUI知見_お守りお祈りラボ成長アルバム.md §8.2 — PrayerCompareTheme = none / cfg / seed / sampler / steps / prompt_tag の 6 種。UX_FLOW §8「指示への忠実度、雰囲気の種、描き方、描き込み量、タグ差分などを割り当てる」 |
| 実装の現状 | backend/models.py の PrayerCompareTheme は none / cfg / sampler / prompt_tag の 4 種のみ。_build_compare_overrides にも seed / steps 分岐なし。フロント（src/types.ts）も同じ 4 種 |
| 推奨 | 「雰囲気の種を比べる」「描き込み量を比べる」を追加実装するか、仕様側を 4 テーマに縮小して確定する |
A-3. お祈り「最終候補生成（final）」の UI 導線 [導線欠落]
| 項目 | 内容 |
|---|
| 仕様の出典 | API_SPEC §8 POST /api/prayer-sessions/{id}/final（最終候補生成）、UX_FLOW §8 のフロー「グループ勝者を確定 → 最終候補生成 → 最終勝者を選択 → この子らしさへ保存」 |
| 実装の現状 | バックエンドの generate_final エンドポイントは存在するが、PrayerView の useMutation は create / generate / rank / finalize-groups / save-winners / regenerate / fillMissing のみで、/final を呼ぶ UI が無い。実フローは「決勝へ（finalize）→ 保存（save-winners）」に短縮されている |
| 推奨 | 現行 UI フローを正とするなら API_SPEC / UX_FLOW から「最終候補生成」段階を削除し、/final エンドポイントを退役（または温存理由を明記）。元仕様の 2 段決勝を復活させるなら UI を追加 |
A-4. 成長アルバムのナビ導線 [導線欠落]＋[記録矛盾]
| 項目 | 内容 |
|---|
| 仕様の出典 | TODO.md P1（完了 [x] 印付き）の実装記録に「ナビ『成長アルバム』タブ追加」と明記。UX_FLOW §8.5 に専用フロー図あり |
| 実装の現状 | growth タブは AppContent にレンダリング実装があり、生成中許可タブ集合にも含まれるが、navigation.ts の baseNavItems に無く、HomeView のカードにも無い。つまり現 UI からは到達不能（experiment / release も同様だが、これらは元々ナビ掲載の確約が無い） |
| 考察 | TODO の完了記録と現状が矛盾しており、ドロワー化（HF-02）等の後続改修でナビ定義から脱落した可能性が高い。機能一式（API・ビュー・テスト）は生きているのに入口だけ消えている |
| 推奨 | baseNavItems への再追加（1 行）か、意図的に隠したのであれば TODO.md / UX_FLOW にその決定を記録 |
A-5. オンボーディング仕様の未達分 [未実装]
ONBOARDING_SETUP.md（および PHILOSOPHY_ALIGNMENT_REVIEW.md の推奨対応）のうち、未対応のもの。
| 仕様項目 | 出典 | 実装の現状 |
|---|
| 画面名を「制作環境の準備」に寄せる | ONBOARDING 4.1、PHILOSOPHY_REVIEW 4.2 | SetupView の見出しは「セットアップと診断」のまま。タブ名は「初回セットアップ/未セットアップ/ステータス」遷移 |
| ホームの初回チェックリスト（「最初にできること」） | ONBOARDING 4.2、PHILOSOPHY_REVIEW 4.3 | HomeView は入口カード＋統計のみ。チェックリスト無し |
| 診断結果のコピー（個人パス伏せ込み） | ONBOARDING 8.3 / 10.3 | 「診断結果をコピー」に相当する機能はリポジトリ内に存在しない（生成エラーの報告用コピーは GenerationOverlay にあるが、セットアップ診断のコピーは無い） |
| 起動失敗時の最低保証（ログを開く / 診断コピー / 環境再構築 / 説明を見る） | ONBOARDING 3.2 | StartupFailureScreen は「もう一度確認する」ボタンのみ |
| Remember の 15 枚条件を制作文脈で説明 | PHILOSOPHY_REVIEW 4.4 | 「学習には15枚以上必要です。あと N 枚追加してください」のみで、「表情や角度が少しずつ違う画像が必要」という理由説明は無い |
| 準備カード形式（基本環境/画像生成/キャラクター制作/タグ辞書/学習機能/保存場所） | ONBOARDING 4.3 | SetupView は診断リスト＋「画像生成を始めるまでの手順」形式。カテゴリ構造は近いがカード化・「あとで」ボタンは無い |
※ ONBOARDING §9.1〜9.4（sd-scripts 導線 / accelerate 優先順 / CUDA 必須化 / VITE_UMARU_ALLOW_CPU_TRAINING）はすべて実装済みであることを確認した（カテゴリ E 参照）。
A-6. model_adapters テーブル [未実装（デッドスキーマ）]
- ARCHITECTURE 8.10 に「モデルアダプタ定義」として記載され、database.py に CREATE TABLE も存在するが、INSERT / SELECT するコードがバックエンドのどこにも無い。
- モデル一覧は毎回 model_dir のファイルスキャン（
detect_models）で賄われており、テーブルは初期構想の残骸。
- 推奨: 将来のモデル登録 manifest（ONBOARDING §11 v2.0 スコープ）まで温存するなら ARCHITECTURE にその旨を注記。使わないなら削除マイグレーション。
A-7. 成長アルバムの「候補を生成する」ループ [仕様と実装の解釈差]
- UX_FLOW 8.5 のフロー図は「候補を生成する → 選ぶ → 次の特徴を足す」と成長アルバム内に生成ステップを描いている。
- 実装の GrowthAlbumView は生成機能を持たず、既存アルバムから採用画像を選ぶだけ（生成は「つくる」画面に依存し、prompt_append を手動で反映する導線も無い）。
- 元仕様（SPEC_SDWebUI知見 §9）は「ユーザーが各段階で良い候補を選ぶ」が主眼なので思想的には整合するが、「段階のプロンプトで生成画面へ飛ぶ」導線が無いため、フロー図どおりの体験にはなっていない。
A-8. TODO.md の未完了項目（抜粋・現在も未対応のもの）
P0 はリリース運用系（実機確認・記録）なので除外し、コード実装に関わる P1/P2 の未対応分のみ:
| TODO | 状態 |
|---|
| API 契約を OpenAPI / 型生成で固定 | 未対応（REQUIREMENTS 7 / ARCHITECTURE 12 でも既知課題として明記） |
| エラー code 一覧の固定化 | 未対応（error_classify.py に分類はあるが一覧文書なし） |
| React Query の query key 定数化 | 未対応（文字列直書きのまま） |
| UI 文言の辞書化（creator/expert 差分含む） | 部分対応（terminology.ts は 7 語のみ。大半の文言は各コンポーネント直書き） |
| migration のバージョンファイル化 | 未対応（database.py 内に直列実装。ただし冪等で後方互換は維持） |
| API client のリソース別分割 | 未対応（api.ts 単一） |
| album 削除時の画像ファイルと記憶画像コピーの整合性テスト | 専用テストは未確認 |
| 学習候補の最低枚数・警告文言の確定 | 実装は 15 枚ハードコード（仕様確定の記録なし） |
A-9. 仕様内で「未実装」と正しく宣言されているもの（乖離ではない）
以下は仕様側が明示的にスコープ外/将来としており、未実装でも整合:
- prompt resolver の本格化（自然文変換・LLM 補完）— REQUIREMENTS 6 で初期スコープ外
- FLUX / 動画生成 / クラウド同期 / NSFW 自動検閲 — 同上
- ポーズ v1.1+（関節回転制約・60fps 計測・顔/手指キーポイント）— pose 仕様の Out of Scope / 残り宣言どおり
- ControlNet B 案（低解像→高解像 2 パス）— controlnet_nf4 仕様 §0 で非スコープ宣言どおり
- VRAM キューの LLM 停止がスタブ — REQUIREMENTS 4.7 が「将来のLLM処理」と明記しており、現状は将来枠の placeholder として整合
2. カテゴリ B: 実装にあるが正典仕様書に無い（仕様外実装）
ここに挙げるものの多くは docs/end/ の個別 SPEC には根拠があるため、「無断実装」ではなく「正典への反映漏れ」である。ただし CODING_GUIDELINES §9 は「API 変更時は API_SPEC.md を更新する」「画面導線変更時は UX_FLOW.md と DESIGN.md を更新する」と定めており、運用ルール上は逸脱状態にある。
B-1. API_SPEC.md に存在しない実装済みエンドポイント（約 40 本）
| 機能群 | 未記載エンドポイント | 根拠仕様の所在 |
|---|
| ControlNet モデル DL | GET /api/pose/controlnet/models、POST /api/pose/controlnet/download、GET /api/pose/controlnet/download/status | pose 仕様の「残: DL導線」を実装した後発分。個別仕様も無い（完全な仕様外実装） |
| アルバム再生成系 | GET /api/album/{id}/restore、POST /api/album/{id}/open-folder、GET /api/album/{id}/download | docs/end/SPEC_SDWebUI知見_アルバム再生成_seedタグ表示.md |
| キャラタグ一括変更 | POST /api/album/reassign-character | v1.3.0 アプデ内容.txt のみ（docs/spec・docs/end に仕様なし） |
| お気に入りの種 | GET/POST /api/favorite-seeds、DELETE /api/favorite-seeds/{id} | docs/end/SPEC_SDWebUI知見（§7） |
| 成長アルバム | /api/growth-albums 系 6 本 | docs/end/SPEC_SDWebUI知見（§9〜10） |
| お祈りラボ | PATCH /api/prayer-sessions/{id}/compare-theme | docs/end/SPEC_SDWebUI知見（§8） |
| プロンプト支援 | GET /api/negative-charms、POST /api/prompt/cleanup、POST /api/prompt/estimate-volume | docs/end/SPEC_SDWebUI知見（§4〜6） |
| 辞書拡張 | GET /api/dictionaries/entries、POST /api/dictionaries/import-custom、POST /api/tags/color-to-tag | docs/end/SPEC_辞書タグ正規化_全プロンプト候補.md、spec_umaru_v0.2_features.md |
| キャラクター拡張 | GET /api/characters/summaries、PUT/DELETE /api/characters/{id}/cover | docs/end/SPEC_実機確認追加改善（HF-04/HF-15 系） |
| 法的通知 | GET /api/legal-notices | docs/end/SPEC_ライセンス方針と生成中UX.md |
B-2. API_SPEC.md と実装でレスポンス / 形式が食い違うもの [Doc未更新]
| 箇所 | API_SPEC の記載 | 実装 |
|---|
| POST /api/generate のレスポンス | ジョブ dict {id, status, progress, message} | {"message": "生成を受け付けました", "job_id": "<uuid>"}（フロントも job_id 形式を期待） |
| GET /api/settings | vram_mode を含む | 含まない（A-1）。代わりに controlnet_openpose_path があるが、これは API_SPEC §5 の追記には載っている |
| GET /api/album | 「limit: 1-80。既定 40」 | limit=0 で全件取得が可能（AppContent が利用）。ページング自体は実装済み |
| ジョブ終端状態 | DESIGN 4.3「completed / error / cancelled」 | ＋ failed / partial / partial_failed（お祈り組）。job_store と src/app/types.ts は 6 種で同期済み |
B-3. 正典に存在しない主要機能ブロック
| 機能 | 実装規模 | 正典への記載状況 |
|---|
| ポーズエディタ全体 | src/features/pose 一式（21 関節リグ・11 プリセット・OpenPose 書き出し・i2i/ControlNet 投入） | REQUIREMENTS / DESIGN（タブ一覧）/ UX_FLOW に一切登場しない。独立仕様 spec_umaru_pose_editor_v1.md のみ |
| ControlNet 生成経路 | backend/services/controlnet_service.py、PoseControlNetRequest | REQUIREMENTS 4.6 の生成入力一覧に無し。API_SPEC には後追記あり（DL 系を除く） |
| 軽量 VAE（TAESDXL / TAESD） | enable_taesdxl 既定 ON、HF から自動取得、フォールバック付き | どの仕様書にも存在しない（ControlNet NF4 仕様に間接登場するのみ）。既定 ON の外部 DL なので本来は仕様化必須（C-2 参照） |
| 複数 LoRA（lora_list、最大 5 件・個別強度） | GenerateRequest.lora_list、adapter 方式適用 | TODO P3 に「LoRA複数指定と個別重みを扱う」が未チェックのまま存在（実装済みなのに残タスク表示）。API_SPEC は単一 loras/lora_weight のみ記載 |
| パイプラインキャッシュ / 通常⇔ControlNet の相互解放 | generation_service / controlnet_service | ARCHITECTURE 9.3 に「pipeline cache」の語のみ。動作仕様は v1.3 アプデ内容にだけ記述 |
| つくる⇔メインのキャラ選択連動 / アルバム一括キャラ変更 | v1.3.0 | 正典未反映（アプデ内容 txt のみ） |
| Tips（待ち時間の祈璃コメント） | src/tips.ts | IA-01 に仕様あり（end 棚）。DESIGN へは未反映 |
B-4. ARCHITECTURE.md の構成記述と現実装の差 [Doc未更新]
| 項目 | ARCHITECTURE の記載 | 現実装 |
|---|
| バックエンド構成 | 「backend main.py を router 分割する（今後）」 | 分割済み（routers/ 8 本＋services/ 6 本。docs/PHASE3/4 リファクタ記録あり） |
| フロント構成 | 「現状は src/App.tsx に集中。今後 feature 分割」 | 分割済み（features/ 14 ディレクトリ）。ただし計画名 features/remembering→実際は remember、src/shared/*→実際は src/components・src/app |
| DB スキーマ | migration 1〜2 相当まで | favorite_seeds・growth_album_*・compare_theme/compare_config・variation_label/generation_overrides・prayer_candidates.seed・characters.builder_state（migration 3〜7）が未記載 |
| Tauri コマンド | 10 個 | 実装は 13 個（show_main_window / select_file / save_bytes が未記載） |
| レイアウト | DESIGN 3「左側に固定サイドバー」 | HF-02 でドロワー化（ハンバーガー開閉）。タブ一覧にもポーズ無し |
| 配布 resources | backend / assets / resources | ＋ LICENSES / EULA.txt / NOTICE.txt も同梱 |
B-5. ナビに無いタブ（experiment / release）
- DESIGN 2 の情報設計では「実験室」「配布準備」が主ナビゲーションのタブとして定義されているが、実装の baseNavItems には無く、レンダリング分岐だけが存在する（到達手段なし）。
- A-4 の growth と合わせ、「実装上タブとして存在するがナビから到達できない」3 タブとして同根の問題。
3. カテゴリ C: Philosophy / CODING_GUIDELINES からの逸脱
C-1. ControlNet ライセンス URL が外部 URL 許可リスト外 [実バグ]＋[逸脱]
| 項目 | 内容 |
|---|
| 事象 | SettingsView（ControlNet モデル DL カード）はモデルの license_url（https://huggingface.co/xinsir/controlnet-openpose-sdxl-1.0）を openExternalUrl で開く。しかし src-tauri/lib.rs の許可リストは https://github.com/DraconicDragon/ と https://github.com/DominikDoom/ の 2 プレフィックスのみ。Tauri 実行時はライセンスリンクのクリックが必ずエラーになる |
| 抵触する規範 | ARCHITECTURE 7「外部URLオープンはGitHub上の許可済み辞書ソースに限定する」— 方針自体は守られているが、ControlNet DL 機能の追加時に許可リスト拡張と仕様更新を怠った。ライセンス確認導線が死んでいるのは「ライセンス注意を目立つ場所で示す」（DESIGN 1）にも反する |
| 推奨 | lib.rs の許可リストへ https://huggingface.co/xinsir/（または registry の license_url 厳密一致）を追加し、ARCHITECTURE 7 を「許可済み辞書ソースおよびモデル配布元」へ改訂。TODO のテスト項目「Tauri command の許可URLテスト」の実装も推奨 |
C-2. 外部ダウンロードの sha256 検証が部分的 [逸脱]
| 対象 | sha256 検証 | 同意 UI | 評価 |
|---|
| sd-scripts ZIP（学習ランタイム） | あり（manifest 固定＋配布ゲート連動） | あり | ✓ 規範どおり |
| 外部辞書 CSV | （ユーザー自身が配置） | あり（consent_required） | ✓ |
| ControlNet モデル（約2.5GB） | なし（HF resolve URL を httpx で直 DL） | あり（ライセンス同意チェック） | ✕ CODING_GUIDELINES 6「外部ダウンロードはsha256検証を行う」に違反 |
| 軽量 VAE（TAESDXL / TAESD） | なし（diffusers 経由で HF から自動取得） | なし（enable_taesdxl 既定 ON。ユーザーへの説明・同意なし） | ✕ 同上＋「外部依存はユーザー同意と分離」（Philosophy: Local First / PHILOSOPHY_REVIEW 1）との緊張。LPW（compel）はパッケージ同梱なので問題なし |
| pip インストール（torch ほか） | pip 既定の hash 機構なし（requirements にピンなし） | あり（ボタン操作＋容量説明） | △ 慣行上許容範囲だが、requirements のバージョン固定は弱い |
軽量 VAE は「初回 VAE 復号が遅い問題」への合理的な既定だが、ローカル完結を明示する Philosophy のアプリが、ユーザーへの予告なしに HF へ接続する点は説明責任の穴になっている。最低限、設定/セットアップ画面での説明文と、レジストリ（リポジトリ ID 固定）の明文仕様化を推奨。
C-3. ドキュメント運用ルール自体の不履行 [逸脱（運用）]
CODING_GUIDELINES §9 の定め（仕様変更時は docs/spec を更新 / API 変更時は API_SPEC 更新 / 導線変更時は UX_FLOW・DESIGN 更新 / 実装済み・未実装・要確認を混ぜない）に対し:
- API_SPEC は 2026-05-25 で停止し、以後の約 40 エンドポイントが未反映（B-1）。
- TODO.md は実装済み項目（複数 LoRA、画像詳細画面、アルバムページング、お祈り seed 可視化、キャラ Prompt 雛形、インストーラ日本語化、App.tsx 分割、main.py/services.py 分割…）が未チェックのまま残り、**「実装済みと未実装が混在」**という、ガイドラインが明示的に禁じた状態になっている。
- 正典の更新が止まった結果、現状を反映した文書が docs/end の個別仕様・アプデ内容 txt・今回の実装版仕様書に分散している。
C-4. 巨大ファイル化 [逸脱（軽度・ガイドライン精神）]
- backend/routers/workflows.py が 133KB / 約 2,600 行（setup・characters・generate・album・prayer・growth・remember・exports が同居）。TODO P2 の「main.py を機能別 router に分割」は形式上達成したが、分割粒度は当初計画（setup / characters / generation / album / memory / prayer / remembering / release …）に達しておらず、実質「main.py が workflows.py に改名された」状態に近い。
- services/generation_service.py 64KB、GenerateView.tsx 33KB、PrayerView.tsx 30KB も同傾向（フロントは hooks 切り出しで緩和済み）。
- 明文ルール違反ではないが、CODING_GUIDELINES 3.4 の分割思想とは不整合。docs/TECH_DEBT_TDD_ROADMAP_2026-06-04.md にも残債として記録されている。
C-5. 軽微な命名・構成の乖離
| 規範 | 実装 | 評価 |
|---|
| features/remembering（GUIDELINES 3.4） | features/remember | 機能同一。命名のみ |
| src/shared/components・shared/api・shared/types | src/components・src/api.ts・src/types.ts | 役割同一。階層のみ |
| WindowTitlebar に「Umaru」表示 | — | IMPLEMENTATION_BASE が「アプリタイトルに残る Umaru は対象外」と許容済み。サイドバー（ドロワー）からは brand 削除済みで思想対応済み ✓ |
C-6. Philosophy 整合の総評（逸脱なしの確認）
以下は調査の結果、思想どおり実装されていることを確認した:
- ユーザー選択主体（お祈りのランク付け・成長アルバムの段階選択に LLM 自動評価なし — SPEC の非目標宣言どおり）
- 失敗を次の行動に変える設計（エラー 4 分類＋カテゴリ別アクションボタン、診断の cause/next/beginner 3 段説明）
- Local First（生成・学習・DB すべてローカル。外部送信なし。例外は C-2 の HF 取得のみ）
- 外部資産の分離と同意（モデル/LoRA/辞書/sd-scripts 非同梱、同意ゲート、出典・ライセンス・同意日時の DB 記録）
- 日本語 UI 文字列の維持、エラーの日本語 message + 機械可読 code
- セキュリティ境界（token 認証・パストラバーサル拒否・Zip Slip 対策・shell=True 不使用・127.0.0.1 bind・CSP/CORS 限定）と、その契約テストによる固定（TDD_WORKFLOW どおり。CI のカバレッジゲート backend 29% / フロント純ロジック 95/90 も実在を確認）
4. カテゴリ D: 過去の差し戻し・未達指摘の解消状況 [解消済み]
docs/end/SPEC_REVIEW_配布前実装ゲート_差し戻し.md の未達 6 件、および関連レビューの現状:
| 未達指摘 | 現状 |
|---|
| 未達1: release-gate が本家環境で即死 | scripts/release_check.py は整備済み（npm run release-gate）。実行成否は運用確認事項 |
| 未達2: 署名 / Defender / SmartScreen が無確認で ready になる | release.py は RELEASE_CHECK_*.md の存在のみで「人手確認が必要」の pending を返す設計に修正済み ✓ |
| 未達3: pending 残りでも成功扱い | release/status は blocking（failed+pending）件数で ready 判定 ✓ |
| 未達4: sd-scripts ZIP に Zip Slip 対策なし | training_runtime._extract が絶対パス・ドライブレター・..・symlink を拒否 ✓（docstring に明記） |
| 未達5: sd-scripts が main 取得で commit/sha256 未固定 | manifest 固定＋未固定なら配布ゲート pending。開発時のみ accept_unpinned ✓ |
| 未達6: CUDA 判定タイミングで GPU 環境が CPU requirements に寄る | training-runtime/install が payload で profile を受ける形に修正済み ✓ |
| IA-04/05/06（sd-scripts 一式検証 / accelerate 解決順 / CUDA 必須化） | すべて実装確認 ✓（VITE_UMARU_ALLOW_CPU_TRAINING、エラーコード training_cuda_required / torch_cuda_missing / accelerate_missing を含む） |
| TECH_DEBT_Pythonサイドカー配布（PyInstaller 化） | 方針転換で解消: PyInstaller ではなく embedded Python 同梱方式（SPEC_PythonEmbedded同梱.md）を採用。負債文書は旧方針のまま end 棚に残置（読み手への注意のみ） |
5. 推奨アクション（優先度順）
| 優先 | アクション | 対応する指摘 |
|---|
| 1 | lib.rs の外部 URL 許可リストに ControlNet モデルのライセンス URL（huggingface.co 配下）を追加し、ARCHITECTURE 7 を改訂 | C-1（実バグ） |
| 2 | growth タブを baseNavItems へ復帰（または隠した決定を記録）。experiment / release の扱いも確定 | A-4、B-5 |
| 3 | ControlNet モデル DL に sha256（または少なくともサイズ・ETag）検証を追加。軽量 VAE の自動取得を設定画面で明示（必要ならトグルの説明文に「Hugging Face から取得」と記載） | C-2 |
| 4 | API_SPEC.md を実装に同期（B-1 の約 40 本、generate レスポンス形式、ControlNet DL 系は新規仕様起こし）。あわせて OpenAPI 自動生成の導入（TODO P1）を検討 | B-1、B-2、C-3 |
| 5 | TODO.md の棚卸し（実装済み項目のチェック付け替え）。REQUIREMENTS / DESIGN / UX_FLOW / ARCHITECTURE の 5/25 版を v1.3 実態へ改訂（ポーズ・ControlNet・複数 LoRA・軽量 VAE・ドロワー UI・migration 3〜7 を反映） | C-3、B-3、B-4 |
| 6 | vram_mode・お祈りラボ seed/steps テーマ・/final エンドポイントの 3 件について「実装する/仕様から落とす」を決定 | A-1、A-2、A-3 |
| 7 | ONBOARDING 残件（診断結果コピー・起動失敗画面の導線強化・15 枚条件の理由説明・初回チェックリスト）の実装計画化 | A-5 |
| 8 | model_adapters テーブルの去就決定 | A-6 |
| 9 | workflows.py の機能別 router 分割（TECH_DEBT_TDD_ROADMAP の残債） | C-4 |
6. 付記: 実装版仕様書（2026-06-10 作成分）の自己訂正
今回の突合過程で、先に作成した docs/Umaru全機能仕様書_v1.3.0_実装版.md 側の誤りも 3 箇所発見し、同ファイルを直接修正済み:
- WebSocket パス
/ws/setup-progress → 正しくは /ws/setup/progress（2 箇所）
POST /api/setup/install-python の説明「embedded python の展開」→ 正しくは存在確認のみ（展開は Tauri 側 setup_python_environment の責務）
調査日: 2026-06-10 / 対象: main ブランチ 9ec07b1（v1.3.0）。実装確認はコード精読（routers / services / features / lib.rs / navigation / 設定モデル）と grep 突合による。実機での動作再現（C-1 のクリックエラー等）は未実施のため、挙動断定が必要なものは実機確認を推奨する。