14. ヒアリングシート

A1 ★★★ 「隠れた業務」はまだ埋もれていないか（MENUR1の再来）

【手がかり】メニュー画面に出ない MENU00 のオプション50から到達する経理管理サブシステム MENUR1 が、2026年7月まで全ての移行棚卸から漏れていました。MENU00 から辿れない到達不能サブシステムは他に31個あり、&INPS=70（MENUU1訂正処理）のような隠しオプションも見つかっています。

【ヒアリングで判明】新實さんは、opt50＝経理のような追加の隠れた現役業務は挙げませんでした。代わりに、到達不能な31サブシステムのうち具体的な13メニュー — MENUMD1/MD2/MD3（削除管理サブシステムD1〜D3）、MENUMQ1/MQ2/MQ3（EXCEL出力サブシステムQ1〜Q3）、MENUMU1/MU2/MU3（変更管理サブシステムU1〜U3）、MENUMW1/MW2/MW3（追加管理サブシステムW1〜W3）、MENUM00（保守管理サブシステム00） — を名指しし、「これらのメニューは作りかけで実際には使っていません」と回答しました。少なくともこのMENUM00配下13メニュー群については、MENUR1のような「隠れているが現役」の再来ではなく、単なる未完成の作りかけと確定しました。 (出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

【ヒアリングで判明・続報】新實さんへ改めて確認したところ「ないと思います」との回答があり、今回提示した13メニュー以外に「メニューに出ないけれど現役で使っている業務」への心当たりは無いと確定しました。セッション34で発見したMENUR1（経理管理）のような「メニュー非表示だが現役」の未発見サブシステムは、顧客の認識上もこれ以上は存在しないとみてよく、A1は完全クローズです。ただし「心当たりが無い」は「存在しないことの証明」ではないため、ソース側の到達可能性解析（analysis/out/edges.csv）による裏取りは引き続き有効な安全網として残します。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（解決済み：今回提示した13メニュー以外に「メニューに出ないけれど現役で使っている業務」への心当たりは無いと確認。「心当たりが無い」は存在しないことの証明ではないため、analysis/out/edges.csvの到達可能性解析による裏取りは安全網として継続するが、追加のヒアリング項目としては残る未解明点なし）

【解けると】移行スコープの取りこぼしを塞げる。 (詳細: masters.html §5 / finance.html)

A2 ★★ 旧メニュー・空メニューは本当に廃止でよいか

【手がかり】(a) MENUM00（変更／追加／削除が別々に分かれた旧マスタ保守メニュー、配下13、末端 MNMD01〜09 はソース自体が無い、呼び出し元0件）。(b) MENUQ1（Query/400直結、F9＝QUERY、9オプション全ラベルが空欄）。(c) MENUA1X0/J1X0/T1X0/T2X0（現行とほぼ同一のバックアップコピー）。(d)「存在しない」と明記されたプログラム3件＋コメントアウト1件。

【ヒアリングで判明】「こちらが正」— MENUM1／MENUM2（現行の保守管理サブシステムメニュー1・2）が正しい現行バージョンであると確認されました。個別のデータファイルを直接操作したい場合は、専用メニューではなくDFU（Data File Utility）で対応しているとのことです。またMENUQ1／MENUQ2のQUERY一覧印刷機能についても「データの件数が多いものは意味がない。今はExcelで出せるので、不要。」と明言され、Excel代替により不要と判断されていることが確認できました。これはA1で判明したMENUM00配下13メニュー（旧・変更／追加／削除の3分割保守メニュー）が「作りかけで実際には使っていません」という回答とも整合し、旧3分割メニューがMENUM1へ統合され切っていることを裏付けます。 (出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

【質問】（解決済み：MENUM1／MENUM2が現行の正しいメニュー、旧3分割保守メニューとMENUQ1／MENUQ2のQUERY一覧印刷機能はいずれも廃止で確定。残る未解明点なし）

【解けると】死んだメニューを追加調査・移行対象から外せる。 (詳細: system-map.html §9 / daily-rhythm.html)

A3 ★★ 現役でない可能性のあるサブシステムは今も動くか（EDI・自動倉庫）

【手がかり】(a) MENUD1（デンソー機工EDI、DSBS04-06／17-19、JUDPDKアップロード）は移植済みだが、本番DBの judpdk テーブルは現在0件。(b) サインオン初期プログラム LL.txt が、ワークステーションID DSP65〜DSP6599999 の端末に限り MENU00 を飛ばして自動倉庫用 MENUZ9（照会4項目＋サインオフ）を直接起動する分岐を持つ。

【ヒアリングで判明】デンソー機工とのEDIデータ交換について「毎日実行。今現在も」と確認されました — judpdkテーブルが現在0件だったのは受信データの保持期間・クリア運用の問題とみられ、EDI自体は現役で稼働し続けています。立体倉庫のDSP65番台専用端末についても「今も稼働している。機能を限定するために別のスタートメニューをデフォルトにしている。」と確認され、LL.txtのサインオン分岐（MENUZ9直接起動）が意図的な現行運用の設計であることが裏付けられました。 (出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

【質問】（解決済み：デンソー機工とのEDIデータ交換は現在も毎日実行、DSP65番台端末も専用スタートメニューにより現役稼働中と確認。残る未解明点なし）

【解けると】EDIと自動倉庫端末の移植要否・優先度が確定。 (詳細: system-map.html §9)

A4 ★★ 自動メールの「宛先空欄」は展開予定か廃止か

【手がかり】「時間外労働集計結果メール送付」の 全社／営業課／工機課／試作課／製造課 の5系統のうち、全社以外の4系統は宛先が空欄。号口指示計算時の設定情報メールは 無印／_G／_S の3系統があり、_G系統だけ宛先が空欄。

【ヒアリングで判明】「時間外労働集計結果メール送付」の課別4系統（営業課／工機課／試作課／製造課）が宛先空欄のままなのは、将来展開待ちではなく廃止済みであることが確認されました。新實さん: 「各部署に限定した内容を送付していたが、どの部署にも全社の内容が送付してほしいということですべて同じものになった。」— 現場からの要望で全部署が全社版の内容に統合され、課別系統は宛先を入れる意味自体がなくなったということです。号口指示計算時の設定情報メールの3系統についても呼称の意味が判明しました: 無印＝「担当にかかわらずすべて」、_S＝「試作部署担当のもの」、_G＝「量産部署担当のもの」。さらに実際のマクロ→送付先の対応も判明しました: 号口指示計算時の設定情報メール送付.xlsm（無印）→三島博之、_S.xlsm→猪股康司、_G.xlsm→宛先空欄。新實さん: 「_Gを担当するものがいない。現在三島が担当している。三島に送られているものに_Gは含まれる。」— _G系統の宛先が空欄なのは担当不在のまま放置されているのではなく、無印（＝「担当にかかわらずすべて」＝三島宛）の送付内容にすでに量産部署（_G）分の内容が含まれているため、別立てで_G宛に送る意味自体がない、という構造上の重複回避であることが確定しました。 (出典: 新實さん、2026-07-22回答、docs/feedback/analysis/2026-07-22-niimi-remaining-A-questions-reply.md参照)

【質問】（解決済み：_G系統の宛先空欄は担当者不在によるものだが、無印＝三島博之宛の送付内容に_G分が包含されているため実質的な欠落ではないと確認。残る未解明点なし）

【解けると】メール移植の要否と3系統分岐の意味が確定。 (詳細: daily-rhythm.html)

A5 ★★ 起動元が辿れない定期メール・ジョブ

【手がかり】(a) 0630.bat の18番目のジョブが BAT0726.xlsm という汎用名で、MailingList.xlsx に対応キーが無い。(b)「勤怠時刻データ転送」が毎日02:40台と08:05台の2回生成されるが、スケジュールタスク/ 配下のどの .bat にもプログラム名が現れない。(c)「本日のお弁当申込み表メール送付」が毎日08:25台に安定送信されるが、6本の .bat のどれにもトリガーが見当たらない。

【ヒアリングで判明】BAT0726.xlsmの正体が判明しました: 「AS400のZSBS26を実行した状態と同じにする」— AS/400側のZSBS26（金型管理マスタ）出力を再現するジョブです。「立体倉庫のDSP65番台専用端末で金型管理マスタ―のExcel出力ファイルを参照するので、1日一回最新の情報に更新している。」とのことで、A3で確認されたDSP65端末の現役稼働とも噛み合い、金型管理マスタの日次更新ジョブという位置づけが確定しました。(b)勤怠時刻データ転送と(c)お弁当申込み表メールのトリガーについては、翌日（2026-07-22）に新實さんから追加回答がありました: 「Soumu7（PC） 勤怠の入力用に使用しているPCが起動元です。Soumu7に勤怠のデータおよびお弁当の注文の有無のデータを一時保管し、Server2へデータを転送しています。」— つまりServer2側のスケジュールタスク/ではなく、勤怠入力専用PC「Soumu7」自身のローカルWindowsタスクスケジューラに別立てで登録されているジョブ群だったため、これまでの.bat調査では見つからなかったのです。あわせて送付されたSoumu7の実ソース一式（VBAマクロ13本・Task Schedulerエクスポート）を解析した結果、「02:40台と08:05台の2回生成」の正体は不具合ではなく、同一の勤怠時刻データ転送.batを指す独立した2本のタスクスケジューラ登録（CalendarTrigger 02:40・08:05）がSoumu7にそのまま存在するためと確定しました。「本日のお弁当申込み表メール送付」も同PCのタスクスケジューラに08:25 CalendarTriggerとして登録されており、観測値と完全に一致します。両プログラムとも実体は既存の「メール本文フォルダに書き出すだけ」の間接送信方式（A6節既出）に乗っており、実際の送信は既知の3分おきメール送信エンジンが担っています。詳細はdaily-rhythm.html A3b節。 (出典: 新實さん、2026-07-21ヒアリングシート回答＋2026-07-22回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md・docs/feedback/analysis/2026-07-22-niimi-soumu7-reply.md参照)

【質問】（解決済み：勤怠時刻データ転送・お弁当申込み表メールとも起動元はSoumu7ローカルのタスクスケジューラと確認。前者が2回生成される理由も同一ジョブへの2本の独立登録と特定。残る未解明点なし）

【解けると】隠れたスケジュールタスクを移植漏れなく拾える。 (詳細: daily-rhythm.html)

A6 ★ デンソープレステック発注指示書メールの単一担当リスク

【手がかり】デンソープレステック社からの発注指示書メールは 古橋花奈氏1名宛で、社内の自動取込トリガーは DNKデータ処理 のExcelマクロに限られる。

【ヒアリングで判明】「古橋以外数名処理はできる。端末は限られるので、Windowsパスワードを数名が知っている状態」と確認されました。属人化リスクがゼロというわけではありませんが、古橋花奈氏1名に完全依存する真の単一障害点ではなく、対象端末を扱える少数のバックアップ要員が存在する体制であることが分かりました。 (出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

【質問】（解決済み：古橋花奈氏以外にも数名が処理可能で、対象端末のWindowsパスワードを共有している。単一障害点ではないと確認。残る未解明点なし）

【解けると】受注取込の属人化リスクを解消できる。 (詳細: daily-rhythm.html)

A7 ★ プリンタ台数・印刷記録の保管場所

【手がかり】Printer_List.xlsx で7台中4台に「未使用」フラグ。印刷記録の5ショートカットはすべて \\SERVER2\KANRI\AS400 配下を指すが、8.3圧縮形式のためサブフォルダ名まで読み取れなかった。

【ヒアリングで判明】現在稼働しているプリンタについて「社内で稼働しているプリンタは他にもあるが、AS400からの出力で指定しているプリンタはその2台」と確認されました — IMC5500FとPC6010Mの2台という理解で正しく、Printer_List.xlsx上の他4台の「未使用」フラグはAS/400出力とは無関係な社内他用途プリンタを指すものと判明しました。5帳票の印刷控えの保管先フォルダも判明しました:

• \\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参照)

【質問】（解決済み：5帳票の保管先フォルダ（作業指示書発行２／組付指示書発行の実パス）が判明。能動的な確認者はおらず、紛失・授受トラブル時の証跡としての保管のみと確認。残る未解明点なし）

【解けると】帳票の物理出力運用を移植版設計に反映できる。 (詳細: daily-rhythm.html)

A8 ★★ 経理システムの潜在バグ2件は「忠実移植」か「修正」か

【手がかり】(a) ITS996R：請求書発行区分の変更権限が、無関係な SSBS77（請求済締日変更）と誤って同一CL名で判定されている（its996r.md L8-18）。(b) ITSI13R：前月繰越額を、要求された仕入先コードではなく読み込みループ終了時の別の仕入先コードを起点に算出している疑い（itsi13r.md L182-190）。

【ヒアリングで判明】(a) ITS996Rの権限バグについて、新實さんは「は不備です。」と明言しました — SSBS77（請求済締日変更）と誤って同一CL名で判定している現状は意図的な設計ではなく、修正すべき不具合であることが確定しました。移行版では忠実再現せず修正して問題ありません。(b) ITSI13Rの前月繰越額算出については「は現在未使用です。前月繰越が発生したことがないので、気づいていません。」との回答でした — つまり実運用上、前月繰越が一度も発生しておらず、疑わしいロジックが実際に実行された実績自体が無い（＝正誤を確認する機会自体がなかった）ということです。バグの実害有無はこの回答だけでは分からず、依然未検証のまま残ります。 (出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

【ヒアリングで判明・続報】「ITSI13Rは現在使用していません。移植の必要ありません。」との回答により、「忠実移植か先回り修正か」という判断そのものが不要（moot）になりました。A8(b)は完全クローズです。ただし移行スコープ上の実態は「これから移植しない」ではなくすでに移植完了している点に注意が必要です——実装本体はpilot/app/src/domain/stagingShiharai.ts（集計・消費税・前月繰越・B1-B3/A1-A9の全サマリ行）、経路はpilot/app/src/routes.ts:161-169（POST /api/print/shiharai-meisai、GSBS06権限ゲート）、画面はpilot/app/public/itsi13.html、ビューはpilot/app/migrations/003_xfer_views.sql:16-19（v_sfdpp3_xfer）で、test/stagingShiharai.test.tsほか複数のテストも揃っています。争点だった前月繰越ロジックも既に決着済みで、docs/decisions.md D3とpilot/DEVIATIONS.md #5により「推定した業務ルール（前月・同一仕入先）で実装し、逸脱として登録、実データ到着時に等価性を検証する」＝先回り修正側を選択して実装済みです。実装済み・テスト済みのコードを撤去する理由はないため、「顧客が現在未使用・移行不要と明言した機能を、既に実装済みのまま保持する」と記録し、以後この機能への追加投資（プレビューseam新設、実データ突合、前月繰越の再検証）は不要とします。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（解決済み：ITSI13Rは現在未使用で移植不要と確認、「忠実移植か先回り修正か」の判断自体が不要に。ただし実態は既にstagingShiharai.ts等で実装・テスト済みであり、前月繰越ロジックも先回り修正側で決着済み（D3／DEVIATIONS#5）。撤去せず現状のまま保持し、追加投資は不要とする。残る未解明点なし）

【解けると】バグを忠実移植するか修正するか判断できる。 (詳細: finance.html)

A9 ★★ 使われていないマスタ項目・追加移行スコープ

【手がかり】(a) BKMP.BKKUTR（手数料区分）はプログラムが一切読まずハードコード判定なのに、実データは162件中160件（98.8%）に値（1＝18件／2＝142件）が入っている。(b) 支払明細書 ITSI13R／GSBS06 はMENUR1棚卸（D23）の対象外だった。(c) ITS001R の25項目版 JUDPR9 契約に対応する請求書プレビューseamがまだ無い。

【ヒアリングで判明】(a) BKMP.BKKUTR（手数料区分）について「は使っていないのであれば廃止で。プログラムを作ったときは、名古屋銀行碧南支店から振込した場合の手数料計算に使用していた。」と確認されました — 現行プログラムはこの項目を一切参照していませんが、162件中160件（98.8%）に値が入り続けていた謎は、かつて実際にこの項目が手数料計算に使われていた名残りで、入力担当者側の運用が惰性的に続いていたためと判明しました。廃止して問題ありません。(b) 支払明細書ITSI13Rについては「ITSI13Rは現在使用していません」と確認され、追加移行の緊急性はないことが分かりました。(c) 実際の請求書出力パイプラインの全体像も判明しました: AS400 SSBS62→SSCB62C→ITS001R→BAT0362→BAT0362.xlsm→請求書作成（範囲指定）.xlsm。これはdaily-rhythm.htmlのA12節（ITA_PGM実行ログ）で謎だった汎用名のBAT0362.xlsm成功ログの正体も同時に解決します。 (出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

【質問】（解決済み：BKKUTRは廃止可、ITSI13Rは現在未使用と確認——追加移行の緊急性なし）

【解けると】移行スコープと未使用マスタ項目の要否が確定。 (詳細: finance.html / masters.html)

A10 ★★★ 無人バッチとジョブスケジュールの全貌 —— 一覧を見せてください

【手がかり】VBA全量解析で、メニューに載らない無人バッチの痕跡が複数見つかりました: (a) ITND06R（伝票№未入力チェック JUDPQ7）と ITUR08R（型費重複計上チェック JUDPS7）はどのメニューにも属さない。(b) BJDPQ5.xls（過剰引当チェック）と TNDPP1.xls（棚卸データ）を書き出すAS/400側プログラムが特定できない。(c) BAT0726/BAT0362 の対応帳票が不明。(d) SSBS02（在庫展開）の実行時刻・頻度も未確認。(e) 物理ファイル再編成（AS400再編成フォルダ、2024年7月にツール新設＝現役）の実施者・頻度も不明。

【ヒアリングで判明】日次バッチ連鎖の全体像が判明しました: AS/400側でLSTPRT01→SCD02→SCDCK02→BACKUP02がデータを作成し、Windowsのタスクスケジューラが6:30にSCD_D_0630.batを起動、これがSCD_DAILY_0630.batを呼び出して本文列挙の19本のメール送付バッチ（BAT0726.xlsm＝金型管理マスタ更新を含む。A5参照）を実行します。タスクスケジューラは現在「Soumu8」のPCにセットされており、実行対象のバッチファイル・Excelマクロも同PCに保存されているとのことです。年次連鎖についても訂正が得られました: 物理ファイル再編成ツール（SCD_Y_07SUN2.bat→AS400_OLD_DATA_TP.xlsm、SCD_Y_07SUN2_0500.bat→OLD_JUDP_ADD_ALL_JUDP.xlsm）は「同じ方法で年1回7月の第2日曜日に実行」——つまり手動棚卸しではなく、日次連鎖と同じWindowsタスクスケジューラによる年次自動実行であることが確定しました（daily-rhythm.htmlのA14節「AS400再編成」はこの点で訂正が必要——別担当が同ページへ反映予定）。JUDPR1のCLRPFM競合についても解決しました: 「JUDPR1はCL開始時にロックを掛ける　→　クリアー　→　変更処理　→　Excel転送　→　ロック解除」という一連の処理全体を通してロックが保持されており、「Excel転送完了できなかった場合は、エラー表示して新實が対処」する運用のため、転送前にクリアされる競合は構造的に起きません。 (出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

SSBS02（在庫展開）の実行頻度についても回答が得られました: 「SSBS01を実行した後に、SSBS01実行者がSSBS02を実行することになっています。基本的に1人が１日１回実行します。」— つまり日次バッチとして自動起動されているのではなく、SSBS01を実行した本人が続けて手動でSSBS02を実行するという、担当者ベースの運用ルールで1日1回回されていることが確定しました。 (出典: 新實さん、2026-07-22回答、docs/feedback/analysis/2026-07-22-niimi-remaining-A-questions-reply.md参照)

【質問】（解決済み：SSBS02はSSBS01実行者本人が続けて1日1回手動実行する運用と確認。残る未解明点なし）

【解けると】1画面の提示で5件以上の未解明（実行主体・時刻）が一括解決し、移行時のバッチ設計ができる。 (詳細: shipping.html / production.html / daily-rhythm.html)

A11 ★★ 受注まとめ入力の「ログアウトで消える」仕様とエラー連絡の実運用

【手がかり】職員自筆の手順書 受注まとめ入力の手順と注意点.xlsx に「ログインの都度、保存内容がクリアされる。作業途中はデスクトップに退避し、再開時に C:\ITA_PGM へ手で戻す」という運用が明記されています。また、Excelジョブ失敗時のダイアログは「社内のコンピュータ管理者に連絡してください」と表示します（Err_Msg.xlsm）。

【ヒアリングで判明】「ログアウトで消える」現象の根本原因が判明しました — 実際にはログアウトそのものではなく、ログイン時に走るタスクスケジューラ登録\\Server2\Common\Settei\Startup\IS_Startup.batが、PC起動・ログインの都度C:\ITA_PGMの中身を配布用の既定状態へ書き戻す仕組みによるものです。新實さん: 「各PCは環境変数の設定やC:\ITA_PGMの中身など、どのPCにも共通して変更を加える必要がある場合に備えて、タスクスケジューラを使って、ログイン時に...IS_Startup.batを実行し、一斉に変更を加える仕組みなっている。」— つまりデスクトップへの退避・手動復元という現場の運用は、バグではなく全PC一斉設定配布という意図的な設計への対処であったことが確定しました（(a)への回答に相当）。あわせて受注まとめ入力.xlsx（各PCのC:\ITA_PGM配下に存在）はトヨタ紡織を前提に作られたファイルで、客先からデータで受け取った注文を手入力ではなくコピペで取り込み、AS/400へ転送するためのものであることも確認されました。(b)「コンピュータ管理者への連絡」の実際の連絡手段・記録有無については直接の回答は得られませんでした。 (出典: 新實さん、2026-07-21ヒアリングシート回答、docs/feedback/hearing/2026-07-21-niimi-hearing-sheet-A.md参照)

(b)についても回答が得られました: 「実際には発生していませんが、手段としてはそのままにして新實を呼びに行く、ことになります。」— 電話やメールのような記録の残る経路ではなく、その場の状態を保持したまま新實さんを直接呼びに行くという、口頭・属人的な対応で（かつ実際に起きたことは一度もない）想定されている運用でした。 (出典: 新實さん、2026-07-22回答、docs/feedback/analysis/2026-07-22-niimi-remaining-A-questions-reply.md参照)

推測・要確認 新實さんはこの回答に続けて、受注まとめ入力そのものの利用実態に重大な疑義を自ら申告しました: 「たぶんですが、受注まとめ入力は使われていないのではなかと思われます。作成依頼をした社員が現在在籍しておらず、その方法が他の社員へ伝わっていないと思われます。」— このカードおよびdaily-rhythm.html A13節でここまで詳述してきた「受注まとめ入力」（トヨタ紡織向けコピペ取込ツール）自体が、依頼元社員の退職により使い方の引き継ぎが絶え、事実上使われていない機能になっている可能性があるということです。エラー時の連絡手段が「実際には発生していない」のも、この使用実態の疑わしさと整合します。移行スコープを判断する前に、実際に現行運用でこのツールが使われているかどうかの追加確認が必要です。 (出典: 新實さん、2026-07-22回答、docs/feedback/analysis/2026-07-22-niimi-remaining-A-questions-reply.md参照)

【質問】（解決済み：エラー時の連絡は口頭で新實さんを呼びに行く運用（実例なし）と確認。加えて、受注まとめ入力自体が現在使われていない可能性が新實さんより申告された——利用実態の追加確認が必要）

【解けると】移行版で最優先に潰すべき運用リスク（作業消失・属人的エラー対応）が確定。 (詳細: daily-rhythm.html)

B1 ★★★ 見積単価がAS/400に入るまでの手動橋渡し＋二重フィールド構造

【手がかり】見積書（Excel）で決めた単価を SSBS04 へ転記する自動連携は存在しないことがVBA全量解析で確定しました。しかも未転記を毎日検知して営業課へ督促する 見積単価未入力リストメール送付.xlsm（2025年10月まで保守）が現役です — つまり手動転記の漏れは日常的に起きています。さらに受注品番マスタ JHMP 自体に「決定単価／見積単価／号試単価／変更単価１〜５」という似た値が並び、PRMP（日付別に複数行の決定単価／見積単価）との関係が不明です（cases⑤）。

【ヒアリングで判明】新實さんの回答により、見積単価の転記フローと二重構造の両方が判明しました。(a) 転記の実担当: 対象製品を担当した営業課の人が見積を行い、SSBS04も基本的に同じ人が入力します。入力量が多い場合は営業課の他の人が入力することもあります——つまり見積書発行と単価転記は部門をまたがず、基本的に同一営業課内、多くは同一人物で完結する運用です。(b) JHMPとPRMPの正: PRMPが正です。当初はJHMPのみで対価を保持していましたが、単価改訂の回数が多く固定フィールド数では対応できなくなったため、複数世代を積み重ねられるPRMPへ移行しました。同じ品番でも注文によって単価が変わる場合があるため、個別受注に紐づくJUDPの単価（伝票別単価、SSBS12）がさらに優先されます——つまり優先順位はJUDP＞PRMP＞（旧世代の名残である）JHMPという構造です。さらに見積単価未入力リストメール送付.xlsmについても運用実態が判明しました: 毎日、当月以降の受注概算をグラフ化しており、決定単価が無いものは見積単価で代用計算し、どちらも未入力のものだけを通知対象にしています。この「見積単価」は見積書に記載された単価そのものではなく、受注入力時の予測単価（見込み単価）という位置づけである点も明らかになりました。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)

【質問】（解決済み：見積書発行とSSBS04入力は同一営業課内・多くは同一人物で完結し部門をまたがない。JHMP/PRMPはPRMPが正でJHMPは単価改訂回数増加に伴う旧世代の名残、優先順位はJUDP＞PRMP＞JHMP。見積単価未入力リストの「見積単価」は受注入力時の予測単価という位置づけと確認。残る未解明点なし）

【解けると】単価の「真の源泉」が定まり、移行時のデータ整合設計ができる（最重要）。 (詳細: estimate.html / estimate.html §JHMP)

B2 ★★ 加工比率マスタから見積金額を出すVBA計算ロジック

【手がかり】加工比率マスタのレート表から見積書金額を計算するVBAの計算式本体はバイナリで未解析です。見積書復元.xlsm の復元元データの場所も未確認【実VBAで解明】手動ファイル選択式の再テンプレート化ツールと判明。図面整理業務・技術情報と見積算出の接続方法は未調査のままです。

【ヒアリングで判明・部分的】新實さんから、加工比率マスタの設計意図（単なるレート参照表ではなく逆算で作られたものであること）が判明しました。新實さん: 「見積を現在どのように作成しているのかは、把握していません。加工比率マスタをつかう方式を作成した時は、おおよその全体金額を各工程の時間に振り分け見積書を作成していました。実際にあっているかどうかは無視して、合計時間×時間単価が狙った見積金額になるように、あらかじめ振り分けを決めたのが加工比率マスタです。」——つまり加工比率マスタは各工程の実際の加工時間から金額を積み上げる順方向の計算表ではなく、先に決めた見積金額に合わせて工程時間の配分を逆算した表であることが確定しました。さらに「いつも同じだとわかってしまうので、乱数で適当に変化させるマクロを組み込みました。アイシン向け専用だったと記憶しています。もう使っていないのではないかと思われます。」との補足もあり、判で押したような値にならないよう乱数で意図的に揺らぎを持たせる仕組みが組み込まれていたこと、対象がアイシン向け専用だった可能性、現在は使われていない可能性——の3点も判明しました。ただし新實さんは「見積の計算式は営業課に問い合わせてください」と明言しており、現在の実際の見積計算方法そのものは今回のヒアリングでは解明されず、営業課への追加確認が必要なまま残ります。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)

【質問】（営業課へ）見積金額の実際の計算方法（工数×レート＋…）を教えてください。加工比率マスタは新實さんの回答によれば「アイシン向け専用・乱数で変化させる特殊な仕組み・もう使っていない可能性」とのことですが、現在も参照していますか、それとも別の方法で計算していますか？

【解けると】見積計算ロジックを移植・文書化できる。 (詳細: estimate.html)

B3 ★★ 単価改定・支給品費の運用ルール

【手がかり】単価を遡及改定した時、既に確定・請求済みの伝票を再計算するのか、次回受注から新単価が適用されるだけか不明です。見積書の内訳区分（機械・治具・型・試作品・設備）と PRMP のコスト内訳（外注費用・自給品費 PRHYJK・支給品費 PRHYSK・表面処理費・償却費・加工費）の対応も未確認。

【ヒアリングで判明】新實さんから、単価改定の適用ルールと内訳区分の対応関係が判明しました。(a) 単価改定は「改定時の取り決めによります。PRMPの適用日を指定して対応します。」——つまり遡及するか次回受注からかは一律のルールではなく、改定のたびに合意した適用日をPRMPへ個別に設定する運用で、estimate.htmlで確認済みの「PBTANKRが適用日以下で最新の行を選ぶ」設計と整合します。見積書の内訳区分（機械・治具・型・試作品・設備）とPRMPのコスト内訳フィールドの対応についても回答がありました: 「特に関連はありません。前者は使っていた見積書にその表示があったのをそのまま再現しただけで特に意味はありません。後者は、デンソープレステックとの価格決定に関してその項目で決めていたので、後の価格改定時にわかるように入力できるようにしました。」——つまり見積書側の内訳区分表示は単に過去の見積書様式を踏襲しただけの名残であり、PRMP側のコスト内訳は主にデンソープレステックとの価格交渉の経緯を後から追跡できるようにするための項目で、両者に設計上の対応関係は最初から存在しません。(b) 無償支給材のゼロ計上については「0円と思っています。正確には営業課に確認ください。」との回答でした——新實さんの認識としては0円計上ですが、確定した運用ルールとしての裏付けは営業課への確認待ちのまま残ります。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)

【質問】（解決済み：単価改定はPRMPの適用日指定による個別合意ベース、見積書の内訳区分とPRMPコスト内訳に設計上の対応関係はなし（前者は旧見積書様式の名残、後者はデンソープレステック価格交渉の追跡用）と確認。無償支給材のゼロ計上は新實さんの認識どおりだが、確定した運用ルールとしては営業課への最終確認が推奨される——残る未解明点: 無償支給材ゼロ計上の営業課による最終確認）

【解けると】単価改定と原価内訳の運用が確定。 (詳細: estimate.html / cases.html)

B4 ★ SSBS18ゲート名重複は既知の不具合か

【手がかり】SSBS18 のゲート名が SSBS17 と同一という設定ミスが確認されています。

【ヒアリングで判明】新實さんから「不備です。」と明言され、SSBS18のゲート名がSSBS17と同一という設定ミスは意図的な設計ではなく修正すべき不具合であることが確定しました。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)

【質問】（解決済み：SSBS18のゲート名重複は不備（不具合）と確認。移行版では修正してよい。残る未解明点なし）

【解けると】移植時に直すか温存するか判断できる。 (詳細: estimate.html)

B5 ★★★ 試作受注はどこから入るのか（MENUT1／T2 試作管理サブシステム）

【手がかり】試作受注の伝票№が jud605＝11〜29 にどこでセットされるか直接確認できず、JSBS01/03 経由と推測しています。MENU00 から到達不能な MENUT1／MENUT2（試作管理サブシステム、menu_tree.md:332-334）が別に存在します。指示形態 21〜29 の呼称も、screen-help.json で「号口組付品」と「試作組付品」に揺れています。

【ヒアリングで判明】2026-07-20メールにより、試作品（受注区分２）はMENUT→MENUA（前段階）→MENUJ1のJSBS08（肝、ITSS08Rで部品展開＋在庫引当）という流れで処理されることが確認されました。指示形態21〜29は「試作組付品」が正式な分類で、「号口組付品」は呼称ゆれ・俗称です（新實さん、2026-07-20メール、docs/feedback/analysis/2026-07-20-niimi-shijikeitai.md参照）。ただしjud605がMENUT／MENUA側の具体的にどの画面・どの処理ステップで11〜29にセットされるか（フローの「順序」は確認できたが「発生タイミング」は未確認）は、なお未解明のまま残ります。

【ヒアリングで判明・続報】2026-07-22の回答で、残っていた「jud605を11〜29にセットするのはどの画面か」という点も解明されました。新實さん: 「JSBS03で当該品番に11または21を入力します。（号口品の場合は51）11の品番は単品のまま出荷される製品で構成展開されることなく、在庫引当の処理へと進みます。21の品番は組付品で構成マスタを参照して部品展開されます。展開された部品1点1点について在庫引当の処理へと進みます。MENUAは21の品番のものを対象としたメニューです（アイシン支給品管理メニューは現在使用されていないと思われます）。MENUTは11の品番のものと21の品番の部品を対象としたメニューです。「1 試作作業指示数計算」が在庫の再引当・不足分の生産指示データの作成を行い、「3 試作作業指示書発行」が指示データを作業指示書として印刷します。」——つまりjud605はJSBS03（新規・設変受注入力）の中で受注担当自身が11／21／51を直接入力することで確定し、MENUT／MENUAはその後段の在庫再引当・作業指示発行を担う画面群であることが確定しました。またアイシン支給品管理メニュー（MENUA2）は現在使用されていない可能性が新實さんから示唆されました。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)

【質問】（解決済み：jud605=11／21／51はJSBS03で受注担当が直接入力して確定し、MENUT／MENUAはその後段の在庫再引当・作業指示発行を担うことが確定。アイシン支給品管理メニューは現在使用されていない可能性ありとの補足も得た。残る未解明点なし）

【解けると】試作受注フローの全体像が確定し、移植の抜けを塞げる。 (詳細: order.html / proto-tooling.html)

B5b ★★ 号口金型の製作は指示形態コードのどこにも現れない

【手がかり】2026-07-20メールで新實さんは、板倉の受注を１号口金型の製作／２試作品の製作／３量産品の製作の3つに大別しました。添付の指示形態（JUD605／JHD062）コード表には２（試作系: 11/21/31）と３（号口系: 51/52/61/999）は載っていますが、１号口金型の製作に対応するコードが存在しません。金型製作は工機課（MENUB1）が担う別プロセスの可能性がありますが、確認できていません。

【ヒアリングで判明】新實さんから、号口金型の製作依頼は指示形態11（単品のまま出荷）に分類されることが判明しました: 「号口の金型製作は指示形態11（単品のまま出荷）に分類します。当然在庫はありませんので、作業指示書が発行され、完成処理後、出荷指示書が発行され、出荷処理がされます。ただし、作業現場には作業用に金型・治具作業指示書が発行されます。こちらをもとに作業します。発行はMENUB1より行います。金型・治具作業指示書は、号口用と試作用の2種類があります。それを使い分けます。」——つまり号口金型は指示形態体系のどこにも専用コードを持たないのではなく、指示形態11（単品出荷品）を流用し、現場作業そのものは工機課のMENUB1が発行する別立ての「金型・治具作業指示書」で指示されるという2階建ての仕組みであることが確定しました。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)

