公開2026.07.11更新2026.09.05 22 人が閲覧（直近 30 日）アーキテクチャ

シーケンス図とは？UMLの書き方とライフライン・複合フラグメント・Mermaid実装を解説

シーケンス図とは、複数のオブジェクトが時間の流れに沿ってどんな順番でメッセージをやり取りするかを表すUMLの図です。システムの「静的な骨格」を描くクラス図に対して、シーケンス図が描くのは「時間軸に沿った動き」になります。この記事では、ライフライン・メッセージ・活性化という基本の記法から、同期と非同期メッセージを設計判断として切り分ける考え方、条件分岐や繰り返しを表す複合フラグメント、クラス図との役割分担、MermaidやPlantUMLのコードで書いて画像に出力するまでの手順、そして設計工程で書くべき場面と過剰設計になる失敗パターンまでを、設計と実装の現場視点で整理します。

まとめ：シーケンス図の構成要素・メッセージの書き方と設計での役割

シーケンス図の芯は、オブジェクト同士がどんな順番で処理を呼び合うかを、時間軸に沿って一枚で追えるようにする点です。上部に並べた登場人物からライフラインと呼ぶ縦の点線を下ろし、その間を横向きの矢印（メッセージ）で結びます。矢印は上から下へ時系列に読み、どの処理がどの処理を呼び出したかが一目で読み取れる点が特徴といえます。

押さえる要素は多くありません。登場人物を表すライフライン、処理が動いている期間を示す活性化（アクティベーション）、命令を伝えるメッセージの3つが土台です。メッセージには、応答を待つ同期と待たない非同期があり、この区別はそのままAPI呼び出しかイベント駆動かという設計判断につながります。条件分岐や繰り返しは、alt・opt・loop・parといった複合フラグメントの枠で囲んで表す決まりです。

作図の手段は、GUIの作図ツールだけではありません。MermaidやPlantUMLならテキストで書けるため、図をソースコードと同じリポジトリに置いてGitで差分を追えます。この記事では、実際に貼り付けて動かせるMermaidとPlantUMLの記述例、コマンド一行でSVGやPNGへ書き出すmmdcの使い方まで載せました。

シーケンス図が効くのは、詳細設計で処理の流れを詰める工程と、複数のサービスやクラスが絡む複雑なやり取りを関係者で合意する場面です。逆に、単純な一本道の処理まで律儀に図にすると、保守されない紙の資料に終わります。どの処理を図にし、どこで手を止めるか、その線引きまで条件付きで言い切ります。静的な構造の側はクラス図が担い、本記事はその構造がどう動くかを描く役割です。

シーケンス図とは何か：UMLにおける定義とクラス図との役割分担

はじめに言葉の範囲をそろえます。シーケンス図は、システムの振る舞いを「誰が、いつ、誰に、何を頼むか」という時間順で捉える図です。部品の設計図であるクラス図とは、描く対象がそもそも違います。

シーケンス図の定義と、時間軸の動きを表すUMLの相互作用図としての位置づけ

シーケンス図は、UML（Unified Modeling Language）で定義された相互作用図の一種で、オブジェクト間でやり取りされるメッセージを、時間の経過に沿って表します。狙いは、実装に入る前に「処理がどんな順番で流れ、どのオブジェクトがどのタイミングで動くか」を設計として固めることです。たとえばECサイトの注文処理なら、利用者・注文画面・在庫サービス・決済サービスといった登場人物を横に並べ、在庫を確認してから決済を呼ぶ、という順序を矢印の並びで描きます。時間の概念を持たないクラス図が「部品の設計図」なら、シーケンス図は「部品がどう連携して動くかの台本」にあたると考えてください。

UML 2.5.1仕様書で相互作用の定義を確かめて用語のぶれを消す方法

シーケンス図の用語は、書籍やツールごとに訳語が揺れます。ライフラインを「オブジェクト」と呼んだり、活性化を「実行仕様」と書いたりする資料が混在するため、チーム内で定義がずれると設計レビューが空転しがちです。よりどころになるのは、標準化団体OMGが公開しているUML仕様書そのもので、公開ページ上の最新版は2.5.1（文書番号 formal/17-12-05、2017年12月発行）と表示されています。PDF本体は無償で参照でき、Interactions（相互作用）の章にライフライン・メッセージ・実行仕様・複合フラグメントの正式な定義が並びます。

