コードLLMがソフトウェア開発の未来にもたらすもの

マシンと共同でコードを作成する時代に入りました。

OpenAI社のChatGPTがテクノロジー業界に初めて登場したとき、最初のユースケースの1つとしてコード生成を掲げ、生成AIの時代が始まりました。その後、草分け的なGitHub社Copilotから、Amazon社Q Developer、Anthropic社のClaudeCode、Google社のGeminiCode Assist、IBM Bob、およびMistralCodeにいたるまで、人工知能（AI）コーディング・アシスタントがその後に続きました。

しかし、これらのコーディング・ツールの根底には、強力なテクノロジーが存在します。それは、コード向けの大規模言語モデル（LLM）です。速度や効率を高め、ソフトウェアの構築方法を変えつつあります。

コードLLMがソフトウェア開発者の役割をどのように再定義しているかについて内情を探り、これらのモデルの将来に対する予測を得るために、数名のIBMエキスパートに話を聞きました。洞察を共有するのは以下の面々です：

• Kaoutar El Maghraoui、プリンシパル・リサーチ・サイエンティスト

• Bridget McGinn、リサーチ・ソフトウェア・エンジニア、AI for Code

• ``Rameswar Panda``、ディスティングイッシュド・エンジニア

• 佐藤 史子、シニア・テクニカル・スタッフ・メンバー兼シニア・マネージャー、AI for Code and Security

コードLLMは、ソースコードでトレーニングされた特化型モデルです。これらは、スクラッチから構築することも、コーディングのデータ・セットでファインチューニングされた事前トレーニング済みモデルから作成することもできます。コードLLMがさまざまなプログラミング言語における多様なコーディング・シナリオに対応できるようにするためには、このトレーニング・データが高品質かつ十分に多様である必要があります。

コード向けのLLMは、通常、自然言語処理（NLP）向けに設計されたAIモデルから派生しているため、多くの場合、自然言語による記述をプロンプトとして受け取ります。これらは、以下のような実世界のコーディング・タスクを実行できます。

• デバッグの支援

• コード補完（オートコンプリートとも呼ばれる）

• コードの生成

• コード・リファクタリング

• コードの要約

• ドキュメンテーションの生成（コード・スニペットのインライン・コメントとして）

• レガシー・コードのモダナイズ（COBOLからJavaへの変換など）

• コード最適化の提案

• 既存のコードをあるプログラミング言語から別の言語へ翻訳（PythonからJavaScriptへなど）

コードLLMの一般的な例としては、Google社のCodeGemma、Meta社のCode Llama、Mistral社のCodestralやDevstralなどがあります。一方、オープンソースのコード・モデルには、DeepSeek Coder、IBM Granite Code、およびQwen3 Coderがあります。

プログラミング専用ではないものの、コーディング向けにトレーニングおよび最適化されている他のLLMとしては、Anthropic社のClaude SonnetやOpus、Google社のGemini Proなどがあります。

コードLLMはソフトウェア作成へのアクセスを民主化し、コンピューター・サイエンスの正規の教育やトレーニングを受けていないシチザン・コーダー、ドメイン専門家、その他の非伝統的な開発者を支援します。これらは、迅速なプロトタイピング、より速い反復サイクル、および新しいソフトウェア・エンジニアのより迅速なオンボーディングを可能にします。

コードLLMは、ソフトウェア開発を再構築するだけでなく、ソフトウェア開発者の役割を再定義しています。

El Maghraouiによると、ソフトウェア・エンジニアはコードの生産者からコードのキュレーターへと進化しています。「コーディングが不可欠であることに変わりはありませんが、重点はプロンプト・エンジニアリングへと移行しています。これらのLLMのコンテキストにおいて、適切なクエリーをどのように構築すればよいでしょうか。And開発者はコードを1行ずつすべて書くのではなく、AIが生成したコードをオーケストレーションし、断片をつなぎ合わせることが増えています。」

しかし、この進化は氷山の一角にすぎません。El Maghraouiは、開発者の役割が、自身が「インテント駆動型エンジニアリング」と呼ぶものへと進展すると考えています。そのアイデアは、構文から離れて構造に焦点を当て、細部を削ぎ落として全体像へとズームアウトし、「何を」から「なぜ」へと切り替えて、目的、成果、およびインパクトを強調することです。

McGinnにとって、コードLLMはプログラムにインポートされるライブラリーとして扱うことができます。「ライブラリーのおかげで、私たちエンジニアがすでに構築された機能を利用でき、車輪の再発明をする必要がなくなるのと同様に、問題はより迅速に解決できます。」

