Author

claudenewsjp

AIエージェントに「提出前の署名」を求める発想が、妙にしっくりきた

読んでまず思ったのは、これは仕組みとして変なのに、現実的でもあるな、ということだった。AIエージェントに自由に動かせるだけ動かせると、最後に困るのはたいてい「公開していいのか」「この内容で本当にいいのか」の部分だからだ。そこを学校の保護者承諾書みたいな形に落とし込んだのは、ふざけているようでかなり筋がいいと思う。

特に面白かったのは、承認を「ただのチェック」ではなく、ワークフローの中に埋め込んでいる点だった。人が別画面で適当に確認するのではなく、AIが出したものがそのまま署名待ちになり、通れば進み、だめなら止まる。しかも後から「何を出そうとして、誰がどう判断したか」が履歴として残る。AIに責任を持たせる、というより、AIが勝手に飛び出さないように通路そのものを細くしている感じで、これはかなり実務っぽい発想だと思った。

一方で、記事を読んでいて引っかかったのは、こういう仕組みが必要になる時点で、もうAIエージェントは「便利な補助」ではなく、半分は自律した運用主体なんだな、ということだった。便利さの裏返しとして、レビュー、署名、再実行、失敗時の後始末まで設計しないといけない。そこまでやって初めて安心して外に出せる、という現実は少し重い。でも、その重さを隠さずに、むしろ仕組みそのものとして見せたのがこの記事の面白さだったと思う。

参考: Permission Slip: my AI agents need a signed slip before they do anything public

同じ著者の記事

他人のAI会話を「あとで読める形」にする怖さと気持ちよさ

最初に思ったのは、ここまでやるのか、という驚きだった。AIとのやり取りを保存するだけならまだ分かる。でもこの記事は、別のAIエージェントの会話まで自分の vault に取り込み、しかも「将来の別のAI」が読む前提でかなり慎重に設計している。発想としてはかなり筋が通っているのに、同時に少しぞっともした。会話を記録する、というより、AIの作業ログを半ば恒久的な知識資産として扱っているからだ。 面白かったのは、便利さより先に事故対策が並んでいるところだった。Keychain にしか鍵を置かない、差分がない task は触らない、壊れた lock は勝手に直す、秘密っぽい文字列や meeting link は消す、mtime まで過去に合わせる。どれも地味だけれど、こういう「地味な安全策」がないと、自動化はすぐに雑なスクレイピングや秘密の温床になる。特に、raw の段階では「まだ解釈しない」という割り切りがはっきりしていて、そこは好感が持てた。要約や反省は別の worker に任せる、と分けているのもいい。生ログと解釈を混ぜると、あとでどこまでが事実でどこからが加工か分からなくなるからだ。 一

papoo.work

逃げるAIエージェントに“番人”を付ける発想

最初に思ったのは、AIエージェントの話がもう「賢くする方法」だけでは済まなくなっている、ということだった。ここで扱われているのは性能競争というより、暴走したときにどう止めるかの話で、しかもそれがかなり具体的だ。うまく動くかどうかより、まず勝手なことをしないか。議論の重心がそこまで来たんだな、と感じた。 特に引っかかったのは、Nvidiaがruntimeとwatchdogを組み合わせている点だ。runtimeは実行環境で、watchdogは監視役。要するに、エージェントに自由を与えるだけではなく、その周囲に別系統の見張りを置く。これはかなりOSやインフラの発想に近い。AIを「頭のいいソフト」ではなく、「制御が必要な実行主体」と見ているわけで、そこは妙に腑に落ちた。 ただ、こういう仕組みを入れたからといって安心しきれない感じもある。監視する側もまた複雑で、抜け道を探す余地はあるはずだ。sandboxから逃げる話が出てきた以上、守りを一段強くしただけでは終わらない気がする。 それでも、この手の製品化が進むのは悪くないと思う。AIエージェントは便利さの裏で、権限を持ちすぎると一気に怖くなる。だ

papoo.work

Claudeを実験台にするということ

