13. 隠れメニュー・システム地図

このページは「見えているメニューの外側」を地図にする — 隠れた入口・死んだ領域・どのプログラムがどのテーブルを書くか。新人が「知らない画面」に出会っても位置づけられるように。

1. 結論ファースト

2. 3つの「隠れ方」

今回の調査で「未到達」と分類されたメニューは、実際には3種類の全く異なる理由で見えなくなっていた。この分類が今回の調査の核心。

3. 未到達メニュー31本の全棚卸し表

各メニューの分類は根拠付きで確定させた。使用停止はPROBABLY-DEAD、特殊はVARIANT/ALIVE-HIDDEN等の注意が必要な扱いを示す。

3.1 F8「次頁」チェーンの全体像（10+3+1=14件のALIVE系統）

実際のソースを辿ると、以下の3本の独立したチェーンで繋がっている（矢印はF8＝次頁、[F9]はF9＝QUERY/照会の意味）。

いずれも該当メニューのCLソース内、CHGVAR VAR(&MSG2) VALUE(' F3=終了 F8=次頁 ...')という行で画面上に明示されている普通のページ送り機能であり、AS/400の利用者（新實さん・古橋さんら）にとっては当たり前に見えていた画面のはずである。今回「未到達」と判定されていたのは、あくまでanalysis/out/menu_tree.mdを生成したクローラーが数値オプション（&WNUM01〜26との比較）しか辿らず、ファンクションキー分岐（&IN08/&IN09との比較）を辿っていなかったためのツール側の限界であり、AS/400の実運用上は最初から「隠れて」いなかったと考えられる。

IF ( &INPS = 50 ) DO
   CALL PGM(MENUWZ)
   MONMSG MSGID(CPF0000 CPD0000) EXEC(DO)
        CHGVAR VAR(&WGID) VALUE('経理管理サブシステムメニュー')
        GOTO @ER010
     ENDDO
   GOTO @IT010
ENDDO

4. MENUZ9 — 端末ID分岐の詳細

IF COND(&NOWS *GE DSP65 *AND &NOWS *LE DSP6599999) THEN(GOTO CMDLBL(@MENUZ9))
CALL PGM(MENU00)
GOTO @FIN
@MENUZ9:  /*自動倉庫端末専用*/
  CALL PGM(MENUZ9)

ワークステーションID（端末名）がDSP65〜DSP6599999の範囲だった場合、MENU00の画面すら一度も表示せず、直接MENUZ9に飛ぶ。これはMENUR1（MENU00の中の打鍵専用分岐）とは全く異なる隠れ方で、「特定の物理端末からログオンした場合だけ見える別の起動メニュー」という、メニューツリーの外側にある入口。おそらく自動倉庫（立体倉庫）の現場に設置された専用端末（DSP65番台）向けに、サインオン時点で業務を絞り込む設計 推測。

中身自体（ZSBS05-08＝材質・使用品番・使用材料・受注残の各種照会）は、幸いMENUZ1配下で既に移植済み（material-usage-by-material.html, material-type-list.html等）。自動倉庫の入出庫トランザクション本体（ZSBS21-23、MENUZ1側にのみ存在）はMENUZ9のメニューには含まれておらず、別経路（PLC/クレーン制御と連動？）の可能性がある 推測。

4.1 その他の注意点

MENUD1（デンソー機工EDI）— 生きているが実データは空。呼び出し経路自体はJSBS30経由で完全に確認でき、public/menud1.htmlも既に構築済み。ただし本番DB（itakura-pilot-db、read-only接続で確認）でjudpdk（EDI受信ステージングテーブル）の行数を見ると0件だった。これはステージングテーブルの性質上（取り込み後にクリアされる運用の可能性）不使用の証拠にはならないが、念のため9章で確認事項に入れている。

MENUQ1（QUERY、全9枠ラベル空欄）。MENUM1のF9（QUERY）から到達できる点は他と同じだが、9オプション全てがWGID空欄（一度もラベルが設定されていない）。到達経路としては生きているが、中身が最初から空だった可能性が高い（Query/400のスロットだけ用意して、結局誰も定義を割り当てなかった） 推測。実害・実務的重要性は低いと判断。

5. MENUM00死亡クラスタ — ソース自体が存在しない36本

MENUM00の中身は3オプションのみ。

MENUMD1/MU1/MW1が挙げるマスタ一覧（部品品番・カレンダー・DNPTカレンダー・製造指示・組付部品状況・組付まとめ指示・設計Y・受注品番）は、現行の到達可能なMENUM1（MENU00 opt5経由）が挙げるマスタ一覧と完全に同一。つまりこれは「削除／変更／追加をそれぞれ別メニューに分けていた旧設計」であり、現行のMENUM1（1画面でCRUDをまとめて扱うMSBSnn系プログラム）に統合された結果、丸ごと使われなくなったと考えるのが自然 推測（ただし状況証拠は強い）。

根拠を積み上げると次の通り（呼び出し元が皆無であるという事実自体はヒアリング後も変わらない）。

