証券代行システム開発の発注/外注/依頼/委託方法について

証券代行システムの発注・外注は、株主名簿、配当、株主総会、総株主通知までの業務範囲を先に定義し、複数社が同じ条件で見積もれるRFPを作ることが成功の近道です。

証券代行システムは、一般的な顧客管理システムよりも法令・制度・締め処理・監査証跡への要求が厳しくなります。この記事では、パッケージやクラウド、スクラッチの選び方、RFPと要件整理、準委任・請負の使い分け、2026年時点の費用目安、委託先と見積書の比較方法まで、発注前に確認したいポイントを順番に解説します。

▼全体ガイドの記事
・証券代行システム開発の完全ガイド

証券代行システムの全体像

発注を始める前に、証券代行システムという言葉が指す範囲を分けておく必要があります。発行会社が株主名簿や配当事務を委託する場合と、信託銀行などの証券代行機関が業務を処理する基幹システムを刷新する場合では、必要な機能、責任分界、費用が大きく変わります。

証券代行システムは、株式会社に代わって株主名簿の管理、株式の異動、配当、株主総会に関する事務を処理する業務システムです。上場会社の株式は株式等振替制度のもとで電子化されており、口座管理機関、証券保管振替機構、株主名簿管理人、発行会社の間で情報が伝達されます。株主確定日に証券保管振替機構から通知される「総株主通知」を名簿更新に使う点が、通常の顧客台帳との大きな違いです（出典：信託協会「証券代行業務」）。

主な機能は、株主・株式数・取得日・異動履歴の管理、名義書換、単元未満株式や株式分割・併合への対応、配当金の計算と支払通知、議決権数の集計、招集通知、帳票作成です。発行会社向けポータルを含める場合は、情報照会、帳票のダウンロード、事務指示、承認ワークフローまで要件になります。

最初に、「発行会社向けの照会・事務指示ポータルだけを作るのか」「名簿・配当・総会を処理する業務コアまで作るのか」を決めます。さらに、上場会社向けか非上場会社向けか、株主向け画面を持つか、ほふり等の外部データ連携を含むか、既存システムを残してAPIだけ刷新するかを整理します。

この切り分けを曖昧にしたまま見積もりを依頼すると、A社はポータルだけ、B社は基幹と移行まで含めるという比較不能な提案になります。要件表には「対象」「対象外」「将来対応」の3列を用意し、株主名簿、権利イベント、配当、総会、帳票、外部連携、移行、運用監視を一つずつ記載すると、後工程の追加費用を抑えやすくなります。

証券代行システムの発注形態はどれを選ぶべきですか？

発注形態は、既存資産の活用度、独自業務の多さ、運用責任をどこまで自社で持つかによって選びます。標準機能に合わせられるならパッケージやマネージドサービスが候補になり、既存データや業務ルールに強い独自性があるなら、アドオンまたは段階的な個別開発が現実的です。

パッケージやクラウドは、株主管理、配当、帳票、権限管理などの標準機能を利用し、設定と必要最小限の追加開発で導入する形態です。初期開発を短くしやすく、制度改正やセキュリティ更新をサービス側に任せられる可能性があります。一方で、総株主通知の取り込み、例外的な訂正処理、旧システムとのデータ連携が標準外になると、アドオン費用や運用上の制約が発生します。

クラウドを選ぶ場合は、保存場所だけでなく、暗号化、アクセス制御、ログ保存期間、バックアップ、復旧目標、再委託先、データ返却の方法まで確認します。FISCは2026年3月に第14版の安全対策基準・解説書を公表しており、金融システムの開発・導入・運用に必要な安全対策を整理しています（出典：金融情報システムセンター「第14版公表」）。RFPに「FISC準拠」とだけ書かず、該当する管理策と提出可能な証跡を指定することが重要です。

既存の株主名簿、配当計算、帳票基盤などを活かし、発行会社向けポータル、API、承認ワークフローだけを追加する方法です。業務コアを一度に置き換えないため、決算期や株主総会期の停止リスクを抑えやすく、500万円〜2,000万円程度のポータル案件として始められる場合があります。ただし、古いデータ形式や手作業の補正を温存すると、障害時に原因を追いにくくなります。

アドオン型では、APIの仕様だけでなく、どのシステムが正しい残高を持つかを決めます。画面に表示した株主数、配当額、議決権数が基幹の値と一致しない場合に、表示側の問題なのか、連携処理の問題なのか、元データの問題なのかを追跡できるよう、取引ID、処理日時、再送回数、承認者をログに残す設計が必要です。

スクラッチ開発は、業務フロー、データモデル、締め処理、帳票、外部接続、ポータルを自社の運用に合わせて設計する形態です。大規模な証券代行機関や複数の発行会社を扱う事業者で、既製品に合わせることが業務上の損失になる場合に向いています。一方、自由度が高い分、制度改正への追随、テストデータ、運用要員、障害復旧、開発会社の撤退リスクまで自社が管理する必要があります。

