DEV Community: Akira

ジョブサーチ自動化：オープンソースAI活用術【転職成功ガイド】

Akira — Tue, 07 Apr 2026 09:59:00 +0000

要約

Career-Opsは、Claude Codeを本格的な就職活動コマンドセンターに変える、無料でオープンソースのボイラープレートです。A-Fスコアリングで求人を評価し、各求人情報に合わせてATSに最適化された履歴書を生成し、45以上の企業ポータルを自動的にスキャンし、すべての情報をターミナルダッシュボードで追跡します。作成者はこれを使用して740以上の求人を評価し、Head of Applied AIの役職を獲得しました。

Apidogを今すぐ試してみましょう

はじめに

多くの開発者は求人応募をスプレッドシートで管理しています。新しいタブを開き、求人情報を貼り付け、キーワードを確認し、「応募済み、結果待ち」で行を更新…。これを50回以上繰り返すと、まるで別の仕事のように感じます。

Career-Opsはこのモデルを逆転します。評価や書式設定、進捗管理の作業をあなたの代わりにClaude Codeが担当します。あなたはURLや求人情報を貼り付けるだけ。システムが履歴書を読み込み、適合性を判断し、10の側面で求人を採点、カスタマイズされたPDFを生成し、結果を記録します。応募の決定だけが、あなたの役割です。

このシステムは手当たり次第に応募するボットではありません。フィルター哲学に基づき、数百の求人から価値のある案件だけを抽出し、4.0/5未満はすべて除外します。作者自身もCareer-Opsで740以上の求人を評価し、100超のカスタム履歴書を生成し、Head of Applied AIに就任しました。このプロジェクトは1週間でGitHub 11.9kスターを獲得しています。

💡 パイプラインテストやAPIの信頼性確保が必要な場合は、Apidogのテストシナリオを活用してください。Career-Opsが求人APIに送るHTTPリクエストを本番前にすべて検証できます。詳しくは[internal: api-testing-tutorial]をご参照ください。

Career-Opsが実際にすること

Career-Opsはスタンドアロンアプリではなく、Claude Code用のボイラープレートです。リポジトリをクローンし、履歴書をマークダウンファイルで追加し、プロファイルYAMLを編集、そのディレクトリでClaude Codeを起動します。以降はスラッシュコマンド一つでパイプライン全体を実行可能です。

コアワークフロー

求人URLまたは説明を貼り付け
        |
        v
アーキタイプ検出
(LLMOps / Agentic / PM / SA / FDE / Transformation)
        |
        v
A-F評価エンジン
(cv.mdを読み込み、10の側面を採点)
        |
   +----+----+
   v    v    v
レポート  PDF  トラッカー
 .md   .pdf  .tsv

すべてがAIランタイムとしてClaude Codeを介して実行されます。システムは実際に使っているファイルを直接読み込むので、Claude側からモードや重み、スクリプトをカスタマイズできます。

14のスラッシュコマンド

Career-Opsは、単一のエントリーポイント /career-ops から14のモードを持っています。

/career-ops                 → すべてのコマンドを表示
/career-ops {求人情報JDを貼り付け}    → 完全パイプライン：評価 + PDF + トラッカー
/career-ops scan            → 45以上の企業ポータルをスキャンし新しい求人を探索
/career-ops pdf             → 求人リストに合わせたATS最適化履歴書生成
/career-ops batch           → 複数（10件以上）の求人を並列評価
/career-ops tracker         → 応募パイプラインの進捗表示
/career-ops apply           → AIで応募フォームを入力
/career-ops pipeline        → 待機中URLキューの一括処理
/career-ops contacto        → LinkedIn連絡メッセージ自動作成
/career-ops deep            → ターゲット企業の詳細調査
/career-ops training        → コースや認定資格を評価
/career-ops project         → ポートフォリオプロジェクトを評価

特に自動パイプラインがよく使われます。任意の求人URLまたは説明テキストを貼り付けるだけで、モード指定不要で完全評価が実施されます。

A-Fスコアリングエンジンの仕組み

Career-Opsの中核はA-Fスコアリングエンジンです。全求人を6つの構造化ブロックで評価します。

A: 職務概要

タイトル、チーム、経験レベル、必須スキル抽出。アーキタイプ分類で適切な評価基準を適用。
B: 履歴書の一致度

キーワード数でなく、あなたの履歴・経験と求人情報を直接比較。スキルギャップや強みを特定し、不適格要因もフラグ。
C: 職務レベル・報酬戦略

報酬ベンチマークを調査し、交渉の論拠を構築。
D: パーソナライズ

企業が何を作っているか、あなたの経験がどこにマッチするかで、具体的なカバーレターやアプローチ角度を生成。
E: 評価スコア (A-F)

上記を統合し最終スコアを出力。4.0/5未満は応募非推奨。時間の無駄な応募を減らします。
F: 面接準備 (STAR+R)

STARフレームワークで履歴書からストーリーを自動生成し、Reflection列で経験レベルを示します。ストーリーはstory-bank.mdに蓄積され再利用可能です。

さらに給与交渉スクリプトも自動生成（給与アンカー、地理的要素への反論、競合オファー活用等）。

ATSに最適化されたPDF生成

Career-OpsのPDFジェネレーターは、各求人ごとにATS最適化された履歴書を生成します。

求人内容からATSがスキャンする主要要件とキーワードを抽出
経験箇条書きをそれらキーワード中心にリライト（虚偽記載なし）
Space Grotesk/DM SansフォントHTMLテンプレートを用い、Playwright/PuppeteerでPDF化

ATSも人間も読みやすい履歴書が作成できます。MITライセンスでテンプレートは自由にカスタマイズ可能です。

# 求人リストに合わせた履歴書をPDF出力
/career-ops pdf

# または完全パイプラインで
/career-ops {求人URLまたは説明を貼り付け}

出力はoutput/ディレクトリに保存。デフォルトでgit管理外なので個人データはローカルに保持されます。

大規模なポータルスキャン

Career-Opsには45以上の企業がスキャン対象としてプリセットされています。

AIラボ: Anthropic, OpenAI, Mistral, Cohere, LangChain, Pinecone
音声AI: ElevenLabs, PolyAI, Parloa, Hume AI, Deepgram, Vapi, Bland AI
AIプラットフォーム: Retool, Airtable, Vercel, Temporal, Glean, Arize AI
LLMOps: Langfuse, Weights & Biases, Lindy, Cognigy, Speechmatics
エンタープライズ: Salesforce, Twilio, Gong, Dialpad
自動化: n8n, Zapier, Make.com
ヨーロッパ (DACH): Factorial, Attio, Tinybird, Clarity AI, Travelperk + 31のDACH企業（コミュニティ追加）

Playwrightで採用ページをクロールし、Greenhouse/Ashby/Lever/Wellfound APIも直接クエリ。portals.ymlでターゲット企業セットし、/career-ops scanで自動追加。

並列サブエージェントによるバッチ処理

大量の求人URLもバッチモードで並列評価できます。

# jds/ディレクトリにURLを配置後
/career-ops batch

内部的にはclaude -pワーカーが並列実行され、各求人を独立評価。重複除去やトラッカーマージも自動化。失敗時にはbatch/batch-runner.shでリトライ処理も可能。

20件以上の求人評価も、手動なら丸一日かかる作業が1時間以内に完了します。

Go TUIダッシュボード

応募パイプラインはdata/applications.mdにマークダウンテーブルで保存。ターミナルダッシュボード（Go/Bubble Tea/Catppuccin Mochaテーマ）が視覚的進捗管理を提供します。

cd dashboard
go build -o career-dashboard .
./career-dashboard

6つのフィルタータブ（ステータス・アーキタイプ・スコア等）
4つのソートモード
グループ/フラットビュー
レポートプレビュー遅延ロード
インラインで応募ステータス編集マークダウン直編集不要でTUIから直接操作できます。

15分でセットアップ

セットアップ手順は以下の通りです。

# 1. クローンと依存インストール
git clone https://github.com/santifer/career-ops.git
cd career-ops && npm install
npx playwright install chromium

# 2. プロファイル設定
cp config/profile.example.yml config/profile.yml
# profile.ymlを編集（氏名・場所・職種・給与・希望など）

# 3. ターゲット企業設定
cp templates/portals.example.yml portals.yml
# 企業リストを編集

# 4. 履歴書追加
# プロジェクト直下にcv.mdを作成
# 履歴書をマークダウンで記載

# 5. Claude Code起動
claude
# Claudeに以下のように指示可能
# 「アーキタイプをバックエンドエンジニアリング職に変更」
# 「5社をportals.ymlに追加」
# 「この履歴書でプロファイルを更新」

Claude側からモードやスコア重み、交渉スクリプトのカスタマイズも可能です。

自動更新システム

v1.1.0からは、システムファイル（自動更新されるスコアリングルール等）とユーザーファイル（プロファイル・履歴書等）を分離。ユーザーデータを保護しながらシステム層のみ更新可能です。

# 更新確認（セッション開始時に自動実行）
node update-system.mjs check

# 更新適用
node update-system.mjs apply

# 問題発生時のロールバック
node update-system.mjs rollback

更新前にはバックアップブランチが生成され、ユーザーファイルの非変更も検証されます。

Career-Opsが他の求職ツールと異なる点

意思決定システム

単なる応募ボットや履歴書自動書き換えツールではなく、A-Fスコアリングにより「応募しない」判断も重視します（4.0/5未満は応募しない設計）。
キーワードマッチングでなく適合性重視

キーワード数でなく、履歴書と求人の意味的な一致に基づき評価。例えば「Python経験5年」と求人にあっても、あなたが3年でも実績次第で高評価となることも。
コンテキストが多いほど精度向上

Claudeは初期状態ではあなたを知らないため、プロフィールやキャリアストーリーを追加するほど判定精度が向上します。
すべてローカル保存

履歴書・応募情報・PDF類はデフォルトでgit管理外&ローカル保存。ClaudeがAPI評価・検索以外で外部送信することはありません。

知っておくべき制限事項

Claude Code必須

Career-OpsはClaude Code専用ボイラープレート。他モデルやUIでは動作不可。Anthropicアカウントが必要です。
Playwrightの一部不安定性

企業の採用ページHTML変化で、Playwrightスキャナーが一部ポータルで動作しなくなる場合あり。標準API採用企業では安定。
初期評価の精度は要調整

最初は大まかな評価となります。プロファイルや実績を十分入力した上でスコアを活用してください。
バッチモードはAPIクレジット消費大

claude -p並列ワーカーはバッチで大量API消費するため、最初の大規模バッチ前に使用状況を確認しましょう。

AIエージェントのキャリブレーションについては[internal: how-ai-agent-memory-works]を参照してください。

対象者

Career-Opsは以下に該当する開発者・技術専門職向けです。

積極的に転職活動中で、手動管理に疲れた人
AI企業での職務を志望する人（ポータルリストもAI寄り）
大量応募ボットでなく、評価・意思決定支援にAIを使いたい人
CLIツール・YAML編集に抵抗のない人

GUI希望の非技術ユーザーや、自動応募提出を望む方には不向きです。応募の最終判断・提出は必ず手動となります。

始め方

リポジトリをクローンし、履歴書を追加し、Claudeでプロファイルを構成。1時間程度で本当に興味ある職務に対し最初の評価を実施できます。調整作業はすぐに成果をもたらします。

GitHub: https://github.com/santifer/career-ops

本プロジェクトはMITライセンスです。コミュニティからの貢献も歓迎。PR前には必ずIssueを作成してください。

結論

Career-Opsは現時点で最も包括的なオープンソース求職パイプラインです。A-Fスコアリング、ATS最適化PDF、並列バッチ処理、Go TUIダッシュボードの各機能は単体でも有用。プロファイルを厳密に調整することで、意味ある求人だけに絞って応募するワークフローが構築できます。

求職活動は「量」ではなく「情報」の問題。Career-Opsはその本質を実装するツールです。

よくある質問

Q: Career-Opsは有料ですか？

ツールは無料(MITライセンス)です。Claude APIの利用料金のみ必要。完全な評価（評価＋PDF＋トラッカー）は10,000～30,000トークン程度（Claude 3.5 Haikuの場合1回0.05ドル未満）。

Q: Claude以外のモデルは使えますか？

直接は不可。Claude Code用に設計されているため。他モデルに移植するにはスキル定義等を書き換える必要あり。

Q: ATS最適化はどのように機能していますか？

求人情報から必須スキル・キーワード抽出し、経験箇条書きを自然にリライトしPDF化。HTMLテンプレートはSpace Grotesk・DM SansフォントでATS対応済み。

Q: サポートしている求人掲示板は？

Greenhouse、Ashby、Lever、Wellfound、Workable、RemoteFrontを直接サポート。その他はPlaywrightでカスタムページをクロール。DACH/ヨーロッパ企業も31件追加済み。APIサーフェスの扱い詳細は[internal: local-vs-api-ai-models]参照。

Q: 履歴書データの安全性は？

全ファイルはローカルかつgit管理外。ClaudeのAPI呼び出し（Anthropic標準）以外は外部送信なし。データ処理詳細は[internal: claude-code]参照。

Q: 独自の企業をポータルスキャナーに追加できますか？

可能です。templates/portals.example.ymlをportals.ymlにコピーし、任意の企業を追加。Greenhouse/Ashby/Lever採用企業は自動認識、カスタムページはPlaywrightセレクターで設定可能。

Q: 完全な評価にかかる時間は？

PDF生成含む単一評価は通常2〜4分（Claude 3.5 Sonnet）。バッチモード並列化で10件でもほぼ同時間。

Q: STAR+Rフレームワークとは？

STAR（Situation, Task, Action, Result）にReflection（反省）を加えたもの。経験を単に説明するだけでなく、そこからの学びや変化も示せるため、経験豊富な候補者像を強調できます。

2026年おすすめオープンソースコーディングアシスタント：無料のCursor代替案

Akira — Tue, 07 Apr 2026 09:53:50 +0000

要点

Cursorは月額20ドル、Windsurfは月額15ドルですが、現在はエージェント型コーディングや複数ファイル編集、モデルの自由な選択などの約80％の機能を無料で提供するオープンソース代替ツールが5つ登場しています。本ガイドでは、それぞれの最適なツールの実用面、得意領域、そして選び方を解説します。

今すぐApidogを試してみよう

はじめに

1年前までは「オープンソースのコーディングアシスタント」といえば、コード補完のみのプラグインが主流でした。しかし今では、コードベースの解析、テスト生成、ターミナルコマンドの自動実行、反復処理も可能なエージェント型コーディング環境にまで進化しています。

有料ツールと無料オープンソースの間の機能差もほとんどなくなりました。Cursorはエージェント型コーディングの代表格ですが、1人月額20ドルはチーム運用にはコスト高です。Windsurf（月額15ドル）やGitHub Copilot（月額10ドル）もありますが、いずれもプロプライエタリで監査やセルフホスト不可、モデル選択も制限されます。

本記事で紹介するオープンソースツールは、モデルを自由に選べ、完全に監査・セルフホストでき、無料で利用可能です。セットアップやUXの面で多少の手間はありますが、導入の価値は十分です。

💡 注意: これらのツールはAI生成コードが呼び出すAPIのテストまではカバーしません。API統合テストにはApidogが最適です。RESTクライアントやOpenAPI仕様のエンドポイント生成後、Apidogのテストシナリオで本番前に検証できます。詳しいAPIテストワークフローは[internal: api-testing-tutorial]を参照してください。

2026年にオープンソースコーディングアシスタントが現実的になった理由

ポイントは3つあります。

モデルへのアクセス: OpenAI・Anthropic・GoogleなどのAPI経由で最新モデルが使えるようになり、Continue.devやClineなどのOSSツールでもClaude 3.5 SonnetやGPT-4o、Gemini 1.5 Proを直接利用可能です。
ローカルモデル: Ollamaの登場でQwen2.5-CoderやDeepSeek-Coder-V2、Code Llamaといった大規模モデルもローカルで手軽に動かせるようになりました。機密コードも外部流出せずAIの恩恵を受けられます。
エージェントアーキテクチャ: ClaudeのツールAPIやGPT-4oの関数呼び出しにより、ファイル操作・ターミナル実行のループをOSSでも再現できるようになりました。

最高のオープンソースコーディングアシスタント5選

1. Continue.dev

概要: VS CodeおよびJetBrains向け拡張機能で、チャットサイドバー・インライン編集・コードQ&Aなどが使えます。最も成熟したオープンソースプロジェクトです。

最適なユーザー: VS Codeから離れずにCursor的な機能を無料で使いたい開発者と、モデル選択を自分でコントロールしたいチーム。

セットアップ手順:

VS CodeマーケットプレイスからContinue.devをインストール
OpenAI, Anthropic, Gemini, またはOllamaなど任意モデルのAPIキーを追加
アカウント作成不要ですぐ利用可能

主な機能:

コードベース全体のインデックス＋コンテキスト認識型チャット
Ctrl+Iによるインライン編集
@codebaseでリポジトリ横断検索
カスタムスラッシュコマンド／コンテキストプロバイダ
20以上のLLMプロバイダ対応

制限: ターミナル実行や自律エージェントループは非対応。全変更は手動承認が必要。

費用: 無料（APIキーは自前で用意）

	Cursor	Continue.dev
価格	月20ドル	無料
VS Code対応	○	○
JetBrains対応	×	○
モデル柔軟性	限定的	完全
エージェントモード	○	部分的
用途	完全エージェント型	モデル制御の支援編集

2. Aider

概要: ターミナルでGitを直接操作する自律型コーディングエージェント。Aiderの解説をどうぞ。

最適なユーザー: ターミナル派・バックエンドエンジニア向け。CIやリモートサーバー自動化にも最適。

セットアップ手順:

pip install aider-chat
プロジェクトルートで aider --model claude-3-5-sonnet-20241022 を実行

主な機能:

Gitコミットベースの複数ファイル自動編集
Claude/GPT-4o/Gemini/ローカルモデル対応
--yesで全変更自動承認
リポジトリマップ読込によるコード構造理解
音声入力対応
組み込みベンチマーク機能（aider-bench）

制限: ターミナル専用。IDE連携・視覚的な差分確認なし。

費用: 無料（モデルAPIは従量課金）

実践例:
GitHub Actionsで失敗したテストを自動修正する:

- name: Run Aider to fix tests
  run: |
    aider --model gpt-4o \
          --message "Fix the failing tests in test_api.py" \
          --yes \
          --no-git

