G検定を制度に導入する企業とは｜三菱商事の例から広がりを探る 先日、「三菱商事がG検定を昇格要件に導入した」というニュースを聞いて、以下のような意見記事を書いた。 三菱商事が「G検定」を昇格要件に導入｜AI人材育成の戦略とは？ その後、G検定を何らかの制度に組み込んだ企業は他にもあるか気になり、過去のニュースを調べてみた。以下はその調査結果と、筆者の簡単なコメントである。 清水建設：建設業でもG検定取得を推進（2023年） 清水建設では2019年にAI活用の専門部署「AI推進センター」を創設し、G検定取得を目標とした社内研修を本格的に展開。4年間で研修受講者1,000人、G検定合格者300人以上という成果をあげている。 出典：G検定合格者300人以上を輩出 コメント：技術職に限らず、法務・総務など全社的な参加を促進している点がユニーク。受講者の中からAI活用に手を挙げる社員が現れるなど、社内における「気づき」や変化をもたらす好例といえる。 ソフトバンク：全社員の12％がG検定保持者（2025年） ソフトバンクは、AI人材育成を全社的に推進するため社内研修制度「ソフトバンクユニバーシティ」を中心に多層的な教育体系を構築しており、G検定の取得支援を重視している。2024年度末時点で**G検定合格者は2,200人以上に達し、全社員の約12％**を占める。20代に至っては5人に1人が取得しているとのこと。 出典：社員の8人に1人がG検定合格者 コメント：さすがに大手IT企業ということもあるが、想像よりも桁違いの取得者数であり非常に驚いた。三菱商事に関する意見記事でわたしは、万人が持つべき資格なのが疑問を呈したものの、他企業がこれだけ有資格者を保持していると、地力が全然異なるので、競業他社は追従せざるを得ないのでは？という印象だ。 まとめ：昇格要件はまだ少数派だが、制度化の動きは進行中 ニュースを隈なく調べた訳では無いが、一企業でも桁違いの資格取得者数を輩出している事例があり、企業の取り組みの本気度が窺えた。三菱商事のように、G検定を昇格要件とまでしている企業は珍しいと推測するものの、各社ともに**「AI人材育成」「DX推進」の文脈で、G検定の取得を制度として導入・推奨している事例**は着実に増えている。 企業ごとの導入レベルには温度差があるが、G検定が単なる資格ではなく、組織におけるデジタル基盤形成の指標として見なされ始めているように思える。 今後のニュースもチェックし、事例を追記していきたい。

