🧠戦略ログ#2(2025/5/10)「AI 二刀流」で bot 開発を加速する方法&開発ロードマップ（2025-05 → 2028-05）

こんにちは、よだかです。
Cursor と ChatGPT を使い分けながら仮想通貨 bot を開発しています。
本稿では

1. ChatGPT — 設計や概念整理
2. Cursor — コード検証・エラー修正
   の二刀流を、どうフローに組み込むかを具体的に示します。

⚠️ 免責・ライセンス
本記事は筆者個人の検証結果をまとめた技術ドキュメントであり、暗号資産取引や投資の勧誘・助言を目的とするものではありません。
掲載コードは MIT ライセンスで提供しますが、運用による損失・障害・情報漏えい等について筆者は一切責任を負いかねます。
ご利用はすべて自己責任でお願いいたします。

1-A. “ChatGPT × Cursor”で実現できること ― ”概要早見表”

フェーズ	AIが担う具体タスク	期待インパクト
① 設計 & 仕様化	プロンプトからコード骨格を自動生成・既存ファイルを解析してフローチャートやMermaidを書く	設計ドキュメントの即時可視化・議論スピード倍増
② 実装 & リファクタ	Editor で ⌘+K → Edit with AI → クラス全体を書き換え／Composerで新規ファイル生成	反復的な“手ぐせコーディング”を80%削減 Cursor - The AI Code Editor
③ テスト生成 & デバッグ	テストコード／pytestシナリオ自動生成・ログやStackTraceを貼って“原因→修正パッチ”を提示	テスト網羅率↑＋デバッグ時間↓
④ データ分析	Forward/BackテストのCSVを貼付 → “勝率が落ちた理由を3パターンで説明せよ” 等の解析	ボトルネック特定までの試行錯誤を短縮
⑤ ドキュメント & 発信	READMEやブログ下書き、ラジオ原稿をワンショット生成	情報発信コスト↓、ブランド力↑

Cursor はコードベース検索・自然言語編集・Tab補完が一体化しており、コピペ不要で AI を呼び出せるのが強み Cursor - The AI Code Editor。
2025-04 以降は o3 がネイティブ選択肢に入り、Composer／チャット両方で利用可能 Medium。

1-B. “ChatGPT × Cursor”で実現できること ― “詳細解説”

前提
以下は o3 （または o3-mini）を Cursor に組み込んだ場合を想定しています。すべて VS Code ショートカット互換表記ですので、既存ワークフローへの移植も容易です。

フェーズ	具体タスクと Cursor 操作	実践TIP / 期待インパクト
① 設計 & 仕様化	a. コード骨格の生成 1. Cmd + K → 「bybit の WebSocket ハンドラを asyncio で雛形化して」 2. 生成された関数をそのまま挿入 or ⌥+Enter で「Replace」選択。 b. 既存ソースの可視化 1. 任意の Python ファイルを開く → Cmd + K → 「このファイルのフローを mermaid の flowchart で」 2. 右サイドバーに Mermaid ソースが返るので、⌘+Shift+V でプレビュー。	• Prompt Bar（Cmd + K）はエディタ直下で動くため 思考‐→コード変換が１アクション。 • フローチャート化は「AI に設計を説明させる」行為でもあり、幻覚ロジックの発見に有効。 • Mermaid はそのまま README に貼れるのでドキュメントが自動更新される。 CursorYouTube
② 実装 & リファクタ	a. インライン大量修正 1. 修正したいクラスを選択 → Cmd + K → 「イベントドリブンに書き換えて」 2. 差分プレビューで承認→即コミット。 b. Composer でファイル生成 1. Cmd + I（Composer）→ 「tests/test_slippage.py を pytest 形式で作って」 2. Composer がスクリプトを生成し、Apply でファイル出現。	• 手ぐせコーディングの自動化：特定パターン（例：ログガード追加）を短文指示で一括反映。 • Composer は“マルチファイル”編集が核。新規モジュールの雛形をまとめて吐かせるとプロジェクト構造の初期整備が爆速。 Cursor - Community Forum
③ テスト生成 & デバッグ	1. 実行ログ or StackTrace をチャットに貼付 → 「Failing test を再現する pytest を書いて → 修正案」 2. Cursor がテスト + パッチを提示。⌘+Enter でテストだけ受け取り、修正案は手動適用も可。	• “現象→原因→修正”を １ターンで回せる ため、初動デバッグ時間を大幅短縮。 • pytest -q をターミナル自動実行させ、失敗出力を再度 AI に食わせるループで 網羅率を押し上げ。 Learn R, Python & Data Science Online
④ データ分析	1. Back/Forward テスト結果 CSV をドラッグ → AI チャットに自動添付。 2. 「勝率が 5% 落ちた原因を 3 つの視点で分析し、改善パラメータを提案」 3. AI が要因別にリスト化 → 該当コードへ @filename.py:linenumber 形式でコメント。	• CSV → 言語化 の摩擦ゼロ。統計処理は軽いものなら AI に丸投げし、重い分析は Pandas スクリプトを自動生成させてローカルで走らせるハイブリッドが有効。
⑤ ドキュメント & 発信	1. 任意ファイル選択 → Cmd + K → 「このコミット内容をブログ草稿に要約。初心者向けに」 2. 出力された Markdown をそのまま Notion/Blog に貼り付け。 3. ラジオ原稿は 「30分想定で台本化」 テンプレで。	• “コードを書いた直後にアウトプット” が可能になり、情報発信が副産物化。 • 社外公開用／社内共有用にトーンを切り替える指示もワンフレーズ。

---

カギとなる Cursor 機能と o3 の相乗効果

機能	役割	o3 で強化されるポイント
Prompt Bar (Cmd + K)	既存コードのインライン編集	o3 の長い思考プロセスを“Thinking”モードで使うと複雑ロジックも一発置換 Cursor
Composer (Cmd + I)	新規/複数ファイル生成	o3-mini の低コストを活かし、繰り返し試作 → 最終版だけ o3 で高精度化
Codebase Q&A	⌘+Shift+Space でサイドバー質問	o3 の推論深度で「この指値ロジックが滑る条件を教えて」など抽象質問が通る
Mermaid ↔︎ Markdown	code → diagram, doc → flow	仕様書 ⇄ フロー図 双方向 ラウンドトリップを自動化

---

私の開発スタックへの具体的適用例

1. MMbot の発注モジュール
   Cmd + K → 「asyncio.gather で板監視と発注を並列化。エラー時は exponential_backoff で再試行」
   → 生成後に Ctrl + Space で型補完をチェック。
2. デプロイ用 Helm Chart 初稿
   Cmd + I → 「charts/mmbot/values.yaml と templates/deployment.yaml を作成」
   → そのまま k8s クラスタに apply → ログを AI チャットへ転送しチューニングサイクルへ。
3. バックテスト結果の異常検知
   CSV を貼って 「Sharpe が 0.8 を割る期間を抽出し、パラメータ共通点を出力」
   → 出力パラメータを ai-lint ターゲットが受け取り、.env.test に自動反映。

