はじめに

フロントエンドとバックエンドを別リポジトリで管理しているプロジェクトは多いと思います。

僕も最初は、AI に実装を頼むときに「まずフロントエンドを見てもらう」「必要になったらバックエンド側のリポジトリへ移動する」という流れで作業していました。ただ、毎回リポジトリを行き来するのが地味に大変でした。

どうにかして両方のリポジトリを一緒に開き、AI が同時に読める状態にできないかと思っていたところ、VS Code の .code-workspace を知りました。

実際に使ってみると開発体験がかなり良くなったので、この記事では、最小構成の .code-workspace と、AI に両方のリポジトリを見せると何が嬉しいのかを整理します。

.code-workspace とは

.code-workspace は、VS Code で複数のフォルダを 1 つの workspace として開くための設定ファイルです。

通常は 1 つのリポジトリを 1 つのウィンドウで開くことが多いですが、.code-workspace を使うと、別々の場所にあるフォルダをまとめて 1 つのウィンドウで扱えます。

今回のようにフロントエンドとバックエンドが別リポジトリになっている場合でも、同じ workspace に入れておけば、AI エージェントが両方のコードを同時に参照しやすくなります。

やりたいこと

たとえば、次のような構成を考えます。

my-app/
├── backend-test/
│   ├── backend-frontend.code-workspace
│   └── src/
│       └── server.js
└── frontend-test/
    └── src/
        ├── apiClient.js
        └── main.js

backend-test と frontend-test は別リポジトリです。

この 2 つを VS Code で同時に開けるようにします。

code-workspace の設定

backend-test/backend-frontend.code-workspace を作ります。

今回は、同時に開きたいフォルダだけを設定します。

{
  "folders": [
    {
      "name": "backend-test",
      "path": "."
    },
    {
      "name": "frontend-test",
      "path": "../frontend-test"
    }
  ]
}

VS Code では次のように開けます。

code backend-test/backend-frontend.code-workspace

Cursor を使っている場合は、次のように開けます。

cursor backend-test/backend-frontend.code-workspace

なぜ便利なのか

一番大きいメリットは、AI が「画面から DB までの流れ」を追いやすくなることです。

画面コンポーネント
↓
API 呼び出し処理
↓
バックエンドの route
↓
Controller
↓
Model / migration
↓
DB カラム

フロントエンドだけを開いていると、AI は API の中身を推測するしかありません。

バックエンドだけを開いていると、API の変更が画面にどう影響するか見えません。

両方を同時に開いておくと、AI がこの間を行き来しながら考えられます。

1. API と画面のつながりを追いやすい

たとえば、フロントエンドに次のような API 呼び出しがあるとします。

fetch("/api/tasks");

フロントエンドのリポジトリだけを見ている場合、この API がどんな値を返すのかはコードからはわかりません。

でも、同じ workspace にバックエンドも入っていれば、AI は route を見に行けます。

Route::get('/tasks', [TaskController::class, 'index']);

さらに、Controller、Model、migration まで追えます。

その結果、次のようなことを判断しやすくなります。

この API は何を返しているのか
フロントエンド側の型とレスポンスの形が合っているか
画面に表示されない値は、どこで欠けているのか

人間が調査するときに自然とやっている「呼び出し元から実装までたどる」作業を、AI にもやらせやすくなるイメージです。

2. 修正漏れに気づきやすい

バックエンドだけを見ていると、API レスポンスを変えたあとに、フロントエンド側の型や表示処理を直し忘れることがあります。

逆にフロントエンドだけを見ていると、「画面ではこの値が必要そうだけど、そもそも API が返していない」ということに気づきにくいです。

たとえばバックエンドが次のようなレスポンスを返しているとします。

return [
    'id' => $task->id,
    'title' => $task->title,
];

フロントエンド側では次の型で受け取っているとします。

type Task = {
  id: number;
  title: string;
};

ここで title を name に変えるなら、バックエンドの返却値だけでなく、フロントエンドの型、API 呼び出し、表示箇所も合わせて直す必要があります。

両方のリポジトリが見えていれば、AI に「画面側も合わせて見て」と言いやすくなります。

3. 不具合調査が速くなる

たとえば「タスク名が画面に出ない」という不具合を調べるとします。

フロントエンドだけだと、コンポーネントや API 呼び出しまでは追えます。ただ、その API がバックエンドでどう処理されているか、DB からどのカラムを読んでいるかまでは見えません。

バックエンドも同じ workspace に入っていれば、次のように一気に追えます。

画面コンポーネント
↓
API 呼び出し処理
↓
Laravel の route
↓
Controller
↓
Model / migration
↓
DB カラム

原因がフロント側の表示ミスなのか、API の返却漏れなのか、DB カラム名の違いなのか。候補を絞るまでの時間が短くなります。

4. 命名のズレを見つけやすい

フロントエンドとバックエンドを別々に見ていると、地味に見落としやすいのが命名のズレです。

たとえばバックエンドが次の JSON を返しているとします。

{
  "is_completed": false
}

一方で、フロントエンドは次の名前を期待しているかもしれません。

isCompleted

片方だけ見ていると、この違いは意外と見落とします。

両方を同じ workspace に入れておけば、AI が「バックエンドは snake_case、フロントエンドは camelCase を期待している」と気づきやすくなります。

5. 少し大きめの変更を頼みやすい

たとえば「タスクに期限を追加する」という変更を考えます。

この変更は、バックエンドだけでもフロントエンドだけでも完結しません。

migration
Model
Controller
API レスポンス
フロントエンドの型
一覧画面
期限の入力フォーム
期限の表示
テスト

画面から DB まで、いくつかの場所に修正が広がります。

こういう変更を AI に頼むとき、片方のリポジトリしか見えていないと、どうしても途中で情報が足りなくなります。

.code-workspace で両方開いておけば、次のように頼めます。

タスクに期限を追加してください。
画面、API、DB まで必要な修正を一通り見てください。

AI がフロントエンドとバックエンドを同時に参照できるので、画面だけ、API だけ、DB だけの修正で止まりにくくなります。

まとめ

.code-workspace を使うと、別リポジトリのフロントエンドとバックエンドを 1 つの workspace として開けます。

設定は最小なら folders だけで十分です。

フロントエンドとバックエンドを同時に AI に見せると、AI が画面から DB までの流れを追いやすくなります。

その結果、次のようなメリットがあります。

API と画面のつながりを追いやすい
修正漏れに気づきやすい
不具合調査が速くなる
命名のズレを見つけやすい
少し大きめの変更を頼みやすい

さいごに

実際に .code-workspace を使ってフロントエンドとバックエンドを同時に開くようにしてから、AI エージェントでの開発体験はかなり良くなりました。

設定自体はかなり軽いので、フロントエンドとバックエンドを別リポジトリで管理していて、AI エージェントを使って開発している場合は、ぜひ導入してみるのをおすすめします。