Files

03_データ仕様書.md — 全面書き直し（M:N関係、中山間17列モデル、面積単位、PDF出力仕様）
04_画面設計書.md — 全面書き直し（Navbar追加、圃場管理/新規作成画面追加、インライン編集方式、PDF帳票フォーマット仕様 E-1）
01_プロダクトビジョン.md — CSV→PDF、M:1→M:N
05_実装優先順位.md — CSV→PDF、Django 5.0→5.2、モーダル→インライン、init_crops削除
00_Gemini向け統合指示書.md — CSV→PDF、Django 5.2、M:N関係、中山間17列モデル、init_crops削除、IsAuthenticated
CLAUDE.md — 既知の課題一覧、次タスク優先順追加、中山間モデル拡張、差異レポートリンク
コード修正（4件）
D-1: reports/views.py — plan.crop / plan.variety の null チェック追加
D-2: init_crops.py を削除
D-3: settings.py — LANGUAGE_CODE/TIME_ZONE の二重定義を解消
D-4: settings.py — AllowAny → IsAuthenticated に変更
次のタスクは CLAUDE.md の優先順リストに従うと A-8（圃場詳細に共済/中山間情報表示）です。続けますか？

2026-02-17 10:56:09 +09:00

16 KiB

Raw Blame History

ドキュメント 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 ではモーダルウィンドウでの編集を想定

対応方針:

実装に合わせてドキュメント更新 / モーダルに変更

実装: 左サイドに常時表示のナビ（作付け計画、圃場管理、帳票出力、データ取込、ログアウト）
ドキュメント: 画面設計書ではヘッダー内にハンバーガーメニュー（スマホ）を想定

対応方針:

ドキュメントに追記する / 現状維持

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帳票フォーマットの再設計

現状の問題:

タイトルに中国語「申请书」が混入
セクション分け形式（表形式でない）
@page 指定なし（A4サイズ・余白未設定）
面積が ha 表示

対応方針: 表形式（1行1区画）で、紙の書式に合わせる

E-1a: 水稲共済細目書 PDF

フォーマット: A4縦、表形式、31行

#	列名	データ元	備考
1	漢字地名	OfficialKyosaiField.kanji_name	例: 四万十町笹ヶ谷 374-1
2	耕地-分筆	k_num + "-" + s_num	例: 2-1
3	本地面積 (m2)	OfficialKyosaiField.area	内部 m2 で保存
4	作付品目	Plan.crop.name	システムの作付け計画から
5	品種	Plan.variety.name	〃
6	圃場名称	Field.name	吉田農地台帳の名称。複数圃場の場合はカンマ区切り

補足:

1つの共済区画に複数の実圃場が紐づく場合 → 作物・品種・圃場名をカンマ区切りで列挙
作付け未設定の場合 → 「未設定」と表示
ヘッダー: 「水稲共済細目書（YYYY年度）」
ページ番号あり

E-1b: 中山間交付金 PDF

フォーマット: A4横（列が多いため）、表形式、71行

#	列名	データ元	備考
1	所在地	大字+字+地番+枝番連結	例: 口神ノ川壱町切 1694
2	植栽面積	OfficialChusankanField.planting_area	ODS「植栽面積」列
3	作付け品目(元)	OfficialChusankanField.original_crop	ODS「作付け品目」列（役場記入）
4	協定管理者	OfficialChusankanField.manager	ODS「協定管理者」列
5	所有者	OfficialChusankanField.owner	ODS「所有者」列
6	作物	Plan.crop.name	システムの作付け計画から
7	品種	Plan.variety.name	〃
8	圃場名称	Field.name	吉田農地台帳の名称

補足:

1つの中山間区画に複数の実圃場が紐づく場合 → 作物・品種・圃場名をカンマ区切り
ヘッダー: 「中山間地域等直接支払交付金（YYYY年度）」
ページ番号あり

E-1c: OfficialChusankanField モデル拡張

現在のモデルに存在しない列を追加する（ODSの17列全部を保存）:

追加フィールド	ODS列名	型
chusankan_flag	中山間	CharField (〇など)
branch_num	枝番	CharField (-, 1, イ, ロ等)
land_type	地目	CharField (田, 畑等)
planting_area	植栽面積	IntegerField (m2)
original_crop	作付け品目	CharField (役場記入)
manager	協定管理者	CharField
owner	所有者	CharField (nullable)
slope	傾斜度	CharField (1/20等)
base_amount	基本金額	IntegerField
steep_slope_addition	超急傾斜加算額	DecimalField
smart_agri_addition	スマート農業加算額	DecimalField

※ 既存フィールド: c_id, oaza, aza, chiban, area(農地面積), payment_amount(交付金額)

対応の進め方

上記すべての項目に対応方針を記入後、以下の順序で作業を進めることを推奨します:

不具合修正 (D-1, D-2, D-3) — すぐに直せるもの
セキュリティ (C-8 / D-4) — 運用方針の確認
データの食い違い修正 (C-1〜C-7) — ドキュメントか実装の修正
未実装機能の追加 (A-1〜A-8) — 優先度を決めて順次対応
ドキュメントへの追記 (B-1〜B-5) — 実装済み機能の記録

16 KiB Raw Blame History Unescape Escape

ドキュメント vs 実装 差異レポート

A. ドキュメントに書かれているが実装されていないもの

A-1: ダッシュボード画面

A-2: チェックボックスによる一括操作

A-3: 前年度コピー機能（フロントエンド）

A-4: 品種のインライン追加

A-5: PDFプレビュー機能

A-6: エクスポート機能（CSV/ZIP）

A-7: 作付け計画画面の検索・フィルタ

A-8: 圃場詳細画面の共済/中山間情報表示

B. 実装されているがドキュメントに記載がないもの

B-1: グループ機能

B-2: 圃場管理画面（/fields）

B-3: 圃場新規作成画面（/fields/new）

B-4: インライン編集方式（作付け計画）

B-5: Navbar（ナビゲーションバー）

C. ドキュメントと実装で食い違っているもの

C-1: Field と共済/中山間の関係（M:1 vs M:N）

C-2: 共済マスタのフィールド型

C-3: 中山間マスタのフィールド型

C-4: 面積フィールドの単位

C-5: 作物マスタの初期データ

C-6: 申請書の出力形式（CSV vs PDF）

C-7: Django バージョン

C-8: DEFAULT_PERMISSION_CLASSES

D. 潜在的な不具合

D-1: PDF生成時の variety/crop が null でクラッシュ

D-2: init_crops.py の不正データ

D-3: settings.py の二重定義

D-4: AllowAny で全API公開

セキュリティ必須

E. 追加で修正の要望

E-1: PDF帳票フォーマットの再設計

E-1a: 水稲共済細目書 PDF

E-1b: 中山間交付金 PDF

E-1c: OfficialChusankanField モデル拡張

対応の進め方

16 KiB

Raw Blame History

ドキュメント vs 実装差異レポート