Microsoft Lists/SharePointリストのフォームで氏名・メールアドレス自動取得を無効化できない理由と匿名回答の代替策

Microsoft ListsやSharePointリストの入力フォームを共有すると、回答内容だけ集めたいのに「作成者(Created by)」として氏名やメールアドレスが自動で紐づいてしまいます。この記事では、標準フォームで何ができて何ができないのかを整理し、匿名に近い運用を実現する現実的な代替案を具体的に解説します。

目次

結論:Microsoft Lists/SharePoint リストの標準フォームでは「氏名・メールアドレスの自動取得」をオフにできない

最初に結論から言うと、Microsoft Lists/SharePoint リストの標準フォームだけで、回答者の識別情報(氏名・メールアドレスなど)を「保存しない」設定は用意されていません。Microsoft 365 のサインインを前提にした仕組みのため、内部ユーザーが入力した場合は作成者(Created by)などのメタデータが自動的に紐づきます。

「作成者」列をビューやフォームから見えないようにすることはできますが、それは表示を隠すだけで、リストの内部メタデータとしては残ります。個人情報を“そもそも保存しない”運用にしたい場合は、入力の入り口を別の仕組みに切り替えるのが現実的です。

「自動取得されている」と感じるポイントは主に3種類ある

同じ「名前やメールが入ってしまう」でも、実際には別物が混ざりがちです。対策も変わるので、まずは切り分けましょう。

よくある現象正体無効化できる?現実的な対処
リストの「作成者」「更新者」に氏名が入るSharePointのシステム列(Created By / Modified By)不可列の表示を隠す/代替の入力手段を使う
フォームに「人」アイコンの入力欄が出て、ユーザー名候補が出る列タイプが「ユーザー(People)」になっている可(列設計次第)People列を使わずテキストにする/必須にしない
フォーム上部などに、回答者のアカウント情報が見えるサインイン前提のUI表示(組織内共有)不可(標準UI)匿名運用ならFormsへ切り替え

なぜLists/SharePointリストは“匿名入力”に向かないのか

SharePointリストは、タスク管理・申請・資産管理など「業務データ」を扱う前提で設計されています。誰がいつ作成・更新したかは、監査やトラブル対応(誤更新、なりすまし、情報漏えい時の調査)に直結します。だからこそ、作成者(Created by)や更新者(Modified by)といった列はシステムとして必ず保持され、標準フォームではオフにできません。

逆に言えば、匿名にしたい=追跡できない状態を許可したいという要望は、製品の思想と衝突しやすい領域です。実現したい「匿名」のレベルを先に定義しておくと、設計がブレません。

「匿名」の定義を3段階で決める

  • 表示だけ匿名:一般閲覧者には名前が見えない(管理者は見える)
  • 保存データとして匿名:データ(回答一覧)に氏名・メールを保存しない
  • 追跡困難な匿名:監査ログや関連ログからも特定しにくい(要件としては難易度が高い)

この記事の主題である「フォームに入力した内容は集めたいが、作成者情報などの識別情報を保存したくない」は、基本的に「保存データとして匿名」の話です。このレベルを狙うなら、Listsの標準フォーム単体ではなく、別の収集経路を用意するのが最短です。

標準フォームでできる対処:見せない・広げない・漏らさない

「保存しない」は無理でも、運用面で“見える範囲”を小さくすることはできます。匿名よりもプライバシー配慮を重視するケースでは、次の対処が現場でよく効きます。

ビューから「作成者」「更新者」を非表示にする

  • リストのビュー設定で、表示列から「作成者」「更新者」を外す
  • 利用者に共有するページでは、そのビューだけを表示する

ポイントは、リストのトップ画面をそのまま見せるのではなく、“見せたいビューだけが載っているページ”を入口にすることです。リンクの配り方を工夫すると、不要な列に触れる機会が減ります。

フォームの項目(列)を最小化する

Listsのフォーム編集(新しいフォーム体験など)で、入力欄として不要な列を表示しないようにするのは有効です。ただし、これはあくまでUI側の整理であり、システム列の保存そのものを止めるものではありません。

「個人情報を入力させない」設計に寄せる

匿名フォームにしたつもりでも、自由記述欄に「○○部の△△です」と書かれてしまうと匿名性は失われます。入力欄の設計で、次のような工夫をすると事故が減ります。

  • 自由記述の冒頭に「氏名・メール・社員番号など個人を特定できる情報は記入しないでください」と明記する
  • 部署や役職が必要なら、テキスト入力ではなく選択式(プルダウン)にする
  • 記述例(OK例/NG例)をフォーム下部に短く入れる

匿名で集めたい最有力の代替案:Microsoft Forms を使う

「回答内容だけを集め、氏名・メールは保存しない」要件に最も素直にフィットするのがMicrosoft Formsです。Formsは設定によって、回答に名前を紐づけずに回収できます。

