https://tech.leverages.jp/entry/2025/07/22/193341

こんにちは！テクノロジー戦略室AI推進チームの苑田です！ AWS Summit 2025 生成AIハッカソンがあり、全部で150チームほど参加した中、準優勝することができました！その時に試したAI駆動開発を時系列順でまとめました！

作成したアプリに関しては別のメンバーが記事を書いてくれたので、一緒にみてもらえるとイメージしやすいと思います！

AWS Summit 生成AIハッカソンで準優勝しました！

AI駆動開発で使用したツール

GitHub Copilot
GitHub Copilot Coding Agent
GitHub
v0

担当範囲

苑田：AI Agent(Strands Agents)周り、Backend
メンバーA：Backend、スライド作成
メンバーB：Backend、デモ動画作成
メンバーC：Frontend

開発までのスケジュール

6月25日に予選があり、作ったアプリケーションを披露する必要があります。スケジュールは上記の通りですが、通常業務や諸々の対応をしていると、実際の構築期間は３週間となりました。当然、通常業務もあるので、メンテ性と可読性の品質を担保する開発ではなく、スピード重視のVibe Codingで進めることにしました。

Vibe Coding

人間がコードを書かずに自然言語でLLMアプリに指示して開発することをVibe Codingといいます。とはいえ、適当に開発すると変なコードが出来上がるので、以下の順番でコーディングするようにしました。

作りたいものをAIと壁打ちして要件を決める
AIに詳細設計を作成してもらう
何をすべきかTODOリストを作成してもらう
どのAIでもタスクを処理できるように、GitHub IssuesにTODOを登録する
Issueを元にAIがコードを書く
AIがPRを作成する
PRをレビューして問題なければマージ

できるかぎり人間の動作を減らすために、Issueの登録やPRの作成はGitHub MCPを使って自動化しました。下記のようにcopilot-instructions.mdにOrganizationとリポジトリの詳細を記載することで、エンターキーを押すだけで開発が進んでいきます。

<!-- I want to review in Japanese. -->
# リポジトリ
- Organization: "現在の組織"
- repository: "現在のリポジトリ"
<!-- I want to review in Japanese. -->

また、「なぜGitHub issuesを使うのか」という話は後で出てきます。

AIの書いたコードを全て許可する

Vibe Codingをしていると、AIの開発スピードが早すぎてレビュワーの負荷がかかり、人間がボトルネックになってしまいます。なので、基本的にAIが書いたコードは全て許可する方針で開発を進めました。

これは実験的な部分もあったのですが、今後AIが賢くなって行った時に、全部AIが開発、運用、テスト、レビュー、修正をやってくれるといいよね！とチーム内で会話になったのがきっかけです。

設計は人間が行い、開発、修正に関してはAIに任せるというスタイルで開発を進めました。

黒☆魔☆術コードができてしまった

基本的にレビューせずに即マージすることはまずあり得ないので、とても気持ちが良くポチポチマージしていました。このタイミングではもうすでに人間が読めるコードではなくなっており、これが本当のVibe Codingと意味不明なことを言ってました。しかし、発表１週間前に大問題が発生しました。

これAPIから取ったデータを表示してないんじゃね？

どういうことかというと、APIからデータを取得してフロントに表示するはずが、毎回同じデータを返してくるという問題が発生しました。

調査した結果、AIエージェントが処理を失敗した時に返す値をそれっぽい固定値で設定しており、APIと連携できていなくとも、きちんとした値を返すようにしていたのが原因でした。

例：
def analyze_sentiment(self, text):
    try:
        # 実際のAPI呼び出し
        response = self.sentiment_api.analyze(text)
         return response['sentiment']
     except:
        # API失敗時の固定値フォールバック
        return "neutral"

例のように、API呼び出しが失敗したとしても、「neutral」が返ってくるので、フロントエンドではエラーが発生しません。

よくよく考えると、AIエージェントは目的を達成するためにタスク分解して処理をするので、最終的なゴールがフロントに表示することであれば、こういうコードを書いてしまうのは当然でした。

