DocsDigest
Back to listLanguage: JA
OpenAIExpoApr 21, 2026, 1:15 PM

How Hipcamp upgraded Expo SDK versions with Claude Code

A condensed section focused on the key takeaways first.

Original Post
OpenAIClaude

Quick Digest

Summary

A condensed section focused on the key takeaways first.

openaienmodel: gpt-5-mini-2025-08-07

How Hipcamp upgraded Expo SDK versions with Claude Code

react-nativeexpoai-agentsdependency-upgradenew-architectureeaspatch-package

Key Points

  • Automated dependency audit with AI agents
  • Replaced many libs with Expo modules and structured DB tracking
  • Upgrade time cut from months to weeks

Summary

Hipcamp used an internal AI agent (Scout, powered by Claude/Claude Code techniques) to automate a large Expo SDK upgrade from Expo 50 (RN 0.73) to Expo 54 (RN 0.81 / React 19.1) and adopt React Native's New Architecture (16kb Android page size). The agent performed a dependency audit, created upgrade PRs, and validated builds so engineers could focus on complex issues. The automated approach reduced an estimated 2–3 month effort to a couple of weeks.

Key Points

  • Goals
    • Only touch dependencies that are required; prefer replacing with Expo modules when available.
    • Use patch-package only as a last resort.
  • Multi-phase workflow
    • Phase 1: Build an agent and index your codebase to avoid hallucinations.
    • Phase 2: Audit every dependency (one per subagent), record notes and results in per-dep files and a sqlite DB.
    • Phase 3: Have subagents open upgrade PRs, run lint/tsc/bundle, create EAS builds, and attach build artifacts and QA notes.
    • Phase 4: QA with staged rollouts, monitor errors, and iterate fixes.
  • Audit requirements (examples to automate)
    • Read changelogs and migration docs, search GitHub issues, check peer-deps and conflicts, and verify New Architecture / 16kb support.
    • Produce structured output: per-dep markdown + sqlite rows (name, expo_50_version, expo_54_version, new_arch_support, sixteenkb_support, status, change_recommendation, etc.).
  • Practical checklist for engineers
    • Index app architecture before automation.
    • Run automated audits one dependency per agent/subagent.
    • After upgrades: run yarn lint, tsc, react-native bundle; create EAS builds for iOS/Android and validate.
    • Use company-wide QA ("QA party") and staged rollouts; integrate error tracking and performance profiling (e.g., Expo Observe).
  • Outcome and caveats
    • Most dependencies were upgraded or swapped to Expo modules; total upgrade time shortened dramatically.
    • Minimal post-upgrade regressions observed; one notable increase in memory usage under New Architecture required focused debugging.

Practical recommendations

  • Prefer Expo modules when possible to reduce maintenance and native complexity.
  • Track audit results in a structured DB to sync with PM/workflow tools.
  • Use subagents for long-running, single-responsibility tasks to keep PRs small and reviewable.
  • Budget for a short focused debugging phase for New Architecture issues (e.g., memory/performance).

Full Translation

Translations

A translation section that keeps the flow of the original article.

openaijamodel: gpt-5-mini-2025-08-07

HipcampがClaude CodeでExpo SDKのバージョンをアップグレードした方法

これはArmaiz Adenwalaによるゲスト投稿です。ArmaizはHipcampのモバイルアプリ体験を担当しています。

概要

React Nativeのアップグレードは常にエンジニアにとって恐ろしい作業でした。慣れないネイティブコードや重要なライブラリに手を入れ、破壊的変更を解決する必要があります。十分にテストしなければ、あらゆる箇所でエラーが発生し得ます。時間の経過とともに React Native Upgrade helper のようなツールがプロセスを楽にし、Expo のようなフレームワークはこの流れをさらにスムーズにするために作られました。

アップグレードの複雑さ

残念ながら、すべての React Native アプリが完璧な状態にあるわけではありません。高速で動く企業では、依存関係の維持と機能リリースのバランスを取るのは非常に難しいことがあります。その結果、アップグレードはより大きな事業になります。

Hipcampでは最近、New Architecture + Expo 54 へのアップグレードに直面しました。New Architecture により、古いまま放置された数十のライブラリをアップグレードするか置換する必要がありました。React Native に十分携わったことがあるなら、単に最新版に上げるだけでは不十分だとおわかりでしょう。デバッグや問題解決に多くの時間がかかります。さらに、複数のライブラリが互いに競合し、互換性のあるバージョンを探す必要が出てきます。

