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

遺言信託管理システムの発注では、申込受付から定期照会、相続発生後の遺言執行までを一つのライフサイクルとして整理し、標準機能と個別開発の境界を決めることが成功のポイントです。

「パッケージとスクラッチのどちらを選ぶべきか」「RFPには何を書けばよいか」「契約形態や費用相場はどう考えるか」と悩む金融機関・信託会社の担当者に向けて、遺言信託管理システムの発注・外注・委託方法を解説します。2026年時点の一般的な開発費用、金融分野のセキュリティ、見積比較の着眼点まで、発注前に検討したい内容をまとめています。

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

遺言信託管理システムの発注で最初に整理すべき全体像

発注前に必要なのは、画面の一覧ではなく、どの業務を、どのデータと証憑で、誰が、いつ確定させるかを明確にすることです。遺言信託は申込から相続発生まで数年から数十年空くこともあるため、短期の案件管理だけを想定すると、担当者交代や死亡連絡後の緊急処理で情報が不足します。まず対象範囲と業務の長さを定義します。

最初に、「遺言信託」と「遺言代用信託」を同じシステム要件として扱わないことが大切です。遺言信託では、遺言書の作成支援、保管、定期照会、相続発生後の遺言執行、財産調査、相続人への通知や払出しなど、長期の案件・書類・期日管理が中心になります。一方、遺言代用信託では、信託契約の属性、受益者、相続発生時の払出し、決算、信託勘定総勘定元帳、当局向け報告など、信託会計や商品管理との連携が重要になります。

BIPROGYのTrustPORT公式情報でも、個人信託システムは遺言代用信託の契約管理、相続発生時の払出し、決算関連帳票、税務署・当局宛報告に対応する構成として紹介されています。自社が必要とするのは遺言執行業務の管理なのか、信託商品・会計まで含む基盤なのかを切り分け、その結果をRFPの冒頭に明記します。

業務を「受託前」「受託・遺言書作成」「定期照会」「死亡連絡・相続開始」「財産調査・執行準備」「払出し・完了」「保管・監査」に分けると、必要なデータが見えやすくなります。顧客・委託者・受託者・受益者・相続人などの関係者、家族関係図、不動産・預貯金・有価証券・債務などの財産台帳、遺言書や証憑書類の版、担当者、期限、承認履歴を一つの案件に結び付けます。

この整理がないまま「顧客管理画面を作ってください」と発注すると、書類の原本確認、相続人の追加、財産評価の更新、定期照会の未回答、担当者の異動といった例外が後から追加されます。システム化の本質は、遺言書を保管することだけではなく、長期間続く案件の状態と期限を担当者の記憶から切り離すことです。

発注形態はどう選ぶ？パッケージ・クラウド・スクラッチの違い

発注形態は、機能の多さだけでなく、標準業務を受け入れられるか、既存基幹と連携するか、法改正や監査対応を誰が担うかで決まります。一般的には、既製サービスを導入する方法、信託・金融向けパッケージを設定・拡張する方法、独自システムをスクラッチ開発する方法の三つがあり、実務ではこれらを組み合わせるケースも多いです。

パッケージやクラウド型サービスは、顧客・契約・案件・文書・承認など、複数組織に共通する機能を早く使い始めやすい方式です。サーバー構築、バックアップ、監視、脆弱性対応の一部をサービス側に任せられるため、自社の初期投資と運用負担を平準化しやすいです。特に最初の対象業務を申込受付、書類、タスク、期日、承認に絞る場合は、有力な選択肢になります。

ただし、クラウドであれば無条件に金融機関の要件を満たすわけではありません。データの保管場所、暗号化、管理者権限、操作ログ、再委託先、障害時の復旧、サービス終了時のデータ返却、閉域接続の可否を契約と設計の両面で確認します。標準機能に合わせて業務を変えられる範囲と、アドオンが必要な範囲をFit＆Gapで記録することが重要です。

スクラッチ開発は、独自の遺言執行フロー、複雑な財産配分、既存の勘定系・顧客管理・文書管理との連携、組織固有の職務分掌などを業務に合わせて設計できる方式です。現場の入力を減らし、独自サービスを差別化したい場合には効果があります。一方で、要件定義からテスト、移行、監査資料、法改正、脆弱性対応、開発会社の交代まで、発注者側が管理する範囲は広くなります。

個別開発を選ぶ場合も、認証、文書保管、監視、バックアップ、帳票エンジンなどまでゼロから作る必要はありません。信託会計や標準的な契約管理はパッケージで利用し、独自の受付・案件管理・照会・分析だけをAPIで追加するハイブリッド型なら、自由度と保守性のバランスを取りやすくなります。

