Posts

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エディタ 今後の記事構成 本記事は概要まとめとして、次の各記事で以下の方言を詳しく紹介していく予定だ。 ...

Typoraのすすめ .txtから.mdへの転換 私はもともと、仕事でもプライベートでも、メモを残す手段としてテキストファイルを多用していた。世の中にはWordでメモを取る人もいるが、あれはまったく性に合わなかった。Wordファイルはプラットフォームに依存し、ファイルは余計なデータで重く、テキストエディタで開こうとすればバイナリ表示になってしまう。しかもバージョンが違えば互換性も怪しい。 そういった理由から、私は軽くてシンプルなテキストファイルでのメモ運用を続けていた。ただ、やはり文字の強調や階層構造といった、最低限の装飾表現が欲しくなり、テキストエディタでそのまま読めるフォーマットとしてMarkdownにたどり着いた。覚える記法も少なく、すぐに馴染めた。 VS Code重すぎ問題とTyporaとの出会い ところが、Markdownを書くためにVS Codeなどの統合開発環境を使うと、機能が多すぎて書くことに集中できない。2ペイン構成も仰々しく、軽快にメモを取りたい私には合わなかった。テキストエディタに近い感触のMarkdownエディタを探していた時に出会ったのが、Typoraだった。 Typoraは、何よりもそのシンプルさに惹かれた。画面は1ペインで、書いているMarkdownがその場で即座にレンダリングされる。以下の画像からも分かるように、編集画面とプレビュー画面が一体化しており、視線移動やモード切替の必要がない。文書を構造的に書きながら、常に整った見た目を確認できるのが最大の利点だ。 ちなみにCtrl+/を押すと、以下画像のようにレンダリング表示が一時的にオフになり、純粋なMarkdown記法がそのまま見える編集モードになる。構文の確認や、細かな記述の修正をしたいときには便利な機能だ。通常の「書く→見る」の切替と違って、同じペインでモードを切り替えられる点が、Typoraならではの洗練された体験を支えている。 メモだけで終わらない：実用的な文書出力 用途としてはメモが中心だが、それにとどまらない。Markdownでそのまま技術文書やドキュメントを書き、TyporaからPDF・HTML・EPUBなどに美しくエクスポートできるのも魅力だ。見た目も整い、軽量で、実用と美しさが両立する文書を誰でも作れる。PDF出力したサンプルを以下に示す。 📄 PDF出力されたサンプル Typoraは高コスパの買い切り型エディタ Typoraは14.99＄と有料だが、これで永続ライセンスである。今後も妙なエディタでストレスを抱えながら書き続けるくらいなら、この一度の投資で済ませる方が合理的だ。安い。 誰に勧めたいかと問われれば、すべての「文章を書く人」だ。特に、技術文書を書く開発者、知識管理をMarkdownで行う人、日々の記録を手軽に残したい人には強く推せる。 🌐 公式サイト：typora.io シンプルなUIと軽快な動作、そして買い切りライセンス。公式ページから詳細な情報やスクリーンショットも見られるので、気になったらぜひ覗いてみてほしい。 Typoraへの唯一の要望：Asciidoc対応 不満はほとんどないが、強いて言えばMarkdown自体の限界は感じている。Markdownにはプラットフォームごとの方言が多く、また標準機能が貧弱なため、カスタム拡張で乱立しているのが現状だ。その点、Asciidocのようなより強力な記法に興味はあるものの、Typoraのように1ペインで快適に使えるAsciidocエディタがないため、移行をためらっている。TyporaがAsciidocにも対応してくれたら、それが唯一の要望だ。 書くことに集中できる数少ないエディタ 優れた道具は手になじむ。それだけではなく、使っていること自体が誇らしくなる。──Typoraはまさにそんな道具だ。 Typoraは「余計なものがない」ことを美徳としながらも、実用性は非常に高い稀有なツールである。文章を書くこと自体を快適にしてくれるこのエディタは、私の思考と記録の中核に今や欠かせない存在となっている。

