Kiroを使ってみた - そこから見える今どきの開発 - Kiro Meetup Japan #1

AWSからリリースされたKiroを使ってみたというKiro Meetup Japan #1の発表資料です。

1. Kiroを使ってみた ～そこから見える今どきの開発 ～ Kiro Meetup Japan #1 フューチャー株式会社 渋川よしき

2. お前誰よ 渋川よしき 　 本田技術研究所 → DeNA → フューチャー 　三女の父 プログラミング歴 　オーガニック: 32年 　生成AIエージェント利用: 3か月 　　Q Developer, GitHub Copilot, Codex, Kiro←今回 著書 　 つまみぐい勉強法（共著）、Real World HTTP 第2版 、 　 　 Mithril、Goならわかるシステムプログラミング 　エキスパートPythonプログラミング、ソフトウェア開発 　スクラム、ポモドーロテクニック入門、 　アート・オブ・コミュニティetc 好きな言語 　 Type Script / Go / Python / Dart(Flutter) プログラミング以外 　インラインスケート＠光が丘公園 アカウント 　github.com/shibukawa 　twitter.com/shibu_jp

3. Discography 同僚社員と一緒に出版 同僚社員と一緒に出版 同僚社員と一緒に出版

4. 最近出ました Software Design の特集をまとめた本です あと4冊ほど進行中です

5. 生成AIの開発ツール

6. 生成AIの開発ツールの分類 ツールはいくつかに分けられる 開発ツールの分類 CLIのエージェント エディタ内蔵 機能の分類 コード補完 チャット エージェント ツールごとにいくつか形態がある Claude Code、Q DeveloperなどはCLIかつエージェント（エディタ拡張あり） GitHub Copilotはエディタ内蔵でコード補完＆チャット＆エージェント Kiro、CursorはVSCode 個人的にはCLIが便利だと思うが初心者はエディタの方が とっつきやすい（らしい）

7. エディタ型のメリットとデメリット メリット 起動するといつでもそこにいるのでとっつきやすい 起動しなおすとかは不要 コンテキストが人と共有しやすい AIが覚えておける知識（コンテキスト、メモリ）は無限ではないし、プロジェクト全部をすべて覚えておくほどはない その場のタスクの遂行に必要な知識を消したり読み込ませたりしてやる必要がある エディタの場合は現在アクティブなウインドウがそのままコンテキストになったりする 変更差分が見やすい デメリット ウインドウが狭くなる 負荷が高くなる？ 操作中、自分で他の作業をしにくい 並列操作ができないものが多い CodexのVSCode拡張はできる

8. Kiro

9. Kiro は生成AI初心者に最適なツール Kiroは生成AI開発を体験してみるには敷居が低い ワークフローが固定化されており「どのように使うか」を考えずに使い始められる 多くのエージェントはどのような開発スタイルに合わせられるように、ワークフローはハードコードされていないため、自分なりのワークフローを定義して読み込ませるところが出発点になる モデルとしては、コーディングで定評のあるSonnet-3.7, 4が選択可能 生成AIが何をやっているのかが理解したり目視しやすい と書くと聞こえはよいが、並列で実行させる機能がない 確認待ちになると通知が来る 他のエージェントでも欲しい

10. Kiro にお任せでやってみた Spec モードにして欲しいものをチャットする 「設計に行っていい？」と聞いてくる→お、まかせたぞ ざっと書いてきて、タスクにしてもいいか聞いてくる→たのんだ！ タスク一覧ができるので、あとはポチポチ、許可が来たらOKを押すだけ →テストもドキュメントもタスクにあるぞ！ →なんかでてきたぞ、すごい

11. 本当にこれだけの入力で欲しいものができるのか？ 未来の技術ってすごい！

