アプリケーションセキュリティとは？完全ガイド

アプリケーションセキュリティは、SAST、DAST、SCA、ランタイム防御などのツールを使用してSDLC全体でソフトウェアを保護します。AppSecプログラムの構築方法を学びましょう。

アプリケーションセキュリティとは？

1つの脆弱なAPIエンドポイント。1つの未修正のオープンソースライブラリ。運用環境で実行されている誤設定のコンテナ。これらのいずれもが攻撃者に環境への鍵を渡すことになり得ます。Verizon DBIRは、脆弱性の悪用が侵害の初期アクセスベクターとしてますます一般的になっていることを確認しています。

アプリケーションセキュリティ（AppSec）は、ソフトウェア開発ライフサイクル（SDLC）全体を通じて、アプリケーションの脆弱性を発見、修正、防御するために使用するプロセス、プラクティス、ツールを包括します。その範囲はアプリケーションコードだけでなく、システム設定、API、データベース、サードパーティライブラリ、アプリケーションが稼働するインフラストラクチャにも及びます。

アプリケーションセキュリティテスト（AST）は、手動技術と専用ツールの両方を用いて、ソフトウェアのセキュリティ上の弱点、コンプライアンス問題、悪用可能な欠陥を特定するための分析手法です。ASTはSDLC全体、すなわち最初のコード記述から本番稼働まで適用され、攻撃者に悪用される前に弱点を発見・修正することが目的です。

AppSecは単独で機能するものではありません。より広範なセキュリティプログラムの中での位置づけを理解することが、カバレッジのギャップを回避するために不可欠です。

なぜアプリケーションセキュリティが重要なのか？

AppSecは、より広範なサイバーセキュリティ戦略の中で特定のレイヤーを担います。 ネットワークセキュリティがデータの転送、境界、インフラストラクチャセグメントを保護するのに対し、アプリケーションセキュリティはそのインフラストラクチャ上で動作するソフトウェアロジック、インターフェース、データ処理を保護します。

これらの分野は補完的であり、相互に置き換え可能ではありません。ファイアウォールは境界で悪意のあるトラフィックを遮断します。アプリケーションセキュリティは、コードの欠陥を突いたSQLインジェクション攻撃を阻止します。両者を混同した戦略は、攻撃者がますます注目するアプリケーション層で未対応のリスクを生み出します。

この収束はさらに深まっています。 OWASP Top 10のドキュメントでは、いくつかの重大なリスクが本番環境でのみ顕在化することが指摘されており、アプリケーションセキュリティはビルドフェーズで止めてはならないことが確認されています。エンドポイント保護、クラウドワークロードセキュリティ、AppSecツールが統合防御として収束するランタイム可視化まで拡張する必要があります。

ツールを選定する前に、それらが対処する脅威を理解する必要があります。

一般的なアプリケーションセキュリティの脅威

 OWASP Top 10:2025は、Webアプリケーションに対する最も一般的なリスクを定義しています。これらのカテゴリは、AppSecチームがテストやランタイム防御の優先順位を決定する際の指針となります。

最も影響の大きいカテゴリは以下の通りです：

• アクセス制御の破損は依然として最大のリスクです。認可ロジックの欠陥により、攻撃者が本来の権限外のデータや機能にアクセスできてしまいます。
• インジェクションの脆弱性（SQLインジェクションや クロスサイトスクリプティング（XSS）など）は、サニタイズされていない入力フィールドを通じて攻撃者が悪意のあるコードを挿入し、データベースやユーザーセッションを侵害します。
• ソフトウェアサプライチェーンの失敗は、脆弱なオープンソースコンポーネント、侵害された依存関係、サードパーティコードの検証不足によるリスクを含みます。 CISAはnpmエコシステムに影響を与えるサプライチェーン侵害について公式アラートを発出しています。
• セキュリティ設定ミスは、デフォルト認証情報、不必要なサービス、過度に許可されたクラウド設定など、アプリケーションを悪用にさらす要因を含みます。
• 暗号化の失敗は、弱い暗号化、漏洩した鍵、トランスポート層セキュリティの欠如などにより、機密データが転送中や保存時に平文で読まれてしまうリスクです。
• サーバーサイドリクエストフォージェリ（SSRF）は、攻撃者がアプリケーションに内部リソースへのリクエストを強制させ、しばしばファイアウォールやアクセス制御を回避します。

