思いつきの実装を AI プロンプトと UI 設計で追加する試み

追加のスパイラル開発として、チャット画面から特定のメッセージを保存できるようにします。
いわゆる、「お気に入り」機能のようなものを、お試しで実装してみようという訳です。

この手の試しに機能は、実装したときのユーザーの効果はあるのか?という問題もありますが、実装してみないとわからないというものが多いです。従来の開発であれば、実装するのも、設計書を書くのも時間が掛かるので「その実装は、本当に意味があるのか?」と事前に議論することが多いでしょう。
しかし、プロトタイプでの工程やモックアップを使ったコードの場合には、実際に動くものを見て考えたほうが議論するよりも早いというのはよくあることです。
それではあっても、モックアップを作ること自体、既存のコードに何かを組み入れて動かすこと自体が手間なことが多いです。

が、先の AI を使ったスパイラル開発の方式で考えれば、

1. 数行のプロンプトでざっくりとしたコードを作る
2. できあがったコードを動かしてみる
3. 画面の動きやコードから、AI で UI 設計や概要設計など逆生成する
4. 出来上がった UI 設計や概要設計を見直す
5. 画面設計や概要設計に従って、コードを再作成する

というサイクルを作ればよさそうです。
UI 設計や概要設計は、コードを生成するときの再現性を高めておくためです。ある程度、開発が進んでしまえばいらなくなる markdown 形式の設計書ですが、プロンプトをちまちまと残しておいて生成するよりも、再現性は高いと思われます。

数行のプロンプトを作る

チャット画面から「お気に入り」に入れられる機能を作ります。
- チャット画面のメッセージをチェックすると「お気に入り」に入れられる
- 「お気に入り」の画面で一覧が確認できる
- 「お気に入り」の画面では、指定したメッセージを削除できる

これを Claude Code で試します。
ベースととなるのは、dev/add-setting-ui-claude ブランチのコードです。

画面的にはチャット画面(ChatScreen.kt)とお気に入り画面(FavoritesScreen.kt)に手を入れることになるので、単機能という訳ではありません。
テスト駆動として作るならば、

1. FavoriteRepository.kt のテストコードを作成する
2. FavoriteRepository.kt を作成する
3. ChatScreen.kt と結合する
4. FavoritesScreen.kt を作成する
5. FavoritesScreen.kt を結合する
6. UI の操作をテストする

という感じでしょうか。最初の「数行のプロンプト入力」の場合は、動きだけを確認して UI 設計を作成することが目的なので、この時点ではテストコードは不要かなと。

できあがったコードを動かす

サンプルとして出来上がったものがこんな感じです。
星マークでメッセージをタップして、お気に入り画面に入れられます。削除ボタンはゴミ箱になっています。
メニューに「★」が追加されているので、今後はメニューが増えたときにどうなるのかわかりませんが、ひとまず動作的には大丈夫そうな感じですね。

試しにアプリを落として再立ち上げしても、お気に入りの内容は保持されています。

repository/FavoriteRepository.kt

// ── 永続化 ─────────────────────────────────────────────────────
private fun load(): List<ChatMessage> = runCatching {
    val json = prefs.getString(KEY, "[]") ?: "[]"
    val arr  = JSONArray(json)
    (0 until arr.length()).map { i ->
        val obj = arr.getJSONObject(i)
        ChatMessage(
            messageId = obj.getString("messageId"),
            senderId  = obj.getString("senderId"),
            timestamp = obj.getLong("timestamp"),
            text      = obj.getString("text")
        )
    }
}.getOrDefault(emptyList())

private fun save(list: List<ChatMessage>) {
    val arr = JSONArray()
    list.forEach { msg ->
        arr.put(JSONObject().apply {
            put("messageId", msg.messageId)
            put("senderId",  msg.senderId)
            put("timestamp", msg.timestamp)
            put("text",      msg.text)
        })
    }
    prefs.edit().putString(KEY, arr.toString()).apply()
}

コードを修正する

お気に入りの画面で、ごみ箱のアイコンをタップすると、即座にメッセージが消されてしまうと困るので、この部分を変更しましょう。

- お気に入りの画面で、メッセージをスライドしたときにゴミ箱アイコンがでるように変更
- ゴミ箱アイコンをタップしたときに、リストから削除する

