Posts

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