【質問】（解決済み：号口金型の製作は指示形態11（単品出荷品）を流用し、現場向けにはMENUB1発行の金型・治具作業指示書（号口用／試作用の2種）で別途指示される。残る未解明点なし）

【解けると】号口金型の受注区分がどこにも文書化されていない空白を埋められる。 (詳細: order.html / proto-tooling.html)

B6 ★★ 伝票№の桁数・かんばん系用語の実体

【手がかり】伝票№は「8桁／16桁」の前提でしたが、実データは judp.junotd（数値8桁）・n1dp/n2dp（英数字8桁）・n3dp（英数字15桁）の3種で、16桁は未発見。「かんばん品内示データ」「デンソーPT指示データ」という用語はRPGスペックに見つからず、Excel側（かんばん品内示と確定の比較）で完結している可能性があります。

【ヒアリングで判明】新實さんから伝票№の実際の運用とデンソーPT呼称の実体が判明しました。伝票№は「基本的に客先の伝票№の流用で対応しています。当社の伝票№月2桁連番4桁の計6桁。客先の伝票№の桁数はバラバラで数字8桁以内であればJUDPに入力、それ以外はn2dp,n3dpへ入力します。試作№はアイシンからの№でアイシンの試作の単位で設定されているものです。支給品の仕分けなどに使用されます。」——つまり伝票№は板倉側6桁（月2桁＋連番4桁）と客先側（桁数不定、8桁以内はJUDP直接、それ以外はn2dp/n3dpのサイドテーブル）という二層構造であることが確定し、order.htmlで確認済みの3種の実測幅（judp.junotd数値8桁・n1dp/n2dp英数字8桁・n3dp英数字15桁）とも整合します。「デンソーPT」「DNPT」という呼称についても: 「デンソーPTは、デンソープレステックのことです。他にDNPTもおなじです。また、旧社名はデンソー機工でDNKと表示しているものもあります。」——つまり社内で「デンソー機工」「デンソーPT」「DNPT」「DNK」という複数の呼称が実際に併用されており、すべて同一の得意先（現・デンソープレステック、コード20）を指す新旧名称の混在であることが確定しました。さらにかんばん・内示の全体像も判明しました: デンソープレステックからの注文は毎日メールで届き専用の取込処理系で処理される一方、デンソープレステック以外の号口品はJSBS48（号口かんばん品内示入力）で内示を入力し、かんばん品の情報に沿って月内で均等にばらして注文を自動割り振り、毎日の確定情報（かんばんの枚数）で再度自動割り振りします——「かんばん品内示データ」（njdp）はまさにこのデンソープレステック以外の号口品を対象にした仕組みであり、デンソープレステックが「いつ何個」という確定情報で来るのに対し、その他は「1か月で何個」という内示情報しかないためこの均等割り振り処理が必要になる、という設計意図も確定しました。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)

