プルリクエストを作成できるコーディングエージェントは便利です。しかし、誰も見ていない間にそれをマージできるコーディングエージェントは、コミット権限を握った負債でしかありません。この2つの文の間にある隔たりこそが、問題のすべてです。エージェントがブランチにプッシュし、テストを実行し、マージをクリックできるようになると、問いは「作業をこなせるか」ではなく「その権限はどこで終わるのか」になります。
ほとんどのチームは、その問いに偶然答えてしまっています。エージェントは実行環境に与えられた権限をそのまま持ち、レビューはその実行が始まったターミナルで行われ、誰が何を承認したかの記録は、ある一人のスクロールバックの中にだけ残ります。これで済むのは、2つのリポジトリにまたがって3つのエージェントを動かし、金曜のデプロイで誰も読んでいないものがリリースされるまでのことです。修正は承認ゲートですが、それは全員が守ることを願う習慣ではなく、共有システム上の本物のチェックポイントである場合に限ります。
その共有システムを提供するのがSharklyです。コーディングエージェントはすでに手元にあるはずで、Sharklyはその実行を、ステータス、Assignee、そして人が意図的に行わなければならないレビューステップを備えたタスクに変えます。本記事では、その背後にある運用モデルを順に説明します。誰が作業を割り当て、誰が実行し、誰がレビューし、誰が受け入れるのか、そしてエージェントが自分の変更を未レビューのままマージしないように、どこで止めるべきなのかを扱います。
承認ゲートとは実際に何なのか
承認ゲートとは、タスクのライフサイクルにおいて、自動実行が停止し、次のステップを人が判断するまで待つポイントです。警告ではなく、スクロールして見過ごせるログ行でもありません。人間が動かすまで作業が留まる状態そのものです。
最も重要な違いは、エージェントが変更を提案することと、変更を着地させることの間にあります。プルリクエストを開くのは提案です。それをマージするのは、本番環境に関する意思決定です。これらは異なる権限行使であり、後者こそチームの判断が宿るべき場所です。Sharklyはその境界を明示します。GitHubを接続していても、プルリクエストをマージしてもタスクのステータスは変わりません。マージは記録上、人間の操作のままであり、エージェントが作業を終えたときに引き起こす副作用ではありません。
この境界を覚えておいてください。というのも、「エージェントが本番を壊した」という話のほとんどは、実際には提案と着地の間にゲートがなかっただけの話だからです。
運用モデル：割り当て、実行、レビュー、受け入れ
Sharklyはタスクを4つの役割に分け、それぞれに1つの仕事を与えます。契約は単純です。エージェントは調査し、実行し、テストし、報告します。人間は方向性を定め、権限を与え、結果を受け入れます。
- 割り当て。 人間がニーズを記述し、Assigneeを設定します。タスクには2つの別個の割り当てがあります。タスクに関わる人間と、作業を実行する単一の実行Assignee（エージェントまたはCrew）です。一方を変更しても、もう一方は変わりません。
- 実行。 実行Assigneeが分離されたgit worktreeで作業を行うため、並列実行が互いのファイルに触れることはありません。進捗、ブロッカー、結果はタスクに戻されます。
- レビュー。 エージェントが完了すると、タスクをクローズするのではなく、人間のレビュー待ちの状態にします。差分、テスト出力、変更サマリーはターミナルではなくタスクに添付されます。
- 受け入れ。 人間が証拠を読み、変更をリクエストするか、受け入れてマージするかを判断します。受け入れが最終操作であり、それを行えるのは人間だけです。
ここでの価値は、Sharklyがエージェントを実行することではありません。4つの役割が、たまたま開いていたターミナルに押し込まれるのではなく、1か所で見える状態に保たれることです。レビュー側のより詳細な内容については、human-in-the-loopコーディングエージェントをご覧ください。
ゲートは習慣ではなくステータスにする
覚えておかなければならないゲートは、いずれ飛ばされるゲートです。だからこそ、タスクのライフサイクルに組み込みましょう。
Sharklyのステータスは、そのカテゴリを通じてシステム上の意味を持ちます。バックログは待機状態であり、そこにあるタスクはエージェントが割り当てられていても実行されません。それを作業可能なカテゴリに移動することが、実行を開始させるきっかけです。完了は終端であり、そこに到達するのは人間の操作であって、エージェントが自ら与えられるものではありません。
タスクステータスは、エージェントの作業状態とは意図的に分離されています。ライフサイクルステータスが「進行中」と表示されていても、その下のエージェントは作業中、人間の返信待ち、人間のレビュー待ち、またはエラー報告中である可能性があります。この分離がゲートです。エージェントは実行を終えて「人間のレビュー待ち」を示すことができますが、タスクがリリース済みを意味する状態に移ることはありません。作業はタスクに戻され、誰かが受け入れるまでそこで止まります。
これもまた、複数のエージェントを同時に安全に実行できる理由です。5つの分離されたworktreeで並列に動くエージェントがすべて同じレビュー列に到達したとき、5つのターミナルを監視するのではなく、1か所でトリアージできます。
具体例：チケットからマージ済みPRまで
SharklyのSH-312形式の識別子を使って、1つのタスクを順に見ていきましょう。
- 起票する。 人間が
SH-312というバグタスクを作成します：「フィルター変更後、検索が古い結果を返す」。説明には目的、再現手順、受け入れ基準を記載します。Assignee：検索リポジトリに紐づけられたClaude Codeエージェント。 - 形を整える。 エージェントがコードベースと関連履歴を調査し、スコープを確認して、計画をタスクに投稿し直します。人間が計画を読み、
SH-312をバックログから作業可能なステータスに移動します。これが開始の合図です。 - 実行する。 エージェントがタスクを引き受け、新しいworktreeで作業します。修正を書き、型チェックとテストスイートを実行し、タイトルに
SH-312を含むプルリクエストを作成します。これによりSharklyがPRをタスクにリンクします。 - ゲートで止める。 エージェントはマージしません。変更サマリー、成功したテスト出力、既知の制限を添付し、
SH-312を人間のレビュー待ちのままにします。作業はタスクに戻りました。 - レビュー。 人間が
SH-312を開き、1つのビューで差分と証拠を読み、修正が共有クエリヘルパーに触れていることに気づきます。より狭い範囲の変更を求めるコメントを残します。Agent Assigneeが準備できているタスクでは、そのコメントが実行を再キューイングするため、変更リクエストのループはプライベートチャットでやり直されるのではなく、記録上に残ります。 - 受け入れてマージする。 2回目の実行がレビューを通過します。人間がプルリクエストを承認し、マージし、
SH-312を完了に移動します。マージしてもタスクは自動クローズされないため、受け入れとマージは記録された2つの人間の意思決定であり、1つの自動カスケードではありません。
このチェーンの各ステップは後から検査できます。これが要件からコードまで追跡可能なワークフローの要点です。「誰が、どの証拠に基づいてこれを承認したのか」を、誰かのスクロールバックを発掘することなく答えられます。
ゲートを置くべきでない場所
ゲートを増やせば自動的に安全になるわけではありません。摩擦が増え、人々がクリックで通過する癖をつけるだけです。ゲートは、誤ったマージのコストが現実に存在する場所に置きます。単一のエージェントに割り当てられた、小規模で明確、低リスクの変更であれば、マージ前レビューで止めるだけで十分であり、Crewや追加の承認ステップを重ねる必要はありません。影響範囲が大きい場合には、より重いレビューを追加します。共有コード、マイグレーション、認証や請求に関わるものなどです。
決して外してはならない唯一のゲートは、マージゲートです。エージェントは一日中、調査し、書き、テストし、提案できます。その変更がmainブランチに到達するかどうかは人間の判断であり、エージェントがほとんどの場合に正しいとしても、そうあり続けるべきです。Sharklyのタスクレベルのレビューを既存のブランチ保護と組み合わせて、プラットフォームがワークフローの意図を強制するようにし、チームがすでに使っているツールはそのままにしましょう。GitHubを接続し、プロセスを作り直すことなくチケットをAIエージェントに割り当てることができます。
すでに複数のコーディングエージェントを実行していて、どれが完了し、どれが失敗し、どれが自分の対応待ちなのかを見失っているなら、そのレビュー列こそがSharklyを試す理由です。既存のエージェントをSharklyで実行し、マージの判断をあるべき場所に置き続けましょう。
よくある質問
Sharklyはエージェントが単独でマージするのを止められますか？ はい。プルリクエストをマージしてもSharklyのタスクステータスは変わらないため、実行は変更を着地させるのではなく、「人間のレビュー待ち」で終わります。これをGitHubのブランチ保護と組み合わせれば、リポジトリレベルで必須レビューを強制できます。
タスクステータスとエージェント状態の違いは何ですか？ タスクステータスはライフサイクルカテゴリです（バックログ、開始済み、完了など）。エージェント状態は、その実行が今何をしているかです。作業中、人間の返信待ち、レビュー待ち、またはエラーです。タスクは、エージェントがあなたを待っている間も進行中のままにできます。
レビュー対象のすべてのタスクにCrewが必要ですか？ いいえ。小規模で範囲が明確な作業では、タスクを1つのエージェントに割り当て、マージ前レビューゲートを使います。Crewは、リーダーエージェントが複数のメンバーを調整する必要がある目標のために取っておきましょう。
