直近のプルリクエストがやけに大量に捌けるようになってきたので、如何にして大量生産に至ったかを書いていこうかと思い、筆を執りました
具体的にどんな手順で開発を回しているのか、や、その中で考えたAI利用による開発の効率化についての自分の考えなんかをつらつらと書いていこうかなと思います
月間PR数400以上を実現したとはいうものの、一定の前提条件があるうえでの数字なので参考値と思っていただけると幸いです
「PR400とか出すぐらい使い込んだ人の使い方や考え方」という観点で以降の文章を読んでもらえると良いのかなと思います
前提と実績
データ基盤の開発・運用をしています
一人チーム・セルフマージOKの運用です。もちろんQAプロセスはありません
mainブランチへのマージ即本番デプロイが（概ね）許容される環境となっています
主たる開発はTerraformとdbtのSQLやyamlで、自動化スクリプト類や、データ収集処理はDeno/TypeScriptを使っています
データ基盤のうち、顧客影響のある部分はdbtのデータマートの一部です（詳細はこの辺↓に書いてあります）
使ってるCoding Agentはタイトルの通りClaude Codeです
以下が実績
自分が出してマージしたプルリクエスト数の月次推移
- 残業時間: 大体10~30時間/月
- この区間のデータ基盤起因の障害件数: 4件程度
- まあ少なく収まってるんじゃないでしょうか
- 2025/12は448件のPRをマージ
目次 兼 tl;dr
初めにAgentを利用するうえで大事だと思う心構え、
次にそれを踏まえて自分が実践していることを書いていきます
本文が結構長くなっちゃったんで、言いたいことを簡単にまとめて見出しとしました。ここを見て興味のあるところだけ見てもらうとかもありかなと思います
心構えのまとめ
- Agentをチームメイトのように扱う。どんな振る舞いをするのかを観察したり、対話して、得手不得手を知り、チームメイトが働きやすい環境を考え、改善する
- Agentとの対話のトライ&エラーの回数を増やす。細かいこと考えるより手を動かした方が良いのと、確率的な動作の「肌感」を自分が獲得することが的確な指示出しへの糧となるので
- Agentにやってもらえそうなことは何でもやらせる。これまでの常識ではありえない速度で自動化ツールを実装できるので、とにかく全てを自動化する方向で検討する
- ↓の3つの切り口でAgentへの作業の委譲を検討出来そう。行き詰まったら考えてみると良いと思う
-
Agentがうまくアウトプットできるようにする/Agentのやる範囲を広げる/人間のやることを減らす
-
自分が実践してることのまとめ
- Agentを気合で並列で回す（今は7並列のセッションを同時に張っています）
- 実装→検証→PR→マージ→実装→...の開発サイクルのうち、PRレビューだけ自分がやって、他のことはほぼAgentにやらせる
- 確率的なプロンプトを頑張るよりも、決定性のある部分を頑張る（linter、 Claude CodeのPreToolUse hookによる動作の制御、 プロジェクト・コードアーキテクチャ・コードベースといった構成のセマンティクスを整え、誤解のない状態にするなど）
- 改善用のプロセスを1、2ほど設けておく。改善点を見つけ次第そこで細かな改善をすぐにやらせる。特にAgentが頻繁に誤解したり失敗するような状況が発生していたらそれを優先して潰す
- 最低限の情報収集
心構え編
自分が日頃Agentを利用しているときの心構えを書いていってみます
多分こういう風に臨むのがいいんだろう、という経験的な思考を基にしている気がします
Agentをチームメイトのように扱う。どんな振る舞いをするのかを観察したり、対話して、得手不得手を知り、チームメイトが働きやすい環境を考え、改善する
AnthropicとかOpenAIのブログとかドキュメントでも「現在のLLMはシニアソフトウェアエンジニアである」といった言及を見かけると思います
しかし自分はそれを受けて、というよりは、もっと自分の経験からこの言葉が出てきました
以下は去年の10月末に社内で話したことです
最近Claude Code賢くね？って思ったんですよね
話したりタスクをさせていると、もしかしてもっと任せられるのでは？という感覚が湧いてきたといいますか。
ということで最近↓のようなフローで開発をしています
- 人間が /plan コマンドで計画を立てる（このときstepごとにPRを分けてマージ可能な形で計画させる）
- Agentにそのまま実装してもらい、PRも上げさせて、PRのchecksがpassしたらgh pr view --webでブラウザを開かせる
- 人間がGitHub上でレビューをし、/address-review ‘[review url]’コマンドでレビュー内容Agentにフィードバックして直させる
- 満足行く結果になったら人間がマージ
ほぼチームメンバー
俺は一人チームだと思っていたけど、今や心強い仲間たちが6人ぐらいいる（？）
（補足: 元々は手元で差分を見ながら修正依頼したりを繰り返してPRは自分で出す、というやり方をしていました）
話したりタスクをさせていると、もしかしてもっと任せられるのでは？という感覚が湧いてきたといいますか。
この辺の感覚が完全に新卒メンバーがチームに所属したときの成長過程とほとんど一緒だったんですよね
任せた作業の過程やアウトプットを見て、この完成度のものを仕上げてくるなら細かいマネジメントをしなくてもいいな、と判断したりすることは一般によくあることだと思います
そしてAgentに関しても同じような体験をして、自分の中で自然と「より多くのことを任せられるな」という思考が働いて、やらせてみて、そして実際にちゃんとアウトプットが出てきた、という話です
・・・さて、では、ここにまるでチームメイトのように働いてくれるAgentさんがいます
一緒にうまく働いていくにはどうすればいいでしょう？
-> その人が得意なことや不得意なことを知って、得意なことをやってもらって不得意なことは巻き取る
-> みんなが働きやすいような環境（Agentにとっては環境はコードで表現される全てになりますが）を整える
-> アウトプットがどんなものかを把握したり、逆に時には任せたりする
みたいな考えが出来るなと感じています（まあこれはもう完全に自分の感性でしかないですが）
多分ここで大事なのは、「Agentを理解することが大事。その理解するメソッドとして 人間と近似して解釈する ことが有効」って点かなと思ってます
どうも自分はLLMの行動を解釈し、理解するのに、人間の行動を解釈・理解するときとほぼ同じ考え方をしてるっぽいんですよね
んでそのやり方でもあんまり実際のAgentの振る舞いと乖離がないので、多分「Agent（の主にLLMとしての）の振る舞いを人間と近似して解釈」は割と有りなメソッドなのかなという結論に至りました[1]
で、「チームメイトとして扱う」って具体的になにしてるねん、って話なんですが、ゆーて大した話ではないです
- コードの変数名とかが誤解しやすい内容になってて、実際にAgentが誤解して変な動きをしているのを見つけたらリファクタリングをするとか
- 定型的な開発タスクをしている中でAgentが同じようなコマンドを何度も叩いて望む出力を得ようとしていたら、それを一発で実行するスクリプトを実装するとか
- コーディング規約っぽいレビューを何度もしていたらlinterなどで機械的に防げるようにするとか
ほんとにこんな感じで、普通に人間とチームで開発しててやってることと変わらないことをやってます
（まあヤツらは人間ではありえないようなミスをしてきたりはするんだが・・・）
Agentとの対話のトライ&エラーの回数を増やす。細かいこと考えるより手を動かした方が良いのと、確率的な動作の「肌感」を自分が獲得することが的確な指示出しへの糧となるので
これは試行回数を重ねろ！というメッセージで、意図として以下の2点があります
- 迷っているぐらいならまず手を動かすべき。ベストなツールを探したり、色々な機能を使いこなしたりしなきゃ・・・とか考えるより先に手を動かしたほうがリターンが圧倒的にデカい
- Agentの確率的な振る舞いを理解するためにコミュニケーションを重ね、相手を理解する必要がある。そのために何度もコミュニケーションするべき
それぞれ書いていきます
迷っているぐらいならまず手を動かすべき
世間は今、大AI時代で、猫も杓子もAI、AI。エンジニアもAgentにコードを書かせる話が無限にSNSに流れてきています
そんな中でAIを使い始めよう、というときに、「どれがいいんだろう・・・」「どの情報をキャッチアップすればいいんだろう・・・」と迷っている話をよく見聞きします
そんな人達に伝えたいのが、「そんなことよりまずは使い始めてトライ&エラーを重ねて肌感を掴め」ということです
最近のAgentはほぼ設定無しでも結構動いてくれます。まずは手を動かし始めてトライ&エラーを重ねるべきです
これは自分の感覚なんですが、↓のように感じています
- Agentを利用することでかかるそもそもの人間の生産性への倍率: 2~数十倍
- ツール選定や機能を使いこなすことでかかるAgentic Codingの生産性への倍率: 1.2~1.5倍
数十倍って盛ってるやろｗって思うかもしれませんが、普通に生産性が真に高いエンジニアの生産性がそのぐらいって話があるので現実的な数字だと思ってます
実際、自分が取り組むとしたら問題領域を理解するところから始まる、みたいなタスクを指示出し一発で成果物をお出しされたら自分のかけた工数が数日→数十分に収まった、みたいなことは何度でもあります
局所的に見たら生産性が数十倍になってるケースもあるな、というのが自分の体感です
それに対して、Agent自体の選定やAgent Skillsであるとかの「Agentの機能を使いこなす」営みは、Agent自体を上手く動くようにはしてくれるものの、あくまでも「Agentic Codingの生産性に多少の倍率を上乗せするもの」という性質です
故に、上手に使うことを考えるより、普段から利用する状況に自分を持っていくことのほうがインパクトがデカいと感じています
また、Agentはこれまで人類が触れてきた技術とは特性が違いすぎて、Agentの挙動を実感として理解するために「多くの経験を要する」という点があると感じています
この点も細かいことを考える前に早々に使い始めるべき理由として挙げられるでしょう
Agentの確率的な振る舞いを理解するためにコミュニケーションを重ね、相手を理解する必要がある。そのために何度もコミュニケーションするべき
チームメイトの話でも若干触れてますが、とにかく彼らに上手く動いてもらうためには彼らのことを理解する必要があります
エンジニアリングの世界ではこれまで、新しいことに触れるときに対象を理解しようと思ったらドキュメントを読むなり、Getting Startedを動かしてみたりすればまあ大体の振る舞いは理解できたんですよね
でもLLMの動作は、LLMの動作原理を理解したところで恐らく実際の動きの理解には繋がりにくいと思います
ってことで、とにかくトライ&エラー、試行回数を重ねるのが良いと思っています
人間を理解するのに人間のドキュメント読んでもしょうがないので理解をするためにコミュニケーションを重ねる必要がある、という言い方をしてもいいかもしれません
どんどん 人間と近似 して理解していきましょう
・・・
「コミュニケーションを重ねる」をもうちょっと掘り下げてみます
Agentに指示を出して、その指示の結果が思ったものにならないことがあるでしょう
そのときに、「何故思った結果が得られなかったか」を考え、原因を予測し、何らかの異なるアプローチで欲しい結果を得ようとすると思います
さて、人間とコミュニケーションするときのことを考えます
何らかのタスクを人に依頼するときにも同様に「指示の結果が思ったものにならない」ことがあると思います（というか別に指示に限らず、自分が喋った内容が相手に思ったように伝わったかどうか、みたいな話と言ってしまっていいですが）
そのときの原因を考える思考と同じことをすればいいと思っています
- チームに参加したばかりのメンバーがデプロイ方法を知らなくてデプロイしておいてと指示されても出来ない
- Slackにアラート通知があったので調べておいて、とお願いしたが、そのアラートは無視していいやつだったのに掘り下げて調べ続けてしまった
- DBに
activityとactivity_eventsという似たテーブルがあり、口頭で「アクティビティ」と伝えたときに取り違えてしまった
など、知識の問題だったり、暗黙知があったり、紛らわしい語彙があったり・・・
自分が伝えた言葉がどのように解釈されやすいか？を検討して次のコミュニケーションでは気をつけるようにする・チームで「これはこう呼びましょう」と取り決めをする（ほぼユビキタス言語ですね）といったように色々な改善を重ねていくと思います
LLM、 Agentに関しても同じように、自分が伝えた内容の解釈のされかたを知っていきましょう
誤解なく伝わっているのか？であるとか、どのようなことまで考慮して動いてくれているのか？であるとか。相手の振る舞いやアウトプットを観察して、理解を重ねることで次に繋がっていきます
Anthropicのドキュメントでも、たびたび観察を通して改善をするべきだと言及されていますね
色々書きましたが・・・結局のところここで言いたいのは、つまりは、これです
「とにかくやれ」
Agentにやってもらえそうなことは何でもやらせる。これまでの常識ではありえない速度で自動化ツールを実装できるので、とにかく全てを自動化する方向で検討する
表題の通りです。おわり。
・・・いえ、ちゃんと書きます
さてこの話、t_wadaさんがちょいちょい近いことを呟いています
自分の言っていることもほぼこのノリです
開発チーム内までいかないような、自分だけが使うスクリプトでもいいし、もちろん開発チーム内に展開するようなものでも良い
今まではちょっとひと手間だな・・・と思ってたようなことがAgentによってあっという間に実現できるんですから、やればやるだけよいです
作るときにコストかかってない分、捨てるときにも気が楽なのも◯（チームの開発フローまで変えちゃうとチーム内で調整がいるのでそこら辺は匙加減ですが）
「チームで調整が大変でなかなかリポジトリに取り込みにくいが、仕事用の便利な自動化はしたい・・・」
といったケースに自分がおすすめしたいのは、「リポジトリ内に個人用スペースを用意する」という方法です
前職stand.fmで確か gomibako みたいなフォルダがいて、その中に個人用のディレクトリを掘って何でも入れて良い・このフォルダだけのdiffのPRは自動Approveされる、という運用をしていたんですよね
個人的にこれを推しています（現職knowledgeworkのメインのリポジトリにも同じノリで作りました）
とにかくこんなノリで環境を整備していって、Agentによる自動化を妨げる要因は全て潰す・どんどんスクリプトを書き捨てていくべし！と思っています
先述した通り、Agentとの対話のトライ&エラーはなんぼでも繰り返した方がよいので、そういった面でも何でも自動化を試みるのは良いと思っています
実際に今のデータ基盤用のリポジトリで自動化した例を上げていくと、
- （大物）Google Cloudのプロジェクト作成の自動化[2]
- （中物）プルリクのRequired Status Checkを簡単に管理する ワークフローの実装
- （小物）年に一回、内閣府が更新する日本の祝日を定義したCSVをダウンロードしてきてdbtに取り込むスクリプト・その差分をPR出すcronワークフローの実装
- （小物）
terraform planのstdoutをAgent向けにstdoutを出さないようにしつつ、tf-summarizeで最低限の結果だけ得られるようにするスクリプトの実装 - （小物）dbtのCloud Run Jobのキックをするスクリプト
などなど
全部挙げていってたらマジでキリがないぐらい、なんでも自動化したれの精神で色々なスクリプトがデータ基盤リポジトリにいます
上長からは「sisisinがやらなきゃいけないと思ったことは全て仕組み化されて返ってくるのである」と言われました。全部Agent様のおかげです。ありがとう頼れるチームメイト
↓の3つの切り口でAgentへの作業の委譲を検討出来そう。行き詰まったら考えてみると良いと思う
AgentがうまくアウトプットできるようにするAgentのやる範囲を広げる人間のやることを減らす
なんとなく、自分が普段Agentを利用した開発の改善でやっていることを分類するとこんな感じになるなと思ったものを書いてみました
Agentがうまくアウトプットできるようにする
Agentのアウトプットの品質を高める、というアプローチです
- AGENTS.mdを変更する
- プロジェクト内でAgentが誤解するようなコードベースをリファクタリングする
- contextの消耗を抑える
- マージ済みのbranchにcommitするなど、gitの状態を扱うのが下手なのでそれを防止する仕組みを入れる（pre-pushとかpre-commit hookでブランチがマージ済みかなどを判定したり）
といった作業によって成されるでしょう
めっちゃ卑近な例を挙げると、最近やったのがtyposというタイポ検出ツールの設定ファイルを _typos.toml から typos.toml に修正しました
彼らはtyposの設定ファイルを typos.toml だと決め打ちで探すっぽくて、見つからないと迷走していたのが観察されたのでやりました
こんなレベルでも全然アウトプット変わります
（ちなみに変更前は迷走した結果、pre-commit hookでのtypos実行時にtypoが出たファイルをignoreしようとしたりしてきました。ウケる。）
Agentのやる範囲を広げる
Agentにもっと色々やらせていく、というアプローチです
- 手元で指示出しをして修正して満足いったらPRを出していたところを、指示出しの時点でPR出すところまでお願いしちゃう
- アラートの調査について、自分で調査してから修正方針を決めて修正させていたところを、調査から修正までやらせる
これまで人間がやっていたことを任せる方針です
もうプログラムから読めるものは何でも出来るといっていいので、何でもやらせましょう
これは余談ですが、最近の悩みとして、Slackのメッセージ取得APIのrate limitがかなり絞られてしまったことでアラートを直でSlackに取りに行かせにくいな〜ってのがあります（Google CloudのアラートのURLを貼って調査してもらってます）
人間のやることを減らす
範囲を広げると何が違うねん？という話がありそうですがちょい見方が違います
Agentは便利でかなりのことをやってくれますが、それでも全部を出来るわけじゃないので人間がやることというのはどうしても残ります
しかし、その残った人間のやることを如何にして軽くするか？という目線で改善が出来るだろうというアプローチです
- PRのレビューをするときに「〜のファイルの〜行目を〜のように直して」と指示していたところを、GitHubのレビューコメントを取得してAgent向けに加工して与えるスクリプトとカスタムコマンドを定義する
- 何らかの連続したタスクをやっているときに、人間が「PRのマージする→GitHub Actionsからterraform applyされるのを待つ→成否をAgentへ伝え、次の作業へ入ってもらう」という作業をやっていたところを、「マージしたのでapplyのワークフローを待機して、成否に応じて次の作業に入る」までをプロンプト・スクリプト化し、人間はただそのカスタムコマンドを実行するだけにする
自分はAgentの出してきたPRのレビューをかなりやることになるので、この例のように、レビューの負担を軽くする自動化をあれこれ試行錯誤しました
人やチームやプロダクトによって「人間が担保する作業」というのは変わってくると思うので、色々出来ることはあるんじゃないかな〜と思ってます
とまあこんな感じでAgentと向き合うのが良かろうという話でした
（最後の方はあんまり心構えっぽくないかも）
自分が実践してること編
心構えを書いたので、次に自分が実際にどう開発しているのかを書いていこうと思います
テクニックだったり筋肉だったりします
Agentを気合で並列で回す（今は7並列のセッションを同時に張っています）
沢山PRを出すということは沢山働かせるということです
並列数を上げれば沢山働かせられて沢山アウトプットが出ます
はい。
・・・真面目な話、人によってここのキャパとか合う合わないがかなり違ってくるのでマジで真に受けないほうが良いとは思います
自分は昔からPRが飛んできたら即座にレビューする、といった動きをしていたりしてて、コンテキストスイッチに慣れていたのが多分影響あります（あるいは元々得意だったのかも）
まあ気合の話になっちゃうと身も蓋もないので、並列で作業するときの実際の工夫を書くことによって知見の共有という体を保とうと思います
やり方は↓みたいにターミナルを分割して、
5並列のときのレイアウト
左上から
- repo
- repo1
- repo2
- ...
って感じでrepoをcloneしておいて、それぞれのターミナルセッションにAgentを割り当ててAgentのセッションを進めてます（左上は自分用のプロセス）
git worktreeは使ってないです（イマイチ使い所わかってない・・・ブランチごとにフォルダ作るの使いにくくね？っていう・・・）
気をつけてることとしては、
- 似たことを並列でやらない（頭がこんがらがるので）
- 独立したタスクをそれぞれアサインする（協調動作させるのは面倒なので）
- 締め切りの厳しいタスクをなるべく請け負わないように調整する（並列化は個々のタスクのリードタイムを犠牲にして総アウトプット量を増やすアプローチなので、リードタイムを短くするような動きを要求されると生産性が劇的に落ちてしまう）
- 主たるタスクだけでなく、改善タスク用のセッションを走らせる余白を常に持たせる（Agent向けにプロジェクト改善を思いついたら即実行できるようにしておく感じ）
という感じです
しれっとタスクの締め切り調整、みたいなAgentとだいぶ遠いところで意識してることがあったりします
データ基盤チームであるがゆえにこういう調整やりやすい、みたいな事情もあったりしますが・・・
実装→検証→PR→マージ→実装→...の開発サイクルのうち、PRレビューだけ自分がやって、他のことはほぼAgentにやらせる
何度か話題に出していますが、自分は今はPRレビューだけしてます
レビューで品質を担保している感じです
実際の開発フローとしては、
- やりたいことを伝え、計画させ、計画ファイルをplan.mdとして出力させてPRを出させる
- 計画のレビューをし、マージする
- 計画の実行を以下のループでやらせる
- 1 Step 1 PRとなるように実装を進めてもらう（実際には計画時点でPRの単位になるように指示している）
- PRが出てきたらレビューし、マージする
- マージしたことを伝え、PR後の GitHub Actionsのワークフロー（主にterraform applyなどのデプロイ）を待たせつつ、次のStepへ進ませる
- 計画ファイルには最後のStepとして「計画ファイルのアーカイブPRを上げる」を定義しているので、この最終Stepの完了をもって計画の完了とする
という感じでやっています
計画ファイルは以下のようなフォーマットで出させています
plan.md フォーマット
<plan-guide>
<description>
このファイルは自己完結型の実行可能な計画（ExecPlan）です。
- このプランは **living document** として扱う。実装中に発見した問題や設計変更は随時反映すること
- 各 Step は独立して検証可能で、段階的にゴールへ近づく構成になっている
- 完全な初心者でも、このファイルだけを読んで実装を完了できることを目指す
</description>
<execution-guide>
このファイルのパスを渡して「実行して」と指示すると、以下のフローで進行する:
1. 次の未完了 Step を実装し PR 作成
2. CI checks 通過後、ユーザーにレビュー依頼
3. ユーザーが `/lgtm` を実行したら PR マージを待機
4. マージ完了後、自動的に次の未完了 Step へ進む
5. 全 Step 完了で作業終了
<pr-rules>
- plan.md の更新（該当 Step を `[x]` に、Progress に記録追加）を実装と同じ PR に含める
- Progress の完了マークだけの PR は禁止
- PR description には `Plan: [path]` と `Step: [番号]` を含める
- 関連 Issue がある場合、PR description に `Related: #[issue number]` を含める
</pr-rules>
<notes>
- 実装中に計画の問題が見つかった場合は plan.md を修正すること
- PR 分割が必要な場合は Step 1.1, Step 1.2 のように分割してよい
</notes>
</execution-guide>
</plan-guide>
# [Feature Name]
## 関連 Issue
<!-- GitHub issue から作成した場合は記載。なければ削除 -->
- #[issue number]: [issue title]
## 目的
なぜこの作業が必要か、完了後に何ができるようになるか。
## Steps
- [ ] Step 1: [Description]
- 達成条件: 何が完了していれば OK か
- Verification: どうやって確認するか（テスト、動作確認など）
- [ ] Step 1.1: [Description] ← 1 Step が大きい場合は分割
- 達成条件: ...
- Verification: ...
- [ ] Step 2: [Description]
- 達成条件: ...
- Verification: ...
- [ ] Step N: 完了処理
- 達成条件: plan.md が \_archived ディレクトリに移動されている
- Verification: `docs/plans/_archived/` に存在することを確認
- Note: 関連 Issue がある場合、PR 本文に `closes #[issue number]` を含めて issue を閉じる
## Progress
進捗を記録。Step 完了時に更新する。
- (YYYY-MM-DD) Step X 完了 (PR #XXX, merged)
一時期ちょっとバズった、Codexで7時間とかのタスクをやらせるプロンプトを参考に、自分の開発で使いやすい形にアレンジしました
Using PLANS.md for multi-hour problem solving
これが今の形になったのが2025年の12月ごろで、これのおかげでかなり生産性が上がりました（最初のPR数のチャートの通り）
で、その数のPRのレビューってどうしてるん？問題について
さて、7並列で回しているとマジで絶え間なくPRが飛んでくるので、普段の開発はレビュー地獄です
月に400件ってことは、20営業日で1日20件以上のPRを捌くことになるのでここはほんとにひたすら筋肉を発揮して対処してるところはあります
一応工夫しているところはあり、
- 自分でコードを書く感覚でアウトプットの品質を求めるのをやめる
- 俺だったらこうは書かないんだけどな、みたいなのを細かくこだわらない。それこそチームメイトのPRをレビューするような感覚で見る
- 実装するドメイン・領域によってレビューの丁寧さを調整する
- 自動化ツールは殆ど見ない
- dbtの実行環境に直接関わるTerraformの変更は丁寧に見る
- などなど
- そもそもレビューしにくいPRが飛んでこないように計画ファイル作成時点で調整する
- plan作成のプロンプトには「ある程度意味のまとまりがある・小さくマージが可能な単位でPRを出すような計画にしろ」と指示している。これがめっちゃ効く
- 計画段階でやることが変だったりしないかの段取りをちゃんとレビューしておいて、計画遂行のPRは自明でわかりやすいものが上がってくるように調整しておく
とまあこんな感じで処理しやすくしています
でもこれはどっちかというと「無数に作業させたからPR捌くのが大変」というよりは「自分が出来るレビュー速度で実装を積み重ねていったらこうなった」ではあるので、因果が逆な感はあります
・・・まあなんにしても毎日レビュー地獄であるというのは変わらないので大変ですね（白目）
余談
レビューや計画をこれだけの数こなしていると、色々な力が養われる感覚はありますね
例えばその一例として、
計画段階でやることが変だったりしないかの段取りをちゃんとレビューしておいて、計画遂行のPRは自明でわかりやすいものが上がってくるように調整しておく
についての「調整しておく」なんかは、かなり養われた能力の一つだなと感じます
これ、実際にはAgentに計画させる前に自分で「この目的を達成させるには大体こういう実装が必要。それをAgentが誤りを起こしにくい段取りにするとこんな感じだろうか」を想定しておいてから計画をさせてます
んで、Agentがお出ししてきた計画に対してその想定段取りと差分を取りつつAgentの提案の方が良いならそれを採用・そうでないなら自分の想定解をフィードバック
みたいな感じで洗練させることで、より確度の高いやり方を組めるようになってきたという体感があります
確率的なプロンプトを頑張るよりも、決定性のある部分を頑張る（linter、Claude CodeのPreToolUse hookによる動作の制御、プロジェクト・コードアーキテクチャ・コードベースといった構成のセマンティクスを整え、誤解のない状態にするなど）
実践編3点目です
プロンプトは自分はそんなに頑張ってません
ちゃんと言語化すれば色々理由は出てくるんですが、結局のところ、単にAgentと対話してAgentに上手く動いてもらおうと思ったときにプロンプトの改善よりもコードベースの改善の方が効果あるなって感じることが多かった、という経験から自然とそうなりました
でもまあ、linter頑張りましょうみたいなのはもう散々言われつくされていることではあります
頑張りましょう
頑張る度合いはプロンプトよりこっちです
決定性のある部分の具体どんな感じかを書いていきます
linterを初めとする静的解析ツールを導入する。lintのカスタムルールなんかもどんどん書く（書いてもらう）。とにかく「人が直させる」のを減らす
人がなんか指摘してたらそれは改善ポイント、ぐらいの精神性を持ちましょう
とにかく整備しましょう
以上！
この辺は自作も厭わない、ぐらいの気持ちで良いと思います。全部Agentが自作してくれるので
自分のメンテしてるデータ基盤リポジトリでは主に、↓ぐらいのことをしています。（言うほど頑張ってない疑惑はあるが、こんなもんでも結構イケる）
- typos（typo検知）
- lefthook（git hook管理。pre commit、pre pushで状態を確認してAgent向けにダメ出し）
- 各種linter、formatter、型検査
- Denoやdbtについてはカスタムルールも導入
Claude CodeやOpenCodeなら、Agentのツール利用などのイベントに引っ掛けてダメ出しすることが出来るので積極的に使う
以下の記事のとおりです
PreToolUse hookはかなり良くて、これに相当する機能がないAgentは自分は使えないなと思ってます
自分は以下のように、bashスクリプト内にdenyなコマンド利用を定義してメッセージを与えられるようにしています
# terraform
match "$command" "terraform apply*" "Do not use 'terraform apply' command."
match "$command" "terraform destroy*" "Do not use 'terraform destroy' command."
match "$command" "terraform import*" "Do not use 'terraform import' command. Write import block in Terraform code instead."
match "$command" "terraform plan*" "Do not use 'terraform plan' command. Use 'mise run terraform:[project]:[module]:plan' instead."
# gcloud
match "$command" "bq query*" "Do not use 'bq query' command directly. Use 'mise run tools:gcloud:run-bq' task instead."
# dbt
match "$command" "uv run dbt*" "Do not use 'uv run dbt' command. Use 'mise run dbt:[command]' instead."
match "$command" "*dbt*run*--target*prd*" "Permission denied to run dbt commands in the 'prd' environment."
# git
match "$command" "gh pr checks*" "Do not use 'gh pr checks' command directly. Use 'mise run tools:git:wait-pr-checks' task instead."
match "$command" "git pull --rebase" "Do not use 'git pull --rebase' command. If you need to latest changes, use 'git fetch && git rebase origin/main' instead."
match "$command" "git -C*" "Do not use 'git -C *' option. Use git commands in the repository root directory."
match関数に実際に実行されたコマンド・禁止するコマンドのglobマッチ条件・禁止条件にマッチしたときに返すメッセージを与えられるようにして、任意のコマンド呼び出しをリジェクト出来るようにしています
terraform apply のように単に禁止したいものから、別のコマンドが正しい場合の誘導が出来るので大変重宝しています
設定してないなら絶対やったほうが良いです。イチオシのフィーチャー
プロジェクトやコードの意図や意味を正しく読み取ってもらえるような構造にする。例外的な構造を作らない。作っちゃったら直させる。とにかく誤った解釈をさせない
getUser関数を呼び出すとusersテーブルのレコードが更新される、みたいなコードを発見したら適切な意図を反映した名前にリファクタリングしましょう
・・・というような話です
この辺はかなり 人間に近似 出来る場所で、とにかく読み違いが起こりそうな場所は片っ端から直していくべきです
コードの修正コストがとても低くなった現在はこれを撲滅する活動のROIが見合うので、どんどんやるべきです
むしろリターンが増えています、彼らのコードリーディングの品質はモデルが同じならかなり似た性能になるからです（人間チームの場合は人ごとのばらつきはめちゃくちゃ大きいことに起因してリーダブルかどうかの議論はかなり難しい。しかし対LLMはその限りではない、というのが滅茶苦茶大きい差分）
実行環境の安全性を確保する
以下のコマンドを実行されて問題ない人はこの章をスキップできます
terraform destroy
rm -rf ~
git push --force origin main
はい。
まあ危ないことをやることがあるので、安全にやれるようにガードレール作りましょうやって話ですね
主に自分が取り組んでいるのは以下の2つです
- Apple Seatbeltを使う
- クラウドやその他APIでアクセス可能なサービスの権限を絞る
Apple Seatbeltについては以下の記事が参考になります
Claude CodeならSandbox機能があるので、以下の記事などを参考に利用しても良いでしょう（自分はちょっと調べたときに不都合な挙動があったのでApple Seatbeltを直接利用し続けてます）
クラウドサービスの権限を絞る、はまあそのまんまです
Google Cloudのリソースを破壊できる権限とか持ったままにしないでちゃんと権限を最低限に絞って運用しましょうという話ですね
改善用のプロセスを1、2ほど設けておく。改善点を見つけ次第そこで細かな改善をすぐにやらせる。特にAgentが頻繁に誤解したり失敗するような状況が発生していたらそれを優先して潰す
実践編4点目です
決定性のある部分を頑張る でも述べましたが、とにかくAgentが上手いこと動いてくれるようにし続けないと困るので、そのためのセッションをちゃんと空けておく、という運用をしています
まあそれだけです
ターミナル1windowを分割しているのでふと目をやると迷走してる、みたいなのは割と観測しやすいようになってます
で、実際にそれを観測したら、止めて、何してるのかを聞いたり、なんでそういう勘違いしたかを聞いたり[3]して改善する、ということをしています
こういう改善の積み重ねで「思った通りのアウトプット」に繋がっていくので欠かさずやっていくのが大事だと思います
最低限の情報収集
心構えのところで「細かいことはいいからまず使え！」というような話をしましたが、さすがに改善を重ねていくのにAgentの情報収集をしないのはキツいです
基本的なAgentツールの機能や、LLMの原理的な話、プロンプトテクニックといった情報があるのとないのとでは出来ることが結構変わってきます
先述した↓の通り、使い始めて数十倍の生産性を得られるようになったなら、そこに1.5倍の倍率をかけるのはめっちゃデカいって話ですね
- Agentを利用することでかかるそもそもの人間の生産性への倍率: 2~数十倍
- ツール選定や機能を使いこなすことでかかるAgentic Codingの生産性への倍率: 1.2~1.5倍
自分の情報源はほとんどXです
話題になってるようなことや、強いエンジニアの人の思考・発想を参考にして自分のリポジトリに転用できないか？を考えて取り込む、といったことをしています
（計画ファイルのフォーマットなんかはまさにXでバズってたところが起点でしたね）
あと個人的にはAnthropicの公式ドキュメントがかなりいいと思っているので、Agent上手く利用するのに情報収集したいと思ったなら読みにいってみると良いと思います
マジでClaudeに限らずAgentを利用するうえでの大事なことが書いてあります。 こんなわけわからん個人の書いた記事を読むより価値があると思うぞ！
まとめ
ということで一ヶ月で450件に迫る勢いで開発出来ている自分のあれこれをまとめてみました
これはなんかちょっと良いこと風のことを書くんですが、Agentを利用した開発って自分のこれまでの開発人生の経験・知識・技術を総動員してアウトプットに繋げられてる感覚があってめっちゃ楽しいんですよね
人間に近似して改善、みたいなのも、チームでの開発活動をしてきた経験からのアプローチだし、Agentに良いアウトプットを出させる設計や段取りをするのとかも完全にこれまでの開発の経験を元にしているし・・・
Agentという新しい技術をキャッチアップしてそれに適応していく、という営みに自分のこれまでの人生が現れているって感じるんですよね。それでアウトプットに繋がってるのがまーじで面白いなと日々感じています
この辺のAI系ツールにお金出してくれて使わせてくれる会社・環境に感謝しかない・・・
感想とは別の話もします
この記事に書いた通りのことをやっているので、人間ボトルネックは計画策定とPRのレビューになっていることが分かります
今後ここを更に効率よく進める方法は模索していきたいなあとは思っています
さすがに今のやり方だとこれぐらいで頭打ちだと思うので・・・
とはいえ、出来るとしたらPRのレビューすらスキップってことになってしまい、それを・・・やるのか・・・？という悩みは日々抱えています
いつかそこも任せられる日が来るんだろうか・・・
まあ色々トライしてみたいですね
Claude Codeに書かせてCodexにレビューさせるのが良い、みたいなのも聞きますし、そうやって品質を上げられたらもしかしたら・・・？と思わんでもないので。
「とにかくやれ」の精神でやっていこうと思います
さらに余談
この文章は人間成分ほぼ100%のオーガニック出力となっています
ここまで普段の開発にめちゃ使い倒している話をしていたのにここには活用できてないんかよ！っていう
いや〜、自分の納得行く出力得られないんですよね〜（出力の改善も自分の妥協ラインを変える事もできてない）
その辺も課題感はあります
そもそも「とにかくやれ」をやれていない部分ではあるんですが。
余談でした
おわりに
ということで、自分がClaude Codeを使い込んで得た考えやらを書いてきました
ホントは実践編で使ってるカスタムコマンドの全文とかスクリプトとか色々書きたかったけどただでさえ文量多いのでやめました
また別の記事として書けたらいいなと思ってます
ここまでお読みいただきありがとうございました
Discussion