コンセプト

フォームを作る人と、回答を読む人を分ける

English version available
フォームを作る人と、回答を読む人を分ける

最終更新日: 2026-09-18

いま使っているフォーム、誰が回答を読めますか。

管理画面にログインできる人、と答えた方が多いと思います。作った人は、当然読める。これはフォームの世界では長いあいだ当たり前でした。

でも、この当たり前は、仕事で使うと静かに破綻します。

作る技能と、読む資格は、別のものだからです。

作れる人がすべて読める、という前提

フォームの道具は、個人の道具として育ちました。

自分でアンケートを作り、自分で集め、自分で読む。作る人と読む人が同じ人なら、権限という考え方はそもそも要りません。誰も困りません。

この前提のまま、道具は会社に入ってきました。

入ってきたところで、事情が変わります。フォームは会社の入口になりました。問い合わせ、採用の応募、社内のアンケート、イベントの申込。そこに届くのは、名前、連絡先、経歴、時には体調や家庭の事情です。

作った人が、それを全部読める。読む必要がないのに、読める。

多くの組織で、この状態は事故が起きるまで問題になりません。事故が起きたときにだけ、「なぜあの人が読めたのか」と聞かれます。

制作会社で起きていること

分かりやすいのは、フォームを作るのが仕事の会社です。

クライアントのサイトに置く問い合わせフォームを作ります。デザインを整え、項目を決め、自動返信の文面を書き、公開します。ここまでが仕事です。

そのあと、回答が溜まります。クライアントの見込み客の名前とメールアドレスと相談内容が、制作した側のアカウントに溜まっていきます。

読む必要は、ありません。作業は終わっているからです。それでも読めます。

担当者が辞めたときに、その人のアカウントをどうするか。契約が終わったあと、フォームと回答をどう引き渡すか。毎回、個別に考えることになります。考えて、だいたいは「とりあえずアカウントを消す」で終わります。回答がどこへ行ったかは、はっきりしないまま残ります。

これは担当者の倫理の問題ではありません。道具が、読めない状態を作れないから起きています。

社内でも、同じことが起きています

会社の中でも構図は同じです。

人事が働き方のアンケートを取りたい。フォームを作れるのは情シスの担当者です。作ってもらいます。作った人は、自由記述まで読めます。

広報が採用の応募フォームを作る。応募者の職務経歴と志望動機が、広報の画面に並びます。

どちらも悪意はありません。作れる人に頼んだだけです。ただ、回答した人の側から見ると、話が違います。上司に読まれないと聞いたから書いた匿名の意見が、隣の部署の画面に並んでいる。そういう構図になります。

作る技能を持っている人に作ってもらうのは、合理的です。その人に読む資格まで一緒に渡してしまうところだけが、設計の問題なんです。

もうひとつ、人ではなくデータに返ってくる代償があります。守れない約束をしたフォームには、安全な答えしか集まりません。本音を聞きたくて作ったアンケートが、建前の集まりとして返ってくる。そして、その集計で意思決定をすることになります。権限の設計は法務の話に見えますが、最初に効いてくるのは、集まるものの質のほうです。

人で決めるから、毎回考えることになる

多くの組織は、この問題を「人」で解いています。

信頼できる人に頼む。読まないでねとお願いする。退職するときにアカウントを消す。異動したら引き継ぐ。

この解き方は、一件ずつは正しく見えます。でも、判断が人に紐づいているので、人が動くたびに判断し直すことになります。

担当者が異動した -> 権限をどうするか考える
契約が終わった -> 誰のアカウントに回答が残るか考える
新しい人が入った -> どこまで見せるか考える
監査で聞かれた -> 当時誰が読めたかを思い出す

しかも、最後の行だけは思い出せません。記録が無いからです。

役割で決めると、この繰り返しが消えます。「田中さんだから見せる」ではなく、「運用者だから見せない」にする。人が入れ替わっても、線は動きません。

役割で決めると、何が変わるか

FORMLOVA の法人プランでは、フォームをまとめる箱(ワークスペース)ごとに役割を持たせています。役割は閲覧者・運用者・編集者・管理者の 4 つです。

このうち運用者が、この記事の主題そのものです。

運用者は、フォームを作れます。項目を決め、デザインを整え、公開できます。何件届いたか、選択肢の分布がどうなっているかという集計も見られます。ただ、既定では個々の回答を開けません。持ち出すことも、回答者へ送ることも、外の道具へ流すこともできません。

作る仕事は全部できて、読む資格だけが無い。そういう役割です。

集計まで見られることが、この役割を形だけのものにしない条件です。何件届いたか、どこで離脱しているかが見えなければ、フォームは直せません。毎回ほかの人に画面を見せてもらうことになります。数は渡して、中身は渡さない。この分け方だから、作る仕事がそのまま続けられます。

見るもの運用者閲覧者以上
フォームの作成・編集・公開できる役割による
何件届いたか、集計の傾向見られる見られる
個々の回答の中身既定では見られない見られる
回答の書き出し・転送・外部連携既定ではできないできる

制作会社なら、担当者を運用者にします。作って、公開して、集計で反応を確認するところまではできます。クライアントの見込み客の名前を開く必要は、そもそもありません。納品のときは、ワークスペースごとクライアントの組織へ引き渡せます。引き渡したあとは、回答もフォームと一緒に相手側の持ち物になります。

社内なら、情シスの担当者を運用者にします。人事のアンケートを作れて、自由記述は読めない。頼む側も、頼まれる側も、気まずくなりません。

見せないことが目的ではありません

ここで誤解されたくないことがあります。

