アプリ開発契約の注意点｜権利・アカウント管理

スマホアプリ開発の契約では、金額と納期だけでなく、ソースコードの権利、App Store・Google Playのアカウント名義、クラウド環境、検収、変更管理、終了時の引き継ぎを発注前に決めることが重要です。原則は「発注者が自社アカウントとデータを持ち、成果物と例外を契約書で明文化する」です。

スマホアプリは、端末にインストールするアプリ本体だけで動いているとは限りません。会員情報やコンテンツを管理するサーバー、通知配信、決済、アクセス解析、管理画面、App Store・Google Playの設定など、複数の環境や外部サービスを組み合わせるのが一般的です。

そのため、契約時に「アプリを納品してもらう」とだけ定めても、公開後に必要な権利やアカウントが発注者へ揃わないことがあります。本記事では、アプリ開発の発注者が契約前に確認すべき項目を、費用・期間・見積もり・依頼手順とあわせて解説します。

※本記事は契約実務に関する一般的な情報です。個別案件の法的判断は、必要に応じて弁護士などの専門家へご相談ください。

• アプリ開発契約で最初に決める8項目
  • 1. 契約書と仕様書の役割を分ける
  • 2. 納品物と知的財産権を具体化する
  • 3. ストア・クラウド・外部サービスの名義を決める
  • 4. 個人情報とセキュリティの責任を定める
  • 5. 検収と契約不適合への対応を決める
  • 6. 仕様変更の手続きを決める
  • 7. 契約終了時の引き継ぎを決める
  • 8. 再委託の条件を確認する
• 契約形態・追加費用・見積もりの見方
  • 請負契約と準委任契約の使い分け
  • 契約・引き継ぎに関連する追加費用の目安
  • 契約締結までの期間
  • 見積書で確認するチェックリスト
• 発注から公開・引き継ぎまでの進め方
  • ステップ1. 事業目的と公開後の運営体制を整理する
  • ステップ2. アカウントとデータの管理表を作る
  • ステップ3. 同じ条件で見積もりを依頼する
  • ステップ4. 契約書・仕様書・見積書を突き合わせる
  • ステップ5. 開発中も変更履歴と権限を管理する
  • ステップ6. 検収・公開・引き継ぎを分けて完了させる
• よくある失敗と開発会社の見極め方
  • 失敗1. 開発会社名義のストアで公開してしまう
  • 失敗2. 「ソースコード込み」の意味が曖昧だった
  • 失敗3. アプリ本体だけが見積もり対象だった
  • 失敗4. ストア審査通過を無条件で約束した
  • 失敗5. 検収後の修正と保守の境界が曖昧だった
  • 開発会社を選ぶ質問チェックリスト
• まとめ
• よくある質問
  • App StoreやGoogle Playのアカウントは開発会社名義でもよいですか？
  • 開発費を支払えばソースコードの著作権は自社に移りますか？
  • アプリ開発の契約はいつ締結すればよいですか？
  • アプリの納品時に受け取るべきものは何ですか？

アプリ開発契約で最初に決める8項目

契約で優先すべきことは、「誰が、何を、いつまでに行い、何を納品し、公開後に誰が管理するか」を具体化することです。特に次の8項目は、見積もりを依頼する段階から開発会社へ伝えておきましょう。

1. 契約書と仕様書の役割を分ける

アプリ開発では、1つの契約書にすべてを書き込むより、文書ごとの役割を分けたほうが変更や確認を行いやすくなります。

要件定義（＝作るものを決める工程）が完了していないのに、開発一式を固定金額で契約すると、後から追加費用や納期変更が発生しやすくなります。未確定事項は隠さず、「要件定義で決める項目」として切り分けることが大切です。

2. 納品物と知的財産権を具体化する

発注者がよく誤解しやすいのが、「開発費を全額支払えば、ソースコードを含むすべての権利が自動的に手に入る」という点です。実際には、成果物の所有・利用条件や著作権の帰属を契約で確認する必要があります。

納品物には、少なくとも次の候補があります。

• iOS・Androidアプリのソースコード
• サーバーや管理画面のソースコード
• デザインデータ、画像、アイコン
• 画面仕様書、API仕様書、データ項目定義
• テスト仕様書とテスト結果
• ビルド手順（＝ソースコードから公開可能なアプリを作る手順）
• ストア申請用の説明文、画像、設定情報
• 利用している外部サービスとライセンスの一覧
• 運用マニュアル、障害対応手順

