AIエージェントを使ってコードを１行も書かずにフロントエンドアプリケーションを作ってみました

はじめに

こんにちは。パーソルキャリア　新規サービス開発統括部デザイン&エンジニアリング支援部の高屋です。バックエンドエンジニアとして、主にwebサービスのソフトウェアアーキテクチャの設計やAPIの設計、実装などを担当しています。

今回、とあるプロジェクトのPOCで、フロントエンドの実装にAIエージェントを使ったので紹介します。

はじめに
- AIエージェント
- ほんとにできるの？
やってみた
感想

AIエージェント

生成AIについてはもう知らない人はいないかと思います。エンジニアなら翻訳や命名、テストデータの作成やリファクタリング案の壁打ちなどに活用されている方も多いでしょう。

しかし、AIエージェントはまだ使ったことがない人もいるかも知れません。簡単に説明すると、

日本語などの自然言語で要求するだけで、自立してアプリケーションの作成をAIが行う

ものになります。

つまり、コーディング途中にコードを補完してくれたり、チャットで質問して回答をもらったりではなく、日本語で仕様を伝えればアプリケーションを作ってくれるというものです。

ほんとにできるの？

技術ブログや共有コミュニティで目にしていたものの、正直試すまで半信半疑でした。というのも、ご存知の通り生成AIには ハルシネーション があり、たまにおかしな回答をしてくることがあります。また、生成するコードも（生成する量が多ければ多いほど）動かなかったり、動くけど読みづらかったり、保守性が悪かったりというケースがあるわけです。

AIが自立して関数やクラスを作るのではなく、アプリケーションを作るのはまだ無理なんじゃないかな？と思っていたのです。

やってみた

まぁいろいろ考えるよりやってみよう、ということで知見も多いであろうfirebase authenticationと連携してサインインする部分を試しにやってもらうことにしました。

使ったAIエージェントは、Jetbrainsのjunieです。選定の理由はもともとJetbrains製のIDEを使っていたので、というだけです。一般的にはGithub copilot AgentやClaude Code Actionsなどのほうが有名かもしれません。

guidlines.mdを作成する

他のAIエージェントでも同じかと思いますが、

環境
ディレクトリ構成
コーディング規則

などを書く guidelines.md を作ります。

# Project Guidelines
    
このガイドラインは、AIアシスタントJunie用のものです。

## 概要
本ドキュメントは、JetBrains Junieでアプリケーションを作成するルールをまとめたものです。

### 言語

- Junieの回答、応答はすべて日本語とします。
- プロジェクトで使う言語は日本語だけです。
- プロジェクト内のドキュメント、コメントもすべて日本語です。

### 環境

- Vue 3
- Vite
- Vue router
- TypeScript
- Vuetify 3

これらをローカル環境のDockerで動かします。

ローカル環境のDockerfileは、`Dockerfile.local`と命名してください。


## 各種コーディング規則

### 命名規則
- ファイル名：PascalCase
- 変数名：camelCase
- クラス・インターフェース：PascalCase
- 定数：大文字

### コードスタイル
- インデントは2スペース（Vue公式推奨 & Prettierデフォルト）
- scriptタグは`<script setup lang="ts">` を推奨
- コンポーネント props は 型指定必須
- index.ts を使ってディレクトリ単位でエクスポート集約（Barrel Pattern）
- 1行は 最大120文字 
- セミコロン必須
- ESLint + Prettier を必ず適用

###  セキュリティ対策
- 入力値のバリデーション必須
- HTMLを直接レンダーしない（XSS対策）
- 外部ライブラリは最新版に更新

## 作成したいアプリケーション
このguidelines.mdと同じ場所に
`spec.md` が配置されています。それを参照してください。

## 説明
README.mdを作成し、起動方法や環境構築手順などを記述してください。

といった感じです。チームで開発している方にはおなじみの「基本ルール」です。

仕様を書く

guideline.mdに続けて書いてもよいですし、別ファイルに書いても構いません。今回はspec.mdに記述しました。

# 作成するアプリケーションの仕様

