SOWとは？意味と記載項目、受託案件での書き方｜作業範囲記述書のテンプレートと記入例

この記事のポイント（TL;DR）

• SOWは「この案件で、誰が・何を・どこまでやるか」を決める文書です。取引全体に共通する法的な条件は基本契約書で決め、案件ごとの中身をSOWで決める、という分担で使われることが多くあります。
• 上位の解説の多くは、社内プロジェクトの管理や発注側の視点で書かれています。本記事は顧客から仕事を受ける側（制作会社・受託開発・コンサル・フリーランス）に絞り、SOWの下書きを自分から出して合意を取る進め方を扱います。
• 記載項目は12あります。受ける側が特に書き漏らしやすいのは「対象外（やらないこと）」「受入基準」「顧客側が担う作業」「変更の手続き」の4つで、どれも抜けると納品後や追加依頼の場面で止まります。
• 請負か準委任かで、SOWの重心が変わります。請負なら「何をもって完成とするか」、準委任なら「どの事務を、どれだけの稼働で、どう報告するか」です。民法の条文で確かめます。
• 取適法（中小受託取引適正化法）やフリーランス法の対象となる取引では、発注側は「給付の内容」などを書面または電磁的方法で明示しなければなりません。SOWは、その「給付の内容」を具体的にする土台にもなります。
• Web制作の記入例、空欄で使えるテンプレート、運用保守とコンサルティングで足す項目を載せています。

どこから読むか

SOWとは｜意味・読み方・日本語訳

SOWとは、委託する仕事の範囲・成果物・役割分担・期限を、発注側と受注側が合意するための文書です。Statement of Work の頭文字を取った言葉で、「エスオーダブリュー」と読みます。英単語の sow（種をまく）とは関係がありません。

IT用語辞典のe-Wordsは、SOWを次のように説明しています。

SOWとは、複数の組織や主体が共同で進める事業や業務、プロジェクトにおいて、目標、成果物の定義や仕様、スケジュール、作業工程、各主体の役割や分担、責任範囲などを定義した合意文書のこと。

出典: e-Words「SOW（作業範囲記述書 / 作業明細書）とは」。2026年10月21日に確認。

同じページは、SOWがシステム開発や運用保守の契約を結ぶ際に発注者と受注者の間で交わされること、契約を補う文書として扱われることが多いこと、基本契約を個別契約で具体化するときに作られることが多いことにも触れています。

日本語の訳語は「作業範囲記述書」「作業明細書」などが使われ、決まった一つの呼び方はありません。現場では「作業範囲書」「業務範囲書」「業務仕様書」「別紙（業務内容）」といった名前で、実質的に同じ役割の文書を交わしていることもよくあります。名前ではなく、案件の範囲・成果物・役割分担を双方で合意した文書かどうかで考えると、自社の案件にSOWがあるかどうかを判断できます。

Statement of Work と Scope of Work の違い

SOWは、Scope of Work（作業範囲）の略として使われることもあります。厳密には次のように使い分けられます。

つまり、Scope of Work は「範囲」、Statement of Work は「範囲を含む合意の文書」です。会話の中で「SOWを詰める」と言うときは、多くの場合は後者の文書を指しています。どちらの意味で使っているか分からないときは、「範囲の一覧の話ですか、それとも文書全体の話ですか」と一度確かめると、話がかみ合います。

SOWは誰が書くのか

SOWを誰が書くかに決まりはありません。官公庁や大企業の調達では、発注側がSOWに近い仕様書を作り、それに沿って提案を募ることがあります。一方、制作会社や受託開発、コンサルティングの案件では、受注側が下書きを作り、顧客が確認して合意する流れが多く見られます。

受ける側が下書きを書くことには、はっきりした利点があります。作業の分け方、成果物の粒度、顧客に担ってもらう作業、範囲外にすべきものは、実際に作る側のほうがよく分かっているからです。発注側が書いたSOWを受け取る場合でも、「対象外」「受入基準」「顧客側の作業」の欄が空いていれば、受ける側から埋める案を出すほうが、後で止まりにくくなります。

