生成AIで作る業務システム——試作と本番の境界をどこに引くか

AIで速く試せるのは、どこまでか

社内に開発担当者がいない会社では、ちょっとした業務ツールでも、外注先を探し、見積もりを取るところから始まりがちでした。

いまは、申請フォームや集計、下書きの生成、社内問い合わせへの一次対応など、小さく切り出せる用途であれば、自分たちで試作品を作り、実際に触って確かめるところまで、短期間で進められる場面が増えています。

この変化の価値は、完成品をいきなり作れることではなく、まず試してから判断できることにあります。

ただし、短くなったのは主に試作までの距離です。

他者の実データを扱い、業務で使われる仕組みとして運用し続けるための責任まで、同じように軽くなったわけではありません。

ここで重要なのは、試作と本番を同じ基準で扱わないことです。

この領域を狭めることが目的ではありません。

むしろ、どこから先で確認が必要になるのかを明確にすることで、それ以外の範囲を迷わず速く進めやすくするための記事です。

なお、本記事では、具体的な実装手順やツールの選び方は扱いません。

動いたことは、安全であることの証明にはならない

生成AIに「ログイン機能を追加して」と頼むと、ログイン画面ができ、正しいIDとパスワードでログインできるところまで、短期間で進むことがあります。

画面上では、機能が完成したように見えます。

しかし、そこで確かめられたのは、正しい情報を入力したときに予定どおり動く「正常系」だけです。

別の利用者のIDを指定したときにアクセスが拒否されるか。

認証情報は安全な方法で保管されているか。

想定外の入力を受けたときに何が起きるか。

こうした点は、通常どおりログインしてみるだけでは分かりません。

ログインできるかどうかは「認証」の問題です。

ログインした人が、どのデータや機能にアクセスしてよいかは「認可」の問題です。

認証が成功したことを確かめても、他の利用者のデータが見えないことまで確認したことにはなりません。

生成AIが提案する実装には、安全なものもあれば、正常には動くものの安全ではないものもあります。

厄介なのは、画面の見た目と正常系の確認だけでは、その違いを見分けにくいことです。

どちらも画面上は成功し、どちらにも整った説明が付きます。

壊れて止まる不具合には気づけます。

安全でないまま動く実装は、画面上では成功に見えてしまいます。

この責任分担は、提供元の文書にも明記されています。

AnthropicはClaude Codeのセキュリティに関する文書で、権限は利用者が与えるものだとしたうえで、「提案されたコードとコマンドの安全性を承認前に確認する責任は利用者にある」と記しています（筆者訳、2026年8月確認時点）。

もちろん、これは「ツール側には保護の仕組みがない」という意味ではありません。

同じ文書では、手動モードでは読み取り専用の権限から始まること、変更を伴う操作の前に確認を求めること、コマンドをファイルシステムやネットワークの境界内で実行するための仕組みなども説明されています。

開始時のモードは、プランや設定によって異なります。

ただし、こうした保護機能があっても、承認前に内容を確認する役割まで利用者からなくなるわけではありません。

ツール側の保護と、利用者による確認は、どちらか一方で代替できるものではありません。

そして、その確認に必要なのは、注意深さだけではありません。

何を危険信号として捉えるべきかは、その領域を実際に扱った経験に大きく左右される可能性があります。

認証まわりを何度も実装した人なら手が止まる箇所でも、経験がなければ、画面が動いた時点で先へ進みやすくなります。

「提案させる」と「実行させる」は別

AIに案を出させることと、環境を操作させることは別です。

違いを生むのは、製品の種類よりも、使い方と与えた権限です。

提案だけなら、人が採用するかどうかを決められます。

ところが、承認なしで環境を操作できる権限を与えると、実行された後に選び直すことはできません。

そのため、提案の品質を確かめるだけでは足りません。

AIがどこまで実行できるのかも、あらかじめ制限する必要があります。

