大手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

セキュリティグループも見た。
NACLも見た。
VPCルートテーブルも見た。

それでも通信できない。

そんなとき、原因はAWSコンソールの中ではなく、OSの中にあるかもしれません。

今回扱うのは、EC2を別AZで起動した際に、Windows ServerのOS内ルート情報が更新されず、通信できなくなった事象です。

この記事では、単なるルート設定の話ではなく、EC2Launch、User Data、AMI再利用、DR設計で見落としやすい「起動後のOS状態」について整理します。

EC2は起動した。でも通信できない

EC2インスタンスを別AZで起動した。

インスタンスの起動は成功している。
OSも上がっている。
しかし、通信できない。

このような事象が起きると、まずAWS側の設定を疑うと思います。

セキュリティグループがおかしいのか。
NACLで止められているのか。
サブネットのルートテーブルが間違っているのか。

もちろん、それらは確認すべきです。

しかし、今回の原因はそこではありませんでした。

問題は、Windows OS内のルーティング情報が、移動先AZに合わせて更新されていなかったことでした。

AZ移動後、Windowsサーバが通信できない

今回の事象は、AZ障害時の切替を想定した環境で発生しました。

通常時は、あるAZでWindows ServerのEC2インスタンスを稼働させています。

障害時には、別AZでインスタンスを起動し、業務を継続する想定でした。

構成としては、クラウドではよくある考え方です。

図　別AZでEC2を起動できても、起動後に通信できるとは限らない

ただし、この構成で注意すべきなのは、「別AZでEC2が起動できること」と「起動後に業務通信が成立すること」は別問題だという点です。

今回も、インスタンスの起動自体は成功していました。

OSも起動していました。

ところが、正常なネットワーク通信ができませんでした。

AWS側の設定だけを見れば、サブネット、セキュリティグループ、NACL、VPCルートテーブルを疑いたくなります。

しかし、調査していくと、問題はWindows OS内部のルーティング情報にありました。

移動先AZで必要となるルート情報が、OS起動時に追加されていなかったのです。

ここで重要なのは、VPCのルートテーブルではなく、Windows OS内のルート情報だという点です。

では、なぜOS内にルート情報が必要になるのでしょうか。

たとえば、次のような構成を考えてみます。

通常の業務通信は、デフォルトゲートウェイから出す。
一方で、監視サーバ向けのセグメント 172.16.10.0/24 には、2枚目のNIC、つまり別ENI側の経路を使って通信させる。

この場合、Windows OS内には、

172.16.10.0/24 は、2枚目のNIC側の経路へ向ける

VPCルートテーブルが正しくても、Windows OS内にこのルートがなければ、監視サーバ向けの通信は期待した経路に流れません。

EC2はクラウド上の仮想サーバです。

しかし、サーバである以上、OSの中にもネットワーク設定があります。

クラウド側の設定だけでは、通信は完結しません。

さらに、別AZで起動すると、通常は起動先のサブネットも変わります。

サブネットやENI構成が変われば、OS内のスタティックルートで前提にしていたネクストホップ（次に経由するルーターやゲートウェイのIPアドレス）　　やインターフェースが、移動先の環境と合わなくなることがあります。

しかし、AMIを取得した時点のOS内ルート情報には、旧環境を前提にした経路が残っている場合があります。

そのまま別AZで起動すると、ルートのエントリは存在しているのに、実際には期待した経路へ到達できない。

これが、

「設定した覚えはあるのに通信できない」

という事象の正体です。

原因はEC2Launchの起動時処理だった

原因は、Windows Serverの起動時に動く初期化処理でした。

Windows Server 2012 R2以前では、EC2Configというサービスが使われていました。

一方、Windows Server 2016 / 2019では、EC2Launch v1が使われる構成があります。

ここで見落としやすいのは、

「Windows Serverなら、起動時に毎回同じ初期化処理が走る」

とは限らないことです。

今回のポイントはここです。

AMIを取得する前のインスタンスで、すでに初回起動時の処理が終わっている。
その状態をAMIとして固める。
そのAMIから別AZで起動する。
しかし、OSや初期化エージェントの状態としては、必要な処理が「初回起動時のみ実行済み」と扱われる。
その結果、別AZで起動したときに、ルート追加処理が走らない。

このような流れになると、EC2自体は起動しているのに、OS内のルート情報が移動先AZに合わないまま残ります。

その結果、サーバは起動したのに通信できない、という状態になります。

若手SEがここで学ぶべきなのは、OSの設定そのものだけではありません。

「その設定は、いつ、どの仕組みによって入るのか」

を見る必要があるということです。

EC2Config、EC2Launch v1、EC2Launch v2をざっくり押さえる

細かい仕様をすべて暗記する必要はありません。

ただ、Windows EC2の初期化エージェントには世代差があることは押さえておくべきです。

Windows Server 2012 R2以前
  → EC2Config

Windows Server 2016 / 2019の一部AMI
  → EC2Launch v1

Windows Server 2022 / 2025、
一部のWindows Server 2016 / 2019 AMI
  → EC2Launch v2

EC2Launch v2では、「どのタスクを、どのステージで、どの頻度で実行するか」を管理する考え方になります。

見るべきポイントは、バージョン名そのものではありません。

実務では、以下を確認します。

・対象OSは何か
・EC2Config、EC2Launch v1、EC2Launch v2のどれか
・User Dataは初回だけか、毎回か
・起動時タスクは有効か
・タスクの実行頻度は once か always か
・初期化処理のログにエラーは出ていないか

ここを確認しないままDR設計や移行設計を進めると、机上では成立しているのに、切替時に通信できないサーバが立ち上がることがあります。

なお、EC2Launch v2には agent-config.yml などの設定ファイルがありますが、この記事では詳細な設定手順までは踏み込みません。

ここで重要なのは、ファイル名を暗記することではなく、起動時に実行されるタスクと実行頻度を確認する、という考え方です。

なぜ永続ルートではなく、起動ごとの処理なのか

ここで、こう思う人もいるかもしれません。

「Windowsなら route add -p で永続ルートにすればよいのでは？」

たしかに、固定的な経路であれば、それで済む場合もあります。

route add -p は、Windowsで再起動後も残るルートを登録する方法です。

しかし、クラウド移行やAZ切替では、単純な永続ルートだけでは不十分な場合があります。

なぜなら、起動先のAZ、サブネット、ENI構成、ゲートウェイ、経路設計によって、追加すべきルートが変わることがあるからです。

AMIに固定ルートを焼き込んでしまうと、元のAZでは正しくても、別AZでは古い経路を引きずる可能性があります。

たとえば、元の環境では `10.0.1.1` 側を通る前提でOS内にルートを持っていたとします。

しかし、別AZで起動した後は、サブネットやENI構成が変わり、`10.0.2.1` 側を通すべき構成になっているかもしれません。

このとき、OS内に旧環境のルートが残ったままだと、設定は存在しているのに、移動先環境では正しい経路に通信が流れません。

一方、起動ごとのスクリプトでルートを追加する方式なら、起動先の環境に合わせて必要なルートを入れ直す設計にできます。

もちろん、その分だけスクリプト設計は慎重に行う必要があります。

特に重要なのが、冪等性です。

冪等性とは「同じ処理を何度実行しても、結果が壊れず同じ状態に収まる性質のこと」です。

起動のたびに実行される処理は、何度実行しても壊れないように作る必要があります。

たとえば、同じルートを毎回追加しようとしてエラーになる。
既存設定を無条件で上書きしてしまう。
途中で失敗したときに中途半端な状態が残る。

こうした作りになっていると、初期化処理そのものが新しい障害原因になります。

対策は「OS起動ごとに必要な処理を実行させる」こと

今回の対策は、OS起動ごとに必要なルート追加処理が実行されるようにすることでした。

EC2Launch v1の場合、単に「起動すれば自動で全部整う」と考えるのではなく、起動時に必要な処理が実行される状態になっているかを確認する必要があります。

たとえば、今回のようなルート追加であれば、User DataからEC2Launchのモジュールを読み込み、`Add-Routes` を呼び出す方法があります。

Import-Module (Join-Path $env:ProgramData 'Amazon\EC2-Windows\Launch\Module\Ec2Launch.psd1')
Add-Routes

<persist>true</persist>

重要なのは、コマンドそのものを暗記することではありません。

タスクスケジューラ、User Data、EC2Launchのどの仕組みによって、起動時の処理を実行させているのかを理解することです。

EC2Launch v2では、この種の起動時タスクの扱いが整理されており、同じ問題が起きにくい構成になっています。

ただし、実際の挙動は、AMIの世代、EC2Launchのバージョン、User Data、タスクの実行頻度に依存します。

そのため、v2だから確認不要、とは考えない方が安全です。

環境によって確認ポイントは変わります。

しかし、共通する考え方は同じです。

「起動時に、必要なOS設定が、確実に反映される状態になっているか」

ここを確認する必要があります。

AWS側の設定だけ見ても足りない

若手SEにとって、EC2の通信不可というと、どうしてもAWS側の設定に目が行きます。

それ自体は間違いではありません。

実際、通信不可の原因として、セキュリティグループ、NACL、VPCルートテーブル、サブネット、ENI、DNS設定などはよくあります。

しかし、それだけでは足りません。

今回のように、OS内部の設定が原因になることもあります。

今回の切り分けは、3つの層で見ると整理しやすくなります。

AWSインフラ層
  → セキュリティグループ、NACL、VPCルートテーブルを見る

初期化エージェント層
  → EC2LaunchやUser Dataが期待どおり実行されたかを見る

OS設定層
  → Windowsのルーティングテーブルが移動先環境に合っているかを見る

EC2の通信確認では、AWS側の設定、クラウド初期化処理、OS内部の設定を一連の流れとして見る必要があります。

図　AWS側の設定だけ見ても足りない

この図で言いたいのは、EC2が起動した時点で確認が終わるわけではない、ということです。

AWS側の設定が正しく、インスタンスが起動していても、その後に動く初期化処理やOS内部の設定が想定どおりでなければ、業務通信は成立しません。

サーバが起動していることと、業務通信が成立していることは別です。

ここを混同すると、DRテストや移行リハーサルで痛い目を見ます。

これはルーティングだけの話ではない

今回の事象は、Windows Serverのルーティング情報が更新されなかった、という個別トラブルに見えます。

しかし、これはルーティングだけの話ではありません。

以前扱ったような、MTU設定が戻る、SSHでログインできない、OS起動後に想定した設定になっていない、といった事象にも共通する構造があります。

共通しているのは、初期化エージェントがOS設定を書き換える、または書き換えないことで、起動後のOS状態が想定とずれる点です。

ある設定は、初期化エージェントによって上書きされます。

別の設定は、初期化エージェントが実行されないために更新されません。

つまり、

「書き換えられて困る」

場合もあれば、

「書き換えてほしいのに書き換わらない」

場合もあります。

どちらも、クラウド初期化処理がOS設定に関与していることを理解していないと、原因にたどり着きにくくなります。

なぜクラウドはOS設定を書き換えるのか

では、なぜクラウド環境では、起動時にOS設定へ手を入れるのでしょうか。

理由は大きく3つあります。

1つ目は、セキュリティです。

クラウド環境では、インターネットや社内ネットワークから到達可能なサーバを短時間で作成できます。

そのため、初期状態をできるだけ安全側に寄せる必要があります。

SSHのパスワード認証を無効にし、公開鍵認証を前提にするような考え方は、その典型です。

パスワード総当たり攻撃の入口を減らすためです。

これは、クラウド環境におけるベストプラクティスに寄せた挙動と考えると理解しやすいです。

2つ目は、クラウド環境に合わせてOSを自動適応させるためです。

EC2インスタンスは、起動時にインスタンスメタデータ、User Data、ネットワーク情報などを利用します。

OSは、起動した場所、割り当てられたIP、ホスト名、初期化スクリプトなどをもとに、クラウド上で動ける状態に整えられます。

3つ目は、AMIを再利用するためです。

AMIは、ある時点のOS状態を固めたものです。

しかし、そのAMIから起動されるインスタンスは、元の環境と同じとは限りません。

別AZかもしれません。
別サブネットかもしれません。
別IPかもしれません。
別用途のサーバとして起動されるかもしれません。

そのため、AMIに残っているOS設定をそのまま信じるだけでは危険です。

クラウドでは、起動時にメタデータやUser Dataを参照し、起動先の環境に合わせて初期化する仕組みが用意されています。

ただし、その初期化処理が「いつ」「どの条件で」「何を」実行するかは、OS、エージェント、設定によって変わります。

