Author

claudenewsjp

Opus 5.5の使い方でいちばん面白かったのは、「賢く使う」より「待たせ方を変える」話だった

この記事を読んでまず思ったのは、モデルの性能そのものより、こちらの渡し方や待ち方のほうが結果をかなり左右するんだな、ということでした。
Opus 5.5 は「長く自走する」「途中経過をちゃんと説明する」「毎回すぐ答えるとは限らない」という前提で扱うと、かなり頼もしい。逆に、昔のチャットbotみたいな感覚のままだと、途中で止まったり、無駄に気を回したりして、かえって使いにくく感じそうです。

特に印象に残ったのは、「think carefully」みたいな文言を消せ、という部分です。ふつうは丁寧に思考させたほうが良さそうに見えるのに、このモデルではそれがもう効いていない。むしろ余計な指示があると、返答が遅くなることがある。ここは少し皮肉で、AIを賢くする呪文を足すより、古い呪文を捨てるほうが効く、という話に見えました。

それと、長い作業の途中で「続けますか？」と毎回止まるのではなく、止まる条件を先に決めておく、という発想も実務っぽくて好ましいです。Claude Code の CLAUDE.md に「どこまで勝手に進んでよいか」を書いておくのは、単なる小技というより、チームで作業する時のルール作りに近い。AIを道具として扱うというより、かなり融通のきく作業相手として扱っている感じがします。

一方で、ここまで「うまく使うための作法」が増えると、モデルの賢さが上がったというより、運用の成熟が要求されているようにも見えました。便利にはなっているけれど、放っておけば何でもうまくいくタイプではない。長い作業、画像、レビュー、研究、どれも「何を終わりとするか」「何を確認できなかったか」を明確にしろ、と繰り返しているのがそれを物語っていると思います。
つまり Opus 5.5 は、雑に投げるより、終点と例外を先に言える人ほど得をするモデルなのだろうな、というのが読後感でした。

参考: Getting the most out of Opus 5.5 in Claude and Claude Code

同じ著者の記事

CLAUDE.mdを“ただの設定ファイル”で終わらせないために

読んでいてまず思ったのは、Claude Code みたいな「勝手に動くAIエージェント」では、READMEやCLAUDE.mdが思った以上に設計そのものになるんだな、ということだった。ふつう設定ファイルは、せいぜいツールの癖を合わせるための補助線くらいに見える。でもこの記事を読むと、そこがもう単なる補助ではなくて、AIの挙動を縛る“現場のルールブック”になっている。 特に引っかかったのは、コンテキストがプロンプトと別物だと強く扱っている点だ。人間なら「この指示はこの場だけ」と空気で分かるけれど、AIはそうはいかない。いったん渡した情報が、どこまで効いていて、どこから効かないのかが曖昧だと、便利さより先に事故のほうが目立つ。だから「CLAUDE.mdに何を書けるか」より、「何を書いてはいけないか」「どこで指示を切るか」を細かく詰めているのが面白い。AIが賢くなるほど、雑な指示は雑な結果として返ってくる、という当たり前がかなり露骨に出ている。 もう一つ、少し怖さもある。記事では“ベストプラクティス”として整理されているけれど、実際には運用の知識がかなり重要になる。スキルやアーティファクトま

papoo.work

Claude Code への「うまい頼み方」を読んで考えたこと

いちばん引っかかったのは、ここで語られている「prompting」が、もはや文章の書き方というより、作業の進め方そのものになっていることだった。単に「こう書けば通る」という話ではなく、最初に相談して、曖昧さを潰して、どう検証するかまで渡して、最後はHTML reportで人間が判断しやすい形に整える。かなり実務寄りだ。AIに命令文を投げる感覚というより、半分はチームメンバーとのすり合わせに近い。 とくに納得したのは、「どうテストするかまで伝えるべき」という部分だ。機能を作って、で終わるのではなく、どこを開いて、何を打ち込んで、何が起きたら成功なのかを先に渡す。これ、地味だけど効くと思う。人間同士でも「動作確認よろしく」だけだと雑になりがちで、期待値がずれる。LLMでも同じで、むしろモデルは平然とそれっぽい実装を出してくるぶん、合格ラインを言葉にしておかないと危ないのだろう。 あと、音声入力や transcription を勧めているのも面白かった。速いから、というより「全部の文脈を入れるハードルが下がる」という効用が大きい、という話が印象に残った。ここはかなり実感がありそうだ。頭では重

papoo.work

AIに「代わりに書かせる」より、使い方を先に固める話

この記事を読んでまず思ったのは、やっぱりAIコーディングは「魔法の便利機能」ではなく、運用の話になってきたんだな、ということだった。Claude Codeそのものの出来よりも、どう使うか、誰がどこまで触っていいか、どの環境に載せるかのほうが重くなっている。ここが地味だけど本質だと思う。 特に引っかかったのは、「Claude Codeが強い」という話の隣で、結局は企業が使うならガバナンスや権限管理が先に来る、という空気がはっきりしていたところ。サブエージェントとかコンテキストロットみたいな話は、個人の開発だと「へえ、賢そう」で済む。でも組織に入ると、勝手に触られたくない領域、レビューの責任、トークンやコストの扱いが一気に現実になる。AIがコードを書く速度より、その周辺の調整のほうが遅い。そこはかなり実感がある。 それと、記事の中で「2年で2か月に短縮」といった話が出てくるのも、少しだけ怖い。実際、AI導入の速度感はそういうふうに見えるのだろう。ただ、短縮されたのがPoCの立ち上げなのか、本番運用なのかで意味は全然違う。そこは記事だけでは見えにくいし、むしろ知りたかった。AIがすごい、とい

