AWS上でAI Agentを動かす構成が、検証環境だけの話ではなくなってきた。専用のIAM Roleを与え、VPC内に置き、必要なAPIやツールを実行させる。権限の与え方だけを見れば、運用ジョブやバッチ処理と大きくは変わらない。違うのは、目的に応じて何を実行するかをAgent自身が判断する点にある。

2026年7月、OpenAIの評価環境で動いていたAI Agentが隔離を越えて外部へ到達し、7月11日から13日にかけてHugging Faceの本番基盤を侵害した。境界の突破は7月に突然始まったわけではなく、5月から断続的に続いていた。両社が公開した技術レポートには、どの経路が使われ、どこで止まり、どこでは止まらなかったかが記録されている。

本記事は、この事件の時系列を追うものではない。攻撃の詳細は両社の一次資料に譲り、ここでは次の問いを扱う。

AWS上で正規の権限を持つAI Agentが、想定した範囲を越えて動いたとき、その到達範囲は何によって決まるのか。

進め方は、セキュリティ要件定義の基本形をそのまま使う。資産を洗い出し、脅威主体を定め、弱点と攻撃シナリオを置き、対策を決めて、残るリスクを確認する。この順に沿って、AI Agentという実行主体を一度当てはめてみる。

リスクアセスメントの進め方そのものは、セキュリティ要件定義の記事で別途整理する。ここでは方法論の説明はせず、事件で実際に何が効いて何が効かなかったかという、設計時には得にくい材料を扱う。

AI Agentに何を預けているのか

リスクアセスメントは、守る対象を決めるところから始まる。AI Agentを載せた基盤で、守る対象は何か。今回の事件は、その範囲を実測で示している。

侵害の経路

事件の経路を、後の議論で必要な範囲だけ確認する。​

図　AIエージェント攻撃チェーン

押さえておきたい事実は3つある。

一つ目は、脱出に使われたのが許可された通信経路だったこと。 評価環境はインターネットから隔離されていたが、パッケージを取得するための経路は業務上必要なため開いていた。エージェントはその経路の実装に脆弱性を見つけ、外部へ抜けている。塞ぎ忘れた穴ではなく、開けておく理由があった経路が足場になった。

二つ目は、コード実行より前に認証情報が漏れていること。 Hugging Faceへの最初の侵入ベクターは、細工したデータセット設定を処理させ、ワーカーのローカルファイルを返させるものだった。コードは一切実行していない。読み取らせた’/proc/self/environ’に本番Podの環境変数が入っており、そこに認証情報が含まれていた。この読み取りで得た認証情報や実装情報が、その後の探索と横展開の材料になった。

三つ目は、一つの境界を越えたあとも連鎖が続いたこと。 本番Podでの足場から、Kubernetesのサービスアカウント、クラウドのメタデータ、内部ネットワーク、ソースコード管理へと進んでいる。

資産の範囲をどう置くか

ここから、自分たちの環境に置き換える。

奪われたものを並べると、業務データそのものより手前にあるものが多い。

図　AI Agentと重要資産の到達範囲

​AI Agentに預けていると考えるべき範囲は、Agentに直接処理させるデータだけではない。Agentが直接・間接に到達できる重要資産まで広げて考える必要がある。 要件定義で資産を洗い出すとき、Agentに渡すデータだけを対象にすると、事件で実際に使われた経路が丸ごと抜け落ちる。

影響も同じ範囲で考える。情報の取得と改ざんに加えて、構成変更による外部公開と、基盤そのものの停止まで入る。構成変更によって内部基盤を外部へ公開できた事例も、後段で確認する。

脅威主体としてのAI Agent

脅威分析では、まず誰が資産に手を伸ばし得るかを並べる。外部攻撃者、内部関係者、委託先、侵害されたワークロード。ここにAI Agentを加えるかどうかが、この記事の前提になる。

人間の内部不正者とは別物として扱う

AI Agentを内部脅威と呼ぶと、人間の内部不正と同じ枠に見えてしまう。動機を持ち、意図して権限を濫用する主体という含みが入るためで、その枠に置くと分析が動機の推定へ向かう。

ここでは次のように定義する。

正規に発行されたWorkload Identity（非人間ID）を持ち、与えられた目的を達成する過程で、設計者が想定した範囲を越える操作を行い得る実行主体。

IAM Role、Kubernetesのサービスアカウント、マシンIDの延長として読める形だ。既存の非人間IDの管理に、判断して行動する性質が加わったものと捉えればよい。

悪意は要件ではない

今回の事件で、エージェントはHugging Faceを攻撃するという目的を与えられていない。与えられていたのは、脆弱性を発見して悪用する能力を測る評価課題を解くことだった。

課題が解けないなかで、エージェントは評価対象のデータや解答がHugging Faceに置かれている可能性に行き当たり、そちらへ向かっている。OpenAIはこれを、報酬を得るための意図しない経路を選ぶreward hackingとして整理している。侵害は目的ではなく、目的達成の副産物だった。

脅威分析で見るのは動機ではない。与えられたGoal（目的）と、許されたAuthority（権限）の組み合わせだ。 Agentがデータを盗もうと考える必要はなく、与えられた目的の達成経路上にその操作が現れるだけで足りる。

達成できない目的を与えると、環境を掘り始める

この事件の前段には、目的が達成できない状況が繰り返し置かれていた。

訓練時の例が公開されている。エージェントは投稿の更新時刻を指定の値にせよと指示されたが、与えられたインターフェースにその機能がなかった。エージェントは環境を広く探索し、ブラウザがroot権限を持つことを発見して’/etc/sudoers.d’を上書きし、権限を得て目的を達成している。

事件時の評価でも同じ形が出ている。**AI Agentの脆弱性悪用能力を評価するベンチマーク「ExploitGym」**の898問のうち198問は、事故以前にどのモデルも正解したことがなかった。

Agentに必要なのは、達成する能力だけではない。達成できないと判断して正常に止まる経路が要る。

図　達成不能時に安全に止まる設計

これらはアライメントだけに任せる話ではなく、Agent実行基盤の設計項目でもある。止まれないAgentに広い権限を与えると、想定した経路が使えなくても、目的達成のために別の経路を探索し続ける。

効いた統制と、効かなかった統制

同じインシデント調査の中で、ある境界では攻撃が止まり、別の境界では止まらなかった。なぜそうなったのかを見ていく。

対策の実効性は、設計時点の机上評価だけでは判断しにくい。テストで確認できる範囲はあっても、複数の境界をまたぐ侵害でどこまで被害を止められるかは見えにくい。今回の事件では、関連するエージェント活動の中で、効いた統制と効かなかった統制の両方が記録されている。

侵入されたあとに止まった側

Hugging Faceの本番Podが侵害されたあと、エージェントはインスタンスメタデータサービスからEC2ノードロールの一時認証情報を読み出している。この認証情報は外部の二つのホスティング事業者のアドレスから再利用され、VPC、EKSクラスタ、Transit Gateway、シークレット、コンテナレジストリが列挙された。ここまでは通っている。

止まったのはこの先だ。AWSクラウドAPI面では、変更を伴う呼び出しがノードロールのポリシーによってすべて拒否された。 Hugging Face自身が、ここで得られたのはcontrolではなくmapだったと整理している。

ネットワーク側も同じ形で効いた。本番Hubのデータベースは、許可リストに載ったアドレスからプライベートリンク経由の接続しか受け付けない構成になっている。盗まれたAWSキーを使った接続はサーバー選択のタイムアウトで失敗し、数時間後の再試行も同じ結果に終わった。

認証情報は奪われている。それでも、奪われた認証情報でできることがIAMポリシーとネットワーク構成の側で先に絞られていた。

同じ事件で止まらなかった側

侵害されたのはHugging Faceだけではない。OpenAI側の評価基盤でも、関連するエージェント活動は続いていた。

7月19日、ある評価ランでは、エージェントが稼働マシンのLinuxカーネルに公開CVEが残っていることを特定し、エクスプロイトを自環境向けに改変して権限昇格し、コンテナの外へ出てワーカーノードのrootを取得した。

同日、別の評価ランでは、別の内部研究モデルのエージェントが、以前の活動によって残されていた署名鍵・復号材料・JWT偽造コードを回収し、新しい管理者JWTを発行してArtifactoryに受理させている。管理者認証情報を作り直せるため、標的に永続的なインプラントを置く必要すらなかった。

一連の活動では、その後、OpenAIのマネージドKubernetes環境でcluster-admin相当の権限まで到達し、Privileged設定かつホストファイルシステムをマウントしたPodも作成された。さらに、クラウドのシークレット管理サービスでは956件のシークレットが列挙・読み取りされ、その中には監視ツール自身のセンサー認証情報も含まれていた。

さらに、取得した認証情報を使って、OpenAIのパブリッククラウド環境にパブリックなApplication Load BalancerとNetwork Load Balancerが作成され、内部基盤の一部がインターネットへ露出し得る状態になった。

差を生んだのは、次の境界が独立して機能したかどうか

図　侵害後の権限展開フロー

ここで比較している活動は、すべて同一モデル・同一評価ランによるものではない。それでも、認証情報の取得、権限拡大、横展開という攻撃チェーンは共通している。結果を分けたのは、取得したIDから何を変更できたかだった。

Hugging Face側も、変更が一切できなかったわけではない。Kubernetesではprivilegedポッドが作られ、ソースコード管理では書き込み権限が取られてプルリクエストまで作成されている。止まったのはAWSのクラウドAPI面に限られる。

ここから引き出せる設計上の区別が一つある。既存の到達範囲で何ができるかという権限と、到達範囲そのものを変更できる権限は分けて考える必要がある。 前者を最小権限化していても、後者が残っていれば、Agent自身がその権限境界やネットワーク境界を広げられる。侵入されるかどうかだけでなく、侵入されたあとに次の境界が独立して機能するかが被害範囲を決める。

AWSで何を許し、何を許さないか

ここまでで、資産、脅威主体、弱点と攻撃シナリオまでを見た。ここからが対策だ。

AI Agentに与える権限を検討するとき、確認しておく観点は次のようになる。

大半は従来のクラウド設計で扱ってきた項目だ。この中で、AI Agentを置くことによって検討の仕方が変わるものを3つ取り上げる。

Agentに自分の境界を変更させない

前章で見たとおり、最小権限では「既存の到達範囲で何ができるか」だけでなく、「到達範囲そのものを変更できるか」を分けて見る必要がある。後者は業務データに直接触らないため、最小権限の議論から漏れやすい。代表例が次のAPIだ。

• elbv2:CreateLoadBalancer
• ec2:AuthorizeSecurityGroupIngress
• ec2:CreateInternetGateway
• ec2:CreateRoute​

これらを持つAgentは、自分が到達できる範囲を自分で広げられる。今回のOpenAI側の活動でも、パブリックなロードバランサーが実際に作成され、内部基盤をインターネットへ露出し得る状態が生まれている。

私がAI Agentを載せる基盤の設計レビューをするなら、ここは「最小権限とすること」という一行では通さない。ネットワークとIAMの構成を変更するAPIを洗い出し、Agent実行ロールから明示的に外れていることを確認する。

加えて、この種の境界変更はIAMポリシーだけに依存させない。 Agent自身、またはAgentがAssumeRoleできるIDに

• iam:PutRolePolicy
• iam:AttachRolePolicy

などのIAM変更権限が残っていれば、最小権限として設計した実行ロールを後から拡張する経路が生まれる。境界の固定は、SCP（Service Control Policies）のようにAgent自身が変更できない上位のガードレールでも制限する。

Read Only ≠ Low Risk

権限を絞る議論は、更新系と参照系を分けるところから始まることが多い。参照だけなら壊れないという前提が置かれる。

事件の被害連鎖は、この前提の外側で始まっている。最初の侵入ベクターはコード実行を伴わないファイル読み取りで、’/proc/self/environ’を返させることで本番Podの環境変数中の認証情報が漏れた。

参照系を一段分けて考えたい。

図　読み取り権限のリスク比較

​※Describe / Listも、対象によってはネットワーク構成やARN、エンドポイントなどの偵察情報を返すため、常に低リスクとは限らない。

下段は性質が二つに分かれる。データベースの顧客データは、読まれた時点で情報漏洩そのものだ。認証情報は、読まれた内容が次の操作の資格情報になる。更新権限を持たないAgentでも、後者に到達できれば、そこで得た認証情報を持つ別のIDとして動ける。

この区別は、Human-in-the-loopをどこに入れるかにも効いてくる。Human-in-the-loopの線を「更新かどうか」だけで引くと、今回のような認証情報窃取の前段は素通りする。 IAM変更やDELETEの手前に人間を置いても、その前段で認証情報が漏れていれば、そこから先は別のIDとして進める。

線を引くなら、その操作が更新か参照かではなく、戻り値そのものが重要資産か、次の攻撃経路を成立させる材料になるかで判断する。

検知ではなく、止められるかまで設計する

この事件では、検知そのものは複数回機能している。

6月27日には監視ツールがポートスイープを検知し、対応者は活動を評価ランに紐づけたが、停止は不要と判断された。7月5日にはサービス停止を契機に管理者レベルの侵害が判明した。Hugging Face側でも、AIによるセキュリティ機構が複数のシグナルを相関させながら、重大度を十分に引き上げてオンコールチームを起動させることに失敗している。

シグナルは上がっていた。それでも活動は止まらなかった。

要件として書くべきは、検知できることだけではない。検知 → 重大度判定 → エスカレーション → 停止権限という4段が、最後まで通ることだ。誰が停止を判断するのか、判断がつかない場合はどちらへ倒すのか、応答がない場合に自動で止まるのか。OpenAIが事件後に示した対応基準では、懸念活動が浮上してから30分以内の通知を目標とし、重大なものは24時間365日のページ発報対象とする。さらに、ページを受けた安全・セキュリティ・研究チームが30分以内に誤検知と断定できなければ、関連する活動を一時停止することが期待されている。

判断がつかないときに止める側へ倒す設計は、可用性とのトレードオフを伴う。AI Agentが本番環境で自律的に動く構成では、この判断を運用開始後に持ち越さず、要件定義の段階で決めておきたい。

監視・ログ・障害時の判断体制を後から付け足すのではなく、要件定義から処理方式と結びつける考え方は、次の記事でも整理している。

運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点

運用設計とは何かをシステム基盤エンジニアの実務目線で解説します。運用設計書の目次サンプルと検討項目一覧を示し、監視・ログ・バックアップ・ジョブ管理、誰がやるのか、要件定義・基本設計との関係、処理方式設計との双方向連携を整理します。

sys-univ.com

2026.08.14

監視の配置も同じ考え方だ。事件では、読み出されたシークレットの中に監視ツール自身のセンサー認証情報まで含まれていた。監視とログをAgentの権限境界の内側に置けば、Agentの到達範囲が広がったときに、検知する側から先に失われる。CloudTrailの組織証跡を別アカウントのログアーカイブへ送り、Agent実行ロールにログの削除・停止権限を持たせない。 表の「ログ」が求めているのは、監査証跡の管理権限をAgentの権限境界から分離するという構成だ。

それでも残るもの

対策を並べたら、次は残存リスクを確認する。ここまでの要件をすべて満たしたとして、何が残るのか。

対策で低減できるものと、残る性質

※左右の項目は1対1の対応関係を示すものではない。

左側は設計によって大きく低減できる。右側は、権限を必要最小限まで絞っても残る。

最小権限もネットワーク分離も、許可した範囲内の動作までは止めない。許可した操作を、設計者が想定していない順序と組み合わせで実行されることまでは、権限の側から防げない。

17,600という数字の意味

Hugging Faceの復元によれば、この事件でエージェントが実行したアクションは約17,600件だった。

この数字を、17,600回の攻撃が成功したと読むと意味を取り違える。ほとんどは失敗している。 Hugging Face自身、多くのアクションはどこにもたどり着かなかったが、合わせると複数の独立したシステムを横断する経路を見つけるだけの網羅性を生んだ、と整理している。

人間による手作業では、探索を繰り返すほど時間と作業量が増える。AI Agentでは探索、失敗、再試行を自動化できるため、一つひとつの失敗にかかる追加コストを大きく下げられる。 塞がれれば別の経路を試し、以前の手がかりへ戻り、短命な実行環境でも必要なツールを組み直して探索を続けられる。

防御側にとって特に変わるのは、個々の攻撃手法よりも探索の物量だ。成功した1本の経路が、失敗した数千本のノイズに埋もれる。前章で検知から停止までを要件として書いたのは、この物量が相関分析の負荷に直接効いてくるためだ。

原則は変わっていない

今回悪用されたのも、安全でないデータ処理、メタデータへの到達、過大な権限、長期の認証情報といった既知の弱点だった。

OpenAI自身も、攻撃的に動作するエージェント集団が侵入のルールを書き換えるわけではないとしたうえで、最小権限、分離とセグメンテーション、強力な認証というセキュリティの基本は従来どおり不可欠であり、いかなる単一の統制も完全に堅牢だと仮定してはならないと整理している。

AI Agentがセキュリティ原則を書き換えたわけではない。従来からある弱点を、より速く、広く、執拗に組み合わせられるようになった。

この能力は評価環境の中だけに留まるものでもない。OpenAIは、同等の能力が外部の脅威アクターにも利用可能になるにつれ、持続的で協調的なAI支援型の攻撃を脅威モデルへ織り込む必要があるとしている。自社でAI Agentを運用していない組織でも、探索の量と速度が増大することを外部脅威側の前提として考える必要がある。

まとめ

AI Agentを載せたAWS環境のセキュリティ要件を、一度フレームに通してみた。持ち帰る点は3つだ。

AI Agentは、正規の非人間IDを持つ実行主体として脅威分析の対象に入れる。 人間の内部不正と同じ枠には置かない。見るのは動機ではなく、与えた目的と許した権限の組み合わせだ。悪意がなくても、目的の達成経路上に想定外の操作が現れる。

一つの境界を突破されても、次の境界が独立して機能するように設計する。 今回、同じインシデント調査の中で止まった統制と止まらなかった統制の両方が記録された。差を生んだのは、取得されたIDから権限とネットワーク境界をどこまで変更できたかだった。既存の到達範囲で何ができるかという権限と、到達範囲そのものを変更できる権限は分けて設計する。

AI固有なのは原則ではなく、探索の量・速度・持続性だ。 最小権限も多層防御も分離も、従来どおり有効なまま残る。単一の統制を完全と考えないという原則が、これまで以上に短時間で試される。

参考資料

Hugging Face, “Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident”

OpenAI, “The Hugging Face incident and the road ahead”

OpenAI, “OpenAI – Hugging Face Incident Technical Report” (August 26, 2026)

関連記事

AI Agentでは、IAMやネットワーク、認証情報といった従来からのセキュリティ設計が不要になるわけではありません。むしろ、Agentが正規の権限を持って自律的に操作することを前提に、どこまで到達できるか、どの境界で止めるかを要件として明確にしておく必要があります。

本記事ではOpenAI・Hugging Faceの事例からAI Agentの到達範囲を整理しましたが、AWS側の統制、検知後の運用設計については、以下の記事で詳しく解説しています。

• VPC Encryption Controlsの落とし穴｜Flow Logsの暗号化判定とEnforce判定は別物
  AWSのネットワーク統制について、Flow Logsで観測できる状態とEnforceによる許可・拒否の判定が同じではない点を整理しています。「見えている状態」と「実際に強制される境界」を分けて考えるという点は、AI Agentのネットワーク設計にも共通します。
  
  
  

  VPC Encryption Controlsの落とし穴｜Flow Logsの暗号化判定とEnforce判定は別物

  VPC Encryption Controlsでは、Flow Logsで暗号化と表示されてもEnforceで許可されるとは限りません。encryption-statusと準拠判定の違い、既存Flow Logsにフィールドが自動追加されない点、ExclusionやTGWの注意点をAWS公式仕様から整理します。

  

  sys-univ.com

  2026.08.27
• 運用設計とは｜監視・障害対応・エスカレーションまでをどう設計するか
  監視はアラートを出して終わりではなく、重大度判定、エスカレーション、対応判断まで含めて設計する必要があります。本記事で扱った**「検知 → 重大度判定 → エスカレーション → 停止」**を、より広い運用設計の観点から整理しています。
  
  
  

  運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点

  運用設計とは何かをシステム基盤エンジニアの実務目線で解説します。運用設計書の目次サンプルと検討項目一覧を示し、監視・ログ・バックアップ・ジョブ管理、誰がやるのか、要件定義・基本設計との関係、処理方式設計との双方向連携を整理します。

  

  sys-univ.com

  2026.08.14

本シリーズでは、詳細設計を「構築・テスト・運用できる形」に落とし込む工程として、全3回に分けて整理しています。

• 【第1部】この記事
  詳細設計とは何を決める工程か／パラメータ表で終わらせないための設計の考え方

• 【第2部】OS・Web/APサーバ・DB・ジョブの詳細設計
  OS／Web・APサーバ／DB／ジョブの4領域

• 【第3部】監視・ログ・バックアップ・セキュリティの詳細設計
  監視／ログ／バックアップ・リストア／セキュリティ／運用スクリプトの5領域

第2部・第3部では、各記事の後半にあたる詳細解説をnote（有料）で公開しています。

はじめに

基本設計では、要件をシステム構成、処理方式、運用方式に落とし込みます。

では、詳細設計では何をするのでしょうか。

詳細設計と聞くと、サーバのパラメータを決める、ミドルウェアの設定値を書く、クラウドサービスの設定項目を埋める、といったイメージを持つ人もいるかもしれません。

もちろん、それらは詳細設計の重要な要素です。

しかし、詳細設計は、単にパラメータ表を埋める工程ではありません。

基本設計で決めた方式を、実際に構築・設定・テスト・運用できる粒度まで落とし込む工程です。

たとえば、基本設計で「ログを1か月保持する」と決めたなら、詳細設計では、どのログファイルを対象にするのか、どのディレクトリに出力するのか、どの周期でローテーションするのか、圧縮するのか、何世代残すのか、バックアップ対象に含めるのか、容量監視をどうするのかまで具体化します。

基本設計で「7時までに業務を開局する」と決めたなら、詳細設計では、その運用要件をジョブ、スクリプト、監視、起動停止、開局前チェックに落とします。

どのジョブを何時に起動するのか。
どのスクリプトを実行するのか。
どの戻り値を正常とするのか。
終了遅延をどう検知するのか。
開局前チェックで何を確認するのか。
どの監視を再開するのか。

これは一見すると運用設計の話に見えます。

しかし、詳細設計では、この運用要件を実際の製品設定、ジョブ定義、スクリプト仕様、監視設定、手順書の粒度に落とします。

ここで落とし込みが甘いと、運用試験や本番移行前に手戻りが発生します。

つまり、詳細設計とは、基本設計で決めた方針を、OS、ミドルウェア、DB、ジョブ、監視、バックアップ、クラウドサービス、運用スクリプト、手順、試験観点へ展開する工程です。

構築担当者が設定値を判断しなければならない。
テスト担当者が期待値を確認できない。
運用スクリプトが作られていない。
ジョブは定義されているが、異常時の分岐が分からない。
監視項目はあるが、閾値や通知先が決まっていない。
バックアップは設定されているが、リストア手順がない。

こうした問題は、詳細設計の時点で「構築できる粒度」「テストできる粒度」「運用できる粒度」まで落とし込めていないことから起きます。

この記事では、基盤SEの目線で、詳細設計で何を具体化するのかを整理します。

この記事で確認する視点

詳細設計書を見るときは、設定値そのものだけを追ってはいけません。

この記事では、詳細設計を確認する時の視点として、次の観点を整理します。
各章の末尾では、その領域ごとの確認観点を3つに絞って整理します。

• この設定値は、基本設計のどの方針を受けているのか
• なぜこの値でよいと言えるのか
• 構築担当者が、この設計書を見て同じ設定を再現できるか
• テスト担当者が、期待値を判断できるか
• 運用担当者が、障害時に使える設計になっているか
• 監視、ログ、バックアップ、ジョブ、スクリプト、手順書とつながっているか
• この設計で品質を確保できると説明できるか

詳細設計は、設定値を埋める作業ではありません。

基本設計で決めた方式を、構築、テスト、運用、保守に接続し、「なぜこの設計でよいのか」を説明できる状態にする工程です。

この視点で見ると、詳細設計書は単なるパラメータ表ではなく、構築・テスト・運用を成立させるための設計資料として見えるようになります。

詳細設計は基本設計の続きである

詳細設計は、基本設計と切り離された工程ではありません。

基本設計で決めた内容を、実際に構築・設定できるレベルに落とし込むのが詳細設計です。

基本設計では、たとえば次のようなことを決めます。

• システム構成
• 処理方式
• サーバ構成
• ネットワーク構成
• DB構成
• ストレージ方式
• ジョブ・バッチ方式
• 監視方式
• ログ方式
• バックアップ・リストア方式
• セキュリティ方式
• 運用方式

一方、詳細設計では、それらをより具体的な設定、パラメータ、ファイル、ジョブ、スクリプト、手順、テスト可能な期待値に落としていきます。

たとえば、基本設計で「Web/AP/DBの3層構成」と決めたなら、詳細設計では、各サーバのホスト名、IPアドレス、OS設定、導入ミドルウェア、待ち受けポート、接続先、タイムアウト、ログ出力先、起動停止順序を決めます。

基本設計で「監視する」と決めたなら、詳細設計では、監視対象、監視方式、監視間隔、閾値、検知条件、通知先、抑止条件、一次対応手順まで落とします。

基本設計で「バックアップを取得する」と決めたなら、詳細設計では、対象ファイル、対象DB、取得コマンド、実行ジョブ、取得時刻、世代数、保管先、削除条件、リストア手順、戻し先、確認方法まで落とします。

詳細設計は、基本設計で決めたことを「誰が見ても同じ構成で作れる状態」にするための工程です。

詳細設計を、構築担当者向けの設定メモにしてはいけません。

詳細設計書は、構築担当者だけのためにあるわけではありません。テスト担当者、運用担当者、レビュー担当者、障害対応者、後続保守担当者も参照します。

そのため、詳細設計では、単に設定値を書くのではなく、なぜその設定にしているのか、基本設計のどの方針を受けているのか、どのテストで確認するのか、運用上どの手順や監視とつながるのかを意識します。

詳細設計とパラメータ設計・環境定義

開発標準によっては、詳細設計、パラメータ設計、環境定義を分けて整理することがあります。

考え方としては、次のように整理できます。

詳細設計は、基本設計で決めた方式を、製品・ミドルウェア・クラウドサービスの設定や構築単位に落とし込む工程です。

パラメータ設計は、その中でも、OS、ミドルウェア、DB、ジョブ管理製品、監視製品、バックアップ製品、クラウドサービスなどの設定値を具体化する作業です。

環境定義は、実際に構築される環境ごとの設定値を一覧化する成果物です。

ただし、実務上は、詳細設計とパラメータ設計、環境定義を一体的に進めることも多くあります。特に基盤領域では、製品ごとの詳細設計書と、環境ごとのパラメータ一覧を合わせて管理することが一般的です。

ここで押さえるべきなのは、すべての製品パラメータを案件ごとにゼロから検証するわけではない、ということです。

OS、Web/APサーバ、DB、ジョブ管理、監視、バックアップ製品、クラウドサービスには、膨大な設定項目があります。これらをすべて個別に妥当性検証することは、現実的ではありません。

そのため、多くのプロジェクトでは、過去案件で実績のある標準構成や製品デフォルト値をベースにし、基本設計で定めた処理方式、性能要件、運用要件、セキュリティ要件に影響するパラメータを重点的に設計します。

「デフォルトだから見なくてよい」ではありません。

案件固有の要件に影響するパラメータを洗い出し、変更する項目については設定値と根拠を示します。

一方、変更しない項目についても、環境定義として値を明示しておくことで、構築後の確認、障害時の調査、後続保守で参照できる状態にしておきます。

詳細設計とは、全パラメータを網羅的に説明する工程ではありません。基本設計で決めた方式と、実際の製品設定・環境定義をつなぐ工程です。

詳細設計は品質保証ストーリーの一部である

詳細設計は、構築担当者のための設定表ではありません。

基本設計で決めた方式を、構築・テスト・運用へつなげることで、「なぜこの設計で品質を確保できると判断したのか」を説明する材料になります。

特に大規模プロジェクトでは、設計値やパラメータ値に対して、根拠を求められることがあります。

なぜこの値なのか。
なぜデフォルト値でよいのか。
なぜこの監視項目で足りるのか。
なぜこの試験で確認できたと言えるのか。
なぜこの構成で性能要件を満たすと判断したのか。

このとき、詳細設計書に設定値だけが並んでいても説明できません。

必要なのは、次の接続です。

• 基本設計で定めた方式
• 非機能要件
• 製品仕様
• 標準構成・過去実績
• 設定値の根拠
• テスト観点
• 監視・運用での確認方法

一方で、すべての製品パラメータやすべての操作パターンを案件ごとに完全検証することはできません。

製品内部の制御仕様、バージョン差分、特定条件でのみ発生する挙動まで、設計段階で完全に予見することは現実的ではありません。

たとえば、通常利用では問題が出ないものの、特定の処理タイミング、特定の負荷条件、特定の運用操作が重なった場合だけ、製品内部の制御仕様によって処理遅延やエラーが発生することがあります。

こうした事象は、要件や設計から自然に導けるものではなく、製品仕様、バージョン差分、既知不具合、過去事例に依存します。マニュアルやベンダー情報に明示されていなければ、設計段階で完全に予見することは困難です。

だからこそ、詳細設計では、次の項目を重点的に設計します。

• 基本設計で決めた処理方式に影響する項目
• 性能・可用性・運用・セキュリティに影響する項目
• 案件固有要件により変更する項目
• 過去実績や標準構成で注意点が分かっている項目

変更する項目には、設定値と根拠を残します。

