no-poach条項付き提携契約テンプレ実務ガイド｜税理士法52条・独禁法・共同サービス設計の論点整理2026

「税理士さんと提携したいが、法律面で何をどう書けばよいか分からない」——これはITベンダーからよく聞く悩みである。一方で税理士法人からは、「ベンダーに紹介した顧客を取られた」「紹介料の受取が税理士法に抵触する懸念がある」という逆の悩みが寄せられる。両者の利害を調整する契約設計の核が、no-poach条項・別契約別請求・顧客書面同意の3点セットである。本記事では、提携契約テンプレート構造と、税理士法第52条、独占禁止法、個人情報保護法の論点を実務目線で整理する。なお、最終的な契約書作成には必ず弁護士レビューを経る前提で、論点整理のたたき台として活用されたい。

提携契約の3つの法務リスク — 概観
税理士法52条 — 非税理士への「あっ旋」の禁止
独占禁止法 — no-poach条項の限界と設計
個人情報保護法 — 顧客情報共有の根拠
提携契約テンプレートの章立て構造
no-poach条項の文言設計
別契約別請求の実装
顧客書面同意のフォーム設計
よくある質問（FAQ）
まとめ

1. 提携契約の3つの法務リスク — 概観

士業とITベンダーの提携契約では、次の3領域でトラブルが発生しやすい。

1.1 リスク1：士業法違反（税理士法・司法書士法・行政書士法）

紹介料モデルは、士業法の名義貸し禁止・あっ旋料受領禁止に抵触する可能性が高い。とくに税理士法第52条（非税理士による税理士業務の禁止）と関連条項は、違反時に税理士側が処分対象となる。

1.2 リスク2：独占禁止法違反

no-poach条項（相互に顧客を奪わない約束）は、過度に広範な合意は独占禁止法上の不当な取引制限に該当するリスクがある。適切な範囲と期間を設定しないと、契約そのものが無効になりうる。

1.3 リスク3：個人情報保護法違反

顧客情報を提携先と共有する際、本人書面同意なしの第三者提供は違法である。士業特有の守秘義務と重ねて、情報共有の法的根拠を常に確認する必要がある。

2. 税理士法52条 — 非税理士への「あっ旋」の禁止

2.1 条文と趣旨

税理士法第52条は、税理士または税理士法人でない者が税理士業務を行うことを禁じている。関連する第37条は、非税理士からのあっ旋料収受も禁じる。この制度趣旨は、税理士の専門責任と独立性の確保である。

2.2 実務上の抵触ケース

ITベンダーが税理士業務（税務申告・税務相談）を事実上行う
税理士が非税理士からあっ旋料を受領する
税理士名義でベンダーが交付申請書を作成する
共同サービスと称して実質的に税理士業務を代行する

2.3 抵触を回避する3原則

業務領域の明確な分離 — 税理士業務と非税理士業務を契約書で明示
別契約・別請求 — 紹介料ではなく、各自が顧客と別契約を結び、別請求を行う
共同サービスの外観整備 — 両社名義で顧客に共同で提供する商品として設計

2.4 共同サービスの設計ポイント

共同サービスは、両社の役割分担と責任範囲を顧客に対して明示することで、名義貸しではないことを外観上担保する。典型的な構造は次の通り。

要素	税理士側	ITベンダー側
顧客契約	税務顧問契約	ITツール契約・PMO契約
請求	税理士から直接	ベンダーから直接
担当者	税理士名明示	プロジェクトマネージャー明示
責任範囲	税務・会計・経営助言	IT導入・運用・効果測定

この構造が維持されていれば、税理士法52条違反リスクは実務上回避できる。

3. 独占禁止法 — no-poach条項の限界と設計

3.1 no-poach条項とは

no-poach条項は、提携先の顧客を自社の別サービスや別契約で勧誘しないことを合意する条項である。士業とベンダーの相互信頼を担保する役割がある。

3.2 独占禁止法上の論点

no-poach条項が過度に広範だと、不当な取引制限または競争制限に該当するリスクがある。具体的には次の条件で違法性が高まる。

対象顧客の範囲が無限定
契約期間が長期（5年超）
契約終了後も無期限で拘束
違反時の制裁が過度

3.3 有効性を高める文言設計

対象を提携を通じて共有した顧客に限定
期間を提携期間中 + 終了後1〜2年程度
例外を明示（顧客自身の自発的なアプローチ、公募案件等）
違反時の損害賠償予定額を合理的範囲で明記

3.4 除外すべきケース

顧客自身が明示的に別契約を希望する場合
公募・入札案件への応札
合併・買収に伴う顧客引継ぎ
提携前から接触していた顧客への継続営業

