open-hoikuict 日案作成機能仕様書 v1.0

作成日: 2026-08-09
対象: open-hoikuict（FastAPI / SQLModel / SQLite / Jinja2 / HTMX）
対象読者: プロダクトオーナー、保育実務者、実装者、レビュー担当者
ステータス: Phase 0・1の主要範囲を実装済み、Phase 2以降は計画
現況再確認: 2026-08-11
比較元:
日案作成機能_設計書_v0.2.md
DESIGN.md
リポジトリ内の現行仕様・実装

1. 結論

初期リリースは、画像例と同じ「ねらい」「内容（活動）」「子どもの姿」「保育士の援助」の4項目に限定する。日付、クラス、年齢、担当者を入力し、過去の日案例を一組選んで4項目へ反映し、必要箇所を編集して保存する流れを最優先とする。

過去資料の変換は別リポジトリで行い、匿名化と人による確認を終えた版付きSQLiteだけを本体が読み取り専用で利用する。受け入れ契約は docs/daily-plan-corpus-contract.md に定める。

以下のワークスペース、活動ブロック、実績・評価などは、4項目版の利用を検証した後に段階的に追加する拡張仕様である。

日案機能は、紙帳票の再現だけではなく、次の循環を支える「今日の保育ワークスペース」として実装する。

週案・過去の振り返り → 今日の文脈 → 日案 → 実践 → 事実・評価・次への問い → 翌日・次週の計画

画面上は日案とクラス日誌を一体で扱う。一方、データ上は承認対象となる「計画」と、承認後に追記する「実績・評価」を分離し、承認時点を再現可能にする。

園ごとの様式差には、共通の意味スキーマと版付きテンプレートの組合せで対応する。時系列は「1行=1時刻」に固定せず、活動ブロックを単位とし、時刻は自由記述を許可する。

AIはMVP外とし、導入後も提案専用とする。AIなしで作成、提出、承認、印刷、実績・評価まで完結しなければならない。

2. 比較結果と採用判断

論点	v0.2	DESIGN.md	採用する仕様
製品像	日案・週日案、経緯レコード連携	今日の保育ワークスペース	ワークスペースを採用。日案・日誌は同一画面
実様式	光の森保育園のクラス日誌を分析	一般的な標準項目を整理	実様式を既定テンプレートの根拠にし、標準意味項目も保持
計画と記録	`PlanReflection` を追記	`ExecutionRecord` に事実・評価・次への問い	`ExecutionRecord` を採用。追記型で計画リビジョンと分離
セクション	園別の動的セクション	共通意味スキーマ	共通キー + 園別表示 + 名前空間付きカスタム項目
時系列	活動ブロック、自由な時刻、園別列	意味ベース行キー、標準列	活動ブロック + 自由時刻 + テンプレート列。意味ロールを別保持
保存	新規テーブル中心	文書と不変リビジョン、JSON併用	検索列 + 版付きJSON。既存表は段階移行し破壊的変更を避ける
原文	本文とAI由来を記録	原文と清書文を分離	`raw_text` と `official_text` を分離
承認	draft/submitted/approved/returned	詳細状態、コメント、承認版固定	現行状態値を互換維持し、承認対象リビジョンを固定
複製	全文コピーを提供しない	前日・前週・前年から複製	参照・項目単位引用をMVP。全文複製は既定無効
上位計画	週案を参照	承認済みリビジョンを参照	週案の文書IDと参照リビジョンIDを固定
出欠等	表示時導出し承認時に固定	文脈表示、明示採用	画面は最新要約、承認時は監査用スナップショットを固定
タグ	5領域・10の姿・養護	明示なし	文書単位タグを採用。MVP後半で実装
AI	ローカルLLM前提	プロバイダ設定可、外部利用時の統制	初期値は無効。外部送信禁止を既定、例外は施設設定と明示同意
API	AI中心の案	日案・レビューを包括	既存URLを互換維持し、日案専用APIを段階追加

2.1 採用しない、または保留する事項

