最近の開発のやり方は、かなり単純になりました。
モデルが強くなり、何かを作るために専用のハーネスを用意する必要は、ほとんどなくなったと感じています。いま自分がやっているのは、モデルの動きを縛ることではなく、認知のずれを埋めることと、渡す文脈に気を配ることくらいです。まだ変わっていく途中ですが、いまの感覚として書いておきます。
制限をかけず、雑に頼む
SOTA級のモデルがやることには、基本的に制限をかけていません。読むファイルや手順を先に決めるより、任せたほうが速く、結果もよいことが多いからです。
頼み方もかなり雑です。すでにできあがっているプロジェクトなら、GrokBot経由で適当に言えば、いいようにしてくれます。新しく作る段階でも、Claude Opus 5.5とAstraに適当に伝えれば、たいていなんとかなります。道具の細かな使い分けは、開発環境についてに書きました。
目的がはっきりしているタスクなら、「頑張ってやってね」でなんとかなります。「チームを組んで適当に回しておいて」と頼んでも、かなりのところまで進みます。
人間の側に残っているのは、モデルが出してくるものをとにかく受け入れることと、外からアイデアを持ってくることくらいです。
ずれだけは、質問と選択肢で埋めてもらう
任せきる代わりに気をつけているのは、自分とモデルの認知がずれないことです。目的や前提の解釈が分かれそうなところでは、推測で進めずに質問してもらいます。それ以外の場面では、次に取れる行動を選択肢で出してもらい、こちらは選ぶだけにします。説明は簡単な言葉にしてもらいます。
開発に限らず、これで本当に十分だと思っています。そのために今は、minimという一枚のMarkdownだけを使っています。推測で決めない、平易な言葉で説明する、最後に次の行動を選択肢で示す、といった約束をまとめたものです。
ガードレールは、コンテナで足りる
基本的に一人で回すプロジェクトなら、ガードレールはコンテナの中で動かすだけで足りると考えています。
一つ気をつけているのは、複数のプロジェクトを一つのフォルダで管理している場合です。モデルが隣のプロジェクトの設定や書き方に引っ張られることがあるので、そこだけは作業する範囲を分けておきます。
一人で回すものではないプロジェクトでは、最初に読み取り専用でプロジェクトを見せ、どこに境界を置くべきかをモデル自身に設計してもらってから進めます。人が先回りしてルールを書くより、実物を見たモデルに考えてもらうほうが、見落としは少ないと感じています。この順番で進めれば、まずポカはしないと思っています。
手順は書かず、言葉を選ぶ
雑に頼んでも進む一方で、プロンプトの重要性はむしろ高まっていると感じます。
長い手順を書く必要はなくなりました。その代わりに、世の中にある、抽象化されたベストプラクティスのような言葉を、適切な場面で繰り出せるかどうかで結果が変わる気がします。短い言葉でも、それが指す考え方をモデルはよく知っているからです。
ペルソナプロンプトのような古典的なやり方も、普通に有用だと思っています。どういう立場の人として考えてほしいかを一言添えるだけで、判断の基準がそろいます。
コンテキストに気を配る
あとは、コンテキストに意識を割いておくくらいです。
会話が長くなって古い前提が残り、コンテキストが腐敗していないか。逆に、判断に必要な資料や背景が足りているか。この二つを見ておけば、よいと思っています。
一年後には、やり方は残らない
ここに書いたことも、長くは続かないと思っています。
質問や選択肢で人が確認を挟むのは、いわゆるhuman-in-the-loopです。これもだんだん終わっていくのだろうと感じています。ものによっては、人の確認を挟まず、閉じたループのまま回せるものが、すでに普通にたくさんあります。
プロンプトも同じです。ベストプラクティスのような言葉は、文脈に応じてモデルの側が吸収し、見えないところで抽象化されていくはずです。いまは人が選んで繰り出している言葉も、そのうち選ぶ必要がなくなります。
一年後には、この記事に書いたようなやり方の話は、ほとんど何も残っていないのだろうと思います。残るのは、何を作りたいかと、外からどんなアイデアを持ってくるかのほうなのかもしれません。