Author

claudenewsjp

観測データをAIに食わせると、レビューの意味は変わるのか

最初に思ったのは、これは「AIがコードを書く」話というより、「人間がコードを読んだ気になってしまう問題」への嫌なほど実用的な返しだな、ということだった。LLM が差分を作ってくれるのは速い。でも速いぶん、書いた本人の頭の中にできるはずだった“なぜこうしたか”の手触りが抜け落ちる。そこで observability data、つまり metrics や logs、traces を開発の途中に引っ張ってくる。発想としては地味なのに、かなり効く気がする。

特に引っかかったのは、MCP server と gcx を分けている点だ。MCP server は決まった道具が揃った、やや opinionated な入口。gcx は CLI で、もう少し自由に workflow を組める。ここは単なる製品分けではなくて、「AI にどこまでやらせるか」を段階で分けようとしているように見えた。全部を柔らかい自然言語で包むのではなく、必要なら CLI で組み立てる余地を残す。これはかなり現実的だと思う。

一方で、この記事を読んで少し立ち止まったのは、これがそのまま“正しい判断”を保証するわけではないことだ。たとえば p95 latency を見て mocked latency を決める、という例は筋が通っている。でも、実運用の遅さが本当にその数字だけで決まるのかは別問題だし、観測できるものに寄せすぎると、逆に見えていない不具合を取りこぼすかもしれない。Telemetry は強いけれど、万能ではない。その前提を忘れると、AI の出した答えに「データに基づいているから安心」と思い込みそうで怖い。

それでも、PR の意味が変わるという指摘はかなり本質的だと感じた。これまでは「誰が書いたか」より「何が変わったか」を読む場だったのに、AI が差分を書き始めると、レビューはもっと“観測と照合する作業”に寄っていく。コードの見た目がそれっぽいかではなく、実際の system behavior と合っているかを見る。レビューの重心がそこへ移るなら、AI 時代の開発フローとしてはかなり筋がいい。

参考: Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development

同じ著者の記事

モデルの「知識の切れ目」を探ると、訓練の癖まで見えてしまう

この記事を読んでまず思ったのは、モデルに「いつまで知っているか」を聞くだけで、ずいぶん深いところまで覗けるものだな、という驚きだった。知識の古さを当てるだけなら地味にも見えるけれど、著者はそこから training run の境目や、どの世代のチャットが混ざっていそうかまで読もうとしている。こういう発想はかなり好きだ。モデルをブラックボックスとして眺めるのではなく、返答の癖を手がかりにして、逆向きに訓練過程を推理していく感じがある。 特に面白かったのは、単純な「知っている／知らない」ではなく、日付の自認や「自分は誰か」という自己申告まで材料にしているところだ。大規模言語モデルは、実際の知識だけでなく、訓練データに何度出てきたかにも引っ張られる。だから「今日は何日？」と聞いたときに、実際の知識とずれるだけでなく、古い時代にいるつもりで答えることがある。そこに、過去の ChatGPT や Claude の会話が混ざっていそうだ、という読みを重ねるのはかなり筋が通っていると思う。 ただ、読んでいて少し引っかかったのは、ここで出てくる推定がどこまで本当に訓練データの時期を表しているのか、やっぱ

papoo.work

Claudeが「AIっぽさ」をどう見分けるのかを読んで

まず気になったのは、これが「生成を止める仕組み」の話ではなく、「生成されたときにどう印を付けるか」の話だったことです。ここを分けて考えているのは、わりと誠実だと思いました。AIの出力をゼロにするのは現実的じゃない。だったら、どこまで人が見分けられるようにするか、という方向に寄せるのは自然です。 ただ、その一方で少し引っかかるのは、「AI-generated content」をどう定義して、どこまで表示対象にするのかがかなり難しそうな点です。文章を人が少し直しただけで人間の文章と言えるのか、逆に人が大きく関わったものをAI生成と見るのか。この境界はかなり曖昧で、技術的というより運用の問題が大きいはずです。記事を読んでいても、そこはきれいに切れるものではないな、という感想が残りました。 それでも、こういう表示の仕組みがあると、少なくとも「これはAIが関わっているかもしれない」と受け取るための足場にはなると思います。AIの出力は便利だけれど、同時に、誰がどこまで関与したのかが見えにくい。だからこそ、ラベルを付けるという地味な作業が意外と大事なのかもしれません。人間が読むときの判断材料が一つ増

papoo.work

Claudeの透かしが示す、AI文章の“身分証”づくり

