システム開発の外注・受注で必ず登場する「発注書（注文書）」。たかが書面、されど書面で、書き方ひとつで「言った／言わない」「成果物の範囲」「追加費用」をめぐるトラブルに直結します。さらに2026年1月1日からは、下請法が「中小受託取引適正化法（取適法）」へと改正され、対象範囲・記載要件・支払ルールが大きく変わりました。
しかし、世の中の発注書解説記事は物品購入を前提にしたものが多く、システム開発のように「成果物の定義が曖昧」「途中で仕様が変わる」「請負と準委任が混在する」といった独自の事情を踏まえた解説はあまり見当たりません。「freeeや弥生のテンプレを真似たけれど、本当に自分の案件で十分なのか確信が持てない」という担当者の方も多いはずです。
本記事ではシステム開発を専業にする立場（受注会社の現場）から、
- 発注書・注文書の定義と役割
- システム開発で特に重要となる記載項目
- 請負契約／準委任契約による書き方の違い
- 2026年取適法・電子帳簿保存法・収入印紙への対応
を、実務で使えるレベルに落とし込んで解説します。発注する側だけでなく、受注する開発会社の営業・経理担当の方にも役立つ内容です。読み終えるころには、自社の発注書フォーマットに何を足し、何を直せばよいかが明確になっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
発注書（注文書）とは
発注書は、買い手（発注者）が売り手（受注者）に対して「この内容で発注します」と意思表示するための書面です。システム開発の現場では、見積書を受けた発注者が見積内容に同意し、正式に開発依頼することを文書で示すために用いられます。
発注書・注文書の定義と役割
発注書（注文書）は、商品やサービスを発注する際に、発注内容・数量・金額・納期などの取引条件を相手方に通知する文書です。法律上「発注書」「注文書」という名称が定義されているわけではなく、商習慣として広く使われています。
主な役割は次の3つです。
- 取引条件の明文化: 何を、いくらで、いつまでに納めるかを明確にし、後日のトラブルを防止する
- 社内稟議・経理処理の証憑: 発注権限者の承認を経たことを示し、経理が支払処理を行うための根拠とする
- 法的義務の履行: 下請法（2026年1月以降は取適法）の適用がある取引では、所定の事項を記載した書面の交付が義務付けられている
発注書と注文書の違い（法的には同じだが使い分けの慣習を解説）
「発注書」と「注文書」は、法的には同じ書面として扱われます。下請法（取適法）が義務付ける書面（いわゆる3条書面、改正後は4条書面）は名称を問わず、必要事項が記載されていれば「発注書」「注文書」「業務委託書」いずれでも有効です。
ただし業界・企業によって慣習的な使い分けが見られます。
用語 | よく使われる場面 |
|---|---|
発注書 | IT・システム開発・コンサルティング・広告などサービス発注 |
注文書 | 物販・製造業の受発注、建設工事 |
業務委託書 | 法務・コンサル・士業など継続的な業務委託 |
システム開発の取引では「発注書」が多く使われていますが、製造業の親会社からシステム子会社へ発注するようなケースでは「注文書」というフォーマットが使われることもあります。書式が違っても、本質的に必要な記載事項は変わりません。
発注書が必要な場面：システム開発における意味
物品購入と異なり、システム開発は「成果物が形に見えにくい」「仕様が途中で変わる」「検収基準が曖昧になりやすい」という特殊性があります。発注書はこの曖昧さを潰すための最初の防波堤です。
物品購入との違い：なぜシステム開発では発注書が特に重要か
物販なら「型番A-100を10個、〇〇円で」と書けばほぼ揃います。一方、システム開発では同じ「Webシステムを作ってほしい」という依頼でも、想定する機能・画面数・性能・運用条件によって工数も金額も大きく異なります。
そのため、発注書だけで取引条件を完結させることが難しく、見積書・要件定義書・基本契約書といった複数の書面とセットで意思を固めるのが通常です。発注書には「対象の見積書番号」「要件定義書のバージョン」「成果物の定義」を紐付けて、何をもって発注したのかをトレースできるようにすることが極めて重要です。
実際、当社（システム開発を専業とする受注会社）の現場でも、発注書に「見積書 No.YYYYMMDD-XX 記載のとおり」と一行書いてあるかどうかで、後日の追加開発が「契約範囲内」か「追加費用対象」かを判断するスピードと正確さが大きく変わります。
契約書・注文請書との役割分担（発注書だけでは契約は成立しない）
発注書は「申込み」の意思表示に過ぎず、それだけで契約は成立しません。受注者が「注文請書」を発行するか、相手方の発注に応じて業務に着手することで、はじめて契約成立とみなされます。
書面の役割を整理すると次のようになります。
書面 | 役割 |
|---|---|
基本契約書（業務委託基本契約書） | 取引全体の枠組み（責任範囲・知財・秘密保持など）を定める |
個別契約書 / 発注書 | 個別案件の納期・金額・成果物を定める |
注文請書 | 受注者が発注を受託したことを示す |
検収書 | 発注者が成果物を確認したことを示す |
システム開発では、まず「基本契約書」を結んでおき、案件ごとに「発注書＋注文請書」で個別契約を成立させる運用が一般的です。基本契約がない取引では、発注書の中に成果物の定義・検収条件・知財・損害賠償の上限などを盛り込まないと、トラブル時の根拠が不足します。
発注書の記載項目と書き方
発注書には、業界・取引にかかわらず共通する基本項目と、システム開発ならではの追加項目があります。両者を分けて整理します。
一般的な必須記載項目
業種を問わず、発注書には次の項目を記載するのが一般的です。
項目 | 内容 |
|---|---|
宛先 | 受注者の正式社名・部署名 |
発行日 | 発注書を発行した日 |
発注番号 | 自社の管理番号（後日の照合に必須） |
件名 | 案件名（例: ECサイト構築開発） |
品名・内訳 | 発注内容の品目・サービス名 |
数量 | 個数・人月・式 など |
単価 | 1単位あたりの金額 |
金額 | 小計／消費税／合計 |
納期 | 納品（検収）期日 |
納品場所 | サーバー、リポジトリURL、本社住所など |
支払条件 | 締日／支払日／振込／手数料負担 |
備考 | 特記事項（例: 見積書番号への参照） |
発注者情報 | 自社の社名・住所・担当者・押印または電子署名 |
システム開発案件特有の記載ポイント
物品購入の延長で発注書を作ると、システム開発では穴ができます。最低でも次の3点は明記してください。
- 要件・成果物の定義: 単に「Webシステム開発一式」とせず、「要件定義書 v1.2 に記載の機能を満たす〇〇システム一式」のように、参照する仕様書のバージョンまで指定する
- 検収条件: 「テスト仕様書に基づくテストの合格をもって検収完了とする」「受領後10営業日以内に検収可否を通知し、通知がない場合はみなし検収とする」など、検収完了の基準と期限を定義する
- 契約類型: 後述する請負か準委任かを明記する。曖昧にすると、瑕疵担保の有無や成果完成義務の有無で揉める
特に「検収」については、システム開発トラブルの最大の発火点です。発注書段階で検収基準と期限を明記しておくと、「いつまでも検収してくれない」「動作不良を理由に支払いを止められた」といった事態を予防できます。
見積書と照合すべきポイント
発注書を作る際には、見積書と齟齬がないかを必ず突合してください。特に以下のポイントは要確認です。
- 見積書の有効期限内であるか
- 数量・単価・金額・税抜／税込の一致
- 想定スケジュールと納期の整合
- 「前提条件」「除外事項」が見積書に記載されている場合、その内容を発注書側でも認識し、必要に応じて備考に転記する
「見積書ではAWS利用料が別途記載されていたのに、発注書で総額〇〇円と書いてしまったため、後日請求できない」といった事故は意外に多く発生します。
請負と準委任で発注書の書き方は変わる
システム開発契約は大きく「請負契約」と「準委任契約」に分かれ、両者で発注書に書くべき内容が変わります。これは多くの一般向け解説記事ではほぼ触れられていない、システム開発特有の論点です。
請負契約の発注書：成果物・納期・金額を明確に
請負契約は「仕事の完成」を目的とした契約です。受注者は完成した成果物の引渡し義務を負い、発注者は成果物の引渡しと引き換えに報酬を支払います（民法632条）。要件が固まり、開発範囲が明確な「設計・実装フェーズ」で多く採用されます（参考: BUSINESS LAWYERS「システム開発契約は請負と準委任どちらを使う？」）。
請負契約の発注書では次の項目を明確化することが最重要です。
- 成果物の特定: 「〇〇システム（要件定義書 v1.2 記載の機能を含む）」のようにバージョンまで指定
- 納期: 「YYYY年MM月DD日までに納品」と明確な期日を記載
- 検収条件・期限: テスト合格基準とみなし検収条項
- 金額: 一括金額（請負の場合、人月ではなく一式）
- 契約不適合責任: 期間（多くは検収後6ヶ月〜1年）
準委任契約の発注書：工数・期間・単価が中心になる理由
準委任契約は「業務の遂行」自体を目的とした契約で、必ずしも成果物の完成までは要求されません（民法656条）。要件定義・PoC・運用支援・SES（システムエンジニアリングサービス）など、要件が固まりきっていない、または継続的な作業をお願いする工程で多く採用されます。
準委任契約の発注書では、成果物よりも「いつ、誰が、どれだけ稼働するか」を明確化します。
- 業務内容: 「〇〇システムの要件定義支援業務」「保守運用業務」など
- 稼働期間: 「YYYY年MM月DD日〜YYYY年MM月DD日」
- 想定工数（人月）または時間単価: 「〇〇エンジニア 1名 × 1人月」「時給〇〇円」
- 精算方法: 固定（成果完成型）／時間精算（履行割合型）／上限下限つき（160h±20hなど）
- 報告義務: 月次稼働報告書の提出など
請負と準委任を混在させた発注書（例: 一括金額なのに業務内容が「支援」止まり）は、契約類型が不明瞭になり、後日「成果物が完成しないのは誰の責任か」で必ず揉めます。発注書冒頭または備考欄に「本案件は請負契約とする」「本案件は準委任契約（履行割合型）とする」と明記することを強く推奨します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
法律・制度への対応（2026年取適法・電子帳簿保存法）
発注書には、複数の法律が関わります。特に2026年1月1日施行の改正下請法（取適法）は、システム開発業界にも大きな影響を与えるため、発注側・受注側双方が把握しておく必要があります。
2026年取適法（旧・下請法）改正：システム開発会社が知っておくべき変更点
2026年1月1日から、従来の「下請法」が「中小受託取引適正化法（通称: 取適法）」に名称変更されたうえで、規制内容が拡充されました（政府広報オンライン「2026年1月から下請法が『取適法』に！」）。改正点を発注書まわりに絞って整理すると次のとおりです。
項目 | 改正前（下請法） | 改正後（取適法・2026年1月〜） |
|---|---|---|
適用判定 | 資本金区分のみ | 資本金区分に加え、従業員数区分も追加（情報成果物作成委託・役務提供委託は常時従業員100人超、製造委託・修理委託は300人超） |
委託内容の明示方法 | 原則書面（紙）／一定要件で電磁的方法 | 電子メール・クラウド等の電磁的方法での提示が明示的に許容 |
支払手段 | 約束手形等も可（120日以内） | 手形・サイトの長い電子記録債権は禁止 |
支払遅延 | 遅延利息（年14.6%） | 同左、加えて減額・遅延に対する規制強化 |
特にシステム開発業界に影響が大きいのは、従業員数区分の導入です。資本金がそれほど大きくない発注企業でも、従業員数が一定規模を超えていれば取適法の規制対象（中小受託取引の発注者）となるケースが増えます。これまで「うちは資本金1,000万円だから下請法対象外」と整理していた企業も、2026年1月以降は再点検が必要です（中小企業庁「2026年1月施行！〜下請法は取適法へ〜改正ポイント説明会」）。
また、約束手形による支払いは禁止され、紙の約束手形・小切手は2027年3月末までに廃止される方針です（ミラサポplus「受注者を守る法！手形払い禁止など『取適法』がもたらす変化」）。
下請法適用時の12の必須記載事項
下請法（取適法）の適用がある取引では、発注時に「直ちに」次の12項目を記載した書面（または電磁的記録）を交付しなければなりません。これは下請法第3条（取適法第4条）で定められた、いわゆる「3条書面（4条書面）」と呼ばれる書面です（公正取引委員会「下請代金支払遅延等防止法第3条に規定する書面に係る参考例」）。
# | 記載事項 |
|---|---|
1 | 親事業者・下請事業者の名称（法人番号でも可） |
2 | 委託をした日 |
3 | 給付の内容（成果物・サービスの内容） |
4 | 給付を受領する期日（役務提供の場合は提供期日または期間） |
5 | 給付を受領する場所 |
6 | 検査をする場合は、検査完了期日 |
7 | 下請代金の額（算定方法でも可） |
8 | 下請代金の支払期日 |
9 | 手形を交付する場合は、手形の金額・満期 |
10 | 一括決済方式を利用する場合の金融機関名等 |
11 | 電子記録債権で支払う場合の電子記録債権の額・支払期日 |
12 | 原材料等を有償支給する場合の品名・数量・対価・引渡日・決済期日・決済方法 |
システム開発の場合、9〜12は該当しないことが多いですが、1〜8は確実に押さえる必要があります。特に「検査完了期日（=検収期日）」を発注書に明記していない発注書をしばしば見かけますが、これは下請法違反のリスクが高いポイントです。注意してください。
電子発行した場合の電子帳簿保存法対応
メール添付PDFやクラウドサービス経由で発注書を電子的に授受した場合、電子帳簿保存法上の「電子取引」に該当し、電子データのまま保存しなければなりません（紙に出力して保存することは原則認められません）。
電子取引の保存要件は大きく2つに整理されます。
- 真実性の確保: タイムスタンプの付与、訂正・削除履歴が残るシステムの利用、または事務処理規程の備付けのいずれかを満たす
- 可視性の確保: 取引年月日・取引金額・取引先で検索できる状態にし、ディスプレイ・プリンタで速やかに表示・印刷できる環境を整備する
詳細は国税庁「電子帳簿保存法一問一答（電子取引関係）」を参照してください。
収入印紙の要否（電子発行なら不要）
注文請書（受注者が発注を受託したことを示す書面）は印紙税法上の課税文書（第2号文書）に該当し、紙で交付した場合には金額に応じた収入印紙の貼付が必要です。一方、発注書（注文書）自体は原則として課税文書ではありません（ただし契約の申込み・承諾の意思表示が一体化した「注文書兼注文請書」は課税対象になる場合があります）。
電子発行の場合は、紙の交付がないため印紙税は課税されません。これは国税庁の質疑応答事例でも明示されています（国税庁「取引先にメール送信した電磁的記録に関する印紙税の取扱い」）。
具体的には次のように整理できます。
書面の種類 | 紙で交付 | 電子で交付 |
|---|---|---|
発注書（注文書） | 原則非課税 | 非課税 |
注文請書 | 課税（金額に応じた印紙貼付） | 非課税 |
注文書兼注文請書 | 課税 | 非課税 |
システム開発の請負契約では、注文請書は数千円〜数万円の印紙が必要になることもあり、電子発行に切り替えるだけで年間数十万円規模のコスト削減につながるケースもあります。
発注書の送付・保存方法
発注書は発行して終わりではなく、送付・保管・検索性まで含めて初めて適切な運用となります。
メール送付時の実務マナー
紙の発注書を郵送するケースは減り、PDFをメール添付やクラウドストレージ経由で送付するのが主流です。実務上のポイントは次のとおりです。
- 件名に「【発注書】案件名・発注番号」を入れる
- 本文に発注内容のサマリ（金額・納期）を3行程度で記載する
- ファイル名は「発注書_案件名_発注番号_発行日.pdf」のように後から検索しやすい命名にする
- パスワードZIP（PPAP）はセキュリティ上もコンプライアンス上も推奨されない。クラウドストレージや電子契約サービスのリンク共有を利用する
- 受領確認の返信を受注者に依頼する（後日のトラブル予防）
電子契約サービスを利用すれば、送付・受領・タイムスタンプ・検索まで一気通貫で電子帳簿保存法の要件を満たせるため、運用負荷が大きく下がります。
保存期間（法人7年〜10年・個人5〜7年）
発注書の保存期間は税法と会社法で定められています。
主体 | 根拠法 | 保存期間 |
|---|---|---|
法人 | 法人税法 | 原則7年（欠損金の繰越期間に応じ最長10年） |
個人事業主（青色申告） | 所得税法 | 原則7年（前々年分の所得が300万円以下の場合は5年） |
個人事業主（白色申告） | 所得税法 | 5年（帳簿は7年、請求書・発注書等の書類は5年） |
電子取引の場合、紙への印刷保存は認められないため、電子データのまま保存要件を満たして保管する必要があります。期間内にいつでも検索・表示できる状態を維持してください。
よくある質問（FAQ）
発注書なしで発注してもいいか？
民法上、発注は口頭・メールなどでも成立するため、発注書なしでも契約自体は有効です。しかし、下請法（取適法）の適用がある取引では発注書（または相当する電磁的記録）の交付が義務付けられており、違反すると勧告・公表の対象になります。
また、適用外の取引であっても、発注書がない場合は「言った／言わない」のトラブルを避ける根拠が乏しくなります。システム開発のような無形成果物の取引では、発注書なしの発注は強く非推奨です。
発注書と契約書はどちらが優先されるか？
一般的には、後に作成された個別の合意が優先されると解釈されます。基本契約書で「個別契約は発注書と注文請書をもって成立する」と定めている場合、発注書の内容（納期・金額・成果物）が個別案件における具体条件として優先します。ただし基本契約書の一般条項（秘密保持・知的財産・損害賠償の上限など）はそのまま生きるのが通例です。
発注書と基本契約書で矛盾がある場合に備え、基本契約書側に「個別契約と本契約の規定が抵触する場合の優先順位」条項を入れておくことを推奨します。
注文請書は必ず返してもらうべきか？
法律上、必ず必要というわけではありません。ただし、契約成立の証拠として注文請書（または受領メール）を残しておくことを強く推奨します。特に下請法（取適法）の適用がある取引では、発注の事実とその内容を記録に残すことが事業者保護にもつながります。
電子発行に切り替えれば、前述のとおり注文請書の収入印紙が不要になるため、受注側のコスト負担も軽減されます。
まとめ：発注書トラブルを防ぐために確認すべきチェックリスト
最後に、システム開発で発注書を作成・受領する際のチェックリストをまとめます。発行前・受領後の両方で活用してください。
【発注側チェックリスト】
- 見積書番号・要件定義書バージョンを発注書本文または備考に紐付けたか
- 成果物の定義を「一式」で済ませず、参照仕様書まで指定したか
- 検収条件と検収期限（みなし検収条項を含む）を明記したか
- 請負か準委任かを明記したか
- 下請法（取適法）の12項目を網羅しているか（特に検査完了期日・支払期日）
- 2026年1月施行の取適法の従業員数区分により、自社が新たに発注者として規制対象に該当しないかを確認したか（情報成果物作成委託・役務提供委託：常時従業員100人超が対象）
- 電子発行する場合、電子帳簿保存法の要件（真実性・可視性）を満たす運用になっているか
【受注側チェックリスト】
- 受領した発注書の内容が見積書と一致しているか（金額・納期・成果物）
- 検収条件・検収期限が明確か。曖昧であれば書面で明確化を依頼したか
- 契約類型（請負／準委任）が明確か
- 注文請書を発行し、契約成立を双方で記録したか（電子なら印紙不要）
- 発注書・注文請書を電子帳簿保存法の要件に沿って保存しているか
発注書は、システム開発という曖昧になりやすい取引を「明文化」する最初の一歩です。本記事のポイントを踏まえて、自社のフォーマットを2026年取適法対応版にアップデートしていきましょう。発注書だけでカバーしきれない要件定義・契約類型の選定・スコープ管理に不安がある場合は、開発実績の豊富な開発会社に相談しながら進めることをおすすめします。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