weekly_daily を独立した文書種別としてMVPに追加しない。週案と日案の関連付けで先に運用し、実様式が揃った後に判断する。
完全なExcel互換帳票デザイナー、XLSX出力、サーバ側PDF生成はMVP外とする。
全文ワンクリック複製はMVPで提供しない。運用評価後に機能フラグで検討する。
AI起案、写真ドキュメンテーション、要録自動生成、自治体への電子提出はMVP外とする。
令和8年度の加算要件は製品境界の参考にはするが、算定可否を本仕様だけで保証しない。最新の告示、通知、自治体運用との別途照合を必要とする。

3. 目的と成功条件

3.1 目的

クラス単位の日案を作成、提出、レビュー、承認、印刷できる。
保育後の事実・評価・次への問いを記録し、次の計画へつなげる。
出欠、日次連絡、健康上の注意、行事を安全な文脈として参照し、重複入力を減らす。
承認時点の本文、様式、参照情報、承認者を再現できる。
園独自の紙様式を、コード分岐を増やさず表現できる。

3.2 成功指標

AIを無効にした状態で、日案作成から実績・評価まで完結する。
アプリ再起動後も文書と履歴が保持される。
同時編集で更新が無言で失われない。
承認済み計画が、出欠や健康情報の後日の変更によって変化しない。
光の森保育園型の「クラス日誌」を、活動ブロックと園別列で印刷再現できる。

4. スコープ

4.1 MVPに含める

日付、クラス、年齢区分、担当者を指定した日案作成
「ねらい」「内容（活動）」「子どもの姿」「保育士の援助」の4項目入力
別リポジトリで構築した承認済み日案例SQLiteの読み取り
年齢、月、キーワードによる日案例検索と一組単位での選択
選択した文例の編集と出典参照の保存
下書き、提出、差戻し、再提出、承認
不変リビジョン、承認版固定、楽観ロック
雨天等の実施変更、重要度判定、事後確認
ブラウザ印刷
施設・クラス範囲の認可と監査履歴

4.2 MVP外

週案・月案からの自動接続
活動ブロック、時系列表、園別の動的列
出欠・日次連絡・健康注意・行事の自動連携
原文と清書文の分離、実績・評価・次への問い
項目単位コメント、版付き園別テンプレート
AI支援
写真添付・ドキュメンテーション
自由配置帳票デザイナー
XLSX出力、サーバ生成PDF
複雑なオフライン同期
個別指導計画そのものの再設計
保育要録の自動生成
外部天気サービスとの自動連携

5. 利用者と権限

能力	主な操作
`plan.view`	対象範囲の日案・承認版を閲覧
`plan.edit`	下書き・差戻し日案を編集
`plan.submit`	日案をレビューへ提出
`plan.review`	コメント、コメント解決、差戻し
`plan.approve`	指定範囲の日案を承認
`plan.record`	実績・評価を追記
`plan.change.confirm`	重要・重大な実施変更を事後確認
`plan.template.manage`	テンプレート版を作成・公開
`plan.export`	印刷・期間出力
`plan.audit.view`	リビジョン、承認、アクセス履歴を閲覧

現行の view_only / can_edit / admin は互換入力として能力へ展開する。
能力と施設・クラス範囲をサーバ側で毎回検証する。
URLやフォーム内の施設・クラスIDを信頼しない。
権限外の文書IDは、存在の推測を防ぐため404相当で応答する。

6. 業務フロー

6.1 作成から承認

担任が日付、クラス、年齢区分、テンプレートを選択する。
システムは対象日の承認済み週案を候補表示する。
担任は週案、前回の「次への問い」、当日の文脈を参照して下書きを作る。
保存時に lock_version を検証する。
提出時に正式リビジョンを作成し、そのリビジョンをレビュー対象として固定する。
レビュー担当者はコメント、差戻し、承認を行う。
差戻し後は旧版を上書きせず、新しい編集リビジョンを作る。
承認時に承認対象リビジョン、テンプレート版、文脈スナップショットを固定する。

6.2 実施後

保育者は承認版を基に実際の活動・変更点を記録する。
「事実」「評価」「次への問い」を分けて入力する。
実績は計画本文を変更せず、追記レコードとして保存する。
次の日案・週案では「次への問い」を候補表示する。自動で本文へ挿入しない。

6.3 雨天等による当日の実施変更