著作権を発注者へ移転する場合は、移転対象を契約書で明記します。日本の著作権法上、翻案などに関する権利も含める場合は、契約条項で範囲を確認することが重要です。また、著作者人格権は譲渡できないため、必要に応じて「行使しない」という取り決めを検討します。

一方、開発会社が以前から保有する共通部品、汎用的なプログラム、オープンソースソフトウェア（＝利用条件が公開されたソフトウェア）まで一律に移転するのは現実的ではありません。次の3つを分けて整理すると、双方の認識を合わせやすくなります。

権利をすべて譲渡してもらうことだけが正解ではありません。重要なのは、将来の改修、他社への保守移管、サービス売却など、想定する事業活動を妨げない利用権が確保されていることです。

3. ストア・クラウド・外部サービスの名義を決める

アプリ特有の重要事項が、各種アカウントの契約名義です。継続運営する事業用アプリであれば、原則として発注者自身がアカウントを契約し、開発会社には作業に必要な権限のみを付与します。

開発会社のアカウントで先に構築すると、初期作業を早く始められる場合があります。しかし、契約終了後に移管できるとは限らず、移管時に再審査や設定変更が必要になることもあります。やむを得ず開発会社名義を使う場合は、移管の可否、期限、費用、移管できない項目への対応を契約に定めてください。

認証鍵や管理者パスワードは、メールやチャットへ平文で貼り付けるのではなく、パスワード管理ツールなどの安全な方法で共有します。開発終了後は不要な権限を削除し、必要に応じて鍵やパスワードを更新します。

4. 個人情報とセキュリティの責任を定める

会員登録、位置情報、写真、決済、健康情報などを扱うアプリでは、データの扱いを開発会社任せにしないことが重要です。発注者は、取得する情報、利用目的、保存期間、削除方法、問い合わせ窓口を整理します。

契約・仕様で確認する主な項目は次のとおりです。

• 開発会社が閲覧できるデータの範囲
• 本番データを開発・テストに利用するか
• データを保存する国・地域とサービス
• 通信・保存時の暗号化
• 管理画面へのアクセス制御と操作記録
• 退会時や契約終了時のデータ削除方法
• 情報漏えいが疑われる場合の連絡期限と対応分担
• バックアップの対象、頻度、復元方法
• 再委託先がデータを扱う場合の管理方法

プライバシーポリシーを作るだけでは不十分です。アプリの画面上で取得する同意、OSの権限許可、実際のデータ処理、契約内容が一致しているかを確認してください。

5. 検収と契約不適合への対応を決める

検収とは、納品物が契約や仕様に合っているかを発注者が確認する手続きです。「アプリが起動する」だけでは合格基準になりません。対象OS・端末、主要な利用シナリオ、通信が不安定な場合の挙動、通知、課金、退会などを具体的に確認します。

契約では次の点を定めます。

• 納品の定義と納品方法
• 検収を開始するための条件
• 発注者の検収期間
• 合否を判断する基準
• 不具合の重要度と修正期限
• 検収後に見つかった不具合への対応期間
• ストア審査で差し戻された場合の対応範囲
• 発注者都合の仕様変更との区別

受入テストの具体的な設計は、システム開発の検収方法｜受入テストと注意点も参考にしてください。

6. 仕様変更の手続きを決める

アプリ開発では、画面を確認した後に操作方法を変えたくなることがあります。変更自体が問題なのではなく、費用・納期への影響を確認しないまま口頭で作業を進めることが問題です。

変更管理（＝当初の仕様から変える際の承認手続き）には、次の流れを定めます。

1. 発注者または開発会社が変更内容を記録する
2. 開発会社が追加費用と納期への影響を示す
3. 発注者が実施、保留、見送りを判断する
4. 承認内容を仕様書や課題管理表へ反映する
5. 検収対象と請求時期を更新する

軽微な修正を月何時間まで含めるのか、画面数や機能数が変わった場合に再見積もりするのかも決めておくと、予算を管理しやすくなります。

7. 契約終了時の引き継ぎを決める

開発会社を変更する可能性は、発注時から考慮しておく必要があります。これは開発会社を信用しないという意味ではありません。担当者の変更、開発会社の事業撤退、サービスの売却、内製化など、乗り換えが必要になる理由は複数あります。

