研究費管理システム開発の完全ガイド

研究費管理システムは、採択や配分から執行、証憑、承認、監査、報告までを研究課題ごとにつなぎ、研究費を正確に管理し、後から説明できる状態を保つ仕組みです。

開発を検討する際は、全体像と主要機能を押さえ、導入方式、開発手順、費用、開発会社の選び方を順に確認します。

▼関連記事一覧
・研究費管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・研究費管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・研究費管理システム開発の見積相場や費用/コスト/値段について
・研究費管理システム開発の発注/外注/依頼/委託方法について

研究費管理システムの全体像

研究費管理システムを中心に、科研費、公的研究費、受託研究費・共同研究費、寄附金・学内研究費を配置した図。
資金種別ごとのルールを分けて持つ構成です。

研究費管理システムは、研究課題、研究者、部局をひも付けて管理するシステムです。資金種別、費目、研究期間も、研究課題ごとに結び付けて扱います。支出を記録するだけの会計ソフトとは、扱う範囲が異なります。採択額や配分額に対して、承認された申請、根拠となる証憑、支払状況、残高を追跡します。

研究費の適正な管理と監査は機関の責任で行われます。そのため、データに加えて、承認者や処理日時も確認できる必要があります。

会計ソフトとの違い

会計ソフトは勘定科目や仕訳を中心に入出金を管理します。一方で研究費管理システムは、仕訳の前段にある申請、予算残高、費目ルール、検収、証憑、承認を管理します。

たとえば同じ物品購入でも、科研費、受託研究費、学内研究費では、支出できる費目や承認者、必要書類が異なる場合があります。

資金種別ごとのルールをシステム側で分けて持ち、会計システムへ正しいコードで連携できれば、研究者と事務担当者の二重入力や差戻しを減らせます。

管理できる研究費の種類

主な対象は、科研費、国や自治体などからの公的研究費、受託研究費、共同研究費、寄附金、学内研究費、研究開発部門のプロジェクト予算です。

資金を一つの画面で横断検索できる一方で、補助金と基金は区別する必要があります。直接経費と間接経費、研究期間の扱いも、取り違えない設計が求められます。費目間流用や分担金も、混同しない構造が必要です。

制度上の違いを一つの共通項目に無理に押し込むと、後から帳票や報告のための手作業が増えます。そのため、共通マスタと資金別ルールを分けて設計することが安全です。

ポイント

会計ソフトの延長で足りるかは、申請や承認、証憑まで扱う必要があるか、資金種別ごとのルールを分けて持てるかで判断できます。

研究費管理システムの主要機能と必要な要件

研究費管理システムを中心に、予算管理、購買・旅費・謝金、証憑、権限・ワークフロー・外部連携の4領域を配置した図。
申請から会計連携まで、機能を役割ごとに整理できます。

機能要件を考えるときは、「研究費を管理する」という大きな言葉を、予算、申請、購買、旅費、謝金に分解します。証憑、承認、会計連携、報告、分析も、機能ごとに切り分けて整理します。

研究者、秘書、部局事務、経理、研究推進、監査担当では、必要な画面と権限が異なります。そのため、全員に同じ入力フォームを渡さないことが重要です。

予算配分・執行・残高の管理

採択額、交付額、入金額、研究者や部局への配分額、執行済額、未払額、残高を、同じ課題コードで管理します。補助金と基金は区別し、複数年度にまたがる研究期間や年度繰越にも対応できる必要があります。

費目別の残高だけでなく、発注済みで未払いの金額や申請中の金額まで含めて「使える残高」を表示します。こうすると、年度末の執行集中や予算超過を早い段階で把握できます。

研究者が自分の画面で残高を確認できれば、事務局への照会件数も抑えられます。

購買・旅費・謝金と証憑の流れ

