AIエージェント実装5フェーズ完全ガイド【2026年版】設計から本番運用まで

2026.03.15 更新 27分で読める
AIエージェント実装5フェーズ完全ガイド【2026年版】設計から本番運用まで

この記事の結論

AIエージェント実装を5フェーズ（要件定義・設計・開発・テスト・本番運用）に体系化。LangChain・LangGraph・AutoGen選定基準、Langfuseによる品質監視、段階的ロールアウト手法を2026年最新情報で解説。初期投資150万円でROI 312%を達成した実例も収録。




「AIエージェントを本番で動かしたいのに、PoCから先に進めない…」

10社以上のAIエージェント導入を支援してきた経験の中で、最もよく聞かれる悩みがこれです。PoCで動いたはずのエージェントが、本番環境では想定外のループに陥ったり、コストが爆発したり。正直、PoCの成功と本番の成功はまったく別の話です。

この記事では、設計から本番運用・スケールまでを5つのフェーズに分解し、各フェーズでやるべきこと・使えるコード例・落とし穴を全公開します。LangGraph、CrewAI、AutoGen、Mastraのフレームワーク比較も含め、2026年時点の最新ベストプラクティスをまとめました。今日から実践できる内容ですので、ぜひ手を動かしながら読んでみてください。

AIエージェントの基本概念や設計パターンについては、AIエージェント構築完全ガイドで体系的にまとめています。本記事ではより実装・運用寄りの内容に絞ります。

まず試したい「即効セットアップ」3選

フェーズ解説の前に、今すぐコピペで試せるコードを3つ紹介します。どれも5分以内に動作確認できます。

即効テクニック1：OpenAI Agents SDKで最小エージェントを動かす

2026年現在、最もハードルが低い入門コードはこれです。OpenAI Agents SDKはPython・TypeScript両対応で、ツール定義もシンプルです。


# 動作環境: Python 3.11+, openai-agents>=0.0.7
# pip install openai-agents
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

import asyncio
from agents import Agent, Runner

# ツール定義
def get_weather(city: str) -> str:
    """指定都市の天気を返す（実際はAPI呼び出し）"""
    return f"{city}の天気: 晴れ、気温22℃"

# エージェント定義
agent = Agent(
    name="WeatherAgent",
    instructions="ユーザーの質問に対して、必要であれば天気ツールを使って回答してください。",
    tools=[get_weather],
)

async def main():
    result = await Runner.run(agent, "東京の天気を教えて")
    print(result.final_output)

asyncio.run(main())

ポイント: `instructions` がシステムプロンプトに相当します。最初は1ツールだけで動作確認し、徐々に追加していくのが鉄則です。

即効テクニック2：LangGraphでステート管理エージェントを作る

複数ステップのワークフローが必要なら、LangGraphのグラフ構造が強力です。


# 動作環境: Python 3.11+, langgraph>=0.2.0, langchain-openai>=0.1.0
# pip install langgraph langchain-openai
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages
from langchain_openai import ChatOpenAI
from typing import TypedDict, Annotated

# ステート定義（型安全）
class AgentState(TypedDict):
    messages: Annotated[list, add_messages]

llm = ChatOpenAI(model="gpt-4o-mini")

def chatbot_node(state: AgentState):
    return {"messages": [llm.invoke(state["messages"])]}

# グラフ構築
builder = StateGraph(AgentState)
builder.add_node("chatbot", chatbot_node)
builder.add_edge(START, "chatbot")
builder.add_edge("chatbot", END)

graph = builder.compile()

# 実行
result = graph.invoke({"messages": [{"role": "user", "content": "AIエージェントとは？"}]})
print(result["messages"][-1].content)

ポイント: `TypedDict` でステートを型定義することで、複雑なフローでもデバッグが格段に楽になります。条件分岐は `add_conditional_edges()` で追加できます。

即効テクニック3：CrewAIでマルチエージェントを30分で立ち上げる

複数エージェントを役割分担させたい場合、CrewAIは最速の選択肢です。


# 動作環境: Python 3.11+, crewai>=0.80.0
# pip install crewai
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

from crewai import Agent, Task, Crew

# リサーチャーエージェント
researcher = Agent(
    role="市場リサーチャー",
    goal="AIエージェント市場の最新動向を調査する",
    backstory="10年以上のリサーチ経験を持つアナリスト",
    verbose=True,
)

# ライターエージェント
writer = Agent(
    role="テクニカルライター",
    goal="リサーチ結果をわかりやすいレポートにまとめる",
    backstory="技術記事を専門に書くライター",
    verbose=True,
)

task1 = Task(description="2026年のAIエージェント市場トレンドを調査", agent=researcher)
task2 = Task(description="調査結果を500字のサマリーにまとめる", agent=writer)

crew = Crew(agents=[researcher, writer], tasks=[task1, task2], verbose=True)
result = crew.kickoff()
print(result)

ポイント: `backstory` がエージェントの「ペルソナ」を決めます。具体的に書くほど、役割に即した応答が得られます。

5フェーズ全体像と所要期間の目安

AIエージェント実装は、以下の5フェーズで段階的に進めるのが安全です。

フェーズ 内容 所要期間 主な成果物
Phase 1 要件定義・設計 1〜2週間 アーキテクチャ設計書、ツール一覧
Phase 2 PoC開発 2〜4週間 動作する最小エージェント、初期ベンチマーク
Phase 3 パイロット展開 1〜3ヶ月 限定公開版、フィードバックログ
Phase 4 本番展開 1〜2ヶ月 CI/CD統合、モニタリング基盤
Phase 5 最適化・スケール 継続（月次） A/Bテスト結果、コスト最適化レポート

重要なのは、各フェーズを省略しないことです。Phase 2（PoC）の成功に自信を持ちすぎて、Phase 3（パイロット）をスキップしてフル展開に踏み切るチームを何度も見てきましたが、ほぼ例外なくPhase 4で大きなトラブルが起きています。

Phase 1：要件定義・設計（1〜2週間）

ここでの設計品質が、最終的な成功率を大きく左右します。エージェントに「何をさせるか」を決める前に、「何をさせないか」を明確にすることが大切です。

ユースケースの明確化

以下の問いに答えてから設計を始めましょう。

  • このエージェントが解決する課題は何か？（KPIで表せるか）
  • 人間の介在が必要なステップはどこか？（Human-in-the-Loop設計）
  • エージェントが「やってはいけないこと」は何か？（ガードレール設計）
  • 失敗した場合のフォールバックは何か？

フレームワーク選定

2026年時点で主要な4つのフレームワークを比較します。

フレームワーク 得意領域 学習コスト マルチエージェント 本番実績
LangGraph 複雑な条件分岐、ステート管理 中〜高 ○ ◎（最多）
CrewAI マルチエージェント協調、素早いPoC 低〜中 ◎ ○
AutoGen マルチエージェント会話、コード実行 中 ◎ ○
Mastra TypeScript/Next.js環境 低（TS既存チーム） ○ △（新興）

選定の基準をシンプルにまとめると：複雑なフローを精密に制御したい → LangGraph、マルチエージェントをすぐ試したい → CrewAI、Pythonチームでコード実行重視 → AutoGen、TypeScriptチーム → Mastraです。

LangChain + LangGraphの組み合わせは2026年時点でPyPIダウンロード数4,700万超と最大のエコシステムを持ちます（o-mega.ai, 2026-02）。一方、CrewAIは標準的なビジネスワークフローでLangGraphより40%早く本番展開できるという報告もあります。

シングル vs マルチエージェント

マルチエージェントは魅力的ですが、複雑さも増します。

  • シングルエージェント向き: ツール数が3〜5個以内、タスクが単一ドメイン、チェーンが5ステップ以下
  • マルチエージェント向き: 専門知識が異なる複数の役割が必要、並列処理でスループットを上げたい、一方のエージェントが他方を検証する構成が必要