「資格？意味あるの？」と言われ続けて──機械系現場で資格が軽視される理由 「資格は意味がない」──それが機械系の現場 機械設計の現場では、資格が軽視される傾向が根強い。たとえば、CAD試験などの設計系資格を取得している人は実際には少なく、「そんなの意味ないよ」「今さらそんな初歩的なものを取ってどうするの？」といった反応が返ってくることが珍しくない。 しかも、こうした言葉を発するのは多くの場合、その資格を持っていない人たちである。そして、口を揃えて言うのが「現場の実務が一番の学びだ」という理屈。これはある種の経験至上主義であり、機械系現場において広く共有されている価値観だ。 このような環境では、若手技術者が自ら学び直そうとしても、それを「遠回り」や「効率が悪い」と一蹴されてしまうことすらある。結果として、職場全体としての知識の更新が進まないという“停滞”を生む要因にもなっている。 なぜここまで資格が軽視されるのか？ その背景には、設計資格の歴史的な設計思想があると考えられる。かつて「設計資格」といえば、建築系・電気系・機械系を一括りにして扱っていた時代があり、試験内容も建築寄りの要素が強かった。機械設計者が資格（特に以下の資格）を取ろうとしても「建築ばかりで意味がない」と感じ、自然と距離を置くようになった──そうした歴史的経緯がある。 2次元CAD利用技術者 3次元CAD利用技術者 機械・プラント製図技能士 さらに現場では、上記資格を取っているCADオペレーターなどに対しても「資格を持っている人の方がかえって厄介」という印象すら存在した。理由は「建築CADに染まっていて、機械系CADを教え直すのが手間」というものであり、資格があることがむしろ“悪目立ち”になる空気もあった。 また、現場の先輩たちが資格を通じた学びを経験していないという事実も、軽視の温床となる。資格の価値を知らないままキャリアを築いてきた世代にとって、それは「今さら必要ないもの」と映るのかもしれない。 それでも自分は、資格を取る そのような環境にあっても、私はあえて資格を取得し続けている。その理由は大きく二つある。 一つは、外部的な評価の必要性を感じたからだ。今の職場では評価されなくても、他所では通用する“ものさし”が欲しかった。そしてもう一つは、独学や現場経験だけでは、どうしても知識に穴があると感じたからだ。 実際に資格取得の学習を通じて、過去に「なぜこうするのか？」と疑問に感じていたことが理論的に理解できるようになり、現場での応用力も高まった。資格学習は単なる暗記ではなく、自分の仕事を“構造的に見直す”きっかけを与えてくれるものだった。 また、体系的に学ぶことで、他人との議論にも強くなれる。「感覚」ではなく「根拠」をもって話すことができるようになると、設計レビューなどでも一目置かれる場面が増えてきた。 学び続ける理由──教える立場になるからこそ そして今、私は「人に教える側」に立ちつつある。そこで痛感したのは、「自己流」だけでは教えきれないということだ。自分の経験だけで話していては、再現性のある指導ができない。誰にでも通じる“体系だった知識”の重要性を感じている。 新人や若手に教える際、資格試験の出題範囲に沿って説明すれば、共通言語ができ、指導のブレも少なくなる。これは自分自身が経験で学んできたことを、よりよい形で次世代に伝えるための土台となる。 だからこそ、私はこれからも資格を取り続ける。現場では軽視されがちな資格だが、それを支える体系知こそが、未来の技術者育成の土台になると信じている。

