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

Antを使ったシステムの発注は、現状調査、要件整理、契約と見積もりの比較の順に進みます。最後は、担当者が替わっても再現できる保守につなげることが目的です。

発注形態、RFP、契約、費用、委託先の選定は、業務の状況と開発基盤の状態を見て決める項目です。

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

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

Antのシステムを発注する前の全体像

Apache Antは、Javaのコンパイルやテスト、JAR・WARの作成、サーバーへの配備を自動化するビルドツールです。ただし、業務システムの画面や販売管理のような機能を単独で提供する製品ではありません。

発注側は、既存のJava業務システム全体を頼むのか、build.xmlを含む開発・リリース基盤を頼むのかを切り分けます。

Antは業務システムではなく開発基盤

発注先に伝える範囲は、ビルド資産だけでなく、実行環境と運用手順にも広がります。

• ビルド資産：build.xmlのtarget、JDK、実行環境のJava、依存JAR。
• 実行環境：アプリケーションサーバー、DB、CIジョブ、環境別設定、秘密情報の保管場所。
• 運用手順：デプロイとロールバック。把握しないまま改修すると、本番で再現できない恐れがあります。

Apache公式は2026年4月10日公開のAnt 1.10.17と、実行にJava 8以上が必要と案内しています（出典：Apache Ant公式「Binary Distributions」、2026年）。

古いかどうかは、この情報だけで判断せず、利用中のAnt、JDK、サーバー、ライブラリのサポート状況を発注側が確かめます。

発注目的の分類：保守・CI化・移行・再構築

発注の目的は、業務機能と開発基盤の状態を見て、次の4つに分けられます。

• 保守：既存機能の維持と、障害対応や小規模改修。
• CI化：手作業のビルドやテストをCIに載せ、成果物をそろえる取り組み。
• 段階移行：JDK更新や、AntからMaven・Gradleへの移行を段階的に進めること。
• 再構築：業務機能や基盤まで含めた、クラウド移行と全面的な作り替え。

業務が安定していて、課題がビルドの属人化に限られるなら、Antを続けたままテストとCIを整える選択肢になります。

依存関係を手作業で管理し、JDK更新のたびに大きな修正が必要で、会社の交代も予定しているなら、段階移行を検討します。発注先には、現状調査とテスト補強を先に行う方針と、移行案の両方を求めます。

発注形態の選び方：Ant継続・段階移行・再構築の違い

発注形態は、Antの知識だけでなく、業務機能の維持、開発速度や依存管理の改善、クラウド移行を見て決めます。

費用は、初期見積もりのほか、保守や脆弱性対応、将来の移行まで含めた総額で比べます。

業務が安定している場合のAnt継続と整備

業務の変更が少なく、build.xmlで成果物を作れるなら、Antはすぐに置き換えず、再現性を高めることを優先します。

改善の際は、次の設定と成果物を開発会社に示してもらいます。

• 環境と依存：JDK・Antの版の固定、依存JARの一覧とハッシュの管理。
• テストと計画：単体・結合・主要業務のテストをCIで実行し、現行ビルドを壊さない改善計画。

この進め方は、保守の緊急性が高い場合や、業務停止が難しい基幹システムに適しています。ただし、属人化したtargetや手動で配置したJARを残したままでは、引き継ぎの問題は解消しません。

交代後も再構築できる状態を目指し、納品物にはテストコードやCI設定まで含めます。

MavenやGradleへの段階的な移行

依存管理やビルド時間が課題なら、移行を検討する価値があります。マルチモジュール化や採用難も、移行を考える材料になります。Antには標準の構成がないので、単純な機械変換では終わりません。

1. まず、Antと移行後の成果物が同じ内容になるかを確かめます。
2. 次に、画面・帳票・バッチ・外部連携の回帰テストを整えておきます。
3. 最後に、Antを動かしながら、テストや依存管理から始めてデプロイまで順に置き換えます。

Gradle公式は、既存のbuild.xmlをant.importBuild()で読み込む方法を案内しています。その利用時は、AntのtargetをGradleのタスクとして扱えます（出典：Gradle公式「Migrating Builds From Apache Ant」、2026年参照）。

業務機能の老朽化と再構築の比較

Javaのバージョンアップだけでは解決しない問題が重なるなら、全体の刷新を比較します。たとえば、性能不足や複雑な権限、保守できない外部連携がこれに当たります。さらに、クラウド移行やデータ移行が加わる場合も、比較の対象になります。

