「AWSアカウントが増えるたびに管理の負担が増加する」「サーバーレスのサービスをどう組み合わせれば最適なのか」――こうした課題に対し、ブラザー工業株式会社の現場で培われた実践的なノウハウが公開された。

本記事では、製品の裏側にあるクラウド基盤やデバイス開発の知見を共有するイベントシリーズ「Behind The Brother」の第1回の内容をレポートする。

---

アーカイブ動画

会社紹介、つながる製品のご紹介

登壇者プロフィール
ブラザー工業株式会社
P&S事業 SC開発部
グループ・マネジャー
矢吹 智康（やぶき・ともやす）氏

「つながる」を生み出すSC開発部の使命

まず登壇したのは、SC開発部グループ・マネジャーの矢吹氏。2004年にブラザー工業株式会社（以下「ブラザー工業」）へ入社し、プリンター製品のソフト開発や、メカ・エレキ・ソフトを束ねる開発リーダーを歴任。現在は製品を世界中とつなぐクラウド基盤を担っている。

ブラザー工業は1908年の創業、1934年の設立から長い歴史を重ねたいまも、進化を続けている企業だ。現在、売上の約8割を海外市場が占めており、主力であるプリンティング・アンド・ソリューションズ（P&S）事業が全体の6割以上の売上を支えている。

IoTが実現するブラザー工業の3つの挑戦

矢吹氏は、IoT技術を活用して「つながる」を実現している具体的なサービスを3例紹介した。

1つ目は、スマートフォンから手軽にプリントやスキャンができるアプリ「Brother Mobile Connect」である。

2つ目は「PICOCHARGE（ピコチャージ）」と呼ばれるサービスで、必要な分だけ印刷枚数をチャージするという、従来のインク購入モデルとは異なる新たなビジネスモデルを実現している。

3つ目は、プリンター以外の製品への展開として、工作機械「SPEEDIO（スピーディオ）」にIoT技術を搭載した例だ。これにより、コールセンターと容易に接続して遠隔サポートを受けられる仕組みを構築している。

これらのサービスに共通するのは、デバイスとクラウドの連携がユーザー体験の核を成しているという点である。

もっとお手軽にしませんか──マルチステージ環境のアカウント管理

登壇者プロフィール
ブラザー工業株式会社
P&S事業
SC開発部
朝倉 弘崇（あさくら・ひろたか）氏

アカウントが増えるほど、管理の辛みは増加する

続いて登壇したのは、SC開発部の朝倉氏だ。朝倉氏は2005年に入社し、PCアプリや組込みソフトの開発、プリンター製品の無線技術(NFC)を活用した機能開発に従事してきた。2023年からクラウド領域へ挑戦、AWSアカウント管理チームの立ち上げから参画し、現在は約150のアカウントを管理している。現在はセキュリティガバナンスの向上や、開発スピードを加速させるツールの導入を主務としている。

「アカウント管理の『辛み』は何でしょうか」と朝倉氏は問いかける。真っ先に挙がるのは、毎月の支払いやユーザー管理の手間だ。AWSのベストプラクティスに従い、開発・検証・本番環境を独立したアカウントに分けると、サービスが増えるたびに管理コストは3倍、6倍、9倍と膨れ上がる。「正直、頑張ることが嫌になるレベルの負担になってしまいます」と朝倉氏は現場の苦悩を代弁した。

一方で、管理を楽にするために一つのアカウントに環境を同居させれば、今度は環境間の境界が曖昧になるリスクが生じる。開発環境のリソースを削除したつもりが、実は本番環境が参照しておりサービスが停止する。そんな事故を防ぐための細かなルール整備や権限管理は、支払い管理以上に神経をすり減らす結果を招いてしまう。

管理の集約と環境分離を両立するAWSサービス

この「管理の手間」と「環境同居の事故リスク」という二つの課題を同時に解決するのが、AWS OrganizationsとAWS IAM Identity Centerを活用したマルチアカウント管理環境である。

AWS Organizationsはアカウントを階層構造で束ねて用途ごとに分離したり、支払い管理を集約したりできるサービスだ。