三菱商事が「G検定」を昇格要件に導入｜AI人材育成の戦略とは？ このページでわかること 三菱商事がG検定を昇格要件にした背景 G検定とは何か？　難易度や対象範囲 導入の現実性と他社への波及可能性 技術者視点からの評価と懸念点 驚きのニュース──「AI検定」が昇格要件？ 三菱商事が「G検定」を昇格要件に導入するというニュースが飛び込んできた。筆者が最初にこの話を聞いたとき、「AI検定とは何だろう？」と素朴な疑問を持ち、調べてみたところ、それは一般社団法人日本ディープラーニング協会（JDLA）が実施する「G検定（ジェネラリスト検定）」であることが分かった。 G検定は、これまでデータサイエンティストやAI開発者のための専門的な知識を測る試験として知られており、「一般社員が対象になるのか？」と疑問を抱いたのが正直なところだった。 G検定の内容とそのハードル 実際にG検定の出題範囲を見てみると、統計学、ニューラルネットワーク、教師あり学習・教師なし学習、強化学習、自然言語処理といった、AI理論の根幹に関わる分野が並んでいる。生成AIの登場により、プロンプトエンジニアリングのような実用的なスキルが徐々に一般にも広まりつつあるが、G検定は依然として理論重視であり、初学者には決して易しい試験ではない。 そのため、「これを一般社員の昇格要件にするのは厳しいのではないか」と感じた。 超大手だからこそ可能な導入？ ただし、その導入企業が三菱商事である点は重要だ。高年収・高学歴の社員が多く在籍し、もともと能力の高い人材が集まる環境であれば、G検定レベルの知識を昇格要件とすることも、ある程度合理的であるとも考えられる。 一方で、筆者が勤務するような技術系メーカーであっても、中高年層を中心にG検定の取得はハードルが高いと感じる。全社的な導入は、慎重な判断が必要だ。 他社への波及はあるのか？ AIリテラシーの底上げは多くの企業にとって急務だが、G検定のように理論に寄った試験を導入する企業がどれほど増えるかには疑問が残る。むしろ、今後はプロンプトスキルや実用的な生成AI活用法の方が重視される傾向が強まると考えられる。 企業によっては、話題性や経営層の思い付きでG検定を制度に組み込む動きが出るかもしれないが、実務との乖離が表面化すれば、数年のうちに撤回される可能性も高い。 ※（追記）なお、実際にG検定を制度として導入している他社の事例について、別記事でまとめてみた。筆者の懐疑的な視点とは異なり、大企業にて導入の広がりを前向きに捉えていた。 G検定を制度に導入する企業とは｜三菱商事の例から広がりを探る 技術者の視点から見たG検定 筆者自身はエンジニアとしての立場から、G検定の内容に対して一定の関心と理解があるため、受験には前向きだ。理論的な背景を知っておくことは、現場での応用や判断力にもつながるからだ。 しかし、それは技術職であるからこその視点であり、非技術系の社員に一律に求めるにはやはり無理があるだろう。昇格要件として運用するならば、選択制や補完的な研修制度との組み合わせが望ましい。 結論──AIリテラシー教育に必要なバランス感覚 G検定の導入は、AIリテラシー向上に向けた先進的な取り組みである一方、その運用には慎重な設計が必要である。知識の深さと実用性、理論と現場感覚のバランスを取りながら、より多くのビジネスパーソンが無理なくAIと付き合える土壌を作ることが、これからの企業に求められる姿だ。 そういえば、10数年前はTOEICの点数を昇格要件として課す企業が流行りのように増えた覚えがある。楽天がその代表で、その後も楽天は英語能力の高さについての噂は継続的に聞く。当時、それに追従しただけの企業は、さて、その制度を今も残しており、ビジネスに活用できている企業がどれほどあるだろうか？