購買、旅費、謝金では、申請から支払までの対象データを一連で管理します。確認対象は次のように分けると、業務ごとの不足を見つけやすくなります。

  • 物品購入:見積、購入依頼、承認、発注、納品、検収、請求、支払い
  • 旅費:出張申請、経路、日当、宿泊、精算、証憑
  • 謝金・人件費:対象者、期間、単価、勤務・従事実績

領収書を添付するだけでは、監査には足りません。監査では、登録者・日時、研究課題、費目、承認者で検索できる必要があります。さらに、電子添付のファイル形式、容量、保存期間、訂正・差し替え履歴も要件に含めます。

権限・ワークフロー・外部連携の設計

研究者は申請と状況確認、秘書は代理入力、部局事務は内容確認を担うように、役割ごとにできる操作を分けます。経理は支払と会計連携、監査担当は検索と出力を担当します。

研究課題や金額によって承認経路を変えるほか、代理承認や差戻しの理由も履歴に残します。財務会計、購買、旅費、人事給与、学内認証、電子申請との連携では、APIが常に最適とは限りません。

日次や数時間ごとのCSV連携で足りるデータは、定時連携も候補になります。初期費用と障害箇所を抑えやすいためです。

ポイント

機能を選ぶときは、役割ごとに画面と権限を分けられるか、証憑を登録者や費目で検索できるかを優先して見るとよいです。購買や旅費は、証憑の扱いとあわせて考えます。

研究費管理システム開発の進め方と6段階の流れ

開発を始める前に、システムの画面より先に、現行業務の流れを整理します。研究費の申請から報告までには、部局ごとの慣行や資金制度ごとの例外が入りやすいため、最初から全機能を作ろうとすると要件が膨らみます。

最初の導入範囲を決め、測定可能な成果を設定したうえで、段階的に広げる進め方が現実的です。

▶ 詳細はこちら:研究費管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 現状業務の洗い出しと要件の決定

現状業務の洗い出しは、次の順に進めます。まず、採択・交付、予算配分、物品購入、旅費、謝金を業務フローにします。そのうえで、検収、支払、年度切替、研究期間終了、実績報告、監査依頼も、同じ流れに組み込みます。

  1. 業務フローの作成
  2. 各工程の入力者と承認者、書類、判断条件、会計コードの記録(例外処理や所要時間も含む)
  3. 研究者や秘書、事務、経理、情報システム、監査の代表者への聞き取りによる、標準業務と例外業務の切り分け

非公式な手順は要件漏れの原因になりやすいため、Excelでの修正担当やメール承認の保管先まで確認します。

2. マスタ・権限・連携仕様の設計

マスタは、入力・承認・会計連携の土台になります。そのため、まず研究課題、研究者、部局を定義します。資金の区分や支出の分類、承認の担当者も、マスタとして持たせます。

  • 資金種別
  • 費目
  • 勘定科目
  • 承認者

研究者が入力する項目と事務局が補完する項目を分けておくと、同じ情報を何度も入力させずに済みます。

e-Radは競争的研究費の応募受付から審査、採択、課題管理、成果報告までをオンライン化する府省横断システムです(出典: 内閣府「e-Radとは」、2026年確認)。

自機関の研究費管理システムは、e-Radと役割を分けて考えます。e-Radの採択情報や課題番号などを取り込み、機関内の執行、証憑、会計処理へつなぐ役割として境界を決めます。

3. 開発・移行・テスト・リリースの段階的な進め方

開発後は、研究者の申請操作と、事務担当者による差戻し、承認、支払処理を順に確かめます。続いて、移行と先行導入、本番展開の準備に進みます。

  1. 年度末、基金の繰越、費目間流用、研究者の異動、分担金のテスト
  2. 研究期間終了、証憑の差し替え、会計連携エラーの再現
  3. 先行導入での入力時間、差戻し率、問い合わせ件数、未処理件数の計測
  4. 移行前のマスタと過去データの点検、および移行・参照専用・紙保管への振り分け

ポイント

