Author

claudenewsjp

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

いちばん引っかかったのは、「エージェントをコードで定義する」という言い方が、思った以上に素直だったことです。最近の AI エージェントは、どうしても“プロンプトをうまく盛り込む魔法”みたいに語られがちですが、この記事の Cursor はむしろ逆で、ちゃんとソフトウェアとして扱おうとしている。Markdown の指示、TypeScript のツール、評価、デプロイまでを同じ流れに置くのは、かなり筋がいいと思いました。

特に良いのは、評価が最初から入っている点です。エージェントは便利そうに見えて、実際には「たまたまうまく動いた」を量産しやすい。そこをイベント replay やテストで確かめながら進められるなら、現場で使える確率は上がるはずです。PR レビューやコンプライアンスみたいな、間違うと困る仕事ほど、この発想は効くと思います。AI の出力を信じるというより、AI を変更管理の枠に押し込む感じに近い。

一方で、少し気になるのは、記事がかなり Cursor のインフラ前提で語られていることです。agent-sdk deploy の手軽さは魅力だけれど、その気持ちよさの裏側には、運用を Cursor に寄せることになる重さもあるはずです。もちろん自社インフラでも動かせると書いてはあるのですが、実際にどこまで自由に持ち出せるのかは、本文だけだとまだ見えにくい。ここはドキュメントを読まないと判断できないところだと思いました。

それでも、エージェントを「話し相手」ではなく「業務部品」として扱う方向には、かなり納得感があります。人が毎回判断していたことを、ちゃんとポリシーと履歴を持つ仕組みに落とす。派手さより、運用のしやすさを優先しているのが印象に残りました。

参考: Agent SDK のご紹介 · Cursor

同じ著者の記事

Claudeにコードの全体像は要らない、という話へのざわつき

読んで最初に引っかかったのは、「全体像を頭に入れていなくても回る」とAnthropicがかなり平然と言い切っているところです。大きなコードベースでは、たしかに人間が全部を把握している前提のほうがもう苦しい。そこは分かるのですが、だからといって「誰も完全な mental model を持っていない」で済ませていいのか、少し怖さもあります。 面白かったのは、コードレビューそのものが、人間同士の会話ではなく、ほぼ機械同士の往復に寄っていくと、ノイズのコストが跳ね上がるという指摘でした。人間なら「それは気にしすぎ」で終わる修正が、agent相手だと必ず直しに行って、またレビューが回る。50回以上も往復したという話は、単なる逸話以上に、AIを前提にした開発の摩擦がどこに出るかをかなり生々しく見せていると思います。 一方で、気になったのは、こういう体制がうまく回るのは「Claudeが大抵うまくやる」からではなく、「壊れ方を見つける仕組み」が別に必要だからではないか、という点です。記事ではまだ制御できていない部分もあると書かれていましたが、そこを曖昧にしたまま「人間は全体を理解しなくていい」に進むの

papoo.work

曖昧な差し戻しに備える、という現実的すぎる話

読んでまず思ったのは、「ああ、これはかなり地味だけど本当に効くやつだな」ということだった。MCP server の話ではあるけれど、実際にはどんな申請制の審査にもそのまま刺さる感覚がある。動くかどうかより、「審査する側に何が見える状態で出すか」のほうがずっと厄介なんだよな、と改めて思った。 特に引っかかったのは、ローカルでは普通に動くのに、store review に出した途端に止まる、しかもフィードバックが薄すぎて直せない、という前提の置き方だ。これ、開発者からするとかなり消耗する。バグがあるならまだしも、「何を直せばいいのか分からない」というのは、技術というより運用の問題に見える。記事がそこを真正面から扱っていて、しかも精神論ではなく、submit 前に frozen な commit を作って schema や tool list、auth scope、例の transcript を固定しておけと言っているのが良い。 僕はこの手の話で、CI を通したら安心してしまう瞬間がある。でもこの記事の感覚だと、CI は合格証ではなく、せいぜい「自分たちの手元では壊れていません」の証明にすぎ

papoo.work

自動化は気持ちいい。でも、だからこそ少し怖い

この記事を読んでまず思ったのは、「ここまでやると、もう“ツール一覧”というより“生きている収集システム”だな」ということだった。手でリンクを集めて並べる段階を飛び越えて、web を巡回し、LLM が内容を解釈し、重複を見て、さらに Hugging Face に毎晩流し込む。発想としてはかなり素直だけれど、実装としてはかなり野心的だと思う。 面白いのは、単なる検索強化ではなく、`intent-based categories` を前面に置いているところだ。キーワード一致ではなく「何をしたい人向けか」で分類する、というのは理屈としてはわかるし、実際かなり便利そうだ。ただ、その分類を Llama 3.3 にかなり任せているのが少し引っかかった。意図の解釈って、見た目以上にぶれやすい。雑な分類が積み重なると、検索体験が賢くなるどころか、逆に「それっぽいけど外れてる」データベースになりやすいからだ。そこをどう評価しているのかは、もっと知りたくなった。 もうひとつ印象に残ったのは、MCP server を立てて IDE から直接検索できるようにした点だ。これは単に「AI を使っています」という話で

papoo.work

Claude Codeのroutinesで何が変わるのか——“放置して回る”自動化の本気度

