Amazon/AWS Kiroで既存サービス作り直してみた感想

（Kiroとは：https://aws.amazon.com/jp/blogs/news/introducing-kiro/

）

ひとことで結論

「今あるコード群をいい感じに書き直して」という用途でも、使えないことはない。
しかし、既存仕様に追随してもらおうとすると、一発で動かないコードを吐き出すようになり、人間のエラー対処能力が必要となる。オススメはしにくい。

背景

AIにソフトウェアコードを書いてもらうだけでなく、ソフトウェア開発の全体をまとめてもらうAI駆動開発の手法が注目されています。
従前はRoo CodeというVS Codeのプラグインを導入して、APIを連携して…という方法が多かった印象ですが、2025年半ばに「Kiro」というサービスをAmazonがリリースしました。
無料かつ簡単に使えることと、Amazonが出したことで爆発的にAI駆動開発を体験する人が増えているらしい・・・
ので、お試ししてみました。
※著者は本業ソフトウェアエンジニアではないので、専門家が読んで間違えている点はご指摘ください

作り直してみたサービス

作り直してみたのは、以下で紹介した、Twitterの告知投稿をGoogle Calendarに登録するサービスです。
2024年秋頃に作ったので、生成AIはまだそこまででもなく、、ほぼ手作りで作りました。

この記事は「新規のサービスを作った」のではなく「作り直した」というのが制約として大きい気がします。

課題

作り直すモチベーションとして、以下の課題がありました。

コードが汚い

手作りなのと、私がAWSのサービス群を使って作る初めてのサービスだったため、コードがかなり汚いです。
作者が記憶があるうちはいいのですが、コードが汚いと保守性が低く、「急に何もしてないのに動かなくなった」ようなときに修正に時間を要する可能性があります。

リカバリが面倒

このサービスは、Twitter(lobstr.io)とOpenAI APIを用いており、何らかの不具合や設定忘れで連携ができないことが年に数回ありました。
その際に、リカバリとして、日付を手動指定してLambda関数を再実行するのですが、、恥ずかしながらコードを修正（日付をハードコーディング）→デプロイ→テストで実行→終わったら元に戻す…というひどい手順で行っていました。
上記の「コードが汚く書き直したくない」という点もあり、このやり方で止まっていたのかなとも思います。

やったこと

1. 「今あるコードを作り直して」という依頼で、サービスの概要と、現状のコードは入力して大枠を作成
   • サービスの概要を列挙して、「以下は参考コード」と言ってコードを貼り付けて依頼しました（各コードの動作はAIが解釈してくれるだろうという魂胆）
   • 生成AIへのプロンプトは2024年に拘って作ったのもあり「なるべく現状のコードを踏襲する形で作って」と依頼しました
2. READMEなどの仕様書を確認しKiroへコメントをすることで大枠を修正
   • 出てきたコードを確認すると、当初、KiroはCloudFormationのYAMLファイルを作成していました。ただ、筆者がこの分野の知識が薄くレビュー不可・異常発生時に対処できない可能性があるため、基本AWS CLIでサービスを作ってもらうことにしました。
   • そもそも、初期設定はCICD使わずとも、GUIでポチポチで十分かなと思っていました。　→ただ、後ほど気づきましたが、Kiroはコードをコロコロ修正する＆一発で動かないのは当然なため、CICDを前提としたほうが良さそうです・・・
   • また、Kiroはテーブルに「処理済みフラグ」を付けていました。しかし、リカバリの際に仕様を完全に把握する必要が出てきそうなのと、本サービスでは過剰な仕様と判断したため、「日付だけ入力して全部処理する。万が一、二重で登録してしまったものは人間が手動で消す」という仕様で作ってもらいました。
   • また、動作確認用？Lambda関数なども作っていましたが、使わないLambda関数となりそうなので、消してもらいました。
3. 個別のPythonコードを確認し、修正を依頼
   • Pythonコードでは使うバケットなどが環境変数で定義されていましたが、小規模なサービスなので、個人的にコード上に埋め込んでくれたほうが楽です。そのため、Pythonコードの上の方で定義するようにしてもらいました（もちろん、ベスト・プラクティスではないと思います・・・）
     • このような修正を行ったとき、「コード中、上の方で定義しているのに、実際は使われてない変数」が生まれたりしました。Ctrl-fで調べれば一発ですが、、「こんなクソコードをAIが書くんだ・・・」と素直に思いました。
   • バケット名やテーブル名が汎用的すぎて記憶に残らず、管理の際に直感的にわかりにくいことに気づきました。そこで、プロジェクト名を命名し、それを頭に付けるようにして、わかりやすい名称にしてもらうようにしました。
     • 例えば、修正前：twitter_post_table、修正後：stnkbot_prd_postsのような具合です。（stnkbotがプロジェクト名）
