N&S Logo

Claude Code × MCPで外部ツールを何でも自動化する7ステップ

更新: 7/20
読了: 約31
字数: 12,303文字
Claude Code × MCPで外部ツールを何でも自動化する7ステップ

チャットが答えるだけで、仕事は動かない。
チャットや生成AIが回答するだけで、実際の業務ツールを動かせず自動化が進まない──そんなもどかしさを解消します。この記事では、Claude CodeとMCPを組み合わせて「回答するAI」から「実際に操作する自動化」へとつなげるための、実践的な7ステップを示します。接続と認証の落とし穴、フロー設計、エラー処理、運用に耐えるガードレール、そして現場ですぐ使えるテンプレと最小限のコード例まで、非エンジニアにも試せる形で具体的に解説します。これを読めば、あなたのAIがただ答えるだけの存在から、実働するオートメーションの中核へと変わります。

そもそもどう動くのか

外部ツール連携が壊れていて「その場にいないと動かない」作業を続けていませんか?

Claude Codeのアーティファクトは、MCPコネクタを呼び出して外部APIやデータベースを「ビューア単位」で読み書きする仕組みだ。仕組みが分かれば、あとはリクエストの成形→認証→レスポンス整形の繰り返しで応用できる。なお、Claude Code 2.1.215以降は /verify や /code-review を自動で実行しないため、必要なときに明示的に呼び出す必要があります。

  1. ビューアと操作を定義する

    • 何を誰のコンテキストで動かすかを決める。例: viewer_id="user:alice"、操作="fetch_orders"。
    • 仕様例:
    { "viewer_id": "user:alice", "action": "fetch_orders", "params": {"limit": 10} }
  2. MCPコネクタのエンドポイントと認証を設定する

    • 環境変数でトークンを管理し、MCPへはHTTPSで叩く。例:
    curl -sS -X POST "https://mcp.example.com/invoke" \
      -H "Authorization: Bearer $MCP_TOKEN" \
      -H "Content-Type: application/json" \
      -d '{"viewer_id":"user:alice","action":"fetch_orders","params":{"limit":10}}'
  3. アーティファクト内でリクエストを組み立てる

    • 必ず viewer_id を含める。テンプレート例(疑似コード):
    const payload = { viewer_id, action: "update_profile", params: { name: "Bob" } };
    callMCP(payload);
  4. レスポンスを実用フォーマットに変換する

    • 受け取ったJSONを必要なフィールドだけに変換。CLI例:
    curl ... | jq '.data.items[] | {id:.id, total:.total}'
  5. ローカルで順次テストする

    • ライブ環境を叩く前に curl で期待するHTTPステータスとJSONスキーマを確認する:
    curl -w "%{http_code}" -o resp.json -sS ... && jq empty resp.json
  6. 検証・コードレビューは明示的に呼ぶ

    • 自動実行されないため、必要時にアーティファクトの実行入力として "/verify" または "/code-review" を送る。例(実行ペイロード):
    { "artifact": "my-artifact", "input": "/verify", "viewer_id": "user:alice" }
  7. デプロイ後の監視とロールバックルートを用意する

    • 失敗時は詳細ログを残し、MCP呼び出しのタイムアウト/再試行を設定する。簡易ヘルスチェック例:
    curl -fsS https://mcp.example.com/health || echo "MCP down"

まとめ:Claude Codeは「viewer単位のMCP呼び出し」を軸に設計すると扱いやすい。まずはローカルで curl を使って viewer_id を含むリクエストを投げ、/verify を手動で呼ぶところまで試してみてください。

① まずは権限と環境を確認する(前提チェック)

家のデスクから離れているときに外部ツールが止まっていると、全部手動でやり直しになる――そんな無駄、減らしたくないですよね。

そもそもどう動くのか:Claude Code側で「アーティファクト」を作れる権限と、MCP(外部コネクタ)連携が有効かどうかをまず確かめる。仕組みは単純で、アーティファクトが「どのコネクタにどう接続するか」を持ち、MCPがその接続情報を仲介する。Claude Codeの一部スキルは自動で走らない仕様もあるので(例:Claude Code 2.1.215では /verify と /code-review は自動実行されない。必要なら /verify や /code-review を明示的に呼ぶ)、確認は手動で確実にやるのが安全。

