2026.10.13 AI

textGrainとは？OpenAIのテキスト電子透かしの仕組み・API設定手順と検出の限界【2026年10月】

textGrainは、OpenAIが2026年10月5日に発表したテキスト向けの電子透かし技術です。モデルが次の単語を選ぶときの乱数を秘密鍵で少しだけ偏らせ、文章全体に統計的な模様を残します。EU域内のChatGPTとCodexには数週間かけて自動で付与され、APIでは世界中の利用者が設定画面からオプトインで有効にできます。この記事ではOpenAIの公式発表と技術報告書をもとに、透かしの埋め込みと検出の仕組み、APIで有効にする手順、検出率が落ちる条件を、しきい値を計算するコード例つきで整理しました。

まとめ：textGrainの要点とAPIで透かしを有効にする前に決めること

textGrainは、文字を足すのではなく単語の選び方そのものに信号を埋め込む方式です。隠し文字やゼロ幅スペースは入らず、読者には見えません。APIでは既定オフで、組織設定かプロジェクト設定で「Allow text watermarking」をオンにし、対象モデルを選ぶだけで付与されます。リクエストのパラメータを変える必要はありません。

注意すべきは検出の側です。検出器は一般公開されず、審査を通った研究者と専門機関に限って提供されます。透かしを有効にしても、自社で判定できるようにはなりません。検出率は文長と編集に強く左右され、400トークンの文で単語の25%を同義語に置き換えると17%まで下がります。

結論として、EU向けにOpenAIのモデルで長文を生成して提供する事業者は、AI Act第50条への対応手段としてAPIの透かしを有効にする価値があります。一方、社内でAI生成文を見分けたい、学生のレポートを判定したいといった目的には使えません。その用途で導入を検討しているなら見送ってください。

textGrainの仕組みを鍵付き乱数とトークン選択の関係から理解する

textGrainの詳細は、ペンシルベニア大学・イェール大学とOpenAIの研究者による技術報告書「textGrain: Entropy-Calibrated Watermarking for Language Model Text」（20ページ）で公開されています。報告書は今後数週間で追記される予定で、以下は2026年10月5日版の内容です。

次トークンの確率を秘密鍵で組み替えて透かしを埋め込む処理の流れ

言語モデルは1トークンごとに「次に来る候補とその確率」を計算し、そこから乱数で1つを選びます。textGrainが手を入れる対象は、このトークン選択に使う乱数の部分です。OpenAIのヘルプ記事の説明では、元の確率から秘密鍵に応じて偏らせた分布を複数作り、それらを平均すると元の確率に一致するよう釣り合わせます。鍵がどの分布を使うかを決め、モデルはその分布から改めてランダムに選びます。

報告書の言葉でいえば、鍵と直前のトークン列（文脈窓）から語彙を複数のブロックに分け、各ブロックと鍵由来のガンベル乱数の組み合わせを、KL正則化つきの輸送問題（optimal transport）で結び付けます。ブロックが決まったあとは、ブロック内のトークンを元の相対確率のまま選びます。

ここで調整するのが「エントロピー予算」です。透かしの強さは、生成のランダムさをどれだけ削るかと表裏一体で、報告書は削る量を元のエントロピーの割合βで上限管理します。強くすれば検出しやすくなる一方で、同じプロンプトへの応答の多様性は下がる関係です。OpenAIがSynthIDなど既存方式でなく自社方式を作った理由も、この釣り合いを細かく制御したかったためと説明されています。

検出器が鍵と文脈窓から得点を再構成してガンマ分布で判定する手順

検出側は、生成時と同じトークナイザー・ブロック数・文脈窓の規則・鍵を使います。文章を1トークンずつ見て、鍵と直前の文脈窓からブロック分けとコスト表を再現し、実際に出たトークンがどれだけ「選ばれやすい側」にいたかを得点にします。

報告書では、各位置の得点をY_t＝−log(1−F_G(Z_t))とし、その合計S_nを検定統計量にします。透かしの無い文なら各Y_tは平均1の指数分布に従い、合計はガンマ分布Gamma(n, 1)になります。S_nがこの分布の上側α点を超えたら「透かしあり」と判定する仕組みです。同じ文脈窓が繰り返し現れた位置は、最初の1回だけ数えます。

実装上の利点は、検出に生成したモデルもエントロピー予算も要らない点です。必要なのは文章と秘密鍵だけです。逆にいえば、鍵を持つOpenAIか、検出器へのアクセスを許可された組織しか判定できません。

