スケジュール起票

日付をきっかけに、別のアプリへレコードを自動で作る機能です。「入社日から 6 か月後、以後は 1 年ごと」「毎年 4 月 1 日」「毎月 25 日」「毎営業日」「シフト表に登録された日」のような予定を決めておくと、その日が来たときにシステムが自動でレコードを起票します。「アプリ設定」→「スケジュール起票」から設定します。

アクション（人がボタンを押して転記する）やデータパイプライン（集計する）と違い、きっかけが「人の操作」ではなく「日付」である点が特徴です。ルールを置いたアプリで設定し、起票先には別のアプリを指定できます。

動作イメージ

ルールの内容

• 1 つのアプリに登録できるルールは最大 10 件です
• ルールごとに有効／無効を切り替えられます。無効の間は実行されません。再度有効にすると、止めていた間の予定のうち 7 日以内の分は追いつきで起票され、それより古い分は「未実行」として記録・通知されます（無効化は予定そのものを消すわけではありません）

発生日の決まり方（3 種類）

「本来レコードがあるはずの日」を発生と呼びます。発生は日付と対象（誰・何について起きたか）の組で決まり、起票はその 1 件ごとに 1 レコードを作ります。

起算日からの周期で（レコードごとに違う日）

このアプリの日付フィールドを起点にして、「起点日の N か月後」を 1 回目、以後「M か月ごと」に繰り返します。繰り返しをオフにすると 1 回だけの起票になります。レコードごとに起点日が違うので、レコードごとに別々の予定が立ちます。

• 予定日は常に「起点日 + N + M × 回数」で計算します。前回いつ実行したかに依存しないため、障害で処理が飛んでも予定はずれません
• 起点日を後から修正すると、予定も自動的に計算し直されます（入力ミスの訂正がそのまま効きます）
• 起点日が空のレコードは対象外です
• 存在しない日になる場合はその月の末日に丸めます（例: 8 月 31 日の 6 か月後 → 2 月 28 日、うるう年は 2 月 29 日）
• 「前回の実施から N か月後」のような運用は、実施日を記録する日付フィールドを起点にすると表現できます（起点日が書き換わると、その先の予定が新しく立ちます）。周期に指定できるのは月単位だけです

暦の規則から（決まった日に、対象の数だけ）

決まった日に起票します。頻度は毎日・毎週・毎月・毎年から選びます。

• 営業日のみ発生するを ON にすると、休日カレンダーの休日には発生しません（「毎営業日、対象の人数分の行を用意する」のような運用に使います）
• 2 月 30 日や「毎月 31 日」のように存在しない日になる場合は、その月の末日に丸められます（2 月なら 28 日、うるう年は 29 日）
• 発生の対象にメンバー等を選ぶと、その日に対象の人数分のレコードが作られます。この場合、起票先のどのユーザー選択項目にその人を入れるかを「何を作るか」の対象を表す項目で 1 組指定します（未指定だと人数分あっても 1 行しか作られません）
• メンバー等では全員（このシステムを利用できるメンバー全員。無効なメンバーは除きます）か対象を絞る（メンバー・グループ・組織を名指し）を選びます。「全社員分を毎営業日用意する」なら全員を選べば、入社・異動のたびに設定を直す必要がありません
• 発生の対象にアプリのレコードを選ぶと、そのアプリの（条件に合う）レコードごとに 1 件ずつ起票されます。値の決め方の「コピー」はそのレコードから写します
• 「なし」の場合は 1 日 1 件です。値の決め方を固定値だけにすると同じ内容のレコードが並ぶため、通常は発生の対象や「コピー」を組み合わせて使います
• 同じ回が二重に起票されることはありません（対象と予定日の組み合わせで記録しているため）。取りこぼした回は7 日以内なら自動で追いつきます — 毎週の場合、この追いつきによって前週分が 1 回起票されることがあります

レコードに登録された日付から（登録された行の数だけ）

参照先のアプリと、その中の日付フィールドを指定します。条件に合う 1 レコードが発生 1 件になり、そのレコードの日付が予定日になります。「シフト表に登録された日の分だけ、日次勤怠の行を先に用意する」「点検計画の日に点検記録を用意する」のような使い方です。

• 予定が登録されていない日には何も起きません。カレンダー側で「休みだから除外する」といった差し引きが要らないのが、この決まり方の要点です
• 参照先はこのアプリ自身でも構いません（「別のアプリ」に限りません）。1 つのアプリに予定と実績を分けて入れている場合に使えます
• 値の決め方の「コピー」は、その発生を生んだレコード（＝参照先アプリの行）から写します。「先行して起票する日数」と組み合わせると「シフトの 3 日前に勤怠の行を用意する」になります
• 参照先アプリのレコードを読むため、実行名義に参照先アプリのレコード閲覧権限が必要です（下記「実行と権限」）

休業期間で除外

未登録チェックと同じ「休業期間で除外」（任意）が、発生日の決まり方 3 種類のどれを選んでいても使えます。 休業期間を記録するアプリ（日付・日時を基準にした範囲型フィールドを持つもの）を選ぶと、 発生日がどれかの行の期間に含まれる日は起票されません。「9/1〜9/7 は改装工事で休業」のような臨時休業の日には、 たとえ本来の予定日でもレコードが作られなくなります。

除外された回は「そもそも発生しなかった」ものとして扱われます。取りこぼしと違い、休業期間が明けた後に遡って起票されることはありません（7 日以内の自動追いつきの対象にもなりません）。

