投資信託管理システム開発の発注/外注/依頼/委託方法について

投資信託管理システムの発注・外注では、基準価額（NAV）の計算精度と日次締め、データ照合、監査証跡、障害時の復旧責任までを先に定義し、標準サービスと個別開発の範囲を切り分けることが成功の要点です。

投資信託管理システムは、投資家向けアプリや販売管理画面だけを作るプロジェクトではありません。市場価格や為替、約定、残高、未収収益、信託報酬などを取り込み、ファンドの評価、基準価額、仕訳、帳票、販売会社・信託銀行との連携までを日々正しく動かすバックオフィス基盤です。本記事では、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較のポイントを、発注担当者が社内で説明しやすい順に解説します。

▼全体ガイドの記事
・投資信託管理システム開発の完全ガイド

投資信託管理システムの発注・外注で最初に整理する全体像

発注前に決めるべきなのは、画面の数や機能名ではなく、信託財産に関するどの業務を、どの会社の責任で、どの時間までに完了させるかです。対象範囲を誤ると、販売チャネルだけが新しくなり、計理や照合はExcelのまま残ることがあります。反対に、基幹システム全体を一度に刷新しようとすると、費用と移行リスクが膨らみます。

一般に投資信託管理システムは、ファンド、銘柄、口座、受益者、運用会社などのマスタを管理し、市場価格、為替、格付、銘柄属性といった外部データを取り込みます。さらに、注文・約定・決済、保有残高、簿価、損益、時価評価、利息・配当、未払費用、信託報酬、分配金、決算、仕訳、帳票をつなぎます。導入目的が「事務を効率化する」だけでも、最終的には基準価額の根拠を追跡できること、訂正や再計算の履歴が残ることが重要です。

2026年4月時点のNRI公式情報では、投資信託向けのT-STAR/TXについて、信託財産のNAV計算や運用会社に代わる計算業務を支援するサービスであることが説明されています。これは、投資信託管理システムを外注するときに、一般的なWeb開発会社ではなく、投信計理と受託業務の責任を理解する委託先を見極める必要があることを示す具体例です（出典: 野村総合研究所「T-STAR/TX」、2026年4月時点）。

RFPの最初に、今回の対象を「ファンドマスタ、日次評価、NAV計算、帳票、販売会社との連携、データ移行」までとするのか、「フロントの運用管理、顧客ポータル、DWH、会計システム」まで含めるのかを書きます。同時に、対象外も明記します。例えば、コア計理は共同利用型サービスを使い、独自の分析画面と社内ワークフローだけを追加開発する方針であれば、どの範囲を標準機能に合わせるかを先に合意できます。

とくに重要なのが正本データの定義です。市場価格の採用値、残高、約定、NAV、仕訳の正本がそれぞれどのシステムにあるのか、連携遅延や不一致が起きたときに誰が判定し、誰が訂正するのかを決めます。システム会社へ丸投げすると、発注者は業務を知っていても計算責任を負い、ベンダーは仕様どおりに作っただけという状態になりかねません。

投資信託管理システムの発注形態はどれを選びますか？

発注形態は、パッケージ・共同利用型サービス、専用クラウド、スクラッチ開発、そして構想やPoCを分ける段階発注の4つで比較すると判断しやすくなります。結論として、標準的な投信計理を早く安定させたい場合はサービス型、独自計算や既存基幹との深い統合が競争力になる場合は個別開発型、判断材料が不足している場合は段階発注が適しています。

パッケージや共同利用型サービスは、ファンドマスタ、評価、基準価額、帳票、権限、監査ログ、日次運用など、金融業務で繰り返し使われる機能を活用できる方式です。計算ロジックや制度対応を自社で一から保有する範囲が小さくなり、インフラ、バックアップ、代替サイト、運用監視も含めて委託しやすい点が利点です。新規参入やファンド数がまだ少ない会社では、初期投資と専門人材の固定化を抑えやすくなります。

ただし、標準機能に合わせることが前提になります。独自の信託報酬計算、特殊な資産クラス、社内承認、帳票様式を追加するほど、アドオン費用とバージョンアップ検証が増えます。デモでは正常系だけを見ず、外国資産、価格欠損、コーポレートアクション、締め後訂正、再計算、照合不一致をサンプルデータで確認し、標準、設定、追加開発、業務変更のどれで対応するかをFit & Gap表に残します。

