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

Accessのシステムを発注・外注するなら、まずAccessで作る範囲と将来の移行先を決め、業務・データ・利用者数を整理してから、複数社へ同じ条件で見積もりを依頼することが重要です。

「担当者が退職して既存ファイルを直せない」「Excel管理から移行したい」「Accessのシステムを新しく作りたいものの、どの会社へ依頼すればよいか分からない」と悩む企業は少なくありません。この記事では、発注形態の選び方、RFPと要件整理、請負・準委任などの契約形態、費用相場、委託先の選定、見積比較、納品後の保守までを、Accessのシステム発注・外注の実務に沿って解説します。

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

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や紙で管理している業務をAccessのシステムに置き換えるなら、新規開発の一括委託が分かりやすい方法です。業務ヒアリング、画面・帳票の設計、VBA開発、テスト、データ移行、操作説明まで一つの会社に任せられるため、社内に開発経験がない場合でも進めやすくなります。

ただし「全部お任せ」にすると、発注側が完成イメージを確認できないまま進む危険があります。特に入力項目、検索結果の並び、帳票の改ページ、締め処理、権限の違いは、担当者の頭の中にある「当たり前」と委託先の理解がずれやすい部分です。サンプル帳票や現行Excelを渡し、試作画面を見ながら合意する進め方が適しています。

作成者が退職した、VBAの内容が分からない、WindowsやOfficeの更新後に動かないという場合は、いきなり全面刷新せず、まず現行Accessの調査を依頼します。ACCDB・MDB本体、リンクテーブル、VBA、マクロ、クエリ、帳票、外部ファイル、利用端末、ログイン方法を確認し、現行仕様と問題点を一覧化します。

調査だけを先に発注する段階契約にすると、不要な作り直しを抑えられます。調査結果で「帳票の修正とバックアップ改善で足りる」「データだけSQL Serverへ移す」「属人化が大きくWeb化する」と分岐できるためです。既存ファイルを渡す際は、個人情報や機密データの取り扱い、複製・返却・削除の方法を秘密保持契約や作業条件に明記します。

現場が慣れたAccessのフォームや帳票を残しながら、データの保存先をSQL ServerやDataverseへ移す方法もあります。Accessをフロントエンド、サーバーやクラウドをバックエンドに分けることで、データの一元管理、バックアップ、権限管理、将来のWeb化を進めやすくなります。MicrosoftはAccessデータをDataverseへ移行する手順を案内しているため、Microsoft 365やPower Platformを使う企業では候補にしやすい構成です。

この形態は、既存画面を短期に維持したい一方で、共有フォルダ上の単一ファイル運用に不安がある場合に向きます。ただし、主キー、リレーション、非対応データ型、添付ファイル、VBA、権限、ライセンスを事前に確認します。移行後もAccessを残すのか、Power AppsやWeb画面へ置き換えるのかをロードマップにしておくと、二重投資を防げます。

RFPと要件整理はどこまで準備してから依頼しますか？

RFPは、委託先に提案と見積もりを依頼するための資料です。完成した仕様書でなくても問題ありませんが、背景、目的、対象業務、現状の課題、希望する成果、納期、予算の考え方、既存資産、セキュリティ条件を同じ形式で整理します。発注側が作り込めない部分は「提案してほしい事項」として残し、各社の提案力を比較できるようにします。

最低限、会社情報と対象業務、利用者・拠点・端末、現行業務フロー、移行対象データ、必要な画面と帳票、検索・集計条件、権限、外部連携、バックアップ、操作ログ、納品物、希望スケジュール、保守条件を記載します。顧客・従業員・取引先の個人情報を扱う場合は、その種類、保存期間、閲覧者、持ち出しの可否、障害時の連絡ルールも明記します。

現場の声は、単なる要望リストではなく業務シナリオで示します。例えば「受注登録」だけでなく、「電話で受注を受け、在庫を確認し、納期を回答し、受注確定後に発注書と作業指示書を出す」という流れです。通常時だけでなく、取消、返品、分納、値引き、締め後の修正、担当者変更などの例外も整理します。

Accessはフォームや帳票の試作を早く確認しやすい点が強みです。発注前または要件定義の段階で、重要な入力画面、検索画面、帳票のサンプルを見せてもらい、現場担当者が操作します。画面の見た目だけでなく、必須入力、重複チェック、権限、検索速度、印刷結果、エラー時の戻り方まで確認します。

受入基準には「何ができれば合格か」を書きます。例えば「受注番号で検索すると3秒以内に結果を表示する」「一般担当者は単価マスタを変更できない」「月末締め後の伝票は承認者だけが修正できる」「旧データの件数と合計金額が移行前後で一致する」といった基準です。数値化できない操作感も、サンプル画面や帳票を添付して判定できる状態にします。