隠し文字やゼロ幅スペースを入れないため見た目もコピー後も変わらない理由

過去の「AI文の透かし」と呼ばれた手法には、ゼロ幅スペースなど見えない文字を挟むものがありました。この種の方式は文字列の正規化で簡単に消えます。textGrainは単語の選び方の統計に信号を持たせるため、ヘルプ記事は「隠し文字、透かし専用のトークン、目に見える変化を加えない」と明記しています。

実装者にとっての帰結は2つです。1つは、受け取った文字列をUnicode正規化しても透かしは消えない点。もう1つは、自社側で文字列を検査しても透かしの有無は分からない点です。透かしが入ったかどうかをログから確かめる手段は、現時点で提供されていません。

ChatGPTとCodexとAPIで透かしが付く範囲を2026年10月時点で整理する

付与範囲は、製品と地域で扱いが分かれます。OpenAI Developer Communityの公式告知でも、APIは既定オフのまま、全世界の既定にはしないと書かれています。

EU域内のChatGPTとCodexへ数週間かけて全プランに自動付与される対象

EU域内では、対象となるChatGPTとCodexのテキスト出力に、全プランで透かしが付与されます。公式発表の時点（2026年10月5日）では「今後数週間で」とされ、段階的な展開です。EU域外のChatGPTには付与されません。地域を絞った理由について、OpenAIは実利用からの学びを得る余地を残すためと説明しています。

Codexも対象に入りますが、後述のとおりコードは透かしが効きにくい領域です。Codexの説明文やコミットメッセージのような自然文には付き、コード本体では検出が難しいと捉えておくのが実務的です。Codexの機能と料金はCodexの使い方・料金・モデルを解説した記事で整理しています。

APIは既定オフで組織設定かプロジェクト設定からオプトインする仕組み

APIは2026年10月5日から全世界でオプトインできます。対象は「一部のモデル」で、利用できるモデルの一覧は設定画面に表示されます。ヘルプ記事によれば、旧来のモデルにも今後数週間で対象を広げる予定です。画像のgpt-image-1やsora-2のように提供終了が近いモデルは、来歴信号の対象外とされています。

クラウド経由の利用も視野に入っています。公式発表は、クラウドパートナー経由で使うOpenAIモデルの出力にも数週間で透かしを提供できるよう調整中と書いています。Azureなど他社クラウドで呼んでいる場合は、提供側の告知を待つ段階です。

画像と音声のC2PA・SynthIDとテキストのtextGrainで異なる検証手段

OpenAIは画像・音声とテキストで来歴信号の仕組みと検証の公開範囲を分けています。Content provenanceガイドの記載をまとめると次のとおりです。

対象	来歴信号	検証の公開範囲
画像	C2PA＋SynthID	検証サイト・APIで誰でも
音声	SynthID	同上（復号後60秒以下・50MiB以下）
テキスト	textGrain	審査を通った研究機関・学術機関のみ

表中のC2PAはContent Credentialsを指し、公開の検証先はopenai.com/verifyとContent Provenance APIです。画像と音声は、次のようにAPIへファイルを送るだけで判定できます。テキストにはこの公開エンドポイントが使えない点が、textGrainの運用で最も誤解されやすいところです。

curl https://api.openai.com/v1/content_provenance_checks \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -F "file=@./example.png;type=image/png"

結果がnot_detectedでも、OpenAI製でないとは言い切れません。メタデータの削除や加工、旧モデルでの生成でも同じ結果になります。

APIでテキスト透かしを有効にする設定手順と出力を確認するコード

APIの透かしはリクエスト単位でなく、組織またはプロジェクト単位の設定で決まります。コードを書き換えずに有効化できる反面、どのリクエストに透かしが入ったかはコードから見えません。

透かしを組織全体かプロジェクト単位で有効にするかを出力先で判断する

ヘルプ記事に記載された設定の場所は次の2つです。どちらも「Allow text watermarking」をオンにし、対象モデルを選んでSaveします。

組織全体に掛ける場合：Organization settings → Data controls → Text provenance
特定のプロジェクトだけに掛ける場合：Project Settings → Text provenance
どちらの場合も、透かしを付けたいモデルにチェックを入れてSaveする

判断の目安は、EU向けの出力と、それ以外の出力が同じ組織に混在しているかどうかです。EUの利用者に生成文を届けるサービスだけをプロジェクトに分け、そのプロジェクトで有効にするのが扱いやすい構成です。組織全体で有効にすると、社内向けの要約バッチなど透かしが不要な処理まで対象に入ります。プロジェクトごとにAPIキーを分けておけば、どの処理に透かしが入っているかをキー単位で説明できます。

