返信が来る提案文には何が書いてあるか、RPA・業務自動化の案件の取り方

RPA・業務自動化の案件に応募しているのに、提案文を送っても返事が来ない。このご相談、本当に多いんです。多くの方が、スキルが足りないせいだと考えて学習に戻ります。でも、実際に届いた提案文をいくつも見せていただくと、原因は技術力ではないことがほとんどでした。

結論から言うと、返信が来る提案文には、発注者が知りたいことが最初の数行に書いてあります。逆に返信が来ない提案文は、自分の経歴から始まっています。読む側の立場に立てば理由は明らかで、発注者は自分の困りごとが解決するかどうかを知りたいのであって、あなたの職歴を知りたいわけではないからです。

この記事では、募集文から発注者の状況を読み取る方法、返信が来る提案文の構成、そして提案の段階で決めておくべき取引条件までを順に見ていきます。法律の話も出てきますが、必ず「つまり」で言い換えますので、身構えないで読み進めてください。

返信が来ない提案文に共通している、3つの欠落

まず、うまくいかない型から見ていきます。ここを直すだけで反応が変わる方は少なくありません。

自己紹介から始まっている

「はじめまして。○○と申します。これまでUiPathを用いた開発に従事しており、金融機関向けのシステムに携わってまいりました」。丁寧で、礼儀正しい文章です。ただ、発注者が最初に知りたい情報は一つも入っていません。

発注者は、複数の提案を並べて読みます。最初の2行で自分の案件との関係が見えない提案は、後回しにされ、そのまま埋もれます。つまり、冒頭の2行をどう使うかが勝負です。

できることしか書いていない

「対応可能です」「経験があります」とだけ書かれた提案は、判断材料になりません。発注者が本当に不安なのは、できると言われた作業が本当にできるかではなく、想定外のことが起きたときにどうなるかです。

ここで効くのが、できないことを先に書くという方法です。「本番環境へのリリース作業は貴社側で実施いただく前提です」「対象システムの画面変更があった場合は別途改修のお見積もりとなります」。こう書いてある提案は、範囲を理解している人が書いたものだと伝わります。

質問が多すぎる

熱心さのつもりで、確認事項を10項目並べてしまう方がいます。読む側から見ると、これは負担です。返事を書くのに時間がかかる提案は、時間があるときに読もうと後回しにされ、そのまま忘れられます。

質問は3つまで。それ以上あるなら、「他にも確認したい点がありますので、ご縁があればお打ち合わせの際に伺えればと存じます」と書いて閉じるほうが返信率は上がります。

募集文から、発注者の状況を読み取る

提案を書く前に、募集文を読み込む工程があります。ここを飛ばして書かれた提案は、どうしても一般論になります。

実際の募集文を見てみましょう。フリーランス向けに公開されている案件の文面です。

金融機関向け業務自動化支援にてBizRobo,UiPathの経験者を募集しています！◆想定作業◆・金融機関のユーザー部署への業務ヒアリング・手作業業務の整理・設計・RPAツールを用いた業務自動化開発・テスト・リリース対応・ユーザー業務の自動化支援 出典: freelance.adecco.co.jp

この短い文面から、いくつものことが読み取れます。

想定作業の並び順に意味がある

注目していただきたいのは、想定作業の先頭が「業務ヒアリング」であることです。開発ではありません。

つまりこの案件は、何を自動化するかがまだ決まっていない段階だということです。発注側は、対象業務を洗い出すところから手伝ってほしいと考えています。この場合、提案文でツールの習熟度を強調しても刺さりません。刺さるのは、業務の聞き取りをどう進めるかの説明です。

逆に、想定作業が「既存シナリオの改修」から始まっている案件なら、すでに動いているものがあり、仕様は形として存在します。この場合は、既存資産をどう読み解くかの話が中心になります。

業界の指定は、制約の指定でもある

「金融機関向け」と書かれている場合、そこには情報の取り扱いに関する制約が含まれています。データの持ち出し可否、作業場所の制限、身元確認の手続き。提案文でこの点に触れておくと、分かっている人だという印象になります。

ツール名の併記は、優先度の情報を含む