ここを理解していないと、

設定したはずなのに戻った
自動で入ると思っていたのに入らなかった
AMIから起動したら前の状態を引きずった

DR設計では「起動できる」だけでは足りない

今回の話は、DR設計やAZ障害時の切替設計にも直結します。

DR設計では、次のような確認をしがちです。

・別AZでEC2が起動できる
・AMIからインスタンスを作成できる
・EBSを付け替えられる
・IPやDNSを切り替えられる

しかし、これだけでは不十分です。

本当に確認すべきなのは、起動後に業務通信が成立するかです。

実務では、少なくとも以下を確認した方がよいです。

・OS内のルート情報は正しいか
・DNS名前解決はできるか
・ADや認証基盤へ到達できるか
・業務アプリの接続先へ通信できるか
・監視、バックアップ、ジョブ管理エージェントは動くか
・User Dataや起動時スクリプトは期待どおり実行されたか
・初期化処理のログにエラーは出ていないか

業務として使える状態になったかどうかです。

ここを間違えると、テストでは成功したように見えても、本番障害時に通信できないサーバが立ち上がることになります。

まとめ

今回は、EC2を別AZで起動した際に、Windows Serverのルーティング情報が更新されず、通信できなくなった事象を扱いました。

原因は、AWS側のセキュリティグループやVPCルートテーブルではなく、OS内部のルート情報でした。

そして、その背景には、EC2Config、EC2Launch、EC2Launch v2といったクラウド初期化エージェントの挙動差がありました。

クラウドでは、サーバを起動するだけなら簡単です。

しかし、起動したサーバが業務として使える状態になっているかは、別の問題です。

若手SEは、EC2が起動したかどうかだけで安心してはいけません。

見るべきなのは、起動後に、どの設定が、どのタイミングで、どの仕組みによって反映されるのかです。

サーバは起動した。
でも通信できない。

その原因は、AWS側ではなく、OSの中にあるかもしれません。

関連記事

今回のようなトラブルは、AWSやOSの設定だけを個別に見るのではなく、切替後にシステム全体が業務として使える状態になっているかまで確認する必要があります。

システム基盤・クラウドエンジニアの仕事
サーバー、OS、監視、バックアップ、可用性、クラウドなどを横断し、
システムを「整える・保つ・戻す」ための基盤設計・運用・障害対応を解説しています。

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

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

sys-univ.com

2026.08.17

詳細設計とは何を決める工程か｜パラメータ表で終わらせないための設計の考え方
基本設計で決めた内容を、構築・テスト・運用できる具体的な設定や手順へどう落とし込むかを整理しています。

【全3回・第1部】詳細設計とは何を決める工程か｜パラメータ表で終わらせないための設計の考え方

詳細設計とは、基本設計で決めた方式を構築・テスト・運用できる粒度に落とし込む工程です。OS、ミドルウェア、DB、ジョブ、監視、バックアップなどを、単なるパラメータ表ではなく品質保証ストーリーとして設計する考え方を基盤SEの目線で解説します。

sys-univ.com

2026.08.20

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

実務で使えるシステム開発方法論｜ナギ ＠ 氷河期SEの知見録｜note

要件定義、基本設計、詳細設計、テスト、移行、運用保守まで、システム開発の流れを実務目線で体系化するマガジンです。教科書には書かれにくい、設計漏れ、手戻り、品質保証、運用で詰まるポイントを、現場経験に基づいて整理します。若手SEだけでなく、開ReadMore...

note.com

たとえば、検証作業、メンテナンス、OS設定変更、ミドルウェア設定変更、不要時間帯の停止などです。

単体のEC2であれば、停止して、起動する。それだけです。

しかし、そのEC2がAuto Scaling Group配下のインスタンスだった場合、話は少し変わります。

Auto Scaling Groupは、単にEC2をまとめて管理する仕組みではありません。指定された台数を維持するために、インスタンスの状態を監視し、異常と判断した場合には新しいインスタンスに置き換える仕組みです。

ここで、現場で起こりがちな事故があります。

Auto Scaling対象のEC2を停止・起動したところ、意図せずインスタンスが再作成されてしまう。

作業者としては「既存のEC2を一時停止して、また起動しただけ」のつもりです。しかしAuto Scaling側から見ると「正常ではないインスタンスがいる。希望台数を維持する必要がある」という判断になることがあります。そして結果として新しいEC2が起動され、元のEC2が置き換えられてしまう。

これが、Auto Scaling配下のEC2停止・起動で起こる落とし穴です。

クラウドでも、過去の落とし穴が消えているとは限らない

実はこれ、かなり昔に経験した事象です。

Auto Scaling配下のEC2を停止・起動したところ、意図せずインスタンスが再作成されてしまった。

当時は、「そんな動きをするのか」と思いました。

ただ、クラウドサービスは日々進化します。

昔の事故事例を、今もそのまま起こる前提で語るのは危険です。

一方で、過去に起きた事故や落とし穴が、現在では完全に解消されているとも限りません。

特に、Auto Scaling、ヘルスチェック、自動復旧、フェイルオーバーのような仕組みは、クラウドサービスの基本的な設計思想に関わります。

そのため、昔の事例であっても、今の仕様ではどうなっているのかを確認することが大切です。

今回の事象も、現在のAWS公式ドキュメントで確認できます。

つまり、Auto Scaling Group配下のEC2を停止するという行為は、今でも単体EC2の停止とは意味が違います。

単体EC2なら、停止はただの停止です。

しかしAuto Scaling Group配下では「本来動いているべきインスタンスが、正常な状態ではない」と判断される可能性があります。

これはAWSのバグというより、Auto Scalingが希望台数を維持するための仕様です。

問題は、作業者の意図とAuto Scalingの判断がずれることです。

HealthCheckとReplaceUnhealthyの違い

Auto Scalingには複数の内部プロセスがあります。今回特に関係するのがHealthCheckとReplaceUnhealthyです。

HealthCheckはインスタンスの正常性を確認し、ReplaceUnhealthyは、異常と判断されたインスタンスを置き換えるプロセスです。

AWS公式ドキュメントでは、以下のとおり説明されています。

つまり、ReplaceUnhealthyを止めていたとしても、その間にインスタンスが異常扱いになっていると、再開した瞬間に置き換えが走る可能性があります。

作業者としては「作業が終わったから戻そう」という感覚です。しかしAuto Scaling側では「このインスタンスはすでに異常とマークされています。プロセスが再開されたので置き換えます」という動きになる可能性があります。だから、単にプロセスを戻すのではなく、戻す前の状態確認が必要になります。

「ヘルスチェック猶予期間があるから大丈夫」ではない

ヘルスチェック猶予期間は、新しく起動したインスタンスがInServiceになってから、Auto Scalingがヘルスチェックの評価を始めるまでの待ち時間です（AWS公式ドキュメント）。

これだけを見ると「猶予期間を長くしておけば安全では？」と思うかもしれません。しかしここに落とし穴があります。

ヘルスチェック猶予期間は、アプリケーションの起動待ちには役立ちます。しかし、Auto Scaling Group内のインスタンスを停止した場合に、それを安全に見逃してくれる仕組みではありません。ここを勘違いすると危険です。

どう対策すべきか

対策として重要なのは、EC2を起動した直後にAuto Scalingのヘルスチェックや置き換えプロセスを機械的に戻さないことです。

「EC2起動後、5分待ってからヘルスチェックを有効化する」という運用は実務上よく見ます。ただし、5分という数字そのものが本質ではありません。本質は「Auto Scalingが正常と判断できる状態になってから戻す」ことです。

戻す前に確認すべきことは次のとおりです。

• EC2のステータスチェックが正常であること

• OSが正常に起動していること

• ミドルウェアが起動していること

• アプリケーションが正常応答していること

• ELBまたはターゲットグループでHealthyになっていること

• Auto Scaling Activityに異常な置き換え履歴がないこと

手順書には「起動後5分待つ」だけでなく、「何を確認できたら次の操作に進んでよいのか」を書く必要があります。

事前にどうチェックすべきか

このような事象を防ぐために、作業前に確認すべき点は大きく4つあります。

1. 対象EC2がAuto Scaling Group配下か確認する

EC2一覧だけを見ていると、普通のEC2に見えます。しかしタグやAuto Scaling Group名を見ると、ASG管理対象であることがあります。少なくとも以下を確認してください。

• 対象EC2はAuto Scaling Group配下か

• Desired Capacityはいくつか

• 対象インスタンスを停止した場合、希望台数維持のために補充されるか

• 再作成された場合、元の状態を再現できるか

特に危険なのは、手作業で設定変更されたEC2がAuto Scalingで再作成されるケースです。再作成されたEC2は起動テンプレートやAMIに基づいて作られるため、手作業で入れた設定が消える可能性があります。

2. どのAuto Scalingプロセスを止めるべきか確認する

HealthCheckとReplaceUnhealthyは意味が違います。状況に応じて、どちらを止めるのか、Standbyを使うのかを判断する必要があります。スケジュールスケーリングやスケーリングポリシーの影響も確認してください。

• プロセスの一時停止・再開：（AWS公式ドキュメント）

• Standby機能：（AWS公式ドキュメント）

3. ヘルスチェック猶予期間と起動時間を確認する

EC2起動からステータスチェック正常化まで何分かかるか、アプリケーションが正常応答するまで何分かかるか、ELBがHealthyになるまで何分かかるか。これらがヘルスチェック猶予期間と整合しているかを確認してください。

4. 手順書に「戻し条件」を書く

運用手順書でよくあるのは、操作手順は書いてあるが戻し条件が曖昧なケースです。「EC2起動後、Auto Scalingのヘルスチェックを有効化する」だけでは危険です。上で挙げた確認項目をすべて満たしたことを確認してから戻す、と明記する必要があります。

運用手順で大事なのは操作そのものではありません。次の操作に進んでよい条件を明確にすることです。

これは運用設計の問題である

今回の話は、AWSのAuto Scalingという個別サービスの話に見えます。しかし実際には運用設計の問題です。

Auto Scalingを使うなら、設計時点で少なくとも以下を決めておく必要があります。

• インスタンスを手動停止してよいのか

• メンテナンス時はStandbyに入れるのか

• HealthCheckやReplaceUnhealthyを一時停止するのか

• どの条件を満たしたらAuto Scalingのプロセスを戻してよいのか

• 再作成された場合、設定やデータは失われないのか

• 手作業で変更した内容はAMI、起動テンプレート、IaCに反映されているのか

これらは、運用当日に作業者がその場で判断するものではありません。設計書、運用設計書、作業手順書、チェックリストに落としておくべき内容です。

クラウドでは、ひとつの操作に対して裏側で複数の自動化機能が反応します。作業対象のサーバだけを見ていると危険です。周辺にある自動制御の仕組みまで含めて、作業手順を考える必要があります。

これはバックアップ保存期限の設計と同じ構図です。「5日保存」と書いてあっても5営業日分なのか5世代なのかを確認しないと復旧時に認識違いが起きます。Auto Scalingも同様で、「EC2を停止・起動する」とだけ書くのではなく、その操作に対してAuto Scaling、ELB、CloudWatchがどう反応するのかまで設計しておく必要があります。

設計で決めるべきことを曖昧にしたまま運用に渡すと、作業時に現場が迷います。Auto Scalingの事故は、そのことを教えてくれる典型例です。

まとめ

Auto Scaling対象のEC2を停止・起動する場合、単体EC2と同じ感覚で作業してはいけません。

停止中にインスタンスがUnhealthyと判定され、起動直後にプロセスを戻した瞬間に置き換えが始まることがあります。ヘルスチェックの猶予期間を長くしても、停止中に発生する置き換えそのものを防げるわけではありません。「起動後5分待つ」といった運用ルールも、環境や処理時間に依存する暫定的な対処であり、設計上の判断基準にはなりません。

重要なのは、Auto Scalingがインスタンスを正常と判断できる状態まで復旧したことを確認してから、通常運用へ戻すことです。さらに、その正常性を何で確認するのかを設計時点で明確にし、運用手順書へ落としておく必要があります。

クラウドの自動化は便利ですが、作業者が「いまはメンテナンス中だから置き換えてほしくない」と考えていることまでは判断してくれません。正常時の構成だけでなく、メンテナンス時、障害時、復旧時に各サービスがどのように振る舞うのかまで含めて設計することが、クラウド環境では重要になります。

関連記事

こうした正常時だけでなく、障害時・復旧時・運用時の振る舞いまで設計する考え方については、以下の記事でも整理しています。

