Instagramストーリーズのアンケート・質問スタンプ活用法【2026】

Instagramストーリーズのアンケート・質問スタンプ活用法【2026】

「アンケートを置いたのに回答が集まらない。
質問スタンプには、答えにくい相談だけが届く」。
原因はスタンプの場所より、誰が何を判断できる質問なのか、回答をどう扱うかが曖昧なことです。

本稿はStoriesのpoll・question stickerの設定、質問設計、回答のprivacy-safeな再利用、同一account内の検証に限定します。
Highlightsのprofile導線はStories Highlights設計、Stories全般の企画はInstagram Stories運用ガイド、投稿時刻の判断はInstagram投稿時間の分析を参照してください。

公開日：2026年8月3日

最終更新日：2026年8月3日 執筆・監修：株式会社S.Line／岡田颯太

結論：一つのStoryで一つの判断を求める

良い質問は、回答者が文脈、選択肢、答えた後の扱いを理解できます。
pollなら二択で答えられる事実・選好、questionなら短文で答えられる具体的な問いを置きます。
「何か質問ありますか」では、対象範囲も答えの長さも分かりません。

基本flowは、背景を一枚、質問を一枚、回答後の次actionを一枚です。
最初に「誰向け・何について」を示し、二枚目で一問、三枚目で結果をどう使うかを説明します。
回答しない人にも、linkや解説で価値を返します。

目的	適した形式	良い問い	避ける問い	次の行動
理解確認	poll	手順A/Bどちらで止まる？	理解した？	該当解説へlink
優先順位	poll	次に見たいのは設定/分析？	何が見たい？	多い方を制作
用語収集	question	分からない用語を一語で	悩み全部教えて	FAQへ整理
事例募集	question	匿名で扱える失敗場面は？	画面を送って	同意を別途確認
導線確認	poll	link先を見つけられた？	買いますか？	UX修正

PollとQuestion stickerを使い分ける

MetaのInstagram Storyへのsticker追加公式Helpは、Stories作成時にsticker iconから利用可能なstickerを選ぶ基本操作を案内しています。
すべてのstickerが全account・地域で常に利用できるとは限らないため、公開前に実機で確認します。

Pollは選択肢が限定でき、回答負荷が低い形式です。
既知の選択肢の比率を知る、次のcontentを選ぶ、理解の分岐を見つける用途に向きます。
ただし二択が現実を過度に単純化する場合、「どちらでもない」「まだ分からない」を別の導線で受けます。

Question stickerは自由記述で、想定外の語彙や質問を集められます。
一方で、個人情報、長文、個別相談が届く可能性があります。
回答欄に「一語で」「個人名を書かず」「投稿で匿名紹介する場合がある」など範囲を示し、公開利用には別の確認を行います。

Quizなど正解を示す形式と、pollの意見収集を混同しません。
知識問題で不正解者を恥ずかしくさせる演出を避け、回答後に根拠と学習先を示します。
Emoji sliderは程度を直感的に集められますが、数値尺度として精密に扱わず、傾向の補助にします。

実機で設定する手順

Instagram appでStory作成画面を開き、写真・動画・背景を選びます。
sticker iconを開き、PollまたはQuestionsを選択します。
問いと選択肢を入力し、重要な本文やaccount UIと重ならない場所へ置きます。
previewで文字切れ、contrast、誤tapを確認して公開します。

選択肢は互いに重ならないようにします。
「初心者」「収益化したい」では、経験と目的が別軸です。
「まだ始めていない／投稿中」のように同じ軸へそろえます。
質問文に二つの問いを入れず、「保存とshare、どちらが大事？」のような前提が必要な問いは、前のStoryで定義します。

公開前に別accountまたはpreviewで、tapできること、linkとstickerが重ならないこと、背景動画で読めること、音声なしで意味が通ることを確認します。
small screenで上下がInstagram UIに隠れないよう、端へ寄せすぎません。

公開後は、誤字や選択肢の欠落があれば結果を無理に使いません。
質問を修正して再公開し、前回と同じ調査として合算しないでください。
実施日、質問文、選択肢、対象Story、公開時間を記録します。

答えやすい質問を設計する七つの条件