---

参考一次情報

• Cursor 公式ドキュメント：Prompt Bar & Inline Edit の概説 Cursor
• Composer でファイル生成（Community Forum） Cursor - Community Forum
• Mermaid 生成チュートリアル（YouTube） YouTube
• 0.49.x Changelog ― o3 ネイティブ/Rules Generation Cursor
• Cursor 機能総覧・比較（DataCamp ガイド） Learn R, Python & Data Science Online
• o3統合の解説記事（Medium, 2025-04） Medium

---

2. 半年ロードマップ（2025-05 → 2025-11）

月	重点テーマ	具体マイルストーン
0-1 M	環境基盤整備	Cursor+o3 を正式導入、Privacy Mode有効化。Makefile に ai-lint ターゲットを追加し、AI で静的解析→PR コメント自動投稿。
1-2 M	テスト自動化	Pytest カバレッジ80%を目標に、AI へ “テストスキャフォールド→実行→失敗理由の要約” をループ実装。
2-3 M	データ分析パイプ	Back/Forward テスト後に PnL, fill 数, DD を自動集計し、AI が Markdown レポートを生成→Slack へ投稿。
3-4 M	マルチ Bot 展開	Docker-compose + GitHub Actions へ AI 生成の k8s Manifests を差分適用。Cline を導入し、一部ファイル操作をエージェント化。
4-6 M	自律改善ループ v1	Fail→Root Cause→Patch→再テストを o3-high による“原因仮説3本＋修正案3本”テンプレで半自動化。コスト管理のため routine 解析は o3-mini へ切替。

0-1 M : 環境基盤整備 ― “AI 並走型” を始める初月フルガイド

トラック	ゴール	完了判定
A. Cursor + o3 本番導入	① o3 をチャット／⌘K／Composer で使えるようにする ② Privacy Mode を常時 ON	- Settings › Models で o3 が選択可 - Settings › General で Privacy Mode ✓ が緑表示
B. “AI-lint” ワンコマンド化	make ai-lint だけで 静的解析 → AI 修正案 を得る	CI でもローカルでも make ai-lint が 0 error
C. PR コメント自動投稿	GitHub Actions が PR を検知 → o3-mini で要約＋修正提案をコメント	PR に “AI Review” ボットコメントが付く

---

A. Cursor + o3 のセットアップ

1. モデルを追加
   ⌘+, → Settings › Models → Add model → "o3" で追加。
   • 料金: $0.30/req（Usage-Based Billing） Cursor - Community Forum
   • 見当たらない場合は一度再起動。
2. Privacy Mode を必ず有効化
   Settings › General › Privacy Mode → ON。
   これで コードは保存・学習されず即時削除 CursorCursor メモ: OFF のまま Pro プランを使うと学習対象になる報告あり Reddit
3. ショートカットの“身体化”
   • Prompt Bar: ⌘ K（部分編集・指示実装）
   • Composer: ⌘ I（新規/複数ファイル生成）
     小さなハック: VS Code の Keyboard Shortcuts で “K C” など好みへマッピング。
4. Usage-Based Billing の上限設定
   Cursor → Account › Billing → “Monthly cap” を $30 などに制限（テスト中の暴走防止）。

---

B. make ai-lint ― 静的解析＋AI リライトを一発実行

PY_FILES := $(shell git ls-files '*.py')

lint:                       ## 静的解析
	ruff check $(PY_FILES)

ai-fix:                     ## Ruff エラーを o3-mini へ渡して一括修正
	@printf "Fix these issues:\n$$(ruff check --silent $(PY_FILES))" \
	| cursor cli refactor -m o3-mini --stdin | patch -p1

ai-lint: lint ai-fix        ## まとめて実行

ポイント

行動	解説
ruff check	ruff は超高速 linter。--silent でエラー列挙だけ取得。
cursor cli refactor	Cursor CLI で o3-mini に修正案を投げ、差分パッチを STDOUT 供給。
上書き運用	生成パッチは patch -p1 で即適用 → git add -u → コミット。

ルール : routine は安価な o3-mini、ロジック複雑部だけ GUI で o3 に切替えて “Apply”。

---

C. GitHub Actions ― PR に「AI Review」を貼る

.github/workflows/ai-review.yml

name: ai-review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Ruff
        id: ruff
        run: |
          ERRORS=$(ruff check --output-format=json .)
          echo "errors=$ERRORS" >> "$GITHUB_OUTPUT"
      - name: Ask o3-mini for fixes
        if: steps.ruff.outputs.errors != '[]'
        env:
          CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
        run: |
          echo "${{ steps.ruff.outputs.errors }}" \
          | cursor cli refactor -m o3-mini --stdin > patch.diff
          echo "::set-output name=patch::$(cat patch.diff)"
      - name: Comment on PR
        if: steps.ruff.outputs.errors != '[]'
        uses: marocchino/sticky-pull-request-comment@v2
        with:
          header: AI Review
          message: |
            ## ✨ AI-fix Proposal
            ```diff
            ${{ steps.review.outputs.patch }}
            ```

🔒 本番クラスタの URL・IP アドレス・アクセストークンなどの機密情報は、必ずダミー値に置き換えてください。
例）
・ https://kubernetes.default.svc ⇒ https://example.com
・ ARGOCD_AUTH_TOKEN ⇒ dummy-token-1234
そのままコピーすると外部に機密を公開するリスクがありますのでご注意ください。

説明

ステップ	役割
ruff check --output-format=json	行番号つきエラーを取得
cursor cli refactor	JSON をプロンプト化し、パッチ生成
sticky-pull-request-comment	同じコメントを更新し続けるのでログが汚れない

到達判定: PR を作成 → 1 min 以内に「✨ AI-fix Proposal」が貼られる。

---

完了後のチェックリスト

• git commit -m "feat: integrate ai-lint" が通過し CI ✅
• Cursor のチャットで Thinking ボタンが o3 利用時に表示
• 日次 billing_monitor.py が Slack に “$usage_today / $cap” を通知
• Privacy Mode が常に ON（設定ファイルに privacyMode=true 反映）

---

リスク & 対策（初月時点）

リスク	兆候	即応策
API 超過課金	Billing cap 警告メール	usage_cap ↓ / o3→o3-mini 切替
幻覚パッチがビルドを壊す	CI RED が増える	ai-fix 適用前に pytest フルスイート強制
プライバシー設定漏れ	Privacy Mode OFF が再現	.cursor/settings.json を Git 監視＆CI にチェックスクリプト

---

💡 次フェーズ (1-2 M) ― テスト自動化 を掘り下げる準備として

• pytest -q | tee fail.log の出力を自動で AI チャットに送るシェルを試作
• coverage.xml を Parse → 未到達行を Composer へ貼り付け → テスト生成指示

---

1-2 M : テスト自動化 ― “AI にテストを書かせ、失敗を自己修復させる” 実践ハンドブック