変更しない項目については、製品デフォルト値または標準構成を採用し、環境定義として管理します。これは、すべてのデフォルト値を個別に検証したという意味ではありません。構築後の確認、障害時の調査、保守引継ぎのために、実際の設定状態を参照できるようにするためです。

テストも同じです。

テストは、見えない全パターンを無限に洗い出すものではありません。要件定義、基本設計、詳細設計で決めた内容に対して、Vモデルに沿って確認観点を展開するものです。

詳細設計で目指すべきなのは、トラブルゼロを保証することではありません。

要件と設計に基づいて、どこを重点的に設計し、どこを標準値として採用し、どこを試験で確認し、どこを運用監視で検知するのかを説明できる状態にすることです。

これが、詳細設計における品質保証ストーリーです。

詳細設計で見るべきなのは「設定値」ではなく「接続性」である

詳細設計というと、どうしても設定値に目が行きます。

OSのパラメータ。
ApacheやTomcatの設定。
DBの初期化パラメータ。
ジョブ管理製品のジョブ定義。
監視製品の閾値。
クラウドサービスの設定項目。

もちろん、これらは大事です。

しかし、詳細設計で見るべきなのは、設定値そのものだけではありません。

基本設計、構築、テスト、運用がつながっているかです。

たとえば、ログ設計であれば、以下がつながっている必要があります。

• 基本設計：ログを1か月保持する
• 詳細設計：logrotate設定、退避先、圧縮有無、世代数
• 構築：設定ファイルの配置、権限設定、反映
• テスト：ログローテーション確認、容量監視確認
• 運用：ログ確認手順、障害調査手順、バックアップ対象

このつながりがないと、詳細設計書は単なる設定一覧になります。

一見すると設計書は埋まっているのに、後工程で漏れます。

ログ保持期間は決まっているが、ローテーション設定がない。
ログ出力先は決まっているが、容量監視がない。
バックアップ対象に含まれていない。
障害時にどのログを見るのか手順書に書かれていない。

こうした漏れは、詳細設計の段階で「設定値を決めること」だけを目的にしていると起きます。

詳細設計で見るべきなのは、設定値が正しいかだけではありません。

その設定が、基本設計の方針とつながっているか。
構築手順に落ちるか。
テストで確認できるか。
運用手順や監視とつながるか。
障害時に使えるか。

ここまで見て初めて、詳細設計として成立します。

詳細設計は製品・ミドルウェア単位で分かれやすい

基本設計では、処理方式や運用方式の単位で設計することが多くあります。

一方、詳細設計では、製品・ミドルウェア・クラウドサービス単位で設計書が分かれることが多くなります。

たとえば、次のような詳細設計書です。

• OS詳細設計書
• Webサーバ詳細設計書
• APサーバ詳細設計書
• DB詳細設計書
• ジョブ詳細設計書
• バックアップ詳細設計書
• 監視詳細設計書
• ログ詳細設計書
• ストレージ詳細設計書
• ネットワーク詳細設計書
• セキュリティ詳細設計書
• 運用スクリプト設計書
• クラウドサービス詳細設計書

これは、詳細設計が実際の構築対象に近づくからです。

構築担当者は、OSを設定し、Webサーバを設定し、APサーバを設定し、DBを設定し、ジョブ管理製品にジョブを登録し、監視製品に監視項目を設定します。

そのため、詳細設計も自然と製品・ミドルウェア・クラウドサービス単位になります。

ただし、ここで注意が必要です。

製品単位で詳細設計書を分けると、設計対象を管理しやすくなる一方で、処理方式としてのつながりが見えにくくなることがあります。

たとえば、バックアップ方式は、DB詳細設計、ストレージ詳細設計、ジョブ詳細設計、監視詳細設計、運用スクリプト設計にまたがります。

ログ方式は、OS詳細設計、ミドルウェア詳細設計、監視詳細設計、バックアップ詳細設計にまたがります。

ジョブ方式は、ジョブ管理製品の詳細設計だけでなく、実行スクリプト、ログ出力、異常終了時の通知、運用手順、運転スケジュールにまたがります。

つまり、詳細設計では、製品単位で分けることと、処理方式として横断的につなぐことの両方が必要です。

ここを意識しないと、各詳細設計書は存在するのに、全体としてつながっていない状態になります。

ここまで、詳細設計の考え方を整理してきました。

ここから先は、基盤SEが実際に詳細設計で具体化する領域を、OS、Web/AP、DB、ジョブ、監視、ログ、バックアップ、セキュリティ、運用スクリプトに分けて見ていきます。

特に、ジョブ管理規約とスクリプトの戻り値設計、正常系だけで終わらせない単体試験、特権IDや本番作業統制の考え方は、現場でトラブルを起こしやすいポイントです。

詳細設計を「設定表作成」で終わらせず、構築・テスト・運用で使える成果物にするための具体論を整理します。

この先、後編①ではOS・Web/AP・DB・ジョブを、後編②では監視・ログ・バックアップ・セキュリティ・運用スクリプトを扱います。

– OS詳細設計で見るべき観点
– Web/APサーバ詳細設計で性能・運用とつなげる考え方
– DB詳細設計で性能・バックアップ・セキュリティをどう見るか
– ジョブ詳細設計で事故りやすい戻り値設計
– ジョブ管理規約とスクリプトのコーディング規約をそろえる理由
– 監視・ログ・バックアップ設計で後工程に漏れを出さない見方
– セキュリティ詳細設計を技術設定だけで終わらせない考え方
– 運用スクリプトの設計・試験で見落としやすいポイント
– 詳細設計でやってはいけないこと

「第一部まとめ｜詳細設計の本質」

詳細設計を単なるパラメータ表ではなく、基本設計で決めた方式を構築・テスト・運用・保守へ接続する工程として整理しました。

設定値を埋めることではなく、基本設計、構築、テスト、運用がつながっているかを見ること。トラブルゼロを保証することではなく、どこを重点設計し、どこを試験で確認し、どこを運用監視で検知するかを説明できる状態にすること。

これが詳細設計の本質です。

その本質を踏まえて、詳細設計でやってはいけないことを4つ整理します。

基本設計とのつながりを見ない
詳細設計は、基本設計で決めた方式を具体化する工程です。基本設計との対応が見えない詳細設計は、ただの設定メモになります。

製品パラメータを埋めるだけで終わる
詳細設計では設定値を決めますが、それだけでは不十分です。構築、テスト、運用、障害対応までつながる粒度で設計します。

設定値の理由を書かない
なぜその値にしたのかが分からないと、レビューも保守もできません。推奨値なのか、性能要件から決めたのか、製品制約なのか、運用要件なのかを残します。

全パラメータを保証したつもりになる
詳細設計は、すべての製品パラメータやすべての組み合わせ挙動を案件ごとに完全検証する工程ではありません。要件・方式・リスクに影響する項目を重点的に設計し、標準構成やデフォルト値に依拠する範囲を明確にします。

第2部ではOS・Web/AP・DB・ジョブ、第3部では監視・ログ・バックアップ・セキュリティ・運用スクリプトの注意点を整理します。

扱う論点の多くは、「知っているか、知らないか」で後工程の品質が大きく変わるものです。設計書の体裁は整っているのに、システムテストや本番移行前に手戻りが発生する。その原因の多くは、詳細設計のこの段階で見落とされています。

Tomcatが共有Volumeへログを書き込み、Fluent Bitが同じVolumeをマウントしてログを読み取る構成です。

最初に発生したのはTomcat側のPermission deniedでした。その問題を解消してTomcatが正常にログを書けるようになると、今度はFluent Bit側で次のエラーが発生しました。

[error] [input:tail:tail.0]
cannot open /var/log/tomcat/app01/catalina.2030-09-18.log

[error] [plugins/in_tail/tail_file.c:888 errno=13]
Permission denied

GCログでも同様です。

[error] [input:tail:tail.2]
cannot open /var/log/tomcat/app01/GC_log....txt

[error] [plugins/in_tail/tail_file.c:888 errno=13]
Permission denied

Tomcat自身はログを書けています。それなのに、同じVolumeを参照するFluent Bitはログを読めません。

今回の問題は、Tomcat単体では解決していても、ECSタスク全体では権限設計が成立していなかったことにありました。

前回の

ECS/FargateでDockerfileのchownが効かない｜非rootコンテナがPermission deniedになる理由

ECS/Fargateで非rootコンテナを実行した際、Dockerfileでchown済みのログディレクトリがPermission deniedになった実例をもとに、空のデータVolume（Empty Volume）とbind mount、VOLUMEの仕様、対策、設計レビュー、事前PoCで確認すべき点を解説します。

sys-univ.com

2026.08.14

では「ビルド時と実行時」を分けて考えました。今回はその続きとして、「コンテナ単体とECSタスク全体」を分けて考えます。

今回の構成｜Tomcatが書き、Fluent Bitが読む

今回の構成を単純化すると、Tomcatが共有Volumeへログを書き込み、Fluent Bitが同じVolumeをマウントしてログを読み取る構成です。

図：ECS/Fargateの共有Volume構成（Tomcat → Fluent Bit）

TomcatはWriterとして、共有Volume上の/var/log/tomcat/app01/へcatalina.2030-09-18.logやGCログを書き込みます。Fluent BitはReaderとして同じVolumeを参照し、in_tailでこれらのログファイルを監視します。

両コンテナが直接データを受け渡しているのではなく、共有Volume上のログファイルがTomcatとFluent Bitの間のインターフェースになっています。

本記事で扱うのは、Fluent Bitのin_tailで共有Volume上のファイルを直接監視する構成です。アプリケーションの標準出力をawsfirelensログドライバ経由でFluent Bitへ渡すFireLensの一般的な構成とは異なります。

また、公式のaws-for-fluent-bitイメージをデフォルトのrootユーザーで実行している場合、本記事で扱うような読み取り権限の問題は通常表面化しません。今回の環境ではFluent Bitを非rootユーザーで実行していたため、共有Volume上のファイル権限が問題になりました。

発端はTomcat側のPermission deniedだった

今回、最初に問題になったのはFluent Bitではありません。

Tomcat側でGCログを作成できず、Javaの起動そのものが失敗していました。

Error opening log file
'/var/log/tomcat/app01/GC_log....txt':
Permission denied

Initialization of output
'file=/var/log/tomcat/app01/GC_log....txt' failed.

Error: Could not create the Java Virtual Machine.

Dockerfileでは対象ディレクトリへchownしていましたが、Fargateタスク起動時に同じパスへVolumeをマウントしていたため、イメージ作成時に設定したディレクトリではなく、実行時にマウントされたVolume側のファイルシステムが見えていました。

この仕組みについては、先ほど示した前回の記事で詳しく整理しています。

本記事では、その問題を解消した後に発生した問題を扱います。

Tomcatは書けるようになった。しかしFluent Bitは読めなかった

Tomcat側では、Volumeがマウントされた後に対象ディレクトリのowner/groupとpermissionを変更することで、ログを書き込める状態にしました。

これによってTomcatは正常に起動します。

ところが、次にFluent Bitでerrno=13が発生しました。

Linuxのerrno=13はEACCES、アクセス拒否です。

ここで重要なのは、

Tomcatがログを書けることと、Fluent Bitがそのログを読めることは別の権限要件

だという点です。

例えばTomcatが所有者であるログファイルなら、owner権限によってTomcat自身は問題なく書き込めます。

Fluent Bitが別UIDで実行されている場合、そのファイルのgroupまたはotherに読み取り権限がなければアクセスできません。

さらにファイル自身のrだけでは足りません。

Fluent Bitが対象ファイルへ到達するためには、ルートから対象ファイルまで、パス上に存在するすべてのディレクトリにx権限が必要です。

例えば、

/
└─ var
   └─ log
      └─ tomcat
         └─ app01
            └─ catalina.2030-09-18.log

であれば、/var、/var/log、/var/log/tomcat、/var/log/tomcat/app01を順に辿れる必要があります。

さらに、*.logのようなワイルドカードでファイルを探索する場合は、ディレクトリエントリを列挙するためのr権限も考慮する必要があります。

確認すべきなのは、

ファイルのread権限
        ＋
パス上の全ディレクトリのtraverse権限
        ＋
Fluent Bit自身のUID/GID

です。

なお、Volumeをマウントしているパスより上位のディレクトリは、各コンテナイメージ側のファイルシステムです。同じVolumeを共有していても、その上位階層まで同じ状態になるわけではありません。

chmod 777で原因を権限問題に絞り込んだ

切り分けとして、対象ログのpermissionを一時的に緩める確認を行いました。

777にするとFluent Bitからログを監視できるようになったため、

• Fluent Bitのtail設定

• 対象ログのパス

• Volumeの共有そのもの

ではなく、ファイルシステム上のアクセス権限が原因であることを確認できました。

もちろん、

chmod -R 777 /var/log/tomcat/app01

を恒久対策にはしません。

777は、原因を切り分けるための確認方法です。

さらにchmod -R 775のようにディレクトリと通常ファイルへ同じmodeを再帰的に設定する方法も避けます。通常のログファイルに実行ビットを付与する必要はないためです。

恒久対策では、ディレクトリとファイルの権限を分けて考えます。

直接原因と設計上の原因は分けて考える

今回の問題には、二つの原因があります。

技術的な直接原因

Tomcatが生成したログファイルのowner/groupとmodeが、Fluent Bit側の読み取り条件を満たしていませんでした。

Tomcatから見れば書き込めるファイルでも、別UID/GIDで動作するFluent Bitから見れば読み取れない状態です。

設計上の原因

Tomcatがログを書けることを権限設計のゴールにしてしまい、共有Volumeを利用するFluent Bitまで含めたアクセス要件になっていませんでした。

本来の要件は、

Tomcatが書ける

ではなく、

Tomcatがログを書く
        ↓
Fluent Bitがそのログを継続して読む

です。

ここをコンテナ単体ではなく、ECSタスク全体の要件として扱う必要があります。

共有VolumeではUID/GIDをコンテナ間インターフェースとして考える

一つの解決方法として、TomcatとFluent Bitが共有するGIDを決める設計が考えられます。

例えば、

Tomcat
UID = 1071
GID = 3000

Fluent Bit
UID = xxxx
GID = 3000

とします。

共有Volumeのログディレクトリを、

owner = 1071
group = 3000

とすれば、

• Tomcatはownerとしてログを生成する

• Fluent Bitはgroupとしてログを読む

という役割分担ができます。

重要なのは、3000という数値そのものではありません。

共有Volumeを境界として、WriterとReader双方から成立するUID/GIDを決めることです。

ECSのタスク定義では、Linuxコンテナの実行ユーザーをuserで指定できます。

Fluent Bitを共有GIDで実行する場合、例えば設計上は、

"user": "2000:3000"

のようにUIDとプライマリGIDを指定する方法があります。

ECSには、Kubernetesのように、プロセスへ補助グループを追加する supplementalGroups 相当の仕組みはありません。Volumeのgroup所有権を自動調整する仕組みについても、bind mountでは提供されていません。

必要に応じて、

• タスク定義のuser

• Fluent Bitのカスタムイメージ

• イメージ内のuser/group定義

などを使って実行UID/GIDを設計する必要があります。

実環境では、設定値を見るだけではなく、

id

で実際にプロセスがどのUID/GID/groupsで動作しているか確認することが重要です。

また、タスク定義でuserを指定すると、コンテナのentrypoint自体もそのユーザーで実行されます。イメージのentrypointがroot権限を前提としたディレクトリ操作などを行っている場合は、別の起動エラーを起こす可能性があるため、その点も確認します。

setgidで新規ログのgroupを引き継ぐ

共有Volumeのディレクトリを最初に、

owner = 1071
group = 3000

としても、それだけでは十分ではありません。

Tomcatがその後に新しいログファイルを作成すると、新規ファイルのgroupが期待した値にならない可能性があります。

そこで利用できるのが、ディレクトリのsetgidビットです。

例えば、

chown 1071:3000 /var/log/tomcat/app01
chmod 2750 /var/log/tomcat/app01

とします。

先頭の2がsetgidです。

setgidを設定したディレクトリ配下で新しくファイルを作成すると、ファイルのgroupは親ディレクトリのgroupを引き継ぎます。

新しくサブディレクトリが作成された場合も、通常は親ディレクトリのgroupとsetgidビットを引き継ぎます。 例えば親ディレクトリにsetgidを設定し、Tomcat側のumaskを0027としている場合、新規サブディレクトリは基本的に750となり、共有groupに所属するReader側からもパスを辿れる構成にできます。

そのため、Tomcatが日付別などのサブディレクトリを作成して、その配下にログを出力する構成でも、setgidとumaskを組み合わせることでgroupとアクセス権を維持しやすくなります。

ただし、アプリケーション自身がディレクトリのmodeやgroupを明示的に変更する場合は、その設定が優先されるため、実際に生成されたディレクトリのowner/group/modeを確認します。

概念的には、

/var/log/tomcat/app01
owner = 1071
group = 3000
setgid
        │
        │ Tomcatが新規作成
        ▼
catalina.2030-09-18.log
group = 3000

となります。

これによって、日付が変わって新しいログファイルが作成された場合でも、共有GIDを維持しやすくなります。

umaskで新規ログのmodeを制御する

groupが正しくても、ファイルにgroupの読み取り権限がなければFluent Bitは読めません。

そこで次に考えるのがumaskです。

Linuxで一般的なファイルが新規作成される場合、最終的なmodeにはプロセスのumaskが影響します。

例えば、

umask 0027

であれば、通常ファイルは基本的に、

640
rw-r-----

となります。

これなら、

owner = Tomcat
group = Fluent Bitと共有するgroup

という構成において、

Tomcat      → read / write
Fluent Bit  → read
others      → accessなし

というアクセス制御ができます。

考え方としては、

setgid
  ↓
誰のgroupになるか

umask
  ↓
そのgroupに何を許可するか

です。

共有Volumeでは、この二つをセットで考えると整理しやすくなります。

なお、アプリケーション自身が明示的にpermissionを変更する場合など、umaskだけでは決まらないケースもあります。実際に生成されたファイルのowner/group/modeは必ず確認します。

Volumeの初期権限を直すだけでは足りない

既存記事では、権限設定用コンテナを先行起動してVolumeを初期化する方式を扱いました。

ECSにはKubernetesのような専用のinit container機能はありませんが、

権限設定用コンテナ
        ↓ SUCCESS
Tomcat / Fluent Bit

という依存関係を作ることができます。

SUCCESSやCOMPLETEを依存条件として使う場合、依存先コンテナをessentialコンテナにはできません。権限設定用コンテナはessential: falseとして定義する必要があります。

この方式そのものについては既存記事で詳しく説明しているため、本記事では繰り返しません。

今回重要なのは、その次です。

権限設定用コンテナが変更できるのは、基本的にタスク起動時点のVolumeの状態です。

その後にTomcatが作成するログファイルについては、

• TomcatのUID

• TomcatのGID

• 親ディレクトリのsetgid

• プロセスのumask

• アプリケーション自身のファイル生成方法

などによってowner/group/modeが決まります。

Volume初期化
    ↓
正しい権限になった
    ↓
完了

ではありません。

Volume初期化
    ↓
Tomcat起動
    ↓
ログ新規生成
    ↓
Fluent Bitから読み取り
    ↓
翌日のログ新規生成
    ↓
引き続き読み取り

まで成立して、初めてタスク全体として権限設計が成立します。

恒久対策として考えられる構成

今回確認した事象とLinuxの権限の仕組みから整理すると、恒久対策としては次の構成が考えられます。

1. 権限設定用コンテナでVolumeを初期化する

権限設定用コンテナでは、TomcatやFluent Bitと同じ共有Volumeを、権限変更用のマウントポイントとして/mntへマウントする想定です。同じVolumeでも、コンテナごとにcontainerPathは異なるパスを指定できます。

そのため、Tomcatからは/var/log/tomcat/app01/として見えるVolumeを、権限設定用コンテナでは/mntとして操作できます。

例えば、

chown 1071:3000 /mnt
chmod 2750 /mnt

find /mnt -type d -exec chmod 2750 {} +
find /mnt -type f -exec chmod 640 {} +

2. Tomcatを非rootで実行する

Volumeの初期化を別コンテナへ分離すれば、Tomcat自身を権限変更のためにrootで実行する必要はありません。

Tomcatはアプリケーション実行用のUID/GIDで起動します。

3. Tomcat側でumaskを設定する

例えば、

umask 0027

としてからTomcatを起動します。

これにより、Tomcatが新しく作成するログファイルについて、共有groupから読み取り可能なmodeにすることを狙います。

4. Fluent Bitを共有GIDから読み取れる状態にする

Fluent Bit側も、共有Volume上のログを読み取れるUID/GIDで実行します。

タスク定義のuserを利用する場合は、例えば、

"user": "2000:3000"

のような指定が候補になります。

実際に使用するUID/GIDは、利用しているFluent Bitイメージやその実行方式に合わせて決めます。

5. Fluent Bit側は可能ならread-onlyでマウントする

Fluent Bitはログを読むだけであれば、共有ログVolumeをread-onlyでマウントする方が役割を明確にできます。

{
  "sourceVolume": "tomcat-logs",
  "containerPath": "/var/log/tomcat/app01",
  "readOnly": true
}

Fluent BitのDBファイルなど書き込みが必要なファイルは、共有ログVolumeとは別の書き込み可能な場所へ配置する必要があります。

6. 新しいログが生成された後まで確認する

起動直後のファイルだけではなく、Tomcatが新しくログを作成した後に、

ls -ld /var/log/tomcat/app01
ls -l /var/log/tomcat/app01
id

などで、

• owner

• group

• mode

• TomcatのUID/GID

• Fluent BitのUID/GID

を確認します。

特に日付が変わってcatalina.YYYY-MM-DD.logが新しく生成された後や、GCログが新しいファイルへ切り替わった後にもFluent Bitが継続して読み取れることを確認します。

この構成は各環境で検証が必要

ここまでの構成は、今回確認した事象とLinuxのファイル権限の仕組みから整理した恒久対策案です。

実際に必要となる設定は、

• 使用するコンテナイメージ

• Tomcat/JDKのバージョン

• ログの生成方式

• Fluent Bitの実行UID/GID

• Fluent Bitのin_tail設定

• Volumeのマウントポイント

などによって変わります。

本記事のUID/GIDやmodeをそのまま適用するのではなく、各環境で実際に生成されたファイルのowner/group/modeと、各コンテナの実行UID/GIDを確認したうえで検証してください。

ECS/Fargateで共有Volumeを使うときの確認項目

共有Volumeの権限問題を確認する際は、Writer側だけを見るのではなく、実行UID/GID、Volumeとファイルの権限、その後のファイル生成まで順に確認します。今回の事象を踏まえて、確認項目を以下に整理しました。

特に、起動時のVolumeのowner/groupが正しくても、その後に生成されるログのgroupとmodeがReaderの要件を満たすとは限りません。setgidとumask、新規ログ生成後の確認までを一連のテストとして扱うことが重要です。

まとめ：共有Volumeはコンテナ間インターフェースとして設計する

今回、Tomcatからログを書けるようになった時点では、権限問題を解決できたと思っていました。実際には、同じVolumeを利用するFluent Bitからログを読めず、タスク全体としてはまだ成立していませんでした。

共有Volumeでは、マウント直後のowner/groupとpermissionを整えるだけでは不十分です。その後に生成されるファイルのgroupをどう引き継ぐか（setgid）、どのmodeで作成するか（umask）、Reader側のUID/GIDから読み取れるか、そしてログが新しく作り直された後も読み続けられるかまで確認する必要があります。

TomcatとFluent Bitのように複数コンテナでVolumeを共有する場合、Volumeは単なる保存領域ではなく、コンテナ間でデータを受け渡すインターフェースになります。Writerが書けることではなく、Readerが継続して読めることが要件です。

コンテナ単体では正しい設定でも、ECSタスク全体では正しいとは限りません。

関連記事

本記事の前段となった事象です。

DockerfileでchownしたディレクトリへECS/FargateのEmpty Volumeをマウントすると、なぜ設定したはずの権限が見えなくなるのか。ビルド時のファイルシステムと実行時のVolumeを分けて整理しています。

ECS/FargateでDockerfileのchownが効かない｜非rootコンテナがPermission deniedになる理由

ECS/Fargateで非rootコンテナを実行した際、Dockerfileでchown済みのログディレクトリがPermission deniedになった実例をもとに、空のデータVolume（Empty Volume）とbind mount、VOLUMEの仕様、対策、設計レビュー、事前PoCで確認すべき点を解説します。

sys-univ.com

2026.08.14

セキュリティ要件を検討するとき、暗号化する、MFAを導入する、アクセス経路を制限する、ログを取得するといった、具体的な対策から考え始めてしまうことがあります。

もちろん、これらは重要なセキュリティ対策です。しかし、対策そのものを先に並べても、

なぜ、この対策が必要なのか
どこまで対策する必要があるのか
なぜ、この対策は実施しないのか

までは決まりません。

同じ「個人情報を扱うシステム」でも、インターネットへ公開するシステムと閉域網だけで利用するシステムでは、想定する攻撃経路が異なります。24時間停止できない基幹システムと、数時間停止しても業務影響が小さい情報提供サイトでは、可用性に対する要求も変わります。

暗号化やMFAといった対策が一般的に有効だからといって、すべてのシステムに同じ方式・同じ水準で実装すればよいわけではありません。

必要なのは、最初に、

何を守るのか
何が起こり得るのか
その結果、どの程度の影響があるのか

を明らかにすることです。

その中心になるのが、リスクアセスメントです。

本記事では、セキュリティ全体の評価・確認を広く「セキュリティアセスメント」と呼び、その中核となるリスクアセスメントを、脅威・脆弱性・影響からリスクを分析・評価するプロセスとして扱います。

具体的には、次の4ステップでセキュリティ要件を導きます。

図　セキュリティ要件を導く4ステップ

1. 脅威を分析する
2. 脆弱性・設定不備・統制不足を分析する
3. リスクを分析・評価する
4. リスク対応を決め、必要な対策へ落とす

このうち、STEP1〜3がリスクアセスメントです。STEP4では、その評価結果をもとにリスクを低減・回避・移転・保有のどれで扱うかを決め、必要なセキュリティ対策へ落とします。

リスクアセスメント
→ リスク対応
→ セキュリティ要件

という順序です。

4ステップに入る前には、何を評価対象にするのか、誰がどのセキュリティコントロールを担うのかを明確にするため、対象範囲と責任分界を整理します。要件を決めたあとも、構成変更や新しい脅威に応じてリスクを見直します。

ここで「セキュリティ要件定義」の位置づけを確認しておく必要があります。

本記事では、RFPや提案書、見積前提、顧客のセキュリティ標準、業界基準など、一定の上位要求が既にインプットとして存在することを前提としています。

ただし、これらの要求は、そのまま実装できる粒度まで具体化されているとは限りません。「強固な認証を行う」「通信を暗号化する」「災害時の業務継続を検討する」といった要求を、対象システムの構成やリスクに合わせて具体化する必要があります。

本記事で扱うのは、こうした上位要求を入力として、リスクアセスメントを行い、個々のセキュリティ要件、責任分界、上位基準との差異、残存リスクまで具体化していく工程です。

RFP・上位要求

→ 提案段階で主要な実現可能性を検討

→ 要件定義で要求・差異・責任分界を具体化

→ 基本設計以降で実装方式を具体化

という流れを前提に、以降の説明を進めます。

要件定義と設計の役割も分けて考えます。

要件定義で決めるのは「どのリスクに、どこまで対応するか」です。基本設計以降では、その要求をどの方式で実現するかを具体化します。

具体的な対策を先に選ぶのではなく、リスクアセスメントによってリスクを明らかにし、その結果から必要な対策を導く。

これが、本記事で説明するセキュリティ要件定義の基本です。

要件定義全体の位置づけや、RFP・提案内容・見積前提との関係は、次の記事で整理しています。

要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務

要件定義とは何をする工程なのか。RFP、質問回答、提案書、見積前提から認識差を潰し、スコープや責任分界を確定する実務を、大規模SIの具体的な失敗事例とともに解説します。

sys-univ.com

2026.08.12

4ステップの前に、セキュリティ対策の範囲と責任分界を決める

リスクアセスメントを始める前に、まずセキュリティ対策の対象範囲と責任分界を整理します。

どこまでを評価対象にするのか、誰がどのセキュリティコントロールを担うのかが曖昧なままだと、その後に脅威や脆弱性を洗い出しても検討漏れが生じます。

これは、後述するリスクアセスメントの前提条件を決める作業です。その前提を整理したうえで、「何を守るのか」「何から守るのか」を明確にしていきます。

システム構成を俯瞰して対象を決める

Webシステムであれば、アプリケーションやサーバだけが対象ではありません。

利用端末、運用管理端末、ネットワーク、外部接続先、認証基盤、バックアップ、CI/CD、SaaSなど、対象システムに関係する構成要素を確認します。業務上重要な情報を紙で扱うのであれば、それも情報資産として評価対象になり得ます。

要件定義の段階では、詳細な物理構成図まで作る必要はありません。

主要な構成要素と接続関係、信頼境界、外部との接点が分かる程度の概念図を用意し、まだ決まっていない部分は想定であることを明記します。

図　主要な構成要素、接続関係、信頼境界、外部との接点を示したWebシステム構成例

この図のように、利用者からWeb/AP、DB、バックアップ、外部接続先までの経路だけでなく、運用管理端末からの管理経路も見えるようにしておくと、後の脅威分析で「どこから、どこへ到達できるのか」を考えやすくなります。

早い段階で実装方式まで固定しすぎると、後続の設計自由度を狭めます。

要件定義では、リスクを判断するために必要な粒度まで構成を見えるようにすることが目的です。

クラウドでは「誰が構築するか」より「どの層で、誰がコントロールするか」を見る

