Micronautのシステム開発の発注/外注/依頼/委託方法について

Micronautのシステムは、発注前に業務範囲と連携先を整理し、PoCで技術を検証してから、契約と保守条件を決めると進めやすくなります。

発注形態から契約と保守まで、各段階で決めることを順に並べます。全体像はMicronautのシステム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・Micronautのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Micronautのシステムを発注する前に知っておきたい全体像

Micronautのシステムとは、業務システムやWebシステム、連携APIなどのバックエンドに、Micronautを組み込んだものを指します。

会計や勤怠のような完成品のパッケージではないため、フレームワークの採用と、業務機能の開発範囲は分けて考えます。

製品ではなく開発基盤としてのMicronaut

Micronautは、依存性注入やAOPの情報をコンパイル時に処理します。そのため、実行時のリフレクションなどへの依存を抑えられます。

起動時間とメモリを抑えたい場合は、APIやコンテナ、短時間で実行する関数に向いています。

業務画面、データモデル、認証は、自動では用意されません。ほかにも次の項目があるため、発注時に利用者へ提供する機能として記載しておきます。

• 権限：利用者ごとに、使える機能と操作の範囲。
• 外部連携：サービスやAPIとの接続。
• テスト：動作確認の範囲と方法。
• 監視：稼働状況を見守る仕組み。

向いている業務と向いていない業務の分け方

Micronautを選ぶ理由は、業務の独自性や連携先、実行環境によって異なります。型ごとの特徴は、次の4つで整理できます。

• API中心の業務：顧客管理や申請・承認、外部SaaSとの連携を含む業務に向きます。
• 独自処理：独自の料金計算やイベント処理、複数サービスにまたがる業務基盤に適します。
• 拡張性：AWS Lambda、コンテナ、Kubernetesで負荷に応じて広げる構成も候補です。
• 標準業務：SaaSやパッケージで足りる業務。無理なスクラッチ開発は避けます。

標準機能はSaaSに寄せ、独自ロジックと連携APIをMicronautで作る構成も選べます。

Micronautのシステムを外注するときの発注形態

契約形態は、要件がどこまで確定しているか、発注者側に技術の責任者がいるか、完成の責任を誰が持つかで選びます。

契約は一つに決め打ちせず、PoCは準委任、本番のうち範囲が明確な機能単位は請負とする組み合わせもできます。

完成させる範囲を定められる場合の請負契約

請負契約では、合意した成果物を完成させ、検収を受けることが中心になります。画面やAPIの仕様が決まり、受入条件と納期も明確であれば、予算と納品物を管理しやすくなります。

• 技術面：MicronautのバージョンやNative Image対応が未確認だと、追加変更が増えることがあります。
• 連携とデータ：外部サービスの仕様やデータ移行の難易度が未確認のままだと、追加変更の原因になります。
• 変更が見込まれる部分：変更が想定される要件を曖昧にしたまま「一式」で発注しないようにします。

検証や要件の変動がある場合の準委任契約

準委任契約では、作業時間に応じて専門人材の提供を受け、発注者と受託者が協力して進めます。そのため、調査や技術検証のように工数が読みにくい工程に向いています。

対象はPoCや設計です。既存Javaシステムの調査や要件定義なども含みます。

• バージョン構成：Micronaut 5とJavaのLTS版の組み合わせの検証。
• 機能の適用範囲：Micronaut DataやSecurityを使う範囲。
• ライブラリ互換性：GraalVM Native Imageで使えるかを調べ、判断材料を作ります。

PoCと本番を分ける段階発注

発注を段階に分けるのは、技術リスクを早く見つけ、本番の契約範囲を具体化するためです。

1. 技術検証：起動時間、認証、DB接続、外部API、負荷、ログ、Native Imageを確認し、継続の条件を決めます。
2. MVP：利用者が使う最小限の機能を、本番相当の監視と権限管理を含めて作る段階。
3. 本番拡張・保守：MVPの結果を踏まえた、請負範囲と保守契約の確定。

見積額だけでなく、失敗を早く見つけられる発注の構造になっているかも確かめます。

RFPと要件整理で書く範囲

RFPは、受託会社に作るものと条件を伝え、同じ前提で提案と見積を得るための資料です。

技術名だけを大きく書くと、各社の想定する業務範囲や品質条件が食い違い、見積を比べられなくなります。

まず業務目的と制約を示し、そのうえで、技術選択の理由と検証事項を分けて書きます。

業務目的と利用条件の整理

