keinasystem/CLAUDE.md

Keina System - Claude 向けガイド

最終更新: 2026-03-16 現在のフェーズ: Phase 1 (MVP) - 気象データ基盤を追加

📌 このファイルの目的

このファイルは、Claude が新しいセッションを開始する際に最初に読むべきドキュメントです。 プロジェクト全体の構造、重要な設計判断、現在の状態を把握するための情報を集約しています。

⚠️ Claude への重要な指示

このファイルは、セッションごとに必ず最初に読んでください。

さらに、以下のルールを厳守してください：

📝 更新義務

ドキュメントドリブンの徹底

• ✅ 仕様に変更がある時は、まず関連するドキュメントから更新する事。

機能追加・変更時は、必ずこのファイルを更新すること。

• ✅ 新機能実装時 → 「実装状況」セクションを更新
• ✅ データモデル変更時 → 「データモデル概要」を更新
• ✅ 重要な設計判断時 → 「重要な制約・ルール」に追記
• ✅ 新作業パターン確立時 → 「よくある作業パターン」に追加
• ✅ 問題解決時 → 「トラブルシューティング」に追加
• ✅ 更新時は必ず「更新履歴」セクションに記録

更新を忘れると、次のセッションで情報が失われます。これは最優先事項です。

---

🎯 プロジェクト概要（30秒で理解）

何を作っているか: 農業生産者向けの作付け計画管理システム。圃場管理、作付け計画、申請書自動生成を行う。

ユーザー: 65歳の農家（元プログラマー）、シングルユーザー、39筆の圃場を管理

技術スタック:

• Backend: Django 5.2 + DRF + PostGIS
• Frontend: Next.js 14 (App Router) + TypeScript + Tailwind CSS
• Database: PostgreSQL 16 + PostGIS 3.4

開発方針: シンプルさ最優先、段階的な機能追加、過度な複雑化を避ける

---

📂 プロジェクト構造

keinasystem_t02/
├── CLAUDE.md              # このファイル（Claude向けガイド）
├── .cursor/
│   └── rules/
│       └── 30_Cursorガイド.md  # Cursor専用ガイド
├── document/              # 詳細設計書（人間向け）
│   ├── 00_Gemini向け統合指示書.md  # 全体像の詳細
│   ├── 01_プロダクトビジョン.md
│   ├── 02_ユーザーストーリー.md
│   ├── 03_データ仕様書.md
│   ├── 04_画面設計書.md
│   └── 05_実装優先順位.md
├── backend/
│   ├── keinasystem/        # Django設定
│   │   ├── settings.py     # 重要: CORS, JWT, DB設定
│   │   └── urls.py         # ルートURL設定
│   └── apps/
│       ├── fields/         # 圃場管理アプリ
│       │   ├── models.py   # Field, OfficialKyosaiField, OfficialChusankanField
│       │   ├── views.py    # インポート機能、CRUD API
│       │   └── urls.py
│       ├── plans/          # 作付け計画アプリ
│       │   ├── models.py   # Plan, Crop(+base_temp), Variety
│       │   └── views.py    # 作付け計画API、集計API
│       ├── weather/        # 気象データアプリ
│       │   ├── models.py   # WeatherRecord (1日1行)
│       │   ├── views.py    # sync(APIキー), records, summary, gdd, similarity
│       │   ├── urls.py
│       │   └── management/commands/fetch_weather.py  # 初回一括取得・差分取得
│       ├── reports/        # 申請書生成アプリ
│       │   ├── views.py    # PDF生成API
│       │   └── templates/  # PDF用HTMLテンプレート
│       ├── fertilizer/     # 施肥計画・散布実績アプリ
│       │   ├── models.py   # Fertilizer, FertilizationPlan, FertilizationEntry, SpreadingSession, SpreadingSessionItem
│       │   ├── services.py # actual_bags再集計、在庫USE連携
│       │   └── views.py    # 施肥計画/散布実績/候補API
│       └── workrecords/    # 作業記録索引アプリ
│           ├── models.py   # WorkRecord
│           └── services.py # sync_delivery_work_record, sync_spreading_work_record
└── frontend/
    └── src/app/
        ├── allocation/     # 作付け計画編集画面（メイン）
        ├── fields/         # 圃場一覧・詳細
        ├── reports/        # 申請書ダウンロード
        ├── import/         # データ取込画面
        ├── mail/
        │   ├── feedback/[token]/  # フィードバックページ（認証不要）
        │   ├── history/           # メール処理履歴
        │   └── rules/             # 送信者ルール管理
        ├── fertilizer/     # 施肥計画（一覧・編集・肥料マスタ）
        │   └── spreading/  # 散布実績画面
        ├── distribution/   # 運搬計画（一覧・編集）
        ├── weather/        # 気象データ画面（年別集計・期間指定・グラフ）
        └── settings/
            └── password/          # パスワード変更