専用クラウド型は、投信管理のコアをクラウド上に置き、既存の会計、DWH、販売会社、資産管理銀行、カストディアンなどとAPIやファイルで連携する方式です。自社専用のデータ分離や権限設計、拡張性を確保しながら、ハードウェアの更改や運用監視の負担を抑えられます。一方で、クラウド利用審査、暗号鍵、バックアップ、ログ保存、データ所在地、障害時の復旧、再委託先の管理を契約書と運用設計で確認する必要があります。

実務上は、コア計理や基準価額計算を実績あるサービスに寄せ、独自のワークフロー、分析、DWH、AI活用をAPIで周辺化するハイブリッドが有力です。2026年1月にNRIが公表したT-STAR/GVの新機能では、発注・約定システム、資産管理銀行やカストディアンの残高、SWIFTなどを連携し、IBORデータとの照合・補正を自動化し、APIを提供する方向が示されています。発注時は「画面をクラウド化できるか」だけでなく、データの鮮度と照合まで評価します（出典: 野村総合研究所「T-STAR/GV」新機能、2026年1月）。

ファンド数、資産クラス、外部接続、既存データの品質が把握できていない段階で、本開発を一括発注するのは危険です。最初の契約を現行業務の棚卸し、主要な計算ケースの整理、サンプルデータによるPoC、データ移行方針、概算WBSの作成に限定し、その成果物を次のRFPと本契約に利用します。安い初期提案に移行やテストが含まれていない場合も、差分を可視化できます。

PoCの終了条件は、画面が表示されることではありません。代表ファンドのNAVや残高が旧システムと一致すること、価格欠損や休日を説明できること、照合差異を検知して再処理できること、障害時の切り戻し手順を実行できることを合格条件にします。発注を分ける場合も、成果物の著作権、設定値、テストデータ、ソースコード、次工程での利用権を契約に書いておくことが大切です。

RFP・要件整理では投信計理と非機能要件を数値化します

RFPは、開発会社へ機能一覧を渡すだけの文書ではありません。目的、対象範囲、現行業務、計算ルール、データ連携、移行、セキュリティ、運用、契約、見積条件をそろえ、複数社から同じ前提で提案を受けるための文書です。すべての仕様を発注者が完成させる必要はありませんが、判断してほしい論点と、発注者が決める論点を分けて記載します。

目的は、「投信業務を刷新する」ではなく、例えば日次締めを短縮したい、手作業の照合を減らしたい、ファンド追加のリードタイムを短くしたい、制度改正に対応しやすくしたい、と業務成果で書きます。対象業務は、ファンド設定、注文・約定、残高、価格・為替取込、評価、収益・費用、NAV、分配、決算、帳票、会計、訂正、監査、運用監視に分けます。

現行業務では、ファンド数、資産クラス、通貨、1日あたりの取引量、価格データの取得時刻、締め時間、帳票数、利用者数、外部接続数を記載します。Excelで補正しているデータ、担当者の経験で判断している例外、月末や決算日にだけ発生する処理も省略しません。新システムの対象外を明確にすると、提案各社の見積範囲がそろいやすくなります。

投資信託管理システムの要件定義で最も避けたいのは、自然言語だけで計算仕様を済ませることです。基準日、価格の採用優先順位、為替レート、未収利息、配当、信託報酬、監査費用、税金、端数処理、休日、償還、分配金、評価不能時の扱いを、入力値と期待結果の組み合わせで示します。基準価額の1円差が販売会社への連携や開示に影響するため、正常系だけでなく異常系を先に作ります。

外国証券では、時差、現地休日、為替、未収利息、約定日と受渡日のずれを例示します。コーポレートアクションでは、株式分割・併合、配当、償還、合併などを対象にし、イベントの訂正や再計算の履歴を残す条件を決めます。計算結果だけでなく、どのデータを使い、誰が承認し、どの処理を再実行したかを追跡できることまで受入条件にします。

非機能要件は「高性能」「安全に運用できる」と書くだけでは比較できません。日次バッチを何時までに完了させるか、ピーク時の処理件数、画面応答時間、同時利用者数、稼働率、障害検知時間、復旧時間目標（RTO）、復旧時点目標（RPO）、バックアップ保持期間を数値化します。日次締めに間に合わない場合の代替処理と、翌日の販売・帳票へ影響を出さないための切り戻し条件も必要です。

