AIによる定性アンケート分析：十五の初期コードとレビュー手順

分析方法を選び、判断の記録を残す

コードは文章の一部に含まれる分析上重要な内容を表すラベルです。テーマはパターンについてのより広い解釈であり、単なる分類箱の名前ではありません。BraunとClarkeはテーマ分析の方法を区別し、リフレクシブな方法ではコーダー間の一致を唯一の正しい解釈の証明として扱いません。本稿は業務上のフィードバックに使うコードブック方式を説明します。著者による方法論FAQ。

研究でリフレクシブ・テーマ分析を採用しているなら、固定された十五分類と一致率の目標を追加して、方法は変わっていないと説明しないでください。研究責任者と手順の一貫性を確認します。本稿の初期分類も回答を読んだ後に改訂でき、実質的な変更は記録して、影響を受けるコーディングを再確認します。

AI支援は研究の専門性の別名ではありません。Ziang Xiaoらの2023年の研究では、専門家が作成したコードブックをGPT-3と組み合わせ、特定の演繹的コーディング課題を検討しました。これは研究史上の背景であり、現在のモデル、あらゆる言語、OpenMaxの性能を示す証拠ではありません。研究概要と書誌情報。

質問文は回答と一緒に残します。「何に困りましたか」への回答と「何が良かったですか」への回答は交換可能ではありません。Pew Research Centerの分析では、自由記述質問の特徴と項目無回答のパターンに関連が見られました。ここから採る実務上の教訓は、質問文と欠測を保持することです。同研究の比率を自社調査の基準値に転用することではありません。Pewの自由記述無回答に関する分析。

コードブックの十五の初期項目

全件を処理する前に、調査の問いに合わせて調整してください。C01〜C14は内容を表すコード候補、C15はレビュー上の状態です。一つの回答に複数コードを付けられますが、それぞれを裏付ける内容が必要です。近いラベルをすべて付けて分析が豊かになったように見せないでください。

この節の引用風の短文も架空の例です。顧客の実体験ではなく分類の境界を示します。製品についての回答者の発言は、製品側の証拠を確認するまでは、あくまで報告された内容です。

1. C01 — 主なニーズ

本人が解決したいと明示している仕事や問題に使います。「計画に使う週次レポートが必要」は業務上のニーズを示します。一方、「青いボタンを追加してほしい」だけでは、周囲の文脈がない限り、背後の仕事までは分かりません。主体と状況を残し、組織戦略を推測で補わないことが重要です。

根拠となる語句を指定し、ニーズを平易に記述します。二つのニーズがあれば、現在のロードマップに合う方だけを選ばず両方を保持してください。分析者の仮説である場合は、本人の発言として扱わず、解釈と明記したメモに分けます。

2. C02 — 望む結果

転記を減らす、レポートを早く用意する、中断を減らす、担当を明確にするといった、本人が望む変化を記録します。「数字の転記をやめられるように」は手作業を減らしたい意図を表しますが、削減時間や、その機能で結果が実現することまでは示しません。

成功を判断する条件であるC05と区別します。同じ箇所が望む結果と期限の両方を示すことはありますが、単に速さを望む文章に数値目標を付け加えてはいけません。既に達成した結果と、将来への希望も別に扱います。

3. C03 — 現在の代替手段

合計値を表計算ソフトに転記するなど、現在使っていると述べた代替手順を含めます。理由があれば一緒に残します。「失敗したら表計算で対応するつもり」は将来の可能性であり、現在その手順が運用されている証拠ではありません。

代替手段を自動的に無駄と呼ばないでください。手作業がレビュー、アクセシビリティ、製品外の要件を支えている場合があります。何の役割を果たし、どの制約から必要なのかが次の調査事項です。存在するだけでは廃止を正当化できません。

4. C04 — 行動のきっかけ

出来事と、その後の行動や再検討が明示的につながっている場合に付けます。「インポートの失敗で別のツールを探し始めた」は本人が報告したきっかけです。「先週インポートに失敗した」だけでは、それが検索や乗り換えにつながったとは言えません。

本人が述べた順序と因果の帰属を保持します。自己申告の説明を、顧客全体に対する実証済みの因果効果に拡張しないでください。発売や価格変更が原因という分析者の仮説は、同じ月の回答すべてに貼り付けず、別途検討します。

