「ChatGPTは使えない」と嘆く現場へ。独自フレームワークを学習させ開発効率を激変させた製造業A社の全記録

AI開発ツールの導入が進む中、多くの開発現場で「GitHub CopilotやChatGPTを導入したものの、結局自分で書いた方が早い」という声が上がるケースは珍しくありません。

システム受託開発や基幹システム構築の現場の観点から言えば、この原因の多くはAIモデルの能力不足ではなく、AIが「自社の固有コンテキスト」を把握していない点にあります。インターネット上の公開コードで学習した汎用的なAIモデルは、一般的なプログラミング言語の書き方には精通していても、長年継ぎ足されてきた独自の社内フレームワークや特殊な命名規則、複雑なデータベースのスキーマ構造までは理解していません。

現在、AIツールは急速な進化を遂げています。長い文脈理解やツール実行能力が大幅に向上したGPT-5.2が主力となり、GitHub CopilotもVS Codeにおいて全AI機能がCopilot Chat拡張へ一本化され、エージェントモードやCLI連携が強化されています。

これらの最新機能を費用対効果高く活用するには、単なる汎用的なコード補完から、AIに自社の文脈を的確に理解させるアプローチへの転換が求められます。現在の公式推奨ベストプラクティスとして重要なのが、カスタムインストラクション（.github/copilot-instructions.md）の設定です。ここにプロジェクト固有のコーディング規約やルールを記述することで、AIは自社の文脈に沿った精度の高い提案が可能になります。さらに、タスクの複雑さに応じて適切なモデルを選択し、詳細なコメントでコンテキストを提供することも不可欠です。

本記事では、汎用AIの限界を乗り越え、最新の機能群を活用しながら自社の技術資産に適応した開発環境を構築するための実践的なアプローチを解説します。現場の課題に即した現実的な環境構築のステップは、独自の技術資産を抱える開発組織にとって、これからのAI戦略における確かな羅針盤となるはずです。

なぜ「ChatGPT」だけでは自社の開発が変わらなかったのか

AIによるコード生成が普及し、コーディングに特化したモデルや、ドキュメントとコードを並べて編集できる機能なども登場しています。さらに開発支援ツールも、エディタ内でより高度な支援ができるよう進化を続けています。

しかし、独自の基幹システムや複雑な業務ロジックを持つ企業ほど、現場のエンジニアからは「期待したほどの費用対効果が得られない」という課題が聞こえてきます。ツールがどれほどシームレスになっても、自社の開発が劇的に変わらないメカニズムを現場目線で解き明かします。

汎用LLMが抱える「文脈理解」の限界

大規模言語モデル（LLM）は、どれほど性能が向上しても、基本的にはインターネット上のオープンソースコードや公開ドキュメントを元に、確率論的にコードを予測する仕組みで動いています。

一般的なWeb開発であれば、最新のAIは世界中の膨大な正解例から洗練されたコードを生成できます。しかし、基幹システム開発でよく見られる「過去に作られた独自のXML設定ファイルに依存し、それに基づいて動的にクラスが生成される複雑な仕組み」だったとしたらどうでしょうか。

汎用AIにとって、それは学習データに存在しない未知の言語です。文脈が共有されていないため、AIは一般的なベストプラクティスを返しますが、それは独自のレガシーシステムでは動かない異物でしかありません。これはモデルの知能の問題ではなく、「社内知識へのアクセス権」の問題なのです。

社内独自フレームワークが引き起こすAIの幻覚（ハルシネーション）

さらに厄介なのが、AIが自信満々に嘘をつくハルシネーションです。モデルの推論能力が向上した結果、より説得力のある嘘をつくケースも見られます。

例えば、独自の社内ライブラリを使うべき場面で、AIは標準的なライブラリや、存在しそうで存在しないメソッドを勝手に捏造して提案してきます。エディタ内のエージェント機能などでコードを自動修正させている最中に、存在しない引数を追加してくることも珍しくありません。

エンジニアはAIが書いたコードを見て喜びますが、コンパイルを通すとエラーが出ます。原因を調べると存在しないメソッドが使われていることに気づき、結局社内Wikiやマニュアルを読み直し、自分でコードを書き直すことになります。これでは、AIの生成したコードのデバッグという新たな業務が増え、かえって工数がかさむだけです。

