こんにちは、モバイルアプリ開発部の Yao です。 Web サイトの URL とアクセス認証情報を渡すと、サイトをクロールして API 仕様を逆生成し、Compose Multiplatform（CMP）の Android/iOS アプリを自動生成して、原サイトとのスクリーンショット比較で検収まで行う——そんなローカル AI パイプラインを作り、実際に自社サービス KINTO のステージング環境を動くアプリに変換してみました。結論から言うと、 アプリファーストはもはや予算の問題ではなく、ツールチェーンの問題 です。本記事ではパイプラインの設計、生成されたアーキテクチャ、実際のコード、原サイトとの並列比較スクリーンショットまで、その全工程を紹介します。 この記事でわかること Web サイトは、それ自体が 仕様書 （ページとフロー）+ テストデータ （実 API トラフィック）+ 受け入れ基準 （モバイルスクリーンショット）である ローカル AI パイプラインが「クロール → 仕様のリバースエンジニアリング → コード生成 → スクリーンショット照合検収」を閉ループで回す 成果：16 画面の仕様化、P0 の 4 画面をエンドツーエンド実装、API 31 オペレーション生成、 テスト 107 本全グリーン 、Android エミュレーター + iPhone シミュレーターで動作 DTO は録画済み JSON から機械的に導出し、 バックエンドを想像で補わない オフラインデモ（Recorded モード）は同一の Ktor クライアントを MockEngine に載せ替えるだけで、 プロダクションのパース経路をそのまま通る :::message alert 本記事のパイプラインは 自社サイト （認証情報と権利を自分が持つサイト）を変換するためのものです。他社サイトのスクレイピングに使うものではありません。クロール対象はすべて自社のステージング環境です。 ::: 1. なぜアプリファーストは避けられないのか まずデータから。日本では、スマートフォンでインターネットを利用する個人の割合が 2016 年の 57.9% から 2025 年には 74.3% へ上昇し、同期間に PC は 58.6% → 45.6% に下落しました（ 総務省 通信利用動向調査 ）。 利用時間の差はさらに顕著です。全年代のインターネット平均利用時間（平日）はモバイル機器が 116.8 分/日 に対してパソコンは 50.0 分/日 と 2 倍以上、休日には 133.5 分 vs 23.6 分 と 5 倍超まで開きます（ 総務省情報通信政策研究所「令和6年度 情報通信メディアの利用時間と情報行動に関する調査」 ）。 さらにスマートフォンの上では、ユーザーはブラウザではなくアプリの中にいます。米国の成人はモバイルのインターネット利用時間の 約 9 割 をアプリに費やしています（ eMarketer ）。 米国市場では、この議論は 10 年以上前に決着しています。 Instagram ：長年、Web 版は閲覧専用だった Uber ：Web クライアントはアプリを動かせない端末向けの軽量フォールバック Venmo ：2018 年に決済機能を Web サイトから丸ごと撤去 プッシュ通知はリテンションの生命線、ホーム画面のアイコンはブランドの恒久的な陣地、OS 統合（決済・生体認証・ウォレット・共有シート）は当然の前提。あちらでは、サービスにアプリが「要るかどうか」を問う人はもういません。 「PWA でいいのでは？」という反論には先に答えておきます。Web Push は確かに存在します（iOS も 16.4 からホーム画面追加済みの Web アプリに開放）が、ユーザーがまずページを手動で「インストール」する必要があり、配信の信頼性も OS 統合の深さもネイティブプッシュには遠く及びません。10 年経ってもギャップは開いたままで、リテンションの勝負は依然ネイティブ側で決まっています。 2. では、なぜ皆やっていないのか 古典的なコスト表が残酷だからです。 項目 内容 デザイン工程 コードを書く前に、Web の体験をモバイル向けに再設計 コードベース × 2 Swift と Kotlin で同じプロダクトを二度実装 チーム × 2 2 種類のスキルセットで採用 ロジックの二重化 同じバグを二度直す。同じ機能が別々の時期に出る。仕様合わせ会議が永遠に続く その上に QA 倍増 + アプリストア運用 本当の急所は v1 ではありません。 v1 以降のすべての機能が、永遠に二度ずつリリースされる ことです。この繰り返し課税が、「Web で十分」を先送りから既定方針へと硬化させてきました。 3. 計算式を変える 2 つの技術 最近 2 つのことが起き、しかも互いに増幅し合っています。 AI が労働コストを消した。 エージェントは既存の Web サイト——レンダリング済みページ、スクリーンショット、実 API トラフィック——を読み取り、その 証拠 からアプリを書けるようになりました。Web サイトはすでに仕様書でありテストデータであり受け入れ基準です。あとは誰かが読むだけ。エージェントは疲れずに読みます。 CMP が二重化コストを消した。 1 つの Kotlin コードベースから Android アプリと iOS アプリが生まれます。「すべての機能を二度リリースする」税は、規律ではなく 構造 によって消滅します。 ここで決定的なのは AI 側の形態です。魔法のプロンプト 1 発ではなく、 クロール → 仕様のリバースエンジニアリング → 仕様からコード生成 → スクリーンショットで照合検収 という パイプライン であること。以降はこれを実サイトに適用した記録ですが、その前に 2 つの設計判断——なぜ ローカル なのか、なぜ CMP なのか——を片付けます。 4. なぜ「ローカル」AI パイプラインなのか クラウド型の変換 SaaS が不可能とは言いませんが、ローカルを選んだ理由は 2 つ、どちらもモデル性能とは無関係です。 ① 権限と認証情報がローカルに留まる。 使うのは環境変数から読む認証情報だけ（gitignore 済みの .env と Playwright のログイン状態）。今回スコープに入れた 16 画面はすべて公開ページで、セッションなしでも到達できます（一部のパスには別系統のアクセス制限がかかっており、そちらの認証を渡していないので後述の 401 になります）。社外に預ける判断は重く、自分のラップトップで動くなら ただの社内ツール で済みます。 境界も明確です。オーケストレーション（今回は Claude Code）・スクリプト実行・認証情報はローカル、 モデルはクラウドなのでページ内容と API サンプルはマシンを離れます 。クロール対象は会員エリアを含まない公開相当のページに限り、API ログはマスキング済みです。 ② ローカルのモバイル開発環境にそのまま繋がる。 Xcode、Android SDK、エミュレーターが同じマシンにあるので、 クロール → 仕様 → コード生成 → ビルド → スクリーンショット検収を 1 回の実行で通せます 。同じパイプラインがエミュレーターを操作して撮影し、原サイトと並べた差分を P0/P1/P2 に分類、深刻なものはループ内で修正（iOS の操作は現状手動）。クラウドでやるなら、2 つの OS のビルドツールチェーンとデバイスファームを自前で抱えることになります。 ローカルかどうかとは独立した、パイプライン自体の方針も 2 つ。 証拠であって、推測ではない。 Playwright が収集するのは レンダリング済み の 60 ページ——HTML、スクリーンショット、 実 API トラフィック （マスキング済みサンプル）。仕様はここから導かれます。 成果物は契約、フェーズはゲート。 各フェーズは成果物を書き出してから次へ（ artifacts/ → spec/ → app/ → report/ ）。決定的に実行できる工程はエージェント自身のスクリプトで、各ゲートを人間が見ます。 :::message パイプラインの鉄則： バックエンドを想像で補わない。 トラフィックで観測されなかったフィールドは、存在しない。 ::: 5. なぜ Compose Multiplatform なのか 私は KMM の時代から KMP / CMP を追いかけてきました（ これまでに書いた記事はこちら ）。今回ターゲットに CMP を選んだ理由は 3 つです。 一貫性。 KMP のデータ層とドメイン層が 1 つで両 OS に仕えるので、iOS と Android のビジネスロジックは 乖離しようがない 。実装が 1 つ、テストスイートも 1 つだからです。 効率。 2 倍ではなく約 1 倍の工数。v1 でも、それ以降のすべての機能でも。1 チームで両ストアに出荷。 性能。 Android では——日本はさておき世界のスマホの過半です——Compose は Google が Android の標準 UI ツールキットとして提供しているものそのもので、ファーストパーティアプリと同じ ART 上、同じ描画パイプライン上で動きます。つまり CMP アプリの Android 側は、 プラットフォーム標準の外に別のレンダリング層を積みません （Compose 自身は View ツリーではなく自前のコンポジションを描画しますが、その先は Android のグラフィックススタックです）。iOS では CMP も Skia で描画します——独自エンジンを積むという点は他のクロスプラットフォームフレームワークと同じアーキテクチャ上の賭けです——が、Kotlin/Native が共有コードをマシンコードにコンパイルし、Android 側は標準ツールキットのまま。今回ベンチマークを取ったわけではないので優劣は断言しませんが、 Android 側で追加の描画層を背負わない という構造上の差は残ります。 スライドに収まらないが実務で効く理由： 既存チームには Android 側がタダ同然。 Compose はすでに Android の標準。CMP アプリの Android 半分は、いまの Android エンジニアが初日から読める慣用的なネイティブコード。Flutter は全員に Dart 乗り換えを要求します。 段階導入できる。 データ層だけの共有も、UI 全体の共有も可。既存ネイティブアプリへの埋め込みも SwiftUI/UIKit との相互運用も可。移行の道筋であって「全面書き直しか、さもなくば」ではない。 両陣営のファーストパーティが支える。 CMP は JetBrains 製。Google は KMP を公式サポートし、自社プロダクションで使用し（ Google Docs が採用済み 、Workspace 他アプリも追随中）、androidx の KMP 版（Lifecycle / ViewModel / Room / DataStore。Navigation の CMP 版は JetBrains 管理）を出荷。CMP の iOS 対応は 2025 年 5 月、1.8.0 で stable 到達 。プラットフォームの所有者と言語の生みの親が同じスタックに収斂している——次の 10 年の投資先を示すこれ以上ないシグナルです。 プラットフォーム API に直接アクセス。 expect/actual で Keychain / EncryptedSharedPreferences をネイティブに呼ぶ。待たされるプラグイン層なし。 スタック全体が 1 言語。 Kotlin で端から端まで、Ktor でバックエンドまで。採用市場もツールチェーンも成熟。 そして本記事全体を貫く理由がこれです。 :::message CMP は AI コード生成の理想的なターゲットである。 強く型付けされた単一コードベースでは、コンパイラがエージェントの全出力に対する無料の検証器になる。 kotlinx.serialization の DTO は記録済み JSON から機械的に導出できる。1 回の生成が全プラットフォームをカバーする。AI と CMP は足し算ではなく 掛け算 で効く。 ::: 6. ケーススタディ：KINTO ステージング → 動く CMP アプリ 6.1 パイプライン全体像 5 フェーズ。各フェーズは成果物を書き出してから次へ進み、フェーズ間に人間のレビューゲートがあります。 CRAWL — サイトをモバイル開発のリファレンスに変える 1 ページを 4 つの成果物として記録します。 モバイル（390×844 @2x、iPhone UA、 isMobile / hasTouch ）とデスクトップ（1440×900）のフルページスクリーンショット、 networkidle 後の レンダリング済み DOM 、そのページが実際に叩いた API、そして各エンドポイントのレスポンス実体。モバイル側が変換の正解データで、Phase 5 の検収でも同じ画像と並べます。 サイトのモバイル表示がそのまま設計書になる ので、「モバイル向けに作り直す」工程が消えます。 API はページ単位で記録します。 各エントリに「どのページが引き起こしたか」が付くので、画面 → 必要データ → エンドポイントが機械的に繋がります（見積りシミュレーションの ?step=1&memberType=corporate&term=7&bonus=0 が car-models/{carCode}/selectable-contract を叩く、という粒度で）。値を型トークンに置き換えたレスポンス形状（ float / iso8601 / url / null ）も保存し、これが DTO の型付けの根拠になります。実体サンプルはエンドポイントごとに最大 3 件、ハッシュで重複排除——複数サンプルの和集合が「どのフィールドが nullable か」を決め、同じファイルが後で MockEngine のリプレイと契約テストにも使われます。 URL をテンプレート化して画面を数えます。 パス 1 セグメントずつ、識別子らしいものを型に畳むだけです。 function templatize(pathname: string): string { return pathname.split("/").map((seg) => { if (/^\d+$/.test(seg)) return "{id}"; if (UUID_RE.test(seg)) return "{uuid}"; // CAR-0000003908 → {carCode}、GRD-… → {grdCode} if (PREFIXED_CODE_RE.test(seg)) return `{${seg.split("-")[0].toLowerCase()}Code}`; if (isOpaqueToken(seg)) return "{token}"; return seg; }).join("/") || "/"; } これで同型ページは最大 3 インスタンスだけ辿れば済み、60 ページは 58 テンプレートに整理されて、これが 16 画面の候補になります。ページごとの outlinks はナビゲーショングラフに、 img / table / iframe /繰り返しカードの構造シグネチャはコンポーネント一覧に、参照されている CSS とフォントは実ファイルとして取得してデザイントークンに回します。 Phase 2 で、サイトは機械可読な契約に変わります。 app-spec.json の 16 画面それぞれに、ソース URL・優先度・コンポーネント・必要データ・明示的なモバイル適応プランが与えられます。本件のようにサイトがすでにレスポンシブ対応済みなら、この適応設計はモバイルビューポートのクロール結果から直接導出され、 パイプラインに吸収されます 。 { "id": "Home", "priority": "P0", "components": ["TopBar", "HeroCarousel", "CarCard", "SectionHeader", ...], "dataNeeds": ["CarouselSlide", "RecommendedCarList", "CorpContent", ...], "mobileAdaptation": "Hero carousel → HorizontalPager with page indicator, 16:9 slides using the imageUrl_x2 asset. The desktop 3-column grid collapses to 2 columns ... 51 images on this page: everything below the first two sections must be lazily loaded via AsyncImage." } 念のため補足すると、この抜粋は 実ファイルのままで、正しい仕様ではありません 。 16:9 slides という横長前提が誤りで、CMS が実際に配信しているのは正方形素材でした。6.4 で触れるレターボックス不具合（実装は 16:10 の枠になっていました）の根っこは、この一行です。仕様そのものも検収ループの検査対象だということです。 API 契約は記録トラフィックから合成した OpenAPI で、そのことをファイル自身がヘッダーで宣言しています。 info: title: KINTO (staging) — reverse-engineered API description: |- Reverse-engineered from real traffic captured in artifacts/api-log.json. Nothing here is invented: every schema is the union of observed samples, a field missing from any sample is nullable. No mutation endpoints exist in this spec: the crawl observed GET traffic only. :::message この仕様は自身のカバレッジの穴も正直に記録しています。取得できたのは 60 ページで、それとは別に 12 の URL は取得できませんでした——404 が 6、アクセス制限による 401 が 6（ /kinto_one/lineup/ と SUBARU 系。4 章で触れた別系統の認証が必要なパスです）。取得できなかったものは「未取得」として仕様に残し、その画面には手を出していません。 ::: デザイントークンも同じ証拠基準です。色・タイポグラフィ・余白はサイトの 24 個の CSS ファイル（2.3MB）から出現頻度順に抽出、WCAG コントラスト比は 計算 済み。ブランドカラーがモバイルで AA を満たさない箇所には、トークンファイルがアクセシブルな代替色を用意してテキストへの使用を強制します。 6.2 生成されたアーキテクチャ Clean Architecture + MVI、すべて commonMain です。 押さえるべきポイントは 1 つだけ。 :::message Recorded モードはモック実装ではない。 第二のコードパスは存在しない。同じ生成済み ApiClient 、同じ JSON 設定、同じマッパーが両モードで動き、Koin が差し替えるのは足元の Ktor エンジンだけ。 ::: メカニズムの全文がこれです。 single<HttpClientEngine> { val config: AppConfig = get() when (config.dataMode) { DataMode.Recorded -> recordedEngine(get()) // MockEngine replaying the crawl DataMode.Live -> platformHttpEngine() // OkHttp / Darwin } } つまりオフラインデモは プロダクションのパース経路をそのまま通ります 。実ペイロードをパースできない DTO は、ライブサーバー相手とまったく同じように Recorded モードでも失敗します。 もう 1 つ、どんなコードレビューでも擁護したいディテール：リクエストに合致するサンプルがないとき、リプレイエンジンは空の 200 ではなく 501 を返します。沈黙の成功を許すと、実際には何も流れていない画面が「実装済み」に見えてしまうからです。 ビジネスロジックは 100% commonMain 。 expect/actual は本当に避けられない箇所（セキュアなトークン保存 → Keychain / EncryptedSharedPreferences、プラットフォーム HTTP エンジン）にのみ現れ、各箇所に理由がドキュメント化されています。 6.3 AI が生成した CMP コードの実物 DTO は導出されるもので、幻覚ではない。 車種カタログのエンドポイントは、CMS 風味の混沌としたネーミングのフィールドを 80 個以上持つオブジェクトを返します。ジェネレーターは記録済みサンプル全体の和集合を取ります。全サンプルに存在するフィールドは非 null、どれか 1 つでも欠けていればデフォルト値付き nullable。 @Serializable data class CarCatalogEntryDto( val name: String, // in every sample → required @SerialName("fuel_label") val fuelLabel: String? = null, // absent in some → nullable @SerialName("year3_bonus0m_taxin") val year3Bonus0mTaxin: String, // … 80+ fields, mechanically derived from recorded JSON ) このクラスを喜んで手書きする人間はいません。書く必要もありませんでした——そして、どのフィールドも 推測 されていません。判定はこの 1 行だけです。 // そのフィールドが現れたオブジェクト数 === 観測したオブジェクト数 のときだけ required const req = (s.propSeen?.get(k) ?? 0) === s.seen; パイプラインの原理はここに凝縮されています： 記録 → 全サンプルの和集合 → 型 → コード 。どの矢印もモデルの判断ではなくスクリプトの計算なので、同じ記録を入れれば同じ DTO が出ます。モデルの仕事は、この機械的な出力の上に画面を組むことだけです。 API 面は型付きで、自分の出自に正直。 生成されたクライアントの全関数が、どの記録済みリクエスト由来かをドキュメント化しています。 /** * Contract terms and bonus-payment options available for a car model * Recorded as: GET /api/price/v1/web/car-models/{carCode}/selectable-contract */ suspend fun getSelectableContract(carCode: String): ApiResult<SelectableContractDto> = runCatchingApi { client.get(hosts.main + "/api/price/v1/web/car-models/$carCode/selectable-contract") .bodyOrThrow() } すべての画面が同じ固定の MVI 形状。 sealed な Intent が入り、 StateFlow が出て、ナビゲーションはワンショットの Effect。 sealed interface HomeIntent { data object Load : HomeIntent data class CarClicked(val car: CarSummary) : HomeIntent // … } class HomeViewModel( private val getHomeFeed: GetHomeFeedUseCase, private val hosts: ApiHosts, ) : ViewModel() { private val _state = MutableStateFlow(HomeUiState()) val state: StateFlow<HomeUiState> = _state.asStateFlow() fun onIntent(intent: HomeIntent) { /* exhaustive when */ } } この均一性は美学ではなく、 画面生成を安全に並列化できる理由そのもの です。テーマ・ナビゲーショングラフ・共有コンポーネントが契約としてコミットされた後は、独立したエージェントが 1 画面ずつ引き受けられます。 契約テストが、すべてを現実に釘付けにする。 クライアントと同時に生成され、オペレーションごとに 1 本、 すべての 記録済みサンプルをプロダクションのクライアントに通します。 /** Contract terms and bonus-payment options — 3 recorded sample(s). */ @Test fun `getSelectableContract parses every recorded sample`() = runTest { val results = ContractTestEnv.forEachSample("getSelectableContract") { env -> env.api.getSelectableContract(carCode = SAMPLE_CAR_CODE) } // サンプル 0 件のまま緑になる事故を防ぐ。件数は生成時に KDoc と同じ値で埋め込まれる assertTrue(results.isNotEmpty(), "no recorded sample was replayed") assertEquals(3, results.size, "recorded sample count changed") results.forEach { assertTrue(it is ApiResult.Success, "failed to parse: $it") } } 件数のアサートは、あとから付け足した保険ではありません。 forEachSample が空リストを返すと——オペレーション ID の綴りを 1 文字間違えるだけで起こります—— forEach は何も検証せずに通ってしまい、「107 本グリーン」が何も意味しなくなります。生成器はサンプル数を知っているので、その数をテストに焼き込みます。 テスト環境は意図的にプロダクションのオブジェクトを使います——本物のクライアントファクトリ、本物の JSON 設定、本物のリプレイエンジン。スイート全体（生成契約テスト + mapper + 回帰）で 107 テスト、失敗 0 。釘付けにしているのは記録された現実なので、後日ライブ API がずれれば、次の再クロール時に同じスイートが捕まえます——本番クラッシュではなく、 赤くなったテスト として。 6.4 Web vs アプリ、並べて比較 検収ループは Android エミュレーター（API 35、1080×2400）上でアプリ自身のナビゲーションを操作し、実装済み画面を撮影します。全工程 Recorded モードなので、ライブ API には一度もリクエストを出していません（画像だけはサイトの CDN から読み込みます）。 各ペアは原サイトとセクション単位で照合します。上の 4 枚で実際に確認できるのは、ホームのヒーローコピーと CTA、PICK UP セクションの実 CMS バナー（後述の iOS スクリーンショットでは 14 枚ぶんのページインジケーターが見えます）、ラインアップの TOYOTA / LEXUS タブとカテゴリチップ、車種詳細の月額料金と納期目処、見積りのプラン選択と下部固定サマリーバーです。差分は P0/P1（コンテンツ欠落、構造・ナビゲーション破損）→ ループ内で修正、P2（ピクセルレベルの磨き込み）→ 記録、と分類処理します。 このスクリーンショットは差分も正直に写しています。ホームのヒーローは、原サイトでは背景ビジュアルに商品写真の装飾イラストが載っていますが、アプリ側はコピーと CTA だけのテキストブロックになっています。装飾素材がクロールの成果物から機械的に取り出せなかったためで、現時点では既知の差分（8 章の P2 リスト）です。 ループが実際に機能した例も 1 つ。ホームのカルーセルは当初バナーを 16:10 の枠にレターボックス表示していましたが、CMS が実際に配信しているのは 630×630 の正方形素材でした。スクリーンショット比較で発覚 → 修正 → 再撮影 → 解消。 :::message スクリーンショット内の料金・納期・キャンペーン表記は、 2026 年 8 月時点のステージング環境の内容 です。実際のサービスの料金や取扱内容は変わります。最新の情報は KINTO 公式サイト をご確認ください。 ::: そして同じコードベースが、 画面コードの追加ゼロ で 2 つ目のプラットフォームに乗ります。  6.5 正直な数字ボックス 項目 実績 仕様にリバースエンジニアリングされた画面数 16 （優先度・コンポーネント・必要データつき） 現時点でエンドツーエンド実装済みの画面数 4 ——P0 セット：Home、Lineup、CarDetail、Estimate 生成された API オペレーション数 31 、4 ホスト横断——すべて GET。ミューテーションは観測されず、想像で足してもいない テスト（契約 + mapper + 回帰） 107 本、全グリーン 動作環境 Android エミュレーター + iPhone シミュレーター——ライブ API 不使用。画像のみサイトの CDN から読み込み 検収中のライブ API への接触 一度もなし （画像取得のみ CDN にアクセス） :::message alert セキュリティに関わる 3 つの決定： DTO は記録データからのみ導出（バックエンドを想像で補わない） ミューテーション系エンドポイントは、仮に観測されても生成 + モックカバレッジまで。明示的な承認なしにライブサーバーへは撃たない 認証情報（ステージングへのアクセス認証。会員ログインではない）は gitignore 済みの環境ファイルにのみ存在し、実行時に環境変数として読み込む。コードにもモデルのコンテキストにも入らない ::: 7. AI を信頼できるものにした工学（デモの手品ではなく） モデルの能力は必要条件であって、十分条件ではありません。実際に重さを支えたのは、その周りを固める工学でした。 固定アーキテクチャという契約。 Clean Architecture + MVI、Koin、Ktor、Coil——生成の前に決定済み。エージェントは即興で形を発明せず、既知の形に中身を埋める。だから成果物はレビュー可能で、失敗は診断可能。 手作業よりスクリプト。 決定的に実行できるものはすべて、エージェントが書いて自分でデバッグするスクリプト。スクリーンショット取得スクリプトも、アプリのコードと同じくパイプラインの産物。 全コミットにゲート。 iOS ターゲットは全コミットでコンパイル必須——クロスプラットフォームの腐敗は最後ではなく数分で捕まる。 1 画面 = 1 タスク = 1 コミット。 並列化は共有契約（テーマ、ナビゲーション、コンポーネント）のコミット後にのみ解禁。 検収は事後ではなくループの内側に。 人間がレビューする前に、エージェントのスクリーンショットは原サイトのスクリーンショットと対決を済ませている。 この 5 つの根底にある姿勢は 1 つです。 :::message 生成ステップは信頼しない——包囲する。 決定的にできるもの（スクリプト、コンパイルゲート、契約テスト）はすべて決定的にし、エージェントの自己採点によるスクリーンショット比較は、すべてのゲートで人間が再レビューする。 ::: 8. 限界を、正直に 16 画面中 12 画面はまだプレースホルダー。 画面単位で線形にスケールする 作業 であって、一発の魔法ではない。 埋め込みコンテンツ （動画、地図、サードパーティウィジェット）はプレースホルダー + expect/actual の移行プランどまり。共通コードに WebView という逃げ道はない。 見た目の既知の差分（P2）。 クロールで取得できないアイコン素材とヒーローの装飾イラスト、フォントウェイトの機微。見積り画面は固定バーぶんの content inset がなく、下端のコンテンツが隠れます（6.4 のスクリーンショット）。iOS のジェスチャーの質感は実機検証が必要。 クロールが捉えるのはハッピーパス。 エラー状態、深いページネーション、パーソナライズ、A/B バリアントは記録に含まれない。 読み取り専用。 31 オペレーションすべて GET、会員エリアはスコープ外。見積りの「保存」「次へ」もアプリ内では書き込まず、選択内容を積んだ URL で原サイトに引き渡します—— ないものは想像で補わず web に戻す 。トランザクション系は次フェーズで、多くのプロダクトにとってはそちらが難しい半分。 適用範囲は自社サイトのみ。 認証情報と権利を自分が持つサイト向けの道具であって、他社プロダクトのスクレイピング道具ではない。 9. ロードマップにとっての意味 コスト曲線は反転しました。かつてアプリ化で最も高くついた部分——モバイル再デザイン（サイトがレスポンシブ版を持つ場合）、ボイラープレート、二重のデータ層、仕様合わせの維持——が、いまや最も安い部分です。人間の労力は本当に判断が要る場所に集中します：どの画面が P0 か、ブランドは何を要求するか、何を Web に残すか。 現実的なチーム像： エンジニア 1 人 + パイプライン で、両プラットフォームで動くレビュー可能なビルドに到達（本記事の範囲では P0 の 4 画面まで。残り 12 画面は同じ手順の反復です）。ネイティブのスペシャリストは最後の 10%（ジェスチャーの質感、埋め込みプレイヤー、ストア向けの磨き込み）で合流。「2 チームで 1 年」とはまったく別次元の予算会話です。 まとめ アプリファーストは、予算の問題であることをやめ、 ツールチェーンの問題 になりました。 あなたがすでに運用しているその Web サイトは、実は 3 つのものを兼ねています。 仕様書 （ページとフロー） テストデータ （実 API トラフィック） 受け入れ基準 （モバイルスクリーンショット） AI パイプラインの仕事はこの 3 つを読み込むことだけ。Compose Multiplatform の仕事は、その結果をすべての端末で動かすことだけ。 プロダクトの居場所とユーザーの居場所のあいだの距離は、いまや年単位ではなく 日単位 です。埋めにいきましょう。 参考リンク 総務省 通信利用動向調査（令和7年調査） 総務省情報通信政策研究所 令和6年度 情報通信メディアの利用時間と情報行動に関する調査（概要） eMarketer — Mobile Internet: Average Time Spent in the US, App vs. Browser JetBrains — Compose Multiplatform 1.8.0: iOS Is Stable and Production-Ready Android Developers Blog — Android's Kotlin Multiplatform announcements at Google I/O and KotlinConf 25 WebKit — Web Push for Web Apps on iOS and iPadOS

オランダに住んでいる私は、電車で過ごす時間がかなり多く、たいていその時間を使って、ビルダーコミュニティが発信している内容をチェックしています。これまでは、そのためにノートパソコンを開いたり、スマートフォンでブラウザタブを操作したりする必要がありました。2026 年 9 月 21 日週、遅れている電車を待っている間に、AWS Builder Center のモバイルアプリでトレンド記事をスクロールしたり、ワークショップを確認したりしていました。そのおかげで、空いた 20 分間をとても有効に活用できました。そこで今週は、まず Builder Center モバイルアプリをご紹介できることをうれしく思います。 AWS Builder Center が iOS と Android のモバイルアプリとして利用できるようになり 、デスクトップやウェブ以外にもエクスペリエンスが拡張されました。AWS Builder ID を使用すると、サインインした状態を複数のセッションで維持しながら、トレンド記事の閲覧、600 以上の AWS Skill Builder コースへのアクセス、無料のサンドボックス環境を使ったハンズオンワークショップの管理を、モバイルデバイスから行えます。AWS Heroes、Community Builders、User Group Leaders をフォローしたり、外出先から Builder Loft のイベントカレンダーを確認したり、購読しているトピックやコミュニティのプッシュ通知を受け取ったりすることもできます。また、このアプリは Wishlist 機能にも対応しており、製品に関するフィードバックを AWS チームへ直接送信できます。Apple App Store および Google Play Store で世界中から利用できます。 Builder Center には今週、さらに 2 つの機能が追加されました。 Polls を使うと、ホームフィードからコミュニティに質問できます。質問を入力し、2～5 個の回答候補を追加して、期限を設定すると、ユーザーが投票できます。結果は随時更新され、コメント欄で議論することもできます。投票は匿名で、作成者には集計された数とパーセンテージのみが表示されます。一方、 Zero to Shipped ハッカソンは、9 月 18 日から 10 月 2 日まで開催されています。コーディングエージェントを AWS に接続し、実際に動作するアプリケーションを構築して AWS 上で公開すると、総額 28,000 ドルの賞金プールの一部を獲得できるチャンスがあります。受賞する 5 つのプロジェクトには、それぞれ 5,000 ドル分の AWS クレジットと AWS Builder のグッズセットが贈られます。 9 月 14 日週のローンチ 9 月 21 日週は、このほかにも次のような発表がありました。 Amazon Connect Talent が一般提供を開始しました 。Amazon Connect Talent は、大規模な採用活動を行う人材獲得チーム向けの、AI を活用した採用ソリューションです。Amazon が長年培ってきた採用ノウハウを基盤としており、AI エージェントを使って構造化された音声面接を実施し、エビデンスに基づく評価を行い、候補者を一貫した基準でスコアリングします。これにより、採用担当者は最終判断に集中できます。候補者は、どのデバイスからでも 24 時間 365 日面接を受けることができ、採用担当者はスコア、文字起こし、詳細な評価結果を翌朝確認できます。AI による評価中は、候補者のすべてのデータが匿名化されます。また、各コンピテンシーは評価基準に基づいて採点され、すべてのスコアは面接中の具体的な根拠と紐付けられます。さらに、採用担当者はすべての採用について最終的な意思決定権を維持します。一般提供版には、コンピテンシーに基づく評価、適応型の質問を行う AI 主導の音声面接、ブランドに合わせてカスタマイズ可能なモバイルファーストの候補者ポータル、管理者向けオンボーディングツールが含まれています。 Amazon Corretto 27 が一般提供を開始しました 。Amazon Corretto 27 は、無償かつマルチプラットフォーム対応の OpenJDK ディストリビューションの Feature Release 版で、Linux、Windows、macOS 上でダウンロードして利用できます。サポートは 2027 年 4 月まで提供されます。主な機能として、すべての環境で G1 がデフォルトのガベージコレクターとして採用されたこと（JEP 523）、TLS 1.3 向けの耐量子ハイブリッド鍵交換（JEP 527）、より小さいメモリフットプリントを実現するコンパクトなオブジェクトヘッダー（JEP 534）、さらに Java Flight Recorder の記録データが JVM 外に出る前に機密情報を削除する、JFR のプロセス内データ編集機能（JEP 536）などがあります。また、強化されたパターンマッチング、構造化並行処理、遅延定数のプレビューも継続されており、Vector API のインキュベーター版も含まれています。 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供を開始しました。Kimi K3 は、コーディングおよびナレッジワーク向けに Amazon Bedrock で利用できるようになりました。 。Moonshot AI によると、Kimi K3 は同社で最も高性能なモデルであり、2.8 兆パラメータ規模に到達した初のオープンモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを組み合わせており、大規模なリポジトリを対象とする長時間のコーディングセッション、複数ドキュメントの分析、拡張エージェント型ワークフローに適しています。Moonshot AI は、Kimi K2 と比較してスケーリング効率が約 2.5 倍向上したとしています。Kimi K3 は、Amazon Bedrock 上のオープンウェイトモデルとして初めて明示的なプロンプトキャッシュをサポートしており、コンテキストを複数のモデル呼び出しで再利用する際のレイテンシーと入力コストの削減に役立ちます。 AWS は利用開始時のエクスペリエンスを刷新しました 。新しいプロジェクトを開始するビルダー向けに、よりシンプルな新しい体験を発表しました。最初に設定作業をすべて完了するのではなく、適切なデフォルト設定ですぐに開始できます。Google、GitHub、Apple などの既存の ID プロバイダーを使用してサインアップでき、多くの新規ユーザーではクレジットカードも不要です。また、AWS Free Tier の一環として 100 ドル分の無料クレジットが提供されます。AWS は作業を「プロジェクト」単位で整理します。プロジェクトには AWS アカウントと共有設定が含まれ、セキュリティ管理も AWS 側で適用されます。チームメンバーを招待できます。IAM ユーザーを設定する必要はありません。月間利用上限額は 20 ドルから設定でき、後から高度な AWS 機能を追加費用なし、かつ移行作業なしで有効化できます。このエクスペリエンスは、徐々に新しいお客様にも展開されています。 新しい低コストで耐久性に優れた Amazon EC2 T8i インスタンスが一般提供を開始しました 。Amazon EC2 T8i インスタンスは、Intel Xeon Scalable プロセッサ（Granite Rapids）を搭載しており、EC2 インスタンスの中でも特に低コストな選択肢の1つです。前世代の T3 インスタンスと比較して、最大 30 %優れたコストパフォーマンスを提供します。マイクロサービス、低トラフィックの Web サイト、開発・テスト環境、小規模なデータベースなど、CPU 使用率が低～中程度のワークロード向けに設計されています。T8i インスタンスは、T3 と比較してコンピューティング性能が最大 70 %向上し、ネットワーク帯域幅が最大 1.25 倍、Amazon EBS 帯域幅が最大 2.4 倍向上しています。また、同じ CPU クレジットシステムを使用しているため、T3 からのアップグレードも容易です。 AWS Elastic Beanstalk に Cluster Mode が導入されました 。AWS Elastic Beanstalk Cluster Mode は、Amazon EKS を基盤とする共有インフラストラクチャ上で複数のアプリケーションを運用するチーム向けの、新しいフルマネージドオプションです。各アプリケーションを個別に運用するのではなく、単一の運用基盤上で複数のアプリケーションを実行できます。これにより、アプリケーションの数が増えるにつれて、アプリケーションあたりのコストを削減できます。Java、.NET、Python、Node.js、PHP、Ruby、Go のソースコードをアップロードでき、Elastic Beanstalk がコンテナ化を自動的に処理します。また、必要に応じて Cloud Native Buildpacks も利用できます。Cluster Mode には、自動ロールバックを備えた本番環境向けのデプロイ戦略、イベント駆動型のオートスケーリング、AWS Secrets Manager との統合、ネイティブな OpenTelemetry オブザーバビリティ、AI を活用したトラブルシューティングが含まれています。Standard Mode と Cluster Mode の環境は、同じアプリケーション内で並行して実行できるため、チームは環境を1つずつ段階的に移行できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース お客様に役立つ可能性のある記事をさらにいくつかご紹介します。 AWS European Sovereign Cloud での構築 — 2つの新しい記事では、AWS European Sovereign Cloud 上での構築について紹介しています。これは、独自のコントロールプレーン、IAM、請求、コンソール、サービスエンドポイントを備え、独立したパーティションとして運用される欧州向けの独立したクラウドです。最初のリージョンはドイツ・ブランデンブルクに開設されます。最初の投稿では、アカウント構造とガバナンス、コードとしてのインフラストラクチャとしてのアイデンティティ、集中ロギング、データ保護、AWSパーティション全体で機能するパーティション対応ARNの構築など、 安全なランディングゾーンの設計について説明します 。2つ目は、AWS European Sovereign CloudのAmazon Bedrock次世代推論エンジンでGemma 4オープンウェイトモデルが一般公開されたことを発表しました 。データ保持やオペレーターアクセスゼロのモデルでは、推論は完全にeusc-de-east-1の範囲内にとどまります。 新しい AgentCore ランタイム：伸縮性に優れ、最適化され、一貫して高速な起動 — エージェントを実行するためのマネージドコンピューティングレイヤーである Amazon Bedrock AgentCore ランタイムの新バージョンを発表しました。新しいランタイムでは、セッション中のピーク時のメモリ量を保持し続けるのではなく、セッションがメモリを解放するとその分を回収します。そのため、料金はセッション全体を通じた実際の使用量に基づいて計算されます。また、コンテナイメージのサイズや同時実行数に関係なく、一貫したコールドスタート時間を実現します。これは、環境を一度準備してスナップショットを取得し、新しいインスタンスごとにそのスナップショットを復元することで実現しています。空のエコーエージェントを使ったテストでは、新しいランタイムは 200 MB のイメージから最大 2 GB までの約 2 秒で P75 コールドスタートを実現しました。これに対し、元のランタイムでは約 5.4 秒から 30 秒かかりました。 更新された AWS Well-Architected ストリーミングメディアレンズの紹介 — 動画ストリーミングワークロードのアーキテクチャのベストプラクティスを提供する改訂版ストリーミングメディアレンズを公開しました 。今回の改訂では、2021 年の初版から対象範囲が拡大され、5つのストリーミングシナリオをカバーしています。これには、Amazon IVS を使ったインタラクティブライブストリーミング、最大 25,000 人の同時視聴者に対応するリアルタイムストリーミング、低遅延ライブストリーミング、広告対応コンテンツの収益化、さらに強化されたビデオオンデマンドおよびライブストリーミングのガイダンスが含まれます。また、カーボンフットプリントの削減に重点を置いた新しいサステナビリティのベストプラクティス、拡張されたオブザーバビリティおよびインシデント対応フレームワーク、多層 DRM とフォレンジックウォーターマーキングを活用した高度なコンテンツ保護も追加されています。レンズホワイトペーパーとカスタムレンズがご利用いただけるようになりました。 AWS のブログ記事の詳細な一覧については、 AWS ブログ ページをご確認ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re: Invent — AWS re: Invent が 11 月 30 日から 12 月 4 日までラスベガスに戻ります。2, 200 以上のセッション時間、ロケーション、講演者がライブ配信されます。AWS re: Invent の指定席は 10 月 6 日にオープンします。 今すぐ登録して 、指定席が開いたら、チョークトーク、ワークショップ、ビルダーズセッションに参加する準備をしてください。 AWS Summits – AWS Summits は、クラウドと AI をカバーする無料の実地イベントです。re: Inventが間近に迫った今、今年のサミットは終わりに近づいています。 最後のサミットはドバイ （9月30日）にドバイワールドトレードセンターで開催され、60以上のセッション、AWSビレッジ、ハンズオンワークショップが行われます。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 レバノン （9月26日）、 マレーシア、クアラルンプール （9月26日）、 フィリピンのセブ（9月26日）、フィリピンのダバオ （9月26日）、 英国のコムサム・マンチェスター（10月1日）、 イタリア、ローマ （10月2日）などがあります。 夏は正式に終わり、9 月を迎えましたが、私のいる場所では、まだ天候が季節の移り変わりに追いついていないようです。日中は今でも例年になく暖かく、本格的な秋が訪れる前の、最後の穏やかな午後なのではないかと思っています。この陽気が続いているうちに、できるだけ満喫しようと思います。9 月 28 日週もまた新しいニュースをお届けしますので、お楽しみに。 – Esra 原文は こちら です。

はじめに 株式会社エブリーは、2026年9月11日（金）〜13日（日）に有明セントラルタワーホール＆カンファレンスで開催された iOSDC Japan 2026 に、ゴールドスポンサーとして参加しました！ 開発本部から6名のエンジニアが現地参加したので、ブースの様子や印象に残ったセッションをご紹介します。 会場の様子 3日間で70本以上のトークや LT が行われ、現地には約1,000名規模の参加者が集まる大盛況でした。 セッションやブース以外の企画も盛りだくさんで、朝9:30からドーナツサービスに始まり（おいしかった！！！）、声優さんによる館内アナウンス、スポンサーブースを回るスタンプカードビンゴ、ペンライトが揺れる LT 大会など、会場全体がお祭りムードでした。 エブリーブース エブリーは今回、ゴールドスポンサーとしてブースを出展させていただきました。ブースでは、参加型のアンケートボードとデリッシュAI の実機デモの2つを展示しました。 当日は多くの方々にブースへお立ち寄りいただき、iOS や AI 開発についてさまざまなお話を伺うことができました。足を運んでいただいた皆様、本当にありがとうございました！ アンケートボード「iOSアプリ開発、AIにどこまで任せていますか？」 「iOSアプリ開発、AIにどこまで任せていますか？」をテーマに、「開発工程のどの段階まで AI に任せているか」と「iOS エンジニアの経験年数」の2軸をシールで答えてもらう参加型のアンケートを実施しました。 3日間で皆様に、ボードいっぱいシールを貼っていただきました。 ざっくりまとめると 完全自律させている人はまだ少数 実装は AI に任せている方が大多数 最終的な確認・判断は人間が行っている エンジニア歴との相関関係は特になし という結果でした。 シールを貼っていただいた流れでリアルな開発事情を共有し合うこともできました。 特に盛り上がったのが「iOS の UI 確認や E2E テストをどう行っているか？」というテーマです。「実装は AI に任せられるけれど、動作確認はスピードやトークン消費の兼ね合いでまだ難しい…」という声が多く、現場のリアルな工夫を聞くことができました。 ドメインの複雑さや求められる品質レベル、個人開発か業務かによって AI 活用のアプローチは異なり、各社・各人が置かれた環境の中で、ベストな開発方法を模索している印象でした。ちなみに数少ない「完全自律させている」方にお話を聞くと、最後は「勇気と度胸」という声もありました。 AI 以外の話題では、iOS エンジニア歴15年以上の歴戦の猛者から、Objective-C / iPhone 3G / Xcode 3 時代の古き良きお話を聞けたのもリアルイベントならではの醍醐味でした。 デリッシュAI の実機デモ もう一つの展示は、iOS 版で新しくなった「デリッシュAI」の実機デモです。デリッシュAI は、チャットで相談するとレシピを提案してくれる『デリッシュキッチン』の AI アシスタントで、提示された選択肢をタップしていくだけで会話が進み、作りたいレシピにたどり着けます。無料プランでも1日5回までお試しいただけるので、ぜひ触ってみてください！ 今回デリッシュAI のアップデートに伴い、Generative UI というアプローチを取り入れる技術的挑戦を行いました。 仕組みとしては、サーバー側の AI エージェントがおすすめレシピといったデータだけでなく「画面構成」までを返し、アプリ側がそれを SwiftUI で動的に描画しています。AI にはあらかじめ定義した数種類のコンポーネントのみを渡し、「どれをどの順で配置するか」の判断に絞らせることで、デザインの品質を保ちながらも、対話や選択肢のバリエーションを柔軟に拡張できるようにしました。 ブースでは、Generative UI という考え方そのものはもちろん、それを実際のプロダクトへ落とし込んでいる点に対して「面白い！」という声を多数いただき、非常に嬉しかったです。 他社のスポンサーブース 3日間で他社のブースも回らせていただきました。どこも工夫を凝らした企画で、ノベルティ含め個性豊かな展示でした。全部は回りきれなかったので、立ち寄れた中から一部を紹介します。 ピクシブ さん ：デジタルシールを作成・交換できるアプリ「ぴくしーる」をデモ展示されていました。今年の iOSDC のために開発されたそうで、イベント専用にアプリを作り込まれる熱量に驚きました。 ZOZO さん ：ZOZO検定というクイズ企画でした。社内で実施されたクイズの出張版とのことで、全10問に挑戦し、正解数に応じてノベルティがもらえました。 LINEヤフー さん ：Yahoo!知恵袋を題材にした「#リアル知恵袋」。来場者が付箋で質問や回答を寄せ合う企画で、技術ネタから人生相談まで多様な交流が付箋上で生まれていました。 転職ドラフト さん ：AI 時代に評価されるエンジニアとは何か、をテーマに、来場者が付箋で意見を貼っていくアンケートボードを実施されていました。AI 時代に iOS エンジニアとして、エンジニアとして生き残っていくために何が必要か、考えさせられる内容でした。 セッション紹介 ブース運営の合間に聴講したセッションから、印象に残ったものを紹介します。 柔軟性のあるUIで、多くの環境でアプリを活躍させる 発表者: noppe さん iOSDC 開幕前日の9月10日（日本時間）に折りたたみ iPhone「iPhone Duo」が発表されたこともあり、レスポンシブな UI 設計というタイムリーなテーマに会場は超満員でした。多様な画面サイズにどう適応していくかは、これから多くの iOS エンジニアが向き合うことになる課題であり、そこにどう向き合うかのヒントとなるようなセッションでした。 noppe さんは「UI の柔軟性」を、状況を問わずに価値を提供できること、と定義していました。UI を「目的（ユーザーが実現したいこと）」「コンテキスト（ユーザーが置かれた状況）」「インターフェース（目的を実現する手段）」という3つの要素の組み合わせとして捉え直すと、コンテキストが変わったときに目的を守るにはインターフェースの側が変わるしかない。マルチプラットフォーム対応や新しい画面サイズへの対応を「利用者が少ない割にコストが高いもの」として後回しにするのではなく、同じ目的に対して複数のインターフェースを持てる状態をつくろう、というのがセッションの主張です。 では、インターフェースはコンテキストの変化にどう応じるのか。セッションではそれを「連続的な適応」と「段階的な適応」の2つに整理していました。前者は枠のサイズに合わせて伸縮させる方法、後者は境界を越えたら情報量やレイアウトの構造そのものを切り替える方法で、その境界は「同じインターフェースのまま目的を十分に達成できるか」で決める、という基準もあわせて示されていました。 単に「デザインの崩れを修正する」のではなく、「目的とコンテキストに基づいて UI を設計する」という本質ベースなアプローチの重要性を再認識させるセッションでした。連続性と段階性という捉え方も、これまで感覚的に対応していた部分を言語化していただいた印象です。iPhone Duo へのリサイズ対応に限らず、UI の設計指針として参考になる内容でした。 世界の中心でAI（App Intents）を叫ぶ - App Intents中心設計の実践ガイド 発表者: touyou（藤井 陽介）さん（株式会社グッドパッチ） App Intents はアプリの機能をアプリの外部から呼び出すための仕組みであり、2022年の登場以来、Siri、ウィジェット、Spotlight、Apple Intelligence、そして今年の Siri AI と、年々呼び出し口を広げてきました。Apple はあらゆるアプリが Siri や Apple Intelligence と統合されたエコシステムを目指しており、その手段となる App Intents の重要性は年々高まっています。これほど重要になっているなら、後から対応するのではなく最初から App Intents を設計の中心に据えてしまおう、というのが本セッションの主題「App Intents 中心設計」でした。 原則として次の3つが挙げられていました。 App Intents から設計する なるべく DRY でいること 色んな動線で使ってもらうこと 実装としては、UI も Siri も Spotlight もウィジェットも同じ Intent を通して Service を呼ぶ構成にする、アプリ内のボタンも Button(intent:) で Intent 経由にする、などというものでした。処理が一箇所にまとまり、どの内部 / 外部システムからでも同じ機能が使えるようになります。 さらに AppIntent をアプリの「動詞」、AppEntity をアプリの「名詞」と捉えれば、App Intents から設計するとは、そのアプリで「誰が何をできるのか」を動詞と名詞で棚卸しすることに他ならない、つまり App Intents 中心設計はユースケース中心設計と同じ発想に立っている、という話でした。 これまで私のなかで App Intents は「ショートカットやウィジェットの実装に必要なもの」という位置づけで、そこに iOS 27 で Siri AI が登場したためAppIntent や AppEntity を用いて音声入力によるアプリ操作をできるようにしたいな、くらいに考えていました。が、Apple が想像以上に App Intents に注力していることを知り、であれば App Intents を起点に設計するという考え方（App Intents Driven Development）も面白そうだと感じました。とはいえ、既存アプリを全面的に App Intents 中心へ移行するのは相応の工数がかかりそうなので、やるとすれば主要なユースケースをいくつか Intent として切り出すところから始めるのが、現実的なアプローチかなと思っています。 アフターイベントのお知らせ ゆめみ、フェンリル、ヤプリ、ウェルスナビ、セーフィー、エブリーの6社合同で「DroidKaigi & iOSDC After Talks Night 2026」を開催します。DroidKaigi 2026 と iOSDC Japan 2026 の合同アフターパーティーで、iOS と Android のエンジニアが同じ場に集まり、各社の LT や懇親会でプラットフォームを越えた交流ができる会です。 項目 詳細情報 開催日時 2026年10月2日（金）19:00〜21:00 開催場所 住友不動産麻布十番ビル 9F アクセンチュア・イノベーション・ハブ 東京（東京都港区三田一丁目4番1号） 開催形態 オフライン / オンライン コンテンツ 各社の Android & iOS に関するセッション / 懇親会 現地参加の申込はすでに締め切られていますが、オンライン（配信）での参加は引き続きお申し込みいただけます。当日はエブリーのメンバーも LT で登壇予定ですので、ぜひご覧ください！ 詳細やオンライン参加のお申し込みは以下からどうぞ。 yumemi.connpass.com 最後に 3日間、多くの方にブースに足を運んでいただきました。エブリーのことを知っていただくだけでなく、iOS 開発や AI 活用の話を情報交換できて、とても良い機会になりました。 これからもデリッシュキッチン、そしてエブリーをよろしくお願いします！ 最後までお読みいただき、ありがとうございました！