契約終了時の取り決めには、次を含めます。

• 最新ソースコードと更新履歴の引き渡し
• 設計・テスト・運用資料の更新
• クラウドやストアの権限移管
• 未完了作業と既知の不具合の一覧
• 新しい委託先への説明会
• 引き継ぎ支援の単価と上限時間
• 開発会社が保持するデータの返却・削除
• 契約終了後も継続する秘密保持義務

「引き継ぎに協力する」とだけ書くのではなく、作業内容、期間、費用の考え方まで定めるのが実務的です。

8. 再委託の条件を確認する

再委託とは、契約した開発会社が業務の一部を別会社や個人へ依頼することです。再委託そのものが直ちに品質低下を意味するわけではありませんが、発注者が体制やデータの取扱者を把握できる状態にする必要があります。

確認項目は以下のとおりです。

• 再委託の有無と担当範囲
• 国内・海外のどこで作業するか
• 発注者の事前承諾を必要とするか
• 秘密保持・セキュリティ条件を再委託先にも課すか
• 品質と納期に対して契約先が責任を負うか
• 再委託先がソースコードや本番データへアクセスするか

契約形態・追加費用・見積もりの見方

アプリ開発では、要件定義から保守までを1つの契約形態に統一するより、工程の確定度に応じて使い分ける方法が適しています。

請負契約と準委任契約の使い分け

請負契約は、合意した成果物の完成を目的とする契約です。仕様と合格基準が明確な開発工程に向いています。準委任契約は、専門的な業務の遂行を依頼する契約であり、作業量や進行に応じて精算する方法が一般的です。

例えば、要件定義は準委任契約で進め、仕様と見積もりが固まった後に開発工程を請負契約へ切り替える方法があります。ただし、契約名称だけで責任範囲が決まるわけではありません。成果物、作業範囲、検収、支払条件を個別に確認してください。

契約・引き継ぎに関連する追加費用の目安

次の金額は、アプリ本体の開発費とは別に発生し得る一般的な目安です。規模、既存資料、セキュリティ要件、専門家への依頼範囲によって変動します。

すべてを追加項目として請求する会社もあれば、開発費やプロジェクト管理費に含める会社もあります。そのため、総額だけを比べるのではなく、どこまでが含まれているかを見てください。

契約締結までの期間

開発会社の選定後、契約条件の確認には一般的に2〜4週間程度を見込みます。大企業のセキュリティ審査、個人情報の取扱確認、複数部門の法務審査がある場合は、1〜2か月程度かかることもあります。

ストアの法人アカウントや決済サービスは、組織確認や審査が必要になる場合があります。公開直前に準備を始めるのではなく、契約交渉と並行して自社アカウントの開設を進めると安全です。

見積書で確認するチェックリスト

見積書には、次の項目が分けて記載されているか確認します。

• 要件定義、デザイン、開発、テスト、申請の費用が分かれている
• iOS・Androidの両方が対象か明記されている
• サーバー、管理画面、外部サービス連携が含まれている
• 対応するOSバージョンと端末条件が記載されている
• ストア審査の差し戻し対応回数が明確である
• ソースコードや設計書などの納品物が記載されている
• アカウント開設、利用料、クラウド料金の負担者が明確である
• 有料ライブラリや外部サービスの費用が示されている
• 仕様変更時の単価と承認方法が決まっている
• 検収後の不具合修正と保守の範囲が分かれている
• 引き継ぎ支援の費用条件が記載されている

画面デザインの作業範囲や見積もり項目については、アプリデザイン費用の相場｜外注の進め方もあわせて確認すると、見積もりの重複や漏れを見つけやすくなります。

発注から公開・引き継ぎまでの進め方

契約条件は、契約書を作る段階で初めて考えるのではなく、相談・見積もり・開発・検収を通じて継続的に管理します。次の6ステップで進めると、契約と実態のずれを抑えられます。

ステップ1. 事業目的と公開後の運営体制を整理する

最初に、誰のどの課題を解決するアプリなのか、収益化するのか、社内用なのか、公開後に誰が問い合わせへ対応するのかを整理します。

依頼前に決めたい項目は次のとおりです。

• アプリの目的と対象利用者
• iOS・Androidの対応方針
• 無料、有料、広告、サブスクリプションなどの収益モデル
• 取り扱う個人情報と決済情報
• 希望公開日と、その日を変更できるか
• 社内の意思決定者と実務担当者
• 公開後の更新・問い合わせ担当者
• 将来的な内製化や委託先変更の可能性

