営業ツールのSSO・SAML対応｜情シス要件の確認手順と代替策

営業ツールの導入を決裁直前まで進めたところで、情シスのセキュリティ審査から「SSO 対応が要件です」と差し戻された。ベンダーの営業担当に確認すると「対応しています」という一言だけが返ってきて、それ以上の粒度に踏み込めない。手元には稟議の差し戻しコメントだけが残り、次に何を聞けばいいのかが分からない。営業ツールの選定でこうした膠着状態に陥るケースは珍しくありません。

やっかいなのは、この状況が「SSO とは何か」を調べても解けないことです。検索して出てくるのはプロトコルの仕組みの解説か、IdP 製品の比較記事がほとんどで、いずれも読者を「SSO の仕組みを導入する側」として想定しています。しかし今まさに困っているのは、すでに社内に IdP がある前提で、目の前の営業ツール 1 本を審査に通そうとしている業務部門の担当者のほうです。

さらに、調べ進めると二つ目の壁にぶつかります。仮に候補ツールが SSO に対応していたとしても、それが最上位プランでしか使えないと分かった瞬間に、話は技術要件からコストの問題へ移ります。逆に明確に非対応だと分かった場合は、「では諦めるしかないのか、それとも別の統制で代替できるのか」という判断を迫られます。どちらに転んでも、判断の基準を持っていないと情シスとの押し問答が延々と続きます。

この記事では、その判断基準を組み立てます。ベンダーの「SSO 対応」という表記を分解して読む方法、そのまま送れる確認 6 問、上位プラン限定だったときの費用比較の型、そして非対応でも審査に出すための代替統制の組み立て方を、順に整理します。読み終えたときに、情シスとの次回打ち合わせに持っていく結論が自分の言葉で言える状態を目指します。

なお、SAML や OIDC といったプロトコルそのものの動作原理には本記事では深入りしません。認証と認可の関係を含めた基礎を押さえたい場合は、認証と認可の違いを整理した記事を先にご覧ください。本記事はその先の、運用と審査の話に絞ります。

営業ツールのSSO要件が一般SaaSと同じ基準では通らない3つの理由

情シスの審査基準を「厳しすぎる」と感じている場合、まず押さえておきたいのは、営業ツールには一般的な業務 SaaS とは異なるリスク構造があるという点です。ここを理解しないまま交渉のテーブルに着くと、「なぜ自分の案件だけ止められるのか」という感情的な対立になりやすくなります。審査側の合理性を先に把握しておくことが、押し問答を解く最初の一手になります。

送信を伴うツールは「乗っ取り」の被害が社外に出る

一般的な社内向け SaaS でアカウントが乗っ取られた場合、まず問題になるのは情報の閲覧・持ち出しです。被害は重大ですが、多くの場合は社内で検知して封じ込める余地があります。

一方、営業ツールは外部への送信という行為を伴います。アカウントを乗っ取られた場合、攻撃者は自社の会社名・担当者名を騙って、社外の企業に対して任意の文面を送信できる状態になります。相手企業に届いた時点で被害は自社の統制範囲の外に出ており、取り消すことができません。送信先が取引先や見込み顧客であれば、信用の毀損は直接的です。

情シスが営業ツールのログイン要件を強めに見るのは、この「被害が自社の名前で外部に出る」という性質があるためです。閲覧系 SaaS のチェックリストをそのまま当てても、審査側が本当に不安に思っている点には答えられません。

営業代行・パートナーへのアカウント貸与という営業部門特有の運用

もうひとつ、営業部門に固有の事情があります。営業活動では、営業代行会社・BPO 事業者・業務委託メンバーといった社外の人にツールのアカウントを渡す運用が発生しやすい点です。

社内システムであれば、アカウントを持つのは雇用契約のある従業員だけであり、退職時には人事部門からの通知によってアカウント停止のトリガーが引かれます。しかし業務委託や代行契約の終了は人事イベントとして流れてこないことが多く、「契約は終わったがアカウントは生きたまま」という状態が生まれやすくなります。ツールの中には送信先企業リストと送信履歴が残っているため、これは営業機密へのアクセス権が社外に残り続けることを意味します。

