投資信託管理システムの発注は、どこまでを誰が受け持つかを整理することから始まります。まず発注形態を決め、次にRFPと要件を整理し、契約と費用を見積もり、最後に委託先を選びます。
RFPとサンプル計算を用意して方式と委託先を比べると、計理の精度と日次運用の安定につながります。
▼全体ガイドの記事
・投資信託管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
投資信託管理システムの発注・外注で最初に整理する全体像
発注前には、信託財産のどの業務を、どの会社が責任を持って、いつまでに終えるのかを決めておきます。画面数や機能名だけで範囲を決めると、計理や照合がExcelのまま残ることがあるため、業務の中身から範囲を考えます。
基幹全体を一度に刷新すると、費用と移行リスクが膨らみます。そこで、対象業務と責任者を先に決め、段階的に進める範囲を検討します。
投資信託管理システムの役割：計理・資産管理の基盤
管理するデータと業務を一覧にすると、このシステムが担う役割がはっきりします。
- マスタ：ファンド、銘柄、口座、受益者、運用会社
- 外部データ：市場価格、為替、格付、銘柄属性
- 計理業務：注文・約定・決済、残高、簿価、損益、時価評価、利息・配当、未払費用
- 締め処理：信託報酬、分配金、決算、仕訳、帳票。訂正・再計算の履歴とNAV根拠も追跡できるようにします
2026年4月時点のNRI公式情報では、T-STAR/TXが信託財産のNAV計算や運用会社に代わる計算業務を支援すると説明されています（出典：野村総合研究所「T-STAR/TX」、2026年4月時点）。
委託先には、投信計理と受託業務の責任を理解していることが求められます。
発注対象と対象外、正本データの責任境界
ファンド業務のどこまでを対象とし、価格やNAVの訂正を誰が担うかを決めておきます。
- 対象範囲：対象業務と対象外を切り分け、どこまでを新システムで担うかを示します。
- 追加開発：コア計理を共同利用型に任せる場合は、独自の分析画面や社内ワークフローの範囲を決めたうえで、標準機能に合わせる部分を合意しておきます。
- 正本と訂正：市場価格、残高、約定、NAV、仕訳の正本の所在を定め、不一致や連携の遅れが起きたときの判定者と訂正者を決めます。
- 計算責任：業務を知る発注者も仕様どおりに作ったベンダーも計算結果に責任を負わない状態を避けるため、責任の所在をはっきりさせます。
まず、ファンドマスタ、日次評価、NAV計算をどこまで対象にするかを決めます。そのうえで、帳票や販売会社との連携、データ移行まで広げるかを判断します。
フロントの運用管理や顧客ポータルのほか、DWHや会計システムまで含めるかも決めます。含めないものは、対象外として明記します。
投資信託管理システムの発注形態の選び方
発注形態は4つの型で比べます。パッケージ・共同利用型と専用クラウド、スクラッチ開発、段階発注です。
標準業務を早く安定させたいならサービス型が候補になります。一方で、独自計算や深い統合が競争力になるなら、個別開発型が候補です。
判断材料が足りないときは、構想やPoCを先に進めます。そのうえで、業務要件と運用責任を確かめ、方式を選びます。
パッケージ・共同利用型：標準業務を早く安定させる方式
標準機能で賄える範囲と、例外処理で追加対応が要る範囲は、機能ごとに分けて確かめます。
- 標準機能：評価、NAV、帳票、権限、監査ログ、日次運用
- 例外処理：価格欠損、外国資産、締め後訂正、再計算
- 対応方法：標準、設定、追加開発、業務変更の区分
標準サービスを使うと、計算ロジックや制度対応を自社で持つ範囲を減らせます。さらに、インフラや運用監視を委託でき、バックアップや代替サイトも任せられます。新規参入やファンド数の少ない会社では、初期投資と専門人材の固定化を抑えられます。
独自の信託報酬計算や特殊資産を追加すると、アドオン費用と更新検証が増えます。社内承認や帳票様式を加える場合も、アドオン費用と更新検証が増えます。そこで、Fit & Gap表には、サンプルデータで確認した対応区分を記録します。
専用クラウド・ハイブリッド型：連携と拡張を両立する方式
連携の方法と運用の条件を踏まえて、構成を検討します。
- 接続先：会計、DWH、販売会社、資産管理銀行、カストディアンとは、APIやファイルで連携します
- クラウド運用：専用データの分離と権限設計で拡張性を確保し、機器の更改や監視の負担を抑えます
- 契約確認：クラウド審査、暗号鍵、バックアップ、ログ、データ所在地、復旧、再委託先
- ハイブリッド：コア計理はサービスに寄せ、独自ワークフロー、分析、DWH、AI活用はAPIで加えます
2026年1月公表のT-STAR/GV新機能は、発注・約定システムや銀行と連携するほか、カストディアンの残高やSWIFTとも結びつきます。さらに、IBORデータとの照合・補正を自動化し、APIを提供する方向です（出典：野村総合研究所「T-STAR/GV」新機能、2026年1月）。発注時は、データ鮮度と照合の仕組みも評価します。
構想・PoC・本開発を分ける段階発注
一括で発注する前に、現状の把握と計算の検証を順に進めます。
- 現行業務、ファンド数、資産クラス、外部接続、データ品質を一覧にする
- 計算ケースを整理し、サンプルデータでPoCを行う
- 移行方針と概算WBSをまとめ、RFPと本契約に利用する
移行やテストが初期提案に含まれない場合も、この成果物があれば差分を洗い出せます。特に、ファンド数や接続、既存データの品質が不明なまま本開発を一括で発注するのは危険です。
PoCの合否は、画面が表示されるかではなく、計算結果で決めます。代表ファンドのNAVと残高が一致するか、価格欠損や休日を説明できるかを見ます。差異の検知と再処理、障害時の切り戻しも合格条件に含めます。
著作権と設定値、ソースコードの扱いを契約に記載します。テストデータや次工程での利用権も、あわせて書いておきます。
RFP・要件整理での投信計理と非機能要件の数値化
RFPは、複数社から同じ前提で提案を受けるための文書です。そのため、目的、範囲、業務、計算、連携の前提をそろえます。移行、セキュリティ、運用、契約、見積条件も、同じ条件で示します。
仕様をすべて完成させる必要はありません。ベンダーに判断してほしい論点と、発注者が決める論点は分けて記載します。
RFP冒頭で共有する目的・対象範囲・現行業務
RFPの冒頭では、新システムで実現したい改善を目的として示し、対象にする業務の広がりを書き出します。
- 改善目標：日次締め、照合、ファンド追加、制度改正への対応
- 業務範囲：設定、注文、約定、残高、評価、NAV、分配、決算
- 周辺業務：帳票、会計、訂正、監査、運用監視
現状のファンド数・資産クラス・通貨・1日あたりの取引量を記載します。価格の取得時刻や締め時間、帳票数も含め、利用者数や接続数も書き添えます。加えて、Excel補正や担当者判断による例外、月末・決算日の処理も入れます。
新システムの対象外を明確にすると、各社の見積範囲がそろいやすくなります。
NAV・評価・費用計算の例示データと期待結果
計算の条件は、文章だけでは解釈がずれやすいため、入力値と期待結果の組で確かめます。価格の扱いから費用の計算、例外の処理まで、条件を一つずつ書き出します。
- 価格・為替：基準日、採用順位、為替レート、評価不能時の扱い
- 収益・費用：未収利息、配当、信託報酬、監査費用、税金
- 例外条件：端数処理、休日、償還、分配、異常系
基準価額は1円の差でも、販売会社との連携や開示に影響します。そのため、正常系だけでなく、外国証券の時差や現地休日、為替の扱いも例示します。未収利息や約定日と受渡日のずれも、例示の対象に含めます。
株式分割・併合、合併、配当、償還などのコーポレートアクションも対象に含めます。
訂正や再計算の履歴と使用データを追跡できることを、受入条件にします。承認者と再実行処理についても、追跡できることを求めます。
性能・可用性・セキュリティ・移行の数値目標
非機能要件は、数値と確認方法を組にして示します。日次締めや障害対応に直結する性能、復旧、切替の項目を、ここで決めておきます。
- 性能：バッチ完了時刻、処理件数、応答時間、同時利用者数
- 復旧：稼働率、検知と回復にかかる時間、RTO、RPO、保管期間
- 切替：代替処理、切り戻し条件、翌日業務への影響
金融機関向けには、権限分離と承認、操作ログ、訂正履歴を定めます。さらに、暗号化や脆弱性への対応、監査の方法も決めます。委託先・再委託の管理と災害復旧も、あわせて定めます。
2025年5月の金融庁・FISC意見交換会では、基準改訂やサイバーセキュリティ、ITガバナンスとシステムリスク管理が議論されました（出典：金融庁「金融庁・FISCの意見交換会について」、2025年5月）。そこで、「FISC準拠」とするだけでなく、対象基準、確認方法、証跡の提出者を具体化します。
移行対象は、ファンドや銘柄、残高、簿価です。さらに、評価額や収益、費用も含みます。履歴と帳票も、移行の対象です。
移行の前後で、件数や残高、評価額を突合します。NAVや仕訳、帳票も突合の対象です。最後に、許容差と未解決の差異をどう扱うかを定めます。
切替の前には、複数回のリハーサルと新旧並行計算を行います。稼働の判定、切り戻しの期限、業務継続の手順も、発注条件に含めます。
投資信託管理システムの契約形態と責任分界の決め方
工程ごとに確定できる範囲が違うため、請負だけで契約すれば安心とは限りません。準委任と請負を基本にし、サービス利用や保守を組み合わせて、成果物と責任の境界を定めます。
準委任契約の向く工程：要件整理・PoC・PMO
業務の洗い出しや方式の比較のように、発注者とベンダーが一緒に調べて検討を重ねる工程には、準委任が向いています。
- 現状把握：業務の洗い出しとRFP作成支援
- 方式検討：Fit & Gap、PoC、移行方針
- 推進支援：プロジェクト管理と課題整理
作業範囲と体制、定例報告を明記します。成果物や検収、追加作業の承認手順も、契約に書いておきます。一方で、発注者には業務ルールや例外処理を提示する責任が残ります。
業務一覧や課題、リスクを成果物として残します。決定・未決事項と次工程の判断材料も含めます。その中身とレビュー基準は、契約や個別発注書に記載します。
請負契約：完成範囲・受入条件・変更管理の固定
請負は、合意した成果物を完成させて検収する工程に適しています。そこで、納品物と受入基準をそろえます。
- 成果物：画面、API、バッチ、帳票、移行、テスト証跡
- 受入基準：件数、エラー時の動作、性能、セキュリティ、許容差
- 引渡し：操作マニュアル、設定、ソースコード
「システム一式」では完成を判断できません。制度改正や商品追加、価格データや接続先の変更に備えて、変更要求から追加テストまでの手続きを定めます。
発注者が設定を変えられる範囲と、第三者保守へ切り替える条件も決めておきます。特に、ソースコードと設定ファイルの引渡しは、将来のロックインに関わります。
SaaS・共同利用型のSLAとデータ責任
サービス利用契約では、業務の停止を防ぐために、どこまでを誰が受け持つかを決めます。確認すべき条件は、次のとおり整理します。
- 稼働条件：提供時間、重大度、一次応答、復旧目標、計画停止
- データ管理：バックアップ、返却、ログ、脆弱性、法改正
- 委託管理：窓口、再委託先、監査資料、障害時の調査と訂正
NAVや帳票に誤りがあった場合、調査と訂正を誰が担うかを定めます。候補は、発注者と提供者、価格データ会社、信託銀行です。
監督指針やFISC基準は、権限やログ、復旧といった統制に分けて確かめます。委託先評価や事故報告も、この統制の一部として扱います。
契約前に、法務と情報セキュリティ、監査、業務部門が確認しておくと、稼働後の追加条件を抑えられます。
投資信託管理システムの費用相場と5年TCOの考え方
費用は、ファンド数や資産クラス、接続数、データ品質で変わります。さらに、計算ルールや帳票、移行が費用を左右します。並行稼働やSLA、DRも費用に影響します。
ここでの金額は、公開価格ではなく、一般相場と投信業務の工数を基にした発注前の推定です。
規模別の初期費用と開発期間の目安
開発規模別の推定レンジは、次のとおりです。前提をそろえたうえで、見積もりを比べてください。
- 周辺開発：500万円から3,000万円程度、3か月から6か月程度
- サービス導入：3,000万円から1億5,000万円程度、6か月から12か月程度
- 基幹刷新：1億5,000万円から5億円程度、12か月から24か月程度
- 大規模フルスクラッチ：5億円から20億円以上、18か月から36か月以上
周辺開発は、帳票やEUC、ファンドマスタの整備を想定します。データ整備や限定連携も含みます。サービス導入は、設定や連携、移行に加えて、教育と受入試験も含みます。
基幹刷新は、NAVや計理、外国資産、企業行動を含む想定です。さらに、複数接続や並行稼働、DRも範囲に入ります。フルスクラッチは、独自計算や複数会社、大量ファンドがあると、期間が長くなる可能性があります。
小規模の相場は100万円から300万円です（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。同じ出典では、中規模が500万円から1,000万円、大規模が1,000万円から数千万円以上です。
人月単価は60万円から200万円程度で、いずれも投信専用の価格ではありません。金融系では、専門テストや移行、監査資料、制度対応も加わります。そのため、一般相場の下限だけで予算を決めないようにします。
要件定義から保守までの工程別見積もり
見積もりは工程ごとに分けて確認します。たたき台として、次の比率を示します。
- 要件定義：10〜20％
- 設計・実装：40〜50％
- テスト：15〜25％
- PM・品質管理：10〜15％
- 基盤・移行・教育：5〜20％
この配分は、統計的な固定比率ではなく、抜け漏れを確かめるための目安です。見積もりは、要件定義や設計、実装から保守まで細かく分けて書き出します。
投信案件では、過去日付や日次・月次・決算、欠損値、異常データの試験が必要です。訂正や再計算、照合の試験も含みます。権限や復旧、新旧並行計算も対象です。
見積にない項目は、別費用になるのか対象外なのかを確認します。
初期費用ではなく5年TCOと増設単価での比較
5年の総費用で比べると、初期費用だけでは見えない利用や運用、変更の負担も分かります。
- 利用費：サービス、ライセンス、クラウド、回線、価格・為替データ
- 運用費：監視、バックアップ、障害、監査、教育
- 変更費：法改正、更新、追加ファンド、追加接続
安価なパッケージでも、アドオンやファンド追加、帳票変更、制度改正で費用がかさみ、5年後にはスクラッチを上回ることがあります。そのため、増設単価も比較表に入れておきます。
ファンドや資産クラス、接続先の追加単価を確認します。テスト環境や休日・夜間対応、制度改正の範囲も確かめます。データ料や、銀行・カストディアンとの接続料が別契約かどうかも確かめます。
同じ条件で5年分を並べると、単年度予算では見えない保守負担と拡張性を比べられます。
委託先の選定と見積比較で確認すべきポイント
知名度や価格だけで委託先を決めず、投信実務と運用の経験を確かめます。専用サービス会社と汎用SI・コンサルでは得意分野が異なるため、評価の観点を分けて見ます。
投信実務の経験と計算結果の検証力
実績は、どの業務範囲をどの方法で計算検証してきたかで確かめます。確認の軸は、業務実績、接続・帳票、稼働後対応の3つです。
- 業務実績：NAV、報酬、未収・未払、分配、決算、外国資産
- 接続・帳票：残高照合、法定帳票、社内帳票
- 稼働後対応：保守年数、障害、制度改正への対応
導入件数だけでなく、ファンド数や資産クラス、接続、担当業務、保守年数も聞きます。顧客名を出せない場合は、匿名化した業務範囲や成果物の例を確認します。
デモでは発注者のデータを使い、価格取込から評価、NAV、帳票までを確かめます。照合や承認、訂正、再計算まで続けて見ます。
計算根拠や異常検知、二重計上防止、説明可能なログも評価します。特に、締め処理と例外対応を説明できない場合は、慎重に見極めます。
見積書の前提・除外・単価・変更条件の横並び
同じRFPを3社以上に渡し、比較の項目は発注者側で決めます。見積の範囲は、次の観点でそろえます。
- 開発工程：要件定義、ライセンス・利用料、設定、追加開発、連携、データ移行、テスト
- 稼働後：教育、稼働支援、保守、基盤、監視、DR
- 追加条件：制度改正、ファンド・接続追加、消費税の扱い
各社には「含む」「別途」「対象外」「未確定」のいずれかを記載してもらいます。そうすると、価格だけの比較を避けやすくなります。
安価な提案は、要件定義やPMが少なかったり、移行データの整備を発注者に任せていたり、並行稼働やテストが限られていたりする場合があります。保守や制度改正が別契約かどうかも確認します。
高額な提案では、監査証跡や代替サイト、24時間対応、専門テスト、移行支援の有無を見ます。差額の理由が明確な見積なら、追加請求や認識違いを抑えられます。
障害・制度改正・ベンダーロックインのリスク評価
障害は、検知から復旧、報告までの流れを決めておくかどうかで対応が変わります。価格データの遅れやNAVの不一致など、締めに響く場面ごとに、担当と手順を確かめておきます。
- 入力遅延：価格データや外部連携が遅れた場合
- 計算差異：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から始めると、判断しやすくなります。
投資信託の実績がないSI会社にも発注できますか？
発注は可能です。ただし、コア計理やNAVを任せるなら、投信業務の専門会社と組めるかを確認します。確かめる項目は、投信計理の有識者がいるかどうか、価格データや受託銀行との連携経験があるかどうかです。
金融水準のテストや監査、障害対応を担う再委託先やパートナーも、明示してもらいます。評価材料になるのは、サンプル計算と根拠、異常時の復旧の説明です。
まとめ｜RFPと責任分界から始める投資信託管理システムの外注
発注前には、業務フローや計算ルール、締め処理を整理します。正本データや例外、移行条件も、あわせて押さえておきます。次に、サービス型や専用クラウド、スクラッチ、段階発注を比べ、標準化する中核と独自拡張を分けます。
発注前にRFPへ入れる項目
RFPには、対象業務やファンド数、資産クラス、接続先を記載します。そのうえで、NAVの期待結果や移行、性能、RTO・RPOを書き込みます。権限、監査、SLA、DRも含めます。
法改正や再委託、データ所有権を決めます。ソースと設定の引渡し、保守範囲も決めます。さらに、3社以上の提案を、テストや並行稼働を含めた5年TCOで比べます。利用料やデータ料、追加ファンドも確かめます。
現行業務とサンプル計算の整理
まずは、代表ファンドの正常・異常データや帳票、照合ルール、日次締めを集めます。それらを、構想やPoCで検証できる状態にします。
経験や計算検証、障害対応、責任分界を確認すると、価格だけでは見えないリスクを減らせます。
投資信託管理システムの外注は、業務を理解し、要件を言葉にできるかどうかで成否が分かれます。
▼全体ガイドの記事
・投資信託管理システム開発の完全ガイド
▼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を創業。