アプリの概要

画面に小さなアプリウィンドウを開いて、マウスカーソル付近にある画素の中で比較的多い色の色名とRGB値が表示されます。

色覚多様性の人は、程度や特性にもよりますが、微妙な色の区別がつきにくかったり、色を間違えたりします。
私自身も赤緑色弱の当事者ですが、PC上での作業(資料作成やグループウェアでの作業など)で「指定された色を使って」のような指示を守るのに苦労し、誤った色を使ってしまうこともあります。
Power Pointなどのオフィスアプリの色選択画面で、選ぼうとしている色の色名がキャプション表示されるのにはずいぶん助けられました。

そのような体験から、色選択画面だけでなく、画面上の任意の場所に表示されているものの色が分かったらうれしいのではないかと思い、このミニアプリを作りました。

また、AIを用いてのプログラミングの実戦経験をしてみたかったので、その題材として今回のアプリをAIに生成させました。
「人間はコードを1行も書かない」ことにこだわって、コメント文も含めてあえてAIに全て生成＆修正させました。

開発プロセス

AIとのやり取りは、マイクロソフトCopilotのプロンプト経由のみです。
プログラマーに要求仕様を提示して発注し、プログラマーの成果物を確認するのと同じようなスタイルです。
Copilotは優秀なプログラマでした。

コーディングに用いる言語はC++を指定し、Copilotが生成したソースコードをVisual Studio Communityでビルドして実行させました。
C++を用いた理由は、技術的な理由ではなく、私がコードレビューをする上で最も都合が良い(慣れている)からです。

実装はイテレーションを何度も回しながら完成度を上げていきました。
最初のイテレーションで、試作のつもりで、作りたいものの大まかなイメージをプロンプトでCopilotに指示してコードを生成させてみたところ、プロンプトでのやり取りだけでいけそうな感触が得られたので、そのまま続けることにしました。

イテレーションでの作業の流れ

各回のイテレーションは、基本的には以下のような進め方を繰り返しました。

Copilotにプロンプトで要求事項(要求仕様)を提示し、コードを生成してもらう
Copilotが生成したコードをビルドする
- ビルドエラーが発生した時は、エラーログをプロンプトに与えてCopilotに対処してもらう
ビルドしたアプリの動作確認および必要に応じてコードレビューを行う
アプリの挙動やコードレビューで気が付いたことがあれば、このイテレーションで修正してもらうか、次回以降のイテレーションでの課題にするかを判断する
- このイテレーションで修正してもらう件については、Copilotにプロンプトでフィードバックし、修正版のコードを生成してもらう
- 修正版のコードでの動作確認や、必要に応じてコードレビューを行う
次回のイテレーションでの目標(要求事項)を検討する

Copilotが生成したコードで、公開前の最後の仕上げとして手直しすれば良いような事項については、途中のイテレーションではあえて目をつぶり、最後の方のイテレーションで修正してもらいました。

各イテレーションの位置付け

イテレーション1 : 試作フェーズ - Feasibilityを確認する
- 作りたいもののイメージや動作環境などを、Copilotのプロンプトにラフに指示して、コード生成させる
- 生成されたコードの動作や実装をラフに確認し、この進め方で作りたいものを作れそうかどうかの感触を得る
イテレーション2～7 : 開発フェーズ - アプリの挙動(外部仕様)を確定する
- Copilotが生成したコードを動かして挙動を見ながら、アプリの外部仕様をブラッシュアップしていく
- この段階では、Copilotが生成したコードの中身(実装)は不問とする(動けば構わない)
イテレーション8～10 : 設計フェーズ - 実装を完了させる
イテレーション11 : リリースフェーズ - 公開できるようにする
- 公開向けに、コードのコメントルール/ガイドラインを決めて、Copilotに指示してコードのコメントを修正してもらう
- Visual Studioに新規にプロジェクトを生成して、まっさらな状態からアプリをビルドできることを改めて確認する

Copilotの生成したコードをレビューした時の印象

設計フェーズでは、Copilotが生成したコードをレビューしました。
想像以上に良かったと思ったことは、以下でした。

特別優秀ではない人間よりも、良いコードを生成してくれる
- 例えば、ムーブセマンティクスなど、Modern C++の仕様を活用できている
メモリリークはなさそうである (プロファイラなどでチェックしたわけではなく、コードレビューで確認できた範囲であるが)

コーディングについて指摘したのは、以下のような内容でした。
(抽象的な書き方をしていますが、Copilotのプロンプトには、コードの該当する部分を具体的に指示しています)

コード全体としての一貫性に欠けている部分がある(別人が書いたようなコードになっている) ⇒ 一貫性のある記述にしてもらった
同じようなコードが複数の箇所で書かれている ⇒ 関数化するなどしてコードの重複を避けてもらった
特別な意味のある値をハードコーディングしている ⇒ 定数にしてもらった
アルゴリズムの細部の調整、不適切な処理の指摘、準正常系の処理の調整
- 例えば、動作の厳密さよりも処理の軽さを優先した実装があった ⇒ 処理が重くなってでも厳密な実装にしてもらった
ビルド環境への依存が大きい実装はなるべく避けてもらった

アプリを作ってみて感じたこと

以下は、あくまで今回Windows向けのC++で書かれた小規模のアプリ(BE MY COLOR)を作ってみた範囲で感じたことです。
大規模なアプリや、AIを学習させる題材の少ないプラットフォーム向けのプログラムですと、状況は違ってくるかもしれません。

プロトタイピングだけなら、AIに丸投げできる
- 作ってほしいもののイメージをAIに伝えれば、それらしく動くものを作ってくれる
- 今回は、最初にプロトタイピングをして、あっさりいけそうな感触を得られたので、そのまま進めることにした
イテレーティブな開発プロセスが向いている
- コーディングに時間がかからないので、イテレーションを何度も回して完成度を上げていけば良い(課金は考慮していません)
- 要求仕様も最初から完璧にしようとは思わず、生成されたコードを動かして挙動を見ながらブラッシュアップしていけば良い
- 何度やり直しを指示してもプログラマに嫌な顔をされないのが、AIの強み!?
自分の常識だけで決めるのではなく、AIの知恵を借りるべき
- AIとの共同作業で作り上げていく
  - AIは自分が知らないようなことも広く知っているので、AIと相談しながら仕様やアルゴリズムをブラッシュアップしていくのが良い
  - AIに対して最初からガチガチな要求仕様を提示するよりは、詳細をAIに任せてみることで、自分1人の知恵よりは良いものを作れる
  - 仕様などをどうするか悩む点があれば、AIに意見を聞いてみる
- コードレビューで気になる点があっても、いきなりAIに指摘して直させるのではなく、まずはそういう実装にした理由を聞いてみてから判断する
コード中のコメントなどは、アプリのユーザではなく作成者本人向けの記述内容にされることがあるので、コードを公開する場合は注意する