Retool案件の単価相場と獲得ルート｜Airtable専門で選ばれる条件

社内の申込管理や在庫管理を Retool で作り、業務データベースを Airtable で整えてきた。気づけば「うちの Airtable も見てほしい」と他社から声がかかるようになった。フリーランスや複業として受けられそうな手応えはあるのに、いざ「ノーコード 案件 単価」で検索すると、出てくるのは「LP 制作 5,000 円〜」「サイト制作 3 万円〜」といった数字ばかりです。これでは生活が成り立たないように見えて、一歩を踏み出せない——そんな状態で止まっている方は少なくありません。

相場が掴めないのには、はっきりした理由があります。検索結果に並ぶ「ノーコード案件」の大半が、STUDIO や Wix、Bubble を使った制作系の仕事を前提にしているからです。一方で Retool や Airtable が扱うのは、社内ツールや業務データベースといった業務システム系の領域です。発注者も、納品物も、保守の有無も、そして単価の決まり方も違います。それが同じ「ノーコード」という一語で括られているために、自分の仕事の値段だけが見えなくなっているのです。

業務システム系ノーコードの案件には、単価を左右する明確な構造があります。単価は「使えるツールの名前」ではなく「どの工程まで引き受けるか」で決まります。管理画面の設定代行で終われば数万円の請負仕事ですが、業務ヒアリングからデータモデル設計、既存システムとの接続、運用の引き渡しまでを担えば、月額の準委任契約として成立します。この構造を先に押さえておくと、提示された条件が妥当なのかを自分の頭で判断できるようになります。

本記事では、Retool 案件・Airtable 案件が制作系ノーコードとどう違うのかを起点に、単価レンジと契約形態、発注者が対価を払っている本当のスキル、機密案件しかない状態からの実績の作り方、案件獲得の 3 ルート、そして買い叩かれないための交渉材料までを順に整理します。最後に、AI によるアプリ生成が広がるなかでこの専門を続けられるのかという論点にも触れます。

Retool案件・Airtable案件とは何か——制作系ノーコードとは別物の仕事

まず土俵を揃えます。ノーコード案件は、大きく「制作系」と「業務システム系」の 2 つに分かれます。Retool と Airtable は後者に属し、検索で見かける単価情報の多くは前者のものです。この区別を曖昧にしたまま相場を見ても、自分が狙うべきレンジは永遠に見えてきません。

制作系ノーコード案件と業務システム系ノーコード案件の違い

両者は「コードを書かずに作る」という点だけが共通していて、仕事としての性質はかなり異なります。

注目したいのは最後の 2 行です。制作系は「作って納めたら終わり」の構造になりやすく、だからこそ 1 本あたりの金額で語られます。対して業務システム系は、業務が変われば画面も変わるため、継続的な関わりが前提になります。この継続性が、月額契約という形の単価に結びついていきます。

なお、制作系ノーコードでの稼ぎ方そのものに関心がある場合は、Bubble・Dify を軸に整理したノーコード・ローコード開発でフリーランスとして稼ぐ方法を参照してください。本記事は、そこでは扱いきれない業務システム系の領域に絞って掘り下げます。

Retoolが担当する領域——既存DB・APIに管理画面を被せる社内ツール

Retool は、すでに存在するデータベースや API の上に、社内向けの管理画面を短時間で組み上げるためのプラットフォームです。テーブル・フォーム・ボタンといったコンポーネントを配置し、それぞれに SQL クエリや API リクエストを紐づけていく作り方をします。

そのため Retool 案件は、ゼロからシステムを作る仕事ではなく、すでに動いているシステムの「操作窓口」を作る仕事として発生します。典型的なのは次のようなケースです。

• 本番 DB を直接触って運用していた業務に、権限付きの管理画面を用意したい
• カスタマーサポートが問い合わせのたびにエンジニアへ調査を依頼している状態をなくしたい
• 新サービスの申込受付・審査・オンボードのオペレーションを、リリースに間に合う速度で用意したい