情シスがこの運用を知っている場合、SSO を要件に挙げる背景には「アカウントのライフサイクルを IdP 側で一元的に握りたい」という意図があります。単にログインを便利にしたいという話ではありません。

情シスが本当に確認したい3点（誰が入れるか・辞めたら消えるか・記録が残るか）

審査で問われている内容を整理すると、多くの場合は次の 3 点に集約されます。

1. 誰が入れるのか: アカウントを持っている人が本人であると確認できるか。パスワードだけで入れてしまわないか。
2. 辞めたら消えるのか: 退職・異動・契約終了のときに、確実にアクセスが止まるか。止まったことを確認できるか。
3. 記録が残るのか: 誰がいつ何をしたかを、後から追跡できるか。

SSO はこのうち 1 番に対する代表的な答えであり、後述する SCIM は 2 番に対する答えです。3 番の監査ログについては、営業ツール導入前のセキュリティチェックリストで認証以外の領域とあわせて整理しています。本記事では 1 番と 2 番、つまり認証とアカウントのライフサイクルに絞って掘り下げます。

なお、ログイン記録（認証ログ）と、ツール内で何をしたかの記録（操作ログ・送信履歴）は別物です。「ログは取れます」というベンダー回答を受け取ったときは、どちらのログを指しているのかを必ず区別してください。

「SSO対応」の一言では判断できない｜SAML・OIDC・SCIMの守備範囲を分解する

ベンダーの資料やサイトに書かれている「SSO 対応」という表記は、実態としてかなり幅のある言葉です。この粒度のまま稟議を出すと、審査で二度目の差し戻しを食らう確率が高くなります。まずは、この一言が指し得る範囲を分解しておきます。

「SSO対応」が指し得る4段階（要件を満たすのはどれか）

「SSO 対応」という記載は、おおむね次の 4 段階のいずれかを指しています。

C と D を「SSO 対応」と表記しているベンダーは実在します。特に C は紛らわしく、画面上の見た目は A・B とほとんど変わりません。情シスが求めているのは通常 A または B、つまり自社が管理する IdP を認証の起点に据えられることであり、ボタンの有無ではありません。

この区別は最初の確認で必ず潰しておいてください。「Google アカウントでログインできます」という回答を「SSO 対応」と受け取って稟議に書くと、情シス側で差し戻されるだけでなく、確認の信頼性そのものが疑われることになります。

SAMLとOIDCはどちらでもよいのか（自社IdPの対応状況で決まる）

A と B のどちらであるべきかは、自社の IdP が何に対応しているかで決まります。結論だけ先に言えば、主要な IdP は両方に対応しているため、多くの場合どちらでも要件を満たせます。

Microsoft は、SAML と OIDC の選択について「OIDC は新しいクラウドネイティブな SaaS に適し、SAML は企業顧客の要件・コンプライアンス上の事情・SAML のみをサポートするレガシーな ID プロバイダーの存在から選ばれる」という趣旨の指針を公開しており、顧客層が両方にまたがる場合は両プロトコルをサポートすることを推奨しています（SAML と OpenID Connect: 適切な SSO プロトコルを選択する｜Microsoft Learn）。

実務上の確認ポイントは、プロトコルの優劣ではなく次の 2 点です。

• 自社が使っている IdP での連携実績があるか。Microsoft Entra ID であれば、Entra ID の SaaS アプリ構成ガイドに該当ツールのチュートリアルが掲載されているかが目安になります。掲載がなくても、カスタムアプリケーションとして設定できる場合が多いため「非対応」と即断はできません。
• 設定作業をどちらが行うのか。メタデータ XML の交換や証明書の更新は情シス側の作業になるため、ベンダーの手順書の有無が工数見積もりに直結します。

「SAML でなければダメ」と最初から決めつけず、自社 IdP 側の担当者に「このツールは OIDC 連携だが問題ないか」を確認する形で話を進めるほうが、選択肢を狭めずに済みます。

