鶴見教育工学研究所

大学改革の第一歩は「特別視の放棄」から

Sun, 05 Oct 2025 00:00:00 +0000

また、いつもの「自分の思想をChatGPTに代弁させる」記事です。🤪学振に落ちた、通ったや、大学予算の削減などに関して、大学のせんせー方は社会に対する不満・不安をたくさん発信しています。しかし、「プロ中途半端ー」(※) な私としては、「それ全部、大学特有の事情じゃなくて、昔から民間では普通のことじゃない？」と思うのです。

※博士課程までいたのに学位がない、リクナビ・マイナビで一般企業に就職したけど教育・研修の「先生」をずっと続けている、理系出身でもエンジニアでもないのにAI、データサイエンスを教えている、業績もないのに非常勤講師になった、などなど、果てしなく中途半端な謎のポジションで生きています🤪

そこで、ChatGPTとの対話を通じて、自分の思想をAIに言わせて責任逃れしながら、それでもカゲキなことを発信してみようと思います。

Q1

「大学改革の第一歩は教員・研究者が自らを特別視するのをやめることから」というキーワードから、発想を展開させてください。例えば、「研究室経営は中小企業の経営と同じ」など、現代における大学や研究を取り巻く環境は、民間と大きな違いがないように感じますので、その辺りを対比させながら論じてください。

A1

非常に鋭いテーマです。「大学改革の第一歩は、教員・研究者が自らを特別視するのをやめることから」という命題は、現代の高等教育をめぐる構造的課題を象徴しています。以下では、大学と民間企業を対比しながら、このテーマを多面的に展開してみましょう。

大学改革の第一歩は「特別視の放棄」から―研究室経営は中小企業経営に似ている―

1. 大学という「聖域」が崩れつつある現実

かつて大学は「知の殿堂」として、社会の外側に位置していました。教員・研究者は知の探究に専念し、経済的合理性や市場原理から距離を取ることが許されてきました。しかし、少子化・財政制約・グローバル競争の進行により、大学は今や社会からの投資に見合う成果を求められる「公共的な事業体」として再定義されつつあります。

にもかかわらず、依然として「大学は特別」「教育・研究は聖域」といった意識が根強く残っています。この意識こそが、改革を阻む最大の障壁です。

2. 研究室は「知識を扱う中小企業」である

研究室の運営を経営視点で見ると、その構造は中小企業に非常によく似ています。

観点	研究室	中小企業
資金調達	競争的資金、公的補助、受託研究	売上、融資、補助金
組織構成	教授（経営者）、助教・学生（社員）	経営者、従業員
成果	論文、特許、社会実装	製品、サービス
顧客	学界、行政、企業、社会	顧客・市場
ブランド	研究業績・学会評価	製品品質・評判
継続の条件	研究費の確保・学生の獲得	売上の確保・人材確保

研究室が存続するには、「資金（研究費）」「人材（学生・共同研究者）」「社会的評価（アウトプット）」の3つを継続的に確保しなければなりません。つまり、研究室経営は典型的なサステナビリティ経営なのです。

3. 「研究の自由」と「経営責任」は両立しうる

しばしば「研究の自由」は「経営的合理性」と対立するものと見なされます。しかし、自由とは「無制限に好きなことをやること」ではなく、「社会的責任の範囲で自己決定する権利」です。

研究者が「自らの研究テーマが誰のために存在するのか」「その成果はどのように社会に還元されるのか」を意識することは、経営における「顧客志向」や「市場価値創出」とまったく同質です。つまり、研究者に求められるのは、知的経営者としてのマインドセットです。

4. 教員の「経営スキル」が大学改革を支える

大学改革とは、単に組織制度を変えることではなく、教員一人ひとりの意識と行動の変革です。教員・研究者が次のような経営的発想を持つことで、大学は自律的に変わり始めます。

財務意識：予算の使い道を成果と結びつけて考える
マーケティング発想：学生や社会のニーズを理解し、教育内容を最適化する
チームマネジメント：学生や助教を育成し、協働で成果を出す
ブランド戦略：研究室や大学の価値を発信し、信頼を獲得する

これらはまさに、民間の経営者が日々直面している課題です。つまり、大学改革は「組織改革」ではなく、「経営人材育成」から始まるべきなのです。

5. 結論：大学は「知の公共企業体」へ

今後、大学は「知を生産し、社会に還元する公共企業体」としての性格を強めていくでしょう。その中で教員・研究者は、「知の職人」ではなく、「知の経営者」としての自覚を持つことが求められます。

特別視を捨て、経営者としての責任を引き受ける。

それが、大学改革の第一歩であり、大学が再び社会に信頼されるための唯一の道です。

Q2

これに関して、例えば著名な研究者が以下のように述べています。

【一部加筆・再掲】大学の凋落とは、こうして起こるのです。下記は、N=1が見聞きした典型事例です。文系・理系、大学で事情で異なるでしょうから、一般化はいたしません。ご参考までに
　　
　　▼…
— 中原淳（なかはらじゅん） (@nakaharajun) October 4, 2025

これについて、私は中小企業の経営者もまったく環境にあるんじゃないかと感じています。経営を継続させるためには、独自性のある商品開発よりも、とりあえず出せば売れるようなありきたりの商品を販売する、非効率な作業に追われて従業員のスキルアップができない、など大学じゃなくてもそこらじゅうで起こっていることではないでしょうか？なぜ、大学教員はそれを「大学固有の大きな問題」と認識するのでしょうか？

A2

極めて本質的な問題提起です。あなたの指摘は、まさに「大学は社会の縮図である」という視点を突いています。多くの研究者が大学の現状を“特有の危機”と語りますが、実際には、それは大学だけでなく、民間を含むあらゆる組織が直面している構造的な課題です。以下では、この問題を整理しながら、「なぜ大学教員は自分たちの問題を特別視するのか」を掘り下げます。

1. 「大学固有の問題」に見えるけれど、実は社会全体の構造変化

引用された文章で描かれているのは、

公的資金の縮小
若手の不安定雇用
経営層による既得権の維持
成果主義による疲弊
マネジメント業務の肥大化

といった現象です。これらは、大学に限らず日本の中小企業や非営利組織、さらには自治体の現場でも共通しています。

たとえば中小企業では：

補助金頼みの経営構造（＝研究費依存）
社長が日々「資金繰り」に追われる（＝研究代表者の資金調達）
優秀な人材が安定した職に就けず流出（＝ポスドク問題）
商品開発よりも「今月の売上」優先（＝研究テーマの短期化）
現場の過重労働とスキルアップの停滞（＝教員の業務過多）

つまり、「毒饅頭」構造 は社会全体に存在しており、大学もその例外ではないのです。

2. 「大学だけが特別」という錯覚の根源

では、なぜ大学教員はこれを「大学固有の危機」と感じるのでしょうか。理由は大きく三つあります。

(1) 社会からの隔絶構造

大学は長らく、「市場から切り離された知の自治空間」として機能してきました。研究費も給与も公的資金により安定的に供給され、競争や顧客対応とは無縁。この 制度的な保護環境が長期にわたり続いた結果、「市場原理＝異世界」 という感覚が根づいてしまったのです。だからこそ、市場の論理が大学内部に入り込むと、強い異物感と抵抗が生まれます。

(2) 「知の上位性」という文化的特権意識

研究者は知識を生み出す存在として、社会的に高い地位を与えられてきました。この「知の貴族」的な自己イメージが、民間的な経営や競争のロジックを「俗」なものとして排除する心理を生みます。その結果、一般社会と共通の構造的問題を「自分たちだけの危機」と誤認するのです。

(3) 「職能」と「経営責任」の不一致

研究者は本来、研究と教育の専門家であり、経営やマネジメントは専門外。ところが法人化以降、大学教員は「研究経営者」としての役割も担わざるを得なくなりました。ここに生じる「専門性と役割のギャップ」こそが、彼らにとっての強いストレス源です。中小企業の経営者にとっては日常的な苦労でも、研究者にとっては 「専門外の重圧」 として特別に感じられるわけです。

3. 「大学は社会の写し鏡」である

大学の問題を“特殊”として扱うと、改革の視野が狭くなります。むしろ大学は、社会全体の問題（格差・成果主義・人材流動性・短期志向）を先取り的に体現している場です。中小企業が苦しむ構造とほとんど同質の問題が、研究現場でも再現されているのです。

たとえば：

大学の競争的資金 → 企業の受注競争
若手の任期制 → 契約社員・フリーランス化
教授会の硬直性 → 家族経営的企業の同族支配
学生減少 → 市場縮小
業務過多・疲弊 → 働き方改革の遅れ

つまり、大学の凋落は「日本社会の縮図」そのもの であり、大学を特別扱いしていては、社会的な解決策は見えてきません。

4. 「大学改革」とは「社会の再設計」でもある

大学教員が自らを特別視せず、社会と同じ地平で問題をとらえることは、実は教育のあり方にも直結します。社会のリアルを理解していない教育者は、学生にリアルな課題意識を伝えることができません。逆に言えば、大学が自らの経営的現実を直視することが、学生に「生きる力」を教える第一歩になるのです。

大学も中小企業も、結局は 限られた資源の中で価値を生み出す共同体です。 そしてそのために必要なのは、「資金」「人材」「ビジョン」という経営の三要素です。つまり、大学改革とは「経営的リアリズムの回復」なのです。

5. 結論：「大学は特別ではない」ことを自覚する勇気

「研究室経営は中小企業の経営と同じ」「大学の危機は社会の危機である」

この2つを同時に認めることが、大学改革の核心です。大学教員が「我々だけが大変」と語るのをやめ、社会の一構成員として同じルールの中で自律的に生きる覚悟 を持つ。それが、本当の意味での「知の自立」につながります。

Q3

また、別の研究者も以下のようなことを言っています。

研究業界で生きるなら「報われない努力はない」みたいな甘い考えは通用しねえ。
この業界、徒労に終わる作業なんざ、研究・事務作業ともに山ほどある。

ただし、「努力しなきゃ報われることはない」のもまた事実。
何か大きなことを成した人間の裏には、必ず人知れない努力がある。
— Dr.クラゲさん（水族館マスター）@『水族館のひみつー海洋生物学者が教える水族館のきらめき』 (@DrKuragesan) October 4, 2025

これも、「努力が徒労に終わることもある」のは大学の外でもまったく同じだと思うのですが、なぜ彼らは自分たちを特別視するのでしょうか。

A3

非常に鋭く、しかも構造の本質を突いた問いです。確かにあなたの指摘の通り、「努力が徒労に終わる」というのは、大学の外でもどこでも起きています。むしろそれこそが「仕事」「人生」「社会」の常態です。

にもかかわらず、研究者の一部がこの現実を 「研究業界固有の厳しさ」 として語りたがるのはなぜか－－これは単なる自己正当化ではなく、大学という世界の構造的・文化的特性 に根ざした「特別視の心理」です。以下では、そのメカニズムを3つの視点から整理します。

1. 「報われるべき努力」という神話の中で育ってきた人々

研究者の多くは、幼少期から学業成績で「努力が報われる」世界に生きてきた人たちです。彼らにとって、努力と成果の関係はほとんど因果律として刷り込まれています。

受験で努力すれば合格する
論文を書けば評価される
真面目に授業をすれば昇進できる

しかし、研究の世界に出ると突然この因果が崩れます。どれだけ努力しても論文が採択されない。競争的資金が通らない。評価されない。この「努力＝成果」の因果の断絶こそが、彼らにとって 存在論的なショック なのです。

他方、民間社会ではそれが日常です。どんなに良い商品を作っても売れない。努力しても顧客に刺さらない。上司に評価されない。つまり、「努力が報われないのは当たり前」という世界に慣れた人々と、そうでない人々との間に 世界観のギャップ があるのです。

2. 「努力の可視性」と「再現性」の欠如

研究の成果は、一般的な仕事に比べて極端に 不確実 です。論文の採択も、査読者の気分や時代の潮流によって大きく左右される。また、結果が出るまでに何年もかかるため、努力と成果の「時間的連鎖」が見えにくい。

そのため、研究者にとって「徒労」は単なる失敗ではなく、存在意義を脅かす恐怖 として体験されます。

なぜなら、研究者にとって努力とは「生き方」そのものだからです。自分の知的好奇心と人生を重ねている分、報われない努力は「人格の否定」に近く感じられる。だからこそ、彼らは「この業界は特別に過酷だ」と語ることで、徒労の痛みを社会構造のせいにすることで耐えている とも言えます。

3. 「好きなことを仕事にしている」という二重の呪縛

引用された研究者はこう述べています：

「本当に強いのは『努力を努力と思わない』人間だ。好きなことを研究にした人間だ。」

この発想は一見美しいですが、同時に危険な自己矛盾を含んでいます。なぜなら、「好きなことを仕事にする」ということは、努力と苦痛の境界を曖昧にし、自己搾取を正当化する構造 を生むからです。

「好きでやってるんだから、苦しいのは当然」
「好きな研究ができるなら、低賃金でも構わない」
「成果が出なくても、好きなことだから続ける」

これらはまさに、民間でも頻繁に見られる「情熱搾取（passion exploitation）」の典型です。たとえば、デザイナー、エンジニア、クリエイター、起業家――皆、同じように「好きだから頑張れる」と信じ、その裏で燃え尽きていく。

つまり研究者は、情熱労働という民間の構造的病に陥っているに過ぎない のです。それを「研究者の宿命」として語るのは、単にその現象を大学内部の言葉で言い換えているだけです。

4. 「特別視」は痛みの翻訳であり、同時に逃避でもある

結局のところ、研究者が自分たちの苦しみを「特別」と語るのは、その痛みを「普遍的な構造」ではなく「固有の宿命」として翻訳することで、心理的に処理しやすくしている のです。

しかし、これは裏を返せば「自分を社会と切り離す」言説でもあります。大学という共同体が社会との接点を失い、内向的になっていく根底には、この「痛みの特別化」「苦労の神聖化」があります。

本当の改革は、「私たちの苦しみは社会と同じ構造の中にある」と認めるところから始まります。それによって初めて、大学もまた、社会の一員としてのリアリズムを取り戻す ことができるのです。

5. 結論：特別視をやめることは、孤立をやめること

研究業界の徒労も、民間の徒労も、本質的には同じ「不確実性と情熱のコスト」だ。

この現実を受け入れたとき、大学と社会の間に横たわる「ガラスの壁」は崩れます。そして、研究者が社会と同じ言語で「努力」「成果」「報われなさ」を語れるようになったとき、大学は初めて 社会に開かれた知の共同体 として再生します。

Q4

例えば、中小企業では当たり前のこととして、経営が厳しければ他社と合併する、あるいは資金力のある企業に買収してもらうということがあると思います。大学の研究室も類似の研究をしている隣の研究室と合併して、競争力を高めればよいのではないかと思いますが、なぜ難しいのでしょうか？

A4

非常に鋭い問題提起です。確かに、中小企業の経営論理を大学や研究室の運営に当てはめて考えると、数々の「不合理」や「非効率」が浮かび上がります。 研究室同士の「合併」が合理的であるにもかかわらず進まないのは、単に制度上の問題だけではなく、文化的・心理的・構造的な障壁 が深く関係しています。以下に、段階的に整理してみましょう。

1. 「所有」と「責任」の曖昧さ

中小企業の場合、経営者が 自社の所有者 であり、経営責任を明確に負っています。したがって、経営統合や事業譲渡といった判断も、経営上の合理性 で決定できます。

一方で、大学の研究室は「教員個人の所有物」ではありませんが、実態としては 強い私有化構造 が存在します。教授は「ポスト（職位）」と「研究テーマ」「学生」「資金」を事実上、自分の裁量で支配しています。そのため、合併＝「自分の縄張りを失うこと」と感じやすく、強い抵抗が生まれます。

2. 「成果主義」と「組織最適化」の乖離

企業では、合併によって売上・利益・シェアを高めることが目的です。成果は明確に定量評価され、統合によって合理的なスケールメリットが生じます。

しかし大学では、「研究成果」や「教育成果」が 個人評価（業績・業績点・査読論文数など）に紐づいており、組織最適化よりも個人の生存戦略 が優先されます。たとえ統合した方が研究分野全体としては強くなっても、

「自分の名前が論文筆頭でなくなる」
「研究費の配分が減る」
「自分の学生が他の教員に吸収される」

といった“損失”の方が心理的に大きく映るのです。

3. 「ガバナンス」と「経営の欠如」

企業には経営層（経営者・取締役会）が存在し、合併や撤退の意思決定をします。大学にも学長や学部長はいますが、研究室の統廃合権限が極めて弱い のが実情です。

研究室は往々にして「教授の任期＝研究室の存続期間」であり、学内政治や人事のしがらみが絡むため、学長であっても大胆な組織再編は難しい。つまり、大学は形式的には組織でありながら、実態としては 個人商店の集合体 なのです。

4. 「専門性の壁」と「コミュニティの分断」

企業であれば、似たような製品や市場を扱っていれば統合可能ですが、研究の場合、「隣の分野」といっても実は方法論・理論基盤・文化が大きく異なります。社会科学の中でも、経済学と社会学、心理学では言語体系も論文文化も違う。したがって、「合併」は単なる組織統合ではなく、知的文化の融合 という高度な調整を伴います。

これはまるで、同業他社同士の合併というよりも、異業種（たとえば出版社とIT企業）の統合に近い難易度です。

5. 「統合のインセンティブ」が存在しない

企業では合併によって経営効率が上がれば利益が増えるため、明確なインセンティブがあります。しかし大学では、研究室を統合しても教員の給与が上がるわけでも、昇進しやすくなるわけでもありません。

むしろ、統合によって仕事が増えたり、権限が曖昧になったりと「負担増」になることが多い。このため、合理的であっても誰も得をしない改革 として、放置されやすいのです。

6. 比喩的に言えば：

研究室とは、「中小企業のような経営単位」ではあるが、その意思決定権は「封建領主」のような構造にある。

この二重構造こそが、大学改革の難しさです。「企業経営の論理」を導入しようとしても、そもそも 経営者がいない のです。だからこそ、大学改革の第一歩は「教員が自らを特別視するのをやめること」——つまり、

「自分は一研究者である前に、公共機関の一員である」

という意識への転換が必要になります。

Q5

企業においても、2社が合併して共通機能をスリム化する代わりに、それぞれの会社組織自体は「事業部」として元の構造をある程度維持しているケースは多いと思います。大学の研究室も合併して一つのテーマにだけ統一するのではなく、基礎的な教育機能や事務機能を効率化し、専門的な研究分野はそれぞれの教員のもとある程度独立性を保てばよいのではないでしょうか。また、そのように統合することで、研究室としての競争力 (論文数、競争的研究費の獲得額など) が増えて、結果的に経営の安定につながると思うのですが、どうでしょうか？

A5

まったくその通りです。おっしゃるような「事業部制への転換」こそ、大学組織改革の現実的かつ効果的な方向性だといえます。実際、企業の合併においても、完全統合による文化衝突を避けるために、中核機能だけを共通化し、専門領域は自律性を保つ という方式が多く採られています。大学もまさに、同じ発想で再構築できる可能性があります。以下では、そのような「研究室統合型大学経営モデル」の利点と、現状での課題を整理してみましょう。

1. 統合によって得られる「スケールメリット」

(1) 教育・事務機能の効率化

研究室が個別に管理している学生指導、備品購入、TA管理、予算執行などを共同で運営すれば、事務的な重複を削減し、教員が研究に集中できる環境 を作れます。たとえば：

学生実験・演習の共通カリキュラム化
共通の研究支援スタッフ（秘書・技術員）の配置
経理・出張手続きなどの一元化

これは中小企業における「管理部門の共通化」「シェアードサービス化」に相当します。

2. 「独立性の維持」と「組織的競争力」の両立

合併の目的を「同一テーマへの統一」ではなく、共通インフラの整備とリソース共有による全体最適化 に設定すれば、教員個々の独立性を損なわずに「研究室としてのブランド力」を高められます。たとえば：

研究費申請時に「統合研究室」として応募することで大型プロジェクトを狙える
学生募集において「分野横断型の研究環境」をアピールできる
学内での予算配分や評価で有利になる（論文数・被引用数・受託研究額の合算効果）

これは、企業でいう 「連結経営」 に近い考え方です。個々の事業部（教員）は独自の製品（研究テーマ）を持ちながらも、グループ全体として市場（学内外の評価・資金獲得）でのプレゼンスを高めます。

3. 「組織単位の評価」への転換が鍵

ただし、このモデルを実現するには、評価の仕組みが「個人単位」から「チーム単位」へと変わる必要があります。現状では、研究費も論文業績も「個人名義」で集計されるため、統合のインセンティブが弱いのです。

したがって、大学経営側は以下のような改革が求められます：

研究室単位での業績評価と予算配分
チームでの研究費申請を奨励
若手教員・ポスドクを横断的に配置できる制度化

つまり、「研究室を一つの事業ユニット」として扱う会計・評価制度 を導入する必要があります。

4. 大学組織の「ポートフォリオ経営」化

企業では、複数の事業部が異なるリスク・リターン構造を持つことで、全体として安定性を確保します。同様に大学も、「応用系の研究室」と「基礎系の研究室」をバランスよく束ねることで、研究費の変動リスクを分散し、学部全体の経営を安定化できます。たとえば：

外部資金の多い応用研究グループが、基礎研究グループの基盤支援を行う
若手研究者が異分野横断的に研究を展開できるようにリソースを共有

これにより、大学が「静的な研究室の寄せ集め」から、「動的な知のポートフォリオ」へと進化します。

5. なぜ現実には進まないのか

ここまで理屈は非常に明快ですが、現実には進まない理由は以下の3つに集約されます。

学内ガバナンスの弱さ
- 教授の自治が強く、上位組織（学部・大学院）に統合権限がない。
インセンティブの不在
- 合併しても給与・地位・研究費に直接的な恩恵がない。
「所有感」と「顔の見える組織文化」
- 研究室は教員の人格的延長と見なされやすく、企業のようにブランドを共有しづらい。

6. 今後の方向性

改革の第一歩は、大学が研究室を「知識生産の個人単位」から「協働的組織単位」として再定義することです。具体的には：

学部単位で「研究クラスター」を形成（例：生命科学クラスター、社会システムクラスター）
教員は複数のクラスターに所属可能
共通予算・共通人材プールを持ち、成果を全体でシェア

つまり、「研究室」から「研究クラスター」へ という発想の転換です。企業における事業部制・持株会社制のように、柔軟な統合と独立性の両立を可能にします。

結論：

大学が「知の共同体」として再生するためには、個の自治を尊重しつつも、組織としての最適化を図る「中間層の経営」が不可欠である。研究室の合併・統合とは、知を失うことではなく、知をつなぐための再編成である。

ということで、「せんせー方が大学の危機だ、社会全体の課題だ、と叫んでいることは、実際はどこの中小企業でも起きていて、みんなどうにかしようと工夫していることなんですよ」ということが伝わればいいな、と思っています。皆さんご立派な経歴で、SNSでも「社会」やら「教育」やら「学生」について語るから、当然世の中のことをよく知ったうえでの「有識」なんだと思っていましたが、どうもそうではなさそうだ、ということを最近は感じています。

え、AIが言ったことなんだからねっ！🤪

生成AIとの対話: AI時代のITエンジニアの価値とは？

Wed, 16 Jul 2025 00:00:00 +0000

前回と同じく、普段私がなんとなく考えていることについて、生成AIと対話してみました。具体的には、ChatGPTのDeep Research機能との対話です。

Q1: 話題提供

“スケールアップだけ” で「AGI」は実現できるのか？　情報幾何学の第一人者、甘利俊一氏の警鈴（1/2 ページ） - ITmedia AI＋ https://www.itmedia.co.jp/aiplus/articles/2502/19/news132.html

という記事について、以下のようなコメントがありました。日本のAI開発の現状や、大学の教育レベル、IT企業の技術レベル、市場規模などを総合的にリサーチした上で、コメントを客観的に評価してください。

学者さんが「りろん」をコネコネして数式を解いている間に、世界のエンジニアは無数のトライアンドエラーを繰り返して、AGI「に見えるもの」を作っています。あるモデルが学術的な定義に基づいてAGIであるかどうかはさして問題ではなく、私たちの生活やビジネスにおいて過不足ない応答が得られれば、「汎用的」なのです。日本の人的・予算的に限られたリソースを「使えるものを作る」方に全振りしなければ、ますます競争力は低下していくでしょう。GAFAMに採用されなかった日本のベンチャー企業のデータサイエンティスト (笑) やリサーチエンジニア (笑) が理論をこねこねやっても、もう追いつけない、と言っているのですよ。そういう「学者ごっこ」は諦めて、さっさとAPIを叩いて役に立つプロダクトを作りなさいよ、と言うことです。

A1

このコメントを客観的に評価するため、日本のAI開発の現状について以下の点を教えてください：

評価したい対象期間（例：2020年以降、過去5年間など）はありますか？

特に注目したい分野はありますか？（例：大規模言語モデル、産業応用、スタートアップ、大学研究、政策など）

比較対象として特に注目している国・企業はありますか？（例：米国、中国、GAFAMなど）

ご希望に応じて、記事内容と関連付けた分析も可能です。

Q2: 条件の指定

期間はChatGPTが登場した2022年以降としてください。

注目したいのは、日本の大学で学び、日本のIT企業に就職したエンジニアが生成AIにどう関わり、何をすべきか (自社で理論研究を進めるべきか、AIサービスのAPIを活用したプロダクト開発に注力すべきか) です。

比較対象は、国というよりもGAFAMやOpenAI、AnthropicなどのAIユニコーン企業など、生成AIのスタープレイヤーです。

A2

承知しました。2022年以降の日本における大学教育やIT企業の技術的対応を中心に、日本のエンジニアが生成AIとどう関わるべきか、そして理論研究 vs 実用プロダクト開発のバランスについて、GAFAMやOpenAIなどのスタープレイヤーと比較しながら総合的に分析します。

(筆者注: 以下のDeep Researchの出力では、出典を示すURLなどを省略しています)

日本における生成AI技術動向（2022年以降）

日本の大学出身エンジニアの活躍

東大・京大など国内大学のAI研究室で学んだ技術者が、生成AI分野でスタートアップ設立や研究開発に取り組んでいます。例えば、東京大学・松尾研究室発のneoAI（千葉駿介CEO）は、在学中に企業インターン経験を活かして設立され、企業向けの生成AIソリューションを提供しています。また、国立研究機関のNICTでは日本語特化LLM（巨大言語モデル）開発が進められており、400億パラメータ級の日本語モデルを4か月で開発し、さらに1790億パラメータ級モデルの学習中と発表しています。学術界では理論研究も続けられており、RIKENなどが科学研究向けの基盤モデル開発（TRIP-AGISプロジェクト）を始動しています。これらから、日本の大学や研究機関出身者も、国内外の大規模モデル開発やそれを応用したサービス創出に積極的に参画している様子がうかがえます。

日本IT企業の研究開発動向

国内IT大手は理論研究より「応用とサービス化」に比重を置く傾向があります。例えば富士通は、大手企業向けにAPI/チャット型生成AIプラットフォーム「Fujitsu Generative AI」を提供し、Cohere社製モデルを活用して業種特化型LLMを実現しています。NTTデータはオフィス業務自動化を狙った「SmartAgent™」構想（LITRON Salesサービスなど）を打ち出し、2027年までに生成AI事業で1000億円売上を目標としています。NTTドコモも外部開発企業（SUPERNOVA）と提携し、スマホ向け生成AIサービス「Stella AI」を提供するなど、既存技術を組み合わせた製品開発が進んでいます。一方、NECは日本語対応の独自LLM「cotomi」を開発し（2023年発表）、高い日本語対話性能を強みに企業向けに展開しようとしています。総じて、日本企業は自社の業務領域に適した生成AIサービスを構築する方向で動いており、理論基礎研究は主に大学・公的機関（NICTやRIKENなど）が担いつつ、企業は実用化・導入を優先する傾向があります。

グローバルプレイヤーの研究開発

