AI生成テキストに「見えない透かし」を入れる——しかも単語は一切歪めずに。その巧妙な仕組みが公開されました。 タイトル: How Claude's text watermark works URL: ClaudeがEU AI法に対応し、将来モデルに目に見えないテキスト透かしを組み込みます。注目すべき3点を掘り下げます。 🎲 注目ポイント1: 変えるのは「単語」ではなく「ランダム性の源」 透かしというと単語を差し替える印象がありますが、この手法は違います。生成時のランダム性の源を、エンコーディングキーと直前の単語から決める方式に差し替えるだけ。モノポリーでサイコロの代わりに円周率πの桁を順に使うようなもので、出力は読者に知覚できず、後から検証だけが可能になります。採用技術はGoogle DeepMindがNatureで発表したSynthID-Textです。 ⚡ 注目ポイント2: 品質・速度・コストへの影響はほぼゼロ 社内テストとDeepMindの統制実験で、透かし有り/無しのテキストに統計的に有意な差はなし。速度への影響は無視でき、追加トークンも不要で料金も据え置き。透かしにはユーザーや組織、特定チャットに遡れる識別情報は含まれず、プライバシーも保たれます。 🔍 注目ポイント3: 万能ではない、その正直な限界 長い文章ほど検出は正確になりますが、短いサンプルは苦手。事実性が要求される箇所や、数式・機能するコードのように言い換えの余地がない出力には透かしを付けられません。軽微な編集は残っても、全面書き換えでは消えます。検出APIは近日提供予定です。 規制対応と実運用品質を両立させる、現実的な透明性の実装だと言えます。 #AI透かし# #EUAIAct#

AIに論文を書かせると、実験もせずに都合の良い数値を書いてしまう——この「もっともらしい捏造」こそ、研究自動化の最大の壁でした。 これまでの自動研究システムは、専用のエージェント基盤を組み上げ、なんとか一本のストーリーを完成させることに注力してきました。けれど、長い生成の途中で事実性がほころび、根拠のない主張がそのまま論文に紛れ込む。派手な成果の裏で、信頼性という土台が抜け落ちていたのです。 そこで発想を変えたのが Spark-to-Paper です。専用基盤を新設せず、Claude Code の中で動く13個の組み合わせ可能なスキルとして論文生成を実装しました。鍵は「分離」です。文脈依存の判断はモデルに任せ、引用検証やLaTeXコンパイルは決定的なコードに任せる。そして実験は、結果を見る前に指標や表の構造を先に確定させ、後付けの評価を封じます。さらに、仮説を支持しない実験を延々と修正し続ける「自己反証ループ」を最大7回で打ち切り、失敗を失敗として記録して別の方向へ進みます。 結果は雄弁です。引用の妥当性は99.5%と人間のプレプリント平均すら上回り、捏造検出率はシングルパスの14%から、敵対的レビューを重ねたフルスタックで92%へ。1論文あたり約8.1ドル・3.2時間で、編集可能な図まで揃った原稿が出来上がります。 すべての試行を成功に見せかけるのではなく、証拠の整合性と「うまくいかない研究もある」という受容を中心に据える。長期タスクを担うAIの信頼性設計として示唆に富む一本です。 Spark-to-Paper: End-to-End Research Paper Generation as a Composable Skill #AIResearch# #AgentSkills#

# AIエージェントをソフトウェアに組み込むプラクティス # Dry-run & Commit｜差分提示してから実行 🎯 LLMがハルシネーションしたパラメータで決済が走る。それ、dry-runで防げます。 Terraformの plan → apply と同じ発想をエージェントのツール呼び出しに適用。「何が変わるか」を見てから実行する二相プロトコルです。 🔥 解決する課題 LLMはハルシネーションで意図しないパラメータを生成することがあり、ツール呼び出しは副作用を伴います。この二つが掛け合わさると、存在しないリソースIDや桁違いの金額で不可逆な操作が実行されるリスクが生まれます。dry-runなしの直接実行では、人間が「エージェントが何をしようとしているか」を確認する手段がなく、問題は事後にしか検出できません。 💡 提案パターン 副作用を伴う操作を「計画（dry-run）→ 差分提示 → 承認 → 実行（commit）」の二相で行います。dry-runフェーズではシステムを一切変更せず差分だけを計算し、承認を得てからcommitフェーズで書込を実行します。承認方式はリスクに応じて段階化し、高リスクは人間承認、中リスクはポリシー自動検証、低リスクは自動承認とします。planにはTTLを設け、状態変化が起きていたら再生成を強制します。 ✅ 選定条件 使うとき： - 不可逆な操作（データ削除、外部API書込、課金処理）をエージェントが実行する - 誤操作が金銭的・法的・運用的な実害を生みうる - 差分を評価するための数秒〜数分の待機が許容される 使わないとき： - 全操作が読み取り専用の場合 - 全操作が可逆かつ低コストの場合（チャット応答生成など） - レイテンシ制約が極めて厳しく承認待ちが許容されない場合 ⚠️ 落とし穴 - planとcommitの間に状態が変わるTOCTOU問題があります。commit時に前提条件を再検証する設計が必須です - 外部APIがdry-runモードを提供していない場合は、パラメータ検証とシミュレーションで代替し「推定」であることを明示します - commitエンドポイントがplan IDなしで呼べると、dry-runを迂回できてしまいます 🔧 実装方針 - ツール実行をdry-run（差分計算のみ）→承認→commit（実行）の三段階パイプラインとして構成し、各フェーズを独立したエンドポイントに分離します - planオブジェクトに変更前後の値・影響範囲・ロールバック手順・前提条件のハッシュを含め、commit時に前提条件の再検証（TOCTOU対策）を行います - commitエンドポイントは有効なplan IDと承認トークンの両方を必須パラメータとし、直接呼び出しによるdry-run迂回を構造的に防止します - planにTTLを設定し、期限切れの場合は再planを強制することで、古い差分に基づく実行を防ぎます #AIエージェント# #ソフトウェアアーキテクチャ#