出力トークン数を記録して200トークン未満の応答を見分けるPythonコード

透かしの有無はレスポンスに表れません。そこで実務では、検出が成り立つ長さかどうかを出力トークン数で記録しておくと、後から監査や問い合わせに答えやすくなります。次の例はResponses APIで生成し、usage.output_tokensが200未満の応答に印を付けます。モデル名は設定画面で透かし対象に選んだものを環境変数で渡してください。

import os, json
from openai import OpenAI

client = OpenAI()
MODEL = os.environ["OPENAI_MODEL"]  # Text provenanceで選んだモデル

resp = client.responses.create(
    model=MODEL,
    input="EU向け製品マニュアルの概要を400語程度で書いてください。",
)
tokens = resp.usage.output_tokens
record = {
    "response_id": resp.id,
    "model": resp.model,
    "output_tokens": tokens,
    # 200トークン未満は行動規範で透かし不要・検出も不安定
    "watermark_reliable": tokens >= 200,
}
print(json.dumps(record, ensure_ascii=False))

このログは「透かしが入った証拠」ではありません。設定で有効にしたプロジェクトのキーで生成したこと、検出が成り立つ長さだったことの2点を、自社側で説明できるようにするための記録です。SDKの導入と認証はOpenAI Python SDKの使い方で手順を追えます。

検出率が落ちる条件を文長・言い換え・言語・コードの4軸で検証する

公式発表は、理想条件での高い性能が日常の利用での確実な検出を保証しないと明言しています。数字はすべて偽陽性率1%の条件でOpenAIが公表した値です。

200トークンで約80%・400トークンで約95%という文長と検出率の関係

公式発表の評価では、心理学のような自由度の高い内容で、200トークンの文の約80%、400トークンの文の約95%から透かしを検出できました。数学のように言い回しの選択肢が少ない内容では、検出率が大きく下がります。

ヘルプ記事は、事実だけを答える文や、渡した文章をそのまま再現させる処理でも、言い換えの余地が少なく検出されにくいと書いています。定型の回答文や、原文を整形するだけの処理には透かしが乗りにくい、と考えて設計してください。

偽陽性率1%のしきい値を文長ごとに計算して短文が不利な理由を確かめる

短文が不利な理由は、報告書の検定式から確かめられます。透かしの無い文ではS_nがGamma(n, 1)に従うので、偽陽性率1%のしきい値を文長nごとに計算できます。次のコードの実行に必要なのは、Pythonの標準ライブラリだけです。

import math

def tail(n, x):
    # Gamma(n,1)の上側確率 P(S_n > x)（nは整数）を対数で計算
    logs = [-x + k * math.log(x) - math.lgamma(k + 1) for k in range(n)]
    m = max(logs)
    return math.exp(m) * sum(math.exp(v - m) for v in logs)

def threshold(n, alpha=0.01):
    lo, hi = 1e-9, n + 20 * math.sqrt(n) + 50
    for _ in range(100):
        mid = (lo + hi) / 2
        lo, hi = (mid, hi) if tail(n, mid) > alpha else (lo, mid)
    return hi

for n in (50, 100, 200, 400, 800):
    th = threshold(n)
    print(f"n={n:4d}  しきい値={th:7.1f}  1トークンあたり={th / n:.3f}")

実行すると、1トークンあたりに必要な平均得点はn＝50で1.358、200で1.172、400で1.120、800で1.084となります。透かしの無い文の平均は1.0なので、短い文ほど各トークンで大きく偏らないと判定を超えられません。200トークン付近で検出率が8割に留まるのは、この構造によります。なお得点を数えるのは文脈窓が初出の位置だけなので、同じ言い回しが繰り返される文では実効的なnがさらに減ります。

単語の10%を同義語に置き換えると92%から66%へ落ちる言い換え耐性

400トークンの英文で、単語の10%を同義語に置き換えると検出率は約92%から66%に、25%を置き換えると17%に下がりました。置き換えた単語の位置だけでなく、その単語を文脈窓に含む後続の位置でも得点が崩れるためです。

ヘルプ記事は、軽い編集やコピー＆ペーストには耐える一方、大幅な言い換えや翻訳では検出できなくなる場合があると書いています。別のモデルで書き直された文は、透かしの対象から実質的に外れると考えてください。

