
Kiro Web のオートメーションと Amplify Gen2 の プルリクエストプレビューを組み合わせて、寝ている間にアプリが育つ開発環境を簡単に用意できた
いわさです。
みなさん「小人の靴屋」をご存知ですか?
靴屋のおじいさんが夜寝ている間に、小人たちが靴を作ってくれるというグリム童話です。
朝起きたら仕事が終わっている。夢のようですよね。
我々エンジニアが運用しているシステムも、機能改修やバグ対応など継続的な開発が必要です。
寝ている間に小人たちがコードを書いてくれたらなぁ...ということで、作ってみました。
何を作っているか
私は普段から Notion、Trello、Google カレンダー、Backlog、Slack など様々な SaaS を使って業務をしているのですが、タスク管理の観点ではこれらが分散しており、間を埋めるために手動対応を結構挟んでいます。
そこで、これらのハブとなるタスク管理ツールを Amplify Gen2 でスクラッチで作って運用しています。

Google カレンダーで 1 日のスケジュールを管理しているので、予定は引き続き Google カレンダーで管理します。
ただ、そこから Notion や Trello へのカード化を行うのが手動で大変だったので、ここは開発しているアプリでは Google カレンダーと連携して自動取り込みできるようにします。

で、昨今の生成 AI(私の場合だと Kiro)によって最低限の機能を実装して使い始めることが出来ました。
最低限の状態なので日常的に使っていると「ここ直したい」「この機能追加したい」が次々と出てきます。
次々と出てくる改善要望。寝てる間に小人さんたちにやっておいてもらいたいものです。
小人が何をしてくれるのか
ということでこの「小人の靴屋」システムを導入しました。みんな見てくれ。
GitHub Issue に「ここを直したい」「この機能がほしい」と書いておくといつのまにか AI エージェントがその Issue を対応し、プルリクエストの送信と、レビュアーが動作確認するための環境のデプロイまで行ってくれます。
私は朝起きてとか移動中とか、スマホで PR のプレビュー URL から動作確認してマージボタンを押すだけです。
実際に Issue を書いておきました。

こんな感じで、気になったことを日本語で書いておきます。
ざっくり書いておくだけでもまぁまぁ良い感じに解釈して動いてくれるのですが、ここはそのままプロンプトになるので本当であればしっかり書いたほうが良いのだろう。まぁ個人利用レベルであればこれでトライアンドエラーし続けるのも悪くないです。
- 「タスク整理の機能がうまく動いていない」
- 「年間サマリー画面で予定と実績に乖離があるものは予定の修正を促してすぐに反映できる機能がほしい」
- 「日報作成機能がほしい」
翌朝スマホからの GitHub アプリを確認すると、PR が複数作成されていました。

Issue 3 件に対して PR が 5 件できています。
PR を開くと、レビュアーが動作確認するための URL が記載されています。

こちらの URL にアクセスすると、修正後のアプリをそのまま確認できます。
こちらを軽くチェックして期待どおりの修正がされていればプルリクエストをマージしましょう。
寝ている間に勝手にイシューを処理して実装・修正し、プルリクエストを作ってマージできる状態にしてくれていますね。なかなか良いぞこれは。
どう実現しているのか
仕組みとして、以下が自動で行われます。
- Kiro Web のオートメーションが 1 時間ごとにリポジトリの Issue を確認する
- 未着手の Issue を 1 件選んでコードを修正し、PR を作成する
- Amplify が PR を検知して自動でプレビュー環境をデプロイする
それぞれ見ていきましょう。1〜2は Kiro Web のオートメーション機能で実現できます。
こちらは Kiro Enterprise (IAM Identity Center でユーザー管理しているやつ) 経由で管理者オプションで有効化していれば使える Kiro Web の機能です。先日ブログを書きました。
Kiro Web は Kiro IDE や Kiro CLI と異なる実行環境が不要で、Web ブラウザ上アクセスし、エージェントの実行環境はリモート上にサンドボックス展開されます。AI エージェントを使おうとすると PC のシャットダウンやロックを気にしなければいけないので結局張り付くケースが多いと思いますが、Kiro Web であればどこか遠くでエージェントが動き続けてくれます。
その中でオートメーション機能を使うと定期的にエージェントに対して提携プロンプトを送信することができます。
ここで次のようなオートメーションを構成しておきます。

オートメーション名は「自動でIssueに着手」としました。
スケジュールは Hourly で 1 時間ごとに実行しています。
プロンプトには以下のような指示を設定しています。
- GitHub Issue にアクセスし、未着手の Issue があるか確認する
- 未着手の Issue がない場合は終了する
- ランダムで未着手の Issue を 1 件選定し、作業中のラベルを設定する
- Issue の課題を解決できるようコードを修正し、main ブランチへの PR を作成する
なお、なぜ main ブランチへ直接マージする運用にしているかというと、最初は develop ブランチを作っていたのですが、個人利用用途だと冗長に感じたのと、Amplify の PR プレビュー機能によって PR ごとに確認用環境が作成されるので、直接 main への PR で十分だと判断しました。
- PR 発行後、Amplify のビルド・デプロイが自動で行われるのでステータスチェックを確認する
- エラーが出ている場合は AWS CLI を使って Amplify のビルドログ・デプロイログを確認し、修正コミットを送信する
ポイントは、Amplify のデプロイエラーが出た場合に自分で修正するところまで指示しているところです。
Kiro は AWS CLI が使えるので、Amplify のビルドログを確認して原因を特定し、修正コミットを自動で積んでくれます。
これで Kiro が 1 時間ごとに Issue を確認してコードを修正しプルリクエストを作成してくれます。
Kiro Web の画面を見ると、「自動でIssueに着手」というセッションがたくさん作られていました。

