Claude Codeのクラウドセッションから、WordPressのREST APIで記事を読んだり更新したりできます。
このとき、WordPressのパスワードをClaudeに見せずに渡せるのが、クラウド環境の「Network secrets」(旧画面のAPI credentials)です。
WordPress側の準備から、クラウド環境への登録、動作の確認までを、両方の公式ドキュメントで整理しました。
- WordPress側で、アプリケーションパスワードを発行する
- クラウド環境の編集画面で、認証情報タイプ「Basic」として登録する
- パスワードはAnthropicの中継サーバーが付けるので、Claudeにもコマンドにも見えない
- Pro・Max・Team・Enterpriseが対象。登録できる環境と組織ロールには条件がある
2026年10月23日に公式資料を再照合しました。既存画像は10月4日の旧画面例です。新しい画面と、この中継方式によるWordPress接続・更新の実機再現は確認していません。
参照:Claude CodeのNetwork secrets、WordPress REST API認証、WordPressの権限。認証情報の新規登録や変更は、この資料照合では行っていません。
仕組み|パスワードはClaudeに渡らない
クラウドセッションは、Anthropicのクラウドにある仮想マシンで動きます。
API認証情報を登録すると、仮想マシンから出たリクエストに、中継サーバー(agent proxy)が認証情報を付け足します。
公式の説明では、キーはClaude、Claudeが実行するコマンド、セッションの環境変数のどれにも届きません。
| 渡し方 | Claudeから見えるか | 向いているもの |
|---|---|---|
| 環境変数 | 見える。環境を使う人は誰でも値を読める | 秘密ではない設定値 |
| API認証情報 | 見えない。値は保存後に表示されない | パスワードやAPIキー |
WordPressのパスワードを環境変数に書くのは避けて、API認証情報で渡します。
使える条件
- Pro・Max・Team・Enterprise。Enterpriseの登録操作や共有環境の編集にはOwner等の組織管理ロールが必要。Teamの個人環境は管理ロールなしでも登録可能
- Anthropicが用意するクラウド環境で、すでに作ってある環境
- WordPressのサイトが、インターネットから接続を受け付けている
- WordPress 5.6以降(アプリケーションパスワードが標準で入っている)
Network secretsは作成済みのAnthropicホスト環境へ登録します。セルフホスト環境は対象外で、顧客管理の暗号鍵を使う組織では保存できません。Enterpriseの一般メンバーはOwnerに共有環境への登録を依頼します。
リクエストはAnthropicのネットワークから出るので、社内からしか入れないサイトには届きません。
サーバーやセキュリティ系のプラグインで、海外からのアクセスやREST APIを制限していると、つながらないことがあります。
手順1|WordPressでアプリケーションパスワードを作る
WordPressには、5.6からアプリケーションパスワードが標準で入っています。
ログイン用のパスワードとは別に、APIのためだけのパスワードを発行する仕組みです。
- 管理画面の「ユーザー」から、APIで使うユーザーの編集画面を開く
- 「アプリケーションパスワード」の欄で、名前(例:Claude Code)を入れる
- 「新しいアプリケーションパスワードを追加」を押す
- 表示されたパスワードを控える(あとから見ることはできない)
アプリケーションパスワードはHTTPSのREST APIへBasic認証で渡せます。この記事の中継方式では、秘密をコマンドへ書かず、後でNetwork secretsへ登録します。登録後の読取り確認例は次のとおりです。
curl --fail-with-body --silent --show-error "https://example.com/wp-json/wp/v2/users/me?context=edit&_fields=id,name"APIで使うユーザーは、必要な権限だけを持つものにします。
標準の投稿なら、自分の記事だけを扱う投稿者、他の人の記事も扱う編集者など、対象に合う権限を選びます。カスタム投稿やプラグイン固有の操作では別の権限が要る場合があります。認証の成功と投稿更新の許可は別です。
手順2|クラウド環境の編集画面を開く
- claude.ai/codeの新規セッション画面で入力欄下の環境セレクターを開く。実行中の自分のクラウドセッションでは、タイトル横のメニューからEdit cloud environmentを選べる
- Cloud の一覧で、使う環境にカーソルを合わせ、右に出る設定のアイコンを押す
- Edit cloud environmentのNetwork secretsを探す
個人環境は環境セレクターから編集します。組織共有環境はOwnerが管理設定のCloud environmentsページから編集します。共有環境を通常のセレクターから開くと読取り専用です。
手順3|認証情報を「Basic」で登録する
Network secretsでAdd secretを選びます。次の画像は旧画面のため、現在のラベルと異なります。

