社内で使うクラウドサービスが増えるほど、サービスごとのIDとパスワードの管理は煩雑になり、ログインの手間や情報システム部門の負担も大きくなります。この課題を解決する手段として、SAML（Security Assertion Markup Language）を使ったシングルサインオン（SSO：一度の認証で複数のサービスにログインできる仕組み）への関心が高まっています。
ただ、いざ導入を検討すると「SAML連携とは、結局どの仕組みで何と何をつないでいるのか」「自社では何を設定すればつながるのか」が分かりにくい、という声は少なくありません。SAMLの連携は、認証する側（IdP）と利用したいサービス側（SP）が決まった手順で情報をやりとりすることで成り立っています。
本記事では、SAML連携の仕組み（登場人物の役割と認証が通るまでの流れ）から、連携に必要な設定項目、実際の進め方とつまずきやすい点、SAML・OAuth・OpenID Connectの違い、セキュリティ上の注意までを順に解説します。SSOを集約するID基盤（IDaaS）の選択肢も整理するので、設定に着手する前の全体像をつかむ材料としてご活用ください。
目次
一括ダウンロードする
SAML連携とは？
SAML連携とは、認証を担うシステムと、実際に利用するサービスとの間で、ログインに必要な情報を安全にやりとりする仕組みです。SAMLは、異なるシステム（ドメイン）の間で認証・認可の情報を交換するために標準化された規格で、標準化団体OASISによって策定されています。
利用者のパスワードそのものをサービス側へ渡すのではなく、「認証が済んだ」という証明書のようなデータを受け渡すことで、1回のログインで複数のサービスを使えるようにします。
Microsoftの公式ドキュメントでは、SAMLは次のように説明されています。
Security Assertion Markup Language (SAML) は、ID プロバイダー (IdP) とサービス プロバイダーの間で認証と承認データを交換するためのオープン標準です。 SAML は、セキュリティ アサーション用の XML ベースのマークアップ言語です。これは、サービス プロバイダーがアクセス制御の決定を行うために使用するステートメントです。
出典：Microsoft Entra ID を使用した SAML 認証｜Microsoft Learn
SAML連携の登場人物（IdP・SP・ユーザー）
SAML連携は、3つの登場人物で動きます。SAMLの仕様では、この3つのロール（役割）が定義されています。
- IdP（アイデンティティプロバイダー）：ユーザーの本人確認（認証）を行う側。社内のID基盤やIDaaSがこれにあたります。
- SP（サービスプロバイダー）：ユーザーが実際に使いたいサービス側。各種クラウドサービスやWebアプリがこれにあたります。
- ユーザー（プリンシパル）：ログインしてサービスを使う利用者本人。
SAMLで連携すると、ユーザーはIdPで一度本人確認を済ませれば、連携済みの複数のSP（サービス）へIDとパスワードを入れ直さずにアクセスできます。「どのサービスのログインをどのIdPに集約するか」を決めるのが、SAML連携の設計の出発点になります。
SAMLアサーションとは（パスワードの代わりに渡る本人情報）
SAML連携でIdPからSPへ渡されるデータが「SAMLアサーション」です。ユーザーのパスワードそのものを渡す代わりに、「このユーザーは確かに本人確認が済んでいる」という情報をXML形式でまとめ、IdPが発行します。Microsoftの公式ドキュメントでは、このアサーションを次のように説明しています。
トークン：プリンシパル (ユーザー) に関する IdP によって行われたクレームのセットを含む SAML アサーション (SAML トークンとも呼ばれます)。 認証情報、属性、および認可決定ステートメントが含まれています。
出典：Microsoft Entra ID を使用した SAML 認証｜Microsoft Learn
SAMLの規格では、アサーションに含められるステートメント（記述）として3種類が定義されています。いつ・どのような方法で認証したかを示す「認証ステートメント」、氏名やメールアドレスなどの属性を示す「属性ステートメント」、ユーザーに許可された操作を示す「認可決定ステートメント」です。SPは受け取ったアサーションの内容をもとに、アクセスを許可するかどうかを判断します。
SAML連携で認証が通るまでの流れ（SP-initiated / IdP-initiated）
ここからは、登場人物が何をどの順にやりとりしてログインが通るのかを見ていきます。SAMLの認証の流れには、どこからログインを始めるかによって「SP-initiated」と「IdP-initiated」の2つの方式があります。
SP-initiated方式の流れ
SP-initiatedは、ユーザーが使いたいサービス（SP）側からログインを始める方式で、最も一般的な流れです。認証が通るまでの流れは次のとおりです。
- ユーザーが、ブックマークやリンクからSP（使いたいサービス）のページにアクセスする。
- SPにまだログイン状態がないため、SPが認証リクエストを作り、ブラウザをIdPのログイン画面へ転送（リダイレクト）する。
- IdPがユーザーの本人確認を行う。有効なログイン状態がなければ、IDとパスワードなどの入力を求める。
- 認証が済むと、IdPが認証状態を表すSAMLアサーションを作成し、改ざんを防ぐためにデジタル署名を付けて、ブラウザ経由でSPへ返す。
- SPが署名を検証してアサーションの内容を確認し、ログイン状態を作って、ユーザーが最初にアクセスしようとしたページを表示する。
出典・参考資料（1件）
IdP-initiated方式の流れ
IdP-initiatedは、ユーザーがすでにログインしているIdPのポータル画面から、各サービスへ移動する方式です。認証が通るまでの流れは次のとおりです。
- ユーザーがIdPにログインする。ログイン状態がなければ、ここで本人確認を行う。
- IdPのポータルに並ぶサービスのリンクから、使いたいSPを選ぶ。
- IdPが認証状態を表すSAMLアサーションを作成し、デジタル署名を付けて、ブラウザ経由でSPへ送る。
- SPが署名を検証して内容を確認し、ログイン状態を作ってサービスを表示する。
この方式を使うには、IdP側に各SPへのリンク（遷移先）をあらかじめ設定しておく必要があります。
出典・参考資料（1件）
2方式の違いとどちらを使うか
2つの方式の違いは、ログインの起点です。SP-initiatedはユーザーが使いたいサービスのURLから始めるため、ブックマークや各サービスへの直接アクセスが多い通常の業務に向いています。
一方のIdP-initiatedは、IdPのポータルを入り口にして、そこから各サービスへ移動する使い方に向いています。多くのサービスではSP-initiatedが基本となり、ポータルからの一覧アクセスを使いたい場合にIdP-initiatedを併用する、と整理できます。
一括ダウンロードする
SAML連携に必要な設定項目
仕組みが分かると、次に気になるのが「連携を成立させるには、具体的に何を設定すればよいのか」という点です。SAML連携では、IdPとSPがお互いを信頼してアサーションをやりとりできるよう、いくつかの情報を交換・設定します。代表的な設定項目は次のとおりです。
| SAML連携に必要な主な設定項目 | メタデータ | 署名証明書 | エンティティID（Entity ID） | ACS URL（アサーション コンシューマー サービスURL） | 属性マッピング（クレーム） | バインディング |
|---|---|---|---|---|---|---|
| 役割（何のための情報か） | IdPとSPが互いの接続先URLや証明書をまとめて記述したXMLファイル。これを交換・取り込みすると、個別の値を手入力せずに設定を進められます。 | アサーションに付けたデジタル署名を、SPが検証するための公開鍵（証明書）。改ざんや偽造を防ぎます。 | IdP・SPそれぞれを一意に識別する名前（識別子）。どのIdPとどのSPの連携かを特定します。 | IdPが発行したアサーションの送り先となる、SP側の受け取り口のURL。 | IdPが持つユーザー情報（メールアドレス・氏名など）を、SP側のどの項目に対応させるかの対応付け。 | SAMLのメッセージをHTTPでどう運ぶかの方式（HTTP RedirectやHTTP POSTなど）の取り決め。 |
| 連携時のポイント | 多くのIdP/SPはメタデータURLを公開しており、URLを取り込む方式が推奨されます。 | メタデータ経由で自動取得すると、証明書の更新時も連携が途切れにくくなります。 | IdP側・SP側で指定する値が一致している必要があります。 | SP側が提示する値を、IdP側に登録します。メタデータで解決される場合もあります。 | 既定ではメールアドレスを識別子に使う製品が多く、何をキーにするかを決めておきます。 | IdP・SPの双方が対応する方式を選びます。 |
※設定項目の名称・入力値は製品によって異なります。実際の設定値は各IdP・SPの公式ドキュメントをご確認ください。
これらのうち「メタデータ」「署名証明書」「エンティティID」「ACS URL」「属性マッピング」は、実際のIdP連携の設定画面でも使われる項目です。たとえば業務自動化サービスのUiPathの公式ドキュメントでは、IdPの設定に必要な情報として次のように案内しています。
ページの上部には、ID プロバイダーの構成に必要な UiPath の情報 ( メタデータ URL 、 アサーション コンシューマー サービス URL 、 エンティティ ID ) が表示されます。これらをコピーして保存し、ID プロバイダーを設定します。
出典：SAML 連携を設定する – Automation Cloud｜UiPath ドキュメント
「バインディング」はSAMLの規格で定められた用語で、SAMLのメッセージを実際の通信プロトコル（HTTPなど）に対応付ける方式を指します。設定項目の具体的な名称や入力手順はIdP・SPごとに異なるため、実際の連携では各サービスの公式ドキュメントに沿って値を登録していくことになります。
SAML連携の進め方とつまずきやすい点
設定項目が分かったら、実際の連携作業に入ります。製品によって画面や手順は異なりますが、進め方の大枠は共通しています。
連携の進め方の全体ステップ
連携作業は、大きく次の4つのステップで進みます。
- SP側の管理画面で、連携に必要な情報（メタデータURL、ACS URL、エンティティIDなど）を取得する。
- 取得した情報をIdP側に登録し、IdPが認証を発行する側として連携するための設定を行う。
- IdP側のメタデータ（接続先URLや署名証明書）をSP側に取り込み、双方がお互いを信頼できる状態にする。
- 実際にログインを試し、SSOで正しくアクセスできるか、既存のユーザーとの対応が正しいかをテスト・検証する。
IdPとSPの両方で管理者権限が必要になるため、担当者が分かれている場合は連携して進めるとスムーズです。
グループウェアのdesknet’s NEOの公式FAQでも、管理者側で事前設定を行い、利用者が公開されたURLからIdPのログイン画面を経てSSOする、という流れが案内されています。
出典・参考資料（2件）
つまずきやすい点
連携作業では、いくつか事前に押さえておきたい落とし穴があります。
アサーションの暗号化に対応しているか。SAMLの規格では、アサーションを暗号化して機密性を高める方式も定められていますが、すべての製品が対応しているわけではありません。たとえばUiPathの公式ドキュメントでは、次のように明記されています。
既知の制限事項：ID プロバイダーからの暗号化された SAML アサーションはサポートされていません。
出典：SAML 連携を設定する – Automation Cloud｜UiPath ドキュメント
既存のアカウントをどう移行するか。SSOを有効化すると、IdP側のアカウントとSP側の既存アカウントが、同じメールアドレスをもとに紐付けられる製品があります。同じメールアドレスを使い回した非アクティブなアカウントが残っていると、意図しない権限が引き継がれる恐れがあるため、連携前にアカウントを整理しておくことが重要です。
SAMLに対応していないサービスの扱い。連携したいサービスがSAMLに対応していない場合、そのサービスはSAMLによるSSOの対象にできません。その場合は、対応する別の認証方式を検討するか、SSOの対象外として運用方針を分ける必要があります。
出典・参考資料（1件）
SAML・OAuth・OpenID Connectの違い
SAMLとあわせて耳にする規格に、OAuth 2.0とOpenID Connectがあります。名前が似ていて混同しがちですが、それぞれ目的が異なります。SAMLは認証・認可の情報をXMLでやりとりする規格、OAuth 2.0は「認可（アクセス権限の委譲）」のための規格、OpenID ConnectはそのOAuth 2.0の上で「認証（本人確認）」を行う規格です。
| SAML・OAuth・OpenID Connectの比較 | SAML 2.0 | OAuth 2.0 | OpenID Connect |
|---|---|---|---|
| 主な目的 | 認証・認可情報の交換 | 認可（アクセス権限の委譲） | 認証（本人確認） |
| 主な用途 | 企業システム・SaaSのシングルサインオン | 外部アプリへ限定的なアクセスを許可する | Webサービスのログイン・ソーシャルログイン |
| データ・トークン形式 | XML（SAMLアサーション） | アクセストークン | IDトークン（JWT） |
※各規格の公式仕様に基づく整理です。
企業で使うクラウドサービスのSSOには、SAMLまたはOpenID Connectが用いられるのが一般的です。OAuth 2.0は、あるサービスのデータへ別のアプリから限定的にアクセスする「認可」の用途で使われるため、ログイン（認証）そのものを担うのはSAMLやOpenID Connectだと理解しておくと、方式の選択で迷いにくくなります。
出典・参考資料（2件）
SAML連携のセキュリティ上の注意
SAML連携は利便性を高める一方で、認証を1か所に集約する仕組みであるため、運用面で意識しておきたい点があります。
認証を集約することの影響範囲
SSOは、IdPでの1回の認証で複数のサービスにアクセスできるようにする仕組みです。裏を返すと、IdPのアカウント情報が漏えいしたり、IdPが障害で停止したりすると、その影響が連携先のすべてのサービスに及ぶことになります。利便性の高さと、集約したことによる影響範囲の広さは表裏一体であり、だからこそIdP側の認証を堅牢にし、障害に備えておくことが重要になります。
多要素認証の併用と署名・鍵の管理
集約による影響範囲を抑えるための備えは、いくつかあります。まず、IdPでの認証を強化するために、多要素認証（MFA：パスワードに加えて別の要素で本人確認する方式）を併用します。SSOとMFAを提供するIdPは多く、たとえばMicrosoft Entra IDは、SAMLアプリのSSOと多要素認証を提供するクラウド型のIdPと位置づけられています。
また、アサーションの改ざんや偽造を防ぐため、SAMLではアサーションにデジタル署名を付け、受け取ったSP側が署名を検証する仕組みになっています。SAMLのセキュリティに関する公式文書でも、POSTで送られるSAMLレスポンスは署名が必要で、SP側は署名を検証して発行者を確認しなければならない、とされています。
署名に使う証明書（鍵）は定期的に更新（ローテーション）されるため、メタデータURL経由で自動更新できるように設定しておくと、鍵の切り替え時も連携が途切れにくくなります。
出典・参考資料（3件）
SSOをどのID基盤に集約する？SAML 2.0対応のIDaaSという選択肢
SAML連携でSSOを実現するには、認証を担うIdPとなるID基盤が必要です。自社のSSOをどのID基盤に集約するかがまだ決まっていない場合は、SAML 2.0に対応したIDaaS（Identity as a Service：クラウドで提供されるID管理・認証基盤）が有力な選択肢になります。
IDaaSをIdPとして使えば、SAML 2.0に対応した各種クラウドサービスのログインを一元的に集約でき、多要素認証やアカウント管理もあわせて運用できます。
SSOをどのIDaaSに集約するかを本格的に比較・検討したい場合は、主要なIDaaSを選び方・機能・導入事例まで掘り下げた以下の記事が検討の出発点になります。
以下は、SAML 2.0に対応し、IdPとして複数サービスのSSOを集約できる主なIDaaSの比較表です。
| SAML 2.0対応IDaaSの比較 | CloudGate UNO | Okta | Microsoft Entra ID | トラスト・ログイン byGMO | HENNGE One | IIJ ID | Gluegent Gate | OneLogin | Extic | Soliton OneGate | RSA ID Plus | Entrust Identity | SafeNet Trusted Access | JumpCloud | Keycloak | Cisco Duo |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| その他の対応SSO方式 | OpenID Connect・フォームベース認証 | OpenID Connect | OpenID Connect | OpenID Connect・フォームベース・Basic認証 | — | OpenID Connect 1.0 | OpenID Connect・プロキシ認証 | OpenID Connect・SCIM | フォームベース認証 | OpenID Connect・代理認証 | OpenID Connect | OpenID Connect | OpenID Connect・RADIUS | OpenID Connect・SCIM | OpenID Connect・OAuth 2.0 | OpenID Connect |
| 多要素認証（MFA） | FIDO2/パスキー・生体認証・OTP・認証アプリ | Okta Verify・FastPass・FIDO2/WebAuthn・OTP・SMS/音声/メール | Microsoft Authenticator・パスキー(FIDO2)・Windows Hello・証明書・OTP・SMS/音声 | アプリ型/メールOTP・パスキー(FIDO2)・プッシュ通知・顔認証 | 多要素認証(MFA)・デバイス証明書による制御 | FIDO2・デバイス証明書・メールOTP・SmartKey | OTP・ICカード・FIDO/FIDO2・生体認証・証明書認証 | プッシュ・OTP・SMS/音声/メール・WebAuthn/生体 | TOTP・メールOTP・FIDO2(パスキー) | デジタル証明書(クライアント証明書)による多要素認証 | FIDO2/パスキー・生体・プッシュ・OTP(SMS/音声)・ハードウェアトークン | PKI/証明書・スマートカード・FIDO2・プッシュ・OTP・生体 | OTP(ソフト/ハード)・プッシュ(MobilePASS+)・FIDO・PKI証明書・SMS/音声 | パスキー(FIDO2/WebAuthn)・TOTP・プッシュ・JumpCloud Go(端末認証) | ワンタイムパスワード・パスキー(FIDO2/WebAuthn)・段階的認証強化 | Duo Push・パスコード・SMS・電話・FIDO2/WebAuthn・生体 |
| 提供形態 | クラウド（IDaaS）・国産 | クラウド（IDaaS）・海外製 | クラウド（IDaaS）・海外製 | クラウド（IDaaS）・国産 | クラウド（IDaaS）・国産 | クラウド（IDaaS）・国産 | クラウド（IDaaS）・国産 | クラウド（IDaaS）・海外製 | クラウド（IDaaS）・国産 （AD/LDAP等オンプレ連携対応） | クラウド（IDaaS）・国産 | クラウド／ハイブリッド／オンプレ・海外製 | クラウド／オンプレ両対応・海外製 | クラウド（IDaaS）・海外製 | クラウド（IDaaS）・海外製 | OSS（セルフホスト型） | クラウド（SaaS）・海外製 |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
ここでは、SAML 2.0に対応したIDaaSをIdPとして使う一例として、国産でSSO・多要素認証・ID管理を一体で提供するCloudGate UNOを取り上げます。各サービスの詳細な比較・選び方は、前掲のIDaaS比較記事もあわせてご確認ください。
CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNOは、株式会社インターナショナルシステムリサーチが自社開発で提供する国産のクラウド型ID基盤（IDaaS）です。SSO（シングルサインオン）がSAML 2.0・OpenID Connect・フォームベース認証に対応しており、IdPとして複数のクラウドサービスのログインを集約できます。
SSOに加えて、多要素認証（MFA）、FIDO2／パスキーによるパスワードレス認証、アクセス制限、ID管理（プロビジョニング・ライフサイクル管理）までを一体で提供します。Google WorkspaceやMicrosoft 365、Salesforce、Slackなどとの連携に対応し、SAML連携でのSSOを前提にID基盤を整えたい企業が検討しやすいサービスです。
出典・参考資料（1件）
SSOへの集約が情報システム部門の運用にどのような変化をもたらすかについて、同社は独自インタビューで導入事例を次のように述べています。
導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。
まとめ
SAML連携は、認証を担うIdPと、利用するサービスであるSPが、SAMLアサーション（本人確認が済んだことを示す情報）をやりとりすることで、1回のログインで複数のサービスを使えるようにする仕組みです。連携を成立させるには、メタデータ・署名証明書・エンティティID・ACS URL・属性マッピングといった情報をIdP・SP間で交換・設定します。
実際の連携では、SP側で情報を取得してIdPに登録し、メタデータを交換してテストする、という流れが基本です。アサーション暗号化の対応可否や既存アカウントの整理といった点に注意しながら進めるとつまずきにくくなります。
連携するIdP・サービスが決まっている場合は、それぞれの公式ドキュメントに沿って設定を進めましょう。どのID基盤にSSOを集約するかがこれからの場合は、SAML 2.0に対応したIDaaSの比較から検討を始めると、全体像をつかみやすくなります。まずは気になるサービスの資料を無料で一括請求し、自社に合うID基盤を比べてみてください。
一括ダウンロードする
よくあるご質問（FAQ）
Q. SAML連携とは何ですか？
A. SAML連携とは、認証を担うシステム（IdP）と、利用したいサービス（SP）が、SAMLという標準規格に沿ってログイン情報を安全にやりとりし、1回の認証で複数のサービスを使えるようにする仕組みです。パスワードそのものではなく「本人確認が済んだ」という情報（SAMLアサーション）を受け渡す点が特徴で、企業のクラウドサービスのシングルサインオン（SSO）で広く使われています。
Q. SAMLとSAML認証、シングルサインオン（SSO）は何が違いますか？
A. SAMLは認証・認可情報をやりとりする「規格」、SAML認証はその規格を使って本人確認を行う「方式」、SSOは一度のログインで複数のサービスを使えるようにする「仕組み（目的）」を指します。
SAML連携は、SAMLという規格を用いてSSOを実現する、という関係にあります。SSOはSAML以外（OpenID Connectなど）でも実現できるため、SAML＝SSOではない点を押さえておくと整理しやすくなります。
Q. 連携したいサービスがSAMLに対応していない場合はどうすればよいですか？
A. SAMLに対応していないサービスはSAMLによるSSOの対象にできないため、そのサービスが対応する別の認証方式を使うか、SSOの対象外として運用方針を分ける必要があります。
製品によってはSAML以外の連携方式（OpenID Connectや独自のID連携）に対応している場合があるため、まずは各サービスの公式ドキュメントで対応状況を確認します。どうしてもSSOに含めたい場合は、認証を代理するリバースプロキシ型の仕組みを別途検討する選択肢もあります。
Q. SAML連携とOAuth・OpenID Connectはどう使い分ければよいですか？
A. クラウドサービスへのログイン（認証）を集約したいならSAMLまたはOpenID Connect、別のアプリにデータへの限定的なアクセスを許可したい（認可）ならOAuth 2.0、という使い分けになります。
企業システムやSaaSのSSOでは、対応製品が多いSAMLと、モバイルアプリやAPI連携と相性のよいOpenID Connectのいずれかが使われるのが一般的です。実際には、連携したいサービスがどの規格に対応しているかで選ぶのが現実的です。
Q. SAML連携でSSOを有効にすると、既存のアカウントはどうなりますか？
A. 多くの製品では、IdP側のアカウントとSP側の既存アカウントが同じメールアドレスをもとに自動で紐付けられるため、連携前に不要なアカウントを整理しておく必要があります。
使われていない古いアカウントが同じメールアドレスで残っていると、意図しない権限が引き継がれる恐れがあります。紐付けのキーにする属性は製品ごとに異なるため、各サービスの仕様を確認したうえで移行手順を決めると、つまずきにくくなります。
Q. IdPが障害で停止すると、連携先のサービスにログインできなくなりますか？
A. SAML連携は認証をIdPに集約するため、IdPが停止すると、そのIdP経由でログインする連携先サービスにSSOでサインインできなくなる可能性があります。
これは利便性と表裏一体のリスクで、IdPの可用性（冗長化や障害時の代替ログイン手段）をあらかじめ確認しておくことが重要です。あわせて、IdPのアカウント情報が漏えいすると影響が連携先の全サービスに及ぶため、多要素認証（MFA）の併用で認証そのものを堅牢にしておきます。
Q. SAML連携を始めるには、まず何を用意すればよいですか？
A. SAML連携を始めるには、認証を担うIdPとなるID基盤、連携先となるSAML対応サービス（SP）、そして両者で交換するメタデータや署名証明書などの設定情報が必要です。自社のIdP（ID基盤）がまだ決まっていない場合は、SAML 2.0に対応し、IdPとして複数サービスのSSOを集約できるIDaaS（クラウド型のID管理・認証基盤）から検討を始めると、全体像をつかみやすくなります。
IDaaS・SSOの料金・資料を一括チェック
MCB FinTechカタログでは、SAML 2.0に対応したIDaaS・SSOサービスの最新資料を無料で一括請求できます。料金や対応機能を各社の資料でまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
