ワークベンチ
ワークベンチは、Agentが駆動するデータ開発タスクのコラボレーションスペースです。明確なタスク目標に沿って、Agentが処理ステップを自ら計画し、ツールを呼び出して情報を収集し、実行結果に応じて作業を進め続けます。関連するタスクを同じワークスペースにまとめて、一元的にフォローアップしたり振り返ったりすることもできます。
ワークベンチは現在まだ先行体験版の段階で、まず運用時のトラブルシューティングのシナリオに対応しています。データタスクの失敗を起点に、エビデンスを自動で収集し、原因を特定して、対応の提案を行います。
1. ワークベンチ、ワークスペース、調査タスクを理解する
先行体験版では現在、「タスクフロー実行失敗」と「タスク実行失敗」の2種類のアラートについて調査を開始できます。1つの障害が1つの調査タスクに対応し、タスクには元のアラート、調査計画、実行過程、エビデンス、結論、対応の提案が継続的に記録されます。
3つのコアオブジェクト
| オブジェクト | 意味 | 使い方 |
|---|---|---|
| 異常イベント | 失敗系のアラートルールによって生成され、調査の起点となる | 失敗したオブジェクト、発生時刻、アラートのコンテキストを確認 |
| 調査タスク | 1つの異常に対して実行される一連の診断 | 計画、ステップ、エビデンス、結論、提案を確認 |
| ワークスペース | 関連する調査タスクをまとめるコンテナ。データ開発スペースとは別物 | 同じ問題や業務チェーンの進捗を集約し、ワークスペース概要を生成 |
ワークスペースの分け方
同じ問題、同じ業務チェーン、または継続的にフォローアップが必要な関連タスクは、同じワークスペースに入れることをおすすめします。概要を通じて共通の原因や全体の進捗を把握しやすくなります。互いに関係のない問題は、それぞれ別のワークスペースを作成してください。問題の対応が完了したらワークスペースをアーカイブでき、過去のタスクが現在の調査の妨げになるのを防げます。
2. 運用調査を開始する
開始する前に
スペース内で失敗系のアラートルールが少なくとも1つ有効になっていることを確認してください。ワークベンチには、アラートルールが検出した異常のみが表示されます。アラートルールがない場合、調査できる異常イベントは取得できません。
異常とワークスペースの選択
調査タスクを新規作成する際は、調査する異常を選択し、既存のワークスペースに入れるか、新しいワークスペースを作成するかを決めます。同じ問題の調査タスクがすでにある場合は元のワークスペースへの追加を優先し、独立した問題であれば新しいワークスペースを作成します。
診断のコンテキストを補足する。最近コード、依存関係、設定を変更した場合や、正常な結果について明確な想定がある場合は、「補足説明」に記入できます。ワークベンチはアラートの文面だけで判断せず、これらの情報も調査に取り入れます。
異常の詳細を確認する。作成前に、失敗したオブジェクト、アラート時刻、関連情報を確認し、誤った異常に対して調査を開始しないようにします。
調査計画の確認
手動で作成したタスクでは、まず調査計画が生成されます。調査の目標、範囲、既知のコンテキストが正確かどうかを重点的に確認してください。漏れがある場合は、背景を補足したり目標を調整したりしてから、実行を確定します。計画が確定すると、ワークベンチはエビデンスの照会を開始し、診断を進めます。
3. ワークベンチによる調査の進め方
調査の仕組み
- 異常イベントと補足情報に基づいて調査計画を生成します。
- 計画に沿って、タスクインスタンス、実行ログ、指標、変更履歴などの情報を照会します。
- ステップを1つ完了するたびに、既存のエビデンスを再確認します。手がかりが不足している場合は、調査ステップを追加したり、関係者に情報を求めたりします。
- エビデンスが十分にそろったら、障害の原因、影響範囲、対応の提案をまとめます。
調査図の各ノードは1つの診断ステップに対応します。ノードを選択すると、照会の目的、実行結果、エビデンスのソースを確認でき、結論がどのように導かれたかを判断できます。
調査との連携方法
エビデンスに応じて情報を補足する。「追加情報が必要」の通知を受け取ったら、業務の背景、想定される結果、最近の変更、既知の影響範囲を提供してください。調査は新しい情報に基づいて続行されます。
元のオブジェクトに戻って確認する。完全なログやタスク設定を確認する必要がある場合は、調査タスクから関連するタスクインスタンスやアセットに移動できます。
対応の範囲
ワークベンチは診断と提案を担当し、修復を自動で実行することはありません。タスクの再実行、コードの修正、依存関係の調整、設定の変更などの操作は、引き続き権限を持つ担当者が確認したうえで行う必要があります。
4. ワークスペース概要で全体の進捗を把握する
ワークスペース概要は、現在のワークスペース内の未アーカイブのタスクの情報を集約したものです。問題に結論が出ているかどうか、次に何を対応すべきか、複数の調査が共通の原因を示しているかどうかをすばやく判断するのに適しています。
| エリア | 答える問い | 適したアクション |
|---|---|---|
| 解明済み | どの問題に明確な原因や結論が出ているか | 結論を確認し、対処が完了しているかを確認 |
| 対応の提案 | 現在実行できる後続アクションは何か | 担当者を割り当て、該当するタスクに移動して根拠を確認 |
| 調査のポイント | 継続的に注目すべき手がかり、現象、パターンは何か | 複数の異常に共通の原因があるかを判断 |
タスクの追加、ステータスの変化、調査の完了があったら、概要を更新して最新の集計を取得できます。概要の集計対象は未アーカイブのタスクのみです。「対応の提案」では、最近新規作成されたタスクの提案を中心に集約します。
概要からタスクに戻る
概要は全体を把握するためのもので、個々のタスクの完全なエビデンスに代わるものではありません。提案の根拠を確認する必要がある場合は、関連タスクの件数や該当する項目から具体的な調査タスクに移動し、実行過程、エビデンス、コンテキストを確認できます。
5. おすすめ：自動作成を有効にする
有効にするのに適したシナリオ
継続的な運用が必要で、失敗後すぐに診断に入りたい本番環境では、自動作成を有効にすることをおすすめします。異常を人が見つけたり、チケットを重複して作成したりする待ち時間を減らせます。
| 設定 | 役割 | 推奨 |
|---|---|---|
| 自動作成 | 新しい失敗アラートが発生すると、調査タスクを自動で作成 | 本番環境では有効にすることを推奨 |
| 計画を自動承認 | タスクの作成後、そのまま診断計画の実行を開始 | 待ち時間を減らせるが、修復は自動実行しない |
| ワークスペースの方針 | システムがワークスペースを自動作成するか、常に指定したワークスペースに追加 | 同じ業務を継続的に注視する場合は、固定のワークスペースを指定可能 |
適用ルール
有効にした後は、それ以降に新しく発生した未対応の失敗アラートのみが処理され、過去のアラートに対してタスクが遡って作成されることはありません。自動作成されたタスクは、アセット責任者に優先的に割り当てられます。指定したワークスペースがアーカイブ済みの場合は、そのワークスペースが復元されて使用されます。削除済みの場合は、システムが作成するワークスペースに切り替わります。
自動作成と外部通知を同時に有効にすることをおすすめします。システムが問題を継続的に検出・診断し、追加情報が必要なときや対応できる段階になったときに、関係者がすぐに通知を受け取れます。
6. 「@自分」と外部通知でタイムリーに対応する
「@自分」には、本人がフォローアップする必要がある調査の通知がまとめて表示されます。未対応と既読のステータスを区別でき、該当するタスクに直接移動できます。
| 通知の種類 | 表示されるタイミング | 必要な対応 |
|---|---|---|
| 追加情報が必要 | 既存のエビデンスが不十分で、調査に業務のコンテキストがさらに必要 | 想定される結果、最近の変更、影響範囲を補足 |
| 対応の提案あり | 調査で実行可能な提案が得られた | 提案の根拠を確認し、その後の対処を手配 |
手動で作成したタスクで対応の提案が得られると、デフォルトでタスクの作成者に通知されます。自動作成されたタスクの場合は、アセット責任者に優先的に通知されます。
ワークベンチを離れても通知を受け取る
Feishuなどの外部チャネルでメッセージを受け取りたい場合は、スペース管理者が「ワークベンチのタスク診断通知」の通知ルールを有効にして個人サブスクリプションを許可し、データ開発スペースに通知チャネルを連携する必要があります。そのうえで、ユーザーが必要に応じて個人サブスクリプションを有効にします。
外部通知が届かない場合
- スペースで「ワークベンチのタスク診断通知」ルールが有効になっていることを確認します。
- 管理者が個人サブスクリプションを許可しており、本人がサブスクリプションを有効にしていることを確認します。
- 現在のデータ開発スペースに、利用可能な通知チャネルが連携されていることを確認します。
管理権限がない場合は、スペース管理者に連絡して上記の設定を完了してください。