しかし、GitLabがプライベートネットワーク内にあり、AWSアカウントも異なるとなると、話はそう単純ではありません。

今回、EC2上のGitLab Self-ManagedとCodeBuildを連携するため、AWS CodeConnectionsの設定を進める過程で、次のエラーが問題となりました。

Invalid host endpoint provided.

当初は、Transit Gateway（TGW）でVPC間の通信経路を確保すれば、あとはCodeConnectionsの設定だけで済むと考えていました。ところが、AWSサポートへの問い合わせを通じて、VPC接続、自己署名証明書、GitLabの認証、さらにCodeBuildのソース取得方式まで、切り分けるべき論点が次々と出てきました。

本記事では、この事例を基に、閉域環境でCodeConnectionsを利用する際の設計ポイントを整理します。

本記事の検証範囲

1. GitLabとCodeBuildを別AWSアカウントで連携する

今回の構成は、次のとおりです。

GitLabにはパブリックIPアドレスがなく、インターネットから直接アクセスできない構成です。

VPC間はTGWで接続されていますが、TGWの接続が存在することと、CodeConnectionsからGitLabへ通信できることは別の話です。

さらに、CodeConnectionsの接続設定、GitLab側での認可、CodeBuildによるソース取得では、それぞれ異なる通信や権限が関係します。

最初はネットワークの問題だと思っていたものが、調べていくと認証や証明書の問題にも広がっていく。複数のAWSサービスを組み合わせる際に、こうした切り分けの難しさを感じる場面は少なくありません。

2. CodeConnectionsの「ホスト」と「接続」は別物

エラーの原因を考える前に、CodeConnectionsの仕組みを整理しておきます。

GitLab Self-Managedとの連携では、「ホスト」と「接続」という2種類のリソースを扱います。

ホストはGitLabの設置環境を表すリソースで、GitLabのURL、VPC、サブネット、セキュリティグループ、必要に応じたTLS証明書などを設定します。

一方、接続はGitLabアカウントによる認可を受け、AWSサービスからリポジトリへアクセスするためのリソースです。

両者を区別すると、ネットワークや証明書の設定と、GitLabへのアクセス認可を分けて考えられます。

PATはホストの認可に使用する

GitLab Self-Managedのホストをセットアップする際には、Personal Access Token（PAT）を使用します。

AWS公式ドキュメントによれば、PATには次の要件があります。

• GitLab管理者が作成・使用する
• apiスコープが必要
• GitLabのAdmin Modeが有効な場合はadmin_modeも必要
• PATはホストの認可に使用され、接続では保存・使用されない
• ホストのセットアップ後にPATを削除できる

つまり、ホストの認可に使用したPATを、そのまま継続的なリポジトリアクセス用の認証情報として保持する必要はありません。

参考：AWS公式｜GitLab Self-Managedへの接続作成

3. Invalid host endpoint provided. とVPC設定の関係

今回のエラーは、CodeConnectionsでGitLab Self-Managedのエンドポイントを設定する際に発生したものです。

Invalid host endpoint provided.

AWSサポートからは、「VPCを使用する」が無効の状態でプライベートIPを指定すると、このエラーが発生するという説明がありました。

また、VPC接続を有効にして必要なネットワーク設定を行うことで、Availableに至ったという経緯も示されています。

このため、今回のエラーを切り分けるうえでは、接続先URLだけでなく、VPC接続の設定が有力な確認ポイントになります。

プライベートIPのGitLabにはVPC接続を検討する

AWS公式ドキュメントでは、GitLab Self-Managedがプライベートネットワーク内に存在する場合、ホストの作成時に「Use a VPC」を選択する構成が示されています。

設定する主な項目は、VPC ID、サブネットID、セキュリティグループIDです。

ここで注意したいのは、GitLabが稼働するVPCと、CodeConnectionsに設定するVPCが必ずしも同一とは限らないことです。

AWS公式手順では、VPNやDirect Connectを経由してGitLabへアクセスできるVPCの例が示されています。一方、今回のような別アカウント間のTGW構成については、同じ手順の中で明示的な例示がありません。

今回の構成ではTGWを利用し、CodeConnectionsのAvailable表示まで到達しています。ただし、これだけでTGW経由のあらゆる構成がサポートされると判断することはできません。

エラーが発生した場合の切り分け

同じエラーに遭遇した場合、まず次の4点を調べます。

1. GitLabのエンドポイントURLが適切か
2. プライベートIPへの接続に対応したVPC設定になっているか
3. 設定したVPC・サブネットからGitLabへの経路があるか
4. HTTPSの証明書が接続先と整合しているか

特に、プライベートIPを指定しているにもかかわらずVPC接続を使用していない場合は、最初に見直したい設定です。

4. 閉域接続では、作業端末からのアクセスも必要になる

AWSからGitLabへのネットワーク疎通を考える際、見落としやすいのが接続の認可操作です。

CodeConnectionsの公式手順では、接続を作成した後、ブラウザでGitLabにサインインし、「Authorize」を選択して認可します。

AWS CLIやCloudFormationで接続リソースを作成した場合も、初期状態はPENDINGとなり、コンソールで認可を完了させる必要があります。

ここで問題になるのが、設定作業を行う端末からGitLabへアクセスできるかという点です。

例えば、AWS側のVPCからGitLabへ通信できても、作業PCが社内ネットワーク外にあり、GitLabのプライベートIPに到達できなければ、ブラウザで認可操作を進められない可能性があります。

この場合は、社内VPNや管理用端末など、GitLabへアクセスできる正規の操作環境を用意する必要があります。

AWSサービス間の通信経路だけを考えていたところに、作業端末からのアクセスという別の問題が出てくる。閉域ネットワークの設計では、こうした運用面まで含めて考える必要があります。

5. TGW経由の通信と自己署名証明書をどう扱うか

今回の構成では、GitLabとCodeBuildが異なるAWSアカウントに存在します。

VPC間はTGWで接続されていますが、TGWが存在するだけでは通信は成立しません。

少なくとも、次の項目を整理する必要があります。

特に、CodeConnectionsとCodeBuildを同じ通信元として扱わないことが大切です。

どのコンポーネントがGitLabに接続するかによって、必要なネットワーク設定は変わります。

自己署名証明書の設定先

今回のGitLabでは、HTTPS通信に自己署名証明書を使用しています。

AWS CodeConnectionsには、非公開認証局を利用する環境向けにTLS証明書を指定する設定があります。

ただし、証明書を登録することと、TLS接続が正常に検証されることは同じではありません。

接続先としてIPアドレスを使用する場合、証明書のSubject Alternative Name（SAN）に、そのIPアドレスが登録されているかが論点になります。

証明書を信頼できても、接続先のIPアドレスが証明書と一致しなければ、ホスト名検証で失敗する可能性があります。

この点は、実際の証明書をopenssl x509 -textなどで調べることで確認できます。

6. CodeBuild側にもVPCや証明書の設定が必要なのか

今回、最も気になったのが、CodeBuild側の証明書設定に関するAWSサポートの回答です。

サポートからは、CodeConnections側で証明書を設定していれば、CodeBuild側に特別な証明書設定は必要ないという趣旨の説明がありました。

当初は、CodeConnectionsがGitLabとの通信を担うのであれば、その説明で理解できそうに思えました。しかし、CodeBuildの公式仕様を調べていくと、一つ疑問が残りました。

CodeBuildが実際にGitLabからソースを取得する際、HTTPS通信はどのコンポーネントが実行するのでしょうか。

この点を整理しないまま、CodeBuild側の証明書設定が不要と判断するのは早いと感じました。

ビルド環境からGitLabへ接続するならVPC設定が必要

CodeBuildのビルド環境から直接GitLabへGit cloneを実行する方式であれば、プライベートIPしか持たないGitLabへ到達できるネットワーク経路が必要です。

通常、VPC設定のないCodeBuildのビルド環境はAWS管理のネットワークで動作するため、TGWで接続されたプライベートVPCへ、そのままアクセスできるわけではありません。

したがって、ビルド環境が直接GitLabへ接続する方式なら、CodeBuild側にも到達可能なVPC設定と通信経路が必要になります。

一方、CodeConnections側の仕組みでソース取得が完結する方式なら、必要なネットワーク構成は異なります。

残る論点は、今回のCodeConnectionsを利用したソース取得が、どちらの方式で動作するかです。

GetConnectionTokenから読み取れること

AWSのCodeBuild向けGitHub App接続手順では、サービスロールに次のIAM権限を付与する例が示されています。

{
  "Effect": "Allow",
  "Action": [
    "codeconnections:GetConnectionToken",
    "codeconnections:GetConnection"
  ],
  "Resource": "arn:aws:codeconnections:<region>:<account-id>:connection/<id>"
}

GetConnectionTokenは、接続に関連する認証トークンを取得するためのアクションです。

この仕組みから、CodeBuildが接続を通じて認証情報を取得し、ソース取得処理に利用する構成が考えられます。

ただし、認証トークンを取得することと、ビルド環境から直接GitLabへ通信することは同義ではありません。IAM権限だけで実際の通信元を特定することはできません。

なお、上記はGitHub App向け公式手順を基にした説明用のポリシー例です。実際のGitLab Self-Managed構成では、接続方式と必要権限に合わせて調整する必要があります。

参考：AWS公式｜GitHub App connections

証明書検証を無効化すればよいのか

CodeBuildのProjectSource APIには、insecureSslという設定項目があります。

ただし、この設定はCodeConnectionsのホスト側で実施するTLS検証とは別のものです。今回のGitLab Self-Managed＋CodeConnections構成に適用できるかも、ソース取得方式によって異なります。

AWSサポートからは、CodeConnections側のTLS証明書検証を無効化することはできないとの説明がありました。

いずれにしても、証明書検証を無効化してエラーを回避するのは、セキュリティ上望ましい対応ではありません。

自己署名証明書を使用する場合でも、適切なCA証明書の信頼設定と、接続先のホスト名またはIPアドレスとの整合性を確保することが基本です。

実際の通信元をどう調べるか

CodeBuildの実行結果が得られるなら、まずDOWNLOAD_SOURCEフェーズのログを調べます。

ソース取得の段階で失敗しているのか、取得後のビルド処理で失敗しているのかを分けるためです。

さらに、GitLab側のVPC Flow Logsを利用し、通信元IPアドレスを調べる方法があります。

通信元IPとENIの対応関係を照合すれば、CodeConnections側のネットワークコンポーネントからの通信なのか、CodeBuild側からの通信なのかを判断する手掛かりになります。

必要に応じてGitLab側のアクセスログとも突き合わせれば、より具体的に切り分けられます。

今回、CodeBuildの実行検証はできていませんが、設計段階では次の4点を整理しておきたいところです。

7. AWSサポートへの問い合わせで重要なのは、設定値より前提条件

今回の問い合わせを整理する中で、改めて感じたのは、エラーメッセージだけを伝えても、問題の本質にはなかなかたどり着けないということです。

最初は「GitLabに接続できない」という問題でも、構成を整理すると、プライベートIP、TGW、自己署名証明書、GitLabの認可など、複数の条件が関係しています。

そこで、問い合わせの前提として、次の情報を整理することが有効になります。

• GitLab Self-ManagedがEC2上で稼働している
• GitLabはプライベートIPのみを使用している
• AWSアカウント間をTGWで接続している
• HTTPSには自己署名証明書を使用している
• CodeConnectionsのエンドポイント設定時にエラーが発生している

