はじめに:n8nとWordPress連携で誰もが一度は通る「カテゴリ指定」の壁
n8nを使ってWordPressへのブログ記事投稿を自動化しようとした際、「よし、カテゴリも自動で設定しよう」と考えて、WordPressノードのCategoriesフィールドに技術・AI学習のようなカテゴリ名を直接入力した経験はありませんか?そして、The value "未分類" is not supportedといったエラーメッセージに頭を抱えたことはないでしょうか。これは、n8nとWordPressを連携させる上で非常に多くの人が直面する典型的な問題です。この記事の目的は、この問題の根本原因を解明し、単なる対症療法ではなく、恒久的に使える堅牢な解決策、つまり「カテゴリ名を動的にIDへ変換して自動設定するn8nワークフロー」の構築方法を、調査で得られた全情報を元に、ステップバイステップで徹底的に解説することです。調査過程で発生したAIとのやり取り、コードのエラー、そしてその修正プロセスもすべて公開しますので、あなたが同じ轍を踏むことなく、スムーズに問題を解決できるようガイドします。
【結論】なぜカテゴリ名での指定はエラーになるのか?
結論から言うと、この問題はn8nのバグや制約ではなく、連携先であるWordPressのREST APIの仕様に起因します。WordPress REST APIは、投稿にカテゴリを割り当てる際、categoriesパラメータとしてカテゴリ名(name)やスラッグ(slug)を受け付けず、整数型のカテゴリID(ID番号)の配列のみを受け入れるように設計されています。これはAPIの仕様書にも明記されており、n8nのWordPressノードはこの仕様に忠実に従っているため、名前で指定すると「サポートされていない値です」というエラーが発生するのです。
- 問題の発生源: n8nではなく、WordPress REST APIの仕様。
- APIの要求:
categoriesパラメータには、[3, 5, 8]のようなカテゴリIDの配列が必須。 - 許容されない値:
['技術ブログ', 'エッセイ']のようなカテゴリ名の文字列配列は受け付けられない。
この根本原因を理解することが、正しい解決策へ至るための第一歩となります。
解決策の選択肢:静的指定 vs 動的取得
原因がわかったところで、解決策は大きく分けて2つ存在します。それぞれのメリット・デメリットを理解し、あなたのユースケースに最適な方法を選びましょう。
| 比較項目 | 解決策1:静的ID指定 | 解決策2:動的ID取得ワークフロー |
|---|---|---|
| 概要 | WordPress管理画面でカテゴリIDを調べ、n8nのノードに直接ハードコードする。 | ワークフロー内でHTTP Requestノードを使い、カテゴリ名からIDを都度取得する。 |
| メリット | 実装が非常に簡単で、すぐに試せる。ノード数が少なく済む。 | カテゴリの増減や変更に強い。メンテナンス性が高く、スケールしやすい。 |
| デメリット | カテゴリを追加・削除するたびにIDを調べ直し、ワークフローを修正する必要がある。 | ワークフローが少し複雑になる。HTTP RequestやCodeノードの知識が必要。 |
| 推奨ユースケース | カテゴリが固定されており、今後変更の予定がほとんどない小規模な個人ブログ。 | 複数のサイトを運営している、カテゴリが頻繁に変わる、チームで運用しているブログ。 |
| 実装コスト | 低い。WordPressの管理画面を開いてIDをコピー&ペーストするだけ。 | 中程度。APIエンドポイントの理解と、簡単なJavaScriptコードが必要。 |
| 堅牢性 | 低い。WordPress側の変更で簡単に壊れる可能性がある。 | 高い。APIから最新の情報を取得するため、常に正しいIDを使用できる。 |
この記事では、長期的かつ安定的な運用を見据え、より実用的な「解決策2:動的ID取得ワークフロー」の構築方法を詳細に解説していきます。
ステップバイステップ:カテゴリID動的取得ワークフローの構築
ここからは、実際にn8nでワークフローを構築していきます。全体の流れは以下の通りです。
- トリガー
ワークフローを開始する(例:手動実行、Webhook) - HTTP Requestノード
WordPress REST APIにリクエストを送り、サイトに存在する全カテゴリのリスト(ID, name, slugを含む)を取得する。 - Codeノード
取得したカテゴリリストと、指定したいカテゴリ名(例:『技術・AI学習』)を照合し、対応するカテゴリIDを抽出する。 - WordPressノード
Codeノードで抽出したカテゴリIDを使って、記事を投稿または更新する。
ステップ1:HTTP Requestノードで全カテゴリ情報を取得する
まず、WordPressサイトから現在登録されているすべてのカテゴリ情報を取得します。これにはHTTP Requestノードを使用します。
- Authentication: あなたのWordPressサイトの認証情報を設定します。(例:Header Authでアプリケーションパスワードを使用)
- Method:
GET - URL:
https://あなたのドメイン/wp-json/wp/v2/categories - Options > Split Into Items: このオプションを有効にすると、取得したカテゴリが個別のアイテムとして後続のノードに渡され、処理しやすくなります。
このノードを実行すると、以下のような構造のデータがカテゴリの数だけ取得できます。
{
"id": 5,
"name": "技術・AI学習",
"slug": "ai-tech",
"count": 10,
"description": "",
"link": "https://example.com/category/ai-tech/",
"parent": 0
}
ステップ2:Codeノードでカテゴリ名からIDを抽出する(エラーと修正の全記録)
ここがこのワークフローの心臓部です。そして、私が調査過程で実際にエラーに直面し、解決した部分でもあります。この試行錯誤のプロセスを共有することが、読者の皆さんにとって最も価値のある情報だと考えています。
【失敗談】最初のコードと発生したエラー
当初、私はAIに以下のような入力データを渡し、categoryNameに一致するIDを返すコードを依頼しました。
[
{
"categoryName": "技術・AI学習",
"availableCategories": [
{
"id": 5,
"name": "技術・AI学習",
"slug": "ai-tech"
},
{
"id": 1,
"name": "未分類",
"slug": "uncategorized"
}
]
}
]
AIは次のようなシンプルなコードを提案しました。
// 最初の誤ったコード
const item = $input.all()[0];
const categoryName = item.categoryName;
const availableCategories = item.availableCategories;
const matchedCategory = availableCategories.find(cat => cat.name === categoryName);
return { id: matchedCategory?.id };
しかし、このコードをn8nのCodeノードで実行すると、以下のエラーが発生しました。
errorMessage: "Cannot read properties of undefined (reading 'find') [line 9]"
errorDescription: "TypeError"
【原因分析】なぜエラーは起きたのか?n8nのデータ構造の罠
エラーメッセージ Cannot read properties of undefined (reading 'find') は、availableCategoriesという変数がundefined(未定義)であることを示しています。つまり、findメソッドを実行しようとした対象が存在しなかったのです。これは、n8nのCodeノードにおけるデータアクセスの方法を誤解していたことが原因でした。n8nでは、前のノードから渡されたデータは、itemオブジェクト直下ではなく、item.jsonプロパティの中に格納されます。これが非常に重要なポイントです。
- 誤ったアクセス:
item.categoryName - 正しいアクセス:
item.json.categoryName
【解決策】修正された最終的なCodeノードスクリプト
この知見に基づき、AIとの対話を経て完成した、堅牢で実用的なスクリプトがこちらです。このコードは、前のノード(HTTP Request)から渡された全カテゴリリストと、別のノード(例:Setノード)で定義した「投稿したいカテゴリ名」を照合して、IDを返します。
前提: このCodeノードは2つの入力を受け取ります。入力0にはHTTP Requestノードからの全カテゴリリスト、入力1にはSetノードなどで定義した投稿したいカテゴリ名(例:{ "categoryName": "技術・AI学習" })が接続されていると仮定します。
// 最終版:エラーハンドリング付きの堅牢なスクリプト
try {
// 入力0: HTTP Requestノードからの全カテゴリリストを取得
const allCategories = $input.all('0');
// 入力1: Setノードなどから指定したいカテゴリ名を取得
const targetItem = $input.item.pairedItem;
const targetCategoryName = targetItem.json.categoryName;
if (!targetCategoryName) {
return { error: "対象のカテゴリ名(categoryName)が入力に見つかりません。" };
}
// カテゴリ名に一致するカテゴリ情報を検索
const matchedCategory = allCategories.find(item => item.json.name === targetCategoryName);
if (matchedCategory) {
// 見つかった場合、IDやその他の情報を返す
return {
categoryName: targetCategoryName,
id: matchedCategory.json.id,
slug: matchedCategory.json.slug,
found: true
};
} else {
// 見つからなかった場合
return {
categoryName: targetCategoryName,
id: null,
found: false,
error: `カテゴリ「${targetCategoryName}」は見つかりませんでした。`
};
}
} catch (error) {
// 予期せぬエラーをキャッチ
return { error: error.message, stack: error.stack };
}
ポイント: 実際のワークフローでは、$input.all()や$input.itemのデータ構造が複雑になることがあります。もしこのコードでうまくいかない場合は、まずデバッグ用のコードを実行して、入力データの構造を正確に把握することが重要です。
// デバッグ用コード:入力データの構造を確認する
const items = $input.all();
return items.map(item => item.json);
ステップ3:WordPressノードで動的に取得したIDを使用する
最後に、Codeノードが出力したIDをWordPressノードのCategoriesフィールドに設定します。ここでも重要なのは、APIがIDの配列を要求する点です。
- WordPressノードを開き、「Add Field」から「Categories」を選択します。
- 入力欄の横にある歯車アイコンをクリックし、「Add Expression」を選択します。
- 以下の式を入力します。
Codeの部分は、あなたのCodeノードの名前に置き換えてください。
{{ [$('Code').item.json.id] }}
この[ ](角括弧)でIDを囲むことで、[5]のような配列形式でデータを渡すことができます。これを忘れると再びエラーになるため、注意してください。複数のカテゴリを指定したい場合は、Codeノードを複数カテゴリ名に対応できるように改修し、{{ $('Code').item.json.ids }}のようにIDの配列を直接渡します。
多角的な分析と評価
この動的ID取得ワークフローは、単なる技術的な解決策以上の価値を持ちます。様々な側面からその有効性を評価してみましょう。
- 技術的側面: WordPress REST APIの仕様を正しく理解し、HTTPリクエストとデータ変換(JavaScript)を組み合わせることで、APIの制約を乗り越える良い実践例です。n8nのデータフローとデータ構造の理解が深まります。
- 実用的側面: 手作業によるIDの確認とコピー&ペースト作業を完全に排除できます。これにより、ヒューマンエラーが減り、特に複数のカテゴリやサイトを管理する場合の作業効率が劇的に向上します。
- コスト・効率面: n8nのセルフホスト版を利用していれば、この自動化に追加の金銭的コストはかかりません。むしろ、カテゴリ管理にかかっていた時間という見えないコストを大幅に削減し、コンテンツ制作など、より価値の高い作業に集中できるようになります。
- 学習曲線: 初心者にとっては、APIやCodeノードの概念が少し難しく感じるかもしれません。しかし、本記事で紹介したエラーと修正のプロセスを追体験することで、実践的なデバッグスキルとn8nの深い知識を効率的に習得できます。
- 市場・動向側面: ノーコード/ローコードツールが普及する中で、API連携は自動化の要です。このようなAPIの仕様に合わせたデータ整形・変換スキルは、n8nに限らず、他の自動化ツールを使いこなす上でも必須のスキルセットとなりつつあります。
著者の気づきと考察:AIとの協業における学び
今回の調査と実装を通じて、私が最も強く感じたのは「AIは万能の魔法の杖ではなく、優秀なペアプログラマーである」ということです。AIは迅速にコードの雛形を生成してくれますが、そのコードが特定の実行環境(今回はn8nのCodeノード)で正しく動作するかどうかは、最終的に人間が検証し、デバッグする必要があります。エラーメッセージを正確に読み解き、データ構造を地道に確認し、AIに的確なフィードバックを与えることで、初めて正解にたどり着くことができました。この「AIへの質問→試行→エラー分析→再質問」というサイクルこそが、現代における問題解決の重要なプロセスなのだと再認識しました。また、n8nのitem.jsonというデータ構造は、多くの初心者がつまずくポイントであり、この「お約束」を一度理解してしまえば、応用範囲が格段に広がることも大きな収穫でした。
まとめと次のステップ
本記事では、n8nのWordPressノードでカテゴリを名前指定した際に発生するエラーの原因と、その根本的な解決策である動的ID取得ワークフローの構築方法を、実際の失敗談を含めて詳細に解説しました。このワークフローを導入することで、あなたのWordPress運用はより効率的で、エラーの少ないものになるはずです。
- 原因の再確認: エラーはWordPress REST APIがカテゴリIDのみを受け付ける仕様のため。
- 解決策の構築: HTTP Requestノードで全カテゴリを取得し、Codeノードで名前からIDを検索する。
- 実装の鍵: Codeノードでは
item.json経由でデータにアクセスすること。WordPressノードではIDを[ ]で囲み配列にすること。
次のステップとして、このワークフローを応用し、タグの動的設定や、複数のカテゴリ名をカンマ区切りで受け取って一度にID配列に変換するような、より高度な自動化に挑戦してみてはいかがでしょうか。この記事が、あなたのn8nライフの一助となれば幸いです。
出典・参考情報
- [1] WordPress REST API Handbook (公式ドキュメント)
- [2] n8n Documentation – Code Node
- [3] Perplexity.aiによる調査結果 (本記事の元情報)