3つのコーディングエージェントを3つのタスクで起動し、次の20分間はターミナルのタブを巡回しながら、たった1つの問いに答えようと格闘する——「今、私を必要としているのはどれだ？」。1つはまだ実行中。1つはあなたが見ていない y/n の応答待ち。1つは1時間前にグリーンで終了し、静かに間違ったものを作り上げていた。それらのどれも、あなたに知らせてはくれなかった。自分で探しに行くしかなかった。
このギャップこそ、コーディングエージェントの可観測性（オブザーバビリティ）が埋めるべきものだ。システムエンジニアリングから借用した可観測性とは、実行中のプロセスが発するシグナルから、そのプロセスに直接アタッチすることなく、何をしているかを理解する能力を指す（OpenTelemetry に優れた入門記事がある）。コーディングエージェントにおける基準はこうだ——「各エージェントは何をしているのか、何が失敗したのか、人間を必要としているのはどれか」を、セッションを tail するのではなく、共有ビューから答えられるべきである。ほとんどの環境ではこれができない。どこかにステータスがあり、どこかにログがあり、それを可観測性と呼んでいる。そうではない。
本記事では、コーディングエージェントが実際に発する3つのシグナル、アラートを仕掛ける価値のある失敗シグナル、そして Sharkly のような共有タスクレイヤーが生の出力を実行可能なものへと変える場所を順に見ていく。Sharkly はあなたがすでに動かしているエージェントの上位に位置する。コーディングエージェントはすでに手元にあるはずで、ここでのポイントは、エージェントが複数になったときにその作業を把握できるようにすることにある。
ステータス、ログ、失敗シグナルはそれぞれ別物だ
この3つの言葉は互換的に使われがちで、その混同がほとんどの不出来な監視体制の根本原因になっている。これらはそれぞれ異なる問いに答えるものだ。
ステータスとは、実行の要約状態だ。実行中、入力待ち、完了、失敗。1つのフィールドで、読み取りは安価で、実行がどこにあるかを教えてくれるが、何をしたかは教えてくれない。ステータスは可観測性ではない。実行に関する最も小さな事実にすぎない。
ログとは、生の実行トレースだ。すべてのツール呼び出し、ファイル編集、モデルの応答が順番に並ぶ。ログは、何かがうまくいかなかったとすでに気づいた後で、何が起きたかを教えてくれる。ポストモーテムには欠かせないが、ライブシグナルとしては役に立たない。誰も5つのスクロールするログを同時に見張ったりはしないからだ。ログは、そこから何かが意味を抽出するまではシグナルではない。
失敗シグナルとは、導出されたアラートだ。あなたの手を止めてでも割り込む価値のある特定の条件——エージェントの停止、間違った方向にグリーンで終わった実行、タスク途中での予算切れ。失敗シグナルこそがあなたが本当に欲しいものであり、手作り環境のほぼすべてが飛ばしてしまうレイヤーだ。導出するには、ログをただ保存するのではなく、イベントへと処理する必要があるからだ。
罠は、最初の2つで止まってしまうことだ。ステータスとログがあれば、状態と記録があるので可観測性のように感じられる。しかしスケールする唯一の問い——「私のエージェントのうち、私を必要としているのはどれか？」——は、完全に3番目のレイヤーに存在する。
実際に重要な失敗シグナル
Webサービスの可観測性はクラッシュとレイテンシを見張る。コーディングエージェントは違う形で失敗し、あなたの午後を丸ごと奪うような失敗は、赤いステータスとして現れるものではほとんどない。以下が、導出する価値のあるシグナルだ。
| シグナル | 意味 | ステータスとログが見逃す理由 |
|---|---|---|
| サイレントストール | エージェントがプロンプトや見つからないシークレットを待っており、何も出力していない | ステータスは依然として「実行中」と表示され、誰も手を挙げない |
| グリーンだが誤り | 実行は正常終了したが、間違ったことをした | ステータスは「完了」。diff を読んで初めて明らかになる |
| 検証のスキップ | typecheck、テスト、ビルドを実行せずに完了と報告 | ログにはその省略が含まれているが、成功したログを誰も読まない |
| 予算の枯渇 | タスクの途中でモデルのクォータや支出上限に達した | 失敗はアラートではなく、切り詰められた応答として現れる |
| 潜在的な競合 | 2つのエージェントが別々の worktree で同じファイルを編集した | 両方の実行は「完了」。衝突はマージ時に待ち構えている |
| スラッシング | エージェントが同じファイルを編集、元に戻す、再編集をループで繰り返す | ログ上では個々のステップはすべて問題なく見える |
6つすべてに共通するパターン——失敗はステータスレイヤーでは見えず、ログレイヤーに埋もれている。「グリーンだが誤り」は最も過小評価されているものだ。間違ったタスクを自信を持って完了したコーディングエージェントは、タスクレベルのエビデンスを伴うレビューがそれを捕まえるその瞬間まで、完璧にやり遂げたエージェントと見分けがつかない。終了コードだけを報告する可観測性は、その失敗を成功として報告してしまう。
このうち2つは行動的というより構造的だ。潜在的な競合があるからこそ、同一リポジトリでの並行作業にはタスクごとの分離された worktree が必要であり、ファイルの重複がマージ中ではなくマージ前に表面化する。予算の枯渇があるからこそ、エージェント間の支出追跡はステータスと同じビューに入れるべきなのだ。クォータ切れで静かに停止した実行は、完了したタスクではなく失敗シグナルである。
チーム規模別に必要な可観測性の量
初日から6つすべてのシグナルが必要なわけではない。適切な計装の量は、何個のエージェントが動き、何人の人間がそれを見る必要があるかによって変わる。
| 体制 | 計装すべきもの | 破綻する場所 |
|---|---|---|
| エージェント1つ、タスク1つ | ステータスのみ。失敗したらログを読む | 2つ目のエージェントを起動するまでは何も問題ない |
| 複数の単独エージェント | 実行ごとのステータスに加え、ストールとグリーンだが誤りのシグナル | 沈黙から状態を推測し、ストールを見逃す |
| 小規模チーム、共有リポジトリ | 6つすべてのシグナルに加え、レビュー状態を共有ビューで | 監視が誰にも見えない1台のラップトップ上に存在する |
| 大規模チーム、多数のリポジトリ | 上記に加え、実行ごとのオーナーシップ、予算、監査証跡 | 1週間後に「誰が何を実行したか」に誰も答えられない |
正直に言えば、無関係な作業で1つのエージェントを動かすソロ開発者なら、必要な可観測性は1つのターミナルの中にすべて揃っている。状況が変わるのは、エージェントの数が画面の数を上回ったとき、作業があなたの座っていないマシン上で実行されるとき、あるいは別の誰かが同じボードを見る必要が出たときだ。その線を越えると、ステータスフィールドとログディレクトリだけでは足りなくなる。
生のログと単一ランタイムで十分な場合
組み込みツールには最大限の評価を与えよう。多くの作業ではそれらが勝つからだ。Claude Code と Codex はどちらも読みやすいセッショントレースを保持しており、単一タスクの単一エージェントにとって、そのトレースがあなたの可観測性だ。自分で起動し、見守っており、止まればログを読む。そこに管理レイヤーを追加するのは純粋なオーバーヘッドでしかない。
1つか2つのエージェントを、他人に引き継ぐことのない無関係な作業で動かすなら、ランタイム自身の出力を使えばいい。共有の可観測性レイヤーに手を伸ばすべきなのは、実行の数があなたの注意力を上回るとき、tail できない場所で実行されるとき、あるいはレビューが私的なものではなくチームの活動にならなければならないときだ。最後のケースは静かな殺し屋だ——5つのエージェントが並行して完了しても、その diff のレビューが結局たった1人の人間のキューに直列化されてしまうなら、それは勝利ではない。エージェントは速くなったが、あなたは遅くなった。これも可観測性の問題であり、単一のランタイムでは解決できない。なぜなら重要なシグナル——「この実行は完了し、あなたのレビューを待っている」——は、1つのエージェントの内部ではなく、エージェントをまたいで存在するからだ。
結果がタスクに戻ってくるときの可観測性
タスクレイヤーは、可観測性の単位を「ペイン内のプロセス」から「状態を持つタスク」へと変える。これが Sharkly が中心に据えているシフトであり、3つのシグナルすべてに一度に対応する。
各エージェントの実行は1つのタスクに紐づく。ステータス、進捗、ブロッカー、結果は、あなただけが見られるログの中に存在するのではなく、そのタスクのタイムラインに戻ってくる。失敗シグナルは1か所に現れる——人間を必要とする実行は Inbox に届くので、問いは「何か完了したか？」から「これは私の判断を必要としている」へと変わる。エージェントは調査し、実行し、テストし、報告する。人間は方向性を定め、権限を与え、結果を受け入れる。自動化は、チームの判断が必要とされる地点で止まる。
この境界は重要だ。誤って想定しやすいからだ。Sharkly はエージェントを実行したりコードを書いたりはしない。Claude Code、Codex、その他すでに使っているランタイムが実行を担う。Sharkly はそれらの周りに共有タスク、Computer、コンテキスト、レビューのレイヤーを加え、コンテキスト、進捗、ブロッカー、結果、人間のレビューを、依頼からリリースまで見える状態に保つ。その共有ボードが何を示すべきかの全体像についてはAIコーディングエージェントのダッシュボードに本当に必要なものを、ライブ監視の観点については並行して実行されるコーディングエージェントを監視する方法を参照してほしい。
1つのエコシステムにコミットするのではなく、複数のコーディングエージェントを使い続けたいなら、その共有されたシグナル優先のビューこそが Sharkly の設計が取り組む問題だ。既存のコーディングエージェントを Sharkly 経由で実行でき、すでに使っているすべてのランタイムをそのまま維持できる。
FAQ
コーディングエージェントの可観測性はログ記録と同じものですか？いいえ。ログ記録は起きたことを保存するものだ。可観測性とは、各エージェントが何をしているか、何が失敗したか、何があなたを必要としているかを、ログを1つずつ読むことなく答えられることだ。ログは可観測性への1つの入力であって、そのすべてではない。
最初に計装すべき、最も重要な失敗シグナルは何ですか？サイレントストールだ。あなたが見たことのないプロンプトを延々と待ちながら「実行中」と表示されるエージェントが、並行作業が静かに死ぬ最も一般的なパターンだ。何か凝ったものを追いかける前に、まずブロックされた実行が手を挙げるようにしよう。
コーディングエージェントの組み込み出力からこれを得られますか？エージェントが1つなら、はい。ランタイム自身のセッショントレースで十分だ。組み込み出力にはエージェント横断的なビューがないため、5つの実行のうちどれがあなたを必要としているかを教えてくれない。これはまさに、1つを超えてスケールしたときに現れる問いだ。