金融機関向けの発注では、権限分離、承認ワークフロー、操作ログ、データ訂正履歴、暗号化、脆弱性対応、監査対応、委託先管理、再委託管理、災害復旧を要件に含めます。金融庁とFISCの2025年5月の意見交換会でも、FISC安全対策基準などの改訂、サイバーセキュリティ、ITガバナンス、システムリスク管理が議論されています。RFPに「FISC準拠」とだけ書かず、対象基準、確認方法、証跡の提出者を具体化します（出典: 金融庁「金融庁・FISCの意見交換会について」、2025年5月）。

移行要件では、旧システムのファンド、銘柄、残高、簿価、評価額、収益、費用、履歴、帳票をどこまで移すかを定義します。移行前後で件数、残高、評価額、NAV、仕訳、帳票を突合し、許容差と未解決差異の扱いを決めます。切替前に複数回のリハーサルと新旧並行計算を行い、稼働判定、切り戻し期限、業務継続手順を発注条件に入れることが大切です。

投資信託管理システムの契約形態と責任分界を決める方法

投資信託管理システムでは、すべてを請負契約にして完成品を受け取れば安心とは限りません。業務ルールや現行データを調べる段階、標準サービスを選ぶ段階、本開発、移行、運用保守では、確定できる範囲と変動する範囲が違うためです。準委任、請負、サービス利用契約、保守契約を工程ごとに組み合わせ、成果物と責任の境界を明確にします。

準委任契約は、発注者とベンダーが協力して業務を調査し、要件を整理し、検討や作業を進める場合に使いやすい契約形態です。現行業務の棚卸し、RFP作成支援、Fit & Gap、PoC、移行方針、プロジェクト管理支援など、開始時点で成果の詳細を固定しにくい工程に向いています。ただし、作業時間を提供する契約になりやすいため、作業範囲、体制、定例報告、成果物、検収方法、追加作業の承認手順を明記します。

発注者側にも、業務部門から計算ルールや例外処理を出す責任が残ります。ベンダーに「調査してもらう」だけでなく、業務一覧、課題一覧、決定事項、未決事項、リスク一覧、次工程の判断材料を成果物にします。準委任だから品質を問えないという意味ではなく、成果物の内容とレビュー基準を契約・個別発注書に置くことが重要です。

請負契約は、合意した成果物を完成させ、検収を受ける工程に向いています。画面、API、バッチ、帳票、データ移行、テスト証跡、操作マニュアルなど、何を納品するかを一覧化し、処理件数、エラー時の挙動、性能、セキュリティ、許容差を受入基準にします。「投資信託管理システム一式」のような曖昧な表現では、完成の判断ができません。

投信業務では、開発途中に制度改正、商品の追加、価格データの変更、接続先の仕様変更が起きます。変更要求の受付者、影響分析、見積提示、承認者、納期変更、テスト追加を手続き化します。納品後に発注者が自社で設定を変更できる範囲、ソースコードや設定ファイルの引渡し、第三者保守への切替条件も、将来のベンダーロックインを左右する項目です。

サービス利用型では、ソフトウェアの機能よりも、業務を止めないための責任分界が契約の中心になります。サービス提供時間、障害の重大度、一次応答、復旧目標、計画停止、バックアップ、データ返却、ログの保存、脆弱性対応、法改正対応、サポート窓口、再委託先、監査資料の提供範囲を確認します。NAVや帳票の誤りが発生した場合に、発注者、サービス提供者、価格データ会社、信託銀行のどこが調査と訂正を担うかも必要です。

金融庁の監督指針やFISCの安全対策基準を参照する場合でも、基準への適合を一文で保証してもらうのではなく、アクセス権限、ログ、バックアップ、災害復旧、委託先評価、インシデント報告といった具体的な統制に分解します。契約締結前に法務、情報セキュリティ、監査、業務部門を参加させると、稼働後に追加条件が発生するリスクを抑えられます。

投資信託管理システムの費用相場と5年TCOの考え方

投資信託管理システム専用の公示価格は少なく、費用はファンド数、資産クラス、外部連携数、既存データの品質、計算ルール、帳票、移行、並行稼働、SLA、DRによって大きく変わります。以下の金額は公開された専用製品価格ではなく、一般的なシステム開発相場と投信業務特有の工数をもとにした、発注前の推定レンジです。提案比較では、金額だけでなく前提条件をそろえてください。

既存システムに帳票、EUC、ファンドマスタ、データクレンジング、限定的な連携を追加する周辺開発は、500万円から3,000万円程度、期間は3か月から6か月程度が一つの推定目安です。パッケージや共同利用型サービスを導入し、設定、外部データ連携、移行、教育、受入試験まで行う場合は、3,000万円から1億5,000万円程度、6か月から12か月程度を見込みます。

