2026.09.30 テスト

Talend API Testerの使い方：Free Editionの制限とCI化・Postman比較まで解説

Q: Talend API Testerで送ると500が返るのにcurlでは成功するのはなぜですか？

最も疑わしいのは、Chrome 80以降の拡張機能が自動で付ける Sec-Fetch-Dest 、 Sec-Fetch-Site 、 Sec-Fetch-Mode の3ヘッダーです。公式FAQに、サーバーがこれらを正しく扱えず空のボディで500を返す例が載っています。curlでこの3ヘッダーを足して再送し、同じ500になれば原因はサーバー側です。拡張機能の権限が「すべてのサイト」になっていない場合も、ヘッダーがブラウザに上書きされて結果が変わります。

Talend API Testerの使い方：Free Editionの制限とCI化・Postman比較まで解説

Talend API TesterはChromeの拡張機能として動くAPIクライアントで、アカウント登録なしでGETやPOSTを送れる手軽さから、APIの動作確認用に広く入れられています。ただし無料のFree Editionには、シナリオを1本しか持てない、データがブラウザ内にしか残らない、CIから実行できないという公式の制限があります。この記事ではインストールからGET・POST送信、環境変数、アサーション、シナリオまでの使い方を公式ドキュメント準拠で並べ、ブラウザ拡張ゆえに起きるSec-Fetch系ヘッダーの落とし穴、Maven pluginによるCI化の前提、Postmanへ移るべき判断基準まで整理しました。

まとめ：Talend API Testerを使う前に押さえる制限と採用判断の結論

Talend API Testerは、1人でAPIの疎通を確かめる用途なら十分に回るツールです。Chromeウェブストアから入れれば数分で最初のリクエストを送れ、ステータスコードやJSONパスのアサーションもGUIで組めます。

無料版の限界は機能ではなく、保存と共有の側にあります。Free Editionのデータは拡張機能の中にだけ保存され、アンインストールや端末の変更で復元できません。シナリオは同時に1本しか保持できず、チームとの共有とMaven pluginによるCI実行も対象外です。

判断はこう分かれます。手元での動作確認だけならFree Editionで足ります。テストをチームで共有したい、プルリクエストごとに自動で回したいとなった時点で、有償のTalend Cloud API Testerか、CLI実行が無償で使えるPostmanとNewmanの組み合わせへ移る時期です。

Talend API Tester無料版の保存先と有償Cloud版との機能差

使い始める前に、無料版がどこまでを担い、何を担わないのかを押さえておきます。ここを知らずに使い込むと、数か月分のリクエスト定義を失う事故が起きます。

Chromeウェブストア版25.17系の提供元とREST・SOAPの対応範囲

ChromeウェブストアのTalend API Tester – Free Editionのページでは、2026年9月時点でバージョン25.17系（2026年6月10日更新）、提供元はQlik、利用者数は60万人と表示されています。Talend製品群はQlik傘下に入っており、ドキュメントもQlikのヘルプサイトへ統合されました。

対応するのはREST、SOAP、HTTPのAPIです。レスポンスはJSON、XML、HTML、画像などの形式で表示でき、インポート元としてPostmanのコレクション、Swagger・OpenAPI定義、HAR形式が挙げられています。

名称が2つある点も混乱の元です。検索で出てくる「Talend Cloud API Tester」は有償のTalend Cloudに含まれる版で、Free Editionはその機能を絞った無料版にあたります。公式ドキュメントはCloud版を主語に書かれているため、読むときはFree Editionで使える機能かどうかを都度確かめる必要があります。

データがブラウザ内だけに残るFree Editionの仕様とエクスポート手順

公式のData storageには、Cloud版ではプライベート変数の値を除く全データがクラウドに保存される一方、Free Editionではデータが拡張機能の中に保存されると書かれています。拡張機能を削除したり別のPCへ移ったりすると、そのデータは戻りません。

守る手段はエクスポートだけです。Exporting your dataの手順では、左パネル下部のExportからJSONファイルとして書き出し、ドライブ全体、プロジェクト、サービス、シナリオ、リクエスト、環境の単位で対象を選べます。

