この記事の内容
受託の合間にAIで自社プロダクトを作り、画面も動くようになった。あとは公開するだけ、という段階で手が止まることがあります。受託なら納品前に取引先の検収があり、公開後の保守も契約で決まっています。自社プロダクトでは、その確認をすべて自分で引き受けることになります。
この記事では、リリースのチェックリストを事業・技術・契約・運用の4つに分けて整理します。ハコブネではこの点検を「進水前の点検」と呼んでいます。APIキーの置き場所やAIの利用料の上限のような技術の話から、利用規約や問い合わせ窓口のような運用の話まで、受託業者が抜かしやすい項目を、4つの箱ごとに並べました。公開前の点検は、完璧に仕上げるためではなく、公開した後に沈まないために行います。
この記事について
書いているのは、作る側です。ハコブネを運営する株式会社Walkersは、受託と自社事業で累計300件の開発に関わり、200社以上の事業づくりを支援してきました。監修は取締役の池田龍一です。
一般論ではなく、実際にやったことの中身で説明します。この記事に出てくる数字は、すべて公開済みの自社・支援先の事例から引いています。出典は記事の最後にまとめました。
受託の納品と自社のリリースで、点検する中身が変わる
受託の納品では、品質の基準を取引先と一緒に決めます。仕様書があり、検収の項目があり、問題が起きれば連絡してくる相手も決まっています。受託業者は作ることに集中でき、お金や規約の話は取引先の側にあります。
自社プロダクトでは、この分担がなくなります。値段を決めるのも、規約を書くのも、問い合わせに答えるのも自分です。AIで作るとコードを書く時間は短くなりますが、作った後に決めることの量は変わりません。むしろ速く作れる分、決めごとが追いつかないまま公開してしまう危険が増えます。
そこで、点検を4つの箱に分けて考えます。事業は「誰に何をいくらで売るか」、技術は「壊れたり漏れたりしないか」、契約は「約束と表記に抜けがないか」、運用は「公開した翌日から誰が何をするか」です。受託の経験がある人は技術の箱には慣れていても、受託では取引先が持っていた事業と運用の箱は手薄になりがちです。
事業の点検：誰に、いくらで、何を約束するか
公開前に合格ラインを決めておく
リリースしたあとに「反応がよかったのか悪かったのか」が分からなくなるのは、合格ラインを決めずに出したときです。ハコブネのハッカソンで運営が作った記録アプリのBENLOGでは、確かめる仮説を「うんちを育てるためなら、人は毎日トイレを記録するのか」の一点に絞りました。そのうえで、7日後の継続率40%、30日後20%、1日平均3.5件という合格ラインを、検証する前に置いています。これは目標値で、実測ではありません。
数字の大きさより、先に決めておくことに意味があります。何を測って、どこまで届けば続けるかを書き出してから公開すると、公開後の判断に迷いが減ります。測り方はMVP検証の方法｜何を測り、何人で判断し、どこでやめるかで整理しています。
価格と支払いの流れを確かめる
有料で出す場合は、価格のほかに、支払い方法、請求のタイミング、解約の手順を決めておきます。月額なのか買い切りなのか、無料期間を置くのか。受託では見積書と請求書で済んでいた部分を、プロダクトの画面と決済の仕組みで表すことになります。
有料モニターから正規リリースに移る場合は、モニターの価格と正規価格の関係も決めておきます。モニターの人に何を約束していたかを読み返し、正規リリースで条件が変わるならその伝え方も用意します。モニターの集め方と価格の決め方は有料モニターの集め方と価格の決め方｜正規リリース前に実績を作るで書いています。
約束しないことを書き出す
受託業者は、取引先の要望に応えるのが習慣になっています。自社プロダクトで同じことをすると、個別対応が増えて受託と同じ働き方に戻ってしまいます。公開前に「このプロダクトでやらないこと」を書き出しておくと、問い合わせへの答え方がぶれません。たとえば、個別のカスタマイズはしない、電話サポートはしない、といった線です。
技術の点検：AIで作ったコードで抜けやすいところ
APIキーと秘密情報の置き場所
AIに作らせたコードでは、外部サービスのAPIキーがソースコードに直接書かれていることがあります。公開前に、キーやパスワードがコードやリポジトリに残っていないかを確かめ、環境変数など外から見えない場所に移します。画面側のコードにキーが入っていると、利用者がブラウザから読めてしまいます。
一度でも公開のリポジトリに上げたキーは、消しても履歴に残る場合があります。心配なときは、キーそのものを作り直すほうが確実です。
AIのAPI利用料に上限をかける
生成AIのAPIを組み込んだプロダクトでは、使われた分だけ利用料がかかります。想定より多く使われたり、誰かに悪用されたりすると、請求が膨らみます。AIを使う機能には、公開前に利用料の上限と、一人あたりの回数の上限をかけておきます。
上限は、ハコブネ式の5原則にある「上限を決めて大胆に」と同じ考え方です。失ってよいお金を先に決めておけば、思い切って公開できます。サービス側の管理画面で上限や通知を設定できるかも確かめておきます。
権限とデータの見え方
ログイン機能があるなら、ある利用者が別の利用者のデータを見られないかを確かめます。URLの番号を一つ変えるだけで他人の情報が出てくる、という抜けは、動作確認をしているときには気づきにくいものです。テスト用のアカウントを2つ作り、片方からもう片方のデータに触れないかを試します。
管理者の画面や、データを消す操作に誰が入れるかも見直します。受託で権限設計をした経験がある人は、その時の確認表をそのまま流用できます。
バックアップと戻し方
データを預かるプロダクトなら、バックアップが取れているかだけでなく、実際に戻せるかを一度試します。更新で不具合が出たときに、前の版へ戻す手順も決めておきます。AIで修正を重ねていると、どの変更で壊れたか分からなくなることがあるため、変更の履歴を残す習慣も役に立ちます。
非エンジニアがAIで作った場合の公開前の確認は、バイブコーディングの始め方｜非エンジニアが最初に作るものと公開前の確認でも触れています。
契約の点検：規約・表記・受託との関係
利用規約とプライバシーポリシー
利用規約には、提供する内容、禁止事項、料金と解約、免責、規約の変更の扱いなどを書きます。個人情報を受け取るなら、プライバシーポリシーで、何を集めて何に使うかを示します。AIに個人情報を送る機能がある場合は、その扱いも書いておく必要があるかを確認します。
ひな形を使うことはできますが、自分のプロダクトに合っているかは自分で読み直します。内容が適切かの判断は、弁護士など専門家に確認してください。
特定商取引法に基づく表記
ネットで有料のサービスを売る場合は、特定商取引法に基づく表記が必要かどうかの確認が必要です。必要な場合にどの項目をどう載せるかは、売り方や相手によって変わる可能性があります。個人で事業をしている人は、住所や電話番号の載せ方も確認しておきたい点です。消費者庁などの公的な情報を確認し、判断は弁護士など専門家に相談してください。
受託の成果物を使っていないか
受託で作った仕組みを土台にしている場合は、その成果物の権利が誰にあるかを契約書で確かめます。秘密保持や競業避止の条項にかかっていないかも見ます。受託の経験を活かすことと、受託の成果物を流用することは、分けて考える必要があります。確認する点は受託の成果物を自社製品に使ってよいか｜契約で確認する5つの点にまとめています。
運用の点検：公開した翌日から誰が何をするか
問い合わせ窓口と返答の目安
問い合わせを受ける窓口を一つ決め、プロダクトの画面から分かる場所に置きます。返答の目安も書いておくと、利用者は待つ間に不安になりにくくなります。受託の連絡と自社の問い合わせが同じ受信箱に混ざると、どちらかが埋もれます。宛先かラベルを分けておくと見落としが減ります。
障害が起きたときの連絡と止め方
不具合が起きたときに、利用者へどこで知らせるかを決めておきます。あわせて、AIの機能だけを止める、新規登録だけを止めるといった、部分的に止める方法を用意しておくと安心です。全部を止めるか何もしないかの二択だと、判断が遅れます。
受託の繁忙期でも回るか
受託業者の自社プロダクトで起きやすいことの一つが、受託が忙しくなって返事が止まることです。公開前に、繁忙期でも最低限やることを決めておきます。問い合わせへの返答だけは毎日見る、更新は週に一度にする、といった低速の運用です。
Walkersは、メールや経理、議事録など会社の定常業務をAIが監視・自動処理し、判断が必要な場面だけ人に届けるFDE-NOAHを、Walkers自身の経営で先に運用しています。自分で毎日使ってみると、運用の穴は公開前に見つかります。規模は違っても、自分や身近な取引先で回してから公開する進め方は、少人数の受託業者でも取り入れられます。
チェックリストは、段階に合わせて厳しさを変える
ここまでの項目を、最初から全部満たす必要はありません。ハコブネ式では、受託から自社プロダクトまでを、受託、受託と有料モニター、正規リリース、自社プロダクトの4段階で考えます。段階ごとに点検の厳しさを変えます。
有料モニターの段階では、相手は顔の見える少人数です。この段階で必ず押さえるのは、APIキーの置き場所、利用料の上限、データの見え方、問い合わせの窓口です。規約や表記をこの段階でどこまで整える必要があるかは、売り方や相手によって変わる可能性があるため、専門家に確認しておきます。モニターとの個別の約束も、書面にして残します。
正規リリースでは、知らない人が申し込んできます。規約、特定商取引法の表記の確認、バックアップの戻し方、障害時の連絡まで揃えてから出します。点検項目を段階で分けておけば、全部が揃うまで出せないという状態を避けられます。4段階の進め方は脱受託はいきなり目指さない｜受託→有料モニター→正規リリースの4段階で詳しく書いています。
よくある質問5選
質問1個人で小さく出すだけでも、利用規約は必要ですか？
有料で提供する場合や、利用者のデータを預かる場合は、何らかの規約や約束ごとを示しておくほうが安全です。内容が適切かどうかは、弁護士など専門家に確認してください。
質問2AIで作ったコードは、自分で全部読む必要がありますか？
全部を読めなくても、APIキーの扱い、ログインと権限、データの削除にかかわる部分は、公開前に必ず中身を確かめます。読めない場合は、その部分だけでも分かる人に見てもらうと安心です。
質問3AIのAPI利用料の上限は、どのくらいにすればよいですか？
金額の正解はなく、失っても事業が続けられる額を先に決めます。そのうえで、一人あたりの回数の上限も別にかけておくと、一部の利用で予算を使い切ることを防げます。
質問4受託の取引先に、公開前に見てもらってもよいですか？
取引先が利用者になりうるなら、有料モニターとして使ってもらうのはよい方法です。受託の契約や守秘義務にかからない範囲で行い、受託の仕事とは別の話として切り出します。
質問5チェックリストの項目が多すぎて、公開が延び続けます。どうすればよいですか？
今の段階で必須の項目と、正規リリースまでに揃える項目に分けます。必須の項目だけを終えた日を公開日にして、残りは公開後の予定に入れます。
点検表を手元に置いて、公開日を先に決める
まずは、この記事の4つの箱を自分のプロダクトに当てはめて、今の段階で必須の項目に印をつけてください。印のついた項目を終える日を公開日として決めると、点検が終わりのない作業になりません。残りの項目は、正規リリースまでの予定表に移します。
ハコブネは、受託と自社の新規事業を並行してきた株式会社Walkersが運営する、受託業者のためのコミュニティです。進水前の点検の考え方や、受託を続けながら自社プロダクトを出す進め方を、会員同士で持ち寄って確かめています。公開前の点検で迷っている方は、入会を前提にしない無料相談会で、今の状況を話してみてください。
この記事について
池田は、ITとノーコードの事業開発・教育事業の立ち上げを経て2021年にWalkersを共同創業。100件以上のシステム開発に携わり、要件がまだ固まっていない案件や、他社から引き継いだ開発の立て直しを担当しています。
株式会社Walkersは、AI駆動開発・ノーコード開発のシステム開発会社です。累計開発実績300件、200社以上の支援、自社メディアの累計100万PV。受託開発と並行して、自社でも複数の新規事業を立ち上げています。
最終更新：2026年10月21日