AIエージェント開発案件の進め方｜要件定義書と契約で決めること

AIエージェントの開発案件は、普通のシステム開発と同じ部分と、違う部分があります。違うのは、AIの出力に誤りが混じる可能性を消せない点です。そのため、何を約束し、何を約束しないかを、要件定義書と契約に書いておきます。

この記事は、2026年10月に経済産業省・IPA・総務省の公開資料と、e-Gov法令検索の条文で確かめた内容をもとにしています。契約書の作成や個別の判断は、専門家に相談してください。

AIエージェント開発案件の流れ

AIエージェント開発の案件は、次の順で進めると、途中の食い違いを減らせます。n8n の案件のようにワークフローを組む場合も、流れは同じです。

経済産業省の「AIの利用・開発に関する契約チェックリスト」（令和7年2月）は、契約を結ぶ時点でリスクを十分に分析できない場合について触れています。その場合は、1つの契約でリスクを調整するのではなく、後に結ぶ契約で段階的に調整するほうが、実態に合う場合があるとしています。検証と本開発を分けて契約するのは、この考え方に沿った進め方です。

検証の段階で確かめること

• 相手の実際のデータで、AIが必要な形の出力を返せるか
• 誤りがどんな種類の入力で出るか
• AIモデルの利用料が、想定の件数でどのくらいになるか
• 連携するサービスのAPIで、必要な操作ができるか

検証の結果は、短い報告にまとめて相手に渡します。この結果が、次の要件定義書の土台になります。

要件定義書に書く項目

AIエージェントの要件定義書には、普通の機能の一覧に加えて、AIに任せる範囲と、結果の確かめ方を書きます。項目の例は次のとおりです。

入力と出力は、チェックリストでも中心になる考え方です。チェックリストは、ユーザがベンダに渡すものを「インプット」、ベンダが出力・提供するものを「アウトプット」と呼び、まず契約の対象になる情報や成果物を特定することを求めています。要件定義書の段階で、インプットとアウトプットを具体的に書いておくと、後の契約の話が進めやすくなります。

精度の約束のしかた：保証しない範囲を書く

チェックリストは、AIモデルが学習用データにもとづく帰納的な手法で作られるため、完成義務の設定や性能の保証が必ずしも容易でないと述べています。一方で、AIモデルを含むシステムを作る場合は、出力の不確実性を考えた設計が求められるとしています。

そのため、要件定義書と契約では、約束することと約束しないことを分けて書きます。

たとえば、問い合わせの分類を任せる案件なら、相手と一緒に評価用の問い合わせを選び、その例で何件正しく分類できたかを測る、と書きます。合格の目安も、その例で測る数字として決めます。すべての問い合わせで正しく分類することは約束しません。誤りが出た場合に人が直す手順も、要件に入れておきます。

契約の形：請負と準委任

開発を受けるときの契約の形は、民法の請負と準委任を手がかりに考えます。民法第632条は、請負を、仕事を完成することを約し、その結果に対して報酬を支払う契約と定めています。準委任は、法律行為でない事務の委託で、委任の規定が準用されます（第656条）。

準委任では、受けた側は善良な管理者の注意をもって事務を処理する義務を負います（第644条）。成果に対して報酬を払うと決めた場合、成果の引渡しが要るときは、報酬は引渡しと同時に払います（第648条の2）。請負の報酬は、仕事の目的物の引渡しと同時に払います（第633条）。請負では、注文者が不適合を知った時から1年以内に通知しないと、追完や報酬の減額などを求められなくなります（第637条）。

途中で終わる場合の扱いも決めておきます。請負では、仕事が完成しない間、注文者は損害を賠償していつでも解除できます（第641条）。委任は、各当事者がいつでも解除できます（第651条）。AIの案件は検証の結果で中止になることもあるため、それまでの作業の報酬をどう払うかを契約に書いておきます。

ただし、チェックリストは、契約が請負か準委任かを抽象的に議論するより、ユーザが成果の内容や水準をどの程度求めるかが論点になることが多いと述べています。IPAが公開するアジャイル開発版のモデル契約は、機能の追加や優先順位の変更に柔軟に対応するため、準委任契約を前提にしています。IPAは、受託開発と保守運用を対象にしたモデル契約（第二版）も公開しています。条文と解説があるため、契約書を作るときの参考になります。検証の段階は準委任、作るものがはっきりした後は請負、と分ける方法もあります。

従業員を使わない個人が受ける場合は、フリーランス法も関わります。発注する事業者は、給付の内容、報酬の額、支払期日などを書面または電磁的方法で明示します（第3条）。

データと成果物の権利

チェックリストは、開発型の契約で、インプットの利用条件が重要な交渉事項になることが少なくないとしています。典型的なのは、ベンダがサービスの提供目的を超えて、自社の技術の開発にインプットを使いたい場合です。使うのか、使うならどの範囲かを決めます。

成果物の権利も先に決めます。チェックリストは、開発で生まれた知的財産をフォアグラウンドIP、開発と関係なく各当事者が持つ知的財産をバックグラウンドIPと呼んでいます。作業が進むほど、どれがどちらに当たるかが曖昧になりやすいため、開発の初期に認識をすり合わせることを勧めています。

• 預かったデータ：使う目的、保管する場所、契約が終わったときに消すか返すか
• 作ったワークフローやプロンプト：権利がどちらにあるか、相手が改変してよいか
• 前から持っている部品：自分の共通部品を使う場合、相手に使用を許す範囲
• ツールのライセンス：n8n や Dify など、使ったツールの条件に合っているか

インプットに個人データが含まれる場合は、個人情報保護法の第三者提供の規制（第27条）を守る必要があると、チェックリストは指摘しています。外国のAIサービスを使う場合の注意点もまとめられています。個人データを扱う案件では、要件定義書の入力の欄に、含まれる情報と扱い方を書いておきます。

自分の共通部品を残しておくと、別の案件でも使えます。同じ仕組みを複数の会社に納めるようになったら、受託から販売に切り替える選択肢もあります。

納品と検収の決め方

納品と検収では、次の点を決めます。

1. 納品するもの：ワークフローのファイル、設定の手順書、評価に使った例と結果
2. 納品の方法：どこに、どの形式で渡すか。APIキーなどの秘密情報は渡さず、相手が自分で設定する手順を書く
3. 検収の方法：要件定義書の評価用の例で測り、合格の目安を満たすかを見る
4. 検収の期間：相手が確かめる日数と、その間に連絡がない場合の扱い
5. 支払い：検収の後、いつ払うか

発注者が従業員を使う事業者で、受ける側が従業員を使わない個人の場合、フリーランス法第4条により、報酬の支払期日は給付を受け取った日から60日以内のできるだけ短い期間で定めます。検収の期間を長く取っても、この期日は給付を受け取った日から数えます。

納品の後は、保守の契約に移ります。AIモデルの更新や連携先の変更にどう対応するかはAIエージェントの運用保守で説明しています。発注する側の視点はAIエージェント開発の外注、副業で受ける場合の確認はAIエージェントの副業を始める前にをご覧ください。同じAIを複数の会社に提供したい場合は、出品者向けの案内もご覧ください。