トランザクションセキュリティのアドバイスはほとんどが「TLSとMFAを有効にしましょう」というものです。それは浅い答えです。生産環境では、実際に金銭を損なう失敗は、TLSとMFA以外の場所にあります。 鍵保管, 承認ロジック, 不正取引検出, および支払い変更、承認、および更新に関連する人間のワークフロー。
支払いは暗号化されたエンドツーエンドでも安全ではない。間違った人が承認した場合、署名キーはデータの隣にあり、財務チームが見た目が正当なリダイレクト要求を受け入れた場合でも。 現代の 取引セキュリティ
は、転送の全パスをカバーする必要があります。意図から承認、監視、および回復まで。
- 目次
- 正しいフレーミングは、層化された制御です。
- トランザクションを標的とする一般的な脅威
- 防御コントロールと安全なアーキテクチャ
- 法的要件と規制フレームワーク
- 現実世界の実装パターン
- 取引の監視とインシデント対応
- 開発チーム向けの実行可能な推奨事項
暗号化と MFA は十分ではない
暗号化は重要であり、MFA も重要である。ただし、それらを単独で使用すると、取引の安全なハンドリングが実現しない。制御プレーンの他の部分が弱い場合、歴史的基準は明確である。NIST の 1997 年の電子銀行に関する研究では、セキュリティ制御をソフトウェアベース、ハードウェアベース、またはハイブリッドシステムとして定義し、暗号化を取引データの保護の核となる方法として位置付けていたが、その基盤は実際の決済処理では単独で使用されるものではなかった「NIST会議論文」).
通常、障害モードは運用上のものです。
ブラウザセッションは、トランジット中でもログイン後に悪用される可能性があります。署名されたペイロードは、承認フローが脆弱またはユーザーインターフェイスが操作されていた場合でも、誤ったビジネスアクションを表す可能性があります。実際のチームでは、一般的なセキュリティチェックリストがスキップするような場所で、破損が頻繁に発生します。例えば、ワイヤー承認のハンドオフ、口座変更要求、ベンダー支払い検証などです。
実用的なルール: 制御があなたに 誰が何を承認したか、どのデバイスで、どのポリシー下で、どの時間枠内でそれがわかっていない場合、重要な金額の転送では十分ではありません。
輸送セキュリティに焦点を絞ると、盲点が生じます。SSLとTLSは、規模で実用的なWebトランザクションを実現しましたが、ブラウザチャネルは全ての問題ではありませんでした。アプリケーションが支払指示を処理する場合、実際の脆弱性にはリプレイ可能な承認アーティファクト、侵害されたエンドポイント、資格情報の盗難、財務プロセスの悪用などが含まれます。
モバイルチームにとって、この問題はアップデートの配信にも影響します。アップデートのパスが弱いと、トランザクションのパスを侵害する可能性があります。アプリケーション自体が承認、支払メタデータ、署名フローの配信車両になります。そういったレイヤーで働いている場合、 SSL pinning for Capacitor apps 「__CAPGO_KEEP_0__」アプリケーション用の
重要ですが、スタックの1つの要素です。
The IMFの決済システムの分析では、リモートデータベースへのアクセスとオープンなネットワーク接続性に依存しているため、システムが露呈されていると表現されました。また、セキュリティはリスクベースで、継続的で、組織全体にわたるものでなければならないと強調しました (IMF分析)。 そのフレーミングは、生産環境で破損するものに合致しています。 ただし、ユーザー、承認者、ベンダー、バックエンドサービスが変化する動的システムを守ることになります。
「暗号化とMFAを使用するかどうか」ではなく、「ユーザーの意図がキャプチャされた後、トランザクションが変更、再生、リダイレクト、または誤ったアクターによって承認される場所はどこか」という有用な質問です。 その質問をすると、トランザクションセキュリティはチェックボックスからオペレーティングモデルになるのです。
トランザクションセキュリティの基礎
トランザクションセキュリティは、制御された銀行ネットワークから始まり、ブラウザベースのコマースに移り、現在はモバイルアプリ、API、更新パイプラインの中にあります。 しかし、核となる問題は同じままです。 価値をシステムが機能し続けるように攻撃者が弱い承認パス、公開されたキー、脆弱なリリースプロセスを探す中で移動するときに保護する必要があります。
ブラウザベースの信頼から始まった決済システムの進化を示すグラフィックです。
1990年代後半のNISTの電子銀行材料は重要な変化を捉えました。取引の制御はソフトウェアベース、ハードウェアベース、または両方の組み合わせで実行でき、データの転送中の主な防御は暗号化でした (NIST会議論文). これは、安全な商取引を専用の銀行機器から一般用途のインターネットシステムに移行させました。
SSLはその移行を大規模に実行可能にしました。ブラウザトラフィックが暗号化できるようになったら、オンラインストアや銀行ポータルは、各中間ネットワークホップに露呈しないように敏感なデータを送信することができました。同様のパターンは、現在も決済ゲートウェイやバックエンドAPIに現れます。チャンネルを暗号化し、エンドポイントを認証し、サーバーサイドでトランザクションを検証するのです。
リモートアクセスは脅威モデルを変える
IMFの決済システム分析は、この作業が解決された問題になることはないことを説明しています。電子決済はリモートデータベースへのアクセスとオープンな接続性に依存しているため、システムは不正行為、ハッキング、障害が可能な限り続けなければなりません (IMF分析). これは、オフラインデータベースまたは内部ネットワーク内で永遠に留まるワークフローとは異なる運用現実です。
運用上の教訓: 取引の安全性は、実行中の制御システムとして扱う必要があります。デプロイメントのマイルストーンではありません。
ビジネスが変化するにつれて、コントロールも変更する必要があります。IMFのガイドラインでは、人間のエラーが情報資産に大きな脅威であることを指摘し、企業が従業員、支店、またはビジネスラインを追加した場合にコントロールを更新する必要があることを警告しています。実際、トランザクションアーキテクチャがモバイルアプリ、ブラウザセッション、ベンダーポータル、バックオフィストールに広がるにつれて、セキュリティは暗号化に加えてプロセスインテグリティに依存するようになります。
トークンハンドリングはそのプロセスインテグリティの一部です。セッションデータまたは承認アーティファクトがクライアント上で不適切に保存されている場合、残りのスタックは避けられるリスクを運ぶことになります。そのため、チームはモバイル開発者向けのセキュアトークンストレージベストプラクティスを サーバーサイドコントロールとともに レビューする必要があります。
開発者にとっての教訓は簡単です。暗号化を使用することは当然ですが、アイデンティティ、承認、ビジネスインテントがパケットストリームから逸脱する可能性があることを前提にします。そのため、生産環境でキー管理、承認分離、詐欺検査、セキュアアップデルドリバリーなどのコントロールが重要です。ユーザーが一つの場所で支払いを承認でき、別のシステムがペイロードまたはリリースを変更したり、リリースを配信したりできる場合、トランザクションモデルはすでに破壊されています。同様の論理は チェック詐欺リスクを軽減する場合にも当てはまります。コントロールは支払いフローの上に位置する必要がありますが、隣に位置する必要はありません。
共通の脅威はトランザクションを標的としています
実際の攻撃はほとんどの場合、攻撃のようには見えません。 その時点では、有効な要求、親知りやすいサプライヤー名、または「クローズ前に通過する必要がある」変更が表示されます。 ただし、パケットのみを追跡する脅威モデルでは、真の障害モードを逃します。 交易リスクは、技術パス、人間のレビュー パス、そしてこれらを結ぶシステムに存在します。
信頼を再利用する技術攻撃
リプレイ攻撃は、最も清潔な例です。 攻撃者は承認アーティファクトをキャプチャし、後で異なるトランザクションに対してそれを再利用します。 OWASP のトランザクション承認ガイドラインでは、実行前に最終的な制御ゲート、制限された承認時間枠、および各操作ごとに一意のクレデンシャルを使用して、キャプチャされた OTP、チャレンジ、または署名が再生できないようにします。OWASP トランザクション承認 チート シート).
マニン・ザ・ミッドル アビューズは、異なる結果を生みますが、実行結果は似ています。 攻撃者はユーザーが見るものやサーバーが受け取るものを変更し、ログイン セッションや署名はまだ有効です。 生産環境では、クライアントの信頼、セッション バインディング、デバイスの整合性は制御平面にあり、トランスポート暗号化だけではありません。
人間を標的とした詐欺は、より大きな問題です
ビジネスメール詐欺と請求書詐欺はTLSを破る必要はありません。銀行口座の新規作成、請求書の改訂、または検証ステップのスキップを承認するだけの1人の財務または請求書処理担当者が必要です。OCCのセキュリティ層の警告はここで役立ちます。一般的なMFAのアドバイスを超えて、顧客の歴史と行動に基づく詐欺検出、異なるアクセスデバイスを通じた二重の顧客承認、正当な支払い、借入ブロックを呼びます。).
あなたが財務部門のワークフローに携わっている場合、 チェック詐欺リスクを軽減することは、支払いオペレーションの一部としてコントロールを扱うため、銀行スタックのサイド機能として扱うのではなく、有用な参照点です。 通常、欠落しているのは次の点です。
攻撃者はすべてのコントロールを破る必要はありません。ただし、1つの場所で、人を正常なレビューステップをオーバーライドさせるように誘導できる場所があれば十分です。 システムの欠陥は、更新と__CAPGO_KEEP_0__ Pipelinesで現れます。
APIの悪用、不正なストレージ、弱いアプリケーション更新パスは、別の脅威のクラスを作成します。コンパウンドされた更新パイプラインは、信頼できるアプリケーションを配信メカニズムに変えることができます。
API abuse, insecure storage, and weak app update paths create a different class of threat. A compromised update pipeline can turn a trusted app into the delivery mechanism. For mobile and cross-platform teams, アプリケーション脆弱性スキャンは、トランザクションコントロールと同じ議論の対象です。なぜなら、発見は、金銭の流れや承認権限の移動に関連するフローにマップされなければ意味がありません。 トランザクションセキュリティのための有用な脅威モデルは、簡潔です。金銭を直接盗むことができない攻撃者は、金銭を転送する、再生する、または人間が間違ったものを承認するように誘導することを試みます。防御はすべての3つを止める必要があります。
OCCのセキュリティ層の警告はここで役立ちます。一般的なMFAのアドバイスを超えて、顧客の歴史と行動に基づく詐欺検出、異なるアクセスデバイスを通じた二重の顧客承認、正当な支払い、借入ブロックを呼びます。
防御的制御と安全なアーキテクチャ
チームが暗号化とMFAを設計全体として扱う場合、トランザクションのセキュリティは弱くなります。 実世界の決済システムは、承認が急がれ、鍵が露呈され、更新が署名されていない、そして金銭がすでに動いた後でフラッドレビューが行われるエッジで失敗します。 強い制御では、承認、保管、実行、監視を別々の層に置きます。 1 つのミスが損失になるのを防ぎます。
金銭が動く前に制御を置く
欧州中央銀行の評価ガイドでは、トランザクションの監視は不正の支払いを検出してブロックする必要があります。 最終承認前に、そして疑わしいまたはリスクの高いトランザクションは、特定の検査と評価を通過する必要があります ( 欧州中央銀行の評価ガイド)。 その順序は重要です。 フラッドレビューがコミットメント後に実行される場合、システムはすでに攻撃者に保護しようとしていたものを渡しています。再生不可能な承認は同じレイヤーにあります。 OWASPでは、最終承認ゲート、制限されたチャレンジウィンドウ、各操作用に一意のクレデンシャルを使用することを推奨しています。 これにより、承認オブジェクトが異なるトランザクションで再利用されないようにします (OWASPトランザクション承認のチートシート
)。 繰り返しユーザーアクションの場合、idempotencyキーは__CAPGO_KEEP_0__境界に属する必要があります。 再試行が重複実行に変わるのを防ぎます。 モバイルでは、承認フローもクライアントアーキテクチャに合わせる必要があります。OWASP Transaction Authorization Cheat Sheet). For repeated user actions, idempotency keys belong at the API boundary so retries do not turn into duplicate execution. On mobile, the approval flow should also match the client architecture, which is why モバイルアプリケーションアーキテクチャパターン デバイスの状態と結びついた取引承認が重要です。
データとキーを分離し、パッチの適用を継続して行う
CISAの2025年1月の制限取引の実装ガイドラインでは、チームをより厳密な保管境界に導きます。カバーされたシステムにMFAを適用し、トランザクション中とデータ保管中の暗号化、カバーされたデータとキーを共存させないようにするための安全なキー管理、インターネット向けシステムの既知の脆弱性の修正を45日以内に実施することを要求しています。CISA実装ガイドラインハードパートは通常、キー分離とパッチの規律が難しいことです。TLSが存在するかどうかは関係ありません。
実用的なアーキテクチャは次のようになります。
- Initiation: ユーザーの意図をキャプチャし、セッションまたはデバイスに特定のものに結びつける
- Authorization: リプレイ耐性の承認、ステップアップレビュー、またはデュアルコントロールを適用する
- Validation: APIゲートウェイで署名されたペイロードを確認し直す。
- 実行: データストアからキー材料を除外してトランザクションを処理する。
- 確認: 暗号化された受領証を記録し、承認トレイルを別途保存する。
更新配信をセキュリティ境界として扱う。
セキュアなOTAパイプラインは同じルールを遵守する。攻撃者が不信頼できるcodeをプッシュできると、実行時制御が反応する前にトランザクションの動作を変更できる。リリース署名、ロールバック保護、制御されたロールアウトは、更新が注入パスになるのを防ぐ部分である。CapgoはCapacitorとElectronアプリケーションで署名されたオーバー・ザ・エア更新の1つのオプションですが、プラットフォームをまたがってコントロールの原則は同じであり、更新が実行中のトランザクションフローを影響させる前に認証される必要がある。
技術的制御が実装された後も、運用上の詐欺制御は重要である。支払い紛争を防ぐために、承認ロジック、例外処理、証拠収集を同じオフィスワークフローに結びつけるチームは、実際の顧客上訴が生じた場合に、レビュートレイルが生き残る必要がある。支払い紛争を防ぐ。).
クリーンな設計のルールは単純である。承認、キー管理、実行、更新配信を別々の信頼ゾーンに分離し、ネットワークとユーザーインターフェイスは両方とも敵対的であると仮定する。そうすることで、実際の顧客上訴が生じた場合に、レビュートレイルが生き残る必要がある。
法的要件と規制フレームワーク
Compliance frameworks overlap more than people think, but they do not fail in the same places. The mistake is treating them like paperwork instead of architecture constraints. Each one pushes a different part of the transaction stack, and the controls have to line up with that pressure.
| Framework | Key Controls | Remediation Timeline | MFA Requirement |
|---|---|---|---|
| PCI DSS | Protect payment data, restrict access, harden cardholder environments | Not specified in the verified data | Not specified in the verified data |
| PSD2 SCA | Strong customer authentication for payment actions | Not specified in the verified data | 強制的な顧客認証によって暗示される |
| SOC 2 | セキュリティコントロールと監査可能性 | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| GDPR | 個人データ保護と露呈の制限 | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| CISA制限事項の取引指針 | MFA、転送中および転送中の暗号化、安全な鍵管理、正確なネットワークトポロジーの可視性、パッチ後の妨害検査 | インターネット向けシステムの既知の脆弱性に対して、実装ガイドラインがタイムラインを設定する場合に必要 45 日間のカレンダー | 必要 カバーされたシステム上 |
オーバーラップが重要な点
PCI DSS、PSD2/SCA、SOC 2、GDPRはすべて、強力なアクセス制御、より良い証拠、露出を減らすチームの方向性を押し進めています。各フレームワークごとに重点が異なります。PCIは支払い面に焦点を当て、PSD2は支払いの際の強力な顧客認証を推進、SOC 2はコントロール環境の一貫性を考慮し、GDPRはデータ最小化と個人データ保護を強制しています。
CISAのガイドラインは、多くのメインストリームの説明者が省略するメカニズムについて明確に述べています。 MFAトランザクション中とトランザクション後でのデータの暗号化、セキュアなキー管理（キーはカバーされたデータから離れます）、正確なネットワークトポロジーの可視性、パッチ後の妨害検出のためのチェックが必要です。つまり、コンプライアンスは、コントロールリストだけではなく、運用対応にも及ぶことになります。モバイルとデバイスに紐づいたクレデンシャルを扱うチームには、生産環境で機能するトークン削除パスが必要です。詳しくは「__CAPGO_KEEP_0__ アプリ用のトークン削除パターン」を参照してください。 token revocation patterns for Capacitor apps.
主な問題は、1 つのフレームワークを選択することではなく、1 つのアーキテクチャが複数のフレームワークを満たすことなく、重複した作業を避けることです。クリーンなキー管理境界は、PCIスタイルの支払い保護、CISAスタイルの制限されたトランザクション処理、内部SOC 2の証拠収集をサポートすることができます。同様に、認証では、1 つのステップアップ制御が、詐欺防止と監査の期待をサポートすることができます。
ルールオブススメ:
]} 重大レビューでは、証拠を提示できない、分離を証明できない、タイミングを強制できない制御は通常存続できません。
製品およびエンジニアリングチームは、各制御を保護するトランザクションイベントにマップする必要があります。そうすると、コンプライアンスが紙上の作業から設計上の制約に変わり、調査、契約レビュー、エスカレーションハンドリング、ツールを使用して作成されたワークフローにわたるオペレーションにとっては、記録がきれいに保たれます。 LegesGPTのAI法的文書生成ツール.
実用的な実装パターン
生産環境で存続するシステムは、平凡で繰り返し実行できる制御に依存しています。重要なアーティファクトに署名し、複数のポイントで検証し、人とサービスを跨ぐ役割を分割し、金銭の流れが始まる前にルートまたはアカウントの変更を可視化します。これは、支払いレール、OTA更新、後方オフィス承認フローに適用されます。
安全な更新配信とトランザクションの整合性
OTA配信は、ハイパーミッショントランザクションチャネルとして振る舞うため、参考点となります。署名されていないパッケージ、弱いロールバックハンドリング、または緩い更新承認が攻撃者に直接パッチを変更するパスを与えます。管理がうまく行くチームは、code署名、チェックサム検証、ステージドロールアウト、ロールバック保護を使用して、悪いリリースが生産ロジックを上書きできないようにします。
モバイルシステムは、クライアントに悪く保存されたシークレットを利用して、攻撃者が妨害されたデバイスから有効な要求を生成できる可能性があります。バックエンドがチェックを実行しても、デバイスに長期間の権限が蓄積されないようにするため、実際には、クライアントを薄く検証されたアプリとして保ち、デバイスに権限を蓄積するのを避ける方が安全です。 Capacitor アプリのトークン削除パターン は、同じコントロールサーフェイスの一部です。
支払いオペレーションには、技術的なものだけではなく、プロセス制御が必要です。
ベンダー支払い検証は、転送の最終化前にリダイレクトを捕捉することで、実際の損失を防ぐことができます。アカウント変更要求は、ワークフローの感度に合ったレビューを通じて行われ、APまたはAR異常検出は、不正な請求書のタイミング、新しい宛先、新しい連絡先パスが一致しない場合に異常を検出する必要があります。これらのチェックは、機転が必要ではありません。毎回実行する必要があります。
__CAPGO_KEEP_0__ アプリをサポートする文書作成を実行するチームは、ツールとして LegesGPTのAI法的文書生成ツール を使用してドキュメントの作成またはレビューを行うことがありますが、コントロールは自身の支払いフロー内に置かなければなりません。
実用的な実装パターンは次のようになります。
- トランザクション ペイロードを署名する アプリまたはゲートウェイを出発する前に。
- 宛先アカウントまたはウォレットを検証する ポリシーまたは許可リストに違反している。
- リスクの高い変更には別の承認パスが必要です。 変更の承認後、ユーザー、デバイス、ポリシー結果をログに記録する。
- 決定ごとにログを記録する。 承認されていない変更があれば実行をブロックする。
- 承認されていない変更があれば実行をブロックする。 パターンは1つ、システムは多数ある。
リリース管理にも同じ規範が適用される。
セキュアなOTA配信では、資金移動、署名アーティファクト、ポリシー検証、明示的なロールバック基準など、同様のトランザクションロジックが使用される。
セキュアな決済APIでは、署名キーはデータストアから外され、ビジネスサービスがリクエストを処理する前に、ゲートウェイが有効性を検証するように強制される。
クリーンな財務運用では、すべての口座変更要求は2つのチャネルを通じて検証されるため、1つのコンプライアンスセッションが支払い指示を書き換えることはできない。
このパターンは、トランザクションセキュリティが値の移動を決定することを保護するため、データが移動中のデータのみを保護するのではなく、実行される。
アップタイムだけではなく、制御の失敗を監視する
承認の失敗のスパイクから始めます。有効なユーザーが突然決済承認を完了できなくなった場合、原因はポリシーが破損している、リプレイ試行、または承認フローのプローブ攻撃である可能性があります。異常なトランザクションの速度、地理的な異常、デバイスの指紋の不一致を監視する必要があります。これらのパターンは、資格情報またはセッションが悪用されている場合によく現れます。
監視は、CISA の実装ガイドで前述したように、 patch state とネットワークの露出とアプリケーションイベントを関連付ける必要があります。これは、ログインの失敗だけを追跡するのではなく、トランザクションの結果をシステムが新しく露出、最近パッチ、または予想外のネットワークパスで動作しているかどうかと関連付ける必要があります。
応答パスを短く保つ
最初のアクションは隔離です。支払いサービス、承認エンドポイント、または更新チャネルが侵害されている場合、影響を受けたパスをチームが原因を議論する前に切断する必要があります。2 番目のアクションは資格情報の削除です。トークンが死んだら、リプレイとセッションの悪用のほとんどの価値が失われます。
リクエストが承認されたかどうかわからない場合は、証拠がそれを証明するまでそれを信頼しないようにします。
After containment, move to forensic log analysis. You want a clean trail of who initiated the action, what was approved, what changed, and which policy fired. That audit trail supports incident response and compliance reporting, which saves time later and reduces the chance that investigators have to reconstruct events from partial records.
A good escalation pattern stays simple. Route suspicious but unconfirmed events to the security queue, confirmed approval abuse to incident response, and payment redirection or update-channel compromise to the people who can stop the flow immediately. That keeps the team from burning time on low-value alerts while the critical one keeps moving.
開発チーム向けの実行可能な推奨事項
あなたが現在トランザクションフローを構築している場合、まず最も簡単に防ぐことができる損失の場所から始めましょう。 最初の投資は 再生不能な認証 時間制限付きの挑戦窓口と一意のオペレーション資格とともに、あるのは、コンクリートな悪用パスを閉じることです。 それからすぐに追加するべきものは 事前承認の詐欺検査実行後は遅すぎるため、意味をなさない
リスク削減順位付け
- 承認の意味を固めてください。 すべての高価値アクションは、特定のユーザー意図、デバイス、ポリシー結果とつながるようにしてください。
- キーとデータを分離してください。 ストレージ層から鍵管理を取り除き、鍵の保管を明示的に行う。
- パッチの露出を短縮する。 インターネット向けの脆弱性対策を運用上の優先事項として扱い、季節ごとの作業として扱わない。
- 運用上の詐欺対策を追加する。 AP、AR、およびベンダーチェンジの場合、レビュー閾値、二重承認、許可リスト、異常チェックを使用する。
- トランザクションのパスをインストルメントする。 失敗が発生した場所を特定できるように、開始、承認、実行、確認を個別にログする。
リリース後ではなく、配信に組み込む。
セキュリティはCI/CD、リリース署名、ロールアウトポリシーに含まれる。アップデートパイプラインが実行時挙動を変更できる場合、それはトランザクションセキュリティの一部であり、別個の懸念事項ではない。同様に、金銭の移動や転送の承認を含むAPIには署名検証、無害性、ポリシー適用が必要であり、ビジネスロジックが実行される前に実行される必要がある。
多くのチームにとって、適切な答えはコントロールとサービスを組み合わせたものである。オペレーショナルバーンダウンを減らすために、第三者コンポーネントを使用するが、承認ポリシーと鍵の保管の決定は直接エンジニアリングの下で管理する。
強固なトランザクションセキュリティポジションは、顧客と監査員に透明性を提供するが、サポートが容易になるのも事実である。承認、拒否、ロールバックのすべてに説明が必要であるため、現在のフローがその説明を生成できない場合、制御パスの再設計が必要である。ただし、警告の調整だけでは十分ではない。
Capgoはチームが署名されたオーバー・ザ・エア更新をCapacitorアプリに配信できるように支援します。これは、更新配信がトランザクションリスク面に含まれる場合に重要です。更新配信が支払いフロー、承認パス、ロールバック安全なリリースチャネルを硬化する場合、 Capgo を訪問し、安全なライブ更新がより広範なトランザクションセキュリティ戦略にどのように組み込まれるかを確認してください。