【質問】（解決済み：伝票№は板倉側6桁＋客先側可変桁（8桁以内はJUDP、それ以外はn2dp/n3dp）の二層構造。「デンソーPT」「DNPT」「デンソー機工」「DNK」はいずれもデンソープレステック（得意先コード20）を指す新旧呼称の併用と確認。njdp（かんばん品内示データ）はデンソープレステック以外の号口品を対象にした内示の均等割り振り機構であることも確定。残る未解明点なし）

【解けると】伝票№設計とかんばん取込の所在が確定。 (詳細: order.html)

B7 ★★ 分納チェックとかんばん品内示データの停止

【手がかり】(a) 分納（JSBS05）の過剰分割チェックが「残数」でなく「親の全受注数」を基準にしているため、繰り返し分納すると残数を超過しうる。(b) njdp（かんばん品内示データ）は実データが2015-08〜2020-03で完全停止、対象は得意先30・50の2社のみ（5000＝トヨタ紡織は0件）。

【ヒアリングで判明】新實さんから、分納の過剰分割リスクとかんばん取引停止の理由の両方に回答がありました。(a) 分納チェックについては「分納処理は、受注数―納品数が次の受注数になるので超えることはないと認識しています。また受注を超える納品は入力できないので、そこも超えないようになっています。」——order.html第5章で指摘していた「親の全受注数を基準にした過剰分割チェック」は、実際には「受注数−納品数＝次の受注数」という差分計算のため構造的に残数を超えられない設計であり、かつ受注数を超える納品自体が別途入力レベルでブロックされている、という二重の安全策が働いていることが確認できました。(b) 得意先30・50とのかんばん取引が2020年3月で完全停止していた理由については「推測ですが、かんばん取引をする対象品番がなくなったと思われます。」との回答でした——これは新實さん自身も明言しているとおり推測（確定情報ではない）であり、対象品番消滅という仮説は得られたものの、断定的な事実確認には至っていません。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)

【質問】（解決済み：分納は「受注数−納品数＝次の受注数」の差分計算＋受注超過納品自体のブロックという二重の安全策で構造的に過剰分割は起きないと確認。得意先30・50とのかんばん取引停止は「対象品番がなくなったと思われる」との新實さんの推測（推測であり確定情報ではない）が得られた。残る未解明点なし）

【解けると】分納チェック仕様と njdp 廃止可否が確定。 (詳細: order.html / production.html §9)

B8 ★ 号口かんばん・部品引継ぎの設計意図（参考）

【手がかり】JSBS53 号口かんばん品内示入力（ITJM56R）が通常受注（ITJM71R）と同じ jkmp カウンタを共有。ITJM76R（部品引継ぎ）は junojo 自己参照と jud602 引継ぎ元リンクの二重構造。JSBS23（最終受注納期問合せ）の KSML1 アクセスパスはソース欠落で推測止まり。

【ヒアリングで判明・部分的】新實さんから3つの手がかりについて回答がありました。1) JSBS53号口かんばん品内示入力（ITJM56R）が通常受注（ITJM71R）と同じjkmpカウンタを共有する点について: 「B6のデンソープレステック以外の号口品の内示をばらして注文として入力するので、実質的に通常の追加受注をする作業と同じ処理です。」——つまりカウンタ共有は設計上の意図的な共有であり、問題ではないことが確定しました。2) ITJM76R（部品引継ぎ）のjunojo自己参照とjud602引継ぎ元リンクの二重構造について: 「どのようなことを指摘されているのかわかりませんが、特に問題になったことは報告されていないと思います。」——これは指摘している技術的な論点自体が新實さんに伝わらなかった非回答であり、設計意図の確認は得られませんでした。ただし「特に問題になったことは報告されていない」という運用上の実害無しの証言は得られています。3) JSBS23（最終受注納期問合せ）のKSML1アクセスパスについては、新實さんが添付ファイルでITJM27R.txt（最終受注納期問合せのRPGソース）とJSBS23.txt（呼び出し元CL）を送ってくれました。この2ファイルを本リポジトリのsource/as400-admin/transport-tooling/ITLIBS/ITJM27R.txt・source/as400-admin/transport-tooling/ITLIBS/JSBS23.txtと直接比較したところ、末尾改行の差を除いて完全に内容が一致しており、新實さんの手元にある実ソースと本リポジトリの既存アーカイブが一致していることが確認できました——つまりこの添付は新規のソース内容を追加するものではなく、既存アーカイブが正確・完全であることの裏付けになります。さらに今回、この確認を機にITJM27R.txt自体を読み直しましたが、ソース内にKSML1自体のDDS定義（キー項目リスト）は含まれておらず、#KSMPサブルーチンのSETLL KSMR/READ KSMRとKSHNBB COMP WSHNBBという比較パターンから「先頭キー＝部品品番kshnbb」であることが読み取れるのみで、これはpilot/spec/itjm27r.mdが既に示していた推測と同一の間接証拠にとどまります。ただし別途analysis/out/lf_indexes.sqlにはCREATE INDEX "ix_ksml1" ON "ksmp" ("kshnbb", "kshnbj")という定義があり、この移行スキーマ側の記述からはキー順（kshnbb→kshnbj）が独立に裏付けられます。結論: KSML1のアクセスパス自体の技術的な未解明点は、ソースの欠落によるものではなく、KSML1という論理ファイル自身のDDS定義が本リポジトリのどのソース束にも含まれていないことが原因であり、新實さんの今回の添付ではこの点は解消されませんでした。 (出典: 新實さん、2026-07-22ヒアリングシート回答＋添付ITJM27R.txt/JSBS23.txt、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-B.md参照)

【ヒアリングで判明・続報】新實さんからKSML1.txtそのものの添付が得られました。全文13行のDDS定義により、キー順はKSHNBB（子品番）→KSHNBJ（親品番）で確定し、analysis/out/lf_indexes.sqlの移行スキーマから間接推定していた順序と一致しました。B8(3)は完全クローズです（pilot/DEVIATIONS.md #92のstaff item「confirm KSML1 key」も確認済みへ更新）。重要な訂正: 添付ファイルは、本リポジトリに既にアーカイブ済みだったsource/as400-admin/transport-tooling/ITLIBS/KSML1.txtと末尾改行の有無を除いてバイト単位で一致していました（添付534バイト／既存535バイト、差分は末尾の改行1文字のみ）。つまり「KSML1のDDS定義はどこにも見つからない」という従来の記述は当方の探索漏れによる誤りで、ソースは最初からリポジトリ内に存在していました——前ラウンド（2026-07-22, B）でITJM27R.txt本文内にKSML1のDDS定義が無いことを確認した際、ITLIBS/直下の同名ファイル自体を確認していなかったことが原因です。重複を避けるため添付KSML1.txtはリポジトリに再配置していません。B8(2)（ITJM76Rのjunojo/jud602二重構造が意図的設計か）は今回も対象外で、未解明のまま残ります（運用上の実害報告が無いため優先度は低いまま）。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（部分解決：1)はjkmpカウンタ共有が意図的設計と確認済み。3)はKSML1.txt添付によりキー順KSHNBB→KSHNBJが確定し完全クローズ——従来の「DDSがどこにも無い」は当方の探索漏れで、ファイルはsource/as400-admin/transport-tooling/ITLIBS/KSML1.txtに最初から存在していた。残る未解明点は2)のみ：ITJM76Rのjunojo/jud602二重構造が意図的設計かどうかは今回も新實さんに技術的指摘の内容自体が伝わらず未解明のまま、優先度は低いまま継続）

【解けると】設計意図を確認して忠実移植の裏取りができる。 (詳細: order.html)

C1 ★★★ 在庫引当・在庫展開の落とし穴（引当漏れ・二段階運用）

【手がかり】(a) WSBS08（ITGO11R）の在庫引当が「納期＝本日」の受注しか減算しない（「今日以降すべて」を意図したバグかも、menuw-open-questions.md L32-36）。(b) 出荷は SSBS01 で記録した後で、SSBS02（在庫展開）を別途手動で実行して初めて在庫が減る二段階運用（SSBS02を忘れると出荷済みなのに在庫が古いまま）。(c) JHMP＋BHMP 両方の在庫減算漏れ（S/A新規登録品で BHZASU が減算されないケース、2020年変更コメントと実装の不一致）。

【ヒアリングで判明】(b)のSSBS02実行頻度は、セクションA10で同じ新實さんへのヒアリングにより既に判明している: 「SSBS01を実行した後に、SSBS01実行者がSSBS02を実行することになっています。基本的に1人が１日１回実行します。」——つまり日次バッチとして自動起動されているのではなく、SSBS01を実行した本人が続けて手動でSSBS02を実行するという、担当者ベースの運用ルールで1日1回回されている。回し忘れが実際に起きるかどうかについては直接の言及はなかった。 (出典: 新實さん、2026-07-22回答、docs/feedback/analysis/2026-07-22-niimi-remaining-A-questions-reply.md参照、hearing.html A10)

【実資料で判明】(a)(c) 号口在庫の増減は実際の入出庫トランザクションではなく完成・出荷イベント基準でのみ再計算される設計であることが、2008年の開発者自身による設計文書で確認できた——「在庫の増減は、在庫の入庫出庫では行われず、完成、出荷を基準に行われる。したがって不良等の通常以外の入出庫があった場合の連絡がないと確実に差異が発生してしまう。」つまり引当漏れ・在庫不一致は例外的な不具合ではなく設計時から織り込まれた構造的な特性であり、これに対応する月次の実地棚卸・差異訂正パイプライン（ITGZ07R〜ITGZ11R）が2008年当時から運用されている。同資料ではITGO03R（S/A完成入力）が2008年当時からJHD091のみを更新しBHZASU／JHZASUを更新しない仕様だったことも確認でき、これは新しいバグではなく長年一貫した仕様と裏付けられた。加えて、社内手順書（Ｅ－０３）「組付品の中止処理」・（Ｅ－０７）「未完成組付品の数量変更処理」には再引当チェックの手動手順（10.試作管理→14、PageDownでのスキャン）、（Ｅ－０８）「完成号口品の数量変更処理」には保護のないBHMP在庫直接編集の手順があり、これらは運用側の一因となり得る候補として挙げられる（特定の不具合の確定的な証明ではない）。(出典: source/dev-archive/20081030_号口品棚卸在庫合わせフロー/号口品棚卸在庫合わせフロー 20081030　.xls「在庫データの確認の流れ」シート・「プログラム表」シート・「現状のシステム」シート参照、source/work-procedures/作業手順書/（Ｅ）　受注状況の変更/（Ｅ－０３）・（Ｅ－０７）・（Ｅ－０８）各参照)

