コンテンツにスキップ

日案サンプルDB作成・任意導入 仕様書 v1.0

  • 作成日: 2026年9月14日
  • ステータス: 計画・初版案(DB作成・配布・導入機能の実装は今回の対象外)
  • 対象: open-hoikuict の日案作成機能、別リポジトリ hoiku-plan-corpus
  • 関連: 日案仕様、日案文例コーパス契約

1. 目的と採用方針

既存の日案をもとに、日案を書く際の参考となる「日案サンプルDB」を作成する。導入を希望する施設だけが追加でき、導入しない施設も通常どおり日案を作成できるようにする。

本体には、別のSQLiteから日案例を検索し、ねらい・内容・一日の流れを下書きへコピーする仕組みがある。この仕組みを再利用し、サンプルDBを任意の追加データとして提供する。

採用方針は次のとおり。

  1. 既存の匿名化レビューDBを作成元とし、人が内容・個人情報・配布条件を確認した日案だけを採用する。
  2. 本体の業務DBとは別の、読み取り専用SQLiteとして配布する。
  3. 新規導入時の初期値は「利用しない」とする。通常起動での投入や自動ダウンロードは行わない。
  4. 利用者が選んだ内容だけを編集用フォームへ反映し、保存操作で施設の日案になる。
  5. DBの更新・利用停止・削除後も、作成済みの日案と履歴を保持する。

ここでいう「導入を希望する人」は、施設の管理者または導入担当者を指す。第1段階では施設のアプリ環境単位で導入し、職員は日案作成時に使うかどうかを選ぶ。職員ごとのDBインストールや、複数施設を一つの環境で切り替える管理は対象外とする。

2. 既存資産の確認結果

2.1 再利用できるもの

2026年9月14日にローカルのコード、スキーマ、DBの集計を確認した。原票本文の審査や配布可否の判定は行っていない。

既存資産 確認結果 今回の利用方針
hoiku-plan-corpus/work/anonymized-review.sqlite 自動匿名化済みの日案100件。2-anonymized-review 形式 最初の候補集合として利用する
hoiku-plan-corpus/schema/runtime.sql 公開用 2-runtime のスキーマ。ねらい・活動ブロック・タグの表を含む 配布DBの生成に再利用する
plan_docs/services/daily_examples.py 読み取り専用接続、年齢・月・キーワード検索、レビュー状態による絞り込み 読み取り処理を拡張して利用する
/plans/daily-plans/new 候補選択、ねらい・内容・横4列の反映 サンプルの選択画面として利用する
plan_docs/services/generators.py 入力内容を独立した日案の下書きとして保存する処理 保存処理を再利用する
test_plan_docs.py 承認済み候補の表示、コピー・編集、元DBが変わらないことの既存テスト 実装時の回帰確認に利用する

2.2 作成元100件の状態

項目 集計結果
内容・個人情報レビュー 100件とも pending / pending。両方承認済みは0件
年齢別件数 0歳18件、1歳17件、2歳19件、3歳17件、4歳16件、5歳13件
月別の範囲 1〜12月すべてに候補がある
年齢×月の網羅 全72組合せのうち55組合せ。17組合せは候補なし
ねらい 100件すべてにねらい行がある
活動ブロック 合計1,661行。日案6件は活動ブロックが0行
配布用メタデータ corpus_version と record_count は未設定

したがって、既存100件から作成することは可能だが、そのファイルをそのまま配布用として使う段階ではない。活動ブロックがある94件についても、内容の正確さや匿名化の十分性は未確認である。配布件数はレビュー後に確定する。