---

🗄️ データモデル概要

コアエンティティ

Field (実圃場)
├── 39筆の実際の農地
├── area_tan (反), area_m2 (m2) の2つの面積フィールド
├── group_name, display_order (グループ分け・表示順)
└── ManyToMany関係
    ├── kyosai_fields (共済マスタ、M:N)
    └── chusankan_fields (中山間マスタ、M:N)

OfficialKyosaiField (共済マスタ)
└── 31区画（水稲共済細目書用）

OfficialChusankanField (中山間マスタ)
├── 71区画（中山間地域等直接支払交付金用）
└── 17フィールド: c_id, chusankan_flag, oaza, aza, chiban,
    branch_num, land_type, area, planting_area,
    original_crop, manager, owner, slope,
    base_amount, steep_slope_addition, smart_agri_addition,
    payment_amount

Plan (作付け計画)
├── field (FK to Field)
├── year (年度)
├── crop (FK to Crop)
├── variety (FK to Variety, nullable)
└── unique_together = ['field', 'year']

Crop (作物マスタ)
├── name（米、トウモロコシ、エンドウ、野菜、その他）
└── base_temp (有効積算温度 基準温度℃、default=0.0) ← 2026-02-28 追加

Variety (品種マスタ)
├── crop (FK to Crop)
├── name (品種名)
└── unique_together = ['crop', 'name']

MailSender (送信者ルール)
├── email (EmailField, nullable)
├── domain (CharField, nullable)
├── rule ('never_notify' | 'always_notify')
└── ConstraintCheck: email/domain どちらか一方のみ

MailEmail (受信メール記録)
├── account (gmail / gmail_service / hotmail / xserver1〜xserver6、旧データxserver)
├── message_id (unique)
├── sender_email, sender_domain
├── subject, body_preview
├── received_at, llm_verdict (important/not_important)
├── notified_at (LINE通知日時、nullable)
└── feedback (important/not_important/never_notify/always_notify, nullable)

MailNotificationToken (フィードバックURL用トークン)
├── email (OneToOne FK to MailEmail)
└── token (UUID, unique)

WeatherRecord (日次気象記録)
├── date (DateField, unique)
├── temp_mean, temp_max, temp_min (気温℃)
├── sunshine_h (日照時間h)
├── precip_mm (降水量mm)
├── wind_max (最大風速m/s)
└── pressure_min (最低気圧hPa)
※ 観測地点: 窪川 (lat=33.213, lon=133.133)、データソース: Open-Meteo archive API
※ 2016-01-01 から蓄積（初回は fetch_weather --full で一括投入）

Fertilizer (肥料マスタ)
├── name（肥料名、必須・unique）
├── maker（メーカー、任意）
├── capacity_kg（1袋重量kg、任意）
├── nitrogen_pct / phosphorus_pct / potassium_pct（成分%、任意）
└── notes（備考、任意）

FertilizationPlan (施肥計画)
├── name（計画名）
├── year（年度）
└── variety (FK to plans.Variety)

FertilizationEntry (施肥エントリ・中間テーブル)
├── plan (FK to FertilizationPlan, CASCADE)
├── field (FK to fields.Field, CASCADE)
├── fertilizer (FK to Fertilizer, PROTECT) ← 使用中の肥料は削除不可
├── bags（袋数、Decimal・計画値）
├── actual_bags（散布実績集計値、Decimal(10,4)、nullable）
└── unique_together = ['plan', 'field', 'fertilizer']

SpreadingSession (散布実績セッション) ← 2026-03-17 追加
├── year（年度）
├── date（散布日）
├── name（セッション名、必須）
├── notes（備考）
└── year+date の一意制約なし（同日複数記録可能）

SpreadingSessionItem (散布実績明細)
├── session (FK to SpreadingSession, CASCADE)
├── field (FK to fields.Field, PROTECT)
├── fertilizer (FK to Fertilizer, PROTECT)
├── actual_bags（実散布袋数、Decimal(10,4)）
├── planned_bags_snapshot / delivered_bags_snapshot（表示時点のスナップショット）
└── unique_together = ['session', 'field', 'fertilizer']