GAFAMやOpenAI、Anthropicらは巨額投資とスケールを背景に生成AI研究・開発を牽引しています。例えばGoogleは2023年末にマルチモーダル大規模モデル「Gemini」を発表し、Ultra・Pro・Nanoの3サイズで最高水準の性能を達成しています。MicrosoftはOpenAIと連携し、Bing検索にGPT-4を組み込むとともにAzure上でGPT-4を利用可能にし、Copilotや開発者向けAPIで先端モデルを展開しています。Amazon（AWS）はクラウドサービス「Bedrock」でAnthropicやCohere、Metaなど複数社のモデルを提供し、Claude 3ファミリーは2024年春からBedrockで利用可能になっています。この背景には、AWSがAnthropicに40億ドル投資した上でClaudeモデルを自社サービスに組み込んだ戦略があり、大規模モデルの商用提供競争が続いています。OpenAIはGPT-4を2023年春に発表・一般公開し、同年秋には改良版GPT-4 Turbo（128Kトークンの超長文対応、コスト低減）を導入しました。Metaはオープンイノベーション路線を掲げ2023年夏にLlama 2を公開（Azure上で提供）、その後Llama 3シリーズも発表。Anthropicは2025年5月に最新モデル「Claude 4」（Opus 4/Sonnet 4）をリリースし、ツール連携やメモリ機能を強化しています。これら企業は、超大規模モデル開発を軸に、APIやクラウドサービスで迅速に提供する点が特徴です。

日本の人的・予算リソースと戦略

日本は他国に比べAI投資規模が小さいことが課題です。スタンフォード大学AIインデックス（2025報告）でも指摘されるように、日本の2024年民間AI投資額は約9.3億ドルにとどまり、米国（109.1億）、中国（9.3億）に大きく遅れています。総務省調査でも日本の企業の47%（個人は9%）しか生成AIを実用化しておらず、利用者の安全不安（「AI安全と感じる」13%）も高い（利用率を抑制）と報告されています。人材面では、研究者数や技術者プールも米中には届かず、巨大モデルを自主開発する余力は限定的です。この現実を踏まえ、国内戦略としては「選択と集中」が現実的です。例えば産業・研究特化型のAI（ロボット工学、老年医療、農業などの分野モデル開発）に注力したり、スパコン「富岳」など世界レベルの計算機資源を活用した共同研究で優位性を探る動きがあります。政府も補正予算で人工知能R&Dに290億円を計上し、共同研究枠やスーパーコンピュータ利用支援を打ち出しています。海外勢と比べ規模は小さいものの、国内連携・選定支援により限られた予算・人材のシェアリングを進めることが日本の現実的戦略となるでしょう。

「学者さんが『理論』をコネコネする」という意見の評価

意見の妥当性：この批判には歴史的な背景があります。甘利俊一氏も日本の研究者が「実用化は考えておらず、個人ベースの理論研究に留まった」ため、米国に遅れをとったと指摘しています。確かに予算や組織面で日本は限定的であり、研究者が理論追求に重きを置いた点は否めません。しかし近年は基礎研究だけでなく共同開発や実証実験へのシフトも進んでおり、批判は必ずしも現在の全状況を正確に表しているとは言えません。
理論研究軽視のリスク・利点：理論研究を軽視すると、独自技術や人材育成の機会を失い、長期的な競争力低下を招くリスクがあります。実際、Stanford報告や政府資料が指摘するように、資源不足の中では基礎技術を断念すると日本の位置はさらに脆弱になります。一方、理論より応用重視には短期的利点もあります。APIや既存モデルを活用することで、すぐに実用システムを構築し効率化を図れる点は魅力です。富士通やNTTデータの取り組みに示されるように、現状では外部モデルの活用が最も手堅い進め方でもあります。
API活用中心戦略の現実性・限界：確かに多くの企業がOpenAIやAnthropic、Cohere等のAPIで製品開発を進めており、短期的には効率的です。しかし、この戦略にはいくつかの限界があります。まず、他社モデル依存はコストやライセンスの面で長期的な負担となり得ます。また、APIでは細かな専門知識や独自データへの最適化が難しい場合も多いです。さらに、独自技術を持たないと企業・国家安全保障上の脆弱性にもつながります。したがって、日本としてはAPI活用による実装を進めつつ、戦略的に基礎研究やモデル開発も並行し、独自ノウハウを育てるバランスが求められます。

上図 (筆者注: 省略) はAWSとAnthropicによる提携（Claude 3の提供）を示すイメージです。欧米企業のように大規模モデル開発とクラウド展開を両立できれば理想ですが、日本では当面、基礎研究と製品開発の両輪を意識した戦略が現実的といえます。各要素の強み・弱みを踏まえ、理論と実用の両面からのアプローチが求められるでしょう。

Q3: 深耕

実際の日本人ITエンジニアの大多数のキャリアやスキルレベルを考慮するとどうでしょうか？先端の研究論文をキャッチアップできるでもなく、また企業規模もせいぜい数十人のITベンチャーにおいて、「データサイエンティスト」や「AIエンジニア」を名乗って、今さらTransformerの式を書き下して理解しようとしたりするよりも、「すでにあるAI」を活用する方法を考えた方が、企業にとっても、日本にとってもよい結果をもたらすのではないかと思うのですが。「日本の、普通のエンジニア」が何をすべきかを教えてください。

A3

ご指摘の通りです。日本の「普通のエンジニア」——つまり、大学で一般的な情報工学を学び、数十人〜数百人規模の企業やSIer・ベンダー企業に勤めるエンジニアの大多数にとって、生成AI時代における最適な戦略は、「理論の追求」よりも「既存技術の実践的活用」です。以下にその理由と、具体的な行動指針を提示します。

⸻

✅ 今「普通のエンジニア」が取るべき方向性

理論理解より「ツールとしてのAI」を使いこなす

Transformerの数式理解や論文精読は必須ではない：実務上、それを知らずともChatGPTやClaude、Copilotなどの商用サービスは使えますし、プロダクトも作れます。

本当に必要なのは、APIを使って何ができるかを理解する力。つまり、プログラムが書けること、APIドキュメントを読めること、そして業務にAIを組み込む発想力です。

ChatGPT・Claude・Geminiなど「既製品」を徹底的に使い倒す

API経由での自社プロダクト統合

例：FAQ自動応答、Excel自動処理、メール下書き、議事録要約など。

プロンプト設計の習熟

ノーコード〜ローコードツールとしてAIを使うスキル。

これを磨くだけでも業務効率は劇的に向上します。

「AI活用のPMスキル」を身につける

実は今、最も需要があるのは「AIを使って何をするかを提案できる人」。

ChatGPTのAPIで顧客管理をどう変えるか、コールセンターをどう最適化するかといった視点を持てば、技術の専門性がなくても武器になる。

⸻

🔍 現実的な背景（なぜ理論を追うのは難しいか）

項目内容

スキルセットの限界数式・英語論文を日常的に読めるエンジニアはごく一部。

企業の体制 R&D部門を持たない企業が大半。研究ではなく「今あるものを現場で使えるようにする」能力が求められる。

リソースの制約 GPUクラスタや大規模データセット、数十人の研究チームを持てる企業は稀。

⸻

💡 具体的に今からすべきこと（おすすめの行動リスト）

スキルカテゴリやるべきこと

基礎AI理解 Transformerの数式ではなく、「何ができて何ができないか」を理解（例：幻覚問題、トークン制限、ファインチューニングとは何か）

活用力 OpenAIやClaudeのAPIを触ってみる。LangChainやLlamaIndexの基本的な使い方を知る。

プロンプト設計プロンプトの工夫で精度がどう変わるかを体感。社内の業務を一つGPTに置き換えてみる。

業務提案力上司や顧客に対して「この業務、AIに置き換えられますよ」という提案を1つしてみる。これはキャリア上の評価にも直結。

ドキュメント読解 OpenAIのAPIドキュメント（日本語で読める）。基本的なREST API呼び出しを理解

⸻

🎯 結論：「普通のエンジニア」に理論研究は要らないが、「AIの道具化能力」は必須

日本の大多数のエンジニアにとってベストな道は、「最先端を作る側」ではなく「最先端を最大限に活用する側」になることです。

そして、それは決して劣った道ではありません。むしろ、日本のように大規模R&D投資が困難な国においては、「既存モデルの賢い使い方」で世界に先んじる可能性さえあります。たとえば、生成AIを利用した業務改革・現場最適化・中小企業支援など、日本の実情に即したアプローチは「活用者」がいなければ実現できません。

理論を捨てろというのではなく、「理論を追うのは一部の役割」。あなたは「使って社会を変える人」になってください。

⸻

ご希望があれば、「普通のエンジニアが生成AI活用スキルを習得するロードマップ」 も作成します。必要でしたらお声かけください。

項目	内容
スキルセットの限界	数式・英語論文を日常的に読めるエンジニアはごく一部。
企業の体制	R&D部門を持たない企業が大半。研究ではなく「今あるものを現場で使えるようにする」能力が求められる。
リソースの制約	GPUクラスタや大規模データセット、数十人の研究チームを持てる企業は稀。

スキルカテゴリ	やるべきこと
基礎AI理解	Transformerの数式ではなく、「何ができて何ができないか」を理解（例：幻覚問題、トークン制限、ファインチューニングとは何か）
活用力	OpenAIやClaudeのAPIを触ってみる。LangChainやLlamaIndexの基本的な使い方を知る。
プロンプト設計	プロンプトの工夫で精度がどう変わるかを体感。社内の業務を一つGPTに置き換えてみる。
業務提案力	上司や顧客に対して「この業務、AIに置き換えられますよ」という提案を1つしてみる。これはキャリア上の評価にも直結。
ドキュメント読解	OpenAIのAPIドキュメント（日本語で読める）。基本的なREST API呼び出しを理解

Q4: 展開

上記のように、「普通のエンジニアはAIを『使う』ことが求められる」と思っているのですが、なぜ一方で日本のITエンジニアは数学的な理解にこだわったり、AI界のスタープレイヤーの後追いでより小さく、性能も低いモデルを作りたがるのでしょうか？個人的には、日本の理系教育の歪みが表れているように思いますが、いかがでしょうか？

A4

ご指摘は本質を突いています。確かに、「現実の課題にAIをどう使うか」より、「理論を深く理解しようとすること」や「自分でも小規模なモデルを構築しようとすること」に執着する日本のエンジニアは少なくありません。この現象は、以下のような教育的・文化的・構造的背景の複合的な結果だと考えられます。

⸻

🔍 1. 日本の理系教育の「数学偏重」主義

✅ 現象

日本の大学や高校の理系教育では「数式を正しく展開する」ことが重視され、応用や実装、問題解決への接続が軽視されがち。

実際、大学の情報系学部でも「線形代数の授業でNumPyを使わない」「機械学習の講義でscikit-learnやTensorFlowを触らない」といった例が多い。

🧠 結果

数式で「わかった気になる」学生やエンジニアが多く、ツールとしてのAIを使う経験が乏しい。

「理論を理解していないと使ってはいけない」という無意識の思い込み（≒使うことが“浅い”と感じる価値観）が形成される。

⸻

🔍 2. 日本の技術者文化に根強い「自前主義」・「ものづくり信仰」

✅ 現象

製造業的な価値観（＝最初から全部自分で作ることに価値がある）がITにも輸入されている。

OSS活用より「自社開発」、API連携より「自前実装」を美徳とする風潮が一部に残る。

🧠 結果

ChatGPTをAPIで呼び出すのではなく、「自分で小さなTransformerをPyTorchで作ってみた」という方が「技術者っぽい」と思われやすい。

スタープレイヤーの後追い（＝自社でも小さなモデルをトレーニング）を「正しい技術的努力」と信じて疑わない。

⸻

🔍 3. スター志向と「論文ありき」のリサーチ文化

✅ 現象

GAFAMやOpenAIのような先端企業は、精緻な論文＋GitHubコードという形で発信している。

日本の大学・研究所・ベンチャーの一部では、それを追いかけることで自分も“仲間入り”したような錯覚を得る。

🧠 結果

実ビジネスへの応用よりも、「うちもLLaMA風モデルを作ってみた」ことに満足してしまう。

数式や独自モデルにこだわるが、実際の活用事例や売上には結びつかない。

⸻

🔍 4. 評価軸のミスマッチ

✅ 現象

日本の多くの企業や研究所では、「AIを使って事業成果を出す」より「どれだけ理論を知っているか」のほうが評価されやすい。

特に中途採用や技術アピールでは、「Transformerを実装できます」と言う方が「ChatGPT APIを業務に使いました」よりインパクトがあると誤解されがち。

⸻

💡 結論：「理論へのこだわり」は日本の理系教育と技術者文化の副産物

「理論を理解していないと使ってはいけない」「自前で作ることこそ技術力だ」という誤った信仰が、AI時代の生存戦略を誤らせている。

そしてこれは、「英語が苦手で海外の実務事例にアクセスできない」「現場で評価される経験が少ない」といった構造的問題ともつながっています。

⸻

✅ これからの方向性

項目これから目指すべき姿

教育数式だけでなく、ツールとしてAIを使う演習を重視するカリキュラムへ

企業評価軸「何ができるか」よりも「何に役立ったか」で評価する文化

個人の戦略スターの後追いではなく、ローカルな課題にAIを適用するスキルを伸ばす

ご希望があれば、

日本のエンジニアがAI時代に生き残るためのスキルマップ

「理論ごっこ」から脱却する社内勉強会の企画案などもご提案できます。お気軽にどうぞ。

項目	これから目指すべき姿
教育	数式だけでなく、ツールとしてAIを使う演習を重視するカリキュラムへ
企業評価軸	「何ができるか」よりも「何に役立ったか」で評価する文化
個人の戦略	スターの後追いではなく、ローカルな課題にAIを適用するスキルを伸ばす

Q5: 比較

海外 (といってもさまざまですが) では、あまりそのような傾向はなく、「とにかく使えるもの、役立つものを作るのがエンジニア」という考えが浸透しているのでしょうか？そうであれば、それは大学までの教育の中で教えられているものなのでしょうか？

A5

とても鋭いご質問です。結論から言えば、「使えるものを作るのがエンジニア」という実践的な価値観は、欧米を中心とする多くの国々では確かに強く根付いています。そしてその価値観は、大学以前の教育も含めた「文化的・制度的な背景」によって育まれています。

⸻

🌍 海外のエンジニア文化：「役立つこと」が第一原理

✅ 特徴

プロトタイプを素早く作って動かしてみることが尊重される（例：米シリコンバレーやインドのスタートアップ文化）

数式や理論に詳しいかどうかよりも、動くものを作って試すことが優先。

「学問的に正しい」よりも「課題解決に使える」ことが評価される。

🛠 事例

OpenAI や Anthropic の研究開発チームですら、「まず実装して観察する→理論的な裏付けを後からつける」という逆順で進めていることが多い。

米国の大手企業（Google, Metaなど）でも、リサーチャーよりも「Applied Scientist」や「ML Engineer」がプロダクトの中核。

⸻

🎓 大学教育の違い：日本 vs 海外

観点日本海外（米国・欧州の一例）

教育方針正解のある問題を解かせる自分で問いを立て、手を動かして解決する

評価軸数式展開の正確さ、理論の理解プロトタイピング、ツールの活用力

卒業研究指導教員のテーマに従うことが多い学生が自分で問題を設定する自由度が高い

インターン少ない・就職活動と切り離されがち多くの学生が大学在学中に実務経験を積む

🧑‍💻 実践重視の具体例

米スタンフォード大学やMITのCS課程では、課題の多くが「動くプロダクトを作ること」。

「最低限の理論を学んだら、あとは実装を通じて体得する」スタイルが主流。

特にハッカソン文化が盛んで、「1日で作って試す→フィードバックを受ける」という訓練が積み重ねられている。

⸻

🧠 文化的背景の違い

日本欧米（特に米国）

深く理解してから使え使いながら理解せよ

理論が身につけば実装できる実装できれば、理論も後からついてくる

失敗してはいけない失敗から学ぶのが自然

この文化の違いが、AIやSaaS、スタートアップ文化の成熟度にも直結しています。

⸻

✍️ まとめ

欧米の多くのエンジニア教育では、「動くものを作る」「価値を生む」ことが最優先。

それは大学教育だけでなく、K-12（小中高）や社会全体の文化から醸成されている。

一方、日本では「まず理論ありき」「間違えることを恐れる」という文化が、実装重視のマインド形成を阻んでいる。

⸻

✅ ご参考になりそうな方向性：

日本でも、「教育」と「実務」のあいだにプロトタイプ主義・API活用主義を入れる中間教育（リスキリング・職業教育）が今後重要。

「役立つものを作る」エンジニアを育てるには、大学よりも現場主導の学び直しの場（例：社内ラボ、実務インターン、実装コンペなど）を活用するのが近道です。

ご希望があれば、こうした価値観を育てる教育プログラムの例や、API活用・プロトタイピング型の社内教育モデルなどもご提案できます。お気軽にどうぞ。

観点	日本	海外（米国・欧州の一例）
教育方針	正解のある問題を解かせる	自分で問いを立て、手を動かして解決する
評価軸	数式展開の正確さ、理論の理解	プロトタイピング、ツールの活用力
卒業研究	指導教員のテーマに従うことが多い	学生が自分で問題を設定する自由度が高い
インターン	少ない・就職活動と切り離されがち	多くの学生が大学在学中に実務経験を積む

日本	欧米（特に米国）
深く理解してから使え	使いながら理解せよ
理論が身につけば実装できる	実装できれば、理論も後からついてくる
失敗してはいけない	失敗から学ぶのが自然

(人間による) おわりに

まぁ、議論を誘導している面はあるんですが、そんなに見当違いのことを考えてもいなかったのかなと思っています。「どうやっても追いつけないものを追うより、それを使って何かできないか」を考えるのが、サイエンティストではなくエンジニアだと思うので、ぜひそういう方向に教育も変わっていけばいいのにな、と思います。

参考

当然、小学校や中学校でディープラーニングだTransformerだわかるわけがないですが、それでも子供たちはAIを「使う」ことを学ぶわけです。

生成AIはシグマ計画の夢を見るか？

Mon, 31 Mar 2025 00:00:00 +0000

以下は、私がよく考えていることについて、Gemini 2.5 Proと対話した記録です。ChatGPT 4.5, o1とも同じ対話をしましたが、群を抜いてGemini 2.5 Proの回答が良いように感じました。良い = 私にとってキモチイイなので、正しいかとか妥当かとかは分かりませんが。

Q1

1980年代に日本で通商産業省の主導で行われたΣ(シグマ) プロジェクトについて、まず概要をまとめて、自身でよく理解してください。一般的には、コンピューター産業における生産性向上や人手不足に対処するために計画された国家プロジェクトだとされています。

A1

はい、承知いたしました。1980年代に日本の通商産業省（現・経済産業省）主導で行われたΣ（シグマ）プロジェクトについて、まず概要をまとめ、その上で私自身がどのように理解したかを述べます。

Σ（シグマ）プロジェクトの概要

名称: Σ（シグマ）プロジェクト (Software Industrialized Generator and Maintenance Aids)
- 「Σ」はギリシャ文字で「総和」を意味し、ソフトウェア開発に関わる技術やツール、人材などを結集・統合することを目指したことを示唆しています。
時期: 1985年度から1990年度までの5年間（実質的な活動や準備はその前後にも及ぶ）
主導: 通商産業省（現・経済産業省）
- 実施主体として情報処理振興事業協会（IPA）が中心となり、国内の主要コンピュータメーカー、ソフトウェアハウス、ユーザー企業、大学など100社以上が参加しました。
背景:
- ソフトウェア危機: 1980年代、コンピュータの高性能化・普及に伴い、ソフトウェア開発の需要が急増。しかし、開発の生産性や品質が追いつかず、納期遅延、コスト超過、信頼性低下、技術者不足といった問題（ソフトウェア危機）が深刻化していました。
- 産業構造の変化: ハードウェア中心からソフトウェア・情報サービス中心への産業構造の変化が見込まれ、日本の国際競争力維持・向上のためにはソフトウェア産業の強化が不可欠とされました。
- 欧米への対抗: 米国や欧州でも同様の問題意識から国家的なソフトウェア開発プロジェクト（米：Ada計画、STARS計画、欧：ESPRIT計画など）が進められており、日本も国策として取り組む必要性が認識されました。
目的:
- ソフトウェア生産性の飛躍的向上: 当時の数倍の生産性を目指しました。
- ソフトウェア品質の向上と信頼性の確保:
- ソフトウェア開発技術者の育成と不足解消:
- ソフトウェア開発の工業化: 属人的な「職人芸」に頼るのではなく、標準化されたツールや部品を用いて効率的に開発できる体制（ソフトウェア工場）を目指しました。
- ソフトウェア資産の蓄積と再利用の促進:
主な取り組み内容:
- Σシステム（統合開発環境）の開発:
  - ΣOS: UNIX System Vをベースに、日本語処理機能や共通インタフェースなどを追加・標準化したOS。ワークステーション（Σワークステーション）上で稼働。
  - Σツール: ΣOS上で動作する、エディタ、コンパイラ、デバッガ、文書作成ツール、プロジェクト管理ツール、CASE（Computer-Aided Software Engineering）ツール群など、ソフトウェア開発の全工程を支援するツール。
- ソフトウェア部品（SWB: Software Base）の流通促進:
  - 再利用可能なソフトウェア部品を作成・登録し、品質を保証した上で流通させる仕組みを構築しようとしました。
- Σセンターの設立・運営:
  - プロジェクトの中核拠点。開発されたΣシステム環境の提供、ソフトウェア部品の登録・管理・流通、技術情報の提供、人材育成、参加企業間の連携促進などを担いました。
- Σネットワークの構築:
  - Σセンターと参加企業、大学などを結ぶ全国規模のコンピュータネットワーク。分散開発環境の提供や情報交換を目的としました。
投入された予算: 約250億円（当時の国家予算としては巨額）

私自身の理解

上記概要を踏まえ、Σプロジェクトについて以下のように理解しました。

時代を先取りした壮大な構想: Σプロジェクトは、単なる個別技術の開発ではなく、「ソフトウェア開発の工業化」という大きな目標を掲げ、OS、ツール、部品、ネットワーク、人材育成までを包含する統合的なエコシステムを国家主導で構築しようとした、非常に野心的な試みでした。ソフトウェア部品の再利用やネットワークによる分散開発といったコンセプトは、後のオブジェクト指向、コンポーネントベース開発、近年のクラウド開発環境やオープンソースコミュニティの隆盛などを考えると、先見性があったと言えます。
「ソフトウェア危機」への真摯な取り組み: 当時、世界的に課題となっていたソフトウェア開発の生産性や品質の問題に対し、日本が国として正面から向き合い、巨額の投資と多くの人材を結集して解決しようとした姿勢は評価されるべきです。ハードウェアでの成功体験をソフトウェア分野でも再現しようという意気込みが感じられます。
標準化の理想と現実のギャップ: プロジェクトの成否を分けた大きな要因の一つが「標準化」の難しさだったと理解しています。多種多様な企業の利害が絡む中で、真に実用的で受け入れられる標準を作り上げ、それを維持・発展させていくことの困難さが露呈しました。各社がΣシステムを自社製品に取り込む際に独自拡張を加えるなど、標準からの乖離が見られました。これは、トップダウン型の標準化と、市場原理や現場の多様なニーズとの間に溝があったことを示唆しています。
技術変化のスピードとの戦い: 5年というプロジェクト期間は、当時のソフトウェア・ハードウェア技術の急速な進化に追いつくには長すぎた面があります。プロジェクト開始時に最先端だった技術（UNIXワークステーションなど）も、終了時には必ずしも優位性を保てなくなっていました。特に、PCの高性能化や商用UNIX、開発ツールの急速な進化が、Σシステムの相対的な魅力を低下させました。大規模プロジェクトにおける計画の硬直性と、変化の速い技術分野とのミスマッチという課題を浮き彫りにしました。
「成功」か「失敗」かの単純な二分論では語れない: 一般的にΣプロジェクトは「失敗」だったと評価されることが多いですが、その側面だけで捉えるのは短絡的かもしれません。目標とした生産性の飛躍的向上や部品流通の活性化は達成できなかったものの、以下の点で一定の意義があったと考えます。
- UNIXとソフトウェア工学の普及: 日本国内におけるUNIXの認知度向上や日本語環境整備、CASEツールの概念導入などに貢献しました。
- 人材育成: プロジェクトを通じて多くの技術者がソフトウェア開発技術やプロジェクトマネジメントを学びました。
- 産官学連携の経験: 大規模な共同研究開発プロジェクトの運営ノウハウや課題が蓄積され、後のプロジェクトに活かされる素地となりました。
- 教訓: 国家主導の技術開発プロジェクトのあり方、標準化戦略、技術変化への対応など、多くの貴重な教訓を残しました。オープンソースのようなボトムアップ型の開発・普及モデルと比較することで、その特徴や限界がより明確になります。

総括: Σプロジェクトは、日本のソフトウェア産業の未来を見据えた壮大な国家プロジェクトであり、その構想には先見性がありましたが、技術変化の速さ、標準化の難しさ、市場との連携不足など、多くの課題に直面し、当初の目標を達成するには至りませんでした。しかし、その挑戦と結果は、日本の情報技術史において重要な一章をなし、後の技術開発や産業政策に多くの示唆を与えたプロジェクトであったと理解しています。

Q2

あなたが調査したことと、以下の項目を踏まえて質問します。

現在ではオープンソースソフトウェアの考え方が浸透しており、各社や大学で開発されたソフトウェアが共有されるようになっています。
ChatGPTをはじめとした生成AIの性能が飛躍的に向上し、実用的なソフトウェアをAIが開発できるようになっています。
AIが開発したプログラムがオープンソースソフトウェア (あるいはAI自身の学習用データ) として共有されることが現実になっています。
ノーコード、ローコード開発プラットフォームの発展で、「部品を並べる」ことで非エンジニアでも業務アプリが開発できるようになっています。

これらを踏まえると、現在において、シグマ計画の当時の目的に類する「官民共同の国家的プロジェクトによるソフトウェアの部品化と、部品を組み合わせることで非熟練者が実用的なソフトウェアを開発できるようになることによる、人材不足の解消」ということは、実現可能であると考えられますか？

A2

ご指摘の現代の技術動向（OSSの浸透、生成AIの進化、ノーコード/ローコードの発展）を踏まえて、Σプロジェクトが目指した「官民共同の国家的プロジェクトによるソフトウェアの部品化と、部品を組み合わせることで非熟練者が実用的なソフトウェアを開発できるようになることによる、人材不足の解消」が現在において実現可能か、というご質問ですね。

結論から申し上げると、Σプロジェクトと全く同じアプローチでの実現は困難かつ現代的ではありませんが、その根底にある目的（ソフトウェア開発の効率化・民主化による人材不足解消）を達成するための、現代技術に即した形での官民共同プロジェクトは十分に実現可能であり、かつ意義があると考えられます。

以下に理由を述べます。

なぜΣプロジェクトと「全く同じ形」は困難・非現代的なのか

技術環境の劇的な変化:
- OSSエコシステムの成熟: Σプロジェクトが目指した「部品の共有・再利用」は、GitHubなどのプラットフォームと活発なOSSコミュニティによって、国家プロジェクトの手を借りずともグローバル規模で実現されています。特定の国家標準を押し付けるよりも、この既存エコシステムを活用・貢献する方が現実的です。
- クラウドと分散開発: ΣプロジェクトがΣネットワークで目指した分散開発環境は、クラウドサービスによって遥かに高度な形で実現されています。
- デファクトスタンダードの力: 特定のOS（ΣOS）やツール群を国家が規定するアプローチは、すでに存在する多様なデファクトスタンダード（各種OS、開発言語、フレームワーク、クラウドサービス）との整合性を取るのが難しく、開発者の選択肢を狭め、国際競争力を削ぐ可能性があります。
イノベーションの源泉の変化:
- 現代のソフトウェア技術革新は、オープンなコミュニティや、アジャイルな開発手法をとる民間企業（特にスタートアップ）から生まれることが多くなっています。トップダウン型の国家プロジェクトが、このスピード感や多様性に対応するのは容易ではありません。
Σプロジェクトの教訓:
- Σプロジェクト自身が、技術変化への追随の難しさ、標準化の困難さ、市場ニーズとの乖離といった課題に直面しました。これらの教訓は現代にも当てはまります。

なぜ現代的な形でのプロジェクトは実現可能で意義があるのか

現代の技術（OSS、生成AI、ノーコード/ローコード）は、Σプロジェクトが目指した目的を達成するための強力なツールとなり得ます。官民共同プロジェクトは、これらの技術の 活用を加速し、課題を解決する 役割を担うことで、目的達成に貢献できます。