初期費用だけでなく、5年間の総保有コスト（TCO）で比較すると、方式の違いを判断しやすくなります。初期導入費、月額利用料、追加ライセンス、インフラ、保守、制度改正、脆弱性診断、データ移行、教育、監査対応、障害時の復旧を並べます。パッケージのアドオンが多い場合は、バージョンアップのたびに回帰テストが必要になり、クラウドの月額費用より高くなることもあります。

判断軸は「一番安い方式」ではなく、「自社が責任を持つべき業務を安定して運用できる方式」です。法務・税務・信託実務のルールを自社で更新する体制が弱い場合は、法制度対応や保守を含むサービスを選ぶほうが安全です。反対に、独自の顧客体験や執行手順が競争力になる場合は、その部分へ個別開発費を集中させます。

RFPと要件整理はどの順番で進めますか？

RFPは、開発会社へ要望を伝える資料であると同時に、発注者自身が対象範囲を決めるための資料です。いきなり機能一覧を書くのではなく、業務目的、対象商品、利用者、データ、連携、セキュリティ、移行、保守、検収の順に整理すると、各社の提案を同じ条件で比較しやすくなります。

最初に、現行業務を担当者へのヒアリング、業務フロー、帳票、Excel台帳、規程、契約書、メール運用から棚卸しします。受託前の相談、本人確認、遺言書の作成支援、受託審査、定期照会、死亡連絡、相続人確認、財産調査、執行、払出し、完了報告までを時系列で並べ、各工程の開始条件・完了条件・責任者・期限・必要書類を記録します。

データ項目は、顧客属性だけでなく、家族関係、相続人の続柄、財産の種類・名義・評価日・残高、遺言書の版、原本の保管場所、照会結果、承認履歴、死亡診断書などの証憑まで対象にします。入力必須項目、更新権限、保存期間、訂正方法、削除や廃棄の条件を決めると、画面設計と個人情報保護の議論を同時に進められます。

機能要件には、顧客・関係者管理、相続人関係図、財産台帳、遺言書・徴求書類の版管理、期日アラート、定期照会、稟議・承認、執行タスク、帳票、検索、操作ログを記載します。非機能要件には、利用者数、同時接続、可用性、バックアップ、RTO・RPO、応答時間、監視、ログ保存期間、脆弱性診断、障害通知、データ返却、再委託管理を記載します。

金融機関が利用する場合は、FISCの「金融機関等コンピュータシステムの安全対策基準・解説書」第13版が2025年3月に公表されていることや、金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」が2024年10月に公表され、2025年7月に一部改正されていることを踏まえます（出典：FISC、金融庁、2025年・2024年）。基準をそのまま貼り付けるのではなく、自社の業態、重要度、委託先管理方針に応じて、認証、権限、暗号化、監視、インシデント報告の要求へ落とし込みます。

要件が文章だけでは伝わりにくい場合は、代表的な案件を一つ選び、申込から定期照会、死亡連絡、執行準備までのプロトタイプを確認します。画面の見た目より、案件状態が変わる条件、書類の版、差戻し、承認者不在、相続人追加、財産更新をどう扱うかを確かめることが重要です。業務部門・情報システム部門・コンプライアンス部門が同じ画面と業務シナリオを見て合意します。

移行では、現行システムや紙台帳から何を移すかを決めます。全案件を移すのか、進行中案件だけを移すのか、原本は保管場所の情報だけを移して画像は別保管にするのかで、費用とリスクが大きく変わります。移行元・移行先の項目対応表、名寄せルール、欠損値の扱い、移行リハーサル、旧システムとの並行稼働をRFPに含め、検収条件に「件数だけでなく内容が正しいこと」を記載します。

契約形態と開発プロセスはどのように組み合わせますか？

遺言信託管理システムでは、要件が固まっていない段階で全工程を一括請負にすると、追加変更の扱いで発注者と開発会社が対立しやすくなります。企画・要件定義、設計・開発、テスト・移行、運用保守を分け、成果物と責任を契約単位で整理します。対象業務の不確実性と、発注者が意思決定できる体制を踏まえて契約を選びます。

請負契約は、合意した成果物を完成させ、検収を受けることを重視する契約です。要件、納期、検収基準が明確な機能開発や移行作業に向いていますが、発注後に要件が大きく変わると、変更契約や追加見積もりが必要になります。何をもって完成とするか、性能、障害、瑕疵対応、再検収の条件まで文書化します。

