システムを導入する企業を、この記事では「発注側」と呼びます。発注側が外部のSIer（システムインテグレーター）に設計・開発などを依頼しても、情シスの仕事がなくなるわけではありません。

私は大手SIerで20年以上、データベースの設計・構築からシステム基盤の統括、プロジェクトマネジメントまで携わってきました。その中で、発注側の役割が曖昧なまま仕事が進み、プロジェクトが行き詰まる場面を何度も見てきました。

「技術のことは詳しいSIerにお任せします」。技術的な設計や実装を専門家に委ねるのは自然です。しかし、自社の業務で何を実現するか、誰が合意するか、導入後に成果が出たかまで委ねることはできません。

これは担当者を批判したいという話ではありません。情シスの役割や発注側としての判断を体系的に教わる機会がなく、何を確認すればよいのか分からないまま現場に立つこともあると感じています。だからこそ、実務で役立つ入門記事を書こうと考えました。

これから情シスになる方、配属されたばかりの方に向けて、組織内の立ち位置、関係者、システム開発・運用の仕事を順番に説明します。後半では、主任クラスを目指す際に役立つ具体的な確認観点も紹介します。

なぜ企業に情シスが必要なのか？

システムを作ることが目的ではない

企業は、売上の拡大、納期の短縮、品質の安定、コストの削減など、事業上の目標を持っています。その実現には、業務の進め方を見直し、情報を適切に使える状態にすることが必要です。

例えば「納期を守れる会社にしたい」という目標があるなら、受注・調達・製造・出荷の状況を把握できていないことが課題かもしれません。必要なのは、いきなり新しいシステムを購入することではなく、どの情報を誰がいつ必要とするのかを整理することです。その結果として、既存システムの改修やSaaSの導入が選択肢になります。

流れは、経営・事業の目標 → 業務課題 → 業務の改善 → IT施策 → 効果の確認です。情シスは、この流れをITの側面から支える組織です。

図　情シスが支える基本の流れ

経営、業務、ITをつなぐ窓口になる

経営層は投資の目的や優先順位を考えます。業務部門は現場の仕事と制約を知っています。SIerは技術的な実現方法を考え、設計・開発を担います。

しかし、これらの情報を別々に持ったままでは、投資目的とシステムの仕様がずれたり、現場で使われない仕組みが出来上がったりします。情シスは、事業の目的をITの取り組みにつなぎ、導入後も目的を達成できたかを確かめる役割を持ちます。

なお、企業によっては情シス自身が開発や運用を行い、別の企業では外部委託を中心とするなど、担当範囲は異なります。この記事では、業務システムの企画・開発・運用を社内外の関係者と進める情シス担当者を中心に説明します。

情シスの仕事内容と、社内外の関係者との役割分担

まずは3つの仕事を押さえる

情シスの仕事は、大きく次の3つに分けられます。

近年はクラウド・SaaSの組み合わせ、外部サービスとのデータ連携、情報セキュリティ、生成AIの利用ルールなども重要になっています。「自社で全部作る」だけでなく、「選び、つなぎ、継続して使う」仕事が増えています。

情シス内部の組織構造も知っておこう

情シスの中でも、役職による判断権限と、業務領域による担当分担があります。例えば、次のような体制です。

これとは別に、企画・開発、運用・保守、社内IT支援などの担当グループが置かれることもあります。企業規模によっては兼務も珍しくありません。若手は担当するシステムと業務を理解するところから始め、主任クラスでは担当領域を横断して課題や判断をつなぐことが期待されます。

情シス担当者の周囲に、誰がいるのか

新任担当者は、まず社内外の関係者を整理してください。情シスはすべてを一人で決める部署ではありません。

図　新任情シス担当者の組織内の位置と社内外の関係者

担当者の仕事は「すべての関係者を指揮すること」ではありません。情報を集め、論点を整理し、権限のある人が判断できる状態を作ることです。ベンダへ技術的な詳細を任せても、判断の所在を曖昧にしないことが大切です。

【実体験】仕事が進む発注者は、決める人が明確だった

私が関わったプロジェクトの中には、発注側がキックオフMTGを自ら仕切り、業務仕様を決める責任者を当初から明確にしている案件がありました。業務ごとに課長級の責任者が判断し、SIerは論点の整理や技術的な選択肢の提示で支援する、という役割分担です。

反対に、発注側の業務部門間で意見が割れた際、ベンダが合意形成まで引き受けてしまうと、あとから「そういう意味で承認したのではない」という行き違いが起こります。業務部門間の合意形成は発注側が主導する。技術的な実現方法はSIerが主体的に設計する。 この線引きは、最初の会議で確認しておきたいことの一つです。

企画・開発・運用で、情シスは何をするのか？

情シスは、システム開発の特定の工程だけに関わるわけではありません。企画から導入、運用、効果の確認まで、仕事がつながっています。

図　発注側とSIerが工程ごとに担う作業

システム開発は、新しい機能を作る仕事だけではありません。既存システムを新しい環境へ移行する「システム更改」でも、現行調査、設計、試験、データ移行、運用引継ぎなど、多くの作業が発生します。

具体的な開発プロジェクトの進め方は、次の記事「システム更改で学ぶ、プログラミングだけではない仕事の全体像」で紹介しています。

【システム開発とは何か】システム更改で学ぶ、プログラミングだけではない仕事の全体像

システム開発はプログラミングだけではありません。A銀行のクラウドリフトを例に、現行調査、基盤設計、データ移行、テスト、運用引継ぎ、ステークホルダーや責任共有モデルまで、初心者向けに解説します。

sys-univ.com

2026.07.17

発注側は「何を実現するか」を決める

業務要件や優先順位は発注側が決めます。一方、実現するための技術方式や物理設計は、SIerが専門家として主体的に検討・設計します。発注側は、その内容が自社の要求に合っているかを理解して承認します。

例えば、データベースの索引をどう設計するかまで情シスが指定する必要はありません。しかし、必要な性能や運用条件が満たされるか、費用にどのような影響があるかは確認すべきです。技術方式が業務や投資判断に大きく関わるなら、SIerが代替案を説明し、発注側と合意して進めます。

任せることと、丸投げすることは違います。

【実体験】RFPの一行から、設計上の論点を引き出す

以前、RFPに「オンライン受付は夕方で終了するが、必要に応じて延長できること」とだけ書かれていたことがあります。

SIerとして確認したいのは、延長をいつまでに申し込むのか、誰が承認するのか、延長範囲はシステム全体か処理単位か、延長対象外の接続はどう扱うのか、といった点です。帳票作成などの非同期処理が終了時刻をまたいだらどうするのかも確認が必要です。

私は質問表で条件を一つずつ確認し、パッケージの標準機能で実現できるか、追加開発が必要かを整理しました。他社パッケージの対応状況も検討材料にしつつ、発注側には「本当に必須か」「代替案を認められるか」を質問しました。

入札で質問・回答が参加各社に公開される場合、こうした質問は、発注側が自らの要求を具体化する機会にもなります。ベンダからの質問が多いことは、必ずしも悪い兆候ではありません。曖昧な要求を放置して進める方が危険です。

ある失敗ケースで考える、誰が何を確認すべきだったのか

ここまで説明した役割が欠けると、何が起こるでしょうか。問題を見つけやすいよう、あえて単純化した極端な例で考えてみます。実際の個別案件を紹介するものではありません。

経験者にとっては初歩的な確認漏れに見える内容ですが、開発を初めて担当する人には、そもそも何を確認すべきか分からないこともあります。まず「誰が、どの段階で気づけたか」を意識して読んでみてください。

取引先との連携で起きたこと

ある企業が、受発注管理システムをクラウドサービスに移行します。通常のデータ送受信は確認できていましたが、本番切替前の外部接続リハーサルで、受信確認が届かなかった場合の再送を試すと、同じ注文が二重に登録されました。

取引先との間には「注文番号で同じ注文を判定し、重複登録しない」という条件がありました。しかし、移行先サービスの標準機能は、その取引先固有の条件に対応していませんでした。この差異が、要件・設計・試験の確認対象から漏れていたのです。導入ベンダは技術的な対応案と費用・期間・リスクを提示し、発注側は業務への影響を検討した結果、追加対応と本番切替の延期を判断しました。

本来、再送時の重複登録防止は、要件定義・設計・試験で扱うべき基本的な確認事項です。本番切替直前まで残るのは重大な品質管理上の問題です。

さて、どの役割を果たしていれば、もっと早い段階で発見できたでしょうか。

欠けていた活動と、本来すべき活動

これは発注側だけの失敗でも、SIerだけの失敗でもありません。専門家が確認すべき技術的論点と、発注側が把握・判断すべき業務条件が結び付かなかったことにあります。

また、対応には品質（Quality）・費用（Cost）・納期（Delivery）、いわゆるQCDの観点が必要です。追加開発するか、取引先と条件を見直すか、安全に管理できる範囲で暫定対応するか。SIerが影響と選択肢を提示し、発注側が事業上の優先順位を踏まえて判断します。

この例から学んでほしいのは、極端な失敗そのものではなく、要件と試験の対応を追い、抜けている確認事項に気づく視点です。後半のVモデルの説明にもつながります。

今回のケースは、問題点を分かりやすくするために単純化した例ですが、上流工程で確認すべき事項を残したまま進めると、後工程で手戻りが発生するという構造は、実際のプロジェクトにも共通します。

別の例として、AWSへのクラウド移行で事前検証（PoC）が不足し、設計上のリスクが構築・試験段階で表面化する問題を次の記事「クラウドリフトの失敗は構築前に始まっている」で解説しています。

【第1回】クラウドリフトの失敗は構築前に始まっている｜PoC不足が手戻り・コスト超過・納期遅延を招く理由

クラウド移行（AWSへのクラウドリフト）で起きる手戻り・コスト超過・納期遅延は、構築中ではなくPoC不足から始まります。Auto Scaling、EFS/EBS、RDS、監視、バックアップ、ライセンスなど10の設計リスクを現場目線で整理します。

sys-univ.com

2026.08.20

開発が終わってからが本番。運用と導入効果はどう評価する？

システムが予定どおり完成し、ベンダによる試験を通過したら成功でしょうか。情シスの評価は、そこで終わりません。

「作れたか」と「成果が出たか」は別の評価

開発段階では、必要な品質を確保できたか、予算と納期を守れたかというQCDが重要です。一方、導入後には、業務が実際に改善したか、投資に見合う便益が生まれたかを確かめる必要があります。

図　QCDと導入効果ROI

SIerはシステムが要求に沿って稼働しているかを検証できます。しかし、部門の実際の工数や取引の改善、事業上の収益への影響を、SIerだけで測ることはできません。業務の成果を測る責任は発注側にあります。

導入前にKPIと測定方法を決めておく

例えば、受注処理の効率化が導入目的なら、稼働前後で「処理件数」「担当者の作業時間」「手戻り件数」などを比較します。

仮に月400時間かかっていた処理が、導入後280時間になれば、月120時間、年間1,440時間の削減です。時間当たり3,000円で換算すると、年間432万円分の工数に相当します。

ただし、432万円がそのまま会社の現金支出削減になるとは限りません。 実際に残業代や外注費が減る場合もあれば、空いた時間を別の業務に振り向ける場合もあるからです。後者は生産性向上という効果ですが、費用削減と同じものとして扱ってはいけません。

このため、KPIは企画段階で決め、測定方法、導入前の数値、導入後の測定時期、データを持つ部署まで定めておきます。導入後に慌てて効果を測ろうとしても、比較する基準が残っていないことがあります。

ROIは「便益」と「費用」を同じ期間で比較する

ROI（Return on Investment、投資利益率）は、投資に対してどれだけの利益が得られたかを見る指標です。簡易的には、ROI＝（便益－費用）÷費用×100％で計算できます。比較期間と費用・便益の範囲をそろえることが前提です。

先ほどの年間432万円は、削減した作業時間の金額換算例でした。ここからは、それとは別に、実際に外注費などの支出を減らせると仮定した試算を示します。

初期投資900万円、削減できる費用が年間480万円、新しいシステムの運用費が年間80万円の場合、年間の差引便益は400万円です。単純な投資回収期間は、900万円÷400万円＝2.25年（約2年3か月）となります。

同じ条件を3年間で評価すると、次のようになります。

したがって、3年間の簡易ROI＝300万円÷1,140万円×100≒26.3％です。これは物価変動や資金の時間価値、税金、追加改修費用などを考慮しない説明用の試算です。

実務ではクラウド利用料、保守契約、ライセンス更新、追加改修、利用部門の負担なども評価対象に含めます。また、内部統制の強化や顧客サービスの改善など、金額にしにくい効果は、ROIと併せて別のKPIで評価します。

安定運用・障害対応・次の更改にも責任がある

稼働後の監視、バックアップ、障害復旧、更新作業などは、契約によってSIerや運用ベンダが担うことも多い仕事です。それでも情シスには、障害の業務影響を把握し、復旧の優先順位を決め、関係者に連絡し、改善の必要性を判断する役割があります。

導入後の効果が低ければ、運用を見直すのか、追加改善するのかを検討します。老朽化による「守りの更改」だけでなく、新しい事業のために仕組みを変える「攻めの更改」もあります。システムを知るベンダとは、稼働後もパートナーとして適切に連携しておきたいところです。

若手・主任クラスの情シス担当者が身につけたい実務能力

「業務を理解する」「関係者と円滑にコミュニケーションする」といった心得だけでは、日々の仕事で何をすればよいか分かりません。そこで、現場でベンダの窓口を担う若手が、主任クラスを目指す際の具体的な到達目標を示します。自担当システムの全体像を説明でき、計画書や報告書にある重要な抜けに気づけることが、一つの目安です。

① 自担当システムの構成と費用を説明できる

まず、担当システムがどの業務を支え、どのシステムと連携しているかを説明できるようにします。主要なサーバ・クラウドサービス、データベース、ネットワーク、認証、外部連携先を、構成図で指し示せる水準が目標です。

また、障害が起きるとどの部署や取引先に影響するか、バックアップや復旧の仕組みはどうなっているかも押さえます。自分が全装置の設定をできる必要はありませんが、どこが止まれば何が止まるのかを説明できることが大切です。

費用面では、初期開発費だけでなく、保守費、クラウド利用料、ライセンス、回線、外注費などの構造を理解します。「今の費用は何に対して払っているのか」「利用量が増えたらどこが増額するのか」が分かれば、更新や追加投資の相談にも参加できます。

② プロジェクト計画書をレビューできる

ベンダから計画書を受け取ったとき、「専門家が作ったから問題ない」と受け取るのではなく、次の点を確認します。

以下の10の観点は、PMI（Project Management Institute）の「PMBOKガイド」第6版※に示された10の知識エリアを参考に、情シス担当者が計画書をレビューするときのチェックポイントとして整理したものです。PMBOKを覚えることが目的ではなく、管理上の確認漏れに気づけるようになることが目的です。

※最新版はこちら

10の観点が一冊の計画書にすべて詳しく書かれているとは限りません。 体制図、品質計画書、課題・リスク管理表などの関連資料も合わせて確認します。大切なのは、各観点について、確認先の文書や担当者を把握し、必要な質問ができることです。

③ Vモデルを理解し、品質の確認方法に目を向けられる

Vモデルは、要件・設計の各段階と、それを検証する試験の対応を考えるための代表的なモデルです。詳細な開発手順が異なるプロジェクトでも、「その要求は、どの試験で確かめるのか」という問いは役立ちます。

情シスの担当者がまず見るべきなのは、RFPや要件定義書に、機能だけでなく非機能要件が書かれているかという点です。非機能要件には、例えば性能、可用性、セキュリティ、バックアップ、障害時の復旧、運用条件などがあります。

非機能要件の中でも、セキュリティは発注側とSIerの認識を合わせておきたい重要な領域です。「セキュリティを強化する」といった抽象的な要求ではなく、どのリスクに、どこまで対応する必要があるのかを明確にすることが求められます。

具体的な検討方法は、次の記事「セキュリティ要件定義の進め方｜リスクアセスメントから対策・残存リスクを決める方法」で解説しています。

セキュリティ要件定義の進め方｜リスクアセスメントから対策・残存リスクを決める方法

