メインコンテンツへスキップ
AI News 39分で読める

Claudeの電子透かし全解説|校正に使っただけでも付く仕組みと限界

研究費の申請書をClaudeで推敲している人が、Hacker Newsに使い方を書き込んでいた。自分でざっと段落を書き、校正用のスキルを呼び出して明確さのために直してもらい、意図どおりか読み返して確認する。そのうえで、こう続けている。

明確さのためにAIを使ったという表示が付くのは構わない。だがAIに丸投げしたと責められるのは嫌だ。相当な労力を注いでいるのに、悪く言われたくない

(出典: Hacker News SubiculumCode氏、2026年8月14日。筆者訳)

2026年8月2日以降に提供が始まったClaudeモデルは、公開時点から目に見えない透かしに対応する。EU AI法(EU AI Act)第50条への対応だが、Anthropicは適用範囲をEU圏内に限らず全世界としている。日本から使っていても無関係ではない。

ひとつ断っておくと、8月20日時点でAnthropicは「どのモデルが実際にマーク済みか」を名指ししていない。以下は公表された仕様と、それに対する開発者の反応の整理だ。

そして、この人が心配しているとおりのことが起きうる。校正に使っただけでも、条件が揃えば透かしは付く。

この記事はこんな人におすすめ
  • Claudeで記事・ドキュメント・提案書を書いている、または校正に使っているフリーランス・会社員の方
  • Claude Codeで生成したコードに何か埋め込まれるのか気になっている開発者
  • AI生成コンテンツの検出がSEOにどう効くのか判断したいブログ運営者・マーケター
  • クライアントから「AIを使っていないこと」を求められる立場の方
結論(忙しい人向け)
  • 適用範囲: 全世界。2026年8月2日以降に提供開始されたClaudeモデルは公開時点から対応。旧モデルも順次適用中
  • 対象製品: Claudeアプリ、Claude Code、Cowork、Claude Tag、開発者向けAPI、AWS・Google Cloud・Microsoft Foundry経由の利用
  • 仕組み: Google DeepMindのSynthID-Textを基にした方式。隠し文字は使わない。単語選択の乱数の出どころを秘密鍵で差し替える
  • 遡及なし: 8月2日より前に生成済みのテキストに、後から透かしが付くことはない
  • 消える条件: 別のモデルや人間による全面書き換えで消えるとされる。軽い編集では残る場合がある。短い文章では最初から検出が効かない
  • コード: 適用は一般に少ない。コメントには付く場合がある
  • 検出手段: 8月20日時点で、個人が自分の文章を確認する公式の手段は存在しない

なぜ全世界に適用されるのか|EU AI法第50条の中身

透かし導入の直接の引き金は、2026年8月2日に適用が始まったEU AI法第50条の透明性規定だ。条文はこう定めている。

合成された音声・画像・映像・テキストのコンテンツを生成するAIシステムの提供者は、そのシステムの出力が機械可読な形式でマークされ、人工的に生成または操作されたものとして検出可能であることを確保しなければならない

(出典: EU AI Act 第50条(2)。原文はEUR-Lex掲載の Regulation (EU) 2024/1689 を参照。訳は筆者による仮訳であり、法的な正文ではない)

Anthropicは第50条(2)に紐づく実践規範(Code of Practice)に、生成AIモデルの提供者としても、生成AIシステムの提供者としても署名した。この実践規範は2026年6月にAI Officeのもとで策定され、7月8日・9日に欧州委員会とAI Boardが第50条の実装手段として適切と判断している。欧州委員会が7月31日に公表した時点で、署名者は全世界で約190者にのぼる(Section 1「提供者」82者、Section 2「導入者」152者)。報道によれば、AnthropicのほかにOpenAI、Google、Meta、Microsoft、Mistralも署名者に名を連ねている(出典: The Next Web 2026年8月12日、InfoQ 2026年8月)。

ここで多くの人が引っかかるのが「なぜ日本のユーザーにも適用されるのか」だ。答えは単純で、モデル側に組み込むからだ。Anthropicのヘルプセンターは、透かしはモデルレベルで適用される、つまりどのClaude製品・どの経路から出てきたテキストであっても存在する、と書いている。地域ごとに出し分ける設計にはなっていない。

