AIに「このアプリを作って」と伝えると、画面やデータベースのたたき台が短時間で出てきます。
便利になった一方で、作る速度と、公開して運用できる状態になる速度は同じではありません。認証がつながらない。外部サービスの権限が足りない。テストは通ったが、誰が公開を承認したのか分からない。こうした問題は、コードを書く前に決めるべきことを後回しにしたときに起きます。
AI開発で大切なのは、AIを止めることではありません。AIに任せる範囲と、人間が判断する境界を先に置くことです。本稿では、個人開発や小規模事業者がアプリを作るときの「公開ゲート」を、壁打ちから運用までの順番に分けて説明します。
AIに任せる前に、公開の条件を一枚にする
最初に書くのは、機能一覧ではなく公開条件です。
たとえば、次のような項目を一枚にします。
| 項目 | 最初に決めること |
|---|---|
| 利用者 | 自分だけか、社内か、外部ユーザーか |
| データ | 何を保存し、何を保存しないか |
| 外部連携 | どの公式APIを使い、どの権限を要求するか |
| 承認 | 投稿、送信、削除、課金を誰が確認するか |
| 合格条件 | どのテストとログがそろえば次へ進むか |
| 停止条件 | 何が起きたら公開を止め、手動に戻すか |
この表がないままAIに実装を任せると、モデルは「動くもの」を作れても、「公開してよいもの」までは決められません。公開条件は、開発の最後に足すチェックリストではなく、最初の入力です。
この一枚の役割は、公開ボタンを押す前に「誰が、何を証明すれば次へ進めるか」を決めることです。たとえば最初の対象を代表一人の下書き作成に限定するなら、合格条件は「テスト用データだけで作成・保存・削除が通り、公開操作は人間の承認後に一度だけ実行され、結果がログに残る」と書けます。
1. 壁打ちを要件へ変換する
AIとの壁打ちは、アイデアを広げるために使えます。ただし、会話のまま実装へ渡すと、希望と必須条件が混ざります。
まず、会話から次の四つを分けます。
- 今回の利用者が達成したい仕事
- 最初の版に必要な機能
- 後から追加する候補
- まだ判断できないこと
たとえば複数のSNSへ同じ素材を投稿するアプリなら、最初から分析、広告、予約、複数ブランド、動画変換まで一度に入れるのではなく、「一つのブランドで下書きを作り、承認後に一つの公式経路へ投稿する」までを最初の検証に絞れます。投稿先を増やすことより、承認履歴が残ることを先に合格条件にしてもよいでしょう。
ここで重要なのは、AIに要件の最終決定を渡さないことです。追加要望を受け入れるか、負債を増やしてもよいか、公開を延期するかは、事業の優先順位を含む人間の判断だからです。
要件メモには、利用者、保存するデータ、外部連携、承認者、合格条件、停止条件を一行ずつ書きます。最初から利用者や投稿先を増やさず、「誰が使い、どのデータを扱い、どの操作だけを許すか」を固定すると、後のレビューで確認する範囲も絞れます。
2. 実装とレビューを同じ役割にしない
AIに実装を任せる場合、実装担当とレビュー担当の仕事を分けます。レビュー担当には、コードの感想ではなく、合格条件に対する証拠を出させます。
- 認証なしで保護ページを開けないか
- 別ユーザーのデータを読めないか
- 投稿や削除が承認なしに実行されないか
- 失敗時に再実行できるか、二重実行にならないか
- 重要な操作がログに残るか
ブラウザーを使ったE2Eテストは、画面を一度表示するためだけのものではありません。入力、権限、エラー、再試行、停止までを一つのシナリオとして確認し、「通った理由」を記録するために使います。テストが緑になったことと、公開を承認できることは別の判定です。
レビュー結果は、少なくとも「ケース、入力、期待結果、実結果、証跡、判定、承認者」の7項目で残します。証跡が空欄のケースは合格にせず、再実行した場合は前回の結果を上書きせずに別行として記録します。これで、テストが通ったという印象ではなく、公開判断に使える証拠になります。
3. 外部APIは、機能より先に公開条件を見る
外部SNSとの連携は、アプリ側の実装だけでは完結しません。登録アプリ、OAuthの権限、リダイレクト先、審査、監査、利用者の認可などがサービスごとに異なります。
ここでいうOAuthは、外部サービスのパスワードをアプリへ渡さず、利用者が許可した操作だけをアプリに委ねる仕組みです。許可する範囲、期限、取り消し方法を確認し、使わない権限まで要求しないことが公開条件になります。
たとえばTikTokのContent Posting APIは、登録アプリに製品を追加し、video.publishスコープの承認と利用者の認可を得る手順を公式に示しています。未監査クライアントの投稿は非公開に制限される場合もあります。したがって、「投稿ボタンが動いた」だけでは、本番の公開条件を満たしたとは言えません。(TikTok for Developersの公式手順)
データ基盤も同じです。Cloudflare D1はSQLiteのSQL仕様を持つマネージド型のサーバーレスデータベースで、Workersからバインディング経由で利用できます。ただし、開発用データベースと本番データベースを分けること、マイグレーションを再現できること、バックアップと復旧方法を確認することは別途必要です。(Cloudflare D1公式概要)
外部仕様が変わる領域では、AIに「対応して」と頼む前に、公式ドキュメントを確認する担当と、審査が通らない場合の代替手段を決めておきます。
4. 公開ゲートを四段階に分ける
公開を一つのボタンにせず、次の四段階に分けると判断が軽くなります。
段階A：自分用の検証
ダミーデータ、テスト用アカウント、最小権限で、主経路だけを通します。ここでは見た目の完成度より、データが想定外へ出ないことを見ます。
段階B：限定した利用者での確認
利用者、ブランド、投稿先、保存期間を限定します。実データを使う場合は、削除方法と問い合わせ先を先に用意します。
段階C：本番設定の確認
本番ドメイン、OAuthのリダイレクト先、秘密情報、API権限、レート制限、エラー通知を確認します。ローカルで通った値をそのまま本番へ持ち込まないことが重要です。
段階D：公開後の計測
公開後に何を見るかを決めます。投稿成功率、失敗理由、承認待ち件数、重複投稿、問い合わせなど、次の判断に必要な最小項目だけを記録します。
この考え方は、AIを含むシステムの設計・開発・利用・評価で信頼性を考えるNIST AI RMFの方向性とも整合します。NISTはAI RMFを任意利用の枠組みとして位置づけ、AI製品やサービスに信頼性の観点を組み込むことを目的にしています。(NIST AI Risk Management Framework)
四段階それぞれに「担当者、開始条件、終了証拠、失敗時の戻り先」を一行で添えると、段階を飛ばして公開する判断を減らせます。証拠がそろわなければ、次の段階へ進まず、前の段階へ戻します。
5. マネタイズは、公開後の別ゲートにする
アプリが動いたことと、誰かが料金を払うことは別です。開発中に「需要がある」「売りやすい」と断定せず、まず自分の業務で使い、次に限定した利用者の困りごとと継続利用を確認します。
初期段階で記録するのは、派手な売上予測ではありません。
- どの作業を何分短縮できたか
- どの操作で止まったか
- どの機能が使われなかったか
- 利用者が手作業へ戻った理由は何か
- 次の利用を約束するほど困りごとが強いか
この記録がないまま機能を増やすと、開発速度だけが上がり、価値の検証が遅れます。公開ゲートを通った後に、利用継続と支払い意思を別の仮説として検証します。
公開後の最初の記録は、売上予測ではなく事実の表にします。日付、対象業務、利用者数、成功回数、停止回数、再実行回数、手作業へ戻った理由、次に直す条件を一行ずつ残し、一定期間後に継続・修正・停止を人間が判断します。
小さく回すためのチェックリスト
最後に、AIへ次の作業を渡す前の確認をまとめます。
- 利用者、データ、最初の一機能が決まっている
- AIに任せる作業と、人間が承認する操作が分かれている
- 実装担当とレビュー担当が分かれている
- 認証、認可、エラー、再実行、停止のE2Eケースがある
- 外部APIの公式条件と本番ドメインが確認済みである
- 本番に置く秘密情報、保存期間、削除方法が決まっている
- テスト結果、承認者、公開日時、失敗理由を記録できる
- 公開後に見る指標と、戻す条件が決まっている
すべてを最初から自動化する必要はありません。小さな仕事を一つ選び、公開ゲートを通す経験を積む方が、次の機能を安全に増やしやすくなります。
AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断（無料） で、既存業務のどこがAIパッケージ化しやすいかをご確認ください。実装まで進めたい候補が見えた場合は、導入前スコープ整理 で対象業務、含む範囲、費用感、5営業日で初期版にできるかを整理します。