その2」なのですが、自身のHubot熱が急速に冷めて行っている&JAWS-UG大阪で廣山さんが発表した資料ニイヨンサンロクゴの中に記載されているPagerDutyの導入を比企のほうで進める事になり、Hubot&MYSQLで対応している部分をPagerDutyに置き換えよう熱が高まったのでその2は延期?させて貰います汗。スプレッドシートに記載しているものをマッチング)を送付してslackに通知するです。Scriptプログラミング入門を見て頂ければ処理の仕方はわかるので、上記を参照して頂ければと思いますが引っかかった部分としてgmailのAPIを個別にCALLにしてしまうと、メールが少ない場合は問題ないのですが、2も含め、cloudpackはメールの量が多いのでGASの処理可能時間を簡単に消費して24時間経たないと処理が再実行されない状況になります。msg.getBody();などは処理上仕方ないのですがmsg.markRead();GmailApp.moveMessageToTrash(msg);などメールの個別のAPIをコールせずにGmailApp.markThreadsRead(thds);GmailApp.moveThreadsToTrash(thds);などのスレッドに対するAPIで処理をまとめて行うようなAPIをコールして処理を行わないと処理が回らなくなりました。関数の先頭で、上記コードで2分間隔ぐらいで実施するように修正しました。配列でアクセスして処理時間を短くする必要があります。※処理時間は関数単位ではなく、アカウント全体での時間になるので自分が作った関数だけちょっと重いけどまあいいやなんて※感じでその場限りで対応すると後でトラブった時に詰んでしまいますので処理時間は必ずスクリプトのメニューの表示→実行トランスクリプトの※処理時間を見ながら計算してください。slackへの投稿部分ですがでslack側で出力先のチャンネル名を設定し、登録後のURLをメモしておきUrlFetchApp.fetchを使って下記コードでslackへ送信します。true;}なお現在ですがHubotによる自動化の推進は止めて、PagerDutyの運用を24365のMSP業務に合わせる為に導入設計・導入を対応していますが、PagerDutyの導入が一段落したらPagerDutyをベースに既存機能の置き換えやPagerDutyによるMSP業務の見える化を実施する予定です。うまく今あるサービスを活用し、足りない部分を実装して運用の負荷を減らしていきたいと思います。S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。cloudpack.。