3 つ目の例として参考になるのが、飲食店向け決済サービスの申込フローを Retool で構築した事例です。2 か月・1 人という限られた体制のなかで、約 50 項目の申込フォーム、回答内容の確認画面、オンボード管理画面、メール送信と Slack 通知までを実装し、3 か月で 3,000 件の申込に対応したと報告されています（1ヶ月で1000件の申込みを捌くフォームを Retool で実装した話 - dinii Tech Blog、2025 年 2 月公開）。ここで選定理由に挙げられているのは「開発リソースと期間が限られていること」「変更への迅速な対応が必要なこと」の 2 点です。

この 2 点こそが、Retool 案件が外部のフリーランスに発注される理由そのものです。社内に開発リソースがない、あるいは正社員エンジニアを本流のプロダクト開発から外せない。しかし業務は止められない。そこに外部人材の枠が生まれます。

Airtableが担当する領域——業務データベースとAutomationsによるオペレーション設計

Airtable は、スプレッドシートの手軽さとデータベースの構造を併せ持つツールです。テーブル間をリンクで関連づけ、Interfaces で用途別の画面を作り、Automations で「レコードが更新されたら通知する」といった処理を組みます。

Airtable 案件が発生する典型は、スプレッドシート運用が限界を迎えたタイミングです。

• 案件・顧客・請求が別々のシートに散らばり、転記ミスが常態化している
• 誰かが並べ替えたせいで他の人の作業が壊れる
• 集計のたびに手作業でコピー＆ペーストしている
• 担当者が退職すると、そのシートを触れる人がいなくなる

これらは「ツールを導入すれば解決する」問題に見えて、その本質はデータ構造の設計問題です。案件と顧客をどう分けるか、ステータスをどこに持たせるか、履歴を残すか上書きするか。ここを間違えると、Airtable に移しても同じ混乱が再現されます。Airtable 案件の価値の中心は、この設計判断にあります。

需要の背景——内製化ニーズと国内ローコード／ノーコード市場の伸び

「そもそも案件は増えているのか」という点も確認しておきます。ITR の調査によれば、国内のローコード／ノーコード開発市場の 2024 年度売上金額は前年度比 15.1% 増の 994 億円で、2025 年度も 14.9% 増の見込み、2024〜2029 年度の年平均成長率（CAGR）は 12.9% と予測されています（ITR「ITR Market View：ローコード／ノーコード開発市場2026」に関する発表、2026 年 2 月発表）。

この数字が意味するのは、ツールの導入そのものが企業側で進んでいるということです。そして導入が進むほど、「入れたけれど使いこなせない」「作ったが誰も保守できない」という状態の会社が増えます。社内ツール開発を外注する動機は、ツールが普及するほど強まる構造にあります。業務システムの内製化支援という枠でフリーランスに声がかかるのは、多くの場合この局面です。

Retool案件・Airtable案件の単価相場と契約形態

ここからが本題です。業務システム系ノーコードの案件は、金額の桁が 3 つのレンジに分かれます。同じスキルセットを持っていても、どのレンジで仕事を受けるかで年間の収入は大きく変わります。

小口請負レンジ——設定代行・自動化単位の相場

もっとも入口にあるのが、クラウドソーシングやスキルマーケットで取引されている小口の請負案件です。ランサーズの Airtable 関連パッケージを見ると、簡易なデータベース構築が 1 万円台から、データベース設計に Interfaces の画面制作と外部連携の自動化までを含むプランで 10 万円前後、追加の自動化 1 本あたり 1.5 万円前後といった価格帯で出品されています（ランサーズ Airtable パッケージ一覧、2026 年 9 月時点の掲載内容）。

このレンジの特徴は次のとおりです。

• 要件が最初から決まっている: 「このシートを Airtable にしてほしい」という形で降りてくる
• 納期が短い: 10 日〜30 日程度で完結する
• 単発で終わる: 納品後の関係が続かない
• 金額が作業量に連動する: 画面数・自動化の本数で見積もられる