WorkRecord (作業記録索引) ← apps/workrecords/ 別アプリ、2026-03-17 追加
├── work_date（作業日）
├── work_type（fertilizer_delivery / fertilizer_spreading）
├── title（一覧表示名）
├── year（年度）
├── delivery_trip (OneToOne FK to DeliveryTrip, nullable)
├── spreading_session (OneToOne FK to SpreadingSession, nullable)
└── 詳細は各業務テーブル側に持つ（索引として機能）

DeliveryPlan (運搬計画) ← 旧 DistributionPlan を置き換え（2026-03-16 再設計）
├── year（年度）← 施肥計画へのFK廃止、年度ベースで全施肥計画を横断
├── name（計画名）
├── groups → DeliveryGroup
└── trips → DeliveryTrip

DeliveryGroup (配送先グループ)
├── delivery_plan (FK to DeliveryPlan, CASCADE)
├── name（グループ名）
├── order（表示順）
└── unique_together = ['delivery_plan', 'name']

DeliveryGroupField (グループ圃場割り当て)
├── delivery_plan (FK to DeliveryPlan, CASCADE) ← 一意制約用
├── group (FK to DeliveryGroup, CASCADE)
├── field (FK to fields.Field, PROTECT)
└── unique_together = ['delivery_plan', 'field'] ← 1圃場=1グループ/1計画

DeliveryTrip (運搬回)
├── delivery_plan (FK to DeliveryPlan, CASCADE)
├── order（何回目）
├── name（任意の名前）
├── date（運搬日、nullable、デフォルト=1回目の日付）
└── items → DeliveryTripItem

DeliveryTripItem (運搬明細)
├── trip (FK to DeliveryTrip, CASCADE)
├── field (FK to fields.Field, PROTECT)
├── fertilizer (FK to Fertilizer, PROTECT)
├── bags（袋数、Decimal）
└── unique_together = ['trip', 'field', 'fertilizer']

重要な設計判断

1. M:N関係に変更: 当初はM:1だったが、実運用で「1つの実圃場が複数の申請区画に紐づく」ケースが判明し、ManyToManyに変更（マイグレーション0003で実施）

2. 面積単位の二重管理:

   • DB内部は area_m2 (整数) で保存
   • 表示用に area_tan (反, Decimal) も保持
   • 理由: 申請書ではm2、農家の感覚では反

3. 品種は全作物で統一:

   • 「作付けしない」も「その他」作物の品種として扱う
   • UI操作を統一するため

4. グループ機能:

   • group_name (エリアや用途によるグループ分け)
   • display_order (リスト表示時の順序)
   • マイグレーション0004で追加

5. 年度管理の設計方針（⚠️ Phase 2 で必ず参照）:

   • 作付け計画: 年度セレクタで独立して来年度も選べる。選んだ年度はlocalStorageに保存して維持
   • 過去年度: 「参照モード」として視覚的に区別（背景色・バナー）
   • Phase 2 の栽培管理・販売管理: グローバル作業年度を導入し、基本は今年度に従う
   • 栽培記録・作業日誌: 日付中心設計、年度は日付から自動算出
   • 参考: ソリマチ農業簿記の年度管理方式（明示的に年度を選択、変更するまで固定）

---

🔑 重要な制約・ルール

絶対に守るべきこと

1. データの整合性

   • 年度 + 圃場の組み合わせは1つの Plan のみ (unique_together)
   • 作物 + 品種名の組み合わせは一意 (unique_together)

2. 面積の扱い

   • 表示: 反 (tan)
   • 計算・保存: m2
   • 変換: 1反 = 1000m2 (正確には991.736m2だが、実運用では1000で統一)

3. M:N関係の重要性

   • Field と OfficialKyosaiField は M:N
   • Field と OfficialChusankanField は M:N
   • 決して FK (1:N) に戻さない

4. シンプルさ優先

   • 過度な抽象化を避ける
   • 3回同じコードを書くまでは抽象化しない
   • ユーザーは1人、パフォーマンス最適化は後回し

コーディング規約

• Backend: Django のベストプラクティスに従う
• Frontend: TypeScript strict mode、ESLint に従う
• API: REST原則、エンドポイントは複数形 (/api/fields/, /api/plans/)
• 命名: 日本語のフィールドは verbose_name で対応

