こんにちは、イノベーションセンターのNetwork Analytics for Security（NA4Sec）プロジェクトの山門です。 この記事では、2025年12月18日-19日に開催されたカンファレンスNCA Annual Conference 2025へ登壇してきた模様を紹介します。 組織におけるドメイン名の「終活（廃棄）」に伴うリスクをテーマに、利用終了ドメイン名に対する2.3億件のログ分析結果を説明しました。ECS（EDNS-Client-Subnet）を用いた分析により、「利用終了後も攻撃・スキャンが絶えない」という実態や、観測行為自体が攻撃を誘発する「観察者効果」といった興味深い知見を解説します。 NCA Annual Conferenceとは NA4Secプロジェクトとは 講演内容 ドメイン名の「終活」という課題 ECSの活用 観測・分析環境 分析結果 結論 おわりに NCA Annual Conferenceとは NCA Annual Conferenceは、一般社団法人 日本シーサート協議会が主催する年次カンファレンスです。 本イベントは、企業や組織内でセキュリティインシデントに対応するCSIRT（Computer Security Incident Response Team）のメンバーが一堂に会する、国内でも大規模なコミュニティイベントの1つです。最新のサイバー攻撃動向や技術情報の共有にとどまらず、組織の枠を超えたCSIRT間の連携や、各組織が抱える課題解決のヒントを得ることを目的として開催されています。 特に、現場の実務者による知見の共有やワークショップを通じた「共創」の精神が重視されており、日本のサイバーセキュリティ対応能力の底上げを図る重要な場として位置づけられています。 NA4Secプロジェクトとは 私の所属するNA4Secプロジェクトについて紹介させてください。 NA4Secプロジェクトは、「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指すプロジェクトです。 NTTドコモビジネスグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズからもメンバーが参画し、日夜攻撃インフラ(攻撃者の管理するマルウェアや C&Cサーバ など)を追跡しています。 講演内容 NA4Secプロジェクトの神田と、私（山門）の2名で、「『君の名は』と聞く君の名は。」というタイトルで、安易なドメイン名放棄に潜むリスク、観測から得られた知見、そして新しい管理アプローチについて講演しました。 登壇資料はこちらにアップロードしておきましたので、よろしければご覧ください。 ドメイン名の「終活」という課題 企業がかつて利用していたドメイン名を悪意を持つ第三者が取得した場合、フィッシングサイトに悪用されたり、ブランドイメージを失墜させたり、Search Engine Optimization（SEO）を悪用したりできるため、攻撃者にとって価値があります。そのためドメイン名の放棄後に第三者によって悪用される「ドロップキャッチ」のリスクが存在します。実際に「ドコモ口座」など複数事例でも問題が顕在化しています。 その対策として、当社ではドメイン名の永年保有ポリシーを策定していますが、「いつまでも持ち続ける」以外の選択肢を探るべく、利用終了ドメイン名に対する「アクセス実態」の観測と分析しています。 ECSの活用 今回発表した中では、「EDNS-Client-Subnet（ECS）」の挙動を調査しました。ECSとはRFC 7871で定義されており、DNS問い合わせにクライアントのIPサブネット情報を付加し、権威DNSサーバがユーザの地理的・ネットワーク的な位置をより正確に把握できるようにする仕組みです。DNSリゾルバの裏に存在する、実際に名前解決しようとしたクライアントのサブネットを意味します。 観測・分析環境 ログ収集環境を下図に示します。 利用終了したドメイン名宛のDNSクエリログ、Webアクセスログ、受信メール・DMARCレポートの3点をAWS上で収集およびJSON化し保管しています。今回はその中のDNSクエリログとWebアクセスログの2点に注目しています。 今回は、NA4Secプロジェクトの利用終了ドメイン名関連の施策の中で、初めてDNSクエリログとWebアクセスログを突合させることでアクセスの正体と目的の分析を試みました。DNSクエリログのECSをキーにWebアクセスログの送信元IPアドレスと突合し、DNSクエリログとWebアクセスログのタイムスタンプの差に着目しました。タイムスタンプの差が小さいと、当該ECSがWebアクセスのためにDNS名前問い合わせをした可能性が高いためです。 分析結果 以下のグラフは、各日付のDNSクエリのカウントをその日調査対象になっていたドメイン名の数で平均した値の遷移です。 以下の事柄が、分析により判明しました。 ログ分析から、利用終了後も大量のクエリが継続している 約2.3億件のDNSクエリログのうちGoogle / Cisco / Akamai など大規模DNSの resolver-ip からのクエリが9割以上を占める DNSで名前問い合わせ直後（24時間以内）に Webへアクセスしてきたものを調査した結果112リクエスト中、90件以上が攻撃またはスキャンである WordPress や Apache の既知脆弱性を狙ったアクセスが多数確認されました。Shellshock（CVE-2014-6271）、WebLogic RCE（CVE-2017-10271）、MobileIron RCE（CVE-2020-15505）、D-Link NAS のバックドア脆弱性（CVE-2024-3272）など、古い脆弱性も依然として集中的に狙われている 今回の分析から明らかになった問題の1つは、観測行為そのものがアクセスを誘発してしまうというジレンマです。 DNSレコードを返すことでサブドメイン探索が行われ、HTTP応答を返すことで脆弱性スキャンが始まるなど、観測行為が攻撃者を誘引し、その行動を変えてしまっている実情が見えてきました。 いわば「観察者効果」です。 その一方で、DNSクエリログ・Webアクセスログ単体だけではアクセスの目的や意図、アクセス元の素性を推し量ることは難しく、適切なアクションに結び付けることは困難です。 より正確に状況を把握し、利用終了ドメイン名に残存するリスクへ効果的に対応するためには、不要な「ノイズ」を除去して、本来残っているアクセスを見分けることが重要となります。 結論 これらの調査から得られた知見として下記のようにまとめられます。 DNSクエリログの一部の送信元のアクセス意図は攻撃やスキャンであることが、今回初めてDNSクエリログとWebアクセスログの2つを突合することで判明した 利用終了ドメイン名であっても攻撃・スキャンは日常的に行われる（今回の調査の対象は24年8月以前に利用終了したドメイン名） 2つのログ突合により、名前問い合わせをしてきた送信元のアクセス意図の理解が高まる（今回の調査では大半がスキャンや攻撃） おわりに 月日が経ってもアクセス数は減らず、「減少＝ドメイン名を安全に手放せる」の単純な判断材料にはならないことがわかりました。 また、現用ドメイン名にも同様の脅威が常に存在するため、サイバーハイジーン（基本的なサイバーセキュリティ対策を平時より実施すること）の徹底が不可欠だと言えます。 講演後の反応として、「同じくドメイン名の終活に悩みを抱えているが、運用・廃止ポリシーはまだ策定していない。今回の講演は、月日が経ってもアクセス数が減らない点や、曖昧な運用が悪意ある第三者によるドロップキャッチの原因になる点など、改めて組織内での運用ポリシーを策定するためのきっかけになった」というご意見もいただきました。 本カンファレンスを通じて、最新の技術動向や脅威情報を習得できたことはもちろんですが、同じ課題を持つ他社CSIRTとの「共創」のネットワークを再確認できたことが最大の収穫でした。一度取得したドメイン名の管理という地味ながらも避けては通れない課題が、いかに多くの実務者の皆さまの共通の悩みとなっているかを痛感しました。 「いつ、どうやってドメインを手放すべきか」という問いに対する最適解はまだありません。しかし、今回ご紹介したログ分析の手法や観測結果が、皆さまの組織における運用ポリシー策定の一助となれば幸いです。 NA4Secプロジェクトでは、今後もこうした観測と分析を継続し、インターネットをより安心・安全なものにするための知見を発信してまいります。 記事を最後までお読みいただきありがとうございました。

