#プロンプト設計

いちばん引っかかったのは、「AIにはもっと細かく指示したほうがいい」という、わりと自然に身についた感覚が、もう古くなりつつあるという点でした。 この記事はその転換をかなりはっきり言っていて、読んでいて少し気持ちがよかったです。人間が毎回やっていた「考えて」「丁寧に」「途中で止まらないで」といったおまじないを、モデル側の能力が上回ってきたので外していく、という話だからです。 とくに面白かったのは、「think carefully」を消せ、という部分です。これは単なる文言の整理ではなくて、昔のモデルの弱さを補うための癖が、今は逆に邪魔になっているということですよね。 コード補完でも何でもそうですが、道具が変わったのに昔の操作手順だけ残ると、かえって遅くなる。この記事はその違和感をちゃんと言語化していて、かなり実務っぽい視点だと思いました。 もう一つ、妙に納得したのは「done を最初に定義する」という考え方です。 長く動く AI ほど、途中で勝手に「もう十分です」と判断してしまうのが怖い。だから、何をもって完了とするか、どこで止まって人に聞くかを最初に書いておく。これはAI向けというより、

記事を読んでまず思ったのは、「みんな、もう少し system prompt を神秘視しすぎていたのでは」ということでした。 LLM の中身を知りたい気持ちはよく分かるし、実際この手の leaked prompt 集はかなり面白い。けれど、この記事でいちばん刺さったのは“暴露されたテキストそのもの”よりも、「結局、あれは公開されてもおかしくない前提で扱うべきだ」という話でした。 ここは開発者にとって、かなり現実的です。`system prompt` は、モデルの振る舞いを決める説明書みたいなものだけれど、説明書を安全装置だと思い込むと危ない。記事でも触れていた通り、アクセス制御はバックエンドでやるべきで、プロンプトに「他人の注文を見せるな」と書くのは頼りない。これは地味だけど重要で、AI を触っているとつい“指示すれば守ってくれる”気になりがちなんですよね。でも、そこに期待しすぎるのは危ないと思う。 もう一つ面白かったのは、各社の prompt を並べると、単なる雑学ではなく設計の癖が見えてくるところです。 tool の使い方、plan してから動けという指示、フォーマットの縛り、例示の

まず思ったのは、こういうのは「賢い自動化」というより、かなり地道な整理術なんだな、ということだった。大きなプロンプトを毎回貼るやり方が破綻するのは想像しやすいけれど、その代わりに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のような“高密度な参照