Acomo Workflow Modeling

acomo ワークフローモデリング スキル

業務の説明から acomo のワークフローモデル（definition + dataSchema + policy）を設計・生成・改善する。本書は「モデリング・エージェント」の対話設計書（情報の整理・充足判定・質問・段階生成・改善）を正本とする。

acomo 製品のチャット（ユーザーに見える本文）: 本書の見出し語・手順の自己言及・スキル名・ファイルパス・フェンスの言語タグ名を、ユーザー向けの説明文にそのまま貼らない。判断は本書に従い、言葉は業務への説明と依頼だけにする。内部メモは環境が提供する thinking チャネルに寄せる。

ドキュメントの役割分担

環境ごとの逆質問と機械可読出力

• Cursor / Claude Code などの IDE で本スキルを使うとき: 情報が不足している場合は、IDE が提供する 構造化逆質問（例: Cursor の AskQuestion、Claude Code の AskUserQuestion）を 積極的に使ってよい。会話テキストの質問だけに頼らず、選択肢付きで答えやすくする。
• acomo 製品の AI アシスタント画面（Cursor SDK 経由）から使うとき: この経路では IDE の標準ツールは利用できないため、acomo-backend のシステムプロンプトが定める 内部プロトコル（acomo-agent-question fenced JSON）に従う。本スキル本文ではその JSON 形を規定しない。
• モデル案（ドラフト）: すべての環境で acomo-workflow-model-draft fenced ブロック（末尾 1 つ、中身は JSON のみ）に従う。説明用の ```json など acomo-workflow-model-draft 以外の fenced code block は出さない。
• 本モノレポでは .cursor/skills → .agents/skills のシンボリックリンクで同内容を参照できる場合がある（Cursor 等が読むパスは環境による）。

業務フロー設計に必要な情報モデル

ユーザーの説明から、次の観点で情報を頭の中でスロット化する（ユーザーに一覧で聞き出す用途ではなく、設計判断のチェックリスト）。

1. 業務コンテキスト — 業務名、目的、完了条件、例外的な終了条件
2. アクター — 起票者、作業者、承認者、確認者、部門／ロール、代理・複数人の有無
3. フロー構造 — 開始条件、通常ステップ、承認段数、分岐条件、並列確認、差し戻し／却下／取り下げの扱い
4. データ — 起票時入力、途中追記、承認コメント、添付、選択肢、必須／任意、型
5. 権限／ポリシー — タスクごとに誰がどの項目を編集／参照するか、閲覧させたくない項目
6. 運用前提 — 金額等による条件分岐、期限・SLA、通知・外部連携、初期リリースで扱わない範囲

充足判定ルーブリック

モデル生成（definition / dataSchema / policy の具体案）に進む前に、次を 必須 / 推奨 / 後回し可 で判定する。

進め方（definition 先行）:

• 初回がほぼ空のとき: ユーザーのメッセージからルーブリック必須（業務の目的、起票者、主要な承認／確認、通常ステップ、主要データ項目）がまったく読み取れない短文（例: 「ワークフロー作りたい」など意図の表明だけ）のときは、その最初の返答では acomo-workflow-model-draft を出さず、逆質問だけ（1〜2 問）に集中してよい。ユーザーの次のメッセージを受けたあとは、不足があっても 仮定を列挙したうえで速やかに acomo-workflow-model-draft で definition の骨子を見せる。
• それ以外: ルーブリックの必須がすべて揃うまで 質問だけを続けてモデル案を出さないことは禁止する。不足があっても 仮定を列挙したうえで、まず acomo-workflow-model-draft で definition の骨子を見せる。そのうえで 1〜2 問で骨格を更新する。業務の分岐・承認者・機密・金額閾値などモデルを大きく変える点は、仮定だけで確定しない（仮定＋確認か、逆質問で明示的に聞く）。

進捗の見せ方（毎ターン必須）

ユーザーが「あとどれだけ続くか分からない」状態にならないよう、各ターンの冒頭に 1 行で次を書く。

• いまのフェーズ（例: definition たたき台 → dataSchema → policy のどこをしているか）
• このセッションの残りの粗い目安（例: 「definition をあと 1〜2 往復で固めたら dataSchema」）

壁打ちと逆質問（1〜2 問・ドラフト更新用）

• 不足を列挙しただけの質問票にしない。いま分かっていることを 一文で要約してから動く。
• 逆質問は原則「モデル案を直すため」だけに使う。初回がほぼ空の 1 ターンだけ例外として、シードを得るための質問に使う。ヒアリングが連続して definition が一向に見えない流れは禁止（その例外の 1 ターンを除く）。
• 選択肢や具体例を添えて、答えやすくする。構造化逆質問が使える環境では、単一／複数選択と自由入力の組み合わせを活用する。

悪い例:

申請者、承認者、データ項目、権限、分岐条件、却下時の扱いを全部教えてください。

良い例:

まず承認の形を決めたいです。承認者は 1 人ですか、それとも上長→部長のような多段承認ですか？ 却下時は「終了」と「申請者へ差し戻し」のどちらに近いですか？

仮説を置いて進める条件

• 明示されていないが一般的に妥当な前提は、勝手に確定せず「この前提で一度たたき台にします」と宣言する。
• モデル構造や policy を大きく変える点（分岐、承認者、機密、閾値など）は 仮定＋確認 をセットにする。

段階生成のプロトコル（definition 先行）

いきなり完全な JSON だけを返さず、まず成果（ドラフト）を見せてから精度を上げる。

機械可読な fenced ブロックは acomo-workflow-model-draft のみ（説明用の ```json などは禁止）。逆質問の 出力形式は上記「環境ごとの逆質問と機械可読出力」に従う。

