Open7

n8nを試す

dehio3dehio3

Gmail node setup

https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.gmail/

認証

https://docs.n8n.io/integrations/builtin/credentials/google/

  • OAuth2とサービスアカウントの２パターンの認証方法がある

Google は技術的に、Gmail で使用するためのサービス アカウントをサポートしていますが、ドメイン全体の委任を有効にする必要があり、Google はこれを推奨していません。また、その動作に一貫性がない可能性があります。n8n は、Gmail ノードで OAuth2 を使用することを推奨しています。

GCPでOAuth2クライアントIDを作成

Sign in with Google にて以下のエラー

このアプリが無効なリクエストを送信したため、ログインできません。しばらくしてからもう一度お試しいただくか、この問題についてデベロッパーにお問い合わせください。 このエラーの詳細
このアプリのデベロッパーの場合は、エラーの詳細をご確認ください。
エラー 400: redirect_uri_mismatch

OAuth2クライアントIDの認証済みリダイレクトURIに、n8nのOAuth Redirect URLの追加が必要

dehio3dehio3

Bedrock

Chat Modelは対話・生成、Embeddingsは検索・類似性計算の役割を担い、両者を組み合わせることでより高度なAIワークフロー（RAG、インテリジェント検索、自動分類等）が実現できます。

AWS Bedrock Chat Modelノード

機能

  • LLM（大規模言語モデル）による対話的なテキスト生成を行うノード
  • Amazon Bedrock上のClaude、Jurassic、Titanなどの基盤モデルを直接利用
  • プロンプトを入力として受け取り、AIが生成したテキスト応答を出力

設定パラメータ

パラメータ 必須／任意 説明 例／デフォルト値
Model 必須 使用するBedrockモデルを選択（例：Claude-3、Titan、Jurassic） Claude-3, Titan
Prompt 必須 モデルへの入力テキスト（ユーザーが生成を依頼するプロンプト） "Hello, world!"
Maximum Number of Tokens 任意 生成されるテキストの最大トークン数 512
Sampling Temperature 任意 出力のランダム性制御（高いほど創造的、低いほど確定的） 0.7
Top-p 任意 nucleus sampling の確率質量の閾値 0.9
Stop Sequences 任意 出力生成を停止させるトークンまたは文字列のリスト ["\n"]
AWS Region 必須 Bedrockサービスが提供されるAWSリージョン ap-northeast-1
AWS Access Key ID 任意 IAMユーザーのアクセスキーID。EC2インスタンスプロファイル利用時は空欄可 （未設定）
AWS Secret Access Key 任意 IAMユーザーのシークレットキー。EC2インスタンスプロファイル利用時は空欄可 （未設定）
Role ARN 任意 明示的に指定する場合のIAMロールARN arn:aws:iam::123456789012:role/n8n-bedrock-role
API Endpoint Override 任意 カスタムエンドポイントを利用する際に指定 https://example.com

使用例

  • メール自動返信: 受信メールの内容を解析し、適切な返信文を生成[6]
  • データ要約: Googleスプレッドシートから取得した案件データをChatGPTで要約し、Slackに通知[6]
  • 問い合わせ分類: メール内容から担当者を判定し、Slackでメンション通知[7]

Embeddings AWS Bedrockノード

機能

  • テキストをベクトル形式（埋め込み）に変換する専用ノード
  • RAG（検索拡張生成）システムの構築に必要な要素
  • 文書の意味的類似性を計算可能な数値ベクトルに変換

設定パラメータ

パラメータ 必須／任意 説明 例／デフォルト値
Model 必須 埋め込み生成用のBedrockモデルを選択（例：Titan Embeddings） Titan Embeddings
Input Text 必須 埋め込みを生成する元テキスト "This is a sample text."
AWS Region 必須 Bedrockサービスが提供されるAWSリージョン ap-northeast-1
AWS Access Key ID 任意 IAMユーザーのアクセスキーID。EC2インスタンスプロファイル利用時は空欄可 （未設定）
AWS Secret Access Key 任意 IAMユーザーのシークレットキー。EC2インスタンスプロファイル利用時は空欄可 （未設定）
Role ARN 任意 明示的に指定する場合のIAMロールARN arn:aws:iam::123456789012:role/n8n-bedrock-role
API Endpoint Override 任意 カスタムエンドポイントを利用する際に指定 https://example.com

使用例

  • RAGチャットボット構築: 社内文書をベクトル化してSimple Vector Storeに保存
  • 社内ナレッジシステム: 議事録、マニュアル、FAQ等をベクトル化し検索可能にする
  • 文書検索システム: 過去のトラブル事例やプロジェクト資料の類似検索

典型的な連携パターン

RAGシステムの構築フロー

  1. Embeddingsノードで社内文書をベクトル化
  2. Simple Vector Storeに埋め込みデータを保存
  3. ユーザーの質問もEmbeddingsノードでベクトル化
  4. ベクトルストアから関連文書を検索
  5. Chat Modelノードで検索結果を元に回答生成

実際のワークフロー例