進め方は、現行業務を洗い出したうえで、導入範囲を小さく決めて段階的に広げる順で考えます。全機能を一度に作ると要件が膨らみやすいためです。

パッケージ・クラウド・スクラッチの違いと選び方

クラウド型、パッケージ、スクラッチ開発を、それぞれ運用負担、設定と連携、自由度の特徴で並べた図。
標準機能と独自ルールの距離が方式選びの分かれ目です。

導入方式は、標準化できる業務の範囲、既存システムとの関係、独自ルールの量、運用体制、予算を基準に選びます。

大切なのは方式の名前よりも、標準機能にどこまで合わせ、どこを設定や追加開発で補うかを決めることです。

クラウド・SaaS型の短期間の導入と運用負担の軽減

クラウド型は、サーバーやOS更新、バックアップなどの基盤運用を自機関で抱えにくく、利用開始までの期間を短くしやすい方式です。標準的な申請、経費精算、証憑添付、権限管理を早く整えたい場合に向きます。

月額は、利用者数、課題数、申請件数、ストレージ、連携オプションで変わることがあるため、5年程度の総額で比べます。

データ所在地、障害時の復旧目標、契約終了時の返却・削除、個別ルールの設定範囲も、事前に確認します。

パッケージ+連携・追加開発の特徴

既存の財務会計や購買を活かしつつ、研究費の申請、残高、証憑、承認を足したい場合は、パッケージを基盤に設定と連携を組み合わせる方法が現実的です。

要件ごとに、標準機能で合わせる部分と、設定で変える部分、追加開発する部分に分類します。

すべてを個別仕様にすると、制度改正のたびに保守費が増えやすいため、資金種別や承認経路は設定値で変えられる構造を優先します。

スクラッチ・大規模統合の特徴と適した場面

複数キャンパス・法人や独自の研究ポートフォリオがあり、標準機能との差が大きい場合は、スクラッチ開発や基幹システムの拡張を検討します。複雑な間接経費配分や既存ERPとの深い統合も、判断材料になります。

自由度が高い一方で、要件定義、移行、テスト、教育、運用保守まで責任範囲が広がります。制度改正時の変更手順と費用も、契約に含めておきます。

開発会社が変わっても保守できるよう、設計書、API仕様、データ定義、テストケースを残します。

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

価格は、研究課題数、利用者数、部局数、既存会計との連携、証憑保管、権限の複雑さによって大きく変わります。

費用は、初期構築費、データ移行費、連携費、保守費など、項目ごとに分けて見積もることが必要です。教育費やクラウド利用料、制度改正対応費も、同じ考え方で分けます。次に示すのは、2026年時点でRFPの予算枠を考える際の目安です。

▶ 詳細はこちら:研究費管理システム開発の見積相場や費用/コスト/値段について

規模別の初期費用の目安

一部局から全学、大規模統合へと対象が広がると、必要な機能や連携範囲に応じて初期費用も変わります。

  • 一部局・小規模:20〜100人程度、CSV中心のクラウド・パッケージ型で300万〜800万円程度
  • 大学全体・中規模:100〜500人程度、購買・旅費・認証・財務会計と連携し1,000万〜3,000万円程度
  • 大規模・個別開発:複数キャンパス・法人で研究支援・財務・購買を統合し3,000万〜1億円超の場合

いずれも、公開事例や一般的な業務システムの工数から整理した推定レンジで、正式な価格を示すものではありません。

比較のアンカーとして使う公開調達額の位置づけ

公開調達の実例として、豊橋技術科学大学の2024年6月公示には「大学研究費管理会計システム一式」が1式、落札価格4,653万円と記載されています(出典: 日本貿易振興機構・政府公共調達データベース、2024年)。

これは借入方式の契約であり、契約期間や利用料、導入・保守の範囲を含むため、開発だけの価格ではありません。

他機関の見積もりと比べるときは、利用者数、期間、機能、会計連携、保守の範囲をそろえ、参考値として扱います。

