最終更新日: 2026-10-15
フォームの作成と個々の回答の閲覧は別の責任です。作る人、生の回答・出力を見る人、保持期間を決める人を本収集前に分けます。所有者・個別所属・箱設定で別の経路があるため、役割名だけで読めないと判断しません。
以下の制作会社や社内の場面は運用を考えるための想定例です。法人プランの権限を説明し、無料で試せる下書きと、有料で検証すべき権限を分けます。
作れる人がすべて読める、という前提
フォームの道具は、個人の道具として育ちました。
自分でアンケートを作り、自分で集め、自分で読む。作る人と読む人が同じ人なら、権限という考え方はそもそも要りません。誰も困りません。
この前提のまま、道具は会社に入ってきました。
入ってきたところで、事情が変わります。フォームは会社の入口になりました。問い合わせ、採用の応募、社内のアンケート、イベントの申込。そこに届くのは、名前、連絡先、経歴、時には体調や家庭の事情です。
作った人が、それを全部読める。読む必要がないのに、読める。
多くの組織で、この状態は事故が起きるまで問題になりません。事故が起きたときにだけ、「なぜあの人が読めたのか」と聞かれます。
制作会社で起きていること
分かりやすいのは、フォームを作るのが仕事の会社です。
クライアントのサイトに置く問い合わせフォームを作ります。デザインを整え、項目を決め、自動返信の文面を書き、公開します。ここまでが仕事です。
そのあと、回答が溜まります。クライアントの見込み客の名前とメールアドレスと相談内容が、制作した側のアカウントに溜まっていきます。
読む必要は、ありません。作業は終わっているからです。それでも読めます。
担当者が辞めたときに、その人のアカウントをどうするか。契約が終わったあと、フォームと回答をどう引き渡すか。毎回、個別に考えることになります。考えて、だいたいは「とりあえずアカウントを消す」で終わります。回答がどこへ行ったかは、はっきりしないまま残ります。
これは担当者の倫理の問題ではありません。使う道具や設定で、作成と生データ閲覧を分離していない場合に起きる構図です。
社内でも、同じことが起きています
会社の中でも構図は同じです。
人事が働き方のアンケートを取りたい。フォームを作れるのは情シスの担当者です。作ってもらいます。作った人は、自由記述まで読めます。
広報が採用の応募フォームを作る。応募者の職務経歴と志望動機が、広報の画面に並びます。
どちらも悪意はありません。作れる人に頼んだだけです。ただ、回答した人の側から見ると、話が違います。上司に読まれないと聞いたから書いた匿名の意見が、隣の部署の画面に並んでいる。そういう構図になります。
作る技能を持っている人に作ってもらうのは、合理的です。その人に読む資格まで一緒に渡してしまうところだけが、設計の問題なんです。
もうひとつ、人ではなくデータに返ってくる代償があります。守れない約束が、書かれる内容に影響する可能性があります。この影響は今回測定しておらず、「安全な答えだけになる」とは断定しません。意見を控えた回答に基づいて判断するリスクも考えられます。権限を整えれば回答の質が上がると保証するものではなく、説明の理解度と回答内容を実際の運用で確認する必要があります。
人で決めるから、毎回考えることになる
多くの組織は、この問題を「人」で解いています。
信頼できる人に頼む。読まないでねとお願いする。退職するときにアカウントを消す。異動したら引き継ぐ。
この解き方は、一件ずつは正しく見えます。でも、判断が人に紐づいているので、人が動くたびに判断し直すことになります。
担当者が異動した -> 権限をどうするか考える
契約が終わった -> 誰のアカウントに回答が残るか考える
新しい人が入った -> どこまで見せるか考える
監査で聞かれた -> 当時誰が読めたかを思い出す
しかも、最後の行だけは思い出せません。記録が無いからです。
役割で決めると、この繰り返しが消えます。「田中さんだから見せる」ではなく、「運用者だから見せない」にする。人が入れ替わっても、線は動きません。
役割で決めると、何が変わるか
FORMLOVA の法人プランでは、フォームをまとめる箱(ワークスペース)ごとに役割を持たせています。役割は閲覧者・運用者・編集者・管理者の 4 つです。
このうち運用者が、この記事の主題そのものです。
運用者は、フォームを作れます。項目を決め、デザインを整え、公開できます。何件届いたか、選択肢の分布がどうなっているかという集計も見られます。ただ、既定では個々の回答を開けません。持ち出すことも、回答者へ送ることも、外の道具へ流すこともできません。
通常の作成・集計確認と、生データや外へ流す設定の権限を分ける役割です。通知先、サンクスページ、追加CSSなど、生データを外へ出せる設定も制限対象があります。
集計まで見られることが、この役割を形だけのものにしない条件です。何件届いたか、どこで離脱しているかが見えなければ、フォームは直せません。毎回ほかの人に画面を見せてもらうことになります。数は渡して、中身は渡さない。この分け方だから、作る仕事がそのまま続けられます。
| 見るもの | 運用者 | 閲覧者以上 |
|---|---|---|
| フォームの作成・編集・公開 | できる | 役割による |
| 何件届いたか、集計の傾向 | 見られる | 見られる |
| 個々の回答の中身 | 既定では見られない | 見られる |
| 回答の書き出し・転送・外部連携 | 既定では制限 | 生データ閲覧と各操作の権限による |
組織所有者は組織所有のフォーム回答を読めます。組織管理者というだけでは生データ閲覧は付かず、フォーム所有・有効な個別チーム所属・箱所属・運用者可視性を含む実効権限を確認します。可視性をオフへ戻しても、既存の予約送信・シーケンスや凍結済みLINE配信は停止しません。必要な停止は個別に行います。
制作会社なら、担当者を運用者にします。作って、公開して、集計で反応を確認するところまではできます。クライアントの見込み客の名前を開く必要は、そもそもありません。納品で所有権移管を使う場合は、対象の箱・契約・組織権限の条件と相手の受諾を確認します。受諾後はフォームと回答の所有者が移り、従来の所属は解除され、通知先や連携にも変更が起きます。設定と実行中の配信を別に点検してください。
社内なら、情シスの担当者を運用者にします。人事のアンケートを作れて、自由記述は読めない。頼む側も、頼まれる側も、気まずくなりません。
見せないことが目的ではありません
ここで誤解されたくないことがあります。
役割の線引きは、疑うための仕組みではありません。「見せなくていい人に、見せる判断をしなくて済むようにする」ための仕組みです。
だから、見せる側の設定も用意しています。ワークスペースには「運用者にも回答を見せる」という設定があり、これを ON にすると、その箱では運用者も回答を読めます。少人数で回していて、作る人と読む人を分ける意味が薄い箱もあるからです。
大事なのは、それが設定として存在し、切り替えた記録が残ることです。
この設定を変えられるのは、その箱の管理者だけです。変更は監査ログに残ります。監査ログは招待や役割の変更、フォームの移動と一緒に 12 か月分を持ち、CSV で書き出せます。
「うちは運用者にも見せています」と言えること。いつからそうしたかを出せること。これが、見せないことそのものより大事だと思っています。
線を引くこと自体が目的ではなく、線がどこにあるかをいつでも言えることが目的なんです。
いつ消すかを、あとで考えない
権限の話と対になるのが、期限の話です。
読める人を絞っても、回答が 5 年前のまま残っていれば、抱えているリスクは減りません。むしろ、誰も見ていないデータほど、持っていることを忘れます。
削除は、たいてい後回しになります。消す作業には締め切りが無いからです。「そのうち整理する」と言ったまま、担当者が代わります。
だから、作るときに決めます。
FORMLOVA の法人プランでは、回答を残す日数を 1 〜 3650 日で設定できます。設定はフォーム・ワークスペース・組織の既定の 3 か所にあり、フォームに近い設定が優先されます。フォームに設定があれば、それが使われます。
7日以内に一覧から除く予定の回答がある場合、週次(月曜・日本時間)で組織の所有者・管理者へ対象件数を通知します。保持期限を過ぎると一覧から除外する論理削除の対象になり、その論理削除から30日経過後に添付ファイルとともに物理削除されます。通知は物理削除の直前を知らせるものではないため、対象件数と通知結果を確認してください。設定しなければ、保持期間による自動削除は行われません。
この「先に決めておく」という順番が、私は好きです。
消す時期を決めるのは設計です。選考終了後や開催後に必要な保管期間は業務方針として整理します。ただし、FORMLOVAの保持期間は各回答の送信日時から計算し、選考終了日・開催日を自動の起点にはしません。方針と設定が一致するか、期限の対象件数も確認してから適用します。
回答した人に「ずっと持っています」と言わなくて済むのは、その人のためでもあります。
AI に読ませられるのは、読める人だけ
FORMLOVA は、AI クライアントから使う道具です。ChatGPT や Claude に話しかけて、フォームを作り、公開し、回答の傾向を聞きます。
この形だからこそ、権限の線引きが効きます。
回答を読める役割の人が、自分の AI クライアントに回答を読ませることはできます。要約・分類を依頼する場合も、組織の目的・規程と接続先AIのデータ取扱条件を確認します。サーバーが権限と無関係に文章要約を行う意味ではありません。
読めない人には、その選択肢自体がありません。運用者が AI に「この回答を全部見せて」と頼んでも、回答は返ってきません。頼み方を工夫しても同じです。境界は、頼まれる側にあるからです。
これは AI を信用していないという話ではありません。境界を人の自制心の側に置かない、という話です。
チャットの入口は自由で、返ってくる中身は役割に従う。AI クライアントから運用する設計そのものについては、MCP フォームサービスとはで書いています。どこまで AI に任せ、どこから人が決めるかという線については、ワークフロー型 AI エージェントと自律型 AI エージェントの違いが近い話をしています。
法人の権限検証へ進む前に下書きと権限表を作る
以下は試用の依頼例で、今回の改稿で実行・実測した結果ではありません。まず検証用の非公開下書きで確かめます。
架空のサービス問い合わせの非公開下書きを、種別と内容だけで作って。実在連絡先は入れず公開しないで。別に作成担当・回答確認担当・組織所有者の権限表を提案し、運用者と保持期間は法人要件と明記して。招待・役割・保持期間を変更せず、無料で権限設定済みとは書かないで。
次に進む前に、ここを確認します。
- 無料では項目設計だけを確認する。権限表は提案で、保存された権限ではない。
- 承認された法人の検証では別の利用者条件を使い、作成・集計・個票・出力・外部操作を実効所属と照合する。
- 保持期間は回答送信日時を起点に、フォーム/箱/組織の優先順、影響件数、削除警告を確認する。箱の移管は別の要件と受諾が必要で、自動引渡しとはしない。
法人権限の検討を、架空の下書きから始める
架空フォームの作成・確認は無料です。運用者ロール、複数ワークスペース、保持期間設定は法人プランと別の検証が必要です。
登録・メール確認後、対応AIクライアントに接続し、上の依頼文を貼り付けます。保存された下書きを確認してから公開を判断してください。AIクライアント側の契約・利用条件は別です。
自分の組織を見直す 5 つの問い
新しい道具を入れるかどうかとは別に、今の運用にそのまま当てられる問いがあります。
1. いま公開しているフォームの回答を、誰が読めるか言えるか
2. その中に、読む必要のない人はいるか
3. 半年前に辞めた人は、まだ読めるか
4. 一番古い回答はいつのもので、なぜまだ持っているか
5. 「誰が読めたか」を聞かれたとき、記録から答えられるか
1 と 2 に答えられない組織は、珍しくありません。私も、自分のフォームを数え直して驚いたことがあります。
答えを出すために、道具を替える必要はありません。まず、今のフォームの一覧を出して、読める人を書き出してみてください。それだけで、直したい場所がいくつか見つかります。
役割と期限で運用を組み直す具体的な形は、法人プランの説明ページにまとめています。
まとめ
フォームを作れる人が、回答も全部読める。
この前提は、個人の道具としては自然でした。仕事で使うと、説明できない状態を作ります。
作る技能と、読む資格を分けます。人ではなく役割で決めます。見せると決めた箱では、見せた記録を残します。いつ消すかは、作るときに決めます。
そうすると、退職と異動と契約終了のたびに個別の判断をしなくてよくなります。判断の代わりに、線が残ります。
自分の組織で公開しているフォームを、一度数えてみてください。誰が読めるか、いつ消えるか。その 2 つを言えるようになるだけで、フォーム運用はずいぶん静かになります。
クラスター全体を先に見たい場合はMCP フォームサービスまとめ、公開したあとの運用を自動化から整理したい場合はフォーム自動化の始め方が入口になります。
次に試すこと
先に既存フォーム、実効的な閲覧者、保持期間を書き出します。架空の下書きで分担を確認できる形にし、本当の顧客・社員情報を受ける前に法人の権限を別アカウントで検証してください。
執筆・確認情報
- 本記事の役割・保持期間・監査ログの記述は、2026-09-18 時点の FORMLOVA の仕様と、法人プランの説明ページの公開文言に合わせて確認しました。
- 運用者が回答を読めるかどうかは、ワークスペースの設定「運用者にも回答を見せる」によって変わります。本記事の「読めない」はこの設定を変えていない既定の状態を指します。
- 保持期間・役割・監査ログの仕様は更新されることがあります。導入を検討する場合は、公開ページの最新の記述を確認してください。


