株主管理システム開発は6フェーズで進みます。前半は要件整理と製品・開発会社の選定、設計開発で、後半はテスト、稼働、定着です。要件整理で現状の資料と正解データをそろえ、設計開発まで順に進めることで、株主情報と取引履歴を正確に管理できる仕組みになります。
▼全体ガイドの記事
・株主管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
株主管理システム開発の全体像
株主管理システムは、株主名簿、株式取引、資本政策、議決権、株主総会、配当などの情報と手続きをまとめる業務システムです。法定帳票と承認済みの取引履歴が一貫してつながるかどうかが、開発の成否を左右します。
管理対象の情報と取引履歴
このシステムでは、株主情報と取引履歴を管理して、基準日時点の状態を確認できるようにします。
- 株主情報：株主マスター、株式種類、保有株式数、持株比率、議決権数の記録です。
- 取引と証跡：取得日・原因、譲渡や消却の履歴、変更の証跡を保存します。
株主名簿には、氏名または名称、住所、保有株式数、取得日などを持たせます。
現在の残高しか持たないと、過去の状態を説明できなくなります。たとえば、2024年の第三者割当増資と2025年の株式譲渡を経て、2025年12月31日時点の株主を確認する場合があります。
そこで、履歴を時系列で持ち、基準日を指定して再現できるようにすると、現在の名簿と過去の決議資料を照合できます。一方で、Excelのセルを上書きすると、誰がいつ何を変えたかをたどりにくくなります。
会社の成長段階ごとに必要な範囲
管理機能は、会社の成長段階に合わせて段階的に追加していきます。
- 創業直後：名簿、株式取引、証明書、株主リスト、CSV入出力が最初の範囲です。
- 業務の拡大後：資本政策、希薄化試算、譲渡承認を加えます。招集通知、委任状、出欠、議決権、配当通知も、この段階で加えます。
- 上場会社：外部の名簿管理基盤を踏まえ、IR、総会事務局、投資家対話、社内承認、分析を補う役割です。
上場会社では、証券代行会社や株主名簿管理人が大規模な名簿管理と議決権集計を担います。たとえば、三井住友信託銀行は2025年3月末時点で受託社数1,657社、管理株主数4,241万名を公表しています（出典：三井住友信託銀行「株主名簿管理業務」、2025年）。そのため、自社システムは、IRや総会事務局を補完する位置づけになりやすいです。
株主名簿と株主リストの違い
開発の初期に、会社法第121条に基づく株主名簿と、登記申請に添付する株主リストを区別しておきます。
法務省によると、株主名簿を添付しても株主リストは省略できません（出典：法務省「株主リストに関するよくあるご質問」、確認日2026年8月）。
両者は目的、記載内容、議決権数の扱いが異なります。そのため、用途別に出力仕様を分けて定めます。たとえば、株主全員の同意による決議、通常総会、登記事項を含む議案では、一覧の条件が変わる場合があります。
- 出力仕様：帳票、担当者、基準日、承認手順を要件表にまとめておきます。
- 用途の区別：名簿と株主リストを同じものとして扱わず、それぞれ別に出力することです。
社内の法務担当者だけに頼らず、司法書士、弁護士、税理士、株主名簿管理人など、実際の書類を確認する専門家にレビューを依頼します。
株主管理システム開発の進め方と6フェーズ
開発を6フェーズに分けると、段階ごとに確認すべき事項を管理しやすくなります。6フェーズは、要件整理から始まり、選定と設計開発を経て進みます。その後は、テスト、稼働、定着へと続きます。
最初から全機能を完成させず、まずは名簿と取引履歴の基盤を整えます。そのうえで、総会、配当、会計、電子契約、IR連携へ広げていく進め方が現実的です。
フェーズ1：要件整理と現状・正解データの確認
最初に集めるのは、株主名簿、株式取引台帳、定款、資本政策表です。あわせて、新株予約権原簿、株主間契約、総会・配当資料、会計データも集めます。
発注側は、現行データの項目、更新者、更新頻度、参照する基準日を一覧にしておきます。原本の所在や重複、欠損も、その一覧に書き加えます。欠損を見つけておかないと、後で推測で補うことになり、誤データのもとになります。
発注側の担当者は、株式数の合計が発行済株式総数と一致するか、種類株式別の合計が定款や登記と矛盾しないかを確かめます。
- MUST要件：名簿、履歴、基準日、株式種類、議決権の定義。帳票、権限、ログ、CSVも定義します。
- WANT要件：OCR、一括メール、ダッシュボード、投資家ポータル、希薄化試算を、初期範囲と切り分けて扱います。
- 作成する資料：業務フロー、項目一覧、帳票、権限表を含みます。非機能要件、移行方針、受入基準も作成します。
法務判断とシステム要件は、分けて整理します。たとえば、「株主を議決権の対象に含めるか」は業務・法務の判断で、「基準日で対象者を抽出できるか」はシステム要件です。両者を曖昧にまとめると、仕様変更が起きやすくなります。
フェーズ2：選定でのSaaS・個別開発・BPOの比較
選定では、標準クラウドSaaS、API・帳票カスタマイズ、FileMakerなどのローコード開発を比べます。スクラッチ開発や、証券代行・総会運営のBPO併用も候補に入ります。
法定帳票と履歴が中心の小規模な非上場会社では、標準SaaSが候補になります。一方で、独自の種類株式や複雑な承認、基幹連携が重要な場合は、カスタマイズや個別開発を検討します。
発注側は、候補先に株主数の上限、種類株式とSOの管理、取引の訂正方法を質問します。あわせて、株主名簿と株主リストの出力、基準日管理、データ出力、APIについても確認します。さらに、MFA、権限、操作ログ、バックアップ、障害時の復旧目標も質問し、解約時のデータ返却も確かめます。
デモでは、増資、譲渡、分割、権利行使、配当、総会決議の操作まで見せてもらいます。新規登録の操作は、履歴管理の実力を見るうえでは材料が少ないからです。
- 開発方式：標準SaaS、カスタマイズ、ローコード、スクラッチの比較。
- 委託範囲：証券代行や総会運営のBPOを併用する選択肢も含めた検討。
- デモ検証：履歴の操作と、基準日を遡った場合の結果の確認。
IPO予定会社は、証券会社、監査法人、株主名簿管理人へ渡すデータ形式を確認します。2025年4月、みずほ信託銀行とスマートラウンドは、smartroundの株主名簿や新株予約権原簿などを管理人へ連携する機能の拡充を公表しました（出典：みずほ信託銀行「スマートラウンドとの提携内容の拡充について」、2025年）。この動きは、将来の受け渡し形式を初期要件に含める判断材料になります。
フェーズ3：設計開発と履歴・権限・帳票の設計
設計では、取引イベントから残高を計算するデータモデルを基本にし、現在の残高を直接書き換えない形にします。
株式の取引では、発行、取得、譲渡を定義します。さらに、贈与、相続、消却を定義し、自己株式、株式分割、種類株式転換も含めます。新株予約権については、付与、行使、失効を定義します。
訂正するときも元データは削除せず、訂正の理由、承認者、承認日時、変更前後の値を保存します。
権限は、管理者、株式事務、経理、法務、経営層、外部専門家など、役割ごとに分けます。住所や連絡先の閲覧者と取引の承認者は、同一にする必要はありません。
MFA、IP制限、セッション管理、退職者の即時無効化、CSV制御、ログ保存期間も設計対象に入れます。ただし、クラウドを使っても、権限分離や証跡が自動で整うとは限りません。
帳票の設計は、画面の設計と並行して進めます。名簿、株主リスト、証明書、議決権集計の各帳票は、出力項目、日付、種類、押印・署名を実物で確認します。さらに、招集通知、委任状、議事録、配当通知書も実物で確かめます。
AIやOCRを使う場合は、人の承認画面を設け、原本、読取日時、承認者も記録します。
- 履歴：取引の記録方式と、訂正時の証跡。
- 権限：担当ごとの閲覧・承認範囲と、認証・ログの設計。
- 帳票：基準日を含む出力仕様の確認。
フェーズ4：テストでの数字と書類の突き合わせ
テストでは、画面に表示されるかを見るだけでなく、数字と書類が合っているかを確かめる必要があります。
- 数字の照合：残高、発行済総数、種類別合計、議決権を正解データと突き合わせる作業です。
- 業務シナリオ：基準日の設定から帳票の作成まで、担当者が一通り通して確認します。
- 統制と復旧：権限、承認、二重登録防止、バックアップ、復旧手順を試します。
最低でも、創業時、増資後、譲渡後、株式分割後、SO行使後、自己株式取得後のケースを用意します。受入テストでは、担当者が基準日を設定し、対象株主を抽出して議決権数を確認します。さらに、招集通知の出力、議決結果の登録、議事録と株主リストの作成まで操作します。
権限のない人がCSVを取得できないこと、承認前の取引が帳票に出ないこと、二重登録を防げることも確かめます。障害・復旧テストでは、バックアップ頻度、復旧目標時間、復旧後に戻る取引時点を確認します。また、災害時の連絡先やサービス停止中の代替手順も確かめます。
議決権電子行使などでは、ISO/IEC 27001を取得しているかに加えて、アクセス制御、暗号化、冗長化、復旧手順が実際に機能するかを確認します（出典：ICJ「議決権電子行使プラットフォームの安全性」、確認日2026年8月）。
フェーズ5：稼働前のデータ移行と役割の確定
IPO準備や株主照会に備えるなら、重要な増資、譲渡、SO、種類株式の発行・転換を説明できる状態にしておくことが望ましいです。
古い資料の欠損を推測で補うと、誤ったデータが入ります。そのため、原本を確認できない項目は、未確認、推定、専門家確認待ちなどの状態で管理します。
稼働日に向けて、発注側は、取引の登録者、承認者、帳票の発行者、問い合わせ窓口を決めておきます。総会や大型調達の直前に切り替えると、二重管理が起きやすくなります。
移行では、本番前に、現時点の株主名簿だけを移行するか、過去の取引履歴まで移行するかを決めます。あわせて、法人名の揺れ、住所変更、旧姓、重複、株主番号の欠落、株式種類の略称を洗い出しておきます。
- 履歴の範囲：重要な取引を説明できる状態にするため、移行する履歴の長さを決めます。
- 移行手順：抽出、名寄せ、変換、取込、照合、承認の順序。
- 本番切替：担当者の決定と、並行稼働・リハーサルの実施。
移行後に発行済株式総数と株主別の合計が合わない場合は、資料の不整合も考えられます。そのため、移行判定表に差異、原因、対応者、承認日を記録しておきます。
並行稼働は、余裕のある時期に読み取り専用で行い、1回分の総会または配当をリハーサルしてから切り替えます。
フェーズ6：定着と運用ルールの更新
稼働後は、操作研修に加えて、株式取引が発生したときの業務ルールを整えます。たとえば、契約書を受け取ったら、法務または専門家が確認し、担当者が仮登録して、責任者が承認する流れです。
残高と帳票を照合し、原本を保管するまでの流れは、手順書にまとめます。
担当者が不在でも処理できるよう、属人的な判断を、チェック項目と承認ルートに置き換えます。
点検は、月次または四半期ごとに行います。株主数や資金調達が増えたときは、総会・配当を追加し、IPO連携も見直します。
AI機能は、読み取り精度だけでなく、人が誤りを見つけて訂正できるかを運用の指標にします。
- 運用手順：取引の確認から原本保管までを、標準の手順にそろえることです。
- 定期点検：未承認、重複、帳票差異、権限、ログ、バックアップの確認。
- 機能更新：事業の成長や制度変更に合わせた、機能と設定の見直し。
法務省の法制審議会では、2026年時点で、バーチャルオンリー株主総会、実質株主確認、株主総会のデジタル化が検討されています（出典：法務省「会社法制（株式・株主総会等関係）部会」、2025〜2026年）。そのため、制度を確定事項として組み込まず、帳票や議決権のルールを後から更新できる設定方式にします。
あわせて、法改正への対応方針とリリース通知も、契約前に確かめます。
株主管理システムの費用相場とコストの内訳
費用は、標準SaaS、既存サービスの拡張、専用システムの開発のどれを選ぶかで変わります。月額だけでなく、移行、法務確認、帳票、連携、研修、保守まで含めて比べます。
初期費用とランニング費用を分けたうえで、3年程度の総保有コスト（TCO）で比べると、判断しやすくなります。
標準SaaSの月額費用は1,000円台から3万円程度
2026年8月時点の公式掲載例では、Share Managerに月額0円、1,100円、5,500円のプランがあります。
カブカンは無料プランに加え、月額3,300円、9,900円、29,700円のプランを公開しています。
機能の範囲は、株主数、種類株式、株主リスト、総会、配当、API連携などで変わります。特定サービスの価格であり、市場全体の一律相場ではありません（出典：Share Manager公式料金、カブカン公式料金、2026年）。
- 小規模導入：非上場会社が標準機能で始める場合の目安は、初期設定込みで0〜30万円、月額で1,000〜3万円程度です。
初期サポートの範囲、CSV移行の件数、過去取引の登録可否、帳票の追加、郵送、専門家レビューの扱いは、サービスごとに違います。無料プランについても、株主数が増えた後に有料になる条件を確かめます。
個別開発の規模別の推定レンジ
株主管理に特化した受託開発の統計を網羅した公的な相場資料は、確認できていません。そのため、ここでは、NotebookLMで整理したERP・基幹システムの一般的な工数の目安と機能範囲から推定します。
開発期間は、小規模で2〜4か月、標準で4〜8か月、大規模で8〜18か月以上が目安です。ERP一般の相場を当てはめた推定にすぎないため、発注側は同じ要件で複数社から見積もります。
- 小規模台帳：株主マスター、履歴、持株比率、CSV・PDF、権限、簡易ログを備えた場合で、300万〜800万円程度です。
- 標準業務システム：種類株式、SO、資本政策、総会、議決権を含みます。配当、承認、外部連携にも対応する場合で、800万〜2,000万円程度です。
- 上場会社向け：数万名以上の株主、信託銀行連携、電子投票などがある場合で、2,000万〜6,000万円超となる可能性があります。
上場会社向けの想定は、IR分析、冗長化、多言語、厳格な監査証跡まで求める場合です。
見積書で確認する初期費用以外のTCO
初期費用には、要件定義、設計、実装、移行、帳票が含まれ、テストと研修も入ります。
運用費は、利用料、基盤、保守、法改正対応、サポートです。さらに、バックアップ、監視、メール・郵送、API利用料なども含まれます。
発注側は、見積もりに含まれる範囲と、運用時の費用を並べて確認します。
- 従量課金：株主数、利用者数、容量、会社数、API回数によって、料金が変わる場合があります。
- 工程配分：要件定義10%、設計10〜20%、実装40〜60%、テスト10〜20%が、ERP一般の目安です。
- 保守費：初期費用の月5〜15%程度という例があります。対応時間や、障害・法改正対応、軽微な改修の範囲も確かめます。
株主管理システムの見積もりを取る際のポイント
見積もりの精度は、作りたい機能だけでなく、データ、ルール、承認者、帳票をどこまで示せるかで変わります。口頭で伝えた場合、株主や議決権、履歴、移行範囲の想定がずれやすく、各社を比べられません。
要件定義書に添える実データと帳票サンプル
RFPには、会社の種類、非上場か上場かの別、株主数、株式種類、SOや持株会の有無を記載します。
あわせて、年間の増資・譲渡件数と総会回数を示します。配当や利用者数、既存システム、希望稼働時期も伝えます。
匿名化したExcelや帳票を添えたうえで、移行する行数と過去履歴の年数も示します。
- 機能の優先度：必須、できれば、対象外に分け、AI読み取りや投資家ポータルは第2段階にすることもできます。
- 帳票要件：画面と紙・PDFの出力項目の区別、法務確認箇所の明記。
必須にするのは、名簿と取引履歴、基準日です。加えて、株式種類、議決権、株主リスト、操作ログも必須です。
こうして要件を具体的に示せば、不要なカスタマイズを減らし、重要な出力の抜けを防げます。
同じシナリオでの複数社比較
標準SaaS、カスタマイズサービス、個別開発会社を、同じデモシナリオと採点表を使って比べます。
たとえば、創業者とVCがいる会社で増資を行い、その後に一部を譲渡したうえで、基準日の株主と議決権を抽出します。さらに、株主リストと総会資料まで出力してもらいます。
- 操作評価：操作回数、エラー時の戻し方、承認、履歴、出力差異の記録。
- 価格評価：初期費用、移行、月額、追加のユーザーや会社を、3年分で比べます。帳票、API、サポート、研修、保守、法改正対応も加えます。
- 機能評価：株主数の上限、種類株式とSO、総会、配当を確認します。返却、セキュリティ、専門家支援も確かめます。
機能が多くても使えなければ定着しないため、実際に操作する担当者も選定会議に参加させます。
契約と運用の両面でのリスク対策
主なリスクは、要件の膨張、データ移行の不整合、法務要件の認識違い、ベンダーロックイン、情報漏えい、担当者の属人化です。
株主情報は機密性が高いため、異常に気づくためのログと、事故の後に説明できる証跡も必要です。
- 契約条件：変更承認、追加費用、データ所有権、設計書・ソースコードの引渡し範囲、SLA、返却・消去を契約書に明記します。
- セキュリティ：認証、権限、暗号化、ログを個別に確認します。復旧、委託先、CSV制御も、同様に見ます。
- 契約方式：要件定義を準委任、合意後の開発を請負とする組み合わせもあります。
障害時の連絡先も、契約書に盛り込んでおきます。
発注側は、要件が固まってから固定価格の請負にします。変更が多い領域を一括で請け負わせると、追加見積もりと納期延長が繰り返される可能性があります。
セキュリティは、クラウドかどうかにかかわらず、項目ごとに確かめます。具体的には、MFA、RBAC、バックアップ、復旧テスト、脆弱性対応、退職者のアクセス停止が対象です。
契約方式は、開発会社の都合ではなく、要件の確かさと社内の意思決定の速さに合わせて、発注側が選びます。
よくある質問（FAQ）
法務や税務の最終判断は、会社の状況によって変わります。そのため、システムでできることと、専門家へ確認すべきことを分けて考えます。
株主管理はExcelのままでも問題ありませんか？
株主数や取引が少ない段階では、Excelで管理できる場合があります。増資、譲渡、議決権、総会、配当、株主リストを扱い、複数人が編集するようになったら、システムの導入を検討します。
判断するときは、株主数よりも、誤りが出たときの影響と基準日時点の状態を説明できるかを見ます。
標準SaaSと個別開発はどちらを選ぶべきですか？
標準的な名簿、取引履歴、証明書、株主リストが中心であれば、短期間で始めやすく、法改正対応も受けやすい標準SaaSが候補になります。
独自の種類株式、複雑な承認、基幹連携、上場会社向けの非機能要件が重要な場合は、SaaSのカスタマイズや個別開発を比べます。
名簿と履歴はSaaSで、特殊な分析や社内連携は別システムとするなど、段階的に導入する選び方もあります。
IPO準備のために最低限確認すべき機能は何ですか？
株主名簿と新株予約権原簿を正確に管理し、増資、譲渡、SO、種類株式などの履歴を基準日ごとに再現できることが基本です。
証券会社、監査法人、株主名簿管理人へデータを出力できること、登録者と承認者を説明できること、一括で返却できることも確認しておきます。
IPOの直前にまとめて帳票を整えるより、資金調達のたびに原本とシステムを照合する運用を定着させます。
システムだけで会社法や株主総会の判断はできますか？
システムが支援するのは、決められたルールに沿った登録、計算、抽出、出力、証跡の管理です。株主リストの要否、議決権、譲渡の有効性、総会手続きの適法性を、システムが自動で最終判断するわけではありません。
法務・税務のルールを専門家と確認し、その結果を設定、承認フロー、帳票仕様に反映する進め方が安全です。
まとめ
株主管理システム開発は、名簿を画面に移すことにとどまらず、履歴、基準日、議決権、法定帳票、承認、専門家確認を業務の流れにつなげる取り組みです。
要件整理では現行資料を洗い出し、選定ではSaaS・個別開発・BPOの役割を比べ、設計では履歴と証跡を中心に考えます。
6フェーズの小さな始め方と段階的な広げ方
進め方は、要件整理、選定、設計開発、テスト、稼働、定着の順です。最初に整えるのは、名簿、取引履歴、基準日、権限、操作ログ、CSV出力です。
総会、配当、会計、電子契約、IR連携は、優先順位をつけて追加します。費用は月額だけでなく、移行、法務確認、帳票、連携、保守を含めたTCOで比べます。
最初の一歩：現行データと帳票の洗い出し
まず株主名簿、取引台帳、定款を集めます。資本政策表、SO台帳、総会・配当資料も続けて集めます。
- 数値の照合：株主別残高、発行済総数、種類別合計、議決権合計の突き合わせ。
- 候補先への確認：同じシナリオで、移行、帳票、安全性、返却、IPO連携について質問します。
- 導入範囲：現状と資本政策に合わせて、機能と統制の優先度を整理します。
社内と専門家で正解データを合意したうえで、候補先には実データに近いシナリオを示します。
移行方法、帳票、セキュリティ、データ返却、IPO前後の連携を確認してから、開発に進みます。
こうして進めれば、手戻りを抑え、株主から信頼される管理基盤を構築できます。
▼全体ガイドの記事
・株主管理システム開発の完全ガイド
▼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を創業。