第一に対象を示します。
「Instagramを仕事で使う方へ」のように答える人を明確にします。
第二に時間軸を示します。
「今週」「直近の投稿」など、回答者が同じ範囲を考えられるようにします。
第三に一問一論点にします。

第四に答えの粒度を指定します。
questionなら「一語」「30字以内」「機能名だけ」と伝えます。
第五に個人情報を書かないよう案内します。
第六に回答の利用目的を伝えます。
「次回FAQの優先順位に使う」などです。
第七に回答後の価値を返します。
結果、解説、関連linkのいずれかを用意します。

誘導的な質問を避けます。
「この機能便利ですよね？」ではなく「使った／まだ使っていない」と聞きます。
購入意思を二択で迫るより、「説明で不足しているのは料金／使い方／対象者」のように改善可能な情報を集めます。

社会的に望ましい回答へ寄る問いも注意します。
「毎日分析していますか」ではなく「直近7日でInsightsを開いた回数に近いのは0／1回以上」のように行動へ戻します。
ただし自己申告は記憶違いを含むため、正確な利用logとは扱いません。

質問bankを検索意図から作る

質問を思いつきで作らず、検索query、DMで繰り返す一般質問、site内検索、support categoryをPII-freeに集計します。
個別相談の文面をそのままcopyせず、共通する意図へ抽象化します。
「Aさんが売れない」ではなく「商品説明から無料診断へ進めない」のようにします。

認知段階では、用語と現状の理解を聞きます。
比較段階では、選択基準を聞きます。
実行段階では、どのstepで止まるかを聞きます。
購入段階では、購入意思ではなく判断に不足する情報を聞きます。
利用段階では、操作箇所や期待との差を聞きます。

一度に質問bankを消化しません。
同じtopicを一定期間扱い、背景、質問、回答解説を一つのseriesにします。
回答が少なければ、関心がないと断定せず、閲覧数、質問の難しさ、文字量、公開時間、stickerの位置を確認します。

質問bankには、目的、対象、format、利用目的、privacy risk、回答後content、実施日、結果を記録します。
同じ問いを繰り返す場合、表現を一箇所だけ変え、結果を別母集団の平均として一般化しません。

回答をprivacy-safeに扱う

回答は公開への包括同意ではありません。
個人情報保護委員会の個人dataの第三者提供に関するguidelineを確認し、自社が取得する情報、利用目的、委託、第三者提供、本人対応を整理します。
法的判断が必要な場合は専門家へ確認します。

回答をStoryで紹介する場合、account名を隠すだけで十分とは限りません。
職業、地域、珍しい経験、文体の組合せから本人が分かる可能性があります。
内容を一般化し、複数回答をcategoryへまとめ、個別caseを再現しないことを優先します。

screen shotをそのまま再投稿せず、必要な意味だけを自分の言葉で要約します。
本人の発言として引用する場合は、掲載文、媒体、期間、広告転用、account表示を別途確認します。
未成年者、顧客、患者、相談者などriskが高い情報は、回答募集自体の設計を見直します。

DMへ続いた相談をanalyticsへ送らず、対応権限を限定します。
保存期間、削除手順、export、backupを確認し、不要になったraw dataを持ち続けません。
集計表には個人名ではなくcategoryと件数だけを残します。

回答後のStoryで信頼を作る

回答を集めっぱなしにしません。
Poll結果を紹介するとき、母数、実施日、対象account内の回答であることを示します。
「Instagram利用者の多くが」と一般化せず、「このaccountの当該Story回答では」と範囲を限定します。

Question回答は、頻度の高いcategoryを3つ程度にまとめ、各categoryへ短い回答と詳しい記事linkを置きます。
少数の深刻な相談は多数派として扱わず、公開回答が適切でない場合は一般的な窓口を案内します。

自分の予想と違う結果も隠しません。
選択肢の設計ミス、閲覧者の偏り、回答しなかった人の存在を注記します。
結果を商品claimの証拠に使わず、次のcontentとUXを改善する仮説にします。

回答者へ見返りを約束した場合は履行します。
「明日解説」と書いたら、公開できない事情が起きた場合も延期を案内します。
個別返信を約束できないなら、質問募集時に明記します。