RFPに書く条件は、業務、機能、負荷、情報管理の4つに分けて整理します。

• 業務：課題、対象部署、利用者数、利用時間、現行業務、改善KPI。
• 機能：画面、API、帳票、CSV、通知、承認経路、データ保持期間、移行対象。
• 負荷と復旧：月間リクエスト数、ピーク同時利用者、応答時間、復旧目標。
• 情報管理：バックアップと監査ログの要否、データ分類、アクセス権限。

顧客の個人情報や決済情報など、機密性の高い情報を扱う場合は、データ分類と権限をRFPで明示します。

技術要件と非機能要件の分け方

技術環境と品質・運用の条件は分けて記載します。次に、採用する版や担当範囲を提案書で確かめます。

• 技術環境：Micronaut、JavaまたはKotlin、実行環境、DB、コンテナ、クラウド。
• 開発基盤：CI/CD、IaC、外部サービス。
• 更新条件：「最新版」だけでなく採用版と更新方針を示し、4.x系は保守期限と移行条件も確認。
• 非機能要件：可用性、性能、セキュリティ、監視、障害対応、復旧、運用引き継ぎ。
• 運用責任：最小権限、秘密情報、脆弱性、ログ保管、SBOM、復旧テストの担当。

Micronaut Framework 5.0.5は2026年7月16日に公開されました。

5.0.0では70を超えるモジュールを含む刷新が案内されています（出典: Micronaut Framework公式リリース、2026年）。

また、Micronaut Security公式ガイドは、JWT、OAuth 2.0、OpenID Connect、監査機能を案内しています（出典: Micronaut Security公式ガイド、2026年確認）。ただし、機能を備えていることと、安全に運用できることは別です。

RFPに入れる提案会社への質問

提案会社には、技術経験、検証計画、運用体制を質問します。その回答から、実務への対応力を見ます。

• 実務経験：本番運用、Java・Kotlin、クラウド・データ連携、認証・権限・監査ログ。
• 進行と運用：PoC項目、想定リスク、発注者の役割、成果物、保守体制、障害連絡、担当交代。
• 公開事例：匿名化した構成図、担当範囲、運用期間、発生した課題と解決方法。

公開事例が少ない場合は、社名や顧客名の開示を無理に求めず、匿名化した構成と課題解決の説明を求めます。

Micronautのシステム開発を発注してからリリースするまでの進め方

業務境界とデータ所有者を先に決め、認証方式と運用責任も早い段階で決めることが、Micronaut案件の成否を左右します。

発注後は、各段階に成果物と判断基準を置きます。

工程は次の5つです。

• 要件定義：業務の範囲と、段階ごとの責任の決定。
• PoC・基本設計：技術の採用可否の確認と、設計の土台作り。
• 実装・連携：設計に沿った作り込みと、外部システムとの接続。
• テスト・移行：受入の確認と、データの移し替え。
• リリース・保守：本番稼働と、稼働後の運用・修正。

要件定義とPoCでの採用可否の検証

要件定義とPoCでは、まず業務上の責任範囲を決め、そのあとで技術面の採用可否を確かめます。

1. 要件定義：業務フローを画面やAPIに分け、データの登録・参照・更新・削除ごとの責任を決めます。
2. 接続と認証：Micronaut DataのDB接続、Micronaut Securityの認証、外部API、ログ、監視を小さく検証します。
3. 実行性能と互換性：コンテナの起動、負荷、Native Imageで使うライブラリの互換性。

公式事例には、MicronautとGraalVMを使ったAWS Lambdaで、コールドスタートを1.5〜2秒に抑えた例があります（出典: Micronaut公式Caribou成功事例）。ただし、これは個別環境の結果のため、自社の依存ライブラリとデータ量で測って判断します。

設計と実装で同時に進める境界・テスト・運用

業務境界を設計するとともに、テストと運用を再現できる形にして、実装と並行して進めます。

1. 基本設計：サービス境界、API、データモデル、認証・権限、例外処理、リトライ、監査ログ、可観測性を決めます。
2. 分割基準：サービス数を増やすこと自体は目的にせず、業務上の変更単位とデータ所有者で分けます。
3. 実装と成果物：単体・結合・契約テスト、脆弱性スキャン、CI/CD、IaCを用意し、環境構築や設定、秘密情報、障害対応の手順を残します。

テスト・移行・リリース判定それぞれの確認

業務を継続するために必要な確認を、受入、移行、リリースの各段階で行います。