情報処理安全確保支援士の罰則は重すぎる？｜他士業との比較と検証 はじめに｜罰則がある資格って怖くない？ 情報処理安全確保支援士（登録セキスペ）には、守秘義務違反に対して「懲役または罰金」の罰則がある。 この点を不安視する声もあるが、他の士業や法律と比べて特段厳しいわけではない。 本記事では、支援士に課される罰則の内容とその背景、他制度との比較を通じて、登録の可否を判断するための視点を整理する。 情報処理安全確保支援士とは 情報処理推進機構（IPA）が認定する国家資格には、ITパスポート・基本情報技術者・応用情報技術者などがある。これらの資格は難易度としてスキルレベルが設定されており、ITパスポートはスキルレベル1、基本情報技術者はスキルレベル2、応用情報技術者はスキルレベル3と区分されている。 ※情報処理推進機構（IPA）より引用 この区分の中で、最高難易度のスキルレベル4に設定されている資格の一つが、情報処理安全確保支援士試験である。他のスキルレベル4の試験とは異なり、登録制がある、士業として名乗れるなど、いくつかの特殊性がある。その一つとして法律上罰則が規定されており、インターネット上でもこの罰則についてネガティブな意見が散見されるため、罰則について詳細に検証する。 なぜ罰則が話題になるのか？ 「懲役」や「罰金」という言葉はインパクトがあり、ネット上でも支援士資格のリスクとして強調されがちである。 特に「独占業務がないのに罰則だけある」という誤解が、不安を助長しているようだ。 情報処理安全確保支援士の罰則について まずは該当の法律について、原文を引用する。 情報処理の促進に関する法律　第25条（秘密保持義務） 情報処理安全確保支援士は、正当な理由がなく、その業務に関して知り得た秘密を漏らし、又は盗用してはならない。情報処理安全確保支援士でなくなつた後においても、同様とする。 ここだけ読むと（少なくとも前文は）「まあ、常識だろう」という印象だが、問題は次である。 情報処理の促進に関する法律　第59条 第25条の規定に違反した者は、一年以下の懲役又は五十万円以下の罰金に処する。 何やら懲役・罰金などという、物々しい文言が書かれている。 不安の声の実例 この条文に対して、インターネット上ではネガティブな意見が散見される（以下引用）。 情報セキュリティという特性上、企業機密や営業機密に触れないことはないため、たとえ重過失だとしても罰則を受ける可能性があるのは大きなリスクとなります。（中略）独占業務がない状況下でリスクのみ抱えるのはセキュリティの専門家としてリスク受容できかねる 出典：https://zenn.dev/tk88e/articles/123b6090cdcfe6 より引用 資格を持つデメリットがある（中略）情報処理安全確保支援士には罰則があり、罰金刑・懲役刑を受ける可能性があります。秘密保持義務違反などを行った場合、有資格であるために刑罰に処される場合があります。 出典：https://qiita.com/Umazular/items/f656dff9a10f9f3c94ad より引用 これらの例では、情報処理安全確保支援士にせっかく合格・登録した専門家が、罰則を理由に自ら登録削除を申し出るという事態にまで至っている。 他の法律・資格と比較した罰則 不正競争防止法　第21条 次の各号のいずれかに該当する場合には、当該違反行為をした者は、十年以下の懲役若しくは二千万円以下の罰金に処し、又はこれを併科する。 「次の各号のいずれかに該当する場合」は煩雑なので省略するが（ここでは秘密漏示した場合と理解してほしい）、注目すべきは「十年以下の懲役若しくは二千万円以下の罰金に処し、又はこれを併科する」という箇所である。明らかに情報処理安全確保支援士の罰則よりも厳しい。 その他士業の秘密保持義務との比較 医師、弁護士、弁理士、行政書士、税理士、公認会計士など、「士業」の名前が付くものについては、詳細は別記事に秘密保持義務をまとめてある。 各士業の守秘義務一覧 結論：情報処理安全確保支援士の罰則は特段厳しいわけではない 情報処理安全確保支援士の守秘義務違反には、**「1年以下の懲役または50万円以下の罰金」**という刑罰が規定されている。 この罰則を見て「怖いから登録しない」と感じる人もいるかもしれないが、他の専門職と比較すると、必ずしも特段厳しいとは言えない。 他制度との比較 資格・制度 罰則内容 情報処理安全確保支援士 1年以下の懲役 or 50万円以下の罰金 医師・弁護士など（刑法） 6か月以下の懲役 or 10万円以下の罰金 行政書士 1年以下の懲役 or 50万円以下の罰金 弁理士 1年以下の懲役 or 100万円以下の罰金 不正競争防止法違反（営業秘密漏洩） 10年以下の懲役 or 2,000万円以下の罰金 想定される質問（FAQ） Q. 支援士資格を持っているだけで逮捕される可能性がある？ A. ない。守秘義務違反がなければ問題なく、業務の範囲や注意点を理解していれば十分対応可能である。 ...

