自社のバックログのために作ったAIエージェントを、今度はあなたのチームに

課題

Ostorlabは、モバイルアプリ、Webアプリ、API、コードの問題を見つけるツールを作っています。それが仕事であり、そこにはコストが伴います。見つけた問題はすべてチケットになるのです。

当社自身のプラットフォームも例外ではありません。ログにはエラーが現れ、バグが報告され、スキャンが問題を見つけ、そのひとつひとつがチケットになります。そしてチケットは次々とやってきました。

その多くは難しいものではありませんでした。スタックトレースが該当する行を正確に指し示し、エラーメッセージが何が問題かを伝え、修正は数行のコードで済むことも少なくありませんでした。それでも誰かが手を止めなければなりません。チケットを開いて読み、コードを探し、修正を書いてテストし、プルリクエストを作成する必要があります。

そのため、簡単なチケットは後回しにされました。難しいからではなく、誰もがより難しい仕事で手一杯だったからです。小さな修正が何日も放置されることもあり、バックログは膨らんでいきました。増えたのは難しい問題ではなく、誰も手を付ける時間のない簡単な問題でした。

機会

それらのチケットをよく見ると、あることに気付きました。その多くは、そもそも人が書いたものではなかったのです。エラーログやスキャン結果から自動生成されたもので、それらの情報源にはエラーメッセージ、スタックトレース、ファイル、行といった詳細がすでに含まれています。チケットには、何が壊れたのか、どこで壊れたのか、そして多くの場合はなぜ壊れたのかが、すでに書かれていました。

当社は、エンジニアが修正に取りかかるのに必要なものをすべて提供するよう、これらのチケットを設計していました。そして、エンジニアが修正に取りかかるのに必要なものは、AIエージェントが必要とするものでもあると気付いたのです。情報はそろっていました。足りなかったのは時間でした。

そこで、シンプルな問いが生まれました。エージェントがチケットを引き受けて修正を始められたらどうだろうか、という問いです。

コーディングエージェントは、すでにコードを読み、エラーを追い、修正を書くことができました。しかし、そのほとんどは依然として、開発者が起動してプロンプトを入力するのを待っていました。当社が求めていたのは別のものでした。エンジニアが使うのを覚えておかなければならないツールをもう一つ増やしたいのではなく、仕事がすでに存在する場所、つまりチケットの中で仕事が始まるようにしたかったのです。

チケットが届き、エージェントがそれを引き受け、プルリクエストが作成され、エンジニアがそれをレビューする。エンジニアは主導権を保ったまま、繰り返しの作業だけを省けます。そして、各チケットはそれぞれ専用のエージェントに割り当てられるため、作業はバックログに合わせてスケールします。処理すべきチケットの数だけ、エージェントが並列に動きます。

最初のバージョン

当社は意図的に小さく始めました。一つの仕事を持つ一つのエージェントを作ったのです。その仕事とは、バグチケットを読み、それを修正するプルリクエストを作成することです。

当社はそれをRubberduckと名付けました。チームの全員がこの名前を気に入っているわけではありません。それでも定着しました。

流れはシンプルでした。エンジニアは、チームメイトに割り当てるのと同じようにチケットをRubberduckに割り当てます。その後はエージェントが引き継ぎます。

• チケットとそのコメントを読む
• 該当するコードを見つける
• 何が問題だったのかを突き止める
• 修正を書いてプルリクエストを作成する
• そのプルリクエストへのリンクを添えて、チケットにコメントを残す

レビュー担当者が変更を求める場合も、新しいツールは必要ありませんでした。同僚に対してするのと同じようにコメントを残せば、Rubberduckがそれを読んで作業を更新しました。

それだけでした。ダッシュボードも設定もなく、一つのエージェントに一つの仕事だけです。完璧ではありませんでしたが、実際のチケットで働かせるには十分な出来でした。

自分たちで使ってみる

当社はRubberduckに自社のバックログの実際のチケットを与え、Rubberduckはプルリクエストを作成し始めました。良いものもあれば、そうでないものもあり、ミスのひとつひとつから学びがありました。