下書き中の変更は、通常編集として日案へ反映する。
レビュー中かつ実施前で時間に余裕がある場合は、取り下げまたは差戻し後に新しいリビジョンで反映する。
レビュー中でも実施が始まっている場合や即時対応が必要な場合は、承認を待たず、固定済みのレビュー対象版を基準に「実施変更」を登録する。このとき未承認状態であったことを記録する。
承認後の変更は承認版を上書きせず、「実施変更」として実績記録へ追加する。
実施変更には、対象活動、変更前、変更後、理由、重要度、変更時刻、記録者を残す。
変更後の環境構成、援助・配慮、安全上の対応も必要に応じて記録する。
変更は「計画」と「実績」の差分として画面・実績付き帳票に表示する。
変更から得た事実・評価・次への問いを、翌日・次週の文脈へ候補表示する。

重要度と確認方法は次のとおりとする。

重要度	例	必要な処理
`minor`（軽微）	雨天で園庭遊びを同じねらいの室内運動へ変更	記録のみ。再承認不要
`significant`（重要）	活動のねらい、安全配慮、場所、担当体制が大きく変わる	関係者へ通知し、主任等が事後確認
`critical`（重大）	事故、災害、重大な健康・安全上の理由による中止・変更	安全確保と既存の緊急対応を優先し、即時共有と事後確認

実施変更は事故報告、ヒヤリハット、医療・服薬指示、災害対応記録の代替にしない。
緊急時に事前承認を待つことを要求しない。安全確保後に必要な記録と確認を行う。
事後確認は承認版の再承認ではなく、実施変更を確認した事実の記録とする。
記録済みの実施変更は上書きせず、訂正が必要な場合は訂正レコードを追記する。

6.4 状態

論理状態	現行互換値	計画本文の編集	説明
下書き	`draft`	可	作成中
レビュー中	`in_review`	不可	提出版を固定
差戻し	`rejected`	新版で可	差戻し理由を受けて修正
承認済み	`approved`	不可	実施に用いる版
完了	当面は派生状態	不可	実績・評価が記録済み
アーカイブ	`archived`	不可	保管状態

submitted はAPI入力の互換別名として in_review に正規化できる。
returned は現行どおり rejected に正規化する。
承認後の計画訂正は、変更理由付きの新リビジョンとして扱う。

7. 機能要件

FR-01 日案の識別

論理キーは facility + classroom + target_date + plan_scope_key とする。
plan_scope_key の既定値は main とする。
合同保育、小集団、延長保育は別スコープを許可する。
削除は論理削除とし、保存期間内は物理削除しない。

FR-02 上位計画との接続

日案は週案の文書IDと参照リビジョンIDを保持する。
対象日を含む承認済み週案を優先候補にする。
未承認週案を参照する場合は警告し、理由入力を必要とする。
週案が更新されても既存日案を自動更新せず、新版の存在だけを通知する。

FR-03 セクション

標準の意味キーは次のとおりとする。

`section_key`	意味
`daily_goal`	本日のねらい
`daily_children_snapshot`	前日までの子どもの姿
`daily_main_activity`	主な活動
`daily_health_safety`	健康・安全
`daily_food_education`	食育
`daily_family_collaboration`	家庭連携
`daily_other_notes`	その他連絡事項

テンプレートは表示名、説明、必須、並び順、表示、印刷可否、AI支援可否を設定できる。
園独自項目は custom.<facility_key>.<name> 形式のキーを使用する。
各記述項目は raw_text と official_text を持つ。
清書、文例採用、将来のAI採用で raw_text を上書きしない。

FR-04 活動ブロック

時系列の編集単位は活動ブロックとする。
活動ブロックは安定した block_key、並び順、活動見出し、自由な時刻表記、セルを持つ。
時刻は 10:00、10:00〜10:45、複数時刻、随時、空欄を許可する。
1ブロックに複数の細目を箇条書きで入力できる。
同じ時刻の複数ブロックを許可する。

FR-05 時系列列

列はテンプレート版で定義する。
各列はテンプレート内で安定した column_key、表示名、並び順、意味ロールを持つ。
標準意味ロールは activity、environment、children、support、consideration とする。
1列に複数の意味ロールを割り当てられる。これにより、光の森保育園型の「配慮事項」列へ環境構成・準備を含められる。
現行の env / children / support キーは互換テンプレートとして維持する。

光の森保育園型の既定列例:

`column_key`	表示名	意味ロール
`child_state`	子供の様子	`children`
`caregiver_action`	保育士の働きかけ	`support`
`care_note`	配慮事項	`environment`, `consideration`

