11. 権限と部署責任マップ
2026-07-17の打ち合わせで「システムと業務責任を各部署へ分割する」という方針が決まった。本ページはその出発点として、現行システムが実際に誰に何を許しているかを実データで示す。
このページの内容
1. 権限のしくみ — squp / sqdp 二層モデル
2. 実権限マトリクス — 4プロファイル × 11＋1サブシステム
3. 共有プロファイル時代 vs 個人認証時代の衝突
4. 端末制限の現状 — IP↔DSP対応表がまだ無い
5. G外製管理の実装ギャップ
6. 人・部署の対応（Excel台帳より）
7. 部署責任分担のたたき台
8. 確認したいこと
1. 権限のしくみ — squp / sqdp 二層モデル
2. 実権限マトリクス — 4プロファイル × 11＋1サブシステム
3. 共有プロファイル時代 vs 個人認証時代の衝突
4. 端末制限の現状 — IP↔DSP対応表がまだ無い
5. G外製管理の実装ギャップ
6. 人・部署の対応（Excel台帳より）
7. 部署責任分担のたたき台
8. 確認したいこと
このページの要点
- AS/400の権限は個人でなく「CL×端末/ログイン名」のホワイトリストで、全行が許可(P)フラグのみ。
- ログイン名は実質SEISAN等の共有プロファイル4種のみで、個人単位の権限化はこれからの課題。
- G外製管理(MENUG1)はpilotアプリに実装が一切なく、購買/外製の担当部署対応も未確定。
このページの性質について
5章（部署責任分担のたたき台）の内容はすべて証拠からの推測であり、正式な分担案ではない。関係者への確認が必須で、その論点は8章に整理した。8章の項目は 14. ヒアリングシート にそのまま引き継がれる。
1. 権限のしくみ — squp / sqdp 二層モデル
1.1 平易な説明
オフコン（AS/400）側の権限は、Windowsのような「ユーザーごとの役割」ではなく、「このCL（コマンド）は、この端末／このログイン名からしか実行できない」というプログラム単位のホワイトリストだった。今回確認した限り、Itakuraの実データは全行が「許可（P）」フラグで、「拒否（R/deny）」の行は1件も存在しない（squp 182行、sqdp 65行、すべてqukusq='P'/qdkusq='P'）。つまり実質的には次の運用だった。
- CLがリストに一件も無い → 誰でも実行できる（デフォルト全開放）
- CLがリストに載っている → リストに載った端末／ログイン名だけが実行できる
「例外的に絞り込みたいプログラムだけを列挙する」運用で、167個のCLだけが何らかの形で絞られており、それ以外（数百のCL）は無制限。
1.2 二本の脚（DSP脚・USER脚）— 両方を満たす必要がある
| 脚 | テーブル | キー | 判定 |
|---|---|---|---|
| 端末側 | SQDP | qdnmcl=CL名 × qdnmdp=物理端末名（例 DSP52、先頭5文字だけ比較） | 端末名がリストに載っているか |
| ログイン側 | SQUP | qunmcl=CL名 × qunmus=ログイン名（例 SEISAN、全文字比較） | ログイン名がリストに載っているか |
両方の脚を判定し、両方が「合格」でないと実行不可。無条件バイパスとしてログイン名の先頭7文字がITAKURAなら、リストの内容に関わらず常に合格する（ロックアウト時の脱出口を兼ねる、ソース内コメントより）。判定結果は3種：合格／D＝「このＰＣからは実行できません。」／U＝「現在のユーザーでは実行できません。」 (出典: pilot/spec/auth/convention.md §2; docs/decisions.md D10)
1.3 現行pilotアプリでの継承状況
旧オフコンの許可リストは、今のWebアプリでも生きたまま強制されている
pilot/app/src/auth/itsq01r.ts が上記ロジックをそのまま移植し、requireClPass()（pilot/app/src/auth/clgate.ts）経由で各サブシステムのルートに配線されている。実際に grep したところ、J受注・W号口・T試作・S出荷・K技術情報・Z材料金型・A組付・B工機・R経理・マスタ保守（M）は全てCLゲートを実装済み（例: menuj1/routes.ts 102箇所、menuw/routes.ts 52箇所、menur1/routes.ts 4箇所）。当初「マスタだけ」という想定を持って調査を始めたが、実際はもっと広く配線済みだった。例外はG外製管理（MENUG1）で、5章で扱う。
1.4 端末＝IPマッピングの実運用状況（重要な穴）
新しいアプリでは「どの端末（DSP名）からのアクセスか」をauth_ipdspテーブル（IP→DSP名）で判定する（pilot/spec/auth/convention.md §5-6）。詳細は4章で扱う。
2. 実権限マトリクス — 4プロファイル × 11＋1サブシステム
2.1 ログイン名の正体（重要な前提）
squpに登場するログイン名は4種類のみ：ITAKURA(2件)・KENSA(10件)・SEISAN(生産, 165件)・SEIZOU(5件)。これは個人名ではなく、部署／工程を表す共有ログインプロファイル（AS/400の伝統的な「端末＝部署共有ログイン」運用）。KENSA→品質課、SEIZOU→製作部という部署対応はhearing.html G1のヒアリングで確定した（ただし各部署が実際にこのプロファイルでサインインしているかは未確認）。一方、pilotアプリのauth_usersは13件（ITAKURA/DSP01/ITAKURAQA/TEST01~TEST10）で、うち10件はテスト用ダミーアカウント。実質「本物」は3件のみで、これも個人名ではなく汎用アカウント。squp 4種 vs auth_users 13件という差は不整合ではなく、「オフコンの共有プロファイル方式」と「新アプリの個別ログイン方式」の過渡期の姿。個人単位の権限化は、まさに今回の部署責任分担の議題そのもの（3章で詳述）。 (出典: DB squp/auth_users 実データ)
2.2 サブシステム対応表（CLプレフィクス→サブシステム、pilot実装有無）
| Prefix | サブシステム | root | pilot実装 | 備考 |
|---|---|---|---|---|
| A | 組付管理 | MENUA1 | ✅ menua1/ | |
| B | 工機管理 | MENUB1 | ✅ menub1/ | |
| D | （ＤＮＰＴ号口処理＝Aisin/Denso EDI連携） | MENUD1 | ⚠一部stub | MENU00の隠しオプションで、visible menuに出ない。MENUJ1のW7グループとしてdefer-loud stub扱い (出典: docs/decisions.md D11 W7) |
| G | 外製管理 | MENUG1 | ❌ 未実装 | pilot/app/src/menug1/ 自体が存在しない（5章参照） |
| J | 受注管理 | MENUJ1 | ✅ menuj1/ | 最大サブシステム（203プログラム） |
| K | 技術情報管理 | MENUK1 | ✅ menuk1/ | |
| M | マスター保守管理 | MENUM1 | ✅ masters/ | ＣＬ実行許可設定USER/DSP自体もここ（MSBS38/39） |
| R | 経理管理 | MENUR1 | ✅ menur1/ | セッション34で発見・移行（easy-feedback #17） |
| S | 出荷管理 | MENUS1 | ✅ menus1/ | |
| SYS | （AS/400 OS操作） | ≒MENUX1 | ✅ menux1/ | コマンド入力／ジョブ管理など汎用OS機能 |
| T | 試作管理 | MENUT1 | ✅ menut1/ | |
| W | 号口管理 | MENUW1 | ✅ menuw/ | |
| Z | 材料・金型管理 | MENUZ1 | ✅ menuz1/ |
2.3 ログイン名×サブシステム 許可CL件数
| ログイン名 | A組付 | B工機 | D(EDI) | G外製 | J受注 | K技術 | M保守 | R経理 | S出荷 | SYS/X | T試作 | W号口 | Z材料金型 | 合計 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ITAKURA | – | – | – | – | – | – | 2 | – | – | – | – | – | – | 2 |
| KENSA（品質課） | – | – | – | – | – | – | – | – | – | – | 2 | 8 | – | 10 |
| SEISAN（生産） | 4 | 4 | 6 | 3 | 26 | 13 | 25* | 16 | 7 | 19 | 17 | 16 | 4 | 165 |
| SEIZOU（製作部） | – | – | – | – | – | – | – | – | – | – | 2 | 3 | – | 5 |
| CL総数（167個中） | 4 | 4 | 6 | 3 | 26 | 13 | 27 | 16 | 7 | 19 | 17 | 16 | 4 | 167 |
* M保守27個中SEISANが持つのは25個（＝MSBS38/39を除く全て。次項参照）。
SEISAN（生産）は事実上のスーパーユーザー — 167個中165個を保有
SEISANは監査用の2CLを除く全CLを保有する。欠けているのはMSBS38（ＣＬ実行許可設定USER）・MSBS39（同DSP）の2つだけ（＝ITAKURAだけが持つ2CLと完全に相補的）。SEISANは事実上「権限管理画面以外は全部触れる」汎用生産端末プロファイルであり、部署別の絞り込みには使われていない。4プロファイルのうち、業務内容から見て「部署の形」をしているのはKENSA（品質課）・SEIZOU（製作部）だけ——SEISANは全開放に近く、ITAKURAは管理者バイパス専用。
2.4 注目すべき例外
- ITAKURAは権限管理CLの2つだけを明示的にリスト化（無条件バイパスがあるので実務上は冗長だが、「多重の砦」として意図的に残されている可能性が高い）。
- KENSA（品質課）とSEIZOU（製作部）は明確に狭い。KENSAはT試作・W号口の「完成入力・出来高修正」系10CLのみ（例: WSBS11 作業指示完成入力, WSBS41 出来高入力）。SEIZOUも同系統5CLで、WSBS41/WSBS45（出来高入力・訂正）はKENSAとSEIZOU両方の許可リストに載っている（＝どちらのログインでも実行可、共同作業エリアの可能性）。この2プロファイルは業務内容から見て最も「部署別権限」らしい実例。
- DSP+USER両方でロックされているCLが16個ある（最重要データ操作群）: DSBS04/05/06/17/18（DNK変更・オリジナルデータ取込/変換）、JSBS30/35/36/37（試作強制中止・完成分納前処理など）、KSBS41/51/52（品番構成変更・EXCEL構成表取込/変換）、SSBS77/78（請求済締日入力/一括処理）、ZSBS21/23（自動倉庫入出庫）。これらは「端末の場所」と「ログイン名」の両方が合っていないと実行できず、最もセンシティブな操作として扱われていたと読める。
- 167件のうち13件は
analysis/out/members.csvにソースが見つからない（⚠missing-source）: DSBS16, JSBS21, KSBS02, KSBS28, KSBS29, MSBS04, MSBS21, RSBS03, RSBS04, RSBS05, WSBS25, WSBS26, WSBS31。ダンプ対象外だった旧メニュー枠で、実害は薄いと見るが、RSBS03/04/05（経理）はMENUR1移行時（D23）に精査した18プログラムの対象外だったため念のため触れておく。
3. 共有プロファイル時代 vs 個人認証時代の衝突
個人単位の権限管理は一度も存在しない
squpの4アイデンティティ（ITAKURA/KENSA/SEISAN/SEIZOU）は個人ではなく、役割共有のAS/400プロファイルである。一方pilotアプリのauth_users13件はほとんどがTEST01~TEST10というテスト用の足場（scaffolding）で、本物のアカウントは3件のみ、それも個人名ではない。つまりITAKURA製作所のシステムは、AS/400稼働の全期間を通じて「個人単位」で権限を管理したことが一度も無い。これは今後決めるべき論点そのもので、8章の質問1・9にそのまま繋がる。
squp/sqdpのように「AS/400の実行権限を部署別に管理していた」形跡は見つからなかった（＝オフコン権限は共有プロファイル4種のみで運用され、個人・部署別の権限管理はWindows/Excel層に別立てで存在していた、という二重構造。詳細は6章）。
4. 端末制限の現状 — IP↔DSP対応表がまだ無い
sqdpは65行、8台の物理端末名のみ登場する。端末の物理設置場所を示す文書はソース内に見つからなかった（8章の質問4）。
| 端末 | CL件数 | 内訳（プレフィクス） | 代表的なCL | 推測される用途 |
|---|---|---|---|---|
| DSP52 | 14 | D6, J5, K2, S1 | DSBS04-19系, JSBS30/35-37/53 | 受注＋DNK連携の総合端末 |
| DSP55 | 10 | J5, K5 | JSBS19/35-37/53, KSBS02/41/51/52 | 受注・技術情報の混在端末 |
| DSP57 | 1 | K1 | KSBS41 品番構成変更（構成展開反映) | 単機能端末（BOM変更専用） |
| DSP58 | 10 | J5, K5 | DSP55と同一パターン | 受注・技術情報 |
| DSP59 | 15 | D3, J3, K2, S4, SYS1, Z2 | 上記に加えSSBS44/45, ZSBS21/23 | 最も広範、フロア統括端末の可能性 |
| DSP64 | 2 | Z2 | ZSBS21 自動倉庫入庫処理, ZSBS23 自動倉庫登録処理 | 自動倉庫端末（金型・材料） |
| DSP65 | 2 | Z2 | DSP64と完全同一 | 自動倉庫端末（DSP64の対と思われる） |
| DSP73 | 11 | J5, K5, S1 | DSP55/58と同系統＋SSBS44 | 受注・技術情報 |
DSP64とDSP65は許可CLが1文字違わず完全一致 — 同じ業務エリア（自動倉庫まわり）に2台設置されている可能性が高い。DSP57は唯一の単機能端末で、技術/設計部門のBOM変更専用ワークステーションと読める。DSP52/55/58/59/73の5台は「受注（J）＋技術情報（K）」の組み合わせが共通しており、営業事務所か技術・受注の共同エリアに集中配置されていたと推測する。
auth_ipdspはデモ用1行のみ — 実運用の端末マッピングが未整備
新しいアプリでは「どの端末（DSP名）からのアクセスか」をauth_ipdspテーブル（IP→DSP名）で判定する（pilot/spec/auth/convention.md §5-6）。本番相当DBを確認したところ、auth_ipdspには127.0.0.1 → DSP01というデモ用の1行しか存在しない。実運用のPC/端末IPは1つもマッピングされていない。D10の設計どおり「未マッピングIP→DSP空欄」になり、sqdp側は全行がP（許可リスト）なので、空欄DSPはsqdpが絡む24個のCLすべてで不合格になる（fail-closed）。つまり今このまま本番投入すると、端末制限つきの24 CL（本章冒頭の表）は現場の誰からも実行できない状態になる。部署ごとの端末運用を決める前に、IP↔DSP対応表の整備がロールアウトの前提になる。
5. G外製管理の実装ギャップ
G外製管理（MENUG1）はpilotアプリに実装が一切無い
pilot/app/src/menug1/ディレクトリ自体が存在しない。squp側では3CLのみ（GSBS03/04/06）がSEISANに許可されているのみで、利用実績の手がかりが薄い。外製管理（外注発注）は今後移行が必要な現役業務か、それとも既に購買管理（Excel/紙）に業務が移っていて不要か、8章の質問7として確認が必要。
6. 人・部署の対応（Excel台帳より）
6.1 情報源の位置づけ（重要な注意）
3種類のExcel台帳は、squp/sqdp（AS/400のCL実行権限）とは別レイヤーの権限台帳。
| 台帳 | 内容 |
|---|---|
Soumu_Admin_List.xlsx | 部署別のWindows/Excelマクロ・アクセス許可者一覧（個人ID） |
MailingList.xlsx | 自動送信レポートの宛先（フルネーム） |
User_Data.xls | Excelブック→Windowsログオン名の対応（部署情報なし、権限台帳ではない） |
squp/sqdpのように「AS/400の実行権限を部署別に管理していた」形跡は見つからなかった（＝オフコン権限は共有プロファイル4種のみで運用され、個人・部署別の権限管理はWindows/Excel層に別立てで存在していた、という二重構造）。
6.2 部署別アクセス者一覧（Soumu_Admin_List.xlsx、原文ID＋推測氏名）
推測氏名は「ID＝名の頭文字＋姓ローマ字」パターンでMailingList.xlsxの実名と照合したもの（例: duchida=d+uchida→内田(大助)、kishikawa=k(eiko)+ishikawa→石川慶子）。複数の一致（4件以上）が同じ規則に従うため中〜高確信だが未確認、要本人確認。 ただしkniinomi・kminai・hitakura・kitakuraの4アカウントは2026-07-22の新實さんへのヒアリング（hearing.html G2）で直接確定済み — 表内の「（確定）」表記はこの4件のみを指し、他は依然推測のまま。
| 部署 | アクセス許可ID（原文） | 推測氏名（推測） |
|---|---|---|
| 総務課 | kniinomi, kminai, KURARA | 新實和敏（確定）, 薬袋和樹・社長（確定）, (共有アカウント) |
| 営業課一般 | kniinomi, kminai, hitakura, duchida, kitakura, kishikawa, kkishikawa, ynaitou, tyoshida, rooguchi | 新實和敏（確定）, 薬袋和樹・社長（確定）, 板倉広子・退職済（確定）, 内田大助, 板倉考司・営業部係長（確定）, 石川慶子, 不明, 内藤恭英?, 吉田?, 不明 |
| 営業課営業係 | kniinomi, kminai, hitakura, duchida, kitakura, kishikawa, kkishikawa, rooguchi | （同上サブセット） |
| 購買管理者 | kniinomi, administrator, kminai | 新實和敏（確定）, (システム), 薬袋和樹・社長（確定） |
| 金型管理担当 | kniinomi, administrator, kminai, hitakura, duchida, kitakura, kishikawa, kkishikawa, ynaitou, tyoshida, rooguchi, souko | ＋souko=倉庫共有アカウント(推測) |
| 見積担当者 | kniinomi, administrator, kminai, hitakura, duchida, kitakura, kishikawa, kkishikawa, tyoshida, rooguchi | |
| PC管理者 | kniinomi, administrator, kminai | |
| 経理担当者 | kniinomi, administrator, kminai, hitakura, duchida, kitakura, kishikawa, kkishikawa, KURARA | |
| 経理管理者 | kniinomi, kminai, hitakura, tyoshida, KURARA | |
| 係長以上 | kniinomi, administrator, kminai, hitakura, duchida, kitakura, ttieda, tieda, hmishima, kinomata, kkobayashi | ＋家田友裕?, 三島博之?, 猪股康司?, 小林幸二? |
kniinomi・kminaiの2アカウントだけが10部署すべての許可リストに登場する
これは「業務のあらゆる領域を横断的に把握しているのは実質2人だけ」という事実を、squp/sqdpとは異なる証拠（Windows権限台帳）から裏づける結果になった。2026-07-17の打ち合わせで課題として挙がった属人化の、定量的な裏付けとして紹介するものであり、特定個人の業務評価を意図するものではない。本ページの目的（システムと業務責任を各部署へ分割する）に照らし、まさにこの一点への対処が出発点になる。
6.3 氏名の突合表（MailingList.xlsxより、高確度の一致のみ）
| 推測ID | フルネーム（MailingList原文） | 一致根拠 |
|---|---|---|
| kniinomi | 新實和敏 | MailingListで最頻出の受信者（Bcc常連）。全部署共通ID |
| duchida | 内田大助 | d+uchida、複数メールで一致 |
| kishikawa | 石川慶子 | k(eiko)+ishikawa |
| ynaitou | 内藤恭英 | y+naitou |
| hmishima | 三島博之 | h(iroyuki)+mishima |
| kinomata | 猪股康司 | k(ouji)+inomata |
| kkobayashi | 小林幸二 | k(ouji)+kobayashi |
| tieda/ttieda | 家田友裕 | t(omohiro)+ieda（2表記あり、要確認） |
hitakura / kitakura（2つの異なる板倉さん）はMailingListの直接一致候補が見当たらなかった。板倉家（創業家）の複数名がそれぞれ別IDを持っている可能性が高いが未確認（8章の質問6へ）。 【ヒアリングで判明】MailingList照合では一致しなかったが、2026-07-22の新實さんへのヒアリングで直接確定した: hitakura＝板倉広子氏（創業家、退職済）、kitakura＝板倉考司氏（営業部係長）。板倉家（創業家）という推測は当たっていたが、hitakura氏は既に退職済みのため、部署分担の「横断承認者」枠を検討する際はkitakura（板倉考司氏）のみを現役の候補として扱うべき。詳細はhearing.html G2 / 8章質問6を参照。
7. 部署責任分担のたたき台
これは会議のたたき台であり、正式な分担案ではない
以下は6章の部署別アクセス実績と、2章のサブシステム構造を突き合わせた議論の出発点。全項目 推測。会議での確認が前提。
| 部署（Soumu_Admin_List） | 対応しそうなサブシステム | 根拠（推測） |
|---|---|---|
| 営業課一般・営業課営業係 | J 受注管理 | 部署名「営業＝受注」が直接対応。squpのJ受注CL数(26)も最大級 |
| 見積担当者 | J受注管理の一部（見積） | source/estimate/フォルダの存在。J受注のサブ機能として要確認（独立サブシステムではない） |
| 購買管理者 | G 外製管理（未実装） | 「購買」と「外製＝外注発注」は近接概念だが同一ではない。要確認 |
| 金型管理担当 | Z 材料・金型管理 | 部署名が直接対応。DSP64/65（自動倉庫端末）もこの系統 |
| 経理担当者・経理管理者 | R 経理管理 | 部署名が直接対応。R自体、easy-feedback#17（新實氏）が発見した経緯があり、経理部門の実利用が濃厚 |
| 総務課 | 横断的（M保守／人事関連、X system管理の一部） | 「総務＝庶務全般」で単一サブシステムに対応しない。ITAKURA権限（M保守のMSBS38/39）の管理主体候補 |
| PC管理者 | X システム管理保守 ＋ 認証管理（auth_users/auth_ipdsp） | 部署名が直接対応。新設のIP↔DSP対応表整備（4章）の担当候補 |
| 係長以上 | 横断承認・例外対応 | 特定サブシステムでなく、複数部署の管理職が名を連ねる＝承認権限や例外処理の枠と推測 |
| （未対応）K技術情報管理 | 設計/技術部門 | Soumu_Admin_Listに対応する部署名が見当たらない。DSP57（BOM変更専用端末）の運用部門を要確認 |
| （未対応）A組付・B工機・T試作・W号口・S出荷 | 製造・検査・出荷の現場 | squpのKENSA(品質課)/SEIZOU(製作部)/SEISAN(生産)がこの領域に対応。個人名でなく現場プロファイルであり、KENSA/SEIZOUの部署対応はhearing.html G1のヒアリングで確定済み（SEISANは未確認。また各部署が実際にそのプロファイルでサインインしているかは別途確認が必要） |
大きな欠落 — 現場部門の個人別台帳が見つからない
Soumu_Admin_List（総務が管理するWindows権限台帳）は事務系5部署（総務・営業・購買・金型・見積・経理・PC管理・係長職）を捉えているが、製造・検査・出荷といった現場部門の個人別台帳が見つからなかった。squp側のKENSA/SEISAN/SEIZOUという共有プロファイルが現場の実態に最も近い証拠であり、現場は「個人」ではなく「工程ログイン」で権限管理されてきたことを裏づける。部署責任分担の会議では、事務系は個人名で、現場系は「工程・ライン」単位で分担を定義する方が実態に合うと考えられる。
7.1 権限モデルの選択 — 経営判断待ち（新實さんの回答範囲を超える）
rmondo氏の決定が必要 — これは現場ヒアリングでは解決しない
hearing.html G1で新實さんに新システムの権限モデル（①個人アカウント単位か②工程・ライン単位の共有ログインか）を尋ねたところ、モデル選択そのものへの回答は得られず、代わりに前提となる制約と「これは経営判断だと思います」という明言が返ってきた。つまりこの選択は現場ヒアリングを重ねても解決しない——rmondo氏が決定すべき事項として、ここに整理する。
新實さんの回答から判明した制約:
- 社員全員にPCが配付されているわけではない。1台を複数人で共用する運用が実態。
- ほとんどがデスクトップ機のため、作業場にあるPCが共用できないと現場が困る（＝個人ログイン化しても「1人1台」は前提にできない）。
- 現行AS/400の「権限」は、そもそも個人・部署単位のアクセス制御という意味では機能していない——入力に関与しない人が誤って処理に入らないようにする誤操作防止の制限に過ぎない（＝旧オフコンの共有ログインは「セキュリティ境界」ではなく「事故防止ガード」だった）。
- AS/400の範囲を超えてExcel管理の経理・給与関係まで権限設計の対象に含めるなら、より細かな権限設定が必要になる、と新實さん自身が指摘している。
| ①個人アカウント単位（Windows台帳方式） | ②工程・ライン単位の共有ログイン（AS/400方式を継続） | |
|---|---|---|
| 現状との親和性 | 低い — 現場はPC共用が前提で、1人1台のログインは運用と噛み合わない | 高い — squpのKENSA/SEIZOU/SEISANという既存の共有プロファイルをそのまま引き継げる |
| 誰が何をしたかの追跡 | 強い — 個人単位で操作ログ・責任範囲が明確 | 弱い — 「工程ログイン」止まりで個人までは追えない（現行と同じ限界） |
| 事務系（総務・営業・経理等）への適合 | 高い — Soumu_Admin_Listで既に個人単位のExcel管理が実在する | 低い — 事務系はもともと個人ベースの実運用 |
| 現場系（製造・検査・出荷）への適合 | 低い — 共用PC・工程ログインの実態と衝突する | 高い — KENSA/SEIZOU/SEISANの実態にそのまま合う |
| 実装コスト | 個人アカウント発行・PC共用時のログイン切替運用の設計が必要 | 既存の共有ログイン運用を移植するだけで済む |
叩き台としての方向性（rmondo氏の判断待ち）: 新實さんの回答は「事務系は個人ベース、現場系は工程・ラインベース」というハイブリッドを裏づける内容になっている（6.3節末の「大きな欠落」callout、および8章質問1・2と同じ結論）。事務系（総務・営業・購買・金型・見積・経理・PC管理・係長職）は個人アカウント単位、現場系（製造・検査・出荷）は工程・ラインの共有ログインを引き継ぐ、という切り分けが実態と最も整合する。ただしこれを正式に決定するのはrmondo氏であり、本ページはその判断のための材料整理に留まる。
8. 確認したいこと
証拠→質問の対で列挙。会議の論点出しに使える形にした。この節は 14. ヒアリングシート にそのまま引き継がれる。
質問1 【ヒアリングで一部判明】
【証拠】squpのSEISANは167 CL中165個を保有し、事実上「権限管理の2CL以外は全て許可」という汎用プロファイルだった。個人ではなく共有ログイン。新實さんから、判断そのものではなく前提となる制約が判明した。社員全員にPCが配付されているわけではなく、1台を複数人で共用する運用が実態で、ほとんどがデスクトップ機のため作業場のPCが共用できないと現場が困る。また現行AS/400の「権限」は個人・部署単位のアクセス制御ではなく、入力に関与しない人の誤入力を防ぐための制限に過ぎない。「SEISAN相当の現場汎用アカウントをどこまで残すか」という設問自体が、この前提（現場は元々PC共用・誤操作防止が目的）を踏まえて再設計すべきものになった。モデル選択そのものは新實さんの回答範囲を超え、本人も「経営判断だと思います」と明言している。(出典: 新實さん、2026-07-22ヒアリングシート回答、
docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)
質問2 【ヒアリングで一部判明】
【証拠】KENSA（品質課）・SEIZOU（製作部）だけが業務内容から見て明確に狭いCLリスト（T試作・W号口の完成入力系のみ）を持っていた。新實さんの回答で、プロファイル名と現在の部署の対応は判明した——KENSA→品質課、SEIZOU→製作部。ただし「今実際にどのユーザーでサインインしているかは、各部署に確認ください」と付け加えられており、各部署が実際にそのプロファイルでサインインしているか（別のプロファイルを使い回していないか）という運用実態は依然未確認。部署責任分担の「現場系」の基本単位としてこの対応をそのまま採用してよいかの判断は、この運用実態の確認後に行うべき。(出典: 新實さん、2026-07-29ヒアリングシート回答、
docs/feedback/hearing/2026-07-29-niimi-hearing-sheet.md参照)
質問3 【ヒアリングで判明】
【証拠】auth_ipdsp（IP→DSP対応表）は本番相当DBにデモ用1行のみ。実端末は1つも登録されていない。sqdpの許可リストは全行がP（許可制）なので、未登録IPからは端末制限つき24 CLが全滅する。新實さんが、IPアドレス・コンピュータ名・使用者・部署・DSP名の対応表（全22台分）をそのまま提供してくれた——「持っている人はいるか」という問いは、新實さん自身がその台帳を持っていたことで解決した。全対応表はhearing.html G3に掲載。(出典: 新實さん、2026-07-22ヒアリングシート回答、
docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)
質問4 【ヒアリングで判明】
【証拠】DSP57はKSBS41品番構成変更（構成展開反映)専用の単機能端末、DSP64/DSP65は自動倉庫入庫/登録処理専用で完全に同一の許可リスト。新實さんから取得したIP↔DSP対応表に使用者名・部署が含まれており、部署単位の設置場所は判明した（例: DSP57＝試作組付２Ｆ・総務扱いDHCP、DSP64/65＝営業/総務の自動倉庫関連端末）。フロア単位の図面までは提供されていないが、部署・使用者ベースでの設置場所特定はこれで十分と考える。(出典: 新實さん、2026-07-22ヒアリングシート回答、
docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)
質問5 【ヒアリングで判明】
【証拠】Soumu_Admin_Listの10部署のうち、kniinomiとkminaiの2アカウントだけが全部署の許可リストに例外なく登場した。kniinomiはMailingListの最頻出受信者（新實和敏氏と推測）とも一致する。kniinomi＝新實様で間違いないか。また2026-07-17の打ち合わせ議事録に登場する「新南さん」は同一人物の表記ゆれか？（新實・新南は読みが近く、Gemini自動文字起こしの誤変換の可能性が高いと見ている）kniinomi＝新實和敏氏で確定（推測どおり）。議事録の「新南さん」も新實さん本人で、想定していたとおりGemini自動文字起こしの誤変換だった。kminai＝薬袋和樹氏（社長）も判明した。(出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)
質問6 【ヒアリングで判明】
【証拠】Soumu_Admin_List.xlsxのhitakuraとkitakuraは、共に「板倉」姓＋別の頭文字で、経理・見積・金型など複数部署の許可リストに個別に登場する。MailingListに対応する明確な実名一致が見つからなかった。hitakura＝板倉広子氏（退職済）、kitakura＝板倉考司氏（営業部係長）で確定。創業家・役員クラスという推測は当たっていたが、hitakura氏は既に退職済みのため、部署分担の「横断承認者」枠にはkitakura（板倉考司氏）のみを想定すべきと考えられる。(出典: 新實さん、2026-07-22ヒアリングシート回答、docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)
質問7 【ヒアリングで判明】
【証拠】G外製管理（MENUG1、25プログラム）はpilotアプリに実装が一切無い（pilot/app/src/menug1/ディレクトリ自体が存在しない）。squp側では3CLのみ（GSBS03/04/06）がSEISANに許可されているのみで、利用実績の手がかりが薄い。外製管理のうち現役なのは発注入力（下請法対応の注文書発行）だけで、それ以外は既に使われていないと確認された。購買業務の本体は既にExcelへ移行済みで、AS/400側に残っているのは振込手数料の計算機能のみを間借りして使っている状態。したがって部署責任分担の対象としては、MENUG1全体ではなく発注入力（注文書発行）のみを購買管理者の担当範囲として組み込めばよい。(出典: 新實さん、2026-07-22ヒアリングシート回答、
docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)
質問8
【証拠】squp/sqdpの167 CLのうち13個（DSBS16, JSBS21, KSBS02, KSBS28, KSBS29, MSBS04, MSBS21, RSBS03, RSBS04, RSBS05, WSBS25, WSBS26, WSBS31）はソース未回収（⚠missing-source）で、内容が不明のまま許可リストに載っている。【質問】これらの13 CLが今も現場で使われているか確認できる人はいるか？（経理系のRSBS03/04/05が3つ含まれるため、経理部門への確認を優先したい）
質問9 【ヒアリングで一部判明】
【証拠】旧オフコンの権限は「共有ログイン×端末」の2軸のみで、個人×部署という軸は存在しなかった（Windows/Excel層にのみ部署別の個人アクセス表が別立てで存在）。新實さんへ確認したところ、①②のどちらを基本にするかというモデル選択自体は「経営判断だと思います」と明言され、現場側の判断範囲を超えることが確定した。あわせて前提となる制約（PCの多くは複数人共用のデスクトップ機、現行AS/400の「権限」は個人・部署のアクセス制御ではなく誤入力防止のための制限に過ぎない）も判明した。この2点を踏まえ、会議ではモデル選択そのものをrmondo／経営陣が決める議題として扱う。(出典: 新實さん、2026-07-22ヒアリングシート回答、
docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)
質問10 【ヒアリングで判明】
【証拠】DSP52とDSP59は他端末より広いCLセット（J受注＋K技術情報＋D(EDI)＋S出荷/Z材料金型の一部）を持ち、フロア統括端末のように見える。新實さんの回答により、この前提自体が訂正された: 「統括端末、横断端末の意味は分かりませんが、特にこの端末が特別という考えはないです。新實が使っているのがDSP59というだけです。DSP52はデンソープレステックのメールを受けるPCなので他の端末よりも機能が多くなっていると思われます。」——つまり「複数部署を横断する統括端末」という設計思想は板倉製作所の運用には存在せず、DSP59が広いのは単に新實さん個人の端末だから、DSP52が広いのはデンソープレステックのメール受信専用という業務都合に過ぎない。後継システムで「横断端末」を意図的に残すか分離するかという設計判断自体は不要になった。(出典: 新實さん、2026-07-22ヒアリングシート回答、
docs/feedback/hearing/2026-07-22-niimi-hearing-sheet-G.md参照)
付録: 主な証拠ファイルパス
- DB:
docker exec itakura-pilot-db psql -U pilot -d itakura（squp/sqdp/auth_users/auth_ipdsp） - 権限モデル仕様:
pilot/spec/auth/convention.md - 決定記録:
docs/decisions.mdD10（認証移植）、D23（MENUR1発見）、D9/D11（MENUD1のW7扱い） - 実装:
pilot/app/src/auth/{itsq01r,clgate,session,routes,errors,types}.ts,pilot/app/src/masters/authorize.ts, 各menu*1/routes.ts - サブシステム集計:
analysis/out/subsystems.csv,analysis/out/members.csv,analysis/out/menu_tree.md - Excel台帳:
source/as400-admin/settei-misc/Soumu_Admin_List.xlsx,source/as400-admin/settei-misc/MailingList.xlsx,source/as400-admin/settei-misc/User_Data.xls（変換CSVはセッションのスクラッチパッドに保存） - 会議記録:
docs/planning/interview.md
板倉製作所 業務フロー資料 — 出典: AS/400 ソース・翻訳仕様・Excel/VBA 資産（itakura-sys リポジトリ）
← 10. システムの一日・一年 / 12. ケーススタディ・特殊ケース →