はじめに
フロントエンドとバックエンドを別リポジトリで管理しているプロジェクトは多いと思います。
僕も最初は、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 エージェントを使って開発している場合は、ぜひ導入してみるのをおすすめします。