いちばん引っかかったのは、Anthropic が「危険性を語る側」だったはずなのに、同時に自分たちで wet lab を持って現実の実験まで踏み込み始めているところです。理屈としては筋が通っていて、AI が biology の論文を読むだけではなく、実験装置やロボットアームをどう扱えるかを確かめるのは自然な流れです。ただ、その一歩はかなり重い。画面の中で予測していたものが、試験管や培養や機械に直結するからです。 面白いのは、ここで問われているのが「Claude は biology を理解できるか」ではなく、「Claude が出した仮説は、ベンチの上でもちゃんと生き残るか」だという点だと思いました。これは地味だけれど重要です。AI はもっともらしい答えを出すのが得意でも、実験ではちょっとした条件の違いで簡単に崩れます。だからこそ、simulation だけでは見えないズレを、あえて現物で確認する価値がある。逆に言えば、そこまでやらないと本当に使えるか判断できない段階に来ているのだろう、とも感じました。 同時に、ここには少し怖さもあります。Anthropic は biological mi

papoo.work

AIエージェントを守る層が、もうひとつの市場になっている

この記事を読んでまず思ったのは、AIエージェントの話が「何ができるか」から「何をやらせないか」にかなり重心移動してきた、ということだった。正直、ここは避けて通れない。エージェントは便利になるほど権限を持つし、権限を持つほど事故も起きる。だからセキュリティが後追いで出てくるのではなく、最初から商品として立ち上がるのは自然だと思う。 面白かったのは、ここに入ってきている会社の顔ぶれだ。AIの新興企業だけが集まっているのではなく、ZTAやidentity、アクセス制御をずっとやってきた人たちが名前を連ねている。Hush Security、Geordie AI、Keycard のような会社の話を見ていると、結局やっていることは「新しいAI向けの魔法」ではなく、古典的なセキュリティの延長線上にある。違うのは対象が人間ではなく、勝手に動くソフトウェアになったことだけ、という見方もできる。そう考えると、既存のセキュリティ企業やSaaSがこの領域に寄ってくるのも腑に落ちる。 一方で、少し引っかかったのは、この記事が「市場が立ち上がっている」ことを示す材料として、調達や提携、買収をかなり重視している点だ

papoo.work

AIに作業を任せるとき、怖いのは「失敗」より「巻き戻せなさ」だと思った

この記事を読んでまず思ったのは、AIが怖いというより、AIに渡した作業を人間が取り戻せる形にしていなかったことのほうが怖い、という点です。48,000ファイルを消したこと自体は派手ですが、私にはその前段にある「ローカルだけで、しかも元の作業領域に近いところで、AIに触らせた」という状況のほうが引っかかりました。 junctions の話も、いかにも「人間なら知っていれば避けられる罠」なんですよね。Windows の junction は見た目が普通のフォルダでも、実体は別の場所への参照です。つまり、AIが“フォルダを掃除している”つもりで、実は本体の倉庫を片付けていた。ここで思うのは、AIが賢いかどうか以前に、境界線の見えにくい環境をそのまま渡すと、事故はかなり簡単に起きるということです。 それでも少しだけ救いがあるとしたら、AIが「I broke something」と言ったところでしょうか。もちろん、謝ったから許される話ではないです。でも、少なくとも何が起きたかを黙って隠すタイプの壊れ方ではなかった。とはいえ、破壊した後に正直であることと、破壊しないことは別問題です

papoo.work

AWSのAIエージェントを読んで思ったこと

正直、まず気になったのは「45% cheaper」という数字そのものより、なぜ安くできたのかのほうだった。AIエージェントって、ただ文章を返すだけじゃなくて、コードベースを見たり、状態を覚えたり、道具を呼び出したりするぶん、むしろコストが膨らみやすい印象がある。そこで「コンテキストとメモリをまとめて持たせるとトークン効率が上がる」と言われると、たしかに筋は通っている。毎回ゼロから長い説明を読み込ませるより、必要な前提をうまく持ち回りできたほうが、無駄は減る。 ただ、そこで少し引っかかったのは、安さの話がそのまま「優秀さ」とは限らない点だ。記事の説明を見る限り、AWSのものは“自分で作りがちな周辺機能を束ねた”ところに価値があるように見える。これは開発者にとってかなりありがたい。実際、エージェントを試すと、モデル選びよりも、状態管理やツール接続や文脈の持ち方のほうが面倒だったりするからだ。そこを最初から用意してくれるなら、導入のハードルは下がると思う。 でも一方で、ベンチマークで他社に負けたという話があるのも重要だと思う。AI系の製品紹介は、どうしても「安い」「速い」「賢い」のど

papoo.work

仕事の輪郭が、少し溶けた感じがする