3. Cline

概要: VS Code拡張で、ファイル読書き・ターミナルコマンド・ウェブ閲覧・ブラウザ操作まで自律的に実行するエージェント。Clineの詳細で解説しています。

最適なユーザー: VS Code内で複数手順の自律コーディングを完結させたい方。

セットアップ手順:

VS Code Marketplaceからインストール
任意モデルのAPIキーを追加
新規タスク開始で即利用

主な機能:

読み込み／書き込み／実行／閲覧まで一貫のエージェントループ
各アクションの承認（自動or手動）切替
Claude、GPT-4o、Gemini、Bedrock、Vertex、Ollamaなど多様なモデル
タスクごとのコスト追跡
カスタムプロンプト注入

制限: 長時間タスク＋高価なモデル利用時はコスト増に注意。

費用: 無料（モデルAPIは直払い）

4. Modo

概要: 2026年4月登場の新規OSSプロジェクト。VS CodeベースのAIファーストIDE。Cursor・Kiro・Windsurfの代替狙い。

最適なユーザー: サブスク不要のAI専用IDEが欲しい方。VS Code Marketplace未掲載のため手動導入が必要。

セットアップ手順:

GitHubからクローン（github.com/mohshomis/modo）
npm install && npm run buildでビルド

主な機能:

VS Code拡張との互換性
AIチャット・インライン補完標準搭載
モデルフリー
OSSで監査・セルフホスト可

制限: 新規プロジェクトのため動作が粗削り。Marketplace未掲載。

費用: 無料

5. Void editor

概要: 拡張不要でAI機能を統合、VS Codeフォーク型のOSSエディタ。「オープンソースCursor」を目指す。

最適なユーザー: 拡張ではなくフルフォークでCursor的UXを求める開発者。

セットアップ手順:

voideditor.comからダウンロード
プロジェクトを開き、モデル設定

主な機能:

ネイティブコードベースチャット＆インデックス
インライン差分編集
AI編集セッション全体でのチェックポイント
Ollama経由ローカルモデル
VS Code拡張機能の互換

制限: VS Code本家のアップデートに遅れやすい。拡張の一部が非対応の場合あり。

費用: 無料

比較表

ツール	IDEサポート	モデルの柔軟性	エージェントモード	最適な用途	費用
Continue.dev	VS Code, JetBrains	完全（20以上対応）	部分的	支援編集・チームでのモデル制御	無料
Aider	ターミナル	完全	完全（ターミナル）	バックエンド・CI/CD自動化	無料
Cline	VS Code	完全（Claude等）	完全	VS Codeでの自律的多段階タスク	無料
Modo	VS CodeベースのIDE	完全	開発中	サブスク不要AIファーストIDE	無料
Void editor	VS Codeフォーク	完全	部分的	Cursor的UX・OSS	無料

適切なものの選び方

VS Code＋無料でCursorチャット体験: Continue.dev一択。成熟度とコミュニティ最大。
ターミナル派・バックエンド: Aider。Git統合＆CI自動化に最適。AIバックエンド構築には[internal: how-to-build-tiny-llm-from-scratch]も参考に。
完全自律エージェント型が必要: Cline。Cursorのエージェントモードに最も近いOSS。
拡張不要のAI IDE: Void editor。Modoも今後に期待。
完全なコードプライバシー: Ollama＋Qwen2.5-Coder-32B等。24GB VRAM以上のPCで本番品質のコード生成可。
チーム評価: Continue.dev・Clineは設定の共有・管理が容易。APIテストの一元化は[internal: rest-api-best-practices]参照。

ApidogがAIコーディングワークフローにどう適合するか

AIコーディングアシスタントはコード生成が得意ですが、APIの実動作検証までは行いません。RESTクライアントやOpenAPI仕様エンドポイントを生成した場合、Apidogのテストシナリオで本番デプロイ前に統合テストを自動化できます。

テストワークフロー

生成エンドポイントをApidogにインポート（URL＋メソッド貼付け、またはOpenAPI仕様から）
ハッピーパス用テストシナリオ作成（認証→主要リクエスト→レスポンス検証）
ネガティブケース追加（期限切れトークン、不正ボディ、レートリミット等）
ステージングがなければSmart MockでサードパーティAPIをシミュレート

例：GitHub APIクライアント検証

{
  "scenario": "GitHub API client verification",
  "steps": [
    {
      "name": "Create issue",
      "method": "POST",
      "url": "https://api.github.com/repos/{owner}/{repo}/issues",
      "headers": {"Authorization": "Bearer {{token}}"},
      "body": {"title": "Test issue", "body": "Created by test scenario"},
      "assertions": [
        {"field": "status", "operator": "equals", "value": 201},
        {"field": "response.number", "operator": "exists"}
      ]
    },
    {
      "name": "List issues (verify created issue appears)",
      "method": "GET",
      "url": "https://api.github.com/repos/{owner}/{repo}/issues",
      "assertions": [
        {"field": "response[0].number", "operator": "equals", "value": "{{steps[0].response.number}}"}
      ]
    }
  ]
}

5分で設定が終わり、AI生成コードで発生しがちなHTTPメソッド間違い・必須フィールド漏れ・ページネーション未対応などを検出できます。ステートフルAPIのテストについては[internal: how-ai-agent-memory-works]も参考に。

まとめ

2026年の今、オープンソースのコーディングアシスタントは十分実用的です。エージェント型コーディングや全体チャット、複数ファイル編集もCursor不要で実現可能です。Continue.dev・Aider・Clineで主要なワークフローを網羅でき、Modo/Voidも注目です。

残る課題はテストです。AI生成コードは速いがバグも生みやすいので、ApidogなどでAPI統合を検証しましょう。

よくある質問

Q: Continue.devはCursorに匹敵する？

A: チャット・インライン編集はほぼ同等。完全自律エージェント（承認なしエンドツーエンド開発）はCursorが一歩上ですが、Claude 3.5 SonnetやGPT-4oを組み合わせれば遜色ありません。

Q: ローカルモデルのみでOSSコーディングアシスタントは使える？

A: 可能です。全ツールがOllama対応で、Qwen2.5-CoderやDeepSeek-Coder-V2などをローカルで動かせます。高度なタスクはフロンティアモデル優位ですが、ボイラープレートやリファクタで十分活躍します。

Q: モデル選択のコツは？

A: Claude 3.5 Sonnetは複雑な自動タスク、GPT-4oはコード生成と関数呼び出しに強み。DeepSeek-Coder-V2はOSS界最強モデルでローカル実行向き。コスト優先ならClaude/GPT-4o、プライバシー重視や大量処理ならDeepSeek推奨。

Q: Aiderを--yesモードで使っても大丈夫？

A: 注意必須。全変更を自動承認するため、必ずブランチ運用＆マージ前に差分レビュー推奨。CI自動化には便利ですが、対話型開発では手動レビューが安心です。

Q: Kiroとは？

A: AWS製AI IDE（2025年発表）。VS CodeをベースにAWS統合を強化。OSSではありません。ModoのREADMEにも代替対象として記載あり。

Q: チームで設定共有できる？

A: 可能。Continue.devは.continue/config.json、Clineはsettings.json、Aiderは.aider.conf.ymlをVCS管理できます。チーム標準化も容易。

Q: オフライン動作は？

A: Ollama経由のローカルモデル使用なら完全オフライン可。APIベース（Claude/GPT-4o）はネット必須。Void editorやModoもローカルモデル運用が可能です。

AIエージェントのメモリの仕組み (APIでテストする方法)

Akira — Tue, 07 Apr 2026 08:04:16 +0000

要するに

AIエージェントの失敗は知能不足ではなく、「忘れる」ことに原因があります。4つのメモリタイプがどのように保存され、API挙動にどのように影響するかを理解することで、より信頼性の高いエージェントを構築し、本番投入前にバグを特定できます。

今すぐApidogを試してみる

はじめに

多くのAIエージェントが失敗する主な理由は、モデル自体の問題ではなく、メモリ層の設計や実装にあります。過去の会話を思い出せない、セッション間でコンテキストが消える、自己矛盾するエージェントの多くはメモリ設計やテスト不足が原因です。

最近登場したオープンソースのエージェントメモリシステム Hippo は、生物学的にインスパイアされた設計で人間の記憶のように短期・長期・エピソードメモリを分離管理します。このような仕組みは、エージェントメモリを後回しにしがちな開発現場でのギャップを浮き彫りにしています。

💡 Apidogのテストシナリオを使えば、ステートフルな複数ターンのエージェント会話を本番前にテストできます。APIコール間のセッション状態検証、コンテキストのアサート、Smart Mockによるメモリ障害シミュレーションも可能です。本記事後半で具体的なテスト方法を解説します。より幅広いAPIテスト方法については [internal: api-testing-tutorial] を参照してください。

AIエージェントメモリとは何か？

エージェントメモリとは、AIシステムが現在の入力を超えて情報へアクセス・保持できる仕組みです。これがなければAPIコールはすべてステートレスとなり、モデルはプロンプトと応答以外何も覚えません。

主に4つのメモリタイプが存在し、それぞれ異なる役割を果たします。

エージェントメモリの4つのタイプ

ワーキングメモリ

ワーキングメモリはエージェントの「現在のコンテキスト」、つまりプロンプト内に含まれる全データです。多くのLLMベースのエージェントでは、これがコンテキストウィンドウに該当します（例：GPT-4oは128Kトークン、Claude 3.5 Sonnetは200K、Gemini 1.5 Proは1M）。

特徴: 高速・高精度だが、トークンごとにコストが発生し上限もある。
注意点: 上限到達時は古いコンテキストが警告なく破棄され、長期タスクでバグの原因になります。

エピソード記憶

エピソード記憶は、過去のインタラクションや決定のログです。エージェントの日記のようなもの。

実装例: ベクトルDB（Chroma, Pinecone, Qdrant）やイベントログ。
取得方法: セマンティック検索で関連エピソードのみプロンプトに注入。
Hippoの特徴: タイムスタンプと減衰重み付きのシーケンスで、直近の出来事ほど取得しやすくなっています。

セマンティック記憶

セマンティック記憶は、事実やドメイン知識、ユーザーの好みなど「知っていること」を保存します。

実装例: システムプロンプトへの事前ロード、過去会話からの知識抽出（ナレッジグラフ）、RAGによる外部知識取得など。

手続き記憶

手続き記憶は「やり方」や「スキル」を保持します。行動シーケンスやツール利用パターンなど。

実装例: システムプロンプト内のfew-shot例、行動計画のテンプレートライブラリ。
注意: 実装が難しく、本番システムでは省略されがち。

実際のシステムでのメモリの保存方法

理想的には4タイプそれぞれに専用ストアを割り当てますが、現実のシステムは以下のような構成が一般的です。

コンテキストウィンドウ（ワーキングメモリ）: エージェントフレームワークが管理し、会話終了時に期限切れ。
外部ベクトルストア（エピソード+セマンティック記憶）: Chroma/Pinecone/Qdrantでインタラクションや知識チャンクの埋め込み管理。各ターンで検索・注入。
構造化DB（セマンティック+手続き記憶）: PostgreSQLやSQLiteでユーザー設定や学習済みアクションを管理。
インメモリキャッシュ（ワーキングメモリのオーバーフロー）: Redisや辞書型ストアで直近コンテキストを高速取得。

Hippoは3層メモリシステムを明示的なハンドオフロジックで実装しており、最近使われなかったワーキングメモリはエピソード記憶に統合、さらに要約されてセマンティック記憶に移行します。これは人間の記憶統合プロセスに近い設計です。

エージェントメモリがAPIの挙動に与える影響

APIを実装・利用する際、メモリ設計はAPI挙動と直結します。主な観点は以下です。

セッションID: 多くのエージェントAPIはセッションIDやスレッドIDで呼び出し間のメモリを紐付けます（例：OpenAI Assistants APIのthread_id）。ID管理ミスによるセッション混入バグに注意。
リクエストペイロードサイズ: メモリ注入型エージェントでは会話の継続でペイロードが肥大化。クライアント側のサイズ制限に注意。
取得レイテンシ: ベクトルストアクエリは1ターン50～200ms加算。応答速度への影響を計測・アサートしましょう。
失敗時の状態不整合: タスク途中でツール呼び出しが失敗した場合、部分的なログが残り次ターンでバグ化しやすい。状態チェックポイントを設ける設計が有効。

ApidogでAPI経由でエージェントメモリをテストする方法

ステートフルなエージェントAPIの本番品質テストには、複数ターン・セッション・障害ケースの検証が不可欠です。Apidogでは、これをテストシナリオで簡単に実現できます。

テスト1：コンテキストの引き継ぎ

事実を伝えるメッセージ（例：「私のプロジェクトはPostgreSQL 16を使用しています」）を /agent/chat にPOST
その事実を問うメッセージ（例：「どのデータベースを最適化すべきですか？」）を同じエンドポイントにPOST
ステップ2の応答に「PostgreSQL」が含まれることをアサート

例（擬似コード）:

// ステップ1
POST /agent/chat
{ "session_id": "A", "message": "私のプロジェクトはPostgreSQL 16を使用しています" }

// ステップ2
POST /agent/chat
{ "session_id": "A", "message": "どのデータベースを最適化すべきですか？" }

// アサーション
expect(response.message.content).toContain("PostgreSQL")

テスト2：セッション分離

異なるsession_idで上記シナリオを2回実行し、2つ目のセッションの応答に1つ目のセッションの情報が混入していないことをアサートします。これでメモリのネームスペース分離バグを検知できます。

テスト3：メモリ障害時の劣化

Smart Mockでベクトルストアのエンドポイントを503にモックし、メモリ障害状態を再現します。

エージェントがクラッシュせず適切なフォールバック応答を返すこと
「十分なコンテキストがありません」等のメッセージが含まれること
モック解除後、同じセッションで再開できること

テスト4：コンテキストウィンドウのオーバーフロー

30回以上連続でメッセージを送信し、ワーキングメモリの制限を超える状況を作ります。

context_length_exceededエラーが発生しないこと
30ターン目でもエピソード記憶から情報取得できること
response.usage のトークン数が想定範囲内であること

これらを1つのテストシナリオで連鎖させ、共有変数でセッションID等を管理できます。LLM側のコンテキストウィンドウ実装詳細については [internal: how-to-build-tiny-llm-from-scratch] も参照してください。

よくあるメモリ障害モード

サイレントなコンテキスト切り捨て: コンテキスト上限で古い履歴が消える。response.usage.prompt_tokens をアサートして制限未満であることを確認。
セッションの混入: セッション分離テストで検知可能。
古いセマンティック記憶: 過去の知識が現状と矛盾。テストで「現在の日付」やバージョン番号を明示的にチェック。
埋め込みのドリフト: 埋め込みモデル変更時の取得異常。取得コンテキストのセマンティック一致度をアサートする。
メモリインジェクション: 悪意あるユーザー入力による保存・取得操作。敵対的入力をテストスイートに含め、システムプロンプトの上書きが無視されることを確認。

APIセキュリティテスト全般は [internal: rest-api-best-practices] 参照。

結論

エージェントメモリ（ワーキング・エピソード・セマンティック・手続き）は、知的なアシスタントと単なる「忘れっぽい」アシスタントの分水嶺です。各メモリタイプの保存・取得方法を理解し、テストで明確にアサートすることで、バグの温床を可視化できます。

Hippoのようなツールはメモリアーキテクチャの進化を示しています。どんなメモリシステムでも、Apidogのテストシナリオで大規模環境特有の障害ケースまで検証しましょう。

よくある質問

Q: エージェントにメモリを追加する最も簡単な方法は？

A: 会話履歴のスライディングウィンドウ（プロンプトに直近Nターンを保持）が手軽です。短期タスク向け。長期運用にはベクトルストア＋セマンティック検索も組み合わせましょう。

Q: OpenAI Assistants APIはどのようにメモリを処理しますか？

A: サーバーサイドでスレッドオブジェクトとして会話履歴を管理。ファイル検索・コードインタープリターの添付で外部知識も利用可能。メモリ管理は抽象化されており、便利ですがデバッグは少し難しくなります。

Q: エージェントメモリに最適なベクトルデータベースは？

A: ローカル開発はChroma、本番はQdrant（セルフホスト）またはPinecone（マネージド）が推奨です。Hippoはプラグイン式ストレージをサポート。Claude Codeの独自メモリ層については [internal: claude-code] 参照。

Q: エージェントが過去インタラクションを幻覚するのを防ぐには？

A: インタラクションログをタイムスタンプや信頼度とともに構造化保存し、プロンプト注入時に明示的な引用を付与します（例：「[日付]の会話によると…」）。

Q: 実行中のエージェントなしでエージェントメモリをテストできますか？

A: 可能です。ApidogのSmart MockでセッションIDやリクエスト内容ごとに異なる応答を返すよう設定し、メモリ挙動をフロント・統合レイヤーで検証できます。

Q: 本番環境でのベクトルストレージのコストは？

A: Pinecone無料ティアは10万ベクトル/1インデックス。本番はp1.x1ポッド（100万ベクトル/768次元）で$0.096/時間程度。Qdrantセルフホストは無料。多くの場合、ストレージより埋め込み生成コストが支配的です。MCPサーバー統合との関係は [internal: what-is-mcp-server] 参照。

Q: RAGとエージェントメモリの違いは？

A: RAGは静的ナレッジベースからドキュメントを取得しますが、エージェントメモリはインタラクションを通じて動的に成長・変化します。RAGは「ドキュメントには何と書かれている？」、エージェントメモリは「このユーザーについて私は何を知っていて何をしてきたか？」に答えます。

LLMをゼロから構築する方法：得られる学び

Akira — Tue, 07 Apr 2026 04:31:53 +0000

要約

ゼロから最小限の言語モデル（LLM）を構築するためには、Pythonコードで300行も必要ありません。この構築プロセスを通じて、トークン化、アテンション、推論の仕組みを正確に理解でき、本番LLMをアプリケーションへ統合する際に、より優れたAPIコンシューマーになることができます。

Apidogを今すぐ試す

はじめに

多くの開発者は言語モデルをブラックボックスとして扱っています。テキストを入力するとトークンが出てきて、その裏側では何らかの「魔法」が起きていると思われがちです。しかしAPI統合のデバッグ、サンプリングパラメータの調整、構造化データの生成エラー解析などの場面では内部構造の理解が不可欠になります。