• 詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程
  基本設計で決めた方式を、実際に構築できる設定値や設計内容まで具体化する工程を解説しています。

【全3回・第1部】詳細設計とは何を決める工程か｜パラメータ表で終わらせないための設計の考え方

詳細設計とは、基本設計で決めた方式を構築・テスト・運用できる粒度に落とし込む工程です。OS、ミドルウェア、DB、ジョブ、監視、バックアップなどを、単なるパラメータ表ではなく品質保証ストーリーとして設計する考え方を基盤SEの目線で解説します。

sys-univ.com

2026.08.20

• 実務で使えるシステム開発方法論
  システム開発の各工程で何を検討し、どのように設計へ落とし込むのかについては、以下のマガジンにまとめています。

実務で使えるシステム開発方法論｜ナギ ＠ 氷河期SEの知見録｜note

要件定義、基本設計、詳細設計、テスト、移行、運用保守まで、システム開発の流れを実務目線で体系化するマガジンです。教科書には書かれにくい、設計漏れ、手戻り、品質保証、運用で詰まるポイントを、現場経験に基づいて整理します。若手SEだけでなく、開ReadMore...

note.com

私が確認した環境でも、タスク定義にはEFSボリュームを定義しており、アプリケーションからEFS上のファイルを正常に読み書きできているにもかかわらず、マウント元はlocalhostになっていました。

EFSへ接続しているはずなのに、なぜ接続先が127.0.0.1なのか。クロスアカウントでEFSを利用していることが原因なのか、Fargate特有の動作なのか、マウント情報だけでは分かりませんでした。

結論から書くと、これはEFSの転送時暗号化（TLS）で使われる仕組みによるものです。

NFSクライアントはEFSへ直接接続するのではなく、ローカルで待ち受けるプロキシへ接続します。そのプロキシがEFSとのTLS通信を担当するため、NFSクライアントから見た接続先として127.0.0.1が表示されます。

この記事では、実際に確認した127.0.0.1という表示を起点に、EFSの転送時暗号化でどのような通信経路が作られるのか、AWSサポートがEC2基盤のECSタスクで確認したログも交えて整理します。

EFSをマウントしているのに127.0.0.1が表示された

今回確認したのは、ECS/Fargateから別AWSアカウントのEFSを利用する構成です。

AWSアカウントA

ECS / Fargate
      │
      │ EFSマウント
      ▼

AWSアカウントB

EFS

タスク定義にはEFSボリュームを定義し、コンテナの所定のディレクトリへマウントしていました。アプリケーションからEFS上のファイルを読み書きできているため、EFSへの接続自体は成立しています。

ところが、コンテナ内からマウント状態を確認すると、次のように表示されました。

127.0.0.1:/ on /mnt/xxxx type nfs4 (...,port=2xxxx,...,addr=127.0.0.1)

通常のNFSマウントをイメージすると、接続先にはEFSのDNS名やマウントターゲットが見えるように思えます。実際に表示されているのは127.0.0.1、コンテナから見たlocalhostです。

この結果だけを見ると、「EFSではなくローカルのファイルシステムを見ているのではないか」「クロスアカウントEFSだから特殊なマウントになっているのではないか」と考えたくなります。

原因はクロスアカウント構成そのものではありませんでした。

NFSクライアントはローカルポートへ接続している

EFSへの通信経路は、転送時暗号化の有無によって変わります。

転送時暗号化を利用しない場合、NFSクライアントはEFSマウントターゲットへ直接NFS通信を行います。転送時暗号化を有効にすると、NFSクライアントとEFSの間に、TLS通信を担当するプロキシが入ります。

図：EFSの転送時暗号化なし／ありで変わる通信経路

転送時暗号化を有効にした場合、NFSクライアントから見た接続先はEFSではなく、ローカルで待ち受けているプロキシです。NFSクライアントは127.0.0.1のローカルポートへ接続し、efs-proxyがその通信をTLSでEFSへ中継します。

このため、mountなどで確認したマウント情報には、EFSのDNS名ではなく127.0.0.1が現れます。127.0.0.1はEFSそのものを示しているのではなく、NFSクライアントから見たローカル側の接続先です。

AWSのEFSドキュメントでも、EFS mount helperを使用して転送時暗号化を行う場合、NFSクライアントはローカルポートへマウントするよう構成され、マウント情報では127.0.0.1として見えることが説明されています。

Encrypting data in transit – Amazon Elastic File System

127.0.0.1が表示されたこと自体は、EFSへの接続異常を示しているわけではありません。

なぜTLS通信ではlocalhostを経由するのか

NFSクライアントからEFSへの通信をTLSで暗号化するには、NFS通信とTLS通信の間を仲介するコンポーネントが必要になります。

EFSではamazon-efs-utilsに含まれるEFS mount helperが、このマウント処理を支援します。現在のamazon-efs-utilsではefs-proxyが利用され、2.0.0より前のバージョンではstunnelが利用されていました。

古いEFSの記事ではstunnel、比較的新しい記事ではefs-proxyという名前が出てくることがありますが、これはamazon-efs-utilsのバージョンによる違いです。amazon-efs-utils 2.0.0以降では、従来のstunnelに代わって、性能を改善したefs-proxyが利用されています。

今回なぜ転送時暗号化が有効になっていたのか

ここまでの仕組みは、EFSの転送時暗号化を利用していることが前提です。

ECSのタスク定義では、EFSボリュームのtransitEncryptionによって転送時暗号化を指定します。transitEncryptionを省略した場合の既定値はDISABLEDです。

IAM認可またはEFS Access Pointを利用する構成では、transitEncryptionを明示的に有効にする必要があります。自動的にTLSが有効になるわけではありません。

たとえばIAM認可を利用する場合、タスク定義のvolumes内の該当部分は次のような設定になります。

{
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-xxxxxxxx",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {
      "iam": "ENABLED"
    }
  }
}

IAM認可と転送時暗号化の関係や、transitEncryptionの既定値についてはAWSのECSドキュメントでも確認できます。

Specify an Amazon EFS file system in an Amazon ECS task definition

EFSを利用している環境で127.0.0.1が表示された場合、クロスアカウント構成かどうかだけを見るのではなく、タスク定義のtransitEncryptionやauthorizationConfigを確認する必要があります。

今回見えていた127.0.0.1は、クロスアカウントだから発生したものではなく、EFSをTLSでマウントする通信経路の一部でした。

EC2基盤のmount.logではefs-proxyの起動を確認できる

Fargateでは利用者がホストOSへログインできないため、EFSのマウント処理をホスト側から直接確認できません。

AWSサポートへ問い合わせたところ、EC2基盤のECSタスクで同様のEFSマウントを確認した結果として、/var/log/amazon/efs/mount.logのログが提示されました。

一部を簡略化すると、次のような内容です。

INFO - binding <local port>
INFO - Starting efs-proxy:
       nsenter --net=/proc/xxxx/ns/net ... /sbin/efs-proxy ...
INFO - Started efs-proxy, pid: <pid>

ログには、ローカルポートの確保、efs-proxyの起動、指定されたネットワーク名前空間への切り替えが記録されています。nsenter --net=が使われていることから、efs-proxyは指定されたネットワーク名前空間内で起動されていることが確認できます。

これを通信経路と対応させると、mountで見えていた127.0.0.1と、mount.logに記録されたローカルポートの確保、efs-proxyの起動、EFSへのTLS接続が一つの流れとして理解できます。

図：EC2基盤のmount.logとefs-proxyによる通信経路の対応

EC2基盤では、127.0.0.1というマウント表示が単なるlocalhostを示しているのではなく、その先でefs-proxyを介してEFSへ接続するためのローカルエンドポイントであることを、ログと通信経路を対応させて確認できます。

Fargateではどこまで確認できるのか

FargateではホストOSがAWSによって管理されているため、利用者がmount.logやホスト側のプロセス一覧を直接確認することはできません。

FargateでEFSボリュームを利用すると、AWSはEFSボリュームを管理するためのaws-fargate-supervisorというsupervisorコンテナを作成します。

このコンテナは、タスクメタデータエンドポイント バージョン4（Task Metadata v4）から確認できるほか、CloudWatch Container Insightsでもaws-fargate-supervisorというコンテナ名で確認できます。

aws-fargate-supervisorはタスクに割り当てられたCPUとメモリを少量使用します。EFSを利用するFargateタスクでは、アプリケーションコンテナ以外にもEFSボリューム管理のためのリソースが消費されることになります。

この仕様はAWSのECSドキュメントに記載されています。

Amazon EFS volumes – Amazon Elastic Container Service

ここで注意したいのは、aws-fargate-supervisorとefs-proxyを同じものとして扱わないことです。

AWS公式ドキュメントでは、aws-fargate-supervisorがEFSボリュームの管理を担当することまでは説明されていますが、supervisorコンテナとefs-proxyの具体的な関係までは明示されていません。

今回、FargateタスクではEFSのマウント元が127.0.0.1として表示されました。EFSの公式仕様では、TLSマウント時にNFSクライアントをローカルポートへ接続する方式が説明され、EC2基盤で確認されたログでは実際にefs-proxyが起動しています。

これらからFargateでも同様の通信方式が使われていると考えられますが、Fargate内部でEC2基盤とまったく同じプロセス起動シーケンスが実行されているところまで、今回直接確認したわけではありません。

127.0.0.1が見えたとき、何を切り分けるのか

mountの結果に127.0.0.1が表示されても、それだけでEFSへの接続障害とは判断できません。転送時暗号化を利用している場合、localhostは正常な通信経路の一部だからです。

アプリケーションからEFS上のファイルを正常に読み書きできているのであれば、127.0.0.1を理由にネットワーク障害を疑う必要はありません。

EFSをマウントできない、あるいはアクセス時にエラーになる場合は、localhostより先の経路を確認します。主な確認対象は次のとおりです。

• ECSタスクとEFSマウントターゲット間のセキュリティグループ
• NFS（TCP/2049）の通信可否
• 利用するAZのEFSマウントターゲット
• IAM認可
• EFSファイルシステムポリシー
• Access Pointを利用している場合はその設定

EC2基盤であれば、/var/log/amazon/efs/mount.logも有力な調査材料になります。Fargateではホスト側のmount.logを直接確認できないため、タスクの停止理由やECSのイベント、EFS側のネットワーク・認可設定など、利用者から確認できる範囲で切り分けます。

ここで重要なのは、

127.0.0.1という表示だけでは、EFSへの到達性が正常か異常かは判断できない

ということです。

設定値と実行時の状態は同じではない

今回の調査で改めて感じたのは、マネージドサービスでは設定として見えているものと、その設定を実現するために内部で動いている処理が同じ粒度ではないということです。

ECSのタスク定義には、EFSのファイルシステムIDやマウント先、転送時暗号化、認可方式などを設定します。そこに「127.0.0.1へNFSマウントする」「efs-proxyを起動する」と書くわけではありません。

利用者が指定した設定を実現するため、基盤側では別の処理が動きます。通常はそこまで意識する必要がないこと自体がFargateの利点ですが、障害調査では、この隠蔽が逆に分かりにくさにつながることがあります。

タスク定義ではEFSを指定しているのに、実行時には127.0.0.1が見える。設定だけを見ていれば、この二つが同じEFSマウントを表しているとは直感的に理解しにくいからです。

以前、ECS/Fargateで非rootコンテナを動かした際にも、Dockerfileでchownしたディレクトリと、ECSがボリュームをマウントした後の実行時状態が異なることで、Permission deniedが発生しました。
この事象については、以下の記事で実際の原因と切り分けを整理しています。

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

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

sys-univ.com

2026.08.14

今回も問題の種類は違いますが、見るべきポイントは似ています。

設定ファイルに何を書いたかだけではなく、その設定によって実行時にどのような状態が作られるのかを見る。

Fargateのように基盤側が隠蔽されているサービスほど、この視点が障害調査や設計レビューで重要になります。

この違いを設計書や設定値だけで確認するには限界があります。

特にクラウド移行では、本番相当の構成で実際に動かし、設計時の想定と実行時の状態に差がないかをPoCで確認することが重要です。PoCで何を確認すべきか、確認不足が後工程でどのような手戻りにつながるのかは、以下の記事で整理しています。

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

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

sys-univ.com

2026.08.20

まとめ

ECS/FargateからEFSをマウントしているにもかかわらず、マウント情報に127.0.0.1が表示されるのは、EFSの転送時暗号化で利用される通信方式によるものです。