NAV、計理、外国資産、コーポレートアクション、複数の外部接続、並行稼働、DRを含む基幹刷新では、1億5,000万円から5億円程度、12か月から24か月程度が目安です。独自計算ロジックや複数会社・大量ファンドを含むフルスクラッチでは、5億円から20億円以上、18か月から36か月以上に及ぶ可能性があります。一般的な2026年のシステム開発相場として、SIAは小規模100万円から300万円、中規模500万円から1,000万円、大規模1,000万円から数千万円以上、人月単価60万円から200万円程度を示していますが、これは投信専用価格ではありません（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。金融系では専門テスト、移行、監査資料、制度対応が加わるため、一般相場の下限だけで予算を決めないことが重要です。

見積書は一式金額ではなく、要件定義、基本・詳細設計、実装、連携、テスト、品質保証、プロジェクト管理、インフラ、移行、教育、稼働立会い、保守に分けてもらいます。検討のたたき台として、要件定義10〜20％、設計・実装40〜50％、テスト15〜25％、PM・品質管理10〜15％、インフラ・移行・教育5〜20％ほどの配分を置けます。ただし、これは統計的な固定比率ではなく、抜け漏れを確認するための参考です。

投資信託案件では、通常の画面開発よりもテストと移行が膨らみやすくなります。過去日付の再現、日次・月次・決算処理、価格欠損、異常データ、訂正、再計算、照合差異、権限、障害復旧、新旧並行計算を確認するからです。見積書にこれらの項目がなければ、「含まれていない」のか「別費用」なのかを確認し、追加費用の条件を明示してもらいます。

5年TCOには、初期開発費だけでなく、サービス利用料やライセンス、クラウド、回線、価格・為替データ、監視、バックアップ、障害対応、法改正、バージョンアップ、監査、教育、追加ファンド、追加接続先の費用を含めます。初期費用が安いパッケージでも、アドオン、ファンド追加、帳票変更、制度改正の都度に費用が発生し、5年後にはスクラッチより高くなる場合があります。

比較表には、ファンドを1本追加する単価、資産クラスを増やす単価、接続先を1つ増やす単価、テスト環境の追加費用、休日・夜間の障害対応費、制度改正対応の範囲を入れます。価格データの利用料や信託銀行・カストディアンとの接続費が別契約になっていないかも確認します。5年分の費用を同じ前提で並べると、単年度予算だけでは見えない保守負担と拡張性を比較できます。

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

委託先は、会社の知名度や見積金額だけで決めません。投信計理、NAV、資産評価、価格データ、外国証券、コーポレートアクション、会計、帳票、移行、障害対応をどれだけ具体的に経験しているかを確認します。専用サービスを提供する会社と、汎用SIやコンサルティングで周辺刷新を担う会社では得意領域が異なるため、同じ評価軸だけで順位をつけないことが大切です。

候補会社には、投資信託の基準価額、信託報酬、未収・未払、分配、決算、外国資産、残高照合、法定・社内帳票をどの範囲まで支援できるかを質問します。実績は社名や導入件数だけでなく、担当した業務、ファンド数、資産クラス、外部接続、稼働後の保守年数、障害や制度改正への対応事例まで聞きます。守秘義務で顧客名を出せない場合でも、匿名化した業務範囲と成果物のサンプルを確認できます。

デモでは、発注者が用意したサンプルデータを使い、価格の取り込みから評価、NAV、帳票、照合、承認、訂正、再計算までを通します。結果の正しさだけでなく、計算根拠を追跡できるか、異常を検知できるか、再実行して二重計上しないか、利用者が説明できるログを出せるかを評価します。画面が美しくても、締め処理と例外対応を説明できない会社は慎重に見極めます。

3社以上へ同じRFPを渡し、見積比較表の列を発注者側で決めておくと、価格だけの比較を避けやすくなります。比較項目は、要件定義、ライセンス・利用料、設定、追加開発、連携、データ移行、テスト、教育、稼働支援、保守、インフラ、監視、DR、法改正、追加ファンド、追加接続、消費税の扱いです。各社に「含む」「別途」「対象外」「未確定」を記載してもらいます。

提案が安い場合は、要件定義やPMが少ない、移行データを発注者が整備する、並行稼働を含まない、テストケースを限定する、保守と制度改正を別契約にするなどの理由があります。高い場合も、監査証跡、代替サイト、24時間対応、金融業務の専門テスト、手厚い移行支援が含まれているかを確認します。差額の理由を説明できる見積書は、契約後の追加請求や認識違いも減らします。