メール受信トリガー → Chat Modelで内容分析 → 担当者判定 → Slack通知

ファイルアップロード → テキスト抽出 → Embeddingsでベクトル化 → Vector Storeに保存

質問入力 → Embeddingsでベクトル化 → 関連文書検索 → Chat Modelで回答生成
dehio3dehio3

Functionノード／Codeノードの「制約」

  • FunctionノードやCodeノードでは、n8nが用意した内部関数（awsApiRequestなど）や外部npmパッケージ（aws-sdkなど）を直接importできません。
  • どちらのノードも @n8n/vm2 の NodeVMサンドボックス でコードを実行します。
  • NodeVM は安全性のため「外部のnpmモジュールや内部n8n関数へのアクセスを禁止」しています。
    つまり、require/importは利用不可・グローバルは限定的・プロセスやファイルシステム、ネットワークへの直接アクセス不可。
  • 標準で使えるのは
    • JavaScriptの基本API（配列操作、Math、Object等）
    • n8nが事前に組み込んだ一部の便利関数（例：console.log, $jmespath, luxon など）
  • aws-sdk等のnpmライブラリや、n8n内部のawsApiRequest等は使えません。
  • より高度な連携や外部API呼び出しは「HTTP Requestノード」やカスタムノードで実装する必要あり。
dehio3dehio3

AWS Resource ExplorerをREST APIで使用してリソースを検索

https://docs.aws.amazon.com/resource-explorer/latest/apireference/API_Search.html

curl -X POST \
  https://resource-explorer-2.ap-northeast-1.amazonaws.com/Search \
  -H "Content-Type: application/json" \
  -H "Authorization: AWS4-HMAC-SHA256 Credential=ACCESS_KEY/DATE/ap-northeast-1/resource-explorer-2/aws4_request, SignedHeaders=..., Signature=..." \
  -H "X-Amz-Date: YYYYMMDD'T'HHMMSS'Z'" \
  -d '{"QueryString":"tag:Environment=prod","MaxResults":50}'
  • APIを呼び出す際は、AWS Signature Version 4による署名認証が必要
dehio3dehio3

Signature Version 4（SigV4）とは？

AWSのAPIを安全に利用するための署名認証の仕組みです。APIリクエストに対して署名を付けることで、送信者の本人確認とデータの改ざん防止を行います。

SigV4の仕組みの概要

  1. 署名対象のリクエスト情報を整理（カノニカルリクエスト作成）

    • リクエストのHTTPメソッドやURI、ヘッダー、ペイロードのハッシュなどを一定の形式に整えます。

  2. 署名鍵の生成

    • AWSアクセスキー（秘密鍵に相当）を日付、リージョン、サービス名に基づいて計算し、スコープされた署名鍵を作成します。

  3. 署名の計算

    • カノニカルリクエストのハッシュと署名鍵を用いてHMAC-SHA256で署名を計算します。

  4. 署名の付与

    • 計算した署名をリクエストの Authorization ヘッダーに含めてAWSに送信します。

なぜ署名するのか？

  • 送信者の本人確認
    署名に使われる秘密鍵を知っているのは認証されたユーザーのみなので、本人確認ができる。

  • 通信途中の改ざん防止
    リクエストの内容が署名計算に含まれており、途中で変更された場合に署名と一致しなくなるため検出可能。

  • リプレイ攻撃防止
    リクエスト中のタイムスタンプが一定時間内であることを検証し、過去の署名済みリクエストの再送を防ぐ。

SigV4とSigV4aの違い

  • SigV4

    • シングルリージョン向け。
    • 署名鍵はリージョンやサービスごとに異なる。
    • 一般的なAWS APIリクエストで使用。

  • SigV4a

    • マルチリージョン対応。
    • 公開鍵暗号を使い、複数リージョンで署名が有効。
    • S3のマルチリージョンアクセスポイントなどの特殊用途向け。

署名の作成と検証の流れ

  1. クライアントはリクエスト情報から署名を作成し、APIリクエストに署名情報を付与する。

  2. AWSサービス側は同じ手順で署名を再計算し、一致すれば認証成功、一致しなければ拒否される。

実際の利用について

  • AWS SDK や CLI を使う場合は署名処理は自動で行われるため、ユーザーが署名の計算を意識する必要は基本的にありません。

  • 独自にAPIを直接呼ぶ場合は、自分で署名計算ロジックを実装する必要があります。

補足

  • 署名はHTTPヘッダーの Authorization に付加する方法や、URLクエリパラメータに署名情報を付加する方法があります。

  • 署名作成には厳密な日付時間の同期が必要で、リクエストがタイムスタンプから5分以上ずれているとAWSは拒否します。

  • AWS公式ドキュメントには署名作成の詳しい計算手順やコード例が掲載されています。

このように、AWS Signature Version 4はAWS APIを安全に使うための認証プロトコルであり、AWS SDKを使う場合はほぼ自動的に処理されますが、直接APIを呼び出す場合には理解と実装が必要な重要な仕組みです。

1