Insightsで同一account内の変化を見る

MetaのInstagram Insights公式Helpは、professional accountでcontentのinsightsを確認できること、一部指標が推定値であることを示しています。
Story閲覧に関する公式Helpも、Storyに関する確認方法を案内しています。
画面や指標は変更されるため、取得時点の定義を残します。

比較するのは、同じaccount、近い期間、近いtopic、同じ枚数のseriesです。
他accountの回答率を目標にせず、自accountで質問文を一要素ずつ変えます。
分母はstickerのあるStoryを見たaccountとして記録し、最初のStory閲覧だけを使わないようにします。

観測値は、対象Storyのreach、回答数、次Story閲覧、link tap、profile actionです。
回答率だけ高くても、問いがcontent目的と無関係なら改善になりません。
回答後の解説閲覧と目的eventまで見ます。

sampleが小さいときは勝敗を決めません。
実施を重ねても母集団は同じではなく、topicや曜日の影響があります。
「今回の範囲で観測した差」と記録し、再検証します。
統計的有意を装う固定thresholdを作りません。

A/Bではなく一要素ずつ検証する

Instagram Storiesで厳密な同時randomized testができない場合、A/B testと断定せず、sequential comparisonと呼びます。
一回目と二回目で質問、背景、時刻、topicを全部変えると、差の理由が分かりません。

検証表には仮説、変更要素、固定要素、開始日、結果、次actionを書きます。
例は「questionを一語指定にすると自由記述開始の負荷が下がる」。
固定するのはtopic、前置き枚数、背景、公開時間帯です。
変えるのは「自由にどうぞ」と「一語で教えて」の文だけです。

結果は回答数だけでなく、回答の利用可能性とprivacy riskも見ます。
回答が増えても個人情報ばかりなら成功ではありません。
回答が少なくても、次のFAQを作れる明確な語彙が得られたなら目的に適合する場合があります。

検証中に機能障害、公開漏れ、campaignがあれば比較から除きます。
後から都合の良い期間だけ切り取らず、除外理由を記録します。

検証対象	変更する一要素	固定する要素	主指標	safety指標
Poll文	行動/感想	topic、時刻	回答/閲覧	誤解comment
Question	一語指定有無	背景、前置き	有効回答	PII混入
配置	中央/下部	文、素材	tap	誤tap、UI重なり
前置き	1枚/2枚	問い、時刻	sticker到達	離脱
結果返却	即日/翌日	集計方法	次Story閲覧	範囲の誇張

CTAへつなぐときの境界

Poll回答を、そのまま購入同意や営業連絡同意として扱いません。
「興味ある」を押した人へ無断でsales DMを送らず、明示されたlinkから本人が次へ進めるようにします。
回答はcontent改善、CTA tapはsite訪問、登録は本人確認済みsignupとして段階を分けます。

無料診断へつなぐ場合、質問と診断の関係を示します。
「分析で止まっている」を選んだ人へ、診断で何が分かり、何が分からないかを説明します。
煽るcountdownや架空の限定数を使いません。

UTMはStory series単位の非個人IDを使い、回答内容をparameterへ入れません。
utm_source=instagram、utm_medium=organic_social、utm_campaign=stories_poll_202608、utm_content=series_a_resultなど命名を固定します。

記事から自accountの導線を確認する場合は、Instagramの導線を無料診断するを利用できます。
診断は回答者個人の性質を判定せず、公開導線の見直しに使います。

企画・公開・集計checklist

企画前：目的は一つか。
対象者は明記したか。
pollの選択肢は同じ軸か。
questionの回答粒度を指定したか。
個人情報を書かない案内が必要か。
回答を何に使うか決めたか。
回答後に返す価値があるか。
個別助言を求める問いになっていないか。

公開前：実機でstickerが使えるか。
文字切れがないか。
contrastは十分か。
Instagram UIと重ならないか。
link stickerとの誤tapがないか。
音声なしで意味が通るか。
前のStoryを見なくても最低限の文脈があるか。
公開日時とquestion versionを記録したか。

