ChatLLM APIとVSCode拡張機能Continueを組み合わせてバイブコーディング環境を構築した話

Sep 6, 2025· wan0ri

概要

本記事では、ABACUS.AI が提供する ChatLLM の API を VSCode 拡張機能「Continue」に連携させ、バイブコーディング環境を整備した一連の流れをまとめます。
当初は Cursor ルール用に作成した .mdc ファイルを参照する方式を考えましたが、最終的には 全ルールを config.yaml に直書きし、API キーもローカルの config.yaml に直接埋め込む 方式に落ち着きました。

経緯

Cursor の Pro プランを利用していたが、毎月の上限を使い切ることが多かった。
既に契約していた Abacus.AI の ChatLLM API を活用できないか検討。
ChatLLM にはエディタ連携機能がないため、VSCode 拡張「Continue」 をフロントエンドに利用。
最初は .mdc にルールを分割し参照する構成を考えたが、将来的に不要になるため廃止。
また、環境変数経由で API キーを渡す方式は GUI 環境の VSCode でうまく読み込まれない ことが判明。
結果として、個人利用では config.yaml に API キーを直書きする方法が最も安定することが分かった。

対応

1. ChatLLM API キー発行

Abacus.AI 管理画面から RouteLLM API キーを発行。
GUI 経由の VSCode では ~/.zshrc などから環境変数が引き継がれなかったため、今回は config.yaml に直書きする運用とした。

2. Continue の設定ファイル

VSCode 拡張 Continue は、ユーザーごとに ~/.continue/config.yaml を参照する。
今回はここに AI モデル定義とルールを直書き。

設定例（抜粋）:

models:
  - name: backend-specialist
    provider: openai
    model: gpt-5
    apiBase: https://routellm.abacus.ai/v1
    apiKey: "sk-demo-your-api-key-here" # ← APIキーは直書き（ダミー値）
    systemMessage: |
      あなたはバックエンド開発専門AIです。
        - RESTful API設計原則に従うこと
        - 認証・認可・入力検証を必須とすること
        - DB設計は正規化とパフォーマンスのバランスを確保すること
        - エラーハンドリングとログ出力を明示すること
        - テスタビリティを考慮すること

3. 専用モデルとルール設計

用途ごとに AI モデルを切り替えて使えるように定義。例えば以下のように専門モデルを用意しました。

docs-claude → ドキュメント生成（Claude 系）
terraform-gpt / infra-specialist → インフラ構築支援（GPT-5 固定）
backend-specialist / frontend-specialist → アプリ開発支援
docker-specialist / kubernetes-specialist → インフラ設定補助
ci-gpt / commit-gpt → CI/CD や Git コミットメッセージ生成
sql-specialist / yaml-specialist / json-specialist → 各フォーマット専用チェック

4. VSCode での利用

VSCode 再起動後、Continue パネルを開くとモデル一覧から選択可能に。
backend-specialist を選べば API 設計支援、ci-gpt を選べばワークフロー定義など、利用場面ごとに使い分けができる。

5. 完成形

最終的に以下が実現できました。

.mdc ファイル不要 → config.yaml 直書きに集約
API キーは 環境変数経由ではなく直書き運用（GUI 環境での安定利用のため）
用途に応じた専門 AI をモデル一覧から切り替えて利用できる

今後の展望

現時点ではアプリ開発は未着手のため、インフラ領域での試験利用を継続。
今後はバックエンド/フロントエンド/CI/CD など、用途ごとに専門 AI を本格活用する予定。
チーム利用する場合は config.template.yaml をリポジトリで共有し、各自が API キーを直書きして利用する方法を推奨する。