1. 受入テスト：発注者が業務シナリオを確認し、権限外利用、重複登録、API停止、DB障害、タイムアウト、想定を超える負荷を試します。
2. 情報と移行：個人情報がログに出ないことを確認し、件数、文字コード、日付、マスタ対応、移行リハーサル、切り戻しを決めます。
3. リリース判定：性能、セキュリティ、監視、復旧、教育、問い合わせ窓口がそろっているかを見ます。

Micronautのシステム発注費用と相場の考え方

Micronautはオープンソースです。そのため、通常はライセンス購入費が開発費の中心にはなりません。

費用の中心は人件費です。

対象は、要件定義から実装、テストまでの工程のほか、クラウド、移行、運用、脆弱性対応にわたります。

以下の金額は、業務システム全般の相場とMicronaut案件の要素をもとにした、計画上の推定レンジです。個別案件の確定価格ではありません。

PoCから全社基盤までの規模別の開発費

規模別の推定レンジは、機能範囲と期間を合わせて見る必要があります。

• 技術検証・PoC：150万〜500万円、1〜3か月。1〜3本のAPI、認証、DB接続、外部連携、起動時間や負荷を検証。
• 部門向け：500万〜1,500万円、3〜6か月。申請・承認、検索、CSV、権限、外部API1〜3本を想定。
• 複数部門・サービス：1,500万〜5,000万円、6〜12か月が目安。
• 全社基幹・高可用性：5,000万円〜1.5億円超、12〜24か月以上の可能性（出典: 業務システム全般の費用整理およびリサーチノート、2026年）。

金額は、機能数に加えて、連携数と移行データ量によって変わります。ほかにも、権限、可用性、監査の要件が費用を左右します。

24時間運用、DR、地域分散の条件も、費用に影響します。

全社基幹でも標準化の範囲が広ければ、費用が下がることがあります。一方で、小規模でも複雑な決済や厳格なセキュリティが必要なら、費用は上がります。

見積を見るときは、規模の名前だけで判断せず、成果物と前提条件を確かめます。

人月単価と工程配分の見方

初期の試算では、次のような人月単価と工程配分を仮に置く方法があります。

これは業務システム全般の計画上の目安です。ただし、Micronaut、Kotlin、GraalVM、クラウドIaCを同時に扱える人材が必要な場合は、専門性や立ち上がり期間も加味します。そのため、単価や工数が変わる可能性があります（出典: 業務システム全般の費用整理およびリサーチノート、2026年）。

• PM・上級SE：PMは90万〜150万円、上級SEは90万〜110万円程度。
• プログラマー・テスター：プログラマーは50万〜90万円、テスターは45万〜80万円程度。
• 要件定義・設計等：要件定義10〜12%、設計・環境構築22〜24%。
• 実装・テスト：実装48〜50%、テスト15〜17%を初期配分にできます。

PoCを省くと初期の見積は安く見えますが、Native Image非対応のライブラリや認証設計の漏れは本番で見つかり、追加費用になることがあります。

見積書では、PM、設計、実装を分けて書いてもらい、各工程の納品物を確かめます。テストと移行、運用設計と管理費についても、内訳を書いてもらいます。

初期費用と分けて見るクラウド費用と保守費用

保守・運用とクラウド利用料は、初期費用とは別に、条件ごとに見積もります。

AWS Lambdaを採用する場合でも、「サーバーがないから無料」という考え方は取りません。

• 保守費の目安：初期開発費の年15〜25%程度、または月15万〜80万円程度。
• 保守範囲：監視、障害一次対応、脆弱性修正、Micronaut・Java更新、性能改善、追加開発。
• 契約条件：対象時間、対応レベル、復旧目標、窓口、月次報告、更新費用。
• Lambdaの料金要素：リクエスト数、実行時間、メモリ、プロセッサー、Provisioned Concurrency。
• 周辺費用：API Gateway、DB、ログ、転送、無料枠、リージョン、周辺サービス。

AWS公式の料金例では、Lambdaのリクエスト料金は月100万リクエストあたり0.20米ドルです（出典: AWS Lambda公式料金、2026年確認）。請求額は構成によって変わるため、月間リクエスト数、平均実行時間、メモリ、ピーク同時実行数をもとにTCOを比べます。

Micronautの委託先選定と見積比較で見るべきポイント

Micronaut専門会社という看板だけで委託先を決めるのは危険です。委託先には、次の点も必要です。