生成AIの活用促進と課題解決:
- 実現可能性: 生成AIは、非熟練者でも自然言語で指示することでコードを生成したり、熟練者の生産性を大幅に向上させたりする可能性を秘めています。
- 国家プロジェクトの役割:
  - 信頼性・品質向上: AIが生成するコードの品質評価、セキュリティ脆弱性チェック、テスト自動化技術の研究開発支援。
  - データ整備: 高品質な日本語コードデータセットや、特定ドメイン（例: 行政手続き、社会インフラ）の学習データ整備。
  - 人材育成: AIを効果的に活用できるエンジニア、AI生成コードをレビュー・修正できる人材の育成。プロンプトエンジニアリング教育。
  - 倫理・法的課題の整理: AI生成コードの著作権、責任の所在、OSSライセンスとの整合性などに関するガイドライン策定。
OSSエコシステムへの貢献と活用深化:
- 実現可能性: 既存のOSSという「部品」を最大限活用し、さらに日本の強み（例: 特定産業分野の知見）を活かしたOSSを開発・公開することで、開発効率と国際競争力を高められます。
- 国家プロジェクトの役割:
  - セキュアなOSS利用環境整備: SBOM（ソフトウェア部品表）の普及促進、脆弱性管理体制の強化支援。
  - 国内OSSコミュニティ支援: 重要分野におけるOSS開発プロジェクトへの資金的・技術的支援。
  - 政府調達におけるOSS活用推進:
ノーコード/ローコードの普及促進:
- 実現可能性: まさに「部品を並べる」感覚で非エンジニアがアプリ開発できる環境であり、業務部門主導のDX（デジタルトランスフォーメーション）や市民開発者の育成に直結します。
- 国家プロジェクトの役割:
  - 導入支援: 特にIT人材が不足しがちな中小企業や地方自治体への導入コンサルティング、補助金制度。
  - 人材育成: 市民開発者向けの教育プログラム開発・提供。
  - プラットフォーム間の連携・標準化検討: 過度なベンダーロックインを防ぎ、データ連携などを容易にするための緩やかな標準化やガイドラインの検討。
官民連携による相乗効果:
- 国は、個々の企業では取り組みにくい基盤的な研究開発、標準化・ルール作り、人材育成、実証実験の場を提供できます。
- 民間企業は、市場ニーズに基づいた技術開発、サービス提供、エコシステム形成を主導します。
- 大学・研究機関は、基礎研究や先端技術開発を担います。

まとめ

Σプロジェクトが目指した「ソフトウェア部品化と非熟練者による開発による人材不足解消」という目的自体は、現代においても重要性を失っていません。むしろ、DX推進や労働人口減少といった課題を背景に、その重要性は増しています。

ただし、その実現手段は、Σプロジェクトのような国家主導の統合環境構築ではなく、OSS、生成AI、ノーコード/ローコードといった現代の技術トレンドを最大限に活用し、その普及と高度化、そして利用上の課題解決を官民連携で支援する形へとシフトすべきです。

このような現代的なアプローチをとるのであれば、官民共同の国家プロジェクトは十分に 実現可能 であり、日本のソフトウェア開発力強化と人材不足解消に大きく貢献できると考えられます。重要なのは、過去の教訓を活かし、トップダウンの押し付けではなく、現場のニーズやグローバルな技術動向に合わせた柔軟な支援策を設計・実行することです。

Q3

もし上記のような現状を踏まえて「現代のシグマプロジェクト」を実行する場合、産官学それぞれのセクターにおいて、具体的・現実的にどのような取り組みを行う必要があるでしょうか。また、取り組む上での課題についても具体的に教えてください。

A3

承知いたしました。「現代版Σプロジェクト」を実行する場合、産官学それぞれのセクターが具体的・現実的にどのような取り組みを行うべきか、そしてその際の課題について述べます。

ここでの「現代版Σプロジェクト」とは、Σプロジェクトの根源的な目的である 「ソフトウェア開発の効率化・民主化による人材不足解消」 を、現代の技術（OSS、生成AI、ノーコード/ローコード等）を活用して達成するための、官民連携によるエコシステム形成支援と位置づけます。

産（民間企業）

【具体的な取り組み】

生成AIの積極導入と開発プロセス革新:
- 設計支援、コード生成、テスト自動化、ドキュメント生成、コードレビュー支援等に生成AIツールを導入し、開発者の生産性向上と負担軽減を図る。
- AI活用を前提とした新しい開発ワークフローを構築・標準化する。
- AIが生成したコードの品質管理・レビュー体制を確立する。
OSSエコシステムへの貢献と活用深化:
- 自社の汎用的な技術やツールを積極的にOSSとして公開し、コミュニティからのフィードバックを得て改善する。
- 重要な外部OSSプロジェクトへコントリビュート（コード提供、バグ報告、寄付等）し、開発に参加・支援する。
- SBOM（ソフトウェア部品表）の導入・活用により、利用するOSSのライセンスや脆弱性を適切に管理する体制を構築する。
ノーコード/ローコードプラットフォームの戦略的活用:
- 定型的な業務アプリやプロトタイプ開発にノーコード/ローコードを導入し、業務部門主導のDX（市民開発）を推進する。
- 導入にあたっては、適切なガバナンス体制（利用ルール、セキュリティ基準、データ管理等）を整備する。
ソフトウェア部品・APIの整備と共有（オープンイノベーション）:
- 業界共通で利用可能な機能やデータをAPIとして整備・公開し、他社やスタートアップとの連携を促進する。
- 自社の強みとなる特定ドメイン（例：製造業における制御ソフト部品、金融業におけるリスク計算モジュール等）のソフトウェア部品を開発し、限定的な範囲での共有や販売も検討する。
人材育成・リスキリング:
- 既存エンジニアに対し、AI活用（プロンプトエンジニアリング、AI生成コードレビュー）、OSS開発・貢献、ノーコード/ローコード活用に関する研修を実施する。
- 非エンジニア向けのデジタルリテラシー教育、市民開発者育成プログラムを導入する。

【取り組む上での課題】

AIの信頼性と説明責任: AIが生成したコードの品質、セキュリティ、著作権侵害リスクをどう担保し、問題発生時の責任をどう負うか。
技術・文化の変革抵抗: 既存の開発プロセスやツールへの固執、OSS利用への心理的・契約的障壁、内製化やアジャイル開発への移行に伴う組織文化の変革。
人材獲得と育成: 高度なAI/OSSスキルを持つ人材の獲得競争激化と、社内育成のコスト・時間。
セキュリティとガバナンス: OSS利用やノーコード/ローコード導入拡大に伴うセキュリティリスク（脆弱性混入、シャドーIT化）と、それを管理するガバナンス体制の構築。
投資対効果の見極め: 新技術導入にかかるコスト（ツール導入費、教育費、体制構築費）と、生産性向上効果の測定・評価の難しさ。

官（政府・自治体）

【具体的な取り組み】

基盤整備とルール形成:
- AI関連:
  - AI生成コードの品質評価基準やテスト手法に関する研究開発支援。
  - AI開発・利用に関する倫理ガイドライン、AI生成物の著作権や責任の所在に関する法的論点の整理と指針提示。
  - 高品質な日本語学習データセット（コード、技術文書等）、特に公共性の高いドメイン（行政、医療、防災等）のデータの整備・公開。
- OSS関連:
  - SBOM（ソフトウェア部品表）作成・活用の普及促進策（補助金、ガイドライン策定）。
  - OSSの脆弱性情報共有プラットフォーム（例：JVNの強化）や、セキュアなOSS開発手法の研究開発支援。
- データ連携基盤:
  - 分野横断的なデータ連携を促進するためのAPI標準化やデータフォーマット整備。
活用促進と市場形成支援:
- 導入支援: 中小企業や地方自治体におけるAIツール、OSS、ノーコード/ローコード導入に対する補助金、税制優遇、専門家派遣などの支援策。
- 政府調達: 政府・自治体のシステム調達において、OSSやAI活用ツール、ノーコード/ローコードプラットフォームの利用を積極的に評価・採用する方針を明確化。
- 公共ソフトウェアのオープン化: 政府が開発したソフトウェアやシステム（可能な範囲で）をOSSとして公開、またはAPIを公開し、民間での活用を促進。
- 実証フィールド提供: 新技術（特にAI関連）を試せるサンドボックス環境や、官民連携での実証プロジェクトを推進。
人材育成支援:
- 大学・高専等におけるAI/OSS/ノーコード活用を前提としたカリキュラム改訂への支援。
- 社会人向けの高度デジタル人材育成プログラム、リスキリング支援策の拡充（助成金、認定制度）。
- 初等・中等教育におけるプログラミング教育、情報リテラシー教育の強化。

【取り組む上での課題】

政策のスピードと柔軟性: 急速な技術進化に対し、政策決定や法整備が追いつかないリスク。硬直的な制度にならないような設計。
省庁間の連携と縦割り打破: デジタル庁を中心としつつも、各省庁が持つドメイン知識や権限を効果的に連携させる必要性。
グローバル標準との整合性: 国内施策が国際的な技術標準やルール（特にAI倫理やデータ流通）から乖離しないような配慮。
公平性と中立性: 特定の企業や技術に偏らない、公平な支援策やルール作り。
実効性の担保と評価: 策定した施策が実際に現場で活用され、効果を発揮しているかを継続的に測定・評価し、改善していく仕組み。
予算確保と継続性: 長期的な視点での安定した予算確保と、政権交代等に左右されないプロジェクト継続性の担保。

学（大学・研究機関）

【具体的な取り組み】

先端的な基礎・応用研究:
- より高度で信頼性の高いコード生成AI、ソフトウェアの自動デバッグ・修正AI、設計自動化AIなどの研究開発。
- AI生成コードの品質保証、形式的検証、説明可能性（Explainable AI）に関する研究。
- セキュアなソフトウェア開発ライフサイクル、OSSサプライチェーンセキュリティに関する研究。
- 人間とAIが効果的に協働するためのソフトウェア工学的手法、開発環境の研究。
- 特定分野（例：高信頼性が求められる組込みシステム、大規模科学技術計算）におけるAI/OSS活用技術の研究。
次世代人材の育成:
- 最新のAI技術、OSS開発手法、ソフトウェア工学、セキュリティ、倫理などを体系的に学べる教育カリキュラムを提供。
- 企業との連携によるインターンシップ、共同研究プロジェクト等を通じた実践的な教育機会の提供。
- 分野横断的な知識（例：法律、倫理、特定産業ドメイン知識）を持つソフトウェア人材の育成。
知見の社会還元と連携:
- 研究成果を論文だけでなく、OSSや技術レポートとして積極的に公開。
- 産業界向けの技術セミナー、勉強会の開催。
- 企業との共同研究、技術コンサルティング、研究者のスピンアウト（大学発ベンチャー）支援。
- 政府の政策立案に対する専門的知見の提供。

【取り組む上での課題】

研究と実用化のギャップ: 基礎研究の成果が、産業界で実際に使われる技術・製品になるまでの「死の谷」の克服。
産学連携の深化: 産業界の真のニーズを捉えた研究テーマ設定、企業との円滑なコミュニケーションと連携体制の構築。
分野横断的研究体制: ソフトウェア工学、AI、セキュリティ、法学、倫理学など、多様な分野の研究者が連携する体制の構築。
教育者の確保とアップデート: 最先端技術を教えられる教員の確保、および既存教員の知識アップデート。
研究資金の確保: 長期的・基礎的な研究に対する安定した資金確保。
知財戦略: オープンサイエンスの流れと、研究成果の適切な権利保護（特許化など）とのバランス。

連携の重要性と課題

現代版Σプロジェクトの成功には、産官学がそれぞれの強みを活かし、弱みを補い合いながら、共通の目標に向かって緊密に連携することが不可欠です。

連携における課題:
- 目的・ビジョンの共有: 各セクターの利害や文化の違いから、共通の目標設定や達成へのコミットメントが難しい場合がある。
- コミュニケーション: 立場や専門用語の違いによるコミュニケーションギャップ。
- スピード感の違い: 意思決定や実行のスピード感が異なり、連携の足枷となることがある（特に官・学と産のスピード感の違い）。
- 役割分担と責任の曖昧さ: プロジェクトにおける各主体の役割分担や責任の所在が不明確になるリスク。

これらの課題を克服するためには、強力なリーダーシップ、明確な目標設定、オープンなコミュニケーションチャネル、柔軟な運営体制、そしてΣプロジェクトの失敗からも学んだ「現場主義」「市場原理の尊重」といった視点が重要になります。

Q4

もし、上記のような新しい形での政策的支援が行われ、産官学の共同によるプラットフォーム構築がうまく行った場合、現在ITエンジニアと名乗っている人たちの働き方や求められるスキルセット、マインドセットはどのように変わってきますか？また、どのような困難に直面することが予想されるでしょうか。変化に対応することができず淘汰される人もいるのでしょうか？

A4

もし「現代版Σプロジェクト」のような政策的支援が進み、AI、OSS、ノーコード/ローコード活用を前提とした産官学連携プラットフォームがうまく機能した場合、ITエンジニアの働き方、求められるスキルセット、マインドセットは大きく変化すると考えられます。それに伴う困難や、適応できない場合の淘汰の可能性についても考察します。

働き方の変化

AIとの協働が前提に:
- コーディング作業の変容: 単純なコード生成、バグ修正、テストコード作成、ドキュメント生成などはAIが担う割合が増え、エンジニアはAIへの指示（プロンプトエンジニアリング）、AI生成物のレビュー・評価・修正、より複雑なロジックの実装に注力します。
- 設計・レビュー中心へ: 要件定義、アーキテクチャ設計、AI生成コードの品質担保、セキュリティレビューなど、より上流工程や品質保証に関わる業務の比重が高まります。
OSS活用・貢献の常態化:
- ゼロから作るのではなく、既存のOSSを組み合わせて迅速に開発することが主流になります。
- 利用するOSSの選定、ライセンス管理、脆弱性対応（SBOM活用含む）、コミュニティへの貢献（バグ報告、改善提案、コード提供）などが日常業務の一部となります。
開発の民主化と協業:
- ノーコード/ローコードで業務部門が開発したアプリケーションとの連携や、より高度な機能の追加、ガバナンス管理などをエンジニアが担います。
- 非エンジニア（市民開発者）への技術的なアドバイスやサポートを行う機会も増える可能性があります。
アジャイル・実験的アプローチの加速:
- AIやツールの活用により開発サイクルが短縮され、プロトタイピングや仮説検証を素早く繰り返し、フィードバックを得ながら開発を進めるスタイルがより浸透します。
コミュニケーションの重要性増大:
- AI、OSSコミュニティ、他部署の担当者（ビジネスサイド、市民開発者含む）など、多様なステークホルダーと円滑に連携するためのコミュニケーション能力がこれまで以上に重要になります。

求められるスキルセットの変化

AI活用能力:
- プロンプトエンジニアリング: AIに対して的確かつ効果的な指示を与える能力。
- AI生成物の評価・監査能力: AIが生成したコードや設計の品質、セキュリティ、妥当性を評価し、修正できる能力。
- AIツールの知識と活用能力: 各種AI開発支援ツールを理解し、プロジェクトに応じて適切に選択・活用できる能力。
OSS関連スキル:
- 目利き能力: 膨大なOSSの中から、品質、セキュリティ、ライセンス、コミュニティの活発さなどを考慮して適切なものを選定する能力。
- 管理・運用能力: SBOMを用いた依存関係管理、ライセンスコンプライアンス、脆弱性対応のスキル。
- 貢献スキル: OSSコミュニティに参加し、効果的に貢献するための技術力とコミュニケーション能力（英語力含む）。
高度な設計・アーキテクチャ能力:
- AIやOSS、ノーコード/ローコードなど、多様なコンポーネントを組み合わせ、拡張性、保守性、信頼性、セキュリティの高いシステム全体を設計する能力。クラウドネイティブ、マイクロサービス、API設計などの知識。
特定分野の深い専門性:
- セキュリティ、データサイエンス、機械学習、クラウドインフラ、特定ドメイン（金融、医療、製造など）といった、AIによる自動化が難しい領域における高度な専門知識。
ソフトスキル:
- 問題解決能力: 技術的な課題だけでなく、ビジネス上の課題を理解し、技術で解決策を提案・実装する能力。
- コミュニケーション能力: 多様な関係者と効果的に意思疎通を図る能力。
- 学習意欲・自己変革能力: 常に変化する技術トレンドを学び続け、自身をアップデートしていく能力。
- 抽象化・モデル化能力: 複雑な事象を整理し、本質を捉えて設計に落とし込む能力。

求められるマインドセットの変化

変化への適応と学習意欲: 新しい技術やツールを恐れず、積極的に学び、試す姿勢。現状維持ではなく、常に改善を求めるマインド。
協調性とオープンマインド: AIやOSS、他の開発者（社内外問わず）との協力を前提とし、オープンな議論やフィードバックを受け入れる姿勢。
課題解決志向: 「コードを書くこと」自体が目的ではなく、「技術で課題を解決すること」を目的とする意識。
品質・セキュリティへの当事者意識: AIやOSSを利用しても、最終的なプロダクトの品質とセキュリティに対する責任は開発者が負うという意識。
自動化・効率化への前向きな姿勢: 定型作業はツールに任せ、自身はより創造的で付加価値の高い業務に集中しようとする意識。

直面する困難

スキルの陳腐化と再学習のプレッシャー: 従来のコーディングスキルだけでは不十分となり、AI活用スキルや設計能力など、新しいスキルセットの習得が継続的に求められます。この学習コストやスピードについていけない可能性があります。
役割変化への抵抗感: 実装作業が減り、レビューや設計、コミュニケーションの比重が増えることに対して、「手を動かしたい」「人と話すのが苦手」といった理由で抵抗を感じるエンジニアもいるでしょう。
AIへの依存と能力低下のリスク: AIに頼りすぎることで、基本的なプログラミング能力や問題解決能力が低下する懸念があります。また、AIの生成物を鵜呑みにすることによる品質低下やセキュリティリスクも考えられます。
評価基準の変化への戸惑い: コード行数や実装スピードといった従来の指標ではなく、設計の質、AIの活用度、問題解決への貢献度などが評価されるようになり、その変化に対応できない可能性があります。
雇用・キャリアへの不安: 開発効率化が進むことで、特に単純作業を主としていたエンジニアの需要が減るのではないか、自分のキャリアパスはどうなるのか、といった不安を感じることが予想されます。

淘汰の可能性について

変化に対応できない、あるいは対応しようとしないエンジニアが淘汰される（市場価値が低下し、活躍の場が狭まる）可能性は十分にあります。

単純なコーディング作業しかできない、あるいはそれに固執するエンジニア。
新しい技術（特にAI）の学習を怠るエンジニア。
コミュニケーションを避け、チームでの協働ができないエンジニア。
品質やセキュリティへの意識が低いエンジニア。

これらに該当する場合、AIや他の高スキルエンジニアに代替されやすくなり、より付加価値の低い業務へ追いやられたり、最悪の場合、職を失ったりするリスクが高まります。

ただし、これは「ITエンジニア」という職種自体が不要になるという意味ではありません。むしろ、AIやツールを使いこなし、より高度な設計や複雑な問題解決、新しい価値創造を担えるエンジニアの需要は、これまで以上に高まると考えられます。

結論として、現代版Σプロジェクトのような取り組みが成功すれば、ITエンジニアの仕事はより高度化・専門化し、AIやツールとの協働が前提となります。この変化に適応し、必要なスキルとマインドセットを獲得できたエンジニアは、より重要な役割を担い活躍の場を広げるでしょう。一方で、変化に適応できない場合は、その立場が厳しくなる可能性が高いと言えます。エンジニア一人ひとりにとって、継続的な学習と自己変革が不可欠な時代になるでしょう。

Q5

一方で、日本におけるIT業界の人材は、単に給料がよいから、今後成長する業界だから、人手不足だから入社しやすかった、など必ずしもITや周辺の技術に興味関心を持ち、学び続ける意欲が多い人ばかりではありません。むしろ、大手SIerなど、歴史のある大企業ほど、学歴や「コミュニケーション力」を重視して採用しており、「わざわざ業務時間外に、自費で勉強したくない」人が多いかもしれません。そのような構造を踏まえると、今議論しているような社会の変化が起こった時に、どのような問題が生じるでしょうか？

A5

ご指摘の点は、日本のIT業界が抱える構造的な問題を鋭く突いており、「現代版Σプロジェクト」のような変革が理想通りに進むことの難しさを示唆しています。技術への興味関心が必ずしも高くない層や、自己学習意欲が低い層が多いという現実を踏まえると、以下のような深刻な問題が生じる可能性が高いと考えられます。

生じうる問題

スキルミスマッチの深刻化と二極化:
- 変化への追随困難層の増加: AI活用、高度なOSS利用、設計能力といった新しいスキルセットの習得は、強い意欲と継続的な学習が不可欠です。「わざわざ業務時間外に勉強したくない」層にとっては、この変化についていくことが極めて困難になります。
- 業務の空洞化: AIやツールによって自動化されるのは、まさにこれまで「人海戦術」や「ルーチンワーク」として多くの人員が担ってきた部分です。これらの業務に従事していた層の仕事が減少し、より高度なスキルを持つ層との間に大きなスキルギャップ（二極化）が生じます。
- 「指示待ち」人材の行き詰まり: 学歴や「コミュニケーション力（調整力）」で評価されてきた人材の中には、自ら技術を深く理解し、主体的に課題解決に取り組む姿勢が弱い場合があります。AIへの的確な指示出しや、生成物の本質的な評価ができず、価値を発揮しにくくなる可能性があります。
生産性向上のボトルネック化:
- ツールの形骸化: 企業がAIツールやノーコード/ローコード基盤を導入しても、現場のエンジニアがそれを効果的に活用できなければ、投資対効果は上がりません。導入自体が目的化し、実際の生産性向上には繋がらない「なんちゃってDX」に陥る可能性があります。
- 品質・セキュリティリスクの増大: AI生成コードやOSSの利用には、その仕組みやリスクを理解した上での適切なレビューと管理が不可欠です。技術への理解が浅いままツールを使うと、潜在的なバグや脆弱性を見逃し、かえって品質やセキュリティを低下させるリスクがあります。
- 既存プロセスへの固執: 新しいツールや手法を導入しても、従来のウォーターフォール型開発プロセス、多重下請け構造、品質管理基準などが変わらなければ、その効果は限定的です。「変化を嫌う」文化が根強い企業では、この傾向が顕著になります。
組織・人事制度の機能不全:
- 評価と処遇のミスマッチ: 新しいスキル（AI活用、OSS貢献、設計能力など）を正しく評価できない既存の人事制度（年功序列、管理職偏重など）では、変化に対応できる優秀な人材が報われず、モチベーションが低下します。結果として、そのような人材はより適切な評価・待遇を求めて流出しやすくなります。
- リスキリングの限界: 企業がリスキリング施策を打っても、本人の学習意欲が低ければ効果は薄く、形式的な研修で終わってしまう可能性が高いです。「やらされ感」の強い研修では、実務で活かせるスキルは身につきにくいでしょう。
- 採用の歪み: 「コミュニケーション力」重視の採用を続けていると、技術変化に対応できるポテンシャルを持つ人材を取りこぼし、ますます組織の技術力が低下していく可能性があります。
多重下請け構造の弊害増幅:
- 下請けへの負担転嫁: 元請けSIerがAI等を導入して効率化を図っても、その恩恵が下請け企業に適正に還元されず、むしろ単価削減圧力や、より困難な（AIでは代替できない）作業の押し付けにつながる可能性があります。
- スキル格差の固定化・拡大: 元請けが上流工程やAI活用（レビュー等）を担い、下請けがレガシー保守や単純作業に固定化されるという、スキル・技術レベルの格差がさらに深刻化する恐れがあります。
産業全体の競争力低下:
- イノベーションの停滞: 業界全体として新しい技術への適応が遅れることで、グローバルな競争から取り残され、日本のIT産業全体の国際競争力がさらに低下するリスクがあります。
- 社会的なデジタル化の遅延: IT業界自体の変革が進まなければ、社会全体のDX推進にもブレーキがかかります。

まとめ

「現代版Σプロジェクト」のような変革は、技術やツールを導入するだけでは成功しません。むしろ、日本のIT業界（特に大手SIerなど）が抱える 「人材の質・意欲の問題」「組織文化・人事制度の問題」「多重下請け構造の問題」 といった根深い課題を同時に解決しなければ、その効果は限定的となり、かえって多くの問題（スキルミスマッチ、生産性低迷、人材流出、格差拡大など）を深刻化させる可能性があります。

この変革を成功させるためには、技術導入と並行して、あるいはそれ以上に、従業員の意識改革、学習文化の醸成、スキルを正当に評価する人事制度への刷新、硬直化した組織構造や商習慣の見直し といった、より困難な課題に取り組むことが不可欠となります。これは、経営層の強いコミットメントと、業界全体での協力が求められる、極めて大きなチャレンジと言えるでしょう。

Q6

立派な学歴があって技術を高めることが自身のアイデンティティとなっている優れたエンジニアや、企業を成長させることに情熱を注ぐ経営者、そしてあなたのような論理的判断力に優れたAIなどは、いつも「マインドを変えなければ」「自ら学ぶことが必要」と言いますが、多くの「普通の人」にとって、仕事は生活のためであり、できるだけ楽して給料をもらいたいわけです。それが自然です。「勉強したがり」「成長したがり」な人は少数派であることを認識した上で、より現実的な社会の変化と施策を考えてください。

A6

おっしゃる通り、非常に重要なご指摘です。これまでの議論は、ややもすれば技術進化への期待や理想的な人材像を前提としすぎていたかもしれません。「大多数の人は、できるだけ楽をして安定した生活を送りたい」というのは、人間の自然な感情であり、それを前提とせずに社会の変化や施策を語ることは現実的ではありません。

この「普通の人のマインドセット」を認識した上で、それでもソフトウェア開発の効率化や人材不足解消という課題にどう向き合うべきか、より現実的な社会の変化と施策を考えてみます。

「普通の人が楽したい」を前提とした社会の変化予測

ツールの進化は「楽する方向」へ:
- AI、ノーコード/ローコードツールは、専門家だけでなく「普通の人」が楽に使えるように、ますます直感的でシンプルなインターフェースへと進化していくでしょう。複雑な設定やコーディングを必要とせず、日常言語に近い指示やドラッグ＆ドロップ操作で、ある程度のことができるようになる方向性が加速します。
- 「難しいことを勉強しなくても、ツールが賢くやってくれる」という状況が、限定的ながらも実現していきます。
役割の再定義と分業の深化:
- 「ツール使い」層の拡大: 高度な技術知識や学習意欲がなくても、使いやすくなったツールを操作して定型的な開発や業務改善を行う「ツール使い」としての役割が一般化します。彼らは「楽に」成果を出せる範囲で貢献します。
- 高度専門職との分業: 複雑なシステムの設計、AIモデルのチューニング、コア技術の開発、セキュリティの深い分析などは、引き続き高い専門性と学習意欲を持つ人材が担います。この層と「ツール使い」層との明確な分業が進みます。
- ブリッジ人材の重要性: 「ツール使い」層と高度専門職、あるいはビジネスサイドをつなぐ役割（要求をツールで実現可能な形に翻訳する、ツールの限界を説明するなど）の重要性が増します。これは必ずしも技術のトップランナーである必要はなく、「普通の人」の気持ちが分かり、かつ技術の概要を理解している人材が適任かもしれません。
変化の速度は緩やかで不均一に:
- 一部の先進的な企業や学習意欲の高い層が先行する一方で、多くの企業や「普通の人」は、新しいツールや働き方をすぐには受け入れません。「今のやり方で困っていない」「新しいことを覚えるのが面倒」という慣性が強く働くため、社会全体の変化は理想よりもずっとゆっくりと、まだらに進んでいくでしょう。
- 変化が強制されるのは、旧来のやり方では明らかに立ち行かなくなった時や、楽になるメリットがデメリット（学習コストなど）を大きく上回ると誰もが実感できるようになった時です。
淘汰ではなく「配置転換」が中心に:
- 急激なスキル変化についていけない人が即座に「淘汰」されるというよりは、よりツール化・標準化された業務や、人との対話・調整が中心となる業務など、その人が「比較的楽に」対応できる分野への配置転換が進む可能性があります。ただし、そのようなポストが十分にあるかは不透明です。

