急成長を遂げるメガベンチャー企業のQAマネージャーにとって、組織の拡大は誇らしい反面、深刻な「品質管理の分断」という課題を突きつけてきます。 プロダクト数が増え、マイクロサービス化が進むなかで、チームごとにテスト方針や運用ルールがバラバラになり、全体像が見えないまま障害や手戻りが増えていく。 そんな状況に限界を感じている方は少なくないはずです。 個別最適の改善では、もはやスピードと品質を両立させることはできません。 今求められているのは、テスト管理ツールを軸としたAPI連携による「品質データの民主化」と「全体最適」です。 そこで今回は属人化した管理やツール間の分断をいかに解消し、QAを「リリースのボトルネック」から「事業成長のパートナー」へと変革させるのか。 現場の板挟みを解消し、論理的なデータに基づいた品質戦略を描くための具体的なアプローチを解説します。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テスト管理ツール11製品の完全比較はこちら▼ 【2026年対応】テスト管理ツール11製品の徹底比較！【脱Excel】 テスト管理ツールとAPI連携が「QAの全体最適」を実現する理由 なぜメガベンチャーでは品質管理がバラバラになりやすいのか 急成長を遂げるメガベンチャー企業において、プロダクト数や開発チームの増加は避けて通れない道です。 しかし、組織の拡大に伴い、各チームが独自のスピード感で開発を進めるようになると、品質基準を統一することが極めて困難になります。 特にマイクロサービスアーキテクチャを採用している場合、システム全体の依存関係は網の目のように複雑化し、一つの変更が思わぬ箇所に影響を及ぼすリスクが常に付きまといます。 このような環境では、チームごとに採用するテストツールや運用ルールが異なってしまうことが珍しくありません。 あるチームはスプレッドシートで手厚く管理し、別のチームは最低限の自動テストのみで済ませるといった状況が常態化すると、組織全体としての品質レベルを把握する術が失われてしまいます。 結果として、QA組織は各チームの進捗や不具合状況を追いかける「後追い対応」に終始せざるを得ず、全体を俯瞰した戦略的な品質保証から遠ざかってしまう構造的な課題を抱えています。 QAがボトルネックになる組織構造 多くの組織において、QAがいまだに「リリース前の最終チェック工程」として位置づけられていることは、スピードと品質の両立を阻む大きな要因です。 開発プロセスが加速する中で、手動テストや属人的なレビューに依存した体制を維持していると、QAの完了待ちがリリースサイクルの遅延を招くボトルネックとなります。 これは単に作業時間の問題だけでなく、開発者やプロダクトマネージャー（PdM）との間に品質情報の非対称性が生じていることにも起因します。 開発側がどのようなテストを行い、どの程度の品質を確認済みなのかが可視化されていないため、QA側は安全を期して過剰な確認作業を行わざるを得ません。 また品質の合否判断が特定の担当者の経験や勘に頼る属人化した状態では、論理的な根拠に基づいた意思決定が難しくなります。 このような分断された構造は、現場に過度な負荷を強いるだけでなく、経営層に対しても品質の現状を正確に説明できないという、組織運営上のリスクを増幅させています。 テスト管理ツールとAPI連携が注目される背景 現代のソフトウェア開発において、CI/CDパイプラインの普及はテストのあり方を根本から変えました。 ビルドのたびに実行される膨大な自動テストの結果を、手動で集約して管理することはもはや不可能です。 そこで重要視されているのが、テスト管理ツールと各種開発ツールをAPIで接続し、テスト結果をリアルタイムで自動集約する仕組みです。 API連携によって、GitHubやCIツール、不具合管理システムとテスト管理ツールがシームレスにつながることで、開発文化の一部として品質管理が組み込まれるようになります。 この変化はQAの役割を「検証部門」から、品質に関するあらゆるデータを司る「品質設計部門」へと進化させるものです。 QAが品質のデータハブとなり、APIを通じて収集された客観的なデータを元に、開発や経営層と同じ言語で品質リスクを議論できる土壌が整います。 単なる不具合の発見者ではなく、持続可能な開発体制を支えるためのデータプラットフォームを構築することこそが、メガベンチャーのQAマネージャーに求められる全体最適の第一歩と言えます。 テスト管理ツールだけでは解決できない品質管理の課題 テストケース管理だけでは品質の全体像が見えない理由 多くの現場ではテスト管理ツールを導入することで、スプレッドシート管理からの脱却を試みます。 しかし、単にテストケースをツール上に並べただけでは、本来目的としている品質状況の把握には至りません。 テストケース自体は管理できていても、それが現在のプロダクトのどの機能に対応し、どの程度のカバレッジを担保しているのかという動的な品質状況が不透明なままになりがちだからです。 特に開発スピードが速い環境では、テスト結果と日々の開発状況が切り離されてしまうことが大きな課題となります。 ソースコードの変更履歴やプルリクエストの状態とテスト結果が結びついていないため、不具合が発生した際、どのテストを強化していれば防げたのかという遡及的な分析が困難です。 またリリース可否を判断する際に、客観的なデータに基づいた説明ができず、最終的には経験則や特定の担当者の判断に頼らざるを得ない状況を生んでいます。 これでは、経営層やPdMに対して「なぜこのリリースは安全なのか」を論理的に納得させることは難しいと言わざるを得ません。 開発ツール・CI・テスト結果が分断される問題 モダンな開発現場では、GitHubやJiraといったIssue管理ツール、GitHub ActionsやCircleCIなどのCIツールが日常的に利用されています。 しかし、これらの開発基盤とテスト管理ツールがAPI等で連携されていない場合、情報は深刻なまでに分断されます。 例えば、CI上で実行された自動テストの結果がCIツールのコンソール内に留まり、テスト管理ツールに自動集約されない状況では、QA担当者は各ツールの画面を行き来して情報を手作業で拾い集めることになります。 このような情報の散在は、QAレポートの作成を極めて非効率なものにします。 複数のダッシュボードを眺め、手動で集計して報告書を作成している間に、開発現場ではさらに新しいコードがマージされ、情報は刻一刻と古くなっていくからです。 情報共有のわずかなタイムラグは、重大な品質リスクの芽を見逃す要因となります。 開発チームが最新のテスト失敗を確認するまでに時間がかかれば、修正コストは増大し、結果としてQAがリリースの足を引っ張る存在として認識される悪循環に陥ってしまいます。 プロダクト横断で品質を可視化できない組織の限界 複数のプロダクトを展開するメガベンチャー企業において、チームごとに品質指標がバラバラであることは致命的な組織課題となります。 あるチームは「バグ密度」を重視し、別のチームは「テスト消化率」を基準にしているといった状態では、QAマネージャーが組織全体の品質健全性を俯瞰して判断することができません。 各プロダクトの品質状況が統一されたフォーマットで可視化されていないため、経営層もどこにリソースを投資すべきか、どのプロダクトがリスクを抱えているのかを正しく把握できないまま経営判断を下すことになります。 組織が拡大し、マイクロサービス化が進むほど、この統制の欠如は大きな歪みとなって現れます。 共通基盤の変更が複数のプロダクトに影響を与える際、横断的なテスト結果の集約ができなければ、品質の連鎖的な崩壊を防ぐことは困難です。 属人化した管理手法やツールごとの個別最適に限界を感じているのであれば、それはまさに組織としての品質統制が機能不全に陥っている兆候です。 場当たり的な改善を繰り返すのではなく、API連携を軸としたデータ統合による全体最適へのシフトが急務となっています。 API連携で実現する「品質データの一元化」 Issue管理ツールとテスト管理ツールの連携 メガベンチャーのようなスピード感のある現場では、JiraやGitHubといったIssue管理ツール上の要件と、それに対応するテストケースの紐付けが極めて重要です。 APIを活用してこれら双方向の連携を実現することで、特定の要件がどのテストケースで検証され、現在どのような実行状況にあるのかというトレーサビリティを自動で確保できます。 不具合が発生した際にも、関連するテストケースが自動で紐付く仕組みを構築すれば、再発防止策の検討がスムーズになり、修正後の回帰テストの範囲も即座に特定可能です。 さらに、エンジニアやPdMが使い慣れたチケット管理画面から離れることなく、テストの実行進捗や結果をリアルタイムで確認できる環境は、チーム間のコミュニケーションコストを劇的に下げます。 要件変更が頻繁に発生するマイクロサービス環境において、仕様変更の影響範囲をAPI経由で即座に把握し、テスト計画を動的に修正できる柔軟性は、QAが開発の足を止めないための生命線となります。 これにより、場当たり的な対応から脱却し、論理的な根拠に基づいた品質管理の基盤が整います。 CI/CDと連携したテスト結果の自動集約 モダンな開発プロセスにおいて、CI/CDパイプラインとテスト管理ツールの連携は欠かせない要素です。 GitHub ActionsやCircleCIなどのツールで自動テストが走るたびに、その結果をAPI経由でテスト管理ツールへ自動送信する仕組みを構築します。 これにより、エンジニアが各ツールのコンソールを個別に確認する手間が省け、自動テストの結果がテスト管理ツール上の最新ステータスとして常に反映されるようになります。 この連携の真の価値は、手動テストと自動テストの結果を一元管理できる点にあります。 探索的テストや複雑なシナリオ検証といった手動テストの知見と、膨大な自動テストの実行ログが同じプラットフォームに蓄積されることで、リリース可否を判断するための品質データが多角的に揃います。 蓄積されたデータは、単なる合格・不合格の記録ではなく、過去の傾向分析やリリース判断の客観的な裏付けとして機能します。 API連携による自動集約は、QAを単なる作業から、データに基づいた意思決定を支えるインテリジェンスな役割へと引き上げる大きな転換点となります。 複数プロダクトの品質を横断して可視化する仕組み 複数のプロダクトやマイクロサービスが並走するメガベンチャーにおいて、QAマネージャーに求められるのは「組織全体の品質を俯瞰する視点」です。 API連携によって各プロダクトから収集されたデータを統合することで、プロダクトごとにバラバラだった品質指標を一箇所に集約できます。 これにより、特定のチームで不具合率が上昇している、あるいはテスト消化が滞っているといった状況をリアルタイムで把握し、横断的なリソース配分や支援の要否を的確に判断できるようになります。 また蓄積されたデータを用いた品質トレンド分析は、次四半期の戦略策定や組織改善の強力な武器となります。 経営層やステークホルダーに対しても、専門用語を羅列するのではなく、グラフや数値で整理された品質レポートとして提示できるため、共通の言葉で議論することが可能になります。 プロダクトを横断した品質の可視化は、QA組織が単なるコストセンターではなく、事業成長とスピードを支える戦略的なパートナーとして社内で認識されるための不可欠なプロセスです。 メガベンチャーQAが実践するツール連携アーキテクチャ テスト管理ツールを中心にした品質データの流れ 大規模な開発体制において、品質管理の全体最適を実現するためには、テスト管理ツールを単なる「ケースの置き場所」ではなく、組織内の「品質データハブ」として再定義する必要があります。 具体的には、GitHubやJiraといった開発ツール、さらにはCIツールや各種自動テストフレームワークから、APIを通じてあらゆる品質関連データを自動で収集する設計が不可欠です。 QAマネージャーは、バラバラに存在する情報を統合し、プロダクトの健全性を一目で把握できるデータ基盤を構築する責任を担うことになります。 このアーキテクチャにおいて、QA組織の役割は検証作業の遂行から、品質データの統合管理へとシフトします。 各ツール間をAPIで接続し、人手を介さずにデータが同期される仕組みを整えることで、情報の鮮度が劇的に向上します。 例えば、エンジニアがコードをマージした瞬間にテストケースの実行ステータスが更新され、その結果が即座に品質レポートに反映されるような自動連携のサイクルを目指します。 このような「品質の自動集約」が実現されて初めて、QAは現場の板挟みから解放され、論理的なデータに基づいた品質推進リードとしての本来の価値を発揮できるようになります。 CI・自動テスト・Issue管理をつなぐ連携構成 効率的な品質保証体制を築くためには、CI・自動テスト・Issue管理の3点をシームレスにつなぐ連携構成が欠かせません。 CIパイプライン上で実行された自動テストの結果は、API経由で即座にテスト管理ツールへと送信され、手動テストの結果と統合される必要があります。 この際、単に「成功・失敗」の結果を送るだけでなく、失敗したテストに関連するJiraのチケットやGitHubのIssueが自動的に紐付く仕組みを構築します。 これにより、障害データとテストケースが強固に結びつき、不具合の修正状況がテスト管理側にリアルタイムで反映されるようになります。 このような連携は、開発・QA・運用の三者が共通の情報を参照できる「品質の情報共有基盤」として機能します。 開発チームはテストの失敗理由を即座に把握でき、QAチームは修正の完了を待たずに次のテスト計画を練ることが可能になります。 また、障害発生時のインパクト分析においても、APIで繋がったデータ群が強力な味方となります。 属人化しがちな不具合の追跡調査がシステム化されることで、組織全体のリテラシーが底上げされ、場当たり的な改善ではない、持続可能な品質向上のプロセスが定着します。 組織横断の品質ダッシュボードを作る方法 メガベンチャーにおける全体最適の最終形は、複数プロダクトの品質状況を横断的に可視化するダッシュボードの構築です。 まず取り組むべきは、テスト成功率や欠陥密度、平均復旧時間（MTTR）といった、組織全体で共通して用いる品質メトリクスの設計です。 これらの指標をAPI経由で集約し、プロダクトごとに比較可能な形で統合表示することで、QAマネージャーはどのチームに支援が必要か、どこにリスクが潜んでいるかを即座に判断できるようになります。 このダッシュボードは、経営層やPdMに対する品質報告の強力なツールにもなります。 専門的なテスト結果を経営判断に役立つ「品質リスク」という言葉に変換し、グラフや数値で可視化することで、品質投資の正当性を論理的に説明できるようになります。 QAの取り組みが事業成長のスピードを支えていることをデータで証明できれば、社内でのQA組織のプレゼンスは飛躍的に高まります。 組織拡大に伴う品質統制の難しさを、テクノロジーによる自動化とデータ統合で解決することこそが、次世代のQAマネージャーに求められる確信ある歩みと言えるでしょう。 QAマネージャーが最初に設計すべきAPI連携のポイント 最初に連携すべき3つのツール（Issue・CI・自動テスト） メガベンチャーのような複雑な開発組織で全体最適を目指す際、全方位に手を広げるのではなく、まずは中核となる3つのツールとのAPI連携から着手するのが定石です。 第一にJiraやGitHubなどのIssue管理ツール、第二にGitHub ActionsやCircleCIといったCI/CDツール、そして第三にPlaywrightやAutifyなどの自動テスト基盤です。 これらをテスト管理ツールと接続することで、要件定義から開発、実行、不具合報告までの一連のサイクルがデータで繋がり、断絶していた情報の流れがスムーズになります。 最初から完璧な自動化を目指すと現場の反発や導入コストの肥大化を招くため、小さく始めて段階的に拡張する方法を推奨します。 まずは「CIで実行された自動テストの結果がテスト管理ツールに自動で反映される」といった、最も作業負荷の高い部分から着手することで、現場のエンジニアやQA担当者は即座にその恩恵を実感できます。 成功体験を積み重ねながら、徐々にIssue管理ツールとの双方向同期などを組み込んでいくことで、組織全体に無理なくAPI連携の文化を浸透させることが可能です。 API連携を成功させる品質データ設計 ツール同士をAPIでつなぐ前に、それらの間を流れる品質データの設計を疎かにしてはいけません。 単にデータを流し込むだけでは、結局どのプロダクトが危険な状態にあるのかを判断できないからです。 まずは組織全体で共通して使用する品質指標を明確に定義し、テストケース一つひとつがどの要件や機能に対応しているのかという紐付けのルールを策定します。 このトレーサビリティの設計が、後のリリース判断における論理的な根拠となります。 また、テスト結果のデータ構造を整理することも重要です。 手動テストの「合格・不合格」という結果と、自動テストから送られてくる詳細な実行ログやエラーメッセージをどのように一つのプラットフォーム上で管理し、分析に活用するかをあらかじめ決めておきます。 このように整理された品質データは、単なる記録を超えて、将来の不具合予測やリソース配分の最適化といった戦略的な意思決定に活用できる資産へと変わります。 データ設計を盤石にすることで、ツール連携は初めて真の価値を発揮します。 QAを「テスト担当」から「品質設計者」に変える視点 API連携による仕組み化の真の目的は、QAの役割を「検証の実行者」から「品質の設計者」へと昇華させることにあります。 手作業による集計や報告業務から解放されることで、QAマネージャーはプロダクトの成長戦略に直結した品質戦略の立案に時間を割けるようになります。 収集された客観的な品質データを武器に、開発組織やPdMと同じ土俵で「現在のリスク」を議論できる環境が整えば、QAはリリースを止めるボトルネックではなく、リリース精度を高めるアクセルとしての信頼を獲得できます。 持続可能なQA組織を構築するためには、属人化した技術や気合に頼るのではなく、システムとして品質を担保する姿勢が求められます。 API連携はそのための強力な基盤であり、一度この仕組みが動き出せば、組織が拡大しても品質統制が破綻することはありません。 品質データを活用した迅速かつ的確な意思決定を繰り返すことで、QA組織は価値創出の中核として社内に認知されるようになります。 これは、QAマネージャーとしての市場価値を高めるだけでなく、現場と経営層の板挟みに悩む状況から抜け出し、確信を持って組織をリードするための重要な一歩となります。 まとめ メガベンチャーにおける品質管理の全体最適は、単に高機能なツールを導入するだけでは成し遂げられません。 Issue管理ツール、CI/CD、自動テスト基盤をAPIで網の目のように接続し、テスト管理ツールを組織の「品質データハブ」へと昇華させることが不可欠です。 API連携によってもたらされる真の価値は、作業の自動化だけではありません。 トレーサビリティの確保： 要件とテスト結果が紐付き、変更の影響範囲が即座に可視化される。 意思決定の迅速化： 主観や経験ではなく、客観的なデータに基づいてリリース可否を議論できる。 QAの役割変革： 工数のかかる集計作業から解放され、戦略的な「品質設計」に注力できる。 QAマネージャーとして、まずは中核となる3つのツール連携から小さく着手し、組織横断の品質ダッシュボードを構築するステップを歩み始めてください。 データに基づいた確信あるリードこそが、現場と経営層双方からの信頼を勝ち取り、プロダクトの価値創出を最大化させる鍵となります。 持続可能な品質体制へのシフトは、もはや選択肢ではなく、事業をスケールさせるための必須戦略です。 API連携できるテスト管理ツールといえばPractiTest テスト管理ツールを品質データのハブとして活用するなら、API連携に強いPractiTestは有力な選択肢です。 PractiTestはJiraなどのIssue管理ツール、CI/CD、自動テスト基盤と連携できるREST APIを提供しており、開発・テスト・不具合情報を一元的に集約できます。 さらに自動テスト結果の取り込みやチケットとのトレーサビリティ確保にも対応しているため、複数プロダクトの品質状況を横断的に可視化する基盤として活用可能です。 既存の開発ツールを活かしながら品質データを統合できるため、QAを検証部門から「品質設計の中心」へ進化させたい組織に適したテスト管理ツールといえるでしょう。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