6割取る学習の是非 試験において、合格基準が「6割」とされていることは多い。たとえば応用情報技術者試験、電験三種、大学の単位認定など、さまざまな分野の試験で「60点以上で合格」という基準が設けられている。この数値を見たとき、多くの受験者がこう考えるだろう。 「じゃあ、6割を目指して学習すればいいんだ」 これは一見合理的な戦略に見える。最小限の努力で最大の成果を得るという発想だ。しかし実際には、この「6割取る学習」は、きわめて危うい戦略である。以下、その理由を述べていく。 点数は常にぶれる 試験というのは、運や環境要因、当日の体調、緊張など、様々な外的要因に左右される。試験本番で「持っている実力のすべてが出せる」人間はごく少数であり、むしろ本番では「実力の8割程度しか出せなかった」と感じる人が大半である。 このとき、**知識として8割を習得していれば、当日の実力が8割しか出なくても、0.8×0.8=0.64で64点となり、6割合格基準を超える。**これはあくまで感覚的なモデルにすぎないが、非常にわかりやすい安全圏の設計方法だと言える。 参考書に書かれる「6割取れ」への違和感 世の中には、「試験は6割取れればいいのだから、6割を目指して効率よく学習しよう」と書いてある参考書や講義が少なくない。しかし筆者にとって、そのような発想は違和感がある。 確かに、全体の学習量を抑えて早く試験勉強を終わらせたいという気持ちは理解できる。実際、「満点を目指して時間切れで全範囲を終えられなかった」という受験者もいるだろう。そうした受験者への反省として、「6割取れればいい」という指導方針が現れたのかもしれない。 しかしながら、「試験範囲全体を学習する」ことは大前提であり、それをやった上で「8割程度を目指す」ことは、むしろ標準的な構えだと考える。 学習量の差はそこまで大きくない 筆者の考えでは、難関資格（弁護士、医師など）を除けば、「6割を目指す」学習と「8割を目指す」学習の間には、せいぜい2〜3割程度の学習量の差しかない。たとえば学習期間が2ヶ月だとしたら、それに+2週間ほどで到達できる範囲である。 その程度の差で「合格の安定性」を買えるのならば、次回の受験まで1年待つリスクと比較しても、明らかに前者のほうが合理的ではないだろうか。 「6割でいい」は甘えか、それとも戦略か？ もちろん、すべての人にとって「8割を目指す学習」が常に正しいとは限らない。人生には時間的・経済的制約があるし、「まずは合格ラインに達すること」を最優先とする戦略もあり得る。 しかし、試験の本質は「知識・技術を身につけたことの証明」である。合格ラインぎりぎりの学習では、試験後の実務や応用に耐えられない可能性がある。 受かるための学習ではなく、合格後に役立つ学習を心がけるならば、なおさら8割を目指す意味は大きい。 資格試験は「戦略ゲーム」のように見えて、実は非常に“誠実さ”を問われる営みだ。合格という結果を安定的に手にするためにも、「6割でいい」ではなく、「8割を取る」という姿勢で取り組むことを、ぜひおすすめしたい。 なお、筆者自身もこの「8割習得」を基本方針としているが、それでもうまくいかないことはある。たとえば知財検定2級はその代表例である。この資格は、そもそも合格基準が8割という非常に厳しい試験であり、筆者は過去問で9割5分正解できる状態まで学習を仕上げたものの、本番では**77.5点（1問2.5点）**を取り、たった1問の差で不合格となってしまった。 このように、「+2割」を目標とする学習には、それ相応の覚悟と精度が求められる。戦略としては妥当でも、現実には困難を伴うこともある——それでもなお、「8割を目指す」という姿勢こそが、長期的な実力の安定に通じる道だと信じている。

Ankiって何？　どうやって使うの？　本当に覚えられるの？──そんな疑問を持った人向けに、この記事では「Ankiの使い方」から、「なぜ続くのか」「どんな効果があるのか」まで、実際に1年近く毎日使い続けてきた視点から紹介する。 Ankiとは？ どんなアプリなのか Ankiは、フラッシュカード形式で記憶の反復を支援する無料アプリである。エビングハウスの忘却曲線に基づき、「復習タイミング」を自動で管理してくれるため、覚えたことを効率よく長期記憶に変えることができる。語学、資格試験、プログラミングなど、あらゆる分野の学習に使われている。 もう覚えられない、と感じたことはないか どれだけ時間をかけて勉強しても、数日後には驚くほど内容を忘れてしまう。そんな経験は、多くの人にあると思う。人間の脳は、放っておくと本当にすぐに忘れてしまう。 自分は昔からそういうのが気になって、大学受験のときに「エビングハウスの忘却曲線」を本で読んで知った。知ったのはいいが、当時はスマホもない時代で、全部手作業で管理しようとしていた。ノートの右上に日付を書いて、「このノートは3日後、7日後、14日後に見返す」みたいなスケジュールを作って、ファイルで管理していた。でも、これがとにかく手間で、しかもやっていても途中で見返し忘れたりして、結局途中でやめてしまった。 今の時代、そんな煩わしいことを自動的にやってくれるツールがある。Ankiだ。 Anki公式サイト 30代からの勉強と、Ankiの効果 他の記事でも、30代になってから資格学習を始めたことを書いたが、大学受験・大学時代の学習から時間が経っており、記憶力の衰えに不安を感じていた。「20代の頃より覚えが悪くなっているかもしれないな」と思いながら、何か補助になるツールはないかと探していてAnkiに出会った。 やはり科学的に理にかなった学習方法というのは効果が凄まじく、さほど苦労せずに記憶の定着化が進んでいる。Ankiを使い始めたのが、2024年7月2日で、現在は2025年5月12日。あと2か月ほどで1年になる。現在のAnkiカード枚数は以下図の通り。効果が目に見えて感じられるので、飽きずに続けられている。 なお、FSRSという新しい復習スケジューラを使ってみた体験記事もある。導入して復習枚数が5000枚に増えたという衝撃の内容である。 FSRSとは何か？　Ankiに入れるとどうなるか？ Ankiの習慣化 今では、朝起きたらAnkiを開いて復習するのが完全に習慣となっている。強制的に学習しなければいけないカード数が表示されているので、翌日にスキップした時のノルマのプレッシャーを感じると、朝に優先してやらなければならないと感じている。これに慣れたら、むしろ復習しないと一日が始まった気がしなくなった。連休のときも「今日はAnkiやらないといけないから、遠出はやめとこうかな……」と思ってしまうくらいで、自分でもちょっと中毒気味だと思っている。 入力が面倒？　でも結局それが一番ラク おそらく、Ankiの使用に一番躊躇う点があるとすれば、いちいちカードを作ってインプットしていく点だろう。自分も最初は面倒に感じた。けれど、やってみると意外と気にならなくなる。むしろその入力作業が学習になっていて、「あとでこれを思い出すときに役に立つな」と思いながらカードを作っている。 大学時代に経験したのは「一夜漬けで乗り切ったけど、半年後にはきれいに忘れている」というパターン。これを何度も繰り返してきた。そういう学び方は、結局将来に残らない。Ankiはそういう“学び捨て”を防いでくれるツールだと思う。 少し手間でも、一度カードを作れば、あとはAnkiがスケジュールを管理してくれる。自分で日付を書いていた頃と比べると、雲泥の差だ。 Ankiは、未来の自分への投資 これからAnkiを使ってみようかなと思っている人には、「とりあえず一週間だけでも使ってみて」と伝えたい。使えばすぐに「これは手放せない」と思うようになるはずだ。 記憶に自信がない、何度やっても覚えられない、でも本気で何かを身につけたい——そう思っている人にこそ、Ankiは向いている。 忘れるのは仕方ない。でも、思い出せる仕組みを持っていれば、それで十分だ。Ankiはその仕組みをくれる、頼もしいアプリだと思っている。