2.3 他の既存データとの関係

  • work/review-sample.sqlite、原票、確認用HTMLは非公開の作業用とし、配布物へ含めない。
  • gen_bunnrei/bunrei.sqlite と facility.sqlite は既存の項目別文例用であり、一日分の活動ブロックを持つ日案DBへそのまま置き換えられない。将来、日案を補う文章の候補として検討する。
  • hoikuict.db は園児・家庭・職員などの業務情報を含むため、DB全体をサンプルとして複製しない。今後、施設で作成した日案を追加する場合は、対象文書・版を明示して許可された項目だけを抽出し、同じレビュー工程に通す。
  • 100人規模デモデータの投入機能とは独立させる。日案サンプルの導入に園児・家庭・アカウントの作成は不要とする。

3. 提供範囲と段階

第1段階: 配布DBと任意導入

  • 既存100件を確認し、合格した日案だけを収録する。
  • 版付きSQLite、マニフェスト、データ利用条件、導入手順を提供する。
  • 導入担当者が手動で取得・検証・配置し、有効化する。
  • 本体に明示的な無効化設定、導入状態の表示、版を含む出典保存を追加する。
  • 通常のWindows起動と、TrueNAS / Dockgeのコンテナ起動に対応する。
  • 更新、前版への復帰、利用停止の手順を用意する。

最初は「既存資料からの選集」として提供する。件数をそろえるための複製や未確認文の追加はしない。年齢・月ごとの収録数と未収録の組合せを公開し、全年齢・全月を網羅した教材とは表示しない。

第2段階以降

  • 管理画面からの導入・更新・利用停止。
  • 複数パックの併用、園専用日案DBとの横断検索。
  • 不足する年齢・月の追加作成と、全72組合せの充実。
  • 施設の日案から候補を取り出す専用の書き出し機能。

第1段階は一つのDBを選択して使う。既に園専用コーパスが設定されている場合は、サンプルDBとの切替であることを導入担当者へ示し、既存ファイルと設定を保存する。自動結合や上書きは行わない。

4. サンプル内容と作成工程

4.1 一件の単位

一件は一日分の日案例とし、次の項目を持つ。

項目 要件
年齢・月・タイトル 0〜5歳、1〜12月。活動が分かる一般的なタイトル
ねらい 空白だけではない文を1件以上
内容・主な活動 ねらいと活動ブロックの内容に対応する記述
一日の流れ 順序付き活動ブロックを1件以上。時刻/活動、子どもの様子、保育士の援助、配慮事項の横4列で確認できる
参照情報 安定した日案ID、外部公開可能な出典参照ID、内容ハッシュ
レビュー状態 内容と個人情報の両方が approved

時刻は「午前」「10:00〜10:30」などの自由記述を許可する。機械的な必須欄埋めはせず、空欄がある場合はレビューで妥当性を確認する。各ブロックには活動を識別できる記述を持たせ、日案全体として子どもの様子・援助・配慮を確認できることを求める。

サンプルの子どもの様子は参考表現であり、利用施設で実際に観察した事実を示すものではない。担当者が当日の子どもと活動に合わせて書き直せる内容にする。

4.2 採用・修正・除外

  1. 作成元DBを読み取り専用で開き、レビュー対象IDを確定する。
  2. 内容レビューで年齢・季節・活動の整合、時系列の順序、欠落、重複、援助や配慮の具体性を確認する。
  3. 個人情報レビューで、氏名・施設固有名・連絡先・識別可能な健康情報・原資料への手掛かりを確認する。
  4. 配布と利用者による編集が認められる範囲を確認し、出典ごとの確認記録を非公開台帳へ残す。
  5. 修正したものは修正後の本文を再確認する。活動ブロック0行の6件は、原資料との照合による補完後に採用するか、初版から除外する。
  6. 内容・個人情報の承認と配布条件の確認を満たしたものだけを、公開用スキーマで新規生成する。
  7. 配布ファイルに対して検証し、収録件数と年齢×月の一覧を確定する。

レビュー記録には日案ID、確認対象の内容ハッシュ、判定、確認者、確認日時を残す。確認者の実名や原票との対応表は配布DBへ含めない。本文を変更した場合は以前の承認を引き継がない。

