n8n-hebrew-workflows

n8n Hebrew ワークフロー

手順

ステップ 1：自動化パターンを特定する

スケジュール実行フローは Schedule Trigger から開始し、必ず安息日／祝日のゲート（ステップ 4）を追加します。イベント駆動型フロー（支払い確認、フォーム送信）は Webhook トリガーから開始します。ヘブライ語テキストのエンコードや RTL 処理が必要な場合は早い段階で Code ノードを追加し（ステップ 3）、分類や要約には AI Agent ノードを追加します（ステップ 7）。ここで名前を挙げたイスラエルの各サービスのフィールド参照は、references/israeli-api-endpoints.md にあります。

ステップ 2：n8n でイスラエルの API に接続する

Morning（旧 Green Invoice）API

Morning（「hashbonit yeruka」／ חשבונית ירוקה）は、API キーとシークレットを使って JWT トークンを取得します（OAuth2 ではありません）。HTTP Request を設定します：

POST https://api.greeninvoice.co.il/api/v1/account/token
Body: { "id": "{{$env.GREEN_INVOICE_API_KEY}}", "secret": "{{$env.GREEN_INVOICE_API_SECRET}}" }

レスポンスには 60 分間有効な JWT が含まれます。Authorization: Bearer {{$json.token}} として渡してください。

イスラエルのインボイス改革 2026（基準額の段階的引き下げ）： 基準額を超える税務インボイスには、税務当局から取得した割当番号（mispar haktza'a）が必要です。基準額は年の途中で引き下げられます：

適用開始日	基準額
2026年1月1日	10,000 NIS
2026年6月1日以降	5,000 NIS

この制度は 2024 年 5 月（25,000 NIS）に始まり、その後 2025 年 1 月からは 20,000 になりました。そのため、過去のインボイスを扱うワークフローでは、それぞれのインボイスについて、その発行日当時に適用されていた基準額を確認する必要があります。全日程は references/israeli-api-endpoints.md にあります。

この件には 2 つの別々の規則があり、混同するのが典型的な誤りです。 売り手の義務は s.47(א2)(1) で、買い手の要求があった場合にのみ発生し、税率ゼロの取引には適用されません：「ובעסקה שסכומה, בלא המס, עולה על הסכום האמור בסעיף 38(א1), חייב הוא לעשות כן לפי דרישת הקונה; הוראות סעיף קטן זה יחולו לעניין חשבונית מס שהוצאה בשל עסקה שהמס שחל לגביה אינו בשיעור אפס」。買い手の仕入 VAT 控除が認められなくなる規則は s.38(א1) で、買い手からの要求を条件としません：「לא יותר ניכוי מס התשומות הכלול בחשבונית מס שסכומה, בלא המס, עולה על 5,000 שקלים חדשים (מינואר 2026 ועד מאי 2026: 10,000 שקלים חדשים) ושאינה כוללת מספר שהקצה לה המנהל」。したがって、「買い手から要求がなかった」ことを適用除外の根拠にしてはいけません。עולה על（超える）に注意してください。ちょうど 5,000 のインボイスは規則の対象外なので、>= ではなく > を使用します。

基準額は VAT 抜きで判定します。 Morning の amount フィールドと比較し、totalAmount は使わないでください。VAT 率が 18% の場合、この 2 つには 5,000 NIS の基準額付近で 900 NIS の差があるため、誤ったフィールドと比較するとその範囲のインボイスを誤分類します。

基準額はハードコードせず、設定可能な変数にしてください。金額の単位はアゴラではなくシェケルの小数です。 price: 50 は 50 NIS を意味します。

文書の作成と送信は 1 回の呼び出しで行います。既存の文書をメール送信するエンドポイントはないため、送信は作成時に POST /api/v1/documents の emailContent と attachment で指定します。Morning の API リファレンスは JS のみのアプリであり、すべてのパスに対して HTTP 200 を返すため、このスキルでは正確なリクエスト本文の形式を検証できていません。 まずブラウザーで https://www.greeninvoice.co.il/api-docs を確認し、割当番号なしで作成された文書は再試行するのではなく、人による対応が必要なものとして扱ってください。

Morning の一般的なエンドポイント：

エンドポイント	メソッド	用途
/api/v1/documents/search	POST	日付範囲、クライアント、ステータスでインボイスを検索
/api/v1/documents	POST	新しいインボイス／領収書を作成
/api/v1/clients/search	POST	名前または osek 番号でクライアントを検索
/api/v1/documents/payments/search	POST	照合用の支払い記録を取得
/api/v1/businesses/me	GET	現在の事業者情報を取得

文書タイプコード：10（見積書）、305（税務インボイス）、320（税務インボイス＋領収書）、330（クレジットノート）、400（領収書）。エンドポイントの詳細とレスポンススキーマは references/israeli-api-endpoints.md にあります。

EZCount（EasyCount）API

EZCountは、一般的なMorningの代替サービスです。REST + JSONを使用し、本文のapi_key + api_emailで認証します（Bearerではなく、OAuthでもありません）。

POST https://api.ezcount.co.il/api/createDoc
Body: { "api_key": "...", "api_email": "...", "developer_email": "[email protected]",
        "type": 320, "customer_name": "שם הלקוח", "customer_email": "[email protected]",
        "item": [{ "details": "שירותי ייעוץ", "amount": 1, "price": 500, "vat_type": "INC" }] }