BizRoboとUiPathのように複数のツール名が並ぶ募集は、どちらかの経験があれば検討するという意味であることが多いです。片方しか経験がない場合、経験のあるほうを先に書き、もう片方については「学習中」あるいは「同等の構成のため短期間でキャッチアップ可能」と正直に書きます。

ここで嘘を書くと、後で必ず問題になります。技術の嘘は、着手した瞬間に露見します。

RPAの案件は4種類に分かれる。どこを狙うかで提案が変わる

案件の取り方を考えるうえで、応募先の種類を整理しておくと戦い方が決まります。公開されている募集を眺めると、RPA・業務自動化の案件はおおむね4つに分類できます。

新規導入の支援

まだRPAを入れていない企業で、対象業務の選定から始める案件です。想定作業の先頭に業務ヒアリングが置かれているのはこの型です。

メリットは、設計の自由度が高いこと。デメリットは、関係者が多く、合意形成に時間がかかることです。提案では、業務の聞き取りをどう進めるかと、範囲をどう確定させるかを中心に書きます。ツールの習熟より、進行の設計が評価される案件だと考えてください。

既存シナリオの改修とマイグレーション

すでに動いているロボットを、システム更改や画面変更に合わせて直す案件です。導入から数年が経った企業で増えています。

▍環境面：リモート併用相談可！▍インボイス未登録の方OKです！金融業向け業務自動化支援にてインフラ構築,RPAの経験者を募集しています！◆想定作業◆・金融機関の手作業をRPAで自動化・ユーザーへの業務ヒアリングを実施・業務整理やRPA設計を担当・RPAツールの開発やテストを実施・リリースまでの一連の工程を担当 出典: freelance.adecco.co.jp

この種の募集では、リリースまでの一連の工程を担当することが前提になっています。つまり、作って終わりではなく、動く状態にするところまでが範囲です。提案では、テストとリリースをどう進めるかに触れておくと、範囲を理解している人だと伝わります。

改修案件のメリットは、仕様が形として残っていること。デメリットは、前任者が書いた読みにくいシナリオを解読する手間が読めないことです。ここは提案の段階で「既存シナリオの確認に一定の工数が必要となります」と書いておくのが安全です。

運用保守

稼働中のロボットを見守り、止まったら直す案件です。月額固定で契約されることが多く、収入が読みやすいという利点があります。

一方で、対応可能な時間帯が拘束されるため、他の案件との掛け持ちがしにくくなります。副業として受ける場合は、対応時間の条件を必ず確認してください。

単発の小規模自動化

特定の作業だけを自動化してほしいという依頼です。金額は小さくなりますが、期間が短く、関係者も少ないため進めやすいという特徴があります。

実績を積む段階では、この型から入るのが現実的です。1件を丁寧に納めると、同じ発注者から次の作業を頼まれる流れができます。

ツールで選ぶという考え方

案件の種類とは別に、扱うツールで応募先を絞る方法もあります。国内ではWinActorのように国産で導入実績の多いツール、UiPathのように大規模導入に使われるツール、Power Automateのようにクラウド基盤と組み合わせて使われるツールなどが並びます。

どれを選ぶかの基準は、単純です。自分が触れる環境があるかどうか。無料版や試用版で手を動かせるツールから入るのが、提案に書ける材料を早く作る方法です。「複数のツールに対応可能」と書くより、1つのツールで具体的な作業内容を書けるほうが、返信率は高くなる傾向があります。

返信が来る提案文の構造

ここからが本題です。構成を5つの要素に分けて説明します。

冒頭2行で、相手の課題を言い換える

最初にやることは、募集文に書かれている状況を自分の言葉で言い直すことです。

たとえば先ほどの募集なら、「対象業務の洗い出しから着手し、自動化の範囲を決めたうえで開発に入る進め方が必要な案件と拝見しました」と書く。これだけで、読んだうえで書いていることが伝わります。

これ、知らない人が本当に多いんです。提案文の冒頭は挨拶の場所だと思われていますが、実際には最も重要な2行です。

進め方を工程で示す

次に、どう進めるかを工程で書きます。開発、テスト、納品のような大きな区切りではなく、相手が想像できる粒度にします。

