GitHub Copilot とローカル LLM で AI コーディング支援環境を構築する

GitHub Copilot Dev Days 2026 at Osaka GitHub CopilotとローカルLLMで AI コーディング 支援環境を構築する 2026/10/31 NTTデータ先端技術株式会社 経営企画部 Microsoft技術センター 原田 幸太郎 © 2026 NTT DATA INTELLILINK Corporation

01 自己紹介 © 2026 NTT DATA INTELLILINK Corporation 2

はじめに 私の属性は インフラエンジニア です。 インフラエンジニアとは： インフラエンジニアは、ITインフラの設計、構築、運用を担当する専門家です。彼らはサーバー、 ネットワーク、ストレージなどの基盤技術を管理し、システムの安定性と効率性を確保します。開 発系エンジニアがアプリケーションのコードを書くのに対し、インフラエンジニアはそのコードが動作する 環境を整備し、最適化します。 異属性の方々にはピンとこない話になることも多々あると思いますが、 暖かくご視聴いただけますと幸いです。 © 2026 NTT DATA INTELLILINK Corporation 3

自己紹介 Azure: まあまあいける Microsoft 365: 普通 Power Platform: 多少 © 2026 NTT DATA INTELLILINK Corporation 氏名 原田 幸太郎 生年月日 1976年3月8日(50歳) 出身地 愛知県北名古屋市 所属 株式会社NTTデータ先端技術 職歴 アプリケーション開発エンジニア：5年 パッケージフィールドエンジニア：3年 パッケージ開発エンジニア：2年 インフラエンジニア：16年 趣味 クラフトビール・旅行・テニス 4

認定資格 © 2026 NTT DATA INTELLILINK Corporation 5

02 背景とゴール © 2026 NTT DATA INTELLILINK Corporation 6

背景とゴール 背景 • 外部の生成 AI サービスは原則利用不可のお客様 • レガシーなアプリで有識者もおらず AI コーディング支援を活用して品質を担保したい • 高性能な環境を用意するような金はない ゴール 外に出せない、お金もかけられない。 だったら手元の PC で動くローカル LLM で AI コーディング支援を回して、レガ シーアプリの品質を守れるようにしよう。 © 2026 NTT DATA INTELLILINK Corporation 7

03 これまでの道のり © 2026 NTT DATA INTELLILINK Corporation 8

① Bonsai-8B セットアップ（2026/04） https://qiita.com/koutaro_harada/items/d45e346f099af9b9a9c8 記事の要約 • 背景：クラウド生成AIが使えない環境向けに、ローカルLLMでVSCodeからAIコーディング支援を使える環境を 構築（連載第1回） • Bonsai-8B は一般的なLLMランタイム未対応のため、カスタム llama-server 同梱のコンテナーイメージ （GPU/CPU両対応）をビルド • モデル（GGUF）をマウントしてコンテナーを起動し、OpenAI互換APIとして公開 • VSCode拡張 Continue の config.yaml に登録し、チャット応答とGPU使用率の上昇を確認 • 課題：VSCode標準チャットではモデルが選択肢に表示されず、カスタム構成ゆえの制約の可能性 © 2026 NTT DATA INTELLILINK Corporation 9

• https://qiita.com/koutaro_harada/items/d45e346f099af9b9a9c8

② Foundry Local セットアップ（2026/04） https://qiita.com/koutaro_harada/items/e3326d9eb5879d777d6e 記事の要約 • 目的：Bonsai-8B の比較対象として、GAされた Foundry Local でローカルLLM環境を構築（連載第2 回） • winget で導入でき、foundry model run でモデルのインストールと起動を同時に実行（Ollama に近い操作 感） • 起動ごとに変わるポートを foundry service set --port で固定し、Continue から OpenAI互換API として接続 • Qwen2.5-coder 1.5b / 7b を Continue から動作確認し、GPU使用も確認 • 課題：VSCode標準チャットではインストール済みモデルを認識できず断念（既知の不具合の可能性） © 2026 NTT DATA INTELLILINK Corporation 10

• https://qiita.com/koutaro_harada/items/e3326d9eb5879d777d6e

