Vscode

ITmediaの 「メモ帳」の対応で脚光を浴びるMarkdown　AI時代の“文書共有のスタンダード”になるか という記事を読みましたが、技術的背景を知る者としては、正直なところ強い危機感を覚えずにはいられませんでした。この記事は、おそらくインプレスの「技術の泉シリーズ Markdown ライティング入門」などをベースに構成されたものと推測されますが、紹介されているツールや認識が数世代前で止まってしまっています。 2026年という現在、Markdownはもはや「普及するかもしれない」技術ではなく、 エンジニアリングと文書作成の分かちがたい交差点 として確立されています。本稿では、同記事で見られた技術的な誤謬を正しつつ、現代における真のMarkdownワークフローを整理します。 1. ツール選定における「出土品」レベルの乖離 まず、Markdownエディタとして「MarkdownPad」や「MacDown」が挙げられている点に驚きを禁じ得ません。MarkdownPadは2013年にMarkdownPad2へと移行しましたが、その後、Microsoftの Visual Studio Code (VS Code) という圧倒的なデファクトスタンダードが登場したことで、その役割を終えています。 今、初心者にこれらの化石化したツールを勧めるのは、令和の時代に「インターネットをするならNetscape Navigatorがいいですよ」と教えるようなものです。 Cursorは「モデル」ではなく「フォーク」である 記事中では以下のような記述がありました。 「Cursor」はこれ（VS Code）をモデルに作られているので、元祖の方でもMarkdown記法に対応している。 技術メディアとして、ここは正確に 「Code - OSSをフォークして開発されている」 と記述すべきです。「モデルにしている」という曖昧な表現では、バイナリ互換性や拡張機能の共有性といった重要な技術的構造が伝わりません。 2. 破壊されているワークロードとAIの拒絶 最も致命的だと感じたのは、執筆環境に関する以下の助言です。 「Markdown Editor」という拡張機能があり、それをインストールするとレンダリングした状態で執筆が可能になる。ただ「Markdown Editor」上で書くと、「Cursor」の特徴であるAIのサジェスチョンが表示されないので…… この「編集画面をプレビュー画面で上書きする」スタイルは、現代のAI駆動開発（AI Native Development）とは極めて相性が悪いものです。CursorやVS Codeの真髄は、エディタがテキストの構造を理解し、AIがリアルタイムで補完や修正を提案することにあります。 標準のプレビュー機能を Side by side (左右分割) で配置すれば済む話を、わざわざAIの恩恵を殺すような拡張機能を紹介するのは、読者を「一番不便で、AIの恩恵を受けられない呪われた環境」に閉じ込める行為に他なりません。 3. 現代のMarkdownエコシステム：Mermaidと自動化 現代のMarkdownは、単なるリッチテキストの代替品ではありません。 Mermaid による図解のコード化、 Pandoc による高度な形式変換、 GitHub Actions による自動ビルドなど、高度に自動化されたエコシステムの一部です。 graph TD A[Markdown Source] -->|AI Pair Programming| B(VS Code / Cursor) B --> C{Processor} C -->|Mermaid| D[Diagrams / Flowcharts] C -->|Pandoc| E[PDF / Docx / LaTeX] C -->|Static Site Gen| F[Hugo / Astro / Zenn] D & E & F --> G[Knowledge Asset] subgraph "Legacy View (Critiqued Article)" H[MarkdownPad] --> I[Manual Preview] I --> J[Text Only Output] end 上記の図が示すように、現代的なワークフローでは「テキストを書いて終わり」ではなく、図解（As Code）やCI/CDを含めた一連のパイプラインとしてMarkdownを扱います。 ...