SOWと契約書・RFP・要件定義書・見積書・SLAの違い

SOWは、案件ごとの範囲と役割を決める文書で、法的な条件を決める契約書、選ぶための文書であるRFP、作るものの要件を決める要件定義書とは役割が違います。それぞれ「何を決める文書か」で並べると、次のようになります。

← 横スクロールで全体を表示 →

契約書との違い：法的な条件と、案件の中身

契約書は、損害賠償の上限、知的財産権の帰属、秘密保持、解除の条件など、取引の法的な枠組みを決めます。SOWは、その枠組みの中で「この案件では何をするか」を決めます。継続的に取引する相手とは基本契約を一度結び、案件ごとにSOWを交わす形にすると、法的な条件を毎回交渉し直さずに済みます。

注意したいのは、契約書とSOWの内容がぶつかったときに、どちらが優先するかです。契約書に「個別契約の定めが基本契約に優先する」といった条項が置かれることもあれば、逆の定めもあります。SOWに書いた範囲や受入基準が、契約書のどの条項とつながっているかは、法務担当者に確認しておきましょう。

RFPとの違い：選ぶための文書と、合意するための文書

RFPは、発注側が複数の候補から依頼先を選ぶために出す文書です。RFPに書かれた要望は、まだ合意ではありません。提案と質疑を経て「この範囲で、この体制で、この期限で」と決まった内容を書き直したものがSOWです。RFPの構成や、受け取った側の読み方はRFP（提案依頼書）の意味とRFI・RFQとの違いで詳しく扱っています。

要件定義書との違い：作業の範囲と、作るものの中身

要件定義書は、システムや成果物が「何を満たすべきか」を決める文書です。SOWは「誰がどの作業をどこまでやるか」を決めます。たとえば「会員登録機能を作る」は両方に出てきますが、要件定義書には登録項目や入力チェックの仕様が、SOWには「要件定義は受注側が下書きし顧客が承認する」「テスト用のデータは顧客が用意する」といった作業と役割が書かれます。

システム開発では、要件定義の段階をSOWの作業として先に契約し、要件が固まってから開発の範囲を決めることもあります。要件定義書の項目と書き方は要件定義書の書き方と記載項目にまとめています。

見積書・SLAとの違い

見積書は金額と、その金額の前提を示す文書です。見積書の「前提条件」「除外事項」とSOWの「前提」「対象外」が食い違うと、どちらを根拠にするかで揉めます。見積書を出した後にSOWを書くときは、見積書の前提と除外事項を、そのままSOWへ写すところから始めると食い違いを防げます。見積書の項目は見積書テンプレートと書き方が参考になります。

SLAは、運用保守のように継続して提供するサービスについて、応答時間や稼働率などの水準と測り方を決めるものです。SOWが「何をするか」を決めるのに対し、SLAは「どの水準で提供するか」を決めます。運用保守の案件では、SOWで作業範囲を決め、SLAで水準を決めて、両方を付けることがあります。

SOWに書く12項目

SOWに書く項目は、目的、作業範囲、対象外、成果物、受入基準、スケジュール、体制と役割分担、前提条件、費用と支払条件、変更の手続き、報告と会議体、未決事項の12です。案件の規模によって詳しさは変わりますが、小さな案件でも見出しだけは残し、「該当なし」と書いておくと、書き漏れなのか不要なのかを区別できます。

1〜3: 目的・作業範囲・対象外

目的は、範囲の判断に迷ったときの物差しになります。「コーポレートサイトをリニューアルする」だけでなく、「採用ページからの応募を増やすために、採用情報を探しやすくする」のように、何のための案件かまで書くと、途中で出てくる要望が目的に合うかどうかを、双方で同じ基準で判断できます。

