10. システムの一日・一年

板倉製作所のシステムは、人が意識しない時間帯にも動いている。夜間バックアップ、朝イチの異常検知メール連鎖、出荷担当者の操作そのものがトリガーになる帳票メール——これが「システムの一日」。そして受注・出荷・支払は年間・月内・週内で明確なリズムを持つ——これが「板倉の一年」。どちらも実運用ログとAS/400実データ7年分に基づく。

A1. システムの一日 — 01:30〜23:00タイムテーブル

Windowsタスクスケジューラが起動する6本の日次バッチ（SCD_DAILY_*.bat）が、1日の情報系の骨格をなす。加えて、メール送信エンジン自体が「常駐して3分おきに自分を再起動する」独立ループを持つため、バッチの起動時刻＝メール到着時刻ではない点に注意（A2節・A6節で詳述）。時刻は(出典: メール本文フォルダの実運用ログ 2026-06-04〜06-11)による観測時刻。

01:30 AS400マスタ全量バックアップ(52ファイル)開始
02:30 メール送信エンジン、自己終了（夜間停止帯の開始）
02:40 勤怠時刻データ転送 本文ファイル生成（送信は04:05以降）
04:05 メール送信エンジン強制再起動（滞留分を一斉送信）
05:00 管理資料棚卸し3本
06:30 19ジョブ連鎖（15秒間隔）— 実送信06:32〜07:22頃
08:10 出勤入力漏れ確認 → 09:10 再送 → 10:10 再送（計3波）
08:09〜18:16 品番紙データ送信／組付指示書発行（イベント駆動、1日30回超も）
月曜12:10 週次: 時間外労働集計結果(全社)＋カレンダー入力確認
19:00 AS_SRC_List.xlsm（ソース一覧追加）
23:00 AS400ソースファイルリスト作成（1900と別プログラム）

A2. 夜間バックアップと「情報系の停止帯」

この2段階の構造（自動実行PCのローカルディスク→サーバーへmove）は、2016年のアーキテクチャ変更が今も効いている結果である。AS400転送設定/使用停止_2016_07_21.txtによれば、当初はサーバーへ直接データ転送していたが速度低下のため現行の2段階方式に変更された(出典: AS400転送設定/使用停止_2016_07_21.txt)。

A3. 06:30の19本連鎖 — 朝イチの異常検知

06:30の19本チェーンが「朝イチの異常検知の本丸」。試作/号口の納期遅れ、型費重複、在庫過剰引当、伝票番号未入力等、ほぼ全ての業務エラー検知メールがここに集中している。15秒間隔で順次起動するため、実際の到着は06:32〜07:22頃まで幅がある（各ジョブの処理時間分だけ後ろにずれるため）。朝一番でこれらのメールを一括確認する運用フローが前提になっていると考えられる推測。

A3b. Soumu7 — 勤怠・お弁当システムの正体 【ヒアリングで判明】【実VBAで解明】

A3節で「未解明」としていた勤怠時刻データ転送（02:40台・08:05台の2回生成）と本日のお弁当申込み表メール送付（08:25台）のトリガーは、新實さんへの追加確認で解けた。新實さん: 「Soumu7（PC） 勤怠の入力用に使用しているPCが起動元です。Soumu7に勤怠のデータおよびお弁当の注文の有無のデータを一時保管し、Server2へデータを転送しています。」——つまりスケジュールタスク/共有フォルダをいくら探しても見つからなかったのは道理で、これらのジョブはServer2側ではなくSoumu7というPC自身のローカルWindowsタスクスケジューラに登録されている、全く別系統のジョブ群だった。新實さんはSoumu7のC:\soumu\フォルダのソース一式（Excel/VBAマクロ13本・起動用bat 5本・Windowsタスクスケジューラのエクスポート）をまるごと送付してくれ、これをsource/labor/勤怠管理-as400settei/に格納・解析した(出典: 新實さん、2026-07-22回答、docs/feedback/analysis/2026-07-22-niimi-soumu7-reply.md参照)。

Task_Export/には他に4本のXMLがあり、Soumu7が勤怠・お弁当以外にも複数の役割を持つことがわかる: 勤怠時刻入力.xmlはLogonTrigger（ユーザーITAKURA\Soumuのログオン時に入力ツールを自動起動する想定だが、エクスポート時点ではSettings>Enabled=falseで無効化されておりデスクトップの勤怠時刻入力 - ショートカット.lnkからの手動起動に置き換わっている可能性がある推測）、勤怠時刻入力自動再起動.xmlは週次（月〜金、10:05、同じくEnabled=false）で入力ツールの保存込み再起動、お弁当発注データ転送.xmlは毎月15日03:30（Enabled=true、12ヶ月すべてに設定）に発注データの月次アーカイブを実行する。最後のIS_Startup.xml（04:00、daily、Command=\\SERVER2\Common\Settei\Startup\IS_Startup.bat）はA13節で既出の全PC一斉設定プッシュ機構がSoumu7にも登録されている確認だが、このSoumu7上の登録はエクスポート時点でEnabled=falseだった（サーバー側や他PCでの稼働まで否定するものではない）。

勤怠時刻データ転送.xlsm — 何をどこへ運ぶか