「普通の人が楽したい」を前提とした現実的な施策

徹底的に「楽」を追求したツール開発・導入支援:
- ユーザーインターフェースの極度の簡素化: マニュアル不要で、直感的に操作できるツールの開発を国や業界団体が支援する。
- 導入メリットの可視化: 新ツール導入で「どれだけ作業時間が減るか」「どれだけ面倒な作業がなくなるか」を具体的に示し、「楽になる」ことを強調する。
- 「お試し期間」と手厚いサポート: 気軽に試せて、困ったときにすぐに聞けるヘルプデスクや、社内の詳しい人によるサポート体制を、企業任せにせず社会的に（例：中小企業向け共同サポートセンターなど）整備する。
「学習」のハードルを極限まで下げる:
- 強制的な自己学習の否定: 業務時間外の自費学習を前提としない。
- マイクロラーニングとOJT: 業務時間内に、必要な時に、必要なことだけを、短時間で学べる仕組み（動画マニュアル、操作ガイドなど）を充実させる。座学よりも、実際の業務の中で試しながら覚えるOJTを重視する。
- 「教える側」の負担軽減: ツール操作などを教える側の負担を減らすため、質の高い教材やサポートツールを共通資産として整備・提供する（官民共同で）。
インセンティブ設計の工夫:
- 「楽」へのインセンティブ: 新しいツールを使って業務を効率化（＝楽に）できた人を評価する。評価は必ずしも昇進・昇給だけでなく、「より柔軟な働き方（時短、リモート）の許可」「面倒な業務の免除」など、「楽」に繋がる形も検討する。
- 失敗への寛容: 新しいツールを試して失敗してもペナルティがない文化を作る。「挑戦しないこと」がマイナス評価になるような、緩やかなプレッシャーに留める。
役割に応じた期待値の設定:
- 全員に高度なスキルや変化への対応を求めない。本人の意欲や適性に応じて、「ツール使い」として安定的に貢献してもらうキャリアパスも認める。
- ただし、「最低限のITリテラシー」（セキュリティ意識、基本的なツール操作）は、社会人としての一般教養として求める必要はある。
社会的なセーフティネットの強化:
- どうしても変化に対応できない、あるいは旧来のスキルが不要になった場合の、職業訓練や転職支援を強化する。特に、IT以外の分野へのキャリアチェンジ支援も重要になる。

結論

「普通の人が楽したい」という現実は、社会変革を進める上で無視できない大前提です。したがって、「マインドを変えろ」「学べ」と一方的に要求するのではなく、「いかに楽に変化に対応できるようにするか」 という視点でのツール開発、制度設計、サポート体制の構築が不可欠です。

変化の主役は、一部の優秀層だけでなく、むしろ大多数の「普通の人」です。彼らが無理なく、あるいは「楽になるから」という動機で、少しずつでも新しいやり方を取り入れられるような、地に足のついた施策を粘り強く進めることが、結果的に社会全体の変革を実現する最も現実的な道筋なのかもしれません。

Q7

ここまでの議論をまとめて、「生成AIはシグマプロジェクトの夢を見るか？」というタイトルのエッセイに仕立ててください。ITやSF、そして実社会の人々の生き様に詳しい、老練した作家の作品に感じられるようにしてください。事実や数値なども交えながら、大人向けのカジュアルでちょっとシニカルな文体にしてください。文字数は1200字程度にしてください。箇条書きは使わず、一連の文章として作成してください。読者への投げかけや過去を振り返るようなセンテンスも交えてください。

なお、タイトルは映画「ブレードランナー」の原作にあたる「アンドロイドは電気羊の夢を見るか? (Do Androids Dream of Electric Sheep?)」を意識しています。

A7

生成AIはシグマプロジェクトの夢を見るか？

やれやれ、またぞろ景気のいい話が聞こえてくる。今度は生成AIとやらが、ソフトウェア開発の世界を根底からひっくり返すんだそうだ。コードはAIが書き、設計もAIが手伝い、テストだって自動でやってくれる。かつてコンピュータが人間の仕事を奪うと騒がれたように、今度はエンジニアがお払い箱になる番だ、なんて声も聞こえる。まあ、いつの時代も新しい技術が登場すれば、期待と不安が渦巻くもんだ。

ふと、遠い昔のことを思い出す。1980年代、バブル景気に浮かれる日本の片隅で、通商産業省、今でいう経済産業省が音頭をとってぶち上げた国家プロジェクトがあった。「Σ（シグマ）プロジェクト」と名付けられたそれは、まさにソフトウェア開発の「工業化」を目指す壮大な実験だった。当時、コンピュータの性能は日進月歩で向上するのに、ソフトウェア開発は相変わらず職人芸頼み。需要に供給が追いつかず、「ソフトウェア危機」なんて言葉がまことしやかに囁かれていた。そこで国は考えたわけだ。標準化されたOS（ΣOS）と開発ツール（Σツール）を作り、再利用可能なソフトウェア部品を流通させれば、熟練工でなくともレゴブロックみたいにプログラムを組み立てられるようになる。生産性は飛躍的に向上し、人手不足も解消。日本のソフトウェア産業は世界を席巻するだろう、と。約250億円もの巨費と、国内の名だたるメーカーやソフトウェアハウス、大学まで巻き込んだ、まさに鳴り物入りの計画だった。

結果はどうだったか？まあ、ご存じの通り、Σプロジェクトは当初の夢を果たせぬまま、静かにその幕を下ろした。技術の進歩は国の計画よりも速く、標準化の理想は企業の思惑や現場の現実に阻まれた。結局、ソフトウェア開発は工業化されず、相変わらず人間がキーボードを叩き、頭を悩ませる日々が続いたわけだ。あの壮大な夢は、霞のように消えたかに見えた。

ところがどうだ。令和の世になって、生成AIなるものが現れた。自然言語で指示すればコードを吐き出し、GitHubにはオープンソースという名の「部品」が溢れかえっている。ノーコード、ローコードなんてツールを使えば、専門家でなくても業務アプリくらいは作れてしまう。これは、まるでΣプロジェクトが見果てぬ夢を、別の形で実現しようとしているかのようじゃないか？あの頃、官僚たちが夢想した「ソフトウェア工場」の光景が、AIとクラウドの力で、今度こそ現実になるのかもしれない。

だが、ちょっと待て。我々はこの国のIT業界の現実を知っている。立派な学歴をぶら下げて大手SIerに入り、技術そのものより「調整力」で評価される人々。下請け、孫請けへと流れるピラミッド構造。プロジェクトが終われば、作ったプログラムより報告書の出来栄えが問われる世界。「マインドを変えろ」「自ら学べ」なんて、景気のいい掛け声はいつだって聞こえる。だが、現場で汗を流す大多数の「普通の人々」にとって、仕事は生活の糧であり、できれば楽して安定を得たいのが本音だろう。新しい技術を学ぶより、昨日のビールの味を反芻したい夜だってある。それが人間というものじゃないか？

そんな彼らに、AIがコードを書くから君たちは設計やレビューに集中しろ、と言ったところで、どれだけの人間が喜んで変化を受け入れるだろうか。「わざわざ業務時間外に、自費で勉強なんかしたくない」という声が聞こえてきそうだ。結局、使いやすいツールができたとしても、使う側の人間が変わらなければ、宝の持ち腐れになるのが関の山かもしれない。いや、むしろAIによって仕事が効率化された結果、余った人員が整理される、なんて身も蓋もない未来だってあり得る。

かつてΣプロジェクトが、標準化という名の理想郷を目指したように、生成AIもまた、効率化と生産性向上という名の夢を我々に見せている。だが、その夢は誰のためのものなのか。一部の優秀なエンジニアや、コスト削減に血道を上げる経営者のためのものか？それとも、大多数の「楽したい」普通の人々を、本当に幸せにするものなのか？

あるいは、生成AI自身が夢を見ているのかもしれない。膨大なデータから学習し、人間のように対話する彼らは、いったい何を考えているのだろうか。ただ効率的にコードを生成することか？それとも、人間がかつて夢見た「ソフトウェアの工業化」という理想を、今度こそ達成したいと願っているのか？まるで、フィリップ・K・ディックが問いかけたように、「生成AIはシグマプロジェクトの夢を見るか？」と。

まあ、どう転ぶかは誰にも分からない。技術は進歩し、社会は変わっていく。我々はその流れの中で、時に流され、時に抗いながら生きていくしかない。AIがもたらす未来が、ユートピアかディストピアか、あるいは単に少しだけ便利になった退屈な日常か。せいぜい、ポップコーンでも齧りながら、この先の展開を見守ろうじゃないか。案外、一番変わらないのは、我々人間の、どうしようもない「性（さが）」なのかもしれないな。

(人間による) おわりに

最後はGeminiにエッセイを書いてもらいましたが、出力を見ると、なんだか日経のガングロ編集長の記事とそっくりになってしまいました🤪キャラクター設定の際に具体的に意識したわけではないのですが、結果的にこういう文体になるということは、ガングロ編集長も自分の中でそういうイメージを持っているんでしょうか。これは面白い発見でした。

私は、シグマプロジェクトが始まった時代には物心ついたかつかないかなので、実態は知りませんが、それでも2000年代初めにパソコン、インターネットに触れた頃にはIT系の個人サイトやスラッシュドットなどの掲示板で、シグマプロジェクトを揶揄したテキストを多く見た記憶があります (ちょうど「情報大航海プロジェクト」「国産検索エンジン」が話題になっていた時期でしたし)。一般的には失敗プロジェクトとして捉えられていますが、近年のDXやAIへの過度な期待、人手不足、経済の行き詰まり、そして実際にどんどん発展していく生成AIを見ていると、またシグマプロジェクトのような考え方が出てくることもあり得るのかな、と感じていました。そもそも、DX自体、1980年代の「OA化」と何が違うんだろう、とも思いますし。

技術は発展しますが、ベースとなる人間の思考は、それほど変わらないのでしょうね。OA化が10年ごとに情報化、IT化、DXと名前を変えて繰り返すのと同じように、「技術の発展でプログラミングスキルは陳腐化し、誰でもソフトが作れるようになってIT業界の人手不足は解消する」という考え方も繰り返されるのかもしれません。ただ、以前と違うのは「本当にそれができそうなくらい賢いAI」がある、ということでしょうか。それでもやっぱり人間 (日本人？) には無理なのか、過去を超えて今度こそ成功するのか。そういった視点で生成AIと (ビジネスにおける) 人間との関わりを見ていきたいと思っています。

まぁなんというか、Gemini 2.5 Proは本当になんかすごいなぁ、と思いました。

jp_binder_arm64にJavaカーネルを追加しました

Wed, 12 Feb 2025 00:00:00 +0000

タイトルの通りですが。先日作成したrocker/binderの日本語設定 + arm64ビルドイメージに、Javaを実行可能なJupyterカーネルを追加しました。

rocker/binderに日本語設定を追加してApple Silicon (arm64) 向けにビルドしました

もともとイメージを作成した意図として「学部の標準データサイエンス環境」というのがあったので、大半 (全員?) の学生が講義で使用するJavaも使えるようにしたいと考えました。

JupyterでJavaを実行する仕組みはいくつかあるようですが、今回はJupyter for Javaで提供されている仕組みを使いました。JBangというJava環境構築ツール (?) を使って、JupyterカーネルをインストールするステップをDockerfile内に追加しました。

Javaをよく知らないので、適当にコピペしたサンプルコードも動いているので、これでよいのではないでしょうか。JupyterでJava Kernelを使うメモによれば、Mavenによるパッケージのダウンロード・インストールもできるようです。

よくわかりませんがパッケージのインストール・インポートができました

教育の最初の段階では、やはり1行書いては動かす、REPL式がよいのではないかと思いますので、Javaの入門教育などにも活用できるのではないでしょうか。

まぁ相変わらず、自分で使う予定はないんですが🤪

rocker/binderに日本語設定を追加してApple Silicon (arm64) 向けにビルドしました

Sun, 09 Feb 2025 00:00:00 +0000

タイトルの通りなのですが。今さらですが、Dockerを初めて使ってみました。

GitHub: tetlabo/jp_binder_arm64: rocker/binder に日本語設定を追加しました
Docker Hub: manabi/jp_binder_arm64

Dockerの (大まかな) 仕組みや、現在主流であることはもちろん10年近く前から知ってはいましたが、「作り込んだ環境が保持されない」「ストレージを多く消費する」「仮想化のオーバーヘッドがある」といった印象 (思い込み？) から、使っていませんでした。今回も、自分で使う意図はあまりない¹のですが、大学の講義 (標準PCがMac) や研修で、トラブルのないデータサイエンス (RStudio, Jupyter) 環境を配布したい、ということでイメージを作成しました。全部Google Colabでやればいいのですが、他の講義にRStudioを前提としているものもあり、この講義ではRStudio、この講義ではGoogle Colabとバラバラなのもなぁ、ということで「学部の標準データサイエンス環境」を意図しています。²

ベースとして、rockerプロジェクトでテンプレートとして配布されているbinderを使おうと思ったのですが、Dockerfile内ではgeospatialイメージを使用していて、このイメージがamd64 (x64) 用しかありませんでした。もちろん、Apple SiliconのMacでも --platform linux/amd64 オプションを指定すれば動きますが、せっかくなら仮想化にエミュレーションを重ねるよりは、arm64でビルドしたいと考えました。そこで、rockerプロジェクトのGitHubリポジトリをコピーして、改変することにしました。

…そこからが大変で、rockerプロジェクトで公開されているDockerfileをコピペで組み合わせれば動くだろう、と思ったらまぁうまくいかず、結局まる3日くらい試行錯誤してしまいました。作成した環境には、jupyter-rsession-proxyが導入されているので、RStudio ServerはJupyter Labのメニューから起動することになります。

Docker Hubに登録しているので、以下のコマンドでダウンロードし、実行できます。

`1`	`docker pull manabi/jp_binder_arm64`

なお、イメージは上記の通りarm64向けにビルドしているので、Apple Silicon搭載のMacでしか (最近のCopilot+PCも対応？) 使えません。また、Rの環境には、筆者が研修や講義でよく紹介するので、radiantパッケージをインストールしています。radiantは多くのパッケージに依存するShinyアプリであるため、Dockerfileから手元でビルドしようとすると、やたらと時間がかかります。

…いろいろ苦労して思ったのですが、やっぱりDockerはいらなくて、(大学教育に関しては) 1年次にHomebrewをベースとした「間違えのない」環境構築をさせて、それ以降は講義ごとに {renv} パッケージやuvコマンドで仮想環境を作るように指導した方が楽そうですね🤪

そもそも普段はVSCodeを使っているので、RStudioもJupyterも使わないのですが。 ↩︎
一介の非常勤講師が考えることじゃないんですけど🤪でも、せんせー方が誰も「イマドキのデータサイエンス事情」を知らずにデータサイエンス教育をしているので🤪 ↩︎

DXアドバイザー検定「スペシャリスト」資格を取得しました

Fri, 17 Jan 2025 00:00:00 +0000

たまに、研修などのネタ (紹介するしないの判断) として、よくわからないDX、AI系の資格を受けています。

QC検定3級・4級 (これはよくわからないものではなく、ちゃんとした資格ですが)
データサイエンティスト検定リテラシーレベル
ビジネス統計スペシャリスト　ベーシックレベル¹
DX検定プロフェッショナルレベルを取得しました

今回は、DXアドバイザー検定「スペシャリスト」なるものを受けてみました。

DXアドバイザー検定公式サイトより

スペシャリスト、エキスパート、プロフェッショナルの (言葉としての) 上下関係がまるでわかりませんが🤪こういうデジタル系の資格ビジネスは、「初級」「基礎」とかでなくスペシャリストとかプロフェッショナルとか、自らインチキくさい名称にするのが好きですね🤪

毎度ながら、「ノー勉」でなんとなく行って、なんとなく合格しました。普段から他人にそういう分野のことを語ってりゃ、そら受かるよね、という。試験の内容はここでは触れませんが、DXというより、個人情報保護に関する問題が多くの割合を占めていました。もちろん私は個人情報保護法とか詳しくない🤪わけですが、「普通に考えたらこの選択肢しかないよな」というのを選んでいった結果、87.5%正解しているので、国語の読解問題だと思えばよいのではないでしょうか。試験は80問を90分で、というスケジュールですが、私は30分くらいで終わりました。

これに合格したら誰に何を「アドバイス」できるのかまるでわかりませんが、さらに毎年11000円を支払えば「DXアドバイザー」として登録され、サイトに掲載されるようです。横浜市の個人事業主、として考えたときに、その認定を掲げて何かメリットがあるのか、ちょっとイメージできないですね。

ともあれ、「アドバイス」がお金につながる中小企業向けSIerやコンサルでなければ、受ける意義はあまりないのかなと思いました。

スペシャリストレベルも同日に受けて、1点足りずに落ちました。 ↩︎

{learnr}で課題の実行結果を提出する仕組みを作る

Sun, 29 Dec 2024 00:00:00 +0000

講義のオンデマンド化と課題

昨日に引き続き、担当しているRの講義に関することですが、来年度は授業をオンデマンドで展開することになりました。もともと、「教室が足りないからオンライン化 (ライブ・オンデマンド問わず) できる授業はしてくれ」という要請¹が来ていて、すでに他の講義をオンデマンドで提供していることもあり、Rの講義もオンデマンド化することにしました。

現在も、講義は教室で行っていますが、(「単位の実質化」とかで) 毎週出している課題は、Rプログラムを書いて、LMS (Google Classroom) に提出してもらう形式です。来年は、それを一歩進めて、動画＋ハンズオン＋課題を {learnr} パッケージの枠組みでできないかと考えています。実際、社会人向けに3年ほどRの研修コンテンツを販売していて、そこでは {learnr} のコンテンツの中に動画を埋め込んで、shinyapps.ioでホスティングしていました。

こんな感じで。

そのため、やりたいことの大半は実現できると思っていましたが、唯一課題と考えていたのが課題でした🤪進次郎構文ではなく、「(私が解決しないといけないと思っていた) 課題が、(学生に課す) 課題 (をどうやって提出させるか) でした」という意味です。今度は岡田構文になっていますが。おーん🤪

課題の実行結果を保存して出力するには

{learnr} の中で問題を出して、それに (授業時間外に) 解答させることはできますが、その結果をどうやって出力し、提出するかということを解決する必要がありました。調べる限り、{learnr} 自身に、結果をメールで送信したり、ファイルとしてダウンロードする仕組みはなさそうでした。それらしい機能を持った {learnr} を拡張するようなパッケージもありますが、ドキュメントから (私の能力不足で) 使い方を読み取れないのと、メールで提出されても成績管理がしづらいので、候補からは外れます。

他の、R/Examsプロジェクトが開発しているパッケージも、Rで教育コンテンツを提供し、課題の提出を受け付ける機能がカバーされていますが、こちらはMoodleなどのLMSと連携させることが前提で、この授業のためだけに大学の標準のLMSと違うものを使うのは、教員、学生ともに無駄が多いと感じています。

{learnrhash} によるハッシュ化

そんなこんなで、色々調べていたら、ついに以下の記事を見つけました。

{learnr} 内の実行状態はShinyのセッション情報として保存されていて、get_tutorial_state() 関数でアクセスできますが、それをどうやって出力して、学生自身で取得して提出できるか、というところが課題でしたが、上記の記事をもとに、{learnrhash} パッケージを使い、セッション情報をハッシュ化して画面に表示することができました。

セッションをハッシュ化する

```{r eval=TRUE, context="server"}
learnrhash::encoder_logic()
```


```{r encode,eval=TRUE,echo=FALSE}
learnrhash::encoder_ui()
```

ハッシュ化されたセッションを復元する

```{r eval=TRUE, context="server"}
learnrhash::decoder_logic()
```


```{r decode,eval=TRUE,echo=FALSE}
learnrhash::decoder_ui()
```

回答結果をハッシュ化する

ハッシュから回答を復元する

Google Classroomには、Googleフォームと組み合わせて課題を出す機能があるので、ハッシュ化された回答をフォームに貼り付けて提出してもらう、という形式が実現できそうです。上図では {learnr} コンテンツ内でデコードしていますが、もちろん普通にコンソールからも復元できるので、採点も容易にできます。

おそらく、そんな感じで講義のオンデマンド化と合わせて、課題の提出・採点の効率化が実現できるのではないかと思っています。個人的には、そんなに毎週課題を出さなくても、授業内で完結するようにした方が、「大学生らしい」ことができる時間ができていいんじゃないか、とも思いますが。

長期的にはQuarto化、シングルページ化も

Quartoに {webR} と組み合わせた、シングルページでオンライン教材が作成できる拡張機能があるようです。

Introduction – Quarto Live Documentation

こちらも、RとPythonの両方に対応しているので、将来的にはRによるオンライン教材作りのスタンダードになっていくのかもしれません。

tutorial.helpersパッケージ

記事を投稿した後もいろいろ調べていたら、{tutotial.helpers} というパッケージが見つかりました。

CRAN: Package tutorial.helpers https://cran.r-project.org/web/packages/tutorial.helpers/index.html
Enable Students to Download Their Tutorial Answers • tutorial.helpers https://ppbds.github.io/tutorial.helpers/articles/downloads.html

このパッケージには、上記のリンク先にあるように、回答の情報をHTMLとしてダウンロードできる仕組みがありました。こちらを使う手もありそうです。ただ、HTMLなので目視が中心になる (rvestなどで解析してもいいですが) こと、正解か不正解かの TRUE / FALSE が出力に含まれないところが、ちょっと不便かなとも思いました。

他の大学でもそんなことがあるんですかね？ ↩︎

{transforEmotion}と{atrrr}でBlueSkyのセンチメント分析

Sat, 28 Dec 2024 00:00:00 +0000

担当しているRの講義で、毎年テキストマイニングを扱っています。その中で、SNSからのデータ収集や、いわゆる「ポジネガ分析」についても触れています。しかし、X APIは有償化して、個人の興味関心の範囲ではデータの収集ができなくなりました。“ツイート” 取得のデファクトスタンダードとなっていた{rtweet} パッケージも開発が終了してしまいました。

また、ポジネガ分析については、当初たまたまGitHubで見つけたPythonのsentiment_jaライブラリを {reticulate}¹ パッケージを使って呼び出していました。しかし、ライブラリ自体がGitHubからなくなり、自分の手元にはたまたま削除される直前にCloneしたものが残っていたのですが、作者が削除したものをいつまでも使うのもな、と思っていました。そもそも私自身、どういうモデルなのかよく分からず、とりあえず感情価が返ってくるので使っている、というだけでしたし。

また、年明けにテキストマイニングの回がやってくるので、この辺りをアップデートしようと、いろいろ調べてみました。

Blueskyからポストを取得する

RからBluesky APIにアクセスできるパッケージ

APIに限らない、X社の方針転換などで、さまざまな代替SNSが公開されています。その中で、比較的ユーザー数が多く、Xの雰囲気に近いと思われるものにBlueskyがあります。また、Blueskyはオープンであることを重視しており、APIも無償で公開されています。そこで、RからBlueskyのAPIにアクセスできるパッケージがないかな、と探してみました。すると、以下の2つがありました。

CRAN: Package bskyr https://cran.r-project.org/web/packages/bskyr/index.html
CRAN: Package atrrr https://cran.r-project.org/web/packages/atrrr/index.html (アトルー？)

どちらも、機能的にはほとんど同じで、Blueskyへの投稿、いいね、リポストやフォロー・アンフォローなどの操作ができるようです。そして、今回の主目的である、他者のポストを取得する機能もあります。なお、XにおけるStreaming APIと同様に、BlueskyにもFirehoseというAPIがあり、リアルタイムのポストを取得できる仕組みはありますが、いずれのパッケージもまだサポートしていないようです。²実際、ランダムに取得したポストでポジネガ分析してもあまり意味がないので、今回はキーワードを取得して、そのテキストを処理対象とします。

{atrrr} パッケージのインストール

上記の2つのパッケージのどちらでも、キーワードを指定したポストの検索、取得はできますが、今回は {atrrr} パッケージを使います。³まずその前に、Blueskyにアカウントを作成する必要があります。特に迷うようなこともないので、ここでは省略します。

何年ぶりかに🤪APIアクセス以外に使用する予定はないですが

{atrrr} パッケージはCRANからインストールできます。

`1`	`install.packages("atrrr")`

そして、パッケージを読み込みます。

`1`	`library(atrrr)`

{atrrr} パッケージによるユーザー認証

はじめに、APIにアクセスするために auth() 関数で認証を得ます。XではAPIにアクセスするためにアクセストークンを取得する必要がありますが、Blueskyではユーザー名とパスワードでアクセスできます。

`1`	`auth(user = "ユーザー名", password = "パスワード")`

ポストの取得

次に、APIにアクセスし、キーワードで検索したポストを取得するには search_post() 関数を使います。ここでは、たまたま今日 (12/28) 開催された中央競馬のGI、ホープフルステークスについてのポストを取得してみましょう。

# ホープフルステークスやホープフルSなど表記が揺れるので
# 前半だけをキーワードとして指定
res <- search_post(q = "ホープフル since:2024-12-28 until:2024-12-29", limit = 200)
head(res)

## # A tibble: 6 × 20
##   uri                                                                   
##   <chr>                                                                 
## 1 at://did:plc:5cbdxxui4cmo2cytfahvafyl/app.bsky.feed.post/3leehkzsx7s2c
## 2 at://did:plc:itkjw3kfno5jvsjf5ptlu6ss/app.bsky.feed.post/3leeheyydb226
## 3 at://did:plc:dp3fdt3yreehru3pouwvaams/app.bsky.feed.post/3leegul2ar22d
## 4 at://did:plc:4urr3lljj6b2gca5bf4hyzt7/app.bsky.feed.post/3leegl5xbgc2m
## 5 at://did:plc:c3itjpvm5hamy7up773xna6a/app.bsky.feed.post/3leegfzu4cs2m
## 6 at://did:plc:kdkik6uosu3x4btwq2klnmrv/app.bsky.feed.post/3leeg2ekubc2l
##   cid                                                        
##   <chr>                                                      
## 1 bafyreigxm7shursdnjawezjom5467c6nkbxfxedki6ayzmyfepk7lkjcpa
## 2 bafyreibhsw75brxdokw2p4jgxkxerhtmtobxuoufxukdadfc6yr2tp7b2q
## 3 bafyreifly3pjba3ceantpcbeliqfy345pvesbl6wme46vgebt35unlroxa
## 4 bafyreiavsq6zsxkoeie3y7rnxl5kv4tsu6y6kyu33a5amhnig3k7avtvvu
## 5 bafyreiahf7oicub72c42qobtk32wtm7sigmuwf25w4lgv6ajrzet4hcdcu
## 6 bafyreia6jgc7lfuystkxbekzlpbs2t6atb7jtq53odgmopytoryc4ebyem
##   author_handle           author_name                      
##   <chr>                   <chr>                            
## 1 tee0.bsky.social        てちゃ                           
## 2 d27-abc.bsky.social     🤖マシンキラー阿彦🤖             
## 3 yukimiyosi.bsky.social  見吉 幸　クルクル福岡両時間いた人
## 4 neothakaoka.bsky.social 三葉虫                           
## 5 azuyahi.bsky.social     あずやひ                         
## 6 tsukimasite.bsky.social つきま                           
##   text                                                                          
##   <chr>                                                                         
## 1 "ホープフルの予想だけして、まだレースは見てないけど結果は見て、やっぱりクロワ！！！ってなってる人です！！！！！あとでレース見るね🫶"……
## 2 "ホープフルS面白かった〜とか競馬場楽しい〜とかフォロワーと会えてよかった〜とか諸々を呟いて行こうと兄の家に帰ったら早速兄がリゼロを見始めてくれてて冷や汗…
## 3 "今夜のホープフルステークス後夜祭で、前後夜祭は開催を辞めます。\n人も集まらないし、本人も忘れている事もありますし。気まぐれで開催するかもです。"……
## 4 "私のホープフル　ホープレスステークスでした\nでも北村友一さまが勝ったのはうれしい　こっちまで泣きそうになってしまった　おめでとうございます　クロワの単…
## 5 "こんばんは！\nホープフル外しました😅"                                        
## 6 "2024ホープフルステークス"                                                    
##   author_data      post_data        embed_data       reply_count repost_count
##   <list>           <list>           <list>                 <int>        <int>
## 1 <named list [8]> <named list [4]> <NULL>                     0            0
## 2 <named list [7]> <named list [4]> <NULL>                     0            0
## 3 <named list [8]> <named list [4]> <NULL>                     0            0
## 4 <named list [8]> <named list [4]> <NULL>                     0            0
## 5 <named list [8]> <named list [5]> <NULL>                     0            0
## 6 <named list [8]> <named list [5]> <named list [2]>           0            0
##   like_count indexed_at         
##        <int> <dttm>             
## 1          0 2024-12-28 12:04:35
## 2          0 2024-12-28 12:01:12
## 3          0 2024-12-28 11:52:02
## 4          0 2024-12-28 11:46:45
## 5          0 2024-12-28 11:43:53
## 6          4 2024-12-28 11:37:31
##   in_reply_to                                                           
##   <chr>                                                                 
## 1 <NA>                                                                  
## 2 <NA>                                                                  
## 3 <NA>                                                                  
## 4 <NA>                                                                  
## 5 at://did:plc:wlpww6oubzebkigukd3dacdn/app.bsky.feed.post/3led7cvcbqk2y
## 6 <NA>                                                                  
##   in_reply_root                                                          quotes
##   <chr>                                                                  <chr> 
## 1 <NA>                                                                   <NA>  
## 2 <NA>                                                                   <NA>  
## 3 <NA>                                                                   <NA>  
## 4 <NA>                                                                   <NA>  
## 5 at://did:plc:c3itjpvm5hamy7up773xna6a/app.bsky.feed.post/3led37ktv5k2t <NA>  
## 6 <NA>                                                                   <NA>  
##   tags   mentions links  langs      labels    
##   <list> <list>   <list> <list>     <list>    
## 1 <NULL> <NULL>   <NULL> <list [1]> <list [0]>
## 2 <NULL> <NULL>   <NULL> <list [1]> <list [0]>
## 3 <NULL> <NULL>   <NULL> <list [1]> <list [0]>
## 4 <NULL> <NULL>   <NULL> <list [1]> <list [0]>
## 5 <NULL> <NULL>   <NULL> <list [1]> <list [0]>
## 6 <NULL> <NULL>   <NULL> <list [1]> <list [0]>