【ヒアリングで判明・追加確認】(a)についても新實さん本人から直接の回答が得られた——「当日出荷完了時点の在庫数のリストです。実際は在庫を合わせるための品番一覧表です」。つまりWSBS08（ITGO11R）が「納期＝本日」の受注しか減算しないのは「今日以降すべて」を意図したバグではなく、当日出荷完了時点の在庫スナップショットとして「在庫確認用の品番一覧表」を作るための設計だったと確定した。あわせて「引当漏れが原因かどうかはわかりませんが、在庫が合わないことはよくあります。現在も多くの品番であっていない可能性があります。日常的に流動しているものでないと合わせることをしない（棚卸をしていない）」との証言も得られており、これは左記の2008年設計文書が示す構造的特性（入出庫では在庫更新されず完成・出荷基準）と一致する運用実態の裏付けになる。SSBS02の実行頻度についても改めて「基本的に1日1回」との回答があったが、これはA10・本カードの既存ヒアリングで確認済みの内容と完全に一致——新事実ではなく、独立した2回のヒアリングラウンドで同じ運用が二重に確認された形。 (出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【質問】(a)（解決済み：新實さん本人が「当日出荷完了時点の在庫確認用の品番一覧表」と明言、バグではなく設計と確定）(b)（解決済み：SSBS02はSSBS01実行者本人が続けて1日1回手動実行する運用と確認。回し忘れの実例有無のみ未確認）(c)（解決済み：新しいバグではなく2008年から一貫した仕様と確定）

【解けると】在庫ロジックを忠実移植か修正か判断でき、二段階運用の自動化可否も決まる。 (詳細: production.html §9 / shipping.html §7)

C2 ★★ 号口の在庫展開・出荷を分ける「範囲コード」の意味

【手がかり】出荷の在庫展開は JHD062（指示形態）が 51〜69 の範囲のときのみ完成品在庫（JHZASU）・S/A在庫（JHD091）を減算し、範囲外は最終出荷日だけ更新（範囲の意味は未文書化）。JUKUED＝9（打切区分＝9）は「出荷確定／完了」と推測だがコメント無し。品番先頭5桁＝61155 のシャフト除外ルールは2008年コメントに反し現行コードにガードが見当たりません。

【実資料で判明】打切区分（JUKUED）の意味が確定した——0＝未納、8＝指打（指示打切）、9＝完納または打切（納品数が受注数未満なら「打切」、受注数以上なら「完納」に分岐、JIQT16画面表示ラベルより）。これは実データ検証（打切区分=9の640/640件が完成度100%でゼロ例外）とも独立に整合する。指示形態51〜69の範囲は、コード表（99999999_AS400_指示形態コード表_最新版）で51＝通常指示、52＝社内かんばん指示（未設定）、61＝610B／シロキ工業（得意先固有）、999＝指示対象外が個別に確認でき、この範囲全体が「号口系（量産品）」の指示形態をまとめてグルーピングする境界であることは確定したが、51〜69の個々のコードすべてが文書化されているわけではない。品番先頭5桁＝61155のシャフト除外は、現行コードのランタイム上のガードではなく、2020-10-03の指示形態方式切り替え作業時に行われた1回限りの手動データ補正（TCMPで品番61155-001〜005-B/Cの担当班を4→3へ変更）だったことが切替手順書で確認できた——2008年コメントが想定していた「実行時のコードガード」は、この切替以降そもそも存在しない設計になっている。同資料により、指示形態方式への切り替え自体の本番投入日は2020-10-03と確定した。(出典: source/dev-archive/20220812_受注データ修正での納入日の変更について/20220812_受注データ修正での納入日の変更について_ITJM38R.xlsx、source/dev-archive/99999999_AS400_指示形態コード表_最新版/AS400_指示形態コード表_最新版.xlsx、source/dev-archive/20201003_指示形態方式への切り替え/指示形態方式への切り替え資料.xlsx参照)

【質問】（解決済み：指示形態51〜69の境界（号口系のグルーピング）・打切区分9（完納/打切）・シャフト61155除外（2020-10-03切替時の1回限りの手動補正で、以後ランタイムガードは無い）はすべて確定。残る未解明点なし）

【解けると】在庫展開の分岐条件を業務言語で説明でき、移植の裏取りになる。 (詳細: shipping.html §7)

C3 ★★ かんばん運用の現場実態（かんばん納入 vs 通常納入）

【手がかり】かんばん実物カードの現場運用（発行枚数・回収サイクル）はソースから分かりません。「かんばん納入」と「通常納入」を区別する業務ロジック（フラグ・分岐）が出荷フロー内に見つからず、一方で得意先ごと（デンソー機工・ヒサダ・浅賀井製作所 等）に納品書フォーマット・手順が異なることは確認できています。

【ヒアリングで判明・部分的】かんばんの方向と対象得意先が確定した——「客先からのかんばんを納品書として扱っている。通常の納入と同じ。客先から板倉へ一方通行。その指定日にいるだけのかんばんが発行される」「かんばんがあるのは、浅賀井製作所、ヒサダ、アイシンぐらい。デンソープレステックは納品書」。つまり「かんばん納入」と「通常納入」を区別する業務ロジックが出荷フロー内に見つからなかったのは正しく、そもそも板倉側では区別しておらず、客先が発行するかんばん自体を納品書としてそのまま扱っているだけ（客先→板倉の一方通行）というのが実態。ただし発行枚数・回収サイクルの具体的な数字は今回も未回答で、新實さんからは「詳しくは営業課に確認してください」（客先向けかんばんの実物運用）「社内での生産用のかんばんは、製造課に問い合わせてください」（社内生産かんばん）と、2つの異なる部署への追加確認が明示的に指示された。 (出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【質問】（部分解決：かんばんは客先→板倉の一方通行で客先発行物をそのまま納品書として扱う運用と確定。対象得意先＝浅賀井製作所・ヒサダ・アイシン、デンソープレステックは納品書。残る課題：客先向けかんばんの発行枚数・回収サイクルは営業課へ、社内生産用かんばんの実態は製造課へ、それぞれ別途確認が必要）

【解けると】かんばん／通常納入の分岐を移植版に実装できる。 (詳細: production.html §9 / shipping.html §7)

C4 ★★ 標準在庫・棚番・点滅表示など生産マスタの使われ方

【手がかり】(a) 標準在庫マスタ hzmp は品番のみでユニーク＝同一品番を複数得意先が使うと、先に登録した得意先のレコードしか残らない（menuw-open-questions.md L133-135）。(b) ITKM02R/03R の点滅表示条件が、DDSコード（未発行＋部品不足で点滅）と07年史コメント（部品が揃うものを点滅）で逆。(c) 棚番管理マスタ tbmp を MENUW1／MENUA1 本体から直接参照する箇所が見つからない。

【実資料で判明】(b) 2011年のAS/400開発者自身による設計メモ（組付部品在庫引当方法の変更）に「組付指示書が発行前で部品が揃うものは受注№を点滅表示する」「（部品が）揃わない社内部品は反転表示する」という明記があり、点滅＝「部品が揃った時」（07年史コメント側が正しく、DDSコード側の読みが誤読だった）と確定した。反転表示は「発行済み」と「揃わない部品」の2用途に使われている。(出典: source/dev-archive/20110304_組付部品在庫引当方法の変更/20110304_組付部品在庫引当方法の変更.xls「組付部品変更」シート・「区分変化」シート参照)

【ヒアリングで判明】(a) 「めったにありませんが、発生したことはあります。ただし、HZMPを使用する処理に関しては、発生したことはありません」——つまり同一品番を複数得意先が使うケース自体はまれに実在するが、hzmpが絡む処理（標準在庫）ではそれが起きたことがないため、hzmpの品番ユニーク制約による「先勝ち上書き」問題は理論上のリスクとして残るものの、実運用で顕在化した実例は無いことが確認できた。(c) 「使っています。自動倉庫の棚番マスタですので、MENUW1、MENUA1とは無関係」——棚番（tbmp）は現役で使用中だが、そもそもMENUW1／MENUA1とは管轄が別（自動倉庫系）であるため両画面から直接参照する箇所が見つからなかったのは仕様通りと確定した。(出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【質問】（全項目解決済み：(a) 同一品番の複数得意先利用はまれに実例あり、ただしhzmp絡みの処理では未発生。(b) 点滅＝「部品が揃った時」。(c) 棚番tbmpは自動倉庫専用マスタとして現役使用中、MENUW1/MENUA1とは無関係で仕様通り）

【解けると】生産マスタの正しい意味と画面挙動が確定。 (詳細: production.html §9)

C5 ★★ アイシン支給品・外注支給材の有償／無償管理

【手がかり】アイシン等からの支給品も、板倉→外注先への支給材も、有償／無償を示すフィールド・フラグがスキーマ（smmp／SKDP 等）に見当たらず、数量管理のみで代金精算は別システム（Excel）の可能性が高いです。

【ヒアリングで判明】「試作品にかかわる支給品は基本的に無償。号口品にかかわる支給品は有償。有償支給のものの管理は特にはしていません。客先からの相殺明細が届いた際に営業担当者に確認してもらうことをしているだけです。金額合計は、入金管理表.xlsxにて記録」——つまり有償／無償はスキーマにフラグが無いのが正しく、判断基準は「試作＝無償／号口＝有償」という業務ルール側の区分であって、AS/400側に有償無償フィールドが存在しないのは仕様通りと確定した。代金精算も体系的な突合システムがあるわけではなく、客先から届く相殺明細を営業担当者が都度確認し、金額合計だけを入金管理表.xlsxに記録するという簡易な運用であることが判明した。 (出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【質問】（解決済み：試作品支給品＝無償、号口品支給品＝有償という業務ルールで区分。有償分の代金精算は客先からの相殺明細を営業担当者が確認し、金額合計を入金管理表.xlsxに記録する簡易運用で、AS/400側に有償/無償フラグが無いのは仕様通り）

【解けると】支給材の会計連携の所在が判明。 (詳細: production.html §9 / outsourcing.html)

C6 ★★ 止まった業務データ —— いつ・なぜ終わったか（生産・組付系）

【手がかり】実データが途中で止まっているテーブル群。記憶と照合したい:

• gkdp（号口組付品使用部品データ）—— 2020-03〜2021-04で停止。ITGO23R（明細も入力する完成入力）を廃止し ITGO22R（明細なし）へ一本化した？
• ktmp（構成ツリー担当班変更）—— 2009-05〜2014-10で停止。担当班（製造ライン）の再編が10年以上発生していない？
• kmdp（組付品まとめ指示データ）—— 2021-12〜2022-08、得意先5000トヨタ紡織・担当班3のみ。Excel側でも 組付まとめ指示/ の修正リスト出力アーカイブが2022-08-09を最後に停止（同基盤の他5フォルダは2026年6月まで継続、マクロ＝BAT0108C自体は現役のまま）。「まとめ指示」種別が廃止された？（出荷まとめ指示 JSBS08 フェーズ1・2は移植版で未実装スタブ）

【実資料で判明】kmdp（まとめ指示）の業務フロー全体像が判明した。2021-10-15付の社内説明会資料により、受注管理・組付管理・試作管理・試作管理２の4サブシステムへまとめ指示専用オプション一式（受注管理オプション17-20・24、組付管理オプション15、試作管理オプション12、試作管理２オプション28・33）が新設されたことが確認でき、フローは「連絡書①発行→同一品番・同一納期でまとめ組付→出荷納期10日前に出庫（この工程はPC処理なし＝手作業）→組付開始・完成（組付側では消込をしない）→品質課が組付指示書を消込→注文単位で出荷指示発行」。同資料のテストデータでもKMDPP1／JUDPP1への実際の書き込みが2021年10〜11月に記録されており、kmdp実データの開始時期（2021-12）と時系列が整合する。また現行の完了指示書処理フローチャート索引（Ｂ０－００）が挙げる帳票種別8種の中にまとめ指示専用の文書種別は存在せず、通常の「組付指示書」フロー図（Ｂ６－００）自体もまとめ／個別を区別する分岐を持たない——つまり「まとめ指示」は独立した文書種別ではなく、指示形態＝31という発行時の条件分岐に過ぎないことが分かった（種別自体が「廃止された」という枠組みは前提として成立しない）。2022年8月の停止理由自体は、この資料でも今回も未解明のまま。(出典: source/dev-archive/20211015_組付まとめ指示システム/説明会資料.pdf・組付まとめ指示システム.xlsx「まとめ用OP」「テストデータ」シート参照、source/work-procedures/作業手順書/（Ｂ）　完了指示書の処理関係/（Ｂ０－００）　作業終了後の指示書の処理.xlsx・（Ｂ６－００）　組付指示書の処理フロー図.xls参照)

【ヒアリングで判明・部分的】新實さんからgkdp・ktmpそれぞれについて業務内容の説明と停止理由の推測が得られたが、いずれも最終確認は新實さん本人ではなく別部署への追加確認待ちとなった。gkdpについて: 「号口品の組付にあたり、いつのロットの部品を使って生産したかのデータ。データが停止しているとすれば、ロット№の運用が現場で変わったのではないかと推測します。どちらにしてもトレースする必要があるので、そこは抑える必要があると思います（トレースできればどのような方法でも可）。製作部に確認してください」——前回の仮説（ITGO23R→ITGO22R一本化）とは異なる新しい仮説（ロット№運用の変更）が提示されたが、確定は製作部への追加確認待ち。ktmpについて: 「初回受注時に担当班を間違えて設定した場合に、関係するマスタ・データを一度で変更する。KSBS27→ITKS61R。使われていないとすれば、間違えていないか、それを使わなければいけない段階までいかないうちに訂正できているのではないか。営業部に確認してください」——ktmpの業務目的（初回受注時の担当班誤りの一括訂正）自体は確定したが、停止理由の確認は営業部への追加確認待ち。「まとめ指示」（kmdp）の業務フロー自体は上記の実資料調査で解明済みだが、2022年8月に停止した理由については今回のCSVにも直接の回答が無く、依然未解明のままである。 (出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【ヒアリングで判明・続報】kmdp（まとめ指示）が2022年8月で止まった理由が判明しました——廃止の意思決定であり、システム障害でもデータ欠損でもありません。経緯は「営業部からの依頼で作成したが、品質課からやめてほしいと営業部に依頼があって使用しなくなった」というものです。C6のkmdp残件は実質クローズ（「なぜ止まったか分からない」状態は解消）。品質課が中止を求めた具体的理由だけが残件として品質課への確認事項に移りますが、これは移行スコープには影響しない参考情報であり、「まとめ指示（指示形態31）を新システムで再現するか」の判断材料としては「業務として廃止済み」で十分です。C6の他の残件（gkdpのロット№運用変更→製作部、ktmpの停止理由→営業部）は今回も対象外で、引き続き他部署への確認待ちです。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（部分解決）gkdpの業務内容＝号口品の生産ロット紐付けデータ、ktmpの業務内容＝初回受注時の担当班誤り一括訂正（KSBS27→ITKS61R）と確定。停止理由はそれぞれ新實さんから推測（gkdp＝ロット№運用変更／ktmp＝誤り自体が起きなくなった）が示されたが、確定にはgkdpは製作部、ktmpは営業部への別途追加ヒアリングが必要——残る宿題。「まとめ指示」（kmdp）の業務フローは資料で解明済み、2022年8月に止まった理由も今回実質クローズ（営業部の依頼で作成→品質課が営業部に中止を依頼→廃止。中止理由の詳細は品質課への参考確認のみで移行スコープには無関係）

【解けると】死んだ機能を移植対象から外し、まとめ指示スタブの要否が確定。 (詳細: production.html §9 / proto-tooling.html / shipping.html §7)

C7 ★★ 部品構成の登録はどの画面でやっているか（構成登録の実体）

【手がかり】KSBS01（ITKS01R）画面のF5「構成登録」は ITKS10R を呼ぶ想定ですが、ITKS10R はどのメニューにもソースが見当たりません。実務では ITKS16R か KSBS41 が構成登録の代わりを果たしているか未確認。ITKS10Rは10年以上メンテナンスされてきたのに現在は呼び出し元を持たない孤立メンバーだと判定していた。設変時の単価自動更新ロジックは ITKS01R/10R/12R/16R のどこにも見当たらず、別サブシステムか手作業か不明です。

【実ソースで再訂正】前回の「孤立メンバー」判定自体が誤りだった。原因は調査手法のバグ：ITLIBS配下のRPG/CLソースは非UTF-8バイトを含むためfileコマンドが"data"（バイナリ）と誤判定し、grep -rを-aなしで実行すると当該ファイルが黙って検索対象から除外されていた。-aを付けて呼び出し元を再検索したところ、ITKS01R.txtのF5処理（76/100/120/142行目）にCALL 'ITKS10R'が実在し、さらにその親（KSBS01のCLソース83行目 CALL PGM(ITKS01R)）、そのまた親（MENUK1メニューのオプション1「受注品番データ登録」）まで辿ると、MENUK1→KSBS01→ITKS01R→（F5）→ITKS10Rという完全な到達経路が現行ソースに存在する。この経路は2010年・2015年の2つのITLIBSスナップショット（source/dev-archive/20101020_.../ITLIBS/、20151016_.../ITLIBS(変更前)/）でも一字一句同一で、ITKS10Rは過去15年以上、一度も呼び出し元を失っていない——「2020年の指示形態改革の周辺で廃止された」という前回の仮説は成立しない。3世代間には本体ロジックの実差分もある：2010→2015で構成ロックの検証メッセージが「構成展開済みの品番です」から「組付指示書発行済みの品番は、処理できません」に変わり（ロック条件自体の拡張）、2015→現行（2020-05-25、新實さん本人による改修）では判定条件がJUKUTN≠ブランクからJUD605が21〜29の範囲に置き換わった——C2で確定した指示形態51〜69グルーピングと対をなす「試作組付品（指示形態21〜29）」導入に、このBOMロック判定も追随した変更と解釈できる。なおITKS10RのF仕様（KSMP UF・JHMP/BHMP/NMMP/JUDL09 IF）には単価フィールドが一切無く、設変時の単価自動更新ロジックがこのプログラム内に存在しないことも確認できた——残る疑問はそちらのみ。(出典: source/as400-admin/transport-tooling/ITLIBS/{ITKS10R,ITKS01R,KSBS01,MENUK1}.txt、source/dev-archive/20101020_中止・数減処理に伴う在庫戻し/ITLIBS/ITKS10R.txt、source/dev-archive/20151016_AS400指示体制変更_中途で消滅/ITLIBS(変更前)/{ITKS10R,ITKS01R,KSBS01,MENUK1}.txt参照)

【ヒアリングで判明】実運用上の使い分けが確定した——「部品構成の新規登録はJSBS03→JSBS03C1（品番情報入力）→ITKS16Rで登録します（JSBS03C2＝構成データ修正、JSBS03C3＝受注入力、という兄弟オプションも存在）」「KSBS01（ITKS10R）は、入力されているデータを変更する場合に使用します。ただし構成展開が1件でも行われた場合は変更できません。その場合はKSBS41を使用します」——つまり左記で解明済みのMENUK1→KSBS01→ITKS01R→（F5）→ITKS10Rという経路は「新規登録」の入口ではなく、あくまで既登録データの編集専用経路であり、実際の新規BOM登録はJSBS03系（受注管理側）からITKS16Rを呼ぶ別経路が使われている。しかもITKS10R経由の編集は構成展開後にロックされる（ソース調査で確認済みの2015→現行のJUD605が21〜29の範囲ロック条件はこの「展開後は編集不可」という業務ルールのコード側実装だったと裏付けられた）ため、展開後の修正はKSBS41を使う二段構えの運用であることが判明した。設変時の単価更新についても明確な回答が得られた——「設計変更であっても、異なる品番で受注し直します（客先での変更を前提）。処理としては新規受注と同じです。単価入力は手動です」。つまりITKS10R/01R/12R/16Rのどこにも単価フィールドが無いのはバグでも欠落でもなく、設計変更＝別品番での新規受注という業務ルールで対応しているため、既存品番の単価を書き換えるロジック自体がそもそもどのプログラムにも存在しないのが正しい仕様と確定した。(出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【質問】（全項目解決済み：新規BOM登録はJSBS03→JSBS03C1→ITKS16R、既登録データの編集はKSBS01／ITKS10R（構成展開後はロックされKSBS41に切替）と確定。設変時の単価は「別品番での新規受注」として手動入力する業務ルールで対応しており、既存品番の単価を書き換えるロジックが存在しないのは仕様通りと確定）

【解けると】構成登録・設変単価更新の実画面が判明。 (詳細: engineering.html §12)

C8 ★ 計画表・出来高Excelマクロと「号口」の語源

【手がかり】計画表作成／Dekidaka のExcelマクロ内部ロジックはVBAソースがrepoに無く未検証（AS/400側ステージングデータをどう加工するか）。「号口（ごうぐち）」という言葉は業界共通語か板倉製作所固有の呼称か、一次資料に定義が見つかりません。

【ヒアリングで判明・部分的】「計画表」がどの計画表を指しているのか新實さん自身も特定できないとの回答だった（質問側の指示対象が曖昧だったことが判明——別途どのExcel/帳票を指すか特定して再質問する必要がある）。一方Dekidaka（\\Server2\Kanri\AS400設定\Dekidaka）＝号口出来高報告書についてはAS/400側の加工ロジックが具体的に判明した——「号口品の組付について個別の作業指示書は発行しない。作業担当者が受注の一覧表を基に生産順・生産ロットを判断して生産し、その結果を報告する用紙が号口出来高報告書。ロット№をユニークにするため、AS400側で品番とロット№（連番）をセットしたデータを枚数分作成し、Excel経由で号口出来高報告書として印刷する。WSBS04が処理オプション」。「号口」の語源については「由来はわからない。トヨタ関連の企業では一般的な用語だと思っている（この会社で知った）」——由来そのものは今回も未解明だが、板倉製作所固有の造語ではなく、トヨタ系企業で一般的に使われる業界用語である可能性が高いという新實さん自身の認識が得られた。 (出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【ヒアリングで判明・続報】2ラウンド続けて「質問が具体的に特定できません」という同じ回答でした——質問の立て方自体が原因であることが確定し、「計画表」という語だけでは新實さんの側で対象を同定できないと分かりました。C8は未解決のままですが、次に進めるべき手は明確になりました。次ラウンドでは「計画表」という語を使わず、具体的なファイルパスまたは帳票名を列挙して「これはどれですか／どれでもないですか」形式で提示すること。候補の洗い出し（\\Server2配下の生産計画系Excel、AS/400側の帳票出力プログラム名）は当方の宿題であり、新實さんに投げる前にやっておく必要があります。この方針転換を経ずに同じ質問を繰り返しても結果は変わりません。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（未解決継続）Dekidakaマクロ（号口出来高報告書、WSBS04処理オプション、品番＋ロット№連番をAS/400側でセットしExcel印刷）は解決済み。「計画表」は2ラウンド続けて新實さん自身も対象を特定できず、質問の立て方自体が原因と確定——次ラウンドでは「計画表」という語を使わず、当方で候補ファイルパス／帳票名を洗い出した上で「これはどれですか」形式の選択式で再質問する必要がある。「号口」の由来自体は依然不明（トヨタ系業界共通語との認識のみ得られた——これ以上の裏取りは困難な可能性が高い）

【解けると】計画表マクロの移植と用語集の裏取り。 (詳細: production.html §9)

C9 ★★ 得意先向け納品書・直送・締日

【手がかり】SSBS01／ITND50R はプルーフリスト（内部証跡）のみで、得意先向けの納品書・受領書は発行しません —— 得意先向けは「出荷準備」Excelジョブ側で別途作成らしいがツール・タイミング不明。得意先ごとの納入先マスタは TKMP 以外に見つからず、直送（得意先を経由しない出荷）の明示フラグ・分岐も無い。ITND50R には SIMEBI（締日）引き継ぎバグ（TK1P レコードの無い得意先を処理すると直前の受注の締日を誤って引き継ぐ疑い）があります。

【ヒアリングで判明・部分的】得意先向け正式納品書の実態が確定した——「基本的に納品書は客先指定納品書が中心。受注後客先より印刷されたものを渡されるか、データで受け取って印刷するものが多い。手書き伝票だが客先指定のもの、当社の手書き伝票と混在しているが、納品書をAS400から発行することはない。製品が完成し（在庫含む）納期が一定期間内になったら、出荷指示書がAS400より発行され、それを元に納品書を手書きで記入、出荷指示書が営業課に回収され、営業課で出荷入力される」——つまり「出荷準備Excelジョブ側で別途作成」という左記の推測は誤りで、得意先向け納品書はAS/400からもExcelジョブからも発行されず、客先支給または当社手書きのいずれかであり、AS/400が発行する出荷指示書は納品書そのものではなく、営業課が手書き納品書へ転記するための社内トリガーに過ぎないことが判明した。直送については「直送は少ないがある。いずれも客先指定伝票と記憶している（営業課に確認要）。特に通常納品と区別することはしていない（納める先が違うだけ）」——直送用の明示フラグ・分岐がソース上見つからなかったのは正しく、そもそも業務側でも通常納品と特に区別していないことが確認できた。ただし新實さん自身「記憶している」という留保付きであり、確定には営業課への追加確認が必要と明言された。SIMEBI（締日）引き継ぎバグについては今回のCSVで直接の言及は無く、未解明のまま。 (出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【ヒアリングで判明・続報】SIMEBI締日引き継ぎバグについて、新實さんからバグの実在が明示的に確認されました——「ご指摘のバグはその通りです。」。合わせて2つの新情報も得られました。1) なぜ起こりにくいか: TKMPとTK1Pは毎月レコードが一致するよう運用されており、JUDPの得意先コードはTKMPを参照して入力するため、TK1Pレコードの無い得意先がITND50Rに流れてくる状況自体がほぼ発生しません（運用による回避）。2) SIMEBIガードの設計意図（これまで文書化されていなかった）: 「基本的に請求済みの期間では入力できないようにするためのもの」——つまりNOHIXX IFLE SIMEBIは締切済み会計期間への遡及入力を防ぐガードであって、単なる日付妥当性チェックではありません。当方の対応状況は既に修正済みです。移植版pilot/app/src/menus1/shipmentEntry.ts:309-320は得意先ごとにTK1Pを都度SELECTし、ヒットしなければガード自体を掛けない実装になっており（pilot/DEVIATIONS.md #36として逸脱登録済み）、回帰テストpilot/app/test/menus1/itnd50.test.ts:485-506がTK1Pのある受注101でブロックされた後にTK1Pの無い受注102が通ることを固定しています。さらにT1MR（TK1P）をCHAINする全9本（ITND50R / ITS995R / ITS994R×2 / ITS996R / ITJM38R / ITJM38RA / ITS001R / ITS001RX1）を機械的にスイープした結果、ELSEリセット漏れはITND50Rのみで、同種の潜在バグは他に存在しないことも確認しました。C9のSIMEBI項目は完全クローズ（バグ実在確認→既に修正済み→テストで固定→横展開スイープ完了）。C9の他の残件（直送の実態を営業課に確認）は今回も対象外で継続です。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（一部解決）正式納品書の発行元は解決済み：AS/400からもExcelジョブからも発行せず、客先指定伝票または当社手書き。AS/400発行の出荷指示書は営業課が手書き転記するための社内トリガーに過ぎない。直送は「少ないがある、客先指定伝票、通常納品と区別なし」との回答だが新實さん自身が記憶ベースの留保付きで述べており、営業課への追加確認が必要（未確定）。SIMEBI締日引き継ぎバグは完全クローズ——バグの実在を新實さんが確認、運用（TKMP/TK1P月次一致）による回避で発生頻度は低いが「発生の可能性はゼロではないので修正できれば修正したほうが良い」との回答も得て、移植版で既に修正済み・回帰テストで固定・全9本の機械的スイープで同種バグ無しを確認済み。SIMEBIガードの設計意図（請求済み期間への遡及入力防止）も新たに判明

【解けると】納品書発行と直送フローを移植版に実装できる。 (詳細: shipping.html §7)

C10 ★ 図面整理・レーザー№・欠落メニュー等の技術情報詳細（参考）

【手がかり】図面整理_AS400_To_Excel.xlsm／図面整理_Excel_To_AS400.xlsm の中身と KSBS13（保管図面データ処理、使用停止）の連携は未解析。 【実VBAで解明】 2本のマクロはHNXPP1（品番＋最終納期の索引ファイル）を介してKSBS13（ITRD01R）と往復する年次棚卸しワークフローの前後半（Excel→AS400でアップロード、AS400→ExcelでRidocの黄色ハイライト作成）でした。手順書RidocSmartNavigatorの図面を整理する場合の手順.docも現存。詳細は engineering.html §8.1。 C1_Laser/C1金型一覧.xls と KSBS14/16/18（レーザー№関連）の連携も類推止まり。KSBS02/04/06/08/12/15/17/19/21〜24（ソース欠落の偶数番オプション群）は空きメニューか未回収か不明。MSBS18 と TAMP が同一テーブルか、KTMPP1 への DUMMY 行スキップ漏れ（潜在バグ）、KSBS25/26 のDFUレーン詳細も未確認です。

【ヒアリングで判明・部分的】「レーザー№」の定義が確定した——「レーザー加工する際のNCデータのファイル名と認識。プレス品作成時のブランクの切断、あるいはプレス成形後の外形トリムといった工程をレーザー加工機で加工する際に使用する」（C1_Laser/C1金型一覧.xlsとKSBS14/16/18との具体的な連携経路そのものは今回も類推止まりで未解明）。空いて見えるKSBS偶数番メニューについては、個別の項目単位ではなく一般論としての回答が得られた——「KSBSに限らず、一度オプション指定したものを使わなくなったために削除したことは多々ある。その際、ソースは残して参考にしたい場合、メニューから削除するだけにして本体は残している場合がある。ただしメニューに表示されないものは現在使用していないものなので、対象から外して問題ない」——つまり「なぜKSBS02/04/06/08/12/15/17/19/21〜24個々が欠番なのか」という項目別の謎自体は依然解明されていないが、メニューに表示されない＝現在は非稼働で移行対象から除外して問題ないという実務上の判断基準は確定した。あわせてKSBS13（ITRD01R）は「メニューに表示があるが、表示通り使用停止している（図面整理作業そのものをしないようにした）」と明言され、メニュー表示＝現役という対応関係も裏付けられた。(出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【ヒアリングで判明・続報】空いて見えるKSBS偶数番メニューについて2点が確定しました。1) 移行対象からの除外が明示的に承認されました（従来は当方の一般原則からの推論でした）——「KSBS偶数番メニューは、現在は非稼働で移行対象から除外して問題ない」。2) 欠番の理由も判明しました——「単に可視性を上げるために、空白行を作るようにしている。（可能な場合）」。つまりKSBS02/04/06/08/12/15/17/19/21〜24が空いているのは個別の廃止事情があるからではなく、メニュー画面の可読性を上げるために意図的に空白行を作っているためで、「偶数番が欠番」は偶然ではなくレイアウト都合だったということです。C10のKSBS欠番項目は完全クローズ。C10の残件（C1_Laser↔KSBS14/16/18の連携）は今回も対象外で継続します。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（部分解決）「レーザー№」＝レーザー加工機用NCデータのファイル名と確定（C1_Laser/C1金型一覧.xlsとKSBS14/16/18の連携経路自体は依然未解明、残る宿題）。空いて見えるKSBS偶数番メニューは完全クローズ——移行対象からの除外が明示的に承認され、欠番は可読性向上のための意図的な空白行と確定した（項目別の個別事情自体は無く、実害の無い参考情報だった）

【解けると】技術情報周辺の残り論点を一括で潰せる。 (詳細: engineering.html §12)

C11 ★ RidocSmartNavigatorは今も稼働していますか？

【手がかり】ridoc.csvの各行にはhttp://server8.itakura.co.jp:8080/rsn/DocViewer?CabID=...&DocID=...という実URLが入っており、RidocSmartNavigator（Ricoh製の文書管理システム、旧「Ridoc Desk 2000」の後継）がserver8上でWebアプリとして稼働していた（している？）ことまでは分かります。一方、この文書をAS/400側と突き合わせて「旧図キャビネットへ移動すべきか」を判定するKSBS13/ITRD01Rの経路は2026/06/10のACS移行で完全に停止しており（§C10参照）、Excel側の年次棚卸しフロー全体も2024/01の時点で業務として止まっています。つまりRidoc自体（保管・閲覧）と、AS/400と連動した棚卸し判定（KSBS13経由）は別物で、後者が止まっても前者が動き続けている可能性があります。フォルダ内のridoc.csv.*.partialという未完了ダウンロードの断片ファイルの由来も不明です。

【ヒアリングで判明】手がかり欄で予想していた切り分けがそのまま確定した——「RidocSmartNavigatorは稼働中です。図面整理作業（旧図フォルダへの移動）はしないようにした」。つまりRidoc自体（保管・閲覧）は今も現役で使われており、止まっているのはAS/400と連動した棚卸し判定（KSBS13経由の旧図キャビネット移動判定、§C10で確認済みの2026/06/10 ACS移行に伴う停止）だけという、両者は別物という理解が新實さん本人の証言により裏付けられた。(出典: 新實さん、2026-07-23ヒアリングシート回答C、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-C.md参照)

【質問】（解決済み：RidocSmartNavigator自体は稼働中——図面・指示書の保管・閲覧は現役。2024年1月以降止まっているのは旧図フォルダへの移動（AS/400連動のKSBS13経由棚卸し判定）だけで、Ridoc本体の運用とは別物と確定）

【解けると】図面保管業務が現在も生きているか、完全に形骸化しているかが分かり、移植要否の最終判断ができる。 (詳細: engineering.html §8.1)

D1 ★★ サイレントに失敗しうる試作パイプライン

【手がかり】(a) TSBS01C に MONMSG MSGID(CPF0000)（全エラー握りつぶし）指定があり、指示数計算パイプラインの途中が失敗しても画面に何も出ず後続が走る（tsbs01c.md:41-56）。(b) TSBS06（ITTS22R）の完成カウンタ KENSU が一度も増えず、BAT1006（仮出庫指示取消連絡）が常に呼ばれない可能性＝指示を中止しても仮出庫の取消連絡が現場に届かない（itts22r.md:165）。

【実資料で判明】(b) の配線（TSBS01→TSBS01C→ITTS51Rと、TSBS06←ITTS22R→BAT1006「仮出庫指示取消連絡」）は2010年の設計文書（中止・数減処理に伴う在庫戻し）により実在する意図的な配線であることが確認できた（偶然の死んだコードではない）。さらに現在進行中の2026年の調査文書（仮出庫指示書発行不具合調査）により、ITSJ83R／ITSJ86Rが仮出庫指示書を先行発行（3日窓、状態変更なし）する一方、完成時には上流の通知状態と無関係にITTS13Rが仮出庫指示の再発行と実際の在庫引当を独立して再実行することが判明した——つまり万一BAT1006が発火しなくても、実在庫の数字自体はITTS13Rの独立再引当で正しく保たれる設計であり、被害の実体は「現場への紙・連絡の伝達漏れ」であって「在庫数の破損」ではない可能性が高い。ただし同2026年調査は「KENSUが一度も増えない」というこの手がかり自体を直接検証・反証しておらず、この点は依然未確認。加えて、社内手順書（Ｅ－０２）／（Ｅ－０３）／（Ｅ－０６）／（Ｅ－０７）（受注状況の変更）により、終了区分＝9への変更を10.試作管理→6.試作作業指示変更（＝ITTS22R）で行う操作は、これらの受注区分における標準・必須・日常的に実行される正規の中止手順であることが確認できた——つまりこのバグが実在するなら「稀な例外」ではなく「日常的な中止操作のたびに毎回発生する」規模の問題になる。(出典: source/dev-archive/20101020_中止・数減処理に伴う在庫戻し/参照、source/dev-archive/20260512_仮出庫指示書発行不具合調査/参照、source/work-procedures/作業手順書/（Ｅ）　受注状況の変更/（Ｅ－０２）・（Ｅ－０３）・（Ｅ－０６）・（Ｅ－０７）各参照)

【ヒアリングで判明】(b) のバグは新實さん自身によって実在が直接確認され、既に修正済みであることが判明した——「ITTS22Rで『仮出庫指示取消連絡』がされないバグを確認しました。修正しました」。資料調査が組み立てた仮説（KENSUが増えずBAT1006が呼ばれないバグが実在し、10.試作管理→6.試作作業指示変更を使う日常的な中止操作のたびに毎回起きる規模の問題）は、規模の見立てまで含めて裏付けられた。ただし実害については、この不具合によるトラブル報告の記憶は新實さんにもなく、「たぶん、現場で対応して新實まで上がってこなかったことがあったと思われる」とのこと。加えてTSBS06の処理自体もそもそも稀な処理で、その中でも仮出庫指示取消連絡をすべきケースはかなり稀だったとも述べており、資料調査が見立てた「実在庫は保護されており実害は伝達漏れ」という読みとも整合する。この修正は板倉製作所側の稼働中AS/400（移行元システム）に対して行われたものであり、本移行プロジェクトが今後ソースを再取得する際は、修正前の旧バグ挙動ではなく修正後の挙動を忠実に再現する必要がある——移行版で新たにこのバグを作り込んではならない。(a) TSBS01C の全エラー握りつぶし（MONMSG CPF0000）については、新實さん自身は認識がなく、営業部・製作部等への確認が必要と回答があった——この小論点は今回も未解決のまま残る。(出典: 新實さん、2026-07-23ヒアリングシート回答D、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-D.md参照)

【質問】（(b)解決済み：ITTS22Rの仮出庫指示取消連絡バグは新實さん本人により実在確認・修正済みと確定。トラブル報告の記憶はなく、実害は現場レベルで対応・吸収されていた可能性が高い。実在庫の数字自体はITTS13Rが独立して保護しており、被害は「現場への連絡・紙の伝達漏れ」という運用面の話に留まる。残る確認事項: (a) TSBS01Cの全エラー握りつぶしの実害については新實さんも未認識のため、営業部・製作部への追加確認待ち）

【解けると】握りつぶしバグの実害を確認し、移植で顕在化させるか判断できる。 (詳細: proto-tooling.html §9)

D2 ★★ 金型の資産評価・償却・型費請求の所在

【手がかり】金型マスタ mdmp（得意先コード mdcdtk・持出コード mdcdmd はある）に償却・金額フィールドが一切無く、決定ログ・仕様にも金型費請求の記述が無い＝会計処理は別系統（Excel等）の可能性。請求側でも型費の扱いが不整合（ITS000R は単価に折り込む、ITS001R は別項目のまま出力）——この点自体はF3で別途解決済み。外注金型（型屋への外部発注）専用画面も MENUB1 内に見当たりません。

【ヒアリングで判明】金型マスタmdmpが資産価値ではなく存在・所在だけを管理する理由が確定した——板倉製作所の会計上の立場では、金型はすべて客先所有の資産であり、当社側で資産として保有しているものはそもそも存在しない。したがって資産計上・償却の管理はしておらず、型費としての管理もしていない（＝「見つからなかった」のではなく「対象が無いので存在しない」）。型屋への金型外注発注についても「金型を外注したことはありません」と明確に否定された——プレス部品を外注する際に金型を伴う場合はあるが、それも別途管理していない。つまりD2の2つの手がかりはいずれも「別の帳簿・画面が見つかっていないだけ」ではなく「その業務自体が板倉製作所には存在しない」という形で解消された。(出典: 新實さん、2026-07-23ヒアリングシート回答D、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-D.md参照)

【質問】（解決済み：金型はすべて客先所有の資産であり、板倉製作所側に資産計上・償却の対象がそもそも存在しないため会計処理も存在しない。型屋への金型外注実績もゼロ——プレス部品外注に金型が伴うケースはあるが、その場合も別立て管理はしていない。型費表示方式の不整合はF3で別途解決済み。残る未解明点なし）

【解けると】金型会計の所在と外注金型フローが判明。 (詳細: proto-tooling.html §9 / finance.html / engineering.html)

D3 ★★ 意味不明のコード値（B／J・1／2／3）を記憶で埋める

【手がかり】(a) zkdp（試作品在庫データ）の在庫区分 zkkuzk が B（215件）と J（352件）の2値のみで意味の説明が無い（B＝部品／J＝治具？B＝本社／J＝事業所？）。(b) sjlp（試作作業指示書発行ログ）の指示区分 l1kusj が 1（13,504件）・2（14,524件）・3（9,262件）の3値のみ（新規／再発行／変更？）。

【ヒアリングで判明】(a) B＝試作の組付部品、J＝試作の単品出荷品と確定した——手がかり欄が挙げていた「部品／治具」「本社／事業所」いずれの仮説も外れており、実際は出荷形態の違いだった。(b) 1＝単品出荷品用（試作品）、2＝組付部品用（試作品）、3＝号口品用／号口出荷品用と確定し（こちらも「新規／再発行／変更」という仮説は外れ）、さらに新實さんの回答からは手がかり欄のデータ調査が把握していなかった4番目の値（4＝号口組付用）が実在することも判明した——sjlpの実データ調査では1〜3の3値しか観測されていなかったが、コードの取りうる範囲自体はそれより広い。移行版のコード表・screen-help.jsonへの反映時は、4という値が実データに一度も出現していない（＝稀にしか使われない、または対象期間・対象データに現れていないだけ）可能性を踏まえ、sjlpの生データを再確認する価値がある。(出典: 新實さん、2026-07-23ヒアリングシート回答D、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-D.md参照)

【質問】（解決済み：zkdpのB＝試作の組付部品、J＝試作の単品出荷品。sjlpの指示区分は1＝単品出荷品用（試作品）、2＝組付部品用（試作品）、3＝号口品用／号口出荷品用、4＝号口組付用の4値と確定——実データ調査で観測されていた1〜3の3値に加え、4番目の値が新たに判明した点はproto-tooling.html未解明事項への反映が必要）

【解けると】画面ヘルプのグロッサリーに正式名称を追記できる。 (詳細: proto-tooling.html §9)

D4 ★ ロット№マスタ・材料/工機Excel・保管期限再計算の詳細

【手がかり】rnmp（ロット№マスタ）は jhmp と99.0%リンクする生きたデータだが、書き込み元プログラムが未特定（MENUM 系保守経由と推測）。材料管理/・工機課管理/ 配下のExcel/VBAサテライトジョブは未解析【実VBAで解明】両系統とも解読済み（proto-tooling.html 参照 — 新たな確認事項はD5へ）。ITMD09R/ITMD10R/BAT0726（ZSBS26 パイプライン、保管期限再計算）は仕様書TBDで計算式が未確認です（自動倉庫分の判定ルールはVBAで発見済み — 「作成/最終出荷/最終入庫から1年・号口5年」）。

【ヒアリングで判明】ロット№の採番元が判明した——\\Server2\Kanri\AS400設定\Dekidaka配下でWSBS04が号口出来高報告書を印刷する際に採番される。号口品の組付については個別の作業指示書は発行せず、作業担当者が受注の一覧表を基に生産順・生産ロットを判断して生産し、その結果を報告する用紙が号口出来高報告書。ロット№をユニークにするため、AS400側で品番とロット№（連番）をセットにしたデータを枚数分作成し、Excel経由で印刷する（一度に1品番あたり10枚程度）。営業部の人が製造担当に依頼されて発行していると思われるが、新實さん自身「要実際確認」と留保しており、発行依頼の起点（営業部か製造か）は現場での追加確認が必要。ZSBS26の保管期限再計算については「同じ設定でよいと思うが、あくまでも廃棄候補をリストするための目安。客先で異なるルールがあり、営業部に確認してください」との回答で、VBAで見つかった「1年（号口5年）」ルールとおおむね同じである可能性は高いが確証ではない——目安に過ぎず客先ごとに例外がありうるため、こちらも営業部への確認待ちの残件。(出典: 新實さん、2026-07-23ヒアリングシート回答D、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-D.md参照)

【質問】（大筋解決：ロット№はWSBS04が号口出来高報告書を印刷する際に、AS400側で品番＋連番データを作成しExcel経由で印刷する形で採番。ZSBS26の保管期限再計算もVBAで見つかった「1年（号口5年）」ルールとおおむね同じ想定だが、あくまで目安であり客先ごとに例外がありうるとのこと。残る確認事項: 新實さん自身が両点とも「要確認」と留保しており、①ロット№発行依頼の起点（営業部か製造か）、②ZSBS26ルールの客先差異、は営業部への追加確認待ち）

【解けると】工機・材料周辺の残りマクロと計算式を文書化できる。 (詳細: proto-tooling.html §9)

D5 ★★★ 工機課・資材の「影の購買」—— AS/400に載らない買い物と支払の突合

【手がかり】VBA解析で、2系統の購買がAS/400（MENUG1／SFDP）を経由せずExcelだけで回っていると判明: (a) 工機課の工具鋼購買（設計材料発注書.xlsm — 山一ハガネ／中野ハガネ／藤巻工範、オネストン発注書.xlsm）。(b) 資材のコイル材・大板材購買（材料発注依頼書.xlsx 台帳、発注書はFAX・アイシン向けはメール）。さらに設計材料発注書は2018年7月にデータ消失事故（復元不能）を起こし、以後「保存毎スナップショット」運用が2026年3月現在も続いています。

【ヒアリングで判明】(a) 支払の管理データはServer2\Soumu_C2\経理\担当者専用\支払業務\請求金額入力.xlsx——各仕入先からの請求書をもとに手入力する。その後AS400へ取り込み、手数料計算をして総合振込データ.xlsxを作成、新實へメール送信。そのデータをもとにインターネットバンクで振込データを手入力で作成する、という流れ。肝心の「Excel台帳と経理入力の突合はあるか」という問いには、AS/400を経由しない2系統の購買（工機課工具鋼・資材コイル材/大板材）と経理入力の間に自動的な連携は一切ないことが確定した——設計材料発注書.xlsm等は発注・入荷を管理しているが、経理とはシステム的に接続されておらず、新實さんが請求書の内容と発注の内容を手作業で突合している。つまりSHDP種別2（材料）／3（工具）への入力自体は請求金額入力.xlsxを介した通常の支払フローに乗るが、その手前で「この請求書は本当にこの発注と対応しているか」を検算する工程が完全に属人的な手作業であるという実態が判明した。(b) Excel台帳消失への備えについては今回直接の追加言及がなく、2018年7月の消失事故以降続く「保存毎スナップショット」運用が唯一の備えという既知の情報のまま残る。(出典: 新實さん、2026-07-23ヒアリングシート回答D、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-D.md参照)

【質問】（(a)解決済み：支払管理は請求金額入力.xlsxへの手入力→AS400取込→手数料計算→総合振込データ.xlsx→新實メール受領→インターネットバンク手入力、という流れ。工機課工具鋼・資材コイル材/大板材の2系統の購買と経理入力の間に自動連携はなく、新實さんが請求書と発注内容を手作業で突合しているのが実態。(b)は今回言及なし——2018年7月の消失事故以降のスナップショット運用が唯一の備えという既知情報のまま、未解決で残る）

【解けると】AS/400外の購買2系統が支払とつながり、移行時に取り込むか別立てかを判断できる。 (詳細: proto-tooling.html / finance.html)

D6 ★ 金型まわりの小さな確認 —— アイシン廃棄承認と「C1」台帳

【手がかり】(a) アイシン精機金型廃棄リスト作成.xlsm は「MJMPからアイシン納入実績のある金型を抽出」します — 得意先所有金型の廃棄に承認手続きがある示唆。(b) C1_Laser/C1金型一覧.xls（2011年作成）はアマダ系タレパン「C1」号機のパンチ金型台帳で、AS/400ともレーザー№とも無関係の完全ローカル管理でした。

【ヒアリングで判明】(b)「C1」の正体が確定した——レーザー加工複合機（レーザー加工と金型の抜き工程を1台でこなす設備）であることが新實さんにより直接確認された。これはengineering.html §6.4がVBA解析から立てていた推測（「フォルダ名のLaserは、C1がレーザー・パンチ複合機であることに由来すると考えられる」）を裏付ける直接証言である。ただしC1金型一覧.xls台帳が今も使われているかどうかは新實さんの担当範囲外で、製作部への確認が必要と回答があった。(a) アイシン所有金型の廃棄に先方承認が必要かどうか、他の得意先で同様の運用があるかについては、新實さんご自身は把握しておらず、営業部への確認が必要と回答があった。D6の2問はいずれも一部は新實さん本人により解決したが、残りは他部署への追加確認待ちとなった。(出典: 新實さん、2026-07-23ヒアリングシート回答D、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-D.md参照)

【質問】（(b)一部解決：C1＝レーザー加工複合機（レーザー加工と金型の抜き工程を1台でこなす設備）と確定。台帳が今も使われているかは製作部への確認待ち。(a)は新實さんも未把握——アイシン所有金型廃棄の先方承認要否・他の得意先での同様運用の有無は営業部への確認待ち）

【解けると】金型廃棄の対外手続きが文書化でき、C1台帳の移行要否が決まる。 (詳細: proto-tooling.html / engineering.html)

E1 ★★★ 受入〜検収〜支払は実際どう回っているか（二重入力・突合なし）

【手がかり】(a) GSBS06 が作る支払明細書（SFDP 側金額）と、経理が MENUR1/RSBS01 で SHDP へ手入力する請求金額は別々に管理され自動連携が無い＝二重入力・転記ミスのリスク。(b) 受入入力 ITSI04R 内に検収（品質合否判定）を記録する独立工程・フィールドが無い。(c) 受入完了時に埋まるはずの SFDP フィールド（納入数・決定単価・納入金額）に値があるのは全23,194件中わずか99件（0.4%）で、しかもほぼ2020〜2022年に集中。

【ヒアリングで判明】この3つの手がかりが前提としていた「二重管理・突合なし問題」自体が、より根本的な事実で解消される——「MENUG1はほとんど停止しています。注文書を印刷するためだけに使用しています。受入れの入力もしていませんし、支払明細の発行もしていません。注文書は下請法に定められた記入項目を網羅するために定めた様式で発行できるように運用しています」。つまりMENUG1（外製管理サブシステム）は実質的に注文書（発注書）印刷専用ツールに縮退しており、(a)で問題視した「GSBS06の支払明細書とSHDP手入力の二重管理・突合なし」は、そもそもGSBS06側の受入入力・支払明細発行自体が運用されていないため、突合すべき「もう一方」が実在せず問題として発生し得ない。(b)の「受入入力内に検収記録フィールドが無い」も同じ理由で、受入入力そのものが行われていないので検収記録の要否自体が生じない。(c)の実データが全23,194件中わずか99件（0.4%）・2020〜2022年に集中という数字も、この「受入入力は運用していない」という事実と整合的である——ごく一部だけ試験的・例外的に入力された名残と解釈するのが自然（ただしこの2020〜2022年クラスタの具体的な経緯を新實さんが直接確認したわけではなく、あくまで整合的な推測にとどまる）。注文書自体は下請法対応の記入様式として今も現役で発行され続けている。(出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)

【質問】（解決済み：GSBS06側の受入入力・支払明細発行はそもそも運用されておらず、MENUG1は注文書印刷専用に縮退している。したがって(a)の二重管理・突合問題、(b)の検収記録フィールド欠如、(c)の実データ0.4%・2020〜2022年集中、いずれも「受入入力が運用されていない」という一つの事実で説明される。残る確認事項: 新實さんより「すべての外注先に注文書が発行されているかは営業部へ確認してください」との留保が付いており、注文書発行の網羅性（全外注先に対して発行されているか）は営業部への追加確認待ちの小さな残課題）

【解けると】受入〜支払の実運用が判明し、二重入力の解消と受入データ欠落の原因が分かる。 (詳細: outsourcing.html / finance.html / daily-rhythm.html)

E2 ★★ 単価通知・分納受入・受入後変更などの実運用有無

【手がかり】現場向け確認シート staff-review-menug1.md の未回答項目群:(a) ITSI04R は「外製受入入力（単価通知なし）」で、更新時に SFKUTT＝9（単価連絡表発行済扱い）を強制設定 —— 「単価通知あり」版は未発見。(b) 分納受入は2回目の受入が1回目を上書きしてしまう仕様。(c) 受入済みの発注を中止すると支払明細書の集計から外れ支払われなくなるが、現行は止めない（A-3）。(d) 再発行時に単価連絡表を出し直すか、対象月0件で支払明細書を出すか（C-3／C-4）。

【ヒアリングで判明】「現在は、運用していません。」——E1で判明したとおり、MENUG1系の受入入力（ITSI04R）自体がそもそも運用されていないため、分納受入・受入後の発注取消・単価連絡表の再発行のいずれの実務シナリオも発生しない。つまり(a)〜(d)で挙げた各コードパスの仕様・潜在バグ（単価通知ありなし、分納時の上書き仕様、受入済み発注中止時の集計除外、単価連絡表再発行時の分岐）は、コードとして存在すること自体は事実だが、いずれも実運用で到達されることのない未使用経路であることが確定した。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)

【質問】（解決済み：分納受入・発注後の取消・単価連絡表の再発行、いずれも「現在は運用していません」との回答。E1で確定した「MENUG1系の受入入力自体が運用されていない」という事実と整合し、これらの潜在バグ・分岐が実運用で顕在化することはない）

【解けると】新システムでどこにエラーガードを入れるか（A-3／C-1〜C-4）が確定。 (詳細: outsourcing.html)

E3 ★★ 表面処理コード名と仕入先「使用停止」フラグの実態

【手がかり】(a) 型種コード 100-399＝表面処理は SFDP 全件の93.6%（21,714件）を占めるが、個別コード名（めっき／熱処理／塗装 等）の一覧が未解明（LTTY01R 実データ要確認）。(b) SIMP.SIKBWK を「使用停止フラグ」と読んできたが、schemaコメントは「処理区分」で、実データでは SIKBWK='E' の仕入先の方が空欄より多く SFDP に登場し「E＝使用停止」と矛盾。

【ヒアリングで判明・部分的】(a) 型種コードの一部が判明した——「100番台＝鍍金。200番台＝塗装（と設定したと思うが、今どの程度運用されているかは営業部に確認要）」。100番台＝鍍金、200番台＝塗装と確定したが、新實さんご本人も「設定したと思う」という記憶ベースの回答であり、現在の実運用での該当度合いは営業部への追加確認が必要と明言された。300番台については今回言及が無く、依然未解明のまま。(b) SIMP.SIKBWK='E'は「使用停止です。」と明確に確認された——schemaコメントの「処理区分」表記とは無関係に、当初の「E＝使用停止」という読みが正しかったことが確定した。ただしこの確認はSIKBWKの意味そのものを確定させるものであり、実データで「E＝使用停止の仕入先の方が空欄より多くSFDPに登場する」という一見矛盾に見える現象自体の理由は今回の回答では説明されておらず、別要因として未解明のまま残る。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)

【ヒアリングで判明・続報】(b) 「矛盾」という当方の前提自体が誤りでした。新實さん: 「ながいこと仕事をしていると、付き合う仕入先も変わっていく。全く付き合わなくなったり、廃業されたりしてもデータをしては残しているので、使用停止の仕入れ先の方が多いのはむしろ当然。」——つまりSIMPは物理削除をしない累積台帳（論理削除方式）であり、取引終了・廃業した仕入先もレコードとして残ります。SFDP（発注実績）は過去分も含む履歴なので、何十年分の累積では「もう使っていない仕入先」の方が「現役の仕入先」より多く登場するのは当然でした。これは矛盾ではなく、マスタ設計の当然の帰結です。E3(b)は完全クローズ。移行への含意: 新システムでもSIMPは論理削除を維持すべきです（過去の発注履歴が参照する仕入先レコードを物理削除すると履歴が壊れる）。SIKBWK='E'は「新規発注時の選択候補から外す」フィルタとしてのみ使い、履歴表示では使わないこと。E3(a)（表面処理コード300番台の意味）は今回も未回答で継続です。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（部分解決）(a) 100番台＝鍍金、200番台＝塗装と判明したが、新實さんご本人の記憶ベースの回答であり現在の実運用状況は営業部へ確認要。300番台は今回も未回答のまま継続。(b) 完全クローズ——SIKBWK='E'＝使用停止という意味に加え、E側の仕入先の方がSFDPに多く登場する現象も「矛盾」ではなくSIMPが物理削除しない累積台帳（論理削除方式）であることの当然の帰結と確定。移行後もSIMPの論理削除は維持し、SIKBWK='E'は新規発注候補の絞り込みフィルタとしてのみ使う（履歴表示には使わない）

【解けると】表面処理コード表と SIKBWK の正しい意味が確定し、画面ヘルプに反映できる。 (詳細: outsourcing.html)

E4 ★ 内外コード'10'・欠落GSBS・外注Excelマクロ

【手がかり】内外コード '10' の正確な意味（部品リンクとしての用法と KSMP の意味の関係）が不明。GSBS05/07/08/09/11/12/14-21/23-26（19本）はソース欠落で機能不明（D6調査で実運用では未使用の可能性が高いと判定済み）。BAT0201.XLSM／BAT0206.XLSM の内部ロジックは未解析。

【ヒアリングで判明】内外コード'10'の意味が確定した——「10は組み付ける途中の中間S/Aの品番です。板倉の構成データは2階層のみ（完成品＝受注品番、と何も組み付いていない部品のみ）で登録される。実作業では順に組み付けていくと中間の状態を表すS/A品番があるが、無視して2階層のみにしている。ただしS/A品番で治具を外注したりするケースがあり、S/A品番の存在がないと不便なので「10」で通常の部品と区別して構成マスタに追加している（構成展開上は無視する）」。つまり板倉のBOMデータモデルは意図的に2階層（受注品番／未組付部品のみ）に単純化されており、実際の多段階組立工程で生じる中間サブアセンブリ（S/A）状態は構成展開上は意図的に無視・畳み込まれる設計だが、その中間S/A品番自体を独立して外注（治具作成等）に出す必要がある例外ケースだけ、通常部品と区別するために内外コード'10'でタグ付けし、構成マスタに存在だけを記録している（構成展開時にはこの'10'は無視される）——技術的に筋の通った完全な説明が得られた。あわせて外注帳票のExcel（BAT0201／BAT0206）についても「外注への注文書です」と確認され、これらのマクロが印刷しているのは外注先への注文書であることが確定した。GSBS05/07/08/09/11/12/14-21/23-26（ソース欠落19本）については、今回の回答では言及が無く、D6調査時点の「実運用では未使用の可能性が高い」という判定以上の進展はなく、依然未解明のまま（もともと本カードの質問がこの19本の廃止可否を直接尋ねたものではない点に留意）。 (出典: 新實さん、2026-07-23ヒアリングシート回答E、docs/feedback/hearing/2026-07-23-niimi-hearing-sheet-E.md参照)

【ヒアリングで判明・続報】GSBS05/07/08/09/11/12/14-21/23-26（19本）について「未使用」との回答が得られました。D6調査で「実運用では使われていない可能性が高い」と当方が判定していたものが、顧客証言で確定したことになります。E4は完全クローズです。B8で判明した「アーカイブに実は存在していた」パターン（KSML1）を踏まえると、この19本についてもsource/配下の再点検で見つかる可能性はありますが、未使用が確定した以上探索する実益は無いため追いません。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（全項目解決済み：内外コード'10'＝中間S/A品番。独立して治具外注等をする場合のみタグ付けし、構成展開上は無視される。外注帳票BAT0201/0206＝外注への注文書。GSBS05/07/08等19本のソース欠落は未使用と確定——D6調査時点の「可能性が高い」という推定が確定に格上げされ、未使用が確定した以上これ以上の探索は行わない。残る未解明点なし）

【解けると】内外コードの意味と欠落GSBSの廃止可否が確定。 (詳細: outsourcing.html)

F1 ★★★ 入金消込・相殺・手形 —— AS/400の外で回る経理業務

【手がかり】(a) 顧客入金を請求書と突き合わせる（入金消込）テーブル・プログラムがAS/400上に見つからない —— 銀行オンラインバンキング＋手作業Excelで完結か。(b) 関連会社間の相殺（ネッティング）機能もAS/400上に無い。(c) 手形は SHDP.SHKGTG（手形金額）が記録され、実データ131件（2.3%）・計142,653,920円（全支払の13.2%）と無視できない規模だが、期日・決済状況（不渡り等）の管理場所が不明。

【ヒアリングで判明】入金の消込は銀行サイトとExcelの併用で行われており、\\Server2\Soumu_C2\経理\売上関係\入金管理表.xlsxと\\Server2\Soumu_C2\経理\経理保存帳票\入出金明細\入出金明細_当期.xlsxの2ファイルで管理されていることが確認された。相殺している取引先も実在し、主なところはデンソープレステック、ヒサダ、トヨトミ、アイシンシロキの4社。受け取った手形の期日についても、別台帳ではなく(a)と同じ入金管理表.xlsxで一元管理されていることが判明し、AS/400上にこれらの機能・テーブルが見当たらなかった理由（＝そもそもAS/400の外で完結する業務だった）が確定した。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-F.md参照)

【質問】（解決済み：入金消込は入金管理表.xlsx等のExcel台帳＋銀行サイトで実施、相殺先はデンソープレステック・ヒサダ・トヨトミ・アイシンシロキの4社、手形期日も同じ入金管理表.xlsxで管理と確認。残る未解明点なし）

【解けると】経理の非AS/400業務の全体像が判明し、移行スコープが確定。 (詳細: finance.html)

F2 ★★ ハードコードされた得意先ルールの背景（記憶頼み）

【手がかり】(a) ITS000R／ITS002R に 60/61・90/91 の得意先ペアリングがハードコードされている（関連会社の一括請求と推測）。(b) ITS001D 画面に「アイシン安城に注意」という警告文言があるが、何に注意すべきかソースに説明が無い（ITS001D.txt L28）。

【ヒアリングで判明】60番と61番の得意先はトヨトミ、90番と91番の得意先は山崎工業であることが確定した。いずれも工場を2つ持つ会社で、納品先そのものは工場ごとに異なるが、請求書は2工場分をまとめて1通にする運用のため、得意先コードがペアで扱われている。「アイシン安城に注意」という警告文言は、取引先やデータそのもののリスクを指すものではなく、新實さん個人の入力操作上の備忘メモに過ぎないことも判明した。範囲指定入力で「10から」スタートさせる癖が新實さんにあり、現在はデフォルトの開始値を8にしているため、単純な入力忘れ防止の覚え書きだったという。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-F.md参照)

【質問】（解決済み：60/61＝トヨトミ、90/91＝山崎工業で、いずれも2工場分の請求書を1通にまとめるためのペアリングと確認。「アイシン安城に注意」は新實さん個人の範囲指定入力時の備忘メモ（取引先・データのリスクとは無関係）と確認。残る未解明点なし）

【解けると】暗黙知をコード化でき、移植版に注意喚起を残せる。 (詳細: finance.html)

F3 ★★ 請求書発行ロジックの不整合・小計方式

【手がかり】(a) 型費の扱いが ITS000R（月次請求）は単価に折り込む、ITS001R（範囲指定）は別項目のまま出力、と異なる。(b) RSBS23（支払総括書）の小計は「レガシー通りの累計小計」を採用したが、種別が今後6つ目以上に増える等で決算方式が変わると再確認が必要（cases①）。

【ヒアリングで判明】型費の扱いは、社内で使う資料では型費・単価を常に別表示にしている一方、客先へ提出する請求書は型費を単価に織り込んで個数割りする得意先が従来は多かった。ただし下請法の影響とみられる近年の傾向として、型費を別立てで請求明細に出すケースの方が増えており、現在は両方式が混在した状態だという。支払総括書（RSBS23）の種別ごとの小計については、前経営者の要望で種別を分けた経緯があるが、現在この帳票はAS/400側の計算結果をチェックするための内部照合リストとしてのみ使われており、種別区分・その小計は特に不要——必要なのは合計のみ、と新實さんは明言した。これはcases.html①（RSBS23小計問題）に直接関わる新事実で、同ページの解決欄に追記した。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-F.md参照)