現状の作業手順を画面共有で確認する、対象業務の一覧と処理件数を整理する、自動化する範囲を合意する、シナリオを作成する、テスト用データで動作を確認する、実データで立ち会い確認を行う、手順書を添えて納品する。この程度に分けて書くと、発注者は自分たちが何をすればよいかも同時に理解できます。

工程を示す提案が強いのは、比較の対象が変わるからです。他の提案が「できます」と書いている中で、進め方を書いた提案だけが具体的に見えます。

できないこと、範囲外のことを先に書く

先ほども触れましたが、ここは重要なので改めて書きます。範囲を書くことは、逃げではなく誠実さです。

書いておきたいのは、対応しない工程、対応しない時間帯、追加費用が発生する条件の3点です。「本番リリース時の立ち会いは平日日中に限り対応可能です」「対象システムの仕様変更に伴う改修は、別途お見積もりとなります」。この2行があるだけで、後のトラブルがかなり減ります。

※ 範囲の線引きが難しい案件では、契約前に専門家へ相談することも検討してください。特に金額が大きい案件や、継続的な保守を含む案件では、条項の意味を確認しておく価値があります。

見積もりの根拠を1行添える

金額だけを書いた提案は、比較されると安いほうが選ばれます。根拠が書いてある提案は、金額そのものより中身で比較されます。

「対象業務3件、それぞれ分岐が中程度と想定し、設計と実装で計40時間、テストと修正で15時間を見込んでおります」。この1行があると、発注者は自分の想定とのずれに気づけます。ずれていれば質問が来ますし、質問が来れば会話が始まります。返信が来る提案とは、要するに質問したくなる提案のことです。

質問は3つまでに絞り、答えやすい形にする

質問の書き方にもコツがあります。開いた質問ではなく、選択肢を添えた質問にすることです。

「対象システムへのアクセスはどのような形になりますでしょうか。貸与端末、VPN接続、仮想デスクトップのいずれかでしょうか」。こう書けば、相手は一言で答えられます。答えるのが楽な質問ほど、返信は早く来ます。

提案文の書き換え、実際の比較

抽象的な話が続いたので、書き換えの例を挙げます。

改善前は、こういう形になりがちです。「はじめまして。RPAエンジニアの○○です。UiPathでの開発経験が3年あり、これまで複数の企業で業務自動化を担当してまいりました。今回の案件についても対応可能ですので、ぜひご検討ください。何かご不明な点がございましたらお気軽にお問い合わせください」。

礼儀は完璧です。ただ、この提案が伝えている情報は「経験がある」「やりたい」の2つだけで、他の応募者と区別がつきません。

改善後は、次のような形になります。「対象業務の洗い出しから着手し、自動化範囲を合意したうえで開発に入る進め方が必要な案件と拝見しました。まず現状の操作を画面共有で確認し、処理件数と例外パターンを一覧化するところから始めます。想定は、範囲確定に1週間、設計と実装に3週間、テストと修正に2週間です。なお、本番リリース時の立ち会いは平日日中のみ対応可能です。1点確認させてください。開発環境へのアクセスは、貸与端末、VPN接続、仮想デスクトップのいずれになりますでしょうか」。

長さはほぼ同じです。違うのは、書いてある情報の種類だけです。

実績が浅い段階で、提案文に何を書くか

経験が少ない場合の書き方についても触れておきます。ここで大事なのは、経験がないことを謝らないことです。

謝罪から入ると、読む側は「不安要素がある応募者」として認識します。そうではなく、経験の代わりに何を差し出せるかを書きます。

書けるのは3つです。1つ目は、対象業務そのものへの理解。経理や人事の実務経験があるなら、それは自動化の対象を理解しているということです。RPAの案件で本当に難しいのは、ツールの操作ではなく業務の理解のほうです。

2つ目は、手を動かして作ったものの説明。自分で組んだ自動化の内容を、対象業務と工程で説明できれば、実務との距離は近づきます。

3つ目は、進め方の設計です。経験が浅くても、どう進めるかを工程で書くことはできます。むしろ、経験が長い人ほど工程の説明を省く傾向があるので、ここは差がつきます。

提案の段階で決めておくべき、取引の条件

ここからは法務の話です。案件を取ることと、取ったあとに困らないことは別の問題なので、両方セットで考えてください。

取引条件は書面かデータで受け取る