• 技術選定：チームのスキルと将来の保守体制を基に、CI/CDや依存管理の扱いを決める。
• 段階切り替え：変更が多い機能からAPI化し、安定したバッチや帳票は一時的に残す。
• 移行条件：データ件数、停止可能時間、並行稼働期間、切り戻し条件の確定。

RFPと要件整理で発注先に伝えるべき項目

RFPは、発注側の希望を伝える資料であり、同じ条件で提案と見積もりを比べるための物差しになります。そのうえで、発注側は、未確定の項目を無理に決めず、確認事項と、提案会社に判断してほしい点を分けて書きます。

業務要件と、ビルド・実行・運用の技術要件は、一つの資料の中でつなげておきます。

現行資産と開発環境の洗い出し

RFPでは、業務の状況と技術資産を分けて洗い出します。

• 業務情報：目的、利用部門・者数、画面・バッチ・帳票・連携数、稼働時間、障害の影響。
• 技術環境：Ant・JDKの版、build.xml、Ivyやlib、JARの入手先。コード管理、CI、サーバー、DB、OS、クラウド。
• 調査の要否：資料が不足するなら現状調査を先に発注し、target依存図、手順、環境差分、依存一覧を作成。
• 運用上の課題：秘密情報の所在、手作業、未テスト領域、保守リスクを記録する。

問題を後から追加費用の理由として示されるのを防ぐため、初回の調査報告と見積もりに反映します。

業務要件と非機能要件の数値目標

要件は、機能の使われ方と運用上の目標を数値で表します。

• 業務機能：利用者、画面・バッチ、頻度、登録・検索・出力データを記す。
• 処理と連携：在庫更新の許容遅延、同時更新、再実行、通知の扱いを決めます。連携先や方式、件数、時刻、再送条件も書き添えます。
• 性能と運用：応答時間、同時利用者数、月間処理件数、稼働率を示します。バックアップ頻度、復旧目標時間・時点、ログ保存期間、監視時間も含めます。
• 試験と目標値：セキュリティ試験の条件を定める。数値が分からないときは、現状を測って目標を提案してもらう。

「高速」「安全」「24時間対応」といった言葉だけでは、会社ごとに解釈が分かれます。

RFPに載せるセキュリティと納品物

RFPには、セキュリティ条件と、引き継ぎに必要な納品物を具体的に書きます。

• 保護要件：認証・認可、最小権限、秘密情報、暗号化の方式を定める。管理者操作、監査ログ、バックアップの扱いも含める。
• 脆弱性対応：JARの入手先と更新の判断者、対応期間、再委託先のアクセス範囲。
• 調達上の確認：IPAの調達資料を参考にする。
• 納品物：ソース、設計書、DB定義、CI設定を納品する。テストコードと結果、依存一覧、運用・切り戻し手順も対象になる。

IPAは2026年2月にガイドブック第2.1版を公開しています。正式名称は「IT製品の調達におけるセキュリティ要件リスト活用ガイドブック」です（出典：IPA公式、2026年2月更新）。

古いJavaシステムでは、とくに脆弱性対応の項目を細かく決めておく必要があります。依存JARの取得元と更新の判断者、脆弱性が見つかったときの対応期間も、RFPに明記しておきます。

公的な調達資料を参考にすると、事故連絡や再委託の管理も、RFPに書き込む項目として挙がります。

Antのシステム開発で選ぶ契約形態と責任分界

契約は、要件の確定度、調査や設計変更の可能性、発注者の管理体制で選びます。

Ant解析や移行方針は不確実性が高いため、成果物と金額を初めから固定すると、追加費用や品質の問題につながります。そこで、工程を分け、契約ごとに成果物と責任範囲を定めます。

準委任契約が向く現状調査と段階的な移行

準委任は、専門家が一定の業務を遂行する契約です。作業中に判断しながら進める工程に適しています。

• 対象工程：build.xml解析、調査、PoC、構成検討、要件定義、継続改善。
• 発注者の役割：業務・情報システムの担当者がレビューし、優先順位と受け入れ条件を決める。
• 成果物：調査報告、課題一覧、移行方針。設計・コードレビュー記録、テスト計画、週次報告、次工程の見積もりも含みます。

作業時間だけでなく、確認事項と判断材料を合意しておくと、担当が替わっても継続しやすくなります。

請負契約が向く、完成範囲と検収条件を固定できる場合

請負は、合意した成果物の完成と検収を目的とする契約で、範囲を固定できる工程に適しています。

