今回はイヤイヤ期に入ってしまって意地でもコードを書きたくなくなった僕がGitHub Copilotを調教して代わりにAndroid開発をさせてみた結果を共有したいと思います。

GitHub Copilotって何？

AIがコードの補完をしてくれる機能です。
ZOZOではGitHub Copilotが全社導入されているので僕も試しに使ってみる事にしました。Android StudioにてPluginsを入れてGitHubにログインする事ですぐに使えるようになりました。

何も考えずに使ってみた感想

導入しただけで特に意識せずいつも通り作業するのみだと「ちょっとすごいサジェスト機能」くらいの感覚です。頭の中読まれてるな頭にアルミホイルもっと巻かないと、と思えるくらい先読みしてサジェストしてくれる時もたまにありますが全く意味不明なサジェストも多かったりで劇的に効率が上がるような体験は得られませんでした。

プロンプトエンジニアリングって何？

この記事を書くにあたってとにかく最初に色々試す事をやって行き詰まり、それからドキュメントを読みました。その中で自分がやろうとしている事がプロンプトエンジニアリングだという事にあとから気付きました。

こちらのブログで大きく3つのポイントが解説されています。

高いレベルの目標を設定してステージを設定する
質問はシンプルかつ具体的にし、短い出力を受信することを目指す
1つか2つ例を挙げる

ですが、個人的にはあまりしっくりこなかったです。むしろ下記の内容が分かりやすく感じました(言いたい事は一緒なのかもしれませんが)

コンピューターは指示されたことしか実行できません

指示を非常に具体的にする必要がある

彼らは一度に一歩ずつ命令を受けるのが得意です

アルゴリズムは単なる一連の命令です

たとえば、「ロボット」にサンドイッチを作るように指示する場合、次のように指示する必要があります。

パンの袋を開ける

袋から最初の2枚の食パンを取り出します

食パンをカウンターに並べて置く

バターナイフでパンの一枚にピーナッツバターを塗ります

などなど

自分で色々試してみた結論と通じる部分があり、先に読んでおけば良かったなあと感じました。

コメントからコードを生成する

手始めにユーザーのデータを持つdata classを以下のようなコメントでコードを生成してみました。これだったら素直にコード書いた方が早いじゃんと思われるかもしれませんがイヤイヤ期なのでできません。

@paramを活用したコメントで書いた方が人間にも分かりやすいですね。

理解できない概念があると途端にポンコツ

1つ困ったのが性別をenumで定義しようとしたのですがどういうわけか意地でもサジェストしてくれませんでした。後述しますがgenderという概念が出てくると途端にGitHub Copilotがだんまりしてしまうのでここだけは仕方なく手動で書きました。この辺りの話題には触れたくないのでしょうか？

GitHub Copilotは別タブのコードも読んでサジェストしてくるので関連するコードは開いておいた方がより正確になるらしいのですがこの件に関しては逆効果になりました。また、別プロジェクトの別タブも読んでいるのでそこは注意です。基本的には質の高いコードを食わせた方が精度が高くなる認識で大丈夫だと思います。チーム開発などでコーディングガイドラインを食わせて統一された表記にできるような使い方ができたら良さそうですね。

汎用的なものは得意

逆にハッキリと答えが分かるものはすごく得意なようで曜日や月などはもちろん都道府県などもサジェストしてくれます。
ただ、EHIMEのあとで止まってしまい、KOUまで入力しないとKOUCHIが出てきませんでした(23/12/24時点)。高知県は四国の中ではメジャーな方だと思ってたのですが不思議です。

おまけですが歴代ダービー馬を列挙してもらったところ怒涛のキタサン連発されてしまいました。

最後の方のゼンショー(全勝？)へのこだわりはなんなんでしょう。たまにゼンシューも混じりますね。そもそもダービー勝ってる馬の方が少なくないですか？

定型文に強い

バージョンカタログの記述などは定型文なので大得意です。

ViewModelの記述も// ViewModelと書くだけでサジェストしてくれます。

ViewModelの中身を作ってみる

ViewModelを定義するこれだけだと意味が分からないみたいでサジェストしてくれません。

ですが、ViewModelを〜とコメントからimplementsするとコメントをサジェストしてくれました。更におまけでユーザーデータの追加や削除処理まで付けてくれました。このようにコメントもサジェストしてそれをベースにコードもサジェストしてくれるのが便利です。