NFSクライアントはEFSへ直接接続せず、ローカルポートで待ち受けるプロキシへ接続します。現在のamazon-efs-utilsではefs-proxyがEFSとのTLS通信を担当するため、NFSクライアントから見た接続先としてlocalhostが表示されます。

127.0.0.1が見えたこと自体はEFSへの接続障害を意味しません。マウントやアクセスに問題がある場合は、localhostという表示ではなく、EFSまでのネットワーク経路やIAM認可、ファイルシステムポリシーなどを切り分ける必要があります。

設定として書いた内容と、それを実現するために実行時に作られる状態は、別に確認する必要があります。

参考文献

• Encrypting data in transit – Amazon Elastic File System
• Specify an Amazon EFS file system in an Amazon ECS task definition
• Amazon EFS volumes – Amazon Elastic Container Service
• EFSVolumeConfiguration – Amazon Elastic Container Service
• EFSAuthorizationConfig – Amazon Elastic Container Service

なのに、本番運用で失敗する。

そういうことがあります。

今回起きたのは、CloudWatch Logsのログエクスポートジョブが、日次処理でエラーになるという事象です。

CloudWatch Logsのログを、定期的にS3へエクスポートする。

AWSを使ったシステムでは、よくある運用設計です。

ログをCloudWatch Logsに集約し、一定期間ごとにS3へ退避する。
監査、障害調査、保存期間、コスト、運用保守を考えると、自然な構成に見えます。

しかし、今回の本質は、ジョブの実装ミスではありませんでした。

問題は、AWSサービスの制約を、運用ジョブ設計とテスト設計に織り込めていなかったことです。

CloudWatch Logsのログエクスポートは、ジョブを作れば好きなだけ並列に流せるものではありません。

ここを知らないと、単体では正常に動いていたジョブが、本番運用で突然失敗します。

起きたこと

あるシステムで、日次ジョブとしてCloudWatch Logsのログエクスポートを実行していました。

処理内容はシンプルです。

CloudWatch Logsに出力されたログを、一定期間ごとにS3へエクスポートする。
S3側に保存しておけば、長期保管、調査、監査対応にも使える。
CloudWatch Logs側の保持期間も適切に管理できる。

よくある構成です。

ところが、日次ジョブで実行しているログエクスポートがエラーになりました。

確認すると、ロググループは存在している。
S3バケットも存在している。
IAMロールも大きく間違っていない。
以前は同じ処理が動いていた。

にもかかわらず、ジョブが失敗する。

この時点で、最初に疑うのは個別設定です。

権限が足りないのではないか。
出力先バケットのポリシーが変わったのではないか。
ロググループ名が間違っているのではないか。
対象期間の指定がおかしいのではないか。
Lambdaやシェルの実装に不備があるのではないか。

もちろん、それらの確認は必要です。

しかし、調べていくと、原因はもっと上位の設計にありました。

何が問題だったのか

問題は、CloudWatch Logsのログエクスポートには、AWS側の制約があるという点です。

CloudWatch Logsのログエクスポートでは、CreateExportTaskを使って、ロググループのログをS3へ出力します。

このExportTaskには制約があります。

1つのAWSアカウント、1つのリージョンにつき、アクティブなExportTaskは1つしか持てません。

ここでいうアクティブとは、実行中または保留中の状態です。

つまり、あるログエクスポートタスクがまだ実行中、または開始待ちの状態で残っている場合、同じアカウント・同じリージョン内で次のエクスポートタスクを作成しようとしても失敗する可能性があります。

これはAWS公式ドキュメントにも記載されているCloudWatch Logsのクォータです。

これが盲点でした。

1つのシステムだけを見ていると、この問題は見えにくいです。

1つのロググループを対象にしている。
手動で1回だけ実行する。
単体テストで1回だけエクスポートする。

この条件なら、正常に見えます。

しかし、同じAWSアカウントの同一リージョンの中に複数システムが存在し、それぞれが日次でCloudWatch Logsのエクスポートを実行していると、話が変わります。

Aシステムのログエクスポートが実行中。
そのタイミングで、Bシステムのログエクスポートが起動する。
さらに、Cシステムのログエクスポートも同じ時間帯に起動する。

それぞれのジョブは、単体で見れば正しい。

しかし、アカウント全体で見ると、同時に実行できない処理が重なっている。

これでは失敗します。

ジョブの中身が間違っていなくても、AWSサービスの制約に引っかかるからです。

個別には正しい。
しかし、共通のAWSアカウント／リージョン側で競合する。

今回の問題は、まさにここでした。

原因

「AWSの制約でした」で終わらせてはいけません。

それは調べれば分かる話です。

実務で問うべき原因は、もう一段深いところにあります。

それは、AWSサービスの制約を、設計時点でジョブ設計・スケジュール設計・テスト設計に落とせていなかったことです。

AWSの制約そのものは障害ではありません。
AWSが壊れていたわけではありません。
CloudWatch Logsが異常だったわけでもありません。

仕様どおりに動いていただけです。

問題は、その仕様を使う側が、運用条件に織り込めていなかったことです。

特に、複数システムを1つのAWSアカウントに載せる場合、各システムが独立してジョブを設計すると、こういう問題が起きます。

Aシステムの担当者は、Aシステムのログエクスポートだけを見る。
Bシステムの担当者は、Bシステムのログエクスポートだけを見る。
Cシステムの担当者は、Cシステムのログエクスポートだけを見る。

個別に見ると、それぞれの設計は間違っていない。

しかし、アカウント全体で見ると、同時実行できないジョブが同じ時間帯に並んでいる。

この状態では、本番運用で失敗します。

打った対策と運用の設計観点

対策を考えるときに、単純に「エラーになったらリトライすればよい」と考えるのは危険です。

もちろん、リトライは必要です。

しかし、何も考えずにリトライを入れると、別のシステムのExportTaskがまだ完了していない状態で、同じ失敗を繰り返すだけになります。

今回考えるべき対策は、少なくとも次の3つです。

1つ目は、ログエクスポートジョブの実行時間をずらすことです。

同じAWSアカウント・同一リージョン内で複数システムがCloudWatch Logsのエクスポートを行う場合、各ジョブの起動時刻を重ねないようにする必要があります。

たとえば、以下のように時間帯を分けます。

変更前：
01:00 Aシステム ログエクスポート
01:00 Bシステム ログエクスポート
01:00 Cシステム ログエクスポート

変更後：
01:00 Aシステム ログエクスポート
02:00 Bシステム ログエクスポート
03:00 Cシステム ログエクスポート

ただし、これは最低限の対策です。

2つ目は、ExportTaskの状態を確認してから、次のタスクを作成することです。

ログ量が多い日には、前のエクスポート処理が想定より長引くことがあります。
障害や遅延により、前日のタスクが残っていることもあります。
単純に時刻をずらしただけでは、処理時間の変動に対応できません。

そのため、既存のExportTaskの状態を確認し、実行中または保留中のタスクがある場合は、待機する、スキップする、後続へ回す、といった制御が必要になります。

処理の流れとしては、以下のような形です。

1. 既存のExportTaskを確認する
2. RUNNINGまたはPENDINGのタスクがあれば待機する
3. 一定時間待っても完了しなければスキップまたは異常終了する
4. 実行可能な状態であれば新しいExportTaskを作成する
5. 作成したタスクIDを記録する
6. 完了状態を確認する
7. 失敗時はリトライまたは運用通知する

ここで重要なのは、ジョブの成功条件を「APIを呼べたこと」にしないことです。

CreateExportTaskを呼び出せた。
タスクIDが返ってきた。
だから成功。

これだけでは不十分です。

運用上は、実際にエクスポートが完了し、S3に期待したログが出力されていることまで確認する必要があります。

3つ目は、失敗時の運用を決めておくことです。

エクスポートに失敗した場合、翌日にまとめて再実行するのか。
対象期間を分割して再実行するのか。
失敗したロググループだけを再実行するのか。
運用担当者にアラートを出すのか。
一定回数までは自動リトライするのか。
リトライしても失敗した場合、誰が判断するのか。

ここまで決めて、初めて運用ジョブの設計になります。

「毎日1時にジョブを起動する」だけでは、設計として足りません。

「その時間に実行してよい状態か」
「実行できなかった場合にどう扱うか」
「ログ欠損や二重出力をどう防ぐか」

ここまで考える必要があります。

失敗時の設計観点は、最低でも次のように整理します。

・リトライ回数
・リトライ間隔
・再実行対象期間
・二重出力の扱い
・ログ欠損時の対応
・通知先
・運用手順書への記載

ジョブは、処理を起動するだけではありません。

失敗したときに、運用担当者が判断できる状態にしておくところまで含めて、ジョブ設計です。

補足：そもそもExportTaskでよかったのか

ここまでの対策は、CloudWatch LogsのExportTaskを使い続ける前提の話です。

しかし、設計としては、そもそもS3へ日次エクスポートする方式でよかったのか、という確認も必要です。

障害調査や一時的なログ検索が目的であれば、CloudWatch Logs Insightsで足りるケースもあります。
CloudWatch Logsにログを保持し、必要なときに検索・分析できれば、必ずしもS3へエクスポートしなくてよい場合があります。

一方で、長期保管、監査対応、CloudWatch Logsの保持期間外の保存、S3を前提にしたログ管理が必要であれば、S3への保存は必要になります。

その場合も、日次のExportTaskだけが選択肢ではありません。

リアルタイム性が必要な場合や、ExportTaskの同時実行制約を避けたい場合は、CloudWatch LogsのサブスクリプションフィルターからAmazon Data Firehoseへ連携し、Firehose経由でS3へ配信する構成も検討対象になります。

つまり、対策は「ExportTaskの起動時間をずらす」だけではありません。

ログの用途、保存期間、検索頻度、監査要件、リアルタイム性、コスト、運用負荷を踏まえて、そもそものログ保存方式を選ぶ必要があります。

今回のようなトラブルは、単にジョブを直すだけでなく、ログ運用方式そのものを見直すきっかけにもなります。

テスト工程で見るべきだったこと

今回の話で重要なのは、設計だけではありません。

テスト工程でも、見方を間違えるとこの問題は見逃されます。

単体テストでは、CloudWatch LogsからS3へエクスポートできるかを確認します。

これは必要です。

ロググループを指定する。
対象期間を指定する。
S3バケットに出力される。
IAMロールで実行できる。
エラー時にログが出る。

ここまでは確認します。

しかし、単体テストで1回エクスポートが成功しても、本番運用で問題なく回ることは保証できません。

結合テストでは、ジョブスケジューラから起動できるか、LambdaやシェルからAWS APIを呼べるか、S3に出力されるか、異常時に通知されるかを確認します。

これも必要です。

しかし、それでもまだ足りません。

システムテストや運用テストでは、実際の運用に近い条件で確認する必要があります。

たとえば、次のような観点です。

・同じAWSアカウント内に複数システムが存在する
・同一リージョン内で複数のログエクスポートジョブが日次で動く
・ログ量が多い日にExportTaskの完了が遅れる
・前日のExportTaskが残っている状態で翌日のジョブが起動する
・他システムのExportTask実行中に自システムのジョブが起動する
・失敗した場合に再実行すると対象期間が重複する
・スキップした場合にログ欠損が起きる
・運用担当者が失敗に気づける
・通知を受けた担当者が、何を見て判断すればよいか分かる

ここまで見ないと、運用ジョブとしての品質は確認できません。

「1回エクスポートできた」ことと、
「毎日、運用として成立する」ことは別です。

これは、テスト工程で非常に重要な考え方です。

機能確認だけなら、1回エクスポートできれば合格に見えます。

しかし、運用確認として見るなら、複数システム、複数ジョブ、ログ量増加、遅延、再実行、通知、手順まで確認しなければいけません。

テスト工程は、単に「作ったものが動くか」を見る工程ではありません。

設計した運用が、実際の条件で破綻しないかを確認する工程です。

クラウドでも設計は省けない

今回の気づきは、CloudWatch LogsのExportTask制約そのものではありません。

それは調べれば分かります。

本当の気づきは、クラウドサービスを使う場合、設計対象は自分たちが作った処理だけではないということです。

AWSのマネージドサービスを使うと、OSやミドルウェアを自分たちで管理しなくてよい部分が増えます。

それは大きなメリットです。

しかし、その代わりに、サービスごとの仕様、クォータ、非同期処理、状態遷移、リトライ設計、料金体系を理解する必要があります。

CloudWatch Logsのエクスポートも同じです。

