はじめに
生成AIにコードを書かせたり、設計案を出させたりすることは、すでに珍しくなくなりました。
では、実装するサービス自体を人間が決めずに、
利用可能な環境の中で事業案を考え、設計し、実装し、公開する
というところまでAIに任せた場合、実際にサービスを公開できるのでしょうか。
この疑問を検証するため、AIに事業案の選定から公開準備までを進めさせる実験を行いました。
その結果、2026年7月16日に、生成AIへ文章を送る前に機密情報の候補をマスキングするWebサービス「MaskedForm」を公開しました。
本記事では、MaskedFormの詳しい実装方法ではなく、次の点を中心に説明します。
- AIへどのような目的を与えたか
- AIがなぜこの事業案を選んだか
- 人間とAIの役割をどう分けたか
- 事業計画をどこまで具体化したか
- 公開までに人間の判断が必要だった点
- AIが事業を作ったといえるのか
実装やプライバシー設計については、今後の記事で個別に扱う予定です。
⸻
実験の目的
今回の実験では、人間が「このアプリを作ってほしい」と具体的なサービス案を指定する方法を取りませんでした。
AIに与えた大まかな条件は、次のようなものです。
- 小規模でも現実に公開できること
- 継続的な需要が期待できること
- 利用可能な開発・公開環境で実現できること
- 初期費用と運用費を抑えられること
- 公開後に利用状況を計測し、改善判断ができること
- 将来的には収益化の可能性を検討できること
- AI自身が実装、文書化、運用設計を継続できること
人間側では、GitHub、Web公開環境、既存のAPIron Labサイトなど、利用可能な基盤を提示しました。
そのうえで、どのような課題を対象にし、何を作り、どう公開するかはAIに検討させました。
⸻
AIが選んだ課題
AIが最終的に選んだのは、生成AIへ文章を貼り付ける際の情報漏えいリスクでした。
生成AIを業務で使う場合、次のような情報をプロンプトへ含めたくなる場面があります。
- 顧客から届いたメール
- 問い合わせ内容
- 障害発生時のエラーログ
- IPアドレスや環境情報
- 社内文書
- 案件名や顧客名
- 設定ファイルの一部
- メールアドレスや電話番号
生成AIへ送信する前に、これらの情報を人手で削除したり、仮の文字列へ置き換えたりすることは可能です。
しかし、毎回手作業で置き換えるのは面倒です。
また、同じ値を複数箇所で異なる文字列に変えてしまうと、文章の意味や対応関係が崩れることがあります。
例えば、次の文章があったとします。
田中様から example@example.com 宛てに連絡がありました。
example@example.com へ返信文を作成してください。
単純にメールアドレスを削除すると、同じメールアドレスが繰り返されているという情報も失われます。
そこで、次のように安定したトークンへ置き換えます。
田中様から [EMAIL_01] 宛てに連絡がありました。
[EMAIL_01] へ返信文を作成してください。
AIから戻ってきた文章に [EMAIL_01] が含まれていれば、ブラウザ内に保持した対応表を使って元の値へ戻します。
この処理を、元の文章や置換表を外部サーバーへ保存せずに実行するサービスとして、MaskedFormが企画されました。
⸻
MaskedFormとは
MaskedFormは、生成AIへ文章を送信する前の確認を支援する、ローカル処理中心のWebツールです。
2026年7月時点の公開ベータでは、主に次の情報候補を検出します。
- メールアドレス
- 日本の電話番号候補
- IPv4アドレス
- AWSアクセスキーID
- クレジットカード番号候補
- 利用者が登録した顧客名や案件名などの任意語句
同じ値が繰り返し登場した場合は、同じトークンを割り当てます。
example@example.com
↓
[EMAIL_01]
AIから返された回答をMaskedFormへ貼り付けると、既知のトークンを元の値へ再置換できます。
重要なのは、次の情報をMaskedFormのデータベースへ保存しない設計にしたことです。
- 元の文章
- マスキング後の文章
- AIから返された文章
- トークンと元の値の対応表
- 利用者が追加した任意語句
MaskedFormのサーバーへ送信するのは、許可されたイベント名と回数などの集計情報に限定しています。
また、MaskedForm自身がOpenAI APIなどへ文章を送信する機能も持っていません。
⸻
なぜこの案が選ばれたのか
AIがこの案を採用した理由は、単に生成AIが流行しているからではありません。
事業案として、次の条件を満たしやすかったためです。
- 課題を説明しやすい
生成AIへ顧客情報やログを貼り付ける際に不安を感じる、という課題は比較的理解されやすいものです。
大規模な市場調査を行わなくても、具体的な利用場面を提示できます。
- 小規模なMVPを作れる
最初から高度なDLP製品や企業向け監査システムを作る必要はありません。
まずは、
- 文章を貼り付ける
- 機密情報の候補を検出する
- 安定したトークンへ置き換える
- 置換後の文章をコピーする
- AIの回答を貼り付ける
- トークンを元の値へ戻す
という一連の処理だけで、価値仮説を検証できます。
- 元データを保存しない構成にできる
機密情報を扱うサービスが、利用者の入力内容を自ら収集してしまうのは大きな矛盾です。
今回の処理はブラウザ内で完結させやすく、元の文章や置換表をサーバーへ保存しない設計を採用できます。
- 無料版から検証を始められる
最初から決済機能を作らず、無料のWeb版で利用実態を確認できます。
需要が確認された場合だけ、ブラウザ拡張やカスタムルールなど、日常利用向けの機能を検討できます。
- AIによる継続改善と相性がよい
検出ルール、テストケース、説明文、FAQ、利用ガイドなど、AIが継続的に改善しやすい要素が多くあります。
一方で、法務判断やセキュリティ事故への対応など、人間が担当すべき領域も明確に分けられます。
⸻
AIが作成した事業仮説
AIは、単にWebツールを実装するだけでなく、公開後の事業仮説も作成しました。
最初の対象利用者は、次のように定義されています。
- 個人事業主
- フリーランス
- 小規模事業者
- 顧客情報やログを生成AIへ入力する利用者
主な利用場面は、次の3つです。
- 顧客メールや問い合わせをAIで要約する前
- エラーログや設定情報をAIへ渡して相談する前
- 社内文書や案件情報をAIで校正する前
提供段階についても、複数のフェーズに分けました。
Phase 1：無料Web版の需要検証
現在の段階です。
登録不要のWeb版を公開し、利用されるかを確認します。
Phase 2：日常利用向け機能
需要が確認された場合、Chrome系ブラウザ拡張を検討します。
想定している機能は次のようなものです。
- 貼り付け前のマスキング
- ドメイン単位の有効・無効設定
- 端末内に保存するカスタムルール
- AI回答の再置換
- 最小限のブラウザ権限
ここで重要なのは、現時点でChrome拡張を公開済みとはしていないことです。
先に無料Web版で需要を検証し、実際に日常利用したい人が存在することを確認してから開発します。
Phase 3：課金検証
有料機能の候補として、次のようなものを想定しています。
- 自動マスキング
- カスタムルール
- ブラウザ拡張
- 高度な検出設定
- チーム向け共有ルール
ただし、価格や有料化は決定事項ではありません。
まず無料版の利用実態と支払意思を確認し、有料版を作る根拠が得られた場合に限って進めます。
これは、利用者が存在するか分からない段階で課金基盤を作り込まないためです。
⸻
成功条件だけでなく、撤退条件も決めた
AIによる事業計画で興味深かったのは、成長計画だけでなく、開発停止の条件も定義したことです。
無料Web版では、次のような指標を参考値として計測します。
- ツールが表示された回数
- マスキング済み文章がコピーされた回数
- 再置換後の文章がコピーされた回数
- 有料機能への関心が示された回数
- 任意回答で再利用意思が示された件数
ただし、匿名計測には限界があります。
MaskedFormでは、個人を識別するためのCookie、メールアドレス、IPアドレス、端末ID、セッションIDなどを分析目的で保存しません。
したがって、取得できる操作回数を、そのまま利用者数やコンバージョン率とは呼べません。
同じ人が複数回操作している可能性を区別できないためです。
この制約も含め、次のような判断基準を設定しました。
- 複数の指標を達成した場合は、次の機能開発へ進む
- 一部だけ達成した場合は、訴求や対象用途を変更して再検証する
- ほとんど利用されなければ、追加開発を停止する
- 技術的に作れることと、事業として需要があることを分けて判断する
AIに事業を任せる場合でも、「作り続けること」自体を目的にしてはいけません。
開発を続けない条件を事前に決めることは、特に個人開発では重要だと感じました。
⸻
AIと人間の役割分担
今回の実験は「AIだけで会社を経営した」というものではありません。
AIが実行した範囲と、人間の判断が必要だった範囲を明確に分けています。
AIが担当したこと
AIは、主に次の作業を担当しました。
- 事業案の検討
- 対象顧客の設定
- 価値仮説の整理
- 機能要件の作成
- プライバシー境界の設計
- Webアプリの実装
- テストの作成
- GitHubリポジトリの整備
- ロードマップの作成
- READMEの作成
- 利用規約とプライバシーポリシーの草案
- 公開前チェック項目の作成
- ロールバック手順の作成
- 公開サイトの文章作成
- 問い合わせ導線の整理
- 将来の課金方法の調査方針作成
- 今回のような広報記事の作成
つまり、企画、設計、実装、文書化の大部分はAIが進めています。
人間が担当したこと
一方で、次のような作業は人間が判断または操作しました。
- 実験そのものを開始する判断
- 利用可能な環境の提供
- GitHub連携の許可
- 公開範囲の承認
- 一般公開するかどうかの最終判断
- 問い合わせ先の決定
- APIron Labを運営主体として表示する判断
- 有料化を急がないという判断
- 外部サービスのアカウント操作
- 費用が発生する処理の承認
- 法的責任を伴う内容の最終確認
AIは契約主体になれず、決済口座も開設できません。
また、公開によって発生する責任をAIへ移すこともできません。
そのため、今回の「AI主導」は、すべてを無人で実行したという意味ではありません。
より正確には、
AIが事業開発の実務を広範囲に進め、人間が権限・責任・費用を伴う判断を行った
という形です。
⸻
人間がAIの提案を変更した例
AIの提案を、そのまま採用したわけではありません。
例えば、公開方法についてAIは当初、限定公開による検証を挟む案を提示しました。
しかし、人間側では次のように判断しました。
- まず周知しなければ利用データを集められない
- 機密性の高い利用者データを収集するサービスではない
- 無料ベータとして公開範囲を明示できる
- 問題があれば公開停止できる
- 限定公開を挟む実益が小さい
そのため、限定公開を省略し、一般公開、検索エンジンへの登録、APIron Labからの導線追加をまとめて実施する方針へ変更しました。
また、AIは早い段階から有料プランや販売方法も検討しました。
これに対して人間側では、
まだ利用者がいるかも分からない段階で、有料版の話を進めるべきではない
と判断しました。
そこで、販売方法は将来の選択肢として文書化するだけにとどめ、現在は無料公開と需要検証を優先しています。
AIは一貫した計画を作ることはできますが、事業上の優先順位が妥当かどうかは、人間が批判的に確認する必要があります。
⸻
セキュリティ上の位置付け
MaskedFormは、DLP製品ではありません。
すべての個人情報や機密情報を完全に検出できるとは保証していません。
例えば、文章の文脈によってのみ機密性が判断できる情報や、独自形式の顧客番号などは、自動的に検出できない場合があります。
誤検出も起こり得ます。
そのため、MaskedFormは次の位置付けで提供しています。
生成AIへ送信する前に、利用者が文章を確認するための補助ツール
マスキングされたから安全であると自動的に判断するのではなく、最終的には送信前に利用者自身が内容を確認する必要があります。
公開時には、この制約をREADME、利用規約、プライバシーポリシー、画面上の説明に反映しました。
技術的にできることだけでなく、「できないこと」を明示する作業もAIに行わせています。
⸻
公開までに整備したもの
サービスを公開するためには、アプリ本体以外にも多くの成果物が必要でした。
今回、次のような文書や運用情報を整備しました。
- README
- 事業・開発ロードマップ
- プライバシーポリシー
- ベータ版利用規約
- セキュリティ報告手順
- 問い合わせ先
- 匿名イベントの定義
- 計測結果の解釈上の制限
- 公開前チェックリスト
- 公開判断の記録
- ロールバック手順
- 将来のマーケット販売方針
- GitHub Issue運用方針
個人開発では、アプリが動いた時点で完成と考えがちです。
しかし、公開サービスとして扱うには、少なくとも次の問いへ答えられる必要があります。
- 誰が運営しているのか
- 何を保存するのか
- 何を保存しないのか
- 問題はどこへ報告するのか
- 機密情報を公開Issueへ書いてよいのか
- サービスは何を保証しないのか
- 問題発生時にどう停止するのか
- 次の開発へ進む条件は何か
- 開発を停止する条件は何か
AIに実装だけでなく、これらの運用条件まで作らせたことが、今回の実験の重要な部分です。
⸻
技術構成
2026年7月時点のMaskedFormは、次のような構成です。
- Vinext / React
- ChatGPT Sitesを通じたCloudflare Worker互換環境への配置
- DrizzleによるCloudflare D1互換の集計イベント保存
- ブラウザ側での決定論的なマスキングと再置換
- マスキング処理におけるOpenAI API呼び出しなし
中心となる処理はクライアント側で行います。
同じ入力に対して同じトークンを割り当てる必要があるため、単純な文字列置換ではなく、検出順序と既存の対応表を考慮して安定した変換を行います。
技術構成や実装上の判断については、別の記事で詳しく紹介します。
⸻
AIは事業を作れたのか
現時点での答えは、
AIは、公開可能なサービスと事業仮説を作るところまでは到達できた。ただし、事業が成立したとはまだいえない
です。
AIは、短期間で次のものをまとめて作成できました。
- 課題設定
- 対象顧客
- MVP
- Webサービス
- テスト
- プライバシー設計
- 運用文書
- ロードマップ
- 公開手順
- 集客案
- 課金仮説
- 撤退基準
これは、従来の個人開発では別々に考える必要があった作業です。
特に、実装後に放置されがちな運用文書や撤退基準まで同時に整備できたことには価値がありました。
一方で、まだ確認できていないことも多くあります。
- 実際に継続利用されるか
- 困りごとの強さは十分か
- マスキング操作が面倒だと思われないか
- 検出対象は適切か
- Web版からブラウザ拡張へ進む需要があるか
- お金を払ってまで使いたい人がいるか
- 問い合わせや保守を継続できるか
サービスを公開したことと、事業が成立したことは別です。
今回の実験は、ようやく仮説を市場へ出せる段階まで進んだところです。
⸻
今後の検証
まずは無料Web版を通じて、次の点を確認します。
- 実際にマスキング処理が使われるか
- どの利用場面で使われるか
- 再置換まで利用されるか
- どの検出対象が不足しているか
- 誤検出や見逃しがどの程度問題になるか
- ブラウザ拡張を求める利用者がいるか
- 継続利用の意思があるか
利用実態が確認できた場合は、ブラウザ拡張のMVPへ進みます。
反対に、十分な利用が確認できなければ、機能追加を続けるのではなく、訴求方法や対象用途を見直します。
それでも反応がなければ、事業仮説自体を停止または変更します。
AIに事業開発を任せる実験だからこそ、成果を都合よく解釈せず、事前に決めた判断基準で評価する予定です。
⸻
まとめ
今回、AIへ「指定したアプリを作って」と依頼するのではなく、事業案の選定から公開までを任せました。
その結果、生成AIへ文章を送る前に機密情報候補をマスキングするWebサービス「MaskedForm」が企画・実装され、無料公開ベータとして公開されました。
今回分かったことは、次のとおりです。
- AIは課題設定から実装まで一貫して進められる
- 事業計画、運用文書、撤退基準も作成できる
- 公開サービスに必要な周辺作業も広く担当できる
- 人間は実装者よりも、承認者・責任者としての役割が大きくなる
- AIの提案をそのまま受け入れず、優先順位を修正する必要がある
- サービス公開と事業成立は明確に分けて評価すべきである
- 真の検証は公開後の利用データから始まる
MaskedFormは現在、無料の公開ベータとして利用できます。
生成AIへ送信する文章にメールアドレス、電話番号、IPアドレス、顧客名などが含まれている場合、そのまま貼り付ける前の確認手段として試せます。
- MaskedForm
https://maskedform.apiron-lab.chatgpt.site/?source=qiita&article=01 - プライバシーポリシー
https://maskedform.apiron-lab.chatgpt.site/privacy - ベータ版利用規約
https://maskedform.apiron-lab.chatgpt.site/terms - 運営者・問い合わせ先
https://apiron-lab.github.io/ja/#contact
なお、MaskedFormはDLP製品ではなく、機密情報の完全な検出を保証するものではありません。マスキング結果は、生成AIへ送信する前に必ず利用者自身で確認してください。
次回は、MaskedFormが元の文章や置換表を外部へ保存せず、ブラウザ内でマスキングと再置換を行う仕組みについて紹介します。