EU AI法そのものの適用範囲や、開発者側に求められる対応についてはEU AI法 8月2日施行で何が変わるかの開発者向けガイドに整理してある。透かしは、そこで解説した義務のうち出力側に効いてくる部分だ。

Claudeの電子透かしの仕組み|隠し文字ではなく「単語の選び方」

最初に誤解を潰しておく。ゼロ幅スペースのような不可視文字を混ぜる方式ではない。

Anthropicの技術解説によれば、採用されたのはGoogle DeepMindが2024年にNature誌で発表したSynthID-Textの手法だ。仕組みの核はこうなっている。

LLMは次の単語を選ぶとき、確率分布からサンプリングする。そのサンプリングに使う乱数の出どころを、秘密鍵と直前の数単語から導いた値に差し替える。確率分布そのものは変えない。だから理屈のうえでは出力の質が落ちない。ただし「どちらを選んでも同じくらい自然」な場面での選択が、鍵を知っている側から見ると予測可能なパターンを描く。

日本語での解説では、自然言語処理を専攻していたKaito Sugimoto氏(hellorusk)の記事が読みやすい。同氏は「乱数の出どころをすり替えるだけなので、定義上、品質は1ミリも劣化しません」と書いている。同記事によれば、修士課程を終えた2023年時点では実用化は無理だろうと考えていたが、3年で商用LLMに載ったことに驚いた、とのことだ(出典: Zenn「Claude がテキストに電子透かしを入れ始めたので、LLM ウォーターマーキングの仕組みを調べた」 Kaito Sugimoto氏、2026年8月)。ただしこれは確率分布を変えない非歪曲型の実装を前提とした説明で、実装方式によっては性質が異なる。

品質への影響については、SynthID-Textの原論文に検証結果がある。Google DeepMindがGeminiのトラフィックの一部に透かし付きモデルを流し、高評価・低評価の比率を比較したところ、統計的に有意な差は出なかったと報告されている。人手による並列比較でも差は認められなかったという(出典: Dathathri et al., Scalable watermarking for identifying large language model outputs, Nature, 2024年10月)。なおこれはGeminiでの検証であり、Claudeで同等の検証結果が公表されているわけではない。

用語ミニ辞典
  • トークン: LLMが文章を扱う最小単位。英語ではおおむね1単語が1〜2トークン。日本語は1〜2文字で1トークンを消費することが多く、同じトークン数でも文字数は英語より短くなる
  • SynthID-Text: Google DeepMindが開発したテキスト向け電子透かし方式。トーナメント方式のサンプリングで、確率分布を保ったまま検出可能なパターンを残す
  • 提供者 / 導入者: EU AI法の区分。提供者(provider)はAIシステムを開発・提供する側(Anthropicなど)、導入者(deployer)はそれを業務で使う側。義務の内容が両者で異なる
  • C2PA: 画像などのファイルに署名付きの来歴メタデータを付ける業界標準。Claudeでは.png/.jpg/.svgが対象
  • n-gram: 連続するn個の単語の並び。「AIが」「が書いた」のような2語の組が2-gram。文章の癖を統計的に見るときの基本単位
  • z検定: 観測された偏りが偶然の範囲かどうかを、標準偏差の何個ぶん離れているかで判定する統計手法。z値が大きいほど偶然ではなさそうという意味になる
  • 偽陽性: AIが書いていない文章を「AIが書いた」と誤判定すること

なお画像などのファイルについては別の仕組みが使われる。透かしではなく、C2PA標準に沿った署名付きの来歴メタデータをファイルに添付する方式で、対象は.png・.jpg・.svgだ。テキストの透かしと違い、こちらは変換やメタデータ削除で失われやすい。

LLMが単語をどう選んでいるのかという前提から知りたい場合は、AIの仕組みを図解でざっくり理解する記事を先に読むと、この節の話が腑に落ちやすい。

Claudeの電子透かしが消える条件・そもそも付かない条件

先に身も蓋もないことを書いておく。2026年8月20日時点で、自分の書いた文章に透かしが入っているかを個人が確認する手段は存在しない。Anthropicが検出APIを出すまで、我々にできるのは入っている前提で運用を組むことだけだ。以下の条件表は、その前提を立てるための材料として読んでほしい。

なお表の内容はAnthropicが公式に説明しているものの整理であり、筆者が実測で検証した結果ではない。

