もし自社が不正アクセスやウイルス感染に遭ったとき、「何が起きたのか」を後から追えるだけのログが、今十分に残っているでしょうか。多くの機器を初期設定のまま運用していると、いざ調査が必要になった段階で肝心のログが欠けていた、という事態になりかねません。
インシデントに備えてログを整えるうえで迷いやすいのは、「どの機器のログを・どれくらいの期間・どう守りながら残せばよいか」という具体的な線引きです。ログが重要だと分かっていても、自社の環境に当てはめて判断できる基準はなかなか見つかりません。
本記事では、インシデント調査に備えて取得すべきログを機器・システム別に一覧で整理し、保存期間の目安・改ざん対策・時刻同期といった「残し方」の実務までを解説します。発生後に慌てないためのログ設計の判断材料としてご活用ください。
目次
一括ダウンロードする
インシデント調査にログが必要な理由
セキュリティインシデントが起きたとき、「いつ・どこから・何が侵入し・どこまで影響が及んだのか」を明らかにできるかどうかは、残っているログに大きく左右されます。ログが欠けていると、原因の特定も、被害範囲の確認も、再発防止策の立案も、根拠を欠いたまま進めることになります。
総務省が運営する「国民のためのサイバーセキュリティサイト」も、事後対応を効果的に行うための前提としてログの取得と保管を挙げています。
外部からの不正アクセスやウイルス感染により、組織内部からの情報漏洩等の事故が発生してしまった場合、そのことにいち早く気づき、被害状況や影響範囲の調査などの事後対応を効果的に行うためには、監査ログ（通信記録）の取得と保管が重要になります。
出典：国民のためのサイバーセキュリティサイト／監査ログの管理｜総務省
ログは、インシデントが起きてから取得を始めても間に合いません。平常時から「どの機器の・どのログを・どれだけの期間」残しておくかを設計しておくことが、発生後の調査を左右します。次章では、まず取得対象となるログを機器・システム別に整理します。
出典・参考資料（1件）
- 出典：国民のためのサイバーセキュリティサイト／監査ログの管理｜総務省（リンク）
【機器・システム別】取得すべきログ一覧
ここからは、インシデント調査に備えて取得しておきたいログを、機器・システム別に整理します。総務省は監査ログの具体例として、ファイアウォールの通信、認証の成功・失敗、Webサーバーやデータベースサーバーへのアクセス、パソコンの操作など12種類を挙げています。
本記事ではこれらを「何のためのログか」で捉え直し、以下の6種類に整理しました。大きくは、誰が何をしたか・どこと通信したか・何が起きたか、の3つの観点に分かれ、総務省が挙げる例の多くもこの6種類に対応します。
以下は、取得すべきログの種類と、それぞれがインシデント調査で何に役立つか、保存期間の目安をまとめた一覧です。保存期間の目安の根拠は後述の「保存期間の目安」で詳しく解説します。
| 認証ログ（ログイン成功・失敗） | 端末の操作ログ | 通信のログ（ファイアウォール・プロキシ） | 名前解決のログ（DNS） | サーバー・アプリケーションのログ | クラウドサービスの監査ログ | |
|---|---|---|---|---|---|---|
| 主な取得元 | 各種サーバー・業務システム・ID管理（IDaaS）・VPN | 従業員のPC（Windows / macOS） | ファイアウォール・Webプロキシ・IDS／IPS | DNSサーバー | Webサーバー・ファイルサーバー・データベースサーバー・業務アプリ | SaaS・IaaSの操作・アクセス記録 |
| 調査で分かること | 誰のアカウントが・いつ・どこからログインしたか。不正ログインや総当たり攻撃の兆候、乗っ取られたアカウントの特定に使います。 | 誰が・いつ・どのファイルを操作・持ち出したか。内部不正や情報漏えいの調査、端末起点の感染の追跡に使います。 | 社内外のどこと通信したか。外部からの侵入経路や、感染端末が外部へ発信する不審な通信（C2通信）の痕跡を確認できます。 | どのドメインへアクセスしたか。不正なサイトへの接続や、マルウェアの通信先の特定に使います。 | どのデータへアクセス・改ざんがあったか。被害範囲の特定や、処理の異常終了の確認に使います。 | クラウド上で誰が・何を操作・ダウンロードしたか。設定変更や大量ダウンロードなど、クラウド経由の情報漏えいの調査に使います。 |
| 保存期間の目安 | 1年以上 | 1年以上 | 1年以上 | 2年以上 | 6か月〜1年以上（サーバーの種類による） | 各サービスの設定に依存（1年を目安に延長を検討） |
※保存期間の目安は、JPCERT/CCがログ種別ごとに示す参考値（後述）を本記事の区分に当てはめたものです。認証・操作ログは取得元の機器区分（端末・サーバー＝ホスト等）に準じます。クラウド監査ログは各サービスの仕様・契約により取得可否と保持期間が異なります。
「誰が何をしたか」を記録する認証・操作のログ
アカウントへのログイン成功・失敗の記録と、端末の操作ログは、インシデントの「人」を追うための基本です。認証ログがあれば、通常と違う時間帯・場所からのログインや、ログイン失敗の連続（総当たり攻撃の兆候）を後から確認できます。
端末の操作ログは、どのPCで・誰が・どのファイルを扱ったかを残すため、内部不正や情報の持ち出しの調査、感染した端末を起点とした被害の広がりの追跡に役立ちます。認証ログだけではアカウントの動きしか分からないため、端末側の操作ログと組み合わせると、実際の行動まで追えるようになります。
端末の操作ログで具体的にどこまで記録できるのか（ファイルの持ち出しやUSB接続、Webサイトの閲覧まで追えるのか）や、Windowsの標準機能での確認方法を詳しく知りたい方は、以下の記事で解説しています。
「どこと通信したか」を記録する通信のログ
ファイアウォール・プロキシ・DNSサーバーのログは、社内外のどこと通信したかを示します。JPCERT/CC（JPCERTコーディネーションセンター）は、攻撃者が外部から内部システムを遠隔操作している場合、その通信がファイアウォールを通過し痕跡が残る可能性があると指摘しています。
攻撃者が外部にいて、内部のシステムを遠隔から操作している場合には、そのための通信が Firewall を通過しており、その痕跡が Firewall のログとして記録されている可能性がある
出典：高度サイバー攻撃への対処におけるログの活用と分析方法（1.2版）｜JPCERT/CC
DNSサーバーのログは、どのドメインに接続したかを記録するため、マルウェアが外部の指令サーバーと通信した痕跡や、不正サイトへの接続を特定する手がかりになります。通信のログは量が多くなりやすいため、後述する集約・長期保存の仕組みとあわせて設計することが大切です。
「何が起きたか」を記録するサーバー・クラウドのログ
Webサーバー・ファイルサーバー・データベースサーバーのアクセスログや、アプリケーションの処理結果のログは、どのデータが参照・編集・持ち出されたかを示し、被害範囲の特定に直結します。総務省も、ファイルの参照や編集の成功・失敗、データベースサーバーへのアクセスを監査ログの具体例に挙げています。
近年はSaaSやIaaSといったクラウドサービス上に重要なデータを置く企業が増えており、クラウド側の監査ログ（誰が・何を操作・ダウンロードしたかの記録）も調査対象として欠かせません。クラウドの監査ログは取得の可否や保持できる期間がサービスごとに異なるため、契約時や設定時に確認しておくと安心です。
出典・参考資料（2件）
取得したログの保存・管理で押さえる3つのポイント
取得すべきログが分かったら、次は「どう残すか」です。取得したログを調査に使えるものにするには、保存期間・改ざん対策・時刻同期の3つを押さえておく必要があります。順に解説します。
ログの保存期間の目安
保存期間は「組織ごとに適切に」と説明されることが多く、具体的な数字が分からず迷いがちです。目安としてまず参考になるのが、JPCERT/CCが示す「1年」という値です。
JPCERT/CC では、インシデント対応支援や高度サイバー攻撃の調査等の結果から、ひとつの参考値として１年分のログを保存することを推奨している。
出典：高度サイバー攻撃への対処におけるログの活用と分析方法（1.2版）｜JPCERT/CC
攻撃は侵入からしばらく潜伏した後に発覚することが多く、発覚した時点で遡れる期間が短いと、侵入の起点までたどり着けません。JPCERT/CCは同じ研究のなかで公開している資料で、ログの種類ごとにも保存期間の目安を示しており、以下のように整理されています。
| DNSサーバーのログ | プロキシサーバーのログ | ファイアウォールのログ | ホスト（端末・サーバー）のログ | その他のサーバーのログ | |
|---|---|---|---|---|---|
| 保存期間の目安 | 2年以上 | 1年以上 | 1年以上 | 1年以上 | 6か月以上 |
※JPCERT/CC「ログを活用した高度サイバー攻撃の早期発見と分析」の推奨保存期間にもとづく。
業界によっては、規制やガイドラインで保持期間が定められている場合もあります。たとえばクレジットカード業界のセキュリティ基準であるPCI DSSについて、JPCERT/CCの報告書は、即時に分析できるオンライン保存で3か月、オフライン保存で1年という監査証跡の保持要件を紹介しています。自社が該当する規制がある場合は、公式の要件を直接確認したうえで、それを優先してください。
なお、米国NISTのガイドライン（SP 800-92）は具体的な年数を定めておらず、組織のリスク低減と、ログ管理にかけられる時間・コストのバランスで保存方針を決めるべきとしています。長期保存のコストを抑える方法として、JPCERT/CCは直近3か月分をすぐ使えるオンラインに、それ以降をオフラインに移す運用を挙げています。
出典・参考資料（2件）
ログの改ざん・消去を防ぐ保管方法
ログを取得していても、攻撃者に消されたり書き換えられたりしては調査に使えません。JPCERT/CCは、攻撃者がログファイルを削除したり自身のアクセス記録を消したりする事例がよく見られるとし、各機器のログを集約して長期保存に適したサーバーに保存することを推奨しています。
総務省も、ログを機器本体ではなく別のログ管理システムで保管することを推奨しています。
ログは、収集した機器の本体内ではなく、ログ取得のために別途ログ管理システムなどを設計し、そこで保管を行うことが推奨されます。そうすることで、ログの改ざんなどの不正行為からの保護だけでなく、ログ解析プログラムによる可視化処理を行ったり、保存期間の制御なども行いやすくなったりします。
出典：国民のためのサイバーセキュリティサイト／監査ログの管理｜総務省
実務では、次のような対策で改ざん・消去への耐性を高めます。自社の運用に取り入れられているか確認してみてください。
- 各機器のログを、機器本体ではなく別のログ管理サーバーへ集約して保存する
- ログ管理サーバーへのアクセス権限を最小限に絞り、閲覧・削除できる人を限定する
- 一定期間を過ぎたログは、書き換えできない外部記憶媒体やオフライン環境へ退避する
- ログ自体のバックアップも、通常のデータと同様に取得する
ログやそのバックアップを通常のネットワークから切り離しておくべき理由は、実際の被害傾向にも表れています。
現状、ランサムウェア攻撃を受けた企業のうち、約8割近くでバックアップデータも潰されていると、警察からも発表されています。バックアップ経路は通常のネットワーク上にあるため、ランサムウェアを仕掛けてきた攻撃者にもたどり着けてしまうものがほとんどだからです。
米国NISTのガイドライン（SP 800-92）も、ログを集中管理し、保管したログの機密性と完全性を保護すること、元のログが改ざんされていないことが証拠としての価値につながることを挙げています。
出典・参考資料（2件）
複数機器のログを突き合わせる時刻同期（NTP）
インシデント調査では、複数の機器のログを時系列に並べて「攻撃がどう進んだか」を再現します。このとき各機器の時刻がずれていると、本来の順序が分からなくなり、ログを突き合わせた分析が成り立ちません。総務省は時刻同期の必要性を次のように説明しています。
ログを取得する場合、各コンピュータ間でシステムの時刻を一致させておく必要があります。この時刻の同期が不適切であると、ログに記録された時刻がずれてしまい、各システム間でログを相関的に分析することが困難になります。
出典：国民のためのサイバーセキュリティサイト／監査ログの管理｜総務省
時刻を合わせる手段としては、NTP（Network Time Protocol）が広く使われています。総務省は、NTPが正しく設定され正常に動作していることを確認しておくことが重要だとしています。JPCERT/CCやNISTのガイドラインも、同様にNTPの活用を挙げています。確認の観点は次のとおりです。
- サーバー・ネットワーク機器・端末がNTPで同じ時刻源に同期しているか
- NTPが実際に正常動作しているか（設定しただけで止まっていないか）
- 海外拠点やクラウドを含む場合、タイムゾーン（日本時間とUTCなど）の扱いが記録から判別できるか
出典・参考資料（1件）
- 出典：国民のためのサイバーセキュリティサイト／監査ログの管理｜総務省（リンク）
インシデント発生後の調査の流れ
ここまで整えたログが、発生後の調査で実際にどう使われるかを押さえておくと、平常時に何を残すべきかの判断がぶれなくなります。一般的なインシデント対応では、おおむね次の流れで進みます。
- 証跡の保全：関係する機器のログを、上書きや消去が進む前に確保する。稼働中の端末やサーバーの状態も必要に応じて保全する
- 時系列の整理（相関分析）：複数機器のログを時刻でそろえて並べ、侵入から内部での動き、外部への通信までの流れを再現する
- 影響範囲の特定：どのアカウント・端末・データが関係したかを洗い出し、漏えいや改ざんの有無を確認する
この流れを支えるのが、前章までに整えた「機器横断のログ」「十分な保存期間」「改ざんされない保管」「そろった時刻」です。どれか一つでも欠けると、調査はその時点で行き詰まります。
ここではログを使った調査の流れに絞って整理しました。発生直後の初動から、やってはいけないこと、関係省庁への報告義務までを含めた対応全体の手順は、以下の記事で解説しています。
対応記録（インシデント記録）の残し方
機器のログとは別に、インシデント対応そのものの記録も残しておくと、事後の振り返りや報告に役立ちます。発見日時、事象の内容、関係したデータやアカウント、とった封じ込め措置、通知の判断、再発防止策までを時系列で記録しておくと、調査の経緯と判断の根拠が後から追えます。
JPCERT/CCも、調査項目をあらかじめ文書化しておくことや、タイムラインを作成して影響範囲を把握することの重要性を挙げています。平常時に記録のひな形を用意しておくと、発生時に慌てず対応に集中できます。
出典・参考資料（1件）
- 出典：高度サイバー攻撃への対処におけるログの活用と分析方法（1.2版）｜JPCERTコーディネーションセンター（リンク）
自社のログ設定が足りているかの点検観点
ここまでの内容を踏まえ、自社のログ取得・保存の現状を点検するための観点をまとめます。一つでも「わからない」「できていない」があれば、そこが発生後の調査でつまずくポイントになります。
- 認証・端末操作・通信（ファイアウォール／プロキシ／DNS）・サーバー・クラウドのログを、それぞれ取得できているか
- 主要なログを1年以上（DNSは2年以上を目安に）保存できているか
- ログを機器本体だけでなく、別のログ管理の仕組みに集約・保管できているか
- 各機器の時刻がNTPでそろい、正常に動作しているか
- インシデント発生時に、必要なログをすぐ取り出して突き合わせられる状態か
機器が増えるほど、これらを手作業で維持するのは難しくなります。取得が難しい領域から、記録を仕組みで支える手段を取り入れていくのが現実的です。
ログの取得・集約・保存・検索をまとめて担うログ管理システムには、PC操作ログに特化したものから、社内のさまざまなログを一元管理する統合型まで幅があります。タイプ別の違いや料金・機能から製品を比較したい場合は、以下の記事が参考になります。
一括ダウンロードする
自前運用が難しいときのログ管理・調査の選択肢
ここからは、ログの取得が難しい2つの領域——「端末の操作」と「ネットワークの通信」——を押さえる代表的な手段を紹介します。これらはログ全体を一元管理する製品ではなく、取得そのものが課題になりやすい領域を記録する手段です。ログ全体を集約・一元管理する製品を広く比較したい場合は、前の章で案内したログ管理システムの比較記事もあわせてご覧ください。
| サービス名 | Network Blackbox | Eye"247" Work Smart Cloud |
|---|---|---|
| 記録する対象 | ネットワークを流れる通信（フルパケット） | PCの操作（誰が・いつ・何を操作したか） |
| ログの位置づけ | 通信のログ（社内外の通信記録） | 端末の操作ログ（ファイル操作・USB・Web閲覧など） |
| 提供形態 | ミラーリングで導入（通信を複製して取り込む／端末へのエージェント不要） | クラウド（SaaS） |
| 保存・検索の仕組み | 通信を保存し、専用技術で高速検索・内容の復元に対応 | 操作ログをクラウドに保存（保存期間を延長するオプションあり） |
| 主な用途 | 外部からの侵入や不審な通信の事後調査（ネットワーク側の記録） | 内部不正・情報漏えいの調査、労務管理・IT資産管理 |
| 初期費用 | 要問い合わせ | 0円 |
| 月額費用 | 要問い合わせ | 400〜1,100円/台（台数に応じた従量制・税別） |
| 無料トライアル | なし（デモ申請あり） | 14日間 |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
1. Network Blackbox（株式会社クワッドマイナージャパン）
Network Blackboxは、ネットワークを流れる通信をフルパケットキャプチャで取り込み、検知・分析・事後調査までを担うNDR（ネットワーク検出および応答）ソリューションです。イベントログやテキストログを集めるのではなく、通信そのものを保存して後からさかのぼって調べられる点が特徴です。
保存したパケットは高速に検索でき、メールやファイルアップロードなどのユーザー活動を分類・管理し、通信内容を復元する機能もあるため、インシデント発生後に「いつ・どこへ・何が送られたか」を通信記録から確認する用途に対応します。
検知方式は、既知の攻撃を捉えるシグネチャベースに加え、ユーザー行為の異常を捉える方式、送受信データの内容を分析する方式を併用します。
端末側の対策であるEDR（エンドポイントでの検知・対応）や、ログ収集のSIEMとはSyslog・REST API経由で連携する補完的な位置づけで、EDRを入れにくい機器を含めたネットワーク側の記録を残したい企業に向いています。
おすすめ企業：ネットワーク上の通信を漏れなく記録し、インシデント後に通信を遡って調査できる体制を整えたい企業。
2. Eye”247″ Work Smart Cloud（株式会社フーバーブレイン）
PCの操作ログに特化して記録・可視化したい企業に向くのが、フーバーブレインのEye”247″ Work Smart Cloudです。「誰が・いつ・どこで・どれだけ・何を操作したか」をクラウド上に記録し、内部不正による情報漏えい対策や、客観的な労働時間の把握、IT資産管理に活用できます。導入実績は3,000社以上（2026年10月時点）とされています。
初期費用は無料で、契約台数に応じた1台あたりの月額従量制（最低5台から）で利用できます。ログの保存期間を延長するオプションも用意されており、本記事で触れた「操作ログを十分な期間残す」という要件に対応しやすい設計です。14日間の無料トライアルがあり、導入前に自社環境で記録内容を確認できます。
おすすめ企業：従業員のPC操作を記録し、情報漏えいの調査や労務管理に使える端末ログの基盤を手軽に整えたい企業。
ログの記録・調査は、社内セキュリティ対策の一部です。ログ管理に限らず、守る対象（端末・ネットワーク・ID・データなど）ごとに対策の種類と代表サービスを見渡して比較検討したい方は、以下の記事をご覧ください。
社内セキュリティソリューション比較｜守る対象別のタイプ・代表サービスと選び方
社内のセキュリティを強化したいものの、端末の保護から不正アクセス対策、情報漏えいの防止まで課題が広く、何から手をつければよいか判断がつかないという声は少なくありません。テレワークやクラウド利用が定着し、社外に持ち出される端末やIDが増えたこ…
まとめ
インシデント調査に備えるログは、認証・端末操作・通信・サーバー・クラウドを機器横断で取得し、主要なログを1年以上（DNSは2年以上を目安に）保存することが出発点です。そのうえで、別のログ管理の仕組みへ集約して改ざん・消去から守り、NTPで各機器の時刻をそろえておくことで、発生後の調査がはじめて成り立ちます。
まずは自社のログ取得・保存の現状を点検し、不足を洗い出すことから始めてみてください。手作業での維持が難しい領域は、端末の操作やネットワークの通信を記録する製品など、仕組みで補うことも検討しましょう。
一括ダウンロードする
よくある質問（FAQ）
Q. 監査ログとは何ですか？
A. 監査ログとは、不正アクセスや情報漏えいなどの事故が起きたときに、その状況や影響範囲を後から調査するために記録しておく、通信・認証・操作などの記録です。インシデント発生後に「いつ・どこから・何が起きたか」をたどる土台になります。
総務省は監査ログの具体例として、ファイアウォールを通過・拒否した通信、IDS／IPSが監視した通信、認証の成功・失敗、サーバーへのアクセス、パソコンの操作など12種類を挙げています。
Q. インシデント調査のためのログは何を取得すればよいですか？
A. インシデント調査に備えるログは、認証（ログイン成功・失敗）、端末の操作、通信（ファイアウォール・プロキシ・DNS）、サーバー・アプリケーション、クラウドサービスの監査ログを、機器・システム横断で取得するのが基本です。
認証・操作のログで誰が何をしたか、通信のログでどこと通信したか、サーバー・クラウドのログでどのデータに何が起きたかを、それぞれ追えます。これらを組み合わせると、侵入から内部での動き、外部への情報の流れまでを一続きで確認できます。
Q. インシデント調査のためのログの保存期間はどのくらいが目安ですか？
A. インシデント調査のためのログの保存期間は、JPCERT/CCが参考値として示す「1年分」が目安で、DNSサーバーのログはより長い2年以上が推奨されています。攻撃は侵入からしばらく潜伏した後に発覚することが多く、遡れる期間が短いと侵入の起点までたどり着けないためです。
業界によっては規制やガイドラインで保持期間が定められている場合もあるので、自社が該当する規制があればその要件を優先して確認してください。
Q. PCI DSSなど業界の規制がある場合、ログの保存期間はどう考えればよいですか？
A. 業界の規制やガイドラインで保持期間が定められている場合は、JPCERT/CCの参考値よりも、その規制の要件を優先して確認する必要があります。
たとえばクレジットカード業界のセキュリティ基準であるPCI DSSについては、JPCERT/CCの報告書がオンライン保存3か月・オフライン保存1年という保持要件を紹介しています。自社に適用される基準がある場合は、その公式の要件を直接確認して保存方針を決めてください。
Q. ログを改ざんや消去から守るにはどうすればよいですか？
A. ログを改ざん・消去から守るには、各機器のログを機器本体ではなく別のログ管理サーバーへ集約し、アクセス権限を絞ったうえで、古いログは書き換えできない媒体やオフライン環境へ退避するのが有効です。攻撃者はログファイルを削除したり自身のアクセス記録を消したりすることがよくあるためです。
総務省もJPCERT/CCも、機器本体とは別の仕組みで集中管理することを推奨しています。ログ自体のバックアップも、通常のデータと同様に取得しておくと安心です。
Q. ログの時刻同期（NTP）はなぜ必要ですか？
A. ログの時刻同期が必要なのは、各機器の時刻がずれていると、複数のログを時系列に並べて突き合わせる相関分析が成り立たなくなるためです。インシデント調査では、複数機器のログを時刻でそろえて攻撃の進み方を再現します。
NTP（Network Time Protocol）で各機器を同じ時刻源に同期し、設定しただけで止まっていないか正常動作を確認しておくことが大切です。海外拠点やクラウドを含む場合は、タイムゾーン（日本時間とUTCなど）の扱いが記録から判別できるかもあわせて確認しましょう。
Q. SaaSなどクラウドサービスのログも取得すべきですか？
A. クラウドサービスのログも、クラウド上で誰が・何を操作・ダウンロードしたかを示す監査ログとして、調査対象に欠かせません。重要なデータをSaaSやIaaSに置く企業が増えており、設定変更や大量ダウンロードといったクラウド経由の情報漏えいの調査に役立ちます。ただし取得の可否や保持できる期間はサービスごとに異なるため、契約時や設定時に確認し、必要に応じて保持期間を延長しておくとよいでしょう。
Q. ログ管理を自前で続けるのが難しい場合はどうすればよいですか？
A. 自前でのログ管理が難しい場合は、ログの取得・保存・検索を仕組みで支える製品の活用が選択肢になります。機器が増えるほど、取得・保存・時刻同期・改ざん対策を手作業で維持するのは難しくなります。まずは自社のログ取得・保存の現状を点検して不足を洗い出し、端末の操作ログやネットワークの通信記録など、優先して仕組み化したい対象から検討するのがおすすめです。
社内セキュリティ・ログ管理の料金・資料を一括チェック
MCB FinTechカタログでは、ログ管理・操作ログ記録・ネットワーク監視など、社内セキュリティ対策に役立つサービスの最新資料を無料で一括請求できます。機能や料金を見比べて、自社に合う選択肢を検討できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