5. C05 — 成功の判断基準

業務がうまくいったかを判断する、本人の条件や観察可能なテストを記録します。「月曜の計画会議より前に完成」は期限を示しますが、「もっと良いレポート」は測定可能な合格条件を定義していません。タイムゾーンなどが必要で原文にあるなら残し、ない情報は作りません。

これは調査記録であり、サービス水準の約束ではありません。一分で終わってほしいという要望は、提供側が一分を保証したという意味ではありません。条件を検証課題に使い、実現可能性、製品範囲、契約上の義務はそれぞれの責任者に確認します。

6. C06 — 肯定的な経験

具体的な良い経験と、その対象を保持します。「エクスポート操作は見つけやすく、自分には問題なく使える」は、全員が使えないという主張に対する反証です。他の人の困難を否定したり、全アカウントで同じ機能が使えることを証明したりはしません。

曖昧な「まあ良い」を詳しい成功談に変えないでください。良い点と問題点が混在する回答は、該当箇所を分けてコード化します。感情ラベルによって、具体的な理由、条件、対比を消してしまうと情報価値が下がります。

7. C07 — 否定的な経験

明示された好ましくない出来事と結果を記録します。インポート失敗を経験したという報告は対象です。失敗するかもしれないという心配は懸念であり、発生済みの事象ではありません。いずれも、それだけで製品の欠陥が確認されたことにはなりません。

重大さと責任の帰属は原文に即して記載します。「一度失敗した」を「プラットフォームは信頼できない」に変えたり、不満を過失の告発に変えたりしないでください。許可された目的とアクセス範囲で、運用ログや追加調査が確認に役立つ場合があります。

8. C08 — 使いやすさの問題

操作を見つける、理解する、移動する、学ぶ、失敗から復帰するといった場面の難しさに使います。「エクスポート操作が見つからない」は発見しにくさの根拠です。エクスポート機能が存在しないことは示しません。この区別が後述の計算例の中心です。

権限不足、明示された規則による制限、システム障害の報告と分けます。本人が支援技術の利用状況を自発的に述べた場合も、調査に必要で利用を認められた範囲だけを保持します。文章の書き方や操作の難しさから、障害、年齢、能力を推測しないでください。

9. C09 — 本人が認識する機能不足

このコードは意図的に「本人が認識する」と限定します。「このアカウントにはCSVエクスポートがない」のように、機能や範囲の欠如を明示した回答に使います。コードは発言を記録するものであり、実際の欠如、プランの制限、権限、設定の違いは製品確認で切り分けます。

別の欠如の主張がない限り、「見つからない」は除外します。追加を求める提案だけでも、現在利用できないとは証明できません。提案はC14として残し、不足の可能性は十分な証拠が得られるまで調査事項にします。

10. C10 — サポートの必要性

説明、研修、トラブル対応、人による支援を明示的に求めている場合に記録します。「操作説明があると助かる」は支援ニーズです。長い不満だけでは、本人が望む窓口まで分かるとは限りません。利用のどの段階で助けが必要なのかも残します。

信頼や使いやすさのコードと重なる場合があります。アップロードしたファイルを誰が読めるかという質問は、情報提供の依頼であり信頼上の懸念でもあり得ます。しかし、セキュリティ事故の証拠ではなく、匿名の回答者への連絡を許可するものでもありません。

11. C11 — 信頼に関する懸念

信頼性、プライバシー、セキュリティ、透明性、制御について明示された懸念や証拠の要求を含めます。「採用前にファイルを誰が読めるか説明してほしい」はアクセスについての問いです。根拠のない恐怖、確認済みの漏えい、心理的診断へ置き換えないでください。

認識されたリスク、報告された事象、独立に確認された不具合を区別します。資料を示す、事象を調べる、確認済み問題を直すでは次の行動が異なります。承認された調査チームの外に引用を渡す前に、機微な情報を保護します。

12. C12 — 価格や価値への懸念

負担可能性、請求の予測可能性、プラン、便益と費用の釣り合いについての明示された懸念に使います。否定や対比を落とさないことが重要です。「価格には納得しているが、承認手続きで導入できない」は、「価格」という語があるだけでは価格への不満になりません。