準委任契約は、専門家の作業やプロジェクト支援を依頼する契約です。要件定義、PMO、業務整理、Fit＆Gap、データ移行支援など、成果物だけでなく継続的な検討や助言が必要な段階に適しています。作業範囲、稼働時間、会議体、報告物、意思決定の期限を明確にし、発注者側の責任者が判断を止めないことが重要です。SaaSやASPは、利用料、サポート、SLA、データ返却、解約時の移行支援を利用規約だけでなく個別契約でも確認します。

進行は、企画・現状分析、要件定義、基本設計、詳細設計・開発、テスト、移行、教育、リリース、運用保守の順で進めます。最初のリリースでは、顧客・案件・書類・期限・承認・検索など共通基盤を対象にし、財産シミュレーションや高度な執行自動化は第二段階に分ける方法が現実的です。ただし、後から追加する業務のデータモデルと権限だけは初期段階で考えておきます。

テストでは、通常の申込だけでなく、相続人の変更、財産の追加・評価更新、書類の差戻し、担当者異動、照会未回答、死亡連絡の重複、休日の期限、緊急の払出し、外部連携の失敗をシナリオにします。遺言信託は発生頻度の低い業務ほど本番で初めて問題が表面化しやすいため、過去案件を匿名化したデータでリハーサルし、現場の担当者が受入テストを担います。

発注者側には、業務部門のプロダクトオーナー、情報システム担当、コンプライアンス・法務担当、現場のキーユーザーを置きます。開発会社に業務判断を丸投げすると、画面は完成しても、規程や権限、例外処理、帳票の根拠が決まらないまま進みます。週次の課題管理、月次の意思決定、変更要求の優先順位付けを行い、決定事項を議事録と要件台帳に残します。

法改正や商品追加は避けられないため、変更要求の受付、影響範囲の分析、見積もり、承認、リリース、証跡保管までの手順を初期契約で決めます。保守契約には、通常の問い合わせ、障害、セキュリティインシデント、制度改正、軽微な帳票変更を分け、それぞれの応答時間・復旧目標・費用の扱いを明記します。

遺言信託管理システムの費用相場と見積の内訳

遺言信託管理システムの公開価格は限られるため、費用は業務範囲、利用者数、既存システム連携、移行件数、監査・BCP水準、保守体制を前提にした概算として考えます。2026年7月公開のSIA株式会社の一般的な業務システム相場では、小規模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と改善効果を同じ表にします。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で、アドオンの増え方まで確認します。

業務目的、対象商品の範囲、現行フロー、利用者と権限、顧客・相続人・財産・書類・期限のデータ項目、必要帳票、外部連携、セキュリティ、可用性、移行、教育、保守、検収条件を記載します。特に、標準機能・設定・アドオン・業務変更のどれで対応する想定か、見積に含む作業と含まない作業は明記します。代表的な例外シナリオを添えると、提案の比較精度が上がります。

最も重視すべきことは、信託・相続実務とシステム開発の両方を理解し、導入後まで責任範囲を説明できることです。遺言信託と遺言代用信託の違い、長期の定期照会、相続発生後の執行、証憑・監査ログ、法改正、データ移行を、提案書とデモで具体化できるか確認します。価格差の理由、再委託、障害対応、データ返却も質問し、複数社を同じ評価軸で比較します。

まとめ

遺言信託管理システムを発注するときは、まず遺言信託と遺言代用信託の対象範囲を分け、申込から定期照会、相続発生後の執行、払出し、保管・監査までのライフサイクルを整理します。そのうえで、パッケージ・クラウド・スクラッチ・ハイブリッドの違いを、機能適合性と5年TCOで比較します。

RFPには、業務フロー、データ項目、権限、連携、セキュリティ、移行、テスト、保守、検収条件を記載します。見積比較では、初期費用だけでなく、法改正、脆弱性対応、教育、監査、運用、データ返却まで含む5年TCOを確認します。開発会社には、標準機能・設定・アドオン・業務変更の境界を説明してもらい、同じ代表案件と例外シナリオで提案を比べます。

最初から全機能を一度に作ろうとせず、担当者交代や定期照会の期限漏れ、書類の所在不明、相続発生後の引き継ぎ不足など、現在のリスクを優先順位にします。業務側の責任者を置き、現行資料と代表案件をそろえ、複数の委託先へ同じ条件で相談してください。遺言信託管理システムは、画面を導入するだけでなく、長期案件を安全に引き継ぎ、正確に執行するための業務基盤として設計することが大切です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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