## 前提
デザインはVuetify 3を採用し、レスポンシブ対応とします。

## エラー
エラーは赤文字で表示します。

# 認証・認可画面

firebase authenticationを使用し、bearerトークンを取得することが目的です。

## サインインの永続化
一度サインインすると、リフレッシュトークンが失効するか、自らサインアウトするまでサインイン状態は永続します。

## サインイン画面
- メールアドレス・パスワードを入力し、サインインします。
- サインインできたら、メイン画面に遷移します。
- パスワード再設定画面へのリンクがあり、それをクリックすると、このあとのパスワード再設定画面へ遷移します。

## パスワード再設定
- メールアドレスの入力欄があります。
- メールアドレスを入力してサブミットすると、firebase authenticationからメールが届き、再設定の手続きが続けられるようにしてください。
- サインイン画面へ戻る導線が必要です。

## サインアウト
- 画面ヘッダーにハンバーガーメニューを設け、そこに「サインアウト」メニューを設けます。
- サインアウトがクリックされると、サインアウトを実行し、サインイン画面へ遷移します。

# メイン画面

まだ機能はなくてよいです。サインインに成功しましたというテキストが表示されていれば問題ありません。

# firebase の接続情報

## config



## Bearer Token が失効していた場合のバックエンドからのレスポンス

http-status-code: 401
{"message": "Expire id token"}

このレスポンスだった場合、リフレッシュキーを用いてtokenを再取得し、バックエンドへリクエストのリトライをします。

上記メッセージ以外の401は、ユーザーがないなどの理由でログインに失敗しています。

いざ実行

junieのチャット欄に

 .junie/guidelines.md を確認してください。
これに基づき、サインイン画面を作成してください。

と入力して実行しました。あるのはguidelines.mdとspec.mdだけです。Dockerfileもなければ、package.jsonもない状態で、本当にできるんでしょうか…

できた

画面にPlanと表示され、何やら生成AIが自分で環境作成して、コーディングして…といった計画が表示されてぐるぐる動いています。ちら見した感じですが、計画の内容や順序は一般的な方法どおり。

数分後、Doneというメッセージがでました。その間、およそ5分弱。本当かなあ？？検証方法はREADME.mdに書いてもらっているので見てみます。

# ローカル開発

本プロジェクトは Vue 3 + Vite + TypeScript + Vuetify で構築されています。ローカルは Docker を用いて起動します。

## 前提
- Docker / Docker Desktop がインストール済み

## 起動手順（Docker）
1. イメージをビルド

   docker build -f Dockerfile.local -t persona-front .

2. コンテナを起動

   docker run --rm -it -p 5173:5173 -v "$PWD":/app -w /app persona-front

   - 初回は依存関係の解決が走ります。
   - 起動後、Vite のアドレス `http://localhost:5173/` にアクセスしてください。```

なるほど、すごいなあ。起動手順どおりに実行してみると…おおすごい…できてる…

firebase authenticationとの連携もバッチリで、サインイン、サインアウト、パスワード再設定などすべて完璧にできていました。

感想

この後、アプリケーションの仕様をファイルに記述し、見事に1日でアプリケーションが完成しました。Vuetifyをつかったデザインとはいえ、それなりの見た目でレスポンシブ対応です。ベテランのフロントエンドエンジニアさんでも、環境作るところから初めて4画面とはいえ1日でこなすのはギリギリかと思いますので、見事な生産性です。

仕様ありき

とはいえ、いいことばかりではないと思います。

AIエージェントが作るのはあくまで仕様ありき、なので、guidlines.mdなどに記述する環境やアプリケーションの仕様を、抽象的な部分をできるだけ排除して記述できるか、が鍵になってくるかと感じました。人間のエンジニアならなんとなく汲み取ってくれた暗黙的な仕様や挙動などは、当然考慮しません。逆にそれを補うために一般的な仕様や挙動で埋めようとします。

これを便利と取るか、融通がきくと思うかは使う人次第ですが、一般的にはPOCやプロトタイプなら許容されても、プロダクトとしてはなかなか厳しい部分もあるのではないでしょうか。