7ステップ(前提チェック)

  1. 管理者コンソールにログインする

    • 管理者権限のアカウントでログイン。まず「Artifacts」メニューが見えるか確認する。
  2. UIでCreate artifact画面を開く

    • 管理コンソール → Artifacts → Create artifact を開く。フォーム内に「connectors」欄(接続先を指定する入力)が表示されていることを確認する。
  3. connectors欄にサンプルを入れてみる

    • connectors欄に既知のコネクタ名を一つ入力して保存まで進められるか試す(保存は破壊的でなければテスト用名前で)。失敗したら権限かMCP設定を疑う。例:connectors: ["slack"]。
  4. IAM/ロールを確認する

    • 該当ユーザーに artifact:create / artifact:write 相当の権限があるか確認。管理コンソールのユーザー権限画面で該当ロールをチェックする。
  5. MCP側のコネクタ有効化を確認する

    • MCP管理画面で目的のコネクタ(Slack, S3 等)が「enabled」になっているか確認。認証情報(APIトークン、OAuthクレデンシャル)が正しくセットされているかを開いて確認する。
  6. 実際に最小限のアーティファクト作成リクエストを投げる(例)

    • コンソールのJSONエディタかAPI経由で、最小構成の作成ボディを送ってみる。例(UIのJSON入力やAPIに貼るサンプル):
    {
      "name": "mcp-test-artifact",
      "description": "MCP接続テスト用",
      "connectors": ["slack"]
    }
    
    • 成功すればIDが返るはず。エラーならレスポンスの権限/connectorエラーコードをメモする。
  7. スキル検証を手動で走らせる

    • 自動実行されないスキルがあるため、必要に応じて /verify や /code-review を手で呼び出す。失敗メッセージが出る場合はログを確認して認証や権限問題を潰す。

まとめ:まずは「Create artifact」画面でconnectors欄が見えるか、実際に最小の作成を試せるかを確かめること。UIでの表示確認→権限の照合→MCPコネクタの有効化→最小作成テスト、の順に潰せば基本的な前提は整う。次は、実際に1つのコネクタをフルで接続して動作確認する(次のセクションへ進んでください)。

② MCP側でコネクタを作る(認証情報の準備)

家のPCの前にいないと外部サービスへの連携が止まってしまう——そんな手元依存をなくすには、MCP側で「使える」認証情報を用意しておくことが最短ルートだ。

そもそもどう動くのか MCPのコネクタは外部サービスへアクセスするための「橋渡し」。橋を架けるには相手側(APIプロバイダ)から発行されるOAuthクライアントID/シークレットやAPIキーが必要で、それをMCPに登録しておくと、MCP経由で自動的にトークンを取得・更新できる。ローカル環境では開発用に同じ認証情報を環境変数へ置いておくと、デバッグやスクリプト実行がスムーズだ。

