n8n の公式テンプレートライブラリには 10,000 以上の公開ワークフローがあり、数年がかりで多くの人が落とし穴を踏み、積み上げてきた自動化ロジックの塊です。しかし n8n は挫折のハードルが昔から高いものです。ノードの設定、クレデンシャルの認可、上流と下流でパラメータが噛み合わなければフローは途切れ、デバッグはコードを書くより骨が折れます。

本チュートリアルでは、n8n-to-codex-skill という meta-skill（メタスキル）を使って、任意の n8n ワークフローを Codex ネイティブの Skill に変換する方法を解説します。ハードルは「n8n を使いこなす」から「Codex の変換が正しいか判断する」へと下がります。SEO 監査 skill と GEO コンテンツ生成 skill の 2 つの実例と、Codex が n8n に対してどこで強く、どこで弱いのかも併せて紹介します。

Codex の使用経験があり、蓄積した自動化資産を Agent 時代へ移行したい開発者や越境 EC 運営者に向いた内容です。

始める前の準備

• Codex App：問題なく使える Codex アカウント
• n8n テンプレートのリンク：n8n.io/workflows から公開テンプレートを任意に 1 つ選びます
• API クレデンシャル：元ワークフローが GSC、DataForSEO、Exa.ai などの有料データサービスに依存している場合は、各 Key が必要です
• 想定時間：1 ワークフローあたり約 30〜60 分（検収込み）

基本概念：Skill と Meta-Skill

手を動かす前に、2 つの概念を整理しておきます。

• Skill（スキル）：パッケージ化されたひとつの能力で、Codex は対応するリクエストに当たるとそれを呼び出します。サイト監査もひとつの Skill、Listing 文の作成もひとつの Skill で、それぞれ自分の担当分しか引き受けません。
• Meta-Skill（メタスキル）：具体的な仕事をしません。その仕事は「スキルを作ること」そのものです。n8n ワークフローのリンクを渡すと、そのワークフローを 1 回実行するのではなく、分解・判断・変換して新しい独立した Skill を生み出します。

n8n-to-codex-skill は後者です。

5 ステップのパイプライン

n8n のリンクを Codex に渡すと、meta-skill は次のフローを強制的にたどります。

1. 解析（Parse）：ワークフローを読み、どんなノードがあるか、各ノードが何をしているか、どの外部サービスに依存しているかを把握する
2. 分類（Classify）：各ノードを固定のカテゴリに分類し、カテゴリごとにデフォルトの処理ルールを適用する
3. 逆質問（Counter-question）：自分で決め打ちせず、重要な判断を推奨案つきでユーザーに見せる
4. プラン提示（Plan）：計画、ディレクトリ構成、ノード対応表を作る。ユーザーが了承するまでコードは書かない
5. 検収（Verify）：実データで 1 回走らせる。捏造した結果でのごまかしは許されない

11 クラスのノード処理ルール

分類こそがこのパイプラインの核です。次の表は meta-skill に組み込まれているノード対応ルールで、これを理解すれば Codex が自分のワークフローをどう処理するかを予測できます。

事例 1：SEO 監査 Skill

ソーステンプレート：n8n.io/workflows/4151

元ワークフローは 6 ノードで、やっていることは次のとおりです。URL を渡す → クローラーで HTML を取得 → 可視テキスト/見出し階層/meta を抽出 → AI がスコアリング（0-10）→ 修正提案を出力。

操作手順

1. テンプレートのリンクを Codex に渡し、meta-skill を呼び出して再現させます
2. Codex が Web からワークフローを取得すると評価を始め、いくつか逆質問をしてきます。
   • トリガー方式はどれにするか？
   • AI ノードは残すか、Codex に肩代わりさせるか？
   • 出力レポートはどこに置くか？
   • robots.txt チェックを強化するか？
3. 回答が終わると、Codex が詳細なプランを提示して確認を求めます
4. 確認後に skill ファイルの生成を開始します
5. 実在するサイトで検収します

検収結果