作業範囲は、行う作業を一覧にしたものです。作業の単位は、できるだけ成果物と対応させます。「デザイン」とだけ書くより、「トップページと下層ページ10ページのデザイン（PC・スマートフォン）」と書けば、何をもって終わりかが分かります。作業の分け方はWBSの作り方とテンプレートと同じ考え方で、顧客側の作業も含めて漏れなく分けておくと、次の「体制と役割分担」にそのまま使えます。

対象外は、受ける側が最も書き漏らしやすい項目です。やることの一覧があっても、やらないことが書かれていないと、その空白に顧客は「当然やってくれるもの」を置きます。原稿の作成、写真の撮影、公開後の更新作業、既存データの移行など、顧客が含まれると思いそうなものを名指しで書きます。対象外が書かれていないことが、範囲がじわじわ広がる最大の入口になる理由は、スコープクリープの意味と追加依頼の線引きで詳しく扱っています。

4〜5: 成果物と受入基準

成果物は、名前だけでなく形式と納め方まで書きます。デザインならデザインファイルの形式と書き出し画像の有無、システムならソースコードの納め方と設計書の範囲、コンサルティングなら報告書の版と報告会の回数です。「一式」とだけ書くと、納品の段階で「あれも入っていると思っていた」が起きます。

受入基準は、成果物が合格とみなされる条件です。ここが曖昧だと、納品しても検収が終わらず、請求に進めません。「顧客が満足すること」「問題がないこと」のような主観的な表現ではなく、「合意したページ一覧のすべてのページが、指定のブラウザで表示できること」「テスト項目表の全項目を実施し、重大な不具合が残っていないこと」のように、双方が事実として確かめられる条件で書きます。確認の期間（たとえば「納品から10営業日以内に結果を連絡する」）と、期間内に連絡がなかった場合の扱いも、ここで決めておきます。検収の流れと基準の書き方は検収の意味と検収基準のテンプレートが参考になります。

6〜8: スケジュール・体制・前提条件

スケジュールには、受注側の作業だけでなく、顧客の確認や素材の提供を待つ期間も節目として入れます。「デザイン案の確認：提出から5営業日」のように書いておくと、確認が遅れたときに、納期への影響を事実として伝えられます。

体制と役割分担では、双方の担当者と、決める人（承認者）を書きます。とくに大事なのは、顧客側が担う作業です。原稿の提供、素材の用意、社内の確認と取りまとめ、テスト用データの準備などを、担当と期限つきで書いておきます。役割を1枚にまとめる書き方はプロジェクト体制図の書き方にあります。

前提条件は、範囲・費用・納期が成り立つための条件です。「原稿は所定の期日までに確定版を提供いただく」「対応ブラウザは指定の最新版とする」といった条件を書き、前提が崩れた場合は変更の手続きで扱うと一文添えます。この一文があると、前提が崩れたときの話が、個人の交渉ではなく取り決めの適用になります。

9〜12: 費用・変更の手続き・報告・未決事項

費用と支払条件は、契約書や注文書に書くことも多い項目です。SOWに書く場合は、金額が契約書・注文書と一致しているかを必ず確かめます。追加費用が出るときに、変更ごとに見積もるのか、あらかじめ決めた単価で精算するのかも決めておきます。

変更の手続きは、範囲を変えるときの流れです。「変更の依頼は書面（メールや共有ドキュメントを含む）で受け付け、受注側が費用・納期への影響を示し、顧客の承認を得てから着手する」のように書きます。最後の「承認を得てから着手する」が抜けると、依頼した時点で作業が始まったと受け取られることがあります。

報告と会議体では、定例の頻度、進捗報告の形式、連絡の窓口を決めます。打ち合わせで決まったことを、どこに、誰が記録するかも決めておくと、後で「言った・言わない」になりません。決定事項の残し方は議事録の書き方と顧客との合意の取り方にまとめています。