2026年4月、SaaSスタートアップのPocketOSで、AIコーディングツールCursorのエージェント（AnthropicのClaude Opus 4.6を使用）が本番データベースを削除しました。

創業者の説明によれば、削除にかかったのは約9秒です。

直近3か月分の予約や新規登録が一時的に利用できなくなり、顧客業務への影響を含む対応は30時間以上に及びました。

創業者は、エージェントが事後に、自ら破った決まりを列挙した出力も公開しています。

創業者によると、エージェントは無関係なファイルに置かれていたトークンを見つけて使用しました。

Railwayの説明では、そのトークンは長期間有効で、アカウント全体に及ぶ権限を持ち、そのアカウントが参加していたすべての作業領域を操作できるものでした。

結果として、ひとつのAPI呼び出しで本番のデータ領域が削除されました。

ここから得られる教訓は二つです。

つまり、通常の復旧手段が事故と同時に使えなくなり、提供元の別系統の備えに頼ることになりました。

Railwayはこの件を受け、API経由の削除とバックアップの削除に猶予を設けました。

さらに、トークン作成時に権限の範囲を把握しやすくするため、画面を見直す方針も示しています（2026年4月29日）。

いずれも、指示の書き方ではなく、権限と取り消し可能性を見直す対策です。

この事例を「外部サービスに預ければ安全」と単純に読むこともできません。

事故自体が外部サービス上で起きており、権限をどこまで絞れるか、どれだけ早く戻せるかは、提供元の設計にも左右されます。

それでも、提供元の仕組みを確かめ、足りない備えを自社で補う責任は残ります。

「消さないでください」という指示は、権限の制限ではありません。

本当の境界にするには、AIがそもそも触れない状態を作る必要があります。

創業者も、取り消せない操作の前には確認を挟むべきだと述べ、事故後もAIの活用を続けています。

止めるべきなのはAIの利用ではなく、確認を経ない実行です。

正常系だけでは、確認できないことがある

PocketOSの事例は、AIに与えた実行権限の問題でした。

同じ時期には、別の経路で情報が見える状態になった事例も公表されています。

ログインできることと、見てよい情報だけが見えることは別です。

2026年4月、AIアプリ開発基盤Lovableは、公開プロジェクトのチャット履歴とソースコードが、リンクを知る他の利用者から閲覧できる状態になっていたと公表しました。

原因は2026年2月の変更で生じた不具合で、いったん制限されていた公開範囲が再び開いたものです。

非公開プロジェクトと同社のクラウド製品は影響を受けていないとされています。

報道によれば、研究者が確認した範囲には、データベースの認証情報がソースコードへ直接書かれていた例もありました。

この事例では、不具合だけでなく、報告を適切な担当者へ引き上げる仕組みも機能しませんでした。

同社によると、有効な報告は2月22日に外部の脆弱性報奨金制度へ届いていました。

しかし、社内文書が古かったため、セキュリティ担当へ引き上げられないまま閉じられました。

研究者が4月20日に公表すると、同社は2時間以内に修正しました。

Lovableは、不具合が生じたこと、報告の処理に失敗したこと、当初の対外説明が問題を軽く扱っていたことを認めています。

報告が届いていても、適切な担当者まで届かなければ対応にはつながりません。

公開設定も、気づかないまま残ることがあります。

2026年5月、WIREDとAxiosは、セキュリティ企業RedAccessが、AI開発ツールで作られ公開状態にあった資産を大規模に調べた結果を報じました。

調査では、数千件が実質的に認証なしで閲覧でき、その一部から診療記録、財務情報、社内文書、顧客との会話ログなどが見えていたとされています。

調査側は、一部のツールでは公開が初期設定になっていることも要因に挙げました。

一方で、各社は調査方法や公開状態の捉え方に異議を唱えています。

Replitは、公表までの猶予が24時間未満だったとし、公開・非公開は利用者が選べる設定だと説明しました。

Base44の親会社であるWixは、検証に必要なURLが示されなかったとし、公開状態にあること自体はプラットフォームの欠陥を意味しないと反論しました。

