目的地を決めれば、ものができていく

目的地を渡すと、勝手に走ってくれる

Claude Code にも Codex CLI にも /goal というコマンドがある。完了条件（＝目的地）を渡すと、それを満たすまで自動でループして自律的に動き続けてくれる、というものだ。仕組みや使い方は公式や解説記事に丁寧にまとまっているので、そっちを見てもらうのが早い。

Codex の公式ドキュメント。

developers.openai.com

Claude Code 側の解説記事。

zenn.dev dev.classmethod.jp

ちなみに Claude と Codex で中身は少し違っていて、ざっくり言うと「達成したか」を Claude は別の小さいモデルに外から判定させ、Codex は自分で自己評価する。とはいえ使う側の体験はだいたい同じなので、細かい違いは上のリンクに譲る。

要は、こういうのが今この手元で実際に体験できるようになった、という話。で、僕がいまどう使っているか。

僕の使い方は、Stepを先導してもらうこと

ここからは僕自身の使い方の話。

セオリーは「測定可能な完了条件をきっちり書く」なんだけど、実際の僕の使い方はもう少しゆるい。多くのケースで、目的地だけ渡して、そこに至るStepの組み立て自体を /goal に先導してもらっている。

たとえば「この機能が動く状態まで」とか「この移行が監視指標に影響を与えずに終わる状態まで」みたいに、最終的にどうなっていてほしいかを渡す。すると、そこに至るための手順――何から手をつけて、どういう順で、どこを確認しながら進めるか――は向こうが組み立てて、勝手に進めてくれる。僕が一手ずつ段取りを指示するのではなく、段取りごと任せている。

完全に測定可能なところまで詰めなくても、目的地さえはっきりしていれば道筋は引いてくれる、というのが実感だ。ただし「いい感じに」レベルまで曖昧にすると、達成したかの判定が効かなくなって迷走する。曖昧でいいけど、的は要る。

カーナビに行き先を入れる感じ

体感としては、カーナビに行き先を入れて、あとは運転を任せるのに近い。曲がる場所を一つずつ指示するのではなく、目的地だけ入れて、ルートの選択も渋滞の回避も任せる。途中で「次どうする」と聞かれることもない。気づくと、自分は行き先を決める人になっていて、ハンドルはもう握っていない。

とはいえ、黙って乗っているわけでもない。僕は助手席、というか後部座席から、あーだこうだ追加の要求を出す人になっている。「さっき通ったコンビニ寄って」「せっかくだから道の駅も行きたい」「トイレ行きたいから次の PA で停めて」みたいに、思いついた寄り道を口にする。運転は任せたまま、行き先と途中の要望だけ足していく。手を動かさなくなっても、口は出している。

行き先の精度の話も、この比喩がちょうどいい。番地まで完璧に入れる必要はないけれど、「どこかいい感じのとこ」では永遠に着かない。「あの道の駅」くらいの的があれば、ルート＝Step は丸ごと任せられる。しかも /goal のナビは目的地に着くまで一度も停まらないから、行き先を間違えて入れると、ものすごい勢いで違う場所に連れていかれる。任せる相手が速くて止まらないほど、どこを目的地に置くかの一回が効いてくる。

開発の重心が、書くから決めるへ

こういう使い方をしていると、自分の仕事の重心が明らかに移った。コードを書く時間と、途中を一手ずつコントロールする時間が減って、目的地を定義する時間と、上がってきた結果を判断する時間が増えた。

細かく見るのをやめたと書いたけれど、見なくなったわけではない。やめたのは途中の逐一のコントロールで、最後に上がってきた結果に責任を持つ判断は、むしろ重くなった。ルートを任せても、行き先を選んだ責任は自分に残る。生成や実装そのものが速くなった分、どこへ向かわせるかの判断と、出てきたものを採否する判断が、相対的に効いてくる。

完了条件を一行で書ける、目的地をはっきり言葉にできる、というのは、要件と設計をその時点で握れている、ということでもある。これは実装力というより、プロダクトとアーキテクチャの思考に近い。生成が誰でも速くできるようになるほど、「何をもって到達とするか」を定義する力のほうが、エンジニアの差になっていく気がする。

試行錯誤のループが、回しやすくなった

/goal を使ってみて、一番価値を感じているのはここだ、と最近思う。特定の目的地に向けて試行錯誤のループを回す――作って、確かめて、ずれていたら直して、また確かめる――その一周のコストが、はっきり下がった。

前は、このループの一周ごとに自分が手を動かして、結果を見て、次を指示して、という往復が挟まっていた。だから回せる試行回数には限りがあった。/goal は目的地さえ決めれば、そのループを止まらずに何周も回してくれる。より多く、より速く、目的地に向けて試せる。

考えてみると、特定のゴールに向けて試行錯誤のループを回し切る、というのはエンジニアリングそのものだ。どこに向けてループを回すかを決めて、回り続ける結果を引き取って、これでいいと判断する。ループを回すコストが下がったぶん、その気になれば生み出せる価値は素直に上がる。これは「楽になった」というより、価値を高めるエンジニアリングがやりやすくなった、という話なのだと思う。

だから自分が鍛えておきたいのは、コードを速く書く力よりも、どこに向けてループを回すかを決める力と、回り切ったループの結果を見極める力のほうだ。Step を引いて走るところは、もう任せられる。任せられないのは、目的地を決めることと、出てきたものに責任を持つこと。

まだ過渡期で、答えが出ているわけではない。ただ、自分とチームの価値をどこに置き直すか、というのは、目先の効率の話ではなく、これからのエンジニアの在り方の話として、真面目に考えておきたいと思っている。