Vol. 01
2026.06.11
PREVIEWING CONTENT

Umaru 仕様 ⇔ 実装 乖離監査レポート

Umaru 仕様 ⇔ 実装 乖離監査レポート

監査日: 2026-06-10
対象実装: main ブランチ（v1.3.0, commit 9ec07b1 時点）
監査方法: docs/ 配下の全仕様書（spec/ 中核文書、end/ の実装時/実装前 SPEC、Umaru仕様書_完全版.md、spec_umaru_v0.2_features.md 等）と、実コード（src/ / backend/ / src-tauri/）の突き合わせ。
別途作成の Umaru_全機能仕様書_実装準拠.md（実装を正とした再構成）を基準実装像として参照。

0. 総括

Umaru の実装そのものは Philosophy / CODING_GUIDELINES からほぼ逸脱しておらず、健全である。検出された乖離の大半は「ドキュメントが 2026-06-04 の大規模リファクタとバグ修正に追従できていない（文書が古い）」もの、または「後付け機能が中核仕様書（spec/REQUIREMENTS.md 等）に逆輸入されていない」ものである。実装が仕様に対して劣化・退行している箇所はごく少ない。

flowchart TD
    Audit["仕様 ⇔ 実装の差分"] --> A["カテゴリA：仕様にあるが未実装/食い違い\n（8件）"]
    Audit --> B["カテゴリB：仕様に無いが実装済み\n＝後付け・バイブコーディング（6件）"]
    Audit --> C["カテゴリC：文書が実装に遅れ\n＝実装が正・文書が古い（7件）"]
    Audit --> D["カテゴリD：Philosophy/Guideline 逸脱\n（3件＋良好多数）"]
    A --> A1["重大度・中: vram_mode 未実装 / HB30秒自爆の記述 / オンボーディング温度"]
    B --> B1["重大度・中: ポーズ/ControlNet が中核要件に未統合 / API_SPEC 大量未記載"]
    C --> C1["重大度・低（実装は正常、文書更新のみ）"]
    D --> D1["重大度・中: ControlNet DL の sha256 未検証 / 中核タブ名の改称"]
カテゴリ件数性質主アクション
A. 仕様にあるが未実装/食い違い8一部は仕様側のバグを実装が修正（良性）文書修正＋一部実装判断
B. 仕様に無いが実装済み（後付け）6機能は別 SPEC で管理されているが中核未統合中核仕様書へ逆輸入
C. 文書が実装に遅れ（実装が正）7リファクタ/バグ修正の文書未反映文書を実装に同期
D. Philosophy/Guideline 逸脱3大半の原則は遵守sha256 実装＋文言方針確認

重大度凡例: 🔴 高（配布/セキュリティ影響）/ 🟡 中（機能・整合の実害あり）/ 🟢 低（軽微・管理済み・良性）

1. カテゴリA：仕様にあるが未実装 / 仕様と実装が食い違う

A-1. 🟡 vram_mode 設定が仕様にあるが実装に存在しない

内容
仕様spec/REQUIREMENTS.md §4.3「VRAMモード: auto / 4gb / 8gb / 12gb_plus」、spec/API_SPEC.md §3 の GET /api/settings レスポンスに "vram_mode": "auto"、spec/DESIGN.md §5.11「VRAMモードを明確にする」
実装backend/models.py の AppSettings および backend/services/settings_service.py:get_settings の既定キーに vram_mode は存在しない。src/types.ts の AppSettings 型にも無く、SettingsView.tsx に VRAM モードの UI も無い。vram_mode は spec/API_SPEC.md と RELEASE_HOTFIX_2026-05-26_実機確認.md にしか出現しない（grep 確認済み）
実態手動 VRAM モードは廃され、総 VRAM 量からの自動判定に置換（controlnet_service.py:_place_controlnet_pipeline が 4GB/8GB-NF4/12GB で配置戦略を自動選択、通常生成も _optimize_pipeline_for_cuda で自動最適化）
種別仕様の機能が未実装（設計変更で代替）
推奨API_SPEC.md / REQUIREMENTS.md / DESIGN.md から vram_mode を削除し、「VRAM は自動判定」と明記。実装方針としては自動判定で妥当

