ノーコード・ローコード開発者のフリーランス案件｜報酬の決まり方と単価を上げる考え方

ノーコード・ローコード開発のフリーランス案件の報酬は、どの種類のツールを扱うか、業務の整理から運用の定着までどこを担うか、コードによる拡張や外部システムとの連携があるか、アプリの数と利用者がどれだけ広いか、稼働日数とリモートの条件で決まります。ノーコード・ローコード案件の単価について公的な統計はなく、案件によって大きく変わります。

単価を上げる近道は、画面を組む作業から、業務とデータの設計、拡張の判断、社内に広げるためのルールづくりへと役割を広げることです。この記事では、報酬が上下する仕組みと、交渉で示せる材料を整理します。なお、Power Platform と RPA の案件は、それぞれ別の記事で扱います。

ツールの種類で、求められる判断が変わる

ノーコード・ローコードと一口に言っても、ツールの種類によって作るものと任される判断が違います。ここではツールの優劣ではなく、案件の性質の違いとして整理します。

各ツールの公式サイトの説明を見ると、性格の違いが分かります（2026年10月時点）。kintone はプログラミングの知識がなくても業務アプリを作れるサービスとされ、開発者向けには REST API と JavaScript API が公開されています。Claris FileMaker は、データ・ロジック・画面・セキュリティを一つの環境で扱うローコードの基盤と説明されています。AppSheet は Google スプレッドシートや各種データベースにつないでアプリを作るノーコードの基盤、Bubble はWebアプリとモバイルアプリをノーコードで作る基盤とされています。

同じ「ノーコード」でも、社内の業務アプリを整える仕事と、社外向けのサービスを一から作る仕事では、求められる経験も責任の重さも異なります。報酬を比べるときは、ツール名だけでなく、何を作る案件なのかをそろえて見ることが大切です。

担当する工程の広さ

報酬を大きく左右するのは、ツールの操作そのものより、どの工程を担うかです。

1. 業務の聞き取りと整理：今の業務の流れ、紙やスプレッドシートで管理しているデータ、困りごとを把握する
2. アプリとデータの設計：何をアプリに分けるか、どの項目をどこに持つか、誰に何を見せるかを決める
3. 構築：画面、項目、一覧、通知、承認の流れなどを設定する
4. 拡張：標準の機能で足りない部分を、プラグイン、JavaScript、APIによる連携で補う
5. 定着と運用：利用者への説明、問い合わせ対応、改修の受け付け、社内の作り手の支援

構築だけを担う案件は、作業の範囲がはっきりしている一方、上がり幅は限られがちです。1と2を任されると、作る前の判断に責任を持つことになり、評価のされ方が変わります。5の定着と運用は地味に見えますが、利用が広がらないアプリは発注側にとって投資の失敗になるため、ここまで見られる人は継続して声がかかりやすくなります。

コードによる拡張と外部連携

ノーコード・ローコードの案件でも、標準の機能だけで完結しない場面は少なくありません。kintone の場合、APIドキュメントでは、外部システムとのデータ連携に使う REST API と、画面の動作や見た目を変える JavaScript API が分けて説明されています（2026年10月時点）。

• 標準の機能だけで組む：設定の正確さと、業務に合わせた設計が中心
• プラグインや連携サービスを組み合わせる：選定と、費用や保守の見通しの説明が加わる
• JavaScript や API で拡張する：コードを書く力と、ツールの更新で動かなくなったときの対応が加わる
• 基幹システムや会計などとつなぐ：データの整合と、障害時の切り分けの責任が加わる

拡張や連携が加わるほど、任せられる人は限られます。一方で、拡張しすぎると保守の負担が増え、発注側が自分たちで直せなくなります。「ここは標準で済ませ、ここだけ拡張する」という線引きを説明できることが、報酬に結びつきやすい力です。

アプリの数と利用者の広さ

一つの部署で使う一つのアプリを作る案件と、全社で数十のアプリを使っている環境を整える案件では、責任の重さが違います。

