7月 22, 2026 タッチポイントWeb編集部

エクセルマクロ・VBA開発の外注費用相場｜フリーランスに直接依頼する前に決める7つのこと

エクセルマクロ・VBA開発を外注する場合の費用は、要件定義がほぼ不要なシンプルな自動化で3万〜10万円程度、要件定義から必要な業務ツール規模で10万〜100万円程度。これが複数の開発会社・マッチングサービスのサイトで共通して示されている目安です。ただし、この記事でいちばん伝えたいのは金額そのものではありません。毎月の集計や転記に半日を取られている状況を変えるうえで、発注前に決めておくべきなのは「作ったあと、誰がそれを直すのか」です。

エクセルマクロ・VBA開発の外注費用相場（複雑さ別）

最初に前提をひとつ。以下に挙げる金額は、政府や業界団体が公表している公的統計ではありません。開発会社やマッチングサービスが自社サイトで公表している目安を横断的に集めたものです。実際の見積もりは要件によって大きく動くため、ピンポイントの数値ではなく幅として捉えてください。

なお用語を一言だけ整理しておくと、マクロはエクセルの操作を自動化する機能そのもの、VBA（Visual Basic for Applications）はそのマクロを記述するためのプログラミング言語を指します。

シンプルな自動化なら3万〜10万円程度

既存ファイルの関数修正、シート間の単純な転記、決まったフォーマットへの変換、月次集計の自動化。こうした要件定義や設計をほとんど挟まずに済む範囲が、この価格帯にあたります。開発期間の目安は1週間程度とされることが多いようです。

金額の提示にはサイトごとに幅があります。発注ラウンジとエッジワークは3万〜10万円、ランサーズとPRONIアイミツは5万〜10万円を挙げています。下限が2万円ほどずれているのは、どこからを「シンプル」と呼ぶかの線引きが各社で違うためです。

クラウドソーシング上では、軽微な改修が数千円台から募集されている水準も確認できます（出典: フォスターネット）。安く頼めること自体は悪いことではありません。ただし、後述する「その後どうするか」の問題とセットで考える必要があります。

要件定義から必要な業務ツール規模は10万〜100万円程度

複数シート・複数画面をまたぐもの、データベースや基幹システムと連携するもの、複数人での同時利用を前提にしたもの。ここまで来ると開発期間は1〜3ヶ月以上に伸びます。

ランサーズは複雑な仕様（要件定義から必要・開発期間3ヶ月以上）で10万〜100万円、発注ラウンジとエッジワークは複雑なマクロ・業務ツールで30万〜100万円程度としています。用途別では、自動集計ツールが5万〜10万円、在庫管理システムが20万〜30万円という目安も示されています（出典: PRONIアイミツ）。

同じ「マクロ作成」という言葉でも、金額が10倍以上動く領域だということが見て取れます。

見積もりが固定額・時間単価・月額で分かれる理由

相場を調べていると、金額がバラバラで比較にならないと感じることがあります。原因の多くは、そもそも売っているものの単位が違うことにあります。見積もりの形態は大きく3つに分かれます。

固定額（機能単位）は、作るものが決まっている場合に向きます。「この集計を自動化する」と要件を言い切れるなら、総額が先に確定するこの形が予算を組みやすい。相場記事で目にする金額の大半はこの形態です。

時間単価は、要件が固まりきらず、走りながら決めていく場合に向きます。時間7,500円という提示例が紹介されています（出典: PRONIアイミツ）。使ってみて調整を繰り返す前提の依頼では、固定額よりこちらのほうが結果的に無駄が出にくいこともあります。

月額・BPO型は、開発ではなく作業そのものを継続的に外に出す形態です。月額10万円前後からのプランが複数のサービスで公表されています（出典: bee-plus）。自動化ではなく人手による代行なので、VBA開発とは別の選択肢として並べて考えるものです。

自分の依頼がどれに当てはまるかを先に決めておくと、相見積もりの比較がかなり楽になります。

同じ「マクロ作成」でも費用が10倍変わる4つの要因

相場表を見ても自分の案件がどこに入るのか分からない、という状態を解消するために、金額を左右する主な要因を挙げます。フリーランスのVBAエンジニアが単価差の要因を解説している動画でも、要件定義の有無とデータベース連携の有無が大きいと指摘されており、発注側の実感ともおおむね一致します。