セッションの中を見ると、Issue の一覧を確認して、未着手のものを選んで、コードを修正して、PR を作成するまでの流れが確認できます。
既に PR が作られている Issue はスキップしてくれているので、重複して作業することもありません。

期待どおり処理されていそうですね。
そしてプルリクエストが送信されると自動でレビュアー向けに一時環境がデプロイされるのですが、これは Amplify のプレビュー機能を有効化しています。
Amplify の PR プレビュー機能についてはこちらの記事が参考になります。
次のように Amplify 側は PR プレビューを有効にしておくだけです。

main ブランチに対するプレビューを有効にしておくと、PR が作成されたタイミングで自動的にプレビュー環境がデプロイされます。
大きくは Kiro Web を導入して Amplify プレビューを有効化することで小人を実装することができます。簡単ですね!
また、Amplify プレビュー環境で動作確認した結果気に入らない点があれば、次のようにプルリクエストのコメントで /kiro fix と指示すれば修正コミットを積んでくれます。

「動作確認してみたところ、乖離がある状態でバッジが表示されませんでした」のようにフィードバックすると、Kiro が追加のコミットを作成してくれます。
コンフリクトの解消も同様に /kiro fix コンフリクトを解消してください で対応してくれました。
注意事項や今後の要検討事項
数日間運用してみて、いくつか課題が見えてきました。
AWS Config の料金が跳ね上がる
コストエクスプローラーを確認したところ、Config の料金がかなり増えていました。

6/22 には $130 を超えています。
原因は、Amplify のデプロイのたびに CDK デプロイが繰り返され、Config のルール評価が大量に走るためです。
AI が同時並行で開発して PR を大量に作成し、Amplify が自動でデプロイをバンバンするので、こうなるみたいですね。
6/23 AM に 6/21 の利用料金のスパイクに気づき慌てて Config を無効化して対処しましたが、時既に時間切れ。
また、Config の無効化も望ましくはないので今後の検討が必要です。
コンフリクトが起きやすい
オートメーションが並行で動くので、同じファイルを触る Issue が同時に処理されるとコンフリクトが起きます。
対策としては、Issue 着手時にコンフリクトが起きにくいところから着手するよう指示するか、あるいは定期的にコンフリクト解消をするオートメーションを別で動かすか、といったところですかね。
Amplify デプロイに 15 分近くかかる
Amplify のデプロイが 1 回あたり 15 分ほどかかっています。
CDK デプロイを含むのでしょうがない部分もありますが、もう少し短縮できないかなぁとは思っています。

外出時などモバイル端末からだと Kiro のセッション履歴を確認しづらい
Kiro Web は一応レスポンシブレイアウトっぽい感じではあるのですが、モバイルに最適化されているとは言いづらいです。
横から出てくるタブなどなどモバイル端末からだと扱いにくい点が多々ありました。
GitHub の PR コメントで/kiro fixなどを使うことで修正指示などは出せるのですが、たまーに Kiro Web 側も確認したい時があります。
こちらも AWS Summit Japan 2026 の 1 日目のキーノートで紹介されていましたが、Kiro Mobile が始まろうとしており、実は数日前にさらっとアナウンスだけされていました。
そちら、こちらは現在クローズドプレビューという形で Early Access Request をした一部のユーザーへのみ TestFlight 経由で配信されるようになったのですが、先日私にも来ていました。

クローズドプレビューなのでアプリケーションの中身の紹介や公開されていない情報の話はできなくて恐縮なのですが、軽く使った感じだと上記課題を解決してくれそうな雰囲気を感じています。良い感じでした。
今後やりたいこと
PR が作成されて Amplify のプレビュー環境のデプロイが完了したら、自動でテストを実行してキャプチャを取得し、PR に貼り付けるところまでやりたいです。
ここまでできたら、Issue を書く → コード修正 → デプロイ → テスト → キャプチャ付きレビュー依頼まで全自動になります。
あとはもしかすると Amplify の PR プレビューに加えて DevOps Agent のリリースマネジメント機能でテスト環境へのデプロイ&テストをさせるのはありかもしれないなと、昨日の AWS Summit Japan 2026 の 1 日目のキーノートを聞いていて思いました。
さいごに
本日は Kiro Web のオートメーションと Amplify の PR プレビューを組み合わせて、Issue を書くだけで自動的に開発が進む環境を作ってみました。
GitHub Actions なども触る必要ないので、CI/CD パイプラインも含めてフルスタックで全部まるっとやってくれる Amplify は改めて良いなぁと思いました。
また、Kiro Web も GitHub リポジトリへの導入は非常に簡単なので、今回紹介した方法は Kiro も Ampliify もポチポチで終わるような手軽さが魅力です。
Config 料金の問題やコンフリクトの課題はまだありますが、Issue を書いてスマホで確認するだけという運用フローは思った以上に快適です。