ども！最近は仕様書×AIの文脈で図解まわりの検証をやってる龍ちゃんです。 Draw.io の開発元である jgraph 社が、公式の MCP サーバーを出しました。 jgraph/drawio-mcp リポジトリで Apache 2.0 ライセンスで公開されています。 コミュニティ実装の MCP サーバーはいくつかありましたが、公式となると話が変わってきます。draw.io 本体と同じ開発元が直接メンテしてくれるので、コミュニティ版よりも長くメンテされやすいんですよね。 MCP の基本的な仕組みについては「 AIエージェントの進化が分からない？秘書で理解する3段階 」で解説しているので、「MCPってなに？」という方はそちらを先にどうぞ。 jgraph/drawio-mcp リポジトリ、中を見てみると実は4つのアプローチが入っていて、それぞれ対象環境や出力形式が異なります（全体像は後半で紹介します）。 この記事では、Claude Code ユーザーに一番スタンダードな MCP Tool Server を試していきます。セットアップ方法、3つの入力フォーマット（Mermaid / XML / CSV）の使用感、そして正直「できないこと」まで、検証した結果をまとめました。 今回の内容です。 MCP Tool Server のセットアップ（ .mcp.json に数行追加するだけ） 3つの入力フォーマットを実際に試した比較 MCP Tool Server の「できないこと」を正直に語る 向いている人・向いていない人の判断材料 龍ちゃん できないことを紹介していますが、それの対処法に関しては「 Draw.io公式Skillで設計図をGitHub管理 — VS Code完結のセットアップ 」で紹介しています。併せてご一読ください！ セットアップ: .mcp.json に数行追加するだけ Claude Code なら、ターミナルで以下のコマンドを実行するだけ。 claude mcp add -s project drawio -- npx @drawio/mcp これで .mcp.json が自動で作られます。手動で書く場合はこう。 { "mcpServers": { "drawio": { "type": "stdio", "command": "npx", "args": ["@drawio/mcp"] } } } 前提として Node.js が必要です（npx を使うので）。検証時の環境は Node.js v25.7.0、npm パッケージ @drawio/mcp v1.1.2 でした。 以前 MCP のトークン消費問題について記事を書いた んですが、draw.io MCP はツール定義が3つしかないので、コンテキストへの負担はかなり軽い部類です。Notion MCP みたいに大量のツールが常駐するタイプとは全然違います。 使えるようになる3つのツール ツール 入力 用途 open_drawio_mermaid Mermaid.js 構文 フローチャート・UML 全般 open_drawio_xml draw.io XML（mxGraphModel） 細かいスタイル制御が必要な図 open_drawio_csv draw.io CSV インポート形式 データ駆動の組織図・ツリー どのツールも lightbox （読み取り専用モード）と dark （ダークモード）のオプションが付いています。 設定はこれだけで、すぐに使い始められます。 使ってみた: 3つの入力フォーマット Mermaid で図を生成 まずは Mermaid から。Claude Code に「ロードバランサー構成図を Mermaid で描いて」とお願いしてみました。 すると Claude が Mermaid 構文を生成して、MCP ツール経由で draw.io に渡してくれます。数秒後にブラウザがパッと開いて、draw.io のエディタに図が表示されました。 これ、良いですね。Mermaid の構文自体がシンプルなので、5ノード程度の図なら入力トークンは約100程度で済みます。しかも Mermaid エンジンが自動レイアウトしてくれるので、ノードが重なったり変な配置になったりしない。ノード数が増えても構文が簡潔なぶん、トークン消費は抑えられます。 ブラウザで開いた draw.io エディタ上で、色やフォントを変えたりノードの位置を微調整したりもできます。AI が下書きして、人間が仕上げる感じですね。 XML で図を生成 次に XML。同じ構成図を XML フォーマットで試してみます。 XML だと draw.io の全プロパティを指定できるので、ノードの色、枠線のスタイル、フォントサイズまで細かく制御できます。Mermaid ではテーマに依存する部分も、XML なら自由自在。 ただし、トレードオフがあります。 同じ図を表現するのに XML は約800トークン使います。Mermaid が約100トークンだったので、ざっくり8倍。さらに、AI がノードの座標（x, y）を自分で計算して配置するので、レイアウトが微妙になることもあります。Mermaid なら自動でいい感じに並べてくれるのに、XML だとそこは AI 任せなんですよね。 トークンもレイアウトも Mermaid に分がありますが、「この色で、このフォントで、この位置に」って指定したいなら XML 一択です。 CSV で図を生成 最後に CSV。これは少し特殊で、draw.io 固有の CSV インポート形式に従う必要があります。 CSV ヘッダーに # label: %name% のようなメタ記法を書いて、データ行で親子関係を定義していく形式です。ツリー構造や組織図を作るには向いてるんですが、ただ汎用性はあまり高くないので、フローチャートや UML を CSV で書こうとは思わないですね。 フォーマット比較 3つ試した結果をまとめます。 比較項目 Mermaid XML CSV トークン効率 高（XML の約 1/10） 低（冗長） 中 レイアウト 自動 手動（AI が座標指定） 自動 スタイル制御 低（テーマ依存） 高 中 対応図形 flowchart, sequence, class, state, ER 等 全て ツリー・組織図 結論としては、特別な理由がなければ Mermaid を使うのが正解 です。トークン効率が XML の約 1/10、自動レイアウトで配置も綺麗、対応する図形タイプも広い。XML は「どうしても色やスタイルを細かく指定したい」ときの選択肢。CSV は組織図やツリーを大量のデータから生成したいときのニッチ枠です。 正直に言う: MCP Tool Server の「できないこと」 ここまで「Mermaid いいじゃん」って話をしてきましたが、MCP Tool Server には正直「できないこと」も結構あります。 まず仕組みを知っておく さっき Mermaid で図を生成したとき、ブラウザがパッと開きましたよね。あれ、実はローカルにファイルを作ってるわけじゃないんです。 MCP Tool Server は、AI が生成したコンテンツを圧縮・エンコードして app.diagrams.net の URL に全部詰め込んでいます（ ソースコード ）。その URL をブラウザで開くと draw.io エディタが表示される、という仕組みです。 つまり すべてが URL に埋め込まれている 。ローカルにファイルは一切残りません。 この「URL 方式」が、以下の制約の根本原因です。 できないこと 一番大きいのは、 ローカルにファイルが残らない ことです。 .drawio ファイルが生成されないので、Git で管理したり、VS Code の Draw.io 拡張で開いたりができません。 これに連動して、VS Code 内で作業を完結させることもできません。図を確認するにはブラウザに切り替える必要があるし、PNG や SVG が欲しければ draw.io エディタから手動でエクスポートする手間が発生します。GitHub に図を置きたい場合も、URL からは .drawio ファイルを取り出せないので、リポジトリ管理のワークフローとは噛み合わない。 もう1つの本質的な制約は、 差分更新ができない こと。URL は毎回まるごと新規生成されるので、「さっきの図のここだけ修正して」ということができません。修正するには図全体を再生成するか、ブラウザの draw.io エディタ上で手動で直す必要があります。 あとは環境面の話で、 app.diagrams.net に接続できないとそもそも動きません。オフラインでは使えないです。 一方で、URL だからこそ便利な面もある URL をそのまま Slack やチャットに貼れば、相手がブラウザで即座に図を見られます。受け取る側に draw.io のインストールは不要で、ブラウザさえあれば OK。しかも URL を開いた先の draw.io エディタでそのまま編集もできるんですよね。 ファイルを共有してもらって、ツールを入れて、開いて…みたいな手間がゼロ。検証で 27ノードのマイクロサービス構成図を作ったときも、URL 長は 1851 文字でブラウザの制限内に収まっていました。 jgraph/drawio-mcp の4つのアプローチ ここまで MCP Tool Server を試してきましたが、 jgraph/drawio-mcp リポジトリには4つのアプローチが用意されています。 アプローチ 対象環境 出力形式 MCP 必要 MCP Tool Server Claude Code, Cursor 等 URL → ブラウザで draw.io を開く ○ MCP App Server Claude Desktop 等 チャット内にインライン描画 ○ Skill + CLI Claude Code .drawio ファイルをローカル生成 × Project Instructions Claude Project Python コード実行で URL 生成 × 「MCP サーバー」と聞くと1つのツールを想像しますが、対象環境と用途に応じて手段が分かれています。MCP Tool Server と MCP App Server は MCP 対応クライアントが必要で、Skill + CLI と Project Instructions は MCP なしで動作します。 まとめ: 向いている人・向いていない人 Draw.io 公式 MCP Tool Server、使い所を選べば便利だけど万能ではない、というのが正直な感想です。 向いていない人 を先に挙げておきます。 VS Code で作業を完結させたい .drawio ファイルをローカルで管理したい GitHub リポジトリに図を保存したい 向いていない人向けには、上で紹介した Skill + CLI が選択肢になります。MCP なしで .drawio ファイルをローカルに生成できるので、VS Code + Git のワークフローに乗せられます。次回の記事で Skill + CLI のセットアップと MCP Tool Server との比較をやっていく予定です。 逆に、 向いている人 はこういう方です。 ブラウザで draw.io を使い慣れている Mermaid で図を書きたい（トークン効率が圧倒的） セットアップを最小限にしたい（ .mcp.json に数行追加するだけ） URL を Slack やチャットで共有したい 最後にもう1つ。Draw.io は Mermaid や PlantUML とは違って GUI エディタなので、AI が生成した図を人間がブラウザ上で手で仕上げるワークフローが成立します。テキストベースのツールだと AI の出力がそのまま最終成果物になりがちですが、draw.io なら色・配置・形状を自由に調整できる。この「AI が 80% 作って、残りを人間が仕上げる」感覚は、他のダイアグラムツールにはないものでした。 ではまた！ 関連ブログ MCP と Skills の使い分け Claude Code MCP が遅い・重い問題、CLI + Skills で解決 — Notion・Playwright MCP の接続・トークン問題を CLI + Skills 移行で軽量化した話。MCP のパフォーマンス面の課題と解決策を扱っています Claude Code: 公式MCPを補完するSkills設計パターン — 公式 MCP の不足機能を Skills で補完する設計パターン。MCP → CLI → Skill の判断基準を整理しています AIエージェントの進化が分からない？秘書で理解する3段階 — MCP の基本的な仕組みを秘書の比喩で解説。「MCP ってなに？」という方向けの入門記事です AI × 図解作成 図解作成、AIに丸投げしたら「たまに自分より上手い」件 — Claude Code Skill で HTML 図解を自動生成 → PNG 変換する流れ。気に入ったデザインを蓄積して AI のスキルを育てる方法も紹介 ClaudeでMermaid図作成を自動化！2時間→5分の劇的時短術 — Claude + Mermaid でフローチャートやシーケンス図を自動生成。Live Editor の活用術と日本語フォントの対処法 Claude Codeで仕様書のPlantUML図を自動生成 — PlantUML の各種図を Claude Code で自動生成し、VS Code Preview で確認する環境構築と実践例 仕様書の図はAIに読ませるな — 軽量コードを添える設計パターン — Mermaid / PlantUML のソースコードと設計意図を HTML コメントで添える設計パターン。AI が推測ではなく正確に読める形式にする方法 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Draw.io公式MCPでできること・できないこと — 3フォーマット比較 first appeared on SIOS Tech Lab .

はじめに こんにちは。Musubi Insightチームでエンジニアをしている中村です。 Musubi Insightでは、SaaS型のE2Eテストツール mabl で14のテストを運用していましたが、認証の安定性やコード管理の面でいくつか課題がありました。 昨今のフロントエンド開発では Claude Code などのAIエージェントと Playwright MCP を組み合わせ、コード修正から動作確認までをPlaywrightベースで回すワークフローが選択肢として広がりつつあります。こうした背景もあり、チームでPlaywrightへの移行を進めることになりました。 本記事では、移行にあたって…