発注時は、いきなり全機能を完成させるのではなく、まず業務フローとデータ移行の検証、次に限定範囲のプロトタイプ、その後に段階リリースという順序が安全です。特に総株主通知、配当基準日、議決権数の3シナリオをサンプルデータで通し、訂正・再処理・照合ができることを確認してから本開発へ進めます。

RFPと要件整理はどのように進めますか？

RFPは「高性能なシステムを作ってください」という依頼書ではなく、解決したい業務課題、対象範囲、データ、品質、納期、契約条件を同じ前提で比較するための文書です。証券代行では、画面の見た目よりも、基準日処理、例外処理、照合、監査証跡、移行、制度改正対応を細かく書くことで見積もりの差が説明しやすくなります。

RFPには、背景と目的、対象会社・対象株主、現行システム構成、利用者と権限、機能一覧、外部連携、帳票、データ移行、非機能要件、希望スケジュール、運用・保守、見積書の提出形式を記載します。機能一覧は「必須」「できれば欲しい」「将来」の3段階に分け、発注後に優先度が変わらないようにします。

外部連携では、総株主通知などの受信形式、件数、到着時刻、再送、エラー訂正、タイムアウト、相手側の接続試験を明記します。帳票では、帳票名、出力タイミング、対象データ、印刷・PDF・電子交付の別、改訂履歴を示します。非機能要件では、月間・日次の処理量、許容停止時間、RTO・RPO、同時利用者数、ログ保存期間、脆弱性診断、バックアップ復元試験まで具体化します。

要件定義では、情報システム部門だけで決めず、証券代行事務、配当、総会、法務、セキュリティ、経理、監査の担当者を集めます。たとえば「株主情報を登録する」という一文でも、名義書換の受付、本人確認、承認、名簿更新、通知、訂正、監査ログまで含めるかによって工数が変わります。

業務ワークショップでは、正常系だけでなく、所在不明株主、未払配当、データ不備、同一処理の再送、決算日直前の訂正などの例外を洗い出します。現行帳票とサンプルデータを持ち込み、「誰が」「いつ」「何を確認し」「どの証跡を残すか」を決めると、開発会社の担当者も金融業務の前提を理解しやすくなります。

証券代行システムでは、新機能の開発よりデータ移行の方がプロジェクトを難しくすることがあります。株主名簿、株式数、取得日、異動履歴、未払配当、過去の帳票、発行会社ごとのコードを対象に、欠損、重複、文字コード、日付形式、名寄せ、保存期間を確認します。RFPでは移行対象を一覧にし、移行元・変換ルール・移行先・照合方法・責任者を明記します。

テストは、単体・結合・総合だけでなく、業務シナリオ、性能、脆弱性、障害復旧、バックアップ復元、制度改正、旧新並行照合まで含めます。受入基準には「処理が成功した」だけでなく、件数・金額・株式数が元データと一致すること、再実行で二重計上しないこと、エラー時に担当者が原因と再処理方法を確認できることを設定します。

証券代行システムの契約形態はどう使い分けますか？

契約形態は、要件が固まっている工程と、専門家と一緒に探索する工程を分けて考えます。証券代行のように業務ルールや例外処理が多い案件では、要件定義を準委任、仕様と受入基準が確定した開発を請負にするなど、工程ごとに組み合わせる方法が現実的です。

準委任契約は、業務調査、要件整理、現行分析、技術検証、プロトタイプ、PMO支援など、作業を進めること自体が目的になる工程と相性があります。業務担当者と開発会社が対話しながら、標準機能で対応できる範囲や、移行の難所を見つける段階では、成果物を固定しすぎない方が合理的です。

ただし、準委任だから責任が曖昧でよいわけではありません。稼働する担当者、月次の報告内容、会議体、課題管理、成果物の定義、情報管理、再委託、作業時間の上限を契約書と個別仕様書に記載します。要件定義書、業務フロー、データ項目一覧、RFP改訂版など、次工程に引き渡す成果物を明確にしておくことが重要です。

請負契約は、完成させるシステム、納品物、検査方法、受入基準、納期が合意できた設計・開発・移行作業に向きます。画面仕様書、API仕様書、プログラム、テスト結果、移行結果、操作マニュアルなど、何をもって完成とするかを明記し、検収の期限と不具合修正の扱いも決めます。

一方で、発注側が要件を決めていないのに、全工程を固定価格の請負にすると、想定外の例外処理が追加変更として積み上がるおそれがあります。契約前に「仕様変更」「法令・制度改正」「外部接続先の仕様変更」「発注側のデータ不備」が起きた場合の協議方法、見積もりの再算定、納期への影響を定めておきます。

