メモ on 鶴見教育工学研究所

生成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は本当になんかすごいなぁ、と思いました。

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万円オーバーで、少額減価償却資産の特例 (一括償却) を超えてしまうというのもあります。 ↩︎

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が気になる人、不要だと感じる人は多くないのかもしれませんが、そう思う方の参考になれば幸いです。

URLメモ

Tue, 08 Nov 2022 00:00:00 +0000

いくつか、控えておきたいWebサイトのURLを。

YAMLで履歴書を作る - Qiita

2020年7月17日付で、日本規格協会グループは、JIS Z 8303『帳票の設計基準』に掲載されていた「履歴書」の様式例を削除しました。2020年7月19日現在は「お知らせ」に記載されていますが、パーマネントリンクが無いようなので、そのうち消えるかもしれません。お知らせによると、もともとJIS Z 8303は帳票の仕上げ寸法等を規定するものであり、個々の帳票の様式を規定するものではなかった、とのことです。つまり、履歴書の様式は、あくまで「例」として掲載されていたもので、JISで規定されていたものではなかったということです。

いわゆる「履歴書」フォーマットって、そもそも定義されていなかったし、指定されるいわれもない、ということなんですね。とはいえ、(新卒) 採用する側からすると、大量の応募者がそれぞれ異なるフォーマットで送ってくると処理しにくいですし、「なんで書式が違うの？」「いや、JISでは定義されてないので」と言ってくる応募者も (なんかめんどくさそうで) 敬遠されるでしょうから、今後も「なんとなく標準」みたいな感じで、“あの” フォーマットが使われていくのでしょうね。そもそも今はWebフォームですかね。

Bluetooth経由で出力を制御できる “IoT電池” Mabeeeを、いくつか持っているんですが、せっかくなので、Pythonなどから操作するハンズオンなどをやりたいなと思っています。ただ、Python向けのSDKや、Windowsでの操作例がなかったので調べていたら、根本的にはBluetooth Low Energyデバイスの操作なので、いくつか利用できそうなライブラリがありました。

PowerShell コンソール内で curl や wget が実行できないとお嘆きのあなたへ : @jsakamoto

Windowsにもcurlやwgetが含まれているんですね。そして、PowerShellではそれがシェルコマンドへのエイリアスになっていて、意図したように動作しないと。