古いWebシステムの入口を段階的に守る — CloudflareとAWSによる移行設計
文書番号：2609.00009
要旨
古いWebシステムを全面的に作り直す前に、外部から使える機能と入力を絞る方法を検討するのだ。まずCloudflareとAWSを通信の中継地点に置き、既存の業務を動かしながら利用状況を調べるのだ。次に、注文や検索といった業務ごとに新しいAPIを作り、動作を確かめてから利用者を移し、不要になった古い入口を閉じるのだ。
AIはAPIの仕様、既存システムへの変換処理、試験の案を作る役割を担うのだ。移行できたかどうかは、業務が正しく続けられることと、許可していない経路や操作を拒否できることの両方で判断するのだ。本稿は2026年9月14日時点の公開文書に基づく設計案であり、実装による効果や性能は未測定なのだ。
1. 全面刷新を待たずに、外部から使える機能を絞る
受注や会計を支える古いシステムには、長年の業務規則やデータが蓄積されているのだ。画面だけを変えるつもりでも、夜間処理や他システムとの連携まで影響することがあるのだ。そこで本稿では、内部の処理を維持しながら、外部からの使い方を先に変える方法を考えるのだ。
例えば、注文の登録と確認だけを外部へ提供したい場合を想定するのだ。古い管理画面や不要な処理まで呼び出せる状態から、必要な操作だけを受け付ける状態へ移すのだ。このように攻撃者が触れられる機能や入力の範囲を狭めることを、本稿では「攻撃面の縮小」と呼ぶのだ。
対象は、ブラウザーの画面やフォームで利用するHTTP(S)のWebシステムなのだ。ログイン状態を保つCookieやサーバー側のセッション、複数画面にまたがる処理も対象に含めるのだ。システム内部の脆弱性修正や保守期限への対応は、この移行と並行して進める必要があるのだ。
AWSのStrangler fig patternは、中継するプロキシを置き、新旧の機能を共存させながら少しずつ移す方式なのだ。1 本稿ではこれを、公開する機能を絞るための移行手順へ具体化するのだ。境界を閉じる基本原則は、レガシーシステムは捨てなくていいでも説明しているのだ。
2. 通信を中継し、業務ごとに新しいAPIへ移す
2.1 最初は既存の画面をそのまま使う
最初の段階では、利用者と既存Webの間にCloudflareとAWSを置くのだ。Cloudflareを外部からの入口とし、AWS上のプロキシが通信を既存Webへ中継する設計なのだ。利用者が今までどおりログインし、注文や検索を完了できるかを確かめるのだ。
ここで使う「透明プロキシ」は、既存の業務動作を保つことを目指す中継処理なのだ。通信の全バイトを不変にするという意味ではなく、画面遷移やCookie、ファイル送信などが正常に働くことを試験するのだ。この段階で、すべての画面操作をAPIへ変換する必要はないのだ。
2.2 次に、注文や検索をAPIから呼び出せるようにする
APIは、プログラムから機能を呼び出すための入口なのだ。例えば「商品を選ぶ→注文内容を確認する→確定する」という画面操作を整理し、新しい画面から注文処理を呼び出せるようにするのだ。画面を置き換える範囲は、業務ごとに決めるのだ。
新しいAPIと既存Webでは、データの形式や処理手順が異なるのだ。その間をつなぐため、APIへの要求を既存Webのフォーム送信や画面遷移へ変換する処理を用意するのだ。これをLegacy Adapterと呼び、以降は「変換処理」と表記するのだ。
| 段階 | 利用者から見えるもの | 背後で行うこと |
|---|---|---|
| 通信を中継する段階 | 今までの画面 | CloudflareとAWSを経由して既存Webへ転送 |
| 業務をAPIへ移した段階 | 新しい画面やAPI | 必要な入力を検査し、変換処理を通じて既存Webを実行 |
この二段階に分けると、通信経路を変えた影響と、業務の呼出し方を変えた影響を順に確かめられるのだ。AWSのサービス構成と接続上の条件は、付録にまとめているのだ。
3. 切替前に、業務が続けられることと戻し方を確かめる
通信経路を変える前に、新しい経路でも主要業務を完了できる状態を作るのだ。正常な注文だけでなく、ログインの失敗、注文の取消し、ファイルの送信、途中で接続が切れた場合も確認するのだ。問題が起きたときに、誰がどの条件で元へ戻すかも先に決めるのだ。
| 確かめること | 残しておく記録 |
|---|---|
| 今までの業務を続けられるか | ログイン、検索、更新、取消し、ログアウトの試験結果 |
| 画面と通信の扱いが変わらないか | Host、Cookie属性、転送先URL、文字コード、圧縮、キャッシュ設定の比較 |
| 処理が遅くなりすぎないか | 現在の応答時間・エラー率・業務完了率と、切替後の許容値 |
| 障害が起きた場所を追えるか | 同じ要求を各層のログで追跡できるRequest ID |
| 接続先と証明書が正しいか | 各区間のTLS検証と、必要な宛先・ポートだけへの接続試験 |
| 問題があれば元へ戻せるか | 通信経路、設定、ログイン状態を含む切戻し手順と試験結果 |
| 調査用データを適切に扱えるか | 取得項目、秘密情報の除去、保存期間、AIへの提供範囲、閲覧権限 |
例えば、ログイン後のページを共有キャッシュへ保存する設定は、利用者ごとの情報の扱いに関わるのだ。また、画面から旧ホスト名へ自動転送されると、意図した中継経路を外れる可能性があるのだ。こうした設定は、表示が一見正しい場合も確認するのだ。
切替にはDNS、つまりドメイン名に対応する接続先の設定を使う計画なのだ。ただしDNSを変えても、旧IPアドレスや別名のドメインから直接接続できる場合があるのだ。IPv6や管理画面も含めて入口を一覧にし、いつ制限するかを決めるのだ。
通常の切戻し先は、できるだけCloudflareを通る既存処理の経路として残すのだ。防御を外す緊急復旧が必要な場合は、別の承認、期限、監視を定めるのだ。DNSのキャッシュや接続中の通信があるため、DNSの変更だけで全利用者を即時に戻せるとは限らないのだ。
4. 実際の使われ方を調べ、AIでAPIと変換処理の案を作る
4.1 通信の記録から業務の流れを調べる
注文をAPIへ移すには、どの画面で何を入力し、どの時点で注文が確定するかを知る必要があるのだ。中継地点でURL、操作の種類、入力項目、応答、画面遷移、処理時間を記録し、一連の業務として整理するのだ。
認証情報や個人情報は、必要性を確認した項目だけを取得し、可能な限り収集段階で除去するのだ。本文やCookieを扱う場合は、通常のアクセスログとは別に取得範囲を設計するのだ。AIへ渡す通信内容は分析対象のデータとして扱い、そこに書かれた文章で公開設定や外部送信が実行されないよう、ツールの権限も分けるのだ。
Cloudflare API Discoveryは、通信からAPIの入口を見つける機能なのだ。Schema Learningは、対象となるAPI操作の通信から入力項目や制約を学習する機能なのだ。確認時点では、過去7日間の対象通信を週次処理し、成功を表す2xx応答のリクエストを利用するのだ。23 既存Webの画面遷移がどの業務を意味するかは、別途整理する必要があるのだ。
4.2 通信が成功していても、正しい仕様とは限らない
ログイン済みの利用者による成功した通信は、調査の手掛かりになるのだ。一方で、権限の悪用やシステムが誤って受理した入力も含まれ得るのだ。観測できた通信をそのまま許可する仕様にせず、業務担当者が確認するのだ。
月末だけの処理や、障害からの回復手順は、短い観測期間では見つからない場合があるのだ。こうした不足は担当者への確認と、決めた業務手順を再現する試験で補うのだ。
4.3 AIの案を人が確認してから採用する
AIには、調べた業務をもとにAPIの仕様、変換処理、試験の案を作らせるのだ。例えば注文なら、誰がどの商品を注文できるか、確認と確定を分けるか、失敗時に何を返すかを決めるのだ。URLを別名にするだけでは、この設計は完成しないのだ。
| AIに作らせる案 | 人が確認すること |
|---|---|
| APIの仕様 | 公開する操作、必要な入力、値の上限、エラーの返し方 |
| APIの受付処理 | 利用者の確認、対象の注文を操作する権限、応答へ含める情報 |
| 既存Webへの変換処理 | ログイン状態、画面遷移、送信先、再試行の扱い |
| 業務を再現する試験 | 通常操作、取消し、低頻度の操作、エラー回復、同時実行 |
| 不正操作を試す検証 | 他人の注文の操作、利用者間の状態混入、未定義の操作 |
仕様はOpenAPIという機械可読な形式で管理するのだ。この仕様には、どのAPIでどの入力を受け付けるかを記述するのだ。以降の入力検査や試験でも、同じ仕様を基準にするのだ。
変換処理では、Cookieやセッションが他の利用者と混ざらないことを確かめるのだ。CSRFトークンのような不正送信を防ぐ確認情報や、画面内の隠し項目も引き継ぐ必要があるのだ。また、利用者が指定した任意のURLへ接続できる作りにせず、業務操作ごとに接続先を固定するのだ。
生成した案はGitで差分を管理し、レビューと自動試験を通して採用するのだ。本番の通信を受けたAIが、その場で稼働中のコードを書き換える仕組みにはしないのだ。
5. 許可する入力を決め、検査の抜けを埋める
注文APIなら、必要な入力だけを受け付け、想定しない操作や形式は拒否する設計にするのだ。このように許可する範囲を先に定める考え方を、Positive Securityと呼ぶのだ。
入力検査はCloudflareとAWSの両方で行う計画なのだ。ただし、同じOpenAPIを登録しても、両製品が同じ項目を検査するとは限らないのだ。対応範囲の差を確認し、検査されない入力をどう扱うかまで決めるのだ。
| 検査する場所 | 確認時点の主な条件 | 設計で補うこと |
|---|---|---|
| Cloudflare Schema Validation | OpenAPI 3.0系に対応し、本文検証はJSON形式が対象。サイズ上限と未対応の定義も存在 | 検査対象外の入力の扱いと、違反を遮断するCustom Rulesの設定 |
| API Gateway REST API | 必須パラメーターは存在と非空を確認し、型や形式は対象外。本文はContent-Typeに合うモデルで検証 | モデルに合わない本文の扱いと、アプリケーション側で補う検査 |
Cloudflareは仕様違反を検知しただけでは遮断せず、Custom Rulesによる制御が必要なのだ。登録済みのAPI操作に当てはまらない通信の扱いも、別に定義するのだ。4 API Gatewayも、本文に合うモデルがない場合には本文検証が行われない条件があるのだ。5
このため、仕様と補助ルールを管理し、製品ごとの設定へ変換した後で、同じ入力を使って受理・拒否の結果を確かめるのだ。未対応の制約はAPIの受付処理や変換処理で検査するか、受け付ける入力を狭めるのだ。
また、形式が正しい注文番号でも、その注文を操作する権限があるとは限らないのだ。利用者の権限、呼出し回数、業務の進行状態も、それぞれ担当する処理で確認するのだ。移行済みのAPIで拒否した要求が、古い中継経路へ回って処理されることも防ぐのだ。
6. 新旧の結果を比べてから、一部の利用者で試す
6.1 読取りは比較し、書込みは二重実行を避ける
注文の確認と注文の確定では、試し方を変える必要があるのだ。確認処理なら、既存の経路と新しいAPIを並行して動かし、同じ結果になるかを比較する方法が考えられるのだ。このように利用者への応答とは別に新しい処理を試す方法を、Shadow検証と呼ぶのだ。
ただし、読取りに見える処理でも既読状態の変更や通知が起きる場合があるのだ。GETという通信の種類だけで判断せず、データや周辺処理への影響がないことを先に確認するのだ。
注文の確定を本番で二重に実行すると、注文も二重に登録されかねないのだ。そこで書込みでは、新APIから作り直した送信内容を実際には送らず、元の通信と比べるのだ。
記録した注文確定の通信
→ 新APIの入力へ変換
→ 既存Webへ送る形式に戻す
→ 元の通信と比較する（本番へは送信しない）
比較時に時刻などの変動値をそろえることを、正規化と呼ぶのだ。必要な確認情報まで消して同じに見せないよう、比較対象と除外項目を決めるのだ。
送信内容が一致しても、注文の登録結果、権限判定、同時更新、通知まで正しいとは限らないのだ。これらは本番から分離した検証環境で実行し、処理前後のデータと照合するのだ。既存業務を壊していないか繰り返し確かめる回帰試験にも、この確認を含めるのだ。
6.2 応答が途切れたときの再実行も確かめる
注文が登録された直後に通信が途切れると、利用者には失敗に見えても処理は完了している場合があるのだ。そのまま再実行する前に、処理済みかを照会できる仕組みを用意するのだ。
同じ要求の繰返しで結果が重複しない性質を、冪等性と呼ぶのだ。新APIに重複判定用のキーを付けるだけで、既存Webまでその性質を持つわけではないのだ。再試行、重複の検出、結果照会を一組で設計するのだ。
6.3 少数の利用者から広げ、問題があれば戻す
試験を通過した機能は、一部の利用者に絞って本番へ適用するのだ。これをCanary運用と呼び、注文完了率、重複登録、結果の差、権限エラー、待ち時間を確認してから対象を広げるのだ。合格基準は、切替前の値と業務要件から先に決めるのだ。
複数画面にまたがる処理は、通信ごとに新旧へ振り分けると途中で状態が食い違う可能性があるのだ。利用者やセッションごとに経路をそろえ、切戻し時には進行中の注文を完了させるのか、中断するのかも決めるのだ。
7. 新しい画面へ移し、古い入口を閉じる
新APIを作っても、利用者が古い画面やフォームを使い続けるなら、その入口は外部に残るのだ。移行する業務の画面も新APIを利用するものへ変え、不要になった旧URLへのアクセスを拒否するのだ。
注文の移行なら、新しい画面で正常に注文できることに加え、古い注文画面、旧IPアドレス、別名のドメインから同じ処理を直接実行できないことを確かめるのだ。ここまで確認して、その業務の公開範囲を狭めたと判断するのだ。
| 移行段階 | 次へ進むために確認すること |
|---|---|
| 中継経路を準備する | 主要業務、ログの追跡、接続制限、切戻しの試験に合格 |
| 通信を調べてAPIを設計する | 業務担当者が操作・権限・例外を確認し、未確認部分を特定 |
| APIと変換処理を試す | 通信の比較と、検証環境での処理結果の確認に合格 |
| 一部の利用者へ適用する | 業務結果と性能が許容範囲内で、元へ戻すことも可能 |
| 古い入口を閉じる | 旧画面や直接接続から、移行済みの業務を実行できないことを確認 |
進捗はAPIの数だけでなく、閉じた旧経路、拒否できた不正操作、試験で扱った業務、切戻しに要する時間で見るのだ。新しい入口を増やした段階と、古い入口を閉じた段階を分けて報告するのだ。
8. 移行後も、変更と新しい脆弱性に対応する
8.1 業務の変更に合わせて仕様と防御を見直す
既存Webの画面や入力項目が変わると、変換処理も影響を受けるのだ。日々の通信記録、業務を再現する定期試験、リリース通知を組み合わせて変化を把握するのだ。変更前に通知を受けられる場合は、先に新しい動作を試すのだ。
AIは仕様、変換処理、試験、防御ルールの修正案を作るのだ。ただし、変更へ追従するために許可する操作や権限まで自動で広げると、制限した意味が失われるのだ。こうした変更は別に審査し、誰が何を承認したかを記録するのだ。
WAFなどの防御ルールは、通信の観測、変更提案、ログでの影響確認、回帰試験、限定適用、全体適用の順に更新するのだ。ログだけを取る動作が使えない機能は、非本番環境や限定した範囲で評価するのだ。遮断件数とともに、正常な業務を妨げていないかを確認するのだ。
API仕様、変換処理、防御ルールの版と、試験結果、承認者、戻し先を結び付けて管理するのだ。互換性がある変更を自動で反映する場合も、許可する変更の種類と停止条件を事前に定めるのだ。
8.2 脆弱性が見つかったら、外部から届くかを調べる
脆弱性情報は、実際に悪用された脆弱性を掲載するCISA KEV、NVD、製品ベンダーの情報から集めるのだ。67 まず、使用製品と版、ソフトウェア部品表であるSBOM、公開中のAPIを照合し、自分のシステムに関係するかを調べるのだ。
次にAIへ「どの入口から、どの権限と入力なら、問題の処理へ届くか」という仮説と試験案を作らせるのだ。試験は許可された検証環境を基本とし、対象、負荷、停止条件、証拠の扱いを定めるのだ。NIST SP 800-115は、このような技術的評価の計画、実施、結果分析、対策検討を扱う指針なのだ。8
| 試験で分かったこと | 記録と次の対応 |
|---|---|
| 対象の処理に届いた、または悪用条件を確認した | 入口、権限、入力、到達した段階を記録し、影響に応じて修正と暫定防御を優先 |
| 試した条件では遮断を確認した | 遮断した場所、設定の版、ログを残し、残るリスクと再検証条件を記録 |
| 結果を判断できなかった | 環境差、試験や観測の不足を記録し、追加確認の担当者と期限を設定 |
処理に届くことと、脆弱性の悪用が成功することは区別するのだ。また、試験が失敗しただけで「外部から届かない」と確定せず、遮断の証拠が得られた条件を明記するのだ。暫定防御とパッチ適用の計画を併記し、設定や経路が変われば再検証するのだ。
9. 導入の判断では、業務の複雑さと保守負担を確かめる
この方式で難しいのは、古いシステムの業務規則を正しくAPIへ移す部分なのだ。ブラウザー側の複雑な処理、外部サイトをまたぐログイン、長時間の処理、大きなファイルの転送は、単純な変換処理では扱いにくい可能性があるのだ。機能ごとに適用可否を確かめ、既存側の改修や別の移行方式も検討するのだ。
中継処理、通信の記録、AIの生成工程、変換処理を追加すれば、費用と保守対象も増えるのだ。本稿ではDDoS対策やWAFによる防御の改善を期待する一方、費用対効果、誤検知率、応答時間、AI生成の成功率は測定していないのだ。最初の試行では小さな読取り業務と書込み業務を選び、動作、権限、復旧、旧経路の遮断まで確認するのだ。
複数システムへ広げる場合は、ログの管理方法、設定をコード化するIaC、試験の形式を共通化する案なのだ。実行環境、認証情報、変換処理、更新の単位は分け、あるシステムの不具合が他へ及びにくくするのだ。AWSのセキュリティ参照構成であるSRAを参考に、共通基盤と各システムの担当範囲を決めるのだ。9 共通の防御ルールも一部から順に適用し、個別に停止できるようにするのだ。
10. 結論：業務を維持しながら、不要な入口を閉じる
外部からの攻撃面を小さくするには、通信を中継するだけでなく、必要な業務をAPIへ移し、その動作を確かめ、古い入口を閉じるまでを計画するのだ。CloudflareとAWSは通信を受け付けて検査する場所を担い、AIは仕様、変換処理、試験の案を作る役割を担うのだ。
移行の判断基準は、正常な業務を続けられることと、許可していない操作や経路を拒否できることなのだ。この二つを業務ごとに確認することで、全面刷新の完了を待たずに外部から使える範囲を見直せるのだ。
付録：CloudflareとAWSの接続構成
実装時には、通信を中継する経路と、APIへ移した経路を分けて用意するのだ。ALBは通信を振り分ける入口、ECSは中継や変換を行うアプリケーションの実行基盤として使う計画なのだ。
| 段階 | 通信経路 |
|---|---|
| 既存画面の通信を中継 | 利用者 → Cloudflare → ALB → ECS上のプロキシ → 既存Web |
| APIへ移した業務 | 新画面／APIクライアント → Cloudflare → API Gateway REST API → VPC Link V2 → Private ALB → API受付・変換処理 → 既存Web |
新しい画面向けのAPI受付処理をBFF（Backend for Frontend）として実装する案なのだ。BFFは利用者の権限や応答内容を扱い、Legacy Adapterは既存WebのCookie、CSRFトークン、フォーム送信、画面遷移を扱うのだ。同じサービスに実装する場合も、この役割は分けて確認するのだ。
AWSの確認時点の文書では、REST APIからVPC Link V2を使ってALBへプライベート統合できるのだ。REST API、VPC Link、ロードバランサーは同一AWSアカウントに置く条件があるのだ。バックエンドへ付加されるステージ名とHTTPSの設定も接続試験で確認するのだ。10 AWSと既存環境はVPNやDirect Connectなどで接続し、必要な宛先とポートを限定する案なのだ。
プライベート統合はバックエンドへの接続方式であり、APIの外部向け入口を非公開にするものではないのだ。API経路では、接続元を証明書で確かめるmTLSをRegionalカスタムドメインに設定し、既定のexecute-apiエンドポイントを無効化する設計なのだ。Workersからの接続にはmTLS bindingを使えるのだ。111213
接続元の証明書を確認しても、その先の利用者が特定の注文を操作してよいかは分からないのだ。利用者の認証、注文ごとの認可、変換処理へ引き継ぐセッションの対応を別に検証するのだ。利用者が任意に付けたユーザーIDや転送ヘッダーを、そのまま権限の根拠にしないのだ。
参考資料（出典）
製品の機能と適用条件は、以下の一般公開された一次資料を根拠としているのだ。移行工程の判定条件と残存リスクの整理は、これらの条件を踏まえた本稿の設計考察なのだ。