この記事のポイント
- 6工程の順序を固定し、工程ごとの実行方法を交換できる構成にする。
- 成果物の封存と、人が内容を認める裁決を別々の事実として扱う。
- Done・Locked・Pending・Failedの意味を画面間で統一する。
- 公開版はhumanアダプター中心。構想と接続済み機能を区別して導入する。
01WHAT 役割と実装範囲を確認する
1つの長い会話から、6つの受け渡しへ
AIに依頼した変更が増えるほど、「何を根拠にこの実装になったのか」を後から確認する手間も増えます。調査の途中で設計が変わり、実装後にテスト条件を足すと、会話の流れだけでは合意した仕様と生成されたコードの関係が追えません。途中でモデルや担当者を替える場合は、前の会話を渡すだけでなく、引き継ぐ入力と終了条件を定める必要があります。これは文章の長さより、作業の境界をどう作るかという問題です。
DevFlowはresearch → design → coding → testing → review → deliveryの6工程を固定します。工程の並びは設定ファイルで自由に入れ替える前提ではなく、公開版では起動時に制御側の定義と整合しているか検証されます。一方で各工程の実行設定は分離されており、方法を変えて比較するための土台になっています。流れを固定することは、すべての案件で同じ設計判断を強制することとは異なります。
| 工程 | 確認する問い | 次へ渡す内容の例 |
|---|---|---|
| research | 何を解決するか | 調査結果・前提・制約 |
| design | どの構造で実現するか | 仕様・契約・判断理由 |
| coding | どの変更を加えるか | コードと変更の説明 |
| testing | 期待した動作を満たすか | 検証結果と再現条件 |
| review | 根拠を持って受け入れられるか | 指摘と裁決 |
| delivery | 何を引き渡すか | 成果物と追跡可能な証跡 |
Harness・Agent・LLM・Skillsを混同しない
Harnessは工程順序、成果物の扱い、状態や門禁のルールを管理する制御面です。Agentは作業の進め方を実行する側、LLMは推論に使うモデル、Skillsは工程に適用する手順や知識という見方ができます。DevFlowの説明ではBMAD Methodが方法の層を担い、Herdrは任意の外部観測源として位置付けられます。観測情報だけで工程の完了を決める設計にはしていません。
ここで大切なのは、実行設定の形式を用意したことと、すべての製品を実際に接続できることを分けて読む点です。本記事の確認基準である公開コミット1eba062の手引きでは、標準の実装はhumanアダプターに限定されています。agent・model・skillsを指定する設定や拡張の境界はありますが、任意のAIツールがそのまま実行できるという意味ではありません。ローカルの追加実装や試作画面を利用する場合は、公開版との差分を別途確認します。
確認した版をそろえる
本記事は公開コミット1eba062を基準にした解説です。ローカルの追加実装、試作画面、将来構想を、標準で接続済みの機能として扱いません。
02POINTS 実践の6ステップ
- 01 調査で、対象と制約を言葉にする
対象業務、困っている場面、変更してよい範囲、外部サービスへの依存を整理します。例えばSAP連携の改修なら、対象の伝票、入力元、影響する周辺処理を区別しておきます。調査で見つからなかった事実は、確定事項として次へ渡さず、確認待ちの項目にします。後工程のAIが不足した前提を推測で埋めるのを防ぐためです。
- 02 設計で、入力・出力・終了条件を固める
実装する責務、データの境界、受け入れ条件を明示します。APIの応答形式やエラーの意味が曖昧なまま実装を始めると、テストも都合のよい解釈を追認しがちです。仕様を成果物として残し、どの版を実装の基準にしたか追える形にします。BMADのような方法論を使う場合も、方法の選択と制御基盤の状態管理を分けておくと整理できます。
- 03 実装では、変更範囲と実行者の組合せを残す
同じ仕様でも、どのAgent、モデル、版固定したSkillsを使うかで作業結果は変わり得ます。設定値を残せば、品質や費用の差を後から調べる手掛かりになります。ただし、実行者を記録しただけで公平な比較が完成するわけではありません。次のテスト工程で、同じ案件規模や成果物契約に基づく検証条件を用意する必要があります。
- 04 テストは、出力の体裁より動作の根拠を見る
テスト結果には成功・失敗だけでなく、何を入力し何を期待したかを残します。基準を途中で変えた場合は、その理由と対象を明示します。公開版の手引きでは回帰セットやベンチマークの比較可能性を扱っており、異なる規模や契約の結果を無条件に混ぜない設計です。数字が出ていても、条件がそろっていなければ改善の証拠にはできません。
- 05 レビューで、成果物と裁決を別々に確認する
成果物が封存されたことは、内容が承認されたことを意味しません。DevFlowでは成果物の存在と署名付きの裁決を別の情報として扱います。小さな作業で門禁を省略したDoneと、門禁を通過したLockedを区別するのもこのためです。レビュー担当は、テストの根拠、残る課題、許容する範囲を確認してから判断を記録します。
- 06 引き渡しで、追跡できる一式にそろえる
コードだけでなく、対応した要求、実行時の設定、検証結果、裁決をたどれる状態にします。別の担当者が後から変更するとき、同じ会話を最初から再生しなくても判断の背景を読めることが目標です。公開版のdeliveryでは成果物や裁決への参照をまとめる考え方が示されています。実際の運用では、その証跡が欠けた場合に誰が補い、どこまでを引き渡し済みとするかも決めておきます。
封存と裁決が分かれている理由
封存マーカーは、成果物が所定の場所に保存されたという事実を表します。一方の裁決は、その内容をどの条件で受け入れたかという判断です。公開版の工程起動で見る前提条件は前の成果物の封存であり、「すべての運用ポリシーで承認後だけに次へ進む」と読み替えてはいけません。組織の承認ルールを強くしたい場合は、実装の判定位置と状態遷移を確かめたうえで要件化します。
自動化の範囲を思い込みで広げない
実行設定、成果物の封存、裁決、配信や公開はそれぞれ別の段階です。画面や説明に名前が出ているだけで、実際の動作が実装・検証済みだとは判断できません。
03INSIGHT 現場へ適用する
まず1つの案件で、引き継ぎの欠落を測る
当社の考察では、最初に測るべきなのは「AIが書いた行数」より、引き継ぎ時に何が欠けるかです。設計の前提を聞き直す回数、テストを再実行するための不足情報、レビューで判断できなかった理由を記録すると、工程の境界を整える効果を確認できます。いきなり多数のAgentへ分配するより、1つの小さな改修で6工程の入力と出力を通してみる方が、運用上の穴を見つけやすくなります。
SAPや周辺システムの開発では、変更の意味を業務担当と技術担当の両方が確認します。AIの実行ログだけでは伝票への影響や受け入れ条件は説明し切れません。DevFlowの成果物・裁決という分離を参考に、要求、設計、実装、検証、承認をそれぞれ読める形にします。当社への相談でも、まず対象業務と検証の単位を整理し、AIを適用する範囲を検討できます。
方法論の側から準備する場合はBMad Methodの成果物と判断の残し方、Skillsの整理から始める場合はSkills設計の考え方も参考になります。運用時に誰が何を見るかは、続編のOperator Console入門で説明します。いずれも、導入すれば品質が自動的に保証されるという話ではなく、品質を確認できる境界を作るための設計です。
小さな変更で1周させる
まず1つの改修で入力、成果物、テスト、裁決、引き渡しを追ってみます。各境界で足りない情報を補い、再現できる運用へ育てていきます。
まとめ
- 6工程の順序と、各工程の実行方法を分けて整理する。
- 成果物の封存を、承認・裁決と同一視しない。
- 実行者の設定と比較条件をそろえて品質を評価する。
- 公開版のhuman実装と、追加のAI接続を区別する。
- 引き渡しにはコード以外の検証・判断の証跡も含める。
出典・参考
- DevFlow README（公開コミット1eba062）
- DevFlow 使用手引き（公開コミット1eba062）
- 工程・終態の実装（公開コミット1eba062）
- DashboardのHTTP境界（公開コミット1eba062）
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-10-15）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。
04FAQ よくある質問
6工程は好きな順番に変えられますか？
本記事の公開版ではsoftware-v1の順序を固定し、起動時に整合性を検査します。工程内の実行方法を替えることと、工程順序を替えることは別です。
どのAIツールでもすぐ実行できますか？
公開コミット1eba062の手引きでは標準実装はhumanアダプターです。任意のAgentやLLMへの接続がすべて完成しているわけではなく、アダプターと契約の実装確認が必要です。
Doneなら人の承認も完了していますか？
Doneは小さな作業などで門禁を省略した状態です。署名付き裁決で門禁を通過したLockedとは意味が異なります。
失敗時は自動でモデルが切り替わりますか？
公開版には再試行の段階を扱う仕組みがありますが、手引きでは実障害からの自動起動は未接続とされています。設計上の段階と、自動運転できる範囲を区別してください。