【質問】（解決済み：型費は社内資料では別表示・客先請求書では単価織り込みが従来多数派だったが下請法の影響で近年は別立てが増加中、両方式が混在。支払総括書の種別小計は前経営者の要望による名残で現在は不要（AS400計算結果のチェック用途のみ、合計のみ必要）と確認。残る未解明点なし）

【解けると】請求書ロジックの意図が確定し、忠実移植の裏取りになる。 (詳細: finance.html / cases.html §1)

F4 ★★ 範囲指定請求書（JUDPR9）は今も使うか＋費用集計マクロ

【手がかり】(a) judpr9（請求書・範囲指定Excel連携、ITS001R／SSBS62 FOR EXCEL）は実データがEXCEPTセンチネルを除き全て2019年3月・得意先20のみに固定＝2019年3月以降使われていない可能性。(b) 月別概算費用集計.xlsm 等のバイナリマクロ（部門別費用・付加価値の算出ロジック）は未解析。

【ヒアリングで判明】ITS001R（範囲指定 FOR EXCEL）の請求書は現在も使用中で、直近では2026年6月分の請求書発行にも使われたことが確認された。これは手がかり(a)の推測を明確に覆す結果——「2019年3月以降使われていない可能性」という結論自体は新實さんの証言により否定された。一方で、judpr9の実データがなぜ2019年3月・得意先20時点のまま固定して見えるのかは、プログラム自体が現役である以上むしろ新たな謎として残る（ステージングテーブル側だけが別の理由で更新停止した可能性があり、要追加調査。masters.htmlにも追記した）。月別概算費用集計.xlsmについては「現在は使用していません」と確認された。以前は概算の試算表を早く出すため、仕入れの納品書内容を入力したExcel・金型材料の発注受入Excel・プレス品材料の発注受入Excelの3ファイルから月別に費用を集計していたとのことだが、現在この集計方法自体は使われておらず、代替手段の有無への言及はなかった。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-F.md参照)