SCIMは「ログイン」ではなく「アカウントの生死」を扱う別の仕組み

情シスとのやり取りで「SCIM は？」と聞かれて詰まるケースがよくあります。これは SSO とは別のレイヤーの話です。

SCIM はアカウントの作成・変更・削除を自動的に同期するための仕組みであり、SAML が扱うログイン認証とは役割が分かれています（SCIMとは？仕組みやメリット、SAMLとの違い｜wiz LANSCOPE）。SSO は「入るときの本人確認」、SCIM は「アカウントそのものを作る・消す」を担当すると理解すると整理しやすくなります。

なぜ情シスが SCIM を気にするかというと、SSO だけではアカウントが消えないからです。SSO を設定していても、ツール側にアカウントのレコードは残り続けます。IdP 側でユーザーを無効化すればログインは止まりますが、ツール側の管理画面には退職者のアカウントが残り、ライセンス費用も発生し続けます。SCIM があれば、IdP 側の退職処理に連動してツール側のアカウントも自動で無効化・削除できます。

ただし現実には、SCIM に対応していない SaaS や、対応していても上位プランに限られる SaaS が少なくありません。SCIM 未対応の SaaS は SaaS 管理基盤側で台帳化し、棚卸しと削除確認を一元管理するという運用が現実解として案内されています（SCIMとは？自動プロビジョニングの仕組みとSAMLとの違い｜Admina by Money Forward）。営業ツールで SCIM まで揃っているケースは期待しすぎないほうがよく、後述する棚卸し運用の設計で埋める前提に立つのが現実的です。

SSO を有効にしてもIDとパスワードでログインできてしまう問題

見落とされやすい論点がもうひとつあります。SSO を有効にしても、従来どおり ID とパスワードでログインできる状態が残っているケースです。

この状態では、SSO を設定した意味がほぼ失われます。IdP 側でユーザーを無効化しても、本人がローカルのパスワードを覚えていればログインできてしまうためです。退職者のアクセスを止めるために SSO を導入したのに、止まらないという事態になります。

そのため確認すべきは「SSO に対応しているか」ではなく「SSO を強制できるか」です。具体的には、組織単位でローカルログイン（ID・パスワード認証）を無効化し、SSO 経由のログインのみを許可する設定が存在するかどうか。この設定がないツールは、情シスの目には「SSO 対応と名乗っているが統制は効かない」と映ります。

管理者用アカウントだけはローカルログインを残せる仕様になっているツールもあります。これは IdP 障害時の緊急アクセス（ブレークグラスアカウント）として合理的な設計ですが、その場合は「どのアカウントが例外になるのか」「そのアカウントに MFA がかかっているか」まで確認しておくと審査での説明が通りやすくなります。

ベンダーに送る確認6問｜営業ツールのSSO・SAML対応を具体化する質問文

ここまでの内容を、ベンダーへの確認質問に落とし込みます。そのままメールや問い合わせフォームに貼れる形で用意しました。回答の読み方もあわせて記載しているため、返ってきた内容をその場で判定できます。

確認6問の一覧（質問文・確認の意図・回答の読み方）

6 問すべてを一度に送ってかまいません。むしろ小出しにすると往復回数が増え、導入時期が読めなくなります。質問の意図まで添えて送ると、営業担当が技術部門にエスカレーションしやすくなり、回答の精度が上がります。

「対応予定です」という回答をどう扱うか（時期・契約上の担保の有無）

ベンダーから「現在開発中です」「次のアップデートで対応予定です」という回答が返ってくることがあります。この回答は、扱い方を決めておかないと稟議が宙に浮きます。

判断の分かれ目は、契約上の担保があるかどうかです。次の 2 点を追加で確認してください。

• 提供時期が四半期単位以上の粒度で示されているか（「年内」「順次」は時期の明示とは扱わない）
• 提供時に追加費用が発生しないか。上位プランでの提供になる場合、現時点での差額はいくらか