③ ベンチマーク準備＆熱暴走対策（2026/04） https://qiita.com/koutaro_harada/items/e4153ee850f04f1b52e6 記事の要約 • モデル比較の準備として EvalPlus（HumanEval 等）を導入し、WSL2 上から OpenAI互換API 経由で実 行（連載第3回） • モバイルワークステーション（T500 / VRAM 4GB）でベンチマーク中、GPU温度が85°Cを超えるとPCが強制 シャットダウン • 対処：nvidia-smi -lgc 500 でGPUクロックを制限し、温度は約75°Cで安定。性能は落ちるが完走を優先 • 再実行しやすいようベンチマークをスクリプト化。WSLから Foundry Local へ接続するには Windows 側のポー トプロキシが必要 • 学び：ノートPCではピーク性能より安定して完走できる構成を優先し、温度・電力制御も検証環境の一部とし て最初から考える © 2026 NTT DATA INTELLILINK Corporation 11

• https://qiita.com/koutaro_harada/items/e4153ee850f04f1b52e6

④ ベンチマーク結果（2026/05） https://qiita.com/koutaro_harada/items/0722bb9b3d88695da7b3 記事の要約 • Bonsai-8B を Qwen2.5-Coder（7B/3B/1.5B）、Qwen2.5-7B、Mistral-7B と比較（EvalPlus・ LMEval）。環境依存が強く、優劣を示すものではない参考値（連載第4回） • 実行環境（モバイルWS / Azure VM）が違ってもスコア差は0.012以内で、モデル差が支配的 • Qwen2.5-Coder-3B は Bonsai-8B より小さいのに EvalPlus で上回り（base 0.829 vs 0.756）、実行時 間も半分以下。コード支援ならコード特化モデルが合理的 • LMEval：gsm8k は Bonsai-8B 0.755 / Qwen2.5-7B 0.775 で同水準。ifeval（inst strict）は 0.387 vs 0.761 と差があるが、公式評価（0.798）とは乖離 • 未解決：モバイルWSでの実行時間（1:34:19）と Azure VM での VRAM 使用量（10,661MB）が突出 © 2026 NTT DATA INTELLILINK Corporation 12

• https://qiita.com/koutaro_harada/items/0722bb9b3d88695da7b3

⑤ ボトルネック解析（2026/06） https://qiita.com/koutaro_harada/items/f4c1984526cda5409d9e 記事の要約 • 第4回の未解決2点（T500での実行時間／Azure VMのVRAM使用量）の原因を分析（連載第5回） • 実行時間：全37層がGPUに載りCPUオフロードはなし。T500とT4のメモリ帯域差（約4倍）に熱対策のク ロック制限が上乗せされ、約6倍差（1:34:19 vs 0:15:43） • プロファイリング（Nsight）：重み計算が推論時間の8割超。超低ビット圧縮の展開処理が独自実装で未成 熟なため、読み出し量が少なくても処理効率は約2.7倍非効率 • VRAM：コンテキスト未指定で65,536トークン分のKVキャッシュ（9,216MiB）を確保。 CONTEXT_SIZE=4096 で 10,661MB→2,021MB、スコアはほぼ同等 • 知見：llama.cpp を直接使う場合はコンテキストサイズを明示的に指定する © 2026 NTT DATA INTELLILINK Corporation 13

• https://qiita.com/koutaro_harada/items/f4c1984526cda5409d9e

⑥ 続 Foundry Local セットアップ（2026/07） https://qiita.com/koutaro_harada/items/eaa20d6b64457bf7476f 記事の要約 • 第2回で頓挫した Foundry Local の VSCode 組み込みに再挑戦（T500 / VRAM 4GB、Qwen2.5coder:1.5b、連載第6回） • インストール・起動・モデル取得・ヘルスチェック・推論テストの流れをスクリプト化 • VSCode のチャットにカスタムエンドポイントとして追加するとモデルは認識されたが、応答が返らずGPU使用が 高止まり • GitHub Copilot CLI で調査：既定ではシステムプロンプト・ツール・MCPで 13k/33k トークン（39%）を消費。 組み込みMCP無効化とツール限定で 3k（8%）に削減し、応答が返るように • 学び：ローカルLLMではコンテキストが実行コストそのもの。「動かすためのコンテキスト設計」が重要 © 2026 NTT DATA INTELLILINK Corporation 14

• https://qiita.com/koutaro_harada/items/eaa20d6b64457bf7476f

