Grayrecord Technow

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を扱います。 ...

会社のメールボックスに届いたメールを見ていて、おかしなものを見つけてしまいました。Vivaldiの表示を見ると一年後になってる。そして、それ以外にもいろいろとおかしなところがある。 「 見どころ 」ポイント Dateヘッダーの怪 : 未来(2027年)からの送信と言う、メーラのソート順をかき乱す禁じ手。 alt属性の罠: 画像ブロック機能によって、隠していた「 2年前の使い回し 」が露呈する恐怖。 Vivaldiのプライバシー保護機能（画像読み込みブロック）が、図らずも企業の怠慢を暴き出すデバッガーとして機能してしまった瞬間です。 タイムトラベルするDateヘッダー まず、Date ヘッダーが 2027年 になっている点です。現在は2026年1月。 これをやられると、常にメーラーのリスト最上部にこのメールが居座ることになります。スパム業者がよくやる手口ですが、まさかテック企業を名乗る会社のニュースレターでこれを見るとは思いませんでした。 送信サーバーの設定ミスなのか、テンプレートの更新忘れなのかは不明ですが、受信者の体験を著しく損ねています。 alt属性に刻まれた「2024」の真実 そしてさらに衝撃的だったのが、画像の alt 属性（代替テキスト）です。 画像が表示されない状態でそこにあったのは、「 2024年賀状 」という文字。 2026年の正月に、2027年の日付で、2024年の挨拶が届く。 これが意味することは単純です。 「2年前のHTMLメールのテンプレートをコピーして、画像だけ差し替えて送信した」ということです。 画像のリンク先や src は変えたものの、目に見えない alt 属性の書き換えを怠ったのでしょう。 表面しか見ない「テック」企業 こういうことをやってしまうと、信頼性に大きな傷がつきます。 アクセシビリティの軽視: alt 属性は画像が見えない人（視覚障害者や、通信環境が悪い人、画像をブロックしている人）のための重要な情報です。そこに嘘（2年前の情報）を書くということは、そういったユーザーを切り捨てていると言っても過言ではありません。 技術力の欠如: 自動化されたテストや、送信前の基本的なQA（品質保証）プロセスが存在しない、あるいは機能していないことを露呈しています。 ブランドへのダメージ: 「表面の見た目（HTML画像）さえ整えれば中身（Dateやalt）はどうでもいい」という姿勢は、製品やサービスの品質そのものを疑わせます。 正直、がっくり来ました。営業メールだとしても、技術を売りにする企業からこんなものが届くと、武士の情けで社名は出しませんが、その会社の技術力もお里が知れるというものです。正月早々に開いた口がふさがりません。 教訓: メールの送信ボタンを押す前に、必ずテキストのみのモードや画像オフのモードでプレビューしましょう。そこには、あなたが隠したつもりの「恥」が残っているかもしれません。

図書館から、『Gemini完全マニュアル』を借りてきました。前から、予約リストに放り込んであったのですが、順番が来たので。そして、借りてきて秀和システムのロゴを見た瞬間に思いました。あ、これ、秀和システムの遺品だって。 基本的には、「できる」のような類の普通の解説本ですね。 3章までの目次は以下のようになっています。 1章 Geminiとは 2章 Geminiをはじめる 3章文章を編集する 文章を要約する 長い文章を箇条書きにする 文章からQ&Aを作成する 長い文章を表にまとめる 箇条書きのメモから議事録を作成する -文章の難易度を変える など その意味では、割と普通の本です。JulesとかNotebook LMとかにも特に触れていません。しいて言うと、Gemini Advancedとなっているのが、時の流れを感じますね。 今となっては、歴史書というか、Gemini 1.0というのがもう時間がたっていますね。 そういえば、こんなだったねという感じですね。

AIモデルの性能評価や、新しいアルゴリズム（例えば以前取り上げたSVG: Support Vector Generationなど）の実験において、適切なデータセットの選定は極めて重要です。今回は、私がソフトウェアエンジニアリング領域の自然言語処理（NLP）タスクでベンチマークとして愛用している「PROMISE Dataset」について、その構造とAIモデルでの活用実験の経験を交えて紹介します。 PROMISE Datasetとは 私がよく利用しているのは、Software-Requirements-Classification リポジトリに含まれている PROMISE.CSV です。 元々は PROMISE Software Engineering Repository で公開されていたもので、ソフトウェア要件定義書のテキストデータと、それが「機能要件」か「非機能要件」か、さらに細かい分類ラベルが付与されたデータセットです。 データの構造とクラス定義 このデータセットは主に以下の構成になっています。 Project ID: プロジェクトの識別子 Requirement Text: 要件のテキスト（例: “The system shall refresh the display every 60 seconds."） Class: 要件の分類クラス クラス分類は以下の4つが主要なラベルとして使用されています。これらは要件エンジニアリングにおける古典的な分類に基づいています。 F (Functional Requirement): 機能要件。システムが「何を」するか。 PE (Performance): 性能要件。非機能要件の一種。 LF (Look-and-Feel): 外観・操作感。UI/UXに関わる非機能要件。 US (Usability): 使用性。使いやすさに関わる非機能要件。 graph TD Req[Software Requirement] Req --> F[Functional (F)] Req --> NF[Non-Functional] NF --> PE[Performance (PE)] NF --> LF[Look-and-Feel (LF)] NF --> US[Usability (US)] NF --> Other[Other NFRs...] AIモデルによる実験：LLM vs SVG 私はこのデータセットを用いて、いくつかのAIモデルのアプローチを試みてきました。 ...

BLOGのアーティクルにOGPイメージは必要と思えたので、Hugo の OGP 画像を自動生成できる「tcardgen」を試したを参考にしています。実際、yamlの設定などは全く同じですし。違うとすれば、Windows環境なのでスクリプトをCMDのバッチファイルにしているくらいですね。 使用しているスクリプトはcovergen.batいう名前で内容は以下の通りの簡単なものです。 tcardgen -f tcardgen\fonts\ -o static\images\ogp\ -t tcardgen\template.png %1 OGP画像の配置先とか、そんなくらいですね、違うのは。テンプレートの画像は適当に作ったものです。