今はAI（特に生成AI）の技術進化と、その有効な活用方法の確立が同時並行で進められている状況かなと思ってる。今回の記事ではAI活用に関する、直近1年以内で個人的におもしろいなと思ったトピックを2つ、自分の意見も交えつつ紹介する。
あ、当ブログ、いつもは「エンジニアじゃない人にも分かるように」をモットーに記事を書いてるんだけど、今回はちょっと分かりづらいかもしれないですごめんなさい。あと僕はAIの専門家でもなんでもない、ただの一介のフリーランスで働く組み込みエンジニアであることも断っておきます。
AI活用で学習効率爆上がり
まずは今年の1月頃に話題になったこちらの投稿。AI活用で学習効率が爆上がりしたという現役高校生のX投稿とそれに対する反応をまとめたもの。
AIの進化で、勉強効率が本当に劇的に上がった。学校の勉強も同じで、昔は数学の問題が分からなかったら答えを見て、詳しい解説を友達に聞く必要があったけど、今はGPTやo1に問題の画像をアップするだけで、めっちゃ丁寧に解説してくれる。効率が爆上がりしてるから、今の中学生とかが羨ましい。
現役高校生「昔は数学の問題が分からなかったら詳しい解説を聞く必要があったが今はGPTやo1に聞いたら丁寧に解説してくれるので学習効率が上がっている」 - Togetter [トゥギャッター]
僕も業務で生成AI（Copilot）を活用してるけど、主な用途はコード生成というより、既存コードをなるはやで理解するために、コードの内容や動作を自然言語（日本語など）で説明してもらう、といった使い方になってしまっている。現状、分かりやすいようでよく分からない説明止まりな気もするけど、これは僕の使い方が悪いのかもしれない。
学習効率が上がると言えば、個人的に助かるのは専門書に書いてある数式の式展開を補足してくれるとかだろうか。ページ数の都合上、式展開の行間を端折ったりな専門書がほとんどなので生成AIがそこを補足説明してくれるならめっちゃ助かる。あと誤記を指摘してくれるとか！
そう考えると、今後、紙の本の需要ってますます減っていくんだろうな。紙の本だと該当ページを写真で撮ったりスキャナで読み込んだりして電子データにする手間が発生するから。本の内容をマルっと入力させてそれをベースに分からない箇所を説明してもらうとか、本全体の要約を説明してもらう、なんて使い方も紙の本では難しいだろう。
とはいえ、こんな意見もある（上記リンク先より引用）。
LLMは英語とかの質問はかなり得意だけど、数学は超苦手で少し質問が込み入るとめっちゃ適当なこと言っている印象なんだが、どうなんだろうな
どうなんだろうね。自分で試してみれば分かるんだろうけど、なんていうか、そこまでAIを活用することにモチベーションが湧かないんだよな。AIの仕組みというか理論を学ぶことに対するモチベーションはあるんだけど。なんでだろ(´･ω･`)
生成AIに疑似コードで指示すると自然言語よりも効率的にプログラムを生成できるよって話
こちらは去年の7月頃の記事。あんまり話題になってた記憶はないけど、僕も同じことを考えてたので「やっぱそうなるよね」って感想を持った。
このような疑似コード*1を、生成AIと人間がやりとりするためのプログラミング言語として発展させ、構文などを定義した生成AI用の疑似プログラミング言語「SudoLang」が提唱されています。
生成AIに疑似コードで指示すると自然言語よりも効率的にプログラムが生成できるというアイデアから生まれた、生成AI用の疑似言語「SudoLang」 － Publickey
ところで僕は以前こんな記事を書いた。
この記事の主張を一言で要約すると、
仕事の抽象度が上がる可能性はあるが、AIにエンジニアの仕事が奪われることはない
ってことなんだけど、この「仕事の抽象度が上がる」ってのがどういうことなのか、その具体例を示しているのが冒頭のリンク記事。
言葉で説明するより図で表した方が分かりやすいと思うので、ざっくり冒頭のリンク記事の内容をベースに、僕の考える生成AIを活用したコード生成の未来予想図を描いてみる。
図1が現在の、生成AIを使ったよくあるコード生成の活用方法。現在の生成AIは、間違いのない完璧なコードを生成するためのツールといった感じではない。どちらかというか不完全でもいいからとりあえず生成させて、それを人間が手直ししながらブラッシュアップさせていくみたいな使い方が多いのかなと思う。でもこの使い方は僕は正直イマイチだと思ってる。
だって人間が手直しするってことは、少なくとも生成AIが生成したコードに人間が一通り目を通す（＝レビューする）必要があるってことだから。これだと生成AIが生成したコードを理解するのと、自分がイチからつくるのとどっちが早いか、みたいな話になってくる。
一方で、間違いのない完璧なコードを生成AIが生成できるのだとしたら、もはや生成したコードを人間がレビューする必要はなくなる。コンパイラが生成した機械語コード*2を人間がレビューしないのと同じ理由で。つまり生成AIが完璧なコードを吐き出してくれるなら吐き出したコードはブラックボックス*3として扱えるってことになる。
しかしながら間違いのない完璧なコードを生成しようすると、どうしてもプログラミング言語のようなガチガチの構文ルールが必要になってくる。それだと今の生成AIのような柔軟性がなくなり、一気に敷居が高くなってしまう（また新しいプログラミング言語覚えないといけないのか、みたいな）。
じゃあ現在の生成AIのような柔軟性と生成コードの完璧さを両立するにはどうすればいいのか？それに対する僕の考えは「中間コード（疑似コード）を介す」ってこと。
（所望のプログラムコードを生成する場合）
こんな感じ（図2）。疑似コードの生成に関しては、今の生成AI同様、人間の意図を完璧に反映したものを生成できる必要はない。というか抽象的であいまいな指示から人間の心の奥底の言語化できない意図まで汲み取った完璧なものを生成するのはどっちみち不可能だろう。
疑似コード生成において大事なのは、人間にとってプログラミング言語よりも直感的に分かりやすい表現であること（＝疑似コード文法の学習の必要性がないこと）と、生成された疑似コードが文法的に完璧であること。あとは人間と生成AIがプロンプトを介して対話しながら、人間の意図を100%反映した疑似コードになるまでブラッシュアップさせていけばいい（図2の①～③を繰り返すイメージ）。
最後に、人間の意図を100%反映した文法的に誤りのない疑似コードを入力として、所望のプログラミング言語（PythonとかC言語とか）で書かれたコードにトランスパイラ（＝別の言語で書かれたプログラムに変換すること）する（図2の④⑤）。ここでのトランスパイラの精度は完璧（あるいはそれに限りなく近いこと）であることが期待される。そうでなければ最終的に生成したコードをブラックボックスとして扱うことができないので。
もはやこうなってくると最終的に生成されるコードがPythonなのかC言語なのかみたいなことはどうでもよくなってくる。なぜなら基本的にそれらのコードを読むこと自体必要なくなるから。これが実現できるとおそらく次のような活用方法もでてくるだろう。
（実行ファイルを生成する場合）
（シミュレーション実行する場合）
実行ファイル*5まで含めて生成してしまう（図3）、あるいは生成AIのプロンプトを介してプログラム動作のシミュレーションまで行う（図4）といった使い道。これ、既存のMATLAB/Simulinkを用いたコード生成の活用例と非常に似てるんだよね。生成AIの場合も同じような形で収れんしていくんだろうなって思ってる。
じゃあこうなったときにソフトウェアエンジニアに必要になってくる能力ってなんだろう？それはシステム仕様やアルゴリズム仕様、テスト仕様といった「仕様を定義する能力」だと僕は考えている（上の図を見れば明らかだよね）。「仕事の抽象度が上がる」ってのはこういうことだ。
ばいちむ
*1:実行することはできないが、人間にとって直感的に分かりやすく書かれた架空のプログラムコードのこと。自分で決めた一定の文法に基づいて、英語や日本語などの自然言語でプログラムの説明文を書く、みたいなイメージ。具体例がリンク先の記事に掲載されているのでそれを見るとイメージ湧くと思う。
*2:コンピュータ（CPU）が理解し実行できる形式で書かれたプログラムコードのこと
*3:内部がどのように作られているかは分からないが、外から見た時の入力に対する出力の関係だけは分かっているような機能のこと。例えば自動車が動く仕組みを知らなくても自動車が運転できるのは、自動車がブラックボックスとして機能してるから。
*4:実行環境（ランタイムシステム）っていうのは、作ったプログラムをWindowsパソコンで実行するのか、iPhoneで実行するのか、みたいなこと。専門用語を使うと「コンパイラ」や「インタプリタ」に何を使うかとほぼ同義。
*5:コンピュータが直接実行できるファイルのことで、機械語コードの集合体
