貿易取引における「保証状(Guarantee)」は、契約履行や支払の裏付けを担保する重要な役割を持っています。実務では、当初発行された保証状の条件を変更する必要が生じるケースも少なくありません。例えば、納期の延長、金額の調整、条件文言の修正などです。
その際に用いられるのが、SWIFTメッセージ MT770(Advice of Charges, Interest and Other Adjustments / 修正依頼) と MT771(Request for Payment of Charges, Interest and Other Expenses / 修正回答) です。
これらMT770とMT771はペアで運用され、発行銀行と受益者側の銀行の間で条件変更の意思疎通を行うために利用されます。まるで「契約の修正申請書と、その承認通知書」のような関係だと考えると理解しやすいでしょう。
SWIFTの公式メッセージカタログ(Message Types, Standards Release Guide)には、MT770(Guarantee Amendment Request)とMT771(Guarantee Amendment Response) は定義されています。ただし、利用頻度は低く、すべての銀行が対応しているわけではありません。実務上は、MT767(Amendment to a Guarantee) に一本化して処理されるケースが多く、結果的にMT770/771が使われず、参考資料や研修資料からも外される傾向があります。
SWIFT MT770とは(Guarantee Amendment Request)
MT770は、保証状に対する修正リクエストを送信するためのメッセージです。依頼者(Applicant)または発行銀行の立場から、受益者側の銀行に対して修正案を伝えます。
- 例:納期を90日から120日に変更したい、保証金額を増額したい、条文の一部を削除したいなど。
- このメッセージを通じて、修正の意図を正式に伝えることで、曖昧な交渉を避け、書面ベースでの明確な証跡を残せます。
例:建築契約で「工期を3か月延ばしたい」と施主が申し出るのに似ています。その要望を文書化して提出するのがMT770です。
SWIFT MT771とは(Guarantee Amendment Response)
MT771は、MT770で送られた修正依頼に対する回答を送信するメッセージです。受益者側の銀行は、修正に「同意」するか「拒否」するかを明確に示します。
- 承認されれば、保証状は新しい条件に基づいて効力を持ちます。
- 拒否された場合は、元の条件が維持されます。
例:先ほどの工期延長の申請に対して、施工会社が「承認する」または「認められない」と返事を出すのがMT771です。
MT770・MT771の対象となる保証状の種類