そのうえで、情シスに提示する際は「対応予定」を対応済みとして書かないことが重要です。「現時点では非対応。ベンダーは 20XX 年 Q◯ の提供を予定と回答。提供されるまでは代替統制で運用し、提供後に SSO へ移行する」という書き方であれば、後述する期限付き例外承認の形に接続できます。逆に「近く対応予定なので問題ありません」という書き方をすると、提供が遅れた場合に説明責任が自分に返ってきます。

回答を情シスへ転送するときの添え方

ベンダーの回答をそのまま転送すると、情シス側で再度読み解く手間が発生し、往復が増えます。次の 3 行を冒頭に添えるだけで、レビューの速度が変わります。

1. 結論: 「SAML 2.0 に対応、Entra ID の手順書あり。ただし SSO 強制は不可、SCIM 非対応」のように、6 問の判定結果を一文でまとめる
2. 懸念点: 自分から見て要件を満たさないと思われる項目を先に挙げる（隠さない）
3. 相談事項: 「SSO 強制が不可の場合、どのような代替統制であれば受け入れ可能かご教示ください」のように、判断を求める点を明示する

特に 2 番目を自分から書くことが、交渉を早く進めるうえで効きます。懸念を伏せた資料は必ず指摘され、そこから信頼の回復コストが発生します。

SSOが上位プラン限定だったときのコスト判断（いわゆる「SSO税」）

確認 6 問のうち 4 番目で「SSO は上位プランのみ」と判明した場合、話は技術要件からコストの問題に移ります。ここで感情的に「セキュリティ機能を人質に取っている」と反発しても稟議は通らないため、比較可能な形式に落とし込みます。

認証機能が上位プランに寄せられる背景（海外での議論を含む）

認証機能を最上位プランに閉じ込める価格設計は、英語圏では「SSO tax（SSO 税）」という名前で長く論点化されてきました。ベンダー各社の SSO 追加料金を一覧化したコミュニティ主導のリスト SSOtax.org は、掲載基準を「SSO が標準価格より 10% 以上高いプランに閉じ込められているベンダー」と定めており、掲載されている事例には基本プランの数倍の単価になるものも含まれます。

この価格設計に対しては、「SSO はセキュリティの基礎機能であり、上位プランの付加価値として扱うべきではない」という批判が業界内から出ています（Explaining the backlash to the SSO tax｜1Password）。一方で、SSO 連携の実装・サポートには相応のコストがかかるというベンダー側の事情もあり、議論は単純な善悪では決着していません。

社内の議論でこの背景を共有しておく意味は、「このツールだけが特別におかしい」という前提を外せる点にあります。業界全体の商習慣として存在する構造であると理解できれば、次は感情論ではなく金額の比較に進めます。

年額に直して3案を並べる比較フォーマット

判断材料を揃えるために、選択肢を同じ土俵に乗せます。月額・ユーザー単価のまま比較すると差額が小さく見えるため、必ず年額に直してください。

表の金額欄は空欄のまま社内に共有し、ベンダー回答と自社の席数を入れて埋める使い方を想定しています。重要なのは、案 C を「0 円の選択肢」として扱わないことです。代替統制には棚卸しや MFA 管理といった人手の工数が必ず発生するため、その工数を金額に換算して同じ列に並べないと比較が成立しません。この点を先に自分から提示しておくと、情シスからの信頼が得やすくなります。

席数を絞る折衷案が成立する条件・しない条件

案 B の「一部の席だけ上位プランにする」という折衷案は、成立する場合としない場合があります。

成立しやすい条件:

• ツール側がプラン混在（同一組織内で上位プランと下位プランのユーザーが共存する形）を許容している
• 送信操作を行う人と、結果を閲覧するだけの人が明確に分かれている
• 高リスクな操作（送信・リスト出力・アカウント発行）を行う席だけを上位プランに寄せられる

成立しない条件:

• ツールの価格体系が組織単位のプランであり、ユーザーごとのプラン混在ができない（多くの SaaS がこちら）
• SSO 強制が組織全体にしか適用できず、一部ユーザーだけローカルログインを残す設定ができない
• 席を絞った結果、営業代行など社外メンバーが下位プラン側に残ってしまう