---

📍 現在の実装状況

✅ 実装済み（Phase 1 - MVP）

1. 認証: JWT認証（アクセストークン24h、リフレッシュトークン7日）
2. 圃場管理:
   • CRUD API (/api/fields/)
   • ODS/Excelインポート (/api/fields/import/)
   • グループ機能（マイグレーション0004）
3. 作付け計画:
   • 年度別の作付け計画 CRUD (/api/plans/?year=2025)
   • 前年度コピー機能 (/api/plans/copy_from_previous_year/)
   • 一括更新 (/api/plans/bulk_update/)
   • 集計API (/api/plans/summary/?year=2025)
4. 申請書生成:
   • 水稲共済細目書 PDF (/api/reports/kyosai/?year=2025)
   • 中山間交付金 PDF (/api/reports/chusankan/?year=2025)
5. フロントエンド:
   • 作付け計画編集画面（集計サイドバー付き）
   • 圃場一覧・詳細・新規作成
   • データ取込画面
   • 申請書ダウンロード画面
   • ダッシュボード画面（概要サマリー、作物別集計、クイックアクセス）
6. 対応付け可視化・紐づけ管理 (E-2):
   • 圃場一覧「対応表」モード（共済漢字地名・中山間所在地の一覧表示、直接紐づけ追加・解除）
   • 圃場詳細画面の共済/中山間リンク管理（+追加、×解除、面積参考表示）
   • 共通 LinkModal コンポーネント
7. メールフィルタリング機能（Windmill連携）:
   • Django apps/mail アプリ（MailSender, MailEmail, MailNotificationToken）
   • Windmill向けAPI（APIキー認証）: GET /api/mail/sender-rule/, GET /api/mail/sender-context/, POST /api/mail/emails/, GET /api/mail/stats/
   • フィードバックAPI（認証不要・UUIDトークン）: GET/POST /api/mail/feedback/<token>/
   • ルール管理API（JWT認証）: GET/POST/DELETE /api/mail/senders/, PATCH /api/mail/emails/<pk>/feedback/
   • フィードバックページ: /mail/feedback/[token]（LINEからタップ一発、認証不要）
   • ルール管理ページ: /mail/rules/
   • 処理履歴ページ: /mail/history/
   • 対応アカウント: Gmail × 2、Xserver × 6（本番稼働中、account は xserver1〜xserver6 で識別）
   • Windmill フロー: f/mail/mail_filter（本番: windmill.keinafarm.net にデプロイ済み、10分間隔スケジュール）
   • To: ヘッダー宛先補正を実装（Gmail先行取り込み時も @keinafarm.com 宛は xserver1〜xserver6 として記録/通知）
   • マスタードキュメント: document/11_マスタードキュメント_メール通知関連編.md
8. パスワード変更機能:
   • Backend: POST /api/auth/change-password/（JWT認証、ChangePasswordView in keinasystem/urls.py）
   • Frontend: /settings/password ページ
   • Navbar: KeyRound アイコンボタン（ログアウトボタンの左隣）
9. 気象データ基盤（Windmill連携）:
   • Django apps/weather アプリ（WeatherRecord: 1日1行、2016-01-01〜）
   • データソース: Open-Meteo archive API（窪川 lat=33.213, lon=133.133）
   • Windmill向けAPI（APIキー認証）: POST /api/weather/sync/（upsert、単一/リスト両対応）
   • フロントエンド向けAPI（JWT認証）:
     • GET /api/weather/records/?year=&start=&end= 日次レコード一覧
     • GET /api/weather/summary/?year= 月別・年間サマリー（猛暑日・冬日数含む）
     • GET /api/weather/gdd/?start_date=&base_temp=&end_date= 有効積算温度（GDD）
     • GET /api/weather/similarity/?year= 類似年分析（月別パターン比較）
   • 管理コマンド: python manage.py fetch_weather [--full] [--start-date] [--end-date]
   • Windmill フロー: f/weather/weather_sync（本番稼働中、毎朝6時 Asia/Tokyo）
   • Crop.base_temp（GDD計算の基準温度、default=0.0℃）をCropモデルに追加
   • 初回データ投入: docker compose exec backend python manage.py fetch_weather --full
   • フロントエンド /weather 画面（年別集計・期間指定 モード、グラフは Recharts）
   • 将来計画: 開花・収穫予測（品種ごとの目標GDD設定 → 到達日予測）
   • マスタードキュメント: document/12_マスタードキュメント_気象データ編.md