実VBA（modMain_603、Sub Main）を読むと、このマクロ自体はメールを送らない。処理は次の順序: ①Server2へのPing疎通確認→②入力元の勤怠時刻入力.xlsm「データ」シートを走査し、G列（退勤時刻）が入力済みの行だけを対象に、まずローカルの履歴ファイル勤怠時刻実データ.xlsxへ丸ごとコピー→③同じ行を転送先の勤怠データ.xlsx（File_Path_Masterで解決される共有パス＝Server2側）へ移動——B列（社員名）と同名のシートがなければ「原紙」シートを複製して新規作成し、そこへ書き込んでから元データを削除する（＝社員1人につき1シートが積み上がっていく設計）。④最後に、その日より前の日付なのにG列が空欄のまま残っている行（＝退勤処理を忘れた社員）を拾い出し、「退勤処理を忘れた社員がいます」という本文を組み立てる。ここで実際に送信されるわけではなく、A6節で解説した「メール本文フォルダに書き出すだけ」の間接送信方式と全く同じ形式（1行目=プログラム名、2行目=件名、3行目=本文…）でファイルをFolder_メール定期自動送信\メール本文へ保存して終わる——Soumu7上のこのマクロも、既に解明済みの3分おきメール送信エンジンに乗っかっているだけだったことが確定した(出典: 勤怠時刻データ転送.xlsm VBA modMain_603.Main)。

勤怠管理マスタ更新.xlsm（02:20起動、転送より20分前）は処理概要コメントに「勤怠管理マスタ.xlsxのマスタシートを勤怠時刻入力.xlsmのマスタシートにコピーする。カレンダーを更新する。定時刻変更を反映する。」とあり、当初の推測どおり先にマスタと稼働日カレンダーを最新化してから02:40の転送を走らせる、前工程であることが確認できた(出典: 勤怠管理マスタ更新.xlsm VBA冒頭コメント)。

本日のお弁当申込み表メール送付.xlsm — 出勤簿とお弁当注文の突き合わせ

こちらも同じ間接送信方式で、modMain_603.Mainが本体。①Server2 Ping確認→②Kyujitu_Judge(Date)で会社休日なら即終了（この関数はB6節で既出のCLMP.xlsをローカルにキャッシュしたClmp.xls/コピーClmp.xlsを検索する——サイト内で既に確認済みのclmpカレンダーマスタが、ここでも稼働日判定の一次情報源として使われていることの追加確認）→③勤怠時刻入力.xlsmの「マスタ」シートから在籍者（入社日以前・退職日以後を除外）を拾い、2025-02-19に追加された「社内表記」（長い氏名対策のエイリアス）で表示名を作る→④当日出勤している人は空欄、それ以外は「不在」をデフォルト表示にしつつ、⑤「弁当注文」シートの当日分で○（いる）／×（いらない）が入力されていれば不在表示より注文データを優先して上書きする、という順序で1枚の申込み表（添付ファイル本日のお弁当申込み表.xlsx）を組み立てる。土曜日かつ翌日曜日が稼働日の場合は、同じ実行の中で「明日の分」も追加で作る——日曜稼働日には別途Soumu7上でこのジョブを起動するタスクスケジューラ登録が無いため、前日の土曜にまとめて先読み生成する設計になっている(出典: 本日のお弁当申込み表メール送付.xlsm VBA modMain_603.Main・本日のお弁当申込み表作成)。

実データ本日のお弁当申込み表/本日のお弁当申込み表.xlsx（2018-06-20時点のスナップショット）でも「社員コード／社員名／申込み」の3列構成、○＝注文あり／－＝不要、34名を超えた分がE〜G列に折り返す様子がVBAロジックどおりに確認できた。

SCD_D_KINTAI_COPY — Soumu8から勤怠バックアップを中継する仕組み 【実VBAで解明】

Soumu7自身のタスクスケジューラとは別に、Soumu8側にも勤怠関連のジョブが1本登録されていることが判明した。SCD_D_KINTAI_COPY.xlsm（2018-07-27作成）は、Server2とSoumu7の両方へPing疎通確認したうえで、その場で1行だけの一時バッチstart /w \\SERVER2\Soumu_C2\労務管理\勤怠時刻入力バックアップ.xlsmを生成・実行し、完了を待つだけの薄い中継ジョブ。実体（勤怠時刻入力バックアップ.xlsm）はServer2側の労務管理共有フォルダにあり、Soumu7・Soumu8のどちらでもなくServer2上で実行される。呼び出し元のSCD_D_KINTAI_COPY.batはSoumu8のWindowsタスクスケジューラに1日9回（02:00・08:20・09:20・15:40・16:40・17:40・18:40・19:40・20:40）別々に登録されており、休日スキップのKyujitu_Judgeチェックはコメントアウトされている（＝休日も含め毎日実行）。A3b冒頭で解明した「勤怠時刻データ転送」（Soumu7ローカル起動、02:40・08:05の1日2回）とは別系統・別目的——あちらは退勤済みデータをServer2の恒久データへ移す処理、こちらは勤怠入力ツール自体の状態を1日9回バックアップする処理と考えられる推測。(出典: source/as400-admin/soumu8-scd-job/SCD_D_KINTAI_COPY.xlsm VBA modMain_600.Main、source/as400-admin/soumu8-scd-job/Task/勤怠時刻入力バックアップ_0200.xmlほか計9本、いずれもCommandはC:\SCD_JOB\SCD_D_KINTAI_COPY.bat)