文書タイプコードは、Morningで使用される税務当局の番号体系（305/320/330/400）に対応しています。金額はシェケルの小数で、vat_typeはデフォルトでPRE（VAT抜き価格）、VAT込みの場合はINCです。

EZCountの割当保留はHTTP 417であり、再試行可能なフィールドではありません。 ドキュメントには「税務当局の割当番号を待っている間、ステータス417を返します」とあります。allocation_statusフィールドはなく、再試行しても保留は解消されません。417の場合、ドキュメントには4つの選択肢が示されています。割当番号をスキップする、文書をキャンセルする、追加の異議申し立てを行う、またはリバースチャージ（VATをゼロ税率にして再発行し、購入者が自ら請求書を発行する）です。417を条件分岐で処理し、税務当局からのメッセージを表示して、人が選択できるようにしてください。4つのうち3つには税務上の影響があるためです。レート制限は10秒あたり250リクエストで、並列ではなく逐次実行してください。

EZCountとMorningは同じ法的効力を持つ書類を作成します。ユーザーがすでに利用しているスイートに合わせて選択してください。

Code Node経由のisraeli-bank-scrapers

israeli-bank-scrapersはNode.jsのライブラリであり、CLIではありません。そのため、createScraper()を使ってCodeノード内で実行します。Node.js >= 22.22.2が必要です。動作を左右する要件は3つあり、順に対処が必要です。require()で解決できるよう、タスクランナーでNODE_FUNCTION_ALLOW_EXTERNAL=israeli-bank-scrapersを設定すること、機能するシークレットの受け渡し経路を用意すること（以下の注記を参照。「認証情報ストアを使う」方法はCodeノードからは機能しません）、そして銀行ごとに正しい認証情報キーを指定することです。キーはuserPasswordではなく、必ずpasswordです。最初のフィールドは銀行によって異なります（HapoalimはuserCode、Leumi/Mizrahi/Maxはusername、Discount/Mercantileはid + num、Isracard/Amexはid + card6Digits）。フィールドの形式を決めつけず、SCRAPERS[companyId].loginFieldsを参照してください。

「認証情報ストアから取得する」方法はCodeノード内では実装できないため、シークレットの受け渡し方法を慎重に選ぶ必要があります。 Codeノードでは認証情報を宣言しないため、$credentialsを利用できません。また、2.xでは$envもデフォルトでブロックされています。実際に使える方法は3つです。タスクランナーでN8N_BLOCK_ENV_ACCESS_IN_NODE=falseを設定して$envを使い続ける方法、先行する認証情報対応ノードからシークレットを渡す方法（実行データに含まれることを受け入れる必要があります）、またはエンタープライズ版で外部シークレットを使う方法です。

Cloudflareによるブロック（2026年）： ボット検出により、AmexとIsracardではヘッドレスブラウザーがブロックされます。メンテナンスされているフォーク@sergienko4/israeli-bank-scrapersは、Camoufoxを使ってこれを回避します。

スクレイピングが本当に適切な方法か検討してください。 この方法では、顧客の現在有効な銀行ログイン情報を保存し、ヘッドレスブラウザーから顧客になりすましてサインインするため、認証情報の共有を禁じる多くのイスラエルの銀行利用規約に抵触するおそれがあります。認可を受けた「金融情報サービス法」（オープンバンキング）に基づく代替手段があり、顧客向けサービスではこちらが正当化しやすい方法です。動作するサンプルコード、CompanyTypesの全一覧、銀行ごとのログインフィールド表はreferences/israeli-api-endpoints.mdにあります。

data.gov.il CKAN API

GET https://data.gov.il/api/3/action/datastore_search?resource_id=<guid>&q=<term>&limit=100

便利なリソースID：非営利団体登録簿（be5b7935-3922-45d4-9638-08871b17ec95。登録済みのアムタを検索できます）、HSコード別の貿易統計（複数のIDがあります）。APIが返すフィールド名はヘブライ語です。後続の処理に進む前に、Codeノードでキーを英語に正規化してください。

WhatsApp Business Cloud

n8n には、送信用のファーストクラスノード n8n-nodes-base.whatsApp（「WhatsApp Business Cloud」、typeVersion 1.1、認証情報 whatsAppApi）と、受信用の n8n-nodes-base.whatsAppTrigger が用意されています。操作は、送信、テンプレートを送信、送信して応答を待機です。

Meta のルールが 2 つあり、これらのワークフローに影響します。24 時間のカスタマーサービスウィンドウ： ユーザーからメッセージまたは電話を受けると、自由形式のメッセージを送信できる 24 時間のウィンドウが開きます。この時間外は事前承認済みのテンプレートのみ送信できます。スケジュールされたワークフローは定義上この時間外に実行されるため、「テンプレートを送信」を使う必要があります。テンプレートは事前承認が必要です。 マーケティング、ユーティリティ、認証の 3 つのカテゴリのいずれかで承認を受ける必要があるため、早めに申請してください。料金は配信されたメッセージごとに発生します（会話ごとの課金は 2025 年 7 月 1 日に終了したため）。そのため、ファンアウトループでは項目ごとに費用がかかります。

Israeli SMS Gateways

ゲートウェイ	ホスト	認証	最適な用途
019 Telzar	019sms.co.il	Bearer token、またはユーザー名＋パスワード	一括マーケティング、トランザクション
InforUMobile	capi.inforu.co.il	Bearer token（IP 許可リストの適用あり）	OTP、トランザクション
Nexmo/Vonage IL	rest.nexmo.com	API key＋secret	国際＋国内

019 は送信に失敗しても HTTP 200 を返します。 認証に失敗した場合も、200 {"status":3,"message":"Username or password is incorrect..."} が返るため、デフォルトの HTTP Request ノードは成功として処理し、SMS が配信されないままワークフローを続行します。Always Output Data を有効にし、HTTP ステータスコードではなく、IF ノードを使って $json.status（0 = 送信済み）を条件分岐してください。InforUMobile はトークンに加えて IP 許可リストも適用するため、Cardcom や Tranzila と同様に、n8n の送信元 IP も許可リストに追加してください。

電話番号は国際形式の 972XXXXXXXXX（先頭の 0 を除く）にする必要があります。また、番号の正規化では単に形式を変換するのではなく、必ず有効性を検証してください。イスラエルの固定電話のプレフィックス（02/03/04/08/09、072-077）と 1-800 または *NNNN の番号には SMS を送信できないため、無条件に 0 を 972 に置き換えると、気付かないうちに番号が誤った形式になります。リクエストボディ、ゲートウェイごとのフィールド名、プレフィックスを確認する正規化処理については、references/israeli-api-endpoints.md を参照してください。

ワークフロー全体を左右するイスラエルの3つの規則

1. すべての事業者が税務請求書を発行できるわけではありません。 עוסק פטור は חשבונית מס（305 / 320）を発行できず、VAT を請求することもできません。発行できるのは קבלה または חשבונית עסקה です。書類の種類を選ぶ前に VAT 登録状況を確認し、305/320 をハードコードしないでください。ゼロ税率の適用対象（輸出、外国居住者へのサービス）やエイラートの免税措置によっても税率が変わるため、vat_type は取引ごとに決定してください。番号は連番で変更できません。誤った請求書はクレジットノート（330）で取り消し、削除してはいけません。また、書類は7年間保管する必要があるため、有効期限のあるリンクではなくPDFを保存してください。

2. 商用メッセージの自動送信は規制されています。 通信法（תיקון 40）第30א条は、このスキルで送信できるすべてのSMSとWhatsAppに適用されます。第30א条（ב）により、送信する前に明示的な書面による事前同意が必要です。第30א条（י）（1）では、違反して受信されたメッセージ1件につき、損害の立証なしで最大1,000 NISの損害賠償が認められています。これは一括送信のループがそのまま招くリスクです。Metaの24時間ウィンドウはプラットフォーム上の規則であり、法律上の規則ではありません。ウィンドウの要件を満たしても、同意が不要になるわけではありません。

ラベル表示の要件はチャネルごとに異なり、よく誤解されています。一般規則である第30א条（ה）（1）（א）では、メッセージの冒頭に פרסומת と記載する必要があります。ただし、第30א条（ה）（2）はSMSの例外規定です。SMSで送る広告には、広告主の名前と、拒否通知の連絡先のみを記載します（「יציין בדבר הפרסומת רק את שמו ואת דרכי יצירת הקשר עמו לצורך מתן הודעת סירוב」）。一般規則が適用されると思い込んで、SMSテンプレートに פרסומת を前置しないでください。

3. これらのワークフローで扱うデータは、規制対象の個人データです。 決済コールバックに含まれるTeudat zehut、リアルタイムの銀行認証情報、第三者のLLMに渡される取引明細は、改正後のプライバシー保護法（改正第13号、2025年8月施行）の適用対象です。保存するデータは最小限にし、Google Sheetを保持ルールのある規制対象データベースとして扱い、適法な根拠なく、個人を特定できる顧客データを国外のモデルに送信しないでください。

ステップ3：n8nノードでヘブライ語データを処理する

Codeノードは文字列をUTF-8として処理するため、ヘブライ語はそのまま扱えます。問題は境界部分で発生します。CSVのエクスポートにはUTF-8 BOMが必要です。そうしないとExcelがANSIとして読み込みます。HTTP RequestのレスポンスにはUTF-8のレスポンスエンコーディングを明示する必要があります。メール本文には <div dir="rtl"> が必要です。data.gov.ilはヘブライ語のJSONキーを返すため、Codeノードで正規化してください。また、文字列の長さには .length ではなく Array.from(str).length を使ってください。イスラエルの銀行や会計システムからの古いエクスポートはUTF-8ではなくWindows-1255であることが多く、BOMに関する対処では解決できません。さらに、顧客が入力した名前に双方向制御文字が含まれると、表示された請求書上で金額の位置が視覚的に入れ替わることがあります。

通貨の書式設定には Intl.NumberFormat('he-IL', { style: 'currency', currency: 'ILS' }) を使用してください。イスラエルの書類の日付形式はDD/MM/YYYYです。MorningはISO 8601形式を返しますが、政府のデータセットはDD/MM/YYYY形式の文字列を返すため、new Date(s) を信用せず、明示的に解析してください。解析ヘルパー、ヘブライ語の月名マップ、プレフィックスを検証する電話番号正規化関数は references/israeli-api-endpoints.md にあります。

Step 4: Shabbat に配慮したスケジュール設定