最低限、納品物と知的財産権、第三者ソフトウェアのライセンス、秘密情報と個人情報、再委託先、障害時の連絡と復旧、損害賠償の範囲、保守・制度改正対応、データ返却、契約終了後の支援を確認します。個人情報を扱う場合は、アクセス権限、持ち出し禁止、委託先監査、事故報告、ログ提供の条件も必要です。

業務上の最終判断を発注側が行うのか、開発会社が設計責任を負うのか、クラウド事業者や再委託先がどこまで担うのかをRACIのような役割表で示します。契約条件は案件ごとに異なるため、締結前に法務・情報セキュリティ・業務責任者でレビューし、見積書だけでなく提案書と議事録も契約上の前提として保存します。

証券代行システムの費用相場とコスト内訳

証券代行システム単体の契約金額を示す公開統計はほとんどないため、以下は業務範囲と金融系基幹システムの難易度から整理した発注前の推定レンジです。実際の見積もりは、対象株主数、発行会社数、外部連携、既存資産、可用性、監査要件、移行データの品質で変わります。金額を確定値ではなく、RFPで精査するための予算帯として利用してください。

発行会社向けの照会・事務指示ポータルを既存基盤とAPI連携する場合は、500万円〜2,000万円程度が一つの検討帯です。株主管理、配当、株主総会の標準機能を持つパッケージやクラウドを設定・移行・教育込みで導入する場合は、1,500万円〜5,000万円程度が目安になります。

個別アドオン、複数の外部連携、発行会社ポータル、監査対応まで含めると5,000万円〜1億5,000万円程度、名簿・権利・配当・総会・帳票・外部接続・移行・災害対策を一体で刷新する大規模基幹なら1億5,000万円〜5億円超になる可能性があります。一般的な2026年の業務システムでは、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上という目安が紹介されていますが、証券代行は金融業務固有の連携・監査・移行が加わるため、そのまま適用できません（出典：SIA株式会社「システム開発の費用・相場 2026年版」）。

見積書は、要件定義・業務設計、アプリ設計・開発、外部連携、インフラ、テスト、移行、リハーサル、PM・監査文書、教育、保守に分けて確認します。開発費だけを比べると、A社は移行とセキュリティ診断を含み、B社は別途という差を見落とします。各社に同じWBS形式で、作業内容、工数、人月単価、前提、除外事項、成果物を出してもらうと比較しやすくなります。

一般的な受託開発では人月単価が60万円〜200万円程度とされることがありますが、金融業務の知識、PM、セキュリティ、移行、試験の経験によって単価と必要人数が変わります（出典：SIA株式会社「システム開発の費用・相場 2026年版」）。単価の安さではなく、必要な役割が見積もりに含まれているか、証券代行の業務責任者を誰が担うかを確認してください。

初期費用だけでなく、5年間の総保有コストで比較します。保守費、クラウド利用料、監視、バックアップ、セキュリティ診断、制度改正対応、追加帳票、データ保管、教育、障害訓練、災害対策、契約更新を合計し、毎年発生する費用と一時費用を分けます。初期開発費の年15％〜25％を保守の仮置きにする方法もありますが、これは契約内容で大きく変わるため、見積依頼時に保守範囲を指定してください。

クラウドは初期のサーバー購入費を抑えやすい反面、月額利用料、データ転送、監視、冗長化、長期保管が継続します。反対にオンプレミスは設備更新、災害対策、運用要員を自社で持つ必要があります。月額を単純に安くするのではなく、株主総会や配当の繁忙期に必要な性能、停止時の損失、撤退時のデータ移行まで含めて判断します。

委託先の選定と見積比較で見るべきポイント

委託先は、金融系SIerという知名度だけで決めず、証券代行業務をどこまで理解しているか、データ移行と運用を任せられるか、提案の前提が明確かで比較します。候補を2〜3社に絞り、同じRFPと同じサンプルデータで説明を求めると、価格と提案品質の違いが見えます。

実績確認では「金融システムを作ったことがあるか」だけでなく、株主名簿、名義書換、配当、議決権、総会、総株主通知、電子提供のどこを担当したかを質問します。たとえばHIMACSは、信託銀行向け証券代行システムについて、株式の名義書換などを扱う書換システム、株主名簿の確定や剰余金配当などを扱う決算システムの開発実績を公開しています（出典：HIMACS「信託銀行向け証券代行システム」）。

候補会社には、実績の対象業務、稼働年数、処理量、担当範囲、現在の保守体制、障害対応の実例、制度改正時の対応方法を確認します。隣接する証券・信託・金融基幹の実績も参考になりますが、証券代行の完成品を持つことと、金融SIの経験があることは同じではありません。提案責任者が業務用語を理解し、業務有識者をプロジェクトに配置できるかを見極めます。