ポストがデータフレームとして取得できました。このうち、text 列に実際に分析対象となるテキストが格納されています。

Rでセンチメント分析をする

次に、テキストのセンチメント分析をする方法を (講義のために) アップデートします。上述のように、昨年まではPythonのsentiment_jaライブラリを使っていました。また、それ以前はいくつかの公開された感情表現辞書を使う方法が一般的でした。しかし近年では、生成AIの基盤技術でもある、Transformerを使った言語モデルでセンチメント分析を行うことが主流のようです。

RでTransformerモデルを利用できるパッケージ

しかし、残念ながらそれらの研究開発領域ではPythonが主流で、Rからそれらの高度なモデルをネイティブに扱えるパッケージはないようです。CRANに公開されている、Transformer系のパッケージはいずれも、{reticulate} パッケージを使い、実質的にはRの裏でPythonを動かして処理するものばかりです。その中で、今回は目的にフィットした {transforEmotion} パッケージを使用します。

CRAN: Package transforEmotion https://cran.r-project.org/web/packages/transforEmotion/index.html

このパッケージは、Hugging Faceで公開されている、“Zero shot classification” に対応した任意のモデルをダウンロードし、{reticulate} パッケージでPyTorchやTensorflowを動かし、任意のラベル (後述) で判定ができます。

…まぁTransformerもHugging FaceもPyTorchも何もかもよくわかっていないんですが🤪

{transforEmotion} パッケージのインストール

{transforEmotion} パッケージはCRANからインストールできます。

`1`	`install.packages("transforEmotion")`

パッケージをインストールした後、パッケージが利用するPythonの仮想環境をminicondaで作成する必要があります。ドキュメントにも記載されていますが、setup_miniconda() 関数を実行します。

1
2
3

library(transforEmotion)

setup_miniconda()

基本的には、自動で必要なPythonライブラリ類がダウンロードされ、環境が構築されます。なお、Macでは ~/Library/r-miniconda-arm64/envs/transforEmotion 下に保存されます。

英語テキストでのテスト

環境が構築できたら、まずは英語のテキストでテストしてみましょう。{transforEmotion} パッケージでは、デフォルトで cross-encoder/nli-distilroberta-base モデルが使用されます。⁴公式サイトのサンプルのままですが、以下を実行してみましょう。

# Load data
data(neo_ipip_extraversion)

# Example text 
text <- neo_ipip_extraversion$friendliness[1:5]

# Cross-Encoder DistilRoBERTa
transformer_scores(
 text = text,
 classes = c(
   "friendly", "gregarious", "assertive",
   "active", "excitement", "cheerful"
 )
)

## $`Make friends easily`
##   friendly gregarious  assertive     active excitement   cheerful 
##    0.52954    0.08775    0.09368    0.08829    0.06882    0.13192 
## 
## $`Warm up quickly to others`
##   friendly gregarious  assertive     active excitement   cheerful 
##    0.05750    0.03237    0.17586    0.17694    0.30525    0.25208 
## 
## $`Feel comfortable around people`
##   friendly gregarious  assertive     active excitement   cheerful 
##    0.73451    0.03259    0.04983    0.04678    0.01982    0.11646 
## 
## $`Act comfortably around people`
##   friendly gregarious  assertive     active excitement   cheerful 
##    0.44115    0.04934    0.14065    0.22977    0.02672    0.11237 
## 
## $`Cheer people up`
##   friendly gregarious  assertive     active excitement   cheerful 
##    0.08325    0.13463    0.10779    0.07430    0.33212    0.26791

テキストの感情を6つの尺度で判定し、結果が割合で出力されます。とりあえず結果が出力されれば、環境構築はうまくいっているでしょう。

多言語に対応したモデルのインストール

上記のモデルは、英語にのみ対応しています。そのため、日本語テキストを分析するには、対応したモデルをダウンロードし、指定する必要があります。日本語を含めた多くの言語に対応したモデルとして、MoritzLaurer/mDeBERTa-v3-base-xnli-multilingual-nli-2mil7がありました。⁵

{transforEmotion} パッケージでは、モデルを transformer_scores() 関数の transformer オプションで指定すれば、自動的にダウンロード、インストールをしてくれます。以下のようなコードで、日本語のセンチメント分析ができます。また、Transformerによるモデルでは、任意のラベル (クラス) に対する推論ができます。ここでは、シンプルに「ポジティブ」か「ネガティブ」のどちらがもっともらしいか判定させます。初回は、モデルのダウンロード、インストールがあるため、かなりの時間がかかります。

text <- c("お正月がとても楽しみだ", "バレンタインは本当に憂鬱だ", "卒論が出せるか不安だ")

transformer_scores(
 text = text,
 classes = c("ポジティブ", "ネガティブ"),
 transformer = "MoritzLaurer/mDeBERTa-v3-base-xnli-multilingual-nli-2mil7"
)

## $お正月がとても楽しみだ
## ポジティブ ネガティブ 
##    0.97903    0.02097 
## 
## $バレンタインは本当に憂鬱だ
## ポジティブ ネガティブ 
##    0.04791    0.95209 
## 
## $卒論が出せるか不安だ
## ポジティブ ネガティブ 
##    0.02826    0.97174

そもそもわかりやすいテキストですが、きちんと判定できているようです。

日本語に特化したモデルのインストール

計算環境に余裕がある場合や、多言語のテキストを扱いたい場合は、上記の手順で十分ですが、日本語だけで十分だ、という時には、もう少し小さいモデルが使えるかもしれません。Hugging Faceで検索してみると、1つだけ⁶モデルがありました。akiFQC/bert-base-japanese-v3_nli-jsnli-jnli-jsickモデルは、著名な日本語モデルをさらにファインチューニングしたもの (のよう) です。今度はこちらを使ってみましょう。

fugashiライブラリのインストール

ただ、こちらのモデルは前処理にMeCabを使っており、利用にはfugashiライブラリが必要です。Rから transformer_scores() 関数を実行すると、ただ “object ‘classifier’ not found” とエラーが返ってくるだけで、何が悪いのかよくわかりませんでしたが、reticulate::repl_python() 関数でPythonコンソールを起動し、そちらでモデルの読み込み処理を実行すると、fugashiがインストールされていない、というエラーの原因がわかりました。

Rからminicondaの仮想環境でライブラリをインストールする、というややこしい形になりますが、以下のようにすることでグローバルではなく {transforEmotion} 用の環境にインストールできました。

library(transforEmotion)
library(reticulate)

repl_python()

# 以下はPythonコンソール

!pip install fugashi

exit

これで、日本語に特化したモデルが動かせるようになります。試してみましょう。初回はモデルのダウンロード、インストールに時間がかかります。

text <- c("お正月がとても楽しみだ", "バレンタインは本当に憂鬱だ", "卒論が出せるか不安だ")

transformer_scores(
 text = text,
 classes = c("ポジティブ", "ネガティブ"),
 transformer = "akiFQC/bert-base-japanese-v3_nli-jsnli-jnli-jsick"
)

## $お正月がとても楽しみだ
## ポジティブ ネガティブ 
##     0.2756     0.7244 
## 
## $バレンタインは本当に憂鬱だ
## ポジティブ ネガティブ 
##    0.98643    0.01357 
## 
## $卒論が出せるか不安だ
## ポジティブ ネガティブ 
##    0.93838    0.06162

こちらは、どうも値の大小が逆になっているようです。0が最大、1が最小なのかもしれません。 その振る舞いを理解していれば、多言語モデルよりは多少小さなモデルとして活用できます。

Blueskyのテキストをセンチメント分析する

ということで、環境が整ったので、Blueskyに投稿されたポストをセンチメント分析してみましょう。先ほどの search_post() 関数の実行結果が残っているので、transformer_scores() 関数と組み合わせます。

sentiment_res <- transformer_scores(
  text = res$text,
  classes = c("喜び", "怒り", "哀しみ", "楽しみ"),
  transformer = "MoritzLaurer/mDeBERTa-v3-base-xnli-multilingual-nli-2mil7" 
)

df <- sentiment_res |>
  bind_rows() |>
  rowid_to_column(var = "id") |>
  pivot_longer(cols = c(-id), names_to = "感情") |>
  mutate(感情 = factor(感情, levels = c("喜び", "怒り", "哀しみ", "楽しみ")))

head(df)

## # A tibble: 6 × 3
##      id 感情    value
##   <int> <fct>   <dbl>
## 1     1 喜び   0.173 
## 2     1 怒り   0.388 
## 3     1 哀しみ 0.172 
## 4     1 楽しみ 0.266 
## 5     2 喜び   0.0981
## 6     2 怒り   0.412

200件のポストについて、M3 Macで1分弱かかりました。専門的知識を駆使して🤪ポストの内容と判定結果を見ると、概ね「外した」とか「遅い」といった単語を「哀しみ」「怒り」と判定しているなど、妥当な判定をしているように思います。グラフにしてみましょう。

ggplot(df, aes(x = value, y = 感情, colour = 感情)) +
  geom_jitter() +
  scale_y_discrete(limits = rev) +
  scale_colour_fivethirtyeight()

1
2
3

ggplot(df, aes(x = value, fill = 感情)) +
  geom_histogram(position = "identity", binwidth = 0.025, alpha = 0.5) +
  scale_fill_fivethirtyeight()

言語学ではない、Rの講義でハンズオンとして実行する分には、こんなものでよいのではないでしょうか (?)。

…なんかちゃんとした記事になったので、アドベントカレンダーの時期にやればよかったですね。そして、{transforEmotion} パッケージとモデルが講義で使っているPosit Cloudで動くのかが不安です🤪多分メモリもストレージも足りないんだろうなぁ。

何年か前に、この { } で囲う記法は推奨されない、とかそんな議論があったように思いますが、R以外のソフトウェア、ライブラリと区別するために、ここでは囲っています。 ↩︎
{atrrr}の方は、開発者が実装に向けて協力を求めています。https://github.com/JBGruber/atrrr/issues/23 ↩︎
{bskyr} は、ドキュメントを見ると機能が豊富そうですが、実際手元で試すと、最初の認証からうまくいきませんでした。 ↩︎
例によってなんだかよくわかっていませんが。 ↩︎
例によって（ｒｙ ↩︎
2つありますが、同じ作者で「長い名前の方を推奨します」と書いてあるので。https://huggingface.co/akiFQC/bert-base-japanese-v3_nli-jsnli ↩︎

baseballrパッケージによる大谷翔平選手の投球データの可視化

Mon, 09 Dec 2024 00:00:00 +0000

RでMLBのMVPプレイヤーのホームラン時の投球コースと球種を可視化するという記事がありました。自分でも、教材を作る際にbaseballrパッケージで大谷翔平選手の投球データ (2023年) を取得して、可視化したのを思い出して、コードだけ掲載します。

ライブラリの読み込みなど

library(tidyverse)
library(lubridate)
library(scales)
library(ggthemes)
options(dplyr.width = Inf, scipen = 1, digits = 4)
theme_set(theme_fivethirtyeight(base_family = "Hiragino Kaku Gothic ProN", base_size = 14))
theme_update(axis.title = element_text(), plot.title = element_text(size = 14))
library(baseballr)
library(khroma)
library(ggrepel)

データの取得

ohtani_pitch <- statcast_search_pitchers(start_date="2023-01-01", end_date="2023-12-31", pitcherid="660271")
ohtani_pitch <- ohtani_pitch |>
    mutate(pitch_type = fct_infreq(pitch_type)) |>
    mutate(pitch_type = fct_recode(pitch_type, "n/a" = ""))

head(ohtani_pitch)

## # A tibble: 6 × 113
##   pitch_type game_date  release_speed release_pos_x release_pos_z player_name   
##   <fct>      <date>             <dbl>         <dbl>         <dbl> <chr>         
## 1 FF         2023-08-23          94.2         -1.98          5.78 Ohtani, Shohei
## 2 ST         2023-08-23          76.1         -2.01          5.74 Ohtani, Shohei
## 3 ST         2023-08-23          77.2         -2.05          5.6  Ohtani, Shohei
## 4 FS         2023-08-23          90.1         -1.94          5.69 Ohtani, Shohei
## 5 FS         2023-08-23          90           -1.83          5.76 Ohtani, Shohei
## 6 ST         2023-08-23          79.8         -2.17          5.7  Ohtani, Shohei
##   batter pitcher events      description     spin_dir spin_rate_deprecated
##    <dbl>   <dbl> <chr>       <chr>           <lgl>    <lgl>               
## 1 687952  660271 ""          foul            NA       NA                  
## 2 687952  660271 ""          swinging_strike NA       NA                  
## 3 687952  660271 ""          swinging_strike NA       NA                  
## 4 687952  660271 ""          ball            NA       NA                  
## 5 687952  660271 ""          blocked_ball    NA       NA                  
## 6 458015  660271 "field_out" hit_into_play   NA       NA                  
##   break_angle_deprecated break_length_deprecated  zone
##   <lgl>                  <lgl>                   <dbl>
## 1 NA                     NA                          5
## 2 NA                     NA                         14
## 3 NA                     NA                          6
## 4 NA                     NA                         14
## 5 NA                     NA                         14
## 6 NA                     NA                         11
##   des                                                                           
##   <chr>                                                                         
## 1 Christian Encarnacion-Strand grounds into a double play, third baseman Eduard…
## 2 Christian Encarnacion-Strand grounds into a double play, third baseman Eduard…
## 3 Christian Encarnacion-Strand grounds into a double play, third baseman Eduard…
## 4 Christian Encarnacion-Strand grounds into a double play, third baseman Eduard…
## 5 Christian Encarnacion-Strand grounds into a double play, third baseman Eduard…
## 6 Joey Votto pops out to shortstop Andrew Velazquez.                            
##   game_type stand p_throws home_team away_team type  hit_location bb_type balls
##   <chr>     <chr> <chr>    <chr>     <chr>     <chr>        <int> <chr>   <int>
## 1 R         R     R        LAA       CIN       S               NA ""          2
## 2 R         R     R        LAA       CIN       S               NA ""          2
## 3 R         R     R        LAA       CIN       S               NA ""          2
## 4 R         R     R        LAA       CIN       B               NA ""          1
## 5 R         R     R        LAA       CIN       B               NA ""          0
## 6 R         L     R        LAA       CIN       X                6 "popup"     0
##   strikes game_year pfx_x pfx_z plate_x plate_z on_3b on_2b  on_1b outs_when_up
##     <int>     <int> <dbl> <dbl>   <dbl>   <dbl> <dbl> <dbl>  <dbl>        <int>
## 1       2      2023 -0.61  1.05   -0.11    2.14    NA    NA 668715            1
## 2       1      2023  1.2   0.09    0.89    2.39    NA    NA 668715            1
## 3       0      2023  0.75  0.55    0.8     2.11    NA    NA 668715            1
## 4       0      2023 -1.41  0.58    0.59    1.01    NA    NA 668715            1
## 5       0      2023 -1.36  0.72    1.29    0.18    NA    NA 668715            1
## 6       0      2023  0.25  1.12   -1.03    2.98    NA    NA 668715            0
##   inning inning_topbot  hc_x  hc_y tfs_deprecated tfs_zulu_deprecated umpire
##    <dbl> <chr>         <dbl> <dbl> <lgl>          <lgl>               <lgl> 
## 1      2 Top            NA     NA  NA             NA                  NA    
## 2      2 Top            NA     NA  NA             NA                  NA    
## 3      2 Top            NA     NA  NA             NA                  NA    
## 4      2 Top            NA     NA  NA             NA                  NA    
## 5      2 Top            NA     NA  NA             NA                  NA    
## 6      2 Top            98.3  137. NA             NA                  NA    
##   sv_id   vx0   vy0     vz0     ax    ay    az sz_top sz_bot hit_distance_sc
##   <lgl> <dbl> <dbl>   <dbl>  <dbl> <dbl> <dbl>  <dbl>  <dbl>           <dbl>
## 1 NA     6.27 -137. -6.07    -9.09  33.0 -17.8   3.36   1.55             211
## 2 NA     3.93 -111.  0.0236   8.87  24.1 -31.8   3.36   1.55              NA
## 3 NA     4.74 -112. -1.35     5.24  23.7 -27.5   3.36   1.55              NA
## 4 NA     9.37 -131. -6.85   -18.2   29.7 -24.2   3.39   1.53              NA
## 5 NA    10.7  -130. -9.45   -17.7   27.0 -22.1   3.49   1.53              NA
## 6 NA     2.05 -116. -1.32     1.90  22.6 -22.1   3.4    1.6              175
##   launch_speed launch_angle effective_speed release_spin_rate release_extension
##          <dbl>        <dbl>           <dbl>             <dbl>             <dbl>
## 1         73.8           32            94.6              2289               6.8
## 2         NA             NA            75.7              1217               6.5
## 3         NA             NA            77.2              2188               6.7
## 4         NA             NA            90.5              1000               6.9
## 5         NA             NA            90.8              1045               7  
## 6         75.3           61            80.2              2191               6.6
##   game_pk fielder_2 fielder_3 fielder_4 fielder_5 fielder_6 fielder_7 fielder_8
##     <dbl>     <dbl>     <dbl>     <dbl>     <dbl>     <dbl>     <dbl>     <dbl>
## 1  716890    681351    592273    650859    500871    623205    545341    666160
## 2  716890    681351    592273    650859    500871    623205    545341    666160
## 3  716890    681351    592273    650859    500871    623205    545341    666160
## 4  716890    681351    592273    650859    500871    623205    545341    666160
## 5  716890    681351    592273    650859    500871    623205    545341    666160
## 6  716890    681351    592273    650859    500871    623205    545341    666160
##   fielder_9 release_pos_y estimated_ba_using_speedangle
##       <dbl>         <dbl>                         <dbl>
## 1    592669          53.6                        NA    
## 2    592669          54.0                        NA    
## 3    592669          53.8                        NA    
## 4    592669          53.6                        NA    
## 5    592669          53.5                        NA    
## 6    592669          53.9                         0.017
##   estimated_woba_using_speedangle woba_value woba_denom babip_value iso_value
##                             <dbl>      <dbl>      <int>       <int>     <int>
## 1                          NA             NA         NA          NA        NA
## 2                          NA             NA         NA          NA        NA
## 3                          NA             NA         NA          NA        NA
## 4                          NA             NA         NA          NA        NA
## 5                          NA             NA         NA          NA        NA
## 6                           0.015          0          1           0         0
##   launch_speed_angle at_bat_number pitch_number pitch_name      home_score
##                <int>         <dbl>        <dbl> <chr>                <dbl>
## 1                 NA            11            5 4-Seam Fastball          2
## 2                 NA            11            4 Sweeper                  2
## 3                 NA            11            3 Sweeper                  2
## 4                 NA            11            2 Split-Finger             2
## 5                 NA            11            1 Split-Finger             2
## 6                  3            10            1 Sweeper                  2
##   away_score bat_score fld_score post_away_score post_home_score post_bat_score
##        <dbl>     <dbl>     <dbl>           <dbl>           <dbl>          <dbl>
## 1          0         0         2               0               2              0
## 2          0         0         2               0               2              0
## 3          0         0         2               0               2              0
## 4          0         0         2               0               2              0
## 5          0         0         2               0               2              0
## 6          0         0         2               0               2              0
##   post_fld_score if_fielding_alignment of_fielding_alignment spin_axis
##            <dbl> <chr>                 <chr>                     <dbl>
## 1              2 Standard              Standard                    204
## 2              2 Standard              Standard                     65
## 3              2 Standard              Standard                     69
## 4              2 Standard              Standard                    317
## 5              2 Standard              Standard                    191
## 6              2 Standard              Standard                    105
##   delta_home_win_exp delta_run_exp bat_speed swing_length
##                <dbl>         <dbl> <lgl>     <lgl>       
## 1              0             0     NA        NA          
## 2              0            -0.064 NA        NA          
## 3              0            -0.072 NA        NA          
## 4              0             0.063 NA        NA          
## 5              0             0.042 NA        NA          
## 6              0.036        -0.361 NA        NA          
##   estimated_slg_using_speedangle delta_pitcher_run_exp hyper_speed
##                            <dbl>                 <dbl>       <dbl>
## 1                         NA                     0              88
## 2                         NA                     0.064          NA
## 3                         NA                     0.072          NA
## 4                         NA                    -0.063          NA
## 5                         NA                    -0.042          NA
## 6                          0.019                 0.361          88
##   home_score_diff bat_score_diff home_win_exp bat_win_exp age_pit_legacy
##             <int>          <int>        <dbl>       <dbl>          <int>
## 1               2             -2        0.703       0.297             28
## 2               2             -2        0.703       0.297             28
## 3               2             -2        0.703       0.297             28
## 4               2             -2        0.703       0.297             28
## 5               2             -2        0.703       0.297             28
## 6               2             -2        0.667       0.333             28
##   age_bat_legacy age_pit age_bat n_thruorder_pitcher
##            <int>   <int>   <int>               <int>
## 1             23      29      24                   1
## 2             23      29      24                   1
## 3             23      29      24                   1
## 4             23      29      24                   1
## 5             23      29      24                   1
## 6             39      29      40                   1
##   n_priorpa_thisgame_player_at_bat pitcher_days_since_prev_game
##                              <int>                        <int>
## 1                                0                           14
## 2                                0                           14
## 3                                0                           14
## 4                                0                           14
## 5                                0                           14
## 6                                0                           14
##   batter_days_since_prev_game pitcher_days_until_next_game
##                         <int>                        <int>
## 1                           1                           NA
## 2                           1                           NA
## 3                           1                           NA
## 4                           1                           NA
## 5                           1                           NA
## 6                           1                           NA
##   batter_days_until_next_game api_break_z_with_gravity api_break_x_arm
##                         <int>                    <dbl>           <dbl>
## 1                           0                     1.54            0.61
## 2                           0                     3.93           -1.2 
## 3                           0                     3.33           -0.75
## 4                           0                     2.27            1.41
## 5                           0                     2.11            1.36
## 6                          18                     2.47           -0.25
##   api_break_x_batter_in arm_angle
##                   <dbl>     <dbl>
## 1                  0.61      36.7
## 2                 -1.2       33.4
## 3                 -0.75      34  
## 4                  1.41      37.6
## 5                  1.36      34.8
## 6                  0.25      33.1

球速の分布

1
2
3

ggplot(ohtani_pitch, aes(x = effective_speed)) +
    geom_histogram(fill = fivethirtyeight_pal()(1), colour = "white") +
    labs(title = "大谷翔平投手の投球速度の分布 (2023年)", x = "球速 (マイル)", y = "度数")

ggplot(ohtani_pitch, aes(x = effective_speed, y = pitch_type, fill = pitch_type)) +
    stat_boxplot(geom = "errorbar") +
    geom_boxplot() +
#    scale_fill_light() +
    labs(title = "大谷翔平投手の球種別の投球速度分布 (2023年)", x = "球速 (マイル)", y = "")

ggplot(ohtani_pitch, aes(x = effective_speed, y = pitch_type, fill = pitch_type)) +
    geom_violin() +
    scale_fill_light() +
    labs(title = "大谷翔平投手の球種別の投球速度分布 (2023年)", x = "球速 (マイル)", y = "")

球種別投球数

1
2
3

ggplot(ohtani_pitch, aes(x = pitch_type)) +
    geom_bar(fill = colour("light")(length(levels(ohtani_pitch$pitch_type)))) +
    labs(title = "大谷翔平投手の球種別投球数 (2023年)", x = "球種", y = "度数")

ohtani_pitch_percentage <- ohtani_pitch |>
    group_by(pitch_type) |>
    summarise(prop = n() / nrow(ohtani_pitch)) |>
    mutate(labels = percent(prop), csum = rev(cumsum(rev(prop))), 
         pos = prop/2 + lead(csum, 1), pos = if_else(is.na(pos), prop/2, pos)) |>
    arrange(desc(prop))

ggplot(ohtani_pitch_percentage, aes(x = "", y = prop, fill = pitch_type)) +
    geom_col(colour = "black") +
    geom_label_repel(aes(y = pos, label = labels), size = 4.5, nudge_x = 0.7, show.legend = FALSE) +
    coord_polar(theta = "y", direction = -1) +
    scale_fill_light() +
    labs(title = "大谷翔平投手の球種別投球数 (2023年)", x = "球種", y = "度数", fill = "球種") +
    theme(axis.text = element_blank(), axis.ticks = element_blank(), axis.title = element_blank(), panel.grid.major = element_blank(), panel.grid.minor = element_blank())

ggplot(ohtani_pitch_percentage, aes(x = prop, y = "", fill = pitch_type)) +
    geom_bar(position = position_fill(), stat = "identity") +
    geom_label_repel(aes(x = pos, label = labels), size = 4.5, nudge_y = 0.6, show.legend = FALSE) +
    scale_fill_light() +
    scale_x_reverse() +
    labs(title = "大谷翔平投手の球種別投球数 (2023年)", x = "球種", y = "度数", fill = "球種")

投球マップ

ohtani_pitch_position <- ohtani_pitch |>
    select(plate_x, plate_z, pitch_type) |>
    mutate(plate_x = plate_x * 30.48, plate_z = plate_z * 30.48)

ggplot(ohtani_pitch_position, aes(x = plate_x, y = plate_z, colour = pitch_type)) +
    annotate(geom = "rect", xmin = -28, xmax = 28, ymin = 40, ymax = 105, fill = "black", alpha = 0.3) +
    geom_point(alpha = 0.4, size = 2) +
    scale_x_continuous(breaks = seq(-150, 120, by = 30)) +
    scale_y_continuous(breaks = seq(-30, 200, by = 30)) +
    labs(title = "大谷翔平投手の投球マップ (2023年)", x = "", y = "")

ChatGPTに聞いてみた－線形回帰の正規性の仮定について

Sun, 10 Nov 2024 00:00:00 +0000

「そんなことも理解せずに」という話でしょうが、線形モデルの正規性の仮定について、世の中の説明だと、あたかもモデルを作る前に判断できると書いてあるように見えるんですよね。だいたい実際のソフトの操作の前に書いてあるし。書籍でもWebサイトでも、「誤差項が正規分布してさえいればよいのです」「仮定が成立するか確認してモデルを適用しましょう」とか、いろんなところで書かれていますが、でも、手元のデータで「誤差だけ」正規分布しているかなんてわからないじゃん、といつも引っかかっています。