3 番目は特に注意が必要です。リスクが高いのは社外メンバーのアカウントであるケースが多いため、そこを統制の対象外に置く形の席数削減は、コストは下がってもリスクは下がりません。情シスからも通らない可能性が高い組み方です。

SSO非対応の営業ツールを審査に通す代替統制の組み立て方

ここが本題です。SSO 非対応、あるいは上位プランのコストが見合わないと判断した場合に、代替統制で審査に出すという選択肢があります。ただし「気をつけます」という運用努力の表明では通りません。何が代替として認められ、何が認められないのかを整理します。

前提として、これは特定のツールが審査に通ることを保証する話ではありません。判断基準は企業ごとに異なります。ここで示すのは、審査に提出する資料をどう組み立てるかという型です。

代替統制の3層（必須／加点／代替にならないもの）

代替統制は、情シスから見た受け入れられやすさで 3 層に分けて考えると整理しやすくなります。

第1層: ほぼ必ず求められるもの

IP 制限・MFA・権限管理・監査ログを組み合わせる多層防御は、SaaS のアクセス統制における標準的な考え方として整理されています（IPアドレス制限とMFA/SSOの併用｜ロリポップ VPN コラム）。SSO が使えない場合、この組み合わせで本人確認の確からしさを補うという構図になります。

第2層: あると審査が通りやすくなるもの

• 権限の最小化とロール分離: 送信できる人・リストを出力できる人・アカウントを発行できる人を分ける。全員が管理者権限を持つ状態は減点対象になります
• 月次のアカウント棚卸し: 誰がアカウントを持っているかを毎月確認し、記録を残す。担当者と実施日を明記した運用手順として提出します
• 監査ログの取得範囲の明示: ログイン記録・送信履歴がどこまで、どのくらいの期間残るかを事前に確認して記載します
• 退職・契約終了時の停止手順の文書化: 誰が、何をトリガーに、何時間以内に停止するかを決めておきます

第3層: 代替にならないもの

次の項目を代替統制として提出すると、審査で一蹴される可能性が高くなります。

• 「複雑なパスワードを設定します」「定期的に変更します」といったパスワード運用の努力目標
• 「利用者に注意喚起を行います」という周知ベースの対策
• 「不審なログインがあれば気づけます」という検知根拠のない主張
• 「利用者が少ないのでリスクは低い」という規模を理由にした説明

これらに共通するのは、実行されたことを後から確認できない点です。代替統制として機能するのは「設定によって強制されるもの」または「実施記録が残るもの」に限られると考えてください。

期限付き例外承認という着地のさせ方

代替統制を提示しても、「SSO 非対応を恒久的に認めるわけにはいかない」という反応が返ってくることがあります。このときに有効なのが、期限付きの例外承認という形での着地です。

具体的には、次のような形で稟議・審査資料に書きます。

本ツールは現時点で SSO 非対応のため、第1層・第2層の代替統制を実施したうえで例外承認をお願いしたい。例外の有効期限は次回契約更新時（20XX年◯月）までとし、更新時点で SSO 対応が提供されていない場合は、代替ツールへの移行を含めて再審査を行う。

この書き方には 2 つの利点があります。ひとつは、情シス側が「無期限に穴を開ける」という判断をしなくて済むこと。もうひとつは、業務部門側も「今回は通ったが次回は分からない」という前提を共有できるため、ベンダーへの継続的な要望のインセンティブが生まれることです。

SSO 非対応のアプリを統制の対象外として放置せず、例外として管理下に置いたうえで段階的に統制へ取り込んでいくという考え方は、ID 基盤の統合設計でも同様に整理されています（SSOツールが増えるほど統制は弱くなる｜axi-pass）。「対応していないから管理外」ではなく「対応していないから明示的に例外台帳へ載せる」という形に持ち込むことが、審査側との合意点になりやすい構図です。

代替統制を選んだ場合に増える運用工数を先に見積もる

代替統制を選ぶということは、SSO が自動でやってくれるはずだった作業を人手で回すことを意味します。この工数を先に見積もって提示しておくと、後から「運用が回らない」と言われる展開を避けられます。