これらを除外しないと、顧客の自由な取引相手選択権を侵害するとして無効とされうる。

4. 個人情報保護法 — 顧客情報共有の根拠

4.1 第三者提供の原則

個人情報保護法は、個人データの第三者提供には本人の同意が原則必要とする。士業とベンダーの提携では、この原則を常に意識する必要がある。

4.2 実務上の選択肢

書面同意取得 — 顧客から明示的な書面同意を取得（最も堅実）
オプトアウト — 提供の事実を公表し、本人に停止機会を与える（士業法と重なるため推奨度低）
共同利用 — 共同利用目的・範囲を明示して同意不要で利用（用途限定）

士業案件では書面同意取得が標準である。オプトアウト方式は士業特有の守秘義務との整合性に注意を要する。

4.3 同意取得のタイミング

提携案件の提案前に同意を取得するのが最も安全である。提案後に情報共有が必要になった場面で慌てて同意を求めると、顧客の不信感を招きやすい。

5. 提携契約テンプレートの章立て構造

実務で通用する提携契約テンプレートの標準的な章立ては次の通り。

5.1 基本章立て

前文・目的 — 共同サービスの目的、想定顧客像
定義 — 共有顧客・共同サービス・提携業務の定義
業務分担 — 士業業務・ベンダー業務の明確化
契約関係 — 各社が顧客と別契約を結ぶこと
請求・決済 — 別請求・直接受領の原則
no-poach条項 — 相互不勧誘の範囲と期間
個人情報・守秘義務 — 本人同意の取扱、目的外利用禁止
責任範囲 — 各社の業務に起因する責任の分離
紛争対応 — 事故発生時の連絡・対応
契約期間と終了 — 期間・更新・中途解約・終了後の処理
損害賠償 — 違反時の賠償範囲
準拠法・管轄 — 日本法・管轄裁判所の指定

5.2 添付別紙

別紙A：業務範囲一覧表（士業業務・ベンダー業務の対比）
別紙B：共同サービス商品説明書
別紙C：顧客情報共有に関する書面同意書雛形
別紙D：違反時の損害賠償予定額表

6. no-poach条項の文言設計

6.1 推奨文言の骨子

6.2 文言設計の5つのポイント

対象を「共有顧客」に限定 — 両社の既存顧客全般を含めない
期間を明示 — 契約期間 + 終了後1〜2年程度
除外条件を具体的に列挙 — 顧客の自発的要請、公募案件、既存関係
損害賠償予定額を合理的範囲で設定 — 過大な金額は無効とされるリスク
違反時の通知・是正手続きを規定 — いきなり訴訟ではなく、通知→協議の段階を用意

6.3 避けるべき文言

「一切の勧誘を禁止」等の無限定表現
「契約終了後も無期限」等の過度な期間
「1億円の違約金」等の合理性を欠く損害賠償
「いかなる理由でも例外を認めない」等の排他的表現

7. 別契約別請求の実装

7.1 契約構造

顧客は士業・ベンダーとそれぞれ別個に契約を結び、それぞれ直接支払を行う。紹介料・あっ旋料は一切発生させない。

7.2 共同提案時の文書設計

共同提案書は両社名義で作成するが、契約は個別に締結する旨を文書冒頭に明記する。

7.3 請求分離の運用

請求は各社から直接顧客に発行する。両社の請求書を合算して一方から送付する運用は、実質的な紹介料収受と誤解されるリスクがあるため避ける。

8. 顧客書面同意のフォーム設計

8.1 書面同意書の必須項目

提携関係の概要（両社名・業務領域）
共有する情報の具体的範囲（社名・決算情報・事業計画等）
利用目的（補助金採択後支援・IT導入提案等）
同意期間と撤回方法
第三者提供先の明示
同意日と顧客代表者署名

8.2 同意書フォームの雛形骨子

8.3 運用上の注意

同意撤回の意思表示があった場合、速やかに情報共有停止と関連データの廃棄
同意範囲を超える情報共有が必要になった場合は追加同意取得
同意書は電子化を推奨（電子署名サービス利用）

9. よくある質問（FAQ）

Q1. no-poach条項は必ず契約に入れるべきですか？

士業側の信頼を獲得する上で極めて重要である。とくに税理士法人との提携では、no-poach条項の有無が提携開始の決定要因になるケースが多い。文言は過度に広範にせず、適切な範囲と期間で設計するのが実務上の鍵である。

Q2. 紹介料を一切受領しない場合、ベンダー側のインセンティブは何ですか？