各カテゴリはアプリケーションスタックの異なる部分を標的としています。以下のセクションで紹介するツールやプラクティスは、これらのリスクに直接対応しています。

アプリケーションセキュリティの主要コンポーネント

AppSecプログラムは、SDLCの各フェーズをカバーする6つの主要ツールに依存しています。

1. SAST（静的アプリケーションセキュリティテスト）は、アプリケーションを実行せずにソースコード、バイトコード、バイナリコードを分析し、セキュリティ上の欠陥を検出します。このホワイトボックス手法は、SQLインジェクション、クロスサイトスクリプティング（XSS）、バッファオーバーフローなどの脆弱性をコードレベルで特定し、修正が必要な行を指摘します。開発フェーズで実施され、パイプライン内で最も早いセキュリティコントロールとなります。
2. DAST（動的アプリケーションセキュリティテスト）は逆のアプローチを取ります。実行中のアプリケーションを外部からテストし、ランタイムでのみ現れる脆弱性に対して実際の攻撃をシミュレートします。このブラックボックス手法はソースコードへのアクセスを必要とせず、認証失敗、サーバー設定ミス、APIの脆弱性をQA、ステージング、本番環境で検出します。
3. SCA（ソフトウェア構成分析）は、アプリケーション内のオープンソースコンポーネントやサードパーティライブラリをスキャンし、既知のCVEやライセンスコンプライアンスリスクを特定します。 OWASP Top 10がソフトウェアサプライチェーンの失敗を主要リスクに挙げていることから、SCAは基本的なコントロールとなっています。初期開発から本番まで継続的に実行されます。
4. IAST（インタラクティブアプリケーションセキュリティテスト）は、機能テスト中にエージェントを介してアプリケーション内部から動作し、SASTとDASTの要素を組み合わせて、実行中のコードをリアルタイムで低い誤検知率で分析します。NIST 800-53 SA-11(9)は、IASTツールによる欠陥の特定と結果の文書化を明示的に要求しています。
5. RASP（ランタイムアプリケーション自己防御）は、セキュリティ機能をアプリケーションに直接組み込み、デプロイ後に保護します。RASPは、運用環境内でリアルタイムにエクスプロイトをブロックすることで、事前テストを補完します。NIST 800-53 SI-7(17)はランタイム自己防御コントロールを義務付けています。
6. WAF（Webアプリケーションファイアウォール）は、Webアプリケーションとインターネット間のHTTPトラフィックをフィルタリング・監視します。ネットワーク境界で動作し、 OWASPルールセットなどのルールを用いて、SQLインジェクション、XSS、ローカルファイルインクルージョンなどの一般的なWeb攻撃から保護します。

以下の表は、これらのツールがSDLC全体でどのように異なるかをまとめたものです：

ツール	SDLCフェーズ	アプローチ	主なカバレッジ
SAST	開発	ホワイトボックス（ソースコード）	コードレベルの欠陥：インジェクション、XSS、バッファオーバーフロー
DAST	QA / ステージング	ブラックボックス（実行中アプリ）	認証、設定ミス、APIの欠陥
SCA	開発 → 本番	依存関係スキャン	オープンソースCVE、ライセンスコンプライアンス
IAST	機能テスト	エージェントベース（アプリ内部）	低誤検知率のランタイムコード欠陥
RASP	本番	インサイドアウト（組み込み）	リアルタイムのエクスプロイトブロック
WAF	本番	アウトサイドイン（ネットワーク境界）	HTTP層攻撃：SQLi、XSS、ファイルインクルージョン

SASTとDASTは異なるインサイトを提供し、どちらも相互に代替できません。ランタイムでは、WAFがネットワーク層でアウトサイドインの防御を、RASPがアプリケーション内部からインサイドアウトの防御を行います。

各ツールの役割を理解することは半分に過ぎません。実際には、開発・デプロイメントパイプライン全体でどのように連携するかが重要です。

アプリケーションセキュリティの仕組み

AppSecは、SDLCのあらゆる段階にセキュリティコントロールを組み込み、「シフトレフト」の原則に従って、修正コストが最も低い早期段階で問題を発見します。

 OWASP DevSecOpsガイドラインは、以下の順序付けられたパイプラインを規定しています：

