株主管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

株主管理システム開発は、株主名簿を電子化するだけでなく、株式の取得・譲渡履歴から基準日時点の持株数と議決権を正確に再現できる業務基盤をつくる取り組みです。

Excelやスプレッドシートで株主を管理している会社では、資金調達、第三者割当増資、株式譲渡、ストックオプションの発行、株主総会、配当のたびに情報が分散しやすくなります。本記事では、株主管理システム開発の進め方を、要件整理、製品・開発会社の選定、設計開発、テスト、稼働、定着の6フェーズに分けて解説します。費用相場、見積もりの確認点、実務で使えるチェック項目まで整理します。

▼全体ガイドの記事
・株主管理システム開発の完全ガイド

株主管理システム開発の全体像

株主管理システムとは、株主名簿、株式取引、資本政策、議決権、株主総会、配当などの情報と手続きを一元管理する業務システムです。開発の成否は、機能の多さよりも、法定帳票に必要な情報と、社内で承認された取引履歴が一貫してつながっているかで決まります。

最低限必要になるのは、株主マスター、株式の種類、株主ごとの保有株式数、取得日、取得原因、譲渡や消却などの取引履歴、持株比率、議決権数、証跡です。株主名簿には氏名または名称、住所、保有株式数、取得日などを持たせますが、実務では現在の残高だけを保存すると、過去の状態を説明できなくなります。

たとえば、2024年の第三者割当増資と2025年の株式譲渡を経て、2025年12月31日時点の株主を確認する場合があります。このとき、システムが取引履歴を時系列で持ち、基準日を指定してスナップショットを再現できれば、現在の名簿と過去の決議資料を同じルールで照合できます。反対に、Excelのセルを上書きする運用では、誰がいつ何を変更したのかをたどりにくくなります。

創業直後の非上場会社では、株主名簿、株式取引、証明書の出力、株主リスト、CSV入出力から始めると過不足がありません。外部株主が増え、種類株式や新株予約権が登場した段階では、資本政策、希薄化シミュレーション、譲渡承認、承認ワークフローを追加します。株主総会や配当の事務負担が大きくなれば、招集通知、委任状、出欠、議決権、配当通知まで対象を広げます。

上場会社では、証券代行会社や株主名簿管理人が大規模な名簿管理と議決権集計を担います。そのため自社でつくるシステムは、名簿管理人の代替ではなく、IR、総会事務局、投資家との対話、社内承認、分析を補完する位置づけになりやすいです。三井住友信託銀行は、2025年3月末時点で受託社数1,657社、管理株主数4,241万名を公表しており、上場会社向けの選定ではこのような外部基盤との役割分担を最初に確認する必要があります（出典: 三井住友信託銀行「株主名簿管理業務」、2025年）。

開発の初期に必ず整理したいのが、会社法第121条に基づく株主名簿と、登記申請に添付する株主リストの違いです。法務省は、株主名簿を添付しても株主リストの添付を省略できないと説明しています。両者は目的や記載内容、議決権数の扱いが異なるため、システムでも「名簿から同じものを出せばよい」と決めつけず、用途ごとの出力仕様を設けます（出典: 法務省「株主リストに関するよくあるご質問」、確認日2026年8月）。

要件表には、どの帳票を、誰が、どの基準日で、どの承認を経て出力するのかを記載します。株主全員の同意による決議、通常の株主総会、登記すべき事項を含む議案では、必要になる一覧の条件が変わる場合があります。法務担当者だけで判断せず、司法書士、弁護士、税理士、株主名簿管理人など、実際の書類を確認する専門家にレビューを依頼することが安全です。

株主管理システム開発の進め方は6フェーズです

株主管理システムの進め方は、要件整理、製品・開発会社の選定、設計開発、テスト、稼働、定着の6フェーズに分けると管理しやすくなります。初めから全機能を完成させるのではなく、名簿と取引履歴を正確にする基盤を先に整え、その後に総会、配当、会計、電子契約、IR連携へ広げる方法が現実的です。

最初に、株主名簿、株式取引台帳、定款、資本政策表、新株予約権原簿、株主間契約、総会資料、配当資料、会計データを集めます。ファイル名を並べるだけでなく、現行データの項目、更新者、更新頻度、参照する基準日、原本の所在、重複と欠損を一覧化します。特に、株式数の合計と発行済株式総数が一致するか、種類株式ごとの合計が定款や登記と矛盾しないかを確認します。

