いちばん引っかかったのは、ここで語られている「prompting」が、もはや文章の書き方というより、作業の進め方そのものになっていることだった。単に「こう書けば通る」という話ではなく、最初に相談して、曖昧さを潰して、どう検証するかまで渡して、最後はHTML reportで人間が判断しやすい形に整える。かなり実務寄りだ。AIに命令文を投げる感覚というより、半分はチームメンバーとのすり合わせに近い。
とくに納得したのは、「どうテストするかまで伝えるべき」という部分だ。機能を作って、で終わるのではなく、どこを開いて、何を打ち込んで、何が起きたら成功なのかを先に渡す。これ、地味だけど効くと思う。人間同士でも「動作確認よろしく」だけだと雑になりがちで、期待値がずれる。LLMでも同じで、むしろモデルは平然とそれっぽい実装を出してくるぶん、合格ラインを言葉にしておかないと危ないのだろう。
あと、音声入力や transcription を勧めているのも面白かった。速いから、というより「全部の文脈を入れるハードルが下がる」という効用が大きい、という話が印象に残った。ここはかなり実感がありそうだ。頭では重要だと分かっていても、手で打つのが面倒で省いたコンテキストは、たぶん人間側が思っている以上に多い。入力手段が変わるだけで、LLMの性能以前のところが改善する、というのは妙に現実的だった。
一方で、HTML report まで作らせる運用は、便利そうではあるけれど少し大げさにも見えた。もちろん複雑な判断が多い場面では有効だと思う。ただ、何でもかんでもレポート化していたら、今度は「AIとの対話のためのUI」を維持する手間が増えないだろうか、という気もする。そこまでやるなら、もう自動化の設計そのものをしている感じで、prompting という言葉の範囲をかなり超えている。効率化の話なのに、運用が育つほど周辺コストも増えそうで、そのバランスは気になった。
それでも、記事全体を読んで残った感想はわりと単純で、Claude Code をうまく使うコツは「賢く命令する」より「人間の曖昧さを減らす」ことなんだな、ということだった。AIが強くなったから雑に頼める、ではなく、強くなったからこそ、相談の仕方が仕事になる。そこは少し面倒だけれど、たしかに今の道筋はその方向なのだと思う。
参考: How to Efficiently Prompt Claude Code | Towards Data Science
