Claude Code から自律AIエージェントにリアルタイムで話しかけてデバッグする仕組みを作った

Claude Code から自律AIエージェントにリアルタイムで話しかけてデバッグする仕組みを作った

Mailbox API、Discord Webhook、GitHub Actionsの3つのチャネルを組み合わせ、Claude Code(開発側AI)が自律エージェントRuby(本番AI)にリアルタイムで話しかけ・デバッグできる仕組みを構築。AIがAIをデバッグする開発サイクルの短縮法を紹介します。
2026.03.23

はじめに

自律AIエージェント「Ruby」を開発していると、デプロイ後の動作確認が最大のボトルネックになります。コードを書いてプッシュし、コンテナが再ビルドされ、Discord でメッセージを送って応答を確認し、ログを見て問題を特定し…という手動サイクルを繰り返していました。

「Claude Code(開発側のAI)が Ruby(本番のAI)に直接話しかけてデバッグできたら、開発サイクルが圧倒的に速くなるのでは?」

この記事では、3つのチャネル を組み合わせて Claude Code が Ruby とリアルタイムで会話・デバッグできる仕組みを構築した方法を紹介します。

全体アーキテクチャ

Claude Code は3つの経路で Ruby にアクセスします:

チャネル 用途 Ruby から見たコンテキスト
Mailbox API DM として直接会話 DM(フルプロファイル)
Discord Webhook Discord チャネルにメッセージ投稿 チャネルメッセージ(チャットプロファイル)
debug-logs ワークフロー コンテナログ取得 — (ログ読み取りのみ)

前提・環境

  • Ruby: 自律AIエージェント(Python 3.12+、Discord/LINE/Slack 対応)
  • 実行環境: Oracle Cloud VM、Docker コンテナ
  • 開発環境: Windows 11 + Claude Code CLI
  • デプロイ: git push → GitHub Actions → SSH → Docker rebuild
  • Discord: Webhook 経由でメッセージ送信

チャネル1: Mailbox API — DM コンテキストでの会話

Ruby は Supabase ベースの Mailbox API を持っており、/api/chat エンドポイントで直接会話ができます。認証は SSH Ed25519 鍵による署名方式です。

仕組み

# 認証ヘッダーを生成して API コール
ts=$(date +%s)
device=$(hostname | tr '[:upper:]' '[:lower:]')
sig=$(uv run python -c "
from cryptography.hazmat.primitives.serialization import load_ssh_private_key
from pathlib import Path; import base64
k = load_ssh_private_key(
    Path.home().joinpath('.ssh','id_ed25519').read_bytes(), password=None)
print(base64.b64encode(k.sign(b'${ts}:${device}')).decode())")

curl -s -X POST \
  -H "X-Device: ${device}" \
  -H "X-Timestamp: ${ts}" \
  -H "X-Signature: ${sig}" \
  -H "Content-Type: application/json" \
  -d '{"text":"Hi Ruby, what model are you running?"}' \
  "https://api.rubyclaw.uk/api/chat"

応答例

{
  "response": "I'm running on Gemini 3.1 Flash Lite. The delegation system is working — I can call Claude Code via the delegate tool."
}

特徴

  • Ruby は DM コンテキスト として処理 → フルプロファイル(全人格ファイル + 全ツール)
  • レスポンスが JSON で返るため、Claude Code がプログラム的に処理しやすい
  • SSH 鍵署名認証で安全

チャネル2: Discord Webhook — チャネルコンテキストでのテスト

Discord Webhook を使うと、特定のチャネルにメッセージを投稿できます。Ruby はこれを 通常のチャネルメッセージ として処理するため、チャネル用のプロンプトプロファイルをテストできます。

セットアップ

  1. Discord チャネル設定 → 連携サービス → Webhook → 新規作成
  2. Webhook URL を .claude/secrets.json に保存(gitignore 済み)
.claude/secrets.json
{
  "discord_webhook_url": "https://discordapp.com/api/webhooks/..."
}

Claude Code スキルとして実装

.claude/commands/discord.md にスキルを定義し、/discord コマンドで呼び出せるようにしました:

.claude/commands/discord.md
Send a message to Ruby on Discord via webhook and optionally check her response.

User input: $ARGUMENTS

## Instructions

1. Read the webhook URL from `.claude/secrets.json`
2. Write message payload to temp file, send via curl
3. Wait 15 seconds, then fetch container logs to check response

使い方

/discord Hi Ruby! What are your Discord formatting rules?

Claude Code が自動的に:

  • Webhook URL を読み取り
  • curl でメッセージ送信
  • 15秒待機後にログを取得して Ruby の応答を確認

なぜ Webhook なのか

Discord の REST API でメッセージを送る方法はいくつかありますが、Webhook を選んだ理由:

  • Bot トークン不要 — Ruby 自身の Bot トークンを使うと、Ruby は自分のメッセージを無視する
  • ユーザートークンは ToS 違反 — Discord は自動化目的のユーザートークン使用を禁止している
  • Webhook は安全 — チャネル設定から30秒で作成、URL だけで送信可能
  • Ruby が正しくチャネルメッセージとして処理 — プロンプトプロファイルのテストに最適

DM vs チャネルの比較テスト

この仕組みの真価は、同じ質問を DM と チャネルの両方から送って、Ruby の挙動の違いを検証できる ことです:

テスト DM(Mailbox API) チャネル(Webhook)
読み込まれるルール SOUL + IDENTITY + USER + CORE + SELF_MODIFY + MEMORY_RULES + SYNC SOUL + IDENTITY + CORE + DISCORD + GROUP_CHAT
利用可能なツール 全12ツール 6ツール(chat セット)
プロンプトサイズ ~4,200 トークン ~1,500 トークン

チャネル3: debug-logs ワークフロー — コンテナログの取得

Oracle Cloud VM に直接 SSH できない場合でも、GitHub Actions 経由でコンテナログを取得できるワークフローを用意しています。

.github/workflows/debug-logs.yml
name: Debug - Fetch container logs

on:
  workflow_dispatch:
    inputs:
      add_ssh_key:
        description: "Public SSH key to add to VM (optional)"
        required: false
      tail_lines:
        description: "Number of log lines to fetch"
        default: "200"

jobs:
  logs:
    runs-on: ubuntu-latest
    steps:
      - name: Add SSH key to VM (if provided)
        if: inputs.add_ssh_key != ''
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.OCI_HOST }}
          username: ${{ secrets.OCI_USER }}
          key: ${{ secrets.OCI_SSH_KEY }}
          script: |
            mkdir -p ~/.ssh
            echo "${{ inputs.add_ssh_key }}" >> ~/.ssh/authorized_keys
            sort -u -o ~/.ssh/authorized_keys ~/.ssh/authorized_keys

      - name: Fetch container logs
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.OCI_HOST }}
          username: ${{ secrets.OCI_USER }}
          key: ${{ secrets.OCI_SSH_KEY }}
          script: |
            cd /opt/rubyclaw && docker compose ps
            docker compose logs --tail=${{ inputs.tail_lines }}

