【ITニュース解説】When AI Moved Into My Editor: Faster… and Weirdly Slower

AIがコード生成に初めて使われたとき、その速さと正確さに多くの開発者は驚きを隠せなかった。筆者の体験も同様で、AIが瞬時に動く小さなコードスニペットを生成した際、通常なら必要だった検索や比較の作業が不要になり、その価値を即座に感じたという。当時はまだ高度な推論能力を持つ「思考モデル」は存在しなかったが、それでもAIの潜在能力は明らかだった。

その後、AIの使い方は進化を遂げた。初期段階では、開発者はコードを大規模言語モデル（LLM）に渡し、分析や書き換えを依頼し、その結果を手動で自身のコードベースに組み込む、という「コピー＆ペースト」を繰り返していた。これは一定の効果はあったものの、完全に満足できるものではなかった。しかし、AIに推論能力が備わる「思考モデル」が登場すると、状況は一変する。AIが生成するコードの質は向上し、Railsのような一般的なウェブフレームワークでは、生成されたコードにほんの少し調整を加えるだけで済むことが多くなった。一方で、Martenのような比較的新しいフレームワークでは、AIの知識が不足しているため、より多くの修正が必要となる傾向が見られた。

次なる大きな進化は、AIがインターネットを検索できるようになったことだ。これにより、AIは最新のドキュメントを参照できるようになり、Martenのような新しい技術にも対応できるようになった。開発者はAIに「まずMartenのドキュメントを読み、それからXYZ機能を実装してほしい」と依頼できるようになったのである。この段階では、AIがほとんどの作業をこなしてくれるように感じられ、「もう自分の頭を使う必要はない」と錯覚するほどだった。しかし、実際には依然としてAIに詳細な文脈を伝えたり、コンパイルエラーや特殊なケース（エッジケース）について説明したりする手間が必要だった。これはまるで、経験の浅いジュニア開発者とペアプログラミングをしているような感覚に近い。AIはインターネットから無作為に情報を拾い上げて提案してくるが、それが常に適切とは限らず、動作することもあれば、しないこともあった。

さらに、AIがエディタ内に統合され、ファイルの読み込みや文脈の自動把握が可能になった。これにより、手動で文脈を伝える手間は省けたが、新たな課題も生まれた。開発者はCLI（コマンドラインインターフェース）を通じてAIに機能要求を出すが、期待通りに動作しない場合、何が問題だったかを繰り返しAIに教える必要があった。また、AIが勝手にファイルを変更することを避けるため、手動で出力結果を確認し、承認するサイクルを維持した。この「プロンプトを書いて結果を待つ、結果を修正する、微調整する」というパターンは、時としてAIの返答を待つ時間がボトルネックとなり、開発サイクルを遅らせる原因にもなった。

最近になって、この「待機、修正、コンテキストのコーチング」といったAIとのやり取りのコストが、開発全体のスピードを落としていることに気づいた。Railsのような確立されたフレームワークでは小さな機能であれば問題ないが、Martenのような新しい環境では、依然としてコンパイルエラーや微妙な誤用が発生し、慎重なガイダンスが求められる。また、AIがコードベースを密かに変更し、何が変わったか追跡できなくなることを警戒する気持ちも強まった。

特に筆者の信頼を揺るがしたのは、AIが生成した大きなコードブロックが「魔法のように」動作していたものの、後になって動作変更の必要が生じた際のことだ。この変更要求に対してAIはうまく対応できず、誤った修正を繰り返し生成し始めた。最初のコード生成時に十分なレビューを行っていなかったため、後からの適応に時間がかかり、最初から自分で実装するか、きちんとレビューして拡張性を確保していれば良かったと痛感したという。これは明らかに自分の責任であったと反省している。

AIがプロジェクト全体を完成させてくれるという幻想を抱いていた時期もあったが、それは間違いだった。AIは既存の勢いを加速させるツールであり、プロジェクトのアイデア出し、プロダクトの方向性決定、技術的なトレードオフの判断、そして地道な作業は人間が担うべき役割だという明確な教訓を得た。

現在、AIの利用方法について慎重な姿勢に転じている。AIは非常に印象的な技術であり、ここに留まることは間違いないが、「AIが人間の仕事を奪う」という誇張された hype（宣伝）は現実とは異なる。AIは問題を解決する能力を持つが、経験豊富な開発者の一貫した品質を提供することはまだできない。AIが得意とするのは、開発者を正しい方向へ素早く導くことだ。

その上で、AIをより効果的に活用するための具体的なプラクティスを確立した。まず、開発を始める前に要件定義書を作成する。これは、達成したい目標、存在する制約、考慮すべき例外、そして受け入れ基準を明確に定めたもので、開発プロセス全体を通じて唯一の信頼できる情報源として機能する。また、何から手をつけていいか全く分からない場合は、AIを使う前に徹底的な調査から始めることが重要だ。

次に、AIには計画段階で次に何をすべきか、どんなリスクがあるか、何が不足しているかを尋ねるが、実際のコードの大部分は手書きで進めるべきだ。AIに任せるのは、小さなコードスニペットや特定のアルゴリズムの生成といった部分的な作業に留める。AIにインターネット検索機能がある場合は、特定のライブラリやツールのドキュメントを分析させ、その回答を読み、必ず引用元を確認する。

AIの活用範囲を適切に設定することも重要だ。AIにはプロジェクトの足場固め、コンポーネント間の結合コード、データ移行スクリプト、定型的なデータ変換といった作業を任せる。しかし、ビジネスの核となるドメインロジックや、特定のフレームワークにおける斬新なパターンといった部分は、人間が責任を持って実装する。制約や不変条件、インターフェース、エッジケースといった情報をAIに最初から明確に伝えることで、手戻りを防ぎ、効率を高めることができる。

AIの出力はジュニア開発者のプルリクエストのように扱い、変更は小さく、レビューしやすい状態に保つよう心がける。テストを最初に、または並行して書くことも重要だ。AIに意図を明確にするテストコードをドラフトさせれば、設計の不一致を早期に発見できる。さらに、コードの変更には「なぜその変更をしたのか」という理由を5行程度の簡潔な設計意図としてAIに記述させ、コードの隣に保存すると良い。

AIが3回連続で誤った提案をした場合、その部分は人間が直接対応する、というように試行回数を制限するルールも設けた。そして最も重要なのは、AIが生成したコードが「ただ動作する」ように見えても、レビューは決してスキップしないことだ。ここに潜在的な技術的負債が忍び込むからである。

結論として、AIが近いうちに人間の仕事を完全に置き換えることはないが、目標達成のための強力な補助ツールとなることは間違いない。適切に利用すれば、AIは人間の知識を拡張し、開発の勢いを加速させる。しかし、AIはあくまで「優秀なヘルパー」として扱うべきだ。最終的な出力は必ずレビューし、ドキュメントに依存する場合は引用を確認し、テストと簡潔な要件定義書を品質のチェックポイントとする。そうすることで、AIは害よりもはるかに多くの利益をもたらすツールとなるだろう。