こんにちは、タイガーチームでエンジニアをしている横塚といいます。この記事では Coding Agent へのタスク依頼を最適化していく過程を step-by-step で一緒に見ていきます。
お題は「Pull Request の作成」です。
この状況から Coding Agent (Cline, Roo Code, Goose CLI, GitHub Copilot Agent, Claude Code etc…) に高品質な Pull Request を作成してもらうことを目指します。
まずは最もシンプルな方法で Pull Request を作成してもらいましょう。
あなたは GitHub Flow で開発するシニアエンジニアです。現在のブランチの内容を元に Pull Request を作成してください。
たった二行のプロンプトですが、Coding Agent はいい感じに振る舞ってくれるでしょう。
git branch や git diff を実行したり、GitHub MCP サーバーのツールを呼び出して、Pull Request を作成してくれることは想像に難くありません。
しかし、この方法で作られる Pull Request の Description は言うなれば「品質ガチャ」状態です。指示するたびに実行するコマンド、参照する情報が代わり、結果として出力はまちまちになることでしょう。
あなたが Pull Request の Description を書く時の手順を想像してください。それをなぞるような形で指示を出すことで、出力はあなたのそれに近づきます。
例えば、このようなプロンプトを考えてみました:
あなたは GitHub Flow で開発するシニアエンジニアです。現在のブランチの内容を元に Pull Request を作成してください。1.`git branch` を実行して現在のブランチ名とデフォルトブランチ名を調べてください2. `git logs $DEFAULT_BRANCH..$CURRENT_BRANCH` を実行して、コミット履歴を調べてください3. `git diff $DEFAULT_BRANCH..$CURRENT_BRANCH` を実行して、現在のブランチでの変更内容を調べてください4. 変更内容の性質(機能追加、バグ修正、リファクタリングなど)を判定してください5. 変更内容を元に Pull Request の Title と Description を生成してください6. `git push origin HEAD` を実行して、remote に現在のブランチをプッシュしてください7. GitHub MCP サーバーのツールを呼び出して Pull Request を作成してください
このくらい明確に指示をあたえると、Coding Agent は手順通りにコマンドを実行し、Pull Request を作成してくれるでしょう。
そして品質もかなり安定するはずです。
おっと、Pull Request を作る時はテンプレートを参照するべきでした。以下のように修正しましょう
-5. 変更内容を元に Pull Request の Title と Description を生成してください+5. 変更内容を元に Pull Request の Title を簡潔な日本語で生成してください+6. リポジトリに Pull Request のテンプレートがある場合は、それを参照して Description を生成してください。テンプレートは .github/ に存在することが多いです
これで Coding Agent はテンプレートに沿って Description を書いてくれるでしょう。
いや、待ってください、もう一つ大事な開発ルールを失念していました。Description には開発の根拠となる URL も含める必要があります。Coding Agent はどうやってその URL を知るのでしょうか?教えてあげる必要がありますね。
-1. `git branch` を実行して現在のブランチ名とデフォルトブランチ名を調べてください+2. 現在のブランチ名からバックログのチケットのキーを抽出してください
こうして PR 作成プロンプトのステップ数は膨らんでいきました…
手順が多いことは複数の観点で問題です。
手順が多いことの問題点は理解できました。ではそれを解消していきましょう。
必要な情報は Agent ではなく開発者自身が収集して prompt を動的に生成するのです。
あなたは GitHub Flow で開発するシニアエンジニアです。現在のブランチの内容を元に Pull Request を作成してください。# Operations1. 変更内容を分析して、Pull Request の Title を簡潔な日本語で生成してください2. Template を参照して Pull Request の Description を生成してください3. GitHub MCP サーバーのツールを呼び出して Pull Request を作成してください# Status現在のブランチ名: {git branch の結果をここに入れる}デフォルトブランチ名: {git branch の結果をここに入れる}## Commit Logs{git logs の結果をここに入れる}## Diff{git diff の結果をここに入れる}# PR Template{リポジトリの Pull Request テンプレートをここに入れる}
必要な情報を全て事前に収集しておき、Coding Agent には「Operations」のみを実行させるようにします。(git push も自分でやるのが良いです)
すると Coding Agent は 2ターンほどで Pull Request を作成してくれるでしょう。
最終的な結果は大きく変わらないでしょうが、かかる時間とお金、そして失敗率は大きく改善されます。
当然の疑問として「え、開発者が自分でコマンド実行するのは面倒じゃない?」「AI がもっと自動でやってくれたらいいのに」と思うでしょう。
しかしここはスクリプトの出番です:
スクリプトは一度書いてしまえば、何度でも使い回せます。更に Coding Agent と違って動作の予測可能性が高いです。Coding Agent のように「たまに」失敗することもありません。動作確認に時間とお金をかける必要もなくなります。
もう一歩進んで Coding Agent に組み込まれた機能を使うのも良いアイディアです。
自分の知る限りではGoose のSharable Recipes が最もクールにこの課題を解決できます。
以下のような YAML ファイルを用意しましょう:
version: 1.0.0title: Create GitHub Pull Requestdescription: 現在の作業内容からGitHub PRを作成するためのワークフローを実行しますinstructions: | あなたは GitHub Flow による開発フローを実践しているシニアエンジニアです。prompt: | # Task 現在のブランチの内容でGitHub PRを作成してください。 # Operations1. PR タイトルと PR 本文の生成-PR タイトルは Conventional Commits仕様に従って日本語で簡潔に作成-例: `feat(auth/stg): Googleでのログインを追加`-PR 本文はテンプレートに従って作成2. GitHub PR作成-GitHub MCP サーバーを使用してPRを作成-生成したタイトルと本文を使用-エラーが発生した場合はユーザーに報告してタスクを終了する-**IMPORTANT**: PR は必ず draft として作成する3. PR URL をユーザーに報告して完了-その他の情報は不要です # Current Status-リポジトリ:{{repository}}-チケットのURL:{{ticket_url}}-現在のブランチ:{{current_branch}}-デフォルトブランチ:{{default_branch}} ## Commit Logs{{commit_logs}} ## Git Diff{{git_diff}} # PR Template{{pr_template}}extensions: # GitHub MCP Server を有効にする(詳細は省略) # https://block.github.io/goose/docs/mcp/github-mcpactivities:[]parameters:-key: commit_logsinput_type: stringrequirement: optionaldefault:"N/A"description:"現在のブランチとデフォルトブランチの差分のコミットログ"-key: current_branchinput_type: stringrequirement: optionaldefault:"N/A"description:"現在の作業ブランチの名前"-key: default_branchinput_type: stringrequirement: optionaldefault:"main"description:"デフォルトブランチの名前"-key: git_diffinput_type: stringrequirement: optionaldefault:"N/A"description:"現在のブランチとデフォルトブランチの差分の内容"-key: pr_templateinput_type: stringrequirement: optionaldefault:"N/A"description:"PR作成時に使用するテンプレートの内容"-key: repositoryinput_type: stringrequirement: requireddescription:"対象のGitHubリポジトリの名前 (例: `org/repo`)"-key: ticket_urlinput_type: stringrequirement: optionaldefault:"N/A"description:"開発の根拠となるチケットのURL"
このファイルを goose コマンドの実行時に指定するだけで、Coding Agent が「必要最小限な MCP サーバー」と「動的に組み立てられたプロンプト」で Pull Request を作成してくれます。
parameter の部分はコマンドを実行して収集します。最終的には以下のようなシェルスクリプトが完成しました:
#!/bin/bashset-eurepository=$(gh repo view --jq .nameWithOwner --json nameWithOwner)default_branch=main# Get git default branch namecurrent_branch=$(git rev-parse --abbrev-ref HEAD)commit_logs=$(git log"$default_branch..$current_branch" --pretty=format:"- %s (%an, %ad)" --date=short| jq -Rs'@json')git_diff=$(git diff"$default_branch..$current_branch"| head-1000| jq -Rs'@json')pr_template="..."# Get the contents of pull request template# Extract ticket key from current branch nameticket_url="N/A"ticket_key=sample# Replace with actual regex to extract ticket keyif [-n"$ticket_key"];thenticket_url="https://backlog.example.com/$ticket_key"figit push origin HEADgoose run--recipe /path/to/recipe.yaml\--params"commit_logs=$commit_logs"\--params"current_branch=$current_branch"\--params"default_branch=$default_branch"\--params"git_diff=$git_diff"\--params"pr_template=$pr_template"\--params"repository=$repository"\--params"ticket_url=$ticket_url"
Points:
Goose の Sharable Recipes の凄さは以下全てを同時に満たせることです:
Goose の Sharable Recipes を例に解説しましたが、大抵の Coding Agent は再利用可能なプロンプトを定義する機能を持っています。
これらのツールを使うことで近い体験が得られると思います。
とはいえさすがに任意の shell command の結果をプロンプトに埋め込むのは難しいはずで、シェルスクリプトの実行結果をクリップボードに入れて運搬するなどの作業は必要になるでしょう。
一番伝えたかったのは「単なるプロンプトチューニング以外にもできることがある」ということです。
Coding Agent を使う時は、プロンプトをチューニングすることも大事ですが、それだけでは不十分です。Workflow の要求や各ステップを精緻に定義し、決定的な処理が可能な部分はスクリプトに任せてしまうことで、LLM の弱点をカバーすることができます。
更にスクリプトの開発が Coding Agent によって圧倒的に楽になっていることも特筆すべきでしょう。これまでだったらあれやこれやとインターネットで検索しなければ実装できなかったような少々複雑なスクリプトも、LLM ならサラッと書いてくれます。
長期的なメンテナンスを考慮してもスクリプトの良さが光ります:
重要なのは、タスクをステップに分解して精緻化する論理的思考と、どのような処理がスクリプト化できるのか、しやすいかということを深く理解することです。
一方で全ての処理をスクリプトで記述しようとするのもアンチパターンです。大変で時間がかかりますし、一つ一つ丹念に組み上げたつもりのスクリプトに限って、外的環境の変化によって容易に瓦解したりするものです。Keep it simple を心がけましょう。
大事なのは LLM とスクリプトを相補的に活用することです。そうすると Coding Agent の力を最大限に引き出すことができるでしょう。
本記事では、「Pull Request の作成」という身近な題材で、Coding Agent によるワークフローの最適化について考察しました。
単にプロンプトを調整するだけでは、多くの課題に直面します。結果の予測可能性が高いスクリプトと非決定的でありつつも柔軟な LLM を上手く組み合わせることで、Coding Agent の安定性と効率性を向上させることができます。
引用をストックしました
引用するにはまずログインしてください
引用をストックできませんでした。再度お試しください
限定公開記事のため引用できません。