プライベート環境変数の値は既定では書き出されず、「Export private variables values」を選んだときだけ含まれます。書き出したJSONはImport API Tester repositoryで読み戻せますが、同名のプロジェクトは上書きされます。書き出したファイルをGitリポジトリに入れておけば、履歴が残り端末故障にも耐える構成です。

シナリオ1本・共有不可・Maven不可というFree Editionの制限

公式のTalend API Tester – Free Edition limitationsが挙げる制限を、Cloud版と並べて整理します。

観点	Free Edition	Cloud版
シナリオ数	同時に1本まで	制限の記載なし
データ保存先	拡張機能内	クラウド
チーム共有	不可	可
Maven plugin	不可	可
Management API	不可	可
GitHubへのプッシュ	不可	可

実務で最初に効いてくるのはシナリオ1本の制約です。新しいシナリオを作るには既存のものを削除する必要があるため、「注文API」と「会員API」の一連の流れを別々に保存しておく使い方ができません。シナリオを複数持ちたくなった時点が、無料版の限界に達した合図になります。

拡張機能のインストールからGET・POSTリクエスト送信までの操作手順

ここからは手を動かす工程です。インストールから最初のレスポンスを画面に出すまでは5分もかかりません。

「すべてのサイト」権限を許可してから最初のGETを送る5ステップ

インストールとGET送信は次の順で進めます。4番目の権限設定を飛ばすと、送ったつもりのヘッダーがブラウザに書き換えられます。

ChromeウェブストアでTalend API Tester – Free Editionを開き「Chromeに追加」を押す
確認ダイアログで「拡張機能を追加」を選ぶ
アドレスバー右の拡張機能アイコンからTalend API Testerを起動する
拡張機能の詳細設定でサイトへのアクセスを「すべてのサイト」にする
METHODでGETを選び、URL欄にエンドポイントを入れてSendを押す

4番目の理由はRequired permissions for the extensionに書かれています。ブラウザはXHRで一部のヘッダーの設定を禁じており、全サイトへのアクセス権が無いと、それらのヘッダーはフォームで指定した値ではなくブラウザの値で上書きされます。検証対象がブラウザから呼ばれるAPIだけなら警告は無視できますが、スマホアプリやサーバー間連携のAPIを試すなら許可が必要です。

POSTでJSONボディを送るときのContent-Typeとボディ形式の指定

リクエストエディタのボディはテキスト、JSON、XML、HTMLの形式で書け、フォーム送信やマルチパートのファイルアップロードにも対応します。ヘッダーは表形式か生テキストで編集でき、Authorizationには基本認証の入力ヘルパーが付いています。TRACEメソッドは非対応です。

POSTでJSONを送るときに最も多い失敗は、ボディだけ書いてContent-Typeを付け忘れるケースです。サーバー側がapplication/json以外を受け付けない実装だと、415や400が返ります。ヘッダー欄の生テキスト表示に切り替えて、次の形で入れておくと確実です。

Content-Type: application/json
Accept: application/json

{
  "customerId": 1024,
  "items": [ { "sku": "A-001", "quantity": 2 } ]
}

1行目と2行目がヘッダー欄、空行の下がボディ欄に入る内容です。マルチパートでファイルを添付した場合、ファイルパスは保存されない仕様なので、再実行のたびに選び直すことになります。ファイルアップロードの検証を繰り返すなら、この点だけでも別のツールを検討する理由になります。

環境変数の${“host”}記法で接続先を切り替える設定と非公開変数

公式のUsing environmentsでは、式の中で変数を${"host"}の形で参照する例が示されています。開発用と検証用の環境それぞれにhostとtokenを定義しておけば、環境の切り替えだけで同じリクエストの向き先が変わります。

URL:
https://${"host"}/api/v1/orders

ヘッダー:
Authorization: Bearer ${"token"}

環境を共有するCloud版では、プライベートに設定した変数の値はクラウドに保存されず、変数名だけが他のメンバーに見えます。機能追加より前に作った環境の変数は既定で公開扱いなので、トークンやパスワードは個別にプライベートへ切り替えてください。Free Editionでも、エクスポートしたJSONを人に渡す場面では同じ注意が要ります。

アサーションとシナリオでレスポンスを自動検証する設定と実行の手順

Talend API Testerを入れる価値は、検証条件を保存して繰り返し判定できる点にあります。