実務での使い方は単純で、記法の解釈が割れたときだけ引く辞書として置いておけば足ります。たとえば「非同期メッセージの矢じりは塗りつぶすのか」「loopの回数指定はどこに書くのか」といった細部は、仕様書の該当節を一度見ればチーム内の議論が終わります。仕様が2017年12月版のまま更新されていない点も、逆にいえば記法が安定している証拠と読めるでしょう。ツールの独自拡張と標準記法の境目を見分けるうえでも、一次情報を一度通しておく価値があります。

クラス図（静的構造）とシーケンス図（時間軸の動き）の役割分担と使い分け

同じUMLでも、クラス図とシーケンス図は補い合う関係にあります。クラス図はどんなクラスがあり互いにどうつながるかという静的な構造を表し、シーケンス図はそのクラスたちが実行時にどんな順で呼び合うかという動的な振る舞いを表します。設計では、まずクラス図で登場人物と関係を固め、次にシーケンス図で処理の流れを追う、という順で使うと過不足がありません。両者を照らし合わせると、クラス図に描いた操作が実際にどこから呼ばれるかが見え、逆にシーケンス図で必要になった呼び出しがクラス図の操作漏れをあぶり出します。静的な構造の描き方はクラス図とは何かで詳しく扱っているので、対にして読むと設計の解像度が上がるはずです。なお、そもそもシステムにどんな機能があるかを利用者目線で洗い出す段階にはユースケース図を使い、その機能の内部処理をシーケンス図で詳細化する、という順に進みます。

ライフライン・メッセージ・活性化というシーケンス図の3つの基本要素

シーケンス図は、3つの要素さえ読めれば骨格をつかめます。まずライフラインは、登場人物（オブジェクトやアクター）を表す頭部の長方形と、そこから真下に伸びる点線を指します。時系列で先に動くものを左に置くと、図が格段に読みやすくなる点がコツです。次に活性化（アクティベーション）は、ライフライン上に重ねる細い縦長の長方形で、そのオブジェクトが処理を実行している期間を表します。メッセージを受けてから応答を返すまでの長さが、この短冊にあたると考えてください。そしてメッセージは、ライフライン間を結ぶ横向きの矢印で、あるオブジェクトが別のオブジェクトへ出す命令を示します。この3要素が組み合わさり、上から下へ読める処理の台本ができあがります。

シーケンス図のメッセージの種類：同期・非同期・応答と複合フラグメントの書き方

シーケンス図で表現に差が出るのは、矢印の引き分けと、処理のまとまりの囲み方です。メッセージの種類を正しく使い分けられると、図が処理の意図まで語り始めます。

同期メッセージと非同期メッセージを設計判断として切り分ける基準

メッセージの矢印は、応答を待つかどうかで描き分けます。同期メッセージは、塗りつぶした三角の矢じり（実線）で表し、呼び出した側は応答が返るまで処理を止めて待ちます。メソッド呼び出しや、結果を受け取ってから次へ進むAPIリクエストが典型です。非同期メッセージは、開いた矢じり（線状）で表し、呼び出した側は応答を待たずに次の処理へ進みます。メッセージキューへの送信や、イベント通知、バックグラウンドジョブの起動がこれにあたります。応答（リターン）は破線の矢印で、呼び出しに対する戻り値を示す線です。

ここで押さえたいのは、この描き分けが図の見た目の問題ではなく、設計判断そのものだという点です。同期で描けば処理は直列につながって追いやすい反面、呼び出し先が遅いと全体が待たされます。非同期で描けば待ち時間を切り離せる一方、応答の受け取りや失敗時の扱いを別で設計する必要が出てきます。シーケンス図の矢印を選ぶ行為は、その処理を同期で組むか非同期で組むかを決める行為とほぼ同じだと考えてください。オブジェクト間のメッセージがメソッド呼び出しに対応するという前提はオブジェクト指向の考え方を土台にしています。

生成・破棄・自己呼び出しといった残りのメッセージ記法の使い分け