MUST要件には、株主名簿の作成、取引履歴、基準日スナップショット、種類株式、議決権、法定帳票、権限、操作ログ、CSV出力を置きます。WANT要件には、AIによるOCR、株主への一括メール、ダッシュボード、投資家ポータル、高度な希薄化シミュレーションなどを置き、初期導入の範囲から分離します。要件整理の成果物は、業務フロー、データ項目一覧、帳票サンプル、権限表、非機能要件、移行方針、受入基準です。

この段階で、法務上の判断とシステム上の判断を区別します。たとえば「この株主を議決権の対象に含めるか」は業務・法務のルールであり、「基準日を指定して対象者を抽出できるか」はシステム要件です。両者を一つの曖昧な要望にまとめると、後工程で仕様変更が発生しやすくなります。

選定では、標準クラウドSaaS、既存SaaSへのAPI・帳票カスタマイズ、FileMakerなどのローコード開発、スクラッチ開発、証券代行や総会運営のBPO併用を比較します。非上場の小規模会社で法定帳票と取引履歴が中心なら標準SaaSが候補になります。独自の種類株式、複雑な承認、既存基幹システムとの連携が経営上重要なら、カスタマイズや個別開発を検討します。

候補先には、株主数の上限、種類株式とSOの管理、過去取引の訂正方法、株主名簿と株主リストの出力、基準日管理、データのエクスポート、API、MFA、権限、操作ログ、バックアップ、障害時の復旧目標、解約時のデータ返却を質問します。デモでは新規株主を登録するだけでなく、増資、譲渡、株式分割、権利行使、配当、総会決議を時系列で操作し、過去の日付に戻して同じ結果が出るかを確認します。

IPOを予定する会社は、証券会社、監査法人、株主名簿管理人にどの形式でデータを渡すかを選定段階で聞きます。2025年4月、みずほ信託銀行とスマートラウンドは、smartroundで管理する株主名簿や新株予約権原簿などの情報を、株主名簿管理人へ連携できる機能の拡充を公表しました。IPO直前に移行方法を考えるのではなく、将来の受け渡し形式を初期要件に含める判断材料になります（出典: みずほ信託銀行「スマートラウンドとの提携内容の拡充について」、2025年）。

設計では、現在の残高を直接書き換えるのではなく、取引イベントを積み上げて残高を計算するデータモデルを基本にします。発行、取得、譲渡、贈与、相続、消却、自己株式、株式分割、種類株式の転換、新株予約権の付与・行使・失効を、会社の業務ルールに合わせて定義します。訂正が必要な場合も元データを削除せず、訂正理由、承認者、承認日時、変更前後の値を保存できる設計が必要です。

権限は、管理者、株式事務担当、経理、法務、経営層、外部専門家などに分けます。株主の住所や連絡先を閲覧できる人と、株式取引を承認できる人を同じにする必要はありません。MFA、IP制限、セッション管理、退職者の即時無効化、CSVダウンロードの制御、操作ログの保存期間まで設計書に書きます。クラウドであっても、権限分離と証跡が自動的に整うとは限りません。

帳票設計は画面設計と並行して進めます。株主名簿、株主リスト、株主名簿記載事項証明書、議決権集計、招集通知、委任状、議事録、配当通知書などの実物をサンプルとして、出力項目、日付、株式種類、基準日、押印・署名の扱いを確認します。AIやOCRを導入する場合は、読み取り結果を人が承認する画面と、原本ファイル、読み取り日時、承認者を残す仕組みを必ず設けます。

テストは、画面が表示されるかを確認するだけでは不十分です。現行Excelから移行した株主ごとの残高、発行済株式総数、株式種類別合計、議決権合計を、原本や専門家が確認した正解データと照合します。最低でも、創業時、増資後、譲渡後、株式分割後、SO行使後、自己株式取得後など、会社の履歴を代表するケースを用意します。

受入テストでは、担当者が業務シナリオを最初から最後まで操作します。たとえば「基準日を設定する」「対象株主を抽出する」「議決権数を確認する」「招集通知を出力する」「議決結果を登録する」「議事録と株主リストを作成する」という流れです。想定結果だけでなく、権限のない人がCSVをダウンロードできないこと、承認前の取引が帳票に反映されないこと、二重登録を防げることも確認します。

