はじめに
子どものトイレトレーニング、親にとって結構な試練です。我が家も例に漏れず、トイトレ停滞中でした。保育園では高頻度でトイレに行けているようですが、家のトイレはボイコット。たまにやる気を出してくれるときもありますが、なかなか習慣化しません。そんな時、「これはやる気の問題だろうから仕掛け作ったら状況変わるかも」と思い立ったのが今回の開発のきっかけです。
市販のトイトレ用品も色々ありますが、きっとすぐに慣れてモチベーション戻っちゃいそう。それなら、子どもの好きな動物キャラクターが出てきて褒めてくれる、オリジナルの装置を作ってみようと考えました。そして、飽きたり慣れてきたらその動物のバリエーション増やしたり、乗り物や別のものに変えてしまえば半永久的に興味を示してくれるだろうと思いました。
ちょうどKiro（AI IDE）の性能を試している時期でもあり、その力を試してみたくなったのも理由の一つ。普段はWebアプリケーションの開発が多く、ハードウェアを使った組み込み開発はほとんどありませんが、AIの力を借りればなんとかなるのではないかという期待もありました。
結果的に、想像以上にKiroに任せることができ、ほぼすべての工程をAIに任せながら進めることができました。技術選定から実装、デバッグ、さらには画像や音声の自動生成まで、従来であれば数日かかっていた作業を、日曜日の朝、一時間ほどで完了できたのは驚きでした。
今回は、その開発過程を振り返りながら、Kiroを使った実際の開発体験や、人間が介在すべきポイント、そして今後のAI駆動開発の可能性についてまとめます。
作ったもの
M5Stack Greyを使った「トイトレ応援デバイス」です。手のひらサイズの小さな装置ですが、子どもが喜ぶ機能をたくさん詰め込みました。
基本的な使い方はシンプルで、トイレが成功したらボタンを押すだけ。すると画面に動物キャラクター（うさぎ、ペンギン、ねこ）がランダムで登場し、音を発します。
表示は日本語にしており、「といれ できた？」「すごい！」といったひらがなで子どもにも分かりやすくしました。まだひらがなも覚えていなくても、ハートや星の記号を表示しているので、動物だけでなくそこの表示にも反応できます。
機能面では、成功回数を自動でカウントし、EEPROMに保存しているので、電源を切っても記録が残ります。また、初回、5回目、10回目といった特別な回数では、レインボー背景の特別なお祝い画面が表示され、子どものモチベーション維持に効果的です。
実用性を考えて、音量調整機能、電池残量確認機能、長押しでのリセット機能も追加しました。特に電池残量確認は、M5Stackに慣れていないこともあったので、開発中に挙動が怪しい際に少しでも状態把握をしやすくなるよう、左と真ん中のボタン同時押しで簡単にチェックできるようにしました。
操作は極力シンプルに、表示は分かりやすい日本語、音声も興味を引く電子音と、子ども目線での使いやすさを最優先に設計しています。
Kiroとの開発体験
Kiro主導の開発フロー
今回の開発では、通常の開発とは逆のアプローチを取ったことです。本来であれば人間がある程度要件や開発方針を AGENTS.md のように作成するところですが、今回はKiroの能力を試すため、あえて何も用意せず、子どものトイトレ用の装置を作りたいことと、持っているデバイスがM5Stack Greyであること、子どもの年齢あたりの情報の伝達だけから始めました。
期待していたアプローチ vs. 実際のアプローチ
Kiroは「計画立案を得意とするAI IDE」として知られており、通常であれば以下のような体系的なSpec作成プロセスを期待していました：
- 要件定義書（requirements.md） - ユーザーストーリーとEARS形式の受け入れ基準
- 技術設計書（design.md） - アーキテクチャ、データフロー、技術選定の理由
- 実装計画（tasks.md） - 段階的な実装手順とタスクリスト
しかし実際には、Kiroは従来のウォーターフォール的な文書作成ではなく、より実践的なアプローチを選択しました。
なぜこのギャップが生じたのか
このアプローチの違いには、いくつかの理由が想像されましたが、真相は不明です。
-
明示的なSpec作成の要求がなかった - 「Kiroの能力を試したい」という漠然とした始まり方で、正式なSpec作成プロセスのトリガーが発動しなかった
-
プロトタイピング的な文脈の認識 - 「子どものトイトレ用装置」という個人的で実験的なプロジェクトと判断し、企業開発向けの重厚なプロセスを避けた
-
ユーザーの期待値の読み取り - 「とりあえず動くものを作りたい」という雰囲気を感じ取り、文書作成よりも実装を優先した
-
AI IDEとしての学習 - 過去の類似プロジェクトから、個人開発では実装優先の方が満足度が高いと学習していた可能性
結果的に良かった判断だったのか
振り返ってみると、この判断は結果的に適切だったと感じます。もし最初に詳細な要件定義書を作成していたら、「子どもが喜ぶUI」や「動物の鳴き声のような周波数の電子音」といった、実際に作ってみないと分からない部分で時間を浪費していたかもしれません。
ただし、これはKiroの「計画立案能力」を十分に活用できていなかったとも言えます。本来であれば、体系的なSpec作成 → 段階的実装というKiroの強みを活かした開発ができたはずです。
実践重視のドキュメント戦略
大規模な要件定義書や設計書を作成する代わりに、Kiroは以下のような実用的なドキュメントを段階的に作成していきました：
-
setup.md- 開発環境構築の具体的手順 -
testing.md- 動作確認とデバッグ方法 -
voice_creation.md- 音声ファイル作成の自動化手順 -
image_preparation.md- 画像生成とフォーマット変換 -
troubleshooting.md- よくある問題と解決方法
この選択が秀逸だったのは、個人開発において本当に必要な情報に絞られていたことです。大企業の開発では要件定義書や設計書が重要ですが、一人で作る小さなプロトタイプでは「どうやって環境を作るか」「どうやってテストするか」「問題が起きたらどう解決するか」といった実践的な情報の方がはるかに価値があります。
アジャイル的な進行
文書を先に完璧に作るのではなく、「動くものを作りながら必要な情報を整理していく」というアプローチでした。実装中に「音を鳴らしたいから音声ファイルを追加したい」となったタイミングでvoice_creation.mdを作成し、「Macが接続を認識しない」という問題が発生した時にtroubleshooting.mdを充実させる、といった具合です。
これは、AIが人間の開発スタイルや状況を理解して、最適なアプローチを選択している証拠だと感じました。ただし、これが意図的な判断だったのか、それとも単純に「実装優先」の傾向によるものだったのかは、正直なところ分からない部分もあります。
AIの判断プロセスの透明性
今回の体験で感じたのは、AIの判断理由が必ずしも明確ではないということです。Kiroが実装優先のアプローチを取った理由が、高度な状況判断によるものなのか、それとも単純にコード生成の方が得意だからなのか、ユーザーからは見えません。
この透明性の欠如は、AI駆動開発における課題の一つかもしれません。人間の開発者であれば「なぜこのアプローチを選んだのか」を説明できますが、AIの場合はその判断プロセスがブラックボックスになりがちです。
最初の相談から実装まで
開発は「子どものトイトレ用の装置を作りたい」という漠然とした相談から始まりました。正直、最初は「ボタンを押したらなにか動きがあるもの」程度のイメージしかなかったのですが、Kiroの提示と実際の動作を見ていくと、具体的な追加要件が次々と明確になっていきました。
まず動くものをAIが作り、人間が使ってみてフィードバックをする流れでした。例えば、前回と同じキャラクターが連続で出ないようにするスマートランダム機能は、動作確認の際に「前回と変化がないと子どもは飽きそう」と人間がフィードバックしてできた機能です。
また、長押しでのリセット機能は、実際の利用シーンだけでなく開発も同じデバイスですることになるので、人間が機能提案の起因になっています。
「作りながら考える」スタイル
従来の開発では要件を完全ではなくても、ある程度固めてから実装に入りますが、今回Kiroは「まずは基本的なものを作って、使いながら改善していきましょう」というアプローチを提案しました。これが結果的に非常に効果的で、実際に動くものを見ながら「ここはもう少し大きな文字の方が良い」「音量調整機能があった方が良い」といった改善点を見つけることができました。
特に、個人開発の場合は要件をしっかり考えることよりも動かしてみたいというモチベーションが大きいことがあります。そのような場合には、まず動かしてみる、さらに改善していくという好循環が生まれやすいアプローチでした。
コード生成の精度
PlatformIOの設定ファイルから、M5Stack用のC++コード、画像生成用のPythonスクリプトまで、一貫してKiroが生成してくれました。人間はコードは1文字も書いていない状態です。
ライブラリの選定と設定
M5Stack用のライブラリ、音声再生用のESP8266Audio、SPIFFS（ファイルシステム）の設定など、適切なライブラリを選んで設定してくれました。platformio.iniの設定も、board設定からライブラリ依存関係まで、人間が介在する必要なく完遂しました。
エラーハンドリング
素材ファイルが見つからない場合のフォールバック処理、音声再生の失敗時の対応など、実際の運用で起こりうる問題は、実機での動作確認におけるフィードバックもしつつ、コードに盛り込んでくれました。
メモリ管理
ESP32の限られたメモリを考慮した実装になっており、動的メモリ確保の適切な解放や、大きなファイルの分割読み込みなど、組み込み開発特有の配慮がされていました。
画像・音声生成の自動化
特に、画像と音声の自動生成機能は役立ちました。
画像や音声の素材を探したり作るとなると労力がかかるので、自動生成は必須要件に近かったです。今後、素材追加も同様にできる意味でも欠かせない要件です。
日本語画像生成
「といれ できた？」「すごい！」といったひらがなは、最初はM5Stackで文字として表示させるつもりでした。しかし、デフォルトの状態ではM5Stackで日本語のフォントを扱えず、ライブラリを追加する必要があります。
今回、Kiroだけで思考しているときには「これで日本語も表示されます」と言いつつも、文字化け状態であり、こちらから「このブログにあるように日本語対応させて」と指示しました。しかし、何度トライしてもうまくいかず、雲行きが怪しくなりました。そこで、日本語の文字列表示ではなく画像にしちゃえばM5Stackの日本語対応不要だと思いつき、Kiroにその方針を指示しました。
その後、テキストをM5Stackで表示しやすいBMP画像として自動生成するPythonスクリプトを作ってくれました。個人開発であることと子ども向けのものなので、美しさを追求する必要はありません。実際にM5Stackで表示しても読めるし、それっぽいものができました。
音声の自動生成
「それぞれの動物らしい鳴き声を自動生成したい」という要望を出したのですが、これは期待値には届かずでした。
それっぽい効果音をPythonで音声合成を実装してくれましたが、鳴き声とは言えないものでした。
ADSRエンベロープを使った自然な音の立ち上がりと減衰、それぞれの動物の特徴を表現した周波数変化など工夫をしてくれてはいたのですが、残念ながら鳴き声と感じるものにならなかったです。外部ライブラリに依存せず、数学的な計算だけで音声を生成しようとした努力は感じられました。
「すごい といれ できたね」のようなセリフも音声ファイルとして生成してくれています。
開発フローの自然さ
Kiroが作ったものを動作確認してフィードバック、のループは以下のように進んでいきました。
- PlatformIOプロジェクトの初期化 - M5Stack用の設定ファイル作成
- 基本的な画面表示 - 「Hello World」レベルの動作確認
- 音声再生機能 - 単純な音声ファイル再生
- 画像表示機能 - 日本語テキスト画像の表示
- ランダム機能 - キャラクター選択ロジック
- データ永続化 - 成功回数の保存
- 特別機能 - お祝い画面や電池残量確認
この流れが良かったのは、各段階で必ず動作するものが手に入ることです。最初の段階でM5Stackの画面に何かが表示されれば、ハードウェアとの接続が正しいことが確認できます。音声が出れば、スピーカーとライブラリの設定が正しいことが分かります。
Kiroは「まずは動くものを作って、それから改善していく」というアプローチを一貫して取っていました。完璧を目指すのではなく、段階的に品質を上げていく手法は、まさに経験豊富な開発者の考え方でした。
Kiroとの開発がスムーズだった理由の一つはこのような人間らしい開発フローを維持できたことです。AIだからといって一気に完璧なものを作ろうとするのではなく、段階的なアプローチを提案してくれました。
また、問題が発生した時の対応も経験豊富な開発者に似ており、こちらが症状を伝えると原因を探り、修正し、ドキュメントに残す、という安心してバグ改修のチケットを任せられそうな振る舞いでした。
一度にすべてを実装するのではなく、動作確認をしながら少しずつ改善していく、まさに人間の開発者と組んでいるような感覚で、AIとのペアプログラミングの新しい可能性を感じました。
人間が介在すべきポイント
一方で、すべてをAIに任せるのではなく、人間が判断すべき場面もいくつかありました。
要件の優先順位付け
Kiroは多くの機能を提案してくれますが、最終的な優先順位は人間が決める必要があります。今回も「WiFi接続」「データのクラウド同期」など、様々な機能が提案されましたが、子どもの使いやすさや必要性を踏まえて実装順序を調整しました。
例えば、WiFi機能は技術的には面白いものの、トイトレという用途を考えると必須ではありません。むしろ、シンプルで確実に動作することの方が重要です。また、データ同期よりも、電池が切れた時の対応や、子どもが間違ってリセットしてしまわないような配慮の方が実用的だと判断しました。
このような判断は、実際の使用場面を想像できる人間だからこそできるもので、AIが提案する技術的な可能性と、現実的な制約のバランスを取る役割は、まだまだ人間が担う必要があると感じました。
ハードウェア固有の問題
M5Stackの個体差や、SPIFFSの容量制限、電源管理の癖など、実際のハードウェアでしか分からない問題については、人間が現象を観察してKiroに伝える必要がありました。
例えば「ハート画像が表示されない」という問題が発生した時、最初はコードの問題かと思いましたが、実際にはSPIFFSへのファイルアップロードが正しく行われていない可能性がありました。シリアルモニターのログやエラーメッセージを共有することで、Kiroが段階的なデバッグ手順を提案し、最終的にファイル存在チェックとフォールバック処理を追加することで解決できました。
このような、実機でしか分からない細かな調整は、人間が観察して報告し、AIが解決策を提案するという協働が効果的でした。
デザインの最終判断
色使いや画面レイアウト、音の長さなど、感覚的な部分の最終判断は人間が行いました。Kiroは技術的に適切な実装を提供してくれますが、「子どもが喜ぶかどうか」という観点での調整は人間の感性が必要でした。
最初の効果音は警告音のような電子音だったので、気を引くことはできても心地よいものではありませんでした。それに気づく能力は人間のほうが勝っています。
開発効率の向上
従来の開発と比較して、明らかに効率が向上した部分がいくつかあります。特に、初期調査からプロトタイピングまでの時間短縮は劇的でした。
調査時間の短縮
M5Stackの使い方、PlatformIOの設定、ESP8266Audioライブラリの使用方法など、通常であれば数時間かけて調査する内容を、Kiroが即座に適切な形で提供してくれました。しかも、単なるAPIリファレンスの引用ではなく、実際のプロジェクトで使える形のサンプルコードとして提示してくれるため、そのまま動作確認に進めました。
特に、複数のライブラリを組み合わせる際の相性問題や設定方法など、経験がないと分からない部分をカバーしてくれたのは大きかったです。例えば、ESP8266AudioとSPIFFSを同時に使う際のメモリ管理や、M5Stackの内蔵スピーカーを使うための設定など、きっとハマりがちであろうポイントを最初から適切に設定してくれました。
プロトタイピングの高速化
「とりあえず動くものを作る」段階が圧倒的に早くなりました。基本的な機能を実装したコードを数分で生成し、実際にM5Stackで動作確認できるまでの時間が大幅に短縮されました。
従来であれば、まずサンプルコードを探し、自分のプロジェクトに合わせて修正し、ビルドエラーを解決し、という段階を経る必要がありましたが、今回は最初から動作するコードが生成されるため、すぐに機能の検証に集中できました。
周辺ツールの自動化
画像生成、音声生成、ファイル変換など、本来であれば別途ツールを探したり、手作業で行ったりする作業を、すべて自動化スクリプトとして提供してくれました。
日本語テキストをM5Stack用のBMP画像に変換するPythonスクリプト。フォントの選択、サイズ調整、背景色の設定、ファイル形式の変換まで、一連の処理を自動化してくれました。手作業であれば、画像編集ソフトを使って一つずつ作成する必要があったでしょう。
おわりに
今回の開発を通じて、Kiroのようなツールが開発現場に与える影響の大きさを実感しました。特に、個人開発や小規模なプロトタイピングにおいては、従来の開発効率を大幅に向上させる可能性があります。
従来、ハードウェアを使った開発は敷居が高く、特に組み込み系の知識がない人にとっては手を出しにくい分野でした。しかし、AIが適切な技術選定から実装まで支援してくれることで、Webエンジニアでもハードウェア開発に挑戦しやすくなったと感じます。
一方で、要件定義、優先順位付け、品質判断など、人間の判断が重要な部分も明確になりました。特に、実際のユーザー（今回の場合は子ども）の立場に立った設計判断は、まだまだ人間の感性や経験が必要です。AIと人間が適切に役割分担することで、より良いものづくりができるのではないでしょうか。
また、今回の開発で興味深かったのは、技術的な実装だけでなく、プロダクトとしての完成度も高められたこと。画像生成、音声合成、ドキュメント作成まで、一貫してAIが支援してくれることで、個人開発でもある程度のレベルのものをスピード感を持って展開できる可能性を感じました。
子どものトイトレという身近な課題から始まった今回の開発でしたが、結果的にAI駆動開発の可能性と課題を体験する良い機会になりました。何より、完成した装置によって、その日から子どもがトイレに行くようになりました。「押していい？」といつも早くボタンを押したそうにしており、トイレに行くモチベーションになっているのは確実です。技術で子育てを改善できた実感があります。
技術の進歩により、アイデアから実装までの距離がどんどん短くなっています。今回のような「ちょっとした思いつき」を、週末の数時間で形にできる時代になっています。これは、個人の創造性を発揮する機会が大幅に増えることを意味し、今後さらに多様で面白いプロダクトが世の中に生まれてくるでしょう。
Discussion