はじめに # GFXBenchというGPUベンチマークソフトを取り上げたシリーズの4回目です。 前回で古いAndroidバージョン対応のビルドが行えました。 今回は実際に古いAndroidバージョンで実行してベンチマークスコアを確認してみます。 ベンチマーク実行結果 # 実行までの手順は今までと変わらないので、早速結果からです。 実行するAndroid端末はAndroidバージョンが古いものを手元のコレクションから見繕ってみます。 目標は SdkVersion:'21' (Android5.0) だったのですが、手元のAndroid端末の都合上、SdkVersion:'22' (Android5.1) までとなりました。 以下、実測した結果例です。ベンチマークスコアはオフスクリーン版のfps値です。 --> Caution あくまで 「筆者の環境および測定時点における一例」 であり、同様のGPU、手順で測定された場合でも、環境によって異なる結果となる可能性がある点をご了承ください。 GPU SoC Driver version Android version T-Rex score Manhattan score Adreno 418 Snapdragon 808 OpenGL ES 3.1 V@103.0 5.1.1 34 15 Kepler GK20A Tegra K1 OpenGL ES 3.2 NVIDIA 361.00 6.0.1 66 32 Kepler GK20A Tegra K1 (Denver) OpenGL ES 3.1 NVIDIA 343.00 7.1.1 63 30 Maxwell GM20B Tegra X1 OpenGL ES 3.2 NVIDIA 361.00 8.1.0 109 59 上記 Tegra X1 のスコアは Pixel C というタブレットのものです。携帯用のためか低い値となっているようで、確か据え置き用のAndroid端末の SHIELD だと T-Rex/Manhattan = 120/60 オーダーのスコアだったかと思います。 この Tegra K1 のスコア T-Rex/Manhattan = 60/30 と Tegra X1 のスコア 同 120/60 のオーダーが長らく私の中で比較する際の基準のスコアとなっていました。 --> Information Tegra K1の SHIELDタブレット で実際にサンプル（Unreal Engine、Unity等）を動かしたりゲームをしたりの感触より。覚えやすい値だったというのもあります。 時代的に仕方ないですが、このあたりのタブレットがメモリ2GBでなく4GB積んでいれば今でも普段使いしていたのに...と惜しく思います。 スマートフォン/タブレットを見る時はまずは Tegra K1 のスコア位あれば十分と見ていたものでした。Tegra X1を超えようものならもうえらい事です（※個人の感想です）。 今回はGPU違いですがオフスクリーン版の結果なのでそのまま比較できます。ただGPUの FLOPS (Floating-point Operations Per Second) も考慮に入れるとまた違った比較が行えます。次回以降に機会があれば触れてみたいと思います。 以下スコア以外の余談です。 ビルド時に CUDA Toolkit が必要だった件ですが、Tegra K1 で無事CUDA情報が表示されていました。Android版でまったく無駄というわけでもなかったようです。例はこれ位かもですが。 今回の古いバージョン5.1.1のAndroid端末でも、Car Chase（OpenGL ES 3.1 + AEP）および Aztec Ruins（OpenGL ES 3.1）までも実行可能でした。 Androidバージョン5.0から OpenGL ES 3.1 + AEP 対応が始まっていたので確かに可能ではあるのですが、実際に描画される画、fpsも低く健気に動く姿に目頭が熱くなる思いでした。 こんな昔からきちんと頑張ってくれていたのだなと...。 おわりに # 今回は前回ビルドした古いAndroidバージョン用のGFXBenchを実際に実行してベンチマークスコアを確認しました。 この記事をお読みの方の中にも、古いAndroid端末を眠らせたままにしている方は多いかもしれません。 久しぶりに取り出して、どこまで頑張れたのかチャレンジしてみてはいかがでしょうか。 より古いAndroidバージョン、より多くのベンチマーク種類の実行、より低いスコアを出せた方が優勝！です。 ライセンスおよび免責事項 # 本記事に掲載している検証結果は、BSD 3-Clause Licenseのもとで公開されている Kishonti-Opensource/gfxbench のソフトウェアおよびアセットを利用したものです。 Original Copyright: (c) 2005–2025 Kishonti Ltd. License: BSD 3-Clause License 【免責事項】 本記事に掲載している手順、ベンチマークスコア等の測定結果は、特定の検証環境における現状のまま（AS IS）のものであり、その正確性、安全性、再現性を保証するものではありません。 本情報の利用や検証の実行により生じた直接的・間接的な損害について、筆者および株式会社豆蔵は一切の責任を負いません。内容を十分にご確認の上、ご自身の責任においてご利用ください。