⑦ Hugging Face モデル導入（2026/09） https://qiita.com/koutaro_harada/items/f8ff9a1cdc34f89cc2ed 記事の要約 • Hugging Face のモデル（Qwen2.5-Coder-3B）を ONNX にコンパイルして Foundry Local で動かす （RTX 4060 / 8GB 端末で作業、T500 で確認、連載第7回） • olive-ai でコンパイル。onnxruntime-genai-cuda を 0.15.2 に固定し、olive のモジュールに2点のパッチを適 用、config.json も調整して実行 • GitHub Copilot CLI で記号の反復しか返らない問題は、Foundry Local が frequency_penalty を扱えない ことが原因。プロキシで同パラメーターを除去して回避 • 結果：正常な日本語応答を確認。T500 の端末でも遅いながら動作 • 学び：バージョン互換性を侮らない／いざとなればコードで対処（HTTPならプロキシが効く）／Windows 環 境依存はある © 2026 NTT DATA INTELLILINK Corporation 15

• https://qiita.com/koutaro_harada/items/f8ff9a1cdc34f89cc2ed

04 中間まとめ © 2026 NTT DATA INTELLILINK Corporation 16

現時点の構成 クライアント プロキシ GitHub Copilot CLI 自作プロキシ VS Code Chat frequency_penalty 除去 モデル 推論ランタイム Qwen2.5-Coder-3B Foundry Local 自作 ONNX int8 実行端末 開発端末 確認端末 RTX 4060 (VRAM 8GB) T500 (VRAM 4GB) © 2026 NTT DATA INTELLILINK Corporation 17

ここまでで分かったこと • モデル：コーディング用途なら、パラメーター規模よりコード特化が効く • ハード：ノート PC では、ピーク性能より完走できる構成（熱・クロック）を優先する • 設定：llama.cpp ではコンテキストサイズを明示しないと VRAM を浪費する • 量子化：超低ビットでも、展開処理が未成熟なら遅くなる • GitHub Copilot：システムコンテキストそのものが実行コストになる → 最小構成から始める • Foundry Local：導入は手軽だが、まだ成熟しきっていない（カタログ外モデルはバージョン固定とパッチが必 要、frequency_penalty で出力異常） • 連携：AI アプリも I/F は HTTP → プロキシで力技が効く © 2026 NTT DATA INTELLILINK Corporation 18

05 追加検証 © 2026 NTT DATA INTELLILINK Corporation 19

01 EXECUTIVE SUMMARY Qwen2.5-Coder-3B コードレビュー検証 外部の生成AIを使えない案件向けに、ローカルLLMでコードレビュー補助ができるかを検証。 Foundry Local上のQwen2.5-Coder-3Bで、入力範囲・API／CLI・プロキシ設定を変えて品質と実行可否を確認。 設定調整による改善余地を確認。 CLIコンテキストの寄与は、まだ未分離。 改善の兆候 残る品質課題 評価の限界 対象関数に絞ると正答が増加。 CLI＋プロキシでも誤記を検出。 正常なSQLも不具合と誤判定。 自由形式のレビューは不安定。 少数ケース・条件差が残る。 一般的な優位性は未確認。 現時点の用途：人が根拠を確認するレビュー補助。自動的な品質判定には未到達。 用語：CLIコンテキスト＝GitHub Copilot CLIが付加する指示・ツール定義。プロキシ＝CLIとローカルLLMの間の自作中継。 © 2026 NTT DATA INTELLILINK Corporation

02 METHOD 評価軸を分けて、品質と実行可否を比較 CLIが付加する指示・ツールの影響を含め、3つの評価系で品質と実行可否を切り分けた。 「全文／関数のみ」は入力コードの範囲。CLI通常モード／軽量モードの区分ではない。 評価系 入力・設定 評価対象 API直接呼出し 全文／対象関数 × クラウド／ローカル 履歴・ツールなし、temperature=0 正常・異常4ケース × 各2回 合計32回、出力上限384トークン CLI固有の指示とツール定義あり シェル・書込は拒否、コードを本文に投入 誤記1ケース × 入力2条件 直接接続とプロキシ経由を確認 -CliMode：全メッセージ・ツールを保持 frequency_penalty のみ削除 ローカルへ転送、CLI上限180秒 回答とメッセージの役割・文字数を記録 CLIを介さない基準条件 実CLI・軽量設定 GitHub Copilot CLIを使用 プロキシ互換設定 CLI→ローカルLLM間の中継 対象：戻り値の識別子誤記／顧客名のアポストロフィとSQL。各々に修正済みの対照コードを用意。 制約：クラウドとローカルの量子化・チャットテンプレートは未統一。CLIの生成設定もAPIと完全同一ではない。 © 2026 NTT DATA INTELLILINK Corporation

