DevFlow Operator Console入門：4画面と3値裁決でAI開発を見渡す

「AIが動いた」と「引き渡せる」は別の話。工程と証跡を分けて確認しましょう。

01WHAT　役割と実装範囲を確認する

運用画面の役割は、次の判断に必要な根拠を並べること

Agentが出力した文章を時系列に並べるだけでは、プロジェクト全体の状態は分かりません。ある工程の成果物は保存されていても、レビュー担当の判断がまだ残っていることがあります。テストに失敗したのか、実行環境を用意できずに始められなかったのかでも、取るべき行動は変わります。Operator Consoleは、こうした違いを作業者が判断できる形にまとめるための運用面として考えられます。

DevFlowの公開版には、Run status、Error store、Regression diff、Benchmark outputという4つのビューがあります。基盤となるHarnessが持つ記録を読み取り、状態や比較の情報を表示します。画面側が別の完了判定を持つと、同じ工程について一覧は成功、詳細は未承認という食い違いが起こり得ます。そのため、工程の状態はHarness側のstep_statusという共通の判定を使う設計になっています。

公開済みのダッシュボードと、統合Consoleの構想を分ける

本記事は公開コミット1eba062の手引きとコードを基準にしています。既存のダッシュボードが提供する4つの読取ビューと、7つの許可された署名付き書き込みAPIを説明し、今後の統合Consoleに求める操作の考え方を整理します。作成途中の画面案にボタンが描かれていても、その操作がバックエンドまでつながったとは限りません。見た目の完成と運用可能性を別々に検証することが大切です。

公開版の手引きでは、3値裁決を入力する統合フォームや、一般的なAgentアダプターには未実装の部分があります。リアルタイム配信、実行途中の一時停止、取消までを標準で備えた完成品として紹介するのは正確ではありません。記事中の図は運用の責務を説明する概念図であり、現在の実画面のスクリーンショットではありません。利用する版に追加実装がある場合は、その版で試験し直します。

4つのビューで、確認する問いを変える

Run statusではDoneとLockedを読み分けます。Error storeではrun_id、step、category、executor_tuple、since、untilの6軸が用意され、複数の条件はANDで組み合わされます。条件名を間違えたときに黙って全件を表示せず、拒否する設計も重要です。絞り込めたつもりで違う集合を判断材料に使う事故を防ぐためです。

Regression diffでは、更新したSkillsがどの工程に影響したかを見ます。合格率の大小だけでなく、案件規模と成果物契約が比較できる条件かを確かめます。Benchmark outputでも推奨値だけを抜き出さず、寄与した実行やハッシュをたどれることが検証の根拠になります。これらの画面は、最終判断を自動的に正しくするものではなく、判断材料を確認可能にするものです。

02POINTS　実践の6ステップ

1. 01 対象のprojectとrunをそろえる

   同じrun_idが別のプロジェクトに存在する可能性を考え、対象を明確にします。案件規模、パイプライン版、実行者設定も合わせて確認します。前の実行を見ながら今回の変更を承認しないように、画面上の識別子と証跡の識別子をそろえることが出発点です。

2. 02 工程の終態と門禁モードを読む

   Doneは門禁を省略した完了、Lockedは署名付き裁決で通過した状態です。Pendingは必要な条件や判断が満たされていないことを表し、Failedは裁決の拒否と関係します。実行アダプターの障害と裁決の拒否を混同せず、実行失敗の詳細はエラー記録と合わせて読みます。

3. 03 成果物とエラーの正本へたどる

   工程の出力が保存されているか、どのテスト結果を根拠にしたかを確かめます。成果物の封存マーカーだけで内容の妥当性は判断できません。エラーは記録を消して隠すのではなく、発生した工程と条件から追います。条件の追加によって対象集合が変わるので、検索結果を比較するときは条件自体も記録します。

4. 04 3値裁決を運用の言葉へ落とす

   accepted、accepted-with-open-items、rejectedを区別します。遺留項目付きの受け入れを単純な成功に丸めると、後で誰が何を引き取るか分からなくなります。open itemsには内容だけでなく担当や確認時期を運用上ひも付けます。公開版で統合フォームが未完成の場合は、APIなど実装済みの経路と、その利用権限を確認します。

5. 05 変更操作は署名と許可されたAPIを通す

   公開版の書き込み先は7つに限定され、裁決、実行者の交換、Skillsの回帰検証と昇格、費用超過の確認、回帰セットからの除外、編集ロックを扱います。画面がデータベースを直接変更する経路を増やすと、監査と整合性の前提が崩れます。署名や内容の検証を経て、Harnessの正本へ反映する境界を保ちます。

6. 06 書き込み後に正本から読み直す

   ボタンを押せたことと、操作が受理されたことは別です。応答のエラーを確認し、対象のrunと工程を読み直して状態を検証します。古い画面表示だけを更新して成功と見せないことが大切です。操作者が交代しても、何を判断し何が反映されたかを同じ正本から確認できる状態を目指します。

3値裁決でも、終態は4種類になる

acceptedとaccepted-with-open-itemsは、遺留項目の有無を保ったうえで門禁の通過として扱われます。これに対して、門禁自体を省略したDoneは別の意味です。色だけで判断させず、状態名、門禁モード、裁決の内容を一緒に表示すれば、単なる「緑の完了」に判断の違いが埋もれません。受け入れ後に項目が残ることを、障害であるかのように扱わない整理も必要です。

03INSIGHT　現場へ適用する

見る・判断する・書き戻すを1つの責務にしない

当社の考察では、運用画面の設計は機能を増やす前に権限と判断の境界を描くと整理しやすくなります。閲覧者はどの証跡を参照できるか、裁決者はどの工程を判断できるか、設定変更者はどこまで実行方法を変えられるかを分けます。これらは画面のボタンの配置だけでは確定しません。バックエンドの許可操作と、誰の判断として記録するかを対応付ける必要があります。

SAPの開発・保守にAIを適用する場合も、調査結果の閲覧と本番へ進める判断を同じ操作にまとめるべきか検討が必要です。テストが通ったこと、業務担当が結果を受け入れたこと、引き渡しの条件がそろったことは、それぞれ別の証跡になり得ます。DevFlowの読取モデルと正本を分ける考え方は、こうした業務上の確認点を整理する参考になります。具体的な権限設計は、各組織の承認手順に合わせて詰めます。

6工程全体の関係はDevFlow Harnessの6工程の開発フロー、AIに委ねる処理と承認を残す処理の分け方はAIエージェントとワークフローの使い分けで説明しています。導入時には既存の承認や検証を画面の都合で省略せず、小さな対象で証跡と状態の読み取りを確かめることを勧めます。

工程の名前より、次の担当者が根拠を読めるかを確かめてみましょう。

出典・参考

• DevFlow README（公開コミット1eba062）
• DevFlow 使用手引き（公開コミット1eba062）
• 工程・終態の実装（公開コミット1eba062）
• DashboardのHTTP境界（公開コミット1eba062）

※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-10-15）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。

04FAQ　よくある質問

封存・完了・裁決の違いで迷ったら、次の質問から確認してください。