子供向けおもちゃの DTC ブランド 2 社をテストしました。

• Lovevery：7.7 点
• Yoto：8.6 点
• robots.txt：6 つの AI クローラーが両サイトとも全通過
• llms.txt：両サイトとも 404 を返す

💡 落とし穴回避：Shopify は 5 月からデフォルトで llms.txt を生成するはずですが、Lovevery と Yoto はともに 404 を返しました。Codex に再確認させても 404 で確定です。この 2 サイトは Shopify の標準テンプレートではなく自社実装のフロントエンドでした。こういう「直感に反する」結果こそ、実データ検収の価値です。

事例 2：GEO コンテンツ生成 Skill

ソーステンプレート：n8n.io/workflows/8768

元ワークフローは、フォームで要件を収集 → AI がコンテンツ生成 → Gmail で人間が承認 → Google Sheets にステータスを記録、という流れです。

主な改造ポイント

• フォーム項目（元は技術ブログ向けテンプレート）を、ページタイプ、セールスポイント、ターゲット層などに分解
• Gmail 承認をローカルでの人間確認に置き換え、メールアカウント接続は不要に

Codex が見つけたバグ

⚠️ 重要な発見：Codex は解析の過程で、このテンプレート自体、完全に通しで動いたことがない可能性があることを見抜きました。複数の箇所で、そもそも存在しないノードを参照していたのです。n8n のテンプレートは 10,000 以上ありますが、そのすべてが動く完成品である保証は誰もしていません。

2 つの Skill の連結

逆質問の段階で、前の SEO 監査 skill のレポートをコンテンツ生成 skill に接続します。

• コンテンツ生成時に、監査レポートの具体的なギャップを読み込む
• H3 が欠けていれば階層化された見出しを生成
• JSON-LD が欠けていれば schema の提案を生成
• 生成結果には "How This Responds to the Audit Report" のセクションを含め、監査レポートの 4 つの問題に 1 対 1 で対応させる

既知の限界

連結の仕組み自体は動きますが、証明はできません。この新コンテンツが本当に ChatGPT に 1 回でも多く引用されるのかを。AI 生成コンテンツには客観的な基準がなく、人間の審査も主観基準での評価にすぎません。

Codex vs n8n：結局どこが強いのか

Codex が本当に強い 3 つの点

1. 元システムのバグを見抜ける：8768 ワークフローのノード参照断裂を、Codex は解析段階で捉えました。実行して落ちるのを待って知るのではありません。n8n は断点まで走って初めてエラーを出します。
2. 決定論的なことと非決定的なことを同時にこなせる：監査 skill のスコアリングでは、文字数やタグといった釘付けできる要素をルールエンジンに任せ、要約のような帰納が必要な要素を AI に任せました。n8n のノードは純コード（全決定論）か LLM ノード（全ブラックボックス）の二択で、中間がありません。
3. 汎化能力：1 つの n8n workflow は 1 つのことしかできません。この meta-skill は理論上、n8n.io の 1 万あまりのテンプレートのどれを食べても、自分で解析し、自分で境界を質問できます。これは「自動化できる」ことと「自動化の仕方を学ぶ」ことの差です。

n8n がまだ強い 2 つの点

1. 決定論性と監査可能性：n8n は同じ workflow を 100 回走らせれば、ノードの実行経路は完全に一致し、問題が起きてもどのノードかを正確に特定できます。Codex skill は推論 + ルールの混合で、長期・大量運用では一致性が純ノードのチェーンに自然と劣ります。
2. 連携のブリッジ：n8n は多くの外部ノードに接続でき、クレデンシャルを設定すれば即座に使えます。Codex は認証やデータ形式の処理をその場でスクリプトに書く必要があります。

選び方の目安

• 判断が必要、自己修復が必要なシーン → Codex が有利
• 成熟したコネクタが必要、どこで壊れたか一目で見たいシーン → n8n が依然として適切

n8n は死んでいません。一部の仕事のやり方が、より賢いやり方に変わっただけです。