副業として月に 2〜3 本こなせば数万円から十数万円にはなります。実績がゼロの段階で「発注されて納品した」という事実を作るには有効な入口です。

一方で、ここに留まり続けると起きることも明確です。要件を決めるのは常に発注者側なので、設計の判断に関与できません。作業量で値付けされるため、慣れて速くなるほど時間あたりの収入は伸びますが、案件単価そのものは上がりません。そして単発なので、毎月ゼロから営業し直すことになります。このレンジは通過点として使い、次のレンジに抜けることを前提に設計してください。

月額準委任レンジ——週2〜3稼働の内製支援

次のレンジが、企業と月額契約を結び、週 2〜3 日の稼働で社内ツールの内製を継続的に支援する形です。契約形態は準委任契約が中心になります。

金額の目安として、ノーコードエンジニアに特化したエージェントが提示している月額単価は 60〜80 万円程度とされています（ノーコードエンジニアのリアルな年収 - atsoho）。参考までに、フリーランスエンジニア全体の月額平均単価は、エン・ジャパンが運営する「フリーランススタート」の集計で 2025 年 12 月度に 78.3 万円と報告されています（エン・ジャパン ニュースリリース）。

つまり、業務システム系ノーコードの月額レンジは、フリーランスエンジニア全体の相場から大きく外れた低い水準ではありません。「ノーコードだから安い」というのは、制作系の単発案件の数字を全体に当てはめたときにだけ成り立つ話です。

ただし、この数字は週 5 日フル稼働を前提とした月額であることに注意してください。週 2 日稼働であれば、単純計算でその 4 割程度、月額 25〜32 万円前後が目安になります。副業として始める場合はこのレンジからの出発が現実的です。

契約条件として確認しておきたいのは次の項目です。

単価が上がる分岐点は引き受ける工程の範囲で決まる

3 つ目が、要件定義から入る高単価レンジです。ここに到達する条件は、ツールの習熟度ではなく「引き受ける工程の範囲」です。

業務システム系ノーコードの案件は、おおむね次の 5 工程で構成されます。

1. 業務ヒアリング: 誰が、いつ、何を、どんな順序でやっているかを聞き取る
2. データモデル設計: 業務の実体をテーブル構造に落とす
3. 画面・自動化の実装: Retool の画面、Airtable の Interfaces と Automations を組む
4. 既存システムとの接続: 既存 DB・SaaS・API との連携と権限設計
5. 運用移譲: 依頼側が自分で軽微な変更をできる状態にする

小口請負のレンジで求められるのは主に 3 だけです。月額準委任のレンジでは 2〜4 が求められます。そして単価が明確に上がるのは、1 と 5 を引き受けたときです。

理由はシンプルで、1 と 5 は発注側にとって代替が難しいからです。3 の実装だけなら、社内の若手に学ばせるか、より安い外注先を探す選択肢があります。しかし業務を聞き取って構造化する仕事と、作ったものを組織に定着させる仕事は、ツールの操作方法を覚えただけの人には務まりません。ここを担えるかどうかが、レンジの境界線になります。

副業と専業で狙うレンジはどう変わるか

現在の状況によって、狙うべきレンジは変わります。

重要なのは、専業を目指す場合に「稼働日数を増やす」方向だけで組み立てないことです。週 5 日を埋めれば単価は積み上がりますが、それは会社員と同じ時間の売り方になります。工程の範囲を広げて 1 日あたりの単価を上げるほうが、稼働に余裕を残したまま収入を安定させられます。

Retool案件で評価されるノーコードエンジニアのスキル——ツール操作は入口にすぎない

「ノーコードしかできない人と見なされて、コードが書けるエンジニアより低く評価されるのではないか」という不安は、この領域を検討する人がほぼ必ず通る場所です。しかし発注者が対価を払っている対象を分解すると、評価軸はツール名ではないことが見えてきます。

業務要件をデータモデルに落とす力——Airtableのテーブル設計が案件の成否を決める

Airtable 案件で成否を分けるのは、ほぼテーブル設計です。