トラック	ゴール	完了判定
A. AI-Driven テストスキャフォールド	pytest カバレッジ ≥ 80 % を最短ルートで突破	make ai-test → 新規テスト生成 → 1 回目の実行で Coverage>=80 %
B. Fail→Fix ループ自動化	失敗 StackTrace が AI に送られ、 “原因要約＋パッチ” が返る	pytest RED → make ai-fix で GREEN に反転
C. CI & Slack 連携	GitHub Actions が 「カバレッジ↓ or RED」のみ Slack 通知	失敗 PR には “AI Root-Cause” コメントが自動付与

---

A. AI-Driven テストスキャフォールド

1. 依存モジュールを追加

poetry add -D pytest pytest-cov coverage

2. Makefile ターゲット

PY_FILES := $(shell git ls-files '*.py' ':!:tests/*')

ai-test-gen:
	@echo "Generate tests for uncoverd lines…"
	@python scripts/gen_tests.py                                  \
	      --coverage .coverage                                   \
	      --model o3-mini

ai-test: clean-test cov-run ai-test-gen cov-run

cov-run:
	coverage run -m pytest -q && coverage xml -q

clean-test:
	@rm -f .coverage coverage.xml

3. scripts/gen_tests.py（抜粋）

import subprocess, xml.etree.ElementTree as ET, textwrap, os, json

def uncovered_lines(xml="coverage.xml"):
    tree = ET.parse(xml)
    for file in tree.iter("class"):
        missing = file.get("missing")
        if missing:
            yield file.get("filename"), missing

def build_prompt(filename, lines):
    return textwrap.dedent(f"""
    ファイル: {filename}
    テスト未到達行: {lines}
    pytest 互換のユニットテストを生成し、
    依存モックが必要なら最小限で stub を書いて。
    """)

def call_cursor(prompt, model="o3-mini"):
    proc = subprocess.run(
        ["cursor", "cli", "refactor", "-m", model, "--stdin"],
        input=prompt.encode(), stdout=subprocess.PIPE, check=True
    )
    return proc.stdout.decode()

for file, lines in uncovered_lines():
    prompt = build_prompt(file, lines)
    patch = call_cursor(prompt)
    subprocess.run(["patch", "-p1"], input=patch.encode(), check=True)

ワークフロー

1. 既存テストを実行 → coverage.xml を生成
2. 未到達行のみ AI に渡してテストを生成（o3-mini で低コスト）
3. 生成パッチ即適用 → 再び coverage run → カバレッジ確認

ポイント
o3-mini は o3 の 1/10 価格（$1.10/1M in, $4/1M out）なので “生成リトライ” も怖くない OpenAI。
Cursor CLI は refactor -m MODEL で 差分形式 を返すためパッチ適用がワンライナー CursorCursor。

---

B. Fail → Root-Cause → Patch ループ

1. StackTrace を自動取得
   pytest -q 2>fail.log || true
2. AI に投げて要約＋修正版を出力

cursor cli refactor -m o3-mini --stdin < fail.log > hotfix.diff
patch -p1 < hotfix.diff

3. 再テスト — GREEN ならコミット。失敗が残れば o3-high にスイッチ：

cursor cli refactor -m o3 --stdin < fail.log > hotfix2.diff

経験則：最初は o3-mini／“詰まったら o3” が 費用対効果最良。o3 は推論深度が高く、分岐の多いアルゴの修正精度が段違い OpenAI。

---

C. CI & Slack 連携（失敗時のみ通知）

.github/workflows/ci.yml

name: test
on: [pull_request]
env:
  CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install poetry && poetry install
      - id: pytest
        run: |
          coverage run -m pytest -q || echo "pytest_failed=true" >> $GITHUB_ENV
          coverage xml -q
      - id: coverage
        run: |
          pct=$(coverage report | grep TOTAL | awk '{print $4}' | sed 's/%//')
          echo "pct=$pct" >> $GITHUB_OUTPUT
      - name: AI Root-Cause & Patch
        if: env.pytest_failed == 'true' || steps.coverage.outputs.pct -lt 80
        run: |
          coverage html -q                              # デバッグ用アーティファクト
          pytest -q 2>fail.log || true
          cursor cli refactor -m o3-mini --stdin < fail.log > patch.diff
          echo "<details><summary>AI Root-Cause</summary>