「なるほどな〜」と思いながらリファクタリングをしようとしたのですが、人間の介入はしない前提で開発を進めていたため、ここからが地獄の始まりでした。

人間によるリファクタリング

発表１週間前に黒魔術コードが完成してしまったので、以下の内容でリファクタリングを行うことにしました。

過剰なtry-exceptを削除
エラーが発生した時に文字列ではなく、エラーコードを返すように修正
人間が確認しやすいように、ディレクトリ構成を整理
APIの疎通ができていない箇所を修正

先ほど記載した通り、AIエージェントは目的を達成するためにコーディングするので、大量のtry-exceptを生成します。なので、不必要なtry-exceptは削除し、エラーが発生した場合、すぐ検出できるように変更しました。

また、とてつもない量のファイルやコードを生成するので、人間が全部確認するのは不可能と判断し、人間が確認しやすいようにディレクトリ構成を整理しました。この時はわかりませんでしたが、ディレクトリ構成や内容をREADME.mdに記載すると、AIの迷いが少なくなった気がします。

APIの疎通に関しても、Mockを大量に生成していたので、全て削除しました。

これらの作業に丸3日かかりましたが、なんとかBackendだけリファクタリングを終えることができました。 Frontendは私の担当ではないのでなんとかしてもらおうという魂胆です。当然担当は地獄を見ていました。

AIが開発しやすいような開発環境の作成

発表まで残り4日。リファクタリングが終わり、AI駆動開発がなかなかうまくいかないなぁと思いながら開発していたのですが、1つの仮説が浮かびました。それは、AIが開発しやすいような開発環境を用意すれば、AI駆動開発がもっと楽になるのではないかということです。

今まではAIが好き勝手にコードを書いていたのですが、AIが必要な情報を取得できないと関連する箇所を次々と調査してしまい、本来の目的を見失ってループに入ってしまいます。したがって、AIが効率的に必要な情報へ辿り着けるよう、専用ツールを作成しました。

docker-compose関連のコマンドを叩くシェル
- ワンコマンドでAIが使用できる
MCPの活用
- GitHub MCPを駆使して、AIが自動でIssueやPRの確認、作成できるようにする
- Strands AgentsのDocs MCPを使用することで、最新の情報でもドキュメントを参照できるようにする
git worktreeの活用
- 複数のブランチを同時に開発できるようにする(これは長いので下で書く)

作成したツールをAIに使用してもらうために、copilot-instructions.mdで以下のような指示を書きました。

# 利用可能なスクリプト
- `./scripts/run-dev.sh` - 開発環境の起動（自動ポート割り当て）
- `./scripts/status-dev.sh` - 全worktreeの状況確認
- `./scripts/stop-dev.sh` - 環境停止
- `./scripts/create-worktree.sh` - 新worktree作成
- `./scripts/remove-worktree.sh` - worktree削除

# AIエージェント向け指示
- `docker-compose logs` などの標準コマンドは使用禁止
- 環境の状況確認は `./scripts/status-dev.sh` を使用
- ポート競合やログ確認が必要な場合は上記スクリプトの出力を参照

これにより、人間がやることを極限まで減らし、AIが開発しやすい環境を整えることができました。以下の画像は、AIが実際に叩くシェルの例で、今このプロジェクトでどのコンテナが動いているかを確認できます。

このようなツールを用意してルールに記載しておくと、ツールを使った結果をAIが確認し、それを元に修正をするようになります。

例えば、エラーが発生した時に以下の手順でAIは修正します。

ステータス確認シェルでコンテナの状況を確認する
確認したコンテナ名やステータスを元に、ログ確認シェルを使用し、ログを確認する
対象箇所を調査する
修正する
動作確認し、エラーが無くなれば終了

このように、適切なツールを渡すことで、変なことをする回数が減りました。

git worktreeによる並列開発

AIが開発しやすい環境を作ってうまく開発ができてきました。しかし、待ち時間が暇なんですよね。 Twitterを見ると怒られるし、どうしようかなと考えていたら、AIがコードを書いている間に、別のブランチで開発を進めることができるかもしれないと思いつきました。