たとえば「案件管理を Airtable にしたい」という依頼を受けたとします。ここで安易に「案件」テーブルを 1 つ作り、顧客名・担当者・金額・ステータス・請求日を列として並べると、数か月で破綻します。1 つの顧客に複数の案件がぶら下がったとき、顧客情報が案件の数だけ重複するからです。顧客名の表記が揺れ、住所が古いまま残り、集計が合わなくなります。

判断すべきなのは次のような点です。

• どこまでを別テーブルに切り出すか: 顧客・案件・請求・担当者をどう分けるか
• ステータスをどこに持たせるか: 案件全体の状態か、工程ごとの状態か
• 履歴を残すか: 上書きしてよい値か、変更のたびに記録が必要な値か
• 単一レコードの粒度は何か: 「1 件」が指すものを業務側と揃えられているか

これらは Airtable の機能を知っていれば答えが出る問題ではありません。業務側が「案件」と呼んでいるものが、見積単位なのか納品単位なのか請求単位なのかを聞き出さないと決められません。この聞き取りと構造化ができる人は、ノーコードツールを離れても通用します。

既存システムとの接続と権限設計——Retoolでつまずきやすい箇所

Retool 案件で難所になりやすいのは、画面の組み立てではなく接続と権限まわりです。

• 本番データを扱う怖さ: 管理画面から更新系のクエリを流す以上、誤操作が本番データを壊します。確認ダイアログ、更新前後の差分表示、論理削除の採用など、壊れない導線の設計が必要です
• 権限の切り分け: 「サポートは閲覧だけ、リーダーは更新可、経理だけが金額を触れる」といった要件をロールで表現し、画面側の表示制御と DB 側の権限の両方で担保する必要があります
• 接続情報の管理: DB の認証情報や API キーをどう保持するか、環境（開発／本番）をどう分けるか
• 監査ログ: 誰がいつ何を変更したかを追える状態にしておくか

これらは「ノーコードだから簡単」とは言えない領域です。むしろ、業務システムの経験がないと落とし穴に気づけません。ここを最初から設計に織り込める人は、発注側から見ると安心して任せられる相手になります。

コードが書けることが効くのはどこか——JavaScript・SQL・API

Retool も Airtable も、ノーコードで完結する範囲とコードが必要になる範囲の境界があります。この境界を越えられるかどうかが、単価の差になって現れます。

「コードが書けるノーコードエンジニア」という立ち位置は、この領域では強い差別化になります。ノーコードだけで組み立てようとして不自然に複雑化した構成を、10 行のスクリプトで整理できるからです。逆に言えば、既に JavaScript と SQL が書ける状態でこの領域に入るのは、かなり有利なスタートです。自分のスキルを「ノーコードしかできない」と評価するのは、おそらく過小評価です。

運用移譲まで設計できると単価が変わる

もっとも見落とされやすく、そしてもっとも単価に効くのが運用移譲です。

社内ツールを作って納めただけでは、依頼側は「変更のたびに外部へ依頼が必要な状態」を抱えることになります。これは発注側にとって新しい属人化であり、内製化の動機とは逆行します。そのため、次のような設計をあらかじめ組み込める人は評価が変わります。

• 業務側が自分で変えられる部分（選択肢の追加・通知先の変更）と、触ってはいけない部分を分けておく
• 命名規則とテーブル構造の意図をドキュメントに残す
• 変更手順を短い動画やチェックリストで渡す
• 引き継ぎ前提でアクセス権を整理しておく

「自分がいなくても回る状態」を作ると仕事を失うように思えますが、業務システムの領域では逆に働きます。安心して任せられる相手として、次の業務領域の相談が来るからです。契約が単発から継続に変わる分岐点は、多くの場合ここにあります。

実績ゼロから最初の1件を取るまでの準備

このスキルセットを持つ人が最初にぶつかるのが、実績を見せられないという壁です。社内ツールは業務の中身そのものであり、画面のスクリーンショット 1 枚が機密になり得ます。「作品を公開しましょう」という一般的なポートフォリオ論が、この領域では成立しません。

