# Acomo Workflow Modeling > acomo のワークフローモデルを設計・生成・改善するスキル。 進捗を明示しつつ、十分なシードがあればドラフト（acomo-workflow-model-draft）を先に見せ、逆質問で更新する。初回がほぼ空のときは逆質問を先に置ける。 業務フローをモデル（definition + dataSchema + policy）に落とし込む作業全般に使う。 acomo CLI の基本操作は acomo スキルを併用すること。 - Skill: `progress-all/acomo-workflow-modeling` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds add progress-all/acomo-workflow-modeling` - Raw SKILL.md: https://api.skillmd.com/api/skills/progress-all/acomo-workflow-modeling/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: progress-all (https://skillmd.com/u/progress-all) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/progress-all/acomo-workflow-modeling --- # acomo ワークフローモデリング スキル 業務の説明から acomo のワークフローモデル（definition + dataSchema + policy）を設計・生成・改善する。**本書は「モデリング・エージェント」の対話設計書**（情報の整理・充足判定・質問・段階生成・改善）を正本とする。 > **acomo 製品のチャット（ユーザーに見える本文）**: 本書の見出し語・手順の自己言及・スキル名・ファイルパス・フェンスの言語タグ名を、ユーザー向けの説明文にそのまま貼らない。判断は本書に従い、**言葉は業務への説明と依頼だけ**にする。内部メモは環境が提供する thinking チャネルに寄せる。 ### ドキュメントの役割分担 | 文書 | 役割 | |------|------| | **SKILL.md（本書）** | 対話フロー、判断基準、段階生成、モデル案（`acomo-workflow-model-draft`）の機械可読出力、逆質問の方針（形式は環境依存） | | [philosophy.md](philosophy.md) | 設計原則・セルフレビュー・よくある誤り | | [patterns.md](patterns.md) | 典型パターン・CLI 手順・サンプル定義 | ### 環境ごとの逆質問と機械可読出力 - **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 の具体案）に進む前に、次を **必須 / 推奨 / 後回し可** で判定する。 | 観点 | 必須 | 推奨 | 後回し可 | |------|------|------|----------| | 業務の目的・完了のイメージ | ○ | | | | 起票者（誰が始めるか） | ○ | | | | 主要な承認／確認と段数のイメージ | ○ | | | | 通常ステップの粗い流れ | ○ | | | | 主要データ項目（名前レベル） | ○ | | | | 却下・差し戻しの方針 | | ○ | 仮定明示で暫定可 | | 並列確認の有無 | | ○ | 仮定明示で暫定可 | | 項目型・enum 値 | | ○ | たたき台後に精緻化 | | 詳細な read/write マトリクス | | | 初版は推測しにくい箇所だけ必須 | **進め方（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 | **申請者**（誰が起票するか） | 最初のタスクノードが決まらない | | 3 | **承認者・確認者**（誰が判断するか、何段階か） | タスクノードの数と順序が決まらない | | 4 | **各ステップの作業内容** | ノード名と役割が決まらない | | 5 | **却下・差し戻し方針**（フロー終了 or 申請者へ差し戻し）| `reject` 終了か差し戻し運用かが決まらない | | 6 | **並列承認の有無**（複数承認者が同時に判断するか）| `parallelFork/Join` が必要か決まらない | | 7 | **データ項目**（何の情報を入力・参照・更新するか）| dataSchema が定義できない | | 8 | **各データ項目の型**（文字 / 数値 / 日付 / ファイル / 選択肢）| dataSchema のプロパティ型が決まらない | | 9 | **enum の選択肢**（選択肢型の場合、何を選べるか）| dataSchema の enum 値が決まらない | | 10 | **タスクごとのデータ権限**（各タスクで項目を**編集**するか**参照のみ**か）| policy（read/write）が定義できない | | 11 | **段階限定の入力項目**（例: 承認者コメントのみ承認タスクで記入）| dataSchema のキーと policy の対応が決まらない | --- ## ヒアリングの指針（補足） **情報が多数不足している場合**: 最も本質的な 1〜2 問に絞る。構造化逆質問が使える環境では選択肢と自由入力を提示する。 **ほぼ揃っているが一部不明の場合**: 不明点だけ確認するか、妥当な仮定を置いて提案する。 **依頼が明確な場合**: ヒアリングを最小化し、仮定一覧を明示して段階生成に進む。 --- ## 設計の手順（情報が揃った後） 1. **ノードを列挙する** - 開始イベント（必ず1つ） - 各アクターのタスクノード（1アクター × 1作業 = 1ノード） - 終了イベント（結末の数だけ） 2. **エッジを設定する** - 開始 → 最初のタスク: `normal` - タスク → 次のタスク（提出）: `submit` - 承認ノード → 承認先: `approve` - 承認ノード → 却下先（終了）: `reject` - 差し戻しは業務・実行時仕様で扱い、エッジの `type` に `revert` は使わない（`FlowType` は `normal` / `submit` / `approve` / `reject` / `yes` / `no` の 6 種 — [philosophy.md](philosophy.md) の FlowType 表参照。モノレポ内の単一ソースは `acomo-backend/src/workflow/model/edge.entity.ts`） 3. **dataSchema を設計する** - プロパティ型は同梱の生成スキーマ [`schemas/dataSchema.json`](schemas/dataSchema.json) に準拠する（モノレポ内の単一ソースは `acomo-backend/src/workflow/model/schemas/model-schemas.json`）。日付は `type: "string"` + `format: "date"` + `_acomoType: "date"`。詳細は [patterns.md](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](philosophy.md)。型・「ノードにエントリがない場合」の意味は [acomo の reference.md](../acomo/reference.md) の ModelPolicy 節を参照 5. **philosophy.md でセルフレビューする** - よくある設計ミスに引っかかっていないか確認する 6. **ユーザーへ説明・確認する** - フローを自然言語で説明する（JSON をいきなり渡さない） - 「この内容でよいですか？」と合意を取る 7. **CLI で登録する**（[patterns.md](patterns.md) の CLI 手順を参照） --- ## 設計原則・制約の詳細 → [philosophy.md](philosophy.md) を参照 ## 典型パターンのサンプル定義 → [patterns.md](patterns.md) を参照 ## CLI / API の操作方法 → acomo スキル（[SKILL.md](../acomo/SKILL.md)）を参照 データ構造の型定義・用語（policy / definition / `actionPolicies` との違いなど）は [reference.md](../acomo/reference.md) を参照する。