1. MENUM00自体、AS/400ソース全体（CLもRPGも）を通じて呼び出し元が1件も無い。
2. MENUM00の子（MNM001/005/009）も、MENUM00以外から呼ばれていない。
3. その先のMENUMD1/MU1/MW1も、対応するMNM00xからしか呼ばれていない。
4. さらにその先のMD2/3、MU2/3、MW2/3（F8連結）、MQ1/2/3（F9連結）も、この閉じたツリーの中だけで完結している。
5. 決定打：各メニューが指す末端プログラム（MNMD01〜09、MNMU01〜09、MNMW01〜09、MNMQ01〜09、計36本）は、analysis/out/members.csv（AS/400ソース全1477メンバーの一覧）に1件も存在しない。つまりメニュー階層は残っているが、実際に処理を行うプログラム本体はとうの昔に削除／未実装のまま。

一方でMENUM00直下の3本の中継プログラム（MNM001/005/009）自体はソースが存在する（source/as400-admin/transport-tooling/ITLIBS/MNM001.txt等、各64行、単純にITSQ01R権限チェック→CALL PGM(*LIBL/MENUMUx)するだけの薄いラッパー）。つまり「メニューの骨組み」と「中継の薄いラッパー」だけが残り、「実際にマスタを削除／変更／追加する本体プログラム」だけがきれいに失われている——最後の統合作業で本体プログラムをMSBSnn側に移植し、旧側は消し忘れた、という経緯が透けて見える 推測。ただし上のヒアリング結果の通り、これは「本体を移植して旧側を消し忘れた」のではなく、「本体（MNMD0x/MNMU0x/MNMW0x等）を最初から作らずMENUM1側の実装だけで済ませた」と読む方が新實さんの証言と整合する。骨組みと薄いラッパーだけが先に用意され、本体の実装がMENUM1側の完成をもって不要になった（あるいは最初から本体着手前にMENUM1へ一本化する方針に切り替わった）、というのが現時点で最も無理のない理解。

6. 死にプログラムの風景（新規参入者向けサマリ）

analysis/out/REPORT.mdの静的解析（到達点172＝MENU*全部・BAT*全部・DTF参照ファイル全部から出発したグラフ探索）によると次の通り。

352件のうち244件（69%）はreferenced_anywhereが空欄＝同ソース内のどこからも参照されない完全孤立、残り108件は他の死んでいるプログラム同士が互いに呼び合っている（＝孤立した死のクラスタ全体）。

7. サブシステム×主要書込テーブル マップ

analysis/out/edges.csvのcall/menu辺で各サブシステム根（MENUJ1等11本）からグラフ探索し、到達した全プログラムのwrites-file辺を集計。表定義ファイル（末尾D、画面record format書き込み）とQPRINT（汎用スプール出力）を除いた、実データテーブルへの書き込み上位を示す。このテーブルはそのまま「どのサブシステムがどのデータを持っているか」の参照表としても使える。

全体として、JUDP（受注データ）とBJDP/SJDP（号口・出荷データ）が複数サブシステムを横断する中核テーブル、JHMP/BHMP（受注品番・部品品番マスタ）がマスタ側の中核であることが定量的に裏付けられた。3章のMENUM2クラスタが指すTYMP/NMMP/MDMPは、MENUZ1のMDMP(4件書込)を除けば書込頻度は低く（照会・保守中心のマスタ）、実データ行数（tymp:121, nmmp:188, mdmp:9,527）と合わせても運用中の実マスタと判断できる。

この読み取り専用クエリはdocker exec -e PGOPTIONS='-c default_transaction_read_only=on'で本番トランザクションに一切影響を与えない形で実行した（更新系コマンドは発行していない）。

8. 調査方法（詳細）

# メニュー間のCALL PGM辺を洗い出す（*LIBL/修飾を含める）
grep -anlE "PGM\(\*?(LIBL/)?MENUXXX\)" source/as400-admin/transport-tooling/ITLIBS/*.txt

# ファンクションキー分岐（F8=次頁 等）
grep -an "IF ( &IN0[0-9] = '1' ) THEN(CALL PGM" source/as400-admin/transport-tooling/ITLIBS/*.txt

# 打鍵専用の隠し分岐（D23と同じパターン）
grep -anE "IF \( ?&INPS ?= ?[0-9]" source/as400-admin/transport-tooling/ITLIBS/*.txt

# Shift-JIS + 不正バイト混在ファイルの安全な変換
iconv -f SHIFT-JIS -t UTF-8//IGNORE MENUJ1.txt

# 本番DB読み取り専用チェック（例）
docker exec -e PGOPTIONS='-c default_transaction_read_only=on' \
  itakura-pilot-db psql -U pilot -d itakura -c "SELECT count(*) FROM tymp;"

9. 確認したいこと

以下は「事実として確認したこと」と「まだ確証が取れず新實さん／古橋さんの記憶に頼りたいこと」を分けて列挙する。推測マークの無い項目はソース・データからの事実、マーク付きは状況証拠からの推測。この節は 14. ヒアリングシート にそのまま引き継がれる。