ステップ2. アカウントとデータの管理表を作る

ストア、クラウド、ドメイン、分析、通知、決済などの一覧を作り、契約名義、管理者、請求先、開発会社に与える権限を記録します。

管理表には、パスワードそのものを書かず、保管場所や管理責任者を記載します。担当者個人のメールアドレスではなく、可能な限り会社が継続管理できるメールアドレスを利用します。

ステップ3. 同じ条件で見積もりを依頼する

開発会社ごとに異なる説明をすると、見積もりの比較が難しくなります。機能、対象OS、デザイン範囲、外部連携、納品物、アカウント方針、保守範囲を同じ条件で伝えましょう。

この段階で仕様を完全に決める必要はありません。未確定事項は「提案してほしいこと」「要件定義で判断すること」として区別します。

ステップ4. 契約書・仕様書・見積書を突き合わせる

契約書だけを法務部門へ渡し、仕様書や見積書を別に確認すると、文書間で矛盾が残ることがあります。次の対応関係を確認してください。

• 見積もり対象の機能が仕様書にあるか
• 仕様書の成果物が契約上の納品物になっているか
• 検収条件と支払時期が一致しているか
• 保守対象と契約不適合への対応が重複していないか
• 権利条項が実際の納品物をカバーしているか
• アカウントの名義と費用負担が一致しているか

契約条件やアカウント設計を含め、外注範囲の整理から支援が必要な場合は、開発のご相談はこちらからご相談いただけます。

ステップ5. 開発中も変更履歴と権限を管理する

開発開始後は、打ち合わせで決まった変更を議事録や課題管理ツールへ残します。発注者側の承認者を決め、追加費用が発生する変更は承認前に着手しない運用にします。

また、開発会社の担当者が変わった場合に、不要なアカウント権限が残っていないか確認します。本番環境へのアクセスは、必要な担当者へ限定してください。

ステップ6. 検収・公開・引き継ぎを分けて完了させる

アプリでは、開発会社からテスト版を受け取る日、発注者が検収する日、ストアへ申請する日、一般公開される日が異なる場合があります。どの時点を納品や請求の基準にするか、あらかじめ決めてください。

ストア審査はプラットフォーム運営者が行うため、開発会社が公開日を完全に保証できるものではありません。一方で、審査ガイドラインを踏まえた準備や、実装不備による差し戻しへの対応範囲は契約で定められます。

公開後は、次の引き継ぎ完了チェックを行います。

• 発注者がストアの管理者権限を持っている
• クラウドの契約名義と請求先を確認した
• 最新のソースコードを自社で閲覧・取得できる
• ビルドとリリースの手順が文書化されている
• 外部サービスとライセンスの一覧がある
• 障害時の連絡先と対応時間が決まっている
• バックアップと復元方法を確認した
• 不要なテストアカウントと権限を削除した
• 退会・データ削除の運用を確認した
• 次回OSアップデートへの対応主体が決まっている

よくある失敗と開発会社の見極め方

契約上の失敗は、悪意よりも「当然そうなると思っていた」という認識違いから起きることが少なくありません。口頭の安心感ではなく、見積書・仕様書・契約書へ具体的に反映されているかを確認しましょう。

失敗1. 開発会社名義のストアで公開してしまう

開発会社名義のアカウントで公開すると、委託先変更時にアプリの移管手続きが必要です。サービスによっては移管できない設定があり、継続運営に影響する可能性があります。

回避策は、自社の法人アカウントを早期に開設し、役割に応じた権限を開発会社へ付与することです。開発会社へ相談した際に、自社名義での開設を積極的に案内してくれるかも確認ポイントになります。

失敗2. 「ソースコード込み」の意味が曖昧だった

ソースコードを受け取っても、画像、有料ライブラリ、サーバー設定、ビルド手順が不足していると、別会社がすぐに改修できないことがあります。

回避するには、納品物の名称だけでなく、形式、更新時点、受け渡し方法まで決めます。ソースコード管理サービス上で、開発中から発注者が閲覧できる状態にする方法も有効です。

失敗3. アプリ本体だけが見積もり対象だった

会員登録や通知があるアプリでは、サーバー、データベース、管理画面、メール配信などが必要です。見積もりに含まれていなければ、後から追加費用が発生します。