正直に言うと、「とりあえずマルチエージェントにしよう」という発想は危険です。最初はシングルエージェントで動かし、どうしても必要になった時点でマルチ構成に移行するのが安全なアプローチです。

Phase 2：PoC開発（2〜4週間）

PoCの目的は「動くことを確認する」ではなく、「本番で機能するかの仮説を検証する」ことです。この認識の違いが、Phase 3以降の明暗を分けます。

最小ツールセットで始める


# 動作環境: Python 3.11+, langgraph>=0.2.0, langchain-openai>=0.1.0
# PoCフェーズ: ツールは最小限（1〜3個）から始める
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from langgraph.prebuilt import create_react_agent

@tool
def search_knowledge_base(query: str) -> str:
    """社内ナレッジベースを検索する"""
    # PoCでは固定レスポンスで動作確認
    return f"「{query}」に関する情報: サンプル回答です。実際のPoCではRAGを接続します。"

@tool
def escalate_to_human(reason: str) -> str:
    """人間オペレーターにエスカレーションする"""
    # エスカレーション通知（PoCではログ出力のみ）
    print(f"[ESCALATION] 理由: {reason}")
    return "担当者に引き継ぎます。少々お待ちください。"

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# PoCエージェント
agent = create_react_agent(
    model=llm,
    tools=[search_knowledge_base, escalate_to_human],
    prompt="あなたはカスタマーサポートエージェントです。n"
           "ナレッジベースで回答できない場合は必ずエスカレーションしてください。n"
           "回答は3文以内にまとめてください。",
)

result = agent.invoke({"messages": [{"role": "user", "content": "返品方法を教えてください"}]})
print(result["messages"][-1].content)

PoC評価で必ず測定すべき指標

PoCフェーズで最低限計測しておくべき数値がこれです。後のフェーズでの比較基準になります。

指標 測定方法 PoCの合格ライン目安
タスク完了率 テストケース100件での正解率 70%以上
平均レイテンシ エージェント実行時間の平均 ユースケース要件次第
ツール誤使用率 不適切なツール呼び出しの割合 10%以下
平均トークン消費 1タスクあたりのinput+output tokens コスト試算のベースライン取得

テストケースは最低100件用意してください。20〜30件では偶然の成功を見逃します。エッジケース（ユーザーが予想外の質問をするシナリオ）を意識的に混ぜることが重要です。

Phase 3：パイロット展開（1〜3ヶ月）

パイロットは、実際のユーザーに触れさせながらフィードバックを収集するフェーズです。全体の5〜20%程度の範囲からスタートするのが一般的です。

Langfuseでトレーシングを入れる

パイロット以降は、必ずトレーシングツールを導入してください。Langfuseはオープンソースで、OpenTelemetry準拠の業界標準になりつつあります（Langfuse, 2024-07）。


# 動作環境: Python 3.11+, langfuse>=2.0.0, langchain-openai>=0.1.0
# pip install langfuse langchain-openai
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

import os
from langfuse import Langfuse
from langfuse.callback import CallbackHandler

# 環境変数で認証情報を管理（ハードコード禁止）
# export LANGFUSE_PUBLIC_KEY=pk-xxx
# export LANGFUSE_SECRET_KEY=sk-xxx
# export LANGFUSE_HOST=https://cloud.langfuse.com

langfuse = Langfuse()
handler = CallbackHandler()

# LangChain/LangGraphにCallbackHandlerを渡す
result = agent.invoke(
    {"messages": [{"role": "user", "content": "請求書の見方を教えてください"}]},
    config={"callbacks": [handler]},  # ← これだけでトレース開始
)

# Langfuseダッシュボードで以下が可視化される:
# - 各ツール呼び出しのレイテンシ
# - トークン消費量（ステップ別）
# - エラー・例外の発生箇所
# - LLMの中間推論（thinking）

エラーハンドリングとフォールバックの実装

パイロット段階で必ず実装すべきなのがエラーハンドリングです。PoCでは無視しがちですが、実ユーザーが触ると想定外のエラーが続出します。