症状ではなく原因を見つける：初期の修正は、エラーを解決するのではなく隠してしまうことがありました。そこで、慎重なエンジニアのように働くようエージェントに教えました。エラーを読み、その本当の原因までさかのぼって追跡し、再現してから修正するのです。

人間に向けて書く：最初のプルリクエストのタイトルは、チケットからエラーメッセージをコピーしただけのものが多く、長い一覧の中では読みにくいものでした。今では、エージェントは何を修正したかを伝える短いタイトルを書きます。

分からないときはそう言う：チケットに十分な情報がないこともありました。エージェントは推測し、推測は悪い修正を生みます。そこで、立ち止まって質問するよう教えました。今では、チケットが修正済み、一部修正済み、ブロック中、追加のコンテキストが必要、のいずれであるかを報告できます。

仕事を最後までやり遂げる：テストが失敗しているプルリクエストは修正ではありません。そこで、エージェントは今ではチェックが通るのを待ち、壊れたものを修正します。

当社のルールに従う：どのチームにも独自のコードの書き方があります。当社はエージェントにスタイルガイドを与えました。また、メモリも与えたため、あるチケットで得た教訓が次のチケットで役立ちます。

シークレットを手の届かない場所に置く：エージェントはコードにアクセスする必要がありますが、パスワードやシークレットを見るべきではありません。そこで、それらをエージェントの手の届かない場所に完全に移しました。シークレットは実行時に注入されるため、エージェントはそれを使うことはできても、読むことは決してできません。

Rubberduckのプルリクエストが、他の全員のものと並んでレビューキューに現れ始めたとき、当社はRubberduckを実験とは考えなくなりました。当社はそれらを同じようにレビューしました。Rubberduckはチームの一員になっていたのです。

より大きな気付き

Rubberduckが機能するようになると、チームのメンバーはさらに多くを求めるようになりました。

「新しいチケットを緊急度で並べ替えられないか」 「検出結果を自社のコンプライアンスルールと照合できないか」 「毎週月曜日に未解決のチケットをレビューできないか」

どれも良いアイデアでしたが、Rubberduckにはできませんでした。その仕事はRubberduckに組み込まれていたからです。コードを修正すること、それだけでした。当社はすでに、コードを書く代わりに作業を計画する2つ目のエージェントを作っていましたが、それにも同じ問題がありました。その仕事も組み込まれていたのです。新しい仕事のたびに新しいエージェントを作り続けることもできましたが、それでは終わりがありません。

Rubberduckを使うのにセットアップは不要でした。しかし、新しいエージェントを作るたびにセットアップが必要でした。長い設定ファイルを手で書く必要があり、そこではすべての名前が正確でなければなりませんでした。機能はしましたが、もっと良い方法があるように感じられました。

そのとき、当社は本当の機会に気付きました。問題は決して「コードを修正するエージェントが必要だ」ということではありませんでした。問題は「チケットの中に、誰も手を付ける時間のない仕事がある」ということであり、コードの修正はその種の仕事の一つにすぎなかったのです。

ですから、エージェントは決まった仕事を持つべきではありません。チームが与えるどんな仕事でも引き受けるべきであり、その設定は設定ファイルを書くようなものではなく、フォームに記入するような感覚であるべきです。平易な言葉で仕事を説明し、モデルを選び、実行するタイミングを選ぶのです。

当社が作ったもの

当社はその考えを軸にチケットエージェントを作り直しました。今ではエージェントは一種類だけで、仕事を与えるまでは何の仕事も持っていません。フォームで、いくつかのステップで設定します。

名前を付ける：好きな名前を付けられます。慎重に選んでください。名前は定着します。当社はそれを知っています。

仕事を与える：エージェントが何をすべきかを平易な言葉で書きます。どこから始めればよいか分からない場合は、当社のセットアップガイドが、当社がその過程で学んだ教訓とともに手順を案内します。

モデルを選ぶ：自社のAIプロバイダーのキーを使うことも、Ostorlabが提供するモデルで実行してクレジット残高で支払うこともできます。各実行は開始時にクレジットを確保し、使わなかったクレジットは戻ってきます。

実行するタイミングを選ぶ：ルールを追加します。ルールは次のタイミングで発火できます。