ユーザーデータはUiStateとしてView側に公開したいのでUiStateを定義します。最初はMutableStateFlowを公開したので

privateな〜やpublicな〜とコメント追記するとすぐに意図を理解してくれました(最初にprivateと記述したらあとのコメントはサジェストしてくれました)

asStateFlow()はstateFlowを返すという一文はサジェストされた文言をそのまま採用したらコードも期待するサジェストを出してくれました。ですが、人間があとから読むと意味不明になるのでこういうところは人力で修正した方がよさそうですね。

ComposeViewを作ってみる

ここが一番苦戦しました。コメント1つでサジェストの内容ががらりと変わるので試行錯誤が非常に多かったです。また、先程も伝えました通りgenderが入ると精度がやたら下がるのでタブを閉じたり一時的にコード削除したりしました。
色々試行錯誤の結果、以下のようにすると比較的精度の高いサジェストが来るように感じました。

やりたいことを伝える
やりたいことはできるだけ短文で伝える
やりたいことを達成する為には何を使うか/使わないか伝える
命令は冒頭にまとめる
上手くいかなければ1行の命令の追加と削除や命令文の言葉のニュアンスを変えてみる

冒頭にお伝えしたプロンプトエンジニアリングの基礎の内容に近しい印象ですがいかがでしょうか。

パンの袋を開ける

袋から最初の2枚の食パンを取り出します

食パンをカウンターに並べて置く

バターナイフでパンの一枚にピーナッツバターを塗ります

などなど

もし、1のやりたいことを伝えるだけで理想のコードがサジェストがされたらもうそれで万事OKです。
実際になかなかそう上手くいかない事が多いので2のやりたい事を1つ1つ短文で区切ります。
それでも上手くいかない場合に3の具体的に何を使って(使わないで)どうするのかを指定します。

例えばユーザーアイコンと名前を横並びで表示するだけのコメントだと全く検討外れのサジェストしかされませんでした。そこでRowを使って〜と加える事により正しくサジェストされるようになりました。更に中央に配置するだけでなくCenterVerticallyを使って〜と記述する事でレイアウトもサジェストされるようになりました。なので1、2を試して上手く行かない場合はある程度やりたい事に対する知識を必要とするなと感じました。

4は最初に命令をまとめておいた方がコードを類推してやりたい事を先読み(たまに余計な事)してくれるので処理毎に細かくコメントを書くよりも効率が良かったです。下記では頼んでないけどIconとTextの間に余白を作ってくれています。

5は命令の組み合わせや言葉を少し変えるだけで結果が全く異なってくるのでより良い精度を求めて消したり増やしたり色々試してみましょうの意味です。内容によっては理解力が著しく低下する場合があるのでその場合はその一文を消したり別の言い方にしたりです。たまにおかしくなって壊れちゃったりします。

ダミーのユーザーデータを生成させてみた時にnameは日本人とすると記述したら
name = "日本人"
がずらっと並んでしまいました。nameは日本人の名前とすると修正する事で上手く行きました。空気を読んでめちゃくちゃ気を利かせてくれる時もありますが、機械のように振る舞う時もあるので基本的には細かく指示をした方が無難です。壊れた時は一旦コメント削除してAndroidStudioを再起動しましょう。また、全く同じ内容のコメントでも昨日と今日で全然違う事もあります。サジェストされたコードは一期一会です。

成果物

コードを一切書かずにこのような画面が完成しました。

Composeが分かるならどう考えても素直にコード書いた方が早いのは間違いないですが初学者の方には良いペアプロ相手になるかもしれません。今回はコードを一切書かないというコンセプトだったので何回もコメントを調整して理想のサジェストが出るまで耐えましたがざっくりサジェストされたコードをベースに微調整した方が効率がいいです。というか本来はそういう使い方だと思います。

まとめ

コメント(プロンプト)の書き方が調教のカギ
定型文は大得意
別タブで開いているコードを読むので質の良いコードを食わせた方が精度が上がる。
GitHub Copilotが理解できない概念があると途端に精度が落ちたりサジェストしてくれなくなる。その場合はそこだけは人力か該当のコードが書いてあるタブを閉じた方がいい。別プロジェクトのタブも読んでいるので注意
サジェストは一期一会。昨日素晴らしいサジェストを返してくれたコメントも今日めちゃくちゃばかになる事がある
コメントをたくさん書くとコメントもサジェストしてくれるようになるがあまり任せっきりにしてはいけない。適度な命令が必要
たまに壊れちゃう