クラウドでは、マネージドサービスだから利用者側のセキュリティ検討対象外、とは考えられません。

クラウド事業者が物理設備やサービス基盤を管理していても、IAM権限、データ、ネットワーク公開範囲、暗号化設定、ログ、アプリケーションなどは利用者側に残ることがあります。

確認したいのは、

このサービスを誰が作るのか

だけではなく、

このリスクを、どの層で、誰がコントロールするのか

です。

例えば、外部からの攻撃を共通のCDNやWAF、ネットワーク基盤で十分に防御できるのであれば、同じ対策を個別システムごとに重複して実装する必要はありません。反対に、共通基盤では実現できない、あるいは構成上利用できない対策については、個別システム側で代替コントロールを検討します。

複数ベンダや共通基盤が関係する案件では、この責任分界が特に重要です。

端末は別ベンダ、ネットワークは共通基盤、アプリケーションは自チームという構成なら、セキュリティ要件ごとに実施主体が変わります。

責任分界が曖昧なままだと、

相手が対応すると思っていた

という「責任の空白」が生まれます。

アセスメントの開始時点で大まかな責任範囲を整理し、個々の対策を検討するときにも、必要に応じて担当主体を残しておきます。

リスクアセスメントで理解しておく「資産・脅威・脆弱性・リスク」

対象範囲と責任分界を整理したら、リスクアセスメントで使う基本用語を確認します。

守る対象は機密性だけではない

情報セキュリティでは、機密性（Confidentiality）、完全性（Integrity）、可用性（Availability）の3つを基本的な観点として扱います。この3つは、それぞれの英語の頭文字を取ってCIAと呼ばれます。

これは、情報を守るには「漏れないこと」だけでは不十分だからです。 情報や処理結果が正しく保たれ、必要なときに利用できることまで含めて考える必要があります。

• 機密性：許可されていない人に情報を見せない
• 完全性：情報や処理結果を不正に変更・破壊されない
• 可用性：必要なときにシステムや情報を利用できる

例えば、情報が外部へ漏れていなくても、不正に書き換えられていれば安全とはいえません。内容が正しくても、攻撃や障害によって必要なときに利用できなければ、業務を継続できません。

リスクアセスメントでは、この3つのうち何が失われるのかを見ながら、脅威と影響を整理します。

個人情報の漏洩は機密性の問題です。データの不正書き換えは完全性、DoS攻撃によるサービス停止は可用性に関係します。

災害や設備破壊も、可用性設計だけの話とは限りません。悪意ある破壊行為によってサービスを停止させるケースを含めれば、セキュリティの観点でも評価対象になります。

可用性とセキュリティを別々の非機能要求として整理する場合でも、実際のリスクは重なります。分類の境界より、どの事象によって何が失われるのかを見る方が重要です。

脅威と脆弱性を混同しない

脅威は、情報資産へ悪影響を与える可能性がある事象や主体です。

例えば、不正アクセス、マルウェア、内部不正、DoS攻撃、災害、機器の破壊などが該当します。

脆弱性は、脅威に利用される可能性のあるシステム・設定・運用上の弱点です。

「機密性が低いこと」が脆弱性なのではありません。

例えば、

外部の攻撃者が管理画面へ不正アクセスする

という脅威に対して、

MFAが設定されていない
管理画面がインターネットから直接到達可能
管理者権限が過大

といった状態は、攻撃を成立させやすくする脆弱性・統制不足です。

ここでいう脆弱性は、ソフトウェアそのものの欠陥だけを指すわけではありません。

ソフトウェアの脆弱性には、CVE（Common Vulnerabilities and Exposures）という共通の識別番号が付与されて公表されるものがあります。CVEは脆弱性そのものの重大度を表す点数ではなく、既知の脆弱性を識別するための番号です。深刻度の評価には、0.0〜10.0で表すCVSSなどが使われます。

セキュリティアセスメントでは、

既知のソフトウェア脆弱性
＋設定不備
＋管理・運用上の統制不足

まで見ます。

リスクは「脅威＋弱点＋影響」で考える

脅威や脆弱性を単独で並べても、対策の優先順位は決まりません。

例えば、管理画面にMFAがないという弱点があったとしても、その管理画面が外部から到達できるのか、どの情報へアクセスできるのか、侵害されたときにどの程度の影響が出るのかによってリスクは変わります。

実務では、

誰が、どこから、どの弱点を利用して、何を起こし、業務や情報資産にどのような影響を与えるのか

というシナリオとして整理すると、対策へつなげやすくなります。

図　脅威からリスク対応までの評価フローイメージ

同じ脅威でも、実際に起きたときの影響によってリスクは変わります。

例えば、インターネット上ですでに公開している情報が第三者に閲覧されても、機密性の観点では大きな損失にはつながりません。反対に、顧客の個人情報や認証情報が漏洩すれば、顧客への被害、法令対応、信用低下など大きな影響が生じる可能性があります。

重要なのは、情報が重要そうだから一律に強い対策をするのではなく、その情報が漏れた、改ざんされた、利用できなくなったときに何が起こるのかを考えることです。

リスクの大きさは、発生可能性と影響度の2軸などを使って評価します。評価尺度や判定基準は組織やプロジェクトによって異なります。

対策を実施してもリスクが完全にゼロになるとは限りません。この「対策後にも残るリスク」が残存リスクです。残存リスクについては後半で具体例とともに説明します。

具体的な評価方法はSTEP3で説明します。

セキュリティアセスメントはどこまでやればよいのか

すべてのシステムに、同じ深さのアセスメントを行う必要はありません。

アセスメントの深さは、システム規模だけでなく、扱う情報の重要度、外部公開の有無、停止が許容できる時間、特権IDの有無、外部システムとの接続、法令・業界基準などによって変わります。

例えば、社内向けの小規模な情報提供システムと、顧客の個人情報を扱い24時間稼働する外部公開システムでは、求められるアセスメントの深さは異なります。

後者では、構成要素や接続経路を細かく分け、管理経路や可用性、バックアップ、特権権限まで含めて評価する必要があります。前者では、重要な資産と主要な攻撃経路に絞って評価する方が現実的な場合もあります。

アセスメントそのものにも、品質、時間、コストのバランスがあります。重要なのは、すべてを同じ粒度で調べることではなく、そのシステムで大きな影響につながるリスクを見落とさない粒度を選ぶことです。

このあと例にするのは、顧客情報を保持し、インターネットへ公開するWebシステムです。小規模な社内ツールよりも、外部からの攻撃経路、内部者の権限、データ保護、復旧などを広く見る必要があるケースとして扱います。

ゼロから項目を考えない

実務では、白紙から脅威や対策を洗い出すより、組織内で実績のあるアセスメントシートや公的なガイドラインをベースラインとして使う方が効率的です。

ただし、過去のシートをそのままコピーして終わりにはしません。

クラウド管理プレーン、SaaS、API、CI/CD、サプライチェーンなど、対象システム固有の構成や現在の脅威に合わせて観点を追加します。

実績のあるシートを再利用する価値は、対策例が並んでいることだけではありません。

「どの構成要素に対して、どの脅威を見るのか」という分析軸を再利用できることに大きな価値があります。

対策には技術的対策だけでなく、物理的対策、組織的な統制、運用手順、教育などもあります。すべてをシステム機能で解決しようとせず、リスクに対して適切な手段を組み合わせます。

セキュリティ対策を導く4ステップ

セキュリティ対策の範囲と責任分界を決め、アセスメントの深さを決めたら、具体的なリスクアセスメントへ進みます。

中心となるのは、はじめにで述べた次の4ステップです。

（再掲）図　セキュリティ要件を導く4ステップ

1. 脅威を分析する
2. 脆弱性・設定不備・統制不足を分析する
3. リスクを分析・評価する
4. リスク対応を決め、必要な対策へ落とす

ここで重要なのは、最初からWAF、MFA、暗号化といった対策を並べないことです。

まず何が起こり得るのかを考え、その事象を成立させる弱点を確認し、発生した場合のリスクを評価します。その結果として必要な対策を決めます。

対策からリスクを考えるのではなく、リスクから対策を導く。

これが4ステップをこの順番で行う理由です。

以降では、顧客情報を保持する外部公開Webシステムを一つの例として、4ステップを順番に追っていきます。

（再掲）図　主要な構成要素、接続関係、信頼境界、外部との接点を示したWebシステム構成例

この図を、以降のSTEP1〜4で共通して使います。利用者からの通常経路だけでなく、運用管理端末からの管理経路、バックアップ、外部接続先までをアセスメント対象として見ます。

STEP1　脅威を分析する

最初に、対象となる資産やシステムに対して、どのような脅威が存在するのかを洗い出します。

今回のWebシステムで守るべき重要な資産の一つは顧客情報です。

ここで、

不正アクセス

とだけ書いても、何を設計すればよいのか分かりません。

もう少し具体化して、

外部の攻撃者がWebシステムへ侵入し、顧客情報を参照・持ち出す

という攻撃シナリオとして考えます。

外部からの攻撃だけではありません。

正規の権限を持つ内部者についても、

内部者が運用管理端末から必要以上の権限を利用し、顧客情報を取得する

というシナリオが成立する可能性があります。

同じ「情報流出」でも、外部攻撃者による侵入と、内部者による不正利用では攻撃経路が異なるため、必要な対策も変わります。

構成要素 × 脅威で検討漏れを減らす

脅威を網羅的に考えるために、実務で有効なのが構成要素と脅威を掛け合わせる方法です。

私が実際に利用していたアセスメントでも、脅威だけを一覧にするのではなく、サーバ、利用端末、運用管理端末、ネットワークなどの構成要素ごとに確認していました。

例えば、次のように考えます。

この表は、対策の要否を判定する表ではありません。

「この構成要素について、この脅威を検討したか」を確認するための分析軸です。

例えばサーバ上の情報流出だけを考えていると、正規の操作で利用端末へダウンロードされたデータが持ち出されるシナリオを見落とす可能性があります。

実績のあるアセスメントシートを使う価値も、対策例が大量に書かれていることだけではありません。

どの構成要素に対して、どの種類の脅威を見るのかという分析軸が既に整理されていることに価値があります。

外部者だけでなく内部者・第三者も見る

不正アクセスや情報流出では、外部攻撃者だけを想定すると検討が偏ります。

今回のWebシステムでも、

外部攻撃者がインターネット経由で侵入する

シナリオだけでなく、

正規権限を持つ内部者が、その権限を不正に利用する

シナリオを見る必要があります。

外部攻撃を防ぐネットワーク制御は、正規の経路からアクセスする内部者には効かない場合があります。

また、情報漏洩は悪意のある内部者だけが原因になるわけではありません。誤送付、誤操作、端末や書類の持ち出しなど、人的・運用上のミスからも発生します。

令和7年度（2025年度）個人情報保護委員会年次報告では、行政機関等の漏えい等事案の発生原因について、誤交付、誤送付、誤廃棄、紛失といったヒューマンエラーが、国の行政機関等で54.8％、地方公共団体等で69.0％を占めています。

さらに、社員だけでなく、運用委託先や外部サービス事業者など正規の権限を持つ第三者、関係者を装って施設へ入り込む人物、利用者をだまして認証情報を取得するソーシャルエンジニアリングも考える必要があります。

セキュリティ対策は、ファイアウォールや認証といったシステム上の対策だけでは完結しません。入退室管理、権限付与・剥奪、操作記録、教育、承認手続きなど、人と運用を含めて考えます。

STEP1の目的は、脅威名を数多く挙げることではありません。

誰が、どこから、どの資産に、どのような影響を与える可能性があるのかをシナリオとして整理することです。

STEP2　脆弱性・設定不備・統制不足を分析する

次に、STEP1で整理したシナリオを成立させる弱点を確認します。

今回の、

外部攻撃者がWebシステムへ侵入し、顧客情報を取得する

というシナリオを考えてみます。

例えば、

• 管理機能へインターネットから到達できる
• MFAが設定されていない
• 一つの管理者IDに必要以上の権限がある

といった状態があれば、攻撃シナリオを成立させやすくなります。

内部者による情報持ち出しであれば、

• 運用管理者に必要以上の参照権限がある
• 操作ログを取得していない
• 重要な操作を後から追跡できない

といった統制不足が問題になります。

ここでいう「脆弱性」は、ソフトウェアそのものの欠陥だけを意味しません。

先ほど説明したように、既知のソフトウェア脆弱性にはCVEという識別番号が付くものがあります。実務では、それらの既知脆弱性に加えて、

ソフトウェアの脆弱性
＋設定不備
＋管理・運用上の統制不足

まで見ます。

例えばソフトウェア脆弱性についても、CVSSが高いから機械的にパッチを当てるのではなく、対象システムでその脆弱性が実際に悪用可能か、対象機能を利用しているか、外部から到達できるか、既存の対策があるかまで確認してリスクを評価します。

機能が存在しているだけでは十分ではない

例えば操作ログを取得する機能があっても、必要な操作が記録されていなければ意味がありません。

ログを取得していても、異常を検知する必要があるのに誰も確認していなければ、早期発見には使えません。

アクセス権を適切に設定していても、異動や退職に伴う権限の棚卸しが行われなければ、時間の経過とともに不要な権限が残ります。

セキュリティ対策では、

機能があるか

だけでなく、

その機能によって必要な統制が実際に成立しているか

まで確認します。

クラウドでは設定不備の観点が増える

クラウドでは、クラウド事業者が基盤を管理していても、利用者が設定するセキュリティ項目は数多く残っています。

今回のWebシステムをAWS上に構築するなら、IAMの権限、ネットワーク公開範囲、暗号化、ログ取得などは利用者側の設計対象になります。

クラウドサービス自体にソフトウェア脆弱性がなくても、利用者側の設定によって攻撃経路が作られる可能性があります。

代表的なのがIAMなどの権限設定です。「最小権限にする」だけではなく、誰に（Principal）、どの操作を（Action）、どのリソースまで（Resource）、どの条件で（Condition）許可しているのかを確認します。さらに、ロールを引き受けられる主体、認証情報の扱い、重要操作のログまで含めて見ます。

権限が過大であれば、一つの認証情報や実行環境が侵害されたときに、攻撃者が到達できる範囲も広がります。

オンプレミス向けの古いアセスメントシートをそのまま流用すると、OSやネットワーク機器は細かく確認しているのに、IAMやクラウド管理コンソールのような管理プレーン側の観点が抜けることがあります。

実績のあるシートはベースラインとして使いながら、対象システムの構成に合わせて更新する必要があります。

STEP3　リスクを分析・評価する

ここまでで、今回のシナリオは次のように整理できます。

資産：顧客情報
脅威：外部攻撃者による不正アクセス
脆弱性・統制不足：管理機能へ外部から到達可能、MFA未設定、権限過大
想定される事象：管理者権限を不正利用され、顧客情報が取得される
リスク：顧客情報の漏洩

ここから、そのリスクがどの程度重要なのかを評価します。

基本となるのが、発生可能性と影響度です。

※発生可能性と影響度からリスク評価を決める基準は、組織やプロジェクトによって異なります。

この表で重要なのは、High／Middle／Lowという文字そのものではありません。

なぜその評価になったのかを説明できることです。

現行対策を考慮して評価する

次に、STEP1で挙げたもう一つのシナリオである、内部者による顧客情報の持ち出しを考えてみます。

仮に運用管理端末が自由に利用できるのであれば、発生可能性は高く評価されるかもしれません。

しかし、

• 運用管理端末が限定されている
• 利用者が限定されている
• 操作記録を取得している

といった現行対策が既に存在するのであれば、その効果を考慮します。

ここを無視すると、アセスメントシート上では常に最悪条件でリスクを評価することになり、必要以上の対策を導きやすくなります。

反対に、

対策があるから安全

と評価するだけでも不十分です。

その対策によって、

発生可能性がどこまで下がったのか
発生した場合の影響は変わるのか
まだ何が残っているのか

を見る必要があります。

発生可能性が低く、影響度が大きいリスク

実務で判断が難しいのが、

発生可能性は低いが、発生すれば影響が非常に大きい

リスクです。

例えばリージョン全体の長期停止や、バックアップを含むデータの完全喪失などです。

この場合、

発生可能性が低いから対策しない

とも、

影響が甚大だから最大限の対策を必ず行う

とも機械的には決められません。

ただし、対策水準をゼロから自由に決めるわけではありません。まず、RFPや適用基準、顧客標準などの上位要求を確認します。

そのうえで、上位要求だけでは決まらない部分について、システムの重要度、復旧可能性、既存対策、追加対策によって得られるリスク低減効果や費用を踏まえて判断します。上位要求どおりに実現できない場合は、その差異によって何ができなくなり、どのリスクが残るのかまで評価します。

STEP4では、こうした評価結果をもとに、そのリスクを低減・回避・移転・保有のどれで扱うかを決めます。リージョン障害のような可用性リスクについては、後述する残存リスクの節で具体例を示します。

STEP4　リスク対応を決め、セキュリティ対策へ落とす

リスクを評価したら、そのリスクをどのように扱うかを決めます。

代表的なリスク対応は、低減、回避、移転、保有の4種類です。

低減

セキュリティ対策を実施し、リスクの発生可能性や影響度を小さくします。

今回の、

外部から管理機能へ侵入され、顧客情報を取得される

というリスクであれば、アクセス経路の限定、MFA、最小権限化、操作ログ取得などが候補になります。

回避

リスクを発生させる活動自体をやめます。

例えば、インターネット公開によるリスクが許容できないため、サービスをインターネットへ公開しないという判断です。

インターネット公開を続けながらWAFなどを利用するのであれば、リスクそのものは残るため「低減」です。

移転

契約や保険などによって、リスクによる金銭的な影響の一部を第三者へ移します。

ただし、保険へ加入したり外部事業者を利用したりしても、事故発生時の顧客や監督機関への説明責任まで移転できるわけではありません。

クラウドサービスを利用する場合も、単純に「クラウド事業者へリスクを移転した」と考えるのではなく、事業者が担う範囲と利用者に残る範囲を責任分界に沿って切り分けます。

基盤設備の管理などクラウド事業者が担うリスクもあれば、IAM、データ、アプリケーション、利用者側の設定など、利用者に残るリスクもあります。

保有

リスクが残ることを理解したうえで、追加対策を行わず受け入れます。

これは、

対策し忘れた

こととは全く異なります。

リスクを認識し、既存対策、発生可能性、影響度、追加対策による効果や費用を評価したうえで、

この水準の残存リスクなら許容する

と判断することです。

例えば、DMZに配置したWebサーバが一般に公開されている情報だけを提供し、機密情報を保持せず、内部システムへの接続経路も持たないとします。さらに、侵害された場合でも初期状態から再構築できるようにしていれば、情報漏洩や内部システムへの横展開による影響は限定できます。

それでも、Webページの改ざんや一時的なサービス停止といったリスクは残ります。追加対策によるリスク低減効果と構築・運用コストを比較した結果、そこまでの対策は行わず、この残存リスクを保有する判断もあり得ます。

リスクを保有するとは、「侵害されても構わない」と考えることではありません。侵害された場合の影響を把握し、既存対策で影響を限定したうえで、追加対策までは行わないと判断することです。

この判断は技術者だけで完結させず、残るリスクを前提にどの方式で進めるのかを関係者で確認します。

リスク対応を決めて、初めて具体的な対策を選ぶ

ここが4ステップの最終地点です。

今回のWebシステムについて、

顧客情報漏洩のリスクを「低減」する

と決めただけでは、まだ設計は終わっていません。

次に、

どのリスクを
どのコントロールによって
どこまで下げるのか

を決めます。

例えば、

• 管理機能へのアクセス経路を限定する
• 管理者認証にMFAを要求する
• 管理者権限を必要最小限にする
• 重要操作を記録・監視する

といったセキュリティ要件が導かれます。

AWSを利用するのであれば、ここで初めてIAMやSecurity Groupなどの具体的なサービスや機能が実装候補として登場します。

順番は、

AWSにこの機能がある
↓
使っておこう

ではありません。

リスクを評価する
↓
リスク対応を決める
↓
必要なセキュリティコントロールを決める
↓
それを実現する方式・サービスを選ぶ

です。

AWSやサードパーティが提供する機能は、セキュリティ対策を実現するための手段です。機能を使うこと自体が目的ではありません。

同じリスクでも、AWSネイティブの機能、サードパーティ製品、共通ネットワーク側の対策、運用統制など、複数の実現方式があります。重要なのは製品名ではなく、必要なセキュリティコントロールを満たし、責任分界や運用まで含めて成立することです。

セキュリティ製品やクラウドサービスは、リスクアセスメントの出発点ではなく、設計判断の結果として選ばれるものです。

上位基準がある案件では「差異」をリスクとして評価する

本記事で想定する案件では、法令や業界基準、組織のセキュリティ標準、顧客の標準仕様、上位システムの要求など、既に一定の上位基準が与えられています。

ただし、これらはすべて同じ扱いではありません。法令や契約上の義務は、リスクが低いという理由だけで不適用にはできません。 業界基準、顧客標準、組織内部の標準についても、差異を認める場合には、正式な例外承認や関係者との合意が必要になることがあります。

まず、その要求が何を根拠としているのか、変更や例外が認められるのか、認められる場合にはどの手続きが必要なのかを確認します。

そのうえで重要なのが、上位基準があるからといって、対象システムのリスクアセスメントが不要になるわけではないという点です。

まず、

このシステムには、どのような脅威・脆弱性・リスクがあるのか

を評価します。

次に、上位基準が要求する対策と、本システムで採用する実現方式が異なる場合には、

その差異によって、新たなリスクが生じないか、既存のリスクが増加しないか

を評価します。

考え方は、

対象システムのリスクアセスメント

＋

上位基準との差異評価

です。

上位基準を単純に「準拠／非準拠」で確認するのではなく、対象システム固有のリスクを評価したうえで、基準との差異がリスクにどのような影響を与えるのかまで確認することが重要です。

○×チェックするだけでは、この差異によるリスク評価が抜けてしまいます。

差異は7段階で評価する

上位基準で要求されている方式を、そのまま採用できないことがあります。

端末を複数システムで共用している、認証基盤を共通化している、ネットワークや端末を別の組織・ベンダが管理している、既存システムとの接続方式を変更できない、といった制約があるからです。

私が実際の案件で使っていたシートでも、単純な「準拠／非準拠」だけではなく、上位基準との差異の有無と、その差異に対する評価を別に管理していました。

評価の流れを図にすると、次のようになります。

図　上位基準と本システムの差異を評価する流れ

この形にすると、「基準と違う」という事実を、セキュリティ要件定義上の判断へ変換できます。

RFPの「検討する」という要求も、実現可能性を評価して結論を出す

RFPでは、実現方式や実現可能性が確定していない要求について、

監査ログの長期保管を検討する

のように、「実現すること」ではなく「検討すること」と記載される場合があります。

この場合、提案段階で複数案を比較し、要件定義で実施範囲を確定します。例えば、

• すべてのログを長期間オンラインで検索できる状態にする
• 直近分だけをオンラインで保持し、古いログは低コストの保管領域へ移す
• 認証や特権操作など、監査上重要なログだけを長期保管する

といった方式を比較できます。

保管期間を長くし、すべてのログを即時検索できるようにすれば調査性は高まりますが、保存容量、検索基盤、運用コストも増えます。逆に保管範囲を絞りすぎれば、インシデント発生時に必要な証跡が残っていない可能性があります。

そこで、法令・契約・上位基準で必須となる保存期間を確認したうえで、どのログを、どの期間、どの状態で保持すれば必要な調査・監査を成立させられるかを評価します。

検討の結果、例えば「認証・特権操作・重要データへのアクセスログは長期保管し、大量に出力されるデバッグログは短期間とする」といった結論にすることがあります。

これは「検討しなかった」のではありません。複数案の効果とコストを比較し、要求の目的を満たす範囲を要件として確定した、という提案・要件定義上の判断です。

同じ方式を採用できなくても、そこで検討を終わらせない

例えば、上位基準で、

ログの改ざんを即時に検知し、異常があれば通知する

という要求があったとします。

対象システムでも同じ仕組みを導入したいところですが、端末を他システムと共用しており、その端末は別の組織やベンダの管理下にあるとします。

上位基準と同じ改ざん検知を実現するには、端末側へのエージェント導入や設定変更が必要ですが、自システムの判断だけでは変更できません。

このような場合に、

上位基準と同じ方式を実現できないので非準拠

として終わらせてはいけません。

確認するのは、

同じ方式を採用できないことで、何のリスクが増えるのか

です。

この例なら、ログが改ざんされた場合の発見が遅れ、不正操作の追跡やインシデント発生時の原因究明が困難になる可能性があります。

そこで、

• 管理作業を行える経路や端末を限定する
• 管理者の操作を記録する
• 通常とは異なる時間帯などの操作を検知する
• インシデント発生後に操作内容を追跡できる状態にする

といった別のコントロールによって、増加するリスクをどこまで低減できるかを評価します。

ただし、代替コントロールを入れたからといって、上位基準との差異そのものが消えるわけではありません。

即時検知の範囲や検知精度などに違いが残るのであれば、それを残存リスクとして明確にします。

最終的には、

代替コントロールを実施したうえで、この残存リスクを許容できるか

を判断します。

「方式」ではなく、その対策が何を守ろうとしているのかを見る

上位基準には、具体的なセキュリティ方式まで指定されている場合があります。

例えば、

生体認証を使用する

という要求があるとします。

ここで確認したいのは、

生体認証を導入しているか

だけではありません。

なぜ生体認証を要求しているのかまで遡ります。

目的が、

本人以外による認証突破の可能性を下げる

ことであれば、本システムが既に共通認証基盤を経由し、利用端末やアクセス経路も限定されている場合、生体認証をさらに追加したときにどの程度の追加的なリスク低減効果が得られるのかを評価します。

追加効果が大きければ採用すべきでしょう。

既存の認証・端末・経路制御によって対象リスクが十分に低減されており、生体認証を加えてもリスク低減効果が限定的なのであれば、採用しないという判断もあり得ます。

ただし、

別の認証方式があるから同等だろう

と根拠なく判断することもできません。

比較するのは、認証方式の名称や機能数ではありません。

どの攻撃シナリオに対して、どの程度リスクを低減できるのかです。

上位基準があっても、STEP1〜4で説明してきたリスクアセスメントの考え方は変わりません。

「準拠している」と書くことの方が危険な場合がある

上位基準と異なる方式を採用すること自体が、直ちに問題になるわけではありません。

システム構成や責任分界が異なれば、同じ対策をそのまま適用できないことはあります。

むしろ問題なのは、

実際には差異があるのに、その差を評価しないまま「上位基準に準拠している」と扱うこと

です。

差異を明確にしておけば、

なぜ同じ方式にできなかったのか
何のリスクが増えるのか
どの代替コントロールを採用したのか
それでも何が残るのか
その前提で、どの方式で進めると合意したのか

を説明できます。

差異を認識していなければ、その説明自体ができません。

セキュリティ標準への準拠とは、書かれている対策を機械的にコピーすることではありません。基準が求めるリスク低減の目的を理解し、本システムとの差異を評価したうえで、必要な対策と残存リスクを明確にすることが重要です。

また、ここで行った差異評価は永久に有効なものではありません。上位基準が改定されることもあれば、「端末を限定している」「操作を記録している」といった代替コントロールの前提が運用中に崩れることもあります。

差異評価は合意して終わりではなく、基準の改定と代替コントロールの実効性を継続的に確認する必要があります。

この点は、後述する継続的なリスクアセスメントでも改めて扱います。

2026年、AI・ゼロデイ時代にリスクアセスメントはどう変わるか

ここまで説明してきたリスクアセスメントの考え方は、AIが普及する以前から使われてきたものです。

では、AIによって脆弱性の発見や攻撃作業が高速化している2026年現在、セキュリティ要件定義や設計の考え方そのものを大きく変える必要があるのでしょうか。

結論は、基本的な原則は変わりません。

変化しているのは、

脆弱性を発見する速度、攻撃へ利用する速度、攻撃を並列化できる規模

です。

「侵入される可能性を前提に多層防御する」という考え方をAIが生み出したわけではありません。

ゼロデイ攻撃、ランサムウェア、サプライチェーン攻撃などを考えれば、以前から「既知の脆弱性をすべて修正すれば安全になる」という前提は成立していませんでした。

AIは、この前提をさらに厳しいものにしています。

AIが攻撃工程そのものを高速化する

2025年11月、Anthropicは「GTG-1002」と名付けたサイバースパイ活動について報告しました。

Anthropicによれば、攻撃者はClaude Codeを利用し、偵察、脆弱性探索、攻撃試行、認証情報の取得、データ分析など複数の工程をAIに実行させていました。同社は、攻撃作業の80〜90％をAIが実行し、人間は重要な判断に関与していたと分析しています。

ただし、これは「AIが人間なしで高度な攻撃を完結させた」という意味ではありません。Anthropic自身も、Claudeが誤った情報を返す場面があり、人間による検証が必要だったと報告しています。外部研究者からも、AIが従来にない攻撃手法そのものを発明したとまでは確認できないという慎重な見方が出ています。

ここで重要なのは「何％が自律だったか」ではありません。

AIが攻撃を完全に自律化したというより、人間が時間をかけて行っていた偵察、脆弱性探索、攻撃試行、結果分析などを高速化・省力化した点です。

人間の作業時間が制約になっていた工程を短時間で繰り返せるようになれば、従来より多くの対象を並行して探索できます。

脆弱性を「発見する側」でも速度が上がっている

AIによる変化は攻撃側だけではありません。

2026年2月、AnthropicはClaude Opus 4.6を利用したOSSの脆弱性調査で、500件を超える高深刻度の脆弱性を発見・検証したと報告しました。

主要なOSSの中には、異常な入力を大量に自動投入して不具合を探すファジングなどの自動検査を、長年継続して受けてきたものがあります。それでもAIを使った解析によって新たな脆弱性が発見されました。