FR-06 個別配慮

必要な園児、小集団、クラス全体へ配慮事項を紐づけられる。
日案本文と別の閲覧・印刷権限を設定できる。
診断名、服薬、医療的ケア指示を本文へ自動コピーしない。
3歳未満児の個別的な計画は既存の個別指導計画へリンクし、日案だけで代替しない。

FR-07 今日の文脈

読み取り専用の DailyPlanContextService は、権限確認後に次を返す。

承認済み週案の要約
前回の事実・評価・次への問い
出席予定数、出席数、欠席数、未確定数
日次連絡の提出数と注意件数
権限制御された健康・アレルギー注意
当日の行事
関連する経緯レコード

表示しただけでは本文を変更しない。「本文へ反映」を実行した項目だけ、ソース情報付きで保存する。

FR-08 出欠とクラス日誌ヘッダ

在籍数、出席数、欠席数・欠席者は表示時に登降園データから導出する。
承認・完了時には参照時刻と集計値を文脈スナップショットへ固定する。
欠席理由や健康詳細は通常印刷へ既定で出力しない。
天候はMVPでは手入力とする。
記入者と承認者は監査情報から印字する。印影画像は必須としない。

FR-09 過去参照と複製

前日、前週、前年同時期の日案と振り返りを参照できる。
セクション単位、活動ブロック単位の「引用して編集」を提供する。
引用元文書ID・リビジョンIDを記録する。
全文複製はMVPで既定無効とする。
将来有効化する場合も、日付依存情報、出欠、健康情報、承認情報、実績を複製してはならず、再確認を必須とする。

FR-10 タグ

5領域、10の姿、養護（生命の保持・情緒の安定）を文書単位で付与できる。
テンプレート必須項目にはしない。
関連する振り返り・経緯レコードの検索条件に利用できる。

FR-11 コメント・レビュー

文書全体または field_path にコメントできる。
コメントは open / resolved 状態、作成者、日時、編集履歴を持つ。
差戻し理由は必須とする。
承認時は未解決の必須コメントがないことを検証する。

FR-12 実施変更

承認済み日案に対して、活動ブロック単位または文書全体の実施変更を登録できる。
理由コードは weather、child_state、safety、staffing、facility、other を標準とする。
other の場合は理由の自由記述を必須とする。
変更前は承認リビジョンまたは直前の実施変更からスナップショットを取得し、利用者が無断で書き換えられないようにする。
変更後は活動見出し、時刻、各セル、全体の健康・安全配慮を必要な範囲で入力できる。
significant と critical は、確認権限を持つ利用者へ未確認件数として通知する。
実施変更の登録には plan.record、事後確認には plan.change.confirm を必要とする。
事後確認者、確認日時、コメントを保持する。
実績入力では、最後に有効な実施変更後の内容を「実際の計画」として参照できる。

FR-13 印刷

A4縦・横をテンプレートで選択できる。
「承認時点」と「現在の実績付き」を分けて出力できる。
通常印刷では原文、内部コメント、AI履歴、健康詳細を除外する。
文書版、テンプレート版、承認者、承認日時をフッターへ表示する。
ファイル名規約は YYYY-MM-DD_クラス_主活動 を既定とする。
クラス×期間の一括印刷をMVP後半で提供する。

8. データ仕様

8.1 設計原則

識別、検索、状態、参照先、版番号は列として保持する。
本文、活動ブロック、文脈スナップショットはスキーマ版付きJSONとする。
承認・レビュー・コメント・実績・ソース・AI実行は別テーブルとする。
現行環境では SQLModel.metadata.create_all() が既存表を変更しないため、MVP移行で plan_documents のALTERを前提にしない。必要な管理列は新しい伴走テーブルへ追加する。
SQLiteで成立し、リポジトリ層の外へSQLite固有処理を漏らさない。
既存 plan_documents のデータは最初のリビジョンへ移行する。

8.2 主要エンティティ

文書ヘッド（論理モデル）

論理上は次の情報を一つの文書ヘッドとして扱う。Phase 1の物理実装では、現行 PlanDocumentRow を識別・基本属性の格納先として維持し、新規 PlanDocumentHeadRow を1対1で追加する。