ステータス・JSONパス・応答時間を検証するアサーションの組み立て

Validating HTTP responsesによると、アサーションの対象はステータスコード、ヘッダー、ボディ長、応答時間、ステータスメッセージ、JSONボディ（JSONパス）、XMLボディ（XPath）、ボディの内容です。条件はequals、less than、existsなどの演算子で組み、リクエストの実行時と更新時にリアルタイムで再評価されます。

注文取得APIなら、まずこの4条件を置けば回帰の大半を拾えます。

ステータスコードがequals 200
JSONパス$.orderIdがexists
JSONパス$.items[0].skuがexists
応答時間がless than 800ミリ秒

応答時間の条件を入れておくと、機能は壊れていないのに遅くなった変更を捕まえられます。しきい値は本番の目標値から逆算して決めてください。リクエストのAcceptとレスポンスのContent-Typeが一致するか、といった値同士の比較も動的アサーションで書けます。

前のレスポンス値を次のリクエストへ渡すシナリオの組み方と停止条件

公式のScenariosは、シナリオをAPIの実際の使われ方を再現する順序付きのリクエスト集合と定義しています。プロジェクトやサービスの中ではリクエストがアルファベット順に実行されるのに対し、シナリオでは順番を自由に並べ替えられます。

典型は「ログインしてトークンを得る」「そのトークンで注文を作る」「作った注文IDで取得する」の3本構成です。1本目のレスポンスに含まれる値を、2本目以降のリクエストが式で参照します。結果は成功が緑、警告が黄、失敗が赤で並びます。

シナリオは子リクエストが1本失敗した時点で止まります。ログインが落ちたのに後続が走って大量の401が並ぶ、という状況にならないので、原因の位置がすぐ分かります。ただし前述のとおりFree Editionで持てるシナリオは1本です。検証したい業務フローが2つ以上ある時点で、有償版か別ツールへの移行を考える段階に入ります。

ブラウザ拡張ゆえの落とし穴とcURLで再現して切り分ける手順

Talend API TesterのFree EditionはChromeの中で動くため、送信されるリクエストにブラウザ由来の要素が混ざります。GUI上で成功と失敗が説明できないときは、まずこの前提を疑います。

Chrome 80以降に自動付与されるSec-Fetch系ヘッダーで500になる事例

公式FAQのAutomatic Google Chrome 80 headersには、Chrome 80以降の拡張機能から送るリクエストにSec-Fetch-Dest、Sec-Fetch-Site、Sec-Fetch-Modeの3ヘッダーが自動で付くと書かれています。サーバーがこれらを適切に扱えない場合、空のボディで500が返る例が挙げられています。

公式が示す解決策は、サーバー側でこれらのヘッダーを正しく処理させることです。拡張機能側で消す手段は案内されていません。なおMaven pluginから実行したテストはこの問題の影響を受けないと明記されています。つまり「Talend API Testerでは500なのに、CIやアプリからは通る」という食い違いが起きたら、このヘッダーが第一候補です。

ブラウザ由来の制約としてはCORSも混同されやすい論点です。プリフライトやオリジン判定の仕組みはCORSとは？仕組み・プリフライト・サーバー設定例で整理しています。

拡張の外でcurlを叩きサーバー側の問題かを判定する切り分け

切り分けは、同じリクエストをブラウザの外から送って結果を比べるのが最短です。次の2本を順に実行します。

# 1本目: ブラウザ由来のヘッダーなしで送る
curl -i -X POST "https://api.example.com/api/v1/orders" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"customerId":1024,"items":[{"sku":"A-001","quantity":2}]}'

# 2本目: Sec-Fetch系ヘッダーを足して送る（値は拡張機能が実際に送った値に合わせる）
curl -i -X POST "https://api.example.com/api/v1/orders" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Sec-Fetch-Dest: empty" \
  -H "Sec-Fetch-Mode: cors" \
  -H "Sec-Fetch-Site: none" \
  -d '{"customerId":1024,"items":[{"sku":"A-001","quantity":2}]}'