状況透かしの有無
コピー&ペースト残る
軽い編集(誤字修正・語順入れ替え程度)残る場合がある
別のモデルや人間による全面書き換え消える
Claudeによる翻訳残る(全単語をClaudeが選ぶため)
短い文章検出が効かない
事実密度が高く言い換えの余地がない文章検出が効きにくい
8月2日より前に生成済みのテキスト付かない(遡って埋め込まれることはない)
ファイル変換でメタデータが落ちた画像消える

(出典: Anthropic「How Claude’s text watermarking works」 2026年8月14日、Anthropicヘルプセンター

表で「全面書き換えで消える」と「Claude翻訳では残る」が並んでいて矛盾に見えるが、分かれ目は書き換えの量ではなく、書き換えた主体だ。透かしを持たない別のモデルや人間が単語を選び直せば消える。選び直したのがClaude自身なら、新しい透かしがそこに乗る。

「短い文章」の閾値についてAnthropicは具体的な数字を出していない。Search Engine Journalによれば、実践規範は200トークンを超える自由記述テキストを透かしの対象と定め、それより短いものを用語集で「very short text」と分類している。つまり200トークン以下は、検出できないというより最初から適用対象外の可能性がある(出典: Search Engine Journal 2026年8月14日)。Hacker Newsでは「確信を得るには1000語くらい必要では」というvisiondude氏の推測に対し、nonethewiser氏が「読んだ限りでは100〜300語に近い」と返していた。いずれも公式の数字ではない。

日本語について付け加えておく。Anthropicは言語ごとの検出精度を公表していない。SynthID-Textはトークン単位で動く方式なので、1文字あたりのトークン消費が英語と異なる日本語では、同じ200トークンでも対応する文字数は変わる。英語基準の閾値をそのまま日本語に当てはめる根拠はない、という程度に留めておくのが安全だ。

「簡単に破れる」という批判|非対称な道具としての透かし

開発者コミュニティの反応は、実効性への疑問に集中した。

T3スタックで知られる開発者のTheo氏は、この計画を「非常に怖い変更で、意図したとおりには機能しない予感がする」と評したと報じられている。同記事が伝えるところでは、出てきたテキストに最も基本的な文法チェックや修正を一度かけるだけで簡単に破れる、というのが同氏の指摘だ。

論の骨格は、テキストには知覚できない余白がほとんど存在しないため、透かし方式は「検出が途方もなく高くつくか、迂回が途方もなく安いか」のどちらかにしかならない、というものだ(出典: BigGo Finance 2026年8月、Theo氏の発言を引用した二次記事。筆者訳。一次発言の原典は筆者未確認)。

Hacker Newsでも同じ趣旨の指摘が最も伸びていた。johnfn氏の書き込みが端的だ。

間抜けな質問かもしれないが、これは透かしの目的を台無しにしないか。つまり検出を避けたい人は while (has_watermark(text)) text = slightly_rewrite_with_non_anthropic_llm(text) を回せばいいだけでは。こんなに簡単に破れるなら、透かしの意図を自分は取り違えているのだろうか

これに対する返答も鋭かった。nonethewiser氏は「そのとおりだ。ただし否定を信用できないだけで、肯定は崩れない。Anthropic製と出たならほぼそのとおりだし、そうでないと出ても何もわからない」と整理している(いずれも出典: Hacker News 2026年8月14日。筆者訳)。

つまり透かしは、非対称な道具だ。検出されたことには意味があるが、検出されなかったことにはほとんど意味がない。

透かしを検出する方法はあるのか|検出APIの現状

現時点の答えは「ない」だ。

Anthropicは公式解説で、近く透かし検出APIを提供する予定であり実装の詳細を検討中だ、と述べている。料金体系も利用条件も公表されていない。8月12日にはAnthropicのエンジニアが、誰でも呼び出せるテキスト検出APIが来ると公にコメントしたと報じられている(出典: The Decoder 2026年8月)。

提供されたとしても、できることの範囲は限られる。検出できるのはClaudeの透かしだけで、GPTやGeminiの出力を判定する汎用のAI検出ツールにはならない。検出結果が示すのも「Claudeで処理された可能性」までだ。

市販のAI検出ツールで代用するのも筋が悪い。透かしの有無を見ているわけではないからだ。実際に自作の検出器を試した例が、この筋の悪さをよく示している。

偽陽性の問題|「AIを使っていない」を証明する手段はない

コンテンツ戦略家のAndrea Saez氏は、n-gramとトークン頻度バイアスによるz検定という一般的な統計手法で検出器を自作し、自分の書いた文章を通してみた。

結果はこうだ。個々の文では散発的に高いz値が出る程度だったが、ブログ記事1本を丸ごと流したところ、1語おきに赤く印が付いた。

原因は言語の反復性だった。theやa、isのような機能語が予測可能な間隔で繰り返されるため、ハッシュ関数が同じ語のペアに固定の判定を返してしまう。同氏はこれを非独立性の問題と呼び、こう結論している。「統計的に正しい検出手法であっても、自然言語の反復パターンを考慮しなければ、自信ありげな偽のシグナルを出しうる」(出典: Substack「Putting Claude’s Watermarking to the Test」 Andrea Saez氏、2026年8月11日。筆者訳)

Anthropicの公式実装とこの自作検出器は別物だ。同列には扱えない。ただし同氏が指摘するとおり、この失敗モードは透かし研究の原典でも認められている。Kirchenbauerらの論文(A Watermark for Large Language Models, ICML 2023)自体が、繰り返しの多い普通の人間の文章が緑トークン数の過剰なカウントを生みうると書いている。偽陽性は実装の粗さではなく、手法に内在する性質だ。

逆方向の穴もある。ETH ZurichのSRI Labが発表したWatermark Stealing in Large Language Models(Jovanović・Staab・Vechev, ICML 2024)は、透かし付きモデルのAPIを叩いて透かしの規則を推定すれば、透かしの除去と偽造が50ドル未満のコストで、平均8割超の成功率で成立することを示した。透かしのない文章に盗んだ透かしを刻み込む実験では、良質な言い換えの少なくとも74%が「透かしあり」と判定されている(出典: Search Engine Journal 2026年8月14日が同研究を引用)。これは自然発生する偽陽性ではなく意図的な偽造攻撃の成功率だが、「透かしあり=Claude製」という推定が第三者に偽造されうることを意味する。

ここに、この技術の一番厄介な非対称性がある。「AIを使った」ことは示せる方向に技術が伸びているのに、「AIを使っていない」ことを証明する手段は増えていない。Hacker NewsのModernMech氏の書き込みが、この構図をよく捉えている。

残念ながら魔女狩りは、AIを使っていようがいまいが止まらない。使っていなくても、避けられない偽陽性のせいで反AI十字軍はいずれ君のところにも来る。すでに純度を求めるアート系コミュニティで山ほど起きているし、コード系コミュニティでも起きるだろう。傷つくのは、ただ物を作ろうとしているだけの人たちだ

(出典: Hacker News ModernMech氏、2026年8月12日。筆者訳)

ただ、備えがないわけではない。執筆の過程が残っていれば、それ自体が証拠になる。ドキュメントの版履歴、gitのコミットログ、下書きのタイムスタンプ。制作の痕跡を残す習慣は、透かし以前から有効な自衛策だ。「AIを使っていない証明」はできなくても、「自分が手を動かした記録」は出せる。

Claude Codeで書いたコードに電子透かしは入るのか

Claude Codeのユーザーが真っ先に気にしたのは、リファクタリング結果が汚れないかどうかだった。Datasette開発者のsimonw氏の書き込みがそれを代表している。

これがどう動くのかもっと知りたい。自分がClaudeとやり取りする内容の多くは、かなり精密なテキストを返すものだ。プロジェクトを編集して特定の関数を複数箇所でリファクタリングしてくれと頼むとき、自分は何が起きてほしいかを正確に把握している。そのリファクタリング結果に、透かしとして働く妙なパターンが焼き付けられるのは許容できない

(出典: Hacker News simonw氏、2026年8月11日。筆者訳)

この懸念に対して、Anthropicは公式解説で答えている。コードは正確さが要求される場面が多いため、他の形式のテキストに比べて透かしの適用は一般に少ない。適用されるのは主にコメントで、実際に生成されるコードへの影響は無視できる程度だとしている。

ただし「まったく入らない」と断定されているわけではない点には注意がいる。生成物の同一性が厳密に問われる用途なら、公式ドキュメントの最新の記述に当たっておいたほうがいい。

裏を返せば、コード生成については透かしがほぼ機能しないということでもある。amai氏が「数学やソースコードでは(コメント以外)効かないということか」と書いていたのは、そのまま正しい(出典: Hacker News amai氏、2026年8月14日。筆者訳)。AIが書いたコードかどうかを透かしで判別する運用は、現状では成り立ちにくい。

コードの出所を管理したいなら、透かしではなくコミット規約やレビュー体制で担保するしかない。Anthropicが企業向けに整備しているCompliance APIによるセッション内容の取得のほうが、監査という目的には素直に効く。

他社モデルに逃げれば済むのか|Google・OpenAIの現在地

「では他社モデルを使えばいいのか」という反応は当然出る。ただ、逃げ場は思ったほど広くない。

Googleは2024年からGeminiにSynthID-Textを適用している。DeepMindの発表では、生成テキスト向け透かしの大規模な実運用としては初めてで、数百万人規模のユーザーに提供されたとされる。つまりGeminiは、Claudeより2年早く同種の透かしを載せていたことになる。

OpenAIは2026年8月2日にサポートページを更新し、透明性義務を満たすためにプロベナンス(来歴)シグナルをテキストモデルにも広げることを目標としている、と記載した。ただしテキストにどう印を付けるかの具体的な方法は明言しておらず、Anthropicと同じ不可視の透かし方式を採るとも確認していない(出典: City A.M. 2026年8月、InfoQ 2026年8月)。

第50条の義務は特定企業ではなく提供者全般にかかる。EU市場でサービスを続ける限り、いずれ同種の対応が広がると見るほうが自然だ。透かしのないモデルを探して回るのは、当面しのげても長期の戦略にはならない。

AIが書いた文章の「らしさ」を落とす実務

透かしとは別に、AI特有の言い回しをどう削るかは編集の技術の問題だ。Claude Code用に配布されているスキルの中身を分解して解説している。

AI臭を消す手順を見る

SEOへの影響|Googleは方針変更を表明していない

ブログ運営者として一番気になるのはここだと思うので、はっきり書く。

現時点で、透かしが検索順位を下げるという公表された根拠はない。Googleの公表方針は従来どおりで、制作手段を問わず役に立つ・独自性のある・専門性を備えたコンテンツを評価し、順位操作を目的に量産されたコンテンツを評価しない、というものだ(出典: Google検索セントラル「AI生成コンテンツに関するGoogle検索のガイダンス」)。AI生成かどうかそのものを評価軸にしていない。

一方で、確定していないことも明確にしておく。Search Engine Journalは、マークが付いたコンテンツがクロール・インデックス・表示の段階で違う扱いを受けるかどうかは誰からも表明されていない、と書いている。GoogleもEUの透明性に関する実践規範に署名しているが、ランキング上の扱いについては何も述べていない。

現実的なリスクは検索エンジンよりも取引先側にある。同記事は、クライアントやプラットフォームが「人間が作った証拠」を求め始める一方で、それを提示する明確な手段がまだ存在しないという信頼性の問題を指摘している。「AI不使用」を納品条件に入れる契約は、この非対称性のせいで実質的に検証が困難な条件になりかねない。実際にどう扱われるかは契約文言と個別事情によるため、条項の設計は専門家に相談したほうがいい。

電子透かし時代の実務判断|自分ならこうする

PMとしてClaudeを日常的に回している立場から、判断を書いておく。

まず、透かしを消す努力はしない。理由は3つある。消す方法として現実的に挙がっているのは透かしを持たない別のモデルや人間による全面書き換えだけで、それをやるなら最初から自分で書いたほうが早い。次に、規制対応として導入された仕組みの回避に第三者へ金を払う構図が、個人的に釈然としない。すでに「透かし除去」をうたうサービスやリポジトリは出回りはじめているが、そこに乗る気にはならない。そしてそもそも、消す必要がある状況を作らないほうが健全だ。

そのうえで、運用としては2つ変える。

1つ目は、AI利用の開示を先に置くことだ。透かしが入る時代には、後から検出されるより自分で先に言っておくほうが立場を守りやすいと考えている。文面はこの程度で足りる。「本サイトの記事は、構成・執筆の一部にAI(Claude等)を使用しています。公開前に運営者が全文を確認し、内容の責任は運営者が負います」。後半の「人間が確認した」部分が第50条(4)の除外規定に対応するので、そこを落とさないほうがいい。

第50条(4)は導入者側にも、公共の関心事項について情報提供する目的で公表されるAI生成テキストについて開示義務を課している。ただし、人間によるレビューまたは編集上の管理下に置かれ、かつその公表内容について編集責任を負う者が存在する場合は除外されるとされる(出典: EU AI Act 第50条(4)。筆者による仮訳・要約であり、正確な適用範囲は原文および専門家の判断による)。要するに、人が責任を持って確認したかどうかが分岐点になっている。

2つ目は、納品物にAI検出結果を条件として書かせないことだ。クライアント側から「AI検出ツールでクリーンであること」を求められた場合は、AI検出には偽陽性が避けられないという論点を材料に条件の見直しを相談する。交渉に使うべきは特定の誤検知率の数字ではなく、検出結果が生成の有無を確定できないという性質そのものだ。代替案も一緒に出すと通りやすい。「AI検出ツールの判定結果を検収基準としない。その代わり、納品物は編集責任者が全文を確認し、事実関係の裏取りを行ったことを保証する」。検証不能な条件を、検証可能な条件に置き換える形だ。

コードについては、当面何も変えない。透かしがほぼ入らない以上、Claude Codeの出力が原因で何かを疑われる展開は考えにくい。むしろ気にすべきはClaude Code auto modeが8月14日に既定化されたことのほうで、人間の目を通らないコードが増える問題に透かしは何も貢献しない。

最後に、この技術に対する筆者の評価を書いておく。少なくとも現在公開されている情報の範囲では、透かしは悪意ある使い方を止める仕組みとしては期待しにくい。HNのbonoboTP氏が書いていたとおり、痕跡を消そうとするだけの手練れは大多数ではない(出典: Hacker News bonoboTP氏、2026年8月14日。筆者訳)。だからこそ、怠惰な学生のレポートのような大量発生する低リスク領域には効く。逆に言えば、本気で隠す意志と手段を持つ相手には効きにくい。

その程度の道具に、就職や成績のような重い判断を委ねる運用が始まったら、それは技術の問題ではなく運用の問題になる。透かしの限界は、Anthropic自身がかなり正直に書いている。読むべきなのは、その但し書きのほうだ。

今日やること(5分)
  1. Claudeで書いた納品物がある場合、契約書に「AI不使用」条項が入っていないか確認する
  2. 自分のサイトやポートフォリオにAI利用の開示があるか見直す。無ければ本文の文例を1行足しておく
  3. Claudeを校正・翻訳にだけ使っている文章にも透かしが付く点をチームに共有する
  4. コード生成についてはほぼ影響がないことを確認し、不要な対応をしない
  5. Anthropicの公式解説をブックマークし、検出APIのアナウンスを追える状態にしておく

※ 契約条項の解釈・対応は個別事情によります。判断に迷う場合は弁護士等にご相談ください。


関連記事


本記事の情報は2026年8月20日時点のものです。電子透かしの仕様・適用範囲・検出APIの提供状況は変更される可能性があるため、最新の情報はAnthropic公式解説およびAnthropicヘルプセンターを参照してください。条件表はAnthropicの公式説明を整理したものであり、筆者が実測で再現検証したものではありません。「200トークン未満」「100〜300語」といった閾値はAnthropicが公表した数字ではなく、第三者による整理・推測です。Theo氏の発言はBigGo Financeの記事を経由した二次引用であり、一次発言の原典は筆者が直接確認したものではありません。実践規範の署名者数・策定経緯は欧州委員会および各報道の公表内容に基づきます。ICML 2023・2024の各論文に関する記述はSearch Engine Journalおよび公開されている論文の要旨に基づくもので、筆者が実験条件を再現検証したものではありません。Andrea Saez氏の検証は同氏が自作した検出器によるものであり、Anthropicの公式実装の挙動を示すものではありません。Hacker News・Substack等から引用した各氏の発言は発言者個人の見解であり、当サイトの見解ではありません。英語ソースからの引用は筆者による翻訳です。正確な文言は各出典先の原文をご確認ください。EU AI法の解釈および契約実務に関する記述は法的助言ではありません。個別の契約条件や法令適用については弁護士等の専門家にご相談ください。当サイトはAnthropic社、Google社その他本記事で言及した企業と資本関係・提携関係を有しません。

※ 記載の会社名・製品名は各社の商標または登録商標です。

Share