Sharklyの自動化：スタンドアップ、バグトリアージ、自動で回るレポート

どのエンジニアリングチームにも、誰も計画していないのに全員がコストを払っている定型的な作業が存在します。朝会のサマリーをまとめる人がいる。届いたバグレポートを1件ずつ読んで振り分ける人がいる。散らばった6つのタブから金曜のステータスレポートを組み立てる人がいる。どれも難しい作業ではありません。しかしそのすべてがトイル（退屈な雑務）です。予測可能で、繰り返し発生し、そして静かにコストを食っていく——なぜなら、最初に気づいた人のところに必ず降りかかるからです。

これはまさに、AI Agent が得意とする種類の仕事です。ただし、誰かがプロンプトを打たなくても、適切なタイミングで Agent を起動してくれる仕組みがあればの話です。その起動の仕組みを提供するのが、Sharkly の Automations です。Automation とは、繰り返し発生する Agent または Crew の作業を Space 単位で定義するもの。具体的には、記述された指示、実行担当者、1つ以上のトリガー、そして確認できる実行履歴で構成されます。

重要なのは、判断を自動化することではありません。Sharkly 自身の説明は明快です。自動化は、チームの判断が必要とされる地点で止まる。Automation は朝会のサマリーを下書きし、バグの一次読み込みを行い、週次レポートを組み立てることができます。しかし、それらをチームとしてどう扱うかを決めるのは、あくまで人間です。Sharkly 自体が初めての方は、まずSharkly とは何かをご覧になってから戻ってきてください。

TL;DR

Sharkly の Automation とは、トリガーが発火するたびに、決まった指示セットで Agent または Crew を起動する、Space 単位のルールです。トリガーは4種類：スケジュール（タイムゾーン付きの5フィールド cron）、タスクステータスの変更、設定したフレーズを含むコメント、外部サービス向けのシークレット Webhook URL。さらに手動テスト用の「Run now」ボタンがあります。各実行は、その発生元・結果・失敗理由とともに実行履歴に記録され、Automation は修正中に一時停止・再開できます。Automations は、明確に定義された定例作業に使いましょう。朝会のサマリー、バグの一次トリアージ、定期的なレポートなどです。読み込みと下書きは Agent が行い、出力を確認して最終判断を下すのは人間です。

Automation とは何か、そして何ではないか

Automation には、1つの繰り返し作業に関する小さく完全な定義が保存されます。名前と、目標・手順・制約・期待される結果を記述した指示。所有する Space。担当者、つまり作業を実行する Agent または Crew。優先度。Active または Paused のステータス。1つ以上のトリガー。そして各実行の発生元・結果・Agent 実行・失敗理由を記録する実行履歴です。

見落とすと驚くことになる境界が2つあります。

1つ目は、Automation は実行ごとに Task を作成しないという点です。Agent または Crew の実行を直接開始します。その実行、出力、そして失敗はタスクリストではなく Automation の実行履歴に残るため、毎朝9時にボードが機械生成の Task で埋め尽くされることはありません。

2つ目は、Automations は Sharkly のワークフローキャンバスではないという点です。Space には2つの自動化の画面があります。ここで説明している単一ルールの Automations と、サードパーティのコネクタを呼び出せるトリガーノードとアクションノードのキャンバスである Automation workflows です。予測可能なイベントに応じて、1つの Agent または Crew に1つの指示セットを実行させたいときは Automation を使います。Agent が関与する前に複数ステップの処理やアプリをまたぐアクションが必要なときは、ワークフローを使います。

担当者は完全な Sharkly Agent なので、その Agent にすでに設定したものすべてが適用されます。指示、Runtime、Skills、リポジトリ、実行設定などです。まだ作成していない場合は、Sharkly の Agentsで、保存された動作する設定がどのようにチームで再利用できるものになるかを解説しています。Automation は、言ってみればその Agent との定例会の約束のようなものです。

4種類のトリガー

Automation は複数のトリガーを持て、それぞれを個別に有効化・無効化できます。1つの定義で複数の入口をカバーできます。たとえば同じトリアージ指示を、ステータス変更でもスラッシュコマンドでも発火させられ、何かを二重に定義する必要はありません。

スケジュールは標準の5フィールド cron 式とタイムゾーンを使い、よく使う毎時・毎日・平日・毎週のプリセットも用意されています。これは「何かが変わったから」ではなく「火曜日だから」実行すべき作業のためのトリガーです。

タスクステータスの変更は、タスクが選択した1つの Organization ステータスに移動したときに Automation を起動します。ここで重要な点が1つあります。ステータスは Organization で再利用可能な定義であり、現在のイベントマッチングは Organization 全体が対象です。複数の Space が同じ「Needs Triage」ステータスを使っている場合、そのいずれかで一致する遷移が起きると Automation が起動し得ます。Agent が行動する前に、トリガーとなったタスクを検証するよう指示を書きましょう。