要望をすべて初期開発に入れると、費用と納期が膨らみます。「今回必ず必要」「できれば入れたい」「将来検討する」の3段階に分け、初期リリースの範囲を決めます。顧客マスタ、商品マスタ、受注登録、検索、帳票など業務を止めない中核機能を優先し、ダッシュボードや細かな自動通知は第2段階に回す考え方です。

優先順位は、現場の好みだけでなく、削減したい時間、入力ミスの発生件数、法令・監査上の必須条件、経営上の締め処理を基準に決めます。委託先から「その機能を入れない場合の代替運用」も提案してもらうと、予算内に収める判断がしやすくなります。

Access開発の契約形態は請負と準委任をどう使い分けますか？

契約形態は、納品物と責任範囲を左右します。要件が固まり、完成させる機能・品質・期限を定義できる部分は請負契約、調査や要件整理など作業内容が変わりやすい部分は準委任契約が候補になります。名称だけでなく、成果物、検収条件、変更手続き、瑕疵や不具合への対応を契約書で確認します。

請負契約では、委託先が合意した成果物を完成させ、発注側が検収する流れになります。新規のAccessのシステムで、画面一覧、帳票一覧、処理仕様、移行データ、マニュアル、テスト結果などを確定できる場合に向いています。見積もり金額が固定されやすい一方、契約後に機能を追加すると変更契約や追加費用が発生しやすいため、変更管理の手順を先に決めます。

検収では、完成したかどうかを主観で判断しないことが大切です。要件定義書と受入テスト仕様書を基準に、正常系だけでなく権限エラー、重複登録、データ欠損、印刷崩れ、バックアップ復元などを確認します。検収後の無償修正期間、対象となる不具合、仕様変更との区別も契約書に記載します。

準委任契約は、調査、要件整理、現行Accessの解析、プロトタイプ作成、技術支援など、作業の進行そのものを委託する場合に向きます。現行仕様が不明、関係部署の意見がまとまっていない、Access単体かWeb化かを判断できない場合は、最初から完成物を固定するより、調査フェーズを設ける方が安全です。

準委任では、作業時間や体制に基づいて費用を計算することが多いため、稼働時間、担当者、定例会、報告書、成果物、作業上限を確認します。「準委任だから何をしてもよい」わけではありません。月次の作業計画と成果確認を行い、継続・縮小・請負への切り替えを判断できるようにします。

Accessのシステムでは、ACCDBやMDB本体だけでなく、VBAのソース、テーブル定義、クエリ、帳票、外部連携の設定、管理者パスワード、バックアップ手順が運用の生命線になります。納品物に何が含まれるか、ソースコードを発注側が利用・改修できるか、第三者へ保守を引き継げるかを明確にします。

保守契約には、問い合わせ対応、障害調査、軽微な改修、バージョンアップ、データ復旧、定期バックアップ確認を分けて記載します。Access 2016とAccess 2019は2025年10月14日にサポート終了となり、Access 2024のサポート終了日は2029年10月9日です（出典: Microsoft Lifecycle、2026年確認）。古いバージョンに依存するシステムを外注する際は、動かすだけでなく、Office更新や将来移行の費用と期限まで確認します。

Accessのシステム外注費用・相場はどのくらいですか？

Accessのシステム開発費は、画面数だけでなく、業務ルールの複雑さ、帳票、既存データの状態、外部連携、テスト、教育、保守によって変わります。ここでは、公開価格・公開事例と、業務システム一般相場を基にした編集上の目安を分けて示します。正式な予算は、同じRFPで複数社から見積もりを取得して決めます。

既存Accessの調査や小規模修正は、公開価格例では5万円からです。小規模な新規開発や改修・機能追加は20万円から、公開価格上の中〜大規模な新規開発は50万円からとされています（出典: Access開発サポート公開価格、2026年確認）。ただし、これは各社の公開価格例であり、要件定義、データ移行、複雑な連携、テストを含めた総額を保証するものではありません。

本ノートの公開情報と業務システム一般相場を組み合わせた編集上の目安では、既存Accessの調査・小規模修正は5万〜50万円程度、小規模な新規Access開発は20万〜300万円程度、複数画面・権限・帳票・連携を含む部門向け刷新は300万〜1,000万円程度です。Access＋SQL ServerやDataverseは500万〜1,500万円程度、Web化やフルリプレースは1,000万〜3,000万円超になることがあります。いずれも案件条件から算出したレンジで、特定金額を断定するものではありません。