機密案件の実績を公開可能な形に翻訳する3つの方法

見せられないのは「そのもの」であって、「そこで行った判断」ではありません。翻訳の方法は 3 つあります。

1. ダミーデータで再現したデモアプリを作る

同じ構造の業務を架空の題材に置き換え、Retool や Airtable で再現します。たとえば社内の審査業務を「架空の中古機材買取サービスの査定管理」に置き換えるといった形です。データも会社名もすべて架空なので公開に支障がなく、設計の力は伝わります。

2. 業務フロー図と Before / After で示す

作った画面そのものではなく、業務の流れを図にして提示します。「6 人が Excel を回覧して 3 日かかっていた承認が、1 画面の申請と自動通知で当日中に完了するようになった」という構造は、企業名を伏せても十分に伝わります。数字を出せない場合でも、工程数や関係者数の変化だけで説得力があります。

3. 設計判断の記録を匿名化して残す

「なぜこのテーブル構成にしたか」「なぜこの処理は自動化しなかったか」を短い文章で残します。技術ブログでも、提案時に渡す 1 枚の資料でも構いません。発注者がもっとも知りたいのは、判断の理由を言語化できる相手かどうかです。 完成品の見た目より、この記録のほうが効きます。

いずれの方法も、現職の守秘義務に抵触しない範囲で行ってください。判断に迷う内容は、抽象度を一段上げて記述するか、扱いを避けるのが安全です。

デモアプリに入れるべき要素——データモデル・権限・自動化

デモアプリを作る場合、見た目の作り込みに時間をかけても評価は上がりません。入れるべきは次の 3 要素です。

• データモデル: テーブルが 3 つ以上あり、リンクで関連づけられていること。1 テーブルで完結する構成は「スプレッドシートの置き換え」にしか見えません
• 権限の切り分け: 役割ごとに見える範囲・触れる範囲が違うこと。業務システムらしさは権限に現れます
• 自動化: 状態の変化を起点に通知や更新が走ること。手作業をどこまで削れるかを示せます

加えて、意図的に「自動化しなかった箇所」を 1 つ用意し、その理由を説明できるようにしておくと効果的です。何でも自動化する人より、自動化の是非を判断できる人のほうが信頼されます。

提案時に効く「業務課題→設計判断」の説明フォーマット

提案や面談の場では、次の順序で話すと伝わりやすくなります。

1. どんな業務が、どう詰まっていたか（例: 申込の受付から審査完了まで、担当者間の転記が 4 回発生していた）
2. 何が本当の原因だったか（例: 申込データと審査結果が別々の場所に置かれていた）
3. どう構造化したか（例: 申込を親、審査履歴を子として分離し、ステータスを申込側に持たせた）
4. なぜその選択にしたか（例: 再審査が発生する業務のため、履歴を上書きしない構造が必要だった）
5. 結果として何が変わったか（例: 転記がゼロになり、審査状況の問い合わせ対応がなくなった）

このフォーマットの利点は、機密情報を出さなくても成立することです。1 と 5 は抽象化でき、2 から 4 は設計の話なので、そもそも社名が要りません。

ポートフォリオの基本構成は既存の解説に委ねる

掲載項目の並べ方や連絡先の書き方といったポートフォリオの基本については、フリーランスエンジニアのポートフォリオ作り方で網羅的に整理しています。本記事で扱った「公開できない実績をどう翻訳するか」という論点と組み合わせて使ってください。

Retool案件・Airtable案件を獲得する3つのルートと選び分け

「Retool 案件」「Airtable 案件」で求人を検索しても、ヒット件数はさほど多くありません。これを「案件が存在しない」と読むのは早計です。発注側は、必ずしもツール名で募集をかけないからです。ノーコード案件の獲得は、ルートごとに探し方が変わります。

小口案件で実績を作るルート——向く時期と抜けるタイミング

クラウドソーシングやスキルマーケットは、実績ゼロの段階でもっとも早く「発注された事実」を作れる場所です。