現場エンジニアが「これなら手で書いた方が早い」と感じる瞬間

開発現場において最も貴重なリソースは、エンジニアの集中力（フロー状態）です。

AIツールを導入した目的は、定型コードの記述を自動化し、エンジニアが本質的なロジックに集中できるようにすることだったはずです。しかし、独自の文脈を理解していないAIとのやり取りでは、以下のようなプロセスが発生します。

• AIに背景情報を説明する長いプロンプトを書く
• 出力されたコードを自社のコーディング規約と照らし合わせる
• 規約に合っていない部分を見つけ、修正のために再度AIに指示するか手動で直す
• コンパイルエラーが出るため、原因を調査する

最新のツールを使ってエディタ内で完結できるようになっても、この「認識のズレを修正するプロセス」は無くなりません。このプロセスを経るくらいなら、最初から統合開発環境の補完機能を使って自分で書いた方が、思考の切り替えが発生せず結果的に早いのです。自社の開発文脈を知らない限り、AIは優秀だが話の通じない外部の新人と同じであり、これが現場でAIツールが定着しない真の理由です。

事例企業の挑戦：30年蓄積された「秘伝のコード」をAIに教える

ここからは、実務の現場で実際に直面する、レガシーシステムを抱える製造業の事例を基に解説します。長年運用されてきたシステムにおける課題は、多くのエンタープライズ企業に共通する切実なものです。

製造業におけるシステム環境：Java 6と独自XML定義の迷宮

創業50年を超えるような大手メーカーの生産管理システムでは、メインフレームからオープン系へ移行する過程で独自の進化を遂げた環境がよく見られます。

• 言語: Java 6（一部Java 8へ移行中だが、レガシーが現役）
• フレームワーク: Struts 1系をベースに、社内で独自拡張したフレームワーク
• 特徴: ビジネスロジックの多くが、数千行に及ぶ巨大なXML設定ファイルに記述されている

このような社内独自のフレームワークは、過去のアーキテクトによって設計されたものの、ドキュメントが古く更新されていないことが多々あります。正しい書き方を知るには、過去の似たような画面のソースコードをコピー＆ペーストして修正するしかないという現場は少なくありません。

プロジェクトの目的：単なる自動化ではなく「技術継承」

このような現場において、技術責任者が最も懸念するのは短期的な開発生産性ではなく、「技術継承の断絶」です。

独自フレームワークの仕様を完全に理解しているベテランエンジニアたちが定年退職を迎える一方で、新しく入ってくる若手エンジニアはモダンなWeb開発の知識はあっても、独自のレガシー環境には適応できません。

「Javaは書けますが、このXMLの意味がわかりません」
「なぜ標準のライブラリを使っていけないのですか？」

現場では毎日このような問答が繰り返され、ベテランの時間は若手の指導とコードレビューに奪われてしまいます。AI導入の真の目的は、コードを書かせること以上に、「社内に散らばる暗黙知をAIに学習させ、若手エンジニアのガイド役にする」ことにあるのです。

直面していた危機：ベテランの退職と属人化した保守業務

特定のエンジニアしかシステム障害に対応できないという属人化は、企業にとって時限爆弾のようなリスクです。

汎用的なAIツールを導入しても、独自フレームワークの作法を知らないAIは役に立たないばかりか、標準的な（しかし現場では動かない）コードを量産して混乱を招く恐れがあります。この課題を根本から解決するには、現場の文脈に特化した自社専用の頭脳を作るという現実的な決断が必要になります。

選択の岐路：RAG（検索拡張生成）かファインチューニングか

自社データをAIに適用させる手法として、主にRAG（Retrieval-Augmented Generation）とファインチューニングの2つのアプローチが議論になります。大規模なレガシーシステムを扱うプロジェクトでは、この技術選定が費用対効果を大きく左右します。

技術選定における比較検討プロセス

一般的には、導入ハードルの低いRAGから検討を始めます。RAGは社内ドキュメントやコードを検索し、その内容をプロンプトに含めてAIに回答させる手法です。