LovableはAxiosに対し、調査に必要なURLや技術情報が不足していたと回答し、WIREDには、アプリの設定は最終的に作成者の責任だと述べています。

Netlifyは取材に回答していません。

報道側は、示された事例の一部が実際に公開状態だったことを独自に確認しています。

ただし、見えていた情報がすべて実在の機微情報だったかまでは確認できていません。

件数や個々のデータの性質には留保が必要ですが、高度な攻撃を経ず、URLへアクセスするだけで中身が見える事例があったという点は、調査と報道に共通しています。

開発中のやりとり自体が、情報の経路になることもあります。

本物の顧客データで動作確認をする。

実際の記録をプロンプトに貼る。

認証情報をAIツールへ渡す。

契約、製品、設定によっては、こうしたやりとりが履歴やログ、端末に残ります。

攻撃者が本番システムを破らなくても、そこから情報が漏れる可能性があります。

ここまで挙げたものは、原因がそれぞれ異なります。

AIに与えた権限、基盤側の不具合、公開設定、開発中のデータ利用です。

共通しているのは、正常系が動くことを確認しても、権限の範囲、認可、公開設定、復旧できるかどうかまで確認したことにはならないという点です。

動いているかどうかとは別の基準が必要です。

なお、ここで扱った3件だけで、事故が増えているとも減っているとも判断できません。

権限、認可、公開設定、復旧は、AI以前から確認されてきた項目です。

変わったのは論点ではなく、そこへ到達するまでの速さです。

PocketOSとLovableは、いずれもソフトウェアを本業とする会社です。

一方、RedAccessの調査対象には、業種も経験も異なる組織が含まれていました。

これは、特定の会社や技術者の力不足だけで説明できる問題ではありません。

専門知識は見落としを減らします。

しかし、結果を分けるのは、何を許可するかを決め、影響の範囲を把握し、異常に気づける経路を用意しているかどうかです。

本番では、「完成」の意味が変わる

試作では、まず利用者向けの機能が意図どおり動くかを確かめます。

本番では、それだけでは足りません。

たとえば、次のような技術面・運用面の準備も必要になります。

• 誰がどのデータにアクセスできるのか
• 誤って削除したとき、どの時点まで、どのように戻せるのか
• 誰が何をしたのかを、後から確認できるか
• 作った人が離れた後も、誰かが保守を続けられるか
• 事故が疑われたとき、誰が調査し、社外対応の要否を判断するのか

これらは利用者から見えにくい部分です。

画面上の機能がすべて揃っていても、こうした準備ができていなければ、本番運用の準備が整ったとは言えません。

しかも、その多くは後から簡単に追加できるものではありません。

誰がどのデータにアクセスできるかは、データの持ち方や権限の設計に左右されます。

どこまで戻せるかは、バックアップの方式や保持期間を決めた段階で大きく変わります。

後から対応しようとすると、システムの構成によっては大きな手戻りになります。

米国国立標準技術研究所（NIST）のSecure Software Development Frameworkも、セキュリティを開発後に付け足すものではなく、通常の開発プロセスに組み込むものとして位置づけています。

本番になると「完成」の意味が変わるのは、機能が増えるからだけではありません。

守り、戻し、運用し続けるための設計まで必要になるからです。

本番移行前に、確認の論点を整理する

ここまでの論点を、自社で検討しやすい形に整理します。

各項目に自社の回答、担当者、確認した日付を記録しておくと、後から構成や運用を変更するときにも見直しやすくなります。

データと環境