向く時期: 対外的な実績が 1 件もなく、見積もりを出した経験もない段階。金額より、依頼の受け方・要件のすり合わせ方・納品の作法を経験することに価値があります。

抜けるタイミング: 次のいずれかに当てはまったら、比重を下げる時期です。

• 同種の依頼を 3 件以上こなし、要件のパターンが読めるようになった
• 見積もりを自分で組み立てられるようになった
• 依頼をこなす時間より、新しい依頼を探す時間のほうが長くなっている

このルートを長く続けると、「安く早く作る人」という位置づけが固定します。実績が積み上がった時点で、次のルートに軸足を移してください。

エージェント・複業マッチングで探すときの検索語の作り方

週 2〜3 日の準委任案件を探す場合、エージェントや複業マッチングサービスが主な入口になります。ここでの最大のコツは、ツール名だけで検索しないことです。

発注側は「Retool ができる人」ではなく「社内の業務を回せるようにしてくれる人」を探しています。そのため募集の文言は、次のような周辺キーワードで書かれていることが多くなります。

ツール名での検索は、案件が見つかったときの適合度は高いものの、母数が小さすぎます。上記のカテゴリを組み合わせて検索し、募集要項の中に「Retool」「Airtable」「スプレッドシート運用の脱却」といった記述があるかを確認する進め方のほうが、結果的に見つかる案件は増えます。

面談では、ツールの習熟度ではなく「業務を聞き取って構造化した経験」を軸に話してください。発注側が不安に思っているのは、操作ができるかどうかではなく、業務の話が通じるかどうかです。

直接取引・リファラルの作り方——現職経験の派生をどう扱う

もっとも単価が高くなりやすいのが、直接取引とリファラルです。仲介手数料が乗らないうえ、相談段階から関われるため、要件定義の工程を含む契約になりやすいからです。

このルートの起点は、多くの場合すでに手元にあります。「うちの Airtable も見てほしい」と声をかけられた経験があるなら、それが最初のリファラルです。ただし進め方には注意が必要です。

• 現職の就業規則を先に確認する: 副業の可否、競業避止の範囲、事前申請の要否
• 顧客・取引先との利益相反を避ける: 現職の取引先から直接受注する場合は、特に慎重に判断する
• 現職で得た機密情報を持ち出さない: 設計の考え方は自分のものですが、データ・資料・顧客情報は違います

そのうえで、次のような接点を継続的に作っておくと、声がかかる確率が上がります。

• 設計判断を言語化した記事や登壇資料を残しておく
• 業務システム・情シス・ノーコード関連のコミュニティに定期的に顔を出す
• 一度受けた案件で運用移譲まで丁寧に行い、紹介につなげる

併走させる比率の目安——副業期と専業期

3 つのルートは、時期に応じて比率を変えていくものです。

専業期にエージェント経由の案件を土台として残すのは、収入の下限を確保するためです。直接取引だけで組み立てると、1 社の事情で収入が大きく変動します。安定した土台の上に、単価の高い直接取引を重ねる構成が現実的です。

買い叩かれないための立ち回りと単価交渉の材料

同じスキルでも、案件の受け方によって提示される金額は変わります。ここでは単価が下がる構造と、それぞれへの対処を整理します。

単価が下がる3つの構造

構造 1: 成果物の見た目だけで比較される

「管理画面を 1 つ作る」という要件で相見積もりになると、比較対象は画面の数と見た目だけになります。データモデルの妥当性や、将来の変更しやすさは見積書に現れません。結果として、いちばん安い提示が選ばれます。

構造 2: 作業単位で切り売りされる

「この自動化を 1 本」「この画面を 1 枚」と作業単位で発注されると、単価は作業時間に収束します。業務を理解して構造を提案する余地がないため、誰が作っても同じという前提で値付けされます。

構造 3: 要件が固まらないまま着手する