常識で問題を解くことの危うさ 資格試験の勉強法を紹介する本やブログで、時折見かけるアドバイスがある。 「この問題は常識で解ける。だから学習の優先度は低い」 この種のアドバイスは、一見すると合理的に見える。だが、その裏には大きな落とし穴がある。 「常識で解ける問題＝学ばなくていい」は本当か？ たしかに、勉強が苦手な人にとって、すべての問題を一から丁寧に理解するのはハードルが高い。その意味では、「常識で解けるなら、そこは飛ばしてもいい」というアドバイスが成り立つこともある。だが、それはあくまで初心者向け、もしくは「資格を持ってさえいればよい」「内容はぶっちゃけどうでもいい」と考えている人向けの話だ。 専門性を求めたり、学んだことを実務で生かしたいと考えるならば、「常識だから」という理由で学びを止めてしまうのは、非常に危うい態度だと言わざるを得ない。 常識という言葉の曖昧さと危うさ そもそも「常識」という言葉自体が危うい。技術者や専門職であれば、この言葉を安易に使うことのリスクを理解しているはずだ。なぜなら、組織とは多様なバックボーンを持った人間の集まりだからだ。メーカーであれば、機械出身、電気出身、情報出身、化学出身、材料出身など、さまざまな専門家が同じ職場で働いている。 たとえば、「金属組織なんて見分けがついて当然でしょ？」「強電・弱電という言葉も知らないの？」といった発言が、同じ分野出身者同士の会話であれば通用するかもしれない。しかし、異分野の人間に対してそれを求めるのは酷であり、非合理的でもある。 新たな分野を学ぶとは、常識を捨てること 本質的に、学習とは「常識の殻を破る」行為である。自分が持っていた先入観をいったん脇に置き、その分野における新たなスキーム、ルール、論拠を丁寧に学び取ることこそが、学習の本質だ。 にもかかわらず、「これは常識でA！」→「解答を見たら正解してた」→「はい、もうこの問題は解かなくていい」という態度で学びを進めると、一体何のために学習しているのかがわからなくなる。そんな態度で合格できたとしても、それは単なる“試験対策の通過”でしかない。 たとえば宅建の民法でよくあるのが、「先に買った人がかわいそうだから、その人が所有権を得るべき」という“常識”で答えてしまい、登記の対抗要件を無視して誤答するケースだ。実際には、**不動産の権利移転は登記がなければ第三者に対抗できない（民法第177条）**という明確なルールがある。 こうした例では、「常識で答えられたからOK」としてしまうことで、肝心の知識の獲得を避けてしまう点にある。 常識を捨て、論拠に立脚する 学習において大事なのは、論拠を求める態度である。その分野における原理・法則を理解し、細かな条件設定や例外に対しても、適切な判断ができるようになること。それが本来の学びであり、実務や応用の場面でこそ生きてくる。 「常識」という名のアナロジーに頼っているうちは、実は何一つ理解していないに等しい。なぜなら、論拠に基づいた推論ではなく、自分の経験やイメージに頼った“勘”で解いているにすぎないからだ。 さらに言えば、学習を始める前の段階の人（＝一般の人）が、「これは常識でしょ」と豪語し、問題を解けたつもりになってしまう場合、それは将来的に極めて危険な兆候である。なぜなら、もしその人がそのまま専門家として開業した場合、「一般の人」と同じレベルの判断しか下せないことになる。そんな専門家が本当に社会に必要だろうか？ それこそ、生成AIやルールベースの自動化に簡単に置き換えられる人材ではないだろうか？ まとめ：理解の深度こそが武器になる 常識で解けたとしても、それがなぜ正解なのかを考えること。その積み重ねこそが、専門家としての地力を育てる。 「常識で解けるから飛ばしていい」という言葉を見たときは、それが誰に向けた言葉かを考えたい。そして、自分が本当に目指しているものは“合格”か“理解”か、自分自身に問い直すことから始めてみてほしい。