# 動作環境: Python 3.11+
# エラーハンドリングとフォールバックのパターン
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

import asyncio
from openai import RateLimitError, APITimeoutError

async def run_agent_with_fallback(user_input: str, max_retries: int = 3) -> str:
    """
    リトライ + フォールバックつきのエージェント実行
    - RateLimitError: 指数バックオフでリトライ
    - APITimeoutError: リトライ → 失敗時は人間エスカレーション
    """
    for attempt in range(max_retries):
        try:
            result = await agent.ainvoke(
                {"messages": [{"role": "user", "content": user_input}]},
                config={"recursion_limit": 10}  # 無限ループ防止
            )
            return result["messages"][-1].content

        except RateLimitError:
            wait = 2  attempt  # 1s → 2s → 4s
            await asyncio.sleep(wait)
            continue

        except APITimeoutError:
            if attempt == max_retries - 1:
                # 最終フォールバック: 人間オペレーターへ
                return "申し訳ありません。現在システムが混雑しています。担当者におつなぎします。"
            await asyncio.sleep(1)
            continue

        except Exception as e:
            # 予期しないエラーはログに残して人間対応
            print(f"[ERROR] 予期しないエラー: {type(e).__name__}: {e}")
            return "システムエラーが発生しました。担当者に報告します。"

    return "一時的な問題が発生しています。しばらく後に再試行してください。"

Phase 4：本番展開（1〜2ヶ月）

本番展開で最も重要なのは、「エージェントを信じすぎないこと」です。どんなに精度が高くても、高リスクな意思決定（金銭の移動、外部への通知送信など）には必ず人間のレビューを挟む設計にしてください。

CI/CDへの自動評価統合

本番エージェントをコードと同様にCI/CDで管理します。プロンプトやツール定義を変更したらデプロイ前に自動評価が走る仕組みが理想です。


# .github/workflows/agent-eval.yml
# GitHub Actions での自動評価パイプライン

name: Agent Evaluation

on:
  pull_request:
    paths:
      - 'agents/'
      - 'prompts/'
      - 'tools/'

jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run agent evaluation
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          LANGFUSE_SECRET_KEY: ${{ secrets.LANGFUSE_SECRET_KEY }}
        run: |
          python scripts/evaluate_agent.py 
            --test-cases tests/agent_eval_cases.json 
            --min-success-rate 0.80 
            --max-avg-latency 5.0 
            --fail-on-regression  # 前回より精度が下がったらCIを落とす

      - name: Upload evaluation report
        uses: actions/upload-artifact@v4
        with:
          name: eval-report
          path: reports/agent_eval_*.json

コスト管理：トークン消費の上限設定

コスト爆発はエージェント特有のリスクです。特に長いツールチェーンでは、1リクエストが予想の10倍のトークンを消費することがあります。


# 動作環境: Python 3.11+, langgraph>=0.2.0
# コスト管理: トークン上限 + アラートの実装例
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

from langchain_openai import ChatOpenAI
from langchain_core.callbacks import BaseCallbackHandler

class TokenBudgetCallback(BaseCallbackHandler):
    """1セッションのトークン消費を監視し、上限超過時に警告"""

    def __init__(self, max_tokens: int = 50000):
        self.max_tokens = max_tokens
        self.total_tokens = 0

    def on_llm_end(self, response, **kwargs):
        usage = response.llm_output.get("token_usage", {})
        self.total_tokens += usage.get("total_tokens", 0)

        if self.total_tokens > self.max_tokens * 0.9:
            print(f"[WARNING] トークン消費が上限の90%に達しました: {self.total_tokens}/{self.max_tokens}")

        if self.total_tokens > self.max_tokens:
            raise RuntimeError(f"トークン上限超過: {self.total_tokens} > {self.max_tokens}")

# 使い方
budget_callback = TokenBudgetCallback(max_tokens=20000)
result = agent.invoke(
    {"messages": [{"role": "user", "content": user_input}]},
    config={"callbacks": [budget_callback], "recursion_limit": 15},
)

本番運用の品質指標（KPI）