一方のAWS IAM Identity Centerはログインユーザーを一元管理し、シングルサインオン（SSO）を実現する。これにより、ユーザーは一つのパスワードを覚えておくだけで、アクセスポータルから各アカウントへ安全にログインできるようになる。

これらを組み合わせることで、アカウント数に比例して手間が増えるという課題を解決できる。

AWS Control Towerでマルチアカウント環境を構築する4ステップ

マルチアカウント環境の構築を始めるにあたって用意するものは、以下の通りである。

• AWSアカウント：1つ
• メールアドレス：3つ（AWSアカウント発行用2つ、ユーザー登録用1つ）
• 認証アプリをインストールしたMFAデバイス：1つ

これらを準備してAWS Control Towerの有効化からAWSアカウント発行までの4ステップを進めることで、AWS OrganizationsとAWS IAM Identity Centerを組み合わせた「マルチアカウント管理環境」が完成する。

ここで朝倉氏は、「AWS Control Tower」を用いた構築手順を4ステップで解説した。

＜ステップ1：請求情報へのアクセス設定を変更＞

ここでは、ルートユーザー以外のユーザーでも請求情報にアクセスできるよう、事前の権限有効化を行う。

• まず、AWSアカウントにルートユーザーでログインする

• マネジメントコンソールにログイン後、画面右上の「アカウント名」をクリックして「アカウント」を選択する

• 「IAMユーザーおよびロールによる請求情報へのアクセス」を編集できる画面が表示されたら、「編集」をクリックし、有効化する

これにより、ルートユーザー以外でも必要な権限があれば管理アカウントのコスト情報にアクセス可能となる。

＜ステップ2：AWS Control Towerで管理環境を構築＞

ステップ2では、AWS Control Towerを有効化し、マルチアカウント運用の土台となるリージョン設定や組織単位（OU）の自動構築を行う。

◾️前半：基本設定と組織単位（OU）の作成

• AWS Control Tower を検索し、サービス名を選択して、サービス画面へ遷移する

• AWS Control Towerのサービス画面が表示されたら、「有効化」ボタンをクリック
  ※有効化ボタンをクリックしたリージョンが「ホームリージョン」となる。一度設定を完了すると後から変更できない点に注意が必要
• ホームリージョン以外に対する設定画面が表示されたら、展開して詳細を確認する
• 「ガバナンスのための追加リージョンを選択」から、ホームリージョン以外で利用したいリージョンを追加する
  ※今回の事例では、最新サービスが最初にリリースされた「バージニア」を追加。さらにバージニアでAmazon Bedrockを利用した場合にクロスリージョン推論も扱えるように「オレゴン」も追加する
• 「リージョン拒否コントロール」を有効化し、指定したリージョン以外でのリソース操作を禁止する設定を行う
  ※ガバナンス強化のためには推奨
• 設定が完了したら「次へ」をクリックし次の設定画面へ遷移する

• 組織単位（OU）の作成画面が表示されたら、右下の「組織を作成」をクリックする
  ※この事例ではすでに「セキュリティ」と「サンドボックス」のOUを作成するように指定されている
• 「組織とOUは正常に作成されました」と表示されれば、各ユニットの作成は完了となる

◾️後半:セキュリティ関連サービス（AWS Config /AWS IAM Identity Center）の設定と環境の有効化

サービス統合の設定画面でAWS Configを有効化するには、「アグリゲーターアカウント」の作成が必要である。アグリゲーターアカウントとは、OU配下に作成された各アカウントのConfig検出結果を集約するためのものだ。

• 組織単位の設定を進めた先の画面から、AWS Config の設定画面へ進む。
  ※IAM Identity Centerを有効化するには、Configの有効化が必須。Config有効化に伴い、アカウント1つ発行につき約0.75ドルの課金が発生する
• 「アグリゲーターアカウント」右横の「新規作成」ボタンをクリック
• アグリゲーターアカウントの「新規アカウント作成」画面が表示されたら、事前に用意したメールアドレスとアグリゲーターアカウント名を入力し、「作成」をクリック。

• 「アカウントが作成されました」と表示されたら、AWS Configの有効化は完了

• AWS IAM Identity Centerは、デフォルトで有効化されているが、今回はコストを極力抑えるため、「AWS CloudTrailを無効化する」を選択（任意設定）
• 選択が完了したら「次へ」をクリックして進む

