diff --git a/Pleasanter/健康診断管理/docs/n8n/design-fixed-menu.md b/Pleasanter/健康診断管理/docs/n8n/design-fixed-menu.md
index c3ee696c..26485fd5 100644
--- a/Pleasanter/健康診断管理/docs/n8n/design-fixed-menu.md
+++ b/Pleasanter/健康診断管理/docs/n8n/design-fixed-menu.md
@@ -1748,3 +1748,24 @@ Process定義の`DataChanges`側に予約済みの参照が無いか（列は未
 参照だけ持っているケース）を事前に確認すべきだった。同種の作業（新規カウンタ列追加）を
 行う際は、対象サイトの全Processの`DataChanges`を横断検索し、候補の列名が使用されて
 いないことを確認してから採番すること。
+
+### Process4のValidateInputsは無くても入力漏れは構造的に起きない（確認・2026-09-12）
+
+Process5（日程通知）に`ValidateInputs`が一切設定されていない件（前節参照）を受け、ユーザーが
+Process4（検査機関確定）へ検査機関・候補日・コース・ClassAの4項目を`ValidateInputs`として
+追加した。ExecutionType:20（「作成または更新」で自動実行）のProcessでは入力検証タブが
+処理されない可能性がある（本ファイル578行目の既存記載）ため、この対応が実際に効くか
+懸念したが、調査の結果**そもそも別の仕組みで既に担保されていた**ことが判明:
+
+1. ServerScript「検査機関確定準備完了同期スクリプト.js」（`BeforeCreate`/`BeforeUpdate`）が
+   レコード保存の都度走り、`Class003`（検査機関）・`Date001`（候補日）・`Class004`（コース）
+   の3項目が全部値ありの場合のみ`CheckC`（日程情報入力済）をtrueにセットする
+2. Process4の条件タブ（`View.ColumnFilterHash`）は`{"CheckC":"true"}`——CheckCがtrueの
+   レコードにしか発火しない
+3. Process5はStatus=260からのみ実行可能で、260になる経路はProcess4（自動実行）のみ
+
+つまり「CheckCがtrueになる＝3項目が既に揃っている」ことをServerScriptが保証しているため、
+Process4通過（250→260）・Process5実行いずれの時点でも3項目の入力漏れは構造的に発生しない。
+Process4への`ValidateInputs`追加は無害な保険だが、無くても元から安全だった設計と確認できた
+（本節の検証自体は実機テストせず、既存ドキュメント記載の仕組みの読み合わせのみで完了・
+ユーザー了承済み）。