各士業の守秘義務一覧 情報処理安全確保支援士の罰則に関する以下記事を作成した際、他の士業についても、同程度の罰則があるということを示すため、様々な法律を調べました。その結果を一覧として公開します。 情報処理安全確保支援士の罰則は重すぎる？｜他士業との比較と検証 不正競争防止法 不正競争防止法　第21条 次の各号のいずれかに該当する場合には、当該違反行為をした者は、十年以下の懲役若しくは二千万円以下の罰金に処し、又はこれを併科する。 情報処理安全確保支援士 情報処理の促進に関する法律　第25条（秘密保持義務） 情報処理安全確保支援士は、正当な理由がなく、その業務に関して知り得た秘密を漏らし、又は盗用してはならない。情報処理安全確保支援士でなくなつた後においても、同様とする。 情報処理の促進に関する法律　第59条 第25条の規定に違反した者は、一年以下の懲役又は五十万円以下の罰金に処する。 医師・弁護士 医師法　第17条の3 前条の規定により医業をする者は、正当な理由がある場合を除き、その業務上知り得た人の秘密を他に漏らしてはならない。同条の規定により医業をする者でなくなつた後においても、同様とする。 弁護士法　第23条（秘密保持の権利及び義務） 弁護士又は弁護士であつた者は、その職務上知り得た秘密を保持する権利を有し、義務を負う。 但し、法律に別段の定めがある場合は、この限りでない。 刑法　第134条（秘密漏示） 医師、薬剤師、医薬品販売業者、助産師、弁護士、弁護人、公証人又はこれらの職にあった者が、正当な理由がないのに、その業務上取り扱ったことについて知り得た人の秘密を漏らしたときは、六月以下の懲役又は十万円以下の罰金に処する。 刑法　第135条（親告罪） この章の罪は、告訴がなければ公訴を提起することができない。 行政書士 行政書士法　第12条（秘密を守る義務） 行政書士は、正当な理由がなく、その業務上取り扱つた事項について知り得た秘密を漏らしてはならない。行政書士でなくなつた後も、また同様とする。 行政書士法　第22条 第十二条又は第十九条の三の規定に違反した者は、一年以下の懲役又は百万円以下の罰金に処する。 ２　前項の罪は、告訴がなければ公訴を提起することができない。 弁理士 弁理士法　第30条（秘密を守る義務） 弁理士又は弁理士であった者は、正当な理由がなく、その業務上取り扱ったことについて知り得た秘密を漏らし、又は盗用してはならない。 弁理士法　第80条 第十六条の五第一項、第三十条又は第七十七条の規定に違反した者は、六月以下の懲役又は五十万円以下の罰金に処する。 ２　前項の罪は、告訴がなければ公訴を提起することができない。 税理士 税理士法　第54条（税理士の使用人等の秘密を守る義務） 税理士又は税理士法人の使用人その他の従業者は、正当な理由がなくて、税理士業務に関して知り得た秘密を他に漏らし、又は盗用してはならない。税理士又は税理士法人の使用人その他の従業者でなくなつた後においても、また同様とする。 税理士法　第59条 次の各号のいずれかに該当する場合には、その違反行為をした者は、二年以下の懲役又は百万円以下の罰金に処する。 三　第三十八条（第五十条第二項において準用する場合を含む。）又は第五十四条の規定に違反したとき。 ２　前項第三号の罪は、告訴がなければ公訴を提起することができない。 公認会計士 公認会計士法　第27条（秘密を守る義務） ...

機械系から見たIPA試験の価値 ――現場主義の壁と、体系知の可能性―― 現場には存在しない「IPA試験」 筆者は機械工学を専門とし、10年近く社会人として実務を重ねてきたエンジニアである。そんな立場から見たとき、IPA試験（情報処理技術者試験）は、機械系の現場ではほとんど話題に上がらない資格のひとつだ。 たとえば筆者の職場は40代〜50代の技術者が中心で、IPA試験の存在すら知らない人も多い。受験しても評価されるわけではなく、「IPAってなに？」という反応がほとんどだ。機械系の現場では「実務第一」「資格より経験」という価値観が根強く、資格取得を軽視する文化がある。 学ぶ関心の変化：技術からマネジメントへ かつて筆者自身も学生時代に基本情報技術者試験の問題を解いたことがある。その当時はプログラミングやセキュリティといった「技術」の部分にしか関心がなかった。しかし、いまは違う。社会人として10年近く働くなかで、むしろマネジメントや経営といった視点の重要性を痛感している。 この意味で、IPA試験の良さは「技術」に加えて「組織運営」や「マネジメント」まで含めた包括的な知識体系を学べる点にある。プロジェクトマネジメントやシステム開発手法、経営戦略など、機械系の専門資格ではほとんど扱われない領域が、IPA試験では当たり前のように出題される。 プロジェクトマネジメントという“共通言語” 一方で、こうした体系的知識の価値は、機械系ではなかなか浸透しにくい。プロジェクトで「スクラム型開発を取り入れてみたい」と若手が提案したとしても、「そんな言葉聞いたことがない。勝手にやり方を変えるな」と年長者に一蹴されることも少なくない。マネジメント理論に基づく議論の土台がそもそも共有されていないのだ。 情報系では「スクラム」や「ウォーターフォール」などの開発手法を、深く理解して実践できるかは別としても、資格試験などで一度は耳にしているため、最低限の共通言語がある。そのため新しい概念にもある程度の耐性がある。だが機械系ではその「共通言語」が欠如している。そもそも管理職層がマネジメントを学術的に学んだことがないケースも珍しくない。 IPA試験を通じた“相対化”の視点 こうした背景から、機械系技術者である筆者は、IPA試験にて"共通言語"が浸透している情報系の分野をうらやましく思っている。たとえ直接の実務に直結しなくても、異なる業界で体系化されている知を知ることで、自分たちの分野の“常識”を相対化するきっかけになる。現場主義の功罪を見直すツールとして、IPA試験は機械系技術者にとっても、じゅうぶん価値があるのだ。 具体的に、機械系（CAD試験、機械技術者試験）とか、化学系（危険物取扱者、毒劇物）とか、電気系（電気工事士、電験三種）試験で、IPA試験のように「プロジェクトマネジメント」や「組織運営」といったマネジメント関連の知識を問うものがあるだろうか？ もしそのような知識が体系的に問われないのだとすれば、私たちの属する業界は、プロジェクトの進め方や組織の在り方において、重要な共通言語を持たないまま仕事を続けているのかもしれない。