• ここでステップ2で設定してきた全内容が確認できる画面が表示される。設定内容を確認し、「AWS Control Tower の有効化」ボタンをクリック
• ここまでの設定をもとにマルチアカウント管理環境の構築をAWS Control Towerが進めてくれる。

環境の自動構築が完了するまで15〜30分待機する。

＜ステップ3：SSOユーザーの作成と権限付与＞

ステップ3では、AWS IAM Identity Centerを使用して、一つのパスワードで複数のアカウントにログインできるユーザーを作成し、管理アカウントへのアクセス権を付与する。

◾️前半：SSOユーザーの登録と有効化

• マネジメントコンソールからAWS IAM Identity Centerを選択して移動

• ナビゲーションバーの「ユーザー」から「ユーザーを追加」をクリック
• ユーザー画面が表示されたら、AWS IAM Identity Centerを管理するユーザー情報である①ユーザー名と②事前に用意した登録用メールアドレス、③表示名を設定する
• 設定が完了したら「次へ」をクリック

• 「ユーザーをグループに追加・任意」の画面が表示されるが、今回の事例ではスキップしてそのまま「次へ」をクリックする
• 確認画面が表示されたら、「ユーザーを追加」をクリックし、ユーザー作成を開始

• ユーザー作成が完了すると、登録したアドレスに招待メールが届く
• 招待メールを開き、「Accept invitation」をクリックして「新規ユーザーのサインアップ」画面を起動

• 新しいパスワードを設定し、「サインイン」画面に遷移したら、ユーザー名と設定したパスワードを入力
• 「MFAデバイスの登録」画面に遷移したら、今回は「認証アプリ」を選択し「次へ」をクリックする

ここから、流れに沿って認証アプリを設定する。

• MFA（多要素認証）デバイスの登録画面で「認証アプリ」を選択し、スマートフォンのアプリ等で発行される認証コードを入力して「MFAを割り当て」をクリック
• 「認証アプリ登録済み」と表示されたら設定完了
• 「次へ」をクリックすると、アクセスポータルが表示される。（この時点で何も表示されない状態で問題なし）

◾️後半：管理アカウントへの権限付与

• 再度、管理アカウントのマネジメントコンソールでAWS IAM Identity Center のナビゲーションバーにある「ユーザー」をクリック

• ステップ3・前半で作成したユーザー名をクリックし、ユーザーの設定画面となったら「AWSアカウント」タブを選択。

• 「AWS Organization」で、ログインを許可したいアカウントにチェックを入れる
• そのアカウント対して、「許可セット」で「AWSAdministratorAccess」など各種権限を付与する

※必要なものを複数付与することができる

• 完了したら、右下の「割り当てる」をクリックし、割り当てを実行する

• アクセスポータルを表示しているブラウザの更新ボタンをクリックすると、管理アカウントがリストに表示されるようになる

• アカウント名をクリックすると、ログイン時の権限が一覧で表示される
• 今回は、割り当てた権限「AWSAdministratorAccess」を選択。これでマネジメントコンソールへログインできることを確認する
• マネジメントコンソールの右上の表示内容から、意図通りにログインできることが確認できる

ここまでで、管理アカウントに対してAWS IAM Identity Centerでログインできるようになる。

＜ステップ4：新アカウントの発行＞

ステップ4では、マネジメントコンソールにログインした状態で、AWS Control Towerの機能を使って学習や開発に使用するための新しいAWSアカウントを発行する。

◾️前半：組織単位（OU）の登録

※これは初回のみ必要な作業で、発行先となる組織の枠組みをAWS Control Towerの管理下に置くためのもの

• マネジメントコンソールからAWS Control Towerに移動し、ナビゲーションバーの「組織」をクリック
• すると、組織を設定するための画面に遷移する

• 発行先とする組織単位（今回はSandbox OU）を選択
• 該当の組織単位に対する設定画面が表示されたら、右上の「アクション」メニューから「組織単位を登録」をクリックする

• クリック後、AWS Control Tower配下でAWSアカウントを発行することへのリスクや利用規約への同意を求める画面が表示される
• チェックボックスにチェックを入れ、「OU登録」をクリックし、実行する

