Customer Match IP address運用ガイド｜時刻列の使いどころと地域除外
Google広告のカスタマーマッチで、アップロード用CSVに「User IP address」と「User Interaction timestamp」という2つの列が使えるようになりました。メールアドレスや電話番号に加えてIPアドレスと接触時刻を照合キーにできるため、これまで連絡先が薄くてマッチしにくかった顧客リストを補える可能性があります。
一方で、IPアドレスはハッシュ化せずに送る必要があり、EEA・英国・スイスのユーザーは照合の対象外です。タイムスタンプだけを送ることもできません。便利な追加機能であると同時に、データの持ち方や社内ルールを見直さないと事故につながりやすい仕様でもあります。
本記事では、カスタマーマッチ全体の使い方ではなく、新しく追加されたIP列と時刻列に絞って、使いどころ、地域除外の設計、送信できない組み合わせ、法務面の留意点までを整理します。仕様は2026年10月時点のGoogle広告ヘルプの記載に基づいています。
この記事の要点
- 新列の中身：IPv4またはIPv6のIPアドレスと、そのIPでの接触時刻を照合に使える
- ハッシュ化：IPとタイムスタンプは非ハッシュのプレーンな文字列で送る
- 地域除外：EEA・英国・スイスのエンドユーザーはIP照合の対象外のため送信前に除外する
- 送信ルール：タイムスタンプはIPなしでは送れず、IPだけならそのIPの最新の既知ユーザーで照合される
- 運用判断：連絡先が薄いリストの補完に向くが、共有IPの誤照合と同意・告知の整備が前提
カスタマーマッチのIP列と時刻列は照合キーを広げる追加仕様
カスタマーマッチのIP列と時刻列は、メールや電話番号で拾いきれなかった顧客をGoogleユーザーと結び付けるための追加の照合キーです。既存の列を置き換えるものではなく、同じCSVに並べて照合の手がかりを増やす位置づけだと理解しておくと、設計を誤りにくくなります。
追加された2つの列の位置づけ
カスタマーマッチとは、広告主が自社で直接取得した顧客データをGoogle広告にアップロードし、Googleのユーザーと照合してリスト化し、配信や除外、入札の判断に使う機能です。従来の照合キーはメールアドレス、電話番号、氏名と国・郵便番号の組み合わせ、モバイルデバイスIDなどが中心です。
ここに加わったのが「User IP address」と「User Interaction timestamp」の2列です。Google広告ヘルプ「Create a Customer Match list by uploading a data file」では、アップロード形式の列見出しとしてこの2つが案内されています。業界メディアの報道によると、ファイルアップロードでの対応が報じられたのは2026年9月25日頃で、Data Manager API側ではそれ以前からIPの取り込みに対応していたと伝えられています。
押さえておきたいのは、IPアドレスは人ではなく回線や端末の接続先を示す情報だという点です。メールアドレスのように1人に1つ対応するキーではないため、IP列は単独で精度を担保するキーではなく、既存キーを補う位置づけで使うのが基本です。
既存の照合キーとの違い
メールアドレスや電話番号は、顧客本人が入力した情報であり、1人の顧客と強く結び付いています。これに対してIPアドレスは、顧客が意識せずに残す接続情報で、同じ人でも自宅、職場、外出先で値が変わります。性質がまったく異なるため、同じ「照合キー」という言葉でひとくくりにしないことが大切です。
もう一つの違いはハッシュ化の有無です。メールや電話番号はハッシュ化して送れるので、Googleが元の値を受け取らない形にできます。IPと時刻は非ハッシュで送るため、送信するデータそのものが読める状態でGoogleに渡ることを前提に、社内の承認や告知の範囲を決める必要があります。
また、IPは時間の経過とともに価値が下がりやすい情報です。メールアドレスは数年単位で使い続けられることが多い一方、IPは回線の契約変更や引っ越し、割り当ての更新で変わります。リストの鮮度を保つ運用が、従来の列以上に重要になると考えてください。
このように、IP列は既存の列と性質も扱い方も異なります。導入を決める前に、自社の顧客データにIPがどの程度残っているか、どの経路で記録されたものかを棚卸しし、使える行数の見込みを把握しておくと、検証の計画も立てやすくなります。
公式ヘルプで確認できる形式要件
2026年10月時点のヘルプでは、IPアドレスはIPv4またはIPv6の文字列で、前後の空白を取り除き、ハッシュ化しないプレーンな文字列として渡すよう案内されています。メールや電話番号はSHA256でハッシュ化して送れるのに対し、IPとタイムスタンプは非ハッシュが前提です。
ファイル自体の要件は従来と同じで、CSV形式、文字コードはASCIIまたはUTF-8です。UTF-16は対象外のため、Excelから書き出す際の保存形式には注意してください。また、モバイルデバイスIDのリストはデバイスIDの列だけで構成する決まりがあり、IP列と同じファイルに混ぜることはできません。
| 項目 | User IP address | User Interaction timestamp |
|---|---|---|
| 形式 | IPv4またはIPv6の文字列 | 日時文字列（UTC表記・時差付き表記など複数形式） |
| ハッシュ化 | しない（プレーンな文字列） | しない |
| 単独送信 | 可能（時刻なしは最新の既知ユーザーで照合） | 不可（IPなしで送るとエラー） |
| 地域制限 | EEA・英国・スイスのユーザーは照合対象外 | IPに付随するため同様に扱う |
| 主な役割 | 連絡先が薄い顧客の照合補完 | どの時点のIP利用者かを特定する補助 |
カスタマーマッチの基本的な仕組みやリストの使い分けについては、以下の記事で詳しく解説しています。
IP列が効く場面と効きにくい場面
IP列が効くのは、メールアドレスや電話番号が欠けている、あるいは古くて照合しにくい顧客を多く抱えているケースです。逆に、すでに連絡先の取得率が高いリストでは上積みは限定的で、共有IPによる誤照合のほうが目立つ可能性があります。
連絡先が薄いリストを補完する使い方
たとえば、資料請求フォームで会社のメールアドレスしか取れていない、来店予約で電話番号の入力が任意になっている、といったリストは従来のマッチ率が伸びにくい傾向があります。こうしたリストに、自社サイトでの申込時に記録したIPアドレスと時刻を添えることで、照合の手がかりを増やせます。
ここで重要なのは、IPアドレスもカスタマーマッチのポリシー上は自社が直接取得したファーストパーティデータでなければならないという点です。自社サイトのフォーム送信ログや会員ログイン時の記録など、取得経路を説明できるデータに限って使ってください。外部から購入したリストや、出所が不明なアクセスログを流用することは認められていません。
BtoCの通販や予約型のサービスでは、会員登録時と購入時のIPを記録しておけば、メールアドレスを変更した顧客や、電話番号を登録していない顧客の照合を補える可能性があります。BtoBでは企業回線の共有が多いため、同じ手法でも誤照合の影響が大きくなる点を意識して使い分けてください。
また、IP列は既存列と同じ行に並べることで効果を発揮します。メール列が空欄の行にIPと時刻だけを入れる使い方もできますが、その場合は精度が下がることを前提に、配信対象ではなく除外リストや観察から試すほうが安全です。
共有IPと動的IPによる誤照合のリスク
IPアドレスは複数人で共有されることが珍しくありません。オフィスのネットワーク、マンションの共用回線、公衆Wi-Fi、モバイル回線のキャリアグレードNATなどでは、1つのIPの背後に多数のユーザーがいます。BtoBで企業の代表回線からの申込が多い場合、その会社の別の社員と照合されることも起こり得ます。
さらに、家庭向け回線の多くは動的IPで、一定期間で別の契約者に割り当てが変わります。数か月前に記録したIPを時刻なしで送ると、そのIPを今使っている別の人と照合されるおそれがあります。業界メディアのPPC Landも、時刻を添えないIPは古いデータほど別人に結び付くリスクがあると指摘しています。
こうした性質を踏まえると、IP列だけで作ったリストを「既存顧客そのもの」とみなして入札を強めたり、既存顧客除外に使って新規顧客の配信を絞りすぎたりするのは避けるべきです。IP照合の結果は「既存顧客の可能性が高い集団」として扱い、成果の検証を挟んでから本格運用に移すのが現実的な進め方です。
IP列を使う前に確認したい点
- 取得経路：自社サイトや自社アプリで直接記録したIPか
- 回線の種類：法人の代表回線や公衆Wi-Fiからの記録が多くないか
- 記録時期：古いIPに時刻を添えられるか
- 用途：配信対象か除外か、誤照合時の影響の大きさ
顧客データの連携経路をCSVの手動アップロードからまとめて管理したい場合は、以下の記事が参考になります。
タイムスタンプ列はどの時点のIP利用者かを固定する補助情報
タイムスタンプ列の役割は、送ったIPアドレスが「いつ」使われていたかを示し、照合相手をその時点の利用者に絞り込むことです。時刻単体には識別力がないため、必ずIPとセットで送る補助情報として設計します。
単独送信不可と「最新の既知ユーザー」の意味
ヘルプでは、タイムスタンプはIPアドレスなしでは送信できず、時刻だけを送るとエラーになると明記されています。CSVを作る際に、IP列が空欄で時刻列だけが埋まっている行が混ざっていないかを事前にチェックしておくと、アップロード時のエラーを防げます。
反対に、IPだけを送って時刻を添えない場合、システムはそのIPの「最新の既知」ユーザーを使って照合すると案内されています。つまり、記録した時点ではなく、照合処理を行う時点に近い利用者が対象になるということです。申込から日が浅いデータなら影響は小さいものの、半年以上前のIPを時刻なしで送るのは誤照合の温床になります。
実務上は、IPを記録する仕組みを作る段階で、同時に記録時刻もサーバー側で保存しておくことをおすすめします。フォームの送信日時やログインの日時がすでにCRMやデータベースにあるなら、それをそのまま時刻列に使えます。
時刻を記録する仕組みの作り方
時刻はブラウザ側ではなくサーバー側で記録するのが原則です。利用者の端末の時計はずれていることがあり、タイムゾーンの設定もまちまちだからです。フォームの送信を受け付けたサーバーの時刻を、IPと同じレコードに保存しておけば、後から抽出するときに迷いません。
すでにフォーム管理ツールやMAツールを使っている場合は、IPと送信日時がどの項目に保存されているかを確認してください。ツールによってはIPを保存していない、あるいは一定期間で消去する設定になっていることがあります。保存期間が短いとIP列は使えないため、導入前の棚卸しが欠かせません。
最初と最後のタイムスタンプの選び方
ヘルプでは、タイムスタンプとして「そのIPでの最初の操作時刻」と「最後の操作時刻」の2つの考え方が示されています。どちらを入れるかは、手元にあるデータと照合したい状態によって判断します。2026年10月時点で列見出しは1つしか案内されていないため、1行には1つの時刻を入れる前提で設計しておくのが無難です。
会員サイトのように同じIPから何度もアクセスがあるなら、直近の利用者と照合したいので最後の操作時刻が適しています。一方、資料請求や見積依頼のように1回の申込が主な接点であれば、その申込時刻をそのまま入れるのが自然です。いずれの場合も、タイムゾーンを明記した形式で書き出すことが重要です。
申込から数か月以上たった顧客を含むリストでは、時刻を添えても照合の精度が下がる可能性があります。IPの割り当てが変わっていれば、その時点の利用者を特定する手がかりが弱くなるためです。古い顧客は既存の列だけで送り、直近に接点があった顧客にだけIPと時刻を付けるといった線引きも検討してください。
| ヘルプに例示されている形式 | 記入例 | 運用上の向き不向き |
|---|---|---|
| UTC表記 | 2012-08-15T00:01:54Z | システム間連携で最も扱いやすい |
| 時差付き表記 | 2012-08-14T17:01:54-07:00 | 日本時間なら+09:00を付けて誤差を防げる |
| 英語の月名表記 | Aug 14, 2012 17:01:54 | タイムゾーンが曖昧になりやすい |
| 12時間制の表記 | 2012-08-14 5:01:54 PM | 午前午後の変換ミスに注意 |
日本の広告主が自社システムから書き出す場合は、ISO 8601形式に「+09:00」を付けた時差付き表記に統一しておくと、変換ミスによる照合ずれを防げます。CRMの日時がタイムゾーンなしで保存されているなら、書き出し時に日本時間であることを補ってください。
EEA・英国・スイスの除外は送信前に自社で行う
EEA・英国・スイスのエンドユーザーはIP照合の対象外なので、該当するユーザーのIPは送信前に自社のデータから除外しておく設計が必要です。対象外だと分かっている情報を送ること自体が、各地域のデータ保護規制の観点でリスクになり得るためです。
対象地域とデータ抽出時の除外設計
EEAはEU加盟27か国にアイスランド、リヒテンシュタイン、ノルウェーを加えた30か国で、これに英国とスイスを合わせた32か国のユーザーがIP照合の対象外となります（2026年10月時点）。カスタマーマッチのポリシーページでも、これらの地域ではIPとタイムスタンプの照合をサポートしていないため、IPの共有を除外し、透明性のある告知と必要な同意の取得を確実に行うよう案内されています。
国内向けの事業でも、越境ECや訪日客向けの予約サイト、海外拠点を持つBtoB企業などでは、該当地域の顧客がリストに含まれることがあります。業界メディアの報道では、該当行をGoogle側で破棄するのか広告主側の除外を前提とするのかは明確にされていないとも伝えられています。そのため、Google側の処理に頼らず、抽出段階でIP列を空欄にする運用を標準にしてください。
除外の判定根拠をどう持つか
除外の判定には、顧客が登録した住所の国、配送先の国、契約時の居住国など、自社で根拠を説明できる属性を使うのが基本です。複数の属性がある場合は、どれを優先するかを決めておくと判定がぶれません。IPアドレスから地域を推定する方法もありますが、VPNやローミングで誤判定が起きるため、それだけに頼ると漏れが出ます。
国の情報がない顧客をどう扱うかも事前に決めておきましょう。迷う行はIP列を送らず、メールや電話番号のハッシュだけで照合する保守的なルールにしておけば、規制面のリスクを抑えられます。除外条件はSQLや抽出スクリプトに組み込み、担当者が手作業で判断しない形にしておくことが重要です。
除外の結果は、件数として記録しておくと後の監査に役立ちます。抽出のたびに、全体の行数、IP列を空欄にした行数、そのうち地域条件で外した行数を残しておけば、社内や取引先から運用状況を問われたときにも根拠を示せます。
地域除外で起きやすいミス
- 国の列が空欄の顧客にもIPをそのまま入れてしまう
- EU加盟国だけを除外し、英国・スイス・EEA追加国を漏らす
- 手作業のフィルタで、担当者ごとに除外条件がばらつく
- 過去に作ったCSVを流用し、除外前のデータを再送する
同意の取得状況を広告計測側でどう扱うかについては、以下の記事で詳しく解説しています。
法務とプライバシー面で整えておくべきこと
IP列を使う前に整えるべきなのは、プライバシーポリシーでの告知、必要な同意の取得、そして社内での保管と送信のルールの3点です。メールや電話番号と違って非ハッシュで送る情報である以上、従来よりも一段丁寧な説明責任が求められます。
プライバシーポリシーと同意取得
カスタマーマッチのポリシーでは、自社が直接取得したデータのみを使うこと、第三者とのデータ共有をプライバシーポリシーで開示すること、法律で求められる同意を取得することなどが求められています。IPアドレスを広告目的でGoogleに提供するのであれば、その旨がポリシーの記載範囲に含まれているかを確認してください。
日本の個人情報保護法の観点では、IPアドレスは単体では個人情報に当たらない場合がある一方、氏名やメールアドレスと同じ行で管理していれば個人データの一部として扱うのが安全です。また、電気通信事業法の外部送信規律により、サイト上で利用者の情報を外部に送る場合の公表や通知が求められるケースもあります。解釈は事業内容や取得方法によって変わるため、IP列の利用開始前に法務担当や顧問弁護士の確認を取ることを強くおすすめします。
業界メディアの報道によると、ドイツの連邦裁判所が動的IPアドレスの個人データ該当性について欧州司法裁判所に判断を求めるなど、IPアドレスの扱いは海外でも議論が続いています。国内向けの施策であっても、将来の規制動向を見ながら定期的にルールを見直す前提で運用してください。
告知の文面は、専門用語を並べるだけでなく、利用者が読んで理解できる表現にすることも大切です。「お客様が当サイトを利用した際の接続情報を、広告の配信や効果測定のために広告配信事業者へ提供することがあります」といった形で、何を、誰に、何のために提供するのかが伝わるよう整えておくと、問い合わせや苦情への対応もしやすくなります。
社内の保管と送信のルール
非ハッシュのIPを含むCSVは、ハッシュ済みのリストよりも漏えい時の影響が大きくなります。ファイルを作成できる担当者を限定し、作業用PCのダウンロードフォルダに残さない、チャットツールに添付しない、アップロード後は削除するといった基本ルールを明文化しておきましょう。
外部の広告代理店や制作会社に作業を委託している場合は、委託先がIP付きのファイルをどう保管し、どの端末で扱うかも確認が必要です。委託契約や秘密保持の取り決めにIPアドレスが含まれているかも、あわせて見直しておくと安心です。
手作業のCSV運用が増えるほど事故の確率は上がります。データマネージャーなどの公式連携に寄せて、ファイルを人が触る回数を減らすことが、法務面とセキュリティ面の両方で最も効果的な対策です。ヘルプでもデータマネージャーはファーストパーティデータの接続を一元管理するハブとして案内されています。
社内で決めておきたいルール
- 告知範囲：プライバシーポリシーにGoogleへの提供と目的を記載
- 取得経路：IPを記録するフォームやログの一覧を管理
- 作業権限：CSVを作成・アップロードできる担当者を限定
- 保管期限：送信後のファイルを残さない運用
- 見直し時期：規制や仕様の変更時に法務確認をやり直す
顧客データの扱いに不安がある場合や、社内ルールの整備から相談したい場合は、広告運用の無料相談もご利用いただけます。
IP列の導入を見送ったほうがよいケース
IP列は全ての広告主に必要な機能ではなく、連絡先の取得率が高い事業や、海外ユーザーの比率が高い事業では導入を見送るほうが合理的です。追加の手間とリスクに見合う上積みがあるかを、導入前に冷静に見極めてください。
上積みが小さいと考えられる状況
会員登録でメールアドレスと電話番号の両方を必須にしているサービスや、購入時に必ずログインが必要なECでは、既存の列だけで十分な照合ができている可能性があります。この場合、IP列を加えても照合できる顧客はわずかで、むしろ共有IPによる誤照合の影響のほうが大きくなりかねません。
リストの件数が少ない場合も注意が必要です。マッチ率が表示される条件を満たさず、効果を測れないまま運用を続けることになりやすいからです。検証できない施策は続けないという原則で、件数が十分にそろってから試すほうが、限られた運用工数を有効に使えます。
リスクが上回りやすい状況
EEA・英国・スイスの顧客が多い越境ビジネスでは、除外処理の負担が大きく、判定漏れのリスクも高まります。医療や金融など、顧客データの取り扱いに特に慎重さが求められる業種でも、非ハッシュのIPを外部に渡すことへの社内合意を得るのは簡単ではありません。
こうした状況では、IP列に頼るよりも、フォームでのメールアドレス取得率を上げる、会員登録の導線を見直すといった、既存の照合キーを強化する施策のほうが確実です。連絡先の取得率を高めることが最も堅実なマッチ率改善策である点は、新しい列が加わった後も変わりません。
フォームで取得した情報を計測の精度向上に生かす方法については、以下の記事で詳しく解説しています。
アップロード運用と効果検証の進め方
IP列と時刻列の導入は、既存リストを丸ごと差し替えるのではなく、IP付きのリストを別に作って比較検証する進め方が最も安全です。マッチ率の変化と、配信や除外に使ったときの成果の両方を見てから、本番のリストに統合するかを判断します。
CSV作成からアップロードまでの流れ
まず、CRMやデータベースから対象顧客を抽出し、メール・電話番号などの既存列に加えて、IPと記録時刻を同じ行に並べます。この段階でEEA・英国・スイスの顧客や国が不明な顧客のIP列を空欄にし、IPが空欄なのに時刻だけが入っている行がないかを確認します。
次に、列見出しをヘルプの記載どおり英語で設定し、UTF-8で保存します。IPの前後に空白が入っていないか、IPv6が途中で切れていないかもチェックしてください。アップロード後の処理には最長で48時間ほどかかることがあると案内されているため、配信開始日から逆算して余裕を持って準備しておきましょう。
リストの更新頻度も決めておきましょう。IPは時間とともに鮮度が落ちるため、一度アップロードして終わりにせず、月次や週次で直近の顧客を追加し、古い行のIPは外していく運用が向いています。カスタマーマッチの会員期間は最長540日と案内されていますが、IP付きの行はそれより短いサイクルで入れ替える前提で考えると安全です。
| 確認項目 | チェック内容 | ミスした場合の影響 |
|---|---|---|
| 地域除外 | EEA・英国・スイスと国不明のIPを空欄化 | 規制面のリスク |
| 時刻単独行 | IPなしで時刻だけの行がない | アップロードエラー |
| ハッシュ | IPと時刻はハッシュ化していない | 照合されない |
| 文字コード | UTF-8またはASCIIで保存 | 読み込み失敗 |
| タイムゾーン | +09:00などの時差を明記 | 照合ずれ |
マッチ率の見方と比較検証
マッチ率は、ユニークユーザーに一致した行が100行以上ある場合に表示されると案内されています。小さなリストで試すと数値が出ないことがあるため、検証用のリストはある程度の件数を確保してください。同じ顧客群でIP列ありとなしの2つのリストを作れば、IP列による上積みを比較しやすくなります。
業界メディアの報道によると、Googleは2026年第3四半期以降にIPと時刻によるマッチ率の改善を見込むとしていましたが、改善幅を示す具体的な数値は公表されていません。10月以降に効果が見え始める可能性はあるものの、改善幅は自社のリストで実測して判断するしかありません。マッチ率だけでなく、除外に使ったときの新規顧客比率や、配信に使ったときのCV率の変化も合わせて確認しましょう。
検証の結果、誤照合が疑われる兆候、たとえば既存顧客除外に使ったら新規CVが不自然に減ったといった変化が見られた場合は、IP列を外したリストに戻す判断も必要です。新しい列は使えば必ず成果が上がるものではないため、効果がないと分かった時点で手放せる設計にしておくことが大切です。
検証結果は、リスト名、作成日、IP付きの行数、マッチ率、用途、成果の変化をまとめた記録として残しておきましょう。担当者が替わっても判断の経緯をたどれるようにしておけば、仕様変更があったときにも再検証の基準として使えます。
リストの用途ごとの使い分け
IP付きリストの使い道は、配信対象として使うか、除外として使うか、観察として使うかで、誤照合の影響が大きく変わります。観察であれば配信は変わらず、成果の差を見るだけなので、最初の検証には最も向いています。
除外に使う場合は、誤照合が起きると本来配信したい新規見込み客まで外れてしまいます。配信対象に使う場合は、既存顧客ではない人に既存顧客向けのメッセージが届く可能性があります。まずは観察で2〜4週間ほど成果差を確認し、問題がなければ除外や配信へ段階的に広げる進め方が安全です。
なお、ターゲティングでの利用にはアカウントのポリシー遵守歴や支払い履歴などの条件があり、ポリシーページでは利用実績の期間や累計支出額の基準も案内されています（2026年10月時点）。自社アカウントでどの用途が使えるかを先に確認しておきましょう。
既存顧客リストを除外に使って新規獲得を伸ばす設計については、以下の記事で詳しく解説しています。
まとめ IP列と時刻列を安全に使う運用ポイント
カスタマーマッチのIP列と時刻列は、連絡先が薄い顧客リストの照合を補える一方、非ハッシュでの送信、地域除外、単独送信不可といった追加ルールを正しく扱う必要があります。導入前に押さえておきたいポイントは次の3つです。
- IPは補助キーとして使う。共有IPや動的IPによる誤照合があるため、既存キーと同じ行に並べ、時刻を添えて精度を保つ
- 地域除外は送信前に自社で行う。EEA・英国・スイスと国不明の顧客はIP列を空欄にし、抽出処理に除外条件を組み込む
- 告知・同意・社内ルールを先に整える。プライバシーポリシーの記載と法務確認を済ませ、比較検証で効果を実測してから本番に統合する
まずは無料で広告アカウント診断を
カスタマーマッチの新しい列は、うまく使えばリストの照合範囲を広げられますが、データの抽出条件や法務面の整備、検証設計まで含めると、社内だけで判断するのが難しい場面も少なくありません。株式会社ハーマンドットでは、Google広告をはじめとする運用型広告の設計と改善を支援しています。
顧客リストの活用状況やマッチ率、既存顧客除外の設計に課題を感じている場合は、現状のアカウントを確認したうえで、改善の優先順位と具体的な進め方をご提案します。お問い合わせフォームからお気軽にご相談ください。
初回相談は完全無料・所要時間30分・オンライン対応可能です。