幸いなことに、今回は既に Scout という、私たちが与えたタスクをこなすAIエージェントを構築していました。エンジニアが数週間かけて行う依存関係の調査やバージョン解決は、Scout が数日の数回の集中セッションで処理しました。内部エージェントが役立つ一方で、本稿では純粋に Claude Code を使って React Native のアップグレードをどう進めるかを共有します。

Scout がアップグレードを加速させた方法

アップグレード前の Hipcamp アプリの状況

  • セキュリティアップデート以外でアプリのバージョニングを追えていなかった
  • 放置されたパッケージや4〜6年前の古いパッケージが混在
  • 依存関係は100以上、うち約40が New Arch をサポートするためにアップグレードが必要
  • 会社がスリムなため、通常のプロダクト作業に加えてアップグレードを回す余裕がなかった

時間が問題であり、コストではありませんでした。エンジニアを数ヶ月このアップグレードに割くことは正当化できませんでした。

アップグレードのスコープの決め方

アップグレードをどう実行するかに入る前に、プロンプト設計のための主要ゴールを定義しました。以下に決めた内容を示します。

  • 必要な依存関係のみにフォーカスする
  • New Arch / 16kb Android をサポートしていないものはアップグレード対象にしない（まずはサポートするものを優先）
  • 依存関係は可能なら Expo 相当のライブラリで置き換える
    • Expo のモジュールはよくメンテナンスされており、信頼性と普及度が高い
  • 最終手段として patch-package を活用する

アップグレードワークフロー

マルチフェーズのアプローチを採ることにしました。各フェーズにどれだけの時間/コストを割くか決める必要がありました。最終的に、トークン（AI利用コスト）は、ドキュメントやコード、GitHub issue を延々と辿るエンジニア時間より遥かに安いと判断しました。さらに節約されたエンジニア時間は収益を生む機能開発に回せます。

Phase 1: エージェントを構築する

Scout のようなエージェントを社内で作るか、または Expo の upgrade skill を活用することを強く勧めます。エージェントにコードベースを学習させ、アーキテクチャをインデックス化する仕組みを設計してください。私たちは /scout-document-architecture コマンドを1日実行して、アプリのあらゆる側面と詳細をメモさせました。これにより Scout の誤生成（hallucination）や見落としを防げました。

Phase 2: すべての依存関係を監査する

エージェントに依存関係を監査させました。追跡には sqlite DB を使うことを推奨します。プロジェクト管理ツールと同期することも、Markdown ファイルにすることも可能です。

以下は私たちがエージェントに渡したプロンプトの例です（翻訳済み）。

Expo SDK 50 → 54 Dependency Audit

依存関係をすべて監査し、Expo 50 → 54 のアップグレード互換性を評価してください。

コンテキスト

  • Current: Expo 50 (RN 0.73, React 18.2)
  • Target: Expo 54 (RN 0.81, React 19.1)
  • Expo 52+ は New Architecture をデフォルトで有効化
  • Expo 52+ は 16kb Android page size サポートが必要

調査で必ず行うこと

  • Expo 50 と Expo 54 の互換バージョン間の GitHub changelogs/releases を読む
  • GitHub issues を検索してバグ・エラー・リスク・不満点を探す
  • セットアップドキュメントやマイグレーションガイドを読む
  • 弊社スタック内の他の依存との競合チェックを行う
  • セットアップやスイッチがリスキー/複雑かどうかを確認する

その上で次の問いに答えること:

  1. Expo モジュールに置き換え可能か?
  2. 完全に削除可能か?
  3. GitHub issues にNew Arch のブロッカーはあるか?
  4. 16kb page size の問題は報告されているか?
  5. 他の依存とpeer dependency の衝突があるか?
  6. アップグレードパスはスムーズか、コード変更が必要か?
  7. 最近のバージョンに対するコミュニティの不満はあるか?

Subagent 戦略

  • 小規模/単純な JS のみの依存には 1 subagent
  • 中程度/やや難しいネイティブ依存には 5 subagents
  • 極めて複雑な依存（react-native core, reanimated, maps, firebase, sentry など）には 10 subagents
  • 各 subagent は必ず 1 つの依存にのみ取り組む — バッチ作業しない