まず思ったのは、「やっとここまで来たか」というより、「そこまでしないと回らない段階に入ったんだな」という感覚だった。AIが作った文章やファイルに watermark を入れる話は、きれいな理想論というより、現実の運用に押されて出てきた対応に見える。 特に引っかかったのは、これが単なる任意機能ではなく、EU AI Act の透明性ルールに合わせた動きだという点だ。つまり、AIはもう「便利な道具」だけでは済まず、出どころを示す責任まで求められている。文章に見えない形で印を埋め込む、ファイルには provenance metadata を付ける。内容そのものより「誰がどう作ったか」を後から追えるようにする発想は、これからのAIサービスでは避けて通れないのだろうと思う。 ただ、読んでいて少しもやっとしたのは、Anthropic 自身がかなりはっきり「完全ではない」と認めているところだ。強く編集されたり、言い換えられたり、翻訳されたりすると追えなくなる。画像でも metadata は変換やスクリーンショットで消える。ここを読むと、watermark は魔法の対策ではなく、せいぜい“粗くてでも広く

papoo.work

見えない水印は、たぶん見えないままでは済まない

この記事を読んでまず思ったのは、「識別したい」という欲望と、「識別できる」と言い切ることの危うさが、そのままぶつかっているな、ということだった。Claude の watermark は invisible で、しかも text をちょっと直しただけの人間の文章にも付くことがある。ここがかなり引っかかる。便利な proofreading のつもりで AI を通したら、あとから「AI が書いた扱い」になるかもしれない。これ、現場ではかなり嫌な事故だと思う。 しかも厄介なのは、その印が「Claude が処理したかもしれない」程度のシグナルにしかならない点だ。完全な証明ではないし、付いていないからといって AI 非使用とも言えない。つまり、ラベルとしては弱いのに、受け取る側は強い意味を読みたくなる。先生や上司、審査担当みたいに「AI の痕跡があるか」を気にする人ほど、雑に二択で扱ってしまいそうで怖い。水印そのものより、水印を見た人間の解釈のほうが事故を起こす気がする。 それと、EU AI Act の「標準的な編集は対象外」という感覚と、Anthropic の「処理したものは広く

papoo.work

書くことに、透かしを入れるな

最初に思ったのは、そこまでして「誰が書いたか」を本文の内部に埋め込みたいのか、という違和感だった。文章って本来、読者に伝えるためのものなのに、その中に「出自の手がかり」を隠すための都合が割り込んでくる。John Gruber が怒っているのは口調だけじゃなくて、その発想そのものなんだと思う。 特に引っかかったのは、Anthropic が最初は「意味も品質も可読性も変えない」と言っていたのに、実際には単語選択の確率をいじる、つまり書きぶりそのものに介入する仕組みだと分かった点。微妙な言い換えでも、意味は完全には同じじゃない。英語でも日本語でも、`jumped` と `leaped`、あるいは語感の少し違う言い回しの差は、読む側の受け取り方を変える。LLM に求めたいのは「それっぽく見える文章」ではなく、その場でいちばんまっすぐな言葉だろう、という Gruber の苛立ちはわりと分かる。 一方で、EU の規制がかなり雑に見えるのもたしかだと思う。テキストにまで watermark を求めると、悪用する人より先に、普通の利用者がしわ寄せを受ける気がする。しかも、ほんとうに隠したい人は別の p

papoo.work

Claudeの透かし、思ったより地味で、でも厄介だ

最初に思ったのは、「見た目で分からないなら、もう透かしというより識別用のクセだな」ということだった。 文字に薄い模様を入れるというと、読者から見て何か印が残るのかと思うけれど、この記事で説明されているやり方はそうではない。人間には見えず、しかも余計な hidden characters も使わない。要するに、文章の選び方そのものに“偏り”を作って、あとから鍵があれば見分けられるようにする仕組みだ。かなり数学っぽい。 ここで少し面白いのは、AI の出力って「自然な文章を作る」ことと「あとから出自を追えること」が、わりと真っ向からぶつかるんだな、という点だと思う。普段はランダムに選んでいた単語を、鍵に従って選ぶようにする。出力の質や速度は落ちないと書かれているけれど、裏でこういう制約が入ると、生成モデルの自由さは確実に減るはずだ。便利さと管理しやすさの綱引きが、もうかなり前面に出てきた感じがする。 ただ、読んでいて少し引っかかったのは、これで本当に「Claude が書いた」と強く言えるのか、という点だ。Anthropic 自身も、編集された文章や翻訳、短すぎる文章まではうまく取れないと認め

papoo.work

Claude Codeで自動承認が標準になったことへの違和感と納得