【ヒアリングで判明・続報】当方の推測が根本から誤っていました。F4は完全クローズです。新實さんの追加回答に添付されたAS/400実機でのDSPFD FILE(JUDPR9) LIBRARY(ITLIBD) TYPE(*ALL)のスクリーンショット（source/hearing/attachments/2026-07-29-dspfd-judpr9-p1.png・source/hearing/attachments/2026-07-29-dspfd-judpr9-p3.png）により、実機のJUDPR9は日常的に使われていることが確認できました——最終変更日／時刻 26/07/21 09:49、最終使用日付 26/07/23、使用日数カウント363、現在19レコード。つまりITS001Rが実行のたびにCLRPFM→再書き込みする典型的なステージングファイルの姿そのものでした。ではリポジトリのjudpr9が「2019年3月・得意先20で固定」なのはなぜか——調査の結果、リポジトリのjudpr9はAS/400のダンプ由来ですらありませんでした。顧客から受領した7年分ダンプbin/AS_DATA-20260630T064204Z-3-001.zipは63ファイルですべて実マスタ／明細の物理ファイルで、JUDPR9は含まれていません。本リポジトリでjudpr9に書き込むコードは1箇所だけで、移植版ITS001Rであるpilot/app/src/menus1/invoices.ts:209-244のinvoiceRange()（TRUNCATE judpr9→再構築）です。その中身は、invoiceRange()を実DBに対して走らせたテスト実行の副産物で、回帰specpilot/app/test/e2e/specs/shukka/its001-null-char-crash.e2e.ts:33-41がORDER BY無しのLIMIT 1で拾った得意先/年月の組（得意先20・2019年3月）がそのまま残っていたものです。推測その実行が具体的にどの回だったかまでは特定できていません——記録に残っているのは commit 154dd804（ITS001RのNULL CHAR(2)クラッシュ修正）のライブ検証ですが、同specは決定的（同じ実データに対して常に同じ組を返す）なので、その後の再実行でも全く同じ結果になります。確実に言えるのは「当方のテスト実行が書いたものである」ところまでで、この行の内容から「実DBを最後に触った日」を逆算してはいけません。「2019年3月で止まっている」のは実機の稼働状況ではなく、当方が自分で作ったテスト出力を実機データと取り違えていただけで、謎は存在しませんでした。横展開（重要）: judp*系の約30テーブル（judpp1..9, judpq5, judpr1/5/7/8/9, judps1..9, judpt2, judpdk等）はすべて同じ出自——各テーブルは移植版のバッチ／帳票エンジンがTRUNCATE+INSERTで書くもので、ダンプ由来のデータは1件も入っていません。これらのテーブルの行数・日付から実機の稼働状況を推測してはなりません。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（完全クローズ：ITS001R（範囲指定FOR EXCEL）は現役で2026年6月分にも使用、月別概算費用集計.xlsmは現在未使用と確認済み。judpr9の実データが2019年3月時点で固定されている「謎」は、実機DSPFD確認（使用日数363・最終使用26/07/23）と当方コード調査により謎自体が存在しなかったと判明——リポジトリのjudpr9はAS/400ダンプ由来ではなく、移植版invoiceRange()を実DBに対して走らせたテスト実行が残した副産物にすぎない（どの実行回かまでは特定不能）。同種のjudp*系テーブル（約30本）全てに同じ出自の注意が必要で、それらの行数・日付から実機の稼働状況を推測してはならないという横断的教訓が確定した。残る未解明点なし）

