AI駆動で挑むプロダクト刷新 ─ アーキテクチャ設計と ワークフロー最適化の実践事例 ─ グリーエックス株式会社 ソフトウェアエンジニア 奥村凌 

奥村凌 グリーエックス株式会社 ソフトウェアエンジニア 2025年新卒入社。入社時から観光DX SaaS 「Aumo Biz」のプロダクト開発を担当。 本サービスの機能全般に、バックエンドから フロントエンド、デザインシステムまで幅広 く携わっている。 2 

アジェンダ Aumoについて SaaS管理画面の全面リニューアル Aumoアプリの全面リニューアル（Kotlin Multiplatform） 爆速リニューアルを支えた開発基盤と体制 AI駆動の開発で意識したこと 3 

Aumoについて ● 観光やグルメ、ホテル、暮らしに関する最新情 報を届ける、おでかけ情報サービス。 ユーザーが店舗を見つけて来店するまで、メ ディアとSaaSの両面から一貫して支援。 ● 一般ユーザー向けには、オウンドメディアとコ ミュニティアプリを提供。 ● 店舗クライアント向けには、口コミ分析や広告 レポートを提供するSaaS（Aumo Biz）を展 開。 4 

SaaS管理画面の全面リニューアル 5 

顧客向けSaaS管理画面のリニューアル 旧管理画⾯ リニューアルの背景 ● 旧管理画面のサーバーサイドは、モノリスなRailsアプ リケーションに組み込まれて肥大化。 ● フロントエンド（Vue／Nuxt.js）はコンポーネントが 画面ごとに分散し、共通化が困難。 ● 画面はPC向けの固定幅で、店舗の方がスマホから操作 できない状態。 新管理画⾯ リニューアルの内容 ● AIと社内デザインシステムを活用してサーバーサイド、 フロントエンドともに刷新を実施。 ● エンジニア1名が約2ヶ月でリリースまで完走し、MAU は前期間比で2倍以上に。 6 

技術選定（Go＋Next.js） 共通してAIと相性の良い言語・フレームワークを選定 Backend（Go） Frontend（Next.js＋Bolt UI） ● 文法がシンプルで書き方が揃いやすく、型と ● 社内デザインシステム（Bolt UI）がReact製 コンパイルでAIの誤りにすぐ気づける。 ● ダッシュボード機能は約30クエリ/reqを実行 するため、並行処理が重要。 ● APIとバッチを1つの静的バイナリにまとめら れ、コンテナイメージを小さく保てる。 のため、Next.jsを採用。 ● Next.js 16のCache Componentsで画面の一 部だけを更新でき、ダッシュボード機能に マッチ。 ● コンポーネント、型、トークンが決まってい るため、AIが実装しても見た目がブレにく い。 7 

操作マニュアルを自動生成する ①画像も含めたマニュアル更新PRを自動生成 PR内容からマニュアルを自動更新 ● 従来は人が手作業で更新しており、機能の追加や 改修にマニュアルが追いつかない状態。 ● PRのマージをきっかけにGitHub Actions上で Claude Codeを起動し、影響するマニュアルを特 定して書き換えるワークフローを導入。 ②静的ページとして同じドメイン上に反映 ● Chrome DevTools MCPでスクリーンショットを 撮影し、操作手順の注釈（アノテーション）の追 加まで自動化。 ● 作成したマニュアルはNext.jsの静的ページとして 公開。 8 

AIクライアントで運用データを参照する 運用データをMCP経由で扱う ● 管理画面で表示している運用データを、AIクライア ントから参照できるようにBFF（Next.js）を拡張。 ● BFFに @modelcontextprotocol/sdk を組み込み、 AIクライアント（Claude Codeなど） 接続先URLを設定してOAuth 2.1で認証 ↓ 社内MCPサーバー（BFF／Next.js） サーバーサイドAPIの結果をAIクライアント上に表 示する社内MCPを実装。 ● 接続先のURLをAIクライアントに登録するだけで使 既存APIの呼び出し ↓ 既存API（Go） えるため、CLIより配布しやすい。 ● 認証はOAuth 2.1で行い、ユーザー権限の範囲で読 み取りのみを許可することで、誤った変更や情報漏 権限の範囲内で運用データを返却 ↓ AIクライアントにレスポンス返却 えいを防止。 9 

Aumoアプリの全面リニューアル 10 

Aumoアプリのリニューアル 旧アプリ 新アプリ 約3ヶ月でアプリを全面リニューアル ● iOSとAndroidで別々だったアプリを、KMP （Kotlin Multiplatform）で1つに統合。 ● 専任のアプリエンジニアが不在のなか、デザイナー とエンジニアの2人がAIメインで開発。 ● KMPでビジネスロジックを1か所にまとめ、OSごと の二重実装と機能差分を解消。 ● 放置されていたプラットフォームやライブラリの アップデートにも追従し、技術的負債を解消。 ● 他業務と並行しながらも、1.5人月でリリースまで 完走。 11 

