GPT-4との新たな開発体験: AIとペアプロを極める

こんにちは、クレスウェア株式会社の奥野賢太郎 (@okunokentaro) です。本記事では、GPT-4を使った開発体験について語りたいと思います。

2023年3月14日、GPT-4が発表されました。GPT-4とは、OpenAI社が開発した最新のAI技術で、自然言語処理の能力が従来のGPT-3.5と比較して、さらに向上しています。これにより、文章生成やコーディングの補助といった様々な分野での応用が期待されており、開発者にとっても非常に興味深いツールとなっています。現在は、GPT-4を利用するためにはChatGPT Plusという課金コンテンツに月額20ドルを支払う必要があります。驚くことに、この記事もChatGPTに大半を書いてもらいました。それでは、GPT-4を活用したコーディング体験について紹介します。

AIとのペアプロに近いコーディング体験

筆者はGPT-4公開初日である日本時間の3月15日からChatGPT Plusを購読し、いくつものプロンプトを試しました。プロンプトとは、シンプルにいうとChatGPTに対して送る質問文や依頼文のことです。Googleでいう「検索ワード」のようなものが、より長く、より文章らしくなったとイメージすればよいです。

筆者の手元には、従来の書き捨てスクリプトのような感じで書き捨てプロンプトが増えつつあります。そして、プロンプトのスニペットも既にストックが生まれ始めています。これらはGPT-4に対して指示を出すときに「こう伝えればうまくいきやすい」という経験に基づいています。

GPT-4にTypeScriptコードを書いてもらうように依頼すると、いくつでも実装してもらえます。そこでいくつかGPT-4にCLIツールを実装させてみて気付いたこととして、GPT-4は完璧なコードを生成してくれなかったとしても、こちらが完璧になるように追加の指示プロンプトを充実させている間に、人間側の方でより考えがまとまってくるのです。

そこで筆者が思いついた実装断片をGPT-4に提示して「この関数を使ってみて」というように促すことがありました。そしてGPT-4は実際にその関数を取り入れてくれました。この流れは、ペアプログラミング（ペアプロ）に近いものがあると感じます。

そして日本語で（開発者の母国語で）GPT-4に対して「こういう仕様を満たすコードを書いて」と依頼するとき、その依頼内容は「自分だったらどう依頼されたら作れるか」と考えながらまとめるので結果的に仕様が明確になり、書き捨てCLIスクリプトですら従来よりもstrictなものができあがり、他への流用のしやすさを感じます。

2023年は、このような「相手がAIだろうが人間だろうが、明確に実装指示を起こせるデベロッパー」が生き残るようになっていくと明らかに感じました。この指示スキルは対人であっても元来必須なもののはずですが、意外とスカスカな要件でも詳細を確認せずに引き受けてしまう人がいてしまう結果、軽視されがちだった気がします。

要件定義能力がますます重要に

GPT-4は確実に優秀になっていると感じますが、それでも複雑な要件を3つくらい混合させて「こういう関数を作れるか」と依頼すると、「それっぽいけど全く出力が期待通りじゃない関数もどき」を返してくることがあります。それは仕方ないことです。

そこで3つの要件を分解して依頼し1つずつ実装してもらうと、意外とどれも正しい関数として実装してくれます。そして、3つの要件を満たすそれぞれの段階に応じた3つの関数をまとめて「この関数に合うテストを書いて」と依頼してJestのテストコードを出力してもらった後「この関数片のままだと処理効率が悪いからリファクタリングして」と依頼すると、関数を合体させ始めます。テストがあるためリファクタリング前後は当然内容が壊れることはありません。やはり、この流れはペアプロに似ていますし、テスト駆動開発も想起させます。

GPT-4コーディングは、いきなり全要件を与えて全量実装させるよりも背景を伝えて「その背景を満たすために、まずこういうのを作りたいけどどう？」と提案する流れにする方が、品質の高いものを作ってくれやすいと感じます。やはり、対人でも対AIでも「開発時の登り方」という概念が介在しているのでしょう。崖を登るより坂道を進むほうが楽なのです。

ペアプロは、ドライバーもナビゲーターも（駆け出しエンジニアだけでなくシニアエンジニアも）成長することで知られていますが、GPT-4とのやりとりにもそれに近いものを感じ、GPT-4にどう伝えればよいかと考える自分としても、得るものがとても多いと感じます。これからもAIとの共同作業を通して、より良いコードを生み出していけることでしょう。