【解けると】範囲指定請求の要否と費用集計マクロの移行価値が確定。 (詳細: masters.html / finance.html)

G1 ★★★ 新システムの権限は「個人」か「共有ログイン」か

【手がかり】旧オフコンの権限は「共有ログイン×端末」の2軸のみで、個人×部署という軸がありませんでした。SEISAN プロファイルは167CL中165個を持つ事実上の「現場汎用アカウント」で、個人ではなく共有ログイン（KENSA 検査・SEIZOU 製造だけが狭いCLリスト＝T試作・W号口の完成入力系のみ）。Windows/Excel層にのみ部署別の個人アクセス表が別立てで存在します。

【ヒアリングで判明】新實さんの回答は、権限モデルそのものの選択ではなく、その前提となる現場の使われ方についての重要な制約でした。まず、社員全員にPCが配付されているわけではなく、1台のPCを複数人で共用するのが実態です。しかもほとんどがデスクトップ機のため、作業場に置かれたPCが共用で使えないと現場が困る、という物理的な制約があります。さらに、現行AS/400の「権限」は、実は個人・部署ごとのアクセス制御という意味合いではなく、入力に関与しない人が誤って処理に入り込んで誤入力しないようにするための制限に過ぎないという位置づけも判明しました。つまりG1の手がかりで「権限」と呼んでいたものは、そもそも今の板倉製作所にとって権限管理というより誤操作防止の仕組みだった、という前提の見直しが必要です。新實さんは続けて、「どこまでの範囲のものを作るかにもよるが、AS400の範囲を超えて、Excelで管理している経理関係・給与関係等も含めるのであれば、こまかな権限設定が必要」であり、この部分は経営判断だと思いますと明言しました。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)

