証券代行システムの発注は、まず対象業務の範囲を決め、同じ条件のRFPで各社から提案を集めます。そのうえで契約形態と委託先を比べると、業務範囲に合った開発につながりやすくなります。
▼全体ガイドの記事
・証券代行システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
証券代行システムの全体像
証券代行システムといっても、業務の範囲は立場によって大きく変わります。発行会社が株主名簿や配当事務を委託する場合と、証券代行機関が基幹を刷新する場合とでは、機能も責任分界も費用も異なるため、発注前に範囲を分けて考えます。
証券代行システムが管理する業務
証券代行システムは、株式会社に代わって株主名簿を管理し、株式の異動や配当、株主総会の事務を処理する仕組みです。
株主に関する情報は、口座管理機関、証券保管振替機構、株主名簿管理人、発行会社の間でやりとりされます。
なかでも、株主確定日に届く「総株主通知」を名簿の更新に使う点が、通常の顧客台帳とは異なる特徴です（出典：信託協会「証券代行業務」）。
- 株主情報：株式数、取得日、異動履歴、名義書換の管理。
- 株式と配当：単元未満株式、分割・併合、配当計算、支払通知の処理。
- 総会と帳票：議決権の集計、招集通知、帳票の作成。
- 発行会社向けポータル：照会、帳票の取得、事務指示、承認を含む機能。
発注前に決めるべき対象範囲
まず、発行会社向けポータルだけにするか、名簿・配当・総会を処理する業務コアまで含めるかを決めます。あわせて、上場・非上場の区分、株主向け画面、ほふり等との連携も整理します。
既存システムを残してAPIだけを刷新するかどうかも、この段階で決めておきます。対象範囲は、名簿から運用監視までの業務ごとに、対象・対象外・将来対応の3列で書き分けます。
範囲が曖昧なままだと、ポータルだけの提案と基幹・移行を含む提案を同じ基準で比べられません。そこで、要件表で範囲をそろえておくと、後工程の追加費用を抑えやすくなります。
証券代行システムの発注形態の選び方
発注形態は、既存資産をどこまで活かすか、独自の業務がどれだけ多いか、運用の責任を自社でどこまで持つかで選びます。
標準機能に合わせられるなら、パッケージやマネージドサービスが候補になります。
既存データや業務ルールに強い独自性がある場合は、アドオンか段階的な個別開発が現実的です。
標準機能に合わせるのか、既存業務を活かすのかで、発注形態の向き不向きが分かれます。各方式の違いは、次に並べて比べます。
- パッケージ・クラウド：標準機能を中心に使い、設定と追加開発を絞り込めます。
- 既存資産へのアドオン：業務コアを残したまま、ポータルやAPIを追加できます。
- スクラッチ開発：独自の業務フローやデータモデルに合わせて作れます。
パッケージ・クラウドを導入する場合
パッケージやクラウドは、標準機能の範囲で業務が足りるかどうかが、選ぶ際の分かれ目になります。制度改正への対応はサービス側に任せられる一方、標準外の業務やクラウドの管理条件は、適合の判断を左右します。
- 標準機能：株主管理、配当、帳票、権限管理の機能をそのまま使い、初期開発を短くできます。
- 更新対応：制度改正やセキュリティ更新を、サービス側に任せられる場合があります。
- 標準外の業務：総株主通知の取込み、訂正、旧システム連携で、追加費用や制約が生じます。
クラウドでは、暗号化やアクセス制御、ログの保存期間を確認します。加えて、バックアップと復旧目標、再委託先、データの返却方法も見ておきます。
FISCは2026年3月に第14版の安全対策基準・解説書を公表し、金融システムの開発・導入・運用の対策を整理しました（出典：金融情報システムセンター「第14版公表」）。
RFPには「FISC準拠」と書くだけでなく、該当する管理策と提出可能な証跡も指定します。
既存システムを残してアドオンする場合
既存システムを残す場合は、追加する機能と費用、運用時の確認点を分けて考えます。
- 追加機能：既存の株主名簿や配当計算、帳票基盤を活かし、発行会社向けポータルやAPI、承認ワークフローを加えます。
- 停止リスク：業務コアを一度に置き換えないため、決算期や株主総会期の停止リスクを抑えられます。
- 費用目安：既存基盤を活かすポータル案件は、500万円〜2,000万円程度で始められる場合があります。
- API仕様：API仕様に加えて、どのシステムの残高を正とするかも決めます。
古いデータ形式や手作業による補正を残したままだと、障害が起きたときに原因を追いにくくなります。そのため、株主数や配当額、議決権数が基幹と食い違ったときに、表示、連携、元データのどこに問題があるかを追えるよう、ログを残しておきます。
ログには取引IDと処理日時を入れ、再送回数と承認者も残します。
スクラッチ開発を選ぶ場合
スクラッチ開発では、業務フローとデータモデルを自社の運用に合わせて作ります。締め処理や帳票、外部接続などに加え、ポータルも対象になります。大規模な証券代行機関や、複数の発行会社を扱う事業者で、既製品に合わせると業務上の損失になる場合に適しています。
自由度が高い一方で、制度改正やテストデータ、運用要員まで自社で管理することになります。障害復旧や、開発会社が撤退するリスクも自社で受け持ちます。
発注時は、全機能を一度に完成させようとせず、段階を分けて進めます。
- 業務フローとデータ移行を検証します。
- 総株主通知、配当基準日、議決権数の3シナリオを、サンプルデータで通します。
- 限定した範囲のプロトタイプを作り、段階的にリリースします。
検証の段階で、訂正や再処理、照合ができることを確かめてから、本開発へ進みます。
RFPと要件整理の進め方
RFPは、業務課題、対象範囲、データ、品質、納期、契約条件を同じ前提で各社に示し、提案を比べるための文書です。
証券代行では、基準日処理や例外処理、照合を明記します。加えて、監査証跡や移行、制度改正への対応も書き込みます。
RFPに記載する項目
RFPは、業務範囲や品質、運用条件を同じ前提で比べられるよう、項目ごとに分けて書きます。
- 基本情報：背景・目的、対象会社・株主、現行構成、利用者・権限の記載。
- 機能と優先度：機能を必須、できれば欲しい、将来の3段階に分けます。
- 連携と帳票：形式、件数、到着時刻、再送、訂正、タイムアウト、試験の条件。
- 移行と非機能：移行、処理量、停止時間、RTO・RPO、同時利用者、ログ期間の条件を示します。
- 運用と発注条件：脆弱性診断やバックアップ復元試験、希望スケジュール、保守、見積もりの提出形式を含めます。
帳票については、名称や出力時期、対象データに加え、印刷・PDF・電子交付の別と改訂履歴を示します。
外部連携の条件も、接続試験の段階まで具体化しておきます。
業務要件の現場での固め方
要件は情報システム部門だけで決めず、業務と管理に関わる担当者を集めて固めます。
- 参加者：証券代行事務や配当、総会の担当に加え、法務、セキュリティ、経理、監査の担当者も集めます。
- 登録業務：受付から本人確認、承認、名簿更新、通知、訂正、監査ログまでの範囲を決めます。
- 例外処理：所在不明株主や未払配当、データ不備、再送、決算直前の訂正を洗い出します。
現行の帳票とサンプルデータを使って、担当者、確認の時点と内容、証跡を決めておくと、開発会社も金融業務の前提をつかみやすくなります。
RFP段階での移行とテストの位置づけ
証券代行では、新しい機能よりもデータ移行が難所になることがあります。そのため、移行の対象と確認項目を先に定めておきます。
- 移行データ：名簿、株式数、取得日、異動履歴を含む株主データと、未払配当、過去帳票、会社別コードを対象にします。
- データ品質：欠損や重複、文字コード、日付形式、名寄せ、保存期間の確認。
- 移行計画：移行元と移行先、変換ルール、照合方法、責任者を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・監査文書、教育、保守の扱いも確認します。
- 見積条件：同じWBS形式で、工数と単価、前提、除外事項、成果物を求めます。
一般的な受託開発では、人月単価が60万円〜200万円程度とされることがあります（出典：SIA株式会社「システム開発の費用・相場 2026年版」）。単価と人数は、金融知識やPM、セキュリティ・移行・試験の経験によって変わります。
見積書の人員に、必要な役割と証券代行の業務責任者が含まれているかも確認します。
5年TCOによる比較
初期費用だけでなく、5年間の総保有コスト（TCO）で比べます。その際は、継続費用と一時費用に分けて見積もります。
- 継続・一時費用：保守、クラウド、監視、バックアップ、診断、制度改正、帳票、保管、教育、訓練、災害対策、更新の各費用を集計します。
- 保守の仮置き：初期開発費の年15％〜25％を仮に置く方法もありますが、保守の範囲は指定します。
- クラウド：初期のサーバー購入費を抑えやすい一方で、月額利用料やデータ転送、監視、冗長化、長期保管が続きます。
- オンプレミス：設備の更新や災害対策、運用要員を、自社で持つことになります。
判断にあたっては、繁忙期の性能や停止時の損失、撤退時のデータ移行も含めて考えます。
委託先の選定と見積比較の観点
委託先は、金融系SIerという知名度だけで決めず、証券代行業務への理解や移行・運用の対応力、提案の前提で比べます。
候補を2〜3社に絞り、同じRFPとサンプルデータで説明を求めると、価格と提案の質の違いが見えてきます。
証券代行のドメイン実績
実績は、金融システムの経験だけでなく、証券代行業務でどこまで担当したかまで確認します。
- 担当業務：名簿、名義書換、配当の担当範囲を確認します。議決権、総会、総株主通知、電子提供についても、どこまで担当したかを尋ねます。
- 導入・保守経験：稼働年数や処理量、担当範囲、保守体制、障害対応、制度改正への対応を尋ねます。
- 実績の具体例：HIMACSは、書換システムと、名簿確定・剰余金配当の決算システムの事例を公開しています。
HIMACSの事例の詳細は、同社の公開ページで確認できます（出典：HIMACS「信託銀行向け証券代行システム」）。証券や信託、金融基幹の実績も参考になりますが、金融SIの経験とは分けて考えます。あわせて、提案責任者の業務理解と、有識者の配置も確認します。
同じ条件での見積もり比較
各社の見積もりは、費用の範囲と前提をそろえて横並びにしてから比べます。総額が最も安い会社よりも、抜け漏れが少なく前提の説明が具体的な会社を評価します。
- 費用範囲：要件定義、設計、開発、連携、移行、テスト、教育、保守、インフラを並べます。
- 見積条件：「含む」「含まない」「別途」の区分に加え、人数、期間、成果物、前提データを記録します。
- 発注・検収条件：発注側の作業や変更単価、検収条件、障害対応時間を比べます。
- デモ：通知取込み、配当再計算、未払訂正、議決権照合、帳票再出力、権限拒否を試します。
デモは、正常な株主登録だけで判断せず、例外の場面も動かして見ます。訂正・再処理や監査ログが不足すると、画面が整っていても実運用で担当者の負担が増えます。
発注時に避けたいリスクと対策
典型的な失敗は、業務範囲を決めないまま開発を始めること、移行を最後に回すこと、繁忙期の切替を想定しないことです。
セキュリティを確認表だけで済ませることや、再委託先が見えないままになることも、失敗につながります。
発注前には、範囲と切替、移行、情報管理、アクセスと記録の4点から対策を決めます。
- 範囲と切替：業務とデータの洗い出しと、繁忙期を避けた切替の計画。
- 移行：本番相当の件数でリハーサルし、旧新照合とロールバックを受入条件にします。
- 情報管理：本番データの開発環境への持ち込み禁止と、テストデータの匿名化。
- アクセスと記録：特権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を配ります。
- 見積金額に加えて、前提や除外、成果物、期間、受入条件、保守、制度改正への対応を比べます。
▼全体ガイドの記事
・証券代行システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。