\`\`\`diff
$(cat patch.diff)
\`\`\`
</details>" > comment.txt
      - name: PR Comment
        if: env.pytest_failed == 'true' || steps.coverage.outputs.pct -lt 80
        uses: marocchino/sticky-pull-request-comment@v2
        with:
          header: Test Report
          path: comment.txt
      - name: Slack Alert
        if: env.pytest_failed == 'true' || steps.coverage.outputs.pct -lt 80
        uses: slackapi/slack-github-action@v1
        with:
          payload: |
            {
              "text": "*CI RED*\nPR #${{ github.event.number }} failed tests or coverage <80%."
            }
          slack-bot-token: ${{ secrets.SLACK_BOT_TOKEN }}

🔒 本番クラスタの URL・IP アドレス・アクセストークンなどの機密情報は、必ずダミー値に置き換えてください。
例）
・ https://kubernetes.default.svc ⇒ https://example.com
・ ARGOCD_AUTH_TOKEN ⇒ dummy-token-1234
そのままコピーすると外部に機密を公開するリスクがありますのでご注意ください。

チェックポイント

条件	動作
pytest × or Coverage < 80 %	① AI Root-Cause コメント ② Slack 通知
全テスト Pass	ワークフロー終了（通知なし）

---

到達判定リスト

• make ai-test 一発で Coverage 80 %以上到達
• RED→make ai-fix で GREEN に戻る（手動パッチ不要）
• 失敗 PR に “Test Report” コメント＋ Slack 警報が付く
• 月間 o3 使用量 < $20（Billing cap で確認）

---

リスク & ワークアラウンド（1-2 M）

リスク	兆候	即応策
幻覚テスト（無意味アサーション）	テストは Pass だがロジック覆いきれていない	pytest --cov-report=term-missing で branch coverage を監視
外部 API 呼び	AI が requests.get() を埋め込む	Prompt で 「外部 HTTP 呼び出しは禁止」 を明示、pytest --no-network マーカーを追加
トークン爆増	fail.log が巨大 → o3-mini billing spike	tail -n 300 fail.log だけ渡す／max_tokens を 2048 に制限

2-3 M : データ分析パイプ ― “テスト→損益レポート→要因分析”を完全自動で回す

トラック	ゴール	完了判定
A. 自動集計スクリプト	Back/Forward テスト終了と同時にPnL / fill / DD を Pandas で集計	python scripts/build_metrics.py が CSV → metrics.md を生成
B. AI 要因分析	Cursor CLI に Markdown を渡し“勝率↓の原因×3 & 改善案×3” を取得	make ai-analyze → analysis.md が生成
C. Slack 報告	GitHub Actions がanalysis.md を Slack へ送信	レポートが #trading-logs に自動投稿

---

A. メトリクス自動集計

1. 依存パッケージ

poetry add pandas tabulate

2. scripts/build_metrics.py

import pandas as pd, pathlib, argparse, json
from datetime import datetime

def load_csvs(folder):
    frames = []
    for f in pathlib.Path(folder).glob("*.csv"):
        df = pd.read_csv(f)
        df["file"] = f.stem
        frames.append(df)
    return pd.concat(frames, ignore_index=True)

def calc_metrics(df):
    pnl = df["pnl"].sum()
    fills = df["fill_qty"].count()
    dd = df["balance"].cummax() - df["balance"]
    max_dd = dd.max()
    return {"PnL": pnl, "fills": fills, "maxDD": max_dd}

def to_markdown(metrics, out="metrics.md"):
    md = pd.DataFrame(metrics, index=["value"]).T.to_markdown()  # tabulate backend :contentReference[oaicite:0]{index=0}
    with open(out, "w") as f:
        f.write(f"# Test Metrics ({datetime.utcnow():%Y-%m-%d})\n\n{md}\n")

if __name__ == "__main__":
    p = argparse.ArgumentParser()
    p.add_argument("--folder", default="reports")
    args = p.parse_args()
    df = load_csvs(args.folder)
    to_markdown(calc_metrics(df))

チェック
python scripts/build_metrics.py --folder reports/2025-05-15 → metrics.md が生成。

---

B. AI 要因分析 (make ai-analyze)

ai-analyze: metrics
	@cursor cli ask -m o3-mini -p "以下のMarkdownを読み、\
勝率が低下した主要因を3つと、改善パラメータを3つ提案して。```markdown\n$$(cat metrics.md)\n```" \
	> analysis.md

トリック : Cursor CLI ask は STDIN で渡した文書全体をコンテキストに推論し、通常チャットと同じフォーマットで回答を返す CursorCursor。
日常ループは o3-mini で十分。推論が浅いと感じた時だけ -m o3 に切替。

---

C. GitHub Actions → Slack

.github/workflows/report.yml

name: pnl-report
on:
  workflow_run:
    workflows: ["test"]          # ← テスト完走後に起動
    types:
      - completed
jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Metrics
        run: poetry run python scripts/build_metrics.py --folder reports

      - name: AI Analyze
        env:
          CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
        run: |
          cursor cli ask -m o3-mini -p "以下省略…" > analysis.md

      - name: Send to Slack
        uses: slackapi/slack-github-action@v1    # 公式 GH Action :contentReference[oaicite:2]{index=2}
        with:
          payload: |
            {
              "text": "*Back/Forward テスト分析完了* :chart_with_upwards_trend:\n```$(cat analysis.md)```"
            }
          slack-bot-token: ${{ secrets.SLACK_BOT_TOKEN }}

GitHub Marketplace には Webhook 専用 Action もあり簡単に差し替え可 GitHub。

---

到達判定リスト

• metrics.md と analysis.md が 手動操作ゼロで更新
• Slack に “:chart_with_upwards_trend:” 付きレポートが投稿
• 1 テストサイクルあたり 人間の所要時間 0 分

---

リスク & 抑え込み

リスク	兆候	即応策
巨大 CSV → トークン爆発	analysis.md 生成で API error	tail -n 2000 でサンプル抽出 or metrics.json だけ渡す
Markdown 表示崩れ	Slack で罫線が欠ける	tabulate に tablefmt="github" 明示
Slack ノイズ	レポートが多すぎる	if: github.event.workflow_run.conclusion == 'failure' で RED のみ通知

---

ここまでで得られる効果

1. テストが回るたびに 数字→因果→改善案 が Slack へ流れ、次の開発タスクが自然に列挙。
2. バックテストとフォワードテストの差異が即言語化され、パラメータ・ロジックの修正点を AI が先読み。
3. 人手でグラフを作る工程ゼロ。必要なら cursor cli ask --python で Matplotlib スニペットも自動生成可能。

3-4 M : マルチ-Bot展開 ― “Docker-compose → Kubernetes → GitOps” を３か月で固める

トラック	ゴール	完了判定
A. コンテナ基盤統一	すべての Bot（MM / FR / P&D …）を docker-compose.yml で起動	docker compose up で 3 Bot が同時稼働し、ログが 1 画面に集約
B. AI 生成 K8s マニフェスト	Compose → Deployment / Service / HPA に変換し、Namespace mmbots 下で動作	kubectl get pods -n mmbots が READY = 1/1
C. GitOps パイプライン	GitHub Actions → Argo CD で自動同期	git push → < 3 min でクラスタが更新 & Slack 通知
D. Cline 導入	“Plan/Act” エージェントがファイル生成・ターミナル実行	VS Code で ⌘⇧P → Cline: Plan → 指示どおりの PR が自動生成

---

A. docker-compose.yml で Bot 群を揃える

1. compose 雛形

version: "3.8"
services:
  mmbot:
    build: ./mmbot
    env_file: .env.mmbot
  frbot:
    build: ./frbot
    env_file: .env.frbot
  pndbot:
    build: ./pndbot
    env_file: .env.pndbot
  redis:
    image: redis:7-alpine
    ports: ["6379:6379"]

2. CI で検証

# .github/workflows/compose-ci.yml
    - name: Compose up
      run: docker compose up -d --build
    - name: Health-check
      run: docker compose exec mmbot curl -f localhost:8000/health

Compose は後で kompose で K8s 変換に使うので、サービス名・ポートはシンプルに揃えるのが吉 Kubernetes。

---

B. Compose → Kubernetes を AI とツールで併用

ステップ	やること	ツール / コマンド
1	kompose convert -f docker-compose.yml -o k8s/	Kompose が Deployment/Service を自動生成 Stack OverflowKubernetes
2	生成 YAML を Cursor Composer に投げ 「HPA と namespace=mmbots を追加」	o3 が multi-file patch を提案 YouTubeCursor
3	helm create mmbots → “templates” に AI 修正版を上書き	Helm 化で Values にパラメータ集約 Blog of STS Consulting

例：Deployment 追記

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mmbot-hpa
  namespace: mmbots
spec:
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

AI には “CPU60%でスケール、imagePullPolicy=IfNotPresent” など制約を文章で渡すと高精度な YAML が返る。

---

C. GitHub Actions + Argo CD で GitOps

repo/
 └─ charts/mmbots/        # Helm package
 └─ manifests/overlays/   # kustomize (optional)

1. Actions で Helm チャートをビルド & Push

# .github/workflows/helm.yml
on: [push]
jobs:
  build-push:
    steps:
      - uses: actions/checkout@v4
      - run: helm lint charts/mmbots
      - run: helm package charts/mmbots -d packaged/
      - uses: actions/upload-artifact@v4
        with: { name: chart, path: packaged/*.tgz }

2. Argo CD アプリ定義

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mmbots
spec:
  source:
    repoURL: 'https://github.com/you/repo'
    targetRevision: main
    path: charts/mmbots
  destination:
    server: https://kubernetes.default.svc
    namespace: mmbots
  syncPolicy:
    automated: { prune: true, selfHeal: true }

3. Actions から Argo 同期

- name: ArgoCD Sync
  uses: actions/checkout@v4
- run: argocd app sync mmbots
  env: { ARGOCD_AUTH_TOKEN: ${{ secrets.ARGO_TOKEN }} }

GitOps 全体像は GitHub Actions → Argo CD で “push から本番反映 < 3 min” が目安 ferrishall.devMedium。

🔒 本番クラスタの URL・IP アドレス・アクセストークンなどの機密情報は、必ずダミー値に置き換えてください。
例）
・ https://kubernetes.default.svc ⇒ https://example.com
・ ARGOCD_AUTH_TOKEN ⇒ dummy-token-1234
そのままコピーすると外部に機密を公開するリスクがありますのでご注意ください。

---

D. Cline で“Plan/Act” エージェント化

1. VS Code 拡張をインストール
   Marketplace → Cline – Autonomous Coding Agent。
   • Plan モード：タスク分解だけを提案
   • Act モード：ファイル操作・ターミナル実行を自動で行う ClineMedium
2. o3 を使う設定

#cline.config.json
{
  "provider": "openrouter",
  "model": "o3-mini",
  "safeMode": true
}

3. 実例：新 Bot 追加

Plan: "Add delta-hedge bot with env=DH_"
Act → creates dhbot/, Dockerfile, values.yaml, updates helm Chart.yaml

安全策：Act 前に “diff preview” が出るので必ず確認 → Approve。

---

到達判定チェックリスト

• docker compose up → 全 Bot が HEALTHY
• kubectl get hpa -n mmbots が CPU しきい値でスケール
• git push 後、Argo CD UI が Synced/Healthy
• VS Code で Cline “Act” が PR を自動生成し、CI パス

---

リスク & 対策（3-4 M）

リスク	兆候	即応策
Kompose 変換漏れ	Env/volume が manifest に無い	Cursor Composer へ “envFrom & PVC 追加” を追指示
Argo Sync 循環	OutOfSync が常態化	Helm appVersion → Chart version の不一致を修正
Cline 誤操作	Act が rm -rf 予期せず実行	cline.safeMode=true ＋ “Require Review” ポリシーで制限

4-6 M : 自律改善ループ v1 ― “失敗を AI が解析し、修正パッチまで⾃動化” を確⽴する

トラック	ゴール	完了判定
A. Fail→Root-Cause→Patch テンプレ化	すべての RED（テスト失敗・実運⽤エラー）をo3-high が 原因仮説×3 ＋ 修正案×3 で返す	make ai-rca → rca.md が “3 × 3” フォーマットで出⼒
B. パッチ⾃動適⽤ ＋ 再テスト	RCA で最有⼒パッチを適⽤ → GREEN なら自動コミット → PR	make ai-fix 1 発で RED→GREEN／CI ✅
C. Billing Monitor	o3 / o3-mini の使い分けを⾃動最適化し、Slack に⽇次報告	“$spent / $quota” が #ai-billing に通知
D. 改善 KPI ダッシュボード	平均復旧時間 (MTTR) を 6 h → 1 h に短縮	Grafana パネルで MTTR 曲線が右肩下がり

—— 「転けたら即、AI が原因を特定しパッチまで当てる」仕組みを固める 90 日間

トラック	ゴール	完了判定
A	Fail → Root-Cause → Patch を “3 × 3” テンプレで自動生成	make ai-rca → rca.md が 原因 3 件＋修正案 3 件
B	最良パッチを適用し GREEN なら自動コミット → PR	make ai-fix 1 発で RED→GREEN・CI ✅
C	o3 / o3-mini の 自動スワップ & 日次 Slack 課金レポート	#ai-billing に「$used / $cap」メッセージ
D	MTTR*¹ を 6 h → 1 h へ	Grafana パネルが右肩下がり

*¹ Mean Time To Recovery — 「失敗検知から GREEN までの平均時間」

---

A. Fail → Root-Cause → Patch テンプレ化

ステップ	実装ポイント	補足
1. ログ取得	`pytest -q 2>fail.log
2. テンプレに差し込み	scripts/rca.py fail.log -m o3	Jinja2 で {{LOG}} ほか 10 変数を埋め込み
3. o3-high に投げる	cursor cli ask -m o3 --stdin	thinking=ON で深掘り推論
4. 出力例	rca.md が  🐞 原因仮説 3 本  🔧 修正案 3 本＋リスク	先頭にスクリーンショットを貼るとレビュー効率↑

