もし、アプリの修正をAIに頼んで、もっともらしいコードが返ってきたら。そのまま採用してよいだろうか。返答が速いことと、目的に合い、後から直せることは別の問題だ。
GitHubの紹介記事は、Javaというプログラミング言語を10年以上使ってきた3人の開発者に、GitHub Copilotの使い方を尋ねている。Copilotは、プログラムを作る作業を助けるAIツールだ。3人の発言から、AIに任せる作業と、人が担う判断を考えてみたい。
コードを出す速さと、採用できるかは別
コードは、アプリの動きを指示する文章だ。GitHubの記事は、AIがコードを素早く生成できても、それだけでは難しい開発上の問題は解けないと説明する。何を作りたいかという前提を伝え、結果を確かめ、後から修正しやすい状態を保ち、世に出すものに責任を持つ必要があるという。これはGitHubが示す開発上の考え方であり、作業時間や品質を測った結果ではない。
修正案が返ってきたら、まず「頼んだ問題に答えているか」を確かめたい。続いて、その変更を別の人が読んで、不具合の原因を追えるかも考える。AIの提案は作業の材料になる。製品に取り込むかどうかは、その材料を確かめて決める仕事だ。
Vlad Mihalcea氏は、開発と文書作業で使い方を変える
Vlad Mihalcea氏は、Hypersistence UtilsとHypersistence Optimizerという二つのプロジェクトで、機能の分析、設計、実装にCopilotを使っていると述べる。何が必要かを調べ、どう組み立てるかを考え、実際にコードを書く。AIの助けを借りる場面は、最後のコード作成だけではない。
一方、レポートやリリースノート（更新内容の説明文）を作ったり、文書を確認したりするときは、より軽量なAIを使うという。機能開発と文書作業では、任せる仕事の性質が違う。同氏の使い方はその違いを具体的に示している。ただし、3人の経験談から作業時間や不具合率への効果の大きさまでは判断できない。
「AIで開発した」という一言には、案を考える、コードを書く、説明文を整えるなど、違う作業が含まれうる。何をAIに任せたのかを知れば、その話が自分の関心にどうつながるかも見えやすくなる。
Patrick Baumgartner氏は、解決策の形を考えてから実行を任せる
チームを指導するPatrick Baumgartner氏は、普段の事業を続けながら仕事を進めるため、すべてを半年止めて変えることはできないと話す。また、解決策の形を作り、実行のより多くをAIエージェントに任せるという考えを述べている。エージェントとは、与えられた課題について作業を進めるAIのことだ。
ここからは本稿の解釈だ。AIに実行を任せるなら、その前に「何を達成したいか」を言葉にし、返ってきた結果を目的に照らして見る必要がある。解決策の形を考えることと、その案に沿って作業を進めることは、ひと続きでも役割が違う。Baumgartner氏の発言は、任せる範囲を考える手掛かりになる。
たとえば、修正したい動きをうまく説明できなければ、返ってきたコードが目的に合うかも確かめにくい。反対に、目的がはっきりしていれば、AIの案のどこを受け入れ、どこを直すかを考えられる。これは同氏のチームで確認された成果ではなく、発言から導いた使い方の視点である。
Frank Delporte氏が重視する、後から直せるコード
Frank Delporte氏は、コードを管理しやすい状態にしておくよう勧める。同僚や将来の自分が、不具合を調べたり改良したりするときに助かるからだという。「保守」とは、作った後も調べ、修正し、改善していく仕事を指す。
この助言をAIの提案に当てはめると、コードが完成したように見える瞬間の先に、次の作業者がいることに気づく。案が複雑で読み解きにくければ、後で問題が起きたときの調査は難しくなる。目的や構造が分かる形なら、修正の手掛かりを残せる。生成の速さだけを見ていると、この時間の差は見えにくい。
3人の発言を、依頼する前、作業を進める間、完成後という順に並べると、人に残る判断が見えやすい。何を作るかを定める。どこまで実行を任せるかを決める。後から直せる形で受け取る。この並べ方は本稿の整理であり、3人が共通の手順として提案したものではない。
私たちが使うアプリにも、完成後の修正はつきものだ。「AIがコードを書いたか」という話を聞いたら、作り手がその結果をどう確かめ、次に直す人へどう渡せるかにも目を向けたい。コードを早く作る力と、長く使える形で受け取る判断は、開発の中の別々の仕事だからだ。