Markdownでテーブルを扱いやすくするための拡張機能を作った

この記事は「ソフトウェアテスト・QAの小ネタ Advent Calendar 2025」3日目の記事です。 https://qiita.com/advent-calendar/2025/software-testing-koneta

はじめに

AI Coding Agentによって、人類はマークアップ言語であるMarkdownをよく扱うようになりました。
私たちテストエンジニアも、Markdownを使ってテスト計画書やテストケースなどのさまざまなテストウェアを作成することが増えてきました。

そんな中、Markdownでテーブルを編集するのが面倒だと感じたことはありませんか？
ちなみに、Markdownのテーブルは、以下のような形式です。

| Header 1 | Header 2 | Header 3 |
|----------|----------|----------|
| Cell 1   | Cell 2   | Cell 3   |
| Cell 4   | Cell 5   | Cell 6   |

シンプルなテーブルなら直接編集できますが、列の多いテーブルや、長い文字列が設定されているセルがあったりすると、途端に編集の難易度が爆上がりします。

拡張機能の開発

世の中には、Markdownのテーブルを編集するためのVSCode拡張機能がいくつか存在しますが、私のニーズに合うツールがなかなか見つかりませんでした。

それなら作っちゃえ！ということで、作りました。

すでに、Visual Studio Codeの拡張機能として公開しているので、お使いいただくことができます。*1
Interactive Markdown Table Editor - Visual Studio Marketplace

ここで機能紹介をしても仕方ないのですが、基本的な編集はもちろん、以下の機能を実装しています。

  • 行・列の追加
  • ドラッグ＆ドロップでの並び替え
  • カット/コピー&ペースト
  • CSVインポート/エクスポート
  • テーマの変更

開発裏話

機能の紹介ばかりをしてもソフトウェアテストの小ネタっぽくないので、テストの話をします。

この拡張機能は、AI Coding Agentを使ってVibe codingで開発しました。
ほとんどの人が同じことを言っていると思いますが、初手動くものを作る目的においては、とてつもないスピードで開発できます。一方で、公開できるレベルのものにするまでには、結構手直しが必要でした。
特に、新たな機能を追加すると、既に動いていた機能が動かなくなることが多々ありました。この拡張機能を開発する上では、VSCodeとWebViewのインタフェース部分にリグレッションがよく発生していました。具体的には、WebViewで編集したのにVSCode側に反映されないバグが頻発していました。
インタフェースの型をしっかり定義したり、ユニットテストを追加することで、一定これらのバグを抑止できた一方、実際に拡張機能を動かしてみないと見つけられないバグも存在し、適切なテストレベルで適切なテストを行うことの重要性を感じたのでした。
また、ありふれた話ではあるのですが、AIによって生成されたコードを納得してリリースするためには、ガードレールとしてのテストの重要性を再認識した次第でした。

AIによって生成されたコードが含まれたプロダクトが増えていく中で、そのプロダクトをテストする立場の私たちテストエンジニアも、実際にAIで開発してみるとテストについて新たな気づきが得られるかもね、というお話でした。

*1:もちろん、VSCodeをforkしたCursorなどでも使えますが、大人の事情でまだマーケットプレイスからのインストールはできないようなので、リポジトリをcloneしてパッケージ化してください

LLMが導出するテスト観点と向き合うためのフレームワーク

テスト分析

テスト設計コンテストというコンテストのアイデアを練る中で、儚くもボツになった内容を書き残しておきます。

はじめに

LLMを活用して、テスト観点*1を導出する場合、短時間で多くの視点を得られる反面、一見整理された文章で出力されるため、その出力が十分なのか、誤りは含まれていないのかを人間が判断するのが難しいという課題があります。

そこで、メタファーを用いれば、LLMが導出したテスト観点と向き合うことができ、人間自身が思考するきっかけを作ることができるのではないかと考えました。

TRIMについて