4. 個別のPythonコードを修正したりすると、READMEやSETUP_GUIDEが古い仕様のままになっていたりしたので、全体の整合性が取れるように、全体の修正を依頼
   • 人間でもあるあるですが、、README等ドキュメントが最新仕様に追随していない部分がありました。そこで、「全コード・説明書、正しくなっているか、整合性が取れているか確認してください」と依頼しました。
   • また、何度依頼しても直らない部分が多く、結構手を焼きました。直っていないのに「修正済みです」と言ってきたりします。。
   • 依頼すれば直してくれるのは良いところですが、勝手に考えてくれる優秀な人って偉いんだな・・・と感じました。
5. 出力されたコードをAWSにデプロイ
   • Lambdaファイル一式をAWSにデプロイしたり、AWS CLIでDynamoDBの新規構築などを行いました。手動のコマンドを教えてくれるので結構楽でした。
6. 既存環境と並行運用し、一定期間後、シームレスに移行
   • コードは書いてもらえますが、既存環境との切り替えなどは人間が判断しました。

感想

✅️コード同士の関係を考えてくれる点、仕様書を作ってくれる点が凄い

従前のClaudeなどとの対話では、基本的にコード1つ〜数個を出力するだけで、説明を読みながら複数のコードを組み立てていました。
しかしKiroを使うと、必要な部品に分けてコードを作ってくれ、さらにREADMEも作ってくれます。
理想的には、人間はREADMEに従って操作するだけです。

言われたとおりにやれば良さそう。2026年1月にPython3.9を使っている点は気になる・・・

✅️ベストプラクティスを教えてくれる

当初、個人レベルのサービスということもあり、OpenAIのAPIキーなどはコードに直で書いていました。
しかし、LLMの提案では、AWS Secrets Managerに認証情報を保存し、それを活用するように書き換えてくれました。
さらに、複数のLambda関数群を一連で実行するのにStep Functionsを使うようにしてくれました。これでリカバリが簡単になりました。
これらのサービスはAWS SAAの勉強では出てきましたが、実際に使ったことの無いサービスであり、「動けば良い」の一歩先のコードを提案してくれたかなと思います。

会話しながら、構成を選べるのは嬉しい

↓
言われたコードを実行するだけで知らない機能を使える

❌️細かく指示すると？一発で動かない。エラー対処は人間

出てきたコードに対して、色々Kiroにコメントして作り直すと、内部での不整合を自動ではすべて解消しないためか、一発で動きませんでした・・・
想定動作しないときの対処は人間が行うのですが、人間のエラー対処能力が必要となります。もちろんLLMに聞いても良いのですが、伝書鳩になるため、経験と勘で解決していったほうが早いです。

「Pandasなら自分でレイヤー作るよりAWS提供のやつを使ったほうが簡単では・・・？」と思ってしまう返答

↓
自分で直したよって言いました

❌️ベストプラクティスに従うのか、過剰な仕様になることがある

上記の逆で、人間だと最低限の仕様で条件を満たすものを作ると思いますが、Kiroは最低限以上のものを提案してきます。
そのため人間からすると「そこまでしなくていい」と思う部分もあります。
（ソフトウェアの品質特性として信頼性・保守性・移植性などを考慮すると、必要な機能なのかもしれませんが。。
蛇足な仕様がないか、READMEを読んで逐一指摘する必要があります。

❌️個別のコードはレビューが必要なケースあり。レビューする知識・能力が必要

既存のサービスのリファクタリングに用いる場合は、勝手に大幅な変更が行われるので、不要な変更が行われていないかの確認が大変でした。
もちろん、初めて作るサービスの場合は「動くまで持っていく」が時間がかかるポイントなので、Kiroを用いるメリットは有ると思います。

また、レビューするには人間側の知識が必要です。レビュー自体は「XXの〜〜の部分は想定通り？」など、自然言語で行えるので便利ですが、最終的には人間が知識を持っていないと指摘を思いつきません。
例えば、私はCloudFormationのYAMLに関して全く知識がないので、レビュー不可でした。
逆に言うと、これまで手で作っていた経験はレビュー能力として活かせますし、今後は、コードを読んで判断する力、適切にプロンプトを入力する力が求めらるのかなと思いました。

おわりに

ネガキャンが多い内容ですが、「コードは書けないけどチェック・指示はできる」という人間になりきれば、そこそこ使えると思います。
（Kiroとのやり取りにかなり苦労して、AI相手に平気で「ウソ乙」とか言い放つ人間になってしまいました。。）