Grok APIの文章透かし｜11月7日の対象と確認方法

01対象モデルと11月7日の予定を確認する

公式は2026年11月7日から既定で有効と案内しています。開始時刻・タイムゾーンは記載がありません。11月7日に確認した対象モデルは次の7つです。実際の切り替え状況は、利用中の環境で確認してください。

• grok-4.7
• grok-4.6
• grok-4.5
• grok-4.3
• grok-4.20-reasoning
• grok-4.20-non-reasoning
• grok-4.20-multi-agent

範囲はテキスト生成APIで、Responses／Chat Completions、通常文章・構造化出力・ツール引数、グローバル／地域別エンドポイントを含みます。ただし、すべてのモデルが各地域の接続先で利用できるわけではありません。米国向けの接続先では、公式案内上、利用できるのは現在grok-4.7とgrok-4.6です。利用できるモデルは地域別エンドポイントの公式案内で確認してください。

根拠：Grok API公式：Output Watermarking

まず、自社アプリや業務ツールが送っているモデル名を確認します。製品の紹介ページに「Grok対応」と書いてあるだけでは、どのモデルを使っているか分かりません。自分でコードを管理していなければ、開発担当者にこの一覧との照合を依頼しましょう。

この表は確認する担当と資料を決めるための本記事の整理です。一般読者の検索需要や、すべての利用者への影響を示す調査ではありません。

02応答ヘッダーで「その1回」の状態を確かめる

HTTPヘッダーは、応答本文とは別に付く情報です。公式の判定は、x-watermark: trueならその要求の出力が透かし付き、それ以外の値・ヘッダーなしなら透かしなしです。新しい要求パラメーターは不要です。

根拠：Grok API公式：Output Watermarking

文章の中に「watermark」と書かれているかを検索しても、応答ヘッダーの確認にはなりません。以下は、手元の記録を誤読しないための確認順です。

1. まず、既に保存している正常なAPI応答や開発環境の記録があるか確認します。新しい要求を送らずに確認できれば、追加の生成や費用を避けられます。
2. 対象の要求のモデル名と日時を照合し、本文だけでなく元のHTTP応答ヘッダーを見ます。SDKで本文しか取得していない場合は、公式ページの使用言語別の例を参照してください。
3. x-watermarkの値を、その要求に対応するものとして記録します。古い結果を使って、別の日時やモデルも同じ状態だとは判断しません。
4. 外部サービスや保存処理でヘッダーが省かれている場合は、取得前の応答を確認できるか担当者へ聞きます。「手元の保存ファイルにない」と「元の応答にない」は区別します。

たとえば、生成後の文章だけが社内文書に貼り付けられている場合、そこから元のHTTPヘッダーを読み取ることはできません。書き手に元の応答記録を確認してもらう作業と、文章を後から判定する作業を分けると、無駄な調査を減らせます。

注意APIキー、Authorizationヘッダー、顧客情報を含む本文を、ブログのコメントや公開リポジトリに貼らないでください。検証用に新たな要求を送る場合も、組織の許可された環境・予算と、秘密情報を含まない入力を使います。

03設定変更はチーム管理者と影響範囲を確認する

公式では、管理者がConsoleでモデル別に設定し、チームの全APIキーへ適用します。変更は新規要求へ5分以内に反映され、監査ログに残ります。ロックされたモデルはConsoleで無効化できません。無効化には法の例外該当と表示等の責任に関する確認が必要です。

根拠：Grok API公式：Output Watermarking

変更を検討する場合は、最初に「誰の、どのシステムまで変わるか」を整理しましょう。自分の試作だけのつもりでも、同じチームのモデル設定を複数の製品が使っていれば、ほかの運用にも関わります。

監査ログの閲覧方法は、別の公式Security FAQでも確認できます。管理者はイベントID・説明・ユーザーで検索し、期間を絞れます。問い合わせるときは、発生日時と変更を行った担当者が分かると照合しやすくなります。

根拠：Grok API公式：Security FAQ・監査ログ

注意「無効化できるから、組織として無効化してよい」とは限りません。この記事は適用法や契約上の義務を判断するものではありません。設定欄が見えない場合も、個人で別チームや別キーを作って回避せず、管理者に確認してください。

04後からの文章判定と、運用の記録を分ける

公式の透かしはトークン選択の調整で、文字や隠しテキストを追加しません。後からの検出APIは申請制の統計判定で、結果には「不確実」もあります。公式は文章が長いほど検出の手掛かりが強くなると説明していますが、長文なら確実に判定できるという保証ではありません。ヘッダー確認とは別です。

根拠：Grok API公式：Output Watermarking

文章を読む人が、見た目だけで確定できる印を探す記事ではありません。また、透かしを確認できても、その文章の内容が正しいこと、第三者の権利を侵害していないこと、公開に必要な承認がそろったことまで分かるわけではありません。

たとえば外部から納品された記事で出所が気になる場合は、まず作成者の説明、素材の出典、編集の記録を確認する方法があります。検出結果だけを根拠に、不正利用や虚偽申告だと決めつけないようにしましょう。

チームで残す確認メモ

次のひな形は本記事の提案です。「確認できた事実」と「担当者へ聞くこと」を分けて記録できます。実際の秘密情報や応答本文は入れず、必要ならアクセスを限定した社内記録の場所を控えます。

確認日時・タイムゾーン：
対象システム・担当者：
利用中のモデル名：
APIの種類・接続経路：
元の応答ヘッダーを確認できたか：
x-watermarkの値：
その要求の記録の保管場所：
チーム設定を確認した担当者・日時：
変更を希望する理由と影響する利用先：
未確認事項・次に確認する担当者：
※APIキー、認証情報、応答本文、個人情報は記入しません。

処理の前後で文章を編集しているなら、その事実も別途記録します。編集後の文章を元の応答そのものとして説明しないことが、問い合わせや後日の見直しに役立ちます。

05よくある質問