HackerNewsで話題となった『GuppyLM』は、Pythonでゼロから実装された870万パラメータのトランスフォーマーであり、一般的なGPUで1時間以内にトレーニング可能です。コードは1ファイルに収まり、目的はGPT-4と競うことではなく、LLMの内部動作の理解にあります。

この記事では、小規模LLMの構築方法・主要コンポーネントの役割・API活用時に内部構造を知っておくことの意義を、実装例と共に解説します。

💡 Apidogのテストシナリオを活用すると、ストリーミング応答の検証やトークン構造のアサーション、エッジケース補完のシミュレーションなどが本番クレジットを消費せずに行えます。詳細は後述。

言語モデルが「小さい」とは？

GPT-4などの本番LLMは数千億パラメータですが、「小さい」LLMは100万〜2500万パラメータが目安です。GuppyLM（870万）、nanoGPT（1億2400万）、MicroLM（100〜200万）などが該当します。

小規模LLMの特徴:

ノートPCやColabでトレーニング可能
CPUメモリで動作
重みレベルでの検査やデバッグが容易

できないこと:

複雑な推論
一貫した長文生成
本番モデル並みの知識量

価値は出力品質よりも、構築・運用を通じて得られる理解にあります。

主要コンポーネント：LLMの実際の仕組み

LLMを構成する4つの主な要素について解説します。

トークナイザー

トークナイザーは生テキストを整数IDに変換します。例: Hello, world! → [15496, 11, 995, 0]

各IDは語彙内のサブワード・文字単位に対応します。

API実装へのヒント

トークン数はレイテンシやコストに直結します。トークナイザーの分割方法を把握しておくことで、プロンプトがコンテキストウィンドウに収まり、不要な切り捨てを防げます。

GuppyLMは文字レベル、GPT-4などはBPE（5万〜10万語彙）を使用しています。

埋め込み層

埋め込み層はトークンIDを密なベクトル（例：384次元）へ変換します。意味的に近いトークンはベクトル空間でも近くなります。

さらに「位置埋め込み」を加えることで、トークン配列の順序も認識できます。

トランスフォーマーブロック

主な計算部です。各ブロックは以下2つから構成されます。

自己アテンション：各トークンが他すべてを参照し、次トークン生成の重要度を判定します。GuppyLMは6ヘッド×6層。
フィードフォワードネットワーク：アテンション後にMLP（2層）を適用。GuppyLMはReLU活性、GPT-4などはSwiGLUなども使われます。

出力ヘッド

最終ブロックの出力を語彙サイズのベクトルへ線形変換し、softmaxで確率を算出。最も高い確率のトークンを選ぶ/サンプリングして繰り返します。

Pythonで最小限のLLMを構築する

GuppyLMを参考にしたPyTorch実装例です。実行に必要な最小構成を示します。

import torch
import torch.nn as nn
import torch.nn.functional as F

# ハイパーパラメータ
VOCAB_SIZE = 256     # 文字レベル：ASCII文字ごとに1スロット
D_MODEL = 128        # 埋め込み次元
N_HEADS = 4          # アテンションヘッド数
N_LAYERS = 3         # トランスフォーマーブロック数
SEQ_LEN = 64         # コンテキストウィンドウ
DROPOUT = 0.1

class SelfAttention(nn.Module):
    def __init__(self, d_model, n_heads):
        super().__init__()
        self.n_heads = n_heads
        self.head_dim = d_model // n_heads
        self.qkv = nn.Linear(d_model, 3 * d_model, bias=False)
        self.proj = nn.Linear(d_model, d_model, bias=False)
        self.dropout = nn.Dropout(DROPOUT)

    def forward(self, x):
        B, T, C = x.shape
        qkv = self.qkv(x).reshape(B, T, 3, self.n_heads, self.head_dim)
        q, k, v = qkv.unbind(dim=2)
        q = q.transpose(1, 2)
        k = k.transpose(1, 2)
        v = v.transpose(1, 2)
        # 因果マスク: 各トークンは前のトークンのみ参照
        scale = self.head_dim ** -0.5
        attn = (q @ k.transpose(-2, -1)) * scale
        mask = torch.triu(torch.ones(T, T, device=x.device), diagonal=1).bool()
        attn = attn.masked_fill(mask, float('-inf'))
        attn = F.softmax(attn, dim=-1)
        attn = self.dropout(attn)
        out = (attn @ v).transpose(1, 2).reshape(B, T, C)
        return self.proj(out)

class TransformerBlock(nn.Module):
    def __init__(self, d_model, n_heads):
        super().__init__()
        self.attn = SelfAttention(d_model, n_heads)
        self.ff = nn.Sequential(
            nn.Linear(d_model, 4 * d_model),
            nn.ReLU(),
            nn.Linear(4 * d_model, d_model),
            nn.Dropout(DROPOUT),
        )
        self.ln1 = nn.LayerNorm(d_model)
        self.ln2 = nn.LayerNorm(d_model)

    def forward(self, x):
        x = x + self.attn(self.ln1(x))
        x = x + self.ff(self.ln2(x))
        return x

class TinyLLM(nn.Module):
    def __init__(self):
        super().__init__()
        self.embed = nn.Embedding(VOCAB_SIZE, D_MODEL)
        self.pos_embed = nn.Embedding(SEQ_LEN, D_MODEL)
        self.blocks = nn.ModuleList([
            TransformerBlock(D_MODEL, N_HEADS) for _ in range(N_LAYERS)
        ])
        self.ln_f = nn.LayerNorm(D_MODEL)
        self.head = nn.Linear(D_MODEL, VOCAB_SIZE, bias=False)

    def forward(self, idx):
        B, T = idx.shape
        tok_emb = self.embed(idx)
        pos = torch.arange(T, device=idx.device)
        pos_emb = self.pos_embed(pos)
        x = tok_emb + pos_emb
        for block in self.blocks:
            x = block(x)
        x = self.ln_f(x)
        logits = self.head(x)
        return logits

# モデル初期化とパラメータ数カウント
model = TinyLLM()
total_params = sum(p.numel() for p in model.parameters())
print(f"Model size: {total_params:,} parameters")  # 約1.2M

トレーニングループ

import torch.optim as optim

def train(model, data, epochs=100, lr=3e-4):
    optimizer = optim.AdamW(model.parameters(), lr=lr)
    model.train()
    for epoch in range(epochs):
        # data: トークンIDのテンソル, 形状 [バッチ, seq_len+1]
        x = data[:, :-1]   # 入力: 最後のトークンを除く
        y = data[:, 1:]    # ターゲット: 1つシフト
        logits = model(x)
        loss = F.cross_entropy(logits.reshape(-1, VOCAB_SIZE), y.reshape(-1))
        optimizer.zero_grad()
        loss.backward()
        optimizer.step()
        if epoch % 10 == 0:
            print(f"Epoch {epoch}, loss: {loss.item():.4f}")

推論（テキスト生成）

@torch.no_grad()
def generate(model, prompt_ids, max_new_tokens=50, temperature=1.0, top_k=10):
    model.eval()
    ids = torch.tensor([prompt_ids])
    for _ in range(max_new_tokens):
        idx_cond = ids[:, -SEQ_LEN:]  # コンテキストウィンドウに合わせて切り詰め
        logits = model(idx_cond)
        logits = logits[:, -1, :] / temperature  # 最後のトークンのみ
        # top-kサンプリング
        v, _ = torch.topk(logits, min(top_k, logits.size(-1)))
        logits[logits < v[:, [-1]]] = float('-inf')
        probs = F.softmax(logits, dim=-1)
        next_id = torch.multinomial(probs, num_samples=1)
        ids = torch.cat([ids, next_id], dim=1)
    return ids[0].tolist()

これがAI APIの挙動について教えてくれること

この構築経験から得られる、API統合時の実践的な知見を紹介します。

Temperatureとサンプリングは単なるパラメータ

Temperatureはsoftmax前のロジットをスケールします。高くすると出力がランダムに、低くすると決定論的になります。APIでtemperature=0.0指定でも、一貫性が出ない場合は仕様です（多くのAPIは完全なargmaxを避けています）。

コンテキストウィンドウは厳密で、緩やかなものではない

推論ループのidx_cond = ids[:, -SEQ_LEN:]のように、モデルはウィンドウ外のトークンを完全に破棄します。API統合時、会話履歴を全て覚えている前提は成り立ちません。

ストリーミングトークン = 推論ループの可視化

ストリーミングAPIも内部的には逐次生成と同じです。トークンごとに応答をフラッシュしているだけ。途中でストリームが切れると再開はできません（最初からやり直し）。

ロジット分布は構造化出力の難しさを示す

各ステップで語彙全体に確率が割り当てられ、例えば有効なJSON生成には全トークンが正しい必要があります。OutlinesやGuidance等はロジットを制約して文法を強制しています。APIで「構造化出力」モードがある場合、内部的にこの処理をしています。

ApidogでAI APIの統合をテストする方法

LLMの推論理解を応用して、Apidogによる堅牢なAPIテストを構築しましょう。Apidogのテストシナリオでは、複数のAPI呼び出しを連鎖させ、AI応答の構造を自動アサートできます。

ストリーミングチャットAPIのテスト例:

/v1/chat/completionsエンドポイントを含むテストシナリオを作成
レスポンスアサーション例:
- response.choices[0].finish_reason == "stop"
- response.usage.total_tokens < 4096
応答を次のターンの入力として再利用し、複数ターン会話をシミュレーション
ApidogのスマートモックでAIエンドポイントをスタブ化し、finish_reason: "length", finish_reason: "content_filter", ストリーム途中のタイムアウト等の異常系もテスト

これにより、CI実行時にAPIクレジットを消費せずAI統合テストが可能です。より広範なアプローチは[internal: api-testing-tutorial]を参照してください。

トークン数アサーションのテスト

{
  "assertions": [
    {
      "field": "response.usage.completion_tokens",
      "operator": "less_than",
      "value": 512
    },
    {
      "field": "response.choices[0].finish_reason",
      "operator": "equals",
      "value": "stop"
    },
    {
      "field": "response.choices[0].message.content",
      "operator": "not_empty"
    }
  ]
}

このテストは、1つのシナリオ内で複数モデル（GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro）に対して実行し、APIスキーマの違いによる不具合を本番前に発見できます。

応用編：量子化と推論の最適化

小さなLLMを動かした後は、本番モデル運用と直結する以下のテクニックも押さえておきましょう。

量子化

モデル重みは通常32ビットfloatですが、8ビット（INT8）や4ビット（INT4）整数に量子化可能です。これによりメモリ消費が4〜8倍削減され、精度低下も小さいです。

# 例: PyTorchでの動的INT8量子化
import torch.quantization
quantized_model = torch.quantization.quantize_dynamic(
    model, {nn.Linear}, dtype=torch.qint8
)

本番APIでも量子化モデルが使われます。同じモデル名でも品質が微妙に異なる場合、量子化の影響であることがあります。

KVキャッシュ

推論ループでは毎回全トークン分のアテンションを再計算しますが、本番環境では「キー・バリューキャッシュ」を使い、1トークンごとに必要部分だけ計算します。これによりストリーミング応答の2トークン目以降のレイテンシが大幅に下がります。

小さなLLMと本番API：それぞれの使い分け

ユースケース	小さなLLM	本番API
モデル内部の学習	最適	過剰
新しいアプリのプロトタイピング	品質不十分	最適
プライベート/機密データ	良い選択肢	プロバイダーによる
オフライン/エッジデプロイメント	実現可能	不可能
コスト重視、大量	トレードオフありで可能	規模が大きくなると高価
推論を多用するタスク	実現不可	必須

ほとんどの開発者には「本番APIを活用しつつ、内部理解のために小さなモデルを動かす」というハイブリッド運用が最適です。両者は競合ではありません。

[internal: open-source-coding-assistants-2026]では境界を曖昧にするツールについても紹介しています。

結論

小さなLLMは週末の時間で構築できます。得られるものは本番品質のシステムではなく、GuppyLMからGPT-4oまでのLLMの動作を理解するための実践的メンタルモデルです。この知識は、ストリーミング統合のデバッグやサンプリングパラメータの調整、AI APIテスト設計などに直結します。

GuppyLMプロジェクトは良い出発点です。クローンし、任意のテキストデータでトレーニングし、推論ループの挙動を観察してみましょう。本番API統合の見方が大きく変わるはずです。

Apidogのテストシナリオをぜひ活用し、他のバックエンド同様に厳密なAI APIテストを実施してください。

よくある質問

「小さな」LLMが一貫性あるテキストを生成するには何パラメータ必要？

おおよそ1,000万〜5,000万パラメータで良質なデータセットなら短い一貫文の生成が可能です。100万未満だと意味不明になりがち。GuppyLM（870万）は60トピックの短文会話で機能します。

GPUなしで小さなLLMは使える？

1億パラメータ未満ならCPUでも動作します（推論は遅い）。上記モデル(120万パラメータ)はノートPCのCPUでミリ秒単位の生成が可能です。

どんなデータセットで学習すべき？

プロジェクト・グーテンベルクやWikipediaサブセット等のプレーンテキストがおすすめ。GuppyLMはHuggingFaceの会話データセット（arman-bd/guppylm-60k-generic）を利用。コード生成にはThe StackやCodeParrotを。

Temperatureとtop-kサンプリングの違いは？

Temperatureは分布全体のランダム性調整、top-kは上位k候補に絞ってからTemperatureを適用。組み合わせて使うのが一般的。

LLMが自己反復する理由は？

直前のトークンに高確率を割り当てる失敗モード。APIではrepetition_penalty=1.1等で対策できます。

小さなLLMのトレーニング時間は？

上記モデルなら単一GPU（RTX 3060等）で2時間以内、Colabでも同等。1億以上はマルチGPUと数日が必要。

小さなLLMからAPIエンドポイントへ移行する最速手順は？

llama.cppでGGUF変換→llama-serverでOpenAI互換API提供→Apidogでテスト可能。[internal: rest-api-best-practices]参照。

本番LLMはトレーニングウィンドウ以上のコンテキストをどう扱う？

RoPEの拡張、スライディングウィンドウアテンション、RAG等でコンテキスト拡張可能。中核アーキテクチャは不変、位置エンコードやアテンション適用方法だけが変わります。

Seedance 2.0 API 2026年版使い方ガイド

Akira — Sat, 04 Apr 2026 12:57:57 +0000

TL;DR (要約)

Seedance 2.0 APIは2026年4月2日にVolcengine Arkを通じてリリースされました。動画生成タスクをPOSTリクエストで送信し、ステータスが「succeeded」になるまでGETエンドポイントをポーリングします。このAPIは、テキストから動画、画像から動画、最初と最後のフレーム制御、マルチモーダル参照、ネイティブ音声生成をサポートしています。5秒の1080p動画の費用は約0.93ドルです。動画は24時間以内にダウンロードしてください。その後、URLは期限切れになります。

Hypereal AI

Hypereal AIを試す

今すぐApidogを試そう

はじめに

2026年4月2日、ByteDanceのVolcengine Arkプラットフォームは公式のSeedance 2.0 APIをリリースしました。それ以前は、Seedance 2.0の動画を生成する唯一の方法はウェブコンソールからでした。UIのウォークスルーを示すチュートリアルを見たことがある場合、それらはコンソール向けに書かれたものです。このガイドでは、開発者がプログラムで呼び出せる実際のAPIについて、実装方法にフォーカスして解説します。

💡 非同期タスクパターンのポイント

このAPIは非同期タスクパターンです。タスクを作成するためにPOSTし、タスクIDを受け取り、ジョブが完了するまでGETエンドポイントをポーリングします。Apidogのテストシナリオを使えば、POST送信→タスクID抽出→GETポーリング→動画URLの検証までシナリオ化できます。Apidogのセクションで具体的なテスト手順を紹介します。

この記事では、すべての入力タイプ、料金算出方法、エラー対応など、実装に必要な知識をまとめています。

Seedance 2.0とは？

Seedance 2.0はByteDanceが提供する動画生成モデルです。Volcengine Ark上で、

標準モデル: doubao-seedance-2-0-260128
高速/低品質モデル: doubao-seedance-2-0-fast-260128 として利用できます。

v1.5よりも多くの入力に対応し、以下の特徴があります。

最初/最後のフレーム制御（両端画像指定）
マルチモーダル参照：画像・動画・音声を組み合わせ可能
ネイティブ音声生成（会話、環境音、効果音、音楽）
8カ国語以上のリップシンク
カメラモーション（ドリー/トラッキング等）制御
最大2K/15秒の動画出力
1:1～21:9のアスペクト比、24fps

変更点：ガイドと公式APIの比較

2026年2月以前の記事は、VolcengineのWebコンソール手順のみを扱っていました。

2026年4月からはAPIが登場し、プログラムから任意の言語で動画生成パイプラインを自動化できるようになりました。本記事はAPI実装に絞って解説します。

前提条件

volcengine.comでVolcengineアカウントを作成
ArkコンソールでAPIキーを生成

  https://console.volcengine.com/ark/region:ark+cn-beijing/apikey

APIキーを環境変数に設定

  export ARK_API_KEY="your-api-key-here"

Bearerトークンとしてリクエストヘッダーにセット

  Authorization: Bearer YOUR_ARK_API_KEY

新規アカウントには無料トライアルクレジット付与（1080pで約8本の15秒動画生成分）

テキストから動画：最初のリクエスト

ベースURL:

https://ark.cn-beijing.volces.com/api/v3

cURL例

curl -X POST "https://ark.cn-beijing.volces.com/api/v3/contents/generations/tasks" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ARK_API_KEY" \
  -d '{
    "model": "doubao-seedance-2-0-260128",
    "content": [
      {
        "type": "text",
        "text": "A golden retriever running through a sunlit wheat field, wide tracking shot, cinematic"
      }
    ],
    "resolution": "1080p",
    "ratio": "16:9",
    "duration": 5,
    "watermark": false
  }'

レスポンス（タスクID）例：

{"id": "cgt-2025xxxxxxxx-xxxx"}

Python例（公式SDK）

まずSDKをインストール：

pip install volcenginesdkarkruntime

タスク送信例：

import os
from volcenginesdkarkruntime import Ark

client = Ark(api_key=os.environ.get("ARK_API_KEY"))

resp = client.content_generation.tasks.create(
    model="doubao-seedance-2-0-260128",
    content=[
        {
            "type": "text",
            "text": "A golden retriever running through a sunlit wheat field, wide tracking shot, cinematic"
        }
    ],
    resolution="1080p",
    ratio="16:9",
    duration=5,
    watermark=False,
)