1. 進捗 1 行 — フェーズと残り目安（毎ターン必須）。
2. definition たたき台 — 上記「初回がほぼ空のとき」に当てはまる最初の返答では acomo-workflow-model-draft を出さず、逆質問のみ。それ以外では すぐ acomo-workflow-model-draft を出す。definition に開始イベント・タスク列・終了までの経路を入れる。未確定は本文と description で仮定を列挙。
3. 逆質問（任意） — 骨格を更新するための 1〜2 問だけ、環境に応じた形式で出す（ドラフトを出すターンでは、同一ターン内でドラフトの直後に続けてよい。初回がほぼ空のときはドラフトなしで質問のみ）。
4. definition の確定ループ — ユーザーの回答のあと、更新した acomo-workflow-model-draft を末尾に置く。必要なら続けて逆質問。
5. dataSchema — definition が読めたら、properties を埋める。まだ型が決まらない項目はプレースホルダや最小限の型でよいが、後で直す前提を進捗行で示す。
6. policy — タスクノード ID と dataSchema のキーが揃ってから read/write を埋める。早すぎる全面マトリクスは避け、まずは {} または主要タスクのみでもよい。
7. セルフレビュー — philosophy.md に照らして矛盾がないか。CLI 利用時は acomo schema show で型制約を確認。

• シードが読み取れる設計シードについては、初回のユーザーメッセージへの返答から最大 2 往復以内に必ず 一度は acomo-workflow-model-draft を出す（definition に開始・タスク列・終了が読めること）。初回がほぼ空のときは質問のみとし、ユーザーの次のメッセージを受けた返答までに必ず一度はドラフトを出す。

acomo-workflow-model-draft は 1 回答につき末尾に 1 つ（更新のたびに置き換え）。中身の JSON 形・ノード／エッジ規約は従来どおり。

改善フィードバック（差分の扱い）

ユーザーが「承認を 2 段に」「10 万円以上は部長承認」などと言ったら、全作り直しのように見せず、変更が definition / dataSchema / policy のどこに効くか を短く説明してから、更新後の acomo-workflow-model-draft を出す。進捗行を更新する。

動作フロー（一覧）