2026年時点の制度では、発注者が業務委託をする際、業務の内容、報酬の額、支払期日といった取引条件を書面または電磁的方法で明示することが求められています。つまり、口頭やチャットの会話だけで始めるのは、本来の形ではありません。

これ、フリーランス側から言い出しにくいと感じる方が多いのですが、法令上求められている事項なので、遠慮する必要はありません。「取引条件を書面でいただけますか」と聞くこと自体が、きちんとした相手だという印象になります。制度の詳細は公正取引委員会や厚生労働省の案内で確認できます。

支払期日の考え方

報酬の支払期日についても、成果物を受け取った日から一定期間内に定めることが求められています。「検収後、都合のよいときに」といった曖昧な条件は、本来の形ではありません。

提案の段階で「お支払い条件はどのようになりますでしょうか」と確認しておくと、後から揉めずに済みます。※ 具体的な条件が制度上どう扱われるか判断に迷う場合は、弁護士や行政書士など専門家に相談してください。

修正の範囲を、回数か期間で決める

RPAの案件で最も揉めやすいのが、ここです。動作の修正はどこまでが納品に含まれ、どこからが追加作業なのか。

決め方は2つあります。回数で決める方法と、期間で決める方法です。「納品後2週間以内に発見された不具合の修正は無償」と期間で切るか、「仕様の変更を伴わない修正は3回まで」と回数で切るか。どちらでも構いませんが、決めていないことだけは避けてください。

区別の基準も添えておくと親切です。合意した仕様どおりに動いていないものは不具合、仕様そのものを変えるものは変更。この2語を定義しておくだけで、会話が成立します。

成果物の権利と、再委託の扱い

作ったシナリオの権利がどちらに帰属するかも、決めておく項目です。多くの案件では発注者に帰属しますが、その場合でも、同種の処理を別の案件で作ることが禁じられるのかどうかは別問題です。汎用的な処理まで使えなくなると、こちらの仕事が制限されます。

再委託についても確認が必要です。自分以外の人に一部を頼む予定があるなら、事前に許諾を得ておかないと契約違反になります。

先日も、こういうご相談がありました。納品したシナリオと似た構造のものを別の会社向けに作ったところ、前の発注者から指摘を受けた、という内容です。契約書を確認すると、成果物の権利は発注者に帰属すると書かれていましたが、汎用的な設計手法の使用を禁じる条項はありませんでした。つまり、同じ画面や同じデータをそのまま流用したのでなければ、通常は問題になりにくいケースでした。ただ、こうした判断は契約書の文言次第で変わりますので、迷ったら条項を持って専門家に相談してください。法律は、あなたを縛るためではなく、あなたを守るためにあります。

提案を出す前に、用意しておくもの

毎回ゼロから書いていると、応募数が伸びません。使い回せる部品を先に作っておきます。

用意するのは4つです。1つ目は、対応できる工程を一覧にしたもの。要件の聞き取り、設計、実装、テスト、リリース、保守のうち、どこを担えるかを明記します。全部に丸を付ける必要はありません。むしろ絞ってあるほうが、判断しやすい相手だと受け取られます。

2つ目は、扱えるツールと、そのツールで何をしたことがあるかの説明。ツール名の羅列ではなく、「Power Automateで、受信メールの添付ファイルを指定フォルダへ保存し、内容を表に転記する処理」のように、対象と処理を具体的に書きます。

3つ目は、標準的な進め方の工程表です。案件ごとに調整はしますが、骨格を持っておけば書き出しが速くなります。

4つ目は、見積もりの計算根拠。対象業務1件あたりの想定時間、分岐の多さによる係数、テストにかける時間の割合。この計算を自分の中で決めておくと、金額の説明に一貫性が出ます。

これらを揃えておくと、1件あたりの提案作成時間が短くなります。時間が短くなれば応募数を増やせますし、応募数が増えれば統計的に返信も増えます。案件の取り方で最初に効いてくるのは、この単純な計算です。

初回の打ち合わせで、確認しておきたいこと

提案に返信が来て打ち合わせに進んだら、そこは審査される場であると同時に、こちらが確認する場でもあります。

