何が共有しづらいのか
n8nのHTTPRequestノードやCode nodeで組み立てたHTMLは、ワークフロー実行時の認証トークンやWebhook URLを含んだまま出力されることがある。そのファイルを未加工でURLに変換すると、APIキーが外部に露出するリスクが生じる。まず出力ファイルをテキストエディタで開き、`Authorization`ヘッダや`Bearer`という文字列が含まれていないかを確認してから共有ステップに進む。
社内ツール風のUIはボタンやフォームが多く、受け取った側がPCで確認した後にスマートフォンで再度開くケースも珍しくない。n8nで生成されたHTMLはレスポンシブ設定が省かれていることが多いため、モバイルで横スクロールが発生して操作できない状態になりやすい。URL化する前に、ブラウザの開発者ツールでスマホビューに切り替えてレイアウト崩れを目視しておく。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
n8nのワークフロー結果として出力されたHTMLには、外部のWebhook URLが`<form action="...">` に埋め込まれていることがある。そのまま公開すると、レビュワーが意図せずフォームを送信したときに本番のn8nワークフローが起動してしまう。プロトタイプ用途では`action`属性を`#`または`javascript:void(0)`に書き換え、送信ボタンにも`disabled`属性を加えておく。
画像やCSSを外部CDNではなくn8nサーバー内のパスで参照している場合、URL化した後にリソースが404になる。`src`や`href`属性をすべてgrep検索して、相対パスや`localhost`始まりのURLが残っていないかチェックする。問題があれば該当リソースをbase64でインライン化するか、公開済みCDNのURLに置き換えてから再出力する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
社内ツールのプロトタイプは、確認してほしい相手が明確な場合がほとんどだ。「開発担当者3名だけに見せたい」という状況であればパスワード認証が最も手軽で、URLとパスワードをセットで伝えるだけで運用が完結する。不特定多数のSlackチャンネルに流す場合は、ドメイン認証を使って社内メールアドレス保有者のみアクセス可能にする設定が安全性と利便性のバランスが取れている。
レビュー期限を設定しないと、半年後に同じURLで古いプロトタイプが見られる状態が続く。n8nは仕様変更が速いため、旧バージョンのUIを最新仕様と誤認されるリスクがある。期限は「レビュー依頼から7日間」程度に設定し、修正が発生したら同じURLで差し替えができるかどうかをアップロード前に確認しておく。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
「全体的にどうですか」という聞き方では、レビュワーが何を見ればよいか迷ってURLを開かないまま期限を迎えることが多い。共有メッセージには「ナビゲーションの操作感」「一覧画面のカラム順序」「エラー表示の文言」のように確認ポイントを3つ以内に絞り、番号を振って記載する。
n8nのプロトタイプは修正サイクルが短く、フィードバックを受けてすぐワークフローを再実行してHTMLを差し替えられる。その際、古いHTMLと新しいHTMLが混在しないよう、共有URLの末尾にバージョン番号（例: `?v=2`）を付けるか、ファイル名にタイムスタンプを含めてURL自体を変更する。レビュワーに「今のURLが最新版か」を毎回確認させない運用を最初から決めておく。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
n8nのCode nodeで生成したHTMLにBase64エンコードされた文字列がある場合、公開しても問題ないですか？
Base64はエンコードであり暗号化ではないため、デコードすれば誰でも内容を読める。埋め込まれているのがAPIキーや内部IPアドレスであれば公開前に必ず削除し、画像データであれば問題ない。
レビュワーがHTMLを直接ダウンロードしてローカルで開いてしまった場合、認証は意味を持ちますか？
ブラウザでURLを開いた時点での認証は機能するが、ダウンロードされたHTMLファイル自体には認証が付かない。ダウンロード不可の設定が使えるサービスを選ぶか、ファイルにwatermarkを入れてトレーサビリティを確保する。
フィードバックを受けてHTMLを差し替えた場合、レビュワーに再通知するタイミングの目安は？
修正が依頼から48時間以内であれば同じスレッドに「更新しました」と一言追記するだけで十分。それ以上経過している場合は新しいメッセージを送り、変更箇所を箇条書きで知らせると見落としが減る。