同期・非同期・応答の3種類を覚えれば大半の図は描けますが、実務では残り3つの記法も必要です。生成メッセージは、処理の途中で新しいオブジェクトが作られる様子を表し、矢印の先に相手のライフライン頭部を配置します。破棄メッセージは、オブジェクトの寿命が尽きる箇所にバツ印を置いて示す記法で、セッションや一時オブジェクトの生存期間を明示したいときに効きます。自己呼び出し（自己メッセージ）は、同じライフラインへ戻る鉤型の矢印で、オブジェクトが自分自身のメソッドを呼ぶ場合に描く形です。

これらは、書かないと図が読めなくなる場面に限って足すのが実務的な線引きです。たとえば接続プールやトランザクション境界を説明する図では、いつ生成していつ破棄するかが議論の中心なので、生成と破棄の記法が効きます。一方、内部のヘルパーメソッド呼び出しを全部自己メッセージで描くと、コードをなぞっただけの図に転落します。記法を知ったうえで、設計判断が要る箇所だけ使うという順序を守ってください。

alt・opt・loop・parで条件分岐や繰り返しを表す複合フラグメントの使い分け

単純な一本道の処理なら矢印を並べるだけで足りますが、条件分岐や繰り返しは複合フラグメントという枠で囲んで表します。枠の左上にラベルを付け、何のまとまりかを示すのが記法です。よく使うものを表にまとめました。

キーワード	表すもの	対応するコード
alt	条件で分かれる分岐	if と else
opt	条件成立時だけ実行	else のない if
loop	まとまりの繰り返し	for や while
par	同時に走る処理	並行実行・並列処理
break	以降を中断する分岐	例外や早期リターン

altは条件分岐で、複数の条件のうちどれか一つが実行される場合に使い、if-else に相当する枠です。optは省略可能な処理で、条件を満たしたときだけ実行される、else のない分岐を表します。loopは繰り返しで、一覧の各要素を処理するような反復に使う枠です。parは並行処理で、複数のまとまりが同時に走る様子を囲む枠です。breakは、条件が成立したらそのフラグメント以降を実行せず抜ける枠で、エラー時に処理を打ち切る流れを描くときに使います。これらを入れ子にすれば、実際のコードのフロー制御をかなり忠実に描けます。

ただし、フラグメントを深く入れ子にしすぎると、図がコードそのものより読みにくくなる点には注意が要る、というのが実務の勘所です。分岐や繰り返しの中でも、設計判断が要る中核の流れだけをフラグメントで囲み、細部は本文の注釈へ逃がすほうが、図は伝わりやすくなります。目安としては入れ子2段までに抑え、それ以上必要になったら図を分割する判断へ切り替えてください。

シーケンス図の書き方：登場人物を洗い出して矢印を時系列に並べる手順

要素とメッセージの種類を押さえたら、実際に描く手順に移ります。いきなり矢印から書き始めず、登場人物ときっかけを先に決めるのが、破綻しない図への近道です。

登場人物とメッセージを時系列に並べるシーケンス図の基本的な作成手順

シーケンス図は、次の4ステップで組み立てると過不足がありません。処理のきっかけから終わりへ、上から下へ順に確定させます。

登場人物を洗い出す：処理に関わるアクターやオブジェクト（利用者・画面・サービス・DBなど）を挙げ、動く順に左から並べる
きっかけを決める：どのアクションから処理が始まるか（ボタン押下やAPIリクエストなど）を最初のメッセージにする
メッセージを時系列に結ぶ：呼び出しを上から順に矢印で描き、同期・非同期・応答を矢じりで描き分ける
条件分岐と繰り返しを囲む：alt・opt・loop・parのフラグメントで、分岐や反復のまとまりを枠に入れる

最初から例外処理やエラー分岐まで盛り込もうとせず、まずは正常系（うまくいく場合）の一本道を描き切るのがコツです。正常系が固まってから、失敗時の分岐をaltで足していくと、図が破綻しません。一度にすべての流れを描こうとせず、一つのユースケースにつき一枚を目安にすると、読める粒度に収まります。

ECサイトの注文処理を題材に正常系のシーケンス図を書き起こす手順

手順を具体で追ってみます。題材は「利用者が注文確定ボタンを押し、在庫を確認してから決済する」という処理です。第1ステップの登場人物は、利用者（アクター）・注文画面・在庫サービス・決済サービスの4つになります。動く順に左から並べる原則に従い、この順で配置します。第2ステップのきっかけは「注文確定を押す」という利用者の操作です。