このように整理すると、単なる接続エラーではなく、どのコンポーネント間の通信に問題があるのかを議論しやすくなります。

さらに、AWSサポートには設定方法だけでなく、設定が必要になる条件まで尋ねたいところです。

例えば、CodeBuild側の証明書設定について疑問が残るなら、次のように質問します。

GitLab Self-Managedへのソース取得にCodeConnectionsを利用する場合、GitLabへのHTTPS通信はどのコンポーネントが実行するのでしょうか。CodeBuild側にVPC設定やCA証明書の登録が必要になる条件を教えてください。

これは、単に「CodeBuild側の証明書設定は必要ですか」と聞くよりも、通信経路と責任分界を明確にできる質問です。

長年、基盤設計やシステム間連携に関わってきましたが、複数の製品やサービスが絡む問題では、個々の設定よりも、サービス間の境界に原因が潜んでいることが少なくありません。

今回のCodeConnectionsも、そうした視点で考える必要がある事例でした。

8. まとめ｜マネージドサービスでも基盤設計は不要にならない

今回、CodeConnectionsでGitLab Self-Managedへの閉域接続を構成する過程で、Invalid host endpoint provided. というエラーが問題となりました。

AWSサポートからは、プライベートIPを使用する場合のVPC接続設定が有力な原因として示され、CodeConnectionsのAvailable表示まで到達しています。

今回の検討から得られる教訓は、次の3つです。

第一に、AWSサービス間の接続でも通信経路を明確にする必要があります。 TGWが接続されているだけでは不十分で、ルートテーブル、セキュリティグループ、通信元の整理が欠かせません。

第二に、ネットワークと認証は別の問題です。 AWS側からGitLabへ到達できても、作業端末から認可画面へアクセスできなければ、接続のセットアップを完了できない場合があります。

第三に、接続ステータスと実際の処理成功は区別します。 CodeConnectionsがAvailableでも、CodeBuildのソース取得やビルド成功まで保証されたわけではありません。

AWSのマネージドサービスは、インフラの構築・運用負担を減らしてくれます。しかし、複数サービスを組み合わせた際の通信経路、認証、TLS証明書、IAM権限まで自動的に設計してくれるわけではありません。

マネージドサービスを利用することと、基盤設計が不要になることは別の話です。

今回の事例は、その基本を改めて考える機会になりました。

参考資料

• AWS公式｜GitLab Self-Managedへの接続作成
• AWS公式｜GitLab access in CodeBuild
• AWS公式｜GitHub App connections
• AWS公式｜CodeBuild ProjectSource API

システムを導入する企業を、この記事では「発注側」と呼びます。発注側が外部の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の立場から新任情シス担当者に最も伝えたいことです。

大手SIerで20年超、大規模な業務システムの基盤構築や運用に携わってきた私が、今回の騒ぎを見て感じたのは、CVSS 9点台の重大な脆弱性が見つかり、緊急対応を迫られる事態は、私が携わってきたシステムでは想定内だったということです。

PHP2Shellという個別の脆弱性を予測していたわけではありません。通常SIerでは、重大な脆弱性が発見されることを前提に、対応基準や正常性確認の手順を平時から整備しています。

本記事では、PHP2Shellが大きな問題になった背景を整理し、運用の現場が重大な脆弱性をどう判断し、どう対策しているのかを解説します。

本記事は2026年10月30日時点の公開情報に基づいています。仮想事例と明記した部分は説明用に構成したものです。

PHP2Shellの重大性と社会的な影響

PHP本体に見つかった2件の重大な脆弱性

PHP2Shellは、PHPの実行基盤に見つかった2件の脆弱性の総称です。CVE-2026-109618はメモリ不足（OOM）時のエラー処理に、CVE-2026-109619はリクエスト処理に関わる内部状態の管理に起因します。いずれも認証なしで遠隔からサーバー上の任意のコードを実行されるおそれがあり、PHPのセキュリティチームは2件ともCVSS v4.0で9.2と評価しています。修正版は10月21日に公開されました。

注意したいのは、サポート切れの古いPHPだけが対象ではなかったことです。サポート中の8.2〜8.5系も、修正版より前はすべて影響を受けます。8.1以前には公式の修正版がなく、7.4・8.0・8.1向けに最小限の修正コードが出たのみです。IPAは、調査に関わったWiz社の情報として、PHP 5.4以降は少なくともいずれかの影響を受けると紹介しています。

悪用の状況について、IPAは10月27日の更新で、米国CISAが2件を「悪用が確認された脆弱性」の一覧（KEVカタログ）に追加したことを紹介し、国内での攻撃被害は把握していないとしています。攻撃が観測されたことと、実際に侵害された被害が確認されたことは、分けて受け止める必要があります。なお、JPCERT/CCは10月29日の更新で、あるファイアウォール製品の特定バージョンについて、侵害成功を示唆する痕跡が確認されたとの報告を紹介しています。

CVSSとは何か

CVSS（Common Vulnerability Scoring System）は、脆弱性の深刻度を0.0〜10.0で評価する共通指標です。CVSS v4.0では7.0〜8.9が「High（重要）」、9.0〜10.0が「Critical（緊急）」で、PHP2Shellの9.2は最も深刻な区分に当たります。ただし、公表される基本評価値は、個々のシステムで実際に攻撃が成立するか、どの順に対処すべきかまでは示しません。

首相による注意喚起とWebサイトの一時停止

高市首相は21日21時55分ごろ、Xで「今夜に対応して頂きたい大至急のお願い」としてパッチの適用準備を呼びかけ、適用が難しい場合は「ウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つ」と述べました。同じ夜、BASE、pixiv、niconico、DMM.comなどが予防的にメンテナンスに入ったと報じられています。

一般の利用者には前例のない非常事態に映ったかもしれません。しかし、OS、Webサーバー、Javaランタイム、RDBMSでも、重大な脆弱性は繰り返し報告されてきました。CVSS 9点台の脆弱性を調べ、緊急対応の要否を判断すること自体は、企業システムの運用では特別なことではありません。

PHPの普及範囲と管理体制の多様さ

では、なぜ今回はこれほど大きな問題になったのか。背景の一つは普及範囲の広さです。W3Techsの調査（2026年10月29日時点）では、サーバー側の言語を判別できるWebサイトの69.2%がPHPを使っています。

もう一つは、システムの管理体制と更新可能性の違いです。専門の運用組織が管理するシステムもあれば、ホスティング事業者や制作会社に運用を任せているサイトもあります。

W3Techsの2026年10月31日時点の集計では、PHPを使うサイトの26.4%が7系、7.6%が5系でした。少なくとも約3分の1が、PHP本家のサポートを終了したEOL（End of Life）のバージョンを利用していたことになります。EOLとは製品やバージョンのサポート終了を意味し、通常は開発元からセキュリティ修正が提供されなくなります。

私が携わってきた企業システムでは、OSやミドルウェアがEOLを迎える前に、更新や移行を計画することを基本としていました。やむを得ずEOL後も利用する場合には、延長サポートや攻撃経路の制限など、代替策と残存リスクを評価する必要があります。期限や対策を管理したうえでの継続利用と、更新されないまま残っている状態とでは、緊急時に取れる対応が異なります。

今回のPHP2Shellは、サポート中のバージョンにも影響した重大な脆弱性です。広く普及したPHPに問題が見つかり、通常の更新が難しい環境も相当数存在していたことが、騒動を大きくした要因の一つではないかと考えています。

重大な脆弱性への対応は、平時から設計している

CVSSに応じた対応基準を準備する

ここからは、私が実際に携わってきたシステムの運用を紹介します。すべてのSIerや企業システムが同じ水準にあるという意味ではなく、あくまで私の経験の範囲です。

私が関わったシステムでは、ベンダーのセキュリティアドバイザリ、IPAやJPCERT/CCの注意喚起、OSやミドルウェアの更新情報を継続的に監視し、管理対象の製品に関係する脆弱性を抽出していました。そのうえで、CVSSの重大度に応じた対応基準に照らし、対象サーバーの範囲、対応期限、緊急対応の要否を判断します。CVSS 9点台で緊急対応になることも、運用上の想定に含めて手順を整えていました。

ただし、CVSSは初期判断の材料です。9点台でも、攻撃に必要な機能を使っておらず成立条件がない場合があります。逆に8点台でも、インターネットから直接攻撃でき、すでに悪用が確認されているなら優先すべきです。脆弱性の重大度と、自分たちのシステムでの実際のリスクは、分けて評価する必要があります。

業務重要度によって対応方法を変える

もう一つの軸が業務重要度です。私が関わったシステムでは、業務への影響に応じて区分していました。以下に簡略化したイメージを示します。

この区分に脆弱性の攻撃可能性を組み合わせて判断します。停止できるシステムにCritical級の脆弱性があり、外部からの攻撃を防げないなら、止めて修正します。停止の影響が大きい基幹系では、冗長構成や代替手段で業務への影響を抑える方法を検討します。

ただし、冗長構成があるからといって、未修正のサーバーを攻撃可能なまま公開し続けてよいわけではありません。片系ずつ適用する場合も、未修正側の攻撃経路を遮断できることが前提です。安全な暫定策がなければ、基幹系でも緊急停止を選ぶ場合があります。

正常性確認まで事前に準備しておく

特に重要だと考えているのが、パッチ適用後の正常性確認です。携わってきたシステムでは、業務重要度の区分ごとに正常性確認スクリプトとテスト項目一覧を整備していました。確認するのは、プロセスの稼働、Web/APサーバーからのDB接続、主要な業務画面やトランザクション、外部システムとの連携、ログ出力と監視、冗長構成での切替や負荷分散です。範囲と深さは、重要度と変更内容に応じて変えます。

緊急時の深夜に確認項目を一から洗い出せば、時間がかかり確認漏れも起きます。手順が手元にあれば、再開の判断を速く下せます。想定内とは、対応が楽に済むという意味ではありません。徹夜になっても、何をどの順に確認し、誰が再開を判断するかが決まっていることです。何から手を付けるか分からず、手探りで朝を迎える徹夜とは違います。

このような準備は運用設計の一部です。NISTのパッチ管理ガイド（SP 800-40 Rev.4）も、定期適用、緊急適用、緊急の緩和策、パッチを適用できない資産といった場面ごとに、対応を事前に計画することを推奨しています。パッチ・脆弱性管理に加え、起動停止や開局・閉塞などの具体的な設計項目は、運用設計書の目次サンプルを解説した次の記事で整理しています。

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

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

sys-univ.com

2026.08.14

CVSSが高くても、必ずパッチを適用するわけではない

仮想事例：未使用の管理サービスにCVSS 8点台の脆弱性

ここでは、パッチを当てるかどうかを判断する技術を、説明用の仮想事例で考えます。

あるミドルウェアの管理用サービスに、CVSS 8点台の脆弱性が公表されたとします。特定のTCPポートで待ち受ける管理サービスを通じて攻撃が成立しますが、このサービスは業務では使っていません。この場合、全サーバーへの即時適用の前に、成立条件を確認します。

1. 影響条件の確認：対象製品、バージョン、機能、攻撃経路を確認する。
2. 対象サーバーの特定：管理台帳から、該当製品を使うサーバーを洗い出す。
3. 利用状況の確認：管理サービスを業務で使っていないことを、設計書と実機の設定で確認する。
4. 稼働状態の確認：管理サービスが起動していないことを確認する。
5. 不要サービスの停止：起動していれば停止し、自動起動も無効化する。
6. 有効性の確認：該当ポートが待ち受けていないこと、別の経路から同じ脆弱性を悪用できないことを確認する。
7. 記録と判断：実施内容と残存リスクを記録し、承認を経て緊急パッチの適用を見送る。

