お疲れ様です！IT業界で働くアライグマです！
個人開発している開発関連ニュースのキュレーションサービス「DevPick」は、Claude CodeやCodexといったAIコーディングエージェントに、Issueの実装からマージまでを任せて開発しています。その消費を減らそうと、簡単なIssueだけを別のAIエージェントへ自動で回す「振り分け」の仕組みを作りました。今回は、その仕組みを判定だけで1週間動かして数えた結果と、2026年10月10日に廃止を決めた経緯をまとめます。
Issueを軽量モデルで判定し、Julesへ回す仕組みを作った
DevPickでは、Issueを1件選ぶと、主役のAIエージェント（Claude CodeやCodex）が実装、PR作成、AIレビューへの対応、CI、マージ、本番デプロイの見届けまでを一通り行います。便利な反面、どんなに小さなIssueでも、毎回この重い流れが最初から最後まで動きます。AIのサブスクリプションには使える量に上限があるので、その枠の消費が気になっていました。
そこで考えたのが、「受け入れ条件がはっきりしていて、範囲も狭いIssueだけを、別のエージェントに任せる」ことです。任せる先は、Googleの自律型コーディングエージェント「Jules」です。それまでも手動でJulesへ依頼することはありました。これを、Issueに着手するときに自動で判定して振り分けるようにしたかったのです。
判定には、TypeSafe AIが提供している「Jev」というモデルを使いました。文章を生成するのではなく、決まった形の判定結果と、その確信度を返すことに特化した安価なモデルです。2026年9月20日に振り分け候補を出すスクリプトを入れ、10月3日に、Issueへ着手する手順の中から毎回呼ぶようにしました。
いちばん気にしたのは、任せてはいけないIssueを任せてしまうことです。そのため、Jevのスコアだけでは振り分けない作りにしました。判定は次の順で進み、どこか1つでも引っかかれば、いつもどおり主役のエージェントが担当します。
- 担当者や作業方法が明示されているIssueは振り分けない
- Jevを呼ぶ前に、手元のルールで除外する。認証・権限、DB・マイグレーション、並行処理、原因不明の調査、設計変更、デプロイ・CI・課金に関する語を1つでも含むもの、受け入れ条件の箇条書きがないもの、受け入れ条件が7項目以上か本文が2,500文字を超えるものが対象
- 残ったものだけJevで採点し、スコアが0.70以上なら「定型（Julesへ）」と判定する。Jevが使えないときや応答がおかしいときは、主役のエージェントに戻す
外部のAPIにはIssueのタイトルや本文を送っていません。手元で数えた文字数、チェックリストの項目数、コードブロックの数、危険な語の分類ごとの件数だけを送っています。
IT女子 アラ美
ITアライグマいきなり自動依頼にせず「判定だけ」で1週間動かした
スクリプト自体は、Julesへの依頼まで自動で行えるように作ってありました。ただ、10月3日に着手手順へ組み込んだときは、判定結果をログに残すだけにしました。「Julesへ」と判定されても実際には依頼せず、主役のエージェントがそのまま実装します。こうすると、振り分けが本当に役に立つのかを、実害なしに数えられます。
判定だけにしたのは、誤った振り分けがどれくらい出るかを先に確かめたかったからです。実際、同じ10月3日に過去のIssueで試した結果も、あまり心強いものではありませんでした。過去にJulesへ依頼した14件と、直近にクローズした22件の計36件を判定させた結果が次のとおりです。
| 判定結果 | 件数 |
|---|---|
| 手元のルールで除外 | 26件 |
| Jevのスコアが閾値未満 | 6件 |
| 定型（Julesへ） | 4件 |
良かった点もあります。過去にJulesへ依頼した14件のうち、主役のエージェントが作り直したり大きく手直ししたりしたのは4件でした。その4件は、どれも手元のルールで除外されていました（認証まわりが1件、DBまわりが3件）。危ないIssueを外すという役目は果たせていたことになります。
一方で、直近の22件で定型と判定されたのは1件だけでした。振り分けられる割合は約1割にとどまり、主役のエージェントの作業を減らせるのも同じくらいが上限だと見込めました。また、Jevのスコアは同じ入力でも実行ごとに0.03程度揺れました。最初は閾値を0.55にしていましたが、アルゴリズムを変えるIssue2件が定型と判定されたため、0.70に上げてその2件を外しています。たった2件に合わせて決めた値なので、閾値として信頼できるかには不安が残りました。
そこで、自動依頼を有効にする条件を先に文書へ書いておきました。
- 判定ログに「Julesへ」の判定が10件以上たまっていること
- その10件以上について、実際に主役のエージェントが実装した結果と見比べ、「Julesに任せていたら再作業になった」と判断できるものが1割以下であること
- Julesの利用上限を確認していること（このときは1日100セッションで、依頼の頻度からは制約にならない見込みでした）
条件を満たしたら、依頼まで行うように切り替えるPRを出す、という段取りです。
IT女子 アラ美ITアライグマ1週間の結果：124件中、定型と判定されたのは5件
2026年10月3日から9日までの判定ログは310行になりました。ただし、このうちIssue番号が付いているもの、つまり実際にIssueへ着手したときの判定は124件です。残りの186行はIssue番号がない判定で、これについては後の章で説明します。
| 区分 | 件数 |
|---|---|
| Issueへの着手時の判定 | 124件 |
| うち主役のエージェントが担当（手元のルールで除外、またはJevの閾値未満） | 119件 |
| うち定型（Julesへ） | 5件 |
| 実際にJulesへ依頼した件数 | 0件（判定だけの運用のため） |
定型と判定されたのは約4%でした。事前の試験で見込んでいた「約1割」をさらに下回っています。119件のほとんどは、手元のルールで除外されたものです。Jevで採点したうえで閾値に届かなかったのは3件だけでした。危ない語を1つでも含めば外す、という保守的なルールの前で、ほとんどのIssueが止まっていたことになります。
この結果を、作業量の面から見直してみました。仮に自動依頼を有効にしても、Julesが担当するのは実装とPR作成までです。そのあとのAIレビューへの対応、CI、マージ、デプロイの見届けは、結局主役のエージェントが引き継ぎます。つまり、減らせるのは全体の約4%のIssueの、しかも実装部分だけです。
その一方で、判定のコストは毎回かかっていました。Issueに着手するたびに、主役のエージェントは振り分けの手順を読み、スクリプトを1回実行し、結果を解釈します。124回すべてでその分の文脈を使い、そのうち119回は「いつもどおり進める」という結論に着いていました。判定を入れてから、着手の流れが実際に変わったことは一度もありません。
IT女子 アラ美ITアライグマ定型と判定された5件の中身を見ると、2件は任せられない規模だった
件数が少ないだけなら、「判定が慎重すぎるだけで、当たったものは安心して任せられる」可能性もあります。そこで、定型と判定された5件の中身を1件ずつ確認しました。5件とも、実際には主役のエージェントが実装してマージしています。
| Issueの内容 | 実際の変更の規模 |
|---|---|
| UIのコントラスト改善（アクセシビリティ基準への準拠）と、色計算の単体テスト・設計文書の更新 | 2コミット |
| トピック検索ページを検索エンジンに公開する条件の統一 | 3コミット・17ファイル |
| 記事IDの正規でない書き方のURLを404にする | 1コミット |
| 要約ページの内部リンクの文言変更とE2Eテストの調整 | 1コミット |
| 関連トピックへの導線の追加 | 1コミット・19ファイル・+622行 |
このうち、トピック検索ページの公開条件の統一は、SEOに関わる複数の領域のロジックをまたいで変える作業でした。関連トピックへの導線の追加は、19ファイル・600行を超える新機能です。どちらも「対象が限定され、受け入れ条件が明確な定型作業」とは言えません。定型と判定したこと自体が誤りでした。
この2件をJulesに任せていたら、主役のエージェントが作り直すか、大きく手直しすることになっていただろうと判断しました。実際には依頼していないので、あくまで変更の規模と性質から見た評価です。それでも、5件中少なくとも2件、つまり40%が再作業に当たる計算になります。事前に決めた有効化の条件は「再作業が1割以下」でした。件数も「10件以上」に届いておらず、どちらの条件も大きく満たしていません。
手元のルールが本文の語や受け入れ条件の数を見ているのに対して、この2件はそうした目印に引っかからないまま、変更が大きくなる性質のIssueでした。文字数や項目数といった表面の情報だけでは、作業の大きさまでは見分けられなかったことになります。
IT女子 アラ美ITアライグマ計測ログ自体がテストで汚れていた
先ほど後回しにした、Issue番号のない186行の話です。内訳は、「受け入れ条件が不明確」と判定されたものが125行、「Jevが使えない」と判定されたものが58行などでした。実際にIssueへ着手したときの判定ではありません。
廃止を検討するIssueを書いた時点では、「テストがスクリプトを呼んだときに、本物のログへ書き込んでいるのではないか」と疑っていました。これを裏付ける事象に、その日の夜（2026年10月9日の23時58分）に別の作業の途中で出くわしました。CIを速くするための調査で、開発ツールのテストを手元で実行したところ、ルーターのテストが1件失敗したのです。
そのテストは、APIキーがない状態での動作を確かめるもので、APIキーの環境変数を外してから判定を呼んでいました。ところが、スクリプトは環境変数がないとき、リポジトリ直下の.envファイルからもAPIキーを読みにいきます。手元の.envにはキーが入っていたので、テストが実際にJevのAPIを呼んで判定していました。さらに、ログの書き込み先を差し替えていなかったため、テスト実行と同じ時刻に、本物のログへ次の3行が追記されていました。
{"ts": "2026-10-09T23:58:03+0900", "mode": "judge", ..., "route": "manual", "reasons": ["unclear_requirements"], "score": null, "issue": null, ...}
{"ts": "2026-10-09T23:58:04+0900", "mode": "judge", ..., "route": "manual", "reasons": ["unclear_requirements"], "score": null, "issue": null, ...}
{"ts": "2026-10-09T23:58:04+0900", "mode": "judge", ..., "route": "jules", "reasons": ["jev_routine"], "score": 0.81, "issue": null, ...}"issue": null、つまりIssue番号のない行です。3行目はテストの入力が「定型」と判定された行で、本物の判定と同じ形でログに混ざっていました。
これで分かった問題は3つあります。
- 評価に使うはずのログに、テスト由来の行が混ざっている
.envにキーがある環境では、テストを実行するたびに外部のAPIを呼んでいる。費用もかかり、レート制限にも当たり、結果も毎回同じとは限らない- その結果、手元でテストが失敗する
テスト由来と確認できた行は、どれもIssue番号のない行でした。Issue番号の付いた124件だけを数える今回の集計からは外れています。ただ、仕組みを残すのであれば、テストが本物のログに書かず、APIキーも読まないように直す必要がありました。
IT女子 アラ美ITアライグマ廃止を決めた理由と、残したもの
ここまでの材料を並べると、判断は難しくありませんでした。
- 定型と判定されるのは約4%で、減らせる作業はその実装部分だけ
- 定型と判定された5件のうち少なくとも2件は任せられない規模で、有効化の条件（10件以上・再作業1割以下）を大きく満たさない
- 判定のための手順・実行・解釈のコストは、Issueに着手するたびに毎回かかる
- テストが外部APIを呼び、ログを汚すという実害が出ている
残す場合は、テストの修正に加えて、有効化を判断する期限と、未達のときに廃止する条件を決め直す必要がありました。それだけの手間をかけても、得られる効果の上限は約4%です。そこで、2026年10月10日に仕組みごと廃止しました。廃止を検討するIssueを書いてから、翌日のことです。
廃止は1つのPRで行い、次のものを削除しました。
- 振り分けの判定スクリプトと、そのテスト
- Issueへの着手手順にあった判定のステップ。Issueを選んだら、そのまま着手に進むようにした
- Claude Code用とCodex用、それぞれの手順書にあった振り分けの記述
差分は13ファイルで、削除が約1,300行でした。同じPRで、スクリプト名がリポジトリ内に1件も残っていないことと、関連するテストがすべて通ることを確認しています。
ただし、Jevを使う仕組みのすべてを捨てたわけではありません。PRのレビューの前に置いている、AIレビューを省略してよい変更かを判定するゲートと、記事分析の前にAIと無関係な記事を除外する判定は、別の施策として残しています（レビューの負担を減らす工夫は、AIコードレビューを前回からの差分だけに絞った増分レビューの記事にも書きました）。Julesへの手動での依頼も、これまでどおり使えます。
1週間の集計結果と廃止の経緯は、同じPRで設計文書に記録しました。仕組みは消しても、なぜやめたのかは読み返せるようにしています。
IT女子 アラ美ITアライグマまとめ
AIエージェントへのIssueの自動振り分けを、判定だけで1週間動かしてから廃止しました。124件のうち定型と判定されたのは5件で、そのうち2件は任せられない規模でした。減らせる作業の上限が小さいうえに、判定のコストは毎回かかり、テストがログを汚す実害もありました。
振り返ると、効いたのは次の2つだったと思います。
- いきなり自動で依頼せず、判定結果をログに残すだけで動かしたこと。誤った振り分けが出ても、実害がないまま数えられた
- 有効にする条件（件数と再作業の割合）を、着手手順へ組み込む段階で文書に書いておいたこと。1週間後は、その条件に数字を当てはめるだけで結論が出た
AIに任せる範囲を広げる仕組みは、作った時点では効果がありそうに見えます。ただ、実際にどれくらいの作業が対象になるのかは、動かして数えてみるまで分かりませんでした。今は、新しい自動化を入れるときほど、最初は判定だけで動かして数え、続けるかやめるかの条件を先に決めておくのがよいと考えています。
IT女子 アラ美ITアライグマ
