社内独自リポジトリを用いた IBM watsonx Code Assistant のファインチューニング：エンタープライズ実践ガイド

大企業のエンジニアリング組織が生成 AI コードアシスタントを本格導入する際、共通して直面する深刻な壁があります。Spring Boot、React、Pandas といったパブリックなオープンソースエコシステムには極めて精通している一般的な商用 AI モデルが、社内独自のプライベート SDK、内製メッセージングミドルウェア、企業固有のアノテーション、独自の業務ドメイン言語（DSL）の前では完全に破綻してしまうという問題です。

汎用モデルは、存在しないメソッドシグネチャを捏造したり、すでに非推奨となったパブリックライブラリを提案したり、企業内のアーキテクチャ規範に反するコードを生成しがちです。

IBM watsonx Code Assistant は、オープンで透明性の高い基盤モデルファミリーである IBM Granite Code をベースに、パラメータ効率的な微調（PEFT/LoRA）、プロンプトチューニング、そしてリアルタイムな IDE ワークスペース検索を組み合わせることで、この課題を解決します。社内の機密コードや知的財産（IP）を隔離・保護しながら、独自フレームワークに特化した高精度なコード補完・生成環境を構築できます。

本稿では、社内リポジトリを活用した watsonx Code Assistant のファインチューニングと本番運用の全プロセスを、データパイプライン、学習設定、検証基準、IDE 連携まで詳細に解説します。

課題の本質：なぜ汎用コードアシスタントは社内フレームワークで破綻するのか？

パブリックな AI コードアシスタントは、公開された GitHub などのオープンソースコードを学習しています。しかし、エンタープライズの基盤は社内専用資産の上に成り立っています。

• 独自フレームワークと非公開 SDK：com.enterprise.platform.* や社内認証クライアントなど、コアライブラリは外部に一切公開されていません。
• 組織固有のアーキテクチャ制約：分散トレーシング、監査ログ用カスタムアノテーション、ゼロトラスト認証手順など、企業独自の開発規約が存在します。
• 知的財産（IP）保護とデータ主権の壁：金融、製造、医療などの重要インフラ企業において、機密コードを外部のマルチテナント型 AI モデルの学習データとして流出させることは固く禁じられています。

IBM watsonx Code Assistant は、「パラメータ適応」と「動的検索」を統合したハイブリッドアーキテクチャでこれに応えます。

1. パラメータ知識の獲得（Granite モデルのファインチューニング）：軽量で高速な Granite Code モデル（8B/20B）の重みを微調整することで、社内 API の呼び出し規則やイディオムをモデル自体に内生化させます。
2. 動的コンテキストの注入（ワークスペースグラウンディング）：VS Code や Eclipse の拡張機能を通じて、作業中のファイル、型定義、ローカルスキーマをリアルタイムにプロンプトへ補完します。
3. 物理的テナント分離：すべての学習および推論は、組織専用の watsonx テナントまたはオンプレミスの Red Hat OpenShift 上で実行され、顧客データが IBM のグローバルモデルに再学習されることはありません。

エンドツーエンド実装フロー：私有コード微調の 6 ステップ

エンタープライズ環境におけるファインチューニングは、単にリポジトリをそのまま投入する作業ではありません。厳格なデータ前処理と評価プロセスが必須です。

+-----------------------------------------------------------------------------------+
| 1. ゴールデンリポジトリ選定とデータ前処理（Data Prep Kit、AST 解析、シークレット除外） |
+-----------------------------------------+-----------------------------------------+
                                          |
+-----------------------------------------v-----------------------------------------+
| 2. データセット合成と多目的フォーマット化（FIM 補全 + JSONL 指示対）              |
+-----------------------------------------+-----------------------------------------+
                                          |
+-----------------------------------------v-----------------------------------------+
| 3. モデル適応学習（OpenShift AI / RHEL AI 環境での Granite LoRA 微調）            |
+-----------------------------------------+-----------------------------------------+
                                          |
+-----------------------------------------v-----------------------------------------+
| 4. オフライン多層評価と文法・ビルド検証（AST 構文解析、社内 Pass@k ベンチマーク）  |
+-----------------------------------------+-----------------------------------------+
                                          |
+-----------------------------------------v-----------------------------------------+
| 5. 推論エンドポイント配備とテナントマッピング（vLLM 稼働端点 -> watsonx ゲートウェイ）|
+-----------------------------------------+-----------------------------------------+
                                          |
+-----------------------------------------v-----------------------------------------+
| 6. IDE 展開とワークスペースグラウンディング連携（.wca 設定、ローカルシンボル検索） |
+-----------------------------------------------------------------------------------+

ステップ 1：ゴールデンリポジトリの選定とサニタイズ

巨大なモノレポ全体を無選別で学習データに投入すると、レガシーな負債やアンチパターン、非推奨 API（v1 など）が混入し、生成品質を著しく低下させます。

選定すべき「ゴールデンリポジトリ」：

