お疲れ様です。渡部です。お久しぶりです。
BTCも在宅ワークが基本になりましたが、私自身はインドア派なので、本（Kindle）があれば基本満足なのですが、やはり運動不足ですね。夜少し走ったりしています。皆様いかがお過ごしでしょうか。

本日はRPAからのメール操作についてまとめてみたいと思います。
※図においてはメール送信を例に記載していますが、メール受信も同じようになります。

基本的な４つのパターン

RPAからのメール送信としては基本以下の４パターンがあります。

A方式：Outlookアプリケーションを経由する

一般的なRPAであれば、PCにインストールされたOutlookをOutlook APIというものを利用して操作が可能です。Outlookを操作して、メールの送信や受信したメールをRPA内に取り込むことも可能です。メールサーバとのやりとりはOutlook自体がしてくれるので、RPA的にはメールサーバや社内ネットワーク環境を特に意識せずにOutlook APIを叩くだけで自動化できるので非常に簡単です。

Outlook APIを叩くと、Outlookが起動していなかった場合、自動的にバックグラウンドで起動するのですが、単純にOutlookアプリが大きなアプリであること、Outlookのアップデート（Officeのアップデート）、Outlookアプリ起動時におけるメールサーバとの同期などが原因でメール操作が失敗することもあります。

B方式：メールサーバと直接通信する

RPAがメールサーバの認証情報（ID・パスワード）を持って、メールサーバと直接通信をするやり方です。

直接通信するので、RPAの動作的には一番安定する方式となりますが、社内ネットワークの制限により通信がブロックされている会社も多いです。

また、一部のメールサービス（Gmail）は設定変更で直接通信を許可する必要なものもあったりします。

現場的な欠点を言えば、メール送信において、「下書き（Draft）」状態にすることができず、すぐに相手先にメールが送られてしまうことです。
多くの会社において、誤送信防止のために、RPA開発規約において社外アドレスへのメール送信を禁止しているところが多いですが、「下書き」状態にすることができれば、RPAによって「下書き」状態までメールを作成してき、RPA運用担当者が下書きメールを確認して、問題なければ実際に送信という手順にすることも可能になるからです。

C方式：Web画面を操作する

GmailやOutlook.comのようなクラウドメールサービスを利用する会社様が増えてきました。さらに、A方式（Outlookアプリの使用）・B方式が禁止されて、メールを見れるのはブラウザ経由しかできないところも多いです。これはインターネットへの通信においてメールで使うようなSMTPポートの許可をする必要がなく、インターネットへの通信はHTTPSに絞れるので、セキュリティ観点からも推奨されているからです。

ただ、GmaiやOutlook.comの画面は、Google社やMicrosoft社により日々開発が行われており、いきなり画面レイアウトが変更になったりします。いきなり画面レイアウトが変わってしまうと、RPAは画面操作で失敗し、エラー終了となってしまいますので、私としては推奨しないパターンでの自動化となってしまいます。

D方式：クラウドサービスAPIを利用する

GmaiやOutlook.comなど大手クラウドサービスの場合は、API接続できるようになっています。これらのAPIにRPAから接続することでメール操作をすることも可能です。

主要RPA製品においては、各APIに対応したモジュールを提供しているところもあり、比較的簡易に対応することができます。以下にその一例を上げます。

Google Gsuite
https://connect.uipath.com/ja/marketplace/components/google-gsuite
Google GSuiteアクティビティ（認証）の徹底解説
https://www.uipath.com/ja/blog/developer/google-g-suite-activity
Gmail API v1
https://digitalexchange.blueprism.com/dx/entry/9648/solution/gmail-api-v1-2

ただ、セキュリティ観点からインターネットへの接続については社内の認証プロキシを経由する必要が多い会社様も多く、認証プロキシを経由して接続できるようにモジュールをカスタマイズする必要もあります。

具体的には接続する前にプロキシ認証情報をもったWebClientクラスを用意して、WebClientクラスを利用してAPI接続を行います。（以下、参考例）

# プロキシサーバ
$proxy_url = "http://squid.bigtreetc.com:8888"
# プロキシ認証アカウント
$user = "watanabe"
$pass = "hogehoge"

# WebClient設定
$proxy_server = New-Object System.Net.WebProxy($proxy_url, $true)
$credential = New-Object System.Net.NetworkCredential($user, $pass)
$proxy_server.Credentials = $credential

$web_client = New-Object System.Net.WebClient
$web_client.Headers.Add("User-Agent","Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36");
$web_client.Headers.Add("Content-Type","application/x-www-form-urlencoded");
$web_client.Proxy = $proxy_server

どの方式がおすすめか

開発の容易性や安定性から考えて、私の考えでは以下の順になるかと思います。

1. A方式：Outlookアプリケーションを経由する
2. B方式：メールサーバと直接通信する
3. D方式：クラウドサービスAPIを利用する
4. C方式：Web画面を操作する

正直、C方式は先に触れましたが最終手段的な方式であり、A方式・B方式がダメな時は、なんとかしてD方式で対応します。D方式は、認証プロキシをRPAが使う許可を情報システム部門に許可を取ったりする必要があることや、プログラミング知識も必要なので、大変なところが多いですが踏ん張りどころです（正直腕の見せ所でもあります）。それでもD方式がダメな場合は、C方式には行かず、その部分の自動化を諦めてもらったり、そもそもメールを使わない方法を一緒に考えたりします。

まとめ

単純に「メール操作」といっても複数の方式があり、またRPA製品によってできるもの・できないものもあります。RPAエンジニアはお客様の要望や各RPAツールの特徴、システム構成を把握して、どの方式を取らないといけないのか、またぞれぞれのリスクは何なのかを判断して自動化のやり方を検討する必要があります。

この記事がお客様への説明時の資料として役立ってくれれば幸いです。

その他

• Exchangeサーバー接続については説明を割愛しました。
• メールウォッチャー機能（特定メールが来たら自動的にRPAが起動）については別記事で掲載予定