4.3 配布する値の扱い

  • main_activity_raw は互換性のために必要だが、配布DBでは匿名化・確認済みの活動表現を入れる。原票の未処理文字列は入れない。
  • target_date と school_year は実施日の再現を目的としない。初版では参照用の架空日付へ置き換え、month と年度の整合を保つ。季節や曜日に依存する本文は合わせて確認する。
  • class_label は「3歳児」などに一般化する。職員名、園児名、施設固有のクラス名を持ち込まない。
  • 初版の reflection_text は空にする。過去施設の実績・振り返りを利用施設の記録としてコピーしない。
  • content_hash は匿名化と修正後の本文・ねらい・順序付きブロックから、生成側で定義する共通の正規化手順で算出する。原資料ファイルのハッシュとは分ける。
  • 同じ日案例の改訂ではIDを維持し、内容ハッシュとコーパス版を更新する。別の例へ同じIDを割り当てない。

作業DBから不要列を削除して配布する方法は採らず、許可された列だけを新しいSQLiteへ書き出す。作業用表、原パス、レビュー用HTML、匿名化キー、削除済みデータのページを引き継がない。

5. 配布物とDB契約

5.1 配布パッケージ

パッケージIDは daily-plan-starter とし、本体とは独立して版を付ける。配布方法は版を選べるリリース添付ファイルを基本とし、公開先は最初のリリース時に決定する。

daily-plan-starter-<版>/
  daily_plan_examples.sqlite
  manifest.json
  README.md
  DATA-LICENSE.txt
  CHANGELOG.md

README.md には対象、収録数、年齢×月の一覧、未収録範囲、対応する本体版、導入・更新・停止手順を記載する。DATA-LICENSE.txt には、データの利用・編集・再配布・出典表示の条件を明記する。本体のMITライセンスが原資料へ自動的に適用されるとは扱わない。データ利用条件が未確定の成果物はリリースしない。

5.2 マニフェスト

フィールド 要件
manifest_version 初版は整数 1
package_id daily-plan-starter
corpus_version 一意のリリース版。例: 2026.09.1。同じ版を差し替えない
schema_version 配布物は 2-runtime に限定
generated_at タイムゾーンを含むISO 8601日時
database_file daily_plan_examples.sqlite
sha256 確定したSQLiteファイルのSHA-256
record_count 日案例の実件数。整数、1以上
aim_count / activity_block_count ねらいと活動ブロックの実件数
coverage age_class、month、count を持つ72要素の配列。0件も明示
data_license 確定したデータ利用条件の識別子
tested_app_revision この成果物で受入確認した本体のリリース版またはコミット

DBの corpus_metadata にも package_id、corpus_version、schema_version、generated_at、record_count、data_license を保持する。SQLite内の値は文字列とし、件数を比較する際は整数として照合する。DB自身のファイルハッシュはDB内に入れない。

5.3 スキーマと検証

日案文例コーパス契約と生成側の schema/runtime.sql に従う。daily_plan_aims は本体が読み込む必須テーブルである。daily_plan_activity_tags は生成側スキーマに含めるが、現行の日案画面ではタグ検索に使用しない。

配布用の検証は、次をすべて確認する。

  • SQLiteの整合性検査、外部キー検査、必須表・列・メタデータの存在。
  • マニフェストの対応版、必須項目・型、DBハッシュと各件数の一致。
  • schema_version=2-runtime、全件が内容・個人情報とも approved。
  • 年齢0〜5、月1〜12、品質スコア0〜1、ID・出典参照・内容ハッシュの重複なし。
  • 日案ごとにねらいと活動ブロックが1件以上あり、孤立した子行がない。
  • position が非負で、同じ日案内で重複しない。
  • 収録範囲の集計がマニフェストと一致する。
  • 許可していない表・列・ビュー・トリガーを含まず、公開対象の全テキストを個人情報・禁止語検査へ通している。
  • 内容ハッシュを共通手順で再計算でき、人による確認記録がその内容に対応している。