1. gitリポジトリの認証情報漏洩スキャン
2. SAST（ソースコードの静的解析）
3. SCA（オープンソース依存関係スキャン）
4. IAST（QA中のエージェントベーステスト）
5. DAST（実行中アプリケーションのブラックボックステスト）
6. インフラストラクチャコードの設定ミススキャン
7. インフラストラクチャスキャン
8. コンプライアンスチェック

実際には、CI/CDパイプラインはすべてのビルドでSASTとSCAを実行します。開発者がコードをコミットすると、ツールチェーンが脆弱なサードパーティライブラリやコーディングの欠陥をビルド完了前に検出します。IASTエージェントは機能テスト中に有効化され、ランタイムコンテキストで脆弱性を検出します。DASTスキャナーはリリース前にステージング環境を検査します。

デプロイ後は、RASPとWAFがランタイム防御を提供します。エンドポイントやクラウドワークロード保護レイヤーは、AppSecテストツールではカバーできない ゼロデイ、設定ミス、本番でのみ発生する脅威に対して振る舞い監視を追加します。

課題は、このパイプラインが大量の脆弱性データセットを生成することです。SAST、DAST、SCAの結果には誤検知や重複が含まれます。従来のAppSecツールは個々の脆弱性を検出しますが、ソフトウェアアーキテクチャを理解したり、ビジネスリスクに基づいて優先順位付けしたりすることはできません。 Cloud Security Allianceが指摘するように、このギャップが、断片化した検出結果を単一のリスク管理ビューに統合するアプリケーションセキュリティポスチャ管理（ASPM）の導入を促進しています。

このパイプラインが効果的に機能すれば、ツールチェーンは既知の脆弱性クラスを大規模に処理できます。しかし、スキャンだけでは成熟したテストプログラムの一側面に過ぎません。

アプリケーションセキュリティテスト手法

完全なテストプログラムは、スキャンツールを超えて、アプリケーションロジック、ビジネスワークフロー、定義済みチェックでは見逃される攻撃経路を評価します。

最も効果的な手法は以下の通りです：

• ペネトレーションテストは、熟練したテスターが実際の攻撃をシミュレートし、脆弱性の連鎖、ビジネスロジックのテスト、アプリケーション境界を越えた権限昇格を試みます。 OWASP Testing Guideは、アイデンティティ管理、認証、認可、セッション管理、入力検証、ビジネスロジックテストをカバーする体系的な手法を提供します。多くの組織は四半期ごと、または大規模リリース後にペネトレーションテストを実施します。
• 脅威モデリングは、コード記述前の設計段階でセキュリティリスクを特定します。 STRIDEやPASTAなどのフレームワークは、開発チームがデータフローをマッピングし、信頼境界を特定し、アーキテクチャ上のリスクに優先順位を付けるのに役立ちます。NIST SP 800-218（SSDF）は、「十分にセキュアなソフトウェアの作成」グループの中核プラクティスとして脅威モデリングを含みます。
• ファズテストは、アプリケーション入力に不正またはランダムなデータを送信し、クラッシュ、メモリリーク、未処理例外を引き起こします。ファザーはプロトコル、ファイルフォーマット、APIレベルで動作し、構造化テストケースでは見逃されるエッジケースの脆弱性を明らかにします。
• APIセキュリティテストは、アプリケーションコンポーネント、マイクロサービス、サードパーティ統合を接続するインターフェースを対象とします。 OWASP API Security Top 10は、オブジェクトレベル認可の破損、認証の破損、無制限のリソース消費など、最も重要なAPIリスクを定義しています。
• 手動コードレビューは、SASTを補完し、スキャナーが誤検知を出す複雑なロジック、暗号化実装、認可モデルに対して人間の判断を適用します。この手法は、脅威モデリングで特定された高リスクのコードパスに集中することで最も効果を発揮します。

これらの手法を前述のスキャンツールと組み合わせることで、測定可能なプログラム効果をもたらすカバレッジの深さが得られます。

アプリケーションセキュリティの主なメリット

成熟したAppSecプログラムは、セキュリティポスチャ、コンプライアンス対応、リスク低減の各面で測定可能な成果をもたらします。