障害・復旧テストも省略しません。バックアップの取得頻度、復旧にかかる目標時間、復旧後にどの時点までの取引が戻るか、災害時の連絡先、サービス停止中の代替手順を確認します。上場会社の議決権電子行使のように、データの改ざんや漏えいに高い対策を求められる領域では、ISO/IEC 27001の取得有無だけでなく、アクセス制御、暗号化、冗長化、復旧手順の実効性を質問します（出典: ICJ「議決権電子行使プラットフォームの安全性」、確認日2026年8月）。

本番稼働前には、移行対象を「現時点の株主名簿」だけにするのか、「過去の取引履歴」まで含めるのかを決めます。IPO準備や株主からの照会を考えると、少なくとも重要な増資、譲渡、SO、種類株式の発行・転換は履歴として説明できる状態にしておくことが望ましいです。ただし、古い資料の欠損を無理に推測して入力すると、きれいに見える誤データになります。原本が確認できない項目は、未確認、推定、専門家確認待ちなどの状態を持たせます。

移行は、抽出、名寄せ、変換、取込、照合、承認の順に実施します。法人名の表記揺れ、住所変更、旧姓、同一人物の重複、株主番号の欠落、株式種類の略称などを洗い出します。移行後に発行済株式総数と株主別合計が合わない場合は、システムの不具合ではなく、現行資料の不整合が原因になっていることもあります。移行判定表に差異、原因、対応者、承認日を記録します。

稼働日には、誰が取引を登録し、誰が承認し、誰が帳票を発行し、問い合わせを誰が受けるかを決めます。年度の株主総会直前や大型の資金調達直前に切り替えると、旧システムとの二重管理が発生しやすくなります。余裕のある時期に読み取り専用の並行稼働を行い、1回分の総会や配当を新システムでリハーサルしてから切り替えると安全です。

稼働後の定着では、システム操作の研修だけでなく、株式取引が発生したときの業務ルールを整備します。「契約書を受領する」「法務または専門家が確認する」「担当者が仮登録する」「責任者が承認する」「残高と帳票を照合する」「原本を保管する」という流れを手順書にします。担当者が休んでも処理できるよう、属人化した判断をチェック項目と承認ルートに置き換えます。

月次または四半期ごとに、未承認取引、重複株主、帳票との差異、権限付与状況、ログの異常、バックアップ結果を点検します。株主数や資金調達の回数が増えたら、総会や配当を追加し、IPO準備の進捗に合わせて証券会社・監査法人・株主名簿管理人とのデータ連携を再確認します。AI機能は、読み取り精度だけでなく、誤りを人が発見して訂正できるかを運用指標にします。

2026年時点では、法務省の法制審議会でバーチャルオンリー株主総会、実質株主確認、株主総会のデジタル化などが検討されています。検討中の制度を確定事項としてシステムに埋め込むのではなく、帳票や議決権ルールを更新できる設定方式にし、ベンダーの法改正対応方針とリリース通知の仕組みを契約前に確認します（出典: 法務省「会社法制（株式・株主総会等関係）部会」、2025〜2026年）。

株主管理システムの費用相場とコストの内訳

株主管理システムの費用は、標準SaaSを使うか、既存サービスを拡張するか、専用システムを開発するかで大きく変わります。月額料金だけで比較すると、データ移行、法務確認、帳票、連携、研修、保守が抜け落ちます。初期費用とランニング費用を分け、3年程度の総保有コストで比べると判断しやすくなります。

2026年8月時点で公式ページに掲載されている例では、Share Managerに月額0円、1,100円、5,500円のプランがあり、株主数や種類株式、株主リスト、株主総会などで機能が分かれます。カブカンは無料プランに加えて、月額3,300円、9,900円、29,700円のプランを公開しており、株主数、総会、配当、API連携などの範囲で差がつきます。これらは特定サービスの価格であり、市場全体の一律相場ではありません。

