質的研究のためのコードブック開発

定性コードブックは、研究内のすべてのコードを一覧にしたもので、各項目には、コードの名前、定義、コードを適用する場合としない場合の基準、そしてデータからの例が含まれます。チームは通常、理論や研究課題から取った演繹的コードから始め、読みながら見つけた帰納的コードを加え、いくつかの記録でコードブックを試行し、各改訂に番号を付けます。各コーディングにバージョン番号を記録しておけば、読み手はコードブックのどのバージョンがどの記録をコーディングしたかを確認できます。

質的研究におけるコーディングは、インタビューの記録、フォーカスグループ、フィールドノート、自由記述式のアンケート回答の抜粋に、コードと呼ばれる短いラベルを付けます。演繹的コードは、コーディングの開始前に理論、先行研究、またはインタビューガイドから生まれ、帰納的コードは、コーディング中にデータから生まれます。この二つの用語は、演繹と帰納的推論の方向を借りています。コーダー間信頼性は、二人のコーダーが同じ抜粋に同じコードを適用する頻度を測ります。疾病対策センター（CDC）でのチームコーディングについて書いたMacQueen ら（1998）は、構造化されたコードブックを、テキストの動的な分析のための安定した枠組みと説明しています。MacQueen らが述べるコードブックの特徴は、コーダー間の一致度を高めるために選ばれました。

以下のセクションは、人のチームが質的分析で適用するコードブックを扱います。効果的なアノテーションガイドラインの書き方は、モデルを訓練または評価するアノテーションタスクのためのラベルのルールを扱い、LLM が従えるコードブックの書き方は、言語モデルが適用するコードブックを扱います。定性コーディングのための共有コードブックは、Potato のコードブック機能をオプションごとに説明します。

演繹的コード、帰納的コード、ハイブリッドコード

演繹的コードブックは、コーディングの開始前に書かれ、コーディングによって、コードブックのカテゴリーが参加者の発言をどれだけよく記述しているかがわかります。帰納的コードブックは、読むうちに育ちます。どのコードにも当てはまらない一節は候補のコードとなり、その考えが複数の参加者にわたって繰り返されると、その候補に項目が与えられます。テーマ分析とグラウンデッド・セオリーは、どちらも帰納的コーディングを利用します。

多くのチームプロジェクトは、二つの方向を組み合わせます。Fereday と Muir-Cochrane（2006）は、看護におけるパフォーマンスフィードバックの研究で、データ駆動のコードと理論駆動のコードを統合したハイブリッドのプロセスを説明しています。DeCuir-Gunby、Marshall、McCulloch（2011）は、インタビューデータのための理論駆動のコードとデータ駆動のコードを開発し、ほかのコーダーにコードブックの適用方法を訓練する手順を示しています。Roberts、Dowell、Nie（2019）は、研究課題、文献、同じプロジェクトのアンケート、インタビューの最初の概観から予備的なコードブックを作り、コーディング中に予期しないテーマを取り入れました。ハイブリッドのコードブックでは、各項目にコードの出自を記録します。そうすれば読み手は、どのコードを研究がデータに持ち込み、どのコードをデータが生み出したかがわかります。

コード項目の構成要素

コード項目は、そのコードが考案されたときにその場にいなかったコーダーに、コードの適用方法を伝えます。Roberts、Dowell、Nie（2019）は、各コードを、ラベル、定義、記述、限定または除外、生データからの例で書きました。以下の表は、その形式を、包含の行、典型的でない例、反例、そしてコードの出自で拡張したものです。例は、遠隔授業についての教師の経験を調べる研究の演繹的コードです。

除外基準は、二つのコードが近接している箇所で最も重要で、隣接するコードの名前を挙げた除外は、二つのうちどちらのコードを選ぶべきかをコーダーに伝えます。例は、識別情報を取り除いた、自分の記録から取ってください。作り上げた例には、実際の発話にある脱線や、言いかけの文が欠けています。

親コードと子コード

長いコードブックは、ツリーにすると適用しやすくなります。親コードは Workload のような広いカテゴリーを指し、子コードは、家族との時間外の連絡のように、研究が別々に数えたい変種を指します。各子コードには、別の項目が必要です。親の項目は、コーダーが親を直接適用するのか、子を通じてのみ適用するのかを述べます。両方を適用するコーダーがいると、親のカウントが二重になるためです。ハイブリッドのコードブックでは、帰納的コードが演繹的な親の子として追加されることがよくあります。遠隔授業の研究では、パイロットで仕事が家庭生活に染み出すことについての一節が見つかり、チームは Workload の子として Home and work boundary を追加しました。

