Webやアプリケーション開発において「アクセシビリティ」や「ユーザー補助」という言葉を聞くと、皆さんはどう感じるでしょうか。「重要だとはわかっているけれど、開発コストがかかる」「一部のユーザーのための特別な対応」といったイメージを持つ方も少なくないかもしれません。 しかし、技術的な観点からアクセシビリティの構造を紐解くと、そこにはエンジニアにとっても合理的で、美しいアーキテクチャが存在します。 結論から言うと、アクセシビリティ対応とは「ユーザーのための特別なUIをゼロから作る」ことではありません。 「ユーザーが利用している環境（OSやブラウザなど）」と「アプリケーション」が正しくデータを連携し、歩み寄ることで初めて成立する仕組み なのです。 今回は、アクセシビリティのはじめの一歩として「環境とアプリの握手」について解説します。 ユーザーを支える強力な武器：「環境」の支援技術 アクセシビリティを考える上で大前提となるのが、デジタル環境へのアクセスを支える仕組みの大半は「環境側」にすでに用意されている、ということです。 現代のOS（iOS、Android、Windows、macOS）やWebブラウザには、ユーザーの多様な特性（視覚、聴覚、運動機能、認知など）を補助する高度な機能が標準搭載されています。これらは大きく2つのレイヤーに分けられます。 ユーザーエージェント（ブラウザなど）： ズーム、文字サイズへの対応、キーボード操作など、表示や操作を調整する機能。 支援技術（Assistive Technology）： スクリーンリーダー（VoiceOver / TalkBack 等）、スイッチコントロールなど、OSのAPIを通じてデバイスの操作を直接的に補助する機能。 ユーザーは自身の状況に合わせて、これらの機能をONにしたり設定を調整したりして、Webにアクセスしています。つまり、ユーザーから差し出された「握手のための手」は、すでに環境側に用意されているのです。 ただし、アクセシビリティのすべてを環境側が自動で担ってくれるわけではありません。アプリケーション自身も、十分なコントラストの確保、フォーカス順序の管理、適切な見出し構造などを責任を持って設計し、環境側と正しく連動する必要があります。 アプリケーション側の役割：情報のリレーと握手 ユーザーがスクリーンリーダーをONにしていれば、どんなWebサイトでも完璧に音声で操作できるのでしょうか？ 答えは「No」です。 どんなに環境側（ブラウザや支援技術）が優秀でも、アプリケーション側が「今、画面に何が表示されていて、どのボタンが押せるのか」という意味情報（セマンティクス）を伝えていなければ、支援技術は正しく機能しません。 Webの世界では、書いたコードは以下のように情報を伝達してユーザーに届きます。 1. Webアプリ (HTML / CSS / JavaScript)       ↓ 2. ブラウザ (ユーザーエージェント) ※DOMツリーと同時に「アクセシビリティツリー」を構築       ↓ 3. OSのアクセシビリティAPI       ↓ 4. 支援技術 (スクリーンリーダーなど)       ↓ 5. ユーザー ブラウザは画面を描画するDOMツリーとは別に、支援技術向けの裏側のデータ構造である「アクセシビリティツリー」を生成します。（※Chrome DevToolsの「Accessibility（ユーザー補助）」タブなどで実際に確認することができます）。 HTMLは、このアクセシビリティツリーを正しく構築するための「指示書」なのです。このリレーを途切れさせず、環境と正しく接続（握手）することこそが、エンジニアの役割です。 Microsoftサイトのアクセシビリティツリー Webフロントエンドにおける「歩み寄り」の具体例 具体的に「環境と握手する」とはどういうことか、実務でやりがちなアンチパターンと改善例を見てみましょう。 1. 適切なHTMLタグを使う（セマンティクスの伝達） NG： <div onClick={submit}>送信</div> 視覚的にはボタンに見えても、ブラウザには「buttonとしての役割（Role）」が伝わりません。その結果、スクリーンリーダーでボタンとして認識されないだけでなく、Tabキーによる「フォーカス移動」や、Enter/Spaceキーによる「標準的なキーボード操作」が不可能になります。 OK： <button onClick={submit}>送信</button> <button>タグを使うことで、ブラウザが持つ標準的なセマンティクスとキーボード操作モデルを利用でき、環境との握手がスムーズに成立します。 2. フォームの入力欄にラベルを紐付ける（関係性の伝達） NG： <span>お名前：</span><input type="text" /> 視覚的には「名前の入力欄」ですが、支援技術が入力欄にフォーカスした際、単に「テキスト、編集テキスト」としか読み上げられず、何を入力すべきか分かりません。 OK： <label for="name">お名前：</label><input type="text" id="name" /> <label> の for 属性と <input> の id を紐付けることで「これはお名前の入力欄だ」と明確に伝わります。さらに、ラベルの文字をクリックしても入力欄にフォーカスが当たるようになり、マウスユーザーの操作性も向上します。 3. アイコンボタンに意味を持たせる（ただしARIAは計画的に） NG： <button><img src="search-icon.png" /></button> 支援技術は何のボタンか判定できません。 OK： <button aria-label="検索"><img src="search-icon.png" alt="" /></button> aria-label などを付与することで、情報を補うことができます。 【注意】 ただし、W3Cには「ARIAの第一原則（The First Rule of ARIA Use）」というものがあります。それは「標準HTMLで表現できる場合は、まず標準HTMLを使う」というルールです。ARIAは万能薬ではなく、誤用すると支援技術を混乱させるため、あくまでHTMLの補助として利用しましょう。 4. フォーカスを見えるようにする（キーボード操作の担保） NG： *:focus { outline: none; } デザイン上の理由でフォーカスリング（枠線）を消してしまうと、マウスを使わずキーボードで操作しているユーザーは「今、画面のどこにいるのか」が全く分からなくなります。 OK： :focus-visible 擬似クラスなどを活用し、キーボード操作時のみフォーカスリングを表示するようスタイリングする。環境からのアクセス経路を視覚的に遮断しないことが重要です。 「環境」と「アプリ」の機能がオーバーラップする領域 ここで一つ、実践的な観点を付け加えます。OSやブラウザの標準機能と、アプリケーションが独自に提供する機能は、 役割がオーバーラップ（重複）している領域 が存在します。 例えば、自治体のサイトなどでよく見かける「文字サイズ変更（大・中・小）」のボタンです。 文字の拡大は、本来ブラウザのズーム機能やOSの設定で行えます。しかし、すべてのユーザーが環境の設定方法に習熟しているわけではないため、アプリ側があえて独自のUIを提供し、環境側の機能を「場合によっては補完」しているのです。 ここで誤解してはいけないのは、「アプリ側で独自にボタンを作ったから、環境側の設定は無視していい」というわけではないことです。独自の文字拡大ボタンを作ったからといって、ブラウザの標準ズーム機能を使った時にレイアウトが崩れてしまっては本末転倒です。 重要なのは、アクセシビリティ機能を追加すること以上に、既存の環境の機能を「壊さない」こと。ユーザーがブラウザの標準ズーム機能を使ったとしても、レイアウトが破綻せずコンテンツが利用できるような、Web本来の堅牢でレスポンシブな設計が求められます。 まとめ：情報を「標準的な形」で公開しよう アクセシビリティ対応の核心は、「アプリケーションが持つ情報を、OSや支援技術が理解できる標準的な形で公開すること」に尽きます。 ユーザーが伸ばした手（支援技術やブラウザの設定）に対して、アプリケーション側からもしっかりと手を握り返す（データを正しく渡す）。これが、エンジニアにおけるアクセシビリティ対応の真髄です。 明日からの開発で、ぜひ以下の「最初の一歩」を試してみてください。 キーボードだけで操作してみる： マウスを置き、Tab キーと Enter / Space キーだけで、自分が作ったアプリの主要な機能が使えるか確認する。 ツールで監査してみる： ChromeのLighthouseや、axe DevToolsなどのブラウザ拡張機能を使って、自分のローカル環境のコードをチェックしてみる。 「環境」と「アプリ」のデータ連携が結実したとき、書いたコードはより強固で、本当に多くの人に届くソフトウェアになります。ぜひ「ブラウザやOSとの対話」を意識した実装を盛り込んでみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post アクセシビリティは「環境」と「アプリ」の握手である 〜Webの構造から紐解くエンジニアの役割〜 first appeared on SIOS Tech Lab .