応用情報技術者と行政書士は“同レベル”？ 技術者にありがちな自己評価の高さに違和感 Wikipediaの「同程度」表記に驚き 日本語版Wikipediaの「応用情報技術者試験」のページには、行政書士試験と“同程度の難易度”という記述がある。これを初めて見たとき、私は目を疑った。応用情報技術者試験（以下、AP）はすでに取得済みであり、行政書士試験についても一定の関心を持ってきたが、その感触からしても、この評価には大きな違和感がある。 私は、行政書士試験そのものをきちんと学んだわけではないが、憲法・民法・商法・行政法については入門書レベルの学習をしており、行政書士のテキストや問題集を眺めてみたこともある。その上で感じたのは、「これは単に“ジャンルが違う”というだけでは片付かない違いがある」ということだった。 技術資格と法律資格の「質的な違い」 APは、IT知識全般に関する幅広い出題と、午後試験での記述問題を特徴とする。情報系出身者であっても一定の準備が必要であり、合格率は例年20%台とされている。ただし、これは「ITにある程度慣れた人」にとっての話だ。 実際、応用情報は本気で学習すれば、午前は過去問道場で10年間分の過去問800題×最低2周、午後は、数年分を1回解いて問題形式に慣れれば、「午後は国語問題」と揶揄されるように、国語能力が高ければ合格することも十分可能だ。つまり、論理的な文章読解と基礎知識があれば、一定の効率で突破できる構造になっている。 対して行政書士は、法律系の国家試験であり、主要科目は憲法・行政法・民法など。中でも行政法の分量が非常に多く、条文暗記と判例の理解が求められる。ITと異なり、根本的に「言葉の意味」や「文脈での正確な理解」が問われるため、知識の性質がまったく異なる。 技術者がはまりがちな“自己評価バイアス” IT業界に身を置いていると、「自分の分野の知識は専門的で高度だ」と無意識に考えてしまうことがある。数式がある、アルゴリズムがある、暗記より理解が求められる──それゆえに、法律系資格を“文系の暗記モノ”と軽視しがちだ。 しかし、実際に行政書士の教科書を開いてみると、この思い込みが崩れる。制度の細かさ、言葉の使い分け、問われる判例知識──いずれも“実務的かつ精緻”であり、IT系資格とは別種の知的体力が必要だと感じた。 「合格率」だけで測れない難易度 Wikipediaの“同程度”評価は、おそらく合格率など数値上のデータを根拠にしている。しかし、合格率が似ているからといって、試験の難易度が等しいとは限らない。受験者層の前提知識、出題分野の異質性、学習に要する時間の質と量など、無視できない要素が多数ある。 たとえば、APは情報系出身者にとって“すでに知っている内容”も多いが、行政書士は多くの人にとって未知の法体系との初対面である。そこには、「慣れ」の壁がある。 本当に難しいのは「慣れない分野」 私自身の経験から言えば、「応用情報」と「行政書士」を並べて同列に語るのは、乱暴すぎる。分野が違えば、戦い方も異なる。そして、もっとも厄介なのは、自分が普段触れていない世界の知識に飛び込むときだ。 だからこそ思う。「本当に難しいのは、“慣れていない分野”の資格試験だ」と。自分の専門分野に安住せず、異なる体系の知識に敬意を払う視点こそ、プロフェッショナルとしての謙虚さなのではないだろうか。