執筆
プロンプトもリファクタリングの対象だ：AIワークフローのログを取り、自動化すべきものを見つける
自分の仕事で最も信頼している進め方はこうだ——経験から「改善できそうだ」と感じたものを起点にし、勘で動くのではなく、なぜそしてどう改善するのかを実データで裏づける。直感はどこを見るべきかを教え、データは自分が正しかったか、そして何をすべきかを教える。近ごろ変わったのは、その「見る」作業をLLMが、かつてなら証明そのものが割に合わないほどの規模でこなせるようになったことだ。
Googleでまさにこれをやった。Legal Content Policy and Standardsチームでポリシーリードを務めていたとき、どの種類の法的削除案件がバックログを詰まらせ、どれが定型的で自動化できるかについて勘があった。それを経験から主張する代わりに、LLMに案件を大規模に——数千件を——分類・要約させ、仮説が裏づけられるか、あるいは修正されるまでデータを回した。Privacy SandboxでTPMを務めたときも形は同じだ。法務レビューに回る文書のうち、どれが本当に深い精査を要するかという感覚を、LLMが一件ずつレビューし分類するパイプラインに変え、高コストな人間の注意を効く場所に落とした。どちらも直感は出発点であって判決ではない。LLMが、その判決を割の合うものにした。
だからLayerXの最近のエンジニアリング記事（著者：LayerXの「バクラク」申請・経費精算プロダクトでモバイルアプリのEMを務める前田洋平氏、はてなID id:myohei11）が目に留まった。私が向けることを思いつかなかった対象——AIワークフローそのもの——に、この同じ手を使っているからだ。コーディングエージェントを一日中使うエンジニアは、いつも同じことを打ち込む。「コミットして、プッシュして、PR作って」「レビューコメントに対応して」「落ちているCIを直して」。繰り返している気がする——だが「気がする」は何を自動化するか決める根拠としては弱い。そこで、エージェントに送ったプロンプトをすべてログに取り、定期的に分析し、実際に繰り返されるパターンに「何を作るべきか」を語らせる。心に残ったのはプロンプトもリファクタリングの対象になるという一節だ。AIへの指示も、コードと同じく、観測し、計測し、再利用可能な部品へ作り替える対象である——同じことを何十回も言うのは重複であり、コードの重複が「におい」なのは、まさにそれが「抽出すべき単位を見つけた」という信号だからだ。
仕組み
仕掛けは意図的に控えめだ。UserPromptSubmit フックが各プロンプトをローカルの prompts.jsonl に追記する——タイムスタンプ、セッションID、本文を1行のJSONにし、極端に短い入力は除外し、ファイルは所有者のみ読み取り可能にする。ログはマスキングし、ローカルに保持し、7日で削除する。（この最後の点は付け足しではない。プロンプトのログは「自分が何を尋ねたか」の記録そのものだから、プライバシーのガードレールは省略可能なオプションではなく、設計の要だ。）
このログの上に2つの検出経路が走る。1つはライブのセッション内で動き、同じ操作が再び出てきたことをリアルタイムで捉える。もう1つは日次のスケジュールジョブで、過去1週間のプロンプトを読み、意図ごとにグルーピングする。両方を回すと、どちらか一方より見落としが減る——リアルタイム経路は会話内での集中を、バッチ経路は数日にまたがって散らばった同じ依頼を捉える。パターンが低いしきい値——3回以上——を超えると、Slackに通知される。パターンの要約に加え、対応するSkillやコマンドを作るためのすぐ使えるプロンプトまで添えられて。
これを単なるログ取りの小細工以上にしているのは、2つの設計判断だ。1つ目は、日次分析が埋め込み（embedding）のクラスタリングではなく、LLMによる意味的なグルーピングを使う点。だから「PR作って」「commitしてpushしてPR作成して」「修正をcommitして、PRまで出して」はすべて1つのパターンに畳み込まれる。言い回しが違っても意図が同じだからだ。これはまさに、言語モデルが得意で、硬直した類似度指標が苦手とする、曖昧で判断を要するグルーピングであり、先の法的案件のトリアージにキーワードフィルタではなくLLMが正解だったのと同じ理由だ。2つ目は、自動化が提案で止まること。自らSkillを作ったり消したりは決してせず、人間が1件ずつ承認する。これにより、半端に役立つだけのルールが知らぬ間に増殖する事態を防ぐ——大半の「自己改善型」自動化を負債に変える、あの失敗モードだ。
面白い転回：AIがAIとの働き方を改善する
これを小ぎれいな整理術以上にしているのは、その矛先がどこを向くかだ。新しい自動化を浮かび上がらせる同じログが、壊れた自動化も浮かび上がらせる。既存のSkillを呼び出した直後に毎回追加の指示を継ぎ足しているなら——「ついでにNotionも更新して」「Slackにも投稿して」「終わってないよ」——その後続のやり取りは、そのSkillが作り込み不足である証拠だ。完了条件が不明瞭だったり、手順が抜けていたり。こうしてシステムは自分自身に矛先を向け、フライホイールが現れる。計測が良くなれば良い自動化が浮かび、それが次を見つけるシステム自体を研ぎ澄ます。
このフライホイールこそ、手口より対象のほうが重要だと私が考える理由だ。エージェント型のコーディングは、ソフトウェアエンジニアリングの標準的な働き方になりつつある——つまり「人とエージェントが実際にどうやり取りするか」が、新しく、しかもほとんど計測されていない改善の余地になる。多くのチームはそこを手探りで進んでいる。ここで報告された成果はあえて地味だ——691回の出現にわたって29個のパターン、うち22個（76%）をSkillやコマンドに変換し、652回分の繰り返しプロンプトを削減。コミット→プッシュ→PRのサイクルだけで、単一の /ship コマンドになる前に94回出現していた——そしてそれが要点だ。これは、数えるまで見えない、退屈で高頻度の雑務であり、いまやそれを数えるのは安上がりになった。
頻度はシグナル、判断基準はレバレッジ
2つの留保で自分を戒めておく。1つ目は、頻度は重要度ではないということ。よく起きるからといって抽象化に値するとは限らない——エンジニアを数語の入力から救うことに、それ自体の価値はほとんどない。価値は、プロセス全体が自動化され、再現可能で、スケールするようになったときに生まれる。回数が教えてくれるのは、それを探す場所であって、見つけた証ではない。2つ目はコストだ。プロンプトのログは、いまや統治（ガバナンス）すべきデータであり、プロンプトはワークフローの一断面しか捉えず、限界的なSkillが積み上がれば、どれが該当するのかエージェントが判別できなくなるほど環境を詰まらせる。どれも致命的ではないが、れっきとした技術的負債であり、だからこそ人間による承認のゲートは省略できない。
言い換えれば、判断はあるべき場所にとどまる——そして最大の見返りは、個々の自動化されたワークフローではない。人とAIのやり取りそのものの効率を上げることだ。なぜなら、それがいまやほぼすべての開発のクリティカルパス上に座っているからである。そこを速くすれば、その下流にあるすべてが速くなる。「これは繰り返しだ」という勘は、依然としてただの勘にすぎない。新しいのは、それを証明し、手を打つことが、研究プロジェクトから日々の習慣にまで降りてきたということだ。私も自分のぶんを、ログに取りはじめようと思う。