ファイルハッシュの一致だけで匿名化確認が済んだとは扱わない。生成担当者の確認記録と、配布直前の検証結果を対応付けて保管する。SQLiteを閉じ、WAL等の付随ファイルを必要としない単一ファイルに確定してからハッシュを計算する。

6. 任意導入と設定

6.1 利用者への案内

導入ガイドに次の選択肢を用意する。

日案サンプルを利用する(任意・初期値は利用しない)
年齢・月・活動から参考例を選び、自園向けに編集できます。サンプルを使わずに日案を作成することもできます。

第1段階はガイドと設定で選択する。インストール画面のチェックボックスやアプリ内の設定ページは第2段階で検討する。

6.2 有効・無効の規則

追加する設定名は HOIKU_DAILY_PLAN_EXAMPLES_ENABLED(未実装) とする。サンプルだけでなく、選択中の日案コーパスの読み取り全体を制御する。

値 動作
0 無効。DBパスが設定されていても、既定位置にファイルがあっても読み込まない
1 有効。既存のパス解決規則で選択したDBを読み込む
未設定・空文字 既存環境との互換動作。従来のパス解決規則を維持する
その他 設定エラーとして候補表示を停止し、管理ログへ理由を記録。手入力は継続可能

新規導入用の設定例・ガイドは明示的に 0 を設定し、Composeからその値をアプリへ渡す。既存環境と共用するComposeでは、未設定を強制的に 0 へ変換せず、未設定の互換動作を維持する。既存環境の更新では設定を書き換えず、既に利用中のコーパスを突然無効にしない。通常配布のソース・Dockerイメージには日案サンプルSQLiteを追加しない。

DBパスは既存の HOIKU_DAILY_PLAN_EXAMPLES_DB_PATH を再利用する。

  1. 明示パスがあればそのパスだけを使用する。相対パスはリポジトリ基準とする。
  2. 明示パスがなければ data/daily_plan_examples.sqlite、gen_bunnrei/daily_plan_examples.sqlite の順に確認する。
  3. 明示パスのファイルが見つからない場合、別の既定DBへ切り替えない。

新規のサンプル導入では版付きの明示パスを推奨する。現行 .env.example の匿名化レビューDBへのパスは、実装時に開発用のコメント付き例へ移す。配布サンプルを使うために HOIKUICT_ENV=development を指定する必要はない。

6.3 導入手順

以下は実装後に提供する手順の仕様であり、検証CLIはまだ存在しない。

  1. 導入担当者が配布元の版・収録範囲・利用条件を確認し、希望するパッケージを取得する。オフライン環境へのファイル持込みも認める。
  2. 現在のDBパスと有効・無効設定を記録する。園専用DBを使っている場合は、切替になることを確認する。
  3. 版ごとの新しいディレクトリへ配置し、配布元のハッシュを照合する。
  4. 本体側の読み取り専用検証CLIでマニフェストとDBを検証する。非対応形式、不一致、未承認データは不合格とし、有効化しない。
  5. HOIKU_DAILY_PLAN_EXAMPLES_ENABLED=1 とDBパスを設定する。
  6. アプリを再起動またはコンテナを再作成し、日案画面の版・件数・検索・下書き反映を確認する。

予定するCLIのインターフェースは次のとおり。指定したDBとマニフェストの検証だけを行い、業務DBの初期化・設定変更・ファイル移動は行わない。成功は終了コード0、失敗は非0とし、本文や個人情報をログへ出力しない。

python -m scripts.validate_daily_plan_examples --db <SQLiteのパス> --manifest <manifest.jsonのパス>

DBと manifest.json は同じ版のディレクトリに置く。配布サンプルは読み取り時にもマニフェストとの対応を確認し、同一検証結果のキャッシュはパス・ファイル変更に応じて失効させる。既存の園専用コーパスへ新しいサンプル専用マニフェストを一律に要求しない。