SDLC全体にわたる測定可能なセキュリティポスチャ。 SAMMフレームワークは、組織がガバナンス、設計、実装、検証、運用の5つのビジネス機能にわたり、ソフトウェアセキュリティポスチャを分析・改善するための効果的かつ測定可能な方法を提供します。DellはOWASP SAMMを活用し、リソースの集中とセキュア開発プログラムの優先順位付けを行っています。

構造化された経営層へのコミュニケーション。SAMMは、経営層レベルでセキュリティの重要性を伝え、シフトレフトの導入を促進します。CISOが予算を正当化する際、BSIMMのようなフレームワークは、社内関係者、顧客、規制当局との信頼構築に役立つピアベンチマークを提供します。

規制コンプライアンス対応。OWASP SAMMは、EUサイバーレジリエンス法（CRA）を含む規制要件に直接マッピングされます。SAMMの活動は、CRA付属書Iのリスク評価、脅威モデリング、SBOM管理、インシデント対応などの必須セキュリティ要件と整合します。

標準化されたプラクティスによる脆弱性負債の削減。 NISTセキュアソフトウェア開発フレームワーク（SSDF）は、以下の4つのプラクティスグループを定義しています：

• 組織の準備
• ソフトウェアの保護
• 十分にセキュアなソフトウェアの作成
• 脆弱性への対応

これらのプラクティスを体系的に実施することで、本番環境に蓄積されるセキュリティ負債を削減できます。

取締役会報告のための定量的リスク低減。 データ侵害は、組織に平均して数百万ドルの損害をもたらし、脆弱性の悪用は初期アクセスベクターとして増加し続けています。成熟したAppSecプログラムは、この増大する侵害カテゴリへの曝露を直接低減します。

これらのメリットは現実的ですが、実現には大きな運用・組織的障壁を乗り越える必要があります。

アプリケーションセキュリティの課題

効果的なAppSecプログラムの構築には、あらゆる段階で進捗を妨げる組織的、技術的、リソース面の障壁に対処する必要があります。

• DevSecOps文化の摩擦。多様なソフトウェアアーキテクチャ、複数言語、さまざまな開発ライフサイクルにAppSecを拡張することが、主要な運用上の課題です。セキュリティを統合されたデリバリ機能ではなくゲートと見なすチームでは、導入に抵抗が生じます。
• ツールの乱立と断片化した可視性。複数のスキャンツールが個別のダッシュボードや異なる脆弱性分類を持つため、チームは手動で検出結果を集約・重複排除する必要があります。従来のSAST、DAST、SCAツールは個々の欠陥を検出しますが、ビジネスリスクやアーキテクチャコンテキストに基づく優先順位付けはできません。
• 事前展開／ランタイムのギャップ。シフトレフトテストは、デプロイ前にコードレベルの脆弱性を検出します。しかし、本番環境は、ランタイム脅威、ゼロデイ、設定ミス、サプライチェーン侵害に依然としてさらされています。Verizon 2025 DBIRは、多くのエッジデバイスの脆弱性が観測期間中未修正のままだったことを示しています。事前展開スキャンだけに依存するプログラムは本番環境で盲点を残します。NIST 800-53は、テストとランタイム保護が異なる機能を担うため、IAST（SA-11(9)）とRASP（SI-7(17)）の両コントロールを義務付けています。
• スキル不足という制約。SANS Instituteは、効果的なセキュリティ運用のための最重要要件として熟練した人材を挙げています。テクノロジーは人間の能力を増幅するものであり、代替ではありません。経験豊富なセキュリティスタッフがいなければ、組織はAppSecツールの運用や検出結果への対応に苦労します。

これらの課題に対処するには、ガバナンス、自動化、ランタイムカバレッジに根ざした意図的なプラクティスが必要です。

アプリケーションセキュリティのベストプラクティス

以下のプラクティスは、組織的な整合から本番レベルの防御まで、これらの障壁に直接対応します。

まずガバナンスにプログラムの基盤を置く。SAMMのガバナンスビジネス機能（戦略と指標、ポリシーとコンプライアンス、教育とガイダンス）は構造的な基盤です。セキュリティポスチャ、既存の脅威、経営層のリスク許容度に関する共通理解を提供します。OWASP SAMMの実践資料は、AppSecにはガバナンス、設計、運用の関係者が必要であり、開発チームだけでは不十分であることを強調しています。フレームワーク選定前に、以下の整合性に関する問いを解決してください：

