前回の記事 では、Web アプリ・SDK・CLI を 1 つの OpenAPI Spec の Consumer として揃えた上で、次に モバイルアプリの開発 に取り組みたい、と紹介しました。本稿はその続報です。いま NASEBANAL Growth Mobile を開発中で（もう少し実装機能を増やした上で正式公開の予定です）、そこで得た経験を本ブログで共有します。また、その開発の過程で、モバイルアプリは画面まわりの実装が比較的シンプルなこともあり ダークモード 化もスムーズに実装できたため、Look & Feel を統一する狙いで Web アプリにも表示モードの切り替え機能を展開しました。これらの開発から得られた学びに触れつつ、最後に、この一連の流れが、いま内製化支援で考えているアプローチとどう重なるのかをお話ししたいと思います。
NASEBANAL Growth Mobile の開発の流れ
NASEBANAL Growth Mobile は、NASEBANAL Growth の 3 つのアプリ——Target・Recorder・Stopwatch——を 1 つのモバイルアプリに束ねた、Expo / React Native 製のクライアントです。3 つを別々のアプリとして出すのではなく、クロスアプリのボトムタブを持つ 1 つの器の下にまとめ、各アプリの中核画面を統一された UI 言語のもとに、単一のアカウント・単一のログインで行き来できるようにしています。
なお、この統合は現時点ではモバイルに限った話ですが、将来的には Web 版にも同様の統合化を進めたいと考えています。
ここで書き留めておきたいのは、アプリそのものというより、どう作ったか のほうです。流れは次のとおりでした。
- 既存の Web 版 UI をベースに。 Growth の各アプリはすでに Web 上に存在し、動作としてもある程度安定しています。そこで Mobile アプリの UI もゼロから設計するのではなく、出発点となる参照として据えました。
- Claude Code から Figma MCP を用いて画面を設計。 Web の画面情報をもとに、Claude Code から Remote MCP 連携で Figma を動かし、自然言語でコンポーネントレベルから画面イメージを設計しました。
- Figma のスクリーンイメージを手で微調整し、それをマスターに。 生成されたフレームがゴールではありません。余白やタブバー、モバイルでの使い勝手を、スマートフォン上でしっくりくるところまで Figma のスクリーンイメージ上で調整しました。この手で微調整した画面が、そのまま マスター——AI がコードを生成する際にインプットとして参照する基準——になります。
- その画面と OpenAPI Spec をもとに自動生成。 仕上げた画面を一方の入力とし、もう一方に OpenAPI Spec——Web アプリ・SDK・CLI がすでに共有しているのと同じ契約——を据えて、AI コーディングでアプリを組み上げました。画面が見た目と振る舞いを、Spec がデータ層と API クライアントを、それぞれ規定します。
Figma を Remote MCP で操作するのは有償ではあるものの、それに見合う便利さがありました。自然言語でコンポーネントレベルから画面イメージを作成でき、かつ手で微調整した内容をマスターとして AI コーディングのインプットに引き戻せる——この組み合わせによって、フォントサイズやパネル構成といった操作性や標準準拠をある程度意識した画面設計を保ちながら、そこに自分のアイディアを形として入れ込むことができました。
強調しておきたいのは、このアプリが 2 つの明確な入力 から立ち上がっている、という点です。すなわち「どう見え、どう振る舞うか」を固定する画面の一式と、「その下でどんなデータが流れるか」を固定する Spec。どちらも即興ではありません。画面は設計から、データの結線は契約から来ています。
学び① — Figma を用いて、AI と人間の間で仕様を調整
モバイルアプリの画面開発は、振り返ると比較的スムーズに進みました。その一因は、いきなり実装に入るのではなく、まず Figma MCP を使って AI に画面構成のドラフトを考えてもらった ことにあります。Web の画面情報をベースに、Claude Code から自然言語でコンポーネントレベルから画面イメージを組み立て、生成されたフレームを人間の手で微調整してから実装に移りました。この「手で整えた Figma のスクリーン設計」が中間成果物として残り、AI がコードを生成する際に参照する明確な基準になったのです。
あわせて、モバイルではあまり労力をかけることなく実装できたダークモードを Web アプリにも展開しました。React Native は OS の外観設定をそのまま扱えますし、色をハードコードではなくトークンとして表現していたため、モバイルでは Claude Code で生成した UI をシステムのライト／ダーク設定に追従させるのは、全画面をひとつずつ手直しして回るような作業ではなく小さな変更で済みました。ランディングページと各 Growth アプリも、いまはいずれも Light / Dark / System に対応しています。
ただ、いざ Web に取り掛かってみると勝手が違いました。まず画面そのものの実装を、Figma を経由せずプロンプトから直接進めたため、レイアウトの調整に繰り返しのやり取りが必要でした。そもそもモバイルの UI よりコンポーネントの数が多いという事情もありますが、改めて思い返せば、「配置を画面の左右両端に寄せたい」「パネルとその下のボタンの間隔をもっと空けたい」といった指示が、パネルの階層が深いためか、なかなか思うように反映されないといった場面もありました。ダークモード化についても同様で、モバイルのように一度で出そろうことはなく、コンポーネントごとに色調を指示して、ようやく形にできました。
いま振り返ると、最初の画面実装からいきなり Vibe コーディングで GUI を調整するのではなく、モバイルと同じように、一度 Figma のリモート MCP 越しに画面イメージへ落とし込み、中間成果物としてのスクリーン設計を人間の手で固めたうえで実装に移る——そういうプロセスを踏んでいれば、画面構成の構造を理解しながら、もっとスムーズにAIコーディングによる実装が進められたのかもしれません。これが、今後のアプリ開発に向けた学びの一つです。
学び② — アーキテクチャを意識する
Vibe コーディングでは、自分が欲しい機能をそのままプロンプトで指示していくのが一般的でしょう。私も最初はそうでした。ただ、開発を進めるにつれて、機能の拡張性やアプリ間での横展開を意識する場面が増え、そのたびにアーキテクチャの見直しを迫られました。
具体的には、次のような問いです。NavBar や Footer といった共通的なコンポーネントを、どうやってアプリ間で統一するか。ログインセッションをどう共通化（SSO 化）するか。ダークモードのようなスタイルを、どうアプリ間でそろえるか。Specmatic のための OpenAPI Spec を、どう複数アプリケーション間で共有するか。サブスクリプションプランを、どうアプリ間で管理するか——。
こうした問いに向き合う過程で得た学びおよび実装アプローチは、テンプレートアプリとして記録しておくことで、自分自身の後続の開発に活かせるだけでなく、将来ご支援するお客様の開発でも活かせるものと期待しています。AI コーディングの時代には、利用する AI エンジンの機能差だけでなく、こうした知見をもとにしたアセットにも、付加価値が出てくるのではないかと思います。
まとめ — 内製化支援で考えているアプローチ
Growth Mobile の作り方から一歩引いて眺めると、その流れは、私がいま 内製化支援 で考えているアプローチに重なります。
つまり、事業会社は 2 つのものを整理する——Figma 等を用いた 画面要件 と、API 仕様（Spec） です。この 2 つの明確な入力から、フロントエンドを AI コーディングで生み出す。まさに、私が Growth Mobile を作るために歩いた道筋そのものです。片側に画面、もう片側に Spec、その間で AI がフロントエンドを組み上げる。
同時に、そこで規定した API 仕様が契約になります。API 自体は、その契約に照らして準拠性を検証しながら、必要に応じて外注し、運用・保守することができます——前回取り上げた Contract-Driven Development の仕組みです。この分担は、事業にとって大切な 2 つのものをもたらします。
- アジリティ（俊敏さ）。 ユーザーに最も近い部分であるフロントエンドは、内製で開発し、クライアントに近いところで高頻度にデプロイ できます——応答性が最も効く場所で、フィードバックループを速く回せるということです。
- レジリエンス（回復力）。 仮にフロントエンドで障害が起きても、API に加え、昨今では LLM と連携する MCP を通じて、業務のワークアラウンドとしてデータアクセスを維持できます。フロントエンドが落ちることが、そのまま業務停止を意味しなくて済むのです。さらに、バックエンドの処理が API の呼び出しとしてシンプルに切り出されていれば、Cloudflare Workers のようなサーバーレスや Kubernetes 上で稼働させることで、オートスケールによる安定稼働も比較的容易に実現できる と期待できます。
ユーザーに面するフロントエンドは、画面と Spec から内製し、その Spec を契約として、バックエンドは品質を担保したまま柔軟に調達する。NASEBANAL Evolution では、さらにもう一歩進めて、API の品質保証を仕組みとして支えるプラットフォーム——契約への準拠性を継続的に検証し、外注したバックエンドであっても品質を担保し続けられる基盤——を用意することを計画しています。テンプレート化した開発物と、この品質保証の仕組みを組み合わせることで、クライアントの内製化を、より確かな形で支援していきたいと考えています。
NASEBANAL Evolution（API 品質保証のプラットフォーム）については、また改めてアップデートできればと思います。