• 開発言語と基盤：Java・Kotlin、DB、クラウドを扱った経験。
• 認証とデータ連携：本人確認の仕組みと、外部システムとのデータのやり取り。
• テスト：検証の計画と進め方。
• 障害対応：発生時の連絡と復旧の流れ。
• 業務理解：対象業務の内容をどこまで把握しているか。

各社は、公開実績、提案内容、担当者、運用の引き継ぎ、契約条件を同じ基準で比べます。

Micronaut以外の実務経験の確認

候補会社の技術経験と、実際に契約を担う組織の役割を確かめます。

• 本番経験：構成、担当範囲、稼働期間、クラウド、DB、認証方式、障害対応。
• 関連技術：公開事例がなくても、Java・Kotlin、AWS Lambda、Kubernetes、API連携、業務システム運用を確認。
• 実担当者：Micronaut経験を決めつけず、担当メンバーの経験とPoC計画を見ます。
• 技術・基盤会社：Object ComputingやOracleなども候補です。
• 国内SI会社：日本語の業務要件や大規模運用を相談しやすい選択肢。

Micronautの創設やコア開発に関わった企業、Oracle Cloud・Oracle Databaseに強い企業も、候補に含まれます。

基盤ベンダー、コンサルティング会社、請負開発会社では責任範囲が異なります。そのため、知名度より、要件定義から保守まで誰が契約上担当するかを見ます。

前提と成果物をそろえた見積比較

各社には、同じRFP、回答期限、質問事項を渡します。そのうえで、見積の比較では工程ごとの内訳をそろえてもらいます。

• 工程：要件定義、PoC、設計、実装、テスト、移行、教育、リリース、保守。
• 見積条件：人月、単価、期間、成果物、対象外、追加変更の単価。
• 追加確認：「開発一式」「クラウド費込み」の内訳と前提。
• 検証と運用：性能試験、セキュリティ診断、監視、障害対応、CI/CD、IaC。
• 引き渡し：マニュアル、ソースコードとリポジトリ。

データ移行とテストデータは、見積に入っているかを確かめます。ほかの項目は、見積や契約の範囲に含まれているかを見ます。

安い見積がこれらを対象外にしていると、後から費用が発生します。一方で、高い見積には、不要なサービス分割や過剰な可用性が含まれている場合もあります。

金額が変わる条件を提案会社に3つ以上示してもらうと、リスクを比べやすくなります。

面談で確かめる担当体制と引き継ぎ可能性

提案書の内容だけでなく、PMやアーキテクト、開発者、クラウド担当、QA担当と面談して説明を聞きます。速度や軽量性に加えて、認証、監査、障害、移行、費用についても説明できるかを確かめます。

担当者が退職したり契約が終わったりしたあとも、別の会社へ移管できる設計かを見ます。そのため、ソースコードやIaCの引き渡しを契約で確かめ、テスト、監視、文書の引き渡しも契約に入れておきます。

発注前に決める契約・保守・リスク分担

OSSのライセンス費が低いことと、運用責任が軽いことは、別の話として扱います。

契約には、成果物や知的財産権、OSS一覧を含めます。加えて、脆弱性対応や更新、クラウドアカウント、データ保管、再委託、終了時の引き継ぎも、契約で定めます。

口頭の約束を契約書に残すため、法務や情報システム部門と内容を確認します。

成果物・権利・アカウントの帰属の明記

保守や移管のためには、成果物、権利、アカウントの扱いを契約で具体的に書く必要があります。

• 開発成果物：ソースコード、リポジトリ、設計書、API仕様、DB定義、テストコードと結果。
• 運用成果物：IaC、CI/CD・監視設定、運用・障害対応手順、SBOM、OSSライセンス一覧。
• 再現とアカウント：ビルド環境、秘密情報の登録方法、クラウドアカウントの名義、終了時の返還形式。

コードだけでは保守できない場合があります。そのため、環境構築に必要な情報も受け取っておきます。

セキュリティとOSS更新の責任分界

認証、脆弱性対応、更新の担当を決め、契約後も保守できる条件をはっきりさせます。

• 認証とデータ保護：認証基盤、権限、トークン期限、ログのマスキング、秘密鍵、テナント分離。
• 脆弱性対応：影響調査の担当と、回避策や修正版を何営業日以内に出すか、保守契約に記載。
• 更新範囲：Micronaut、Java、依存ライブラリ、コンテナイメージ、OSを一括で扱うか、対象外を設けるか決定。
• 更新手順：定期確認、検証環境、リリース手順、追加費用を定めます。
• 引き継ぎ：文書と自動テストを納品条件にし、特定会社だけが環境を直せる状態を避けます。

