# ドキュメント vs 実装 差異レポート > **作成日**: 2026-02-16 > **目的**: ドキュメントと実装の差異を洗い出し、対応方針を決定する > > 各項目の「対応方針」欄に指示を記入してください。 > 記入例: 「実装する」「ドキュメント削除」「Phase 2に延期」「現状維持」など --- ## A. ドキュメントに書かれているが実装されていないもの ### A-1: ダッシュボード画面 - **ドキュメント**: 画面設計書 画面2 - 概要サマリー（全圃場数/作付け済み/未割当）、クイックアクセスボタン、最近の変更履歴 - **実装**: `/` はトークンの有無で `/allocation` か `/login` にリダイレクトするだけ - **影響**: なくても作付け計画画面から全機能にアクセス可能。Navbarで各画面に遷移できる **対応方針**: ``` 将来、機能追加する時には、ここにボタンが増えていく形式になっていくはずなので必要です ``` --- ### A-2: チェックボックスによる一括操作 - **ドキュメント**: 画面設計書 画面3 - 各行にチェックボックス、複数選択→一括割当 - **実装**: チェックボックスなし、一括操作UI なし - **補足**: Backend には `POST /api/plans/bulk_update/` APIが既に存在する **対応方針**: ``` 利便性向上の為必要です。 ``` --- ### A-3: 前年度コピー機能（フロントエンド） - **ドキュメント**: ユーザーストーリー P1-5、画面設計書 画面3 - [前年度をコピー]ボタン - **実装**: Backend API (`POST /api/plans/copy_from_previous_year/`) は存在するが、Frontend にボタンがない - **影響**: 毎年手動で39筆を設定する必要がある **対応方針**: ``` 必要な項目です。 ``` --- ### A-4: 品種のインライン追加 - **ドキュメント**: 画面設計書 画面4 - [+ 新しい品種を追加]ボタン、その場で入力して即座にマスタ登録 - **実装**: 既存品種からの選択のみ。新品種の追加はDjango管理画面からのみ可能 - **影響**: 運用中に新品種が出てきた場合、管理画面を開く必要がある **対応方針**: ``` 追加出来る事は必要です。削除も出来ないと間違って追加した時に不便です ``` --- ### A-5: PDFプレビュー機能 - **ドキュメント**: 画面設計書 画面6 - [プレビュー]ボタンで新タブにPDF表示 - **実装**: ダウンロードボタンのみ（プレビューなし） - **影響**: ダウンロード前に内容確認ができない **対応方針**: ``` プレビューしてから保存、もしくは、印刷出来るようにしたいです。 ``` --- ### A-6: エクスポート機能（CSV/ZIP） - **ドキュメント**: 画面設計書 画面7 - 全圃場データCSV、作付け計画CSV、全データZIPバックアップ - **実装**: 未実装 - **影響**: バックアップ手段がない（DBダンプのみ） **対応方針**: ``` 必要です。近い将来サーバーに移行するので、その時に、このローカル環境で設定したデータを移動できるようにしたいです。 ``` --- ### A-7: 作付け計画画面の検索・フィルタ - **ドキュメント**: 画面設計書 画面3 - 圃場名・住所で部分一致検索、作物で絞り込み、未割当のみトグル - **実装**: 並び替え（カスタム順/グループ順/作付け順）のみ。テキスト検索なし - **影響**: 39筆なので目視でも探せるが、検索があると便利 **対応方針**: ``` 優先度は低いですが必要です。 ``` --- ### A-8: 圃場詳細画面の共済/中山間情報表示 - **ドキュメント**: 画面設計書 画面5 - 共済情報（耕地番号/分筆）、中山間情報（ID）を表示 - **実装**: 基本情報（名称、住所、面積、所有者、グループ）の編集のみ - **影響**: 圃場と申請区画の対応がUI上で確認できない **対応方針**: ``` これ絶対に必要！ ``` --- ## B. 実装されているがドキュメントに記載がないもの ### B-1: グループ機能 - **実装**: `group_name`（エリア分け）、`display_order`（表示順）フィールド。圃場一覧・作付け計画で並び替え可能 - **ドキュメント**: CLAUDE.md にのみ記載。データ仕様書・画面設計書には未記載 - **経緯**: マイグレーション0004で後から追加された機能 **対応方針**: ``` ドキュメントに追記する / 現状維持 ``` --- ### B-2: 圃場管理画面（/fields） - **実装**: 圃場一覧（テーブル形式）、グループ編集、表示順変更（上下ボタン）、削除機能 - **ドキュメント**: 画面設計書に独立した画面としての記載なし（画面5は「圃場詳細」のみ） **対応方針**: ``` ドキュメントに追記する / 現状維持 ``` --- ### B-3: 圃場新規作成画面（/fields/new） - **実装**: 手動で圃場を1件ずつ作成可能 - **ドキュメント**: インポート（ODS/Excel）のみ想定。手動作成の記載なし **対応方針**: ``` ドキュメントに追記する / 現状維持 ``` --- ### B-4: インライン編集方式（作付け計画） - **実装**: テーブル内で直接作物・品種・備考を編集（即時保存） - **ドキュメント**: 画面設計書 画面4 ではモーダルウィンドウでの編集を想定 **対応方針**: ``` 実装に合わせてドキュメント更新 / モーダルに変更 ``` --- ### B-5: Navbar（ナビゲーションバー） - **実装**: 左サイドに常時表示のナビ（作付け計画、圃場管理、帳票出力、データ取込、ログアウト） - **ドキュメント**: 画面設計書ではヘッダー内にハンバーガーメニュー（スマホ）を想定 **対応方針**: ``` ドキュメントに追記する / 現状維持 ``` --- ## C. ドキュメントと実装で食い違っているもの ### C-1: Field と共済/中山間の関係（M:1 vs M:N） - **ドキュメント（データ仕様書）**: M:1（ForeignKey）- 「複数の実圃場が1つの共済区画に対応」 - **実装**: M:N（ManyToManyField）- 1つの実圃場が複数の申請区画に紐づくケースにも対応 - **CLAUDE.md**: M:N に更新済み - **影響**: データ仕様書のER図、紐付けロジックのコード例が古い **対応方針**: ``` データ仕様書を M:N に更新 ``` --- ### C-2: 共済マスタのフィールド型 - **ドキュメント**: `k_num` = IntegerField, `s_num` = IntegerField、(k_num, s_num)のペアで一意 - **実装**: `k_num` = CharField(unique=True), `s_num` = CharField(null許容) - **影響**: 紐付けロジックの仕様が異なる。k_num 単独で一意になっている **対応方針**: ``` (k_num, s_num) ペアで一意が正しいです ``` --- ### C-3: 中山間マスタのフィールド型 - **ドキュメント**: `c_id` = IntegerField, `chiban` = IntegerField - **実装**: `c_id` = CharField, `chiban` = CharField - **影響**: 数値でないデータが入る可能性（実運用で問題ないか要確認） **対応方針**: ``` 数値でないデータが入る可能性あります。イとかロとかがあります ``` --- ### C-4: 面積フィールドの単位 - **ドキュメント**: 共済マスタ `area` = m2 (FloatField)、中山間マスタ `area` = m2 (IntegerField) - **実装**: 両方とも `area` = DecimalField(ha表記) - **影響**: PDF出力時の面積表示が m2 ではなく ha になっている可能性 **対応方針**: ``` 面積の内部表現がm2に統一。表示上は（反=10a）に統一してください ``` --- ### C-5: 作物マスタの初期データ - **ドキュメント**: 米、トウモロコシ、エンドウ、野菜、その他 - **実装（init_crops.py）**: 水稲、大豆、小麦、そば、とうきび - **品種も全く異なる**: - ドキュメント: にこまる、たちはるか、たちはるか（特栽）、久留米豊、完全休耕 等 - 実装: コシヒカリ、ひとめぼれ、あきたこまち、つや姫、タマホマレ 等 - **影響**: ドキュメントはユーザー固有のデータだが、init_crops.py は汎用的なサンプルになっている **対応方針**: ``` 初期データはいらないです消して入れなおさなきゃいけない事になっている どうしても必要なら、今登録されているデータに準拠してください ``` --- ### C-6: 申請書の出力形式（CSV vs PDF） - **ドキュメント（複数箇所）**: - 01_プロダクトビジョン.md: 「申請書（水稲共済・中山間）のCSV出力」 - 05_実装優先順位.md: 「水稲共済細目書のCSV出力」「中山間交付金のCSV出力」 - 02_ユーザーストーリー.md: 「PDFでダウンロード」 - 04_画面設計書.md: 「PDFダウンロード」 - **実装**: PDF出力（WeasyPrint） - **影響**: ドキュメント内で CSV と PDF が混在している **対応方針**: ``` 全ドキュメントをPDFに統一 ``` --- ### C-7: Django バージョン - **ドキュメント（統合指示書）**: Django 5.0 - **実装**: Django 5.2.11 **対応方針**: ``` ドキュメントを 5.2 に更新 ``` --- ### C-8: DEFAULT_PERMISSION_CLASSES - **ドキュメント（統合指示書）**: `IsAuthenticated`（認証必須） - **実装**: `AllowAny`（認証なしでアクセス可能） - **影響**: 現状では誰でもAPIにアクセスできる状態。開発中は便利だが本番では危険 **対応方針**: ``` IsAuthenticated に変更 後で変えると、漏れが怖いです ``` --- ## D. 潜在的な不具合 ### D-1: PDF生成時の variety/crop が null でクラッシュ - **該当コード**: `backend/apps/reports/views.py` 20行目、24行目 - **問題**: `plan.crop.name` / `plan.variety.name` を直接参照。variety は nullable (blank=True, null=True)、crop も nullable - **再現条件**: 品種を設定せずに作物だけ設定した圃場があるとPDF生成時にエラー - **修正案**: `plan.variety.name if plan.variety else ''` のように null チェックを追加 **対応方針**: ``` 修正する ``` --- ### D-2: init_crops.py の不正データ - **該当コード**: `backend/apps/plans/management/commands/init_crops.py` 12行目、26行目 - **問題**: - `'ミヤギром'` — 日本語 + キリル文字（ロシア語の「ром」が混入）。正しくは「ミヤギシロメ」等？ - `'ゴールdent'` — 日本語 + 英語混在。正しくは「ゴールデント」等？ - **影響**: マスタデータの品種名が不正。品種選択UIで表示される **対応方針**: ``` 削除する — init_crops.py 自体を消す。作物・品種は管理画面やUIから登録する運用にする ``` --- ### D-3: settings.py の二重定義 - **該当コード**: `backend/keinasystem/settings.py` - 113行目: `LANGUAGE_CODE = 'en-us'`、115行目: `TIME_ZONE = 'UTC'` - 152行目: `LANGUAGE_CODE = 'ja'`、154行目: `TIME_ZONE = 'Asia/Tokyo'` - **問題**: 後の定義で上書きされるので動作に影響はないが、コードが紛らわしい - **修正案**: 前の定義を削除し、後の定義のみ残す **対応方針**: ``` `LANGUAGE_CODE = 'ja'`、154行目: `TIME_ZONE = 'Asia/Tokyo'` ``` --- ### D-4: AllowAny で全API公開 - **該当コード**: `backend/keinasystem/settings.py` 137行目 - **問題**: DEFAULT_PERMISSION_CLASSES が AllowAny。認証トークンなしでもすべてのAPI（圃場データ、作付け計画、インポート、PDF生成）にアクセス可能 - **影響**: ローカル開発のみなら問題ないが、外部公開時にはデータ漏洩リスク - **備考**: C-8 と同じ内容。セキュリティ面での対応 **対応方針**: ``` ``` セキュリティ必須 --- ## E.追加で修正の要望 ### E-1.PDF出力される帳票のフォーマットが気に入らないです。 ここ未定義なので、まずは仕様を決めましょう ## 対応の進め方 上記すべての項目に対応方針を記入後、以下の順序で作業を進めることを推奨します: 1. **不具合修正** (D-1, D-2, D-3) — すぐに直せるもの 2. **セキュリティ** (C-8 / D-4) — 運用方針の確認 3. **データの食い違い修正** (C-1〜C-7) — ドキュメントか実装の修正 4. **未実装機能の追加** (A-1〜A-8) — 優先度を決めて順次対応 5. **ドキュメントへの追記** (B-1〜B-5) — 実装済み機能の記録