パッチを適用しないことは、放置することではない

この例で伝えたいのは、パッチを見送る判断にも技術的な根拠が必要だということです。攻撃経路が特定のサービスに限られ、そのサービスを確実に無効化できるなら、緊急のリスク低減策として成立する場合があります。

ただし、攻撃経路が実際に遮断されていることを確認できなければなりません。ポートを閉じただけでは、別のインターフェースから攻撃が成立する可能性も残ります。脆弱性そのものは残っているため、構成変更やサービスの再有効化でリスクは戻ります。緊急適用を見送っても、定期メンテナンスでの更新計画は別途必要です。すでに侵害されている疑いがあれば、停止とは別に調査も欠かせません。

「脆弱性のある製品を使っている」ことと「その脆弱性を悪用できる状態にある」ことは、必ずしも同じではありません。この違いを実際のシステム構成や設定から調べ、対応方針を決めるのが、システム基盤エンジニアの仕事です。

パッチを当てるか、代わりの対策で済ませるか、どのリスクを残すか。この判断の考え方は、システムを作るときのセキュリティ要件定義で行うリスクアセスメントと同じです。対策の選び方から、残存リスクを関係者と合意するところまでは、次の記事で詳しく解説しています。

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

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

sys-univ.com

2026.09.17

PHP2Shellなら、現場ではどう対応するか

PHPの採用領域と運用体制の違い

まず、PHPがどのようなシステムで使われているかを整理します。

たとえばBASEは、PHPによる大規模な商用ECを継続的にリアーキテクチャしてきた経緯を技術ブログで公開しています。システムの種類だけで管理水準が決まるわけではなく、SIerが管理するシステムにも古い環境は残り、一般のWebサイトにも高度な管理をしている例はあります。今回問われたのは、実行環境を誰が管理し、どれだけ迅速に更新できるかでした。

影響対象はアプリケーションではなくPHPランタイム

PHP2Shellは、PHP本体の脆弱性です。WordPressやLaravelを更新しても解消しません。確認すべきなのは、実際にWebリクエストを処理しているPHPのバージョンと実行方式です。

PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどを影響対象に挙げています。mod_phpではアプリケーションのコードが動く前に攻撃が成立することが実証され、最もリスクが高いとされました。PHP-FPMでも、CVE-2026-109619で条件付きの攻撃成立が確認されています。設定変更で一部の経路は減らせますが、PHP公式は完全な緩和策はないとし、更新を強く求めています。

仮想事例：LB配下の公開Webシステム

ここからは説明用の仮想事例です。インターネットに公開されたWebシステムで、ロードバランサー（LB）の配下に複数台のWeb/APサーバーがあり、それぞれでPHPが動いているとします。DBや外部APIと接続しており、一時的なサービス停止は業務上許容できます。私なら、次の流れを基本に検討します。

①〜③ 影響を調査し、必要なら公開を止める

構成管理台帳だけでなく実際の稼働環境と照合して、どのサーバーでPHPが動いているかを確認します。攻撃可能で修正まで安全を確保できなければ、LBでSorry画面に切り替えます。Sorry画面はPHPに依存しないLBの固定応答や静的コンテンツで返し、Web/APサーバーへの直接アクセス、管理用の別ポート、公開API、IPv6など、LBを迂回する経路も確認します。

④ パッチを適用し、実際の稼働状態を確認する

見落としやすいのがこの段階です。パッケージを更新しても、PHP-FPMやApacheを再起動しなければ古いランタイムが動き続けます。Webサーバーが使うPHPとコマンドラインのPHPで、バージョンが異なることもあります。コンテナは修正版のイメージで置き換え、オートスケールの起動テンプレートも更新しなければ、後から増えたサーバーが修正前の状態で立ち上がります。ディストリビューションが修正をバックポートしている場合は、表示バージョンではなくベンダーのアドバイザリやパッケージの修正履歴で判断します。

⑤ セキュリティ確認と正常性確認を行う

修正前に侵害を受けていなかったかも調べます。JPCERT/CCは、不自然に長い、または異常な形式のPHPSESSID Cookie、不審なmultipart/form-data形式のリクエストとその前後のメモリ上限エラーやHTTP 500、PHPワーカーの異常終了や頻繁な再起動の3点の確認を推奨しています。痕跡がないことは侵害がなかった証明にはならず、疑わしい兆候があれば証拠保全や再構築も検討します。

パッチ適用後は、既存機能に不具合が生じていないかを確認するデグレード確認（無影響確認）が必要です。私が携わったシステムでは、この確認のために正常性確認スクリプトとテスト項目一覧を平時から作成・整備していました。今回のようなケースでも、それらを使ってDB接続、主要業務画面、外部連携、ログ出力や監視の動作を確認する想定です。ただし、すべてのケースで正常性確認スクリプトで対応できわけるではなく、事象事に適用可否を検討します。

⑥ LB配下へ段階的に再公開する

修正済みのノードを1台ずつLB配下に戻し、エラー率、応答時間、CPU使用率、DB接続数を見ながら範囲を広げます。これは全対象ノードの安全を確保したうえでの段階的な復旧であり、未修正のサーバーを公開したまま順番にパッチを当てるという意味ではありません。

PHPだけに特別な対処をしているわけではない

この流れはPHPに固有のものではありません。Javaのランタイムでも、Webサーバーでも、OSやRDBMSでも、影響を確認し、リスクを評価して対策を選び、安全と業務の両面を確かめて再開する考え方は共通です。差を生むのは、判断基準と確認手順を平時から持っているかどうかです。

こうした判断と準備は、システム基盤エンジニアの日常業務の延長にあります。平時に構成と手順を整え、稼働を保ち、いざというときには安全な状態へ戻す。基盤エンジニアの仕事の全体像は、次の記事で紹介しています。

システム基盤・クラウドエンジニアの仕事｜整える、保つ、戻す

システム基盤エンジニアの仕事内容を、インフラエンジニアとの違いから実務まで解説。サイジング、標準化、監視、可用性、バックアップ、AWS移行、障害対応を大規模SIの実例を交えて紹介します。

sys-univ.com

2026.08.17

脆弱性対応で本当に重要なのは、更新できる状態を維持すること

緊急時に「すぐ更新できない」理由

今回は、サポート終了バージョンへの対応も課題になりました。8.1以前は公式の修正版がなく、サポート中の版への移行にはアプリケーションやプラグインの互換性確認と改修が必要です。長く更新されていないシステムでは、設計資料が不足していたり、当時の担当者がいなかったり、保守契約が終わっていたりもします。IPAも今回の注意喚起で、こうした理由で更新が難しくなる場合があると指摘しています。パッチが出ても、安全に適用できるとは限らないのです。

こうした事態を避けるため、企業システムではOSやミドルウェアのサポート終了を見据え、計画的にバージョンアップやシステム更改を行います。重大な脆弱性が見つかってから更新方法を検討するのではなく、平時から更新可能な状態を維持しておくことが重要です。

保守終了を契機としたシステム更改については、システム更改で学ぶ、プログラミングだけではない仕事の全体像で、基盤設計からテスト、移行までの進め方を解説しています。

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

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

sys-univ.com

2026.07.17

更新できる状態を維持することも運用設計

迅速に動くには、平時から次の状態を保つ必要があります。使っているOSやミドルウェアの製品とバージョン、サポート期限を把握していること。パッチ適用時の影響範囲を確認でき、正常性確認手順が整っていること。サービスの停止と再開の判断基準と責任者が決まっていること。そして、更新後の監視と復旧の手順を用意していることです。

これらは脆弱性が見つかってから短期間で整えられるものではありません。正常性確認の手順も、機能追加や構成変更に合わせて更新し続けて初めて、緊急時に使えるものになります。

脆弱性対応とは、パッチを当てる作業ではない

重大な脆弱性への緊急対応を「想定内」にできるのは、重大な脆弱性が見つかることを前提に、情報収集から対応基準、対象の特定、適用の要否、正常性確認、再開までを平時に準備しているからです。成立条件を確実に排除できるなら緊急パッチを見送る判断もあり、PHP2Shellのように攻撃リスクが高く修正まで安全を確保できなければ、一時停止も合理的な選択です。どちらも、脆弱性の特徴と実際のシステム構成を確かめたうえで下す判断です。

PHP2Shellが社会問題になった背景には、普及範囲の広さに加え、管理体制や更新のしやすさがシステムごとに異なるという事情がありました。これはPHPに限った話ではありません。

脆弱性対応とは、単にパッチを当てる作業ではありません。影響を調査し、対策を選択し、安全に業務を継続・再開するための運用設計なのです。

参考文献

1. IPA「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」（2026年10月22日公開、10月27日更新） https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html
2. IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（2026年10月21日） https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
3. PHP公式「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-5
4. PHP公式「Supported Versions」 https://www.php.net/supported-versions.php
5. JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（2026年10月22日公開、10月29日更新） https://www.jpcert.or.jp/at/2026/at260033.html
6. FIRST「Common Vulnerability Scoring System Version 4.0」 https://www.first.org/cvss/v4.0/
7. NIST「Guide to Enterprise Patch Management Planning, SP 800-40 Rev.4」 https://csrc.nist.gov/pubs/sp/800/40/r4/final
8. W3Techs「Usage statistics of PHP」 https://w3techs.com/technologies/details/pl-php
9. BASEプロダクトチームブログ「事業継続のためにPHPを使ったサービスを継続的に進化させていくこと」 https://devblog.thebase.in/entry/leverage_php
10. ITmedia NEWS「高市総理『大至急、PHPパッチ適用を』Xで異例の要請」（2026年10月22日） https://www.itmedia.co.jp/news/article/2610/22/2000002483/
11. Impress Watch「国内大手サービスで緊急メンテやサービス停止 PHP脆弱性で対策」（2026年10月21日） https://watch.impress.co.jp/docs/news/2150159.html

ある処理で、全角アンダースコア「＿」を含むデータを探したところ、意図しない大量のレコードが検索対象になる事象が発生しました。調査では、公開されていたサポート情報と実機の動作が食い違い、最終的にOracle側の不具合と確認されました。しかし、製品側に修正があるからといって、パッチ適用がプロジェクトの最適解とは限りません。

本記事では、事象の把握→原因の切り分け→対策の比較→実施→効果確認→再発防止の過程を紹介します。あわせて、Oracle Database 19cの公式仕様に基づく現在の書き方と、読者自身が確認するための検証SQLを示します。

先に結論：Oracle 19cでのLIKE検索

• ワイルドカードは半角の%（0文字以上）と_（1文字）。全角の％と＿は通常の文字として扱うのが公式仕様です。
• 利用者が入力した半角%・_を文字として探すときは、ESCAPE句で明示的にエスケープします。バインド変数だけではワイルドカード化を防げません。
• 過去の案件で採用したLIKECへの一律変更は、19cでの一般的な推奨規約ではありません。照合順序・データ型も含めて、実際に使用するDB環境で検証して判断します。

※障害事例は特定リリースの記録ですが、Oracle 19cの説明・SQL例は公式仕様に基づいており、筆者は19c実機での再現・効果検証を実施していません。利用するリリース、文字セット、データ型、照合順序で読者自身が検証してください。

