こんな方に向いています
- 社内で温めているアプリのアイデアを、まず動く形にして確かめたい
- ウェブサービスはあるが、スマートフォンのアプリとしてもストアに出したい
- アプリ内課金（サブスクリプション・買い切り）や広告で収益化したい
- 以前ストア審査で却下され、どこを直せばよいかわからず止まっている
対応範囲
企画・設計
誰が何のために使うのかを整理し、最初に作るべき機能を絞り込みます。画面の流れを先に作り、触りながら決めていきます。
iOS・Android・ウェブ
ひとつのコードからウェブ版とiOS・Android版を作る構成を得意としています。3つを別々に作るより、開発と保守の費用を抑えられます。
ストア申請・審査対応
App Store・Google Playへの登録、掲載情報やスクリーンショットの準備、プライバシー関連の申告、審査で指摘を受けた際の修正まで対応します。
課金・広告
サブスクリプションや買い切りの課金、広告の表示を組み込みます。購入の復元や解約案内など、ストアの規約で求められる表示も含めて実装します。
公開後の運用
不具合の修正、OSの更新への追従、利用状況を見ながらの機能改善を継続して行います。
自社アプリの運用経験が活きるところ
アプリ開発で時間を取られるのは、コードを書く工程よりも、その前後にある「ストアの審査」「課金の設定」「各種の申告」であることが少なくありません。私たちは自社アプリ「麻雀 辻斬る！」をApp Storeで公開し、課金と広告を組み込んで運用しています。その過程で実際に経験した例をいくつか挙げます。
例1：課金の商品がアプリに表示されない
アプリ側のコードやストアの商品設定をどれだけ見直しても購入画面が出ない、という状況に陥りました。原因はストア側の「有料アプリ契約」が、税務情報と銀行口座の登録待ちで有効になっていなかったことでした。契約が有効でない間は、ストアが商品情報を一切返さないためです。いまは課金の不具合を調べる前に、まず契約状態を確認するようにしています。
例2：審査で求められる表示の漏れ
サブスクリプションを販売するアプリには、自動更新の条件、請求先、解約方法、利用規約へのリンクなどを、アプリ内のわかる場所に表示することが求められます。価格の読み込みに失敗したときにこれらの表示ごと消えてしまう作りだと、審査で指摘されます。表示の条件まで含めて設計することが大切です。
例3：広告に関する申告
広告を表示するアプリは、App StoreとGoogle Playの双方で、広告識別子を使うかどうかの申告が必要です。広告のSDKを組み込むだけで識別子を扱う処理がアプリに含まれるため、実態と異なる申告をすると、提出が止まったり却下されたりする原因になります。
こうした知見を案件の最初から計画に織り込むことで、「完成したのに公開できない」期間を短くできます。
主な技術
- TypeScript
- React / Next.js
- Capacitor（iOS・Android）
- Supabase
- Cloudflare Workers
- RevenueCat（アプリ内課金）
- Google AdMob
案件の内容に合わせて、既存システムとの連携や別の技術の採用も検討します。ご自身で運用を引き継がれる場合は、引き継ぎやすい構成と資料の用意を優先します。
進め方
- ご相談困っていること、実現したいことを伺います。予算や要件が未定でも構いません。
- 試作（目安2週間）主要な画面が動く試作を作り、実際に触っていただきながら方向を確かめます。
- 開発毎週、進んだ部分をお見せしながら進めます。途中での方針変更も歓迎します。
- 公開・申請ストアへの申請と審査対応を行い、公開します。
- 運用・改善公開後の数字と利用者の声をもとに、改善を続けます。
よくあるご質問
- 費用はどのくらいかかりますか？
- 必要な機能と対応するプラットフォームによって大きく変わるため、ご相談の内容を伺ったうえでお見積りします。最初に試作だけを小さくご依頼いただき、手応えを見てから本開発を判断することもできます。
- ウェブ版だけ、iOS版だけの開発もできますか？
- できます。まずウェブ版で公開して反応を見てから、ストア向けのアプリを追加する進め方もおすすめしています。
- 他社で作ったアプリの改修や、審査で止まっているアプリの対応もできますか？
- ソースコードと現在の状況を拝見したうえで、対応できる範囲をご説明します。審査での指摘内容がわかる資料があると、原因を早く特定できます。
- 公開後の保守だけをお願いすることはできますか？
- ご相談ください。OSの更新対応や、ストアの規約変更に伴う修正などを継続して行う形でお受けしています。