専用のバイブコーディングツールがほしい　その2

Posted at 2025-12-12

前書き

こちらの続き　
AIと設計を詰める。
やってみて思ったのは、AIの指示に対して疑問や提案するのは自分の中でも整理になるので大事だなと。
なんでもAIの言う通りにやるのは思考の停止になりかねない。
以下生成AIの成果物。

📄 第1章：概要（Introduction / Overview）

1.1 システムの目的

本システムは、ユーザーが自然文で記述した「意図（vibe）」を解析し、
環境に適応したコード生成を自動で行う バイブコーディングツールである。

従来のコード生成ツールとは異なり、本システムは以下を重視する：

環境適応性：ユーザーのローカル環境（system.yaml）に合わせて生成内容を最適化
再現性：生成プロセスを監査ログとして保存し、後から完全に再現可能
拡張性：タスク分類や生成ロジックを後から追加・改善できる
自然文中心の操作性：ユーザーはコードではなく「意図」を入力するだけでよい

本ツールは、ローカル開発環境での自動化、API 開発、データ処理、AI ワークフロー構築など、
幅広い用途に対応することを目指す。

1.2 システムの特徴

自然文 → Structured Task → コード生成 の3段階パイプライン
環境検出（system.yaml） に基づく最適化
ローカル LLM / API LLM 両対応
監査ログ（JSONL）による完全な再現性
VS Code 拡張との連携
仮想環境（uv/venv）に自動適応
タスク分類体系に基づく安定したコード生成

1.3 システム構成要素（高レベル）

UI レイヤー：VS Code 拡張、CLI
API レイヤー：FastAPI ベースのローカルサーバ
バイブコーディング本体：意図解析、プロンプト生成、コード生成
環境基盤：system.yaml、config、ログ、仮想環境
LLM レイヤー：ローカルモデル or API モデル

1.4 想定ユーザー

ローカル環境で開発するエンジニア
自動化ツールを素早く作りたいユーザー
コード生成を高速化したいユーザー
AI ワークフローをローカルで構築したいユーザー

📄 第2章：要求仕様（Requirements）

2.1 機能要件（Functional Requirements）

本システムは以下の機能を提供する。

意図解析

ユーザーの自然文を解析し Structured Task を生成する
タスク分類（task_type）を推定する
処理ステップ（steps）を抽出する
依存関係（dependencies）を推定する

プロンプト生成

Structured Task と system.yaml を統合し LLM 用プロンプトを生成する

コード生成

LLM を用いてコードを生成する
生成コードを複数ファイルに分割可能
VS Code に反映する

環境適応

system.yaml を参照し、環境に適したコードを生成する
仮想環境（uv/venv）に応じて依存関係管理を調整する

監査ログ

Structured Task
プロンプト
LLM 応答
生成コード
を JSONL として保存し、再現性を確保する。

2.2 非機能要件（Non-functional Requirements）

再現性

生成プロセスを完全に再現できること
system.yaml と監査ログにより、同じ環境で同じ結果が得られること

監査性

生成プロセスの全ステップをログとして保存すること
Structured Task のバージョン管理を行うこと

拡張性

タスク分類体系を後から追加可能
LLM モデルを差し替え可能
プロンプトテンプレートを拡張可能

パフォーマンス

ローカル LLM でも実用的な応答速度を確保すること

セキュリティ

ローカル環境で完結する構成を優先
API モードでは安全な通信方式を採用

2.3 制約条件（Constraints）

Python 3.13 以上
Windows / macOS / Linux 対応
ローカル LLM の VRAM 制約
VS Code 拡張との通信は HTTP ベース

2.4 前提条件（Assumptions）

system.yaml が存在する
仮想環境が構築可能（uv または venv）
LLM が利用可能（ローカル or API）
ユーザーが VS Code を利用している

📄 バイブコーディングツール設計書（Architecture Document）

第3章：全体アーキテクチャ設計

3.1 概要

本章では、バイブコーディングツール全体のアーキテクチャを定義する。
本ツールは、ユーザーの自然文による意図（vibe）を解析し、
環境に適応したコード生成を行うことを目的とする。

アーキテクチャは以下の 5 レイヤーで構成される。

UI レイヤー
アプリケーション API レイヤー
バイブコーディング本体レイヤー
環境基盤レイヤー
LLM / ストレージレイヤー

3.2 レイヤー構造