7ステップ(手を動かせる手順)

  1. MCPダッシュボードにログインしてコネクタ管理画面を開く

    • ブラウザでMCPのダッシュボードへアクセスし、対象サービス用の新規コネクタ作成画面を表示する。
  2. 認証方式を選ぶ(OAuth2かAPIキー)

    • OAuthが必要な場合は「OAuth2」を選択、単一キーで良い場合は「API Key」を選択する。どちらかを間違えると動かないのでサービス仕様を確認する。
  3. OAuthアプリをプロバイダ側で登録する(OAuthの場合)

    • プロバイダ(例: GitHub, Google 等)の開発者コンソールで新しいOAuthアプリを作成する。
    • リダイレクト/コールバックURLには、MCPのコネクタ作成画面で表示されるコールバックURL(例: <MCP_CALLBACK_URL>)を正確に貼る。
  4. クライアントID/シークレットまたはAPIキーを取得する

    • プロバイダの画面で発行された client_id と client_secret、またはAPIキーを取得する。
    • 取得した値は即コピーしてMCPのコネクタ設定に貼り付ける。
  5. MCPに値を登録して保存する

    • MCPのコネクタ設定欄に client_id / client_secret / api_key を入力して保存する。
    • 保存後に「接続テスト」や「認可を実行」ボタンがあれば必ず実行して成功を確認する。
  6. ローカルで開発用に環境変数を設定する(最低限の例)

    • 開発マシンでスクリプトやローカルCLIが参照できるように、環境変数をセットする。
    • 例:
      export MCP_CLIENT_ID="your_client_id"
      export MCP_CLIENT_SECRET="your_secret"
      export MCP_API_KEY="your_api_key"   # APIキー方式ならこちら
      
    • .envファイルを使う場合は .gitignore に追加し、ファイル権限を制限する(例: chmod 600 .env)。
  7. 動作確認と運用上の注意

    • 簡単な確認スクリプトで環境変数が読み取れるかチェックする:
      # check_creds.sh
      #!/bin/sh
      : "${MCP_CLIENT_ID:?MCP_CLIENT_ID not set}"
      : "${MCP_CLIENT_SECRET:?MCP_CLIENT_SECRET not set}"
      echo "MCP credentials present"
      
      chmod +x check_creds.sh && ./check_creds.sh
    • 本番ではOSのシークレットマネージャやクラウドのSecret Storeを使い、平文ファイルやリポジトリへの保存を避ける。認証情報は最小権限で発行する。

まとめ MCPにコネクタを作って認証情報を安全に保管する作業は、ダッシュボードで登録→プロバイダで発行→ローカルに環境変数という流れで済む。まずは上の手順でテスト登録して、次はClaude Code側からそのコネクタを呼び出す設定に進んでください。

③ アーティファクトにコネクタを宣言する(マニフェスト編集)

家の外でダッシュボードが止まると、手元でしか作業できない自分が本当に嫌になる。

そもそもどう動くのか:アーティファクトのマニフェストに「どのコネクタを使うか」を宣言しておくと、ランタイム側がその名前を見て必要なドライバ/資格情報を紐づけに行く。マニフェストはコネクタ名+(コネクタごとの)シークレット参照を持つのが基本設計。仕組みが分かれば、名前を追加→シークレットを登録→デプロイ、の3つを繰り返すだけで拡張できる。

7ステップ(手を動かせる粒度で)

  1. マニフェストを開く
  • artifact定義ファイル(例: artifact.json / artifact.yaml)をエディタで開く。
  1. connectors配列を追加する
  • 既存の定義にconnectorsフィールドを追記する。例:
{
  "name": "sales-dashboard",
  "connectors": ["salesforce","vectordb"]
}
  1. シークレット参照を明示する
  • コネクタごとにプラットフォーム上のシークレット名を紐づける。例(簡易JSON拡張):
{
  "name": "sales-dashboard",
  "connectors": ["salesforce","vectordb"],
  "secrets": {
    "salesforce": "secret_sales_sf",
    "vectordb": "secret_vectordb"
  }
}
  1. シークレットを登録する(プラットフォーム側)
  • MCPのシークレットストアに、上で指定した名前で値(APIキー、接続文字列)を登録する。UIでもCLIでも可。名前はマニフェストの値と厳密に一致させる。
  1. マニフェストの構文チェック
  • JSONなら jq で簡易検証: jq . artifact.json
  • YAMLなら yaml-lint 等でチェック。構文不備でランタイムが無視することがあるので必ず通す。
  1. デプロイ/再適用
  • 普段のワークフローでartifactを再デプロイ(CI経由、あるいは手動で適用)。マニフェストを反映させることでランタイムは指定コネクタの初期化を行う。
  1. 動作確認とログ確認
  • コネクタ起動時に認証エラーが出やすいので、起動ログを確認して「シークレット読み取り成功」「コネクタ接続成功」を見る。エラーが出たらシークレット名と値、権限を再確認。

まとめ:マニフェストにコネクタ名+シークレット参照を追加して、MCP側で該当シークレットを登録すればOK。まずはartifactファイルに上のJSONを追記して、jqで構文チェックしてみてください。次は「実際にシークレットをMCPに登録する手順」を一緒に見ますか?

④ ビューアごとの認可フローを実装する(ユーザー単位で安全に操作)

家の前で作業を止めてしまう一番の原因は、「誰のトークンで何を実行しているか」が追えないことだ。