標準フォームではSecret typeのBearerをBasicへ変えます。Teamの管理ロールなしのフォームではUsername and passwordを選びます。WordPressのログイン用パスワードではなく、発行したアプリケーションパスワードを使ってください。
| 項目 | 入力内容 |
|---|---|
| 名前 | 見分けるための名前(例:WordPressAPI) |
| 認証情報タイプ | Basic |
| 許可ウェブサイト | WordPressのドメイン(例:example.com) |
| パスプレフィックス(任意) | WordPressのREST APIのパス(例:/wp-json/) |
| ユーザー名 | WordPressのユーザー名 |
| パスワード | 手順1で発行したアプリケーションパスワード |
標準フォームのAllowed websitesでは先頭の*.がサブドメイン指定になります。Teamの簡易フォームは1ホストのみで、ワイルドカードに対応しません。WordPressの実際のHTTPSホストを指定してください。
旧画面にはパスプレフィックスがありましたが、今回の公式資料はホスト照合を説明しており、現行のパス制限の提供範囲は確認できませんでした。パスだけで権限を限定できると仮定しないでください。
WordPressのAPI URLが/blog/wp-json/のようなサブディレクトリを含む場合、接続テストもその正しいURLで行います。画面にパス指定欄があれば、その仕様を確認してから使ってください。
画面の説明では、値は「Authorization: Basic」ヘッダーとして送られ、書き込み専用で、保存後は表示されません。
現行の標準フォームではAdd、Teamの簡易フォームではAdd secretで保存します。環境全体のSave changesを待たずに保存されます。
登録した認証情報はあとから編集できず、変えるときは削除して登録し直します。
手順4|つながったか確かめる
その環境で新しいセッションを始めて、Claudeに認証が要るAPIを呼んでもらいます。
curl --fail-with-body --silent --show-error "https://example.com/wp-json/wp/v2/users/me?context=edit&_fields=id,name"コマンドにはユーザー名もパスワードも書きません。
HTTP 200で想定したユーザーのIDと名前が返れば、認証は成功です。公開記事が読めるだけでは認証確認になりません。投稿更新は、検証用下書きで対象権限と保存結果を別に確かめます。
認証が付いていないと、users/me は401のエラーになります。
一覧で認証情報に「Not sent」と出たときは、その下の説明に理由と対処が書かれます。
つまずきやすいところ
| 症状 | 見るところ |
|---|---|
| 401で認証されない | 認証情報タイプがBasicか。ユーザー名が合っているか。アプリケーションパスワードを取り消していないか |
| つながらない・403になる | サーバー側制限、WordPressの操作権限、認証ヘッダー転送、REST API制限 |
| 一部のURLだけ認証されない | 実際のHTTPSホストとAPIパス、転送先、旧パス設定の適用範囲を確認 |
| 2つの認証情報が同じホストにある | ホストが重なると、どちらか一方しか送られない |
同じドメインに、別のユーザーのWordPressがいくつもある場合、パスプレフィックスで分けて送り分けられるかは、公式ドキュメントでは確認できていません。
また、認証情報は、その環境の全セッションから対象ホストへの該当リクエストに付きます。環境をアーカイブしても動作中のセッションには残るため、利用を止めるときはNetwork secretsの削除とWordPress側のパスワード失効を確認します。
ほかの人も使う環境に登録すると、その人のセッションからもWordPressを更新できてしまう点に気をつけます。
認証情報が付かないリクエスト
次のリクエストには、登録した認証情報は付きません。
- GitHub(別の仕組みで認証される)
- AnthropicのAPIと、npmやPyPIなどの公開パッケージの置き場
- セットアップスクリプトの中のリクエスト
- Claude Codeの利用状況の送信
セットアップスクリプトでWordPressからデータを取ろうとしても、認証は付かないので、セッションの中で取ります。
ネットワークの設定との関係
クラウド環境のネットワーク設定が「Trusted」のままでも、API認証情報に登録したホストには届きます。
公式の説明では、認証情報のホストは、ネットワークの許可リストを通らない経路で扱われます。
そのため、WordPressのドメインを、ネットワークの Allowed domains に足す必要はありません。
関連記事:Claude Codeのプロジェクトとは
よくある質問:Claude CodeのクラウドセッションからWordPressを更新するとき
WordPressのパスワードを、Claudeに見せずに渡せますか?
渡せます。
クラウド環境の「Network secrets」(旧画面のAPI credentials)に登録すると、パスワードはAnthropicの中継サーバーが付けるので、Claudeにもコマンドにも見えません。
公式の説明では、キーはClaude、Claudeが実行するコマンド、セッションの環境変数のどれにも届きません。
環境変数に入れるのと、何が違いますか?
環境変数は、Claudeから見え、環境を使う人は誰でも値を読めるため、秘密ではない設定値向けです。
API認証情報は、Claudeから見えず、値は保存後に表示されないため、パスワードやAPIキー向けです。
どのプランで使えますか?
Pro・Max・Team・Enterpriseが対象。登録できる環境と組織ロールには条件があります。
公式資料は2026年10月23日に再照合しています。既存画像は10月4日の旧表示で、新しい画面と接続実機は未確認です。
WordPress側では、何を準備しますか?
WordPressには、5.6からアプリケーションパスワードが標準で入っています。
管理画面の「ユーザー」から、APIで使うユーザーの編集画面を開き、「アプリケーションパスワード」の欄で名前(例:Claude Code)を入れて「新しいアプリケーションパスワードを追加」を押し、表示されたパスワードを控えます(あとから見ることはできません)。
APIで使うユーザーは必要な権限だけを持つものにし、標準の投稿なら、自分の記事だけを扱う投稿者、他の人の記事も扱う編集者など、対象に合う権限を選びます。カスタム投稿やプラグイン固有の操作では別の権限が要る場合があります。認証の成功と投稿更新の許可は別です。
クラウド環境には、どう登録しますか?
新規セッションの環境セレクターで対象環境を編集し、Network secretsを開きます。共有環境はOwnerが管理設定のCloud environmentsから編集します。
Add secretを選び、Basic(Teamの簡易フォームではUsername and password)と対象ホスト、WordPressユーザー名、アプリケーションパスワードを設定して保存します。旧画面のパスプレフィックスが現行環境でも使えるかは別途確認してください。
登録した認証情報は、あとから編集できますか?
できません。
値は書き込み専用で、保存後は表示されません。
変えるときは、削除して登録し直します。
つながったか、確かめるには?
その環境で新しいセッションを始めて、Claudeに認証が要るAPIを呼んでもらいます。
コマンドにはユーザー名もパスワードも書きません。
HTTP 200で想定したユーザーのIDと名前が返れば、認証は成功です。公開記事が読めるだけでは認証確認になりません。投稿更新は、検証用下書きで対象権限と保存結果を別に確かめます。
認証が付いていないと、users/me は401のエラーになります。
401や403になるときや、気をつける点は?
401は、認証情報タイプがBasicか、ユーザー名が合っているか、アプリケーションパスワードを取り消していないかを確認します。
つながらない・403になるときは、サーバーやセキュリティ系プラグインの海外アクセス制限、REST APIの制限を確認します(リクエストはAnthropicのネットワークから出るため、社内からしか入れないサイトには届きません)。
一部のURLだけ認証されないときは、ホストや転送先、APIパス、旧パス設定を確認します。現在のパス制限仕様は未確認です。
なお、認証情報は、その環境で動くすべてのセッションに付くため、ほかの人も使う環境に登録すると、その人のセッションからもWordPressを更新できてしまう点に気をつけてください。
