1. 結論：SIer・受託開発会社なら、何から始めるか
受託開発でAIを使うなら、最初の一手は「顧客の要望」と「合意した要件」を分け、要件に番号を付けることです。次が変更を原因で区分し、波及範囲と無償対応を可視化すること、その次が外注の発注条件と支払期日を原価台帳と同じ場所から出すことです。
この記事が想定しているのは、顧客から業務システムの開発を受託し、自社または外注の体制で実装する会社です。SaaS事業者、常駐して顧客の指揮命令下で働く形態が中心の場合、保守運用のみを受託する場合は、責任の置かれ方が変わるため範囲外です。
この順番になるのは、受託開発で最も損失の大きい事故が検収の不一致だからです。そして検収の争点は、「それは要件だったのか」という点になりやすいものです。要件に番号が付いていなければ、争点は記憶と印象の勝負になります。
一方で、AIに渡せない領域もはっきりしています。要件の合意、契約方式の決定、指揮命令の設計、支払期日の確定、検収の合意——いずれも人が責任を持つ判断です。
ただ、これは「だからAIは使えない」という話ではありません。要望の整理も、波及範囲の列挙も、テストケースの生成も、無償対応の抽出も、要件IDを起点にAIが担えます。要件IDが無ければ、AIに与えられる入力そのものが存在しません。
2. 業務全体の流れ
受託開発の仕事は、提案から保守までが一本です。
- RFPを受け、目的・機能・非機能・制約・期限に分解する
- NDAを結び、情報の区分を決める——このときAIへの投入可否も決めます
- 現行業務と課題をヒアリングする
- 提案し、概算見積を出す——前提条件と除外条件を明文化します
- 契約方式と責任分界を確定する——請負か準委任かで、責任の内容が変わります
- 要件定義する——顧客の要望を、優先順位と受入条件の合意を経て合意済み要件にします
- アーキテクチャとセキュリティを設計する
- 体制を組み、指揮命令の経路を設計する
- 外注へ発注する——発注内容・代金・支払期日を明示します
- 設計・開発する
- 変更要求を管理する——原因で区分し、要件IDから波及範囲を出します
- テストする——要件IDからテストケースを起こします
- 移行・リリースし、検収して請求する——承認済みの変更が追加請求の根拠です
- 障害・問い合わせ、脆弱性・インシデントに対応する
- 保守を継続し、案件採算を見て、ナレッジに戻す
この流れの特徴は、「不確実性が合意の側にある」ことです。建設や設備工事では、掘るまで分からないという現場の不確実性が中心です。受託開発では、作ってみるまで「求めていたものと違う」と分からない——事実の発見ではなく、合意の失敗です。
3. AI導入優先Top3
Top 1：要望と合意済み要件を分け、要件IDで検収までつなぐ
何をするか。顧客の発言は要望として記録し、優先順位と受入条件の合意を経て合意済み要件（要件ID）にします。要件IDは設計要素・コード・テストケース・受入条件に紐づき、検収時には「合意した要件」との対応表が出ます。
なぜ最初か。受託開発で最も損失の大きい事故を直接防ぐからです。要件IDが無いとTop 2・Top 3も成立しません。
どう始めるか。進行中の1案件で、要件一覧に「合意済み／候補」の列を1つ足すだけから始めます。列を分けた瞬間に、合意していない要件が見えます。
何を測るか。
- 検収時に「合意していない」と指摘された件数
- 要件定義が確定するまでの版数と日数
注意。AIが担うのは、議事録から要求を抽出して要件候補へ整理し、前の版との差分を出すところまでです。合意済み要件への確定は顧客との意思決定であり、要件候補を要件一覧に直接載せないでください。候補と合意済みを同じ表に置くと、元の問題が再発します。
Top 2：変更を原因で区分し、波及範囲と無償対応を可視化する
何をするか。変更要求に区分を付けて変更IDを発番し、波及する要件・設計・テスト・移行を列挙して、原価・納期・請求への影響を出します。
区分は3つでは足りません。 最低限、次を分けておくと費用負担の判断が付きます。
| 区分 | 中身 |
|---|---|
| 要望（新規） | 合意していない機能・振る舞いの追加 |
| 不具合 | 既存の合意済み要件を満たしていない |
| 仕様の解釈違い | 合意はあったが、読み方が食い違った |
| 法令・セキュリティ由来 | 制度改正、脆弱性対応など、当事者の意思と関係なく生じるもの |
| 外部サービス由来 | 連携先のAPI変更・提供終了・仕様変更 |
| 前提条件の変更 | 対象業務・データ量・利用者数・稼働時期など、見積の前提が動いたもの |
後半の3つを「要望」に押し込むと、費用の話が噛み合いません。 顧客の要望ではないのに、追加費用の交渉になります。
どこがAIの仕事か。 波及範囲は「機械的に出せる」ものではありません。 出せるのは、要件IDのトレーサビリティが張られている範囲だけです。AIが担うのは、その範囲をたどって影響しそうな要件・設計・テストの候補を並べることと、変更要求の文面から区分の候補を挙げることです。トレーサビリティが切れているところは、AIにも見えません。波及範囲の確定は人が行います。
なぜ2番目か。採算の低下要因が特定できるようになるからです。無償対応の件数と工数が見えると、見積と契約の改善点が定まります。
どう始めるか。変更要求に区分のラベルを付けるだけから始めます。1か月分の内訳を見れば、どこに手を入れるべきかが分かります。
何を測るか。
- 原因区分別の変更件数
- 無償で対応した変更の件数と工数
注意。無償対応がすべて問題とは限りません。数えることと、なくすことは別です。
Top 3：外注の発注条件と支払期日を、案件の原価台帳と同じ場所から出す
何をするか。外注先ごとに委託の種類と規模基準の該当性を整理し、発注内容・代金・支払期日を明示した書面を、原価管理と同じ台帳から出します。
なぜ3番目か。委託取引への対応と原価管理を同時に解決するからです。法令対応と資金繰りの両方に効き、受託開発会社は「守られる側」でもあるため、同じ構造を自社の債権管理にも使えます。
どう始めるか。外注先ごとに、委託の種類（プログラムの作成かどうか）と規模基準の該当性を整理した一覧を作ります。適用区分が決まれば、支払期日の設定ルールも決まります。
何を測るか。
- 発注時に書面が交付された割合
- 成果物を受領した日から支払までの日数
注意。支払期日の設定と支払手段の適否を確定するのは人です。「守られる側」と「守る側」を別の仕組みで管理すると、片方が必ず抜けます。
4. AIに任せやすい仕事
| 性質 | 受託開発での具体例 |
|---|---|
| 形を整える | RFPを目的・機能・非機能・制約・期限へ分解する。議事録から要求を要件候補へ整理する |
| 照らし合わせる | 要件IDと設計要素の対応表を作る。受入条件と成果物、脆弱性情報と自社の構成・ライブラリを突き合わせる |
| 違いを見つける | 要件候補の前版との差分を出す。見積工数と実績の差異を工程別に出す |
| 足りないものを探す | RFPに無い前提・矛盾・確認事項を抽出する。テストが存在しない要件、請求に結びついていない変更を出す |
| 下書きを作る | 要件IDからテストケース候補を生成する。承認済み変更IDから追加請求の内訳、発注書面、SLA報告を組み立てる |
| 探し出す | 過去の類似案件から工数・構成・リスクを検索する。障害票を要件・原因区分に分類する |
5. AI支援に向く仕事
AIが案を出し、人が確認してから使う領域です。
- 本番データの持ち込み要否とマスキング方針——テスト要件から方針案は出せます。決めるのは人です
- 権利帰属と再利用可否の条項案——汎用部分の切り分け方の案は出せます
- 脅威と対策の候補——構成と脅威情報から候補を並べられます。承認は技術責任者です
- 要員配置の案——要件と工程から必要スキルと配置の案は出せます。指揮命令の経路は人が確定します
- 外注先の適用区分の判定材料——委託の種類と規模基準の該当性の材料は整理できます。判定は人です
- 変更の影響額の試算——類似変更の実績から概算は出せます
6. 人に残す仕事・判断
線の引き方の原則は、「AIが答えを出せるか」ではなく「誰がその答えに責任を持つのか」です。
契約方式によって、責任の内容が変わる
請負は、当事者の一方が仕事を完成することを約し、相手方がその仕事の結果に対して報酬を支払うことを約する契約です（民法第632条）。準委任は、法律行為でない事務の委託であり、委任の規定が準用されます（同法第656条）。
契約不適合についても押さえたい点があります。請負人が契約の内容に適合しない仕事の目的物を引き渡したときでも、注文者の供した材料の性質または注文者の与えた指図によって生じた不適合を理由とする追完請求等は、原則としてできません（同法第636条本文。請負人が不適当と知りながら告げなかったときを除く）。
そして期間の制限です。注文者がその不適合を知った時から1年以内に通知しないときは追完請求等ができません（同法第637条第1項）。引渡し時に請負人が不適合を知り、または重大な過失によって知らなかったときは適用されません（同条第2項）。
「引渡しから1年」ではありません。起算点は「注文者が不適合を知った時」です。
請負・準委任と労働者派遣の区別
労働者派遣とは、自己の雇用する労働者を、当該雇用関係の下に、かつ、他人の指揮命令を受けて、その他人のために労働に従事させることをいいます（労働者派遣法第2条第1号）。
区別の基準は「誰が指揮命令をするか」です。契約の名称ではなく、実態で判断されます。常駐案件では、①作業指示の経路 ②勤怠・労務管理の主体 ③業務の遂行方法の決定権 を、どちらに置くかという設計が必要になります。
この論点について、「最大のリスク」といった順位付けはしません。リスクの重さは案件形態と会社の実情によります。
成果物の権利帰属
法人等の発意に基づき、その法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とするとされています（著作権法第15条第2項）。
プログラムの著作物については、他の著作物と異なり「自己の著作の名義の下に公表するもの」という要件が課されていません。契約で定めなければ、自社の従業員が職務上作成したプログラムの著作者は自社になります。汎用部分をどこまで顧客へ譲渡するかは、資産が残るかどうかの判断です。
ただし、この規定が働くのは「その法人等の業務に従事する者」が職務上作成した場合です。 外注先の会社やフリーランスに書いてもらったコードは、この条文だけでは自社のものになりません。外部に委託した部分の権利帰属は、契約で定めてください。 定めがないまま顧客へ譲渡すると、自社が持っていない権利を渡すことになりかねません。再委託があれば、その先まで通っているかも確認が要ります。
生成されたコードを、そのまま納品物にしない
AIが書いたコードを使うこと自体に問題はありません。問題になるのは、確認せずに納品物へ入れることです。 少なくとも次の4つは、人が確認する対象になります。
| 確認すること | なぜ |
|---|---|
| ライセンス | 学習元や提案元に由来する条件が付く可能性がある。顧客へ譲渡する成果物の権利関係に影響する |
| 脆弱性 | 動作することと、安全であることは別。既知の危険な書き方が混ざりうる |
| 依存ライブラリ | 追加された依存にライセンス・保守状況・脆弱性の問題がないか。依存は後から外しにくい |
| 秘密の混入 | 接続情報・鍵・顧客データがコードやコメントに残っていないか |
この4つは、レビューの観点として明文化しておいてください。 「AIが書いたかどうか」で分けるより、納品物に入るものすべてに同じ確認をかけるほうが運用として続きます。
会社として責任を持つ判断
- 提案するかどうか／AIへの投入可否・外部共有可否の決定
- 真の課題と優先度の合意／価格・契約方式・引き受けるリスクの確定
- 要件・優先順位・受入条件の合意（プロジェクトの核心）
- 方式・セキュリティ設計、重要設計・例外実装の承認
- 指揮命令の経路・勤怠管理・報告主体の確定
- 支払期日の設定と支払手段の適否の確定
- 追加見積・納期変更の合意／品質基準の達成と残課題の扱い
- リリースの可否／検収と追加請求の合意
- 顧客への脆弱性通知の要否・内容・時期
7. Best Practice
ひとつ。要望と合意済み要件を分け、要件IDで設計・テスト・検収までつなぐ。検収の争点は「要件だったかどうか」に集約されます。要件IDが無ければ、記憶の勝負になります。
ふたつ。変更を原因で区分し、要件・設計・テスト・請求へ波及させる。「不具合」なら自社の責任、「要望」なら追加見積、「解釈違い」なら次案件のテンプレートへ戻します。区分が費用負担の起点です。
みっつ。外注と受託の両側で、委託取引の条件を同じ台帳から出す。自社は元請から受託する側であると同時に、外注へ発注する側でもあります。別々の仕組みで管理すると、片方が必ず抜けます。
よっつ。AIへ投入してよい情報を、案件の最初に決めて記録する。NDAと情報区分を整理する工程で、AIへの投入可否も同時に決めます。後から決めると、既に投入された後になります。
なお「同じ台帳から出す」は、すべてを1画面へ平置きすることではありません。要件ID・変更ID・発注を版と状態で関連付け、どれが合意済みかが分かるようにすることです。
8. Before / After
Before。RFPを受け、経験から工数を積み上げて提案します。要件定義では議事録から要件一覧を起こし、顧客のレビューを経て開発へ進みます。変更要求はチケットで受け、小さいものは吸収します。検収では画面と機能を確認して指摘に対応します。外注は付き合いのある会社へ電話で依頼し、請求書を受けて支払います。
この流れには理由があります。要件定義に時間をかけるほど開発期間が短くなり、変更を都度交渉すれば関係が悪くなります。現実的な選択の結果です。
After。顧客の発言は要望として記録され、優先順位と受入条件の合意を経て合意済み要件になります。要件IDが設計・コード・テスト・受入条件に紐づき、変更要求には原因区分が付いて波及範囲の候補が出ます。無償で対応した変更は件数と工数で見えます。外注は、委託の種類と規模基準から適用区分が決まり、発注内容・代金・支払期日が明示されます。
変わるのは開発の速さではありません。「合意したこと」と「合意していないこと」の境界が、いつでも取り出せるようになることです。
9. 法令・規制・情報管理
委託取引の適正化
外注する側になったとき、製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律（旧・下請代金支払遅延等防止法。以下「取適法」）が関わります。適用の判定は、委託の種類と当事者の規模の組み合わせで決まります（同法第2条第8項）。見落とされやすいのが情報成果物作成委託の扱いです。
- プログラムの作成に係る情報成果物作成委託は、資本金3億円超／常時使用する従業員300人超の基準側に置かれます（同項第1号・第5号）。同法第2条第8項第1号の情報成果物及び役務を定める政令第1条が、政令で定める情報成果物を「プログラム」としているためです
- プログラム以外の情報成果物作成委託は、資本金5,000万円超／従業員100人超の基準側です（同項第3号・第6号）
「情報成果物作成委託は一律に100人基準」ではありません。受託開発の中心はプログラムの作成であり、300人基準側が主軸になります。
支払期日についても条文は明確です。代金の支払期日は、検査をするかどうかを問わず、給付を受領した日から起算して60日の期間内において、かつできる限り短い期間内に定めなければなりません（同法第3条第1項）。「検査後60日」ではなく、起算点は「受領した日」です。
また、支払期日の経過後なお支払わないこと（手形の交付、および支払期日までに金銭と引き換えることが困難な支払手段の使用を含みます）は、委託事業者の遵守事項に反します（同法第5条）。
なお、上記の政令は令和8年（2026年）1月1日に施行されています。
個人データを扱う開発
顧客の個人データを扱うシステムを開発・保守する場合、個人データの取扱いの委託に該当することがあります。
個人情報取扱事業者は、個人データの取扱いの全部または一部を委託する場合、委託を受けた者に対する必要かつ適切な監督を行わなければなりません（個人情報保護法第25条）。
この監督義務の名宛人は、委託元＝顧客企業です。受託開発会社は委託先の側にあります。「代わりに監督する」のではなく、「顧客が負う監督義務に応えられる体制を示す」という位置づけになります。
あわせて、利用目的の特定（同法第17条第1項）、利用目的による制限（同法第18条第1項）、第三者提供の制限（同法第27条第1項）が関わります。
AIへ投入してよい情報
受託開発では、顧客の業務データ、システム構成、認証情報、未公開の計画を扱います。次を確認したうえで使います。
- 必要最小限の情報だけを入れる（本番データが要るのか、構造だけで足りるか）
- AI事業者が入力データを学習に使わない設定・契約になっているか
- 保存期間と削除の方法
- NDAと契約上の機密保持・データ取扱条件（顧客との間、外注先との間の両方）
- アクセス権限と操作ログが残るか
- 再委託・国外保管など、顧客の規程上あらかじめ決めておくべき事項
接続情報・鍵・本番の個人データは、原則として投入しないと決めておくほうが安全です。扱うのは会社が利用を承認したアカウント・サービスに限ります。
モデル契約・ガイドラインは法令ではない
IPA（独立行政法人情報処理推進機構）は、情報システムのモデル取引・契約書、要件定義に関するガイド、アジャイル開発版のモデル契約等を公開しています。
これらは法令ではありません。契約実務の参考として広く用いられていますが、法的根拠として扱うものではありません。従っていることが法令の遵守を意味せず、異なる条項を置くことが直ちに問題になるわけでもありません。
なお、アジャイル開発版のモデル契約は準委任を前提とした契約モデルを示すものであり、それが唯一の契約形態であることを意味しません。
資格・認証について
情報処理安全確保支援士、ISMS・PMS等の認証は、業態全体に課される要件ではありません。個別の顧客要求・入札要件として求められることがあるにとどまります。
法令・制度の記述について
※法令・制度に関する記述は、内容確認日時点の一般的な整理です。実際の適用は、業務内容、契約関係、事業規模、地域、施行時点の法令・行政解釈等によって異なります。重要な判断は、最新の一次情報と自社の具体的な条件を確認してください。
10. 最初の30日プラン
1週目：測ることから始めます。
進行中の1案件の変更要求と、直近で検収を終えた1案件を対象にします。測るのは、①変更要求の件数と原因区分の内訳 ②請求に結びつかなかった変更の件数と推定工数 ③検収時の指摘件数と、そのうち「要件だったかどうか」が争点になった件数。この週はAIを使いません。
2週目：ルールを決めます。
要件一覧に「合意済み／候補」の列を追加します。既存案件にも遡って付けます。変更要求の原因区分を定義してチケットのラベルにし、AIへ投入してよい情報の線引きを案件ごとに決める運用を作ります。外注先ごとに、委託の種類と規模基準の該当性を整理します。
3週目：低リスクな範囲でAIを使います。
完了した過去案件で試します。要件候補の前版との差分抽出と、変更の波及範囲の列挙を、過去の案件で試します。出力はすべて「候補」として扱います。
4週目：同じ測り方で比べます。
判断するのは、①原因区分の内訳に偏りが見えたか ②無償対応の工数が把握できたか ③差分抽出の精度が実用に足りたか。「解釈違い」が多いなら要件定義の記述精度の問題、「要望」が多いなら契約の変更ルールの問題です。打ち手が変わります。
11. AI活用成熟度
レベル1：人に依存している。要件も変更の経緯もプロジェクト責任者の記憶にあり、検収の争点も記憶に依存します。
レベル2：台帳やツールがある。課題管理・チケット・工数記録はありますが、要件と変更が別のツールにあり、要件IDで横断できません。
レベル3：一元化されている。要望と合意済み要件が分かれ、要件IDが設計・テスト・受入条件に紐づき、変更に原因区分があります。ここまで来て、はじめてAIに影響分析をさせる意味が出ます。
レベル4：AIが支援している。要件候補の整理・差分抽出・波及範囲の列挙・テストケース生成・脆弱性突合・無償対応の抽出をAIが担い、人は合意・承認・商務判断に時間を使っています。
レベル5：仕組みになっている。この業種のレベル5は「AIが要件を決める」ことではありません。要件の合意は顧客との意思決定であり、そこは動きません。プロジェクト責任者が「合意すべきこと」だけに時間を使えている状態がレベル5です。差分の突合・影響の列挙・カバレッジの集計に時間を使っていない。そして、検収の場で初めて認識のずれが判明することがありません。
12. よくある質問
AIにコードを書かせることは問題ありませんか。
技術的な可否と、契約上の扱いは別の話です。成果物の権利帰属と再利用可否を契約でどう定めているかを先に確認してください。そのうえで、ライセンス・脆弱性・依存ライブラリ・秘密の混入を納品前に確認します（節6）。生成AIが出力したコードの権利関係について、本記事では断定的な結論を置きません。
外注先への支払は、検収してから60日以内でよいですか。
検査をするかどうかを問わず、給付を受領した日から起算して60日の期間内において、かつできる限り短い期間内に定めなければならないとされています（取適法第3条第1項）。起算点は「受領した日」です。
うちは元請から仕事をもらう側なので、取適法は関係ありませんか。
関係します。元請から再委託を受けるときは守られる側になり得ますが、さらに外注へ発注すれば守る側になり得ます。どちらになるかは、当事者の規模と委託の種類で決まります。
常駐案件で、顧客から直接指示を受けても問題ありませんか。
労働者派遣は、雇用関係の下に、かつ他人の指揮命令を受けて労働に従事させることと定義されています（労働者派遣法第2条第1号）。契約の名称ではなく、実態で判断されます。作業指示の経路・勤怠管理の主体・業務遂行方法の決定権をどこに置くかの設計が要ります。
顧客の個人データを扱う開発で、監督義務はどちらにありますか。
監督義務の名宛人は委託元＝顧客企業です（個人情報保護法第25条）。受託開発会社は委託先の側であり、「代わりに監督する」のではなく、顧客が負う監督義務に応えられる体制を示すという位置づけです。
13. 関連する業種の記事
- Web制作会社のAI活用——同じ受託でも、争点が「合意した仕様どおりか」ではなく「公開してよいか」になります
- 中小企業診断士・経営コンサルティングのAI活用——成果物より、定義プロセスの再利用に価値がある点が共通します
- 工務店・注文住宅のAI活用——「掘ったら地盤が悪かった」と「作ったら求めていたものと違った」の対比が分かりやすい例です
シリーズの一覧は業種別AI活用からご覧いただけます。
14. この記事を自社に当てはめたい方へ
同じ受託開発でも、契約形態と案件の規模によって最初の一手は変わります。
請負中心の会社と準委任中心の会社では、検収の争点そのものが違います。前者は「完成の定義」から、後者は「事務処理の範囲」から整理するほうが、無理がありません。
この記事の内容を自社に当てはめるところから始めたい方は、次の診断をお使いください。
15. 無料AI戦略診断／AI顧問サービス
AI戦略診断は無料・登録不要です。回答すると、自社のAI活用がいまどの段階にあるかと、最初に取り組むべき領域が分かります。
より踏み込んだ伴走をご希望の方は、AI顧問サービスもご覧ください。個別のご相談はお問い合わせから承ります（30分の無料リモート面談）。