イスラエルの業務ワークフローは、Shabbat（毎週金曜日の日没から土曜日の日没まで）とユダヤ教の祝祭日に実行してはいけません。n8n の Schedule Trigger には標準でこの機能がないため、スケジュール実行するすべてのワークフローの先頭にチェックノードを追加してください。

アーキテクチャ： Schedule Trigger -> HTTP Request (Hebcal) -> IF (is Shabbat?) -> Continue or Stop

GET https://www.hebcal.com/shabbat?cfg=json&geonameid=293397&M=on

geonameid=293397 はテルアビブです。エルサレムは 281184、ハイファは 294801、ベエルシェバは 295530 です。キャンドル点灯時刻は、エルサレムでは日没の 40 分前、ハイファとジフロン・ヤアコブでは 30 分前、それ以外の地域では 18 分前のため、geonameid は重要です。ワークフローを実行するかどうかを判定する Code ノードは次のとおりです。

const now = new Date();
const items = $input.first().json?.items;
// FAIL CLOSED: if we cannot read the calendar we do not know, so we do not run.
if (!Array.isArray(items) || items.length === 0) return [];

// Pair each candle-lighting with the FIRST havdalah after it. Taking
// items.find('candles') and items.find('havdalah') is wrong: asked ON a chag,
// Hebcal returns that chag's havdalah BEFORE the next festival's candles, so
// the range test is unsatisfiable and the workflow runs on Yom Kippur.
const ev = items.filter(i => i.category === 'candles' || i.category === 'havdalah')
  .map(i => ({ cat: i.category, at: new Date(i.date) }))
  .sort((a, b) => a.at - b.at);

for (let k = 0; k < ev.length - 1; k++) {
  if (ev[k].cat === 'candles' && ev[k + 1].cat === 'havdalah'
      && now >= ev[k].at && now <= ev[k + 1].at) return [];
}
if (ev.length && ev[0].cat === 'havdalah' && now <= ev[0].at) return [];
return $input.all();

作業を何も言わずに破棄しないでください。 return [] はその分岐を終了するため、Shabbat 中に予定されていた請求書や顧客への通知は、遅延されずに失われます。顧客が待っている処理は、項目をキュー（ワークフローの静的データまたはテーブル）に入れ、別のハヴダラー後ワークフローから順次処理してください。

ユダヤ教の祝祭日については、https://www.hebcal.com/hebcal?v=1&cfg=json&year=now&month=x&maj=on&mod=on&i=on に問い合わせ、yomtov: true の項目に絞り込んでください。どちらのクエリパラメーターも重要で、どちらも失敗してもエラーが表示されません。month=now は無効です。HTTP 200 と "items": [] が返されるため、ゲートは一度も作動しません。i=on を指定しない場合、Hebcal はイスラエルではなくディアスポラの暦を返します。2026 年の yomtov はイスラエルでは 8 日間ですが、ディアスポラでは 13 日間となり、通常の営業日が 5 日間停止されます。平日のみの cron を使っても、このゲートは不要になりません。2026 年のイスラエルの yomtov 8 日間のうち 6 日間は日曜日から木曜日に当たり、その中には Yom Kippur も含まれます。references/shabbat-cron-patterns.md には、修正済みのパターン、erev chag に必要なイスラエル現地日付の処理、およびこのゲートでは対象外となる断食日と chol-hamoed のケースが記載されています。

Step 5: イスラエルの決済ゲートウェイ Webhook

イスラエルのカード決済のほぼすべては 3 つのゲートウェイで処理されますが、それぞれコールバックの配信方法が異なります。全フィールドの一覧、ベースパス、Bit のフローは references/israeli-api-endpoints.md に記載されています。正確性を左右する要点を以下に示します。

ゲートウェイ	コールバックの形式	成功の判定	重複排除キー
Cardcom v11	WebHookUrl に LowProfileResult を POST	ResponseCode == 0	TranzactionId
Tranzila	GET クエリパラメーター	Response == '000'	index
Grow by Meshulam	POST multipart/form-data（JSON ではありません）	webhookKey が保存済みキーと一致することを確認し、その後に再読み込み	asmachta

ReturnValue は Cardcom のステータスフィールドではありません。 Cardcom の v11 仕様では、これを「トランザクションに保存するデータの文字列。通常は固有の注文 ID を送信し、Webhook URL で受け取ります」と説明しています。これは渡した値がそのまま返されるパススルーです。これを基準に分岐すると、拒否された決済を承認してしまいます。v11 に DealResponse フィールドは存在しません。また、InternalDealNumber／CardOwnerID／NumOfPayments はレガシーの classic API の名前であり、結果オブジェクトには含まれていません。そのため、InternalDealNumber を使って重複排除キーを作成すると、常に undefined となり、請求書の重複発行を防ぐガードは作動しません。teudat zehut と分割払いの回数は、TranzactionInfo の CardOwnerIdentityNumber と NumberOfPayments に格納されています。

コールバックの本文をそのまま使って書類を発行しないでください。 Webhook URL は公開されており、これら 3 つのゲートウェイはいずれもペイロードに署名しません。そのため、金額がもっともらしい偽造 POST を送るだけで、ワークフローによって実際の税務請求書が発行され、実際の割当番号が消費されてしまいます。まずサーバー側でトランザクションを再取得し（Cardcom は TranzactionId、Grow は getPaymentProcessInfo、Tranzila は index を使用）、金額を確認してから発行してください。Grow では、完了のために approveTransaction も必要です。