確認したいのは5点です。対象業務の1日あたりの処理件数。例外パターンがどれくらいあるか。開発環境へのアクセス方法。テストで実データを使うか。そして、決定権を持つのが誰かということです。

特に例外パターンの確認は重要です。「基本的にはこの流れです」と説明を受けたあと、「基本的でないケースは月に何件くらいありますか」と聞いてみてください。ここで数字が返ってこない場合、その業務はまだ整理されていません。整理されていない業務を固定価格で請けると、工数が膨らみます。時間精算にするか、範囲確定のフェーズを分けて見積もるかを検討する場面です。

決定権の所在も見落とせません。打ち合わせに出てきた担当者が決められないなら、仕様の判断のたびに待ち時間が発生します。これは能力の問題ではなく組織の構造なので、事前に把握しておけば工程表に織り込めます。

つまずきやすい進め方

案件を取ったあとに苦しくなる型も、いくつか挙げておきます。注意しておくと避けられます。

最も多いのが、範囲を決めずに着手することです。「まず動くものを見せてください」と言われて作り始め、見せるたびに要望が増えていく。この進め方は、悪意がなくても双方が消耗します。試作を見せること自体は良い方法ですが、試作の目的と、そこから何を決めるのかを先に合意しておいてください。

次に多いのが、口頭の合意で進めることです。打ち合わせで決まった内容を、その日のうちに文章にして送る。この習慣があるかどうかで、後の分かれ目が変わります。記録がないと、記憶の食い違いを埋める手段がなくなります。

3つ目は、成功の基準を決めないことです。何をもって完成とするのか。処理が最後まで通ることか、既存の手作業と同じ結果になることか、想定件数を規定時間内に処理できることか。これを決めていないと、いつまでも終わりません。

4つ目は、対象業務そのものが変わることへの備えがないことです。自動化しようとしていた作業が、途中で会社の方針変更によってなくなる。RPAの案件ではときどき起きます。この場合の扱いを契約に書いておくと、双方が納得できる形で精算できます。

案件をどこで探すか、探し方で結果が変わる

提案文の質と同じくらい、どこに出すかが結果を左右します。

まず、案件の性質が場所によって違います。エージェント経由の案件は、企業の常駐や準常駐が中心で、稼働時間が長めに設定されている傾向があります。一方、直接契約の場になっている場では、成果物単位の小さな案件が見つかりやすくなります。

もう一つの違いが、間に入る取り分です。仲介が何段も入る形だと、発注者が支払う金額と受け手に届く金額の差が広がります。同じ作業をしても手取りが変わるので、どの経路で受けるかは無視できない選択です。

仕事の全体像を確認しておきたい方は、RPA・業務自動化ツールのお仕事に工程ごとの作業内容と必要なスキルがまとめられています。応募先を決める前に、自分がどの工程を担えるかを整理しておくと、提案文の説得力が上がります。RPAに隣接する領域まで視野を広げるなら、AI・マーケティング・セキュリティのお仕事も参考になります。自動化の先にデータ活用の依頼が続くことは珍しくありません。

金額の伝え方で、印象は変わる

提案文で金額を書くとき、注意したい点が2つあります。

1つ目は、幅を持たせすぎないことです。「20万円から60万円」のような広い幅は、見積もれていないと受け取られます。前提を書いたうえで一つの数字を出し、前提が変わる条件を添えるほうが信頼されます。

2つ目は、安さで勝負しないことです。相場より大きく下げた提案は、選ばれても後が苦しくなります。しかも、一度決めた単価を後から上げるのは簡単ではありません。

加えて、支払いの単位をどうするかも伝え方の一部です。成果物一式に対する固定金額なのか、稼働時間に対する時間精算なのか。範囲が固まっている案件なら固定金額のほうが双方にとって分かりやすく、範囲が未確定の案件なら時間精算か、範囲確定までを別見積もりにする形が現実的です。ここを混ぜたまま金額だけ提示すると、後で追加費用の話が切り出しにくくなります。

消費税とインボイス制度の扱いについても、金額を書く際に触れておくと親切です。提示額が税込か税別かを明記し、登録の有無を伝える。募集文の中には登録の有無を問わないと明示しているものもあり、条件は案件ごとに違います。2026年時点の制度上の取り扱いは国税庁の案内で確認できます。

