こんにちは。ファインディ株式会社でプリンシパルエンジニアをしている戸田です。 ファインディでは、施策の立案からIssueの生成、タスク分解、AIエージェントによる並列実装やQAまで、開発フローの各所にAIエージェントを組み込んでいます。 この記事では、開発フロー全体のアーキテクチャを図で示し、構成要素ごとに役割を解説します。PM、開発、QAのそれぞれでエージェントが何を担い、人間がどこで判断しているのか、開発の状態をGitHubのどこに置いているのかが分かる内容となっています。 複数のAIエージェントを開発フローに組み込もうとしている方や、AIエージェントとの役割分担を考えているエンジニアの方の参考になると思います。それでは見ていきましょう！ 開発フローのアーキテクチャ 施策を作るエージェント 施策提案スキル 要件定義スキル 要件をIssueに分解するエージェント Issueの依存関係から実装の順番を決める計画エージェント 並列で動く実装エージェント スタックプルリクエスト QAのエージェント まとめ 開発フローのアーキテクチャ エージェントやスキルは、PM向け、開発向け、QA向けの3つのPluginにまとめています。 開発フローは次の順に進みます。 PM向けPlugin PMのエージェントがNotionやGitHubなどからコンテキストを集めて施策を作り、要件定義のIssueとしてGitHubに作成する 開発向けPlugin 開発のエージェントが要件定義のIssueをタスクに分解し、親Issue、Sub-issue、依存関係をGitHubに作成する 計画エージェントがGitHubからIssueと依存関係を読み、実装の順番を決める 実装エージェントが依存の順にIssueを実装し、スタックプルリクエストとして積む レビュー 人間やAIがプルリクエストを順にレビューしてマージする QA向けPlugin QAのエージェントが要件定義のIssueからQA観点とテストケースを作り、Playwrightで実行する ここからは、構成要素ごとに解説します。 施策を作るエージェント フローの起点は、施策を作る段階です。PM向けの社内Pluginに、施策を提案するスキルと、施策の要件を定義するスキルを用意しています。施策提案スキルで案を選び、要件定義スキルでGitHubのIssueにする、という順に使います。 施策提案スキル 施策提案スキルは、PMからテーマや領域を受け取り、取り組むべき課題を探すところから始めます。 最初に、専用のエージェントが情報を並列に収集します。社内ドキュメントからはKPIや戦略、コードベースからは既存の機能やデータスキーマ、GitHubからは既存のIssueとプルリクエスト、Notionからは仕様書や議事録などを集めます。あわせて、Google AnalyticsとSearch Consoleのアクセス解析のデータと、Web上の市場や競合の情報も取得します。 収集した結果をもとに、別のエージェントが複数の観点から施策のアイデアを出し、さらに別のエージェントがインパクトと実現可能性などで評価して優先順位を付けます。 PMは、順位付けされた提案の一覧から採用する案を選びます。採用した案は次に紹介する要件定義スキルに引き継ぎます。 要件定義スキル 要件定義スキルは、提案された施策の要件を定義します。 情報収集の段階では、仮説エージェントと収集エージェントを並列に動かします。仮説エージェントが仮説を立てると、収集エージェントはその仮説に沿って必要なデータを集めます。仮説エージェントは追加で集まったデータを受け取り、仮説を裏付けたり修正したりします。 続いて、施策の規模を判定します。ユースケースやユーザー種別が複数にまたがる場合は、MVPと優先度付きの拡張項目に分けます。そのうえで、収集したデータが仮説を裏付けているかと、技術的に実現できるかを整理して、統合ドラフトにまとめます。PMはこのドラフトをレビューし、修正や補足があれば伝えます。 PMがドラフトを最終承認すると、要件定義の親IssueをGitHubに作成します。 要件をIssueに分解するエージェント 要件定義のIssueを受け取るのが、Issue生成スキルです。要件定義IssueのURLを入力に、実装タスクのIssueを作るところまでを対話的に進めます。 最初に、要件定義Issueの本文とコメントを読んで要件を理解し、対象のコードベースを探索して既存の構造と実装パターンを把握します。 tech.findy.co.jp 設計の段階では、方針の異なる設計案を並列に作り、開発者が比較して設計方針を決めます。決めた方針をもとに、タスクに分解します。 tech.findy.co.jp Issueの作成は、専用のサブエージェントに切り出しています。サブエージェントは、要件定義Issueを親Issueとして再利用し、子IssueをSub-issueとして作成したうえで、Issue間の依存関係を設定します。依存関係を本文の #番号 ではなくGitHubのIssue依存関係機能（ blocked_by ）で登録しているのは、後段の計画エージェントが機械的に読めるようにするためです。 blocked_by は、あるIssueが別のIssueの完了を待つ関係を、Issue同士に設定する機能です。Sub-issueで「何を作るか」を親子に整理し、 blocked_by で「どの順に作るか」を表します。 Issueの依存関係から実装の順番を決める計画エージェント 並列実装を指揮するのが計画エージェントです。計画エージェントの役割は実行計画の作成と実装エージェントの起動に限られていて、コードの編集、worktreeの操作、GitHubへの書き込みはしません。 計画エージェントは親Issueを起点に、GitHubからopenなSub-issueと、それぞれの blocked_by を読み込みます。closedのIssueは対象から外し、closedのIssueへの依存は解決済みとして扱います。 開発者は、計画エージェントが提示した実行計画を確認します。確認が取れると、計画エージェントは、依存でつながったIssueのグループごとに実装エージェントを並列で起動します。 tech.findy.co.jp 並列で動く実装エージェント 実装エージェントは、依存でつながったIssueのグループごとに起動され、担当のIssueを実装してプルリクエストを作るまでを、完全に非対話で受け持ちます。 計画の承認が必要な場合は、先に計画だけを返す実装エージェントを起動します。開発者が計画を承認したあとで、改めて実装エージェントを起動します。 実装エージェントは、担当のIssueを依存の順に下から実装します。Issueごとにgit worktreeを作り、2番目以降のIssueは前のIssueのブランチをbaseにします。この時点のブランチはpushせず、手元に置いたままです。 tech.findy.co.jp グループの中に互いに依存しないIssueがある場合は、それらを並列に実装したあと、組み立てエージェントがリベースして依存の順に並べ直します。リベースを実行する権限は、このエージェントだけに持たせています。 並べ終わったブランチからプルリクエストを作成し、スタックプルリクエストとして登録します。 スタックプルリクエスト 実装エージェントは、プルリクエストをスタックプルリクエストとして登録し、そこで終了します。 tech.findy.co.jp プルリクエストの本文には、対応するIssue（ Closes #番号 ）、親Issue、依存しているプルリクエスト、セルフレビューなどの品質保証の結果を入れます。 開発者は、スタックを下から順にレビューしてマージします。下位のプルリクエストがマージされると、GitHubが上位のブランチを自動でリベースし、baseを付け替えます。図の例では、#201をマージすると#202のbaseがmainに付け替わります。どこまでマージされたかという状態はGitHubが持っているため、エージェントはマージを待ちません。 マージされたプルリクエストは、 Closes によって対応するIssueを自動でcloseします。closeされたIssueは、次に計画エージェントを起動したときの計画の対象から外れます。 QAのエージェント QAには、QA向けの社内Pluginを使っています。開発リポジトリとは別のQA用リポジトリで動かし、分析対象の開発リポジトリを設定で登録しておきます。 QA観点を作るスキルは、要件定義のIssueを仕様ソースとして読みます。NotionやFigmaのページも仕様ソースとして渡せます。まず仕様を抽出するエージェントが、キーワードと対象ファイルを決めて探索の範囲を絞ります。続いて、画面と操作フローを調べるエージェントと、変更による回帰リスクを判定するエージェントを並列に動かし、その間に要件がコードとテストで満たされているかを突き合わせます。 集めた検証項目は、テスト戦略のスキルで「テストコードで自動化するもの」と「QAテストで確認するもの」に分けます。QA観点にはQAテスト側の項目だけを展開し、テストコードが足りていない箇所は別のファイルとして出力します。 テストケースを作るスキルは、QA観点をもとに、前提条件、手順、期待値、ロールごとの結果欄を持つテストケースを作ります。各ケースには、ブラウザ操作で自動実行するAutoか、人間が目視で確認するManualかを付けます。判断に迷うケースはManualに寄せています。 作成した観点とテストケースは、QA基準のカテゴリごとにレビュー用のエージェントを並列に起動して、網羅性と品質を確認します。QA担当は、指摘のうちどれを反映するかを選びます。 Autoのケースは、Playwright MCPを使ってロールごとに順に実行します。結果は、失敗したケースのスクリーンショットを含むレポートとして出力し、元のテストケースには書き戻しません。Manualのケースは目視確認の一覧としてまとめ、QA担当が目視で確認します。 まとめ AIエージェントを開発フローに組み込むうえで大事なのは、AIに任せる範囲と人間が判断する部分を切り分けることだと考えています。 情報の収集、設計案の作成、実装、テストの実行といった作業はAIに委任し、施策の採択、設計方針の決定、実行計画の確認、マージ、QAの確認といった最終的な判断は人間が行います。 AIに委任して人間が最終判断するという線引きを決めておくことが、AIエージェントと一緒に開発を進めるうえでの前提になります。 開発フローのどこにAIエージェントを置くかは、チームによって答えが変わると思います。この記事の図が、自分たちのフローを見直すときのたたき台になればうれしいです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに 先日、社内で AI Coding Agent Hackathon というイベントを開催いたしました。本記事では、そのイベントの様子を紹介します。 目的 RevComm には「AI活用推進室 (AI Promotion Office)」という組織があります。AI活用推進室における活動の一環として、「AI Coding Agents Optimization Guide」というガイドラインを策定しています。このガイドラインは、AI コーディングエージェントの価値を最大化するために、各チームが段階的に AI コーディングエージェントの活用を進めていけるような指針を定めています。具体的には、まず AGENTS.md の導入などから始め、最終的にはサブエージェントやスキル、MCP などの活用やコスト削減のための方法論などの応用的な活用法を段階的に取り入れていくためのプラクティスを整備しています。 この AI Coding Agents Optimization Guide を実践を通じて組織的に学ぶ場として、ハッカソンを開催しました。 実施したこと 概要 開催時間: 3 時間 使用した AI コーディングエージェント: Claude Code または Codex 題材 今回のハッカソンではタイピングゲームの開発を題材としました。普段、フロントエンド開発に携わっているメンバーも参加しやすいよう、ランタイムとしては Node.js を選定しました。 当日の進行をスムーズにするために、あらかじめテンプレートリポジトリを整備しました。各参加者はこのテンプレートをベースにリポジトリを作成することで、すぐに開発に取り掛かることができます。 メトリクスの収集・可視化 各種メトリクスを収集・可視化することでトークン使用量などのコストを意識して課題に取り組めるようにするために、ダッシュボードを作成しました。このダッシュボードは Claude Code や Codex などのコーディングエージェントを OpenTelemetry を介して Datadog と連携させることによって実現されています。テンプレートリポジトリの Markdown ドキュメントに Datadog と各種コーディングエージェントの連携方法を記載しておき、スムーズにセットアップできるようにしました。 Datadog によるメトリクスの可視化 課題の着手 テンプレートリポジトリには、取り組むべきタスクを詳細に記載した Markdown ドキュメントが含まれています。 タスクの一覧 各タスクには priority が設定されており、それに応じて最終的な採点結果が加算されます。 タスクの例 成果発表 最後に成果発表を実施しました。各自で取り組んだ内容や工夫したことに加えて、普段の開発環境やコーディングエージェントの活用方法についての共有も実施しました。 成果発表の様子 スコアと分析結果の共有 各メンバーのスコアの採点と全体的な分析結果の共有を実施しました。スコアは runn と Playwright を活用して、自動で採点できる仕組みを構築しました。また、ハッカソンに参加いただいた各メンバーが今後、より効果的に AI コーディングエージェントを活用できるようにするため、Datadog で収集したコスト情報とスコアのプロットや、Datadog で収集した情報から判明した良い活用法などについても全体で共有しました。 フィードバック まとめ 成果発表の場を通して、参加者の方々がさまざまな工夫や活用法などを実践されていることがわかりました。 Git worktree や herdr / cmux などを活用してセッションを並列実行することで、タスクをより効率的にこなす。 claude-code-orchestra を活用したマルチエージェントのオーケストレーション /grill-me スキルの活用 自分自身、まだ試したことのないコーディングエージェントの活用法などを知ることもできたため、今後、実践していきたいです。 今回のように、普段の業務と異なる題材で気軽に試せる場を設けることで、組織全体として AI コーディングエージェントの知見を共有する機会になったと感じています。今後もこのような取り組みを通じて、より実践的な AI 活用を進めていきます。

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