証明書発行システムの発注は、業務範囲の整理、同条件のRFP（提案依頼書）の作成、PoCでの比較と選定の順に進めると、導入後の定着につながります。
発注前に決めることから委託先の比較まで、順に説明します。全体像は、証明書発行システム開発の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・証明書発行システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
証明書発行システムの発注前に決めること
発注前に決めるべきは、誰が、どのデータを使い、どの証明書を、どの方法で、どの提出先へ渡すかです。
システムの名前や画面の見た目より、この点を先に固めておきます。
発注の前提が曖昧なまま相見積もりを取ると、会社ごとに置く前提条件がずれます。そのため、金額を並べても、同じ条件で比べたことにはなりません。
発行業務を構成する範囲
証明書発行システムが扱うのは、申請の受付から証明書の交付、発行後の運用までです。
- 申請と本人確認：Webやスマートフォンからの申請受付、在学生・卒業生の利用者登録、本人認証。
- 照合から交付：在籍や卒業情報の照合、審査、決済を経て、帳票の生成、印刷またはPDF送付、発行履歴の保存までの流れ。
- 発行後の運用：再発行、失効、訂正、問い合わせ対応、監査ログ、バックアップまで含めた日々の作業の範囲。
「オンライン申請だけを導入する」場合でも、職員が別画面への転記や印刷・押印を続けるなら、業務全体の負担は残ります。そこで、RFPには申請から交付までの現行フローと、導入後も残る作業を明記してください。
受け取り方法と真正性のレベル
受け取り方法と、真正性を確かめる手段は、利用者と提出先に応じて組み合わせます。
- 受け取り方法：学内の自動発行機、窓口、郵送、コンビニのマルチコピー機、電子署名付きPDFの区分。
- 真正性の仕組み：電子署名、タイムスタンプ、二次元コード、検証ページ、提出先の限定、失効・再発行の組み合わせ。
受け取り方法の選択肢は、利用者と提出先の事情に合わせて設計します。たとえば、就職活動中の学生、遠方の卒業生、留学生や、提出先の企業などを想定します。すべてを一度に用意する必要はありません。
発行者が正しいことや、発行後に改変されていないことは、PDFを受け取れるだけでは示せません。そのため、提出先が何を確認できる状態にするかまで決めてください。
学校・自治体・企業で変わる要件
対象組織によって連携先や管理対象は異なるため、業務固有の要件と共通要件を分けてRFPに記載します。
- 大学・学校：学生情報・教務・成績・履修データとの連携、卒業生の本人確認、和文・英文の帳票、発行機やコンビニへの接続が中心。
- 自治体：住民情報や個人番号を含む情報の取り扱い、窓口・証明書交付機、厳格な監査と災害対策が重く求められる点。
- 企業：人事・資格・取引先管理との連携、在職状況や有効期限の管理が中心。
この記事は、学校・大学向けを主な対象にしています。
自治体や企業が発注する場合も、データの正本、本人確認、発行後の検証、アクセス権限、ログ保存という共通項は使えます。
発注形態の選び方
方式を選ぶ前に、業務を標準サービスに合わせられるか、独自の帳票や連携が必要かを確かめます。
方式を比べるときは、初期費用だけでなく5年間の利用料も見ます。
改修や機器の費用、保守、制度変更への対応も、比べる対象に含めます。
クラウド・SaaS型を選ぶ場合
標準機能で短期間に使い始めたい組織には、クラウド型が候補になります。
- 使える標準機能：申請、決済、コンビニ発行、郵送、電子PDFなど。
- 運用面：サーバー保守やセキュリティ更新を抱えにくく、繁忙期の増加にも対応しやすい方式。
運用の利点がある一方で、データの扱いは契約で確かめる必要があります。データ保存地域やバックアップ、障害時の目標復旧時間は、契約前に確認します。サービス終了時のデータ返却、解約後の削除、再委託先も、確認項目に含めます。
月額・従量・決済手数料に加えて、標準外の帳票や認証との連携開発費も見積もります。
パッケージ・専用機型を選ぶ場合
定型業務を安定して運用し、既存の設備も活かしたい組織では、パッケージや自動発行機が候補になります。
- 対応業務：証明書種別、手数料、印影、発行履歴、代理発行、発行機管理の範囲。
- 既存設備：学生証、プリンター、学内ネットワークを使い、業務変更を抑えられる場合があること。
導入前には、保守期限や英語帳票の扱いを確かめます。卒業生認証やクラウド移行、故障時の代替手段も、確認しておきます。
機器購入費や設置工事費は、別見積もりになりやすい項目です。そのため、ソフトウェア費だけで判断しないようにします。
ハイブリッド・スクラッチ型を選ぶ場合
標準製品に合わない要件がある場合は、共通機能を再利用して、独自の部分を追加する方法があります。
- ハイブリッド：独自様式、複雑な審査、複数法人統合、自治体固有の住民情報連携などに、API・ポータル・帳票を追加する方式。
- 完全スクラッチ：自由度は高い一方で、正本、署名鍵、失効・再発行、制度変更、長期保守の責任が増える方式。
ハイブリッド方式では、認証や署名、決済、バックアップなどを再利用できます。一方、スクラッチを選ぶ場合は、標準機能で不足する業務要件を説明できる状態にしておきます。
RFPと要件整理の進め方
RFPは、同じ条件で提案と見積もりを比べるための基準です。そこで、現行業務や対象範囲、必須と希望の要件を書き、前提、納期、成果物、評価方法もまとめます。
現行フローと対象証明書の洗い出し
証明書の種類と発行条件を整理し、ピーク時の発行件数も見積もっておくと、対象範囲を定める材料がそろいます。
- 証明書：在学、卒業、成績、健康診断、英文などの一覧。
- 発行条件：対象者、可能期間、停止条件、厳封、提出先、保存期間、再発行・訂正の取り決め。
- 件数：月平均のほか、卒業・入試・採用時期のピーク。
申請から問い合わせまでの各工程について、担当者と所要時間も記録します。
本人確認や照合、承認、決済などが、記録する工程の例です。
導入前の基準値として、窓口件数や郵送費、職員の工数を押さえておきます。加えて、発行機の台数や問い合わせ件数も、押さえておく項目です。
データ連携と本人確認の決め方
連携仕様と認証の強さは、卒業後の利用も含めて決めます。利便性を保ちながら、誤発行やなりすましのリスクも抑える必要があるためです。
- データ連携：学生情報、教務、成績、履修の項目と、受け取る時点の取り決め。
- 連携方式：APIかファイルか、文字コード、氏名表記、卒業後の保持範囲、エラー確認者の記載事項。
- 本人確認：初回登録、本人確認書類、過去の連絡先、二要素認証などを、対象者に応じて組み合わせる方法。
認証が強すぎると利用率が下がる一方、弱すぎるとなりすましや誤発行のリスクが高まります。
こうした両面を踏まえ、認証は対象者とリスクに応じて段階的に設計します。
帳票・セキュリティ・災害対策の要件
帳票の仕様や情報保護、障害時の復旧は、RFPに含めておきます。提出先が紙か電子データかによって、必要な機能も変わります。
- 帳票：和文・英文、印影、ページ数、QRコード、電子署名、タイムスタンプ、発行番号、検証URL、提出先限定、印刷後の確認方法の指定。
- セキュリティ：権限分離、通信・保存時の暗号化、操作・発行ログ、バックアップ、脆弱性対応、再委託管理の取り決め。
- 災害対策：繁忙期、災害、発行機・クラウド障害時の窓口・郵送・別拠点と、復旧手順の要求。
デジタル庁「教育分野の認証基盤に関する調査研究（2025年度）」では、学生情報データベースとの連携や、受取先による発行主体の検証が整理されています。
この調査には検討途中の構想も含まれるため、商用機能と将来候補を分けてRFPに記載します。
請負と準委任の使い分け
成果物と仕様を確定できる工程には請負を、要件整理や継続改善には準委任を当てる方法があります。
工程ごとに契約を分けると、責任範囲を明確にできます。どこまでを誰が受け持つかも、この段階ではっきりさせられます。
請負契約で確定させる項目
請負では、合意した仕様どおりの成果物を納品し、検収します。成果物と変更の手続きを先に決めておくと、納期と予算の見通しが立ちやすくなります。
- 成果物：画面やAPI、帳票、テスト結果、操作マニュアル、移行データ、設定値の一覧。
- 検収と保証：検収条件、瑕疵対応、保証期間、納期、遅延時の扱いの明確化。
- 仕様変更：契約前に決める、変更の定義、承認者、追加費用の算定方法。
帳票の文言や印影は、後から変わることがあります。開発中には、既存データの不備が見つかる場合もあります。そのため、変更要求の扱いを定め、予算と納期への影響を管理しておきます。
準委任契約で進めやすい項目
要件整理など、専門人材の支援を受けながら進める工程では、準委任が候補になります。業務の知識はあっても、連携やセキュリティを整理する人材が足りない場合に活用できます。
- 支援内容：要件定義、現行調査、ベンダー調整、データ整理、運用設計の依頼。
- 契約条件：作業時間、体制、会議、報告、成果物の扱い、責任分界。
準委任は作業を支援する契約で、依頼するだけでシステムが完成するわけではありません。また、要件定義の成果を次の請負契約へ引き継ぐ方法も設計します。
段階発注と受け入れ体制
段階発注では、課題を早い段階で見つけ、受け入れを判断する機会を作れます。特に、電子証明書の提出先対応などは、小規模な検証から始められます。
- 現状分析と要件定義。
- 少数の証明書種別でのPoC（電子証明書の提出先対応、卒業生認証、成績連携）。
- システムの構築と連携の実装。
- テストと移行、運用保守への移行。
発注者の側では、業務責任者や情報システム、個人情報・セキュリティ、窓口・教務の担当者を置きます。
帳票や発行停止、誤発行時の対応、利用者への告知について、発注者が判断できる体制を整えます。
証明書発行システムの費用相場の目安
公開されている価格は少なく、機能や連携の範囲によって差があるため、一律の定価はありません。
ここで示すのは、公的調達、公開料金、類似業務システムからの推定レンジです。予算を立てるには、要件をまとめたRFPで個別の見積もりを取ります。
導入方式ごとの費用レンジ
費用は、導入する範囲によって変わります。次の金額はあくまで目安で、正式な予算を立てるには個別見積もりが必要です。
- 小規模：Web申請、郵送受付、PDF帳票に限定した場合の、初期100万〜300万円、月額1万〜10万円程度。
- クラウド標準導入：申請、決済、教務や人事データ連携、コンビニまたは学内発行機、基本的な運用設計を含む場合の、初期300万〜800万円、月額5万〜30万円程度。
- 大学の本格導入：複数キャンパス、英文帳票、複数発行機、電子署名、既存改修を含む場合の、初期500万〜1,000万円前後。
大学向けの本格導入では、要件によって初期費用が1,000万〜2,000万円超になる可能性もあります。
新潟県立大学の案件では、2025年12月24日に株式会社SIGが税抜745万円で落札しました。
この金額は、機器や連携範囲、保守期間を含めた個別の結果で、共通の定価ではありません（出典：新潟県立大学の入札結果）。
見積もりに含める費用項目
見積もりは、初期費用と継続費用を分け、数量や単価、前提、対象外の作業までそろえて比べます。
- 開発・導入：要件定義、基本設計、画面・API、帳票、連携、データ移行、認証を含む範囲。
- 機能・設備：署名・タイムスタンプ、決済、発行機・プリンター、クラウド利用料の扱い。
- 運用準備：テスト、教育、導入支援、保守の区分と、含まれない作業。
公立鳥取環境大学の仕様書は、国内保存や冗長バックアップ、教務・認証サーバ・発行機との連携、データ設定、単体・結合テストを求めています。
利用期間は2026年4月から2031年3月までの60か月です。
この仕様書は、初期構築費と年間利用料を分けています（出典：公立鳥取環境大学の業務仕様書）。
比べるときも、導入費と5年間の運用費を分けて見ます。
5年TCOでの比較
5年TCOには、初期構築費に加えて、継続利用や改修、設備、職員対応などを含めます。一方、効果としては、窓口時間や郵送日数、遠方からの来学、繁忙期の残業、誤発行対応の減少を整理します。
- 継続・決済：月額・年間料、決済手数料、署名・タイムスタンプの利用料。
- 設備・改修：発行機・プリンターの購入と保守、連携改修、帳票変更。
- 人と残存業務：移行、教育、問い合わせ、紙・郵送の費用。
京都大学の利用者向け料金は、在学者のオンラインPDFが1通300円、卒業者などが1通610円です。コンビニ印刷は、これとは別に1通60円かかります。
ここで示した金額は発行と印刷の料金で、ベンダーへの導入費や月額費用とは別のものです（出典：京都大学「証明書発行サービスについて」）。
委託先選定と見積比較のポイント
委託先では、連携の実績や証明書業務への理解を確かめます。セキュリティや障害対応、保守、データ返却も、確認しておきたい項目です。そのうえで、同じRFPを各社に渡し、提案書・見積書・デモの条件をそろえます。
同規模・同業務の実績
比べるときは、導入実績の有無に加え、運用の規模と導入後の効果を示すデータを確かめます。
- 導入条件：学校規模、証明書、利用者数、発行ピーク、連携先、受取方法、導入期間。
- 運用体制：保守体制、窓口・郵送件数、処理時間、問い合わせ、発行機の稼働状況。
- 品質指標：誤発行や再発行の件数など、導入後の数値。
NTT西日本は、2026年3月末時点の利用校を186校、2025年度の年間発行枚数を2,718,212枚と公表しています。こうした公開情報は、クラウド型の運用規模を比べる材料になります（出典：NTT西日本「証明書発行サービス」）。
見積もりの前提をそろえた比較
費目と作業の扱いをそろえると、金額差の理由が見えてきます。曖昧な回答は、追加費用や遅延の原因になることがあります。
- 費用区分：初期、月額、従量、決済、機器、連携、保守、帳票、移行、教育の区分。
- 作業範囲：「標準」「オプション」「別途見積もり」「発注者が用意」の表記をそろえること。
- 確認事項：API、改修責任、認証、署名鍵、ログ期間、障害窓口、SLAについての各社への質問。
- 契約終了後：データ出力や制度変更時の費用負担。
一社だけ安く見えるときは、他社が含めている作業をその会社が除外していないかを照らし合わせます。
回答の内容は、提案と契約の前提に反映させます。
デモとPoCでの発行業務の再現
自組織の証明書を使ってデモを行うと、カタログでは分からない運用の差が見えてきます。本番データは使わず、匿名化したサンプルでPoCを行います。
- 通常業務：申請、本人確認、照合、決済、発行、提出先での検証までの一通り。
- 例外業務：失効、再発行、職員の代理発行。
- 異常系：氏名誤記、卒業年度の不一致、発行停止、決済失敗。
- 復旧：発行機停止、通信断、PDF検証期限切れの場面での担当者と復旧画面。
一連の操作を再現すれば、提案された機能が実際の業務に合うか、担当者が復旧できるかを確かめられます。
よくある質問（FAQ）
費用や機能に加え、契約、データ連携、電子証明書の扱いについて答えます。
証明書発行システムは数百万円で導入できますか？
小規模なWeb申請や帳票出力であれば、初期100万〜300万円程度の推定レンジに入る可能性があります。
一方で、教務連携やコンビニ・発行機まで含めると、初期費用は300万〜1,000万円前後になります。要件がさらに重なれば、それ以上の見積もりもあり得ます。金額が上がりやすいのは、次のような要件を加えるときです。
- 電子署名
- 複数拠点
- 移行
- 保守
要件別の内訳を確認してください。
クラウド型とスクラッチ開発はどちらが良いですか？
標準的な申請や決済、コンビニ発行、郵送、PDF送付を早く始めたいなら、クラウド型が候補になります。
独自審査や帳票、複数法人との連携が重要なら、標準サービスを使い、独自部分を開発するハイブリッドから検討します。
完全スクラッチは、標準機能では解決できない要件が明確な場合に選びます。
電子証明書付きPDFなら紙の証明書は不要ですか？
不要になるとは限りません。まず、提出先が電子署名やタイムスタンプ付きPDF、検証ページ、二次元コードを使えるかを確認します。
紙での提出が必要な相手には、郵送やコンビニ印刷を用意します。PDFを印刷して再スキャンするだけでは、電子証明書の真正性を活かしにくくなります。
まとめ
発注前のチェックポイント
証明書と発行ピークを整理したうえで、データ連携、本人確認、受取方法、真正性、障害時の代替運用を決め、RFPを作成します。
安全な進め方
発注から運用評価まで、次の順に進めます。
- 申請画面だけでなく発行業務全体を対象に、証明書、利用者、提出先、受取方法、認証、連携、検証、ログ、障害対応を整理。
- 初期費用と月額費用を含めた、5年TCOでの比較。
- 参考事例を自組織の要件に照らし、PoCで確かめてからの発注。
- 導入後の窓口件数や処理時間の計測と、保守契約・改善計画への反映。
候補は、クラウド、パッケージ、ハイブリッド、スクラッチです。同条件のRFPを複数社に渡し、実績や連携、セキュリティ、保守、データ返却を確かめます。
公的調達の税抜745万円や、60か月のクラウド利用仕様は参考例にすぎません。組織の規模や要件が異なるため、そのまま当てはめないでください。
少数の証明書種別からPoCを始め、発行ピーク、照合、誤発行、失効を確かめます。PDF検証、利用者案内、災害時の代替経路も、あわせて見ておきます。そのうえで対象を広げ、本開発と保守を委託します。
▼全体ガイドの記事
・証明書発行システム開発の完全ガイド
▼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を創業。