こんにちは。自称ソフトウェアエンジニアの橋本 (@hassaku_63)です。
今日の話は Claude Code を使った Vibe Coding のネタと、作ったツールの紹介記事です。
何作ったのか
Serverless Framework で開発された Stack をリストアップするためのツールが欲しくなったので、業務的なコンテキストを排除しつつ、Claude Code の手習いを兼ねて汎用ツールとして自作してみました。 find_serverless_stacks という名前のコマンドラインツールです。
こんな感じのインタフェースを備えています。AWS プロファイル指定と AssumeRole をサポートしていますので、ある程度いろいろな環境で使っていただけるのではないかと思います。
$ find_serverless_stacks -h
find_serverless_stacks identifies CloudFormation stacks deployed by Serverless Framework
by detecting the presence of ServerlessDeploymentBucket resources.
Usage:
find_serverless_stacks [flags]
Flags:
--assume-role string ARN of the IAM role to assume
--duration int32 Session duration in seconds (900-43200) (default 3600)
--external-id string External ID for AssumeRole (required by some roles for security)
-h, --help help for find_serverless_stacks
-o, --output string Output format (json, tsv) (default "json")
-p, --profile string AWS profile name (default "default")
-r, --region string AWS region name (required)
--session-name string Session name for the assumed role session (default "find-serverless-stacks-session")
実行例はこんな感じです。該当する Stack がリストされます。判定の根拠が reasons に出力されるようになっています（もっとも、本記事執筆時点でロジックは1種類のみですが）。
$ find_serverless_stacks -r ap-northeast-1 | jq
{
"stacks": [
{
"stackName": "sls-example-dev",
"stackId": "arn:aws:cloudformation:ap-northeast-1:1234356789012:stack/sls-example-dev/6b8d28d0-e4da-11ed-a237-06df524be86f",
"region": "ap-northeast-1",
"createdAt": "2025-04-27T09:03:47.834Z",
"updatedAt": "2025-04-27T09:27:40.197Z",
"description": "The AWS CloudFormation template for this Serverless application",
"stackTags": {
"STAGE": "dev"
},
"reasons": [
"Contains resource with logical ID 'ServerlessDeploymentBucket'"
]
},
...
いきさつ
私はここ5年くらい社内 SE としての立場で開発寄りな仕事をしています。
誰がなんのために作ったかもわからない謎 Stack や謎コードベースなどにも遭遇しますし、自分は開発してないコードを引き取ってメンテしたりすることが良くあります。
そして、社内システムとして採用している SaaS たちのグルーとして振る舞う小さな連携システムが、私の管理対象として特にたくさん存在します。複数のアカウント・リージョンにばらまかれてます。
で、そんな小さなシステムたちの中には Serverless Framework で開発されたものが多く存在しました。Serverless Framework は v4 から有償化しており、v4 にスイッチして料金を支払うにしても、CDK 等の異なる IaC に移植するにしても、上申のためにはコスト比較が必要です。
Serverless Framework の課金体系はデプロイするアプリケーション単位が基本ですので、現存する保守対象の Stack のうち Serverless Framework 製のものがどれなのか、いくつあるのかを知る必要がありました。
管理対象の AWS アカウントとリージョンは複数にまたがり、かつ環境ごとにそこそこ Serverless Framework 製のツールが存在していることは感覚値としてわかっていましたし、また他の部署でも似たような事情があることも、なんとなく察せられました。そういうわけで、何回もやる作業ならさっさと自動化したいですし、簡易的に補助ツールを作ってしまおう／ついでにせっかく自作するなら最近の仕事で恵まれない新規実装ネタで Vibe Coding を練習してみよう／さらにツール用途の自体も業務文脈から切り離せる性質なのだから OSS として公開してみよう、などなどのことを思いつき、やってみました。
Vibe Coding のお供として、Claude Code + VSCode を使いました。
成果物
Release に各プラットフォーム向けのバイナリがあるので、それを落として使ってください。
ダウンロードしたバイナリの実行が OS 側でブロックされている場合があります。一例として、私の環境 (MacOS) の場合は以下のコマンドを実行すると、バイナリの実行が許可されます。
$ xattr -d com.apple.quarantine ${downloaded_path}
製作期間は本日（執筆日）の1日です。
どんなスタイルで作った？
コミットログは汚いので、追ってもあんまり参考にならないと思います。なので簡単にここで説明します。
Vibe Coding による機能開発の流れは基本的に「実装計画を立案して md に書き出させる」→「ユーザーレビューOK なら実装に進む」の繰り返しです。
実装計画にはフェーズ分割とゴールの定義（例えばインタフェースの例示などが含まれる）を書かせるようにしました。実行の指示も基本的にここで計画した各フェーズごとに行わせます。一度に全部やるのは私もしんどいですし、あまり大きな単位を破綻なくやり通してくれる信頼もなかったのでこのようなスタイルになりました。
開発サイクルを始める前の基礎資料として、以下のドキュメントを先立って用意しました。
1つ目のドキュメントは皆さんお馴染みの t-wada さん（というか TDD）のスタイルに従え、というものです。これは、考えなしにテストのないコードを量産してもあとが苦しいだけだしな…という意識から用意したものです。またこのハック自体 X でも御本人を含む様々な方が言及されている印象ですので、そのプラクティスに従った感じです。
2つ目のドキュメントは AWS Go SDK v2 のドキュメントを出典とするテスタブルな Go 実装のスタイルを事例で説明するものです。これもちょいちょい言われている話だと思いますので私自身の独自性はありません。ノーヒントで AI のコードを書かせるとどんな個性を出してくるかわかりませんので、一定の方向づけをすることが必要と考えました。で、よりベターな質のコードを書かせるにはテスタブルな実装例を示すことが最も効果的であろう、という意図から AWS Go SDK のドキュメントを参照することにしました。
これらのドキュメントを用意してから、順次計画と実装を進めていきました。
実装計画を書かせる手前の話として、プロンプトか別の md ファイルにアイデアレベルの機能要求を記載しておきました。書けそうな場合は想定するインタフェースとか、この機能の実装が完了した時点でどうなっててほしいのか、などの情報を書くようにしていました。実装計画のアウトプットとしてもこれらの情報を重視していました。これは、結局ゴールの定義がしっかりしていることは私自身にとっても AI との協業という観点においても重要である、という認識によります。
1個の実装計画は基本的に複数のフェーズを含みます。フェーズのブレイクダウンは基本的に AI に書かせました。しかし、実装計画のレベルで何を作るのかの決めは私の方で監修しています。今回のツールはごくシンプルであり、自分の中でも開発イメージが明白でしたので、大きなマイルストーンを事前に脳内で切ることができました。そのマイルストーンがそれぞれの実装計画ドキュメントの単位に落とし込まれている感じです。
このへんまでのやり取りでいくつか文章でのインプット／アウトプットが挟まるわけですが、そのへんはレポジトリの docs/ 以下にまとめました。
一例は CLI ツールに新しく AssumeRole のサポートを追加する実装で、AI に実装計画の立案を依頼する前に以下のドキュメントを書いておきました。
https://github.com/hassaku63/find-serverless-stacks/blob/v0.1.0/docs/feat-assume-role-support.md
これを叩きにして実装計画を作らせました。MFA 対応の要否など本機能に関連のある別口の観点が出てきたので、そのへんの議論は基本的にチャットで行いつつ、たまに docs にダンプしたり、こちらで追加の情報を書き足したりしていました。このへんの進め方は改善の余地があるかもしれません。チーム開発でこのムーブをするとおそらく生成したドキュメントの辻褄が合わず、チームメンバーが検討経緯を後追いできなくなります。
感想
Claude Code で実装した経験は今日時点まででほぼなく、私自身も不慣れなところがありました。また、ここ最近は既存実装のコードリーディングと（開発業務に限定されない）プランニングくらいでしか AI を使っていなかったので、書く用途でまともに AI を使ったのは久々です。
機能的にそこまでがっつりしたものではないですし、やり方が洗練されればおそらくもっと短い時間で作れると思います。例えば並列実行は今回試していないので、例えばそのへんに余地があるかもしれません。
とはいえ、当面はドキュメントや Slash Command 等の整備によって試行の精度と質を上げる方向性を模索するのが先かなぁ、と考えています。
AI に動かせる前に、先にアイデアの概要の書き出しやゴールの定義を行う意識が強かったです。これは、結局のところ「破綻なく計画立案と実装をやらせる」という考え方が根底にあったためです。
破綻させないには LLM のコンテキストを飽和させないことが重要であり、ユーザーがコンテキストの圧迫を回避するような使い方をするのが最も確実と考えていました。そして、私自身も一度に大量の情報を脳内処理するのがしんどい…という事情もありました。こうした事情が反映された結果として、今回は「人間によるインタラクション」が増えるものの、できるだけ人間による監修作業を挟みながら進めるスタイルでの Vibe Coding に落ち着いた、という感じです。
多分、このへんは AI ネイティブな開発にがっつり浸かっている方ならもっと大胆にされて、上手くいってるんじゃないかな？とも思います。なので私の今回のやり方も、時間効率がよい方法であるとは思っていません。
また、私にとってまったくの未知なプロダクト開発であれば、「人間による監修」の粒度のさじ加減は変わっていたかもしれません。もっとざっくりした指示になっていたかもしれません。…とはいえ、Vibe Coding 中の私の意識は「いかにコンテキストを爆発させずに（≒破綻させずに）回せるか」でしたので、仮に自分にわからないプロダクトを実装する場合だったとしても、大きな塊のままブン投げるようなことはせず、何かしらブレイクダウンしてから実装に移れるような方策を講じていたような気はします。
ひとまず、今回の取り組みでそれっぽい体裁のツールを一定の形に持っていくまでが体験できましたので、今後もこのノリで自分にとって必要なツールや気になるネタはじゃんじゃん Vibe していこうと思います。今回作ったツールもしっかり実務に投入してみようと思います。
コメント