いくつかの記録でのコードブックの試行

試行では、本格的なコーディングのラウンドの前に、コードブックの草案をいくつかの記録に適用します。互いに異なる試行用の記録（たとえば、各サイトまたはグループから一人の参加者）を選び、二人のコーダーにすべての抜粋を独立してコーディングしてもらいます。二つのコーディングを抜粋ごとに比較し、各不一致について、項目が不明確だったのか、抜粋が曖昧だったのかを判断します。不明確な項目には、より鋭い定義、新しい除外、または新しい例が与えられます。

改訂した後は、試行用の記録をもう一度コーディングするのではなく、新しい記録をコーディングしてください。試行用の記録から書かれた項目は、その記録によく合っており、同じ素材を再コーディングしても、新しいインタビューでコードブックがどう機能するかはほとんどわかりません。試行で計算した係数は、草案のコードブックを表し、論文で報告する信頼性は、後のラウンドから得られます。DeCuir-Gunby らは、コーダーを訓練しながら信頼性を確立することを論じています。チームが最終バージョンに合意したら、コードブックは、変更なしにはコーディングを続けられない箇所でのみ変更されます。Roberts らは、最終バージョンの検証中に不一致を記録し、同じ規則に従いました。

チームでのコードの改訂

チームの改訂には、次のものがあります。

• 鋭くする。 コーダーが項目を異なる形で読む場合、定義を書き直すか、除外を追加します。
• 追加する。 データが生み出し続ける帰納的コードの項目を書きます。
• 統合する。 コーダーが区別できない二つのコードを一つにまとめます。
• 分割する。 コーダーが二つの異なる考えのために使ったコードを分けます。
• 廃止する。 誰も適用しなかったコードを削除するか、そのコードがないこと自体が知見である場合は、注記付きでコードを残します。

チームの一人にコードブックを編集してもらい、ほかのチームメンバーは、記録の途中で項目を編集するのではなく、定例のミーティングで変更を提案します。各判断には、変更、理由、合意した人々を記した日付付きの行を変更ログに加えます。統合や分割は、以前のコーディングの意味を変えるため、ログには変更が及んだ抜粋を記します。

コードブックのバージョン管理

コードブックの各バージョンに、パイロット草案には 1.0、本格的なラウンドが使うコードブックには 2.0 のように、番号と日付を付け、すべてのバージョンを保管します。各記録のコーディングの隣にバージョンを記録します。そうすれば、方法のセクションで、どのコードブックがどの記録をコーディングしたかを述べられます。変更がコードの意味を変える場合、以前のバージョンでコーディングされた記録は、そのコードについて再コーディングするか、以前の定義でコーディングされたものとして報告します。表現を直したり例を追加したりする変更には、再コーディングは必要ありません。最終バージョンと変更ログは、付録または補足ファイルとして公開してください。

Potato でのコードブック

Potato 2.13.1 は、コードブックをプロジェクトのデータベースに保存し、各変更を記録します。以下の設定は、遠隔授業の研究のパイロットラウンドを設定します。両方のコーダーがすべての抜粋をコーディングし、コーダーは読みながらコードを追加でき、ユーザー lead が裁定者として定義を編集し、コードを統合します。

annotation_task_name: Remote teaching interviews
task_dir: .
output_annotation_dir: annotation_output/
data_files:
  - data/excerpts.jsonl
item_properties:
  id_key: id
  text_key: text
user_config:
  allow_all_users: true
  users: []
 
# Pilot round: both coders code every excerpt of the pilot transcripts
num_annotators_per_item: 2
 
# Coders may add a code while they read; only the lead edits definitions or merges codes
codebook_mode: extensible
 
adjudication:
  enabled: true
  adjudicator_users: [lead]
 
annotation_schemes:
  - annotation_type: multiselect
    name: codes
    description: Which codes apply to this excerpt?
    codebook: true
    labels:
      - name: Workload
        description: The teacher describes the time or effort that remote teaching took.
      - name: Student engagement
        description: The teacher describes whether students took part, paid attention, or completed work.
      - name: Technology access
        description: The teacher describes devices, internet connections, or software that students or the teacher had or lacked.
      - name: School support
        description: The teacher describes help, guidance, or resources from the school or district, or the lack of them.