ただし現在のところ、GPT-4に「どう出力させたいか」と出てきたコードについて「品質としてどうか」を見極める立場というのが必要になっており、現代においてはそこは人間が必要だと感じます。とはいえ、5年後や10年後は確実にもっと流れが変わるはずです。

自分は開発者としての背景に、ドメイン駆動設計の習得などから由来する「要件定義と要件分解」が大きく含まれており、これは今までの業務でもとても役に立っていました。今後は、ますます要件を定義できるかが生き残りの上で問われると感じます。ただプログラム片を生み出すだけの存在であれば、駆逐される立場になってしまうでしょう。

GPT-4を活用した業務改善と将来への期待

昨日と今日でかなりGPT-4と今の自分の業務との親和性が見えてきました。セキュリティ上の懸念から業務コードを丸投げしてやりとりすることは避けていますが、業務ドメインと直結しない抽象的な処理の断片については、すでにどんどん壁打ちするようにしています。例えば、書きたいけど微妙に面倒だと思っているようなESLintの新しいルール実装をGPT-4に壁打ちしてもらいながら瞬殺させてしまいました。

E2Eテスト（ブラウザを実際に使用したオートメーションテスト）のやり方なども今後変わってくる気がします。従来の破壊されやすいE2Eテストコードを書くのではなく、日本語で「このボタンを押したらこうなるはず」といったように仕様を書いたら、AIが文章解釈をした上でブラウザを自動操作するイメージがあります。これもAIとの協力によって、より効率的で質の高い開発が進んでいくことでしょう。おそらく調べていないだけで、もう開発が始まっていたり、あるいは公開まで済んでいる可能性があります。

この記事をどのようにして書いたか

本記事は筆者のツイートが元になっています。GPT-4を活用したペアプロを進めながら実況的にツイートを重ねていたものを、すべてGPT-4に与えて記事本文として整形してもらい、そこに見出しやタイトルを与えてもらい、筆者が全体を筆者自身の文体に微調整した上で、最終的にまたGPT-4にその文章全体の推敲をしてもらっています。以下は、ペアプロしている様子や、この記事を生成してもらっている様子のスクリーンショットです。

スクリーンショットからもわかるように、コツとしてはプロンプトとして「事前条件」と「引数」を分けたほうがうまくいくことが多いという傾向があります。そのためスクリーンショット内では「準備はよいですか」というワンクッションを置いています。

この辺りは事前条件と引数の2プロンプトを表現する間に必ず1返答が挟まれるという会話としての特性上、どうコミュニケーションを取るのが妥当かと考えた上で、こう尋ねると回答し始めずに待ち構えてくれるというフィードバックから由来しています。

これはあくまでも筆者の感覚的なものですが、プロンプトをすべてまとめて投稿すると誤読されることがまだありました。ただしこの工夫はGPT-3.5時代のフィードバックから得ていたもののため、GPT-4ではプロンプト内の条件と変数の分解について、もうちょっと精度が上がっているかもしれません。この辺の工夫はエンジニアとしての経験やアイデアが問われる点だと感じており、プログラミング経験の有無とGPT-4の工夫には（年齢が上がれば上がるほど）差が生じると予想します。逆に生まれたときからGPT-4が存在するような将来の子どもたちは、驚くべき速度でこの機能を使いこなしていくと予想しています。

記事の作成において、GPT-4の文章生成はGPT-3.5に比べてかなり遅いことから最初の依頼にかかる時間や手直しや推敲も含めると延べ1時間は掛かっています。筆者は3,000字前後の文章であれば30分程度で書いてしまうため、今回、執筆効率が大幅に向上したかというと実はそこまででもないです。

ただ、ツイートの集合を与えることで、それら全体を要約し見出しを付ける能力などはかなり優れているので、どちらかというと自身の記事執筆よりも、他人のツイートを要約するなどに向いている気がします。もちろん他人の内容を要約させる場合は、私的利用である配慮は必要になってくると思われますので、他人のツイートを要約して自身の記事として公開することなどは別の倫理観が問われ始めると思います。

GPT-4の可能性を追求する

GPT-4には確かに将来性を感じますし、今後もっと多くの開発者が活用し、工夫を重ねることで広まっていくことでしょう。AIは恐れる対象ではなく、私たちが創意工夫して生産性を高めるためのツールと捉えることが大切です。これからの展開が楽しみで仕方ありませんね。今後とも、GPT-4と共に新しい可能性を追求していきましょう。それではまた。