Tsumiki、Claude Code、Gemini CLI を組み合わせて、
スマートメータのデータ収集とエアコンの自動制御を「仕様駆動」で実装しました。
AIエージェント主体で設計〜実装〜運用まで進めた実例として、今更ながらですが紹介します。
Switchbot、Nature Remoのセンサーデータの収集、Nature RemoのAPIによるエアコンの設定温度の自動調整を実装し、Google Cloud上で稼働させています。
一応、仕様駆動開発とし、人の手で作成したのは仕様、設計の修正、各タスク作業後の指摘がほとんどとなります。
- Gemini CLI、Claude Code、Tsumikiとのやり取りに関して、記録をとれてなかったので、記載内容に誤りのある可能性があります
- 2025/08時点(Kiroがまだ招待制だったころ)での作業の記録であり、古い情報がたくさんあります
全体アーキテクチャ
本システムは以下の機能を提供します：
- 📊 データ収集: SwitchBot、Nature Remo、Weather APIからの自動データ収集（10分間隔）
- 🗄️ データ蓄積: BigQueryでの時系列データ管理・分析
- 🤖 AI予測制御: 線形回帰による温度予測とエアコン自動制御
- 👤 手動操作優先: ユーザーの手動操作を検知し、自動制御を一時停止
- 📈 監視・アラート: Cloud Monitoring + Discord通知による24時間監視
- 🔒 セキュリティ: Secret Manager、IAM最小権限による包括的セキュリティ
下記の図のようにサーバーレス・イベント駆動型アーキテクチャを採用しており、自宅のSwitchBot・Nature Remoのセンサーデータを各IoT機器のAPIサービスを利用して、Google CloudのBigQueryにデータ集約を実施しています。
設定温度制御では、Nature RemoのAPI呼び出しによりエアコンの設定温度変更を行っています。
また、Looker Studioで電力、温湿度推移を可視化しています。
開発の流れ
要件定義、設計、タスク分解、TDDによる開発の流れで進んでいきます。
途中までGemini CLI(Google CloudのGemini)を使用していましたが、2,3日で課金額が3000円を超え、課金額の増加が想定以上だったため、Claude Code の有料プランに切り替えて開発を継続しました。
Gemini CLIの設計やタスク分解、コード生成に不満はなかったです。
実際に使ったリポジトリではなく、最終成果物から公開可能なものだけを使って再構築したリポジトリが下記になります。
要件定義
kairo-requirementsを実行します。当時はGemini CLIで無理やり実行してましたが、Claude CodeにTsumikiプラグインを入れてスラッシュコマンドで実行すればよいです。
/tsumiki:kairo-requirements
要件概要を入力
案件概要は、Google Cloud上で、Switchbot、NatureRemoのデータをBigQueryに定期的に収集する。特定のセンサーの室温を参照し快適温度を維持するようにエアコンを自動制御する。など。いったんやりたいことを書きます。
/doc/specに要件が生成されるので、確認して修正します。最初の要件概要になるべくしっかり入れておけば、ここでの修正の手間が省けると思います。手で修正しましたが、Claude Codeに修正内容を伝えて修正してもらうのでもよいと思います。
通常のシステム開発における要件定義よりも詳細に記載しておくほうが、
後続工程での構成修正は少なくなると感じました。本来要件定義では記載しないようなシステム方式設計の範疇も記載しておくと、設計がスムーズに進みます。
現在は最初に、/tsumiki:init-tech-stackで技術スタックを定義するそうです。
設計
要件定義が完成したら、設計に移ります。
/tsumiki:kairo-design
/doc/designに設計書が生成されます。要件定義同様中身をレビューします。
- アーキテクチャ:
- データフロー図:
- APIエンドポイント仕様: 外部APIインタフェース、内部APIインタフェースが生成されます。外部APIインタフェースはかなり間違っていたので、しっかり確認
- スキーマ
この段階で外部APIインタフェースやテーブル構成もAIが生成してくれます。
要件定義の段階で使いたいデバイスの種類や管理したいデータテーブル構成を伝えておくとスムーズだと思いますが、この段階で生成された内容を見て修正していくとよいかと思います。
タスク分解
設計書がOKであれば、タスク分解に進みます。
/tsumiki:kairo-tasks
/docs/tasks/にタスクが生成されるのでタスクの内容をレビューします。
実装
下記のコマンドで、タスクを実装していきます。
/tsumiki:kairo-implement タスクファイル名 TASK番号
TDDでテストケース作成、実装、テスト実行までまとめてやってくれます。
レビューして問題があれば指摘して修正します。
コミットのルールを当初定めてなかったのですが、タスクごとにコミットさせるようにすればよかったと思います。
キーや公開されたくない情報の分離を徹底できていなかったので、実施しませんでしたが、プルリクエストまでさせてPRでタスク完了をレビューするやり方でもよかったかなと思います。
また、この段階で要件や設計変更を入れるのは可能で、Claude Codeに指示して各種ドキュメントを変更すれば一応変更できます。ただし、一貫性の維持がかなり大変なので、要件定義の段階で可能な限り確定しておくほうが良いです。
テストはフェーズが進むまで単体テストのみだったため、途中からテスト方針を変えさせて、ローカル環境から実際にSwitchBotなどのAPIを実行するテストを行ってからGoogle Cloud上にデプロイする流れとしました。
TDDは初めてやりました。関数もない状態で、関数をテストするコードを作ってNGにし、関数を作成後にパスするか確認という流れでしたが、テストが通ってはいるものの、入出力をテストのパス条件にできていないことが多かったので、いまいちでした。
せめて関数の枠だけでも作って出力が違うからテストNGになった状態から始めて、関数の中身実装後にテストが通ることを確認するのほうが現実的ではないかと思います。
データ可視化
Looker StudioでBigQueryに接続し、温湿度、エアコンの設定温度、消費電力を時系列のグラフ化をしています。
2F書斎が制御対象ですが、快適温度の範囲に設定した室温内に何とか踏みとどまっているのが見えるかと思います。
Looker Studioのレポートは、今回手作業で作成しています。ここもAIに頼めた気はしますが、Looker Studioでの勉強も兼ねてます。
開発完了・運用
プロジェクト完了報告書
プロジェクト完了報告書まで出力してくれていました。
よくまとまっているため、こちら参照ください。
費用
月額費用$10-20USDとありますが、実際は月100円程度でした。
今後の改善点（予測モデルによる最適運転など）
現状のコードだと下記のような課題があります。
- 冷房のみ対応
- 先読みしての温度設定は苦手で、室温が一定ではなく快適温度の上限・下限を行き来してしまう。
- 快適温度の動的変更
- 曜日、時間帯や営業日だけ実行といった機能の稼働日設定（現状はスケジューラで簡易に設定しているのみ）
- ログが二重に出ているなど整理できていない
開発を通しての振り返り
- 仕様駆動開発なのに仕様があいまいなまま進めてしまった。仕様変更は現状のAIでは荷が重かったので、なるべく最初から仕様をFIXし、設計段階でもログ等の入出力仕様を明確化しておくべきだった。
- 人力で開発しようとして２年くらい眠らせていたものを2週間程度の期間で開発、運用開始でき、人の介在が必要なのは、ほぼレビュー対応だけでよかった。
- 仕様駆動開発は可能だが、マイクロサービスに分解してから仕様駆動開発を実施する必要はあると感じた。もっと大きな仕様でも開発は可能だったと思われるが、仕様変更などが発生した場合に、統一感のある対応は仕様が複雑だとおそらく回りきらない。
まとめ
仕様駆動開発を AI エージェント主体で行うこと自体は十分可能だと感じましたが、
仕様変更耐性や一貫性の維持という点では、まだ人の設計力が必要なフェーズも多いと感じています。
一方で、「動かすところまで持っていく」スピードは圧倒的で、
個人開発・検証用途では非常に強力な手法だと思います。
あらためて、今回作成したコードはプライベートリポジトリからコピーして下記で公開しています。
設計、タスク分解、フェーズ1完了、フェーズ2完了時点のコードを登録しています。