【ITニュース解説】DIY Holding Tank Sensors Part 2: "The React Native App"

貯水タンクの残量センサーと、それを表示するスマートフォンアプリを開発するプロジェクトについて解説する。このプロジェクトでは、ESP32という小さなマイクロコントローラー（C言語で開発）と、React Nativeというフレームワーク製のスマホアプリをAIを積極的に活用して開発した。AIが開発をいかに効率化したか、そしてどのような課題に直面したかを探る。

スマートフォンアプリの開発は、AIツールの一つであるClaudeを使ってReact Nativeプロジェクトの初期設定から開始した。しかし、すぐに問題に直面した。Claudeはプロジェクト構造に問題があると指摘し、React Native開発を簡略化するExpoというフレームワークからプロジェクトを「eject（切り離す）」するよう求めてきた。開発者はExpoの最新機能を活用したかったが、Expo Goという簡易実行環境ではBluetoothのような特定のネイティブ機能が利用できないという制約があった。このため、Bluetooth通信を可能にする expo-dev-client パッケージの導入を試みたが、これも失敗に終わった。ビルドの途中でプログラムが何度もクラッシュし、node_modulesという依存ライブラリを格納するフォルダのファイルが破損するという状況に陥ったのだ。この経験から、AIに初期設定のような、既に成熟したコマンドラインツールがある領域を任せるのは時期尚早だと判断し、AIに頼り切った開発（「vibe coding」と呼ぶ）によって「コーディングデススパイラル」に陥る危険性を感じ、一度AIから離れて手動でプロジェクトを再構築することにした。

問題解決のため、従来の「正常な方法」でExpoと開発クライアントのセットアップをコマンドラインからやり直し、プロジェクトの基盤を整えた。再びAI（Claude）に開発協力を求めたが、ここでもAIの特性による新たな課題が見えてきた。Claudeは開発者の指示に基づきコードを生成するが、時には「幻覚」を起こすかのように、不要な機能やUI要素（例えば「Explore」タブや「tank history」ビュー）を勝手に盛り込むことがあった。これは、AIがユーザーの真の意図を完全に理解せず、一般的なパターンや学習データから推測してコードを生成することに起因し、これらの不要な要素は後で手動で削除する必要があった。さらに、最も重要な機能であるBluetooth接続の確立にも苦労した。AIに何度か指示を与えても安定した接続を実現できなかったため、最終的には開発者自身が詳細なデバッグと調整を行い、ようやくマイクロコントローラーとスマートフォンアプリがBluetoothで通信できるようになり、センサーのデータに基づいてタンクレベルがアプリ上に表示されるようになった。

このプロジェクトを通じて、「vibe coding」（AIに全面的に依存する開発スタイル）の利点と限界が明らかになった。AIを活用することで、これまで数日から数週間かかっていたであろうマイクロコントローラーと連携するスマートフォンアプリの開発を、わずか2〜3日間で完了できたことは非常に画期的な成果だった。特に、開発者が普段得意としない組み込み系のC言語コードの生成においては、AIは大きな助けとなり、学習や試行錯誤の時間を大幅に短縮してくれた。しかし、AIが生成した初期のアプリは「製品レベル」とは程遠いものだった。例えば、Bluetooth接続時にPIN認証を求められるが、それが実際には機能しない、管理者用のPINを設定できない、マイクロコントローラーの設定をアプリから変更できない、といった課題が残った。これは、AIが基本的な機能は実装できるものの、複雑な要件定義、ユーザーエクスペリエンス、そして特に「セキュリティ」のようなデリケートな側面については、まだ人間の深い洞察と判断が必要であることを示している。今回のBluetooth通信はPIN番号以外の秘密情報を含まず、仮にデータが傍受されても大きなリスクはないと判断されたが、もし機密性の高い情報を扱うアプリケーションであれば、AIの生成コードをそのまま使用することは非常に危険であると感じられた。