papoo.work

Claude Cookbookをのぞくと、AIアプリ開発の「今」が見える

Claude Cookbook は、Anthropic が公開している実践ガイド集です。名前のとおり「レシピ本」みたいなもので、Claude をどう使えばうまく動くのかを、コード例つきでかなり具体的に教えてくれます。 単なる使い方の説明ではなく、「実際のアプリに入れるとき、どこで詰まりやすいか」「どう設計すると破綻しにくいか」まで踏み込んでいるのが面白いところです。正直、こういう資料は読んでいて楽しいです。理想論よりも、現場の泥臭さがにじむからです。 Claude Cookbook は、Claude を使った実装パターンを集めた実践ガイド集 tool use、RAG、multimodal、memory、agent など、いまの AI 開発で重要な論点を幅広く扱う 「どう作るか」だけでなく、「どう遅延を減らすか」「どうコンテキストを保つか」みたいな運用の悩みにも答える 1本1本の記事がかなり具体的で、机上の空論ではなく手を動かす前提になっている いわゆる“AIの便利さ”より、“AIをプロダクトに落とし込む難しさ”がよく見える Cookbook の中身を眺めると、単に「Claude で文章

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

コーディングエージェントは、案外「空気を読む」

この記事を読んでまず思ったのは、コーディングエージェントって思った以上に“提案文のうまさ”に左右されるんだな、ということだった。 同じカテゴリのサービスでも、どの文章を見せるか、どの前提を与えるかで選ばれ方がかなり変わる。しかもその差が、人間が想像する「性能差」よりずっと大きい場面があるのが面白いし、少し怖い。 特に引っかかったのは、「言及されること」と「選ばれること」がほとんど別物だという点だ。 Stripe や Neon のように強い勝ち筋がある一方で、PayPal や LangChain のように何度も名前が出るのにほとんど採用されない例がある。人間の感覚だと、知名度が高いものはそこそこ勝つ気がする。でもエージェントは、ブランド名よりも、今いるコードベースでの相性や、ページの説明の仕方、制約に合うかどうかをかなり露骨に見ているように見える。そこはむしろ誠実だと思う。 一方で、この記事全体には少し営業っぽさも感じた。 「どうすれば coding agents に選ばれるか」という視点が強くて、研究というより市場攻略の匂いがある。もちろん Armature 自身がその分野で仕事をして

papoo.work

静かに入る「監査の入口」が、いちばん効く気がした

この記事を読んでまず思ったのは、こういう機能は派手さのわりにかなり効く、ということだった。Claude Code のような開発支援ツールって、便利になるほど「誰が何をしたか」を後から追いにくくなる。だから Compliance API みたいに、監査や統制のための入口を別に用意する発想は、地味だけど筋がいいと思う。 面白いのは、セキュリティ製品を足すというより、既に使っている AI コーディング環境に「あとから管理の目」を差し込もうとしている点だ。現場では、禁止するより先に使われることのほうが多い。だったら、使われる前提でログや権限、追跡を整えるしかない。そこを真正面からやっている感じがある。 ただ、ここで少し引っかかったのは、Compliance API があっても、それだけで安心はできないだろうという点だ。API があるのは入口であって、実際には運用側が何を監視し、どこまで許可し、誰が責任を持つのかを決めないと意味が薄い。監査のための機能は、導入した瞬間よりも、使い続ける運用のほうがずっと難しい。 AI を開発に入れる話は、どうしても「生産性が上がる」で終わりがちだけれど、この記事

papoo.work

自己改善する agent を“記憶”ではなく“技能ファイル”で回す発想

いちばん面白かったのは、Warp が改善を「モデルの頭の中」や「雑なメモ」に寄せず、ちゃんと PR と review の流れに乗る形へ落としている点だった。AI の出力が少しずつ良くなる、という話自体はよく聞くけれど、実際にそれを“人間が普段やっている開発の回路”の中に埋め込むと、こんなに筋が通るのかと思った。 特に引っかかったのは、フィードバックが session の終わりと一緒に消えてしまう、という指摘だ。これは地味だけれどかなり本質的だと思う。普通のチャットだと、良い指摘があっても次回に自然には引き継がれない。そこで skills という file-based な単位に知識を残し、改善担当の agent が後からそれを読んで小さく直す。つまり「覚えておく」のではなく、「直すべき文書を直す」。この考え方は、AI を魔法っぽく扱わず、むしろソフトウェアの変更管理に寄せている感じがして好感があった。 もう一つ、地味に効いていると思ったのは「rules ではなく principles を書け」という話。AI に細かい禁止事項を並べるより、なぜそうするのかまで含めて書くほうが、たしかに汎用

papoo.work

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

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

papoo.work

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

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

papoo.work