第3ステップでは、注文画面が在庫サービスへ在庫確認を投げ、結果を受け取ってから決済サービスを呼ぶ流れを矢印で結ぶ段階です。在庫確認も決済も結果を待つ必要があるため、どちらも同期メッセージとして描き、返りは破線の応答で表します。第4ステップで、在庫がある場合と足りない場合をaltで囲めば、正常系と主要な例外分岐が一枚に収まる構成です。この4ステップを踏むと、次節のMermaidコードがほぼそのまま書き下せる状態になります。

MermaidとPlantUMLでシーケンス図を書いて画像へ出力する作業手順

作図ツールで描いたシーケンス図は、処理が変わるたびに矢印を引き直す手間がかかります。バージョン管理と相性がよいのが、テキストから図を生成するツールです。ここからは、前節で組み立てた注文処理を実際のコードに落とし、画像として書き出すところまで手を動かします。

Mermaidのコードでシーケンス図を書きGitHubのMarkdownへ埋め込む

Mermaidは、テキストの数行から図を描画するライブラリで、シーケンス図の記法は公式ドキュメントのsequenceDiagramのページにまとまっています（ドキュメント上のバージョン表記は11.17.2系、2026年9月時点）。前節のECサイトの注文処理をそのまま書くと次のようになります。

sequenceDiagram
    autonumber
    actor User as 利用者
    participant UI as 注文画面
    participant Stock as 在庫サービス
    participant Pay as 決済サービス
    User->>UI: 注文確定を押す
    UI->>+Stock: 在庫確認(商品ID, 数量)
    Stock-->>-UI: 在庫あり
    alt 在庫あり
        UI->>+Pay: 決済要求(注文ID, 金額)
        Pay-->>-UI: 決済完了
        UI-->>User: 注文完了を表示
    else 在庫不足
        UI-->>User: 在庫切れを表示
    end

読み方の対応関係は次のとおりです。participant と actor がライフラインの宣言、実線の矢印が同期メッセージ、破線の矢印が応答にあたります。矢印の末尾に付けた + と - は活性化の開始と終了を示す短縮記法で、activate と deactivate を明示的に書く形と同じ意味です。冒頭の autonumber を入れると各メッセージに連番が振られ、レビューで「3番目の呼び出し」と指し示せるようになります。alt と else の組が、そのまま複合フラグメントの枠になります。

このコードは、GitHubのMarkdown内にそのまま貼れます。GitHub公式ドキュメントによれば、言語識別子に mermaid を指定したコードフェンスで囲むだけで、Issue・Discussion・プルリクエスト・wiki・リポジトリ内のMarkdownファイルのいずれでも描画されます。書き方は以下の形です。

```mermaid
sequenceDiagram
    Alice->>Bob: 認証要求
    Bob-->>Alice: 認証応答
```

プルリクエストの説明欄に処理フローを貼っておくと、レビュアーはコードの差分と処理の順序を同じ画面で突き合わせられます。設計書を別ファイルで探しに行く手間が消えるため、レビューの往復が減る効果が実感しやすい使い方です。Mermaidの記法全般とエディタでの試し方はMermaid記法の使い方に、VSCode上で実際にシーケンス図を描く手順はVSCodeでMermaidを使ったシーケンス図の作成方法にまとめています。

mmdcコマンドでmmdファイルをSVGやPNGへ変換して配布する手順

設計書としてWordやConfluenceへ貼る場合は、画像ファイルが要ります。mermaid-cliを入れると、コマンド一行でSVGやPNG、PDFへ書き出せます。先ほどのコードを order.mmd という名前で保存し、次のコマンドを実行してください。

# インストール（グローバル）
npm install -g @mermaid-js/mermaid-cli

# mmd から SVG を生成
mmdc -i order.mmd -o order.svg

# ダークテーマ・背景透過の PNG を生成
mmdc -i order.mmd -o order.png -t dark -b transparent

環境を汚したくない場合は、インストールせずに npx -p @mermaid-js/mermaid-cli mmdc -h で起動できます。Docker版のイメージも公開されており、minlag/mermaid-cli を取得して図の置き場をボリュームマウントすれば、Node.jsを入れないマシンでも同じ出力を得られる仕組みです。CIに組み込めば、mmdファイルをコミットするたびに最新の画像が生成される状態を作れます。図の更新漏れという設計書の慢性的な問題を、仕組みで潰せる点が効きます。

