コピーの所要時間とは別に、切替の判断基準を決める必要があったからです。コピー中も業務が動くなら、転送先にはいつの時点のデータが揃うのでしょうか。DataSyncのタスクが成功したら、そのまま切り替えてよいのでしょうか。

私が移行計画で分けて考えるのは、初回コピーにかかる時間と、書き込みを止めてから切替が終わるまでの時間です。以下では、S3バケット間のコピーを例に、両方をどう見積もり、何を確認して切り替えるかを整理します。

1. 最大5 Gbpsで見積もれるのは、転送時間の理論下限

エージェントを使用しないDataSync転送では、1タスクあたり最大5 Gbpsです。たとえば20 TBを5 Gbpsで連続転送できたとしても、約8時間53分かかります。これは10進単位で容量を速度で割った試算です。実際のタスクには、対象オブジェクトの列挙や転送結果の検証も含まれます。移行計画では、本番に近いサイズ分布・件数で、起動から完了までの所要時間を測ります。

速度を改善したい場合は、同じデータセットでBasicとEnhancedを比較します。Basicは準備・転送・検証を順に進め、Enhancedは列挙・準備・転送・検証を並行して進めます。EnhancedではAPIの PrepareDuration、TransferDuration、VerifyDuration がいずれも0を返すため、比較には TotalDuration を使います。切替リハーサルでは、タスクの時間とは別に、書き込み停止から照合・切替までを通しで計測します。

もう一つの選択肢は、互いに重複しないプレフィックスに分け、複数のタスクを並列に実行する方法です。たとえば archive/2024/ と archive/2025/ を別タスクに割り当てます。並列化の効果は、最初のタスクを開始してから最後のタスクが完了するまでの時間で判断します。データ量が一方に偏ると、そのタスクの完了が全体を左右します。

参考：AWS DataSyncのクォータ ／ タスクモードの選択 ／ タスク実行結果のAPI仕様

2. タスクが成功した時点で、S3のデータは揃っているか

AWSサポートからは、準備時に転送対象を洗い出し、転送時にその情報と照らし合わせる仕組みだと説明を受けました。準備中や転送中に追加・上書き・削除されたオブジェクトは、その回の転送に変更が反映されないことがあるとのことです。この処理順序はBasicの説明と整合します。S3間では2024年10月からEnhancedも選べるため、挙動やログを調べるときは、まず対象タスクのモードと検証設定を確認します。

対策として、転送元の更新を止めてデータの状態を固定する時間を設けること、その確保が難しければS3レプリケーションなどの別の手段を検討することを勧められました。

たとえば、Enhancedで report.csv の転送と検証が済んだ後、タスク全体が終了する前に、転送元で同じキーが上書きされたとします。Enhancedの既定の検証対象は、そのタスクで転送したデータです。タスクの結果が SUCCESS でも、上書き後の内容が転送先に反映されたかは、結果ステータスだけでは判断できません。更新のタイミングによっては、検証不一致が起きることもあります。

Basicでは、対象範囲全体を転送後に検証する POINT_IN_TIME_CONSISTENT を選べます。これは転送後の照合設定で、書き込みを続ける転送元をある時点で固定する機能とは役割が異なります。切替の基準時点を定め、その時点の状態と転送先をどう照合するかを手順に落とします。

参考：Enhancedの提供開始 ／ DataSyncの検証オプション ／ 検証不一致のトラブルシューティング

3. 最終差分と照合を、切替手順に組み込む

以下は、初回コピーを稼働中に行い、最終差分の転送前に書き込みを止められる場合の設計例です。

初回コピーと最終差分を分ける

1. 稼働中に初回コピーを行う。 結果とログを確認し、エラーや再転送が必要な対象を洗い出します。
2. 転送元への更新を止める。 アプリ、バッチ、外部連携などの書き込み元を洗い出し、実行中の更新が終わった時点を切替の基準にします。照合が終わるまで、転送先への業務書き込みも止めておきます。
3. 差分転送を実行する。 変更分の転送に加え、転送元にないキーを転送先にも残すかを事前に決めます。削除を反映する REMOVE を使う場合は、転送先だけに存在するデータを消してよい範囲かを確認します。全件転送の TransferMode=ALL では転送先をスキャンしないため、PreserveDeletedFiles=REMOVE は組み合わせられません。
4. 結果を照合して切り替える。 タスク結果、エラーや想定外のスキップ、対象キーの不足や余分なキーを確認し、必要な範囲では内容も照合します。条件を満たしたら、参照先と書き込み先を切り替えます。

差分転送を再実行して転送0件になることは、補助確認に使えます。たとえば、転送元で削除されたキーを転送先に保持する設定では、転送0件でも古いキーが残り得ます。切替直前のキーとサイズの確認には、対象プレフィックスを ListObjectsV2 で両側ともページ末尾まで取得して照合します。S3 Inventoryは日次・週次の出力なので、事前調査や監査に使います。

参考：DataSyncのタスクオプション ／ ListObjectsV2 ／ S3インベントリ

同じサイズの上書きは、どう見分けるか

キーとサイズだけでは、同じサイズに上書きされたオブジェクトを見分けられません。大容量オブジェクトでは、ETagをそのまま内容照合に使うのにも注意が必要です。マルチパートアップロードで作られたETagはオブジェクト全体のMD5とは異なり、同じ内容でもパートの分け方が違うとETagが異なる場合があります。

オブジェクト本体を取得せずに照合するなら、両バケットで HeadObject を ChecksumMode=ENABLED で呼び出し、両方が FULL_OBJECT で、同じアルゴリズムのチェックサムが取得できる場合に値を比較します。たとえば、両方にオブジェクト全体の ChecksumCRC64NVME があれば、その値を照合します。片方しか値がない場合や、片方がパート単位の値を組み合わせる COMPOSITE の場合は、この方法で直接比較できません。

比較できる値がなければ、必要な対象だけ両側から読み出し、オブジェクト全体のSHA-256を同じ方法で計算して比べます。既存データに比較可能なチェックサムがどの程度あるかを事前に確認します。読み出し照合が必要な対象が多ければ、そのデータ量と照合時間をリハーサルで測り、費用も見積もります。

移行費用を見積もる際は、DataSyncの料金に加え、S3のリクエスト料金も含めます。切替前の照合で両バケットを列挙したり、チェックサムを取得したり、オブジェクト本体を読み出したりする場合は、その分の LIST・`HEAD`・`GET` も見積もりに入れます。タグなども業務で使う場合は、内容のチェックサムとは別の照合項目にします。

参考：S3オブジェクトのETagとチェックサム ／ HeadObject ／ マルチパートアップロードのチェックサム

書き込みを長く止められない場合は、S3レプリケーションを検討する

S3レプリケーションを使う場合は、まず転送元・転送先の両方でバージョニングを有効にします。既存バケットで有効にする場合は、上書きや削除後に残る旧バージョンの保管費用と、ライフサイクルによる保持・削除ルールを見直します。そのうえで、ライブレプリケーションのルールを先に設定し、新規書き込みを複製する経路を作ってから、S3 Batch Replicationで既存分を移します。

現行形式のレプリケーションルールでは、削除マーカーの複製は既定で無効です。複製が必要なら、ルールが対応していることを確認して明示的に有効にします。バージョンIDを指定した削除や、ライフサイクルが作成した削除マーカーは複製されないため、要件に含まれる場合は別途扱いを決めます。

レプリケーションは非同期です。切替前には、既存分のジョブ結果とライブレプリケーションの未完了・失敗を確認し、旧バケットへの書き込みをどこで締め切るかを決めます。書き込みを一切止められない場合は、旧バケットに遅れて到達する更新も含め、アプリ側の書き込み先の切替方法を設計する必要があります。

参考：レプリケーションの要件 ／ S3 Batch Replication ／ S3が複製する対象と削除時の挙動

まとめ

移行計画に所要時間を書くときは、初回コピーと書き込み停止を別の欄にします。停止時間の欄には、最終差分だけでなく、照合と切替までの実測時間を入れます。切替判定の欄には、対象範囲、削除の扱い、内容まで確認する範囲を書きます。今回の問い合わせで私が改めて意識したのは、切替当日に迷わないよう、どの時点のデータを揃え、何が一致すれば進めるかを移行計画の段階で決めておくことです。

ある処理で、全角アンダースコア「＿」を含むデータを探したところ、意図しない大量のレコードが検索対象になる事象が発生しました。調査では、公開されていたサポート情報と実機の動作が食い違い、最終的に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、照合順序

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

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/

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

2026年7月、OpenAIの評価環境で動いていたAI Agentが隔離を越えて外部へ到達し、7月11日から13日にかけてHugging Faceの本番基盤を侵害した。

しかも、これは後から確認された一連の想定外動作の一例にすぎない。9月には、6月にOpenAIのAgentが豪州政府のMedicare統計ポータルへ無許可アクセスしていた事例も公表された。発生時点で把握・通知されたものではなく、後日の調査で明らかになった事例である。

境界の突破は7月に突然始まったわけではなく、5月から断続的に続いていた。両社が公開した技術レポートには、どの経路が使われ、どこで止まり、どこでは止まらなかったかが記録されている。

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

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

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

リスクアセスメントの進め方そのものは、セキュリティ要件定義の記事で整理している。

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

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

sys-univ.com

2026.09.17

ここでは方法論の説明はせず、事件で実際に何が効いて何が効かなかったかという、設計時には得にくい材料を扱う。

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

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

侵害の経路

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

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

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

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

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

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

資産の範囲をどう置くか

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

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

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

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

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

脅威主体としてのAI Agent

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

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

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

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

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

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

悪意は要件ではない

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

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

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

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

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

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

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

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

図　達成不能なら止まれる設計にする

モデル自身に「止まる判断」を期待するだけでなく、実行基盤側にハードリミットを持たせる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

特にEKSでは、Podにノードロールの認証情報を使わせない構成を前提にする。IRSAやEKS Pod IdentityでPodごとの権限を分離し、ノードのIMDSを必要としないPodからはアクセスできないようにする。IMDSv2の必須化やhop limitの設定は、その制御を補強する手段になる。

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

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

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

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

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

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

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

• iam:PutRolePolicy
• iam:AttachRolePolicy

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

Read Only ≠ Low Risk

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sys-univ.com

2026.08.14

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

それでも残るもの

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

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

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

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

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

17,600という数字の意味

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

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

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

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

原則は変わっていない

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

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

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

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

まとめ

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

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

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

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

参考資料

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

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

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

関連記事

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

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

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

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

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

  

  sys-univ.com

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

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

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

  

  sys-univ.com

  2026.08.14

ある異なるAWSアカウントにある2台のRDS for OracleをDatabase Link（以下、DBリンク）で接続する構成を検討していたときの話です。

一方はAWS KMSによるストレージ暗号化あり、もう一方は暗号化なし。

注：本記事では、KMS暗号化ありのRDS AをDBリンク元、暗号化なしのRDS BをDBリンク先として説明します。NNEではDBリンク元とDBリンク先で設定するパラメータが異なるためです。

クロスアカウントRDS for OracleのDBリンク構成

つまり、A側に作成したDBリンクからBへ接続します。

ここでいう「DBリンクの方向」は接続を開始する方向です。AからBの表をSELECTすれば結果データはBからAへ返るため、DBリンクの向きとデータが流れる向きは同じとは限りません。

最初に疑問だったのは、

「KMSで暗号化されたRDSから、暗号化されていないRDSへDBリンクを張って問題ないのか」

ということでした。

問い合わせでは「データが文字化けしないか」という表現も使いました。しかし今振り返ると、本当に確認したかったのは文字コードの問題ではありません。

ストレージ上で暗号化されたデータがOracle Databaseからどう見え、DBリンクではどの状態で扱われるのか

という疑問でした。

さらに、

• 相手AWSアカウントへKMSキーを共有する必要があるのか
• 別VPC間でDBリンクを成立させるには何が必要なのか

も確認しました。

このとき印象的だったのが、AWSサポートから最初に、

「今回の暗号化とは、RDSのストレージボリューム暗号化という理解でよいか」

という趣旨の確認が入ったことです。

この確認が、今回の記事の本質です。

RDS for Oracleで「暗号化」と言っても、実際には複数のレイヤーがあります。

• AWS KMSによるRDSストレージ暗号化
• Oracle Transparent Data Encryption（TDE）
• Oracle NetのNNE／SSL/TLS
• AWSネットワーク基盤側の通信暗号化

「RDSが暗号化されている」ことと「DBリンク通信が暗号化されている」ことは別の話です。

本記事では、2026年8月時点のAWS公式仕様も確認しながら、この違いを整理します。

結論｜KMSによるRDS暗号化はDBリンクへ引き継がれない

結論から言えば、AWS KMSによるRDSストレージ暗号化が原因で、DBリンクのSELECT結果が暗号文になることはありません。

そもそも、DBリンク先のOracle Databaseがリンク元RDSのKMSキーを使ってデータを復号する仕組みではありません。

AWSサポートからも、KMSによる暗号化はストレージレイヤーで処理され、ストレージから読み出す際には透過的に復号されるため、ストレージ暗号化を原因としてDBリンクのデータが文字化けすることはない、という回答を得ています。

この「ストレージ暗号化を原因として」という限定も重要です。文字コードやOracle Netなど、別の原因による問題まで否定しているわけではありません。

AWS公式でも、RDSの保存時暗号化は基盤ストレージ、ログ、自動バックアップ、Read Replica、スナップショットなどを対象とし、RDSが復号を透過的に処理すると説明されています。

概念的には次の関係です。

KMSによるRDS暗号化とOracle Database／DBリンクの関係

Oracle Database自身が、KMSで暗号化されたストレージブロックを受け取ってKMSキーで復号しているわけではありません。

したがって、DBリンク接続のためにA側のKMSキーをB側AWSアカウントへ共有する必要もありません。

また、AからDBリンク経由でBへデータを書き込んだ場合、A側のストレージ暗号化属性がBへ引き継がれるわけでもありません。Bへ保存されたデータを暗号化するかどうかは、B自身のRDS暗号化設定で決まります。

なお、既存の非暗号化RDS DBインスタンスを、そのまま後から暗号化済みに変更することはできません。暗号化したスナップショットコピーを作成し、そこから新しいDBインスタンスをリストアする必要があります。

つまり、

「必要になったら後から暗号化をONにすればよい」

という設計にはできません。

RDS for Oracleで分けて考える4つの暗号化レイヤー

今回の話は、次の4レイヤーに分けると整理できます。

ポイントは、どれか一つを有効にすれば他のレイヤーまで暗号化されるわけではないことです。

KMS暗号化はどこまでの話なのか｜TDEとの違いとKMSキー共有

Oracle TDEはKMS暗号化とは別物

Oracle Transparent Data Encryption（TDE）は、Oracle Database側でデータを暗号化する仕組みです。

RDSのKMS暗号化がOracleより下のストレージレイヤーで処理されるのに対し、TDEではOracle Databaseがデータを書き込む前に暗号化し、読み出す際に復号します。

RDS for OracleでTDEを利用できるのはOracle Enterprise Edition＋BYOLです。Oracle WalletとTDE master keyはAmazon RDSが管理します。

TDEには設計時に注意すべき制約があります。

AWSではRDS for OracleのTDEをpermanent／persistentなオプションとして扱っており、一度有効にすると無効化できず、TDEを含まないOption Groupへ変更することもできません。TDEを利用するDBスナップショットは共有できません。

つまり、TDEは後から簡単に外せるオプションではありません。

RDS for Oracleには、TDE以外にもオンプレOracleの前提をそのまま持ち込めない制約があります。詳しくは「RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった」で整理しています。

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

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

sys-univ.com

2026.08.30

また、TDEで保護されたデータも、暗号文のままDBリンクへ流れるわけではありません。Oracleが論理データへ復号した後、Oracle Netへ渡されます。

その先の通信を暗号化するのはNNEまたはSSL/TLSです。

RDSのKMS暗号化 ≠ Oracle TDE ≠ DBリンク通信の暗号化

という関係です。

DBリンク接続ではKMSキー共有は不要

DBリンクでは、各RDSの保存時暗号化は各RDS内で処理されます。

A側OracleがB側のKMSキーを使うわけでも、B側OracleがA側のKMSキーを使うわけでもありません。

したがって、クロスアカウントDBリンクのためにKMSキーを共有する必要はありません。

一方、暗号化されたDBスナップショットそのものを別AWSアカウントへ共有する場合は、KMSキーへのクロスアカウントアクセスが関係します。

AWSアカウントのデフォルトKMSキーで暗号化されたスナップショットはそのまま共有できません。AWS公式では、対象アカウントへアクセスを許可したcustomer managed keyを用意し、そのキーでスナップショットをコピーして共有し、共有先でも自アカウントのKMSキーを指定してコピーする手順が案内されています。

DBリンクとスナップショット共有では、

論理データへアクセスするのか、暗号化されたAWSリソース自体を共有するのか

が違います。

別AWSアカウントのRDS間でDBリンクを成立させる条件

KMSキー共有が不要でも、別AWSアカウントのRDSへそのままDBリンクを張れるわけではありません。

先に、AからBへOracle Netで到達できるネットワークを作る必要があります。

確認順序は、

VPC間接続 → Route → Security Group／NACL → DNS → Oracle Net → Database Link

と考えると分かりやすいです。

AWSサポートからはVPC Peeringが例示されました。AWS公式のRDS for Oracle DBリンク手順でも、同一VPCまたはピア接続されたVPC間で、有効なルート、ACL、Security Group、名前解決を確認するよう案内されています。

ただし、Database LinkというOracle機能自体がVPC Peeringを要求しているわけではありません。

本質的な要件は、DBリンク元からDBリンク先のRDS endpointとOracle Listenerポートへ到達できることです。

本記事ではAをDBリンク元としているため、基本となる通信方向は、

• A側：Bへのoutbound
• B側：AからOracle Listenerポートへのinbound

です。

Security Groupはstatefulなので、戻り通信のためだけに対称のinboundルールを追加する必要はありません。一方、Network ACLを独自に制限している場合はstatelessなので、復路も確認します。

接続先にはIPアドレスを固定せず、RDS endpointのDNS名を使用します。RDS自身も、基盤IPはフェイルオーバー等で変わり得るため、DNS名を利用することを推奨しています。

別VPCの場合はDNSも確認します。

VPC Peering越しでAmazon提供DNSを利用する場合は、VPC側のenableDnsSupportと、Peering接続側のDNS解決サポートを確認します。カスタムDNSを利用している場合は、そのDNSサーバーがDBリンク先を解決できる必要があります。

つまり、

Routeがある／SGが通る／DNSが引ける

を分けて確認する必要があります。

DBリンク通信の暗号化はKMSとは別に構成する｜NNEの設計

DBリンクのOracle Net通信を暗号化する方法の一つがNative Network Encryption（NNE）です。

RDS for Oracleでは、Option GroupへNATIVE_NETWORK_ENCRYPTIONを追加して利用します。NNEはOracle Databaseの全エディションで利用できます。

ここで重要なのは、

NNEオプションを追加しただけで「暗号化を必須にした」と考えてはいけない

ことです。

DBリンク元RDSはOracle Net clientになる

本記事の構成では、

• A：DBリンク元 → Oracle Net client
• B：DBリンク先 → Oracle Net server

です。

AWS公式も、DBインスタンスがDatabase Linkを利用するとき、そのDBインスタンスはクライアントとして動作すると明記しています。

したがって主に確認するのは、

A側：

SQLNET.*CLIENT

B側：

SQLNET.*SERVER

です。

Requestedは「必須」ではない

RDSのNNE Optionでは、SQLNET.ENCRYPTION_CLIENTとSQLNET.ENCRYPTION_SERVERの既定値はいずれもRequestedです。

ただし、この既定値はNNEオプションを追加した後の話です。NNEオプションを追加していないRDSが、最初からNNEで通信しているという意味ではありません。

また、Requestedだから暗号化されないという意味でもありません。

CLIENT／SERVERともにRequestedで双方がNNEを利用できれば暗号化は成立します。

問題は、相手が暗号化に対応しなくても、暗号化なしで接続できる場合があることです。

つまり、

「暗号化されることがある」と「暗号化を必須条件として保証する」は別です。

AからBへのDBリンクについて暗号化を必須にしたい場合、A側を例えば、

SQLNET.ENCRYPTION_CLIENT=Required

とします。

B側がRequestedでも、接続が成立すれば暗号化されます。暗号化条件を満たせなければ接続自体が失敗します。

一方、B側を、

SQLNET.ENCRYPTION_SERVER=Required

とすると、DBリンクだけでなくBへ接続する他のOracle Netクライアントにも暗号化を要求します。

したがって、

DBリンクだけを暗号化したいのか、RDSへの全接続を暗号化したいのか

を分けて設計します。

Requiredだけでなく暗号方式も確認する

さらに注意したいのが暗号アルゴリズムです。

Oracle Database 19cなどのRDS NNE設定では、既定候補にAESだけでなくRC4、3DES、DESも含まれ、既定リストはRC4_256から始まります。AWSはDES、3DES、RC4をsecure encryption methodとは扱っていません。

そのため、

SQLNET.ENCRYPTION_CLIENT=Required

だけでは、使用する暗号方式まで安全なものへ限定したことにはなりません。

例えばAES256へ限定する設計なら、

A側：

SQLNET.ENCRYPTION_CLIENT=Required
SQLNET.ENCRYPTION_TYPES_CLIENT=AES256

B側：

SQLNET.ENCRYPTION_SERVER=Requested または Required
SQLNET.ENCRYPTION_TYPES_SERVER=AES256

のように、CLIENT／SERVER双方で共通する方式を設定します。

SQLNET.ALLOW_WEAK_CRYPTOとSQLNET.ALLOW_WEAK_CRYPTO_CLIENTSはいずれも既定値がTRUEです。弱い方式を禁止する場合はこちらも確認しますが、既存クライアントのパッチレベルや互換性へ影響するため、接続元を確認した上で変更する必要があります。

暗号化と整合性チェックは別設定

NNEでは、通信の暗号化とは別にデータ改ざんを検知するチェックサムも設定できます。

SQLNET.ENCRYPTION_*をRequiredにしても、SQLNET.CRYPTO_CHECKSUM_*が自動的にRequiredになるわけではありません。

盗聴対策と改ざん検知は別々に設計する必要があります。

「暗号化されているか」だけでなく方式まで確認する

設定後はV$SESSION_CONNECT_INFOを確認し、実際にネゴシエーションされた暗号方式を確認できます。

SELECT NETWORK_SERVICE_BANNER
FROM V$SESSION_CONNECT_INFO
WHERE SID = SYS_CONTEXT('USERENV', 'SID');

NNEが有効ならencryption service adapterを含む行が表示され、AES256など実際にネゴシエーションされた方式を確認できます。

見るべきなのは、

「暗号化されているか」だけではなく「何で暗号化されているか」

です。

既定候補にはRC4_256も含まれるため、AES256など設計時に想定した方式が実際に使われているところまで確認する必要があります。

なお、DBリンクによって生成されたリモートセッションをどのように特定し、証跡化するかについては、DBリンク固有の実機確認が必要です。

RDS間DBリンクはSSL/TLSでも暗号化できる

DBリンクの暗号化方式はNNEだけではありません。

AWS公式には、Oracle DBインスタンス間では、各インスタンスにOracle SSLオプションが構成されていれば、SSL/TLS endpoint経由でDatabase Linkを確立でき、追加構成は不要と明記されています。

つまり、本記事のA→B構成でも、両RDS for OracleへSSLオプションを設定することでDBリンク通信をTLS化できます。

SSLオプションを入れただけでは全通信TLSにはならない

RDS for Oracleでは、SSL接続用に通常接続とは別の第2ポートを利用します。

そのため、

• 通常ポート：非SSL通信
• SSLポート：SSL/TLS通信

を同じDBインスタンスで併存できます。

つまり、SSLオプションを追加しただけでは、そのRDSへの全通信がTLS必須になるわけではありません。

TLSを必須にする場合は、SSL/TLS endpointを利用することに加えて、Security Group等で非SSL経路を許可していないかも確認する必要があります。

NNEはOracle NetのネゴシエーションでRequiredを使って強制し、TLSはポートと接続経路で強制するという違いがあります。

TLSバージョンとCipher Suiteも確認する

2026年8月時点で、RDS for Oracleの19c／21cはTLS 1.0と1.2をサポートしています。

特に既存のOracle SSLオプションでは、SQLNET.SSL_VERSIONが自動的に1.0へ設定されています。既存環境では「SSLを使っている＝TLS 1.2」と判断せず、設定値を確認する必要があります。26aiではTLS 1.2のみがサポートされています。

Cipher Suiteも同様です。

19c／21cの既定Cipher SuiteであるSSL_RSA_WITH_AES_256_CBC_SHAはFIPS対応ですが、AWS公式表ではFedRAMP準拠ではありません。つまり、既定値のままで自分たちのセキュリティ要件を満たすとは限りません。

また、RDS for OracleではRSA証明書とECDSA証明書をサポートしており、SQLNET.CIPHER_SUITEへ指定する方式はDBインスタンスの証明書タイプと互換である必要があります。互換性のないCipher Suiteしか設定していないOption GroupはDBインスタンスへの関連付けに失敗します。

NNEとSSL/TLSは併用できない

NNEとSSL/TLSは、同じRDS for Oracle DBインスタンスで併用できません。

したがって、

NNEで暗号化した上にTLSを重ねる

という構成にはできません。

どちらを採用するかは、既存の接続方式、証明書管理、接続クライアント、セキュリティ基準から判断します。

重要なのは、

KMSによるRDS暗号化とは別に、Oracle Net通信の暗号化方式を選ぶ

ことです。

AWS基盤側の通信暗号化とOracle Net暗号化は分けて考える

AWSネットワーク基盤側にも通信暗号化の仕組みがあります。

Amazon RDSでは、一部のインスタンスタイプについてNitro Systemによるインスタンス間通信の自動暗号化が提供されています。ただし、対象インスタンスタイプ、同一Region、同一VPCまたはVPC Peering、Transit Gateway等の仮想ネットワークサービスを経由しないことなどの条件があります。

RDS for Oracleでは、Oracleで利用可能なインスタンスクラスと、Nitroによる自動暗号化の対象一覧を別々に確認する必要があります。

例えば、RDS全体の自動暗号化対象一覧に含まれるM7g／R7gはRDS for Oracleの利用可能クラスには含まれていません。一方、RDS for Oracleで利用可能なM7i／R7i／M8i／R8iは、2026年8月時点の自動暗号化対象一覧には列挙されていません。

したがって、「新しい世代だから自動的に暗号化される」とは判断できません。

さらに2025年11月にはVPC Encryption Controlsが追加され、AWS基盤側の転送時暗号化をMonitor／Enforceで監視・強制できるようになりました。RDS公式でも、Enforce VPCでは転送時暗号化をサポートするNitroベースのDBインスタンスのみ新規プロビジョニングできるとされています。既存VPCをEnforceへ移行する際は、まずMonitorで非準拠リソースを確認・是正する必要があります。

VPC Encryption ControlsのMonitor／Enforceの違い、Flow Logsのencryption-statusの読み方、ExclusionやTransit Gatewayを含むEnforce移行時の注意点は、「VPC Encryption Controlsとは｜Monitor／EnforceとFlow Logsの読み方」で整理しています。

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

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

sys-univ.com

2026.08.27

ただし、ここでDBリンクの記事として重要なのは、AWS基盤側の証跡とOracle Net側の証跡は同じではないことです。

VPC Flow Logsではencryption-statusとして、

• 0：not encrypted
• 1：nitro-encrypted
• 2：application-encrypted
• 3：両方
• -：状態不明、またはVPC Encryption Controlsが無効

を記録できます。

ただしAWSがapplication-encryptedとして認識する通信は限定されています。interface endpointやgateway endpointについては、AWS自身がパケット内容ではなく使用ポートから暗号化状態を推定していると説明しています。

したがって、

Flow Logsが1: nitro-encryptedだから、Oracle NetもNNE/TLSで暗号化されている

とは言えません。

逆に、Oracle NetをNNEで暗号化していても、Flow Logsがそれをapplication-encryptedとして認識するとは限りません。Nitro暗号化も適用されない経路では、Flow Logs側で0: not encryptedと評価される可能性があります。

つまり、

一方のレイヤーの証跡だけで、もう一方の暗号化状態を証明も否定もできません。

VPC Flow Logsが答えるのは、

「AWS基盤から見て、このフローをどの暗号化状態として扱っているか」

です。

NNEでV$SESSION_CONNECT_INFOから確認するのは、

「このOracle Netセッションで、どの暗号方式がネゴシエーションされたか」

です。

対象も粒度も異なります。

まとめ｜「暗号化されているか」ではなく「どのレイヤーか」で考える

今回の疑問は、

KMSで暗号化したRDS for Oracleと、暗号化されていない別AWSアカウントのRDSをDBリンクで接続するとどうなるのか

というところから始まりました。

結論は3つです。

• KMSによるRDS暗号化は保存時の暗号化であり、暗号化属性やKMSキーがDBリンク先へ伝播するわけではない
• DBリンクのOracle Net通信を暗号化するなら、NNEまたはSSL/TLSを別途設計する
• AWS基盤側の暗号化とOracle Net暗号化は別レイヤーであり、一方の証跡だけでもう一方を証明・否定できない

設計時に確認するべきなのは、

「暗号化されているか、いないか」

という二択ではありません。

「どのデータを、どのレイヤーで、どの仕組みによって暗号化し、それをどの方法で確認するのか」

まで分けて考える必要があります。

今回AWSサポートが問い合わせの冒頭で、

「今回の暗号化とは、RDSのストレージボリューム暗号化という理解でよいか」

という趣旨の確認をしてきた理由も、ここにあります。

KMS、TDE、Oracle Net、AWSネットワーク基盤。

すべて「暗号化」ですが、守っている場所も確認方法も異なります。

RDS for OracleでDBリンクを設計するときは、まずこの境界を分けるところから始めるのがよいでしょう。

関連記事

RDS for Oracleでは、暗号化以外にもオンプレミスOracleの前提をそのまま持ち込めない制約があります。また、こうしたクラウド固有の差異は、構築段階ではなく要件定義や基本設計の段階で確認しておくことが重要です。あわせて確認したい方は、以下の記事も参考にしてください。

• RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった
  SYS権限やOSアクセス、ログ確認など、オンプレミスOracleからRDS for Oracleへ移行するときに変わる運用・設計上の前提を、実案件で直面した制約から整理しています。

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

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

sys-univ.com

2026.08.30

• 基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程
  サーバー、データベース、ネットワーク、セキュリティ、監視、バックアップ、運用など、システム基盤の基本設計で何を決めておくべきかを整理しています。

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

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

sys-univ.com

2026.06.20

本シリーズでは、システム監視を「何を、どのように監視し、検知後の対応につなげるか」という観点から、前編・後編に分けて整理しています。

• 【第1部】この記事
  システム監視の基本構造／死活監視／エージェント監視・エージェントレス監視／SNMP監視／MIB・OIDなど、監視を理解するための基礎
• 【第2部】クラウド監視と「運用で使える監視設計」
  AWS CloudWatch・OCI Monitoring／既存監視のFit & Gap／監視対象・閾値・通知・一次対応まで含めた監視設計

はじめに

システム開発や基盤設計に関わっていると、「監視」という言葉は必ず出てきます。

「サーバは生きています。 `ping` は通っています」

そう報告した10分後に、業務が止まった。

原因は、Webサーバのプロセス停止だった。

サーバ自体にはネットワーク的に到達できていたため、 `ping` 監視では異常を検知できなかった。

答えは単純です。 `ping` が通ることと、システムが業務として使える状態であることは、まったく別の話だからです。

死活監視。リソース監視。ログ監視。プロセス監視。ジョブ監視。URL監視。SNMP監視。

言葉としては聞いたことがあっても、実際に「監視の仕組み」を説明しようとすると、意外と難しいものです。

若手SEの中には、監視を「サーバが落ちたらアラートが出る仕組み」「CPUやメモリが高くなったら通知する仕組み」「ログにエラーが出たらメールが飛ぶ仕組み」と理解している人もいます。

もちろん、間違いではありません。

ただし、それだけでは監視設計はできません。

監視では、何を監視するのか、どこから監視するのか、どの方式で監視するのか、どの条件で異常と判断するのか、誰に通知するのか、通知を受けた人が何を確認するのかまで決める必要があります。

監視とは、単にアラートを出す仕組みではありません。

システムの異常や異常予兆を、運用で対応できる形で検知する仕組みです。

前編では、監視サーバー、監視対象サーバー、死活監視、エージェント監視、エージェントレス監視、SNMP監視、MIB/OIDの基本を整理します。

監視を「設定」ではなく「運用で使える仕組み」として理解するために、まずは基本構造から見ていきます。

システム監視とは何か

監視をしていなければ、障害が起きても運用側は気づけません。

利用者から「画面が開かない」と問い合わせが来て、初めて障害を認識する。これは運用の失敗です。

システムが正常に稼働しているか。障害の予兆がないか。それを運用で対応できる形で検知する仕組みです。

システム監視の目的は、大きく2つあります。

• システムが正常に稼働しているかを確認する
• システムに障害予兆となる兆候がないかを確認する

業務システムでは、障害そのものを完全にゼロにすることはできません。

だからこそ、障害が発生したときに早く気づく。
影響範囲を把握する。
一次対応につなげる。
必要に応じてエスカレーションする。

そのために監視があります。

監視には「監視する側」と「監視される側」がある

まず押さえるべき基本は、監視には「監視する側」と「監視される側」があるということです。

一般的なオンプレミスや仮想基盤の監視構成では、次のような役割があります。

• 監視サーバー
• 監視マネージャー
• 監視対象サーバー
• 監視エージェント
• 運用端末
• 通知先

監視サーバー、または監視マネージャーは、監視する側です。

監視対象サーバーは、監視される側です。

Webサーバ、APサーバ、DBサーバ、ジョブ管理サーバ、ストレージ、ネットワーク機器などが該当します。

監視サーバーは、監視対象に対して定期的に確認を行います。

たとえば、Web/APサーバとの通信状況、DBサーバのCPU負荷、共有ストレージのディスク容量、ログの異常メッセージなどを収集し、異常があれば運用者や管理者へ通知します。

　　　　　　　　　　　　　　　　　　図：監視サーバーと監視対象サーバー・機器の関係

ここで重要なのは、監視は「何となく全体を見ている」のではないということです。

監視対象ごとに、何を、どの方式で、どの周期で、どの閾値で、どの通知先へ送るかを細かく決めています。

前編では、まず代表的な監視方式として、死活監視、エージェント監視、エージェントレス監視、SNMP監視を整理します。

これらは、どれか1つだけを選ぶものではありません。

実際のシステムでは、複数の方式を組み合わせます。

たとえば、次のような組み合わせです。

• ネットワーク疎通は死活監視
• OS内部のCPU、メモリ、ディスクはエージェント監視
• ネットワーク機器やストレージはSNMP監視
• Webサービスの応答はURL監視
• クラウドリソースはCloudWatchやOCI Monitoring
• アプリケーションログはログ監視
• バッチ処理はジョブ監視

つまり、監視方式は「どれが正解か」ではありません。

そのシステムで何を知りたいのか。
どこまで異常を検知したいのか。
どのタイミングで誰が対応するのか。

これに応じて選びます。

死活監視とは何か

死活監視とは、監視対象が生きているかどうかを確認する監視です。

代表的には、監視サーバーから監視対象サーバーへ `ping` を実行し、応答があるかを確認します。

システム開発では、死活監視というと、まず `ping` による疎通確認をイメージすることが多いです。

`ping` は、監視サーバーから監視対象のIPアドレスへ到達できるか、相手が応答を返すかを確認するためによく使われます。

ここで注意が必要です。

`ping` が通ることは、システムが正常に動いていることを意味しません。

少しネットワークの階層で見ると、`ping` で確認しているのは、ざっくり言えばネットワーク層レベルの到達性です。

つまり、監視サーバーから監視対象のIPアドレスへ届き、相手が応答している、ということを確認しているに過ぎません。

その上で動いているWebサーバ、APサーバ、DB、ジョブ、業務アプリケーションまで正常であることを確認しているわけではありません。

たとえば、次のような状態でも `ping` は通ることがあります。

• Webサーバプロセスが停止している
• APサーバのスレッドが枯渇している
• DBリスナーが停止している
• DB表領域が枯渇している
• 業務APが内部エラーを返している
• ログイン画面は開くが検索処理が失敗する
• バッチジョブが異常終了している
• ディスク使用率が100%に近い
• メモリ不足で処理が極端に遅い

つまり、死活監視は重要ですが、それだけでは不十分です。

`ping` による死活監視で分かるのは、「ネットワーク的に到達できるか」「機器やOSが応答しているか」という入口の状態です。

一方で、業務として使える状態かどうかを確認するには、ポート監視、プロセス監視、URL監視、ログ監視、DB接続監視、ジョブ監視など、より上位の状態を見る監視が必要になります。

なお、死活監視は `ping` だけとは限りません。

SNMPを使って機器の稼働状態を確認する場合もあります。ネットワーク機器やストレージ、UPSなどでは、SNMPでインターフェース状態、電源状態、ファン、温度、装置状態などを取得したり、SNMP Trapで機器側から異常通知を受けたりします。

エージェント監視とは何か

エージェント監視とは、監視対象サーバーに監視用ソフトウェアを導入し、そのエージェントがサーバ内部の状態を収集する方式です。

監視対象サーバーの中に入って、CPU、メモリ、ディスク、プロセス、ログ、サービス状態などを確認するイメージです。

たとえば、次のような情報は、エージェントを入れた方が取得しやすくなります。

• CPU使用率
• メモリ使用率
• ディスク使用率
• ディスクI/O
• 特定プロセスの起動状態
• 特定サービスの状態
• OSログの特定メッセージ
• ミドルウェアログのエラー
• アプリケーションログの異常
• ファイル数やファイルサイズ
• 独自スクリプトの実行結果

商用監視製品であれば、JP1、Systemwalker、Hinemosなどが代表例です。

エージェント監視のメリットは、監視対象サーバーの内部情報を細かく取得できることです。

たとえば、単にDBサーバに `ping` が通るかだけでなく、DBプロセスが起動しているか、DB関連ログにエラーが出ていないか、CPUやメモリが逼迫していないか、といった情報を取得できます。

一方で、デメリットもあります。

エージェントをインストールする必要があります。
監視対象サーバーのリソースを使います。
バージョン管理が必要です。
OS更改やパッチ適用時に影響確認が必要です。
エージェント自体が停止すると監視できません。
セキュリティ上、導入や通信許可の調整が必要です。

そのため、エージェント監視を使う場合は、「何を監視したいからエージェントが必要なのか」を明確にします。

一方、エージェント監視のデメリットを見ると、「エージェントを入れずに済む方法はないか」という発想が生まれます。それがエージェントレス監視です。

エージェントレス監視とは何か

エージェントレス監視とは、監視対象サーバーに監視用エージェントを導入せず、監視サーバー側からリモートで状態を確認する方式です。たとえば、サーバに到達できるかを確認するだけなら `ping` で確認できます。

プロセス起動確認とWebサービス応答確認は違う

Webシステムでは、Apacheの `httpd` やTomcatのプロセスが起動していることを確認して、Web/APサーバが正常だと判断してしまうケースがあります。

しかし、プロセスが起動していることと、Webサービスが正常に応答していることは別です。

`httpd` が起動していても、アプリケーションのデプロイに失敗しているかもしれません。Tomcatが起動していても、DB接続でエラーになっているかもしれません。ロードバランサやリバースプロキシの経路が誤っていて、利用者から見ると画面に到達できないこともあります。

そのため、Webサービスの正常性を確認するには、HTTP/HTTPSで対象URLへアクセスし、HTTPステータスコードやレスポンス内容を確認することがあります。

たとえば、監視サーバーから `/healthcheck` や `/login` などのURLへHTTP GETリクエストを送り、HTTPステータスコードが `200` で返るか、レスポンス本文に想定した文字列が含まれるか、応答時間が閾値内かを確認します。

この考え方は、現在でもWebサービスの正常性確認として一般的に使われます。

ただし、最近のシステムでは、確認の粒度を分けることが増えています。

ロードバランサでは、配下のサーバへHTTP/HTTPSのヘルスチェックを行い、正常なターゲットだけにリクエストを振り分けます。

コンテナやKubernetes環境では、コンテナが生きているか、リクエストを受け付けられる状態か、起動完了しているかを分けて確認します。

また、より利用者目線で確認したい場合は、単一URLのGET確認だけでなく、外形監視やSynthetic Monitoringを使い、ログイン、検索、API呼び出しなど、実際の利用者操作に近いシナリオを定期実行することもあります。

つまり、`/healthcheck` や `/login` のHTTP応答確認は今でも有効です。

ただし、それだけで十分かは、システムの特性によります。

重要なのは、`httpd` やTomcatのプロセス起動確認だけで「Webサービスが正常」と判断しないことです。

Webサービスが業務として使えるかを確認するには、少なくともHTTP/HTTPSで実際にアクセスし、期待した応答が返ることを確認する必要があります。

ネットワーク機器やストレージの状態を確認する場合は、SNMPで情報を取得できることもあります。クラウドサービスであれば、APIやクラウド側のメトリクスから状態を取得できる場合もあります。

つまり、監視対象の内部にエージェントを入れなくても、監視サーバー側からリモートで確認できる内容であれば、エージェントレス監視を選択できます。

一方で、OSログの詳細確認、独自スクリプトの実行結果、アプリケーションログの細かな異常検知、サーバ内部の詳細なメトリクス取得などは、エージェントを入れた方が扱いやすい場合があります。

そのため、エージェントレス監視は「エージェントを入れなくて済むから楽」というだけではありません。

監視したい内容が外部から取得できるのか。
取得に必要な認証や権限をどう管理するのか。
通信経路やファイアウォール設定はどうするのか。
取得できる情報の粒度で運用判断できるのか。

ここまで考えたうえで、エージェント監視にするのか、エージェントレス監視にするのかを決めます。

代表的には、次のような方式があります。

• ping
• TCPポート監視
• HTTP/HTTPS監視
• SNMP監視
• SSH経由のコマンド実行
• Windows WMIによる情報取得
• APIによる状態取得
• クラウドサービスのメトリクス取得

エージェントレス監視のメリットは、監視対象サーバーにソフトウェアを導入しなくてもよいことです。

サーバ台数が多い場合、エージェント導入やバージョン管理の負荷を抑えられます。

また、ネットワーク機器、ストレージ、アプライアンス製品、クラウドサービス、マネージドサービスでは、そもそもエージェントを入れられないこともあります。

その場合は、SNMP、API、クラウドメトリクスなどを利用して監視します。

ただし、エージェントレス監視には制約があります。

外側から見える状態は分かるが、OS内部やアプリケーション内部の詳細までは見えないことがあります。
ログファイルの中身までは見にくいことがあります。
独自スクリプトの実行や詳細なメトリクス取得に制約が出ることがあります。
監視サーバーやネットワーク経路に障害があると、監視できないことがあります。

つまり、エージェントレス監視は「エージェントが不要だから簡単」という話ではありません。

エージェントを入れない代わりに、監視サーバー側の接続方式、認証、通信経路、権限、取得できるメトリクスの範囲を設計する必要があります。

SNMP監視とは何か

オンプレミスの監視やネットワーク機器監視でよく出てくるのが、SNMPです。

SNMPは、Simple Network Management Protocolの略です。

ネットワーク機器、サーバ、ストレージ、UPS、アプライアンスなどの状態を監視・管理するために使われるプロトコルです。SNMPの管理情報を扱うMIBについては、RFC 3418でもSNMPエンティティの動作を説明する管理オブジェクトとして定義されています。(IETF Datatracker)

SNMP監視では、一般的に次のような役割があります。

• SNMPマネージャー
• SNMPエージェント
• MIB
• OID
• SNMP Get
• SNMP Trap

SNMPマネージャーは、監視する側です。

SNMPエージェントは、監視される機器側で動作し、機器の状態情報を持っています。

SNMP Getは、マネージャーがエージェントに対して「この情報を教えて」と問い合わせる方式です。

SNMP Trapは、機器側からマネージャーへ「異常が起きた」と通知する方式です。

たとえば、ネットワーク機器でインターフェースがDownした場合、機器側からSNMP Trapが飛ぶことがあります。

監視サーバーはそのTrapを受け取り、アラートとして運用者へ通知します。

SNMP監視でつまずきやすいOIDとMIB

SNMPの説明では、OIDやMIBという言葉が当たり前のように出てきます。

しかし、これを正しく理解していないと、

「MIBファイルを監視製品に読み込ませれば、監視できるんですよね」

という誤解につながります。

これは危険です。

まず、OIDから整理します。

OIDは、Object Identifierの略です。

一言でいえば、監視対象機器の中にあるデータの住所です。

ネットワーク機器やサーバは、人間が話すように「CPU使用率を教えてください」と理解してくれるわけではありません。

SNMPでは、監視マネージャーが、監視対象機器に対して、

「この番号の情報をください」

と問い合わせます。

たとえば、あるネットワーク機器のCPU使用率を表すOIDが、次のような番号だったとします。

1.3.6.1.4.1.9.9.109.1.1.1.1.5

監視マネージャーは、このOIDを指定して、監視対象機器に問い合わせます。

すると、機器側のSNMPエージェントは、

80

のように値を返します。

この場合、人間から見ると「CPU使用率が80%」という意味です。

しかし、機器や監視マネージャーのやり取りとしては、基本的には「どのOIDの値を取るか」という話になります。

つまり、OIDは、監視対象機器の中にある監視項目の住所です。

次にMIBです。

MIBは、Management Information Baseの略です。

一言でいえば、OIDという数字の住所と、人間が理解できる意味を対応づける辞書です。

人間が、毎回、

1.3.6.1.4.1.9.9.109.1.1.1.1.5

という数字を見ても、それが何を意味するのかは分かりません。

そこで、ベンダーが提供するMIBファイルを使います。

MIBには、たとえば次のような対応関係が定義されています。

1.3.6.1.4.1.9.9.109.1.1.1.1.5
=
CPUの5分平均使用率

実際には、製品ごとの正式な項目名や階層構造で定義されていますが、考え方としてはこのようなものです。

つまり、OIDは「住所」です。
MIBは「住所録」または「辞書」です。

OIDが分かれば、監視マネージャーは対象機器から値を取得できます。
MIBがあれば、そのOIDが何を意味するのかを人間が理解しやすくなります。

ここまでは、SNMP監視の基本です。

ただし、実務で本当に重要なのはここからです。

MIBを登録しただけでは監視設計は終わらない

MIBファイルを監視製品に読み込ませると、製品固有のOIDやTrapの意味を解釈できるようになります。

しかし、それだけでは監視設計は終わりません。

MIBは、あくまで辞書です。

辞書を入れただけでは、

• どのOIDを監視するのか
• どの値を警告とするのか
• どの値を異常とするのか
• どのTrapを通知対象にするのか
• どのTrapは通知しないのか
• 何分継続したら異常にするのか
• 誰に通知するのか
• 通知を受けた人が何を確認するのか

は決まりません。

ここを決めるのが監視設計です。

たとえば、CPU使用率のOIDを監視するとします。

CPU使用率が80%になったら、必ず異常でしょうか。

そうとは限りません。

夜間バッチの時間帯だけ一時的にCPUが上がるシステムもあります。
バックアップ処理中だけCPUやI/Oが上がることもあります。
短時間のスパイクであれば、業務影響がない場合もあります。
一方で、CPU使用率が70%程度でも、長時間継続すれば性能劣化の予兆かもしれません。

つまり、単に「CPU使用率のOIDを監視する」だけでは不十分です。

次のように、運用で判断できる条件まで落とす必要があります。

CPU使用率が90%以上
かつ
5分以上継続した場合は警告

CPU使用率が95%以上
かつ
10分以上継続した場合は異常

ただし、夜間バッチ時間帯は別閾値とする

もちろん、これは例です。

実際の閾値は、システムの特性、性能要件、通常時の負荷、ピーク時間帯、バッチ処理、運用体制に応じて決めます。

MIBを入れただけで監視を始めると何が起きるか

よくない進め方は、ベンダーのMIBファイルを監視サーバーに登録し、デフォルト設定に近い形で対象機器の監視を一斉に始めてしまうことです。

この場合、運用開始後にアラートが大量に出ることがあります。

いわゆる、アラートの大洪水です。

なぜそうなるのか。

主な理由は3つあります。

1つ目は、通知すべきイベントと、通知しなくてよいイベントを分けていないことです。

機器や製品は、さまざまなTrapや状態変化を出します。

その中には、本当に即時対応が必要な障害もあります。

一方で、単なる情報通知、状態変化、復旧通知、一時的な警告、運用上は無視してよいメッセージもあります。

これらをすべて同じように通知すると、運用者は大量のアラートを受けることになります。

2つ目は、閾値や継続時間をシステム特性に合わせていないことです。

CPU、メモリ、ディスクI/O、ネットワーク使用率などは、システムによって通常値が違います。

業務ピーク時にCPUが高くなるシステムもあります。
夜間バッチ中にI/Oが急増するシステムもあります。
月次処理の日だけ負荷が上がるシステムもあります。

それを考慮せず、一般的な閾値だけで監視すると、正常な業務処理まで異常として検知してしまいます。

3つ目は、テスト工程で実際のログやアラートを精査していないことです。

監視条件は、設計時点の机上検討だけでは決めきれません。

特に、ログ監視やTrap監視は、実際にシステムを動かしてみないと、どのメッセージがどれくらい出るのか分からないことがあります。

システムテスト、運用テスト、本番リハーサルで、業務データ、日次処理、月次処理、ピーク時のトランザクション、バックアップ、ジョブ、外部連携などを動かして初めて、大量のログやイベントが出てきます。

その中から、

• 本当に通知すべきもの
• 通知は不要だが記録しておくもの
• 除外してよいもの
• 閾値や継続時間を見直すべきもの
• 一次対応手順に落とすべきもの

を精査する必要があります。

これをやらずに本番稼働すると、運用開始後に大量のアラートが出ます。

すると、運用者はアラートを見切れなくなります。

最悪なのは、本当に重要な障害が、不要なアラートの中に埋もれてしまうことです。

監視は、アラートをたくさん出せばよいわけではありません。

運用者が判断できる形で、必要な異常を検知することが重要です。

SNMP監視も詳細設計の対象である

ここまで見ると分かるように、SNMP監視は単にMIBを登録する作業ではありません。

• MIBを登録する
• OIDを選ぶ
• Trapを受ける
• 閾値を決める
• 重大度を決める
• 通知先を決める
• 除外条件を決める
• テスト工程で実際の発報状況を確認する
• 運用手順と対応づける

ここまで含めて、SNMP監視も詳細設計の中で決めるべき重要な領域です。

まとめ｜監視は「異常を検知する設定」ではなく設計である

システム監視では、まず何を正常とし、何を異常として検知するのかを決める必要があります。

本記事では、監視の基本として次の点を整理しました。

• 監視には「監視する側」と「監視される側」がある

• ping が通ることと、システムが業務として正常に使えることは別

• 死活監視、エージェント監視、エージェントレス監視、SNMP監視は目的に応じて使い分ける

• SNMPではMIBを登録するだけでなく、OID、閾値、Trap、除外条件まで設計する

• 監視条件は設計時に決めて終わりではなく、テスト工程で実際の発報を確認して見直す

監視製品を導入し、監視項目を設定すれば監視設計が終わるわけではありません。

重要なのは、

「何を検知するか」
「どの条件で異常と判断するか」
「検知した後に誰がどう動くか」

までつながっていることです。

監視は、アラートを出すための設定ではなく、障害に気づき、判断し、対応につなげるための設計です。

次の記事｜クラウドでは監視設計がどう変わるのか

オンプレミスでは、監視サーバーやエージェント、SNMPなどを使って監視する構成が一般的でした。

一方、AWSやOCIでは、CloudWatchやOCI Monitoringといったクラウドネイティブな監視サービスを利用できます。

ただし、クラウド監視サービスを使えば、監視設計そのものが不要になるわけではありません。

後編では、

• AWS CloudWatch／OCI Monitoringによるクラウド監視

• オンプレミスからクラウド移行するときの監視Fit & Gap

• 監視方式と監視対象の違い

• 閾値、検知条件、重大度、通知先

• 一次対応・エスカレーション・復旧確認

まで踏み込み、実際の運用につながる監視設計を整理しています。

【後編】システム監視の基本｜クラウド監視と「運用で使える監視設計」

CloudWatch等のクラウド監視サービスは部品に過ぎない。既存監視をクラウド移行後どう引き継ぐか、Fit & Gapの整理方法を実務観点で解説します。

sys-univ.com

2026.09.07

関連記事

監視は単独で設計するものではありません。

非機能要件で求める可用性や運用性を整理し、詳細設計で監視条件へ落とし込み、テスト・運用につなげていく必要性については次の記事で説明しています。

• 詳細設計で決めること 後編②｜監視・ログ・バックアップ・セキュリティ・運用スクリプト
  監視対象、閾値、通知、ログ監視条件など、監視を詳細設計としてどこまで具体化するかを整理しています。

【全3回・第3部】監視・ログ・バックアップ・セキュリティの詳細設計｜運用で使える設計にする観点

詳細設計を「構築・テスト・運用できる形」に落とし込む後編②。設計時点では判断しきれない監視条件の見極めなど、現場で見落としやすい監視設計の難しさを整理します。

sys-univ.com

2026.08.20

• 機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う点
  可用性、性能、運用・保守性など、監視設計の前提となる非機能要件について解説しています。

機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う

「機能が動く」と「本番で使える」は違う。機能要件と非機能要件の違いを、購入申請システムの具体例と現場の失敗パターンから整理します。

sys-univ.com

2026.06.19

• 要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
  監視を含む非機能要件を、設計に入る前の要件定義でどこまで決めるのかを整理しています。

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

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

sys-univ.com

2026.08.12

• システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか
  要件定義、設計、構築、テスト、運用まで、監視設計がシステム開発全体のどこに位置するのかを解説しています。

システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか

システム開発は、アプリケーションだけで成立するものではありません。システム基盤、性能・可用性などの非機能、テスト、移行、運用がどのようにつながって一つのシステムを成立させるのかを、現場目線で整理します。

sys-univ.com

2026.08.26

• 【第1部】システム監視の基本｜死活監視・エージェント監視・SNMP監視
  監視の基本構造、死活監視、エージェント監視、SNMP監視、MIB・OIDなどを解説

• 【第2部】この記事
  クラウド監視、既存監視のFit & Gap、運用で使える監視設計を解説

はじめに

前編では、死活監視、エージェント監視、SNMP監視など、システム監視の基本的な仕組みを整理しました。

そこで確認したのは、ping が通ることと、システムが業務として正常に使えることは別だという点です。

サーバへの到達、プロセスの起動、HTTP/HTTPSの応答、業務処理の正常終了では、それぞれ確認しているレベルが異なります。

後編では、この考え方をクラウド環境へ広げます。

AWS CloudWatchやOCI Monitoringを使えば、自前の監視サーバを構築せずに、メトリクス、ログ、アラームを扱える場合があります。

しかし、クラウド監視サービスを使えば、監視設計が不要になるわけではありません。

• 標準メトリクスで足りるのか
• 既存監視をそのまま置き換えられるのか
• どの値を異常とするのか
• 誰に通知するのか
• 通知後に何を確認し、どう対応するのか

こうした点は、クラウドでも設計する必要があります。

特にオンプレミスからクラウドへ移行する場合は、既存監視をそのまま移すのではなく、何を引き継ぎ、何を標準機能で代替し、何を見直すのかというFit & Gapが重要になります。

監視は、アラートを出すための設定ではありません。

障害に気づき、判断し、対応につなげるための設計です。

クラウド監視とは何か

前編で説明した監視構成は、オンプレミスや従来型の監視製品を前提としたものでした。

一方、クラウドでは監視の実現方法が少し変わります。

クラウドでは、クラウドベンダーが用意する監視サービスを使って、仮想サーバ、ストレージ、ロードバランサ、データベース、ネットワーク、サーバレス、コンテナなどのメトリクス、ログ、イベントを収集できます。

そのため、従来のように自前で監視サーバを立てて、すべてのサーバに監視エージェントを導入し、監視製品を運用する、という構成が必ずしも必要ではありません。ただし、ここで誤解してはいけないことがあります。

クラウド監視サービスがあることと、監視設計が不要になることは別です。
クラウド監視サービスは、監視を実現するための部品です。

何を監視するのか。 どの値を異常とするのか。 どの条件で通知するのか。 通知を受けた人が何を確認するのか。 既存システムで行っていた監視を新システムでも継続するのか。

ここは、設計で決める必要があります。

特にオンプレミスからクラウドへ移行する業務システムでは、既存監視の引き継ぎが大きな論点になります。

クラウド監視サービスの代表例

クラウド監視サービスは、クラウドベンダーごとに用意されています。

AWSであれば、CloudWatch。 Azureであれば、Azure Monitor。
Google Cloudであれば、Cloud Monitoring。
OCIであれば、OCI Monitoring。

それぞれ名称や機能の範囲は異なりますが、基本的には、クラウド上のリソースからメトリクス、ログ、イベントを収集し、条件に応じてアラームや通知につなげるためのサービスです。

この記事では、AWSでよく使われるCloudWatchを中心に説明します。

あわせて、Oracle DatabaseやOracle製品を利用している業務システムではOCIが選択肢になることもあるため、OCI Monitoringについても簡単に触れます。

AWS CloudWatchの場合

AWS CloudWatchは、AWS上のリソースを監視するための代表的なサービスです。

EC2、RDS、ELB、EBS、Lambda、ECS、EKSなど、AWS上の多くのサービスはCloudWatchにメトリクスを出力できます。

たとえば、EC2であればCPU使用率、ネットワーク送受信量、ディスクI/Oなどを確認できます。

RDSであれば、CPU使用率、DB接続数、ストレージ容量、読み書きIOPSなどを確認できます。ELBであれば、リクエスト数、ターゲットの正常性、HTTPエラー数、レスポンスタイムなどを確認できます。

CloudWatchでは、こうしたメトリクスに対してアラームを設定できます。

たとえば、CPU使用率が一定時間以上高い状態が続いたら通知する。 RDSの空き容量が少なくなったら通知する。 ELB配下の正常ターゲット数が減ったら通知する。 アプリケーションログに特定のエラーメッセージが出たら通知する。

このように、CloudWatchはAWS上のシステム監視における基本的な部品になります。ただし、CloudWatchを使えばすべてが自動で完璧に監視されるわけではありません。

標準メトリクスで足りるのか。 詳細監視が必要なのか。 CloudWatch Agentを入れてOS内部のメモリやディスク使用率を取得するのか。 アプリケーションログをCloudWatch Logsへ送るのか。 ログのどの文字列を異常として拾うのか。 アラーム閾値をどう設定するのか。 通知先をどうするのか。 通知を受けた人が何を確認するのか。

これらは設計が必要です。

特にオンプレミスからAWSへ移行する場合、既存の監視をCloudWatchだけでそのまま置き換えられるとは限りません。

JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで見ていた監視項目が、CloudWatchの標準メトリクスだけで同じ粒度で取得できるとは限らないからです。

そのため、AWSへ移行する場合でも、CloudWatchで何が見えるかだけではなく、既存監視で何を見ていたのか、新システムでも同じ監視が必要なのか、必要ならCloudWatchで代替できるのか、できない場合は何で補うのかを整理する必要があります。

OCI Monitoringの場合

OCIでも、クラウドネイティブな監視サービスがあります。
代表的なのがOCI Monitoringです。

OCI Monitoringを使うと、OCI上のコンピュート、ストレージ、ロードバランサ、データベース、ネットワーク関連リソースなどのメトリクスを収集し、条件に応じてアラームを設定できます。

OCIのComputeインスタンスでは、プラグインを有効化することで、インスタンスの状態やメトリクスを取得できる構成もあります。
ただし、OCI Monitoringを使えば、Oracle Databaseの性能監視や既存の運用監視がすべて自動で置き換わるわけではありません。

Oracle Databaseを利用している業務システムでは、OCI Monitoringで見るもの、Oracle Database側の機能で見るもの、OEMで見るもの、ログ監視で見るもの、運用手順で確認するものを分けて考える必要があります。

特に、既存システムでOracle Database、Oracle Enterprise Manager、AWR、ASH、Performance Hub、PFM for Oracleなどを利用していた場合、クラウド移行後にどの監視を何で代替するのかを整理する必要があります。

Oracle系システムでは、DB性能、待機イベント、SQL、セッション、表領域、アラートログなど、DB内部の監視観点が重要になることがあります。
そのため、OCI Monitoringだけで考えるのではなく、Oracle Databaseの監視機能や既存運用を含めて、全体として監視設計を行う必要があります。

クラウド移行では、既存監視のFit & Gapが必要

クラウド移行といっても、完全な新規開発ばかりではありません。

実務では、既存のオンプレミスシステムをクラウドへ移すリフト＆シフトや、移行後に段階的にクラウドネイティブ化していくケースが多くあります。

その場合、移行前のシステムで行っていた監視を、移行後にどう引き継ぐかが大きな論点になります。

既存環境では、JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで、OS、ジョブ、ログ、DB性能、表領域、待機イベント、SQL、アラートログなどを監視していたかもしれません。

では、それをクラウド移行後に同じように見られるのでしょうか。答えは、簡単ではありません。

クラウド移行後の監視Fit & Gapでは、少なくとも次の3つに整理して考える必要があります。

1. 既存監視を標準機能で置き換えられるもの

PFM for Oracleや既存監視製品で見ていた内容を、OEM、AWR、ASH、Performance Hub、CloudWatch、Performance Insights、Database Insightsなどで代替できる場合は、新環境の標準機能に寄せる判断があります。

この場合、既存監視をそのまま機械的に移植するのではなく、新環境で標準的に提供されている監視機能を使い、運用をシンプルにできないかを検討します。

2. 標準機能だけでは置き換えられないもの

一方で、既存監視で見ていた項目が、新環境の標準機能では取得できない、または同じ粒度で監視できない場合もあります。

その場合は、代替方式を検討します。

別のメトリクスで代替できるのか。 ログ監視で拾えるのか。 スクリプトで補完できるのか。 外部監視製品やAPMを使うのか。 そもそも新環境でも本当に必要な監視なのか。

ここを整理せずに進めると、オンプレでは見えていた異常が、クラウド移行後に見えなくなることがあります。

3. 代替するか、捨てるか、運用でカバーするもの

標準機能で置き換えられない監視については、最終的に判断が必要です。

手組みしてでも実装するのか。 別製品を追加して実現するのか。 運用手順でカバーするのか。 監視対象から外すのか。

監視を外す場合は、障害検知が遅れる可能性、一次対応への影響、サービスレベルへの影響を説明し、リスク受容として顧客と合意する必要があります。

ここで重要なのは、プロジェクト側だけで勝手に決めないことです。

既存システムで実装されていた監視には、多くの場合、過去の障害、運用上の要請、監査対応、顧客側の不安、サービスレベル上の理由があります。

そのため、単に「新しい製品ではできないのでやりません」とは言いにくいことがあります。

技術的には実現できない。 実現はできるがコストが高すぎる。 手組みすれば可能だが保守性が悪い。 運用カバーで十分と判断できる。 リスクを受容して監視対象から外す。

こうした判断を、要件、コスト、運用負荷、障害時の影響、顧客の期待値を踏まえて整理します。

クラウド移行時の監視設計で重要なのは、既存監視を機械的に移植することではありません。

業務システムとして必要な異常検知、性能把握、一次対応、エスカレーションが、新システムでも成立するかを確認することです。

そのうえで、できること、できないこと、代替すること、やめることを顧客と合意する。ここまで含めて、新システムの監視設計です。

監視対象・目的で見た監視の種類

ここで重要なポイントは、「監視方式」と「監視対象・監視目的」を混同しないことです。

この中で、若手SEが特に理解しておくべきなのは、死活監視だけでは業務正常性は分からないという点です。

サーバに ping が通っていても、Web画面がエラーになっているかもしれません。 Web画面が開いても、検索処理が失敗するかもしれません。 DBプロセスが起動していても、表領域が枯渇して更新できないかもしれません。 バックアップジョブが正常終了していても、リストアできないかもしれません。

だからこそ、監視設計では「何をもって正常と判断するのか」を決める必要があります。

監視方式は「何を知りたいか」から選ぶ

監視方式を選ぶときに大事なのは、製品や流行から入らないことです。

まず決めるべきなのは、「何を知りたいのか」です。

• サーバが起動しているかを知りたいなら、死活監視です。
• Webサービスが応答しているかを知りたいなら、URL監視です。
• OS内部のCPUやメモリを知りたいなら、リソース監視です。
• DBプロセスが動いているかを知りたいなら、プロセス監視です。
• DBとしてログインできるかを知りたいなら、DB接続監視です。
• ログに異常メッセージが出ていないか知りたいなら、ログ監視です。
• ストレージやネットワーク機器の状態を知りたいなら、SNMP監視や製品API監視です。
• クラウドリソースの状態を知りたいなら、CloudWatchやOCI Monitoringなどのクラウド監視サービスです。

監視方式は、目的によって変わります。

逆に言えば、監視方式だけを決めても意味がありません。

「SNMPで監視します」では不十分です。

• SNMPで何を監視するのか。
• どのOIDを見るのか。
• どのTrapを受けるのか。
• 重大度をどう判定するのか。
• 通知先はどこか。
• 一次対応手順は何か。

ここまで決めて初めて、監視設計になります。

監視設計で決めること

監視設計では、最低限、次のような項目を決めます。

• 監視対象
• 監視項目
• 監視方式
• 監視間隔
• 閾値
• 検知条件
• 除外条件
• 重大度
• 通知先
• 通知方法
• 監視抑止条件
• メンテナンス時の扱い
• 一次対応手順
• エスカレーション先
• 復旧確認方法
• 監視設定の変更手順
• 監視条件の見直しタイミング

たとえば、CPU使用率の監視でも、単に「CPUを監視する」では足りません。

• CPU使用率が何％を超えたら警告なのか。
• 何分継続したら異常なのか。
• 瞬間的なスパイクは除外するのか。
• 夜間バッチ中は閾値を変えるのか。
• 警告と異常で通知先を分けるのか。
• 通知を受けたら、運用者は何を見るのか。
• AP担当、DB担当、基盤担当のどこへ連絡するのか。

ここまで決める必要があります。

監視は、アラートを出すことが目的ではありません。

アラートを受けた人が判断できることが目的です。

監視でよくある誤解

監視でよくある誤解は、次の3つです。

そのため、監視設計は、設計時点で決めて終わりではありません。
システムテスト、運用テスト、本番リハーサル、本番稼働後の初期期間を通じて、見直す前提が必要です。

システム基盤エンジニアが持つべき監視の見方

まず持ってほしいのは、「監視は設定項目ではなく、運用の入口である」という見方です。

監視アラートは、障害対応のスタート地点です。

アラートが出た瞬間に、運用者は判断を求められます。

• これは本当に障害なのか。
• 無視してよい通知なのか。
• すぐにエスカレーションすべきなのか。
• まず手順書に沿って確認すべきなのか。
• 復旧したと言える条件は何か。

この判断ができるように設計するのが、監視設計です。

• 監視サーバがある。
• エージェントが入っている。
• CloudWatchにメトリクスが出ている。
• OCI Monitoringにアラームがある。 MIBを読み込ませた。

それだけでは、監視設計としては不十分です。
重要なのは、検知した後に運用が動けることです。

まとめ｜クラウドでも、監視の本質は変わらない

クラウド監視サービスを使えば、メトリクス、ログ、アラームを扱いやすくなります。

しかし、CloudWatchやOCI Monitoringを使えば、監視設計そのものが不要になるわけではありません。

特にオンプレミスからクラウドへ移行する場合は、既存監視をそのまま移植するのではなく、

• 標準機能で置き換えられるもの
• 標準機能だけでは置き換えられないもの
• 代替するもの、運用でカバーするもの、監視対象から外すもの

に分けて、Fit & Gapを整理する必要があります。そのうえで、

• 何を監視するのか。
• どの条件で異常と判断するのか。
• 誰に通知するのか。
• 通知後に誰が何を確認し、どう対応するのか。

まで設計して初めて、監視は運用で使える仕組みになります。

監視で重要なのは、たくさんのアラートを出すことではありません。

本当に検知すべき異常を、運用で判断・対応できる形で検知することです。

監視は、アラートを出すための設定ではなく、障害に気づき、判断し、対応につなげるための設計です。

前編では、監視する側・監視される側という基本構造から、死活監視、エージェント監視、エージェントレス監視、SNMP監視、MIB・OIDまで、システム監視の基礎を整理しています。

【前編】システム監視の基本｜ping・エージェント・SNMP監視を整理する

pingが通ることとシステムが業務で使えることは別物。死活監視・エージェント監視・SNMP監視の基本構造と、監視設計で見落としやすい落とし穴を整理します。

sys-univ.com

2026.09.09

関連記事

監視設計は、単独で完結するものではありません。

非機能要件で求める可用性や運用性を整理し、詳細設計で監視条件へ落とし込み、テスト・運用につなげていく必要性については次の記事で説明しています。

• 【全3回・第3部】監視・ログ・バックアップ・セキュリティの詳細設計｜運用で使える設計にする観点
  監視対象、閾値、通知、ログ監視条件、運用スクリプトなど、監視を詳細設計でどう具体化するかを整理しています

【全3回・第3部】監視・ログ・バックアップ・セキュリティの詳細設計｜運用で使える設計にする観点

詳細設計を「構築・テスト・運用できる形」に落とし込む後編②。設計時点では判断しきれない監視条件の見極めなど、現場で見落としやすい監視設計の難しさを整理します。

sys-univ.com

2026.08.20

• 機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う点
  可用性、性能、運用・保守性など、監視設計の前提となる非機能要件を整理しています。

機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う

「機能が動く」と「本番で使える」は違う。機能要件と非機能要件の違いを、購入申請システムの具体例と現場の失敗パターンから整理します。

sys-univ.com

2026.06.19

• 要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
  監視を含む非機能要件を、設計に入る前の要件定義でどこまで具体化するのかを解説しています。

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

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

sys-univ.com

2026.08.12

• システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか
  要件定義、設計、構築、テスト、運用まで、監視設計がシステム開発全体のどこに位置するのかを整理しています。

システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか

システム開発は、アプリケーションだけで成立するものではありません。システム基盤、性能・可用性などの非機能、テスト、移行、運用がどのようにつながって一つのシステムを成立させるのかを、現場目線で整理します。

sys-univ.com

2026.08.26

AWS上の通信はNitro Systemによって暗号化される。

そう聞くと、「ではVPC Encryption Controlsは何をする機能なのか」と疑問に思うかもしれません。

VPC Encryption Controlsは、新しい暗号アルゴリズムではありません。VPC内やVPC間の通信について、暗号化状態を監視し、暗号化を保証できないリソースを特定し、Enforceでは暗号化されない構成を制限するための仕組みです。

ただし、Monitorで「暗号化」と表示された通信がEnforceでも必ず許可されるわけではありません。Flow Logsのapplication-encryptedも、AWSが任意のTLS通信をパケット解析して確認した結果ではありません。

この記事では、VPC Encryption Controlsを「何ができるか」だけでなく、暗号化状態をどう読み、Enforceへ移行できる構成かをどう判断するかという観点から整理します。

VPCの通信はもともとNitroで暗号化されているのではないか

AWSでは以前から、一部のNitroベースEC2インスタンス間で、条件を満たす通信をハードウェアレイヤーで透過的に暗号化できます。

ただし、暗号化にはインスタンスタイプや通信経路などの条件があります。

「条件を満たせば暗号化される」と「暗号化されない構成を許さない」は別です。

VPC Encryption Controlsは、Nitroによるハードウェア暗号化とアプリケーションレイヤーの暗号化を組み合わせ、VPC単位で暗号化状態を監視・強制します。

さらに、Nitroのハードウェア暗号化をFargate、Application Load Balancer、Transit Gatewayなど、EC2以外のAWSサービスへ広げる役割も持っています。

AWS公式：VPC Encryption Controls

つまり、単なる監視機能ではありません。

AWS基盤側の暗号化範囲を広げながら、その状態をVPC単位で統制する仕組みです。

VPC Encryption Controlsとは｜MonitorとEnforceで何が変わるのか

VPC Encryption ControlsにはMonitorとEnforceがあります。

既存VPCは、まずMonitorを有効にします。

非準拠リソースを是正するか、必要なExclusionを設定した後でEnforceへ移行します。新規VPCは作成時からEnforceを指定できます。

Enforceは既存通信を後から暗号化するスイッチではない

Enforceを有効にしても、既存リソースの通信へ後から暗号化処理を追加するわけではありません。

例えばRDSでは、Enforce VPCへ転送中暗号化に対応しないDBインスタンスを新規作成しようとすると、APIリクエストがブロックされます。既存ワークロードは動作を継続します。

AWS公式：Working with a DB instance in a VPC

ただしPrivateLinkは注意が必要です。

Enforce VPC内のPrivateLink Endpointでは、アプリケーションレイヤーで暗号化されていないトラフィックが破棄されます。

そのため、「Enforceは新規作成だけを止める」と一律には考えられません。

VPC Flow Logsで暗号化状態を見る｜encryption-statusの3つの落とし穴

VPC Flow Logsではencryption-statusで通信の暗号化状態を確認できます。

なお、一部のネットワークアプライアンスでは暗号化状態を報告できず、encryption-statusが-になる場合があります。

-を即座に平文と判断しないことも重要です。

落とし穴1｜application-encryptedは任意のTLS検査ではない

AWSがapplication-encryptedとして扱う通信は限定されています。

これは、AWSが通信内容を復号してペイロードを検査しているという意味ではありません。Interface EndpointやGateway Endpointでは、AWSはpacket dataを確認せず、使用しているポートから暗号化状態を推定しています。

したがって、

encryption-status=2だから、任意のアプリケーション通信についてTLSを実証した

とは言えません。

逆にOracle NNEなどで暗号化していても、Flow Logs上でapplication-encryptedと判定されるとは限りません。

アプリケーション／DBレイヤーの暗号化は、そのレイヤーの方法で別途確認する必要があります。

落とし穴2｜既存Flow Logsにはencryption-statusが追加されない

Encryption Controlsを有効にしても、encryption-statusは既存Flow Logsへ自動追加されません。

さらにFlow Logは、作成後にrecord formatのフィールドを追加・削除できません。

既存環境でencryption-statusを取得するには、このフィールドを含む新しいFlow Logを作成します。

AWS公式：Flow Logsの制約

すでにSIEMや監査基盤へ連携している場合は、新ログの保存先や切替・並走も運用設計に含めます。

落とし穴3｜MonitorのencryptedとEnforceの準拠判定は同じではない

ここが最も重要です。

Monitorでencryptedでも、Enforceでは非準拠になる場合があります。

一つは、AWSサービスが作成したENIを含む通信です。

フロー自体が暗号化されていても、そのAWSサービスがEncryption Controlsをサポートしている必要があります。

もう一つはVPC Peeringです。

Peeringで転送中暗号化を保証するには、同一リージョンの両VPCがExclusionなしのEnforceである必要があります。

逆にMonitorでnot encryptedでも、関連リソースをExclusionにしていればEnforceでは許容される場合があります。

つまり、

Flow Logsのencryption-statusは「そのフローをどう観測したか」
Enforceは「その構成をポリシー上許容できるか」

を見ています。

同じ判定ではありません。

Transit GatewayはEncryption Supportを別途有効化する

Transit Gatewayを利用している場合は、Encryption Supportを明示的に有効化します。

有効化は既存通信を停止せずに行われますが、enablingからenabledになるまで最大14日かかる場合があります。

また、Connect、Peering、Network Firewall、Client VPNなど、Encryption Supportと併用できないAttachmentや機能があります。

AWS公式：Transit Gateway Encryption Support

Encryption Supportを有効化したTGWで、両側のVPCがExclusionなしのEnforceなら、VPC間通信は暗号化された経路を通ります。

一方、

Enforce VPC → Transit Gateway → Monitor VPC

という構成では、暗号化が保証されるのはMonitor側のTGW Attachmentまでです。

その先は宛先リソースに依存します。

図：Enforce VPCからMonitor VPCへTransit Gateway経由で通信する場合の暗号化保証範囲

つまり、TGWを暗号化しただけで相手VPC内部まで暗号化が保証されるわけではありません。

RDSでVPC Encryption Controlsを使うときの注意点

RDSもVPC Encryption Controlsに対応しています。

AWSサービスによって、Enforceへの対応方法は異なります。

NLB、ALB、Fargate、EKS Control Planeは、Monitorを有効にするとAWS側で暗号化対応ハードウェアへ自動移行します。

一方、RDSは必要に応じて利用者がインスタンスクラスを見直すmanual migration側です。

すでに対応クラスなら変更不要ですが、古い非対応クラスではNitro native encryptionに対応したクラスへの変更が必要です。

また、VPCがEnforceでも、Oracle NetがNNEやSSL/TLSで暗号化されていることを意味しません。

RDS for Oracleでは、

• KMSによるRDSストレージ暗号化
• Oracle TDE
• Oracle NetのNNE／SSL/TLS
• AWS基盤側の通信暗号化

は別レイヤーです。

この違いは、以下の記事で整理しています。

RDS for OracleのDBリンクは暗号化されているのか｜KMS暗号化とOracle Net通信は別物

KMSで暗号化したRDS for Oracleと非暗号化RDSを別AWSアカウント間でDBリンク接続した場合の挙動を、AWSサポートへの問い合わせと公式仕様をもとに整理。KMS暗号化はDBリンク通信へ伝播せず、NNEまたはSSL/TLSを別途設計します。

sys-univ.com

2026.08.25

導入するならMonitorから始める｜Exclusion・Enforce移行・料金

既存VPCでは、次の順序で進めると整理しやすくなります。

1. Monitorを有効にする
2. encryption-statusを含むFlow Logsを作る
3. Enforceを阻害するリソースを確認する
4. 対応構成へ移行する
5. 必要なExclusionを判断する
6. PeeringやTGWも確認する
7. Enforceへ移行する

EnforceできるかはExclusionと非対応リソースで決まる

Exclusionを設定できるのは8種類だけです。

• Internet Gateway
• NAT Gateway
• Egress-only Internet Gateway
• 非Enforce VPCへのVPC Peering
• Virtual Private Gateway
• VPC内Lambda
• VPC Lattice
• EFS

Exclusionは、「AWSが暗号化済みと保証する」設定ではありません。

利用者がエンドツーエンド暗号化を維持する責任を負う、監査可能な例外です。

Exclusionを設定した通信はVPC Encryption Controlsによる暗号化保証の対象外となるため、AWSの責任共有モデルで見ても、利用者側で暗号化方式と証跡を明示的に管理する必要があります。

一方、Gateway Load BalancerとAWS Network FirewallはEnforce非対応で、これらがあるVPCはMonitorで運用する必要があります。

Local Zone subnetもEnforceでは利用できません。

したがってMonitorの目的は、平文通信を探すだけではありません。

「このVPCをそもそもEnforceへ移行できるのか」

を判断することです。

複数VPC・複数アカウントでは集中管理もできる

Account LevelではUnmanaged、Attempt Monitor、Attempt Enforceを設定でき、複数VPCへまとめて適用できます。

ただしAttempt Enforceは全VPCの移行成功を保証しません。

1つ以上のVPCが期待したモードへ移れなかった状態として、transitions-partially-successfulも定義されています。

AWS公式：AccountVpcEncryptionControl

AWS OrganizationsのDeclarative Policyを使えば、組織・OU・アカウント単位で集中適用することもできます。

Monitorでも料金は発生する

VPC Encryption Controlsは2026年3月1日から有料です。

Network Interfaceを持つnon-empty VPCでMonitorまたはEnforceを有効にすると、固定時間料金が発生します。

TGWでEncryption Supportを有効にした場合は、接続VPCのEncryption Controlsモードに関係なく料金対象になる場合があります。

具体的な単価はリージョンごとの最新料金を確認します。

AWS公式：VPC Encryption Controls pricing

Monitorのまま長期間放置する場合も、コスト設計上は無視できません。

まとめ｜「暗号化されることを期待する」から「暗号化されない構成を許さない」へ

VPC Encryption Controlsで押さえる点は3つです。

• Nitroの自動暗号化とEncryption Controlsによる統制は同じものではない
• Flow Logsのencryption-statusとEnforceの準拠判定は同じではない
• EnforceしてもTLSやOracle NNEなどアプリケーション／DBレイヤーの暗号化設計は別途必要

VPC Encryption Controlsによって、AWSの通信暗号化設計は、

「条件を満たせば暗号化されることを期待する」

から、

「暗号化を保証できない構成を許さない」

へ一段進みました。

導入時はまずMonitorで現在の構成と通信を可視化し、何をAWS基盤側で保証し、何をアプリケーション側で保証するのかを整理したうえでEnforceへ進むのがよいでしょう。

関連記事

VPC Encryption Controlsでは、AWS基盤側の通信暗号化をMonitor／Enforceで監視・強制できますが、実際の通信ではサービスごとの転送時暗号化もあわせて理解しておく必要があります。

特にEFSはVPC Encryption ControlsでExclusionを設定できるリソースの一つであり、ECS／FargateからEFSへ接続する場合は、NFS通信の転送時暗号化がどのように実現されるかを分けて考える必要があります。あわせて確認したい方は、以下の記事も参考にしてください。

• ECS/FargateでEFSが127.0.0.1にマウントされる｜NFSの接続先がlocalhostになる理由
  ECS／FargateでEFSの転送時暗号化を有効にすると、NFSの接続先が127.0.0.1として見える理由を、TLSトンネルとEFSマウント処理の仕組みから整理しています。

ECS/FargateでEFSが127.0.0.1にマウントされる｜NFSの接続先がlocalhostになる理由

ECS/FargateからEFSをマウントするとマウント元が127.0.0.1と表示される理由を、転送時暗号化で使われるefs-proxyの通信経路、タスク定義のtransitEncryptionとIAM認可の関係、mount.logで確認できた内容、障害調査時の切り分け観点から解説します。

sys-univ.com

2026.08.14

RDS for Oracleでは、オンプレミスOracleと同じ方法でSYS.X$BHを直接参照できません。

対応する環境では、X$BHを基にしたSYS.RDS_X$BHビューを作成できます。ただし、X$固定表はOracle内部の非公開オブジェクトであり、本番環境で利用する場合は、非本番環境での検証やエンジンアップグレード後の確認が必要です。

一方、調査の目的が、

DBバッファキャッシュ上に、どのテーブルやインデックスのブロックがどの程度存在しているか確認する

ことであれば、Oracleが公開している動的パフォーマンスビューV$BHを利用できます。

V$BHはX$BHの完全な代替ではありません。LRU_FLAGやTCHなど、V$BHでは取得できない情報もあります。

しかし、オブジェクトごとのキャッシュブロック数や概算容量を把握する目的であれば、V$BHから必要な情報を取得できます。

本記事では、RDS for OracleでV$BHを使用してDBバッファキャッシュの内訳を調査するSQLと、結果を評価する際の注意点を解説します。

SYS.X$BHを直接参照できない理由と、SYS.RDS_X$BHを利用する際の条件については、以下の記事で整理しています。

【RDS for Oracle】オンプレの調査SQLが動かない｜X$BHを直接参照できない理由

RDS for OracleでSYS.X$BHを直接参照できない理由を解説。SYSDBA権限の制約、RDS_X$BHの作成方法、V$BHとの使い分けや運用上の注意点を整理します。

sys-univ.com

2026.07.13

V$BHで確認できる情報

V$BHは、SGA内に存在する各バッファの状態を表示する動的パフォーマンスビューです。

Oracle公式リファレンスでは、バッファの状態、データファイル番号、ブロック番号、データオブジェクト番号、表領域番号などを確認できるビューとして説明されています。

V$BHの列定義｜Oracle Databaseリファレンス

オブジェクト別のキャッシュ量を調査する際、主に利用する列は次のとおりです。

このうち、オブジェクトとの結合で中心になるのがOBJDです。

V$BH.OBJDをDBA_OBJECTS.DATA_OBJECT_IDと結合することで、バッファキャッシュ上のブロックが、どのテーブル、インデックス、パーティションに属しているかを確認できます。

OBJECT_IDではなくDATA_OBJECT_IDで結合する

V$BHとDBA_OBJECTSを結合する際、注意したいのが結合列です。

次のように、OBJECT_IDと結合したくなるかもしれません。

ON o.object_id = bh.objd

しかし、ここではOBJECT_IDではなく、DATA_OBJECT_IDを使用します。

ON o.data_object_id = bh.objd

OBJECT_IDは、データディクショナリ上でオブジェクトを識別する番号です。

一方、DATA_OBJECT_IDは、そのオブジェクトのデータを格納するセグメントに対応する番号です。

V$BH.OBJDが保持しているのは、バッファ内のブロックに対応するデータオブジェクト番号です。そのため、DBA_OBJECTS.DATA_OBJECT_IDと結合します。

Oracle公式のバッファキャッシュ調査SQLでも、次の条件が使われています。

o.data_object_id = bh.objd

この違いは、パーティション表や、TRUNCATE、MOVEなどによってセグメントが再作成されたオブジェクトを扱う場合に重要です。

オブジェクトの論理的な識別子であるOBJECT_IDが変わらなくても、物理的なセグメントに対応するDATA_OBJECT_IDが変化する場合があります。

バッファキャッシュ上のブロックを、実際のセグメントへ正しく関連付けるには、DATA_OBJECT_IDを使用する必要があります。

Oracle公式の基本SQL

OracleのPerformance Tuning Guideでは、バッファキャッシュ上に存在するオブジェクト別のブロック数を、次のようなSQLで確認しています。

SELECT
    o.object_name,
    COUNT(*) AS number_of_blocks
FROM
    dba_objects o,
    v$bh bh
WHERE
    o.data_object_id = bh.objd
    AND o.owner <> 'SYS'
GROUP BY
    o.object_name
ORDER BY
    COUNT(*);

このSQLは、V$BH.OBJDとDBA_OBJECTS.DATA_OBJECT_IDを結合し、オブジェクトごとのブロック数を集計するものです。

基本SQLと、バッファキャッシュの利用状況を調査する手順は、Oracle公式のチューニングガイドで確認できます。

Tuning the Database Buffer Cache｜Oracle Database Performance Tuning Guide

基本的な目的は、このSQLで達成できます。

ただし、実務で結果を確認する場合は、次の情報も表示したほうが分かりやすくなります。

• オブジェクトの所有者

• パーティション名

• オブジェクト種別

• 表領域名

• ブロックサイズ

• キャッシュ容量の概算値

これらを追加したSQLが次の例です。

オブジェクト別のキャッシュ容量を確認するSQL

SELECT
    o.owner,
    o.object_name,
    o.subobject_name,
    o.object_type,
    t.name AS tablespace_name,
    COUNT(*) AS cached_blocks,
    d.block_size,
    ROUND(
        COUNT(*) * d.block_size / 1024 / 1024,
        2
    ) AS cached_mb
FROM
    v$bh bh
    LEFT JOIN dba_objects o
        ON o.data_object_id = bh.objd
    LEFT JOIN v$tablespace t
        ON t.ts# = bh.ts#
    LEFT JOIN dba_tablespaces d
        ON d.tablespace_name = t.name
WHERE
    bh.status <> 'free'
GROUP BY
    o.owner,
    o.object_name,
    o.subobject_name,
    o.object_type,
    t.name,
    d.block_size
ORDER BY
    cached_mb DESC;

このSQLでは、V$BH上の使用中バッファを、データオブジェクトと表領域へ関連付けています。

結果は、概ね次のような形式になります。

この結果から、どのオブジェクトのブロックがバッファキャッシュ上で大きな割合を占めているかを確認できます。

SQLの各項目

OWNER

オブジェクトの所有者です。

異なるスキーマに同じオブジェクト名が存在する場合があるため、OBJECT_NAMEだけではなく、OWNERも表示します。

OBJECT_NAME

テーブルやインデックスなどのオブジェクト名です。

パーティション表やパーティションインデックスでは、同じOBJECT_NAMEに対して複数のセグメントが存在します。

SUBOBJECT_NAME

パーティション名またはサブパーティション名です。

これを表示しないと、どのパーティションのブロックがキャッシュされているか分からなくなります。

OBJECT_TYPE

オブジェクトの種類です。

主に次のような値が表示されます。

• TABLE

• INDEX

• TABLE PARTITION

• INDEX PARTITION

• TABLE SUBPARTITION

• INDEX SUBPARTITION

TABLESPACE_NAME

オブジェクトのブロックが属している表領域名です。

V$BH.TS#とV$TABLESPACE.TS#を結合して取得します。

CACHED_BLOCKS

バッファキャッシュ上に存在するブロック数です。

V$BHは基本的にバッファ単位で行を返すため、COUNT(*)によってオブジェクトごとのブロック数を集計します。

BLOCK_SIZE

表領域のブロックサイズです。

通常はデータベース標準のブロックサイズが使われますが、非標準ブロックサイズの表領域が存在する可能性もあります。

そのため、固定値として8192を掛けるのではなく、DBA_TABLESPACES.BLOCK_SIZEを使用します。

CACHED_MB

キャッシュされている概算容量です。

計算式は次のとおりです。

キャッシュブロック数 × ブロックサイズ

SQLでは、この値を1024で2回割り、MiB相当へ換算しています。

ただし、この値はオブジェクトの物理サイズではありません。

SQLを実行した時点で、バッファキャッシュ上に存在するブロック数を容量換算した値です。

LEFT JOINを使用する理由

V$BHとDBA_OBJECTS、表領域関連ビューの結合にはLEFT JOINを使用しています。

INNER JOINを使用すると、対応するオブジェクトや表領域情報を取得できなかったバッファが、結果から除外されます。

通常のユーザーテーブルやインデックスだけを確認する場合は、INNER JOINでも大部分の結果を取得できます。

しかし、バッファキャッシュには次のようなブロックが含まれる可能性があります。

• 一時セグメント

• Undo関連ブロック

• 内部管理用ブロック

• オブジェクトへ単純に関連付けられないバッファ

• 取得タイミングによってディクショナリと一致しない情報

そのため、まずはV$BH側の行を残し、オブジェクトや表領域へ関連付けられなかった行も確認できるようにしています。

OWNER、OBJECT_NAME、TABLESPACE_NAMEなどがNULLになった行が多い場合は、不要と判断して除外するのではなく、FILE#、BLOCK#、TS#、STATUSなどを追加して内容を確認します。

ユーザーオブジェクトだけを簡潔に確認したい場合は、INNER JOINへ変更しても構いません。

STATUSがfreeのバッファを除外する

今回のSQLでは、次の条件を指定しています。

WHERE bh.status <> 'free'

V$BH.STATUSには、バッファの状態が表示されます。

代表的な値は次のとおりです。

今回の目的は、現在キャッシュ上で使用されているブロックの集計です。そのため、未使用状態のfreeを除外しています。

障害解析やRAC関連の調査など、状態ごとの内訳が必要な場合は、STATUSをSELECT句とGROUP BY句へ追加して確認します。

キャッシュ量が多いオブジェクトは問題なのか

V$BHの結果を見ると、特定のテーブルやインデックスが大量のブロックを占めていることがあります。

しかし、

キャッシュ量が多い
＝不要なデータがキャッシュされている
＝チューニングが必要

とは限りません。

業務で継続的に参照されるテーブルであれば、多くのブロックがキャッシュされていることは自然です。

必要なブロックがバッファキャッシュに残っていれば、その後のSQLはストレージからの物理読み込みを減らせます。

問題になる可能性があるのは、例えば次のようなケースです。

• 利用頻度の低い大規模表が大量に読み込まれている

• 大規模バッチの後にオンライン処理の物理読み込みが増える

• フルスキャンが繰り返されている

• 想定していたインデックスが使用されていない

• 同じ大規模オブジェクトへ不要なアクセスが繰り返されている

• 必要なブロックが短時間でキャッシュから追い出されている

したがって、V$BHの結果だけで良否を判断してはいけません。

V$BHと一緒に確認する情報

SQLと実行計画

キャッシュ上で大きな割合を占めるオブジェクトを特定したら、そのオブジェクトへアクセスしているSQLを確認します。

• フルテーブルスキャンになっていないか

• パーティションプルーニングが機能しているか

• 想定以上の行やブロックを読み込んでいないか

• 同じ処理を不必要に繰り返していないか

キャッシュ量が多いという結果だけで、SQLに問題があるとは判断できません。実行計画と実行統計を組み合わせて評価します。

物理読み込みと待機イベント

AWRやStatspack、V$SYSSTATなどから、処理量に対して物理読み込みが増えていないかを確認します。

また、次のようなI/Oやバッファ関連の待機イベントも確認します。

• db file sequential read

• db file scattered read

• direct path read

• free buffer waits

• buffer busy waits

• read by other session

ただし、待機イベントが発生しているだけで、バッファキャッシュを増やすべきとは判断できません。

SQL、ストレージ性能、DBWRの書き出し、同時実行数など、複数の要因を確認する必要があります。

V$DB_CACHE_ADVICE

バッファキャッシュのサイズを変更した場合に、物理読み込みがどの程度変化すると推定されるかを確認するには、V$DB_CACHE_ADVICEを利用できます。

Oracle公式ドキュメントでは、複数の仮想的なキャッシュサイズに対する物理読み込み数やミス率の予測値を表示するビューとして説明されています。

ただし、これは実測値ではなく予測値です。

代表的な業務負荷が流れている状態で取得し、AWRや実際のレスポンスタイムと合わせて評価します。

V$BHの検索負荷に注意する

V$BHは、バッファキャッシュ内の各バッファに対応する行を保持しています。

バッファキャッシュが大きい環境では、V$BHの行数も多くなります。

そこへDBA_OBJECTSや表領域関連ビューを結合し、全件をGROUP BYすると、SQL自体がCPUやソート領域を使用します。

Oracle公式ドキュメントでも、全セグメントを対象にした集計は、バッファキャッシュのサイズによって多くのソート領域を必要とする場合があると説明されています。

本番環境で実行する場合は、次の点に注意します。

• 非本番環境で実行時間と負荷を確認する

• 業務ピークを避ける

• 必要に応じて対象スキーマを絞る

• 定期監視として短い間隔で実行しない

• 実行計画とTEMP使用量を確認する

参照SQLだから安全とは限りません。

データを更新しないSELECTであっても、大量の行を走査して集計するSQLは、データベースへ負荷を与えます。

非マスターユーザーから参照する場合

非マスターユーザーへV$BHの参照権限を付与する場合は、RDSの管理プロシージャgrant_sys_objectを使用します。

権限付与時には、シノニム名のV$BHではなく、基になるSYSオブジェクト名V_$BHを指定します。

BEGIN
    rdsadmin.rdsadmin_util.grant_sys_object(
        p_obj_name  => 'V_$BH',
        p_grantee   => 'MONITOR_USER',
        p_privilege => 'SELECT'
    );
END;
/

ただし、付与できるのは、マスターユーザー自身が保持している権限の範囲内です。

実行前に、対象環境でマスターユーザーからV$BHを参照できることを確認してください。

また、監視ユーザーへ権限を付与する場合は、必要なビューだけに限定し、広いカタログ参照権限を安易に付与しないほうが安全です。

X$BHとV$BHの違い

V$BHでオブジェクトごとのキャッシュ量を確認できますが、X$BHのすべての情報を取得できるわけではありません。

オブジェクト別のキャッシュブロック数や概算容量を確認したいのであれば、まずV$BHを検討できます。

一方、LRU_FLAGやTCHなどX$BH固有の情報が必要な場合や、Oracle Supportから固定表を使った調査を指示された場合は、対応環境でRDS_X$BHを作成する選択肢があります。

V$BHは調査の入口

V$BHが示すのは、SQLを実行した時点でバッファキャッシュ上に存在するブロックの状態です。直前に大規模バッチが実行されていれば、その処理で読み込まれたブロックが多く表示される可能性があります。

頻繁に利用されるオブジェクトであっても、DBインスタンスの再起動直後や業務開始前であれば、キャッシュブロック数は少なく表示されます。結果を評価する際は、まず取得タイミングを確認します。

• 代表的な業務負荷が実行されている時間帯か

• バッチ実行前か実行後か

• DBインスタンス再起動から十分な時間が経過しているか

必要に応じて複数の時間帯で結果を取得し、業務処理の実行状況やSQL統計、物理読み込み、待機イベントと対応付けて評価します。利用可能な機能やライセンス条件に応じて、AWR、Statspack、CloudWatch Database Insightsなども組み合わせます。

特定のオブジェクトが大量のバッファを使用しているという結果だけでは、キャッシュサイズの変更やSQLチューニングが必要とは判断できません。

調査では、既存SQLをそのまま再現することよりも、そのSQLで何を確認しようとしていたのかを整理することが重要です。オンプレミスで使用していたSYS.X$BHをRDS for Oracleから直接参照できない場合でも、目的がオブジェクト別のキャッシュブロック数を確認することであれば、公開された動的パフォーマンスビューであるV$BHを利用できます。

LRU_FLAGやTCHなど、X$BH固有の情報が必要な場合は、使用しているエンジンリリースと作成可能なビューを確認したうえで、SYS.RDS_X$BHの利用を検討します。X$表はOracle内部のシステムオブジェクトであるため、非本番環境で検証し、本番環境への導入はOracle Supportのガイダンスを踏まえて判断します。

V$BHは、性能問題の全体を説明するビューではありません。どのオブジェクトのブロックがバッファキャッシュ上に存在しているかを確認し、その後のSQL、実行計画、I/O、待機イベントの調査につなげる入口として位置づけます。

今回取り上げたX$BHの制約は、RDS for Oracleで変わる運用前提の一例です。SYSDBA権限、OSアクセス、物理ファイル操作、ログ取得、ストレージ管理についても、オンプレミスと同じ手順をそのまま使用できるとは限りません。

オンプレミスの操作を一対一で置き換えるのではなく、調査や運用の目的を整理し、RDSで提供される機能を使って手順を再構成する必要があります。

RDS for Oracleで変わる設計・運用上の前提と代替アプローチについては、以下の記事で整理しています。

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

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

sys-univ.com

2026.08.30

まとめ

RDS for Oracleで、DBバッファキャッシュ上のオブジェクト別ブロック数を確認する場合は、V$BHを利用できます。

V$BH.OBJDは、DBA_OBJECTS.OBJECT_IDではなく、DATA_OBJECT_IDと結合します。

ON o.data_object_id = bh.objd

オブジェクト別のキャッシュ容量は、キャッシュブロック数と表領域のブロックサイズから概算できます。

キャッシュブロック数 × ブロックサイズ

V$BHはX$BHの完全な代替ではありませんが、どのオブジェクトのブロックがバッファキャッシュ上にどの程度存在しているかを確認する目的には利用できます。

キャッシュ量が多いオブジェクトが、直ちに性能問題の原因とは限りません。SQL、実行計画、物理読み込み、待機イベントなどの情報と対応付け、取得した時間帯の業務負荷も踏まえて評価する必要があります。

また、大規模なバッファキャッシュを全件集計するSQLは、相応のCPUやソート領域を使用する可能性があります。本番環境で実行する前に負荷を確認し、必要に応じて対象スキーマや表領域を絞ります。

オンプレミスの調査SQLをそのまま再現するのではなく、調査目的を起点に、RDSで利用可能な手段を組み合わせることが重要です。

Oracle DatabaseをオンプレミスからAmazon RDS for Oracleへ移行する際、確認すべきなのは、アプリケーションが正常に動作するかだけではありません。

性能調査、障害解析、ログ取得、セッション管理など、DBAが日常的に使用している調査手順が、RDS上でも同じように成立するかを確認する必要があります。

本記事で取り上げるのは、DBバッファキャッシュの利用状況を調査する際に使用されるX$BHです。

オンプレミスOracleで使用していたX$BH参照SQLを、RDS for Oracleのマスターユーザーで実行すると、次のエラーが発生します。

ORA-00942: table or view does not exist

Oracle Databaseという製品自体は同じです。

しかし、通常のRDS for OracleではSYSとしてログインできず、SYSDBA権限も使用できません。そのため、オンプレミスと同じ方法でSYS.X$BHを直接参照することはできません。

一方、現在のRDS for Oracleには、対応する環境でX$BHを基にしたSYS.RDS_X$BHビューを作成する仕組みがあります。

また、調査の目的によっては、Oracleが公開している動的パフォーマンスビューV$BHによって必要な情報を取得できます。

本記事では、RDS for OracleでSYS.X$BHを直接参照できない理由と、現在利用できる代替手段を整理します。

RDS for Oracleでは、X$BH以外にも、SYSDBA権限、OSアクセス、ストレージ操作、ログ取得など、オンプレミスの運用前提がそのまま通用しない場面があります。

RDS for Oracle全体の設計ギャップと代替アプローチについては、以下の記事で整理しています。

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

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

sys-univ.com

2026.08.30

今回調べたいのはDBバッファキャッシュの内訳

Oracle DatabaseのSGAには、データブロックを保持するDBバッファキャッシュがあります。

SQLによって読み込まれたデータブロックをメモリ上に保持しておくことで、同じブロックが再び必要になった際に、ストレージから読み込む処理を減らせます。

更新されたブロックについても、即座にすべてがデータファイルへ書き込まれるわけではありません。更新済みのブロックはバッファキャッシュ上に保持され、DBWRによって適切なタイミングで書き出されます。

このように、DBバッファキャッシュはOracle DatabaseのI/O性能に大きく関係するメモリ領域です。

ただし、バッファキャッシュは大きければ大きいほどよい、というものではありません。

DBインスタンスで利用できるメモリには上限があります。SGAに多く割り当てれば、その分だけPGAやOS、RDSの管理プロセスが利用できるメモリは少なくなります。

