AIにテーブル設計をレビューさせる：貼ってよい情報と頼み方の型

渡してよい情報・渡さない情報の判断表

迷ったら「その情報がなくても設計の穴は指摘できるか」で考えてください。できるなら渡す必要はありません。

• テーブル名、列名、渡す？：渡してよい、理由・代わりの出し方：社名や社内プロジェクト名が入っていれば一般名に変える
• 列の型（テキスト、数値、日付、選択、関連など）、渡す？：渡してよい、理由・代わりの出し方：設計レビューの中心材料
• 選択肢の候補（「仮」「確定」など）、渡す？：内容次第、理由・代わりの出し方：病名や属性など機微な語が入るなら「区分A/B/C」に置き換える
• テーブル間の関係（1対多など）、渡す？：渡してよい、理由・代わりの出し方：「予約は1人の利用者に紐づく」のように文章で書く
• 運用ルール（誰が入力し、誰が見るか）、渡す？：渡してよい、理由・代わりの出し方：人名でなく役割で書く
• 実際の行データ、渡す？：渡さない、理由・代わりの出し方：必要なら下記のダミーに置き換える
• メール、電話、住所、氏名、渡す？：渡さない、理由・代わりの出し方：形式だけ示す（例：user001@example.com）
• APIキー、共有URL、シートのURL、渡す？：渡さない、理由・代わりの出し方：設計の指摘には不要

個人情報保護委員会は、2023年6月2日付で生成AIサービスの利用に関する注意喚起等を公表しています。事業として個人情報を扱う場合は、この資料や所管の指針を確認してください。本稿は個別の適法性を判断するものではなく、「そもそも値を渡さずに済ませる」ための型を扱います。

なお、AIサービスの「入力を学習に使わない」設定と、入力内容が秘密として守られることは別の話です。設定をオフにしたから貼ってよい、とは考えないほうが安全です。

手順1〜5：ダミーデータへの置き換え

次の手順で、手元の設計を「貼れる形」にします。

1. 設計を列の一覧に書き出す

シートやデータベースの画面を、スクリーンショットのまま貼らないでください。画面には行データが写り込みます。テキストで「テーブル名：列名（型）」の形に書き直します。

2. 値は消して、型と制約だけ残す

「山田太郎」ではなく、「氏名（テキスト、必須）」と書きます。ここで、型や制約が分からない列は「未定」と書いて構いません。AIにはその曖昧さも指摘してもらえます。

3. 選択肢と固有名詞を点検する

列名や選択肢に、取引先名、社内の部署名、個人名が入っていないか見ます。入っていれば「取引先A」「区分B」のように置き換えます。

4. 値の形式が問題になるときだけ、ダミー行を作る

電話番号の先頭の0が消える、日付の書式が揺れる、といった「値の形式」の相談では、ダミー行を数行だけ添えます。

利用者ID: U001 / 表示名: ダミー利用者A / メール: user001@example.com / 電話: 000-0000-0000
利用者ID: U002 / 表示名: ダミー利用者B / メール: user002@example.com / 電話: 000-0000-0001

実在しない値を自分で作ってください。実データの一部を伏せ字にしただけのものは、元が推測できるので避けます。

5. 貼る前に、全文を検索して確認する

貼る文章をエディタに置き、@、http://、https://、実際の人名や会社名を検索します。電話番号は10桁・11桁やハイフン入りの表記も点検します。見つかった箇所が自作のダミーか確認し、実データなら削除・置換します。検索だけでは見落とすため、最後に全文を読み直します。

設計レビュー依頼文の型

依頼文は「状況・設計・見てほしい観点・出力形式・禁止事項」の5つで組むと、返答が散らかりにくくなります。下の例は、小さな教室の予約アプリを想定した説明用の例です。

あなたはノーコードアプリのデータ設計のレビュー担当です。
初心者が自分で運用するので、専門用語には短い説明を付けてください。

【状況】
小さな教室の予約管理アプリを作ります。利用者は10〜30人程度で、
入力するのは運営者1人、予約の確認は運営者とスタッフ2人です。
【設計】（実データは含まれていません）
テーブル「利用者」：利用者ID（自動）、表示名（テキスト）、メール（テキスト）、
  電話（数値）、備考（テキスト）