Bit は単独の API ではありません。Tranzila v2（決済ページで bit: true を指定）または Bit を有効にした Grow 経由で利用し、同じ Webhook フローに異なる transactionType で届きます。

Webhook の認証

n8n の Webhook ノードでは、認証モードとして「なし」、「Basic 認証」、「Header 認証」、「JWT 認証」の 4 つをサポートしています。2026 年に発生した未認証 Webhook の CVE の経緯を踏まえると、パブリックにルーティング可能な Webhook で「なし」を選ぶことは、実質的に脆弱性です。ただし、上記の 3 つのイスラエルのゲートウェイでは、通信時の認証は実際の保護策ではありません。いずれもペイロードに署名しないため、実際に保護するのはサーバー側での再読み込みです。n8n の JWT 認証は署名と exp クレームを検証しますが、iss や aud は検証しません。references/webhook-auth-patterns.md には、動作するスニペットと、単純な HMAC チェックを破綻させる生のボディに関する注意点があります。

IP ホワイトリスト： Cardcom と Tranzila では、Webhook の IP をホワイトリストに登録する必要があります。セルフホストする場合は、固定 IP または送信元が固定されたリバースプロキシが必要です。

ステップ 6：セルフホストに関する考慮事項

n8n 2.x のセキュリティラインとバージョンの固定

n8n 2.0 は 2025 年 12 月にリリースされました。2026 年 9 月時点での最新の安定版は 2.38.7 です。2.32.1 以上に固定し、n8nio/n8n:latest は絶対に使わないでください。3 件の重大な脆弱性（CVE-2026-44789 HTTP Request ノードのプロトタイプ汚染による RCE、CVE-2026-44790 Git ノードによる任意のファイル読み取り、CVE-2026-44791 XML ノードのパッチ回避）は 2026-05-14 に公開され、2.22.1 で修正されました。認証情報の窃取やサンドボックスの脱出に関する重大度 HIGH の修正は、2.31.5 および 2.32.1 までに適用されました。CVE-2026-44789 はこのスキルの重要な処理経路にあります。ここで紹介するイスラエルの各連携はすべて HTTP Request ノードを使用し、各決済ゲートウェイのワークフローにはパブリックな Webhook ノードが追加されるためです。

2.0 の破壊的変更に伴う 2 つの設定がこのスキルのコードを制限します。タスクランナーが有効な場合（2.0 のデフォルト）、どちらもメインコンテナではなくランナーに設定する必要があります。

NODE_FUNCTION_ALLOW_BUILTIN=crypto
NODE_FUNCTION_ALLOW_EXTERNAL=israeli-bank-scrapers

N8N_BLOCK_ENV_ACCESS_IN_NODE も 2.x ではデフォルトで true のため、Code ノード内の $env.* は何も返さずに処理されます。Code ノードで認証情報を宣言していないため、認証情報ストアを使っても解決しません。ステップ 2 にある 3 つの方法のいずれかを選んでください。

**n8n 3.0 は 2026 年 10 月にリリースされ、**セルフホスト環境での npm インストール（Docker のみ）、Function／Function Item／Item Lists ノード、$getPairedItem ヘルパー、そして従来のすべてのエージェントモードを備えた AI Agent ノード v1 が削除されます。ステップ 7 は、現行の Tools Agent を使って構築してください。

CVE の全履歴、2.0 の破壊的変更の表、Execute Command を再有効化する方法、3.0 での削除項目の全一覧、イスラエルのデータレジデンシーに対応したホスティングオプションについては、references/n8n-version-migration.md を参照してください。

イスラエルで重要なセルフホスト設定

GENERIC_TIMEZONE=Asia/Jerusalem と TZ=Asia/Jerusalem の両方を設定してください。設定しないと、Schedule Trigger ノードは UTC で実行され、安息日の計算に 2～3 時間のずれが生じます。イスラエルの夏時間は、3 月最後の日曜日の前の金曜日から 10 月最後の日曜日までです。認証情報ストアが再起動後も維持されるよう、安定した N8N_ENCRYPTION_KEY を設定し、イメージタグを固定して、Code ノードのモジュール変数はタスクランナーのサービスに設定してください。すぐに使える Compose ファイルとイスラエルのデータレジデンシー対応ホスティングの表は、references/n8n-version-migration.md にあります。

ステップ 7：イスラエルのワークフロー向け n8n AI エージェントノード

n8n 2.x には、ネイティブの LangChain 統合（「Advanced AI」ノードグループ）が含まれています。RAG 用の Tools Agent、メモリノード、ベクトルストアノード（Pinecone、Qdrant、Supabase pgvector）、OpenAI、Anthropic、Ollama 経由のローカルモデル用のモデルノードを利用できます。Tools Agent を基盤に構築してください。n8n 3.0 では、AI Agent node v1 とともに SQL、Conversational、OpenAI Functions、Plan-and-Execute、ReAct モードが削除されます。