ひとつめは、要件が整理されているか。作業手順書、現在使っているエクセルファイル、想定される例外パターン。これらを渡せる状態なら、依頼を受ける側は設計にかける時間を圧縮できます。逆に「とにかく効率化したい」からのスタートだと、要件を固める工程が丸ごと見積もりに乗ります。

ふたつめは、外部データとの連携があるか。ファイル内で完結する処理と、基幹システムからのCSV取り込みやWeb上のデータ取得を含む処理では、必要な作り込みが変わります。

みっつめは、使う人が自分ひとりか、複数部署か。自分だけが使うなら操作手順を守れば動きますが、複数人が使うツールは、想定外の入力や操作ミスを前提にしたエラー処理と入力チェックが必要になります。この作り込み量が費用に直結します。

よっつめは、納品後の修正対応が見積もりに含まれているか。同じ金額でも、納品して終わりなのか、一定期間の不具合対応まで含むのかで意味がまったく違います。この点は後半で詳しく扱います。

そもそも自動化すべきか？費用対効果とVBA以外の選択肢

回収期間を計算してから相談する

外注費が高いか安いかは、単体では判断できません。判断できるのは、削減できる時間と比べたときです。計算は単純です。

月にかかっている作業時間 × 想定時給＝毎月の削減額
外注費 ÷ 毎月の削減額＝回収にかかる月数

たとえば月10時間の集計作業があり、時給2,000円で換算すると月2万円相当。外注費が10万円なら5ヶ月で回収できる計算になります。この数字はあくまで計算方法の見本であり、相場を示すものではありません。自社の実際の作業時間と人件費を入れて計算してください。

この試算は、上司や経営者に費用を説明するときの材料としてもそのまま使えます。「便利になるから」ではなく「何ヶ月で元が取れるか」で話すほうが、稟議は通りやすい。

補足として、中小企業のデジタル化は入口の段階で止まっている会社がまだ多い状況です。中小企業庁の2025年版中小企業白書によると、デジタル化に「まったく取り組んでいない」段階の企業は2023年の30.8%から2024年に12.5%へ急減した一方、業務効率化に取り組む段階にある企業は26.9%にとどまっています（出典: 中小企業庁 2025年版中小企業白書）。何かを始めた会社は増えたものの、実務の効率化まで届いている会社はまだ4社に1社ほど、という読み方ができます。

VBAが最適解とは限らない（GAS・クラウドツール・業務システム化）

Excel VBAが向くのは、既存のエクセルファイルと業務フローをそのまま活かしたい場合、社内で完結する処理の場合、扱うデータ量がそれほど大きくない場合です。

一方で、Googleスプレッドシート中心の運用ならGAS（Google Apps Script）のほうが素直に組めます。複数人が同時に触る、変更履歴を残したいといった要件なら、クラウド型の業務ツールを検討する価値があります。業務そのものを設計し直す段階なら、エクセルの延長ではなく業務システム化のほうが結果的に安く済むこともあります。

もうひとつ、VBAはOfficeのバージョンやPC環境に依存する技術です。会社のPC入れ替えやOfficeの更新をきっかけに動かなくなる可能性があることは、頭の片隅に置いておいてください。

最初から「VBAで作ってください」と決め打ちして相談すると、より安く済む方法や、より長く使える方法を提案してもらう機会を自分から閉じてしまうことがあります。相談の入口は、手段ではなく困りごとから始めるほうが得です。

開発会社・クラウドソーシング・フリーランスへの直接依頼、価格の内訳はどう違うか

同じ金額でも、誰にいくら渡っているかが違う

依頼先によって金額が変わるのは事実ですが、その差は品質差ではなく、価格に何が含まれているかの差です。

開発会社に依頼した場合、見積もりには実装者の作業費だけでなく、営業、ディレクション、テスト体制、保守窓口の人件費が含まれます。担当者が異動しても退職しても窓口が引き継がれる。つまり、体制そのものを買っていることになります。基幹業務に関わるツールや、社内の複数部署が使うシステムでは、この体制にお金を払う意味は大きい。

クラウドソーシングでは、サービス利用料や手数料が価格に内包されます。募集から契約、支払い、トラブル時の運営対応までの仕組みを含んだ価格です。発注に慣れていない場合、この仕組みがあること自体が安心材料になります。