codebook: true は、スキームが YAML ではなくコードブックからコードを読み込むようにします。最初のサーバー起動時に、Potato は labels からコードブックを初期化し、各ラベルの description がコードの短い定義になります。それ以降はデータベースがコードブックを保持し、labels を編集しても何も変わりません。2.13.1 のブラウザーインターフェースでは、コーダーはトップレベルのコードを追加し、項目の本文を編集できます。コードの名前変更、移動、削除は、コードブック API を通じて行います。本格的なラウンドでは、codebook_mode: fixed を設定してサーバーを再起動してください。fixed モードでは、誰もコードを追加、名前変更、移動、削除できず、定義の編集は、管理者または裁定者が承認または却下する提案としてキューに入ります。

コードブックのページでの項目の記述

/codebook ページでは、各コードの項目は、型付きブロックのリストです。Markdown で書いた項目を貼り付けてコードを選ぶと、Potato は各見出しを対応するブロックの下に振り分けます。

### Short definition
 
The teacher describes the time or effort that remote teaching took.
 
### Use when
 
Hours, preparation, grading, or messages that took longer than in a classroom.
 
### Avoid when
 
Tiredness or stress with no task or time named.
 
### Examples
 
"The lesson plans took twice as long because everything had to work on a phone."
 
### Counter-examples
 
"I was exhausted all the time."

Use when は包含基準を、Avoid when は除外基準を保持します。### Definition ブロックは完全な定義を保持し、### Rationale ブロックはコードの出自を保持できます。Potato には、典型的でない例のための別のブロックはありません。典型的でない例は、注記付きで Examples の下に置いてください。コーダーは、抜粋の隣のコードブックトレイで、各コードの短い定義を見ます。

入れ子のコード

トレイは入れ子のコードをツリーとして表示し、2.13.1 のトレイには、コードを入れ子にする操作がありません。2.13.1 の codebook と qdpx のエクスポートは、コードブックに基づくスキームのコードをトップレベルに一覧し、codebook.csv の parent 列と color 列は空のままになります。Potato から出てもそのまま保たなければならないツリーには、内容分析で説明されているように、CSV ファイルから読み込む hierarchical_multiselect スキームが適しています。その場合、コーダーはコーディング中にコードを編集できません。

ラウンドの間のコードの追加

最初の起動の後で labels に追加された演繹的コードは、コードブックの CLI を通じてコードブックに届きます。

potato codebook config.yaml

このコマンドは、コードブックにない YAML のラベルごとにコードを作成し、名前だけをコピーします。新しいコードの定義は /codebook に書いてください。CLI は、サーバーがすでに初期化したコードブックに対してのみ実行してください。空のコードブックでは、CLI は YAML の説明なしでコードを作成し、サーバーはその後、初期化をスキップします。2.13.1 の potato codebook のエントリーポイントは --dry-run フラグを無視して、コードを書き込みます。書き込まずにプレビューするには、python -m potato.codebook_cli config.yaml --dry-run を実行してください。

改訂番号と変更履歴

コードの追加、名前変更、移動、統合、削除は、コードブックの改訂番号を上げ、Potato は保存された各アノテーションに、その時点で有効だった改訂を記録します。トレイの Review リストは、各コーダーに、後の改訂より前にそのコーダーが保存した抜粋を示します。項目の本文を編集しても、改訂番号は変わりません。/admin/iaa の一致度ページは、一致度のドリフトと再較正ラウンドで説明されているとおり、時間にわたる一致度の表の下にコードブックの改訂を一覧します。

2.13.1 では、トレイから行った統合や分割はコードブックを変更しますが、すでに保存されたコーディングには手を触れません。統合されたコードでコーディングされた抜粋は、アノテーションファイルに古いコードの名前を残します。チームはその後、それらの抜粋を再コーディングするか、分析中に古い名前を新しい名前に対応づけ、その判断を変更ログに記録します。

改訂のスタンプはプロジェクトのデータベースに残り、アノテーションのエクスポートには含まれません。方法のセクションのためにコードブックのバージョンを固定するには、各ラウンドの終わりにコードブックをエクスポートし、スナップショットを取ってください。