2025年機械系資格カレンダー 2025年に実施される/された、主要な機械系資格試験のスケジュールをまとめた。機械系資格一覧については、以下記事でもまとめてある。 機械系資格一覧 電気系資格（電験三種・電気工事士）にも興味がある方は、以下を参照のこと。 2025年電気系資格カレンダー 資格別スケジュール詳細 計算力学技術者(固体力学/熱流体力学/振動) 1級 【実施日】未公表(2024年は11月29日) 【申込期間】未公表(2024年は7月23日～8月8日) 【主催】日本機械学会 【形式】CBT 計算力学技術者(固体力学) 2級 【実施日】未公表(2024年は12月6日) 【申込期間】未公表(2024年は7月23日～8月8日) 【主催】日本機械学会 【形式】CBT 計算力学技術者(熱流体力学/振動) 2級 【実施日】未公表(2024年は12月5日) 【申込期間】未公表(2024年は7月23日～8月8日) 【主催】日本機械学会 【形式】CBT 2次元CAD利用技術者 1級(機械) 【実施日】前期：6月15日、後期：11月9日 【申込期間】前記：4月7日～5月8日、後期：8月18日～9月18日 【主催】コンピュータ教育振興協会 【形式】実技+筆記 2次元CAD利用技術者 2級 【実施日】随時実施(申し込み時に任意選択) 【申込期間】随時 【主催】コンピュータ教育振興協会 【形式】CBT 3次元CAD利用技術者試験 1級/準1級 【実施日】前期：7月20日、後期：12月7日 【申込期間】前記：5月9日～6月12日、後期：9月29日～10月30日 【主催】コンピュータ教育振興協会 【形式】実技+筆記 3次元CAD利用技術者試験 2級 【実施日】随時実施(申し込み時に任意選択) 【申込期間】随時 【主催】コンピュータ教育振興協会 【形式】CBT QC検定 1級/2級 【実施日】9月28日 【申込期間】6月2日～7月18日 【主催】日本規格協会グループ 【形式】筆記 QC検定 3級/4級 【実施日】6月23日～9月28日 【申込期間】5月8日～8月24日 【主催】日本規格協会グループ 【形式】CBT