チュートリアルに記載されたモデル名をハードコードしないでください。 現在の Anthropic Chat Model ノードは、固定のドロップダウンではなく実行時に Anthropic API からモデルリストを取得するため、n8n のリリースがなくてもリストが変わります。要件に応じて選択してください（ヘブライ語の分類には中位クラスの最先端モデル、ヘブライ語の長文の法律文書には利用可能な最強モデル、リアルタイムチャットにはファミリー内で最も低レイテンシのモデル、PII をイスラエル国内に留める必要がある場合はイスラエルの VPS 上のローカルな多言語モデル）。そのうえで、現在ノードが提供しているモデルを選びます。ヘブライ語コーパスの RAG には多言語埋め込みモデル（Cohere の embed-multilingual-v3.0 または OpenAI の text-embedding-3-large）を使用してください。text-embedding-ada-002 はヘブライ語への対応が不十分です。顧客の取引明細を外国のモデルに渡すことは、品質だけでなくプライバシーに関する判断でもあることに注意してください。

n8n MCP ノード。 MCP Client Tool（@n8n/n8n-nodes-langchain.mcpClientTool）はサブノードとして接続され、AI エージェントが外部の MCP サーバー上のツールを呼び出せるようにします。たとえば、agentskills.co.il の hebcal、israeli-bank、data-gov-il サーバーが該当します。MCP Server Trigger（@n8n/n8n-nodes-langchain.mcpTrigger）は、n8n ワークフロー自体を MCP ツールとして公開し、Claude Desktop、Cursor、Windsurf から呼び出せるようにします。typeVersion 2 以降では、n8n User Auth（OAuth2）も利用できます。toolMcp ノードは存在しません。この名前はよくある幻覚であり、n8n はこれを使用したワークフロー JSON を拒否します。ヘブライ語の取引分類器の実例は、references/n8n-workflow-authoring.md にあります。

ステップ 8：プラットフォームの選択、ワークフロー JSON、認証情報

イスラエルのデータレジデンシーに対応するセルフホスト、無制限の自動化、またはイスラエルの API 固有の事情に対応するための完全なコードアクセスが必要な場合は、Make.com や Zapier より n8n を選んでください。3 つともイスラエルの API に対応する組み込みノードを備えていないため、いずれの場合も HTTP Request ノードと Code ノードが必要です。イスラエルのリージョンでホストできるのは n8n だけです。

ワークフローは JSON です。nodes 配列（各ノードには接続キーとして使用される一意の name、n8n-nodes-base.httpRequest のような type、typeVersion、parameters、position が含まれます）と、ソースノード名をキーとする connections オブジェクトで構成されます。POST /api/v1/workflows でインポートしてから、実行前に公開してください。チュートリアルの古い番号をコピーするのではなく、各ノードの現在の typeVersion を固定してください。たとえば、Schedule Trigger は 1.4 ですが、ほとんどのサンプルではまだ 1.2 が示されています。

シークレットは n8n の暗号化された認証情報ストアに保存し、ワークフロー JSON に直接記述しないでください。ただし、ここで重要な例外が 1 つあります。Code ノードには認証情報がないため、銀行と HMAC のシークレットにはステップ 2 で説明した方法のいずれかが必要です。Morning にもネイティブの認証情報がないため、HTTP Request で /account/token にアクセスし、Authorization: Bearer {{token}} を後続処理に渡してください。JWT は 60 分後に期限切れとなるため、実行のたびに更新します。

references/n8n-workflow-authoring.md には、比較表の全体、ワークフロー JSON の完全なサンプル、サービスごとの認証情報の設定方法が記載されています。

例

例1：平日の朝に請求書を照合する

「毎朝、前日のMorningの請求書を取得し、未払いのものにフラグを付けてください。」

0 9 * * 0-4（GENERIC_TIMEZONEが設定されているため、イスラエル時間の09:00）にSchedule Triggerを設定し、Step 4の祝日ゲートにつなぎます。2026年の8日間のヨムトーブのうち6日間がこのcronの対象になるためです。続いて、JWTを取得するために/api/v1/account/tokenへHTTP Requestを送り、Authorization: Bearer {{$json.token}}を指定して/api/v1/documents/searchへHTTP Requestを送ります。fromDate／toDateを前日に、typeを305／320に絞り込み、支払い状況に応じて分岐するIFノードを配置し、ヘブライ語の本文を<div dir="rtl">で囲んだSMSまたはSend Emailノードを追加します。

例2：祝日を考慮して銀行取引をGoogle Sheetに記録する

「毎晩、事業用口座の取引を取得して新しい取引をシートに追記します。ただし、安息日と祝日は除外してください。」

Schedule Triggerの後に、Step 4のHebcalリクエストとペアスキャンゲート（フェイルクローズ）を配置します。次に、実際のシークレットルートを指定してcreateScraper()でisraeli-bank-scrapersを実行するCodeノード、ヘブライ語の摘要とDD/MM/YYYY形式の日付を正規化するCodeノード、Google Sheets Appendの順に配置します。さらに、通知のないまま処理が停止してしまうため、無人実行のスクレイピングがエラーを起こした場合に備えて、別のError Triggerワークフローを追加します。

おすすめのMCPサーバー

• hebcal：ヘブライ暦／ユダヤ暦と安息日の時刻を扱えます。各ワークフローでHebcal HTTPを呼び出す代わりに使えます。
• israeli-bank：イスラエルの銀行口座データを扱えます。エージェントは、Codeノードでisraeli-bank-scrapersを実行せずに取引を取得できます。
• data-gov-il：イスラエル政府のオープンデータ（CKAN）を扱えます。HTTP Requestノードを手作業で組み立てずに、レジストリを照会できます。