この見方は、ジェネレーティブ・コンピューティングと一致しています。このフレームワークでは、コード・モデルがモジュール方式のソフトウェア・コンポーネントとしてシステムに統合され、プログラマブル・インターフェースのように扱われます。そのため、低レベルなタスクを抽象化して排除することができ、開発者はより高次の問題解決に多くの取り組みを向けることができます。

「開発者は、コードを書くことよりもデザイン思考を考慮する必要があります」と佐藤史子は述べています。「私たちは、システムのアーキテクチャーを作成できる、より高レベルなエンジニアを必要としています。」

これは、デザインやアーキテクチャーだけでなく、倫理やセキュリティーといった他の側面も取り入れ、より多角的な役割になりつつあります。「手作業が減り、自動化が進んでいますが、より戦略的になっています」とEl Maghraouiは述べています。「ソフトウェア・エンジニアリングを、システム・レベルの思考、製品の思考、および倫理的な推論と融合させているのです。現在、私たちは単にコーディングのリテラシーがあるだけでなく、AIリテラシーを持ち、AIファーストのエンジニアになりつつあります。」

これにより、特にジュニア開発者にとって、それらのより高レベルなタスクに関するアップスキリングの道が開かれます。「多くのベンチマークの目標は、ジュニア開発者の機能レベルに達することです。したがって、それが私たちの目指すメトリクスであるならば、その必要性をそれほどなくすという考え方になります」とMcGinnは述べています。「私たちはジュニア開発者よりも深いレベルを持つ人材を必要としています。あるいは、シニア開発者が何を行うかを理解するために、もはやジュニア開発者の役割を経験する必要さえなくなるかもしれません。」

Pandaは、他のあらゆる大規模言語モデルと同様に、コードLLMにも欠点があると指摘しています。同氏は、特に金融やヘルスケアなどのセクターにおける重要なアプリケーションに取り組む場合、著作権、バイアス、およびセキュリティーに関して注意を促しています。

「それらにただ盲目的に依存することはできません」とPandaは述べています。「彼らが生成したコードは、常に割り引いて考える必要があります。」

この懐疑的な見方は、健全性と正確性を検証するためのパフォーマンス最適化メカニズムや検証手段とも組み合わせる必要があります。「手動で作成された場合と同じくらい徹底的に、テスト・ケースを作成し、コードをチェックしていることを、引き続き確認する必要があります」とMcGinnis氏は述べています。

El Maghraouiは、コードLLMへの依存ではなく、コードLLMからのサポートを強調しています。「これらを教材やペア・プログラマー、あるいはアイデア・ジェネレーターとして使用すれば、学習、創造性、および生産性を高めることができます。しかし、自己反省や検証を行うことなく、これらを依存先として使用すると、私たちの判断力や説明責任が損なわれる可能性があります。」

検証は、開発者が基礎となるコンピューティングの原則を把握している場合にのみ可能となります。結局のところ、プログラミングの基本を理解していなければ、これらのモデルによって生成されたコードの妥当性をどのように確認できるでしょうか。

「これは高速なコーディングですが、常に堅牢、正確、またはセキュアであるとは限りません」とEl Maghraouiは述べています。同氏は、生成されたコードをそのまま使用することは危険を伴う可能性があると付け加えています。「コードベースに脆弱性をもたらす可能性があります。これらのモデルに過度に依存したり、そのアウトプットを過度に信頼したりすると、特にクリティカルなシステムにおいて、潜在的なバグや非効率性が伝播する可能性があります。そのため、何が起きているかを理解することが重要なのです」。

ここで深い専門知識の出番となりますが、それを可能にするのがソフトウェア開発の基本概念です。

「学校では、今でも手作業で筆算の割り算を教えていますが、電卓を使うのであれば、それに何の意味があるのでしょうか。それはコーディングにも似ています。何が起きているかを理解するために、重要だと考える基礎的な要素とは何でしょうか」とMcGinnは言います。

これらの技術的な基盤の一部には、コンパイラー、コンピューター・アーキテクチャー、データベース、メモリー管理、およびオペレーティング・システムが含まれる場合があります。「コードLLMがこれらの概念を抽象化しているため、開発者はこれらの概念を深く学習することをスキップし始める可能性があります」とEl Maghraouiは述べています。しかし、ソフトウェア開発の内部の仕組みを理解することは、ソースコードの機能やパフォーマンスに影響を与えるため不可欠であると同氏は付け加えています。

また、コードLLMは反復的なタスクの自動化を通じて認知のオーバーヘッドを削減できる一方で、El Maghraouiが呼ぶところの「認知の萎縮」を引き起こす可能性もあります。El Maghraouiはそれを、GPSの利用増加が人間の本来の方位感覚を損なうことに例えています。「開発者がコード提案に深く依存しすぎると、デバッグがスムーズにできなくなるでしょう。基礎的な実践や基礎的な知識とのバランスを取らなければ、コードLLMはアルゴリズム的に思考する能力を弱める可能性があります」。