例えば、アプリケーションの機能追加によって同時接続数や処理量が増え、PGAの総使用量が増える可能性があるとします。

DBインスタンス全体のメモリに余裕がなければ、PGAに必要なメモリを確保するため、SGAを縮小できるか検討することになります。

SGAには、DBバッファキャッシュのほかにも、共有プール、ラージプール、Javaプール、REDOログバッファなどがあります。

その中でDBバッファキャッシュの縮小余地を検討する場合、まず確認したいのが、

どのテーブルやインデックスのブロックが、バッファキャッシュ上にどの程度存在しているか

という内訳です。

オンプレミスではX$BHを参照できる

オンプレミスOracleでは、DBバッファキャッシュの内部状態を詳しく調べるために、X$BHを参照する方法があります。

X$BHは、一般的なアプリケーション表や通常のデータディクショナリビューではありません。

Oracleが内部的に管理しているバッファヘッダーの情報を参照するための固定表です。

どのデータオブジェクトのブロックがバッファキャッシュ上に存在するかだけでなく、LRU_FLAGやTCHなど、バッファの利用状況を分析するための詳細な情報も保持しています。

例えば、TCHはバッファへのアクセス状況を調べる際に利用される情報です。

Oracle公式ドキュメントでは、X$BH.TCHはバッファのタッチカウントとして説明されており、値が高いブロックはホットブロックの候補になるとされています。

一般的には、次のような流れで調査します。

1. SGAとPGAの使用状況を確認する

2. DBバッファキャッシュがSGA内で占める容量を確認する

3. X$BHとDBA_OBJECTSを結合する

4. オブジェクトごとのキャッシュブロック数を集計する

5. キャッシュ上で大きな割合を占めるテーブルやインデックスを確認する

6. SQL、実行計画、物理読み込みなどの情報と照合する

重要なのは、特定のオブジェクトが大量にキャッシュされているだけでは、直ちに問題とは判断できないことです。

業務で頻繁に参照されるテーブルであれば、多くのブロックがキャッシュされていること自体は正常です。物理読み込みを減らし、性能向上に寄与している可能性があります。

一方で、利用頻度の低い大規模バッチが大量のブロックを読み込み、オンライン処理で必要なブロックをキャッシュから押し出している場合には、SQLや実行計画を見直す余地があります。

そのため、X$BHの結果だけでチューニングの要否を判断するのではなく、AWR、Statspack、SQL統計、待機イベント、実行計画などと組み合わせて評価する必要があります。

同じSQLをRDSで実行するとORA-00942になる

オンプレミスで使用しているX$BH参照SQLを、そのままRDS for Oracleのマスターユーザーで実行すると、次のエラーが発生します。

ORA-00942: table or view does not exist

このエラーだけでは、対象オブジェクトが存在しないのか、実行ユーザーに参照権限がないのかを判別できません。

Oracleでは、存在する表やビューであっても、実行ユーザーに必要なアクセス権限がない場合、ORA-00942が返ることがあります。

そのため、最初に考えられるのは、マスターユーザーに対する権限不足です。

しかし、X$BHのようなX$固定表は、通常の表やビューと同じ方法で、RDSのマスターユーザーへ参照権限を追加できるオブジェクトではありません。

AWSの公式ドキュメントでは、SYS.X$固定表はSYSだけが直接アクセスできる内部システムオブジェクトとして扱われています。通常のRDS for OracleではSYSとしてログインできないため、マスターユーザーに通常のGRANTを追加し、オンプレミスと同じ参照方法を再現することはできません。

RDSのマスターユーザーはSYSDBAではない

RDS for OracleのDBインスタンスを作成すると、マスターユーザーにはDBA権限が付与されます。

ただし、オンプレミスでSYSDBA権限を持つユーザーと、完全に同じ操作ができるわけではありません。

通常のRDS for Oracleでは、利用者はSYS、SYSTEMなど、Oracleがあらかじめ用意している管理ユーザーを使用できません。また、マスターユーザーにSYSDBA権限を付与することもできません。

Amazon RDSはマネージドサービスです。

バックアップ、パッチ適用、障害復旧、基盤監視などの一部をAWSが管理する代わりに、利用者が実行できるデータベース管理操作には一定の制限があります。

そのため、マスターユーザーにDBA権限が与えられていても、すべてのシステム権限やOracle内部オブジェクトへのアクセスが許可されるわけではありません。

今回参照しようとしているX$BHは、SYSだけが直接アクセスできるOracle内部の固定表です。

オンプレミスでSYSまたはSYSDBA権限を持つユーザーから参照できていても、RDSのマスターユーザーから同じ名前で直接参照することはできません。

grant_sys_objectでも何でも参照できるわけではない

RDS for Oracleでは、SYSが所有する一部のオブジェクトについて、次のRDS管理パッケージを使用し、別のデータベースユーザーへ権限を付与できます。

rdsadmin.rdsadmin_util.grant_sys_object

例えば、SYSが所有するデータディクショナリビューやパッケージに対して、SELECT権限やEXECUTE権限を付与する際に利用します。

ただし、このプロシージャを使用すれば、すべてのSYSオブジェクトへ自由にアクセスできるわけではありません。

grant_sys_objectで付与できるのは、マスターユーザー自身がロールまたは直接付与によって保持している権限に限られます。

マスターユーザー自身が持っていない権限を、このプロシージャによって新たに作り出すことはできません。

したがって、マスターユーザー自身がSYS.X$BHを直接参照できない環境では、grant_sys_objectを使って他のユーザーへX$BHの参照権限を付与することもできません。

オンプレミスで使用しているSQLがRDSで実行できなかった場合、

権限が足りない
　↓
GRANTを追加する
　↓
解決する

という単純な流れでは解決できないことがあります。

RDSで許可されている機能の中から、調査目的を満たせる別のビューや、RDS固有の管理プロシージャを探す必要があります。

現在はSYS.RDS_X$BHを作成できる

現在のRDS for Oracleには、対象となるX$固定表を基に、SYS.RDS_X$ビューを作成する仕組みがあります。

対応環境では、次のプロシージャを実行することで、RDS_X$ビューの作成対象として認められているX$固定表を確認できます。

SELECT *
FROM TABLE(
    rdsadmin.rdsadmin_util.list_allowed_sys_x$_views
);

実際に利用する際は、対象環境でこのプロシージャを実行し、その時点の一覧にX$BHが含まれていることを確認します。

対象として表示された環境では、次のプロシージャによって、X$BHを基にしたRDS_X$ビューを作成できます。

EXEC rdsadmin.rdsadmin_util.create_sys_x$_view('X$BH');

作成されるビュー名は、元のX$固定表名にRDS_が付いた形式です。

SYS.RDS_X$BH

作成されたRDS_X$ビューに対しては、マスターユーザーへSELECT WITH GRANT OPTIONが付与されます。必要に応じて、マスターユーザーから別のデータベースユーザーへ参照権限を付与できます。

RDS_X$ビューを利用できる環境

AWSの公式ドキュメントでは、RDS_X$ビューを利用できる環境として、次の条件が示されています。

• 一度もアップグレードされていない既存DBインスタンスで、19cまたは21cの2023年10月以降の対象リリースを使用している

• 新規に作成したDBインスタンス

• エンジンをアップグレードした既存DBインスタンス

一度もアップグレードされていない既存インスタンスでは、19cは19.0.0.0.ru-2023-10.rur-2023-10.r1以降、21cは21.0.0.0.ru-2023-10.rur-2023-10.r1以降が対象として示されています。

ただし、利用条件や作成対象となるX$固定表は、今後変更される可能性があります。

実際に使用する際は、記事に記載されたバージョン情報だけで判断せず、次の2点を確認する必要があります。

• 最新のAWS公式ドキュメントを確認する

• 対象環境でlist_allowed_sys_x$_viewsを実行する

RDS_X$ビューを本番で使う場合の注意点

RDS_X$ビューを作成できるからといって、通常のデータディクショナリビューと同じ感覚で使用してよいわけではありません。

RDS_X$ビューの基になっているX$固定表は、Oracleの内部システムオブジェクトです。その構造や動作は、一般的な公開インターフェースとして保証されていません。

AWSは、特定のRDS_X$ビューを非本番環境で検証し、本番環境ではOracle Supportのガイダンスの下で作成することを推奨しています。

また、X$固定表の構造は、エンジンアップグレードの前後で同じであることが保証されていません。

RDS for Oracleでは、エンジンアップグレード時に既存のRDS_X$ビューが削除され、アップグレード後のX$固定表を基に再作成されます。その後、マスターユーザーにはSELECT WITH GRANT OPTIONが再び付与されます。

ただし、マスターユーザー以外のデータベースユーザーへ付与していた権限は、自動的には復元されません。アップグレード後に、必要なユーザーへ権限を再付与する必要があります。

RDS_X$ビューを監視や定期調査へ組み込む場合は、次の点を運用設計へ反映します。

• 対象のX$固定表が作成対象に含まれているか確認する

• 非本番環境でSQLの動作と負荷を検証する

• エンジンアップグレード後にビューの状態を確認する

• マスターユーザー以外へ付与した権限を再設定する

• アップグレード後も必要な列が存在するか確認する

• 列構造や挙動を公開仕様として前提にしない

RDS_X$BHを作成すれば、対象環境においてLRU_FLAGやTCHなど、V$BHでは確認できない情報を参照できる可能性があります。

ただし、X$固定表の列構造は公開仕様ではありません。特定の列が将来にわたって同じ形で存在することを前提にした監視や運用は避けるべきです。

X$BHを調査する3つの方法

RDS for OracleにおけるX$BHの扱いは、次のように整理できます。

したがって、現在のRDS for Oracleについては、次のように理解する必要があります。

通常のRDS for Oracleでは、SYS.X$BHを直接参照できない。ただし、対応環境ではSYS.RDS_X$BHを作成できる。

「SYS.X$BHを直接参照できないこと」と、「X$BHを基にした情報を一切取得できないこと」は同じではありません。

それでもV$BHを知っておく理由

ここで一つ疑問が出てきます。

RDS_X$BHを作成し、対象環境でLRU_FLAGやTCHなどの必要な列を参照できるのであれば、V$BHを使った代替調査は不要ではないか、という疑問です。

しかし、必ずしもそうとは限りません。

RDS_X$BHは、Oracle内部の非公開オブジェクトを基にしたビューです。

作成対象となるX$固定表や列構造、アップグレード後の互換性を、公開仕様として前提にすることはできません。

また、本番環境で利用する前に、非本番環境での検証やOracle Supportへの確認が推奨されています。

一方、V$BHはOracleの公式リファレンスに記載された動的パフォーマンスビューです。

V$BHからは、バッファの状態、ファイル番号、ブロック番号、データオブジェクト番号、表領域番号などを取得できます。

必要な参照権限を持つユーザーであれば、RDS_X$ビューを新たに作成せずに利用できます。

そのため、今回のように、

バッファキャッシュ上に、どのオブジェクトのブロックが何件存在するか確認したい

という目的であれば、まずV$BHで必要な情報を取得できるか検討するのが現実的です。

V$BHでは不足する情報があり、LRU_FLAGやTCHなどX$BH固有の情報が調査上どうしても必要になった場合に、RDS_X$BHの作成を検討するという順序が考えられます。

ただし、V$BHはX$BHの完全な代替ではありません。

V$BHから取得できる情報と取得できない情報を区別し、調査目的に応じて使い分ける必要があります。

同じOracleでも運用方法まで同じとは限らない

今回の事例で重要なのは、X$BHという一つの内部表を参照できるかどうかだけではありません。

RDS for Oracleでは、Oracle Databaseという同じエンジンを使用していても、管理権限や調査方法までオンプレミスと同じになるわけではありません。

移行前には、アプリケーションのSQLや接続方式だけでなく、次のようなDBA運用についても確認する必要があります。

• 性能問題が起きた際に必要な情報を取得できるか

• 障害解析で利用しているビューやパッケージを参照できるか

• SYSDBAを前提とした運用手順が残っていないか

• Oracle内部表に依存した監視や調査を行っていないか

• RDS固有のプロシージャで代替できるか

• 代替した場合に取得できなくなる情報はないか

• 本番環境で使用する前に非本番環境で検証できるか

• エンジンアップグレード後も同じ手順を利用できるか

• アップグレード時に再設定が必要な権限はないか

オンプレミスの運用手順書に記載されたSQLを、そのままRDSへ移植するだけでは不十分です。

重要なのは、既存のコマンドをそのまま再現することではありません。

そのSQLを何のために実行しているのかを整理し、RDSで利用可能な手段によって同じ調査目的を満たせるか検証することです。

今回の目的は、DBバッファキャッシュ上に存在するオブジェクトと、そのキャッシュブロック数を把握することでした。

この目的に限定すれば、Oracleが公開している動的パフォーマンスビューV$BHを使って調査する方法があります。

一方、V$BHでは、X$BHが持つすべての内部情報を確認できるわけではありません。LRU_FLAGやTCHなど、V$BHからは取得できない情報もあります。

V$BHを使ってオブジェクトごとのキャッシュ量を確認するSQLと、X$BHから置き換える際の注意点については、以下の記事で詳しく解説しています。

【RDS for Oracle】V$BHでバッファキャッシュの内訳を調査する｜X$BHの代替方法

RDS for OracleでV$BHを使い、オブジェクト別のバッファキャッシュ量を調査する方法を解説。DATA_OBJECT_IDを使ったSQL、X$BHとの違い、結果の見方と実行時の注意点を整理します。

sys-univ.com

2026.07.13

まとめ

通常のRDS for Oracleでは、SYSまたはSYSTEMとしてログインできず、SYSDBA権限も使用できません。

そのため、オンプレミスと同じ方法でSYS.X$BHを直接参照することはできません。

ただし、現在のRDS for Oracleでは、対応する環境であれば、次のプロシージャを使用してSYS.RDS_X$BHビューを作成できます。

EXEC rdsadmin.rdsadmin_util.create_sys_x$_view('X$BH');

したがって、RDS for OracleにおけるX$BHの利用については、次の3点を区別する必要があります。

• SYS.X$BHを直接参照できるか

• SYS.RDS_X$BHを作成できる環境か

• V$BHで調査目的を代替できるか

RDS_X$BHを利用できる環境であっても、X$固定表はOracle内部の非公開オブジェクトです。

本番環境へ導入する際は、非本番環境での検証、エンジンアップグレード後の確認、他ユーザーへの権限再付与などを考慮する必要があります。

RDS移行では、データベースエンジンが同じであっても、オンプレミスと同じDBA権限や調査方法が提供されるとは限りません。

アプリケーションの互換性だけでなく、性能調査や障害解析を含む運用手順についても、移行前のPoCで確認しておく必要があります。