A4. 出勤入力漏れ確認の3連発（08:10/09:10/10:10）

A5. イベント駆動メール — 品番紙・組付指示書

品番紙・組付指示書系メールは「バッチ」ではなく「業務操作のトリガー」。SCD_DAILY_*.batのどれにも出てこないにもかかわらず、1日に30回以上生成される実データがある。つまり出荷指示書/組付指示書を発行する担当者（EIGYOU26/EIGYOU29のPCを使う営業担当）の操作そのものが、直接メール本文ファイルを生成するトリガーになっている。定時バッチの読み方だけでは、この種の帳票運用は見えない。

(出典: 実運用ログ 2026-06-04〜06-11、MailingList.xlsx)

A6. 自動メールの全体像（57プログラム）

各業務プログラム（オフコン連携Excel/VBA）はメールを直接送らず、「メール本文」フォルダにyyyymmddhhmmss_プログラム名.xlsxという本文ファイル（1行目=プログラム名/検索キー、2行目=件名、3行目=本文、4行目=添付ファイルフルパス、5行目=送信PC、6行目=送信ユーザー）を書き出すだけ。別プロセス定期実行（メール自動送信）.xlsmが3分おきにこのフォルダを走査し、MailingList.xlsx（プログラム名×宛先マスタ57件）を引いて宛先を解決し実送信する(出典: 自動送信メールのプログラム変更覚書.txt)。【実VBAで解明】3分おきの正体は独立したWindowsタスクスケジューラ登録ではなく、VBA内のApplication.OnTime自己再スケジュールループであることが実ソースで確認できた——詳細な仕組みと「04:05再起動」claimの訂正はA2節参照。

送信元PC名から部署が読み取れる推測（フォルダパスとの整合性から）:

外部宛先（社外）は今回の一次資料からは1件も確認できなかった——自動メールはすべてitakurass.co.jpドメイン内の個人宛。唯一の外部データ往来は逆方向（受信）で、デンソープレステック社から「定期部品発注指示書」「変更部品発注指示書」が毎朝8:30頃、古橋花奈氏1名宛（Cc:デンソー社員2名）に届き、DNKデータ処理配下のExcelマクロで取り込まれるEDI的フロー(出典: DNKデータ処理/_デンソープレステック発信情報_定期部品発注指示書.msgヘッダ)。