参考リンク

ソース	URL
n8nドキュメント	https://docs.n8n.io/
n8n 2.0の破壊的変更	https://docs.n8n.io/changelog/v20-breaking-changes
n8n Codeノードでのモジュール有効化	https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/enable-modules-in-code-node
n8nでのノードアクセスのブロック	https://docs.n8n.io/hosting/securing/blocking-nodes/
Morning（Green Invoice）API	https://www.greeninvoice.co.il/api-docs
Hebcal API	https://www.hebcal.com/home/developer-apis
data.gov.il CKAN API	https://data.gov.il/api/3/action/help_show?name=datastore_search_sql

注意事項

• エージェントが :latest または古い 2.1x／2.2x タグを固定してしまいます。 2.21.4 だけで公開済みアドバイザリが 68 件あり、そのうち 3 件は CRITICAL（2.22.1 で修正された CVE-2026-44789／44790／44791 の一連の脆弱性）です。さらに、認証情報の窃取につながる HIGH 深刻度の修正が 2.32.1 まであります。パブリックな Webhook ノードがあると、リスクが高まります。2.32.1 以上を固定してください。現在の安定版は 2.38.7 です。
• エージェントが MCP Client Tool に @n8n/n8n-nodes-langchain.toolMcp と記述してしまいます。 そのようなノードは存在しません。型は mcpClientTool と mcpTrigger です。
• エージェントがスケジュール済みワークフローから自由形式の WhatsApp メッセージを送信してしまいます。 その時点では Meta の 24 時間のカスタマーサービス対応時間が終了しているため、承認済みテンプレートでしか配信できません。Send Template を使用し、ワークフローをリリースする前にテンプレートの承認を受けてください。
• エージェントが EZCount の 417 を一時的なエラーとして再試行してしまいます。 417 は税務当局が番号を割り当てていないことを意味するため、再試行しても解消されません。allocation_status フィールドはありません。417 の場合は分岐し、文書化されている 4 つの選択肢を提示してください。
• エージェントが Code ノード内で $env を使ってシークレットを読み取ってしまいます。 2.x ではデフォルトでブロックされるため、読み取り結果は何も返さず、未定義の値によってノードが失敗します。ただし、認証情報ストアでは解決できません（Code ノードには認証情報がないためです）。ステップ 2 にある 3 つの方法から選んでください。
• エージェントがモジュールを許可リストに追加せずに Code ノード内で require() を呼び出してしまいます。 require('crypto') には NODE_FUNCTION_ALLOW_BUILTIN=crypto、require('israeli-bank-scrapers') には NODE_FUNCTION_ALLOW_EXTERNAL=israeli-bank-scrapers が必要です。タスクランナーが有効な場合（2.0 ではデフォルト）、どちらもメインコンテナではなくランナー上で実行されます。
• エージェントがスケジュールトリガーのタイムゾーンをデフォルトで UTC にしてしまいます。 イスラエルでは Asia/Jerusalem を使用します。夏時間は 3 月最後の日曜日の前の金曜日から 10 月最後の日曜日までです。GENERIC_TIMEZONE を設定し、夏時間が切り替わるたびに再確認してください。
• エージェントが VAT 込みだと思い込んでしまいます。 イスラエルの請求書では、VAT 抜きの金額（lifnei maam）が記載されることがよくあります。Morning は amount（VAT 抜き）と totalAmount（VAT 込み）の両方を返します。現在の VAT は 18% です（2026 年）。
• エージェントがろうそく点灯時刻を 1 つに固定してしまいます。 時刻は都市によって異なります（エルサレムは日没の 40 分前、ハイファとジフロン・ヤアコヴは 30 分前、テルアビブなどは 18 分前）。そのため、時刻を固定すると、どこかで安息日の最中に実行されてしまいます。
• エージェントが Cardcom の Webhook を ReturnValue で分岐してしまいます。 これは返された独自の注文 ID であり、ステータスではありません。ResponseCode == 0 を使い、存在しない InternalDealNumber ではなく TranzactionId で重複を排除してください。
• エージェントが items.find('candles') と items.find('havdalah') で安息日ゲートを構築してしまいます。 祝祭日に問い合わせると、Hebcal はその祝祭日のハヴダラーを次の祭日のろうそく点灯より先に返します。そのため、期間の判定が決して true にならず、ワークフローがヨム・キプルに実行されてしまいます。各ろうそく点灯時刻を次のハヴダラーと組み合わせ、カレンダーを読み取れない場合はフェイルクローズにしてください。
• エージェントが Code ノードのシークレットを認証情報ストアに入れるようユーザーに指示してしまいます。 Code ノードには認証情報がありません。ランナーで $env のブロックを解除するか、前のノードからシークレットを渡してください。
• エージェントが決済 Webhook のリクエスト本文から直接請求書を発行してしまいます。 URL はパブリックで、イスラエルの決済ゲートウェイはいずれもペイロードに署名しません。まずサーバー側で取引情報を再取得してください。
• エージェントが書類タイプを 305／320 に固定してしまいます。 osek patur は、タックスインボイスを発行したり VAT を課したりできない場合があります。まず VAT のステータスを確認してください。
• エージェントが同意確認やオプトアウト手段なしに SMS または WhatsApp を一斉送信するワークフローを構築してしまいます。 תיקון 40 לחוק התקשורת により、損害の証明がなくてもメッセージ 1 件につき最大 1,000 NIS の法定損害賠償が課される可能性があります。
• 2026 年インボイス改革の基準額は、2026 年 6 月 1 日に引き下げられます。 基準額を超える請求書（5 月 31 日までは 10K NIS、6 月 1 日以降は 5K NIS）を API 経由で作成するには、割当番号が必要です。VAT 抜きの金額で判定するため、totalAmount ではなく Morning の amount と比較してください。ワークフロー変数にしてください。法令の表現は עולה על（超える）なので、>= ではなく > を使用してください。また、買い手が求めたかどうかを条件にしてはいけません。s.38(א1) により、いずれにせよ買い手の控除が認められないためです。
• エージェントが month=now を指定し、i=on を付けずに Hebcal の祝日ゲートを構築してしまいます。 month=now は HTTP 200 と空の items 配列を返すため、ゲートが作動しません。i=on を省略すると、ディアスポラ向けカレンダーが返されます（2026 年はイスラエルの 8 日に対し、ヨム・トーブが 13 日）。month=x&i=on を使用してください。
• エージェントがイスラエルの SMS ゲートウェイから返される HTTP ステータスを信用してしまいます。 019 は認証に失敗しても status: 3 を含む HTTP 200 を返します。ステータスコードではなく、本文のフィールドで分岐してください。
• エージェントが Webhook 1 件につき決済 1 件だと思い込んでしまいます。 3 つのゲートウェイはいずれも再試行します。書類を作成する前に TranzactionId／index／asmachta で重複を排除してください。そうしないと、再試行によって請求書が重複発行され、割当番号も 2 つ目が消費されます。
• n8n エディターのキーボードショートカットはヘブライ語配列で機能しません。 キャンバスは e.code ではなく e.key を読み取るため、Ctrl+C を押すと e.key = 'ב' になります。編集時は英語入力に切り替えてください。n8n issue #12569。
• n8n の式エディターは RTL に対応していません。 ヘブライ語は左から右に表示されます。長いヘブライ語のリテラルはワークフローの静的データに保存し、名前で参照してください。
• Error Trigger がないと、無人ワークフローはエラーを通知せずに停止します。 スケジュールされたスクレイピングがエラーをスローすると、そのまま停止します。アラートを送信する独立した Error Trigger ワークフローを追加してください。一時的な障害にはノードごとの Retry On Fail を有効にできますが、安息日ゲートでは絶対に有効にしないでください。再試行の結果、最終的に空のデータが返された場合、フェイルクローズにする必要があります。