print(resp.id)

タスクIDを保存し、後述のポーリングで使用します。

非同期タスクパターン：送信、ポーリング、ダウンロード

生成には時間がかかります（例：5秒の1080pで60〜120秒）。

タスクの状態遷移は以下の通りです。

queued -> running -> succeeded
                  -> failed
                  -> expired
                  -> cancelled

queued/runningの間は、GETで状態確認をポーリングします。

完全なPythonポーリングループ

import os
import time
import requests
from volcenginesdkarkruntime import Ark

client = Ark(api_key=os.environ.get("ARK_API_KEY"))

# Step 1: submit
resp = client.content_generation.tasks.create(
    model="doubao-seedance-2-0-260128",
    content=[{"type": "text", "text": "Aerial shot of a mountain lake at sunrise, slow dolly forward"}],
    resolution="1080p",
    ratio="16:9",
    duration=5,
    watermark=False,
)

task_id = resp.id
print(f"Task submitted: {task_id}")

# Step 2: poll with exponential backoff
wait = 10
while True:
    result = client.content_generation.tasks.get(task_id=task_id)
    status = result.status
    print(f"Status: {status}")

    if status == "succeeded":
        video_url = result.content.video_url
        print(f"Video URL: {video_url}")
        break
    elif status in ("failed", "expired", "cancelled"):
        print(f"Task ended with status: {status}")
        break

    time.sleep(wait)
    wait = min(wait * 2, 60)

# Step 3: download immediately
if status == "succeeded":
    response = requests.get(video_url, stream=True)
    with open("output.mp4", "wb") as f:
        for chunk in response.iter_content(chunk_size=8192):
            f.write(chunk)
    print("Downloaded: output.mp4")

指数バックオフ（最大60秒）はAPI負荷抑制に有効です。

画像から動画（I2V）：静止画のアニメーション化

画像をアニメーション化するには、content配列にimage_urlを追加します。

resp = client.content_generation.tasks.create(
    model="doubao-seedance-2-0-260128",
    content=[
        {
            "type": "text",
            "text": "The woman slowly turns her head and smiles at the camera"
        },
        {
            "type": "image_url",
            "image_url": {"url": "https://example.com/portrait.jpg"}
        }
    ],
    ratio="adaptive",
    duration=5,
    watermark=False,
)

ratio: "adaptive" で入力画像のアスペクト比を自動採用
画像サイズは30MB未満、1リクエスト最大9枚

最初と最後のフレーム：開始点と終了点の制御

最初・最後のフレーム制御例：

resp = client.content_generation.tasks.create(
    model="doubao-seedance-2-0-260128",
    content=[
        {
            "type": "text",
            "text": "The flower blooms from bud to full open, macro lens, soft light"
        },
        {
            "type": "image_url",
            "image_url": {"url": "https://example.com/flower-bud.jpg"}
        },
        {
            "type": "image_url",
            "image_url": {"url": "https://example.com/flower-open.jpg"}
        }
    ],
    ratio="adaptive",
    duration=8,
    watermark=False,
)

両端画像＋テキストで、中間アニメーションを生成します。

return_last_frame: trueを指定すると、最終フレーム画像も取得でき、次回リクエストの初期フレームとして活用可能です。

マルチモーダル参照：画像、動画、音声の組み合わせ

content配列で以下の型を混在可能：

テキスト: {"type": "text", ...}
画像: {"type": "image_url", ...}
動画: {"type": "video_url", ...}
音声: {"type": "audio_url", ...}

制限：

画像: 最大9枚（各30MB）
動画: 最大3本（各2〜15秒/50MB）
音声: 最大3本（MP3/各15MB）

例：

resp = client.content_generation.tasks.create(
    model="doubao-seedance-2-0-260128",
    content=[
        {
            "type": "text",
            "text": "Match the visual style of the reference clip and add the provided background audio"
        },
        {
            "type": "image_url",
            "image_url": {"url": "https://example.com/style-reference.jpg"}
        },
        {
            "type": "video_url",
            "video_url": {"url": "https://example.com/motion-reference.mp4"}
        },
        {
            "type": "audio_url",
            "audio_url": {"url": "https://example.com/background-music.mp3"}
        }
    ],
    duration=10,
    ratio="16:9",
    watermark=False,
)

動画参照を入れると料金ティアが下がります（V2V: 約3.90ドル/100万トークン）。

ネイティブ音声生成

generate_audio: trueを指定すると、音声付き映像を生成します。

リップシンクや環境音も自動生成。

resp = client.content_generation.tasks.create(
    model="doubao-seedance-2-0-260128",
    content=[
        {
            "type": "text",
            "text": "A street musician plays guitar outside a cafe in Paris, crowds passing by, city sounds"
        }
    ],
    resolution="1080p",
    ratio="16:9",
    duration=10,
    generate_audio=True,
    watermark=False,
)

トークン消費は若干増加します。

解像度、アスペクト比、期間の制御

resolution: "480p", "720p", "1080p", "2K"（デフォルト "1080p"、高いほど高コスト）
ratio: "16:9", "9:16", "4:3", "3:4", "21:9", "1:1", "adaptive"
duration: 4～15（秒、デフォルト5）

高速モデルはプロンプト試行に、本番は標準モデル推奨。

応答からの費用の読み取り

成功時のレスポンス例：

{
  "usage": {
    "completion_tokens": 246840,
    "total_tokens": 246840
  }
}

15秒/1080p: 約308,880トークン
5秒/1080p: 約102,960トークン

期間	およそのトークン数	費用 (T2V/I2V)
5秒	~103,000	~0.47元 / ~$0.93
10秒	~206,000	~9.48元 / ~$1.32
15秒	~309,000	~14.21元 / ~$1.97

V2V: ~3.90ドル/100万トークン。

completion_tokensでコスト追跡可能です。

重要：動画は24時間以内にダウンロード

video_urlは24時間で失効。

完了したら即ダウンロードしてください。

execution_expires_afterはタスク自体の有効期間（例：48時間）ですが、動画URLは24時間のみ。

ApidogでSeedance APIをテストする方法

非同期タスクパターンは、POSTとGETの連携が必要です。Apidogの「テストシナリオ」機能で自動化できます。

具体的な流れ：

ステップ1：テストシナリオ作成

「テスト」→新規シナリオ（例: Seedance 2.0動画生成）
環境変数ARK_API_KEYを設定（{{ARK_API_KEY}}で参照）

ステップ2：送信リクエスト追加

POST /contents/generations/tasks
Authorization: Bearer {{ARK_API_KEY}}
JSONボディでモデル/コンテンツ指定

ステップ3：タスクID抽出

応答の$.idをTASK_ID環境変数に抽出

ステップ4：待機

30秒の遅延を追加（モデル初期処理用）

ステップ5：Forループでポーリング

最大20回
1. GET /contents/generations/tasks/{{TASK_ID}}
2. 10秒遅延
3. Break条件: $.status == "succeeded"または"failed"

ステップ6：アサーション追加

$.status == "succeeded"
$.content.video_urlが空でない

Apidogは各ステップ・抽出・テスト結果をレポート化します。

cURLコマンドからのインポートもサポート。

料金の内訳：10秒の動画の費用

タスクタイプ	料金（100万トークンあたり）
1080pでのT2V / I2V	46元（約6.40ドル）
V2V（動画参照入力）	28元（約3.90ドル）

期間	およそのトークン数	費用 (T2V/I2V)
5秒	~103,000	~0.47元 / ~$0.93
10秒	~206,000	~9.48元 / ~$1.32
15秒	~309,000	~14.21元 / ~$1.97

新規アカウントには約8本の15秒動画生成分の無料トライアルあり。

開発時は解像度を720pや480pに落とすことでコスト削減可能です。

よくあるエラーとその解決策

429 Too Many Requests

→ 同時実行制限。指数バックオフ（10秒→20秒→…最大60秒）でリトライ。

status: "failed"

→ プロンプト違反/画像破損/パラメータ不正等。入力内容を見直して再実行を。

status: "expired"

→ キュー待ち時間超過。混雑時発生。再送信のみ。

video_urlの403エラー

→ 24時間超過でURL失効。再生成が必要。

シードの再現性

→ 応答のseed値を保存して同条件で再リクエストすると再現性アップ。

結論

Seedance 2.0 APIは高性能な動画生成をプログラムから自動化できます。

非同期タスクパターンのPOST→ポーリング→即ダウンロード
マルチモーダル入力やネイティブ音声など、Web UIではできないワークフローを構築可能

本番前にApidogでE2Eテストシナリオを構築し、ポーリングや抽出、URL有効期限の問題を事前検証しましょう。

FAQ

Q: doubao-seedance-2-0-260128とdoubao-seedance-2-0-fast-260128の違いは？

A: 標準モデルは高品質、本番用。高速モデルは速いが低品質。プロンプト検証は高速モデルで、最終出力は標準モデル推奨。

Q: Seedance 2.0は中国国外で使える？

A: エンドポイントは北京リージョン。国外開発者も利用可能だが遅延あり。地理制限はVolcengine利用規約参照。

Q: 複数クリップで長い動画を作りたい

A: 各生成でreturn_last_frame: trueを指定。最終フレーム画像を次の最初のフレームに使い、動画編集で連結。

Q: ネイティブ音声生成は高コスト？

A: トークン消費はやや増加。generate_audio: trueオフの同一リクエストと比較し、completion_tokensで確認可能。

Q: ポーリングではなくWebhook利用は？

A: 送信時にcallback_url指定で、完了時に自動通知。パイプライン大量処理時に有効。

Q: 画像9枚制限を超過すると？

A: 400エラー。9枚以内に制限。

Q: シード値で完全再現できる？

A: シード値で再現性は高まるが、パラメータやモデルバージョンが変わると完全一致は保証されません。

Q: 複数タスクの費用管理は？

A: completion_tokens×レートでコスト算出。APIに支出ダッシュボードはないので、アプリ側で集計・記録を。

ApidogでのAPI連携テストには

Apidog公式サイト

を活用してください。

Grokテキストから動画APIの使い方【完全ガイド】

Akira — Fri, 03 Apr 2026 08:40:51 +0000

要するに

Grokのテキスト-to-ビデオAPIは、テキストプロンプトからビデオを生成します。POST /v1/videos/generationsを呼び出すとすぐにrequest_idが返され、ステータスが"done"になるまでGET /v1/videos/{request_id}でポーリングします。モデル名はgrok-imagine-videoで、料金は480pで1秒あたり0.05ドルから。xAI Python SDKを使えばポーリング処理も自動化できます。

今すぐApidogを試す

はじめに

xAIは2026年1月だけで12億本のビデオを生成しました。これは、2026年1月28日にGrokのテキスト-to-ビデオAPIをリリースしてから最初の1ヶ月の成果です。このモデルは同月、Artificial Analysisのテキスト-to-ビデオリーダーボードで1位を獲得しました。大規模かつ実績あるインフラを前提に使えます。

このガイドでは、リクエストの作成、結果のポーリング、パラメータ調整、プロンプト設計、参照画像の使い方、ビデオの延長・編集手順、適切なAPI選択まで具体的に解説します。

💡 APIは非同期です。 フロントエンドはビデオの生成完了まで何も表示できません。UIを開発・テストするには、APIのポーリングフローを模倣できる環境が必須です。ApidogのSmart Mockなら生成・ポーリング両エンドポイントを簡単にモック可能。バックエンド開発中でもUIやポーリングロジックを実装できます。詳細は後述のテストセクション参照。

Grokテキスト-to-ビデオAPIとは？

Grokテキスト-to-ビデオAPIは、https://api.x.aiで提供されるxAIのメディア生成APIの一つです。テキストプロンプトのみでgrok-imagine-videoモデルが短い動画を生成します（ソース画像不要）。

同期型の画像生成エンドポイント（POST /v1/images/generations、モデルgrok-imagine-image、1画像0.02ドル）も併設されています。さらに、既存ビデオの延長や編集用エンドポイントも利用可能です。

テキスト-to-ビデオは「言葉だけで」構図・動き・スタイルをゼロから生成します。画像-to-ビデオのようにソース画像を渡したい場合は、Grok画像-to-ビデオAPIガイドを参照してください。

テキスト-to-ビデオ生成の仕組み（非同期パターン解説）

ビデオ生成APIは非同期パターンです。フローは以下の通り：

プロンプトを含めてPOSTリクエスト送信
即座にrequest_idが返却
サーバー側でビデオ生成開始
request_idを使いGETエンドポイントをポーリング
ステータスが"done"になればビデオURLを取得

この設計により、HTTP接続を短時間で済ませ、進捗確認やUIの切り替えが柔軟に行えます。ローディングインジケーターや中間状態の実装が必要です。

前提条件

実装前に以下を準備します。

xAIアカウント

console.x.aiで作成。API利用には課金情報登録が必要です。
APIキー

コンソールでAPIキーを生成し、安全な場所に保管。全リクエストでBearer認証として使います。

APIキーは環境変数に設定しましょう。

export XAI_API_KEY="your_api_key_here"

オプションでxAI Python SDKをインストール可能です。

pip install xai-sdk

初めてのテキスト-to-ビデオリクエスト

curlでリクエスト

curl -X POST https://api.x.ai/v1/videos/generations \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-imagine-video",
    "prompt": "A golden retriever running through autumn leaves in slow motion, cinematic lighting"
  }'

即座に次のようなレスポンスが返却されます。

{
  "request_id": "d97415a1-5796-b7ec-379f-4e6819e08fdf"
}

Python (requests) での実装例

import requests
import os

API_KEY = os.environ["XAI_API_KEY"]
BASE_URL = "https://api.x.ai"

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

payload = {
    "model": "grok-imagine-video",
    "prompt": "A golden retriever running through autumn leaves in slow motion, cinematic lighting"
}

response = requests.post(
    f"{BASE_URL}/v1/videos/generations",
    headers=headers,
    json=payload
)

data = response.json()
request_id = data["request_id"]
print(f"Generation started. Request ID: {request_id}")

ビデオ結果のポーリング

request_idを受け取ったら、GET /v1/videos/{request_id}を一定間隔で呼び出してステータスが"done"になるまで待ちます。

"processing" … 生成中
"done" … 完了、ビデオURLあり
"failed" … 失敗

ポーリングループの実装（Python例）

import requests
import time
import os

API_KEY = os.environ["XAI_API_KEY"]
BASE_URL = "https://api.x.ai"

headers = {
    "Authorization": f"Bearer {API_KEY}"
}

def poll_video(request_id: str, interval: int = 5, max_attempts: int = 60) -> dict:
    """ビデオ生成が完了するまでポーリング"""
    url = f"{BASE_URL}/v1/videos/{request_id}"

    for attempt in range(max_attempts):
        response = requests.get(url, headers=headers)
        data = response.json()

        status = data.get("status")
        progress = data.get("progress", 0)
        print(f"Attempt {attempt + 1}: status={status}, progress={progress}%")

        if status == "done":
            return data
        elif status == "failed":
            raise RuntimeError(f"Video generation failed: {data}")

        time.sleep(interval)

    raise TimeoutError(f"Video not ready after {max_attempts} attempts")

# ワークフロー例
def generate_video(prompt: str) -> str:
    response = requests.post(
        f"{BASE_URL}/v1/videos/generations",
        headers={**headers, "Content-Type": "application/json"},
        json={"model": "grok-imagine-video", "prompt": prompt}
    )
    request_id = response.json()["request_id"]
    print(f"Request ID: {request_id}")

    result = poll_video(request_id)
    video_url = result["video"]["url"]
    print(f"Video ready: {video_url}")
    return video_url

video_url = generate_video(
    "A timelapse of a city skyline at sunset transitioning to night, aerial view"
)

ポーリング完了時のレスポンス例

{
  "status": "done",
  "video": {
    "url": "https://vidgen.x.ai/....mp4",
    "duration": 8,
    "respect_moderation": true
  },
  "progress": 100,
  "usage": {
    "cost_in_usd_ticks": 500000000
  }
}

xAI Python SDKの活用

手動ポーリングを省略したい場合はxAI SDKが便利です。client.video.generate()が完了までブロックします。

from xai_sdk import Client
import os

client = Client(api_key=os.environ["XAI_API_KEY"])

result = client.video.generate(
    model="grok-imagine-video",
    prompt="A golden retriever running through autumn leaves in slow motion",
    duration=8,
    resolution="720p",
    aspect_ratio="16:9"
)

print(f"Video URL: {result.video.url}")
print(f"Duration: {result.video.duration}s")

カスタムポーリングや進捗制御が必要な場合はrequests版を利用してください。

ビデオ生成のための効果的なプロンプト設計

シーン記述

被写体と設定を明確に記述。「雨に濡れた窓の横の木製テーブルに置かれた白いセラミックのコーヒーマグ」など。
動きの指示

「湯気が立ち上るマグカップの周りをカメラがゆっくり旋回する」など、動きの明示が重要。
カメラスタイル

「クローズアップ」「ドローンビュー」など映画的な表現を加える。
ライティング・ムード

「ゴールデンアワー」「ネオンライト」「憂鬱な雰囲気」などで見た目・雰囲気を指定。
スタイル参照

「シネマティック」「アニメ」「ハイパーラプス」など、スタイル名も積極的に活用。

効果的なプロンプト例

A lone astronaut floats past the International Space Station,
tether drifting behind them. The camera tracks slowly
alongside, showing Earth below. Cinematic, IMAX quality,
warm sunrise light reflecting off the visor.

解像度・持続時間・アスペクト比の制御

リクエスト時に以下のパラメータで出力仕様を調整できます。

持続時間

"duration": 10

範囲：1〜15秒（デフォルト6秒）。長いほどコスト増。

解像度

"resolution": "720p"

"480p"（デフォ、開発・テスト向け）
"720p"（本番/高品質用）

アスペクト比

"aspect_ratio": "9:16"

比率	用途
`16:9`	デスクトップ、YouTube、プレゼン資料（デフォ）
`9:16`	TikTok、Instagramリール、モバイル
`1:1`	Instagramフィード、ソーシャルカード
`4:3`	クラシック映像、プレゼン
`3:4`	ポートレート系モバイル
`3:2`	一般的な写真比率
`2:3`	ポートレート写真

フルパラメータ例