フリーランスへの直接依頼では、作業する本人に支払う金額がそのまま費用になります。ランサーズの記事でも、フリーランスへの発注は開発会社と比べて同等クオリティを2分の1〜3分の2程度の費用で依頼できる可能性があると指摘されています（出典: ランサーズ発注者向けノウハウ）。

どれが優れているという話ではありません。必要な体制を必要なだけ買うのが合理的です。そのうえで、直接依頼の実質的な利点は安さよりも、実際に作る本人と直接話せることにあります。伝言を挟まない分、要件のすり合わせが速く、「そこは、こうしたほうが運用が楽になりませんか」といった提案がその場で返ってきます。

個人に直接頼むときのデメリットも正直に見ておく

直接依頼には、構造上どうしても弱い部分があります。

リソースの上限があります。一人が同時に抱えられる案件数には限りがあり、今週中にという急ぎの依頼や、数ヶ月がかりの大規模開発は物理的に受けられないことがあります。

代替要員がいません。体調不良、繁忙、廃業といった事情があれば、同じ人が対応できない期間が生まれます。会社であれば別の担当者が引き継ぐ場面でも、個人にはその仕組みがありません。

保守の継続性も、会社のように窓口が引き継がれる保証はありません。品質保証や返金といった制度が組織的に用意されているわけではなく、実力の見極めも発注側の判断に委ねられます。技術的な判断材料が手元に少ないほど、この見極めは難しくなります（同様の指摘は前掲のランサーズ記事にもあります）。

これらは「だから個人には頼まない」という結論に向かうものではありません。「だから、発注前に何を決めておくべきかが決まる」という話です。次の章が、その理由にあたります。

依頼したあとに本当に困るのは「作った人しか直せない」状態

20年動き続けたマクロが、誰にも開けなくなっていた

ある企業向け支援会社の担当者が、note上でこんな相談事例を紹介しています。20年前に作成されたエクセルマクロが月末業務を支えているものの、作成者はすでに退職済み。VBAエディタを開いたことのある社員が社内に一人もいない、という状況です。

この事例で指摘されているのは、属人化したマクロの本当の怖さは「止まること」ではないという点でした。止まればすぐ気づけます。より重いのは、動き続けているマクロから出力される数値が本当に正しいのかを、検証できる人が社内に存在しないことです。

動き続けるマクロから出力される数値が本当に正確か、検証できる人が存在しない
— 出典: note（SIA株式会社）

誤った数値がそのまま経営判断や取引先への提出資料に流れていても、誰も気づけない。これは外注か内製かに関係なく起きます。

もっとも、悲観だけの話でもありません。同記事では、生成AIの普及によって古いVBAコードの解読や引き継ぎがしやすくなりつつあり、属人化を解消する好機だという見方も示されています。

パスワードロックと「野良マクロ」

VBAにはコードを保護するパスワードロック機能があります。ところが実務では、これがセキュリティ対策のつもりで、実質的に属人化の温床になっているという指摘があります。ロックを解除できたとしても、変数名やロジックが難読なままでは中身は分からず、ブラックボックスであることに変わりはない、というケースです（出典: セルネッツ）。

部署内だけで使われ、情報システム部門も把握していない「野良マクロ」が、退職リスクと直結してDX推進の障害になっているという実務コラムもあります（出典: パーソルHRパートナーズ）。作った本人が善意で作った便利ツールほど、この状態に陥りやすい。

マクロは作って終わりではなく、業務に合わせて育てるもの

消費税率の変更、取引先の帳票フォーマット変更、部署の統廃合、Officeのバージョン更新。業務が変われば、マクロには必ず改修が要ります。一度作れば10年動く、という前提で発注すると、たいてい数年後に困ります。

だから発注時に見るべきは「作れるか」だけではありません。その後も相談できるかどうかです。誰が作ったか分からない状態と、作った本人に直接連絡できる状態とでは、3年後にかかるコストがまるで違ってきます。直接つながっていれば、少なくとも「あのとき作ってもらったものを直したい」という相談を、本人に持っていけます。もちろん、対応できるかどうかはその人の状況によりますが、連絡先が分からない状態よりは選択肢が残ります。

発注前に書面で決めておく7つのこと

前章までを踏まえて、発注前に書面で確認しておきたい項目を整理します。相手が開発会社でもフリーランスでも、確認すべき内容は変わりません。

納品物の権利と、その後の直しやすさに関する4項目