選定時は、稼働後の障害対応を必ず質問します。価格データが遅れた場合、外部連携が重複した場合、NAVの計算結果が合わない場合、締め時間に間に合わない場合に、誰が検知し、どのログを確認し、どの手順で再計算し、いつまでに報告するのかを確認します。重大度ごとのSLA、休日対応、代替サイト、切り戻し、顧客・当局への報告支援まで確認すると、提案書の運用体制を具体的に比べられます。

2024事務年度の金融行政方針では、投資信託の基準価額を委託会社と受託会社が二重に計算する慣行の見直しと一者計算の普及、公販ネットワークの互換性確保が示されています。今後の発注では、現在の機能を置き換えるだけでなく、計算責任の変化や販売会社とのデータ連携に対応できるかを評価します（出典: 金融庁「2024事務年度金融行政方針」、2024年8月）。制度やサービス仕様は更新されるため、公開情報と個別提案書を契約前に再確認してください。

投資信託管理システムの発注・外注でよくある質問

最後に、発注担当者から寄せられやすい疑問を整理します。投資信託管理システムは個別条件で費用や責任分界が変わるため、FAQの回答をそのまま仕様にせず、自社のRFP、契約、監査・法務の確認へつなげてください。

周辺業務の追加開発なら500万円から3,000万円程度、パッケージ・共同利用型の導入なら3,000万円から1億5,000万円程度、基幹刷新なら1億5,000万円から5億円程度が発注前の推定レンジです。専用システムの公示価格ではなく、ファンド数、資産クラス、連携、移行、テスト、DR、保守で変動します。見積は初期費用ではなく、利用料・データ料・制度改正・追加ファンドを含む5年TCOで比較してください。

すべての詳細設計をRFPで完成させる必要はありませんが、基準日、価格・為替の採用、費用計上、端数処理、例外、再計算、訂正、締め時間、正本データ、受入テストの考え方は示すべきです。代表的なファンドと異常系のサンプルデータ、期待結果を渡し、ベンダーの提案で補う部分と発注者が決定する部分を分けると、提案と見積の差が小さくなります。

標準的な計理、NAV、帳票、権限、監査、運用を早く安定させたい場合は、パッケージや共同利用型サービスを核にする方法が有力です。独自の計算、複数会社をまたぐ業務、既存基幹との特殊な接続が事業上不可欠で、長期保守の人材と費用を持てる場合はスクラッチを検討します。迷う場合は、コア計理を標準化し、差別化部分をAPIや周辺開発で補う方式からFit & Gapを始めると判断しやすくなります。

発注は可能ですが、コア計理やNAV計算を任せる場合は、投信業務を理解する専門会社との体制を組めるか確認してください。汎用SI会社に依頼する場合でも、投信計理の有識者、価格データや受託銀行との連携経験、金融水準のテスト・監査・障害対応を持つ再委託先やパートナーを明示してもらいます。提案時のサンプル計算、計算根拠、異常時の復旧説明が評価材料になります。

まとめ｜投資信託管理システムの外注はRFPと責任分界から始めます

投資信託管理システムの発注・外注では、最初から画面や技術を決めるのではなく、投資信託の業務フロー、計算ルール、締め時間、データの正本、例外処理、移行条件を整理します。そのうえで、パッケージ・共同利用型、専用クラウド、スクラッチ、段階発注を比較し、標準化する中核と自社独自の拡張を切り分けます。

RFPには、対象業務と対象外、ファンド数・資産クラス・連携先、NAVと評価の期待結果、データ移行、性能、RTO・RPO、権限、監査ログ、SLA、DR、法改正、再委託、データ所有権、ソースコードと設定の引渡し、保守範囲を記載します。見積は3社以上から取得し、初期費用だけでなく、テスト、並行稼働、利用料、データ料、制度対応、追加ファンドを含む5年TCOで比較してください。

委託先を選ぶ前に、代表ファンドの正常系・異常系データ、現在の帳票、照合ルール、日次締めの手順を集め、構想整理やPoCで検証できる状態にします。投信実務の経験、計算結果の検証力、障害・制度改正への対応、データと責任の境界を確認できれば、価格だけでは見抜けない発注リスクを減らせます。投資信託管理システムは、業務を理解して要件を言語化するところから外注の成否が決まります。

▼全体ガイドの記事
・投資信託管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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