curl -X POST https://api.x.ai/v1/videos/generations \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-imagine-video",
    "prompt": "A coastal town at dawn, waves breaking gently on a rocky shore",
    "duration": 10,
    "resolution": "720p",
    "aspect_ratio": "16:9"
  }'

参照画像でビデオスタイルを指定する

reference_imagesパラメータで最大7枚の画像URLを指定可能。これらは主題ではなく、スタイルや色味のガイドとして機能します。

{
  "model": "grok-imagine-video",
  "prompt": "A coastal town at dawn, waves breaking gently on a rocky shore",
  "reference_images": [
    {"url": "https://example.com/my-style-reference.jpg"},
    {"url": "https://example.com/color-palette-reference.jpg"}
  ]
}

一貫したスタイルの画像セットが最も効果的。プロンプトが主で、画像は色・構図・テクスチャに影響。

生成ビデオの延長と編集

xAIには生成済みビデオの操作用エンドポイントが2種類あります。

ビデオの延長

POST /v1/videos/extensions

既存ビデオのrequest_idと新しいプロンプトをセットで送信し、映像を追加できます。複数回呼び出すことで15秒以上の動画も実現可能。

ビデオの編集

POST /v1/videos/edits

既存ビデオをプロンプトで編集できます（スタイル変更・シーン修正など）。

いずれもrequest_idが返る非同期パターンです。GET /v1/videos/{request_id}で結果を取得。

APIレスポンスからコスト取得

完了時レスポンスのusage.cost_in_usd_ticksを10,000,000で割るとUSD換算できます。

cost_in_usd = result["usage"]["cost_in_usd_ticks"] / 10_000_000
print(f"Cost: ${cost_in_usd:.4f}")
# 出力例: Cost: $0.0500

料金表

解像度	1秒あたり	10秒クリップ
480p	$0.05	$0.50
720p	$0.07	$0.70

500000000ティック＝$0.50、480pの10秒クリップに相当します。全リクエストのコストを自前で集計し、ダッシュボードへ反映可能です。

ApidogでGrokビデオAPIをテストする方法

非同期ポーリングはテストが難しいですが、ApidogのSmart Mockで効率化できます。

ユースケース1：フロントエンド開発用Smart Mock

ApidogのSmart Mockでエンドポイントのスキーマを定義すれば、即座にリアルなモックレスポンスが得られます。

生成エンドポイントのモック例：

POST /v1/videos/generations レスポンススキーマにrequest_id（文字列）を設定。自動でUUID風の値が返る。

{
  "request_id": "d97415a1-5796-b7ec-379f-4e6819e08fdf"
}

ポーリングエンドポイントのモック例：

GET /v1/videos/{request_id} status、video.url、video.duration、progress、usage.cost_in_usd_ticksなどを含むスキーマ・カスタムレスポンス例。

{
  "status": "done",
  "video": {
    "url": "https://vidgen.x.ai/mock-video-12345.mp4",
    "duration": 8,
    "respect_moderation": true
  },
  "progress": 100,
  "usage": {
    "cost_in_usd_ticks": 400000000
  }
}

開発のポイント：

"status": "processing"/"done"/"failed"のバリエーションでUI状態をテスト
開発中はAPIクレジット消費ゼロ

ユースケース2：ポーリングループのテストシナリオ

統合テストもApidog内で自動化できます。

生成リクエスト追加

POST /v1/videos/generations→JSONPathでrequest_idを抽出し変数保存
ポーリング追加

GET /v1/videos/{{videoRequestId}}をForループで繰り返し、status == "done"でブレーク。各ループで5秒待機。
アサーション

最後のレスポンスで$.video.urlが空でないか検証。

このシナリオをCIに組み込めば、回帰テストも高速化できます。

テキスト-to-ビデオ vs 画像-to-ビデオ：使い分け

どちらもgrok-imagine-videoモデル利用ですが、用途が異なります。

テキスト-to-ビデオが適するケース：
- スクリプトやコンセプトから新規動画を生成
- モデルに構図や演出の自由度を持たせたい
- 入力がプロンプトのみ
画像-to-ビデオが適するケース：
- 既存の画像（写真・イラスト）をアニメーション化
- 細かなビジュアル要件がある
- 一連の画像から連続アニメーションを作成

重要：

テキスト-to-ビデオはゼロから生成、画像-to-ビデオは既存画像に動きを付与。詳細はこちらのガイド参照。

両対応UIの場合、入力内容に応じてAPIルーティングを自動化しましょう。

よくあるエラーと対処法

401 Unauthorized

APIキーの指定ミス・期限切れ。Bearer YOUR_XAI_API_KEY形式・有効性を再確認。
429 Too Many Requests

レートリミット超過。1分60リクエスト・1秒1リクエスト。ポーリング間隔（5秒以上）を調整。
status: "failed"

モデレーション違反の可能性。respect_moderationがtrueの場合はプロンプトを修正。
ビデオURL 404

生成ビデオURLは短期間有効。取得後すぐに自ストレージへ保存。
空白/静止ビデオ

曖昧なプロンプトや動きの記述がない場合。動きやシーンを明確に指定する。
生成遅延

720pや長尺は時間がかかる。開発・テストでは短尺＆480p推奨。

まとめ

Grokテキスト-to-ビデオAPIは、テキストだけで動画生成を実現します。非同期パターンの理解が重要です。

request_idでポーリングし、完了したらビデオURLを取得・保存。

持続時間・解像度・アスペクト比・参照画像などパラメータも柔軟に指定可能です。

コスト追跡はcost_in_usd_ticksから計算。

開発時はApidogでAPIモックサーバー・テストシナリオを構築し、実際のビデオ生成待ちやクレジット消費なしでフロントエンド開発・CIテストが可能です。

よくある質問

Q: テキスト-to-ビデオ生成にはどのモデル名を使う？

A: grok-imagine-videoを指定。/v1/videos/generationsで必須。

Q: ビデオ生成にかかる時間は？

A: 持続時間・解像度による。480pの短尺は30秒未満、720p長尺は数分。5〜10秒おきのポーリング推奨。

Q: 15秒超のビデオ生成は可能？

A: 単一リクエスト不可。最大durationは15秒。/v1/videos/extensionsで延長。

Q: 生成ビデオのダウンロード方法は？

A: ポーリング完了時のresult.video.urlから即時ダウンロード。URLは一時的。

Q: プロンプトがモデレーション違反の場合？

A: status: "failed"で完了。respect_moderationがtrueならプロンプト修正で再試行。

Q: ビデオAPIの無料枠は？

A: ビデオは1秒ごとに課金。無料枠はなし。新規クレジットはconsole.x.aiで確認。

Q: reference_imagesとソース画像の違いは？

A: 参照画像はスタイルガイド用。画像-to-ビデオは画像そのものが最初のフレーム。

Q: クレジット消費なしでポーリングテストするには？

A: ApidogのSmart Mockで生成・ポーリング両エンドポイントをモック。"processing"/"done"状態のレスポンスを切り替えれば、実API不要でテスト可能です。

Grok画像から動画APIの使い方【ステップバイステップガイド】

Akira — Fri, 03 Apr 2026 08:36:04 +0000

要約

Grok画像-動画APIは、grok-imagine-videoモデルで静止画像を動画クリップにアニメーション化します。画像URL、プロンプト、オプション設定をhttps://api.x.ai/v1/videos/generationsにPOSTし、request_idが即時返却されます。その後、GET /v1/videos/{request_id}でstatusが"done"になるまでポーリングします。動画の長さは1～15秒、料金は480p出力で1秒あたり0.05ドルからです。

Apidogを今すぐ試す

はじめに

2026年1月28日、xAIはgrok-imagine-videoモデルを公開APIアクセス向けにリリースしました。公開から1ヶ月で12億本の動画生成を達成し、Artificial Analysisのテキスト-動画リーダーボードで1位を獲得しました。写真と説明プロンプトをAPIに送信するだけで、その写真を短い動画クリップとしてMP4ダウンロードできます。

このAPIは非同期フロー（ジョブ送信→完了までポーリング）を採用しており、POSTの200レスポンスのみでは統合テストは不十分です。"processing", "done", "failed"の各状態を現実的なネットワーク条件下で正しく処理することが重要です。

Apidogのテストシナリオなら、/v1/videos/generationsのPOST→request_id抽出→status == "done"までのポーリングループ構築→動画URLのアサートまで一連の自動テストを簡単に実装可能です。本記事後半のハンズオンに沿って、Apidogでテストを始めましょう。

Grok画像-動画APIとは？

Grok画像-動画APIは、xAIの動画生成製品の1機能です。grok-imagine-videoモデルを使用し、画像を動画の開始フレームとして受け付けます。画像とテキストプロンプトからシーンを自然にアニメーション化します。

APIエンドポイント：

POST https://api.x.ai/v1/videos/generations

認証はBearerトークンです。

Authorization: Bearer YOUR_XAI_API_KEY

APIキーは公式xAIコンソールから取得します。

同じエンドポイントでテキスト-動画（image省略）、動画延長、編集も可能です。

画像から動画への処理フロー

リクエストボディのimageパラメータは、出力動画の最初のフレームを指定します。モデルはこの画像を変更せずに開始し、プロンプトに基づいて動きを生成します。

例：山湖の写真＋「朝霧が漂い、水面に穏やかな波紋」→最初のフレームは写真、その後のフレームで水や霧が動く。

画像-動画: 開始シーンを完全制御したい場合
テキスト-動画: 画像なしでゼロからシーン生成したい場合

前提条件

APIコール前に以下を準備してください。

console.x.aiのxAIアカウント
APIキー（環境変数で管理推奨）
Python 3.8+またはNode.js 18+（本記事例で使用）
公開アクセス可能な画像URLまたはbase64データURI

画像例：

APIキーを環境変数にセット：

export XAI_API_KEY="your_key_here"

xAI Python SDKを使う場合はインストール：

pip install xai-sdk

生HTTPの場合、requests（Python）またはfetch（Node.js）以外は不要です。

最初の画像-動画リクエストを行う

curlでの実装例

curl -X POST https://api.x.ai/v1/videos/generations \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-imagine-video",
    "prompt": "Gentle waves move across the surface, morning mist rises slowly",
    "image": {
      "url": "https://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/24701-nature-natural-beauty.jpg/1280px-24701-nature-natural-beauty.jpg"
    },
    "duration": 6,
    "resolution": "720p",
    "aspect_ratio": "16:9"
  }'

レスポンス例：

{
  "request_id": "d97415a1-5796-b7ec-379f-4e6819e08fdf"
}

Python（生HTTPリクエスト）

import os
import requests

api_key = os.environ["XAI_API_KEY"]

payload = {
    "model": "grok-imagine-video",
    "prompt": "Gentle waves move across the surface, morning mist rises slowly",
    "image": {
        "url": "https://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/24701-nature-natural-beauty.jpg/1280px-24701-nature-natural-beauty.jpg"
    },
    "duration": 6,
    "resolution": "720p",
    "aspect_ratio": "16:9"
}

headers = {
    "Authorization": f"Bearer {api_key}",
    "Content-Type": "application/json"
}

response = requests.post(
    "https://api.x.ai/v1/videos/generations",
    json=payload,
    headers=headers
)

data = response.json()
request_id = data["request_id"]
print(f"Job started: {request_id}")

base64画像を使いたい場合

import base64

with open("my_image.jpg", "rb") as f:
    encoded = base64.b64encode(f.read()).decode("utf-8")

payload["image"] = {
    "url": f"data:image/jpeg;base64,{encoded}"
}

結果のポーリング

動画生成は非同期です。request_idで進捗をポーリングします。

GET https://api.x.ai/v1/videos/{request_id}

ステータス	意味
`"processing"`	動画レンダリング中
`"done"`	動画完成・URLが応答に含まれる
`"failed"`	生成失敗

レスポンス例（完了時）：

{
  "status": "done",
  "video": {
    "url": "https://vidgen.x.ai/....mp4",
    "duration": 6
  },
  "progress": 100
}

完全なPythonポーリングループ

import time

def poll_video(request_id: str, api_key: str, interval: int = 5) -> dict:
    url = f"https://api.x.ai/v1/videos/{request_id}"
    headers = {"Authorization": f"Bearer {api_key}"}

    while True:
        response = requests.get(url, headers=headers)
        data = response.json()
        status = data.get("status")

        print(f"Status: {status} | Progress: {data.get('progress', 0)}%")

        if status == "done":
            return data["video"]
        elif status == "failed":
            raise RuntimeError(f"Video generation failed for {request_id}")

        time.sleep(interval)

# 使用例
video = poll_video(request_id, api_key)
print(f"Video URL: {video['url']}")
print(f"Duration: {video['duration']}s")

注意：ポーリング間隔は5秒以上推奨。APIは1分60回・1秒1回までです。

xAI Python SDKの利用

xai-sdkならポーリングやエラー処理も自動。

from xai_sdk import Client
import os

client = Client(api_key=os.environ["XAI_API_KEY"])

video = client.video.generate(
    model="grok-imagine-video",
    prompt="Gentle waves move across the surface, morning mist rises slowly",
    image={"url": "https://example.com/landscape.jpg"},
    duration=6,
    resolution="720p",
    aspect_ratio="16:9"
)

print(f"Video URL: {video.url}")
print(f"Duration: {video.duration}s")

細かいポーリングやリトライ設定をしたい場合は生HTTPを選択してください。

解像度、期間、アスペクト比の制御

期間: duration（1～15秒、デフォルト6秒）
```
"duration": 10
```
長いほどコスト増。10秒は1秒の10倍。
解像度: "480p"（デフォルト）, "720p"
| 値 | 説明 |
|---------|---------------------------|
| "480p" | 低コスト、高速 |
| "720p" | 高品質、1秒0.07ドル |
```
"resolution": "720p"
```
アスペクト比: aspect_ratio
| 値 | 用途 |
|--------|-------------------------------|
| "16:9" | デフォルト、ワイド |
| "9:16" | 縦型、SNSストーリー |
| "1:1" | インスタやサムネイル |
| "4:3" | クラシック写真 |
| "3:4" | ポートレート |
| "3:2" | 標準写真 |
| "2:3" | 縦型標準 |

imageを指定するとデフォルトで画像比率に自動設定。変更したい場合は明示指定。

スタイルガイド用の参照画像

image: 最初のフレームとなる画像
reference_images: スタイルや雰囲気をガイドする画像配列（最大7枚）。フレームにはならない。

例：

{
  "model": "grok-imagine-video",
  "prompt": "A product rotating slowly on a clean white surface",
  "image": {
    "url": "https://example.com/product-shot.jpg"
  },
  "reference_images": [
    {"url": "https://example.com/brand-style-reference-1.jpg"},
    {"url": "https://example.com/lighting-reference.jpg"}
  ],
  "duration": 6,
  "resolution": "720p"
}

参照画像だけで、imageなしも可能です（その場合はテキスト-動画生成＋スタイルガイド）。

動画の延長と編集

動画の延長: 既存動画に追加生成。15秒制限以上の動画を生成したい場合に有効。

curl -X POST https://api.x.ai/v1/videos/extensions \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-imagine-video",
    "video_id": "your_original_request_id",
    "prompt": "The mist continues to lift as sunlight breaks through",
    "duration": 5
  }'

結果は同じ非同期パターンでポーリング。

動画の編集: 既存動画の一部をプロンプトで変更。

curl -X POST https://api.x.ai/v1/videos/edits \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-imagine-video",
    "video_id": "your_original_request_id",
    "prompt": "Change the sky to a dramatic sunset with deep orange tones"
  }'

こちらもポーリングで完了を確認。

料金内訳：10秒の動画の場合

コンポーネント	費用
入力画像	1枚あたり0.002ドル
480p出力	1秒あたり0.05ドル
720p出力	1秒あたり0.07ドル

10秒の720p動画例

入力画像：0.002ドル
出力：10秒 × 0.07ドル = 0.70ドル
合計：0.702ドル

6秒の480p動画例

入力画像：0.002ドル
出力：6秒 × 0.05ドル = 0.30ドル
合計：0.302ドル

同じ画像URLでも毎回入力画像料金がかかります。テキスト-動画は画像入力料金（0.002ドル）は不要。

ApidogでGrok動画API統合をテストする方法

非同期APIのテストには以下の自動化フローをApidogで構築します。

生成POSTでrequest_idを取得
ポーリングGETで"processing"状態をハンドリング
"done"後に動画URLの存在をアサート

テストシナリオ構築手順

ステップ1: Apidogで新規テストシナリオ作成（例:「Grok画像-動画非同期フロー」）

ステップ2: 生成POSTリクエスト追加

URL: https://api.x.ai/v1/videos/generations
メソッド: POST
ヘッダー: Authorization: Bearer {{xai_api_key}}
ボディ(JSON)例:

{
  "model": "grok-imagine-video",
  "prompt": "Gentle mist rises from the water as light filters through the trees",
  "image": {
    "url": "https://example.com/your-test-image.jpg"
  },
  "duration": 6,
  "resolution": "480p"
}

ステップ3: request_id抽出（変数抽出プロセッサで$.request_id→video_request_idへ）
ステップ4: ForループでポーリングGETリクエスト
- URL: https://api.x.ai/v1/videos/{{video_request_id}}
- ヘッダー: Authorization: Bearer {{xai_api_key}}
- 変数抽出: $.status→video_status
- 待機プロセッサ5000ms追加
- ブレイク条件: {{video_status}} == "done"
ステップ5: 完了後に動画URLをアサート
- フィールド: $.video.url
- 条件: 空でない

シナリオ実行例
テストシナリオ画面で「実行」。POST→request_id抽出→ループ→動画URLアサートまで自動実行し、各ステップの進捗と結果がレポートされます。

CLI経由でCI/CD統合も可能：

apidog run --scenario grok-video-async-flow --env production

よくあるエラーとその修正

401 Unauthorized

APIキー未設定または無効。ヘッダー形式Bearer YOUR_XAI_API_KEYとキーの有効性を確認。
422 Unprocessable Entity

リクエストボディの必須フィールド漏れや画像URLアクセス不可。画像URLはブラウザで事前チェック。
画像URLにアクセス不可

xAIサーバーから到達可能なURLまたはbase64データURIを使用。private/localhost/認証付きURLは不可。
processingのまま進まない

高解像度・長時間動画は遅延。10分以上変化なければ再リクエスト推奨。タイムアウトは現状APIから返却されません。
429 レート制限

