DocsDigest
一覧へLanguage: EN
OpenAIExpo2026/04/21 13:15

How Hipcamp upgraded Expo SDK versions with Claude Code

要点だけを先に読めるように短く再構成したセクションです。

元記事
OpenAIClaude

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

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

Hipcamp が Claude Code（Scout）で Expo SDK を短期間アップグレードした方法

exporeact-nativeai-agentdependency-managementnew-architectureeas

Key Points

  • Expo 50→54 を短期間で実施
  • 依存関係をサブエージェントで個別処理
  • Expo モジュールを優先して互換性確保

Summary

Hipcamp は AI エージェント（内部の Scout／Claude Code）を使い、Expo SDK 50 から 54（RN 0.73→0.81、React 18→19）および New Architecture 対応を数週間で完了しました。従来は数ヶ月を要する依存関係調査・バージョン解決を、ドキュメント化・サブエージェントによる個別作業・自動化されたチェックで大幅に短縮しています。

Key Points

  • アップグレード方針

    • 必要な依存のみ対象化、Expo の公式モジュールを優先して置換
    • 16KB Android ページサイズと New Architecture の互換性を最優先で確認
    • patch-package は最後の手段として利用

  • ワークフロー（フェーズ）

    • Phase 1: エージェントにコードベースを学習させる（アーキテクチャのドキュメント化）
    • Phase 2: 依存関係監査をサブエージェント単位で実行（各依存ごとに notes ファイル + SQLite 管理）
    • Phase 3: サブエージェントでアップグレード→レビューワークフロー→yarn lint / tsc / react-native bundle を実行
    • Phase 4: QA（社内 QA イベント）、段階的ロールアウト、監視とパフォーマンス計測

  • 実務的なチェックリスト

    • 各依存で changelog/issues/setup docs を確認し互換性と既知のブロッカーを記録
    • 1 依存 = 1 サブエージェント（バッチ処理禁止）
    • EAS ビルドを必ず作成して iOS/Android を検証
    • PR にビルド成果物・QA 手順・影響画面を添付

  • 成果と注意点

    • トークンコストを投資してエンジニア時間を節約（結果的に短期間で完了）
    • New Architecture でメモリ使用量増加などの挙動差に注意

実践ポイント：依存ごとに小さく分割した自動化（エージェント＋サブエージェント）と、Expo モジュール優先のポリシー、EAS ビルドの早期導入が成功の鍵です。

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

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 支援エンジニアリングの真のメリットはエンジニアを置き換えることではなく、彼らを単調で骨の折れる作業から解放し複雑な問題に集中させることにある、という証明でした。