セキュリティ要件定義を、RFPや上位基準を起点に、リスクアセスメント、差異評価、対策、残存リスクまで具体化する方法を解説。脅威・脆弱性の分析、関係者との合意、変更時の再アセスメントまで実務例で整理します。

sys-univ.com

2026.09.17

次に、基本設計の内容が要件を反映しているか、基本設計に対応するシステム試験などで、必要な動作を検証できるかを確認します。正常系だけでなく、異常系、ピーク時の性能、障害復旧、外部連携の例外処理まで視野に入れます。今回の重複登録のケースは、まさにこの確認が欠けた例です。

個々の詳細なテストケースを情シスがすべて作る必要はありません。しかし、重要な機能・非機能要件に対して、どの試験で何をもって合格とするのかを説明してもらえることは、品質レビューの基本です。発注側による受け入れ試験は、技術試験の繰り返しではなく、実際の業務が成立するかを判断する場です。

図　Vモデルと要件試験の対応

重要なのは、試験項目の数だけを見ることではなく、要件や設計で決めた内容を、対応する試験で確認できるかという視点です。

この考え方については、次の記事「Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方」で詳しく取り上げています。

Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方

Vモデルは古い開発手法の話ではなく、要件・設計で決めたことをテストで確認する品質保証の考え方です。バックアップ要件の具体例で各工程の対応関係を整理します。

sys-univ.com

2026.07.13

④ 会議体の目的・参加者・決定権限を見抜く

プロジェクト計画書に「週次定例会を実施」と書かれていても、それだけでは足りません。その会議が報告のためなのか、課題を解決する場なのか、正式に意思決定する場なのかを確認します。

ここで目を配りたいのは、「何を決める会議か」「決められる人が出席しているか」「決められないときは誰に上げるか」の3点です。会議が多くても、意思決定の経路が曖昧では意味がありません。

【実体験】全体統括は、すべての詳細調整を引き受ける仕事ではない

複数のベンダが参加する移行プロジェクトで、私は全体統括を担当したことがあります。各社の作業に依存関係があったため、要員を増やして重要な会議の参加漏れを減らし、各社のキーマンと直接連携しました。曖昧な回答が他社の作業の前提になっていないかを確認し、顧客側の責任者にも日々状況を報告しました。

ある会議を欠席した際、アプリケーション間の詳細仕様の調整を、私たち統括が担う前提で話が進みかけていました。しかし、統括は個々の業務仕様の詳細を把握している立場ではありません。発注側の担当者から連絡を受け、具体的な調整は担当者同士で進め、統括は課題の管理と必要な調整会議への参加を担う形に整理しました。

全体統括は、情報を集め、横断的な影響と課題を管理します。何でも自分が引き受けるわけではありません。なお、契約関係のない会社同士で調整する場合も、仕様変更や費用・納期に関わることは、発注者を含む正式な場で決めるべきです。

この経験は情シスの現場担当者にも通じます。各人の責任を明確にし、必要な情報を取りに行き、判断を適切な人へつなぐことが重要です。

⑤ 導入効果を自分の言葉で報告できる

最後は、開発したシステムを「使った成果」で説明する力です。稼働後のKPIは改善したか、運用費に見合う効果があるか、どこに次の改善余地があるか。業務部門と計画値・実績値・差異の原因を確認し、改善の選択肢と次のアクションを添えて情シス管理者に報告できる水準を目指します。

主任クラスに期待されるのは、すべてを一人で解決することではありません。構成・コスト・品質・関係者・導入効果をつないで、プロジェクトや運用の全体像を説明できることです。そこまで視野が広がれば、ベンダとの協議も、計画書のレビューも、単なる報告の受け手から一段進んだ仕事になります。

まとめ：情シスは、ITを業務の成果につなげる仕事

情シスは、システムを発注するだけの部署ではありません。経営や業務の目的を理解し、関係部署とSIerをつなぎ、開発中の判断や品質確認を行い、導入後の効果まで確かめる役割を担います。

新任担当者は、まず自分の周囲の関係者、担当システムの構成、費用、判断権限を把握してください。そのうえで、ベンダの計画書や試験方針を読み、「何を根拠に大丈夫と判断するのか」を質問できるようになることを目指しましょう。

技術は専門家に任せる。しかし、業務上の判断と導入成果の確認まで丸投げしない。 これが、SIerの立場から新任情シス担当者に最も伝えたいことです。

とはいえ、SQLもデータ件数も固まっていない段階で、最適なインデックスを決めることはできません。必要なのは、設計段階で最低限の候補を抽出し、性能試験で効果を確かめながら見直す進め方です。

本記事では、業務側の設計がまだ本格的に動き出していない時期に、システム基盤側でインデックス設計を巻き取り、設計指針・実施要領・検討表を整えて業務チームへ展開した事例を紹介します。技術解説はOracle Database 19cを基準にしています。

事例中に登場する「1万件」「3％」などの各種数値は架空の値です。案件で作業量を絞るために置いた仮の一次選別ルールであり、Oracle 19cの推奨値や実測結果ではありません。

1. インデックス設計とは？「作る・作らない」を根拠付きで決める

インデックスがあれば速くなる、とは限らない

インデックスは、特定の検索条件に対して対象行を効率よく見つけるためのデータ構造です。Oracleで一般的なB-treeインデックスは、等価検索や範囲検索で有力なアクセスパスになります。

ただし、表の大部分を読むSQLでは、インデックス経由の行アクセスがかえって高コストになることがあります。インデックスはINSERT・UPDATE・DELETEのたびに維持されるので、増やすほど書き込み負荷と格納領域も増えます。

設計すべきなのは「どの列に索引を張るか」だけではありません。対象SQL、選択性、データ量、更新頻度、結合や並び替えの条件、既存索引との重複まで含めて、付与する理由と付与しない理由を説明できる状態にすることです。

インデックス設計は物理設計とアプリケーション設計の接点

インデックスの判断には、DBAや基盤SEが持つDBの知識だけでなく、業務チームが把握しているSQL・検索条件・データ分布が必要です。設計書を一人で眺めて完結する作業ではありません。

データベース物理設計の全体像は、次の記事で紹介しています。インデックス設計は、その中でもSQLの処理特性に強く依存する領域です。

データベースの物理設計とは？設計項目・進め方・容量見積の実務をOracle 19cで解説

データベースの物理設計とは？設計項目・進め方・容量見積をOracle 19cで解説。大手SIer20年超の基盤SEが、実案件の物理設計書・課題管理表をもとに、暫定見積、PROCESSES算定、Data Guard設計の実例を紹介します。

sys-univ.com

2026.10.21

2. なぜ単体性能試験の前にインデックス設計が必要なのか

「性能は基盤がやるもの」という空気

このプロジェクトでは、設計が始まって間もない時期で、業務チームは画面や機能の設計に追われていました。インデックス設計どころではありません。加えて、性能は基盤の担当という空気がありました。

性能を基盤に預けたまま工程が進めば、そのツケは性能試験でまとめて返ってきます。単体性能試験では、ある程度のインデックスを付与した状態から性能を確認し、必要に応じて見直すのが現実的です。索引がほとんどない状態で大量のSQLを一斉に試験へ流せば、遅いSQLが多数出て、切り分けだけで工程が埋まります。

当時の設計指針にも、この考え方を明記していました。机上だけで正確に判断するのは難しい。ただ、インデックスをまったく作らずに試験すると、ボトルネックの特定が膨大になる。最低限のインデックス設計を先に行い、試験工程のSQLトレース等で見直す、という方針です。

押し付け合いになる作業を、先に巻き取る

担当が曖昧な作業は、どこのプロジェクトでも押し付け合いになり、誰も手を付けないまま期限を迎えます。インデックス設計はその典型です。

私はインデックス設計を基盤側で引き受けると宣言しました。作業を引き取るだけではなく、判断基準と進め方も基盤側で決める。その方針を示して、先行設計に着手しました。

開発プロセスを知らない人には、性能は基盤がやるものに見えていたようです。リーダークラスの中には、面倒な作業を基盤側が引き受けて助かった、と感じた人もいたように思います。私の見方は逆で、ここを握れば性能試験までの進め方を自分で組み立てられます。経験としても悪くないと考えました。

何を材料に先行したか

先行設計の材料は、SQLマップ、エンティティ定義書、想定レコード件数です。SQLは、プロトタイプアプリを作っていた業務チームと組んで集めました。完成したアプリケーションがなくても、主要な検索のパターンはプロトタイプの段階でかなり見えてきます。

ここで意識したのは、基盤側が業務の最終判断まで奪わないことです。私が作ろうとしたのは、業務側が後から検討を引き継げる共通の土台でした。

3. 設計指針はどう作るか――判断基準と成果物を基盤側で定義する

指針・実施要領・検討表・定義書を分ける

用意した成果物は、役割を明確に分けました。

この分け方の利点は、指針を変更したとき、どのSQLのどの判断に影響するかを追跡できることです。最終的なCREATE INDEX文だけを成果物にすると、「なぜ作ったのか」「なぜ作らなかったのか」が残りません。

ルールは一次選別用の仮基準として置く

指針には、候補を効率よく絞り込むための具体的な目安を入れました。

「1万件」「3％」「5本」「10列」は、Oracle製品の仕様上限でも、一般に正しい性能境界でもありません。限られた時間で検討の優先順位を付けるための基準です。Oracle 19cのオプティマイザは、統計情報、値の分布、I/Oコストなどからアクセスパスを選びます。しきい値だけで採否を確定させないことが前提です。

「例外」と「判断保留」の入口も決めておく

指針を機械的に適用すると、重要なSQLを見落とします。小さい表でも呼び出し回数が多ければ問題になり得ますし、JOINを含むSQLこそ性能の主要因になる場合があります。

実務で作る規約には、「原則」と同じくらい「例外の入口」が必要です。一次選別で除外したSQLも、不要と確定したのか、情報不足で判断保留なのか、実機試験へ回したのかを区別して残します。

4. SQLマップからインデックス付与候補を抽出する手順

手順1：SQLマップ上の管理IDと対象SQLを一覧化する

実施要領では、SQLマップの名前空間と、select・insert・update・deleteに相当するSQLの管理IDを抽出し、付与検討表に転記する手順を定めました。ここでの管理IDはアプリケーション設計資料上の識別子であり、OracleのV$SQL.SQL_IDとは別物です。

現在のプロジェクトなら、アプリケーションのSQL定義、ORMの生成SQL、SQL実行ログなども情報源になります。最初に押さえるべきは、SQLが「どの業務機能で使われるか」「どの表を参照・更新するか」を追跡できる状態にすることです。

手順2：一次候補を機械的に絞り込む

当時の実施要領では、次の順番でSQLを選別しました。

この方法の良いところは、すべてのSQLを同じ深さで分析しないことです。数の多いSQLから一次候補を機械的に選び、判断の難しいSQLと性能上重要なSQLへ検討工数を集中できます。

動的SQLやJOINを含むSQLでも、実行頻度が高いもの、業務上の応答時間が厳しいものは早い段階から実行計画を確認します。

手順3：選択性を仮計算する

想定100万行の表をCUSTOMER_IDで検索し、結果が500行と見積もられる場合、選択性は次のとおりです。

500行 ÷ 1,000,000行 × 100 = 0.05％

当時の基準なら一次候補に残ります。ここから「必ず索引を作る」とは決めません。値の偏り、索引から表へ戻るアクセスの回数、SQLの実行頻度、更新時の負荷、似た索引の有無を確認します。

逆に、100万行中20万行を取得する検索（20％）でも、索引だけで必要な列を取得できるケースや、複数条件の組み合わせで効果が出るケースがあります。数字は候補を絞るための入口で、最終判定ではありません。

手順4：複合インデックスの列順と、索引が使われない書き方を確認する

-- 説明用のSQL。実案件のSQLではありません。
SELECT ORDER_ID, ORDER_DATE, STATUS
FROM   ORDER_HEADER
WHERE  CUSTOMER_ID = :customer_id
AND    ORDER_DATE >= :date_from
AND    ORDER_DATE <  :date_to;

このSQLでは、CUSTOMER_IDの等価条件とORDER_DATEの範囲条件が候補になります。(CUSTOMER_ID, ORDER_DATE)の複合索引を比較対象にできますが、列順は他のSQLでの使われ方や値の分布も踏まえて決めます。

同じ表にCUSTOMER_ID単独、(CUSTOMER_ID, ORDER_DATE)、(CUSTOMER_ID, ORDER_DATE, STATUS)を無計画に重複作成しないことも大切です。Oracle 19cには先頭列を省略した場合のスキップ・スキャンもあるので、「先頭列がないと絶対に使われない」という古いルールをそのまま当てはめるのも適切ではありません。

索引を作っても、SQLの書き方で使われないケースもこの段階で拾っておきます。代表的なのは次の2つです。

• 列への関数適用：WHERE TRUNC(ORDER_DATE) = :d のように列を関数で包むと、ORDER_DATEの通常の索引を使った効率的な範囲検索が難しくなります。日付の範囲条件に書き換えるか、関数ベース索引を検討します。
• 暗黙の型変換：VARCHAR2の列を数値のバインド変数と比較すると、列側にTO_NUMBERが適用され、索引が使われなくなります。SQL規約とバインド変数の型定義で防ぎます。

もう一つ、Oracleで見落とされやすいのが外部キー列の索引です。子表の外部キー列に索引がないと、親表の行削除や主キー更新の際に子表に表レベルのロック（TMロック）がかかり、子表への同時更新が待たされることがあります。検索条件に出てこない列でも、親表を削除・更新する処理があれば付与を検討します。

手順5：「不要」の理由まで記録する

インデックスを付与しない場合も、判断の根拠を残します。付与検討表の記入イメージは次のとおりです。

※この表の管理ID・表名・SQL条件は説明用の例です。

5. 実務事例：先行設計で「作らない」判断も残す

業務領域ごとに付与判断が分かれた

業務グループが本格的に設計へ取りかかる前に、私は開発が先行する業務領域について、基盤側でインデックスを設計しました。結果は次のとおりです。

「3」「8」はインデックスの本数ではなく、インデックスを付与したテーブルの数です。業務Cでは当時の一次選別基準に該当する表がなく、後工程の再評価対象として判断を記録しました。

すべての業務領域に同じように索引を作るのではなく、候補を抽出し、作らない場合も理由を残して後から見直せるようにする。先行設計で狙ったのはそこです。

中間一致・後方一致は、通常の選別とは切り分けた

業務Aには、中間一致・後方一致検索の性能課題がありました。通常のB-tree索引は LIKE 'ABC%' のような前方一致には有効な場合がありますが、LIKE '%ABC' や LIKE '%ABC%' では、範囲スキャンで効率よく絞り込めません。

なお、LIKE検索では、インデックスの利用可否だけでなく、検索条件の解釈にも注意が必要です。

過去に私が担当したプロジェクトでは、Oracleの不具合により、全角アンダースコア「＿」がワイルドカードとして扱われ、想定外の大量ヒットが発生しました。

実機検証による原因調査から、LIKECの検証、SQL改修・運用回避の判断、再発防止までの経緯は、次の記事で解説しています。

OracleのLIKE検索でほぼ全件ヒット？全角アンダースコアの不具合とSQL改修・再発防止の実例

Oracle LIKE検索で全角アンダースコア「＿」がワイルドカード化した障害事例。ORA-01424とLIKECの検証、パッチと運用回避の対策比較、保守サポートと根拠をそろえた判断を解説。19cでは全角は通常文字、半角%・_を文字として探す場合はESCAPEを使用。

sys-univ.com

2026.10.21

この検索は一次選別の流れには乗せず、中間一致・後方一致に対応する索引を個別に設計し、定義書と分析資料に設計理由を残して業務側へ引き継ぎました。現在の案件で同じ要件が出た場合は、Oracle Textなどの適用可否も含め、検索要件、運用負担、ライセンス条件を合わせて評価します。

設計に使った資料の「時点」を残して引き継ぐ

先行設計で気をつけたのは、使った情報が必ずしも最新ではないことです。SQLマップ、エンティティ定義書、想定レコード件数は、それぞれ異なる時点の資料でした。列のカーディナリティも、一部は想定を置いて判断しています。

業務グループへの引き継ぎでは、設計に使った各資料の時点と前提条件を明記し、最新資料との差異やカーディナリティの見込み違いがあれば再評価するよう依頼しました。基盤側で設計を先行させることと、業務側の検証を省略することは別の話です。