ビルドをして実機で実行するとこんな感じ。

追加した機能を UI 設計書に書き出す

複数のプロンプトをまとめておくために、UI 設計書に書き出します。既存の UI 設計書に追記してもいいのですが、ここでは別途 agents/UI設計書_お気に入り.md を作成して、そこに書き出すことにします。

追加した機能を agents/UI設計書_お気に入り.md に書き出して

たぶん、あとから複数の UI 変更をひとつにまとめた方が効率がいいはずです(これも後で試してみましょう)。

出来上がった、agents/UI設計書_お気に入り.md はこんな感じです。

出来上がった UI 設計や概要設計を見直す

果たして、この UI 設計書が今後のリファクタリング等に耐えられるかどうかは判断しかねます。UI 設計にしては、コードのファイル名やメソッド名が直書きになっているので、コード変更に弱い感じがしますが…アプリ開発時の一時的な参考としてはこれで十分でしょう。
すくなくとも、UI 設計書から Claude Code や GitHub Copilot などの異なる AI エージェントを使っても、同じようなコード(完全に同じとは言えないが)が生成される「再現性」が担保できれば ok です。

- 「お気に入り機能」を 概要設計.md に追加 
- UI 設計書をひとつにまとめる

作業を追加しておきます。いわゆる、機能追加や仕様変更を、設計書に反映する作業です。

いわゆる、情報のトレーサビリティの問題で、概要設計書やUI設計書から過不足なくコードに反映されていればよいという発想です。細かいところは、かつては詳細設計という形で詰めていたのですが、昨今はコードが残ればだいたい ok です。
コードからドキュメントを再作成するツールはかつてもありましたが、UML の出力やクラスのメソッドの一覧などの留まっていました。

現在ならば、AI でコードから生成した設計書をもとに、AI 自身が設計書をもとにコードを再生成ことも可能だろう、という考え方です。

まとめてしまったので、設定とお気に入りの UI 設計書は削除してしまいます。

画面設計や概要設計に従って、コードを再作成してみる

修正した概要設計と画面設計を使って GitHub Copilot でコードを再作成してみます。
ベースはお気に入りの機能を入れる前の branch: dev/add-setting-ui-claude を使って試します。

概要設計.md と UI設計書.md に従ってコードを変更して

AI が設計書の差分から確認し始めるので、なんらかの形で差分がわかるような設計書の作り方にしたほうがいいかもしれません。あるいは Git の差分を見て AI 自身が判断するようがよいのかも。実際、コードの差分などは Git diff を取ることが多いので。

お気に入り画面の背景色がちょっとミスっているのはさておき、ほぼ Claude Code で作ったコードと同じものができます。これで、概要設計やUI設計が「再現性がある」という状態ということが確認できます。

AI を含めたスパイラル開発

仕様駆動開発の場合には、要件定義や設計を煮詰めるところから始まるのですが、プロトタイプをもとにしたスパイラル開発の場合は、最初は「数行のプロンプト」で描けるような所謂バイブコーディングでも構いません、というスタンスになります。ただし、そこでできあがるのは、あくまで「動作確認」のコードなので、そこからいったん「設計生成」を生成した後に AI によるコード生成をします。

こうすると、設計からコードへの再現性を確認できるし、バイブコーディング的な AI コード生成の動作確認も可能になるのでは?と思うのですがどうでしょうか。

このスパイラル開発のループに「自動テスト」を入れることになります。テストコードとしては

  • 動作確認を自動化するための自動実行コード
  • 設計から生成されたコードを確認するためのテストコード
  • 完成品の品質を確認するためのテストコード

などが考えられます。

これを次から組み入れていきます。毎度、Android Studio でビルドした後に、チャットメッセージの動作確認を手作業でやっているのですが、これが意外と面倒です。できれば自動化したいですよね。果たして自動化できるのでしょうか?

コード

https://github.com/moonmile/BLE-chat

  • branch: dev/add-favorites-claude : お気に入り画面を Claude Code で 追加
  • branch: dev/add-favorites-copilot : 更新した設計書から GitHub Copilot でコード生成
カテゴリー: 開発 パーマリンク

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

*