ClaudeとTravis CIを連携する — 非公式MCPサーバーmcp-travisの使い方

Travis CIには、AnthropicやTravis CI GmbHが提供する公式のMCPサーバーが存在しません。ここで扱うmcp-travisは個人開発者が公開している非公式プロジェクトで、Travis CI API v3をMCPのツールとして包み、Claude Codeから自然文でビルドを操作できるようにします。トリガー・再実行・ログ取得といった基本操作に加えて、2つのビルドを突き合わせて差分を出す機能や、ログを解析してキャッシュ設定を提案する機能まで実装されている点が、単純なAPIラッパーとは違います。

mcp-travisが包むのはTravis CI API v3

Travis CIのAPIにはv2とv3があり、公式ドキュメントはv3への一本化を明言しています。v2は2018年に廃止予定と告知されたまま長く残っていましたが、新規に組むならv3一択です。mcp-travisもv3のエンドポイント(api.travis-ci.com)を叩く前提で作られています。

古い情報を検索するとapi.travis-ci.orgというホスト名が出てくることがありますが、travis-ci.orgは2021年6月に廃止されました。オープンソースリポジトリも含めてtravis-ci.comへの移行が完了しており、.org宛のリクエストはもう機能しません。mcp-travisの環境変数が既定で.comを指しているのはこのためです。

サーバーが公開しているツールは10個あります。

このほかにtravis:build-log?jobId=...のようなリソースURIも公開されており、特定ジョブのログだけをピンポイントで読みたいときに使えます。

Claude Codeに接続する

動かすにはNode.js 18以上が必要です。設定する環境変数は3つあります。

まずリポジトリを取得してビルドします。

git clone https://github.com/Montana/mcp-travis.git
cd mcp-travis
npm install
npm run build

次にTravis CIのAPIトークンを発行します。travis-ci.comにログインし、プロフィールアイコン→「Settings」→「API authentication」の順に進むとトークンが表示されます。このトークンはビルドのトリガーや停止まで操作できる強い権限を持つため、他のシークレットと同じ扱いで保管してください。

トークンを取得したら、Claude CodeにMCPサーバーとして登録します。標準入出力(stdio)で動くローカルサーバーなので、ビルド済みのdist/index.jsを直接起動する形になります。

claude mcp add --transport stdio travis \
  --env TRAVIS_API_URL=https://api.travis-ci.com \
  --env TRAVIS_API_TOKEN=your_travis_token_here \
  --env TRAVIS_USER_AGENT=mcp-travis/0.1 \
  -- node /path/to/mcp-travis/dist/index.js

/path/to/mcp-travisはビルドしたリポジトリの絶対パスに置き換えます。リポジトリ付属のsetup.shはNode.jsのバージョン確認から依存関係のインストール、対話形式でのトークン入力までを自動化してくれる便利なスクリプトですが、書き込み先はClaude Desktop向けのclaude_desktop_config.jsonに固定されており、Claude Code CLIの設定は書き換えてくれません。CLIで使うときは上のコマンドで直接登録します。登録後は/mcpでサーバーがConnectedになっているか確認します。

ビルドの状態を自然文で追う

接続できれば、リポジトリ名とブランチを伝えるだけでビルドを操作できます。

travis-ci/travis-webのdeploy_2026.09.10ブランチでビルドをトリガーして

ビルド276783990のログを全部見せて

ログ取得には2通りの経路があります。travis_getBuildLogsにビルドIDだけ渡すと、そのビルドに含まれる全ジョブのログを一括で結合して返す最短ルートです。一方、失敗したジョブだけを狙い撃ちしたい場合は、先にtravis_getBuildJobsで各ジョブのIDと状態(passed / failed)を取得し、失敗しているジョブIDだけを指定してログリソースを読む2段構成が使えます。マトリクスビルドで一部の言語バージョンだけ落ちているようなケースでは、後者のほうが読むログの量を絞れます。

ビルドを比較して原因を絞り込む

単なるログ取得より価値が出るのはtravis_compareBuildsです。2つのビルドIDを渡すと、状態・所要時間・コミット差分・ジョブ単位の合否をまとめて返してくれます。

ビルド276783990と276783991を比較して、何が変わって落ちたのか教えて

「昨日まで通っていたのに今日から落ちる」というよくある相談に対して、コミットの差分とジョブ単位の合否を並べて見せてくれるため、原因の当たりを付ける時間が短縮されます。travis_getBuildInsightsはさらに広い範囲を見る機能で、直近50件(既定値、最大100件)のビルドを集計し、合格率の推移やブランチ別の安定度を出します。「最近このリポジトリのビルドが不安定な気がする」という感覚を、実際のトレンドとして裏付けたいときに向いています。

travis_getOptimizationRecommendationsはビルドログを解析し、パッケージインストールやテスト実行のパターンを検出してキャッシュ化・並列化の提案を返します。提案には.travis.ymlに足す具体的な設定例も含まれます。

cache:
  directories:
    - node_modules
    - ~/.npm