• 社内共通 SDK・クライアントライブラリ：公式に保守されており、テストコードとJavadoc/ドキュメントが完備されたソースコード。
• アーキテクチャ標準となる参照マイクロサービス（Blueprint）：アーキテクチャ委員会が承認した規範的な本番マイクロサービス。
• 公式テンプレート・スターターキット：新規プロジェクト開始時に推奨される雛形。

データサニタイズパイプライン

オープンソースの IBM Data Prep Kit（DPK） や構文解析ツールを用いてコードを洗浄します。

1. 認証情報・機密データの完全除去：API キー、JWT トークン、社内限定ホスト名、内部 IP アドレス、データベース接続文字列を正規表現および AST パターンで自動マスキングします。
2. 依存関係のライセンスチェック：社内リポジトリ内に埋め込まれたサードパーティ OSS のライセンス汚染がないか検証します。
3. ノイズの排除：ビルド成果物（target/、node_modules/）、自動生成された Protobuf/gRPC スタブ、重複コードを削除します。

ステップ 2：学習データセットの構造化（FIM と指示対）

コードアシスタントには、「タイピング中のインライン補完（Autocomplete）」と「チャットでの対話的なコード生成・リファクタリング」という 2 つの役割があります。データセットもこれに対応して 2 種類作成します。

1. インライン自動補完向け：FIM（Fill-In-The-Middle）形式

編集中ファイルの途中にコードを差し込むタスクを学習させるため、プレフィックス、サフィックス、ミドルの特殊トークンで整形します。

<fim_prefix>// 社内注文ディスパッチサービス実装
package com.enterprise.order.service;

import com.enterprise.common.security.AuditLog;
import com.enterprise.platform.messaging.EventProducer;

public class OrderDispatchService {
    private final EventProducer producer;

    public void dispatch(OrderEvent event) {
        <fim_suffix>
    }
}<fim_middle>@AuditLog(action = "DISPATCH_ORDER", severity = Severity.HIGH)
        producer.sendTransactional("order-events", event.getId(), event);

2. 対話型支援・ボイラープレート生成向け：JSONL 指示対形式

社内フレームワークの書き方や単体テスト作成を支援するための対話データです。

{
  "messages": [
    {
      "role": "user",
      "content": "社内 CorpEventBus を使用して 'account-updates' トピックを受信する非同期リスナーを作成してください。リトライ上限は3回、デッドレターキューを指定してください。"
    },
    {
      "role": "assistant",
      "content": "@CorpEventHandler(topic = \"account-updates\", autoAck = false)\npublic class AccountUpdateListener implements EventConsumer<AccountPayload> {\n    @Override\n    @RetryPolicy(maxAttempts = 3, backoffMs = 1000, dlqTopic = \"account-updates.dlq\")\n    public void onMessage(ConsumerRecord<AccountPayload> record) {\n        // 社内イベント処理ロジック\n    }\n}"
    }
  ]
}

ステップ 3：モデル適応の実行（LoRA 微調の推奨設定）

IBM エコシステムにおける主なカスタマイズ手法の比較は以下の通りです。

Granite-8B-Code に対する LoRA チューニング構成

実運用において、IBM Granite-8B-Code は推論レイテンシ（初回トークン生成 <150ms）と推論精度のバランスが最も優れています。

Red Hat OpenShift AI 上での代表的な構成例：

• ベースモデル：ibm-granite/granite-8b-code-instruct
• LoRA 設定：
  • ランク（$r$）：16 または 32
  • アルファ（$\alpha$）：32 または 64
  • 対象モジュール：q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
  • ドロップアウト：0.05
• 学習ハイパーパラメータ：
  • 学習率：1e-4（Cosine スケジューラ、5% ウォームアップ）
  • シーケンス長：4096 トークン
  • エポック数：3〜5 エポック（過学習防止のため検証ロスを監視）
  • 精度：bfloat16

# Granite Code 向け PEFT LoRA 設定例
from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM

base_model = AutoModelForCausalLM.from_pretrained(
    "ibm-granite/granite-8b-code-instruct",
    torch_dtype="auto",
    device_map="auto"
)

lora_config = LoraConfig(
    r=32,
    lora_alpha=64,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)

custom_model = get_peft_model(base_model, lora_config)
custom_model.print_trainable_parameters()
# 学習対象パラメータはモデル全体の 0.5% 未満に抑えられます

ステップ 4：オフライン多層評価と構文・ビルド検証

BLEU や ROUGE といった自然言語指標は、コード生成の品質評価には役立ちません。セミコロンが1つ欠けたり型が食い違うだけでビルドは失敗します。

以下の 4 つの検証ゲートを設けます。

1. AST 構文解析整合率：Tree-sitter や JavaParser などの構文解析器を通し、構文エラーやコードの途切れがないか検証します。
2. 社内アーティファクトを用いたビルド検証：生成されたコードを社内 Nexus/Artifactory に接続された検証用コンテナ内でコンパイルし、クラス名やシグネチャが合致するか確認します。
3. 社内専用 Pass@k ベンチマーク：社内の典型的な開発タスク 100〜200 件からなるテストスイートを作成し、自動テストの合格率を計測します。
4. セキュリティスキャン：SAST ツールおよび watsonx.governance により、非推奨の暗号化方式や脆弱な構文が出力されていないか検査します。

