AI研究
AIメモリガバナンスの枠組み：何を記憶し、いつ忘れ、どう個人情報保護を守るか
記憶を持つAIは使うほど賢くなりますが、ガバナンスのない記憶は使うほど企業を露出させます。本稿は個人情報保護法、GDPR、EU AI法の実際の条文を用い、実装可能なAIメモリガバナンスの枠組み——情報の階層化、保持と忘却、PIIコンプライアンス、アクセス制御と監査——を示します。
「Cursor で 2 週間で作りました。機能は一通り揃っていて、投資家に見せても評判は悪くありませんでした」。その次に続くのはたいてい「でも実際に顧客に使ってもらうには、何が足りないのかわかりません」という言葉です。この「わからない」の代償は、公開してから表面化します。ある顧客のデータが別の顧客に見えてしまう、データベースを誤って削除して復元できない、深夜に 3 時間落ちていたのに翌日まで気づかない、といった形で。作ったものの出来が悪いわけではありません。「デモができる」と「本番で使える」の間にまだ埋まっていない部分があると、誰も教えてくれなかっただけです。以下の五つが、その差の中でもっともよく欠けているものです。
「できあがった」と「公開できる」の間にある差
同じプログラムでも、デモと本番環境ではまったく状況が違います。
- 使う人が違う：デモは自分でクリックしますが、本番ではお金を払った顧客がクリックします。あなたが想定した順番どおりには操作しません。
- データが違う：デモは架空のデータなので、削除してまた作ればよいだけですが、本番は本物の注文や個人情報で、削除すれば戻ってきません。
- エラー時の対応が違う：デモでエラーが出たら再読み込みすればよいですが、本番でエラーが出たら顧客はそのまま離れるか、電話でクレームを入れてきます。
AI ツールが得意なのは「機能を作ること」です。会員ログインを作れと指示すれば、会員ログインを作ります。しかし「パスワードを推測されたらどうするか」「データベースが壊れたらどうするか」「深夜に落ちたら誰が気づくか」を指示しなければ、AI はそれをやりません。Vibe Coding と本当のシステムアーキテクチャの差という記事ではなぜこの差が生まれるのかを解説しましたが、本記事ではその差の中に具体的に何が欠けているのかを扱います。
もっともよく欠けている五つのこと：それぞれ自分に問う一言
この表はそのままシステムを作った人に見せて聞いてみてください。答えられない行が、そのまま欠けている部分です。
| 欠けているもの | 自分に問う一言 | やらない場合の代償 |
|---|---|---|
| セキュリティ | 2 人の顧客がログインしたとき、A は B のデータを見られるか | 情報漏洩は「起こるかもしれない」ではなく「誰かが試すのを待っているだけ」 |
| バックアップ | データが消えたら、昨日の状態に戻せるか | 1 回の誤削除やサーバー障害で、データが完全に失われる |
| 監視 | サイトが落ちたら、数分以内に気づけるか | 顧客のほうが先に気づき、どれくらい落ちていたかもわからない |
| デプロイ | 文言を 1 か所変えて顧客に届くまで何ステップかかるか | 更新のたびに賭けになり、失敗しても元に戻せない |
| エラー処理 | 決済が応答しないとき、顧客には何が表示されるか | 顧客は問題をうまく説明できず、こちらも原因を調べられない |
この五つに共通しているのは、どれも「機能」ではないという点です。AI は自分から作ってはくれません。あなた自身がそれを指示しようと思いつかないからです。そしてこれらの代償は、必ず一番心の準備ができていないときに発生します。
10 分でできるセルフチェック
技術知識は不要です。以下の各項目に「はい」か「いいえ」で答えてください。答えられないものは「いいえ」とします。
- テストアカウントを 2 つ用意してログインすると、一方はもう一方のデータを見られない。
- コード内で password、key、secret を検索しても、本物のパスワードや鍵が見つからない。
- データベースは毎日自動でバックアップされ、バックアップはサーバー以外の場所に保存されている。
- ユーザーがアップロードした画像やファイルも毎日バックアップされている。
- サイトが落ちたとき、誰かのスマートフォンやメールに通知が届く。
- 新しいバージョンのプログラムを本番環境に反映する手順が、文書として残されている。
- 失敗したとき、数分以内に前のバージョンに戻す方法がある。
- ユーザーがエラーに遭遇したとき、表示されるのは説明文であって、白紙のページや英語の羅列ではない。
- システムがエラーを起こしたとき記録が残り、後から確認できる。
- AI ではなく人間が 1 人、システム全体の構成を把握している。
「いいえ」の数は点数ではなく、やることリストです。3 個以下なら多くの会社より良い状態です。5 個以上なら、まだ有料顧客に公開しないでください。
欠けているものが多いときはこの順番で補う
欠けているものが多いのは普通のことで、AI で作った製品はほぼどれもこうなります。大事なのは順番です。全部同時にやらず、いちばん時間のかかるものから手をつけないことです。
- まずバックアップ。もっとも安く、もっとも速く、かつ「やらなければ取り返しがつかない」唯一の項目です。
- 次にセキュリティの穴を塞ぐ。コードに直書きされたパスワードや鍵を外に出し、権限が本当に分かれているか確認します。
- 続いて監視を入れる。顧客より先に自分が気づけるようにします。
- 次にデプロイを整理する。公開を固定手順にし、前のバージョンに戻せることを確認します。
- 最後にエラー処理を補う。機能ごとに確認する必要があり最も時間がかかりますが、ここまで終えていれば代償はすでに小さくなっています。
この順番が終わるまでは、新機能を追加しないでください。追加するたびに、上の五つの対象範囲が広がります。
Nerdtechnic（恩梯科技)が AI 製品を引き継ぐときの 4 つのこと
- 最初の 1 週間でバックアップと鍵を先に補い、「やらなければ取り返しがつかない」ことをリスク圏から外します。
- 同じチームが引き継ぎ、保守、改善、継続開発を担当し、機能開発と運用が別々のベンダーに分かれて食い違うことがありません。
- 何かあれば必ず対応：サーバーやサービスに問題が起きたら 1 営業日以内に対応、不具合を報告いただいたら 2 営業日以内に評価結果を返答します。
- 契約終了時、ドキュメントと記録は御社にお渡しします。担当が変わってもブラックボックスにはなりません。
AI が機能を作ってくれた後、目に見えないその部分は、本来なら誰かが継続して見ているべきものです。
AI で作った製品を本番公開するときに補うべきなのは、まさにこの目に見えない部分です。これは私たちが Helper CTO として引き継ぐ典型的なケースです。会社の技術責任者のような存在でありながら、御社の社員ではありません。最初の一歩は 60 分のシステム健診です。コードを見せていただくだけでよく、本番環境のアカウント情報は不要です。3～5 営業日以内に、何が欠けていて何から補うべきかを明記した 1 ページのレポートをお渡しします。デモと公開の間で立ち止まっている製品があれば、まずはこちらからどうぞ：Helper CTO：システム保守プラン。
