LINEのプロフィール取得が404になる理由｜ブロックと決めつける前の確認
文・小川 靖人元LINE社員・LIFE合同会社 代表この記事の結論
Messaging APIのプロフィール取得で返る404は、ブロックだけを示す結果ではありません。ユーザーID、対象チャネル、プロフィール取得の条件と、名前・画像が取れない場合の対応を整理します。
最終更新：2026年10月9日
Messaging APIでユーザープロフィールを取得して404が返っても、その人にブロックされたと断定することはできません。存在しないユーザーID、プロフィール取得への未同意、対象の公式アカウントとの関係など、複数の理由があります。まず取得元と条件を調べ、原因を確認できるまで「プロフィール未取得」として扱います。
顧客管理にLINEの表示名や画像を出す担当者と、取得エラーを調べる実装担当者向けの記事です。友だち全体の件数を数えることや、LINEログインのメールアドレスを取る処理とは異なります。
404が示すのは、プロフィールを取得できなかったこと
公式APIリファレンスのGET /v2/bot/profile/{userId}では、400は無効なユーザーIDの指定、404はプロフィールを取得できなかった場合の応答です。404の理由として、IDの不存在、未同意、未友だち追加、ブロックなどが説明されています。
取得できる対象には、公式アカウントを友だち追加しているユーザーのほか、追加したことはなくても公式アカウントへメッセージを送ったことがあるユーザーも含まれます。ただし、ブロックしているユーザーは対象外です。「友だち追加していない」という一項目だけで、すべて取得不可とする説明にも広げないでください。
一つのエラーを「ブロック確定」としてスタッフの画面へ出すと、相談を継続してよいのか、データが壊れているのかを取り違えます。事実として確認できる取得結果と、原因の仮説を分けて記録します。
IDと、取得するチャネルの対応を確認する
最初に見るのは、入力したIDがどこから来たかです。表示名や、友だち検索に使うLINE IDを、APIのuserIdとして渡してはいけません。Webhookなど、確認した取得経路から来た値を使います。
同じユーザーでも、異なるプロバイダーではIDが異なります。別のプロバイダーのLINEログインから取得したIDを、今のMessaging APIの対象としてそのまま使っていないかを確認してください。詳しい対応はプロバイダーとユーザーIDで整理しています。
調査では、チャネルの組み合わせ、取得時点、応答コードを確認します。アクセストークンそのものや、顧客の全プロフィールをチャットや共有ログへ貼る必要はありません。担当者が調べられる記録と、広い範囲へ出してよい情報を分けてください。
図：問い合わせの調査と、プロフィールを表示する画面の点検に使う確認表です。利用者の気持ちや退会の意思をエラーから推測しないでください。
グループのメンバーは、対象のAPIも確認する
グループ・複数人トークの参加者のプロフィールには、それぞれメンバー用の取得エンドポイントがあります。通常の1対1のプロフィール取得と同じ条件で扱わないようにします。グループにいたという記録だけでは、公式アカウントとの友だち関係を示しません。
プロフィール取得の同意に関する公式説明では、同意の条件のほか、Botやユーザーのグループからの退出も取得できない理由として説明されています。過去の参加状態を、現在も取得できる証拠にはしないでください。
たとえば、架空の家族グループの相談で写真の送信者の表示名が取れない場合、別の参加者の表示名を代わりに付けて処理を進めないようにします。相談の場所と送信者、取得結果を区別し、必要な確認を権限のある担当へ渡します。
成功した応答でも、すべての項目が揃うとは限らない
プロフィール画像やステータスメッセージは、ユーザーが設定していなければ応答に含まれません。画像URLがないことを、取得エラーや顧客データの消失と扱わないでください。取得できるのはメインプロフィールで、サブプロフィールを同じAPIで取得する仕様ではありません。
画面では、画像がない場合の表示、取得に失敗した場合の表示、既に確認した会員情報を、それぞれ分けます。取得していない表示名を勝手に補ったり、同じ名前の別人へ情報をまとめたりしません。お客様を認識するための一つのIDに、確認できた情報だけを結び付けます。
次の担当者が見たいのは、「名前が取れたか」だけではなく、その相談にどこまで返答できたかです。プロフィール未取得でも、確認済みの会話を読める状態は残し、必要な確認が終わる前に返信済み・解決済みにしないようにします。
原因と画面表示を、一件ずつ確かめる
公開前の検証では、許可されたテストユーザーで成功応答を確認し、架空のエラー応答や画像のない応答で画面を点検します。顧客の設定を勝手に変えたり、実顧客をブロックさせて調査したりする必要はありません。
入力IDの取得元、対象チャネル、使ったエンドポイント、応答コード、未確認の原因を残してください。404のままなら、名前を推測して埋める前に、どの条件が未確認かを担当へ渡すことが次の行動です。
※仕様の確認日：2026年10月9日。実顧客のプロフィールを今回取得したり、既存サービスの取得処理を変更したりしたという記録ではありません。