入力となる件数やSQLが変われば、同じ判断表でも結論は変わります。使用した資料の版と判断日を残すことは、インデックス名を決めることと同じくらい重要です。

6. 業務グループへ展開する――説明会・修正・引き継ぎ

説明会で手順をそろえる

一部の業務領域を基盤側で先行設計できても、プロジェクト全体のSQLを基盤チームが把握し続けるのは現実的ではありません。SQLの機能要件や業務データの分布を一番よく知っているのは、各業務グループです。

そこで、業務GLとインデックス設計担当者を集めて説明会を開き、設計指針、実施要領、付与検討表、定義書の作り方を一通り説明しました。インデックスの一般的な仕組みではなく、SQLマップのどこを見て、どの条件で候補を絞り、検討表や定義書に何を記録するのか。基盤側の先行設計を実例として見せ、業務グループでも同じ手順を踏めるようにしました。

たたき台を出すと、指摘が出てくる

説明会では、作成した指針や検討結果について指摘が出ました。自分たちではなかなか手を付けないのに、たたき台には意見が出る。正直に言えば、カチンときたのも事実です。

ただ、指摘を受けてあるSQLの判定を「必要」から「不要」に改め、実施要領にも作業手順の説明を追記しています。白紙の段階では出てこなかった業務側の知見が、たたき台を出したことで初めて表に出てきたわけです。最終的に同じ基準で合意できたので、結果としては良かったと思っています。

指摘を反映した版を共通の設計資料として配布し、業務側の検討へ引き継ぎました。

誰が何を更新するかまで決める

引き継ぎでは、役割も整理しました。基盤・DBAは指針と技術上の制約、共通レビュー、実行計画の技術支援を持つ。業務・アプリケーション担当は、SQLとデータ件数の更新、候補抽出、定義書の作成を持つ。性能試験担当は、試験条件と実績値、SQLトレースや実行計画の取得を持つ。GLは役割分担と改訂ルールの周知、判断保留の解消を持つ。

肩書きはプロジェクトによって変わります。決めておくべきなのは、設計の根拠となった情報が更新されたとき、誰が再判定するかです。

7. Oracle 19cでは、設計したインデックスをどう検証するか

机上見積と実機の結果を分けて見る

インデックスの最終的な有効性は、実行計画と実行統計で確認します。見る対象は検索時間だけではありません。

データ量、統計情報、バインド変数、SQLの条件をそろえ、索引がある場合とない場合を比較します。差が出ても索引だけが原因とは限らないので、実行計画の変化を必ず確認します。

DBMS_XPLANで実行計画と実績値を見る

Oracle 19cでは、DBMS_XPLAN.DISPLAY_CURSORで実際に実行したSQLの計画を確認できます。行数やBuffersの実績値を取るには、対象SQLにGATHER_PLAN_STATISTICSヒントを付けるのが影響範囲が狭く扱いやすい方法です。セッション全体で statistics_level = ALL にする方法もありますが、そのセッションのすべてのSQLに計測負荷がかかります。

-- 説明用の手順例。実案件の実測結果ではありません。検証環境で実行してください。
SELECT /*+ GATHER_PLAN_STATISTICS */
       ORDER_ID, ORDER_DATE, STATUS
FROM   ORDER_HEADER
WHERE  CUSTOMER_ID = :customer_id
AND    ORDER_DATE >= :date_from
AND    ORDER_DATE <  :date_to;

SELECT *
FROM   TABLE(DBMS_XPLAN.DISPLAY_CURSOR(
         sql_id          => :target_sql_id,
         cursor_child_no => NULL,
         format          => 'ALLSTATS LAST'));

DBMS_XPLANの参照には、動的パフォーマンスビューへのアクセス権限が必要です。検索1回だけで判断せず、代表的なバインド値、データ量、実行頻度で確認します。

統計情報とカーディナリティを確認する

インデックスを作っても、オプティマイザが使うとは限りません。特定の値にアクセスが集中する列では、平均的な選択性と実態が一致しないことがあります。

SELECT table_name, num_rows, blocks, last_analyzed
FROM   user_tables
WHERE  table_name = 'ORDER_HEADER';

SELECT index_name, blevel, leaf_blocks,
       distinct_keys, clustering_factor, last_analyzed
FROM   user_indexes
WHERE  table_name = 'ORDER_HEADER';

統計情報が古い場合は、検証条件を整えたうえでDBMS_STATSによる収集を検討します。収集前後で実行計画が変わる可能性があるので、性能検証の途中で無計画に統計情報を更新しないようにします。

Invisible IndexとAutomatic Indexingの使いどころ

Oracle 19cのInvisible Indexは、索引をオプティマイザから見えなくする機能です。検証用セッションで ALTER SESSION SET OPTIMIZER_USE_INVISIBLE_INDEXES = TRUE; とすれば、他のセッションに影響を与えずに、その索引がある場合の実行計画を確認できます。ただし、Invisible IndexもDMLのたびに維持されます。参照側の比較には使えますが、更新負荷の検証は別に必要です。

自動インデックス作成機能（Automatic Indexing）は、Oracle 19cの通常のEnterprise Edition（EE）だけでは利用できません。OracleのLicensing Informationでは、Exadata上のEnterprise Edition on Engineered Systems（EE-ES）や対象のExadata Database Serviceで利用可能とされています。Autonomous Databaseでも提供されています。導入を検討する際は、製品・サービスと契約上の利用条件を確認します。

特定の機能を使うことがゴールではありません。設計時の仮説を計測で更新し、その理由を記録することがゴールです。

8. まとめ：インデックス設計は「試験前に仮説を作る仕事」

インデックス設計は、すべてのSQLを完成させ、十分な試験データを揃えてから始める作業ではありません。大規模開発では、業務チームの設計進捗や資料の不足に関係なく、単体性能試験の準備期限が来ます。

今回の事例では、基盤側でSQLマップ・エンティティ定義・想定件数から一次候補を抽出し、設計指針、実施要領、付与検討表、インデックス定義書を用意しました。先行設計の結果は、資料の時点と前提を明記して業務チームへ引き継ぎ、説明会での指摘を受けて判定と手順を直しています。最終的な有効性は、Oracle 19cの実行計画と実績値で確かめる前提です。

所感

振り返ると、一番の収穫は、試験に入る時点で「なぜこの索引があり、なぜこの表にはないのか」を説明できる状態を作れたことです。単体性能試験で遅いSQLが出ても、付与検討表を見れば、当時の前提と判断理由に戻れます。前提が変わっていれば判断を更新し、変わっていなければ実行計画を見て原因を絞り込む。手戻りをゼロにはできなくても、手戻りの範囲は小さくできます。

指針も最初から完成していたわけではなく、説明会の指摘を受けて判定と手順を直しました。完璧な規約を目指して止まるより、たたき台を出して業務側の知見を取り込み、同じ版を全員で使う。大規模開発のインデックス設計は、この進め方が現実的だと考えています。

参考資料（Oracle公式）

• Oracle Database 19c SQL Tuning Guide
• Query Optimizer Concepts：選択性・カーディナリティ
• Optimizer Statistics Concepts：Clustering Factorなど
• DBMS_XPLAN：DISPLAY_CURSOR
• Managing Indexes：Invisible Indexなど
• Database Licensing Information：Automatic Indexingの利用条件

関連記事

データベースの物理設計とは？設計項目・進め方・容量見積の実務をOracle 19cで解説

データベースの物理設計とは？設計項目・進め方・容量見積をOracle 19cで解説。大手SIer20年超の基盤SEが、実案件の物理設計書・課題管理表をもとに、暫定見積、PROCESSES算定、Data Guard設計の実例を紹介します。

sys-univ.com

2026.10.21

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

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

sys-univ.com

2026.08.03

本記事では、その中からデータベースエンジニア（DBA）を取り上げます。

SEの職種全体と、それぞれの役割の違いについては、次の記事で詳しく解説しています。

システムエンジニアの種類と仕事内容｜SIerのSEはどこまで担当するのか

システムエンジニアの種類と仕事内容を、PM、アプリ、AP基盤、インフラ、ネットワーク、DBに分けて解説。大手SIerで20年以上働いた筆者の経験から、SEのキャリアの広がりや求められるスキルも紹介します。

sys-univ.com

2026.08.25

データベースエンジニアとは

データベースエンジニアは、システムが扱うデータを安全に保存し、必要なときに正しく、十分な速度で利用できるデータベースを設計、構築、運用する職種です。

「データベースエンジニア」という言葉から、テーブル設計やデータモデリングを想像する人もいると思います。私が関わってきたSIerのプロジェクトでは、データベースの構築、性能管理、権限管理、監視、バックアップ、障害対応を担うDBA（データベース管理者）を指すことが一般的でした。

ここからは、長く担当してきたOracle DBAの実務を軸に、物理設計、構築、性能管理、セキュリティと監査、運用、復旧を見ていきます。製品ごとにアーキテクチャや実装方法は異なりますが、DBAに求められる基本的な役割と考え方には共通する部分があります。

DBAの中心的な役割は、論理的に整理されたデータモデルを、安定して稼働できる物理構成へ落とし込むことです。データベース製品をインストールして初期設定するだけではありません。アプリケーションが扱うデータ量、処理量、同時実行数、更新頻度、障害時の復旧要件を踏まえ、業務特性に合った物理構成と運用方式を設計します。

ここでいうデータモデルは、顧客、契約、申請、承認など、業務で扱う情報を整理し、どのような単位で管理するのかを定めたものです。この構造を設計する作業をデータモデリングと呼びます。業務要件やアプリケーションの処理と密接に関わるため、概念モデルや論理モデルの作成は、アプリケーション側が中心になることが多い領域です。

DBAも、完成したデータモデルを受け取るだけではありません。正規化の妥当性、テーブルや列の構成、主キーや外部キー、インデックス、データ量、検索や更新の特性を確認し、性能や運用の観点からレビューや助言を行います。

テーブル設計は、稼働後に変更すると、SQL、画面、バッチ、外部システムとの連携、データ移行、テストまで広い範囲へ影響します。将来のデータ増加や機能追加も見据え、物理設計へ進む前の段階からDBAが関わることが重要です。

主な担当領域は、大きく次のように分けられます。

構築と物理設計

• データベース製品と構成の選定

• インストールと初期設定

• 表領域、データファイル、ログ領域の設計

• 各種初期化パラメータの設計

性能と容量管理

• SQLと実行計画の分析

• インデックスや統計情報の管理

• 性能チューニング

• データ容量と増加量の見積もり

セキュリティと運用

• ユーザー、権限、ロールの設計

• 監査要件への対応

• 監視とログ管理

可用性とデータ保護

• 冗長化と障害時の切り替え

• バックアップとリカバリの設計

移行と製品管理

• システム移行（データ・環境・運用）

• バージョンアップや製品更改

• ライセンスと保守契約の管理

製品ごとに仕組みや用語は異なりますが、アプリケーションの特性を踏まえて構成を決め、稼働後も性能、セキュリティ、可用性、復旧を管理するという役割は共通しています。

アプリケーションの特性から物理構成を設計する

データベースの構築は、アプリケーションの処理内容を理解しなければ始められません。

どの程度のデータを登録し、どの時間帯に更新が集中するのか。長時間の検索、大量更新、夜間バッチなどがあるのか。アプリケーションの処理特性によって、必要なデータベース構成は変わります。

Oracleでは、REDOログのグループ数やサイズ、UNDO表領域の容量と保持期間、各表領域の初期容量や自動拡張の可否などを決めます。これらは、製品の標準値をそのまま採用すればよいものではありません。

更新量に対してREDOログが小さすぎれば、ログスイッチが頻発し、チェックポイント処理の負荷も高まります。次に使用するロググループのチェックポイントやアーカイブが完了していなければ、更新処理に待機が発生することもあります。

長時間の検索や大量更新に対してUNDO領域の容量や保持期間が不足すると、読み取り一貫性に必要な過去のデータを保持できません。ORA-01555（スナップショットが古すぎます）などによって、検索処理が失敗することもあります。

表領域の容量や拡張方法が不適切であれば、データの増加によって業務処理が停止する可能性があります。

容量の見積もりは、初期構築時だけの作業ではありません。どの表が月次や年次でどれだけ増えるのかをアプリケーションチームから引き出し、拡張の余地とストレージの追加時期まで計画に落とします。

こうしたデータベースの物理設計では、設定値を決めること以上に、何を検討し、どのような根拠で判断するかが重要です。

具体的な設計項目や進め方については、実際のプロジェクトの容量見積や課題管理の事例をもとに次の記事で詳しく解説しています。

データベースの物理設計とは？設計項目・進め方・容量見積の実務をOracle 19cで解説

データベースの物理設計とは？設計項目・進め方・容量見積をOracle 19cで解説。大手SIer20年超の基盤SEが、実案件の物理設計書・課題管理表をもとに、暫定見積、PROCESSES算定、Data Guard設計の実例を紹介します。

sys-univ.com

2026.10.21

DBAが押さえるべきシステム移行の三要素

システム移行というと、旧システムのデータを新システムへ移し替える作業を想像しがちです。実際の移行は、データ移行、環境移行、運用移行の三つで構成されます。DBAはデータ移行を中心に、環境移行と運用移行にも関わります。

データ移行では、移行対象、停止時間、移行方式、データ変換、移行後の確認方法を設計し、本番相当のデータ量でリハーサルを行います。移行後の統計情報が適切でなければ、データを正しく移せても、業務開始後に性能問題が発生することがあります。Oracle 19cへのバージョンアップでは、統計情報の更新を契機に実行計画が変化した事例もあり、移行後は主要なSQLの実行計画と性能まで確認する必要があります。

Oracle 19c更改後に実行計画が変わる――パーティション削除時の統計情報更新と影響調査漏れ

Oracle Database 19cへの更改後、DROP PARTITIONを契機に表統計の一部が更新され、実行計画とSQL性能が変化した事例を解説。AWRやPLAN_HASH_VALUEによる原因調査、統計情報の再収集、SQL Plan Baseline、更改時の影響調査と試験の観点を整理します。

sys-univ.com

2026.07.22

環境移行では、データベースを構築するだけでなく、tnsnames.oraや接続文字列、DNS名などを新環境へ切り替えます。運用移行では、監視、バックアップ、ログ収集、ジョブ、障害対応などを新環境でどのように実現するのかを決めます。バージョンや提供形態が変われば、従来の運用ツールやスクリプトがそのまま動くとは限りません。

データを移し替えただけでは、システム移行は完了しません。移行の全体像と、どこで失敗が起きやすいのかは、別の記事で整理します。

マネージドサービスでも設計は残る

マネージドサービスを利用する場合も、この考え方は変わりません。

RDSではパラメータグループを通じて設定を変更し、変更できる範囲は製品そのものより狭くなります。

標準値のまま構築してよいという意味ではありません。決められる範囲が限られた中で、業務特性に合う値を選ぶ作業が残ります。

クラウドサービスが引き受けるのは、データベース運用の一部です。どのような性能が必要なのか、障害時にどこまで業務を継続するのか、どの時点までデータを戻すのかといった判断まで、クラウド側が決めてくれるわけではありません。

RDS for Oracleへ移行すると、SYSDBA権限やOSへのアクセス、ストレージ管理、監査ログの扱いなど、オンプレミスで前提としていた運用をそのまま持ち込めない場面があります。具体的な設計ギャップと代替方法は、次の記事で詳しく解説しています。

RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ

RDS for Oracleではオンプレ運用の前提が通用しない。Storage-Full、アーカイブログ、SSH不可など、開発中に見えた9つの設計ギャップと代替アプローチを整理します。

sys-univ.com

2026.08.30

データベースは構築後も変化し続ける

システム基盤との大きな違いの一つは、構築後も継続的な調整が必要になることです。

サーバーやOSは、構築時に適切な構成を決めれば、稼働後に設定を大きく変えずに運用できるケースもあります。

データベースでは、データ量や分布、利用者数、業務処理の内容が日々変化します。昨日まで高速だったSQLが、データの増加や統計情報、実行計画の変化によって突然遅くなることもあります。

一つのSQLを改善して終わりとは限りません。業務機能の追加やデータ量の増加によって別の処理が遅くなり、新たな実行計画の変化が発生します。