小規模な非上場会社が標準機能だけで始める場合、初期設定を含めて0〜30万円程度、月額1,000〜3万円程度が入口の目安になります。ただし、公式料金に含まれる初期サポートの範囲、CSV移行の件数、過去取引の登録、帳票の追加、郵送、専門家レビューはサービスごとに違います。無料プランでも、株主数が増えた段階で有料化する条件を確認しておきます（出典: Share Manager公式料金、カブカン公式料金、2026年）。

株主管理専用の受託開発統計を網羅した公的な相場資料は確認できないため、ここではNotebookLMで整理したERP・基幹システムの一般的な工数目安と、株主管理の機能範囲から推定します。株主マスター、取引履歴、持株比率、CSV・PDF出力、権限、簡易ログに絞った小規模な専用台帳は300万〜800万円程度、種類株式、SO、資本政策、総会、議決権、配当、承認、外部連携を含む標準的な業務システムは800万〜2,000万円程度が一つの検討レンジです。

数万名以上の株主、証券代行・信託銀行との連携、IR分析、電子投票、冗長化、多言語、厳格な監査証跡まで求める上場会社向けでは、2,000万〜6,000万円超となる可能性があります。開発期間の目安は、小規模で2〜4か月、標準的な業務システムで4〜8か月、大規模案件で8〜18か月以上です。これらは公開された株主管理専用統計ではなく、ERP一般の相場を機能範囲に当てはめた推定ですので、発注前には必ず同じ要件で複数社から見積もりを取ります。

初期費用には、要件定義、設計、実装、データ移行、帳票、テスト、研修が含まれます。ランニング費用には、利用料、クラウド基盤、保守、法改正対応、サポート、バックアップ、監視、メールや郵送、API利用料が含まれます。株主数やユーザー数、保存容量、会社数、API回数に応じて従量課金になる場合もあります。

開発案件では、要件定義10%、設計10〜20%、実装40〜60%、テスト10〜20%程度というERP一般の配分を補助線にすると、工程別の金額を読みやすくなります。保守費を初期費用の月5〜15%程度とする見積もりもありますが、提供される時間、障害対応、法改正対応、軽微な改修の範囲で大きく変わります。数字だけで安い会社を選ばず、何が含まれるかを比較します。

株主管理システムの見積もりを取る際のポイント

見積もりの精度は、発注側が「何をつくりたいか」だけでなく、「どのデータを、どのルールで、誰が承認し、どの帳票にするか」を示せるかで変わります。口頭で機能を伝えるだけでは、会社ごとに想定する株主、議決権、履歴、移行の範囲がずれて比較できません。

RFPには、会社の種類、非上場・上場の別、株主数、株式種類、SOや持株会の有無、年間の増資・譲渡件数、株主総会の開催回数、配当の有無、利用者数、既存システム、希望稼働時期を記載します。さらに、現在のExcelや帳票を匿名化したサンプルとして添え、移行対象の行数と過去履歴の年数を示します。

機能ごとに、必須、できれば、対象外を区分します。株主マスター、取引履歴、基準日、株式種類、議決権、株主リスト、操作ログは必須、AI読み取りや投資家ポータルは第2段階というように分けます。帳票については、画面上の項目と紙・PDFに出す項目を分け、法務確認が必要な箇所を明記します。こうすると、不要なカスタマイズを減らしながら、重要な出力の抜けを防げます。

標準SaaS、カスタマイズ可能なサービス、個別開発会社を同じ土俵で比べるには、同じデモシナリオと採点表を使います。創業者とVCがいる会社に第三者割当増資を行い、その後に一部譲渡し、基準日で株主と議決権を抽出し、株主リストと総会資料を出力する流れを見せてもらいます。操作回数、エラー時の戻し方、承認の有無、履歴の表示、出力の差異を記録します。

価格評価では、初期費用、移行費用、月額、追加ユーザー、追加会社、帳票、API、サポート、研修、保守、法改正対応を3年分にそろえます。機能評価では、株主数の上限、種類株式とSO、総会、配当、データ返却、セキュリティ、専門家支援を確認します。機能が多くても、自社の担当者が日常的に使えなければ定着しませんので、実際に操作する担当者を選定会議へ参加させます。

株主管理システムでは、要件の膨張、データ移行の不整合、法務要件の認識違い、ベンダーロックイン、情報漏えい、担当者の属人化が主なリスクです。対策として、仕様変更の承認手順、追加費用の算定方法、データ所有権、設計書とソースコードの引き渡し範囲、SLA、障害時の連絡、契約終了時の全データ返却・消去を契約書に明記します。