利用が広がった環境では、似たアプリが部署ごとに作られていたり、権限の設定がばらばらだったり、誰が作ったか分からないアプリが残っていたりします。こうした環境の整理や、社内の作り手が守るルール（命名、権限、アプリの作成と廃止の手順）づくりは、ツールの知識に加えて全体を見渡す力が要るため、経験者が求められやすい仕事です。

面談では、次の点を確かめると案件の重さをつかめます。

• いま何個くらいのアプリがあり、何人くらいが使っているか
• 社内で誰がアプリを作っているか（情報システム部門か、業務部門か）
• 作成や変更のルール、管理者が決まっているか
• 外部システムとの連携があるか、誰が保守しているか

上がり方と下がり方の特徴

条件が上がりやすい経験

• 業務の聞き取りから、アプリとデータの設計までを任された
• 部署をまたいで使われるアプリの権限と、データの持ち方を設計した
• 外部システムとの連携やデータ移行で、整合を保った
• 散らばったアプリを整理し、社内の作り手のためのルールを整えた
• 特定の業界や業務（製造、建設、不動産、営業管理など）に詳しく、聞き取りが早い

条件が上がりにくい状態

• 指示された画面や項目を設定する作業が中心で、設計の判断に関わらない
• 一つのツールの、限られた機能の経験に偏っている
• 作ったアプリが現場でどう使われたかを説明できない

契約の形と稼働の形

ノーコード・ローコードの案件は、アプリを作って納める請負の形と、稼働時間に応じて報酬が決まる準委任の形のどちらもあります。請負では、何をもって完成とするかがあいまいなまま進むと、修正の依頼が続いても報酬が変わらないことがあります。準委任では、月の稼働時間の幅と、超えたときの扱いを確かめておきます。違いは準委任契約と請負契約の違い、精算の仕組みは精算幅の記事で解説しています。

導入後の改善や運用の支援は、週に数日の稼働で続く形もあります。この場合、依頼をどう受け付けるか（チケットか、チャットでの随時の依頼か）が決まっていないと、同じ報酬のまま作業が増えがちです。

交渉で示せる材料

条件の見直しを相談するときは、次のような事実を、発注側が社内で説明できる形にまとめます。

1. 役割の広がり：構築の担当として入ったが、業務の聞き取りや設計の判断まで担っている
2. 利用の広がり：最初は一部署だったアプリが、他の部署にも使われるようになった
3. 作業の削減：紙やスプレッドシートの転記がなくなった、集計の手間が減った（守秘の範囲で）
4. 自走の支援：社内の作り手向けのルールや手順書を整え、自分が抜けても回る状態にした

伝え方は単価交渉の記事、報酬の仕組みの全体像はフリーランスの単価の決まり方にまとめています。業務改革やDX推進の立場から関わる場合はDXコンサルタントの報酬の記事も参考になります。

よくある質問

ノーコード・ローコード開発者の単価の相場はいくらですか？

公的な統計はなく、ツールの種類、担当する工程、拡張や連携の有無、稼働日数、リモートの可否によって大きく変わります。相場の数字を探すより、ご自身の経験がどの工程と範囲に当てはまるかを整理し、複数の案件で条件をそろえて比べるほうが判断の材料になります。

JavaScript などのコードが書けないと単価は上がりませんか？

コードで拡張できると任せられる範囲は広がりますが、それだけが道ではありません。業務の聞き取りと設計、社内に広げるためのルールづくりを担えると、コードを書かなくても評価が変わることがあります。求められるスキルはノーコード・ローコード開発者のスキルの記事で整理しています。

複数のツールを扱えるほうが有利ですか？

案件によります。ツールの数より、一つのツールで設計から定着までやり切った経験のほうが伝わりやすい場面も多くあります。別の種類のツールに広げる場合は、作るものの違い（社内の業務アプリか、社外向けのサービスか）を意識すると、経験を生かしやすくなります。今後の広げ方はノーコード・ローコード開発者の将来性の記事をご覧ください。