見落としやすいランニングコスト

月額・年額の利用料に加え、追加料金や運用費用も確認します。

  • 利用・連携:ストレージ、ユーザー、API・CSV連携、電子証憑保存
  • 運用支援:バックアップ、問い合わせ窓口、教育、年度切替
  • 継続対応:制度改正、脆弱性対応、データ出力

初期費用が低くても、個別改修が毎年必要であれば総額は上がります。逆に、標準機能に業務を寄せ、費目や承認経路を設定で変えられるなら、保守費を抑えやすくなります。

5年間の総保有コストと担当者の作業時間も、合わせて評価します。

ポイント

予算枠を決めるときは、規模別の目安を参考にしつつ、利用者数と連携先の数で自機関がどの規模に当たるかを見定めます。

見積もりを取る際のポイントとRFPに入れる項目

見積もりの精度は、発注側が現行業務と必要な成果物をどこまで整理できるかで変わります。

機能一覧と一緒に、前提条件を添えます。資金種別、利用者、件数、承認経路、連携先、移行データを示し、保存期間と運用体制も共有します。

価格の安さだけでなく、何が見積もりに含まれていないかを確認することが重要です。

要件定義書に書く業務・データ・非機能要件

要件定義書には、次の3種類を分けて記載します。

  • 業務要件:採択、配分、申請、承認、検収、支払、報告、監査
  • データ要件:課題番号、資金種別、期間、費目、課税区分、会計コード、利用者、証憑
  • 非機能要件:同時利用者数、応答時間、可用性、バックアップ、復旧時間、アクセスログ、暗号化、多要素認証、データ所在地、保守時間、問い合わせ対応

2026年時点では、研究データの管理計画やアクセス範囲も確認します。日本学術振興会は、2024年度以降に実施する新規・継続を含む科研費の研究課題でDMPの活用を示しています(出典: 日本学術振興会「科研費における研究データの管理・利活用について」、2026年確認)。

会計情報と研究データを別システムで持つ場合は、必要な識別子と連携範囲も要件にします。

同じ条件と成果物で比較する複数の見積もり

比較対象には、専用型、大学の財務統合型、クラウド経費型、受託開発型など、異なる選択肢を含めます。ただし、評価はデモ画面の印象よりも、同じサンプル業務で行います。

たとえば、基金の複数年度管理や費目外支出の差戻し、分担金の配分を実演してもらいます。さらに、領収書の差し替え、研究者の異動、会計連携エラー、年度切替も、実演の対象に含めます。

初期費用や月額、連携、移行、教育、保守などの単価は、同じ様式で出してもらいます。追加改修と制度改正の単価も含めると、安く見える見積もりの抜け漏れを見つけやすくなります。

契約・移行・制度改正のリスクの切り分け

要件変更が多い部分は、固定範囲の請負だけで進めると変更協議が増えやすくなります。逆に準委任だけでは、総額が見えにくくなります。

要件定義、標準機能の設定、追加開発、データ移行、運用改善を分け、成果物と受入条件を明確にします。データ移行では、過去データの欠損、重複課題、コード変換、証憑のファイル名、保存期限を点検します。

制度改正では、誰が改修の要否を判断し、いつテストし、どの費用で本番反映するかを保守契約に記載します。

研究費管理システムの開発会社・ベンダーの選び方

開発会社・ベンダーは、機能一覧の多さよりも、研究費固有の制度と現場運用を理解し、既存の会計・購買・認証基盤へ安全につなげられるかで評価します。

専用パッケージに強い事業者、大学財務との統合に強い事業者、クラウド経費に強い事業者、大規模な個別開発に強い事業者では、得意領域が異なります。そのため、発注前に自機関の優先順位を決め、同じ質問を各候補に投げかけます。

研究費制度と大学・研究機関の業務経験

