ゴールを伝えるだけでGitLab Duo CLIがタスクをやり切る

複雑なタスクは、チャットの1ターンが終わるたびに足止めされます。何を達成したいのかはデベロッパー自身がすでに分かっており、作業を止めているのは、ステップごとに発生する往復のやり取りです。成功の定義があらかじめ示されていないと、エージェントは処理を止めて指示や確認を待つだけ。結果として、ステップごとにプロンプトを入れ直すことになり、タスクが終わるまで人間が「続ける」ボタンの役目を担う構図になってしまいます。

この往復にかかる時間はチームによって差があり、数分で済むこともあれば、誰かが手を空けるまでリクエストが放置されることもあります。範囲が明確な小さな依頼なら、このやり取りでも十分に回ります。しかし、デベロッパーが実際に多くの時間を使っているのは、失敗しているテストを直す、ビルドをチェックに通す、モジュール全体のLintエラーを片付けるといった、終わりの線が引かれていない作業。こうした作業では、1ターンずつの受け渡しがすぐに立ち行かなくなります。

GitLab 19.4では、GitLab Duo CLIに/goalスラッシュコマンドが加わりました。こうした終わりの見えにくい作業に正面から取り組む、統制されたゴール駆動のフローです。ローカルで動作し、主導権は手元に残ります。

GitLab Transcendが10月に再び開催

コーディングエージェントにより開発スピードは向上していますが、レビュー、セキュリティポリシー、リリースサイクルもそれに追いつく必要があります。10月6日開催のTranscendでは、チームがそのギャップを埋めるためにGitLabをどう活用しているかをご紹介し、エージェント型AIのスピードをソフトウェアライフサイクル全体へ広げるために何が必要なのかを探ります。

ライブ配信への登録はこちらから

1ターンずつのチャットが時間を奪い続ける理由

これは、アシスタントがもっと賢くなれば解決する話ではありません。1ターンずつのチャットでは、応答を読み、次の指示を決めて送る、という手順を誰かが繰り返して前に進めなければなりません。モデルの性能が高くても、各ターンの終わりには人が動かしてくれるのを待つ状態。そのため、デベロッパーの時間は「実際に自分の手で進める必要がある量」ではなく「タスクが終わるまでの長さ」に縛られたままになります。これまでのAI支援が、デベロッパーの時間を取り戻すというより、時間の使われ方の形を変えるにとどまってきた理由はここにあります。

任せたら、検証済みの結果が返ってくる

/goalでは、求める成果を伝えたら、あとは別の作業に移れます。実行中に付き添う必要はありません。作業は続き、指示した内容に照らして検証され、完了するか、解決できなかった点が報告されます。会話に張り付いたまま終わりを待つのではなく、同僚に任せた仕事の進み具合を後から確認するのと同じ感覚で、仕上がった結果と検証の記録を受け取る形になります。

単発のプロンプトから、常設のゴールへ

やってほしい作業と、「完了」と見なす条件を示すだけ。あとはGitLabが主導権を引き継ぎ、そのゴールラインを越えるまで手を止めずに取り組みます。

      /goal Fix the failing tests. Ensure CI is fully green and the fix is reviewed by Duo Developer.

    

あとはGitLabが問題に取り組み、変更を加えて検証を実行し、必要に応じてイテレーションを繰り返します。各ステップでは別のモデルがその作業を指定されたゴールと照らし合わせ、本当に完了しているのか、もう一度イテレーションが必要なのかを判断。繰り返しの回数には、設定した上限が適用されます。質問に答えるだけのアシスタントと、タスクを完了まで押し進めるアシスタントの違いは、ここにあります。

統制の効いたままの自動化

ただし、ゴールを預けることは、状況が見えなくなることを意味しません。/goalの実行は任意のタイミングで停止でき、要件が変わればゴールを設定し直せます。進行中のセッションが的を外していると分かったときに、最後まで走らせる必要はありません。

