更新日:2026年7月17日
6分で読めます
GitLab 19.2でDuo CLIが一般提供開始。コード、パイプライン、複数ステップの作業も、シェルから離れずに完結できます。

ソフトウェアデリバリーに関わる作業の多くは、エディタの中だけでは完結しません。パイプラインは失敗し、テストは壊れ、脆弱性も見つかります。そうした作業の多くは、コマンドラインで始まり、コマンドラインで終わります。
コードしか理解できないターミナル上のエージェント型AIでは、こうした課題には対応できません。単体のアシスタントは、ソフトウェアライフサイクル全体にわたるエージェントのことも、組織内の複数のプロジェクトにまたがる権限のことも、GitLab上ですでに設定済みの特定のプロジェクトコンテキストのことも把握していないからです。
GitLab 19.2では、その状況が変わります。GitLab Duo CLIが一般提供となり、GitLab Duo Agentic Chatをそのままターミナルに持ち込めるようになりました。外部から後付けされたツールとは異なり、GitLab Duo CLIはプロジェクトやパイプライン、エージェントの設定をすでに把握しています。調査や構築を行う際はインタラクティブに、ジョブやスクリプトで実行したい場合はヘッドレスに使えます。
その結果、デベロッパーは障害が発生したシェルにとどまったまま作業を続けられ、その作業はターミナル、UI、エディタをまたいで継続します。プラットフォームチームは、GitLab上の他の機能と同様にロールアウトを管理でき、エージェントによる支援も「この関数を書いて」にとどまらず、デリバリーライフサイクルのより広い範囲をカバーするようになりました。
エージェント型ツールは、デモ映えする領域、つまりファイル編集からまず成熟していきました。しかし、コミット後のライフサイクルはもっと煩雑で、運用色の強いものです。障害の原因がパイプラインや依存関係、CI設定にある場合、そのコンテキストはGitLabの中にあり、コーディングエージェントの学習データやローカルコンテキストの中にはありません。
汎用的なCLIアシスタントでこのギャップを埋めようとしたチームは、別の代償を払うことになりました。管理コントロールを共有できず、プラットフォームと連携したMCP/セットアップの診断もできず、エージェント型のソフトウェアライフサイクルの他の部分と単一のIDモデルを共有することもできなかったのです。結果として、ターミナル上のエージェント作業はコーディングにとどまり、デリバリーの他の領域を支援するには至りませんでした。
/doctorを実行してセットアップを確認したり、/mcpでMCPの設定を確認したりできます。GitLab Duo CLIの実際の動作を見る:
最も簡単な方法はGitLab CLI経由です。glab duo cliを実行すれば、認証はglabが代わりに処理してくれます。個人アクセストークンを使ってduoをスタンドアロンツールとしてインストールし、実行することもできます。どちらの構成でも、同じモードと機能を利用できます。
glab duo cli run --goalまたはduo run --goalを使用します。たとえば、パイプラインが失敗したときは、同じシェルからこう尋ねられます。
$ glab duo cli
> The pipelines in MR 23 are failing. Please help me fix them.
Duo CLIは状況を確認し、原因を特定したうえで、適用前にレビューできる変更案を提示します。規模が大きくなっても、カスタム指示(chat-rules.md、AGENTS.md、SKILL.md)に従って動作し、カスタムスラッシュコマンドを使ってインタラクティブセッションを拡張できます。
インストールと認証についてはGitLab Duo CLIのドキュメントをご覧ください。すでにGitLab CLIをお使いの場合は、glab duo cliから始められます。
GitLabを初めてお使いですか?GitLab Duo Agent Platformの無料トライアルを開始できます。すでにPremiumまたはUltimateをご利用の場合は、Duo Agent Platformを有効化し、サブスクリプションに含まれるGitLabクレジットをご活用ください。
このブログ記事を楽しんでいただけましたか?ご質問やフィードバックがあればお知らせください。GitLabコミュニティフォーラムで新しいトピックを作成してあなたの声を届けましょう。
フィードバックを共有する