Formsで「名前を記録しない」設定にする方法

Formsの設定画面で、次のいずれかを選びます。

  • Anyone can respond(誰でも回答可能):回答は名前なしで届く
  • Only people in my organization can respond(組織内のみ回答可能):Record nameのチェックを外すと、名前を記録しない
設定パターン名前・メールの記録回答できる範囲運用上の注意
Anyone can respond記録しない(匿名)リンクを知っている人全員(社外含む)リンクの拡散・想定外の回答が入りやすい。周知範囲と期限設定が重要。
Only people in my organization can respond + Record nameをオフ記録しない(匿名)組織内ユーザーのみ社内限定で匿名にしたい場合のバランスが良い。
Only people in my organization can respond + Record nameをオン記録する組織内ユーザーのみ本人確認や1人1回の制御をしたいとき向き。

匿名でも「荒れない」質問設計のコツ

匿名フォームは本音が集まる一方で、質問設計を雑にすると「短文の不満だけが大量に来て、改善に繋がらない」状態になりがちです。次の型を意識すると、集計も改善アクションも取りやすくなります。

  • 事実 → 影響 → 提案の順に聞く(例:何が起きた?/何が困る?/どうしてほしい?)
  • 自由記述は最後に1〜2問に絞り、途中は5段階評価や選択式で“傾向”を先に取る
  • 部署などの属性が必要なら、個人を特定できない粒度(例:部門レベル)にする

Formsを安全に運用するための設定チェックリスト(リンク拡散・重複回答対策)

匿名で集めるほど、リンクが想定以上に回ったり、期間外に回答が入り続けたりしやすくなります。Formsには回答受付をコントロールする設定が用意されているので、最低限ここだけは押さえておくと安心です。

設定何が防げる?おすすめの使い方
Accept responses(回答受付のオン/オフ)締切後の回答締切日時を過ぎたらオフ。案内文に締切を明記しておく。
Start date / End date(受付期間)早すぎる・遅すぎる回答社内イベントや研修アンケートは必ず期間設定。
One response per person(1人1回)重複回答組織内限定で使うと効果的。匿名性と両立したい場合はRecord nameの扱いを整理する。
Customize thank you message(完了メッセージ)回答後の不安・問い合わせ増「匿名で回収しています」「個人情報は記入しないでください」などを最後に再掲する。

SharePointにMicrosoft Formsを埋め込む手順

「SharePoint上で回答してもらいたい」「リストのページにフォームを置きたい」という場合、FormsはSharePointページに埋め込めます。手順は環境で多少表記が違いますが、流れは次の通りです。

  1. Microsoft Formsでフォームを作成する
  2. Formsの共有(送信)から、フォームのリンクまたは埋め込み用コードを取得する
  3. SharePointのモダンページを編集し、Webパーツで「Microsoft Forms」(または「埋め込み」)を追加する
  4. 取得したリンク/コードを貼り付けて公開する

SharePointに置くメリットは、社内ポータルとしての導線が作れることです。「このページから匿名で回答できます」と明示しやすく、配布URLの管理もしやすくなります。

回答をSharePointリストに集約したい場合:Power Automateで“匿名のまま”転記する

「集めるのはFormsで良い。でも、後工程のワークフローや集計の都合でSharePointリストに入れたい」というケースは多いです。その場合は、Forms → Power Automate → SharePointリストという構成が定番です。

この構成が“匿名っぽい”理由

  • Forms側で名前を記録しない設定にしておけば、回答データ自体に氏名・メールが含まれない
  • SharePointリストへの登録者(Created by)は、フローの接続に使っているアカウント(例:業務用のサービスアカウント)になる

つまり、リスト側で作成者が残るという仕様は変えられないものの、作成者=回答者にならないため、閲覧者が回答者個人を特定しにくい設計にできます。

Power Automate転記フローの作り方(概要)

  1. トリガー:「Microsoft Forms – 新しい応答が送信されたとき」
  2. アクション:「Microsoft Forms – 応答の詳細を取得」
  3. アクション:「SharePoint – アイテムの作成」
  4. Formsの各回答を、リストの各列にマッピングする
構成入力者の氏名・メールSharePointリストのCreated by向いている用途
Lists標準フォームのみ自動で紐づく回答者本人申請・チケット・台帳など、誰が作ったか重要な業務
Forms(匿名)+ SharePointは使わない保存しないなしアンケート・満足度・改善提案など、とにかく本音回収
Forms(匿名)+ Power AutomateでSharePointに転記保存しないフロー実行アカウント匿名回収しつつ、後工程(集計・一覧管理・通知)をリストで回したい

実務での設計例:目的別に“最短で失敗しない”構成を選ぶ