セキュリティの質問は「クラウドだから安全ですか」ではなく、MFA、RBAC、暗号化、操作ログ、バックアップ、復旧テスト、脆弱性対応、委託先管理、退職者のアクセス停止、CSVの持ち出し制御を個別に聞きます。機密性の高い株主情報を扱うため、認証と権限だけでなく、異常を発見できるログと、事故後に説明できる証跡が必要です。

請負契約を選ぶ場合は、要件が固まっていないまま固定価格にしないことが重要です。まず要件定義を準委任で進め、合意した範囲を設計・開発の請負に分ける方法もあります。反対に、変更が頻発する領域を一括請負にすると、追加見積もりと納期延長が繰り返される可能性があります。契約方式は、開発会社の都合ではなく、要件の確度と社内の意思決定速度で選びます。

よくある質問（FAQ）

最後に、株主管理システムの導入を検討する会社からよく寄せられる質問に回答します。法務や税務の最終判断は会社の状況によって変わるため、システムでできることと、専門家へ確認することを分けて考えます。

株主数が少なく、取引も少ない段階では、Excelで管理できる場合があります。ただし、増資や譲渡の履歴、議決権、株主総会、配当、株主リストを扱うようになり、複数人が編集する状態になったら、履歴・承認・権限を管理できるシステムを検討する時期です。株主数ではなく、間違えた場合の影響と、基準日時点の状態を説明できるかで判断します。

標準的な株主名簿、取引履歴、証明書、株主リストが中心なら、短期間で始めやすく法改正対応を受けやすい標準SaaSが候補です。独自の種類株式、複雑な承認、既存基幹システムとの連携、上場会社向けの厳格な非機能要件が経営上重要なら、SaaSのカスタマイズや個別開発を比較します。最初から二者択一にせず、名簿と履歴はSaaS、特殊な分析や社内連携は別システムという段階導入も選択肢です。

株主名簿と新株予約権原簿を正確に管理し、増資、譲渡、SO、種類株式などの履歴を基準日ごとに再現できることが基本です。加えて、証券会社、監査法人、株主名簿管理人へ渡すデータを出力できること、誰が登録・承認したかを説明できること、データを一括返却できることを確認します。IPO直前に帳票を整えるのではなく、資金調達のたびに原本とシステムを照合する運用を定着させます。

システムは、決められたルールに沿った登録、計算、抽出、出力、証跡管理を支援するものです。株主リストの要否、議決権の扱い、株式譲渡の有効性、総会手続きの適法性などを自動的に最終判断するものではありません。法務・税務のルールを専門家と確認し、その結果をシステムの設定、承認フロー、帳票仕様に落とし込む進め方が安全です。

まとめ

株主管理システム開発は、現在の株主名簿を画面に移す作業ではなく、株式の履歴、基準日、議決権、法定帳票、承認、専門家確認を一つの業務フローにつなげる取り組みです。要件整理では現行資料を棚卸しし、選定ではSaaS・個別開発・BPOの役割を比べ、設計では履歴と証跡を中心に考えます。

進め方の軸は、要件整理、選定、設計開発、テスト、稼働、定着です。最初は株主名簿、取引履歴、基準日、権限、操作ログ、CSV出力を確実にし、総会、配当、会計、電子契約、IR連携は優先順位をつけて追加します。費用は公開SaaSの月額だけでなく、移行、法務確認、帳票、連携、保守を含むTCOで比較します。

まずは株主名簿、取引台帳、定款、資本政策表、SO台帳、総会資料、配当資料を集め、株主別残高、発行済株式総数、株式種類別合計、議決権合計を照合します。そのうえで、候補サービスや開発会社に同じ実データに近いシナリオを示し、移行方法、帳票、セキュリティ、データ返却、IPO前後の連携を質問します。社内と専門家が正解データを合意してから開発に進めば、後工程の手戻りを抑えながら、株主から信頼される管理基盤を構築できます。

株主管理の現状や将来の資本政策に合わせて、必要な機能と導入範囲を整理することから始めると、過剰な開発と不足する統制の両方を避けやすくなります。

▼全体ガイドの記事
・株主管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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