「まず作ってみて、見ながら決めましょう」という進め方は、業務システムでは高確率で手戻りを生みます。しかも請負契約で受けていると、その手戻りは自分の負担になります。当初の想定の 2 倍働いて同じ金額、という状態がここから生まれます。

見積もりの切り方を変える——画面数見積もりから脱する

構造 1 と 2 への対処は、見積もりの単位を変えることです。

画面数で見積もると、比較されるのは画面の値段になります。そうではなく、業務プロセスの数とデータモデルの複雑度で切ります。

この形で提示すると、比較の土俵そのものが変わります。相手が「画面 3 枚で 15 万円」の見積もりと並べようとしても、こちらの見積もりには相手側にない項目が並んでいます。値引き交渉ではなく、範囲の交渉に持ち込めるのがこの切り方の利点です。 「予算内に収めたいなら、運用移譲を次フェーズに回しましょう」という会話ができます。

準委任と請負のどちらを選ぶか

構造 3 への対処は契約形態の選択です。

• 請負契約: 仕事の完成に対して報酬が発生します。完成しなければ報酬は発生せず、成果物に不備があれば契約不適合責任を負います
• 準委任契約: 業務の遂行に対して報酬が発生します。善良な管理者の注意をもって業務にあたる義務を負いますが、完成そのものの義務は負いません

要件が固まっており、範囲が明確で、変更の可能性が低い案件は請負でも問題ありません。小口の設定代行はこちらに向きます。

一方、業務ヒアリングから入り、作りながら要件が具体化していく案件は準委任が適しています。業務システム系ノーコードの案件の多くはこちらです。「作りながら決めたい」と言われた時点で、それは準委任で受けるべき案件だと判断してください。請負で受けて仕様変更を無償で吸収する構図が、この領域でもっとも単価を毀損します。

なお、2024 年 11 月 1 日に施行された「特定受託事業者に係る取引の適正化等に関する法律」（フリーランス新法）により、発注事業者には業務内容・報酬額・支払期日などの取引条件を書面または電磁的方法で明示する義務が課されています（厚生労働省「知っていますか？ フリーランスの取引に関する新しい法律」）。条件が曖昧なまま着手を求められた場合、明示を求めることは正当な要求です。交渉の場で立場を弱く感じる必要はありません。

運用・保守を「作業」ではなく「改善」に組み替える

業務委託で入ったあと、運用・保守だけの作業者に固定されてしまう——これも単価が伸び悩む典型です。原因は、保守契約の中身が「壊れたら直す」に限定されていることにあります。

組み替えの方向は、保守を改善のサイクルとして定義し直すことです。

契約更新時に「先月はこの工程の手作業を削って、月 8 時間分の作業がなくなりました」と報告できる状態を作れば、保守は費用ではなく投資として扱われます。金額の議論の土台が変わります。

AI時代にRetool・Airtable専門で続けられるか——ノーコードの将来性

最後に、この専門に賭けてよいのかという論点です。AI がアプリを生成できるようになるなかで、ノーコードツールの専門性は数年で無価値になるのではないか。この不安は正当なので、工程ごとに切り分けて考えます。

AIに置き換わりやすい工程・置き換わりにくい工程

見てのとおり、置き換わりやすいのは前章で「小口請負レンジ」に対応すると整理した工程です。逆に、単価が上がる分岐点として挙げた業務ヒアリングと運用移譲は、置き換わりにくい側に並びます。

つまり AI の進展は、この領域の仕事を消すというより、レンジ間の格差を広げる方向に働きます。実装だけを担っている状態は今後さらに厳しくなり、業務の側に踏み込んでいる状態はむしろ相対的な価値が上がります。危機感を持つべき対象は「ノーコードという手段」ではなく「実装だけを担う立ち位置」です。

需要側の動き——内製化と市場規模の推移

需要そのものは縮んでいません。先に触れたとおり、国内のローコード／ノーコード開発市場は 2024 年度に前年度比 15.1% 増の 994 億円、2024〜2029 年度の年平均成長率は 12.9% と予測されています（ITR 発表、2026 年 2 月）。