6.4 Windowsとコンテナ

  • Windowsの通常起動は、読み取り権限を付けた版付きディレクトリへの絶対パスを設定する。DBは実行中に上書きしない。
  • TrueNAS / Dockgeは任意のCompose追加設定で、サンプルのディレクトリを /opt/hoiku-samples:ro などへ読み取り専用マウントする。本体の業務DB用ボリュームと分ける。
  • コンテナ内の HOIKU_DAILY_PLAN_EXAMPLES_DB_PATH には、例として /opt/hoiku-samples/<版>/daily_plan_examples.sqlite を指定する。
  • Composeの変数定義だけではアプリへ渡らない場合があるため、追加設定には app.environment の2設定と app.volumes を明記する。サンプルを使わない施設は追加設定を適用しない。
  • バックアップ・通知のworkerへはサンプルのマウントを追加しない。復旧に必要なパッケージ版・ハッシュ・設定・配布物は導入担当者が別途保存する。

7. 日案画面と保存

7.1 状態表示

状態 表示・動作
無効・未導入 「日案サンプルは利用していません」。手入力フォームを利用できる
利用可能 「日案サンプル」、パッケージ版、収録件数、年齢・月・キーワード検索
該当なし 「この条件のサンプルはありません」。別条件での検索と手入力を案内
有効だがファイルなし 「日案サンプルが見つかりません」。手入力を維持し、導入担当者へ確認する案内
破損・非対応・検証不一致 「日案サンプルを読み込めません」。候補を止め、手入力を維持

無効・未導入と検索0件を区別する。エラー時に原資料やサーバーの絶対パスを一般職員へ表示しない。園専用コーパスには「日案サンプル」という配布パック名を付けず、利用中の文例として表示する。

7.2 反映対象

候補のプレビューにはねらい・内容・活動ブロックを示し、「このサンプルを下書きへコピー」で反映する。

  • コピーする: ねらい、内容、時刻・活動、子どもの様子、援助、配慮事項。
  • 利用者の指定を保つ: 対象日、クラス、年齢、担当者。
  • コピーしない: 元の実施日・年度・施設情報・記入者・園児参照・実績・振り返り・承認状態。

年齢が異なる候補を使う場合は差を表示し、利用者が対象年齢に合わせて編集する。入力済みフォームで別の候補を選ぶ場合は置換する項目を示し、明示操作まで入力を保持する。検索・プレビュー操作だけで編集中の本文を失わないようにする。

下書きへ反映した段階では保存済みの日案を増やさない。保存後は通常の日案と同じ編集・提出・確認の流れを使用し、自動承認は行わない。利用・保存の権限は既存の日案権限とクラスへのアクセス制御に従う。

7.3 出典と版

保存する文書・リビジョンには、コピー元の package_id、corpus_version、日案ID、source_ref、content_hash を対応付ける。既存の source_refs を互換維持し、追加の参照情報の表現は実装時に連携契約へ追記する。

現行は出典参照を保存するが、パッケージ版を含む固定参照は未実装である。クライアントが送信した出典文字列だけを信用せず、選択時のサーバー検証済み情報と照合する。フォーム表示後にDBが切り替わった場合も新しい版へ誤って紐付けない。選択時の参照を検証できない場合は本文を保持して再確認を求め、出典不明のまま承認済みサンプル由来と記録しない。

保存済み本文をサンプルDBと同期しない。DBを取り外しても、保存済み文書の表示・編集・印刷・履歴確認に元DBを必要としない。

8. 更新・復帰・利用停止

操作 手順と保証
更新 新版を別ディレクトリへ配置・検証し、パスを切替。自動更新はしない。既存の日案本文・承認版は変えない
更新失敗 検証失敗時は設定を切り替えない。切替後の確認失敗時は記録済みの前版パスへ戻す
同じ版の再導入 同一ハッシュなら同じ成果物として扱う。同じ版で異なるハッシュは不一致として拒否する
前版へ復帰 保存してある前版の検証とパス切替を行い、アプリを再起動・再作成する
利用停止 HOIKU_DAILY_PLAN_EXAMPLES_ENABLED=0 にして再起動・再作成。既定位置に別DBがあっても読み込まない
ファイル削除 利用停止後、対象パッケージのディレクトリとマウントを外す。業務DB・園文例DB・保存済み日案は操作しない