A-2. 🟢 機能①の当初 API GET /api/tags/dict・/api/tags/categories が未実装

内容
仕様spec_umaru_v0.2_features.md §1-4「エンドポイント: GET /api/tags/dict → { tag_en: tag_ja }」、§3-2 の Pact 対象に /api/tags/dict・/api/tags/categories
実装両エンドポイントとも存在しない（grep で仕様書のみヒット）。内蔵辞書は dictionary_service.py:import_builtin_tag_dictionary で起動時に prompt_dictionaries テーブルへ取り込み、GET /api/dictionaries/search / /entries で引く方式
種別仕様の API 設計が未実装（別方式で同等機能を実現）
推奨spec_umaru_v0.2_features.md を「DB 取り込み＋ search 方式」に更新（機能としては実現済み）

A-3. 🟢（良性）カラー→髪色タグの明度閾値が仕様と実装で異なる

内容
仕様spec_umaru_v0.2_features.md §2-3: blonde_hair if l > 0.6 else brown_hair
実装backend/color_tags.py:hex_to_hair_tag は l > 0.45。コメントで「仕様の閾値 l>0.6 だと #FFD700（金, l≒0.5）が brown_hair になり、仕様 3-1 の TDD 例（#FFD700 → blonde_hair）と矛盾するため 0.45 に調整」と明記
種別仕様内の自己矛盾を実装側が解消（実装が正）
推奨spec_umaru_v0.2_features.md §2-3 の閾値を 0.45 に訂正。実装変更は不要

A-4. 🟢 機能②ビルダーのタグ例が仕様と実装で一部相違

内容
仕様spec_umaru_v0.2_features.md §2-2: 目「アーモンド→almond_eyes」「大きな目→big_eyes」、表情「普通→:>」、身長「高め→tall」
実装characterBuilder.ts: 目の形は tsurime/tareme/jitome/half-closed_eyes/wide-eyed（almond_eyes/big_eyes なし）、身長「高め」は tall_female、「普通」表情は OMIT。コメントに「同梱辞書の高頻度タグ（実在タグ）から採用」と明記
種別仕様は「選択肢例」、実装は辞書実タグ準拠（意図的調整）
推奨軽微。仕様の「（例）」表記で許容範囲。気になるなら実タグへ追記

A-5. 🟡 「ハートビート 30 秒途絶で FastAPI 自爆」の記述が実装と食い違う

内容
仕様Umaru仕様書_完全版.md 改訂サマリ「親 PID 監視 + ハートビート 30 秒超過で FastAPI 自動終了」、§4.2「親 PID 消滅または heartbeat 30 秒以上途絶で os._exit(0)」「ParentMonitorThread（heartbeat 30 秒超過で自動終了）」
実装backend/security.py:parent_watch_decision は親 PID の死活のみで判定。if not pid_alive: return "親プロセスが終了しました"。ハートビート切れ単独では停止しない。コメントに「ハートビート切れ単独で自爆していたのが起動ハング/生成タイムアウトの原因だった」と明記。HEARTBEAT_TIMEOUT_SECONDS=90 は保険値で実判定に未使用
種別完全版仕様書（2026-05-26）が、その後のバグ修正を反映していない（実装が正）
推奨Umaru仕様書_完全版.md §4.2 を「親 PID 死活で判定、HB 切れ単独では停止しない」に訂正。この点は実装準拠仕様書 §2.2 では既に正しく記述済み

A-6. 🟢 お祈りの「最終生成（決勝の新規生成）」が status 遷移のみ

内容
仕様UX_FLOW.md §8「グループ勝者を確定 → 最終候補生成 → 最終勝者を選択」、API_SPEC.md POST /api/prayer-sessions/{id}/final「最終候補生成」
実装workflows.py:generate_final は prayer_sessions.status を selecting_final_winners に更新するのみで新規生成しない。save_winners は既存候補の rank1-3 を学習素材へ保存。実体は「決勝＝既存候補からの選抜」フロー
種別仕様の図が示す「決勝の再生成フェーズ」は未実装（選抜フローで成立）
推奨UX_FLOW.md / API_SPEC.md の「最終候補生成」を「決勝候補の選抜・確定」に文言修正