定期的にモニタリングすべき6つの指標です。

指標 定義 目標値の目安
タスク完了率（Success Rate） エラーなく意図したゴールに到達した割合 90%以上
ツール使用精度（Tool Use Accuracy） 適切なツールを選択・実行できた割合 85%以上
平均レイテンシ タスク開始〜完了の平均時間 ユースケース要件次第
1タスクあたりコスト 平均トークン消費量 × 単価 事業収支に合う範囲で設定
エスカレーション率 人間介入が必要になった割合 20%以下（ユースケース依存）
自己修復率（Error Recovery Rate） エラー後に自律回復できた割合 60%以上

Phase 5：最適化・スケール（継続）

本番稼働が安定したら、改善のサイクルを回し続けます。このフェーズに「完了」はありません。

プロンプトA/Bテストの組み込み


# 動作環境: Python 3.11+
# システムプロンプトのA/Bテスト実装例
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

import random

PROMPTS = {
    "control": (
        "あなたはカスタマーサポートエージェントです。"
        "ナレッジベースで回答できない場合はエスカレーションしてください。"
    ),
    "variant_a": (
        "あなたはカスタマーサポートエージェントです。"
        "まず質問の意図を確認してから回答してください。"
        "ナレッジベースで回答できない場合はエスカレーションしてください。"
    ),
}

def get_prompt_variant(user_id: str) -> tuple[str, str]:
    """ユーザーIDで一貫したバリアント割り当て（ランダムだとセッション間でぶれる）"""
    variant = "control" if int(user_id[-1]) < 5 else "variant_a"
    return variant, PROMPTS[variant]

# 実行時
variant_name, system_prompt = get_prompt_variant(user_id="user_12345")

# Langfuseにバリアント情報を記録（後で集計できるよう）
langfuse.trace(
    name="support_agent",
    metadata={"ab_variant": variant_name, "user_id": user_id}
)

RAGシステムの品質向上

エージェントの精度向上において、プロンプト改善と同等かそれ以上に効果的なのが、RAGのナレッジベース品質の改善です。以下の3点を月次でチェックしてみてください。

  • ヒット率の低いクエリを抽出し、対応するドキュメントを追加する
  • チャンクサイズを調整する（長すぎると不要情報が混入、短すぎるとコンテキストが切れる）
  • Rerankerを導入して検索結果の精度を上げる（cohere-rerank等）

セキュリティと安全運用チェックリスト

本番エージェントには必ずセキュリティ対策を組み込んでください。Gravitee.ioの「State of AI Agent Security 2026」レポートによると、88%の組織がAIエージェント関連のセキュリティインシデントを経験しており、最多はプロンプトインジェクション攻撃です。

チェック項目 対策
プロンプトインジェクション ユーザー入力をシステムプロンプトに直接埋め込まない。入力のサニタイゼーション実施
APIキー管理 コードにハードコード禁止。環境変数またはSecret Manager（AWS Secrets Manager等）で管理
ツールの権限範囲 最小権限の原則。DB書き込みツールは読み取り専用と分ける
出力フィルタリング PII（個人情報）が応答に含まれていないかチェックするガードレールを設置
ループ検出 `recursion_limit` を必ず設定（LangGraph: デフォルト25）
Human-in-the-Loop 金銭移動・外部通知など高リスク操作には人間の承認ステップを必須化 

# プロンプトインジェクション対策の基本実装例
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

import re

INJECTION_PATTERNS = [
    r"ignore (previous|above|all) instructions?",
    r"you are now",
    r"act as",
    r"forget (your|the) (instructions|system prompt)",
    r"jailbreak",
]

def sanitize_user_input(text: str) -> str:
    """明らかなプロンプトインジェクション試行を検出してブロック"""
    for pattern in INJECTION_PATTERNS:
        if re.search(pattern, text, re.IGNORECASE):
            raise ValueError("入力にセキュリティ上の問題が検出されました")
    # HTMLタグを除去（ツール経由でHTMLが注入されるケース対策）
    text = re.sub(r'<[^>]+>', '', text)
    return text.strip()

