生成AIと「いっしょにコードを書く」という新しい仕事観

その同僚は膨大な知識を持ち、驚くほど速くコードを書き上げてくれます。しかし同時に、その同僚は昨日覚えたはずのライブラリの最新仕様を今日は忘れてしまっていたり、変数名を何の悪意もなく微妙に間違えてしまったりもします。少し癖はあるけれど、付き合い方さえ覚えれば、これほど頼もしいパートナーはいない――生成AIとのコーディングは、そんな不思議な体験だと感じます。

段階的なアプローチという賢明な選択

まず、「いきなりコードを生成してもらうのではなく、概要を伝えて、プログラムの概要を生成してもらってから実際にコードを生成してもらう」というアプローチを採ることは、 とても合理的な判断だと思います。

これは建築に例えるならば、設計図なしに大工さんに「とにかく家を建ててください」と頼まないのと同じです。最初に概要を共有し、AIが解釈した設計図を確認してから着工することで、 根本的な方向性のズレを早期に発見できます。「Webアプリ」と理解してほしいところを「CLIツール」として設計し始めてしまうような、取り返しのつかないズレを未然に防げるのです。

この概要の確認段階では、使用するプログラミング言語、フレームワーク、そしてライブラリとそのバージョンを明示的に合意しておくことが特に重要になります。 後述するバージョン問題の多くは、この段階で防ぐことができるからです。

依頼プロンプトは「発注書」のつもりで書く

生成AIへの依頼は、優秀なフリーランスエンジニアへの発注書を書く感覚で臨むとよいと思います。曖昧な指示は、曖昧な成果物を生みます。

環境情報をはっきり伝える

環境情報の明示は最初の鉄則です。「Python 3.12」「React 18」「TensorFlow 2.16」といった具体的なバージョンを伝えることで、 AIが参照する知識の範囲を絞ることができます。AIの学習データには様々な時代のコードが混在しており、バージョンを明示しないと古い書き方と新しい書き方が混在したコードが生成されてしまうことがあります。

制約条件と非機能要件も最初に載せておく

制約条件と非機能要件の明示も、見落とされがちですが重要です。「外部APIへの通信はすべてエラーハンドリングを入れてほしい」「関数の単体テストを書いてほしい」 「コメントは日本語で書いてほしい」といった要件をあらかじめ伝えておくと、後から追加依頼する手間を減らせます。生成AIは、明示されなかった要件については、良くも悪くも自分の判断で埋めてしまいます。

モジュール構成の粒度を指定する

また、モジュールの粒度を指定することも有効です。「すべてを1ファイルに収めてほしい」あるいは「機能ごとにファイルを分割してほしい」といった指示がないと、 AIは自分の好みで構造を決めてしまいます。その結果、自分のプロジェクトの慣習と噛み合わないコードが出てきてしまい、後から整理するコストが意外に大きくなることがあります。

生成されたコードとどう向き合うか

コードが生成されたとき、依頼者はレビュアーおよびテスターという重要な役割を担うことになります。ここで気を抜いてしまうと、AIの優秀さへの信頼が思わぬ落とし穴になってしまいます。

ライブラリのバージョン問題を疑う習慣

ライブラリのバージョン問題は、最も頻繁に遭遇するトラブルの一つです。たとえばPython界隈では、scikit-learnやTensorFlowのAPIは比較的頻繁に変更されており、 1〜2バージョン前の書き方で生成されることがあります。生成されたコードに見慣れない書き方があれば、公式ドキュメントで該当バージョンのAPIを確認する習慣をつけておきたいところです。 「このコードはバージョンXXで動作することを確認した」と自分自身でコメントを残しておくことも、後のデバッグで大きな助けになります。

変数名の一貫性を機械にチェックさせる

変数名の一貫性も、意外な盲点です。AIは長いコードを生成する際、途中で変数名を微妙に変えてしまうことがあります。 user_dataとして定義したものが、30行後にはuserDataとして参照されている、といったケースです。IDEの静的解析やリンターを通すことで機械的に検出できるため、 生成されたコードを実行する前にこのステップを挟む癖をつけておくと安心です。

ロジックの正しさはテストでしか担保できない

そして、ロジックの正しさは動作確認で担保するという原則も重要です。コードが一見きれいで、エラーも出なかったとしても、エッジケースの処理が抜けていることがあります。 空のリストを渡したとき、負の数を渡したとき、日本語を含む文字列を渡したとき――AIが想定していなかったインプットを意図的に試してみることが、テスターとしての務めだといえます。

「説明を求める権利」を行使する

さらに、生成されたコードには説明を求める権利があるということも忘れたくありません。理解できないコードをそのまま本番環境に投入することは、 著作者不明のブラックボックスをシステムに組み込むことと変わりません。「このクロージャはなぜ必要なのですか？」「このエラーハンドリングはどのようなケースをカバーしていますか？」と 追加で質問することで、AIは丁寧に説明してくれます。その説明が自分の中で腑に落ちなければ、そのコードを信頼すべきではないと思います。

なぜ依頼者がコードレビュアーであることが重要なのか

生成AIが登場したことで、「プログラムを書く」という行為の意味は少しずつ変わりつつあります。かつては実装力そのものが価値の中心でしたが、 今は「何を作るべきか」「生成されたものが正しいか」を判断する能力が、より重要な位置を占めつつあるように感じます。

その意味で、依頼者がコードレビュアーおよびテスターという役割を担うという認識は、極めて本質的です。AIはコードを書くことができます。 しかし、そのコードが自分のシステムの文脈において正しいかどうか、セキュリティ上の問題がないか、将来の保守性を損なっていないか――これらを判断できるのは、 現時点ではまだ依頼者自身だけです。

生成AIとのコーディングを「AIに丸投げする作業」と捉えるのではなく、「AIを道具として使いながら、自分が責任を持って設計・検証する営み」と捉えること。 そのマインドセットこそが、生成AIの恩恵を最大限に引き出しながら、品質の高いソフトウェアを生み出していくための、今のところ最良の態度なのだろうと思います。