そもそもどう動くのか 各ビューア(ユーザー)ごとにOAuthで認可を行い、取得したアクセストークン/リフレッシュトークンをサーバ側で安全に保管する。ビューアからの操作要求が来たら、そのユーザー用トークンを引き出してMCPへAPIコールする、という流れである。仕組みが分かれば各ビューアを自由にオンボードできる。

7ステップ

  1. アプリ登録とリダイレクトURI設定
  • MCPにアプリを登録し、リダイレクトURIをhttps://your.domain/callbackにする(管理画面で設定)。
  • 取得する情報: client_id, client_secret を控える。
  1. 認可開始エンドポイントを用意
  • ビューアがクリックするURLを生成: https://{MCP_AUTH_ENDPOINT}/authorize?response_type=code&client_id={CLIENT_ID}&redirect_uri={REDIRECT_URI}&scope=actions&state={STATE}
  • stateはUUIDで生成してRedis/DBに保存(CSRF対策)。 例: redis-cli: SET oauth:state:{STATE} {VIEWER_ID} EX 300
  1. /callback を実装して code→token を交換
  • コールバック例(curl): curl -X POST https://{MCP_TOKEN_ENDPOINT}/token
    -d grant_type=authorization_code
    -d code=${CODE}
    -d redirect_uri=${REDIRECT_URI}
    -u "${CLIENT_ID}:${CLIENT_SECRET}"
  • 返却JSONを受け取り access_token, refresh_token, expires_in を抽出。
  1. state検証とトークンの永続化
  • 受け取った state で Redis/DB を引き、対応する VIEWER_ID を検証。
  • PostgreSQL 例: INSERT INTO viewer_tokens(viewer_id, access_token, refresh_token, expires_at) VALUES ('{VIEWER_ID}', '{ACCESS}', '{REFRESH}', now() + interval '{EXPIRES}s');
  1. 実行時に保存トークンを使う(環境変数例)
  • 実行前に環境変数で一時的に読み込む例(サーバ管理用スクリプト): export MCP_TOKEN="ey...ユーザトークン..."
  • API 呼び出し例: curl -H "Authorization: Bearer $MCP_TOKEN" https://{MCP_API}/action -d '{"task":"deploy"}'
  1. リフレッシュ処理を自動化
  • expires_at が近づいたら refresh_token で更新: curl -X POST https://{MCP_TOKEN_ENDPOINT}/token
    -d grant_type=refresh_token
    -d refresh_token=${REFRESH}
    -u "${CLIENT_ID}:${CLIENT_SECRET}"
  • 新トークンをDBへ上書き。
  1. セキュリティ運用と削除フロー
  • DB暗号化(列レベルまたはKMS)、外部からの直接アクセス禁止、最小権限のサービスアカウントを使う。
  • ユーザーが解除したら revoke API 呼び出しと DB 削除を行う。
  • ローカルでの一時確認用にトークンを環境変数に入れるなら、必ず export 直後に権限を絞ったシェルで作業し、作業終了後は unset する: unset MCP_TOKEN

まとめ ユーザー毎にOAuthを回してトークンをDB/鍵管理に置き、呼び出し時だけ取り出してAPIを叩く。まずは1ユーザーで /auth/start → /callback を実装して、curlでtoken交換が成功することを確認するのが次の一歩だ。

家のPCの前でしか検索が回せず、必要なドキュメントがチームに届かない――そんな煩わしさを一行で潰す。

そもそもどう動くのか:MCPは「コネクタの仲介役」で、各種ベクトルDBへの認証・API変換を担う。あなたはMCPにベクトルDBコネクタを登録し、アーティファクト(検索クエリやメタ情報)を投げるだけ。MCPが該当コネクタに問い合わせて結果を返すので、クライアント側は単一のAPIだけ覚えればよい。

  1. コネクタを登録する(MCP側) curlで登録例:
curl -X POST http://mcp.example/api/connectors \
  -H "Authorization: Bearer $MCP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name":"vectordb",
    "type":"vector",
    "config":{"endpoint":"https://vdb.example","api_key":"REDACTED"}
  }'

レスポンスでconnector_idを控える。

  1. 登録状態を確認する