【要注意】よくある失敗パターンと回避策

失敗1：PoC成功を過信して本番展開を急ぐ

❌ PoCで85%の精度が出たので、すぐに全社展開

⭕ パイロット（5〜20%展開）で3ヶ月以上運用し、本番特有の問題を先に洗い出す

なぜ重要か: PoCのテストケースは作成者の思い込みが入ります。実ユーザーは必ず想定外の使い方をします。パイロット段階で発見できなかった問題は、本番で規模拡大されて顕在化します。

失敗2：ツール選択ミスによる無限ループ

❌ ツールを10個定義して全部使えるようにする

⭕ ツールは3〜5個から始め、目的が重複するツールは統合する。必ず `recursion_limit` を設定する

なぜ重要か: ツールが多すぎると、エージェントは適切なツールを選べずにループします。ツールの説明文（description）が曖昧だと特に起きやすいです。

失敗3：コスト爆発

❌ 長いエージェントチェーンでコスト試算なしに本番展開

⭕ Phase 2でトークン消費のベースラインを計測し、トークン上限コールバックを必ず実装する

なぜ重要か: エージェントは1リクエストで複数回LLMを呼ぶため、通常のChat APIと比べてトークン消費が10倍以上になることがあります。

失敗4：過度な自律性を与える

❌ エージェントに「最善の判断で全て実行して」と指示する

⭕ 高リスクな操作（外部API呼び出し、DB更新、メール送信）には `interrupt_before` を使ってHuman-in-the-Loopを挟む

なぜ重要か: エージェントは「意図した通りに」ではなく「指示通りに」動きます。曖昧な指示は曖昧な実行を生みます。人間の承認なしに重要な決定をしてしまうリスクは、常にゼロにはなりません。

失敗5：モニタリング不在での本番運用

❌ 公開後に「なんか精度が落ちた気がする」で気づく

⭕ LangfuseやArize等でトレーシングを最初から組み込み、KPIの自動アラートを設定する

なぜ重要か: LLMの応答は非決定的であり、同じエージェントでも時間経過で精度が変化します。モデルのアップデート、ナレッジベースの劣化、ユーザーの使い方の変化など、複合的な要因を早期に検知するにはトレーシングが不可欠です。

参考・出典

まとめ：今日から始める3つのアクション

  1. 今日やること: 「即効セットアップ3選」のコードのうち1つを自分の環境でコピペして動かしてみる。まずOpenAI Agents SDKからが最もハードルが低いです。
  2. 今週中: Phase 1のフレームワーク選定表を参照して、自社のユースケースに最適なフレームワークを1つ選び、PoCのスコープと評価指標を書き出す。
  3. 今月中: Phase 2のPoC開発を完了させ、タスク完了率・レイテンシ・トークン消費量の3指標を計測する。この数字があるとPhase 3の計画が格段に立てやすくなります。

あわせて読みたい:

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。
100社以上の企業向けAI研修・導入支援。著書累計3万部突破。
SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

AIエージェント実装のご相談は お問い合わせフォーム からお気軽にどうぞ。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約 支援実績を見る

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年3月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事

推論モデルは本音を言わない｜Anthropic研究が示すCoTの信頼限界 ニュース

推論モデルは本音を言わない｜Anthropic研究が示すCoTの信頼限界

Anthropicの研究「Reasoning Models Don't Alwa...

10分で読める
Claude Code /config完全ガイド｜モデル切替とAuto-Compactを使いこなす AIエージェント入門

Claude Code /config完全ガイド｜モデル切替とAuto-Compactを使いこなす

Claude Codeの/configコマンドが制御する設定を全解説。モデル選択...

7分で読める
Claude Code Channelsの仕組み解説｜Webhookとチャット橋渡しの使い分け AIエージェント入門

Claude Code Channelsの仕組み解説｜Webhookとチャット橋渡しの使い分け

Claude Code Channelsとは何か、どう動くのか。MCP経由のチャ...

9分で読める