<details><summary>テンプレ完全版</summary>

## 🔥 問題ログ
```text
{{LOG}}
```    

---

🐞 原因仮説（上位 3 件）

1. {{hyp1}}
2. {{hyp2}}
3. {{hyp3}}

---

🔧 修正案

#	パッチ概要	影響範囲	リスク
1	{{fix1}}	{{scope1}}	{{risk1}}
2	{{fix2}}	{{scope2}}	{{risk2}}
3	{{fix3}}	{{scope3}}	{{risk3}}

Fail → Root-Cause → Patch テンプレ化:詳細解説

— 「エラーが起きたら、AI に原因を特定させて修正パッチまで吐かせる」ミニ自動化ラインを作る

ステップ	コマンド例	かんたん解説（初心者向け）
1. ログ取得	pytest -q 2>fail.log	テストを静かに (-q = quiet) 回して、エラー出力だけを fail.log に保存します。「何が壊れたか」を後で AI に渡すための材料づくりです。
2. テンプレに差し込み	python scripts/rca.py fail.log -m o3	fail.log の中身を、あらかじめ用意した Markdown テンプレート（{{LOG}} などの穴あき部分）に流し込みます。ここで使う Jinja2 は “差し込み印刷” のようなテンプレートエンジンです。
3. o3-high に投げる	cursor cli ask -m o3 --stdin	完成した Markdown を o3 (ChatGPT AI) に送って、「エラーの原因仮説を３つ、それぞれに対する修正案を３つ書いて」と指示します。thinking=ON なので AI が深く考えながら答えるモードです。
4. 出力確認	生成ファイル → rca.md	AI が返した結果は ① 🐞 原因仮説 3 本 ② 🔧 修正案 3 本 + 影響範囲 & リスク の形で Markdown（= 普通のテキストファイル）になります。レビューしやすいように、必要ならエラーログのスクリーンショットを１枚貼るとさらに分かりやすいよ、という補足です。

---

テンプレートの中身をもう少し噛み砕くと…

## 🔥 問題ログ       ← ここに実際のエラーメッセージがそのまま入る
{{LOG}}

🐞 原因仮説（上位 3 件）  ← AI が「たぶんこれが原因だろう」を３つ列挙
{{hyp1}}
{{hyp2}}
{{hyp3}}

🔧 修正案                  ← それぞれの原因に対応するパッチ案
#  パッチ概要  影響範囲  リスク
1  {{fix1}}   {{scope1}} {{risk1}}
2  {{fix2}}   {{scope2}} {{risk2}}
3  {{fix3}}   {{scope3}} {{risk3}}