• 今回の「Sandbox OU」の登録が完了し、AWS Control Tower baseline statusが「有効」になる。

ここまでで、アカウント「Sandbox OU」配下に発行する準備が整う。

◾️後半：Account FactoryによるAWSアカウントの発行

• AWS Control Towerのナビゲーションバーから「Account Factory」をクリック

• 「Account Factory」の画面が表示されたら、「アカウント作成」をクリックし、必要情報を下記の通り入力する
  • アカウントEメール：事前に用意したメールアドレス
  • アカウント名：任意の名前
  • アクセス設定：ステップ3で作成したSSOユーザーの情報を入力
  • 組織単位：ステップ4前半で有効化した情報（今回は Sandbox OU）
• 「アカウントの作成」をクリックし、発行処理を開始する

ここで、アカウント発行の結果をアクセスポータルから確認する。

• 数分後、SSOユーザーのアクセスポータルでWebブラウザを更新すると、新しく発行されたアカウントがリストに表示される

引き続きログインを進める。

• 追加されたアカウント名をクリックすると、ログイン時の権限が表示される
• 表示された権限をクリックできれば、新しい環境のマネジメントコンソールへのログインが完了

「地味な領域ですが…」エンジニアの日常に良い変化を与えられる

この4ステップで完成するのは、「お手軽版」の管理環境だ。朝倉氏はその先にある本格運用を見据え、ブラザー工業の実践例として、ルートユーザーの操作を制限するSCP（サービスコントロールポリシー）の適用や、AWS CloudTrailによるログの集約、監査アカウントでのセキュリティサービス一括有効化、管理アカウントへのSCP適用によ るルートユーザー操作の禁止といった段階的なセキュリティ強化の取り組みを紹介した。

「アカウント管理は正直、地味な領域です。でもそれを通じて、エンジニアの日常に良い変化を与えていけることに、強いやりがいを感じています」と朝倉氏は話す。自身も変わり続けること、そしてトライアンドエラーを楽しむことを大切にしていると語り、セッションを締めくくった。

サーバーレスを活用しよう──IoTプラットフォームの設計とDevOpsノウハウ

登壇者プロフィール

ブラザー工業株式会社
P&S事業
SC開発部
瀧尻 豊（たきじり・ゆたか）氏

ブラザー工業株式会社
P&S事業
SC開発部
墨 啓希（すみ・ひろき）氏

どんな事業にも使える汎用基盤を、どう設計するか

イベント後半では、瀧尻氏と墨氏の2名が登壇した。

瀧尻氏は2010年に入社。長らく業務用通信カラオケシステムの開発に従事した後、2017年ごろからクラウド開発へとシフトした。ドメイン駆動設計（DDD）を武器にシステム設計に携わり、2022年からのIoTプラットフォーム開発ではプロダクトオーナー（PO）を務めている。

一方の墨氏は2022年に新卒入社。クラウドエンジニアとして同プラットフォームの開発・運用を担当し、現在は運用フェーズにおいてPOを継承し、DevOpsによる改善を続けている。

セッションでは、まず瀧尻氏がマルチステージ・マルチリージョンのIoTプラットフォームについて紹介した。

IoTプラットフォーム開発の背景には、「どの事業や製品でも使える汎用的な基盤を作りたい」という強い思いがあった。事業によって数台規模から数千万台規模まで利用状況は異なるが、それらに一つの設計で柔軟に対応し、かつ10年以上の長期運用に耐えうる仕組みが求められたのである。

瀧尻氏は、汎用的なIoTプラットフォームの機能を定義する苦労を振り返りつつ、最終的に絞り込んだ「4つの基本機能」を紹介した。

1. デバイス認証・登録： 正当なデバイスのみの登録・接続を許可する、セキュリティの要となる機能
2. デバイスのステータスの把握： 接続状態やエラー状況を自動、あるいはデバイス自らの報告により記録する機能
3. デバイスへ指示を伝達： 橋渡しするデータはJSON形式とし、中身は各事業・製品側で自由に定義できる
4. デバイスからデータを受信： 指示への応答やログ、カウンター値などを即時に通知する

瀧尻氏は「複雑ではないと思っていただければ幸いです」と語る。シンプルさを保ちつつ、事業ごとにデプロイを分けることで、多様な製品への柔軟な展開を可能にしている。

事業に寄り添う柔軟な展開と「速度を買う」決断

これらの機能を持つプラットフォームは、事業や製品のニーズに合わせて個別にデプロイされる設計となっている。

例えば、ある事業では3つのリージョンに開発・評価・本番の3ステージを展開し、別の事業では1リージョンのみで運用するといった柔軟な構成が可能だ。これら膨大な数のアカウントは、第1部で紹介されたAWS Organizations配下の子アカウントとして統合管理されており、必要に応じて即座に作成・削除できる体制が整っている。

開発初期にチームが掲げた方針は、徹底して「速度を買う」ことだった。

当時、IoT技術に関して「素人だった」チームは、有償の座学講習でAWSの基礎を固める一方、細かなコスト削減は後回しにして「楽に素早く作れる機能」を最大限に活用することを決断した。

その結果として採用されたのが、フルサーバーレス構成である。AWS Lambdaを中心としたサーバーレスサービスは、「つくらず使う」「スケーラブル」「楽に運用」の3点いずれにも合致していたためだ。

サーバーレスサービスの組み合わせと自動スケール

ここからは、墨氏がサーバーレスサービスや組み合わせに触れながらIoTプラットフォームの構成を紹介するパートへ移る。

実際のシステム構成は、代表的なサーバーレスサービスを部品のように組み合わせて実現されている。HTTP通信にはAPI GatewayとLambda、MQTTでの双方向通信にはAWS IoT CoreとLambdaを組み合わせ、データの永続化にはAmazon DynamoDB、外部通知にはAmazon SNSをAWS SDK経由で操作する仕組みだ。

具体的な処理フローとして、例えば「デバイス登録」では、デバイスが提示した証明書をIoT Coreが検証し、正規のデバイスであれば後段のLambdaが起動して情報を記録する。また「指示伝達」においては、サービスサーバーからのAPIリクエストをAPI Gatewayが受け、IoT CoreからデバイスへMQTTで即時に指示を届ける。

このプラットフォームの構成図には、ロードバランサーなどの負荷分散装置が存在しない。API GatewayやIoT Coreといったサーバーレスサービスが内部で自動的にスケーリングするため、数千万台規模のデバイス接続にも対応できる設計となっている。

サーバーレス活用時に知っておくべきポイント

しかし、「こんなにすばらしいサーバーレスサービス」にも特有の注意点が存在するという。瀧尻氏は、開発・運用のなかで直面した実体験を3つ紹介した。

1. サービスクォータ（利用上限）
ある日、本番環境でエラーが多発。調査の結果、原因はスロットリングであった。アカウントの作成時期やリージョンによって、マネジメントコンソール上では確認できない個別のクォータ上限が設定されているケースがある。

「本番環境に限って、見えていた値より小さな上限が設定されていた」と瀧尻氏は語り、重要な環境については事前にサポートへ現在のクォータ値を問い合わせておくことを推奨した。

2. コスト把握
一定の利用量にもかかわらず、月初にIoT Coreのコストが増大し、逆にLambdaのコストが下がる現象に遭遇した。

これは、利用量に応じて単価が下がる段階的料金設定の「月初リセット」と、毎月1日に復活する「無料枠」が原因であった。コストエクスプローラーの表示方法を変えることで、この複雑な挙動を把握できるという。

3. 結果整合性
デバイス登録直後にその情報を検索しても、ヒットしたりしなかったりする現象に悩まされた。「当時は結果整合性を知らず、この現象を逆に楽しんだ」と瀧尻氏は振り返る。

IoT CoreのフリートインデックスやDynamoDBのセカンダリーインデックスなど、結果整合性を伴う機能については「無理にねじ伏せようとせず、結果整合性を前提とした仕様として公開すべき」と、設計思想としての割り切りの重要性を語った。

こうした困難に直面した際の強い味方として、瀧尻氏はAWSの有償技術サポートとAWSアカウントチームの2つを紹介した。

