結論: OpenAI Agents SDK の2026年4月大型アップデートで、Sandbox実行・Session Persistence・モデルネイティブHarnessが加わり、マルチエージェントシステムを本番環境で動かす基盤が整いました。LangGraph・CrewAIとの比較も踏まえ、正しいフレームワーク選択ができるようになります。
この記事の要点:
- Agents SDK 2026年4月更新の3大機能（Sandbox / Harness / Session Persistence）を実装コード付きで解説
- Handoff・マルチエージェントオーケストレーションを30行以内で実装する最短ルート
- LangGraph・CrewAI との選定マトリクス（30軸比較）で「どれを選ぶべきか」に答える
対象読者: Python でAIエージェントを本番導入しようとしている開発者・テックリード
読了後にできること: Handoff を使ったマルチエージェントシステムを今日中にローカルで動かせる
「エージェントを作ったのに、本番で何が起きているか全然わからない…」
先日、研修先のスタートアップ（従業員30名・SaaSプロダクト開発）でこんな相談を受けました。OpenAI Agents SDK で社内向けカスタマーサポートbotを作り、デモ環境では完璧に動いたのに、本番に投入したら何をしているか追跡できず、エラーが出るたびにログをひっくり返す羽目になった、というのです。
正直に言うと、これは2025年時点のAgents SDKなら避けにくい問題でした。でも2026年4月の大型アップデートで、この状況は劇的に変わりました。Tracing・Sandbox・Session Persistenceが揃い、「エージェントが何をしているか見える」「コンテナが落ちても再開できる」「機密情報がサンドボックス外に漏れない」という3つを同時に達成できるようになったんです。
この記事では、Agents SDKのマルチエージェント実装・2026年4月の新機能・LangGraph/CrewAIとの比較まで、開発者目線で全部書きます。コピペできるコードを10個以上用意したので、今日中に手を動かせます。
まず5分で動かす：Handoffマルチエージェント
「まず動かしてみる」が最短学習ルートです。以下のコードで、トリアージ→専門エージェントへのHandoffが体験できます。
pip install openai-agents
import asyncio
from agents import Agent, Runner
# 専門エージェント1：請求担当
billing_agent = Agent(
name="BillingAgent",
instructions=(
"あなたは請求・支払いの専門家です。"
"請求書の確認、支払い方法の変更、返金対応を担当します。"
"不明点があれば最初に質問してから作業を開始してください。"
),
model="gpt-4o"
)
# 専門エージェント2：技術サポート担当
tech_agent = Agent(
name="TechSupportAgent",
instructions=(
"あなたは技術サポートの専門家です。"
"バグ報告・機能の使い方・API連携の質問を担当します。"
"仮定した点は必ず'仮定'と明記してください。"
),
model="gpt-4o"
)
# トリアージエージェント：振り分け役
triage_agent = Agent(
name="TriageAgent",
instructions=(
"あなたはカスタマーサポートの一次窓口です。"
"ユーザーの質問内容を判断し、適切な専門エージェントに引き継いでください。"
"請求・支払いに関する質問はBillingAgent、"
"技術的な質問はTechSupportAgentに handoff してください。"
),
handoffs=[billing_agent, tech_agent],
model="gpt-4o"
)
async def main():
result = await Runner.run(
triage_agent,
"先月の請求額が間違っているようです。確認してもらえますか？"
)
print(result.final_output)
asyncio.run(main())
これだけです。30行でトリアージ→専門エージェントへのHandoffが動きます。研修先でこのコードを見せると、「え、こんなに短いんですか」と驚かれることが多いんですが、Agents SDKの設計哲学がまさにここにあります。
2026年4月の3大アップデートを徹底解説
2026年4月15日、OpenAIは「The Next Evolution of the Agents SDK」を発表しました。既存の完全ガイドで解説した基礎部分（Responses API移行、4コアコンセプト）に加え、本番運用に直結する3つの大機能が追加されています。
1. Sandbox Agents：コード実行を安全に隔離する
Sandbox Agentsは、エージェントがファイル操作・コマンド実行・コード編集を「汚染されたコンテナ内」で行う機能です。モデルが生成したコードが実行されても、ホスト環境のクレデンシャルには触れられません。
from agents import Agent, Runner
from agents.sandbox import E2BSandbox # E2B統合例
# E2Bサンドボックスを使うエージェント
code_agent = Agent(
name="CodeAnalysisAgent",
instructions=(
"ユーザーが提供したPythonコードを実行・分析します。"
"セキュリティリスクのあるコードは実行前に警告してください。"
"数字と固有名詞は根拠（出典/計算式）を添えてください。"
),
model="gpt-4o",
# sandbox=E2BSandbox() # 本番ではサンドボックスを指定
)
対応サンドボックスプロバイダーは現時点で7社です: Blaxel、Cloudflare、Daytona、E2B、Modal、Runloop、Vercel。自社インフラのコンテナも持ち込み可能です。
セキュリティ設計の核心は「Harnessとサンドボックスの分離」です。認証コンテキスト（APIキー・DBクレデンシャルなど）はHarness側に保持され、モデル生成コードが動くサンドボックス側には一切渡りません。プロンプトインジェクションやデータ流出を前提とした設計になっているのが、企業導入において大きな安心材料になります。
2. Session Persistence：コンテナ障害でも会話が続く
長時間タスクの最大の敵は「コンテナが突然落ちる」ことです。Session Persistenceは、エージェントの状態をスナップショットして、新しいコンテナで再ハイドレーションします。
from agents import Agent, Runner
from agents.sessions import DatabaseSession # セッション永続化
# セッション永続化付きエージェント
long_task_agent = Agent(
name="ResearchAgent",
instructions=(
"長期リサーチタスクを担当します。"
"タスクの進捗を定期的にまとめてください。"
"未完のタスクは次回起動時に引き継ぎます。"
),
model="gpt-4o"
)
# セッションIDを指定してRunnerを実行
# 同じsession_idを使うと前回の会話コンテキストが引き継がれる
async def run_with_session(session_id: str, prompt: str):
result = await Runner.run(
long_task_agent,
prompt,
# session=DatabaseSession(session_id=session_id) # 本番設定
)
return result.final_output
これで何が変わるかというと、「1時間かかるリサーチタスクをエージェントに任せて、途中でインフラ障害が起きても再開できる」ようになります。顧問先の一社で、夜間バッチ処理をAgents SDKで構築したチームがいましたが、まさにこのSession Persistenceがなくて途中から作り直しになる、という問題を経験していました。
3. Model-Native Harness：メモリ・ツール・オーケストレーションを一元管理
新しいHarnessはCodexライクなファイルシステムツールを内蔵し、メモリ管理・サンドボックス認識オーケストレーション・標準化された統合プリミティブを提供します。
重要な注意点: 2026年4月時点で、Sandbox・Harness・Code Modeの新機能はPythonのみ対応です。TypeScriptサポートは後日公開予定とアナウンスされています。
Handoff vs. as_tool：2つのマルチエージェントパターン
Agents SDKでマルチエージェントを組む方法は2通りあります。どちらを使うかで設計思想が変わってきます。
パターン1：Handoff（制御の委譲）
トリアージエージェントが「もうあとはよろしく」と専門エージェントに制御を渡すパターンです。
from agents import Agent, Runner, handoff
# コンテキストを引き継いでHandoff
escalation_agent = Agent(
name="EscalationAgent",
instructions="クレーム対応の専門家。誠実かつ迅速に解決策を提示します。",
model="gpt-4o"
)
support_agent = Agent(
name="SupportAgent",
instructions=(
"一般的なサポートを担当します。"
"解決困難なクレームはEscalationAgentにHandoffしてください。"
),
handoffs=[
handoff(
escalation_agent,
tool_name_override="escalate_to_specialist",
tool_description_override="深刻なクレームや補償が必要な案件を専門チームに引き継ぐ"
)
],
model="gpt-4o"
)
Handoffの特徴: 制御が渡ったら元のエージェントは終了します。バトンタッチ型で、シンプルな振り分けロジックに向いています。
パターン2：as_tool（エージェントをツールとして呼ぶ）
マネージャーエージェントが専門エージェントを「ツール」として呼び出し、結果を受け取って次の判断をするパターンです。
from agents import Agent, Runner
# 専門エージェントを定義
sentiment_agent = Agent(
name="SentimentAnalyzer",
instructions="テキストの感情分析を行い、Positive/Negative/Neutralで返してください。",
model="gpt-4o-mini" # 分析タスクはコスト低いモデルで
)
summary_agent = Agent(
name="Summarizer",
instructions="テキストを3行以内で要約してください。",
model="gpt-4o-mini"
)
# マネージャーエージェントが両方をツールとして使う
manager_agent = Agent(
name="AnalysisManager",
instructions=(
"レビューテキストを受け取り、感情分析と要約を並行して実施し、"
"総合的なインサイトを提供してください。"
),
tools=[
sentiment_agent.as_tool(
tool_name="analyze_sentiment",
tool_description="テキストの感情（Positive/Negative/Neutral）を分析する"
),
summary_agent.as_tool(
tool_name="summarize_text",
tool_description="テキストを3行以内で要約する"
)
],
model="gpt-4o"
)
async def analyze_review(review_text: str):
result = await Runner.run(manager_agent, review_text)
return result.final_output
as_toolの特徴: 制御はマネージャーに残ります。複数の専門エージェントの結果を統合したい場合に最適です。
研修でよく聞かれるのが「HandoffとasToolどっちを使えばいい？」という質問です。シンプルな答えは、「振り分け型ならHandoff、統合型ならasTool」です。カスタマーサポートの一次振り分けはHandoff、複数エージェントの分析結果を統合するオーケストレーターはasToolが合っています。
Tracing：エージェントの「見える化」を実装する
Agents SDKの組み込みTracingは、デフォルトで有効です。LLM生成・ツール呼び出し・Handoff・Guardrails・カスタムイベントを全て記録します。
from agents import Agent, Runner, trace
# コンテキストマネージャーでトレースに名前をつける
async def run_with_tracing():
with trace("customer_support_workflow"):
result = await Runner.run(
triage_agent,
"プランのアップグレード方法を教えてください"
)
return result.final_output
# カスタムトレースプロセッサーでLangfuseに送る例
from agents.tracing import add_trace_processor
class LangfuseProcessor:
def process_trace(self, trace_data):
# Langfuse SDK でエクスポート
pass
add_trace_processor(LangfuseProcessor())
エコシステム統合: Weights & Biases、Arize-Phoenix、MLflow、Langfuse、LangSmith、Datadog、PostHog を含む25+のプラットフォームにコミュニティ製プロセッサーで接続できます。
Tracingで収集できる情報はこれだけです:
- どのエージェントがいつ起動したか
- どのツールが呼ばれ、何秒かかったか
- Handoffがいつ起きたか
- Guardrailsのチェック結果
- LLM生成の入出力（プライバシー設定で無効化可能）
冒頭の研修先スタートアップが直面していた「本番で何が起きているかわからない」問題は、まさにTracingを設定していなかったことが原因でした。設定自体は5行でできるので、最初から入れておくことを強くお勧めします。
Guardrails：入出力バリデーションを本番仕様で実装する
Guardrailsは入力検証と出力検証の2種類があります。デフォルトでは並列実行（エージェントと同時にバリデーション）ですが、コスト最適化のためブロッキングモードに切り替えることもできます。
from agents import Agent, Runner, input_guardrail, output_guardrail
from agents.guardrails import GuardrailFunctionOutput, RunContextWrapper, TResponseInputItem
from agents.models.interfaces import MessageOutput
# 入力Guardrail：機密情報を含むプロンプトをブロック
@input_guardrail
async def block_sensitive_input(
ctx: RunContextWrapper,
agent: Agent,
input: str | list[TResponseInputItem]
) -> GuardrailFunctionOutput:
# パスワード・APIキーのような機密情報をブロック
sensitive_keywords = ["password", "api_key", "secret", "token"]
input_text = input if isinstance(input, str) else str(input)
has_sensitive = any(kw in input_text.lower() for kw in sensitive_keywords)
return GuardrailFunctionOutput(
output_info={"detected_sensitive": has_sensitive},
tripwire_triggered=has_sensitive
)
# 出力Guardrail：個人情報の漏洩を防ぐ
@output_guardrail
async def prevent_pii_output(
ctx: RunContextWrapper,
agent: Agent,
output: MessageOutput
) -> GuardrailFunctionOutput:
import re
# メールアドレスパターンを検出
email_pattern = r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b'
output_text = str(output)
has_pii = bool(re.search(email_pattern, output_text))
return GuardrailFunctionOutput(
output_info={"has_pii": has_pii},
tripwire_triggered=has_pii
)
# Guardrails付きエージェント
safe_agent = Agent(
name="SafeAgent",
instructions="ユーザーの質問に答えてください。個人情報は出力しないでください。",
input_guardrails=[block_sensitive_input],
output_guardrails=[prevent_pii_output],
model="gpt-4o"
)
# Guardrails違反時の例外ハンドリング
from agents.exceptions import InputGuardrailTripwireTriggered, OutputGuardrailTripwireTriggered
async def safe_run(user_input: str):
try:
result = await Runner.run(safe_agent, user_input)
return result.final_output
except InputGuardrailTripwireTriggered:
return "申し訳ありません。入力内容に問題が検出されました。"
except OutputGuardrailTripwireTriggered:
return "申し訳ありません。回答内容を安全のため差し替えました。"
ツールレベルでもGuardrailsを設定できます。特にマルチエージェント構成で、特定のツール呼び出しだけを厳密にバリデートしたい場合に便利です。
from agents import function_tool
@function_tool(
tool_input_guardrails=[block_sensitive_input], # ツール呼び出し前に実行
tool_output_guardrails=[prevent_pii_output] # ツール実行後に実行
)
def query_customer_database(customer_id: str) -> str:
"""顧客データベースを検索します。"""
# 実際のDB検索処理
return f"顧客ID {customer_id} のデータを取得しました"
注意点: ツールGuardrailsはHandoff・ホスト型ツール・組み込み実行ツールには適用されません。
Agents SDKのドキュメント（公式）より: 「Guardrails run input validation and safety checks in parallel with agent execution, and fail fast when checks do not pass.」（Guardrailsはエージェント実行と並列で動作し、チェックが通らなければ即座に停止します）
LangGraph・CrewAI との徹底比較
「どのフレームワークを選べばいい？」は研修で最も多い質問の一つです。30軸で比較した結果を整理すると、3者の特徴は明確に分かれます。
| 比較軸 | OpenAI Agents SDK | LangGraph | CrewAI |
|---|---|---|---|
| アーキテクチャ | エージェントループ + Handoff | 有向グラフ（ノード・エッジ） | ロールベースのクルー |
| 学習コスト | 低（50行で動く） | 高（グラフ設計の概念理解必要） | 中（宣言的APIでわかりやすい） |
| 状態永続化 | Session Persistenceで対応（2026年4月〜） | 強力（タイムトラベルデバッグ付き） | タスク出力の順次引き渡し |
| 長時間タスク | Sandboxで改善（2026年4月〜） | 最強（チェックポイント必須環境に最適） | 部分対応 |
| モデル対応 | Chat Completions互換なら可（2026年4月〜） | 完全モデル非依存 | 完全モデル非依存 |
| TypeScript | 基本機能はOK、新機能はPythonのみ | LangGraph.js あり | 部分対応 |
| Tracing | 組み込み（25+プラットフォーム統合） | LangSmith（有料） | サードパーティ依存 |
| Guardrails | ファーストクラスの概念 | カスタム実装 | カスタム実装 |
| 料金 | モデル使用量のみ（SDK自体は無料） | OSS（LangSmithは有料） | OSS（エンタープライズ版有料） |
選択基準：3行で判断する
- OpenAI Agents SDKを選ぶ場合: GPT-4o/GPT-4o-miniをメインモデルにする、開発スピード重視、カスタマーサポート・コード生成・単一ドメインのエージェント
- LangGraphを選ぶ場合: 複雑な分岐フロー・ヒューマンインザループが必要、金融・医療のような規制業界、チェックポイントと再開が非交渉
- CrewAIを選ぶ場合: リサーチチーム・コンテンツ制作パイプラインのような「役割分担のチーム」を模倣したい、非エンジニアがエージェント定義に関わる
個人的な観点で言うと、2026年4月のアップデートでAgents SDKとLangGraphの差が縮まりました。Session PersistenceとSandboxが加わったことで、「GPT-4oで固める」ならAgents SDKで大半のユースケースをカバーできるようになっています。一方で、モデル非依存が必要な場合・複雑な状態遷移管理が必要な場合はLangGraphの優位性は依然として高いです。
AIエージェントの基本概念や導入ステップについては、AIエージェント導入完全ガイドで体系的にまとめています。フレームワーク選定の前提知識として参考にしてください。
動的instructions：コンテキストに応じた指示を生成する
本番環境では、エージェントのinstructionsを実行時に動的に生成したい場面が多いです。ユーザーの権限・プラン・過去の会話履歴などに応じてプロンプトを変えることで、精度が大幅に上がります。
from agents import Agent, Runner, RunContextWrapper
from dataclasses import dataclass
@dataclass
class UserContext:
user_id: str
plan: str # "free" | "pro" | "enterprise"
language: str # "ja" | "en"
is_verified: bool
def dynamic_instructions(ctx: RunContextWrapper[UserContext], agent: Agent) -> str:
user = ctx.context
base_instructions = f"""
あなたは{user.language}で応答するカスタマーサポートエージェントです。
ユーザーID: {user.user_id}
プラン: {user.plan}
"""
if user.plan == "enterprise":
base_instructions += "企業向けの詳細なSLA情報を提供できます。"
elif user.plan == "pro":
base_instructions += "プロプランの全機能についてサポートします。"
else:
base_instructions += "無料プランの制限について正直に伝えてください。"
if not user.is_verified:
base_instructions += "\n本人確認が完了していないため、アカウント変更操作はできません。"
return base_instructions
context_aware_agent = Agent(
name="ContextAwareAgent",
instructions=dynamic_instructions, # 関数を渡す
model="gpt-4o"
)
# ユーザーコンテキストを渡してRunnerを実行
async def handle_user_query(user: UserContext, query: str):
result = await Runner.run(
context_aware_agent,
query,
context=user # RunContextWrapperに渡る
)
return result.final_output
これは研修でも「こんな使い方があったのか」と驚かれることが多い実装パターンです。同じエージェントでも、ユーザーのプランや権限に応じて振る舞いを変えられるので、マルチテナントのSaaSプロダクトと相性が抜群です。
Structured Output：型安全なエージェント出力
本番でエージェントの出力を後処理するなら、Pydanticモデルを使ったStructured Outputが必須です。
from agents import Agent, Runner
from pydantic import BaseModel
from typing import Optional, List
class SupportTicket(BaseModel):
category: str # "billing" | "technical" | "general"
priority: str # "low" | "medium" | "high" | "critical"
summary: str
required_action: str
estimated_resolution_hours: Optional[int]
related_issues: List[str] = []
ticket_classifier = Agent(
name="TicketClassifier",
instructions=(
"ユーザーのサポートリクエストを分析し、"
"カテゴリ・優先度・対応方針を分類してください。"
"不足情報があれば estimated_resolution_hours は null にしてください。"
),
output_type=SupportTicket, # Pydanticモデルを指定
model="gpt-4o"
)
async def classify_ticket(user_message: str) -> SupportTicket:
result = await Runner.run(ticket_classifier, user_message)
ticket = result.final_output # SupportTicketインスタンスが返る
# 型安全にアクセスできる
if ticket.priority == "critical":
print(f"緊急対応が必要: {ticket.summary}")
return ticket
【要注意】よくある失敗パターンと回避策
失敗1：Handoffが無限ループする
❌ よくある間違い：エージェントAがBにHandoff → BもAにHandoffを持っている → 会話がループ
⭕ 正しいアプローチ：Handoffは一方向に設計する。双方向が必要なら as_tool パターンに切り替える。
# NG: 双方向Handoffはループのリスク
agent_a = Agent(name="A", handoffs=[agent_b])
agent_b = Agent(name="B", handoffs=[agent_a]) # 危険
# OK: トリアージ→専門という一方向フロー
triage = Agent(name="Triage", handoffs=[specialist_a, specialist_b])
specialist_a = Agent(name="SpecialistA") # handoffsなし
研修でAgents SDKを初めて触るチームが最初にハマるのがこのループ問題です。「なぜか会話が終わらない」と言われたら、まずHandoffの方向性を確認してください。
失敗2：Guardrailsのtripwireを捕捉しない
❌ よくある間違い：Guardrailsを設定したのに例外ハンドリングを書いていない → 本番でUnhandled Exceptionが発生する
⭕ 正しいアプローチ：必ず InputGuardrailTripwireTriggered と OutputGuardrailTripwireTriggered をtry-exceptで捕捉する（上記の実装例を参照）。
失敗3：本番でTracingを無効化して何もわからなくなる
❌ よくある間違い：「パフォーマンスが落ちる気がする」とTracingをオフにする → エラー原因が追跡不能になる
⭕ 正しいアプローチ：Tracingは基本的にオンのまま。機密データが気になる場合は RunConfig.trace_include_sensitive_data=False でLLMの入出力だけ除外する。
from agents import RunConfig
# 機密データを除外しつつTracingを維持
result = await Runner.run(
agent,
user_input,
run_config=RunConfig(
trace_include_sensitive_data=False # LLM入出力を記録しない
# tracing_disabled=True # これは最終手段
)
)
失敗4：全エージェントにgpt-4oを使ってコストが爆発する
❌ よくある間違い：全エージェントのmodelを “gpt-4o” にして請求額が想定の10倍になる
⭕ 正しいアプローチ：分類・要約・検索など単純タスクには “gpt-4o-mini” を使い、複雑な推論・最終回答生成だけ “gpt-4o” を使う。モデルごとの料金差は大きい（入力: gpt-4o $2.50/1Mトークン vs gpt-4o-mini $0.15/1Mトークン、参照日: 2026-05-05）。
# コスト最適化の構成例
triage_agent = Agent(
name="TriageAgent",
model="gpt-4o-mini", # 振り分けは安いモデル
handoffs=[premium_agent]
)
premium_agent = Agent(
name="PremiumAgent",
model="gpt-4o", # 最終回答は高品質モデル
instructions="詳細で高品質な回答を提供してください。"
)
Codex Cloud との組み合わせ：コード生成エージェントの次の一手
2026年5月に正式公開された Codex Cloud は、Agents SDK の Sandbox Agents との相性が特に良いです。Codexが長時間のコード生成タスクを並列エージェントで処理し、その結果をAgents SDKのエージェントが受け取って後処理するパターンが実用的になってきました。
Codex Cloudの詳細と並列エージェント活用法は Codex Cloud完全解説 にまとめています。Agents SDKと組み合わせた開発自動化フローに興味がある方は参照してください。
また、Codex CLI を使ったローカル開発環境でのエージェント自動レビュー・Sub-agents 活用については Codex CLI Sub-agents活用ガイド も参考になります。
参考・出典
- OpenAI Agents SDK 公式ドキュメント — OpenAI（参照日: 2026-05-05）
- Guardrails — OpenAI Agents SDK — OpenAI（参照日: 2026-05-05）
- Tracing — OpenAI Agents SDK — OpenAI（参照日: 2026-05-05）
- The Next Evolution of the Agents SDK — OpenAI（2026年4月15日）
- OpenAI updates its Agents SDK to help enterprises build safer, more capable agents — TechCrunch（2026年4月15日）
- OpenAI Agents SDK vs LangGraph vs CrewAI: 2026 Matrix — DigitalApplied（参照日: 2026-05-05）
- GitHub: openai/openai-agents-python — OpenAI（参照日: 2026-05-05）
まとめ：今日から始める3つのアクション
- 今日やること: 冒頭の30行Handoffコードをローカルで動かしてみる（
pip install openai-agentsから5分） - 今週中: Tracingを設定し、自分のエージェントが何をしているか可視化する（Langfuseの無料プランで十分）
- 今月中: GuardrailsとStructured Outputを組み込み、本番環境へのデプロイを検討する
Agents SDKは2026年4月のアップデートで、「プロトタイプを作るフレームワーク」から「本番でも動く基盤」へと進化しました。正直に言うと、まだLangGraphの複雑な状態管理には及ばない部分もあります。でも、GPT-4oファミリーを使うなら、今のAgents SDKは最短で本番レベルのエージェントシステムを作れる選択肢になっています。
次の記事では「Claude API × Agents SDK互換レイヤーの実装」をテーマに、OpenAI以外のモデルをAgents SDKで使う実践的なパターンをお届けします。
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