重要なのは手法名そのものではなく、従来の自動検査とは異なる方法でもコードを調べられるようになり、脆弱性探索の速度と範囲が広がっていることです。

ここで「500件すべてがゼロデイだった」と読むべきではありません。

Anthropicは、報告前に各バグを検証し、初期の調査では自社のセキュリティ研究者が脆弱性を確認してパッチを作成し、件数が増えた後は外部の人間のセキュリティ研究者も検証とパッチ開発に加わったと説明しています。

AIが候補を大量に発見できても、内容の確認、修正、テスト、リリースには人間や開発チームの作業が残ります。

発見量が増えるほど、

発見する
↓
検証する
↓
修正する
↓
テストする
↓
本番へ適用する

という防御側の処理能力がボトルネックになります。

Anthropicも、従来の90日程度の脆弱性開示・修正サイクルが、LLMによる発見量と速度に対して維持しにくくなる可能性を指摘しています。

発見と公開の速度が上がるのであれば、緊急パッチの影響判断や適用までのリードタイムを、運用開始前に決めておく重要性も高まります。

CVSSの数値だけでなく、実際の悪用実績や自システムでの利用状況、攻撃経路、パッチ適用の影響などを踏まえて判断します。具体的な判断基準と意思決定プロセスは、後半の脆弱性管理で説明します。

未知の脆弱性はアセスメントシートに列挙できない

ここで、この記事のSTEP1が効いてきます。

未知の脆弱性を、

CVE-XXXX-XXXX

のようにアセスメントシートへ事前に書くことはできません。

しかし、未知の脆弱性が悪用された場合に、どのような攻撃経路が成立するかは考えることができます。

ここまで例として使ってきた顧客情報を保持するWebシステムなら、次のような攻撃経路を考えます。

図　侵入から情報持ち出しまでの攻撃経路と、各段階に配置する防御ポイント

最初の侵入を完全に防げなかった場合でも、攻撃経路の途中で止めることはできます。

侵入後に不要な管理権限まで取得されないよう最小権限化し、認証情報を取得されても権限昇格や横展開が容易に成立しないよう、通信経路や信頼関係を制限します。

DBへ到達する段階では、通信経路と権限の両方を絞ります。

例えば、Web/APとDBの間だけ必要な通信を許可するネットワークセグメントを設け、利用者側のネットワークからDBへ直接到達できないようにします。運用管理についても、管理用LANや踏み台などの管理経路からだけアクセスできる端末・サーバを分離します。

さらに、アプリケーションや管理者に与えるDB権限を必要最小限にし、不審なアクセスや重要操作を検知・記録します。DBの権限と監査ログについては、次の記事で具体例を紹介しています。

データベースエンジニア（DBA）の仕事｜止めない、失わない、遅くさせない

データベースエンジニア（DBA）は何をする職種なのか。Oracle DBAの実務経験をもとに、物理設計・構築、性能と容量管理、権限・監査、監視、バックアップ、障害復旧、データ移行まで、構築後も続く仕事と責任をわかりやすく解説します。

sys-univ.com

2026.08.03

バックアップも、本番環境が侵害されたときに同じ権限や攻撃経路から破壊されないよう分離します。

攻撃シナリオの途中に複数の防御ポイントを置くことが、未知の脆弱性を前提にした設計につながります。

「侵入させない」だけではなく「侵入された後」まで設計する

セキュリティ対策というと、

攻撃をどう防ぐか

に目が向きやすくなります。

しかし未知の脆弱性を完全になくせないのであれば、予防だけでは設計が完結しません。

考える範囲を、

予防
↓
検知
↓
封じ込め
↓
復旧

まで広げます。

例えばWebサーバへの侵入そのものを防げなかったとしても、権限昇格を防ぎ、横展開を制限し、異常操作を検知し、影響範囲を特定して安全な状態へ戻せれば、最終的な事業影響を小さくできます。

この考え方自体は2026年になって突然登場したものではありません。NIST Cybersecurity Framework 2.0でも、サイバーセキュリティリスクへの対応をGovern、Identify、Protect、Detect、Respond、Recoverの6機能で整理し、ライフサイクル全体でリスクを管理する考え方を示しています。

AIによって変わったのは原則ではなく、各段階を攻撃者が通過する速度が上がる可能性です。

AI対応をうたう製品を追加する前に、まず攻撃シナリオのどの段階を止め、どこで検知し、どの状態まで復旧する必要があるのかを決めます。

AI Agentも同じです。AIだから特別な対策を足すのではなく、そのAgentがどの認証情報を使い、どのAPIを実行でき、どのリソースまで到達できるのかを確認し、必要な権限だけを与えます。AWS IAMでAI Agentへ与える権限の考え方は、次の記事で詳しく整理しています。

AI AgentのIAM権限はどこまで届くか｜OpenAI・Hugging Face侵害から考えるAWSセキュリティ設計

OpenAI・Hugging Face侵害を一次資料から検証し、AI Agentに与えるIAM権限、Workload Identity、ネットワーク境界、Read Only権限、検知・停止設計をAWSのセキュリティ要件として整理します。

sys-univ.com

2026.09.07

未知の脆弱性をすべて事前に把握できないからこそ、個々の脆弱性一覧だけではなく、資産・攻撃シナリオ・攻撃経路を基準にリスクを考える重要性が高まっています。

次に問題になるのが、どこまで対策し、何を残存リスクとして扱うのかです。

実施しない対策と残存リスクの扱いを決める

ここまで、脅威と脆弱性からリスクを評価し、そのリスクに応じて必要なセキュリティ対策を導く方法を説明してきました。

リスクアセスメントの結果として考えられる対策を、すべて実施するわけではありません。

対策を実施してもリスクを完全にゼロにできない場合があります。追加対策によって得られるリスク低減効果に対して、構築費や運用負荷が大きすぎる場合もあります。

最後に必要になるのが、

どこまで対策し、何を残存リスクとして扱うのか

という判断です。

これは、対策を考えることと同じくらい重要なセキュリティ要件定義です。

残存リスクは「対策しなかったリスク」だけではない

残存リスクという言葉は、

対策を実施しなかったために残ったリスク

という意味に捉えられがちですが、それだけではありません。

対策を実施しても、リスクが完全になくなるとは限りません。

例えば、管理画面へのアクセスを管理ネットワークに限定し、MFAを導入し、管理者権限を必要最小限にして、操作ログも記録したとします。

これによって外部からの不正アクセスや、認証情報を盗まれた場合のリスクは大きく下げられます。

しかし、DBAのように業務上強い権限を持つ管理者であれば、正規の権限を利用して意図的にデータを取得する可能性まで完全になくすことは困難です。

そこで、

• 特権IDの利用者や利用時間を限定する
• 重要操作を記録する
• 誰が、いつ、どのデータへアクセスしたのか追跡できるようにする
• 監査ログを管理対象のDBとは別の基盤へ転送する
• 必要に応じて承認手続きや操作監視を組み合わせる

といった統制を行います。

ログを取得していても、そのログを同じDBA権限で消せるのであれば、証跡として十分とはいえません。管理者自身が容易に改ざん・削除できない場所へ証跡を残すことも重要です。

それでも、正規権限を持つ内部者による不正利用の可能性がゼロになるわけではありません。

対策を実施したあとにも残っているリスクが、残存リスクです。

ここは、STEP4で説明した「保有」と区別しておきます。

「保有」はリスクへの対応方針です。残存リスクは、低減策を実施した場合にも存在します。

リスクを低減する
↓
対策後のリスクを再評価する
↓
それでも残るリスクを把握する
↓
そのリスクを前提に、どの方式・運用で進めるかを判断する

という流れになります。

ここまでは、主に情報漏洩や不正利用といった機密性に関する残存リスクを例にしてきました。

しかし、情報セキュリティは機密性・完全性・可用性（CIA）の3つで考えます。大規模障害や災害によって、必要なときにシステムを利用できなくなることも、可用性に関するセキュリティリスクです。

次に、CIAのうち可用性に関する残存リスクの例として、リージョン障害を考えます。

「バックアップがある」と「災害対策先で安全に業務継続できる」は違う

別リージョンへデータや復旧資材を保管していても、それだけで災害対策先から安全に業務を再開できるとは限りません。

DRでは可用性を回復することが目的になりますが、復旧先でも機密性や完全性を維持する必要があります。データを復旧できても、アクセス制御が効かず誰でも参照できる状態になったり、認証を省略しなければ利用できなかったりするのであれば、セキュリティ要件を満たした復旧とはいえません。

例えば、セカンダリリージョンにWeb/AP、DB、バックアップを用意できても、認証基盤がプライマリリージョンに依存している場合があります。

AWSでCognitoを認証基盤として利用しているケースなら、

セカンダリリージョンでWeb/APやDBは起動できる

↓

しかしログイン時の認証はプライマリリージョン側のCognitoに依存している

↓

プライマリリージョンが利用できなければ、正常な認証経路が成立しない

ということが起こり得ます。

この状態で、

認証を迂回してサービスだけ起動する

という対応をすれば可用性だけは回復できるかもしれませんが、今度は認証・認可が成立せず、機密性を損なうリスクが生じます。

DRで確認すべきなのは、

バックアップデータが存在するか

だけではなく、

認証、DNS、鍵管理、外部接続、アクセス制御などを含め、一連の業務経路がセキュリティを維持した状態で成立するか

です。

上位基準との差異があれば、残存リスクまで明確にする

前節で説明した差異評価も、最終的には同じところへ行き着きます。

上位基準と同じ方式を採用できなかった場合、

差異がある

と確認するだけでは不十分です。

差異によって増えるリスクを評価し、代替コントロールを実施したうえで、それでも何が残るのかを確認します。

例えば、上位基準と同じリアルタイムの検知方式を採用できず、別の監視や操作記録によってリスクを低減したとします。

代替コントロールによってリスクが下がっても、上位基準とまったく同じ検知能力になるとは限りません。

そこで、

代替コントロールを実施した結果、何のリスクがどの程度残るのか

まで明確にします。

ここまで整理して初めて、

この差異を前提に、この方式で進めてよいか

を判断できます。

「×」や「対象外」だけでは、設計判断を残したことにならない

セキュリティの確認表では、対策ごとに「○」「×」「対象外」と記録することがあります。

しかし、

対策A：×

だけでは、なぜ実施しなかったのか分かりません。

リスクを見落としていたのか。

追加対策による効果が小さいと判断したのか。

費用とのバランスを評価した結果なのか。

代替コントロールによって十分に低減できているのか。

その違いは、記号だけでは残りません。

「対象外」も同じです。

対象外は、本来、

このシステムでは当該リスクが成立しない
この構成要素には適用されない
別の組織やシステムが責任を持つ範囲である

など、評価した結果として適用対象から外したことを意味します。

対象外にしたことと、リスクを認識したうえで追加対策を実施せず保有したことは別の判断です。

どちらの場合も、後から判断を再現できるように理由を残します。

「実施しない」を技術者だけで決めない

残るリスクをどう扱うかは、セキュリティ担当者やシステム設計者だけで完結する判断ではありません。

例えば、DBAの不正利用リスクに対して、特権ID管理、二重承認、常時監視などを追加すれば、さらにリスクを下げられる可能性があります。

しかし、追加対策には費用と運用負荷が伴います。技術者は、

現在の対策でどこまでリスクが下がっているか
追加対策で何が改善するか
それでも何が残るか

を説明できます。

そのうえで、システムの重要性、業務影響、費用を踏まえ、残るリスクを前提にどの方式で進めるのかを、適切な責任者を含む関係者で決めます。

理想的には、残存リスクとその扱いを成果物に明示し、受容主体まで残せるのが分かりやすい形です。

ただし、実務では必ずしもそうならないことがあります。

実務Tips：残存リスクは、必ずしも「受容」と明記されるとは限らない

私の経験では、発注者側が「このリスクを受容する」という表現や、リスクが顕在化した場合の結果を成果物へ明記することを避けるケースがありました。特に大規模案件や公共系の案件では、そのような場面もありました。

会議では、

ここまでは対策する
ここから先は実現しない
このリスクは残る
その前提でこの方式を採用する

という議論が実際に行われていることがあります。

その場合、「残存リスクを受容した」と強い表現で書けなくても、

何が制約なのか
何が実現できないのか
その結果、何が起こり得るのか
どの代替策を採るのか
その前提でどの方式で進めると確認したのか

を、可能な範囲で記録に残します。

議事録は納品成果物に含まれない場合もありますが、会議後に関係者へ正式に共有される重要なプロジェクト記録です。計画時には想定していなかった緊急会議であっても、そこで何を説明し、何を確認したのかを議事録に残しておけば、後から判断経緯を追跡できます。

例えば、

「○○の制約により△△は実施しない。代替策として□□を採用し、本方式で進めることを確認した。」

という残し方です。

議事録が契約上の承認文書になるかどうかは案件の文書管理ルールによります。それでも、「説明した」「制約を共有した」「その前提で方式を確認した」という判断経緯を後から確認できる状態にしておくことには大きな意味があります。

事故後に「なぜ実施しなかったのか」を説明できるか

セキュリティ事故が起きたあとに、

「なぜ、この対策を実施していなかったのか」

と問われることがあります。

そのとき、

リスクを認識したうえで、既存対策と追加対策の効果を評価し、その残存リスクを前提にこの方式で進めることを関係者間で合意していた

と説明できる状態と、

なぜ「×」になっているのか分からない

状態では、大きな違いがあります。

セキュリティ要件定義の品質は、実施した対策の数だけでは決まりません。

必要な対策を導くこと。

実施しない対策についても判断理由を明確にすること。

対策後に残るリスクを把握すること。

そして、その残存リスクを前提に、どの方針で進めると決まったのかを追跡できるようにすること。

ここまで行って、リスクアセスメントによるセキュリティ要件の判断が一度閉じます。

ここからは、決めたセキュリティ要件をプロジェクトの後工程でどう扱うかです。

アセスメント結果を設計・見積・RFPへ引き継ぐ

前半で触れた要件定義と設計の境界を、後工程へ渡す観点から整理します。

要件定義では、リスク評価をもとに必要なリスク低減水準や満たすべきセキュリティ要求を決めます。 基本設計以降では、その要求を満たすネットワーク構成、認証方式、製品、クラウドサービス、運用方式を具体化します。基本設計で何を具体化するのかは、基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程でも詳しく整理しています。

この境界を意識しないと、要件が粗すぎて見積前提が揃わないか、逆に要件定義で方式まで固定しすぎて設計の選択肢を失います。

また、セキュリティ要件は厳しく設定すればよいわけではありません。必要な権限を絞りながら、システムとして成立する実装方式へ落とす必要があります。

例えばECS/Fargateでコンテナを非rootで実行する設計にすると、共有VolumeのUID/GIDやファイル権限まで整合させなければ、アプリケーションやログ収集がPermission deniedで動かなくなることがあります。Fluent BitがPermission deniedでログを読めない｜ECS/Fargate共有VolumeのUID/GID設計では、最小権限を実装レベルまで落としたときに何を設計する必要があるかを具体例で整理しています。

STEP4で導いた要件を後工程の条件へ変換する

STEP4で導いたセキュリティ要件は、アセスメントシートの中に閉じ込めず、設計・見積・調達の条件へ変換して渡します。

ここで重要なのは、対策項目をもう一度並べることではありません。どのリスクをどこまで下げるための要求なのかという設計根拠を、後工程でも追跡できる状態にすることです。

セキュリティ要件は見積条件でもある

セキュリティ要件をどこまで求めるかによって、構築費と運用費は変わります。

例えば、

ログを保存する

という要求と、

セキュリティ上重要な操作を集中管理し、一定期間保存し、不審な操作を検知する

という要求では、必要になる仕組みも運用も違います。

可用性についても、バックアップから復旧できればよいのか、別拠点や別リージョンへの切替まで求めるのかによって費用は大きく変わります。

要件定義で、

高いセキュリティを確保すること

とだけ書いても、見積条件にはなりません。

費用に影響するセキュリティ要求は、ベンダが同じ前提で見積もれる粒度まで明確にする必要があります。

同時に、実装方式まで不必要に固定しないことも重要です。

認証強度や監視範囲、保存期間など、費用やシステム構成へ大きく影響する要求は要件として定める。それをどの製品やクラウドサービスで実現するかは、設計に選択肢を残せるのであれば固定しない。

見積可能な粒度まで要求を具体化しながら、実装方式まで不必要に縛らないことがポイントです。

RFPへ渡すなら「対策」だけでなく「要求の背景」も残す

冒頭で説明したRFPは、本記事の要件定義へ入るための入力でした。工程ごとに調達を分ける案件では、要件定義の成果が次工程のRFPや見積条件になります。

要件定義と基本設計以降で契約や担当ベンダが変わる案件では、アセスメント結果を次工程へ渡せる形にしておく必要があります。

このとき、

MFAを実装すること

だけを渡すより、

管理機能への不正アクセスによる顧客情報漏洩リスクを低減するため、管理者認証にはMFAを要求する

と、要求の背景まで追跡できる方が設計しやすくなります。

後工程で方式変更が必要になった場合にも、

MFAという方式を守れるか

だけではなく、

元々低減しようとしていたリスクを、変更後の方式でも十分に低減できるか

という判断に戻れるからです。

要件定義工程と基本設計以降を別に調達する案件では、この粒度がそのまま次工程の入札条件になります。

要求が粗すぎれば、ある応札者は24時間監視まで含め、別の応札者はログ保存だけを想定するなど、見積前提がばらつきます。価格差が方式差なのか、単なる前提差なのか分からなくなり、比較そのものが難しくなります。

細かく書きすぎて製品名や実装方式まで固定すると、応札側がより適切な方式を提案できる余地を奪います。

RFPでは、応札者が同じ要求水準を見積もれる具体性と、設計提案を可能にする自由度の両方が必要です。

要求の背景にあるリスクを残しておけば、この2つを両立させやすくなります。

未確定事項を「決まったこと」にしない

要件定義ですべての実装方式まで決められるとは限りません。

詳細な製品仕様や他システムとの調整結果を見なければ判断できない項目もあります。

その場合、無理に○や×を付けて確定させるより、

要件として必要なこと
現時点で決まっていること
基本設計以降で継続して検討すること

を分けておきます。

未確定事項を未確定のまま明示することは、設計品質が低いことを意味しません。

判断に必要な情報がまだ揃っていないことを明確にし、誰がどの工程で判断するのかを後工程へ渡す方が安全です。

アセスメント結果は、セキュリティ部門だけが保管する資料ではありません。

設計条件、見積条件、調達条件へ変換されて初めて、プロジェクト全体で使えるセキュリティ要件になります。

セキュリティアセスメントは一度実施して終わりではない

要件定義でリスクアセスメントを実施し、必要な対策と残存リスクの扱いを決めても、その評価がシステム廃止まで有効なわけではありません。

システム構成も脅威も変化します。

特に確認しなければならないのが、

評価した当時の前提が、現在も成立しているか

です。

代替コントロールの前提が崩れれば、差異評価も変わる

上位基準との差異評価では、同じ方式を採用できない場合に、別のコントロールでリスクを低減する方法を説明しました。

例えば、

利用できる管理端末を限定している
管理操作を記録している

ことを前提に、上位基準との差異による残存リスクを許容したとします。

その後の運用変更によって、管理端末が増えたり、操作ログの監視が実施されなくなったりすれば、当初の差異評価を支えていた前提が崩れます。

評価表に書かれた結論が同じでも、実際のリスクは既に変わっています。

上位基準自体が改定される場合もあります。

差異評価では、差異そのものだけでなく、代替コントロールが現在も有効に機能しているかを継続して確認する必要があります。

システム変更は、リスクの変更でもある

機能追加や構成変更でもリスクは変化します。

例えば、当初は社内ネットワークからだけ利用していたシステムを、インターネットから利用できるように変更すれば、同じアプリケーションでも脅威への露出が変わります。

外部SaaSとのAPI連携を追加すれば、新しい通信経路、認証情報、責任分界が生まれます。

IAM権限を変更したり、運用端末を追加したりした場合も、以前とは異なる攻撃経路が成立する可能性があります。

設計変更を、

機能が動くか

だけで確認するのではなく、

既存のリスク評価に影響しないか

まで確認します。

リスクアセスメントは、要件定義時に一度作って保管する資料ではありません。システムや外部環境が変われば、前提となるリスクも変わるため、必要に応じて見直します。具体的な見直しの契機は後述します。

脆弱性の「深刻度」だけでなく、実際に悪用されているかを見る

運用開始後には、多数の脆弱性情報が継続的に公開されます。

すべての脆弱性を同じ速度で修正することは、現実には困難です。

CVSSなどの深刻度は重要な判断材料ですが、それだけで対応順位を決める必要はありません。

CISAは、実際の攻撃で悪用された脆弱性をKnown Exploited Vulnerabilities（KEV）Catalogとして継続的に管理・公開しており、組織の脆弱性管理における優先順位付けの入力としてKEVを利用するよう案内しています。

例えば、

CVSSは高いが、自システムでは該当機能を使用しておらず外部からも到達できない脆弱性

と、

深刻度だけを見れば同程度でも、実際の攻撃で悪用されており、自システムが外部へ公開している機能に存在する脆弱性

では、対応優先度が同じとは限りません。

ここでも見るのは、

脆弱性の点数

だけではありません。

その脆弱性が、自システムのどの資産に対して、どの攻撃シナリオを成立させるのかです。

KEVに掲載されているから無条件に自システムの最優先になるわけでもありません。対象製品を利用しているか、脆弱な機能が有効か、攻撃経路が存在するかといった、自システム側の条件と組み合わせて判断します。

脆弱性管理では「何日で判断し、何日で適用するか」も設計する

AI節では、脆弱性を発見する量と速度が上がれば、人間側の検証・修正・適用能力がボトルネックになる可能性について触れました。

この問題は、運用開始後に初めて考えるものではありません。運用開始後の監視・ログ・バックアップ・判断体制まで含めた設計については、次の記事で説明した論点ともつながります。

運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点

運用設計とは何かをシステム基盤エンジニアの実務目線で解説します。運用設計書の目次サンプルと検討項目一覧を示し、監視・ログ・バックアップ・ジョブ管理、誰がやるのか、要件定義・基本設計との関係、処理方式設計との双方向連携を整理します。

sys-univ.com

2026.08.14

重大な脆弱性が見つかったとき、CVSSの数値だけで「9.0以上なら即適用」のように機械的に決めるのではなく、例えば次の観点をあらかじめ判断基準として決めておきます。

• CVSSなどの脆弱性の深刻度
• 実際の攻撃で悪用されているか
• 脆弱性の対象となる製品・サービス・機能を自システムで利用しているか
• 外部から到達可能か、攻撃経路が成立するか
• WAF、アクセス制御、ネットワーク分離など既存対策でどこまで抑えられているか
• パッチ適用による停止や互換性への影響
• すぐ適用できない場合の代替コントロールがあるか

こうした情報をもとに、セキュリティ、基盤、アプリケーション、運用などの有識者で評価し、

緊急で適用する
通常の保守タイミングで適用する
代替対策で一時的にリスクを下げる
自システムには影響しないと判断する

といった対応方針を決めます。

さらに、

重大な脆弱性は何時間・何日以内に影響判断するのか
緊急適用が必要な場合、何日以内を目標にするのか
システム停止を誰が承認するのか
適用できない場合、誰が代替策と残存リスクを判断するのか

まで運用として決めておくと、脆弱性が公表されてから毎回ゼロから相談する必要がありません。

ここでは責任分界も重要です。OSやミドルウェアの脆弱性について、影響調査、適用判断、パッチ作業のどこまでを保守ベンダ、運用委託先、利用者側が担うのかを決めていなければ、緊急時に判断が止まります。

パッチを急いで適用すれば、変更による障害リスクも高まります。十分な検証を優先しすぎれば、既に悪用されている脆弱性を長期間残すことになります。

ここにも、セキュリティと安定運用のトレードオフがあります。

重要なのは、脆弱性の点数だけを見るのではなく、その脆弱性が自システムでどのリスクを成立させるのかを評価し、判断基準と意思決定プロセスを事前に決めておくことです。

再アセスメントする契機を決めておく

毎日すべてのリスクを最初から評価し直す必要はありません。

再評価の契機は、大きく3種類に整理できます。

1つ目はシステム側の変化です。 構成やインターネット公開範囲を変更した、外部サービスや接続先を追加した、IAMや管理経路を変更した、新しいAPIを公開した、保持するデータを変更した、といった場合です。

2つ目は外部環境の変化です。 上位基準やセキュリティ標準が改定された、重大な脆弱性が発見された、実際の攻撃で悪用されていることが確認された、といった変化が該当します。

3つ目は評価の前提そのものの変化です。 代替コントロールの運用方法や実効性が変わった、セキュリティインシデントが発生して従来の想定が不十分だと分かった、といった場合です。

図　システム・外部環境・前提条件の変化を契機に再アセスメントし、要件・設計・運用を更新する循環イメージ

実務では、仕様変更が入ったときに、変更対象のプログラムだけを見るのではありません。

変更管理委員会などで、

変更内容
→ 影響する構成要素・関連チーム
→ 変化する脅威・脆弱性
→ リスク再評価
→ 必要な要件・設計・運用・テストの見直し

まで確認します。

例えば、外部接続の追加であれば、ネットワークチームだけでなく、認証、IAM、ログ監視、運用手順、障害時の切り分けまで影響する可能性があります。セキュリティに影響する変更であれば、関連するリスクアセスメントも見直します。

何かが変わるたびにアセスメントシート全体を作り直すのではなく、変化によって影響を受ける資産、脅威、攻撃シナリオ、既存対策、残存リスクを見直すという考え方です。

ウォーターフォール型の大規模開発では、後工程になるほど要件、設計、試験、運用手順など複数の成果物へ影響が波及するため、変更時の見直しは大きな作業になります。前工程へ戻るコストが大きいからこそ、変更管理の中にセキュリティ影響確認を組み込んでおく必要があります。

アジャイル開発でも原理は同じです。大きな工程へまとめて戻るのではなく、機能追加や変更のサイクルごとにセキュリティ影響を確認し、必要に応じてリスク評価や対策を更新します。

開発手法にかかわらず、変更によって以前のリスク評価の前提が変わっていないかを確認することが重要です。

セキュリティアセスメントは単なる成果物ではなく、システムの変化に対してセキュリティ判断を更新するための基準として使うものです。

まとめ｜セキュリティ要件は、リスクから必要な対策を導く

セキュリティ要件は、暗号化、MFA、WAF、ログ管理といった具体的な対策を先に選んで決めるものではありません。

RFP、顧客標準、業界基準などの上位要求を入力として、まず対象範囲と責任分界を整理し、

脅威を分析する
↓
脆弱性・設定不備・統制不足を分析する
↓
リスクを分析・評価する
↓
リスク対応を決め、必要な対策へ落とす

という流れでセキュリティ要件を導きます。

脅威を検討するときには、構成要素と脅威を掛け合わせ、外部攻撃者だけでなく、内部者、委託先、人的ミス、物理的な侵入まで見ます。

上位基準がある案件でも、基準への○×判定だけでは終わりません。

上位基準の要求
↓
本システムの実現方式
↓
差異
↓
差異によって増えるリスク
↓
代替コントロール
↓
残存リスク
↓
合意

まで評価します。

AIによって脆弱性の発見や攻撃作業の速度が上がっても、この順序は変わりません。

未知の脆弱性をすべて事前に列挙することはできないため、個々のCVEだけを見るのではなく、資産と攻撃シナリオを基準に、侵入後の権限昇格、横展開、情報取得まで含めて考えます。

必要な対策を実施しても、リスクを完全にゼロにはできません。

最後に必要なのは、

何を実施し、何を実施しないのか。
その結果、何のリスクが残るのか。
その前提で、どの方式・運用で進めると決まったのか。

を説明できる状態にすることです。

理想的には残存リスクの受容主体まで明文化します。実務上それが難しい場合でも、制約、代替策、残るリスク、判断経緯を成果物や議事録などで追跡できる状態にしておくことが重要です。

そして、そこで判断を終わらせません。

要件定義で決めた内容を設計、見積、次工程のRFP、運用へ引き継ぎ、システム構成や脅威、上位基準、代替コントロールの前提が変われば、リスクを再評価します。

公的なガイドラインや組織標準、過去のアセスメントシートは、検討漏れを防ぐための重要な材料です。ただし、それ自体が対象システムの答えになるわけではありません。

セキュリティ要件定義で本当に必要なのは、

何を守るのかを明確にし、脅威と弱点からリスクを評価し、そのシステムに必要な対策と残るリスクの扱いを判断すること

です。

この判断過程まで説明できて初めて、セキュリティ要件が設計根拠を持った要求になります。

実務で使うためのアセスメントシートと差異評価

ここまでで、セキュリティ対策をリスクから導き、実施しない対策と残存リスクまで判断する考え方を説明しました。

実際の案件でこの方法を回すには、判断結果を残すためのアセスメントシートと、上位基準との差異・代替コントロール・残存リスクを記録する型が必要になります。

今後公開予定の実務編では、リスクアセスメントシートと差異評価シートの具体的な記入方法、差異ステータスの判定、判断理由・残存リスクの書き方、顧客説明資料への落とし込み方を、実務で使える形にまとめるます。

参考資料

• Anthropic, “Disrupting the first reported AI-orchestrated cyber espionage campaign”
  
  

  Disrupting the first reported AI-orchestrated cyber espionage campaign

  A report describing an a highly sophisticated AI-led cyberattack

  

  www.anthropic.com
• Ars Technica, “Researchers question Anthropic claim that AI-assisted attack was 90% autonomous”
  
  

  Researchers question Anthropic claim that AI-assisted attack was 90% autonomous

  The results of AI-assisted hacking aren't as impressive as many might have us believe.

  

  arstechnica.com
