生成は速くなったのに、マージまでの時間は変わっていない。エージェント型のツールを検討し始める人は、だいたいここから来ます。
うちは受託開発の小さなチームで、週に 15〜20 本の PR が上がります。詰まっていたのは書く速度ではなく、レビューのほうでした。補完系の AI を入れても、その行列は短くなりませんでした。生成が速くなっても、確認する人は増えません。
この記事では、Verdent が「計画 → タスク分解 → 実行 → テスト・レビュー → 人の承認」をどう回すのか、そのうえで開発者が手放してはいけない判断がどこにあるのかを書きます。
検索では「バーデントAI」と表記されることが多いのですが、公式の製品名は英字の Verdent（ヴェルデント） です。以降は Verdent と表記します。記載は 2026年8月24日に公式サイトおよび製品ドキュメントで確認したものです。
バーデントAIコーディングとは
コード補完やチャットとの違い
補完やチャットは、あなたが書いている最中に割り込みます。エディタの中で次の数行を提案し、採否をその場で決める。判断の単位は「この行を受け入れるか」です。
Verdent の単位はそこではありません。目標を自然言語で渡すと、フェーズに分解し、サブタスクを個別のエージェントに割り当てて並行実行し、完了したものを To Review 列に積みます。判断の単位は「この差分をマージするか」に移ります。
つまり、手を動かす場所が減る代わりに、確認する場所が増える。ここを理解しないまま導入すると、レビュー待ちの行列が短くなるどころか、確認対象が大きくなって長くなります。
目標をレビュー可能な変更へ変える流れ
公式に説明されている流れは4段階です。目標を伝える（@project-name でプロジェクトを指定できます）。Verdent がフェーズとサブタスクに分解する。各サブタスクが専任エージェントに配られ、進捗が Kanban ボードに出る。完了分が To Review に入り、そこで承認・修正・フィードバックを返す。
重要なのは最後の列です。完了は「終わり」ではなく「レビュー待ち」として置かれる設計になっています。
ひとつ範囲を限定しておきます。この4段階は Verdent Manager について公式に説明されている流れです。VS Code 版は自身のワークフローを Plan-Code-Verify として定義しており、実行とレビューの画面も異なります。つまり「どの入口でも同じ画面が出る」わけではありません。入口ごとの違いはApp の選び方をまとめた記事にあります。この記事が扱うのは Manager 側の流れです。
要求からコード変更までの進み方
要求を整理して計画を作る
曖昧な要求のまま走らせると、出てくる差分も曖昧になります。それを避けるのが Plan Mode です。
切り替えは Shift+Tab（macOS は Cmd+.、Windows は Ctrl+.）。入力欄の Switch Mode ボタンからも切り替えられます。
Plan Mode に入ると、Verdent 側から明確化の質問が返ってきます。多肢選択、自由記述、その併用のいずれかで答える形式です。選択肢が自分の状況に合わなければ Modify Options で調整でき、要求がはっきりしているなら Skip Clarifications で飛ばせます。答えを変えたくなったら Rollback Changes で戻せます。
生成される計画には、目標とスコープと成功基準、コンポーネント構成、データモデルと API 契約、技術選定の検討が含まれます。この計画は Verdent に頼めば markdown ファイルとして保存できます。設定名まで書いておきます。あとで自分が困るので。
なお Plan Mode も credits を消費します。「計画だけなら無料」ではありません。
タスクを分解して並行実行する
計画が固まったら Agent Mode に切り替えて実行に入ります。ここで、並行するコード変更を必要に応じて別々の作業環境に分離するのが Workspace Isolation です。タスクごとに必ず一つ、という対応ではありません。ひとつのワークスペースが複数のタスクを含むこともあります。
仕組みは git worktree で、分離はファイルシステムのレベルで効きます。ディレクトリ、ブランチ、ファイル、ステージングエリアが workspace ごとに独立するため、片方の変更がもう片方に漏れません。
元のクローンは Base Workspace と呼ばれ、通常は main か development にいます。分離が不要な小さな変更はここで済ませ、並行作業や失敗しても構わない実験は新しい workspace を作る、という使い分けになります。
ここは仕様が動いた部分なので、古い記事を読んでいる場合は上書きしてください。現行の Desktop インターフェースでは、ワークスペースの手動作成は提供されていません。 New Workspace ボタン、キーボードショートカット、Duplicate to New Workspace はいずれも非表示です。ワークスペースは、Verdent が対応する分離ワークフローの中で使われる形になっています。
既存のワークスペースは Projects パネルにプロジェクトごとにまとまって表示され、選択するとそのタスクとファイル状態を確認できます。同じワークスペース内のタスクはファイルを共有しますが、会話コンテキストは別々に保たれます。切り替えると、アクティブな worktree とブランチのコンテキストが変わります。
変更をテストしてレビューする
Code Review には Reviewer という組み込みのサブエージェントがあります。チャットで @Reviewer と書けば呼び出せます。指示なしで呼んでも、何を見るかは自分で判断します。
手動だけではありません。Agent がワークフローの最終 VERIFY ステップとして Reviewer を自動的に呼ぶことがあります。
出力は Findings というリストです。各項目にタイトル、なぜ問題かの説明、ファイルパスと行番号、そして confidence score（0〜1）が付きます。重大度は P0（必須修正、ロジックエラーや SQL インジェクションなど）、P1（重要、エッジケース漏れや性能上の懸念）、P2（提案、スタイルや可読性）の3段階で、先頭に P0: 1 / P1: 3 / P2: 5 のような集計、末尾に overall_explanation が付きます。
修正はチェックボックスで選んで Fix を押すと自動適用され、状態が Fix done に変わります。
Verdentに任せやすい開発タスク
範囲が明確な機能追加・修正・テスト
向いているのは、完了条件を先に文章で書けるものです。入力と出力が決まっている機能追加、再現手順があるバグ修正、既存実装に対するテストの追加、影響範囲が読めるリファクタリング。
判断のしかたとしては、「レビューする人が差分を見て可否を決められるか」を先に考えると外しにくくなります。決められないなら、それはタスクの切り方が粗いという合図です。
適性の見極め方はAI コードレビューの記事側で細かく扱っています。
任せるべきでない曖昧・高リスクな変更
逆に渡さないほうがいいものもはっきりしています。仕様が固まっていない新規設計、認証・認可・課金まわり、本番データを触るマイグレーション、暗号処理、外部公開 API の互換性を壊しうる変更。
理由は能力の問題ではなく、間違えたときの取り返しがつかない領域だからです。こういう変更は、たとえ差分が正しく見えても、正しさを差分だけでは確認できません。
安全に使うためのワークフロー
エージェント型を使い始めた最初の週、私は承認プロンプトを読まずに全部通しました。結果はテストコードごと書き換え。それ以来、順番を変えています。どこで止まるかを決めてから、走らせます。
分析と計画を先に確認する
まず Plan Mode で計画を出させ、内容を読んでから実行に移ります。機能一覧より先に、権限の既定値を読みます。 権限は必要な範囲だけに絞り、最初から広い書き込み権限を渡さないようにしてください。最初の1回は使い捨てのリポジトリで動かし、何が確認なしで進むのかを自分の目で見ておくと、あとが楽です。
ワークスペースとブランチを分離する
分離そのものは Verdent 側のワークフローが担うので、自分で決めるのは「その分離をどう畳むか」のほうです。
ここで一つ、失いやすいものがあります。ワークスペースを削除すると、コミットされていない変更は失われます。 削除前に必ずコミットするか stash してください。ディスク使用量も、.git は共有されるものの作業ファイルは複製されるため、プロジェクトサイズ×ワークスペース数で増えていきます。放棄した実験を残さない、という運用が要ります。
main に戻すときは、中央パネルの Task Changes で差分を確認 → Workspace Actions → Rebase to main branch → 競合を解決 → 内容を確認してから確定、という順です。長く生きている workspace には Workspace Actions → Sync with main branch を定期的にかけると、最後に大きな競合を抱え込みにくくなります。
テスト・差分・人間の承認を残す
三つ、決めておくことがあります。
自動修正の扱い。 Reviewer は低リスクと判断した場合、Findings を全件自動選択して確認なしで修正を実行することがあります。仕様として公開されている挙動です。つまり「自分が押していない変更」が入りうる。だから最終的な差分確認を省略できません。
レビュー体制。 複数モデルによるレビューは Settings → Chat → Reviewer → Multi-model review で有効化します。Default モードなら Verdent が組み合わせを選び、User モードなら自分で最大3つまで選べます（1つ目が primary、残りが secondary）。モデルを増やせば観点は広がりますが、その分遅くなります。
そして人の承認。 差分を確認したら、対象のテストと既存のテストスイートを実行し、その結果を見てから人が承認します。順番が逆になると、通したあとに気づくことになります。
Reviewer が P0 をゼロにしても、それは人手のセキュリティ監査の代わりにはなりません。confidence score も「Reviewer がどれだけ確信しているか」であって、正しさの保証ではありません。認証・権限・課金に触れる変更は、人が読んで通す工程を残してください。
並行して動かすこと自体は問題になりにくいです。並行して動かしますが、同時に承認するのは1つだけです。
知っておきたい制限とトレードオフ
曖昧な指示と不足するコンテキスト
一番よく詰まるのは、要求が曖昧なまま実行に入ったときです。Plan Mode の明確化はそのための工程ですが、Skip Clarifications で飛ばせる以上、飛ばした結果は自分に返ってきます。
開発全体でどれだけ時間が減るか、マージまでの時間が何割短くなるかを示す公式数値は、今回確認した公開情報では見当たりませんでした。自分のリポジトリで測るしかない部分です。
一方、Code Review については公式のベンチマークが公開されており、precision 74.2%、recall 20.1% という数字が出ています。これは開発全体の生産性を示す数字ではありません。そして recall が 20% 台であることは、指摘されなかった箇所が安全だという意味にはならない、と読むべきです。人が見る工程を残す理由が、ここにもあります。
レビューコストと変化するモデル環境
Review Rules（Settings → Chat → Reviewer → Review Rules エディタ、Markdown 対応、約500ミリ秒で自動反映）は便利ですが、全プロジェクトにグローバルに適用されます。 特定プロジェクト専用のルールを入れっぱなしにすると、無関係なリポジトリでも指摘が出ます。使い終わったら消す、という運用が要ります。
モデル環境も動きます。選んだモデルが提供終了になれば無効化され、差し替えが必要になります。無料枠の User モードでは Eco Mode プールのモデルしか選べず、BYOK で自分の API キーを使っている場合は、期限切れや残高不足がそのままレビュー失敗になります。
コストの形も一つではありません。標準のクレジット課金では credits を消費し、Plan Mode もその対象です。複数モデルレビューは単一モデルより高コストになります。一方、Eco Mode は credits とは別の利用枠で動き、BYOK で自分の API キーを使う場合も Verdent の credits は必要ありません。自分のタスクがどの枠で走っているかを先に確認しておくと、請求で驚かずに済みます。
行列が短くなったかどうかは、credits ではなくマージまでの時間で測ってください。
FAQ
生成コードの著作権やライセンスは誰が確認しますか？
以下は一般的な情報であり、法的助言ではありません。 権利関係は、公開日時点で適用される Verdent の利用規約、対象プロジェクト自体のライセンス、各依存関係のライセンスによって決まります。Cloud の公開機能を使う場合は、規約に組み込まれる Publishing Terms も確認してください。そこには、AI 生成物が正確・安全・適法・非侵害・唯一・完全・機能的であること、および目的への適合性を保証しない旨が明記されています。
この記事は権利の帰属について結論を出しません。最終的な確認責任は開発者およびチーム側に残ります。判断に迷う場合や商用配布が絡む場合は、有資格の法律専門家に相談してください。
秘密情報を誤って入力した場合はどうすべきですか？
まず、その認証情報を失効させて再発行するのが最優先です。入力を取り消しても、送信済みのものが無効になるとは限りません。そのうえで、コミットやワークスペースに残っていないかを確認します。
保持と削除については、プライバシーポリシーの日本向けの節に、利用目的の達成に必要な期間だけ保持し、不要になった時点または法定保存期間の満了時に削除するとあります（APPI に基づく開示・訂正・削除・利用停止の請求権も明記）。一律の保存日数は公開されていません。セキュリティポリシー側では、アカウント削除時に関連データを削除する一方、クラウドバックアップには通常の保持期間が満了するまで残る場合があるとされています。入出力は、明示的な同意がない限りモデル学習には使用しないと記載があります。
リポジトリの indexing については、公式文書間に不整合が残っています。セキュリティポリシー（2025年11月3日）は indexing・解析を提供していないとする一方、プライバシーポリシー（2026年5月26日）は明示的に有効化した場合の扱いを定めており、Changelog にも indexing の導入と更新の履歴があります。機能の存在を示す新しい情報のほうが優勢ですが、ここは私も試していないので、公開情報から言えるところまでです。 データ取扱いを前提に判断するなら、サポートに現行の挙動を確認してください。予防としては、環境変数と .gitignore の設定を先に済ませてから走らせるのが確実です。
社内のコーディング規約はどこまで設定できますか？
Review Rules に Markdown で書けます。「SQL は必ずパラメータ化する」「非同期処理には try/catch を入れる」「公開 API は権限検証を必須にする」といった粒度が公式の例として挙がっており、ESLint のルールや命名規則も同じ形で書けます。
制約は前述のとおりグローバル適用である点です。チームで共有するなら、プロジェクト横断で成立するものだけを入れ、個別案件のルールは別管理にしてください。
長時間タスクが途中で停止した場合、結果は保存されますか？
「停止」を二つに分ける必要があります。
自分で止めた場合。 VS Code 版のドキュメントには、実行はいつでも中断でき、現在のステップを完了してから停止し、そこまでの進捗は保持されると案内があります。
クラッシュや通信断など、意図しない停止の場合。 一律の復旧保証を示す記載は、今回確認した範囲では見つけられませんでした。上記は VS Code 版の案内であり、Desktop や Cloud の異常停止に同じ保証があることを示すものではありません。ここは推測で埋めません。
分かっているのは、コミットされていない変更はワークスペースを削除した時点で失われることです。長く走るタスクほど、途中でこまめにコミットしておくと、停止しても手元に残るものが増えます。
AIが追加した依存関係はどう管理すべきですか？
差分レビューで、コードの変更と同じ強度で lock ファイルの差分も見るのが基本です。新しいパッケージ名、バージョン、ライセンス、メンテナンス状況。
サプライチェーン上の安全性について、Verdent 側が保証を示している記載は見当たりませんでした。依存関係の追加を指摘させる Review Rules は書けますが、それは検知であって審査ではありません。導入可否の判断は人が持ったままにしてください。
インストール手順は公式のインストールドキュメントにあります。
最初に確かめるのは、使い捨てのリポジトリを1つ用意して、Plan Mode で計画を出させ、実行して、どこで承認プロンプトが出て、どこが確認なしで進んだかを記録すること。それだけで、自分のチームで何を止めるべきかが決まります。