• {{LOG}} … 取得したエラー全文
• {{hyp1}}…{{hyp3}} … AI が出す３つの「ありそうな原因」
• {{fix1}}…{{fix3}} … それぞれどう直すかの提案
• {{scope}} / {{risk}} … 修正が影響する範囲 & 想定される副作用

目的は「①エラーを読む→②原因を推理→③修正を考える」という人間の手作業を AI に肩代わりさせ、あなたは レビューと最終判断だけ に集中できるようにすることです。

---

なぜ便利？

• 時間短縮 — ログ解読→原因推理→修正案作成のループが１コマンドで終わる
• 抜け漏れ防止 — 原因を３つ、修正案も３つ必ず列挙させるので“見落とし”が減る
• ドキュメント兼ナレッジ — rca.md がそのまま「過去トラブル事例集」になる

---

推奨

最も安全かつ効果が高い案は #{{best_fix}}。

</details>

**なぜ 3 × 3 か？**  
*1 案だけだと幻覚のまま突っ走る*／*5 案だと人間がレビューしきれない*——実務で最もバランスが良かったため。

---

## B. パッチ自動適用 ＋ 再テスト

1. **パッチ生成**  
   ```bash
   make ai-fix        # (= ai-rca → ai_fix.py → pytest)

ai_fix.py が rca.md を読み、
cursor cli refactor -m o3-mini に

「#{{best_fix}} を diff 形式で出力せよ」

と指示 → patch コマンドで即適用。

2. 再テスト
   • GREEN → peter-evans/create-pull-request@v6 が Autopatch PR を発行。
   • RED 残存 → スクリプト内で -m o3 に切替えて再試行（リトライ上限 2）。
3. CI ゲート
   • 自動マージはせず “Auto-Merge on review” に設定。
   • Canary デプロイ（10 % / 5 min）で事故を封じ込める。

---

C. Billing Monitor で コスト自動最適化

要素	実装	ポイント
Usage API	GET /dashboard/billing/usage?start_date=YYYY-MM-DD&end_date=YYYY-MM-DDGitHub	応答 JSON→total_usage (¢)
Slack 通知	slackapi/slack-github-action@v1 で payload:JSONGitHubGitHub	23 : 00 JST に cron
自動スワップ	if usage > cap*0.8: export AI_MODEL=o3-mini	CI が mini モデルにフォールバック

cap=50 USD で運用すると、残枠 10 USD を切ったタイミングで mini へ強制ダウングレードし 課金事故 を回避。

---

D. MTTR ダッシュボード

• 1.計測

python scripts/mttr.py   # returns seconds
echo "bot_mttr_seconds $(…)" | curl -XPOST localhost:9091/metrics/job/mttr

mttr.py は Git log から

FIRST_RED_COMMIT → 次の GREEN_COMMIT

の経過秒を算出。

• 2.Prometheus ルール

# mttr.rules.yml
groups:
  - name: bot_mttr_rules
    rules:
      - record: job:bot_mttr_7d
        expr: avg_over_time(bot_mttr_seconds[7d])

Grafana Labs Community Forums

• 3.Grafana
  • Statパネルに mttr_7d を表示。
  • Threshold: 1 h 以下で緑。
  • SLO ボードに重ね、回帰線が右肩下がりを確認Grafana Labs。

---

まとめ & チェックリスト

確認項目	目標値
make ai-rca ➜ rca.md が 原因 3 件＋修正案 3 件 出力	✅
make ai-fix ➜ RED→GREEN（CI） 成功率 ≥ 80 %	✅
Slack #ai-billing ➜ 毎晩「$used / $cap」投稿	✅
Grafana MTTR 7d 移動平均 ≤ 1 h	✅

---

リスクとワークアラウンド

リスク	兆候	即応策
幻覚パッチが静かに仕様破壊	Canary でエラー比率↑	Feature flag を仕込み、HPA + Alertmanager で即 Rollback
o3-high トークン爆発	RCA 1 回 $5＋	max_tokens=2048・ログ 4 k 行上限
Slack ノイズ	Billing通知が多すぎる	if usage > cap*0.5 未満ならスキップ

---

3. 3 年ビジョン（2025-05 → 2028-05）

フェーズ	ゴール	技術／体制
Year 1	“AI-first CI/CD”完成：PR→AIレビュー→自動マージ→自動デプロイ	o3 + GitHub Actions + ArgoCD、セキュリティスキャンを CodeWhisperer 無料枠で補完 AWS ドキュメント
Year 2	マルチ戦略×自律最適化：RL-based パラメータチューナがリアルタイムにスプレッドや流動性を監視	強化学習ループのコスト抑制に open-source LLM（Code Llama 70B, StarCoder2 15B）をローカル推論 InfoQMedium
Year 3	全自動 Bot-Ops 平台：取引所/API 追加も AI がマニフェスト生成、Kubernetes へデプロイ	社内ツールとして JetBrains AI か Amazon Q Developer を併用し、Cursor 系が停止しても開発継続可 JetBrainsAmazon Web Services, Inc.

到達指標例
同時運用 Bot 10 本、デイリー取引 2 k 回、回帰テスト完走 < 30 min、SAR (risk-adjusted PnL) 1.5↑

3 年ビジョン (2025-05 → 2028-05) ― “AI-First Bot-Ops” に到達するロードマップ

それぞれの年度を「何が出来るようになるか」「どうやって作るか」「到達判定は何か」に分解します。

---

Year 1（～ 2026-05）ゴール：AI-first CI/CD を日常運用に定着させる

項目	具体内容
① AI レビュー → 自動マージ	- GitHub Actions で PR 差分を cursor cli ask -m o3-mini に送り要約＋指摘を自動コメント。 - すべて GREEN（テスト／カバレッジ／セキュリティ）なら “Auto-Merge on green” ルールで main へ。
② 自動デプロイ	- Argo CD が main ブランチをウォッチし、Helm チャートを即同期。 - Canary 10 % → 全量 (5 min) を標準化。
③ セキュリティ・ライセンススキャン	- AWS CodeWhisperer Individual Free Tier（常時無料）を Actions 内で呼び、最大 50 code scans/月 を確保 AWS ドキュメント。
体制	- o3 / o3-mini を使い分ける Billing ガード。 - リポジトリ単位で “CI pass < 15 min、PR→Prod < 30 min” を SLO に設定。

完了判定

• 手動レビューゼロでもデプロイまで到達する PR が 80 %↑
• 緊急 Hotfix は平均 30 min 以内 に本番反映
• CodeWhisperer スキャンが月 50 枠を使い切るペース（= 自動運用が回っている証拠）

---

Year 2（～ 2027-05）ゴール：マルチ戦略 × 自律最適化

要素	実装ポイント
① RL-based パラメータチューナ	- 強化学習エージェントがスプレッド・出来高・FR を常時観測し、スプレッド幅やオーダーブロックサイズを刻々チューニング。
② コスト抑制のためのローカル推論	- 推論コストの重い“シミュレーション内会話”は Code Llama 70B や StarCoder2 15B を Apple Silicon / GPU BOX でオンプレ稼働 Meta AIMeta AI。
③ データ基盤	- Prometheus → Thanos で 18 か月分のメトリクスを保持。 - プライベート MinIO に生 Tick を圧縮保存（後段 RNN / LSTM 用）。
体制	- “Open-source fallback-first” 方針：クラウド LLM が落ちてもローカル LLM に自動フェイルオーバー。 - 週次 “strategy-retrospective” を AI が自動議事録化。

完了判定

• 運用中 Bot が 5 → 10 本 に拡張、各戦略の Sharpe (SAR) ≥ 1.2
• RL チューナによる 日次 PnL +5 % 改善が 30 日連続で確認
• OpenAI トークン費用が Q/Q 比 ▲40 %（ローカル化の効果）

---

Year 3（～ 2028-05）ゴール：全自動 “Bot-Ops 平台”

要素	実装ポイント
① 取引所 / API 追加も AI 化	- 新エクスチェンジの REST / WS Spec を投げると、AI が  a. Python クライアント  b. Helm overlay  c. モニタリング Rule を自動生成。
② IDE／モデルの多重化	- JetBrains AI Assistant（2025 以降 “無料枠あり”）を第二開発ラインに常備 The JetBrains BlogJetBrains。 - Amazon Q Developer Free Tier（月 50 チャット / 5 コード変換）で障害時の保険 Amazon Web Services, Inc.Amazon Web Services, Inc.。
③ 完全 GitOps	- Argo CD + Kyverno で セキュリティ/コンプラポリシー も Git 管理。 - 自動ロールバックは 5 min SLO。
体制	- “Bot-SRE 当番” を AI エージェントがサポート。PagerDuty を鳴らす前に RCA + パッチまで提示。

到達指標（Year 3 末）

KPI	目標値
同時運用 Bot	10 本
デイリー取引数	≈ 2 000 Fill / 日
回帰テスト完走	< 30 min（GPU + 分散）
SAR (risk-adjusted PnL)	1.5 以上

---

３年プラン全体を通して意識すること

1. “モデル可換” アーキテクチャ
   • ai_client.py に provider=OpenAI | LocalLLM | JetBrains | AmazonQ を抽象化。
   • IDE／Cloud ベンダーが落ちても数行の ENV 切替で継続可能。
2. コスト vs. 精度のダイナミックルーティング
   • ルーチン解析：o3-mini → 高難度：o3-high → オフピーク：ローカル LLM に自動振り分け。
   • Billing Monitor で日次使用量が上限の 80 % を超えたら強制ダウングレード。
3. ナレッジの“層”を残す
   • RCA, 改善案, パフォーマンスレビューを Markdown 化 → mkdocs-material で社内ポータル。
   • トレードログの決定的瞬間はスクリーンキャストも取り、LLM フィードバックの教師データに。

---

4. “Cursor & ChatGPT が落ちた時”の保険プラン

カテゴリ	代替ツール	特徴／利点
IDE＋クラウド LLM	JetBrains AI Assistant (無料枠)	Java/Python 等で IntelliJ 系に乗換えても AI チャット・テスト生成が同等に可能 JetBrains
	Amazon Q Developer / CodeWhisperer	VSCode/JetBrains プラグインあり。個人枠無料＋50 回/月 セキュリティスキャン AWS ドキュメントAmazon Web Services, Inc.
IDE エージェント	Cline (VS Code)	Plan/Act モードでファイル生成・ターミナル操作まで自動化。モデルは OpenRouter 経由で o3 や Claude, Gemini も利用可 Cline
ローカル推論	Code Llama 70B / StarCoder2 を Ollama で起動	GPU/Apple Silicon で GPT-3.5 相当の補完がオフライン可。ソース流出リスクゼロ InfoQMedium
SaaS型マルチモデル	Qodo / Sourcegraph Cody / Codeium など	毎月のランキング記事で性能比較しつつスイッチング可能 Qodo

実装メモ

• AI 呼び出しを ai_client.py に抽象化し、provider="cursor" / "cline" / "local_llm" を切替可能にしておく。
• モデルの推論深度を HIGH/MEDIUM/LOW の Enum にし、コストと速度をプロンプト側で制御。

4. “Cursor × ChatGPT が落ちた時”の保険プラン

ねらい - 1 時間以内に開発を再開できる よう、IDE／モデル／推論環境を多重化しておく。
ここでは “工事の要点”＋“スイッチ手順” を初心者にも分かる平易な語でまとめます。

カテゴリ	代替ツール	できること & 利点	導入 5 分クイックガイド
IDE＋クラウド LLM	JetBrains AI Assistant (無料枠)	IntelliJ 系（PyCharm／IDEA／WebStorm …）で: • チャット質問 • コード補完 • ⾃動テスト作成 が使える。 → VS Code → JetBrains へ IDE を切替えても 学習コスト少なめ。	① JetBrains Toolbox で PyCharm Community をDL ② Preferences › AI Assistant → Enable ★無料枠は 30 req/日程度 ③ Alt+Enter で「AI Fix」／⌥⌘⌥A でチャット
	Amazon Q Developer ＆ CodeWhisperer	• VS Code & JetBrains プラグインあり • 個人枠は完全無料 ＋ 月 50 回 セキュリティスキャン • 「Explain this code」や IAM ポリシー生成も◎	① AWS Console → Amazon Q で「個人無料」開始 ② VS Code 拡張 AWS Toolkit → Q Developer を ON ③ /// コメントで「?」を打つと提案が挿入
IDE エージェント	Cline (VS Code)	• “Plan→Act” の２段モード • Act でファイル生成／ターミナル操作／git commit まで全自動 • モデルは OpenRouter → o3 / Claude / Gemini が選べる → Cursor が落ちても同じモデル を叩ける	① VS Code Marketplace → Cline を Install ② cline.config.json に   {"provider":"openrouter","model":"o3-mini"} ③ ⌘⇧P → Cline: Plan → 指示文を書く → Act へ昇格
ローカル推論	Code Llama 70B or StarCoder2 15B + Ollama	• Mac M-series or GPU PC で “ChatGPT-3.5 相当” 補完が オフライン。 • コードがクラウドに漏れない。	① brew install ollama（mac） ② ollama pull codellama:70b ③ VS Code → Continue 拡張で http://localhost:11434 に接続
SaaS型マルチモデル	Qodo / Sourcegraph Cody / Codeium など	• 毎月の性能ランキングで「その時いちばん安く速いモデル」にスイッチ • ブラウザ or VS Code 拡張で即利用可	① アカウントを作成（メールのみ） ② VS Code に拡張を入れて API KEY を貼る ③ チャット or インラインで利用

---

速攻で“切り替えられる”コード設計 — ai_client.py をハブ化する

# ai_client.py ざっくり例
class Provider(Enum):
    CURSOR = "cursor"
    CLINE = "cline"
    LOCAL = "local_llm"
    JETBRAINS = "jetbrains"
    AMAZON_Q = "amazon_q"

AI_PROVIDER = Provider(os.getenv("AI_PROVIDER", "cursor"))

def ask(prompt, *, depth="MEDIUM"):
    if AI_PROVIDER is Provider.CURSOR:
        model = "o3" if depth=="HIGH" else "o3-mini"
        return cursor_cli(prompt, model)
    elif AI_PROVIDER is Provider.CLINE:
        return cline_api(prompt, depth)
    elif AI_PROVIDER is Provider.LOCAL:
        return ollama_chat(prompt, model="codellama:70b")
    …

切り替え手順

1. Cursor 障害検知 → .env の AI_PROVIDER=cline に変更
2. docker compose restart bot — これだけで全 Bot が Cline 経由に

推論深度 HIGH/MEDIUM/LOW を Enum で渡し、ルーチンは安価モデル、RCA だけ高精度モデルなど自動で振分けると コストと速度の最適解 が取りやすい。

---

障害シナリオ別 “30 min リカバリ” フロー

シナリオ	即応 10 分プラン	半日以内の恒久化
Cursor API Down	.env→AI_PROVIDER=cline → VS Code で Cline Act を解放	JetBrains AI にプロジェクトを Import、CI の ai_client.py を CLINE 固定にリビルド
OpenAI 全停止	AI_PROVIDER=local_llm → Ollama を -d 起動し VS Code Continue を接続	Amazon Q Developer を provider=amazon_q に追加、課金上限を設定
IDE ごと故障 (VS Code ext ⚠)	JetBrains PyCharm を開いて AI Assistant を ON	Sourcegraph Cody Web IDE にリポジトリを clone、Push 後に Argo CD へ再同期
法規制／課金上限	同上 (Local LLM / Amazon Q free)	SaaS マルチモデル (Qodo) に移行、コスト比較で月次見直し

---

最低限準備しておくチェックリスト

• 各ツールの API Key を 1Password 等の保管庫に登録済み
• docker-compose.override.yml に “local-llm” サービス（Ollama）を用意
• ai_client.py が 5 分で他プロバイダへ切替可
• “AI Fallback” runbookを Notion に整備 & スマホで閲覧可

これで Cursor / ChatGPT が完全停止 しても、30 分以内に開発を再開できる態勢が整います。
実際の環境で試運転し、「本当に 30 分で戻れるか」を一度ドリルしておくと安心です。

---

5. 現状プランの“脆弱ポイント”と対策

指摘	リスク	打ち手
o3 コスト膨張	入力$10／出力$40 per 1M tok と高額 OpenAI	解析ジョブは o3-mini へ、重要局面のみ o3-high を “Batch API” で回す Batch API は OpenAI Docs (2025-03) で “~50 % 単価” と明記されており、 大量ログ解析時はコスト削減効果が大きい。
LLM の幻覚	データソース無しのコード例を生成	VSCode で enableStrictMode=True、ユニットテスト自動生成で裏どり
ベンダーロック	Cursor プラットフォーム依存	前述の抽象化レイヤ＋JetBrains/Cline 併用で冗長化
法規制・コンプライアンス	海外拠点・税制最適化時に規制変化	AI へ条文要約させつつ、専門家レビューを必須フローに

よくあるリスクと“即効で効く”対策の背景解説

指摘	何が危険？（初心者向けに解説）	打ち手（ステップ‐バイ‐ステップ）
1. o3 コスト膨張	o3 は 入力 $10 / 出力 $40 / 100 万トークン。長いログや大容量 CSV を雑に投げると 1 回 $2〜$5 も珍しくない。しかも 1 日に数十リクエスト流せば月額数百ドルに跳ね上がる。 OpenAI Community	① ルーチン解析は o3-mini に固定（単価 1/10）。 ② 重要局面のみ o3 ─ ai_client.ask(prompt, depth="HIGH") で明示的に切替。 ③ Batch API を使う：ログ 100 本を一括投げれば 通常料金の 50 % で済む。 OpenAI ヘルプセンター
2. LLM の幻覚（誤情報コード）	AI が「それっぽい」コードを返すが、根拠データなし・型違い・API 存在しない──いわゆる hallucination。新人ほど鵜呑みにして本番クラッシュの元になる。	① VS Code の Strict チェックを強制  Settings → Python › Analysis: Type Checking Mode = strict で型違いを即エラー。 Stack Overflow ② make ai-test で 自動ユニットテスト生成→即実行。失敗すればパッチを却下。 ③ “外部 API 呼び出しは禁止” をプロンプトに毎回入れ、幻覚確率を下げる。
3. ベンダーロック（Cursor 依存）	Cursor が停止・値上げ・仕様変更した瞬間、開発がすべてストップする“一点故障”。	① すべての AI 呼び出しを ai_client.py に抽象化（`provider=cursor
4. 法規制・コンプライアンス	海外拠点や多通貨取引は、税制・暗号資産規制が年度単位で変わる。違反すると口座凍結や追徴のリスク。	① 新しい法令 PDF を **AI に「300 字で要約＋論点抽出」**させ、まず概要を把握。 ② その要約を持って 専門家（税理士・弁護士）にレビュー依頼――“AI+人”の二段チェックを必須フローに。 ③ リポジトリに compliance/REGYYYY-MM.md を残し、変更履歴を Git 管理。