ツールの導入が進むほど、企業側には次のような課題が積み上がります。

• 部門ごとに作られたツールが乱立し、データが分断される
• 作った担当者が異動・退職して、誰も保守できないアプリが残る
• 権限設計が甘いまま運用され、監査で指摘される
• AI が生成したアプリの妥当性を評価できる人が社内にいない

いずれも「作る」より「整える」に近い仕事です。ツールの普及と AI の生成能力が進むほど、この種の需要は増えます。

専門の置き方——ツール軸から業務領域軸へ

長く続けるうえで有効なのは、専門をツール名で名乗らないことです。

「Retool ができます」「Airtable ができます」という名乗り方は、そのツールの流行が終わったときに立ち位置ごと失われます。そうではなく、業務領域で専門を置き、ツールは手段として複数持つ構成にします。

業務領域の例としては、受発注・在庫管理、審査・与信オペレーション、カスタマーサポート業務、採用・労務のバックオフィス、店舗運営のオペレーションなどが挙げられます。1 つの領域で複数社の案件を経験すると、業界の標準的な業務フローが頭に入ります。この蓄積は、次の案件でヒアリングの質を上げ、提案の説得力を高めます。ツールの習熟度は追いつかれますが、業務の蓄積は追いつかれにくい資産です。

スキルの横展開先

Retool・Airtable で培ったスキルは、隣接領域に展開できます。

• 他の業務システム系ツール: kintone、Notion、Microsoft Power Apps、Salesforce の設定領域。データモデル設計と権限設計の考え方はそのまま通用します
• 業務自動化（iPaaS）: Zapier、Make、Workato。SaaS 間の連携設計は、Airtable の Automations の延長線上にあります
• データ活用・BI: 業務データを整えた次に来るのが可視化です。ツール専門としてフリーランスで成立させる型は共通しており、単価水準やキャリアの進め方はBIエンジニアのフリーランス案件が参考になります
• 通常の受託開発: ノーコードで扱いきれない要件に出会ったとき、コードで作る選択肢を自分で持てると、案件の幅が一段広がります

複数の手段を持つことは、単に対応範囲が広がるだけでなく、「この業務はノーコードで作るべきか、コードで作るべきか」という判断ができるという意味を持ちます。この判断力そのものが、発注側にとって希少です。

まとめ——狙うレンジと次の一手

Retool 案件・Airtable 案件は、制作系ノーコードの単価情報からは見えてこない領域にあります。単価を決めるのはツール名ではなく、引き受ける工程の範囲です。

現在地に応じた次の一手は、次のように整理できます。

• 実績がまだ 1 件もない: ダミーデータで再現したデモアプリを 1 つ作り、設計判断を言語化した説明をセットで用意する。並行して小口案件を 2〜3 件受け、見積もりと納品を経験する
• 小口案件は回せている: 見積もりの単位を画面数からプロセス数とデータモデルの複雑度に切り替える。エージェント・複業マッチングで「業務改善」「内製化支援」「情報システム」等の周辺キーワードから週 2〜3 日の準委任案件を探す
• 月額契約はあるが単価が伸びない: 契約範囲に業務ヒアリングと運用移譲を含める交渉を、次回更新のタイミングで行う。保守を「壊れたら直す」から「毎月 1 つ手作業を削る」に定義し直し、成果を数字で報告する

そして、専門の名乗り方をツールから業務領域に移していくことが、この領域で長く続けるための条件です。Retool と Airtable は現時点で強力な手段ですが、手段は入れ替わります。入れ替わっても残るのは、業務を聞き取り、構造化し、組織に定着させる力です。買い叩かれない位置は、そこにあります。

次のアクション

社内ツール開発や業務システムの内製化支援で、週 2〜3 日から参画できる案件を探したい場合は、Workee で条件を指定して検索できます。稼働日数・リモート可否・単価条件のほか、業務改善や情報システム領域の案件も掲載されているため、いまの働き方を保ったまま試せる範囲を確認してみてください。

Workee で案件を探す