コメントのフレーズは、タスクのコメントに設定したフレーズが含まれているときに実行を開始します。マッチングは大文字小文字を区別せず、コメント内のどこに含まれていても対象となり、これも Organization 全体を監視します。ドキュメントの推奨は、「check」のような一般的な語ではなく /triage-bug のような特徴的なスラッシュコマンドを使い、指示の中でトリガーとなったタスクを検証させることです。

Webhook は、外部サービスからの POST を受け付けるシークレット URL を作成します。完全な URL はトリガーの作成時または再生成時にのみ表示され、後から確認することはできません。デフォルトでは URL 自体がベアラーシークレットとして機能するためです。署名シークレットを設定した場合、リクエストは署名検証も通過する必要があります。これはGitHub が自社の Webhook で採用しているのと同じ方式です。これらのシークレットはソース管理に含めないようにし、漏洩した場合は再生成してください。Webhook 以外の方法で Sharkly をスクリプトから操作したい場合は、Sharkly CLI と APIをご覧ください。

実行を開始するもう1つの方法は、トリガーではありません。「Run now」は Automation を直接開始するもので、4つのトリガーに仕事を任せる前に、指示と担当者の可用性をテストする手段です。

Automation が実際に実行するもの

トリガーが発火すると、Sharkly は Automation の指示とともに、割り当てられた Agent または Crew を起動します。この指示が契約のすべてであるため、ドキュメントでは何を明記すべきかを具体的に示しています。生み出すべき成果、確認すべき入力、従うべき手順、結果を記録する場所、許可される変更、そして人間がレビューまたは判断すべきタイミングです。

最後の項目は強調に値します。よく書かれた Automation は、自分自身の停止点を明示します。「サマリーを下書きして記録すること。タスクステータスは変更しないこと」は、権限があいまいなままの長い指示よりも優れています。ドキュメントの展開ガイドラインも同じくらい明快です。まずは観察可能で取り消し可能な作業から始め、範囲を広げる前に何回か実行をレビューしましょう。

まず自動化する価値のある3つの雑務

いずれも、製品がサポートする範囲の精度にとどまります。Agent が読み、下書きし、記録する。意思決定は人間が握り続けます。

毎日の朝会サマリー。トリガー：スケジュール、平日プリセット、チームのタイムゾーン。担当者：関連するコンテキストへの読み取り権限を持つレポート用 Agent。指示：現在の Sprint のタスクを確認し、動いたもの、ブロックされているもの、レビュー待ちのものを洗い出し、タスクを一切変更せずに、チームが読む場所へ短いサマリーを記録する。誰もが嫌う朝会の作業——全体像の組み立て——を Agent が担うことで、朝会は判断が必要な2つの項目について話し合う場になります。チームのサイクルを Sharkly で回しているなら、Sprintsが Agent の確認する構造を提供します。

バグの一次トリアージ。トリガー：バグ受付ステータスに対するタスクステータストリガー、または /triage のような特徴的なフレーズに対するコメントトリガー、あるいはその両方。担当者：対象コードをカバーするリポジトリを持つトリアージ Agent。指示：トリガーとなったタスクが意図した Space のバグであることを検証し、レポートを読み、コードベースの関連箇所を確認したうえで、そのバグが触れていそうな範囲、レポートに行動するのに十分な情報があるか、根拠付きの推奨優先度を記録する。推奨までにとどめ、判断はしないこと。検証ステップは飾りではありません。ステータスとコメントのマッチングは Organization 全体が対象なので、指示こそがスコープのフィルターになります。得られる効果は、どのバグも届いてから数分以内に同じ丁寧な一次読み込みを受けられることです。Sharkly の外から作業が届く場合も、分業の考え方は同じです。Jira チケットがどうやって Agent の仕事になるかをご覧ください。

定期的なレポート。トリガー：スケジュール、毎週プリセット。担当者：同じ種類のレポート用 Agent で、より長い期間を対象とした指示を与えます。完了したもの、遅れたもの、ブロックされているものをまとめる。朝会の場合との違いは対象範囲と読者だけであり、まさにそれが Automation にふさわしい理由です。毎週金曜に同じ精度で存在するレポートは、誰かに時間ができたときだけ存在する、より良いレポートに勝ります。

3つすべてに共通して、指示の中に決して現れない言葉に注目してください。受け入れる、承認する、出荷する、クローズする、判断する。

実行履歴、ヘルス、一時停止と再開