MarkdownユーザーがAsciidocを試してみた｜使いやすさ・欠点・移行の所感 この記事でわかること MarkdownとAsciidocの主な違い Asciidocを使って感じたメリット・デメリット 実際の使用例と学習コストの印象 Markdownからの移行はおすすめできるのか？ Markdownの限界 Markdownで記事をずっと書いてきたが、そろそろ限界を感じていた。ルビが振れない。表が書きにくい。数式が表示できない。…そんな中で見つけたのが「Asciidoc」だった。 はじめは軽い気持ちだった。「ちょっと試してみるか」程度で始めたものの、いざ書き始めてみると、予想以上にしっくりきた。「これ、最初からこっちで書いていればよかったのでは？」とすら感じるほどだった。Asciidocの思想は、“なんとなく書ける”Markdownとは違い、“最初から構造的に書く”という方向に向いている。 使い慣れているMarkdownと比べて何がどう違い、どこに惹かれたのかを、ここに記録しておく。 MarkdownからAsciidocに興味を持った理由 Markdownは軽量で便利だが、「構造化された長文」を扱うには力不足だと感じるようになった。特に以下の点で不満があった： 表記の自由度が低い（脚注・ルビ・図番号など） 表が複雑になると地獄（パイプ区切りの視認性） 数式を書こうとするとKaTeXやMathJax頼りで面倒 ファイル構造やテンプレートとの連携に限界がある そんな中で「Asciidocは本格的な技術ドキュメントのために作られた」「見出し構造や属性が自然」「PDFやHTML、EPUBにも出力可能」といった紹介を見て、試してみたくなった。 各記法の詳細等は、Qiitaなどで調べればいくらでも出てくるので割愛するが、以下に実際に使ってみて感じたことを記す。 Asciidocを使って感じた4つのメリット 1. 見出しやリストのネストが、MediaWiki記法に近い Asciidocでの記法 == 見出し * 箇条書き ** ネスト1 *** ネスト2 Markdownのように見出しに#を使うか、asciidocのように=を使うかは、単なるルールの違いのため、どちらが良いとは言えないが、個人的にWikipediaなどのMediaWiki記法には馴染みがあるため、asciidocのように見出しに=を使うというのは、書く上で慣れていて嬉しい。逆に、MediaWiki記法に慣れた状態から、初めてMarkdownを触ったときは、#を使うのに戸惑ったくらいだ。 箇条書き及びネストについては、asciidocの仕様はMediaWiki記法そのものである。個人的にMarkdownのネストの仕様は好きでは無かった。Markdownでは、箇条書きをネストする場合、以下のように空白文字でインデントする必要がある。空白文字でのコントロールは視認性に劣ると感じている。 Markdownでの記法 * 箇条書き * ネスト1 * ネスト2 2. テーブルがCSV形式で書ける Asciidocでの記法 [format="csv", opstions="header"] |====== a, b, c 1, 2, 3 4, 5, 6 |====== csv形式で書けるのが地味に嬉しい。行数・列数が一目瞭然である。以下のようなMarkdownでの記法も悪い訳では無いが、どのパイプ文字「|」の内側にいるかを意識しないと、プログラミング言語における括弧閉じ忘れのように、意図しない挙動になりがちだ。 Markdownでの記法 |a |b |c | |---|---|---| |1 |2 |3 | |4 |5 |6 | 3. ルビが振れる Asciidocでの記法 ...

GitHub Flavored Markdown（GFM）とは？ Markdown方言の全体像については以下の記事を参照のこと。 Markdown方言の全体像 GFMとは何か？ GFM（GitHub Flavored Markdown）は、GitHubが開発・採用しているMarkdownの方言である。。GitHub上でのREADMEやIssue、Wikiなどに使われている形式で、CommonMarkをベースに以下のような拡張機能が加わっている。 CommonMarkでできること・できないこと 以下は、同一のMarkdown文書をCommonMarkとGitHub Flavored Markdown（GFM）でレンダリングした比較画像である。細かな違いが視覚的に理解できる。純粋なCommonMarkと比べて、基本的な整形記法に対応しており、現実的に使える方言として活用できる（純粋なCommonMarkでは表はチェックリストすら未対応）。 なお、この比較ツールの実装については以下記事に記してある。 Markdown方言比較ツールの紹介と公開 GFMでの追加機能一覧 GFMがサポートしている主な機能を以下表に示す。 機能 GFMでの対応 サンプル記法 表（table） ✅ 対応 ` ——– —- 内容1 内容2 ` チェックボックス ✅ 対応 - [x] 済み - [ ] 未完了 行内コード ✅ 対応 コード シンタックスハイライト ✅ 対応 python\nprint("hi")\n 自動リンク（URL） ✅ 対応 https://example.com → 自動リンク 打ち消し線 ✅ 対応 ~~打ち消し~~ → 打ち消し @メンション ✅ 対応 @username SHA, Issue番号 ✅ 対応 #123, deadbeef（リンク化） タスクリスト ✅ 対応 - [ ] task HTMLタグ ✅ 部分対応 セキュリティ上、制限あり 結論：なぜGFMは実用で好まれるのか？ 表やチェックリスト、コードハイライトなど、日常的なドキュメントに便利な機能が揃っている GitHubという大規模なプラットフォームでの利用により、事実上の業界標準となっている Markdownの方言による違いが気になる場合は、より厳密な構造記述が可能な Asciidoc の導入も検討する価値がある。 ...