未決事項は、合意の時点でまだ決まっていないことの一覧です。すべてを決めてから合意するのは現実的ではありません。決まっていないことを空欄のまま進めるのではなく、「何が未決か」「誰が決めるか」「いつまでに決めるか」を書いて残します。

← 横スクロールで全体を表示 →

この図のように、範囲は「やる」「やらない」の2つではなく、「まだ決まっていない」を加えた3つに分けて書きます。未決事項を対象範囲に紛れ込ませると、決まらないまま作業が進み、決まった時点で手戻りになります。

受託でSOWが効く場面｜書き漏らすと起きること

SOWが効くのは、追加の依頼が来たとき、納品後の確認が止まったとき、顧客側の作業が遅れたとき、担当者が替わったときの4つの場面です。どれも、着手前に書いておけば事実の確認で済み、書いていなければ交渉になります。

担当者が替わっても、合意が残る

受託の案件では、途中で顧客側の担当者が替わることがあります。新しい担当者は、前任者とどんな合意をしたかを知りません。口頭やチャットの合意しかないと、範囲の線引きをもう一度最初からやり直すことになります。SOWがあれば、「この案件で合意している範囲はこれです」と1枚で引き継げます。受ける側の担当が替わる場合も同じです。

請負か準委任かでSOWの書き方が変わる

SOWの重心は、契約が請負か準委任かで変わります。請負は仕事の完成に報酬を払う契約なので「完成の条件」を、準委任は事務の処理を委託する契約なので「どの事務を、どれだけの稼働で、どう報告するか」を、とくに具体的に書きます。

民法は、請負を次のように定めています。

請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。

出典: 民法 第632条（e-Gov法令検索）。2026年10月21日に確認。

準委任については、委任の規定を、法律行為でない事務の委託に準用すると定めています。

この節の規定は、法律行為でない事務の委託について準用する。

出典: 民法 第656条（e-Gov法令検索）。2026年10月21日に確認。

さらに、準委任でも、事務の履行によって得られる成果に対して報酬を払う形を取ることができます（民法第648条の2）。この場合は、報酬が成果と結びつくため、成果物と受入基準を請負と同じくらい具体的に書く必要があります。

どちらの契約でも、SOWに書いた内容が契約の中でどう位置づけられるかは、契約書の条項によって変わります。ここでの説明は一般的な整理であり、個別の案件についての法的な助言ではありません。契約の型の選び方や条項の書き方は、法務担当者や弁護士に確認してください。請負と準委任の違いをクライアントワーク全体の視点で整理した内容は、クライアントワークとは何かを整理した記事にあります。

取適法・フリーランス法と「給付の内容」｜SOWが明示の土台になる

取適法やフリーランス法の対象となる取引では、発注側は「給付の内容」などを書面または電磁的方法で明示しなければなりません。SOWは、この「給付の内容」を具体的にするための土台になります。

2026年1月1日に施行された取適法（製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律。旧下請法）は、第4条で次のように定めています。

委託事業者は、中小受託事業者に対し製造委託等をした場合は、直ちに、公正取引委員会規則で定めるところにより、中小受託事業者の給付の内容、製造委託等代金の額、支払期日及び支払方法その他の事項を、書面又は電磁的方法（中略）により中小受託事業者に対し明示しなければならない。

出典: 製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律 第4条（e-Gov法令検索）。2026年10月21日に確認。

フリーランスとの取引についても、2024年11月に施行されたフリーランス法（特定受託事業者に係る取引の適正化等に関する法律）が、第3条で同じく「給付の内容、報酬の額、支払期日その他の事項」の明示を求めています。

業務委託事業者は、特定受託事業者に対し業務委託をした場合は、直ちに、公正取引委員会規則で定めるところにより、特定受託事業者の給付の内容、報酬の額、支払期日その他の事項を、書面又は電磁的方法（中略）により特定受託事業者に対し明示しなければならない。

出典: 特定受託事業者に係る取引の適正化等に関する法律 第3条（e-Gov法令検索）。2026年10月21日に確認。