集計時：対象Storyの閲覧を分母にしたか。
回答しなかった人を含めて解釈したか。
母数と期間を示したか。
別accountへ一般化していないか。
個人が推測できる少数回答を出していないか。
raw回答を不要にexportしていないか。
結果が予想と違っても残したか。

再利用時：投稿利用への確認が必要か。
screen nameを隠すだけで再識別されないか。
意味を変える切り取りをしていないか。
広告へ転用しないか。
削除依頼窓口があるか。
公開期間を決めたか。
結果に公式根拠を加えたか。

よくある失敗と修正

「何でも質問して」は範囲が広すぎます。
「Instagram分析で分からない用語を一語で」に直します。
「はい／いいえ」で答えられない複合質問は、目的別に二回へ分けます。
選択肢の片方だけ魅力的なpollは、neutralな行動選択へ直します。

回答0を需要0と断定しません。
sticker到達、表示位置、問いの理解、公開errorを確認します。
回答が多いことを市場調査の代表sampleと扱いません。
accountの閲覧者と回答者に偏りがあるためです。

匿名なら自由に公開できると考えません。
内容から本人が分かる場合があります。
要約、category化、別途同意を使います。
回答をsales listに変えません。
次actionは本人が選べるlinkにします。

「結果発表」だけで終えず、何を変えるかを示します。
質問に合う記事、操作、FAQへ接続します。
過去の結果を最新仕様の根拠として使わず、実施日と対象を残します。

FAQ

目的別の設問library

設問libraryはcopy集ではなく、どの判断を改善するための質問かを管理する台帳です。
表現だけ流用せず、自accountのtopic、対象者、次に提供できるcontentへ合わせます。
質問を公開する前に、回答がどちらでもactionを用意できるか確認します。

初心者向けの理解確認では「今止まっているのは、profile作成／最初の投稿」「Insightsで最初に探すのは、reach／保存」「用語で迷うのは、views／accounts reached」のように、同じ段階の選択肢を置きます。
「初心者／収益化」のように状態と目的を混ぜません。

発信中の人向けでは「直近の投稿で先に見るのは、非follow到達／profile行動」「企画時に決めているのは、読者の問い／format」「見直したいのは、冒頭／次action」のように、改善可能な行動へ戻します。
正解を誘導せず、回答後に両方の役割を説明します。

店舗accountでは「予約前に不足するのは、menuの違い／来店flow」「初回来店前に確認したいのは、所要時間／access」「link先で迷ったのは、menu選択／日時選択」と聞けます。
個人の健康状態や施術歴をStoryで募集せず、予約に必要な情報はsecurityのあるformへ置きます。

B2Bでは「導入判断で不足するのは、対応範囲／進行flow」「社内説明に必要なのは、費用の考え方／運用体制」「問い合わせ前に確認したいのは、対象企業／開始条件」とします。
会社名、予算、担当者名をQuestionへ書かせず、一般的な不足情報だけを集めます。

教育contentでは「次に例が必要なのは、設定／読み方」「説明で難しかった語を一語で」「実行時に止まったstep番号を一つ」のようにします。
テストの正解率を人の能力評価へ使わず、教材の説明不足を発見します。

FAQ収集では「今週のtopicで分からない用語を一語」「手順1〜4のどこで止まった？」「比較表へ追加してほしい項目は？」が使えます。
「困っていること全部」より回答をcategory化しやすく、個人情報の混入も減らせます。

段階	Poll例	Question例	回答後content	収集しない情報
認知	topicを知っていた/初めて	分からない用語を一語	用語解説	年齢、職歴
理解	手順A/Bで止まる	step番号を一つ	操作図	login情報
比較	基準は費用/対応範囲	比較したい項目	比較表	競合との契約内容
実行	次は設定/分析	error名だけ	troubleshooting	screenの個人data
検討	不足は対象/flow	説明不足を一語	FAQ、LP修正	予算、会社名
利用	使うのは日次/週次	改善したい画面名	product guide	account ID

設問libraryには廃止理由も残します。
誤解が多かった、個人情報が届いた、次actionを提供できなかった質問は、回答数が多くても再利用しません。
安全性と目的適合を回答率より上位に置きます。

