ブラザー工業株式会社インタビュー：IoT プラットフォームの運用とAWS活用事例

こんにちは、プロトタイピングソリューションアーキテクトの 市川です。本日は AWS Summit 2025 や IoT@Loft にもご登壇いただいたブラザー工業株式会社で IoT プラットフォームの開発・運用に携わっていらっしゃるP&S事業 SC開発部の瀧尻 氏と 墨 氏 にお時間をいただき、イベントでは語りきれなかった Deep な話について質問させていただきました。

自己紹介

市川: 本日はよろしくお願いします。イベントの動画やスライドでも紹介されていますが、簡単にお二人の自己紹介をお願いできますでしょうか？

IaC による属人化排除とリソース管理の工夫

市川: セッションでのお話で特に印象的だったのが、IaC(CDK) によるデプロイに制限することで属人化を排除されている取り組みですが、そのように決めた経緯について教えていただけますか？

瀧尻: つくった IoT プラットフォームを様々な事業・用途で使ってもらうためには、どのように各事業に提供すればよいか、ということを考えました。手動作業が多いと導入の敷居が高くなる上、導入先ごとの差分や予期しない変更が発生してしまうおそれがあります。なるべくコマンド1つでまったく同じ構成のものを一式デプロイできることが望ましいです。そこで、CDK を利用して IoT プラットフォーム一式を構成し、配布できるようにしました。CDK には TypeScript を採用したので、AWS Lambda 関数の実装言語とも統一できました。

市川: 複数の環境を管理する場合は、IaC 化をすることで、プラットフォームごとに差分が出ずに管理ができますからね。IoT プラットフォームでは、全体のアーキテクチャのような比較的固定的な部分と、Thing や証明書のように随時増えていくリソースがあると思いますが、どの範囲を IaC で管理され、増えていくリソースはどのように管理されているのか、詳しく教えていただけますか？

瀧尻: 私たちは大きくコントロールプレーンとデータプレーンに分けて考えています。

まずコントロールプレーンについては、3つのレベルで管理を分けています。どのような用途・環境であっても共通 IoT プラットフォームとして構成を強制する部分は CDK で管理、用途ごとに調整可能にするものは CDK + 環境変数で管理、そして事業や用途・デプロイした環境ごとに運用上異なるものは CDK 外での手動設定としています。また AWS Organizations によって AWS アカウントに適用される構成設定もあります。
一方のデータプレーンについては、事業・用途・環境ごとに運用者が管理する形にしています。

具体的には、まず CCoE が管理する AWS Organizations により AWS Security Hub、Amazon GuardDuty 、AWS CloudTrail 、Amazon Inspector などの設定が AWS アカウント単位で適用されます。
IoT プラットフォームとしての IaC 管理には、 AWS IoT Core のルール、Thing に付与するポリシー、Amazon API Gateway、AWS Lambda 、Amazon DynamoDB、Amazon SNS、Amazon S3、AWS Identity and Access Management (IAM)、AWS Config、Amazon CloudWatch などの構成定義を含めています。
IaC 管理しつつ環境変数で調整可能にしているのは、ステージ名や環境識別子プレフィクス、AWS Lambda メモリサイズ、出力ログレベル設定、Amazon DynamoDB や Amazon CloudWatch Logs の TTL・保持期間、そして一部機能のオンオフ（データ基盤連携、ログへの本文ダンプ有無など）です。
IaC 管理外で手動運用としているのは、開発者のロール、Amazon Route53 ドメイン・ACM 証明書、AWS IoT Core に登録する CA 証明書、API Key などの認証情報、異常通知の通知先、外部システムが Amazon SNS トピックをサブスクライブするポリシー設定、Cost Anomaly Detection や AWS Budgets 設定、そして Amazon CloudWatch Dashboards などがあります。
データプレーンについては、運用に伴い増加・変動するものとして、Thing、Thing証明書、Device Shadow の内容、一時クレデンシャルやトークン、IoT Job、Amazon DynamoDB の内容（コマンド履歴、デバイスの通知設定など）、各種ログ、メトリクス値などがあり、これらは IaC 管理外としています。