03 API RESULTS 対象を絞ると、ローカル版で正答が増加 正常コードと誤記入りコードを渡し、不具合の有無と理由をモデルに答えさせた（正常・異常4ケース×各2回＝各条件8回）。 API直接呼出し（CLIを介さない）。棒は判定の正答数、右列は理由付きの有効な正答数。 条件 判定正答数（最大8） 理由付き正答 クラウド / 全文 4/8 2/8 クラウド / 関数のみ 4/8 4/8 ローカル / 全文 4/8 4/8 ローカル / 関数のみ 6/8 6/8 注意：パラメーター化済みSQLは全条件で2回とも誤検出。 クラウド全文は理由が空の回答が4件。入力限定の改善は兆候であり、一般的な精度向上の証明ではない。 © 2026 NTT DATA INTELLILINK Corporation

04 CLI AND PROXY CLI＋プロキシでは、誤記の検出に成功 GitHub Copilot CLIから自作プロキシ経由でローカルLLMを呼び出し、誤記入りコード（1ケース）をレビューさせた。 CLIの追加コンテキストを保持したまま完了。ただし、直接APIとの因果比較ではない。 実行条件 全文 関数のみ ローカル・直接接続 45秒でタイムアウト 45秒でタイムアウト クラウド・直接接続 ツール設定によりHTTP 400 ツール設定によりHTTP 400 ローカル・CLI互換プロキシ 誤記を検出 / 7.2 秒 誤記を検出 / 6.1 秒 GetSalesTotal ≠ GetSalesTotl 回答は、関数名と代入先の識別子の違いを正しく指摘。 上限を180秒へ延長したが、両方とも45秒以内で完了。延長だけの効果とは判断できない。 成功は誤記1ケース・各1回。自由形式のレビュー精度や、ファイル読込ツールの実行成功は未確認。 © 2026 NTT DATA INTELLILINK Corporation

05 TUNING ASSESSMENT 品質改善の可能性と、まだ言えないこと スライド21〜22の結果から、どの調整が品質改善に効いたと言えるかを整理。 入力・指示・通信互換性を分けて評価し、成功要因を一つに決めつけない。 調整対象 評価 根拠と限界 入力範囲・タスク分割 有望 関数限定で改善の兆候。サイズ自体の効果は未分離。 CLIの追加コンテキスト 仮説 指示・ツールを保持して正答。CLI単独の寄与は未分離。 プロキシの互換性調整 完了を確認 CLI応答に成功。penalty削除・ウォームアップ等は未分離。 手順・出力形式の指定 限定的 形式は改善。誤抽出・比較誤り・誤検出は残った。 few-shot／重みの調整 未検証 今回未実施。改善幅や再現性は評価できない。 報告上の表現：CLIが付加するコンテキストが有効に働いた可能性はある。 ただし、プロキシ調整や生成設定など、他条件の影響とは分離できていない。 © 2026 NTT DATA INTELLILINK Corporation

06 NEXT STEPS 次の検証は、追加コンテキストの寄与を分離 スライド23で分離できなかった要因を、次の検証で一つずつ切り分ける。 再現可能な基準構成を固定し、未見の正常・異常コードで比較する。 01 CLIリクエストを基準化 CLIが実際に送るリクエストを機微情報を除いて取得し、APIへ同条件で再送。モデル・生成設定・プロキシを固定。 02 指示・ツール定義を一要素ずつ変更 どの要素が効くかを特定するため、CLIのシステム指示とツール定義の有無を比較。削除時は関連するtool_choiceも整合させ る。 03 正常コードへの誤検出まで評価 異なる問題を増やし、学習用の例と評価用を分離。正答率・誤検出率・完了率・時間を記録。 推奨：レビュー補助として検証継続。自動判定への採用は、誤検出を含む評価基準を定めてから。 © 2026 NTT DATA INTELLILINK Corporation