1000個のAPIをAIループで監査してみた。人間はどこに残るのか

今回組んだのは、AIに調査してほしい機能一覧を渡すと、それを分解して監査し、結果を『Jira』のチケットにして、そのチケットを別のAIがどんどん消化していく、という仕組みです。

定期実行でAIが未着手のチケットを拾って、プルリクをどんどん上げてくる。そういう流れです。

段階はざっくり4つあります。機能の監査（調査）、チケット化、チケットに対する調査と修正、そしてレビューですね。

ループエンジニアリングって、人間がAIを使うんじゃなくて、AIが主導で回して、人間がワークフローに組み込まれる、みたいによく言われるんですよね。まさにそういう状態になっているのが面白かったんです。

最初の監査は、1000個あるAPI一つ一つに対して、ある特定のテーマでバグがないか調べて、あれば報告して記録に残す、というものです。

ここでポイントなのは、AIに「1000個APIあるから不具合見て」とやると、絶対にコンテキストが足りなくなることなんですよね。

なので、API一覧を用意して、5個ぐらいずつwhileループで回しています。claude -pのコマンドで、API5個ごとにclaudeのセッションを作って調査させる感じです。

5個に対する調査なら『Sonnet』でもできるかな、というくらいの粒度で、コンテキスト溢れによるハルシネーションを起こしにくくしている訳です。

適切に小さい粒度で1セッションに渡すことでコンテキストを節約して精度を高める、というのはポイントかもしれないですね。

もう1つ気をつけているのは、「バグ一覧」ではなく「バグ候補一覧」くらいのノリでやらせていることです。

だから400箇所出たとしても、400個バグを見つけたわけじゃなくて、あくまで候補だぞ、と。候補だから後で担当者が頑張ってね、という扱いにしています。

監査結果はJSONで出てきます。それを『Codex』（AstraのCodex）に渡して、Jiraチケットに変換してもらいます。

400個そのままチケットにするんじゃなくて、結合できるものは結合しながら、作業しやすい粒度にまとめてもらう。結果として80件ぐらいのチケットになる感じですね。

チケットには全部、「これは不具合候補なので、指摘が間違っている可能性がある。自分で調べて判断してね」という一文を入れてあります。

これは人間でも同じですよね。PMや顧客報告のチケットが回ってきても、「対応不要ですね」とか「この対応方法じゃダメだからもう少し考えます」というのがいっぱいあるわけじゃないですか。だからインプットは暫定なものとして渡すのが重要かなと思います。

チケットは1つのエピックの下に子タスクとしてまとめて作っておきます。そうすると『Devin』のAutomationを起動したときに、そのエピック配下の未着手チケットを拾って対処し、プルリクを上げてくれるんですよね。

DevinのAutomationは、朝8時、10時、12時、14時、16時と、1日に5回起動して、未着手のものを1個ずつ進めていきます。

プルリクができたら、バックエンド開発の人間にランダムでレビュー依頼が飛びます。依頼を受けた人はそのJiraチケットも割り当てられるので、マージまで面倒を見てね、という形にしています。

実装自体はAIがやるんですけど、マージまでを各担当で分担できるので、チームでめちゃくちゃ大きいことができる感じになります。

チケットの内容が妥当なら、Devinはそのまま修正してプルリクを上げてきます。妥当じゃない場合は、その根拠を書いて『Slack』で人間に報告してくるんですよね。

報告を受けた担当者は、その主張が妥当だねとなれば見送りのステータスにする。そうやって仕事が進んでいきます。

直さない、見送りにするワークフローも組めたのがすごく良かったです。直さないことも成果物にするのがやっぱり良いんですよね。

工夫している点として、Devinの実装時のスキルに、今回対象にしているある種のエラーを避けるためのスキルを入れてあります。だからDevin自体も最初から適切にエラー対処できるようになっている訳です。

さらにプルリクのCIのところに、その問題に特化したレビュー担当を置いています。Devinがやってきたものが本当に直っているかを、もう一回AIがレビューするんですよね。

しかもこれは結構頭のいいモデルを使っていて、レビュー品質がかなり高い。指摘が来たらDevinのAutomationが勝手に拾って直していく。最終的にレビュー担当の人間が「大体OKですね」とマージする、という流れです。

昨日このワークフローを組んで、1個試しにやらせてみたらいい感じにできたので、じゃあこれでいこうか、と。2週間したら80個ぐらいのチケットが全部捌ける計算になっていて、あまり人間が作業していないのにどんどん進むんですよね。

AIがどんどん作業して、人間がレビュー担当としてワークフローに組み込まれている。これがめちゃくちゃ面白くて、画期的やなと思いました。

ただ、やってみて思ったのは、人間側は承認ボタンを押すだけにはならないな、ということです。

修正プルリクであれば、そもそも指摘が妥当か、仕様に合っているか、という判断はやっぱり必要なんですよね。CIでClaudeによる自動レビューを挟んではいますが、スルーで承認、というのはなかなかならないです。

もう少ししたらなるかもしれません。バックエンドの開発で言えば「ここはマジで危ないな」という勘所はあるので、そこだけ見て、小さい修正ならスルーで承認、というのは結構間近に来ている気はします。

性能観点のCIもレビュアーに入れていて、たとえばSQLを直したときに、それが本番環境に負荷を与えないかをステージング環境で負荷試験してくれるAIレビュアーもいます。そいつがいれば意外に全部スルーでいけるんじゃないか、という感じはありますね。

まあ仕様が間違っていたら危ないので、仕様だけは確認する、という感じかな。

今の一般的なエンジニアのAI活用って、チケット1個につき自分でコーディングエージェントに頼んで、プルリクを出して自己レビューする、くらいだと思うんです。

でもこうやってチームを巻き込んで、大量のプルリクを1日にボコボコ生成して、大量の機能修正を行う、というのはループという概念がないとできないんじゃないかと思って、今日は紹介してみました。

面白かったら#素人ゲーム制作者の日常でXなどでシェアお願いします。ゲーム制作とAI活用のメルマガもやっているので、概要欄のリンクからぜひ登録お願いします。

それと、僕が作っている『Very Long C&P物語』、Steamで体験版を公開中です。明日9月12日の土曜日に体験版の大規模アップデートをかまします。新ステージのお昼寝部屋風や、新キャラの鳴神の能力が使えたりと、結構やっています。体験版終了のエンディングも作ったので、ぜひプレイお願いします。じゃあまたね。バイバイ。

まとめ

1000個のAPI監査を、5個ずつの監査・チケット化・AIによる修正・レビューの4段階に分けてループで回した実例です。実装はAIがどんどん進めますが、指摘が仕様に合っているかの判断は人間に残る、というのが今のところの実感です。

• 大量の監査は小さい粒度（5個ずつ）に分けてループで回すとコンテキスト溢れを防げる
• AIの指摘は「バグ候補」として渡し、妥当性の判断とマージは担当が面倒を見る
• 「直さない・見送り」もワークフローの成果物として組めたのが良かった
• 承認ボタンを押すだけにはまだならず、仕様と勘所の確認は人間の役割として残る