目次
ギターペダルの小さな画面に、自作プログラムの画面を表示する。動けばうれしい。けれど見た目は、どうにも1980年代風。今っぽく整えたいが、Linus Torvalds氏はJavaを書かない。カーネルが専門だからだ。
そこでAIにコードを作らせてみた。最初に出てきたものはひどかったという。それでもTorvalds氏はAIを使うのが楽しいと話す。自分がすでにできる仕事を丸ごと任せるのではなく、苦手な部分を補う道具として使っているからだ。
チェコのプラプで開かれたOpen Source Summit Europeで、Torvalds氏は長年の友人であるDirk Hohndel氏とAIについて語った。Linuxカーネルの開発では慎重さが必要だとしながらも、趣味のプログラミングや初心者の挑戦にはAIが役立つと見ている。その話からは、AIを使う場所と、出力を確かめる手順のヒントが見えてくる。
「自分ができない部分」を任せる#
Torvalds氏は、ギターペダルのマイコン画面を作る趣味のプロジェクトで、C言語を使って自分なりのユーザーインターフェースを動かしていた。プログラムは書ける。けれど、見た目を今世紀風に整えるのは得意ではない。Javaも書かない。
そこでAIに、画面の見た目を改善するコードを頼んだ。最初の出力は期待外れだったが、何が違うのかは判断できた。自分で書いた部分と比べ、「動作はすでにできている。足りないのは見た目だ」と切り分けられたからだ。
この使い方では、AIに丸投げして完成品を受け取るのが目的ではない。自分の専門外にある作業のとっかかりを作り、出力を見ながら修正する。コードの内容を自分で確かめられる範囲で試すのが前提になる。
初心者が「作ってみる」きっかけにも#
Torvalds氏は、AIをプログラミングの楽しさにつながる「きっかけ」として捉えている。昔はコンピューターもソフトウェアも比較的シンプルで、個人が作った小さなプログラムにも価値を感じやすかった。いまは洗練された商用ソフトが身近にあり、個人の作品が見劣りしやすい。
AIがあれば、従来なら難しくて手を出せなかった題材にも挑戦しやすくなる。画面づくりに詳しくなくても、まず動くものを作り、見た目を改善する案をAIに尋ねられる。コードを一から書けない人でも、アイデアを形にする入口を得られるかもしれない。
ただし、AIが出したコードを理解しなくていい、という話ではない。出力に間違いがあれば、動かないだけでなく、思わぬ不具合を持ち込むこともある。何を変えたのか、なぜその変更が必要なのかを確かめてから使いたい。
カーネル開発では、趣味と同じ使い方はできない#
Torvalds氏はLinuxカーネルのメンテナーで、日々の実質的な開発作業は多くの協力者が担っている。カーネルに関わる重要な仕事では、AIの利用にとても慎重になる必要があると述べた。
趣味のプロジェクトなら、AIの提案を試して壊れたら戻す、という進め方もできる。ところが、カーネルに送られるパッチやバグ報告は、メンテナーが内容を確認し、影響を見極めなければならない。AI生成の出力が大量に届けば、確認する側の負担が増える。見かけ上もっともらしいコードでも、正しいとは限らない。
つまり、AIを使う判断は「使うか、使わないか」だけでは決まらない。誰が出力を検証するのか、その結果を誰が保守するのかも考える必要がある。個人で試す小さな工作と、多くの利用者が頼るカーネルでは、求められる慎重さが違う。
まずは小さく試し、出力を確かめる#
AIを自分の作業に取り入れるなら、次のような順番が現実的だ。
- 自分がすでに理解している、小さな課題を選ぶ
- AIには、苦手な作業や面倒な下準備を頼む
- 出力を既存のコードや仕様と比べ、変更点を確認する
- 実行して問題がないか試し、不要な変更は取り込まない
たとえば、簡単な画面の装飾や、既存コードの説明を頼むところから始められる。いきなり重要な機能を任せるより、間違いに気づける題材が向いている。AIが書いたコードを読んで分からない部分があれば、説明を求めたり、別の案を出させたりする。そのうえで、採用するかどうかは自分で決める。
Torvalds氏の話は、AIなら何でもうまくできるというものではない。専門外の作業を助けてもらい、できることを広げる一方で、重要な成果物には慎重に向き合う。AIに任せる範囲を決め、出力を確かめる人がいることが大切だ。
まずは小さな個人プロジェクトを一つ選び、自分の苦手な部分だけをAIに頼んでみよう。出力を読み、動かし、納得できたところだけ取り入れる。その試し方なら、AIが自分の作業に役立つかを確かめやすい。
出典: https://japan.zdnet.com/article/35253465/
目次