• 組織はアプローチに合意していますか？
• フレームワークは自社環境向けにカスタマイズが必要ですか？
• 予算は確保・計画されていますか？

このフェーズを省略すると、導入率の低下や投資の無駄につながります。

セキュリティチャンピオンの配置と役割定義。セキュリティチャンピオンモデルは、開発チームにセキュリティ責任の主体性を持たせ、従来のセキュリティモデルが高速環境で摩擦を生むボトルネックを解消します。 OWASP Cincinnatiが指摘する通り、 NIST SSDFは、組織が新たな役割を創設し、既存の責任をフレームワーク全体に拡張することを要求しています。明確な役割定義がなければ、セキュリティは後付けとなります。

サードパーティ脆弱性スキャンの自動化。 NIST SP 800-218は、ソフトウェアコンポーネントの自律的な脆弱性スキャンをツールチェーンに組み込むことを規定し、取得した商用・オープンソースコンポーネントがライフサイクル全体で要件を満たしていることの検証を組織に求めています。オープンソース依存関係の手動レビューは持続不可能であり、サードパーティレビューはコアプログラム責任となります。

OWASP ASVSによる検証の標準化。 OWASP ASVSは、Webアプリケーションの技術的セキュリティコントロールをテストするための基準を提供し、SDLC全体で共通のベースラインを作成します。

リスクベースの優先順位付けの適用。NIST SSDFは、どのプラクティスを実施するか、どれだけの時間とリソースを割くかを決定する際に、コスト、実現可能性、適用性を考慮することを規定しています。SAMM＋CRAガイダンスは、実用的な公式優先度＝CRAリスク重大度×SAMM成熟度ギャップでこれを補強します。このフィルターがなければ、プログラムは成果を出す前に停滞します。すべてのプラクティスがすべての組織に等しく適用されるわけではありません。

保護をランタイムまで拡張。ランタイム防御なしではAppSecプログラムは不完全です。シフトレフトテストにRASP、クラウドワークロード保護、エンドポイント振る舞い監視を組み合わせ、事前展開スキャンではカバーできない本番脅威に対応してください。

これらのプラクティスは、2026年までにアプリケーションセキュリティを再構築するトレンドに対応するための基盤となります。

アプリケーションセキュリティのトレンド：2025年・2026年

AI駆動の攻撃からプラットフォーム統合まで、アプリケーションセキュリティへのアプローチを再構築する動きが進んでいます。

1. AIが攻撃対象領域を拡大。脅威アクターは、エンタープライズアプリケーションへのAI統合によって生じた脆弱性を標的としています。OWASPは2025年にSecuring Agentic Applications Guide v1.0をリリースし、AIエージェント開発者向けのセキュリティ推奨事項を提供しました。英国国家サイバーセキュリティセンターは、生成AIアプリケーションに対するプロンプトインジェクション攻撃が完全に防止されることはないと警告し、リスク低減と影響限定に注力するよう組織に指示しています。
2. プラットフォーム統合が加速。KuppingerColeのResearch Compass Cybersecurity 2026は、XDRとCNAPPがEDRやSIEMツールに代わり、自律的な対応のための統合データソースを提供すると予測しています。ランタイム保護はCNAPPの主要な差別化要素となり、組織はポスチャスキャンとともに振る舞い監視を求めています。
3. AppSec／ランタイムの境界が縮小。従来の開発時セキュリティテストと本番時保護の分離が解消されつつあります。組織は、AppSecの検出結果、ランタイムテレメトリ、SOC対応を統合したワークフローを通じて、技術的曝露とビジネスインパクトを結び付ける単一の優先順位モデルを構築しています。

この収束こそが、プラットフォームアプローチが最大の価値を発揮する領域です。

重要なポイント

アプリケーションセキュリティは、SDLCの各フェーズでSAST、DAST、SCA、IAST、RASP、WAFを用いて、コードから本番までソフトウェアを保護します。脆弱性の悪用やサプライチェーン侵害が増加する中、事前展開テストだけでは不十分です。

ランタイム保護は、パイプラインスキャンと本番防御の間の重要なギャップを埋めます。OWASP SAMMとNIST SSDFを基盤とし、サードパーティ脆弱性スキャンを自動化し、振る舞い監視を本番ワークロードに拡張してください。

よくある質問

アプリケーションセキュリティ（AppSec）とは？

