ISMSにおける容量・能力の管理とは？具体例や実践手順とメリットをわかりやすく解説！
- 【監修者】金光壮太(ISOトラストのコンサルタント)
- 4月2日
- 読了時間: 10分
▼ 目次
1. はじめに
1.1. 本記事の目的と想定読者
ISMS（Information Security Management System）では、可用性（システムを止めない、サービスを継続する）が大切な要素の一つです。その中で、容量・能力の管理はシステムや人的リソースの過不足を見極め、ダウンタイムや業務停止を防ぐために不可欠な取り組みとなります。
この記事の目的
ISMS（ISO27001）で取り組む容量・能力の管理の基本概念と重要性をわかりやすく解説
具体的なステップ（現状把握、需要予測、監視、内部監査など）や実務対策ポイントを紹介
他社事例やコンサル経験から、形骸化を防ぎ、本来の可用性確保とコスト最適化を実現するヒントを提供
想定読者
これからISMS認証を取ろうと考えている企業の担当者・管理者
容量不足やシステム障害に不安を感じ、可用性を強化したいIT部門の方
「リソースを増強すればいいの？」と悩む経営者・役員→ 計画的に取り組みたい人
1.2. “容量・能力の管理”とは？ISMSで重要な理由
容量・能力の管理: サーバーやネットワーク、人的リソースなどの“限界”を把握し、過不足を防ぐこと。
可用性の確保: ISMS三要素（機密性・完全性・可用性）のうち、システムがダウンしないよう適切にリソースを維持するために必須。
コンサル視点: この管理を怠ると、アクセス集中時や障害発生時に大きな被害が出て、認証審査でも指摘を受けやすい。
1.3. 本記事で得られるメリット
ISMSで容量・能力を管理すべき理由が明確化
リスクや失敗事例を踏まえた具体的実践手順（現状把握、需要予測、モニタリングなど）
コンサル経験や他社事例を学び、可用性強化とコスト最適化の両立を実現
2. 容量・能力の管理がISMSで求められる背景
2.1. ISO27001における可用性要件との関係
可用性（Availability）: システムが止まらず継続稼働し、必要なときに情報にアクセスできる状態
容量・能力の管理: リソース不足や過剰投資による無駄を防ぐだけでなく、必要なときに必要な性能を確保→ 組織全体のセキュリティリスクを下げる
コンサル経験: 容量不足でシステムがしょっちゅうダウンしている企業は、ISMS審査でも可用性対策が不十分とされ、指摘を受けやすい
2.2. 業務継続（BCP）とリソース確保
BCP（事業継続計画）: 災害や障害が起きても事業を止めないための計画
リソース（容量・能力）: BCP達成には、最低限のサーバー性能や人員配置が必須
他社事例（製造業A社）: 自然災害で拠点が停止→ 代替サイトも容量不足で混乱→ 事前にキャパシティを増やしておけば被害が少なかった
2.3. 初心者が陥りがちな誤解
「容量管理＝サーバーを高性能にすればOK」と思いがち
運用ルールや人員体制（夜間の監視、障害対応要員など）も含めて考えないと、結局ダウンタイムが発生
コンサル視点: 技術的対策だけでなく、運用プロセスと人的要素を一体的に考えるのがISMS流
3. 容量・能力の管理で想定されるリスクと失敗事例
3.1. リソース不足によるサービス停止リスク
例: 急なアクセス集中でCPU・メモリ不足→ システムが応答しなくなる
具体例: IT企業B社でキャンペーン開始時のトラフィックを甘く見積→ サーバーがダウンし顧客離脱
対策: 需要予測＋ 定期監視＋ アラート閾値設定
3.2. 過剰投資でコスト増大
危険: 必要以上の高額サーバーや回線を契約→ 実際には使用率が低く、資金を圧迫
コンサルTIP: “リスクが怖いから最大容量を買う”という極端な判断はROIを下げがち→ 過去データと将来計画をもとに最適化
3.3. 管理ルール不備で運用ミス
事例（サービス業C社）: アラートが出ても誰が対処すべきかわからず放置→ ディスク満杯でデータ破損
教訓: 運用フローを定義し、監視ツールの通知を受けたら誰が何時間以内に対応するか決めておく
4. ISMSで押さえるべき「容量・能力の管理」の具体ステップ
4.1. 現状把握と使用量の測定
アセット（資産）の洗い出し: サーバー、ネットワーク機器、クラウドリソース、人員体制など
使用状況の可視化: CPU利用率・メモリ使用量・ディスク使用量・回線帯域などを定期モニタリング
コンサル視点: 過去6〜12か月のログをグラフ化し、ピーク負荷の傾向を把握→ 適正なベースラインを設定
4.2. 将来需要の予測とキャパシティ計画
需要予測: 新サービス開始や取引先増など、業務量増加を考慮→ いつリソースが逼迫するか見積もる
キャパシティ計画書: リソース増強のタイミング、クラウドスケーリングなど具体的な計画をまとめ、経営層の承認を得る
他社事例（製造業A社）: 3年先までの生産拡大を想定しサーバーを段階的に拡張→ コスト最適化とダウンタイム防止両立
4.3. 継続的モニタリングと警告閾値設定
監視ツール活用: ZabbixやNagios、クラウドのモニタリング機能などでリアルタイム監視
閾値設定: CPU80%超でメール通知、ディスク90%超で管理者アラート発動 など
メリット: 事前警告により緊急対策が可能→ ダウンを回避できる
4.4. 運用ルール・内部監査・レビュー
運用ルール: 閾値を超えたら何時間以内に誰が対応？ 増強手順や臨時予算承認フロー などを明文化
内部監査: “監視記録をきちんと管理しているか？” “アラートを放置してないか？”を定期チェック
マネジメントレビュー: 経営層が年1回程度モニタリング結果を確認し、次年度の投資や対策を決定
5. 導入メリット：どんな効果が得られるか
5.1. ダウンタイム・インシデントの大幅減少
事例（IT企業B社）: リソース不足による障害が80%減少→ カスタマーサポートの負荷も激減
効果: 障害対応コストが下がり、サービス品質も向上→ 顧客満足度UP
5.2. コスト最適化と無駄な投資の防止
過剰投資を回避: 本当に必要なリソース量を分析し、段階的に拡張→ ROIを高める
クラウド活用: 需要ピークだけリソースを拡張し、平常時は抑える→ 経営的にもメリット大
他社事例（サービス業C社）: 以前は最大規模のサーバーを保有しコストが膨大→ クラウドスケーリングで半分以下のコストに
5.3. 顧客満足度向上と業務効率UP
安定稼働: ダウンしにくいシステムは信頼度が高く、ユーザー離脱や顧客クレームが減る
従業員の負担軽減: 24時間体制の障害対応が少なくなり、他の業務に集中できる
コンサル視点: 形だけでなく“継続的な容量監視”が回っている企業ほど、審査でも“実効性が高い”と評価される
6. 成功・失敗事例：容量・能力の管理がもたらした結果
6.1. 成功事例：製造業A社がランサムウェア被害を未然に防ぐ
背景: 生産系システムが古いままで、負荷が高いと動作が遅くなるリスク
対策: ISMS導入でリソース監視を強化し、設備更新とピーク時間帯に余裕を持たせる
成果: ランサムウェア侵入の試みがあったが、監視ツールが早期警戒→ 被害ゼロ＆連続稼働を維持
6.2. 失敗事例：IT企業B社がアクセス集中を予想せずダウン
原因: 新キャンペーン開始日に想定以上のアクセス殺到→ サーバー負荷オーバーでサービス停止
結果: SNSで批判拡散、顧客離脱が相次ぎ収益ダウン
学び: イベント前に需要予測し、クラウドスケーリングや一時的な増強を計画しておくべきだった
7. Q&A：ISMSの容量・能力管理に関する疑問解消
7.1. 「コストがかかりすぎないか？」
回答: 適切なキャパシティ計画はコスト最適化にもつながる。過剰投資や無駄が防げ、障害による損失も減る
TIP: クラウドの弾力性を活用したり、オンプレとのハイブリッドで必要分だけ増強
7.2. 「内部監査では何をチェックすればいい？」
回答: 監視ログの保管状況、閾値やアラート対応フローが守られているか、設備増強の記録など
コンサル例: サーベイランス審査で“容量監視レポートはあるが、誰も見ていない”と指摘された例が多い
7.3. 「小規模企業にも必要？」
回答: 規模問わずシステムはダウンする可能性あり、小規模ほど1回の停止が致命的→ 必要最低限の監視や計画は必須
他社事例: スタートアップでもクラウドで柔軟に対応し、大きな障害を回避
7.4. 「クラウド導入ですべて解決する？」
回答: 自動スケーリング機能は便利だが、設定誤りやコスト急増リスクも→ 適切な監視と閾値設定が必須
経験談: 繁忙期だけスケールアウト、平常時は縮小し経費削減している企業が多い
8. 失敗事例と回避策
8.1. 設備更新を後回しにし大規模障害
原因: リソースが限界近い報告を放置→ 費用がかかるからと投資を拒否
回避策: 定期レビューで“更新スケジュール”を明記し、優先度高い部分からアップデート
8.2. 経営層の理解不足で“形だけのISMS”
原因: コストを嫌って最低限のサーバーだけ用意→ 負荷ピーク時にしばしば障害
回避策: インシデント被害額や機会損失を可視化し、容量・能力の管理が投資対効果に優れると説明
8.3. 監視アラートを誰も見ずトラブル拡大
原因: ツールが導入されても担当不在、マニュアル不備
回避策: アラート受信担当とエスカレーションフローを決め、研修で定着→ 内部監査で定期チェック
9. 他社事例：容量・能力の管理で効果を上げた企業
9.1. 製造業A社：3年計画で安定稼働＆審査高評価
背景: 主要ラインが24時間稼働。少しのダウンでも大損失
やり方: 過去1年の負荷データを分析→ 3年間の増強スケジュールを策定→ 年1回レビュー
成果: ダウンタイムほぼゼロ＆コストが予想範囲内で推移。ISMS審査でも“継続的改善が機能”と評価
9.2. IT企業B社：クラウドスケールでコスト最適化
対策: 需要のピーク時だけリソースを拡張、自動スケーリング設定＋ 監視閾値
メリット: キャンペーン時にもダウンせず、平常時はリソースを抑えてコスト削減
コンサルTIP: 過剰スケールでコスト暴走しないよう、アラートも兼ね備える
10. まとめ：ISMSにおける容量・能力の管理とは？具体例や実践手順とメリットをわかりやすく解説！
10.1. 記事の総括：ポイントの再確認
容量・能力の管理: システムや人員のリソースが不足・過剰にならないよう計画し、継続的に監視・改善すること
リスクと失敗事例: リソース不足でダウン、過剰投資でコスト浪費、警告放置でトラブル拡大など
具体的ステップ: (1)現状把握→ (2)将来需要予測→ (3)監視と閾値設定→ (4)内部監査・レビュー
導入メリット: ダウンタイム削減、コスト最適化、顧客満足度UP、ISMS審査での高評価
形骸化防止: 経営層の理解とPDCAが重要。技術面だけでなく運用・人的面を含めた総合アプローチが成功の鍵
10.2. 次のアクション：初心者が取り組むべきステップ
使用状況のログ収集: 過去6〜12か月の負荷データを把握し、ピーク負荷を明確化
需要予測と計画: ビジネス成長や季節イベントを考慮し、中長期のキャパシティ計画を立てる
運用ルール定義: 閾値超過時の担当者対応フロー、内部監査時のチェック項目を策定
内部監査で継続確認: ログ・アラートの運用実績をレビューし、改善サイクルを回す
審査対応: この実践をISMS審査時に示し、可用性管理が適切に機能していると証明
あとがき
ISMS（ISO27001）を導入するうえで、容量・能力の管理は“可用性”を担保する重要なテーマです。過負荷やリソース不足で起きる障害は、情報漏えいとは別種のセキュリティリスクとなり、業務停止や信用失墜を招きかねません。本記事の具体ステップ（現状把握→ 需要予測→ 閾値設定・監視→ PDCA）を活用し、形骸化せずに容量・能力を計画的に管理すれば、ダウンタイム大幅削減、コスト最適化、顧客満足度向上など、多大なメリットが得られます。経営層の理解と部署連携を大切に、持続的に改善していくISMS運用をめざしてください。
この記事の監修者情報
金光壮太 (ISOコンサルタント)
大手商社にて営業を経験した後、ISOコンサルティングに従事。ISO9001、14001、27001を中心に、各業界の課題や特性に応じたシステム構築や運用支援を行い、企業の業務効率化や信頼性向上に貢献。製造業や建設業など、多岐にわたる業界での豊富な経験を活かし、お客様のニーズに応じた柔軟なソリューションの提案を得意としている
Comentários