技術サポートは機能の使い方から仕様の理解、トラブルシュートまで確実な対応を提供してくれる有用な存在である。瀧尻氏は「サポートへの問い合わせ内容と回答を記録してチーム内に共有すると、大きな学びになる」とその付加価値もあることを強調した。

また、企業ごとに付くAWSアカウントチームのソリューションアーキテクトも、アーキテクチャの相談や事例ベースのアドバイスをくれる存在だ。窓口が不明な場合でも、総合窓口やセミナー、イベント参加をきっかけに相談先を確保できるため、瀧尻氏は「使える支援はどんどん使い、サーバーレスのメリットを最大化させてほしい」と話す。

10年以上の長期運用を支えるコード管理と監視の仕組み

続いて墨氏は、長期にわたって基盤を保守・改良し続けるための実践知を共有した。

まず、開発初期から意識しておくべき2つのポイントが挙げられた。

• 拡張余地を確認しつつ、ミニマムで作る
  AWSのサービスは多機能であり、一つの目的に対して複数の実現手段が存在する。その中で、まずは実現方法を1つに絞り、シンプルに構築することを優先した。これは素早い開発につながるだけでなく、利用者が迷わずに済む「筋の通った設計」を実現するためでもある

• スタイルの統一された実装
  IoTプラットフォームは「レイヤードアーキテクチャ」で実装されており、機能ごとの実装スタイルの差を最小限に抑えている。開発初期のコードは他の箇所へコピーされて広がりやすいため、初期段階から命名規則やコード構造の規則をチーム内で統一しておくことが、将来の保守性を高める鍵となる

長期にわたって保守・改良し続けるための実践として、AWS CDKを用いたIaC管理（※）についても触れられた。

◾️運用体制にマッチしたIaC管理
マルチアカウント・マルチリージョン環境において、同一の環境を容易に再構築できるIaCは相性が良い。ただし、「すべてをコード化すべき」という考えに固執せず、APIキーの設定などはあえてマネジメントコンソール等での手動設定に残している。全環境で共通の要素、デプロイ時に指定したい要素、そして独立して変更したい要素を整理し、自分たちの運用体制にマッチした管理を実現することが推奨された。

◾️意思決定の背景を残すADRの重要性
さらに、ドキュメント作成においてはADR（アーキテクチャ決定記録）の整備を重視している。仕様の最終結果だけでなく、その構成や実装に至った「理由」を記録しておくことで、後任の担当者や将来の自分が自信を持って変更を加えられるようになる。理由が不明なものは、自信をもって変更できないからだ。この記録は、後のDevOpsによる改善判断においても極めて大きな役割を果たすことになる。

※IaC（Infrastructure as Code）管理：クラウドリソースの構成定義をコードで管理する方法

運用の手間を最小化するDevOpsの実践

稼働後のDevOpsにおいては、主に以下4つの取り組みを実践している。

1. 稼働状況の監視と可視化
   Amazon CloudWatchアラームを活用し、システムエラーやログ内のワーニングをSlackの専用チャンネルへ通知している。重要な通知を見逃さないよう、スタンプによるアクション管理やスレッドでの状況共有といった工夫が凝らされている。

2. 定常保守
   フルサーバーレスであっても、Lambdaのランタイムやパッケージの更新作業は不可欠である。「サーバーレスは一度作ったら何もしなくて良くなるものではなく、管理する範囲を狭くできるものだ」と墨氏は釘を刺す。

3. AWSアップデート情報の収集
   RSSで購読した最新情報をSlackへ自動通知し、チームに関係する新機能があれば随時調査・検証を行っている。

4. ユースケースの継続的な収集
   ミニマムで開発を始めたからこそ、実際の利用者の課題や要望の変化を継続的に把握し、改良し続ける姿勢を大切にしている。

可視化と自動化による運用の高度化

可視化の面では、クロスアカウントクロスリージョンダッシュボードを活用し、一つの画面で全環境のビジネスメトリクス（デバイス接続数等）やシステムメトリクスを一元的に監視している。これにより、複数のアカウントを切り替える手間を排除し、朝会などでの迅速な状況確認を可能にした。