python -m potato.export -c config.yaml -f codebook -o ./export/
potato snapshot create config.yaml --note "Codebook 2.0, after the pilot" --tag codebook-2.0

このエクスポートは、各コードの短い定義とコーダーがそのコードを適用した回数を含む codebook.csv を書き出します。包含基準と除外基準、および例は、/codebook とプロジェクトのデータベースに残ります。スナップショットは、設定、データ、アノテーション、プロジェクトのデータベースを、タグ codebook-2.0 の下にまとめます。スナップショットのコンテンツハッシュは、設定、データ、アノテーションをカバーしますが、データベースはカバーしません。そのため、コードブックだけを変更したラウンドではハッシュが変わらず、potato snapshot create がそのラウンドを保存するのは --force を付けた場合のみです。スナップショットのコマンドは、プロジェクト・スナップショットで扱います。

よくある質問

定性コードブックには何を含めるべきですか？

定性コードブックには、すべてのコードの項目が含まれ、各項目には、名前、短い定義と完全な定義、包含基準と除外基準、データからの典型的な例、典型的でない例、反例があります。多くのチームは、各コードの出自と親も記録します。コードブック全体には、バージョン番号、日付、変更ログがあります。

コードブックには、演繹的コードと帰納的コードのどちらを使うべきですか？

多くのチームのコードブックは両方を使い、理論、先行研究、またはインタビューガイドから取った演繹的コードから始めて、パイロットの記録が生み出す帰納的コードを加えます。純粋に演繹的なコードブックは、名前付きのカテゴリーを検証する研究に向き、純粋に帰納的なコードブックは、グラウンデッド・セオリーのような探索的な研究に向きます。

コードブックの変更の監査証跡はどのように残しますか？

各コードブックのバージョンに番号を付け、すべての変更を日付、理由、合意した人々とともにログに記録し、どのバージョンがどの記録をコーディングしたかを記録することで、監査証跡を残します。Potato では、保存された各アノテーションが、その時点で有効だったコードブックの改訂を記録し、各ラウンドの終わりの potato snapshot create config.yaml --tag codebook-2.0 が、コードブックをアノテーションとともに固定します。

関連資料

• 定性コーディングのための共有コードブック。Potato のすべてのコードブックのオプションについて
• QDA モード。オープンなコードブック、メモ、ケースを使って、一人のアナリストがコーパス全体をコーディングする場合について
• 質的研究におけるコーダー間信頼性
• 定性コーディングのためのインタビュー記録の準備
• 定性コーディングで LLM を使い、その使い方を報告する方法
• 二人のコーダーでインタビュー記録をコーディングしアルファを報告する。二人のコーダーが適用するコードブックを、Krippendorff のアルファと QDPX ファイルまで扱います
• 効果的なアノテーションガイドラインの書き方
• LLM が従えるコードブックの書き方
• 定性データ分析ソフトウェアの比較
• Potato での質的研究

参考文献

1. DeCuir-Gunby, J. T., Marshall, P. L., & McCulloch, A. W. (2011). Developing and Using a Codebook for the Analysis of Interview Data: An Example from a Professional Development Research Project. Field Methods, 23(2), 136-155. https://doi.org/10.1177/1525822X10388468
2. Fereday, J., & Muir-Cochrane, E. (2006). Demonstrating Rigor Using Thematic Analysis: A Hybrid Approach of Inductive and Deductive Coding and Theme Development. International Journal of Qualitative Methods, 5(1), 80-92. https://doi.org/10.1177/160940690600500107
3. MacQueen, K. M., McLellan, E., Kay, K., & Milstein, B. (1998). Codebook Development for Team-Based Qualitative Analysis. CAM Journal (Cultural Anthropology Methods), 10(2), 31-36. https://doi.org/10.1177/1525822X980100020301
4. Roberts, K., Dowell, A., & Nie, J.-B. (2019). Attempting rigour and replicability in thematic analysis of qualitative research data; a case study of codebook development. BMC Medical Research Methodology, 19, 66. https://doi.org/10.1186/s12874-019-0707-y
5. Jurgens, D., Chen, M., & Iyer, L. (2026). Potato 2.0: A Comprehensive Annotation Platform with AI-in-the-Loop Support. Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations), 374-386. https://aclanthology.org/2026.acl-demo.37/