10. 施肥計画機能（本番稼働中）:

• Django apps/fertilizer アプリ（Fertilizer, FertilizationPlan, FertilizationEntry, SpreadingSession, SpreadingSessionItem）
• API: /api/fertilizer/fertilizers/, /api/fertilizer/plans/, /api/fertilizer/calculate/, /api/fertilizer/candidate_fields/
• PDF出力: /api/fertilizer/plans/{id}/pdf/（WeasyPrint、A4横向き）
• FertilizationEntry.fertilizer は PROTECT（使用中の肥料は削除不可）
• 自動計算3方式: per_tan（反当袋数）/ even（均等配分）/ nitrogen（反当チッソ）
• 四捨五入トグル: ≈（丸め）/ ↩（元の計算値に戻す）
• フロントエンド: /fertilizer（一覧）、/fertilizer/masters（肥料マスタ）、/fertilizer/new・/fertilizer/[id]/edit（編集）
• 施肥機能全体で alert/confirm を廃止し、React インラインバナーでエラー表示
• マスタードキュメント: document/13_マスタードキュメント_施肥計画編.md
• 散布実績機能（2026-03-17 追加）:
  • 散布実績API: /api/fertilizer/spreading/（CRUD + candidates）
  • 散布日単位の記録（同日複数セッション可能）
  • 運搬済み肥料ベースで候補を表示、圃場×肥料単位で実績袋数を記録
  • 保存時に在庫USE連携・FertilizationEntry.actual_bags再集計・WorkRecord自動生成
  • 施肥計画一覧に進捗表示（未散布/一部散布/完了/計画超過）
  • 旧「散布確定」ボタン廃止（is_confirmed/confirmed_at はDB残留、UI未使用）
  • フロントエンド: /fertilizer/spreading

12. 作業記録索引（2026-03-17 追加）:

• Django apps/workrecords アプリ（WorkRecord モデル）
• 運搬・散布の作業を日付順に一覧する索引テーブル
• 明細は各業務テーブル側（DeliveryTrip / SpreadingSession）に持つ
• API: /api/workrecords/?year=
• WorkRecord自動生成: 運搬回の日付保存時・散布実績保存時にupsert

11. 運搬計画機能（旧・分配計画、本番稼働中）:

• 旧 DistributionPlan/Group/GroupField → 新 DeliveryPlan/Group/GroupField/Trip/TripItem に移行
• 施肥計画への直接FK廃止 → 年度ベースで全施肥計画を横断
• 「軽トラ1回分」を基本単位とする運搬回（DeliveryTrip）を追加
• 運搬明細（DeliveryTripItem）で圃場×肥料単位の袋数を管理
• 運搬回ごとの日付記録（作業記録としても機能）
• グループ一括割り当て・グループ単位の回間移動・未割り当て戻し
• API（JWT認証）: /api/fertilizer/delivery/ 配下
• PDF出力（A4横向き・回ごとに1ページ）
• フロントエンド: /distribution/（一覧・編集）
• マスタードキュメント: document/14_マスタードキュメント_分配計画編.md

🚧 既知の課題・技術的負債

1. 認証周り: ログアウト処理が未実装（トークン破棄のみ）
2. エラーハンドリング: フロントエンドでの統一的なエラー表示が未実装
3. テスト: 自動テストが未実装（Phase 2で追加予定）
4. パフォーマンス: N+1問題が一部存在（現状は問題ないが、データ増加時に対応必要）

🔜 次の実装タスク（優先順）

差異レポートの全タスク（A-1〜A-8, B-1〜B-5, C-1〜C-8, D-1〜D-4, E-1〜E-2）は全件完了。 Phase 2 のタスクに進む段階。

詳細は document/06_ドキュメントvs実装_差異レポート.md を参照

📅 次のマイルストーン（Phase 2）

• 栽培履歴管理（播種日、農薬・肥料の散布記録）
• 作業予定のカレンダー表示
• モバイル対応の改善（スマホでの記録入力）

---

🛠️ よくある作業パターン

新しいモデルを追加する場合

1. apps/<app_name>/models.py にモデルクラスを追加
2. python manage.py makemigrations
3. python manage.py migrate
4. apps/<app_name>/admin.py に登録（管理画面で確認するため）
5. Serializer 作成 (apps/<app_name>/serializers.py)
6. ViewSet 作成 (apps/<app_name>/views.py)
7. URL登録 (apps/<app_name>/urls.py)

