Amazon Web Services ブログ
インフラエンジニアのあなたも！Shell スクリプト開発で Kiro を使ってみよう
こんにちは、ソリューションアーキテクトの松本です。
本ブログは Kiroweeeeeek ( X: #kiroweeeeeeek ) の第 5 日目です。昨日のブログは菅原さんの「Kiro を使ったペアプログラミングのすすめ」という内容でした。これまでに公開した記事の一覧はKiroweeeeeeek in Japan 開催のお知らせをご参照ください。
本ブログでは、これまでの連載と少し視点を変えて、「Kiro は私に不要なツールでは？」と見逃しているかもしれない皆様にメッセージをお届けしたいと思います。具体的には、アプリケーション開発担当ではなく、サーバやミドルウェアを中心に扱うインフラエンジニアの皆様に、「使ってみたい」と思ってもらえるよう Kiro の魅力がお伝えしたいと思います。この記事は日曜に投稿しているので、ちょっとした番外編だと思って気楽に読んでいただければ幸いです。では、本編へどうぞ！
はじめに
私も以前はインフラエンジニアとして働いており、ちょっとした構築・運用作業を Shell スクリプトで自動化することが好きでした。当時を思い起こしてみると、こういったスクリプトの開発はテキストエディタや vi エディタで作成することがほとんどで、Eclipse や VSCode のようないわゆる統合開発環境は自分にとって無用の長物、過ぎた代物だと思い込んでいました。
しかし、そうではないことを知った今、「もしかしたら、あの時の私のように見過ごしてしまう方もいるかもしれない！」と気づいた私はいてもたってもいられず、今こうして一心不乱に筆を取っているというわけです。
皆様にできるだけわかりやすくお伝えするため、本ブログでは二つのシナリオを通して Kiro の魅力をご紹介いたします。
シナリオ 1 : ディスク容量をクリーンアップするスクリプトを開発する
サーバ上のディスク容量を確保するために、定期的にファイル削除やローテーションを実行するのは必要な運用の一つです。単純なログファイルであれば logrotate などを利用して実装可能ですが、中にはアプリケーション固有のビジネスロジックに基づいたファイル操作・管理を必要とするケースも少なくありません。このようなスクリプトを Kiro を利用して開発するシナリオを考えてみましょう。
要件
このシナリオでは、「特定ディレクトリのファイル一覧を取得し、同一ファイルが Amazon S3 にアップロード済みであれば削除する」というディスククリーンアップスクリプトを考えてみましょう。
こういう “ちょっとした” スクリプトの開発では、ドキュメントが残っていないなんてことも残念ながらよくあります（私にも謝らなければいけない過去があります）。しかし、Kiro の Spec mode を利用すれば、Kiro の対話を通じてドキュメントもセットで生成してもらうことができるのです。
Kiro での作業手順
1. Kiro を起動し、要件を伝える
Spec mode では次のように自然言語で要求を伝え、仕様書を生成してもらうことから始まります。
Linux サーバの特定ディレクトリのファイル一覧を取得し、同一ファイルが S3 にアップロード済みであればローカルディスクからそのファイルを削除するディスククリーンアップ Shell スクリプトを開発してください。
これは作成された仕様書の一部ですが、概ね期待していた内容が記載されています。
図中のように WHEN や IF、THEN で表現する記法は EARS 記法 (Easy Approach to Requirements Syntax) と呼ばれるもので、 要件を構造化して記述する手法です。要件の曖昧さを排除し、テストケースの作成も容易になるという特徴があります。Kiro ではこの記法を活用することで、明確で実装しやすい仕様書を自動生成しています。
2. Kiro が生成したドキュメントをレビューする
仕様書のレビューを進めていくと、バケット名などのパラメータは実行時に引数として与える想定であることが分かりました。
コマンドの引数でパラメータを与える方法だと、パラメータ変更のたびにジョブの呼び出し側の修正（例えば JP1 ジョブの定義など）が必要になるため、あまり望ましくありません。そこで、コンフィグファイルとしてパラメータ管理するように、仕様書の修正をリクエストします。
実行時のパラメータ指定は引数ではなくコンフィグファイルで定義するようにしたいです。
そうすると次のような修正案が提示されました。Config_File の概念が追加されており、これなら良さそうです。Kiro による自動生成と人間によるレビューでヒューマンインザループを実現できるので、適切なシーンで人間が介入できます。
なお、修正された内容は下図のように diff 表示が可能で、変更点を把握しやすくなっています。
3. 設計フェーズに進む
仕様書の生成は完了とし、次は設計フェーズに進みましょう。仕様書の生成と同様に、まずは Kiro が設計書を作成します。設計フェーズでも Kiro が生成した初版に少し手を加えて欲しかったので、次のような追加の指示を与え、設計書の生成を完了しました。
このスクリプトで登場するファイルの一覧とその情報（オーナーやパーミッション）と、セットアップの手順、手動実行の手順も書いておいてほしいです。cronで定期実行するつもりなので、セットアップ手順にはその部分も含めてください。
このファイル一覧があれば、OS 上のファイル変更を監視するミドルウェアを導入していた場合でも、監視対象の設定追加がスムーズに行えますね。
4. Kiro に Task の実行を指示する
設計書の生成も完了したので、スクリプト本体の開発を進めてもらいました。ところが、生成されたスクリプトを見てみるとスクリプト内のコメントが全て英語になっていました。できれば日本語のほうが読みやすいですから、設計に戻って追加の指示を与えました。
このスクリプトのユーザは日本語のほうが読みやすいので、設計書を修正してスクリプト内のコメントは全て日本語になるように指定してください。
このように的確に設計を修正してくれました。実装タスクは一部実行してしまっていたので、設計書の修正を伝えて再実行をリクエストします。
変更点も正確に把握できており、期待通りにスクリプトの修正が完了しました。このように、先のフェーズに進んだ後でも要求や設計に立ち返って、修正していくことが可能です。
このあとは順調にタスクを進め、一通りの実装作業を完了することができました。これはログ出力関数を作成しているシーンですが、今回のスクリプト以外にも活用できそうです。
このように、Kiro の Spec mode を利用することで、インフラエンジニアが必要とするスクリプトを簡単に開発することができ、かつ丁寧なドキュメントも用意できることがお分かりいただけたと思います。
シナリオ 2 : 既存のスクリプトを読み解き、改善する
悲しいことにこれもよくあることですが、前任者、あるいはさらにその前の担当者が残していったスクリプトを維持・保守しなければいけないシーンもあるでしょう。そしてシナリオ 1 のようにドキュメントも存在せず…。そんな時でも、Kiro の Vide mode があなたの作業をお手伝いします。
要件
今回のシナリオでは、ログ監視の仕様変更に伴い、既存のログ監視スクリプトを調査・改修することになったとします。要件としては既存の ERROR という文字列に加えて、FATAL も検知対象にするというものです。既存のスクリプトは問題なく動作しているようですが、実は次のような問題点が含まれています。
- コメントがほとんどない
- 未使用の関数・変数がある
- 不安を煽るコメントがある
- エラーハンドリングなし
- 危険なコマンド (rm -rf) が実行される可能性がある
- ファイルパスがハードコードされている
- グローバル変数の乱用がある
- 非効率なループ処理がある
- パスワードが平文で書かれている
大変恐ろしい状況ですが、作業に取り掛かってみましょう。
Kiro での作業手順
1. 既存スクリプトの解析をリクエストする
まずは既存スクリプトの正体を明らかにするため、README.md を作成してもらうことにしました。
bad_example.sh の改修を任されたのですがドキュメントがないのでどういうスクリプトなのかよく分かりません。まずはこのスクリプトの仕様を解析し、 README.md に記録してください。
そうすると早速、先回りして問題点を指摘してくれました。もちろん、このブログのことやスクリプトの問題点については一切情報を与えていません。
出来上がった README.md を見てみると、丁寧に解説された文章ができていることが確認できました。
2. 既存の問題点を精査する
さて、さきほどすでに一部が露見した問題点について、改めて精査してもらいます。
問題点が多いスクリプトのようなので、改めてスクリプトをチェックし、問題があると思われる箇所を全てリストアップしてください。
すると、次のように 20 件もの問題点が発見され、README.md に詳細を書き足してくれました。
あらかじめ仕込んでおいた問題点のほぼ全てが指摘されていますが、コメント関連の部分だけは指摘がないようなので、追加でチェックをお願いしてみます。
スクリプトの可読性の観点で、適切なコメントも必要だと思いますがその観点だとどうですか？
その結果、期待通りに問題点が抽出され、さらに対応優先度まで提案してくれました。
3. 既存のスクリプトを改修する
もともとは仕様変更の依頼でしたが、問題点を放置しておくわけにもいきません。依頼元に報告した上で、問題点の修正も実施することにします。とはいえあまり長い記事になるのもよくないので、優先度が高い問題だけを修正してもらおうと思います。
まずは優先度：高の問題点を修正してください。
この通り、README.md の項目に従って 5 つの優先度が高い問題点を修正してくれました。問題点が修正できたところで、当初の依頼であった FATAL も検出できるように改修を進めてもらいます。
監視文字列として、FATAL も検出できるように改修してください。
diff で示されている通り、grep コマンドを修正して改修が完了しました。
本来はデグレ試験なども必要になりますが、いったん今回の記事ではここまでとしましょう。
なぜインフラエンジニアに Kiro が向いているのか
二つのシナリオを通じて、Kiro がインフラエンジニアの日常業務にどのように貢献できるかをご覧いただきました。ここで、インフラエンジニアにも向いている理由を一度振り返ってみましょう。
1. ドキュメント化の自動化
インフラエンジニアが作成する Shell スクリプトは「書いた本人しか理解できない」「動いているから触りたくない」という状況に陥りがちです。
Kiro は仕様書ベースでの開発を前提としているため、開発プロセスの中で自然とドキュメントが生成されます。しかも、単なる機能説明だけでなく、セットアップ手順、実行方法、ファイル構成まで含んだ実用的なドキュメントが作成されるため、引き継ぎや保守作業が格段に楽になります。さらに、既存のスクリプトから仕様書を生成することも可能です。
2. ベストプラクティスの適用
インフラエンジニアが作成するスクリプトは、本番環境で長期間稼働することが前提となります。そのため、エラーハンドリング、適切なログ出力、セキュリティ対策、リソースの適切な管理など、多くの考慮事項があります。
しかし、これらすべてを毎回完璧に実装するのは現実的ではありません。Kiro は、こうしたベストプラクティスを自動的に適用したコードを生成してくれるため、「動くけど不安なスクリプト」ではなく、「安心して運用できるスクリプト」を効率的に作成できます。
3. 学習コストの低さ
多くのインフラエンジニアにとって、従来の AI を搭載していない統合開発環境は「アプリケーション開発者のもの」という印象があり、導入に心理的なハードルがありました。また、これらのツールは高機能である反面、設定や操作方法の習得に時間がかかることもあります。
Kiroは VSCode ベースでありながら、主要なインターフェースは自然言語での対話です。「こういうスクリプトが欲しい」「この部分を修正したい」といった要望を日本語で伝えるだけで作業が進むため、新しいツールの操作方法を覚える必要がほとんどありません。
まとめ
いかがでしたか？
Kiro 利用開始のハードルは決して高くありませんので、ぜひ試してみてください。日々の Shell スクリプト開発が、驚くほど効率的になるはずです。従来手作業で数時間かかっていた仕様書作成からコード実装までの作業が、Kiro との対話により大幅に短縮され、かつ品質の高いドキュメントも同時に得られます。
また、本ブログではご紹介しませんでしたが、Kiro CLI という直接ターミナルで利用可能なツールも提供しています。こちらもインフラエンジニアにとっては馴染みやすいツールだと思うので、ぜひこちらのブログをチェックしてください。
今回の記事は以上です。いよいよ kiroweeeeeeek も折り返しを迎えましたが、今後の記事にもぜひご注目ください。
引き続き X で #kiroweeeeeeek をつけて様々な角度からの投稿をお待ちしています！