Covid-19のダッシュボードの作成を例にしています。イメージとしては、表形式でデータが見えるようにして、時系列で合計値がチャートして見えるようにして、カレンダーヒートマップで曜日ごとの動きが見えるようにするというのを考えてみます。仮説としては人の動きに感染者は依存しているのではないかと言う仮説です。だとすれば、曜日ごとに特徴があるのではないかと言う仮説です。 流れとしては、以下のような順番になります。 プロジェクトの作成 データのインポート クエリとビジュアリゼーションコンポーネントの配置 クエリとビジュアリゼーションコンポーネントの配置は主にMarkdownのドキュメントで行います。 プロジェクトの作成 まず、プロジェクトを作成するところから始めます。プロジェクトの作成はVisual Studio Codeから作成します。 プロジェクトの作成(1/5) プロジェクトの作成(2/5) プロジェクトの作成(3/5) プロジェクトの作成(4/5) プロジェクトの作成(5/5) Evidenceのウェルカム画面 プロジェクトを作成すると、Evidenceのサーバを起動可能になります。Evidenceのサーバを起動すると通常はポート1313で待ち受け状態になります。そうすると、Webブラウザで開けるようになります。ウェルカム画面は以下のようになります。 Evidenceサーバの起動 Evidenceサーバの起動はVisual Studio Codeから行います。コマンドパレットから起動できます。 データのインポート https://www.mhlw.go.jp/stf/covid-19/open-data.html から取得した、新規陽性者数の推移（日別）のデータをプロジェクトフォルダのsourcesにcovid19というディレクトリを作成して 配置します。新規陽性者数の推移（日別）のデータはnewly_confirmed_cases_daily.csvというファイル名なので、newly_confirmed_cases_dailyというテーブルとして識別されます。 データのインポートはEvidenceのサーバからやると、設定ファイルなどを簡単に作成できます。 データのインポート データのインポート (1/4) Evidenceのサーバのインポート画面ではインポート可能なデータ形式の確認ができます。 Evidenceでインポート可能なデータについてはEvidenceのWeb画面を起動したときのSettingsの中の画面で確認できる。 データのインポート (2/4) データのインポート (3/4) データのインポート (4/4) 現在Evidenceでインポート可能なもの BigQuery CSV Databricks DuckDB Microsoft SQL Server PostgreSQL Redshift JavaScript Snowflake SQLite Trino MotherDuck 最初のコンテンツの作成 最初のコンテンツの作成 (1/2) 次に、プロジェクトフォルダのpages/index.mdを編集します。index.mdはEvidenceのサーバに接続してデフォルトで表示されるページになります。ここのコンテンツを以下のようにします。 --- title: Welcome to Evidence --- ## Covid19 のCSV確認 ```sql covid19_10 select * from covid19.newly_confirmed_cases_daily limit 10 ``` <DataTable data={covid19_10}/> 最初のコンテンツの作成 (2/2) これにより、covid19.newly_confirmed_cases_dailyから10行取り出して表として出力されます。 ...

目的と対象読者 このドキュメントは、Windows環境を前提にEvidenceの利用方法について記述しています。Evidenceは様々な環境で稼働しますが、執筆時点での環境および設定を基準としています。 対象読者 Evidenceをはじめて利用する方 Windows環境でのセットアップ利用方法に関心のある方 前提条件 インストール済みのソフトウェア Visual Studio Code Git Node.js npm Node.jsのインストール方法 Scoopを利用し、執筆時点のLTSを利用しています。 Evidenceのバージョン バージョン 40.1.1をターゲットにしています。 Evidenceとはなにか 「Evidence」とは、Markdownで管理できるオープンソースのBI（ビジネスインテリジェンス）ツールです。 具体的には、レポート、意思決定支援ツール、埋め込みダッシュボードなどのデータプロダクトを構築するための オープンソースのフレームワークと説明されています。 Evidenceの主な特徴は以下の通りです。 コード駆動型BIツール:ドラッグ＆ドロップ式のBIツールとは異なり、コード（主にSQLとMarkdown）を使用してデータプロダクトを構築します。 Markdownで管理: Markdownファイル内でSQLクエリを記述し、コンテンツやレイアウトを管理します。 多様なデータソースに対応: データウェアハウス、フラットファイル（例：CSV）、非SQLデータソースなど、さまざまな種類のデータソースを扱うことができます。 SQLクエリの実行と結果の可視化: Markdownページに記載されたSQLステートメントに基づいてデータソースに対してクエリを実行し、その結果をグラフや表としてウェブサイトに出力できます。Markdown内で使用されるSQLはDuckDBのSQLです。 静的サイトの生成 出力は静的なウェブサイトとして生成されるため、デプロイや共有が容易です。npm run buildコマンドで静的サイトを生成し、S3などのホスティングサービスに格納して簡単に共有できます。 豊富なコンポーネント: クエリ結果に基づいて、さまざまなチャート（棒グラフなど）、表（DataTable）、大きな単一の値（BigValue）などのコンポーネントをレンダリングできます。 高度な機能: テンプレートページによる複数ページの生成、表示内容の制御のためのループやIf/Else文、クエリ結果のフィルタリング機能（Query Functions）なども備わっています。 Evidenceの適する用途 アーキテクチャなどを踏まえての説明は次回以降になりますが、Evidenceは様々な用途に利用可能です。基本的にはOn the flyのクエリーは困難なので、IoTなどの機器からのリアルタイムなダッシュボードには向きません。どちらかと言うと、日次・月次でしめるような処理が適します。従って、売り上げなどの分析が適すると思われます。