新しいAPI エンドポイントを追加する場合

1. apps/<app_name>/views.py にビューを追加
2. apps/<app_name>/urls.py にパスを追加
3. フロントエンドで型定義 (frontend/src/lib/types.ts)
4. API呼び出し関数作成 (frontend/src/lib/api.ts または直接fetch)

新しい画面を追加する場合

1. frontend/src/app/<page_name>/page.tsx を作成
2. 必要に応じてレイアウト調整 (layout.tsx)
3. API呼び出しは useEffect + fetch で実装
4. ローディング状態、エラー状態を適切に処理

---

🔍 トラブルシューティング

本番デプロイコマンド（必須）

# deploy.sh で git pull → down → build → up -d を一括実行
ssh keinafarm-claude 'sudo -u keinasystem bash /home/keinasystem/keinasystem_t02/deploy.sh'

Docker Compose 構成:

• docker-compose.yml = 本番用（Traefik連携、gunicorn、prod Dockerfile）
• docker-compose.develop.yml = 開発用（ホットリロード、DEBUG=True）
• 本番サーバー: .env → .env.production シンボリックリンク
• deploy.sh = 本番デプロイ、develop.bat = ローカル開発起動

本番確認手順（デプロイ後の必須チェック）

⚠️ Playwright（ビジュアルテスト）を使う前に、必ずcurlで先に確認すること。 curlはキャッシュの影響を受けず、偽装不可能な確認手段。

# ステップ1: curlヘルスチェック（全9項目、所要約10秒）
bash scripts/check_prod.sh claude keina1234
# → 全 9 項目 PASS が出れば本番が正常稼働中

# ステップ2（任意）: Playwrightでビジュアル確認する場合のプロンプト原則
# - 「認証できなければ即中止して報告せよ」を必ず明記
# - 「スクリーンショットには今日の日付が画面内に見えること」を要求
# - 「成功の証跡（HTTP レスポンスの実テキスト）を必ず添付すること」を要求

本番バックエンドのマイグレーション適用（バックエンド変更時のみ）:

ssh keinafarm-claude 'cd /home/keinasystem/keinasystem_t02 && \
  sudo -u keinasystem docker compose build backend && \
  sudo -u keinasystem docker compose up -d && \
  sleep 5 && \
  sudo -u keinasystem docker compose exec backend python manage.py migrate'

マイグレーションエラー

# マイグレーションをリセット（開発環境のみ！）
docker-compose exec backend python manage.py migrate <app_name> zero
docker-compose exec backend python manage.py makemigrations
docker-compose exec backend python manage.py migrate

CORS エラー

• backend/keinasystem/settings.py の CORS_ALLOWED_ORIGINS を確認
• 現在は http://localhost:3000 と http://127.0.0.1:3000 を許可

JWT トークンエラー

• トークンの有効期限を確認（アクセストークン: 24時間）
• リフレッシュトークンを使って更新（エンドポイント: /api/auth/jwt/refresh/）

PDF 生成エラー

• WeasyPrint のインストールを確認
• 日本語フォントの設定を確認（HTMLテンプレートのCSS）

---

📚 詳細情報へのリンク

マスタードキュメント（機能別の網羅的リファレンス）

特定機能の実装詳細を知りたい場合、まずマスタードキュメントを参照すること。 マスタードキュメントにはデータモデル・API仕様・画面仕様・インポート/エクスポート仕様が ソースコード参照不要なレベルで記載されている。ソース確認が必要な場合もファイル名と行番号の索引がある。

• 圃場管理機能: document/10_マスタードキュメント_圃場管理編.md
• メール通知機能: document/11_マスタードキュメント_メール通知関連編.md
• 気象データ機能: document/12_マスタードキュメント_気象データ編.md
• 施肥計画機能: document/13_マスタードキュメント_施肥計画編.md
• 運搬計画機能（旧・分配計画）: document/14_マスタードキュメント_分配計画編.md

設計ドキュメント（プロジェクト横断）

• プロジェクトの背景・目的: document/01_プロダクトビジョン.md
• 機能要求・ユーザーストーリー: document/02_ユーザーストーリー.md
• データモデル詳細: document/03_データ仕様書.md
• 画面設計: document/04_画面設計書.md
• 実装手順: document/00_Gemini向け統合指示書.md
• 差異レポート・タスク一覧: document/06_ドキュメントvs実装_差異レポート.md