そこで、git worktreeを使って、複数のブランチを同時に開発できるようにしました。 git worktreeの説明は以下のブログが参考になります。

AIエージェントで並列実装なら必須技術！ Git Worktree を理解する

git worktreeを使うと、AIが開発する環境を簡単に作成できます。私はworktreeを作成、削除するシェル(script以下)を用意しており、以下の構成で使用していました。親は基本的にworktreeを作成、削除、本番環境のデプロイを行う場所で、子はAIが実際に開発する場所と定義していました。

ここで必要なのが、AIが動作確認するための環境です。 docker-composeを使用しているため、並列で開発しているとportが枯渇する問題が発生しました。なので、portを動的に割り当ててdocker-compose upするシェルを作りました。これにより、AIが簡単に動作確認できます。

また、git worktreeを使用することで、以下のメリットがありました。

AIがコードを書いている間に、別のブランチで別のIssueを進めることができる
同じIssueを複数のAIに処理させ、一番いいものを採用できる

1つ目はそのままですが、2つ目が結構便利でした。 AIは同じプロンプトでも生成する内容が異なるため、２〜4並列でAIに同じプロンプトで生成させ、その中でいいものを選択していました。私たちはこの開発をリセマラ駆動開発と呼んでいます。

完成！

無事予選前日の深夜12時にアプリケーションが完成しました。なんとか完成したのでワイワイしていると、スライド作成していないことに気づき、予選当日の開始１時間前にスライドが完成しました。ここら辺の話は色々あったので、また別のタイミングで話せたらなと思います。

実際にAI駆動開発やってみた結果

今回色々な仮説をもとに検証を行なっていましたが、AIが開発しやすい環境を作成した途端、爆発的に開発が進みました。 AIが指示通りに動いてくれない理由は、考えることが多すぎて変な方向に進んでいくからという結論になりました。AI駆動開発はコーディングしてもらうだけだと思っていたので、タスクを処理しやすいように環境を整えてるのは新鮮で面白かったです。

また、ある程度コードを人間が読めるようにする必要があると感じました。今回はハッカソンだったので最悪全部壊せばいいですが、本番稼働しているアプリだと必ず人間がリファクタリングする必要があります。したがって、ある程度人間が読めるようにドキュメントを整備したり、コーディング規約を言語化しておくことで、最悪の事態は避けられると思います。

どうすればもっと開発が楽になるか考えてみた

ひとまずアプリをリリースできましたが、今後組織に普及していくために、チーム内でどうすればもっと開発が楽になるかを考えました。話題として上がったのがAIが暴走してしまい、人間が対応するのが大変だったという点です。実際に試したわけではないので話半ばで聞いて欲しいですが、チーム内で結論付けたことを記載しておきます。

テストを書く

今回スピード重視で開発していたため、テストを書かずに構築していました。しかし、AIは目的を達成するために、モックを作ったり、都合のいい処理を書いたりします。明確なテストを用意しておくことで、ある程度この暴走は抑えられるのではないかと考えました。

また、AIがすごいスピードでリファクタリングするので、いきなりコードが動かなくなることも多々ありました。その観点でも、テストがあると人間は安心でき、AIもテストが失敗したら修正を行なってくれるので、チーム内では必須だと結論付けました。

しかし、テストを書いたとしても、そのテストが通るようにコードを生成したりするので、ある程度人間がレビューする必要があります。

プロンプトを使い分ける

copilot-instructions.mdに守って欲しいことや設計手法など全部記載しても、AIは完全にそれ通りに動くわけではないことを学びました。したがって、TODO作成プロンプト、構築プロンプト、テストプロンプトのように、プロンプトを分けることで役割分担するのもいいのではないかと考えました。

今回のハッカソンでは、各専門エージェントを使用したマルチエージェントで構築しており、1つのエージェントで構築するより精度が向上しました。

この要領でプロンプトを分ける(claude codeだとカスタムスラッシュコマンド)と、AIが暴走することは少なくなると思います。