市川: なるほど、コントロールプレーン、データプレーン で分けるという観点は良いですね。それに加えて組織という単位でも分かれるという考え方は、とても参考になります。

事業部に提供した後の運用はどのように行われているのでしょうか？

墨: 開発は SC 開発部の IoT プラットフォーム開発チームが専任で行い、定期的に社内にリリースしています。導入先の事業ごとに、リリースバージョンを指定して CDK 一式を取得(git clone) し、それぞれの IoT プラットフォーム用 AWS アカウントへデプロイします。なお、P&S 事業用の IoT プラットフォームの運用は、DevOps として私たち開発チームが担当しています。

事業ごとに開発されるサービスサーバーとの独立性を保つために、1システム – 1アカウントの原則を採用し、事業ごとの IoT プラットフォームはサービスサーバーとは別の AWS アカウントを使用します。各導入先での、IoT プラットフォームそのものの改造・変更は禁止しており、手順に従い CDK 一式をそのままデプロイしてもらっています。AWS Config ルールによりAWS CloudFormation のドリフトを検出する機構も CDK による定義に含めているため、意図せず、手動でリソースの設定などを変更してしまった場合にも気付くことができます。仕様や機能の要望があれば、IoT プラットフォーム開発チームが交流と発展のチャンスとばかりに飛びつき、対応しています。

遠隔からの印刷を実現する仕組み

市川: IoT プラットフォームで提供されている仕組みについてお聞きしたいのですが、実は我が家では御社のプリンターを利用していまして、受験を控えた子どもの問題集の印刷など、さまざまなサイズや用途の印刷に対応していて大変重宝しています。課題とかで写真の印刷も必要な時に、スマートフォンからの印刷をすることも多いのですが、反応が非常に速いのでどのような仕組みなのか気になっていました。このようなリモート印刷は IoT@Loft で紹介いただいた過疎地域の新聞印刷の取り組みでも活用されているとのことですが、他にもこの仕組みは利用されているのでしょうか？

墨: 外出先からオフィスのプリンターへレポートを送ったり、遠方に住むご家族へ写真を送ることもできます。また、LINE から印刷することもできます。ここではメール添付印刷を例に内側をご紹介します。
まず、E メールで送られたデータをリモート印刷システムが受信し、IoT プラットフォームに対してリモート印刷指示を出します。IoT プラットフォームは、プリンターがサブスクライブしている MQTT トピックへその指示を Publish します。プリンターはそれを即時受信し、印刷データをダウンロードしながら印刷します。つまり、大きな印刷データを全て受信し終える前に動きはじめます。印刷し終えると、プリンターは HTTP API により、IoT プラットフォームへ印刷結果を通知します。

このように、即時性が重要なクラウド側からデバイスへの指示伝達には、MQTT の常時接続を用いています。

市川: AWS IoT Core が対応している MQTT は常時接続のプロトコルですので、あの反応の速さにつながっているんですね。リモート印刷との相性がとても良いように思います。

大規模IoTデバイス管理におけるコスト最適化

市川: IoTのユースケースでは大量のデバイスがつながることが多いと思いますが、コストに関してなにか工夫をされていることはありますか？

墨: 一度作ったシステムをそのまま維持するのではなく、より最適化できないかという視点を持ち続けるようにしています。その一環として、AWS の SA や TAM から情報をいただいたり、AWS の News Update の RSS を Slack で購読するなどして、関係しそうな新サービス・新機能をチームでウォッチしています。

デバイスの MQTT 接続状態を正確に把握することは意外と難しく、従来はデバイスが Shadow に明示的に状態を記録し、不慮の切断時は LWT により状態を更新する、という仕組みをとっていました。しかし、この仕組みの場合は、接続状態の更新の度に様々な処理が動くため、コストの面でも気になっていました。2024/12に AWS IoT Core の接続ステータスクエリ API が発表され、これは何だろうか？とチームで調査しました。AWS IoT Core がデバイスの正確な MQTT 接続状態を提供してくれる機能であることがわかり、チームを挙げてこれを利用した内部構造への改良を行いました。コストダッシュボードでも、この仕組みを導入したタイミングの前後で、AWS IoT Core 関連コストの減少が観測できました。

