#開発効率

まず思ったのは、こういうのは「賢い自動化」というより、かなり地道な整理術なんだな、ということだった。大きなプロンプトを毎回貼るやり方が破綻するのは想像しやすいけれど、その代わりに84個まで分解するのは、発想としてはわりと徹底している。AIに何でも覚えさせるのではなく、必要な文脈だけを都度差し込む、という考え方は筋がいいと思う。 特に引っかかったのは、ここでやっていることが単なる「プロンプトのテンプレ化」ではない点だ。技能ごとに切り分けて、トリガーに応じて読み込ませる。要するに、長い指示文を一枚岩で持つのをやめて、作業単位で知識を分割している。人間の作業メモでも、巨大な一枚の資料より、用途別の短い手順書のほうが使いやすいことが多い。AI相手でも同じなんだろう、と思わされた。 一方で、ここまで細かく分ける運用は、作る側のメンテナンスがかなり大変そうでもある。84個という数字はインパクトがあるけれど、そのまま真似すると管理コストのほうが先に効いてきそうだ。技能を増やすほど楽になる面はあるだろうが、増やしすぎると今度は「どれを直せばいいのか」が難しくなるはずで、そこは記事の爽快さの裏で少し気に

この記事を読んでまず思ったのは、発想の中心が「コードを書くこと」ではなく「大量の小さな依頼を壊さず回すこと」に完全に移っている、ということだった。そこが面白い。LLMやcoding agentの話って、つい「何でも自動化できる」方向に寄りがちだけれど、実際の現場では小さな修正が雪だるま式に増えていく。しかも、その一つ一つが地味にあいまいで、雑に投げると別の場所まで触られる。この記事はそこをかなり正直に見ている。 特に腑に落ちたのは、全部を一つのセッションに押し込まない判断だ。コンテキストが長くなると、モデルは当然つらくなるし、人間側も何がどこで決まったか追いにくくなる。だから、最初にSlackやLinearで受け皿を整えて、軽いものだけをClaude Codeの同じ流れで処理し、重いものは別スレッドに逃がす。これは派手さはないけれど、現実的だと思う。AIを入れた瞬間に「全部速くなる」はず、ではなくて、むしろ受付・仕分け・確認の設計がないと詰まる、という話に見えた。 もう一つ印象に残ったのは、HTML reportを何度も挟むところだ。人間が確認しやすい形にわざわざ整えるのは、少し回り道

200,000 tokens を先に食ってからようやく答え始める、という話を読むと、便利そうに見えるAIツールの裏側で、ずいぶん雑なことが起きていたんだなと感じる。人間なら「資料が多いから少し重い」で済む場面でも、LLM だとその「少し重い」がそのままコストと待ち時間に跳ねる。しかも利用者から見えにくい形で起きていたのが、かなり気持ち悪い。 いちばん引っかかったのは、問題が“賢さ”ではなく“読み込み方”にあったことだと思う。Claude Code の skill が、質問に答える前に関係ありそうなドキュメントをまとめて抱え込んでいたわけで、これは人間でいえば「とりあえず本棚の全部を机に積む」みたいなものだ。実際の作業では、必要なページを必要なときに開けばいい。そこを on-demand に変えて 25K まで落とした、というのはかなり素直な改善に見える。 ただ、ここで終わらないのも面白い。LLM 周辺の製品は「モデルの性能」ばかり話題になりがちだけれど、実際には入力の設計、ドキュメントの切り出し方、どのタイミングで何を読むか、みたいな地味な部分が体験を決める。今回の話は、その地味な部分

最初に思ったのは、「これ、便利だけど境界がかなり繊細だな」ということだった。 Claude Code が別のセッションへメッセージを飛ばせる、という発想自体はわかりやすい。長い migration を別端末で回していて、片方で見つけたことをもう片方に渡したい。並列で worktree を触っていると、いちいち人間がコピペで中継するのは正直つらい。そこを AI 同士でつなぐのはかなり筋がいいと思う。 ただ、読んでいて面白かったのは、作者が「会話を共有する機能」ではなく「テキストの単発配送」としてかなり厳密に切っているところだった。履歴もファイルも渡さない。あくまで一文のメッセージだけ。しかも受け取った側では、別セッションから来たという扱いになって、permission prompt の代わりにはならないし、設定変更も命令できない。ここはかなり重要で、便利さを足しつつも「他人の承認を勝手に流用しない」線を引いている。雑に作るとすぐ危ない機能だから、こういう制限はむしろ安心材料だと思った。 もう一つ引っかかったのは、同じ「メッセージ」と言っても、ローカルでは直接 socket で飛ぶのに、別

最初に思ったのは、これはわりと当たり前のことを、ちゃんと実務の形に落とし込んだ話だな、ということでした。AIを1回ずつ順番に使うと、待ち時間も文脈の肥大化も避けにくい。人間の作業でも、調べもの、実装、テスト、レビューを同じ人が全部抱えると遅くなるのと同じで、AIにも役割分担をさせたほうが自然です。 面白いのは、この記事が「すごい裏技」というより、「Claude Codeをちゃんとチームっぽく扱え」という発想を押し出しているところです。サブエージェントという言い方をしているけれど、要するに小さな専門家を複数走らせる感じで、これはかなり腑に落ちました。コンテキストウィンドウ、つまりAIが一度に覚えていられる範囲が広がるほど雑になる、という感覚は使っていると身に覚えがあります。長いやり取りのあとに急に浅くなること、ありますよね。 一方で、そこまで万能でもないのも正直だと思いました。トークンコストが増える、独立した作業にしか向かない、という線引きがちゃんと書かれているのがよかったです。ここを曖昧にすると「なんでも並列化すれば速い」と勘違いしがちですが、実際はむしろ逆で、依存関係がある仕事まで分

最初に思ったのは、「AIを賢くする話というより、AIの暴走をどこで止めるかの話なんだな」ということだった。ここが面白い。ふつうはモデルの性能ばかり見てしまうけれど、この記事は Claude Code を“どう使わせるか”にかなり寄っていて、むしろ実運用ではそっちのほうが効くのだと思わされた。 とくに、CLAUDE.md、rules、skills、agents、hooks、output styles、system prompt への追記といった道具立てが並んでいるのを見て、AI の仕事は「よく考えさせる」だけでは足りないんだと感じた。人間の開発でも、優秀な人に口頭でお願いするだけでは品質が揃わない。手順書があり、禁止事項があり、レビューの観点があり、例外処理がある。Claude Code も、結局はその延長線上に置かれている。AI なのに、かなり地味なガードレール設計が主役になっているのが妙に現実的だった。 一方で、少し引っかかったのは、これだけ細かく分けても、現場の人が本当に運用しきれるのかという点だ。設定項目が増えるほど制御は効くけれど、そのぶん「どこに何を書けばいいのか」を覚えるコ