1本目が201で2本目が500なら、原因はサーバー側のSec-Fetch系ヘッダーの扱いで確定です。両方とも500ならリクエスト内容かサーバーの不具合、両方とも成功するなら拡張機能の権限設定を見直してください。-iはレスポンスヘッダーも表示するオプションで、エラー時のContent-Typeや独自ヘッダーまで比較できます。Chromeで実際に送られたリクエストをそのままcURLに変換する手順はCopy as cURLの使い方にまとめています。

Maven pluginでCIに載せる構成とTalend Cloudライセンスの前提

GUIで組んだテストを自動で回す手段として、Talend API TesterにはMaven pluginが用意されています。ただし先に書いたとおり、Free Editionでは使えません。この章はTalend Cloudの契約がある前提の内容です。

Maven pluginのJARを登録しpom.xmlへテスト実行を定義する記述

Installing the Talend Cloud API Tester Maven pluginの手順では、Talend Cloud画面右上のユーザー名から開くDownloadsページで「API Tester Maven Plugin」のJARを入手し、ローカルリポジトリへ登録します。同ページが挙げる前提はJDK 8（Oracle JDKは8u162以上）、Maven、Talend Cloudアカウントです。

mvn install:install-file -Dfile=api-tester-maven-plugin-1.0.0.jar \
  -DgroupId=org.talend.ci -DartifactId=api-tester-maven-plugin \
  -Dversion=1.0.0 -Dpackaging=jar

バージョン番号はダウンロードしたJARのものに合わせます。次に、GUIからエクスポートしたJSONを実行対象としてpom.xmlに書きます。設定項目はCustomizing your testsの一覧に従いました。

<build>
  <plugins>
    <plugin>
      <groupId>org.talend.ci</groupId>
      <artifactId>api-tester-maven-plugin</artifactId>
      <version>1.0.0</version>
      <executions>
        <execution>
          <phase>test</phase>
          <goals><goal>test</goal></goals>
          <configuration>
            <file>orders_api.json</file>
            <selectedEnvironment>staging</selectedEnvironment>
            <accountId>${account_id}</accountId>
            <instance>us</instance>
            <stopOnFailure>true</stopOnFailure>
            <httpclientTimeoutInMs>30000</httpclientTimeoutInMs>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

必須はfileとaccountIdの2つです。stopOnFailureは既定がfalseで、失敗してもビルドが通ってしまうため、CIのゲートに使うならtrueにします。httpclientTimeoutInMsの既定は60000ミリ秒。外部API依存のテストでは短めに設定しておかないと、応答が無いときにジョブが1分ずつ待たされます。instanceは契約しているTalend Cloudのリージョンに合わせます。

GitHub Actionsからmvn clean testで実行するワークフロー例

公式のRunning your tests from your command lineが示す実行コマンドはmvn clean testだけです。これをプルリクエストごとに走らせる最小構成を示します。公式手順はJARをTalend Cloudから入手する前提のため、リポジトリのci/配下に置いて毎回登録する形にしています。

name: api-test
on:
  pull_request:
    branches: [ main ]

jobs:
  talend-api-tester:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '8'
      - name: Install API Tester Maven plugin
        run: |
          mvn -B install:install-file -Dfile=ci/api-tester-maven-plugin-1.0.0.jar \
            -DgroupId=org.talend.ci -DartifactId=api-tester-maven-plugin \
            -Dversion=1.0.0 -Dpackaging=jar
      - name: Run API tests
        run: mvn -B clean test -Daccount_id=${{ secrets.TALEND_ACCOUNT_ID }}

accountIdをpom.xmlに直書きせず、-Daccount_idでCIのシークレットから注入している点がこの構成の要です。エクスポートするJSONにはプライベート変数の値が既定で含まれないため、トークン類はpom.xmlのvariablesで実行時に上書きします。JARをリポジトリに置く運用がライセンス上問題ないかは、契約条件を確認してから決めてください。

Talend API Testerを採用する条件と見送ってPostmanへ移す判断基準

ここまでの仕様を踏まえると、Talend API Testerを使い続けるか別のツールへ移るかの線引きは、機能の多さよりも「誰と、何回、どこで回すか」で決まります。

個人の手動疎通確認に限れば登録不要のFree Editionで足りる場面

