会員情報アプリで持つ項目と持たない項目：個人情報を最小にする設計

項目を足す前に通す4つの問い

新しい項目を足したくなったら、次の4つに順に答えます。一つでも詰まれば、その項目は保留です。

1. 使う場面は何か：「連絡する」ではなく「例会の変更をメールで知らせる」のように、操作まで書きます。
2. ないと困るのは誰か：運営側が困るのか、会員本人が困るのかを分けます。運営の「あると楽」だけなら任意か不要です。
3. 別の項目で代われないか：生年月日の代わりに「20歳以上か」のチェック一つで足りる場合があります。
4. いつ使い終わるか：使い終わる時点が言えない項目は、保管期間も決められません。

個人情報保護委員会のガイドライン（通則編）は、利用目的をできる限り具体的に特定すること、特定した目的の範囲で利用することを求めています。また、利用する必要がなくなったときは遅滞なく消去するよう努める、という考え方も示しています（個人情報保護法ガイドライン（通則編）の利用目的の特定、利用目的による制限、データ内容の正確性の確保等の各節）。上の4問は、この考え方を作業用に言い換えた編集上の手順です。法令の要件を満たすことを保証するものではありません。

棚卸し表のテンプレート

そのままコピーして、スプレッドシートに貼れる形です。

• （例）メールアドレス、目的（使う場面）：例会の変更連絡、必須／任意／持たない：必須、誰が見るか：運営担当のみ、保管期間（終了の基準）：退会後30日で削除、持たない場合の代替：―

列の書き方のルールは次のとおりです。

• 目的：場面と動作を書きます。「管理のため」「サービス向上のため」は不可です。
• 必須／任意／持たない：必須は「入力しないと会員として使えない」ものだけです。任意にするなら、空欄でも使える設計にします。
• 誰が見るか：役割で書きます。「全会員」と書く項目は特に慎重に扱います。
• 保管期間：日付ではなく、終了の基準で書きます（例：退会後30日、イベント終了後1か月）。
• 持たない場合の代替：持たないと決めた項目は、理由と代わりの方法を残します。

記入例（説明用の例）

架空の「週末ボードゲーム会」（会員約30人、月2回の例会）の名簿を想定した、説明用の例です。実在の団体のデータではなく、期間も私が置いた仮の値です。法令が定める期間ではありません。

• ニックネーム、目的：例会の出欠表示、必須／任意／持たない：必須、誰が見るか：全会員、保管期間：退会時に削除、代替：本名は持たない
• メールアドレス、目的：日程変更の連絡、必須／任意／持たない：必須、誰が見るか：運営のみ、保管期間：退会後30日、代替：―
• 参加回数、目的：幹事の持ち回り調整、必須／任意／持たない：任意、誰が見るか：運営のみ、保管期間：退会時に削除、代替：記録しない選択も可
• 緊急連絡先、目的：例会中の体調急変への対応、必須／任意／持たない：任意（会場参加のみ）、誰が見るか：当日の幹事のみ、保管期間：当日終了後に削除、代替：持たず、本人に携帯を持参してもらう
• 生年月日、目的：―、必須／任意／持たない：持たない、誰が見るか：―、保管期間：―、代替：20歳以上か確認するだけのチェック欄
• 住所、目的：―、必須／任意／持たない：持たない、誰が見るか：―、保管期間：―、代替：景品は手渡し
• 勤務先、目的：―、必須／任意／持たない：持たない、誰が見るか：―、保管期間：―、代替：使う場面なし

この例では、7項目のうち3項目を「持たない」にしました。「持たない」行を表に残すのがコツで、あとで誰かが「住所もあった方が」と言い出したときに、判断の履歴として使えます。

要配慮個人情報（病歴、障害の有無、信条など、ガイドライン上とくに配慮が必要とされるもの）に当たりうる項目は、原則「持たない」から検討を始めます。たとえば「アレルギー」を飲食イベントで聞きたい場合も、「食べられないものの有無」を当日口頭で確認する運用で足りないかを先に考えます。ただし、口頭でも病歴や信条などの要配慮個人情報を取得する場合には、原則として事前に本人の同意が必要です（通則編「要配慮個人情報の取得」）。