稼働後も監視、分析、改善を繰り返すのが、データベース運用の実態です。

性能問題はデータベースだけでは解決できない

性能問題が発生した場合、CPUやメモリの使用率を見るだけでは原因を特定できません。

遅いSQLを特定し、実行計画や待機状況を確認しながら、検索対象となるデータ量、結合順序、アクセスパス、統計情報、キャッシュの状態、I/O、ロック競合などを横断的に調べます。

同じSQLでも、必要なデータがメモリ上にあるか、ストレージから読み込むかによって処理時間は変わります。過去に生成された実行計画が再利用されるか、新しい実行計画が選ばれるかによっても、性能は大きく変化します。

性能問題をデータベースの設定だけで解決できるケースは、実際にはそれほど多くありません。

SQLや業務ロジックそのものに原因があれば、データベース側のパラメータを変更しても根本的な改善にはなりません。

改善策は、インデックスの追加や変更、統計情報の更新、必要に応じたSQLヒントの付与といったデータベース側の対応に限りません。SQLの書き換え、処理の分割、検索条件の見直し、データの持ち方の変更が必要になることもあります。

接続数やトランザクション管理に問題があれば、AP基盤チームへコネクションプールや共通処理の修正を依頼します。

CPUやストレージI/Oが不足していれば、システム基盤チームとリソース増強や構成変更を検討します。業務ルールを実装した共通部品が非効率であれば、アプリケーションチームの改修が欠かせません。

実際にあった例では、検索画面の入力にアンダースコアが含まれたことで、想定を大きく超えるデータが検索され、システムが高負荷になったことがありました。

当時使用していたOracleのリリースでは、全角の「＿」や「％」がLIKE検索のワイルドカードとして扱われることがあり、NULL以外のほぼ全件が検索対象となっていました。

サポートへの照会とバージョンごとの再現試験を重ねると、旧リリース向けにエスケープ処理を入れた場合、新しいリリースへアップグレードした後には逆にエラーになることも分かりました。

最終的には、バージョンが変わっても動作が変わらない書き方をSQLコーディング規約へ反映しました。

本来はアプリケーション側のSQL実装に関わる問題でも、データベースが最初に疑われ、DBAが製品仕様とSQLの両面から切り分け、再発防止まで取りまとめることがあります。

このLIKE検索の問題については、実際の障害対応をもとに、原因調査から対策の比較、保守サポートとの技術的な確認、SQL規約による再発防止までを次の記事で詳しく解説しています。

OracleのLIKE検索でほぼ全件ヒット？全角アンダースコアの不具合とSQL改修・再発防止の実例

Oracle LIKE検索で全角アンダースコア「＿」がワイルドカード化した障害事例。ORA-01424とLIKECの検証、パッチと運用回避の対策比較、保守サポートと根拠をそろえた判断を解説。19cでは全角は通常文字、半角%・_を文字として探す場合はESCAPEを使用。

sys-univ.com

2026.10.21

権限とロールはアプリケーションと切り離せない

権限とロールの設計も、アプリケーションとの調整が避けられない領域です。

既存システムを引き継いだとき、アプリケーションのスキーマにDBA相当のロールがそのまま付与されていたことがありました。

セキュリティ要件の観点で認められる状態ではなく、必要な権限だけを個別に付与する形へ絞り込むことになりました。

権限を外した結果、これまで動いていた処理が動かなくなりました。どの処理がどのオブジェクトへどう触れているのかを整理した資料はアプリケーションチームにも残っておらず、発生したエラーと処理を突き合わせながら、必要な権限を一つずつ特定していく作業になりました。

権限を細かく制限するほど、影響確認と試験にも相応の工数がかかります。

マネージドサービスでは、この制約がさらに強くなります。

RDS for OracleではSYSDBA権限そのものが提供されず、管理操作は用意されたパッケージ経由に限定されます。オンプレミスで当たり前に実行していた手順が使えない前提で、権限の設計と運用手順を組み立て直す必要があります。

監査ログは出せばよいわけではない

監査も、要件を満たす設定を入れれば終わりという作業ではありません。

とりあえず監査ログを出力する設定にしたところ、膨大な量のログが出力され、何を監査対象とするのかを決める作業の方が大変でした。

すべてのSQLを記録すれば、性能とストレージへ影響します。絞りすぎれば、問題が起きたときに誰が何をしたのか説明できません。

特定のテーブルへのアクセスだけを対象にするのか、更新だけでなく参照まで含めるのか、保持期間をどれだけにするのかを、業務要件と法令要件の両面から決めます。

個人情報や決済に関わるデータでは、誰がいつどのデータへ触れたのかを後から説明できることが求められます。

共通のアプリケーションユーザーで接続していれば、データベース側の記録だけでは実際の利用者までたどれません。

アプリケーションのログと突き合わせて追跡できる設計にするのか、クライアント識別情報をデータベースへ渡してもらうのかを、アプリケーションチームと事前に決めておく必要があります。

監視も、稼働状況を眺めるためのものではありません。

表領域の使用率と増加傾向、権限の変更、想定外の接続元、監査ログが想定どおり出力・保管されているかなど、業務が止まる前に気づくべき事象と、後から説明を求められる事象の両方を対象にします。

冗長化しても業務を継続できるとは限らない

データベースの可用性を高めるには、障害が発生してからデータを復旧するだけでなく、待機系へ切り替えて業務を継続できる構成も設計します。

オンプレミスではRACやData Guard、クラウドではRDSのMulti-AZなど、障害の範囲、許容停止時間、許容できるデータ損失、費用に応じて方式を選びます。

冗長化構成を用意しても、データベースが待機系へ切り替わるだけで業務を継続できるとは限りません。

アプリケーションの再接続、接続プールの回復、DNSキャッシュ、切り替え中に失敗した処理の扱いまで含め、システム全体の復旧動作を設計します。

私が担当したシステムでは、正常時の通信遅延を抑えるため、WebサーバーとAPサーバーをRDSのプライマリと同じAZ側へ寄せて稼働させていました。正常時の性能を優先しつつ、障害時にはRDSが別のAZへ切り替わることを前提とした構成です。

RDSが別のAZへフェイルオーバーすると、Web／APサーバーとデータベースの通信がAZをまたぐ場合があります。通信経路が変わればレイテンシーも変化し、データベースアクセスの多い業務では性能へ影響する可能性があります。

確認すべきなのは、フェイルオーバーが成功したかどうかだけではありません。RDSが反対側のAZへ切り替わった状態でも、オンライン処理の応答時間やバッチ処理時間が要件内に収まるのかを試験します。

通常時と同じ性能を維持できない場合には、あらかじめ定めた縮退運転の条件で業務を継続できることまで確認します。Web／APサーバーを別AZ側へ切り替える構成であれば、アプリケーションとデータベースを同じAZ側で動かせるかも検証対象です。

RDS Multi-AZで自動化されるのは、データベース側の待機系への切り替えです。その後にアプリケーションが正常に再接続し、性能要件や縮退要件を満たして業務を再開できるかは、利用者側で設計し、試験しなければなりません。

バックアップがあっても復旧できるとは限らない

データベースに障害が発生すれば、システム全体が停止したり、複数の業務が同時に利用できなくなったりする可能性があります。データの破損や消失が起きれば、サーバーを再起動するだけでは復旧できません。

重要なのは、どの時点まで戻すのかという要件を、事前にアプリケーションチームと合意しておくことです。

前日の夜間バックアップまで戻してよいのか、障害の直前まで戻す必要があるのか。直前まで戻す要件があるなら、アーカイブログモードで運用し、アーカイブログの出力先、退避方法、保持期間まで設計に含めます。

判断が難しいのは、夜間バッチの途中で障害が発生した場合です。

どのジョブまで完了していたのか、どこまで戻せば再実行できるのか、中途半端な状態で残ったデータをどう扱うのかは、データベース側だけでは決められません。

復旧の目標時間と、戻した後に業務をどの順番で再開するのかを含めて、アプリケーションチームと一緒に決めます。バックアップを取得しているだけでは不十分です。

データファイルが壊れた場合、誤って大量のデータを削除した場合、バッチの途中で停止した場合では、手順も所要時間も変わります。

ユースケースごとに、実際にリストアとリカバリを実施します。本当に戻るのか、目標時間内に終わるのか、戻した後にアプリケーションが正しく動くのかを、アプリケーションチームと合同で確認しておきます。

RDSの復元は元のインスタンスを巻き戻す処理ではない

マネージドサービスを利用する場合も、復旧方法を事前に決めておく必要があります。

RDSのポイントインタイムリカバリでは、バックアップ保持期間内の任意の時点へ復元できます。直近については制約があります。トランザクションログは通常5分間隔でAmazon S3へアップロードされるため、指定できる最新の復元時点は現在時刻より数分前になることがあります。実際に復元可能な最新時点は、LatestRestorableTimeで確認します。

注意が必要なのは、指定した時点の状態が新しいDBインスタンスとして作成され、元のインスタンスが巻き戻るわけではないことです。

復旧時間には、新しいインスタンスの作成だけでなく、DB接続先情報の変更やDNSの切り替え、接続確認に要する時間も含まれます。

アプリケーションがRDSのエンドポイントを直接参照するのか、DNS名で接続先を抽象化するのかを含め、切り替え方式を事前に設計しておかなければ、復旧目標時間には収まりません。

旧インスタンスをいつ削除するのか、切り戻せる状態をどこまで残すのかも決めておきます。また、復元できる単位にも制約があります。

この復元方式では、DBインスタンス全体が新しいインスタンスとして作成されます。既存のDBインスタンスを過去の状態へ戻したり、特定のテーブルだけを1時間前の状態へ戻したりする機能ではありません。

誤更新への対応では、復元した別インスタンスから対象データを抽出して取り込むなど、別の方式を組み合わせる必要があります。

データベース製品によって、アーキテクチャと設計上の判断は変わる

以上、Oracleを主な例として説明しました。

近年は、一つのシステムでも、業務データにはリレーショナルデータベース、ログや非定型データには別のデータストアを利用するなど、用途に応じて複数の製品を組み合わせる構成も増えています。

OSはAmazon LinuxからRed Hat Enterprise Linuxへ変わっても、プロセス、メモリ、ファイルシステム、権限管理など、基本的な仕組みや設計の考え方には共通する部分があります。データベースは、製品の種類が変わると設計思想そのものが大きく変わることがあります。

同じリレーショナルデータベースでも、Oracle、PostgreSQL、MySQLでは、運用機能、可用性構成、拡張方式、チューニングの考え方に違いがあります。OracleとMongoDBのようなドキュメント指向データベースであれば、データの持ち方、整合性の考え方、検索方法、拡張方式まで異なります。

製品が変わっても、DBAに求められる基本的な役割や考え方には共通する部分があります。変わるのは、その役割を実現するためのアーキテクチャ、機能、制約、管理方法です。

操作方法だけでなく、データモデルやトランザクション、可用性、性能設計の前提から学び直さなければならないこともあり、ここにDBAという職種の難しさがあります。

まとめ

DBAは、データベース製品を構築するだけの担当者ではありません。

アプリケーションの処理を理解して性能問題の原因を横断的に分析し、権限や監査の要件を業務と擦り合わせ、障害が起きてもデータを失わずに業務を再開できる状態を維持し続ける役割です。

構築が終わっても仕事は終わらず、性能問題や障害が起きれば、DBAが原因分析と関係チームの調整の中心に立ちます。

データ量が増えても必要な性能を保ち、稼働後もデータの安全性と業務継続を支える。その責任を担いながら、採用する製品や要件の変化に応じて知識を更新し、新しい設計思想へ適応し続けるところに、DBAの専門性があります。

関連記事

システム開発では、データベースエンジニアだけで仕事が完結することはありません。 アプリケーション、ネットワーク、システム基盤など、それぞれの担当が連携してシステム全体を作ります。

アプリケーションエンジニアの仕事
業務要件を仕様へ落とし込み、設計・実装・テスト・障害対応まで担当するアプリケーションエンジニアの仕事を解説しています。

アプリケーションエンジニアの仕事｜決める、そろえる、動かし続ける

アプリケーションエンジニアの仕事内容を、SIerでの実務経験をもとに解説。曖昧な要望を仕様へ変換する設計、画面・帳票・バッチ・API、テスト、性能問題、障害対応まで、担当範囲と責任を具体例で整理します。

sys-univ.com

2026.08.05

ネットワークエンジニアの仕事
通信経路、ルーティング、通信制御、冗長化、外部ネットワーク接続、障害時の切り分けなど、ネットワークエンジニアの仕事を解説しています。

ネットワークエンジニアの仕事｜通す、通さない、切り替える

ネットワークエンジニアの仕事内容を、通信経路、VLAN、ルーティング、ファイアウォール、冗長化、外部ネットワーク接続、障害切り分け、AWSまで実務経験をもとに解説します。

sys-univ.com

2026.08.11

実際のプロジェクトでは、Oracleのデフォルト設定をほぼそのまま使用し、表領域の初期容量を決めて自動拡張を有効にするだけで、データベースを構築しているケースも見受けられます。しかし、データが格納でき、システムが正常に動作することと、性能・可用性・運用性まで考慮した物理設計ができていることは別です。

物理設計で重要なのは、設定値そのものではなく、業務特性やデータ量、アクセス傾向、将来の増加量などを把握し、何を検討し、どのような根拠で判断し、どう検証するかというプロセスです。

本記事では、実際のプロジェクトで使用した物理設計書、課題管理表、容量見積Excelをもとに、データベースの物理設計で押さえるべき検討項目と、設計を進めるための具体的なアプローチを解説します。技術解説にはOracle Database 19cを使用し、容量見積や接続数の算定、性能・運用面での設計判断を実例とともに紹介します。

なお、実務事例は過去のプロジェクト資料を匿名化・再構成したものであり、掲載する設定値は案件固有のものです。個々の数値を正解として示すのではなく、自分のプロジェクトで適切な設計値にたどり着くための考え方を伝えることを目的としています。

データベースの物理設計とは？

データベースの物理設計とは、論理設計で定義されたデータを、実際のデータベース環境にどのように格納し、安定して稼働させるかを具体化する工程です。

表領域やデータファイル、メモリ、REDOログ、バックアップなどを設計し、性能・容量・可用性・運用性に関する要件を実現します。

概念設計・論理設計・物理設計の違い

データベース設計は、大きく概念設計・論理設計・物理設計の3段階に分けられます。

例えば、注文データを5年間保存するシステムを考えます。

論理設計では注文テーブルの項目やキー、テーブル間の関連を定義します。

一方、物理設計では、初期データ120万件、年間増加30万件という条件から5年後の件数を270万件と見積もり、必要な表領域容量、データファイルの拡張方法、バックアップ方針などを決めます。

つまり、論理設計が「どのようなデータを管理するか」を決める工程であるのに対し、物理設計は「そのデータをどのような構成で稼働・管理するか」を具体化する工程です。

物理設計は誰が担当するのか

物理設計は、インフラエンジニア、DBA、アプリケーション担当者が連携して進めます。

担当領域の違いや連携については、以下の記事で詳しく解説しています。

システムエンジニアの種類と仕事内容｜SIerのSEはどこまで担当するのか

システムエンジニアの種類と仕事内容を、PM、アプリ、AP基盤、インフラ、ネットワーク、DBに分けて解説。大手SIerで20年以上働いた筆者の経験から、SEのキャリアの広がりや求められるスキルも紹介します。

sys-univ.com

2026.08.25

実際のプロジェクトでは、この担当範囲の境界で情報が不足することがあります。

私が携わった案件でも、ミドルウェア製品が使用するセッション管理用テーブルについて、製品ベンダーに仕様を確認してからスキーマや表領域を決定しました。また、帳票データの型がBLOBなのかCLOBなのかについて、関係者間で認識が異なっていたこともありました。

物理設計では担当者間の役割分担を明確にするとともに、必要な情報の提供元も確認する必要があります。

本記事では、インフラエンジニア・DBAの立場から行う物理設計に焦点を当て、Oracle Database 19cを例に解説します。

データベース物理設計でやること・設計項目一覧

物理設計では、ソフトウェア構成、表領域、初期化パラメータ、可用性、通信、運用、セキュリティなどを決定します。