1. 事象発生：全角アンダースコアの検索で想定外の大量ヒット

何を検索したかったのか

アプリケーションでは、データに含まれる全角アンダースコア「＿」を、文字そのものとして検索したいという要件がありました。ところが、問題が発生したOracle Database 11.2.0.1環境では、次のような検索が想定外の結果になりました。

-- 過去の障害を説明するために匿名化したSQL
-- 両端の % は半角、中央の ＿ は全角
SELECT *
FROM TEST
WHERE EFG LIKE '%＿%';

本来は「全角アンダースコア（＿）を含む行」だけを検索するはずでした。ところが、当時のOracle環境では、全角＿が「任意の1文字」を表すワイルドカードとして扱われる不具合がありました。

この結果、LIKE '%＿%' という条件で、全角＿を含まない1文字以上の値まで一致し、ほぼ全件がヒットしてしまいました。

問題は、検索結果が誤るだけでなく、不要なデータまで検索対象となり、処理負荷も増大することです。 実際、この案件でも性能問題をきっかけに調査を開始しました。

半角・全角の違いは目視では分かりにくい

SQLのレビュー画面では、特に半角_と全角＿を見落としやすくなります。また、問題の本質は「全角文字が常にワイルドカードになる」ことではありません。過去の検証記録では、パターンに半角の%や_が混在したとき、全角％・＿がワイルドカードとして動作する現象が問題となりました。

2. 現状把握・原因調査：仕様、データ型、実機結果を突き合わせる

まず再現条件を小さくする

障害対応では、いきなり本番SQLを広範囲に修正するのではなく、現象を小さな表と短いSQLで再現します。この案件でも、CHAR、NCHAR、NVARCHAR2、VARCHAR2を使い、半角・全角のアンダースコアを格納したテストデータで挙動を確認しました。

調査の観点は、次の4つに分けられます。

各国語キャラクタセットは、例えば次のSQLで確認できます。

SELECT parameter, value
FROM NLS_DATABASE_PARAMETERS
WHERE parameter IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

過去のサポート調査では、各国語キャラクタセットが固定幅かどうかも論点になりました。再現性を評価するときは、実際の環境で確認した文字セット名と、対象列の型を記録します。

サポート文書と実測結果が一致しなかった

当時のサポート情報には、特定のNCHAR・NVARCHAR2環境では、全角の％をワイルドカードとして扱わないという説明がありました。しかし、検証環境では半角記号との組合せなどにより、説明と一致しない結果が得られました。

サポート窓口への初期問い合わせでは、特定リリースの「仕様」とする説明が提示されました。しかし、当時のサポート文書では全角記号をワイルドカードとして扱わないと説明されている一方、手元の実機では半角記号が混じると一致範囲が広がりました。私は、仕様の説明だけでは今回のSQL実行結果を説明できないと考えました。 そこでSQL、データ型、再現条件、エラーを具体的に提示し、継続調査を依頼しました。その後、Oracle側から製品の不具合に起因する事象と考えられるとの回答があり、11.2.0.4で修正済みと報告されました。

ここで重要なのは「メーカーの回答を疑う」という姿勢ではありません。文書の記述と実測が異なる場合に、同じ条件で再現できる証拠をそろえ、技術的な説明がつくまで調べることです。技術的な事実を確定させると、対策を比較する土台ができます。

3. 対策の立案・評価：ORA-01424と将来互換性まで比較する

対策を「直せるか」ではなく「全体コスト」で比べる

原因が製品不具合だと分かると、パッチ適用が第一候補に見えます。しかし、稼働中システムのパッチ適用では、問題の検索処理以外の業務機能にも影響しないかを確認する必要があります。今回の案件では、パッチの適用作業そのものより、広範囲の影響調査・回帰テスト・リリース調整にかかる工数が大きいと評価しました。

複数の業務グループを集めてアクション会議を開催し、方式・基盤側が技術評価・再現検証を主導、業務側には影響範囲と運用上の回避可否の確認を依頼しました。GLとして、技術的な正しさに加え、PMと業務側が費用・リスク・運用制約を含めて選択できるよう整理したのです。

これは特定案件での費用・リスク評価です。パッチにセキュリティ修正が含まれる場合、サポート要件がある場合などは、別の結論になることがあります。

ORA-01424を生んだのはどの書き方か

実機確認で明らかになったのは、「全角記号をエスケープする」という方針自体が、リリースの違いによって成立しなくなることでした。

-- 旧リリース（11.2.0.1）では ORA-01424 を確認
SELECT * FROM TEST WHERE EFG LIKE '%\＿%' ESCAPE '\';

-- 同じ旧リリースで実行できた、LIKEC＋全角エスケープ
SELECT * FROM TEST WHERE EFG LIKEC '%\＿%' ESCAPE '\';

-- ただし上のLIKEC文は11.2.0.4の検証環境では ORA-01424

ORA-01424が発生するのは、ESCAPE '\'に指定したエスケープ文字の次に、リテラル化の対象となる半角%・_やエスケープ文字自身ではなく、通常文字である全角＿が続くためです。修正前に成立した「全角記号のエスケープ」が、修正後には無効な指定になることを理解する必要があります。

対策を採用する前に、修正対象の現行環境だけでなく、将来のアップグレード先でも同じSQLが成立するかを確認したことが、二度の改修を避けるうえで重要でした。

なぜLIKECをSQL規約として採用したのか――保守サポートと技術的な認識をそろえる

今回重視したのは、LIKEとLIKECのどちらが一般的に優れているかではありません。調査では、旧環境のNCHAR・NVARCHAR2列に対し、LIKEに全角エスケープを付けるとORA-01424になる一方、LIKECなら実行できる組合せを確認しました。保守サポートからもLIKECへの書き換えが回避策として提示され、原因、成立する回避方法、リリースによる挙動の違いについて、サポートと技術的な認識をそろえることができました。

ただし、将来のアップグレード後には、全角記号をエスケープしたLIKECがORA-01424になることも実機で確認しました。そこでプロジェクトのSQL規約では、「パターンマッチングにはLIKECを使い、半角%・_を文字として探す場合にエスケープする。全角％・＿はエスケープしない」という方針を定めました。

この規約は、旧環境に存在した全角記号の問題をすべてSQLだけで解消するという意味ではありません。今回の対応目的を、新規・改修SQLの記述を統一すること、影響のある既存機能のリスクを抑えながら業務を継続すること、将来のアップグレード時に同じ箇所を再改修しないことと定め、改修量が大きい一方で対象データが限定的な部分には運用回避を併用しました。

この対策で目的を達成できることについて、保守サポートから得た技術的根拠を持ち、PMや業務側に説明して実施方針の合意につなげられたことが重要です。 自分たちの推測だけではなく、問い合わせ結果と実機検証に基づいて判断したことは、後から対応理由を説明する際にも役立ちます。保守サポートが確認したのは製品動作と回避策に関する技術的見解であり、改修・運用回避の適用範囲や工数の判断はプロジェクト側の責任で決めました。

今回パッチを見送り、SQL規約と運用回避を選んだ理由

今回の障害への個別対処としてパッチを当てることは選択しませんでした。製品修正を適用すれば問題箇所は直っても、影響調査を対象SQLだけで済ませられず、調査・試験の総コストが大きかったためです。

一方、SQL修正であれば対象機能を絞って検証できます。ただし、既存SQLの改修箇所が膨大なのに、問題となるデータや利用場面が少ない場合は、改修・試験の工数が効果に見合いません。そこで影響の大きさと対象データの量、運用で吸収できる負担を比較し、必要なSQL修正と運用回避を使い分ける方針を選びました。新規・改修SQLにはLIKECの規約を適用し、既存機能のうち費用対効果が見合わない範囲は運用面で対処します。

4. 対策の実施：変更範囲を絞り、SQL規約と運用を整える

改修対象と運用対象を分けて展開する

SQL規約を改訂し、パターンマッチングにはLIKECを利用すること、半角の%と_をリテラルとして検索するときはエスケープすること、全角の％と＿にはエスケープを付けないことを定めました。新規・改修SQLではこの方針を使い、既存機能については改修の費用対効果と業務影響を見て対応方法を選びました。

SQL改修が膨大でも、対象データが限られ、現場で無理なく回避できるなら、運用対応の方が合理的な場合があります。運用回避を選んだ機能については、対象条件と対処手順を業務側に周知する必要があります。

GLの役割は、技術評価と業務上の判断をつなぐこと

今回、複数の業務グループを集めたアクション会議で、影響調査と対応の方向性を整理しました。方式・基盤側がSQLの再現検証と対策評価を主導し、業務側には対象機能や対象データ、運用回避の可否を確認してもらいました。

PMへの説明では、パッチ適用の作業費だけでなく、DB全体の影響調査・回帰テスト・変更管理の総コストと、SQL改修後の将来互換性を比較しました。さらに、保守サポートに確認した技術的な内容を対策の根拠として示し、業務側とは修正する範囲と運用回避する範囲を調整しました。技術的に可能な対策と、プロジェクトとして選ぶべき対策は必ずしも同じではありません。 GLには、製品側の技術的見解を確認するだけでなく、PM・業務側の合意形成を通じて実行可能な対策へ落とし込む役割があります。

今回のように、データベースで発生した問題が必ずしもDB側の設定だけで解決するとは限りません。SQLの実装や業務要件にも踏み込み、アプリケーション担当者や保守サポートと連携して原因を切り分けることも、DBAの重要な仕事です。

DBAが担う物理設計、性能管理、障害対応、バックアップ・復旧などの役割については、次の記事で詳しく解説しています。

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

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

sys-univ.com

2026.08.03

5. 効果の確認：検索結果の正しさと将来互換性を確認する

SQLの実行可否・検索結果・将来互換性を確認する

SQLの検証では、エラーが出ないだけでは合格にできません。「全角＿を含む行だけを返す」という要件を満たすか、含まない行が混ざらないかまで確認します。さらに、同じ検索処理が将来のアップグレード後にも成立するかを調べます。

実行できるSQLと、業務要件どおりの結果を返すSQLは別です。 この区別が、原因調査でも、対策評価でも重要でした。

次章以降の規約・テスト項目に反映する際は、全角と半角を混ぜた入力、エスケープ文字、NULLや空文字なども含め、同じ不具合を再び見落とさないようにします。現行Oracle向けの具体的なSQL例は第7章で紹介します。

6. 歯止め：個別対処をプロジェクト全体のルールにする

SQL規約に判断結果を反映する

実案件では、SQL規約に「パターンマッチングにおけるLIKECの利用」を新設し、設計・コーディング時の確認基準としてプロジェクトに展開しました。

重要なのは、調査担当者だけが知っている注意点を、ほかの開発メンバーも実践できるルールに変えたことです。規約、レビュー観点、テストデータまで揃えてこそ、障害対応が再発防止につながります。

当時の規約改訂は、その案件の環境と将来のリリース変更を考慮したものです。現在のOracle 19c向けの規約としては、そのままコピーせず、次節に示すようにLIKEを原則としたうえで、必要な例外条件を整理します。

再発防止は「注意喚起」で終わらせない

プロジェクト内へ周知するだけでなく、SQLレビューで確認する項目と、テストで使う文字の組合せを具体化します。例えば、検索条件に利用者入力が含まれる処理では、半角%・_・エスケープ文字、全角％・＿、NULLや空文字をテストデータに含めます。