フィールド	説明
`id`	現行 `PlanDocumentRow.id`
`public_id`	`PlanDocumentHeadRow` のURL/API用UUID
`document_type`	`daily_plan`
`nursery_ref`, `classroom_ref`	施設・クラス境界
`target_date`	現行 `PlanDocumentRow` の対象日
`plan_scope_key`	`PlanDocumentHeadRow`。日案の論理スコープ
`age_class`	年齢区分
`status`	現在状態
`owner_actor_ref`	主担当
`current_revision_id`	`PlanDocumentHeadRow`。最新編集版
`review_revision_id`	`PlanDocumentHeadRow`。提出・レビュー対象版
`approved_revision_id`	`PlanDocumentHeadRow`。承認版
`template_version_id`	`PlanDocumentHeadRow`。作成時の様式版
`lock_version`	`PlanDocumentHeadRow`。楽観ロック
`deleted_at`	`PlanDocumentHeadRow`。論理削除

PlanDocumentHeadRow.document_id は一意とする。
facility + classroom + target_date + plan_scope_key の一意性は伴走テーブル側で保証する。
将来、正式なマイグレーション基盤を導入した段階で単一テーブルへ統合できるが、リポジトリ契約から物理配置を隠蔽する。

`PlanRevisionRow`

document_id, revision_no, payload_schema_version
raw_inputs, official_sections, activity_blocks
individual_considerations, tags
context_snapshot, confirmation_items
parent_document_id, parent_revision_id
created_by, created_at, reason, content_hash

リビジョンは作成後に更新・削除しない。

`PlanTemplateRow` / `PlanTemplateVersionRow`

論理テンプレートと公開済みの不変版を分ける。
公開版はセクション、列、初期活動ブロック、印刷設定、承認ルートを保持する。
公開済み版を直接編集せず、新版を作成する。

`PlanExecutionRecordRow`

document_id, approved_revision_id
actual_raw_text, actual_official_text
evaluation_text, next_question_text
change_summary
recorded_by, recorded_at
必要に応じて追記履歴を保持し、計画リビジョンを変更しない。

`PlanExecutionChangeRow`

id, document_id, base_revision_id
approval_state_at_change。変更時点の in_review または approved を固定する。
affected_block_key。文書全体の変更ではNULLを許可する。
reason_code, reason_note, impact_level
before_snapshot, after_snapshot
changed_at, recorded_by, recorded_at
confirmation_status: not_required, pending, confirmed
confirmed_by, confirmed_at, confirmation_comment
corrects_change_id: 訂正元。元レコード自体は更新・削除しない。

実際に採用された変更を時系列順に適用することで、当日の「実際の計画」を再現できること。base_revision_id は承認済みなら承認版、レビュー中の即時変更なら固定済みレビュー対象版を指す。before_snapshot はサーバ側で基準版または直前変更から生成し、クライアント送信値を正としない。

その他

PlanSourceLinkRow: 反映先フィールドと参照元ID・版・参照時刻
PlanReviewActionRow: 提出、差戻し、承認、取り下げ、訂正
PlanCommentRow: 項目コメントと解決状態
PlanTagRow: 分類体系とコード
PlanAiRunRow: AI導入時のみ、入力範囲・モデル・提案・採否

8.3 活動ブロックJSON例

{
  "block_key": "block-uuid",
  "order": 40,
  "heading": "制作（ネックレス）",
  "time_label": "10:00 / 10:45",
  "cells": {
    "child_state": {
      "raw_text": "素材を選ぶ。友達の作り方を見る。",
      "official_text": "素材を選び、友達の作り方にも関心を向ける。"
    },
    "caregiver_action": {
      "raw_text": "選び方を急がせない",
      "official_text": "一人ひとりが選ぶ時間を確保し、試し方を言葉にする。"
    },
    "care_note": {
      "raw_text": "準備: 紙粘土、毛糸、ストロー",
      "official_text": "紙粘土、毛糸、ストローを選べる位置に用意する。"
    }
  }
}

8.4 現行スキーマからの互換

現行 SectionBlock.body は初回移行時に official_text へ格納し、raw_text は同値または空として移行方針を選ぶ。
現行 PlanSchedule.rows[].row_key は block_key として引き継ぐ。
現行 start_time と label は、移行時に time_label と heading へ写す。
現行の env / children / support は互換テンプレート列として保持する。
payload_schema_version により旧JSONを読み取り可能にし、読み込み時変換を行う。