1分60回・1秒1回。複数ジョブ同時ポーリング時はインターバル追加。
Base64アップロード失敗

データURIのMIMEタイプが正しいか確認（例: JPEGならdata:image/jpeg;base64,）。
アスペクト比不一致

ソース画像と異なる比率を指定するとクロップ/レターボックスされることあり。最良結果には画像比率と同じaspect_ratioを設定。

まとめ

Grok画像-動画APIは、静止写真→短尺アニメクリップの自動化に最適です。シンプルなPOST→request_id取得→完了までポーリング→MP4ダウンロードという流れで実装できます。grok-imagine-videoは2026年1月時点で業界リーダーの実績。大規模運用でも安定したパフォーマンスが期待できます。

非同期処理を正しくテストするには、Apidogの変数抽出・ポーリングループ・アサーションを活用してください。これにより本番前のバグ検出・品質担保が容易になります。

Apidogを無料でダウンロードして、今すぐ統合テストを始めましょう。クレジットカード不要です。

よくある質問

Q. Grok画像-動画APIのモデル名は？

A. grok-imagine-videoです。POSTリクエストのmodelフィールドに指定。

Q. imageパラメータとreference_imagesの違いは？

A. imageは開始フレーム、reference_imagesはスタイルガイド。両方同時利用可能。

Q. 動画生成はどれくらい時間がかかる？

A. 6秒480pで約1～3分、15秒720pで4～8分。ポーリングは5秒間隔推奨。

Q. ローカルファイルも使える？

A. はい。base64データURI（例:data:image/jpeg;base64,xxxx）にエンコードしてimage.urlに指定。

Q. aspect_ratioを省略すると？

A. image指定時は画像の比率、テキスト-動画時は16:9がデフォルト。

Q. 10秒720p動画の料金は？

A. 入力画像0.002ドル＋出力0.70ドル＝合計0.702ドル。

Q. レート制限は？

A. 1分60回・1秒1回。POST/GETすべてに適用。

Q. 15秒を超える動画は？

A. POST /v1/videos/extensionsで分割生成・連結が可能。各延長も非同期パターン。

これで、Grok画像-動画APIの実装・テスト・運用のための実践的なガイドを完了します。

2026年版 Bird SMS APIの料金は？

Akira — Fri, 03 Apr 2026 07:08:23 +0000

要約

Bird SMS APIは、米国宛送信メッセージあたり0.00331ドル、米国発信受信メッセージあたり0.003ドルという低価格で利用可能です。競合他社と比較してもエントリーレベルの料金が非常に安価で、1日5通までの無料SMSが使える無償プランも提供されています。Proプラン（月額49ドル）には1,000通分のSMSクレジットが含まれます。

今すぐApidogを試す

はじめに

MessageBirdは2023年にBirdへブランド変更し、AIを活用したオムニチャネルコミュニケーション（SMS、WhatsApp、Eメール、音声通話）を単一プラットフォームで提供することに注力しています。従量課金制へと料金体系が刷新され、TwilioやVonageなど他社よりも低価格が実現されています。

💡 SMS統合を今すぐ構築するなら

Apidogでは、Bird APIリクエスト設計・テスト・応答検証がコード不要で可能。最新の料金データも取得でき、Bird SMS統合のテストが数分で行えます。詳しくは apidog.com をご覧ください。

この記事では、2025～2026年のBird SMSコスト構造・コスト増加要因・競合比較・実装手順を解説します。

Bird SMS料金概要

BirdのSMS利用料金は2階層で構成されています。

プラットフォームプラン料金（月額サブスクリプション）
メッセージごとの従量課金

プラン	月額費用	含まれるSMS数
無料	0ドル	1日5通のSMS
Pro	49ドル	1,000通/月
Enterprise	カスタム	カスタムボリューム

プランのSMS上限超過時は、下記の従量課金が発生します（米国番号の場合）:

送信SMS: 1通あたり0.00331ドル
受信SMS: 1通あたり0.003ドル

詳細は bird.com/en/pricing/sms を参照してください。

料金の内訳：SMS、MMS、WhatsApp、Eメール

SMS

米国宛送信SMS：0.00331ドル/通。150ヵ国以上へ直接接続可能。国別料金の一例：

国	送信料金（概算）
米国	～0.00331ドル
英国	～0.036ユーロ
オーストラリア	～0.009ユーロ
ドイツ	～0.056ユーロ
インド	ルートにより異なる
ブラジル	～0.047ユーロ

注意: 米国・カナダでは追加キャリア手数料（10DLC, Toll-Free等）が別途発生します。

MMS

MMS（画像付きメッセージ）は米国・カナダでサポート。料金はSMSの約3～5倍で、国やプランによって異なります。最新情報は bird.com/en/pricing/sms を参照。

BirdのWhatsApp料金は2要素で決まります。

Bird処理手数料（1,000メッセージ単位）：

ボリューム	1,000メッセージあたり手数料
1～1,000	0.001ドル
1,001～100,000	0.005ドル
100,001～500,000	0.0045ドル
500,001以上	0.004ドル

Metaパススルー手数料（会話単位、国・内容で異なる）米国番号例：
マーケティング会話：0.0250ドル
ユーティリティ会話：0.0034ドル
認証会話：0.0034ドル

BirdはMeta手数料を原価で転嫁します。

Eメール

API経由のEメール送信は1通0.001ドル～（ボリューム次第で単価低減）。Proプランで月10,000通まで無料枠。コスト効率の良いチャネルです。

音声通話

BirdのVoice APIは従量課金制。米国発信：1分あたり約0.013～0.015ドル。着信はより安価です。大量利用は営業窓口へ。

Birdの請求額に影響する要因

1. 国・キャリアルーティング

送信先によって料金は大きく異なります。例：ドイツ（～0.056ユーロ）、バングラデシュ（～0.208ユーロ）、ブルンジ（～0.269ユーロ）は米国の10～80倍。国際SMS前には最新料金表の確認を推奨。

2. 電話番号の種類

ロングコード（10DLC）: 標準番号。ブランド・キャンペーン登録必須。
ショートコード: 5～6桁、高スループット、月額500～1,000ドル。
フリーダイヤル: 中程度のコスト・スループット。

番号の月額レンタル料は別途発生。

3. メッセージ長・エンコーディング

GSM-7: 160文字/セグメント
Unicode: 70文字/セグメント

160文字超や絵文字使用時はセグメント数が増え、従量課金も加算。

4. チャネルミックス

ワークフローでSMS送信失敗時にWhatsApp等へフォールバック設定する場合は、それぞれのチャネル利用料金が発生します。BirdのFlow Builderで自動化可能ですが、コストシミュレーションを事前に行いましょう。

5. ボリューム

公式な段階的ボリューム割引は非公開ですが、大量送信時はEnterpriseプランで交渉可能。

隠れた費用と手数料

米国キャリア手数料（10DLC）

ブランド登録：1回約4～44ドル
キャンペーン登録：月額約10ドル/キャンペーン
メッセージごとの追加料金：数セント

これらは米国キャリア（AT&T, T-Mobile, Verizon）が設定し、Birdは原価で請求。

電話番号のレンタル

ロングコード：月1～2ドル
フリーダイヤル：月2～3ドル
ショートコード：月500～1,000ドル

受信ウェブフック・処理

受信SMSごとに0.003ドル（米国）。オプトアウトや自動応答の運用時も発生。

プラットフォームサブスクリプション

Proプラン（月49ドル）は固定。送信量が少ない場合は従量課金がコストの中心となります。

Birdと競合他社の比較

主要プロバイダーの米国宛SMS料金比較：

プロバイダー	米国宛送信SMS	米国発信受信SMS	備考
Bird	0.00331ドル	0.003ドル	最低水準の料金、オムニチャネル対応
Twilio	0.0079ドル	0.0079ドル	基本料金高め、巨大なエコシステム
Telnyx	～0.004ドル	～0.001ドル	競争力あり、キャリア直結
Plivo	0.0055ドル	0.0005ドル	受信料金が安価、シンプルなプラットフォーム

Birdは送信単価で優位。Twilioはボリュームディスカウントあり。シンプルなAPI利用だけならTelnyxやPlivoも検討対象。Flow Builderによる自動化や複数チャネル統合の要件がある場合、Birdのトータルコスト優位性が際立ちます。

Birdの利用開始方法

無料アカウント作成

bird.comでアカウント登録。クレジットカード不要で1日5通のSMSテスト可。
ブランド・キャンペーン登録

米国10DLC対応にはブランド/キャンペーン登録が必須。Birdダッシュボードから申請（通常1～3営業日）。
電話番号取得

BirdのNumbers APIまたはダッシュボードでロングコード番号をプロビジョニング。
APIコール実行

REST API（JSON形式）でSMS送信。例：

   curl -X POST https://api.bird.com/v1/messages \
     -H 'Authorization: AccessKey {YOUR_API_KEY}' \
     -H 'Content-Type: application/json' \
     -d '{
       "originator": "{YOUR_NUMBER}",
       "recipients": ["{DESTINATION_NUMBER}"],
       "body": "テストメッセージ"
   }'

公式ドキュメント docs.bird.com には各種SDK（Node.js, Python, PHP, Go, Java, Ruby）・認証・Webhook設定方法も詳細に記載されています。

結論

Bird SMS APIは、米国宛送信0.00331ドルという業界最低水準の単価で利用でき、無料プランでAPIテストも容易です。Proプランでは月1,000通のSMS込みで、チームでの本格利用もすぐに開始できます。

コスト計算時は10DLCキャリア手数料・番号レンタル・国際料金などの追加費用も必ず考慮してください。特に国際送信や大量配信時は見積精度が重要です。

本番導入前は、Apidogを使ってBird SMS統合をエンドツーエンドで検証しましょう。Apidogはリクエスト設計・環境変数・テストチェーン・配信アサートをワンストップで提供します。

よくある質問

米国でのBird SMS APIのメッセージ単価は？

米国宛送信SMS：0.00331ドル、米国発信受信SMS：0.003ドルです（APIティアの基本料金）。追加で10DLCキャリア手数料が発生します。

BirdはMessageBirdと同じ？

はい。MessageBirdは2023年にBirdへリブランド。APIエンドポイントや一部ドキュメントでは旧名称が残っています。

受信SMSも課金対象？

米国発信受信SMS：1通0.003ドル。オプトアウト返信やヘルプキーワード応答も課金対象です。

無料プランの内容は？

1日5通のSMS、10通のEメール、15通のAIエージェントメッセージを無料提供。クレカ不要でAPIテスト可。

Twilioとの価格差は？

Birdの米国宛送信SMS（0.00331ドル）はTwilio（0.0079ドル）の半額以下。月10万通の場合、Birdは約331ドル、Twilioは約790ドル（ボリュームディスカウント除く）。

隠れた費用は？

10DLCブランド登録（4～44ドル）、キャンペーン登録（月10ドル/件）、番号レンタル（月1～2ドル）、国際メッセージは高額です。

実際のメッセージ送信なしでAPIテストする方法は？

ApidogのSmart Mock機能でBird API応答をシミュレート可能。BirdのサンドボックスやApidogのテストシナリオ連携で安全に検証できます。

【参考リンク】

Twilio SMS API 料金: 2026年版料金体系を徹底解説

Akira — Fri, 03 Apr 2026 03:53:33 +0000

要するに

米国ロングコードSMS（送信/受信）：1メッセージあたり $0.0083
MMS送信：$0.022 / MMS受信：$0.0165
トールフリーSMS：$0.0083（+キャリア料金）
ショートコードレンタル：ランダム 月額$1,000 / バニティ 月額$1,500
10DLCブランド登録：一回限り $4.50（2025年8月更新）、キャンペーンは月額$1.50~$10
電話番号（ロングコード）：月額$1.15 / トールフリー：月額$2.15
キャリア料金はすべての基本料金に追加
月間150,000メッセージ超で自動ボリュームディスカウント
無料トライアルあり、開始にクレジットカード不要

はじめに

Twilioは、多くの開発者にとって標準的なSMS APIです。ドキュメントが充実していてAPI設計も洗練されていますが、サイドプロジェクトから本番運用へ拡大すると、料金構造が複雑化しコストも急増します。メッセージごとの単価だけでなく、基本料金・キャリア追加料金・電話番号・10DLC登録費用などが加算されます。

Apidogを今すぐ試す

💡 SMS連携の構築前に十分なテストを！

Apidogを使えば、Twilio WebhookのOpenAPI仕様に基づく自動テストシナリオを構築できます。ステータスコードやレスポンスボディのスキーマ検証、CI/CDでの契約テストの自動化も可能です。本番移行前にApidogでSMSワークフローを無料検証しましょう。

この記事では、Twilioの料金体系の詳細、コストに影響する要素、競合サービスとの比較、開発者が押さえるべきポイントを解説します。

Twilio SMS料金の概要

Twilioは従量課金制を採用しています。メッセージセグメントごと、電話番号ごと、追加機能や登録ごとに料金が発生します。契約や最低利用料は不要（エンタープライズ契約を除く）です。

米国ロングコードSMSの基本料金は送信/受信ともに1セグメントあたり$0.0083。しかし実際にはキャリア料金や番号レンタル料、コンプライアンス登録料が毎月加算されます。

月間150,000メッセージを超えると番号タイプごとに自動でボリュームディスカウントが適用されます。

料金の内訳：SMS、MMS、トールフリー、ショートコード

ロングコードSMS（10桁の電話番号）

ロングコードは米国A2Pメッセージングの標準です。

メッセージタイプ	セグメントあたりの料金
SMS送信	$0.0083
SMS受信	$0.0083
MMS送信	$0.022
MMS受信	$0.0165

ポイント

Twilioは「1メッセージ」単位ではなくセグメント単位で課金します。GSM-7では160文字、Unicode利用時は70文字が1セグメントです。たとえば、200文字の平文SMSは2セグメント分の料金になります。

トールフリー番号

トールフリー番号もロングコードと同じSMS料金（$0.0083/セグメント）ですが、MMS受信料金は若干高くなります（$0.02）。初期費用や10DLC登録不要で、大量配信に向いていますが、最大スループットには番号検証が必要です。

ショートコード（5～6桁の番号）

ショートコードは高スループットキャンペーン向き。SMS料金は$0.0083ですが、番号レンタル料が高いです。

ショートコードの種類	月額費用
ランダム	$1,000（四半期請求）
バニティ	$1,500（四半期請求）
持ち込みバニティ	$500（四半期請求）

MMS対応時は一回限り$500のセットアップ費用が別途かかります。

ボリュームディスカウント

Twilioは番号タイプごとに自動的に階層型割引を適用します。

月間メッセージ数	セグメントあたりの料金
1～150,000	$0.0083
150,001～300,000	$0.0081
300,001～500,000	$0.0079
500,001～750,000	$0.0077
750,001～1,000,000	$0.0075
1,000,001以上	$0.0073

※ロングコード・トールフリーなどのメッセージ数は合算できません。

Twilioの請求額に影響する要因

電話番号の種類

送信元番号のタイプで適用される料金が異なります。複数番号タイプを使い分けると割引基準に到達しにくくなります。

メッセージセグメント

メッセージは1セグメント単位で課金。長文やUnicode利用時は、1通あたりのコストが倍増することも。

キャリア料金

Twilio基本料金に加え、米国キャリアごとに追加料金が上乗せされます。

ロングコードSMS送信時のキャリア追加料金例：

キャリア	送信料金
AT&T	$0.0035
T-Mobile	$0.0045
Verizon	$0.004
US Cellular	$0.005
その他	$0.004

MMSはさらに高額（AT&T: $0.009, T-Mobile: $0.01 など）。

例:

AT&T宛SMSは Twilio料金 $0.0083 + キャリア料金 $0.0035 = $0.0118/セグメント

宛先国

国際SMSは料金が大きく異なります。例：イギリス $0.04、インド $0.0029、ブラジル $0.075。

10DLC登録

米国A2P 10DLCではブランド/キャンペーン登録が必須。未登録はキャリアでブロックされます。

隠れたコストと手数料

10DLC登録費用

2025年8月以降、TCRによる新料金に更新。

ブランド登録：

個人事業主/低ボリューム：$4.50（1回）
標準（二次審査含む）：$46（1回）

キャンペーン登録：

審査費用（1回）：$15/キャンペーン
月額：タイプ別 $1.50～$10

キャンペーンタイプ	月額料金
個人事業主	$2
低ボリューム混合	$1.50
標準	$10
チャリティ/501(c)(3)	$3
緊急サービス	$5

審査異議申立てや再試行にも追加費用が発生します。

電話番号料金

ロングコード：月額$1.15

トールフリー：月額$2.15

大量番号を利用する場合は合計額に注意。

メッセージ処理失敗時手数料

「失敗」扱いのSMSごとに$0.001課金。デバッグや配信エラー時に積み重なる場合あり。

オプション機能のアドオン

エンゲージメント（リンク短縮・クリックトラッキング）やコンプライアンスツール使用時：

最初の1,000通無料、以降1通あたり$0.015加算。

サポートプラン

無料開発者サポートは制限あり。有料サポートは月額$250から。

Twilioと競合サービスの比較

プロバイダ	米国SMS送信	米国SMS受信	電話番号	10DLC要件
Twilio	$0.0083 + キャリア料金	$0.0083 + キャリア料金	$1.15/月	はい
Plivo	$0.005	$0.00035	$0.80/月	はい
Telnyx	$0.004	$0.004	$1.00/月	はい
Bird（旧MessageBird）	~$0.007	~$0.007	変動	はい

Plivo、TelnyxはTwilioより低価格。特にPlivoの受信は大幅に安価。Telnyxはキャリア料金の扱いが異なるため、総額比較が必要です。

Twilioは開発者体験・ドキュメント・グローバル展開・機能面で優位。シンプルな大量配信ならPlivo/Telnyxも選択肢。

Twilioを無料でテストする方法

Twilioはクレカ不要の無料トライアルアカウントを提供。少額クレジットが付与され、SMS送受信やWebhookテストができます。

トライアルのポイント：

テスト番号のプロビジョニング
API経由でSMS送受信
Webhook配信のテスト
コンソールや利用ログの確認

未検証番号宛SMSには"Sent from your Twilio trial account"のプレフィックスが付きます。削除には有料アップグレードが必要。

アップグレード後も従量課金で最低利用料なし。

ApidogでTwilio SMS連携をテストする方法