修正箇所だけでなく、SQLの作り方とレビュー観点を変えることが歯止めになります。既存の機能が大きく、全面改修が現実的でない場合には、運用制約を明示し、将来の改修時に見直す対象として管理することも必要です。

7. Oracle 19cではどう書くか：LIKE・ESCAPE・照合順序

Oracle 19cの公式仕様では全角は通常の文字

Oracle Database 19cのSQL言語リファレンスでは、LIKEのワイルドカードとして認識するのはASCII相当の半角%と_で、全角の％と＿は通常の文字として扱うと説明されています。また、Oracleはほとんどの場合にLIKEを推奨し、LIKECはUnicodeの完全な文字単位で比較する必要がある場合の選択肢と位置付けています。

そのため、19cで旧案件のSQL規約をそのまま移植し、すべてのLIKEをLIKECへ変更する必要はありません。適切な演算子は検索要件に基づいて選択します。

適用時は列のデータ型・照合順序・入力値の取り扱いを確認します。

入力値のワイルドカードはバインド変数だけでは防げない

現行システムで起こりやすいのは、検索欄に利用者が入力した%や_がそのままワイルドカードとして解釈され、想定より広い範囲に一致してしまう問題です。

例えば次のSQLは、SQLインジェクションを防ぐ目的でバインド変数を使用していても、:keyword中のワイルドカードが有効なままです。

-- バインド変数を使っていても、入力中の % や _ はワイルドカードとして働く
SELECT *
FROM TEST
WHERE EFG LIKE '%' || :keyword || '%';

利用者入力を通常の文字列として部分一致検索したい場合は、先にエスケープ文字自体を二重化し、その後%と_をエスケープします。次は説明用のSQLです。

