# ChronometricaとApify Instagram Profile Scraper：n8nのプロフィールデータセットにはどちらが適しているか

入力内容の再出力、安定した識別情報、件数の精度、結果ステータスを備えた、公開プロフィールの簡潔なスナップショットがn8nのワークフローに必要なら、Chronometricaを選びます。Aboutセクションの追加機能や関連プロフィールのデータが必要なら、Apify Instagram Profile Scraperを選びます。この判断は、文書に記載されたフィールドに基づきます。実測した性能差に基づくものではありません。[ChronometricaのActor](https://apify.com/chronometrica/instagram-channel-scraper)、[ApifyのActor](https://apify.com/apify/instagram-profile-scraper)。

Chronometricaは、この記事で比較する自社のActorを公開しています。Actorは、データを収集するホスティング型のプログラムです。Taskは、Actor用に保存した入力設定です。

読者が行いたいのは、Instagramの公開プロフィールデータをn8nに取り込むことです。この要望は、[公開のn8nディスカッション](https://www.reddit.com/r/n8nforbeginners/comments/1vfzrh4/ways_how_to_pull_public_instagram_profile_data/)に見られます。このディスカッションは、読者の疑問を示すものです。特定の提供元を推奨するものでも、性能テストでもありません。

両方のActorは、複数の公開プロフィールの一括処理に対応し、n8nから呼び出せます。連携機能に、一方だけが持つ優位性はありません。この比較では、2026年10月20日に確認した公開製品ドキュメントを使用しています。この比較のために、新たな収集実行や、条件をそろえた性能テストは行っていません。[Chronometricaのドキュメント](https://apify.com/chronometrica/instagram-channel-scraper)、[Apifyのドキュメント](https://apify.com/apify/instagram-profile-scraper)。

## Actorを選ぶ前に出力仕様を決める

出力仕様は、結果の各行に含まれるフィールドと、その読み方を定めます。n8nのマッピングを作る前に、この仕様を選びます。マッピングとは、返されたフィールドを保存先テーブルの列に対応付けることです。

まず、そのデータを使う次の処理を考えます。レポートには、プロフィールIDとフォロワー数が必要かもしれません。確認用テーブルなら、件数が欠けていても、識別情報を含むレコードを受け入れられるかもしれません。同じプロフィールを情報源にしていても、これらの処理には異なる受け入れルールが必要です。

6つの判断項目で、要件に合うかを比較します。

| 判断項目 | Chronometrica | Apify Instagram Profile Scraper |
| --- | --- | --- |
| 必要な入力 | `startUrls`：公開プロフィールのURLまたはハンドル名を1～1,000件 | 複数の公開プロフィールを一括入力 |
| 必要な出力単位 | 重複を除いた各入力につき、結果の状態を含む結果行を1行 | より広範なプロフィールデータ。必要な行のルールは要確認 |
| 欠損データの扱い | 不明な値は不明のまま保持し、`status`と`statusReason`で処理を振り分ける | 不明な値は不明のまま保持し、必須フィールドを確認する |
| 必要なフィールド | 入力内容の再出力、`channelUrl`、`channelId`、`countPrecision`、`observedAt`、結果ステータス | プロフィールのメタデータ、最近のコンテンツ、関連アカウント、有料のAboutセクション |
| 主な制限 | 結果の状態が得られても、プロフィールデータがすべてそろう保証はない | 必須フィールドと追加機能の範囲を確認する必要がある |
| 選択を変える条件 | 絞り込まれた出力仕様でテーブルの要件を満たせる場合に使う | より豊富なフィールドが必要な場合に使う |

この表の製品範囲は、確認済みの公開仕様に基づきます。欠損データの扱いは、利用者がワークフローに適用するルールです。文書に記載がないことは、その機能が存在しない証拠にはなりません。[Chronometricaの仕様](https://apify.com/chronometrica/instagram-channel-scraper)、[Apifyの仕様](https://apify.com/apify/instagram-profile-scraper)。

必須フィールドとは、欠けると次の処理が機能しなくなるフィールドです。この定義を明確にします。任意フィールドは補足情報を加えられます。ただし、今回の選択を決める必須要件の代わりにはなりません。

## Chronometricaの確認済みの結果行に含まれるもの

Chronometricaは、入力内容の再出力、`channelUrl`、`channelId`、`countPrecision`、`observedAt`、`status`、`statusReason`を文書に記載しています。入力スキーマは、公開プロフィールの入力を最大1,000件受け付けます。重複する入力は1回だけ確認されます。重複を除いた各入力が結果行を1行生成し、利用量に加算されます。[Actorの公開ドキュメント](https://apify.com/chronometrica/instagram-channel-scraper)。

これらには、それぞれ異なる用途があります。入力内容の再出力は、送信した情報源を保持し、結果をそのリクエストと結び付けられるようにします。`channelUrl`は正規プロフィールURLを保持します。これは、そのプロフィールの標準URLとして返されるものです。`channelId`は、レコードの照合に使うプロフィールの識別情報を保持します。

`countPrecision`は、件数の値の精度情報を示します。`observedAt`は、観測した日時を記録します。`status`は結果の状態を示し、`statusReason`はその理由を示します。これらは文書に記載されたフィールドです。リクエストしたすべてのプロフィールから、必要な値をすべて取得できるという約束ではありません。[フィールドのドキュメント](https://apify.com/chronometrica/instagram-channel-scraper)。

保存先では、これらのフィールドをまとめて保持します。件数には、その精度と観測日時が必要です。結果の状態には、確認の手順に必要な情報が必要です。識別情報は、送信した情報源と結び付ける必要があります。

送信したURLと正規URLを、同じフィールドとして扱わないでください。前者はリクエストを記録します。後者は結果で特定されたプロフィールURLを記録します。文字列が一致していても、別々に保存します。

この区別は、後からの確認も容易にします。返された識別情報を変えずに、何をリクエストしたかを確認できます。そのうえで、返されたレコードに識別情報のルールを適用できます。

## 最初に保存先テーブルを定義する

どちらのActorを設定する場合も、先にn8nが書き込む列を一覧にします。これは、レポートや確認待ちキューなど、次の処理で使うテーブルです。

小規模なプロフィールデータセットなら、送信した情報源、プロフィールID、正規URL、必須の件数、件数の精度、観測日時、結果の状態、結果の理由などを列にできます。これらは、テーブルの列の提案です。Actorに追加されたフィールド名ではありません。

各列を必須または任意に分類します。次に、明確な受け入れルールを1つ書きます。たとえば、レポートには使用可能なプロフィールIDとフォロワー数が必要かもしれません。別の識別処理なら、その件数がなくてもレコードを受け入れられるかもしれません。

必須の値が欠けた場合の処理を定めます。その行を確認に回す、次の処理を保留する、または別の明示したルールを使います。気付かないまま、保存先の既定動作にルールを決めさせないでください。

空白セル、null値、0は、後の計算で異なる結果を生むことがあります。多くのデータシステムでは、null値はデータの欠損を表します。0は数値です。n8nが保存先に書き込む際に、不明な値を不明のまま保持できる形式を選びます。

最後に、各必須列を、文書に記載された出力と照合します。必須フィールドが絞り込まれた出力仕様の範囲外なら、残りのフローを作る前にActorの選択を見直します。これにより、マッピングは機能するのに、次の処理に必要なデータを渡せない状況を防げます。

## 識別情報、件数、結果の状態を別々にマッピングする

マッピングでは3つの確認を行います。それぞれ異なる点を確かめます。

1. 結果を入力に結び付けます。送信した情報源の一覧を保持します。入力内容の再出力を`channelUrl`とは別にマッピングします。テーブルのルールを満たす場合は、識別情報の照合に`channelId`を使います。
2. 件数の関連情報を保持します。必須の件数を、`countPrecision`と`observedAt`とともに保存します。返された精度情報は、そのまま保持します。
3. 結果の状態と必須フィールドで処理を振り分けます。文書に記載された`status`の値を使い、`statusReason`を保持します。テーブルの要件も満たした場合に限り、その行を受け入れます。

行の位置だけで結果を入力に結合しないでください。Chronometricaは、重複する入力を、重複を除いた入力ごとに1回だけ確認します。そのため、同じ入力を繰り返しても、各入力項目に対して個別の結果行が返される必要はありません。元の一覧を保持し、各項目を重複のない結果に結び付けられるようにします。[入力ルール](https://apify.com/chronometrica/instagram-channel-scraper)。

文書に記載された精度が裏付けない限り、件数を正確な値と表示しないでください。観測日時も一緒に保持し、後から読む人が、その値をいつ観測したか分かるようにします。[出力フィールド](https://apify.com/chronometrica/instagram-channel-scraper)。

分岐は、明示したルールに従い、行をワークフロー内の異なる処理経路に送ります。1つの分岐では、テーブルの要件を満たす行を受け入れられます。もう1つでは、未解決の行を確認に回せます。これらのルールを設定する際は、実際に文書に記載されたステータス値を使います。独自のステータス名を作らないでください。

ステータスだけでなく、フィールドがそろっているかも確認します。結果行は、何が起きたかを説明できても、レポートに必要な値がすべて含まれているとは限りません。フォロワー数が欠けている場合は、欠損のまま保持しなければなりません。取得できない値や検索失敗の代わりに0を使うことはできません。

## 架空のn8n選定例

これは架空の例です。テスト、購入者の発言、実際のデータセット、実測したコスト結果ではありません。

あるチームが、公開クリエイター情報のテーブルをn8nで作るとします。受け入れるすべてのレコードには、プロフィールID、正規URL、フォロワー数、観測日時、結果の状態が必要です。チームは、送信した情報源と件数の精度も保存します。

次の処理には、追加のアカウント情報は必要ありません。必要なのは、確認担当者が点検できる、簡潔なプロフィールのスナップショットです。この要件には、Chronometricaの文書に記載された仕様が適しています。[Actorの仕様](https://apify.com/chronometrica/instagram-channel-scraper)。

この架空のフローは、対象の公開プロフィールを3件送信します。返された各行について、識別情報、必須の件数、結果の状態を確認します。すべての要件を満たす行は、クリエイターテーブルに入れます。必須の件数が欠けた行は、確認に回します。その件数は不明のまま保持します。識別情報が未解決の場合も、確認に回します。

チームは出力単位を確認します。重複を除いた入力1件から、確認結果を示す状態が1つ生成されます。その状態は、プロフィールデータがすべてそろうことを保証しません。行の受信は、受け入れ確認の始まりです。確認の完了ではありません。

今度は、次の処理に、比較対象のAboutセクションや関連プロフィールのデータが必要になったとします。チームはマッピングを拡張する前に、より豊富な出力仕様を検討します。必須フィールドによって、選択が変わります。[Apifyのプロフィールデータの範囲](https://apify.com/apify/instagram-profile-scraper)。

この例は、フィールドで選ぶ方法と、不完全な行を扱う方法を示します。速度、稼働率、正確性、節約効果についての結果を示すものではありません。

## 入力を準備し、対象プロフィールを1件確認する

公開されている[Instagramプロフィールのn8n自動化Task](https://apify.com/chronometrica/instagram-channel-scraper/examples/instagram-profile-n8n-automation)は、開始用の入力設定です。ページ確認ではHTTP 200が返され、意図したTask名を確認できました。ただし、この確認では、現在保存されている入力内容は分かりません。実行前に、現行スキーマに沿った入力を適用します。

この最小限の入力は、確認済みの公開スキーマに対する静的チェックに合格しました。静的チェックは、収集を実行せずに入力の構造を調べます。確認したのは、フィールド名、必須フィールド、許可された選択肢、指定したリストの件数、文字列パターン、数値の上下限です。例の情報源が現在利用できるかどうかは確認していません。[Actorの入力スキーマ](https://apify.com/chronometrica/instagram-channel-scraper)。

```json
{
  "startUrls": [
    "https://www.instagram.com/mrbeast/"
  ]
}
```

入力を準備し、対象プロフィールを1件確認する

例を、対象の公開プロフィール1件に置き換えます。確認済みのスキーマは、1～1,000個の文字列を含む`startUrls`配列を受け付けます。公開プロフィールのURLまたはハンドル名を入力できます。[入力要件](https://apify.com/chronometrica/instagram-channel-scraper)。

次に、以下の簡単な受け入れ確認を行います。

1. 対象の情報源を1件選びます。ワークフローで使う公開プロフィールを選びます。既定の例だけでは、実際の対象から取得できるかは分かりません。
2. 現行スキーマを適用します。結果を詳しく確認できるように、入力1件から始めます。
3. 返されたフィールドを確認します。入力内容の再出力、`channelId`、`channelUrl`、必須の件数、`countPrecision`、`observedAt`、`status`、`statusReason`を探します。テーブルの要件と照合します。
4. 両方の振り分けルールを確認します。受け入れには、すべての必須フィールドが必要であることを確認します。確認に回す処理で、不明な値と結果の理由が保持されることを確認します。返された行が1行だけでは、両方の経路を試せないことがあります。
5. マッピングしたレコードを1件書き込みます。保存されたレコードを確認します。識別情報、欠損値、精度、観測日時の意味が保たれているかを確認します。
6. 入力を増やすかを判断します。フィールドが要件に合い、マッピングが機能するなら続けます。必須フィールドが範囲外なら、Actorの選択を変えます。

この確認により、誤ったマッピングや、欠損値を0に置き換える保存先を見つけられます。ただし、プロフィール1件では、長期的な稼働率や比較性能は判断できません。

確認する問いは絞ります。返されたこのレコードで、次の処理に必要な要件を満たせるか、という問いです。識別情報を分析する詳しい方法は、[クリエイターリストから重複するInstagramプロフィールを削除する方法](/ja/articles/instagram-%E3%82%AF%E3%83%AA%E3%82%A8%E3%82%A4%E3%82%BF%E3%83%BC%E4%B8%80%E8%A6%A7-%E3%83%97%E3%83%AD%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB%E9%87%8D%E8%A4%87%E6%8E%92%E9%99%A4/)を参照してください。このガイドは、同じ識別情報の重複を扱います。今回の比較は、レコードがその処理に入る前に、収集時の出力仕様を選ぶものです。

## 制限も判断に含める

この証拠は、文書に記載された範囲による選択を裏付けます。稼働率、規模拡大への対応、速度、正確性、信頼性、取得範囲の優位性を証明するものではありません。総コストが低いという主張を裏付ける、新たな料金計算もありません。

2026年10月19日の自社監査では、ChronometricaのActorは正常と分類されました。この小規模な確認では、比較性能を証明できません。推奨の根拠は、引き続き公開されたフィールド仕様です。[ChronometricaのActor](https://apify.com/chronometrica/instagram-channel-scraper)。

このプロフィール用ワークフローは、過去履歴の復元、フォロワー一覧、ダイレクトメッセージ、自動的な連絡送信を提供しません。連絡先情報は、公開されている場合に限り取得できます。その別の作業については、[公開プロフィール文の連絡先確認ガイド](/ja/articles/instagram-%E8%87%AA%E5%B7%B1%E7%B4%B9%E4%BB%8B%E3%83%AA%E3%83%B3%E3%82%AF-%E5%85%AC%E9%96%8B%E9%80%A3%E7%B5%A1%E5%85%88%E3%81%AE%E7%A2%BA%E8%AA%8D/)を参照してください。

選択を変える主な条件は、簡潔なスナップショットの範囲外に必須フィールドがあることです。この条件をワークフローの要件に残します。次の処理が変わったら、フローを拡張する前にフィールド一覧をもう一度確認します。

## プロフィール用Taskから始める

文書に記載されたスナップショットがテーブルの必須要件を満たすなら、[Instagramプロフィールのn8n自動化Task](https://apify.com/chronometrica/instagram-channel-scraper/examples/instagram-profile-n8n-automation)を開きます。開始用の入力設定として使い、上に示した現行スキーマに沿う入力を適用します。

[ChronometricaのInstagram Channel Scraper](https://apify.com/chronometrica/instagram-channel-scraper)で、対象の公開情報源1件から始めます。入力内容の再出力を、返された識別情報とは別に保持します。精度と観測日時を残し、不完全な行は確認に回します。保存したレコードが受け入れルールを満たしたら、入力一覧を増やします。必須フィールドによって適合性が変わる場合は、より豊富な出力仕様を選びます。

## 出典と参考資料

- [Chronometrica Instagram Channel Scraper — 2026年10月20日に公開ドキュメントと入力スキーマを確認。記載したフィールド、1～1,000件の指定入力、重複入力のルール、利用量の単位を裏付ける。最小限の入力が合格したのは静的チェックのみ。新たな収集実行や、条件をそろえた性能テストは行っていない。10月19日の自社監査ではActorを正常と分類したが、小規模な確認では比較性能を証明できない](https://apify.com/chronometrica/instagram-channel-scraper)
- [Apify Instagram Profile Scraper — 2026年10月20日に公開ドキュメントを確認。記載した、より広範なプロフィールデータと、有料のAbout追加機能を裏付ける。条件をそろえた実行や料金比較は行っていない。文書に記載のない機能が存在しないという推論もしていない](https://apify.com/apify/instagram-profile-scraper)
- [n8nでInstagramプロフィールデータを扱うことについての読者の公開質問 — 2026年10月20日の制作概要に、需要を示す証拠として提供された。個別のページ確認日は提供されていない。ワークフローに関する疑問を示すものであり、提供元の推奨や検証済みのベンチマークではない](https://www.reddit.com/r/n8nforbeginners/comments/1vfzrh4/ways_how_to_pull_public_instagram_profile_data/)
- [Instagramプロフィールのn8n自動化Task — 提供されたページ確認記録に、HTTP 200と意図したTask名が記録されている。2026年10月20日の制作概要には、この記録の個別の確認日は含まれていない。開始用の入力設定にすぎない。現在保存されている入力内容は証明されておらず、この比較のための実行も行っていない](https://apify.com/chronometrica/instagram-channel-scraper/examples/instagram-profile-n8n-automation)
- [クリエイターリストから重複するInstagramプロフィールを削除する方法 — 2026年10月20日の制作概要とともに提供された既存のガイド。個別の確認日は提供されていない。今回取り上げたActorの選択ではなく、識別情報の照合を扱う](https://chronometrica.com/ja/articles/instagram-%E3%82%AF%E3%83%AA%E3%82%A8%E3%82%A4%E3%82%BF%E3%83%BC%E4%B8%80%E8%A6%A7-%E3%83%97%E3%83%AD%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB%E9%87%8D%E8%A4%87%E6%8E%92%E9%99%A4/)