提案はログのパターンマッチングによるヒューリスティックで、Travis CI側が公式に保証する最適化ではありません。実際に効果があるかは自分の.travis.ymlに当てはめて確認する前提で使います。

組織の状況とTravis CI自体の稼働を確認する

ビルド個別の話とは別に、travis_getOwnerStatsを使うとユーザーや組織単位の状況を俯瞰できます。

railsオーガニゼーションのTravis CI統計を見せて

これを呼ぶと、対象がユーザーか組織か、GitHub上のID、リポジトリの総数と稼働中の数、直近アクティブなリポジトリごとの最終ビルド状況(合格・失敗・ビルド未実行の3値)がまとまって返ってきます。複数リポジトリを横断で見たいとき、1つずつrecent-buildsリソースを叩くより早く全体像がつかめます。

「ビルドが落ちているのは自分のコードの問題か、Travis CI側の障害か」を切り分けたいときはtravis_getServiceStatusを使います。

Travis CIは今落ちている?

APIやビルド処理、通知など各コンポーネントの稼働状況、進行中のインシデント、予定されているメンテナンスの有無がステータスページの情報として返ります。原因調査を始める前にこれを一度確認しておくと、自分のコードを疑って無駄な時間を使う事態を避けられます。

導入前に確認しておきたいこと

mcp-travisはTravis CI GmbHが提供するものではなく、個人開発者が公開しているオープンソースプロジェクトです。GitHub上の情報では、リポジトリの作成は2025年10月末、直近の更新も同年11月中旬と比較的新しく、star数もまだ少数です。リポジトリにライセンスファイルが設定されていない点も見ておくべきポイントで、明示的なOSSライセンスが無い状態は「著作権者に無断で再配布・改変してよいとは限らない」ことを意味します。社内で複製して使う、フォークして手を加えるといった運用を考えている場合は、この点を先に確認しておきます。ビルドのトリガーや停止まで操作できるAPIトークンをこのサーバーに渡すことになるため、実行前にソースコードを一読しておくと安心です。継続的なメンテナンス体制を前提にした公式サーバーとは性質が違う、という点は認識しておく価値があります。

Travis CIそのものの利用状況も踏まえておくと良いでしょう。公式のBilling FAQによれば、オープンソースリポジトリ向けのビルド枠は現在無条件の無料枠ではなく、サポートチームに申請して特別クレジットを受け取る形に変わっています。この特別クレジットは公開リポジトリのビルド専用に割り当てられるもので、自動付与ではなくTravis CIのサポートチームへ直接問い合わせて申請する運用です。新規プロジェクトでCIを組むなら選択肢に挙がりにくい状況なので、このMCPサーバーが刺さるのはすでにTravis CIで運用しているチームに限られます。逆に言えば、長年蓄積されたビルド履歴を持つ既存プロジェクトほど、travis_getBuildInsightsのような傾向分析ツールの恩恵は大きくなります。

よくあるつまずき

• .org宛のURLを設定してしまう: 古いブログ記事や社内Wikiにはapi.travis-ci.orgが残っていることがありますが、廃止済みで応答しません。TRAVIS_API_URLは必ずhttps://api.travis-ci.comにします
• トークンが通らない: 認証エラーになる場合は、travis-ci.comに改めてログインし「Settings → API authentication」で.com側のトークンを発行し直します
• setup.shを実行したのにClaude Codeで使えない: このスクリプトが書き換えるのはClaude Desktopの設定ファイルです。Claude Code CLIには前述のclaude mcp addコマンドを別途実行する必要があります
• npm run buildを忘れてdist/index.jsが無いエラーになる: claude mcp addのコマンド行はビルド済みファイルを直接起動する構成なので、登録前に必ずビルドを済ませておきます
• ビルドIDとジョブIDを取り違える: travis_getBuildLogsが受け取るのはビルドID、個別ログのリソースURIが受け取るのはジョブIDです。両者は別の採番体系なので、travis_getBuildJobsの出力で対応関係を確認してから使います

まとめ

mcp-travisを使えば、ビルドのトリガー・比較・ログ解析までをClaude Codeのセッション内で完結できます。特にtravis_compareBuildsとtravis_getOptimizationRecommendationsは、単純なAPIラッパーでは得られない分析まで踏み込んでいる点が実用的です。ただし個人メンテナンスの非公式プロジェクトである以上、トークンの扱いとメンテナンス状況は自分の目で確認してから導入します。すでにTravis CIの有償プランで運用しているチームには効果がありますが、新規にCIを組むならGitHub Actions前提のMCPサーバーを検討する方が現実的です。導入するかどうかを判断する際は、まずtravis_getServiceStatusのような読み取り専用のツールだけを試し、トリガーや停止といった書き込み系の操作は挙動に慣れてから任せる、という段階を踏むのが安全です。

MCPサーバーの追加構文やスコープの使い分けはClaude Code MCP設定ガイドにまとめています。Jenkinsを使っている場合はJenkinsのMCP連携、他のCIサービスとの機能差はCircleCI/Buildkite/Jenkins MCP比較で確認できます。