curl http://mcp.example/api/connectors/vectordb -H "Authorization: Bearer $MCP_TOKEN"

status=active を確認する(エラーならconfigを修正して再登録)。

  1. アーティファクト(検索クエリ)を作る クエリをMCPのアーティファクトストアに保存:
curl -X POST http://mcp.example/api/artifacts \
  -H "Authorization: Bearer $MCP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"query","text":"顧客Aに関連するドキュメント","metadata":{"priority":"high"}}'

返ってきたartifact_idをメモ。

  1. 検索実行(MCP経由でベクトルDBに問い合わせる) 提供の擬似コマンド例に沿って呼ぶ:
curl -X POST http://mcp.example/mcp/execute \
  -H "Authorization: Bearer $MCP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "connector":"vectordb",
    "action":"search",
    "query":"顧客Aに関連するドキュメント",
    "artifact_id":"<artifact_id>"
  }'

またはartifact_idだけ渡す運用も可能(上のbodyでartifact_id指定)。

  1. 結果の扱い方(JSONパース) 返却例(概念)から上位結果を抽出:
curl ... | jq '.results[0]'

scoreやsnippet、source_urlが返る想定なので、必要ならsnippet→全文取得APIに続ける。

  1. エラーハンドリングと再試行 HTTPステータスで判定し、500系は指数バックオフで再試行:
for i in 1 2 3; do
  STATUS=$(curl -s -o resp.json -w "%{http_code}" ...)
  if [ "$STATUS" = "200" ]; then cat resp.json; break; fi
  sleep $((i*2))
done

認証失敗はconfigのapi_keyを再発行して差し替える。

  1. 検証をClaudeに頼む(手動で) 実装チェックをClaudeにやらせたい場合、注意:Claude Code 2.1.215は /verify や /code-review を自動実行しません。必要ならClaudeセッションで手動実行してください。例:Claude にメッセージとして "/verify mcp-connector-config" を送って検証を走らせる。

まとめ:まずは自分のベクトルDB接続情報を用意して、ステップ1のPOSTでコネクタを登録し、ステップ4の /mcp/execute を叩いてみてください。結果が取れればあとはパイプライン化するだけです。

⑥ アクション実行とコードチェック:/verify と /code-review を使い分ける

家のPCの前にいないと外部操作が止まる——自動化の最後の壁は「実行していいか」を人が確認する工程だ。

そもそもどう動くのか:Claude Code 2.1.215では、/verify と /code-review は自動で走らない。必要なときに対話内で明示的に呼び出して、アーティファクト(ビルド出力、マニフェスト、差分など)をチェックしてから外部アクションを発火するワークフローが推奨される。仕組みが分かれば、あとは手順化してCIやバッチの前段に差し込める。

7ステップ

  1. アーティファクトを確定する

    • 生成物を1箇所にまとめ、ハッシュとメタを作る。例:
      sha256sum build/app.tar.gz > build/sha256.txt
  2. 対話にアーティファクト情報を投げる(/verify)

    • Claudeに対して以下を送る。
      /verify
      artifacts: build/app.tar.gz, build/sha256.txt, manifest.json
    • チェック結果をテキストで返してもらう。ログを必ず保存する。
  3. 失敗内容を深掘りする

    • /verify の出力に「どのファイル」「どのチェックが失敗したか」がなければ、追加入力で指定して再確認させる。例:
      「manifest.json の依存バージョン整合と署名検証をもう少し詳しく」
  4. コード品質とセキュリティ観点のレビュー(/code-review)

    • ソースやパッチを貼って実行。例:
      /code-review
      focus: security, input validation, error handling
      files: src/, tests/
    • レビューコメントを必ずタスクに紐付ける(Jira/Phabricator/issue)。
  5. 修正・テストを回して再実行

    • 修正後、ローカルでテストを通す(例: npm test / pytest)し、通ったら再度 /code-review を走らせる。
    • 自動化前の手順は「/verify → /code-review → 実行許可レスポンス」の順に固定する。
  6. 実行ゲートの設置(明示的承認)

    • 自動バッチは「Claudeからの承認レスポンス」をトリガーとする。たとえば対話で「OK_TO_RUN」と返すまで次を実行しない運用にする。
  7. レポート保存と差し戻しルール化

    • /verify と /code-review の出力をファイル化してアーティファクトとして保存。例:
      (対話ログを保存するイメージ)
      claude_verify_output.txt
      claude_code_review_output.txt
      
    • 失敗時の差し戻し手順(担当者、期限)も明文化する。