PlantUMLでalt・loopと活性化まで含めた図をテキストで書き分ける

もう一つの選択肢がPlantUMLです。記法は公式のシーケンス図ドキュメントに一覧があり、活性化の明示や参加者の別名付けなど、Mermaidより細かい制御が効きます。同じ注文処理をPlantUMLで書くと次の形になります。

@startuml
autonumber
actor 利用者 as User
participant "注文画面" as UI
participant "在庫サービス" as Stock
participant "決済サービス" as Pay
User -> UI: 注文確定を押す
UI -> Stock: 在庫確認
activate Stock
Stock --> UI: 在庫あり
deactivate Stock
alt 在庫あり
  UI -> Pay: 決済要求
  activate Pay
  Pay --> UI: 決済完了
  deactivate Pay
  UI --> User: 注文完了を表示
else 在庫不足
  UI --> User: 在庫切れを表示
end
@enduml

実線の -> が同期メッセージ、破線の --> が応答という対応はMermaidと同じです。違いは activate と deactivate を独立した行として書ける点で、活性化の区間を意図どおりに制御できます。公式ドキュメントには v1.2025.5 で追加された記法の注記もあり、参加者の装飾や色分けなど表現の幅はPlantUMLのほうが広い状況です。逆にMermaidは、GitHubやNotionが標準で描画してくれるため、追加の実行環境を用意せずに済みます。チームが図をどこで読むかで選ぶのが現実的な判断でしょう。

図をコードで管理すると設計レビューで処理の差分が読めるようになる

MermaidにせよPlantUMLにせよ、テキストで持つ最大の利点は差分が読めることにあります。作図ツールのバイナリファイルは、変更点を目視で探すしかありません。テキストなら git diff に「在庫確認の後に与信チェックの呼び出しが1行増えた」と表示され、処理の変更がレビューの対象になります。設計と実装のずれを早く検知できる点が、運用上の一番の見返りです。

置き場所は、設計書フォルダではなくソースコードと同じリポジトリを推奨します。実装を変えるプルリクエストの中で図も一緒に直す流れができれば、更新漏れを構造的に防ぐ運用です。ツールに任せる前に、メッセージの種類やフラグメントの意味を理解しておくと、生成された図の善し悪しを自分で判断できます。

設計工程でシーケンス図を使う判断と、書くべきでない場面の見極め

ここからは立場を明確にします。シーケンス図は、どんな処理でも必ず描くべき図ではありません。効く場面があり、逆に描くことが手間だけを増やす状況もあります。どちらかを見極める基準を、具体的な条件で示します。

詳細設計・複雑な連携でシーケンス図が効く場面と成果物としての扱い

シーケンス図がもっとも力を発揮するのは、複数のオブジェクトやサービスが絡み合う処理を設計する場面です。マイクロサービス間の呼び出し順、外部APIや決済のような非同期を含むフロー、認証やトランザクションのように順序を間違えると事故になる処理では、流れを図で共有しておくと実装のぶれと考慮漏れを抑えられます。どのシステムから何のデータがどちらへ流れるかを俯瞰する段階にはデータ連携図を使い、その1回分の処理をシーケンス図で詳細化する、という順で分担します。工程全体のどこにシーケンス図という設計成果物が位置づくかはシステム開発の工程と7フェーズの成果物の全体像が判断の土台です。クラス図で静的な構造を固め、その構造がどう動くかをシーケンス図で詰める、という順で使い分けると、設計の抜けを互いに補えます。

シーケンス図を書かない方がよい場面と、過剰設計になりがちな失敗パターン

シーケンス図を描くべきでない場面もはっきりあります。第一に、登場人物が一つか二つで、呼び出しも一本道の単純な処理です。コードを読めば一目で分かる流れを図にしても、保守の手間が増えるだけになります。第二に、まだ処理の順序が固まっていない検討初期の段階で、無理に清書すると手戻りで描き直しになります。