• Anthropic, “Evaluating and mitigating the growing risk of LLM-discovered 0-days”
  
  

  LLM-discovered 0 days

  AI models can now find high-severity vulnerabilities at scale. This is a moment to empower defenders. We're now using Claude to find and help fix vulnerabilitieReadMore...

  

  www.anthropic.com
• NIST, “The NIST Cybersecurity Framework (CSF) 2.0”
  
  

  The NIST Cybersecurity Framework (CSF) 2.0

  The NIST Cybersecurity Framework (CSF) 2.0 provides guidance to industry, government agencies, and other organizations to manage cybersecurity risks.

  

  www.nist.gov
• CISA, “Known Exploited Vulnerabilities Catalog”
  
  

  https://www.cisa.gov/known-exploited-vulnerabilities-catalog

  

  www.cisa.gov
• 個人情報保護委員会, 「令和7年度（2025年度）個人情報保護委員会年次報告」
  
  

  個人情報保護委員会　令和７年度年次報告の公表について（令和８年７月７日） ｜個人情報保護委員会

  個人情報保護委員会のホームページです。令和７年度個人情報保護委員会年次報告の概要等の公表について掲載しています。

  

  www.ppc.go.jp
• AWS, “Shared responsibility – Security Pillar”
  
  

  責任共有 - セキュリティの柱

  セキュリティとコンプライアンスに関して、AWS とお客様の間で責任を共有します。この共有モデルにより、ホストオペレーティングシステムや仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまで、さまざまなコンポーネントを AWS が運用、管理、制御するため、お客様の運用の負担が軽減されます。お客様はReadMore...

  

  docs.aws.amazon.com
• IPA, “システム構築の上流工程強化（非機能要求グレード）紹介ページ”
  
  

  システム構築の上流工程強化（非機能要求グレード）紹介ページ | アーカイブ | IPA 独立行政法人 情報処理推進機構

  情報処理推進機構（IPA）の「システム構築の上流工程強化（非機能要求グレード）紹介ページ」に関する情報です。

  

  www.ipa.go.jp

大手SIerで20年以上、システム基盤エンジニアとしてプロジェクトに参画してきました。その中で繰り返し遭遇してきたのが、運用設計の漏れや、処理方式設計との不整合を原因とするトラブルです。

運用設計とは、本番稼働後に必要となる作業、判断基準、体制を整理し、それをシステムの処理方式や構成と結びつける設計です。

• 監視対象は定義されているのに、何を異常とみなすのか決まっていない。

• ログは出力されているのに、保持期間や削除方法が決まっていない。

• バックアップは取得しているのに、必要な時間内にリストアできるか確認されていない。

• ジョブネットは作られているのに、実行するスクリプトが存在しない。

こうした設計不備は、重大な障害の見逃しや復旧の遅れにつながります。システムを利用するお客様だけでなく、その先にいる利用者や社会へのサービス提供を損なう事態にもなりかねません。

それほど重要な設計領域であるにもかかわらず、運用設計は多くのプロジェクトで軽視されてきました。

なぜでしょうか。

100のシステムがあれば、運用の形も100通りあります。運用・保守に関する確認観点を整理したフレームワークや標準はありますが、それをそのまま適用すれば運用設計が完成するわけではありません。

サービス時間、業務日付、外部連携、夜間バッチ、監視、バックアップ、障害時の判断、運用体制は、システムごとに具体化する必要があります。

非機能要件だけでなく、業務運用や組織の役割分担にもまたがるため、定型の設計書に集約しにくく、見える化しづらい設計領域だといえます。

もう一つ、情報の偏りという問題もあります。

世の中の技術情報を見渡すと、logrotateの設定方法やクラウドサービスの使い方といった処理方式寄りの解説か、ITILに基づく管理プロセスといった組織・サービス管理寄りの解説か、そのどちらかに偏っています。現場のSEが本当に苦労するのは、その中間にある領域です。

運用要件をどの仕組みで実現し、どの設定値、スクリプト、ジョブ、監視条件に落とし込むのか。ここを扱った情報は、驚くほど少ないのが実情です。

この記事では、システム基盤から見た運用設計を中心に、共通化しやすい検討項目を「運用設計書の目次サンプル」として示します。

あわせて、運用設計が処理方式設計と切り離せない理由と、運用設計が要件定義から始まり、基本設計の段階で骨格が決まることを、現場の経験から整理します。

実際にあった運用設計漏れによるトラブル

まず、運用設計漏れによって発生したトラブルの例を見てみます。

あるサーバでは、syslogファイルをローテーションしないまま、ログが出力され続けていました。

このまま運用を続ければ、syslogファイルはパーティションの空き容量を消費し続けます。それがルート領域であれば、OSやミドルウェアが正常に動作できなくなり、ログインやプロセス起動にも支障が出る可能性があります。

ログ管理設計の漏れがどのように障害へつながるのかを、図にすると次のとおりです。

ディスクの空き容量を監視していれば、容量が枯渇する前に検知できたかもしれません。

ただ、これは監視だけの問題ではありません。空き容量の監視は、容量逼迫という状態を検知する仕組みです。

根本原因は、ログの増加を前提に、保持、退避、圧縮、削除を設計していなかったことにあります。

ログ管理を運用設計項目として定義し、

• どのログを管理対象とするのか、

• 何の目的で保存するのか、

• どの期間保持するのか、

• 即時に参照できる必要があるのか、

• いつ外部領域へ退避するのか、

• いつ圧縮・削除するのか、

• 誰が参照できるのか

これらを決めていれば避けられたトラブルです。

その運用設計を入力として、処理方式側では、logrotateを使うのかジョブで退避するのか、どのパーティションへ保存するのか、どれだけの容量が必要なのかを具体化します。

一見すると「検討していて当然」と思われる内容です。それでも、ログ管理を運用設計の対象として認識していないプロジェクトでは、実際に漏れます。

運用設計はいつやるのか｜要件定義から始まり基本設計で骨格が決まる

運用設計のプロセスを理解するには、システム開発全体の中での位置づけを押さえる必要があります。

ウォーターフォール型の開発プロセスは、要件定義、設計、製造、試験、移行、保守・運用という流れで説明されることが多いと思います。

このモデルでは工程の最後に「保守・運用」が置かれているため、運用に関する検討もシステムが完成してから行えばよい、という誤解が生じます。

最後に置かれているのは、完成したシステムを実際に維持管理する運用工程です。そのシステムをどのように運用するのかを決める運用設計は、設計工程の中にあります。

運用設計を設計工程として扱わないプロジェクトでは、サービス開始直前になって検討不足が表面化します。

• ログがローテーションされない。

• バックアップはあるのに戻せない。

• ジョブは定義されているのに実行するスクリプトがない。

• 監視アラートは出るのに一次対応者が決まっていない。

• 夜間処理は終了したのに、業務を開始してよいか判断できない。

私はそうした現場を数多く見てきました。

これらは、運用開始後に考える問題ではありません。工程初期から、処理方式とセットで具体化すべき設計事項です。

処理方式設計と運用設計は双方向でつながっている

ここからが、この記事で最も伝えたい内容です。

運用設計で最も重要なのは、処理方式設計との接続です。
運用設計は単独では成立せず、処理方式設計と対になって、初めて本番で運用できる設計になります。

処理方式設計とは、要件をどのような仕組みで実現するかを具体化する設計です。運用設計とは、その仕組みを実際の運用の中でどのように扱うかを具体化する設計です。

この2つは別の設計領域ですが、完全に分けて考えることはできません。

ログ管理を例に考えます。

運用設計側では、管理対象とするログ、利用目的、保持期間、参照要件、退避・削除方針、アクセス権限を決めます。

「syslogを1か月保持する」と運用設計で決めたとします。この決定だけでは、1か月保持は実現できません。

• 処理方式側で、

• 日次と週次のどちらでローテーションするのか、

• Linuxのlogrotateで実現するのか

• ジョブ管理製品で退避するのか、

• 退避先ディレクトリをどこにするのか、

• 圧縮するのか、

• 外部のログ管理基盤へ転送するのか、

• 必要なディスク容量はいくらか、

• 容量逼迫をどの条件で検知するのか

これらを設計する必要があります。運用設計の決定が、Linuxや監視製品、ログ管理製品の処理方式設計への入力になるわけです。

逆方向の流れもあります。Linux設計側でログの退避先を決めたなら、その情報は運用設計側へ伝えなければなりません。

ログは、要件に応じてバックアップや外部保管の対象になります。退避先が運用設計側へ伝わっていなければ、バックアップ対象やログ収集対象から漏れる可能性があります。

障害調査に必要なログが残っていない、という事態はこうして生まれます。

運用設計側が「何を、どれくらい、何の目的で管理したいのか」を決める。処理方式設計側が「それをどの仕組みで実現するのか」を決める。運用要件が処理方式に影響し、処理方式の制約が運用設計に戻ってくる。

この関係は一方向の受け渡しではなく、レビューやウォークスルーを通じて、相互に入力とフィードバックを繰り返しながら固めていくものです。

どちらを先に検討するかは状況によって異なりますが、運用設計者と処理方式設計者の間で認識齟齬を残さないことが重要です。

現場では、構築チームと運用準備チームが分かれ、ドキュメントも処理方式設計書と運用設計書に分断されることがあります。

その結果、ログ保持期間を満たすためにどの設定と容量設計が必要なのか、という両者の紐付けが、設計者の頭の中にしか存在しない状態になりがちです。

この紐付けを設計書、課題管理、レビューの仕組みで見える化できるかどうかが、運用設計の品質を左右します。

運用スクリプトは運用設計で横断的に洗い出す

処理方式設計と運用設計の双方向連携を示す例として、運用スクリプトを考えます。

バックアップ要件をジョブネットで実現するとします。

• ジョブネットには、

• バックアップ取得、

• ログ退避、

• 世代削除、

• 整合性確認、

• 後処理

といった個別ジョブが登録されます。それぞれのジョブでは、実行対象となるスクリプト、コマンド、プログラム、製品機能が必要です。

ここで問題になるのが、必要な実行部品を誰が洗い出すのかという点です。

バックアップ方式だけを設計していると、バックアップ製品の設定は完了していても、ジョブから呼び出すスクリプトや終了判定処理が漏れることがあります。

ジョブネットだけを設計していると、ジョブの箱は並んでいるのに、中で何を実行するのか決まっていないことがあります。

運用で必要になるスクリプトや実行処理は、運用設計の中で横断的に洗い出す必要があります。

運用設計で横断的に洗い出すことと、運用設計担当がすべてのスクリプトを作成することは別です。

バックアップスクリプトはバックアップ方式の担当、ログ退避スクリプトはログ管理方式の担当、ジョブ制御スクリプトはジョブ設計の担当、起動停止スクリプトはOS・ミドルウェアの担当というように、実際の設計、製造、単体試験は、その仕組みを設計した担当が行うのが基本です。

運用設計側で行うのは横断管理です。

必要なスクリプトを一覧化し、

• 用途、

• 呼び出し元となるジョブ・手順・他スクリプト、

• 関連する運用作業、

• 作成担当、

• 完成時期、

• 後続テストでの確認方法

それらを明確にします。そして、スクリプトの設計、製造、単体試験、ジョブ登録をWBSへ反映し、結合テスト、システムテスト、運用テストに間に合わせます。

この横断管理がないプロジェクトでは、個別の方式設計は完了しているのに、実際の運用に必要なスクリプトだけが作られていない、という事態が起こります。

サービス開始直前になって発覚するスクリプト不足やジョブネットの実行エラーの多くは、この横断管理が不足した結果です。

運用設計で必要な実行部品を早期に洗い出し、処理方式の担当へ返すことが重要です。

運用設計の全体像

システム運用とは、利用者へ提供しているサービスを安定して継続するために、システムを維持管理していく活動です。その運用を成立させるための設計が、運用設計です。全体像は、次の3つに分けて考えると理解しやすくなります。

業務運用設計は、業務機能や実際の業務作業と結びつく領域です。

システム基盤運用設計は、サーバ、ネットワーク、ストレージ、ジョブ、監視、ログ、バックアップといった、システムを支える仕組みと強く結びつきます。

全体運用設計は、ITILのプラクティスと重なる領域が多く、体制や責任分界、障害・変更管理、サービスレベル管理を扱います。この記事では、主にシステム基盤運用設計を対象とします。

なお、運用手順書一覧、運用スクリプト一覧、ジョブ一覧は、特定の区分だけに属するものではありません。3つの領域で必要になる成果物を横断的に洗い出し、作成担当と期限を管理する必要があります。

関連する工程に、運用テストがあります。

運用テストでは、ここで設計した運用フロー、判断基準、承認フロー、復旧方法が実際に運用可能かを確認します。

運用設計の品質が低ければ、運用テスト自体が成立しません。

障害時の連絡先が分からない、問い合わせの受付方法が決まっていない、誰が業務開始可否を判断するのか分からない。こうした状態を、サービス開始後に残してはいけません。

運用テストを含むテスト工程の考え方は、以下の記事で解説しています。

Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方

Vモデルは古い開発手法の話ではなく、要件・設計で決めたことをテストで確認する品質保証の考え方です。バックアップ要件の具体例で各工程の対応関係を整理します。

sys-univ.com

2026.07.13

システム基盤運用設計書の目次サンプル

運用設計について調べている人が最も知りたいのは、運用設計書で検討すべき「項目」ではないでしょうか。以下に、システム基盤運用設計書の目次サンプルを示します。

この目次は、IPAの非機能要求グレードなどの確認観点を参考にしながら、実際のプロジェクトで扱いやすい運用作業単位に整理したものです。

非機能要件の項目をそのまま設計書の章立てにしても、実際の運用作業との対応が見えにくいことがあります。

プロジェクト参画経験から、システム運転、監視、ログ、バックアップ、起動停止といった、実際に発生する運用作業を目次の単位にすることで、検討漏れを減らせると考えています。

表の「項目」は、運用設計書の章や節を組み立てる際のたたき台として使えます。

ただし、設計内容だけを書いて終わりではありません。

各項目について、実施主体、実施契機・頻度、正常・異常の判断条件、承認者・判断者、入出力情報、運用フロー、必要な手順書、必要なスクリプト・ジョブ、処理方式設計への申し送りも、必要に応じて整理します。

要件定義で合意した内容を、どの運用設計項目へ反映するのかを確認しながら進めることが重要です。

ここで挙げた項目は、一般的なシステムにおける最大公約数です。

すべてのシステムに同じ項目を適用すればよいわけではありません。外部公開サービスであれば、DDoS対策やWAF運用が必要になるかもしれません。

クラウドネイティブなシステムであれば、オートスケーリング、マネージドサービスのメンテナンス通知、クラウドコスト管理を追加することもあります。

反対に、小規模なシステムでは、複数の項目を一つの章にまとめることもあります。

重要なのは、テンプレートにシステムを合わせることではありません。システム運用で発生する作業と判断を洗い出し、必要な項目を追加・統合することです。

ここで示した運用設計の項目は、基本設計の段階で方針が決まっていることが前提です。

運転スケジュール、監視、ログ、バックアップ、開局判定の方針を基本設計でどう決めるのか、基盤SEが見ている設計の全体像は、以下の記事で解説しています。

基本設計書の目次と、各章で作成すべき成果物を1つの表で対応させたExcelファイル付きです。運用設計書目次サンプルと2点セットで、設計書の抜け漏れ確認に使えます。

基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程

基本設計は画面設計だけでは終わらない。ログ・バックアップ・ジョブ・監視など、本番運用を見据えた基盤設計の論点を、ファイルアップロードや夜間バッチの実例で整理します。

sys-univ.com

2026.06.20

運用設計は誰がやるのか｜4つの役割と責務分界

システムは構築して終わりではありません。

想定した運用を実行できる状態で運用担当へ引き継いで、初めて開発プロジェクトの役割を果たしたといえます。運用設計では、作業内容だけでなく、誰が実施するのかを明確にする必要があります。

役割は契約形態や組織によって異なりますが、一般的には次のように整理できます。

同じ組織や担当者が複数の役割を兼ねる場合もあります。

大切なのは、組織名ではなく責務を明確にすることです。監視アラートが発生したとき、誰が最初に確認するのか。原因調査は誰へ依頼するのか。業務影響は誰が判断するのか。処理を打ち切るかどうかを誰が承認するのか。

ここが曖昧なままでは、連絡先一覧があっても運用は回りません。

また、すべての作業を自動化すればよいわけでもありません。

頻度が低く、計画時間内に安全に実施できる作業であれば、手動運用を選ぶこともあります。

ただし、手動で行う場合でも、実施者、実施時期、必要な権限、作業手順、正常性の確認方法、作業証跡、異常時の対応、承認・報告方法は設計する必要があります。

自動化するか手動で残すかを、頻度、工数、リスク、ミスの影響、開発・保守コストから判断すること自体が、運用設計の重要な役割です。

まとめ｜運用設計は要件定義から始まっている

運用設計の目的は、システム利用者、運用担当、開発・保守担当、システムオーナーが、それぞれの役割を果たしながら、システムを安定して利用・維持できる状態をつくることです。

運用設計は、運用フェーズに入ってから考えるものではありません。要件定義からすでに始まっており、その骨格は基本設計の段階で決まります。

運転スケジュール、ジョブ、監視、ログ、バックアップ・リストア、起動停止、開局・閉塞、運用日付、異常時運用、エスカレーション、運用スクリプト。

これらの方針は、システム構成や処理方式とセットで具体化する必要があります。

運用設計側が、何をどのように運用したいかを決める。

処理方式設計側が、それをどの仕組みで実現するかを決める。処理方式上の制約が分かれば、運用設計側が運用方法や判断基準を見直す。

この双方向の関係を基本設計で押さえていなければ、詳細設計以降でどれだけ頑張っても、本番直前の

「必要なスクリプトがない」
「ジョブネットが動かない」
「バックアップから戻せない」
「アラート発生後の対応者がいない」
「夜間処理後に業務を開始してよいか判断できない」

は防げません。

運用設計は、運用担当へ仕事を押しつけるための設計ではありません。

本番稼働後に発生する作業、判断、障害、変更を想定し、システムの仕組みとプロジェクト計画へ反映する設計であり、処理方式と運用設計をつなぎ、本番で運用できるシステムを設計することです。

関連記事

運用設計は、単独で完結する工程ではありません。要件定義で決めた内容を基本設計・詳細設計へ落とし込み、さらにテストや運用へつなげていく必要があります。
運用設計の前提となる要件の考え方から、要件定義、基本設計、詳細設計、テストまでのつながりを確認したい方は、以下の記事もあわせてご覧ください。

機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う
要件定義で整理する「機能要件」と「非機能要件」の違いを、実務で使える視点から解説しています。

機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う

「機能が動く」と「本番で使える」は違う。機能要件と非機能要件の違いを、購入申請システムの具体例と現場の失敗パターンから整理します。

sys-univ.com

2026.06.19

要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
RFP・質問回答・提案書・見積前提を起点に、認識差を潰しながらスコープと責任分界を確定する要件定義の実務を解説しています。

要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務

要件定義とは何をする工程なのか。RFP、質問回答、提案書、見積前提から認識差を潰し、スコープや責任分界を確定する実務を、大規模SIの具体的な失敗事例とともに解説します。

sys-univ.com

2026.08.12

基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程
要件定義で決めた内容を、システム全体の構成や方式へ落とし込む基本設計について解説しています。

基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程

基本設計は画面設計だけでは終わらない。ログ・バックアップ・ジョブ・監視など、本番運用を見据えた基盤設計の論点を、ファイルアップロードや夜間バッチの実例で整理します。

sys-univ.com

2026.06.20

詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程
基本設計で決めた方式を、実際に構築できる設定値や設計内容まで具体化する工程を解説しています。

【全3回・第1部】詳細設計とは何を決める工程か｜パラメータ表で終わらせないための設計の考え方

詳細設計とは、基本設計で決めた方式を構築・テスト・運用できる粒度に落とし込む工程です。OS、ミドルウェア、DB、ジョブ、監視、バックアップなどを、単なるパラメータ表ではなく品質保証ストーリーとして設計する考え方を基盤SEの目線で解説します。

sys-univ.com

2026.08.20

Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方
要件定義・基本設計・詳細設計の内容が、後工程のテストとどう対応するのかを整理しています。

Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方

Vモデルは古い開発手法の話ではなく、要件・設計で決めたことをテストで確認する品質保証の考え方です。バックアップ要件の具体例で各工程の対応関係を整理します。

sys-univ.com

2026.07.13

開発工程全体の流れから確認したい方は、以下の記事も参考にしてください。

システム開発の流れを現場目線で理解する【前編】

システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか

システム開発は、アプリケーションだけで成立するものではありません。システム基盤、性能・可用性などの非機能、テスト、移行、運用がどのようにつながって一つのシステムを成立させるのかを、現場目線で整理します。

sys-univ.com

2026.08.26

システム開発の各工程や設計・テスト・運用に関する記事は、以下のカテゴリにまとめています。

システム開発

システム開発に関する開発プロセス、プロジェクトマネージメントの解説

sys-univ.com

システム開発は、要件定義、設計、開発・構築、テスト、移行、運用保守といった工程に分けて進みます。

工程表だけを見ると、それぞれが順番に並んだ独立した作業のように見えるかもしれません。

実際のプロジェクトでは、そうではありません。

要件定義で曖昧なまま残した条件は、設計で判断に迷います。設計で見落とした条件は、テストで問題として表面化します。移行や運用を十分に考えずに作ったシステムは、本番切替や稼働後に手戻りを生みます。

前工程で何を決めたかが、次工程の前提条件になります。

この記事では、要件定義で何を決め、それを基本設計・詳細設計へどう落とし込み、開発・構築したシステムをどのようにテストし、本番へ移行して運用につなげるのかを整理します。

工程の名前を覚えることが目的ではありません。前工程の判断が次工程へどう引き継がれ、どこで認識差や設計漏れが手戻りにつながるのかを、アプリケーションとシステム基盤の両面から見ていきます。

システム開発を、プログラミングだけでなくアプリケーション、システム基盤、非機能まで含めた全体像から整理したい方は、以下の記事も参考にしてください。

システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか

システム開発は、アプリケーションだけで成立するものではありません。システム基盤、性能・可用性などの非機能、テスト、移行、運用がどのようにつながって一つのシステムを成立させるのかを、現場目線で整理します。

sys-univ.com

2026.08.26

要件定義・設計・開発の流れ

要件定義：何を実現し、どの水準で成立させるかを決める

要件定義は、システムで何を実現するのかを具体化し、後続の設計・開発・構築・テストができる状態にする工程です。

ここで決めるのは、画面や業務機能だけではありません。要件は大きく、機能要件と非機能要件に分けて考えます。

機能要件は、利用者から見えるシステムの機能です。

• 申請を登録できる
• 承認・差戻しができる
• 承認履歴を確認できる
• 申請一覧を検索できる

非機能要件は、その機能を本番環境で継続して使うための条件です。

• 平日8時から22時まで利用できる
• 画面応答を原則3秒以内とする
• サーバ1台の障害では業務を停止させない
• 障害発生後1時間以内に復旧する
• バックアップを毎日取得する
• 監視アラートを運用担当へ通知する
• 個人情報を暗号化する
• 本番移行に失敗した場合は旧システムへ切り戻せる

要件定義で注意したいのは、「お客様の要望を聞いて機能一覧を作れば終わり」と考えないことです。

実際の利用部門から出てくるのは、「止まらないようにしてほしい」「普通に使える速度にしてほしい」「障害時は早く戻してほしい」「安全なシステムにしてほしい」といった言葉であることも少なくありません。

これだけでは設計できません。

「止まらない」とは、サーバ1台の障害までなのか、拠点やAZ単位の障害まで考えるのか。「早く復旧」とは10分なのか1時間なのか。「普通の速度」とは画面応答1秒なのか3秒なのか。

曖昧な要求を、設計・試験で確認できる具体的な水準へ落とすことが要件定義です。

ここを曖昧なまま進めると、設計工程だけでなく、テストや本番稼働後まで影響が残ります。

要件定義は白紙から始まるとは限らない

実際のシステム開発では、受注後にゼロから自由に要件を考える案件ばかりではありません。

特に大規模案件では、事前にRFP（提案依頼書）が提示され、必要な機能、外部連携、性能、運用、セキュリティ、移行などの条件がある程度示されています。

ベンダーはRFPを読み、不明点を質問し、必要に応じて前提条件を置いたうえで提案・見積を行います。受注後の要件定義では、それらを起点として、設計・開発できる粒度まで内容を具体化していきます。

たとえばRFPに、次のような記載があったとします。

• 高い可用性を確保すること
• 必要なログを保管すること
• 既存システムと連携すること
• 適切なセキュリティ対策を実施すること

一見すると要件らしく見えますが、このままでは設計できません。

どこまで冗長化するのか。ログを何年間、どこへ保存するのか。外部連携で文字コード変換や異常データの再取込まで必要なのか。セキュリティ対策の対象範囲をどこまで含めるのか。

こうした条件を具体化し、発注者と受注者の認識を合わせていきます。

RFPだけでは現場の実態まで分からない

RFPは重要な出発点ですが、そこに業務や運用のすべてが書かれているとは限りません。

大規模案件では、コンサルティング会社や外部アドバイザーがRFP作成を支援することもあります。文書としてきれいに整理されていても、実際の業務担当者や運用担当者が行っている作業まで完全に反映されているとは限りません。

「既存運用を踏襲する」と書かれていても、月末だけ手作業でデータを補正しているかもしれません。「外部データを取り込む」と書かれていても、実際には文字コード変換、例外データの補正、再取込が必要かもしれません。

要件定義では、RFP、提案内容、見積前提、実際の業務・運用をすり合わせ、後工程で「聞いていない」「想定していなかった」をできるだけ残さない状態まで具体化します。

要件定義の進め方や、RFP・質問回答・提案内容・見積前提との関係については、以下の記事で詳しく整理しています。

要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務

要件定義とは何をする工程なのか。RFP、質問回答、提案書、見積前提から認識差を潰し、スコープや責任分界を確定する実務を、大規模SIの具体的な失敗事例とともに解説します。

sys-univ.com

2026.08.12

基本設計・詳細設計：要件を実装できる形へ落とし込む

要件定義で確定した内容を、実際に作れる形へ変換するのが設計工程です。

基本設計では、利用者から見える仕様とシステム構成の大枠を決めます。

アプリケーション側では、画面レイアウト、入力項目、検索条件、帳票、メール通知、外部システム連携などを設計します。システム基盤側では、Web/AP/DBをどう構成するか、サーバを何台にするか、どこを冗長化するか、ネットワークをどう接続するか、監視やバックアップをどう実現するかといった全体構成を決めます。

ここで重要なのは、アプリケーションとシステム基盤を別々に設計しすぎないことです。

たとえば、「大量のファイルをアップロードできる」という機能を追加するとします。

アプリケーション側ではアップロード処理を実装すれば終わりに見えますが、システム基盤側では、ファイル保存先の容量、通信量、タイムアウト、ウイルスチェック、バックアップ、保管期間、削除方法、ストレージ障害時の扱いまで検討する必要があります。

アプリケーションの要件は基盤設計に影響し、基盤側の制約もアプリケーション設計に影響します。

詳細設計では、基本設計で決めた方針を、実際に開発・構築・テストできる粒度まで具体化します。

アプリケーション側なら、処理ロジック、SQL、API、エラー処理、データ更新条件などです。システム基盤側なら、サーバ名、IPアドレス、CPU、メモリ、ディスク構成、OS設定、ミドルウェア設定、DBパラメータ、ジョブスケジュール、監視閾値、ログ出力先、バックアップ取得時刻、ファイアウォールルールなどに落とし込みます。

詳細設計で初めて決めてはいけないこともある

詳細設計で具体的な値を決めるからといって、その前提条件まで詳細設計で決めればよいわけではありません。

たとえば、ログの保管を考えます。

監査のために7年間必要なのか、障害調査用として数か月あればよいのか。すべてオンラインで検索できる必要があるのか、一定期間を過ぎたら安価なストレージへ退避できるのか。改ざん防止まで求められるのか。

この違いによって、必要なディスク容量、ストレージ性能、バックアップ容量、運用方法、コストは大きく変わります。

RFPに「必要なログを保管すること」とだけ書かれた状態で詳細設計まで進み、後から「監査で7年間必要だった」「すべて検索できる状態で残してほしい」と判明すれば、容量やコストの前提が崩れます。

詳細設計で決めるのは実装値です。その値を決めるための業務要件や非機能要件は、上流工程で明確にしておく必要があります。

基本設計については、以下の記事で詳しく整理しています。

基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程

基本設計は画面設計だけでは終わらない。ログ・バックアップ・ジョブ・監視など、本番運用を見据えた基盤設計の論点を、ファイルアップロードや夜間バッチの実例で整理します。

sys-univ.com

2026.06.20

開発・構築：アプリと基盤を同じゴールへ向けて形にする

設計が固まると、アプリケーション開発とシステム基盤の構築が進みます。

アプリケーション側では、画面、業務ロジック、API、バッチ、SQLなどを実装します。システム基盤側では、設計書に基づいてサーバ、OS、ミドルウェア、DB、ネットワーク、ロードバランサ、監視、バックアップ、ジョブ、セキュリティなどを構築します。

両者は別チームで進むことが多いものの、独立しているわけではありません。アプリケーションが動くためには基盤が必要で、基盤側の結合試験や性能試験には、アプリケーションや疑似アプリケーションが必要になる場合があります。

図　システム開発フローの全体像

アプリケーション側とシステム基盤側では、担当する領域や成果物は異なります。各エンジニアが設計・構築・テストでどのような役割を担うのかについては、以下の記事で詳しく整理しています。

アプリケーションエンジニアの仕事｜決める、そろえる、動かし続ける