1. LC(Letter of Credit / 信用状)との関係
LC自体(輸入信用状など)は、SWIFT MT7xxシリーズでも別メッセージ(MT700〜709など) が使われます。MT770/771は通常の「ドキュメンタリーLC(輸入信用状)」の修正には直接使われません。LC修正には MT707(Amendment to Documentary Credit) が一般的に使われます。
2. DLC(Documentary Letter of Credit / 書類信用状)
DLC=基本的には「通常のLC」と同じ概念です。よって、DLCの修正もMT770/771ではなく MT707 を使用します。
3. SBLC(Standby Letter of Credit / スタンバイ信用状)や保証状(Guarantee)
ここでMT770・MT771が登場 します。SBLCやBank Guaranteeは「保証状(Guarantee)」の一種として扱われ、これらの修正依頼・回答に MT770(修正依頼) と MT771(修正回答) が用いられます。特に SBLCは保証状的な性格 を持つため、MT770・771の適用範囲に含まれます。
MT770・MT771の対象は
- LC/DLCの修正 → MT707(信用状専用の修正メッセージ)
例:輸入信用状の有効期限を延長 → MT707 - SBLCや保証状(Bank Guarantee)の修正 → MT770 / MT771
例:履行保証の金額を増額 → MT770/771
つまり、MT770・MT771は 保証系(SBLC・Bank Guarantee) に適用され、貿易信用状(LC/DLC)の修正には使われない という整理になります。
MT770とMT771のやり取りメッセージの流れ
保証状の修正は、銀行間通信を通じて段階的に進められます。以下は、典型的なプロセスの詳細です。
01. 修正依頼の発行(MT770送信)
発行銀行(Issuing Bank)が、保証状の修正を必要とする理由(納期延長、金額変更、条文の修正など)を確認し、依頼人の意向に基づいて MT770(修正依頼) を作成。この時点では「修正希望」の段階であり、効力はまだ生じていません。
例:契約工事の施主が「工期をあと1か月延ばしてほしい」と正式な依頼書を提出する段階に相当します。
02. 受益者銀行での受領と確認
MT770を受け取った受益者銀行(Beneficiary’s Bank)は、まずメッセージの形式や参照番号(Original Guarantee Reference)を確認。その後、保証状の受益者(Beneficiary=契約相手)に修正依頼の内容を伝達します。この段階では、まだ「銀行経由で顧客に回覧された」だけで、承認・拒否は未決定。
03. 受益者の判断
受益者(Beneficiary)が修正内容を精査し、自身に不利益がないかを判断。必要であれば、顧問弁護士や社内の契約管理部門と相談し、承認または拒否の方針を決定します。
例:施工会社が「工期延長を認めても良いか、追加コストを請求すべきか」を社内で検討するイメージです。
04. 修正回答の作成(MT771送信)
受益者の意思に基づき、受益者銀行が MT771(修正回答) を発行銀行へ送信。この回答には、「承認する(Accepted)」または「拒否する(Rejected)」の意志が明記されます。一部ケースでは、補足条件を付けて「条件付き承認」の形を取ることもあります。
例:施工会社が「工期延長は認めるが、追加費用を負担してほしい」と回答書を返送するようなイメージです。
05. 保証状修正の効力発生
MT771が「承認」として戻ってきた場合、修正は正式に効力を持ち、保証状が更新されます。一方で「拒否」とされた場合は、元の保証状の条件がそのまま維持され、修正は成立しません。この一連のやり取りは、すべてSWIFTネットワーク上で行われ、法的証拠性を伴う公式な記録として残ります。
全体イメージ
MT770=「修正申請書」
MT771=「審査結果通知」
つまり、MT770とMT771の流れは「申請者が希望を提出 → 審査機関が内容を精査 → 承認または却下を通知 → 契約が修正される」という行政手続や建設工事契約修正と極めて似ています。
SWIFT MT770とMT771のサンプル
MT770サンプル(修正依頼)
{1:F01XXXXJPJTAXXX0000000000}{2:O770YYYYGB2LXXXX0000000000}{4:
:20:REF20250901ABC123
:21:ORIGINAL-GUARANTEE-REF001
:23:AMENDMENT REQUEST
:30:20250901
:72:/CHANGE REQUEST/ 有効期限を2025年12月31日まで延長希望
-}
MT771サンプル(修正回答)
{1:F01YYYYGB2LXXXX0000000000}{2:O771XXXXJPJTAXXX0000000000}{4:
:20:REF20250901ABC123
:21:ORIGINAL-GUARANTEE-REF001
:23:AMENDMENT RESPONSE
:30:20250902
:72:/RESPONSE/ 延長を承認する
-}
サンプルの解説
- :20:REF20250901ABC123
送信側で付与するユニークな参照番号。銀行内での検索やトレーサビリティに必須。 - :21:ORIGINAL-GUARANTEE-REF001
元の保証状の参照番号。どの保証状に対して修正が依頼されているのかを特定する。 - :23:AMENDMENT REQUEST / RESPONSE
MT770では「修正依頼」、MT771では「修正回答」であることを明示。メッセージの性格を一目で判断できる。 - :30:20250901 / 20250902
メッセージ作成日。依頼と回答の日付を比較することで、処理に要した日数も確認可能。 - :72:/CHANGE REQUEST/
自由記述欄。依頼内容や回答の具体的条件を記載する。今回の例では「期限を2025年12月31日まで延長希望」と「延長を承認する」。
このように、各フィールドには取引の透明性と追跡性を担保するための情報が明確に盛り込まれています。実務上はこれに加え、保証金額や適用条項の修正が記載される場合もあります。
SWIFT MT770とMT771のメリット・デメリット・留意点
メリット
MT770・MT771を利用することで、保証状の修正は単なる口頭合意ではなく、公式な銀行通信として処理されます。これにより、実務上での信頼性が大きく高まります。
- 修正が正式に記録され、後の紛争時に証拠として利用できる
- 修正の合意形成が迅速に進みやすい
- SWIFTネットワーク経由のため、改ざんリスクが低く信頼性が高い
メリットの本質は「透明性」と「証拠性」です。取引当事者の間で修正の痕跡を残すことにより、後日の誤解やトラブルを最小限に抑えることができます。
デメリット
一方で、保証状の修正プロセスには、実務上の制約やリスクも存在します。すべての依頼が承認されるとは限らず、場合によっては交渉が難航する可能性があります。
- 受益者側が拒否すれば修正は成立せず、取引の停滞リスクがある
- 承認までに数日を要することがあり、緊急性には対応しづらい
- 修正に伴い、追加保証料や銀行手数料が発生する可能性がある
デメリットを理解した上で、修正依頼を行う際には「どの程度の時間とコストが追加で発生するか」を事前に見積もり、契約スケジュールに反映させることが重要です。
留意点
メリット・デメリットを踏まえた上で、実際にMT770とMT771を利用する際に特に注意すべき実務上のポイントがあります。これを怠ると、修正自体が無効になったり、余計なトラブルを招く恐れがあります。
- 修正内容は必ず依頼人・受益者双方で事前合意を形成してから送信する
- 曖昧な表現や不完全な記載は、後の拒否や紛争の原因となる
- 承認が得られるまでは元の保証状が有効であることを忘れない
留意点を守ることは、単なる形式遵守ではなく、国際取引全体の信頼性を維持するための基本です。書き方や手続きの一つひとつが、結果的にビジネス全体の安全性を支えることになります。
SWIFT MT770とMT771のまとめ