AIに表の下書きを頼む依頼文

AIには「項目の洗い出しと、問いへの当てはめ」を任せ、最終判断は人が行います。名簿の実データは貼らず、項目名と運営の状況だけを渡します。

あなたは会員名簿アプリの設計を手伝うアシスタントです。
以下の団体情報と「集めたい項目の候補」から、会員情報の棚卸し表を作ってください。

【団体情報】
・種類：趣味サークル（会員約30人）
・連絡手段：メール
・名簿を見る人：運営3人
・イベント：月2回、会場参加のみ

【集めたい項目の候補】
ニックネーム、メールアドレス、生年月日、住所、緊急連絡先、勤務先

【出力形式】
表の列：項目名／目的（使う場面と動作）／必須・任意・持たない／誰が見るか／保管期間（終了の基準）／持たない場合の代替

【ルール】
・目的は「管理のため」のような曖昧な書き方にしない
・目的の場面が思いつかない項目は「持たない」と判定し、理由を書く
・要配慮個人情報になりうる項目には印を付ける
・保管期間は仮案であることを明記し、法令上の根拠は断定しない
・不足している情報があれば、表の前に質問を3つまで出す

返ってきた表で、人が確認する点は次の3つです。

• 目的欄の場面が、実際の運営で本当に起きることか。
• 「持たない」と判定された項目に、運営が必要とする場面が漏れていないか。
• 保管期間が、会計書類など別の保存の必要と矛盾していないか。法令で保存が求められる情報は、消去の考え方の例外になりえます。迷う場合は、税理士や自治体・団体の相談窓口など、人の専門家に確認してください。

ノーコードツールに載せるときの注意

表で「必須」「任意」と決めた項目だけをデータ表の列にします。ノーコードツールでは、列を足すのは簡単でも、あとから消す判断が後回しになりがちです。

見せ方の設定にも注意が必要です。Glideの公式ブログ（2024年10月25日付）は、機微な情報はやむを得ない場合を除いて保存を避けること、保存する場合は行の所有者（Row Owners）で閲覧者を絞ることを推奨しています（Glide Security Best Practices）。同じ記事には、Row Ownersはメールアドレスの列などを使って、指定したユーザーがその行のデータにアクセスできるようにする仕組みとして説明されています。Glideの公式ヘルプも、画面上で隠す設定だけではデータを保護できないと説明しています。Row Ownersは行単位の制限なので、例のニックネームとメールアドレスのように「誰が見るか」が異なる項目は、別のテーブルに分けるなど、閲覧範囲ごとにデータを保護できる設計にします。

ここで扱うのは公式資料に基づく設計上の注意で、プランごとの機能差や最新の画面操作、実機での動作は確認していません。AppSheetやBubbleなど他のツールを使う場合も、「画面で隠す」設定と「データそのものへのアクセスを制限する」設定が別かどうかを、各公式ドキュメントで確かめてから設計に反映してください。

もう一つ、画面のフォームの文言も表から作ります。個人情報保護委員会のガイドライン「直接書面等による取得」は、入力画面などを通じて本人から直接個人情報を取得する場合、原則として、取得前に本人へ利用目的を明示することを求めています。入力フォームの近くに、表の「目的」列をそのまま利用目的として表示する作り方が、最も無理がありません。

保管期間の決め方と見直し

保管期間は「終了の基準」で書き、次の3種類に分けると決めやすくなります。

• イベント単位：当日の緊急連絡先など。終了後すぐに削除します。
• 在籍単位：メールアドレスなど。退会から一定日数（例では30日）後に削除します。
• 別の必要に従うもの：会費の入出金記録など。個人名簿とは分けて、保存の必要性を確認したうえで管理します。

運用では、四半期に1回など決まった時期に棚卸し表を開き、次の2点を点検します。

1. 「持たない」はずの項目が、自由記述欄やメモ欄に紛れていないか。
2. 保管期間を過ぎた行が残っていないか。

退会者の行の削除はノーコードでも手作業になりやすいので、「退会日」列を一つ設けて、絞り込みで期限切れを見つけられるようにしておくと、点検が続きます。この退会日も、使う場面（削除の期限管理）が言える項目です。