Twilio認証情報とWebhookを設定後、Apidogのテストシナリオを使って連携テストを自動化できます。手動テストでは検出しにくいWebhook仕様の不一致もキャッチ可能です。

テストシナリオ構築手順例：

TwilioのWebhookエンドポイント仕様をApidogテストシナリオにインポート
SMS送信・配信コールバック受信・返信処理など各メッセージフローのステップを追加
オーケストレートモードでステップを並べ、順番に実行
{{$.stepId.response.body.field}} 形式でデータをステップ間連携（例：メッセージSIDを利用）

これにより、Twilio APIの実際の利用フロー（送信→SID返却→Webhook受信）を自動テストとして再現できます。

契約テスト

Apidogの契約テスト機能で、OpenAPI仕様とレスポンスの自動突合。

HTTPステータスコード一致
必須フィールドの存在確認
各フィールドの型検証
余分なフィールドの検出

独自アサーションスクリプトを記述せずに、仕様準拠の自動検証が可能です。

はじめ方

Apidogを無料でダウンロードし、Twilio API仕様をインポート。Webhookスキーマを定義し、SMS送受信フローを模倣するテストシナリオを組みましょう。

結論

Twilio SMS APIの料金は米国ロングコードで$0.0083/セグメントからですが、実際はキャリア料金・番号レンタル・10DLC登録料も加算されます。AT&T宛送信なら$0.0118/セグメント、10DLCキャンペーンは月額$10追加も。

料金体系は透明で、ボリュームディスカウントも自動適用。ただし見かけの単価だけでなく総コストを見積もることが重要です。

コスト算出後は、連携を構築し、Apidogのテストシナリオ＆契約テストでWebhookフローやAPIレスポンスの自動検証を行いましょう。

よくある質問

Q: Twilioでの米国SMS送信の基本料金はいくらですか？

A: 米国ロングコードSMS送信は$0.0083/セグメント。キャリア料金が上乗せされます。AT&T宛なら$0.0118。

Q: Twilioは受信SMSにも課金しますか？

A: はい。ロングコード・トールフリーで$0.0083/セグメント。発信元キャリアによっては追加料金も。

Q: 10DLCとは？費用は？

A: 10DLCは米国のA2P SMS登録制。ロングコード利用時はブランド登録$4.50（1回）、キャンペーン種別で月額$1.50～$10。

Q: Twilioのショートコード料金は？

A: ランダムショートコードは月額$1,000（四半期請求）、バニティは月額$1,500＋MMS有効時は$500（1回）。SMS料金は$0.0083。

Q: Twilioはボリュームディスカウントを提供している？

A: はい。月間150,000通超で自動割引（最大で$0.0073/セグメント）。エンタープライズは個別交渉でさらに割引。

Q: Twilioの無料トライアルはある？

A: あり。クレジットカード不要、クレジット付き。トライアル中はSMSにプレフィックス付き。

Q: SMSでTwilioの安価な代替は？

A: Plivo（送信$0.005/受信$0.00035）、Telnyx（$0.004）等。いずれも10DLC登録は必須。Twilioはドキュメントと機能面で優位。

Apidogを今すぐ試す:

https://apidog.com/?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation

Vonage SMS API 料金はいくらですか？ (2026年価格)

Akira — Fri, 03 Apr 2026 03:48:08 +0000

TL;DR

Vonage SMS APIの料金は、米国では送信メッセージあたり$0.00809、受信メッセージあたり$0.00649から。月額最低料金なし。国際料金は国によって異なり、一部市場で$1.00/通超も。Vonage SMS統合を構築・テストする際は、Apidogでテストリクエスト送信、応答検証、エラー捕捉が可能です。

今すぐApidogを試す

はじめに

Nexmoをご存知の方は、既にVonageにも馴染みがあるでしょう。2016年にVonageがNexmoを買収し、開発者用SMS・通信API基盤としてdeveloper.vonage.com（旧nexmo.com/developers）が今も稼働中です。2022年にはエリクソンがVonageを買収し、API事業はグローバル通信大手の一員となりました。

現在Vonageは10万社超・160万人超の開発者にAPIを提供。従量課金、契約縛りなし、190カ国以上対応の成熟したプラットフォームです。

💡 統合を進める前に、APIテストツールが必須です。ApidogならVonage SMSリクエストのテストシナリオを構築し、応答検証や複数API呼び出しのワークフロー自動化が可能。無料トライアル、クレカ不要。

Vonage SMS料金概要

VonageのSMS APIは従量課金制。月額や初期費用は不要で、メッセージごとに支払い。料金は送信先国や番号種別で変動します。

米国の料金例：

メッセージタイプ	メッセージあたりの料金
送信SMS（米国LVN）	$0.00809
受信SMS（米国LVN）	$0.00649
送信SMS（米国フリーダイヤル）	営業担当者にお問い合わせ
受信SMS（米国フリーダイヤル）	無料

LVNはLocal Virtual Number（標準10DLC長番号）。料金は国ごとに異なり、リアルタイムで請求額が計算されます。

グローバル料金表は公式ダッシュボードからダウンロードでき、国際キャンペーンのコスト見積もりに活用できます。

料金の内訳：送信、受信、MMS、WhatsApp

送信SMS

アプリ→ユーザーへの送信は、米国LVNなら$0.00809/通（2026年初頭時点）。公式ダッシュボードで最新料金を確認してください。

受信SMS

Vonage番号で受信するSMSは、米国LVNなら$0.00649/通。フリーダイヤル番号は無料のものもありますが、アカウントで要確認。

MMS料金

MMSはMessages API経由で送信可能ですが、単価は非公開。営業チームに問い合わせが必要です。

Vonage経由のWhatsApp

Messages API経由でWhatsApp送信が可能。料金体系は：

WhatsApp側の課金（Meta）：会話カテゴリごとに異なる。最新はMeta公式料金ページ参照。
Vonageプラットフォーム料金：$0.00015/通～。カテゴリ・ボリュームで変動。

Facebook Messenger

Vonage経由でFacebook Messengerは$0.0011/通（Messages API経由）。

RCS（リッチコミュニケーションサービス）

米国キャリアごとのRCS料金：

キャリア	RCSリッチ（テキスト）	RCSリッチメディア
T-モバイル	$0.00620	$0.01250
ベライゾン	$0.00400	$0.00600
AT&T	$0.00450	$0.01000
USセルラー	$0.00620	$0.01350

RCSには国ごとに$600の一回限り設定料も発生。

Vonageの請求額に影響するもの

送信先の国: アメリカは安価。アフリカ・東南アジアなどは高額のことも（$0.50/通超）。
番号の種類:
- ロングコード(10DLC): 標準番号。最も安価。
- フリーダイヤル番号: A2P向け。受信は無料なことが多い。
- ショートコード: 大量配信向け。レンタル料高。
番号レンタル料: 仮想番号は月数ドル～。種類により異なる。
メッセージエンコーディング: GSM-7は160文字/通、Unicode含むと70文字/通。長文や絵文字でコスト増に注意。
キャリア課徴金: 10DLC A2Pはキャリア独自の追加料金あり。Vonage請求書に反映。

見落としがちな隠れたコスト

サポートティア

無料はコミュニティ/ドキュメントのみ。有料ビジネスサポートは月$3,300（24/7/365電話・専任担当）。

アドオンAPI

アドオン	月額料金
監査API	$550/月
自動編集（PII削除）	$1,100/月
レポートAPI	$495/月（または$0.00049/CDR従量）

監査APIは厳格なコンプライアンス用途、自動編集はPII削除機能。

Verify APIコスト

二要素認証に使う場合、認証成功あたり$0.0572。失敗してもメッセージ料金は発生。

番号登録（米国10DLC）

A2P SMS送信にはTCR登録が必須。

ブランド登録：一回限り
キャンペーン登録：月額発生

未登録はメッセージがフィルタ対象。

Vonage vs 代替サービス

米国送信SMSの主要サービス比較：

プロバイダー	米国送信SMS	米国受信SMS	無料トライアル	サポート
Vonage	$0.00809	$0.00649	あり（認証済番号のみ）	有料（月$3,300の24/7/365）
Twilio	$0.0079	$0.0075	あり（$15クレジット）	月$250～有料サポート
Plivo	$0.0055	$0.0005	あり	基本無料/有料ティア
Telnyx	$0.004	$0.002	あり（$5クレジット）	メールは無料・電話は有料

Telnyxは最安だがサポート規模小
Plivoは受信が安く開発者評価も高い
Twilioは最大規模・統合多数・ドキュメント充実
Vonageは中間価格で、エリクソン傘下の信頼性・国際ネットワークが強み

価格だけでなく配信率、規制遵守、開発者ツール、サポートも考慮しましょう。

Vonageを無料で試す方法

Vonageは無料のトライアルアカウントを提供しています。主な内容と制約：

得られるもの

テスト用Vonage仮想番号
APIキー・シークレット
開発者向けドキュメント・SDK
テストクレジットで少量送信可

制限事項

認証済み電話番号のみに送信可能（不正防止）
有料化しないと任意番号送信不可

開始手順

dashboard.nexmo.com または vonage.com/communications-apis にアクセス
メールアドレスでアカウント作成
電話番号認証
ダッシュボードでAPIキー・シークレット取得
REST APIまたは公式SDKでAPIコール

Vonage SDKはNode.js、Python、PHP、Ruby、Java、.NET、Go対応。任意HTTPクライアントでREST APIも可。

ApidogでVonage SMS統合をテストする方法

APIキー・シークレット取得後は、本番前に統合テストが必須。Apidogはこのために設計されています。

テストシナリオのセットアップ

Apidogのテストモジュールで新規シナリオを作成。以下の方法でステップ追加：

OpenAPI形式のAPI仕様からインポート
Vonage REST APIエンドポイントにカスタムリクエスト追加
Vonage公式ドキュメントのcURLコマンドをインポート

例：SMS送信テストはhttps://rest.nexmo.com/sms/jsonにPOSTリクエスト。APIキー、シークレット、送信元・送信先・本文をフォームパラメータで指定。

応答の検証

Apidogは応答を自動スキーマ検証。Vonage SMS APIでは、messages配列のstatusが0で成功。

アサーション例：

ステータスコード200
messages[0].status == "0"
messages[0].message-idが非空

エラー時は応答本文を確認し、素早くデバッグ可能。

リクエスト間のデータ受け渡し

{{$.stepId.response.body.field}}構文で、1つ目の応答（例：message-id）を2つ目のリクエストで利用できます。

CI/CDでのテスト自動化

ApidogはGitHub Actions、GitLab CI、Jenkinsと連携可能。テストシナリオをエクスポートし、CLIで自動実行。PRごとにSMS統合の回帰テストを実施可能です。

Apidog.comで無料トライアル。クレカ不要。

まとめ

Vonage SMS APIは従量課金制。月額最低料金なし。米国送信SMSは$0.00809/通、受信は$0.00649/通。コストは送信先国・番号種別・エンコーディングで変動。監査APIや24時間サポートなどのプレミアム機能は月額コスト増。予算計画時に考慮必須。

代替サービス比較では、Telnyx・Plivoは安価、Twilioはエコシステム規模でリード。Vonageはエリクソンのネットワークを活かした信頼性と国際カバレッジが強み。

本番移行前にApidogでVonage統合のテストシナリオを構築し、全ワークフロー・応答を検証、エラーを開発段階で検出しましょう。

よくある質問

VonageはNexmoと同じ？

はい。Vonageは2016年にNexmoを買収。developer.vonage.comでAPI提供中。rest.nexmo.comエンドポイントも旧統合で現役。両者は同一製品。

VonageはSMSで月額費用がかかる？

SMS API自体は月額なし。送信/受信ごと+番号レンタル料のみ。監査API等のアドオンは別途月額。

Vonage番号のレンタル料金は？

米国のLVNは月数ドル～。フリーダイヤル・ショートコードはさらに高額。最新料金はダッシュボードで要確認。

Vonage SMSはどの国で使える？

190カ国超でサポート。料金は大幅に異なる。特定国は$0.50/通超の例も。グローバル料金表はダッシュボードでダウンロード可能。

ボリュームディスカウントはある？

あり。大量送信者は営業へ相談しカスタム料金の交渉が可能。なければデフォルトの従量課金制。

受信SMSは無料？

米国フリーダイヤル番号は多くの場合無料。ロングコードは$0.00649/通。国ごとに異なるので要確認。

VonageとTwilioの比較は？

米国送信SMS単価はVonageが$0.00809、Twilioが$0.0079。Twilioはエコシステム/統合/ドキュメントで優位。Vonageはエリクソンのネットワークによる信頼性・国際展開が強み。価格差は小さいため、最終判断は開発体験・サポート品質次第。

API開発者にとってCursor 3は何を意味するのか？

Akira — Fri, 03 Apr 2026 03:43:08 +0000

要約: Cursor 3は2026年4月2日にリリースされ、IDEファーストのインターフェースをエージェントファーストのワークスペースに置き換えました。API開発者にとって最大の変化は、並列エージェント実行、よりリッチなMCPツール出力、そしてワークフローを中断なく実行し続けるクラウドからローカルへのハンドオフです。Cursor 3をApidogのMCPサーバーと組み合わせると、AIエージェントがライブAPI仕様を読み取り、コピー＆ペーストなしで正確なスキーマ認識コードを生成できます。

今すぐApidogを試してみよう

おそらく予感していた変化

AIコードエディターは2年間で賢くなってきましたが、Cursor 3は単なるアップデートではなく、AI開発環境の構造そのものを再設計しています。

Cursor 3以前は、ファイルを開き、エージェントに指示し、差分を確認して作業を進める従来のIDE的なワークフローが中心でした。エージェントはオンデマンドアシスタントとして機能していましたが、Cursor 3ではエージェントが作業単位の中心になります。複数のエージェントを同時に起動し、並列で出力を比較・選択できます。

API開発では複雑な連携や同時進行タスクが多いですが、Cursor 3によりツール側でもそれに適応したワークフローが実現します。

💡Cursor 3単独ではAPI仕様を認識できません。ここでApidog MCPサーバーが重要です。接続すれば、CursorエージェントがApidogからOpenAPIスキーマ、エンドポイント、テストシナリオを直接取得でき、仕様準拠のコード生成が可能になります。

この記事では、Cursor 3の変更点、API開発への影響、Cursor 3とApidog MCPサーバーを組み合わせた具体的なワークフローを解説します。

Cursor 3の新機能

Cursor 3は2026年4月2日リリース。主な新機能とAPI開発者視点での活用ポイントを紹介します。

エージェントウィンドウ

エディター中心のレイアウトからエージェント中心のレイアウトへ移行。複数リポジトリで同時にエージェントを実行可能。ローカル・クラウド・SSH環境でもOK。

Cmd+Shift+P → Agents Windowでアクセス。IDEを併用しつつ、エージェントの並列実行や管理ができます。

例えば一方のエージェントで新APIエンドポイントの実装、もう一方で共有ライブラリのバグ修正といった作業を同時進行し、成果物をレビュー・統合できます。

デザインモード

デザインモードではブラウザUIに直接注釈を付与可能。要素選択や領域ハイライト→説明なしでエージェントの指示文脈に追加できます。API＋Webフロントの連携作業で「右上のボタン」などの曖昧な指示が不要に。

ショートカット:

Cmd+Shift+Dでデザインモード切替
Shift+ドラッグで領域選択
Cmd+Lで要素をチャットに追加

MCPアプリ: 構造化出力

Cursor 3ではMCPツール出力がリッチかつ構造化データとして返せます。

ApidogのMCPサーバーと組み合わせれば、API仕様やテスト結果がエージェントにクリーンなデータとして伝わり、より高精度なコード生成や検証が可能です。

/worktree, /best-of-nコマンド

/worktree：分離ワークツリーで破壊的変更や別実装を安全に試せます。

/best-of-n：複数モデル（Claude, GPT-4o, Gemini等）で同じタスクを並列実行し成果物を比較可能。API設計・実装時の多様なアプローチ検討に有効。

クラウドからローカルへのハンドオフ

エージェントセッションをクラウドとローカル間で自由に移動。重いタスクをクラウドで走らせ、ローカルで実サービス検証、もしくは逆のフローも可能。

API開発にとっての意味

API開発は仕様、クライアント、エディター、ターミナル、ドキュメント間でのコンテキストスイッチが多い作業です。Cursor 3とMCPレイヤー連携で、この分断を埋める実践的なワークフローが作れます。

並列エンドポイント開発

例えば10個のRESTエンドポイントを個別エージェントで同時に実装、成果物のレビュー・統合が可能です。スプリント圧縮やリリースサイクル短縮に直結します。

スキーマ認識型コード生成

Apidog MCPサーバーと接続すれば、エージェントがOpenAPI仕様から直接スキーマ情報を取得。フィールド名・型・ネスト構造・必須/任意情報を正確に反映したコードが即座に生成できます。

エディター内コントラクトテスト

Cursor 3エージェントはターミナルコマンド実行にも対応。Apidog CLIと統合すれば、エディター内で自動化コントラクト検証を実装できます。

apidog run --scenario <test-id>

エージェントがテスト失敗時に自動修正を繰り返すワークフローも構築可能です。

ドキュメントの最新状態維持

APIコードと仕様ドキュメントのずれは、エージェントがMCP経由で両方を比較し、差分を指摘・修正提案できます。レビューサイクルに組み込むことで、ドキュメントの陳腐化を防げます。

変更されていない点

Cursor 3はAPI自動テストや認証・レート制限の自動検出等は行いません。あくまでエージェントインターフェースであり、QAは別途専用ツールで担保する必要があります。また、MCPサーバーの構造化出力対応状況はサーバーごとに異なります（Apidog MCPサーバーは対応済み）。

Cursor 3 + Apidog MCPサーバー: 実践ワークフロー

セットアップ

CursorのMCP設定にApidog MCPサーバーを追加。下記の設定例を参考にしてください。

{
  "mcpServers": {
    "apidog": {
      "command": "npx",
      "args": ["-y", "@apidog/mcp-server@latest"],
      "env": {
        "APIDOG_ACCESS_TOKEN": "your_access_token"
      }
    }
  }
}

アクセストークンはApidog「アカウント設定」→「APIアクセストークン」で取得。接続後はget_endpoint_detailやget_schemaなどのツールを利用できます。

ワークフロー例: 仕様から新エンドポイントを足場固め

Apidogで新エンドポイントPOST /invoicesを定義し、スキーマ・テストシナリオをリンク
エージェントウィンドウで新セッション開始、下記のように指示