改善提案箱(社内限定・匿名・継続運用)

  • 入口:Forms(組織内のみ回答可+Record nameオフ)
  • 集約:Power AutomateでSharePointリストに転記(Created byはサービスアカウント)
  • 運用:月次で集計し、採用/検討/見送りのステータス列をリストで管理

この形の強みは「匿名性」と「業務の進捗管理」を両立できる点です。特に継続運用では、Forms単体よりもリストに転記して状態管理する方が、担当者が回しやすくなります。

研修・イベント後アンケート(期間限定・重複防止を優先)

  • 入口:Forms(受付期間を設定、必要ならOne response per personも活用)
  • 匿名性:本音回収が目的ならRecord nameオフ、受講証跡が必要ならRecord nameオン

研修の満足度調査は「匿名で本音を集めたい」と「受講確認を取りたい」が混ざりやすい領域です。どちらが主目的かを決めて、匿名設定を選び分けるのが事故を減らします。

相談窓口(プライバシー最優先)

  • 入口:Forms(匿名設定)
  • 閲覧権限:回答を見られるメンバーを最小化し、担当者以外はアクセスできない場所で管理
  • 注意:自由記述に個人情報が入りやすいので、注意書きを強めに入れる

この用途では「技術で匿名化する」よりも、アクセス権限と運用ポリシー(誰が見られるか、保管期間、共有禁止のルールなど)の方が重要になります。

「表示だけ匿名」で良いなら:SharePointリストの権限設計で守れる範囲もある

要件が「保存しない」ではなく「他の一般ユーザーからは見えないようにしたい」なら、SharePointの権限設計で現実的にカバーできることがあります。たとえば、投稿内容を投稿者本人と管理者だけが見えるようにするイメージです。

ただし、ここでの注意点は次の2つです。

  • 権限で隠せるのは“閲覧範囲”であり、作成者メタデータが保存されないわけではない
  • 管理権限を持つユーザーが完全に見られない設計は、基本的に難しい(運用ポリシーで担保する領域)

添付ファイルを使う場合は要注意

「アイテムは見えないはずなのに、添付ファイルだけ見えてしまう」といった事故が起こることがあります。実際、アイテムレベルの権限設定が添付ファイルに同じように適用されないケースがあるため、機密性が高い運用で添付ファイルを使う場合は事前検証が必須です。

安全側に倒すなら、添付ファイルを受け付けない設計にするか、ファイルは別のドキュメントライブラリで権限設計するなど、分離を検討してください。

よくある質問:Lists/SharePointリストで匿名化したいときの落とし穴

「作成者」列を削除すれば解決しませんか?

残念ながら、SharePointリストの「作成者(Created by)」はシステム列に近い扱いで、標準の考え方としては削除対象ではありません。表示を隠すことはできても、仕組みとして保持される前提です。

Power Appsでフォームをカスタマイズすれば、作成者を消せますか?

入力UIをPower Appsで変えても、データの保存先がSharePointリストである限り、作成者・更新者のメタデータが残るという前提は変わりにくいです。匿名性を優先するなら、保存先自体を変える(Formsに寄せる、サービスアカウント経由で登録する)という発想が必要になります。

「社内限定」で、なおかつ匿名にしたいです

Formsの「組織内のみ回答可能」を選び、名前を記録する設定(Record name)をオフにするのが、最もバランスが良い選択肢です。

機能追加を望むなら:公式チャネルにフィードバックを出す

「Listsのフォームで、Created byなどの作成者メタデータを任意で無効化できるオプションが欲しい」という要望は一定数あります。ただし現状は製品仕様として制約があるため、実現を期待するならMicrosoftのフィードバックチャネルへ投稿するのが現実的です。

投稿する際は、次のように用途と困りごとを具体的に書くと伝わりやすくなります。

  • 社内アンケートで本音を集めたいが、作成者が残ると回答が萎縮する
  • ビュー非表示では管理者が見えてしまい、匿名性として不足
  • Formsのように「名前を記録する/しない」をListsにも欲しい

まとめ:要件別のおすすめルート

要件おすすめ理由
誰が入力したかを管理したい(監査が必要)Lists/SharePointリストの標準フォーム作成者メタデータが自然に残り、運用がシンプル
氏名・メールを保存せずに本音を集めたいMicrosoft Forms(匿名設定)設定だけで名前を記録しない運用が可能
匿名回収しつつ、リストで集計・通知・フロー連携したいForms(匿名)+ Power AutomateでSharePointに転記回答者個人をリスト側で特定しにくくしつつ、リストの利点を活かせる

「Listsで匿名にしたい」と考えたときは、まず匿名の定義を決め、次に入力の入口をどこに置くかを検討してください。標準フォームの限界を理解したうえで、FormsやPower Automateを組み合わせると、現場で回る“ちょうど良い匿名性”に着地しやすくなります。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次