技術選定（Kotlin Multiplatform） リニューアルの背景 ● 2018年リリース当時はクロスプラットフォームの採用例 これまで が少なく、OSごとにネイティブ開発を行っていた。 ● 専任のアプリエンジニアが不在であり、SDKやライブラ リの更新が滞り技術的負債になっていた。 ● また、利用者の多いiOSで機能やABテストを先行導入し た結果、Androidとの機能差が発生。 KMPを選んだ理由 iOS Android Swift Kotlin 二重に実装するため、機能がズレる ↓ ● KMPはロジックだけを共通化でき、UIは各OSのネイ ティブで作れる。 ● JetBrainsが開発し、Googleも公式にサポートしている 1つのリポジトリ ／ ロジックを共通化 成熟した環境。 ● FlutterやReact NativeはUIの共通化が前提で、OSごと の操作感を作り込みづらいため不採用。 12 

KMP（Kotlin Multiplatform）の構成 ● 通信、データ処理、状態管理などのビジネスロ 共通ロジック（Kotlin） ジックは、Kotlinで1か所にまとめて両OSで共有 する。 通信、データ処理、状態管理などの ビジネスロジック / クリーンアーキテクチャ各層 ● 簡易的なクリーンアーキテクチャを採用し、UI以 外の層をすべて共通化する。 ↓ ↓ iOS Android ● OS固有のネイティブ実装はUIだけになり、機能の 追加や修正は共通ロジックの1か所で完結できる。 ● UIは各OSの操作感を優先し、iOSはSwiftUI、 SwiftUI Jetpack Compose AndroidはJetpack Composeで実装。 UIはそれぞれに最適化して実装 13 

アプリ開発のワークフロー最適化の経緯 Ph.0 環境構築（エンジニア） ● 技術選定、アーキテクチャ設計、エージェント用のスキルやMCPを整備したリポジトリを作成。 ● Google I/Oで安定版が発表されたAndroid CLIなど、AIエージェントが使えるCLIを用意。 Ph.1 チャット駆動（デザイナー） ● デザイナーがAIにチャットで依頼しながら、PoCとして開発を進行。 ● 約1週間で見た目は完成したものの、不具合やOS間の挙動の差が多く発生。 Ph.2 エージェント監査駆動（デザイナー） ● サブエージェントが別のサブエージェントを管理し全体を監査するループを回す手法を導入。手戻りはかなり 減ったが、時間とトークンの消費が大幅に増加。 Ph.3 仕様駆動（デザイナー） ● 仕様書と作業手順を先に決め、実装するAIと確認するAIを分離。AIがエミュレーターとシミュレーターを操作 し、スクリーンショットで動作を確認しながら進めることで手戻りが激減し安定化。 14 

Aumoアプリのリニューアルについて詳しくはこちら AI駆動でAumoアプリを全面リニューアルした 話 ① ─ エンジニアがデザイナーに開発環境 を引き渡すまで ─ Aumo 開発体験 Kotlin Multiplatform iOS Android AI 技術選定 Kotlin Multiplatformの技術選定から、AIエージェントが自 律的に開発できる環境づくりまでを紹介。 masashi.hamaguchi GREE X Tech Blog 2026/10/15 QRコードから記事を読む https://tech.gree-x.com/aumo-app-renewal-overview 15 

爆速リニューアルを支えた開発基盤と体制 16 

AIネイティブな開発基盤 全サービスをIaCで統一 ● 手作業で作られていたインフラを、Terraformで完全にIaC化し命名規則も統一。 ● IaC化したことで、AIが構成を読んで調査や変更案の作成まで行える状態に整備。 Aumo Skillsの導入 ● 仕様や設計方針などのコンテキストをスキル化してチームで共有。 ● 運用チームにもClaude経由で展開することで、コード化されていないノウハウもコンテキスト化。 Aumo CLIの導入 ● AI開発用CLI（Aumo CLI）を導入し、AWSへの認証とリソース状態の取得を1コマンドで実行できる環境 を整備。 ● AIもCLI経由でコンテナでのコマンド実行やSQLでの調査を、セキュリティに配慮した範囲で行える。 17 

AIネイティブな開発体制 1プロジェクト＝1オーナー ● 縦割りの役割ではなく、プロダクト単位で担当を分ける。要件の検討から運用・改善までを同じ人が 一貫して受け持つ。 ● 課題の発見から反映まで1人で完結するため、意思決定が速く判断の理由も失われない。 複数エージェントをメンバー化 ● 実装したモデルとは別のモデル（Codex、Gemini）がレビューするなど、 コンテキストごとにエージェントに分業させ、開発メンバーの一員とする。 ● 人は設計や判断に集中でき、レビュー・承認待ちなどで生まれるボトルネックを削減。 18 

AI駆動の開発で意識したこと AIと相性の良い技術を選ぶ ● 型や規約で書き方が決まり、AIが書いたコードのブレが少ないことやエコシステムの成熟を基準に選定。 ● 書きやすさよりも読みやすさを優先したGo、デザインシステムを活かせるReact（Next.js）、ロジックを共有 できるKMPなどを採用。 AIが自走できる土台を先に作る ● 繰り返し発生する作業は、CI/CD、IaC、CLI、共通スキルとして仕組み化する。 ● AIが自分で判断して進められるよう、仕様書やデザインシステムとして判断材料や土台を用意する。 作るものを決め、責任を持つのは人 ● 事業を考え、意思をもってプロダクトや機能を決めるのは人の役割。AIが作ったものの運用や保守まで、人が 責任を持つ。 エージェントのための「土台」を設計し、整えること、 それこそがエンジニアが発揮すべき役割。 19 

ご清聴ありがとうございました 20 

No content