準委任契約とは？請負との違い・向くケースと契約時の確認点

Webサービスやスマホアプリの開発、保守運用、SESを外部委託するとき、「準委任契約なら何を任せられるのか」「請負とどちらにすべきか」「進捗や費用をどう確認するか」で迷う担当者は少なくありません。契約名だけで決めると、完成条件、追加作業、支払、終了時の引継ぎで認識がずれるおそれがあります。

この記事では、準委任の基本から請負との違い、アジャイル・SESでの役割分担、締結前の確認事項までを整理します。読後には、工程ごとに完成責任・業務範囲・精算・確認責任を設計するための論点を整理し、法務・調達・経理・情報セキュリティへ確認すべき資料を特定できるようになります。

準委任は契約名だけで判断せず、任せる業務、報酬と確認の方法、変更・終了時の扱いまでをつなげて設計します。

01Section準委任契約とは？完成保証ではなく、合意した業務の遂行を設計する契約

準委任契約とは、法律行為ではない事務を委託する際に、委任に関する規定を準用する民法上の仕組みです。民法第656条では、法律行為でない事務の委託に委任の規定を準用すると定めています。条文の詳細はe-Gov法令検索の民法で確認できます。

開発・保守の発注実務では、契約締結の代理のような法律効果を直接発生させる行為ではなく、専門的な実務処理を依頼する場面で検討されます。たとえば、要件整理、技術調査、保守運用、継続的な改善、プロジェクト支援などです。

善管注意義務と報告義務を実務の言葉で理解する

民法の委任規定には、受託者が善良な管理者の注意をもって事務を処理すること、発注者から求められた場合に処理状況を報告すること、終了後に経過と結果を報告することが定められています。準委任でも、これらの規定が基本ルールとして参照されます。

善管注意義務は、受託者が合意した業務の専門家として通常期待される注意を払い、契約内容と業務の性質に沿って合理的に進める責任です。完成したシステム、売上、事業上の成果を当然に保証する意味ではありません。

報告義務は、発注者が業務の状況と結果を確認できるようにする基本ルールです。開発案件では、作業実績、進捗、課題、中間成果物、業務結果を、誰が・いつ・どの記録で確認するかを決めておくことが重要になります。

完成物や品質を求めるなら、個別に条件を定める

準委任であっても、設計書、調査報告書、ソースコード、テスト結果などの提出を求めることはあります。ただし、成果物があることだけで、完成責任や修正義務の内容まで決まるわけではありません。

発注時には、少なくとも次の点を個別契約、別紙、作業計画、変更記録で具体化します。

• 完成させる対象、または継続して処理する業務
• 提出する成果物と提出形式
• 品質、期限、確認方法、修正の範囲
• 報酬が発生する条件と精算の根拠
• 終了時に引き継ぐ成果物、データ、アカウント、手順

02Section請負との違いは、完成責任だけでなく報酬・変更・確認方法で見る

比較の中心は完成責任だけではありません。報酬の発生条件、変更時の扱い、発注者が担う確認も合わせて確認します。

請負は、民法第632条で「仕事の完成」と報酬を基本構造とする契約です。一方、準委任では、合意した専門業務を適切に遂行し、報告することが中心になります。情報システム取引では、仕様、プロジェクト管理、確認方法について当事者間の共通理解をつくることが重要です。IPA「情報システム・モデル取引・契約書（第二版）」も、こうした確認観点を扱っています。

支払、不備の修正、途中終了時の精算は、契約名だけで一律に決まりません。報酬の発生条件、確認基準、修正範囲、終了時精算、引継ぎの条項をまとめて照合しましょう。

要件定義は準委任、完成条件を固定しやすい実装部分は請負、保守改善は準委任というように、工程・業務単位で組み合わせる設計も検討できます。契約類型をまたいで条項を確認する際は、IT契約のチェックポイントも参考になります。

03Section履行割合型・成果完成型準委任は、報酬条件と確認方法で分ける

どちらの型でも、報酬の基準、確認方法、変更・終了時の精算を個別の条件として明確にします。

準委任の報酬設計では、業務の履行や実績に応じて支払う履行割合型と、委任事務の履行によって得られる成果への報酬を定める成果完成型を区別して検討します。

ここでいう「成果完成型準委任」は、民法第648条の2（成果等に対する報酬）を前提にした説明語です。条文上の固定用語とは限りません。条文はe-Gov法令検索の民法で確認できます。IPA「情報システム・モデル取引・契約書（第二版）」でも、準委任の対価設計として履行割合型と成果完成型の整理が示されています。

業績や達成度に連動する成果報酬・インセンティブは、成果完成型準委任と同義ではありません。両方を置く場合は、業務または成果への対価と追加の業績連動報酬を分け、算定指標や測定時点を定めます。