9. 画面仕様

9.1 画面一覧

画面	目的
日案ダッシュボード	今日・今週の日案、状態、反省未記入、未解決コメント
日案作成	日付、クラス、年齢、週案、テンプレートを選択
日案ワークスペース	計画、活動ブロック、文脈、コメント、実績を編集
レビューキュー	提出版、差分、コメント、承認操作
テンプレート管理	園別様式の版管理と印刷プレビュー
文書検索・保管	日付、クラス、担当、状態、タグ、全文検索
印刷ビュー	承認時点または実績付き帳票

9.2 ワークスペース

ヘッダ: 日付、クラス、状態、担当、保存状態、提出・印刷操作
文脈バー: 欠席、体調注意、行事、前回の問いの件数要約
中央: 園様式順のセクションと活動ブロック
ドロワー: 文脈詳細、ソース、コメント、要確認
下部: 実施後の事実、評価、次への問い
承認後は活動ブロックに「実施変更」操作を表示する。
実施変更入力では、変更前と変更後を並べ、理由、重要度、変更時刻を入力する。
変更済みブロックには「計画から変更」ラベルを表示し、計画内容と実際の内容を切り替えて確認できる。
significant、critical の未確認変更は、レビューキューと日案ヘッダに件数を表示する。
狭い画面では活動ブロックをカード表示し、列を縦に並べる。
自動保存状態、競合、エラーは色だけでなく文字で示す。

10. API仕様

10.1 互換方針

現行の /plans/daily-plans/new、POST /plans/daily-plans、/plans/documents/{id}、/plans/api/documents/{id} は移行期間中維持する。
新しい日案ワークスペースAPIは /plans/api/daily 配下に追加する。
互換ルートも同じアプリケーションサービスとリポジトリを使用し、別の保存経路を作らない。

10.2 現在の追加エンドポイント

GET   /plans/daily-plans/
GET   /plans/daily-plans/new
POST  /plans/daily-plans
GET   /plans/documents/{document_id}

GET   /plans/api/daily/{document_ref}/execution-changes
POST  /plans/api/daily/{document_ref}/execution-changes
POST  /plans/api/daily/{document_ref}/execution-changes/{change_id}/confirm
POST  /plans/api/daily/{document_ref}/execution-changes/{change_id}/corrections

document_refは内部IDまたは公開IDを受け付ける。振り返りは/plans/documents/{document_id}/reflection、画面上の実施変更は/plans/documents/{document_id}/execution-changes配下を使用する。

文脈API、自動保存、コメント、専用の提出・差戻し・承認API、実施記録API、専用印刷URLは後続フェーズで追加する。現時点では文書詳細・編集・状態更新の既存ルートを再利用する。

10.3 更新契約

現行のHTML編集・状態更新はlock_versionを必須とし、成功時に新しい版を保存する。
将来のJSON更新APIはIf-MatchとETagを使用する。
版競合、状態遷移違反は409とする。
入力不備は422、権限違反は403、範囲外IDは404相当とする。
CSRF対策を既存ミドルウェアに統合する。

11. AI支援（MVP後）

表示名は「候補を出す」「文章を整える」とし、「AIで完成」等の表現を使わない。
原文、現行清書文、AI候補、差分を並べる。
採用、部分採用、不採用をセクション単位で行う。
未入力の事実、診断、家庭状況、医療・服薬指示を生成しない。
承認・公開を自動化しない。
氏名、診断、医療情報は既定で入力から除外する。
既定はローカルLLMまたはAI無効とする。外部APIは施設設定、送信項目表示、権限、監査を満たす場合だけ許可する。
実行者、モデル、プロンプト版、送信フィールド、候補、採否を記録する。

12. 非機能要件

12.1 性能

想定: 施設100人、1クラス20人、2年度分の日案。
日案ワークスペースの初期表示は通常環境でp95 1秒以内を目標とする。
文脈取得でN+1クエリを発生させない。
AI導入時も通常保存を待たせない。

12.2 可用性・耐久性

SQLModelリポジトリを本番経路とし、インメモリ実装はテスト専用とする。
SQLiteのWAL、外部キー、busy timeoutという既存方針を維持する。
保存失敗時は入力をブラウザで一時保持し、再送できる。
バックアップと復元手順を運用文書へ追加する。