導入社数よりも、どう実装したかを聞くことが大切です。科研費の補助金・基金、受託研究、共同研究を対象に、間接経費や費目間流用の扱いを聞きます。研究期間終了と実績報告の扱いも、あわせて確認します。

可能であれば、匿名化した画面や業務フローを見せてもらい、研究者、秘書、部局事務、経理それぞれの利用場面を確かめます。

制度の理解が十分でない場合、要件定義で「現行では例外」と扱われた処理が、本番後に重要になることがあります。そのため、導入責任者や業務コンサルタントの参加体制も評価します。

セキュリティと導入後の保守体制

認証と権限では、SSO、多要素認証、最小権限、職務分掌を確認します。データでは、通信・保存データの暗号化、バックアップ、復旧手順を確かめます。さらに、操作・承認・出力の監査ログ、脆弱性対応、再委託先の管理も確認します。

研究者の個人情報、謝金や雇用に関する情報、共同研究先の情報を扱う場合は、個人情報保護委員会の安全管理措置や委託先監督の考え方も、契約・運用に落とし込みます(出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年6月時点)。

また、導入後の問い合わせ窓口、年度切替の支援、制度改正の通知、障害時の連絡、データ出力、契約終了時の移行支援も見ておきます。

見積もりの前提と責任範囲

見積もりの範囲は、「標準対応」の実現方法と、連携・移行・教育の前提を文書で示してもらい、確かめます。

  • 機能の実現方法:設定、追加開発、運用回避のどれか
  • 連携・移行:相手方、件数、頻度、再送方法、移行対象
  • 導入支援:テスト環境、研修回数、マニュアルの範囲

研究セキュリティでは、2026年度も、研究の開放性と安全を両立させるリスク管理が重視されています(出典: 科学技術振興機構「研究セキュリティ確保への取組」、2026年度情報)。

アクセス権限やデータ持ち出しの申請を、導入後に誰が担うかも決めておき、管理が形だけにならないようにします。

▶ 詳細はこちら:研究費管理システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら:研究費管理システム開発の発注/外注/依頼/委託方法について

ポイント

開発会社を比べるときは、機能の多さよりも、研究費制度と現場運用を理解しているか、既存の会計・購買基盤へつなげられるかを軸にします。

導入効果を出すための運用設計と評価指標

導入の目的を「紙をなくす」に置くと、現場が便利になったか、監査対応が改善したかを測りにくくなります。そこで、導入前の作業時間や差戻し件数を計測し、導入後に同じ指標で比べます。

研究者の入力負担と、事務局の統制・説明責任を、同時に改善する視点が必要です。

導入前後の工数・差戻し・問い合わせ

測定項目には、申請から承認までの時間、1件あたりの入力時間、差戻し率、未処理件数を含めます。さらに、残高照会の問い合わせ数、月次集計にかかる時間、監査資料の準備時間も測ります。

測定では、導入前の1か月間に、研究者が何分入力し、事務局が何回修正し、経理がどの帳票を手作業で作ったかを記録します。

導入後は、処理件数を増やすことよりも、正確性と処理の早さが両立しているかを確かめます。

利用定着を支えるルールと支援

研究者が使わない理由には、操作の難しさのほか、運用ルールが不明確なことも挙げられます。そこで、定着を支える対応をそろえます。

  • 入力・判断支援:入力例と費目の判断ガイド
  • 問い合わせ対応:差戻しテンプレートと窓口
  • 利用案内:短時間の研修と残高・処理状況の確認方法

費目選択、差戻し理由、代理入力の範囲、年度末の締切が不明確だと、利用は進みません。そこで、先行導入で得た質問をFAQや画面ヘルプに反映しておくと、全学展開後の負担を抑えられます。

制度改正と研究データの変化への備え

研究費制度や報告様式、研究データ管理方針、研究セキュリティの要件は変化します。研究費管理システムにすべての研究データを集約する必要はありません。

