D2: C4モデル レベル1 シーケンス

inputする成果物

成果物のパス	重要度	内容
docs/D1.business-requirements/product-requirement-document.md	重要	PRD(対象システムの責務・内製/外部の境界の定義元。どこまでを対象システム内の処理として描き、どこから外部システムへ委ねるかの判断根拠)
docs/D1.business-requirements/domain-requirements/*.md	重要	ドメイン要求仕様書群(ドメイン共通要求仕様書を含む)。§業務状態遷移 が当該 UC の前提条件・事後条件、§業務ルール(DOM-*-BR-*) が正常系の判定・順序、§業務運用イレギュラー対応(DOM-*-IRR-*) がガード節(不成立時に打ち切る分岐)の根拠
docs/D1.business-requirements/use-case-list.md	重要	ユースケース一覧(シーケンスの分割単位。1 UC = 1 シーケンス図。UC 名・主アクター・トリガ・主要価値を節見出しとメタ情報・開始メッセージ・終了メッセージにそのまま引く)
docs/D2.system-requirements/c4-level1-system-context.md	重要	C4モデル レベル1(登場要素の唯一の定義元。participant に置けるのは本書 §登場要素の ACT-* / 対象システム / EXT-* のみ。関係ラベルの語彙もここに揃える)
docs/D2.system-requirements/function-list.md	重要	機能一覧(機能グルーピングの定義元。「関連 UC」列で当該 UC を参照する FUNC-* を、その機能が担うメッセージ範囲として opt で括る。機能 ID と機能名をそのまま opt ラベルに引く)
docs/D1.business-requirements/user-story-list.md	補助	ユーザーストーリー一覧(利用者視点の期待・受け入れ条件の補足。メッセージの業務的な言い回しの裏取りに使う)

outputする成果物

成果物のパス	内容
docs/D2.system-requirements/c4-level1-sequences/<ドメインID>_<ドメイン名>/<UC-N>_<UC 名>.md	1 ユースケース 1 ファイル(例: APPL_申込受付/UC-10_申込項目を入力・検証する.md)

使用するテンプレート

出力時は以下のテンプレートを読み込み、その章構成・UC 節の骨組み(メタ情報の項目・Mermaid 図の枠)に従う。

テンプレートのパス	内容
.claude/skills/d2-c4-level1-sequences/template.md	C4モデル レベル1 シーケンス テンプレート(タイトル + UC 節の骨組み)

ユースケース 1 件ごとに本テンプレートを 1 ファイルとして適用する。

記法の正典サンプル

生成前に以下のサンプルを読み込み、エイリアス命名・活性区間・インデント・メッセージ本文の具体度・機能 opt・他 UC 参照の書き方を引き写す。文言レベルの判断に迷ったときは、本スキルの規約とサンプルの実物を突き合わせて揃える。

サンプルのパス	内容
.claude/skills/d2-c4-level1-sequences/example.md	UC-12(申込受付)の完成形 1 ファイル。外部システム 3 体の活性区間・照会ごとのガード節(break)・他 UC への Note over 参照を含む

サンプルは機能 opt を 1 個しか含まないため、複数機能が 1 UC に紐づく場合の並べ方は §機能の可視化 の抜粋に従う。

生成規約

以下は本成果物を生成・更新する際に守る規約。

分割とファイル構成

• 1 UC = 1 シーケンス図 = 1 ファイル。ユースケース一覧の UC をそれ以上まとめない・割らない(分割単位の妥当性判断は上流のユースケース一覧が持つ)。1 ファイルに複数 UC を並べない。
• ファイル名は <UC-N>_<UC 名>.md。UC 名はユースケース一覧の表記をそのまま使い、省略・言い換えをしない(例: UC-10_申込項目を入力・検証する.md)。ただし次の 4 点だけは機械的に変換する(いずれもファイル名・URL の制約によるもので、タイトル # UC-N: {{UC 名}} とサイドバーの label は一覧の表記のまま書く)。
  • ASCII の丸括弧 ( ) は全角の （ ） に置換する(ディレクトリ名も同じ)。Docusaurus のルーティングは ASCII 括弧をパターン記法として解釈するため、含まれるとページが 404 になる(例: UC-11_関係者整合（被保険者同意要否）を検証する.md)
  • UC 名に含まれる / はハイフンに置換する(例: UC-36_保険証券を交付する（電子交付-物理発送）.md)
  • 半角スペースは詰める(例: UC-63_証跡を10年保持し参照可能性を維持する.md)
  • [フェーズ2] ラベルはファイル名から外す(例: UC-24_機械学習で査定を高度化する.md)
• 配置はドメイン単位のディレクトリ。c4-level1-sequences/<ドメインID>_<ドメイン名>/ に置く。ディレクトリ名の <ドメインID> と <ドメイン名> はドメイン定義書の一覧からそのまま引く(例: ASF_反社チェック/・BOOK_契約成立（計上）/)。ドメイン名が長く括弧書きの補足を伴う場合は、ユースケース一覧の「ドメイン / 区分」列の短い表記に合わせる(例: AUDIT_統制・証跡管理/)。ドメイン定義書に載らない区分 横断 は、ドメイン共通要求仕様書の ID 体系に合わせて COMMON_横断/ とする。
• サイドバーの並びはユースケース一覧の UC 番号順。

登場要素(C4 レベル1 の要素だけを使う)

• participant に置けるのは C4モデル レベル1 §登場要素に載っている要素のみ: 人(ACT-*)・対象システム(1 ライフライン)・外部システム(EXT-*)。レベル1 に載っていないアクター・システムは登場させない(必要になった場合は、シーケンスを書き換えるのではなく C4モデル レベル1 側の見直し要否をユーザーに確認する)。
• 対象システムは黒箱の 1 ライフライン。内部を複数 participant に割らない。内部処理は対象システムの自己メッセージ 1 本で表す(何を判定し・何を記録/更新するかを書く。§メッセージ本文)。内部構造(コンテナ・API 名・テーブル名・技術スタック)は書かない(C4 レベル2・D3 設計へ降ろす)。
• 同一業務責務の複数アクターは 1 ライフラインに統合 する。ユースケース一覧の主アクター表記に合わせ、ラベルに ID を中黒で併記する(例: 募集人<br/>ACT-1・ACT-2)。
• ライフラインの並びは 左から: 主アクター → その他のアクター → 対象システム → 外部システム。対象システムを中央に置き、線の往復が交差しないようにする。

Mermaid 記法

骨格

• 各節の図は ```mermaid フェンス内の sequenceDiagram。先頭行に autonumber を置き、メッセージを番号で参照できるようにする。
• participant 宣言は actor(人)/ participant(対象システム・外部システム)を使い分ける。エイリアス ID は小文字 + ID 由来(act1 / sys / ext6)、複数アクター統合時はアンダースコア連結(act1_2)。表示ラベルは 名称<br/>ID(対象システムは ID を持たないため名称のみ)。
• 依頼は実線 ->>、応答は破線 -->>。

メッセージ本文(何をするのかが一目で分かるように書く)

「誰が何を依頼した」で止めず、システムとして何が起きるのかが読んで分かる粒度で書く。方向ごとに書き方を固定する。

方向	書き方	例
人 → 対象システム	画面上の操作 として書く。どの画面のどの操作かを特定できる語(〜画面・〜ボタンをクリック・〜を入力)を使う	申込内容確認画面で<br/>「申込確定」ボタンをクリック
対象システム → 人	画面に何が表示されるか として書く。「提示する」「通知する」で止めない	申込確定完了画面に受付番号と<br/>後続手続きの案内を表示
対象システム → 自身(自己メッセージ)	何を判定し・何を記録/更新するか を書く。「〜を実施」「〜を処理」で止めない	申込の業務状態を「申込確定」へ更新し、<br/>確定日時・確認結果・操作者を<br/>証跡として記録
対象システム → 外部システム / 外部システム → 対象システム	何を渡し・何を受け取るか を書き、C4モデル レベル1 の関係ラベルの語彙に揃える	本人確認結果(確認成否・確認日時)を照会

画面名・ボタン名・表示内容はここまで書いてよい(CLAUDE.md §11 の「例外: シーケンス図の利用者接点」に基づく)。一方、対象システムの内部構造(コンテナ・API 名・テーブル名・カラム名・技術スタック)は書かない。

折り返し

• メッセージ本文と Note 本文は 20 文字程度ごとに <br/> で折り返す。1 行に長文を流し込むと矢印ラベルが横に伸び、図全体が読めなくなるため。20 文字以内に収まる本文は折らない。
• 折る位置は 意味の切れ目(読点の後・助詞の後・括弧の前後)に合わせる。ID(UC-12 / EXT-6 等)や鉤括弧で囲んだ状態名の途中では折らない。
• opt / alt / else の ラベルは折り返さない(ブロックラベルは短く保ち、長くなる説明はメッセージ本文側へ寄せる)。

activate / deactivate(必須)

• 1 つの処理がどこまで続いているかを必ず活性区間で示す。依頼メッセージの直後に activate <受け手>、その処理の応答直後に deactivate <受け手> を置く。
• ->>+ / -->>- の省略記法は使わず、必ず activate / deactivate を独立行で書く(どこで始まりどこで終わるかを行として読めるようにするため)。
• 活性化するのは 対象システムと外部システムのライフラインのみ。人のアクターは処理の起点・終点であり activate しない。
• 活性区間は 開始したブロックと同じブロック内で閉じる。opt / alt をまたいで開始・終了しない。

インデント(可読性)

• sequenceDiagram 直下の行は 4 スペース。opt / alt / else / loop / par / critical / break などのブロックに入るごとに さらに 4 スペース下げ、end はブロック開始行と同じ深さに揃える。
• activate / deactivate はインデントの段を作らない(直前のメッセージと同じ深さ)。
• 意味のまとまり(工程の切れ目・ブロックの前後)には空行を入れ、ブロックが視覚的に固まって読めるようにする。

機能の可視化(opt によるグルーピング)

機能一覧のどの機能がシーケンス上のどの範囲にあたるかを、opt ブロックで囲んで示す。

• ラベル書式は opt FUNC-N: {{機能名}}。機能 ID を先頭に置くこと自体が「グルーピング目的の opt」であることの目印になるため、他の接頭辞は付けない。機能 ID と機能名は機能一覧からそのまま引く。

• 条件分岐としての opt と混同させない: 機能 ID で始まらない opt / alt は本来の意味(条件付き・代替フロー)で使い、機能 opt の 内側 に置く。機能 opt には条件を書かない(opt FUNC-7: 保険料試算機能(試算可能な場合) のような書き方をしない)。

• 機能 opt は 入れ子にしない。1 本のシーケンス上でフラットに並べ、範囲を重ねない(UC-9 のように 1 UC に複数機能が紐づく場合の並べ方):

  opt FUNC-9: プラン比較提示機能
      sys-->>act1_2: プラン比較画面に複数プランの<br/>保障内容・保険料を並べて表示
      sys->>sys: 比較提示の実施日時・提示プラン・<br/>操作者を情報提供証跡として記録
  end
  
  opt FUNC-10: プラン確定・申込引き渡し機能
      act1_2->>sys: プラン比較画面で顧客選択プランを選び<br/>「このプランで申込」ボタンをクリック
      sys->>sys: プランの業務状態を「確定」へ更新し、<br/>確定プラン一式を申込受付へ引き渡す
  end
  

1 つの機能が飛び地になる場合は、機能の粒度か UC の分割を疑い、機能一覧・ユースケース一覧側の見直し要否をユーザーに確認する。

• 網羅: 機能一覧で「関連 UC」列に当該 UC を含む FUNC-* は、その UC のシーケンスに機能 opt として すべて登場させる。逆に、当該 UC を関連 UC に持たない機能を持ち込まない。
• 横断機能(認証・通知配信・帳票出力・同意管理・縮退運用 等)は、機能一覧上でそれぞれ独自の横断 UC に紐づく。業務局面 UC のシーケンスでこれらを再掲せず、必要な場合のみ Note over で参照先 UC を示す(例: Note over sys: 参照: UC-68 業務通知を配信する)。

分岐・例外の描き方

• 不成立はガード節として即時に返す(最重要)。外部照会の結果やシステム判定が「不成立」と分かった時点で break を置き、そのブロック内に 業務状態の保持/記録 と 画面への結果表示 まで書いて処理を打ち切る。判定を溜めておいて末尾で 1 つの alt にまとめない(どの確認で落ちたのか、そのとき利用者の画面に何が返るのかが読めなくなるため)。

  sys->>ext6: 本人確認結果(確認成否・確認日時)を照会
  activate ext6
  ext6-->>sys: 本人確認結果
  deactivate ext6
  
  break 本人確認が未成立・照会不達
      sys->>sys: 申込の業務状態を「確認中」のまま保持し、<br/>本人確認の未成立を停留事由として記録
      sys-->>act1_2: 申込内容確認画面に本人確認が未成立である旨と<br/>再実施導線を表示
  end
  

• 事前条件で保証済みの状態を図の中で再検査しない。ガード節に置いてよいのは、当該 UC の中で初めて成否が判明する事象(外部照会の結果、入力内容の検証結果、期限の到来 等)だけ。上流 UC が成立させた状態(例: 確定設計プランの引き渡し済み)は事前条件に書き、図では検査しない。上流の業務ルールを図へ持ち込む際は、それが「この UC で判明する事象か」を必ず確かめる。

• 正常系(DOM-*-BR-*)はガード節の外側を主線として最後まで通す。図の末尾が成功時の業務状態更新と画面表示で終わる形にする。図の先頭が例外分岐から始まらないようにする。

• alt / else を使うのは、成否ではなく 業務上の複数経路が並ぶ場合(例: 電子交付 と 物理交付、自動判定経路 と 医的査定経路)。不成立・失敗系に alt を使わない。

• 同一アクターがインラインで処理する業務運用イレギュラー(DOM-*-IRR-*)は同じ図に収める。別アクター・別トリガの収束業務は独立 UC としてユースケース一覧に立っているため、ガード節の中では Note over で参照先 UC を示すに留め、その処理自体は描かない。

• 全 IRR を詰め込まない。当該 UC の成否を分ける主要なガード節に絞り、1 図あたりメッセージ 10〜25 本程度に収める。それを超える場合は UC の粒度をユーザーに確認する。

• 外部システム連携の不達・タイムアウトは、当該照会の直後のガード節に 不成立と同じ扱いで合流させる(break 本人確認が未成立・照会不達)。リトライ・保留は loop / Note over で簡潔に示す。

各 UC 節の埋め方

• タイトル: # {{UC-N}}: {{UC 名}}。ID・UC 名はユースケース一覧からそのまま引く(本書は独自 ID を採番しない)。UC が [フェーズ2] の場合はタイトルにも同じラベルを付ける。
• 図の前に置くのは事前条件と事後条件の 2 項目だけ。主アクター・トリガ・関連機能・関連外部システムは図(ライフライン・1 本目のメッセージ・機能 opt)を見れば分かるため、文章側に重ねて書かない。
• 事前条件 / 事後条件: ドメイン要求仕様書 §業務状態遷移の当該遷移の前後の業務状態を 1 行ずつ書く。事後条件は UC の主要価値が成立した状態と、ガード節で打ち切られた場合にどう返るかを書く。「3 確認」「各種確認」のような読み手が中身を復元できない省略語を使わず、対象を具体名で列挙する(例: 本人確認(eKYC)・反社照合・電子署名の 3 つがすべて成立し…)。

網羅(トレーサビリティ)

• ユースケース一覧の全 UC に 1 ファイルが対応すること(UC 総数 = ファイル総数)。
• 機能一覧の全 FUNC-* が、その「関連 UC」列の UC の図に機能 opt として現れること。
• 図に登場する ACT-* / EXT-* がすべて C4モデル レベル1 §登場要素に実在すること。