12.3 セキュリティ・プライバシー

施設・クラス範囲、能力、対象リビジョンをサーバ側で検証する。
IDOR、権限昇格、承認なりすまし、CSRFをテストする。
健康・家庭情報の詳細アクセスは監査ログへ記録する。
通常ログへ本文や健康詳細を出力しない。
デモ環境へ実在の個人情報を入れない。

12.4 監査・再現性

承認時点の文書、テンプレート、参照ソース、承認者、日時を再現できる。
不変リビジョンの更新・削除をアプリケーションサービスで禁止する。
保存期間は施設・自治体設定とし、システムで一律物理削除しない。

12.5 アクセシビリティ

キーボードだけで主要な入力、保存、提出ができる。
色だけで状態を表さない。
タッチ操作対象を十分な大きさにする。
エラーを該当項目と画面上部の両方に示す。

13. 受入基準

ID	受入基準
AC-01	日付、クラス、年齢、テンプレートを選び日案を作成できる
AC-02	週案の文書ID・リビジョンIDを参照し、後日の週案更新で日案が変わらない
AC-03	原文と清書文が別保存され、清書しても原文が変わらない
AC-04	未入力・未接続の情報を推測せず「要確認」と表示する
AC-05	活動見出し、複数時刻を含む自由時刻、園別列を編集できる
AC-06	光の森保育園型の3列を持つクラス日誌を印刷できる
AC-07	必要な園児・小集団だけに個別配慮を紐づけられる
AC-08	提出リビジョンが固定され、レビュー中に本文を直接変更できない
AC-09	項目コメント、差戻し理由、承認者、承認日時が履歴に残る
AC-10	承認後の訂正で旧版が上書きされない
AC-11	実績の事実、評価、次への問いを計画とは別に追記できる
AC-12	次への問いが翌日の日案に候補表示されるが、自動挿入されない
AC-13	出欠・日次連絡は文脈表示だけでは本文を変更しない
AC-14	承認時の出欠集計と参照時刻を再現できる
AC-15	再起動後も日案、リビジョン、コメント、承認、実績が保持される
AC-16	同時編集の競合で409となり、一方の更新が失われない
AC-17	権限外の施設・クラス文書を取得・更新・承認できない
AC-18	通常印刷に内部コメント、AI履歴、健康詳細が出ない
AC-19	AIを無効にしても全MVP機能が成立する
AC-20	現行の日案作成・文書詳細URLが移行期間中も動作する
AC-21	承認済み日案で雨天変更を登録しても承認リビジョンが変化しない
AC-22	実施変更の変更前後、理由、重要度、変更時刻、記録者を再現できる
AC-23	重要・重大な変更は未確認として通知され、確認者・日時・コメントが残る
AC-24	実績付き帳票で計画と実際の変更内容を区別して表示できる
AC-25	実施変更の訂正が元記録を上書きせず、追記履歴として残る
AC-26	重大な実施変更が事故・健康・災害の既存記録を代替しない旨を画面で案内する

14. テスト方針

14.1 単体

状態遷移と能力判定
必須・要確認判定
原文不変
リビジョン不変、ハッシュ生成
テンプレート版固定
活動ブロックの並び替えと自由時刻
旧スキーマJSONの読み込み変換

14.2 統合

週案から日案作成
出欠、日次連絡、行事、健康注意の文脈取得
提出、コメント、差戻し、再提出、承認
承認版を基にした実績記録
雨天による軽微な実施変更と、計画・実績差分の再現
重要・重大な実施変更の通知、事後確認、訂正履歴
DB再起動後の再現
楽観ロック競合
印刷時の機微情報除外

14.3 セキュリティ

他クラス・他施設のID差し替え
閲覧権限での更新・承認
承認後の直接PATCH
CSRFなしの状態変更
健康情報の印刷・AI入力への混入

15. 実装ロードマップ

Phase 0: 互換契約と安全網

ADRを作成する。
現行日案生成、schedule、権限、URLの回帰テストを固定する。
DocumentRepository Protocolを導入する。

完了条件: UIを変えずに保存実装を差し替え可能。

Phase 1: 永続化・版管理