確認すること	主に関わる領域（例）
そもそも取得・保存しないで済むデータはないか	業務フロー／データ設計
適用される法令・契約・社内基準、利用目的、委託先、保持期間を確認したか	法務・契約／データ管理
試作環境と本番環境で、データベース、実行環境、認証情報が分離されているか	クラウド／DB／シークレット管理
開発には、架空データまたは適切に作成した合成データを使えるか。実データをもとにしたデータが必要な場合は、再識別リスクと法令上の扱いを確認したか	テストデータ管理
AI開発ツールへ本番の認証情報や実データを入力・送信しない運用になっているか。必要な場合は、契約条件、保存範囲、アクセス範囲を確認したか	AIツールの契約・設定／社内ルール
認証情報がソースコード、AIとの会話、端末上の平文ファイルに残っていないか。安全な保管、更新、失効の手順があるか	シークレット管理／権限管理／端末

権限と実行

確認すること	主に関わる領域（例）
操作を実行するAIエージェントが、本番のデータベースやデプロイ経路へ直接アクセスできない設計になっているか。必要な場合は、対象・権限・期間を限定し、承認、記録、失効の手段を設けたか	権限管理／デプロイ経路
利用者ごとのアクセス範囲が、画面表示だけでなくサーバー側でも制限されているか	API／DB／アクセス制御
別の利用者のデータへアクセスしようとしたとき、拒否されることを実際に試したか	テスト／結果の記録
支払い、送信、削除などの操作に、金額・件数・対象の上限、重複実行の防止、承認、取り消しまたは復旧の手段があるか	業務ルール／アプリ実装／外部サービス

検知・記録・復旧

確認すること	主に関わる領域（例）
異常または不正な操作を検知し、停止し、必要な担当者へ連絡できるか	監視・通知／インシデント対応
本番環境に削除保護や猶予付きの削除があり、バックアップが同じ事故で失われないよう分離されているか	クラウド／DB／バックアップ設計
許容できるデータ損失と復旧時間を定め、実際に復旧を試したか	バックアップ／復旧手順／業務継続
どの操作を記録し、どれだけ保持し、誰が閲覧できるかを決めたか	ログ設計／保持・アクセス管理
外部から届いた脆弱性や異常の報告を、適切な担当者まで確実に届ける経路があるか	報告窓口／社内手順

継続運用と責任

確認すること	主に関わる領域（例）
作成者以外にも、システムを保守し、必要なときに停止できる人がいるか	運用体制／保守
事故が疑われたときの初動責任者と、判断の経路が決まっているか	インシデント対応／社内体制
本番移行前に、扱うデータと機能に必要な専門知識を持つ人が確認したか	社内レビュー／外部レビュー

先に「持たないで済むか」を考える

表の最初に、データを取得・保存しない選択を置いたのには理由があります。

マイナンバーは、漏えいして不正に用いられるおそれがあると認められる場合、本人の請求や市区町村長の職権によって変更されることがあります。

米国の社会保障番号にも、問題への対処を試みた後も元の番号を使うことで不利益が続く場合など、限られた条件で別の番号を割り当てる仕組みがあります。

ただし、いずれも所定の手続きが必要です。

番号を変更しても、すでに外へ出た情報そのものを取り消せるわけではありません。

だから「どう暗号化するか」を考える前に、そもそも取得・保存する必要があるのかを検討します。

日本のマイナンバーについては、利用できる事務や特定個人情報ファイルの作成が、通常の個人情報より厳しく制限されています。

カード会員データも同じ考え方です。

PCI DSSは、カード会員データを保存・処理・送信する環境に、技術面と運用面の要件を定めています。

自社のシステムがカード会員データを保存・処理・送信しない構成にできれば、適用範囲を縮められる場合があります。

ただし、決済を外部へ委託しても、委託先の管理や、自社側に残る適合確認までなくなるわけではありません。

取得しないデータは、自社の保有・処理経路から漏れることもありません。

保存・処理・送信する範囲を狭めるほど、管理しなければならない経路も減ります。

確認を形式で終わらせないために

表を埋めること自体が目的ではありません。

認可や復旧には、その領域の実務経験がなければ見つけにくい論点があります。

また、問題が見つかったときに、本番移行を保留できる権限と手順も必要です。

問題が見つかっても止められないなら、確認は形式だけになりやすくなります。