• 開始・終了のどちらかだけが入力された行は無効として無視されます（期限の入れ忘れで終了日の無い行ができ、その先ずっと除外扱いになってしまうのを防ぐためです）
• 参照先のアプリやフィールドが後から削除・変更されて使えなくなった場合、その回はエラーとして実行履歴に記録され、実行名義とシステム管理者へ通知されます（参照を直すまで同じ状態が続きます）
• 指定しない場合はこれまでと変わりません（除外は行われません）

値の決め方（4 種類）

• 保存するときに型の互換性まで検証します（数式の結果が日付なのに数値の項目へ入れようとしている、など）。合わない設定は保存できません
• 起票先の必須項目は、値の指定か初期値のどちらかが必要です。どちらも無い場合は保存時にエラーになります（実行のたびに必ず失敗するルールを作らせないため）
• 計算フィールド・自動採番・関連レコード集計など、システムが値を決める項目は指定できません（起票後に自動で埋まります）

実行と権限

起票はルールを保存した人の名義で行われます。そのため保存時に、次の 2 つの権限を持っているかを検証します。

• 発生の材料になるアプリのレコード閲覧権限 — 条件の判定やコピーのために、実際のデータを読むため。「起算日からの周期で」ならこのアプリ、「レコードに登録された日付から」なら参照先アプリ、発生の対象がアプリのレコードならそのアプリが対象です
• 起票先アプリのレコード追加権限

• 権限は実行のたびにも確認します。後から権限が外れた場合、その回は起票されず理由が記録されます
• 名義のユーザーが無効化・削除されると、ルールは自動的に停止し、システム管理者へ通知されます
• 起票は通常のレコード作成と同じ経路で行われるため、入力チェック・重複禁止・自動採番・通知・変更履歴・期間ロックがそのまま効きます。期間ロック中や入力チェックに引っかかった回は起票されず、理由が記録されます
• ルールの設定を変更できるのは、そのアプリのアプリ管理者です

取りこぼしと重複の扱い

• 同じ回を二重に起票しません。実行済みの記録はデータベース側で一意に保たれているため、処理が同時に走っても 1 件だけになります
• 障害などで処理できなかった回は、予定日から 7 日以内なら翌日以降の実行で自動的に追いつきます。追いついた場合も、値は本来の予定日を基準に計算されるため、遅れて起票されても内容は正しいままです
• 7 日を過ぎた回は自動では起票されません。発生に対象がある場合（起算日からの周期 / レコードに登録された日付から / 発生の対象を選んだ暦の規則）は、その回が「未実行」として実行履歴に残り、履歴から手動で再実行できます。発生の対象が「なし」の暦の規則では個別の履歴は残らず、残った件数がまとめて通知されます（どちらも実行名義とシステム管理者へ通知されます）
• ルールを作る前の予定は対象外です（過去にさかのぼって起票することはありません）。過去分が必要な場合は手動で登録してください
• 1 回の実行で起票する件数には上限（500 件）があり、超えた分は翌日以降に持ち越されます。ただし持ち越せるのは上記の 7 日以内なので、1 つの回で起票できるのは合計 3,500 件程度が上限です。対象がこれを超える規模になる場合は、条件で絞るか、起算日からの周期（レコードごとに予定日がばらけるため一度に集中しません）を検討してください

実行履歴

ルールごとに「いつ・どのレコードの・どの回が・どうなったか」を確認できます。結果は次のように表示されます。

• 「未実行」やエラーになった回には「この回を今すぐ起票」が表示され、手動でやり直せます。この場合も値は本来の予定日を基準に計算されます
• 起点日を過去方向へ修正した場合、7 日を過ぎた回は自動では起票されません。必要であればこの手動実行で回収してください

バックアップ・パッケージへの同梱

スケジュール起票のルールは、アプリの設定の一部としてバックアップとパッケージに含まれます。ただし、復元・導入したルールは次のように扱われます。

• 必ず「停止」状態で入ります。復元・導入した直後に、意図しない自動起票が走らないようにするためです。内容を確認してから有効にしてください
• 実行名義は、復元・導入を実行した人に差し替わります。元の実行名義がそのまま引き継がれると、本人の知らないところでその人の名義で自動起票が走ることになるためです。有効にする前に、その名義で「起点となるアプリのレコード閲覧権限」と「起票先アプリのレコード追加権限」が揃っているか確認してください
• 実行履歴（過去に何をいつ起票したか）は引き継ぎません。復元・導入したアプリでは、有効にした時点から先の予定が対象になります
• パッケージの場合、起票先アプリがパッケージに含まれていないと書き出せません。含まれていれば、導入後は「導入した新しいアプリ」同士で正しくつながります

サンプルで試す

アプリストアのパッケージ「勤怠」には、この機能を使った「勤続年数に応じた休暇の自動付与（出勤率チェック付き）」が最初から組み込まれています。社員マスタの入社日を起点に、6 か月後から毎年、法定の日数と有効期限で台帳へ自動起票し、出勤率が基準に満たない社員はその回を見送ります。集計（出勤率）はデータ側の項目として持ち、ルールは普通の項目条件で判定する、という組み立て方の実例になっています。

スケジュール起票は AI エージェント連携 (MCP) からも設定できます (settings:scheduled_rules を許可したトークンが必要です)。 AI から設定する場合も、画面と同じ保存前の検証・実行名義の権限確認・プランの制限を通ります。 残高設定が自動で作った失効の起票ルールは、AI からは編集も削除もできません (正本は残高設定側です)。

関連機能

• アクション — 人がボタンを押して他アプリへ転記する
• 通知 — 未登録チェック（あるはずのレコードが無いことを日次で検知して知らせる）
• データパイプライン — 集計結果をレコードとして書き出す