受ける側にとっての意味

これらの明示の義務を負うのは発注側です。ただ、「給付の内容」が「Webサイト制作一式」のような一行だけだと、何が範囲で、何が変更なのかを後から区別できません。SOWで成果物・範囲・対象外を具体的に書いておくと、明示される「給付の内容」がはっきりし、変更が起きたときに「当初の内容からの変更」として扱いやすくなります。

もう一つは、自社が発注する側になる場面です。制作会社が顧客から受けた案件の一部を、個人のデザイナーやエンジニア、小規模な制作会社に再委託することはよくあります。このとき、再委託先が従業員を使用しない個人などであればフリーランス法により、自社と再委託先の資本金や従業員の数が取適法の基準に当たる取引であれば取適法により、自社が明示の義務を負う側になります。どちらにも当たらない場合でも、顧客とのSOWを、再委託先への発注の内容に分けて書き直しておくと、発注の内容を具体的に伝えられ、明示が必要な取引では「給付の内容」を作りやすくなります。

どの取引にこれらの法律がかかるかは、取引の内容、資本金や従業員の数、相手が従業員を使用しない個人かどうかなどで決まります。事業会社が自社で使うサイトやシステムを直接発注する取引は、取適法の対象外になることが多い点も含め、適用の範囲は検収とは｜取適法の支払期日と、どの取引にかかるかで整理しています。個別の取引が該当するかは、公正取引委員会の相談窓口や法務担当者に確認してください。

SOWのテンプレートと記入例｜Web制作の場合

ここでは、架空の案件「コーポレートサイトのリニューアル」を例に、SOWの記入例を示します。実在の企業や案件のものではありません。金額や日数は説明のための仮の値です。自社の案件に合わせて差し替えてください。

記入例の「対象外」と「未決事項」に注目してください。対象外は、顧客が含まれると思いそうなものを名指しで並べています。未決事項は、決める人と期限をつけて残しています。どちらも空欄にしないことが、このテンプレートで最も大事なところです。

空欄で使えるSOWテンプレート

社内の共有ドキュメントや表計算ソフトにそのまま貼り付けて使える形です。見出しは12項目と同じ順に並べています。

SOW（作業範囲記述書）
案件名：
版：      作成日：      承認日：      承認者（顧客）：      承認者（自社）：

1. 目的・背景
2. 作業範囲（行う作業の一覧）
3. 対象外（行わない作業・作らないもの）
4. 成果物（名前・形式・数量・納め方）
5. 受入基準（合格の条件・確認の方法・確認の期間）
6. スケジュール・マイルストーン（顧客の確認期間を含む）
7. 体制と役割分担（双方の担当者・決める人・顧客側の作業と期限）
8. 前提条件・制約（崩れた場合は変更の手続きで扱う）
9. 費用と支払条件（契約書・注文書と一致させる）
10. 変更の手続き（依頼→影響の提示→承認→着手）
11. 報告と会議体（定例・報告の形式・決定事項の記録場所）
12. 未決事項（内容・決める人・期限）

変更履歴
版／日付／変更した箇所／理由／承認者

冒頭に「版」「承認日」「承認者」の欄を置いているのは、後で「どの版に合意したか」を確かめられるようにするためです。末尾の変更履歴は、合意後に内容を変えたときに使います。

運用保守のSOWで足す項目

運用保守の案件は、SOWで揉めやすい分野です。作るものが決まっている制作と違い、何が起きるかが事前に分からないためです。12項目に加えて、次の項目を書いておきます。

運用保守では、「保守の範囲内だと思っていた改修」が最も揉めやすい依頼です。保守で扱う「修正」と、別の見積りが要る「改修」の境目を、具体例で書いておきます。たとえば「既存の機能が仕様どおりに動かない場合の修正は保守に含む。新しい画面や項目の追加は改修として別途見積もる」のような書き方です。

コンサルティングのSOWで足す項目