同梱リソース

参考資料

• references/israeli-api-endpoints.md — イスラエルの API エンドポイントのリファレンス（Morning、data.gov.il、SMS ゲートウェイ、決済ゲートウェイ、Hebcal）。
• references/shabbat-cron-patterns.md — Hebcal と連携する、Shabbat に対応したスケジュール設定パターン集。
• references/webhook-auth-patterns.md — HMAC 署名の検証と JWT クレームの検証を行う Code ノードのスニペット。
• references/n8n-version-migration.md — CVE の全履歴、2.0 の破壊的変更一覧、3.0 で削除される項目の完全な一覧、イスラエルのホスティングオプション。
• references/n8n-workflow-authoring.md — プラットフォームの選択、ワークフロー JSON の構造、認証情報の設定、AI エージェントの詳細、詳しいトラブルシューティング。

トラブルシューティング

症状	原因	対処法
Morning API が 401 を返す	JWT の有効期限切れ（TTL は 60 分）	各実行の開始時にトークンを更新します。$getWorkflowStaticData('global') にタイムスタンプとともにキャッシュし、55 分を過ぎたら更新します
CSV エクスポートのヘブライ語が文字化けする	UTF-8 BOM がないため、Excel が ANSI として読み込む	Spreadsheet File のエンコーディングを UTF-8-BOM に設定します
Cardcom のコールバックが一度も届かない	URL がパブリックに到達できない、または IP が許可リストに登録されていない	有効な SSL を使用したパブリック HTTPS を設定し、WEBHOOK_URL をパブリックホストと一致させ、Cardcom ダッシュボードで n8n の IP を許可リストに登録します
Schedule Trigger が Shabbat 中に実行される	サーバーのタイムゾーンが UTC になっている、またはゲートで異なるキャンドル点灯時刻とハヴダラーの時刻を組み合わせている（Step 4 を参照）	GENERIC_TIMEZONE と TZ を設定し、Code ノードで new Date().toString() をログに出して確認します。ペアスキャンゲートを使用します
Code ノードで israeli-bank-scrapers が失敗する	require() がブロックされている、シークレットが未定義、または銀行ごとの認証情報キーが正しくない	タスクランナーで NODE_FUNCTION_ALLOW_EXTERNAL を設定し、使用可能なシークレットの設定方法を選び（Step 2）、SCRAPERS[companyId].loginFields を読み取ります
Cloudflare が Amex／Isracard のスクレイピングをブロックする	ヘッドレスブラウザーでボット検出が行われる	メンテナンスされている @sergienko4/israeli-bank-scrapers フォーク（Camoufox）を使用します

ランナーイメージの依存関係や Chromium に必要な最低メモリを含む、詳しい診断については references/n8n-workflow-authoring.md を参照してください。