LinkedInコメント投稿者の公開情報から職種を調べる方法

コメントとアカウントを分ける

保存した1行は、取得できたトップレベルコメント1件に対応します。1人の人物ではありません。1件のリアクションでもありません。1件の完全なプロフィールでも、スレッド全体でもありません。

各行には、次のフィールドがあります。

• `commentId`
• `commentUrl`
• `postUrl`
• `postUrn`
• `authorType`
• `authorUrl`
• `authorId`
• `authorUrn`
• `authorPublicIdentifier`
• `authorName`
• `authorHeadline`
• `authorLocation`
• `authorCurrentOrganizations`
• `text`
• `observedAt`

`authorUrn`と`postUrn`はURN値です。URNは、公開ソースが提供する、種類を示す情報を含んだ文字列の識別子です。`authorId`も公開ソースの識別子です。これらの識別子は公開情報です。秘密鍵ではありません。

`authorType`で確認済みの値は、`person`、`organization`、`null`の3つです。`null`は、種類が示されていないことを意味します。`null`を個人と解釈しないでください。

`observedAt`は、その行を観測した時刻です。投稿の公開時刻ではありません。両方の時刻がわかる場合は、両方をメモに記録してください。取り違えないでください。

`authorCurrentOrganizations`には、複数の公開項目が入る場合があります。すべての項目を残してください。根拠なく雇用主を1つに決めないでください。フィールドがnullまたは空の場合、所属組織を示す情報は不明です。不明はゼロではありません。失業しているという意味でも、会社に所属していないという意味でもありません。

投稿者の詳細情報が欠けている場合があります。リクエストの結果として、プロフィール見出しや所属組織が空の行が返されることもあります。そうしたセルは不明のままにしてください。コメント本文から補完しないでください。

コメント表は1つだけ使います。職種の分類に、別のデータセットは必要ありません。

小規模な実行を設定する

1. 把握している公開投稿を選びます。収集前に、調査で明らかにしたい問いを書きます。収集時刻を明記します。投稿ごとに収集件数の上限を定めます。宣伝コメント、元の投稿者によるコメント、組織アカウントの行が調査結果に影響する場合は、印を付けます。宣伝コメントとは、主に商品やサービスを宣伝するコメントです。印を付けた行は残してください。削除しないでください。元の投稿者のアカウントを割合の計算から除外する場合は、その旨を明記し、合計も変更します。
2. 投稿者の詳細情報を有効にして、小規模なサンプルを収集します。2026年10月13日に確認した保存済みTaskは、公開プロフィール情報付きのLinkedInコメント投稿者です。保存されている入力は次のとおりです。

{"startUrls": ["https://www.linkedin.com/posts/timferriss_how-to-become-dramatically-more-productive-activity-7386884213343428608-wrF3"], "maxComments": 100, "collectAllAvailable": false, "includeAuthorDetails": true}

サンプルの投稿を、調査対象の公開投稿に置き換えます。最初の実行では、`maxComments`を3に設定します。`collectAllAvailable`はfalseのままにします。falseにすると、件数の上限が有効なままになります。`includeAuthorDetails`はtrueのままにします。

投稿者の詳細情報は、コメント行とは別のリクエストで取得します。追加の詳細情報を正常に取得すると、別途課金イベントが発生する場合があります。課金イベントとは、課金の記録です。すべてのリクエストに課金されるわけではありません。詳細フィールドが空で返る場合もあります。この記事では価格を示していません。

1. コメント行と実行のOUTPUTを保存します。職種を分類する前に、投稿ごとのOUTPUTを確認します。

実行全体のOUTPUTには、`savedRows`、`authorProfileRequests`、`authorDetailEvents`、`rowsWithAuthorDetails`が含まれます。これらを確認し、行数と詳細情報のリクエスト数がそれぞれいくつ記録されたかを把握します。詳細情報が欠けている場合、`rowsWithAuthorDetails`はコメント数より少なくなることがあります。これらの件数を職種集計の合計に使わないでください。請求額として解釈しないでください。

投稿ごとに`inputResults`の項目があります。その中で、次のフィールドを確認します。

• `status`
• `statusReason`
• `pageCommentCount`
• `publicRowsOnPage`
• `savedRows`
• `isPublicPageComplete`
• `isComplete`
• `stopReason`

その投稿の`inputResults`内にある`stopReason`を使います。OUTPUTの最上位にある`stopReason`は、その投稿の上限到達状況を示すものではありません。

`isPublicPageComplete`がtrueの場合、公開されているページの抽出が完了したことを意味します。議論全体を保存したという意味ではありません。`isComplete`がfalseの場合、保存した収集結果は不完全です。件数上限、公開プレビューの制限、ソース側の制限、または課金上限によって、この結果になることがあります。入力ごとに、状態、理由、stopReasonを確認してください。実行状態が成功でも、表が完全になるわけではありません。`pageCommentCount`と`publicRowsOnPage`はページ上の件数です。観測した個人アカウントの数ではありません。

