Cursor や Claude Code で追加した画面が認証 SDK を直接呼び出し、別の機能も同じ SDK の内部状態を使い始める。こうなると、認証の変更が関係のない画面まで壊す原因になります。

React Native で AI を使いながら機能を増やすなら、各サービスが公開する操作と、具体的な提供元の実装を分けてください。service boundaries はその分離を定義し、composition root は実装を選んで接続する場所を一つにまとめます。

service boundaries はアプリが所有する interface から始める

画面が必要とするのは「現在の利用者を取得する」「ログインする」といった操作です。SDK 固有のレスポンスやセッションの保存形式まで画面に持ち込む必要はありません。

まずアプリ側で interface を定義し、外部の実装をその契約に合わせます。次の TypeScript は構造を示すための最小例です。実際の認証通信やトークン管理は含みません。

export interface User {
  id: string;
  displayName: string | null;
}

export type AuthResult =
  | { ok: true; user: User }
  | { ok: false; code: "UNAVAILABLE" | "SIGNED_OUT" };

export interface AuthService {
  getCurrentUser(): Promise<AuthResult>;
}

export function createServices(auth: AuthService) {
  return { auth };
}

// A deterministic adapter for a signed-out test scenario.
export const signedOutAuth: AuthService = {
  async getCurrentUser() {
    return { ok: false, code: "SIGNED_OUT" };
  },
};

export const services = createServices(signedOutAuth);

この例では、呼び出し側は AuthService だけを知っています。実際のアダプターでは外部レスポンスを検証し、想定する失敗を AuthResult に変換します。TypeScript の型だけでは、ネットワークから届いた値の実行時検証はできません。

composition root で実装を選び、利用側には依存を渡す

composition root は、設定や実行環境に応じてアダプターを作り、アプリへ渡す場所です。画面ごとに SDK を生成すると、どの実装が使われるかが分散し、差し替えや検証が難しくなります。

composition root
  ├── AuthService を実装するアダプター
  │     └── 認証 SDK / 外部 API
  └── composition hook
        └── React Native の画面

画面は hook から表示に必要な状態と操作を受け取ります。外部 SDK の初期化、レスポンスの検証、失敗の変換はサービス側に残します。composition root の変更も通常の確認と検証の対象です。

AI への指示を import の規則と検証につなげる

「きれいな設計にして」という指示だけでは、守るべき境界が曖昧です。新しい機能を頼むときは、既存の interface、変更を所有する層、許される import、必要な検証を具体的に示します。

  • 画面が外部 SDK や別画面の内部実装を直接 import していないか確認する。
  • サービスの成功、未認証、利用不可の各結果を利用側が扱っているか確認する。
  • 実装の差し替え後も同じ契約を満たすか、contract tests で確認する。
  • プロジェクトで定めた型、依存関係、テストの検証を省略せず実行する。

文章の規則と自動検証は役割が違います。規則は変更の意図を伝え、検証は定義された違反を検出します。どちらも、製品の要件そのものが正しいことまでは保証しません。

提供元の差し替えで変わるものを先に調べる

interface を保てるなら、利用側への変更を小さくできます。ただし、認証方式、更新トークンの扱い、利用者 ID、オフライン時の動作が異なる場合は、アダプターを置き換えるだけでは済みません。

差し替え前に、観測可能な挙動とデータ移行の必要性を確認してください。契約自体が変わるなら、その変更を明示し、利用側と一緒に検証します。「必ず一行で移行できる」という前提は置かない方が安全です。

Autotomy の Expo Foundation での使い方

Autotomy はサービスの責務、依存の境界、機能を追加する手順と基本的な検証を用意します。アプリ用の認証、決済、バックエンドは同梱していません。必要になった提供元を、製品側で選んで追加します。

次の機能では、まず外部サービスに依存する操作を一つ選び、入力、結果、失敗を interface に書き出してください。互換性と対応範囲やコマンド一覧を確認し、変更後に必要な検証を実行します。