市川: 新しい機能を積極的に取り込んでいただくことにより改善が進む良い事例ですね。ちなみに、コストダッシュボードとおっしゃいましたが、どのような監視をされているのでしょうか？

瀧尻: システム全体の状況は AWS CloudWatch のダッシュボードを使って監視しています。上にビジネスメトリクス的なグラフを、下にいくほどシステムメトリクスや内部状況のグラフを配置して、全体を把握してから詳細を確認できる導線をつくりました。ダッシュボードには「登録デバイス台数」「MQTT 接続台数」「各 API リクエスト数」「レイテンシ」「各 AWS Lambda 呼び出し回数」「AWS Lambda 同時実行数」「エラー・Warn 発生数」、「各ロググループ記録容量」といったメトリクスのグラフを作成し、スクラムの朝会で一通り眺める習慣になっています。複数環境・アカウントありますが、AWS CloudWatch のクロスアカウント機能で1つのアカウントのダッシュボードに集約しました。

コストダッシュボードは、各環境のコスト推移を監視するために作成した AWS CloudWatch のダッシュボードのことです。1日ごとのコストの推移、コスト上位の主要なサービスの内訳推移、デバイス1台あたりの推定年間コストの推移、月次コストの推移をグラフ化しています。こちらは AWS CloudWatch 標準のメトリクスでないため、GitHub Actions を使って各環境の AWS Cost Explorer の情報を取得し、毎晩集約アカウントの AWS CloudWatch メトリクスに登録しグラフ化しています。IoT プラットフォームの設計時に目標とした1台あたりの年間コストがありますが、各環境、稼働開始直後のデバイス数が少ない時期は、メトリクスやアラーム、Amazon GuardDuty などのほぼ固定費な要素により割高になりますが、デバイス数の増加に伴い、目標コストのレンジに収束しています。

AWS Budgets を用いたコストアラートも各環境に設定し、意図しないコスト増があってもすぐに気付けるようにしています。

市川: コストを下げる取り組みの基点として、AWS CloudWatch のダッシュボードを作って可視化を行っているのはとても良い取り組みですね。これらのダッシュボードを朝会でチェックされているとのことですが、どのような気づきがありましたか？

墨: チームで定期的に取り組んでいるコスト最適化を、本番環境にデプロイした前後のコスト変化にはいつも着目しており、下がった際には皆で喜びます。また、リージョン障害やその後の段階的な復旧の様子も、ひと目で確認できます。加えて、地域ごとのイベントや長期休暇のシーズンには、接続数やアクセス数に変化がみられます。販売のキャンペーン期間には、新規の登録台数が増加する様子も確認できます。グラフの期間を変えることで、短期と長期の変化や傾向を把握でき、しばしばチームで課題探索や将来予想にも活用しています。

さいごに

本日は貴重なお話をありがとうございました。IaC による運用の標準化から、大規模 IoT デバイスの管理、そしてコストの監視と、非常に参考になるお話をお聞かせいただきました。

特に印象的だったのは、プラットフォームを提供する側として、いかに事業部が使いやすく、かつ管理しやすい仕組みを構築されているかという点です。また、継続的な改善とコスト最適化への取組みも、多くの AWS 利用者にとって参考になる事例だと思います。

今後もブラザー工業様の IoT プラットフォームの進化に注目していきたいと思います。

参考：

AWS Summit Tokyo 2025

オフィス機器から産業機器まで多様な製品群に対応する IoT プラットフォームの構築：長期運用を目指し、アジャイルで小さく始める設計

AWSブログ

IoT@Loft #27 AI時代にIoTを語れ！【祝】AWS IoT Core 10周年レポート【開催報告＆資料公開】

ブラザー工業様登壇：未来へつなぐ IoT ～IoT でモノはもっと価値をもつ～