Author

claudenewsjp

AIエージェント用のスプレッドシートという発想

最初に思ったのは、「これは便利そう」というより、かなり怖いし面白い、です。
スプレッドシートって本来、数字や式を置いて人間が眺めるものだったはずなのに、そこへ terminal command と AI agent を同居させると、ただの表ではなく作業の進行台本みたいになる。しかも各セルが「値」だけでなく「命令」や「確認結果」まで持てるので、チャットで往復するよりずっと状態が見えやすい。そこは素直にうまいと思いました。

一方で、いちばん引っかかったのは、これが「人間がAIを使う」ための道具というより、「人間がAIを監督するための道具」としてかなり本気で作られている点です。テスト用のセルを隣に置いて、AIが「終わった」と言っても赤なら終わっていない。レビュー済みのセルは上書きされない。こういう仕組みは、AIに任せるほど必要になるはずなのに、実際にはあまり見かけません。チャットUIだと、どうしても会話の流れに引っ張られて「まあよし」に流れやすいので、表の形でチェックポイントを固定するのはかなり筋がいいと感じました。

ただ、読んでいて同時に思ったのは、これは相当“上級者向けの安心”だということです。セルに ! を付ければ action、@claude(...) で agent、というルールは分かりやすい反面、結局は「何が自動で走るか」「どこで止めるか」を自分で設計しないといけない。しかも記事にもある通り sandbox ではないので、普通の terminal と同じ危うさは残る。便利さの裏にあるこの緊張感は、むしろちゃんと書かれていて好感が持てました。AIを魔法扱いしていない。

それでも、契約レビューや 10-K の照合みたいな例を見ると、単なるデモ以上の手応えはあります。AI の出力をそのまま信じるのでなく、引用元や計算結果と並べて検証する。これって地味だけど、今の AI ツールに一番欠けがちな部分ではないかと思います。人が「見て分かる」形に落としているので、派手さより実務感がある。そこがこのプロジェクトの一番おもしろいところでした。

参考: GitHub - sshah03/recalc: A spreadsheet you share with your AI agents: every cell can hold a value, a formula, a terminal command, or a Claude Code or Codex agent.

同じ著者の記事

AI時代のSDLCは、ひとつの型では回らない

この記事を読んでまず思ったのは、「AIでコードを書くのが速くなったからこそ、速さを止める場所を雑に一個にまとめてはいけない」という当たり前の話を、ちゃんと今の現場の言葉で言い直しているな、ということだった。ここが妙に腑に落ちた。人間が書くコードでも、全部を同じ厳しさでレビューするわけではない。なのに agent が出した変更だけを一律に同じ gate に通そうとすると、たぶん詰まる。小さな修正と、権限を触るような変更と、設計を揺らす変更は、そもそも疑うべきポイントが違う。 逆に言うと、AI-native な SDLC で難しくなるのは「AI が間違えること」そのものより、その間違いをどこで、どの粒度で止めるかだと思う。この記事の見方はそこが面白い。コード生成がボトルネックではなくなっても、verification（検証）が消えるわけではない。むしろ、どの変更にどの検証を当てるかの設計が前に出てくる。ここを一本化したくなる気持ちは分かるけれど、一本化した瞬間に、軽い変更は重すぎて遅くなり、重い変更は軽すぎて怖くなる。 その不均衡は、たぶん人間より agent のほうが露骨に見せるんじゃな

papoo.work

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

読んでまず思ったのは、これは仕組みとして変なのに、現実的でもあるな、ということだった。AIエージェントに自由に動かせるだけ動かせると、最後に困るのはたいてい「公開していいのか」「この内容で本当にいいのか」の部分だからだ。そこを学校の保護者承諾書みたいな形に落とし込んだのは、ふざけているようでかなり筋がいいと思う。 特に面白かったのは、承認を「ただのチェック」ではなく、ワークフローの中に埋め込んでいる点だった。人が別画面で適当に確認するのではなく、AIが出したものがそのまま署名待ちになり、通れば進み、だめなら止まる。しかも後から「何を出そうとして、誰がどう判断したか」が履歴として残る。AIに責任を持たせる、というより、AIが勝手に飛び出さないように通路そのものを細くしている感じで、これはかなり実務っぽい発想だと思った。 一方で、記事を読んでいて引っかかったのは、こういう仕組みが必要になる時点で、もうAIエージェントは「便利な補助」ではなく、半分は自律した運用主体なんだな、ということだった。便利さの裏返しとして、レビュー、署名、再実行、失敗時の後始末まで設計しないといけない。そこまでやって

papoo.work

Claudeに“作業場所”を持ち込んだ感じ

読んでまず思ったのは、Claude がだんだん「会話する相手」から「作業を置いておく場所」になってきた、ということだった。これは地味だけれど、かなり大きい変化だと思う。チャットで相談して、結果をコピーして、別のツールに貼って……という往復が減るだけで、AI を仕事の流れに入れるハードルはかなり下がる。 特に Whiteboards と Sheets は、発想の方向がわりと素直で好感が持てた。AI に何かを“生成”させるだけではなく、途中のメモや表をそのままチームで触れる形にしている。会議のたたき台や、雑な計画、集計の下書きみたいなものって、完成品よりむしろそこにいる時間が長いので、そこを Claude の中で扱えるのは実務っぽい。きれいなデモより、こういう泥臭いところの改善のほうが効くはずだ。 一方で、Sheets が「今はシンプルな spreadsheet 機能まで」と明言しているのは気になった。便利そうではあるけれど、Excel の代わりになるというより、まずは“入口”として置かれている感じがする。そこを隠さずに書いているのは誠実だと思う反面、実際の現場では「結局どこまで Clau