成果物（VBAコード）の著作権をどちらに帰属させるか。譲渡なのか、利用許諾にとどめるのか。ここに明記がないと、後から改変や再利用の可否でもめる原因になります。
ソースコード一式（標準モジュール、フォーム、設計メモなど）が納品物に含まれるか。著作権を譲り受けても、コードが手元になければ実際には改変できません。ソースコード提供義務の有無は契約書に明記がないと争いになりやすい、という実務上の指摘があります（出典: IT法務ナビ）。
パスワードロックをかける場合、そのパスワードを発注側が保持するか。前章の通り、ここを曖昧にしたまま数年が経つと手が付けられなくなります。
納品後の保守・修正を誰が担うか。作った本人以外でも読める状態か。変数名の付け方、コメントの記載、簡単な仕様書の有無まで具体的に確認してください。

フリーランス新法で、発注する側にも求められること

個人のフリーランスに業務を委託する場合、発注側もフリーランス新法（正式名称: 特定受託事業者に係る取引の適正化等に関する法律、2024年11月1日施行）の対象になりえます。堅苦しく構える必要はありませんが、実務としてやることは決まっています。

業務内容、報酬額、支払期日、委託した日、納品を受ける日などを、書面またはメール等の電磁的方法で明示する
報酬は原則として、成果物を受け取った日から60日以内のできる限り短い期間内に支払う

出典は厚生労働省の資料および政府広報オンラインです。要するに、口頭とチャットの流れだけで進めないこと。条件をひとつのメールにまとめて送っておくだけでも、後の認識違いはかなり減ります。

渡すデータの範囲を先に決める

エクセルの自動化を頼むということは、売上データや顧客情報を含むファイルを社外に渡すことを意味します。ここに触れている記事は多くありませんが、実務上は重要な論点です。

秘密保持の取り決めを結ぶか、渡すのは本番データかダミーデータか、作業完了後にデータを削除してもらうか。この3点を最初に決めておけば、社内の情報管理ルールとの整合も取りやすくなります。

コーダーとプログラマーは何が違う？依頼先を間違えないための整理

依頼先を探し始めると、コーダー、プログラマー、エンジニアといった呼称の違いに迷います。発注者目線での目安はこうです。

コーダーは、デザインをHTML/CSSで形にする役割。Webサイトの見た目、ページ遷移、ボタンの配置など、画面に見える側を担当します。

プログラマーは、Java、PHP、VB.NETなどで内部処理やデータ処理、業務ロジックを組む役割。マクロやVBAはこちらの領域にあたります。エクセルの自動化を頼みたい場合は、まずこちら側の人を探すことになります（出典: クラウドワークス）。

ただし実務では、この呼び分けはかなり曖昧です。プログラマーと呼ばれる仕事をしている人がコーダーと名乗ることも、その逆もあります（出典: パーソルクロステクノロジー）。肩書きだけで判断せず、これまで何を作ってきたかを見るのが確実です。

なお、Webサイトの見た目の実装を依頼したい場合の進め方は、コーダーに直接依頼する方法をまとめた記事で別途扱っています。作りたいものが業務の自動化ではなくWebページの制作であれば、そちらを参照してください。

どんな人に相談すればいいか

タッチポイントWebに掲載中のあるプログラマーは、VB.NETやC#、PHPなどを使い、生産管理システム、受発注システム、会計システムといった業務システム開発を独立以来手がけてきたとプロフィールに記しています。本人の言葉として印象的なのは、次の一節です。

システム開発の仕事で求められることは、要望通りのシステムを納品するだけではない

技術力だけでなく、発注側との関係構築を重視する姿勢がうかがえます。テスト自動化スクリプトによってデグレーションテスト（修正が既存の機能を壊していないか確認する作業）の工数を3分の1に削減した実績も紹介されています。エクセルの自動化から、その先の業務システム化まで地続きで相談できる人がいる、という一例です。

また、タッチポイントWebに掲載中のあるコーダーは、「技術は課題解決の手段」であり、コードの美しさよりもクライアントの売上や業務効率化という目的の達成を優先すると自己紹介しています。工業機械のメンテナンスという経歴を持ち、複雑な仕組みを構造的に理解して不具合の原因を特定する論理的思考力を強みに挙げています。Web制作以外の畑から来た人もいる、というのは依頼先を探すうえで知っておいて損のない事実です。

相手を選ぶときの基準としては、次の3つが実用的です。