公開事例では、基幹システム改修に2,000万円以上の見積もりが出た案件で、不要な機能を削り、Accessで帳票レイアウトの変更機能を実装し、4か月・450万円で導入した例があります（出典: 株式会社プロズサービス公開事例、2026年確認）。一方、AccessをC#へフルリプレースした製造業事例では、プロジェクト規模2人、制作期間3か月と公表されていますが、金額は公開されていません。期間や金額が公開されていない部分を推測して補わないことが大切です。

見積書では、要件定義・現状調査、基本設計、画面と帳票の開発、データベース設計、外部連携、データクレンジングと移行、テスト、操作説明、リリース支援を分けて記載してもらいます。「開発一式」だけでは、どこまで対応するか、仕様変更で何が増えるかを比較できません。工程ごとの工数、単価、前提条件、対象外を確認します。

初期費用とは別に、AccessやMicrosoft 365のライセンス、SQL Server・Azure・Dataverseの利用料、バックアップ保存、端末更新、ウイルス対策、保守、教育、追加帳票、障害時の緊急対応が発生することがあります。保守費用は一般的な業務システムでは初期開発費の年15〜25%程度を目安に置くことがありますが、Access固有の公的な相場ではありません。契約内容と対応時間を基に確認します。

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

委託先は、Accessを作れるかだけでなく、業務を理解して将来の運用まで設計できるかで選びます。Access専門会社、AccessとAzureやローコードを組み合わせる会社、Access資産のWeb化を得意とする会社、C#などへの移行を得意とする会社では、提案の方向性が異なります。自社の課題に近い実績を確認し、同じRFPで2〜3社程度を比較すると判断しやすくなります。

新規開発の実績だけでなく、既存Accessの解析、MDBからACCDBへの移行、32bitと64bitの差、VBAやActiveX、リンクテーブル、壊れた帳票、データクレンジングに対応できるかを聞きます。作成者が不在のシステムでは、資料が少ないことを前提に、実ファイルとヒアリングから仕様を起こす力が必要です。

実績を確認するときは、会社名の一覧だけでなく、対象業務、利用者数、拠点数、既存資産の状態、開発期間、移行方法、導入後の保守内容を確認します。公開事例の数が多いことと、自社の案件に適していることは同じではありません。可能であれば、担当予定者が過去案件でどこまで設計・開発・導入に関わったかも確認します。

見積比較では、総額が安い会社をすぐに選びません。要件定義、設計、開発、テスト、移行、教育、保守の各項目が揃っているか、画面・帳票・連携の数が同じか、データ移行の作業範囲が同じかを確認します。片方が移行費用を含み、もう片方が別途なら、比較表に戻して同じ条件へ揃えます。

特に確認したいのは、要件定義の時間、打ち合わせ回数、試作の有無、テストデータの準備者、受入テストの回数、納品物、ライセンス費、保守の受付時間、仕様変更の単価、障害時の復旧目標です。見積もりが極端に安い場合は、調査・テスト・移行・教育のどれかが抜けていないかを確認します。極端に高い場合は、不要な機能や過剰な基盤が含まれていないかを確認します。

Accessのシステムを共有フォルダに置くだけで運用すると、ファイル破損、権限の形骸化、バックアップ不足、VBAの野良改修、操作履歴の不足が起きることがあります。個人データを扱う場合は、利用者の識別と認証、アクセス制御、外部からの不正アクセス対策、通信や保存の保護、ログの確認、復旧手順を要件に含めます。

個人情報保護委員会のガイドラインでは、担当者と個人情報データベースの範囲を限定するアクセス制御、アクセス者の識別・認証、外部からの不正アクセス防止、ログの定期的な分析などが技術的安全管理措置の例として示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、令和8年6月一部改正）。Accessを採用できるかどうかを「古いか新しいか」だけで判断せず、必要な安全管理措置を実装・運用できるかで判断します。

作成者一人にしか分からないVBAやパスワードが残る場合は、ソースコードの引き渡し、仕様書の更新、管理者の複数化、操作マニュアル、定期的なバックアップ復元テストを契約に含めます。委託先が変わっても運用できる状態を納品条件にすると、外注先への過度な依存を減らせます。

発注から納品・保守までの進め方

Accessのシステム発注は、会社を決めて終わりではありません。発注側の意思決定、現場確認、受入テスト、移行判断が遅れると、開発会社の作業が止まり、納期や費用に影響します。社内の責任者と現場代表を決め、いつ何を確認するかを最初に合意します。