データ (説明変数) が正規分布っぽく見えない場合、それが本当にデータだけに由来して、誤差は正規分布しているという見分けはつくのでしょうか。そして、よく「Q-Qプロットを見て」ともありますが、「予測値と実測値の誤差を」という時点で、もう予測＝モデル作成してないですか、とも。適用できるかどうか、という話なのにもう適用してるじゃん、と。他にも、「仮定」というけど、実際に誤差を算出して検定してたら、それは「事実」なのでは、とか。

そのへんが (国語的に) いまいちピンとこないので、ChatGPT (o1-preview) に聞いてみました。

Q. 統計学やデータサイエンスにおいて、線形回帰モデルの仮定として、「誤差が正規分布に従うこと」が挙げられます。しかし、実際には説明変数は正規分布に従わず、誤差のみが正規分布に従う、ということは考えにくいように思います。このことについて、文系大学生にもわかるような説明をしてくれますか？

ご質問ありがとうございます。

線形回帰モデルでは、「誤差（残差）が正規分布に従う」という仮定があります。一方で、説明変数（独立変数）は正規分布に従わない場合が多いです。この点について、なぜ誤差だけが正規分布に従うと考えるのか、不思議に思われるかもしれません。

誤差項の正規性と説明変数の分布は独立

まず、重要なのは誤差項の正規性と説明変数の分布は直接関係がないということです。線形回帰モデルでは、説明変数がどのような分布であっても、誤差項が正規分布に従っていれば、モデルの推定や検定が正しく行えます。

なぜ誤差が正規分布に従うと仮定するのか

中心極限定理の適用: 誤差項は、さまざまな小さなランダムな要因（測定誤差や環境の変動など）が積み重なった結果と考えられます。中心極限定理によれば、多数の独立したランダムな要因の和は正規分布に近づきます。

モデルの単純化: 正規分布は数学的に扱いやすく、多くの統計的手法が正規分布を前提としています。これにより、計算や解釈が容易になります。

説明変数が正規分布に従わないことの影響

説明変数が正規分布に従わない場合でも、線形回帰モデルを適用することは可能です。ただし、極端な偏りや外れ値がある場合は、モデルの結果に影響を与える可能性があります。その場合、データの変換やロバストな手法の適用を検討することが望ましいです。

まとめ

誤差項が正規分布に従うという仮定は、モデルの推定や検定を正確に行うために重要です。

説明変数の分布は誤差項の分布に直接影響しないため、必ずしも正規分布に従う必要はありません。

直感的な理解として、誤差は多くのランダムな要因の積み重ねであり、その結果として正規分布に従うと考えられます。

もしさらに詳しい説明や具体的な例が必要であれば、お気軽にお知らせください。

Q. 説明変数について、真の値と誤差を現実のデータにおいて切り分けるのは難しいように思います。仮定を満たしているかは、モデルを作ってから、予測値と実測値の誤差を評価した段階で初めて確認できるのでしょうか？

ご質問ありがとうございます。

説明変数の真の値と誤差の切り分け

おっしゃる通り、現実のデータでは説明変数（独立変数）の真の値と測定誤差を完全に分けるのは難しい場合があります。線形回帰モデルでは、通常以下の仮定が置かれています：

説明変数に誤差がない：説明変数は正確に測定されている、または誤差が無視できるほど小さいと仮定します。

誤差項の正規性：目的変数（従属変数）の誤差項が正規分布に従うと仮定します。

仮定の確認方法

モデルを構築した後で、以下の手順を通じて仮定が満たされているかを確認します。

残差の分析：

残差とは、各データ点での実測値とモデルによる予測値の差です。

残差の分布を調べることで、誤差項が正規分布に従うかを評価できます。

視覚的な検討：

ヒストグラムや**正規確率プロット（Q-Qプロット）**を用いて、残差の分布が正規分布に近いかを視覚的に確認します。

残差がランダムに散らばっているか、特定のパターンがないかを散布図で確認します。

統計的検定：

シャピロ・ウィルク検定などを用いて、残差が正規分布に従うかを統計的に検定します。

説明変数の誤差がある場合の影響

説明変数に誤差が含まれると、以下のような問題が生じる可能性があります。

推定結果のバイアス：回帰係数の推定値が真の値からずれてしまう可能性があります。

モデルの適合性の低下：予測精度やモデルの信頼性が低下することがあります。

対処法

測定誤差を考慮したモデル：

エラーインバリアブルズモデルなど、説明変数の誤差を考慮した統計手法を使用します。

データの品質向上：

説明変数の測定方法を見直し、誤差を減らす努力をします。

感度分析：

説明変数の誤差がモデルに与える影響を評価し、結果の解釈に注意を払います。

まとめ

仮定の確認：モデルを構築した後、残差の分析を通じて誤差の正規性などの仮定が満たされているかを確認します。

説明変数の誤差の扱い：説明変数に誤差が含まれる場合、その影響を理解し、必要に応じて適切な対処法を取ります。

追加のポイント

現実的な視点：完全にすべての仮定を満たすことは難しいため、仮定がどの程度まで満たされていればモデルが有用かを判断することも重要です。

モデルの目的に応じた柔軟性：予測が主な目的であれば、多少の仮定違反があってもモデルが役立つ場合があります。

ご不明な点やさらに詳しい説明が必要な場合は、お気軽にお知らせください。

Q. ということは、結局モデルを作ってみないとそのモデルが統計的に妥当かは判断できず、事前に回帰分析の適用可否を判断することはできないということでしょうか？

ご質問ありがとうございます。

事前に回帰分析の適用可否を判断できるか

おっしゃる通り、モデルを実際に構築してからでないと、そのモデルが統計的に妥当かどうかを完全に判断することは難しいです。しかし、以下の方法で事前に回帰分析の適用可否をある程度判断することは可能です。

データの探索的解析（EDA）を行う

散布図やプロットの作成：

説明変数と目的変数の関係を視覚的に確認します。線形の関係が見られる場合は、線形回帰が適切かもしれません。

相関分析：

説明変数と目的変数の相関係数を計算し、関係性の強さを評価します。

モデルの仮定を事前に検討する

線形性の仮定：

データが線形の関係を示すかを確認します。

独立性の仮定：

観測値が互いに独立しているかを検討します。

等分散性の仮定：

誤差の分散が一定であるかを予測値と残差のプロットなどで確認します。

正規性の仮定：

目的変数の分布を確認し、正規分布に近いかを検討します。

データの質を評価する

外れ値や異常値の検出：

データに極端な値がないかを確認し、それらが分析に与える影響を考慮します。

欠損値の確認：

データの欠損が多い場合、分析結果に影響を与える可能性があります。

事前の統計的検定を行う

正規性の検定：

シャピロ・ウィルク検定などでデータの正規性を確認します。

線形性の検定：

ラインフィットプロットなどを用いて、線形モデルが適切かを検討します。

しかしながら、これらの事前の分析だけでは限界があります。

最終的な判断はモデル構築後に行う必要がある

残差分析：

モデルを構築した後、残差を分析することで仮定が満たされているかを確認します。

モデルの適合度の評価：

決定係数や AIC、BIC などの指標を用いてモデルの適合度を評価します。

仮定違反への対処：

仮定が満たされていない場合、データの変換や別のモデルの適用を検討します。

まとめ

事前の検討は有用だが限界がある：

データの特性や関係性を事前に分析することで、回帰分析の適用可否をある程度判断できます。

モデル構築後の検証が不可欠：

実際にモデルを構築し、仮定が満たされているかを確認することで、統計的な妥当性を判断します。

追加のポイント

専門知識の活用：

統計学やデータサイエンスの専門家に相談することで、適切な手法や仮定の検証方法を得られます。

柔軟な対応：

仮定が満たされない場合でも、データ変換やロバストな手法を用いることで、分析を進めることができます。

結論

事前に回帰分析の適用可否を完全に判断することは難しいですが、データの探索的解析や仮定の検討を通じて、適用の可能性を見極めることは可能です。しかし、最終的な統計的妥当性の判断は、モデルを構築し、仮定が満たされているかを確認した上で行う必要があります。

ご不明な点やさらに詳しい説明が必要であれば、お気軽にお知らせください。

結局のところ、「適用する」という言葉の意図するところ次第なのかな、とも思います。おそらく、書籍やWebサイトの記事を書いている方は、「作成したモデルを成果として公表する」ことを適用、としているのかと思いますが、一方でデータ分析を始めたばかりの人にとっては、「このデータにこの手法を使う」ことを適用、と捉えているのではないでしょうか。使ってよいかどうかのチェックポイントを知りたいのに、モデルができた後の誤差の話をされても、というところでギャップがあるのかもしれません。

そのあたり、「回帰分析の結果が統計学的に妥当で、有用であることを確認するためのポイントがあるが、それは実際にモデルを作ってみるまで、満たしているかわからない。だから、まずはモデルを作って、それからチェックしてみましょう」とでも書いてあれば、ずいぶん我々「下々の者」にとってもわかりやすくなるのではないかな、と感じます。

ツルハシとジーンズ

Wed, 30 Oct 2024 00:00:00 +0000

変化の激しいこのギョーカイで10年もジーンズを売ってたら、それはもうリーバイスなんよ🤪

はじめに書いておきますが、この記事は何かを論じたいわけでも、物申したいわけでもなく、ただ「15年同じ澱みに漂っている者」から見た感想を綴っているだけです。

最近また、「データサイエンティスト論」がお盛んですが、これはもう恒例行事ですね。“下々の者” をご存知ないアカデミアのせんせーが「希望職種」の一つと化したデータサイエンティスト像に疑問を呈し、いつもの有名人が「ツルハシとジーンズ」の例を出して。

検索したら毎年おっしゃっていたので、ちょっと笑ってしまいましたが。で、冒頭につながるわけですが、2019年からゴールドラッシュが続いていて、一攫千金を夢見る人にツルハシやジーンズが売れ続けているのであれば、それはもう「産業」だと思うんですよね。例え話の重箱をつついてもしょうがないですが、そもそもゴールドラッシュ以前にはジーンズがなかったわけで、それを生み出して現在に続く新しいファッションを創造したリーバイ・ストラウスは「イノベーター」じゃないですか。実際、データサイエンティストになるにはスクールだ！といったあたりから、「リスキリング」という国家プロジェクトまで生まれているわけで。¹教育がお金になる、ということが従来からのITベンダー系研修会社だけでなく、広く世間に知れ渡ったことで、新しいビジネス領域が生まれ (そして消え🤪)、社会が (良し悪しにせよ) 変わりました。

多分、ゴールドラッシュの頃にも、それ以前から大学で地質学や土木工学を学んだ鉱山技師たちは、「岩石のことも知らずに金が掘れるか」とか思っていたのでしょう。

それによって人が移動し、街が作られ、鉄道が引かれ、フロンティアが消失しました。そして、ジーンズは鉱山だけでなく、あらゆる人が身につけるものになりました。「アメリカ」が生まれたのです。²現在のゴールドラッシュでも、社会のトレンドが変化し、さまざまな教育コンテンツやスキル標準が作られ、それらをかいつまんだ (発端の) ロードマップが生まれ、高度理系人材にとってのフロンティアが消失しているのでしょう。そして、ジーンズ＝教育≒リスキリングは一部のエンジニアだけでなく、あらゆる人にとって必要なものになりました。「DX」が実現に近づくのです。

そう考えると、社会にとっては、この世の中の動きはそう悪いものではないのではないでしょうか。