また、GitHub Actionsによる自動化も徹底されている。プッシュ時の構文チェックや単体テスト、マージ時の開発環境への自動デプロイ、さらには夜間のE2Eテストまでが自動化されている。本番環境へのリリースも数クリックで完了する体制が整えられた。特筆すべきは、料金などのメトリクス化されていない情報もGitHub Actionsで収集し、カスタムメトリクスとして記録してダッシュボードに表示させている点である。

最後に墨氏は「日々新しい発見をしながら、主体的に改善・改良していける活動はものすごくおもしろく、それが個々の成長にも直結している。自分でもやってみたいと思えるポイントが一つでも見つかっていれば嬉しい」と話し、セッションを締めくくった。

【Q&Aセッション】

Q&Aセッションでは、登壇者4名がイベント参加者から投げかけられた質問に回答した。

Q. ブラザーさんの商品は海外でも販売されていますが、ホームリージョンはどのように決められているのでしょうか？

朝倉氏：ホームリージョンはガバナンスに関するログ情報やAWS IAM Identity Centerのユーザー情報など、組織の情報を管理する場所です。弊社は日本法人ですので、社内のセキュリティルールに準拠して国内に設置しています。一方、ワールドワイドでビジネスを展開するシステムについては、管理対象リージョンにアメリカのバージニアやオレゴン、ヨーロッパのリージョンを追加する形で対応しています。社内の情報は国内、ビジネスの展開先については管理対象リージョンで対応するという使い分けです。

Q. クラウドと機器の間での通信がJSONで中身は自由とのことでしたが、クラウドでデータを受信後は形式を整えますか？また、さまざまなJSONデータがあることによる課題はありますか？

瀧尻氏：IoT基盤としてはコードが1つなので、ある事業のコマンド指示の中身をバリデーションしてしまうと、別の事業のJSONが来たときに対応できなくなります。そのため、IoT基盤としては基本的に「土管」として素通しします。JSONであるというチェックはしますが、その中身のバリデーションはデバイスやサービスサーバー側で行ってもらう形で統一しています。

Q. 本日の手順書はかなり詳細に記録されていますが、社内教育でもこの粒度でドキュメントを管理しているのですか？

朝倉氏：アカウント管理パートについては、本日のイベント専用に作成しました。なぜここまで詳しくしたかというと、3年前の自分たちが欲しかった情報をお伝えしているからです。これからアカウント管理を始めたいけれど最初の一歩が踏み出せないという方に、壁を乗り越えるきっかけになればと思い、かなり頑張って作りました。

墨氏：開発の方では、結構細かい粒度で手順を書いています。長期間システムを運用していくとメンバーも入れ替わっていきます。人が入れ替わっても問題なく動き続けるためには、運用作業が自動化されているか、あるいはドキュメントがしっかりしているかのどちらかだと考えています。自動化できていない作業については、誰でもできる手順書があることが望ましいと思っています。

Q. 結果整合性があることで、実装方法を変えた機能や、実装を断念したケースはありますか？

瀧尻氏：最初、フリートインデックスを使ってデバイスのオンライン状態を取得できる機能を作って公開しました。しかし、「取れたり取れなかったりする」「反映遅延が何分か教えて」と言われ、調べたところ「いつかは反映されるが、いつかは保証できない」と分かりました。そこでフリートインデックスを使った実装を断念し、IoT Coreのデバイスシャドウに状態を記録して単一デバイスの情報として返す方式に変更しました。その後、IoT Core側で接続状態のクエリ機能が新たに追加されたため、内部的にはそちらを使うように変更しています。デバイスの存在確認など他の機能でも当初の想定通りにいかないケースがありましたが、リトライを組み込んだり結果整合性のない機能に置き換えたりして対応してきました。

Q. 最後に、このイベントに参加してくださった皆さんにメッセージをお願いします。

矢吹氏：このイベントではブラザー工業で進めている「つなぐ技術」を紹介しました。せっかくの機会なので「皆さんに何か持ち帰ってほしい」という想いで準備して参りました。これをきっかけに弊社に少しでも興味を持っていただけると嬉しく思います。今後もイベントを企画していますので、次回の参加もお待ちしています。

_

ブラザー工業株式会社
https://www.brother.co.jp/

文＝宮口 佑香（パーソルイノベーション）
※所属組織および取材内容は2026年3月時点の情報です。