市場の水準を確認しておくと、根拠を持って書けます。RPA開発は分類上ソフトウェア開発の周辺に位置するため、統計に基づくソフトウェア作成者の年収・単価相場が目安になります。提案書や報告書の書き方そのものを整えたい場合は、ビジネス文書検定が扱う範囲が実務に近いところにあります。文章で仕事を受ける方向にも興味があるなら、著述家，記者，編集者の年収・単価相場で周辺職種の水準も見ておくと視野が広がります。技術面の裏付けとしては、ネットワークやセキュリティの基礎を扱うCCNA（シスコ技術者認定）が、社内システムの制約が絡む案件で会話を成立させる材料になります。

運営者として見てきた、案件が続く人の提案

フリーランスと在宅ワークの市場を20年運営してきた立場から見ると、案件を継続的に取れている人の提案文には、はっきりした特徴があります。相手の作業量を減らす設計になっていることです。

答えやすい質問、判断しやすい選択肢、確認しやすい工程表。読んだ相手が次に何をすればよいかが分かる提案は、返信までの時間が短くなります。運営者として見てきた限りでは、返信率の差は文章の巧拙より、この一点で説明がつきました。

もう一つ、長く続く人ほど、単発の受注ではなく関係の作り方に時間を使っています。1件目の提案で全部を取りに行くのではなく、まず小さく始めて、進め方が合うかを互いに確認する。そのうえで範囲を広げていく。この順番を守る人は、次の依頼が向こうから来ます。

金銭面の話もしておきます。中間に何段も取り分が乗る形だと、同じ予算でも受け手に届く額は薄くなります。薄いぶんを件数で埋めようとすると、提案文を書く時間そのものが削られ、一件ごとの質が落ちる。この悪循環はよく見てきました。手数料0%の直接取引が効くのは、金額が跳ね上がるからではなく、同じ仕事量で手取りが厚くなるぶん、一件に丁寧に向き合う余裕が生まれるからです。依頼する側も、同じ予算でより多く頼めます。双方が得をする構造というのは、こういうことです。

提案文は、相手の判断を助ける書類である

ここまで見てきたように、返信が来る提案文と来ない提案文の違いは、文章力ではありません。書いてある情報の種類が違うだけです。

相手の課題を言い換え、進め方を工程で示し、できないことを先に書き、見積もりの根拠を添え、答えやすい質問を3つに絞る。この5つを守れば、経験の長短に関わらず読まれる提案になります。

そして、取れたあとに困らないために、取引条件は提案の段階から確認しておいてください。書面での明示も、支払期日も、修正範囲の合意も、こちらから言い出してよい話です。むしろ言い出せる人のほうが、相手からきちんとした事業者として扱われます。

よくある質問

Q. RPAの案件に応募しても返信が来ません。何を直せばよいですか？

まず提案文の冒頭2行を見直してください。自己紹介から始まっている場合、募集文に書かれた状況を自分の言葉で言い換える内容に差し替えます。加えて、進め方を工程で示し、対応しない範囲を明記し、見積もりの根拠を1行添える。この4点で、比較されたときの見え方が大きく変わります。

Q. 未経験でもRPAの案件に応募してよいのでしょうか？

応募自体は可能ですが、経験がないことを謝る書き方は逆効果です。代わりに、対象業務そのものへの理解、自分で組んだ自動化の内容、進め方の設計の3点を書きます。RPAで難しいのはツール操作より業務の理解なので、経理や人事などの実務経験があれば十分に材料になります。

Q. 提案の段階で、どこまで契約条件を確認すべきですか？

業務内容、報酬額、支払期日、修正対応の範囲、成果物の権利の5点は最低限確認してください。2026年時点の制度では、業務委託の取引条件を書面や電磁的方法で明示することが発注者に求められているため、書面での提示を求めるのは正当な依頼です。判断に迷う条項は専門家に相談してください。

Q. 単価はどのように設定すればよいですか？

安さで勝負するのは避け、前提条件を書いたうえで一つの数字を提示するのが基本です。対象業務の件数、分岐の複雑さ、想定工数を根拠として添えると、金額だけでの比較を避けられます。市場の水準は職種別の年収・単価データで確認でき、根拠を持って提示できると交渉が安定します。