「アプリで利用者が操作する機能」と「運営者が管理する機能」を分けて確認してください。外部サービスを利用する場合は、初期費用だけでなく月額料金や従量課金も予算へ入れます。

失敗4. ストア審査通過を無条件で約束した

ストア審査は外部プラットフォームの判断を含むため、開発会社だけで結果や日程を確定できません。「必ず特定日に公開できる」という説明より、審査に必要な準備、想定リスク、差し戻し時の対応を具体的に説明する会社を選びましょう。

失敗5. 検収後の修正と保守の境界が曖昧だった

仕様どおりに動かない不具合への対応と、新しいOSへの対応、機能追加、操作改善は性質が異なります。すべてを無償修正と考えると認識違いが起きます。

不具合の定義、無償対応期間、保守開始日、保守に含む作業を分けてください。検収期間中に発注者が確認できる時間と担当者を確保することも重要です。

開発会社を選ぶ質問チェックリスト

候補会社には、次の質問をすると契約・運用への実務対応力を確認できます。

• ストアとクラウドを当社名義で契約できますか
• 開発中から当社がソースコードを閲覧できますか
• 納品物に含まれないものは何ですか
• 既存部品や外部ライブラリの権利はどうなりますか
• 仕様変更はどのように見積もり、承認しますか
• ストア審査で差し戻された場合、どこまで対応しますか
• 再委託先はありますか。本番データへアクセスしますか
• 担当者が交代した際の権限管理はどうしますか
• 契約終了時にどのような資料とデータを引き渡しますか
• 別会社への引き継ぎ支援は可能ですか

発注のご相談を受ける開発会社の立場から見ると、契約条件を細かく確認する発注者は、必ずしも「交渉が厳しい発注者」ではありません。公開後の運用まで考えていることが伝わるため、責任範囲を現実的に設計しやすくなります。

反対に、「すべてお任せで大丈夫です」と説明するだけで、名義、納品物、検収、終了時対応を具体化しない会社には注意が必要です。提案内容と契約条項が一致しているかを確認し、回答は可能な限り書面で残してください。

まとめ

• アプリ開発契約では、金額・納期に加えて権利、アカウント、データ、検収、引き継ぎを決めます
• App Store、Google Play、クラウド、ドメイン、決済などは原則として発注者名義で管理します
• 開発費を支払うだけで、ソースコードを含むすべての権利が自動的に移転するとは限りません
• 新規成果物、開発会社の既存部品、外部ライブラリを分けて利用条件を確認します
• 要件が未確定なら、要件定義と本開発の契約を分ける方法があります
• 見積書ではアプリ本体だけでなく、サーバー、管理画面、申請、外部サービス、引き継ぎを確認します
• 検収日、ストア申請日、一般公開日は異なる可能性があるため、契約上の完了条件を明確にします
• 契約終了時のソースコード、資料、データ、権限の移管方法を発注前に決めておきます
• 法的判断が必要な権利・個人情報・損害賠償の条項は、必要に応じて専門家へ確認します

よくある質問

App StoreやGoogle Playのアカウントは開発会社名義でもよいですか？

技術的には開発会社名義で公開できる場合もありますが、契約終了や会社変更の際に移管が必要になります。移管できない情報や手続き上の制約もあるため、継続運営するアプリは原則として発注者自身の法人アカウントで公開し、開発会社へ必要な権限だけを付与する方法が適しています。

開発費を支払えばソースコードの著作権は自社に移りますか？

開発費を支払っただけで、すべての著作権が当然に発注者へ移転するとは限りません。権利を移転する範囲、既存ライブラリなどの除外対象、著作者人格権を行使しないこと、利用できる範囲を契約書で明確にしてください。

アプリ開発の契約はいつ締結すればよいですか？

秘密情報を共有する前に秘密保持契約を結び、有償作業を始める前に対象工程の契約を締結します。要件が固まっていない場合は、要件定義を準委任契約で先に実施し、その成果を基に開発工程の見積もりと契約を確定する方法があります。

アプリの納品時に受け取るべきものは何ですか？

ソースコードだけでなく、設計資料、画面・API仕様、テスト結果、ビルド手順、利用サービス一覧、ライセンス一覧、ストア申請情報、運用手順、障害時の連絡方法を確認します。認証情報は安全な方法で移管し、納品後に不要な権限や共有用パスワードを見直してください。