• 対象作業：確定済みの機能改修、テスト自動化、移行ツール、範囲を定めた画面開発。
• 仕様と検収：ブラウザや性能、テストの条件を定める。セキュリティ試験、納品物、期限、不適合時の対応も明記する。
• 変更時の扱い：対象と前提を明記し、変更要求票で費用、納期、品質への影響を合意する。
• 追加費用の条件：「一式」の範囲や、軽微な変更の扱い、追加見積もりの承認者を決めておく。

調査後に、手作業、不明なJAR、本番固有の設定が見つかる場合があります。

契約に残す権利・再委託・運用責任

契約では、引き継ぎと運用に必要な条件を、資産から責任分界まで具体的に取り決めます。

• 引き渡し資産：ソース、設計書、API仕様、DB定義を引き渡す。テストコード、CI/CD、IaC、依存一覧、運用手順も対象に入る。
• 利用権とOSS：改修・二次利用の権利、著作権、著作者人格権、第三者ライブラリのライセンスを定める。クラウドアカウントの所有者、表示・改変条件も明記する。
• 再委託先：社名、所在国、担当範囲、コード・本番データへのアクセス、事故連絡、監査可否。
• 責任分界：各社の責任を図で示し、障害や漏えい、返却、削除時の担当を明文化する。

OSSは無料でも、自由に再配布できるとは限りません。また、クラウドを利用しても、アプリや依存JARが自動的に安全になるわけではありません。

Antのシステム開発・保守の費用相場と内訳

Antはオープンソースのため、発注費用の中心はライセンス料ではありません。

実際にかかるのは、コード解析や業務理解、テストです。加えて、依存関係の整理や、Java・ミドルウェアの更新にも人と時間が必要です。

さらに、データ移行やクラウドの扱いが費用に影響します。運用設計やセキュリティも、費用を左右する要素です。

リサーチノートに基づく2026年時点の概算では、build.xml調査、環境再現、簡易文書化は80万〜300万円程度が一つの目安です。

AntビルドのCI化、テスト自動化、脆弱性棚卸しは160万〜600万円程度です。

案件の規模と作業範囲による費用レンジの違い

ここで示す費用と期間は推定の幅で、作業の規模や方式によって異なります。

• 小規模なJava業務機能の新規開発・改修：300万〜1,000万円、3〜6か月。
• 中規模のAnt改修・クラウド移行：1,000万〜3,000万円、6〜12か月。
• AntからMaven・Gradleへの段階移行：800万〜3,000万円、6〜15か月。
• 大規模基幹システムの再構築：3,000万円〜1億円超、12〜24か月超。
• 現状調査・CI化：調査は1〜3か月、CI化は2〜5か月。

これらはAntの公式価格ではなく、機能数や資産の品質、テスト量で変わります。そのほか、外部連携や停止可能時間、セキュリティでも変わります。

たとえば、テスト済みのシステムと、手作業で画面を確認するシステムとでは、回帰テストの工数が異なります。

見積もりは、現状調査、要件定義、設計、実装、テストの工程ごとに分けてもらいます。移行、教育、保守の費用は、別の行に分けて書いてもらいます。

初期費用と分けて考える保守費・クラウド費・更新費

初期開発費と継続費は分けて考え、対応時間や契約範囲も確かめます。

• 運用費：保守、クラウド、監視、バックアップ、ログ。更新、脆弱性調査、障害対応も含まれます。
• 保守の目安：一般的には初期開発費の年15〜25％程度ですが、契約範囲や対応時間によって変わります。
• 特別対応：24時間監視や休日対応、駆け付けを含む場合は、別の体制と費用になることがあります。
• 更新作業：JDKやサーバーの更新を保守に含めるか、JAR対応は調査だけにするか、改修やリリースまで含めるかを決める。
• 追加料金：更新や障害対応が別料金になることがあるため、年間の作業量と単価を確かめます。

委託先の選定と見積比較で確認するポイント

委託先は、知名度やJava対応よりも、Ant資産の読解や環境再現の力を見て選びます。テスト補完や、移行後の保守体制も確認します。

秘密保持契約を結んだあと、発注側はbuild.xmlの一部や構成資料を示し、targetの役割や初回調査の内容を質問します。

実績はJavaの件数より課題との近さ

Java案件の数よりも、自社の技術課題に近い経験と、担当者の理解を確かめます。

• 技術経験：Ant・Ivy解析、JDK更新、サーバー更改、テスト自動化の経験を聞く。CI/CD、クラウド移行、レガシー保守も確かめる。
• 事例の確認：守秘義務に配慮しながら、build.xmlの規模や利用者、移行期間、テスト方法、保守体制を聞く。
• 担当者面談：予定PMやJava・インフラ担当、テスト責任者に参加してもらう。