Story seriesを一つの小さなlessonとして設計する

単独のstickerだけでは、質問の前提を共有できません。
seriesを「問題の確認、短い説明、質問、結果、次action」に分けます。
すべてを同時に置く必要はありませんが、読者が途中から見ても何の質問か分かるよう、stickerのある枚に対象とtopicを再掲します。

一枚目は、読者が観測できる場面を置きます。
「投稿は見られるのにprofileへ進まない」のように、架空の割合を使わず状態を示します。
二枚目は、可能性を二つに分けます。
「投稿の結論が不明」「次actionが不明」。
三枚目で「自分の投稿ではどちらを先に直したい？」とPollを置きます。

四枚目では、回答直後に最低限の価値を返します。
「結論は一枚目、次actionは最後の一文で確認」のようなcheckを示します。
五枚目は、詳しい記事または無料診断へのlinkです。
Pollを押さないと情報が得られない構造にせず、閲覧者全員が学べるseriesにします。

Question seriesでは、前の枚で良い回答例を匿名の架空templateとして示します。
「例：設定」「例：指標名」のように、実在者の回答を無断利用しません。
質問枚で文字数・個人情報禁止・利用目的を示し、後日category別に回答します。

結果seriesは、質問文、実施日、回答範囲を再掲します。
円graphの見た目だけで大差に見せず、件数と対象をtextで示します。
自由記述は原文一覧ではなくcategoryと代表的な一般語へまとめます。
回答0 categoryも、選択肢として提示した場合は隠しません。

series途中の離脱を悪いと決めつけません。
最初の枚で目的が完了する人もいます。
sticker到達、回答、結果閲覧、link tapを役割別に見ます。
すべての閲覧者を最後まで残すために結論を遅らせる手法は避けます。

Moderationとescalationの手順

Question stickerを開く前に、届き得る内容を想定します。
一般質問、support、個別相談、苦情、個人情報、権利侵害、危険の示唆にcategory化し、誰がどこまで回答するかを決めます。
担当者一人の判断で公開・返信しません。

一般質問は、確認済みのofficial情報へ回答します。
Product supportは、account情報を書かせず公式supportへ案内します。
個別相談は、公開回答できる一般論と個別判断を分けます。
苦情はStoryで反論せず、受付窓口と記録手順へ移します。

個人情報を含む回答はscreen shotを共有せず、必要な対応ownerへ安全な方法で連絡します。
回答者へ削除を依頼する前に、社内で不要なcopyを増やしていないか確認します。
権利侵害や違法性が疑われる内容は、公開せず法務・policyに沿って判断します。

自傷・他害など緊急性が疑われる内容は、一般contentの返信で解決しようとせず、platformのreport・safety機能と公的な緊急窓口を優先します。
担当者の心理的負担も考え、一人で対応させないescalationを作ります。

block、restrict、hide、reportなどの機能は目的が違います。
Metaのcomment管理に関する公式Helpを含む最新案内を確認し、自社のmoderation policyに合わせます。
批判的な意見という理由だけで消さず、個人情報、harassment、spam、安全riskなど事前基準で判断します。

対応記録には内容全文を不要に保存せず、category、対応日、owner、action、完了だけを残します。
screen captureが必要なincidentではaccessと保存期限を限定します。
content改善の集計へは大きなcategoryだけを渡します。

Measurement sheetの具体設計

集計sheetは一行を一つのStory seriesにします。
Series ID、topic cluster、目的、対象、質問version、公開日時、sticker位置、前置き枚数、閲覧、回答、次Story閲覧、link tap、除外理由を列にします。
回答者名や回答原文は入れません。

分母を複数持ちます。
Series開始閲覧、sticker枚閲覧、結果枚閲覧です。
answers / sticker_viewersは回答負荷、sticker_viewers / series_start_viewersは質問到達、result_viewers / answersは回答後だけでなく全閲覧者を含むため解釈に注意します。
指標名へ分母を明記します。

link tapはdestination側のlanding eventと照合します。
Instagram app内browser、同意、network、redirectによって差が出るため、tap数とlanding数が一致しなくてもdata欠損を確認します。
UTMがredirectで落ちたら、回答率改善より先に導線を直します。

回答の有効性は、個人情報なし、質問範囲内、category化可能、次actionへ使える、のcheckで集計できます。
有効でない回答を隠すためではなく、質問設計のriskを測るためです。
無効回答が多い場合、指示文や質問範囲を改善します。

列	定義	入力例	注意
series_id	非個人の一意ID	st_202608_topic_a	account名を含めない
objective	判断すること	FAQ優先度	売上など遠い目的にしない
question_version	文面version	qv2_one_word	後から上書きしない
sticker_views	sticker枚の閲覧	集計値	start閲覧と区別
answers	sticker回答	集計値	unique定義を記録
usable_categories	category数	3	原文をsheetへ入れない
landing_visits	UTM landing	server aggregate	tapと同一視しない
exclusion	比較除外理由	feature error	都合で除外しない

週次reviewでは、最も回答率が高いseriesを真似するのではなく、目的eventまで届いたseriesと、privacy riskが低かったquestionを探します。
質問が改善されたなら、次回versionと変更理由を記録します。

14日implementation plan

Day 1は、過去Storiesの質問を一覧化し、対象・目的・次actionが書かれていたか確認します。
原文回答はexportせず、質問文とaggregateだけを使います。
Day 2は、検索queryとFAQから質問bankを十件以内で作ります。

Day 3は、一つのtopicを選び、背景、Poll、解説の三枚を作ります。
Day 4に実機previewとprivacy reviewを行います。
Day 5に公開し、公開直後の操作errorだけを確認します。
結果を途中で変えません。

Day 6はaggregateを記録し、Day 7に結果と解説を返します。
母数と範囲を示します。
Day 8はQuestion sticker用に、Pollで選ばれたtopicの一語質問を作ります。
利用目的と個人情報禁止を明記します。

Day 9に公開、Day 10にcategory化、Day 11にFAQを作ります。
Day 12はFAQからsiteまたは無料診断へのlinkを実機検証します。
Day 13はlanding eventとUTMをreadbackします。
Day 14は次回変更を一要素だけ決めます。

このplanは回答件数を保証しません。
機能が利用できない、重大なprivacy risk、link errorがあれば公開を止めて修正します。
回答待ちの間は、既存FAQ、broken link、Highlightsの更新など独立した改善を進めます。

日	作業	完了条件	止める条件
1-2	audit・bank	目的付き質問を選定	raw PII exportが必要
3-4	制作・review	実機で意味が通る	UI重なり、同意不足
5-7	Poll・解説	範囲付き結果を返す	集計定義不明
8-11	Question・FAQ	categoryで回答	個別相談risk
12-13	導線確認	UTM landing readback	redirect欠損
14	次の一変更	仮説と期限を記録	複数変更しかできない

Accessibilityとsafe area

Storyは縦長ですが、上下にaccount情報やreply UIが重なります。
重要な質問と選択肢を中央の読みやすい領域へ置き、端へ寄せません。
link sticker、mention、pollを近づけすぎると誤tapが起こるため、操作要素間に余白を取ります。

背景動画が動く場合、半透明のsolid背景を文字の下へ敷きます。
文字色だけで選択肢の意味を分けず、labelで示します。
小さい文字に情報を詰め込まず、補足は次のStoryまたはcaption相当のtextへ分けます。

音声で質問を読む場合も同じ内容をtextで表示します。
音声なしの閲覧者が答えられることを確認します。
Videoへ自動字幕を付けた場合、固有名詞、否定、数字を手動確認します。

難しい漢字や略語には短い説明を付けます。
英語のUI名はapp表示と照合し、日本語名が変わった場合にもstickerのiconで探せる説明にします。
回答速度を煽るtimerを、理解に必要なtopicで使いません。

390×844相当の画面だけでなく、文字size設定やapp内browserも確認します。
結果Storyのgraphに代替textを置き、「青が多い」ではなく「設定を選んだ回答が多かった」のように書きます。

Team運用とapproval matrix

企画ownerは質問目的と次action、designerは可読性とsafe area、subject ownerは事実、privacy ownerは回答利用、analystは集計定義を確認します。
一人が兼務してもcheck欄を分けることで、回答数だけを追う判断を防ぎます。

低riskのPollは事前承認済みquestion bankから運用できます。
個人の経験を募るQuestion、商品claimに使う調査、未成年者を対象にし得る問い、健康・finance・法律を含む問いは、公開前に追加reviewします。
緊急性がある質問募集は行いません。

公開calendarには、question、owner、reviewer、公開日、結果返却日、archive方針を置きます。
「毎日質問する」をKPIにせず、未回答の重要意図と既存回答の返却を優先します。
担当者不在で回答を扱えない日はQuestionを開きません。

外部委託する場合、回答原文へのaccessを必要最小限にします。
制作会社へaccount passwordを共有せず、Metaの提供する権限管理を最新仕様で確認します。
export、local保存、終了時削除を契約と手順へ含めます。

月次で、誰がraw回答へaccessできるか、不要なdownloadがないか、公開再利用の同意が有効かを確認します。
退職・委託終了時はaccessを停止します。
数値reportにはaggregateのみを使います。

引継ぎ時は、成功した質問文だけでなく、公開しなかった理由も渡します。
個人情報が集まりやすかった問い、回答後の解説を用意できなかった問い、選択肢が重なった問いを再利用禁止として残します。
担当者が変わっても、raw回答を閲覧し直さずに判断できる台帳にします。

障害時の代替も決めます。
stickerが一時的に表示されない場合、無理に別accountへ切り替えず、通常のStoryで解説を公開し、質問は延期します。
外部formへ移す場合は、取得項目、privacy notice、保存先、完了messageを確認し、Instagramの回答と同じ扱いだと誤認させません。

Q1. PollとQuestion、どちらから始めるべきですか？

選択肢が既に分かるならPoll、読者の言葉を集めたいならQuestionです。
初回は回答負荷の低いPollで停止箇所を分け、その後に該当者向けQuestionで用語を集める順番が使えます。

Q2. 回答率の平均は何％ですか？

一律の平均を目標にしません。
account規模、topic、閲覧者、Story枚数、公開時刻で変わります。
同じaccount内で近い条件をそろえ、質問文を一要素ずつ比較します。

Q3. 回答をscreen shotで紹介してよいですか？

回答したことだけで公開同意があるとは限りません。
account名を隠しても内容から本人が分かる可能性があります。
利用目的を先に示し、必要なら掲載文と範囲を別途確認し、category化を優先します。

Q4. 個別相談が届いた場合はどうしますか？

Storyで診断せず、一般情報と適切な窓口を案内します。
健康、法律、finance、安全に関わる相談は専門家や公的窓口を優先します。
DM内容を公開analysisへ送りません。

Q5. Stickerが表示されません。

app更新、account、地域、機能提供状況を確認します。
公式Helpでも利用可能なstickerは変わり得ます。
再installなどの操作前にdraftを保存し、代替としてtext回答やlink formを用意します。

Q6. 何枚のStoryが適切ですか？

固定枚数ではなく、背景、質問、回答後actionが理解できる最小構成にします。
枚数を増やす場合、各枚に新しい役割があるかを確認し、stickerまでの到達を見ます。

Q7. 結果を商品訴求に使えますか？

自accountの任意回答を市場全体の証明にしません。
対象、期間、母数、質問文を示し、content改善の仮説として扱います。
商品性能の表示には別の検証と法令確認が必要です。

Q8. 同じ質問を繰り返してよいですか？

目的があり、実施日と条件を記録するなら可能です。
ただし前回回答を覚えている影響や閲覧者の変化があります。
同じ母集団の厳密なtrendと断定せず、今回の観測として比較します。

まとめ

Storiesのpoll・question stickerは、派手なinteraction装置ではなく、読者が止まる問いを小さく確認する道具です。
一問一論点、回答範囲、利用目的、回答後の価値をそろえます。
回答を公開同意やsales同意へ置き換えず、aggregateで改善します。

まず、次のcontentで判断したいことを一つ書き、二択で答えられるかを確認してください。
自由記述が必要なら「一語で・個人情報なし」と範囲を示します。
導線全体は無料診断で確認できます。