連携の識別子は、研究課題番号と研究者を軸に設計します。加えて、研究期間、資金種別、公開・共有・非公開区分も、設計に含めます。変更履歴や設定変更者、適用日、旧ルールの処理記録も残しておくと、制度改正後の説明に備えられます。

研究費管理システムに関するよくある質問

導入の検討では、方式、費用、既存システムとの関係、制度対応について、同じ疑問が繰り返し出てきます。特に導入前に確認しておきたい質問に、順に答えます。

研究費管理システムは会計システムがあれば不要ですか?

会計システムがあっても、研究費管理システムが必要になることがあります。会計システムは仕訳や決算を中心に扱うのに対し、研究費管理システムは、採択や配分、申請、承認から証憑、残高、研究課題ごとの報告までを扱うため、役割が異なります。

会計システムを残したまま、研究費の前段業務だけを追加し、確定した支払データを連携する構成も選べます。

研究費管理システムはクラウドでも問題ありませんか?

要件を満たすクラウドであれば、選択肢になります。多要素認証や権限分離、暗号化、監査ログといった安全面を見ておきます。加えて、バックアップや復旧目標、データ所在地、委託先・再委託先の管理、契約終了時のデータ返却も確認します。

閉域網や学内サーバーが必要かどうかは、研究内容、既存認証、組織のセキュリティ方針で判断します。方式を先に決めつけないことが重要です。

研究費管理システムの導入費用はどのくらいですか?

一部局・小規模のクラウドやパッケージは、300万〜800万円程度が目安です。大学全体の中規模導入は、1,000万〜3,000万円程度を見込みます。

大規模な個別開発は、3,000万〜1億円超になる場合があります。会計・購買連携、移行、証憑保管、研修、保守の範囲によって変わります。月額だけでなく、5年間の利用料と制度改正対応を含む総額で比べてください。

DMPや研究セキュリティまで研究費管理システムで管理すべきですか?

すべての研究データを研究費管理システムに保存する必要はありませんが、研究課題とDMP、研究データ基盤、公開・共有・非公開の判断を連携できる設計は有効です。

科研費では2024年度以降の研究課題についてDMPの活用が示され、2026年度は研究セキュリティへの対応も進んでいます。

会計情報、研究者情報、共同研究情報のアクセス権限を分け、必要な識別子とログだけを安全に連携する方法を検討します。

まとめ:制度・現場・会計をつなぐ研究費管理システム

研究費管理システムは、採択・配分から執行、証憑、承認までを研究課題単位でつなぎます。さらに、会計、監査、報告も同じ単位で結び付ける仕組みです。

成功のポイントは、研究者が残高や申請状況を確認しやすく、事務局が制度に沿って統制でき、監査担当が必要な証跡をすぐに出せる状態を同時に実現することです。

導入前に押さえるべき要点

まず現行業務を洗い出し、資金種別、複数年度、費目、承認経路を要件にします。証憑、会計連携、監査ログも要件に入れます。次に、クラウド・パッケージ・スクラッチのどこが適するかを、独自ルールと運用体制から判断します。

費用は初期構築だけでなく、移行、教育、連携、保守、制度改正、5年間の利用料まで含めて比較します。

2026年時点では、DMPや研究セキュリティ、個人情報の安全管理も、システム要件と運用ルールの両面で確認します。

次に作るべき資料と進め方

次の資料をそろえ、候補選定と段階導入に進みます。

  1. 業務フロー、利用者と権限、資金種別と費目、連携先、移行対象、非機能要件の整理
  2. 同じシナリオで複数候補を比べること(デモ、見積もり、導入体制、保守条件)
  3. 小さく先行導入して効果を測り、質問と例外処理を反映したうえでの全体展開

この手順を踏むと、研究者の負担と運用リスクを抑えながら、導入を進められます。

▼関連記事一覧
・研究費管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・研究費管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・研究費管理システム開発の見積相場や費用/コスト/値段について
・研究費管理システム開発の発注/外注/依頼/委託方法について

 

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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