開発者はさらにセキュリティを高めるため、Bluetooth通信の暗号化を試みた。マイクロコントローラーのC言語コードに戻り、AI（Claude）に暗号化の実装を依頼した。Claudeはいくつかの選択肢を提示し、最も安全とされる「MITM（Man In The Middle）保護」を推奨したため、それを実装した。しかし、アプリを再ビルドして接続しようとすると、期待されるBluetoothペアリングのためのダイアログが表示されないという問題が発生した。この問題についてAIに尋ねても解決策は得られず、セキュリティに関するAIの生成コードの信頼性に改めて疑問を抱いた。

スマートフォンのアプリ開発に戻り、コードの保守性と拡張性を高めるため、アプリの状態管理（画面のデータや設定などをどう管理するか）を改善することにした。具体的には、すべての状態を一箇所に集中させるのではなく、アプリ全体で共有できる「グローバルコンテキスト」と「リデューサー関数」を使って管理するようリファクタリング（コードの内部構造を整理・改善すること）を試みた。当初、このリファクタリングもClaudeに依頼したが、期待通りの結果が得られず、かえってコードが複雑になってしまった。そこで、別のAIツールであるOpenAIの「Codex」を試すことにした。Codexに同じ質問を投げかけたところ、Claudeとは異なる、より適切なアドバイスが得られた。この経験から、異なるAIツールにはそれぞれ得意不得意があり、一つのAIに固執せず、複数のAIの意見を比較検討し、最終的な判断は人間が行うことの重要性を学んだ。AIの生成するコードは、常に開発者自身が「正しい」と判断できるまで検証する必要がある。

Codexにリファクタリングを依頼した結果、時間はかかったものの、大きなエラーなくコードの改善が完了した。次に、コードの品質を保証するために「テスト」を書くことにした。テストは、コードが意図した通りに機能するかを確認する重要なプロセスである。Codexにテストコードの生成と修正を依頼したが、ここでも課題に直面した。生成されたテストはすぐにパスせず、メモリリーク（プログラムが使用済みのメモリを解放し忘れ、徐々にメモリを消費し続ける問題）のようなエラーが発生した。AIに繰り返し修正を指示しても、問題の根本解決には至らないことがあった。最終的に、AIとの対話の「コンテキストウィンドウ」（AIが記憶している対話の履歴）をリセットし、新しい視点で問題を提示することで、ようやくすべてのテストがパスする状態になった。これは、AIとのやり取りが複雑になりすぎると、AI自身が「迷走」し始める可能性があることを示唆している。

このプロジェクトを通して得られた最も重要な教訓は、AIが開発者の生産性を劇的に向上させる強力なツールである一方で、その限界を理解し、適切に活用することが不可欠であるということだ。AIは、一人では何週間もかかるような開発作業を、数日という短期間で実現する能力を持っている。特に、これまで経験の少なかった技術分野（例えばBluetoothスタックの利用方法）の学習時間を大幅に短縮し、より洗練されたコード（メモ化された関数や抽象化されたクラスなど）を生成する手助けをしてくれた。これは、AIが「思考の速度で開発できる」未来を示唆している。しかし、AIはあくまでツールであり、その出力は常に人間の「判断」を必要とする。AIは不要な機能を生成したり、セキュリティ上の問題を見落としたり、最適化の意図と異なる結果を生んだりすることがあるため、開発者はAIが生成したコードが「適切か」「過剰な設計ではないか」「本当に意図通りに機能するか」といった観点から、常にコードをレビューし、修正する役割を担う必要がある。AIの進化により、高品質なコードと迅速な開発のギャップは縮まるだろう。AIを盲目的に信頼せず、その限界を理解し、注意深く活用することで、これまで実現困難だったアイデアをより速く、高品質で形にできる未来が期待される。AIとの対話で「デススパイラル」に陥った場合は、コンテキストをリセットする勇気も必要だ。AIが開発の未来を変えるが、その舵取りをするのは人間である。