【ヒアリングで判明】この受信フローは見かけ上「古橋花奈氏1名宛」だが、単一障害点ではないことが確認された。新實さん: 「古橋以外数名処理はできる。端末は限られるので、Windowsパスワードを数名が知っている状態」——処理できる担当者は複数名おり、対応可能な端末が限られる分をWindowsログインパスワードの共有で補っている、という体制。(出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

A7. 新實さんBcc集中 — 引き継ぎ検討事項

A8. 週次・月次処理（毎週月曜12:10 ほか）

A9. 帳票の物理動線 — プリンタ／保存先マップ

プリンタの物理配置

「事務所伝票専用」機の存在は、出荷指示書・品番紙・組付指示書のような伝票類が汎用コピー機と分離した専用機で常時出力される運用を示唆する推測(出典: Printer_List.xlsx)。

【ヒアリングで判明】新實さん: 「社内で稼働しているプリンタは他にもあるが、AS400からの出力で指定しているプリンタはその2台」——社内には他にも稼働中のプリンタがあるが、AS/400からの出力先として指定されているのはIMC5500F・PC6010Mの2台のみであることが確認された（上表の「未使用フラグ」判定と一致）(出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)。

帳票アーカイブへのショートカット（印刷のみ・メール化されていない帳票）

印刷記録/フォルダには5つの.lnkショートカットが置かれ、いずれも\\SERVER2\KANRI\AS400\配下の圧縮サブフォルダを指す。ショートカット名がそのまま帳票名になっている:

• 試作作業指示データ修正リスト
• 組付部品引当在庫の引継ぎ指示書
• 組付部品引当在庫の分納引継ぎ指示書
• 中止・数量変更・納期変更連絡書（新實さんの回答では「受注内容変更連絡書」——ショートカット名からの推定名称と実際の帳票名の食い違いとみられ、同一帳票の別名である可能性が高い。断定はしない） 【実業務手順書で解明】同一帳票の別名ではなく、別の2つの文書だった。「中止・数量変更・納期変更連絡書」は、中止・数量変更・納期変更の連絡が現場に届いた際に手作業で回覧される入力側のトリガー文書——作業手順書（Ｅ－００）〜（Ｅ－１３）の各手順は例外なく「この作業は『中止・数量変更・納期変更連絡書』が回ってきた時、常に行ってください」で始まり、末尾に処理済みチェック欄と回覧順の記入欄を持つ紙の連絡票で、これを受けて１６．受注データ修正（ITJM38R）や１０．試作管理→６．試作作業指示変更（ITTS22R）などのAS/400画面操作を行う。一方、本節のショートカット名「受注内容変更連絡書」（フォルダ作業指示書発行２\受注内容変更連絡書）は、その受注データ修正（JSBS16／ITJM38R）が完了した際にAS/400側が自動的に印刷する出力側の記録（BAT0116／BAT0116A、変更件数KENSU>0で発行）であり、入力トリガーとは別物である。つまり同一ワークフロー上の「入口（紙で回ってくる連絡票）」と「出口（システムが吐く変更記録）」という別役割の2文書。(出典: source/work-procedures/作業手順書/（Ｅ）　受注状況の変更/（Ｅ－００）　オフコン変更処理.doc・（Ｅ－０２）　単品出荷品の中止処理.doc等参照、order.html JSBS16/ITJM38R節のBAT0116/BAT0116A記述参照)
• 部品在庫引当の自動変更結果

5件ともMailingList.xlsxに対応キーがなく（メール化されていない、印刷のみの帳票）、唯一「試作作業指示データ修正リスト印刷」だけ「仮出庫が取り消しになった場合メール」という条件付き送信がMailingList.xlsxにある(出典: 印刷記録/*.lnkバイナリ解析、MailingList.xlsx30行目)。

【ヒアリングで判明】8.3圧縮形式で読み取れなかったサブフォルダの実パスと、確認者の有無が新實さんの回答で判明しました。5帳票は作業指示書発行２と組付指示書発行（いずれもsource/production/配下に実在する部署フォルダ）の2系統に分かれます:

• \\Server2\kanri\AS400設定\作業指示書発行２\試作作業指示データ修正リスト
• \\Server2\kanri\AS400設定\組付指示書発行\組付部品引当在庫の引継ぎ指示書
• \\Server2\kanri\AS400設定\組付指示書発行\組付部品引当在庫の分納引継ぎ指示書
• \\Server2\kanri\AS400設定\作業指示書発行２\受注内容変更連絡書
• \\Server2\kanri\AS400設定\組付指示書発行\部品在庫引当の自動変更結果

確認者については新實さん: 「いずれも保管するのみで、確認者はいません。保管処理と同じタイミングで印刷します。紛失の場合や「もらった、もらっていない」の時のために保管しているだけです。」——5帳票とも能動的な確認者はおらず、紛失・授受トラブル時の証跡として保管されているだけと確定しました。 (出典: 新實さん、2026-07-22回答、docs/feedback/analysis/2026-07-22-niimi-remaining-A-questions-reply.md参照)

ファイルサーバー上の帳票保存先（抜粋）

見積書は「見積書発行」（現行）と「Old_Data」（旧アーカイブ）の2系統、請求書は「請求書発行」（AS400設定側=出力生成）と「Soumu_C2\経理」（総務経理側=原紙保管・照合結果）の2系統に分離されている。「システムが吐き出す場所」と「経理担当者が受け取って保管照合する場所」が意図的に分けられていると考えられる推測。

すべての自動メール添付ファイルは送信前に\\SERVER2\Kanri\AS400設定\メール定期自動送信\添付ファイル\へ一時生成され、送信後は7日間保管ののち削除される。つまりこのフォルダは「直近1週間分の全自動送信帳票のスナップショット」として機能する、事実上の監査ログ。

A10. 現場の入口 — メインメニューの起動の仕組み 【実VBAで解明】

デスクトップの「メインメニュー」アイコンは、実は本体ではなく2秒で消える中継ファイル。メインメニュー/メインメニュー.xlsm（53.6KB）を実際にVBA解析すると、中身はServer_Path_Setで共有パスを組み立てたあと000_000_000_メインメニュー.xlsm（本体、104.4KB）をマクロ実行つきで開き、自分自身は即座に閉じるだけの薄いスタブだった。デスクトップショートカットが軽量な中継ブックを指しておき、本体は毎回サーバー上の最新版が開かれる——各PCへの配布・更新作業が要らない設計(出典: メインメニュー.xlsm VBA modMain_600: File_Open(Data_Path, DATA_FILE, False, True) → Quit_Or_Close)。

権限もこの中継地点で強制される。リストの「使用制限」欄に部署名（例:「見積担当者」「経理担当者」）があると、ボタンを押した瞬間にPass_Check→Win_User_Powers_GetがSoumu_Admin_List.xlsxをログインユーザー名（Environ("USERNAME")）で検索し、リストに無ければ「このオプションの使用権限がありません。」で処理を止める。開く直前には毎回Zoom_ChangeがSize_To_Zoom.xlsx（解像度→ズーム％の対応表。1024×768〜1920×1080の5解像度に対応）を参照して画面ズームを自動調整する——どのPC・どのモニタ解像度でも同じ見た目でメニューが開くようにする、地味だが徹底した配慮(出典: modMenu_604のPass_Check/Zoom_Change、Size_To_Zoom.xlsx)。

A11. 共通アドイン — 経理インボイス色分けと汎用マクロ 【実VBAで解明】

共通様式/には現品票（A4/A5の2サイズ、品番・入出庫履歴・棚番を記録する現場の物理タグ）が1件のみ。Excel_Addin_Backup/の3アドインをVBA解析すると、AS/400連携用ではなく個人の作業効率化ツールだった。

A12. ITA_PGM — クライアント側エラー通知と実行ログの心臓部 【実VBAで解明】

各クライアントPCのC:\ITA_PGM\は「AS/400↔Excel連携が壊れた時に何が起きるか」を一手に引き受ける場所だった。readme ITA_PGM.txt（2005年作成）によれば、AS/400のCLプログラムがサーバー上のExcelマクロを直接呼ぶと、ネットワーク障害時にエラーも出さず黙って終了してしまう問題があったため、必ずFile_Op.batを経由させる設計にした——CLプログラム側は常に同じバッチファイルを呼べばよく、Excel側のマクロを変更しても各クライアントの設定変更が不要になる、という意図的な間接化である(出典: readme ITA_PGM.txt)。

ここでVBAを追うと、Err_Msg.xlsmのAuto_OpenはErr_Proc_Name.txtを読み取り、Rec_ResultでローカルのC:\ITA_PGM\自動実行結果記録.xlsxに「失敗」を記録し、同時に\\Server2\Kanri\AS400設定\共用\エラー監視\フォルダへタイムスタンプ付きでログをコピーしたあと、「エラーが発生しました。オフコンからの処理を継続できません。このままの状態で社内のコンピュータ管理者に連絡してください。」というダイアログを表示する(出典: Err_Msg.xlsm VBA Sub Main: Err_File = ThisWorkbook.Path & "\Err_Proc_Name.txt"、Rec_Result(Err_Name, False, 1))。「社内のコンピュータ管理者」に連絡させるこの導線は、A7節で確認した「新實さんBcc集中」構造とクライアント側でも一致する——サーバー側の異常検知メールもクライアント側のAS/400接続エラーも、最終的に同じ1人に集約される設計思想が徹底している推測。

自動実行結果記録.xlsx自体はRec_Result共通ルーチン（modRecoed_603、AS400再編成やError_Mail系ツールなど複数のマクロから共有）が呼ばれるたびに1行追記される「実行成功／失敗の飛行記録装置」。今回読み取れたローカルコピーの実データ3行には請求書作成（範囲指定）.xlsmと本日のお弁当申込み確認.xlsmに混じってBAT0362.xlsmという正体不明の汎用名の成功ログがあり、A節末尾で既出のBAT0726.xlsm（用途不明）と同じ「意味のない番号名バッチ」パターンがもう1件見つかった(出典: ITA_PGM/自動実行結果記録.xlsx実データ3行、2026-06-11 08:25〜09:10、ユーザーkniinomi／PCSOUMU5)。

【ヒアリングで判明】BAT0362.xlsmの正体は、新實さんへの確認により請求書出力パイプラインの一部であることが判明した。実際の経路はAS400 SSBS62→SSCB62C→ITS001R→BAT0362→BAT0362.xlsm→請求書作成（範囲指定）.xlsm——つまりBAT0362.xlsmは正体不明の汎用名バッチではなく、請求書（インボイス）生成パイプラインの中間ステップである。請求書作成（範囲指定）.xlsmと同じログに並んで記録されていたのも、同一パイプラインの前後工程だったためと整合する。(出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

ITA_PGM/WorkSpace/（122ファイル）は、この連携の実データ置き場——60種類以上のAS/400物理ファイル（プレフィックスBHMP/BJDP/JHMP/JUDP/KFDP/KMDP/KSMP/NJDP/SFDP/SHDP/SJDP/SJXP/SNMP/TNDP等）のローカルミラーが、それぞれ.FDF（転送定義）と.xls（実データ）のペアで並ぶ。BHMP.xlsは14.6MB、JHMP.xlsは8.5MB、SNMP.xlsは4.9MBと、単なる作業用一時ファイルにしては大きく、複数の部署別Excel入力ツールが共有する「PC-AS/400間の中間バッファ」として日常的に肥大化しているとみられる推測。構成表入力用ブック.xlsm（と原本の_Base版）はITA_PGM直下の構成データExcel入力.xlsxと対の入力ツールで、BOM（構成表）データの投入もこの仕組みを使っている。

A13. 受注まとめ入力 — 現場が書いたSOPを読む 【実VBAで解明】

ITA_PGM/受注まとめ入力の手順と注意点.xlsxは、担当者向けに書かれた5ステップの実務手順書だった。AS/400メニュー番号53〜57が、それぞれ専用のExcelツールを起動する形で1本の処理パイプラインを構成している——これはAS/400の一件ずつ入力するグリーン画面をバイパスし、Excelでまとめて複数件を先に入力してから一括でAS/400へ流し込む「バルク受注登録」の仕組みである。

A14. AS400再編成 — 日次・週次ではなく年次の自動棚卸し 【実VBAで解明】【ヒアリングで一部訂正】

AS400再編成/の4ファイルは、スケジュールタスク/配下のSCD_DAILY/SCD_WEEKLYのどの.batからも呼ばれていない——そのためSCD_DAILY/SCD_WEEKLYの自動連鎖には含まれない、手動起動のメンテナンスツール群だと推測していた。【ヒアリングで判明】実際には手動起動ではなく自動化されている。新實さん: 「SCD_Y_07SUN2.bat は同じ方法で年1回7月の第2日曜日に実行」——A3節で解説した06:30の日次連鎖（Windowsタスクスケジューラ起動）と同じ仕組みで、日次ではなく年1回（7月第2日曜日）のスケジュールとして登録されている別系統だった。SCD_Y_07SUN2.batがAS400_OLD_DATA_TP.xlsmを、SCD_Y_07SUN2_0500.batがOLD_JUDP_ADD_ALL_JUDP.xlsmを同様の年次スケジュールで実行する。「タスクスケジューラは現在Soumu8のPCにセット」「実行するバッチファイル、ExcelマクロもSoumu8に保存」——SCD_DAILY/SCD_WEEKLYの連鎖解析にこの2本が出てこなかったのは、手動運用だったからではなく、単に別のPC（Soumu8）上の別のタスクスケジューラ登録（年次）だったため、という説明が正しい（名前が似た「LogFile再編成実行.xlsm」はA3節の06:30連鎖に含まれる別物で、混同注意）。(出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

【実VBAで解明】ヒアリング回答と独立に、Soumu8の実ソース(SCD_Y_07SUN2.xlsm・SCD_Y_07SUN2_0500.xlsm)からも同じ結論を裏付けられた。両ファイルとも他のSCD_D_*ラッパーと同型のmodMain_600構造を持ち、それぞれAS400_OLD_DATA_TP.xlsm・OLD_JUDP_ADD_ALL_JUDP.xlsmをJOB_FILEとして起動する——ここまでは新實さんの回答通り。加えて実ソースだけが明かす点として、この2本の休日判定は他のSCD_D_*と逆になっている: 通常はIf Kyujitu_Judge(Date) Then（休日なら中止）だが、年次再編成の2本はIf Not Kyujitu_Judge(Date) Then（休日でなければ中止）——つまり「7月第2日曜日」が万一何らかの理由で稼働日扱いになっていた場合は自動的にスキップされる、休日限定実行のガードが明示的にコードされている。(出典: source/as400-admin/soumu8-scd-job/SCD_Y_07SUN2.xlsm・SCD_Y_07SUN2_0500.xlsm VBA modMain_600.Main)

AS400_OLD_DATA_TP.xlsm（タイトル「ＡＳ４００データベース再編成」）は、AS/400側で古くなった（＝オフコンの物理ファイルから間引かれる）受注データをCWBTF経由でExcelへ転送し、指定列の不要行を削除したうえで処理日を付加したファイル名にリネームし、\\Server2\Kanri\AS_OLD_DATA\yyyymmdd\という日付フォルダへ格納する。エラー時はA12節と同じRec_Result／メール本文書き出しの仕組みで通知される(出典: AS400_OLD_DATA_TP.xlsm VBA modMain_600)。

もう一段面白いのはOLD_JUDP_ADD_ALL_JUDP.xlsmで、コード内コメントの新規作成日が24/07/24（2024年7月24日）——比較的最近に追加されたツールだった。処理概要には「AS400の受注データから再編成された旧データをALL_JUDP.xlsxに追加する」とあり、使用制限として「AS400の再編成と同一日での処理を前提にしているので、違う日の実行はエラーになる」と明記されている。つまり①AS/400側でオフコン管理者が受注データの物理再編成（不要領域の回収）を実行→②同じ日のうちにAS400_OLD_DATA_TP.xlsmで退避データをExcel化→③さらに同日中にOLD_JUDP_ADD_ALL_JUDP.xlsmで恒久アーカイブALL_JUDP.xlsxへ追記という3ステップで「消される前に歴史を保存する」棚卸しが行われている。手動3ステップの「儀式」が今も続いていることが分かる推測——2024年に新規ツールが作られたことは、この儀式が過去の遺物ではなく現役の運用であることの証拠でもある。【ヒアリングで判明】上記の通りこの3ステップは「儀式」的な手動作業ではなく、SCD_Y_07SUN2.bat／SCD_Y_07SUN2_0500.batによる年1回（7月第2日曜日）のタスクスケジューラ自動実行として組み込まれている。ただし「2024年に新規ツールが追加された」という事実そのもの——コード内コメントの新規作成日24/07/24——は今回のヒアリングとは独立に検証済みの根拠であり、この年次自動棚卸しが過去の遺物ではなく現役で運用されていることを裏付ける点は変わらず有効(出典: OLD_JUDP_ADD_ALL_JUDP.xlsm VBA modMain冒頭コメント、新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)。日付入り旧版AS400データ再編成処理_20100914.xls／_20130711.xlsは、この棚卸し作業が2010年代から続く長期運用であることを示す考古学的な痕跡と考えられる推測。

B1. 一年のリズム — 繁忙期・閑散期

ここからは実データ7年分（judp受注/出荷, sjdp製造指示, shdp支払, clmp/dcmp稼働日カレンダー, tkmp得意先マスタ）の分析。分析窓は2019〜2025年（7完全年）、ガベージ日付は除外（judpで126行・0.28%除外）(出典: SQL Appendix 0節)。

繁忙期は7〜9月（受注/稼働日が26.4・24.8・25.8と突出）。閑散期は11月〜1月（17.2〜19.2）。5月は稼働日数自体が少ない（GW影響で18.0日）にもかかわらず出荷/稼働日が22.6と月間トップ級で、GW前の駆け込み出荷が起きていることが読み取れる推測。10月は出荷/稼働日20.8で2位——多くの得意先の上期末（9月）決算後の下期立ち上がり出荷の可能性推測。

支払金額（shdp発生月ベース）は受注量から約1〜2ヶ月遅れて連動しているように見える（7〜9月の受注ピーク→7月・9月・12月の支払ピーク）。12月は最大値が突出（月間2,430万円）しており、年末に大口の支払・仕入決済が集中する年がある推測・要確認。

B2. 一月のリズム — 月末受注集中と出荷の平準化

得意先マスタtk1p140件の94%が月末締め。これと符合し、受注入力日（jujuhi）は25〜28日に明確に集中している——26日が突出して3,391件（全期間中最多、月平均日の約3.4倍）(出典: SQL Appendix 2a節)。

一方、出荷実績日（junohi）は受注ほど極端な集中がなく、月末31日はむしろ少ない。受注は月末に集中するが、出荷は月内に平準化されている——受注の月末集中を生産計画側が緩衝している可能性推測。製造指示書発行日・出荷納期にも大きな偏りはなく、むしろ月末（29〜31日）の出荷納期設定は明確に少ない——納期を月末より前倒しする実務判断とみられる推測。

B3. 一週間のリズム — 火曜受注・水曜出荷

受注は火曜、出荷は水曜がピーク。木・金にかけて両方とも減少し、週前半（月〜水）に業務が寄っている——週末に向けて出荷を終わらせる／週明けに新規受注をまとめて処理するパターンと考えられる推測。

B4. 年間稼働日と土曜稼働の実態

年間稼働日は毎年243〜245日で安定（週5日勤務＋祝日休みのモデルとほぼ一致）。2019年に1回だけ土曜稼働があった以外、7年間で土曜出勤はゼロ、日曜は7年間で1件も稼働日フラグが立っていない——板倉は完全週休二日制で運用されている（カレンダー上は）。なお受注・出荷が非稼働日（土日祝）に計上されているケースが受注4件・出荷48件あり、出荷側が受注側の12倍あるのは「実際の出庫日を週明けにまとめて遡及入力している」可能性を示唆推測・要確認。

B5. 7年トレンド — 得意先構成の地殻変動

最大の構造変化: 従来の最大顧客「デンソープレステ」（コード20、デンソー系）が2019年比-32%で縮小する一方、「トヨタ紡織」（コード5000）が+120%で急成長し、件数ベースでほぼ肩を並べる規模に（2025年は20:1,605件 vs 5000:1,633件で逆転）。主要取引先がデンソー系からトヨタ紡織系へシフトしつつある推測・要確認（商品構成や単価も含めた実質的な売上シフトかは要検証）。

アイシン系グループ内でも明暗が分かれている——アイシンシロキ・アイシン新豊は激減する一方、アイシン試作工場・アイシン新川は急拡大しており、アイシングループ内での発注元の再編が起きている可能性がある推測。エクセディは2022年以降注文ゼロ（取引終了とみられる）、逆に浅野静岡が2025年に突然132件で新規登場——小口取引先の入れ替わりが継続的に起きている(出典: SQL Appendix 4節、judp.jucdtk × tkmp)。

B6. 「二つのカレンダーの謎」の解消

clmpの方が8年分（1988〜1996年、3,004行）長く歴史を持つ。dcmpが存在しない期間は単純に「無い」だけで、逆（dcmpにあってclmpにない日）は0件——dcmpはclmpの部分集合的な後発カレンダーという関係。

両テーブルに共通する11,688日のうち、稼働日フラグが食い違う日は92日（0.79%）のみ。かつこの92日はすべて2000-04-15〜2019-10-22の間に集中しており、2020年以降は7年間まるまる差分ゼロ。差分の内訳は曜日別で土曜44件・月曜25件・金曜16件が典型（「clmpでは稼働日とされている土曜がdcmpでは休日」という向きが多い）——2000年代〜2010年代の臨時出勤の反映漏れ・運用ラグとみられる推測。

結論: 「2つのカレンダーの謎」は、実データ上は既に解消済みの過去問題——2020年以降は完全に同期している。差分が残っているのはclmpだけが持つ1988〜1996年の歴史データと、2000〜2019年の92日間の運用ラグのみ。現行運用（2020年〜）ではどちらを見ても同じ結果になる(出典: SQL Appendix 5節)。

-- ===== 0. データ健全性チェック =====
SELECT count(*) FILTER (WHERE jujuhi IS NULL OR jujuhi=0) AS null_or_zero,
       count(*) FILTER (WHERE jujuhi IS NOT NULL AND jujuhi<>0 AND (jujuhi<20180101 OR jujuhi>20261231)) AS out_of_window,
       count(*) AS total
FROM judp;

-- ===== 1. 月次リズム =====
-- 1a. 受注 件数/数量 の月別平均(7年)
WITH ym AS (
  SELECT extract(year FROM d)::int yr, extract(month FROM d)::int mo, count(*) c, sum(qty) q
  FROM (SELECT to_date(jujuhi::text,'YYYYMMDD') d, jujusu qty FROM judp WHERE jujuhi BETWEEN 20190101 AND 20251231) t
  GROUP BY 1,2
)
SELECT mo, round(avg(c),1) avg_orders, round(stddev_pop(c),1) sd, min(c), max(c), round(avg(q),0) avg_qty
FROM ym GROUP BY mo ORDER BY mo;

-- 1-2. 稼働日で正規化(受注/出荷 per 稼働日)
SELECT mo,
  round(avg(c_orders)/avg(wd),1) orders_per_wd,
  round(avg(c_ships)/avg(wd),1) ships_per_wd
FROM (
  SELECT o.yr, o.mo, o.c c_orders, s.c c_ships, w.wd
  FROM
   (SELECT extract(year FROM d)::int yr, extract(month FROM d)::int mo, count(*) c
    FROM (SELECT to_date(jujuhi::text,'YYYYMMDD') d FROM judp WHERE jujuhi BETWEEN 20190101 AND 20251231) t GROUP BY 1,2) o
  JOIN
   (SELECT extract(year FROM d)::int yr, extract(month FROM d)::int mo, count(*) c
    FROM (SELECT to_date(junohi::text,'YYYYMMDD') d FROM judp WHERE junohi BETWEEN 20190101 AND 20251231) t GROUP BY 1,2) s
   ON o.yr=s.yr AND o.mo=s.mo
  JOIN
   (SELECT (clymd/10000)::int yr, ((clymd%10000)/100)::int mo, count(*) FILTER (WHERE cld101=0) wd
    FROM clmp WHERE clymd BETWEEN 20190101 AND 20251231 GROUP BY 1,2) w
   ON w.yr=o.yr AND w.mo=o.mo
) x GROUP BY mo ORDER BY mo;

-- 7月スパイク検証
SELECT jucdtk, count(*) FROM judp WHERE jujuhi=20210728 GROUP BY 1 ORDER BY 2 DESC;

-- ===== 2. 月内リズム =====
-- 2a. 受注日 日別分布
SELECT extract(day FROM d)::int dom, count(*) c
FROM (SELECT to_date(jujuhi::text,'YYYYMMDD') d FROM judp WHERE jujuhi BETWEEN 20190101 AND 20251231) t
GROUP BY 1 ORDER BY 1;

-- 2e. 得意先締め日分布
SELECT distinct t1d301, count(*) FROM tk1p GROUP BY 1 ORDER BY 2 DESC;

-- 2f. shdpp1 が空であることの確認
SELECT count(*) FROM shdpp1;

-- ===== 3. 週内リズム =====
-- 3a. 受注 曜日分布
SELECT to_char(d,'Dy') dow, count(*) c
FROM (SELECT to_date(jujuhi::text,'YYYYMMDD') d FROM judp WHERE jujuhi BETWEEN 20190101 AND 20251231) t
GROUP BY 1, extract(isodow FROM d) ORDER BY extract(isodow FROM d);

-- 3c. 年間稼働日数
SELECT (clymd/10000)::int yr, count(*) FILTER (WHERE cld101=0) worked_days, count(*) total_days
FROM clmp WHERE clymd BETWEEN 20190101 AND 20251231 GROUP BY 1 ORDER BY 1;

-- 3d. 土曜稼働
SELECT (clymd/10000)::int yr, count(*) FILTER (WHERE cld101=0) sat_worked, count(*) sat_total
FROM clmp WHERE clyobi='SAT' AND clymd BETWEEN 20190101 AND 20251231 GROUP BY 1 ORDER BY 1;

-- 3e. 非稼働日への計上
SELECT 'orders' kind, count(*) c FROM judp j JOIN clmp c ON c.clymd = j.jujuhi
  WHERE j.jujuhi BETWEEN 20190101 AND 20251231 AND c.cld101=1
UNION ALL
SELECT 'shipments', count(*) FROM judp j JOIN clmp c ON c.clymd = j.junohi
  WHERE j.junohi BETWEEN 20190101 AND 20251231 AND c.cld101=1;

-- ===== 4. 得意先別7年トレンド =====
WITH yearly AS (
  SELECT jucdtk, extract(year FROM to_date(jujuhi::text,'YYYYMMDD'))::int yr, count(*) c, sum(jujusu) q
  FROM judp WHERE jujuhi BETWEEN 20190101 AND 20251231
  GROUP BY 1,2
), tot AS (
  SELECT jucdtk, sum(c) total_c FROM yearly GROUP BY 1 ORDER BY 2 DESC LIMIT 12
)
SELECT t.jucdtk, tk.tknmrj, y.yr, y.c, y.q
FROM yearly y JOIN tot t ON t.jucdtk = y.jucdtk
LEFT JOIN tkmp tk ON tk.tkcdtk = t.jucdtk
ORDER BY t.total_c DESC, y.yr;

-- ===== 5. カレンダー比較 clmp vs dcmp =====
SELECT 'clmp' t, min(clymd), max(clymd), count(*) FROM clmp
UNION ALL SELECT 'dcmp', min(dcymd), max(dcymd), count(*) FROM dcmp;

SELECT (c.clymd/10000)::int yr, count(*) FILTER (WHERE c.cld101<>d.dcd101) diffs
FROM clmp c JOIN dcmp d ON c.clymd=d.dcymd GROUP BY 1 ORDER BY 1;

SELECT c.clyobi, count(*) FROM clmp c JOIN dcmp d ON c.clymd=d.dcymd
  WHERE c.cld101<>d.dcd101 GROUP BY 1 ORDER BY 2 DESC;

-- ===== 参考: リードタイム再確認 (memo記載17日と近似) =====
SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY (to_date(junohi::text,'YYYYMMDD') - to_date(jujuhi::text,'YYYYMMDD')))
FROM judp WHERE jujuhi BETWEEN 20190101 AND 20251231 AND junohi BETWEEN 20190101 AND 20261231 AND junohi >= jujuhi;
-- => median 16日