テーブル「予約」：予約ID（自動）、利用者（利用者への関連）、
  日時（日時）、人数（数値）、状態（選択：仮／確定／キャンセル）、メモ（テキスト）
【ルール】
- 同じ日時に予約できる上限は1件
- 退会した利用者の予約履歴は、集計のために残したい
【見てほしい観点】
1. 同じ情報が複数箇所にないか
2. 型の選び方に後で困りそうな列はないか
3. 削除や変更をしたとき、関連データがどうなるか
4. 個人情報が入りやすく、扱いに注意が要る列はどれか
【出力形式】
指摘を重要度（高／中／低）の表にし、各行に「問題」「理由」「直し方の案」を書く。
最後に、私に確認すべき質問を3つまで書く。
【お願い】
データが足りない部分は推測で断定せず、「確認が必要」と書いてください。
実在の個人情報はここに含まれていません。値を入力するよう求めないでください。

最後の2行は、不明点を断定せず、実データを求めないよう伝えるための指定です。AIが「サンプルデータを貼ってください」と返してきても、貼らずに「列構成だけで答えてください」と戻せます。

返答が浅いときの追い依頼

指摘が一般論で終わったら、次のように絞ります。

上記の指摘のうち「重要度：高」だけを対象に、
ノーコードで実装するときの具体的な直し方を、列名と型を示して書いてください。
ツールは○○（使っているツール名）で、わかる範囲の機能名で説明してください。

AIが挙げる機能名は存在しない場合もあります。実際の画面で確かめてください。

返ってきた指摘を人が確認する観点

AIに任せるのは「穴の候補を洗い出すこと」まで、決めるのは自分です。特に次の点は、ツールの公式資料で確認します。

• 提案された型がそのツールにあるか、見る場所：ツールの公式ヘルプの列・フィールド型の一覧
• 関連（リレーション）やリスト列の作り方、見る場所：同上
• 誰がどのデータを見られるか、見る場所：ツールの権限・公開設定
• 列を消した後にデータが残らないか、見る場所：ツールの削除時の挙動

Bubbleの例を挙げます。公式マニュアルによると、フィールドの型にはテキスト、数値、日付、yes/no、ファイル、画像、住所などがあり、他のデータタイプを型に指定すると関連を作れます。「このフィールドはリスト」にすると複数の値も持てます。参照：Data types and fields

注意したいのは、同じページにある削除の説明です。フィールドを削除しても、エディタから見えなくなるだけで、基になるデータが消えるわけではなく、API経由では値にアクセスできる場合があると書かれています。個人情報の列をやめるときは、列を消す前に値を空にする、という段取りをAIの指摘とは別に決めておいてください。

また、プライバシールールの解説では、データタイプごとに、誰がどのフィールドを閲覧できるかなどを設定する方法が説明されています。ルールはサーバー側の条件で、複数のルールに合致すると権限が足し合わされる点にも注意が必要です。確認時点の英語版マニュアルの記述なので、使っているプランや最新版は各自で見てください。AIの設計レビューは「どの列が重要か」を教えてくれますが、実際に誰が見られるかは、設定画面を確認し、ログアウト状態や各役割のテスト用アカウントでも動作を確かめてください。

GlideやAppSheetなど他のツールでも同じ考え方です。AIの提案を受けたら、「その列型・設定がそのツールに実在するか」を公式ヘルプで確かめてから作り直してください。

失敗しやすい貼り方

• スクリーンショットを貼る：行データやURLが写り込みます。テキストで書き直してください。
• 「個人情報は伏せました」と言いつつ、メモ欄の例文をそのまま貼る：メモ欄は自由記入なので、実データを例文にすると紛れ込みます。
• エラーメッセージをそのまま貼る：メッセージに行の値やURLが含まれることがあります。レビュー依頼とは別の相談でも、同じ確認をしてください。
• AIの出力をそのまま本番に反映する：まずテスト用のコピーで試します。

今日やること

1. 手元の設計を「テーブル名：列名（型）」のテキストにする
2. 判断表に沿って、値・固有名詞・URLを消す
3. 依頼文の型に貼り、観点を自分のアプリに合わせて書き換える
4. 返答の重要度「高」だけをツールの公式ヘルプで裏取りし、テスト用のコピーで試す