見積もりに含めるべき項目は次のとおりです。

• アカウント発行・削除の作業時間 × 想定発生回数（入社・異動・退職・委託契約の開始と終了）
• 月次棚卸しの作業時間 × 12 ヶ月
• MFA の再設定対応（端末変更時など）の想定発生回数
• 棚卸し記録の保管・提出にかかる時間

これらを年間の合計時間として出し、前述のコスト比較表の「運用工数の金額換算」欄に入れます。ここまで揃えると、上位プランへの差額と代替統制の運用コストが同じ単位で並び、どちらを選ぶべきかの議論が数字の上でできるようになります。

そして、誰がこの工数を負担するのかを明記してください。営業部門が持つのか情シスが持つのかを曖昧にしたまま承認を取ると、運用開始後に押し付け合いが発生し、棚卸しが形骸化します。

導入後に効いてくる運用設計｜退職者・異動・代行先アカウントの棚卸し

審査を通すことがゴールではありません。SCIM がない環境では、アカウントのライフサイクル管理を人手で回す必要があります。この設計を先に固めておくことが、導入後に統制が形骸化しないための条件になります。

人事イベントとアカウント操作の対応表

まず、どの出来事が起きたときに何をするのかを対応表として決めます。この表をそのまま運用手順書に転記できる形にしておくと、審査資料としても使えます。

太字にした「業務委託・代行契約の終了」が最も漏れやすい項目です。人事部門の退職処理フローには乗らないため、契約管理側から営業ツールの管理者へ連絡が届く経路を明示的に作っておかないと、通知そのものが発生しません。契約書の終了時チェックリストに「利用中の SaaS アカウントの停止」を項目として入れておくのが確実です。

SCIM がない場合の棚卸し頻度と担当の決め方

対応表を決めても、通知の漏れは必ず起きます。そのバックストップが定期棚卸しです。

頻度の目安は、人の入れ替わりの頻度で決めます。営業代行・業務委託を使っており担当者の交代が発生しやすい場合は月次、社内の正社員のみで運用しており人事異動が年 2 回程度であれば四半期ごとでも成立します。判断に迷う場合は月次から始め、運用が安定してから間隔を広げる提案を情シスに出すほうが通りやすくなります。

担当の決め方では、次の 2 つの役割を分けます。

• 棚卸しの実施者: ツールの管理画面からアカウント一覧を出し、在籍・契約状況と突き合わせる人。営業部門側の管理者が担当するのが現実的です
• 棚卸し結果の確認者: 実施結果を受け取り、記録として残す人。情シスまたは営業部門の責任者が担当します

実施者と確認者を同一人物にすると、「実施していないのに実施済みと記録される」リスクを潰せません。審査でもこの点を問われることがあるため、最初から 2 名体制で設計しておくことをおすすめします。

記録として残すものは、実施日・実施者・確認者・アカウント総数・停止したアカウント数・特記事項の 6 項目で足ります。凝った様式は不要で、続けられる粒度に抑えるほうが重要です。

営業代行・パートナーに貸与したアカウントの停止条件

社外メンバーへのアカウント貸与については、貸与時点で停止条件を決めて合意しておきます。契約終了後に交渉すると、データの扱いで揉めます。

貸与前に取り決めておきたい項目は次のとおりです。

• 停止のタイミング: 契約終了日当日か、検収完了日か。引き継ぎ期間を設ける場合はその日数と、その間の権限範囲
• アクセスできるデータの範囲: 自社の送信先企業リスト全体を見せるのか、担当分だけに限定するのか。ツールが組織単位・チーム単位でのデータ分離に対応している場合は、その機能で範囲を絞ります
• 送信履歴の引き渡し範囲: 代行先が実施した送信の履歴を、契約終了時にどちらがどう保持するか
• 再委託の可否: 代行先がさらに別の事業者に再委託する場合、そのメンバーにアカウントを渡してよいか