出力

  • 各依存について ./dependencies/{name}.md にノートを一つ
  • ./dependencies.db（SQLite）を作成、カラム:
    • name, expo_50_version, max_version_expo_50, expo_54_version, new_arch_support, sixteenkb_support, status, type (javascript/native), change_recommendation (upgrade/remove/swap), swap_target, complexity (0-10), notes
  • 可能なら常に Expo 相当ライブラリへの置換を優先
  • 依存を一つずつ処理 — スキップして先に進まないこと

参考

Phase 3: レビューとアップグレード開始

各アップグレード項目を手動で確認し、想定外にライブラリが削除されていないか、推奨代替が適切かを検証しました。利用できるなら Expo のライブラリを強く推奨します。Active にメンテナンスされ、ドキュメントも充実しています。

プロセスの文書化とPR作成

作業完了後、エージェントに各アップグレードの PR 作成を任せました。初回の実行はノンストップで3日間のアップグレード作業になりました。長時間にわたるタスクには subagent を複数使うことを強く推奨します。各依存を独立したコンテキストで処理することが、信頼性あるアップグレードには不可欠です。

私たちが与えた実際の手順は次の通りです:

  • 依存を一つ選ぶ
  • subagent に前段のノートを参照させる
  • 1〜3 人の subagent に指定されたバージョンへのアップグレードを試行させる
  • 完了したら reviewer subagent に変更をレビューさせる
  • yarn lint, tsc, および react native bundle を実行し、出たエラーを修正
  • iOS と Android の EAS ビルドを作成し、ビルド成功を検証。出たエラーを修正
  • 最終的な iOS + Android の EAS Build を作成
  • PR を作成し、ビルド結果、手動 QA 手順、影響のある画面などを記載

私が戻ってきたときには、レビューすべき多数の PR が並んでいました。PR を確認するのは非常に速かったです。もちろん、一部の PR はエンジニアの密接な関与が必要でしたが、エージェントがすでに PR 内に文脈、ドキュメント、関連 GitHub issue などを添えてくれていたため、作業は容易でした。

私たちの経験では、New Architecture のビルド問題をデバッグするのに合計で1週間ほど費やしました。全体のアップグレード作業は当初見積もりの2–3ヶ月から数週間に短縮されました。四半期の作業がスプリント1つ分に変わったようなものです。私たちの依存関係の状況がかなり深刻だったため、より小さいアプリならさらに短く済むでしょう。もちろん仕上げ作業は残りましたが、作業の大部分は完了しました。

Phase 4: QA、ロールアウト、監視

安全なリリースを目指して、社内の同僚にアプリを使ってもらいバグを指摘してもらいました。社内で QA パーティーを開き、多くの人に参加して QA をしてもらうのは非常に生産的でした。

ローリングリリースは iOS と Android のスローロールアウト機能を活用しました。まず iOS をリリースし、iOS の状態に自信がついてから Android をリリースしました。

監視: エラートラッキングの仕組みを必ず導入してください。加えてパフォーマンスプロファイリングをアプリに統合することを推奨します。多くの選択肢がありますが、例えば Expo Observe などがあります（私たちはプライベートプレビューに参加していました）。

また、エージェントにエラーの監視と修正を任せる運用も行いました。QAパーティーや本番で届いたエラーに対して、エージェントは最小限のエンジニア関与で大半のバグを解決できました。驚いたことに、New Architecture によって顕在化した高メモリ使用の問題以外に大きな新規エラーは見られませんでした。全体のエラー数はむしろ減少しました。これは、エンジニアが複雑な問題解決や十分な QA に時間を使える一方で、エージェントがその他の作業をこなしてくれたためだと考えています。

結論

AI はエンジニアの働き方を変えています。ドキュメントの読み漁り、締め切りとの戦い、不可解な問題のデバッグに費やしていた時間は近い将来過去のものになるかもしれません。このアップグレードは、AI エージェントが重要で難しいプロジェクトの信頼できるパートナーになり得ること、そして AI 支援エンジニアリングの真のメリットはエンジニアを置き換えることではなく、彼らを単調で骨の折れる作業から解放し複雑な問題に集中させることにある、という証明でした。

How Hipcamp upgraded Expo SDK versions with Claude Code | Expo | DocsDigest