語調から予算、所得、支払意思を推測しないでください。請求書が分かりにくいという発言と、高くて払えないという発言では追跡調査が違います。頻度は調査すべき問いを示しても、新価格や売上への効果を単独で確定できません。

13. C13 — 導入の障壁

承認、連携、移行、未解決の審査事項など、利用を妨げたり遅らせたりする明示された条件を記録します。「採用前に」という表現が条件を示す場合があります。資料への一般的な関心だけでは、導入を止めているとは限りません。

現在の障壁か仮定上の条件か、誰が管理すると述べられているかを残します。回答者に購買権限があると決めつけないでください。組織の制約を個人の意欲不足や技術力不足へ言い換えるのも不適切です。

14. C14 — 改善提案

提案された変更と、明示されていればその便益を記録します。「数字の転記をやめられるようCSVエクスポートを追加してほしい」は、提案、望む結果、現在の代替手段を含みます。それぞれ原文に根拠があるため別コードを付けられます。

提案を検証済みの解決策や製品の約束と扱わないでください。担当者が調べられる具体性を残し、制約と別案も記録します。要望が多くても、実現が難しい、狭い層しか対象でない、まれだが深刻な障害より優先度が低い場合があります。

15. C15 — 未分類またはレビュー待ち

これは内容上の発見ではなく作業状態です。意味が不明、言語を確認できない、文脈不足、適合するコードがない場合に使います。空欄、質問と無関係な回答、曖昧だが空欄ではない回答は異なるため、理由を分けて残します。

例の「まあ、良いのでは」は、具体的な経験コードを付ける文脈が足りず保留します。処理完了率を上げるために肯定ラベルへ押し込めないでください。宣言した非空欄の分母には残し、未解決件数を示します。適切な追加証拠や定義の改訂が得られれば再検討します。

試行して判断の違いと変更を記録する

最初に、利用可能なデータを定義します。 招待された人、完了した人、自由記述項目を見た人を記録し、質問の版と分岐も残します。不要な項目を除き、レコードの証拠に基づいた重複判定を文書化します。異なる人の似た文章だけでは重複と判断できません。

次に、大量のラベル付けより先に読みます。 短文、長文、評価が混在する回答、少数意見、英語以外の回答を含む多様な全文を読みます。分析者の前提と、それを覆す証拠を簡潔にメモします。マーケティング用の分類に回答を合わせるのではなく、実際の問いに初期コードを合わせます。

三段階目は試行です。 この業務用コードブック方式では、承認された標本に複数の担当者が定義を適用し、判断の違いと理由を確認します。一致度を測るなら、単位、標本、統計量、複数コード、保留回答の扱いを明示します。本稿は普遍的な合格率を定めません。一致していても解釈が真であるとは限りません。

四段階目でAIの出力を限定します。 回答ID、根拠箇所、提案コード、簡潔な証拠に基づく理由を要求し、保留を認めます。モデルとプロンプトの版も保存します。生成された理由自体も検査対象であり、それだけで監査記録にはなりません。存在しないID、改変された引用、未承認コードを拒否します。

五段階目は調整と再コーディングです。 試行で発見しにくさと機能の欠如を混同したなら、C08とC09を明確にし、変更を記録します。偶然見つけた誤りだけでなく、影響し得る回答全体を再確認します。以前の割り当てと差し替え理由を残し、異なる版の結果を黙って混在させないでください。

最後に、反証を含む解釈を書きます。 調査の問いに照らして記述をまとめ、経験が食い違う部分や別の説明を示します。件数表は業務報告に役立ちますが、それだけで完成したテーマ分析にはなりません。AI調査レポートのテンプレートを使い、発見、計算、提案を分けて記録できます。

計算例：十九件のコード割り当ては十九人ではない

架空の質問は「最近のレポート作成業務について、うまくいった点、妨げになった点、変えたい点を教えてください」です。対象者二十人を招待し、十二人が調査を完了してこの項目まで到達します。十人は自由記述に回答し、二人は空欄です。S03が重複して書き出され、ファイルは十三行になりますが、固有の完了レコードは十二件のままです。

