AIエージェントに任せて、新機能を開発してみた

公開日：2026/07/06

技術ノウハウ・Tips設計・アーキテクチャ

こんにちは、FREEMINDでAI活用を担当している俊也です。

今回は、英語学習システム「Lepton」に新機能「AIスピーキング」を追加した開発プロジェクトの裏側を紹介します。

特筆すべきは——この機能、私が手で書いたコードは0行だということ。
フロントエンド（Next.js / React）からサーバー処理、音声を扱うAPIやS3・DB連携まで、すべてGitHub CopilotのAgentモード（中身はClaude）に書かせました。

「AIにコードを書かせる」と聞くと、補完やちょっとした関数生成を思い浮かべる方が多いと思います。
でも今は、設計さえ人間が固めれば、機能まるごとをAIエージェントに任せられるところまで来ています。
この記事では、実際にやってみて分かった「効果」と「落とし穴」、そして明日から始める方法までお伝えします。

作ったもの：英語の発音を自動採点する「AIスピーキング」

まず、何を作ったのかから。

Leptonは英語の学習システムで、生徒は「Day」という単位で少しずつ学習を進めます。今回追加した「AIスピーキング」は、生徒が画面の英単語・英文を声に出して読み上げると、その発音をAIが自動で採点してくれる機能です。

生徒側の画面はこんな感じ。単語が表示され、「録音する」ボタンを押して発話します

（※AIスピーキングのテスト画面。生徒が単語を見て発話し、録音ボタンで音声を提出する）

発話した音声は、クラウドの発音評価AIに送られ、文ごとに点数化されます。講師が見る採点結果の画面がこちら。

（※AIスピーキングの採点結果画面。文ごとに点数が出て、80点以上は緑、60〜79点は黄、59点以下は赤で色分けされている）

80点以上は緑（合格）、60〜79点は黄、59点以下は赤、と一目で出来栄えが分かる色分けにしています。録音した音声もその場で聞き返せます。

システム構成：使っている技術

裏側の仕組みも簡単に紹介します。全体像はこの図の通りです。

（※システム構成図。生徒がNext.js（React）の画面で英文を録音し、サーバー（Next.js + Express）が受け取って、S3・発音評価AI・PostgreSQLの3つに連携。採点結果は講師の結果画面へ表示される）

フロント／サーバー：Next.js（React）+ Express：画面表示も、AIへの橋渡しをするサーバー処理も、Next.jsをベースに構築。サーバーはNext.jsをExpressのカスタムサーバーでラップしています
音声保存：AWS S3：生徒が録音した音声ファイルをアップロード
発音採点：クラウドの発音評価AI：音声を解析し、発音をスコア化（この記事の主役の技術）
スコア保存：PostgreSQL：採点結果を保存し、講師の結果画面に表示

生徒が話す → 音声をS3に保存 → 発音評価AIで採点 → スコアをPostgreSQLに保存 → 講師が結果を確認、という流れです。

なぜAIエージェントに丸ごと任せたのか

正直に言うと、最初から「全部AIに書かせよう」と決めていたわけではありません。

きっかけは、この機能が発音評価AIやS3、音声のアップロード処理など、自分が普段あまり触らない技術領域を含んでいたことです。ゼロから調べながら書くと時間がかかる。そこで「未知の技術こそAIに任せたら速いのでは？」と考え、思い切ってAgentモードに全部任せてみることにしました。

結論から言うと、この判断は当たりでした。理由は後述します。

「コード0行」を実現したAgentモードとは

使ったのは、IntelliJ上で動く GitHub Copilot ChatのAgentモードです。モデルにはClaude（Opus）を指定しました。

普通のコード補完と何が違うのか。ポイントは「自律性」です。

Agentモードでできること

自然言語で指示するだけ：「この機能を作って」と書くと、AIがプロジェクト内のファイルを自分で探し、読み、必要な場所にコードを書きます
コードベース全体を理解する：プロジェクトの構造を把握したうえで、適切な場所に適切なコードを配置してくれます
対話で修正できる：「ここをこう変えて」と返すだけで、文脈を保ったまま繰り返し改善できます

実際の指示は、たとえばこんな粒度で渡していました。

DAY単位のスピーキングテスト機能を作りたい。
- 生徒が単語/英文を見て録音、音声をS3にアップロード
- アップロード完了後、発音評価AIのAPIに投げてスコアを取得
- 文ごとのスコアをDBに保存し、講師の結果画面で色分け表示（80以上:緑 / 60-79:黄 / 0-59:赤）
- マイク権限がない場合・ネットワーク不良時のエラーハンドリングも入れて