共同サービス経由で獲得した顧客に対する直接のIT導入契約収入がインセンティブである。間接的な紹介料収受ではなく、直接の顧客契約による売上が本来の収益構造であり、この構造がむしろ事業の持続性を高める。

Q3. 税理士法人と複数のベンダーが提携することは可能ですか？

可能である。ただし、no-poach条項の整合性に注意する。複数ベンダー間で顧客が競合する場合、税理士側の調整負担が増える。複数提携する場合は、各ベンダーの専門領域を補完的に設計するのが望ましい。

Q4. 顧客同意なしでも提携先に情報共有できるケースはありますか？

ない。士業特有の守秘義務と個人情報保護法の両面から、書面同意取得は必須と考えるのが安全である。緊急時の最小限の情報共有（例：事務局からの緊急照会対応）も、事前包括同意の範囲内に収めるよう設計する。

Q5. 契約書作成時に弁護士レビューは必須ですか？

必須と考えるのが実務的である。とくに税理士法・独占禁止法・個人情報保護法の3領域にまたがる複雑な論点があり、テンプレートのみで運用すると、想定外のリスクを残す可能性がある。契約書テンプレートは論点整理のたたき台とし、最終確定版は弁護士レビューを経るのが標準プロセスである。

10. まとめ — 契約設計は信頼関係の可視化

士業とITベンダーの提携契約は、単なる法務文書ではなく、両者の信頼関係を形にした実装である。no-poach条項、別契約別請求、顧客書面同意の3点セットは、法務リスク回避と同時に、お互いの事業領域を尊重する意思表示として機能する。

2026年度のデジタル化・AI導入補助金をはじめ、補助金制度は年々複雑化しており、士業単独・ベンダー単独で顧客満足を実現するのは難しい。適切な契約設計のもとでの協業は、顧客・士業・ベンダーの三方にメリットがある構造を作り出せる。

契約書作成は弁護士レビューを経る前提で、本記事の論点整理を社内協議のたたき台として活用いただきたい。

関連サービス

GXOでは税理士法人をはじめとする士業との提携に際し、no-poach契約雛形の提供、共同サービス設計支援、顧客書面同意フォームの整備まで一貫でご相談いただけます。弁護士ネットワークとの連携もご紹介可能です。

→ 士業提携に関するご相談

GXO実務追記: システム開発・DX投資で発注前に確認すべきこと

この記事のテーマは、単なるトレンド紹介ではなく、要件定義、費用、開発体制、ベンダー選定、保守運用を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。

まず決めるべき3つの論点

論点	確認する内容	未整理のまま進めた場合のリスク
目的	売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか	成果指標が曖昧になり、PoCや開発が終わっても投資判断できない
範囲	対象部署、対象業務、対象データ、対象システムをどこまで含めるか	見積もりが膨らむ、または重要な連携が後から漏れる
体制	自社責任者、現場担当、ベンダー、保守運用者をどう置くか	要件確認が遅れ、納期遅延や品質低下につながる

費用・期間・体制の目安

フェーズ	期間目安	主な成果物	GXOが見るポイント
事前診断	1〜2週間	課題整理、現行確認、投資判断メモ	目的と範囲が商談前に整理されているか
要件定義 / 設計	3〜6週間	要件一覧、RFP、概算見積、ロードマップ	見積比較できる粒度になっているか
PoC / MVP	1〜3ヶ月	検証環境、効果測定、リスク評価	本番化判断に必要な数値が取れるか
本番導入	3〜6ヶ月	本番環境、運用設計、教育、改善計画	導入後の運用責任と改善サイクルがあるか

発注前チェックリスト

[ ] 発注前に目的、対象業務、利用者、現行課題を1枚に整理したか
[ ] 必須要件、将来要件、今回はやらない要件を分けたか
[ ] 見積比較で、開発費だけでなく保守費、運用費、追加改修費を見たか
[ ] ベンダー選定で、体制、実績、品質管理、セキュリティ、引継ぎ条件を確認したか
[ ] 検収条件を機能、性能、セキュリティ、ドキュメントで定義したか
[ ] リリース後3ヶ月の改善運用と責任分界を決めたか

参考にすべき一次情報・公的情報

上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。

GXOに相談するタイミング

次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。

見積もり依頼前に、要件やRFPの粒度を整えたい
既存ベンダーの提案が妥当か第三者視点で確認したい
補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
PoCや診断で終わらせず、本番導入と運用改善まで進めたい

no-poach条項付き提携契約テンプレ実務ガイド｜税理士法52条・独禁法・共同サービス設計の論点整理2026を自社条件で診断したい方へ

GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。

システム開発費用・要件診断を相談する

※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。