最新のトレンドでは、知識グラフを活用して情報の関係性を理解するGraphRAGや、図表やUI画像まで統合して検索するマルチモーダルRAGが登場しており、検索精度は飛躍的に向上しています。これにより、ドキュメント間のつながりや文脈を以前より深くAIに理解させることが可能になりました。しかし、独自のフレームワークや複雑な依存関係を持つレガシーコードにおいては、RAGだけでは解決しきれない課題が残ることがあります。

RAGアプローチでの限界：複雑な依存関係と「暗黙の流儀」

基幹システム開発の現場では、依存関係が極めて複雑になりがちです。例えば、ある画面のボタン処理を1つ実装するために、以下のような複数のファイルを整合性を保ちながら同時に記述する必要があります。

1. JavaのActionクラス（ビジネスロジック）
2. 画面定義のJSPファイル（フロントエンド）
3. バリデーション定義のXML（入力チェック）
4. DBマッピングのXML（データ永続化）

最新のLLMはコンテキストウィンドウが拡大しており、大量のコードを読み込ませることは技術的に可能です。しかし、ここで壁となるのが「ファイル間の暗黙の連携ルール」や「組織特有のコーディングスタイル」です。RAGはあくまで参照ですが、開発現場で求められるのは、組織の流儀を体得した振る舞いです。プロンプトに情報を詰め込んでも、熟練エンジニアのような阿吽の呼吸によるコード生成を再現するのは困難な場合があります。

ファインチューニングへの決断とコスト試算の現実

そこで、より踏み込んだ選択肢となるのがファインチューニングです。AIモデル自体のパラメータを調整し、組織独自のコードを母国語として学習させる手法です。

GPUリソースの確保や学習データの作成工数といった初期コストは発生しますが、投資対効果（ROI）を評価する際は、以下の観点を含めることが重要です。

• オンボーディング期間の短縮: 新人エンジニアが独自の規約を学ぶコストの削減
• 将来的なリプレイスコストの低減: ブラックボックス化した仕様をAIに学習させ、将来のマイグレーションを容易にする

システムがブラックボックス化したままでは、数年後の刷新時に現状調査だけで莫大なコストがかかるリスクがあります。AIに知識を移転しておくことは、将来のための生きたドキュメント整備と同等の価値があると言えます。

泥臭い「教師データ作成」こそが成功の鍵だった

プロジェクトにおいて最も工数を要するのは、モデルの学習でもパラメータ調整でもなく、データのクレンジングです。システム受託開発の現場においても言えることですが、質の低いデータからは質の低い結果しか生まれません。

ゴミデータからはゴミしか生まれない：コードクレンジングの苦闘

長年運用されているリポジトリには、過去のコードが大量に蓄積されています。しかし、それをそのままAIに読ませることはできません。

• コメントアウトされた大量の廃止コード
• 「テスト用」「一時対応」と書かれた場当たり的な修正
• ハードコーディングされたパスワードやIPアドレス
• コピー＆ペーストで増殖した重複コード

これらをそのまま学習させれば、AIは誤った流儀を自社の標準だと誤学習してしまいます。また、バグを含んだコードを学習すれば、AIはバグを量産するマシンになってしまいます。

「悪いコード」をAIに学ばせないためのフィルタリング戦略

現場主義のアプローチとしては、学習させるべき正解データの選定基準を厳格に設けることが不可欠です。

1. 静的解析ツール（Linter）を通す: 構文エラーや明らかな規約違反があるコードは自動的に除外。
2. セキュリティスキャン: パスワードや個人情報が含まれるファイルを検出し、無効化または除外。
3. 重複排除: 似通ったコードを間引き、学習効率を高める。
4. 「ゴールドデータ」の選定: ベテランエンジニアが模範的だと認める高品質なコード群を別途タグ付けし、学習時の重み付けを高く設定。

特に4番目が重要です。過去の負債も含めてすべてを学ぶのではなく、これからの組織が目指すべきコードだけを重点的に教え込む必要があります。

ベテランエンジニアの暗黙知をデータ化するプロセス

さらに、コードだけでは伝わらない意図を補完するため、主要なフレームワークのコードに対して、ベテランエンジニアに解説コメント（DocString）を追記してもらうプロセスも有効です。