• 実行を停止: 介入が必要になったら、任意のタイミングで止められます。
• 新しいゴールを設定: 要件が変わったら、ゴールを設定し直して再開できます。
• 検証内容を確認: 各ターンの終わりに検証結果を見て、継続と停止のどちらを選んだ理由を確かめられます。

定めた成果に向かってエージェントが自ら作業を進め、監督役の人間が一挙手一投足に張り付く必要がない。それでいて、人が判断を差し込むポイントは明確に残されています。この組み合わせがあるからこそ、/goalは目新しい機能ではなく、実用的な自動化への一歩になります。

使い始める

/goalスラッシュコマンドは、インタラクティブモードで現在ご利用いただけます。実行方法は次のとおりです。

      /goal <task>. <done when...>

    

たとえば、次のように指定します。

      /goal Fix the failing tests in spec/models/user_spec.rb. Continue until all tests pass locally and CI is green.

    

実際の動作は、次のデモでご覧ください。

デベロッパーが働く場所に届ける

ゴール駆動のフローがどれだけ価値を持つかは、デベロッパーがどの接点からそれに手を伸ばせるかで決まります。/goalがまずCLIから提供されるのは、こうした反復的で手を動かす作業の多くが、すでにターミナルで行われているため。とはいえ、根っこにある仕組みは特定のクライアントに限られたものではありません。自動化を使うためにわざわざ別のインターフェースへ移るのではなく、すでに使っているツールの中からゴールを委任できることが望ましい姿といえます。

近日提供予定のGitLab Duo Slackエージェントでは、Slackの中からGitLab Duo Agent Platformを会話形式で利用できるようになります。任意のチャンネルやスレッドで@GitLabにメンションするだけで、コードベースについての質問、エージェントフローの起動、会話からのGitLabイシュー作成まで対応。別のツールやタブ、専用のコマンド構文は必要ありません。GitLab Duoは進捗をリアルタイムでスレッドに返すため、依頼から作業、結果までのやり取りが、会話の起きている場所にそのまま残ります。

繰り返している作業から、任せ始める

/goalはGitLab Duo CLIでご利用いただけるようになりました。ゴールが達成されたのか、それとも続けるべきなのか。タスクの背後にあるこうした判断を単一のクライアントから切り離し、GitLabのあらゆる接点から呼び出せる統制されたワークフローへ移していく、その最初の一歩です。同じ仕組みがSlackにも広がれば、チームがいま手作業で回している修正と検証の繰り返しが、統制されたゴール駆動のフローに変わります。デベロッパーに働く場所を変えてもらう必要はありません。

/goalを試してみませんか。まずはGitLab Duo CLIのスラッシュコマンドに関するドキュメントをご覧ください。

/goalの利用には、GitLab 19.3以降とGitLab Duo CLI 9.17.0以降が必要です。対応環境はGitLab.com、GitLab Self-Managed、GitLab Dedicatedで、対象はPremiumプランとUltimateプランです。

/goalはGitLab Duo Agent Platformの一部であるため、この機能やその他のエージェント型の機能を使うには、Agent Platformを有効にする必要があります。アクセス権の取得はGitLab Duo Agent Platformの無料トライアルから。Freeプランの場合は、数ステップでサインアップしていただけます。

すでにGitLab PremiumまたはUltimateをご利用中の場合は、まずDuo Agent Platformを有効化し、サブスクリプションに含まれるGitLabクレジットをご活用ください。

本ブログ記事には、1933年証券法（改正済み）第27A条および1934年証券取引所法第21E条にいう「将来の見通しに関する記述」が含まれています。これらの記述に反映された期待は合理的なものと考えていますが、既知および未知のリスク、不確実性、前提条件、その他の要因の影響を受けるため、実際の結果は大きく異なる可能性があります。これらのリスクおよびその他の要因の詳細については、当社がSECに提出する報告書の「リスク要因」の項に記載しています。当社は、法令により義務付けられる場合を除き、本ブログ記事の日付以降にこれらの記述を更新または改訂する義務を負いません。