Accessのシステム発注は、業務の目的と既存資産を整理し、要件と受入基準を決めてから、契約と見積もりを比べて進めます。
この流れで進めると、納品後も運用しやすくなります。発注形態から納品後の進行までを順に説明します。全体像はAccessのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・Accessのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Accessのシステム発注・外注の全体像
Access外注には、新規開発のほかに既存Accessの調査・改修があります。Accessの画面は残したまま、データベースだけをSQL ServerやDataverseへ移す方法もあります。
さらに、Access資産を活用したWeb化や、C#などでのフルリプレースもあります。最初に選択肢を並べておくと、Accessを作ること自体が目的になる失敗を防げます。
「何を解決するシステムか」の決定
最初に決めたいのは、「Accessで顧客管理を作る」ことよりも、「二重入力をなくす」といった業務上の目的です。目的が明確であれば、不要な機能を削り、基盤も選びやすくなります。
- 入力を減らす：二重入力をなくし、請求書の作成時間を短縮する狙いです。
- 在庫を把握する：在庫数の正確な管理です。
- Accessを候補にする業務：社内の数名がWindows端末で入力し、定型帳票を印刷する部門業務が該当します。
Access単体に向く案件と向かない案件の区分
利用者が限られ、社内ネットワークで入力・検索・集計・帳票出力を行う業務なら、Access単体や分割データベースが合います。
- 別基盤も検討：複数拠点での常時接続、スマートフォン利用、社外アクセスが必要な場合です。
- 可用性・ログ：厳密な操作ログや高可用性が必要なら、SQL Server、Dataverse、Webシステムも候補です。
Microsoft公式では、Accessのファイルサイズ上限はシステム領域を除いて2GBです。同時ユーザー数は255人、テーブル内のフィールド数も255が上限です（出典: Microsoft Support「Accessの仕様」、2026年確認）。
ただし、この上限は「255人まで安全に使える」という保証ではありません。ネットワーク品質、クエリの重さ、画像データ、同時更新頻度を踏まえ、上限に対して余裕を持たせる必要があります。
Accessのシステム発注形態の選び方
発注形態は、既存資産、必要なスピード、将来の利用範囲で選びます。短期の業務改善と中長期の計画を、一つの表で並べて比べます。
新規開発を一括で依頼する方法
Excelや紙の業務を置き換える場合は、一括委託が分かりやすい方法です。社内に開発経験がなくても進めやすいのが特徴です。
- 委託できる工程：業務ヒアリング、画面・帳票設計、VBA開発、テスト、データ移行、操作説明です。
- 合意の進め方：サンプル帳票や現行Excelを渡し、試作画面を見ながら認識を合わせます。
「全部お任せ」にすると、完成像を確認しないまま進むおそれがあります。特に、入力項目や検索結果の並び、帳票の改ページは、認識の食い違いが生じやすい点です。締め処理や権限のずれも、注意が要る部分です。
既存Accessの調査・改修を依頼する方法
作成者が退職した、VBAの内容が分からない、WindowsやOfficeの更新後に動かない場合は、全面刷新の前に現行Accessを調査します。そのうえで、現行仕様と問題点を一覧にします。
- 確認対象：ACCDB・MDB本体とリンクテーブルです。VBA、マクロ、クエリ、帳票、外部ファイルも含みます。
- 利用環境：利用端末とログイン方法も対象に含めます。
調査を先行する段階契約にすると、不要な作り直しを抑えられます。調査の結果を見て、帳票修正、バックアップ改善、データだけのSQL Server移行、Web化などから、次に進む先を選べます。
既存ファイルに個人情報や機密データが含まれる場合は、複製、返却、削除の方法を秘密保持契約や作業条件に明記しておきます。
Access＋SQL Server・Dataverseへ段階移行する方法
現場が慣れたAccessのフォームや帳票は残し、データの保存先をSQL ServerやDataverseへ移す方法があります。この構成では、Accessをフロントエンド、サーバーやクラウドをバックエンドとして役割を分けます。
- 期待できる運用：データの一元管理、バックアップ、権限管理を行いやすくなり、将来のWeb化も進めやすくなります。
- 候補となる企業：Microsoft 365やPower Platformを使っている企業は、検討しやすい構成です。
MicrosoftはAccessデータをDataverseへ移行する手順を案内しています。既存画面を短期に維持したい一方で、共有フォルダ上の単一ファイル運用に不安がある場合に合います。
移行前には、主キーとリレーションを確認します。非対応データ型と添付ファイルも、移行の前に洗い出しておきます。VBA、権限、ライセンスについても確かめます。
Accessを残すか、Power AppsやWeb画面へ置き換えるかも、ロードマップに入れておきます。
RFPと要件整理の準備範囲
RFPは、委託先に提案と見積もりを依頼するための資料です。完成仕様書まで必要ありませんが、各社が同じ条件で提案できるよう、情報を整理しておきます。
RFPに記載する基本項目
RFPには、背景と目的、対象業務、現状課題を書きます。さらに、希望成果、納期、予算の考え方、既存資産、セキュリティ条件も入れます。ただし、作り込めない部分は、提案事項として残しておきます。
- 業務と利用環境：利用者、拠点、端末、現行業務フロー。
- 機能とデータ：移行対象、画面・帳票、検索・集計条件、権限、外部連携を書きます。
- 運用条件：バックアップ、操作ログ、納品物、希望日程、保守条件。
- 個人情報：種類、保存期間、閲覧者、持ち出し可否、障害時の連絡ルールを明記します。
現場の要望は、業務シナリオの形で示すと伝わりやすくなります。たとえば、電話受注から在庫確認、納期回答、発注書と作業指示書の出力までを一続きに書きます。
通常時だけでなく、取消や返品、分納といった例外も整理します。値引きや締め後の修正、担当者変更も、例外として書き出しておきます。
試作画面と受入基準の先行合意
Accessはフォームや帳票の試作を早く確認できるため、発注前か要件定義の段階で、現場担当者に入力・検索画面や帳票を操作してもらいます。
- 入力と検索：必須入力、重複チェック、権限、検索速度を確かめます。
- 出力と例外：印刷結果と、エラー時の戻り方。
受入基準には、合格となる条件を書きます。たとえば、受注番号検索で3秒以内に表示されること、一般担当者による単価マスタの変更が禁止されることなどです。
月末締め後の伝票は承認者だけが修正できること、旧データの件数と合計金額が移行前後で一致することといった基準も定めておきます。一方で、操作感はサンプル画面や帳票で判定します。
必須・希望・将来構想の区分
すべての要望を初期開発に入れると、費用と納期が膨らみます。そのため、優先度を分けて初期リリースの範囲を決めます。
- 今回必ず必要：顧客・商品マスタ、受注登録、検索、帳票など業務の中核です。
- できれば入れたい：初期費用と納期を見て優先します。
- 将来検討する：ダッシュボードや細かな自動通知は、第2段階に回す考え方です。
優先度は、削減時間や入力ミス件数のほか、法令・監査要件、経営上の締め処理を基準に決めます。また、機能を入れない場合の代替運用も、委託先に提案してもらいます。
Access開発の契約形態（請負と準委任）の使い分け
契約形態は、納品物と責任範囲を左右します。要件が固まり完成機能を定められるか、調査や伴走が必要かで使い分けます。
請負契約（完成物を明確にできる場合）
請負契約では、委託先が合意した成果物を完成させ、発注側がそれを検収します。機能や成果物を決められる新規Access開発であれば、請負が合います。
- 成果物を定める：画面・帳票一覧、処理仕様、移行データ、マニュアル、テスト結果を合意します。
- 変更を管理する：契約後の機能追加に備えて、変更手順を決めておきます。
金額は固定されやすい一方で、追加機能には変更契約や追加費用が発生しやすくなります。
検収は要件定義書と受入テスト仕様書に基づいて行います。そのうえで、権限エラーや重複登録、データ欠損を確認します。印刷崩れやバックアップ復元も、検収の対象に含めます。
検収後の無償修正期間と対象となる不具合、仕様変更との区別も、契約書に記載しておきます。
準委任契約（調査・伴走・段階開発）
作業の進行そのものを委託したい場合は、準委任契約が合います。たとえば、調査や要件整理、現行Accessの解析、プロトタイプ作成、技術支援などが該当します。
現行仕様が不明なときや、関係部署の意見がまとまらないとき、Access単体かWeb化かを判断できないときは、調査フェーズを設けるほうが安全です。
- 費用と体制：稼働時間、担当者、定例会、報告書、成果物、作業上限を確認します。
- 継続判断：月次の作業計画と成果を見て、継続、縮小、請負への切り替えを決めます。
準委任では、作業時間や体制に基づいて費用を計算することが多いものです。そのため、作業範囲の確認も欠かせません。
ソースコード・設計書・保守の権利
運用には、ACCDB・MDB本体のほか、VBAソースやテーブル定義が要ります。さらに、クエリや帳票、外部連携設定、管理者パスワード、バックアップ手順も欠かせません。
- 納品物と権利：何が納品され、発注側がソースを利用・改修できるかを定めます。
- 保守範囲：問い合わせ、障害調査、軽微な改修、更新、復旧、バックアップ確認を分けます。
第三者へ保守を引き継げるかも、明確にしておきます。なお、Access 2016とAccess 2019は2025年10月14日にサポート終了となりました。
Access 2024のサポート終了日は2029年10月9日です（出典: Microsoft Lifecycle、2026年確認）。
古いバージョンに依存する場合は、稼働だけでなく、Office更新や将来移行の費用と期限も確認します。
Accessのシステム外注費用・相場の目安
Access開発費は、業務ルールや帳票、既存データによって変わります。さらに、連携やテスト、教育、保守の範囲でも差が出ます。そのため、公開価格や事例と、編集上の目安を分けて示します。
案件タイプ別の費用レンジ
公開価格例と編集上の目安、公開事例を分けて見ると、案件タイプごとの費用幅をつかめます。
- 公開価格例：調査・小修正は5万円から、小規模新規・改修は20万円から、中〜大規模新規は50万円からです。
- 既存・小規模開発の目安：調査・修正は5万〜50万円、小規模新規開発は20万〜300万円程度です。
- 移行・刷新：部門刷新は300万〜1,000万円、SQL Serverなどは500万〜1,500万円程度です。
- Web化・フルリプレースの目安：1,000万〜3,000万円超になることがあります。
- 公開事例：基幹改修事例の導入費用は450万円。AccessからC#への製造業の移行事例は、プロジェクト規模2人、制作期間3か月です。
公開価格は各社の価格例にすぎず、要件定義、データ移行、複雑な連携、テストを含めた総額を保証するものではありません（出典: Access開発サポート公開価格、2026年確認）。
編集上の目安は、案件条件から算出したレンジです。特定の金額を断定するものではありません。なお、部門刷新は、複数画面・権限・帳票・連携を含む案件です。
基幹改修では、不要機能を削ったうえで、Accessで帳票レイアウト変更機能を実装しました。導入期間は4か月、費用は450万円でした（出典: 株式会社プロズサービス公開事例、2026年確認）。
一方、C#移行事例の金額は公開されていません。そのため、公開されていない金額や期間は推測で補わず、正式な予算は同じRFPで複数社から見積もりを取って決めます。
見積もりに含める費用と別途費用
工程別に費用を示してもらうと、作業範囲や仕様変更の影響を比較できます。特に、「開発一式」とだけ書かれた見積もりでは、範囲が分かりません。
- 開発工程：調査・要件定義、基本設計、画面・帳票、データベース、外部連携です。
- 導入工程：データ整備・移行、テスト、操作説明、リリース支援です。
工程ごとの工数、単価、前提、対象外も確認しておきます。また、ライセンス、SQL Server・Azure・Dataverse利用料、保存、端末更新、ウイルス対策も、別途発生する場合があります。
保守や教育、追加帳票、緊急対応は、費用に含まれるかを確認します。一般的な業務システムでは、保守に初期開発費の年15〜25%程度を見込むことがあります。ただし、これはAccess固有の公的な相場ではありません。
委託先の選定と見積比較で確認すべきポイント
委託先は、Accessを作れるかに加えて、業務理解と運用設計の力で選びます。専門会社、Azureやローコードとの組み合わせ、Web化、C#移行などでは、得意分野が異なります。
自社の課題に近い実績を確認し、同じRFPで2〜3社程度を比べると判断しやすくなります。
Accessの実績と解析力
新規開発だけでなく、既存Accessの解析力も確認します。具体的には、MDBからACCDBへの移行、32bitと64bitの差、VBA・ActiveX、リンクテーブルへの対応力などです。
- 既存資産への対応：壊れた帳票やデータクレンジングまで、扱えるかを見ます。
- 仕様化の力：資料が少なくても、実ファイルとヒアリングから仕様を起こせるかを確認します。
実績は、対象業務と利用者・拠点数で見ます。ほかに確かめたいのは、次の項目です。
- 資産の状態
- 期間
- 移行
- 保守内容
事例の数が多くても、自社に適するとは限りません。
可能であれば、担当予定者が過去案件の設計・開発・導入にどこまで関わったかも確認しておきます。
見積書の前提と範囲の比較
総額の安さだけで決めず、まずは同じ作業範囲かを確認します。移行費用が片方だけ別途になっている場合は、条件をそろえて比較表に戻します。
- 工程と成果物：要件定義から保守まで、工程ごとの成果物を確認します。
- 見積前提：画面・帳票・連携数と、データ移行範囲をそろえます。
- 運用条件：ライセンス、保守受付時間、変更単価、障害時の復旧目標を確認します。
要件定義の時間や打ち合わせの回数、試作、テストデータの準備者も照合します。受入テストの回数と納品物も、あわせて確かめます。
極端に安い場合は、調査、テスト、移行、教育の抜けがないかを確認します。逆に高い場合は、不要な機能や過剰な基盤が含まれていないかを確認します。
セキュリティと属人化リスクへの備え
Accessを共有フォルダに置くだけで運用すると、ファイルの破損や権限の形骸化、バックアップ不足が起きることがあります。さらに、VBAの野良改修や操作履歴の不足も生じることがあります。
- アクセス管理：利用者の識別・認証と、アクセス制御を要件に含めます。
- 安全対策：不正アクセス対策、通信・保存の保護、ログ確認、復旧手順を定めます。
個人情報保護委員会のガイドラインでは、担当者と個人情報データベースの範囲を限定するアクセス制御や、アクセス者の識別・認証が例として挙げられています。
外部からの不正アクセス防止や、ログの定期的な分析も、技術的安全管理措置の例に当たります（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、令和8年6月一部改正）。
Accessを採用するかどうかは、新旧だけで決めず、必要な安全管理措置を実装・運用できるかで判断します。
VBAやパスワードが一人にしか分からない場合は、対策を契約に含めます。具体的には、ソースコードの引き渡し、仕様書の更新、管理者の複数化、操作マニュアルの整備、定期的なバックアップ復元テストが挙げられます。
委託先が変わっても運用を続けられる状態を納品条件にしておくと、特定の外注先に頼りきる状況を減らせます。
発注から納品・保守までの進め方
Accessの発注は、委託先を決めれば終わりではありません。意思決定や現場確認、受入テスト、移行判断が遅れると、開発会社の作業が止まり、納期や費用に影響します。
発注側は、社内責任者と現場代表を決め、いつ何を確認するかを最初に合意しておきます。
調査・要件定義・設計
最初に、現行業務とデータを洗い出します。そのうえで、業務フローやマスタ、コード体系を整理します。さらに、権限や帳票、連携、保存期間も押さえます。
- 既存資産の調査：ファイル構成、リンク先、VBA、マクロ、クエリを調べます。
- 不要機能とエラーの洗い出し：未使用機能とエラーを確かめます。
- 要件と技術の確定：必須機能と将来機能を分け、採用技術、移行・テスト方針、納品物を決めます。
- データ構造の設計：テーブル間の関係と主キーを決め、顧客、商品、受注、受注明細、入金などのデータを分けます。
- 履歴と締め処理の設計：マスタ変更履歴と締め処理を設計します。
この設計は、Excel列の流用による重複や表記ゆれ、更新漏れを防ぐために要ります。
試作・開発・テストでの認識差の解消
重要な画面と帳票は、早い段階で試作します。現場には実データに近いサンプルで確認してもらい、入力順や検索条件、警告文、帳票の見え方を確かめます。
試作の承認後に大きな仕様変更が出た場合は、その扱いを承認記録と変更管理表に残します。
- 単体テストで、各機能を確かめます。
- 結合テストで、画面や機能の組み合わせを確認します。
- 総合テストによる業務全体の確認。
- 利用者による受入テストで、実務上の要件を確かめます。
通常の登録だけでなく、例外もあわせて試します。入力漏れや重複、権限外の操作、締め後の修正が対象です。さらに、移行前後の件数や印刷、バックアップ復元、Office更新後の動作も試します。
移行・教育・保守（運用開始の条件）
移行後の確認から運用開始後の支援までは、順に進めます。
- 移行内容を確認：対象と期間、不要データ、重複や空欄、文字コード、日付形式、コード変換を確かめます。
- 移行結果を照合：件数や金額合計、残高、最新日付、主要マスタ、サンプル帳票を照らし合わせます。
- 切り替えを決める：旧Accessの停止時期、並行稼働日数、切り戻し条件を決めます。
- 利用開始を支援：管理者と一般利用者への説明を分け、問い合わせ先と障害時の一次対応を知らせます。
- 保守条件を決める：納品後30日間の初期サポート、月次保守、更新対応、追加改修の依頼方法を決めます。
よくある質問（FAQ）
発注時は、費用に加えて、既存資産や将来の拡張、契約、保守、セキュリティも確認します。よくある質問に、順に答えます。
Accessのシステム開発は本当に安くできますか？
小規模な部門業務で既存のExcelやAccessを活用し、画面と帳票を絞れば、フルスクラッチの大規模開発より費用を抑えられる可能性があります。
ただし、要件整理や既存VBAの解析、移行、権限、テスト、保守まで含めると、単純な画面作成より高くなります。なお、公開価格と自社案件の総額は分けて考えます。
RFPはAccessの知識がない担当者でも作れますか？
作れます。目的や業務フロー、困りごと、利用者、帳票、データ、希望納期を、分かる範囲で整理します。分からない部分は、提案事項として残します。
現実的なのは、Excelや帳票、Accessファイル、画面キャプチャを添付し、委託先に不足項目を質問してもらう進め方です。
古いAccessをそのまま外注先へ渡しても大丈夫ですか？
秘密保持や複製範囲、保管場所、閲覧者、返却・削除の方法を合意してから渡します。個人情報を含む場合は、匿名化したデータで調査できるかを確認します。
サポート終了版のOfficeを残す場合は、セキュリティと更新計画も委託先に評価してもらいます。
Accessのシステムを最初からWeb化した方がよいですか？
利用者や拠点、社外アクセスの有無で判断します。監査ログや可用性、将来連携も判断材料になります。たとえば、少人数が社内Windows端末で使う帳票中心の業務なら、Accessが合う場合があります。
多拠点、社外利用、モバイル、厳格な監査が必要な場合は、SQL ServerやDataverseを含む構成とWebを比べます。また、Accessで始めて、将来移行できる設計にする方法もあります。
まとめ
Access発注では、まず業務の目的と範囲を決めます。そのうえで、Access単体、新規開発、既存改修、SQL Server・Dataverse連携、Web化を比べます。
RFPでは現状と要件を整理し、必須・希望・将来構想を分けます。
費用は、案件の複雑さや既存資産、移行、テスト、ライセンス、保守によって変わります。見積もりは、工程や成果物、前提、対象外、変更条件をそろえて比べます。
契約では、請負か準委任か、ソースや設計書、検収、障害対応、将来移行を確認します。選ぶときは、利用者やデータ量、拠点、社外利用を見ます。監査や属人化、サポート期限も判断の材料になります。
発注側と委託先が同じ業務シナリオと受入基準で進めれば、認識の違いや運用開始後の追加費用を抑えやすくなります。
▼全体ガイドの記事
・Accessのシステム開発の完全ガイド
▼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を創業。