このユニットの結論
容量は「多めに」でも「ぎりぎり」でもなく、計算して決めます。
いまの量、増える速さ、山（ピーク）の高さ、の 3 つを根拠つきで置き、部品ごとの計算の仕方で必要量に直し、余裕率と「いつ増やすか」の目安を決める。これを文書にしたものが容量計画です。計算のない容量は、足りなくなるか、無駄になるかのどちらかです。
1. 何の話か
このユニットは、システムに用意する計算機・記憶領域・通信の大きさ（容量）をどう決めるかの話です。
06-02 何人まで利用できればよいのか では、同時利用者数という要件の決め方を学びました。ここでは、その要件を実際の部品の大きさに翻訳し、増える量に合わせて増やしていく計画を扱います。世界で共有されている考え方では「容量計画（キャパシティプランニング）」と呼びます。
2. なぜ必要か
計算せずに決めると、
- 通常時は問題なくても、締めの日や期末の山で遅くなり、止まる
- 稼働の 1 年後にデータの置き場所が足りなくなり、慌てて増設する
- 逆に、不安から過大に用意し、使われない部品に毎月費用を払い続ける
ということが起きます。容量は一度決めて終わりではなく、増える量に合わせて見直し続けるものです。
3. このユニットで分かること
- 容量を決める 3 つの前提（いまの量・増える速さ・山の高さ）
- 前提から必要量への計算の仕方
- 余裕率と「いつ増やすか」の目安
4. 3 つの前提
| 前提 | 何を調べるか | 根拠の取り方（一般的な例） |
|---|---|---|
| いまの量 | 登録利用者、同時利用者、1 日の処理件数、データの総量 | 現行システムの記録（最も信頼できる）。新規なら類似業務の実測 |
| 増える速さ | 1 年でどれだけ増えるか | 採用計画、事業計画、過去数年の増加の実績 |
| 山の高さ | 通常時の何倍になるか、いつ来るか | 業務のカレンダー（締め、給与、期末）。現行の時間帯別・日別の記録 |
山の高さは見落とされやすい前提です。月に 1 度の締めの日に同時利用者が通常の 3 倍になるなら、容量は 3 倍の日に合わせて決めるか、山の日だけ増やせる仕組みにするかを選びます。
5. 計算と余裕率
部品ごとに「計算の仕方」を決めます。たとえば、画面を処理する計算機なら「山の日の同時利用者 ÷ 1 台が受け持てる人数」、データの置き場所なら「件数 × 1 件の大きさ × 索引などの係数」、夜間処理なら「件数 ÷ 1 時間に処理できる件数」です。1 台が受け持てる人数や 1 件の大きさは、試験で測ります。
余裕率は、必要量に対してどれだけ余裕を持つかです。通常時の使用率を 6 割程度に保つ、といった置き方をします。使用率が高いほど、少しの増加で遅くなります。
いつ増やすかは、「使用率がこの値を超えたら、これだけ増やす」という目安と、増やすのにかかる日数で決めます。増やすのに 10 営業日かかる部品は、10 営業日より前に判断しなければ間に合いません。
計算の前提と結果は ARC-008 容量計画書 に書き、性能試験（TST-005 性能試験結果報告書）で「計算どおりか」を確かめます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の量に関する記載
- アステリア株式会社は従業員 約4,000名
- 約1,500件の要件、約36本のシステム連携、10年分のデータ移行
- システムに SYS-01 新基幹システム、SYS-06 システム連携基盤、SYS-07 BI基盤 がある。Vendor B クラウドブリッジの担当範囲に クラウド基盤、ネットワーク が含まれる
- 成果物に ARC-008 容量計画書、TST-005 性能試験結果報告書 がある
- P-008 黒田 健 — システムアーキテクト
同時利用者数、処理の件数、データの総量、増える速さ、山の高さ、用意した部品の大きさは、正本に記録がありません。記録なし 「従業員 約4,000名」は会社の規模であり、同時利用者数ではありません。
6. THINK — 「余裕を見て 2 倍にしておけばよい」
基盤の設計の会議で、次の意見が出ました。
「容量の計算は難しいので、現行システムの 2 倍にしておけば安全でしょう。」
問題
この決め方の問題は何でしょうか。
判断例を開く
判断
「現行の 2 倍」は、現行が足りていたのか、山の日に足りていなかったのか、何年持つのかが分からない数字です。
確認すること:
- 現行の使用率はどれだけか。山の日に遅くなっていなかったか
- 新システムは現行と処理の仕方が違う（1 件あたりの重さが違う）可能性があるか
- 増える速さを見込んだとき、2 倍は何年持つか
- 部品によって必要な倍率は違わないか（データの置き場所は増え続け、計算機は山に合わせる）
- 2 倍の費用を毎月払う根拠を、経営層に説明できるか
「2 倍」が結果として正しいこともあります。しかし計算なしの 2 倍は、足りない部品と無駄な部品を同時に生みます。前提を 3 つ置いて計算し、その結果が 2 倍なら 2 倍にします。
7. よくある失敗
- 登録利用者数をそのまま同時利用者数として計算し、過大に用意する
- 通常時の量だけで計算し、締めの日に遅くなる
- データの増える速さを見込まず、1 年後に置き場所が足りなくなる
- 増やすのにかかる日数を知らず、足りなくなってから発注する
8. 成果物との接続
- ARC-008 容量計画書：3 つの前提、部品ごとの計算の仕方、余裕率、増やす目安を書く
- TST-005 性能試験結果報告書：計画書の前提の量で試験し、計算どおりかを確かめた結果
9. AI WORKFLOW — 計算の検算をさせる
AIは、容量計画書の「前提 × 計算の仕方 ＝ 必要量」の検算に役立ちます。
指示例:
「次の容量計画の表について、部品ごとの『計算の仕方』に『前提の量』を当てはめて計算し直し、書かれている必要量と一致するかを示してください。一致しない行は差を示してください。前提の値や計算の仕方が妥当かどうかは判断しないでください。」
10. REVIEW — AIの検算を確認する
- AIが計算の仕方（単位、係数）を正しく読み取っているか
- 差が出た行は、計画書の誤りか、AIの読み違いかを人が確かめたか
- 計画書を AI に渡してよいか（構成情報の扱い）を事前に確かめたか
11. 人間が判断すること
- 余裕率をどこに置くか（費用との釣り合い）
- 山の日に合わせて常に用意するか、山の日だけ増やす仕組みにするか
- 増やす目安に達したとき、増やすか、使い方を見直すか
設計承認は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
社員食堂の席数を決める、と想像してください。
「いまの量」「増える速さ」「山の高さ」をそれぞれ何で調べるか、席数の「計算の仕方」をどう置くか、余裕率と「いつ増やすか」の目安をどう決めるかを書いてください。そのうえで、システムの容量計画と同じ考え方の部分と、違う部分を 1 つずつ書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
容量は計算で決める。いまの量・増える速さ・山の高さを根拠つきで置き、部品ごとの計算の仕方で必要量に直し、余裕率と増やす目安を決める。試験で計算どおりかを確かめる。