役割の線引きは、疑うための仕組みではありません。「見せなくていい人に、見せる判断をしなくて済むようにする」ための仕組みです。

だから、見せる側の設定も用意しています。ワークスペースには「運用者にも回答を見せる」という設定があり、これを ON にすると、その箱では運用者も回答を読めます。少人数で回していて、作る人と読む人を分ける意味が薄い箱もあるからです。

大事なのは、それが設定として存在し、切り替えた記録が残ることです。

この設定を変えられるのは、その箱の管理者だけです。変更は監査ログに残ります。監査ログは招待や役割の変更、フォームの移動と一緒に 12 か月分を持ち、CSV で書き出せます。

「うちは運用者にも見せています」と言えること。いつからそうしたかを出せること。これが、見せないことそのものより大事だと思っています。

線を引くこと自体が目的ではなく、線がどこにあるかをいつでも言えることが目的なんです。

いつ消すかを、あとで考えない

権限の話と対になるのが、期限の話です。

読める人を絞っても、回答が 5 年前のまま残っていれば、抱えているリスクは減りません。むしろ、誰も見ていないデータほど、持っていることを忘れます。

削除は、たいてい後回しになります。消す作業には締め切りが無いからです。「そのうち整理する」と言ったまま、担当者が代わります。

だから、作るときに決めます。

FORMLOVA の法人プランでは、回答を残す日数を 1 〜 3650 日で設定できます。設定はフォーム・ワークスペース・組織の既定の 3 か所にあり、フォームに近い設定が優先されます。フォームに設定があれば、それが使われます。

期限を過ぎた回答は一覧から消えます。30 日の猶予のあと、添付ファイルごと削除されます。削除の前の週には、対象の件数がメールで届きます。設定しなければ、保持期間による自動削除は行われません。

この「先に決めておく」という順番が、私は好きです。

消すことを最初に決めるのは、ためらいではありません。設計です。採用の応募フォームなら、選考が終わって何日で消すか。イベントの申込なら、開催後どれだけ持つか。フォームを作る会話の中で決めておけば、あとで誰かが思い出す必要がなくなります。

回答した人に「ずっと持っています」と言わなくて済むのは、その人のためでもあります。

AI に読ませられるのは、読める人だけ

FORMLOVA は、AI クライアントから使う道具です。ChatGPT や Claude に話しかけて、フォームを作り、公開し、回答の傾向を聞きます。

この形だからこそ、権限の線引きが効きます。

回答を読める役割の人が、自分の AI クライアントに回答を読ませることはできます。要約させることも、分類させることもできます。便利です。

読めない人には、その選択肢自体がありません。運用者が AI に「この回答を全部見せて」と頼んでも、回答は返ってきません。頼み方を工夫しても同じです。境界は、頼まれる側にあるからです。

これは AI を信用していないという話ではありません。境界を人の自制心の側に置かない、という話です。

チャットの入口は自由で、返ってくる中身は役割に従う。AI クライアントから運用する設計そのものについては、MCP フォームサービスとはで書いています。どこまで AI に任せ、どこから人が決めるかという線については、ワークフロー型 AI エージェントと自律型 AI エージェントの違いが近い話をしています。

自分の組織を見直す 5 つの問い

新しい道具を入れるかどうかとは別に、今の運用にそのまま当てられる問いがあります。

1. いま公開しているフォームの回答を、誰が読めるか言えるか
2. その中に、読む必要のない人はいるか
3. 半年前に辞めた人は、まだ読めるか
4. 一番古い回答はいつのもので、なぜまだ持っているか
5. 「誰が読めたか」を聞かれたとき、記録から答えられるか

1 と 2 に答えられない組織は、珍しくありません。私も、自分のフォームを数え直して驚いたことがあります。

答えを出すために、道具を替える必要はありません。まず、今のフォームの一覧を出して、読める人を書き出してみてください。それだけで、直したい場所がいくつか見つかります。

役割と期限で運用を組み直す具体的な形は、法人プランの説明ページにまとめています。

まとめ

フォームを作れる人が、回答も全部読める。

この前提は、個人の道具としては自然でした。仕事で使うと、説明できない状態を作ります。

作る技能と、読む資格を分けます。人ではなく役割で決めます。見せると決めた箱では、見せた記録を残します。いつ消すかは、作るときに決めます。

そうすると、退職と異動と契約終了のたびに個別の判断をしなくてよくなります。判断の代わりに、線が残ります。

自分の組織で公開しているフォームを、一度数えてみてください。誰が読めるか、いつ消えるか。その 2 つを言えるようになるだけで、フォーム運用はずいぶん静かになります。

クラスター全体を先に見たい場合はMCP フォームサービスまとめ、公開したあとの運用を自動化から整理したい場合はフォーム自動化の始め方が入口になります。

執筆・確認情報

  • 本記事の役割・保持期間・監査ログの記述は、2026-09-18 時点の FORMLOVA の仕様と、法人プランの説明ページの公開文言に合わせて確認しました。
  • 運用者が回答を読めるかどうかは、ワークスペースの設定「運用者にも回答を見せる」によって変わります。本記事の「読めない」はこの設定を変えていない既定の状態を指します。
  • 保持期間・役割・監査ログの仕様は更新されることがあります。導入を検討する場合は、公開ページの最新の記述を確認してください。

次にやること

フォームを作るだけで終わらせない

この記事の内容を、実際のフォーム作成、回答管理、MCP連携で試せます。

最終検証日:

この記事をシェア

執筆者

@Lovanaut
@Lovanaut

FORMLOVAの開発者。「ラバ = ラブ」の想いで、優しいサービスを作り続けています。

同じカテゴリの記事