-- :keyword を1か所でバインドするSQL例
-- 未入力はNULLとして扱い、検索対象としない
WITH input_keyword AS (
    SELECT :keyword AS keyword FROM dual
)
SELECT t.*
FROM TEST t
CROSS JOIN input_keyword k
WHERE k.keyword IS NOT NULL
  AND t.EFG LIKE
      '%' ||
      REPLACE(
        REPLACE(
          REPLACE(k.keyword, '\', '\\'),
          '%', '\%'
        ),
        '_', '\_'
      ) || '%'
      ESCAPE '\';

REPLACEは、エスケープ文字→%→_の順序で適用します。逆順にすると、新たに挿入したエスケープ文字が再度処理され、意図しない検索パターンになる可能性があります。

Oracleは空文字列をNULLとして扱うため、未入力を検出する条件としてLENGTH(:keyword) > 0を追加する必要はありません。未入力で全件表示する仕様の場合は別途分岐してください。また、上の例ではバインド変数はSQL中の1か所です。実運用ではアプリケーション側で文字列をエスケープしてから単一のバインド変数として渡す方法も選べます。

データ型がNVARCHAR2の場合は、文字列リテラルとバインド値の型変換も検証してください。また、検索語にSQL構文を連結するのではなく、値をバインドして渡す方針は維持します。

実機で確認するSQL：VARCHAR2とNVARCHAR2を比較

以下は読者のOracle 19c環境で試せる検証手順です。テスト専用スキーマで作成し、DBの文字セット・セッション設定も記録してください。全角・半角の字形が入力時に変換されていないかにも注意します。

-- 検証用テーブル（業務データは使用しない）
CREATE TABLE LIKE_TEST (
    ID NUMBER PRIMARY KEY,
    TXT_V VARCHAR2(40 CHAR),
    TXT_N NVARCHAR2(40)
);

INSERT INTO LIKE_TEST VALUES (1, '東京＿本店', N'東京＿本店');
INSERT INTO LIKE_TEST VALUES (2, '東京_本店',  N'東京_本店');
INSERT INTO LIKE_TEST VALUES (3, '東京％本店', N'東京％本店');
INSERT INTO LIKE_TEST VALUES (4, '東京%本店',  N'東京%本店');
INSERT INTO LIKE_TEST VALUES (5, '東京本店',   N'東京本店');
INSERT INTO LIKE_TEST VALUES (6, NULL, NULL);
COMMIT;

-- ① 全角＿を含む値の検索：VARCHAR2／NVARCHAR2で比較
SELECT ID, TXT_V FROM LIKE_TEST WHERE TXT_V LIKE '%＿%' ORDER BY ID;
SELECT ID, TXT_N FROM LIKE_TEST WHERE TXT_N LIKE N'%＿%' ORDER BY ID;

-- ② 半角_はESCAPEを付け、文字として検索
SELECT ID, TXT_V FROM LIKE_TEST WHERE TXT_V LIKE '%\_%' ESCAPE '\' ORDER BY ID;
SELECT ID, TXT_N FROM LIKE_TEST WHERE TXT_N LIKE N'%\_%' ESCAPE '\' ORDER BY ID;

-- ③ 全角＿にESCAPEを付けるとどうなるか（エラー確認用）
SELECT ID, TXT_V FROM LIKE_TEST WHERE TXT_V LIKE '%\＿%' ESCAPE '\' ORDER BY ID;
SELECT ID, TXT_N FROM LIKE_TEST WHERE TXT_N LIKE N'%\＿%' ESCAPE '\' ORDER BY ID;

-- ④ LIKECを使用した全角＿の検索
SELECT ID, TXT_V FROM LIKE_TEST WHERE TXT_V LIKEC '%＿%' ORDER BY ID;
SELECT ID, TXT_N FROM LIKE_TEST WHERE TXT_N LIKEC N'%＿%' ORDER BY ID;

-- 確認終了後、必要な場合のみ実行
-- DROP TABLE LIKE_TEST PURGE;

公式仕様上、①と④では全角＿を通常文字として扱い、②では半角_をエスケープし、③は無効なエスケープ指定となることが想定されます。実際の結果は照合順序・文字セットを含めて検証し、条件ごとの一致行・エラー番号を記録してください。必要に応じて、後述する照合順序の条件も記録してください。

照合順序によって文字の一致判定が変わる場合がある

Oracle 19cで全角＿をワイルドカードとして扱わないことと、全角・半角の文字が比較上同じと見なされるかは別の問題です。LIKEの一致判定は、列・式の照合順序（collation）の影響を受けます。大文字・小文字、アクセント、文字幅など、区別したい属性がある場合は、対象DBの照合設定と実際の検索結果を確認してください。

-- セッションの比較設定を記録する
SELECT parameter, value
FROM NLS_SESSION_PARAMETERS
WHERE parameter IN ('NLS_COMP', 'NLS_SORT');

NLS_COMPやNLS_SORTに加え、列・式で指定された照合順序が評価に影響する場合もあります。検索結果の差を調査するときは、SQLだけでなく、これらの環境条件を合わせて記録することが重要です。

検索パターンの先頭に%を置く部分一致検索は、通常のB-tree索引の範囲検索を効率よく利用しにくくなります。大量データを対象にする場合は、実行計画やI/Oを確認し、必要に応じて検索方式・索引設計を見直します。

8. まとめ：サポートと根拠をそろえ、説明できる対策を選ぶ

今回の事例で重要だったのは、Oracleに不具合があったという事実だけではありません。検索結果の異常から出発し、再現条件を切り分け、サポート文書と実機の矛盾を根拠とともに提示して調査を依頼しました。

不具合を修正するパッチが存在しても、稼働中のシステムでは影響調査や回帰テスト、展開の負担まで含めて判断しなければなりません。今回の案件では、パッチ適用を見送り、新規・改修SQLの規約整備と、改修量に比べ対象データが少ない既存機能での運用回避を組み合わせる方針を選びました。さらに、旧環境で有効なエスケープ方式がアップグレード先ではORA-01424になることを検証し、将来の保守も考慮した規約としました。

こうした対策を選ぶうえで大きかったのは、保守サポートと技術的な認識をそろえ、その回答と実機検証を根拠にPM・業務側へ説明し、実施方針の合意を得られたことです。製品の動作についてはサポートに確認し、どの範囲を改修して何を運用で回避するかはプロジェクトで決める。その責任分界と判断根拠を明確にしたことで、対応を実行に移すことができました。

障害対応の本質は、技術的な解決策を見つけることだけではありません。品質・コスト・リスクを比較し、ベンダーと関係者の技術的な認識をそろえ、後から理由を説明できる対策を選ぶことです。 この進め方こそが、別の障害に直面したときにも再利用できる実務上のノウハウだと考えます。

なお、現在のOracle 19cでは、全角記号を通常文字として扱う仕様が明記されています。個々のシステムでは、利用者入力のワイルドカード化、文字セット、照合順序、性能面も含め、対象環境で検証して最終判断してください。

参考資料

• Oracle Database 19c SQL言語リファレンス：Pattern-matching Conditions — LIKE、LIKEC、ESCAPE、全角記号の扱い
• Oracle Database 19c Globalization Support Guide：Linguistic Sorting and Matching — NLS_COMP、NLS_SORT、照合順序

ECS/Fargateでコンテナを非rootユーザーとして実行したところ、ログ出力先のディレクトリでPermission deniedが発生したことがありました。

Dockerfileでは、ログ出力先のディレクトリを作成し、アプリケーションを実行するユーザーへchownしていました。Dockerイメージだけを見ると、書き込みできるように設定されています。

問題が起きたのは、アプリケーションコンテナとFluent Bitコンテナでログ用のVolumeを共有する構成にしたときでした。

原因を調べていくと、Dockerfileの設定が常に無効になるという単純な話ではありませんでした。Dockerfile、ECSタスク定義、Volumeを個別に確認するだけではなく、それらを組み合わせた実行時の最終状態まで設計対象にできていたかという問題に行き着きました。

この記事では、実際に発生した事象と採用した対策を、AWS公式ドキュメントで確認できる仕様と照らし合わせて整理します。採用しなかった対策候補との違いも明確にしながら、設計段階で見落とした点と、事前のPoCで確認すべきだった内容を振り返ります。

ECS/FargateでPermission deniedが発生した

今回の構成を単純化すると、アプリケーションがファイルへログを書き込み、同じVolumeをマウントしたFluent Bitがそのログを読み取る構成でした。

Application Container
非rootユーザー
        │
        │ ログ書き込み
        ↓
    Shared Volume
        │
        │ ログ読み込み
        ↓
Fluent Bit Container

ECSのタスク定義では、Volumeを定義し、アプリケーションコンテナとFluent Bitコンテナの双方へマウントしていました。

本記事では、タスク定義でボリューム名を定義した空のデータVolumeを、AWS公式ドキュメントに合わせてbind mountと呼びます。AWS公式でも、bind mountの用途として、1つ以上のコンテナにマウントする空のデータVolumeが示されています。Fargateでは、bind mountにタスクへ割り当てられたエフェメラルストレージが利用されます。

詳細は、AWS公式「Amazon ECSでのバインドマウントの使用」とAWS公式「Amazon ECS向けのFargateタスクエフェメラルストレージ」で確認できます。

アプリケーションコンテナは非rootユーザーで動作させていました。Dockerfileでは、概念的には次のようにログ出力先を作成し、所有者を変更しています。

RUN mkdir -p /app/logs
RUN chown appuser:appgroup /app/logs

USER appuser

タスク定義側のuserによる上書きはなく、実行ユーザーはDockerfileのUSERで指定した非rootユーザーでした。

このDockerイメージだけを見ると、appuserが/app/logsへ書き込めるように見えます。

ところがECS/Fargate上でタスクを起動すると、アプリケーションがログを書き込む際にPermission deniedが発生しました。

Dockerfileでchownしたのに、なぜ書き込めなかったのか

問題のポイントは、Dockerfileでchownしたディレクトリと、ECS/Fargate上でアプリケーションが実際に書き込むディレクトリが、Volumeマウント後は同じものではなかったことです。

Dockerイメージ内では、/app/logsの所有者をappuserへ変更していました。

Docker Image
    │
    └─ /app/logs
         owner = appuser

この状態だけを見れば、appuserは/app/logsへ書き込めるように見えます。

ECSで同じ/app/logsへVolumeをマウントすると、イメージ内のディレクトリはマウントによって覆い隠されます。実行中のコンテナから見えるのは、Dockerfileでchownしたイメージ側の/app/logsではなく、Volume側の/app/logsです。

Docker Image
/app/logs
owner = appuser
        │
        │ ECS Task起動
        ↓
Volumeを /app/logs へmount
        │
        ↓
イメージ側の /app/logs は隠蔽
        │
        ↓
コンテナから見える /app/logs
＝ Volume側

Dockerfileで設定したディレクトリが削除されたわけではありません。同じパスへVolumeをマウントしたことで、イメージ側のディレクトリが実行中のコンテナから見えなくなっています。

Dockerfileでchownしていても、Volumeマウント後の/app/logsが同じ所有者・権限になるとは限りません。

今回見落としていたのは、この「イメージ作成時の権限」と「Volumeマウント後の実効権限」の違いでした。

DockerfileのVOLUMEとcontainerPathが一致する場合

ここまでだけを見ると、「VolumeをマウントするとDockerfile側の権限設定は使われない」と考えたくなります。

Amazon ECSには、もう一つ重要な仕様があります。

DockerfileのVOLUMEで指定した絶対パスと、タスク定義のcontainerPathが一致する場合、ECSはそのパス内のデータをデータVolumeへコピーします。

AWS公式ドキュメントには、非rootユーザー向けに対象ディレクトリをchownし、USERを指定した後にVOLUMEを宣言する例も掲載されています。この説明の中では、既定のVolume権限を0755、所有者をrootとし、Dockerfileでカスタマイズできることも示されています。

詳細は、AWS公式「Amazon ECSでのバインドマウントの使用」を参照してください。

概念的には次のような記述です。

RUN mkdir -p /app/logs
RUN chown appuser:appgroup /app/logs

USER appuser
VOLUME ["/app/logs"]

今回使用していたDockerfileには、ログ出力先をVOLUMEとして宣言する記述はありませんでした。

Dockerfile
/app/logs を appuser に chown
        │
        ↓
ECSで同じパスへVolumeをmount
        │
        ↓
イメージ側の /app/logs は隠蔽
        │
        ↓
VOLUME宣言なし
        │
        ↓
Volumeマウント後の権限で
書き込み可否が決まる

今回の構成では、Dockerfileでchownした/app/logsへVolumeをマウントしたことで、イメージ側のディレクトリは隠蔽されました。また、Dockerfileに対象パスのVOLUME宣言がなく、VOLUMEとcontainerPathを一致させてイメージ側の状態をVolumeへ引き継ぐ仕組みも利用していませんでした。

当時は、このDockerfileとECS Volumeを組み合わせた後に、実行時にどのような状態になるのかを設計観点として持っていませんでした。

VOLUME宣言がなかったことだけで、Permission deniedの原因をすべて説明できるわけではありません。実際の書き込み可否は、Volumeマウント後のowner、group、modeと、アプリケーションの実効UID/GID、書き込み対象パスの組み合わせで決まります。

今回の問題で重要だったのは、Dockerfileでchownしたという設定だけを見て書き込み可能と判断し、Volumeマウント後にどの所有者・権限になるのかを確認していなかったことです。

今回の案件ではVOLUMEを利用する方法は採用していないため、ここではAWS公式仕様から確認できる対策候補の一つとして扱います。

実効ユーザーもDockerfileだけで確認しない

ファイルやディレクトリの権限とあわせて確認する必要があるのが、コンテナを実際にどのユーザーで実行しているかです。

ECSでは、DockerfileのUSERとは別に、タスク定義のuserでも実行ユーザーを指定できます。このパラメータはDockerのUserや--userに対応します。

今回のタスク定義ではuserを指定しておらず、DockerfileのUSERを上書きする設定はありませんでした。

設計レビューで確認すべきなのは、「DockerfileにUSER appuserと書いてある」ことではありません。

ECS上で最終的にどのUID/GIDでプロセスが動き、そのユーザーがVolumeマウント後のパスへ必要な操作をできるかまで確認する必要があります。

Volumeの権限と同じく、Dockerfileやタスク定義を個別に見るだけでは不十分です。設計対象にすべきなのは、それらを組み合わせた後の実行時の最終状態です。

userパラメータの仕様は、AWS公式「FargateでのAmazon ECSタスク定義パラメータ」で確認できます。

対策はchownの方法だけで考えない

Permission deniedが発生すると、chmodやchownの方法から考えたくなります。

今回の構成を設計の観点から見直すと、その前に確認すべきことがあります。

アプリケーションコンテナとFluent Bitの間に、そもそも共有Volumeが必要なのか。

権限をどう合わせるかだけではなく、権限調整が必要になる境界そのものをなくせないかを最初に検討します。

共有Volume自体をなくせないか

今回の構成は次のようになっていました。

Application
    ↓ file
Shared Volume
    ↓ file
Fluent Bit

ログ出力要件が許せば、アプリケーションのログをファイルへ出力せず、awsfirelensログドライバ経由でFluent Bitへ渡す構成も考えられます。

FireLensでは、アプリケーションコンテナにawsfirelensログドライバを設定し、Fluent BitまたはFluentdをログルーターとして利用できます。

詳細は、AWS公式「Amazon ECSタスク定義の例：FireLensにログをルーティングする」を参照してください。

Application
    ↓ awsfirelens
Fluent Bit

この構成に変更できれば、アプリケーションとFluent Bitの間でログファイルを共有するVolumeをなくせる可能性があります。Volumeに付随するowner、group、mode、UID/GID、マウント後の権限といった設計項目も減らせます。

実案件でも、ログ出力方式そのものを変更して共有Volumeをなくす案を検討しました。既存のログ出力方式を変更するとAP側での改修と再テストが必要になるため、今回は共有Volumeを残したうえで権限設定方法を変更する判断としました。

設計として上位の選択肢を検討しても、変更影響やプロジェクト条件によって採用できないことがあります。

重要なのは、「権限エラーをどう直すか」から始めるのではなく、「その権限設計自体をなくせないか」を一度確認したうえで、案件条件に合った方法を選ぶことです。

VOLUMEディレクティブを利用する方法

共有Volumeを残す場合には、前述したDockerfileのVOLUMEとcontainerPathの仕様を利用する方法も候補になります。

この方法ではDockerfile、すなわちコンテナイメージそのものを変更します。ECS上の課題を解決する目的でVOLUMEを追加しても、同じイメージを別の環境で実行した場合の挙動にも影響します。

今回の環境ではこの方法を追加検証していないため、AWS公式仕様から確認できる対策候補としての紹介に留めます。

補足：configuredAtLaunchはbind mountの設定ではない

対策を調べる過程では、ECSのVolumeに関する情報を複数確認しました。その中で紛らわしかったのがconfiguredAtLaunchです。

名称からはVolumeの初期設定に使えるようにも見えますが、configuredAtLaunch=trueは、ECSのデプロイ時にAmazon EBS Volumeを構成するための設定です。今回利用していたbind mountの権限を変更するためのオプションではありません。

AWS公式「Amazon ECSのデプロイ時にAmazon EBSボリューム設定を指定する」でも、configuredAtLaunchをtrueに設定したタスク定義に対して、デプロイ時にAmazon EBS Volumeを構成する仕組みとして説明されています。

同じ「Volume」という言葉で扱われていても、bind mount、EBS、EFSでは仕様も設定方法も異なります。目にした情報をそのまま設計判断に使うのではなく、自分が利用しているVolume方式を特定したうえで、該当する公式ドキュメントを確認する必要があります。

権限設定用コンテナを先行して実行する

別の方法として、Volumeの所有者や権限を設定するコンテナを先に実行し、正常終了した後にアプリケーションコンテナを起動する構成があります。

ECSではdependsOnでコンテナ間の起動依存関係を設定できます。SUCCESSを指定すると、依存先コンテナが終了コード0で完了するまで後続コンテナを開始しません。SUCCESSとCOMPLETEの依存先にはessential containerを指定できません。

詳細は、AWS公式「FargateでのAmazon ECSタスク定義パラメータ」を参照してください。

Permission Setting Container
        │
        │ Volumeの所有者・権限を設定
        │ exit 0
        ↓
Application Container
        ↓
Fluent Bit Container

権限設定用コンテナには、共有Volumeへ必要な所有者・権限を設定できる権限を持たせます。アプリケーションコンテナ自体は従来どおり非rootユーザーで実行します。

この方法であれば、アプリケーションイメージを変更せず、タスク定義を中心とした基盤側の変更で対応できます。

なお、権限設定用コンテナでVolumeの初期権限を整えても、その後アプリケーションが生成するファイルを別コンテナから読めるとは限りません。TomcatとFluent BitでVolumeを共有した際に実際に発生したPermission deniedと、UID/GID・setgid・umaskを含む権限設計について、続編で整理しました。

Fluent BitがPermission deniedでログを読めない｜ECS/Fargate共有VolumeのUID/GID設計

ECS/FargateでTomcatとFluent Bitが共有Volumeを利用する構成でPermission deniedが発生。Fluent BitのUID/GID、setgid、umask、read-onlyマウントなど、Dockerコンテナ間でログを共有する際の権限設計を実例から解説します。

sys-univ.com

2026.08.24

rootユーザーで実行する

アプリケーションコンテナ自体をrootユーザーで実行する方法もあります。

権限問題は回避しやすくなりますが、非root実行を前提としていたセキュリティ設計との整合を確認する必要があります。動作するかどうかだけではなく、なぜ非rootユーザーで実行する設計にしていたのかまで戻って判断する必要があります。

技術的に動く対策と、プロジェクトで採用できる対策は違う

今回検討した方法を、変更対象まで含めて整理すると次のようになります。

最終的には、権限設定用コンテナを先行して実行する構成を採用しました。

アプリケーション側を修正したりログ出力仕様を変更したりする場合、AP側での改修とテストが必要になります。権限設定用コンテナの追加であれば、タスク定義を管理する基盤側で変更を完結でき、既存のコンテナイメージにも影響を与えません。

変更範囲を基盤側に限定できることから、この方式を採用しました。 この構成への変更後は、非rootユーザーで実行するアプリケーションからログを正常に書き込めるようになり、Permission deniedは解消しました。

技術的に成立する対策と、プロジェクトとして採用しやすい対策は同じとは限りません。変更主体、責任分界、変更影響、追加試験の範囲まで含めて対策を決める必要があります。

なぜ設計段階で気づけなかったのか

今回の問題で重要なのは、ECSのVolume仕様を知っていたかどうかだけではありません。

結果として、Dockerfileで設定した権限と、ECSがVolumeをマウントした後の実効権限との接続部分を、設計時に十分確認できていませんでした。

Dockerfileだけを見れば、確認対象は次の範囲です。

Dockerfile
 ├ mkdir
 ├ chown
 └ USER

実際には、その後ろまで設計する必要があります。

Docker Image
      ↓
ECS Task Definition
      ↓
Volume生成
      ↓
containerPathへmount
      ↓
実効UID/GID
      ↓
Applicationからwrite
      ↓
Fluent Bitからread

「Dockerfileで対象ディレクトリをchownしたこと」と、「Volumeをマウントした実行環境でアプリケーションユーザーが書き込めること」は同じではありません。

前者は設定内容です。設計で最終的に保証したいのは後者です。

「担当者が知らなかった」で終わらせない

今回のECS Volumeの仕様を知っている担当者であれば、設計段階で問題に気づけた可能性があります。

原因を「担当者が仕様を知らなかった」で終わらせても、次の案件で同じ問題を防ぐ仕組みにはなりません。

クラウドでは、自分たちがDockerfileや設定ファイルへ直接記述するものだけでなく、クラウドサービスが実行時に生成、マウント、変更するものがあります。必要なのは、それらを含めた実行時の最終状態を設計する観点です。

今回であれば、設計レビューでは次のような項目を確認すべきでした。

Fargateで利用するbind mountはタスクのエフェメラルストレージ上にあり、bind mountを使用するすべてのコンテナが停止するとデータは削除されます。今回のようなFargateタスクでは、タスク停止時のライフサイクルまで含めて設計する必要があります。

詳細は、AWS公式「Amazon ECSでのバインドマウントの使用」を参照してください。

設計書に「Dockerfileでchownする」と書くだけでは足りません。Volumeをマウントした後に、どのUID/GIDが、どのパスへ、どの権限でアクセスできるのかを定義する必要があります。

ここまで書いて、初めて実行時の権限設計になります。

この考え方は、ECSだけに限りません。基本設計で決めた方式を、構築・テストできる状態までどう落とすかについては、次の記事で詳しく整理しています。

• 基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程
• 【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

事前PoCでは、ここまで確認すべきだった

今回の問題は、設計段階のPoCで発見できた可能性があります。

ECSでコンテナが起動することだけを確認するPoCでは足りません。

今回のPermission deniedを検出するだけなら、大掛かりな試験は必要ありませんでした。本番と同じ非rootユーザーとVolume構成でタスクを起動し、次の範囲を確認すれば、書き込み権限の問題を設計段階で検出できた可能性があります。

ECS Task起動
      ↓
実効UID/GIDを確認
      ↓
Volume mount後のowner/group/modeを確認
      ↓
Applicationからファイル作成
      ↓
Applicationからディレクトリ作成

これが、今回の問題を発見するために必要だった最低限のPoCです。

ログ機構全体の成立性まで確認するのであれば、その先にFluent Bitからの読み取り、ログ転送、Task再作成後の動作まで確認します。

Applicationからwrite
      ↓
Fluent Bitからread
      ↓
ログ転送
      ↓
Task再作成後も成立するか

設計レビュー表とPoCで似た項目を確認するのには理由があります。

設計では、実行時に成立すべき状態を定義する。PoCでは、その状態が実際の環境で成立することを確認する。

今回なら、設計では「非rootのアプリケーションユーザーがVolumeマウント後のログ出力先へwriteできる」と定義します。PoCでは、本番相当のユーザーとVolume構成で実際にファイルを作成して確認します。

PoCは「AWSのサービスが使えるか」を試すだけの工程ではありません。

本番と同じ境界を通したときに、設計したシステムが成立するかを確認する工程です。

クラウドリフトでも、AWSサービス単体の機能確認だけを行い、オンプレミスからクラウドへ移した後の実際の処理や運用まで通さなければ、問題が後工程で表面化します。今回のVolume権限も規模は小さいものの、構造は同じでした。

クラウドリフトでPoCに何を含めるべきかは、次の記事で詳しく整理しています。

• クラウドリフトの失敗は構築前に始まっている｜PoC不足が手戻り・コスト超過・納期遅延を招く理由
• クラウドリフトPoCで「動いた」は確認できた。しかし業務では使えなかった｜10の設計リスク① 可用性・性能・ストレージ・バックアップ・監視

今回の事象から得た3つの学び

一つ目は、Dockerfileは設定であって、実行時の最終状態ではないことです。

DockerfileでUSERやchownを指定しても、それだけでECS上の実効ユーザーやVolumeマウント後の権限は確定しません。設計で確認するべきなのは、各設定をECS上で組み合わせた後の最終状態です。

二つ目は、設計で抜けやすいのはコンポーネント単体ではなく、その接続部分であることです。

Dockerfileの設定もECSのVolume定義も、それぞれ単体で存在しています。今回確認できていなかったのは、DockerイメージとECS Volumeを接続した後に、どのユーザーがどのファイルシステムへアクセスするのかという実行時の状態でした。

三つ目は、PoCでは本番と同じ境界を通す必要があることです。

コンテナが起動したことだけでは、システムとして成立したことにはなりません。本番と同じUID/GID、Volume、マウントポイント、サイドカーを含めて実際の処理を通し、設計した状態が成立することを確認する必要があります。

今回の事象を振り返ると、

「Dockerfileでchownした」ではなく、「Volumeをマウントした後に、必要なユーザーが必要な操作をできる」まで確認して初めて権限設計は完了する

ということになります。

クラウドでは、自分たちが直接構築・設定したものだけを見るのでは足りません。クラウドサービスが実行時に生成、変更、接続するものまで含めて最終状態を設計し、不確実性が残る境界は事前PoCで実際に通す。

今回のPermission deniedは小さな権限エラーでしたが、クラウド設計とPoCで何を確認するべきかを改めて考えるきっかけになりました。

参考にしたAWS公式ドキュメント

• Amazon ECSでのバインドマウントの使用

• Amazon ECS向けのFargateタスクエフェメラルストレージ

• FargateでのAmazon ECSタスク定義パラメータ

• Amazon ECSのデプロイ時にAmazon EBSボリューム設定を指定する

• Amazon ECSタスク定義の例：FireLensにログをルーティングする

関連記事

ECS/Fargateの権限問題を、設計レビューで何を確認するかという観点を、運用設計や要件定義の工程まで広げて確認したい方は、以下の記事も参考にしてください。

• 運用設計とは？運用設計書の目次サンプルと項目一覧｜基盤SE視点
  ログ、監視、ジョブ、バックアップ、障害対応など、本番運用を成立させるために設計しておくべき項目を整理しています。

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

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

sys-univ.com

2026.08.14

• 要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
  RFPや提案内容を前提に、スコープや責任分界を確定し、設計・構築・テストできる水準まで具体化する実務を解説しています。

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

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

sys-univ.com

2026.08.12

とはいえ、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を採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ
• セキュリティ要件定義の進め方｜リスクアセスメントから対策・残存リスクを決める方法

データを遠隔地に保全し、サーバやデータベースを別リージョンで起動できるようにすることは重要です。ただ、それだけで業務を再開できるとは限りません。

DBが復旧している。Web/APも起動している。それでも利用者がログインできなければ、オンラインサービスは利用できません。

DRで確認すべきなのは、リソースが存在するかではなく、利用者が認証され、必要な処理を実行し、安全に業務を継続できる一連の経路が成立するかです。

Amazon Cognitoは、この問題を分かりやすく示す例です。

本記事では、実際のDR検討で経験した問題と、2026年に提供開始されたAmazon Cognito User PoolsのMulti-Region Replication（MRR）を題材に、AWSのDR設計で何を確認すべきかを整理します。

1. DRは「データ」「起動」「業務経路」の3レベルで考える

DRを考えるときは、どこまで復旧できれば「DRが成立した」と考えるのかを3つのレベルに分けると整理しやすくなります。

レベル1は、データが残っている状態です。

データベースのバックアップやスナップショット、オブジェクトストレージ、AMIなどを遠隔リージョンへ保管し、大規模障害でもデータや復旧資材を失わないようにします。

レベル2は、システムを起動できる状態です。

DRリージョンでネットワーク、サーバ、コンテナ、データベースなどを起動し、アプリケーションが動作できるところまで復旧します。

レベル3は、安全に業務経路が成立する状態です。

利用者がシステムへ到達できるか。認証できるか。適切な権限でAPIやDBへアクセスできるか。KMS、Secrets、外部IdP、外部APIなどの依存先がDRリージョンでも利用できるか。

ここまで確認して初めて、業務を再開できます。

バックアップがあることは、DRの一部にすぎません。

図　DRは「データが残る」「システムが起動する」だけではなく、「安全に業務経路が成立する」ところまで確認する

2. DRではリソース一覧ではなく「1トランザクション」を追う

DR設計では、EC2、RDS、S3、Lambdaなど、AWSリソース単位で対策を並べがちです。

リソース単位の確認は必要ですが、それだけでは依存関係を見落とします。

見るべきなのは、利用者が1回の業務処理を完了するまでに何を通るのかです。

Webシステムなら、利用者はDNS、WAFやロードバランサー、Web/APを通り、認証基盤で認証された後、DBや外部APIを使って業務処理を行います。

認証基盤が外部IdP、メール、SMS、Lambda Triggerへ依存する構成もあります。KMS、Secrets Manager、証明書は複数の処理から参照される共通依存です。

監視、ログ、運用管理端末、管理アクセスもDR時に必要になります。

2026年9月のAWS Security Blog記事でも、Cognito MRRを利用する場合、Lambda、WAF、SNS、SES、CloudWatchなどのリージョナルな構成を別リージョンのレプリカ側で準備する必要があると説明されています。

DR設計で見る単位を、

何のリソースを複製したか

から、

利用者が業務を完了するまでに、どの依存先を通るか

へ変えることが重要です。

図　DRでは利用者からDBまでの本流だけでなく、認証、外部IdP、KMS、Secrets、外部API、監視など、その業務経路を支える依存先まで確認する

認証フローは構成によって異なります。Amazon CognitoのManaged Loginでは、ブラウザがCognitoのドメインへ直接遷移する場合があるため、この図は依存関係を理解するための概念図です。

3. 実案件で直面した「データは送れるが、認証できない」問題

Amazon Cognitoが大阪リージョンへ対応する前の案件で、東京リージョン全体が利用できなくなった場合に、大阪リージョンで業務を継続する構成を検討しました。

Cognitoが大阪リージョンで利用可能になったのは2023年9月1日です。今回の案件はそれより前の検討でした。

AWSの発表はWhat’s Newで確認できます。

私がこの案件で強く印象に残ったのは、データを大阪へ持っていけることと、大阪で業務を継続できることは別だったという点です。

Web/APやデータ、復旧資材を大阪側へ持つ構成は検討できました。

しかし当時はAmazon Cognitoを大阪リージョンで利用できず、認証を大阪側だけで完結できませんでした。

Web/APやDBを大阪側に用意しても、利用者がログインできなければオンライン業務は成立しません。

結果として、大阪側ではデータを遠隔保全するところまでとし、認証を含めて大阪側で業務を継続するDR構成にはできませんでした。

この経験は、前章で整理した「データが残る」だけでは、「安全に業務経路が成立する」ところには届かない例です。

DR要件を「別リージョンにデータを保管する」とだけ定義すると、この違いを見落とします。

4. Cognito MRRで何が変わったのか

2026年6月、Amazon Cognito User PoolsにMulti-Region Replication（MRR）が追加されました。

提供開始時の概要はAWS What’s Newで確認できます。

MRRではPrimary User Poolを権威あるユーザープールとし、ユーザー属性、ハッシュ化された認証情報、グループ、App Client、外部IdP設定などをSecondaryへ複製します。

レプリケーションはPrimaryからSecondaryへの一方向です。

Secondaryではサインインやトークン発行などの認証処理を継続できますが、Primaryとまったく同じ機能を持つわけではありません。

図　MRRにより認証基盤を別リージョンへ複製できるようになった。ただし、レプリケーションだけでDRが完成するわけではなく、フェイルオーバー方式や周辺依存を別途設計する必要がある

以下は、2026年10月時点のAmazon Cognito Developer Guideに基づく主な前提と制約です。

詳細な制約はAmazon Cognito Developer Guideに整理されています。

issuerもDRの依存関係になる

MRRを検討するときはOIDC issuerにも注意が必要です。

Cognitoにはoriginal issuerとupdated issuerがあり、AWSはMRRを含むUser Poolでupdated issuerを推奨しています。

updated issuerではOIDC discoveryとJWKSを複数リージョンで提供できます。

MRR自体はoriginal issuerでも利用できます。

ただしoriginal issuerのOIDC discovery endpointとJWKS endpointは単一リージョンに紐づきます。リージョン障害時にはJWKSを取得できない可能性があり、アプリケーションが公開鍵を動的に取得してトークン署名を検証する構成では影響を受ける可能性があります。

updated issuerへ移行できない場合、AWS Security Blogでは、アプリケーションのトークン検証層でJWKSをキャッシュする方法を緩和策として挙げています。

認証サービスがSecondaryで動作しても、トークンを検証する側が参照するJWKSまで確認しなければ、認証経路全体の可用性は評価できません。

また、2026年10月時点のDeveloper Guideでは、updated issuerはApplication Load BalancerのCognito認証、およびAmazon API Gateway REST APIのCognito authorizerとは互換性がありません。

サービス仕様が変わる可能性があるため、実装時には最新ドキュメントの確認が必要です。

ALB認証の制約とJWKSキャッシュは別の論点です。JWKSキャッシュはアプリケーション側のトークン検証層に対する対策であり、ALB認証の非互換を解消する方法ではありません。

5. 東京→大阪DRで確認すべきこと

2026年6月のMRR提供開始時点では、対応リージョンに東京は含まれていましたが、大阪は含まれていませんでした。

提供開始時点の対象リージョンはAWS What’s Newで確認できます。

ここで重要なのは、

「大阪リージョンでCognitoを利用できる」ことと、「東京のCognito User Poolを大阪へMRRできる」ことは別

という点です。

東京→大阪を前提にFull-stack DRを設計する場合、MRRの対応リージョンを設計時点で確認する必要があります。

対応していなければ、MRRを利用できる別リージョンの組み合わせへ設計を変更する方法があります。この場合、ユーザー情報が別リージョンへ複製されるため、データ所在や組織内の規程との整合も確認が必要です。

AWS Security Blogでも、Secondaryのリージョンを選ぶ際にはdata sovereigntyやresidency要件を確認するよう説明しています。

MRRを使わず、別User Poolを自前で同期する方法も考えられます。

AWSは、MRR以前の手動エクスポートやインポートには、データ露出や不整合のリスク、利用者へのパスワードリセットといった課題があったとAWS News Blogで説明しています。

単に「同期処理を作ればよい」と考えず、運用負荷とセキュリティまで含めて評価する必要があります。

MRRの対象リージョンは追加される可能性があるため、実装時には最新のAWS公式情報を確認してください。

6. 「認証だけのDR」と「システム全体のDR」は違う

2026年9月のAWS Security Blogでは、CognitoのフェイルオーバーをAuthentication-only failoverとFull-stack failoverに分けています。

Authentication-only failoverは、アプリケーション本体を同じリージョンで稼働させたまま、認証だけをCognitoのSecondaryへ切り替える方式です。

Full-stack failoverは、compute、data store、API、authenticationなど、アプリケーション全体を別リージョンへ切り替える方式です。

Lambda TriggerがリージョナルなDynamoDBへアクセスする場合など、認証処理の周囲にある依存先もDR側で成立させる必要があります。

先ほどの東京→大阪の実案件は、東京リージョン全体が利用できなくなることを想定していました。

求めていたのはFull-stack failoverです。

CognitoのMRRが成立しても、Web/AP、DB、API、Lambda、KMS、Secrets、外部サービスなどがDRリージョンへ切り替わらなければ、Full-stack DRにはなりません。

複数コンポーネントの切替を協調させる仕組みとして、AWSは**Amazon Application Recovery Controller（ARC）**も紹介しています。

認証、compute、database、APIなどをリカバリープランとして扱い、切替を協調させる選択肢です。

DR時だから認証を弱めてよいわけではない

DRでは可用性の回復が優先されやすく、「ログインできないなら認証を一時的に緩める」という発想が出ることがあります。

避けるべき設計です。

情報セキュリティでは、可用性だけでなく機密性と完全性も維持する必要があります。

MRRのSecondaryでTOTP MFAを利用できないなら、障害発生後に認証水準を下げるのではなく、SMS OTP、Email OTP、passkeyなど、利用可能な代替方式を平時に設計します。

SMSを使う場合も、Secondary側でSNS設定や送信元IDの登録が必要です。登録に時間がかかる場合があるため、DR発動後に準備するものではありません。

フェイルオーバー先ではPrimaryとは別に失敗回数が管理されます。ロックアウトまでの失敗回数が引き継がれないため、切替後のロックアウト判定はPrimaryの状態と一致しない場合があります。

DRでは、可用性だけでなく、認証・アクセス制御の挙動が切替前後でどう変わるかも確認する必要があります。

セキュリティリスクから要件を導き、残存リスクまで評価する考え方については、次の記事で整理しています。

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

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

sys-univ.com

2026.09.17

7. フェイルオーバーは「何を異常とみなすか」まで設計する

Managed LoginやFederationを利用する構成では、Cognito MRRはRoute 53 Health Checkを利用したフェイルオーバーに対応しています。

Custom DomainだけでなくPrefix Domainでも利用できます。

Health Checkを設定し、Unhealthyになった場合、CognitoはSecondaryを利用する認証経路へ切り替えられます。

重要なのは、MRRを有効にするだけで切り替わるわけではないことです。

何をもってPrimaryが異常と判断するのかは、利用者側が設計します。

単純なHTTP死活監視では、認証処理そのものが失敗していてもHealthyになる可能性があります。

AWS Security Blogでは、CloudWatch Syntheticsで実際の認証フローを実行し、その結果をCloudWatch AlarmとRoute 53 Health Checkへつなぐ例を紹介しています。

単なる死活監視ではなく、認証処理がエンドツーエンドで成立しているかを見る考え方です。

SDKやCognito APIを直接利用する構成では、アプリケーション側でRegional Endpointの切替を行います。

AWS Security Blogでは、カスタムエンドポイントやプロキシを介してPrimaryとSecondaryへルーティングする構成も示されています。

DR設計書に、

CognitoはMRRを利用する

とだけ書いても不足です。

最低でも、何を監視するのか、どの状態を障害と判定するのか、自動切替か運用者判断か、誰が復旧を判断するのか、どこまでを一緒に切り替えるのかを決める必要があります。

この領域は基本設計と運用設計の両方にまたがります。

可用性方式や依存関係を基本設計で具体化する考え方については、次の記事で整理しています。

基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程

基本設計は画面設計だけでは終わらない。ログ・バックアップ・ジョブ・監視など、本番運用を見据えた基盤設計の論点を、ファイルアップロードや夜間バッチの実例で整理します。

sys-univ.com

2026.06.20

監視条件、障害判定、切替手順、復旧後の戻し方については、次の記事で整理しています。

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

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

sys-univ.com

2026.08.14

8. AWS DR設計で確認したいチェックリスト

MRRの前提

• □ 利用するUser PoolとPrimary、SecondaryのリージョンがMRRの対象か
• □ EssentialsまたはPlus、Multi-Region KMS KeyなどMRRの前提を満たすか
• □ original issuerとupdated issuerのどちらを使うか決め、その依存先への影響を確認したか

障害時に認証できるか

• □ SecondaryをACTIVEにする前に、Lambda、WAF、SNS、SES、ログなどのリージョン固有設定を完了したか
• □ SMSを使う場合、Secondary側のSNS設定と送信元IDなどの登録を済ませたか
• □ TOTP利用者の代替認証方式を平時に決めたか
• □ Route 53 Health Checkで何を異常とみなすかを決めたか
• □ 自動切替か手動切替か、判断者と復旧判断を決めたか
• □ SDKやAPIを直接利用する場合のRegional Endpoint切替方式を決めたか

業務経路全体が成立するか

• □ DNS、WAF/LB、Web/AP、DBまでDR側で利用できるか
• □ KMS、Secrets、証明書がDRリージョンでも利用できるか
• □ 外部IdP、外部API、外部システムへの接続を確認したか
• □ 認証後に呼ばれるLambdaや、その先のデータストアまで確認したか
• □ 監視、ログ、運用管理端末、管理アクセスがDR時にも利用できるか
• □ 「ログイン → 業務処理 → データ参照・更新」まで実際にDRテストしたか
• □ Health Checkを意図的に反転し、PrimaryからSecondaryへの切替と復帰を確認したか

AWS Security Blogでは、Health Checkの反転やAWS Fault Injection Service（FIS）を使ったフェイルオーバーテストも紹介されています。

チェックリストで重要なのは、個々のAWSサービスが存在するかではありません。

業務を開始して終了するところまで、一連の経路を実際に通せるかです。

9. まとめ

バックアップがあることと、DR先で業務を継続できることは同じではありません。

データが残っている。システムも起動できる。それでも、認証やKMS、外部サービスなどの依存先が成立しなければ、利用者は業務を再開できません。

Amazon CognitoのMRRによって、User Poolを別リージョンへ複製し、認証基盤の可用性を高められるようになりました。

MRRにもリージョン条件、Secondaryの機能制限、issuer、リージョナルサービス、フェイルオーバー方式など、確認すべき依存関係があります。

Authentication-only failoverとFull-stack failoverも区別する必要があります。

DRで確認すべきなのは、

「何をバックアップしたか」ではなく、「利用者が安全に業務を再開できるか」

です。

この視点で1トランザクションの経路を追うと、バックアップ一覧やリソース一覧だけでは見えなかったDRの弱点が見えてきます。

参考資料

Amazon Cognito Developer Guide — Multi-Region replication for user pools
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-multi-region.html

Amazon Cognito Developer Guide — Identity provider and relying party endpoints
https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints.html

AWS Security Blog — Architecting resilient authentication with Amazon Cognito multi-Region replication
2026年9月15日
https://aws.amazon.com/blogs/security/architecting-resilient-authentication-with-amazon-cognito-multi-region-replication/

AWS What’s New — Amazon Cognito now supports multi-Region replication
2026年6月4日
https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-cognito-multi-region/

AWS News Blog — Improve your application resilience with Amazon Cognito multi-Region replication
2026年6月3日
https://aws.amazon.com/blogs/aws/improve-your-application-resilience-with-amazon-cognito-multi-region-replication/

AWS What’s New — Amazon Cognito がアジアパシフィック（大阪）リージョンとイスラエル（テルアビブ）リージョンでご利用いただけるようになりました
2023年9月1日
https://aws.amazon.com/jp/about-aws/whats-new/2023/09/amazon-cognito-new-regions/

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

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

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

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

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

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

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