Micronaut 5へ更新する場合は、Javaのベースラインやモジュール構成が変わる可能性があります。

よくある質問

発注では、技術の採用可否や費用、委託先、保守責任について質問が寄せられます。よくある疑問に、ここで答えます。

Micronautのシステム開発費用はいくらですか？

技術検証・PoCは150万〜500万円、部門向けは500万〜1,500万円が推定レンジです。複数部門・複数サービスは1,500万〜5,000万円、全社基幹は5,000万円〜1.5億円超です。

金額は、機能数や連携、データ移行、可用性、セキュリティ、運用時間によって変わります。

Micronautを採用したからといって、一律の価格になるわけではありません。

Spring BootではなくMicronautを選ぶべきですか？

Micronautを選ぶか、Spring Bootを選ぶかは、重視する条件と社内の事情で決まります。

• Micronautが候補になる場合：起動時間やメモリ、コンテナ・サーバーレス、コンパイル時処理を重視するとき。
• Spring Bootが適する場合：国内の人材や既存部品、社内の保守経験、移行リスクを考えるとき。
• PoCで比べる項目：自社のAPI、認証、DB、監視、負荷。

判断は性能だけでなく、5年程度の保守体制と総保有コストも含めて行います。

Micronautの開発会社はどのように選べばよいですか？

Micronautの経験だけでなく、Java・Kotlinやクラウド、認証の経験も確かめます。

稼働後の運用まで任せられるかは、データ連携から業務理解までの経験を見て判断します。

• データ連携：連携先とのデータ受け渡しの経験。
• テスト：検証の計画と進め方。
• 監視：稼働後の状態を見る仕組み。
• 障害対応：発生時の連絡と復旧の流れ。
• 業務理解：対象業務の内容をどこまで把握しているか。

同じ条件のRFPを渡し、担当者、PoC計画、見積の前提、納品物、保守、引き継ぎを比べます。

公開実績が少ない場合は、匿名化した構成と課題解決の説明を求めます。そのうえで、PoCで採用可否を検証できる会社を選びます。

OSSなので保守費用はかかりませんか？

OSSでも、開発会社の作業費やクラウド費、監視、脆弱性対応、更新費は無料になりません。

目安としては、保守・運用を初期開発費の年15〜25%程度、または月15万〜80万円程度と仮置きできます。

金額は、対応時間やSLA、対象範囲によって変わります。そのため、Micronaut・Javaの更新、依存ライブラリ、障害対応の担当条件を契約に記載します。

まとめ

Micronautの発注では、「軽量で高速だから安い」と決めつけず、業務範囲や利用者数、APIと連携先を要件に含めます。ほかに次の項目も、要件に入れます。

• 移行：移すデータの量と方法。
• 性能：応答時間や負荷への要求。
• 認証：本人確認と権限の仕組み。
• 監査：監査ログを残すかどうか。
• 運用：稼働後の保守と障害への備え。

要件が未確定なら、準委任でPoCを行います。完成範囲が明確になったら請負を組み合わせます。そうすれば、技術と予算のリスクを分けて管理できます。

発注前に確認する項目

RFPには、業務目的と機能、Micronaut・Javaの版、PoC項目を書きます。加えて、クラウド、非機能要件、成果物、見積前提、保守条件も書きます。

各社の提案は、総額だけでなく、工程と工数で比べます。さらに、ほかの項目も比べます。

• 対象外・追加変更：含まれない作業と、変更が出たときの扱い。
• 担当者：実際に作業する人と、その経験。
• コードとIaC：納品されるソースコードや構成の定義。
• テスト：確認の範囲と、その担当。
• 引き継ぎ：契約の後に、別の会社へ移せるかどうか。

費用レンジは計画上の推定です。自社の要件と検証結果をもとに、見積を更新します。

小さく検証してから本番発注へ進む流れ

本番発注に備えて、社内条件の整理から、検証結果の契約への反映まで進めます。

1. 相談準備：現行業務、利用者数、連携先、データ、希望時期、予算上限、社内の役割を整理します。
2. 会社比較：Micronautの採用を検証できる会社と、運用まで支援できる会社を比べます。
3. 本番準備：PoCの成果を本番RFPと契約に反映し、将来の保守担当者にも説明できる状態にします。

▼全体ガイドの記事
・Micronautのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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