アプリケーションエンジニアの仕事内容を、SIerでの実務経験をもとに解説。曖昧な要望を仕様へ変換する設計、画面・帳票・バッチ・API、テスト、性能問題、障害対応まで、担当範囲と責任を具体例で整理します。

sys-univ.com

2026.08.05

システム基盤・クラウドエンジニアの仕事｜整える、保つ、戻す

システム基盤エンジニアの仕事内容を、インフラエンジニアとの違いから実務まで解説。サイジング、標準化、監視、可用性、バックアップ、AWS移行、障害対応を大規模SIの実例を交えて紹介します。

sys-univ.com

2026.08.17

システム開発では、接続先URL、ポート番号、タイムアウト値、ファイル配置先、DB接続情報、ジョブ起動時刻、ログ出力先、文字コードなど、アプリケーションと基盤の境界に多くの調整事項があります。

こうした値を「少し変えるだけ」と考えるのは危険です。

1つの変更が、アプリケーション、基盤、DB、ネットワーク、運用、外部システムのテスト前提に影響することがあります。

仕様や設定を変更するときは、影響範囲を確認し、関係チームと認識を合わせ、必要に応じて変更管理のプロセスを通します。

システム開発では、作る技術だけでなく、変更を管理することも品質を守る仕事です。

テスト・移行・運用保守の流れ

テスト：動くことではなく、本番で使えることを確認する

テストは「バグを見つける作業」だけではありません。

作ったシステムが、要件どおりに動き、本番環境で業務に使える状態になっていることを確認する工程です。

プロジェクトによって名称や切り分けは異なりますが、単体テスト、結合テスト、システムテスト、性能テスト、障害復旧テスト、運用テスト、移行テストなどがあります。

テストでは、まず次の2つの観点を押さえます。

• 機能が正しく動くか
• 本番環境で継続して運用できるか

アプリケーション側では、申請、承認、差戻し、検索、帳票出力などの業務機能を確認します。

システム基盤・非機能の観点では、本番相当のデータ量で性能が出るか、アクセス集中に耐えられるか、サーバ障害時にも業務を継続できるか、DB障害から復旧できるか、バックアップからリストアできるか、監視やジョブの異常を検知して対応できるかを確認します。

特に重要なのは、正常時だけを確認しないことです。

サーバが1台停止したらどうなるのか。DBとの接続が切れたらどうなるのか。夜間ジョブが途中で異常終了したらどこから再開するのか。バックアップから戻したデータの整合性は保たれるのか。

「壊れないか」だけでなく、「壊れたときにどうなるか」を確認することが、本番運用を想定したテストです。

設計とテストの対応関係については、以下の記事で詳しく整理しています。

Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方

Vモデルは古い開発手法の話ではなく、要件・設計で決めたことをテストで確認する品質保証の考え方です。バックアップ要件の具体例で各工程の対応関係を整理します。

sys-univ.com

2026.07.13

運用テスト：手順書と運用ワークフローが本当に回るかを確認する

運用テストは、本番稼働後の作業や手続きが、設計したとおりに実行できるかを確認するテストです。

運用というと、サーバへログインしてコマンドを実行する、ジョブを起動する、ログを見る、といった技術作業を想像しやすいかもしれません。

実際の運用では、その前後に作業申請、承認、関係者への連絡、実施可否判断、証跡取得、異常時のエスカレーションなどがあります。

運用テストでは、たとえば次のような観点を確認します。

• 日次・月次・年次ジョブが前提条件と順序を含めて実行できるか
• 外部システムから受領したデータを所定の手順で取り込めるか
• ジョブ異常や監視アラートを運用担当者が検知し、一次切り分けできるか
• 異常終了後のリスタートポイントと復旧手順が決まっているか
• バックアップ取得だけでなく、実際にリストアできるか
• 定常・臨時作業の申請、承認、実施、証跡取得まで流れるか
• 障害時のエスカレーション先と判断者が明確になっているか
• 夜間・休日でも連絡・承認・判断の流れが成立するか

たとえば、外部システムから月1回ファイルを受領し、夜間バッチで取り込む業務を考えます。

「取込ジョブが正常終了する」だけでは、運用テストとして十分ではありません。

外部システム側の処理完了を確認し、対象ファイルの到着と件数・形式を確認し、取込ジョブを起動する。結果を確認して後続処理へつなぎ、異常があれば運用担当者が検知して復旧する。

個々の機能が動くだけでなく、その前後を含めた一連の運用が成立するかを確認します。

特にジョブネットがあるシステムでは、日次、月次、年次の運用を疑似的に流し、処理順序や前提条件、異常時の復旧まで確認することが重要です。

運用テストを軽視すると、本番稼働後に「システムは動いているのに、運用が回らない」という問題が起きます。

運用テストで確認する内容は、テスト工程になってから考えるものではありません。ジョブ管理、監視、ログ、バックアップ・リストア、起動停止、開局・閉塞、運用日付管理など、本番稼働後にどう運用するかを事前に設計しているからこそ、運用テストで成立性を確認できます。

運用設計で検討する項目や、運用設計書の構成については、以下の記事で目次サンプルとともに整理しています。

運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点

運用設計とは何かをシステム基盤エンジニアの実務目線で解説します。運用設計書の目次サンプルと検討項目一覧を示し、監視・ログ・バックアップ・ジョブ管理、誰がやるのか、要件定義・基本設計との関係、処理方式設計との双方向連携を整理します。

sys-univ.com

2026.08.14

移行：新システムへ切り替えるだけではない

移行は、旧システムから新システムへデータをコピーするだけの工程ではありません。

本番切替では、データ移行以外にも多くの作業を決められた時間内に実施します。

• 旧システムのデータを新システムへ移行する
• ユーザー情報を登録・移行する
• 権限を設定する
• 外部システムとの接続先を切り替える
• DNSやネットワーク経路を切り替える
• ジョブを有効化する
• 監視を開始する
• 旧システムを停止する
• 問い合わせ窓口や運用体制を新システムへ切り替える

移行の難しさは、こうした複数の作業を限られた時間で連携させる必要があり、失敗した場合の業務影響も大きいことにあります。

たとえば、次のような問題が起こります。

• データ移行に想定以上の時間がかかる
• 移行前後で件数や金額が一致しない
• 文字化けやコード変換の問題が発生する
• ユーザーや権限が正しく移行されていない
• 外部システムとの接続が切り替わらない
• 新システムで重大障害が見つかる
• 切り戻し手順が成立しない

移行では、旧システムに蓄積されたデータそのものも大きなリスクになります。

実際の現場では、古いシステムの日付項目に「昭和70年」のような存在しない日付が残っていることもあります。旧システムでは登録できていた値でも、新システムの入力チェックやDB制約では受け付けられないことがあります。

この場合、移行前にデータを補正するのか、変換ルールを設けるのか、移行対象外にするのかを業務担当者と決めなければなりません。

本番移行当日に初めて見つけるのでは遅いため、事前に実データを確認し、存在しない日付、必須項目の空欄、コード値の不整合、桁数オーバー、文字化け、移行前後の件数・金額差異などを洗い出します。

移行とは、旧システムに残っている過去の運用、例外データ、入力ミス、暫定対応を、新システムでどう扱うかまで決める工程です。

設計書だけでなく、実際のデータを見る必要があります。

本番稼働・運用保守：リリース後に設計の結果が見える

本番リリースは開発プロジェクトの大きな節目ですが、システムそのものにとっては運用の開始点です。

本番環境では、テスト環境では再現できなかったことが起きます。想定以上の利用者がアクセスする、データ量が増える、外部システムの応答が遅れる、監視アラートが多発する、夜間バッチが長時間化するといった事象です。

本番稼働直後には初期流動期間を設け、通常より厚い体制で監視、問い合わせ、障害対応を行うことがあります。

その後は運用保守へ移ります。

運用保守では、障害対応、問い合わせ対応、監視、バックアップ・ジョブ確認、パッチ適用、証明書更新、権限変更、性能監視、セキュリティ対応、小規模改修などを継続して行います。

「問題なく動いている」ことを説明できるようにする

運用では、単にシステムが停止していなければよいわけではありません。

月次や週次の運用報告では、システム稼働率、障害件数、アラート件数、バックアップ結果、ジョブ結果、外部データ取込状況、CPU・メモリ・ディスク使用率、問い合わせ件数などを確認します。

「今月も問題ありませんでした」と口頭で伝えるだけではなく、SLAを満たしていることや、システムが正常に運用されていることを数字と記録で示す必要があります。

運用保守には、システムを動かすだけでなく、正常に動いていることを説明できる状態を維持する役割もあります。

キャパシティ管理で将来の変化を見る

運用中は、CPU、メモリ、ディスク、ネットワーク、DB接続数などの利用状況を継続的に確認します。

リソース使用率が増え続けていれば、将来的な性能不足を予測して増強を検討します。クラウド環境でCPUやメモリが長期間ほとんど使われていないのであれば、インスタンスタイプや台数、稼働時間を見直す余地があります。

本番運用で得られた実績は、次の更改や設計変更の重要な入力情報になります。

運用保守は設計品質の答え合わせであり、同時にシステムを継続的に改善していく工程です。

工程をまたいで見るための3つの視点

ここまで各工程を見てきましたが、個々の作業だけを覚えても、プロジェクト全体の動きは見えにくいままです。

工程同士のつながりを見るために、次の3つを意識すると整理しやすくなります。

1. 今どの工程で、何を決めるべきかを見る

要件定義、基本設計、詳細設計、構築、テスト、移行、運用では、判断すべき内容が違います。

会議や設計書を見るときに、「これはどの工程で、何を決めるための話なのか」を意識すると、プロジェクト全体の中で自分の作業を位置づけやすくなります。

2. 自分の担当領域だけで完結させない

アプリケーションの要件は基盤へ影響し、基盤の制約はアプリケーションへ影響します。DB、ネットワーク、運用、外部システムも同じです。

すべての専門技術を自分で実装できる必要はありません。

重要なのは、自分の設計や変更が、隣の領域に何を要求するのかを見ることです。

3. 「動くか」ではなく「本番で使えるか」を考える

機能が動いても、性能が出ない、障害から復旧できない、バックアップから戻せない、運用担当者が対応できないのであれば、本番システムとしては不十分です。

設計やテストで迷ったときは、

「この状態で実際の業務を継続できるか」

と考えると、見るべき論点が見えやすくなります。

まとめ：工程をまたいで見ると、手戻りが起きる理由が分かる

システム開発は、要件定義、設計、開発・構築、テスト、移行、運用保守という工程に分けて進みます。

各工程が独立しているわけではありません。

要件定義で曖昧だった条件は設計で判断に迷い、設計で残した抜けはテストで不具合や手戻りとして表面化します。移行や運用を十分に考えずに作ったシステムは、本番切替や稼働後に問題を残します。

逆に、前工程で決めた内容が次の工程へ正しく引き継がれ、アプリケーション、システム基盤、DB、ネットワーク、運用などの各領域がつながっていれば、問題を早い段階で見つけやすくなります。

すべての技術を一人で深く理解する必要はありません。

まずは、いま何を決めているのか、その判断が次の工程や別の担当領域にどう影響するのかを見ることが重要です。

工程同士のつながりが見えるようになると、会議、設計書、テスト、移行、運用で行っていることが一本の線としてつながります。

それが、システム開発を「自分の担当作業」ではなく、プロジェクト全体として理解するための土台になります。

関連記事

システム開発の各工程や設計・テスト・運用に関する記事は、以下のカテゴリにまとめています。

システム開発

システム開発に関する開発プロセス、プロジェクトマネージメントの解説

sys-univ.com

ある異なるAWSアカウントにある2台のRDS for OracleをDatabase Link（以下、DBリンク）で接続する構成を検討していたときの話です。

一方はAWS KMSによるストレージ暗号化あり、もう一方は暗号化なし。

注：本記事では、KMS暗号化ありのRDS AをDBリンク元、暗号化なしのRDS BをDBリンク先として説明します。NNEではDBリンク元とDBリンク先で設定するパラメータが異なるためです。

クロスアカウントRDS for OracleのDBリンク構成

つまり、A側に作成したDBリンクからBへ接続します。

ここでいう「DBリンクの方向」は接続を開始する方向です。AからBの表をSELECTすれば結果データはBからAへ返るため、DBリンクの向きとデータが流れる向きは同じとは限りません。

最初に疑問だったのは、

「KMSで暗号化されたRDSから、暗号化されていないRDSへDBリンクを張って問題ないのか」

ということでした。

問い合わせでは「データが文字化けしないか」という表現も使いました。しかし今振り返ると、本当に確認したかったのは文字コードの問題ではありません。

ストレージ上で暗号化されたデータがOracle Databaseからどう見え、DBリンクではどの状態で扱われるのか

という疑問でした。

さらに、

• 相手AWSアカウントへKMSキーを共有する必要があるのか
• 別VPC間でDBリンクを成立させるには何が必要なのか

も確認しました。

このとき印象的だったのが、AWSサポートから最初に、

「今回の暗号化とは、RDSのストレージボリューム暗号化という理解でよいか」

という趣旨の確認が入ったことです。

この確認が、今回の記事の本質です。

RDS for Oracleで「暗号化」と言っても、実際には複数のレイヤーがあります。

• AWS KMSによるRDSストレージ暗号化
• Oracle Transparent Data Encryption（TDE）
• Oracle NetのNNE／SSL/TLS
• AWSネットワーク基盤側の通信暗号化

「RDSが暗号化されている」ことと「DBリンク通信が暗号化されている」ことは別の話です。

本記事では、2026年8月時点のAWS公式仕様も確認しながら、この違いを整理します。

結論｜KMSによるRDS暗号化はDBリンクへ引き継がれない

結論から言えば、AWS KMSによるRDSストレージ暗号化が原因で、DBリンクのSELECT結果が暗号文になることはありません。

そもそも、DBリンク先のOracle Databaseがリンク元RDSのKMSキーを使ってデータを復号する仕組みではありません。

AWSサポートからも、KMSによる暗号化はストレージレイヤーで処理され、ストレージから読み出す際には透過的に復号されるため、ストレージ暗号化を原因としてDBリンクのデータが文字化けすることはない、という回答を得ています。

この「ストレージ暗号化を原因として」という限定も重要です。文字コードやOracle Netなど、別の原因による問題まで否定しているわけではありません。

AWS公式でも、RDSの保存時暗号化は基盤ストレージ、ログ、自動バックアップ、Read Replica、スナップショットなどを対象とし、RDSが復号を透過的に処理すると説明されています。

概念的には次の関係です。

KMSによるRDS暗号化とOracle Database／DBリンクの関係

Oracle Database自身が、KMSで暗号化されたストレージブロックを受け取ってKMSキーで復号しているわけではありません。

したがって、DBリンク接続のためにA側のKMSキーをB側AWSアカウントへ共有する必要もありません。

また、AからDBリンク経由でBへデータを書き込んだ場合、A側のストレージ暗号化属性がBへ引き継がれるわけでもありません。Bへ保存されたデータを暗号化するかどうかは、B自身のRDS暗号化設定で決まります。

なお、既存の非暗号化RDS DBインスタンスを、そのまま後から暗号化済みに変更することはできません。暗号化したスナップショットコピーを作成し、そこから新しいDBインスタンスをリストアする必要があります。

つまり、

「必要になったら後から暗号化をONにすればよい」

という設計にはできません。

RDS for Oracleで分けて考える4つの暗号化レイヤー

今回の話は、次の4レイヤーに分けると整理できます。

ポイントは、どれか一つを有効にすれば他のレイヤーまで暗号化されるわけではないことです。

KMS暗号化はどこまでの話なのか｜TDEとの違いとKMSキー共有

Oracle TDEはKMS暗号化とは別物

Oracle Transparent Data Encryption（TDE）は、Oracle Database側でデータを暗号化する仕組みです。

RDSのKMS暗号化がOracleより下のストレージレイヤーで処理されるのに対し、TDEではOracle Databaseがデータを書き込む前に暗号化し、読み出す際に復号します。

RDS for OracleでTDEを利用できるのはOracle Enterprise Edition＋BYOLです。Oracle WalletとTDE master keyはAmazon RDSが管理します。

TDEには設計時に注意すべき制約があります。

AWSではRDS for OracleのTDEをpermanent／persistentなオプションとして扱っており、一度有効にすると無効化できず、TDEを含まないOption Groupへ変更することもできません。TDEを利用するDBスナップショットは共有できません。

つまり、TDEは後から簡単に外せるオプションではありません。

RDS for Oracleには、TDE以外にもオンプレOracleの前提をそのまま持ち込めない制約があります。詳しくは「RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった」で整理しています。

RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ

RDS for Oracleではオンプレ運用の前提が通用しない。Storage-Full、アーカイブログ、SSH不可など、開発中に見えた9つの設計ギャップと代替アプローチを整理します。

sys-univ.com

2026.08.30

また、TDEで保護されたデータも、暗号文のままDBリンクへ流れるわけではありません。Oracleが論理データへ復号した後、Oracle Netへ渡されます。

その先の通信を暗号化するのはNNEまたはSSL/TLSです。

RDSのKMS暗号化 ≠ Oracle TDE ≠ DBリンク通信の暗号化

という関係です。

DBリンク接続ではKMSキー共有は不要

DBリンクでは、各RDSの保存時暗号化は各RDS内で処理されます。

A側OracleがB側のKMSキーを使うわけでも、B側OracleがA側のKMSキーを使うわけでもありません。

したがって、クロスアカウントDBリンクのためにKMSキーを共有する必要はありません。

一方、暗号化されたDBスナップショットそのものを別AWSアカウントへ共有する場合は、KMSキーへのクロスアカウントアクセスが関係します。

AWSアカウントのデフォルトKMSキーで暗号化されたスナップショットはそのまま共有できません。AWS公式では、対象アカウントへアクセスを許可したcustomer managed keyを用意し、そのキーでスナップショットをコピーして共有し、共有先でも自アカウントのKMSキーを指定してコピーする手順が案内されています。

DBリンクとスナップショット共有では、

論理データへアクセスするのか、暗号化されたAWSリソース自体を共有するのか

が違います。

別AWSアカウントのRDS間でDBリンクを成立させる条件

KMSキー共有が不要でも、別AWSアカウントのRDSへそのままDBリンクを張れるわけではありません。

先に、AからBへOracle Netで到達できるネットワークを作る必要があります。

確認順序は、

VPC間接続 → Route → Security Group／NACL → DNS → Oracle Net → Database Link

と考えると分かりやすいです。

AWSサポートからはVPC Peeringが例示されました。AWS公式のRDS for Oracle DBリンク手順でも、同一VPCまたはピア接続されたVPC間で、有効なルート、ACL、Security Group、名前解決を確認するよう案内されています。

ただし、Database LinkというOracle機能自体がVPC Peeringを要求しているわけではありません。

本質的な要件は、DBリンク元からDBリンク先のRDS endpointとOracle Listenerポートへ到達できることです。

本記事ではAをDBリンク元としているため、基本となる通信方向は、

• A側：Bへのoutbound
• B側：AからOracle Listenerポートへのinbound

です。

Security Groupはstatefulなので、戻り通信のためだけに対称のinboundルールを追加する必要はありません。一方、Network ACLを独自に制限している場合はstatelessなので、復路も確認します。

接続先にはIPアドレスを固定せず、RDS endpointのDNS名を使用します。RDS自身も、基盤IPはフェイルオーバー等で変わり得るため、DNS名を利用することを推奨しています。

別VPCの場合はDNSも確認します。

VPC Peering越しでAmazon提供DNSを利用する場合は、VPC側のenableDnsSupportと、Peering接続側のDNS解決サポートを確認します。カスタムDNSを利用している場合は、そのDNSサーバーがDBリンク先を解決できる必要があります。

つまり、

Routeがある／SGが通る／DNSが引ける

を分けて確認する必要があります。

DBリンク通信の暗号化はKMSとは別に構成する｜NNEの設計

DBリンクのOracle Net通信を暗号化する方法の一つがNative Network Encryption（NNE）です。

RDS for Oracleでは、Option GroupへNATIVE_NETWORK_ENCRYPTIONを追加して利用します。NNEはOracle Databaseの全エディションで利用できます。

ここで重要なのは、

NNEオプションを追加しただけで「暗号化を必須にした」と考えてはいけない

ことです。

DBリンク元RDSはOracle Net clientになる

本記事の構成では、

• A：DBリンク元 → Oracle Net client
• B：DBリンク先 → Oracle Net server

です。

AWS公式も、DBインスタンスがDatabase Linkを利用するとき、そのDBインスタンスはクライアントとして動作すると明記しています。

したがって主に確認するのは、

A側：

SQLNET.*CLIENT

B側：

SQLNET.*SERVER

です。

Requestedは「必須」ではない

RDSのNNE Optionでは、SQLNET.ENCRYPTION_CLIENTとSQLNET.ENCRYPTION_SERVERの既定値はいずれもRequestedです。

ただし、この既定値はNNEオプションを追加した後の話です。NNEオプションを追加していないRDSが、最初からNNEで通信しているという意味ではありません。

また、Requestedだから暗号化されないという意味でもありません。

CLIENT／SERVERともにRequestedで双方がNNEを利用できれば暗号化は成立します。

問題は、相手が暗号化に対応しなくても、暗号化なしで接続できる場合があることです。

つまり、

「暗号化されることがある」と「暗号化を必須条件として保証する」は別です。

AからBへのDBリンクについて暗号化を必須にしたい場合、A側を例えば、

SQLNET.ENCRYPTION_CLIENT=Required

とします。

B側がRequestedでも、接続が成立すれば暗号化されます。暗号化条件を満たせなければ接続自体が失敗します。

一方、B側を、

SQLNET.ENCRYPTION_SERVER=Required

とすると、DBリンクだけでなくBへ接続する他のOracle Netクライアントにも暗号化を要求します。

したがって、

DBリンクだけを暗号化したいのか、RDSへの全接続を暗号化したいのか

を分けて設計します。

Requiredだけでなく暗号方式も確認する

さらに注意したいのが暗号アルゴリズムです。

Oracle Database 19cなどのRDS NNE設定では、既定候補にAESだけでなくRC4、3DES、DESも含まれ、既定リストはRC4_256から始まります。AWSはDES、3DES、RC4をsecure encryption methodとは扱っていません。

そのため、

SQLNET.ENCRYPTION_CLIENT=Required

だけでは、使用する暗号方式まで安全なものへ限定したことにはなりません。

例えばAES256へ限定する設計なら、

A側：

SQLNET.ENCRYPTION_CLIENT=Required
SQLNET.ENCRYPTION_TYPES_CLIENT=AES256

B側：

SQLNET.ENCRYPTION_SERVER=Requested または Required
SQLNET.ENCRYPTION_TYPES_SERVER=AES256

のように、CLIENT／SERVER双方で共通する方式を設定します。

SQLNET.ALLOW_WEAK_CRYPTOとSQLNET.ALLOW_WEAK_CRYPTO_CLIENTSはいずれも既定値がTRUEです。弱い方式を禁止する場合はこちらも確認しますが、既存クライアントのパッチレベルや互換性へ影響するため、接続元を確認した上で変更する必要があります。

暗号化と整合性チェックは別設定

NNEでは、通信の暗号化とは別にデータ改ざんを検知するチェックサムも設定できます。

SQLNET.ENCRYPTION_*をRequiredにしても、SQLNET.CRYPTO_CHECKSUM_*が自動的にRequiredになるわけではありません。

盗聴対策と改ざん検知は別々に設計する必要があります。

「暗号化されているか」だけでなく方式まで確認する

設定後はV$SESSION_CONNECT_INFOを確認し、実際にネゴシエーションされた暗号方式を確認できます。

SELECT NETWORK_SERVICE_BANNER
FROM V$SESSION_CONNECT_INFO
WHERE SID = SYS_CONTEXT('USERENV', 'SID');

NNEが有効ならencryption service adapterを含む行が表示され、AES256など実際にネゴシエーションされた方式を確認できます。

見るべきなのは、

「暗号化されているか」だけではなく「何で暗号化されているか」

です。

既定候補にはRC4_256も含まれるため、AES256など設計時に想定した方式が実際に使われているところまで確認する必要があります。

なお、DBリンクによって生成されたリモートセッションをどのように特定し、証跡化するかについては、DBリンク固有の実機確認が必要です。

RDS間DBリンクはSSL/TLSでも暗号化できる

DBリンクの暗号化方式はNNEだけではありません。

AWS公式には、Oracle DBインスタンス間では、各インスタンスにOracle SSLオプションが構成されていれば、SSL/TLS endpoint経由でDatabase Linkを確立でき、追加構成は不要と明記されています。

つまり、本記事のA→B構成でも、両RDS for OracleへSSLオプションを設定することでDBリンク通信をTLS化できます。

SSLオプションを入れただけでは全通信TLSにはならない

RDS for Oracleでは、SSL接続用に通常接続とは別の第2ポートを利用します。

そのため、

• 通常ポート：非SSL通信
• SSLポート：SSL/TLS通信

を同じDBインスタンスで併存できます。

つまり、SSLオプションを追加しただけでは、そのRDSへの全通信がTLS必須になるわけではありません。

TLSを必須にする場合は、SSL/TLS endpointを利用することに加えて、Security Group等で非SSL経路を許可していないかも確認する必要があります。

NNEはOracle NetのネゴシエーションでRequiredを使って強制し、TLSはポートと接続経路で強制するという違いがあります。

TLSバージョンとCipher Suiteも確認する

2026年8月時点で、RDS for Oracleの19c／21cはTLS 1.0と1.2をサポートしています。

特に既存のOracle SSLオプションでは、SQLNET.SSL_VERSIONが自動的に1.0へ設定されています。既存環境では「SSLを使っている＝TLS 1.2」と判断せず、設定値を確認する必要があります。26aiではTLS 1.2のみがサポートされています。

Cipher Suiteも同様です。

19c／21cの既定Cipher SuiteであるSSL_RSA_WITH_AES_256_CBC_SHAはFIPS対応ですが、AWS公式表ではFedRAMP準拠ではありません。つまり、既定値のままで自分たちのセキュリティ要件を満たすとは限りません。

また、RDS for OracleではRSA証明書とECDSA証明書をサポートしており、SQLNET.CIPHER_SUITEへ指定する方式はDBインスタンスの証明書タイプと互換である必要があります。互換性のないCipher Suiteしか設定していないOption GroupはDBインスタンスへの関連付けに失敗します。

NNEとSSL/TLSは併用できない

NNEとSSL/TLSは、同じRDS for Oracle DBインスタンスで併用できません。

したがって、

NNEで暗号化した上にTLSを重ねる

という構成にはできません。

どちらを採用するかは、既存の接続方式、証明書管理、接続クライアント、セキュリティ基準から判断します。

重要なのは、

KMSによるRDS暗号化とは別に、Oracle Net通信の暗号化方式を選ぶ

ことです。

AWS基盤側の通信暗号化とOracle Net暗号化は分けて考える

AWSネットワーク基盤側にも通信暗号化の仕組みがあります。

Amazon RDSでは、一部のインスタンスタイプについてNitro Systemによるインスタンス間通信の自動暗号化が提供されています。ただし、対象インスタンスタイプ、同一Region、同一VPCまたはVPC Peering、Transit Gateway等の仮想ネットワークサービスを経由しないことなどの条件があります。

RDS for Oracleでは、Oracleで利用可能なインスタンスクラスと、Nitroによる自動暗号化の対象一覧を別々に確認する必要があります。

例えば、RDS全体の自動暗号化対象一覧に含まれるM7g／R7gはRDS for Oracleの利用可能クラスには含まれていません。一方、RDS for Oracleで利用可能なM7i／R7i／M8i／R8iは、2026年8月時点の自動暗号化対象一覧には列挙されていません。

したがって、「新しい世代だから自動的に暗号化される」とは判断できません。

さらに2025年11月にはVPC Encryption Controlsが追加され、AWS基盤側の転送時暗号化をMonitor／Enforceで監視・強制できるようになりました。RDS公式でも、Enforce VPCでは転送時暗号化をサポートするNitroベースのDBインスタンスのみ新規プロビジョニングできるとされています。既存VPCをEnforceへ移行する際は、まずMonitorで非準拠リソースを確認・是正する必要があります。

VPC Encryption ControlsのMonitor／Enforceの違い、Flow Logsのencryption-statusの読み方、ExclusionやTransit Gatewayを含むEnforce移行時の注意点は、「VPC Encryption Controlsとは｜Monitor／EnforceとFlow Logsの読み方」で整理しています。

VPC Encryption Controlsの落とし穴｜Flow Logsの暗号化判定とEnforce判定は別物

VPC Encryption Controlsでは、Flow Logsで暗号化と表示されてもEnforceで許可されるとは限りません。encryption-statusと準拠判定の違い、既存Flow Logsにフィールドが自動追加されない点、ExclusionやTGWの注意点をAWS公式仕様から整理します。

sys-univ.com

2026.08.27

ただし、ここでDBリンクの記事として重要なのは、AWS基盤側の証跡とOracle Net側の証跡は同じではないことです。

VPC Flow Logsではencryption-statusとして、

• 0：not encrypted
• 1：nitro-encrypted
• 2：application-encrypted
• 3：両方
• -：状態不明、またはVPC Encryption Controlsが無効

を記録できます。

ただしAWSがapplication-encryptedとして認識する通信は限定されています。interface endpointやgateway endpointについては、AWS自身がパケット内容ではなく使用ポートから暗号化状態を推定していると説明しています。

したがって、

Flow Logsが1: nitro-encryptedだから、Oracle NetもNNE/TLSで暗号化されている

とは言えません。

逆に、Oracle NetをNNEで暗号化していても、Flow Logsがそれをapplication-encryptedとして認識するとは限りません。Nitro暗号化も適用されない経路では、Flow Logs側で0: not encryptedと評価される可能性があります。