見積比較表には、要件定義、設計、開発、外部連携、移行、テスト、教育、保守、インフラの費用を横並びにし、含む・含まない・別途の3区分を加えます。さらに、担当人数、期間、主要成果物、前提データ、発注側の作業、追加変更の単価、検収条件、障害対応時間を記入します。総額が最も安い会社ではなく、抜け漏れが少なく、前提の説明が具体的な会社を評価することが大切です。

提案のデモでは、正常な株主登録だけでなく、総株主通知の取り込み、配当計算の再実行、未払配当の訂正、議決権数の照合、帳票の再出力、権限のない利用者の拒否を見せてもらいます。画面がきれいでも、エラーを訂正して再処理する機能や監査ログが不足していれば、実運用で担当者の負担が増えます。

典型的な失敗は、業務範囲を決めずに開発を始めること、移行を最後に回すこと、繁忙期の切替を想定しないこと、セキュリティをチェックリストだけで済ませること、再委託先が見えないことです。対策として、発注前に現行業務とデータを棚卸しし、移行リハーサルを本番相当の件数で実施し、旧新の並行照合とロールバック手順を受入条件に入れます。

また、株主データを扱うため、開発環境に本番データをそのまま持ち込まない、テストデータを匿名化する、特権IDを分離する、操作ログと承認記録を保管する、委託先の退職者・異動者の権限を速やかに無効化するなど、運用ルールまで決めます。AIを検索やテストデータ生成に活用する場合でも、株主残高、配当額、議決権数の確定ロジックは人が検証し、生成結果を本番判断へ直接利用しない設計にします。

よくある質問

ここでは、証券代行システムを発注・外注するときに寄せられやすい質問へ回答します。費用や期間は業務範囲で変動するため、質問への回答とあわせて、RFPに何を記載すれば精度が上がるかも確認してください。

発行会社向けポータルなら500万円〜2,000万円程度、標準機能中心のパッケージ・クラウド導入なら1,500万円〜5,000万円程度が検討帯です。複数連携やアドオンを含むと5,000万円〜1億5,000万円程度、大規模な基幹刷新なら1億5,000万円〜5億円超になる可能性があります。証券代行固有の公開相場ではなく、対象範囲から整理した推定ですので、同じRFPで複数社に見積もりを依頼してください。

標準的な株主管理、配当、帳票を短期間で導入したい場合はパッケージやクラウドが候補です。独自の権利処理、複数の発行会社、既存基盤との複雑な連携、長期の運用要件がある場合は、アドオンやスクラッチの方が適することがあります。まず業務フローを比較し、標準機能・設定・追加開発・個別構築に分けたFit & Gapを実施してください。

証券代行の実績について、名簿、名義書換、配当、議決権、総会、総株主通知、移行のどこまで経験があるかを確認することです。加えて、業務有識者の配置、データ移行の責任者、障害時の復旧体制、再委託先、制度改正への対応、監査資料の提出範囲を質問します。金融実績の社数や会社規模だけでなく、実際に担当するチームの経験を確認してください。

要件調査、現行分析、技術検証、PMOなど成果の形を固定しにくい工程は準委任、仕様・納品物・受入基準が確定した設計・開発・移行は請負が基本的な考え方です。実際には、要件定義を準委任で行い、確定した仕様をもとに開発を請負で契約するなど、工程ごとに分ける方法があります。責任分界と変更ルールは、契約締結前に法務と業務責任者で確認してください。

まとめ

証券代行システムの発注では、まず発行会社向けポータルなのか、株主名簿・配当・株主総会・外部連携まで含む業務基幹なのかを切り分けます。そのうえで、パッケージ・クラウド、既存資産へのアドオン、スクラッチ開発を、業務の独自性、データ移行、運用責任、5年TCOで比較します。

RFPには、総株主通知、名簿更新、配当計算、議決権数、帳票、例外処理、再処理、外部連携、移行、テスト、監査証跡、復旧要件を記載します。準委任と請負を工程ごとに使い分け、変更・制度改正・障害・再委託の責任分界を契約に落とし込みます。委託先は金融実績の看板ではなく、証券代行の担当範囲と実際のチーム体制で評価します。

最初の一歩は、業務担当者と現行システムの一覧を作り、名簿・配当・総会・ポータル・外部連携・移行・運用の対象範囲を決めることです。次に、3つの代表シナリオとサンプルデータを用意し、2〜3社へ同一条件でRFPを配布します。見積金額だけでなく、前提、除外、成果物、期間、受入条件、保守、制度改正対応を比較すれば、証券代行実務に合う委託先を選びやすくなります。

▼全体ガイドの記事
・証券代行システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。