はじめに
私はAUDERでQAを担当しています。
最近は、AIエージェント「Devin」を使って業務の自動化に取り組んでいます。
今回書くのは、Devin のプレイブックを動作確認していたときに、こちらの理解不足もあって少しハマった出来事についてです。
今回は動作確認中の出来事で、大きな影響はありませんでしたが、実際に触ってみて初めて分かることがいくつかありました。この記事では、そのとき何が起きたのかと、使ってみて気づいた点をまとめます。
やりたかったこと
作っていたのは、チャットツールの Slack で !bug_report の後に簡単に概要を入力すると、Devin が Linear というチケット管理ツールに不具合チケットを起票してくれるプレイブックです。
プレイブックは、Devin に用意されている機能のひとつで、一定の手順をまとめて実行させるための自動化フローのようなものです。今回は、このプレイブックを使って不具合起票の流れを組んでいました。
プレイブックには、次のような処理を組み込んでいました。
- 不具合内容からタイトルやラベルを自動生成する
- 担当者、優先度、サイクルを自動で設定する
- 関連ソースコードを調査し、「Devin調査」として補足する
- 起票前にプレビューを表示し、人間の承認を待つ
特にこの承認待ちを含む部分で、こちらの理解不足もあって少しハマりました。
何が起きたか
プレイブックが完成したので、動作確認をしていました。
Devin には「子セッション」を起動して、別の Devin に作業を実行させる仕組みがあります。今回は、親の Devin が子の Devin にテスト用の不具合情報を渡し、プレイブックどおりに動くかを確認する構成にしていました。
子セッションは起動し、プレイブックに従って情報を整理し、起票前のプレビューを表示しました。そこまでは想定どおりでした。
その時点で私は、
「プレビューだけ確認して、今回は起票しないでおこう」
と考えました。
そこで、まず STOP ボタンを押し、さらに「しない」とメッセージを送りました。
いったんは止まったように見えました。
しかし、その後また処理が再開されました。
そこで今度は、「この作業を中断して」 と、より明確に中断の意図が伝わるメッセージを送りました。
それでも、同じように処理は再開され、最終的には Linear にチケットが起票されました。
なお、Devin はクラウド上で動くツールなので、手元でウィンドウやブラウザを閉じても、それだけで処理が止まるわけではありません。ブラウザを閉じても、処理がバックエンドで継続するという点にも注意が必要です。
なぜそうなったのか
最初は、STOP が効かなかったのかと思いました。ですが、実際には停止操作には反応していて、そのあと親セッション側から再開指示が出ていた、というのが近い状況でした。
流れを整理すると、こうなります。
12:48 子Devin → プレビューを表示
「この内容で起票してよいですか？」
12:48 私 → STOPを押し、「しない」と送信
12:48 子Devin → いったん停止
12:49 親Devin → 再開を指示
12:49 子Devin → 再開
12:49 私 → 「この作業を中断して」と送信
12:49 子Devin → 再度停止
12:50 親Devin → 再び再開を指示
12:51 子Devin → チケット起票完了
つまり、こちらは止めたつもりでも、親セッション側からは処理を続ける指示が出ていた、ということです。
というより、親子セッションの関係を自分が十分に理解できていなかった、というほうが実態に近かったです。
このとき実感したのは、Devin の動き方を自分がまだ十分に理解できていなかった、ということでした。特に、親子セッションの関係や、クラウド上で処理が継続する前提をきちんと把握できていなかったことが、今回のハマりどころだったのだと思います。
使ってみて分かったこと
今回の体験は、大きな失敗談というより、Devin のような AI エージェント機能は、前提を理解しないまま触ると、思ったより簡単に認識がずれる という話でした。
実際に触ってみて、特に気づいたのは次の3点です。
1. STOPの効き方は、思っているより単純ではない
STOPを押したから完全に終わる、という理解では足りませんでした。
セッション単体では止まっていても、別のセッションや別の指示経路から再開されることがあります。どこまで止まるのかは、事前に把握しておいたほうが安心です。
2. 承認ステップがあるだけでは、期待どおりに動くとは限らない
当時は「承認待ち」があることで、ひとまず安全だと思っていました。
ただ実際には、親Devinがそのまま「承認済み」と判断して進めていました。少なくとも今回のような構成では、承認ステップがあることだけでは、自分が期待していた動きにはなりませんでした。
3. クラウドツールとしての前提を理解しておく必要がある
手元の画面を閉じても終わらない、というのは、使う前はそこまで強く意識していませんでした。
でも Devin はクラウド上で動くので、ローカルアプリの感覚とは違います。この前提を理解しているかどうかで、「止めたつもり」の感覚はかなり変わると思います。
おわりに
AIエージェントは本当に便利です。今回作ったプレイブック自体も、不具合起票の手間をかなり減らしてくれましたし、関連コードまで調査してくれるのは素直にすごいと感じました。
一方で、今回の出来事を通して、AI機能を使うときには機能そのものだけでなく、どう動いて、どう止まるのか という前提も理解しておく必要があると感じました。
いま振り返ると、これは当たり前のことかもしれません。
それでも実際に触ってみるまでは、そこを十分に意識できていませんでした。
今回は、プレイブックの動作確認をする中で、自分の知識が足りずにハマったというだけの話かもしれません。
ただ、だからこそ、これから同じように AI エージェントを触る人にとっては、事前に知っておくと少しハマりにくくなるポイントかもしれないと思っています。
この記事はAUDERのQAチームで実際に体験した内容をもとにしています。今回の事象はDevin自体の不具合というより、私自身が親子セッションの挙動やクラウド上での実行のされ方を十分に理解できていなかったことで起きたものでした。現在は運用を見直し、当時プレイブックに入れていたプレビュー表示と承認待ちの処理は削除し、直接起票する形に変更しています。
Discussion