• チケットに何かが起きたとき：作成された、割り当てられた、再オープンされた、新しいコメントが付いた、期限を過ぎた、
• スキャンが完了したとき、
• または、毎週月曜日の朝のようなスケジュールに従って

各ルールは絞り込むことができます。たとえば、クリティカルなチケットだけ、あるいは一つのアプリのスキャンだけ、といった具合です。

自社の仕事のやり方を教える：スキル、つまりチームの仕事の進め方を説明する短いガイドを与えることができます。また、メモリを与えることもでき、あるチケットで学んだことが次のチケットで役立ちます。

自社のツールに接続する：エージェントはMCP（Model Context Protocol）サーバーを使えるため、Ostorlab自身のツールだけでなく、チームがすでに使っているツールとも連携できます。

人と並んで働く：チームメイトに割り当てるのと同じように、チケットをエージェントに割り当てます。一つのチケットに両方を割り当てることもできます。エージェントは自分の担当部分をこなし、人が主導権を保ちます。

テンプレートから始める：ゼロから始めたくない場合は、脆弱性のトリアージやコンプライアンスレビュー用の既製のエージェントを使えます。

テンプレートのルールは最初はオフになっているため、指示するまで何も実行されません。

チケットエージェントがチームのためにできること

当社はまず自分たちのためにこれを作りました。そして今、あなたのチームで使える準備が整いました。

エージェントは、バグの修正、新しいチケットの仕分け、コンプライアンスのレビュー、毎週月曜日の確認などを行えます。その仕事、実行するタイミング、触れてよい範囲は自社で決められます。そして最終的な判断は常に人が下します。

自社のバックログがかつての当社のような状態なら、チケットエージェントが簡単なチケットを片付け、チームは難しいチケットに専念できます。

当社と同じように、小さく始めてください。テンプレートを選び、テスト用のチケットを一つ割り当て、エージェントの報告を読んでから、次に何を任せるかを決めましょう。

チケットエージェントはプラットフォームのAgents → AI Agentsにあります。設定の全体については、チケットエージェントのセットアップガイドで最初から最後まで解説しています。

よくある質問

Ostorlabのチケットエージェントとは何ですか？ チケットのバックログを処理するAIエージェントです。平易な言葉で仕事を与え、モデルを選び、実行するタイミングのルールを設定します。バグを修正してプルリクエストを作成したり、新しいチケットをトリアージしたり、コンプライアンスをレビューしたり、スケジュールに従って実行したりでき、その作業は常に人がレビューします。

エージェントはいつ実行すればよいかをどのように知るのですか？ ルールを追加します。ルールは、チケットに何かが起きたとき（作成された、割り当てられた、再オープンされた、コメントが付いた、期限を過ぎた）、スキャンが完了したとき、または毎週月曜日の朝のようなスケジュールに従って発火できます。各ルールは、たとえばクリティカルなチケットだけ、あるいは一つのアプリのスキャンだけに絞り込めます。

自社のAIモデルを使えますか？ はい。自社のAIプロバイダーのキーを持ち込むことも、Ostorlabが提供するモデルで実行してクレジット残高で支払うこともできます。各実行は開始時にクレジットを確保し、使わなかった分は戻ってきます。

エージェントはエンジニアに取って代わるのですか？ いいえ。チームメイトに割り当てるのと同じようにチケットをエージェントに割り当て、一つのチケットに両方を割り当てることもできます。エージェントは繰り返しの作業を担ってプルリクエストを作成し、人がそれをレビューして最終的な判断を下します。

Ostorlab以外のツールに接続できますか？ はい。エージェントは、リモート、ローカル、Ostorlab OXOのいずれのMCP（Model Context Protocol）サーバーも使えるため、チームがすでに使っているツールと連携できます。

どのように始めればよいですか？ Vulnerability TriageやCompliance Reviewなどのテンプレートを選び、テスト用のチケットを一つ割り当てて、その報告を読んでください。ルールは最初はオフになっているため、有効にするまで何も実行されません。設定の全体については、セットアップガイドで最初から最後まで解説しています。

最初のエージェントの設定にお困りですか？ support@ostorlab.devまでメールでお問い合わせください。