<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Drawio on ROBOCO</title>
    <link>https://roboco.io/ja/tags/drawio/</link>
    <description>Recent content in Drawio on ROBOCO</description>
    <generator>Hugo</generator>
    <language>ja</language>
    <lastBuildDate>Sat, 14 Jun 2025 12:35:06 +0900</lastBuildDate>
    <atom:link href="https://roboco.io/ja/tags/drawio/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AIでアーキテクチャ図を描く</title>
      <link>https://roboco.io/ja/posts/how-to-draw-diagram/</link>
      <pubDate>Sat, 14 Jun 2025 12:35:06 +0900</pubDate>
      <guid>https://roboco.io/ja/posts/how-to-draw-diagram/</guid>
      <description>&lt;figure&gt;&lt;img src=&#34;https://roboco.io/posts/images/Dohyun.png&#34;&gt;&lt;figcaption&gt;&#xA;      &lt;h4&gt;チョン・ドヒョン - ROBOCO首席コンサルタント&lt;/h4&gt;&#xA;    &lt;/figcaption&gt;&#xA;&lt;/figure&gt;&#xA;&#xA;&lt;p&gt;バイブコーディングをするとき、人はしばしばコードさえあれば十分だと考えがちです。しかし現実は違います。文書化のないコードは、地図を持たずに出かける旅のようなものです。目的地がどこなのか、道のりがどうなっているのかが分からなければ、誰も一緒に来てはくれません。バイブコーディングにおいて文書化が特に重要なのは、コードが単に動作するためのものではなく、アイデアと設計の意図を他の人に正確に共有するためのものだからです。文書化は協働を滑らかにし、プロジェクトの方向性を明確にし、ひいては持続可能な開発環境を築く土台になります。&lt;/p&gt;&#xA;&lt;p&gt;私は文書化の作業をコードと一緒に管理する方式を強くおすすめします。特にMarkdownとmermaidを使えば、シンプルで明確な図をすばやく作成できます。複雑な構造や流れを長い言葉の代わりに図ひとつで表せるので、意思疎通がはるかに効果的になります。&lt;/p&gt;&#xA;&lt;p&gt;もちろん、mermaidだけでは足りないこともあります。より精緻で複雑な図が必要なときは、draw.ioを使うことができます。draw.ioはXMLベースの.drawioというファイル形式を使うため、AIにこの形式で図を生成するよう指示すれば比較的簡単に作業できます。ただし、AWSアイコンのような特定のアイコンのIDは公開されていないので、AIがそのまま活用するのは容易ではありません。&lt;/p&gt;&#xA;&lt;p&gt;そこで私は、draw.ioクライアントからAWSアーキテクチャアイコンのIDを直接抽出し、別途&lt;a href=&#34;https://github.com/Hands-On-Vibe-Coding/ecs-fargate-fast-scaleout/blob/main/docs/aws-2025-icons-drawio.md&#34;&gt;文書化&lt;/a&gt;しました。これによってAIにアイコンIDを教え、望むアイコンを正確に活用できるようにしたわけです。この文書は、次のGitHubリポジトリで実際に作業した例を通して確認できます。&lt;/p&gt;&#xA;&lt;h2 id=&#34;tldr&#34;&gt;TL;DR&lt;/h2&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;バイブコーディングにおいて文書化は選択肢ではなく、設計意図と協働の文脈を共有するための中核的な作業です。&lt;/li&gt;&#xA;&lt;li&gt;単純な構造ならMarkdownとmermaidで十分ですが、より精緻なアーキテクチャ図はdraw.ioファイルをAIと一緒に生成できます。&lt;/li&gt;&#xA;&lt;li&gt;AWSアイコンのようにAIが知りにくい細かなIDは、別文書として与えれば望みどおりの図をより正確に作れます。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://github.com/Hands-On-Vibe-Coding/ecs-fargate-fast-scaleout/&#34;&gt;ECS - Fargate Fast Scaleout&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;このようにして生成された図は、VS Codeのdrawio関連の拡張機能を使えば手軽にプレビューしたり修正したりできます。また、draw.ioクライアントをインストールすると一緒に提供されるCLIツールで、簡単にSVGやPNG形式の画像に変換して文書へ挿入することもできます。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://raw.githubusercontent.com/Hands-On-Vibe-Coding/ecs-fargate-fast-scaleout/abbb4dee4d89070692fc4edc0e81a313c910c52b/docs/diagrams/architecture.svg&#34; alt=&#34;alt text&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;一方で、最近のmermaidの最新バージョンでは、AWSアイコンをはじめとするさまざまなアーキテクチャアイコンが標準でサポートされ始めました。&lt;a href=&#34;https://mermaid.js.org/syntax/architecture.html&#34;&gt;公式ドキュメント&lt;/a&gt;を参照すればすぐに活用できます。ただし、GitHubではまだこの最新機能がサポートされていないため、先ほど説明した方法が当面は最も有用なアプローチになるでしょう。&lt;/p&gt;&#xA;&lt;p&gt;良い文書は単なる説明書にとどまらず、協働の質を高め、長期的にプロジェクトの価値を持続させます。バイブコーディングにおいて文書化は選択ではなく必須です。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