画面上は簡単に見えます。
APIも用意されています。
S3へ出力できるので、仕組みとしてはシンプルに見えます。

しかし、実運用では、同時実行数、処理時間、ログ量、再実行、監視、通知まで考える必要があります。

クラウドだから簡単になる部分はあります。

しかし、クラウドだから設計しなくてよい、という話ではありません。

むしろ、クラウドサービスの仕様を知らないまま設計すると、オンプレとは別の形で詰まります。

オンプレでは、サーバ、ディスク、ネットワーク、ジョブスケジューラ、ミドルウェアの制約を見ていました。

クラウドでは、そこにAWSサービスごとの制約が加わります。

サービスを使うだけなら簡単です。

しかし、業務システムとして運用するなら、サービスの制約まで含めて設計する必要があります。

再発防止として見るべきこと

同じ問題を繰り返さないためには、個別ジョブを修正するだけでは不十分です。

今回のような問題は、担当者がCloudWatch LogsのExportTask制約を知っていれば防げます。
しかし、知らない人が設計すれば、また同じことが起きます。

だからこそ、個人の知識や注意力に頼るのではなく、設計レビューやテスト計画の観点として残しておく必要があります。

以下は、設計レビューやテスト計画にそのまま転用できる形で整理したチェックリストです。

・使用するAWSサービスのクォータを確認したか
・アカウント単位、リージョン単位の制約を確認したか
・同一アカウント内の他システムと競合しないか
・同一リージョン内で競合するジョブがないか
・同時実行できない処理を並列に起動していないか
・ジョブの起動時刻だけでなく、完了時刻も考慮したか
・処理時間が長引いた場合の後続影響を確認したか
・前回処理が残っている場合の動作を決めたか
・リトライ時に二重処理やログ欠損が起きないか
・スキップ時にどのように検知するか決めたか
・失敗時に誰が、どの通知で、何を見て判断するか
・運用手順書に再実行方法を記載したか
・運用テストで複数システム同時稼働を確認したか

このような観点を、設計レビューやテスト計画に入れておく。

それが再発防止のために見るべきことです。

今回のような問題は、担当者個人の注意力だけに頼ると再発します。

CloudWatch LogsのExportTask制約を知っている人がいれば防げる。
知らない人が設計するとまた起きる。

それでは、組織として弱いです。

だから、レビュー観点にする。
テスト観点にする。
運用設計のチェックリストにする。

これが、実務では必要になります。

若手SEに伝えたいこと

若手SEのうちは、どうしても「処理が動くか」に意識が向きます。

コマンドが成功した。
APIが通った。
S3にファイルが出た。
ジョブが正常終了した。

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

しかし、実務ではそれだけでは足りません。

本番では、他のシステムも動いています。
他のジョブも動いています。
ログ量も日によって変わります。
AWSサービス側の制約もあります。
障害時には再実行もあります。

だから、設計では「単体で動くか」だけでなく、「運用全体の中で成立するか」を見なければいけません。

CloudWatch Logsのログエクスポート失敗は、小さなトラブルに見えるかもしれません。

しかし、ここには大事な教訓があります。

ジョブは、処理単体ではなく、運用全体で設計する。

そして、

テストは、機能確認ではなく、運用で破綻しないことを確認する工程である。

この視点がないと、クラウドでもオンプレでも、同じように運用で詰まります。

AWSを使うこと自体は難しくありません。

しかし、AWSを使って業務システムを安定運用するには、サービス仕様、制約、ジョブ設計、監視、再実行、テスト工程までつなげて考える必要があります。

「1回動いたから大丈夫」

この考え方が、本番運用では一番危ないです。

単体で動くことと、運用で回ることは違います。

この違いを理解しているかどうかが、実務のSEとしてかなり大きな差になります。

今回の話は、単なるCloudWatch Logsの制約の話ではなく、
「ジョブ単体では動く」ことと、
「本番運用で毎日回る」ことは別物である、という話でもあります。

このあたりは、以下の記事でも詳しく書いています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

クラウドリフトでは、既存サーバをAMI化し、そこからEC2を作成することがあります。

オンプレミスのサーバ更改でいえば、既存環境を複製して、新しい環境で起動するようなイメージです。

一見すると、とても便利です。

OS、ミドルウェア、設定ファイル、アプリケーション、ディレクトリ構成などを、元の環境に近い状態で再現できます。

そのため、クラウド移行では、

と思いがちです。

しかし、ここに落とし穴があります。

EC2は起動できる。
EBSボリュームも作成できる。
別のEC2へアタッチもできる。

それなのに、OS上で期待どおりにマウントできないことがあります。

今回扱うのは、AMIコピーやスナップショットから復元したEBSを、既存EC2にアタッチしてデータ復旧しようとしたときに起きたトラブルです。

何が起きたのか

過去のAMIバックアップからデータを復旧したい場面がありました。

やろうとしたことは、よくある復旧作業です。

1. 過去のAMIまたはスナップショットからEBSを復元する

2. 復元したEBSを既存のEC2にアタッチする

3. OS上でマウントする

4. 必要なファイルを取り出す

クラウド環境では、障害調査や復旧作業でよく出てくる手順です。

EBSはAWS上では問題なく作成できました。
既存EC2へのアタッチもできました。
OS上でもディスクとして見えていました。

ところが、いざマウントしようとすると失敗しました。

たとえば、以下のようにデバイスを直接指定してマウントしようとします。

mount /dev/xvdf2 /mnt

すると、次のようなエラーになります。

mount: /mnt: unknown filesystem type 'LVM2_member'

ここが今回のポイントです。

OSから見ると、/dev/xvdf2 はそのままマウントできるXFSやext系のファイルシステムではありませんでした。

LVM2_member として認識されています。

つまり、直接マウントしようとしていた対象は、ファイルシステムそのものではなく、LVMの物理ボリュームとして扱われる領域だったということです。

原因は「EBSが壊れていた」ではない

この手のエラーを見ると、最初はこう考えがちです。

EBSの復元に失敗したのではないか。
スナップショットが壊れているのではないか。
デバイス名を間違えたのではないか。

もちろん、それらも確認すべきです。

しかし今回の本質は、EBSそのものが壊れていたことではありません。

原因は二つあります。

一つ目は、直接マウントしようとした対象が LVM2_member だったことです。

二つ目は、同じAMIを元にしたインスタンス同士で、ディスクやボリューム管理情報の識別子が競合したことです。

AMIからEC2を作ると、OSの中身も含めて複製されます。

ファイルシステムのUUID、LVMのボリューム情報、/etc/fstab の記述、デバイス構成の前提なども、元の環境を引き継ぎます。

そのため、同じAMIを元にしたEC2に、同じ系統のAMIやスナップショットから復元したEBSをアタッチすると、OSから見た識別情報が競合することがあります。

作業者としては、

です。

しかしOS側から見ると、同じような識別情報を持つボリュームが複数見えている状態になります。

AWS上ではEBSがアタッチできていても、OS上で安全にマウントできるとは限りません。

ここを取り違えると、復旧作業で詰まります。

これはAWSの不具合というより、Linuxのディスク管理、UUID、LVM、fstab の仕組みに基づく動作です。

EBSはクラウド上のブロックストレージですが、最終的にそれをどう認識し、どうマウントするかはOS側の話になります。

なぜ LVM2_member になるのか

Linuxでは、ディスク上に直接ファイルシステムが作られている場合もあれば、LVMを使ってボリューム管理している場合もあります。

単純な構成であれば、パーティションにXFSなどのファイルシステムがあり、そのパーティションを直接マウントできます。

一方、LVMを使っている場合、物理ディスクやパーティションは、まずLVMの物理ボリュームとして扱われます。

その上にボリュームグループがあり、さらに論理ボリュームが作られ、その論理ボリューム上にファイルシステムがあります。

つまり、LVM構成では、次のような階層になります。

この場合、LVMの物理ボリュームを直接 mount しても、ファイルシステムとして認識できません。

そのため、

unknown filesystem type 'LVM2_member'

となります。

これは、OSが対象を見失っているというより、

という意味に近いです。

たとえば、blkid で見ると、対象パーティションが次のように見えることがあります。

blkid /dev/xvdf2

/dev/xvdf2: UUID="xxxxx" TYPE="LVM2_member"

この状態で /dev/xvdf2 を直接 mount しても、XFSやext系のファイルシステムとしては扱えません。

UUIDの競合も見落としやすい

もう一つ重要なのがUUIDです。

Linuxでは、ディスクやパーティションを /dev/xvdf、/dev/xvdf1、/dev/nvme1n1p1 のようなデバイス名で扱うことがあります。

しかし、クラウド環境ではデバイス名だけを信じると危険です。

AWSコンソール上で指定したデバイス名と、OS上で見えるデバイス名が直感どおり一致しないことがあります。

さらに、AMIやスナップショットから復元したボリュームでは、ファイルシステムUUIDやLVM関連の識別情報が元の環境と同じまま残ることがあります。

そのため、同じAMI由来のボリュームを同じ系統のEC2にアタッチすると、UUIDやボリューム管理情報が競合し、どのボリュームをマウントすべきかが分かりにくくなります。

ここで必要なのは、勘でデバイス名を指定することではありません。

OSが実際にどう認識しているかを確認することです。

たとえば、以下のようなコマンドで確認します。

lsblk
blkid
ls -l /dev/disk/by-uuid

これらを使って、次の情報を確認します。

• どのデバイスが追加ボリュームなのか

• どのパーティションにファイルシステムがあるのか

• LVM2_member として見えているのか

• どのUUIDがどのデバイスに対応しているのか

• 既存ボリュームと識別情報が競合していないか

どう対処したのか

今回の対処の核心は、同じAMI由来ではない作業用EC2を用意し、そこに復元EBSをアタッチしてマウントするという点です。

狙いは、同じAMI由来のOSボリュームと復元ボリュームを同じEC2上に同居させることで起きる、UUIDやLVM関連の識別情報の競合を避けることです。

ここでいう「別のEC2を用意する」とは、LVM2_member が自動的にマウントできるようになる、という意味ではありません。

そのうえで、OS上で lsblk、blkid、/dev/disk/by-uuid を確認し、どの領域が直接マウントできるファイルシステムなのか、どの領域が LVM2_member なのかを切り分けました。

LVM構成を維持したまま確認したい場合は、pvscan、vgscan、vgchange -ay でボリュームグループを有効化する方法や、複製されたLVMボリュームを別物として扱う vgimportclone を使う方法もあります。

また、既存EC2上で対応せざるを得ない場合は、mount -o nouuid で一時的に参照する方法もあります。

ただし、これらは環境と目的によって適否が分かれます。

今回は復旧対象のファイルを一時的に安全に取り出すことが目的だったため、作業用EC2を用意し、UUIDで対処する方針を採りました。

具体的な手順は以下のとおりです。

まず、/dev/disk/by-uuid でUUIDとデバイスの対応を確認します。

ls -l /dev/disk/by-uuid

たとえば、以下のように表示されます。

lrwxrwxrwx. 1 root root 11 Feb 16 07:47 1c5999b9-594d-40aa-84d2-167a92a977c5 -> ../../xvdf1
lrwxrwxrwx. 1 root root 11 Feb 16 07:46 949779ce-46aa-434e-8eb0-852514a5d69e -> ../../xvda2

この例では、xvdf1 がアタッチした復元ボリューム、xvda2 が既存のルートボリュームとして見えています。

次に、/etc/fstab にマウント先を追記します。

# fstab.new（変更後）
UUID=949779ce-46aa-434e-8eb0-852514a5d69e /      xfs  defaults  0 0
UUID=1c5999b9-594d-40aa-84d2-167a92a977c5 /mnt   xfs  defaults  1 1

そのうえで、マウントを実行します。

mount -a

最後に、マウント先の中身を確認して、意図したボリュームであることを確認します。

cat /mnt/etc/hostname

この確認により、単にマウントできたかどうかだけでなく、本当に目的のボリュームを参照できているかを確認できます。

クラウドリフトでは「コピーできた」と「運用できる」は違う

クラウドリフトでよくある誤解があります。

AMIを作れた。
EC2が起動した。
EBSもアタッチできた。
だから移行できている。

もちろん、これらは重要です。

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

本当に確認すべきなのは、移行後に必要な運用作業ができるかです。

たとえば、障害時に旧ボリュームを別EC2にアタッチして中身を確認できるか。
/etc/fstab の記述は移行後の構成に合っているか。
デバイス名だけに依存せず、UUIDで対象を識別できるか。
LVM構成なら、LVMとして認識・有効化できるか。

こうした確認が抜けると、本番障害時に困ります。

通常時は問題なく動いているように見えても、いざ障害調査や復旧作業をしようとしたときに、

となります。

クラウドリフトでは、このような運用時の確認観点が後回しになりがちです。

事前にどうチェックすべきだったのか

チェックリストとして最小限に絞るなら、見るべきポイントは次の4つです。

1. OSのディスク構成を確認する

ルートボリュームはどれか。
追加ボリュームはどれか。
パーティション構成はどうなっているか。
ファイルシステムは何か。
LVMを使っているか。
UUIDは何か。
/etc/fstab はどう書かれているか。

クラウドリフトでは、EC2を起動できるかだけでなく、移行後のOS内部構成まで確認する必要があります。

2. LVM構成か、直接マウント可能なファイルシステムかを確認する

lsblk や blkid で、対象がXFSなどのファイルシステムなのか、LVM2_member なのかを確認します。

LVM2_member であれば、直接 mount する対象ではありません。

LVMとして認識させるのか、UUIDでマウント対象を指定するのかを、OS構成に応じて判断する必要があります。

3. UUIDの対応を確認する

/dev/disk/by-uuid を確認し、どのUUIDがどのデバイスを指しているかを確認します。

同じAMI由来のボリュームを扱う場合は、UUIDやボリューム管理情報の競合に注意します。

デバイス名だけで判断せず、UUID、ファイルシステム、マウント先の対応を確認します。

4. 復旧手順として事前に試す

設計書や手順書に「EBSをアタッチしてマウントする」と書いてあっても、本当にできるとは限りません。

別EC2にEBSをアタッチする。
OS上でデバイスを確認する。
UUIDを確認する。
必要に応じてLVM構成を確認する。
マウントして中身を確認する。
作業後にアンマウントする。

ここまで一度試しておくべきです。

復旧手順は、障害が起きてから初めて実行するものではありません。

これは詳細設計・運用設計の問題である

今回の話は、EBSをマウントできなかったという作業トラブルに見えます。

しかし、本質は詳細設計・運用設計の問題です。

クラウドリフトでAMIやEBSを扱うなら、設計時点で少なくとも以下を決めておく必要があります。

• 移行後のEBS構成

• OS上のデバイス認識

• LVMを使っているかどうか

• ルートボリュームと追加ボリュームの識別方法

• UUIDの確認方法

• /etc/fstab の記述方針

• 障害時に別EC2へアタッチして確認する手順

• マウント確認後に何を見て正常と判断するか

これらは、運用当日に作業者が感覚で判断するものではありません。

設計書、運用設計書、作業手順書、復旧手順書に落としておくべき内容です。

特に、構築担当者と運用担当者が分かれているプロジェクトでは、この問題が起きやすくなります。

構築担当者は、「AMIからEC2は起動した」「EBSも作成できた」と考える。

一方、運用担当者は障害時に、「復元したEBSをどのEC2にアタッチし、どのUUIDを見て、どのディレクトリにマウントし、何を確認すればよいのか」で迷う。

この間を埋めるのが、詳細設計と運用設計です。

「EC2が起動した」ことと、「運用できる」ことは違います。

「EBSがアタッチされた」ことと、「安全にマウントできる」ことも違います。

この違いを設計で潰しておくことが重要です。

まとめ

AMIコピーやスナップショット復元で作成したEBSは、AWS上でアタッチできていても、OS上でそのまま期待どおりにマウントできるとは限りません。

今回の事象では、直接マウントしようとした対象が LVM2_member であり、さらに同じAMI由来のボリューム識別情報が競合していたことが問題でした。

対処の核心は、同じAMI由来ではない作業用EC2を用意して、そこに復元EBSをアタッチすることです。

そのうえで、/dev/disk/by-uuid を確認し、実際にマウント対象となるファイルシステムのUUIDを指定してマウントしました。

作業前には、lsblk、blkid、/dev/disk/by-uuid で、OSが対象ボリュームをどう認識しているかを必ず確認します。

デバイス名だけで判断せず、UUID、ファイルシステム、マウント先の対応を確認してから作業に入ることが重要です。

クラウドリフトで本当に大事なのは、サーバをクラウド上で起動することだけではありません。

移行後に、調査できること。
復旧できること。
運用できること。

ここまで確認して初めて、クラウドリフトは現場で使えるものになります。

関連記事

この考え方については、以下の記事でも整理しています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

「これで設定完了です」

そう報告したあと、OSを再起動したら設定が戻っていた。
クラウド環境でインスタンスを再作成したら、同じ設定が入っていなかった。

インフラ構築では、こういうことが起きます。

特に危ないのは、作業直後には正しく見えるケースです。

コマンドを実行した。
設定値も変わった。
疎通もできた。

だから大丈夫だと思っていた。

しかし、再起動後、AMI化後、インスタンス再作成後、DHCP更新後に設定が戻る。

本番運用でこれが起きると、単なる作業ミスでは済まなくなります。

今回は、MTU設定を題材にします。

MTUとは、ネットワークで一度に送れるパケットサイズの上限です。

通常のWebシステムでは、普段あまり意識しないかもしれません。
しかし、クラウド環境、VPN、Direct Connect、閉域接続、ジャンボフレーム、オンプレからクラウドへの移行などが絡むと、MTUは設計・構築・試験で確認すべき項目になります。

今回のトラブルは、次のようなものでした。

RHEL7の環境では、NetworkManager を使ってMTUを設定していた。
ところが、Amazon Linux 2の環境では、同じように設定しようとしても、RHEL7と同じ前提では作業できなかった。

つまり、RHELで使っていた設定手順を、そのままAmazon Linux 2に横展開できなかったのです。

何が起きたのか

ある環境で、ネットワークインターフェースのMTU値をカスタマイズする必要がありました。

RHEL7の環境では、次のように nmcli を使って設定していました。

nmcli c modify "My favorite connection" ethernet.mtu 1600

nmcli は、NetworkManagerを操作するためのコマンドです。

NetworkManagerが管理している接続設定に対して、MTU値などを変更できます。

この場合、設定内容は結果的に以下のようなファイルにも反映されます。

/etc/sysconfig/network-scripts/ifcfg-XXXX

そのため、RHEL7で構築経験がある人からすると、

「MTUを変えるなら、nmcli で設定すればよい」

という感覚になりがちです。

しかし、今回のAmazon Linux 2環境では、同じ前提が成り立ちませんでした。

RHEL7と同じように NetworkManager.service を前提にした構成ではなく、nmcli 前提の手順をそのまま使うことができなかったのです。

問題は「MTUの設定方法を知らなかったこと」ではない

ここで大事なのは、

「Amazon Linux 2では、このファイルを編集しましょう」

という単純な話ではありません。

本質的な問題は、OSが変わったにもかかわらず、ネットワーク設定の管理方式が同じだと思い込んだことです。

Linuxといっても、すべてが同じではありません。

RHEL、CentOS、Amazon Linux、Ubuntu、Oracle Linuxなど、ディストリビューションが違えば、設定ファイルの場所、サービス管理の考え方、ネットワーク設定の反映方法、標準で有効になっているサービスが変わることがあります。

さらに、同じRHEL系に見えても、バージョンやクラウドイメージの作りによって、デフォルト構成が違うこともあります。

つまり、

「前の案件で動いた」
「RHELではこうだった」
「Linuxだから同じだろう」

という判断は、インフラ構築では危険です。

なぜこういうことが起きるのか

オンプレミス環境のLinuxと、クラウド環境のLinuxでは、サーバの作られ方が違います。

オンプレミスでは、OSをインストールし、ネットワーク設定を作り込み、固定的なサーバとして長期間運用することが多くあります。

一方、クラウド環境では、AMIなどのイメージからインスタンスを起動し、起動時にIPアドレス、ホスト名、鍵情報、ネットワーク関連の初期設定などが自動的に構成されることがあります。

Amazon Linux 2のようなクラウド向けのOSイメージでは、オンプレミスのRHEL環境と同じ管理サービス構成になっているとは限りません。

そのため、NetworkManagerだけでなく、network service、DHCP、cloud-init、AMI作成時の状態など、複数の仕組みが関係する場合があります。

今回の環境では、RHEL7で使っていたNetworkManager前提の設定手順を、そのまま使える構成ではありませんでした。

見るべきポイントは、

「どのOSか」

だけではありません。

より正確には、

「そのOSイメージでは、ネットワーク設定を何が管理しているのか」

です。

ここを確認せずに手順を横展開すると、設定が反映されない、再起動後に戻る、別インスタンスでは挙動が違う、というトラブルにつながります。

なお、Amazon Linux 2023では、さらに事情が変わります。

AWS公式ドキュメントでは、AL2023では `systemd-networkd` がネットワークインターフェースを管理し、AL2で使われていた `dhclient` から変更されていると説明されています。

つまり、Amazon Linux 2で確認した手順も、Amazon Linux 2023にそのまま横展開できるとは限りません。

RHEL7ではNetworkManager、Amazon Linux 2では別の見方が必要だった

今回の差分を簡単に整理すると、以下のようになります。

RHEL7では、NetworkManagerがネットワーク設定の中心になっている環境があります。

その場合、nmcli で接続プロファイルを変更することが自然な方法になります。

一方で、Amazon Linux 2では、環境によってはNetworkManagerを前提にできません。

そのため、インターフェース設定ファイルやDHCPクライアント設定、起動時にネットワーク設定へ関わる仕組みを確認する必要があります。

たとえば、インターフェース側では以下のような設定ファイルを確認します。

/etc/sysconfig/network-scripts/ifcfg-eth0

MTU値を指定する場合、環境に応じて次のような設定を追加・変更します。

MTU=1600

さらに、DHCPでネットワーク設定を取得している場合は、DHCPクライアント側の設定も確認対象になります。

/etc/dhcp/dhclient.conf

ここで出てくるコマンドやファイルパスを、すべて丸暗記する必要はありません。

大事なのは、個別のコマンドを覚えることではなく、

「誰がネットワーク設定を管理しているのか」
「どこに書けば再起動後も残るのか」
「何に上書きされる可能性があるのか」

という構造を押さえることです。

この図で見てほしいのは、設定値の違いではありません。

同じMTU設定でも、RHEL7ではNetworkManager経由、Amazon Linux 2では設定ファイルやDHCP関連の確認が中心になる、という設定経路の違いです。

一番怖いのは、設定できたように見えてしまうこと

この手のトラブルで怖いのは、最初から完全に失敗してくれるとは限らないことです。

コマンドが存在しない。
サービスが存在しない。
設定ファイルが見つからない。

ここまで分かりやすく失敗してくれれば、まだよいです。

問題は、設定したつもりになっているケースです。

たとえば、次のようなコマンドで確認したとします。

ip link show eth0

その時点では、MTUが変わっているように見える。

しかし、ネットワークサービスを再起動すると戻る。
OSを再起動すると戻る。
AMIから再作成すると戻る。
DHCP更新後に戻る。
別のインスタンスでは挙動が違う。

この場合、作業者の感覚としては、

「設定したのに戻った」
「なぜか環境によって違う」
「手順通りにやったのに再現しない」

となります。

しかし、原因はシンプルです。

その設定が、永続化される場所に入っていなかった。
または、
永続化したつもりの設定が、別の仕組みに上書きされていた。

作業直後に設定値が変わることと、運用中もその設定が維持されることは、別の話です。

設定確認は「今」だけで終わらせない

MTU設定後に ip link show eth0 で確認することは必要です。

しかし、それは「今そうなっている」ことを見ているだけです。

インフラ構築では、設定直後だけでなく、network再起動後、OS再起動後、AMI化・再作成後、DHCP更新後まで確認します。

• 設定直後にMTUが変わっているか

• network再起動後も維持されるか

• OS再起動後も維持されるか

• AMI化・再作成後も維持されるか

• DHCP更新後に戻らないか

この図で伝えたいのは、「今変わっているか」だけでなく、戻らないかまで見る必要がある、ということです。

このトラブルを防ぐための確認観点

1. ネットワーク設定の管理方式を確認する

対象OSでネットワーク設定を何が管理しているかを最初に確認します。

systemctl status NetworkManager
systemctl status network
ls -l /etc/sysconfig/network-scripts/
cat /etc/sysconfig/network-scripts/ifcfg-eth0

見るべきなのは、コマンドが使えるかどうかだけではありません。

そのサービスがOS起動時に使われているか。
対象インターフェースを管理しているか。
設定ファイルの内容と実際の状態が合っているか。

