コーディングエージェントは、あなたがコーヒーを飲んでいる間にチケットをプルリクエストに変えてしまう。しかしその速さは、ツールが決して代わりに答えてくれない、より静かな問いを生む。diff が出来上がったとき、それは誰のものなのか。誰がタイプしたか、ではない。それはエージェントがやったことだ。出荷するかどうか、その変更が正しかったかどうか、深夜2時に壊れたらどうなるか——それに責任を負うのは誰か。実行はエージェントに移った。オーナーシップは移っていない。そして移ることもない。
エージェントを2つ以上動かした瞬間、この曖昧さはさらに悪化する。バグを1つ Claude Code に、もう1つを Codex に渡せば、ブランチが2本、サマリーが2つ、そして「これらがマージされるとき、それぞれの名前は誰のものか」という単純な問いへの共通の答えは存在しない。ターミナルのスクロールバックに住んでいるオーナーシップは、オーナーシップではない。次の git log まで生き延びる推測にすぎない。
これが Sharkly が中心に据えている問題だ。Sharkly はコーディングエージェントの上に位置するレイヤーとして、誰が作業をアサインしたか、どのエージェントが実行したか、誰が結果をレビューするか、誰が受け入れるかを記録する。本記事ではこの運用モデルを4つの役割と一連のステータスとして提示し、その後で1つのチケットをアサインから PR マージまで追いかける。その土台にあるレビューの仕組みについては、ヒューマン・イン・ザ・ループのコーディングエージェントのガイドで、これらの決定を強制する5つのゲートを解説している。
TL;DR
エージェントの作業に対する人間のオーナーシップとは、実行がエージェントに移っても、変更に対する責任がエージェントに移ることは決してない、ということだ。運用モデルには4つの役割がある。人間がアサインし、エージェントが実行し、名前のわかる人間がレビューし、同じ人間が受け入れる。エージェントはタスクを Ready for review まで進められるが、Done に動かせるのは人間だけだ。エージェントは調査し、実行し、テストし、報告する。人間は方向性を定め、権限を与え、結果を受け入れる。
エージェントが生み出した作業のオーナーは誰か
オーナーシップと実行は別の仕事であり、これを混同することが根本的な誤りだ。実行とは変更を生み出すこと、つまりコードベースを読み、ファイルを編集し、テストを走らせ、PR を開くことだ。エージェントはこれをうまく、速くやる。オーナーシップとは結果に対して説明責任を負うこと、つまりその変更に取り組む価値があったか、受け入れ基準を満たしているか、3か月後に誰かに問い合わせできるか、ということだ。この説明責任は人間に残る。エージェントは後からトレードオフの正当性を問われることも、結果の重荷を負うこともできないからだ。
この分担を最も明快に言い表すのが、人間とエージェントの契約だ。エージェントは調査し、実行し、テストし、報告する。人間は方向性を定め、権限を与え、結果を受け入れる。自動化はチームの判断が必要なところで止まる。「結果を受け入れる」までのすべてはエージェントに任せられる。受け入れそのものは任せられず、リリースの決定も同様だ。AI アシスタントと AI チームメイトの違いについての記事でも、反対の方向から同じ線を引いている。
運用モデル：アサイン、実行、レビュー、受け入れ
オーナーシップと実行を切り離せば、ワークフローはそれぞれ1つの仕事を持つ4つの役割に落ち着く。これらに名前を付けることが、5つの並行エージェントが5つの孤立したブランチに変わるのを防ぐ。
| ステップ | 実行者 | 所有するもの |
|---|---|---|
| アサイン | 人間 | その作業に取り組む価値があると判断し、受け入れ基準を書き、誰が責任を負うかを決める |
| 実行 | エージェント（Computer 上の Runtime 経由） | 変更を生み出し、テストを走らせ、何をしたか・何が不確かかを報告する |
| レビュー | 人間の Assignee | 受け入れ基準とエビデンスに照らして結果を判断する |
| 受け入れ | 同じ人間の Assignee | マージとリリースの決定 |
重要なのは最初と最後の行だ。アサインと受け入れを同じ人物が所有する。こうしてループが閉じる。その作業に価値があると決めた人が、それが完了したことを確認する人でもある。Sharkly はこれを、タスク上に2つのアサイン枠——人間の Assignee とエージェントの Assignee——を同時に保持することで実現している。責任と実行が、曖昧な「担当者」1つではなく、別々の事実として記録されるのだ。作業がどのようにエージェントに届くかについては、エージェントの作業を一か所でアサイン・追跡・レビューするためのガイドを参照してほしい。
ステータスとゲート：エージェントは Ready for review まで、人間がタスクを Done へ動かす
運用モデルは、タスクのステータスにマッピングされたときに実体を伴う。ステータスの変更は、後から指し示せる意思決定だからだ。ここでのルールは厳格で、率直に言う価値がある。エージェントは作業を Ready for review まで進められるが、タスクを Done に動かせるのは人間だけだ。
| ステータス区分 | 動かす人 | 意味 |
|---|---|---|
| Backlog | 人間 | 未着手。ここでエージェントをアサインしても何も実行されない |
| Ready for work | 人間 | タスクをこの区分に移すことが、エージェントの実行開始の合図になる |
| In progress | エージェント | 実行が分離された worktree 内で進行中 |
| Ready for review | エージェント | 実行が完了し、名前のわかる人間を待っている |
| Done / Accepted | 人間 | 人間がエビデンスを読み、結果を受け入れた |
この境界を守るものが2つある。第一に、エージェントは自分のタスクの Task Workflow が許可していないステータスを選べない。つまり、自分の作業を勝手に受け入れ済みにはできない。タスクは人間のレビューを待つ状態で残り、そのシグナルは誰も読まないチャンネルではなく、責任者の Inbox に届く。第二に、リンクされたプルリクエストをマージしてもタスクのステータスは変わらない。マージは Git のイベントであって受け入れの意思決定ではなく、Sharkly は両者を分けて扱う。だから「PR がマージされた」が「人間がこれを正しいと判断した」と取り違えられることはない。レビューキャパシティが心配なら、なぜ人間のレビューが真のボトルネックなのかという分析で、そのための設計を解説している。
チケットから PR マージまで：具体的な一例
ここでは単一のタスク SH-312「公開検索エンドポイントにレート制限を追加する」で、このモデルを端から端まで動かしてみる。
- アサイン。 エンジニアがタスクを書く。対象のエンドポイント、目標の制限値、そして受け入れ基準（超過時に 429、既存テストが引き続き通る、制限値用の新しいテストがある）。自分を人間の Assignee に設定し、エージェントの Assignee を選ぶ。タスクは Backlog にある。まだ何も実行されない。
- 実行。 彼女が
SH-312を Ready for work のステータスに移す。このステータス変更が実行を開始する。エージェントがタスクを引き受け、この作業が他の何とも衝突しないよう新しい worktree を用意し、説明と最近のコメントを読み、エンドポイントを編集し、テストを追加し、テストスイートを実行する。 - 報告。 エージェントはプルリクエストを開き、タスクにコメントを投稿する。変更の要約、実行したテストとその結果、そして実際のトラフィック下で制限値をロードテストしていないという正直な注記1つ。
SH-312を Ready for review に移す。ここで止まる。それ以上は進めない。 - レビュー。 レビュー待ちのシグナルがエンジニアの Inbox に届く。彼女は順番に読んでいく。受け入れ基準、エージェントのコメント、実行ログ、そして diff。ログには、実行がなぜキューに入ったのか、どんなツール呼び出しを行ったのかが表示される。だから彼女は変更そのものをレビューでき、変更についての物語を読まされることはない。ロードテストの欠落は実際の問題なので、彼女はドキュメント化された上限値でのテストを求めるコメントを残す。そのコメントは同じエージェントに対する後続の実行をキューに入れる。2つ目のタスクは開かない。
- 受け入れ。 エージェントがテストを追加し、再び報告し、タスクを Ready for review に戻す。今度はエビデンスが基準と一致している。彼女は PR をマージし、
SH-312を Done に移す。最初からこの作業を所有していた人物による、2つの意図的な行為だ。
すべてのステップはタスクに還元される。実行、PR のリンク、レビューコメント、受け入れ。ターミナルの中だけに存在するものは何もない。受け入れる前に何を読むべきかについては、タスクレベルのエビデンスで AI 生成コードをレビューするためのガイドでより深く掘り下げている。
オーナーシップが静かに崩れる場所
すべてのタスクでこの完全な儀式が必要なわけではなく、そう装うとレビューが茶番になる。作業が読み取り専用か、些細に巻き戻せる場合は軽いバージョンを使えばいい。リポジトリの監査や、テストが通っている依存関係の更新は、実行からそのまま素早い受け入れに進めてよい。変更がデータに触れる、公開インターフェースを変える、1つのコマンドでは元に戻せない、といった場合は常に、両端に名前のわかる人間を置く完全な4役割ループを使う。
警戒すべき失敗パターンは、エージェントがやりすぎることではない。オーナーシップが未アサインのままになることだ。エージェントの Assignee はいるが人間の Assignee がいないタスクは、説明責任を欠いた実行、つまり進捗の衣装を着た孤立ブランチ問題である。解決策はどこでも通用する1つのルールだ。エージェントのすべてのタスクは、それを所有する人間を指名する。複数のエージェント間のハンドオフを調整する場合は、エージェント間・エージェントから人間へのハンドオフパターンのガイドで、その連鎖の中で人間のオーナーがどこに位置するかを示している。
まとめ
エージェントの作業に対する人間のオーナーシップは、自動化へのブレーキではない。むしろ、自動化を安全にスケールさせるために必要なものだ。実行はエージェントに任せよう。できる限りの速さで、すべてを。4つの決定は人間の手に残す。何をアサインするか、実行する権限を与えるか、結果が基準を満たしているか、リリースするか。これらの決定を共有タスク上のステータス変更として書き留めておけば、説明責任は誰かのスクロールバックの中の推測ではなく、誰でも読める事実になる。
すでに複数のコーディングエージェントを動かしているなら、Sharkly はその作業をアサインし、実行を見守り、各結果を誰がレビューし受け入れたかを記録する、1つの場所を提供する。このモデルは worktree とスプレッドシートで手作業で組み上げることもできるし、Sharkly をダウンロードしてタスクに運ばせることもできる。このレイヤーの全体像については、Claude Code と Codex の上に位置するコーディングエージェント管理から始めてほしい。
FAQ
人間のオーナーシップとは、人間がすべてのエージェント実行を監視するという意味ですか？ いいえ。オーナーシップは監督ではなく説明責任です。人間が作業をアサインし、結果を受け入れ、その間エージェントは無人で実行します。そもそもターミナルを眺めるやり方は、エージェント1つを超えるとスケールしません。
エージェントは自分の作業を完了にできますか？ いいえ。エージェントはタスクを Ready for review まで進められますが、その Task Workflow は accepted ステータスを許可していません。人間がエビデンスを読み、タスクを Done に移します。
プルリクエストをマージするとタスクが受け入れられたことになりますか？ いいえ。リンクされた PR のマージは Git のイベントであり、Sharkly のタスクステータスを変えません。受け入れは、レビュー後に人間のオーナーが行う別のステータス変更です。
エージェントのタスクは誰が所有すべきですか？ その作業に取り組む価値があると決めた人です。Sharkly はエージェントの Assignee と並んで人間の Assignee 枠を保持するので、レビューのシグナルはその人に届き、その人が受け入れます。
人間がアサインされていない場合はどうなりますか？ 説明責任を欠いた実行が生まれます。エージェントのすべてのタスクが人間のオーナーを指名する、というのが安全なルールです。そうすれば、完了した実行には常に説明責任を負う人がいます。