本番移行の判断基準は、確認を始める前に決めます。

完成した後に決めると、すでにできたものへ基準を合わせやすくなるからです。

作成者と確認者を分けるかどうかは、想定される影響の大きさと、法令や契約が求める独立性によって判断します。

社内に必要な知見がなければ、外部の専門家による確認を検討します。

外部レビューを入れたこと自体が安全性を保証するわけではありませんが、社内にない知見を補う手段にはなります。

会社の規模によって変わるのは、主に誰が確認を担うかと、どこまで深く確認するかです。

アクセス制御、復旧、記録、責任者といった論点そのものが、小規模な会社だからなくなるわけではありません。

また、一度確認すれば終わりではありません。

扱うデータ、与える権限、お金の処理、外部サービスとの連携、システムの構成が変わるたびに、必要な論点を見直します。

確認の深さは、変更内容と想定される影響に応じて調整します。

境界を決めるのは、速く進めるため

確認の深さを分ける目的は、作れる範囲を狭めることではありません。

何をどこまで確認するかが曖昧なままだと、すべてが「なんとなく危ない」ものに見えてしまいます。

その結果、実データや本番権限に触れない小さな試作まで、同じ議論に巻き込まれて止まりやすくなります。

境界を決めるのは、その外側を無条件に安全とみなすためではなく、影響の小さい範囲を迷わず速く進めるためです。

一方、本番で事故が起きたとき、問題はAI活用が止まることだけではありません。

業務の停止や復旧費用、顧客・取引先への説明、契約や法令に基づく対応、信頼の低下など、事業そのものに影響が及ぶ可能性があります。

そのうえで、社内に「AIを使ったから問題が起きた」という受け止めだけが残ると、本来は安全に進められる活用まで止まりかねません。

だから、安全性を高める設計は、AIの利用を抑えるためのものではありません。

事故を起こしにくくし、起きた場合の影響を限定し、事業として使い続けられる状態をつくるためのものです。

AIで速くできるところは、速く進める。

利用者や事業に影響するところでは、守り、戻し、説明できる状態を整える。

この二つは対立するものではありません。

扱う範囲を分けることで、どちらも実現しやすくなります。

情報の確認と本記事の位置づけ

本記事は、2026年8月確認時点の情報をもとに、生成AIを使った業務ツールを試作から本番へ移す際の論点を一般的に整理したものです。

制度、ガイドライン、規格、製品の仕様は変更される可能性があります。

また、適用される法令、契約上の義務、必要な対策は、業種、扱うデータ、利用地域、システムの構成などによって異なります。

本記事に示した目安や確認項目は、個別のシステムの安全性、適法性、契約への適合性を判定または保証するものではありません。

実際の判断では、最新の一次情報を確認し、自社の状況に応じて、法務、セキュリティ、インフラ、業務運用などの専門的な観点から検討してください。

主な参照元は次のとおりです。

制度・規格: 個人情報保護委員会「特定個人情報の適正な取扱いに関するガイドライン（事業者編）」（令和7年6月一部改正）、デジタル庁「マイナンバー制度に関するよくある質問」、米国社会保障局（SSA）「Can I change my Social Security number?」、米国国立標準技術研究所（NIST）「Secure Software Development Framework（SSDF）Version 1.1／SP 800-218」（2022年2月）、PCI Security Standards Council「PCI DSS」および同協議会のFAQ（決済処理をすべて外部委託する加盟店への適用について）。

ベンダー資料: Anthropic「Claude Code — Security」ドキュメント。

事例: PocketOSについては、創業者Jer Craneの公開した説明、基盤提供元Railwayの公式事後説明（2026年4月29日）、Euronews、ABC News、Fast Companyなどの報道（2026年4月）。

Lovableについては、同社の公式事後説明「Our response to the April 2026 incident」（2026年4月22日）およびThe Next Webの報道。

公開状態にあった資産の調査については、RedAccessの調査およびWIRED、Axiosの報道（2026年5月7日）。