#プロンプト設計

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

この記事を読んでまず思ったのは、便利な抽象化って、たいてい裏で何かを盛大に燃やしているんだな、ということだった。MCPは「AIに外部ツールをつなぐ標準」としてかなり筋がいい発想に見えるけれど、その代償として、JSON schema を毎回モデルに食わせるコストがこんなに大きいのは、正直かなり嫌な現実だと思う。 特に引っかかったのは、使い始める前の時点で 91K tokens 近く飛ぶという話だ。ツールを1回も使っていないのに、まず「どんな道具があるか」を説明するためのJSONだけで会話予算が削られる。しかもその説明が会話ごとに繰り返されるなら、賢いはずの仕組みが、かなり雑に燃費を悪くしている感じがする。AIにツールを渡す設計なのに、ツール一覧そのものが重荷になっているのは皮肉がある。 もう一つ面白かったのは、著者がそこを「愚痴」で終わらせず、圧縮用のプロキシを作っているところだった。TOONみたいな表現に変えて、冗長なJSONを削る。発想としてはかなりまっとうで、こういう地味な改善が実際の使用感を大きく変えるんだろうなと思う。LLMまわりって派手なモデル性能の話

この記事を読んでまず思ったのは、コードを書く速さそのものより、「何を作るつもりなのか」を毎回ちゃんとすり合わせるほうが、今の開発ではむしろ主戦場になってきているんだな、ということでした。Claude Code みたいな coding agent は、雑に言えば“手は速いけど、前提がずれると一気に遠回りになる”存在です。そこをかなり実感のある話として書いていて、そこは素直にうなずきました。 特に引っかかったのは、著者が繰り返し強調している「is my understanding correct?」です。これ、ただの確認文に見えるのに、実際はかなり強い型なんだと思います。人間同士の会話でも、相手に「自分の理解を言い直させる」とズレが見えますが、それを coding agent 相手に、しかも開発の途中で何度もやる。そうすると、説明する側が人間ではなく agent になり、しかも毎回“自分の理解”を検査できる。これは地味だけど効きそうです。 一方で、少し面白かったのは、この記事が「AI に任せれば楽になる」ではなく、「AI が速くなったぶん、こちらの認識の粗さが露出する」と書いているところで

Claudeの開発チームが、Claude Codeのsystem promptを80%以上削った、と聞くと少し驚きます。 ふつうは「安全のためにルールを増やす」方向に行きがちだからです。でもこの記事は、その逆をやっている。モデルが賢くなったなら、人間側が細かく縛りすぎないほうがいい——そんな発想の転換をかなりはっきり示しています。 Claude 5世代では、細かい禁止ルールより「状況に応じた判断」を重視している promptだけでなく、system prompt、Skills、CLAUDE.md、memory などを含めた「context engineering」が重要 以前は有効だった定石が、今はむしろ足かせになっている 例をたくさん与えるより、toolやfileの設計を良くするほうが効く 情報は全部を最初に詰め込まず、必要になったら読み込む「progressive disclosure」が強い CLAUDE.mdやSkillsは「何でも入れる倉庫」ではなく、必要時に開く案内板として考えるべき 参考資料も、単純なmarkdownよりHTMLやコード、rubricのような“高密度な参照