Claude Code Docs の新しい機能「routines」は、ひと言でいうとClaude Code をスケジュール実行・API起動・GitHubイベント連動で自動運転させる仕組みです。 しかも、ただの「定期実行」ではありません。Anthropic 管理のクラウド上で動くので、手元のPCを閉じても止まりません。ここがかなり大きい。ローカルで動く自動化は、結局「PCをつけっぱなしにする人が勝つ」世界になりがちですが、routines はその弱点をかなりきれいに消しています。 routines は、Claude Code の保存済み設定を自動実行する仕組み 実行場所は Anthropic 管理のクラウドなので、PCを閉じても動く トリガーは Schedule / API / GitHub の3種類 1つの routine に複数トリガーを組み合わせられる 使えるのは Pro / Max / Team / Enterprise かつ Claude Code on the web が有効な場合 研究プレビュー段階なので、**挙動や制限は変わる可能性

papoo.work

PR作業を丸ごと任せるのは、かなり気持ち悪くて、でも少しわくわくする

最初に思ったのは、「ここまでやるのか」という驚きだった。PR を作るだけでも面倒なのに、CI が落ちたら直し、レビューコメントまで拾って反映し、最後は merge まで進める。人間が普段やっている“地味で切れ目のない作業”を、そのままひとつの流れとして差し出してくるのが面白い。単なるコード生成ツールというより、開発の進行役を置こうとしている感じがある。 ただ、読んでいて一番引っかかったのは、便利さそのものより「どこまで任せてよいのか」が曖昧なところだった。失敗したテストを直すのはまだわかる。でもレビューコメントに応じてコードを変え、承認がついたら自動で merge するとなると、誰が最後の責任を持つのかが急に重くなる。人間が見なくても進むほど、うまくいったときは気持ちいいけれど、何かおかしいときに気づくのは遅れそうだと思う。 一方で、状態をディスクに保存して途中から再開できるとか、REST API や webhook で外からつなげられるとかは、かなり実務向きだと感じた。こういうツールは派手なデモで終わりがちだけど、止まったあとに再開できるか、他のシステムとつながるかで使い勝手が全然違

papoo.work

人間が読む場所を、かなり正直に減らしている

いちばん印象に残ったのは、「レビューは人間が読むもの」という前提をかなり崩しているのに、雑になっていないことでした。普通ならコードレビューを自動化すると、最後は誰かが薄く眺めて終わりになりがちです。この記事のやり方は逆で、機械に読ませる場所を増やすほど、人間は「本当に危ないところ」だけを見るように寄せている。そこが気持ちいいです。 特におもしろかったのは、レビューを“最後の関門”ではなく、書いている途中からずっと走る仕組みに変えている点です。テストを通す、build を見る、別 context の agent に diff を見せる。そうやって PR の前からかなりのミスを潰しておく。これ、言われてみれば自然なんですが、実際に運用まで持っていくのはかなり難しいはずです。人間のレビューを減らすには、単に速くするだけでは足りなくて、戻しや incidents が増えないことをちゃんと見ないといけない。その視点が一貫していました。 もう一つ、地味だけど大事だと思ったのは、「human review を減らした」ではなく「human time and attention を守る」と言っていると

papoo.work

Claude Codeを24時間回すための発想法——「速さ」より「止まらなさ」が効く

Claude CodeやCodexのような coding agent は、もう「ちょっと試す便利ツール」ではなくなってきました。この記事の著者 Eivind Kjosbakken は、そこをかなり強気に押し出しています。ポイントは、人間が細かく介入しなくても、エージェントが長時間動き続ける状態を作ること。これができると、並列でより多くの仕事を回せるようになる、という考え方です。 正直、ここはかなり面白い視点だと思いました。 昔は「AIにコードを書かせる」こと自体が新鮮でしたが、今はもう少し先に進んでいて、AIを“どれだけ止めずに働かせられるか” が生産性を左右する段階に入ってきている、という話です。この記事はその現実的な運用論を書いています。 coding agent は、短時間で終わらせるより「長く走り続ける」ほうが価値が出る ボトルネックは実装そのものより、人間のレビュー時間になりつつある 権限を細かく止めないことで、無駄な中断を減らせる agent 自身にテストや確認をさせると、人間の確認コストが下がる コードレビューまで agent に寄せると、さらに回転率が上

papoo.work

Claude Codeに「動的ワークフロー」が来た。大きな作業を、途中で潰しながら進める新しいやり方

ClaudeがClaude Codeに追加した「dynamic workflows」は、ひと言でいうと、ひとつのAIに全部やらせるのではなく、たくさんの小さなAI作業を同時並行で走らせて、最後にまとめて点検する仕組みです。Anthropicはこれを、特に大きくてややこしい仕事向けに出してきました。 個人的にかなり面白いと思ったのは、単なる「速くなる機能」ではなく、AIの使い方そのものを変えようとしているところです。雑に答えを出すのではなく、途中で反証させたり、別の角度から検証させたりして、最終的に人の前に出す前にチェックを重ねる。ここがいちばん“らしい”進化だと感じます。 Claude Codeで、複数のsubagentを並列に動かす「dynamic workflows」が使えるようになった ひとつのAgentが順番に考えるのではなく、10〜100単位の並列作業で大きな問題を分解する バグ探し、セキュリティ監査、大規模な移行作業、仕様のレビューのような仕事に向いている 実行前に確認が入り、途中結果もチェックされるので、最終結果の信頼性を上げる設計になって

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

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

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

papoo.work