つまり、

一方のレイヤーの証跡だけで、もう一方の暗号化状態を証明も否定もできません。

VPC Flow Logsが答えるのは、

「AWS基盤から見て、このフローをどの暗号化状態として扱っているか」

です。

NNEでV$SESSION_CONNECT_INFOから確認するのは、

「このOracle Netセッションで、どの暗号方式がネゴシエーションされたか」

です。

対象も粒度も異なります。

まとめ｜「暗号化されているか」ではなく「どのレイヤーか」で考える

今回の疑問は、

KMSで暗号化したRDS for Oracleと、暗号化されていない別AWSアカウントのRDSをDBリンクで接続するとどうなるのか

というところから始まりました。

結論は3つです。

• KMSによるRDS暗号化は保存時の暗号化であり、暗号化属性やKMSキーがDBリンク先へ伝播するわけではない
• DBリンクのOracle Net通信を暗号化するなら、NNEまたはSSL/TLSを別途設計する
• AWS基盤側の暗号化とOracle Net暗号化は別レイヤーであり、一方の証跡だけでもう一方を証明・否定できない

設計時に確認するべきなのは、

「暗号化されているか、いないか」

という二択ではありません。

「どのデータを、どのレイヤーで、どの仕組みによって暗号化し、それをどの方法で確認するのか」

まで分けて考える必要があります。

今回AWSサポートが問い合わせの冒頭で、

「今回の暗号化とは、RDSのストレージボリューム暗号化という理解でよいか」

という趣旨の確認をしてきた理由も、ここにあります。

KMS、TDE、Oracle Net、AWSネットワーク基盤。

すべて「暗号化」ですが、守っている場所も確認方法も異なります。

RDS for OracleでDBリンクを設計するときは、まずこの境界を分けるところから始めるのがよいでしょう。

関連記事

RDS for Oracleでは、暗号化以外にもオンプレミスOracleの前提をそのまま持ち込めない制約があります。また、こうしたクラウド固有の差異は、構築段階ではなく要件定義や基本設計の段階で確認しておくことが重要です。あわせて確認したい方は、以下の記事も参考にしてください。

• RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった
  SYS権限やOSアクセス、ログ確認など、オンプレミスOracleからRDS for Oracleへ移行するときに変わる運用・設計上の前提を、実案件で直面した制約から整理しています。

RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ

RDS for Oracleではオンプレ運用の前提が通用しない。Storage-Full、アーカイブログ、SSH不可など、開発中に見えた9つの設計ギャップと代替アプローチを整理します。

sys-univ.com

2026.08.30

• 基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程
  サーバー、データベース、ネットワーク、セキュリティ、監視、バックアップ、運用など、システム基盤の基本設計で何を決めておくべきかを整理しています。

基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程

基本設計は画面設計だけでは終わらない。ログ・バックアップ・ジョブ・監視など、本番運用を見据えた基盤設計の論点を、ファイルアップロードや夜間バッチの実例で整理します。

sys-univ.com

2026.06.20

セキュリティグループも見た。
NACLも見た。
VPCルートテーブルも見た。

それでも通信できない。

そんなとき、原因はAWSコンソールの中ではなく、OSの中にあるかもしれません。

今回扱うのは、EC2を別AZで起動した際に、Windows ServerのOS内ルート情報が更新されず、通信できなくなった事象です。

この記事では、単なるルート設定の話ではなく、EC2Launch、User Data、AMI再利用、DR設計で見落としやすい「起動後のOS状態」について整理します。

EC2は起動した。でも通信できない

EC2インスタンスを別AZで起動した。

インスタンスの起動は成功している。
OSも上がっている。
しかし、通信できない。

このような事象が起きると、まずAWS側の設定を疑うと思います。

セキュリティグループがおかしいのか。
NACLで止められているのか。
サブネットのルートテーブルが間違っているのか。

もちろん、それらは確認すべきです。

しかし、今回の原因はそこではありませんでした。

問題は、Windows OS内のルーティング情報が、移動先AZに合わせて更新されていなかったことでした。

AZ移動後、Windowsサーバが通信できない

今回の事象は、AZ障害時の切替を想定した環境で発生しました。

通常時は、あるAZでWindows ServerのEC2インスタンスを稼働させています。

障害時には、別AZでインスタンスを起動し、業務を継続する想定でした。

構成としては、クラウドではよくある考え方です。

図　別AZでEC2を起動できても、起動後に通信できるとは限らない

ただし、この構成で注意すべきなのは、「別AZでEC2が起動できること」と「起動後に業務通信が成立すること」は別問題だという点です。

今回も、インスタンスの起動自体は成功していました。

OSも起動していました。

ところが、正常なネットワーク通信ができませんでした。

AWS側の設定だけを見れば、サブネット、セキュリティグループ、NACL、VPCルートテーブルを疑いたくなります。

しかし、調査していくと、問題はWindows OS内部のルーティング情報にありました。

移動先AZで必要となるルート情報が、OS起動時に追加されていなかったのです。

ここで重要なのは、VPCのルートテーブルではなく、Windows OS内のルート情報だという点です。

では、なぜOS内にルート情報が必要になるのでしょうか。

たとえば、次のような構成を考えてみます。

通常の業務通信は、デフォルトゲートウェイから出す。
一方で、監視サーバ向けのセグメント 172.16.10.0/24 には、2枚目のNIC、つまり別ENI側の経路を使って通信させる。

この場合、Windows OS内には、

172.16.10.0/24 は、2枚目のNIC側の経路へ向ける

VPCルートテーブルが正しくても、Windows OS内にこのルートがなければ、監視サーバ向けの通信は期待した経路に流れません。

EC2はクラウド上の仮想サーバです。

しかし、サーバである以上、OSの中にもネットワーク設定があります。

クラウド側の設定だけでは、通信は完結しません。

さらに、別AZで起動すると、通常は起動先のサブネットも変わります。

サブネットやENI構成が変われば、OS内のスタティックルートで前提にしていたネクストホップ（次に経由するルーターやゲートウェイのIPアドレス）　　やインターフェースが、移動先の環境と合わなくなることがあります。

しかし、AMIを取得した時点のOS内ルート情報には、旧環境を前提にした経路が残っている場合があります。

そのまま別AZで起動すると、ルートのエントリは存在しているのに、実際には期待した経路へ到達できない。

これが、

「設定した覚えはあるのに通信できない」

という事象の正体です。

原因はEC2Launchの起動時処理だった

原因は、Windows Serverの起動時に動く初期化処理でした。

Windows Server 2012 R2以前では、EC2Configというサービスが使われていました。

一方、Windows Server 2016 / 2019では、EC2Launch v1が使われる構成があります。

ここで見落としやすいのは、

「Windows Serverなら、起動時に毎回同じ初期化処理が走る」

とは限らないことです。

今回のポイントはここです。

AMIを取得する前のインスタンスで、すでに初回起動時の処理が終わっている。
その状態をAMIとして固める。
そのAMIから別AZで起動する。
しかし、OSや初期化エージェントの状態としては、必要な処理が「初回起動時のみ実行済み」と扱われる。
その結果、別AZで起動したときに、ルート追加処理が走らない。

このような流れになると、EC2自体は起動しているのに、OS内のルート情報が移動先AZに合わないまま残ります。

その結果、サーバは起動したのに通信できない、という状態になります。

若手SEがここで学ぶべきなのは、OSの設定そのものだけではありません。

「その設定は、いつ、どの仕組みによって入るのか」

を見る必要があるということです。

EC2Config、EC2Launch v1、EC2Launch v2をざっくり押さえる

細かい仕様をすべて暗記する必要はありません。

ただ、Windows EC2の初期化エージェントには世代差があることは押さえておくべきです。

Windows Server 2012 R2以前
  → EC2Config

Windows Server 2016 / 2019の一部AMI
  → EC2Launch v1

Windows Server 2022 / 2025、
一部のWindows Server 2016 / 2019 AMI
  → EC2Launch v2

EC2Launch v2では、「どのタスクを、どのステージで、どの頻度で実行するか」を管理する考え方になります。

見るべきポイントは、バージョン名そのものではありません。

実務では、以下を確認します。

・対象OSは何か
・EC2Config、EC2Launch v1、EC2Launch v2のどれか
・User Dataは初回だけか、毎回か
・起動時タスクは有効か
・タスクの実行頻度は once か always か
・初期化処理のログにエラーは出ていないか

ここを確認しないままDR設計や移行設計を進めると、机上では成立しているのに、切替時に通信できないサーバが立ち上がることがあります。

なお、EC2Launch v2には agent-config.yml などの設定ファイルがありますが、この記事では詳細な設定手順までは踏み込みません。

ここで重要なのは、ファイル名を暗記することではなく、起動時に実行されるタスクと実行頻度を確認する、という考え方です。

なぜ永続ルートではなく、起動ごとの処理なのか

ここで、こう思う人もいるかもしれません。

「Windowsなら route add -p で永続ルートにすればよいのでは？」

たしかに、固定的な経路であれば、それで済む場合もあります。

route add -p は、Windowsで再起動後も残るルートを登録する方法です。

しかし、クラウド移行やAZ切替では、単純な永続ルートだけでは不十分な場合があります。

なぜなら、起動先のAZ、サブネット、ENI構成、ゲートウェイ、経路設計によって、追加すべきルートが変わることがあるからです。

AMIに固定ルートを焼き込んでしまうと、元のAZでは正しくても、別AZでは古い経路を引きずる可能性があります。

たとえば、元の環境では `10.0.1.1` 側を通る前提でOS内にルートを持っていたとします。

しかし、別AZで起動した後は、サブネットやENI構成が変わり、`10.0.2.1` 側を通すべき構成になっているかもしれません。

このとき、OS内に旧環境のルートが残ったままだと、設定は存在しているのに、移動先環境では正しい経路に通信が流れません。

一方、起動ごとのスクリプトでルートを追加する方式なら、起動先の環境に合わせて必要なルートを入れ直す設計にできます。

もちろん、その分だけスクリプト設計は慎重に行う必要があります。

特に重要なのが、冪等性です。

冪等性とは「同じ処理を何度実行しても、結果が壊れず同じ状態に収まる性質のこと」です。

起動のたびに実行される処理は、何度実行しても壊れないように作る必要があります。

たとえば、同じルートを毎回追加しようとしてエラーになる。
既存設定を無条件で上書きしてしまう。
途中で失敗したときに中途半端な状態が残る。

こうした作りになっていると、初期化処理そのものが新しい障害原因になります。

対策は「OS起動ごとに必要な処理を実行させる」こと

今回の対策は、OS起動ごとに必要なルート追加処理が実行されるようにすることでした。

EC2Launch v1の場合、単に「起動すれば自動で全部整う」と考えるのではなく、起動時に必要な処理が実行される状態になっているかを確認する必要があります。

たとえば、今回のようなルート追加であれば、User DataからEC2Launchのモジュールを読み込み、`Add-Routes` を呼び出す方法があります。

Import-Module (Join-Path $env:ProgramData 'Amazon\EC2-Windows\Launch\Module\Ec2Launch.psd1')
Add-Routes

<persist>true</persist>

重要なのは、コマンドそのものを暗記することではありません。

タスクスケジューラ、User Data、EC2Launchのどの仕組みによって、起動時の処理を実行させているのかを理解することです。

EC2Launch v2では、この種の起動時タスクの扱いが整理されており、同じ問題が起きにくい構成になっています。

ただし、実際の挙動は、AMIの世代、EC2Launchのバージョン、User Data、タスクの実行頻度に依存します。

そのため、v2だから確認不要、とは考えない方が安全です。

環境によって確認ポイントは変わります。

しかし、共通する考え方は同じです。

「起動時に、必要なOS設定が、確実に反映される状態になっているか」

ここを確認する必要があります。

AWS側の設定だけ見ても足りない

若手SEにとって、EC2の通信不可というと、どうしてもAWS側の設定に目が行きます。

それ自体は間違いではありません。

実際、通信不可の原因として、セキュリティグループ、NACL、VPCルートテーブル、サブネット、ENI、DNS設定などはよくあります。

しかし、それだけでは足りません。

今回のように、OS内部の設定が原因になることもあります。

今回の切り分けは、3つの層で見ると整理しやすくなります。

AWSインフラ層
  → セキュリティグループ、NACL、VPCルートテーブルを見る

初期化エージェント層
  → EC2LaunchやUser Dataが期待どおり実行されたかを見る

OS設定層
  → Windowsのルーティングテーブルが移動先環境に合っているかを見る

EC2の通信確認では、AWS側の設定、クラウド初期化処理、OS内部の設定を一連の流れとして見る必要があります。

図　AWS側の設定だけ見ても足りない

この図で言いたいのは、EC2が起動した時点で確認が終わるわけではない、ということです。

AWS側の設定が正しく、インスタンスが起動していても、その後に動く初期化処理やOS内部の設定が想定どおりでなければ、業務通信は成立しません。

サーバが起動していることと、業務通信が成立していることは別です。

ここを混同すると、DRテストや移行リハーサルで痛い目を見ます。

これはルーティングだけの話ではない

今回の事象は、Windows Serverのルーティング情報が更新されなかった、という個別トラブルに見えます。

しかし、これはルーティングだけの話ではありません。

以前扱ったような、MTU設定が戻る、SSHでログインできない、OS起動後に想定した設定になっていない、といった事象にも共通する構造があります。

共通しているのは、初期化エージェントがOS設定を書き換える、または書き換えないことで、起動後のOS状態が想定とずれる点です。

ある設定は、初期化エージェントによって上書きされます。

別の設定は、初期化エージェントが実行されないために更新されません。

つまり、

「書き換えられて困る」

場合もあれば、

「書き換えてほしいのに書き換わらない」

場合もあります。

どちらも、クラウド初期化処理がOS設定に関与していることを理解していないと、原因にたどり着きにくくなります。

なぜクラウドはOS設定を書き換えるのか

では、なぜクラウド環境では、起動時にOS設定へ手を入れるのでしょうか。

理由は大きく3つあります。

1つ目は、セキュリティです。

クラウド環境では、インターネットや社内ネットワークから到達可能なサーバを短時間で作成できます。

そのため、初期状態をできるだけ安全側に寄せる必要があります。

SSHのパスワード認証を無効にし、公開鍵認証を前提にするような考え方は、その典型です。

パスワード総当たり攻撃の入口を減らすためです。

これは、クラウド環境におけるベストプラクティスに寄せた挙動と考えると理解しやすいです。

2つ目は、クラウド環境に合わせてOSを自動適応させるためです。

EC2インスタンスは、起動時にインスタンスメタデータ、User Data、ネットワーク情報などを利用します。

OSは、起動した場所、割り当てられたIP、ホスト名、初期化スクリプトなどをもとに、クラウド上で動ける状態に整えられます。

3つ目は、AMIを再利用するためです。

AMIは、ある時点のOS状態を固めたものです。

しかし、そのAMIから起動されるインスタンスは、元の環境と同じとは限りません。

別AZかもしれません。
別サブネットかもしれません。
別IPかもしれません。
別用途のサーバとして起動されるかもしれません。

そのため、AMIに残っているOS設定をそのまま信じるだけでは危険です。

クラウドでは、起動時にメタデータやUser Dataを参照し、起動先の環境に合わせて初期化する仕組みが用意されています。

ただし、その初期化処理が「いつ」「どの条件で」「何を」実行するかは、OS、エージェント、設定によって変わります。

ここを理解していないと、

設定したはずなのに戻った
自動で入ると思っていたのに入らなかった
AMIから起動したら前の状態を引きずった

DR設計では「起動できる」だけでは足りない

今回の話は、DR設計やAZ障害時の切替設計にも直結します。

DR設計では、次のような確認をしがちです。

・別AZでEC2が起動できる
・AMIからインスタンスを作成できる
・EBSを付け替えられる
・IPやDNSを切り替えられる

しかし、これだけでは不十分です。

本当に確認すべきなのは、起動後に業務通信が成立するかです。

実務では、少なくとも以下を確認した方がよいです。

・OS内のルート情報は正しいか
・DNS名前解決はできるか
・ADや認証基盤へ到達できるか
・業務アプリの接続先へ通信できるか
・監視、バックアップ、ジョブ管理エージェントは動くか
・User Dataや起動時スクリプトは期待どおり実行されたか
・初期化処理のログにエラーは出ていないか

業務として使える状態になったかどうかです。

ここを間違えると、テストでは成功したように見えても、本番障害時に通信できないサーバが立ち上がることになります。

まとめ

今回は、EC2を別AZで起動した際に、Windows Serverのルーティング情報が更新されず、通信できなくなった事象を扱いました。

原因は、AWS側のセキュリティグループやVPCルートテーブルではなく、OS内部のルート情報でした。

そして、その背景には、EC2Config、EC2Launch、EC2Launch v2といったクラウド初期化エージェントの挙動差がありました。

クラウドでは、サーバを起動するだけなら簡単です。

しかし、起動したサーバが業務として使える状態になっているかは、別の問題です。

若手SEは、EC2が起動したかどうかだけで安心してはいけません。

見るべきなのは、起動後に、どの設定が、どのタイミングで、どの仕組みによって反映されるのかです。

サーバは起動した。
でも通信できない。

その原因は、AWS側ではなく、OSの中にあるかもしれません。

関連記事

今回のようなトラブルは、AWSやOSの設定だけを個別に見るのではなく、切替後にシステム全体が業務として使える状態になっているかまで確認する必要があります。

システム基盤・クラウドエンジニアの仕事
サーバー、OS、監視、バックアップ、可用性、クラウドなどを横断し、
システムを「整える・保つ・戻す」ための基盤設計・運用・障害対応を解説しています。

システム基盤・クラウドエンジニアの仕事｜整える、保つ、戻す

システム基盤エンジニアの仕事内容を、インフラエンジニアとの違いから実務まで解説。サイジング、標準化、監視、可用性、バックアップ、AWS移行、障害対応を大規模SIの実例を交えて紹介します。

sys-univ.com

2026.08.17

詳細設計とは何を決める工程か｜パラメータ表で終わらせないための設計の考え方
基本設計で決めた内容を、構築・テスト・運用できる具体的な設定や手順へどう落とし込むかを整理しています。

【全3回・第1部】詳細設計とは何を決める工程か｜パラメータ表で終わらせないための設計の考え方

詳細設計とは、基本設計で決めた方式を構築・テスト・運用できる粒度に落とし込む工程です。OS、ミドルウェア、DB、ジョブ、監視、バックアップなどを、単なるパラメータ表ではなく品質保証ストーリーとして設計する考え方を基盤SEの目線で解説します。

sys-univ.com

2026.08.20

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

実務で使えるシステム開発方法論｜ナギ ＠ 氷河期SEの知見録｜note

要件定義、基本設計、詳細設計、テスト、移行、運用保守まで、システム開発の流れを実務目線で体系化するマガジンです。教科書には書かれにくい、設計漏れ、手戻り、品質保証、運用で詰まるポイントを、現場経験に基づいて整理します。若手SEだけでなく、開発プロセスを改めて見直したい中堅・ベテランSEにも向けた内容です。

note.com

本シリーズでは、システム監視を「何を、どのように監視し、検知後の対応につなげるか」という観点から、前編・後編に分けて整理しています。

• 【第1部】この記事
  システム監視の基本構造／死活監視／エージェント監視・エージェントレス監視／SNMP監視／MIB・OIDなど、監視を理解するための基礎
• 【第2部】クラウド監視と「運用で使える監視設計」
  AWS CloudWatch・OCI Monitoring／既存監視のFit & Gap／監視対象・閾値・通知・一次対応まで含めた監視設計

はじめに

システム開発や基盤設計に関わっていると、「監視」という言葉は必ず出てきます。

「サーバは生きています。 `ping` は通っています」

そう報告した10分後に、業務が止まった。

原因は、Webサーバのプロセス停止だった。

サーバ自体にはネットワーク的に到達できていたため、 `ping` 監視では異常を検知できなかった。

答えは単純です。 `ping` が通ることと、システムが業務として使える状態であることは、まったく別の話だからです。

死活監視。リソース監視。ログ監視。プロセス監視。ジョブ監視。URL監視。SNMP監視。

言葉としては聞いたことがあっても、実際に「監視の仕組み」を説明しようとすると、意外と難しいものです。

若手SEの中には、監視を「サーバが落ちたらアラートが出る仕組み」「CPUやメモリが高くなったら通知する仕組み」「ログにエラーが出たらメールが飛ぶ仕組み」と理解している人もいます。

もちろん、間違いではありません。

ただし、それだけでは監視設計はできません。

監視では、何を監視するのか、どこから監視するのか、どの方式で監視するのか、どの条件で異常と判断するのか、誰に通知するのか、通知を受けた人が何を確認するのかまで決める必要があります。

監視とは、単にアラートを出す仕組みではありません。

システムの異常や異常予兆を、運用で対応できる形で検知する仕組みです。

前編では、監視サーバー、監視対象サーバー、死活監視、エージェント監視、エージェントレス監視、SNMP監視、MIB/OIDの基本を整理します。

監視を「設定」ではなく「運用で使える仕組み」として理解するために、まずは基本構造から見ていきます。

システム監視とは何か

監視をしていなければ、障害が起きても運用側は気づけません。

利用者から「画面が開かない」と問い合わせが来て、初めて障害を認識する。これは運用の失敗です。

システムが正常に稼働しているか。障害の予兆がないか。それを運用で対応できる形で検知する仕組みです。

システム監視の目的は、大きく2つあります。

• システムが正常に稼働しているかを確認する
• システムに障害予兆となる兆候がないかを確認する

業務システムでは、障害そのものを完全にゼロにすることはできません。

だからこそ、障害が発生したときに早く気づく。
影響範囲を把握する。
一次対応につなげる。
必要に応じてエスカレーションする。

そのために監視があります。

監視には「監視する側」と「監視される側」がある

まず押さえるべき基本は、監視には「監視する側」と「監視される側」があるということです。

一般的なオンプレミスや仮想基盤の監視構成では、次のような役割があります。

• 監視サーバー
• 監視マネージャー
• 監視対象サーバー
• 監視エージェント
• 運用端末
• 通知先

監視サーバー、または監視マネージャーは、監視する側です。

監視対象サーバーは、監視される側です。

Webサーバ、APサーバ、DBサーバ、ジョブ管理サーバ、ストレージ、ネットワーク機器などが該当します。

監視サーバーは、監視対象に対して定期的に確認を行います。

たとえば、Web/APサーバとの通信状況、DBサーバのCPU負荷、共有ストレージのディスク容量、ログの異常メッセージなどを収集し、異常があれば運用者や管理者へ通知します。

　　　　　　　　　　　　　　　　　　図：監視サーバーと監視対象サーバー・機器の関係

ここで重要なのは、監視は「何となく全体を見ている」のではないということです。

監視対象ごとに、何を、どの方式で、どの周期で、どの閾値で、どの通知先へ送るかを細かく決めています。

前編では、まず代表的な監視方式として、死活監視、エージェント監視、エージェントレス監視、SNMP監視を整理します。

これらは、どれか1つだけを選ぶものではありません。

実際のシステムでは、複数の方式を組み合わせます。

たとえば、次のような組み合わせです。

• ネットワーク疎通は死活監視
• OS内部のCPU、メモリ、ディスクはエージェント監視
• ネットワーク機器やストレージはSNMP監視
• Webサービスの応答はURL監視
• クラウドリソースはCloudWatchやOCI Monitoring
• アプリケーションログはログ監視
• バッチ処理はジョブ監視

つまり、監視方式は「どれが正解か」ではありません。

そのシステムで何を知りたいのか。
どこまで異常を検知したいのか。
どのタイミングで誰が対応するのか。

これに応じて選びます。

死活監視とは何か

死活監視とは、監視対象が生きているかどうかを確認する監視です。

代表的には、監視サーバーから監視対象サーバーへ `ping` を実行し、応答があるかを確認します。

システム開発では、死活監視というと、まず `ping` による疎通確認をイメージすることが多いです。

`ping` は、監視サーバーから監視対象のIPアドレスへ到達できるか、相手が応答を返すかを確認するためによく使われます。

ここで注意が必要です。

`ping` が通ることは、システムが正常に動いていることを意味しません。

少しネットワークの階層で見ると、`ping` で確認しているのは、ざっくり言えばネットワーク層レベルの到達性です。

つまり、監視サーバーから監視対象のIPアドレスへ届き、相手が応答している、ということを確認しているに過ぎません。

その上で動いているWebサーバ、APサーバ、DB、ジョブ、業務アプリケーションまで正常であることを確認しているわけではありません。

たとえば、次のような状態でも `ping` は通ることがあります。

• Webサーバプロセスが停止している
• APサーバのスレッドが枯渇している
• DBリスナーが停止している
• DB表領域が枯渇している
• 業務APが内部エラーを返している
• ログイン画面は開くが検索処理が失敗する
• バッチジョブが異常終了している
• ディスク使用率が100%に近い
• メモリ不足で処理が極端に遅い

つまり、死活監視は重要ですが、それだけでは不十分です。

`ping` による死活監視で分かるのは、「ネットワーク的に到達できるか」「機器やOSが応答しているか」という入口の状態です。

一方で、業務として使える状態かどうかを確認するには、ポート監視、プロセス監視、URL監視、ログ監視、DB接続監視、ジョブ監視など、より上位の状態を見る監視が必要になります。

なお、死活監視は `ping` だけとは限りません。

SNMPを使って機器の稼働状態を確認する場合もあります。ネットワーク機器やストレージ、UPSなどでは、SNMPでインターフェース状態、電源状態、ファン、温度、装置状態などを取得したり、SNMP Trapで機器側から異常通知を受けたりします。

エージェント監視とは何か

エージェント監視とは、監視対象サーバーに監視用ソフトウェアを導入し、そのエージェントがサーバ内部の状態を収集する方式です。

監視対象サーバーの中に入って、CPU、メモリ、ディスク、プロセス、ログ、サービス状態などを確認するイメージです。

たとえば、次のような情報は、エージェントを入れた方が取得しやすくなります。

• CPU使用率
• メモリ使用率
• ディスク使用率
• ディスクI/O
• 特定プロセスの起動状態
• 特定サービスの状態
• OSログの特定メッセージ
• ミドルウェアログのエラー
• アプリケーションログの異常
• ファイル数やファイルサイズ
• 独自スクリプトの実行結果

商用監視製品であれば、JP1、Systemwalker、Hinemosなどが代表例です。

エージェント監視のメリットは、監視対象サーバーの内部情報を細かく取得できることです。

たとえば、単にDBサーバに `ping` が通るかだけでなく、DBプロセスが起動しているか、DB関連ログにエラーが出ていないか、CPUやメモリが逼迫していないか、といった情報を取得できます。

一方で、デメリットもあります。

エージェントをインストールする必要があります。
監視対象サーバーのリソースを使います。
バージョン管理が必要です。
OS更改やパッチ適用時に影響確認が必要です。
エージェント自体が停止すると監視できません。
セキュリティ上、導入や通信許可の調整が必要です。

そのため、エージェント監視を使う場合は、「何を監視したいからエージェントが必要なのか」を明確にします。

一方、エージェント監視のデメリットを見ると、「エージェントを入れずに済む方法はないか」という発想が生まれます。それがエージェントレス監視です。

エージェントレス監視とは何か

エージェントレス監視とは、監視対象サーバーに監視用エージェントを導入せず、監視サーバー側からリモートで状態を確認する方式です。たとえば、サーバに到達できるかを確認するだけなら `ping` で確認できます。

プロセス起動確認とWebサービス応答確認は違う

Webシステムでは、Apacheの `httpd` やTomcatのプロセスが起動していることを確認して、Web/APサーバが正常だと判断してしまうケースがあります。

しかし、プロセスが起動していることと、Webサービスが正常に応答していることは別です。

`httpd` が起動していても、アプリケーションのデプロイに失敗しているかもしれません。Tomcatが起動していても、DB接続でエラーになっているかもしれません。ロードバランサやリバースプロキシの経路が誤っていて、利用者から見ると画面に到達できないこともあります。

そのため、Webサービスの正常性を確認するには、HTTP/HTTPSで対象URLへアクセスし、HTTPステータスコードやレスポンス内容を確認することがあります。

たとえば、監視サーバーから `/healthcheck` や `/login` などのURLへHTTP GETリクエストを送り、HTTPステータスコードが `200` で返るか、レスポンス本文に想定した文字列が含まれるか、応答時間が閾値内かを確認します。

この考え方は、現在でもWebサービスの正常性確認として一般的に使われます。

ただし、最近のシステムでは、確認の粒度を分けることが増えています。

ロードバランサでは、配下のサーバへHTTP/HTTPSのヘルスチェックを行い、正常なターゲットだけにリクエストを振り分けます。

コンテナやKubernetes環境では、コンテナが生きているか、リクエストを受け付けられる状態か、起動完了しているかを分けて確認します。

また、より利用者目線で確認したい場合は、単一URLのGET確認だけでなく、外形監視やSynthetic Monitoringを使い、ログイン、検索、API呼び出しなど、実際の利用者操作に近いシナリオを定期実行することもあります。

つまり、`/healthcheck` や `/login` のHTTP応答確認は今でも有効です。

ただし、それだけで十分かは、システムの特性によります。

重要なのは、`httpd` やTomcatのプロセス起動確認だけで「Webサービスが正常」と判断しないことです。

Webサービスが業務として使えるかを確認するには、少なくともHTTP/HTTPSで実際にアクセスし、期待した応答が返ることを確認する必要があります。

ネットワーク機器やストレージの状態を確認する場合は、SNMPで情報を取得できることもあります。クラウドサービスであれば、APIやクラウド側のメトリクスから状態を取得できる場合もあります。

つまり、監視対象の内部にエージェントを入れなくても、監視サーバー側からリモートで確認できる内容であれば、エージェントレス監視を選択できます。