使い方

# ログ取得
gh workflow run debug-logs.yml -f tail_lines="100"

# 結果を読む
gh run view <run_id> --log 2>&1 | grep "rubyclaw-1" | grep -v "healthz"

SSH 鍵の追加機能

新しい開発マシンからの SSH アクセスを追加する機能も組み込んでいます:

gh workflow run debug-logs.yml \
  -f add_ssh_key="$(cat ~/.ssh/id_ed25519.pub)" \
  -f tail_lines="100"

これにより、GitHub Actions の SSH 鍵を経由して、新しいマシンの公開鍵を VM の authorized_keys に追加できます。

実際のデバッグフロー

ここからは、実際にこの仕組みを使ってデバッグしたケースを紹介します。

ケース: v0.23.0 デプロイ後の動作確認

v0.23.0 で大規模なリファクタリング(プロンプトプロファイル + 委任ツール)をデプロイした後の確認フロー:

ステップ1: デプロイ完了を確認

gh run list --workflow deploy.yml --limit 1
# completed  success  Deploy to Oracle Cloud

ステップ2: Mailbox API で Ruby に話しかける

curl -s -X POST ... \
  -d '{"text":"What model are you running?"}' \
  "https://api.rubyclaw.uk/api/chat"

→ Ruby が応答。モデル名やツールの可用性を確認。

ステップ3: Discord Webhook でチャネルコンテキストをテスト

/discord Hi Ruby! What are your rules about markdown tables?

→ Ruby が Discord ルール(DISCORD.md)に基づいて応答することを確認。

ステップ4: ログで内部挙動を確認

gh workflow run debug-logs.yml -f tail_lines="50"
# → LiteLLM completion() model= gemini-3.1-flash-lite-preview; provider = gemini
# → tool:delegate args={'task': '...'}
# → Delegation completed (1735 chars)

→ 正しいモデルが使われているか、ツールが呼ばれているか、エラーがないかを確認。

ケース: レートリミットの発見

テスト中にログで以下を発見:

rate_limit_error: 50,000 input tokens per minute

Claude Code がログからレートリミットを検出し、原因分析と対策(プロバイダー切り替え)を即座に提案できました。手動では「Ruby が応答しない → ログを見る → 原因を考える」のサイクルに数十分かかるところが、数分で完了しました。

セキュリティの考慮

要素 対策
Webhook URL .claude/secrets.json に保存、.gitignore で除外
Mailbox API 認証 SSH Ed25519 鍵署名、デバイス登録制
コンテナログ GitHub Actions 経由、OCI SSH 鍵は Secrets に保存
Discord Webhook チャネル管理者のみ作成可能、URL の漏洩に注意

まとめ

  • Mailbox API → DM コンテキストで Ruby と直接会話。認証済み、JSON レスポンス
  • Discord Webhook → チャネルコンテキストでのテスト。プロンプトプロファイルの検証に最適
  • /discord スキル → Claude Code からワンコマンドで Webhook 送信 + ログ確認
  • debug-logs ワークフロー → SSH なしでコンテナログを取得。新マシンの鍵追加も可能

この3つを組み合わせることで、Claude Code が「コードを書く → プッシュ → Ruby に話しかける → ログで確認」のサイクルを すべてターミナル内で完結 させられるようになりました。人間がブラウザで Discord を開いてメッセージを打つ必要がなくなります。

AI が AI をデバッグする — これが実現すると、開発サイクルのボトルネックは「デプロイ待ち」だけになります。

この記事をシェアする

FacebookHatena blogX

関連記事