ありがちな失敗は3つあります。すべてのメソッド呼び出しを漏れなく描こうとして、コードをなぞっただけの巨大で読めない図になること。ゲッターやログ出力のような些末な呼び出しまで矢印にして、本筋の流れが埋もれること。そして図を作ること自体が目的化し、実装が変わっても更新されず、実態と食い違ったまま放置されることです。三つに共通するのは、シーケンス図が処理の合意と設計判断の道具であるという原点を見失っている点にあります。全体を一枚に描き切ろうとせず、判断や合意が要る中核の流れに絞るほうが、図は長く使われます。放置が心配なら、前節のとおり図をリポジトリへ入れてコードと一緒に直す運用へ寄せてください。

受託開発で処理設計を業務要求から一貫して組み立てる体制の作り方

シーケンス図が真価を発揮するのは、業務システムや基幹システムのように、複数の処理が連携し、長く保守し続ける前提の開発です。処理の順序や同期・非同期の判断を初期に誤ると、後から負荷や障害が顕在化し、切り分けに時間がかかります。とはいえ、業務の要求を破綻しない処理フローへ落とし込むには、システム設計とドメインの理解の両方が要る仕事です。社内に設計を主導できる人材がいない、既存システムの処理連携が複雑で手を入れづらい、といった場面では、外部の伴走が歯止めになります。一創では基幹システム開発として、業務要求を処理フローやクラス構造へ整理する要件定義から、設計・実装・運用までを一貫して支援しています。図を描く技術だけでなく、変更や障害に強い処理設計を業務要求から導くところまで含めた伴走が一創の強みです。

よくある質問

シーケンス図の理解と実務でつまずきやすい点を、5つの質問に絞って整理します。

シーケンス図とクラス図の違いは何ですか？

表す対象が異なります。クラス図はシステムを構成するクラスと属性・操作・関係を表す静的な構造の図で、時間の概念を持ちません。シーケンス図はオブジェクト間のメッセージのやり取りを時間順に表す動的な振る舞いの図で、処理の順序を扱います。設計では、クラス図で部品と関係を固め、シーケンス図でその部品がどう動くかを描く、という補い合う使い方をします。同じシステムを、静止画で見るか、動画で見るかの違いに近いと考えると分かりやすいです。

同期メッセージと非同期メッセージはどう使い分けますか？

応答を待つ必要があるかで判断します。呼び出した結果を受け取ってから次へ進むなら同期（塗りつぶした矢じり）、応答を待たずに処理を続けてよいなら非同期（開いた矢じり）です。データベースへの問い合わせのように結果が必要な処理は同期、メール送信やイベント通知のように結果を待たなくてよい処理は非同期が向きます。この選択は図の見た目でなく、処理を直列にするか並行にするかという設計判断そのものなので、応答の受け取りや失敗時の扱いまで含めて決めます。

複合フラグメント（alt・opt・loop）はどんなときに使いますか？

処理に条件分岐や繰り返しがあるときに使います。altは複数の条件のどれか一つを実行するif-elseに相当し、optは条件を満たしたときだけ動くelseのない分岐、loopは反復処理を表します。並行して動く処理はparで、条件成立時に以降を打ち切る流れはbreakで囲むのが基本です。ただし深く入れ子にすると図がコードより読みにくくなるため、設計判断が要る中核の分岐だけを囲み、細部は注釈へ逃がすのが実務のコツになります。まずは正常系を描き、そこへaltで例外分岐を足す進め方がまとまりやすいです。

シーケンス図はどのツールで作成できますか？

作図に特化したツールとして、draw.io、Lucidchart、astah、PlantUMLエディタなどが挙げられます。テキストから図を生成するMermaidやPlantUMLも使え、Gitでのバージョン管理と併せて運用できる点が強みです。Mermaidで書いたファイルは mmdc -i order.mmd -o order.svg のようなコマンドでSVGやPNGへ書き出せるため、設計書への貼り込みにも困りません。処理の変更が頻繁で図を実装と同期させたい場合はMermaidやPlantUML、見た目を細かく整えたい場合はGUIの作図ツールが向きます。

シーケンス図はどこまで詳しく書くべきですか？

合意や設計判断が要る中核の流れに絞るのが基本です。すべてのメソッド呼び出しやログ出力まで描くと、コードをなぞっただけの読めない図になり、実装が変わるたびに更新できず放置されます。目安は、一つのユースケースにつき一枚、正常系と主要な例外分岐が追える粒度、複合フラグメントの入れ子は2段までと考えてください。細部はコードに任せ、図は「なぜこの順で呼ぶか」という設計意図が伝わる範囲に留めると、長く使える資料になります。