同じIDと同じ内容の重複行だけを除きます。異なるIDの似た回答は削除しません。主なコーディングの分母は、保留のS09も含めた非空欄十件です。次の表は架空回答の日本語訳で、CSVには英語の原文を収録しています。判断は明示したコードブックによる教材例であり、唯一の客観的解釈やAI製品の実行結果ではありません。

調査完了割合は 12 ÷ 20 × 100 = 60%。完了者のうち、この自由記述項目が非空欄だった割合は 10 ÷ 12 × 100 ≈ 83.3% です。これらは架空の回答経路を記述する別々の指標であり、標準化された調査回答率の推定値や代表性の証拠ではありません。

九つの回答に、内容コードが合計十九件付いています。S09には内容コードがありませんが、十件の分母に残ります。コード別比率の合計は 19 ÷ 10 × 100 = 190%。複数ラベルを認めるこの規則では成立しますが、190%の人が回答したという意味ではありません。相互排他的な円グラフの内訳として描くのは誤解を招きます。

C08はS01とS08の 2 ÷ 10 × 100 = 20%。C09はS03だけの 1 ÷ 10 × 100 = 10% です。S01とS08も機能不足に入れる誤った解釈では 3 ÷ 10 × 100 = 30% になります。修正後は、欠如の主張三件ではなく、発見しにくさ二件と明示的な機能不足の認識一件です。それでも、そのアカウントで機能が実在するかは確定しません。

S02は反対の経験として残します。S04の価格への納得を価格不満に変えず、S10の提案から現在の利用可否を断定しません。S09を保留すると内容コード付与済みの割合は 9 ÷ 10 × 100 = 90% ですが、これは例の規則による処理カバー率であり、モデル精度90%ではありません。

説明できる要約は「非空欄十件中、二件がエクスポートの見つけにくさ、一件が明示的な機能不足を報告した。一件には肯定的な経験がある。改善を選ぶ前に画面、アカウント、権限の違いを調べる。曖昧な一件は保留中」といった範囲です。架空の十件から顧客全体へ一般化したり、製品変更を約束したり、証明されていない原因を断定したりはできません。

調査のボトルネックに合わせて道具を選ぶ

手作業での分析は、扱える量の回答と細やかな解釈に適しています。管理された表計算にID、根拠箇所、コード、判断を保存できます。人数や調査回が増えた際の版管理と追跡性が課題であり、表計算では良い研究ができないという意味ではありません。

調査ツールの標準機能で十分な場合もあります。QualtricsはText iQでのトピック付与と回答確認、複数タグを説明しています。機能へのアクセスや言語対応は分析機能ごとに確認が必要です。英語、中国語、日本語ですべて同様に使えると仮定せず、契約中の具体的な手順を確認してください。Qualtrics Text iQの機能説明。

決定的なルールによる自動処理は、妥当な重複除去、許可コードの検査、分母計算に向きます。存在しない回答へのコード付与は検出できますが、「見つからない」が機能の欠如を意味するかは算術だけでは決められません。解釈はレビュー工程に残します。

エージェント支援は、基盤となる道具と権限が対応していれば、原文にひも付く草稿やレビュー待ち案件の連携に役立つ可能性があります。規模を広げる際は、言語上の失敗、コードブック変更、引用漏えい、異なる原文の版を試験します。レビュー工数を評価するなら実測方法を統一し、生成文字数から削減効果を約束しないでください。

従業員調査では、パルスサーベイ分析ガイドも参照し、対象集団と職場での報告の条件を確認します。顧客向けの手順を、そのまま雇用上の判断へ移さないでください。

範囲を限定したコーディング演習でOpenMaxを評価する

OpenMaxは公開サイトで人とエージェントの協働プラットフォームを説明しています。連携用途を相談する理由にはなりますが、検証済みの定性研究手法、専用の調査コネクター、本稿のすべてのレビュー機能や保護機能を備える証明ではありません。OpenMaxの製品概要。

架空資料、小さな合意済みコードブック、明示的な期待出力から始めます。重複規則を保持できるか、C08とC09を区別するか、S02の反証を残すか、S09を保留できるかを確認します。要約を評価する前に、各コードの根拠を読みます。

実環境でのアクセス境界、対応言語、引用の忠実性、版の記録、エクスポート、保存期間を確認します。コーディングだけの課題に連絡先を含めないでください。見栄えのよい成果物は、制限された回答を取得できないことや、少人数の詳細を自動で隠せることの証拠にはなりません。

