AIにシーケンス図・構成図を書かせる｜PlantUMLで起こす型
「この処理、AがBに投げて、Bが認証確認してからCに保存して……」 頭の中では流れがちゃんと見えているのに、いざ図にしようとすると、作図ツールで箱を置いて、線を引いて、微妙にずれた矢印を直して——そこで気力が尽きて、図はいつも後回し。結局、口頭とテキストで説明して、レビューのたびに認識がずれる。そんな経験、ありますよね。
そんなとき、「図くらいAIに起こしてもらえないか」と考えるのは自然なことです。 実際、頭の中の流れを図の形に整えるのは、AIが得意な作業です。しかもコツがひとつあって、いきなり画像を描かせるのではなく、PlantUML というテキストで図を書かせると、格段に扱いやすくなります。テキストなので直しやすく、差分が見え、そのままリポジトリに置いてバージョン管理もできます。
ただ、ここには落とし穴があります。 AIは、あなたが渡していない矢印や順序を、それらしく足したり入れ替えたりすることがあります。見た目がきれいな図ほど「合っている」と錯覚しやすく、実装や仕様と食い違った図が独り歩きするのがいちばん怖い事故です。
結論：AIに任せていいのは、①箇条書き→PlantUMLテキストへの変換（図の下書き化）②記法・レイアウトの整え ③分岐やエラー系など抜けがちな観点の洗い出しまで。人が必ず確認するのは、①登場人物（誰が・何が）が実際と合っているか ②呼び出しの順序と戻りが正しいか ③分岐・エラー時の線が漏れていないか。AIは「下書きを起こす作図係」、人は「実装と照らして直す監督」。出てきた図は、確認が済むまですべて仮として扱う。この一線さえ守れば、後回しにしていた図が、今日ひとつ形になります。
図が描けないのは、あなたの段取りが悪いからではありません。 頭の中の流れを、記法を思い出しながら手で線に落とすのは、そもそも脳への負荷が高い二重作業です。だから「気合いで作図する」の前に、流れは箇条書きで出し切って、図の形はAIに起こしてもらう。今日はその進め方を、コピーして使えるプロンプトと一緒に整理していきます。
なぜ「画像」ではなく「PlantUMLのテキスト」で書かせるのか
AIに「シーケンス図の画像を作って」と頼むと、一見それっぽい絵は返ってきます。 でも画像は、直せません。矢印を一本足したい、順序を入れ替えたい、名前を変えたい——そのたびに作り直しになり、しかも前とどこが変わったのか分かりません。
PlantUMLのようなテキストで書かせると、この弱点が全部ひっくり返ります。
- 直せる：一行足す・消すだけで図が変わる。ツールで線を引き直さなくていい。
- 差分が見える：
git diffで「どの矢印を足したか」が読める。レビューできる。 - 残せる：
.pumlファイルとしてリポジトリに置けば、仕様と一緒に更新していける。図だけ古くなる問題が減る。
つまりAIには「絵」ではなく「図の設計図」を書かせる。 レンダリング（テキストから画像を起こすこと）は PlantUML公式 や各エディタのプラグイン、社内のドキュメントツールに任せればいい。ここを分けて考えるのが、扱いやすさの分かれ目です。
手順を小さく分ける
一度に完璧な図を狙わず、次の順で進めます。
1. 何の図を描きたいかを一言で決める
まず種類を決めます。よく使うのはこの2つです。
- シーケンス図：登場人物のあいだで、時間の流れに沿って「誰が誰を呼ぶか」を描く。処理の流れ・API連携・ログイン手順などに向く。
- 構成図（コンポーネント図）：システムの部品と、その間のつながりを描く。「どのサービスがどのDBを見るか」といった静的な関係に向く。
「動きの順番を見せたい」ならシーケンス図、「全体の配置を見せたい」なら構成図、と分けると迷いません。
2. 登場人物と流れを、箇条書きで出し切る
ここがいちばん大事な工程で、AIではなくあなたがやります。 図の中身（誰が・何を・どの順で）はあなたしか知らないからです。難しく書かなくて大丈夫です。
- 登場人物：ユーザー、Webアプリ、認証サービス、DB
- 流れ：
1. ユーザーがログインボタンを押す
2. WebアプリがIDとパスワードを認証サービスに送る
3. 認証サービスがDBに照合する
4. 一致したらトークンを返す、しなければエラーを返す
5. Webアプリが結果をユーザーに表示するこの箇条書きが、そのまま図の骨になります。
3. AIにPlantUMLへの変換を頼む
出し切った箇条書きを渡して、テキスト化だけを頼みます。
次の流れをPlantUMLのシーケンス図にしてください。
・登場人物と呼び出しの順序は、下の箇条書きのとおりに忠実に再現する
・箇条書きにない矢印・処理・登場人物は足さない
・成功/失敗の分岐はaltを使って描く
・不明な点は勝手に埋めず、'（要確認）とコメントで残す
【流れ】（ここに2で作った箇条書きを貼る）
ポイントは「足さない」「勝手に埋めない」を明記すること。ここを言わないと、AIは親切心でそれらしい線を補ってきます。
4. レンダリングして、箇条書きと見比べる
出てきたPlantUMLを実際にレンダリングして、2で作った箇条書きと一本ずつ突き合わせます。 「登場人物は合っているか」「矢印の向きと順番は合っているか」「戻り（返す線）はあるか」。図を眺めるのではなく、自分の箇条書きを正として照合するのがコツです。
5. ズレていた所だけ、テキストを直す
違っていたら、AIに直させるか、自分でその行を書き換えます。 テキストなので、直すのは一瞬です。分岐やエラー時の線が抜けていたら、そこだけ足します。ここまで来れば、図はもうあなたの理解と一致した「使える図」になっています。
コピーして使えるプロンプト
シーケンス図（処理の流れ・API連携）
下の箇条書きの流れを、PlantUMLのシーケンス図にしてください。登場人物・順序・戻りは箇条書きに忠実にし、書かれていない要素は足さないでください。成功と失敗は alt で分けてください。（箇条書きを貼る）
構成図（システムの部品と関係）
下の構成を、PlantUMLのコンポーネント図にしてください。部品と、その間の依存の向きだけを描き、書かれていないつながりは足さないでください。外部サービスは色を分けてください。（構成の箇条書きを貼る）
既存の図やコードから起こしたいとき
このコード（またはメモ）の呼び出しの流れを読み取って、PlantUMLのシーケンス図にしてください。読み取れなかった部分は矢印を足さず、'（コードから読み取れず） とコメントで残してください。
最後の「読み取れなかった部分は足さない」は特に効きます。既存コードから起こすときほど、AIは推測で矢印を補いがちだからです。この読み解き自体を深めたいときは、AIにレガシーコードの仕様を読み解かせる進め方も合わせて使えます。
鵜呑みにしない——ここだけは人が見る
図がきれいだと、つい「合っている」と思ってしまいます。 でも、確認するのは見た目ではなく中身です。よくあるズレはこの3つです。
- いない登場人物・ない矢印が足されている：あなたが渡していない「キャッシュ」「ログ」などを、AIが気を利かせて足すことがあります。実際にその処理があるか確認します。
- 順序や向きが入れ替わっている：「AがBを呼ぶ」が「BがAを呼ぶ」になっていたり、戻りの線が抜けていたり。時間の前後は、箇条書きと照らして必ず見ます。
- 分岐・エラー系が省かれている：成功パターンだけ描かれ、失敗・タイムアウト・権限なしの線が消えていることがあります。図で語られない分岐は、実装でも忘れられがちです。
これらはハルシネーション（もっともらしい誤り）が図の形で出たものです。文章より気づきにくいぶん、箇条書きという「正」を手元に置いて突き合わせるのが、いちばん確実な歯止めになります。図をチームで共有する前に、AIの生成物のレビュー・検証チェックリストと同じ姿勢で、一度この目を通しておくと安心です。
チェックリスト
図をチームに共有したり、仕様書に貼ったりする前に、ここだけ確認します。
渡す前（自分の準備）
- 描きたいのはシーケンス図か構成図か、決めたか
- 登場人物と流れを、自分の言葉で箇条書きにしたか
- プロンプトに「書かれていない要素は足さない」と明記したか
出てきた図を見るとき
- 登場人物が、箇条書きと同じか（増えていないか）
- 呼び出しの順序と向きが、箇条書きどおりか
- 戻り（返す線）が描かれているか
- 成功だけでなく、失敗・エラー時の分岐が描かれているか
- AIが推測で埋めた箇所に、印やコメントが残っているか
残すとき
- PlantUMLのテキストを
.pumlなどで保存し、後から直せる形にしたか - この図が実装と合っていると、自分の言葉で言えるか
最後に
図が後回しになるのは、あなたが図を軽視しているからではありません。 頭の中の流れを、記法を思い出しながら線に落とす——その二重作業が、単に重かっただけです。
流れを箇条書きで出すところまでは、もうあなたの中にあります。 そこから先の「テキストに起こす」をAIに任せて、人は「合っているか見比べる」に集中する。役割を分ければ、いつも後回しだった図が、今日ひとつ形になります。
一度で完璧な図を目指さなくて大丈夫です。まず一枚、箇条書きから起こしてみる。それだけで、次のレビューでの認識のずれが、少し減ります。