A-7. 🟢（管理済み）機能③テスト戦略の Pact / E2E / mypy strict が未実装

内容
仕様spec_umaru_v0.2_features.md §3: Contract（Pact）、E2E（tauri-driver）、mypy --strict、tsc strict 化、スナップショットテスト
実装.github/workflows/test.yml は 3 ジョブ（python/frontend/rust）のみ。Pact/tauri-driver/mypy は未導入（grep でコード無し）。ただし test.yml 冒頭コメントで「Pact 契約テスト / tauri-driver E2E / mypy —strict / tsc strict 化は将来スコープ」と明示済み。Unit/Integration・プロパティテスト（hypothesis==6.122.3 導入済、fast-check 導入済）・tsc --noEmit・カバレッジゲートは実装済み
種別部分実装（残りは意図的に将来スコープ化＝管理済み）
推奨対応不要（計画的）。spec_umaru_v0.2_features.md に「Pact/E2E/mypy は将来スコープ（test.yml 参照）」を追記すると整合

A-8. 🟡 オンボーディングの「制作環境の準備」化が未消化

内容
仕様spec/ONBOARDING_SETUP.md §4.1「画面名は『制作環境の準備』」、§4.2 初回チェックリスト、§4.3 準備カード。PHILOSOPHY_ALIGNMENT_REVIEW.md §4.2/4.3「初回導線がまだ診断画面寄り」「ホーム制作導線が薄い」
実装SetupView は GET /api/setup/status の診断項目リスト方式（workflows.py:setup_status の items[]）。画面名は navigation.ts で「初回セットアップ/未セットアップ/ステータス」を動的表示。「制作環境の準備」「初回チェックリスト」「準備カード」は未実装
種別Philosophy 整合の推奨が未消化（実害は小、UX 温度の問題）
推奨プロダクト判断。診断方式自体は ONBOARDING_SETUP §8 とも整合するため、画面名・チェックリスト導入は任意の改善余地

2. カテゴリB：仕様（中核 spec）に無いが実装されている（後付け・バイブコーディング）

いずれも 別 SPEC（end/ や docs/ 直下）や完全版仕様書 v3 では管理されているが、中核 3 文書（REQUIREMENTS.md / DESIGN.md / ARCHITECTURE.md / API_SPEC.md）への逆輸入が漏れている。「野良実装」ではなく「仕様の分散」。

B-1. 🟡 ポーズエディタ（3D OpenPose）/ ControlNet 生成

内容
中核仕様REQUIREMENTS.md の機能要件（§4.6 画像生成）に ポーズ・ControlNet の記載なし。DESIGN.md §2 のタブ一覧に「ポーズ」タブなし。ARCHITECTURE.md の IPC/サービス層にも言及なし
実装pose タブ（PoseEditorTab、three.js）、POST /api/pose/controlnet・/to-i2i、GET/POST /api/pose/controlnet/models・/download、controlnet_service.py、controlnet_models.py、AppSettings.controlnet_openpose_path
管理状況独立仕様 docs/spec_umaru_pose_editor_v1.md・docs/spec_controlnet_nf4_vram8gb_v1.md・API_SPEC.md（ControlNet 追記分）・完全版 v3 で管理。中核 REQUIREMENTS/DESIGN への統合のみ漏れ
推奨REQUIREMENTS.md §4.6 と DESIGN.md §2 に「ポーズ（構図転写）」を正式機能として追記

B-2. 🟢 成長アルバム / お祈りラボ / お守り / 言葉の整頓 / ボリューム / 雰囲気の種