コンサルティングは、成果物が報告書や助言で、形が見えにくい仕事です。12項目に加えて、次の点を書いておきます。

• 扱う問いと扱わない問い: 「新規事業の市場調査」なら、対象の市場、地域、期間を決め、事業計画の作成や実行の支援を含むかどうかを書く
• ヒアリングの対象と回数: 顧客側の誰に、何回話を聞くか。対象部門を広げる場合は変更として扱う
• 報告書の版と報告会: 中間報告と最終報告の時期、報告書の版の数、報告会の回数と参加者
• 顧客側の情報提供: 社内データの提供と、その期限。提供されない場合の扱い

SOWを顧客と合意する進め方

SOWの合意は、受注側が下書きを出し、顧客と読み合わせ、未決事項を残したまま承認を記録する、という流れで進めます。全部を決め切ってから合意しようとすると、着手が遅れます。

1. 見積書の前提と除外事項を写して下書きを作る: 見積書を出していれば、その前提条件と除外事項を、SOWの「前提条件」「対象外」にそのまま写すところから始める
2. 顧客側の作業と期限を書き足す: 原稿、素材、確認、社内の取りまとめなど、顧客に担ってもらう作業を担当と期限つきで書く
3. キックオフで読み合わせる: 書面を送るだけでなく、キックオフの場で「対象外」「受入基準」「顧客側の作業」を声に出して確認する
4. 決まらないことは未決事項に移す: その場で決まらないことは、決める人と期限をつけて未決事項に書き、合意を先に進める
5. 承認を記録する: 誰が・いつ・どの版を承認したかを残す。メールの返信でも、共有ドキュメント上の承認でもよい

キックオフで確認すべき項目と進め方は、キックオフミーティングの進め方と決定項目にまとめています。

読み合わせで、顧客に聞いておきたい質問

読み合わせの場では、次の質問を顧客にしておくと、後で出てくる「当然含まれると思っていた」を前もって拾えます。

• 「対象外に挙げたもののうち、含まれていると思っていたものはありますか」
• 「受入基準の確認は、どなたが、どの環境で行いますか」
• 「社内で確認を取る方は、窓口の方のほかにいらっしゃいますか」
• 「原稿や素材の準備で、期限が厳しいものはありますか」
• 「公開後に、どなたがどのくらいの頻度で更新する予定ですか」

最後の質問は、対象外に入れた「公開後の更新作業」を、顧客が誰に頼むつもりでいるかを確かめるためのものです。社内で更新する予定なら、更新手順書が成果物に入っているかの確認につながります。

合意後にSOWを変えるとき｜版と変更記録の残し方

合意したSOWを変えるときは、変更の内容を記録し、影響を示して承認を得たうえで、SOWの版を上げます。変更そのものは悪いことではありません。変更が記録されず、どの版が今の合意なのか分からなくなることが問題です。

変更のたびに、SOWの末尾の変更履歴に次の項目を残します。

これは先ほどの架空の記入例の続きです。版1.1は、未決事項に残していたものが決まり、範囲と公開日を変えた例です。未決事項として最初から残していたので、変更は「決める予定だったことが決まった」として扱えます。版1.2は、対象外にしていたものを範囲に移した例です。対象外を名指しで書いていたので、「対象外だったものを、追加のご依頼として範囲に入れる」と説明できます。

変更依頼の受け付け方と、追加の依頼への返し方の文例は、スコープクリープの意味と追加依頼の線引きで扱っています。範囲の変更が手戻りにつながる仕組みは手戻りの意味と原因4類型が参考になります。

SOWでよくある失敗と対策

SOWでよくある失敗は、作って満足して見返さない、見積書や契約書と食い違う、主観的な言葉で書く、顧客側の作業を書かない、の4つです。

1. 作ったまま、誰も見返さない