確認できない Automation は信頼できない Automation です。だからこそ、すべての実行が記録されます。実行履歴は各実行を Running、Completed、Failed、Skipped として報告し、実行の詳細からはトリガーのペイロード、Agent の実行、出力、記録された失敗理由を開くことができます。個々の実行の上には、最新の有用な状態を要約するヘルスシグナルが表示されます。never tested、running、healthy、skipped、needs attention のいずれかです。

頭の中で太字にしておくべき境界が1つあります。Completed というステータスは Automation の実行を表すものであり、下流の結果がすべて正しかったことを約束するものではありません。Completed は仕組みが動いたという意味です。サマリーが正確だったか、トリアージの判断が妥当だったかは、依然として人間が読み解くべきことです。

一時停止と再開は、まさに予想される場面のためにあります。指示、トリガー、担当者を修正している間は Automation を一時停止して新しいトリガー実行を止め、設定が整ったら再開します。その間も定義と履歴はそのまま残ります。削除が唯一の除去手段なので、実行履歴がもう不要になった定義のために取っておきましょう。また、Agent をアーカイブする前に、それに依存している Automation が残っていないか確認してください。

何らかの Automation に頼る前に、ドキュメントでは短いチェックリストを推奨しています。「Run now」で手動実行する。Agent または Crew が必要なアクセス権を持っているか確認する。実行とその出力を確認する。各トリガーを個別にテストする。絞り込んだステータスか特徴的なコメントフレーズを使う。Webhook のシークレットをソース管理に含めない。

自動化が止まる場所

目標は無人パイプラインだと結論づけるのは簡単です。しかしそうではありません。製品自体の設計がそう語っています。Automations は自分の出力を自分で承認することはなく、すべての実行をレビュー用に記録します。

ですから、正直な判断基準はこうです。同じ明確に定義された作業を繰り返し、あるいは予測可能なイベントに応じて開始すべきとき、そして時々優れたものができるよりも、安定した一次ドラフトがあるほうが良いときに Automation を使います。単発の作業なら Agent に直接 Task を割り当てます。仕事そのものが判断である場合は、完全に人間に任せます。相反するプレッシャーの中での優先度判断、受け入れの決定、そして「時々遅い」よりも「常に間違っている」ほうが悪いあらゆる事柄です。

小さく、地味に始めましょう。セットアップを済ませ、レポート用 Agent を1つ作成し、平日スケジュールと「タスクを一切変更しないこと」で終わる指示を持つ Automation を1つ書き、一度手動で実行します。出力を読んでください。役に立つなら、あとはスケジュールに任せましょう。ドキュメントでは Automations とワークフローキャンバスをより詳しく解説しています。

FAQ

Sharkly の Automations はどのようなトリガータイプに対応していますか？

4種類あります。タイムゾーン付きの5フィールド cron 式を使うスケジュール、タスクが選択した Organization ステータスに移動したときに発火するタスクステータストリガー、設定したフレーズで発火するコメントトリガー、シークレット URL で POST を受け付ける Webhook トリガーです。Automation は複数のトリガーを組み合わせることができ、それぞれを個別に有効化・無効化できます。また「Run now」を使えばテスト用に手動で実行できます。

Automation は実行のたびに Task を作成しますか？

いいえ。現在の Automations は Agent または Crew の実行を直接開始し、実行ごとに Task を作成しません。実行、その出力、失敗理由は Automation の実行履歴に記録されます。結果をチームが読む場所に残したい場合は、指示の中でそのように明記してください。

Automations と Automation workflows はどう違いますか？

これらは Space 内の別々の画面です。Automation は1つのルールです。いつ開始するか、どの Agent または Crew が実行するか、どの指示に従うか。Automation workflows は、コネクタ経由でサードパーティアプリを呼び出せるトリガーノードとアクションノードのキャンバスです。定期的なチェックやコメントコマンドには単一ルールを使い、複数ステップでアプリをまたぐフローにはキャンバスを使いましょう。

Automation はバグトリアージを単独で処理できますか？

一次対応は可能です。トリガーとなったタスクの検証、レポートの読み込み、関連コードの確認、推奨優先度を添えた調査結果の記録までです。トリアージの判断は人間が担い、指示にもそのことを明示すべきです。ドキュメントでは、観察可能で取り消し可能な作業から始め、範囲を広げる前に何回か実行をレビューすることを推奨しています。

Automation の実行が失敗するとどうなりますか？

その実行は失敗理由とともに実行履歴に Failed として記録され（理由が取得できる場合）、ヘルスシグナルは needs attention に変わります。実行の詳細を開いてトリガーのペイロード、Agent の実行、出力を確認し、指示・トリガー・担当者を修正したうえで、「Run now」を使ってトリガーを再び信頼する前に修正を検証してください。