基本的な準備 システム構成の概要 Evidenceのアーキテクチャ Evidenceは基本的には、データソース、DuckDB、レンダリングエンジンという仕組みになっています。実際には更に、 静的サイトジェネレータも重要な位置を示しますが、その性質からここには表現していません。以下の図にEvidenceの基本的なアーキテクチャを示します。 まず、データソースからデータが取り出され、共通のデータ形式であるParquetに変換されます。ParquetはDuckDBによって利用されます。 従って、Evidenceで利用可能なデータは基本的にParquetに抽出されたデータに限定されます。 よって、標準的なBIツールのようにOn the flyのクエリを動的に送出してリアルタイムなデータを反映させることは出来ません。 従って、そのような要件が含まれる場合にはEvidenceは適切な選択肢ではありません。 従って、ドキュメントの流れまで含めて、アーキテクチャを図示すると以下のような形になります。 動作環境 Evidenceを動作させるためには、以下の環境が必要です。 Node.js: バージョン ≥18.13, 20, または 22 が必要です。初めてインストールする場合は、LTS（長期サポート）バージョンの利用が推奨されています。現在のNode.jsのバージョンはコマンド node -v で確認できます。 NPM (Node Package Manager): バージョン 7 以上が必要です。 Git: Gitがインストールされている必要があります。Gitがインストールされていない場合は、インストールする必要があります。GitHubへの登録も推奨されています。 これらの要件を満たすことで、Evidenceをローカル環境にインストールし、データプロダクトの構築を開始することができます。 現在のNode.jsのバージョンの確認方法 node -v 最新のNode.jsへの更新方法 scoop update nodejs-lts npmのバージョン確認方法 npm -v gitのインストール方法 scoop install git Evidenceのインストール方法 Evidenceには幾つかのインストールパターンがありますが、ダッシュボード開発時にはVisual Studio Codeと専用の拡張機能の利用が推奨されます。 本アーティクルでは、基本的にはScoopで環境構築を行っています。 scoopがインストールされている場合は以下のコマンドでnode.jsやNPMを展開できます。 scoopを利用することで、バージョンの管理、アップデートは容易になります。 scoop install nodejs-lts なお、本アーティクル以降ではVisual Studio Codeでの構築を行っていきますので、Visual Studio CodeにEvidenceの拡張機能を導入してください。 また、これらのインストール中にエラーが生じた場合には、そのステップに応じて、ScoopやVisual Studio Code、Evidenceのドキュメントを参照してください。 システム構成の概要 ダッシュボード開発時の典型的な構成は以下のようになります。 ...

今回はちょっとだけ箸休め的にScoopによる環境構築を多少補足します。 本シリーズでは基本的には、環境構築はScoopを用いることを前提としています。 Scoopはコマンド一つで様々なパッケージを展開可能なツールです。 Scoopは悪い意味ではまっとうなパッケージマネージャではありません。しかし、以下の条件の元では極めて有効に働きます。 You’re a programmer/developer You want to set up a machine without having to visit a bunch of websites, download installers and then click through each one You’re comfortable working on the command line, especially with tools like Git You’re familiar with UNIX tools, and you wish there were more of them on Windows You read Hacker News and you feel like you’re ‘stuck’ on Windows and missing out on lots of cool things You wish there was an easier way to tell other developers how to install programs (maybe your own programs) You use Homebrew/apt-get and think, “this is awesome”. https://github.com/ScoopInstaller/Scoop/wiki/So-What より。 ...