---

💡 新しいセッションでの推奨フロー

1. この CLAUDE.md を読む
2. タスク対象の機能に対応するマスタードキュメントを読む（例: 圃場関連 → document/10_マスタードキュメント_圃場管理編.md）
3. マスタードキュメントで不足する場合のみ、ソースコードや他のドキュメントを参照
4. 実装・修正を行う
5. 重要な設計判断があれば、この CLAUDE.md と該当マスタードキュメントを更新

---

📝 更新履歴

• 2026-03-17: 施肥散布実績連携を実装・本番稼働。旧「散布確定」ボタン廃止→日付単位の散布実績記録（SpreadingSession/Item）へ移行。FertilizationEntry.actual_bags追加、散布保存時に在庫USE連携・WorkRecord自動生成。apps/workrecords新設。StockTransaction.spreading_itemをCASCADE→SET_NULLに変更。マスタードキュメント13/14を更新

• 2026-03-16: 分配計画を「運搬計画」に再設計・本番稼働。実運用のワークフロー（軽トラ複数回・複数施肥計画混在・肥料指定）に合わせ、DeliveryPlan/Trip/TripItem モデルへ移行。施肥計画へのFK廃止→年度ベース。グループ一括割り当て・グループ単位の回間移動機能を追加。マスタードキュメント14を全面改訂

• 2026-03-05: メール通知機能を更新。MailEmail.account を xserver1〜xserver6 で識別可能に変更。Windmill mail_filter に To ヘッダー宛先補正を追加し、Gmail先行取り込みでも Xserver 宛先ラベルが崩れないよう修正。マスタードキュメント/仕様書を同期。

• 2026-02-28: Cursor連携を廃止。Claude Code 単独運用に変更。document/20_Cursor_Claude連携ガイド.md を削除

• 2026-03-02: 分配計画機能を実装。apps/fertilizer に DistributionPlan/DistributionGroup/DistributionGroupField 追加、API /api/fertilizer/distribution/、PDF出力（A4横・グループ★行＋圃場サブ行）、フロントエンド /distribution/。マスタードキュメント document/14_マスタードキュメント_分配計画編.md 追加

• 2026-03-01: 施肥計画機能を実装・本番稼働。apps/fertilizer（Fertilizer, FertilizationPlan, FertilizationEntry, 自動計算3方式, PDF出力, PROTECT migration 0002）、フロントエンド /fertilizer/（一覧・編集・肥料マスタ）。施肥機能全体で alert/confirm 廃止・インラインバナーに統一。マスタードキュメント document/13_マスタードキュメント_施肥計画編.md 追加

• 2026-02-28: 気象データ機能を実装・本番稼働。apps/weather（WeatherRecord, 5 API）、Windmill f/weather/weather_sync（毎朝6時）、フロントエンド /weather（年別集計・期間指定・Rechartsグラフ）。Crop.base_temp 追加。デプロイコマンドの本番パス修正（/home/keinasystem/）。マスタードキュメント document/12_マスタードキュメント_気象データ編.md 追加

• 2026-02-25: CLAUDE.md更新。パスワード変更機能追記。メールフィルタリング機能を本番稼働済みに更新。マスタードキュメント document/11_マスタードキュメント_メール通知関連編.md リンク追加。デプロイコマンド（--env-file .env.production 必須）をトラブルシューティングに追加

• 2026-02-22: メールフィルタリング機能を実装。apps/mail Django app、Windmill向けAPI（APIキー認証）、フィードバックページ、ルール管理ページを追加。仕様書: document/メールフィルタ/mail_filter_spec.md

• 2026-02-21: マスタードキュメント体系を導入。document/10_マスタードキュメント_圃場管理編.md を追加。セッション推奨フローにマスタードキュメント参照を追加

• 2026-02-18: E-2（対応付け可視化・紐づけ管理）仕様追加。画面設計書・差異レポート・次タスク一覧を更新。完了済みタスク(A-8, D-1〜D-4, E-1)を既知の課題から除外

• 2026-02-17: ドキュメント一斉更新（差異レポートA〜E反映、CSV→PDF統一、M:N関係、中山間モデル17列化、インライン編集方式、Navbar追加、既知の課題・次タスク一覧追加）

• 2026-02-16: 初版作成（ハイブリッドアプローチの方針決定）