Free Editionで十分なのは、次のどちらかに当てはまる場合です。1つは、開発者が自分の実装したAPIをその場で叩いて確かめる用途。アカウント登録が要らず、Chromeさえあれば社用PCにインストーラーを入れる申請も不要です。もう1つは、受託開発で発注側の担当者に「この画面でこう送ると、こう返る」と見せる場面で、拡張機能を入れてもらうだけで同じ操作を再現できます。どちらもテストが1人の手元で完結し、消えても作り直せる規模です。

チーム共有とCIが要るならPostmanへ移すかCloud版にする判断

次のいずれかに当てはまったら、Free Editionは見送ります。シナリオを2本以上保持したい、2人以上で同じテストを編集したい、プルリクエストごとに自動で回したい。どれもFree Editionの制限に正面からぶつかります。

移行先は2択です。すでにTalend Cloudを契約しているならCloud版に切り替えれば、同じ画面のままMaven pluginまで使えます。契約が無いなら、コマンドライン実行のNewmanを無償で使えるPostmanへ移るほうが費用面で有利です。Postmanのコレクション運用とNewmanでのCI組み込みはPostmanとは？APIテスト自動化とNewmanでのCI組み込みで手順まで扱っています。

移行の向きには注意が要ります。Request collectionsが記載する取り込み形式はPostman Collection v2.0、HAR 1.2、Talend独自のリポジトリJSONで、Postman→Talendの向きは公式に案内されています。逆のTalend→Postmanは双方の公式ドキュメントに手順の記載が見当たりません。OpenAPI定義があるならそれをPostmanに読み込ませて作り直すのが確実です。API仕様の管理から接続方式の設計まで外部に任せたい場合は、API開発・システム連携で受託の範囲を確認できます。

よくある質問

Talend API Testerの導入と運用でよく出る質問を、2026年9月時点の公式情報に基づいて整理します。

Talend API Testerは無料でどこまで使えますか？

Free Editionは無料で、リクエスト送信、環境変数、アサーション、履歴、インポートとエクスポートまで使えます。制限は保存と共有と自動化の側にあります。データは拡張機能内にしか保存されず、シナリオは同時に1本まで。チームとの共有、Maven plugin、Management API、GitHubへのプッシュは使えません。これらが要る場合は有償のTalend Cloud API Testerが対象になります。

Talend API TesterはFirefoxやEdgeでも使えますか？

公式のインストール手順で案内されているのはGoogle Chromeのみで、配布元もChromeウェブストアです。Firefox向けの公式版は案内されていません。EdgeはChromium系のためChromeウェブストアの拡張機能を追加できる設定がありますが、Qlikの公式手順には含まれていないため、動作は自己責任での利用になります。チームで端末のブラウザが揃わない場合は、デスクトップアプリがあるPostmanなどを検討してください。

保存したリクエストが消えないようにするにはどうしますか？

Free Editionでは定期的なエクスポートが唯一の手段です。左パネル下部のExportからドライブ全体をJSONで書き出し、Gitリポジトリなど端末の外に置きます。プライベート環境変数の値は既定では書き出されないため、復元時には値を入れ直す必要があります。読み戻すときは同名プロジェクトが上書きされるので、別名で保存しておくと安全です。

Talend API Testerで送ると500が返るのにcurlでは成功するのはなぜですか？

最も疑わしいのは、Chrome 80以降の拡張機能が自動で付けるSec-Fetch-Dest、Sec-Fetch-Site、Sec-Fetch-Modeの3ヘッダーです。公式FAQに、サーバーがこれらを正しく扱えず空のボディで500を返す例が載っています。curlでこの3ヘッダーを足して再送し、同じ500になれば原因はサーバー側です。拡張機能の権限が「すべてのサイト」になっていない場合も、ヘッダーがブラウザに上書きされて結果が変わります。

Talend API TesterとPostmanはどちらを選べばよいですか？

1人の手動確認で、登録なしにすぐ使いたいならTalend API TesterのFree Editionで足ります。2人以上での共有、複数シナリオの保持、CIでの自動実行のどれかが必要ならPostmanが有利です。Postmanは無料プランでもコレクションを複数持て、Newmanで無償のCI実行ができます。Talend Cloudを契約済みの組織だけは、Cloud版に切り替えて同じ画面のまま自動化まで進める選択肢があります。