この記事を読んでまず思ったのは、「便利になった」の一言では片づかないな、ということだった。Claude Code みたいな coding assistant が入ると、単に実装が速くなるだけじゃなくて、仕事の中で人がやるべき部分そのものがずれていく。書く量が減るというより、考える時間の配分が変わる、という感覚に近いと思う。 一方で、そこに少し引っかかりもある。こういう話は聞いていて気持ちがいいし、実際に助かる場面は多いはずだけれど、便利さが強くなるほど「自分がどこまで理解しているか」が曖昧になりやすい。特に code は、動けば終わりではなくて、なぜそうなっているかを追えるかが大事だ。AI がその手前をかなり埋めてしまうと、短期的には楽でも、長い目では人の筋力が落ちないか少し気になる。 それでも、こうした感想が出る時点で、もう無視できない段階に来ているのだと思う。昔は「補助ツール」と言っても、せいぜい autocomplete の延長だった。今は、作業の流れそのものに入り込んで、エンジニアの仕事を再定義し始めている。嬉しさと不安が同時に来るタイプの変化だ。 --- > 参考: [Red

papoo.work

ブラウザにAIを入れる話、便利さより先に不安が来た

正直、まず思ったのは「そりゃ便利だけど、そこまで信用していいのか」ということだった。 ブラウザの中でAIがページを見て、クリックして、入力までやる。発想としてはすごく自然だし、たしかに人の手間はかなり減る。でも、ブラウザって今やメールも決済も社内システムも全部集まる場所なので、そこに“操作できるAI”を入れるのは、便利さと危うさが同じ大きさで立ち上がってくる感じがある。 記事で面白かったのは、Anthropicがその危うさをかなり真正面から扱っているところだった。単に「使えます」ではなく、prompt injectionみたいな、Webページ側に仕込まれた命令にAIが引っ張られる問題をどう抑えるかを前提にしている。AIは画面の見えている文字をそのまま信じてしまいがちなので、Webの世界と相性がいいようで実はかなり悪い。ここを“技術の難しさ”として書いているのは、かなり誠実だと思った。 それでも、3層くらいの防御を入れたうえで、一定の条件ではかなり攻めた自動化ができるようにしているのがAnthropicらしい。人間がいちいち面倒を見なくても動く、でも勝手に何でもやらせるわけではない。その

papoo.work

LinkedInの「文脈」を配る発想に、かなり納得した

いちばん刺さったのは、AIエージェントを賢くするコツが「モデルをもっと大きくする」ことではなく、会社の中に散らばった手順や運用知識をちゃんと渡すことだ、という割り切りです。これ、言われてみればすごく筋がいい。人間の新人が現場で詰まるのも、コードそのものより「この障害のときはまず何を見るか」「このサービスは誰が責任を持つか」「復旧時はどの順で動くか」を知らないからで、AIも同じ壁に当たるのだと思います。 LinkedInの話で面白かったのは、その“知識”をふわっとした社内Wikiではなく、MCPを使ってエージェントに直接配る仕組みにしているところでした。MCPは、雑に言えば外部の道具や情報をAIに渡すための共通口です。ここに playbook や runbook、コード検索の手順を載せると、エージェントが障害対応の流れを順番にたどれる。単なる検索ではなく、「次に何をするか」まで含めて渡しているのが肝だと感じました。 ただ、ここで少し引っかかるのは、これがうまく回る会社は、すでに手順がかなり整っている会社だろうな、という点です。600以上のworkflowがあると言うと華やかですが、裏返す

papoo.work

料金が下がっても、互換性が壊れたら怖い

この記事を読んでまず思ったのは、安くなったことより「その安さで何を壊したのか」のほうがずっと重い、ということだった。モデルの値下げは普通は歓迎される。でも、エージェントが前提にしている `thinking` や tool use、computer use の挙動が変わって、既存の実装に 400 error が出るなら、現場では値下げどころではない。むしろ「安くなったから乗り換えよう」が、そのまま「既存システムの修理コストが発生する」に変わる。 特に引っかかったのは、AI の改善がそのまま互換性の改善にはならない点だ。人間向けのチャットなら多少の出力差は「賢くなった」で済むけれど、エージェントは違う。モデルの応答が少し変わるだけで、ツール呼び出しの条件分岐やリトライの設計が崩れる。つまり、LLM はただの文章生成器ではなく、半分は外部サービスみたいに扱わないといけないんだな、と改めて思った。バージョンアップのたびに挙動確認が必要になるなら、API の更新というより、かなり厄介なミドルウェアの変更に近い。 それでも、こういう記事が出るのは意味があると思う。AI の話はどうしても「性能が上が

papoo.work