内容
中核仕様REQUIREMENTS.md §4.10 のお祈りは基本 A-D のみ。これら拡張は要件本文に無し
実装全実装済み（GrowthAlbumView、PrayerView の比較テーマ、prompt-helpers.ts、favorite_seeds、各 API）
管理状況DESIGN.md §5.7/§9（将来拡張＋別 SPEC 参照）、end/SPEC_SDWebUI知見_お守りお祈りラボ成長アルバム.md、TODO.md（[x] 実装済み）、完全版 v3 §2.1（実装済み 16〜21 番）で管理
推奨対応はほぼ不要（管理済み）。REQUIREMENTS.md に 1 行追記すれば完全

B-3. 🟢 キャラクター特徴ビルダー / カラーピッカー / color-to-tag

内容
中核仕様REQUIREMENTS.md / DESIGN.md §5.4 の「つくる」に特徴パネル・カラーピッカーの記載なし
実装CharacterBuilderPanel、ColorPickerWidget、characterBuilder.ts、color_tags.py、POST /api/tags/color-to-tag、characters.builder_state（migration v7）
管理状況spec_umaru_v0.2_features.md §2（機能②）で詳細管理
推奨DESIGN.md §5.4 に特徴パネルを追記

B-4. 🟢 後付け改善群（HF/IA/v1.3 番号で管理）

機能実装出典
キャラサマリ API（HF-04）GET /api/characters/summariesAPI_SPEC 未記載
カード画像固定（HF-15）PUT/DELETE /api/characters/{id}/coverAPI_SPEC 未記載
アルバム キャラ一括再割当（v1.3）POST /api/album/reassign-characterAPI_SPEC 未記載
Prompt 雛形（IA-13）default_prompt_layersAPI_SPEC §4 に記載あり
soft delete（IA-02）characters.status='deleted'API_SPEC §4 に記載あり
実 seed 保存（IA-10）/ rank 重複解消（IA-11）prayer_candidates.seedAPI_SPEC §8 に記載あり

出典は end/SPEC_実機確認追加改善_2026-05-26.md（HF/IA 番号）。一部は API_SPEC 反映済み、一部（summaries/cover/reassign）が未記載。

B-5. 🟢（要確認）内蔵日本語タグ辞書の自動同梱

内容
中核仕様REQUIREMENTS.md §4.12「初期配布時に Danbooru 由来データを同梱しない」「外部辞書の利用には同意」。CODING_GUIDELINES §7「Danbooru 由来データ…を本体に同梱しない」
実装resources/tags/tags_ja.csv を同梱し、起動時に同意なしで自動取り込み（import_builtin_tag_dictionary、license_name="The Unlicense"）
整合コメント上は「自作 Unlicense CSV」で Danbooru 由来でないと主張。scripts/check_no_bundled_danbooru.py で非同梱を機械検査。spec_umaru_v0.2_features.md §1（機能①）で「unlicense の…日本語訳を同梱」と承認
種別方針（外部辞書は同意取り込み）と内蔵辞書（自動同梱）の住み分けは別 SPEC で承認済みだが、REQUIREMENTS.md 本文とは表面的に矛盾して見える
推奨REQUIREMENTS.md §4.12 に「自作 Unlicense 内蔵辞書は同梱可・外部辞書のみ同意必須」と区別を明記。ライセンス由来の最終確認は別途（プロジェクトの辞書ライセンス方針に依拠）

B-6. 🟡 API_SPEC.md に多数のエンドポイントが未記載