---

ai_client.py実装メモ（再掲）

# ai_client.py (抜粋)
from enum import Enum
import os

class Depth(Enum):
    LOW = "o3-mini"
    HIGH = "o3"

class Provider(Enum):
    CURSOR     = "cursor"
    CLINE      = "cline"
    LOCAL_LLM  = "local_llm"
    JETBRAINS  = "jetbrains"
    AMAZON_Q   = "amazon_q"

PROVIDER = Provider(os.getenv("AI_PROVIDER", "cursor"))

def ask(prompt: str, *, depth: Depth = Depth.LOW):
    if PROVIDER is Provider.CURSOR:
        return cursor_cli(prompt, model=depth.value)
    if PROVIDER is Provider.CLINE:
        return cline_api(prompt, model=depth.value)
    if PROVIDER is Provider.LOCAL_LLM:
        return ollama_chat(prompt, model="codellama:70b")
    if PROVIDER is Provider.JETBRAINS:
        return jetbrains_ai(prompt)
    if PROVIDER is Provider.AMAZON_Q:
        return amazon_q_chat(prompt)
    raise RuntimeError("Unsupported provider")

ポイント :

• モデル単価を depth で制御（渋い処理は LOW、RCA だけ HIGH）。
• プロバイダ切替は環境変数だけなので、Cursor 障害時は以下の操作で5分以内に復旧可能。

export AI_PROVIDER=CLINE && make restart

---

最後に

半年先までに「AI並走型開発」を日常化できれば、3 年後には“自律最適化 Bot 運用基盤”に到達可能――これは、私が既に実証している“学習→実装→検証”ループを AI が指数的にブーストする。次に着手すべきは AI 呼び出しの抽象化 と テスト自動化。ここを固めれば、モデルや IDE が変わっても開発エッジは維持できるはず。