データの分離設計そのものについては、営業ツールの組織単位データ分離で扱っています。本記事の範囲では、「誰にアカウントを渡し、いつ止めるか」を決めておくことに絞って押さえておけば十分です。

認証要件を営業ツールの選定表と稟議書に落とし込む

最後に、ここまでの内容を実際の文書に転記できる形にまとめます。ツール比較表と稟議書、それぞれに何を書くかを示します。

比較表に追加する認証・アカウント管理の5項目

営業ツールの比較表を作っている場合、認証まわりは次の 5 項目を列として追加すれば審査に必要な情報が揃います。

この 5 列を埋めた比較表があれば、情シスとの打ち合わせで「このツールのここが引っかかる」という議論が具体的にできます。逆に「SSO: ◯／×」の 1 列だけでは、前述したとおり 4 段階のどれを指すのかが伝わらず、確認の往復が発生します。

稟議書のセキュリティ欄に書く3行の型

稟議書のセキュリティ・情報管理の欄には、次の 3 行構造で書くと過不足なく収まります。

1 行目（要件）: 情シスから提示されている要件をそのまま引用する

「SaaS 利用基準に基づき、認証は自社 IdP 連携（SSO）を必須とする」

2 行目（現状）: 候補ツールの実態を、確認 6 問の結果として書く

「本ツールは SAML 2.0 に対応するが、利用には上位プラン（年間差額◯円）が必要。SCIM は非対応」

3 行目（対応方針）: 選択した案と、その理由・期限を書く

「上位プランへの変更を行い SSO を有効化する。SCIM 非対応のため、退職・契約終了時のアカウント停止は営業部門管理者が対応表に基づき実施し、月次棚卸しで確認する」

SSO 非対応で代替統制を選ぶ場合は、3 行目を次のように書き換えます。

「現行プランで導入し、MFA 必須化・IP 制限・共有アカウント禁止・月次棚卸しを実施する。次回契約更新時（20XX年◯月）を期限とする例外承認をお願いしたい。更新時点で SSO が提供されない場合は代替ツールへの移行を含めて再審査する」

稟議書全体の構成や、セキュリティ欄以外の記載項目については、フォーム営業ツール導入の稟議書テンプレートに認証要件以外の項目とあわせた型をまとめています。本記事で整理した内容は、そのセキュリティ欄に差し込む素材として使えます。

次のアクション

情シスとの次回打ち合わせに向けて、手を動かす順序は次のとおりです。

1. 候補ツールのベンダーに確認 6 問を送る（6 問まとめて送る）
2. 回答が揃ったら、比較表の認証 5 項目を埋める
3. 上位プラン限定だった場合は、年額に直した 3 案比較表を作る
4. 非対応だった場合は、代替統制の第1層・第2層から実施可能なものを選び、運用工数を見積もる
5. 稟議書のセキュリティ欄に 3 行の型で記載し、期限付き例外承認の要否を明示する

この 5 ステップを終えた時点で、「このツールをこういう条件で通したい」という自分の言葉での結論が出ているはずです。情シスとの議論は、そこから初めて建設的な形で進みます。

営業ツールの選定では、認証やアカウント管理のような統制の設計と、送信そのものをどう扱うかの設計は地続きの問題です。秋霜堂株式会社が提供する Form Pilot は、企業リスト・送信履歴・文面を組織単位で分離するマルチテナント設計を採用しており、営業代行・BPO 事業者がクライアントごとにデータを混在させずに運用できる構成になっています。また、CAPTCHA の突破は行わず、CAPTCHA 等で完全な自動送信ができないフォームでは Chrome 拡張機能が入力までを自動化し、送信ボタンは人が押すセミオート設計を採っています。フォーム営業の効率化と受信側への配慮を両立する形をご検討中の方は、サービスページをご覧ください。

関連記事

• 営業ツール導入前のセキュリティチェックリスト — 認証以外の 6 領域を含めた情シス確認項目の一覧
• フォーム営業ツール導入の稟議書テンプレート — 稟議書全体の構成と記載項目
• 認証と認可の違い — OAuth・SAML・SSO の役割を発注者向けに整理