API_SPEC.md §12 が「未追従」を自認。実装にあって API_SPEC に無いもの:

  • GET /api/characters/summaries、PUT/DELETE /api/characters/{id}/cover
  • POST /api/album/reassign-character、GET /api/album/{id}/restore・/download・/open-folder
  • GET/POST/DELETE /api/favorite-seeds
  • GET /api/pose/controlnet/models・/download・/download/status
  • PATCH /api/prayer-sessions/{id}/compare-theme
  • GET/POST /api/growth-albums/*、POST /api/growth-album-steps/{id}/select-generation
  • GET /api/negative-charms、POST /api/prompt/cleanup・/estimate-volume
  • GET /api/dictionaries/entries・/count、POST /api/dictionaries/import-custom、POST /api/tags/color-to-tag
  • GET /api/legal-notices、GET /api/release/status、/api/diagnostics/inference-check

加えて GET /api/album の仕様差: API_SPEC は limit: 1-80 既定40 だが実装は limit=0 で全件取得可・上限なし（フロントは limit=0 を使用）。

推奨: 実装準拠仕様書 §11 のエンドポイント表で API_SPEC を全面更新（または OpenAPI 自動生成へ移行、TODO P1 既出）。

3. カテゴリC：ドキュメントが実装に遅れている（実装が正・文書が古い）

これらは「仕様 ⇔ 実装の乖離」だが、実装の方が新しく正しい。文書を実装へ同期するだけでよい。2026-05-25〜27 の spec/ が、2026-06-04 のリファクタ（PHASE3/4/5）を反映していないのが主因。

#文書の主張（古い）実装の現状（正）根拠
C-1 🟢TODO.md P2・REQUIREMENTS §7・ARCHITECTURE §10・CODING §3.4「src/App.tsx が巨大化、要分割」完全分割済み。App.tsx 29 行、src/features/*・src/app/* に分離PHASE5_FRONTEND_HOOKS_REFACTOR_SUMMARY_2026-06-04.md
C-2 🟢TODO.md P2「backend main.py を router 分割する」（未）分割済み。backend/routers/*、main.py 114 行PHASE3_BACKEND_ROUTER_REFACTOR_SUMMARY_2026-06-04.md
C-3 🟢TODO.md P2「backend services.py を責務別分割」（未）分割済み。backend/services/*（generation/controlnet/dictionary/training/settings/vram_queue）PHASE4_BACKEND_SERVICES_REFACTOR_SUMMARY_2026-06-04.md
C-4 🟢PHILOSOPHY_ALIGNMENT_REVIEW §4.1・IMPLEMENTATION_BASE §2・TODO P1「サイドバー左上の Umaru を削除」（未対応）削除済み。AppContent.tsx のドロワーは「メニュー」見出し＋キャラ選択から開始。Umaru は WindowTitlebar.tsx のタイトルバーのみ（ONBOARDING_SETUP §9 で許容）src/app/AppContent.tsx、src/app/WindowTitlebar.tsx
C-5 🟢TECH_DEBT_TDD_ROADMAP_2026-06-04.md の P0/P1/P2 バグ候補全消化: download 500（get_remove_exif_setting）、job terminal 統一（job_store.py）、削除済みキャラ生成拒否（get_character）、欠落モデル自動差し替え防止（useModelSelection）、sdxl_train_network.py 診断、cancel 伝播（_terminate_process）、require_row、NumberInput、ControlNet family ガード各実装ファイルで確認済み
C-6 🟢IMPLEMENTATION_BASE.md の行番号参照（App.tsx:395〜437 等）全て陳腐化（AppContent.tsx へ移動）—
C-7 🟡ARCHITECTURE.md §8 の DB スキーマmigration 3〜7 が未記載: favorite_seeds、growth_album_sessions/steps、prayer_sessions.compare_theme/compare_config、prayer_groups.variation_label/generation_overrides、prayer_candidates.seed、characters.builder_statebackend/database.py:migrate

4. カテゴリD：Philosophy / Guideline 逸脱チェック

逸脱・要注意

D-1. 🟡 ControlNet モデル DL の sha256 検証欠如（CODING §6 逸脱）

  • ガイドライン: CODING_GUIDELINES.md §6「外部ダウンロードは sha256 検証を行う」。REQUIREMENTS.md §4.14 も同旨。
  • 実装: 学習ツール DL（training_runtime.py:_install_pipeline）は manifest の sha256 を照合。一方 ControlNet モデル DL（controlnet_models.py:download_model）は sha256 照合なし（HEAD でサイズ取得のみ、レジストリ CONTROLNET_OPENPOSE_MODELS に期待 sha256 フィールドがない）。
  • 影響: ユーザー操作 DL（HuggingFace から xinsir モデル）の完全性検証が無い。MITM や破損ファイルを検知できない。
  • 推奨: CONTROLNET_OPENPOSE_MODELS に期待 sha256 を追加し、download_model 完了時に照合（training_runtime と同じ契約に揃える）。🔴 寄りの中。

D-2. 🟡 中核タブ名「この子らしさ→学習素材」「この子を覚える→この子を学習する」の改称

  • 仕様: Philosophy.md・DESIGN.md §2・REQUIREMENTS.md §4.9/4.11・UX_FLOW.md・ONBOARDING_SETUP.md が一貫して「この子らしさ」「この子を覚える」を使用。TODO.md 仕様詰めメモは**「この子らしさ／この子を覚えるの文言はプロダクトらしさの核」**と明記。
  • 実装: navigation.ts のラベルは「学習素材」「この子を学習する」。
  • 評価: 「核」とされた擬人化文言が、機能的に分かりやすい語へ変更されている。Philosophy.md「“その子らしさ”を残す」の温度感からは後退とも、初心者向けの明確化とも解釈できる。
  • 推奨: プロダクトオーナー判断事項。意図的改善なら Philosophy.md/DESIGN.md/UX_FLOW.md の文言を実装に合わせて更新（核文言の正を一本化）。意図せぬドリフトなら復旧を検討。

D-3. 🟢 TAESDXL 等の暗黙的な外部ダウンロード（Local First の軽微な緩み）

  • Philosophy: 「Local First」「クラウド依存は必要最小限」。REQUIREMENTS.md §5「大容量依存は初回または明示操作時に導入」。
  • 実装: TAESDXL 軽量 VAE（madebyollin/taesdxl）を生成時に自動 DL（enable_taesdxl 既定 ON、generation_service.py:_try_load_tiny_vae）。同様に ControlNet 使用時の軽量 VAE も。
  • 緩和要因: サイズが小さく（~9MB）、DL 失敗時は同梱フル VAE に自動フォールバック。ユーザー画像/モデルの外部送信は無い（送信禁止原則は遵守）。
  • 推奨: 軽微。オフライン前提を厳格化するなら設定で TAESDXL を明示 ON/OFF にする余地（現状も enable_taesdxl フラグはある）。

良好（遵守）— 主要原則は全て満たす

原則（出典）実装での遵守
token 認証を外さない（CODING §6）全 /api/* が require_token、WS は require_ws_token、画像 GET は query token + compare_digest
127.0.0.1 のみ bind（CODING §5）uvicorn --host 127.0.0.1、CORS は Tauri/localhost 限定
token をログ/引数/環境変数に出さない（CODING §5）stdin 一度きり伝播（lib.rs/security.py）
パストラバーサル防止（CODING §4.4）resolve_under が APP_ROOT 拘束、\x00/\ 拒否
Zip Slip 対策（CODING §4.4）training_runtime.py:_extract が絶対パス/../symlink/逸脱を拒否
shell=True 回避・subprocess は配列（CODING §6）album_open_folder・kohya 起動とも配列引数・shell=False
外部 URL は許可リスト（CODING §5）open_external_url は DraconicDragon/DominikDoom のみ
VRAM 処理は VramQueue を通す（CODING §4.5）生成・お祈り・学習とも vram_queue.task() 内で実行
エラーは日本語 message + code（CODING §4.2）全エラーが {code, message}、4 カテゴリ分類（error_classify.py）
UI 文字列は日本語（CODING §1, DESIGN §7）ラベル・ボタン・エラー・診断とも日本語、terminology.ts で creator/expert 分離
物理削除と論理削除の区別（CODING §4.3）キャラは soft delete、生成画像は物理削除
既存ユーザーデータを壊さない（CODING §10）migration は後方互換（_add_column_if_missing）、画像消失行は自己整合削除
失敗を「次に直せる状態」に（Philosophy）setup/status・inference-check・release/status・training-runtime が状態と次アクションを返す
Local First / 外部送信しない（Philosophy）ユーザー画像・モデルの外部送信なし。DL は依存・モデル取得のみ

5. 推奨アクション（優先度別）

すぐ対応すべき（実装またはセキュリティ）

  1. D-1 / 🟡→🔴寄り: ControlNet モデル DL に sha256 検証を追加（controlnet_models.py）。ガイドライン §6 の唯一の実装逸脱。

文書を実装に同期（実装は正・文書が古い）

  1. C-1〜C-7: ARCHITECTURE.md・REQUIREMENTS.md §7・CODING §3.4・TODO.md P2・PHILOSOPHY_ALIGNMENT_REVIEW §4.1・IMPLEMENTATION_BASE.md から「App.tsx/main.py/services.py 未分割」「左上 Umaru 未削除」の記述を完了済みへ更新。ARCHITECTURE §8 の DB スキーマに migration 3〜7 を追記。
  2. A-1: vram_mode を全 spec から削除し「VRAM 自動判定」に。
  3. A-5: 完全版仕様書 §4.2 の「HB 30 秒自爆」を「親 PID 死活判定」に訂正。
  4. B-6 / A-6: API_SPEC.md を実装の全エンドポイントへ更新（または OpenAPI 生成）。final の文言を「決勝選抜」に。

中核仕様への逆輸入（後付け機能の正式化）

  1. B-1 / B-2 / B-3: REQUIREMENTS.md・DESIGN.md に ポーズ/ControlNet・成長アルバム・お祈りラボ・特徴ビルダーを正式機能として追記。
  2. B-5: REQUIREMENTS.md §4.12 に内蔵辞書（自作 Unlicense・同梱可）と外部辞書（同意必須）の区別を明記。

プロダクト判断

  1. D-2: 中核タブ名「学習素材／この子を学習する」を正とするか「この子らしさ／この子を覚える」へ戻すかを決定し、Philosophy/DESIGN/UX_FLOW の文言を一本化。
  2. A-8: オンボーディングを「制作環境の準備」温度へ寄せるか（Philosophy 整合の任意改善）。

軽微・任意

  1. A-2 / A-3 / A-4 / A-7: spec_umaru_v0.2_features.md を実装に合わせて訂正（API 方式・閾値 0.45・実タグ・将来スコープ注記）。

付録: 参照した仕様書と実装の対応

仕様書最終更新実装との整合度
spec/Philosophy.md2026-05-25思想は遵守。タブ名（D-2）のみ要確認
spec/PHILOSOPHY_ALIGNMENT_REVIEW.md2026-05-25指摘 §4.1（左上 Umaru）は対応済み（文書未更新）
spec/REQUIREMENTS.md2026-05-27vram_mode（A-1）、後付け機能未反映（B群）、§7 が古い（C）
spec/ARCHITECTURE.md2026-05-25DB スキーマ・分割状況が古い（C-2/3/7）
spec/API_SPEC.md2026-05-25vram_mode 誤記（A-1）、大量未記載（B-6）。§12 で自認
spec/DESIGN.md2026-05-25タブ名・VRAM・ポーズ未反映
spec/CODING_GUIDELINES.md2026-05-25実装はほぼ遵守。§3.4 のみ古い（C-1）
spec/UX_FLOW.md / ONBOARDING_SETUP.md / IMPLEMENTATION_BASE.md2026-05-25タブ名・オンボ温度・行番号が古い
Umaru仕様書_完全版.md2026-05-26 (v3)最も実装に忠実。§4.2 の HB 自爆記述（A-5）のみ古い
spec_umaru_v0.2_features.md2026-06-01機能①②③の出典。API 方式（A-2）・閾値（A-3）・テスト範囲（A-7）が実装と差
spec_umaru_pose_editor_v1.md / spec_controlnet_nf4_vram8gb_v1.md—ポーズ/ControlNet の独立仕様（B-1 の管理元）
TECH_DEBT_TDD_ROADMAP_2026-06-04.md / PHASE3-5_*_2026-06-04.md2026-06-04実装の現状に最も近い（C-1〜C-5 の根拠）

注: 本監査は静的なコード/文書読解に基づく。実モデル推論・実学習・実 DL の動的挙動は含まない（CODING §8 の通り、これらは実機検証が別途必要）。