本記事は 2026 年 8 月 17 日 に公開された「 Migrating from Kubernetes and Agones to Amazon GameLift Servers 」を翻訳したものです。 Kubernetes 上で動作する Agones は、専用ゲームサーバーをホストするためのオープンソースソリューションとして広く使われています。単一クラスター、単一の AWS リージョンでの構成であれば、専用ゲームサーバーのホスティング基盤として十分に機能します。しかし、グローバルな本番環境の規模になると、Agones の管理は複雑になり、ロケーションごとに複数の補助システムを構築・運用する必要が生じます。具体的には、リージョン間のセキュアな通信、プライベートネットワーク接続、ゲームセッションのアロケーター、マッチメイキング、モニタリング、そして Agones 自体が含まれます。これらはすべて、最初のゲームサーバーをデプロイする前に必要になります。 こうした運用の複雑さとそれに伴うコストから、多くの開発者はフルマネージドなグローバルゲームサーバーホスティングに Amazon GameLift Servers を選んでいます。Amazon GameLift Servers は、グローバルなゲームサーバーオーケストレーションの管理に加えて、リアルタイムの分散型サービス拒否 (DDoS) 保護とマッチメイキングを追加コストなしで組み込みで提供します。さらに、第 6 世代以降のインスタンスでは料金にデータ転送 (アウト) の料金も含まれており、総所有コストを大幅に削減できます。 Amazon GameLift Servers はまた、グローバルなゲームサーバーオーケストレーション全体に対して 99.95% の可用性 SLA を提供します。Agones ベースのソリューションでは、基盤となる Amazon Elastic Kubernetes Service (Amazon EKS) の SLA を超える部分はすべてユーザーの責任になります。 本記事では、この 2 つのホスティングオプションの違いをいくつか取り上げ、Agones ベースの実装から Amazon GameLift Servers へ移行する方法を解説します。 運用面とコスト面の主な違い 本番環境における 2 つのオプションの主な違いは、コストと運用の複雑さにあります。表 1 では、運用面を比較します。 機能 Amazon EKS 上の Agones Amazon GameLift Servers コンテナのコントロールプレーン EKS のデプロイ、バージョンアップグレード、プラグインを自分で管理 サービスに組み込み済み セッションのライフサイクル管理 各リージョンの Agones コントローラーを自分で運用 サービスに組み込み済み セッションの割り当て Agones アロケーターを自分で運用 サービスに組み込み済み グローバルなゲームサーバーコンピューティング 各リージョンの Amazon EKS クラスターを自分で管理 サービスに組み込み済み マッチメイキング 自分で管理・運用 (Open Match やその他のソリューション) サービスに組み込み済み モニタリング Amazon CloudWatch の Container Insights と、Prometheus や Grafana などのソリューション サービスに組み込み済み ( 組み込みの統合サポート により Prometheus や Grafana を追加することも可能) フリートのオートスケーリング Eviction の管理と Karpenter サービスに組み込み済み リモートロケーションのクラスターと中央バックエンド間の通信 クラスター間の証明書ベースのセキュアな通信を自分で構築 サービスに組み込み済み リージョン間でのコンテナイメージのレプリケーション 自分で管理 サービスに組み込み済み Blue/Green デプロイ 独自の継続的インテグレーション / 継続的デリバリー (CI/CD) ソリューションを自分で構築 シンプル: ゲームのバージョンを透過的に切り替え可能 ゲームセッションの DDoS 保護 各リージョンで独自のグローバルリレーソリューションを自分で管理 (Quilkin など) サービスに組み込み済み Ping エンドポイント Agones インフラの一部としてデプロイし、自分で管理 サービスに組み込み済み ゲームサーバーのコンテナイメージ 自分で管理 自分で管理 表 1 – 運用機能の比較 本番環境に対応した Agones ベースのデプロイでは、最初のゲームサーバーをデプロイする前の段階で、ホームリージョンに 30〜40 個の Pod、追加ロケーションに 20〜25 個の Pod が必要になります。これらは、モニタリング、運用、パッチ適用、セキュリティ対策、そして支払いをすべて自分で担う必要のあるサービスやツールです。 Amazon GameLift Servers ベースのデプロイでは、ビルドを一度アップロードし、グローバルフリートとその設定を定義するだけです。補助的なツールはサービスによって管理されるため、自分で管理する必要はありません。 図 1 は、グローバルな本番環境に対応した Agones ベースのデプロイと Amazon GameLift Servers のデプロイについて、アーキテクチャの違いを大まかに示したものです。 図 1 – アーキテクチャの比較 ホスティングプロバイダーを選ぶ際には、コストも同様に重要です。表 2 では、コスト要素を比較します。 コスト要素 Amazon EKS 上の Agones Amazon GameLift Servers コンテナのコントロールプレーン Amazon EKS コントロールプレーンのコスト 追加費用なし ゲームサーバーコンピューティング Amazon Elastic Compute Cloud (Amazon EC2) のコスト GameLift Servers のコンピューティングコスト (EC2 に対して約 20% の追加料金) ゲームサーバーインスタンスのデータボリューム Amazon EBS のコスト 追加費用なし ゲームサーバーからプレイヤーへのデータ転送 (アウト) データ転送 (アウト) のコスト 追加費用なし 補助サービス (オーケストレーション、割り当て、リージョン間通信、Ping エンドポイント) すべての AWS リージョンにわたるすべてのシステムの Amazon EC2 コンピューティングコスト (リージョンあたり 20 個以上の Pod) 追加費用なし DDoS 保護 各リージョンの各アベイラビリティーゾーンにおける独自のリレーレイヤーのコンピューティングコスト 追加費用なし マッチメイキング コンピューティングコスト (Open Match など) 追加費用なし モニタリング Container Insights とカスタムメトリクスのコスト (Prometheus や Grafana) 追加費用なし (Prometheus や Grafana による追加のモニタリングは追加コストで利用可能) 表 2 – コストの比較 表のとおり、コストはさまざまな要素で構成されます。中でも重要な 2 つの要素は、コンピューティングとデータ転送 (アウト) です。Amazon GameLift Servers ではデータ転送 (アウト) が料金に含まれますが、独自の Agones ソリューションではトラフィックの GB 単位で課金されます。データ転送のコストは、ゲームサーバーホスティングの総コストの最大 40〜50% を占めることもあります。コンピューティングについては、Amazon GameLift Servers では約 20% の追加料金を支払いますが、補助ツールに関する追加コストは一切かかりません。Agones ベースのソリューションでは、こうしたコストがリージョンをまたいで積み上がっていきます。Amazon GameLift Servers には、マッチメイキングと DDoS 保護が組み込まれています。いずれも、そうでなければ大きなコストになりかねない機能です。 データ転送 (アウト) や補助ツール、マッチメイキング、データボリューム、高度な DDoS 機能が料金に含まれることで、Amazon GameLift Servers はほぼすべてのシナリオで最もコスト効率の高いソリューションになります。さらに、これらの機能がマネージドであることで運用の複雑さが軽減されるため、ゲームサーバーの実装と最適化に集中できます。 ここまで Amazon GameLift Servers の運用のしやすさ、コスト、機能面での利点を説明してきましたが、それでもよりカスタムなデプロイが必要になる状況はあります。たとえば、ゲームサーバーノード間の緊密な連携を必要とする、大規模に分割された MMO ゲームなどのユースケースは、Amazon GameLift Servers での実装が難しい場合があります。単一プロセスで最大数百のゲームセッションをホストする基本的なリレーサーバーも、このサービスにとって最適とは言えないもう 1 つのユースケースです。これは、Amazon GameLift Servers がゲームセッションとゲームサーバープロセスの 1 対 1 のマッピングを前提に設計されているためです。 Agones から Amazon GameLift Servers への移行 既存の Agones ベースのソリューションから Amazon GameLift Servers に移行する際の手順は、比較的シンプルです。 Agones SDK の呼び出しを GameLift Servers SDK に置き換えるか、SDK Wrapperを使用する ゲームサーバー全体で単一のプライベートポートを使用する コンテナイメージをビルドし、 Amazon Elastic Container Registry (Amazon ECR) にプッシュする コンテナグループ定義を作成する コンテナフリートを作成する アロケーターをゲームセッションキュー (または FlexMatch) に置き換える バックエンドを更新し、接続情報の取得に Agones アロケーター API ではなく GameLift API を呼び出すようにする Agones インフラを廃止する 各手順を詳しく見ていきましょう。 ステップ 1: Agones SDK を GameLift Servers SDK に置き換えるか、SDK Wrapperを使用する Agones SDK の統合 ( SDK.Ready() 、 SDK.Shutdown() 、 SDK.Health() ) を、Amazon GameLift Servers SDK の対応するものに置き換えます。ここで重要な概念上の変化は、Agones がプル型 (サーバーまたは外部のアロケーターが Allocate() を呼び出す) であるのに対し、Amazon GameLift Servers はプッシュ型 (セッションを配置する際に、サービスが選択したゲームサーバー上の OnStartGameSession コールバックを呼び出す) である点です。WebSocket 接続を確立する InitSDK() 、 OnStartGameSession と OnProcessTerminate のコールバックハンドラーを備えた ProcessReady() 、そしてセッションの完了を通知する ProcessEnding() を実装します。Amazon GameLift Servers SDK は C++、C#、Go で利用でき、Unreal Engine と Unity 向けのプラグインも用意されています。SDK の統合とゲームセッションのライフサイクル管理の仕組みについては、ブログ記事「 Amazon GameLift Servers でローンチを成功させるためのステップ：開発フェーズ 」で詳しく解説しています。 完全な SDK 統合を行いたくない場合は、 Containers Starter Kit がサイドカーソリューションを提供します。これは、サーバービルドを変更することなく、サービスに必要な接続を自動的に実装します。 ステップ 2: ゲームサーバー全体で単一のプライベートポートを使用する Agones は、パブリックからプライベートへのポートマッピングを行いません。各 Kubernetes ノード上で、設定された範囲 (たとえば 7000〜7029) からホストポートを直接割り当てます。ゲームサーバーはそのポートにバインドし、プレイヤーは同じポート番号でノードの IP に接続します。Amazon GameLift Servers では、コンテナが内部ポートを定義し、EC2 インスタンス上の外部ポートへのマッピングはサービスが管理します。つまり、ゲームサーバーのコードは、外部に公開されるポートを認識したり気にしたりする必要がありません。Agones SDK を使って割り当てられたホストポートを検出して登録する代わりに、内部ポートにバインドし、外部へのマッピングは Amazon GameLift Servers に任せます。そしてセッションが配置されると、サービスがクライアント向けに正しい接続情報を返します。たとえば Unreal Engine で開発されたゲームであれば、すべてのサーバーがデフォルトの 7777 ポートを登録するといった形になります。 ステップ 3: コンテナイメージをビルドして Amazon ECR にプッシュする Amazon GameLift Servers のコンテナフリートは、Amazon ECR からイメージをプルします。フリートを作成する AWS リージョンと同じリージョンにプライベートな ECR リポジトリを作成し、ゲームサーバーイメージにタグを付けてプッシュします。既存の Docker file は、通常そのまま使えるか、わずかな修正で済みます。コンテナのエントリーポイントは、どちらのシステムでもゲームサーバープロセスです。前述の Containers Starter Kit は、このプロセス全体を自動化します。 ステップ 4: コンテナグループ定義を作成する コンテナグループ定義を作成して、コンテナのアーキテクチャを定義します。これは Agones の Fleet スペックと Pod テンプレートに代わるものです。ECR イメージ URI と、コンテナグループの vCPU およびメモリの上限を指定します。ロギングやモニタリング用のサポートコンテナ (サイドカー) を追加することもできます。Amazon GameLift Servers は、指定したリソース上限とインスタンスタイプに基づいて、各 EC2 インスタンスに収まるコンテナグループのレプリカ数を自動的に計算します。これは、Agones がリソースリクエストに基づいて Pod をノードに配置する方法に似ています。この手順でも、 Containers Starter Kit に要件を満たすための自動化が含まれています。 ステップ 5: コンテナフリートを作成する コンテナグループ定義、EC2 インスタンスタイプ、地理的なロケーションを指定して、マネージドコンテナフリートを作成します。この単一のリソースが、EKS クラスター、ノードプール、Agones のインストール、Helm チャート、cert-manager、そしてマルチクラスターの割り当て設定に取って代わります。Amazon GameLift Servers は、インスタンスのプロビジョニング、基盤となる OS、コンテナのデプロイ、ヘルスチェック、オートスケーリングを処理します。単一のフリートに複数のロケーションを追加すれば、複数リージョンでの展開が可能です。VPC ピアリングやクラスター間の TLS 通信は必要ありません。ホームリージョンからリモートロケーションへの通信は、サービスによって完全に管理されます。 ステップ 6: アロケーターをゲームセッションキュー (または FlexMatch) に置き換える フリートを指すゲームセッションキューを作成します。これは、独自の Director、マルチクラスターの Agones アロケーター、そしてリージョン間の TLS/VPC ピアリング接続に代わるものです。キューは、レイテンシーベースまたはロケーション優先度ベースのルーティングにより、ロケーション間での配置を処理します。組み込みのマッチメイキングが必要な場合は、チームサイズ、スキルレンジ、レイテンシー許容範囲を定義したルールセットを使って FlexMatch を設定します。それ以外の場合は、バックエンドから直接 StartGameSessionPlacement() をプレイヤーのレイテンシーデータとともに呼び出し、最適なロケーションをキューに見つけさせます。 ステップ 7: バックエンドを更新し、接続情報の取得に Agones アロケーター API ではなく GameLift API を呼び出すようにする 現在、バックエンドサービスは、ゲームサーバーの接続情報 ( GameServer.Status の IP とポート) を Agones アロケーター API に問い合わせています。これを、キューイベントの処理に置き換えます。配置が完了すると、 Amazon Simple Notification Service (Amazon SNS) の通知を受け取ります。マッチメイキングに FlexMatch を使用している場合は、FlexMatch イベントを使用することもできます。これらのイベントには、クライアントがサーバーへの接続を認証するために使用する、ゲームセッションの IP アドレス、ポート、プレイヤーセッション ID が含まれます。Amazon GameLift Servers は、オプションのプレイヤーセッション管理も提供します。これを採用することも、既存のソリューションを引き続き使用することもできます。 Event-based session placement のガイダンスには、キューを効果的に使用するためのアーキテクチャとサンプルコードが含まれています。 ステップ 8: Agones インフラを廃止する トラフィックが完全に Amazon GameLift Servers に移行され、検証が完了したら、Agones スタックを廃止します。これには、EKS クラスター (全リージョン)、VPC ピアリング接続、Open Match のデプロイ、cert-manager、Amazon ECR のレプリケーションルール、および関連するノードグループが含まれます。これにより、プラットフォームを稼働させるためだけに動いていた、ホームリージョンの 30〜40 個、各リモートリージョンの 20〜25 個のシステム Pod がなくなります。 まとめ 本記事では、Agones ベースのソリューションと Amazon GameLift Servers の主な違いを、運用とコストの観点から説明しました。運用面では、Amazon GameLift Servers に比べて Agones の方がはるかに多くの責任を負うことがわかりました。コスト面では、無料のデータ転送 (アウト)、料金に含まれる補助ツール、そして追加機能により、Amazon GameLift Servers が多くの場合によりコスト効率の高いソリューションになります。 また、Agones から Amazon GameLift Servers への移行手順も紹介しました。ほとんどのゲームでは、ゲームサーバーとゲームバックエンドのロジックに必要な変更はわずかで、シンプルかつ手間のかからないプロセスになるはずです。 マルチプレイヤーゲームサーバーのホスティングに、今すぐ Amazon GameLift Servers を使い始めましょう。ビジネスの加速をどのように支援できるかについては、AWS 担当者にお問い合わせください。 参考資料 Amazon GameLift Servers Developer Guide Free Network Bandwidth for Amazon GameLift Servers is Here Amazon GameLift Servers でローンチを成功させるためのステップ：ローンチフェーズ 著者について Juho Jantunen AWS for Games チームのワールドワイドプリンシパルソリューションアーキテクトで、ゲームバックエンドとゲームサーバーホスティングのソリューションを専門としています。ゲーム業界とクラウドテクノロジーのバックグラウンドを持ち、数百万人のプレイヤーを抱える複数のタイトルについて、AWS 上でゲームバックエンドを構築・運用してきました。 この記事は Kiro が翻訳を担当し、Solutions Architect の西坂がレビューしました。