まとめ:/verify と /code-review を手動で明示的に呼ぶだけで、実行ミスやセキュリティ事故のリスクを大幅に下げられる。まずは1回、手動で /verify → /code-review を行い、出力をファイルに残すところから始めてください。

⑦ 運用と安全対策:ログ・レート制限・段階的ロールアウト

家やオフィスの外で自動化が止まる──原因は運用と安全対策の抜け穴だ。

そもそもどう動くのか:Claude Codeは外部ツール呼び出しを行い、MCP(Middleware/Connector Platform)はそれら呼び出しを仲介して実行・監査する。監査ログ・呼び出し上限・エラー復帰の仕組みを堅牢にしておけば、不意の障害や無限ループを現場で止められる。

  1. 監査ログを必須化する
  • すべての外部実行に対し「イベント」「caller」「payload」「status」「duration」を記録。まずはWebhookで受け取る。例:
curl -X POST https://your-log-endpoint -H "Content-Type: application/json" \
 -d '{"event":"mcp-exec","caller":"claude-code","status":"ok","id":"abc123"}'
  1. ログの署名と保管先を決める
  • Authorizationヘッダで署名付き送信。S3やログ集約サービスへ転送するなら転送ルールを明記。例:
-H "Authorization: Bearer <LOG_INGEST_TOKEN>"
  1. レート制限をMCPかプロキシで実装する
  • 直接MCPの管理画面で設定できない場合はNginx等で保護。最低限「/invoke」に1秒間隔・バースト上限を設定する。Nginxの例(要環境調整):
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/m;
  1. エラーハンドリングとリトライ戦略を明示する
  • 一時エラーは指数バックオフでリトライ、恒久エラーは停止して人間へ通知。bashでの簡易リトライ例:
for i in 1 2 4 8; do
  curl ... && break || sleep $i
done
  1. スモークテスト用コネクタを本番前に必ず通す
  • 本番コネクタに切り替える前に、テスト用エンドポイントで同じフローを1回以上通す。成功ログをWebhookで受け取り、ステータス確認。
  1. 段階的ロールアウト(カナリア)を運用に組み込む
  • 最初はトラフィックの5〜10%だけ新コネクタへ流す。失敗率が閾値を超えたら自動でロールバックするルールをMCPかデプロイツールで設定。
  1. 人間のチェックポイントを残す/自動検証の呼び出し制御
  • 自動コードレビューや検証は開発ポリシーで決める。補足:Claude Codeは自身で/verifyや/code-reviewを自動実行しない(必要なら手動で/verify等を呼び出すこと)(検証済み事実)。

まとめ:ログを確実に取り、レート制限とリトライをプロキシかMCPで担保し、まずはテストコネクタでスモークテスト→カナリア展開へ進める。まずはWebhook受信用のエンドポイントを1つ立てて、上のcurl例でログを受け取ることから始めましょう。

まとめ

Claude CodeとMCPを組み合わせれば、外部ツールの操作を安全かつ再現性のあるワークフローに落とし込めます。本稿では、要件整理、コネクタ設計、アーティファクト生成、手動検証(/verify)、自動化、監視までの7ステップを解説しました。まずは小さなコネクタでPoCを作り、アーティファクトに追加して手動で /verify を実行して動作を確かめることを次の一歩にしてください。その後、段階的に拡張していきましょう。

📱 関連ショート動画

この記事の内容をショート動画で解説

横にスクロールできます

著者について

原田賢治

原田賢治

代表取締役・AI技術責任者

Mike King理論に基づくレリバンスエンジニアリング専門家。生成AI検索最適化、ChatGPT・Perplexity対応のGEO実装、企業向けAI研修を手がける。 15年以上のAI・システム開発経験を持ち、全国で企業のDX・AI活用、退職代行サービスを支援。