2026年10月13日の範囲を限定した検証では、1件の投稿から3件のコメントを保存しました。投稿者の詳細情報を取得するリクエストは3回でした。公開ページに示された件数が4のところ、上限に達して実行が停止しました。その投稿では、`isPublicPageComplete`がtrue、`isComplete`がfalse、`stopReason`が`max_comments_reached`でした。保存した3行は、議論全体ではありません。公開された投稿者情報が返される場合があることだけを示しています。職種レポートではありません。以下の具体例に使わないでください。

2つの表を作る

コメント表を保持します。各行に、その行の`commentId`を付けます。

`commentId`がない場合は、その行をソースから得た独立した観測記録として残します。`missing-comment-1`など、自分で作ったラベルを付けます。コメントIDが両方とも空だからといって、2行を統合しないでください。コメント本文が一致するという理由で2行を統合しないでください。同じ本文でも、同じコメントとは限りません。

個人アカウント表は、種類を確認してから作ります。

1. `authorType`を確認します。
2. `authorType`が`person`の場合だけ、IDで行をまとめます。
3. 安全に識別できるキーとして、`authorUrn`または`authorId`を優先します。
4. これらのIDがない場合は、確認済みの公開プロフィールURLを暫定ラベルとして使えます。URLによるラベルは、安定したIDよりも識別の確実性が低いことを明記します。URLによるラベルがある場合は、識別不能ではありません。
5. 識別不能とは、安全に識別できるキーがない状態です。`authorUrn`も、`authorId`も、確認済みプロフィールURLもない場合を指します。確認済みURLがあるのに、安定したIDがないという理由だけで識別不能にしないでください。
6. `authorName`で行を統合しないでください。
7. 空のID同士を統合しないでください。

`organization`のアカウントは、別のグループに分けます。そのIDは個人のIDと分けて管理します。個人アカウントの合計には含めません。個人アカウントの合計の横に、組織アカウントの数を記載します。

`authorType`が`null`の場合、その行を個人アカウントとして扱わないでください。その行に個人を安全に識別できるキーもない場合は、識別不能のままにします。近くにある名前に割り当てないでください。

職種不明と識別不能は異なります。職種不明とは、個人アカウントを識別できたものの、プロフィール見出しに職種が明記されていない状態です。そのアカウントは、個人アカウントの合計に含めます。識別不能の行は含めません。

確認できるプロフィール見出しを分類する

集計前にコードブックを作ります。コードブックとは、分類項目と、各分類に必要なプロフィール見出しの根拠をまとめた短い一覧です。

次の基準を使います。

• `operations`：プロフィール見出しに、オペレーション業務が明記されている。
• `technical`：プロフィール見出しに、ソフトウェアまたはエンジニアリングの業務が明記されている。
• `marketing`：プロフィール見出しに、マーケティング業務が明記されている。
• `mixed`：プロフィール見出しに、上記の職務分野が複数明記されており、分類基準では1つに絞れない。
• `unknown`：プロフィール見出しがない、または職務分野が明記されていない。スローガンは不明として扱う。

分類項目の横に、プロフィール見出しの原文をそのまま保存します。明記された職務分野の全体を使って判断します。スローガンから仕事を推測しないでください。コメントの語調から職種を推測しないでください。コメント本文は、職種の根拠ではありません。

各個人アカウントに、主分類を1つ付けます。これにより、割合の集計では各アカウントを1回だけ数えられます。追加のタグを別のフィールドに残してもかまいません。そのタグを追加のアカウントとして数えないでください。

同じアカウントのプロフィール見出しに食い違いがある場合は、両方の時点の記録を日付付きで残します。各時点の記録について、根拠となる原文をそのまま保存します。グラフを見やすくするために都合のよい肩書きを選ばないでください。レポートでは、どの観測記録を採用するかの基準を1つ定め、明示して使います。その基準を適用できない場合、主分類は`unknown`のままにします。`conflict pending review`は、読み手による別途の確認状況を示すためだけに使います。異なる時点の職種をまとめて`mixed`に分類しないでください。`mixed`に分類するのは、採用したプロフィール見出しに複数の職種が明記され、コードブックでは1つに絞れない場合だけです。採用したプロフィール見出しから1つの明確な職務分野が読み取れない場合は、`unknown`に分類します。

職種分類は、明記された職務分野に自分で付けたラベルです。確認済みの資格や経歴ではありません。

1回ずつ数えてから割る

同じアカウントによる複数のコメントは、活動量の表で数えます。職種表では、観測した各個人アカウントを1回ずつ数えます。

