Gmailに他社メールを取り込む機能が終了した後の受注メール集約｜転送・ローカル読み取り・POP直取りの選び方

Gmailの設定画面で「他のアカウントのメールを確認」を開いても、「メールアカウントを追加する」のリンクが見当たらない。これは操作ミスや権限の問題ではありません。GoogleがこのPOP取り込み機能（Mail Fetcher）とGmailifyの提供を終了しつつあるためで、公式ヘルプでは「2026年第1四半期以降、新規ユーザーには提供しない」「既存ユーザーは2027年1月まで利用できる」と案内されています。

結論から書きます。受注メールや問い合わせメールをGmailに集めて自動処理していた場合、今後の集約経路は次の3つから選びます。

経路	仕組み	向いている条件
A. 送信元サーバーの自動転送	独自ドメイン側のメールサーバーで、届いたメールをGmailへ転送する	サーバーの管理画面に自分で入れる。即時性が欲しい
B. PCのメールソフトが保存したデータを直接読む	受注メールを受けているPCのメールソフトがローカルに保存した実体を、日次のプログラムが読む	既にPCのメールソフトで受信している。日次処理で足りる。サーバー設定に触れない
C. POP/IMAPで直接取得	プログラムがメールサーバーへ直接接続して取得する	認証情報を自分で管理できる。PCの稼働に依存させたくない

どれを選んでも、「取り込みが止まったことに気づく仕組み」を同時に入れます。取り込みが静かに止まると、受注台帳に新しい行が増えないだけで、エラーは出ません。最後に受信したメールの時刻を毎回記録し、一定時間より古ければ警告する。この鮮度チェックが、経路の選択と同じくらい重要です。

この記事では、弊社graciautoが名古屋の革製品メーカー（自社EC＋3モール、受注は月70件前後）の受注管理を組む際に、Gmail取り込みが使えないと分かった時点から集約方式を選び直した実例をもとに、3経路の判断基準と鮮度チェックの設計をまとめます。

何が終了したのか｜公式ヘルプの内容を整理する

終了の対象は2つです。

• Gmailify：他社のメールアカウントに、Gmailの迷惑メール対策や受信トレイの分類、検索、スマホ通知などを適用する機能
• 他のアカウントのメールを確認（POP取り込み）：他社のメールアカウントからPOPでメールを取得し、Gmailの受信トレイに取り込む機能

公式ヘルプに書かれている時期は次のとおりです。

区分	時期
新規の追加	2026年第1四半期以降は提供されない
既存の設定	2027年1月まで利用できる
取り込み済みのメール	終了後もGmailに残る

Googleが代わりに案内しているのは、「他社メールプロバイダ側で自動転送を設定する」「スマホのGmailアプリでIMAP接続して読む」「メールと連絡先を一度だけインポートする」の3つです。このうち自動処理の入口として使えるのは自動転送だけで、スマホアプリのIMAP接続は人が読むためのもの、一度きりのインポートは移行用です。

注意したいのは、既存の設定がまだ動いている会社です。2027年1月までは今までどおり取り込まれるため、止まるまで気づかないことがあります。取り込みの設定が残っているなら、期限より前に別経路へ切り替えておく方が安全です。

実例｜Gmail取り込みが使えないと分かってから集約方式を選び直すまで

前提を整理します。

• 販売チャネルは自社EC（Shopify）・楽天・Yahoo!ショッピング・Amazonの4つ。各モールからの受注通知メールが、会社の独自ドメインのアドレスに届く
• 受注は月70件前後（1日2〜3件）。役員が毎朝メールを印刷して確認し、品番をマスタで検索して社内シートに転記していた
• 目標は「毎朝7時までに前日の受注がスプレッドシートに載り、正しい品番と商品名が補完されている状態」

受注メールを集める経路の第一候補は、通知用のGmailアカウントにPOP取り込みを設定する方法でした。サーバー側の設定も、ドメインを管理している会社への依頼も要らず、手元のIDとパスワードだけで完結するからです。集約経路は設計の最初に実際の設定画面で確認する、という手順どおりにGmailの設定画面を開くと、「メールアカウントを追加する」のリンクはなく、「Mail Fetcherの詳細」というリンクだけが残っていました。公式ヘルプの終了案内を確認し、この時点で候補から外しています。

転送そのものが不要だった

次に検討したのは、経路Aの「送信元サーバーで転送する」方法です。事前にDNSを調べてメールサーバーの提供元と受信サーバーのホスト名、開いているポート（POP3S 995・IMAPS 993など）まで特定していましたが、サーバー側の転送設定は契約者向けの管理画面でしか行えない可能性が高く、メールユーザーの権限だけで設定できるかは公開情報では確認できませんでした。