一方で、OSログの詳細確認、独自スクリプトの実行結果、アプリケーションログの細かな異常検知、サーバ内部の詳細なメトリクス取得などは、エージェントを入れた方が扱いやすい場合があります。

そのため、エージェントレス監視は「エージェントを入れなくて済むから楽」というだけではありません。

監視したい内容が外部から取得できるのか。
取得に必要な認証や権限をどう管理するのか。
通信経路やファイアウォール設定はどうするのか。
取得できる情報の粒度で運用判断できるのか。

ここまで考えたうえで、エージェント監視にするのか、エージェントレス監視にするのかを決めます。

代表的には、次のような方式があります。

• ping
• TCPポート監視
• HTTP/HTTPS監視
• SNMP監視
• SSH経由のコマンド実行
• Windows WMIによる情報取得
• APIによる状態取得
• クラウドサービスのメトリクス取得

エージェントレス監視のメリットは、監視対象サーバーにソフトウェアを導入しなくてもよいことです。

サーバ台数が多い場合、エージェント導入やバージョン管理の負荷を抑えられます。

また、ネットワーク機器、ストレージ、アプライアンス製品、クラウドサービス、マネージドサービスでは、そもそもエージェントを入れられないこともあります。

その場合は、SNMP、API、クラウドメトリクスなどを利用して監視します。

ただし、エージェントレス監視には制約があります。

外側から見える状態は分かるが、OS内部やアプリケーション内部の詳細までは見えないことがあります。
ログファイルの中身までは見にくいことがあります。
独自スクリプトの実行や詳細なメトリクス取得に制約が出ることがあります。
監視サーバーやネットワーク経路に障害があると、監視できないことがあります。

つまり、エージェントレス監視は「エージェントが不要だから簡単」という話ではありません。

エージェントを入れない代わりに、監視サーバー側の接続方式、認証、通信経路、権限、取得できるメトリクスの範囲を設計する必要があります。

SNMP監視とは何か

オンプレミスの監視やネットワーク機器監視でよく出てくるのが、SNMPです。

SNMPは、Simple Network Management Protocolの略です。

ネットワーク機器、サーバ、ストレージ、UPS、アプライアンスなどの状態を監視・管理するために使われるプロトコルです。SNMPの管理情報を扱うMIBについては、RFC 3418でもSNMPエンティティの動作を説明する管理オブジェクトとして定義されています。(IETF Datatracker)

SNMP監視では、一般的に次のような役割があります。

• SNMPマネージャー
• SNMPエージェント
• MIB
• OID
• SNMP Get
• SNMP Trap

SNMPマネージャーは、監視する側です。

SNMPエージェントは、監視される機器側で動作し、機器の状態情報を持っています。

SNMP Getは、マネージャーがエージェントに対して「この情報を教えて」と問い合わせる方式です。

SNMP Trapは、機器側からマネージャーへ「異常が起きた」と通知する方式です。

たとえば、ネットワーク機器でインターフェースがDownした場合、機器側からSNMP Trapが飛ぶことがあります。

監視サーバーはそのTrapを受け取り、アラートとして運用者へ通知します。

SNMP監視でつまずきやすいOIDとMIB

SNMPの説明では、OIDやMIBという言葉が当たり前のように出てきます。

しかし、これを正しく理解していないと、

「MIBファイルを監視製品に読み込ませれば、監視できるんですよね」

という誤解につながります。

これは危険です。

まず、OIDから整理します。

OIDは、Object Identifierの略です。

一言でいえば、監視対象機器の中にあるデータの住所です。

ネットワーク機器やサーバは、人間が話すように「CPU使用率を教えてください」と理解してくれるわけではありません。

SNMPでは、監視マネージャーが、監視対象機器に対して、

「この番号の情報をください」

と問い合わせます。

たとえば、あるネットワーク機器のCPU使用率を表すOIDが、次のような番号だったとします。

1.3.6.1.4.1.9.9.109.1.1.1.1.5

監視マネージャーは、このOIDを指定して、監視対象機器に問い合わせます。

すると、機器側のSNMPエージェントは、

80

のように値を返します。

この場合、人間から見ると「CPU使用率が80%」という意味です。

しかし、機器や監視マネージャーのやり取りとしては、基本的には「どのOIDの値を取るか」という話になります。

つまり、OIDは、監視対象機器の中にある監視項目の住所です。

次にMIBです。

MIBは、Management Information Baseの略です。

一言でいえば、OIDという数字の住所と、人間が理解できる意味を対応づける辞書です。

人間が、毎回、

1.3.6.1.4.1.9.9.109.1.1.1.1.5

という数字を見ても、それが何を意味するのかは分かりません。

そこで、ベンダーが提供するMIBファイルを使います。

MIBには、たとえば次のような対応関係が定義されています。

1.3.6.1.4.1.9.9.109.1.1.1.1.5
=
CPUの5分平均使用率

実際には、製品ごとの正式な項目名や階層構造で定義されていますが、考え方としてはこのようなものです。

つまり、OIDは「住所」です。
MIBは「住所録」または「辞書」です。

OIDが分かれば、監視マネージャーは対象機器から値を取得できます。
MIBがあれば、そのOIDが何を意味するのかを人間が理解しやすくなります。

ここまでは、SNMP監視の基本です。

ただし、実務で本当に重要なのはここからです。

MIBを登録しただけでは監視設計は終わらない

MIBファイルを監視製品に読み込ませると、製品固有のOIDやTrapの意味を解釈できるようになります。

しかし、それだけでは監視設計は終わりません。

MIBは、あくまで辞書です。

辞書を入れただけでは、

• どのOIDを監視するのか
• どの値を警告とするのか
• どの値を異常とするのか
• どのTrapを通知対象にするのか
• どのTrapは通知しないのか
• 何分継続したら異常にするのか
• 誰に通知するのか
• 通知を受けた人が何を確認するのか

は決まりません。

ここを決めるのが監視設計です。

たとえば、CPU使用率のOIDを監視するとします。

CPU使用率が80%になったら、必ず異常でしょうか。

そうとは限りません。

夜間バッチの時間帯だけ一時的にCPUが上がるシステムもあります。
バックアップ処理中だけCPUやI/Oが上がることもあります。
短時間のスパイクであれば、業務影響がない場合もあります。
一方で、CPU使用率が70%程度でも、長時間継続すれば性能劣化の予兆かもしれません。

つまり、単に「CPU使用率のOIDを監視する」だけでは不十分です。

次のように、運用で判断できる条件まで落とす必要があります。

CPU使用率が90%以上
かつ
5分以上継続した場合は警告

CPU使用率が95%以上
かつ
10分以上継続した場合は異常

ただし、夜間バッチ時間帯は別閾値とする

もちろん、これは例です。

実際の閾値は、システムの特性、性能要件、通常時の負荷、ピーク時間帯、バッチ処理、運用体制に応じて決めます。

MIBを入れただけで監視を始めると何が起きるか

よくない進め方は、ベンダーのMIBファイルを監視サーバーに登録し、デフォルト設定に近い形で対象機器の監視を一斉に始めてしまうことです。

この場合、運用開始後にアラートが大量に出ることがあります。

いわゆる、アラートの大洪水です。

なぜそうなるのか。

主な理由は3つあります。

1つ目は、通知すべきイベントと、通知しなくてよいイベントを分けていないことです。

機器や製品は、さまざまなTrapや状態変化を出します。

その中には、本当に即時対応が必要な障害もあります。

一方で、単なる情報通知、状態変化、復旧通知、一時的な警告、運用上は無視してよいメッセージもあります。

これらをすべて同じように通知すると、運用者は大量のアラートを受けることになります。

2つ目は、閾値や継続時間をシステム特性に合わせていないことです。

CPU、メモリ、ディスクI/O、ネットワーク使用率などは、システムによって通常値が違います。

業務ピーク時にCPUが高くなるシステムもあります。
夜間バッチ中にI/Oが急増するシステムもあります。
月次処理の日だけ負荷が上がるシステムもあります。

それを考慮せず、一般的な閾値だけで監視すると、正常な業務処理まで異常として検知してしまいます。

3つ目は、テスト工程で実際のログやアラートを精査していないことです。

監視条件は、設計時点の机上検討だけでは決めきれません。

特に、ログ監視やTrap監視は、実際にシステムを動かしてみないと、どのメッセージがどれくらい出るのか分からないことがあります。

システムテスト、運用テスト、本番リハーサルで、業務データ、日次処理、月次処理、ピーク時のトランザクション、バックアップ、ジョブ、外部連携などを動かして初めて、大量のログやイベントが出てきます。

その中から、

• 本当に通知すべきもの
• 通知は不要だが記録しておくもの
• 除外してよいもの
• 閾値や継続時間を見直すべきもの
• 一次対応手順に落とすべきもの

を精査する必要があります。

これをやらずに本番稼働すると、運用開始後に大量のアラートが出ます。

すると、運用者はアラートを見切れなくなります。

最悪なのは、本当に重要な障害が、不要なアラートの中に埋もれてしまうことです。

監視は、アラートをたくさん出せばよいわけではありません。

運用者が判断できる形で、必要な異常を検知することが重要です。

SNMP監視も詳細設計の対象である

ここまで見ると分かるように、SNMP監視は単にMIBを登録する作業ではありません。

• MIBを登録する
• OIDを選ぶ
• Trapを受ける
• 閾値を決める
• 重大度を決める
• 通知先を決める
• 除外条件を決める
• テスト工程で実際の発報状況を確認する
• 運用手順と対応づける

ここまで含めて、SNMP監視も詳細設計の中で決めるべき重要な領域です。

まとめ｜監視は「異常を検知する設定」ではなく設計である

システム監視では、まず何を正常とし、何を異常として検知するのかを決める必要があります。

本記事では、監視の基本として次の点を整理しました。

• 監視には「監視する側」と「監視される側」がある

• ping が通ることと、システムが業務として正常に使えることは別

• 死活監視、エージェント監視、エージェントレス監視、SNMP監視は目的に応じて使い分ける

• SNMPではMIBを登録するだけでなく、OID、閾値、Trap、除外条件まで設計する

• 監視条件は設計時に決めて終わりではなく、テスト工程で実際の発報を確認して見直す

監視製品を導入し、監視項目を設定すれば監視設計が終わるわけではありません。

重要なのは、

「何を検知するか」
「どの条件で異常と判断するか」
「検知した後に誰がどう動くか」

までつながっていることです。

監視は、アラートを出すための設定ではなく、障害に気づき、判断し、対応につなげるための設計です。

次の記事｜クラウドでは監視設計がどう変わるのか

オンプレミスでは、監視サーバーやエージェント、SNMPなどを使って監視する構成が一般的でした。

一方、AWSやOCIでは、CloudWatchやOCI Monitoringといったクラウドネイティブな監視サービスを利用できます。

ただし、クラウド監視サービスを使えば、監視設計そのものが不要になるわけではありません。

後編では、

• AWS CloudWatch／OCI Monitoringによるクラウド監視

• オンプレミスからクラウド移行するときの監視Fit & Gap

• 監視方式と監視対象の違い

• 閾値、検知条件、重大度、通知先

• 一次対応・エスカレーション・復旧確認

まで踏み込み、実際の運用につながる監視設計を整理しています。

【後編】システム監視の基本｜クラウド監視と「運用で使える監視設計」

CloudWatch等のクラウド監視サービスは部品に過ぎない。既存監視をクラウド移行後どう引き継ぐか、Fit & Gapの整理方法を実務観点で解説します。

sys-univ.com

2026.09.07

関連記事

監視は単独で設計するものではありません。

非機能要件で求める可用性や運用性を整理し、詳細設計で監視条件へ落とし込み、テスト・運用につなげていく必要性については次の記事で説明しています。

• 詳細設計で決めること 後編②｜監視・ログ・バックアップ・セキュリティ・運用スクリプト
  監視対象、閾値、通知、ログ監視条件など、監視を詳細設計としてどこまで具体化するかを整理しています。

【全3回・第3部】監視・ログ・バックアップ・セキュリティの詳細設計｜運用で使える設計にする観点

詳細設計を「構築・テスト・運用できる形」に落とし込む後編②。設計時点では判断しきれない監視条件の見極めなど、現場で見落としやすい監視設計の難しさを整理します。

sys-univ.com

2026.08.20

• 機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う点
  可用性、性能、運用・保守性など、監視設計の前提となる非機能要件について解説しています。

機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う

「機能が動く」と「本番で使える」は違う。機能要件と非機能要件の違いを、購入申請システムの具体例と現場の失敗パターンから整理します。

sys-univ.com

2026.06.19

• 要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
  監視を含む非機能要件を、設計に入る前の要件定義でどこまで決めるのかを整理しています。

要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務

要件定義とは何をする工程なのか。RFP、質問回答、提案書、見積前提から認識差を潰し、スコープや責任分界を確定する実務を、大規模SIの具体的な失敗事例とともに解説します。

sys-univ.com

2026.08.12

• システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか
  要件定義、設計、構築、テスト、運用まで、監視設計がシステム開発全体のどこに位置するのかを解説しています。

システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか

システム開発は、アプリケーションだけで成立するものではありません。システム基盤、性能・可用性などの非機能、テスト、移行、運用がどのようにつながって一つのシステムを成立させるのかを、現場目線で整理します。

sys-univ.com

2026.08.26

• 【第1部】システム監視の基本｜死活監視・エージェント監視・SNMP監視
  監視の基本構造、死活監視、エージェント監視、SNMP監視、MIB・OIDなどを解説

• 【第2部】この記事
  クラウド監視、既存監視のFit & Gap、運用で使える監視設計を解説

はじめに

前編では、死活監視、エージェント監視、SNMP監視など、システム監視の基本的な仕組みを整理しました。

そこで確認したのは、ping が通ることと、システムが業務として正常に使えることは別だという点です。

サーバへの到達、プロセスの起動、HTTP/HTTPSの応答、業務処理の正常終了では、それぞれ確認しているレベルが異なります。

後編では、この考え方をクラウド環境へ広げます。

AWS CloudWatchやOCI Monitoringを使えば、自前の監視サーバを構築せずに、メトリクス、ログ、アラームを扱える場合があります。

しかし、クラウド監視サービスを使えば、監視設計が不要になるわけではありません。

• 標準メトリクスで足りるのか
• 既存監視をそのまま置き換えられるのか
• どの値を異常とするのか
• 誰に通知するのか
• 通知後に何を確認し、どう対応するのか

こうした点は、クラウドでも設計する必要があります。

特にオンプレミスからクラウドへ移行する場合は、既存監視をそのまま移すのではなく、何を引き継ぎ、何を標準機能で代替し、何を見直すのかというFit & Gapが重要になります。

監視は、アラートを出すための設定ではありません。

障害に気づき、判断し、対応につなげるための設計です。

クラウド監視とは何か

前編で説明した監視構成は、オンプレミスや従来型の監視製品を前提としたものでした。

一方、クラウドでは監視の実現方法が少し変わります。

クラウドでは、クラウドベンダーが用意する監視サービスを使って、仮想サーバ、ストレージ、ロードバランサ、データベース、ネットワーク、サーバレス、コンテナなどのメトリクス、ログ、イベントを収集できます。

そのため、従来のように自前で監視サーバを立てて、すべてのサーバに監視エージェントを導入し、監視製品を運用する、という構成が必ずしも必要ではありません。ただし、ここで誤解してはいけないことがあります。

クラウド監視サービスがあることと、監視設計が不要になることは別です。
クラウド監視サービスは、監視を実現するための部品です。

何を監視するのか。 どの値を異常とするのか。 どの条件で通知するのか。 通知を受けた人が何を確認するのか。 既存システムで行っていた監視を新システムでも継続するのか。

ここは、設計で決める必要があります。

特にオンプレミスからクラウドへ移行する業務システムでは、既存監視の引き継ぎが大きな論点になります。

クラウド監視サービスの代表例

クラウド監視サービスは、クラウドベンダーごとに用意されています。

AWSであれば、CloudWatch。 Azureであれば、Azure Monitor。
Google Cloudであれば、Cloud Monitoring。
OCIであれば、OCI Monitoring。

それぞれ名称や機能の範囲は異なりますが、基本的には、クラウド上のリソースからメトリクス、ログ、イベントを収集し、条件に応じてアラームや通知につなげるためのサービスです。

この記事では、AWSでよく使われるCloudWatchを中心に説明します。

あわせて、Oracle DatabaseやOracle製品を利用している業務システムではOCIが選択肢になることもあるため、OCI Monitoringについても簡単に触れます。

AWS CloudWatchの場合

AWS CloudWatchは、AWS上のリソースを監視するための代表的なサービスです。

EC2、RDS、ELB、EBS、Lambda、ECS、EKSなど、AWS上の多くのサービスはCloudWatchにメトリクスを出力できます。

たとえば、EC2であればCPU使用率、ネットワーク送受信量、ディスクI/Oなどを確認できます。

RDSであれば、CPU使用率、DB接続数、ストレージ容量、読み書きIOPSなどを確認できます。ELBであれば、リクエスト数、ターゲットの正常性、HTTPエラー数、レスポンスタイムなどを確認できます。

CloudWatchでは、こうしたメトリクスに対してアラームを設定できます。

たとえば、CPU使用率が一定時間以上高い状態が続いたら通知する。 RDSの空き容量が少なくなったら通知する。 ELB配下の正常ターゲット数が減ったら通知する。 アプリケーションログに特定のエラーメッセージが出たら通知する。

このように、CloudWatchはAWS上のシステム監視における基本的な部品になります。ただし、CloudWatchを使えばすべてが自動で完璧に監視されるわけではありません。

標準メトリクスで足りるのか。 詳細監視が必要なのか。 CloudWatch Agentを入れてOS内部のメモリやディスク使用率を取得するのか。 アプリケーションログをCloudWatch Logsへ送るのか。 ログのどの文字列を異常として拾うのか。 アラーム閾値をどう設定するのか。 通知先をどうするのか。 通知を受けた人が何を確認するのか。

これらは設計が必要です。

特にオンプレミスからAWSへ移行する場合、既存の監視をCloudWatchだけでそのまま置き換えられるとは限りません。

JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで見ていた監視項目が、CloudWatchの標準メトリクスだけで同じ粒度で取得できるとは限らないからです。

そのため、AWSへ移行する場合でも、CloudWatchで何が見えるかだけではなく、既存監視で何を見ていたのか、新システムでも同じ監視が必要なのか、必要ならCloudWatchで代替できるのか、できない場合は何で補うのかを整理する必要があります。

OCI Monitoringの場合

OCIでも、クラウドネイティブな監視サービスがあります。
代表的なのがOCI Monitoringです。

OCI Monitoringを使うと、OCI上のコンピュート、ストレージ、ロードバランサ、データベース、ネットワーク関連リソースなどのメトリクスを収集し、条件に応じてアラームを設定できます。

OCIのComputeインスタンスでは、プラグインを有効化することで、インスタンスの状態やメトリクスを取得できる構成もあります。
ただし、OCI Monitoringを使えば、Oracle Databaseの性能監視や既存の運用監視がすべて自動で置き換わるわけではありません。

Oracle Databaseを利用している業務システムでは、OCI Monitoringで見るもの、Oracle Database側の機能で見るもの、OEMで見るもの、ログ監視で見るもの、運用手順で確認するものを分けて考える必要があります。

特に、既存システムでOracle Database、Oracle Enterprise Manager、AWR、ASH、Performance Hub、PFM for Oracleなどを利用していた場合、クラウド移行後にどの監視を何で代替するのかを整理する必要があります。

Oracle系システムでは、DB性能、待機イベント、SQL、セッション、表領域、アラートログなど、DB内部の監視観点が重要になることがあります。
そのため、OCI Monitoringだけで考えるのではなく、Oracle Databaseの監視機能や既存運用を含めて、全体として監視設計を行う必要があります。

クラウド移行では、既存監視のFit & Gapが必要

クラウド移行といっても、完全な新規開発ばかりではありません。

実務では、既存のオンプレミスシステムをクラウドへ移すリフト＆シフトや、移行後に段階的にクラウドネイティブ化していくケースが多くあります。

その場合、移行前のシステムで行っていた監視を、移行後にどう引き継ぐかが大きな論点になります。

既存環境では、JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで、OS、ジョブ、ログ、DB性能、表領域、待機イベント、SQL、アラートログなどを監視していたかもしれません。

では、それをクラウド移行後に同じように見られるのでしょうか。答えは、簡単ではありません。

クラウド移行後の監視Fit & Gapでは、少なくとも次の3つに整理して考える必要があります。

1. 既存監視を標準機能で置き換えられるもの

PFM for Oracleや既存監視製品で見ていた内容を、OEM、AWR、ASH、Performance Hub、CloudWatch、Performance Insights、Database Insightsなどで代替できる場合は、新環境の標準機能に寄せる判断があります。

この場合、既存監視をそのまま機械的に移植するのではなく、新環境で標準的に提供されている監視機能を使い、運用をシンプルにできないかを検討します。

2. 標準機能だけでは置き換えられないもの

一方で、既存監視で見ていた項目が、新環境の標準機能では取得できない、または同じ粒度で監視できない場合もあります。

その場合は、代替方式を検討します。

別のメトリクスで代替できるのか。 ログ監視で拾えるのか。 スクリプトで補完できるのか。 外部監視製品やAPMを使うのか。 そもそも新環境でも本当に必要な監視なのか。

ここを整理せずに進めると、オンプレでは見えていた異常が、クラウド移行後に見えなくなることがあります。

3. 代替するか、捨てるか、運用でカバーするもの

標準機能で置き換えられない監視については、最終的に判断が必要です。

手組みしてでも実装するのか。 別製品を追加して実現するのか。 運用手順でカバーするのか。 監視対象から外すのか。

監視を外す場合は、障害検知が遅れる可能性、一次対応への影響、サービスレベルへの影響を説明し、リスク受容として顧客と合意する必要があります。

ここで重要なのは、プロジェクト側だけで勝手に決めないことです。

既存システムで実装されていた監視には、多くの場合、過去の障害、運用上の要請、監査対応、顧客側の不安、サービスレベル上の理由があります。

そのため、単に「新しい製品ではできないのでやりません」とは言いにくいことがあります。

技術的には実現できない。 実現はできるがコストが高すぎる。 手組みすれば可能だが保守性が悪い。 運用カバーで十分と判断できる。 リスクを受容して監視対象から外す。

こうした判断を、要件、コスト、運用負荷、障害時の影響、顧客の期待値を踏まえて整理します。

クラウド移行時の監視設計で重要なのは、既存監視を機械的に移植することではありません。

業務システムとして必要な異常検知、性能把握、一次対応、エスカレーションが、新システムでも成立するかを確認することです。

そのうえで、できること、できないこと、代替すること、やめることを顧客と合意する。ここまで含めて、新システムの監視設計です。

監視対象・目的で見た監視の種類

ここで重要なポイントは、「監視方式」と「監視対象・監視目的」を混同しないことです。

この中で、若手SEが特に理解しておくべきなのは、死活監視だけでは業務正常性は分からないという点です。

サーバに ping が通っていても、Web画面がエラーになっているかもしれません。 Web画面が開いても、検索処理が失敗するかもしれません。 DBプロセスが起動していても、表領域が枯渇して更新できないかもしれません。 バックアップジョブが正常終了していても、リストアできないかもしれません。

だからこそ、監視設計では「何をもって正常と判断するのか」を決める必要があります。

監視方式は「何を知りたいか」から選ぶ

監視方式を選ぶときに大事なのは、製品や流行から入らないことです。

まず決めるべきなのは、「何を知りたいのか」です。

• サーバが起動しているかを知りたいなら、死活監視です。
• Webサービスが応答しているかを知りたいなら、URL監視です。
• OS内部のCPUやメモリを知りたいなら、リソース監視です。
• DBプロセスが動いているかを知りたいなら、プロセス監視です。
• DBとしてログインできるかを知りたいなら、DB接続監視です。
• ログに異常メッセージが出ていないか知りたいなら、ログ監視です。
• ストレージやネットワーク機器の状態を知りたいなら、SNMP監視や製品API監視です。
• クラウドリソースの状態を知りたいなら、CloudWatchやOCI Monitoringなどのクラウド監視サービスです。

監視方式は、目的によって変わります。

逆に言えば、監視方式だけを決めても意味がありません。

「SNMPで監視します」では不十分です。

• SNMPで何を監視するのか。
• どのOIDを見るのか。
• どのTrapを受けるのか。
• 重大度をどう判定するのか。
• 通知先はどこか。
• 一次対応手順は何か。

ここまで決めて初めて、監視設計になります。

監視設計で決めること

監視設計では、最低限、次のような項目を決めます。

• 監視対象
• 監視項目
• 監視方式
• 監視間隔
• 閾値
• 検知条件
• 除外条件
• 重大度
• 通知先
• 通知方法
• 監視抑止条件
• メンテナンス時の扱い
• 一次対応手順
• エスカレーション先
• 復旧確認方法
• 監視設定の変更手順
• 監視条件の見直しタイミング

たとえば、CPU使用率の監視でも、単に「CPUを監視する」では足りません。

• CPU使用率が何％を超えたら警告なのか。
• 何分継続したら異常なのか。
• 瞬間的なスパイクは除外するのか。
• 夜間バッチ中は閾値を変えるのか。
• 警告と異常で通知先を分けるのか。
• 通知を受けたら、運用者は何を見るのか。
• AP担当、DB担当、基盤担当のどこへ連絡するのか。

ここまで決める必要があります。

監視は、アラートを出すことが目的ではありません。

アラートを受けた人が判断できることが目的です。

監視でよくある誤解

監視でよくある誤解は、次の3つです。

そのため、監視設計は、設計時点で決めて終わりではありません。
システムテスト、運用テスト、本番リハーサル、本番稼働後の初期期間を通じて、見直す前提が必要です。

システム基盤エンジニアが持つべき監視の見方

まず持ってほしいのは、「監視は設定項目ではなく、運用の入口である」という見方です。

監視アラートは、障害対応のスタート地点です。

アラートが出た瞬間に、運用者は判断を求められます。

• これは本当に障害なのか。
• 無視してよい通知なのか。
• すぐにエスカレーションすべきなのか。
• まず手順書に沿って確認すべきなのか。
• 復旧したと言える条件は何か。

この判断ができるように設計するのが、監視設計です。

• 監視サーバがある。
• エージェントが入っている。
• CloudWatchにメトリクスが出ている。
• OCI Monitoringにアラームがある。 MIBを読み込ませた。

それだけでは、監視設計としては不十分です。
重要なのは、検知した後に運用が動けることです。

まとめ｜クラウドでも、監視の本質は変わらない

クラウド監視サービスを使えば、メトリクス、ログ、アラームを扱いやすくなります。

しかし、CloudWatchやOCI Monitoringを使えば、監視設計そのものが不要になるわけではありません。

特にオンプレミスからクラウドへ移行する場合は、既存監視をそのまま移植するのではなく、

• 標準機能で置き換えられるもの
• 標準機能だけでは置き換えられないもの
• 代替するもの、運用でカバーするもの、監視対象から外すもの

に分けて、Fit & Gapを整理する必要があります。そのうえで、

• 何を監視するのか。
• どの条件で異常と判断するのか。
• 誰に通知するのか。
• 通知後に誰が何を確認し、どう対応するのか。

まで設計して初めて、監視は運用で使える仕組みになります。

監視で重要なのは、たくさんのアラートを出すことではありません。

本当に検知すべき異常を、運用で判断・対応できる形で検知することです。

監視は、アラートを出すための設定ではなく、障害に気づき、判断し、対応につなげるための設計です。

前編では、監視する側・監視される側という基本構造から、死活監視、エージェント監視、エージェントレス監視、SNMP監視、MIB・OIDまで、システム監視の基礎を整理しています。

【前編】システム監視の基本｜ping・エージェント・SNMP監視を整理する

pingが通ることとシステムが業務で使えることは別物。死活監視・エージェント監視・SNMP監視の基本構造と、監視設計で見落としやすい落とし穴を整理します。

sys-univ.com

2026.09.09

関連記事

監視設計は、単独で完結するものではありません。

非機能要件で求める可用性や運用性を整理し、詳細設計で監視条件へ落とし込み、テスト・運用につなげていく必要性については次の記事で説明しています。

• 【全3回・第3部】監視・ログ・バックアップ・セキュリティの詳細設計｜運用で使える設計にする観点
  監視対象、閾値、通知、ログ監視条件、運用スクリプトなど、監視を詳細設計でどう具体化するかを整理しています

【全3回・第3部】監視・ログ・バックアップ・セキュリティの詳細設計｜運用で使える設計にする観点

詳細設計を「構築・テスト・運用できる形」に落とし込む後編②。設計時点では判断しきれない監視条件の見極めなど、現場で見落としやすい監視設計の難しさを整理します。

sys-univ.com

2026.08.20

• 機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う点
  可用性、性能、運用・保守性など、監視設計の前提となる非機能要件を整理しています。

機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う

「機能が動く」と「本番で使える」は違う。機能要件と非機能要件の違いを、購入申請システムの具体例と現場の失敗パターンから整理します。

sys-univ.com

2026.06.19

• 要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
  監視を含む非機能要件を、設計に入る前の要件定義でどこまで具体化するのかを解説しています。

要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務

要件定義とは何をする工程なのか。RFP、質問回答、提案書、見積前提から認識差を潰し、スコープや責任分界を確定する実務を、大規模SIの具体的な失敗事例とともに解説します。

sys-univ.com

2026.08.12

• システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか
  要件定義、設計、構築、テスト、運用まで、監視設計がシステム開発全体のどこに位置するのかを整理しています。

システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか

システム開発は、アプリケーションだけで成立するものではありません。システム基盤、性能・可用性などの非機能、テスト、移行、運用がどのようにつながって一つのシステムを成立させるのかを、現場目線で整理します。

sys-univ.com

2026.08.26