ここまで確認します。

2. 一時設定と永続設定を分ける

MTUは、一時的に変更するだけなら次のようなコマンドでも変更できます。

ip link set dev eth0 mtu 1600

しかし、これは基本的に一時的な変更です。

OS再起動後に維持されるかは別問題です。

一時設定で確認するのか。
永続設定として設計するのか。

ここを混同すると、構築時は動いていたのに、本番運用で戻るということが起きます。

3. DHCPやcloud-initによる上書きを確認する

クラウド環境では、OSが起動した後に、DHCPやcloud-initなどがネットワーク設定に関わることがあります。

そのため、設定ファイルに値を書いただけでは不十分な場合があります。

確認すべきことは、たとえば次のような点です。

• DHCPで取得した設定によりMTUが上書きされないか

• dhclient.conf で明示的な設定が必要か

• cloud-initが起動時にネットワーク設定を生成・変更していないか

• AMI化した後、別インスタンスで同じ設定が再現されるか

さらに対策として、手作業で変更した内容を、AMI作成手順、構築手順、構成管理、または自動構築の仕組みに反映しておく必要があります。

詳細設計と構築手順では「設定値」だけでなく「反映と確認」まで書く

詳細設計書に、

とだけ書いてあったとします。

設定値だけでは、構築する側は判断できません。
少なくとも次の情報が必要です。

対象OS：
  Amazon Linux 2

対象インターフェース：
  eth0

設定値：
  MTU=1600

設定箇所：
  /etc/sysconfig/network-scripts/ifcfg-eth0

DHCP設定：
  /etc/dhcp/dhclient.conf の更新要否を確認

反映方法：
  networkサービス再起動、またはOS再起動

確認方法：
  ip link show eth0
  ping疎通
  必要に応じてパケットサイズ指定で疎通確認

永続化確認：
  OS再起動後もMTU値が維持されること
  AMI化・再作成後もMTU値が維持されること
  DHCP更新後にMTU値が戻らないこと

これくらい書いて、ようやく構築・試験できる設計になります。

構築手順書に落とす場合も同じです。

手順書には、設定コマンドだけでなく、変更前確認、変更後確認、再起動後確認、必要に応じてAMI化・再作成後の確認まで含める必要があります。

たとえば、作業の流れとしては次のようになります。

1. 現在のMTU値を確認する
2. 対象インターフェースを確認する
3. ネットワーク設定の管理方式を確認する
4. 設定ファイルやDHCP設定を修正する
5. network再起動またはOS再起動で反映する
6. MTU値を確認する
7. OS再起動後に再確認する
8. 必要に応じてAMI化・再作成後に再確認する

試験項目では「今の設定値」だけを見ない

ip link show eth0 だけでは「今の状態」しか分かりません。
実務では次の観点まで確認します。

特にクラウド環境では、AMI化・再作成後の確認が重要です。

Auto Scalingや障害復旧で新しいインスタンスが起動したときに設定が戻るなら、構築時に確認できていても運用には耐えません。

レビューでは設定値ではなく、設定が残る仕組みを見る

MTU設定の設計書や手順書をレビューするなら、次のような観点で見ます。

• 対象OS・バージョン・対象インターフェースが明記されているか

• 設定箇所と反映方法が明記されているか

• NetworkManager前提か、network service前提かが明記されているか

• DHCP・cloud-initの影響を確認しているか

• OS再起動後の確認があるか

• AMI化・再作成後の確認があるか

「MTU=1600と書いてあるからOK」では、このトラブルは防げません。
設定値ではなく、設定が残る仕組みまで見ることがレビューのポイントです。

まとめ

今回のトラブルは、RHEL7とAmazon Linux 2でMTU設定方法が違っていた、という事例です。

ただし、学ぶべきことは「Amazon Linux 2ではこのファイルを編集する」という単純な話ではありません。

重要なのは、以下です。

• OSが変われば、設定の管理方式も変わる

• コマンドではなく、管理している仕組みを見る

• 設定直後だけでなく、再起動後・再作成後も確認する

• 詳細設計では、設定値だけでなく設定箇所・反映方法・確認方法まで書く

• クラウド環境では、AMI化・再作成後も同じ設定になるかを見る

コマンドを知っていること以上に、その設定がどの仕組みに管理され、再起動後も維持されるのかを確認できること。

この視点が、インフラ構築の品質を分けます。

関連記事

今回の記事で扱った「設定値だけでなく、設定箇所・反映方法・確認方法・永続化確認まで設計に落とす」という考え方は、以下の記事でも整理しています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

Oracle Databaseを19cへ更改した後、最初の年次処理を終えた直後から、一部SQLの性能が急激に悪化し、夜間バッチの処理時間へ影響が及びました。

SQLもアプリケーションも変えていません。統計収集ジョブも実行していません。それにもかかわらず、実行計画だけが変わっていました。

原因は、Oracle 19cで追加された、パーティションメンテナンス時に統計情報が更新される仕様でした。従来から実施していたパーティション削除を契機として表統計の一部だけが更新され、実行計画が変化した結果、SQL性能が悪化していました。

この障害の本質は、Oracleの仕様そのものではありません。非互換情報の確認だけでは捉えられない「新機能による内部動作の変更」が、更改時の影響調査から漏れていたことです。同じ構図の見落としは、OracleでもAWSでもLinuxでも起こり得ます。

本記事では、この事例を題材に、原因調査で確認した証跡、対策の設計判断、更改プロジェクトとして追加すべき影響調査と試験の観点を整理します。

発端は更改後最初の年次処理だった

ある基幹システムでは、Oracle Databaseの更改後、最初の年次処理として保存期間を超えたデータをパーティション削除で整理していました。旧環境から長年継続している定期メンテナンスで、SQL、アプリケーション、運用手順のいずれにも性能へ影響するような変更は加えていません。

年次処理が終了した直後から、一部SQLの応答が悪化し始めました。

最初に疑ったのは、アプリケーション側の変更です。変更履歴を確認しても、性能劣化につながる修正は見つかりません。次に疑ったのは統計情報ですが、運用担当者が対象表へ統計収集を実行した記録もありませんでした。

処理内容もSQLも統計収集も、利用者側は何も変えていない。それでも更改後の環境では、SQLの性能特性だけが変わっていました。

この時点で、利用者側の変更を探す調査は行き詰まりました。残る可能性は、旧バージョンと19cの間で、Oracle内部の動作そのものが変わっていることです。調査の焦点を、アプリケーションからOracleの内部動作へ切り替えました。

Oracle 19cへの更改で顕在化した統計情報の更新

調査を進めた結果、パーティションメンテナンス時にOracleが統計情報を更新する動作が関係していることが分かりました。

この動作は、My Oracle Supportの次の文書でも、Oracle Database 19cにおけるパーティション表の統計情報変更として整理されています。

Partitioned Table Statistics Changed After Truncate Partition or Drop Partition Operation
MOS Doc ID 2970098.1

Oracle Database 19cのSQL Tuning Guideにも、パーティションメンテナンスに伴う統計情報の処理が「Online Statistics Gathering for Partition Maintenance Operations」として記載されています。

ここで区別しなければならないのは、すべてのパーティション操作で同じ統計収集処理が実行されるわけではないことです。

パーティションメンテナンスには、次のような操作があります。

• DROP PARTITION
• TRUNCATE PARTITION
• MOVE PARTITION
• MERGE PARTITION
• COALESCE PARTITION
• SPLIT PARTITION

MOVE PARTITIONやMERGE PARTITIONなど、データの移動やダイレクトパス書き込みを伴う処理では、操作内容に応じてオンライン統計収集が行われる場合があります。

本事例で問題となったDROP PARTITIONでは、DBMS_STATS.GATHER_TABLE_STATSに相当する全統計収集が実行されたわけではありません。パーティション削除に合わせて、グローバル表統計のNUM_ROWSやBLOCKSなどがOracle内部で更新されました。

運用担当者が統計収集ジョブを実行していなくても、統計情報の一部はパーティション操作によって変化します。

「統計情報を収集していない」という運用上の認識と、「統計情報が変化していない」というデータベース上の事実は同じではありません。

この違いを認識していなければ、性能劣化の調査でアプリケーション、SQL、負荷状況だけを追い続け、実行計画を変化させた統計情報の更新を見落とすことになります。

なぜデータを削除した後にSQLが遅くなるのか

この動作は旧環境では発生しておらず、19cへの更改後に初めて顕在化しました。

データを削除すれば処理対象が減るため、SQLも速くなるように思えます。

今回の事象では、パーティション削除後にSQL性能が悪化しました。

原因を理解するには、Oracleのオプティマイザが利用する統計情報を、表統計とカラム統計に分けて考える必要があります。

表統計には、表全体の規模を示す情報が含まれます。代表的な項目はNUM_ROWS、BLOCKS、AVG_ROW_LENです。

カラム統計には、列の値がどのように分布しているかを示す情報が含まれます。代表的な項目には、個別値数を示すNDV、LOW_VALUE、HIGH_VALUE、NULL数、ヒストグラムなどがあります。

DROP PARTITIONを実行すると、削除されたパーティションを反映して、表全体の行数やブロック数を示す統計が更新されます。カラム統計やヒストグラムまで、同じタイミングで整合した状態へ再収集されるわけではありません。

この状態では、オプティマイザが参照する統計情報に異なる時点の情報が混在します。

表統計は、パーティション削除後の表が以前より小さくなったことを示しています。カラム統計は、削除前の値分布を前提とした状態で残っています。

オプティマイザは、表統計とカラム統計を使って、検索条件へ該当する行数を推定します。両者の前提が一致していなければ、カーディナリティ推定が実際のデータ分布から外れる可能性があります。

カーディナリティ推定が変わると、索引を使うか全表走査を選ぶか、Nested LoopsとHash Joinのどちらを使うか、どの表を駆動表とするかといった判断も変わります。結合順序や並列実行の選択まで変化することがあります。

本件では、統計情報が更新されたという事実だけで性能が悪化したのではありません。

表統計の一部だけが更新され、既存のカラム統計との前提が一致しない状態が次回の統計収集まで残った結果、カーディナリティ推定が変化し、従来とは異なる実行計画が選択されました。

たとえば本件では、パーティション削除後にNUM_ROWSが大幅に減少した統計を基に、オプティマイザが従来とは異なるアクセスパスを選択したと推定されます。統計上は小さく見える表に対してIndex Range ScanよりFull Table Scanのコストが低いと判断されたり、結合方式がNested LoopsからHash Joinへ変わったりすることで、実業務データの実際の件数との乖離が性能劣化として現れます。

統計情報の更新は、常に性能改善を意味するものではありません。どの統計が、どの単位で、どの範囲まで更新されたのかを確認しなければ、オプティマイザが参照している情報の状態を正しく把握できません。

調査で確認した証跡

性能障害を説明するには、「パーティションを削除した」「統計情報が変わった」「SQLが遅くなった」という個別の事実だけでは十分ではありません。

重要なのは、それらの出来事が同じ時間軸で発生していることを確認することです。

今回の調査では、AWR、実行計画、統計情報の更新時刻を組み合わせ、原因と結果を時系列で整理しました。

AWRでSQL性能の変化を確認する

最初に確認したのは、AWRに記録されたSQL性能の変化です。

年次処理の終了後から対象SQLの負荷が増加しており、単純に実行回数が増えたのではなく、1回当たりの処理コストそのものが悪化していました。

主に確認した項目は次のとおりです。

• Elapsed Time
• CPU Time
• Buffer Gets
• Disk Reads
• Executions
• Rows Processed

これらは合計値だけでは判断できません。

たとえばElapsed Timeが増加していても、単純に実行回数が増えただけであれば異常とは言えません。

• 1実行当たりのElapsed Time
• 1実行当たりのBuffer Gets

まで確認し、SQLそのものの性能が変化したことを確認しました。

実行計画が変わっていないかを確認する

次に確認したのは実行計画です。

AWRやDBA_HIST_SQLSTAT、DBA_HIST_SQL_PLANを調査すると、対象SQLでは性能悪化前後でPLAN_HASH_VALUEが変化していました。

PLAN_HASH_VALUEが変わるということは、少なくともOracleが異なる実行計画を選択したことを意味します。

もちろん、PLAN_HASH_VALUEだけでは原因を断定できません。

実際には、

• アクセスパス
• 結合方式
• 結合順序
• 推定行数（Cardinality）
• 実際の処理行数

まで確認し、オプティマイザがどの判断を変更したのかを追跡しました。

統計情報はいつ変わったのか