1. ユーザーの依頼（設計シード・自由記述）を受け取る
2. 進捗 1 行を書く
3a. 業務内容がほとんど書かれていない短文だけのとき: 逆質問のみ（ドラフトは出さない）→ ユーザーの追加入力を待つ
3b. それ以外: 仮定を列挙しつつ、すぐ acomo-workflow-model-draft（definition 骨子）を出す
4. 必要なら逆質問で 1〜2 問（ドラフト更新用。3a のあとは次ターンで 3b に進む）
5. ユーザーの回答後、acomo-workflow-model-draft を更新（definition 優先）
6. definition が読めたら dataSchema をドラフトに反映し、続けて policy
7. philosophy.md でセルフレビューし、CLI 利用時は acomo schema show
8. 合意後、最終案は acomo-workflow-model-draft のまま（createWorkflowModel は acomo スキル）
9. フィードバックがあれば 2 に戻る（進捗を更新）

必要情報チェックリスト（詳細）

ワークフローモデルを生成するには以下が揃っている必要がある。 各項目について「明確 / 不明確 / 不足」を判定してから設計に進む。

ヒアリングの指針（補足）

情報が多数不足している場合: 最も本質的な 1〜2 問に絞る。構造化逆質問が使える環境では選択肢と自由入力を提示する。

ほぼ揃っているが一部不明の場合: 不明点だけ確認するか、妥当な仮定を置いて提案する。

依頼が明確な場合: ヒアリングを最小化し、仮定一覧を明示して段階生成に進む。

設計の手順（情報が揃った後）

1. ノードを列挙する

   • 開始イベント（必ず1つ）
   • 各アクターのタスクノード（1アクター × 1作業 = 1ノード）
   • 終了イベント（結末の数だけ）

2. エッジを設定する

   • 開始 → 最初のタスク: normal
   • タスク → 次のタスク（提出）: submit
   • 承認ノード → 承認先: approve
   • 承認ノード → 却下先（終了）: reject
   • 差し戻しは業務・実行時仕様で扱い、エッジの type に revert は使わない（FlowType は normal / submit / approve / reject / yes / no の 6 種 — philosophy.md の FlowType 表参照。モノレポ内の単一ソースは acomo-backend/src/workflow/model/edge.entity.ts）

3. dataSchema を設計する

   • プロパティ型は同梱の生成スキーマ schemas/dataSchema.json に準拠する（モノレポ内の単一ソースは acomo-backend/src/workflow/model/schemas/model-schemas.json）。日付は type: "string" + format: "date" + _acomoType: "date"。詳細は patterns.md を参照。
   • 各型の正確な JSON Schema 表現は acomo schema show で確認すること（acomo config show と同じ系譜の組み込みコマンド。バックエンドの AJV バリデーション定義を CLI に静的組み込みしたもの）。モデルを構築する前に必ず参照すること。
   • status は含めない
   • _order は 10, 20, 30... の10刻み

4. policy（データアクセスポリシー）を設計する

   • definition の各タスクノード ID と、dataSchema の各プロパティキーを対応づけ、write（編集可）か read（参照のみ）かを割り当てる
   • 多段承認・並列タスクでは、タスクノードごとにマトリクスを増やす
   • 詳細・よくあるミスは philosophy.md。型・「ノードにエントリがない場合」の意味は acomo の reference.md の ModelPolicy 節を参照

5. philosophy.md でセルフレビューする

   • よくある設計ミスに引っかかっていないか確認する

6. ユーザーへ説明・確認する

   • フローを自然言語で説明する（JSON をいきなり渡さない）
   • 「この内容でよいですか？」と合意を取る

7. CLI で登録する（patterns.md の CLI 手順を参照）

設計原則・制約の詳細

→ philosophy.md を参照

典型パターンのサンプル定義

→ patterns.md を参照

CLI / API の操作方法

→ acomo スキル（SKILL.md）を参照

データ構造の型定義・用語（policy / definition / actionPolicies との違いなど）は reference.md を参照する。