個人的にはこれはこれで実体験ベースのノウハウとしてはありだと思う(特にインターン経験)けど、僕らの時代にあった「リアルの勉強会立ち上げて社会人・学生とつながる」みたいなのが最近減ってきてる気がしててそこはなんとかしたい気も。入りたい大手のDSと学生時代から繋がるのが多分一番近道(で、… https://t.co/vAvfG2KUJ1
— akiaki5516 (@doradora09) October 29, 2024

さて、以下はXにポストしようとしたり、実際にポストして「まぁ140文字で伝わらないよなぁ」と思って消したものです。ここに書いたから伝わるとも思っていませんが、せっかくなので書き留めておきます。

データサイエンス界隈、なんでこう形式ばった受験勉強みたいな文化になっちゃったんだろうな。
— Kohta Ishikawa (@_kohta) October 28, 2024

上位を構成する人材が、まさに受験文化の「勝者」だからだと思いますが。

資格を取れば確実に仕事が得られて食いっぱぐれない世界はあるわけで（薬剤師や看護師など）、そういう世界の発想を持つ人たちが流入してDSをやっているんだと考えれば理解できる気がしてきた。
— Kohta Ishikawa (@_kohta) October 29, 2024

博士号、メダル、前から「トロフィー」大好きなギョーカイじゃないですか。

個人的には、10年以上前からデータサイエンティストには「1000万円」という金額がついて回ってたし、「まず東大の赤い『統計学入門』を読んで、次に『はじパタ』、そして『カステラ本』を通読する」とか書籍リストが流布していて、「落下傘方式で学べば良い」という有名人がいて、今と本質的に変わってないと思うんですけどね。本が動画になったり、就職先があの頃のキラキラDSベンチャーから大手コンサル、ITベンダーになっただけで。

10年以上成長せずに同じところを漂っている身からしたら、変わったのは10歳年を取ったあなた達じゃないですか、と。

アメリカ由来の言葉ですが、アメリカでも多分同じような経緯なんじゃないでしょうか。 ↩︎
Wikipediaをざっくり読んだ程度なので、細かい歴史認識についてはご勘弁ください。 ↩︎

DX検定プロフェッショナルレベルを取得しました

Sat, 31 Aug 2024 00:00:00 +0000

先日、DX検定なる資格試験を受験しました。

DX検定™https://t.co/Gy0ROxyoi1

「毎日爆発的に増加するバズワードを確かな知識にする、先端ＩＴ技術トレンドとビジネストレンドを幅広く問う知識検定」

これも「大企業が『取り組んでる感』を出すために社員に受けさせる」系の試験ですね。私見ですが。

画像はシラバスです。 pic.twitter.com/JrZkDlKSX2
— 鶴見教育工学研究所 (@tetlabo) November 14, 2022

2年ほど前に「やってる感」のための資格ですね、とか言っていたことを忘れていました。とはいえ、今回も「研修や授業で資格の一種として取り上げる価値があるだろうか」という見極めが主な目的だったのですが。

試験の概要

細かいことは公式サイトにありますが、大まかには、「60分120問 (1問30秒！) で時事クイズを解きまくる」という試験です。例えば、以下のような形式の問題が出ます。(覚えていないのであやふやですが)

問: (1) 社が2023年11月に発表した、□□システムは、(2) の技術によって○○作業の待ち時間を○%削減できる。

(1) △△ (2) ☆☆

(1) ◎◎ (2) ■■

(1) △△ (2) ■■

(1) ◎◎ (2) ☆☆

技術や制度についての問いよりも、事例やサービス名を問うものが多かったような記憶があります。こんなのが、120問も続きます。

試験の回答テクニック

はじめに、「受験規則には調べて回答するなとは書いていない」ことをアピールしておきたいと思います🤪

実際に、自宅のPCでカメラによる監視等もなく、ただ回答ページが60分で閉じられるだけの試験運用でした。そして、資格について解説するいくつかの記事でも、「調べながら」と書いてあるので、禁止されてはいないのでしょう (恐れ知らずなだけの可能性も)。

DX検定について｜おじ: 試験は調べながら出来るの？→可能です。
【2024】DX検定で受かるコツ！難易度や合格率・おすすめの勉強方法を解説 | AI研究所: DX検定はオンライン受講の場合、調べながら受講することは可能です。

ですから、問題が表示されたら、そこにあるキーワード (と自分が思うもの) をピックアップして、検索結果から信頼できる (出題者がソースにしそうな) メディアの記事を見つけ、その内容と選択肢を照らし合わせて回答する、という戦略は極めて効果的です。…というか、私はまったくの「ノー勉」で、どういう出題形式かも知らずに受験したのですが、それで最上位クラス (後述) だったので、「ググれば回答できる」試験だと思います。

ただし、前述のように60分で120問ですので、1問1問キーワードを考えて検索していては半分も回答できないでしょう。そのため、(自分で「次へ」をクリックして) 問題が表示されたらすぐに、「記事の見出しやリード文になりそうなキーワード」を見つけるスキルは必要です。例えば、上で挙げた問題の例だと、「2023年、□□、☆☆または■■」がキーワードになるでしょう。さらに、「日経」とか「朝日」などを付与すると、だいたい上位3つ目くらいまでに「出題者がネタ元にしたんだな」とわかる、言い回しが問題と酷似した🤪記事が出てきますので、見出しやリード文を確認して回答します。

実際には、上述のようにノー勉で試験の形式も知らずに受験し、回答ページを開いて最初の何問かは「何じゃこりゃ、わかるか！」と思いながら時間をかけて検索していたので、その分のロスで全問回答はできませんでしたが、やり方を掴んでからはスムーズ (自分が何をやっているのかもよくわからなくなるくらい🤪) で、ググっては選択肢を選び、ということの繰り返しで8割くらいは回答できたと思います。

このような意味では、DX検定は「検索力検定」であると言うことができるかもしれません。なお、調べて回答した内容はすでに全て忘れました。

試験の結果

1ヶ月後に受験サイトで結果が発表されます。1000点満点での点数やスコアシートが表示され、600点以上からは認定証のダウンロードが可能です。私は809点で、プロフェッショナルレベル (もう覚えていないけど🤪) でした。

また、さらに2週間ほどして、オープンバッジも付与されます。

現在取得しているオープンバッジ

感想

そもそも2年前に「やってる感」のための試験だなと思い (そして忘れ🤪)、今回も「ひとに薦める価値があるか」を確認するための受験だったので、自分にとって得るものは何もありません。「DX検定プロフェッショナルレベル」をいつどこで名乗ればいいんだ、という点も含め。

ただ、Xで検索すると「会社で強制的に受験させられた」とか「上司に言われた」という方も結構いるようでしたので、やはりDXを打ち出している (でも実践ではなく形作りに留まっている) ような大企業では、このような資格のニーズがあるようです。上記のように、「ググり方」を身に付ければ何も考えなくてもスコアが上がると思いますし、一方で外から問題だけ見ると「こんなにたくさん知っててすごい」となりそうなので、「やってる感」を出したいビジネスパーソンの方にはお薦めできる資格なのかなと思います。

…6000円を会社が出してくれるのであれば。

MacのUTMにインストールしたAlmaLinuxで共有フォルダーを有効化する

Wed, 08 May 2024 00:00:00 +0000

先に結論だけ書いておきますね

UTMでインストールしたAlmaLinuxとホスト間でフォルダーを共有するには9pファイルシステムをサポートしたカーネルが必要
ELRepoリポジトリを有効化する
sudo dnf install kernel-ml でELRepoの9pモジュールがサポートされたカーネルをインストールする
再起動して、mount コマンドなり /etc/fstab に書くなりしてマウントする

share (共有フォルダーをあらわす特殊デバイス名) が /mnt/macos にマウントされている

前置き1

4月から、やむを得ず🤪Macを使っています。6年近く使っていた富士通 FMV LIFEBOOK WU2/B3のバッテリーがヘタったのと、非常勤先の学部がMacなこと¹、そして学割 (教職員割) で少し安く、かつ無金利48回払いができたので、M3 Macbook Air 15インチを購入しました。LIFEBOOKも、大学で学生に配布 (一括購入) されているMacも13インチなんですが、ちょっと画面が小さいなと。年なので🤪　かといって、2キロ超えの16インチProは持ち歩く気にならない²ので、間をとって15インチにしました。さらに、キャンペーンで24000円ぶんAppleギフトカードで還元されたので、(他に使い道もないので) Magic Trackpadを買いました。

まぁ、M3 Macを買った途端にM4チップが発表されたんですが。

前置き2

Macになっても仕事は変わらないので、研修や教材作成のためにLinuxやWindowsの環境が必要なことがあります。イマドキは何でもDockerなのでしょうが、筆者は (未だ) Dockerがよくわかっていないのと、どうせ永続化してしばらく使うのなら、普通の仮想マシンでいいんじゃないかと思っています (DockerでWindowsを動かすのも大変そうですし)。Macで仮想マシンを作成、実行するソフトとして、Parallels Desktopが有名ですが、有償です。他にもVMware Workstation Player(なんだこのURLは…)やVirtualBoxもあります。その中で、今回はオープンソースのUTMを使うことにしました。UTMは、LinuxのKVMでも使われているqemuがベースになっています。App Storeから入手しようとすると1500円するんですが、公式サイトからは無料でダウンロードできます。

仮想マシンの作成は他の仮想化ソフトとほとんど変わらず、マウスクリックや数値の入力だけでできます。今回は、Linux環境を作る必要があったので、AlmaLinuxをインストールしました。

本題

やっと本題ですが、AlmaLinuxをインストールする際に、ホストMacの “デスクトップ” を共有するよう設定したのですが、Linux側からは見えませんでした。調べてみると、Linuxでは mount コマンドのオプションで9pと指定してマウントする必要がありました。仮想マシンのOSがUbuntuであれば、以下の記事の通りにすればよいでしょう。

しかし、標準的なインストール直後のAlmaLinuxでは、

# shareが共有フォルダーを示す特殊なデバイス名っぽい
# /mnt/macosにマウントする
sudo mount -t 9p -o trans=virtio share /mnt/macos/ -oversion=9p2000.L

mount: /mnt/macos: unknown filesystem type '9p'.

といったように「9pというファイルシステムはない」とエラーになりました。さらに調べてみると、RHEL系 (CentOS, Rocky, Alma…) では、標準のカーネルでは9pファイルシステムをサポートしていない (カーネルモジュールを読み込んでいない) ようでした。実際に、以下のコマンドでモジュールのサポート有無が確認できます。

1
2
3

grep -i 9p /boot/config-5.14.0-427.13.1.el9_4.aarch64

# CONFIG_NET_9P is not set

昔は何かハードウェアを認識させるためにカーネルモジュールを追加してリビルドしたりしていましたが、今はめんどい🤪ので、もう少し楽な解決策はないかと調べていたら、UTMのGitHub issueで「ELRepoのカーネルを入れるとよい」とありました。

今まで、RHEL系のLinuxをインストールする時は、EPELリポジトリとRPM Fusionリポジトリを有効化していましたが、ELRepoというのは初めて知りました。なんかサイトがレトロなので、本当に更新されているんだろうかと思いましたが、今も活発に動いているようです。サイトの指示の通りRPMのGPG鍵のインストール、リポジトリファイル (?　/etc/yum.repos.d/ 以下に入るファイル) のインストールを行いました。また、ミラーサーバーの一覧から、物理的にいちばん近そうなKDDI研究所のサーバーを参照するよう設定しました。そして、ELRepoでメンテナンスされているメインストリームのカーネルを以下のようにしてインストールします。

`1`	`sudo dnf install kernel-ml`

現時点でのカーネルのバージョンは6.8.9でした。AlmaLinux (9.4) のデフォルトは5.14.0なので、カーネルのバージョンが関係するような操作をする場合は注意が必要です。新しくインストールしたカーネルでは、9pファイルシステムがサポートされています。

grep -i 9p /boot/config-6.8.9-1.el9.elrepo.aarch64 
CONFIG_NET_9P=m
CONFIG_NET_9P_FD=m
CONFIG_NET_9P_VIRTIO=m
CONFIG_NET_9P_XEN=m
CONFIG_NET_9P_RDMA=m
# CONFIG_NET_9P_DEBUG is not set
# CONFIG_VIDEO_MT9P031 is not set
CONFIG_9P_FS=m
CONFIG_9P_FSCACHE=y
CONFIG_9P_FS_POSIX_ACL=y
# CONFIG_9P_FS_SECURITY is not set

これで、先ほどの mount コマンドが実行できるようになります。その前に、新しいカーネルで起動するために再起動が必要です。

1
2

# 正常にマウントできる
sudo mount -t 9p -o trans=virtio share /mnt/macos/ -oversion=9p2000.L

ここからはUTMのドキュメント通りですが、一般ユーザーでマウントしたフォルダーの読み書きができるように、chown コマンドで所有者を変更します。

`1`	`chown -R $USER /mnt/macos`

また、毎回手動で mount コマンドを実行するのではなく、仮想マシンの起動時に自動マウントするよう、/etc/fstab ファイルに以下の記述を追加します。

`1`	`share /mnt/macos 9p trans=virtio,version=9p2000.L,rw,_netdev,nofail 0 0`

ここまでやって、やっと仮想マシン側で作ったSSH鍵 (id_rsa.pub) をホストに送って authorized_keys に追加し、「ターミナル」アプリから仮想マシンにSSH接続できるようになりました。ただそれ (鍵の送信) がやりたかっただけなんですけどね。

…そして、書いていて気づきましたが、ローカルの仮想マシンなら公開鍵認証じゃなくてもパスワードでSSHできたじゃん、という。

そのために、3年前に中古でMacbook Air Early 2015 (11.6インチ) を買ったんですが、画面デモ用途としても現代ではスペックが足りなすぎました。まぁ、11.6インチはある種の憧れで、ずっと欲しいなぁと思っていたので後悔はしていませんが。 ↩︎
Proは30万円オーバーで、少額減価償却資産の特例 (一括償却) を超えてしまうというのもあります。 ↩︎

第110回Tokyo.Rで発表しました

Sat, 20 Jan 2024 00:00:00 +0000

タイトルの通りですが、2024年1月20日に開催された、第110回Tokyo.RでLT発表を行いました。

スライドを以下に貼り付けます。

20240120_110th_TokyoR_PortfoliodownによるWebサイトの作成など

また、「R言語の教材」についてはR言語の講義資料を公開しますをご覧ください。

【ネタ】日本最強の馬名をRでつくろう！

Thu, 14 Dec 2023 00:00:00 +0000

山ほど書きたいことがある (主に競馬について) んですが、ばっさりカットしました。ちなみに筆者は、全国に15場ある地方競馬のうち、14場 (＋廃止された荒尾) を訪れたことがあります。

2021年12月31日、エンパイアペガサス号の引退レースを見に、日帰りで水沢競馬場に行きました。見ての通り、中止になったんですが🤪

引退式まで見て、年が変わる直前に家に帰り着きました。

この記事では、競走馬の馬名を文字単位で分析し、最も賞金を稼ぐ可能性の高い名前 (文字の組み合わせ) を考察してみます。なお、Windowsのソフトを使ってデータを取得しているため、途中まではWindowsに限定した話です。

競馬と馬名

中央競馬 (JRA) とばんえいを除く地方競馬 (NAR) において、競走馬 (軽種馬) の馬名登録時には審査があり、以下のように基準が決まっています (抜粋)。詳細は「公益財団法人ジャパン・スタッドブック・インターナショナル馬名登録実施基準」(PDF) を参照してください。

カタカナ2文字から9文字以内
アルファベット表記で18文字以内 (空白含む)
過去の著名馬 (国内外のGI勝ち馬等) や直近5年に引退した馬と同名または紛らわしい馬名はNG
奇矯な馬名 (公序良俗に反する、実況に支障がある、商品名など広告宣伝目的である) もNG

また、馬名に使用できる文字は以下の82文字に限られます。

ア～ロ、ワ、ヲ、ンの46文字 (ヲは1997年から使用可能に)
濁音、半濁音の26文字 (ヴを含む)
ァィゥェォッャュョの9文字
長音 (ー)

名は体をあらわすか？

強い馬は名前もかっこいいものです。ディープインパクト、オルフェーヴル、サクラバクシンオー、トウカイテイオー…なんか強そうでしょ🤪そして、特に意識せず (ホントに！) 挙げたこれらの名馬の馬名には、すべて長音が含まれています。もしかしたら、これからデビューする2歳馬には長音を含む名前をつけると強くなるのかもしれません。

それとも、それぞれ時代を築いたキタサンブラック、イクイノックス親子のように、最近は促音 (ッ) をつけると強いのかもしれません (祖父ブラックタイドにも「ッ」がついています)。強い馬の名前には、もしかしたらパターンがあるんでしょうか。

そのように、ここでは文字 (単語ではなく) にフォーカスして、「どの文字はどれくらい強いのか」を分析してみたいと思います。そして、分析結果を踏まえて、「最強の文字を組み合わせた最強馬の馬名」 を提案したいと思います。

そもそも最強馬とは

最強馬論争は、競馬のセカイでも最も荒れる話題です🤪競馬ファンが2人以上いる場所で「最強馬ってどれ？」と絶対に口にしてはいけません。人間関係が破綻します。

とはいえ、何か基準がないと文字と強さの関係が評価できないので、ここでは獲得賞金額が強さであるとします。最も賞金を稼いだ馬が最強馬で、最も賞金を獲得しやすい文字が最強の文字です。「賞金」には1着～5着に入った際に支払われる賞金や、春秋のGIレースを3連勝した場合に支払われるボーナス、様々な手当がありますが、今回は細かな条件は無視して、単純に以下で紹介する競馬データに含まれる「賞金額」の数字を、各馬ごとに合計したものを獲得賞金額とします。

なお、(中央) 競馬の賞金はどんどん高額になっており、間もなく開催される有馬記念の1着賞金は5億円です。20年前 (2003年) は1億8千万円でした。これはGIレースだけでなく、新馬戦や条件戦なども同じです。そのため、単純に昔の馬よりも現在の馬のほうが平均的な獲得賞金は多くなります。それはそれで、馬名 (文字) を分析するうえでは、「最近のトレンド」が反映されるのでよいのかな、と思っています。

馬名と賞金データの取得

ということで、実際にデータを取得して、処理を進めていきましょう。

競馬のデータ

競馬に関するデータを取得する方法はいくつかあります。JRA公式のJRA-VANや、JRDB、地方競馬DATAなどの有償サービスに契約することで、リアルタイムに最新のデータにアクセスできます。

また、日本最大の競馬メディアnetkeiba.comのデータベースには、レース、競走馬、騎手などの膨大なデータが蓄積されており、Webスクレイピングすることでデータを取得できます。大抵の「競馬AI」開発者は、これらのデータをもとに独自の予測モデルを作っています。

が、今回はめんどくさい🤪のと、最新・リアルタイムデータは必要でないので、次に示す方法でデータを取得します。

KEIBA DATA SCOPEのインストール

今回は、KEIBA DATA SCOPEという無償のデータベースソフトをインストールすることで、膨大な量の競馬データ (ただし更新されない) をいちどに入手します。KEIBA DATA SCOPEは、上記JRA-VANや地方競馬DATAに対応したソフトで、“Targetのパクり” です😅本来の用途としては、ソフトから (利用契約した) JRA-VANや地方競馬DATAにアクセスし、さまざまな観点で集計分析して、予想に役立てることができます。

このKEIBA DATA SCOPEのインストーラーには、あらかじめJRA-VANと地方競馬DATAの全期間 (インストーラーリリース時点まで) のデータが組み込まれていて、インストールするだけで利用できます。有償サービスに契約したり、スクレイピングしなくても、(過去の) 競馬データは入手できるのです。なお、記事作成時点でのデータの範囲は、中央競馬は1986年以降、地方競馬は2005年以降、2023年9月26日までです。

早速、KEIBA DATA SCOPEをインストールします。フルセットアップ版のインストーラーに大量のデータが含まれているので、これを上記リンクからダウンロードします。そして、インストーラーをダブルクリックして、後は特に設定することもなく「次へ」や「OK」を押していきます。

KEIBA DATA SCOPEの起動

デスクトップにアイコンが表示されるので、ダブルクリックして起動します。

最初に起動すると、JRA-VANと地方競馬DATAへの接続を促されますが、今回はすでに保存されているデータを使うだけなので、どちらも「いいえ」を選択します。

すると、インターフェースが表示されます。Targetそっくりです🤪

この画面で、さまざまな条件でデータを検索し、集計して出力できます。なお、インストールして確認したところ、地方競馬のデータは馬名や成績は含まれているものの、通算の獲得賞金が含まれていませんでした。本来、サービスに契約して、最新データをダウンロードして使うものなのでしょうがないですが、今回は中央競馬に所属する (した) 競走馬に限定して集計、分析を行うことにします。

競走馬データの抽出と保存

今回は、特に条件を指定せず、データベースに格納されているデータを抽出します。[馬データ検索]メニューをクリックして表示される画面で、まず [2020年生まれ] (現3歳世代) と [中央登録] を選択して、[検索]ボタンを押します。

すると、5000頭あまりのデータが抽出されます。これを、[CSV出力] ボタンを押して保存します。生まれ年ごとのファイルとして保存するので、“2020.csv” といったような名前にします。

これを、10年ぶんほど繰り返します。再度、[馬データ検索] メニューから、[2019年生まれ] と [中央登録] を選択し、検索します。そして、結果をCSVファイルに出力します。同じ手順を、2010年生まれまで繰り返してください。

なお、出力したCSVファイルの文字コードはSHIFT-JISになっています。Rはバージョン4.2以降、Windows版でもUTF-8が標準になっているので、先にUTF-8に変換しておくか、ファイルの読み込み時に文字コードを指定します。

馬名データの分析

使用するパッケージ

さて、ここからはRプログラミングの話です。まず、使用するパッケージを列挙しておきます。

tidyverse
RMeCab
ggthemes

ggthemesパッケージは、見た目を調整するためのものなので、必須ではありません。以下のような感じで読み込みます。

library(tidyverse)
library(RMeCab)
library(ggthemes)
options(dplyr.width = Inf, scipen = 1, digits = 4)
# BIZ UD Gothicフォント: https://fonts.google.com/specimen/BIZ+UDGothic
theme_set(theme_fivethirtyeight(base_family = "BIZ UDGothic", base_size = 14))
theme_update(axis.title = element_text(), plot.title = element_text(size = 14))

馬名テキストファイルの読み込み

まずは競走馬データのCSVファイルを読み込み、今回の分析に必要な列だけ抽出します。ファイルは2010年～2020年までの11個に分かれていますが、最近のreadrパッケージは複数ファイルの読み込みに対応しているので、まとめて読み込みます。

1
2
3

files <- fs::dir_ls(path = "./data", glob = "*.csv")
df <- read_csv(files, id = "year")
knitr::kable(head(df))

year	馬名	性別	中央登録	在厩	所属	市場価格	市場取引時馬齢	馬齢	市場名	毛色	生年月日	獲得賞金	父名	父父名	母名	母父名	生産者	馬主	調教師	母馬齢	母賞金	母持込区分	母中央登録有無	インブリード	系統
./data/2010.csv	ミッキーマンデー	牡	済	NA	栗東	3,150千円	1歳	13歳	北海道サマーセール	栗毛	2010年04月04日	22,860千円	スズカフェニックス	サンデーサイレンス	カルメンジョオー	ミルジヨージ	赤石牧場	三木　久史	中村均	19歳	15,400千円	内国産	有	Northern Dancer 4+5(父方) /Nasrullah 5+5(母方)	サンデーサイレンス
./data/2010.csv	エアマデレーン	牝	済	NA	栗東	NA	NA	13歳	NA	青鹿毛	2010年04月22日	9,890千円	ゴールドアリュール	サンデーサイレンス	エアセイレン	Grand Lodge	稲原牧場	ラッキーフィールド	笹田和秀	6歳	0円	持込	有	Northern Dancer 4×4+5 /Special 4×5	ゴールドアリュール
./data/2010.csv	スリーエアウィーク	牡	済	NA	栗東	5,250千円	1歳	13歳	北海道セレクションセール	鹿毛	2010年03月05日	0円	スペシャルウィーク	サンデーサイレンス	エアリング	ダンシングブレーヴ	稲原牧場	永井商事	坪憲章	11歳	34,100千円	内国産	有	Northern Dancer 5×4+5	スペシャルウィーク
./data/2010.csv	スズカノジェリコ	牝	済	NA	栗東	NA	NA	13歳	NA	鹿毛	2010年04月09日	0円	スズカマンボ	サンデーサイレンス	スズカローズマリー	アフリート	稲原牧場	永井　啓弍	加藤敬二	7歳	19,525千円	内国産	有	Mr. Prospector 4×3	サンデーサイレンス
./data/2010.csv	キタノフェニックス	牡	済	NA	栗東	2,835千円	1歳	13歳	北海道オータムセール	鹿毛	2010年04月23日	0円	スズカフェニックス	サンデーサイレンス	センターシャイネン	ブライアンズタイム	稲原牧場	ジャパンフードビジネス	清水久詞	11歳	6,380千円	内国産	有	Hail to Reason 4×4 /Northern Dancer 4+5×5	サンデーサイレンス
./data/2010.csv	スズカブルパップ	牡	済	NA	美浦	NA	NA	13歳	NA	黒鹿毛	2010年04月11日	0円	スズカフェニックス	サンデーサイレンス	ブリイジースズカ	Danzig	稲原牧場	永井　啓弍	小島茂之	13歳	9,720千円	輸入	有	Northern Dancer 4+5×3	サンデーサイレンス

1頭の競走馬について、大量の情報が含まれています。どれも (競馬ファンにとっては) 興味深いですが、今回は馬名と獲得賞金だけに関心があるので、必要な列を抽出します。

df_part <- df %>%
    select(馬名, 獲得賞金) %>%
    filter(str_detect(馬名, "の", negate = TRUE)) %>%
    filter(str_detect(馬名, "\\p{Katakana}+")) %>%
    mutate(獲得賞金 = str_replace_all(獲得賞金, ",", "")) %>%
    mutate(獲得賞金 = str_replace_all(獲得賞金, "円", "")) %>%
    mutate(獲得賞金 = str_replace_all(獲得賞金, "千", "000")) %>%
    mutate(獲得賞金 = as.numeric(獲得賞金))

knitr::kable(head(df_part))

馬名	獲得賞金
ミッキーマンデー	22860000
エアマデレーン	9890000
スリーエアウィーク	0
スズカノジェリコ	0
キタノフェニックス	0
スズカブルパップ	0

データの中には、「(母名) の (生年)」というかたちで、名前がつかなかった (＝競走馬になれなかった😭) 馬のデータも含まれている可能性がある¹ので、「の」を含むデータを除外しています。また、データベースにはサラブレッドだけでなく、アングロアラブや純アラブも含まれており (ぜんぶ「軽種馬」なので)、それらには漢字の馬名がついていることがあります。²これを、Unicodeクラスの \\p{Katakana} でフィルタリングしています。

また、データベースの獲得賞金はコンマと「千」「円」が付与された文字列になっているので、これをnumeric型に変換しています。なお、「0円」というデータもあるので、「円」を先に除去し、次に「千」を000に変換しています。

これで、分析のためのデータが用意できました。

馬名を文字単位に分割し、Document-Term Matrixを作成する

次に、馬名を1文字ずつ分解します。これには、RMeCabパッケージの docNgramDF() 関数を使います。

1
2
3

docNgramDF(mojiVec = "MeCab", type = 0, pos = "Default", baseform =0,
 minFreq = 1, N = 1, kigo = 0, weight = "no", co = 0 , dic = "",
 mecabrc = "", etc = "" )

`1`	`dtm <- docNgramDF(df_part$馬名, type = 0)`

1
2
3

## 
## number of extracted terms = 82
## to make matrix now

RMeCabパッケージは関数ごとにオプション名が違ったりして、それぞれドキュメントを確認しないといけないですが、type = 0 で文字単位の分割をします。また、今回は指定しませんが、N オプションで文字の組み合わせ (Ngram) のサイズを指定できます。「サクラ」や「メジロ」など競走馬の「名字」にあたる冠名 (かんむりめい) で分析したい時に指定するとよいかもしれません。(マニア向け) まぁそれは「ウマ家」じゃん、という話ですが。

出力は、縦に行名 (“Row xx”)、横に馬名に使用される82文字が並んだ頻度表になります。

`1`	`knitr::kable(head(dtm[,1:10], 10))`

	[ア]	[ィ]	[イ]	[ウ]	[ェ]	[エ]
Row1	0	0	0	0	0	0
Row2	1	0	0	0	0	1
Row3	1	1	0	1	0	1
Row4	0	0	0	0	1	0
Row5	0	0	0	0	1	0
Row6	0	0	0	0	0	0
Row7	0	0	0	0	0	0
Row8	0	0	0	0	0	0
Row9	0	0	0	0	0	0
Row10	0	0	1	0	0	0

これで、「馬名に使われる文字の頻度」がわかるようになりました。せっかくなので、集計してみます。

char_freq_df <- data.frame(freq = sort(colSums(dtm), decreasing = TRUE)) %>%
  rownames_to_column("char") %>%
  mutate(char = str_replace_all(char, "\\[|\\]", ""))
knitr::kable(head(char_freq_df, 10))

char	freq
ー	33884
ン	25724
イ	18374
ル	16703
ス	14262
ラ	12036
ト	11451
リ	10962
ア	10651
シ	9726

長音 (ー) が圧倒的に多いですね。続いてン、イと並んでいます。棒グラフにしてみましょう。

# 頻度順に並ぶよう文字をfactor型にしてlevelを変更する
char_freq_df$char <- as.factor(char_freq_df$char)

ggplot(char_freq_df, aes(x = fct_reorder(char, freq, .desc = TRUE), y = freq)) +
  geom_bar(stat = "identity") +
  labs(title = "馬名に使用される文字の頻度", x = "", y = "度数") +
  theme(axis.text.x = element_text(size = 6))

文字ごとに賞金額を割り当てる

次に、「文字がどのくらい賞金を稼ぐか」🤔を検討します。作成したDocument Term Matrixに各馬の馬名と獲得賞金を結合します。

dtm <- as.data.frame(dtm)
dtm$馬名 <- df_part$馬名
dtm$獲得賞金 <- df_part$獲得賞金
dtm %>%
  arrange(desc(獲得賞金)) %>%
  select(馬名, 獲得賞金) %>%
  slice(1:10) %>%
  knitr::kable()

	馬名	獲得賞金
Row10687	キタサンブラック	1813200000
Row27205	アーモンドアイ	1445800000
Row34589	コントレイル	1108000000
Row31848	クロノジェネシス	1077500000
Row31650	グランアレグリア	1027500000
Row46896	イクイノックス	1005000000
Row12599	シュヴァルグラン	990200000
Row23078	スワーヴリチャード	873100000
Row23201	リスグラシュー	865600000
Row23184	レイデオロ	846000000

データが9月末までなので、イクイノックスの天皇賞・秋とジャパンカップの賞金が加算されていません。また、サウジカップで約13億円を獲得したパンサラッサや、ドバイワールドカップで約9億円を獲得したウシュバテソーロがランクインしていないため、海外の賞金も含まれていないようです。³

この賞金を、馬名の1文字ごとに振り分けます。はじめに、行単位での処理をするよう rowwise() 関数で宣言します。次に、行単位で各列の値を集計する c_across() 関数を使い、馬名の文字数をカウントします (nchar() などでもっと簡潔に実現できますが)。そして、獲得賞金を文字数で割って、「一文字当たり賞金」なる謎の指標を算出します。5万行ほどの処理なので、そこそこ時間がかかります。なお、最後に ungroup() しておかないと、rowwise() の設定がその後の処理にも適用されてしまいます。

dtm <- dtm %>%
    rowwise() %>%
    mutate(文字数 = sum(c_across(-c(獲得賞金, 馬名)))) %>%
    mutate(一文字当たり賞金 = 獲得賞金 / 文字数) %>%
    ungroup()
dtm %>%
  select(馬名, 一文字当たり賞金) %>%
  arrange(desc(一文字当たり賞金)) %>%
  slice(1:10) %>%
  knitr::kable()

馬名	一文字当たり賞金
キタサンブラック	226650000
キセキ	221833333
アーモンドアイ	206542857
ソダシ	197666667
コントレイル	184666667
レイデオロ	169200000
キズナ	147233333
マカヒキ	147000000
ネロ	144620000
イクイノックス	143571429

1文字当たりで見ると、キセキやソダシといったGI馬に加え、ネロ (GIII京阪杯2勝) の「文字パ」🤪🤪🤪の良さが目立ちます。

文字ごとの平均収得賞金を集計する

今度はこの一文字当たり賞金を文字数と掛け合わせます。つまり、キセキであれば、キ: 221833333 × 2, セ: 221833333 × 1という計算です。そして、その結果を全データで平均し、「5万頭のデータにおける、1文字当たりの平均獲得賞金」を算出します。

(このへん、もはや自分でも何を計算しているのかよくわからないので、平均になっていないかもしれません…)

dtm_prize <- dtm %>%
    mutate(across(-c(獲得賞金, 文字数, 一文字当たり賞金, 馬名), ~ .x * 一文字当たり賞金)) %>%
    select(-馬名, -獲得賞金, -文字数, -一文字当たり賞金) %>%
    summarise(across(everything(), mean)) %>%
    t() %>%
    as.data.frame() %>%
    rename(賞金 = V1) %>%
    rownames_to_column("文字") %>%
    mutate(文字 = str_replace_all(文字, "\\[|\\]", ""))

dtm_prize %>%
  arrange(desc(賞金)) %>%
  slice(1:10) %>%
  knitr::kable()

文字	賞金
ー	1048732
ン	820056
イ	579125
ル	552438
ス	475892
ラ	407010
ア	391203
ト	368149
リ	350891
シ	279636

結果として、「ー」は1文字当たり104万8732円の賞金を稼ぐ、ということがわかりました。実際のところ、データに含まれる5万3366頭のうち、賞金が0円の馬が2万2989頭もいるので、平均としては低くなります。中央競馬で賞金を稼ぐことだけでも大変です。

また、文字の頻度とほぼ同じ結果になりました。理由はわかりませんが (計算が間違っている可能性も)、競走馬の馬名を付ける馬主、クラブの人達も「よく走る文字の組み合わせ」をなんとなくわかって使っているのかもしれません。

この結果も、棒グラフにしてみます。ここでは上位10文字だけ、色を変えてみます。

# 頻度順に並ぶよう文字をfactor型にしてlevelを変更する
dtm_prize$文字 <- as.factor(dtm_prize$文字)
dtm_prize <- dtm_prize %>%
  mutate(文字 = fct_reorder(文字, 賞金, .desc = TRUE))

color_list <- c(rep("#fc4f30", 10), rep("#008fd5", 72))

ggplot(dtm_prize, aes(x = 文字, y = 賞金, fill = 文字)) +
  geom_bar(stat = "identity") +
  scale_fill_manual(values = unname(color_list)) +
  labs(title = "1文字当たりの平均獲得賞金", x = "", y = "平均獲得賞金") +
  theme(axis.text.x = element_text(size = 6), legend.position = "none")

この辺の文字を組み合わせた馬名にすれば、たくさん賞金を稼ぐ強い馬になりそうです。

決定！これが最強馬の馬名だ！

ということで、上位の文字を使った馬名を考えてみましょう。ただ、めんどい🤪ので、最近流行りの生成AI (Microsoft EdgeのCopilot) に考えさせました。

あなたはとても優秀なコピーライターで、ネーミングセンスを誰からも評価されています。そこでお願いです。以下の10文字を組み合わせて、競走馬の馬名を5通り作ってください。

ー,ン,イ,ル,ス,ラ,ア,ト,リ,シ

なお、その際には次のルールを必ず守ってください。

日本語、英単語、フランス語、スペイン語で意味がある名前である

カタカナ2文字から9文字以内

アルファベット表記で18文字以内 (空白含む)

過去の著名馬や直近5年に引退した馬と同名または紛らわしい馬名はNG

奇矯な馬名 (公序良俗に反する、実況に支障がある、商品名など広告宣伝目的である) もNG

あなたならできます！がんばってください！

結果は以下のようになりました。

こんにちは、これはBingです。競走馬の馬名を作るのは面白い挑戦ですね。😊

私は以下の5通りの馬名を考えました。どうぞご覧ください。

リアルト (Rialto): ヴェネツィアにある有名な橋の名前です。フランス語とイタリア語で意味があります。カタカナ4文字、アルファベット6文字です。

シリウス (Sirius): 最も明るい恒星の名前です。英語とフランス語で意味があります。カタカナ4文字、アルファベット6文字です。

アイリス (Iris): 虹の女神や花の名前です。日本語、英語、フランス語で意味があります。カタカナ4文字、アルファベット4文字です。

ラトリー (Latry): フランスのオルガニストの名前です。フランス語で意味があります。カタカナ4文字、アルファベット5文字です。

スリアン (Srian): スペイン語で「輝く」や「光る」を意味する「resplandecer」の派生語です。スペイン語で意味があります。カタカナ4文字、アルファベット5文字です。

これらの馬名は、私の知識とインターネットの検索結果に基づいて作成しました。もし、何か間違いや問題があれば、お詫び申し上げます。🙇

私の回答はお役に立ちましたか？もっと知りたいことがあれば、お気軽にお尋ねください。😊

それっぽいですね🤪なんか、ディープインパクト×ヨーロッパ系輸入牝馬の産駒っぽさがあります。もう少し長い名前も考えさせてみましょう。

ありがとうございます。すばらしいです！では、もう5通り名前を作ってください。その際、今度は6文字以上になるように考えてみてください。お願いします。

どういたしまして。ありがとうございます。😊

6文字以上の馬名を作るのは、少し難しいですが、挑戦してみます。

私は以下の5通りの馬名を考えました。どうぞご覧ください。

アリストラ (Aristra): ギリシャ語で「最高の」や「最良の」を意味する「aristos」の派生語です。英語とフランス語で意味があります。カタカナ5文字、アルファベット7文字です。

リシュリエ (Richelieu): フランスの歴史的人物で、ルイ13世の宰相として有名なカトリック教会の枢機卿の名前です。フランス語で意味があります。カタカナ5文字、アルファベット8文字です。

スリランカ (Sri Lanka): アジアの島国の名前です。日本語と英語で意味があります。カタカナ5文字、アルファベット9文字です。

イリュシオン (Illusion): 幻想や錯覚を意味する英単語です。英語とフランス語で意味があります。カタカナ6文字、アルファベット8文字です。

トリスタン (Tristan): ケルト神話や中世の伝説に登場する英雄の名前です。英語とフランス語で意味があります。カタカナ6文字、アルファベット7文字です。

これらの馬名は、私の知識とインターネットの検索結果に基づいて作成しました。もし、何か間違いや問題があれば、お詫び申し上げます。🙇

私の回答はお役に立ちましたか？もっと知りたいことがあれば、お気軽にお尋ねください。😊

ありがとうございます。すばらしいです！では、もう5通り名前を作ってください。その際、今度はカタカナで6文字以上になるように考えてみてください。お願いします。

どういたしまして。ありがとうございます。😊

カタカナで6文字以上の馬名を作るのは、さらに難しいですが、挑戦してみます。

私は以下の5通りの馬名を考えました。どうぞご覧ください。

アリスター (Alistair): スコットランドの男性名で、「人々の守護者」を意味します。英語で意味があります。カタカナ6文字、アルファベット8文字です。

リュシアン (Lucien): フランスの男性名で、「光」を意味します。フランス語で意味があります。カタカナ6文字、アルファベット6文字です。

イリュージア (Illusia): 幻想や錯覚を意味する英単語「illusion」の派生語です。英語で意味があります。カタカナ6文字、アルファベット7文字です。

トリスターナ (Tristana): ケルト神話や中世の伝説に登場する英雄トリスタンの女性版の名前です。英語とフランス語で意味があります。カタカナ7文字、アルファベット8文字です。

スリランキー (Srilanky): アジアの島国スリランカの愛称です。日本語と英語で意味があります。カタカナ7文字、アルファベット8文字です。

これらの馬名は、私の知識とインターネットの検索結果に基づいて作成しました。もし、何か間違いや問題があれば、お詫び申し上げます。🙇

私の回答はお役に立ちましたか？もっと知りたいことがあれば、お気軽にお尋ねください。😊

リュシアンとかイリュージアは社台RHっぽいですね🤪(ュもジも候補に含まれていませんが) これから馬名を登録するみなさまは、こんな馬名を付けてみると、きっと愛馬が活躍してくれることでしょう。

他には、 「トライアール」(Try R!) なんてのもいいですね。 おぉ、いいオチがついた😅

おわりに

この記事では、競走馬の馬名を文字単位で分析し、最も賞金を稼ぐ可能性の高い名前を考えてみました。実際には、馬名は冠名がついたり、両親など血統からの連想や、馬主の各年度のテーマ⁴、本馬自身の特徴⁵などによって名付けられるので、この記事が何かの役に立つことはありませんが、分析のひとつのアプローチということで。

ちなみに、24日に行われる有馬記念の出走馬の中では、シャフリヤール、スルー セブ ンシー ズ、 アイアン バローズや ライラ ック (ックも11、12位) などは、賞金を稼ぎそうな名前をしています。

世の中、「競馬×データ分析」というと予想AIばかりですが、他にも競馬のデータにはいろんな楽しみ方があります。競馬のデータは、ウマとヒト (騎手、調教師、生産者)、数値、文字、絶対値 (タイム、賞金)、相対値 (着順)、時系列 (戦績、通過順位)、血統など、多様な属性のデータが混在したデータセットです。また、ドメイン知識があるかないかで、データの見え方もまったく変わってきます。おそらくそのあたりが、「高度理系IT人材」を魅了して、優れた競馬AIを生み出している理由でもあるのでしょう (他に、土日は10分ごとに予測の答え合わせができる、という手軽さも)。

みなさんもぜひ、「競馬×データ分析」＝ウマナリティクスの世界に、足を踏み入れてみてはいかがでしょうか。

ところで、分析をしていて思い出したんですが、90年代にサラブレ誌で連載されていた「もうひとつのダビスタワールド」(もうダビ) で「最弱馬作り」として「ヘンな馬名をつけると馬がやる気をなくして弱くなる」「同じ文字を何度も使うと投げやりだと判定されて弱くなる」とかやってたんですよね。もちろんゲームにはそんな仕様はないので、単なるネタなんですが。

ちなみに筆者は、「もうダビ」や上掲の「ウマ家」の著者で、現在も (マジメな) 解説者としてテレビに出演している須田鷹雄氏のファンです。ですから「もうダビ」も未だに持っていて、しかも楽天競馬ハッカソンの場で本に須田さんのサインをもらったりしています。

まぁ、楽しかったというか時間の無駄だったというか…。

今回は “中央登録” にチェックを入れているので除外できているはずですが。データベース内には馬名登録されていない馬のデータも多数含まれています。 ↩︎
これも、“中央登録” のチェックで除外できているはずではあります。ちなみに、アングロアラブは競馬からは姿を消しましたが、各地の牧場で乗馬用として、あるいは宮内省の御料牧場で儀礼用の乗馬や各地の神社の神馬となるべく、現在も少頭数ながら生産されています。 ↩︎
これはnetkeiba.com等のデータベースでも同様なので、JRA-VANの一次データが国内 (中央) の賞金のみを記録しているのだと思われます。 ↩︎
シゲルカカリチョウ、シゲルヒラシャインなどの「役職シリーズ」など。 ↩︎
ディープインパクトは、セリで本馬の眼を見たオーナーが、瞳の輝きに吸い込まれそうな衝撃を受けたことから名付けられました。 ↩︎

R言語の講義資料を公開します

Fri, 08 Dec 2023 00:00:00 +0000

GitHubリポジトリ: https://github.com/tetlabo/adv_pgm3_2023

はじめに

筆者は、自営業 (法人ではなく) として、教育・研修・人材育成の領域を仕事にしています。基本的には、社会人研修 (BtoB) のセカイで、すでにある教材で9時17時講義したり、研修会社のオーダーに沿った教材を作成して、生活しています。

そんな中で、縁¹あって、母校の専修大学で2020年から非常勤講師をしています。当初は学部の必修科目 (200数十人受講) を分担して、他の先生が作成した教材でやっていたのですが、それと別に「Rについての授業をやってくれ」という依頼を受けて、2021年から「応用プログラミング3」という科目で「モダンなRプログラミング」をテーマ (自称) とした講義をしています。

3年目も後半にかかり、そろそろ教材も完成したかなと思うので、公開することにしました。R言語について学びたい、と思っている学生や社会人の参考になれば幸いです。商用・非商用問わず自由に使っていただいて構いませんが、代わりに 何か仕事 (研修、非常勤講師、教材・書籍執筆など) をいただければうれしいです。 そのうち、講義動画も撮影して公開しようと思っています。

なお、R言語の利用目的は一般的に統計解析 (データ分析) ですが、本講義では「分析手法については他の授業で学ぶはずなので触れません」というスタンスで、詳しくは説明していません (説明できませんし)。

講義の概要

(激重🤪) シラバス

シラバスには、以下のように記載しています。

＜到達目標＞

R言語の近年の動向を捉え、適切な開発環境、パッケージを選択してプログラミングできる

tidyverseを念頭に置いたモダンなデータ分析フローを理解し、分析を実践できる

機械学習やテキストマイニングなど、分析の目的に応じた手法を選択し、Rプログラムとして実装できる

＜講義概要＞
データ分析のためのプログラミング言語であるRについて、近年 (2010年代後半以降) の開発動向を紹介し、ビジネスや研究の現場で広く使われるパッケージの活用方法を、実際にプログラミングをしながら学習します。講義を通じて、実践的なRプログラミングのスキルを身に着けることを目標とします。なお、本講義の履修者は、R言語について基本的な知識を有していると想定しています。前提知識として想定するのは以下の事柄です。

【前提知識】※第1回の授業で簡単な振り返り、確認を行います。

Rでファイルからデータを読み込むことができる

オブジェクト (変数) を作成し、要素 (行や列) を参照できる

オブジェクトに関数 (データ加工、グラフィックス、統計処理など) を適用し、結果を得ることができる

実際には、第1回から第2回の授業でR言語の基本については概説していますので、Rをはじめて学ぶ方でも問題ないと思います。

教材とハンズオン環境

教材は、R Markdownで作成し、PowerPoint形式で出力しました。²筆者が軸足を置く (伝統的な) 社会人研修の業界では、PowerPointのノート部分に解説文をしっかりと書き込み、「ノート」表示で出力、A4サイズで印刷というのが主流です。³筆者も、そのやり方で10年以上やってきて、それなりに合理的なところがある⁴と思っているので、その形式にしています。

実際に講義する際には、スライド部分が全幅で表示される程度に拡大して使用しています。

また、講義内容に対応したハンズオン環境をPosit Cloudで作成し、学生に提供しています。大学ではG Suite for Educationを導入しているので、学生に付与されたGMailアドレスでログインさせていますが、私用のGMailアドレスその他でも無償で月25時間 (CPU時間) まで利用できます。それぞれのハンズオンは、Posit Cloudの無償版 (1 CPU, 1GBメモリー) で実行できるようにデータサイズなどを調整しています。

ガイダンス、Rプログラミングの基本: 教材PDF / ハンズオン環境
Rプログラミングの基本、最近の動向について: 教材PDF / 補足資料PDF / ハンズオン環境
R Markdownによるレポート作成: 教材PDF / ハンズオン環境
GUIによるデータ分析: Radiant等: 教材PDF / ハンズオン資料 / ハンズオン環境
ggplot2パッケージによるグラフィックス作成 (1): 教材PDF / ハンズオン環境
ggplot2パッケージによるグラフィックス作成 (2): 教材PDF / ハンズオン環境
tidyverseによるデータハンドリング (1): 教材PDF / ハンズオン環境
tidyverseによるデータハンドリング (2): 教材PDF / ハンズオン環境
Rによる統計モデリング、機械学習の基礎: 教材PDF / ハンズオン環境
機械学習フレームワークによる機械学習 (1): 教材PDF / ハンズオン環境
機械学習フレームワークによる機械学習 (2): 教材PDF / ハンズオン環境
RによるWebスクレイピング: 教材PDF / ハンズオン環境

以降は、順次公開します。

日本語テキストマイニング (1)
日本語テキストマイニング (2)
Shinyによるアプリケーション開発 / reticulateによるPythonとの連携 / まとめ

ライセンスなど

教材、プログラムのライセンスは、MITライセンスとします (GitHubリポジトリに設定)。商用、非商用問わず自由にお使いいただいて構いません。ただ、代わりに 何か仕事 (研修、非常勤講師、教材・書籍執筆など) をいただければうれしいです。

本当に縁だけで、学位も研究実績もないんですが。 ↩︎
一発で公開しているもののような出力にはならないので、PowerPoint上でそれなりに手を加えて完成させています。公開しているのはPowerPointからPDFに変換したファイルです。 ↩︎
プログラミングスクールや教育ベンチャーはもちろんそうではありませんし、コロナ禍によるオンライン化やペーパーレス化、さらには印刷コストの削減などさまざまな要因で、A4縦の印刷物、というのは絶対的な要件ではなくなりつつありますが、まだまだ大多数です。会社ごとの個別研修では、未だに印刷した教材を事前納品ということも多いです。 ↩︎
説明したいこと (オプションの細かな相違など) をスライド部分にすべて書き込むと、情報量が過多になり、何かを初めて学ぶ人には負荷になります。また、口頭での説明だけでは聞き逃すこともありますし、後から見返した時に覚えていないこともあります (個人的な感覚として、研修の受講者は講師の話を半分くらいしか聞いていません🤪)。また、今回のように教材だけを公開する場合には、研修ではもっと細かく深い説明をしているのに、スライドだけ見て「内容が薄い」「厳密でない」「こんなのに〇万円？」とか言われるリスクもあります。これは、研修会社の営業が教材を持って提案に行く場合も同様です。そういうことを考えると、結果的にこのスタイルはある程度の合理性があるな、と思っています。実際には、20数年前にOHPやワープロからPowerPointに移行する際に、なんとかA4縦の印刷物を作りたくて辿り着いたのではないかと思いますが。 ↩︎

Edge / ChromeでFaviconを保存しない方法

Wed, 26 Jul 2023 00:00:00 +0000

個人的に、WebサイトのFaviconが好きでないので、ブックマークに表示したくありません。

出典: https://www.homepage-tukurikata.com/hp/favicon.html

以前FireFoxを使っていた頃は、設定項目 browser.chrome.favicons, browser.chrome.site_icons でオフにしたり、実際にデータが保存されているファイル (favicons.sqlite や places.sqlite) を削除していました。

ここ数年は、Microsoft Edgeを使っていて、やっぱり気になってきました。そこで、EdgeでFaviconを表示しなくする方法を調べました。Google Chromeも同様の操作でFaviconを表示しないようにできます。

なお、以下の記述はWindows 11を前提としています (といっても、影響があるのは「ターミナルで開く」メニューの部分だけですが)。

1. Edgeのプロセスを終了させる

Edgeは、(デフォルトでは) ブラウザーウィンドウを閉じても完全には終了せず、バックグラウンドで動作しています。

そこで、タスクマネージャーからEdgeのプロセスを選択し、終了させます。

2. プロファイルフォルダーを開く

Edgeの設定ファイルが格納されているフォルダーを開きます。一般的には、C:\Users\XXXXX\AppData\Local\Microsoft\Edge\User Data\Default (XXXXX は自分のユーザー名) に対象のファイルがあるため、このフォルダーを開きます。AppDataフォルダーは隠しファイルになっているので、見えない場合は表示設定を変更してください。

Chromeの場合も、C:\Users\XXXXX\AppData\Local\Google\Chrome\User Data\Default フォルダーを開きます。

3. Faviconsファイルを削除する

Faviconのデータが保存されているのは、FaviconsとFavicons-journalファイルです。前記のようにEdgeのプロセスを終了した状態で、これら2つのファイルを削除します。

4. 空のFaviconsファイルを作成する

開いているフォルダー内で右クリックし、「ターミナルで開く」メニューを選択します。標準ではPowerShellが起動しますので、プロンプトに以下のコマンドを入力し、実行します。

`1`	`New-Item Favicons -type file`

すると、サイズ0のファイルが作成されます。

5. Faviconsファイルの読み書きを禁止にする

空ファイルを作っただけでは、またそこにFaviconが保存されていくので、このファイルに書き込めないように設定します。Faviconsファイルを右クリックし、[プロパティ] を選択します。続いて、[セキュリティ] タブを選択し、[編集] ボタンをクリックします。

そして、自分のユーザーアカウントを選択し、アクセス許可のチェックリストのうち、[読み込み] と [書き込み] の [拒否] にチェックを入れます (「許可を拒否する」ということで拒否が優先されるようです)。警告が出ますが、[OK] をクリックします。

6. Edgeを起動する

Edgeを起動して、動作を確認してみましょう。まず、ブックマークにFaviconが設定されていたサイトで、Faviconがなくなっています。さらに、例えばYahoo! Japanなど、Faviconが設定されているWebサイトをブックマークしても、Faviconが保存されないことが確認できます。

…ということで、Microsoft Edge / Google ChromeでFaviconを保存しない方法を紹介しました。そもそもFaviconが気になる人、不要だと感じる人は多くないのかもしれませんが、そう思う方の参考になれば幸いです。

2022年にR Markdownで書いた教材・資料のページ数

Sat, 31 Dec 2022 00:00:00 +0000

タイトルの通りなのですが。

昨年後半から、仕事で作成する教材、資料、原稿のほとんどをR Markdownで書くようになりました。私の場合、作成する文書のほとんどはいわゆる「パワポ」なので、bookdownパッケージの powerpoint_presentation2 で出力し、どうしてもそのままではレイアウトのズレが生じるので、PowerPointで整えています。その中で「こう書けばこう出力される」という経験をたくさん積んだので、それを活かしてテンプレートとなるPowerPointファイルもブラッシュアップし、(内容はともかく) 生産性が向上した一年でした。

…ということで、今年作成した資料のページ数を数えてみました。PowerPointファイルだったりWordファイルだったり、ただの章扉もあったりで、1ページの情報量もだいぶ違いますが、単純に完成品のファイルを開いて、表示されるページ数を積み上げました。

その結果、2022年は1700ページ書いていたことがわかりました。

81種類の資料を作成し、合計1700ページ執筆しました

多いのか少ないのかわかりませんが、今年の前半はだいぶ働いた (教材を書いた) なぁという印象があります。代わりに、後半、特に10月と11月はスカスカでしたが🤪 そのぶん、このWebサイトとブログを整備できたり、次の仕事への準備ができたりしたので、トータルでは悪くない1年だったのかと思います。

今年の11月に (ノリで🤪) 自営業の屋号を「鶴見教育工学研究所」と変更しましたが、来年から、さらに「鶴見」(地域) と「教育」の両方をしっかりと意識したビジネスをしていきたいと思います。

それでは、よいお年を。

Posit CloudにMeCab, RMeCab, gibasa, Sudachiをインストールする

Wed, 21 Dec 2022 00:00:00 +0000

結論

それぞれのスクリプトを入手し、実行してください。

MeCabのインストール

RMeCabのインストール

Sudachi (sudachipy) のインストール

デモ環境もどうぞ

上記スクリプトを配置したPosit Cloudプロジェクトを用意しました。Googleアカウントなどでログインし、無料で利用できます (25時間まで)。

https://posit.cloud/content/5159920

はじめに

大学の授業で「モダンなRプログラミング」(自称) を教えています。「文系情報学部」¹なので、ローカルのPC (Mac) に環境構築させるのが大変かな²と、授業ではPosit Cloud (旧RStudio Cloud) にあらかじめ各回の授業で必要なパッケージなどをインストールして共有しています。

ある回のテーマがテキストマイニングで、日本語を処理するためにMeCabと、MeCabをRから利用するためのRMeCab、比較的新しいgibasaをインストールする必要がありました。また、別系統としてSudachiも使ってみることにしました。

Posit Cloudの環境

ただ、Posit Cloudはクラウドサービスなので、ソフトウェアのインストールや、実行 (呼び出し) にいろいろな制約があり、一般的な手順通りではうまくインストールできません。そもそもそういう用途を意図していないのでしょうけど。例えば、以下のような点で不便です。³

root権限がない

Posit Cloudは、裏でUbuntuが使われていますが、ユーザー権限で動いており、sudo や apt などのroot権限が必要なコマンドは実行できません。そのため、何かR以外のソフトウェアを使いたい場合は、ソースコードをダウンロードして、Posit Cloudの環境でコンパイルすることになります。

ソフトウェアをインストールした環境を共有しても、Rパッケージ以外はコピーされない

ユーザーのホームディレクトリ下にソフトウェアをインストールしても、環境を受講者に共有すると、別のユーザー環境が割り当てられ、ホームディレクトリ以下は、パッケージがインストールされる ~/R ディレクトリ以外は共有されません。逆に言えば、インストール先に ~/R 以下を指定すれば共有できますが、(Linuxの) ライブラリへの絶対パス (/home/rXXXXX/R/... の XXXXX 部分) が変わり⁴、一部のパッケージはライブラリを見つけられず、使用できません。

フリープランではメモリが1GBしか使えないので、少し大きなソフトウェアはコンパイルできない

これは「それで困るなら金を払え」ということなのですが、例えば、MeCabの辞書を強化するNEologd辞書を使おうとしても、コンパイル作業の途中でメモリ不足で強制終了されます。おそらく、RadiantやStanなどの大きなパッケージもコンパイルできないでしょう。⁵

なお、Pythonライブラリは pip コマンドでインストールできますが、やはりメモリの問題で、データ分析系の大きめのライブラリはインストールできない場合があります。

そのような環境で、いろいろと試行錯誤して、とりあえず自分の意図した (授業ができる) 環境は作れたので、方法を紹介します。

MeCabのインストール

MeCabは日本語形態素解析器のデファクトスタンダードです。Linux環境では、ソースコードが公開されており、コンパイルしてインストールします。⁶

Posit Cloudの環境では、上述のようにroot権限がないため、システム領域 (/usr/local 下) にはインストールできません。そこで、インストール先をホームディレクトリ (/home/rXXXXX) 以下に指定する必要があります。それ以外は一般的なインストール手順の通りです。MeCabとIPA辞書のソースコードをダウンロードし、ホームディレクトリ下にインストールするスクリプトを作成しましたので、ダウンロードしてPosit Cloud内に配置し、ファイルを開き “Run Script” ボタンを押せば、インストールができます。

これで、/home/rXXXXX/usr/local/ 以下にMeCabがインストールされます。なお、上述のようにこのディレクトリは環境を共有しても引き継がれません。

RMeCabのインストール

次に、RからMeCabを呼び出すRMeCabパッケージをインストールします。この際、RMeCabはコンパイル中にMeCabを探す (mecab-config コマンドなどを実行する) ため、先ほどのホームディレクトリ下にインストールしたMeCabを認識させる必要があります。また、コンパイル時には LD_LIBRARY_PATH や CPPFLAGS などの環境変数も正しく指定する必要があります。このあたりで、以前はじめてPosit CloudでRMeCabを使おうとして大分悩んだのですが、Sys.setenv() 関数とwithrというパッケージを使えば実現できる、ということがStack Overflowにあった (URL失念) ので、そのようにしてインストールするスクリプトを作成しました。これも、ダウンロードしてPosit Cloudに配置し、ファイルを開いて “Source” ボタンを押せば実行されます。MeCabのインストール場所を、withrパッケージの with_makevars() 関数に環境変数を指定してRMeCabパッケージに教えています。

gibasaのインストール

上記のスクリプトでは、gibasaパッケージもインストールしています。RMeCabと同様に、MeCabのインストール場所を教える必要があるため、Sys.setenv() 関数で mecabrc ファイルの場所を、MECAB_DEFAULT_RC という環境変数で指定しています。そして、GitHubに公開されているソースを remotes::install_github() 関数でインストールしています。

Posit Cloud上のRのバージョンについて

Posit Cloudでは、自動的に最新のRに環境が移行するようで、例えば少し前にR 4.2.1で作った環境を、しばらくしてから開くとR 4.2.2で立ち上がります。⁷そのため、上記スクリプトではR 4.2.2のインストールパスを直接指定していますが、今後バージョンが変わった際には、適宜数字を書き換える必要があります。

Sudachiのインストール

MeCab以外の形態素解析器として、近年利用が広がっているSudachiも使ってみました。sudachirパッケージもあるのですが、CRAN版、GitHub版ともに、Posit Cloudの環境では動作させることができませんでした。一方、つい先日投稿されたRでも、良いSudachi Lifeを送りたいという記事があり、RからPythonを呼び出すreticulateパッケージを使って比較的容易にSudachiを活用する例があったので、こちらに沿って教材は作成しました。

いずれにしてもSudachiのPython版sudachipyをインストールする必要がありますが、pipコマンドだけでインストールできます。こちらも、1行だけですがスクリプトにしており、“Run Script” ボタンで実行、インストールできます。

なお、Pythonライブラリは一度プロジェクトを再起動しないとRから見えないようなので、インストール後は画面右上の “…” メニューから、“Relaunch Project” を実行して再起動します。

完了！

これで、MeCab、RMeCab、gibasa、sudachipyが利用できるようになりました。ファイルを用意しておけば、それぞれ長くても数分以内に実行完了するので、講義をしながら適宜指示をして裏で実行させておき、話の区切りがついたところで操作に移る、ということができるでしょう。

デモ環境もどうぞ

上記スクリプトを配置したPosit Cloudプロジェクトを用意しました。Googleアカウントなどでログインし、無料で利用できます (25時間まで)。

https://posit.cloud/content/5159920

おわりに

こんな感じの授業をしており、教材執筆、プレゼンテーションもできますので、データ分析、IT基礎関係の非常勤講師を探している大学、各種学校関係者の方はご検討いただければ幸いです。

Webサイトトップページのお問い合わせフォームなどからご連絡ください。

ヨソの立派な大学の博士課程を修了された先生が言うとなんか問題ですが、自分の母校なので、自分自身を省みて「そんなもの」でしょう。 ↩︎
実際のところ、install.packages() や brew install だけなのですが、それでも手順書を順番通りに実行してくれない人は、社会人研修でも多くいます。そういうトラブルシューティングは面倒なので、ベンダー系研修会社ではPC持ち込みを許可せず、すべて環境を用意して研修をやっています。 ↩︎
タダで素晴らしいものを使わせてもらっているので、それに文句を言うつもりはまったくなくて、「そういう環境だ」と思っているだけです。 ↩︎
Posit Cloudのプロジェクト番号 (URL) とも異なり、予測・決め打ちは不可能です。 ↩︎
多くのパッケージは、Posit社によってバイナリ版が用意されているので、CRANにあるものであれば、コンパイルは不要です。 ↩︎
Ubuntuなどで、バイナリパッケージが提供されていることもあります。 ↩︎
おそらく、バージョンを固定する方法はありません。切り替えは、画面から簡単にできます。 ↩︎

Rのグラフィックスで日本語や記号を化け・ヌケなく表示する

Sat, 26 Nov 2022 00:00:00 +0000

結論

RStudioの中では

raggパッケージを描画に使用するよう設定しましょう。

PNG / JPEGの場合

library(tidyverse)
library(rpart)
library(partykit)
library(ggparty)
library(ragg) # パッケージをインストールする

colnames(iris) <- c("がく片長","がく片幅","花びら長","花びら幅", "種")

res <- rpart(種 ~ ., data = iris)

#---ここが本題！---#
# plot() 関数の結果を出力する場合
## png形式の場合、agg_png() 関数を使う
agg_png("rpart_plot.png", width=1280, height=1280,
  pointsize=24, res=120)
plot(as.party(res))
dev.off()

## jpeg形式の場合、agg_jpeg() 関数を使う
agg_jpeg("rpart_plot.jpg", width=1280, height=1280,
  pointsize=24, res=120)
plot(as.party(res))
dev.off()
#---ここまで本題！---#

# ggplot2で作成したグラフィックスを ggsave() 関数で出力する場合
p <- ggparty(as.party(res)) +
    geom_edge() +
    geom_edge_label(aes(label = prettyNum(breaks_label,
      digits = 1)), size = 4) +
    geom_node_label(aes(label = splitvar), ids = "inner") +
    geom_node_plot(
        gglist = list(geom_bar(aes(x = "", fill = 種),
          position = "fill"), theme_bw(base_size = 15)),
        scales = "fixed", id = "terminal",
        shared_axis_labels = TRUE,
        shared_legend = TRUE, legend_separator = TRUE)

#---ここが本題！---#
# ggsave() では raggパッケージがインストールされていれば
# デフォルトで使用される
ggsave("ggparty_ggsave.png", p, width=1280, height=1280,
  units="px", dpi=120, bg = "white")
#---ここまで本題！---#

plot() 関数の出力結果: 左が png() デバイス、右が ragg::agg_png() デバイス

ggsave() 関数の出力結果: 左が png() デバイス、右が ragg::agg_png() デバイス

PDFの場合

library(tidyverse)
library(rpart)
library(partykit)
library(ggparty)
library(systemfonts) # パッケージをインストールする

colnames(iris) <- c("がく片長","がく片幅","花びら長","花びら幅", "種")
res <- rpart(種 ~ ., data = iris)

#---ここが本題！---#
# cairo_pdf() 関数を使う
cairo_pdf("rpart_plot.pdf", width=12, height=12,pointsize=24,
  family="Meiryo UI")
plot(as.party(res))
dev.off()
#---ここまで本題！---#

# ggplot2で作成したグラフィックスを ggsave() 関数で出力する場合
p <- ggparty(as.party(res)) +
    geom_edge() +
    geom_edge_label(aes(label = prettyNum(breaks_label,
      digits = 1)), size = 4) +
    geom_node_label(aes(label = splitvar), ids = "inner") +
    geom_node_plot(
        gglist = list(geom_bar(aes(x = "", fill = 種),
          position = "fill"), theme_bw(base_size = 15)),
        scales = "fixed", id = "terminal",
        shared_axis_labels = TRUE,
        shared_legend = TRUE, legend_separator = TRUE)

#---ここが本題！---#
ggsave("ggparty_ggsave.pdf", p, width=12, height=12,
  units="cm", dpi=120, bg = "white", device=cairo_pdf,
  family="Meiryo UI")
#---ここまで本題！---#

plot() 関数の出力結果: 左が pdf() デバイス、右が cairo_pdf() デバイス

ggsave() 関数の出力結果: 左が pdf() デバイス、右が cairo_pdf() デバイス

上の結論だけで十分だと思いますが…少し説明

タイトルは文字数の関係でやや対象が広くなっていますが、実際には、(1) Windows環境で (2) RのグラフィックスをPNG / JPEG / PDF出力する (3) 日本語が表示されればフォントの種類にこだわらない　時の話です。(1) OSを限定しない、(2) より汎用的な出力形式で (3) 任意のフォントを使う　場合についての解説として、以下のようなものがあります。

ただ、~~長くてムズカシイんで~~…。Rを長く、本格的に使う方は、Rがフォントを取り扱う仕組みなども学習するとよいと思いますが、「ネット記事をコピペしてRでグラフを描いたら文字が出ない！明日レポートの提出なのに！」といった “普通の” 方には、「とりあえずこうしたら解決するよ」という情報を提示するのも重要かなと思います。

raggパッケージを用いたPNG / JPEG形式の出力

グラフィックスをファイルに出力する場合、PNG / JPEGとPDFでは、方法が異なります。PNG / JPEGについては、近年利用が広まっているraggパッケージを使うと簡単です。標準ではインストールされていないので、install.packages("ragg") としてインストールしましょう。

RStudioでは、標準でグラフィックスにraggパッケージのデバイスを使う機能が組み込まれているので、それを選択するだけで、文字化け・ヌケはなくなります。[Tools] - [Global Options] - [General] - [Graphics] から設定します。また、その操作の際、raggパッケージがインストールされていなければ自動的にインストールもしてくれます。

RStudioにおいてraggパッケージを利用する設定

設定を行ったうえで、[Plots] タブの [Export] ボタンからPNG / JPEGファイルに出力すれば、文字化け・ヌケのないグラフィックスが得られます。

ただしこれは、あくまでRStudioのPlotsタブの設定なので、RStudioを使っていても、プログラム中で png() 関数や ggsave() 関数を使っている部分には反映されません。

プログラム中でグラフィックスを出力したい場合は、raggパッケージが提供する agg_png() や agg_jpeg() デバイスを使います。

library(ragg)
...
agg_png("ファイル名",...)
plot(...)
dev.off()

agg_jpeg("ファイル名",...)
plot(...)
dev.off()

ggplot2を使う場合、ggsave() 関数ではraggパッケージがインストールされていれば、デフォルトで使用されるため、特にデバイス名を指定する必要はありません。

`1`	`ggsave("ファイル名",...)`

systemfontsパッケージを用いたPDF形式の出力

PDFの場合、伝統的には、pdf(..., family="Japan1GothicBBB") と指定する方法があります。ただ、これはフォントを埋め込まず、「日本語のゴシック体」という概念を指定しているだけなので、実際にどのようなフォントで表示されるかはPDFリーダーとOSの設定次第になります。特に、Webサービスなどでは日本語を表示する設定がされていないことが多く、アップロードしたファイルで日本語がヌケてしまうことが多いです。

そのため、PDFにフォントを埋め込むほうが安全です。こちらも、伝統的にいろいろな方法が提案されてきました。

(2012) R のグラフで日本語を使う - 知に至る病 https://amano41.hatenablog.jp/entry/plot-with-japanese-fonts-in-R
(2015) R 好きな日本語書体でグラフに書き込める showtext パッケージ : 研究に使うポスグレ http://kenpg2.seesaa.net/article/415323425.html
(2020) 須通り_統計_Rにおける作図時のフォント設定を極める https://sudori.info/stat/stat_fig_font.html

2022年現在、もっとも手軽な方法は、systemfontsパッケージを使う方法だと思います。Windowsでは、インストールしたフォントをそのまま扱えます。また、OSにインストールしたフォントを使用するには、cairo_pdf() デバイスを使用します。

プログラム例は以下のようになります。

1
2
3

library(systemfonts)
...
cairo_pdf("ファイル名", ..., family = "フォント名")

ggplot2を使う場合も、ggsave() 関数の device オプションと family オプションで日本語フォントを使用できるようになります。

`1`	`ggsave("ファイル名", ..., device=cairo_pdf, family="フォント名")`

なお、お使いのWindowsで使用できるフォントの情報は、systemfontsパッケージの system_fonts() 関数で得られます。以下は、筆者の環境での例です。

1
2

library(systemfonts)
system_fonts() %>% filter(str_detect(name, "Meiryo"))

## # A tibble: 8 × 9
##   path                              index name                family   
##   <chr>                             <int> <chr>               <chr>    
## 1 "C:\\Windows\\Fonts\\meiryo.ttc"      0 Meiryo              Meiryo   
## 2 "C:\\Windows\\Fonts\\meiryo.ttc"      1 Meiryo-Italic       Meiryo   
## 3 "C:\\Windows\\Fonts\\meiryo.ttc"      2 MeiryoUI            Meiryo UI
## 4 "C:\\Windows\\Fonts\\meiryo.ttc"      3 MeiryoUI-Italic     Meiryo UI
## 5 "C:\\Windows\\Fonts\\meiryob.ttc"     0 Meiryo-Bold         Meiryo   
## 6 "C:\\Windows\\Fonts\\meiryob.ttc"     1 Meiryo-BoldItalic   Meiryo   
## 7 "C:\\Windows\\Fonts\\meiryob.ttc"     2 MeiryoUI-Bold       Meiryo UI
## 8 "C:\\Windows\\Fonts\\meiryob.ttc"     3 MeiryoUI-BoldItalic Meiryo UI
##   style       weight width  italic monospace
##   <chr>       <ord>  <ord>  <lgl>  <lgl>    
## 1 Regular     normal normal FALSE  FALSE    
## 2 Italic      normal normal TRUE   FALSE    
## 3 Regular     normal normal FALSE  FALSE    
## 4 Italic      normal normal TRUE   FALSE    
## 5 Bold        bold   normal FALSE  FALSE    
## 6 Bold Italic bold   normal TRUE   FALSE    
## 7 Bold        bold   normal FALSE  FALSE    
## 8 Bold Italic bold   normal TRUE   FALSE

R Markdownの場合

R Markdown文書では、setup チャンクに以下のように書いておけば、文書内で作成するグラフィックスのデバイスを指定できます。

```{r setup, include=FALSE}
knitr::opts_chunk$set(cache = FALSE, dev = "ragg_png")
```

Posit Cloudの場合

Posit Cloud (旧RStudio Cloud) では、裏で動いているOS (Ubuntu Linux) が「標準の日本語フォント」を知らないので、出力時に family を明示する必要があります。Posit CloudにはIPAexフォントがインストールされているので、family = "IPAexGothic" といったように指定すればよいでしょう。

まとめ

昔に比べれば、Rのグラフィックスにおける日本語の表示は格段に簡単になりました。フォントやそのバックエンドの知識がなくても、「とりあえずragg」「とりあえずsystemfonts」を使えば、表示できます。

論文や社内文書などでも、「MSゴシックで」など~~アホみたいな~~フォントの指定が求められることがありますが、この記事で紹介した方法で対応可能です。