最近の業務の傾向として、コードを書く仕事が減りつつあるような気がしている*1。
序：
では何をしているのかと言えば、マーケティングの分析をしてみたり、プログラムを教えてみたり、プロジェクトのディレクションをしてみたり(、少しサボったり)、と、ITエンジニアに類する仕事ではあるものの、胸を張って「エンジニアの仕事してるぜ」とは言いにくい周辺の仕事ばかりをしている。ついでに言えば、会社の決算を税理士を入れずに自分自身で行う関係で、経理系の仕事も入ってくる。
コードを書かない仕事が続くと、書きたいと思うものだが、ここ最近は分析のために使うプログラムを作ること(いわゆるツール内製化)をしたりしてコードが書けない寂しさを紛らわしている。
もう一つ、今回の内製コードでは使わなかったが、コードを(ある程度)勝手に書いてくれる、ChatGPTも試したことがある。新たにコードを書き起こす場合にベースとなるコードを作ってくれるので便利。自分でロジックを弄ったり変数を変えたりするだけでだいたい納品レベルに到達するのは確かに便利ではある。
いわゆる「生成AI」を仕事に導入している、と言うほどガッツリと使っているわけではないが、実際に使ってみての感想であったり、今後について少し考えてみたい。
生成AIとコーディング
ChatGPT以外にもコーディングに使うことができる生成AIプロダクト(以下「コーディングAI」と略す)はいくつかあるらしいが、全部を試したりするつもりもないし、コーディングAI同士の優劣の前に、俺自身がAIより優れたエンジニアだと自負しているので*2、顧客要望に応えてコードを微調整することを前提にコードを書いてもらう、という使い方を想定して(実際に使って)いる。
利点まとめ
なにがメリットであるか、という話については、それこそ数多の(含むアフィカス)サイトで礼賛しているので適当にググれば情報が得られるはずだが、俺が感じたメリットを挙げてみると、
- 思った通り(≒指示通り)のコードを書いてくれる
- 再利用性の高いコードを書いてくれる
- バグ0コードを書いてくれる
といったあたり。だが、バグ以外のメリットについては、コーディングAIに対して出す指示がキモになってくる。
生成AI自体の特性として、指示内容(いわゆる「プロンプト」)が具体的であればあるほど精度が高まるので、指示もできる限り細かくすることで思った通りにコードが生成される。再利用性についても同様で、再利用性を前提とした指示を出す必要がある。具体的に俺の実例で挙げるなら、指示は基本的に単一機能についての指示のみとしている。あれもこれも盛りだくさん、という指示を出し(てコード生成をし)たことがないので実際のところはわからないが、普通にチーム開発をするときにエンジニアに盛りだくさんな指示を出しても混乱を招くことの方が多いわけで、明確かつ簡潔な指示を出す方がよいという経験則からそういう指示内容を書くように目指している。
その結果として、バグが、少なくとも生成時点では0になるので、開発中のコードに組み込んでいく*3、という流れでバグの少ないコードを作ることができる。
欠点
ではデメリットだが、メリット同様に数多のサイトをググってみると相当筋違いなことが羅列されているような印象である。筋違い、とは言いすぎな気もするが、いわゆる生成AI一般論として言われるデメリットであり、実利用にあたっての注意点と考えるべき話である。「注意点」は別項で論ずることとして、これまた俺自身の感じているデメリットを書くとすれば、
- 複雑な指示が出せない(≒理解してもらえない)
- 複雑なアーキテクチャに対応できない
- 可読性が微妙によろしくない
メリットとして感じている部分の裏返しな部分も多い。特に「複雑さ」に対する欠点がそれだが、指示内容が明確・簡潔である方がメリットをより享受しやすいと考えれば「複雑」な指示もそうできれば解決できるのかもしれない。デメリットに関しては少し深掘りをしつつ、どうすれば補完できるかについても考えてみる。
複雑な指示が出せない
メリットのところでも書いている通り、
指示内容(いわゆる「プロンプト」)が具体的であればあるほど精度が高まる
のだが、指示内容を具体的かつ複雑にするのは、ある意味矛盾している。可能な人もいるだろうが、少なくとも俺には無理、と思っている。そこまでの高等な言語化スキルを持っているわけではないので。
ただ、プログラム自体は「最終的には」ロジックが複雑に絡み合いながら動いている*4。そのロジックの組み立てや関連付けを行うのは俺の仕事であり、関連付けをひも解きながら個別ロジックのコーディングをコーディングAIに任せ、生成物を組み合わせる、というやり方をすれば解決できるだろう。
複雑なアーキテクチャに対応できない
ロジックを単純化しても、基本的に生成されるコードは、いわゆるオブジェクト指向とはかけ離れたモノだったりする。
Flutterのコード生成を試していた時によく経験したことだが、MVVM(≒MVC)的なアーキテクチャで作りたいと考えていても*5、出てくるコードはビューとビューモデルを混在させた、ある意味シンプルなコードが生成される。
まぁこれも生成されたコードのリファクタリングをする、という手間をとればいいし、ある程度ビューを作っておいて、それをベースにビューモデルを書け、という指示を加えれば済むのかもしれないし*6、ベストプラクティスとまでは言い難いが、俺的なやり方ならシンプルなロジックのルーチンを生成させてリファクタリングでOK。
後であらためて述べるが、コーディングAI(を含む「生成AI」)のみですべての作業を完結させようとするのはどうしても無理がある、と思っている。ある程度は、間違いをしやすい人間の介在を許容してもいいし、多少人間の手間をかけても効率は良いのではないか、という考えである。
可読性が「微妙に」よくない
まず、コードの可読性について前提となる意見を述べておくと、『リーダブルコード』という書籍に書いてあることを守れば、ある程度ではあるが可読性が高くなる、とは思っている。が、可読性自体はその書籍に依るのではなく、特にチーム開発を行う場合はチーム内で決められたコーディング規約に基づかなければいけないし、それによって「チームの内部において(のみ)」可読性が圧倒的に高くなるのである。
[リーダブルコードのAmazonリンク]
それを前提にコーディングAIで生成されたコードを見てみると、かなり『リーダブルコード』を意識した感じで書かれている(ような気がする)。そういう意味では、実は可読性がかなり高い…、のだが、若干冗長的に感じる箇所も多いように感じる。変数名が長くなりがちなのはかなりリーダブルコードチックではある。
ちなみに、一応ChatGPTに「ChatGPTにおけるコーディング規約」について質問してみたところ、
ChatGPT自体はコーディング規約に対する明示的なガイドラインを持っていません。OpenAIが公開している具体的なコーディング規約やスタイルガイドは存在しません。ChatGPTは大規模かつ多様なデータセットを用いて訓練されており、その中には様々なスタイルや規約に基づくテキストが含まれています。
ただし、一般的なプログラミング言語やフレームワークに関する知識を持っており、ユーザーからのプログラミング関連の質問に対してコード例を生成することができます。そのため、コード例のスタイルは多岐にわたる可能性があります。ユーザーが指定したスタイルに従うような生成は難しい場合がありますが、要望があれば特定のスタイルに合わせたコードを生成するような指定も行えます。
という回答が得られておりますです、はい。
と言うことは、もしクローズな環境でコーディングAIを使うことができるのであれば、コーディング規約を事前にAIに学習させておけばよいのだろう。そうでなければ…、と言ったところで、ある程度の「一般的なプログラム言語」の知識があるのだから、例えば変数名を書くときにキャメルなのかスネークなのか、みたいなことは一般的な書き方に基づいて作ってくれるのだろう。
全般的に見ると
業務に使い得るか、という観点で見れば、かなり有益なのだろう、と思う。が、いくつか注意が必要なこともある。一般的な生成AI利用における留意点、すなわち、他のサイトでは「デメリット」と目されていた内容だ。
セキュリティのコトを考えながら使う
オープンな環境で使う場合は特に留意が必要なのだが、生成AIに指示プロンプト(など)を送る場合に、その内容は生成AIにとっては、
- 学習の対象となる情報
- 世界に公開してもよい情報
として扱われる、と言うことを肝に銘じる必要がある。
ありがち(？？？)なのは、自分の書いたコードをデバッグ(添削)してもらう、という用途でコーディングAIを利用する場合だが、コーディングAIに自分の書いたコードを送るということは、そのコードが上記2つの条件を満たすもの、として扱われることになる。
このコードが、もし社内秘であったり、クローズドライセンスであったりした場合、そのコードを送った人物が本来秘匿する必要のある情報を漏洩させた、ということになるのだ。
デバッグしてもらう、という側面だけを見れば、「間違ったコードを送っているのだから問題あるまい」と思うかもしれないが、生成AI側では間違ったコードを修正したうえでさらに学習するわけだし、逆に、そのコードの意味するところ(≒実行することで得られる結果)を他のユーザが質問した場合に、そのままのコードを展開することも十分に考えられる。
メリット・デメリットとして指示内容の具体性・簡潔性について触れたが、そんなセキュリティの面からも、実際のデータの流れを元にコードの動きを具体的に指示する、と言うよりは、想定されるダミーの情報をもとにコードの一部の動きを具体的に指示した方が、情報の漏洩により結びつきにくくなるはずである。
リテラシーを持って使用する
セキュリティ面でも問題もそうだが、俺的に言えば「コーディングAIに関しては初心者お断り」、という感じである。リテラシーという話をするなら、コーディングのコトをわかっていない人にとっても生成AIが勝手にコードを書いてくれる、というリスクがあるのだ。
ちょっとわかりにくいが。
俺含め、エンジニアとしてそれなりの経験を積んでいれば、他者が作ったコードの問題点を見つけることは難しくない。コーディングAIが作るコードのバグがない、という話はメリットとして挙げてはいるが、実際のところ、指示が明確だからバグを混在させる余地がない、という言い方の方が正しいのだ。未経験者の場合は、指示を明確に出せるのであればよいが、基本的に大味な、というかおおざっぱなイメージを指示として出す傾向がある*7。それに対して出してくるコードもあいまいな部分が残っているし、さらに言えばセキュリティ対策なども施されていないわけだ。
でも実行してみれば動くから、とそのままリリースしてしまう。使えない・ヤバいモノができあがるのだ。エンジニアとして見れば我々の評判を下げるようなことをしてくれる、と感じてしまう*8。
「誰でも(コードを)書ける」と言うのがウリなのかどうかは定かではないが、少なくともコーディングAIに関しては、コーディングの知識(言語知識、セキュリティ知識だけでなくIT全般の知識)がないと使い物にならない。
その他の生成AIの利用
コーディング以外でも生成AIの利用シチュエーションは多いし、この1年くらいでいろいろと試してみた。イケてる/イケてない、でざっくりと意見を述べていくが、その前に俺自身の「属性」について少し述べておく。
評価する「俺」の属性
エンジニア以外にマーケティングの仕事もしているので、お客さまに提出する資料なんかも作っています。ただしデザインセンスが皆無です。ブログ読者の皆様もお気づきの通り、文章力も割と貧弱です。
文書生成AI
いわゆる「資料作成」をするときに、どういう切り口で進めていくのか、というのを悩むことは多い。
今までは、切り口をググって調べる、ということをやっていたが、微妙に言葉遣いが違っていたり、切り口という観点だけで言えば、その優先順位によって切り口の順番が変わっていたり、と、とにかく情報が多すぎてどうすればよいかわからなくなることが多かった。
文書生成AIの場合は、とりあえず一つのパターンとして提示してくれるので、その順番はともかく*9ある程度網羅された骨組み部分を示してもらっている。さらに、それぞれの切り口に対する情報の肉付けについてもさらに文書生成AIを使って大まかな肉付けを行う。
具体的な手順
ネタとして作ってみたある企画書の作成手順を示す。
- テーマを決める(命題→切り口の分解) テーマに対して、複数の視点を持たせるような回答を得られるように指示内容を考える。今回のネタは、「なぜ女子はスタバが好きなのか？」というテーマにした。 ChatGPTを使ってこの質問を投げかけると、要因として4点、それぞれの要因に対して若干の解説も加えられている。
- 切り口の深掘り(切り口骨子→肉付け) それぞれの切り口に対して深掘りする質問を投げかける。スタバを好む理由として、「コーヒーが美味しい」という切り口があったのだが、「(スタバの)コーヒーの美味しさ」に対してさらに深い洞察を得られるような質問を投げかける。
- テーマに対して不足している情報を追加する ここからは文書生成AIを使わずに自分で調べるなり、仮説思考で考えていくことになる…。
ざっとこんな感じだが、実際にこの手法でいくつか提案書を作ってみたが、評判は上々であった。
画像生成AI
「会社のロゴ」がないので、小ネタレベルで作ってみよう、というところからDALL-Eを使ってみたが、結論から言うと満足のいく成果物を得ることができなかった。理由は、指示内容があまりにも「センスなさすぎ」だったから、としか思えない。
実は、生成AIにおける指示内容(≒プロンプト)の大切さは画像生成AIを扱っている時に痛切に感じたことである。基本的にコーディングだろうが画像生成だろうが、生成手法は数あれど、やっていることは同じで、こちら側(≒人間)が指示をした通りの何かを、今までAIの仕組みの中で学習した内容をもとに組み合わせて提示する、という仕組みであり、指示内容がカギになる、というコーディングAIを使う上での留意事項が画像生成AIでも言える。
もちろん、たたき台として生成されたものをさらによくする、ということもできるのだろうが、このあたりから「センス」が問われる気もしないでもない。
楽しくつかってみましたよ、と言う程度で終わってしまっているし、あまり深掘りしたくないところだが、全く使えない、という代物ではなさそうだ、とは思っている。
結：
生成AIのプロダクトを業務に使う、というテーマで1年あまり使いながらの考察をしてみたが、総じて『使うためのテクニックが必要』という結論になりそうではある。
実際に生成AI利用テクニックみたいな書籍も見かけたし、よくわからないセミナーみたいなのも開催されているようで、それだけ使うのが難しい、ということ、または使い方がわからない、ということなのだろう*10。
俺の中では、どのようなモノ・コトでもそうだが、「すべて完璧にできなくてはいけない(must)」ということはないと思っていて、このブログの中でも触れているように、画像生成AIについては使いこなせる自信がないどころか、俺には絶対無理、とすら思うし、これ以上(技術的興味以外の理由で)触ることもない気はしている*11。
使えるモノに関してはきちんと使おうと思うけれど、無理して使わなくちゃ、というような性質のものでもないし、もっと言えば使いこなすことが大事なのではなく、それが成果に結びつくかどうか、なので、成果の出せる使い方をもう少し探っていけたらな、という程度で考えている。
余：
生成AIのプロダクトには、当たり前と言うかイマドキっぽいと言うか、APIの呼び出しをすることで自分の作っているアプリケーションと連動させることができる、という機能を持っているものも多いと聞く。
興味自体はあるし、業務で活かすこともできそうだな、という感覚はあるものの、積極的に使っていこう、というほどの魅力も感じていなかったりする。
2022年から2023年の初めくらいにかけては、まだRPAだのチャットボットだの、といった、ML/DLとは別物の「AI」が幅を利かせていた*12が、マーケティングで顧客に対して案内をするためには「その程度の知能(性能)」で十分、という気もしている。
補：
時系列だけで言うと、この投稿の前に年末年始の投稿を書き、そのあとにAIについての展望としてこの記事、そして自社HP作成を進めながら先週の記事のネタを書いた。
HP作成に関しては、コーディング以外の部分でAIの力を借りているが*13、誰かの代わりに作業をしてもらう、と言うよりは、「壁打ち」相手としてアイデアの具現化を進めるやり方だったし、それが想定される使い方(≒ベストプラクティス)なのかもしれない、と思っている。
*1:コードを書いている時間を計測するツールもあるらしいが使ったことがない。あくまでも主観として見ている
*2:語弊を恐れずに言えばコーディングAIはしょせん指示通りにコードを書く「コーダー」だと思っている
*3:もちろん人の手に渡り改修されることでバグが発生することはありうる
*4:微妙な均衡の上に成り立っているという意味ではない
*5:わかりやすく言うと、ビューの中にモデル的なロジックを書きたくない
*6:基本的にリファクタリングで十分だと考えているのでビューモデル再生成指示は面倒に感じる
*7:エンジニアとして顧客と話をするときによく感じる、あのイライラであるｗ
*8:で、直してくれ、と泣きつかれるのだが、あまりにもお粗末な状態なのでそれなりに費用もかさみ、結局うやむやになってしまう、という妄想をしたくなる
*9:最終的に優先度は俺が決めるので
*10:だから教えるというコンテンツが成立している
*11:ホームページ作成では結構使ったし、自分で責任を持てる範囲であれば使っていこうと思った
*13:このあたりの顛末については来週投稿予定