12. いくつか作らせてみようと思った Let’s Encrypt のローカル版 mkcertでやたら長寿なキー(800日)を生成して使うのではなく、開発環境用の短い寿命のHTTPS証明書を都度発行の方が良い 共同編集前提の表コンポーネント 共同編集前提のはない Canvasで高速描画をうたっているものは多いが、可能ならDOMとハイブリッドでE2Eフレームワークフレンドリーなのが欲しい ちょっとしたライブラリ 現在の環境がDockerの中かどうか判定とか、JSONフォーマッター(特定の階層以下はインデントしない）

13. そのままおまかせでいける？ プログラマーはもういらない？

14. だめだった 0:05

15. 結果 Let’s Encryptのローカル版 仕様がごちゃごちゃしてきたので、Kiroのプロジェクトを作り直した 実装は並列で進めるために途中からQ Developerにスイッチして完成までもっていった https://github.com/shibukawa/myencrypt 共同編集前提の表コンポーネント 日本語入力のハンドリングが全然うまくいかない 回避策を提示してもすぐに元に戻る ちょっと停止中 ちょっとしたライブラリ 80%ぐらいうまくいった https://github.com/shibukawa/incontainer https://github.com/shibukawa/jsonformat JSONの方は不正なJSONを生成したのと、アプリに組み込もうとしたらそっちのAIがフルスクラッチで同じものを作ってしまって不要になった

16. 現時点で完全お任せは難しい なんか進んでいるのだけど、不安になって動かしてみたらコンパイルも通らなかったりする 出来上がっても触ってみるとなんか違う 要件が誰に聞いても明確なもの（例えばテトリス）とかはいけるのかもしれないが、作る必要があるソフトウェアは世の中に無いもの 他の言語で実装されたもののクローンぐらいはあるが 少ないコメントでは実装に必要な情報は当然得られない 生成AIの開発では、きちんとフィードバックして期待通りかどうかを一歩一歩確認しながら進めるのが大事

17. AI のアウトプットに介入していく 要求や設計の執筆では、毎回聞いてくるので「おおいいぞ、まかせた」ではなく、「ちょっと、一言いいかい？」と割り込んでいけばよい 次のフェーズに行くか？と確認してくるので、OKを押すまではキャッチボールをしつづけられる フェーズが進んでから戻りたい場合は、「ちょっと要求のここを修正して」とか指示すれば良い 実装フェーズでなんか変なことをやりだしたな、というに気づいたら 停止ボタンで一時停止してから指示をする

18. 閑話休題 本資料はAIの作業を止めて意思入れをすることを「介入する」と表現しています 過去の雑に「QDevが暴れたのでCtrl+Cで止めて折檻した」と書いたらされされたが、意味的には良いが体罰の文脈で使われることもあるので・・・

19. 要件定義フェーズへの介入 要件定義からきちんとコメントをがしがしいれていく アーキテクチャに影響のある機能はどんどん入れていく 使う言語やフレームワークなどもガシガシ書く Tailwind CSSのV3/V4とか、Dockerfileの新旧とか書き方が複数あるやつとか要注意 ただ、苦手な方は結局書いてくれないので手間がかかる

20. 設計フェーズへの介入 設計もガシガシコメント入れまくる。これでいいですか？ときても言い尽くすまでは書き続ける なくても成立する独立した機能で、あとリリースでいいものは入れない。 タスクの総量は絞る方がよい 入出力の形式、引数やオプションの内容、コマンドラインなどとにかく入れる HTTPSでサーバー公開、ではなく、証明書ファイルを渡すのか、mkcertで生成するのか、 Let’s EncryptみたいなACMEプロトコルでとってくるのか。1つなのか複数選択肢を提供するのか。選択のための設定やコマンドライン引数、環境変数はどうなるのか？ 可能ならサンプルも書かせる。 0:10

21. タスク実行への介入 タスクはウォーターフォール的な手順で来るが、順番通りに実行する必要はない プロジェクトの枠を作ったら、まっさきにcliとかサーバーとかを作るのを先にやり、まずは動かして確認する ドキュメントを先に書いてもらうのも良い ユーザーの目線で評価 必要なら後で再修正はしてもらえるので 自分で動かしながらフィードバックをどんどん入れて修正していくのが大事

22. 生成AI開発の悩み：クオータ対策

23. AI クオータ・エラー対策 Kiroが人気すぎてAWS Bedrockの資源を使いつくしたのか、Q DevもKiroも動かなくなったことがあった 複数のツールやバックエンドを切り替えて可用性を上げる リクエスト数が有限のサービスがほとんど。使い切ったら別のツールに移行する Kiroも制限がある デイリーリミットの文字を見かけた Kiroに仕様までを任せて、実装は別のツール(Q DevとかGitHub Copilotとか)に任せるのを最近はやっていました というか、KiroのPricingが発表されて追い出されて使えなくなった・・・

24. Kiro/Q Developerこうなってほしい Q Dev と同じアカウントで使えるようになって欲しい・・・ 同じクオータの中で要件定義得意エディタと、なんでもできるCLIの両方使いたい 両方契約しても使い切れない・・・ 当初発表された価格体系だと、2倍払うと3倍使える、みたいな感じだったと記憶しているがなくなった？ Q Devの方は利用料確認ができず、いきなりMonthly Limit到達で来月まで まって、といわれる ちょっと社内で利用を始めていて困っています。ロックされると別のアカウントを登録する必要がある Kiroは追加でリクエストごとの支払いができるとあるので、これをQ Devにも導入して欲しい

25. 生成AI開発で常識が変わっていく

26. ベストプラクティスはまだわからない 今日のみんなの発表もおそらくそうですが、どのようにやらせればよいかはみんな試行錯誤中 ソフトウェアの難易度、選択するモデルによっても変わってくる 小さくスタートする→既存のコードの修正箇所が広いとそこに時間がかかる 大きくスタートする→なかなかゴールにたどり着かない 厳しくしすぎても誤魔化し始めるし、緩すぎても雑にやり始める 🤖 全部のドキュメントを書いて投げる？ ちょっとずつ指示する？ 概要・詳細設計レベル まで書いて投げる？ アジャイル的に箇条書きなシンプルメモでフィードバックサイクル回す？ 画面量産とかさせる？

27. ベストプラクティスはまだわからない 今日のみんなの発表も おそらく そうですが、どのようにやらせればよいかはみんな試行錯誤中 ソフトウェアの難易度、選択するモデルによっても変わってくる 小さくスタートする→既存のコードの修正箇所が広いとそこに時間がかかる 大きくスタートする→なかなかゴールにたどり着かない 厳しくしすぎても誤魔化し始めるし、緩すぎても雑にやり始める 🤖 全部のドキュメントを書いて投げる？ ちょっとずつ指示する？ 概要・詳細設計レベル まで書いて投げる？ アジャイル的に箇条書きなシンプルメモでフィードバックサイクル回す？ 画面量産とかさせる？ 生成AIがこんなこんな誤魔化しをしてくるぞケーススタディは 来月10/11に技育祭で発表予定

28. このあたり、実はアジャイル開発が誤魔化してきたところでは？ 要件定義は1人の超人顧客、PO、ドメインエキスパートが優先度ばっちり決めてくれる そんなの現実的ではない アーキテクチャはそんなの勝手に決まるでしょ？ メタファーとして共有すればそれで拡張性もメンテナンス性もばっちりOK のちにイテレーションゼロ(スプリントゼロ)が提唱される 情報伝達速度がボトルネックという前提で、新しい方法論が必要感 手は確かに早い モジュール分割とかは最初にやりきって、その中はアドホックにやるとか？ アジャイルとウォーターフォールの間になることは間違いないと思うが・・・

29. ソフトウェア設計の常識が変わる 仕様の煮詰めに時間取るよりは、ガンガン実装して動かして確認の方が良い ただ何も決めずに作り始めると終わらないので多少は必要 入出力だけはきちんと定義して中身の実装はおまかせにする マネジメントしない領域を増やす方が効率は良い 複数プロダクトの同時開発 最大で4つぐらい同時に作ってみたがなんとかなる ごっちゃにならないようにウインドウの色をプロジェクトごとに変える テスト駆動開発の価値は下がる モジュール分割、インタフェース定義とかも人の意思を入れない自動で行わせることが多いとなるとそこをテストする価値はあまりなく、静的チェックの延長ぐらいの扱い 完成して確認ができた受け入れテストのみが価値のあるテスト アジャイル開発というよりは高速ウォーターフォールに近い実感がある 手が速すぎてたくさん生成される 中間的な設計書なんかは削除してしまっても良さそう。ノイズになるし このような議論がこれから起こるはずなので、 KiroでAI開発をとにかくやってみて話題に参加できるようにしましょう！

30. まとめ

31. まとめ Kiro は生成AI開発をやってみる、エントリポイントとしてはわかりやすい ワークフローが設定済み コーディングもよく書いてくれるモデルが利用できる いろんなツールが出てきているが、まずは触ってみて学んでみるのが大事 高いツールとかもあるが、Kiroのイニシャルコストは高くない 生産性の高さで良し悪しの比較ではなく、まずは触ってみよう、というフェーズ 新しいツールとかバージョンアップも頻繁なので「これじゃなきゃダメ」とか決めつけずにまずはなんでもいいから触ってみるとよい→Kiroでよい アカウントはなんとか・・・ 0:15