はじめに # GFXBenchというGPUベンチマークソフトを取り上げたシリーズの3回目です。 前回までで新しいAndroidバージョンで実行が行えました。 今回からは古いAndroidバージョンでの実行を試みてみます。 ソースコード準備 # 前回までのAPKファイルを古いAndroidバージョンで実行するとエラーが発生し（詳細は後述）ベンチマーク実行不可でした。 エラー原因からソースコードを修正して回避出来ないか検討してみます。 修正方針 # 修正方針も色々あるかと思いますが、今回の前提としてAndroid SDKおよびNDKバージョン、Java側の設定は変更しないで頑張ってみる事にしました。 以下前回までの設定を再掲します。 Path Version Description Location build-tools;35.0.0 35.0.0 Android SDK Build-Tools 35 build-tools/35.0.0 cmdline-tools;latest 16.0 Android SDK Command-line Tools (latest) cmdline-tools/latest ndk;28.0.12674087 28.0.12674087 rc2 NDK (Side by side) 28.0.12674087 ndk/28.0.12674087 platform-tools 35.0.2 Android SDK Platform-Tools platform-tools platforms;android-35 1 Android SDK Platform 35 platforms/android-35 platformBuildVersionCode='35' compileSdkVersion='35' minSdkVersion:'21' targetSdkVersion:'35' これら設定の元で修正案を考えていきます。 実行時のエラーと修正案 # 最初は実行時のエラーの理由が訳わからなかったのですが、整理すると以下の3つの様でした。 Androidバージョン 8 → 7 の壁 commons-io が java.nio に依存していてそれで NoSuchMethodError が実行時に発生しました。 E AndroidRuntime: Caused by: java.lang.NoSuchMethodError: No virtual method toPath()Ljava/nio/file/Path; in class Ljava/io/File; or its super classes (declaration of 'java.io.File' appears in /system/framework/core-libart.jar) E AndroidRuntime: at org.apache.commons.io.IOCase$$ExternalSyntheticApiModelOutline0.m(D8$$SyntheticClass:0) ・・・ Androidバージョンによる java.nio サポート可否が原因ですが、そもそものところで java.nio を使っていないバージョンにしてみます。 Apache Commons IO のDependencies情報あたりからバージョンを 2.6 まで下げればいい様なのでそうしてみます。 Androidバージョン 7 → 6 の壁 cannot locate symbole "__fread_chk" という問題が実行時に発生しました。 W Runner : Failed to preload lib: dlopen failed: cannot locate symbol "__fread_chk" referenced by "/data/app/net.kishonti.gfxbench.v50105.corporate-1/lib/arm/libgfxbench40_gl.so"... E (Error) ではなく W (Warning) 表記なので最初は見過ごしていたのですが、これがクリティカルでした。 これも何かネイティブ側のライブラリバージョンを下げる方法があればいいと思われます。探すと ANDROID_NATIVE_API_LEVEL という定義が見つかったので、元の値 24 (Android7.0) から 21 (Android5.0) と下げてみます。 Androidバージョン 6 → 5 の壁 requestPermissions() で NoSuchMethodError が実行時に発生しました。 E/AndroidRuntime(22812): java.lang.NoSuchMethodError: No virtual method requestPermissions([Ljava/lang/String;I)V in class Lnet/kishonti/testfw/app/MainActivity; or its super classes (declaration of 'net.kishonti.testfw.app.MainActivity' appears in /data/app/net.kishonti.testfw.app-1/base.apk) このメソッドは APIレベル23 (Android6.0) からなのでそのバージョンから有効な記述に修正します。 修正 # 以上の修正をまとめたパッチです。Android用 公式手順へのプラス分 となります。 --> Warning 以下のパッチは筆者の環境における一例であり、適用は 自己責任 にてお願いいたします。（ライセンス等の詳細は 記事末尾 に記載しています） なお、前々回適用したパッチ frameworks/cudaw/CMakeLists.txt （CUDAヘッダパスの設定を修正）の内容も含まれています。 diff --git a/app_android/benchui-lib/build.gradle b/app_android/benchui-lib/build.gradle index ceb9dbaa..534663bf 100644 --- a/app_android/benchui-lib/build.gradle +++ b/app_android/benchui-lib/build.gradle @@ -24,7 +24,7 @@ android { dependencies { implementation('com.google.code.gson:gson:2.10.1') - implementation('commons-io:commons-io:2.15.0') + implementation('commons-io:commons-io:2.6') implementation('de.greenrobot:greendao:2.1.0') implementation project(':testfw') diff --git a/frameworks/cudaw/CMakeLists.txt b/frameworks/cudaw/CMakeLists.txt index 0cc4a30e..710b4519 100644 --- a/frameworks/cudaw/CMakeLists.txt +++ b/frameworks/cudaw/CMakeLists.txt @@ -13,7 +13,9 @@ add_library(cudaw STATIC if(ANDROID) execute_process( - COMMAND cp -rL /usr/local/cuda/include ${CMAKE_CURRENT_SOURCE_DIR}/include/nvidia + COMMAND ${CMAKE_COMMAND} -E copy_directory + "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.2/include" + ${CMAKE_CURRENT_SOURCE_DIR}/include/nvidia RESULT_VARIABLE COPY_RESULT ) if(NOT COPY_RESULT EQUAL 0) diff --git a/frameworks/testfw/android/testfw-app/build.gradle b/frameworks/testfw/android/testfw-app/build.gradle index a4edba77..59e41cbf 100644 --- a/frameworks/testfw/android/testfw-app/build.gradle +++ b/frameworks/testfw/android/testfw-app/build.gradle @@ -45,7 +45,7 @@ android { } dependencies { - implementation("commons-io:commons-io:2.11.0") + implementation("commons-io:commons-io:2.6") implementation project(':testfw') implementation project(':platform-utils') diff --git a/frameworks/testfw/android/testfw-app/src/main/java/net/kishonti/testfw/app/MainActivity.java b/frameworks/testfw/android/testfw-app/src/main/java/net/kishonti/testfw/app/MainActivity.java index 808b4a47..89c53e1d 100644 --- a/frameworks/testfw/android/testfw-app/src/main/java/net/kishonti/testfw/app/MainActivity.java +++ b/frameworks/testfw/android/testfw-app/src/main/java/net/kishonti/testfw/app/MainActivity.java @@ -38,7 +38,9 @@ public class MainActivity extends Activity { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); - requestPermissions(new String[] { Manifest.permission.WRITE_EXTERNAL_STORAGE }, 2); + if (android.os.Build.VERSION.SDK_INT >= 23) { + requestPermissions(new String[] { Manifest.permission.WRITE_EXTERNAL_STORAGE }, 2); + } mDetailView = (TextView) findViewById(R.id.detailView); mDetailView.setMovementMethod(new ScrollingMovementMethod()); diff --git a/frameworks/testfw/android/testfw-lib/build.gradle b/frameworks/testfw/android/testfw-lib/build.gradle index d0e757b1..37dc1bcf 100644 --- a/frameworks/testfw/android/testfw-lib/build.gradle +++ b/frameworks/testfw/android/testfw-lib/build.gradle @@ -27,5 +27,5 @@ android { dependencies { implementation('com.google.code.gson:gson:2.10.1') - implementation('commons-io:commons-io:2.15.0') + implementation('commons-io:commons-io:2.6') } diff --git a/scripts/build-3rdparty.sh b/scripts/build-3rdparty.sh index 26e1cce7..c72e0d73 100644 --- a/scripts/build-3rdparty.sh +++ b/scripts/build-3rdparty.sh @@ -28,7 +28,7 @@ fi : ${CONFIG?"not set"} # set default values -: ${ANDROID_NATIVE_API_LEVEL:="android-24"} +: ${ANDROID_NATIVE_API_LEVEL:="android-21"} : ${ENABLE_CLANG:="false"} : ${USE_WAYLAND:="false"} diff --git a/scripts/build.sh b/scripts/build.sh index 8e501d7a..a34fb2a7 100644 --- a/scripts/build.sh +++ b/scripts/build.sh @@ -385,7 +385,7 @@ case $PLATFORM in fi RENDER_API=${OVERRIDE_RENDER_API:="${RENDER_API}"} COMMON_OPTS+=" -DRENDER_API=${RENDER_API}" - COMMON_OPTS+=" -DANDROID_NATIVE_API_LEVEL=24" + COMMON_OPTS+=" -DANDROID_NATIVE_API_LEVEL=21" PROJECTS="frameworks/platform-utils $PROJECTS frameworks/testfw" COMMON_OPTS+=" -DOPT_SWIG_JAVA=1 -DLIBRARY_OUTPUT_PATH_ROOT:PATH=${TFW_PACKAGE_DIR}" ビルド実行 # 古いAndroid端末でも動作する様に android-arm64-v8a android-armv7a 両対応のユニバーサルAPKとしてビルドしてみます。 前々回の環境変数を設定の後、 公式手順 ビルドスクリプト2種 の代わりに以下のスクリプト を実行します。 （環境変数の内、 PLATFORM, CONFIG, APPLICATION_TYPE はこのsh内で再設定されます） scripts/build-multiarch-apk.sh --> Information 前々回のAndroid用公式手順には載っていないのですが、GitHub workflow手順ではAndroid用にこのスクリプトでビルドしている様でそこからの拝借です。 デフォルトだと android-armv7a android-x86 android-arm64-v8a android-x86-64 の4種類分ビルドされます。 android-armv7a android-arm64-v8a の2種類だけで良ければ以下の様に実行します。 PLATFORMS="android-armv7a android-arm64-v8a" scripts/build-multiarch-apk.sh apkサイズとビルド時間を削減する効果があります。特にビルド時間の削減効果が大きいです。 ビルドが成功すると、ビルドのコンソールログで表示されるディレクトリに gfxbench-5.1.5+corporate.apk ファイルが出来上がります。 おわりに # 今回はGFXBenchを古いAndroid端末用にビルドしてみました。 次回は実際に古いAndroid端末で実行しベンチマークスコアを測ってみます。 ライセンスおよび免責事項 # 本記事に掲載しているビルド修正パッチ、引用しているビルド手順は、BSD 3-Clause Licenseのもとで公開されている Kishonti-Opensource/gfxbench のソースコードおよびドキュメント（ doc/gfxbench_gl_android_build.txt ）を利用・引用したものです。 Original Copyright: (c) 2005–2025 Kishonti Ltd. License: BSD 3-Clause License ドキュメントの権利について: 記事内で引用している公式ビルド手順のテキストの著作権は、原著作者であるKishonti Ltd.に帰属します。 【免責事項】 本記事に掲載しているパッチ、手順は、特定の検証環境における現状のまま（AS IS）のものであり、その正確性や安全性を保証するものではありません。 パッチの適用やビルドの実行により生じた直接的・間接的な損害について、筆者および株式会社豆蔵は一切の責任を負いません。内容を十分にご確認の上、ご自身の責任においてご利用ください。

こんにちは、モバイルアプリ開発部の 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