最終更新日: 2026年10月10日／内容確認日: 2026年10月10日
本記事では、事業者から受託して、スマートフォン向けのアプリ（iOS・Android）の要件定義・画面の設計・開発・テスト・ストアへの申請の支援・公開後の運用保守（OSの新しい版・ストアの要件の変更・外部サービスの更新への追従、不具合の修正）を行う、従業員数名〜数十名の受託開発会社を主なモデルとして想定します。アプリの機能に必要なサーバ側（API・管理画面）は、アプリが主たる成果物である案件に付随する範囲で含めます。開発者アカウントの名義は顧客とし、自社は付与された権限で操作します。この対象は本記事の設計上の前提で、業界の典型像ではありません。消費者からの受託、自社アプリの開発・運営、ゲームの開発、組込みソフトウェア、アプリの広告の運用・集客の代行、顧客の指揮命令の下での常駐、基幹システム・大規模の業務システム・多重の下請は、本記事では扱いません。
法令は2026年10月9日に確認した、その日に施行されている版によります（節9）。
1. 結論：アプリ開発会社なら何から始めるか
アプリ開発会社でAIを使うなら、最初の一手は「ビルドの版を鍵に、テスト・検収・提出の前の照合・顧客の提出の承認・審査・公開を一本の台帳にすること」です。次に「組み込む外部サービス・ライブラリをアプリの版ごとの台帳にし、ストアの申告の案と顧客への外部送信の材料の元にすること」、その次に「要望と合意した要件の版を分け、画面・テスト・検収が要件の版を指すようにすること」が続きます。
番号は効果の大きさの順位で、そのTopで作る台帳・記録を材料に使う業務の数（本記事の業務の分解で数えた計算値で16・11・10）で比べました。時間・費用の削減の大きさや法令上の重要度の順位ではありません。ビルドの版の台帳は提出から保守・引渡し・請求まで使うため、Top1が最も広くなります。実施の順序も同じです（節3）。
一方で、受けるか、契約の条件、要件の合意、採用する外部サービス、提出するか、保守の対応は人が決めます。本記事の設計では、提出・公開の承認と、外部送信・前払の機能・メッセージの機能に関する法令の当てはめは顧客に残します（節6）。本記事を貫く原則は「AIは候補まで、確定は人と顧客」です。
2. 業務全体の流れ
本記事のモデルでは、1つのアプリの仕事は次の流れで進みます。
- 受注。受ける範囲の判断、目的・既存のアプリ・端末・外部連携の聞き取り、開発と運用保守を分けた提案と見積、契約。
- 合意。要件定義と合意、画面の設計と承認、開発の方式・対応するOSの下限・外部サービスとライブラリの選定。
- 実装と検証。開発とビルド、端末とOSの組合せのテスト、顧客の受入テストと検収。
- 公開。ストアの掲載情報と申告の案、提出の前の照合、顧客が承認した版の提出、審査への対応と公開。
- 継続。運用保守と、障害・脆弱性への対応。
- 終了とお金。ソースコード・鍵・権限の引渡しと返上、契約の型に応じた請求と入金の消込（収益の入口）、外注への支払。
本シリーズでは、この業態を、作る画面・機能・対応するOSの版・外部サービスが着手の時点では決まらず、聞き取りと要件の合意・試作のレビューで定まる「知的案件プロジェクト型」を主、公開後の運用保守と月額の請求が周期で反復する「周期型」を従と整理しています。
3. AI導入優先Top3
| 業務マップ上の範囲 | 記録の単位 | 実施の順序 | 導入前提 | |
|---|---|---|---|---|
| Top1：ビルドの版の台帳 | 最も広い（16） | 1ビルド番号1行（アプリ・OSごと） | ①（2週目から） | ビルド番号を採番している |
| Top2：外部サービス・ライブラリの台帳 | 2番目（11） | アプリの版ごとに1外部サービス1行 | ②（3週目から） | 採用した外部サービスの一覧がある |
| Top3：要件の版と合意の記録 | 3番目（10） | 1要件ID1行（版ごと） | ③（新しい案件で3週目から） | 新しい案件の要件定義の工程がある |
どのTopも、他のTopの完了を前提にしません。
Top1：ビルドの版を鍵に、テスト・検収・照合・承認・提出・公開を一本の台帳にする
何をするか。 ビルドごとに、どのコードの版・どの外部サービスの版から作ったかを採番して記録し、テストの結果、顧客の検収の結果、提出・審査・公開を同じビルド番号の行に結びます。提出の前には、検収の結果・本番の設定・ストアの申告の案と外部サービスの台帳の一致・外部送信と前払の機能についての顧客の回答を照合します。本記事の設計では、顧客の提出の承認の記録が無い版、照合で不一致が残る版、外部送信についての顧客の回答が「該当で通知又は公表の方法が決まっていない」か「未確認」の版は提出しません。AIは記録の集約と、照合の不一致の候補を出します。
なぜ最も広いか。 本記事の分解では、この台帳を受入テストに出す版の判定、検収の対応表、保守と脆弱性の影響の抽出、引渡し物の一覧、請求の下書きなど16の業務が使います。
どう始めるか。 進行中の1案件で、次のビルドから、ビルド番号・テストの結果・顧客の承認の記録の欄（承認の日と承認者）を1つの表に並べます。集約は欠け・不一致だけを人が見て、提出の前の照合は担当者が全件確認します。提出するかは責任者が判断し、提出の操作は人が行います。
何を測るか。 提出の前に顧客の承認の記録が揃っていた版の割合、照合で見つかった不一致の件数、リジェクトの件数。承認の記録の無い版の提出は0を前提とし、改善の目標にしません。
注意。 照合の結果を顧客の承認の代わりにしません。照合と提出しない条件は本記事の業務上の止めで、法令の要件ではありません。
Top2：アプリに組み込む外部サービス・ライブラリを版ごとの台帳にし、申告と外部送信の材料の元にする
何をするか。 組み込む外部サービス（SDK）・ライブラリごとに、名称・版・ライセンス・アプリから送信される利用者に関する情報の内容・送信先で情報を取り扱う者の氏名又は名称・利用目的・端末の権限を、提供元の資料と設定で確かめて台帳にします。送信の3つの列は、電気通信事業法施行規則第22条の2の29が情報送信指令通信ごとに定める事項に合わせます。台帳から、ストアの申告（Appleのプライバシーに関する詳細情報・Google Playのデータ セーフティ）の案と顧客への外部送信の材料を作り、顧客の回答を記録します。AIは台帳と申告の案を作り、担当者が全件確認します。
なぜ2番目か。 本記事の分解では、この台帳を採用の決定、顧客への材料の提出、脆弱性・ライセンスの照合、申告の案、提出の前の照合、OSの更新の影響の抽出など11の業務が使います。
どう始めるか。 2週目に列を決め、3週目に、次に申告を更新する1アプリで、組み込んでいる外部サービスを台帳に起こします。
何を測るか。 申告の案の作成にかかった時間、申告の案と外部サービスの台帳の不一致の件数、台帳に無い外部サービスの件数。
注意。 台帳は、顧客が外部送信の規律の義務者に当たるかの判断ではありません（節9）。
Top3：要望と合意した要件の版を分け、画面・テスト・検収が版を指すようにする
何をするか。 打合せの記録から要件の候補（機能・画面・対応するOSと端末・端末の権限・外部連携・データの扱い）を整理し、版の差分で合意した要件と合意しない要件を分け、合意の後に要件の版を登録します。画面の設計・テストケース・検収の対応表・変更の影響の範囲は、要件の版のIDを指します。本記事の設計では、前払の機能・利用者間のメッセージの機能を含む要件は、法令の当てはめについての顧客の回答が「未確認」の間は合意しません。AIは候補と差分を出します。
なぜ3番目か。 本記事の分解では、要件の版を、合意、画面の設計、技術の選定、開発、テスト、検収の対応表、変更の影響の範囲など10の業務が使います。
どう始めるか。 次に始まる新しい案件の要件定義で、要件の一覧に「合意／合意しない／未確定」の列を足します。要件の候補は担当者が全件確認し、合意は顧客と責任者が決めます。
何を測るか。 検収の時点で「合意していない要望」と区分された指摘の件数。
注意。 要件の候補を合意済みとして扱いません。法令の当てはめは、本記事の設計では顧客が行います（節6）。
4. AIに任せやすい仕事
結果をそのまま次へ渡せる仕事です。照らし合わせる相手は、人が確定した記録です。
- 形を整える。 ビルドの版の採番の記録、テストの結果、検収の結果と受領の日、提出・審査・公開の台帳の更新、受注の登録、引渡し物の一覧。
- 照らし合わせる。 ライブラリの脆弱性情報・ライセンスと外部サービスの台帳、入金と請求、AIへの入力の記録と決めた条件。
- 違いを見つける。 要件の版の差分（解釈が要る差分は人が見ます）。
- 足りないものを探す。 入金の無い請求（未収）。
- 下書きを作る。 受注の登録・検収の結果・変更と保守の記録からの請求の下書き（記録と合わない差だけを人が見て、確定と送付は人が行います）。
- 探し出す。 見張る先をOS・ストアの運営者と外部サービスの提供元の公式の公表に固定した変更・脆弱性の収集と、影響を受けるアプリと版の抽出。拾ったものは候補で、担当者が定期的に公式の情報と適用の時点を確かめます。
5. AI支援に向く仕事
AIが候補や文案を作り、担当者が全件確認してから使う仕事です。確認を挟むことは手間ではなく、品質の設計です。
- 提出の前の照合の不一致の候補、ストアの掲載情報と申告の案
- 外部サービス・ライブラリの台帳の案
- 要件の候補と、法令の当てはめの確認が要る機能（前払の機能・メッセージの機能・外部送信）の抽出、顧客への確認の依頼の文案
- コードの候補（開発者が全件確認し、作成者と別の者がレビューしてから取り込みます）、テストケースの案、検収の依頼書と対応表
- 審査の結果への対応の候補、保守の提案、状況の報告、漏えい等の事実の整理
6. 人に残す仕事・判断
線の引き方の原則は「AIが答えを出せるか」ではなく「誰がその答えに責任を持つのか」です。以下は、事業者として自社が負う判断です。
- 受注と契約。 受けるか、提案と見積、契約の型と条件（報酬・検収・報告・権利・個人データの取扱い・再委託）。
- 合意と品質。 要件の合意、画面の設計の確定、採用する外部サービス・ライブラリ、不具合の修正、受入テストに出す版、不合格・条件付きの扱い。
- 公開と保守。 提出するか、変更の合意、保守の対応をするかと時期、障害のときの暫定の対応と修正の版。
- お金・情報・人。 未収の回収、外注するかと条件、受け取る個人データの区分、漏えい等の事案への対応、AI・外部サービスに入力してよい情報の範囲と条件、案件への配置。
顧客が決めること。 本記事の設計では、提出・公開の承認、公開するストアと決済の方式、外部送信・前払の機能・メッセージの機能についての法令の当てはめを顧客の側に置き、自社は材料の提出、確認の依頼、回答と決定の記録に限ります。
AIの照合や候補が9割正しくても、ここに挙げたものは人と顧客が決めます。修正の版も、照合と顧客の承認を省きません。
7. Best Practice
本シリーズでは、到達点を、「何を合意したか」「どの版を誰が確かめて出したか」「アプリが何をどこへ送るか」がそれぞれ一本の記録で辿れる構造と整理しています。第一に、ビルド番号ごとにテストの結果・検収・照合・顧客の承認・審査・公開がつながり、承認と照合の揃わない版はストアに出ない。第二に、外部サービスの台帳が、ストアの申告・外部送信の材料・脆弱性の照合の元になっている。第三に、要件の版が合意した要件と合意しない要件を分け、画面・テスト・検収がその版を指す。
8. Before / After
Before。本記事が改善の出発点として置いた設計上の比較の基準で、業界の実態の描写ではありません。 ビルド・テスト・検収・提出と公開の記録がビルド番号で結ばれておらず、提出の前の照合は別々の記録を突き合わせる作業になる。外部サービスの台帳が無く、申告の案・外部送信の材料・脆弱性の照合を別々に起こす。要件の版が無く、テストケースと検収の対応表は要望の一覧を指す。
After。到達点として置いた姿です。 提出の前の照合はビルド番号の1行の上で行え、申告の案と外部送信の材料は同じ台帳から出て、画面・テスト・検収・変更が要件の版を指します。提出の承認と法令の当てはめは顧客に残ったままです。
9. 法令・規制・情報管理
以下は本記事の実務上の整理で、条文を確かめた規律だけを挙げており、すべての規律ではありません。法令は2026年10月9日に確認した、その日に施行されている版によります。未施行の改正は扱っていません。
ストアの指針は法令ではありません。 Appleは提出の際にプライバシーに関する詳細情報の提供を必須とし、Google Playはサードパーティのライブラリ・SDKを通じたデータを含めた申告の責任をデベロッパーに置いています。本記事では、ストアの審査の指針と申告の求めを、法令ではなく、運営者と開発者アカウントの名義人との間の契約・運用の基準として扱います。
外部送信の規律。 電気通信事業法第27条の12は、電気通信事業者又は第三号事業を営む者（内容、利用者の範囲及び利用状況を勘案して利用者の利益に及ぼす影響が少なくないものとして総務省令で定める電気通信役務を提供する者に限る）に、その利用者に対し電気通信役務を提供する際に、利用者の電気通信設備を送信先とする情報送信指令通信（利用者の電気通信設備に記録された利用者に関する情報を利用者以外の者の電気通信設備に送信する機能を起動する指令を与える電気通信の送信）を行おうとするときは、総務省令で定めるところにより、あらかじめ、送信される利用者に関する情報の内容、送信先となる電気通信設備その他の総務省令で定める事項を、利用者に通知し、又は利用者が容易に知り得る状態に置くことを求めています。ただし、その情報が、利用者が役務を利用する際に送信が必要なものとして総務省令で定める情報、事業者が役務の提供の際に送信した識別符号で事業者の電気通信設備を送信先とするもの、送信されることについて利用者が同意している情報、利用者の求めに応じて送信又は利用を停止する措置を講じその事項を容易に知り得る状態に置いている場合に利用者が措置の適用を求めていない情報であるときは、この限りでありません。総務省令の事項は、情報送信指令通信ごとに、送信される利用者に関する情報の内容、送信先の電気通信設備を用いて情報を取り扱う者の氏名又は名称、利用目的です（同法施行規則第22条の2の29）。本記事の整理では、アプリを作る受託者である自社は同条の義務者ではない側に立ちます。顧客が義務者に当たるか、個々の送信がただし書に当たるかは、本記事では判断していません。
前払の機能とメッセージの機能。 資金決済に関する法律は、自家型前払式支払手段のみを発行する者に、基準日においてその基準日未使用残高が発行を開始してから最初に基準額を超えることとなったときの、内閣府令で定めるところによる内閣総理大臣への届出を求め（第5条第1項）、第三者型前払式支払手段の発行の業務は内閣総理大臣の登録を受けた法人でなければ行ってはならないとし（第7条）、適用を除外する規定も置いています（第4条）。電気通信事業法は、電気通信事業を営もうとする者に、設置する電気通信回線設備の規模と区域の範囲が総務省令で定める基準を超えない場合等を除き総務大臣の登録を（第9条）、登録を受けるべき者以外には総務省令で定めるところによる総務大臣への届出を（第16条第1項）求めています。アプリ内の通貨・ポイントや利用者間のメッセージの機能で顧客がこれらに当たるかは、本記事では判断していません。
個人情報。 2026年10月1日施行の版の個人情報の保護に関する法律では、個人情報は、個人情報データベース等（特定の個人情報を電子計算機を用いて検索することができるように体系的に構成したものなど。政令で定めるものを除く）を構成する場合に個人データに当たります（第16条）。アプリの利用者や顧客の担当者の情報がこれらに当たるかは判断しておらず、本記事の設計では個人データに当たりうる情報として扱います。個人情報取扱事業者は、法令に基づく場合など第27条第1項各号の場合を除くほか、あらかじめ本人の同意を得ないで個人データを第三者に提供してはなりません。利用目的の達成に必要な範囲内において取扱いの全部又は一部を委託することに伴って提供される場合は、提供を受ける者は、同条の前各項の規定の適用については第三者に該当しないとされます（同条第5項第1号）。運用保守の原因の調査などで受け取る情報が委託に伴う提供に当たるかは、本記事では判断していません。本記事の設計では、受け取る前に委託か第三者提供か、要配慮個人情報を含みうるかを確かめて記録し、「未確認」の間は受け取りません。
個人情報取扱事業者が外国（同等の水準にあると認められる制度を有する外国として規則で定めるものを除く）にある第三者（規則で定める基準に適合する体制を整備している者を除く）に個人データを提供する場合は、第27条第1項各号の場合を除き、あらかじめ外国にある第三者への提供を認める旨の本人の同意を得なければならず、この場合は第27条の規定は適用されません。同意を得ようとするときは、規則で定めるところにより、あらかじめ外国の制度などの参考となる情報を本人に提供し、体制を整備している者に提供したときは、規則で定めるところにより、相当措置の継続的な実施を確保するために必要な措置と、本人の求めに応じた情報提供を行います（第28条第1項〜第3項）。外国にサーバのある生成AI・外部サービスへの入力がこれに当たるかは判断しておらず、本記事の設計では、委託に当たるかとは別にこの判定を行い、「対象外と確認済み」になるまで個人データを入力しません。
生成AI・クラウドに出す条件。 顧客の秘密やソースコードを入れる前に、①入れる情報を必要最小限にする②入力データを学習に利用するか③保存期間と削除の方法④契約上の機密保持とデータの取扱条件⑤アクセス権限と利用ログ⑥再委託や国外保存など自社の規程上確認が必要な事項、の6点を確かめ、組織が利用を承認したサービスに限ります。これは法令の要件ではなく、組織として決める運用です。
10. 最初の30日プラン
1週目：測る。 案件の担当者が、直近1か月分の提出の記録・申告の履歴・検収の指摘から、①提出の前に顧客の承認の記録が揃っていた版の割合②照合で見つかった不一致の件数③リジェクトの件数④申告の案の作成にかかった時間⑤申告の案と外部サービスの一覧の不一致の件数⑥台帳（一覧）に無い外部サービスの件数⑦検収の時点で「合意していない要望」と区分された指摘の件数を、5営業日で数えます。
2週目：ルールを決める。 Top1の台帳の列を決め、進行中の1案件の次のビルドから記録を始めます。Top1の提出しない条件を文書にし、Top2の台帳の列を決めます。
3週目：人が全件確認する小規模試行。 次に申告を更新する1アプリで、AIが提供元の資料と設定から作った台帳の案を担当者が全件確認し、台帳から申告の案を作ります。Top1では、AIが出す照合の不一致の候補を担当者が全件確認します。新しい案件が始まる場合は、Top3の列を足します。個人データと顧客の秘密は、外国にサーバのあるAIに入力しません。
4週目：比べる。 ①〜⑦を2〜4週目の記録で数え直し、1週目と比べます（Top1は①〜③、Top2は④〜⑥、Top3は⑦。新しい案件が無ければ⑦は比べません）。次の候補は、Top2の台帳とOS・ストアの公表の照合です。
11. AI活用成熟度
- Lv1 人依存。 版・承認・提出の記録、外部サービスの一覧、要件の版が担当者の手元にある。
- Lv2 台帳化。 ビルドの版の台帳・外部サービスの台帳・要件の版を表で持つ。
- Lv3 一元化。 3つの台帳がビルド番号・外部サービス・要件IDでつながり、照合・申告の案・検収の対応表が同じ記録から出る。
- Lv4 AI支援。 AIが台帳・照合・申告・テストケースの案を作り、人が全件確認か例外の確認をする。
- Lv5 仕組み化。 台帳と照合がビルド・テスト・提出の流れに組み込まれ、承認と照合の揃わない版は提出の手順に進まない。
Lv5は、AIが提出の可否や顧客の承認を自動で決める状態ではありません。
12. FAQ
Q. アプリに分析や広告のSDKを組み込みます。外部送信の通知や公表は開発会社の義務ですか。 A. 電気通信事業法第27条の12の義務を負うのは、電気通信事業者又は第三号事業を営む者のうち総務省令で定める役務を提供する者です（ただし書があります）。本記事の整理では自社は義務者ではない側で、顧客が当たるかは判断していません（節9）。
Q. 不具合の調査で、本番のログやクラッシュの報告を受け取ってもよいですか。 A. 個人データや委託に伴う提供に当たるかは、本記事では判断していません。本記事の設計では、開発とテストでは本番の個人データを受け取らず、それ以外は受け取る前に区分を確かめて記録し、「未確認」の間は受け取りません（節9）。
Q. 生成AIにコードを書かせてもよいですか。 A. 本記事の設計では、AIのコードは候補として扱い、開発者の全件確認と、作成者と別の者のレビューを経て取り込みます。入力の条件は節9のとおりです。
Q. アプリ内のポイントを作る場合、届出は誰がしますか。 A. 資金決済に関する法律の届出・登録は前払式支払手段を発行する者についての規定で（条件は節9）、顧客の機能が当たるかは本記事では判断していません。本記事の設計では、顧客の回答が「未確認」の間はその要件を合意しません。
13. 関連業態・シリーズ導線
SIer・受託開発会社の記事は、顧客から業務システムの開発を受託し、自社または外注の体制で実装する会社を想定し、要望と合意済み要件を分けて要件IDで検収までつなぐことをTop1に置いています。本シリーズでは、ブラウザで利用するWebアプリケーション・業務システムが主たる成果物の受託開発は、この記事の側と整理しています。
Web制作会社の記事は、顧客企業のWebサイトの制作・改修を受託し、公開後の運用も一部担う制作会社を想定し、送信項目と送信先を設置時に一覧化することをTop3に置いています。本記事はWebサイトではなく、端末で動くアプリを扱います。
業種別AI活用の一覧はピラーページにまとめています。
14. この記事を自社に当てはめたい方へ
同じアプリ開発会社でも、ビルドと提出の記録の残し方、組み込んでいる外部サービスの数、運用保守を受けているかで、最初の一手は変わります。
15. 無料AI戦略診断／AI顧問
AI戦略診断は無料・登録不要です。回答すると、自社のAI活用がいまどの段階にあるかと、最初に取り組むべき領域が分かります。
自社の業務に沿って一緒に設計したい方には、AI顧問サービスがあります。まず話を聞いてみたい方は、お問い合わせから30分の無料リモート面談をご利用ください。