実務で使用した物理設計書の章立ても参考にしながら、Oracle 19cで検討する設計項目と成果物、実務上の進め方を整理します。

物理設計の主要設計項目と成果物

【実務事例：物理設計書の章立てから必要項目を把握する】

実際の物理設計書は全10章で構成されていました。次の表は、その章立てを手がかりに、Oracle 19cの物理設計で確認すべき項目を整理したものです。

OS・ストレージやHugePages、ASMなどは、設計書の章立てとは別に、基盤設計側との責任分界を決めて確認します。表は設計項目の把握に使い、実際の成果物の構成はプロジェクトごとに合意します。

最初にエディション・ライセンスとCDB/PDBの設計単位を確定し、後続の表領域やメモリ設計の制約条件を整理します。

物理設計の主な成果物

成果物の名称や分け方はプロジェクトによって異なり、初期化パラメータ一覧などを環境定義書に含める場合もあります。

【実務事例：成果物とフォーマットの合意】

実際の課題管理表では、設計作業の初期に、設計書のフォーマットについて確認を行っていました。

その後、成果物を「データベース詳細設計書」と「環境定義書」の2つとする方針で合意しています。

さらに設計途中で、統一テンプレートが提供され次第、差し替える方針が決まりました。

この経験から、物理設計では内容の検討に入る前に、成果物の名称、記載範囲、使用するテンプレート、レビュー方法を関係者と合意することが重要だと考えています。

物理設計の進め方と依存関係

物理設計の実務では、最初に必要な情報がすべて揃うとは限りません。

実案件の課題管理表にも、システム特性、テーブル定義、データ件数、同時接続数、LOB容量、バッチ処理量などの情報を関係者へ依頼した記録が多数残っています。

設計項目と必要情報の依存関係

【実務事例：設計FIXの延期】

実案件の課題管理表では、1月中旬から課題が起票されていました。

物理設計書のFIXは当初2月末を予定していましたが、容量見積に必要なデータを2月中に提供できないことが判明し、3月末へ延期されています。

一方、データが揃うまで設計を止めたわけではありません。未確定の情報には暫定値を置いて設計を進め、資料の受領後に見直しました。具体的な方法は後述の容量見積の章で解説します。

物理設計を進める6つのステップ

⓪ 成果物とフォーマットを合意する

設計書、環境定義書、容量見積書などの成果物、記載範囲、テンプレートを関係者と合意します。

① 必要な情報を確認し、不足分を課題として起票する

非機能要件、論理設計書、テーブル定義、業務処理量などを確認し、不足する情報は提供元と期限を明確にして管理します。

② 基本構成を決める

Oracleのエディションとライセンス、CDB/PDB構成、可用性構成、OS・ストレージ方式などを決定します。

③ 未確定事項を管理しながら詳細設計を進める

表領域、容量、REDOログ、メモリ、初期化パラメータなどを設計し、未確定事項には暫定値と根拠を記録します。

④ 設計レビューを実施し、課題を解決する

関係者から提供された情報やレビュー結果を設計書に反映し、未解決課題の影響範囲と確定条件を明らかにします。

⑤ 構築・試験で設計を検証する

構築時に設定値を確認し、移行リハーサルや性能試験で容量、接続数、REDO生成量などを検証します。

次章では、これらの設計項目について、Oracle Database 19cを例に具体的な判断とその根拠を解説します。

Oracle 19cの物理設計で具体的に決めること

Oracle Database 19cを例に、物理設計で決定する主要な項目と、その判断基準を解説します。単なる設定項目の紹介ではなく、実際の設計判断を具体例とともに示します。

最初に決めるソフトウェア構成とライセンス

物理設計では、まずOracleのエディションと利用できる機能を確認します。

Oracle 19cのStandard Edition 2（SE2）ではRACとData Guardを利用できません。また、Enterprise Edition（EE）でも追加ライセンスが必要な機能があります。

※実際の利用条件は、契約、導入形態、クラウドサービスなどによって異なります。

【設計判断例：Data Guardによる待機系の参照利用】

障害対策としてData Guardを採用し、待機系を帳票検索にも利用したい場合を考えます。

フィジカル・スタンバイを読み取り専用で開くだけなら基本Data Guardでも可能ですが、REDOの適用を継続しながら参照処理を実行するには、Active Data Guardオプションが必要です。

また、Diagnostics Packを契約しない場合は、CONTROL_MANAGEMENT_PACK_ACCESSをNONEに設定して、有償の診断・チューニング機能を誤使用しないようにします。性能監視にはSTATSPACKなどを採用します。

このように、技術的に実現できる構成と、契約上利用できる構成は区別しなければなりません。

Oracle 19cでは、採用するRelease Update（RU）やパッチ適用方針も物理設計時に決定します。

CDB/PDB構成と設計単位

Oracle 19cでは、CDB（Container Database）とPDB（Pluggable Database）によるマルチテナント構成を基本として設計します。

19cでは非CDB構成も利用できますが非推奨であり、21c以降ではサポートされません。将来のアップグレードを考慮すれば、CDB/PDB構成が基本的な選択となります。

【設計判断例：PDB数とライセンス】

Oracle 19cでは、SE2・EEともにMultitenantオプションを追加契約せず、1つのCDBにユーザー作成PDBを最大3個まで配置できます。

例えば、3つの業務データベースを統合する場合、ライセンス上は1つのCDBに3つのPDBを構成できます。

一方、4つ以上を統合する場合には、Multitenantオプションの利用条件などを確認する必要があります。

ただし、3個まで配置できるからといって、必ず統合するべきではありません。業務ごとの可用性、負荷特性、リソース競合、運用体制を踏まえて決定します。

OS・インスタンス・CDB・PDBの設計境界

PDB内で変更できる初期化パラメータは限定されています。次のSQLで変更可能なパラメータを確認できます。

SELECT name, ispdb_modifiable
FROM v$parameter
WHERE ispdb_modifiable = 'TRUE'
ORDER BY name;

RAC構成では、1つのCDBを複数のインスタンスで稼働させます。そのため、SGAなどの資源はインスタンス単位で管理する必要があります。

データベース作成時に決める重要項目

DBブロックサイズとキャラクタセットは、作成後の変更が容易ではないため、慎重に決定します。

【実務事例：8KBと16KBをどう選ぶか】

Oracle 19cでは一般的な8KBを基準に検討します。実際に担当した案件では、標準ブロックサイズに16KBを採用しました。判断材料として記録されていたのは次の3点です。

• DSS系のシステム特性
• 行連鎖の発生を抑える
• テーブルフルスキャン時のI/Oコストを低減する

16KBを採用するかどうかは、これらをそのまま結論にせず、対象システムの行長とI/O・更新特性から判断します。

① フルスキャンのI/O

OracleのDB_FILE_MULTIBLOCK_READ_COUNTは、シーケンシャルスキャンで1回のI/Oに読み込む最大ブロック数を指定します。

19cの既定値はプラットフォームに応じて決まり、多くの環境で最大約1MBの効率的な読み込みに対応するよう自動設定されます。

そのため、8KBから16KBに変更しても、マルチブロック読み込みの総バイト数が単純に2倍になるわけではありません。

フルスキャンが多いという理由だけでは、16KBを採用する十分な根拠にはなりません。

② 行連鎖

レコード長が大きい場合には、大きなブロックを採用することで、行連鎖の発生を抑えられる可能性があります。

一方、平均行長が十分小さければ、16KBを採用する理由としては弱くなります。

移行元のOracleが存在する場合は、DBA_TABLES.AVG_ROW_LENなどを確認し、実データの特性を把握します。

③ 更新処理とブロック競合

ブロックサイズを大きくすると、1ブロックに格納できる行数も増えます。

更新が集中するOLTP系処理では、アクセスが同じブロックに集中する可能性があるため、ブロック競合やバッファキャッシュ効率への影響も評価する必要があります。

したがって、19cでは8KBを基準とし、16KBを採用する場合は代表的なSQLによる性能検証と、実際の行長・アクセス特性を根拠に決定します。

キャラクタセットの選択

Oracle 19cでは、CDBのキャラクタセットとしてAL32UTF8を基本に検討します。

AL32UTF8のCDBには、条件を満たせば異なるキャラクタセットのPDBを収容できます。ただし、文字コード互換性やLOBアクセスの制約は確認が必要です。

CLOBの内部表現と容量への影響については、次章の容量見積で詳しく説明します。

表領域とストレージの設計

Oracle 19cでは、SYSTEM、SYSAUX、TEMPなどの表領域がCDBルートと各PDBに存在します。ローカルUNDOモードではPDBごとにUNDO表領域を管理します。

通常のローカル管理表領域では、ASSMによる空き領域管理とAUTOALLOCATEによるエクステント自動割り当てを基本とします。

エクステントサイズを明示的に管理する要件があればUNIFORMも選択できますが、既定の方式から変更する理由を設計書に残します。

【実務事例：表領域を大・小に分けた見積】

実際の案件では、テーブルサイズや定義レコード長をもとに、表領域を大・小に分けて見積もっていました。

この案件では大きなテーブルと小さなテーブルで固定エクステントのサイズを変えていました。ただし、表領域の分類と固定エクステントの採用は別の判断です。

Oracle 19cではAUTOALLOCATEを基本とし、固定サイズのUNIFORMを指定する場合は、その必要性を個別に検証します。

表領域を分けるかどうかも、単に大きさで決めるのではなく、保存期間、容量監視、バックアップ、リカバリ、移行などの運用要件で判断します。

【設計判断例：240GBの表領域をどう構成するか】

実務事例の容量見積では、テーブル格納表領域を240GBとしています（内訳と見積条件は次章で説明します）。これはファイル構成の考え方を示すための入力値です。

Oracle 19cの8KBブロック環境で240GBを構成する場合、SMALLFILEとBIGFILEの2つの選択肢があります。

SMALLFILEの場合、240GBなら最低8ファイル必要です。運用方針に応じて10ファイル程度に分ける構成も考えられます。

一方、BIGFILEなら1ファイルで構成できます。

ただし、BIGFILEでは大きなデータファイルをどのようにバックアップ・復旧するかが重要になります。

RMANではSECTION SIZEを指定したマルチセクション・バックアップを利用でき、1つの大きなデータファイルを複数セクションに分け、並列にバックアップできます。

例えば、CDBルートに接続したRMANからPDB1のAPP_DATA表領域をバックアップする場合は、次のように指定します。

BACKUP
  SECTION SIZE 8G
  TABLESPACE PDB1:APP_DATA;

※バックアップの並列度は、RMANのチャネル設定などにも依存します。PDBに直接接続する場合は、そのPDB内の表領域名を指定します。

このように、必要容量だけでなく、バックアップ時間、リカバリ方式、ASMやOMFの利用方針を踏まえてファイル構成を決定します。

REDOログ・アーカイブログ・可用性の設計

REDOログの設計では、サイズ、グループ数、多重化、アーカイブ方式を決めます。

【設計判断例：REDOログサイズの決定】

例えば、ピーク時のREDO生成量が毎分20MBで、ログスイッチ間隔の目安を30分とした場合、

20MB×30分＝600MB

となります。

この値をREDOログサイズの初期検討値とし、実際の負荷や運用要件に応じて調整します。

REDO生成量はどのように把握するか

移行元のOracleが存在する場合は、AWRまたはSTATSPACKのredo sizeなどを確認します。

また、V$LOG_HISTORYからログスイッチの頻度を確認できます。ログサイズと組み合わせることで、概算の生成量を推定できますが、ピーク時の厳密なREDO生成量を求めるには、統計情報や実測による確認が必要です。

さらに、V$INSTANCE_RECOVERYのOPTIMAL_LOGFILE_SIZE列も参考になります。

SELECT
  optimal_logfile_size,
  target_mttr,
  estimated_mttr
FROM v$instance_recovery;

OPTIMAL_LOGFILE_SIZEは、FAST_START_MTTR_TARGETなどの設定に基づくREDOログサイズの目安です。FAST_START_MTTR_TARGETを有効に設定している場合に算出され、設定条件によってはNULLとなるため、その場合はREDO生成量やログスイッチ頻度から判断します。

REDOログのグループ数はどう決めるか

REDOログは、ログスイッチによって次のグループへ切り替わります。

ロググループを再利用するまでに、必要なチェックポイント処理やアーカイブが完了していなければ、更新処理が待たされる可能性があります。

したがって、グループ数は単に最小構成にするのではなく、ピーク時のログスイッチ間隔とアーカイブ・チェックポイント処理の時間を踏まえて決定します。

特に大量バッチが存在するシステムでは、ピーク時にロググループが不足しないか検証する必要があります。

なお、Oracle 19cのクラッシュリカバリ時間は、主にFAST_START_MTTR_TARGETなどによって制御します。REDOログサイズだけで復旧時間が決まるわけではありません。

アーカイブの生成間隔を制御する必要があれば、ARCHIVE_LAG_TARGETも検討します。

Data Guardを利用する場合

Data GuardではMaximum AvailabilityやMaximum Performanceなどの保護モードを、データ損失の許容範囲と性能・可用性要件に応じて選択します。

スタンバイREDOログは、各REDOスレッドに対してオンラインREDOと同じサイズを基本とし、オンラインREDOより1グループ多く用意します。

例えば、オンラインREDOが3グループであれば、スタンバイREDOは4グループとします。

Data Guardにおける大量バッチのREDO転送・適用性能の課題については、後述の実案件の章で説明します。

メモリ・初期化パラメータの設計

Oracleのメモリ設計では、SGA・PGAに加えて、プロセス数とセッション数を検討します。

LinuxでHugePagesを利用する場合は、AMM（MEMORY_TARGET）と併用できないため、ASMMなどを採用します。

【設計判断例：PROCESSESの初期見積】

例えば、次の構成を想定します。

この場合、PROCESSES=300を初期検討値とできます。

ただし、これは説明用の仮定であり、PDB数、有効機能、並列実行、バックグラウンドプロセスの数によって必要値が変わります。

検証環境ではV$PROCESSなどを利用して実際のプロセス数を確認し、余裕を含めて見直します。

また、APサーバのローリング再起動時には、古い接続プールと新しい接続プールが一時的に併存する可能性があります。このような通常運用以外のピークも考慮する必要があります。

SESSIONSはPROCESSESから派生する

Oracle 19cでは、SESSIONSの既定値は原則として次の式から算出されます。

SESSIONS＝1.5×PROCESSES＋22

例えばPROCESSES=300なら、計算上の既定値は472です。

ただし、PROCESSESとSESSIONSは同一の設定ではありません。PDB単位のセッション制限も含め、アプリケーションの接続方式に合わせて設計します。

実際の案件で、端末数・同時アクセス数とDB接続数をどう区別したかは、後述の課題事例で説明します。

その他の物理設計項目

基盤・運用関連の設計

Oracle 19cではUnified Auditingの混合モードが既定の構成です。新規設計では、従来型監査への依存を避け、純粋なUnified Auditingへの移行も検討します。

アプリケーション寄りの物理設計

索引、パーティショニング、非正規化なども広義の物理設計に含まれます。

これらはDBAとアプリケーション担当者が連携して設計します。

また、Amazon RDS for OracleなどのマネージドDBでは、OS、ストレージ、ファイル管理などについて、オンプレミスとは設計できる範囲が異なります。利用するサービスに応じて、設計対象と責任分界点を整理する必要があります。

テーブルサイズ・表領域容量の見積方法と実務ノウハウ

データベースの物理設計で特に難しいのが、容量見積です。物理設計の段階ではテーブル定義やデータ件数が確定していないことも多く、そのような状況でもストレージ容量を決めなければなりません。

ここでは、実際の大規模システムで使用した容量見積Excelと課題管理表をもとに、Oracle Database 19cでも活用できる見積の進め方を解説します。

容量見積に必要な情報と基本的な計算方法

テーブル容量の見積では、次の情報を確認します。

基本的な計算式は以下のとおりです。

将来件数＝初期件数＋年間増加件数×見積年数

テーブルデータ量＝将来件数×平均レコード長

冒頭で例に挙げた注文テーブル（初期件数120万件、年間増加30万件、見積期間5年で、5年後に270万件）に、平均レコード長420バイトを当てはめると、次のようになります。

420バイト×270万件＝1,134,000,000バイト

