こんにちは、SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当している貝塚です。
(生成)AIを使用したソフトウェア開発が盛り上がっていますね。AWSまわりを主戦場にしている我々の部署でも Amazon Q Developer や Kiro を使用した開発はホットな話題です。
私も顧客に提供するウェブサイトをインフラからアプリまで一式、Amazon Q Developerを使用して開発したので、その概要と所感を書いてみます。
開発概要
特定顧客向けのウェブサイトです。サイトの内容はQuickSightのURL埋め込み機能を使用してQuickSightダッシュボードを表示するだけのシンプルなものです。取得するダッシュボードのIDなどを取得するためにDynamoDBを、サイトアクセスの認証のためにCognitoユーザプールを使用しました。アーキテクチャ図は以下の通りです。
AWSリソースを作成するCloudFormationテンプレートと、Webサイトのソースコード、すべてを生成AIで開発しました。
開発体制
人数：1人。テスト等でお手伝いしてもらったりしていますが、基本的には私だけです。
ツール：Windows上にインストールしたVSCode + Amazon Q拡張。使用MCPはAWS Knowledge MCP, Documentation MCPなど。WSL UbuntuをインストールしてVSCodeのターミナルからQ CLIを併用。バージョン管理システムはCodeCommitです。
開発期間：言うのが割と本気で恥ずかしいので秘密です。多分、慣れてる人が作ったらあっという間じゃないかな……と。でも生成AIを使った開発のメリットは開発時間の短縮だけではないですよ……ということは後で書きます。
開発開始当初
開発開始当初はAmazon Q Developer Proのサブスクリプションがなかったので、Bedrock (Claude Sonnet 4)で開発していました。しかもマネジメントコンソールのプレイグラウンドを使って……もうこの環境には戻れないですね。
とにかくまずは動くものを作りたかったので、一番最初は
→何度かQ&Aや機能の追加・変更を要望してアーキテクチャを決定
→コードを生成してもらう
→デプロイは自分で手作業(CI/CD環境は作りました)
機能追加・改善は
→何度かQ&Aしてアーキテクチャ・設計を決定
→現在のコードからの変更提案を作成してもらう
→変更提案に納得出来たら修正版のコードを生成してもらう
エラー対応は
→何度かQ&Aや追加で調査した情報を与えて原因を推測し、修正方針を決定
→修正点について変更提案を作成してもらう
→変更提案に納得出来たら修正版のコードを生成してもらう
修正する内容を、コードを実際に修正する前に変更提案という形でC1, C2 … のように通し番号をつけて作成してもらうようにしたのが工夫点でしょうか。例えばこの変更はいらないなという時に、番号が付いていれば指示が出しやすく紛れがないかなと考えました。
この頃は、ソースコードにも自分で識別子つけて管理していました。「ソースコードL1を変更提案に基づき修正してください。以後、修正後のコードをL2として参照します」という感じです。必要なことではあったのですが、本質的ではない部分に随分手間をかけていましたね。
問題点・不便だった点
- 変更提案(日本語＋コード引用して修正内容を説明)にない変更を勝手にソースコードに加えてしまう。「ソースコード修正の際、変更提案にない修正は厳禁です」と指示してみるも、十分な効果が得られない。
- ソースコードから大量のコードが消えている、使用されている関数が消えている、などが発生。コンテキストがあふれてソースコードの情報が失われたせいと思しきケースもあるが、そうではなさそうなケースもあり。
- 生成AIが返してくる内容が本当に正しいか分からない。細かく質問を繰り返していくとハルシネーションが判明することもあるが、そもそもそこまでやらないといけないというのが辛い。
- AWSサービスについても得手不得手に濃淡がある。不得手なものもそれっぽいことを言ってそれっぽいコードを生成してくれるが、バグだらけの上にしばらくデバッグを続けていると別のアーキテクチャへの変更を提案してくることも。
- デバッグはエラーメッセージを手動で与えなければならないし、デバッグ手順の示唆を与えてもらうにせよかなり人の手が必要。デプロイも手動で実施する必要あり。デバッグはそれでも生成AIによって大幅に楽になっているのですが、贅沢なものでデプロイ＆テスト＆デバッグはもっと生成AIにやってもらいたいと思っていました。
Amazon Q Developerによる開発への転換
Amazon Q Developerのサブスクリプションが手に入った頃、丁度AWSが提供するAI-DLC(AI駆動開発)のトレーニングを受けることができたので、本システムの開発もAmazon Q Developerを使用したAI-DLCに乗り換えることにしました。
AI-DLC 導入後のプロンプト
まずはAI-DLCの趣旨に沿って作成したプロンプトをAmazon Q Developerで使用したときの使い勝手という観点から見て行きます。
作業計画の立案
AI-DLCのトレーニングで学んだ内容からだいぶ我流のカスタマイズを加えたプロンプトを使っていますが、個人的に肝だと感じているのは以下のような箇所です。
このプロンプトにより生まれる長所だと私が感じているものは以下の通りです。
1. 計画を立ててから実行させると全体的にだいぶ品質が上がる気がする
計画を立ててもらうと、何も言わなくとも調査→設計→コード作成→テスト・検証というステップを踏んでくれることが多いです(AI-DLCではユーザーストーリーの作成から始まるのですが、開発途中のシステムということもあり今回は省きました)。大きなタスクを細かいタスクに分割してやると生成AIの精度が良くなるというのはよく知られた話ですが、それだけではなくステップ間でレビュー・修正を入れられるのも大きいです。定量的に品質が上がりましたというデータを持っているわけではありませんが、効果は大きいように感じます。
2. 事前に計画を提示してくれるので計画の修正が容易
計画修正したいケースは様々考えられますが、たとえば「ここのテストは後でまとめてやろう」「ちょっとここの実装あやしいからドキュメント調査＆設計見直しのステップを入れよう」などの意思が反映しやすいです。
3. セッションをまたいで開発を継続できる
Amazon Q Developerの記憶力(会話履歴)には限界があり、しばらく開発を続けていると会話履歴が要約されたりクリアされたりしてしまいます。Amazon Q Developerでは会話履歴がクリアされる前に会話履歴の圧縮を勧めてくれますが、いずれにせよ文脈の一部が失われることは避けられません。その他にもツールの不具合であったり、開発に使用するPCを切り替えたりと、新たにセッションを開始しないといけない事態は発生します。
機能追加等の改修作業をひとつまるまる完了したタイミングであればよいのですが、トライアンドエラーを繰り返している最中に文脈が失われると手戻りが大きいです。
AI-DLCでは計画書がありその進捗状況が分かるようになっているので、セッションが別になってもタスクを再開することができます。
デプロイ、デバッグ
私が受けたAI-DLCのトレーニングでは、コードの作成まではAmazon Q Developerにやってもらっていましたが、AWS環境へのデプロイや、デプロイ時およびデプロイ後のテスト時にエラーが発生したときの調査、コードを修正して再デプロイなどには触れられていなかったので、これらは自分で追加しました。もちろんこれらも予め計画を立ててもらってから実行します。
コードの作成までとデプロイ以降とでセッションを分ける場合も分けない場合もあります。大きな機能追加の場合は分けることが多いですし、デバッグがうまく行かなかった時にセッションを変えて何度もデバッグを試みることもあります。
いずれにせよ、デプロイは(CI/CD環境を作成していたので)CodeCommitにコードをコミットするだけなので、カレントフォルダがgitリポジトリになっていることを説明するだけです。デバッグは、CodePipelineの名前だけ教えてあげればそこからCloudFormationのスタック名を、スタック情報から作成されたリソース名を芋づる式に調べてくれます。ただ、セッションを新たにしてデプロイ・デバッグする場合は、主要リソース名は予め与えるようにした方が余計な試行錯誤で時間を無駄にせずに済みます。
所感・工夫した点など
Amazon Q DeveloperでAI-DLCを実践して、良かった点・使いづらかった点などいろいろ込みで感じたことや、工夫した点などを思いつくままに挙げてみます。
ドキュメント作成について
ドキュメント作成について特にプロンプトで触れていないのですが、計画を立てて実行させることによって、途中の調査・検討結果をドキュメント化してくれるようになりました。改めて言うまでもないですが記録を残すのは非常に重要なのでありがたいです。
ドキュメントの整合性維持について
開発の中で次々ドキュメントが作成されていくのですが、工程を進めていくと、前に作成されたドキュメントに記載されている内容とは違う方向に進めたくなる/進んでしまうことがあります。その時、現在のステップで作成するドキュメントはもちろんその方向に沿って作成してくれるのですが、以前作成したドキュメントを整合性が取れるように修正してくれることはあまりありません。「ドキュメントを作成するたびに、以前作成したドキュメントを整合性が取れるように更新してください」のようなプロンプトを入れてあってもほぼ効果がありませんでした。現時点では、文書間の依存関係を自分で把握するようにしておいて、○○の文書を整合性を取れるように更新してください、と細かく指示を出すようにしています。
文書間の依存関係を記述したファイルを作成しておいて、ドキュメントの作成・更新時にそのファイルを参照して依存関係を特定し、関連ドキュメントを更新するようにうまく生成AIを誘導できるのではないか？と考えているので近いうちに試してみたいと思っています。
ドキュメントの管理について
ステップごとに1つまたはそれ以上の数のドキュメントを作成してくれて、その場で読んでいるときはなるほどなるほどと読んでいるのですが、作成されるドキュメントの数がかなり多いです。作成するファイル名の命名規約等を与えていないのもあり、後から見るとどのファイルに何が書かれているのか分からなくなってしまいます。開発補助のエージェントとしてこの部分はこれから改善していく、またはプロンプトのノウハウが出回るのだと思いますが、ひとまずはドキュメントの種類などでディレクトリを分ける、ファイル名の先頭にステップ番号をつける、くらいの工夫で管理しています。
変更提案に基づくソースコード修正
Bedrock単体開発のところでも書きましたが、私は、ソースコード修正の際は変更提案というどこをどのように修正しその修正がなぜ必要なのかを説明するドキュメントを作成してもらい、その中から採用する変更提案を選んで修正してもらうという手順を採用しています。
先の所感で変更提案にない修正が行われると述べましたが、これはAmazon Q Developer + AI-DLC に移行した後もさほど改善されませんでした。承認していない変更が行われているだけではなく、ソースコードから大量の関数が消える事象もBedrock単体開発の頃と変わらず発生しました。
対策として「ソースコードの修正を行ったら変更前後のファイルでdiffを取り、変更提案の内容に過不足なく一致しているか確認してください」というような指示を与えています。ここでおかしい箇所に気づいてくれることもありますが、私から見ると明らかにおかしい場合でも「diffの結果、適切に変更されていることが確認できました」のようなことをしれっと返してくることもあります。もっとも、Bedrock単体で開発していた時は指示を出すのが面倒で差分確認をさせるということをしていなかったので、差分確認するようになっただけでも十分な進歩ではあります。また、diffが画面に表示されるので、私が異常に気付ける場合があるという点では、diffを毎回取らせるようにした意味はありました。
CodeCommitのコミットログ
過去に私が自分の手でコードを書いていた時は、一人で開発することが多かったので、バージョン管理システムのコミットログはかなり適当でした。それが、Amazon Q Developer + AI-DLC では、ソースコードを変更したらgitコミット用のコメントも出力してくださいと指示するだけでまともな変更履歴が出力されてきます。一人で小規模に開発している分にはなくてもなんとかなるかなという感覚なのですが、やっぱりあれば役に立ちます。これは個人的に非常に大きなメリットでした。
MCPの使用
プロンプトに「正確性の検証」という項目を入れて、「正確性を担保するためにAWSのサービスを使うときは必ずAWSドキュメントを調査して検証してください」と指示をしていますが、MCPを使ってくれたり使ってくれなかったりします。
これについては現状、調査して欲しいことが出てくる都度、AWSドキュメントを調査して裏を取ってください、と指示をするくらいしか対策が思いつきませんでした。AWSが提供するAIエージェントなのでここはぜひAWSさんに頑張って欲しいです！！
チャット履歴・セッション引継ぎについて
設計決めのために何度も質問を繰り返したり、デプロイ・テスト時のエラーが解消できなくて何度も再デプロイ・再テストを繰り返していると、「チャット履歴が一杯になりそうです、履歴を要約して圧縮しますか？」と聞いてくれます。これを無視し続けるとコンテキストが一杯になってチャット履歴が強制クリアされます。私の場合、一つの機能の実装が完了する前にチャット履歴要約を勧められる多いです（周りの人の話を聞いていると、開発のやり方による個人差は大きそうです）。前述の通りセッションを引き継いでタスクを継続するのに計画書が役立つのですが、ときに重要な情報が抜けてしまうことがあります。
セッション終了時に、引き継いでほしい情報を指示して引き継ぎドキュメントや次回セッション開始時に与えるべきプロンプトを作成してもらうように追加で指示するようにしており、手ごたえは感じているのですが、まだまだ試行錯誤という状態です。
作業計画を外れた場合の対応について
これはプロンプトでしっかり指示しようねという話に尽きるのですが、作成された作業計画にない指示をしてしまうことがあります。ちょっとこれも調査して欲しいな、とかです。あるいは、現在の作業計画は繰り返しを想定したものになっていないので、デプロイとデバッグを繰り返しているといつの間にか作業計画から外れてしまいます。そういう時、指示する側がきっちりと、こういうことをやりたいのでまずは作業計画を作成してください、とやればよいのです。それは分かっているのですが、ついうっかり（またはちょっと寄り道するだけだから大丈夫だろうと軽い気持ちで）作業計画にない指示をしてしまいます。その結果、実施したタスクの結果をドキュメントにしてくれなくなったり、ステップごとに承認を求めるように指示しているのに（ステップから外れた作業なのだから文字通りとらえれば指示違反ではないのですが）承認を求めずに次々と作業を進めたり……という状況になることがあります。
現在は、指示プロンプトを改めて入力してやり直す、というのが私の対応です。それでもうまく指示が伝わらないなと感じたときは、別のセッションを開始するようにしています。ここでセッション引継ぎのための準備が役に立ってくれます。
プロンプトの最適化について
このように開発をしていると大小取りまぜ気になる部分が出てくるのでそれに対処するためにプロンプトに指示を追加していくのですが、ある程度プロンプトが長くなってくると、守ってもらえない指示が増えていきます。今のところ、優先度の低い指示は予めプロンプトとして与えず、問題が出たときに都度対応するようにしています。
最後に
Amazon Q Developer, AI-DLCについての所感などをつらつらと書いてみました。
計画を立てて一つ一つステップを踏んで……と進めていると、自分が詳しい分野については自分の手でコードを書いた方が早いのでは？と感じることがありますが、自分に経験がなくAmazon Q Developerがなければ自分で調査と試行錯誤をする必要がある個所の開発は大幅に期間を短縮してくれています。また実際に動くモノの作成に比べて優先度低くなりがちなドキュメント作成・自然言語での説明をきっちりやってくれるので、自分の詳しい分野でもAmazon Q Developerに大幅に任せるようにした方が最終的に運用しやすいシステムが作れるのではないかな？という感覚があります。
生成AIは日進月歩なので、あっという間に状況が変わってしまい、この記事の賞味期限は非常に短いだろうなと思いますが……何らか、なるほどそういうこともあるのか、と感じて頂ければ幸いです。