情報システムハードウェア規模算定指針（TTAK.KO-10.0292/R3）
1. 概要
A. 定義
情報システム構築時にサーバー・ストレージ・ネットワークなどのハードウェア容量を業務量と性能指標に基づき客観的・定量的に算定するためのTTA（韓国情報通信技術協会）標準指針であり、R3（2023.12改定）はクラウド・仮想化環境を反映して算定式と参照表を更新したものである。
規模算定（Sizing）は「どの程度の性能の装置を、どれだけ備えるべきか」を根拠をもって決定する活動である。これは単なる見積もりではなく、将来の業務量を予測しその業務量を処理する計算資源を逆算する需要-供給の整合問題である。経験やベンダー提案のみに依存すると判断の責任所在が不明確になり、事業者間の提案が互いに比較不能になるが、この指針は共通の計算手順と標準性能指標（tpmCなど）を規定することで、異なる事業者・監理者・発注機関が同じ方式で検証可能な根拠を作るよう強制する。
TTA標準番号 TTAK.KO-10.0292 は幾度も改定され、算定対象と指標を拡張してきた。当初はサーバー中心のtpmC算定が骨子であったが、改定を経てストレージ・ネットワーク・セキュリティ装置へ対象が広がり、仮想化・クラウド資源共有を前提とした補正論理が追加された。すなわち指針は固定された計算器ではなく、技術環境の変化に合わせて算定モデルを更新してきた生きた標準であるという点を理解することが重要である。
この指針の性格を要約すると三つである。第一に客観性 — 算定根拠を標準指標と係数で明示し、誰でも辿って検証できる。第二に定量性 — 経験的判断を排除し業務量の数値から規模を逆算する。第三に再現性 — 同じ入力なら同じ結果が出るよう手順を規定し、事業者・監理者間の結果を比較可能にする。この三つの性格が公共調達・監理体系で指針が事実上の準拠として機能する根拠である。
B. 登場背景および必要性
ハードウェア算定は双方向に失敗する。過大算定は必要以上の装置を買い込み、予算と床面積・電力・冷房を浪費し、減価償却が終わる前から遊休資源として残る。逆に過小算定はピーク時の応答遅延・タイムアウト・障害につながりサービスの信頼を崩し、急いで増設するため追加予算とシステム停止を強いる。両方の失敗ともコストであるが、特に過小算定は開通直後に対国民サービスが止まる形で表れ社会的波及が大きい。
特に国民の税金が投入される公共・大規模事業では「なぜこれだけの装置が必要か」を監理・予算審議・調達の過程で客観的に釈明しなければならない。例えばある公共機関が次世代システムに高性能サーバー数十台を提案したなら、監理はその数量の根拠となる同時利用者数・トランザクション量・ピーク率・余裕率を要求する。標準指針がなければこの釈明は「ベンダーがそう提案した」という循環論理に陥るが、指針があれば算定式と係数を辿り結果の妥当性を事後検証できる。
また算定根拠の標準化は紛争予防の機能もする。開通後に性能問題が発生したとき、算定時に反映した業務量の仮定と実際の業務量を比較すれば、責任が発注機関の要求事項の不備なのか、事業者の算定誤りなのか、予測不可能な需要急増なのかを分けられる。根拠が文書化されていてこそこうした事後判断が可能である。
C. 規模算定対象
算定対象はサーバー（WAS/DB/AP）、ストレージ・バックアップ、ネットワーク（回線・スイッチ）、セキュリティ装置に区分する。各対象は負荷の性格が異なり指標も異なる。サーバーは毎秒処理量（TPS・tpmC）とCPU・メモリを中心に、ストレージはデータ総量・増加率とIOPS（毎秒入出力）を、ネットワークは同時セッションと帯域幅（bps）を、セキュリティ装置は毎秒処理セッション・スループットを基準に算定する。
対象別に指標が異なる理由はボトルネックの位置が異なるからである。トランザクションがいかに速くてもディスクIOPSが追いつかなければDBがボトルネックになり、サーバーに余裕があっても回線帯域幅が不足すれば大量転送が塞がる。したがって算定は単一指標ではなく資源別のボトルネックを併せて点検する多次元作業であり、ある一つの資源だけ潤沢に取り残りを放置すれば、システム全体は最も弱い環の性能に縛られる。
また対象は階層（tier）別に負荷性格が変わる点も考慮すべきである。3階層（Web-WAS-DB）構造でWeb階層は静的処理・セッションが多く水平拡張が容易で、WASはビジネスロジックでCPUを多く使い、DBは状態を持つ単一地点であり垂直拡張と冗長化の負担が大きい。したがって同じトランザクションでも階層ごとに要求資源が異なって算定され、特にDB階層は拡張が難しく算定誤りの代償が最も大きい。
2. 規模算定手順と全体構造
flowchart LR
A["要求・業務量分析"] --> B["算定対象・方式選定"]
B --> C["基準値・補正係数適用"]
C --> D["規模算出"]
D --> E["検証・調整"]
E -->|"不足・過大"| A
手順の核心論理は「需要をまず定義し、その需要を装置の単位性能で割る」ことである。規模算定を割り算で要約すると必要装置 = 総要求性能 ÷ 装置1台の単位性能であり、この式の分子をいかに正確に立てるかが算定の質を左右する。
第一段階の業務量分析では同時利用者数・トランザクション（TPS）・データ量とピーク（最大負荷）時点を把握する。規模算定は平均ではなくピークに耐えねばならないためピーク把握が特に重要である。例えば年末調整・受講申込・連休の予約のように特定時点で負荷が急増するシステムは、平均負荷で算定すれば必ず失敗する。この段階で過去ログ・類似システム統計・業務担当者インタビューを根拠にピークシナリオを具体的な数値で確定する。
次に対象別の算定方式を定める。新規大規模システムは標準性能指標に基づく定量算定が適し、既存システムの増設や類似事例が豊富な場合は参照モデルを併用する。続いて性能・余裕率・冗長化・目標可用率など補正係数を反映して総要求性能を膨らませたうえで規模を算出し、最後にベンチマーク（BMT）・負荷試験・妥当性検討で検証・調整する。検証結果で過大・過小が明らかになれば業務量の仮定に立ち戻って再算定する反復ループがこの手順の本質である。
この手順が強調するのは各段階の追跡可能性である。最終装置数量から逆に業務量プロファイルまで辿れてこそ監理・審議での釈明が可能である。逆にある段階の仮定が文書化されなければその地点が検証の死角となり、開通後の問題発生時に責任究明が不可能になる。したがって手順の成果物（業務量プロファイル・補正根拠表・算定結果書）を段階ごとに残すことが指針遵守の実質的要件である。
| 段階 | 内容 | 成果物 |
|---|---|---|
| 業務量分析 | 同時利用者・トランザクション（TPS）・データ量・ピーク把握 | 業務量プロファイル |
| 方式選定 | 対象別の算定方式（定量・参照）決定 | 算定方式書 |
| 補正適用 | 性能・余裕率・冗長化・可用率係数反映 | 補正根拠表 |
| 算出・検証 | 規模計算後に妥当性・ベンチマーク検証 | 規模算定結果書 |
3. 規模算定方式と性能指標
flowchart TB
subgraph Demand["要求性能（分子）"]
T1["基準トランザクション量"] --> M["総要求性能"]
T2["ピーク率"] --> M
T3["余裕率・冗長化・可用率"] --> M
end
subgraph Unit["単位性能（分母）"]
U1["tpmC / OPS / SPECint"] --> U["装置の単位性能"]
end
M --> R["必要規模 = 要求性能 ÷ 単位性能"]
U --> R
算定方式は大きく三つの軸で構成される。数値（定量）基盤はTPC-CのtpmC、トランザクション処理量（OPS）、SPECのSPECintのような標準性能指標で計算する方式である。tpmCは「毎分処理可能な新規注文トランザクション数」を意味するTPC-Cベンチマーク指標であり、サーバー製造社が公認測定値を公開するためこれを分母（単位性能）とすれば根拠が明確で大規模新規システムに適する。SPECintは整数演算性能を表しCPU集約業務の算定に用いる。
参照モデル基盤は類似の既存システムの実測値や標準構成を比較・類推する方式である。新規指標の算定が難しい場合（例：ベンチマークのない新技術装置）や定量算定結果を交差検証すべきときに用いる。例えば同格機関の同一業務システムがサーバー4台で運用中で、我々の業務量がその1.5倍なら、6台前後を参照値として定量算定値と対照する。参照モデルは現実適合性が高いが参照対象の品質に結果が左右される限界がある。
これに補正・余裕率を共通に適用して現実の不確実性を吸収する。算出式の骨格は必要性能 = 基準トランザクション量 × ピーク率 × 余裕率 ÷ 装置の単位性能である。具体事例として、平常時に毎秒100トランザクションを処理するシステムでピーク時に負荷が3倍に集中し（ピーク率3）、CPU使用率を70%までのみ使うよう30%の余裕（余裕率 ≈ 1/0.7 ≈ 1.43）を置けば、実際に確保すべき性能は100 × 3 × 1.43 ≈ 429 TPSで基準値の4倍を上回る。ここに障害対応の冗長化（N+1）まで加えれば確保規模は再び増える。このように係数を明示的に掛けてこそ算定根拠が透明になり、各係数の妥当性を個別に審査できる。
| 方式 | 説明 | 適合状況 |
|---|---|---|
| 数値（定量）基盤 | tpmC・OPS・SPECintなど標準性能指標で計算 | 新規・大規模、公認根拠が必要 |
| 参照モデル基盤 | 類似システム事例・標準構成と比較類推 | 増設・交差検証、指標算定が困難 |
| 補正・余裕率 | ピーク率・増加率・冗長化・目標可用性反映 | すべての算定に共通適用 |
補正係数をいくつに取るかはトレードオフの核心である。余裕率を大きく取れば安全だが過大算定に流れ、小さく取れば経済的だがピークに脆弱になる。指針はこの係数を恣意的に定めないよう業務特性別の参照範囲と根拠提示を要求し、これが「感による算定」と「標準算定」を分ける地点である。
CPU・tpmCだけでなくメモリ算定も別途重要である。WASは同時セッション数 × セッション当たりヒープ使用量で基本メモリを取り、DBはバッファキャッシュ・整列領域・コネクションプールを合算して算定する。メモリが不足するとスワッピング・GC（ガベージコレクション）の急増でCPUに余裕があっても応答が急落するため、「CPUは潤沢なのに遅い」典型的ボトルネックがメモリの過小算定から来る。したがってtpmC基盤のCPU算定とメモリ算定を独立して行い交差点検すべきである。
余裕率にはピーク持続時間という変数も隠れている。瞬間的スパイクはキューイング・バッファで吸収できるが、ピークが数十分以上持続すれば資源が実際にその分必要である。したがって同じピーク率でも「短く尖った負荷」と「長く緩やかな負荷」は要求性能が変わり、業務量分析で負荷の形態（持続時間・分布）まで把握してこそ余裕率を合理的に決定できる。
4. 算定実務事例と比較
定量算定と参照算定は排他的でなく相互補完的である。実務では定量式で1次規模を出し、参照モデルでその値が常識的な範囲か交差検証したうえで、最終的にBMT（ベンチマークテスト）で実証する3段構造をよく用いる。三つの方法の結果が大きく食い違えば業務量の仮定か係数のいずれかが誤りであり再検討の信号となる。
この交差検証が重要な理由は各方法が見逃す誤差が互いに異なるからである。定量式は係数の仮定が誤れば静かに大きく外れるが現実感覚がなく、参照モデルは現実的だが参照対象と業務特性が異なれば歪む。BMTは最も信頼度が高いが時間・費用がかかり実データの確保が難しい。三つの方法を重ねて用いれば一方の誤差を他方が捉えるため、いずれか一つに依存するときより算定の頑健性が高まる。
具体事例として対民ポータルを考えよう。平常時に同時接続1万人、利用者当たり毎秒0.2トランザクションなら基準負荷は2,000 TPSである。しかし特定の政策発表日に接続が5倍に集中するならピーク率5を適用して1万TPSが要求される。ここに余裕率1.43と無停止のための冗長化を加えれば確保すべき性能は2万TPSを超え、サーバー1台の単位性能がtpmC換算で一定水準なら必要なサーバー台数が算出される。この計算がなければ「サーバー数台で十分だ」という主張は検証不能な宣言に過ぎない。
各資源の算定論理が異なる理由は先に挙げたボトルネックの位置が異なるからであり、実務的含意は「資源を均衡よく確保すべき」ということである。ある一つの資源だけ過投資すればコストは増えても全体性能は最弱資源に縛られ改善されない。この均衡感覚が規模算定を単なる割り算でなく設計活動にする。
ネットワーク算定もまた単純な帯域幅の掛け算では終わらない。同時セッション数、セッション当たり平均/ピークトラフィック、セキュリティ装置（ファイアウォール・IPS）のセッション処理限界を併せて見なければならない。例えば帯域幅は潤沢なのにファイアウォールの同時セッションテーブルが埋まれば新規接続が拒否されるが、これは回線を増やしても解決しない別のボトルネックである。このように各資源の「最も先に枯渇する限界値」を識別することが正確な算定の要である。
ストレージ算定はサーバーと論理が異なる。データ総量だけでなく増加率とIOPSを併せて見るべきである。例えば初期データ10TBに年30%増加を仮定すれば3年後に約22TBが必要で、ここにバックアップ・スナップショット・インデックスのオーバーヘッドと余裕空間（通常20〜30%）を加えて実際の確保容量を取る。同時にトランザクションが要求するIOPSをディスク構成（SSD/HDD・RAID）が耐えられるか別途確認してこそ、容量は十分なのに入出力がボトルネックになる状況を避けられる。
増加率の仮定は複利で累積するため小さな誤差も長期的に大きく開く。上の例で増加率を30%でなく50%と誤って低く見積もれば3年後の実際の必要量は約34TBに跳ね上がり算定値を大きく超過する。したがってストレージはサーバーより再算定・増設が頻繁な資源であることを前提に、オンライン増設が可能な構造（スケールアウトストレージ・ボリューム拡張）を併せて設計するのが実務的である。これがサーバーは初期に潤沢に、ストレージは拡張性中心に接近する理由である。
| 区分 | サーバー | ストレージ | ネットワーク |
|---|---|---|---|
| 核心指標 | TPS・tpmC・SPECint | 総量・増加率・IOPS | 同時セッション・帯域幅 |
| ボトルネック要因 | CPU・メモリ | 容量・入出力 | 回線・スイッチ |
| 余裕反映 | CPU使用率上限 | 余裕空間20〜30% | ピーク帯域幅 |
公共部門の実際の監理現場では、この表の各項目ごとに「仮定値-根拠-計算-結果」が一行ずつ噛み合うか点検する。例えばサーバー算定でピーク率3の根拠が過去3年のトラフィックログか、余裕空間25%がバックアップ・インデックスのオーバーヘッドを反映した値かを確認する。根拠なく大きな係数を入れれば過大算定として減額調整され、逆に増加率を欠落すれば早期増設リスクとして指摘される。このように指針は算定を監査可能な形にして予算の正当性を確保する。
5. 深化：クラウド・FinOps時代の算定の変化
技術士の観点で注目すべき最新の変化は、クラウド移行が算定のパラダイムを変えている点である。オンプレミス時代の算定は「将来のピークまで耐える装置を初期にすべて買っておく」固定確保（ピーク対比プロビジョニング）モデルであった。しかしオンデマンド・オートスケール環境では平常時に最小資源のみ置き、負荷が上がると自動で増やすため、重心が「ピーク対比の固定確保」から「弾力確保 + コスト最適化（FinOps）」へ移る。
それでも規模算定指針は依然として有効であり、むしろ役割が再定義される。オートスケールも最小・最大容量と予算上限を定めてこそ暴走するコストを防げ、その境界値を定めるには業務量に基づく定量根拠が必要である。予約インスタンス（RI）・セービングプランのように長期約定で単価を下げる決定も「基底負荷はいくらか」という算定判断の上に立つ。すなわちクラウドは算定をなくしたのではなく、1回性の初期算定から継続的な容量・コスト管理へ性格を変えたのである。
コンテナ・Kubernetes環境でもポッドのrequests/limits、HPA（水平ポッドオートスケーラ）の閾値設定が新たな算定対象になる。requestsを大きく取りすぎるとノード資源が浪費され、小さく取りすぎるとOOM（メモリ不足）・スロットリングで性能が崩れる。結局「要求性能を測定して単位資源で割る」という指針の根本論理は物理サーバーからポッドへ単位が変わっただけでそのまま作動する。
実務事例として、大規模 eコマースは平時に対し大型セール当日の負荷が数十倍に跳ね上がる極端なピークを経験する。これらは固定確保では対応不可能なため、平時は最小資源で運用し、イベント前に予測負荷に合わせて事前スケールアップしオートスケールで残りの変動を吸収する。このときも「どこまで増やすか（最大容量）」と「予算上限」はサイジング計算であらかじめ定め、ここで規模算定指針の論理がクラウド費用統制の骨格として再活用される。
観測可能性（Observability）の発展は算定の根拠を事前予測から実測に基づく継続補正へ移す。APM・メトリクス収集で実際の負荷を常時観察すれば、算定時に仮定したピーク率・余裕率が現実と合うか検証し次の増設判断に反映できる。これは指針が要求する「検証・調整」ループを運用段階まで延長したものと見なせる。
出題方向の面では、ハードウェア規模算定は「算定式と係数を正確に記述する」短答型を超え、クラウド・オートスケールとの関係、FinOps観点のコスト最適化、可用性設計との連携を問う方向へ深化する可能性が大きい。したがって答案ではtpmC算定式という古典的根拠と、弾力確保・継続的容量管理という最新の流れを併せて編み込んで記述するのが高得点戦略である。指針の存在理由（客観的根拠の確保）をオンプレ・クラウドを貫く原理として提示すれば説得力が高まる。
6. 考慮事項および示唆点
将来・成長の反映：算定は開通時点のスナップショットではなく今後3〜5年のデータ・利用者増加を包括すべきである。成長率を欠落すれば早期増設で追加コストと停止が発生し、過度に取れば初期過投資になる。成長曲線の根拠（事業計画・過去趨勢）を明示することが要である。
可用性・冗長化設計との連携：目標可用率（例：99.9%）はすなわち冗長化・DR（災害復旧）容量を決定するため算定と分離できない。無停止を要求すればN+1以上の余裕ノードが必要で、これは確保規模をその分大きくする。可用性要求を定量目標としてまず確定したうえで算定に反映すべきである。
検証なき算定の危険：計算式だけで終えずBMT・負荷試験で実証すべきである。ベンダー公認のtpmCは理想的条件の値であり実際の業務ではそのまま出ない場合が多いため、実データ・クエリで測定した値との乖離を補正してこそ算定値が信頼を得る。
クラウド・FinOpsへの戦略転換：オンプレ-クラウド混合（ハイブリッド）環境では基底負荷はオンプレ・RIで、変動負荷はオンデマンド・オートスケールで分ける戦略的配置が有効である。算定はこの配置の境界を定める根拠となり、初期容量だけでなく継続的コスト最適化の基準線として活用される。
標準・監理整合性：公共事業ならば算定根拠がTTA指針・監理基準と整合してこそ予算審議・監理を通過する。算定方式・係数・参照根拠を文書化して事後検証可能性を確保することが技術士が押さえるべき実務ポイントである。
資源均衡と階層別拡張性：CPU・メモリ・IOPS・帯域幅を均衡よく確保しつつ、DBのように水平拡張が難しい単一地点は初期から余裕と冗長化を潤沢に取るべきである。拡張が容易な階層と難しい階層を区分し余裕率を差等適用することが費用対効果が大きい。
持続可能性・電力効率（グリーンIT）：近年データセンターは電力・炭素制約が大きくなり、過大算定は予算だけでなく電力・冷房・炭素の面でも負担である。算定時に性能当たり電力（ワット当たり性能）とPUEを併せて考慮し持続可能な規模を選択する観点が求められる。
不確実性下の意思決定：将来の業務量は本質的に予測であるため、単一シナリオではなく楽観・基準・悲観の多重シナリオで算定しその幅を意思決定者に提示するのが望ましい。クラウドの弾力性はこの不確実性を吸収する手段になるため、予測信頼度が低い新規サービスほど固定確保より弾力確保の価値が大きくなる。
参考資料
- 韓国情報通信技術協会（TTA）標準化資料室：https://www.tta.or.kr
- TPC-Cベンチマーク（tpmC）公式サイト：https://www.tpc.org/tpcc/
- SPEC（Standard Performance Evaluation Corporation）：https://www.spec.org
一言まとめ: TTAK.KO-10.0292/R3は業務量分析→方式選定→補正適用→算出・検証の手順でHW容量をtpmCなど標準性能指標に基づき客観算定する指針であり、要求性能 = 基準量 × ピーク率 × 余裕率 ÷ 単位性能の論理で過大・過小算定を防ぎ公共事業の監理根拠を提供し、クラウド・FinOps時代には初期容量算定を超え弾力確保と継続的コスト最適化の基準線へその役割が再定義される。