SOWを着手時に交わしたきり、共有フォルダの奥にしまってしまう失敗です。追加の依頼が来たときに、担当者がSOWを開かずに判断すると、SOWがあっても範囲は守られません。定例の議題に「範囲の確認」を入れる、変更の依頼を受けたら必ずSOWを開く、と決めておきます。

2. 見積書・契約書と食い違う

見積書の除外事項にあるものがSOWの作業範囲に入っている、契約書の納期とSOWのスケジュールが違う、といった食い違いです。食い違いがあると、相手は自分に都合のよい方を根拠にします。SOWを確定する前に、金額・納期・前提・除外事項の4点を、見積書・注文書・契約書と照らし合わせます。

3. 「適宜」「一式」「大幅な」で書く

「適宜対応する」「デザイン一式」「大幅な修正は別途」のような言葉は、人によって受け取り方が違います。回数、ページ数、対象、工程のように、数えられるもの、指させるもので書き直します。

4. 顧客側の作業を書かない

受注側の作業だけを書いたSOWは、顧客側の作業が遅れたときに役に立ちません。原稿・素材・確認・社内の取りまとめは、顧客にとっても「自分の仕事」として見えていないことが多い作業です。期限つきで書いて、最初の読み合わせで確認しておきます。

SOWを、顧客と同じ場所で最新に保つ

SOWは、合意した後の運用で効果が決まる文書です。ファイルをメールで送り合うと、手元に古い版が残り、どれが最新の合意か分からなくなります。最新の版を顧客と同じ場所に置き、変更の記録をそこに積み上げていくと、「今の範囲はどこまでか」をいつでも同じものを見て確かめられます。

クライアントワークOSのTerasuでは、案件ごとのRoomにページを作り、SOWをそのまま顧客と共有できます。ページは本文の保存に合わせて自動で履歴が作られ、30日間さかのぼって過去のバージョンを確認・復元できます。同じ編集者が短い間に続けて更新した分は1つにまとめられるため、数か月にわたる案件の版の記録は、この記事で紹介した「変更履歴」の表をページ本文に残して管理するのがおすすめです。顧客をRoomの編集者として招待すれば、ページ上のコメントスレッドで範囲の確認をやり取りし、解決したかどうかを残せるので、「どの指摘に、どう答えたか」が散らばりません。社内だけで検討したいメモは、社内限定のページにしておけます。

よくある質問（FAQ）

まとめ

SOW（作業範囲記述書）は、案件ごとに「誰が・何を・どこまで・いつまでに」やるかを決める合意文書です。法的な条件を決める契約書、選ぶための文書であるRFP、作るものの要件を決める要件定義書とは役割が違い、提案・見積りと基本契約の内容を受けて案件の範囲を決め、要件定義・サービス水準・検収の土台になります。

書く項目は、目的、作業範囲、対象外、成果物、受入基準、スケジュール、体制と役割分担、前提条件、費用と支払条件、変更の手続き、報告と会議体、未決事項の12です。受ける側は、対象外・受入基準・顧客側の作業・変更の手続きの4つを、とくに具体的に書きます。請負なら完成の条件を、準委任なら事務の内容と稼働の上限を重く書きます。取適法やフリーランス法の対象となる取引では、明示される「給付の内容」を具体的にする土台にもなります。

SOWは、交わした後に見返し、変更のたびに版を上げて記録してこそ効きます。範囲の線引きと追加依頼への返し方はスコープクリープの意味と追加依頼の線引きに、受入基準から検収までは検収の意味と検収基準のテンプレートに、作るものの要件は要件定義書の書き方と記載項目にまとめています。

本記事の情報について: SOWの定義はe-Words、法令の条文はe-Gov法令検索で、2026年10月21日に確認しています。SOWの記入例・テンプレート・変更履歴の例は、Terasu 編集部が作成した説明用のひな形で、実在の企業や案件のものではありません。個別の契約への当てはめや、取適法・フリーランス法の適用の有無は、法務担当者や弁護士、公正取引委員会の相談窓口に確認してください。

---