外部ベンダーにペネトレーションテストを委託すると、最後に受け取るのが「報告書」です。発注を決める前には「どんな成果物が出てくるのか」が見えず、納品された後には「この構成で合っているのか、抜けはないのか」を確かめたくなります。報告書は社内の意思決定や取引先への説明の材料になるため、中身を正しく理解できるかどうかが、その後の対策の質を左右します。
とはいえ、ペネトレーションテストの報告書には何が書かれ、各章をどう読み、誰に見せればよいのかは、発注してみないと分かりにくいのが実情です。報告書の実物は、公開されているサンプルが限られていたり、閲覧にフォーム送信が必要だったりして、中身の全体像をつかみにくいこともあります。
本記事では、ペネトレーションテスト報告書の章立てと各章の中身を、まず全体像から具体の粒度まで整理します。あわせて、脆弱性の危険度（CVSS）の読み方、経営層・技術チーム・取引先それぞれへの使い分け、報告書を受け取った後にやることまでを解説します。章立てや危険度の基準は、NIST・OWASP・CVSS など公開されている標準と対応づけて示すので、社内説明の根拠としても使えます。
目次
一括ダウンロードする
ペネトレーションテスト報告書の章立てと各章の中身
ここからは、報告書を開いたときに並ぶ章の全体像と、各章に書かれる内容を解説します。まず章立ての一覧で全体像をつかみ、続けて主要な章を具体的に見ていきます。
ペネトレーションテストの報告書は、決まった1つの様式があるわけではありませんが、国際的な標準やガイドラインが示す構成はおおむね共通しています。米国国立標準技術研究所（NIST）のガイドライン「SP 800-115」は、テストの最後に作る報告書を「発見した脆弱性を記述し、リスク評価（risk rating）を提示し、弱点をどう是正するかの指針を与えるもの」と位置づけています。
ペネトレーションテスト実行標準（PTES）や、Webアプリケーションのセキュリティテスト手引きであるOWASP WSTGも、経営層向けの要約と技術者向けの詳細という二層構成を推奨しています。
これらの標準に共通する章立てを、「章名」「何が書かれるか」「主に読む人」の3つで整理すると次のとおりです。
| 章 | 何が書かれるか | 主に読む人 |
|---|---|---|
| エグゼクティブサマリー | テストの目的・対象・期間と、主要な発見、事業へのリスクの要約 | 経営層・意思決定者 |
| テスト範囲・手法・交戦ルール | 対象資産、実施期間、内部／外部の別、使用した手法、前提条件や制約 | 技術チーム・管理者 |
| 発見した脆弱性と証跡・再現手順 | 脆弱性ごとの名称・該当資産・悪用可能性・影響・再現の証跡 | 技術チーム・開発者 |
| リスク評価（危険度） | 各脆弱性の深刻度（CVSSなど）と、対応の優先順位 | 経営層・技術チーム |
| 対策・再検査の計画 | 推奨する是正策、担当・期限、再テストの計画 | 技術チーム・管理者 |
| 付録 | 評価基準の説明、略語一覧、テスト手順やツール出力 | 技術チーム |
このうち「リスク評価（危険度）」と「対策・再検査の計画」は、読みどころが大きいため、本記事ではそれぞれ脆弱性の危険度（深刻度）の読み方、報告書を受け取った後にやることで詳しく扱います。以下では、それ以外の主要な章を順に見ていきます。また、実際のベンダーの報告書では「結果概要」「結果詳細」「附録」といった名称が使われることもありますが、役割は上表の章に対応します。
出典・参考資料（3件）
エグゼクティブサマリー
エグゼクティブサマリーは、報告書の冒頭に置かれる経営層向けの要約です。テストの目的と対象、期間、そして「何が見つかり、事業にとってどの程度のリスクか」を、専門用語を避けてまとめます。PTESでは、この要約に全体的なセキュリティ水準の評価やリスクの格付け、主要な発見、推奨事項の概要を含めるとしています。
技術的な詳細を追わない読み手が、ここだけで「どこに、どれくらいの危険があり、次に何をすべきか」を判断できることが、この章の役割です。経営層への報告や、取引先への説明では、まずこの章が使われます。
テスト範囲・手法・交戦ルール
この章では、何を・どこまで・どのように調べたかを示します。対象となる資産（Webアプリケーション、API、サーバー、ネットワークなど）、実施期間、使用した手法、そして「交戦ルール（Rules of Engagement）」と呼ばれる前提条件や制約を記載します。交戦ルールには、攻撃を試みてよい範囲や時間帯、禁止事項などが含まれます。
テストが社内ネットワークの内側から行う「内部テスト」か、インターネット側から行う「外部テスト」かによっても、記述する前提が変わります。範囲の章を読めば、「今回のテストで調べていないもの」も分かるため、報告書の結論をどこまで一般化してよいかの判断材料になります。
発見した脆弱性と証跡・再現手順
報告書の中核となるのが、見つかった脆弱性を1件ずつ記載する章です。OWASP WSTGは、各発見事項に次の要素を含めることを推奨しています。
- 識別番号とタイトル（脆弱性の名称）
- 発生可能性（likelihood）と影響（impact）
- リスク評価（深刻度）
- 脆弱性の説明と是正策
実際の報告書では、これらに加えて、該当する資産と、攻撃を再現した証跡（スクリーンショットやリクエスト・レスポンスの記録）が添えられます。1件の脆弱性は、たとえば次のように書き起こされます（内容はイメージをつかむための記入例です）。
- タイトル：SQLインジェクション（注文検索API）
- 該当資産：注文検索APIの検索パラメータ
- リスク評価：High（CVSS 8.6）
- 影響：本来権限のない他ユーザーの注文情報を読み取れる（情報漏えい）
- 再現手順：検索欄に特定の文字列を入力すると、権限のないデータが返る（該当のリクエストとレスポンスを証跡として添付）
- 是正策：入力値をそのままSQLに渡さず、プレースホルダを用いたパラメータ化クエリに変更する
証跡と再現手順がそろっていることが、この章の価値です。脆弱性の名称だけでなく「どう悪用され、何が起きうるか」が具体的に示されていれば、技術チームは優先順位をつけて修正に取りかかれます。逆に、再現手順が曖昧だと、開発側で問題を再現できず対応が止まることがあります。
出典・参考資料（1件）
付録（評価基準・略語・テスト手順）
付録には、本文を読み解くための補助情報を収めます。危険度の評価基準（どのスコアをどの深刻度に対応させたか）、略語の一覧、使用したツールの出力、テスト手順の詳細などです。OWASP WSTGも、評価基準の説明やツール出力、チェックリストを付録に置くことを推奨しています。
付録の評価基準は、報告書全体の危険度の付け方が妥当かを確認する手がかりになります。評価の根拠がどこにも書かれていない報告書は、深刻度の判断がテスト実施者の主観だけに委ねられている可能性があり、社内説明の根拠として弱くなります。
脆弱性の危険度（深刻度）の読み方
ここからは、報告書のリスク評価の章で使われる危険度の指標を解説します。読み方が分かれば、「どこから直すべきか」を自社で判断できるようになります。
多くの報告書では、脆弱性の深刻度を共通脆弱性評価システム「CVSS（Common Vulnerability Scoring System）」のスコアで示します。CVSSは0.0〜10.0の数値で深刻度を表し、スコア帯ごとに5段階の評価が対応します。CVSSの仕様を定めるFIRSTによると、バージョン3.1でも最新の4.0でも、スコア帯と深刻度の対応は次のとおり同一です。
| 深刻度 | CVSSスコア | 対応の目安 |
|---|---|---|
| Critical（緊急） | 9.0 〜 10.0 | 最優先で是正する |
| High（重要） | 7.0 〜 8.9 | 早期に是正する |
| Medium（警告） | 4.0 〜 6.9 | 計画的に是正する |
| Low（注意） | 0.1 〜 3.9 | リスクを踏まえて対応を判断 |
| None（なし） | 0.0 | 該当なし |
報告書に脆弱性の分類として「CWE-〇〇」という番号が併記されることもあります。CWE（Common Weakness Enumeration）は、MITREが公開する脆弱性の種類の分類です。CVSSが個々の脆弱性の深刻度を測るスコアであるのに対し、CWEは「どんな種類の弱点か」を示す分類であり、役割が異なります。
ただし、CVSSのスコアだけで対応の優先順位を決めるのは早計です。CVSSを定めるFIRST自身が、基本スコア（Base Score）は脆弱性の「深刻度」を測るものであって、そのまま「リスク」の評価に使うべきではないと明言しています。
CVSS Base Score (CVSS-B) Measures Severity, not Risk（CVSSの基本スコアは、リスクではなく深刻度を測るものである）
CVSS v4.0 User Guide｜FIRST
同じスコアの脆弱性でも、実際のリスクは自社の環境によって変わります。たとえば、外部から直接アクセスできる資産にある脆弱性と、社内からしか到達できない資産にある脆弱性では、同じCVSSスコアでも優先度は異なります。
報告書を読むときは、スコアを出発点にしつつ、その脆弱性がある資産の重要度や、実際に悪用されやすいかという観点を加えて判断するとよいでしょう。質の高い報告書では、こうした事業影響を踏まえた優先順位の提案まで記載されています。
脆弱性を一覧化するだけでは、受け取った側は何から対応すればよいか判断しづらくなります。脆弱性診断を手がける株式会社TECHFUNDの生田氏も、報告書で攻撃シナリオと事業インパクトまで示すことの意図を次のように語っています。
脆弱性の報告だけでは、企業側からすると、何から対応すればいいのか分かりません。「この問題を悪用されると、他ユーザーの情報を取得される可能性がある」「この脆弱性は認証を突破して管理者権限を取得される可能性がある」といった形で、攻撃シナリオと事業インパクトまで整理して説明することを重視しています。
一括ダウンロードする
読者別の報告書の使い方
ここからは、1つの報告書を立場の違う相手にどう使い分けるかを解説します。章ごとに読む人が異なるため、相手に応じて見せる章を変えるのが基本です。
経営層にはエグゼクティブサマリーで伝える
経営層に報告するときは、技術的な詳細ではなく、エグゼクティブサマリーを軸にします。「どの資産に、どの程度の危険があり、放置すると事業にどんな影響が出るか」「対策にどれくらいの工数・費用がかかるか」を、CriticalやHighといった深刻度の件数とともに示すと、投資判断の材料になります。個々の脆弱性の技術名よりも、事業への影響と優先順位を前面に出すのがポイントです。
技術チームは脆弱性詳細と再現手順で優先修正する
技術チームや開発者は、発見事項の章と付録を使います。各脆弱性の再現手順と影響を確認し、深刻度の高いものから修正に着手します。修正後は再テストで効果を確かめます。報告書の深刻度別の件数を起点に、平均修復時間や修正率、同じ問題の再発率といった指標で進捗を追うと、対応の抜け漏れを防げます。再現手順が具体的なほど、開発側での修正と検証がスムーズに進みます。
取引先・監査にはコンプライアンスの証跡として示す
取引先からセキュリティ体制の説明を求められたときや、監査を受けるときには、報告書がテストを実施した証跡になります。業種によっては、報告書の提示が取引の条件になることもあります。
たとえばクレジットカード業界のセキュリティ基準であるPCI DSS（最新版はv4.0.1）は、要件11.4でペネトレーションテストの実施と、悪用可能な脆弱性の是正・再テストを求めています。こうした場面では、エグゼクティブサマリーと、対策・再テストの結果を中心に提示します。
出典・参考資料（1件）
報告書を受け取った後にやること
ここからは、報告書を受け取ってからの動きを解説します。報告書は読んで終わりではなく、対策・再テスト・提出・機密管理という次の段取りにつなげてはじめて価値が出ます。
対策の実施と再テスト（再検査）
NIST SP 800-115は、報告書の役割の1つを「弱点をどう是正するかの指針を与えること」としています。報告書の推奨事項に沿って、深刻度の高い脆弱性から対策を進め、担当者と期限を割り当てるのが基本です。
対策を終えたら、その脆弱性が確実に解消されたかを再テスト（再検査）で確認することが重要です。多くのベンダーは、一定期間内の再テストを報告書の付録やサービスの一部として用意しています。再テストの計画が報告書に含まれているかは、受け取ったときに確認しておくとよい点です。
取引先・監査への提出
見せ方は前の章で触れたとおりで、ここでは開示する範囲の決め方を扱います。取引先や監査に提出する場合は、相手が求める範囲を確認しておくことが望まれます。脆弱性の詳細や再現手順まで渡すと、自社の弱点の手の内を明かすことにもなるため、エグゼクティブサマリーと対策状況の要約に絞った版を用意することもあります。提出前に、どこまでを開示するかを社内で取り決めておくと安全です。
報告書の機密管理
報告書には、未対策の脆弱性とその再現手順という、攻撃者にとって価値の高い情報が含まれます。そのため、閲覧できる範囲を限定し、保管や共有の方法を定めておく必要があります。メールへの添付やクラウドストレージでの共有は、アクセス権を絞ったうえで行い、不要になった複製は削除しておきます。対策が完了するまでは、特に取り扱いに注意が必要です。
報告書の品質を見極めるチェックポイント
納品された報告書が十分な内容かを、発注側でも確認できます。ここまでに見てきた標準の章立てと照らし合わせると、次のような観点で抜けや落とし穴を見極められます。
- エグゼクティブサマリーがあり、技術知識がなくても要点をつかめるか
- テストの範囲・手法・交戦ルールが明記され、「調べていないもの」が分かるか
- 各脆弱性に再現手順・証跡が添えられ、開発側で再現・修正できる具体性があるか
- 危険度の評価基準（CVSSのバージョンやスコア帯）が付録などで示され、根拠をたどれるか
- 対策の推奨と、再テスト（再検査）の計画が含まれているか
これらが欠けている報告書は、脆弱性の一覧は出ていても「次に何をすればよいか」が読み取れないことがあります。発注前にサンプル報告書の目次を確認し、こうした章がそろっているかを見ておくと、ベンダー選びの判断材料になります。
報告書の粒度や診断シナリオ、料金は会社によって大きく異なります。実際にペネトレーションテストを依頼する会社を具体的に比べたい場合は、次の記事で各社の特徴と失敗しない選び方を整理しています。
ペネトレーションテストと脆弱性診断の違い
報告書を読む補足として押さえておきたいのが、ペネトレーションテストと脆弱性診断の違いです。脆弱性診断は、ツールと手作業で既知の弱点を網羅的に洗い出す手法で、「どこに弱点があるか」を一覧化します。
一方のペネトレーションテストは、攻撃者の視点で実際に侵入を試み、「その弱点を使ってどこまで到達できるか」を検証します。報告書も、前者は発見した脆弱性の網羅的なリストが中心になるのに対し、後者は攻撃シナリオと、侵入が成立したかどうかの検証結果が加わる点が異なります。本記事で扱う報告書は、主に後者のペネトレーションテストを想定しています。
両者の違いを目的・費用・選び方の面からもう少し詳しく整理したい場合は、『ペネトレーションテストと脆弱性診断の違いを比較』もあわせてご覧ください。
報告書作成・継続的な診断を任せられるサービス
ここからは、報告書の中身を理解したうえで、実際にペネトレーションテストや脆弱性診断を依頼・運用したい場合に検討できるサービスを紹介します。専門家に委託して報告書を受け取るタイプと、自社で継続的に診断を回すSaaSタイプがあります。後者は、報告書を受け取る委託とは目的が異なり、日々の開発・運用のなかで脆弱性を検査し続けたい場合の選択肢です。
| サービス名 | CoWorker 脆弱性診断サービス | Aikido Security |
|---|---|---|
| タイプ | 委託型 専門家に依頼して報告書を受け取る | 自己運用型SaaS 管理画面で自動・継続的に検査 |
| 診断の進め方 | AI「Red Agent」の自動解析＋社内の専門家による最終確認 | SAST・SCA・DAST・CSPMを管理画面で自動スキャン |
| 主な診断対象 | ソースコード・設計書 稼働中のWebアプリ・API | ソースコード・依存ライブラリ クラウド設定・稼働中のWebアプリ |
| ペネトレーションテスト | ●実践攻撃シミュレーション診断として提供 | △人手のペンテストはAndGoの別サービス。SaaSは自動スキャンが主軸 |
| 報告書・レポート | 報告書をPDF納品（最短3営業日） | スキャン結果を管理画面で確認 PDF・CSVで出力 |
| 継続的な診断 | △四半期・月1回の定期診断も相談可（委託のつど実施） | ●開発・運用のなかで自動で継続実行 |
| 日本語サポート | ●国内で開発・診断 | ●AndGoが日本語窓口（製品本体は英語） |
| 料金 | ソースコードAI診断15万円〜 （Lite 50万円／Standard 100万円／Professional 150万円） ※MCB FinTechカタログの掲載情報より・2026年10月時点 | Basic 年額3,780ドル／Pro 年額7,560ドル （利用者10人までで月額5万円台〜、請求は日本円） ※AndGoの案内より・2026年11月時点。無料のDeveloperプランあり |
| こんな場合に向く | 報告書を専門家に任せ、ペネトレーションテストまで依頼したいとき | 自社で継続的に脆弱性を検査し続けたいとき |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
1. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker 脆弱性診断サービスは、自社開発のAI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた診断サービスです。診断メニューは「ソースコードAI診断」「動的脆弱性診断（Web／API）」「実践攻撃シミュレーション診断（ペネトレーションテスト）」の3つで、ソースコード単体の診断から実践的な攻撃検証まで段階的に選べます。
報告書は、プレスリリースによれば診断開始から最短3営業日でPDF形式で納品されます。
料金は、公式サイトでは通常50万円からと案内されており、MCB FinTechカタログの掲載情報では、最小構成のソースコードAI診断が150,000円、Web・APIの動的診断を含むプランがLite 500,000円、Standard 1,000,000円、Professional 1,500,000円と示されています（2026年10月時点）。
ソースコードだけでなく、稼働中のWebアプリ・APIや実践的な攻撃検証まで任せたい場合に向いています。
2. Aikido Security（株式会社AndGo）
ソースコード・依存ライブラリ・クラウド設定・稼働中のWebアプリを1つの管理画面で検査するSaaSが、Aikido Securityです。日本では株式会社AndGoが販売と問い合わせの窓口を担っています。
ソースコード診断（SAST・SCA）や動的診断（DAST）、クラウド設定診断（CSPM）を自動で継続的に回せるため、一度きりの委託ではなく、開発や運用のなかで脆弱性を検査し続けたい場合に向いています。
料金は、AndGoの案内でBasicが年額3,780ドル、Proが年額7,560ドル、Customは要問い合わせで、年間契約・利用者10人までの場合で月額5万円台からとされています（2026年11月時点、請求は日本円での案内）。
無料で試せるDeveloperプランもあります。ただし、人手によるペネトレーションテストはAndGoが別サービスとして案内しているため、自動スキャンによる継続診断を主軸に検討するとよいでしょう。
ここで取り上げた2社以外にも、脆弱性診断・セキュリティ診断のサービスは数多くあります。診断方法のタイプや費用相場、自社に合う選び方を一覧で見比べてから検討したい場合は、次の記事でまとめて整理しています。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
まとめ
ペネトレーションテストの報告書は、エグゼクティブサマリー、テスト範囲・手法、発見した脆弱性と証跡、リスク評価、対策・再検査の計画、付録という章立てでまとめられるのが一般的です。これはNISTやOWASP、PTESといった標準が示す構成とおおむね共通しており、章立てがこれらに沿っているかは、報告書の品質を見極める手がかりになります。
危険度はCVSSのスコアで示されますが、スコアはあくまで深刻度であり、自社の環境を踏まえてリスクとして読み替える必要があります。
受け取った報告書は、経営層・技術チーム・取引先それぞれに章を使い分けて示し、対策・再テスト・機密管理まで段取りをつけることで、はじめて投資に見合う成果になります。報告書の作成や継続的な診断をどこに任せるかを検討する際は、各サービスの資料で対応範囲や料金を比べてみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. ペネトレーションテスト報告書とは何ですか？
A. ペネトレーションテスト報告書とは、攻撃者の視点で侵入を試みた結果として、発見した脆弱性・そのリスク評価・是正の指針をまとめた、テストの最終成果物です。米国NISTのガイドライン（SP 800-115）も、報告書を「発見した脆弱性を記述し、リスク評価を示し、弱点をどう是正するかの指針を与えるもの」と位置づけています。
一般には、エグゼクティブサマリー、テスト範囲・手法、発見した脆弱性と証跡、リスク評価、対策・再検査の計画、付録といった章で構成されます。
Q. ペネトレーションテスト報告書は内部テストと外部テストでどう違いますか？
A. ペネトレーションテスト報告書は、内部テストでは社内ネットワークの内側から、外部テストではインターネット側からの侵入可否を検証した結果である点が異なります。想定する攻撃者の立ち位置が違うため、報告書に記載される対象資産や攻撃経路、見つかる脆弱性の種類も変わります。
報告書のテスト範囲・手法の章で内部／外部のどちらを前提にしたかを確認すると、その結論をどこまで一般化してよいかを判断できます。
Q. 報告書のエグゼクティブサマリーとテクニカルレポート（技術詳細）は何が違いますか？
A. 報告書のうち、エグゼクティブサマリーは経営層向けに事業リスクを専門用語を避けて要約した部分、テクニカルレポートは技術者向けに脆弱性ごとの再現手順や証跡まで詳述した部分です。同じ報告書でも読む相手によって使う章が分かれ、経営層への報告ではサマリーを、技術チームの修正ではテクニカル部分を使います。質の高い報告書は、この二層構成でどちらの読み手も必要な情報にたどり着けるようになっています。
Q. ペネトレーションテスト報告書の危険度（深刻度）は誰がどのように決めているのですか？
A. 報告書の危険度は通常、テストを実施したベンダーが、CVSS（共通脆弱性評価システム）のスコアを基本に、脆弱性の種類や事業への影響を加味して割り当てます。ただしCVSSの基本スコアは深刻度を測るものでリスクそのものではないと、仕様を定めるFIRSTも明言しています。
同じスコアでも、外部に露出した資産か社内からしか到達できない資産かで実際の優先度は変わるため、付録の評価基準で割り当ての根拠をたどれるかを確認するとよいでしょう。
Q. PCI DSS対応のために専用の報告書形式は必要ですか？
A. PCI DSS専用の決まった報告書テンプレートが定められているわけではありませんが、要件11.4が求めるペネトレーションテストの実施範囲・悪用可能な脆弱性の是正・再テストの結果が、報告書に記載されている必要があります。取引先や監査にPCI DSSの証跡として提出する場合は、これらの要素が報告書に含まれているかを、発注時にベンダーへ確認しておくと安全です。
Q. ペネトレーションテストとTLPTでは報告書はどう違いますか？
A. TLPT（脅威ベースのペネトレーションテスト）の報告書は、脅威インテリジェンスに基づく実戦的な攻撃シナリオと、その再現結果を中心に構成される点が、通常のペネトレーションテスト報告書と異なります。TLPTは主に金融機関などで、実際の攻撃者の手口を想定した高度な検証として用いられます。章立ての基本構成は共通しますが、どの脅威シナリオをどこまで再現できたかの記述が報告書の主眼になります。
Q. ペネトレーションテスト報告書に再テスト（再検査）は標準で含まれますか？
A. 再テストが報告書やサービスに標準で含まれるかはベンダーによって異なり、別料金となる場合もあります。脆弱性の対策後に、その問題が確実に解消されたかを再テストで確認することは重要なので、再テストの計画や費用、実施期限が報告書・契約に含まれているかを、発注前に確認しておくとよいでしょう。
脆弱性診断・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、ペネトレーションテストや脆弱性診断サービスの最新資料を無料で一括請求できます。診断の対応範囲や料金、報告書の形式を資料でまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