ここで前提を見直しました。受注メールを受けているアドレスは、担当者のMacのメールアプリに既に設定されています。つまり受注メールは全部、そのMacのローカルにファイルとして保存されています。日次のプログラムがそのファイルを直接読めば、Gmailへの転送も、モール側の認証情報も、ドメイン管理会社への依頼も不要です。経路Bを採用しました。

結果

前日分の受注メールを毎朝7時に読み、4チャネル分をチャネル別のシートに1行ずつ追加する構成にしました。初回に8日分をまとめて取り込んだ結果は55行（楽天13・自社EC19・Yahoo!17・Amazon6）で、メール解析の失敗はゼロでした。翌日以降の定時実行でも新規行が追加され、既に載っている行は二重に増えません。

同時に「稼働ログ」シートを設け、実行ごとに件数と、チャネル別の最新受信時刻を記録し、最新の受信が48時間より前なら警告を出すようにしました。受注メールを読む側のプログラムから見ると「今日は受注がゼロだった」のか「メールソフトの受信が止まっていた」のかは区別できません。だから受信時刻そのものを見ます。

品番をモールごとの表記から自社の商品コードへ戻す規則の話は楽天・Amazon・Yahoo!・自社ECの受注を1つにまとめる方法に、台帳の設計はネットショップの受注を1枚のスプレッドシートに集約する設計に書いています。本稿はその手前の「メールをどこから読むか」の部分です。

3経路の判断基準｜どれを選ぶか

経路A｜送信元サーバーの自動転送

Googleが公式に案内している方法で、Gmail側に何も設定しなくても新着がGmailに届きます。転送先のGmailから先は、時間主導のトリガーで「まだ処理していないメール」を検索して処理する既存の作り方がそのまま使えます。組み方は問い合わせメールをLINEに自動転送する仕組みの前半が参考になります。

条件は「サーバーの転送設定に自分で入れること」です。レンタルサーバーを自社で契約していれば管理画面で数分の作業ですが、ドメインやメールを別会社（親会社・運営会社・制作会社）が管理している場合は依頼と確認のやり取りが発生し、その会社の契約者向け画面でしか設定できないこともあります。転送設定は原本をサーバーに残す形にし、転送先に届かない事態に備えて送信元に控えを残します。

経路B｜PCのメールソフトが保存したデータを直接読む

受注メールを受けているPCで、既にメールソフトが受信している場合に選べます。メールソフトはメールを1通ずつファイルとしてローカルに保存しているので、プログラムがそのフォルダを読み、送信元と件名で「どのモールの何の通知か」を判別して解析します。

向いているのは、日次処理で足りる業務です。受注が1日数件で、翌朝の定時にまとまって台帳に載れば十分なら、リアルタイム性は要りません。逆に、この経路の弱点は「そのPCとメールソフトが動いていること」が前提になる点です。PCの電源が落ちている、メールソフトを閉じている、OSのアップデート後に受信が止まっている、といった状態でも、プログラム自体はエラーを出さずに「新着0件」として正常終了します。鮮度チェックを必ず組み込む理由がここにあります。

実装上の注意が2つあります。

1. メールのファイルは読み取り専用で扱う。移動・削除・変更はしない。メールソフトの管理下にあるファイルを外から書き換えると、ソフト側の索引と食い違うおそれがある
2. OSのアクセス権限を先に付与する。Macの場合、メールデータの保存先はシステムが保護しているフォルダにあり、自動実行の起点となるアプリ（ターミナルなど）に「フルディスクアクセス」を付与していないと、自動実行時に権限エラーで止まる。手動実行では動くのに定時実行だけ落ちる、という状態になりやすいので、付与後に定時実行を手動で起動して1回完走させてから運用に入る

経路C｜POP/IMAPで直接取得

プログラムがメールサーバーへ直接接続して取得する方法です。PCのメールソフトに依存せず、サーバーで動かせます。条件は、受信サーバーのホスト名・ポート・ID・パスワードを自分で管理できることです。

注意点は、POPで「サーバーから削除する」設定にしているクライアントが他にあると、先に取った側しかメールを持てなくなることです。既にPCのメールソフトがPOPで受信しているなら、その設定が「サーバーにコピーを残す」になっているか、あるいはIMAPかを先に確認します。この確認はGmailのPOP取り込みが使えた時代から同じで、経路Cを選ぶときにも変わりません。

弊社の実例では、経路Bで運用を始め、PCへの依存を外したくなった段階で経路Cへ格上げする計画にしています。日次処理で足りる規模なら、まずBで一周回してから考えても遅くありません。

判断のまとめ

状況	選ぶ経路
サーバーの転送設定に自分で入れて、即時処理もしたい	A
受注メールを既にPCのメールソフトで受けていて、日次で足りる	B
認証情報を自分で管理でき、PCの稼働に依存させたくない	C
既存のGmail取り込みがまだ動いている	2027年1月より前にA〜Cへ切り替える

