遺言信託管理システムの発注は、業務範囲の整理、方式の選定、RFPの作成、見積もりの比較、契約と開発の順に進めると、長期の案件を安全に引き継げます。
遺言信託は申込から相続発生まで数年から数十年空くこともあるため、担当者が替わっても追える形で進める必要があります。
▼全体ガイドの記事
・遺言信託管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
遺言信託管理システムの発注で最初に整理する全体像
発注する側は、発注の前に対象業務、使うデータと証憑、担当者と時期を決めておく必要があります。遺言信託は申込から相続発生まで数年から数十年空くこともあり、長く続く案件では、この時点の決め方が後の引き継ぎに響きます。
短期の案件管理だけを想定して作ると、担当者の交代や死亡連絡後の緊急処理で情報が足りなくなります。そこで、画面の一覧より先に、業務範囲と期間を整理しておきます。
遺言信託と遺言代用信託の切り分け
同じ信託でも、遺言信託と遺言代用信託では、システムが管理する業務とデータが異なります。
- 遺言信託：遺言書作成支援・保管、定期照会、執行、財産調査、通知・払出し
- 遺言代用信託：契約属性、受益者、払出し、決算、信託勘定総勘定元帳、当局報告。会計・商品管理との連携も重要
BIPROGYのTrustPORTの公式情報でも、個人信託システムは遺言代用信託の契約管理や相続時の払出しに対応すると紹介されています。決算関連の帳票や、税務署・当局宛ての報告も対象に含まれます。
発注者は、遺言執行業務の管理が必要か、信託商品・会計を含む基盤が必要かを切り分け、その結果をRFPの冒頭に明記します。
案件の流れと管理データ
案件の流れは、受託前の相談から受託・遺言書作成、定期照会へと進み、死亡連絡・相続開始、財産調査・執行準備、払出し・完了を経て、保管・監査へ続きます。
各工程の情報は、次のように案件に結び付けて管理します。
- 関係者：顧客、委託者、受託者、受益者、相続人、家族関係図
- 財産：不動産、預貯金、有価証券、債務などの台帳
- 手続き：遺言書・証憑の版、担当者、期限、承認履歴
この整理がないまま顧客管理画面を発注すると、原本確認や相続人の追加などの例外が、後から一つずつ加わっていきます。
システム化の目的は、長期案件の状態と期限を担当者の記憶から切り離すことにあります。書類を保管するだけでは、この目的は果たせません。
発注形態の選び方とパッケージ・クラウド・スクラッチの違い
方式は、標準業務を受け入れられるかと、基幹連携や法改正・監査を誰が担うかで決まります。機能の数も判断材料になりますが、判断の中心はこの二点です。
方式には既製サービス、信託・金融向けパッケージ、独自開発の三つがあり、これらを組み合わせる場合もあります。
標準化できる範囲が広い場合のパッケージ・クラウド型
パッケージやクラウドは、顧客、契約、案件、文書、承認などの共通機能を早く使い始めやすい方式です。サーバーの構築、バックアップ、監視、脆弱性対応の一部は、サービス側に任せられます。
初期投資と運用負担を平準化しやすいため、申込受付、書類、タスク、期日、承認に対象を絞る場合に有力です。
ただし、金融機関の要件に自動的に合うとは限りません。次の事項は、契約と設計の両面で確かめておきます。
- データ管理：保管場所、暗号化、管理者権限、操作ログ
- 委託・継続性：再委託先、障害復旧、サービス終了時の返却
- 接続と適合：閉域接続、標準機能とアドオンの範囲
業務を標準機能に合わせて変えられる範囲と、追加開発が必要な範囲は、Fit＆Gapで記録しておきます。
独自商品・複雑な連携を重視する場合の個別開発
スクラッチ開発なら、独自の遺言執行や複雑な財産配分に合わせて設計できます。勘定系や顧客管理、文書管理との連携、組織固有の職務分掌にも対応できます。
入力を減らしたうえで、独自のサービスで差別化できます。一方で、要件定義やテストから、法改正や脆弱性対応、開発会社の交代まで、発注者が管理する範囲も広がります。
認証、文書保管、監視、バックアップ、帳票エンジンまでは、ゼロから作る必要はありません。たとえば、信託会計や契約管理はパッケージで利用し、受付、案件管理、照会、分析をAPIで追加する方法もあります。
5年TCOによる発注形態の比較
初期費用だけで比べると、後の負担を見落とします。そこで、5年間の総保有コスト（TCO）で比べます。費用項目には、初期導入、月額利用料、追加ライセンス、インフラ、保守が入ります。
そのほか、制度改正、脆弱性診断、移行、教育、監査、障害復旧も含まれます。パッケージのアドオンが多いと、更新のたびに回帰テストが必要になるため、クラウドの月額費用より高くなる場合があります。
こうした費用まで含めたうえで、自社で担う業務を安定して運用できる方式を選びます。法務・税務・信託実務のルールを更新する体制が弱い場合は、制度対応と保守を含むサービスが候補になります。一方で、独自の顧客体験や執行手順が競争力になるなら、その部分に開発費を集中させます。
RFPと要件整理の進め方
RFPは、開発会社への要望書であると同時に、発注者が対象範囲を決めるための資料でもあります。
業務目的、対象商品、利用者、データ、連携の順に整理します。次に、セキュリティ、移行、保守、検収を整理すると、提案を同じ条件で比べやすくなります。
現行業務の洗い出しと利用者・データ項目
現行業務は、担当者への聞き取りと業務フローから洗い出します。そのほか、帳票、Excel台帳、規程、契約書、メール運用も材料になります。
工程は時系列に並べ、開始と完了の条件、責任者、期限、必要書類を記録しておきます。
- 前半：受託前の相談、本人確認、遺言書作成支援、受託審査
- 後半：定期照会、死亡連絡、相続人確認、財産調査、執行、払出し、完了報告
データには、顧客の属性や家族関係、相続人の続柄を含めます。財産については、種類、名義、評価日、残高を押さえます。さらに、遺言書の版と原本の保管場所、照会結果、承認履歴、死亡診断書などの証憑も含めます。
入力必須の項目、更新権限、保存期間、訂正の方法、削除・廃棄の条件も決めておきます。そうすると、画面設計と個人情報保護の議論を並行して進められます。
RFPに書く機能・連携・セキュリティ
RFPには、機能要件と非機能要件を分けて書きます。
- 業務機能：顧客・関係者、相続人関係図、財産台帳、遺言書・徴求書類の版管理
- 手続き機能：期日アラート、定期照会、稟議・承認、執行タスク
- 記録機能：帳票、検索、操作ログ
- 非機能要件：利用者数、同時接続、可用性、バックアップ、RTO・RPO、応答時間
- 運用・安全：監視、ログ保存、脆弱性診断、障害通知、データ返却、再委託管理
金融機関では、FISCの安全対策基準・解説書第13版が2025年3月に公表されています。また、金融庁のサイバーセキュリティガイドラインは2024年10月に公表され、2025年7月に一部改正されました（出典：FISC、金融庁、2025年・2024年）。
基準は、そのまま転記するより、自社の業態や重要度、委託先管理の方針に応じて、認証、権限、暗号化、監視、インシデント報告の要件へ落とし込むほうが実務に合います。
試作品・移行範囲・受入条件
代表的な案件の試作品と移行条件を事前に確かめておくと、要件と受入基準がそろいます。
- 試作品：申込、定期照会、死亡連絡、執行準備を通した動作
- 例外処理：状態変更、書類の版、差戻し、承認者不在、相続人追加、財産更新の扱い
- 移行範囲：全案件、進行中案件のみ、原本情報のみから選ぶ範囲と、紙画像の保管先
- 受入条件：項目対応、名寄せ、欠損値の扱い、リハーサル、並行稼働、内容の正確さの検収
業務、情報システム、コンプライアンスの各部門が、同じ画面とシナリオで合意しておく必要があります。移行範囲や紙画像の保管方法は、費用とリスクの両方に影響します。
契約形態と開発プロセスの組み合わせ
要件が固まらないまま全工程を一括請負にすると、変更の扱いをめぐって発注者と開発会社が対立しやすくなります。そこで、工程ごとに成果物と責任を整理します。工程は、企画・要件定義から運用保守まで区切って進めます。
契約は、対象業務の不確実性と、発注者が意思決定できる体制を踏まえて選びます。
請負・準委任・SaaS利用の使い分け
成果物が明確かどうか、継続的な検討が必要かどうかに応じて、契約形態を選びます。
- 請負：成果物の完成と検収を重視し、要件と納期が明確な開発や移行に向く
- 準委任：要件定義、PMO、業務整理、Fit＆Gap、移行支援などの作業や助言が対象
- SaaS・ASP：利用料、サポート、SLA、データ返却、解約時の移行支援を、利用規約と個別契約で取り決める
請負では、完成の定義や性能、障害、瑕疵対応、再検収を契約で決めておきます。要件の変更が大きい場合は、変更契約や追加の見積もりが必要になります。
準委任では、作業範囲や稼働時間、会議体、報告物、意思決定の期限を定めます。特に、発注者側の責任者が判断を止めないことが重要です。
要件定義から段階リリースまでの進め方
企画・現状分析から運用保守まで、工程ごとに合意を取りながら進めます。
- 企画・現状分析、要件定義
- 基本設計、詳細設計・開発
- テスト、移行、教育、リリース、運用保守
初回は、顧客、案件、書類、期限、承認、検索などの共通基盤を対象にできます。一方で、財産シミュレーションや高度な執行自動化は、第二段階に分けるのが現実的です。
後から追加する業務のデータモデルと権限は、初期段階で考えておく必要があります。テストには、通常の申込に加えて例外業務も含めます。
- 案件・書類：相続人変更、財産追加・評価更新、差戻し、担当者異動
- 期限・連絡：照会未回答、死亡連絡の重複、休日期限、緊急払出し
- 連携：外部システムとの連携失敗
発生頻度の低い業務ほど、本番で初めて問題が見つかりやすくなります。そのため、匿名化した過去の案件でリハーサルを行い、受入テストは現場の担当者が担います。
契約に盛り込む変更管理と業務側の体制
発注者側の体制と契約上の管理項目は、あらかじめ決めておきます。
- 担当体制：業務プロダクトオーナー、情報システム、コンプライアンス・法務、現場キーユーザー
- 意思決定：週次課題管理、月次決定、変更の優先順位付け、議事録・要件台帳の記録
- 変更管理：法改正・商品追加の受付、影響分析、見積、承認、リリース、証跡保管
- 保守契約：問い合わせ、障害、事故、制度改正、軽微な帳票変更の応答・復旧・費用
業務の判断を開発会社に任せると、規程や権限、例外処理、帳票の根拠が決まらないまま、画面だけが完成する恐れがあります。
遺言信託管理システムの費用相場と見積の内訳
公開されている価格は限られるため、費用は概算で考えます。その前提には、業務範囲、利用者数、既存連携があります。さらに、移行件数や保守体制も前提に入ります。監査・BCP水準も、前提の一つです。
SIA株式会社が2026年7月に公開した相場では、小規模システムは100万〜300万円、中規模は500万〜1,000万円です。大規模システムは1,000万円〜数千万円以上が目安で、人月単価は60万〜200万円程度です（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。
金融・信託案件は、一般的な業務システムに比べて、要件定義、テスト、監査、長期保守の比重が大きくなります。
予算の起点となる方式別の費用目安
方式と対象範囲によって、初期費用の目安は大きく変わります。
- クラウド：初期50万〜300万円、月額10万〜100万円。案件・文書・タスク中心で、信託会計や厳格な閉域接続は含まない想定
- パッケージ：導入、設定、帳票、連携を含め1,000万〜5,000万円程度
- 個別開発：中規模は3,000万〜1億円程度
- 大規模刷新：複数拠点、勘定系、本人確認、文書・会計、BCP、移行を含み、1億円超から数億円以上
金額は、研究ノートの一般的な相場と業務範囲から推定したもので、公開された定価ではありません。案件数や利用者数、連携数によって変わるほか、紙資料やデータ品質、監査証跡、復旧目標も影響します。そのため、RFPを示して再見積もりを依頼します。
要件定義・開発・テスト・移行の工程別内訳
見積書は工程ごとに分けて、作業と予算配分の前提を確かめます。
- 要件定義：10〜20%
- 設計・開発：40〜50%
- テスト：15〜25%
- PM・監査資料：10〜15%
- インフラ・移行：10〜25%
この配分は比較のための仮説です。実際の見積では、連携や帳票、テスト、診断の人月を確かめます。移行や教育、リリース、保守については、成果物と前提を見ます。
見落としやすい項目は、移行リハーサル、紙書類のスキャン・紐付け、並行稼働です。加えて、教育、受入支援、監査資料、脆弱性診断、法改正対応も、見積に入っているかを確かめます。
「別途」とされた作業は、件数や単価、発生条件を確認しておくと、価格差の理由を説明しやすくなります。
5年TCOと費用対効果による見積の読み方
初期費用を並べて比べるだけでなく、5年TCOと改善効果を見ます。TCOには、初期開発、月額・年額の利用料、保守、クラウド、ライセンスの費用が含まれます。
そのほか、監視やバックアップ、法改正、追加帳票の費用も含めます。また、教育、移行、終了時の返却も対象です。効果は、書類の検索時間や期限超過、二重入力、担当者交代時の引き継ぎ時間で見ます。
照合や監査資料の作成時間、事故・再作業の減少も、見る項目になります。監査ログや移行を含む高額な提案は、導入後の手戻りを抑えられる可能性があります。ただし、初期費用が低くても、定期照会を人手で管理し続けると、稼働と期限漏れのリスクは残るため、金額とあわせて、どの業務リスクをどこまで減らす見積なのかを提案書とデモで確かめます。
委託先選定と見積比較で確認すべきポイント
委託先は、知名度や安さだけでは判断しきれません。遺言信託や遺言代用信託、遺産整理の実績を確かめます。信託会計の実績と担当者の業務理解も見ておきます。導入後は、法改正・保守・障害対応まで確かめます。
標準機能、設定、アドオン、発注者側の業務変更を分けて説明できる会社であれば、費用と責任範囲を把握しやすくなります。
信託・相続実務と類似案件の実績
「金融向け」の実績があるかだけでなく、信託・相続の対象業務と機能の対応範囲を見ます。
- 業務範囲：文書、相続人関係図、財産台帳、照会、死亡連絡、払出し
- 連携・会計：信託会計、当局報告、勘定系連携
- 実装区分：標準機能と個別開発の境界
- 確認資料：匿名化画面、業務フロー、導入後の保守体制
公開情報では、オービックが遺言信託・遺産整理の支援として、家族・財産情報や台帳、相続人関係図を案内しています。定期照会や執行の稟議決裁も、あわせて案内されています。
BIPROGYのTrustPORTは、信託会計と事務管理を連動させ、遺言代用信託などを支援します。
NTTデータグループは2026年4月8日、金融業界横断の相続手続き一元化プラットフォーム「みらいたすく」の構築に向けた基本合意を公表しました。銀行・信託・証券をまたぐ標準化の動きではありますが、自社業務への適合を示すものではありません（出典：NTTデータグループ、2026年）。
提案の時点で、対象商品の類似性と導入後の責任分界を確かめておきます。
同じ評価軸による提案書と見積書の比較
各社には、同じRFP、代表案件、データ件数、連携の前提を渡します。評価軸をそろえると、提案の違いが見えてきます。
- 適合性：業務、標準機能、拡張性、操作性
- 運用性：セキュリティ、移行、テスト、保守、体制
- 契約条件：費用・納期、前提・除外、追加費用、成果物、検収
デモでは、案件の差戻しや相続人の追加、財産評価の更新を実演してもらいます。照会未回答や承認者不在、誤入力の訂正、操作ログも、あわせて見せてもらいます。
担当が交代しても判断の根拠を追えるかを確かめます。実務の例外を再現できるかで、見積の信頼性と導入後の定着が左右されます。
契約で定める委託先管理・再委託・データ返却
遺言書や家族関係、財産情報、本人確認書類は、漏えいした場合の影響が大きい情報です。そのため、個人情報保護委員会の金融分野向けガイドラインを踏まえて、管理項目を契約と規程に定めておきます。
- 利用管理：アクセス権限、目的外利用の禁止、委託先監督
- 委託管理：再委託承認、事故報告、保存期間
- 終了時：返却・消去とその証明
開発、検証、本番の各環境でデータを分け、実データの持ち出しを抑えます。そのうえで、個別アカウント、特権操作の承認、ログ改ざん防止、脆弱性対応の期限、事故時の連絡先も決めておきます。
契約終了時に標準形式で返却でき、バックアップを含めて消去できるかも、選定の際に質問します。出典は個人情報保護委員会「金融分野における個人情報保護に関するガイドライン」です。
よくある質問
発注範囲、方式、費用、開発会社の選び方について、発注前によくある疑問に答えます。
遺言信託管理システムの開発費用はいくらですか？
クラウドの初期導入は50万〜300万円、パッケージの導入・設定・連携は1,000万〜5,000万円程度が目安です。
中規模の個別開発は3,000万〜1億円、大規模な基幹連携型は1億円超が目安です。
公開された専用の価格ではなく、業務範囲からの推定です。利用者数や案件数、移行、監査、法改正、保守を含めた5年TCOで比べます。
パッケージとスクラッチ開発はどちらがよいですか？
標準的な案件や書類、承認、信託会計を早く整えたい場合は、パッケージやクラウドが候補になります。一方で、独自商品や複雑な連携を競争力にしたい場合は、スクラッチを検討します。
標準的な中核機能はパッケージで使い、受付や照会、分析を個別開発するハイブリッド型もあります。その場合は、Fit＆Gapと5年TCOでアドオンの増え方まで確かめます。
RFPには何を書けばよいですか？
RFPには、業務目的や対象商品、現行フロー、利用者と権限を書きます。顧客や相続人、財産、書類、期限といった項目のほか、帳票や連携、セキュリティも記載します。可用性、移行、教育、保守、検収条件も、あわせて書いておきます。
標準機能、設定、アドオン、業務変更のどれで対応するかに加え、見積に含む作業と除外する作業も明記します。代表的な例外シナリオを添えると比較しやすくなります。
委託先を選ぶときに最も重視すべきことは何ですか？
信託・相続の実務と開発の両方を理解し、導入後まで責任範囲を説明できることです。遺言信託と遺言代用信託の扱いを確かめます。長期照会と執行の進め方も、提案やデモで見ておきます。証憑・監査ログの扱いも確かめます。法改正と移行への対応も見ておきます。
価格差の理由や再委託、障害対応、データ返却についても質問し、複数社を同じ評価軸で比べます。
まとめ
まず、遺言信託と遺言代用信託の対象範囲を分け、申込から定期照会、相続発生後の執行、払出し、保管・監査までを整理します。
方式は、パッケージ、クラウド、スクラッチ、ハイブリッドを、機能の適合性と5年TCOで比べます。
発注前のRFPと評価表の準備
RFPには、業務フロー、データ、権限、連携、セキュリティを記載します。そのほか、移行、テスト、保守、検収条件も書きます。見積では、制度対応や脆弱性、教育、監査、運用、返却を含む5年TCOを見ます。
開発会社には、標準機能、設定、アドオン、業務変更の境界を説明してもらいます。そのうえで、同じ代表案件と例外シナリオを使って提案を比べます。
業務部門と情報システム部門の最初の一歩
全機能を一度に作らず、担当交代や照会期限の漏れ、書類の所在不明、相続後の引き継ぎ不足など、現在のリスクに優先順位を付けます。
業務責任者を置き、現行資料と代表案件をそろえたうえで、複数社に同じ条件で相談します。そして、長期案件を安全に引き継ぎ、正確に執行できる業務基盤として設計します。
▼全体ガイドの記事
・遺言信託管理システム開発の完全ガイド
▼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を創業。