┌──────────────────────────────┐
│ ① UI レイヤー（VS Code / CLI）│
└───────────────┬──────────────┘
                │
┌───────────────▼───────────────┐
│ ② アプリケーション API レイヤー │
│    - FastAPI（ローカルサーバ）  │
└───────────────┬───────────────┘
                │
┌───────────────▼────────────────────┐
│ ③ バイブコーディング本体レイヤー      │
│    A. 意図解析（Vibe → 構造化タスク）│
│    B. プロンプト生成（環境統合）     │
│    C. コード生成（LLM）             │
└───────────────┬────────────────────┘
                │
┌───────────────▼──────────────────┐
│ ④ 環境基盤レイヤー（基盤）         │
│    - 環境検出（system.yaml）      │
│    - 依存関係管理（uv/venv）      │
│    - 設定ファイル管理（config/*）  │
│    - ログ管理（監査ログ）          │
└───────────────┬──────────────────┘
                │
┌───────────────▼──────────────┐
│ ⑤ LLM / ストレージレイヤー     │
│    - ローカル LLM / API LLM    │
│    - モデル管理（models/）      │
│    - 監査ログ（JSONL / SQLite） │
└────────────────────────────────┘

3.3 データフロー（意図 → コード生成）

[1] ユーザーの意図（自然文）
        │
        ▼
[2] 意図解析（A）
        │  構造化タスク(JSON)
        ▼
[3] プロンプト生成（B）
        │  LLMに渡す完全プロンプト
        ▼
[4] コード生成（C）
        │  生成コード
        ▼
[5] VS Code へ反映

3.4 環境情報の流れ（system.yaml の役割）

[環境検出モジュール]
        │
        ▼
  system.yaml
        │
        ├── 意図解析（A）で参照
        ├── プロンプト生成（B）で参照
        ├── LLM 実行方式の決定（GPU/CPU）
        └── VS Code 側の補助情報にも利用

3.5 各レイヤーの責務

① UI レイヤー（VS Code / CLI）

ユーザーの意図入力
コード生成のトリガー
結果の表示（diff / 新規ファイル）

② アプリケーション API レイヤー（FastAPI）

UI と本体ロジックの橋渡し
HTTP 経由での安全な処理呼び出し

③ バイブコーディング本体レイヤー

A：意図解析（Vibe → Structured Task）
B：プロンプト生成（環境統合）
C：コード生成（LLM）

④ 環境基盤レイヤー

system.yaml の生成・更新
config/*.yaml の管理
仮想環境（uv/venv）の検出・構築可否判定
監査ログ（JSONL / SQLite）

⑤ LLM / ストレージレイヤー

ローカル LLM または API LLM の選択
モデルのロード・推論
監査ログの永続化

3.6 アーキテクチャの特徴

レイヤー分離が明確で責務が重複しない
system.yaml が“環境の真実”として全レイヤーに影響
バイブコーディング本体が UI や LLM と独立
ログと設定が一元管理され、監査性・再現性が高い
将来的な拡張（モデル変更、UI変更、環境変更）に強い

第4章：意図解析レイヤー設計

4.1 Structured Task スキーマ定義

4.1.1 概要

Structured Task は、ユーザーの自然文を解析した結果を表す
中間表現（IR: Intermediate Representation） である。

4.1.2 Structured Task JSON スキーマ（正式版 Draft v1）

{
  "task_schema_version": 1,

  "task_type": "string",
  "description": "string",

  "steps": [
    {
      "id": "string",
      "action": "string",
      "details": "string",
      "inputs": ["string"],
      "outputs": ["string"]
    }
  ],

  "inputs": ["string"],
  "outputs": ["string"],

  "dependencies": [
    {
      "name": "string",
      "type": "python_package | system_binary | model",
      "required": true
    }
  ],

  "environment": {
    "python_version": "string",
    "venv_type": "string",
    "gpu_available": "boolean",
    "os": "string"
  },

  "constraints": {
    "performance": "low | medium | high | null",
    "memory_limit_mb": "number | null",
    "reliability": "low | medium | high"
  },

  "metadata": {
    "created_at": "ISO8601 string",
    "source": "user_input | system_inference",
    "notes": "string"
  }
}

4.1.3 スキーマの特徴

拡張性：バージョン管理・柔軟な dependencies
監査性：metadata による追跡
再現性：environment を完全保持
環境適応性：system.yaml を統合

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

専用のバイブコーディングツールがほしい その2

前書き