切替・復帰・停止の担当者、日時、変更前後のパッケージ版・ハッシュ・結果を運用記録に残す。本体更新後もサンプルは同じ版を維持し、互換性検証に失敗した場合だけ候補表示を停止する。

9. 現行との境界と実装箇所

項目 現状 必要な追加
原資料の抽出・自動匿名化 hoiku-plan-corpus に実装あり 内容・個人情報レビュー、配布条件確認、承認版の新規生成
公開DBスキーマ 定義あり 生成・配布用検証、マニフェストと利用条件の整備
SQLite読取・検索 実装あり 明示的な無効化、配布サンプル検証、状態の区別
下書きへの反映 実装あり 入力保持、サンプル表示、版と内容ハッシュの固定参照
配布DBの検証CLI 未実装 scripts/validate_daily_plan_examples.py を追加
導入・停止 パス指定は可能 設定例、任意Compose追加設定、版付き配置・更新・復帰のガイド
アプリ内導入管理画面 未実装 第2段階。第1段階の依存条件にしない

主な変更対象は plan_docs/services/daily_examples.py、plan_docs/routers/plans.py、plan_docs/services/generators.py、templates/plan_docs/daily_plans/form.html、関連テスト、設定例、導入資料とする。文書の参照情報を追加する際は、保存・シリアライズ・旧文書読取の互換性も確認する。

10. 受入条件

下表は実装後に実施する受入確認であり、本仕様書作成時に実施済みという意味ではない。

ID 確認内容 合格条件
A01 新規導入で利用しない ダウンロード・DB作成・候補読取がなく、手入力保存できる
A02 既定位置にDBがある状態で明示無効 候補一覧にもID指定による取得にもデータが出ない
A03 有効化と再起動 検証済み版の名前・版・件数が表示され、検索・選択できる
A04 年齢・月・キーワード 該当例が絞り込まれ、未収録の組合せでは0件と表示される
A05 サンプルをコピーして編集・保存 ねらい・内容・ブロックの順序が一致し、利用者の編集だけが保存される。元DBのハッシュは不変
A06 日付・クラスと実績の扱い 利用者の指定が保たれ、原資料の実施日・個人情報・振り返りが付与されない
A07 未承認データの混入 一件でもレビュー未承認なら配布用検証が失敗。開発環境でも配布パックの検証を省略しない
A08 マニフェスト・DB異常 ハッシュ・件数不一致、表欠落、破損、非対応版、孤立行、空の活動ブロックを検出する
A09 DB欠落・エラー 候補表示だけを止め、手入力の日案作成・保存は継続できる
A10 更新・前版への復帰 指定版へ切り替わり、保存済み文書・履歴・コピー元の版は変わらない
A11 停止・ファイル削除 保存済みの日案を閲覧・編集・印刷でき、園児等の業務データが変化しない
A12 入力中の候補切替・DB更新 未保存入力を失わず、別の版への誤った出典記録を防ぐ
A13 Windows・TrueNAS / Dockge 読み取り専用配置で利用可能。希望しない環境に追加マウントが不要
A14 既存の園専用DB利用環境 有効化設定が未設定なら従来どおり動作。サンプル導入時に既存DBを上書きしない
A15 配布範囲 配布物に原票・作業DB・元ファイル名・ローカルパス・匿名化キー・個人の識別情報が含まれない

初回リリースは、レビュー済みの収録一覧、利用条件、配布DBとマニフェスト、Windowsとコンテナの導入・停止確認がそろった時点で可能とする。収録件数、配布先、データ利用条件の確定は初回リリースまでの残件とし、仕様段階で配布済みとは扱わない。