PlantUMLもClaude Codeで書きたい ども！Claude Codeで仕様書を書く方法を模索している龍ちゃんです。 以前、 ClaudeでMermaid図作成を自動化する記事 を書きました。あの記事のおかげで図解作成がめちゃくちゃ楽になったんですが、しばらく使ってるうちに壁にぶつかりました。 アクティビティ図が作れない。ユースケース図も作れない。 PlantUMLなら作れる。確認はVS Code上のMarkdown Previewで完結する。今回はその設定方法と実践例を紹介します。 Mermaidは便利だけど、対応していない図の種類があるんです。仕様書を書いてると「ここはアクティビティ図で表現したい」「アクターの関係をユースケース図で見せたい」って場面が出てきます。Mermaidのフローチャートで無理やり代用しても、分岐やマージが不自然になる。 そこで PlantUML の出番です。 今回は、Claude CodeでPlantUMLの図を生成して、VS Code上のMarkdown Previewでそのまま確認する方法を解説します。VS Code上に拡張機能を入れるだけですぐ確認できていたのですが、PlantUMLではちょっとしたコツが必要になったので紹介していきます。 この記事でわかること: Mermaidでは作れないアクティビティ図・ユースケース図・コンポーネント図をPlantUMLで作る方法 VS Code上でPlantUML図をプレビュー表示する環境設定（Markdown Preview Enhanced + Kroki.io） Claude Codeと組み合わせた実践的な作業フロー 前提環境 : VS Code 1.85以上、インターネット接続必須（Kroki.ioサーバーとの通信に必要） なぜPlantUMLなのか？ MermaidとPlantUMLの使い分け 全部PlantUMLに乗り換えろという話ではないです。Mermaidが得意な領域はMermaidを使えばいい。PlantUMLが必要になるのは、Mermaidでは作れない図を描くときだけです。 こういう図なら こっちを使う 理由 フローチャート Mermaid 記法がシンプル、学習コスト低い シーケンス図（シンプル） Mermaid 4参加者程度ならMermaidで十分 状態遷移図 Mermaid stateDiagram-v2が使いやすい ER図 Mermaid erDiagramが直感的 パイチャート Mermaid Mermaid専用機能 アクティビティ図 PlantUML Mermaid非対応。if/else分岐の自然な表現 ユースケース図 PlantUML Mermaid非対応。UML標準のアクター記法 コンポーネント図 PlantUML database/queue専用記号が使える 複雑なシーケンス図 PlantUML ==フェーズ分割==、ref over が使える UML準拠が求められる設計書 PlantUML UML 2.0標準に準拠 シンプルな結論: 迷ったらMermaid。アクティビティ図・ユースケース図・コンポーネント図の3パターンだけPlantUML。 PlantUML固有の強み PlantUMLでしか使えない表現がいくつかあります。記事の後半で実際に使いますが、先に紹介しておきます。 database "名前" — ドラム型のデータベース記号。Mermaidでは汎用の四角になる queue "名前" — キュー型の記号。メッセージキューの表現に最適 == フェーズ名 == — シーケンス図をフェーズで区切る。認証→データ取得のような段階を明示できる left to right direction — ユースケース図の横向きレイアウト。縦長にならず収まりがいい if/else/endif — アクティビティ図の条件分岐。ネストも可能 VS Code Preview設定方法 ここが記事の核です。一度設定すれば、あとはMarkdownに書くだけでPlantUML図がプレビュー表示されます。 必要な拡張機能 Markdown Preview Enhanced を使います。 項目 詳細 拡張機能ID shd101wyy.markdown-preview-enhanced バージョン 0.8.20（2025年11月時点） PlantUML対応 Kroki.ioサーバー経由で描画 Mermaid対応 ブラウザ内JSで描画（同時対応） VS Code標準のMarkdownプレビューではPlantUMLは表示されません。Markdown Preview Enhancedの専用プレビューを使う必要があります。 PlantUMLサーバー設定 PlantUMLのコードを画像に変換するサーバーが必要です。 Kroki.io を使います。無料で登録不要です。 注意 : Kroki.ioはパブリックサーバーなので、PlantUMLのコードがインターネット経由で送信されます。社内の機密情報を含む図を描く場合は、 セルフホスト版のKrokiサーバー （Dockerで立てられる）を検討してください。個人のブログ執筆用途であれば問題ないです。 VS Codeの設定で以下を追加します: { "markdown-preview-enhanced.plantumlServer": "https://kroki.io/plantuml/svg/" } これだけです。 devcontainer.jsonへの設定例 devcontainerを使っている場合は、 devcontainer.json に書いておくとチーム全員が同じ設定で使えます。 { "customizations": { "vscode": { "extensions": [ "shd101wyy.markdown-preview-enhanced", "bierner.markdown-mermaid" ], "settings": { "markdown-preview-enhanced.plantumlServer": "https://kroki.io/plantuml/svg/", "markdown-preview-enhanced.previewTheme": "github-dark.css", "markdown-preview-enhanced.mermaidTheme": "dark" } } } } 自分のプロジェクトでは実際にこの設定を使っています。 Markdown Preview Mermaid Support （ bierner.markdown-mermaid ）も入れておくと、VS Code標準プレビュー側でMermaidが表示できて便利です。 動作確認 設定が終わったら、以下の手順で確認します。 以下のコードブロックを書く: Markdown Preview Enhanced のプレビューを開く コマンドパレット（Ctrl+Shift+P）→ Markdown Preview Enhanced: Open Preview to the Side ショートカット: Ctrl+K V Markdownファイルを開く @startuml Alice -> Bob: Hello Bob --> Alice: Hi! @enduml プレビューにシーケンス図が表示されたら設定完了です。表示されない場合は、後述のトラブルシューティングを確認してください。 注意 : VS Code標準のMarkdownプレビュー（Ctrl+Shift+V）ではPlantUMLは表示されません。必ずMarkdown Preview Enhanced のプレビューを使ってください。アイコンが異なるので区別できます。 基本的な作業フロー Claude Code連携の流れ Claude Codeで作業する場合の具体的な流れです。 Markdownファイルを開いた状態でClaude Codeにプロンプトを入力 Claude Codeが plantuml コードブロックを含むMarkdownを生成 VS Code上でMarkdown Preview Enhancedのプレビューを確認 修正が必要なら「この図の〇〇を変更して」と追加指示 完成したらそのまま仕様書・設計書として使える エディタとターミナルの行き来だけで完結するのが強みです。 PlantUML公式エディタで確認する方法 VS Code Previewが本記事のメインですが、ブラウザで手軽に確認したい場面もあります。PlantUMLには公式のWebエディタがあるので紹介しておきます。 PlantUML Web Editor 使い方はシンプルです。 上記URLにアクセス 左側のエディタにPlantUMLコードを貼り付ける 約1.5秒後に右側にプレビューが自動表示される ツールバーからPNG/SVGでダウンロードできる Mermaid版の記事で紹介した「Live Editor」のPlantUML版だと思ってください。URLがそのまま図の共有リンクになるので、チームメンバーに「この図見て」と送るときにも使えます。 ただし自分は普段使いではVS Code Previewのほうを使っています。理由は2つあって、エディタから離れなくていいことと、Markdownファイルにそのまま残せること。公式エディタは「VS Codeの設定がまだの環境で急ぎ確認したい」「誰かに図だけ共有したい」ときの補助ツールという位置づけです。 実践①: アクティビティ図 アクティビティ図とは ワークフローや処理の分岐を表現する図です。フローチャートに似ていますが、UMLの正式な図の1つで、条件分岐（if/else）とマージの表現が自然です。 Mermaidのフローチャートでも似たことはできますが、分岐とマージの接続が不自然になりがちです。PlantUMLのアクティビティ図なら、if/else/endifの構文でネストした分岐も綺麗に描けます。 プロンプト例 以下のワークフローをPlantUMLのアクティビティ図で作成してください。 【ワークフロー】ブログ記事の執筆〜公開プロセス 1. 記事のアウトラインを作成 2. Claude Codeで下書きを生成 3. 内容を確認・修正 4. 判定: 技術的に正確か？ - YES → ライティングチェックへ - NO → 技術検証をやり直して下書き修正 5. 判定: 品質OK？ - YES → サムネイル作成 → WordPress入稿 → 公開 - NO → AIっぽい表現を修正 → 再チェック ```plantuml のコードブロック形式で出力してください。 PlantUMLコード例 @startuml start :記事のアウトラインを作成; :Claude Codeで下書きを生成; :内容を確認・修正; if (技術的に正確？) then (はい) :ライティングチェック; if (品質OK？) then (はい) :サムネイル作成; :WordPressに入稿; :公開; else (いいえ) :AIっぽい表現を修正; :再チェック; endif else (いいえ) :技術検証をやり直す; :下書きを修正; endif stop @enduml VS Code Previewで見ると、こんな感じで表示されます。 分岐のダイヤモンド記号とマージが自然に接続されます。ネストしたif/elseもインデントで表現されるので読みやすい。Mermaidのフローチャートで同じことをやろうとすると、ノード間の矢印を手動で繋ぐ必要があって面倒です。 実践②: ユースケース図 ユースケース図とは システムの機能（ユースケース）と、それを使う人やシステム（アクター）の関係を表現する図です。要件定義の初期段階で「誰が何をするか」を整理するのに使います。 Mermaidにはユースケース図のサポートがないので、PlantUMLの独壇場です。 プロンプト例 以下のシステムのユースケース図をPlantUMLで作成してください。 【システム名】ブログ執筆システム 【アクター】 - エンジニア: 記事執筆、図の生成、コードレビュー - Claude Code: 下書き生成、図の生成、サムネイル作成、SEOチェック、ライティングチェック - レビュアー: コードレビュー 【関係】 - 図の生成と記事執筆にはinclude関係がある - SEOチェックと記事執筆にもinclude関係がある left to right direction で横向きレイアウトにしてください。 ```plantuml のコードブロック形式で出力してください。 PlantUMLコード例 @startuml left to right direction actor "エンジニア" as Engineer actor "Claude Code" as Claude actor "レビュアー" as Reviewer rectangle "ブログ執筆システム" { usecase "記事を執筆" as UC1 usecase "図を生成" as UC2 usecase "コードレビュー" as UC3 usecase "サムネイル作成" as UC4 usecase "SEOチェック" as UC5 usecase "ライティングチェック" as UC6 } Engineer --> UC1 Engineer --> UC2 Engineer --> UC3 Claude --> UC1 : 下書き生成 Claude --> UC2 : Mermaid/PlantUML生成 Claude --> UC4 Claude --> UC5 Claude --> UC6 Reviewer --> UC3 UC2 ..> UC1 : <<include>> UC5 ..> UC1 : <<include>> @enduml VS Code Previewでの表示結果がこちらです。 left to right direction でアクターが左右に配置されて、横長のレイアウトになります。 rectangle でシステム境界を囲って、 ..> + <<include>> でユースケース間の依存関係を表現しています。 棒人間のアクターアイコンはPlantUML固有のもので、UML標準に準拠しています。Mermaidでは表現できません。個人的にはこのアクターアイコンが出るだけで「ちゃんとした設計図」感が出るので気に入ってます。 実践③: コンポーネント図 コンポーネント図とは システムのコンポーネント（サービス、データベース、キューなど）と、それらの依存関係を表現する図です。PlantUMLの database と queue の専用記号が使えるのがここで効いてきます。 Mermaidでもflowchartでシステム構成図を描けますが、データベースもキューも同じ四角形になります。PlantUMLならドラム型のDB記号やキュー記号で一目でわかる図が作れます。 プロンプト例 以下のシステム構成をPlantUMLのコンポーネント図で作成してください。 【システム名】ブログ執筆環境 【レイヤー構成】 - 開発環境: VS Code、Claude Code CLI、Playwright - CLIツール: blog-scraper、html-to-png、svg-to-png、thumbnail-generator - 外部サービス: WordPress（DB）、Kroki.io（キュー）、GitHub（DB） database記号とqueue記号を使い分けてください。 packageでレイヤーを分けてください。 ```plantuml のコードブロック形式で出力してください。 PlantUMLコード例 @startuml package "開発環境（devcontainer）" { [VS Code] as VSCode [Claude Code CLI] as Claude [Playwright] as PW } package "CLIツール" { [blog-scraper] as Scraper [html-to-png] as H2P [svg-to-png] as S2P [thumbnail-generator] as Thumb } package "外部サービス" { database "WordPress" as WP queue "Kroki.io" as Kroki database "GitHub" as GH } VSCode --> Claude : コマンド実行 Claude --> Scraper : 記事取得 Claude --> H2P : 図のPNG変換 Claude --> Thumb : サムネイル生成 Scraper --> WP : スクレイピング H2P --> PW : ブラウザ描画 VSCode --> Kroki : PlantUMLプレビュー Claude --> GH : コミット・プッシュ @enduml VS Code Previewで表示するとこうなります。 WordPressとGitHubがドラム型のDB記号で、Kroki.ioがキュー型の記号で表示されます。 package でレイヤーが囲まれるので、3層構造が一目でわかります。 [コンポーネント名] の記法はUMLコンポーネント記号（角に突起が付いた四角形）で表示されます。Mermaidの ["テキスト"] とは見た目が違って、設計図っぽさが出ます。実はこの図、自分が普段使ってるブログ執筆環境そのものなので、「こういう構成で動いてるんだ」と思いながら見てもらえると嬉しいです。 トラブルシューティング Previewに図が表示されない 症状 原因 対策 コードブロックがそのまま表示される VS Code標準のMarkdownプレビューを使っている Markdown Preview Enhanced のプレビューに切り替える。コマンドパレットで「Markdown Preview Enhanced: Open Preview to the Side」を実行 「Loading…」で止まる Kroki.ioサーバーに接続できない ネットワーク接続を確認。プロキシ環境の場合はVS Codeのプロキシ設定を確認 図が真っ白 plantumlServer の設定値が間違っている 設定値が https://kroki.io/plantuml/svg/ になっているか確認（末尾のスラッシュも必要） エラーメッセージが表示される PlantUMLの構文エラー エラーメッセージをClaude Codeに貼り付けて「修正してください」と依頼 日本語が文字化けする Kroki.ioサーバー側で描画されるため、ローカルのフォント設定は影響しません。Kroki.ioは日本語フォントに対応しているので、通常は文字化けしないです。 もし文字化けする場合は、skinparamでフォントを指定してみてください: @startuml skinparam defaultFontName "Noto Sans JP" ' 以下に図の内容 @enduml 図が大きすぎてプレビューに収まらない 2つの方法があります。 方法1: scaleで縮小 @startuml scale 0.8 ' 80%に縮小して表示 @enduml 方法2: skinparam dpiで調整 @startuml skinparam dpi 150 ' デフォルト（200程度）より小さくする @enduml ノード数が多い場合は、図を分割するのが根本的な解決策です。 プロンプトテンプレート集 コピペして使えるテンプレートです。 アクティビティ図用 以下のワークフローをPlantUMLのアクティビティ図で作成してください。 【ワークフロー名】 [ワークフローの名前] 【ステップ】 1. [ステップ1の内容] 2. [ステップ2の内容] 3. 判定: [条件分岐の内容] - YES → [処理A] - NO → [処理B] ```plantuml のコードブロックで出力してください。 skinparamは不要です。 ユースケース図用 以下のユースケース図をPlantUMLで作成してください。 【システム名】 [システムの名前] 【アクター】 - [アクター1]: [役割の説明] - [アクター2]: [役割の説明] 【ユースケース】 - [UC1]: [機能の説明] - [UC2]: [機能の説明] 【関係】 - [UC間のinclude/extend関係があれば記述] left to right direction で横向きレイアウトにしてください。 ```plantuml のコードブロックで出力してください。 コンポーネント図用 以下のシステム構成をPlantUMLのコンポーネント図で作成してください。 【システム名】 [システムの名前] 【レイヤー構成】 - [レイヤー1]: [コンポーネント一覧] - [レイヤー2]: [コンポーネント一覧] - [データ層]: [DB、キャッシュ、キュー等] database記号とqueue記号を適切に使い分けてください。 packageでレイヤーを分けてください。 ```plantuml のコードブロックで出力してください。 修正依頼用 先ほどのPlantUML図を以下の点で修正してください: 【修正内容】 - [修正点1] - [修正点2] - [修正点3] ```plantuml のコードブロック形式を維持してください。 まとめ Mermaidで作れない図はPlantUMLで作る。確認はVS Code上のMarkdown Previewで完結する。 この記事のポイント: 使い分け : 迷ったらMermaid。アクティビティ図・ユースケース図・コンポーネント図の3パターンだけPlantUML 環境設定 : Markdown Preview Enhanced + Kroki.ioサーバー。devcontainer.jsonに数行設定するだけ 作業フロー : Claude Code → PlantUMLコード生成 → VS Code Preview確認。エディタから離れない PlantUML固有の強み : database/queue専用記号、if/else分岐、ユースケースのアクター記法 Mermaid版の記事では「Live Editorでブラウザに切り替えて確認」でしたが、PlantUML版は「VS Codeのプレビューで確認」です。エディタとターミナルの行き来だけで図の作成が完結するのは地味に楽です。仕様書のMarkdownにそのまま埋め込めるので、図の管理も別ファイルにする必要がありません。 自分はこの仕組みを使って、仕様書や設計書の図解を全部Markdownに集約しています。 ほなまた。 関連ブログ・参考リンク 関連ブログ ClaudeでMermaid図作成を自動化！2時間→5分の劇的時短術 今回の記事の前編にあたる記事です。Mermaidでフローチャート・シーケンス図・パイチャートを自動生成する方法と、Live Editorでの確認フローを紹介しています。Mermaid側の使い方はこちらを参照してください。 図解作成、AIに丸投げしたら「たまに自分より上手い」件 Claude CodeのSKILL機能でHTML図解を自動生成し、CLIでPNG変換する方法を紹介しています。気に入ったデザインをreferenceに保存するだけでスキルが育つ仕組みも解説。図解の品質を上げたい人はこちらもどうぞ。 参考リンク PlantUML公式 Kroki.io — Diagram as Code Markdown Preview Enhanced Mermaid.js公式 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeで仕様書のPlantUML図を自動生成 — VS Codeプレビューで完結 first appeared on SIOS Tech Lab .

こんにちは。ファインディのPlatform開発チームでSREを担当している 大矢 です。 2026年はファインディのSREについて1ヶ月に1本ペースで発信していきます。今回はその第1弾として、ファインディにおけるSREの体制についてご紹介します。 この記事では、SREチーム(現在のPlatform開発チーム)がどのように発足し、現在どのような体制で運用しているのかをお伝えします。SREに興味がある方、特にこれからSREを目指す方に読んでいただけますと幸いです。 目次 目次 はじめに Platform開発チームのSREとEmbedded SREの役割分担 Platform開発チームのSREとは Embedded SREとは 役割の違い SREチームの発足まで SREがいなかった時期（〜2023年8月） 1人目SRE入社後（2023年9月〜2024年3月） SREチーム発足後（2024年4月〜） チームの変化 2024年 2025年 2026年以降 まとめ はじめに 2026年1月現在、ファインディでは「Platform開発チーム」が全社横断のSREの役割を担っています。 このチームは、ファインディが提供する複数のプロダクトに対して横断的に信頼性を向上させ、開発チームが事業成長に関わる開発に集中できるような仕組みを構築・提供することを目指しています。 現在は5名のSREメンバーで構成されており、各プロダクトの開発チームと連携しながら、環境の整備や運用改善、ファインディ全社へのSREのイネーブリングに取り組んでいます。 Platform開発チームのSREとEmbedded SREの役割分担 ファインディのSRE体制には、「Platform開発チームのSRE」と「Embedded SRE」という2つの役割があります。 Platform開発チームのSREとは ファインディで単に「SREチーム」といった場合、SREメンバーが所属するPlatform開発チームを指します。私たちはこのチームに所属しています。 私たちのチームではSREとPlatform Engineeringを推進しており、弊社内では「横断SRE」や「Platform SRE」と呼ばれることもあります。 私たちは「SREの文化を組織全体に根付かせ、開発チームが自律的にSREを実践できるように支援する」というビジョンを掲げています。このビジョンについては別の機会に詳しく紹介したいと思います。 なお、ローンチから日が浅いプロダクトなど、プロジェクト規模が比較的小さいプロダクトには後述のEmbedded SREが在籍していないため、Platform開発チーム/SREがプロダクト固有のタスクも含めて対応しています。 Embedded SREとは Platform開発チームのSREメンバーとは別に、各プロダクトの開発チームには「Embedded SRE」と呼ばれるメンバーが在籍しています。 Embedded SREは、SREチーム発足前から各プロダクトの開発チーム内でSRE的な立ち回りをしていたメンバーです。Platform開発チーム発足後の現在でも、プロダクトに特化したタスクについては引き続き担当しています。 役割の違い Platform開発チームのSRE : プロダクト横断的な信頼性向上、共通基盤の整備 Embedded SRE : 特定プロダクトに特化した信頼性向上、プロダクト固有の課題対応 この2つの役割が連携することで、全社的な視点とプロダクト固有の視点の両方から、信頼性の向上に取り組んでいます。 SREチームの発足まで SREがいなかった時期（〜2023年8月） 実は、ファインディには2023年9月までSREは1人も在籍していませんでした。各プロダクトの開発チーム内で、クラウドやインフラに詳しいメンバーがSRE的な役割を担っていました。 プロダクト開発をメインにしながら、障害対応やインフラの改善も同時に行うという状況が続いていました。 サービスが成長するにつれて、信頼性向上やクラウド・インフラの整備がより重要になり、専門的に取り組む必要性が高まっていきました。 1人目SRE入社後（2023年9月〜2024年3月） 2023年9月、ファインディに1人目のSREが入社しました。ただし、最初はチームではなく「1人SRE」としての活動でした。 この時期は、ファインディの新規サービスの立ち上げのための環境構築や、それまで実現したくても手の付けられなかった課題に対応していきました。 SREチーム発足後（2024年4月〜） 2024年4月、2人目のSREメンバーが加わり、正式に「SREチーム」が発足しました。1人から2人になったことで、チームとしての活動が本格的にスタートしました。 その後、メンバーが徐々に増え、2026年1月現在では5人体制となっています。組織の成長に伴い、チーム名も「Platform開発チーム」に変更されました。 チームの変化 2024年 チーム発足時からしばらくの間、SREチームはマネジメント経験のあるシニアメンバーのみで構成されていました。当時はチームマネジメントは必要最小限にとどめ、マネージャーもプレイングマネージャーとしてメンバーと同等のタスクを担当していました。 タスク管理には「かんばん」を利用し、各自で優先順位付けとチーム内外の合意、タスクのクローズまでおこなっていました。 また、この年の12月にSREチーム初のジュニアメンバーがチームにジョインしました。 2025年 2025年は、ファインディがAI関連の新プロダクトを中心に多くのリリースをおこなった年でした。新プロダクトのリリースに伴い、SREチームには環境構築やインフラ整備の依頼が集中しました。 この状況に対応するため、構築作業の短縮化とトイルの削減が急務となりました。具体的には、新環境を3日で提供できるようTerraformのモジュールを汎用化し、Terraform Testの導入による環境構築の信頼性向上も実現しました。 tech.findy.co.jp tech.findy.co.jp そしてDevinを使ったユーザー管理業務の自動化など、さまざまな効率化施策に取り組みました。 tech.findy.co.jp その他、WordPressのShifter移行やFlatt Security様提供のTakumi導入など、セキュリティ強化にも注力しました。 tech.findy.co.jp tech.findy.co.jp この年にもジュニアメンバーが増え、チームの育成やナレッジ共有の重要性も高まりました。 ファインディでは2026年もより多くの成長を目指しており、チームとしての立ち回りの変化も求められています。 2026年以降 2026年1月現在、Platform開発チームはシニア2名、ジュニア3名の5人体制で運用されています。 チーム運営の面では、これまでの「かんばん」でトイルや細かなタスク管理をおこない、構築や1ヶ月以上かかるタスクはロードマップを引くようになり、中期的な視点でSRE活動を計画できるようになりました。 2026年度も引き続きプロダクトが増え続ける見込みです。 現在の体制でファインディの全てのプロダクトを見ていくことは難しくなるため、環境構築やプロダクトのクラウド運用を開発チーム主体でおこなえるよう、ファインディ全体へのSRE文化の浸透を推進します。 新規プロダクト立ち上げ時や環境追加時には、開発チームの担当メンバーに主導していただき、Platform開発チームはサポート役として次のような支援をおこないます。 簡単に新規環境を構築するための仕組みの提供（汎用Terraformモジュール、環境構築のClaude CodeのPlugin） 構築・運用のレクチャー これらの施策により、SREが環境構築を直接おこなうのではなく、開発チームが自律的に構築・運用できるような仕組み作りとイネーブリングに注力していきます。 まとめ ファインディのSREは、2023年9月の1人目入社から始まり、約2年半で5人体制のPlatform開発チームへと成長してきました。 Platform開発チーム/SREとEmbedded SREが連携することで、全社的な視点とプロダクト固有の視点の両方から信頼性向上に取り組んでいます。まだまだ発展途上のチームですが、これからもファインディのサービス成長を支えるべく、日々改善を続けています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers