「3周は上限であって、目標ではない」——AIの修正ループに書き足した一行の話
こんにちは、エンジニア兼ビートメーカーのPHONONです。
7月25日、土曜日。朝のウォーキングは5,304歩。今日もきっちり30分歩いてきました。ただ今日は、朝いちでヒゲ脱毛を済ませてからのウォーキング。施術後の顔でそのまま外に出るのもなんなので、マスクをしたまま歩きました。夏場のマスクウォーキング、なかなかの修行です。
そして昨日の記事では、最後に「なんでもない休日を、なんでもなく」と書いて終わりました。今日はその答え合わせと、脱毛の待ち時間に読んでいたClaude Opus 5のプロンプトガイドラインの話を書きます。
ビートを作るつもりが、Reactのフックスを学んでいた
昨日の午前中は、本当はビートを作るつもりでいました。
ところが業務のほうで、フロントエンドのコードレビューをすることになりまして。だったら今のうちに手を入れておくか、とそのまま学習に切り替えました。
ここ最近はNext.jsの教材を進めていたんですが、それがちょうど終わったタイミング。次にReactで強化したいのはどこだろうと考えながらUdemyの講座を覗いていたら、フックスだけを集中的にやる講座を見つけました。useStateあたりを、改めて腰を据えて。基礎に戻るには、ちょうどいいタイミングだったと思います。
そんなことをしていたら午前中が終わっていました。休日の午前中って、こういう溶け方をしますよね。
昼は弘前の二郎系「一文路」で、麺少なめ・アブラ増し
せっかくの休日なので、お昼は外に出ることに。向かったのは弘前市の二郎系の有名店、一文路さんです。
コールは相変わらず麺少なめ・アブラ増し。この組み合わせが自分にはいちばん合っていて、毎回ここに落ち着きます。非常に美味しかったです。写真も撮ってきたので載せておきますね。


パートナーへのプレゼントは、古着屋のラルフローレン
ご飯のあとは、カメラを片手に駅前を散策。パートナーの誕生日がそろそろ近いので、そのプレゼント探しです。
バッグとか、候補はいろいろあったんですが、今回はちょっとチャレンジングな方向に振ってみました。向かったのは、仲の良い方がやっている古着屋のシーソーさん。そこで選んだのが、ラルフローレンのオープンカラーのベロアシャツです。


オープンカラーで、しかもベロア。物としてはなかなか珍しいと思います。無難なところを選ぶ手もあったんですが、こういうときこそ古着だろう、と。結果、喜んでもらえたので、この振り方で正解でした。
GR IVとX-T50、昨日ははっきり使い分けられた
昨日撮った写真は、カメラ2台の使い分けでした。
ラーメンの写真はGR IV。街中のスナップと店内の写真はX-T50です。改めて、GRは狭いラーメン屋の店内みたいな場所に本当に強い。ポケットに入れておいて、撮りたいときだけさっと取り出す——あの一連の動作に、これ以上ないくらい適した道具だと思います。周りに気を遣わずに済むサイズ感が、そのまま撮れる枚数になって返ってくる。
一方のX-T50は、歩きながらスナップを撮りたいときや、もともと仲のいい店員さんがいて、しかもカメラ好きという場所。要するに「カメラを堂々と取り出せる環境」では、こっちの出番です。取り出しやすさが担保されているなら、フジの色で撮りたい。
同じ一日の中で、それぞれ適した場面にちゃんと振り分けられた感触があって、そこが昨日いちばん気持ちよかったところかもしれません。
Opus 5になって、プロンプトのガイドラインが更新されていた
で、ここからが今日の本題です。
昨日、Claude Opus 4.8から5に上がりましたよね。それに伴ってプロンプトのガイドラインも更新されていたらしく、今朝のヒゲ脱毛の待ち時間に、その内容を確認していました。
読んでいたら、この日記を書いているスキルにも、業務で使っている設定にも、手を入れたほうがいいと思う箇所がいくつかあったので、抜粋して書いておきます。
サブエージェントに委譲するかは、タスクの粒度で決まる
まず、サブエージェントへの委譲は明示的に抑制したほうがいいという方向性。
この日記を組み立てているスキルは、ひとつのオーケストレーター(=メインの会話)に寄せています。理由はシンプルで、日記1本はそこまで規模が大きくないから。というわけで、日記側は委譲を抑制する方向に調整しました。
逆に、実務で使っているほうは積極的に委譲していくほうがいいと思っています。こちらはそれぞれのサブエージェントに渡すタスクの粒度が大きいから。同じ「委譲するかどうか」でも、判断の分かれ目は好みではなく粒度なんだな、と整理がつきました。
「3周」は上限であって、目標ではない
次が、個人的にいちばん刺さったところ。
日記の編集ループには、修正を最大3周までという上限を明示的に設定していました。ただ、モデル側の自己修正の能力が上がったこともあって、「3周は上限であって目標ではない」と書き換えたほうがいいらしいんです。
というのも、ただ「3周」とだけ書いておくと、1周で終わらせると手を抜いた気がする方向にバイアスが生まれるとのこと。
これ、人間とまったく同じですよね。「最大3回まで見直していい」と言われたら、なんとなく3回やらないと落ち着かない。1周で品質基準を満たしているなら、そこで終わるのが正しいはずなのに。上限を書くときは「これは安全弁であって目標ではない」まで書き添えないと、上限がそのままノルマに化ける、ということです。
「深刻度が高いものだけ報告して」と書くと、本当に報告が減る
コードレビューまわりの話も面白かったです。
レビューの指示に「深刻度が高いものだけ報告して」「保守的に判断して」と書くと、文字通り報告そのものが減る、と。だからいったん全件出させて、絞り込みは別のステップでやるほうがいい。
これは実務的にかなり効くと思います。報告と選別を同じステップでやらせると、「絞らなきゃ」という圧が観察そのものに混ざってしまうので。見る人と落とす人を分ける——これ、レビュー体制の話としてもそのまま通じますよね。
検証ステップは、入れすぎると過剰になる
もうひとつ。モデル側の自己検証の能力が上がったことで、スキルの中に検証ステップの指示を書いておくと、検証が過剰になるケースがあるらしいです。
こちらも見直しが必要だなと思っています。以前は「ちゃんと確認させないと確認しない」前提で書いていた指示が、今は逆に足を引っ張る側に回っている、ということですね。
薄くしつつ、必要なところで効かせる
全体を通して感じたのは、モデルの性能が上がるほど、指示は薄くしていいということ。
ただ、薄くすればいいという単純な話でもなくて、どこを残して効かせるのかという勘どころが要ります。上限を書くなら「目標ではない」まで添える。報告と選別は分ける。この「どこを削って、どこを厚くするか」の判断こそが、これから効いてくる部分なんだろうなと感じました。
ガイドラインが更新されるたびに設定を書き直すのは、正直ちょっと面倒です。でも、書き直しながら「なぜ自分はこう書いていたんだっけ」を思い出す時間が、いちばん勉強になっている気もします。
それでは、良い一日を。以上です。