分母は、割るときの基準となる合計です。分子は、その合計で割る対象の件数です。割合は、分子を明示した分母で割った値です。

職種レポートの分母は、観測した個人アカウントの数です。組織の行と識別不能の行は含めません。職種不明のアカウントは含めます。

職種を把握できた割合は、別の集計として示します。対象者が新たに増えるわけではありません。分子は、主分類が`unknown`ではない個人アカウントの数です。分母は、観測したすべての個人アカウントの数です。`mixed`は`unknown`ではありません。

職種が判明したグループの中だけで、割合を示してもかまいません。その場合、分母は小さくなります。表にその分母を記載します。横に職種不明の数も残します。その割合を、大きい分母で計算した割合と比較しないでください。アカウントが変わったのではなく、合計が変わっています。

別の読み手に、同じコードブックでいくつかのプロフィール見出しを分類してもらいます。分類が異なった行を確認します。これは分類の一貫性を確かめるためのものです。その仕事に実際に就いていることの証明にはなりません。

架空のデータを使った計算例

この節の投稿、ラベル、名前、プロフィール見出し、件数は架空のものです。2026年10月13日の検証結果ではありません。実在する人物を表すものでもありません。

架空の投稿から、8行のコメントが得られたとします。架空の`commentId`は、`c1`から`c8`です。この8行に、`commentId`が空の行はありません。個人の行にある個人IDは確認済みです。`c8`には、安全に識別できるキーがありません。

個人アカウント表：

`org1`の`authorType`は`organization`で、コメントは1件です。個人アカウント表には含めません。`c8`の`authorType`は`null`で、安全に識別できるキーがありません。識別不能のコメント1件として扱います。`c8`を`p4`に割り当てないでください。

8件のコメントには、観測した個人アカウント4件、組織の投稿者1件、投稿者を識別できない行1件が含まれています。正確に6人いたとは言わないでください。識別不能の行は、すでに数えた個人アカウントのものかもしれません。`org1`は組織です。

職種別の割合は、観測した4件の個人アカウントを分母にします。

オペレーション職の割合は、1を4で割って求めます。結果は25%です。同じ計算で、技術職、マーケティング職、職種不明もそれぞれ25%になります。この4つの割合は同じ分母を使っているため、合計は100%です。

職種を把握できた割合は、分子を3、分母を4として求めます。3を4で割ると75%です。職種不明のアカウントも、4件中の1件として見える形で残します。

別の集計では、職種が判明した3件のアカウントだけを使います。各職種グループは、1を3で割るため約33.3%です。この集計の横にも、職種不明の数を残します。職種不明のアカウントは1件で、この分母には含まれません。

33.3%と25%を比較しないでください。分母が異なります。対象者が変化したことを示す数値ではありません。

コメント活動量の合計は、別の集計です。合計は8件になります。

`p1`と`p2`は、それぞれ2件のコメントを書いています。職種レポートに8行すべてのコメントを使うと、この2つのアカウントをそれぞれ2回数えることになります。件数の把握には、活動量の表を使います。構成の把握には、4件の個人アカウントを使います。

架空の収集範囲に関する注記：上限は8です。観測したソースページ上の件数は12です。`inputResults`では、`stopReason`が`max_comments_reached`、`isComplete`がfalseです。この架空の注記では、`status`や`statusReason`の値を設定していません。

判断：4件のアカウントからなる職種表を、観測したサンプルとして保持します。調査でより広い範囲が必要な場合にだけ、追加で収集します。このサンプルを、参加者12人全員と呼ばないでください。12という数値を、個人アカウント12件と解釈しないでください。

架空の調査結果：上限を設けたこのサンプルでは、観測した4件の個人アカウントに対し、各主分類の割合は25%です。職種を把握できた割合は75%です。この結果が示すのは、そのサンプルの範囲だけです。すべての顧客を説明するものではありません。誰に購買権限があるかも示しません。

引き渡すもの

次のものを引き渡します。

• 各アカウントに主分類を1つ付けた個人アカウント表。
• コードブックと、根拠に使ったプロフィール見出しの原文。
• 個人アカウントの分母には含めない、組織アカウントの数。
• 識別不能の件数と、`commentId`がない各行に読み手が作成したラベル。
• `inputResults`に基づく、投稿ごとの収集範囲に関する注記。
• 分母と上限を明記した、範囲を限定した調査結果1つ。

収集時刻を明記します。投稿の公開時刻で置き換えないでください。プロフィール見出しや所属組織の一覧が空だった場合は、不明と示します。不明をゼロに置き換えないでください。

`isComplete`がfalseの場合、その表が議論全体を含まないことを明記します。2つの時点のプロフィール見出しに食い違いがある場合は、両方を示します。分類に使わなかった方を隠さないでください。