このレベルの自然言語の指示から、AIがファイルをまたいで実装を組み上げてくれます。IntelliJさえあれば今すぐ使えるのも大きな魅力でした。

ただし、設計はすべて人間がやった

ここが一番伝えたいところです。

コードは0行でも、設計は100%自分でやりました。具体的にはこの4つ。

要件定義：どんな問題パターンにするか、色分けのルール、再テストの仕様などを、関係者との打ち合わせで詰める
テーブル設計：6テーブル構成、UNIQUE制約、テスト状態を管理するステートマシンの設計
API設計：問題取得・回答提出・結果参照・可否判定。処理フローまで詳細に定義
リスク管理：マイクが使えないとき、ネットワークが不安定なとき、端末の容量が足りないときの対処策

AIに渡せるのは「どう作るか」であって、「何を作るか」ではありません。設計・判断・意思決定は、依然として人間の仕事です。Notionにかなりの量の設計ドキュメントをまとめ、それをAIに読み込ませる形で進めました。

AIに丸投げ＝楽、ではありません。
むしろ「曖昧さのない設計」を用意できるかどうかが、AI開発の成否を分けます。

開発プロセスと、体感の工数削減効果

実際の開発は、次のサイクルの繰り返しでした。

機能を小さく分解する
自然言語で指示を書く
AIが実装する
人間がレビューする
動作確認 → 修正指示を出す

開発期間は約4ヶ月。体感ですが、工数はおよそ4割削減できたと思います。

ただし、ここで意外だったのは時間の使い方です。コードを書く時間より、レビューと動作確認の時間のほうが圧倒的に長かったのです。これは後で「役割の逆転」として効いてきます。

やってみて良かったこと

実体験として、良かった点は次の通りです。

実装スピードが圧倒的に速い：手で書いていたら何日もかかる部分が一気に出来上がる
自分より論理的な設計が出てくることもある：素直に「なるほど」と思う実装が返ってくる場面も
未知の技術が怖くなくなる：今回の発音評価AIのSDKのように、触ったことのない技術でもスムーズに導入できた
やり直しコストが激安：気に入らなければ作り直してもらえばいい。試行錯誤のハードルが一気に下がる

特に「未知の技術への参入障壁が激減する」点は、AI開発の一番のインパクトだと感じています。

やってみて困ったこと

一方で、正直に困った点も。むしろこちらのほうが学びは大きかったです。

一度に大量実装されてレビューが爆発する：指示が曖昧だと、AIは大量のコードを一気に書いてくる。結果、レビューが追いつかない
既存の命名規則やルールを無視してくる：プロジェクト独自のルールは、明示しないと守ってくれない
テストがないと手動確認の地獄：テストを用意していなかったため、動作確認がすべて手作業になった
結局コードを全部読まないと不安：「AIが書いたから大丈夫」とは思えず、自分で全部読んでしまう

これらは「AIが悪い」のではなく、任せ方の設計が甘かったということ。次に活かせる学びになりました。

気づき：人間がAIの「外付けモジュール」になる

このプロジェクトで一番印象に残った気づきがあります。

それは、自分がコーディングしている時間より、AIの手となり足となって動作確認やバグチェックをしている時間のほうが長かったということ。AIが書く → 自分が動かして確認する → フィードバックを返す、の繰り返し。

まるで人間が、AIの「外付けモジュール」になったような感覚でした。これは比喩ではなく、実際に役割が逆転していたのだと思います。

次にやるなら：AI開発を成功させる4つのポイント

困ったことの裏返しとして、「次はこうしたい」という学びが4つあります。

ガードレールは『仕組み』で敷く
プロンプトで「これはやるな」と書いても、AIは平気で破ります。テスト・lint・型チェック・CIで、物理的に弾く仕組みを用意するのが正解。
テスト駆動にする
そもそもAI開発ツールは「テストが通れば完了」という前提で設計されています。全行を人間が読むのは非現実的。テストを正とする運用に切り替えるべき。
タスクは極小に分解する
タスクが大きいとレビューが不能になります。「1ファイル・1関数」レベルまで小さく割って依頼するのがコツ。
ルールを明文化して毎回渡す
命名規則やディレクトリ構造をドキュメント化し、AIに毎回読み込ませる。暗黙の了解は通じません。

興味深いのは、これらがClaude CodeやDevinといった最新のAI開発ツールの設計思想とぴたりと一致していること。「AIに任せやすいコードベース」は、人間にとっても良いコードベースなのだと思います。