Markdown方言比較ツールの紹介と公開 なぜこのツールを作ったのか 軽量マークアップ言語であるMarkdownは、記法について覚えることが少なく気軽に書けるため、ちょっとしたメモから、手順書等のドキュメント、スクリプトのREADME.md等を書くのに重宝している。しかし、以下記事で取り上げたように、実はMarkdownには各種方言があり、実行環境によっては特定の記法が使えないなどの落とし穴がある。 Markdown方言の全体像 そこで上記記事では、代表的な方言である、CommonMarkとGitHub Flavored Markdownを取り上げ、以下図のように比較した。この比較画像を作成する際、HTML+JavaScriptにてちょっとした比較ツールを作成したのだが、1回使ってお蔵入りするのも勿体無いと感じたので、ソースコードを公開することにする。 使い方 この比較スクリプトは、Markdownを異なるレンダリングエンジンで表示した結果を並べて比較できる、ローカル実行型のHTMLツールである。 主な表示内容は以下の3つである： Raw Markdown：入力したMarkdownソース Whitespace Annotated：空白・改行を記号で可視化したもの（スペース=␣、改行=↵） CommonMark / GFM Rendering：2つのエンジン（CommonMarkとGitHub Flavored Markdown）による表示結果 1. ファイルの準備 記事内に掲載されたHTMLコードをコピーし、任意のファイル名（例：compare.html）で保存する。 2. 実行方法 保存したHTMLファイルをWebブラウザで開くと、自動的にツールが起動する。 ※このツールはJavaScriptを使用しており、ライブラリをCDN経由で読み込むため、インターネット接続が必要である。 3. 使用手順 左側のテキストエリアに比較したいMarkdown文書を入力する。 入力に応じて、以下の3カラムがリアルタイムに更新される： Whitespace Annotated：スペースと改行を可視化（整形トラブルの特定に有用） CommonMark Rendering：CommonMark仕様による出力 GFM Rendering：GitHub Flavored Markdownによる出力 4. 例 以下のようなMarkdownを入力すると： # 見出し - リスト - ネスト これは~~打ち消し線~~である - [x] 完了 - [ ] 未完了 GFMとCommonMarkの挙動の違い（チェックボックスの描画、打ち消し線の有無など）が視覚的に確認できる。 5. ライセンス MITライセンス 6. 補足事項 ※本ツールでは、JavaScriptライブラリをCDN（jsDelivr）経由で読み込んでいる。信頼性の高いCDNを使用しており、通常の使用においてはセキュリティ上の問題はほぼないが、気になる場合はローカルにライブラリをダウンロードして使用することもできる。 ...