SQLModelリポジトリへ切り替える。
既存表をALTERせず、PlanDocumentHeadRow とリビジョン、レビュー対象版、承認版、楽観ロックを新規テーブルで追加する。
現行JSONを初回リビジョンへ移行する。

完了条件: 再起動後の保持、承認版再現、競合検知。

Phase 2: 実様式対応ワークスペース

原文と清書文を分離する。
版付きテンプレートと活動ブロックスキーマv2を追加する。
光の森保育園型テンプレート、タブレット表示、印刷を実装する。

完了条件: 非AIで実様式の日案を作成、提出、承認、印刷可能。

Phase 3: 文脈・レビュー

DailyPlanContextService、コメント、レビューキューを追加する。
出欠・日次連絡・健康注意・行事を安全に接続する。
能力ベース権限を導入する。

完了条件: 重複入力を減らし、項目別レビュー履歴を保持。

Phase 4: 実績・評価の循環

PlanExecutionRecordRow を追加する。
PlanExecutionChangeRow と実施変更・事後確認UIを追加する。
事実、評価、次への問いを翌日・次週へ候補表示する。
経緯レコードへの冪等な昇格を接続する。

完了条件: 計画・実践・評価・次の計画が一連で回る。

Phase 5: AI・高度な出力

差分ベースの校正・構造化候補を追加する。
AI実行監査、テンプレート管理UI、XLSXマッピングを追加する。

完了条件: AIが本文を無断変更せず、安全な付加価値として機能。

16. 未決事項

論点	推奨初期値	決定時期
保管年限	施設・自治体設定。自動物理削除なし	導入園確認時
承認者	主任・園長へ能力を付与可能	Phase 1
反省の承認要否	追記可能。訂正履歴は残すが再承認不要	Phase 4前
全文複製	既定無効	ベータ評価後
週日案文書種別	追加しない	実様式追加調査後
テンプレートのカスタム列検索	意味ロールで限定検索	Phase 2
外部AI	既定禁止	Phase 5前の個人情報評価後
加算要件トレーサビリティ	別紙で管理	最新告示・自治体運用確認後

17. 根拠と参照

こども家庭庁「保育所保育指針解説」: 短期的な指導計画、子どもの実態、環境構成、個別的な計画、評価と改善の根拠。
こども家庭庁「保育所における自己評価ガイドライン」: 計画・実践・評価・改善の循環の根拠。
こども家庭庁「令和8年度導入に向けた自治体向けオンライン説明会」: 保育ICT推進加算（仮称）の案で示された「保育に関する計画記録」機能。最終要件は別途確認する。
docs/spec-weekly-daily-plans.md: 現行の文書種別、section_key、schedule、URLの互換契約。
plan_docs/contracts.py, plan_docs/models.py, plan_docs/store.py, plan_docs/db_models.py: 現行実装と移行対象。

18. 実装状況

2026-08-09 初回実装

実装済み:

全計画ルートをインメモリ保存からSQLModelリポジトリへ切り替え
既存表をALTERしない PlanDocumentHeadRow の追加
PlanRevisionRow による不変スナップショット、連番、内容ハッシュ
編集・状態変更の楽観ロックとHTTP 409
提出リビジョン、承認リビジョンの固定
既存 plan_documents 行の初回アクセス時移行
差戻し理由の必須化
PlanExecutionChangeRow による実施変更、重要度、事後確認、追記訂正
雨天等の変更前後を表示する日案画面
内部ID・公開IDの両方を受け付ける実施変更JSON API
自由な時刻表記への入力変更
永続化、競合、承認版不変、変更確認、訂正、公開ID APIの統合テスト
初期作成画面を4項目だけに簡素化
4項目一組の日案例SQLiteを読み取り専用で検索・選択するサービス
approved の候補だけを表示し、選択後に編集できる作成フロー
外部コーパスのスキーマ、匿名化、版管理、取り込み契約

次の実装対象:

raw_text / official_text と活動ブロックスキーマv2
版付き園別テンプレートと光の森保育園型印刷
DailyPlanContextService と出欠・日次連絡・健康注意・行事の連携
項目コメント、能力ベース権限、レビューキュー
事実・評価・次への問いと経緯レコード連携
タグ、AI支援、高度な出力

open-hoikuict 日案作成機能 仕様書 v1.0