【ヒアリングで判明・続報】KENSA／SEIZOUが現在のどの部署・チームに相当するかが確定しました——「KENSA→品質課、SEIZOU→製作部となりますが、今実際にどのユーザーでサインインしているかは、各部署に確認ください。」つまりAS/400の共有ログインプロファイルと現組織の対応（KENSA＝品質課、SEIZOU＝製作部）は確定しましたが、「その部署が実際にどのプロファイルでサインインしているか」という現場の運用実態は各部署への確認が必要なまま残ります。docs/sites/responsibility.html各所でKENSA＝「検査」、SEIZOU＝「製造」という非公式な訳語を当てていた箇所は、正式部署名（品質課／製作部）に揃えるとよいでしょう。G1本体（新システムを①個人アカウント②共有ログインのどちらでモデル化するか）は新實さんが明言したとおり経営判断であり、rmondo／経営陣の決定待ちで継続オープンです。今回の回答はその判断材料（既存プロファイルの実部署マッピング）を1つ埋めたにとどまります。(出典: 新實さん、2026-07-29ヒアリングシート回答、docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)

【質問】（一部解決：PC共用・デスクトップ中心という運用制約と、現行「権限」が実質は誤入力防止であるという位置づけは判明。KENSA＝品質課、SEIZOU＝製作部という部署対応も確定したが、各部署が実際にどのプロファイルでサインインしているかという運用実態は各部署への確認待ちのまま残る。①個人アカウント単位（Windows台帳方式）と②工程・ライン単位の共有ログイン（AS/400方式）のどちらを新システムの基本モデルにするかは、新實さん自身が「経営判断だと思います」と明言しており、rmondo／経営陣が決めるべき事項として継続オープン）

【解けると】権限モデルの設計方針が定まる（会議冒頭で決めたい最重要事項）。 (詳細: responsibility.html §8)

G2 ★★★ アカウント実名の確定（新實／新南は同一人物か）

【手がかり】Soumu_Admin_List.xlsx の10部署で、kniinomi と kminai の2アカウントだけが全部署の許可リストに例外なく登場。kniinomi は MailingList 最頻出受信者（新實和敏氏と推測）と一致。hitakura／kitakura は共に「板倉」姓＋別頭文字で複数部署に登場（創業家・役員クラスと推測）。2026-07-17の打ち合わせ議事録の「新南さん」は新實さんの表記ゆれ（Gemini自動文字起こしの誤変換）の疑いがあります。

【ヒアリングで判明】4アカウントすべての実名が新實さん本人により確定しました。kniinomi＝新實和敏氏——推測どおり本人でした。2026-07-17の議事録に現れる「新南さん」についても「新南さんは新實だと思います」との回答で、想定していたとおりGemini自動文字起こしの誤変換（新實→新南）であることが裏付けられました。残る3アカウントも判明しました: kminai＝薬袋和樹氏（社長）、hitakura＝板倉広子氏（退職済）、kitakura＝板倉考司氏（営業部係長）。hitakura／kitakuraが創業家・役員クラスという推測も正しく、うちhitakura氏は既に退職済みであることも新たに判明しました。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)

【質問】（解決済み：kniinomi＝新實和敏氏、議事録の「新南さん」も新實氏本人の表記ゆれ、kminai＝薬袋和樹氏（社長）、hitakura＝板倉広子氏（退職済）、kitakura＝板倉考司氏（営業部係長）と確定。残る未解明点なし）

【解けると】権限台帳の実名が確定し、横断承認者枠も定まる。 (詳細: responsibility.html §8)

G3 ★★ 端末（DSP）の実体と設置場所の台帳

【手がかり】auth_ipdsp（IP→DSP対応表）は本番相当DBにデモ用1行のみで実端末が未登録＝未登録IPからは端末制限つき24CLが全滅します。DSP57 は KSBS41 品番構成変更専用、DSP64/65 は自動倉庫入庫／登録専用、DSP52/59 は複数部署横断の統括端末に見えます。物理設置場所（DSP52/55/57/58/59/64/65/73）の台帳が必要です。

【ヒアリングで判明】新實さんが、IPアドレス・コンピュータ名・使用者・部署・DSP名の対応表そのものを提供してくれました。「持っている人はいるか」という質問への答えは、新實さん自身がその台帳を持っていた、という形で解決しています。

「DSP52／DSP59のような統括端末は今も現役か」という問いの前提そのものが、新實さんの回答により訂正されました。新實さん: 「統括端末、横断端末の意味は分かりませんが、特にこの端末が特別という考えはないです。新實が使っているのがDSP59というだけです。DSP52はデンソープレステックのメールを受けるPCなので他の端末よりも機能が多くなっていると思われます。」——つまり「統括端末／横断端末」という枠組み自体が移行チーム側の思い込みで、板倉製作所の運用にはそのような特別な端末区分は存在しません。DSP59が広いCLセットを持つように見えたのは単に新實さん本人の端末であるという属人的な理由に過ぎず、DSP52が他端末より機能が多いのもデンソープレステックからのメールを受信する専用PCだからという業務上の理由であって、いずれも「複数部署を横断する統括端末」という設計意図の証拠ではありませんでした。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)

【質問】（解決済み：IP↔DSP対応表を新實さんより取得。「統括端末／横断端末」という概念そのものが板倉製作所の運用には存在せず、DSP59は新實さん個人の端末、DSP52はデンソープレステックのメール受信専用という業務上の理由で機能が多いだけと確認。残る未解明点なし）

【解けると】端末別権限を機能させる台帳が整い、端末設計方針が定まる。 (詳細: responsibility.html §8 / system-map.html §9)

G4 ★★ 外製管理は現役業務か＋ソース欠落CLの生死

【手がかり】(a) G外製管理（MENUG1、25プログラム）はpilotアプリに実装が一切無く、squp 側でも3CL（GSBS03/04/06）が SEISAN に許可されるのみで利用実績の手がかりが薄い。(b) squp/sqdp の167CL中13個（DSBS16／JSBS21／KSBS02／KSBS28／KSBS29／MSBS04／MSBS21／RSBS03／RSBS04／RSBS05／WSBS25／WSBS26／WSBS31）はソース未回収で内容不明のまま許可リストに載る（経理系 RSBS03/04/05 を3つ含む）。

【ヒアリングで判明】外製管理（外注発注）の現在の利用範囲が確定しました。新實さん: 「外注管理は発注入力以外は現在使用していません。発注入力は注文書を発行するために使用しています（下請法の必要項目を入れたものを印刷するため）。ただし、注文書は必要な仕入れ先すべてに注文書を発行しているかは定かではありません（注文書を発行しないまま注文している可能性あり）。」——つまりMENUG1配下の外製管理業務全体のうち、実際に現役で使われているのは発注入力（下請法対応の注文書発行のため）だけで、それ以外の機能は既に使われていません。加えて購買業務全体の実際の流れも判明しました: 「購買のデータは、仕入先から請求書が届いたところからスタートです。Excelで管理しています。ExcelのデータをAS400に転送して、振込手数料の計算をして、Excelに戻す、という手順です（AS400の振込手数料の計算部分がすでにあったのでそれを使用しているだけです）。」——つまり購買管理の本体は既にExcelへ移行済みで、AS/400側に残っているのは振込手数料計算という一部の計算機能のみを間借りして使っている状態です。列挙した13画面のうち、どれが個別に今も使われているかまでは新實さんの回答で名指しされておらず、外製管理全体を「発注入力以外は不使用」という粒度で確認できた段階に留まります。 (出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)

【質問】（解決済み：外製管理の現役業務は発注入力（下請法対応の注文書発行）とAS/400側の振込手数料計算の2点のみに確定、それ以外は既に購買のExcel管理へ移行済みと確認。残る未解明点は、列挙した13画面（DSBS16等）個々の使用状況の逐一確認のみで、上記の全体構造が判明した以上、実務上の重要性は低い）

【解けると】外製管理の移行要否と、死んだCLの棚卸が確定。 (詳細: responsibility.html §8)

G5 ★ テストデータの汚染確認（bjdpq3）— 当方の誤りにより取り下げ

【手がかり】bjdpq3（引継ぎ専用ワークキュー）は17行中16行が無条件センチネル 'EXCEPT'、残り1行が「CATEST-SUCC」「CATEST-NOSTOCK」という明らかなテスト文字列で、実運用の引継ぎイベントが1件も残っていません。

【訂正 — この質問自体が誤りでした】17行のうち1行だけをテスト残骸として扱っていましたが、17行すべてが当方のpilotテスト実行の出力であり、AS/400由来の行は1行も含まれていませんでした。したがって「この2行を消してよいか」を新實さんに確認する必要はそもそもありません（消しても実機には何の影響もなく、消す判断は当方の側の話です）。根拠:

• AS/400ダンプ（bin/AS_DATA、63ファイル）にBJDPQ3が存在しない——BJDPQ2・BJDPQ4も同様。移行元データが最初から無い。
• 17行すべてが端末名Q3NMDP='TESTJ'・日付20260630・時刻150700で完全一致。pilot/app/test/menuj1/carryoverAlloc.test.ts:35のconst DSP = "TESTJOB "がchar(5)に切り詰められた結果。
• 書き込み元はpilot/app/src/menuj1/carryoverAlloc.ts:73,392のINSERT INTO bjdpq3。CATEST-*は同テストのフィクスチャ文字列。

これはF4（judpr9）と同じ誤りの再発です——自分たちのテスト実行が書いた行を、AS/400実機の状態を示す証拠として読んでしまいました。bjdpq2／bjdpq3／bjdpq4の内容から実機の運用実態を推論しないこと。

【ヒアリングで判明（この部分は有効）】新實さんからbjdpq3そのものの用途とライフサイクルが判明しました: 「bjdpq3は組付部品の引継ぎ＆引当処理をするときに使用する中継ファイルで、処理回数のカウンタの役目もあります。データの中身自体は処理完了後も保持する必要はないが、ファイル自体は必要。」（用途の補足: 組付品が設変になり一部の部品が新しい部品になるものの多くの部品はそのまま使う場合、設変前の注文に引き当たっているそのまま使う部品を、設変後の注文の引当にそのままスライドして引当てるための処理に使用する。）——bjdpq3が永続保存用のマスタではなく一時的な作業キューであることは確定しており、この知見は移行設計にそのまま使えます。無効になったのは「現在の17行の中身」についての当方の解釈だけです。 (出典: 用途は新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照 / 訂正はダンプ内容・テストコード・実データの突合による)

【質問】（取り下げ——顧客への確認は不要。当方の誤りとして記録のみ残す）

【解けると】本番データのテスト汚染を安全に掃除できる。 (詳細: masters.html)