はじめに 2026年に開催された DroidKaigi 2026 に、弊社の開発本部から 3 名のエンジニアが参加してきましたので、イベントの様子や印象に残ったセッションをご紹介します。 イベントの様子 スポンサーブース エブリーは今回、ゴールドスポンサーとしてブースを出展させていただきました！ 足を運んでいただいた皆様、本当にありがとうございました！ ブース企画 アンケートボード ブースでは、「AI時代！どこまで越境したいですか？」をテーマにした参加型のアンケートボードを実施しました！ Android開発をベースにしつつ、バックエンドやPdM、データサイエンスといった他の領域へどのようにスキルを広げていきたいか、皆様のリアルな声を聞かせていただきました！ 回答いただいた多くの皆様、ありがとうございました！最終結果はこちらです……！ 2日間でいただいたシールは、合計およそ 400 枚。領域ごとの内訳は次のようになりました。 最も票が集まったのは「Android」でしたが、Backend と iOS がほぼ同数で並び、この3つが上位を分け合う形になりました。一方で全体を見ると、Android 以外の領域に貼られたシールは全体の 8 割弱。「Android を軸に据えつつ、その外側にも手を伸ばしていきたい」という方が多数派でした。 また、シールを貼っていただきながら、こんな声も聞かせていただきました。 モバイル領域が好きなので、クロスプラットフォームでやっていきたい コードは AI が書いてくれるので、プロダクトをどうグロースさせるかを考えられるようになりたい 「AI 時代にどう越境するか」という問いに対して、技術の横方向に広げていく方向と、プロダクトづくりそのものへ踏み込んでいく方向、その両方のリアルな声を伺うことができました。 ※シール数は写真からの集計のため、概算値です。 Xフォロー＆くじ引き エブリー開発部の X アカウントをフォローいただくと、くじを1回引けるという企画も実施しました。 景品は、レンジ調理鍋・まな板・計量スプーン・しゃもじ・お箸など、普段の料理で使えるキッチングッズです。 ハズレの方にも、CTO 自らがテイスティングして選んだ「CTO ブレンド」のコーヒーをお渡ししていたので、くじを引いてくださった方には全員何かしらお持ち帰りいただけるようにしていました。 キッチングッズが当たった方に喜んでいただけて、こちらも嬉しかったです！ またXをフォローいただいた皆様、本当にありがとうございました！X ではテックブログの更新情報も発信しているので、ぜひチェックしていただけると幸いです！ ネイル体験会 会場ではプロのネイリストによるネイル体験会が開催されており体験してきました！ 流れとしては、ネイルをする指を2本選び、それぞれのデザインを決めていくというもの。ベースカラーはネイリストの方と相談しながら決められるので、ネイルに詳しくなくても安心して選ぶことができました。 デザインは、DroidKaigi のキャラクター3種類とロゴの中から好きなものをチョイスできました。指先に DroidKaigi のキャラクターがいてくれるので、ふとした拍子に目に入るたび嬉しくなります。 他社のスポンサーブース REALITY さん REALITY さんは、AEP 対応に関するアンケートを行っていました！ AEP (Apps Experience Program) は、Google が指定した要件を満たすと認定を受けられ、Google Play の新しい料金表の適用などの特典が得られるプログラムです。 Material3 は対応済み (80% 以上) の回答が多く、予想以上でした。一方でフルコンポーズ化は、まだ対応中・検討中という回答の方が多いようでした。 アーキテクチャも公開されていました。3D アバター以外の箇所はネイティブで作成されているとのことで、Unity を使っていると思っていたので驚きました。 BIZREACH さん BIZREACH さんは、AI が進化して楽になったことについてアンケートを行っていました！ テストコードの生成やエラーの原因調査のような、コーディング業務の補佐的な立ち位置に留まらず、相談相手として活用している方が多く面白かったです。 晩ご飯の献立については、他と比べると少ないようでした。 デリッシュキッチン の出番のようです！ エムスリー さん エムスリーさんは、毎年恒例の、プログラムのコードが印刷されたクリアファイルを配布されていました。 なんと去年よりコードが短くなっているとのことでした！ クリアファイルの詳細については、昨年版のものになりますが エムスリーさんのテックブログ で公開されていますので、ぜひご覧ください！ セッション紹介 なんとかする力 〜Androidエンジニアからマネージャー、さらにその先へ？〜 発表者: m.coder さん（フラー株式会社） レポート: 岡田 m.coder さんに、「目の前の課題を『なんとかする』の積み重ねが今の自分を作ってきた」という考えをもとに、キャリアとの向き合い方を語っていただいたセッションでした。 仕事のやりやすさは「何を・いつまでに・どこまでやるか」が決まっているかで大きく変わり、曖昧な箇所を明確にして不確実性を下げること自体が価値ある仕事だという話から始まりました。 印象的だったのは、役職が上がっていくにつれ、皆等しく抽象度の高い課題の解決を求められるというお話です。「なんとなくチームの雰囲気が悪い」「なんかプロジェクトの品質が悪い気がする」といった、課題かどうかすら曖昧なものを扱う必要があるという具体例に痛く納得しました。こういった漠然とした課題については、どうしても目を瞑りがちなので、自身のマインドセットを見直す必要があるなと痛感しました。 またテックリードとマネージャーは向き合い方が違うだけで、どちらも「自分以外の領域（チームや組織）をなんとかする」役割だという整理も面白かったです。 自分のキャリアを考えるうえで、抽象度の高い問題に立ち向かうべきという方針や、それを実現させる方法について非常に学びになりました。ご自身の経験から語られている箇所も多く、熱いメッセージをいただいた気持ちになりました。 また冒頭で『エンジニアリング組織論への招待』を紹介していただきました。1 章だけでも読む価値があるとのことなので、ネクストアクションとしてはこちらを読もうと思います。 あなたのANRはどこから？ — 発生する仕組みを診断し、症状別に処方する 発表者: chomi さん（NRIネットコム株式会社） レポート: 岡田 会場が皆うなずいていたセッションだったように思えます。 メインスレッドについての解説を経て、まずは誰しもが経験したことがあるであろう、メインスレッドでの I/O についてのお話から始まりました。その後起動時の重い初期化、ロック競合と進みました。 起動時の重い処理については、特にレガシーコードを触ったことがある人なら対応したことがあるのではないかと思います。本当に Application で初期化すべきかを考えるというのは ANR 以外にも、パフォーマンスの観点から非常に重要です。例として FirebaseSDK の初期化について出ましたが、こちら誰しもがなんとかならないかなと調べたことがあると勝手に思っているので面白かったです。また固有端末依存や Binder 経由の呼び出し先での ANR などについても話があり、やはり皆さん困っているのだなと共感しました。 何より構成と見せ方が完璧だったと思います。スライドは要点だけが目に入る作りで、定義や例などもとても丁寧でしたので、スッと内容が入ってきました。終章の ANR 診断フローチャートについても綺麗にまとめられており、参考になりました。 発表での再現には、公開されているサンプルアプリ DorodoroTimer を用いたそうです。デモモードをONにすると上記の ANR が実際に発生し、コード内の [ANR-xx] マーカーから問題箇所と修正版を見比べられます。 AndroidにおけるServer-Sent Events: 工場の現場を生き抜くリアルタイムストリーム 発表者: Mr. Jasveen Sandral (Industrial Android, Toyota Group Japan) レポート: 鈴木 ( @0muji4_eng ) 本講演は、AndroidにおけるServer-Sent Events（SSE）を用いたリアルタイムストリーミング実装の課題と、その具体的な解決策について論じています。 Webブラウザとは異なり、Androidの標準的なライブラリ（OkHttpなど）にはSSEの自動再接続や状態管理の機能が不足しており、通信障害時にエラーを検知できず画面のデータがフリーズしてしまうエラーケースが存在します。講演者はこの事象を "The Trap of Silence" (沈黙の罠) と呼んでいました。この問題を克服するためには、サーバーに依存するのではなく、クライアント側（Android側）で堅牢な自己回復機能を持つ独自の仕組みを設計する必要性が生じます。 具体的には、サーバーからの定期的な通信（ハートビート）を監視してタイムアウトなどの切断を検知する仕組みや、厳密な状態管理（ステートマシン）の実装が不可欠です。あわせて、再接続時には最後に受信したID（Last-Event-ID）をサーバーへ送信することで、通信断絶中のデータ欠落を補完し、安全にストリーミングを再開する必要があります。 また、頻繁な双方向通信に適したWebSocketとの技術的な比較や、端末がオフラインになった際の適切なUI制御にも触れられています。最終的に、一方向のデータ監視システムにおいてSSEを有効に活用するには、サーバー側でのバッファリングといった設計だけでなく、クライアント側がいかにして通信の切断と復帰に耐えうるアーキテクチャを構築できるかが重要であると結論付けています。 WebAssembly in Android Apps 〜 WASMはJNIの夢を見るか 発表者: keiji_ariyama さん (C-LIS CO., LTD.) レポート: 鈴木 ( @0muji4_eng ) 本講演は、Androidアプリ開発において、C++などで書かれた既存のネイティブライブラリ（OpenJPEG など）を、WebAssembly（Wasm）を用いて安全に再利用するためのアーキテクチャ設計について論じています。 背景として、運転免許証やパスポート、マイナンバーカードなどに格納されている顔写真データ（JPEG 2000形式など）を読み込む際、従来のJNI（Java Native Interface）経由の直接実行では、悪意のある細工された画像データによって深刻な脆弱性を突かれ、アプリ全体が危険にさらされるリスクがありました。 この課題に対する実践的な解決策として、講演者は Wasm と Jetpack JavaScript Engine を組み合わせた多層防御（Defense-in-Depth）を提案しています。Wasmによってシステムコールを持たないメモリ隔離環境（第一層）を構築し、さらにJS Engineによってネットワークやローカルファイルへのアクセス権限を持たない別プロセス（第二層）として実行します。これにより、万が一デコーダーの脆弱性を突かれても、被害をサンドボックス内に完全に封じ込め、アプリ本体への影響を防ぐことが可能になります。 また、実装上の大きな障壁となる プロセス間のデータ転送コスト についても詳細な検証が行われています。文字列変換によるデータ受け渡しでは、プラットフォーム側にネイティブ実装が存在する Base64 を使用するのが最もパフォーマンスが高いことが実証されました。しかし現在では、JS Engine バージョン1.1.0で導入された MessagePort API を活用することで、バイナリデータの双方向通信が可能となり、エンコードのオーバーヘッドが劇的に解消されることが解説されています。あわせて、プロセス間通信の1MB容量制限も、RAM 上のファイルディスクリプターを介することで安全に回避できる点が示されています。 結論として、Wasm はメモリコピーが発生する点（ゼロコピー不可）やコードの隠蔽化に向かない点においてJNIとトレードオフの関係にあります。しかし、外部からの信頼できないデータを処理する要件においては、過去の優れたネイティブ資産を極めて安全にモバイル環境へ持ち込むための、非常に有効なベストプラクティスであると位置づけています。 まとめ 今年は例年と違い、 AI 関連のトピックが増加した印象です！ ブースでは AI を用いた開発に関してのアンケートが多数見受けられました！ セッションでは デバイス操作はAIエージェントの時代へ。mobile-mcpを活用したAndroid UI/E2Eテストの挑戦 や AI に Inclusive UI を書かせよう — Design Rules Skill で Compose UI を作り直す のような AI を開発効率化に用いる内容から、 Google のオープンモデル Gemma を活用した最新の AI 開発のトレンド のような AI 開発そのものについてまで幅広く講演されており、時代の変化を感じました！ またブースには本当に多くの方に足を運んでいただき、たくさんの人にエブリーを知っていただけて、とても良い機会でした！ これからもデリッシュキッチン、エブリーのことをよろしくお願いいたします！ 最後に エブリーでは、ともに働く仲間を募集しています。 テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！ corp.every.tv さらに、 DroidKaigi & iOSDC After Talks Night 2026 を、ゆめみ、フェンリル、Yappli、WealthNavi、セーフィー、エブリーの6社合同で開催いたします！なお、今回はiOSDC Japan 2026のアフターパーティーも兼ねているので、AndroidエンジニアだけでなくiOSエンジニアの方も交えて、プラットフォームの垣根を越えた活発な技術交流や情報交換をお楽しみいただけます。両カンファレンスの熱気をそのままに、各社によるLTセッションや懇親会をご用意しております。 項目 詳細情報 開催日時 2026年10月2日（金） 19:00 ~ 21:00 開催場所 東京都港区三田一丁目4番1号 住友不動産麻布十番ビル 開催形態 オフライン / オンライン コンテンツ 各社のAndroid & iOSに関するセッション / 懇親会 詳細や参加登録につきましては、以下のリンクよりご確認ください。 yumemi.connpass.com 最後までお読みいただき、ありがとうございました！