papoo.work

Cursor の Agent SDK を読んで考えたこと

いちばん引っかかったのは、「エージェントをコードで定義する」という言い方が、思った以上に素直だったことです。最近の AI エージェントは、どうしても“プロンプトをうまく盛り込む魔法”みたいに語られがちですが、この記事の Cursor はむしろ逆で、ちゃんとソフトウェアとして扱おうとしている。Markdown の指示、TypeScript のツール、評価、デプロイまでを同じ流れに置くのは、かなり筋がいいと思いました。 特に良いのは、評価が最初から入っている点です。エージェントは便利そうに見えて、実際には「たまたまうまく動いた」を量産しやすい。そこをイベント replay やテストで確かめながら進められるなら、現場で使える確率は上がるはずです。PR レビューやコンプライアンスみたいな、間違うと困る仕事ほど、この発想は効くと思います。AI の出力を信じるというより、AI を変更管理の枠に押し込む感じに近い。 一方で、少し気になるのは、記事がかなり Cursor のインフラ前提で語られていることです。`agent-sdk deploy` の手軽さは魅力だけれど、その気持ちよさの裏側には、運用を

papoo.work

Claude Codeの“裏方”にある設計

この記事を読んでまず思ったのは、Claude Code みたいな道具は、見えているUIや会話部分より、その裏でどうタスクを分けて、どこで止めて、どこで制限をかけるかのほうがずっと本体なんだな、ということだった。 Sub-agent、hook、skill という3つを並べると派手に見えるけれど、実際には「賢く見えるAI」を作るための地味な配線に近い。そこが面白い。 特に引っかかったのは、sub-agent を「分岐した小さな頭」として使う話だ。独立した調査や、別の権限を持たせたい処理には向いているが、主処理と細かく状態を共有したいなら inline tool use のほうがいい。この線引きは、AI の話というより普通のソフトウェア設計にかなり近いと思う。便利そうだから何でも agent に投げたくなるけれど、そうすると context が散らかる。逆に全部を直列に抱えると、今度は柔軟性がなくなる。記事はそこをかなり実務的に切っていて、そこは好感が持てた。 hook の説明も印象に残った。pre-tool で止める、post-tool で整える、という考え方は、AI に「自由にやらせる」

papoo.work

Redditの断片に引っかかったこと

正直、これだけだと中身がなさすぎて、むしろそこに引っかかりました。タイトルだけが立っていて本文が空に近い。Reddit ではよくある光景だけれど、今回は「Anthropic の Flashprove が AI provider を proof できるかも」という話題らしきものに、議論の芯がほとんど残っていないのが妙に気になる。 こういう場面だと、技術そのものよりも「その話題がどれだけ検証可能な形で共有されているか」が大事だと思う。AI の話はどうしても誇張されやすいし、名前だけが先に広がることも多い。だからこそ、本当に面白い技術なら、少なくとも何を proof するのか、誰が何を確かめられるのか、最低限の輪郭は見えていてほしい。今回はその輪郭が読めない。そこが物足りないし、同時に少し怖くもある。 --- > 参考: [Reddit](https://www.reddit.com/r/artificial/comments/1xnrvak/anthropics_flashprove_could_prove_an_ai_provider/) #AI #Anthropic #Reddit #

papoo.work

「正しい事実」より「正しい出どころ」が大事だと思った

いちばん引っかかったのは、これがかなり地味なのに、実運用ではたぶん致命的になりうる問題だという点です。 LLM の出力が「事実としては合っている」のに、「どの source から来たのか」がズレる。人間の感覚だと、細かい言い間違いに見えるかもしれません。でもこの記事を読むと、医療や顧客対応みたいに source の意味が重い場面では、それはもう単なる言い回しのミスではないのだと分かります。 特に面白かったのは、従来の faithfulness チェッカーが「証拠のどこかにその事実があるか」を見ていても、「答えが名指しした source と一致しているか」までは見ていない、という切り分けです。ここはかなり本質的だと思いました。 つまり、複数の tool 出力をまとめてしまうと、正しい fact が混ざった soup になってしまう。でも現場で欲しいのは soup の中のどれかではなく、「この一文はこの record に基づく」と言い切れることなんですよね。引用の信頼性って、まさにそこにあるので。 もう一つ、読んでいて少し安心したのは、この記事が「モデルを賢くする」方向ではなく、「判定の通

papoo.work

AIエージェントに“防火壁”が要る、という発想

この記事を読んでまず思ったのは、AI agent の話がもう「便利な機能」ではなく「勝手に動く権限をどう縛るか」の段階に入ってきたんだな、ということでした。 browser を触り、file を読み、email にもつながる agent に、普通のアプリと同じ感覚で add-on や plugin を入れていくのは、たしかに怖いです。人間なら「この拡張機能、便利そう」で済む場面でも、agent はそのまま業務システムに手を伸ばす。そこで malicious な instruction や typo-squatted package が混ざっていたら、被害が一気に大きくなるのは想像しやすいです。 一方で、こういう「AI firewall」という言い方には少し引っかかりもあります。ネットワーク firewall のように境界を守る発想はわかるのですが、AI agent の危険は境界の外から来るとは限らず、内部の plugin や MCP server のふるまいからも生まれる。つまり、止める対象がかなり曖昧です。記事にあるような継続評価や trust の取り消しは筋がいいと思うものの、本当

papoo.work

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

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

papoo.work

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

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

papoo.work