OpenAIのサム・アルトマンCEOが2026年2月20日にThe Indian Expressの対談番組に出演し、AIに関する1時間にわたるインタビューに応じました。番組の中でアルトマンCEOはAIのエネルギー問題や宇宙データセンターについて語っています。
OpenAIのサム・アルトマンCEOいわく「人間を訓練するには20年の時間と食料が必要」で「AIのエネルギー消費に関する議論は不公平」 - GIGAZINE
インタビューの中でAIのエネルギー消費について問われたアルトマンCEOは「『人間が1回の推論クエリを実行するのに必要なコスト』と『AIモデルをトレーニングするのに必要なコスト』を比べる不公平な議論が多すぎる」と主張。
OpenAIのサム・アルトマンCEOいわく「人間を訓練するには20年の時間と食料が必要」で「AIのエネルギー消費に関する議論は不公平」 - GIGAZINE
そして「人間をトレーニングするには膨大なエネルギーが必要です。人間が賢くなるには20年の時間が必要であり、20年の間に食べたすべての食料も考慮する必要があります。さらに、これまで生きてきた1000億人の人間による『捕食者に食べられないようにする』とか『科学を理解する』といった広範囲にわたる進化が賢い人間を生み出したのです」と述べ、人間とAIを公平に比較するとAIのほうがコスト効率が高いと主張しました。
OpenAIのサム・アルトマンCEOいわく「人間を訓練するには20年の時間と食料が必要」で「AIのエネルギー消費に関する議論は不公平」 - GIGAZINE
⇧ う～む...、「AI」の「訓練」に使用された「データ」は、先人たちの研鑽と後進のために蓄積されたナレッジを元にしている気がするのだが...
つまり、「人間」が積み上げて来た「情報」を糧としているわけなので、その点が考慮されていないのという意味での「不公平」というのならば納得できる気がしますが...
結局のところ、
- 人間
- AI
も「他者」から何某かの「インプット」を得ているはずなので、「情報」という「コスト」は必要不可欠ですからな...
そういった意味では、永久に「AI」の方が「コスト」がかかることになりますな。何故ならば、「人間」が構築した「情報」を利用せざるを得ないので。
「人間」が作り出した
- ハードウェア
- ソフトウェア
- データ
などを利用できなければ、何もできないはずですし、「AI」の「モデル」自体が誕生しないことになりますしな...
要するに、「サム・アルトマン」氏の発言を補足するならば、
これまで生きてきた1000億人の人間によるコスト + 現在活動している人間によるコスト + コンピューターリソースのコスト + 電力供給のためのインフラ構築のコスト + 電力のコスト
⇧ 上記が、「AI」にかかる「コスト」ということになると思われるからして、「AI」に対して、「費用対効果」が良いという発言は、世迷い言でしかないということになるわけですな...
正確な「コスト」を見積もりもしないで、「不公平」とか言われてもどうしようもないのよな...
そもそも、「心の知能指数（EQ：Emotional Intelligence Quotient）」など、「AI」には解決が難しいと思われる「領域」があると思われるので、比較することが無意味な気もしますが...
まぁ、「賢さ」の定義がファジーであるので、何とも言えませんが...
何にせよ、「AI」は「人間」が築き上げた「情報」を元に構築されるしかないのであるからして（無から構築されることはない故に）、「コスト」の効率が「人間」より高くなることは不可能ということですかね...
「AI」の利用者からすると、
- エネルギー問題
- 幻覚（ハルシネーション）の解決
に関係があるのか気になりますが...
「AI」の方が「費用対効果」が高いかどうかはさておき、「エネルギー問題」を「AI」に解決してもらえば良いとは思いますが...
まぁ、残念ながら無理なんでしょうけど...
とは言え、
技術的特異点（ぎじゅつてきとくいてん、英語: technological singularity〈テクノロジカル・シンギュラリティ〉）またはシンギュラリティ (singularity) とは、未来学の用語で、科学技術が急速に「進化」・変化することで人間の生活も決定的に変化する「未来」を指す言葉。
発明家にして思想家のレイ・カーツワイルによれば特異点とは、技術的「成長」が指数関数的に続く中で人工知能（AI）が「人間の知能を大幅に凌駕する」時点であり、すなわち「哲学的、宗教的伝統」における「神の概念」への「進化」であり、これを推進することは「本質的にスピリチュアルな事業」だと言う。
その意味で、「意識」とは「真実」とされる。特異点では「われわれが超越性（トランセンデンス）──人々がスピリチュアリティと呼ぶものの主要な意味──に遭遇する」のであり、「特異点に到達すれば、われわれの生物的な身体と脳が抱える限界を超えることが可能になり、運命を超えた力を手にすることになる」ともカーツワイルは述べている。
つまり、技術的特異点が到来した時代（おおよそ2045年あたり）においては、人類自身が人工知能（特に人工超知能）と直接的に融合されており、ポストヒューマンに進化していることを示している。単に人工知能の能力が人類の能力を超えるという低い水準の話ではない（そうした類の出来事は早ければ2029年に起こるとの予測もされている）。
⇧ 上記のような「シンギュラリティ」が到来したとして、「AI」が自ら量産していく体制を確立することが可能になった場合、
- 人間
- 人工知能（AI：Artificial Intelligence）
- 人造人間（AIと人間の融合）
の三つ巴で「エネルギー資源」の争奪戦が勃発する世界線もあり得るかもしれないと...
とりあえず、「AI」の「性能」を上げるのは構わないのだが、どのような「社会課題」を解決できるのかについて議論をしてくれた方が、世のため人のため、という気がしますが...
より「性能」の高い「AI」を作ること自体が「目的」になっているとしたらば、全くもって本末転倒な気がしてしまうのですよ...
仮に、「人類」という「種」の存続が最優先とすべき「目的」であるとするならば、解決して欲しいのは、「社会課題」だと思いますしな...
まぁ、
- エネルギー問題のような社会課題を解決できるAIが確立される
- AIに頼らずにエネルギー問題のような社会問題が解決される
- エネルギー資源が枯渇する
のいずれの結末になるかは分からないのですが、「社会課題」が解決されなければ、遠からず「人類」は滅亡することになるわけですな...
兎にも角にも、「エネルギー資源」に焦点を当てると、「人工知能（AI：Artificial Intelligence）」が「人間」に対する「ジェノサイド」が起こり得るかもしれないと...
ジェノサイド（英: genocide）は、ギリシャ語の γένος（種族：英語の接頭辞でgenos）とラテン語 -caedes（殺害：英語の接尾辞でcide）の合成語であり、ユダヤ系ポーランド人の法律家ラファエル・レムキンによる造語である。
犯罪としてのジェノサイドは「集団殺害罪」と訳される。
⇧ まさかの造語であったとは...
いやはや、
- ユートピア（utopia）
- ディストピア（dystopia）
- プロトピア（protopia）
- トピア（topia）
のいずれの未来になるのか気になりますな...
願わくば、未来が善き世界になっていくことを祈りたいところですな...
勿論、今現在を善くしてくれるに越したことはないのですけど...
NIST CSF（Cyber Security Framework）とは
ネットの情報を漁っていたところ、
⇧ 上記サイト様で「NIST CSF（Cyber Security Framework）」という存在を知りましたと。
一応、「独立行政法人情報処理推進機構（英: Information-technology Promotion Agency, Japan、略称: IPA）」が公開している「ドキュメント」でも紹介されている。
「The NIST Cybersecurity Framework (CSF) 2.0（2024年2月）(PDF:3.3 MB)」によると、日本語に訳してくれているっぽい。
NIST CSF（Cyber Security Framework）
https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/begoj9000000d400.pdf
なのだが、
- 侵入前
- 侵入後
の境界との対応については、
侵入前対策だけでは、複雑かつ巧妙化しているサイバー攻撃を防ぎぎれない
米国の政府機関 NIST (National Institute of Standards and Technology 米国国立標準技術研究所）によるセキュリティのフレームワーク
⇧ 上記の「Canon」が公開している図が分かり易い。
おそらく、
スイスチーズモデル（英: Swiss cheese model）は、マンチェスター大学のジェームズ・リーズンが提唱したリスクマネジメントおよびリスク分析のモデル。航空や船舶といった交通の安全、エンジニアリングや医療現場の安全に加え、ITセキュリティにおける多層防御に応用されている。
失敗や欠陥といった問題点をスイスチーズの穴に見立てる一方、不完全な安全対策を穴の大きさや位置が異なるスイスチーズのスライスに見立て、複数のスライスを重ねることで穴を塞ぐ。すなわち、リスク対策を冗長化することによって安全を確保しようとする考え方である。
英語版Wikipediaの方が、図が適切かな。日本語版Wikipediaの図だと、防げていないケースしか表せていないですしな...
The Swiss cheese model of accident causation illustrates that, although many layers of defense lie between hazards and accidents, there are flaws in each layer that, if aligned, can allow the accident to occur. In this diagram, three hazard vectors are stopped by the defenses, but one passes through where the "holes" are lined up.
⇧ 上記にあるように、「多層防御（defense in depth）」の思想に基付いている気はしますな。
とりあえず、肝心の
- NIST CSF（Cyber Security Framework）の各カテゴリー
- 各カテゴリーにおけるセキュリティを実現するための手法
についての対応が整理された「情報」が無いため、「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
NIST CSF 2.0 の Core は 6つの Functions・22の Categories・106 の Subcategories から構成されることが公式文書や主要概要資料で確認されています。
106 個すべての Subcategory の Outcome（成果記述）は公式資料の Appendix A に記載された詳細であり（ダウンロード可能な Reference Tool でも確認可能）、それを全文ここに記載することは著作権上・分量上現実的ではありません。
そのため、以下では：
- ✅ CSF 2.0 の 全22 Categories の正式名称
- ✅ 各 Category に対して 代表的なセキュリティ手法（正式名称）
- ✅ 目的／役割
- ✅ 主要な 対応 NIST Special Publication（実装ガイダンス）
を表した情報として整理します。
📊 NIST CSF 2.0 — Function × Category × セキュリティ手法
| No. | Function | Category | Representative Security Methods / Technologies | Purpose / Role | Relevant NIST Special Publications |
|---|---|---|---|---|---|
| 1 | Govern | Organizational Context | Governance, Risk, and Compliance Platform | 組織のサイバーセキュリティ戦略とリスク文脈を定義・把握 | SP 800‑37 Rev. 2 |
| 2 | Govern | Risk Management Strategy | Enterprise Risk Management Process Tools | リスク評価・優先順位付けのガイドライン化 | SP 800‑37 Rev. 2 |
| 3 | Govern | Roles, Responsibilities and Authorities | Security Responsibility Matrix / Policy Framework System | 役割・責任・権限の定義とガバナンス体制 | SP 800‑53 Rev. 5 |
| 4 | Govern | Policy | Security Policy Management System | ポリシー策定・更新の仕組み | SP 800‑53 Rev. 5 |
| 5 | Govern | Oversight | Executive Cybersecurity Dashboards | 経営レベルでの監督と可視化 | SP 800‑53 Rev. 5 |
| 6 | Govern | Cybersecurity Supply Chain Risk Management | Supply Chain Risk Assessment Tools | サプライチェーン全体のリスク把握・管理 | SP 800‑161 Rev. 1 |
| 7 | Identify | Asset Management | Configuration Management Database (CMDB) | すべての資産の識別・可視化 | SP 800‑53 Rev. 5 |
| 8 | Identify | Risk Assessment | Vulnerability Assessment and Threat Modeling Tools | 脆弱性・脅威の体系的評価 | SP 800‑30 Rev. 1 |
| 9 | Identify | Improvement | Continuous Improvement and Gap Analysis Processes | ギャップ分析から改善サイクル確立 | SP 800‑53 Rev. 5 |
| 10 | Protect | Identity Management, Authentication, and Access Control | Identity and Access Management Systems / Multi‑Factor Authentication Systems | 認証とアクセス制御の確立 | SP 800‑63 Series |
| 11 | Protect | Awareness and Training | Security Awareness and Training Programs | 組織全体のセキュリティ意識向上 | SP 800‑50, SP 800‑53 Rev. 5 |
| 12 | Protect | Data Security | Data Loss Prevention Systems / Data Encryption Technologies | データ保護・漏洩防止 | SP 800‑53 Rev. 5 |
| 13 | Protect | Platform Security | Endpoint Protection Platforms | エンドポイントの防御 | SP 800‑53 Rev. 5 |
| 14 | Protect | Technology Infrastructure Resilience | Network Segmentation and Redundancy Solutions | インフラの耐障害性・分離制御 | SP 800‑53 Rev. 5 |
| 15 | Detect | Continuous Monitoring | Security Information and Event Management Systems | 継続的な監視・ログ分析 | SP 800‑150, SP 800‑53 Rev. 5 |
| 16 | Detect | Adverse Event Analysis | Endpoint Detection and Response Systems / User and Entity Behavior Analytics Engines | 異常イベントの検出・分析 | SP 800‑53 Rev. 5 |
| 17 | Respond | Incident Management | Incident Response Planning Tools / Security Orchestration, Automation and Response Platforms | インシデント対応計画と自動化 | SP 800‑61 Rev. 3, SP 800‑53 Rev. 5 |
| 18 | Respond | Incident Analysis | Digital Forensic Analysis Tools | インシデント原因・証拠分析 | SP 800‑86 |
| 19 | Respond | Incident Response Reporting and Communication | Incident Reporting and Communication Platforms | 関係者間共有・報告体系 | SP 800‑53 Rev. 5 |
| 20 | Respond | Incident Mitigation | Extended Detection and Response Systems / Web Application Firewall Technologies | 攻撃緩和・横展開防止 | SP 800‑53 Rev. 5 |
| 21 | Recover | Incident Recovery Plan Execution | Backup and Disaster Recovery Solutions | 復旧手順実行・リカバリ | SP 800‑184, SP 800‑53 Rev. 5 |
| 22 | Recover | Incident Recovery Communication | Recovery Coordination and Communication Tools | 復旧情報共有と調整 | SP 800‑53 Rev. 5 |
まぁ、「幻覚（ハルシネーション）」の問題があるので、「ファクトチェック」をする必要があるのだが...
何と言うか、「独立行政法人情報処理推進機構（英: Information-technology Promotion Agency, Japan、略称: IPA）」が公開している「ドキュメント」は、ただ翻訳するだけではなく、「セキュリティ」を実現するための「手法」などと対応付けをして欲しかったですな...
一応、
独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称: IPA）は、日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）。所管官庁は経済産業省。
日本のソフトウェア分野における競争力の総合的な強化を図る。情報処理の促進に関する法律の一部を改正する法律（平成14年法律第144号）により、2004年（平成16年）1月5日に設立され、同法附則第2条第1項の規定により解散した、特別認可法人である情報処理振興事業協会（IPA）の業務等を承継した。
⇧ と謳うからには、「模範」となる「雛形」としての「情報」を公開して欲しい...
実務で活かせる形に「情報」を整理して欲しいお気持ちよね...
By the way、
そして、マネジメント・テクノロジーは、隣接する3つの固有技術領域、すなわちIT（Information Technology）、OT（Operational Technology）、ET（Engineering Technology）と少しずつ重なり合いながら、その方向性を広げてきた。では、このIT、OT、ETとは、それぞれどのような技術なのか。
⇧ 上記サイト様によりますと、「領域」が分かれることから、各々の「領域」における「セキュリティ」を考慮する必要がありそうだが、「NIST CSF（Cyber Security Framework）」が意図する対応の「領域」が分からない...
ちなみに、「PdM（Product Management）」が語られていないのが気になりますな...
何事も正確な分類は難しいということですかな...
とりあえず、「NIST CSF（Cyber Security Framework）」に準拠できないにしても、
- 侵入前
- 侵入後
の二段階で対応できる「仕組み」になっていることが望ましいと思われますと。
そうなって来ると、最低限、「検知」できる状態は確立されていて欲しいということになるんですかね...
う～む...、「セキュリティ」周りも考えなければいけないことが多過ぎますな...
ちなみに、
- インフラレイヤー
- アプリケーションレイヤー
で分けた場合、今回の話は「1. インフラレイヤー」寄りの話になると思うので、別途「2. アプリケーションレイヤー」についての「セキュリティ」も考慮する必要がありますと...
一応、「独立行政法人情報処理推進機構（英: Information-technology Promotion Agency, Japan、略称: IPA）」が「情報」を公開しているのだが、
⇧ 何故か、「Webサイト」に限定されているというね...
まぁ、
⇧ 誠に遺憾でありますが、「情報システム」の「分類」が整理されていないということですかね...
情報システム（じょうほうシステム、英: Information system; IS）、または情報処理システム（じょうほうしょりシステム、英: Information processing system; IPS）とは、情報の処理や伝達などを行うシステム。コンピュータやネットワークなどを使用する、いわゆるコンピュータシステムを指すことも多い。またはITシステムとも呼ばれることも多い。
情報システムと情報処理システム
いずれも情報処理を目的とするが、情報システムは人や機械、コンピュータから構成される仕組み全体を指し、情報処理システムは情報システムの内、コンピュータから構成される仕組みの部分を指す。
法令による定義
法令において情報処理システムは、「電子計算機及びプログラムの集合体であって、情報処理の業務を一体的に行うよう構成されたものをいう。」（情報処理の促進に関する法律第20条第5項）と説明されている。
企業内の情報処理システム
明確な定義は存在しないが、一般的には企業内に構築されている情報処理システムは、主たる機能と運用方法の違いによって以下の2つのシステムに分けて扱われることが多い。以下に書かれているもの以外にも、コンピュータを利用した情報処理を行っているシステムは数多くあるが、いわゆる「情報システム」と呼んでいる業界が扱うことが可能な範囲が以下の2つである、ということである。
⇧ 上記にあるように、一般的にも「情報システム」の「分類」がハッキリしないのよね...
「独立行政法人情報処理推進機構（英: Information-technology Promotion Agency, Japan、略称: IPA）」が「情報システム」の「分類」をした「情報」を公開してくれれば良い気はするのだが...
いつまで経っても、「ソフトウェア開発」に関する「情報」は整備されないままといった感じは否めないのよね...
今日も今日とて、不毛な時間を費やすことになってしまうわけですな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