「Apidogプロジェクト内のPOST /invoicesエンドポイントを検索し、スキーマに合致するNode.js/Expressハンドラーを生成、テストシナリオで検証せよ」

エージェントはMCP経由で仕様取得→コード生成→CLIでテスト実行→失敗時自動修正
成果物をレビューし、必要ならマージ

/best-of-nで複雑な実装比較

複雑なエンドポイント実装には/best-of-nを利用。3モデルで同時生成し、Cursorワークツリーで比較。仕様はMCP経由で統一的に取得されるため、モデルごとの差異は実装方針やエラー処理に集約されます。

ドキュメント同期

新APIリリース後、エージェントに下記のように指示

「POST /invoicesのApidogドキュメントとinvoices.jsのコードを比較し、不一致箇所を指摘、必要なら仕様かコードを修正」

MCP経由で両者を比較→修正提案→承認/拒否

この一連の流れをパイプラインやCIと連携することで、APIドキュメントの陳腐化を防げます。

実践セットアップ手順

ステップ1: Cursor 3へアップグレード

cursor.comから最新版をダウンロード
Cmd+Shift+P →「Agents Window」で新UIを起動

ステップ2: Apidogアクセストークン生成

Apidogログイン→「アカウント設定」→「APIアクセストークン」で新規作成・コピー

ステップ3: MCPサーバー設定追加

Cursor「設定」→「MCP」で下記を追加

{
  "mcpServers": {
    "apidog": {
      "command": "npx",
      "args": ["-y", "@apidog/mcp-server@latest"],
      "env": {
        "APIDOG_ACCESS_TOKEN": "your_token_here",
        "APIDOG_PROJECT_ID": "your_project_id"
      }
    }
  }
}

プロジェクトIDはApidogのURL等で確認

ステップ4: 接続確認

エージェントウィンドウ新セッションで「Apidogプロジェクト内のエンドポイントをリストしてください」と入力
エンドポイント一覧が返ればOK

ステップ5: Apidog CLIインストール

npm install -g apidog-cli
apidog -v

Apidogの各テストシナリオ「CI/CD」タブにCLIコマンドが記載されています。これをCursorターミナルやエージェントワークフローで活用可能

ステップ6: 実際のMCPタスクを試す

例：「ApidogのUserスキーマを検索し、完全一致するTypeScriptインターフェースを生成せよ」
スキーマと出力が合致すれば統合成功です

ここから、仕様→コード生成→テストまで一気通貫のワークフローを構築できます。

まとめ

Cursor 3はAIと協働する開発環境のあり方を一新しました。エージェント中心設計により、API開発の現場に即した並列作業・ドキュメント同期・スキーマ認識型コード生成が実現します。

Apidog MCPサーバー＋CLIとの連携で、エージェントが仕様に基づいた正確なコードを生成し、テスト＆検証まで自動化されたループを毎日の開発フローに組み込めます。

よくある質問

Cursor 3は既存のIDEインターフェースを置き換えますか？

いいえ。Cursor 3は新しいエージェントウィンドウを追加するだけで、従来のIDEも併用可能です。

Cursor 3と従来版の主な違いは？

アーキテクチャが大幅刷新。エージェント中心・並列実行・クラウド/ローカル間ハンドオフ・デザインモード・/worktree・/best-of-nコマンド等が追加されました。

Apidog MCPサーバーはCursor 3とどう連携しますか？

Cursorの「設定」からMCPサーバーとして追加。API仕様・スキーマ・テストシナリオを直接ツール呼び出しでき、エージェントが型付きデータとして受け取れます。

Cursor 3エージェントはApidogテストシナリオを自動実行できますか？

はい。Apidog CLIと組み合わせれば、エージェントが自動でテストシナリオ実行・結果取得・修正提案までをループ可能です。

エージェントウィンドウ利用に有料プランは必要？

エージェントウィンドウ自体は全プランで利用可能。クラウドエージェント実行など一部機能は有料サブスクリプションが必要です。詳細は cursor.com/pricing を参照してください。

OllamaでGemma 4をローカルで実行する方法：完全ガイド

Akira — Fri, 03 Apr 2026 02:47:16 +0000

TL;DR

Gemma 4 は2026年4月3日にリリースされ、Ollama v0.20.0 は同日サポートを追加しました。デフォルトの gemma4:e4b モデルは2つのコマンドでプルして実行できます。このガイドでは、セットアップ、モデル選択、API使用法、Apidog を使用したローカルの Gemma 4 エンドポイントのテスト方法について説明します。

Apidog を今すぐ試す

はじめに

Google は Gemma 4 を2026年4月2日にリリースしました。24時間以内に、Ollama は v0.20.0 をリリースし、4つのモデルバリアントすべてを完全にサポートしました。

これは開発者にとって重要です。Gemma 4 は単なるマイナーアップデートではありません。Gemma 3 の 20.8% と比較して、AIME 2026 で 89.2% のスコアを記録しています。コーディングベンチマークスコアは Codeforces で 110 ELO から 2150 に跳ね上がりました。ネイティブ関数呼び出し、設定可能な思考モード、そして大規模バリアントでは 256K のコンテキストウィンドウが利用できます。これらすべてが、独自のハードウェア上で動作します。

APIを活用したアプリを構築している場合、ローカルセットアップは多くのメリットがあります。モックデータ生成、テストシナリオ作成、APIレスポンス検証などを、プライベートかつ低レイテンシなAIレイヤーで行えます。

💡 Gemma 4 をローカルで実行できるようになれば、Apidog の Smart Mock で、スキーマからリアルな API レスポンスデータを生成できます。API の形式を一度定義すれば、以降のモックデータ生成は自動化され、スキーマ準拠のテストデータでローカルモデルの実験がスムーズに進められます。

このガイドでは、インストールから最初のローカルAPI呼び出しまで、すべての手順を解説します。

Gemma 4 の新機能

Gemma 4 は4つのモデルバリアントを提供します。

Gemma 3 からの主な進化ポイント：

推論とコーディング: 31BモデルはLiveCodeBench v6で80%達成。旧27Bは29.1%。
Mixture-of-Experts (MoE) アーキテクチャ: 26BバリアントはMoEを採用し、推論時のパラメータ数は4Bのみ。高速かつ高品質。
長いコンテキスト: E2B/E4Bは128Kトークン、26B/31Bは256Kトークンまで対応。
ネイティブ関数呼び出し: 関数スキーマを定義するだけで、構造化JSONを返す。
音声・画像入力: E2B/E4Bは音声や画像も入力可能。
思考モード: リクエストごとに連鎖的思考推論のON/OFF切り替えができる。

Gemma 4 モデルバリアントの解説

利用する前に、ハードウェアに合ったモデルを選択しましょう。

モデル	ディスク上のサイズ	コンテキスト	アーキテクチャ	最適な用途
`gemma4:e2b`	7.2 GB	128K	Dense	ラップトップ、エッジ、音声/画像
`gemma4:e4b` (デフォルト)	9.6 GB	128K	Dense	ほとんどの開発者
`gemma4:26b`	18 GB	256K	MoE (4B アクティブ)	GBあたりの最高品質
`gemma4:31b`	20 GB	256K	Dense	最高品質

e4b は ollama run gemma4 のデフォルト。10GB以上のVRAMまたはApple Siliconで高速動作。
26b MoE バリアントは、20GB+ RAMで高速かつ高品質。要件を満たすならおすすめ。

前提条件

Ollama v0.20.0 以上必須。
バージョン確認:

  ollama --version

アップデート:

  # macOS
  brew upgrade ollama

  # Linux
  curl -fsSL https://ollama.com/install.sh | sh

Windowsは ollama.com から最新版をダウンロード。

ハードウェア要件:

gemma4:e2b: 最小8GB RAM (16GB推奨)
gemma4:e4b: 10GB VRAMまたは16GBユニファイドメモリ
gemma4:26b: 20GB+ RAMまたはユニファイドメモリ
gemma4:31b: 24GB VRAMまたは32GBユニファイドメモリ

Gemma 4 のインストールと実行

デフォルト (e4b) モデルのプル＆実行:

ollama run gemma4

初回で約9.6GBダウンロード後、インタラクティブセッションが開始されます。

例：

>>> クライアントエラーのHTTPステータスコードは何ですか？

他バリアントの実行

# 小型エッジモデル
ollama run gemma4:e2b

# MoE高品質バリアント
ollama run gemma4:26b

# フル・フラッグシップ
ollama run gemma4:31b

モデルのみプル

ollama pull gemma4
ollama pull gemma4:26b

所有モデル確認

ollama list

ローカルで Gemma 4 API を使用する

Ollama は http://localhost:11434 でREST APIを公開。CLI不要でAPI呼び出し可能。

補完の生成

curl http://localhost:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4",
    "prompt": "Write a JSON response for a user profile API endpoint",
    "stream": false
  }'

チャット補完 (OpenAI互換)

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4",
    "messages": [
      {
        "role": "user",
        "content": "Generate a realistic JSON mock for an e-commerce order API response"
      }
    ]
  }'

Python クライアント例

import requests

def ask_gemma4(prompt: str, model: str = "gemma4") -> str:
    response = requests.post(
        "http://localhost:11434/api/generate",
        json={
            "model": model,
            "prompt": prompt,
            "stream": False
        }
    )
    response.raise_for_status()
    return response.json()["response"]

result = ask_gemma4("List the fields a payment API response should include")
print(result)

OpenAI Python SDK を利用

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # 必須だがOllama側では未使用
)

response = client.chat.completions.create(
    model="gemma4",
    messages=[
        {
            "role": "system",
            "content": "You generate realistic API response data in JSON format."
        },
        {
            "role": "user",
            "content": "Generate a sample response for a GET /users/{id} endpoint"
        }
    ]
)

print(response.choices[0].message.content)

Gemma 4 で関数呼び出しを使う

Gemma 4はネイティブの関数呼び出しに対応。ツールスキーマ定義に基づき構造化JSONを返します。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_user",
            "description": "Retrieve a user by ID from the API",
            "parameters": {
                "type": "object",
                "properties": {
                    "user_id": {
                        "type": "integer",
                        "description": "The unique user ID"
                    },
                    "include_orders": {
                        "type": "boolean",
                        "description": "Whether to include order history"
                    }
                },
                "required": ["user_id"]
            }
        }
    }
]

response = client.chat.completions.create(
    model="gemma4",
    messages=[
        {"role": "user", "content": "Get user 42 with their order history"}
    ],
    tools=tools,
    tool_choice="auto"
)

tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.name)       # get_user
print(tool_call.function.arguments)  # {"user_id": 42, "include_orders": true}

思考モードの有効化

複雑なタスクやAPI仕様の分析には、思考モードを有効にしましょう。

response = client.chat.completions.create(
    model="gemma4",
    messages=[
        {
            "role": "user",
            "content": "Design a complete test scenario for a payment processing API with edge cases"
        }
    ],
    extra_body={"think": True}
)

print(response.choices[0].message.content)

単純なリクエストには思考モード不要です（レイテンシ増加防止）。

Apidog で Gemma 4 API レスポンスをテストする

ローカル Gemma 4 インスタンス起動後、Apidog でエンドポイントを体系的にテストできます。

ステップバイステップ

Ollama API 仕様をインポート

Apidogで新規プロジェクトを作成し、http://localhost:11434 をベースURLに設定します。
エンドポイント定義
- POST /api/generate（シングルターン補完用）
- POST /v1/chat/completions（チャット用）
- GET /api/tags（モデル一覧取得用）
テストシナリオ設定
- ステップ1: GET /api/tags で gemma4 の存在確認
- ステップ2: POST /api/generate でプロンプト送信、response フィールド非空を検証
- ステップ3: POST /v1/chat/completions でレスポンス形式を検証

Apidogの「変数抽出プロセッサ」でレスポンス連携も可能。

レスポンススキーマ検証

OpenAPI仕様に基づき契約テスト設定。モデル更新時にも破壊的変更を検知。
Smart Mock の活用

Apidog の Smart Mock で、Gemma 4 レスポンス形式を事前に定義→フロント・バックエンド並行開発やモックデータ生成に即活用可能。

Gemma 4 によるマルチモーダル入力

E2B/E4Bモデルはテキストと画像を同時入力可能。画像はbase64エンコードで送信します。

import base64

with open("api_diagram.png", "rb") as f:
    image_data = base64.b64encode(f.read()).decode()

response = client.chat.completions.create(
    model="gemma4:e4b",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "image_url",
                    "image_url": {
                        "url": f"data:image/png;base64,{image_data}"
                    }
                },
                {
                    "type": "text",
                    "text": "Describe the API flow shown in this diagram and identify potential error paths"
                }
            ]
        }
    ]
)

アーキテクチャ図の解析やAPI仕様の画像レビューにも活用できます。

よくある問題と修正

Ollamaがモデルが見つからない:

ollama pull gemma4 で取得、ollama list で確認。
CPUでの推論が遅い:

GPU推奨。CPUのみなら gemma4:e2b を選択。
メモリ不足:

ollama ps でVRAM/RAMチェック。小型モデルに切り替え。
Apple Siliconでモデルが動かない:

Ollama 0.20.0以上へアップデート。
ポート競合:

OLLAMA_HOST=0.0.0.0:11435 ollama serve で別ポート指定。
レスポンスが途中で切れる:

"options": {"num_ctx": 8192} をリクエストに追加。

Gemma 4 と他のローカルモデルの比較

モデル	最適サイズ	コンテキスト	関数呼び出し	コーディングベンチマーク
Gemma 4	e4b (9.6 GB)	128K-256K	ネイティブ	LiveCodeBench 80%
Llama 3.3	70B-Q4 (40 GB)	128K	ネイティブ	LiveCodeBench 約60%
Qwen3.6-Plus	72B-Q4 (44 GB)	128K	ネイティブ	強力
Mistral Small	24B (14 GB)	128K	ネイティブ	中程度

MoE 26Bバリアントは18GBで高品質・高速推論。
31Bはコーディングタスクで大規模モデルと競合可能。
軽量モデル（e2b）はエッジやラップトップ向け。

結論

Gemma 4 + Ollama は現時点で最高クラスのローカルAIセットアップです。

インストールはわずか2コマンドで、ほとんどの開発者PCでデフォルトモデルが動作。

ollama run gemma4 で起動し、Apidog でAPIテスト→最適バリアント選択でワークロードに合わせた運用を。

Gemma 4上でAPI駆動機能を開発するなら、ローカル推論・ApidogのSmart Mock・テストシナリオを組み合わせて、リモート依存ゼロの開発ループが構築できます。

よくある質問

Q: 新しいバージョンが出た時の更新方法は？

A: ollama pull gemma4 で差分のみ取得します。

Q: GPUなしでも動きますか？

A: 可能ですが低速です。CPUのみなら e2b モデル推奨。

Q: e2b と e4b の違いは？

A: 両者とも高密度なエッジ向けモデル。E4Bはパラメータ数多く、複雑な推論に強い。E2Bは小型かつ音声入力対応。多くのテキスト処理にはE4B推奨。

Q: LangChain/LlamaIndexと連携可能？

A: どちらもOllamaバックエンド対応。http://localhost:11434 を指定し、モデル名に gemma4 を設定。

Q: OpenAI API向けコードと互換性は？

A: 多くの場合互換。Ollamaの /v1/chat/completions を利用し、base_urlとapi_keyを調整。

Q: 思考モードの使い方は？

A: OpenAI SDKでは extra_body に "think": true、直接APIの場合はリクエストJSONに "think": true を追加。

Q: 他マシンからAPI公開は？

A: OLLAMA_HOST=0.0.0.0:11434 ollama serve で外部公開。

Q: API開発タスク向きのモデルは？

A: モック生成・テストは e4b、複雑な分析は 26b MoE がおすすめ。

DEV Community: Akira

ジョブサーチ自動化：オープンソースAI活用術【転職成功ガイド】

要約

はじめに

Career-Opsが実際にすること

コアワークフロー

14のスラッシュコマンド

A-Fスコアリングエンジンの仕組み

ATSに最適化されたPDF生成

大規模なポータルスキャン

並列サブエージェントによるバッチ処理

Go TUIダッシュボード

15分でセットアップ

自動更新システム

Career-Opsが他の求職ツールと異なる点

知っておくべき制限事項

対象者

始め方

結論

よくある質問

2026年 おすすめ オープンソース コーディングアシスタント：無料のCursor代替案

要点

はじめに

2026年にオープンソースコーディングアシスタントが現実的になった理由

最高のオープンソースコーディングアシスタント5選

1. Continue.dev

2. Aider

3. Cline

4. Modo

5. Void editor

比較表

適切なものの選び方

ApidogがAIコーディングワークフローにどう適合するか

テストワークフロー

例：GitHub APIクライアント検証

まとめ

よくある質問

AIエージェントのメモリの仕組み (APIでテストする方法)

要するに

はじめに

AIエージェントメモリとは何か？

エージェントメモリの4つのタイプ

ワーキングメモリ

エピソード記憶

セマンティック記憶

手続き記憶

実際のシステムでのメモリの保存方法

エージェントメモリがAPIの挙動に与える影響

ApidogでAPI経由でエージェントメモリをテストする方法

テスト1：コンテキストの引き継ぎ

テスト2：セッション分離

テスト3：メモリ障害時の劣化

テスト4：コンテキストウィンドウのオーバーフロー

よくあるメモリ障害モード

結論

よくある質問

LLMをゼロから構築する方法：得られる学び

要約

はじめに

言語モデルが「小さい」とは？

主要コンポーネント：LLMの実際の仕組み

トークナイザー

埋め込み層

トランスフォーマーブロック

出力ヘッド

Pythonで最小限のLLMを構築する

トレーニングループ

推論（テキスト生成）

これがAI APIの挙動について教えてくれること

Temperatureとサンプリングは単なるパラメータ

コンテキストウィンドウは厳密で、緩やかなものではない

ストリーミングトークン = 推論ループの可視化

ロジット分布は構造化出力の難しさを示す

ApidogでAI APIの統合をテストする方法

トークン数アサーションのテスト

応用編：量子化と推論の最適化

量子化

KVキャッシュ

小さなLLMと本番API：それぞれの使い分け

結論

2026年おすすめオープンソースコーディングアシスタント：無料のCursor代替案

Seedance 2.0 API 2026年版使い方ガイド

初めてのテキスト-to-ビデオリクエスト