「AntをGradleに変えれば解決する」と急ぐ会社より、成果物の再現や依存関係、テストの有無を確かめる会社のほうが信頼しやすいです。さらに、業務停止の制約を伝え、継続・移行・再構築の違いを比べます。

見積もりの前提と範囲をそろえた比較

各社の見積もりは、同じ形式にそろえてから比べます。

• 工程：調査、要件定義、設計、実装、各テスト。移行、リリース、教育、保守も別に記載します。
• 機能範囲：画面、バッチ、帳票、連携を範囲に含める。データ移行、CI、監視、セキュリティ試験も対象に入れる。
• 見積条件：単価、人月・人日、人数、期間、前提、除外項目を並べてもらう。

公的資料では、工程や機能別の単価を示し、「一式」を避けて、同一仕様で複数社に依頼する考え方を示しています（出典：事業再構築補助金「システム構築費を計上する際の注意点」、2025年公開）。

ただし、すべての民間発注に同じ要件が当てはまるわけではありません。工程と機能を分ける方法は、参考になります。

安すぎる見積もりで抜けている作業

安い提案が悪いとは限りません。また、高い見積もりも理由が明確なら妥当です。

• 含まれる作業：調査、テスト、移行、文書、セキュリティが入っているか、保守が外されていないかを確かめる。
• 発注者側の前提：build.xml解析、JAR整理、受け入れテストを自社が担う想定になっていないかを見る。
• 別料金と工数：クラウド費やライセンス費を除いた前提でないかを見る。テスト不足、複数サーバー移行、データ変換、並行稼働は工数に影響します。
• 価格差：各社に同じ質問をして、人数・期間・範囲・品質条件のどこで差が出るかを見極める。

発注側は、価格だけでなくリスクも含めて選びます。

よくある質問

発注時によく出る疑問を、技術選定や既存資産、費用、責任分界の判断材料として取り上げます。

Antを使っているシステムは古いので、すぐ移行すべきですか？

すぐに移行すべきとは限りません。業務が安定していて、AntとJDKを安全に保てるなら、まずはテストや依存ライブラリ、CI、文書を整えます。そのうえで、移行の効果とリスクを比べます。

人材の確保や脆弱性が課題になる場合は、段階移行や再構築を検討します。再現性やJDK更新の問題も、判断の材料になります。

Antのシステム開発は最低いくらから発注できますか？

一律の最低価格はありません。調査、環境再現、簡易文書化は80万〜300万円程度の推定です。

CI化・テスト自動化・脆弱性棚卸しは160万〜600万円、小規模改修は300万〜1,000万円程度です。

対象や資料、テスト量、外部連携で変わるため、要件を伝えて個別の見積もりを依頼します。

Java開発会社ならAntのシステムを任せられますか？

Java開発会社でも、Ant資産を扱えるとは限りません。build.xml、Ivyやlib、JDKの経験を確かめます。

Ivyやlibディレクトリ、利用中のJDK、CIの経験を聞きます。さらに、アプリケーションサーバーの経験も聞き、調査から保守までの体制を確かめます。

社名にAntが含まれていても、Apache Antへの対応力があるとは限りません。面談と提案で判断します。

まとめ

発注では、Antと業務システムを混同せず、既存環境を洗い出します。対象は、build.xmlやJDK、依存ライブラリのほか、テストやCIにも及びます。

サーバーとデプロイも確かめ、継続、段階移行、再構築の選択を、保守体制と事業計画から判断します。

RFP・契約・見積もりでそろえる発注条件

RFPには、現行資産や業務要件、性能、セキュリティを記載します。移行や納品物、保守範囲も書き込みます。

調査や要件定義は準委任、範囲が固まった開発や移行ツールは請負にするなど、工程に合わせて選びます。

見積もりは工程や機能ごとに分け、単価や人数、期間、除外項目をそろえて、同じ条件で比べます。

最初に行う現状調査と再現可能なビルド

発注前は、現状と候補会社を次の順で確かめます。

1. 現行環境で成果物を作れるか、主要業務をテストできるかを確かめ、JARの出所と脆弱性も調べます。
2. 候補会社には、担当者や調査方法、テスト方針、移行基準、納品物、保守体制を示してもらいます。
3. 開発費に加えて、引き継ぎやすさや更新性、障害時の責任分界を比べます。

これらを比べておくと、発注後の追加費用や属人化を抑えやすくなります。

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

▼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を創業。