なぜここでこのAPIを呼ぶのか、このXMLパラメータはデータベースのどのカラムと紐付いているのかといった暗黙知を言語化します。通常業務で忙しいエンジニアにとって骨の折れる作業ですが、これが終われば新人の質問攻めから解放されるというメリットを共有し、高品質なデータセットを構築します。この泥臭い作業こそが、後の高い精度の源泉となります。

検証結果：コード生成率70%達成と意外な副次的効果

適切な準備期間と学習を経て構築された自社専用のコード生成AIモデルを、VS Codeの拡張機能として現場に導入した結果、実務においてどのような変化が起きるのかを解説します。

定量的成果：ボイラープレート記述時間の9割削減

独自フレームワークにおける定型的なCRUD（登録・参照・更新・削除）処理の実装において、AIが生成したコードの約70%がそのまま、あるいは軽微な修正で動作するようになります。

以前は過去のコードを探し出し、コピーして変数名を置換するといった手作業に時間を要していましたが、自然言語の指示だけで瞬時に雛形が出力されるようになります。特に複雑なXML設定ファイルの記述に関しては、人為的なミスが減り、構文エラーによる手戻りが激減するという明確な費用対効果が現れます。

定性的変化：若手エンジニアのオンボーディング期間半減

数値以上の成果として現場で評価されるのが、若手エンジニアの教育効果です。

これまで若手はコードを書くたびにベテランに確認していましたが、専用AIを導入してからは、まずAIにコードを書かせ、それをベースに修正するフローへと移行します。AIが提案するコードはベテランが選定したゴールドデータに基づいているため、AIが書くコード自体が生きた教科書となり、若手はコード生成を通じて自社の正しいコーディング規約を自然と学ぶようになります。

「AIが社内規約を教えてくれる」という新たな教育効果

現場の若手エンジニアからは、「以前は自己流で書いて指摘を受けることがありましたが、今はAIが自社フレームワークの一般的な書き方を教えてくれるため、メンターが常に隣にいるような安心感がある」といった声が上がります。

AIは単なる自動化ツールを超えて、組織の知識を標準化し、効率的に伝達するためのメディアとして機能し始めるのです。

結論：自社専用AIを持つことが企業の競争力になる

汎用的なAIモデルは、いわば優秀な外部のエンジニアです。一般的な技術力は高くても、各企業の内部事情までは把握していません。

対して、ドメイン適応（ファインチューニング）やRAGでカスタマイズを行ったAIは、自社のシステムの癖や歴史、独自のビジネスロジックを深く理解したベテラン社員の分身となります。

「借り物の知能」から「自社の知能」への転換

今後、AIを活用する企業としない企業の格差は広がりますが、さらにその先には「汎用AIを使う企業」と「自社専用AIを持つ企業」の格差が明確になるでしょう。

自社の技術資産、独自データ、ノウハウをAIという形に蒸留し、再利用可能な資産に変えることこそが、デジタルトランスフォーメーションの本質的なゴールの一つです。開発ツールが高度な文脈理解を備えつつある現在、自社独自の知識をAIに連携させる価値はかつてなく高まっています。

これから取り組む企業への3つのアドバイス

独自のシステム環境を持ち、AI導入を検討している企業は、以下の現実的なステップから始めることを推奨します。

1. データの棚卸し: AIに学習させられる高品質なコードや仕様書がどれくらい存在するかを把握する。
2. スモールスタート: 全システムではなく、特定のサブシステムに絞って概念実証（PoC）を行い、限定的なスコープで費用対効果を測定する。
3. 目的の再定義: 短期的な工数削減だけでなく、技術継承や教育といった中長期的な観点で投資対効果を評価する。

小さく始めて大きく育てるドメイン適応のロードマップ

いきなり大規模な学習を行う必要はありません。まずはRAGを利用して社内ドキュメントの検索を強化し、次に小規模なモデルで特定のタスクを学習させるアプローチが、リスクを抑えつつ効果を最大化する現実的な手法です。また、エディタに統合されたAIコーディングアシスタントに自社のコードベースを読み込ませるだけでも、大きな効率化が見込めます。

レガシー資産を負債ではなく強力な武器に変えるため、コードの中に眠る知見を発掘し、本格的なAI資産化に向けた第一歩を踏み出すことをおすすめします。