プロセスをストーリーラインとしてモデル化する — 正しい方法

複雑なプロセスをストーリーラインに変換するのは、転記ではなくモデリングの演習です。詳細は フローをストーリーラインにコンパイルする に記載されています。これは、単に大半の場合に動作するグラフを作成するのではなく、結果を信頼できるものとするための 思考方法 です。

プロファイルから始め、次に分岐点を決める

ノードを描く前に、追跡対象（つまり profile_schema、例：docs_ready、risk_flag、attempts）を決定します。次に、単なるハッピーパスだけでなく、実際の意思決定ポイント をマッピングします。会話の分岐や失敗が発生するすべての箇所は、出口を持つノードです。理想的なパスのみをモデル化したフローは、ユーザーが予期せぬ行動をとった瞬間に壊れます。

1 ノード = 1 つの整合的なステップ

ノードは、人が名付けるような単一のタスク（「書類の収集」、「本人確認」など）を実行すべきです。サブプロセス全体を単一ノードの task に押し込めて、モデルがそれを順序付けしてくれると期待しないでください。そうすると、分岐、再開、測定する能力を失います。ノードのタスクに「そして次に、そして次に」という表現がある場合、それは複数のノードです。

結果が信頼できる場合は、分岐を決定論的にする

• ブランチが予測可能である必要がある場合は、rule（プロファイルの次元に対して）または user_choice でルーティングします。真の判断（「実際に問題の説明を行ったか？」など）に対してのみ、ai 出口を予約します。
• 出口は優先順位付きです。決定論的なものを先に配置し、ai のフォールバックを最後に配置します。
• バックエッジと writes カウンター（op: "inc"）および rule 上限を使用して、リトライループをモデル化します。モデルがループを十分に行ったと判断することに依存しないでください。

アイデンティティと安全性はノードではなくエージェントに保持する

エージェントの soul と安全性の境界は、ストーリーライン全体を通じて一定です。それがポイントです。ノードごとにペルソナを再定義したり、安全性を再適用しようとしないでください。ノードはタスク/スキル/知識ベース/ツールを追加し、プロファイルの次元に書き込むことのみを行います。

node_key を安定させて維持し、公開前に検証する

node_key は出口のアイデンティティおよびファネル参照です。update_storyline で編集する際は、それらを安定して維持してください。ノードをリネームすると、その出口が静かに孤立します。publish_storyline の前に常に validate_storyline を実行してください。これにより、到達不能なノード、行き止まり、および dangling な出口が検出されます。

過剰なモデリングを行わない

タスクが単一の質問と回答である場合、それはストーリーラインではありません。それはナレッジベースを持つエージェントです。真のマルチステップ状態の継承（情報収集、チュータリング、ガイダンス付きアプリケーションなど）がある場合にのみ、ストーリーラインを使用してください。一発の Q&A をグラフとしてモデル化すると、何の価値もなくコストと障害モードが増加するだけです。

失敗しやすい一般的なパターン（これらを避ける）

• ハッピーパスのみ — 「ユーザーが混乱している」または「提供されていない」場合の出口がないため、フローが停止する。
• すべてが ai 出口 — ルーティングが賭け事になる；同じ入力でも異なるパスを取る。
• メガノード — 1 つのノードの task がプロセス全体を記述している；分岐も再開もできない。
• 無制限のループ — カウンターも上限もないバックエッジ。
• ノードごとに安全性を再定義 — エージェントの実際の境界と競合するノイズ。

これらは、実際の状態を特定し、各意思決定を決定論的な出口に移動することで修正します。