Markdown方言のCommonMarkとは何か？ Markdown方言の全体像については以下の記事を参照のこと。 Markdown方言の全体像 CommonMarkとは何か？ CommonMarkは、Markdownの明確な仕様と互換性を持たせることを目的とした標準化プロジェクトである（2014年発足）。このため、これを方言と表現するのは正確では無いが、利用者からすれば、「結局また新たな仕様が派生した」ように見えるので、便宜的に方言として扱う。 曖昧な記法を厳格に定義 公式のテストスイートと仕様書（https://spec.commonmark.org） 実装ごとの差異を減らすことを目指す CommonMarkでできること・できないこと 以下は、同一のMarkdown文書をCommonMarkとGitHub Flavored Markdown（GFM）でレンダリングした比較画像である。細かな違いが視覚的に理解できる。 なお、この比較ツールの実装については以下記事に記してある。 Markdown方言比較ツールの紹介と公開 CommonMarkがサポートしている主な機能と、未対応の機能を以下表に示す。 機能 CommonMarkでの対応 サンプル記法 見出し ✅ 対応 ## 見出し2 段落・改行 ✅ 対応 行末に2スペース / 空行 強調（太字・斜体） ✅ 対応 **太字**, *斜体* リスト ✅ 対応 - アイテム, 1. 番号付き コード ✅ 対応 インライン: code / ブロック: code リンク・画像 ✅ 対応 [Google](https://...) 引用 ✅ 対応 > 引用文 区切り線 ✅ 対応 ---, *** 表 ❌ 非対応 ※構文上は書けてもHTMLには変換されない チェックボックス ❌ 非対応 - [ ] タスク 脚注 ❌ 非対応 [^1] 比較の準備：次回以降の方針 CommonMarkは、Markdownの「共通語」として各方言との比較の基準に使える。 ...

Markdown方言の全体像 本記事を書こうと思ったきっかけ Markdownの記法について調べようとして、いわゆる「記法一覧」記事を参考にすることがある。しかし、それらの多くはどのMarkdown方言を前提にしているのかが明記されておらず、いざ自分の使っている環境で試すと、思ったように表示されない、ということが何度かあった。 おそらく、記事を書いた側も「方言があること」を十分に認識しておらず、自分の使っているツールの仕様を“Markdownの標準”だと誤解しているのかもしれない。 こうした経験から、Markdownには複数の方言があり、それぞれに対応する記法と環境があることを整理し直したいと考え、このシリーズを書くことにした。 はじめに Markdownは「軽量マークアップ言語」として広く使われており、シンプルな記法で文書を整形できることから、ブログ・技術文書・ドキュメント・ノートアプリなどで広く採用されている。しかし、Markdownには正式な標準が長らく存在せず、上述の通り、各ツール・サービスごとに**微妙に異なる記法の“方言（ダイアレクト）”**が存在している。 なぜ方言が生まれたのか Markdownには元々厳密な仕様がなかった（2004年にJohn Gruberが提案したが、仕様書は曖昧） ツールやWebサービスが独自に拡張して便利機能を追加（例：チェックリスト、表、脚注など） この結果、「どのMarkdown環境で、何が書けるのか」が分かりにくくなった 代表的なMarkdown方言と特徴 方言名 主な特徴 CommonMark Markdownの厳密仕様を定義した“標準化”プロジェクト。拡張なし。 GFM（GitHub Flavored Markdown） CommonMarkベースに表・チェックボックス・打ち消し線などの拡張あり Obsidian Markdown CommonMarkベース＋内部リンク、脚注、YAML frontmatter等の拡張 Pandoc Markdown 脚注、数式、フィルターなど高機能・LaTeX出力向け 比較の一例：CommonMark vs GitHub Flavored Markdown 以下がCommonMarkとGitHub Flavored Markdownを比較した結果のスクリーンショットだ。 なお、この検証用に作成した比較ツールは、以下記事で公開している。 Markdown方言比較ツールの紹介と公開 違いが生じた箇所を表にまとめると、以下になる。 表現 CommonMark GitHub Flavored Markdown チェックボックス ❌ 表示されない ✅ <input type="checkbox">に変換される 表 ❌ 表示されない ✅ <table>として表示 打ち消し線 ❌ ~~text~~は無視 ✅ <del>タグとして解釈 このように、書いたMarkdownがどの環境でどう見えるかは“方言”に依存している。 各アプリの採用方言まとめ アプリ・サービス 採用方言 備考 GitHub GFM 表、チェックボックス、打ち消し線に対応 Obsidian Obsidian独自 脚注、内部リンク、YAML frontmatterなど拡張多数 Typora Pandoc風 数式・脚注・LaTeX出力に強い Zenn GFMベース＋独自 @[toc] やKaTeX数式サポートなど Qiita GFMベース＋拡張 TOC・絵文字・Mermaid対応など独自性あり StackEdit GFM互換＋MathJax 表示力が高いWebエディタ 今後の記事構成 本記事は概要まとめとして、次の各記事で以下の方言を詳しく紹介していく予定だ。 ...