既存の調査ツールで十分なら、そのまま使う選択が適切です。証拠の受け渡しが分断される場合は、機微な情報を除いた演習と合格条件を用意して限定したOpenMaxワークフローを相談します。次の段階は小さな課題の評価であり、機密調査全体のアップロードや公開判断の委任ではありません。

回答者を保護し、言い過ぎを防ぐ

承認された翻訳と原文を並べて保存します。否定、慣用句、複数言語の混在でコード判断が変わる場合があります。影響の大きい解釈は、その言語と研究の文脈を理解する人が確認します。モデルの確信度だけでは翻訳の同等性は証明できません。回答から本人の身元、保護対象の属性、心理状態を推測しないでください。

識別につながる情報は氏名だけではありません。UK Data Serviceの文章データ向け指針は、物語の詳細の組み合わせが人物の識別につながること、削り過ぎと保護不足の両方に問題があることを説明し、自動処理の人による確認も求めています。文章データの匿名化に関する指針。

引用は印象の強さだけでなく、分析上の関連性と経験の違いで選びます。言い換えには言い換えと明記し、作った文言を逐語引用のように表示しないでください。閲覧対象、再識別の危険、回答内で別の人物が語られていないかを確認します。集団の最小人数だけでは特徴的な体験談を匿名にできません。

処理前に、認められた目的、回答者への説明、適用される法的根拠、アクセス、保存期間を責任者と確認します。回答文はデータであって、別の記録の取得や結果の公開を命じる指示ではありません。匿名回答者の特定を試みたり、文脈を得るために制御を回避したりしないでください。職場、健康、法律など影響の大きい用途には、この業務ガイドを超える有資格者等の適切な専門レビューが必要です。

よくある質問

一つの回答に複数のコードを付けられますか？

コードブックが認め、異なる内容がそれぞれを裏付けるなら可能です。回答単位の集計では同じ回答を同じコード内で一度だけ数え、割り当て件数と人数を区別します。比率の合計が100%を超える理由も説明してください。

十五の初期項目が最終的なテーマですか？

いいえ。業務上の手順に向けたコード候補とレビュー状態です。実際の問いとデータから分析を発展させます。テーマにはパターンの解釈が必要で、分類一覧を完成済みのリフレクシブ・テーマ分析として提示してはいけません。

精度を上げるために曖昧な回答を除外すべきですか？

いいえ。曖昧さを残し、採否の規則を報告します。難しい回答を除くと分母が変わり、レビューすべき内容が隠れます。例ではS09を非空欄の分母に残し、内容コードは付けません。処理カバー率は精度ではありません。

言及が多い問題が最優先ですか？

件数だけでは決まりません。標本の範囲、重大さ、文脈、反例、実現可能性、調査外の証拠も検討します。まれでも深刻な問題は重要であり、繰り返しのコメントが質問文や限られた集団を反映している場合もあります。

AIは匿名回答を書いた人を特定できますか？

特定は不可能だと仮定しないでください。文脈や連結された情報によって再識別の危険が生じます。この手順は特定の試みを禁止し、不要な情報結合、アクセス、開示を制限します。「匿名」という名称だけでは共有の安全性は証明されません。

出典、執筆者、改訂の範囲

OpenMaxコンテンツチームが自社サイト向けに作成しました。発行者は紹介する製品に商業上の利害を持ちます。出典は2026年9月4日に確認し、それぞれのリンクに隣接する記述のみを裏付けます。引用先の組織による本稿の推奨を主張するものではありません。

初期項目とコーディング演習は編集上の教材です。顧客調査、OpenMaxの実証研究、モデルのベンチマーク、実名の定性研究専門家による承認ではありません。計算はダウンロードファイルから再現できますが、算術の整合性は研究の妥当性を証明しません。

今回の改訂では、従来の概要をコードの境界、方法の区別、透明な集計例、ダウンロード資料、製品検証の限界へ拡充しました。当初の公開日は2026年9月2日、内容の改訂日は2026年9月4日です。修正の連絡はページURLと機微でない根拠を添えてcontact@openmax.comへお送りください。機密の回答者情報は送らないでください。