アプリケーションセキュリティ（AppSec）は、開発ライフサイクル全体を通じてソフトウェアの脆弱性を発見、修正、防止するための実践です。ソースコード、API、サードパーティライブラリ、システム構成、アプリケーションが稼働するインフラストラクチャを対象とします。 

AppSecプログラムは、テストツール（SAST、DAST、SCA、IAST）とランタイム防御（RASP、WAF）を組み合わせて、コードから本番環境までアプリケーションを保護します。

アプリケーションセキュリティにおけるSASTとDASTの違いは？

SASTはアプリケーションを実行せずにソースコードを解析する（ホワイトボックステスト）ことで、開発中にSQLインジェクションやXSSなどの欠陥を発見します。DASTは外部から稼働中のアプリケーションをテストする（ブラックボックステスト）ことで、認証失敗やサーバー設定ミスなどのランタイム問題を検出します。 

SASTは正確なコード行を特定します。DASTは攻撃者が見るものを示します。どちらも互いの代替にはならず、両方が完全なカバレッジに必要です。

アプリケーションセキュリティとネットワークセキュリティの違いは？

アプリケーションセキュリティは、ソフトウェア層（コードロジック、API、データ処理、サードパーティコンポーネント）を保護します。ネットワークセキュリティは、インフラ層（転送中のデータ、境界、ネットワークセグメント）をファイアウォール、VPN、IDS/IPSによって保護します。

WAFは、ネットワーク境界でHTTPトラフィックをフィルタリングすることでウェブアプリケーションを保護し、両方の分野を橋渡しします。多くの組織では両方の対策が必要であり、ファイアウォールだけではコード内のSQLインジェクション脆弱性を防ぐことはできません。

2025年にソフトウェアコンポジション解析が重要な理由は？

OWASP Top 10:2025は、ソフトウェアサプライチェーンの失敗を主要なリスクの一つとして挙げています。CISAは2025年9月、Shai-Hulud npmワームに関する正式な警告を発表しました。これは同種で初めて成功した自己増殖型サプライチェーン攻撃です。

ほとんどの最新アプリケーションがオープンソースコンポーネントに大きく依存しているため、SCAは依存関係ツリー全体にわたる既知のCVEやライセンスコンプライアンスリスクへの継続的な可視性を提供します。

アプリケーションセキュリティにおけるランタイム保護の役割は？

ランタイム保護（RASP、CWPP、エンドポイント監視）は、SAST、DAST、SCAなどのデプロイ前ツールが可視化できないデプロイ後のアプリケーションを防御します。NIST 800-53 SI-7(17)は、ランタイムアプリケーション自己防御制御を義務付けています。これは、本番環境がゼロデイ、設定ミス、サプライチェーンの侵害など、テストだけでは防げない脅威に直面するためです。

ランタイム防御は、アプリケーションが稼働して初めて現れる脅威をカバーすることで、シフトレフトテストを補完します。

アプリケーションセキュリティプログラムの成熟度はどのように測定しますか？

OWASP SAMMは、ガバナンス、設計、実装、検証、運用の5つのビジネス機能にわたる構造化された評価を提供します。BSIMMは他組織とのピアベンチマーキングを可能にします。 

最も効果的なアプローチは、SAMMの指針となるロードマップとBSIMMの記述的ベンチマークを組み合わせ、OWASP ASVSを標準化された検証基準として使用することです。これらのフレームワークを組み合わせることで、進捗を継続的に追跡し、ギャップを特定する再現可能な方法が得られます。

アプリケーションセキュリティに使用されるツールは？

主なツールには、SAST（ソースコードの静的解析）、DAST（稼働中アプリケーションのブラックボックステスト）、SCA（オープンソース依存関係のスキャン）、IAST（QA中のエージェントベーステスト）、RASP（ランタイムでのエクスプロイトブロック）、WAF（ネットワーク境界でのHTTPトラフィックフィルタリング）などがあります。

スキャンツールに加えて、チームはペネトレーションテスト、脅威モデリング、ファズテスト、手動コードレビューを適用し、スキャナーが見逃すビジネスロジックの欠陥やエッジケースをカバーします。多くの成熟したプログラムでは、コミット時の静的解析から本番環境でのランタイム防御まで、これらのツールをSDLC全体に重層的に導入しています。