MT770(Guarantee Amendment Request)
保証状の修正を依頼するメッセージ。発行銀行が送信し、納期延長・金額修正・条文変更などの希望を正式に伝える役割を持つ。
MT771(Guarantee Amendment Response)
MT770に対する回答を行うメッセージ。受益者銀行が送信し、「承認」「拒否」「条件付き承認」のいずれかを明示する。
MT770とMT771の比較表
項目 | MT770 | MT771 |
---|---|---|
名称 | Guarantee Amendment Request(保証状修正依頼) | Guarantee Amendment Response(保証状修正回答) |
役割 | 保証状の修正を依頼する | 修正依頼に対して承認・拒否を回答する |
送信主体 | 発行銀行(Issuing Bank) | 受益者銀行(Beneficiary’s Bank) |
主な内容 | 納期延長、金額変更、契約条項の修正など | 承認、拒否、条件付き承認 |
効力 | 単なる「申請」であり、この時点では効力なし | 「承認」が通知されて初めて修正が有効化 |
比喩 | 「修正申請書」に相当 | 「審査結果通知」に相当 |
実務ポイント | 明確で具体的な修正依頼を記載する必要がある | 回答は法的証拠性を持ち、曖昧さは許されない |
実務上の流れ
① 発行銀行が修正依頼(MT770)を送信
② 受益者銀行が受領し、顧客に確認
③ 受益者が判断し、回答(MT771)を送信
④ 承認されれば保証状が修正され、拒否されれば元の条件を維持
重要ポイント
MT770は「申請書」、MT771は「回答通知」と捉えると理解しやすくなります。また修正は受益者側の承認が得られるまで効力を持たないことを忘れないでください。これらの記録はSWIFTネットワークに残るため、透明性と証拠性が担保されることとなります。
MT770とMT771は、保証状を柔軟に運用するための「修正の申請と回答」のペアです。申請側と受領側の合意を銀行通信で正式に残すことで、国際取引における信頼性と安全性を高めています。