EU公用語24言語でスペイン語69.0%・ルーマニア語42.2%と開く言語差

ヘルプ記事では、英語の500プロンプトを他の23言語に翻訳し、EU公用語24言語で検出率を比べています。偽陽性率1%で、最も高いスペイン語が69.0%、最も低いルーマニア語が42.2%でした。OpenAIは強さを調整する「つまみ」を持っており、60%を下回った言語では強度を上げて改善したとしています。日本語はEU公用語に含まれず、この評価の対象外です。

コードはさらに不利です。次に来る記述の選択肢が自然文より少ないためで、ヘルプ記事は、行動規範が200トークン（英語で約150語）未満の出力とコード片には透かしを求めていないと説明しています。

EU AI Act第50条対応でtextGrainを採用する条件と見送る場面

ここからは、技術の性質を踏まえた採否の判断です。制度の全体像はEU AI Actのリスク分類と日本企業の対応を解説した記事で扱っているので、本章は第50条の技術対応に絞ります。

第50条の機械可読なマーキング義務と2026年6月確定の行動規範の関係

AI Act第50条は、生成AIの提供者に、出力をAIによる生成と機械可読な形で識別できるようにすることを求めています。欧州委員会の行動規範ページによれば、この透明性義務は2026年8月2日から適用され、自主的な行動規範の最終版は2026年6月10日に公表されました。行動規範は、提供者向けのマーキングと検出（セクション1）と、導入者向けのディープフェイク等のラベル表示（セクション2）の2部構成です。

OpenAIはこの行動規範に署名した提供者の1社で、textGrainはそのセクション1に沿った対応です。ヘルプ記事は、第三者のAI判定ツールのように生成後の文章を分類器で推定する方式では、生成文に信号を埋め込むという法の要件を満たせないと書いています。

EU向けに生成文を届ける事業者がAPIで透かしを有効にすべき条件

次の3つが揃うなら、透かしを有効にしてください。EUの利用者に生成文をそのまま届けている。出力の多くが200トークンを超える自然文である。OpenAIのモデルを直接のAPIで呼んでいる。この条件では追加の実装なしに義務への対応を補強でき、コストもほぼ掛かりません。

品質と速度への影響は小さいと公表されています。公式発表の評価では、最新モデルAstraのベンチマークで、透かしの有無による差は計測のぶれの範囲でした。例としてGPQA Diamondは94.44%と93.94%、Terminal-Bench 4.0は53.90%と56.06%です。速度への影響もごくわずかとされています。

ただし、透かしだけで第50条の対応が完結するとは考えないでください。ディープフェイクや公共性の高い文章の表示義務は導入者側にも掛かり、画面上のラベル表示など、透かしの付与とは別の対応が必要です。EU・米国・日本の規制の違いはAI規制の国別比較にまとめています。生成AIを組み込んだサービスで、モデル選定から出力の記録設計まで含めて相談したい場合は、生成AI開発・AI受託開発で要件整理からお手伝いしています。

社内文書の判定や学生レポートの確認に使えないため見送るべき場面

「ChatGPTで書いた文を見分けたい」目的なら、textGrainは使えません。検出器は一般公開されず、許可されるのはテキストの来歴や検出の信頼性を研究する学術・研究機関などです。採点や人事評価のために申請しても、対象外になると考えるのが妥当です。

仮に判定できても、結論に使える情報は限られます。公式発表は、透かしが示せないものとして、人の寄与の程度、所有権や責任の所在、利用者の特定、内容の正確さを挙げています。透かしが検出されないことも、人が書いた証明にはなりません。短すぎる文、編集や翻訳を経た文、他社モデルの文はどれも「検出なし」になります。この性質を知らずに判定結果で人を評価すると、誤った結論を出すことになります。

EU域外の利用者だけに提供している場合や、生成文が短い定型応答とコード中心の場合も、現時点で有効にする意味は小さいです。設定は後からでも変えられるので、EU向け提供を始める時点で見直せば足ります。

textGrainの導入条件・料金・検出の制約についてよくある質問

textGrainの導入や判定について、実装者から出やすい質問に答えます。

textGrainの透かしはChatGPTの日本語の回答にも入りますか？

EU域外のChatGPTには付与されないため、日本から使う通常のChatGPTの回答には入りません。対象はEU域内で生成された対象テキストです。APIで日本語を生成する場合は、設定で有効にしたプロジェクト・モデルであれば付与されます。ただし公表された言語別の評価はEU公用語24言語が対象で、日本語の検出率は公表されていません。