ozawaです。暑い日が続いていますのでオフィス出社した際のランチは毎回同じ中華屋さんで冷麺セットを頼んでいます。たぶん冷麺野郎と裏で呼ばれていると思います。
- AWS発のAIコーディングエージェント「Kiro」
- インフラ屋さんのモチベーション
- 結論、「上流工程の品質が物を言う」
- 個人的に気になった点
- そもそも何がいけなかった？
- インフラ屋さんがAIコーディングエージェントと仲良くなるために
- まとめ
AWS発のAIコーディングエージェント「Kiro」
巷で流行りのKiroです。AIコーディングエージェントはいくつかありますが、満を持して登場です。
かれこれ10年弱インフラエンジニアをやってきた私ですが、この手のコーディングエージェントをいくつか触ってみては「なるほど。。。？」とあまり腹落ちしない状態が続いていました。
今回改めてKiroを触ってみて、この問いに対して少し見えてきたものがあるのでそちらについてお話しします。
インフラ屋さんのモチベーション
まずインフラ屋さんがAIコーディングエージェントに何を求めるのかについて考えてみました。
- イケてるアーキテクチャの設計がしたい
- イケてる IaCテンプレートを作ってもらいたい
- 面倒な更新系タスクを全部やってほしい
- etc...,
一般的かどうかはわかりませんが、私としては「なんか要件突っ込んでそれに最適なIaCベースのアーキテクチャが構築されればOK」みたいなことを考えていました。
オーダーを与えて面倒なことを全部やってもらう且つ品質高いプロダクトができれば最高だなーとふんわり思っていました。
結論、「上流工程の品質が物を言う」
早速結論です。10年弱エンジニアやってて今更かい、とツッコミが聞こえそうです。仰る通り。
やったこと
今回はKiroのSpecモードを試しました。ざっくりいうとSDLC (Software Development Life Cycle = ソフトウェア開発ライフサイクル) を意識した開発を進めるための枠組みに則って開発できるモードです。
具体的には下記のドキュメントをチャットでAIエージェントと壁打ちしながら作成を進めて、最終的に作業リストを生み出します。
- requirements.md
- Specモードでは、作成時の一番最初にAIチャットに対して「こういうことをやってほしい」というオーダーを出します
- そのオーダーをもとにまずは要件定義書を作成します
- 修正が必要であればチャットでAIエージェントに修正依頼を出し、問題なければ提案を受け入れます
- design.md
- 要件定義書をもとに方式レベルの設計資料を起こしてくれます
- これも適宜AIエージェントとチャットで壁打ちしながら進めます
- tasks.md
- 方式設計書をもとに実際に構築を進めるための作業手順書を作成してくれます
- これが出来上がると、一旦AIエージェントとの壁打ちは終わります
- tasks.md をKiro上で開き、中身を見ると Start Task ボタンがあるので、そちらを押すとKiroが作業タスクを開始します
ちなみに今回はこういった感じのアーキテクチャを作ってもらおうとしていました。
requirements.md→tasks.mdまでの作成に関しては、AIエージェントと壁打ちしながら作りますが、さして時間はかからなかったです。
今思い返すとここで色々と気にすべき観点があったなーと思いました。
要件・方式決めまではすんなりいく、ように見えた
今回の作業では上述の３ファイルを作成する部分は数分もあれば作成できました（かのように見えました）が、実際の作業タスクについては１日以上かかりました。なんなら現状も当初のゴールには辿り着いていません。ふりかえって見た上で個人的に気になった点についてまとめます。
個人的に気になった点
わりかし複雑な構成
今回は「OSSの掲示板ツールを使ったECS on FargateなサービスをCDK管理で作って」といったオーダーを出しました。結果、出来上がった方式としてはECSだけではなくS3、EFS、DocumentDB、ElastiCacheといった様々なサービスを組み込んだ構成が上がってきました。さして疑うこともなく「まぁこんな感じか」というレベル感でdesign.mdを受け入れました。実際の構築フェーズで何が起こるかというと、
- 各種リソース権限（IAM）の設定不備
- ECSからDocumentDBへのネットワークアクセス経路の不備（VPCサブネット間でルーティングが通っていない）
といった事象がありました。IAMの部分については仕方がないかなーと思った反面、DocumentDBへの通信が通っていないのを確認した時は「なんか人間みたいなミスするなぁ」と思いました。
漢気あふれる課題解決
AIエージェントは非常に優秀です。だが時としてその優秀さが仇となる瞬間がありました。
- 明らかにNGな動作をしているテスト箇所で、NG動作を受け入れるようテストケースを修正
- 総合テスト用のTypeScriptなテストコードも実装してくれたKiro、DocumentDBのインスタンスクラス取得結果が想定の結果にならなかったので、その結果を受け入れよう！と意気込んだ次第でした
NG結果をそのまま受け入れようとするkiro
- 総合テスト用のTypeScriptなテストコードも実装してくれたKiro、DocumentDBのインスタンスクラス取得結果が想定の結果にならなかったので、その結果を受け入れよう！と意気込んだ次第でした
- ネットワークエラーで失敗するツールインストールをあらゆる方法で解消しようとし、最終的にはソースコードをcurlでGETするという漢気あふれる方法で回避しようとする
- ローカル環境のツールはasdfで管理していて、asdf installを試みたものの失敗したので、最後の手段に出た感じです
jqをソースからインストールしようとするkiro
- ローカル環境のツールはasdfで管理していて、asdf installを試みたものの失敗したので、最後の手段に出た感じです
最後の方はチャットで「やめてください」とお願いする時がありました。
そもそも何がいけなかった？
色々統合した結果、下記が問題では？という結論になりました。
- 曖昧な指示
- 考慮すべき観点の漏れ
- 前提条件のすり合わせ不足
自分で書いていて、なんだか悲しくなりました。
曖昧な指示
一番感じたのはテストでNGになった際やバグを発見した際のトラブルシュート時にただただ「〇〇を解決してください」とお願いするのはよくないかなと思いました。 このパターンにおいては、AIエージェントはなんかわかった気になってるだけで結局解決できていないという無限ループに陥ることが多かったです。
→「〇〇が××という状況のようです。この事象について原因を究明し、解決策を提案してください」とお願いすることで、まず何が起こっているのかを整理した上で対応策をいくつか提示してくれるようになりました。ちゃんと対話を重ねた上でよりお互いが解像度の高い状態で作業を進めていけたような気がしています。
考慮すべき観点の漏れ
AIエージェントは非常に優秀で、Kiro自身もツールとしてはよくできているなーと感心しつつ、ある程度の複雑さを伴うアーキテクチャを作ろうと思った際に、何も考えずにただ指示するだけでは品質がまだ期待値に届かない部分があるなという印象です。
特に総合・結合システムテストの観点で考慮すべき箇所については注意が必要だと感じました。CDKコード実装時点ではそれっぽいものができているだけで、実際にリソース構築が終わって接続しようとするとネットワークエラーになるといった状態になっていることがちょこちょこありました。
このようなInterface 間のつながりの部分については、IaCコード実装やテスト実施時に確認すべき観点として抑えた上でAIエージェントとやり取りをすることが重要だと感じました。
前提条件のすり合わせ不足
先述の通り、ツールインストールで問題が起こった際にAIエージェントくんはその課題を何としてでも解決しようとするため漢気あふれる対応を実施します。しかし我々が常日頃開発を進める上では少なからず前提環境を定義しているはずです（MacOSならbrew経由でインストールする、ツール管理はasdfにする、etc...,）。AIエージェントはチャットのやり取りの中である程度状況を推察した上で対応を実施してくれることが多いですが、前提条件や役割についてはあらかじめ提示した上で作業してもらうのが良いかと思いました。
インフラ屋さんがAIコーディングエージェントと仲良くなるために
「何でもかんでもAIや〜」な世界線は個人的にはまだ遠いかなーと考えています。が、いくつか注意点を持った上でAIと相対することで素晴らしい相乗効果が期待できる、とも思いました。
一般的にリスクをはらむ箇所を抑える
例えばシステム開発の現場において、
- Interface 間の接続
- 権限制御(IAMなど)
- アクセス制御(IPアドレスなど)
といったつながりを意識する箇所は、開発を進めていく上でも特に慎重に確認する箇所かと思います。AIエージェントに実装させる際にも、構築後の総合観点のチェックはもちろん、コードレベルにおいても適切な設定がされているかという観点を持って確認してもらう、というフェーズを設けるのが良いかなと思いました。
今回、Kiroで実装するにあたってはtasks.mdの章立てレベルの実装が完了したタイミングで「npm build」「cdk synth」といったコマンドを一通り実行して正常に動作するかを確認するフェーズがありました。ここに一つ「〇〇と△△の間における通信が通るように設定がされているか確認してほしい」といった依頼をAIエージェントに投げかけることができれば良いかと思いました。実際、ECS→DB間の接続トラブルシュートの際に、コードレベルまで遡ることになったのでここは事前に伝えておくと気づける問題かなと思いました。
また、今回はCDKソースコードの実装→apply→テスト、というわりかしウォーターフォールなアプローチでタスクリストを進めましたが、スクラム開発的な考え方である程度の小粒なモジュール単位でCDK実装→apply→テストを繰り返すというやり方であれば、影響範囲も絞れつつ対処できるような気がしたので、より効率的に実装が進むのかなと思いました。
開発環境やコーディング規約を統一する
「ツールインストールには〇〇を使ってください」「コーディング規約は△△に則ってください」といったことを事前に伝えておくと良いかと思いました。あとあと調べていく中で、Kiroに関してはAgent Steering機能でこの辺りのガードレールを調整すればうまくいくのでは？とうっすら気づきました。
既存ツール等でAIだけに依らない品質担保を意識する
ぶっちゃけ生成AIが作成したコードについては「本当に大丈夫？」感が拭えないので、ソースコードレベルにおいては、kics等のSASTツールを利用してAIに依らない品質担保の経路を確保しておくのも重要かと思いました。
まとめ
かなりふんわりとした内容になりましたが、AI初心者が「こんな感じでいけるかな？」と手を動かしてみたら割とハマって悶々とした事象は結構世の中あるあるなのでは？と思ったのでまとめてみました。
特に技術的なTipsがあるわけではないですが、インフラ屋さんでもこういう心持ちでAIと関わることができれば幸せになるかもよ？というポエムだと思って読んでいただければ幸いです。