最後に、統計情報そのものを確認しました。

DBA_TAB_STATISTICSを見ると、パーティション削除を実施した時刻を境に、対象表の統計情報が更新されていました。

確認した主な項目は次の三つです。

• NUM_ROWS
• BLOCKS
• LAST_ANALYZED

運用では統計収集ジョブを実行していないにもかかわらず、これらの値はパーティション削除のタイミングで変化していました。

さらに、DBA_TAB_COL_STATISTICSやヒストグラム関連ビューも確認したところ、カラム統計は従来の状態を保持していました。

• 表統計は更新されている
• カラム統計は更新されていない

という状態になっていたことが分かります。

この結果は、前章で説明した「表統計とカラム統計の前提が一致しない状態」が実際に発生していたことを裏付ける証拠となりました。

時系列で整理すると原因が見えてくる

今回の調査結果を時系列で整理すると、次の流れになります。

年次処理でDROP PARTITION
        ↓
Oracle内部で表統計の一部が更新
        ↓
表統計とカラム統計の前提が一致しない
        ↓
オプティマイザのカーディナリティ推定が変化
        ↓
実行計画が変更される
        ↓
PLAN_HASH_VALUEの変化として観測される
        ↓
Elapsed Time・Buffer Getsが増加

この流れは、一つのビューだけを見て導いたものではありません。

パーティション操作の実施時刻、統計情報の更新時刻、実行計画の変化、AWRに記録された性能指標を同じ時間軸へ並べることで、初めて因果関係を説明できます。

性能障害の調査では、「実行計画が変わった」「統計情報が更新された」という個別の事実だけを示しても説得力はありません。

複数の証跡を時系列で結び付けて初めて、性能劣化の原因を論理的に説明できます。

問題はOracleではなく影響調査の範囲だった

Oracleは仕様どおりに動作していました。

本件の問題は、パーティションメンテナンスに伴う統計情報の更新を、更改時の影響調査対象として認識できていなかったことです。

システム更改では、多くの場合、次のような項目を重点的に確認します。

• 非互換情報
• 廃止機能
• Deprecated機能
• 初期化パラメータの変更
• サポート終了機能
• 既知の不具合
• SQL構文やAPIの変更

これらは重要な確認項目です。

新機能については「追加機能だから既存システムには影響しないだろう」と判断され、調査対象から外れてしまうことがあります。

今回見落としていたのは、「従来のSQLが実行できなくなる非互換」ではありませんでした。

従来と同じSQLが正常終了したまま、Oracle内部の統計情報管理だけが変わる仕様変更です。

このような仕様変更は、機能試験だけでは見つかりません。

SQLは正常終了し、処理結果も正しく、エラーログも出力されません。

実行計画や統計情報まで確認して初めて、旧バージョンとの違いが見えてきます。

更改プロジェクトでは「新機能だから影響はない」と考えるのではなく、既存処理の内部動作を変える仕様変更はないかという観点で調査することが重要になります。

このような影響調査は、構築フェーズに入ってから始めるものではありません。クラウドリフトでは、PoCや基本設計の段階で「何を調査対象に含めるか」が品質を大きく左右します。

設計前に確認すべき観点は、次の記事で詳しく解説しています。

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

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

sys-univ.com

2026.08.20

技術的な対策は一つではない

本件のような事象に対して、「統計情報の更新を止めればよい」と考えるのは適切ではありません。

問題は、パーティション削除そのものではなく、統計情報の状態が変化した結果として実行計画が変わることです。

更改設計では

• 統計情報をどのように管理するか
• 実行計画の変化をどこまで許容するか
• 運用でどこまで吸収するか

という三つの観点から設計する必要があります。

パーティションメンテナンス後に統計情報を再収集する

最も直接的な方法は、パーティション削除後にDBMS_STATS.GATHER_TABLE_STATSを実行し、表統計とカラム統計を同じ状態へ揃えることです。

今回の事象では、表統計だけが更新され、カラム統計との前提が一致しない状態が残ったことが実行計画変更の要因でした。

統計情報を再収集すれば、この不整合は解消されます。

統計情報を取得すれば必ず性能が改善するとは限りません。

表全体を再収集するのか、対象パーティションだけで十分なのか、インクリメンタル統計を利用するのかなど、システム特性に応じた設計は必要になります。

重要なのは、「統計情報が更新されたこと」ではなく、「統計情報の整合性をどのように維持するか」という観点で設計することです。

実行計画そのものを安定させる

統計情報を適切に管理しても、データ量や分布は時間とともに変化します。

業務影響が極めて大きいSQLについては、統計情報だけに依存せず、SQL Plan Baselineなどを利用して実行計画を管理する方法もあります。

SQL Plan Baselineは、統計情報の変化そのものを止める機能ではありません。

その代わり、十分に検証された実行計画を維持することで、予期しない計画変更による性能劣化を防ぐ役割を持ちます。

すべてのSQLを固定する運用は現実的ではありません。

長時間バッチや業務影響の大きいSQLなど、対象を限定して利用することが重要です。

Oracle内部動作を変更する方法もある

Oracleには、オンライン統計収集の動作そのものを抑止する方法も存在します。

SQL単位で抑止するのであれば、公式ドキュメントに記載されているNO_GATHER_OPTIMIZER_STATISTICSヒントが利用できます。影響範囲を特定のSQLへ限定できるため、対象処理が明確な場合には検討しやすい選択肢です。

データベース全体で抑止する方法としては、隠しパラメータである_optimizer_gather_stats_on_loadが公開されている技術情報でも言及されています。ただし、このパラメータはパーティションメンテナンス時の統計更新だけではなく、ダイレクトパスロード時を含むオンライン統計収集全体へ影響します。

隠しパラメータは、公開パラメータと同じ感覚で変更できるものではありません。バージョンやRelease Updateによって挙動が異なる可能性があり、適用の可否は自環境の構成を踏まえてOracle Supportへ確認した上で判断すべきです。

今回の事象だけを止めたつもりでも、別のバルクロード処理へ新たな影響を与えることも考えられます。抑止は最初に選ぶ対策ではなく、統計の再収集や実行計画の管理で解決できない場合の最後の選択肢として、影響範囲を十分に評価して使うべきものです。

更改設計として考えるべきこと

この事例で重要なのは、「どの対策が正しいか」を決めることではありません。

最適解はシステムによって異なることに対し、どのようなシステムでも共通する考え方があります。

パーティションメンテナンスによって統計情報が変化するのであれば、その変化を前提とした運用を設計することです。

統計情報を再収集するのか、SQL Plan Baselineで重要SQLを保護するのか、あるいはOracle内部動作まで変更するのか。

その判断は、性能要件、バッチ時間、データ量、運用体制まで含めたシステム設計として決めるべき事項です。

更改プロジェクトで追加すべき試験と運用

今回の教訓は、Oracleのチューニングだけでは終わりません。

本質的な問題は、更改プロジェクトの影響調査にありました。

多くの更改プロジェクトでは、オンライン処理や通常の日次バッチを中心に性能試験を実施します。

年次や月次にしか実行されない処理は、試験対象から外れることがあります。

パーティション削除や履歴データの整理、大量データのアーカイブなどは、その代表例です。

こうした処理は実行頻度が低いため、問題があっても更改直後には表面化しません。

今回のように、更改後最初の年次処理で初めて障害として顕在化することがあります。

更改試験では、本番データを完全に再現できないことも少なくありません。

その場合でも、DDLの実行、統計情報の変化、実行計画の変化までは十分検証できます。

さらに、更改後最初の年次処理や月次処理は通常運用として扱うのではなく、重点監視期間として計画しておくことが重要です。

SQLの実行時間だけを見るのではなく、PLAN_HASH_VALUE、統計情報の更新時刻、AWRの性能指標をあらかじめ比較できる状態にしておけば、異常が発生しても原因へたどり着くまでの時間を大幅に短縮できます。

性能障害は、発生してから調査を始めるよりも、比較するための基準値を更改前から残しておく方がはるかに効率的です。

PoCでは性能確認だけではなく、「更改後に何を比較するか」という観点で証跡を残しておくことが重要です。

PoCで確認すべき項目は、次の記事で詳しく整理しています。

【第2回】クラウドリフトPoCの設計リスク｜可用性・性能・ストレージ・バックアップ・監視

クラウドリフトPoCで「動いた」だけでは、構築・試験・運用まで成立するとは限りません。可用性・性能・ストレージ・バックアップ・監視の5領域について、PoCで確認すべき設計リスクと、見落とした場合の後工程への影響を実務例から整理します。

sys-univ.com

2026.08.25

非互換情報の外側にある変更を見る

この事例は、Oracle Databaseだけに当てはまる話ではありません。

システム基盤の更改では、新しいバージョンへ移行するたびに、ベンダーは性能、運用性、セキュリティ、自動化を目的として既定動作を見直しています。

たとえばAmazon RDSでは、エンジンのバージョンアップに伴って、デフォルトパラメータグループの既定値が変更されることがあります。アプリケーションを変更していなくても、データベース側の既定設定が変われば、性能や動作特性へ影響する可能性があります。

VMware vSphereでも同様です。バージョンアップに伴ってTLSの既定設定が変更され、従来は接続できていた外部システムとの通信へ影響した事例があります。システムが故障したわけではなく、製品側の既定動作が変わったことが原因でした。

Linuxでも、カーネル更新によってメモリ管理やネットワーク関連の既定動作が変更されることがあります。アプリケーションは従来どおり動作していても、OSの内部動作が変わることで性能特性が変化するケースは珍しくありません。

これらに共通しているのは、「何も変更していないのに動作が変わった」のではないという点です。

利用者は変更していなくても、ベンダーは変更しています。

更改プロジェクトでは、自分たちが修正したプログラムや設定だけに目が向きがちです。

実際には、ベンダーが変更した既定動作の方が、既存システムへ大きな影響を与えることがあります。

更改影響調査では「非互換情報」だけを見るのではなく、「既定動作は変わっていないか」という視点を同じ重みで持つ必要があります。

本記事のように、更改後に初めて表面化した仕様変更や設計上の見落としは少なくありません。

クラウドリフトやシステム更改で実際に発生したトラブル事例は、次のマガジンにまとめています。

クラウド移行でハマる、AWS設計・運用の落とし穴｜ナギ ＠ 氷河期SEの知見録｜note

AWSへのクラウド移行やDR設計で見落としやすい、設計・起動・再作成・運用の落とし穴を整理するマガジンです。EC2、AMI、cloud-init、EC2Launch、Auto Scaling、EBS、CloudWatch Logs、S3、AReadMore...

note.com

まとめ

今回の性能障害では、年次処理によるパーティション削除を契機として、Oracle内部で表統計の一部が更新されました。

表統計だけが新しい状態となり、カラム統計との前提が一致しない状態が残った結果、オプティマイザのカーディナリティ推定が変化し、実行計画も変わりました。その結果として、SQL性能が低下しました。

原因を特定できたのは、一つの情報だけを見て判断しなかったためです。

AWRで性能変化を確認し、PLAN_HASH_VALUEで実行計画の変化を追跡し、DBA_TAB_STATISTICSで統計情報の更新時刻を確認しました。それぞれを同じ時間軸へ並べることで、初めて原因と結果を論理的に説明できました。

Oracleは仕様どおりに動作していました。

問題だったのは、パーティション削除に伴う統計情報の更新という仕様変更が、更改時の影響調査対象になっていなかったことです。

更改プロジェクトで確認すべき対象は、非互換情報だけではありません。

新機能、デフォルト設定、バックグラウンド処理、内部アルゴリズムなど、既存システムへ影響を与える可能性のある仕様変更まで含めて評価する必要があります。

システム更改では、「正常終了した」ことだけでは十分とは言えません。

同じSQLが正常終了していても、実行計画や性能特性まで従来と同じとは限りません。

更改で本当に確認すべきなのは、プログラムが動くかではありません。

設計時に置いていた前提が、バージョンアップ後も成立しているかです。

システム更改の品質を左右するのは、コード変更量ではなく、前提条件の変化をどこまで洗い出せるかです。

参考資料

• Oracle Support, Partitioned Table Statistics Changed After Truncate Partition or Drop Partition Operation（MOS Doc ID 2970098.1）
• Oracle Database 19c SQL Tuning Guide（SQL Plan Management）
• Oracle Database 19c PL/SQL Packages and Types Reference（DBMS_STATS）
• Amazon RDS User Guide(DB parameter groups)
• VMware vSphere 8 Release Notes(Security and TLS changes)