最初に現行業務とデータを棚卸しし、業務フロー、マスタ、コード体系、権限、帳票、外部連携、保存期間を整理します。既存Accessがある場合は、ファイル構成、リンク先、VBA、マクロ、クエリ、未使用機能、エラー箇所を調査します。その後、必須機能と将来機能を分け、採用技術、移行方針、テスト方針、納品物を確定します。

設計では、テーブル間の関係と主キーを先に決めます。Excelの列をそのままテーブルにすると、顧客名や商品名の重複、表記ゆれ、更新漏れが起きやすくなります。顧客、商品、受注、受注明細、入金などのデータを適切に分け、マスタ変更の履歴や締め処理の扱いまで設計します。

重要な画面と帳票は、開発の早い段階で試作を確認します。現場担当者が実際のデータに近いサンプルを使い、入力順、検索条件、警告文、帳票の見え方を確認します。試作を承認した後で大きな仕様変更が出た場合の扱いも、承認記録と変更管理表で残します。

テストは、単体テスト、画面や機能を組み合わせる結合テスト、業務全体を確認する総合テスト、利用者が行う受入テストに分けます。通常の登録だけでなく、入力漏れ、重複、権限外操作、締め後修正、データ移行前後の件数、帳票印刷、バックアップからの復元、Office更新後の動作も確認します。

データ移行では、移行対象、対象期間、不要データ、重複、空欄、文字コード、日付形式、コード変換を確認します。移行後は、レコード件数だけでなく、金額の合計、残高、最新日付、主要マスタ、サンプル帳票を照合します。旧Accessをいつ停止するか、並行稼働を何日行うか、切り戻し条件は何かも決めます。

導入時には、管理者向けと一般利用者向けの操作説明を分け、問い合わせ先と障害時の一次対応を知らせます。納品後30日間の初期サポート、月次保守、バージョンアップ対応、追加改修の依頼方法を整理しておくと、運用開始後に「誰へ何を頼めばよいか分からない」状態を防げます。

よくある質問（FAQ）

Accessのシステムを発注する際は、費用だけでなく、既存資産の扱い、将来の拡張、契約、保守、セキュリティを同時に確認する必要があります。ここでは、発注前によく寄せられる質問に直接回答します。

小規模な部門業務で、既存のExcelやAccess資産を活用し、必要な画面と帳票に絞れば、フルスクラッチの大規模開発より費用を抑えられる可能性があります。ただし、要件整理、既存VBAの解析、データ移行、権限、テスト、保守まで含めると、単純な画面作成より高くなります。公開価格のレンジと自社案件の総額は分けて考えます。

作れます。目的、現状の業務フロー、困っている点、利用者、帳票、データ、希望納期を分かる範囲で整理し、「提案してほしい事項」を残せば十分に依頼できます。既存のExcel、帳票、Accessファイル、画面キャプチャを添付し、委託先から不足項目を質問してもらう進め方が現実的です。

秘密保持、データの複製範囲、保管場所、アクセスできる担当者、返却・削除の方法を合意してから渡します。個人情報を含む場合は、実データではなく匿名化したテストデータで調査できるかも確認します。古いAccessを動かすためにサポート終了版のOfficeを残す場合は、セキュリティと更新計画を含めて委託先に評価してもらいます。

利用者、拠点、社外アクセス、スマートフォン、監査ログ、可用性、将来の連携要件によって判断します。社内の少人数がWindows端末で使う帳票中心の業務ならAccessが適する場合がありますが、多拠点・社外利用・モバイル・厳格な監査が必要なら、SQL ServerやDataverseを含むハイブリッド構成、またはWebシステムを比較します。最初にAccessで小さく始め、将来移行できるデータ設計にする方法もあります。

まとめ

Accessのシステムを発注・外注するときは、最初に業務上の目的と対象範囲を決め、Access単体、新規開発、既存改修、SQL Server・Dataverseとの組み合わせ、Web化を比較します。RFPには現状業務、利用者、データ、画面、帳票、権限、連携、移行、テスト、保守を記載し、必須・希望・将来構想を分けます。

費用は公開価格や事例を参考にできますが、案件の複雑さ、既存資産の解析、データ移行、テスト、ライセンス、保守によって変わります。見積もりは総額だけでなく、工程・成果物・前提・対象外・変更条件を揃えて比較し、契約では請負か準委任か、ソースコードや設計書の扱い、検収、障害対応、将来の移行方針を確認します。

「Accessは古いから使えない」「Accessなら必ず安い」と一律に決めるのではなく、利用者数、データ量、拠点、社外利用、監査、属人化、サポート期限を基準に選ぶことが成功への近道です。発注側と委託先が同じ業務シナリオと受入基準を見ながら進めれば、納品直前の認識違いや、運用開始後の追加費用を抑えやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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