DifyのHTTPノードで403エラーが出た話｜設定ミスの原因と解決手順を実践ログで解説

HTTPノードの実行結果で status_code が 403 になっているのを確認しました。レスポンスBodyには以下が返ってきていました。

{"code": "rest_forbidden", "message": "Sorry, you are not allowed to create posts as this user."}

「このユーザーとして投稿する権限がない」というメッセージです。認証が通っていないことは明確でした。

ステップ2：BodyからHeaderへ認証情報を移動する

Bodyにあったusernameとpasswordを削除して、HeaderにAuthorization: Basic {Base64文字列}を追加しました。

ステップ3：WordPressのアプリパスワードを再発行する

通常のWordPressログインパスワードではなく、「アプリパスワード」を使う必要があります。

発行手順：

1. WordPress管理画面 → ユーザー → プロフィール
2. 「アプリケーションパスワード」のセクションへ
3. 名前を入力して「新しいアプリケーションパスワードを追加」
4. 表示された文字列（スペース含む）をそのままBase64エンコードに使う

ステップ4：再実行して200を確認する

修正後に再実行したところ、status_code: 201（作成成功）が返ってきました。WordPress管理画面に下書き記事が追加されているのを確認して、ホッとしました。

判断基準をまとめておきます。

• status_codeが403 → 認証設定を見直す（HeaderのAuthorizationを確認）
• status_codeが401 → APIキーが間違っている（再発行を検討）
• status_codeが200・201 → 成功。レスポンスBodyを次のノードに渡す

---

実際にWordPress連携で使った構成

私が本番で動かしているワークフローの構成を公開します。

GAS + Dify + WordPress構成

最終的に以下の構成に落ち着きました。

Dify（LLMノード）
  ↓ 記事本文・タイトルを生成
Dify（HTTPノード）
  ↓ GASエンドポイントへPOST
Google Apps Script（GAS）
  ↓ WordPress REST APIへ中継投稿
WordPress（下書き保存）

Difyから直接WordPress REST APIを叩くのではなく、GASを中継レイヤーとして挟んでいます。理由は2つあります。

1. CloudflareのWAFをGASのIPで回避できる
2. GAS側でデータ整形・エラーハンドリングができる

HTTPノードの役割位置

ワークフロー内でのHTTPノードの位置は、LLMノードの直後です。

• 前ノード：LLMノード（記事タイトル・本文を生成）
• HTTPノード：GASへPOSTリクエストを送信
• 後ノード：レスポンスを受け取り、投稿IDを変数に格納

リクエスト設計（具体例）

HTTPノードの設定は以下のとおりです。

Method: POST
URL:    https://script.google.com/macros/s/{デプロイID}/exec

Headers:
  Content-Type: application/json

Body:
  {
    "title": "{{LLMノード.title}}",
    "content": "{{LLMノード.content}}",
    "status": "draft",
    "secret": "{{ENV.GAS_SECRET}}"
  }

ENV.GAS_SECRETはDifyの環境変数に登録したシークレットキーです。GAS側で一致するか検証することで、不正なリクエストを弾いています。

レスポンスの扱い方

GASからは以下のJSONが返ってきます。

{
  "success": true,
  "post_id": 123,
  "url": "https://example.com/?p=123"
}

HTTPノードのレスポンスBodyを次のノードで参照して、投稿IDを記録したり、Slackに通知を送ったりしています。

---

非エンジニアが詰まるポイントまとめ

私が詰まった場所と、その理由を整理しておきます。

「なんとなく設定」が通用しない理由

HTTPノードは、設定に明確なルールがあります。Authorizationというキー名は決まっていて、スペルを1文字でも間違えると認証が通りません。「なんとなく書いたら動いた」が起きにくい場所です。

私は最初、Authorisation（イギリス英語スペル）と書いてしまって認証が通らず、30分近く悩みました。

JSON理解の壁

BodyにJSONを書くとき、フォーマットのルールを守る必要があります。

• 文字列は必ず "ダブルクォート" で囲む
• 最後の項目に ,（カンマ） をつけない
• 中括弧 {} と角括弧 [] の対応を揃える

JSONの書き方が間違っていると、status_code: 400（Bad Request）が返ってきます。JSONを書いたら、jsonlint.com 等のバリデーターで事前確認するのがおすすめです。

APIドキュメントの読み方

APIドキュメントは英語のことが多く、非エンジニアには難しく感じると思います。最低限、以下の3か所だけ確認すれば動かせます。

1. Authentication（認証）：どの形式でAPIキーを渡すか
2. Endpoint（エンドポイント）：URLは何か
3. Request Body（リクエストボディ）：どんなデータを送るか（必須項目はどれか）

他の説明は後回しにして、まずこの3点だけ読んでください。

デバッグの考え方

エラーが出たときの確認順序を決めておくと、余計に悩まなくて済みます。

• status_codeを最初に確認する（400番台はクライアント側の設定ミス）
• レスポンスBodyのエラーメッセージを翻訳して読む
• ヘッダーの設定を確認する（認証情報が正しく渡っているか）
• URLのスペルを確認する（末尾スラッシュの有無も影響することがある）

---

HTTPノードを使えるようになる判断基準

「動いた」だけで満足していると、次に別のAPIを叩くときにまた詰まります。使えるようになったかどうかの判断基準を整理しておきます。

動いたかどうかの判断では不十分

「200が返ってきた」は最低条件です。それだけでは「たまたま動いた」かもしれません。

確認すべきこと：

• なぜそのHeaderの設定で認証が通るのか説明できるか → NOなら認証の仕組みを調べる
• エラーが出たとき、自分でステータスコードを見て原因を絞り込めるか → NOならデバッグフローを作っておく

再現性があるか

一度動いたワークフローを、翌日もう一度最初から設定できますか？

設定値をメモしておく、スクリーンショットを残す、という習慣がないと再現できません。私はNotion上にAPIの設定値とBase64エンコード文字列をセットで記録しています。

他APIに応用できるか

WordPress REST APIで動いたなら、NotionのAPIやSlackのAPIも同じ考え方で設定できるはずです。

• メソッド（GET/POST）の使い分けがわかるか
• Headerに何を書くかがAPIドキュメントから読み取れるか

これができれば、HTTPノードを「汎用のAPI接続ツール」として使えています。

自動化に組み込めるか

最終的なゴールは「HTTPノードを使って何かを自動化すること」だと思います。単発でAPIが叩けても、ワークフローの中でどこに置くか・前後のノードとどう繋げるかが設計できないと自動化にはなりません。

---

まとめ：次にやるべきこと

DifyのHTTPノードで詰まる場所は、ほぼ「認証ヘッダーの設定ミス」か「APIキーの渡し方の違い」です。まずstatus_codeを確認して、403なら認証を、400ならリクエストBodyのJSON形式を見直してみてください。

今日から試せる一歩は、WordPressのアプリパスワードを発行して、HTTPノードにBase64エンコードした認証情報をHeaderに設定してみることです。それだけで、DifyからWordPressへのAPI連携が動き始めます。

HTTPノード単体で動かせるようになっても、収益に繋げる設計は別の話です。自動化→記事投稿→収益化まで組んだ全体構造は、bizinets.bizで実践ベースで公開しています。