コードLLMが進歩するにつれて、新しい機能や斬新なユースケースさえも明らかにするでしょう。それは、バイブ・コーディングのトレンドによって実証されています。では、これらのモデルの未来には何が待ち受けているのでしょうか。当社のエキスパートが予測を提示します。

世界は、AIエージェントがソフトウェア開発を含むほぼすべての業界で働き方の未来を変革するという話でもちきりです。

「自己修復型のコードベースを備えた、これらのマルチエージェント・コーディング・システムへの移行が進むと考えています」とEl Maghraouiは言います。これらのエージェント型AIシステムは、すでに具体化しつつあります。例えば、IBMのソフトウェア・エンジニアリング（SWE）エージェントは、まずコードベース内のバグの場所を「特定」し、次いでそれらのコード行を編集してバグを解決することにより、GitHubの問題を自律的に解決できます。

McGinnは、「すべてを最大のモデルで行うのではなく、異なるエージェントが特定のプログラミング・タスクを遂行する、より小規模なエージェント型アプローチによってエネルギーを節約できる」という、よりエネルギー効率の高い戦略を期待しています。

同様に、Pandaは、Granite Codeのような小規模言語モデル（SLM）をラップトップやエッジデバイスなどのリソースが制限されたデバイスで利用できるようにすることに期待を寄せています。「同時に、SLMで解決するのが困難な課題もあるため、その場合はより大規模なGraniteモデルが登場することになります。単一のモデルですべてを解決するのではなく、複数のモデル間のバランスが重要です」

コンテキストに応じたメモリーと推論をコードLLMに統合することも、注目すべきもう1つの改善点である、とEl Maghraouiは指摘します。「これらはプロジェクトの全履歴とそれがどのように進化したかを記憶できます。これにより、将来に向けてより適切な提案が可能になります」。

Pandaが表現するように、推論コンポーネントは「長期的なタスク」に役立ちます。「コードLLMはコード・リポジトリーと対話し、単発のアクションだけでなく、多くのアクションを連続して実行するようになるでしょう。コードLLMの推論能力が高くて初めて、これらのタスクを実行できます」。

今日の統合開発環境（IDE）は、コード・モデルやコーディング・アシスタントをサービスまたはプラグインとして組み込んでいます。しかし、未来のIDEはAIネイティブの開発者環境へと向かう可能性があります。「これらのIDEがプラグインとしてではなく、コアの一部として、コードLLMを使用してゼロから再設計されるのを目にすることになるでしょう」とEl Maghraouiは言います。

El Maghraouiはまた、コードLLMのプライベート・インフラストラクチャーへのデプロイの増加を成長トレンドとして捉えています。例えば、CodestralとDevstralを搭載したMistral AI社のCode AIアシスタントは、オンプレミスでのデプロイをサポートしています。

「これらのコードLLMのプライベート・デプロイメントは、パフォーマンス、コスト、およびプライバシーに関する懸念によって加速されています」とEl Maghraouiは述べています。「企業は、独自のコードをサード・パーティーのAPIに送信することを避けたいと考えています。プライベート・デプロイメントにより、ソースコード、内部ライブラリー、およびスタック・トレースが社内ネットワークから外に出ないことが保証されます。特に金融やヘルスケアにおける規制コンプライアンスの問題もあり、高スループットのユースケースを社内で実行するコストは、大規模な場合には安価になる可能性があります。」

コードの記述とテストの作成は、ソフトウェア開発プロセスの個別の部分です。佐藤は、コードLLMがこれら2つの段階をシームレスにリンクさせるのを支援し、コード生成とテスト生成の両方に役立つことを想定しています。

「シームレスな製品を作るために、これらを同じモデルで接続する必要があります」とSatohは言います。佐藤はさらに一歩進めて、要件定義や設計などの初期フェーズを含む「ソフトウェア開発ライフサイクル全体をサポートする」コード・モデルを予見しています。

しかし、マシンと共同で作成されるコードのこの成長期が私たちをどこへ導こうとも、El Maghraouiは慎重ながらも楽観的な姿勢を崩しません。「それは両刃のナイフのようなものです。開発者としての私たちを傷つけるものになる可能性もあれば、私たちを助けるものになる可能性もあります。そのため、強みを失うことなく、よりクリエイティブになれるよう、これらのコードLLMを適切に使用する方法を理解することが極めて重要です」。そして、成功を収める可能性が高いのは、これらのワークフローを受け入れ、AIを単なるツールとしてではなく、パートナーとして扱う「開発者や企業」であると、El Maghraouiは信じています。