これは何か
使用ソフトウェア・依存関係一覧は、システムを作り、動かすために使っているソフトウェアの部品（基盤のソフト、プログラムが利用する部品、開発や運用の道具）を、版・用途・使っている場所・管理する責任者・更新の予定つきで書き出した成果物です。
今のシステムは、自分たちで書いたプログラムだけでは動きません。世の中で公開されている部品を数多く組み合わせて動きます。部品のどれか一つに欠陥や脆弱性（攻撃に使える弱点）が見つかると、それを使っているすべての場所が影響を受けます。「どこで何を使っているか」が分からなければ、影響の範囲も直す順番も決められません。この一覧は、そのための台帳です。
なぜ作るか
- 部品の欠陥・脆弱性が公表されたとき、影響する場所をすぐに特定する
- 古くなった部品（提供元の保守が終わるもの）を、計画的に更新する（14-04 システムは完成しない）
- 利用の条件（ライセンス）を守っているかを確かめる
- 会社ごとに使う部品がばらばらにならないよう、共通の基盤をそろえる（09-03 開発・テスト・本番をなぜ分けるのか）
誰が使うか・いつ作るか
- 作る人：開発・CI/CD 基盤を担当する会社と、各システムの開発の取りまとめ役。セキュリティの担当が確認する
- 使う人：セキュリティの担当、運用の担当、各ベンダーの開発者、監査に対応する人
- 一般的には、開発環境を作るときに最初の形を作り、自動の流れ（DEV-003 自動テスト・自動配布構成）で部品の一覧を機械的に集め、人が責任者と更新の予定を足して育てます
- アステリア案件で使われた部品、版、管理の責任者は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
部品の管理に関係する記載
- システムは 11（SYS-01〜SYS-11）。うち SYS-09 開発・CI/CD基盤、SYS-10 AI開発エージェント、SYS-11 監視・ログ基盤
- SYS-03 勤怠・工数管理SaaS は Vendor D タイムリンクの担当範囲（外部のサービスとして利用）
- Vendor B クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視
- P-012 石井 稔 — セキュリティ責任者、P-013 木村 亮 — AIガバナンス責任者
アステリア案件で、どの部品をどの版で使い、脆弱性の公表にどう対応したかは、正本に記載がありません。未確定 上の人物がこの一覧を管理したという記載もありません。未確定
主な項目
一般的には、部品 1 件ごとに次の項目を持ちます。
- 部品の名前と種類：基盤のソフト（OS、データベース、実行環境）、プログラムが利用する部品（ライブラリ）、開発・運用の道具、外部のサービス
- 版：使っている版と、提供元の保守の期限
- 使っている場所：どのシステムの、どの部分で（直接使っているか、ほかの部品を通じて間接的に使っているか）
- 用途：何のために使うか
- 管理の責任者：更新や脆弱性への対応を決める人（会社と役割）
- 利用の条件：ライセンスの種類と、守るべき条件
- 更新の方針：いつ、どの条件で版を上げるか。上げられない事情があるなら、その理由と代わりの対策
- 脆弱性の確認：最後に確認した日と、対応中のもの
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 一覧の抜粋と、脆弱性が公表されたときの読み方
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、一覧の書き方を学ぶための例です。部品名は種類だけを書いた架空の例で、実在の製品を示すものではなく、アステリア案件の記録でもありません。
| 部品（教材上の例） | 種類 | 版 | 使っている場所 | 責任者 | 保守の期限 | 更新の方針 |
|---|---|---|---|---|---|---|
| データベースの製品 X | 基盤 | 14 系 | 新基幹、連携基盤 | 基盤を担当する会社 | 来年 9 月 | 年 1 回、保守の期限の 6 か月前までに |
| 帳票を作る部品 Y | ライブラリ | 2.8 | 新基幹の請求の画面 | 新基幹を担当する会社 | 提供元の告知なし | 脆弱性の公表時に即時 |
| 日付を扱う部品 Z | ライブラリ（間接） | 1.4 | 部品 Y を通じて利用 | 新基幹を担当する会社 | ― | 部品 Y の更新に合わせる |
| 工数管理の外部サービス | 外部サービス | 提供元が管理 | 連携の受け口 | サービスを担当する会社 | 契約期間内 | 提供元の仕様変更の告知を受けて確認 |
| 確認すること（教材上の例） | 一覧のどこを見るか | 決めること |
|---|---|---|
| その部品を使っているか | 部品の名前と版（間接利用を含む） | 影響の有無 |
| どこで使っているか | 使っている場所 | 直す範囲と順番 |
| 誰が直すか | 管理の責任者 | 対応の担当と期限 |
| すぐ直せないとき | 更新の方針の「代わりの対策」 | 一時的な守り方（機能の停止、通信の制限など） |
読み方
- 間接的に使っている部品（部品の部品）まで一覧に入っているか
- 部品ごとに責任者が決まっているか。「全員」「各社」のようなあいまいな書き方になっていないか
- 保守の期限が近い部品が見えるようになっているか
- 脆弱性の確認の日付が新しいか。確認が止まっていないか
- 一覧が手作業だけで作られていないか（手作業だけだと、すぐ現物とずれる）
書き方
- 部品の一覧は、自動の流れで機械的に集める（開発の道具は、使っている部品の一覧を出せるものが多い）
- 集めた一覧に、人が責任者・用途・更新の方針を足す
- 脆弱性の情報と突き合わせる仕組みを、自動の流れに組み込む（DEV-003 自動テスト・自動配布構成）
- 保守の期限が近い部品を、定期的に（たとえば四半期ごとに）棚卸しする
- 脆弱性が公表されたときの確認の手順を、一度実際に通してみる
何を書いてはいけないか
- 責任者のいない部品（「誰かが見ているはず」は、誰も見ていない）
- 版の書かれていない部品（版が分からなければ、影響の有無も分からない）
- 「最新にする」とだけ書いた更新の方針（上げられない事情があるときの扱いを書く）
- 実在の製品名を、案件の正式な採用として書くこと（正本に記載がない）
どこを見るか
- 間接利用を含む部品の網羅
- 部品ごとの責任者
- 保守の期限と更新の方針
- 脆弱性の確認日
- 一覧を自動で集める仕組みの有無
赤信号
- 一覧が開発の初期に一度作られたまま、現物とずれている
- 脆弱性が公表されても、影響の有無を答えるのに何日もかかる
- 保守の終わった部品が本番で動いていることに、一覧からは気づけない
- 会社ごとに別々の一覧があり、全体を見渡せる人がいない
よくある失敗
- 直接使っている部品だけを書き、部品の部品（間接利用）を見落とす。脆弱性の影響を「ない」と答えてしまう
- 版を上げると動かなくなる部品を「上げない」と決めたまま理由を残さず、保守が終わって初めて問題になる
- 外部のサービス（SaaS）を「自分たちの部品ではない」と一覧から外し、提供元の仕様変更の告知を誰も受け取っていない
関係するUnit・成果物・危機演習
- Unit：09-04 自動テストと自動配布、09-03 開発・テスト・本番をなぜ分けるのか、14-04 システムは完成しない、08-05 開発者は本番データを自由に見てよいのか
- 成果物：DEV-003 自動テスト・自動配布構成、SEC-001 セキュリティ基本方針、SEC-005 セキュリティ評価報告書、ARC-007 環境・配置構成図
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、自動で集めた部品の一覧と、人が管理している一覧の差を見つける下書きに役立ちます。
「次の 2 つの一覧（自動で集めた部品の一覧と、管理台帳）を突き合わせ、片方にしかない部品、版が違う部品を一覧にしてください。どちらが正しいかは判断せず、差の箇所だけを示してください。」
REVIEW
- AIが「同じ部品」と判断した根拠が妥当か（名前が似ているだけの別物ではないか）
- 部品の一覧を AI に渡してよいか（構成情報の扱い）を事前に確かめたか
- 差が見つかった部品について、どちらに合わせるかを人が決めたか
人間が判断すること
- 部品ごとの責任者を誰にするか
- 脆弱性が公表されたとき、すぐ直すか、一時的な対策で持たせるか
- 保守の終わる部品を、いつ、どう置き換えるか
セキュリティ例外承認は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 09｜120人で安全に開発する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この一覧を見た担当者は、「ある部品に欠陥や脆弱性が公表されたとき、それをどのシステムのどこで使っていて、誰が直す責任を持つか」を、その日のうちに答えられますか？