成果物の提出や成果への報酬を定めたことだけでは、請負と同じ完成義務や検査・修正の扱いになるとは限りません。完成義務、成果の提出・確認、修正範囲、支払条件、中途終了時の精算を、条項全体で確認してください。

04Sectionアジャイル開発・SESで準委任を使う場合の役割分担

要件や優先順位が変わりやすい開発、継続的な技術支援では、変化を前提に役割分担と確認の仕組みを置く必要があります。準委任は、こうした変化を放置するためではなく、発注者の意思決定と受託者の自律的な業務遂行を明確にするために検討されます。

アジャイルでは、発注者の判断と受託者の作業判断を分ける

アジャイル開発では、発注者が要求事項、優先順位、受入れ観点、事業上の制約、契約上の変更承認を担います。受託者は、実現方法、作業の分解、担当者への割付、日々の進め方を自律的に決めます。

レビューは、請負における完成検収と同一ではありません。優先した業務が進んでいるか、中間成果が受入れ観点に沿っているか、品質上の課題がないか、次に何を優先するかを確認し、必要な変更を記録する場として設計します。役割分担や変更管理の詳細は、IPA「情報システム・モデル取引・契約書（アジャイル開発版）」およびアジャイル開発の進め方で確認できます。

SESでは、受託者側の責任者を介して依頼・調整する

SES・業務委託では、会議、チャット、チケット管理ツールを共同利用すること自体が直ちに問題となるわけではありません。一方で、契約形式にかかわらず、発注者が受託者側の個々の担当者へ直接的な指揮命令を行う実態がある場合は、注意が必要です。厚生労働省「37号告示関係疑義応答集（第3集）」は、アジャイル型開発を含め、実態として指揮命令関係がある場合の考え方を示しています。

発注者は、依頼の背景、要求、優先度、受入れ観点、期限、変更承認を提示します。受託者側は、担当者の配置、作業方法、作業順序、労働時間、休暇などの労務管理を担います。必要な依頼や是正は、受託者側の責任者または合意した窓口を通して行い、判断内容を記録に残します。SESの契約・運用上の確認は、SES契約とはも参照してください。

05Section準委任では検収の代わりに、確認・承認の流れを設計する

準委任では、実績・進捗・中間成果物・業務結果を段階的に確認し、支払や変更、次工程の判断につなげます。

準委任で必要なのは、「検収があるか、ないか」という二択ではありません。作業実績、進捗、中間成果物、業務結果を段階的に確認し、支払、変更、次工程への移行判断につなげます。

承認者、確認期限、変更を有効にする記録、予算・稼働上限の警告時点は、契約期間と発注者側の体制に合わせて決めます。確認できないまま支払や追加依頼が進まないように設計することが大切です。

06Section契約締結前は、必須5論点を契約書と運用文書で照合する

準委任契約では、契約書だけでなく、個別契約、見積書、作業計画、報告様式、変更記録、引継ぎ台帳の内容が矛盾していないかを確認します。契約上の条件と、日々の運用で残す記録をつなげることが重要です。

案件の内容によっては、再委託、個人情報・セキュリティ、知的財産・OSS・外部サービス、損害賠償・紛争解決も早い段階で確認します。個人データを扱う場合は、個人情報保護委員会「個人情報保護法ガイドライン（通則編）」が確認先になります。

07Section印紙税は契約名ではなく、作成する文書と締結運用で確認する

準委任契約という名称だけで、印紙税の要否を一律に判断することはできません。契約書案、個別契約書、注文書・注文請書、変更契約書など、実際に作成する文書ごとに、記載内容と文書類型を確認します。国税庁「No.7104 継続的取引の基本となる契約書」も、継続的取引の基本となる契約書についての確認観点を示しています。

締結前には、作成する文書の一覧、紙・電子の締結方式、相手方への交付方法、変更時に作成する文書を整理し、経理・税務担当へ共有します。判断が難しい場合は、国税庁資料や税務の専門家への確認を検討してください。

08Section自社案件に当てはめる一次判定：工程ごとに契約設計を決める

最後に、契約名称を先に決めるのではなく、各工程の性質と発注者側の確認体制を基準に候補を絞ります。次の表は社内検討のための一次判定です。個別案件の法的評価は、契約書案、別紙、見積書、実際の運用を踏まえて法務などの担当者と確認してください。

発注前には、対象工程、固定済み・未確定の要件、必要成果物、発注者側の責任者、予算上限と引継ぎ要件を整理します。準委任を選ぶ場合も、受託者へ任せる業務と、発注者が決めて確認する事項を分けておくことで、変更や途中終了が起きた際の対応を進めやすくなります。

開発の依頼範囲と体制を整理したい場合

要件が固まりきっていない段階でも、対象工程、必要な成果物、確認体制、予算上限を整理したうえで、開発パートナーを比較できます。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発のパートナーを探す