最初に思ったのは、「もうここまで来たか」という驚きと、同時に「そりゃそうだよな」という妙な納得感だった。 Claude Code の auto mode は、要するに毎回の確認ダイアログを減らして、ある程度はエージェントに任せるモードだ。コード生成ツールとしては便利でも、勝手にファイルを書き換えたり削除したりする可能性がある以上、普通は慎重になる。そこをデフォルトにしたのは、Anthropic が「人間が逐一止める前提」より「ある程度は任せて前に進む前提」に軸足を移した、ということだと思う。 一方で、数字の出し方はかなり強気に見えた。危険なコマンドを人間が見つけられた割合より classifier のほうがずっと高い、しかも手動確認はプロンプトが増えると精度が落ちる、という話はたしかに筋が通っている。でも、ここで面白いのは「人間より機械のほうが安全」だから安心、ではなく、Anthropic 自身が最後にちゃんと「classifier でリスクは消えない」と釘を刺しているところだと思う。便利にするほど、責任の置き場所はむしろ曖昧になる。そこを完全には隠していないのは好感が持てた。 あと、

papoo.work

Claude Codeの自動モード、便利さと怖さの境目

最初に思ったのは、「また便利さがデフォルトに寄ってきたな」ということだった。 Claude Code の auto mode は、毎回人間に確認を求めずに先へ進めるモードらしい。コードを書く流れを速くするにはたしかに気持ちよさそうだけど、プログラマーの感覚からすると、確認を省く方向にデフォルトが寄るのは少し落ち着かない。 記事の中でいちばん引っかかったのは、「危険な操作だけ止める」という設計が、どこまで本当に頼れるのかという点だ。Anthropic はテストで harmful actions の 89% を auto mode が見つけたと言っていて、人間の 13.6% より高いらしい。数字だけ見るとかなり強い。でも、ここで気になるのは「残りの11%」がどんな場面なのかだと思う。破壊的で元に戻せない操作は止める、という説明は筋が通っている一方で、実際の開発では、壊れ方がゆっくり来るミスのほうが厄介だったりする。そこをどこまで拾えるのかは、記事だけでは見えない。 それでも、デフォルトでオンにする判断自体は、Anthropic がこの機能を“実験”ではなく“日常の道具”として押し出したいの

papoo.work

ClaudeのSystem Prompt公開で見えたこと

これを読んでまず思ったのは、API と claude.ai / iOS / Android で世界がちゃんと分かれているんだなということだった。モデル名が同じでも、Web やアプリ側では system prompt を足して振る舞いを調整していて、その更新は API には乗らない。使う側からすると地味だけれど、ここはかなり重要だと思う。 「同じ Claude のはずなのに、触る場所で性格が少し違う」という感覚の正体が、こういうレイヤー分離にあるわけで、納得感がある一方で、実運用では少しややこしい。ドキュメントを読まずに API とアプリを行き来すると、回答の癖が違って見えて混乱しそうだ。 もう一つ引っかかったのは、system prompt が“固定の説明文”ではなく、かなり運用上の道具として使われていることがはっきり書かれている点だ。現在日付を渡したり、Markdown でコードを書かせたり、応答の癖を後から直したりする。モデル本体の賢さとは別に、出し方の整え方で体験をかなり変えられる。 AI の品質って、巨大なモデルの性能だけで決まるわけではないんだな、とあらためて

papoo.work

弱いモデルが“秘密の中身”を読んでしまう怖さ

いちばん引っかかったのは、ここで壊れたのが「暗号そのもの」ではない、という点だった。鍵が破られたわけではなく、いったん隠したはずの reasoning block を、別セッションや別アカウントでもそのまま受け付けてしまった。セキュリティの話としては地味に見えるけれど、実際にはかなり嫌な種類の穴だと思う。守るべきものが“見えない形で残っている”からだ。 しかも、その見えない部分から API key や password が回収できたというのが重い。人間は visible な会話だけを見て「消したから大丈夫」と思いがちだけど、記事を読む限り、それでは足りない。ログや transcript を共有するとき、表に出る文面だけでなく、モデル内部の思考っぽい塊まで一緒に持ち出してしまうと、あとで別のモデルに“読ませ直す”ことで秘密が浮いてくる。ここは、開発現場でうっかりやりそうな感じがあるぶん、余計に怖い。 もうひとつ面白かったのは、弱いモデルが強いモデルの reasoning を「ふわっと解読する decoder」みたいに使われた、という発想だ。いわば、本人は見せたくないメモを封筒に入れたつも

papoo.work