鮮度チェックの設計｜取り込みが止まったことに気づく

どの経路でも、次の3点を入れます。

1. 最後に受信したメールの時刻をチャネル別に記録する。「処理した件数」ではなく「メールの受信時刻」を見る。件数ゼロは正常な日にも起こる
2. しきい値を超えたら警告する。実例では48時間。受注が毎日あるチャネルなら24時間でも成立するが、週末に受注が少ないチャネルを含めると誤警告が増えるので、実績を見て決める
3. 警告の出口を決める。稼働ログのシートに書くだけでなく、担当者が毎朝見る場所（台帳の先頭や通知）に出す。誰も見ないログに警告を書いても止まったことには気づけない

「成功」と表示されているのに反映されていない、という状態の見つけ方は自動処理が「成功」と出ているのに反映されないときに、監視の指標を「最後に成功した時刻」に置く考え方は自動処理の監視は「最後に成功した時刻」を見るにまとめています。

起こりうる失敗と予防

起こりうること	予防策
Gmail取り込みを前提に設計を進め、設定段階で追加できないと分かる	集約経路は設計の最初に、実際の設定画面を開いて確認する。公式ヘルプの終了案内を前提に3経路から選ぶ
既存のGmail取り込みが2027年1月で止まり、台帳が更新されなくなる	期限の前に別経路へ切り替える。切り替え後は鮮度チェックで止まっていないことを確認する
転送設定を管理会社に依頼したまま、着手が数週間止まる	依頼と並行して、PCのメールソフトで既に受信していないかを確認する。受信していれば経路Bで先に動かせる
PCのメールソフトが止まり、「新着0件」のまま正常終了し続ける	受信時刻ベースの鮮度チェックと、担当者が見る場所への警告
定時実行だけ権限エラーで落ちる	自動実行の起点となるアプリにアクセス権限を付与し、定時実行を手動で起動して1回完走させる
POPで「サーバーから削除」の設定が競合し、片方にしかメールが残らない	既存クライアントの受信設定（POP/IMAP、コピーを残すか）を先に確認する
メールソフトのデータを外から書き換えて表示が壊れる	読み取り専用で扱い、移動・削除・変更はしない

よくある質問

Q. 「メールアカウントを追加する」が出ないのは、自分の設定のせいですか

いいえ。Googleが新規の提供を終了したためで、設定やプランを変えても復活しません。既に設定済みのアカウントには「Mail Fetcherの詳細」などのリンクだけが残ります。

Q. 今動いているGmailの取り込み設定はいつまで使えますか

公式ヘルプでは「既存ユーザーは2027年1月まで」と案内されています。取り込み済みのメールはその後もGmailに残りますが、新着は取り込まれなくなるので、それまでに別経路へ移してください。

Q. Gmailを経由しない場合、GASのメール処理は使えなくなりますか

Gmail上の検索を起点にした処理は使えなくなります。経路Aで転送すればGmail上の処理はそのまま使えます。経路B・Cではメールの読み取りをPCやサーバー側のプログラムに移し、スプレッドシートへの書き込み以降を共通にします。書き込み後の処理（ステータス変更で指示書を出すなど）はスプレッドシート側に置けるので、経路に依存しません。その部分はスプレッドシートのステータスを変えた瞬間にPDFを自動作成する仕組みに書いています。

Q. 自分で作れますか

経路Aの転送設定と、Gmailを起点にした簡単な通知なら、サーバーの管理画面に入れる方であれば自分で組めます。経路B・Cは、メールの解析・モールごとの通知形式の違い・鮮度チェック・権限設定まで一式が必要になるので、受注管理の台帳設計と合わせて制作会社に相談する方が早いです。

まとめ

• Gmailの「他のアカウントのメールを確認」は、2026年第1四半期以降は新規追加できず、既存の設定も2027年1月までで終了する
• 代わりの経路は3つ。サーバー側の自動転送（A）、PCのメールソフトが保存したデータの直接読み取り（B）、POP/IMAPでの直接取得（C）
• 既にPCのメールソフトで受注メールを受けていて日次で足りるなら、転送も認証情報も依頼も不要なBが最短。PCの稼働に依存させたくなければCへ格上げする
• どの経路でも、チャネル別の最新受信時刻を記録して、しきい値を超えたら担当者が見る場所に警告を出す。件数ではなく受信時刻を見る
• 既存のGmail取り込みがまだ動いている会社は、止まってから気づくのが一番損。期限前に切り替える

弊社では、受注メールの集約経路の選定から、モールごとの通知形式の解析、スプレッドシートへの日次反映、鮮度チェックまで一式で対応しています。「Gmailに集めていた受注メールをどう移すか」で止まっている方は、お問い合わせからご相談ください。