Trail-map-based Route and Interaction Method (TRIM)は、テスト対象のソフトウェアやシステムを山や森に見立て、その山を登る(登山)ことを想像しながら、テストの中で「どこをどう確認すればよいか」を整理するためのフレームワークです。 登山という比較的イメージしやすいメタファーを用いることで、LLMと対話(Interaction)することを目指しています。

TRIMは、登山道を中心に、以下のような要素で構成されます。

  • 山頂
  • 登山道
  • 樹海
  • 天候
  • 登山者の属性
  • 地図の破れ・歪み
  • 落石
  • 道しるべ
  • 山の管理者

各エリアの詳細は次のとおりです。

山頂

ユーザーが最終的に達成したい目的地を示します。 操作上のゴールだけでなく、サービスを通じて得たい本質的な価値も含みます。

例えば、ホテルの予約完了という操作上のゴールだけでなく、旅行を楽しみたいという本質的な価値も含まれます。

登山道

登山道は、ユーザーがシステムを「どのように利用するか」という典型的な操作の流れを指します。これはユーザーが特定の目的を達成するために行う「一連の行動」そのものです。例えば、「チケットを探して予約し、決済する」といった一連のステップが含まれます。

樹海

通常のルートから外れた予測困難で危険な領域を指します。 入力の限界値や過去の問題領域、仕様の隙間を含みます。

天候

天候とは、システムの外側を取り巻く環境や条件を表すメタファーです。 通信環境、端末の種類、ネットワークの状態、外部サービスの稼働状況、法的規制など、システムを取り巻く外部要因を記載します。

登山者の属性

登山者の属性は、システムを利用する「人の特徴・スキル」に着目します。 例えば、年齢層、システムを利用する回数、障がいの有無、異なる言語、悪意を持ったユーザなどが含まれます。

地図の破れ・歪み

要求仕様の曖昧さや不明点を指します。どの部分の仕様が不明確かを特定するための視点です。

落石

予期せぬ入力や操作によるエラーや例外発生を指します。システムが正常な処理を行えず、ユーザーの行動を妨げる可能性のある事象を列挙します。

道しるべ

ユーザーが迷わず目的の機能にたどり着けるかを確認する視点です。UIやナビゲーションの分かりやすさ、操作性、一貫性を含みます。

山の管理者

システムの健全性やトラブル対応力を支える運用・監視の視点です。ログ出力・システム監視、バックアップなどの視点を含みます。

出力フォーマット

テストベースと、これらの定義を読み込ませた上で、json形式で、以下のフォーマットに従って出力させます。 エリアの名称と、そのエリアに含まれる観点を出力させ、その根拠となったドキュメントをsourcesとして列挙させます。

{
  "sources": [
    {"id": "1", "name": "hogehoge.md"},
    {"id": "2", "name": "hogahoga.md"}
  ],
  "sections": [
    {
      "name": "山頂",
      "items": [
        {"text": "チケットの予約が行えること", "source": ["1", "2"]}
      ]
    }
  ]
}

json形式を扱いやすくするために

このjsonを付箋形式で便利に扱うためのVSCode拡張機能まで作っちゃいました。*2 でも、公開していないです。でも、どうしても興味がある方はこっそりとご連絡ください。

このフレームワークの課題

ボツになった理由はいくつかあります。

  1. なんとなくそれっぽい出力は出てくるものの、抽象的なものから具体的なものまで挙げてくるので、元々やりたかった「それが十分なのか」を判断するには不十分
  2. ここで出力したテスト観点をどうテストに落とし込んでいくのか、TRIMの考え方を活かした方法が思い浮かばなかった
  3. 富士山をメタファーにした考え方がすでにある

一方で、異なるテスト対象に対しても、出力の型を決めて毎回同じ型で出力させるというやり方は、TRIMに限らず有効だと感じました。

*1:抽象的であいまいさを持つこの単語ですが、ここではテストすべきこと全般を指すものとします

*2:背景画像はAI生成です。申立てがあった場合は削除いたします。