したがって、データ本体の概算は約1.1GBです。

ただし、Oracleの実際の格納容量には、ブロック管理領域、PCTFREE、エクステント割り当てなどの影響があります。

定義レコード長と平均レコード長は区別する

実案件では、エンティティ定義書から取得した定義上のレコード長を使って概算していました。

この方法は実データがなくても計算できますが、VARCHAR2などの可変長項目では、定義上の最大長が実際の平均長より大きくなる場合があります。

移行元のOracle Databaseが利用できる場合は、DBA_TABLES.NUM_ROWSとAVG_ROW_LENを参照すると、実態に近い見積が可能です。AVG_ROW_LENには行オーバーヘッドも含まれます。

ただし、統計情報が古ければ信頼性が低下します。また、行外LOBのデータ本体は平均行長だけでは評価できないため、別途容量を見積もる必要があります。

必要な情報が揃わないときの暫定見積

実務では、すべてのテーブルの件数や増加量が確定してから物理設計を開始できるとは限りません。

私が担当したプロジェクトでも、物理設計時点では全テーブルの定義と件数が揃っていませんでした。

課題管理表には、業務側に全テーブルの定義と件数一覧を求めた記録が残っています。その中で、必要な資料が不足していても、既存資料から設計を進めるという方針が示されました。

実際には以前に提供されていたエンティティ定義書を利用して見積を開始し、その後に件数や増加率の情報を取得して修正を進めました。定義書の項目長に未記入が見つかり、資料を再確認した経緯もあります。

【実務事例：105テーブルを暫定見積】

実案件の容量見積Excelでは、件数が把握できるテーブルは5年後の推定件数から容量を計算し、初期件数が不明なテーブルには暫定容量を設定しました。

※元資料のMB表記を使用。100MBは実際の案件固有の暫定値であり、Oracle 19cの推奨値ではありません。

全体の約11％を暫定値が占めていました。

仮に、この105テーブルの実際の平均容量が300MBだった場合、必要容量は31,500MBとなります。

当初見積10,500MBとの差は21,000MBです。

つまり、未確定部分の見積条件によって、ストレージ容量が大きく変わる可能性があります。

そのため、暫定値については少なくとも以下を記録しておきます。

重要なのは、情報不足を理由に設計を止めるのではなく、合理的な前提を置いて設計を進め、後から検証・修正できるようにしておくことです。

暫定値は正解ではありません。未確定であることを明示し、関係者と合意して使用する必要があります。

索引・LOBの容量見積

テーブル本体の容量を計算しただけでは、データベース全体の容量は決まりません。

索引容量は、定義が確定していなければ暫定見積する

物理設計段階では、性能チューニングによって索引が追加される可能性があります。

実案件では、索引容量を次のように見積もっていました。

（240GB－80GB）×25％＝40GB

240GBはテーブル格納表領域全体、80GBはLOBを含むテーブルの見積容量です。

この計算では、LOBを除いた160GBを基準に25％を掛けています。

なお、160GBには非LOBテーブルのデータ量120GBに加え、表領域設計上の余裕40GBも含まれるため、索引の見積にも実質的に余裕を見込んでいます。

この25％は案件固有の暫定係数であり、Oracle 19cの標準的な割合ではありません。

索引定義が確定した後は、キー長、索引本数、データ件数などをもとに再見積します。既存テーブルであれば、DBMS_SPACE.CREATE_INDEX_COSTを利用する方法もあります。ただし、対象テーブルの統計情報が適切に収集されていることが前提です。

LOB容量は文字コードと格納方式に注意する

実案件では、帳票データを格納するCLOBの容量見積で問題が発生しました。

当初の見積には、以下の2つの問題がありました。

• 見積に使用した帳票枚数が、実際にLOBへ格納されるデータ件数を正しく表していなかった。
• すべてのLOBが行外格納されるという前提で計算していた。

このため、LOB容量の再見積が必要になりました。

Oracle 19cでCLOB容量を見積もる場合は、文字コードによる内部表現の違いも考慮します。

例えば、AL32UTF8環境では、CLOBの可変長文字データはUCS2互換の内部形式で格納されます。

基本多言語面の文字を例にすると、次の違いがあります。

つまり、ASCII中心の帳票では元のUTF-8データより大きく、日本語中心では小さくなる場合があります。

ただし、補助文字、管理領域、LOB格納方式などの影響があるため、この比率をそのまま最終容量に使用してはいけません。

行内格納と行外格納の違い

Oracle 19cでは、ENABLE STORAGE IN ROWが有効な場合、管理情報を含めておおむね4,000バイト以下のLOBを行内に格納できます。

1文字が内部的に2バイトとなる文字を中心に考えれば、おおむね2,000文字弱が目安になります。ただし、これは厳密な文字数上限ではありません。

4,000バイトを超えるLOBは行外格納となり、別途LOBセグメントの容量を考慮する必要があります。

また、BasicFilesでは小さなLOBの行外格納に最低1チャンクが必要となる場合がありますが、SecureFilesでは格納方式が異なります。

Oracle 19cではSecureFilesを基本に検討し、圧縮・重複排除・暗号化を利用する場合は、Advanced CompressionやAdvanced Securityのライセンス条件も確認します。

LOBの容量は単純な「件数×元ファイルサイズ」では求められません。実際のデータ形式と格納特性を確認したうえで見積もる必要があります。

表領域・ストレージ容量への積み上げ

テーブル・索引・LOBの容量を見積もった後は、表領域およびストレージ全体の必要容量を決めます。

【実務事例：テーブル格納表領域の設計】

最終物理設計書には、次の容量が記録されています。

なお、前述のExcel約93,431MBは、見積ツール上の大・小区分の集計値です。

最終物理設計書では、非LOBテーブルを約200テーブル×平均600MBとして120GBに見積もり、さらに帳票データなどのLOBを含むテーブルに80GBを計上しています。

両者は同じ条件で算出した値ではなく、Excel集計から最終値へ至ったすべての再計算過程も確認できないため、93GBと200GBを直接比較することはできません。

実務では、このように見積条件や対象範囲が変わることがあるため、見積値だけでなく、算出時点・対象範囲・前提条件を一緒に管理することが重要です。

データファイルのサイズと拡張方針を決める

Oracle 19cでは、必要容量を踏まえて次の項目を設計します。

• 初期データファイルサイズ
• AUTOEXTENDの使用有無
• NEXTによる拡張増分
• MAXSIZEによる上限

AUTOEXTENDを有効にしていても、ストレージの空き容量が不足すれば拡張できません。

そのため、データファイルの上限と物理ストレージの空き容量を合わせて管理します。

ストレージの冗長化も考慮する

ASMでNORMAL REDUNDANCYを採用する場合、通常のデータファイルは2重化されます。

例えば280GBの論理容量を同じASMディスクグループに配置すると、ミラーリングを含めて、概算560GB相当の物理容量が必要です。

さらに、ASMの管理領域や障害時の再ミラーリングに必要な余裕も考慮します。ストレージ装置側で冗長化する場合は、その方式に応じて計算します。

その他の領域も忘れずに見積もる

特にアーカイブログは、テーブルの総容量ではなく更新処理量の影響を大きく受けます。

設計時には容量監視の方針も決めます。DBA_TABLESPACE_USAGE_METRICSなどを利用し、使用率だけでなく、自動拡張可能量、ストレージの空き容量、増加速度も監視します。

概算→補正→実測で容量見積の精度を上げる

容量見積は一度で完成するものではありません。実務では、次の3段階で精度を高めます。

第1段階：概算

前述のように、基本設計・詳細設計の初期段階では、わかっている件数とレコード長から概算し、未確定部分は暫定値で補います。

第2段階：Oracleの標準機能で補正

Oracle 19cではDBMS_SPACE.CREATE_TABLE_COSTを利用して、平均行サイズと想定件数からテーブル容量を推定できます。

例えば、平均行サイズ420バイト、270万件の場合は次のように指定します。

SET SERVEROUTPUT ON
DECLARE
  v_used_bytes  NUMBER;
  v_alloc_bytes NUMBER;
BEGIN
  DBMS_SPACE.CREATE_TABLE_COST(
    tablespace_name => 'APP_DATA',
    avg_row_size    => 420,
    row_count       => 2700000,
    pct_free        => 10,
    used_bytes      => v_used_bytes,
    alloc_bytes     => v_alloc_bytes
  );
  DBMS_OUTPUT.PUT_LINE(
    'USED_BYTES=' || v_used_bytes
  );
  DBMS_OUTPUT.PUT_LINE(
    'ALLOC_BYTES=' || v_alloc_bytes
  );
END;
/

※ APP_DATAは説明用の表領域名です。実際には対象PDB内の表領域を指定します。

Oracle公式マニュアルでは、以下のように説明されています。

• USED_BYTES：データが使用する容量。ブロック管理情報やPCTFREEなどのオーバーヘッドを含む。
• ALLOC_BYTES：表領域のエクステント割り当て特性を考慮した容量。

ただし、索引や行外LOBの容量まで自動的に求まるわけではありません。

このSQLはOracle 19c実機での確認用です。実行環境で得た値とExcelの概算値を比較し、必要に応じて見積モデルを補正します。

第3段階：移行リハーサル・性能試験で実測

実際のデータを投入した後は、DBA_SEGMENTSでテーブル・索引・LOBの割当容量を確認します。

PDB内に接続してDBA_SEGMENTSを確認する方法のほか、CDBルートからCDB_SEGMENTSをCON_ID付きで確認する方法もあります。

さらに、DBMS_SPACE.SPACE_USAGEによるセグメント内の空き領域、性能試験時のUNDO・TEMP使用量、REDO生成量などを確認します。

DBA_SEGMENTS.BYTESは割当済み容量であり、純粋な業務データ量ではありません。そのため、見積と比較する際には、何を測定した容量なのかを揃える必要があります。

こうして概算から実測までの差異を確認し、その理由を設計書に反映すれば、今回の容量設計だけでなく、次のプロジェクトでも活用できるノウハウとして蓄積できます。

物理設計で実際に発生した課題と解決方法

物理設計では、教科書どおりの手順だけでは設計値を決められないことがあります。

ここでは実際の課題管理表と物理設計書をもとに、同時接続数、Data Guard、設計変更の3つの事例を紹介します。各数値は設定値の推奨例ではなく、入力情報をどのように解釈して判断したかを示す材料です。

端末数・同時アクセス数からPROCESSESを決めてはいけない

PROCESSESの設計では、利用端末数、同時アクセス数、DBへの最大接続数を区別する必要があります。

【実務事例：400台・250接続・30同時アクセス】

実案件の課題管理表には、次の回答が記録されていました。

250台が同時接続可能でも、実際に処理を実行する台数が30台程度なら、接続数とアクティブな処理量を分けて考える必要があります。

さらに、DBには利用者向けシステム以外からも接続が発生します。

実際の物理設計書では、接続元ごとの上限を次のように積み上げていました。

250はDB全体の最大接続数ではなく、一つの接続元の上限でした。

これに、案件の環境で確認したバックグラウンドプロセス約40と、Data Guard関連の想定10を加えています。

370＋40＋10＝420

最終的には約19％の余裕を見込み、PROCESSES=500を採用しました。

また、SESSIONSは既定の計算式から772としました。

1.5×500＋22＝772

Oracle 19cでもこの算出式を利用できます。ただし、CDB/PDB構成や有効機能でバックグラウンドプロセス数が変わるため、事例の50を固定値とせず、対象環境のV$PROCESSなどで実数を確認します。

重要なのは、最大接続数と同時実行負荷は別の設計指標であることです。

Data Guardと夜間バッチのREDOをどう設計するか

Data Guardでは、スタンバイの用途によって設計が変わります。

障害時の切替先として利用するのか、日常的な参照処理に利用するのかによって、適切な構成を選択します。

【実務事例：参照用DBにロジカル・スタンバイを採用】

実際の案件では、本番DBとは別に、利用者がSQLによる参照処理を行うDBを用意していました。

この参照用DBにはData Guardのロジカル・スタンバイを採用しました。Oracle 19cで同様の要件を設計する際には、後述する他の参照用DB構成とも比較して選択します。

ロジカル・スタンバイでは、DBをオープンしたままSQL Applyによって変更を反映できます。

ただし、フィジカル・スタンバイのREDO Applyとは異なり、REDOから論理的な変更を再構成し、SQLを実行して反映します。

そのため、大量の更新を伴うバッチでは、REDOを受信する速度だけでなく、SQL Applyの処理性能が同期完了時間を左右します。

また、更新対象の行を効率的に特定できるよう、主キーや一意キーの有無も重要です。適切なキーがない表では、更新や削除の適用時にフルスキャンが発生し、性能が低下する可能性があります。

ロジカル・スタンバイでは、更新行を識別するためのサプリメンタル・ロギングも必要となり、REDO生成量に影響します。

加えて、すべてのデータ型や表構成をSQL Applyで扱えるわけではありません。対象外の表はDBA_LOGSTDBY_UNSUPPORTEDなどで確認できます。

夜間バッチ終了時点までの反映をSCNで確認する

この案件では、参照用DBへの反映を日次で実施していました。

物理設計書に記載された手順は、次のとおりです。

1. 夜間バッチ終了後、プライマリでログスイッチする。
2. アーカイブログの最終SCNを取得する。
3. スタンバイ側でREDO適用を開始する。
4. 適用済みSCNが目標SCNに到達したことを確認する。
5. REDO適用を停止する。

ここでいうSCNは、夜間バッチ終了時点までの更新が反映されたかを確認する基準です。

単にREDOが届いたことではなく、目標SCNまでSQL Applyが完了したことを確認する運用でした。

FORCE LOGGINGと大量バッチの問題

実案件の夜間バッチでは、中間ファイルを作成し、JavaプログラムまたはSQL*Loaderを使ってDBへデータを格納していました。

ダイレクト・パス・インサートなどの大量投入処理では、NOLOGGINGによってREDO生成量を抑制できる場合があります。

しかし、必要なREDOが生成されないと、スタンバイ側で投入データを正しく再現できない可能性があります。

このため、この案件ではData Guardとの整合性を考慮し、FORCE LOGGINGを有効にしました。

一方、FORCE LOGGINGやサプリメンタル・ロギングにより、REDO量、アーカイブログ容量、転送負荷が増える可能性があります。

【実務事例：1日約100万件を基準にREDO量を算出】

課題管理表では、年次の大量処理として、1日約100万件を想定していました。

REDO量は、現行システムで同等の処理を実行した際のアラートログをもとに算出し、アーカイブログの保存期間は1週間としました。

アラートログのログスイッチ情報を利用した見積は概算ですが、実績に基づく設計値を得るための方法です。

Oracle 19cでは、利用権のあるAWRやSTATSPACKのredo size、実際のバッチ試験などを組み合わせて検証します。

【実務事例：ネットワーク転送負荷の判断】

REDO転送については、業務用と運用用のネットワークが分離されていないことが懸念事項となりました。

この案件では「問題ないレベルと思われる」という定性的な判断で課題を完了しましたが、REDO転送量と回線帯域を比較した定量的な根拠は記録されていません。

19cで同様のシステムを設計するなら、次の項目を確認します。

特に、大量バッチ後のSQL Applyの所要時間は実測し、同期の完了時刻に間に合うかを確認します。

なお、19cで参照用DBを構成する場合は、ロジカル・スタンバイに加え、フィジカル・スタンバイとActive Data Guard、GoldenGateなどの論理レプリケーションも比較対象となります。要件、ライセンス、対応データ型、同期方式を踏まえて選択します（前述のライセンスの設計判断例を参照）。

設計の前提条件が変わったときの対応

物理設計では、設定値や構成が後から変更されることがあります。

重要なのは、変更後の値だけでなく、変更理由と検証すべき事項を残すことです。

【実務事例：UNDOを20GBから10GBへ変更】

課題管理表には、UNDO表領域を20GBから10GBへ変更した記録があります。

理由は、システム全体の容量を考慮したためです。

この事例は、個別の表領域に求められる容量だけでなく、ストレージ全体の制約も設計値に影響することを示しています。

19cではV$UNDOSTATなどを確認し、必要なUNDO保持期間を満たせるか検証します。

必要資料は設計開始の条件ではなく、検証の材料とする

実案件の課題管理表では、テーブル定義やデータ件数に関する資料について、設計済みの容量が十分かどうかを確認するために必要であり、資料がなくても設計を進められる、という考え方が示されていました。

つまり、資料が揃うまで設計を止めるのではなく、暫定的な前提を置いて設計し、資料の受領後にその妥当性を検証するという進め方です。

LOBの再見積では格納方式や運用方針も見直す

LOB容量を再見積した際には、専用表領域を設けず、テーブルと同じ表領域へ格納する方向も検討されました。

また、帳票データのパージ方針は、容量を再見積した後に判断することになっていました。

このように、前提条件が変われば、単なる設定値だけでなく、表領域構成や保存・削除方式まで見直す必要があります。

課題管理表は、未確定事項を管理するだけでなく、設計判断の根拠と変更の経緯を残すための成果物として活用します。

まとめ｜データベースの物理設計で重要なこと

データベースの物理設計は、表領域や初期化パラメータの設定値を埋める作業ではありません。性能・容量・可用性・運用性の要件を踏まえ、根拠を持って設計判断を積み重ねる工程です。

本記事では、Oracle Database 19cを例に、主な設計項目、容量見積の方法、実際のプロジェクトで発生した課題を紹介しました。

Oracle 19cでは、エディションとライセンス、CDB/PDBの設計単位を最初に確認し、その制約を踏まえて表領域やメモリなどを設計します。

実務で特に重要なのは、必要な情報がすべて揃っていなくても、設計を止めないことです。

テーブル件数や接続数が未確定であれば、暫定値とその前提条件を課題管理表に記録し、設計を進めます。そして資料が提供された段階で、見積や設定値の妥当性を検証します。

また、別案件の設計値をそのまま流用しないことも重要です。

例えば、別案件の設計書に16KBのDBブロックサイズや固定エクステントが記載されていても、その値を流用せず、平均行長、アクセス特性、運用要件を確認します。フルスキャンの多さだけでは大きなブロックを選ぶ十分な根拠にはならず、代表的なSQLでの検証が必要です。

物理設計の品質を左右するのは、設定値そのものだけではありません。なぜその値を選んだのか、どの情報を根拠にしたのかを説明できることが、構築・試験・運用まで通用する設計につながります。

参考資料｜Oracle Database 19c公式マニュアル

• Licensing Information — エディション、オプション、管理パックの利用条件
• DBMS_SPACE — CREATE_TABLE_COSTなどの容量見積機能
• DBA_TABLES — テーブル統計情報（列定義の詳細はALL_TABLESを参照）
• Physical Database Limits — SMALLFILE／BIGFILE等の物理的上限
• FAST_START_MTTR_TARGET — クラッシュリカバリ時間の目標
• SESSIONS — セッション数とPROCESSESの関係
• DB_FILE_MULTIBLOCK_READ_COUNT — マルチブロック読み込み
• Managing a Logical Standby Database — SQL Applyの処理方式と運用
• Backing Up the Database — RMANのSECTION SIZEとマルチセクション・バックアップ

関連記事

• Oracle 19c更改後に実行計画が変わる――パーティション削除時の統計情報更新と影響調査漏れ
• 性能テストの進め方｜負荷モデル・テストデータ・評価方法を実務で解説
• 運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点
• RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ
• セキュリティ要件定義の進め方｜リスクアセスメントから対策・残存リスクを決める方法

設計工程のレビューが完了し、品質指標も社内基準の範囲内でした。

普通に考えれば、そのまま次工程へ進めそうです。

しかし、このプロジェクトではすぐには進めませんでした。

理由は、全体の数値には現れにくい「偏り」があったからです。数値が基準内でも、特定機能への指摘集中や、逆に不自然なほど指摘が少ない成果物が隠れていることがあります。

本記事では、実際のプロジェクトで行った品質評価をベースに、そうした違和感をどう見つけ、原因を追い、次工程へ進める根拠をどう作ったかを紹介します。

まずは、レビュー指摘件数をどう見るかから始めます。

1. レビュー指摘件数だけでは、設計品質は判断できない

あるプロジェクトで、複数機能を合わせた設計書115ページに対し、レビュー指摘が36件出ました。

この36件という数字だけを見て、

「36件もある。品質が悪い」

あるいは逆に、

「社内基準の範囲内だから問題ない」

と判断してよいのでしょうか。

どちらも早すぎます。

36件が多いか少ないかは、対象範囲によって意味が変わります。

1機能の小さな設計書で36件なら多く見えるかもしれません。一方、大規模なサブシステム全体で36件なら、むしろ少なく見えることもあります。

だから最初に確認するのは、指摘件数そのものではありません。

成果物の規模と、指摘がどこに偏っているかです。

実際に担当したあるプロジェクトでも、全体の指摘件数だけを見ると、社内で設定していた品質水準から大きく外れた状態ではありませんでした。

ところが機能別に分解すると、ある認証系機能に指摘が集中していました。

全36件のうち17件。全体の約47％です。

認証機能だけ、何か違う。

この違和感をそのままにせず、原因を確認するところから品質評価が始まります。

2. まず全体値を見る。ただし、ここでは結論を出さない

設計レビューが終わったら、まず全体の数字を確認します。

次のような結果でした。

当時のプロジェクトでは、こうした値を社内標準の品質基準と比較していました。

ここでいうエラー摘出密度は、100ページ当たりの指摘件数です。

基準値との比較は必要です。大きく外れていれば、その時点で何らかの問題がある可能性があります。

ただし、ここで「基準内だから品質に問題なし」と結論は出しません。

逆に多少基準を外れていても、それだけで品質不良とは見ません。

私にとって品質指標は、結論を出す数字ではなく、次にどこを見るかを決める入口です。

例えば、レビュー指摘が多くても、その大部分が誤字や表現修正なら、設計そのものの品質が悪いとは限りません。

一方、指摘件数が少なくても、その中に重大な設計漏れが含まれていれば話は別です。

30件の軽微な記述修正と、1件の重大な設計漏れでは意味が違います。

だから、全体値を確認した次は、その数字を分解して見ます。

今回のケースで行った流れを整理すると、次のようになります。

図：設計工程における品質評価の流れ。基準値の確認だけで終わらず、偏り・重要度・原因を確認し、必要に応じて設計へ戻す

この流れの中で、最初に重要になるのが「偏り」です。全体平均だけでは見えない違和感を、機能別に分解して確認します。

3. 設計工程の品質評価では「平均」より違和感を見る

先ほど示した36件を機能別に分けると、内訳は次のようになります。

認証系だけで全体の約半数を占めており、偏りがはっきり見えます。

ここで見るべきなのは、

なぜ、この機能だけ突出したのか

です。

品質評価では、こうした偏りをかなり重視します。

特定機能に指摘が集中している、特定種類の指摘だけ突出している、規模の割に指摘が多い。こうした数字には、何らかの理由があります。

今回の認証系機能でも、17件のうち大半が「説明不足」「記述上の不備」でした。

一見すると、

設計者の文章力の問題ではないか

と思うかもしれません。

しかし、実際に原因を追っていくと、問題はもっと上流にありました。

この点は後ほど詳しく説明します。

指摘が「0件」の成果物も確認する

逆方向の偏りもあります。

指摘が少なすぎるケースです。

ある程度の規模や複雑さがある成果物でレビュー指摘が0件だった場合、私は「品質が高かった」とすぐには受け取りません。

むしろ、一度確認します。

もちろん、小規模な定型機能なら0件でも不思議ではありません。

しかし、ある程度の規模があり、新規設計や条件分岐、外部連携などを含むのに0件であれば、

本当に十分なレビューが行われたのか？

を疑います。

実際のプロジェクトでも、指摘が多い機能だけを確認していたわけではありません。規模の割に指摘が少ない機能や、指摘が0件だった機能も確認対象にしていました。

0件には、

• 本当に完成度が高かった
• レビュアーが十分に内容を理解できていなかった
• レビュー観点が不足していた
• 表面的な確認だけで終わっていた

といった、まったく異なるケースが混在するからです。

品質評価で探すのは、単純な「悪い数字」ではありません。

説明しにくい数字、違和感のある数字です。

多すぎる場合も見る。少なすぎる場合も見る。

全体平均の中に埋もれた違和感を拾うことが、品質評価の最初の重要な作業です。

4. 指摘件数より「何を指摘されたか」を見る

レビュー結果を見るときは、指摘件数だけでなく、その指摘がどの程度の影響を持つものかを確認します。

例えば、同じ10件でも、

• 誤字脱字や表現の修正が10件
• 処理条件の漏れや設計誤りが10件

では、品質上の意味はまったく違います。

私が品質評価をするときは、指摘内容を重要度で分けて見ます。

この分類で重要なのは、件数の多寡だけで工程完了を判断しないことです。

軽微な指摘だけであれば、修正を確認できた時点で問題にしません。

一方で、重要度「大」に相当する設計漏れや設計誤りが残っているなら、たとえ指摘件数が1件でも、そのまま工程完了とはしません。

重要度の高い指摘が見つかった時点で、同じ原因による漏れが他機能にもないか、横展開の確認も必要になります。

つまり、

「何件あったか」より、「何が残っているか」の方が重要です。

先ほどの認証系機能でも、指摘の大半は説明不足や記述上の不備で、重要度としては「小」〜「中」が中心でした。

認証方式そのものを大量に間違えていたわけではありません。

それでも、同じ種類の指摘が一つの機能に集中している以上、

なぜ、この機能だけ設計内容を明確に書けなかったのか

は確認する必要があります。

次章では、この認証系機能について、実際にどこを疑い、原因をどう絞っていったのかを見ていきます。

5. 認証系だけ指摘が多い。まず何を疑ったか

認証系機能では、他の機能より指摘が明らかに多く出ていました。

こういうとき、私はいきなり

担当者のスキルが足りない

とは考えません。

まず機能単体で見える構造を確認し、次に人を見て、それでも説明できなければ機能の外側にある構造へ視野を広げます。

この順で見る理由は、個人を疑う前に、担当者を替えても同じ問題が起こる要因がないかを確認したいからです。

機能そのものの難易度

まず、その機能が他より難しくないかを見ます。

認証や外部連携のように、複数システムをまたぎ、条件分岐も多い機能は、単純な機能より設計上の確認事項が増えます。

当時のプロジェクトでも、認証まわりは経験者が限られており、他機能より確認すべき前提が多い領域でした。

要件が十分に固まっているか

次に見るのが要件です。

設計者が正しく理解していても、要件そのものに不足があれば、設計書に明確に落とし込むことはできません。

ここでは、要件定義書や過去の打ち合わせ内容を見直し、

そもそも設計者が判断できるだけの情報が揃っていたか

を確認します。

担当者の理解・経験

ここで初めて、担当者側を見ます。

機能の前提は理解できているか。過去の設計や類似機能を把握しているか。

ただし、指摘が多いことだけを理由に担当者の力量が低いとは見ません。

レビュアー側の知識

設計者だけでなく、レビューする側も確認します。

レビュアーがその機能の前提や過去の経緯を知らなければ、レビュー回数を増やしても重要な観点を拾えないことがあります。

機能の外側まで視野を広げる

個人や単一機能だけでは説明できない場合は、認証基盤側と個別機能側の責任分界も確認します。

認証や外部連携では、

どこまでを認証基盤側で決め、どこからを個別機能側で決めるのか

が曖昧だと、誰も設計しない領域が生まれます。

この観点は、単純な設計書レビューだけでは見落としやすい部分です。

ここまで確認して初めて、

指摘が多かった理由は何だったのか

を絞り込めます。

今回の認証系機能でも、表面的には「説明不足が多い」という現象でしたが、その原因は設計書の書き方だけでは説明できませんでした。

次章で、実際にどこが不足していたのかを見ていきます。

6. 原因は「書き方」ではなく、要件と責任分界にあった

認証系機能では、「説明不足」「記述上の不備」が多く出ていました。

表面だけを見ると、

設計者が分かりやすく書けていない

という問題に見えます。

しかし、設計内容を追っていくと、原因はそれだけではありませんでした。

当時の要件では、外部の認証基盤から利用者IDを受け取り、そのIDが認証用のテーブルに存在する利用者だけをシステムへ通す、というところまでは決まっていました。

ところが、その先が十分に詰められていませんでした。

例えば、

• その利用者は参照だけできるのか
• 更新もできるのか
• 管理者権限を持つのか
• 担当業務だけを利用できるのか
• こうした権限情報をどこで管理するのか

といった点です。

つまり、「誰であるか」を確認する認証までは決まっていても、「何をしてよいか」を決める権限側の要件が十分ではなかったのです。

さらに、認証基盤側と個別機能側のどちらが、どこまで責任を持って設計するのかも曖昧でした。

例えば、認証基盤側は利用者IDが正しいことまでを保証し、その利用者に「参照のみ」「更新可能」「管理者」といった権限を与えるのは個別機能側なのか。それとも権限情報そのものを認証基盤側で管理するのか。

この境界が十分に決まっていませんでした。

この状態では、設計者が設計書を明確に書こうとしても限界があります。

要件として決まっていない内容を、設計者の判断だけで確定させることはできないからです。

結果として、

「この場合はどうするのか」
「この権限はどこで判断するのか」
「この条件では認証エラーなのか、権限エラーなのか」

といった部分が設計書上で曖昧になっていました。

この関係は、次のように整理できます。

要件が不足している
↓
認証基盤側と個別機能側の責任分界が曖昧になる
↓
設計者が一意に仕様を決められない
↓
設計書の記述が曖昧になる
↓
レビューで説明不足として表面化する

ここで重要なのは、レビューで見えた「説明不足」をそのまま原因だと考えないことです。

説明不足は原因ではなく、上流の問題が設計書に現れた結果だったわけです。

もしここで、

設計書をもっと分かりやすく書くこと

だけを対策にしていたら、根本的な問題は残ったままです。

今回のケースでは、この原因を確認した時点で、次工程へそのまま流すのではなく、設計の前提を見直す必要があると判断しました。

7. 基準内でも、原因が見つかれば設計へ戻す

認証系機能で指摘が多かった原因を追うと、設計書の書き方だけでなく、要件不足と責任分界の曖昧さがあることが分かりました。

この状態でそのまま製造へ渡せば、実装者ごとに仕様の解釈が分かれ、後から設計変更や製造修正が発生する可能性があります。

そのため、全体として品質基準の範囲内であっても、そのまま次工程へ進む判断はしませんでした。

不足していた仕様を確認する

最初に行ったのは、曖昧だった仕様の再確認です。

認証そのものだけでなく、

• 利用者にどの権限を与えるのか
• どこまでを認証基盤側で持つのか
• どこからを個別機能側で判断するのか

といった、設計の前提を整理し直しました。

私の現場では、こうした仕様不足を見つけたとき、

今ここで決めずに後工程へ送ると、設計変更や製造修正として追加工数が発生するか

も判断材料にします。

今回の内容は、後工程へ持ち越せば手戻りにつながる可能性が高いため、この工程で確認すべき事項と判断しました。

プロジェクトの経緯と運用を知る有識者にも確認する

次に、有識者を加えて確認しました。

ここでいう有識者は、単に認証技術に詳しい人ではありません。

重視したのは、

そのプロジェクトで、なぜ現在の設計になったのかを知り、既存システムが実際にどう運用されているかも理解している人

です。

技術力が高くても、途中から参加した人では、過去にどのような議論があり、なぜその方式を採用し、他機能とどこを揃える必要があるのかまでは分からないことがあります。

さらに、要件定義書には明示されていなくても、既存システムを長く使ってきた中で当然視されている運用要件が存在することもあります。

横並びで品質を見るときは、技術知識だけでなく、プロジェクト固有の設計経緯と運用実態を知っていることも重要です。

他機能へ横展開する

認証系機能で問題が見つかったからといって、その機能だけを修正して終わりにはしません。

まず、要件不足やシステム間の責任分界という観点で、同じ問題が他機能にもないかを確認しました。

例えば、

• 設計者が判断できない未確定条件が残っていないか
• 他システムとの責任分界が曖昧になっていないか

といった観点です。

加えて、横展開を進める中では、認証系とは別の種類の不足も見つかりました。

例えばポータル画面です。

プロジェクトの経緯と既存システムの運用を知る有識者から、

• 本日・今月のバッチ処理の終了予定時刻
• バッチ処理の実施結果
• 処理件数
• 利用者への連絡事項

といった情報も、共通的に表示する必要があるという指摘がありました。

こうした内容は、要件定義書に書かれた項目だけを追っていても拾いにくいものでした。

そのシステムが実際にどう使われてきたかを知る人だからこそ見つけられた設計上の不足です。

この不足は設計へ反映し、修正後に再確認しました。

横展開は、同じ不備を他機能から探すだけの作業ではありません。

プロジェクト固有の設計経緯や運用知識まで含めて、設計に抜けがないかを確認する作業です。

そして、今回見つかった問題はその場限りで終わらせず、次回以降のレビューでも使えるよう、

• 未確定条件が残っていないか
• 他システムとの責任分界が明確か

といった形でチェック観点として残しました。

最初から完璧なチェックリストを作る必要はありません。実際に発生した問題を確認観点へ戻していくことで、そのプロジェクトに合ったチェックリストになっていきます。

ただし、それを第三者でも同じように使える形に整理することは、また別の作業です。

修正後の再確認では、今回問題となった観点について追加の修正指摘は出ませんでした。

重大な設計漏れや未解決事項も残っていないことを確認しました。

仕様を再確認する → プロジェクト経験者を含む有識者で確認する → 他機能へ横展開する。

ここまで実施して、次工程へ進めました。

基準の確認は必要ですが、それだけでは足りません。

数字の偏りから原因が見つかったのであれば、基準内かどうかより、その原因を放置しないことを優先します。

8. 数字の良し悪しの前に、「何を計った数字か」を確認する

品質評価では、レビュー密度や生産性といった数字も確認します。

ただし、数字が基準より高い、低いというだけでは評価しません。

代表的なのがレビュー密度です。

当時のプロジェクトでは、レビュー密度が社内標準より低く見える場面がありました。

数字だけを見れば、

レビュー時間が不足していたのではないか

と考えたくなります。

しかし実態を確認すると、設計書レビューだけでなく、事前の横並び確認や整理にもかなり時間を使っていました。一方、それらの時間すべてが管理ツール上のレビュー時間として計上されていたわけではありません。

つまり、

レビューが少なかった

のではなく、

数字に含まれている作業範囲が、実際に行った品質確認の全量ではなかった

ということです。

ここで確認すべきなのは、実績値が正しいかどうかではありません。

その数字が、何をどこまで計測したものなのかです。

レビュー密度が低くても、横並び確認や有識者レビューまで含めて十分な確認をしているのであれば、その実態も合わせて評価します。

時間の多寡と、レビュー観点の質は別の問題です。

成果物ごとの指摘件数も同じです。先ほど触れたように、規模や難易度に対して極端な値になっていれば、その理由を確認します。

生産性についても、高く見えていても、工数の計上範囲や外部支援の有無によって意味が変わります。

数字が良いか悪いかではなく、その数字が実態を正しく表しているかを見る。

これが重要です。

場合によっては、こうした理由から指標を「参考値」として扱うこともあります。

ただし、参考値とすることは、評価しなくてよいという意味ではありません。

なぜその数字をそのまま評価に使えないのかに加え、何を代わりの品質確認の根拠としたのかも説明できる必要があります。

例えば、横並び確認、有識者レビュー、修正後の再確認などです。

「参考値」は逃げ道ではなく、別の根拠で補完することを前提にした扱いです。

9. 品質評価の目的は「次工程へ進める根拠」を作ること

設計工程の品質評価は、

基準値に入ったから合格

という判定ではありません。

偏りを見つけ、原因を追い、必要なら設計へ戻し、横並びや有識者の確認を重ねる。

その結果として、重大な問題が残っていないことを説明できて初めて、次工程へ進めます。

品質評価の目的は、品質指標を計算することではありません。

「なぜ、この設計成果物を次工程へ渡してよいのか」を説明できる状態にすることです。

今回のケースを口頭で説明するなら、骨子はこうなります。

全体の品質指標は基準範囲内だったが、認証系機能への指摘集中が見つかった。原因を確認すると、要件と責任分界に不足があったため設計へ戻した。さらに有識者を交えて他機能も確認し、必要な修正と再確認を行ったうえで、次工程へ進める状態になった。

実務では、この判断を口頭で説明して終わりにはできません。

顧客やプロジェクトマネージャー、PMOなど、第三者が後から見ても、

• どの数字に着目したのか
• なぜ追加確認が必要と判断したのか
• どんな品質強化を行ったのか
• 何を根拠に次工程へ進めると判断したのか

を追える形にしておく必要があります。

第8章で触れたように、レビュー密度などを「参考値」とした場合も同じです。

なぜその数字をそのまま評価に使えないのか。
その代わりに何を確認し、品質を担保したのか。

ここまでを整理して初めて、第三者にも品質判断の根拠を説明できる状態になります。

ここから先は、「品質をどう判断するか」ではなく、その判断をどう資料にするかの話です。

実務編では、実際の品質評価で使用してきた考え方をベースに、架空プロジェクトのデータを使って、

• レビュー実施状況表
• エラー分析表
• 横展開用チェックリスト
• 品質・生産性報告書

をどのように作るか、具体的に整理します。

本記事が「何を見て、どう判断するか」なら、実務編は「その判断を第三者に説明できる成果物へどう落とすか」です。

※実務編は近日公開予定です。

関連記事

設計工程の品質評価では、レビュー結果だけを見るのではなく、要件が十分に具体化されているか、設計した内容を後工程でどう確認するかまでつなげて考える必要があります。

今回の記事で扱った「要件不足」「責任分界」「次工程へ進める根拠」と関係する内容は、以下の記事でも詳しく整理しています。

要件定義とは？RFP・見積前提から認識差を潰す実務を解説
要件定義書に書かれた要求をそのまま設計へ渡すのではなく、設計・構築・テストできる粒度まで具体化する考え方を、責任分界や実際の手戻り事例とともに整理しています。

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

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

sys-univ.com

2026.08.12

Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方
要件や設計で決めた内容を、どのテスト工程で確認するのか。設計成果物とテストを対応づけて、後工程まで含めて品質を作り込む考え方を解説しています。

Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方

Vモデルは古い開発手法の話ではなく、要件・設計で決めたことをテストで確認する品質保証の考え方です。バックアップ要件の具体例で各工程の対応関係を整理します。

sys-univ.com

2026.07.13

機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う
機能が正しく動くだけでは、本番で使えるシステムとは限りません。性能・可用性・運用性・セキュリティなど、設計時に見落としやすい非機能要件の考え方を整理しています。

機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う

「機能が動く」と「本番で使える」は違う。機能要件と非機能要件の違いを、購入申請システムの具体例と現場の失敗パターンから整理します。

sys-univ.com

2026.06.19

はじめに

「Vモデルってウォーターフォール時代の話でしょ？」

こう話すエンジニアに、現場でたびたび出会います。アジャイルやスクラムが当たり前になった今、Vモデルは時代遅れだと思われがちです。しかし、これは大きな誤解です。

Vモデルは特定の開発手法の話ではありません。要件定義や設計で決めたことを、対応するテストで確認するという、品質保証の基本的な考え方です。この考え方を持てているかどうかが、システム開発の品質を大きく左右します。

この記事では、システム基盤開発を例にとりながら、Vモデルの本質をテスト工程の視点から解説します。教科書的な図の説明ではなく、現場でどう使うかに焦点を当てています。

Vモデルとは何か

Vモデルとは、開発工程とテスト工程を対応づけて考えるモデルです。

名前の由来は見た目の形にあります。左側に開発工程が並び、右側にテスト工程が並ぶ。その形がアルファベットの「V」に見えることから、Vモデルと呼ばれています。

ただし、大事なのは形ではありません。本質は次の一文に集約されます。

「ある工程で決めたことは、対応するテスト工程で確認する」

このイメージを図にすると、次のようになります。

ただし、工程の名称や対応関係はプロジェクトごとに異なります。ここで示すのはあくまで一例です。その前提で、システム基盤の開発に当てはめると次のような対応関係になります。

• 環境定義（実際の設定値・パラメータ）→ 単体テスト
• 詳細設計（製品ごとの設計内容）→ 結合テスト1（基盤に閉じた接続確認）
• 基本設計（処理方式・システム構成・採用製品）→ 結合テスト2（プロトタイプアプリを用いた確認）
• 要件定義・運用設計（可用性・性能・セキュリティ・運用要件など）
  → システムテスト・運用テスト・受入テスト

結合テストを2段階に分けているのは、確認の観点が異なるからであり、教科書的なVモデルをそのまま当てはめたものではなく、基盤開発の成果物粒度に合わせた整理です。

結合テスト1は基盤に閉じた機器間・システム間の接続確認です。結合テスト2はプロトタイプの業務アプリケーションを使い、基本設計で定めた処理方式や構成が実際に機能するかを確認します。基本設計の内容を検証するには、アプリが一部でも動く状態でないと確認できないため、この段階にアプリが入ってきます。

システムテストは「総合テスト」とも呼ばれ、基盤とアプリケーションが合流して行う最終的な全体検証です。プロジェクトによっては、運用テストや受入テストがシステムテストの一部として扱われることもあれば、システムテスト後の別工程として実施されることもあります。なお、運用テストは手順・承認フローの確認、受入テストはお客様がシステムを本番として受け入れるかの判断が目的であり、両者は異なります。

この対応関係が崩れると、品質の抜け漏れが発生します。「要件定義で決めたのにテストしていない」「テストしたが根拠となる設計が存在しない」。そういう状況を防ぐための考え方が、Vモデルです。

なぜ段階的なテストが必要なのか

テストを「最後に一度まとめてやればいい」と思っている人が、現場に一定数います。完成したシステムに対して動作確認をすれば十分、という考え方です。

しかし、これには重大なリスクがあります。

システムは複数の要素の集合で成り立っています。クライアント端末、ネットワーク、ネットワーク機器、サーバ、ストレージ。これらが組み合わさって、一つのシステムとして動作します。

この状態で一気にテストしようとすると、何が起きるでしょうか。

問題1：原因の特定に時間がかかる

想定どおりに動作しなかった場合、どこが悪いのかを特定するのが困難になります。ネットワークの設定ミスなのか、サーバのパラメータが間違っているのか、アプリケーションの処理が悪いのか。複数の要素が絡み合うため、原因の切り分けに膨大な時間がかかります。

本来であれば、単体テストで「このサーバの設定値は正しいか」を確認し、結合テストで「このサーバとあのサーバは正常に通信できるか」を確認する。問題が発生したときに、どの段階のどの要素が原因かを絞り込みやすい状態を作っておくことが重要です。

問題2：たまたま動いて終わってしまう

逆のパターンも怖いです。本来は網羅すべき条件を確認していないのに、たまたまテストが通ってしまうことがあります。

例えば、単体・結合テストでフェイルオーバーの検証をスキップし、システムテストでも正常系しか確認しなかったとします。システムが正常に動いているうちは問題が表面化しません。しかし本番で障害が発生したとき、初めて「フェイルオーバーが機能しない」と発覚する。これは最悪のシナリオです。

単体テスト、結合テスト、システムテストと段階を踏むことで、確認すべき項目を体系的に洗い出すことができます。

問題3：テスト項目が後から書けない

設計内容が曖昧なまま進むと、テスト工程で「何を確認すれば合格なのか」がわからなくなります。

「バックアップを取得すること」とだけ書かれていた場合、何をテストすればよいでしょうか。取得対象は何か。何時に取得するのか。何世代保持するのか。何時間以内に終わる必要があるのか。これが決まっていなければ、テスト項目に落とせません。

テスト項目は、テスト工程で突然生まれるものではありません。要件定義や設計で決めた内容から導き出されるものです。

そして、本来その工程で検出すべきバグが後続工程で発見されることを「すり抜け」と呼びます。

これは単なる発見タイミングのずれではありません。単体テストで見つかるべき設定ミスが結合テストやシステムテストで出てきた場合、「他にも同じ観点でのすり抜けがあるのではないか」という疑義が生じます。結果として、同じ観点の横並び確認が必要になり、場合によっては設計書、設定値、テスト項目の見直しが全体に波及します。

品質報告の場では、T型マトリックスという管理表が使われることがあります。

一般的には、縦軸に「実際に不具合を発見した工程」、横軸に「本来その不具合を摘出すべき工程」を置き、不具合がどの工程で検出され、どこですり抜けたかを可視化するものです。

対角線上に並ぶものは、本来の工程で適切に検出できた不具合です。一方、後続工程側にずれて計上されるものは、前工程で摘出できずに流出した不具合、つまりすり抜けを意味します。

たとえば、本来は単体テストで摘出すべき設定ミスが、結合テストやシステムテストで発見された場合、それは後工程へのすり抜けとして扱われます。このマトリックスを見れば、どの工程で検出力が弱いのか、どの工程で不具合が後ろ倒しになっているのかが一目でわかります。

「単体テストで検出すべき不具合が、なぜ結合テストやシステムテストまで残っていたのか」。その問いに答えられるかどうかが、テスト設計や品質分析の力を問われるポイントです。

テスト工程を段階的に設計し、各工程で検出すべき項目を明確にしておくことは、すり抜けリスクを下げるための最も基本的な手立てです。すり抜けの詳細なメカニズムと対策については、テスト編で改めて解説します。

バックアップ4時間以内という要件を例に考える

ここで、具体的な例を見てみましょう。お客様と次のような非機能要件を合意したとします。

DBおよびログのバックアップ時間は4時間以内とする

一見すると、シンプルな要件に見えます。しかし、この要件を実現し、テストで確認するためには、複数の工程にわたる設計が必要です。

要件定義の段階

この段階では「4時間以内」という目標を合意します。具体的な方式はまだ決まっていません。重要なのは、この数字が「何の性能要件か」を明確にしておくことです。性能・拡張性の要件であり、後工程のシステムテストで確認する項目です。

基本設計の段階

要件を実現するための方式を決めます。

• バックアップ対象は何か（DBのみか、ログも含むか）
• 取得先はどこか（サーバ内ディスクか、共有ストレージか、クラウドストレージか）
• 取得経路はどうするか（専用VLANを用意するか、本番ネットワークを使うか）
• 本番処理と同じ時間帯に実行しても問題ないか

これらを決めることで、システム構成と採用製品が固まります。

詳細設計の段階

採用する製品やミドルウェアを前提に、具体的な処理内容を決めます。

• バックアップジョブをどう構成するか
• どの順番で取得するか
• 圧縮・暗号化はするか
• エラー時の再実行ロジックはどうするか
• 失敗時の通知先はどこか

環境定義の段階

実際のパラメータを確定します。

• バックアップ対象のフォルダパス・ファイルパス
• 保存先のパス
• 実行スケジュール
• 保持世代数
• タイムアウト値

テストの段階

ここまで設計が積み上がって初めて、テスト項目が具体的に書けます。

• 本当に4時間以内に完了するか
• 対象ファイルに漏れはないか
• バックアップ失敗時にアラートが上がるか
• リストアできるか
• 本番相当のデータ量でも時間内に終わるか

Vモデルを理解していないと、「要件に4時間以内と書いてある」「バックアップジョブは作った」「テストで何となく動いた」で終わってしまいます。しかし現場では、それでは足りません。

ここまでは、Vモデルの基本的な考え方を整理しました。
以降では、現場でこの考え方をどう使うか、工程ごとの留意点、よくある失敗パターン、運用テストの位置づけまで踏み込んで整理します。

セキュリティ要件を検討するとき、暗号化する、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 ClReadMore...

  

  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 tReadMore...

  

  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 とお客様の間で責任を共有します。この共有モデルにより、ホストオペレーティングシステムや仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまで、さまざまなコンポーネントをReadMore...

  

  docs.aws.amazon.com
• IPA, “システム構築の上流工程強化（非機能要求グレード）紹介ページ”
  
  

  システム構築の上流工程強化（非機能要求グレード）紹介ページ | アーカイブ | IPA 独立行政法人 情報処理推進機構

  情報処理推進機構（IPA）の「システム構築の上流工程強化（非機能要求グレード）紹介ページ」に関する情報です。

  

  www.ipa.go.jp

本シリーズでは、詳細設計を「構築・テスト・運用できる形」に落とし込む工程として、全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

大手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