ステップ 5：推論基盤の展開とゲートウェイ連携

検証に合格したモデルを本番環境へ配置します。

1. モデルレジストリ登録：学習済み LoRA アダプタを社内の watsonx Model Registry に登録します。
2. 高速推論サービング：vLLM や IBM TGIS を用いて Red Hat OpenShift AI 上に推論エンドポイントをデプロイし、Continuous Batching を有効化して高速応答を確保します。
3. テナントマッピング：watsonx Code Assistant の管理コンソールで、対象エンジニア組織の推論先を自前のカスタムモデルエンドポイントに割り当てます。

ステップ 6：IDE 展開とワークスペースグラウンディングの統合

モデルの重み学習だけでは、昨日リリースされたばかりの新機能に対応できません。ファインチューニングされた Granite モデルに、IDE レベルの動的検索（Workspace Grounding） を組み合わせます。

+--------------------------------------------------------------------------+
| 開発者 IDE 環境（VS Code / Eclipse）                                     |
|                                                                          |
|  1. カーソルトリガー（入力中の自動補完またはチャット要求）                |
|  2. ワークスペース走査（.wca 設定による制約、AST シンボル抽出）          |
|  3. コンテキスト注入（同一ファイル定義、近傍の型宣言、DTO スキーマ）     |
+------------------------------------+-------------------------------------+
                                     |
                                     v
+--------------------------------------------------------------------------+
| 企業ネットワーク境界（mTLS 認証 / 企業 SSO 連携）                        |
|                                                                          |
|  watsonx Code Assistant API ゲートウェイ -> 独自推論エンドポイント       |
|  （固定 Granite 8B 基盤 + 社内 LoRA アダプタ + 動的注入コンテキスト）   |
+--------------------------------------------------------------------------+

1. 社内専用 IDE 拡張機能の配布：社内ポータル経由で watsonx Code Assistant 拡張機能を一括導入します。
2. リポジトリ定義（.wca/config.json）：各プロジェクトルートに設定ファイルを配置し、コーディング規約や推奨ライブラリを宣言します。
3. アクティブコンテキストの自動付与：エディタで開いているタブの型情報や import 文を動的にプロンプトへ追加し、微調モデルの推論を補強します。

手法比較マトリクス：最適なカスタマイズ手法の選択

知的財産（IP）の保護とエンタープライズガバナンス

社内コード資産を AI に学習させる際、watsonx は強力な法的・技術的保護を提供します。

1. データ非学習保証とテナント隔離：顧客が投入したソースコード、学習データ、生成された LoRA アダプタは自社専用環境内に完全に隔離されます。IBM がこれらを汎用モデルの学習に利用することは契約上ありません。
2. 厳格なアクセス制御（RBAC）：学習パイプラインや推論エンドポイントへのアクセスは企業の SSO（SAML/OAuth）と統合され、完全な監査ログが保持されます。
3. IBM Granite の IP 免責補償：IBM は Granite モデルファミリーに対して知的財産権の侵害補償（IP Indemnification）を提供しており、法的な著作権侵害リスクから企業を保護します。

継続的 MLOps：モデルの陳腐化を防ぐライフサイクル管理

1. 採択率（Acceptance Rate）の監視：watsonx 管理ダッシュボードで開発者のコード補完採用率を継続計測します（健全な目標値：32〜38% 以上）。
2. SDK メジャーバージョンアップ時の自動再学習：内部共通ライブラリが v2 から v3 にバージョンアップした際、CI/CD からパイプラインを自動起動して LoRA アダプタを更新します。
3. InstructLab による初期データの補完：既存コードがまだ少ない新規ライブラリの場合、API 仕様ドキュメントから InstructLab で合成指示データを自動生成し、先行学習させます。

結論と推奨アプローチ

汎用 AI コードアシスタントをそのまま社内システムに適用しても、ビルドエラーや存在しない API の提案が多発し、開発現場に失望を招くだけです。

最も費用対効果が高く確実な構成は、IBM Granite-8B-Code に対する LoRA 微調と IDE ワークスペース検索の併用 です。ミリ秒単位の高速レスポンス、社内独自 SDK への完璧な適応、そして鉄壁の知的財産隔離を同時に満たすことで、生成 AI を企業の真のエンジニアリング武器へと昇華させることができます。

参考資料

• IBM watsonx Code Assistant | IBM Cloud Docs
• AI coding agent | IBM
• GitHub - ibm-granite/granite-code-models: Granite Code Models: A Family of Open Foundation Models for Code Intelligence · GitHub
• GitHub - data-prep-kit/data-prep-kit: Open source project for data preparation for GenAI applications · GitHub
• GitHub - instructlab/instructlab: InstructLab Core package. Use this to chat with a model and execute the InstructLab workflow to train a model using custom taxonomy data. · GitHub
• GitHub - ibm-granite-community/granite-snack-cookbook: Granite Snack Cookbook -- easily consumable recipes (python notebooks) that showcase the capabilities of the Granite models · GitHub