Created
September 8, 2023 06:00
-
-
Save j416dy/4f54335bf20bc7b2b3d149d721f59409 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| CONNECTED(00000003) | |
| --- | |
| Certificate chain | |
| 0 s:CN = koukoku.shadan.open.ad.jp | |
| i:C = US, O = Let's Encrypt, CN = R3 | |
| 1 s:C = US, O = Let's Encrypt, CN = R3 | |
| i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 | |
| --- | |
| Server certificate | |
| -----BEGIN CERTIFICATE----- | |
| MIIFHTCCBAWgAwIBAgISAzUhRkrknor3ol5B44s9aQ16MA0GCSqGSIb3DQEBCwUA | |
| MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD | |
| EwJSMzAeFw0yMzA5MDYwMjExNDFaFw0yMzEyMDUwMjExNDBaMCQxIjAgBgNVBAMT | |
| GWtvdWtva3Uuc2hhZGFuLm9wZW4uYWQuanAwggEiMA0GCSqGSIb3DQEBAQUAA4IB | |
| DwAwggEKAoIBAQC6kfQYdhh1dc27kFvnGs9QVzoDQwHWssdULYdmQ9EpTVa8USjp | |
| SqJr9er2cUTsY1mXnMea860YCpSy6OIg49iR8GLdKGQDJdL63UwFUxhf6Dao8lzg | |
| oIL0XO4ixXFnzhb9jQAS9Imz24Qb/TpQnXlQXDnQazkchuV0BmpRdaqi53ZGa/Oh | |
| M+0/Rq+CxmEI5MkkWlbjRls6AttewA6IaW1sJEz033Ni0wHWrPmofeUxp970aaP6 | |
| UPY7GrlpQjC8FgwEou4fRK6n3SHnPhOwnVSvo/V/QQuJpnkqeTM35DjVl1QHWYSg | |
| L6CeOyHtbaXqxL6FxKTB6nWHaUxM5414qsglAgMBAAGjggI5MIICNTAOBgNVHQ8B | |
| Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB | |
| /wQCMAAwHQYDVR0OBBYEFK/eBpftmzk/tkvHJdRvpeIXNZZwMB8GA1UdIwQYMBaA | |
| FBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEFBQcw | |
| AYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8vcjMu | |
| aS5sZW5jci5vcmcvMEEGA1UdEQQ6MDiCGyoua291a29rdS5zaGFkYW4ub3Blbi5h | |
| ZC5qcIIZa291a29rdS5zaGFkYW4ub3Blbi5hZC5qcDATBgNVHSAEDDAKMAgGBmeB | |
| DAECATCCAQUGCisGAQQB1nkCBAIEgfYEgfMA8QB3AHoyjFTYty22IOo44FIe6YQW | |
| cDIThU070ivBOlejUutSAAABimh5ZxkAAAQDAEgwRgIhALPI+efjp5aKiay9DXUA | |
| B4DK24AsWLa999PCSRJsQ5JJAiEA0p04mRvumhgc0OzbWO/A9NvAOCKQC7GKFh+D | |
| EReIa4wAdgC3Pvsk35xNunXyOcW6WPRsXfxCz3qfNcSeHQmBJe20mQAAAYpoeWcO | |
| AAAEAwBHMEUCIG/SBFRWFdfdL0Pzsjs318vQqkoyDvysovPOIApVdo+VAiEAnZC9 | |
| b3RxLwAwV0nktaS+4U3JFqUon4Z8Yu7ynHbDuRIwDQYJKoZIhvcNAQELBQADggEB | |
| AC07jNIDCrAfMn/ZqNF3/Q25KzuV2711R6fA4OkVXiWzj0ojsQwOnasWJyL1FME3 | |
| /g3ELVfvxYTEZDF2xkKeak1xekpku5eJRpj/XSSYFOPVwDvyYBeDF09zu8KM26fB | |
| Ss/LTNLhE7B2+4Vzv+Fn+fsI8SZaG8h5X+fqrNBCEbu89YeMI3Hln9QznZjqaQHp | |
| xelUstypQ/ELHQt9P6Os0qc8cLdSeWJq9zj/Qqtc8ie0c1c0Ndb7+HYnQAxxCI24 | |
| Qq9lIylpmBnIuHY0YhmnDKUxb9RQ8Zqpfn8SLJjp6aQtnZMMjXwulvQBgmY/00OD | |
| 4HSlPFLtIwhtEElYrjLNURo= | |
| -----END CERTIFICATE----- | |
| subject=CN = koukoku.shadan.open.ad.jp | |
| issuer=C = US, O = Let's Encrypt, CN = R3 | |
| --- | |
| No client certificate CA names sent | |
| Peer signing digest: SHA256 | |
| Peer signature type: RSA-PSS | |
| Server Temp Key: X25519, 253 bits | |
| --- | |
| SSL handshake has read 3164 bytes and written 381 bytes | |
| Verification: OK | |
| --- | |
| New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256 | |
| Server public key is 2048 bit | |
| Secure Renegotiation IS NOT supported | |
| Compression: NONE | |
| Expansion: NONE | |
| No ALPN negotiated | |
| Early data was not sent | |
| Verify return code: 0 (ok) | |
| --- | |
| [0m | |
| ■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ | |
| ■□ You must use UTF-8 Encoding to view this page ■□ | |
| ■□ ■□ | |
| ■□ 一般社団法人サイバー技術・インターネット自由研究会 ■□ | |
| ■□ ■□ | |
| ■□ インターネット公告システム ホームページへようこそ！■□ | |
| ■□ W e l c o m e ! ! ■□ | |
| ■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ | |
| 最終更新日時 2023/09/08 (金) 07:57 (JST) | |
| - TELNET over TLS/SSL (TCP Port 992) secure edition - | |
| あなたは １２４９６５ 番目のアクセス人間です！！ | |
| Your internet human number is #124965 !! | |
| Ｓｏｒｒｙ， Ｊａｐａｎｅｓｅ ｌａｎｇｕａｇｅ ｏｎｌｙ． | |
| 次のとおり電子公告をします。 | |
| ★ 第Ｘ期 決算公告 ★ | |
| 202X 年 X 月 X 日 東京都新宿区○○ | |
| 一般社団法人サイバー技術・インターネット自由研究会 | |
| 代表理事 ○○ ○○ | |
| 貸借対照表の要旨 202X 年 X 月 X 日 現在 (単位: 円) | |
| 資産の部 (科目、金額) | 負債の部 | |
| 流動資産 XXXX 円 | 流動負債 XXXX 円 | |
| 固定資産 XXXX 円 | 固定負債 XXXX 円 | |
| 資産合計 XXXX 円 | 負債合計 XXXX 円 | |
| ------------------- | |
| | 純資産の部 | |
| | 社員資本 XXXX 円 | |
| | 利益剰余金 XXX 円 | |
| | 純資産合計 XXX 円 | |
| ----------------------+------------------------ | |
| 資産合計 XXXX 円 | 負債・純資産合計 XXX 円 | |
| 損益計算書の要旨 202X 年 X 月 X 日 ～ 202X 年 X 月 X 日 | |
| 科目 | 金額 | |
| 売上高 | XXXX 円 | |
| 販売費・一般管理費 | XXXX 円 | |
| 経常利益 | XXXX 円 | |
| 法人税・住民税・事業税| XXXX 円 | |
| 当期純利益 | XXXX 円 | |
| (単位: 円) | |
| 以上 | |
| ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆ | |
| ☆ お 楽 し み 機 能 ☆ | |
| ☆ この TELNET 電子公告システムは、より発展的な機能として、 ☆ | |
| ☆ TELNET トーク放話機能が付いています － TELNET 画面に向かい ☆ | |
| ☆ メッセージ (日本語文字を含む必要あり) を放話し Enter を押す☆ | |
| ☆ とチャットが放話できます。同じ TELNET 画面を同時に開いてい ☆ | |
| ☆ る他のユーザーにも表示されますので、会話が可能です。荒らし ☆ | |
| ☆ 防止のため、投稿元のホスト名が一部伏せ字で表示されます。 ☆ | |
| ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆ | |
| ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ | |
| ★ お 楽 し み 加 重 ヒ ン ト ( 耳 よ り 情 報 館 ) ★ | |
| ★ 「nobody」と入力すると、本公告システムにはもはや公告が表示 ★ | |
| ★ されなくなり、チャット専用モードになります。これはいけませ ★ | |
| ★ んから改心し「body」と入力すると公告が無事復活いたします。 ★ | |
| ★ 尚「notalk」と入力するとﾁｬｯﾄが消えて公告閲覧に没頭できます｡★ | |
| ★ これは寂しいですから「talk」と入れると再今ﾁｬｯﾄが復活します｡★ | |
| ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ | |
| ★ チャット放話機能における自由演説機能 (2023-09-07) | |
| 公告本文には流れるような文章が一方的にきらびやかに表示され | |
| るというのに、閲覧者が投稿するチャット放話は軽薄な文字でしか | |
| 表示を成し得ないことについて、あたかも公告主が博大で接続者が | |
| これに劣るような印象を植え付け、不平等・不均衡である旨の意見 | |
| が寄せられた。 | |
| 確かにその通りなので、これからは、チャット放話機能において、 | |
| 公告本文と同様の風体で対等に演説をしたい者は、誰でも、 | |
| 「http://」または「https://」で始まる URL を半角でチャット | |
| 機能に打込すれば良いことになった。 | |
| そうすれば、その URL から取得されるテキストファイルの内容 | |
| が演説として放話される。 | |
| ただし、以下の制限があるので、是非注意しなければならない。 | |
| (1) 日本語で、Shift_JIS で表現可能な文字のみで、 | |
| おおむね 1 回 30 行が限度とされる。 | |
| (2) 指定する URL には QueryString ('?' 文字) が含まれては | |
| ならない。また、HTTP/HTTPS GET でアクセス可能でなけ | |
| ればならない。 | |
| (3) URL においては Content-Type が「text/plain」で応答せ | |
| ねばならない。text/html は拒否するやうになってある。 | |
| (4) 1 名が何度も沢山の演説をすることはできない。 | |
| 又一度行なった演説と同内容を何度も演説してはならない。 | |
| (5) 演説は、公告の本文と同様の文体で、できるだけ正確な表現 | |
| に努めなければならない。 | |
| (6) 演説 URL 打込に際して第三者の権利を侵害することは絶対 | |
| にこれを禁ずる。 | |
| (7) よく譲り合って演説すべし。 | |
| すでに誰かが演説している合間に重ねて演説をすることは | |
| できない。 | |
| ★ TELNETS (TELNET over SSL/TLS) 版提供開始 | |
| 「SSL で暗号化されていない TELNET はセキュリティ上危険な為 | |
| 絶対に避けなければならぬ。」旨の近視眼的クレムが相次いだこと | |
| から、この度本システムでは TELNETS (TELNET over TLS/SSL) 版 | |
| をも実装した。 | |
| 一般的端末から以下のやうに投入すれば、TELNETS でアクセス可 | |
| 能である。証明書も正規のものを利用しているから今後厳格な論者 | |
| に出合っても金甌無欠といえる。 | |
| $ openssl s_client -connect koukoku.shadan.open.ad.jp:992 | |
| ★ 注記１ | |
| 当法人においては、未だ第一回目の決算を奉迎していない。 | |
| 上記の決算公告は、本公告システムの瀬踏みのためのもの | |
| なのである。 | |
| ★ 注記２ 法務局登記事項 本法人の目的 | |
| この法人は、インターネットとそれを支えるサイバー技術 | |
| の進化を促進するため、自由な発想の奨励と実験の場の提 | |
| 供、多様な個性を持つ研究者やグループの育成、そして多 | |
| 種多様なソフトウェアやインターネットサービスの開発等 | |
| への支援を通じ、次世代のサイバー技術の発展とその応用 | |
| 、及び持続可能な経済活動と人材育成の両立を実現し、よ | |
| り実践で開かれた実験基盤の研究・開発・運用を推進し、 | |
| 世界に貢献する人材の育成とインターネット・サイバーセ | |
| キュリティの技術の発展に寄与することを目的とともに、 | |
| その目的に資するため、次の事業を行う。 | |
| １ インターネット・サイバーセキュリティの研究調査事 | |
| 業 | |
| ２ 人材育成・教育事業 | |
| ３ 電気通信事業 | |
| ４ 認証基盤事業 | |
| ５ その他この法人の目的を達成するために必要な事業 | |
| ★ 注記３ | |
| 「公告においてＴｅｌｎｅｔ方式を利用する必要がある具体的理由 | |
| の申出書」 令和５年５月２２日付 | |
| 法務省 東京法務局 御中 | |
| 当法人が、電子公告の方法として、「http://」で始まるアドレ | |
| スではなく「telnet://」で始まるアドレスを記載する必要がある | |
| 理由を、今ここで改めて説明いたします。 | |
| そもそも、「インターネット」というものは、今から 54 年前の | |
| 1969 年にアメリカ合衆国で開始されたコンピュータ・ネットワー | |
| クです [根拠資料 1]。それから長い間、インターネット上では、 | |
| サーバーにアクセスする際には、伝統的な TELNET またはこれと | |
| 同様のプロトコルが使用されてきました。これらは、文字を中心と | |
| したプロトコルです。TELNET は、すでに安定し、これ以上変化の | |
| 余地がない、この上なく安定した優良な通信方式です。その性能は | |
| 、HTTP と比較にならないほど高く、安定しています。TELNET は、 | |
| インターネットの基礎的通信の仕組みを用いて文字を伝送し表示す | |
| るものですので、今後、百年間程度は利用できると想定されます。 | |
| TELNET は、長期間活動する予定の法人の電子公告等に向いています。 | |
| このような伝統のあるサーバー・アクセス方式である TELNET | |
| と比較しますと、HTTP というものが発明されたのは、ごく最近の | |
| 1991 年のことです [根拠資料 2]。HTTP は、未だ、発展途上の不 | |
| 安定なプロトコルです。HTTP は、文字だけでなく、ハイパーリン | |
| クと呼ばれるページ間のダイナミック・ジャンプの仕組みや、画像 | |
| やマーキー、MIDI 音楽、ショック・ウェーブ、リアル・プレイヤ | |
| ー、フラッシュ・アニメ、アクセス・カウンター等を貼り付けるこ | |
| とができるビジュアル性を実現した点で画期的でした。このように | |
| 、HTTP は、刹那的で刺激的な法人の営業サイト等の公開に向いて | |
| いますが、その反面、後述するように、毎月のように、次々に仕様 | |
| が変更され、ある時閲覧できていたページが、しばらくすると見ら | |
| れなくなってしまいます。これでは、電子公告のような重要な情報 | |
| を安定して提供する際の閲覧者による閲覧を妨げることになってし | |
| まいます。 | |
| そこで、当法人は、流行の HTTP ではなく、伝統的な TELNET を | |
| 用いて、電子公告用のインターネットサーバーを長期間安定的に運 | |
| 営する予定です。TELNET を用いて電子公告サーバーを運営する利 | |
| 点をまとめると、次のとおりです。 | |
| (1) TELNET のほうが、HTTP よりも、通信量がかなり削減されま | |
| す。90% 以上の削減が可能だと思われます。サーバーの通信コスト | |
| が、大幅に軽減されます。すなわち、月額のサーバー維持コスト | |
| のうち、通信費用が、HTTP と比較して、10 分の 1 以下になると | |
| いうことです。 | |
| (2) HTTP のサーバーは、その性質上、HTTP プロトコルという複 | |
| 雑な制御信号を解釈する必要があり、脆弱性 (セキュリティ・ホー | |
| ル) が多く発生します。企業や官庁のシステムが、セキュリティ・ | |
| ホールによって侵入され、改ざんや情報漏えいが発生するニュース | |
| が多発していますが、それと同様のリスクが発生します。他方、 | |
| TELNET において電子公告ページを一方的に配信するだけのサーバ | |
| ーは、複雑な制御が全く存在しないので、原理上、脆弱性が発生す | |
| るリスクが皆無であり、サイバー攻撃によって外国人攻撃者に侵入 | |
| されるおそれがほぼ絶対にありません (わずかな例外としては、 | |
| TCP/IP スタックと呼ばれるプロトコルモジュールに脆弱性があっ | |
| た場合の侵入リスクがありますが、この脆弱性が存在し、かつ影響 | |
| するリスクは、HTTP のサーバーに存在する潜在的可能性がある脆 | |
| 弱性によるそれと比較して数百分の 1 以下であると見積もられま | |
| す)。したがって、サイバーセキュリティ上、HTTP を使用するこ | |
| となく、TELNET を使用することは、大きな利点があります。 | |
| (3) HTTP のサーバーにアクセスするための「Web ブラウザ」や | |
| Web のプロトコルや動作は、誠に残念なことに、事実上、日本人の | |
| 意思とは無関係に、インターネット上で力を有する外国人たちによ | |
| って、非民主的に決定されます。たとえば、「グーグル クロム」 | |
| や「マイクロソフト エッジ ブラウザ」等の Web ブラウザは、ほ | |
| とんど外国人によって開発され、外国人によって動作がいつでも | |
| 変更されます。そのため、HTTP を用いて電子公告を公開している | |
| と、外国人の意志ひとつで、突然日本人の電子公告を閲覧者が事 | |
| 実上閲覧できない状態になってしまうリスクがあります。他方、 | |
| TELNET プロトコルは、接続先のインターネットサーバーに閲覧者 | |
| がアクセスするとサーバーから送付されてくる文字を単に画面上 | |
| に表示するだけの、これ以上に単純化することができない程度に | |
| 最も基礎的なプロトコルであることから、外国人の意志によって | |
| も、決してその挙動が変更されない安定性があります。 | |
| (4) HTTP で電子公告を公開すると、その電子公告にアクセス | |
| しようとするユーザーのブラウザの履歴情報が、ブラウザを開発 | |
| している力のある外国人やその企業に自動的に送付されることが | |
| あります。これは、セーフティ・ブラウジング等の名目によって | |
| 行なわれますが、その結果、どの法人の電子公告に日本人のうち | |
| 誰がいつアクセスをしたのかを、外国人が簡単に追跡することが | |
| でき、外国人は、これに基づいて日本人と利益を相反させたマー | |
| ケティング等の活動を日本人を対象として行なうことが容易とな | |
| ります。他方、TELNET の場合、TELNET のブラウザ (TELNET クラ | |
| イアントと呼びます) には、そのようなアクセス履歴送信機能が | |
| 一切含まれていないため、外国人に日本人の閲覧情報が送付され | |
| 漏えいするリスクがまったくなく、電子公告にアクセスをする閲 | |
| 覧者の権利保護に資することができます。 | |
| 「根拠資料の提出」 | |
| [1]「総務省 通信白書」 | |
| https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h08 | |
| /html/h08a03010101.html | |
| [2] 「総務省 情報通信審議会 情報通信政策部会 ドメイン名政 | |
| 策委員会資料」 | |
| https://www.soumu.go.jp/main_content/000327054.pdf | |
| 上記の理由により、当法人は、「telnet://」という文字で始ま | |
| るアドレスを用いて電子公告を行なうことに意思決定をしたので | |
| 本書のとおり申し出をします。 | |
| 以上 | |
| ★ 補足１ - 2023/09/01 (月) 追記 | |
| 「TELNET サーバーにも脆弱性が存在し得るのであつて、必ずしも | |
| HTTP サーバーよりも安全とは言えない。」との指摘があつた。確 | |
| かに、対話型の TELNET サーバーを完全なる実装で実現する場合 | |
| にあつては、制御コード等の解釈の瑕疵により、バッファオーバー | |
| フローの不具合を混在させるおそれは、低いとはいえない。しかし | |
| ながら、本 TELNET 型ホーム・ページ・システムのように、単に | |
| 一方的にコンテンツを配信するために文字列を TCP を用いてスト | |
| リームとして送付するだけであれば、クライアントから送付され | |
| てくる TCP 上のデータは何ら読み取らず、又、解釈をする機会も | |
| ないのである。この場合、OS の有する TCP スタックに脆弱性が | |
| 存在する場合をのぞき、機密性・完全性を損なう脆弱性が発生する | |
| 余地はないと考えられる。 | |
| 以上 | |
| ★ 補足２ - 2023/09/05 (火) 14:20 追記 | |
| 上述の理由 (2) に関して、次の技術的論難があつた。すなわち、 | |
| 「TELNET 通信は、いわゆるプレエーン・テキストであつて、通信 | |
| 経路が暗号化されていないから、悪意のあるインターネット上の攻 | |
| 撃者により、通信内容が改ざんされる脆弱性がなお存在し、サーバ | |
| ー証明書によるサーバー認証とその後の暗号化がなされる HTTPS | |
| よりも脆弱と言い得るのではないか。」というものである。 | |
| しかしながら、上記指摘は妥当ではない。まず、これは、形式的 | |
| 言い逃れに聞こえるかもしれないが、上述理由 (2) は、あくまで | |
| も、HTTP (HTTPS を含む。) を用いた情報発信側のサーバーには高 | |
| 度複雑なウェッブ・サーバーのプログラムに起因する脆弱性が存在 | |
| し得ることにより、これを端緒として侵入を小成する電算攻撃者に | |
| よる書き換えのおそれがあることと対象的に、単純明白な TELNET | |
| によるストリーム文字列発信の機構においては、そのおそれが、 | |
| OS のプロトコル・スタックに起因するバグの可能性をのぞいて、 | |
| ほとんど皆無であるということを述べたものに過ぎない。上記指摘 | |
| は、通信経路上の中間者攻撃による情報書換えの可能性を指摘する | |
| ものであり、上述理由 (2) に対応するものではなく、論難として | |
| 成立しない。 | |
| 上記のように、理由 (2) に対する指摘については、これにより | |
| 一応反論を成すことができたと考えるが、われわれはここで立ち止 | |
| まってはならない。このことは、より本質的に、真に HTTPS の側 | |
| が TELNET よりも中間者攻撃に対して安全であるのかという点を考 | |
| えるという、おそれおおい深淵の洞窟に、勇気をもって、進入して | |
| いくことの折角の契機となる。 | |
| 確かに、インターネットの初学者にとっては、「TLS により定評 | |
| のある認証機関 (CA) のサーバー証明書によって構成される HTTPS | |
| サーバーを用いた情報発信により、インターネット経路上における | |
| 中間者攻撃による書き換えの可能性を防止することができ、他方で | |
| 、いわゆるプレエーン・テキストを用いた TELNET 通信は、インタ | |
| ーネット経路上における同攻撃の可能性を防止できないから、 | |
| HTTPS は相当安全であり、TELNET は相当危険である。」という風 | |
| なステレオ・タイプともいえる誤解・過信が蔓延していることも、 | |
| 確かなことである。しかし、このような考え方は、インターネット | |
| 学の実用的ハウ・ツー部分のみを表皮的に理解してセキュリティを | |
| 語るような技術者においては広くみられるものの、実際には、 | |
| HTTPS とサーバー証明書の提供する安全性に対する過信に過ぎず、 | |
| 極めて危険である。 | |
| インターネットがいよいよ重大な日本社会におけるインフラ・ス | |
| トラクチャとなりつつある今、誠に重要なことであるから、よりこ | |
| の過信の危険性について、詳しく検討をする。すなわち、われわれ | |
| の議論の焦点は、今、「HTTPS を用いることで、定評のある認証機 | |
| 関 (CA) のサーバー証明書によって構成されるウェッブ・サーバー | |
| による情報発信内容が中間者攻撃により改ざんされるおそれがなく | |
| なるのか否か」という点を、セキュリティ上、じゅうぶんに究理す | |
| るという点にある。 | |
| まず、TLS によるサーバー証明書や暗号化が用いられる HTTPS | |
| であろうと、プレエーン・テキストを用いる HTTP であろうと、 | |
| TELNET であろうと、インターネット上における情報流通経路上の | |
| 書き換えは、中間者攻撃によってなされることは、同様である。そ | |
| して、インターネット上の経路は、BGP (中継儀礼) による網の目 | |
| 状の動的なルーチングによって制御されるので、中間攻撃者は、通 | |
| 信内容を確実に中間者攻撃するためには、ルーチングに影響を及ぼ | |
| す必要がある。これは、BGP ハイジャックと呼ばれる。BGP ハイジ | |
| ャックは、インターネット上の経路に接触できる者であれば、誰で | |
| も可能である。インターネットは、BGP の水準においては、ほとん | |
| ど紳士協定的信用モデルで成り立っており、誰でも、虚偽の経路情 | |
| 報を BGP に流し、また、これに先だって、経路宣言を、IRR と呼 | |
| ばれる、いわば法務局の登記所のような場所に進んで書き立てるこ | |
| とができる。われわれが驚くべきことは、この際に、IP アドレス | |
| の真の持主以外がそのような経路を流通させ、また IRR への登録 | |
| を禁止する、全世界的に普遍的かつ実効的な具体的認証機構をも、 | |
| 存在していない、という事実である。これについては、セキュリテ | |
| ィ上の問題は長年指摘され続けていて、部分的にはこれに対応する | |
| 試みがみられるが、未だ共通的な仕組みとはなっていないのである | |
| 。さて、インターネット上では、BGP ハイジャックにより、誰でも | |
| 中間攻撃者になることができるが、このことは、誰でも、ターゲッ | |
| トのコンテンツ・サーバーに対して、(a) DNS 権威サーバーの静的 | |
| IP アドレスを奪取する、(b) HTTPS/HTTP/TELNET の情報発信サー | |
| バーの IP アドレスそのものを奪取する、の 2 つが可能であるこ | |
| とを意味する。(a) を実行すれば、たとえばこの koukoku.shadan. | |
| open.ad.jp という FQDN の A レコード (103.41.63.2) を、 | |
| 贋作のウェッブ・サーバーを稼働させた、異なる IP アドレスに差 | |
| 替えることが可能である。(b) を実行すれば、たとえばこの kouk- | |
| oku.shadan.open.ad.jp サーバーの IP アドレス 103.41.63.2 | |
| を、そのまま乗っ取ることができる。そして、われわれインターネ | |
| ット市民が特に刮目しなければならない点は、(a), (b) とも、い | |
| ずれも、DNS サーバーにも、コンテンツ・サーバーにも、一切侵入 | |
| する等の具体的接触を経ることなく、インターネット経路上のいず | |
| れの場所からでも (日本国内においても、海外においても、全世界 | |
| 中インターネットさえ届けばどこからでも) 容易に成し得るという | |
| ことにある。すなわち、BGP ハイジャック攻撃は、極めて容易な攻 | |
| 撃手法であるにもかかわらず、攻撃対象となるサーバーにいかに厳 | |
| 重なセキュリティ対策や監視を施したとしても、それらによって全 | |
| く予防されず、ほとんど確実に成功させることができてしまう攻撃 | |
| 手法である。 | |
| そうして、攻撃者が BGP ハイジャック攻撃手法を用いても、実 | |
| 際には、なかなか気付かれないものである。数十時間または数日間 | |
| 後に、ようやく気付かれる。BGP ハイジャックにおいては、原理上 | |
| は IP アドレス 1 個単位で可能であるが、インターネット上の慣 | |
| 習に基づき、IP アドレス 256 個単位で行なわれる。よって、被害 | |
| ホスト 1 台のほか、最大 255 台が巻き添えを受ける。そのため、 | |
| 比較的早期に感づかれると思われるかも知れないが、実際には、長 | |
| 期間気付かれず、放置される。実例をみてみよう。2022 年 8 月 | |
| 17 日に実際に発生した著名な BGP ハイジャック攻撃は、仮想通貨 | |
| システムの通信をハイジャックするためのものであったが、これは | |
| 、AWS の EC2 の 1 つのホスト (1 つの IP アドレス。具体的には | |
| 、44.235.216.69) を対象としたものであった。攻撃者 | |
| (QuickHostUk: AS209243) は、IRR に贋作の経路を宣言し (2022 年 | |
| 8 月 16 日 17 時 21 分 UTC)、26 時間以上経過してから、悠々と | |
| その贋作経路と一致する実際の BGP 広報を開始し、BGP ハイジャ | |
| ックを開始した (2022 年 8 月 17 日 19 時 39 分 UTC)。IP アド | |
| レス群「44.235.216.0/24」 (256 個の IP アドレス) をインター | |
| ネット上で完全に乗っ取られた AWS 社がこれに気付き、対処 (同 | |
| 一のサブネット長での対抗的な広報) を行なったのは、攻撃者の | |
| IRR 上の贋作経路の宣言からなんと 29 時間も、そして、実際の | |
| BGP ハイジャック開始からなんと 3 時間も経過した、2022 年 8 | |
| 月 17 日 23 時 08 分 UTC のことであった。世界最大級のネット | |
| ワーク運営事業者である AWS 社であっても自己の所有する IP ア | |
| ドレスの範囲における贋作 BGP ルーチングを気にかけていなかっ | |
| たことから、他の一般的・健全なネットワーク運営者も、まともに | |
| BGP ルーチングの監視をしていないと推測される | |
| (https://www.coinbase.com/blog/celer-bridge-incident-analysis)。 | |
| さて、上記のとおり (a) DNS、(b) サーバー本体、のいずれか一 | |
| 方の IP アドレスに対する BGP ハイジャックを実施しさえすれば | |
| (これが容易に何人にも可能であることは、前述した。)、たとえ | |
| HTTPS サーバー本体をその管理者がいかに普段からセキュリティの | |
| 意識高く TLS を用いて保護をしようとしていても、これを、まっ | |
| たく無力化することができ、中間者攻撃による内容の改ざんが容易 | |
| に可能となるのである。なぜならば、中間攻撃者が立ち上げる贋作 | |
| のウェッブ・サーバーは、HTTPS において、自己署名証明書 (いわ | |
| ゆる、オレオレ証明書) ではなく、真正な、定評のある認証機関 | |
| (CA) のサーバー証明書を取得し、これをアクセス者に対して掲げ | |
| ることができるようになるためである。その理由は、真正な、定評 | |
| のある認証機関 (CA) が証明書の申込みに対して申込者が当該ドメ | |
| イン名の権原者であるか否かの判定にも、インターネットが使われ | |
| るためである。この判定は、現代においては、大量の HTTPS サー | |
| バー証明書を日々無数に発行するという需要を達成するため、完全 | |
| に機械的に行なわれている。具体的な判定手法としては、DNS で指 | |
| し示されている A レコード (ウェッブ・サーバーである) または | |
| MX レコード (メールサーバーである) に対して、認証文字列を通 | |
| 知し、この認証文字列を申込者が受領できるか否かを試験する方法 | |
| でなされている。 | |
| さて、前述のとおり、攻撃者はすでに (a) または (b) の IP ア | |
| ドレスをハイジャックしているから、この認証文字列を受け取るこ | |
| とが可能である。これにより、攻撃者は、ターゲットの HTTPS サ | |
| ーバーのドメイン名を実際に指し示す正規の TLS 証明書を取得す | |
| ることができ、これを、贋作の HTTPS サーバーで提示することに | |
| より、それ以降アクセスしようとするすべてのアクセス人間に、 | |
| 改ざんされたコンテンツを提示することができるのである。Let's | |
| Encrypt の証明書を受領しようとする際や、有償の CA から証明 | |
| 書を購入しようとする際の手続を、よく思い出してほしい。いずれ | |
| も証明書発行に前置する本人確認をインターネット上のプレエーン | |
| ・テキストの通信に頼ってきたではないか。言い換えれば、これは | |
| 、金庫の上に、鍵が置いてあるのと同様の状態である。これが現在 | |
| の SSL 証明書の、そして、インターネットのセキュリティ保護技 | |
| 術の限界である。セキュリティとインターネットについて十分に | |
| 探求している研究者、技術者たちは、この不完全性を皆認識して | |
| いても、目を瞑っている。インターネット初学者と大衆的ユーザー | |
| たちだけが、この不完全性を全然知らずに、HTTPS のセキュリティ | |
| を過信し、「HTTPS は中間者攻撃による改ざんが不能で、安全であ | |
| る」と誤解をしているのである。 | |
| 上記のとおり、インターネット上における BGP ハイジャックは | |
| 何人でも容易に実行ができ、これにより、たとえコンテンツ・サー | |
| バーが HTTPS であっても、これを改ざんしたコンテンツを提示す | |
| る贋作サーバーを立ち上げて、正規の証明書を取得したウェッブ・ | |
| ページを表示する (ユーザーのブラウザには証明書エラーの警告は | |
| 何ら表示されず、改ざんに気付くことは不可能である) ことは、容 | |
| 易なことである。したがって、経路上の攻撃手法が利用できる攻撃 | |
| 者が存在する限り、HTTPS と TELNET とを比較して、HTTPS は改ざ | |
| んが不可能であるから TELNET と比較して安全であるという主張は | |
| 、誤りである。せいぜい上記のように攻撃に若干の手間がかかると | |
| いうものであり、HTTPS と TELNET のいずれも通信経路上で内容が | |
| 改ざんされ得る点においては、程度問題に過ぎない。 | |
| むしろ、いざ経路上でコンテンツの内容が改ざんされた場合に発 | |
| 生する被害を比較すべきである。HTTPS の場合、そのコンテンツ本 | |
| 体は HTML であり、JavaScript 等のさまざまな仕組みを含んでい | |
| る。毎月のように発見されるブラウザの脆弱性を、わずか 1 つで | |
| も突くことで、容易に、ブラウザのセキュリティ・サンドボックス | |
| 障壁を突破して、ユーザーホストそのものに影響を与えることがで | |
| きる機密性・完全性上への攻撃が容易となるではないか。他方で、 | |
| TELNET のプレエーン・テキストはおおいに安全である。その仕様 | |
| 上、表現できるものがテキスト文字しかなく、JavaScript を実行 | |
| したり、ロードプログラムに脆弱性があることを悪用してウェッブ | |
| ・フォント等を読み込ませて任意コード実行を引き起こしたりする | |
| ことは不可能である。 | |
| よって、HTTPS と TELNET を比較すると、インターネット経路上 | |
| の中間者攻撃手法がひとたびなされれば、改ざんの発生のおそれは | |
| いずれも同等であり、この 2 者は安全性的に等価である。むしろ | |
| コンテンツ内容の表現がプレエーン・テキストに拘束される | |
| TELNET のほうが、おおいに、セキュリティ上安全であるといえよ | |
| う。インターネットに関するセキュリティについて考えるときは、 | |
| その表皮部分に終始せずに、インターネットの本質的構成要素の仕 | |
| 組みも含めてインターネットをじゅうぶんに理解することにより、 | |
| インターネット初学者を脱することができ、いよいよ本格的なイン | |
| ターネット構築者の世界に、入って行くことになるのである。そし | |
| て、そのような考え方を身に付けることは、そうでない大多数の道 | |
| 具的インターネット受益者と比較して、技術者として、豊かな人生 | |
| を切り拓くことができ、有利である。 | |
| 以上 | |
| ★ 補足３ - 2023/09/05 (火) 19:15 追記 | |
| 補足２について、先刻、「中間者攻撃による内容改ざんを想定し | |
| た場合、HTTP/HTTPS であっても、コンテンツ内容をプレーン・ | |
| テキストにすれば、JavaScript 等の実行は不能となり、ブラウザ | |
| の脆弱性を発動することが不可能となるから安全であり、あえて | |
| TELNET を利用する必要はないのではないか。」旨の異論が寄せら | |
| れた。 | |
| しかし、たとえ正規の HTTP/HTTPS サーバーを公開する管理者が | |
| コンテンツをプレーン・テキストのみで公開していたとしても、 | |
| 中間攻撃者は、その URL 内容をまったく自由に任意の HTML に | |
| 差替えることができるから、正規のサイトとして信用して接続した | |
| アクセス人間のブラウザ上においては、結局、脆弱性が突き通って | |
| しまい、攻撃に成功してしまう。ブラウザは Content-Type HTTP | |
| ヘッダの値をみて HTTPS サーバーから返されるコンテンツの種別 | |
| を判定する。たとえ、正常時は text/plain としてコンテンツが応 | |
| 答されていても、攻撃者は、中間攻撃によりいつでも当該ヘッダを | |
| text/html 等に書き換えることができる。すなわち、中間者攻撃が | |
| 可能である以上、攻撃者はブラウザの挙動を完全に自由にコントロ | |
| ールして、脆弱性を発動できてしまうのである。 | |
| 上記の異論は、この点を看過している。 | |
| 他方、TELNET を使用する限りにおいては、もとよりこのような | |
| 薄氷な点がないから、安全である。このように、TELNET のほうが、 | |
| HTTPS よりも、セキュリティ上、すぐれて安全である。 | |
| 以上 | |
| ★ 補足４ - 2023/09/05 (火) 20:45 追記 | |
| 先刻、「Shift_JIS という文字コードは、もはや流行ではないか | |
| ら、使うべきできない。UTF-8 を使用するべきである。」旨の異論 | |
| が寄せられた。 | |
| しかしながら、行政機関や電話会社などで現役の、1990 年代に | |
| 作られた端末群から安全にアクセスするためには、これらの古い端 | |
| 末のサポートしている文字コードでコンテンツが読める必要がある | |
| 。これらの古い端末は Shift_JIS や EUC-JP 等の文字コードしか | |
| サポートしておらず、UTF-8 は読めないのである。他方で、最新の | |
| 端末であっても、わずかな努力で少し設定を行なえば Shift_JIS | |
| を読める。加えて、Windows 10 等の現役の Windows 端末の | |
| telnet クライアントは日本語環境では Shift_JIS が標準設定であ | |
| るから、ユーザーの利便も考慮して、やはり、Shift_JIS を使用す | |
| ることが合理的である。 | |
| いやしくもインターネットを公的目的で取扱いする者は、公共的 | |
| 利益の観点から、自らの組織の環境のみを想定した狭隘な観点では | |
| なく、影響を受け得る幅広い環境に存するアクセス人間たちのこと | |
| を考えて、さまざまな点を商量して物事を決めるべきである。 | |
| 以上 | |
| ★ 補足５ - 2023/09/05 (火) 21:13 追記 | |
| 先刻、「ホストの遠隔ログイン目的に作られた TELNET などでは | |
| なく、WWW の元祖である、本来情報提示目的に適した Gopher プロ | |
| トコルを、つとめて利用すべきである。」旨の異論が寄せられた。 | |
| しかしながら、Gopher は日本語等のマルチバイト文字に対応し | |
| ていないので、日本語における電子公告システムでの利用に不向き | |
| である。 | |
| そして、Gopher を用いる場合、我が国のより重大なセキュリテ | |
| ィ (安全保障) 問題が生ずるのである。すなわち、Gopher の場合 | |
| 、否応にも英文字 (ASCII 文字) を用いて情報発信することを強い | |
| られることになるが、その場合、上記のような外国人インターネッ | |
| ト列強関係者からも海山を越えて容易にアクセスが可能となり、 | |
| 上記の「申出書」の (3), (4) のような点について日本人が察知し | |
| ている点が外国人インターネット列強たちに漏れ出でてしまうおそ | |
| れがある。 | |
| このような理由で、われわれ日本人は、Gopher ではなく、 | |
| TELNET を利用し続けるべきである。TELNET で Shift_JIS を利用 | |
| している限り、日本語端末でしか内容が読めないというプロテクシ | |
| ョンが講じられるのであった。 | |
| 以上 | |
| ★ 補足６ - 2023/09/05 (火) 22:20 追記 | |
| 先刻、「此の TELNET 配信サーバーとのパケットをキャプチャし | |
| てみたところ、１文字あたり 1 個の TCP パケットに分割されて送 | |
| 付されてきているから、本来必要なパケット通信量よりも多くのパ | |
| ケット通信量が生じている。複数文字分バッファリングして 1 パ | |
| ケットにまとめるべきである。」旨のクレムがあった。 | |
| このクレムは、確かに技術的には的を得ていが、「複数文字分バ | |
| ッファリングして 1 パケットにまとめるべきである。」という提 | |
| 案は、俗解である。われわれは、あえて 1 文字ずつパケットを送 | |
| 付しているのである。これらのパケット断片化方式をあえて選ん | |
| だ理由として、現代インターネットを取り巻く大いなる秘密が隠さ | |
| れていることに気付いた者は、未だ少ない。本日ここで説明をしよ | |
| う。 | |
| 米 NSA、中国 GFW 管理局に代表される、数多くの外国インター | |
| ネット先進国政府らが設置している国家的インターネット検閲・ | |
| 監視システム群は、インターネット上の経路上でパケットをミラー | |
| リングしてキャプチャし、中身のテキストをひたすら保存し、イン | |
| デクシングし、迅速に検索可能としている。 | |
| ここで、通常の TCP の 1 パケットには 1414 文字から 1460 文 | |
| 字もの連続した TCP データが格納されている。検閲・監視システ | |
| ムは、この 1414 ～ 1460 文字の 1 個の区切り (これを、今ここ | |
| で TCP セグメントと呼ぼう。) をひとまとまりとして、その中身 | |
| を字句分割し、インデクシングするしかない。1 本の TCP ストリ | |
| ームは、前後連結されている TCP セグメントにより構成され、TCP | |
| セグメントのストリーム中からの位置は、TCP SYN, SYN+ACK, ACK | |
| 時にネゴシエーションされた TCP シーケンス番号を起点とした無 | |
| 限に後方に伸びる仮想的な TCP ストリームにおける相対的シーケ | |
| ンス番号によって識別される。ここで、理想的なパケットキャプチ | |
| ャシステムは、キャプチャした各々の TCP パケットにおける分割 | |
| 後の TCP セグメント群を連結して結合するであろう。多くの企業 | |
| に導入されているファイアウォールや IDS というような装置の類 | |
| は、このような TCP セグメント再結合の機能を有している。とこ | |
| ろが、TCP セグメント再結合を実施するには、すべてのパケットが | |
| 流れる監視点において、各々の TCP セッションを、TCP シーケン | |
| ス番号を元にした状態遷移機械を作ってメモリ上で識別せねばなら | |
| ない。そして、メモリ上でセグメントを再結合せねばならない。企 | |
| 業等で導入されている程度の規模の FW や IDS であれば、監視対 | |
| 象はせいぜい社員の通信程度であるから、そのような状態遷移機械 | |
| を動かしてすべての TCP セッションのステートを管理し、セグメ | |
| ント再結合により元のストリームを復元可能である。ところが、 | |
| NSA 等の外国政府の監視用パケットキャプチャシステムがキャプチ | |
| ャするパケットは、IX や海底光ケーブル接続点などにおける、ほ | |
| ぼ全世界のパケットに及ぶので、到底 TCP セッションの状態遷移 | |
| の管理やセグメント再結合を行なう CPU およびメモリリソース的 | |
| 余力がない。そこで、こういった外国政府の監視システム群は、 | |
| TCP セグメント再結合は諦めて、各 TCP セグメントに含まれるペ | |
| イロードの範囲内で、そこに含まれるキーワードや URL、Cookie | |
| 文字列、TLS SNI 文字列等をひたすらインデクシングしているの | |
| である。 | |
| したがって、米 NSA、中国 GFW 管理局に代表される強力な国家 | |
| 的インターネット検閲・監視システム群のキャプチャ・ポイントを | |
| 通り抜けるとき、TCP メッセージの電文が 1 文字ごとに分割して | |
| いれば、これらのキャプチャ・システムにおいては、一体何が書い | |
| てあるのか、さっぱり皆目がつかない状態に陥るのである。たとえ | |
| てみれば、官憲が国際郵便局を監視しているとして、用心深い国際 | |
| 人は、もちろん、ハガキ 1 枚につき 1 文字を書いて数百枚のハガ | |
| キを送付し、数百文字を送付するであろう。このとき、官憲はハガ | |
| キ 1 枚単位でしか意味を理解できず、これをつなぎ合わせたメッ | |
| セージを監視することは不可能になる。これと同じ工夫である。 | |
| このような博大な理由があり、この TELNET ベースのコンテンツ | |
| 配信システムでは、複数文字をまとめて 1 つの TCP セグメントに | |
| して送付することはつとめて避けており、あえて 1 文字ごとに 1 | |
| つの TCP セグメントとして送付しているのである。これによるセ | |
| キュリティ上の効果は高く、TCP パケット数が上回ることによる若 | |
| 干の負荷の増大を上回る利益があることを、忘れてはならないであ | |
| ろう。 | |
| 以上 | |
| ★ 補足７ - 2023/09/06 (水) 06:15 追記 | |
| 先刻、「この配信ページの冒頭部に表示されているアクセス・カ | |
| ウンターの番号は連続かつユニークである。接続元の IP アドレス | |
| とアクセス・カウンターの番号とが紐付けてログに記録されている | |
| おそれがある。そのため、そのスクリーン・ショットを記念写真と | |
| してブロマイド撮影したものを SNS 等に公開すると、後からその | |
| 番号を手がかりに各 SNS アカウント毎の IP アドレスが割り出さ | |
| れるという、大胆な手口であろう。」旨の難詰が寄せられた。 | |
| しかし、当システムでは、そのようなアクセス・カウンターの番 | |
| 号との紐付けなどいっさい記録していない。当システムは、ユーザ | |
| ーを追跡して識別することを欲する狭小な利欲目的インターネット | |
| 広告カンパニーとは、おおいに異なる、高尚なものである。 | |
| そもそも、本システムは、あくまでも「公告」であり、「広告」 | |
| ではない。われわれの本システムは、営利広告業界とは隔絶しなけ | |
| ればならない。本システムの管理者が、巷でみられるインターネッ | |
| トサイトのように小遣い欲しさにトラッキング付きバナー広告の仕 | |
| 組みを貼り付けることは、決してあつてはならないことである。 | |
| 以上 | |
| ㌢㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉ | |
| ㌢ ㍉ | |
| ㌢ 【テキストバナー広告枠１】(テスト) ㍉ | |
| ㌢「暑い夏には、カップ・ラーメン！ 極寒電算ルームのお供 ㍉ | |
| ㌢ 飲食禁止ルール対応 隠蔽フタ機能付き 区役所食品」 ㍉ | |
| ㌢ ㍉ | |
| ㌢㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉㌢㍉ | |
| ★ 補足８ - 2023/09/06 (水) 07:34 追記 | |
| 先刻、「TELNET は、社内/庁舎内/大学内ネットワークからアクセ | |
| スできない。」とか「TELNET へのアクセスは一応できるが、『おや | |
| 、いまポート 23 へのアクセス人間が出たぞ』などと、インシデン | |
| トとして情シスアラートが挙がって、社内でやり玉に挙げられて困 | |
| る。」旨のクレムが寄せられた。おそらく組織内のプロクシ・サー | |
| バーやファイアウォールが設置されているのであろう。 | |
| これは、これからの日本の将来を考える上でとても重要かつ興味 | |
| 深い問題であるから、以下のように絮説をする。「社内や庁舎内や | |
| 大学内から、この TELNET の公告ページにアクセスできるか否か」 | |
| が、いわば当該組織のサイバー・セキュリティの組織的水準のバロ | |
| メーターとなっているのである。(a) アクセスが遮断または抑制さ | |
| れていれば、その組織の組織的セキュリティ能力水準は中の下とい | |
| ったところである。(b) アクセスが全然遮断または抑制されておら | |
| ず、自由に TELNET へのアクセスができている場合は、その組織の | |
| 組織的セキュリティ能力水準は、(b-1) 十分に高いか、(b-2) 極め | |
| て低いか、の両極端のいずれかである。 | |
| すなわち、この TELNET 公告にアクセスできるか否かで、その組 | |
| 織におけるセキュリティ能力の高まりと人材育成の余地が測定でき | |
| るのである。ここで、(b-1) と (b-2) の見極めは容易であるから | |
| 、専ら (b-1) と (a) との違いが重要になる。 | |
| まず (b-1) について述べると、これからの高度複雑で国際市場 | |
| 競争力の高いソフトウェアやネットワーク技術、世界普及するイン | |
| ターネット技術、セキュリティ技術、クラウド技術を生み出す余地 | |
| がある人材を組織的に擁する場合、その組織は (b-1) の状況にあ | |
| る。そのような組織は、内部人材の能力と個々人のリスク管理およ | |
| び責任判断能力を十分に尊重し、短期的ではなく長期的な価値を | |
| 追及するという歴史的にみて正しい経営方針により運営されてい | |
| ると見極めることができる。だから、社内や庁舎内や大学内から | |
| (b-1) のように本 TELNET 公告にアクセスできる状態であること | |
| は、その所属楽隊の番兵にとっては将来に希望がもてるまことに | |
| 喜ばしい状況にあることになる。 | |
| さて、本件クレムを述べてきた人材が普段組織で利用している | |
| ネットワークは (b-1) ではないことは明らかである。すなわち中 | |
| 途半端な一時的状態としてみられる (a) の状態にあるからこの | |
| クレム人は困っているのである。 | |
| そこで (a) について述べると (a) の状態にある組織がいよいよ | |
| (b-1) のより優れた状態に進化できるかどうかは不透明である。 | |
| 中途半端な (a) の状態に陥ってしまった組織が (b-1) に脱却す | |
| るためには、組織構成員によるセキュリティ能力水準を高める必 | |
| 要があるが、その水準を高めるためには、任意のプログラミング | |
| 言語、OS 環境が与えられ、自由で責任のある通信実験を各構成 | |
| 員が自らの判断と興味に基づいて行なう必要がある。これがある | |
| 一定の年数、自律分散的に行なわれてはじめて、組織的なセキュ | |
| リティ水準が、他組織と比較して各段に競争力がある程度に、向 | |
| 上するのである。これにより、その組織は、やがて、国際市場競 | |
| 争力の高いソフトウェアやネットワーク技術、世界普及するイン | |
| ターネット技術、セキュリティ技術、クラウド技術を生み出し、 | |
| ひいては、日本国から、外国人インターネット列強の技術を上回 | |
| る高付加価値技術、すなわち、唐土産品のようなものを、多数生 | |
| み出す未来が実現される。これはコンビュータ・ソフトウェア技 | |
| 術以外のさまざまな技術分野において、たとえば造船とか、鉄鋼 | |
| 、家電、半導体、自動車、化学、建築その他ほとんどすべての技 | |
| 術分野において、明治以降、また戦後の成長期において、われわ | |
| れ日本人が成し遂げてきたことと同じであり、これからコンピュ | |
| ータ・ソフトウェア技術分野において、われわれ日本人が成し遂 | |
| げることである。このような長期的価値と利益に基づく経営を行 | |
| なっている組織であれば、たとえ (a) の状態にあったとしても | |
| 、(a) とは峻別した (b-1) のような目的のための自由な実験・ | |
| 人材育成用ネットワークを、いわばゲリラ的にでも少しずつ組織 | |
| 内で復活させていく気運が、すでに生じていることであろう。こ | |
| のようなレジスタンス的運動は、数年前から日本中の官公庁や大 | |
| 企業を含めたさまざまな組織で小規模に開始されており、経営者 | |
| および管理者はこれらを黙認し内心は推奨しているのもである。 | |
| なぜならば経営者群と、自ら創意工夫をして技術進化を行なうこ | |
| とに価値を見出すまさに資本主義的な考え方を有した技術者群と | |
| の間では、その価値観はまったく等しいからである。 | |
| というわけで、社内/庁舎内/大学内ネットワークからこの | |
| TELNET 公告にアクセスしようとしてもプロクシや業者ファイアウ | |
| ォールで遮断されているとか、アラートが出てやり玉に挙げられ | |
| るという問題に直面している方々は、組織内をくまなく探してみ | |
| るとよい。おそらく少人数の前記 (b-1) の考え方に立脚する集団 | |
| が管理者・経営者の黙認のもと、他の大多数の (a) 的な人員用の | |
| 日常業務用ネットワークとは別に、高度な実験・セキュリティ探 | |
| 求・人材育成・技術開発のための秘かなレジスタンス的自由ネッ | |
| トワークを組織内で構築していることであろう。そのような高度 | |
| で希少なネットワークを、ぜひ所属組織内で発見して利用させて | |
| もらうのがよい。ところでそのような希少な高度人材用コンピュー | |
| タ・ネットワークを利用する際には、相応のソフトウェアやセキュ | |
| リティに関するリテラシーが要求される。なぜならば、すでにその | |
| ような先鋭的ネットワークを構築し日常的に楽しんでいる職員たち | |
| は、総じてセキュリティ能力が高いので、自由な環境であっても事 | |
| 故を発生させる可能性が極めて低いが、そこにセキュリティ素人人 | |
| 材が紛れ込み、勉学の初等であるにもかかわらずネットワーク闊歩 | |
| をすると、直ちに事故が生じて組織的にやり玉に挙げられ (来週の | |
| 経営の会議で問題になる)、そのような自由ネットワークもろとも | |
| お取り潰しになってしまうリスクがあるためである。そこで、これ | |
| を防止するため、すでに高い能力を身に付けている既存団員たちは | |
| 、通常、セキュリティ素人的同僚に対してそのような秘密的ネット | |
| ワークが組織内にあることをひた隠しにしようとするであろうし、 | |
| 運良くそれを探り当てて接触してきた者に対しては、かなり高レベ | |
| ルな水準能力を有しているかどうかを考試した上で仲間に入ること | |
| を許認するであろう。そのようにして水準を維持しなければ、組織 | |
| 内で自由で創造性のあるコンピュータ・ネットワークを維持するこ | |
| とはできない。組織内で自由で創造性のあるコンピュータ・ネット | |
| ワークを維持できなければ、その組織からは競争力がある技術や経 | |
| 営的自己判断能力を有する技術人材は生まれないから、長期的にみ | |
| ると組織は他の組織との競争に敗退し存続不能になる。 | |
| さて、社内/庁舎内/大学内で前述のような自由な通信ネットワー | |
| クが秘かに営まれていることを発見したならば、それに加入させて | |
| もらうためには、ある程度のセキュリティ能力水準を身に付ける必 | |
| 要があるが、そのためにはまさにそのネットワークを利用する必要 | |
| があるということになるから、これは鶏と卵の問題となる。そこで | |
| 最初のうちはやむを得ず自宅環境などを発展させてそこで勉学する | |
| のがよい。そうしてある程度の水準に達したならば、社内において | |
| ひた隠しにされていた極秘の自由研究用コンピュータ・ネットワー | |
| クへの入口が、ついには、普段見慣れた事務室のキャビネット机の | |
| 下から、思いがけなく姿を現わすであろう。 | |
| 以上 | |
| ★ 補足９ - 2023/09/06 (水) 14:45 追記 | |
| つとめて TELNETS (TELNET over SSL/TLS) を実装し、本日これを | |
| インターネットにポート番号 TCP 992 で蝉脱させたところ、 | |
| 「TELNETS プロトコルなどといふものは、聞いたこともない。自ら | |
| 勝手気ままに変造した非公認プロトコルを、神聖な ARPANET (イン | |
| ターネット) 上において、あたかも正規のものと標榜するとは、ネ | |
| チケット的にいっても極めて不料簡である。」旨の論難が異朝より | |
| 寄せられた。 | |
| しかしながら、TELNETS は IANA のポート番号表にも記載されて | |
| いる正規なプロトコルである。これは少なくとも 20 年前以上前か | |
| ら登録されている。ただし、ついぞ TELNETS を実装したサーバー | |
| など見たことはないのであるが、TCP ポート番号 992 は、まさに | |
| この TELNETS のためだけに予約されている番号である [出典 1]。 | |
| [出典 1] https://www.iana.org/assignments/service-names-port | |
| -numbers/service-names-port-numbers.xhtml?search=992 | |
| われわれは、今般、この古より IAIA プロトコル番号表に潜没し | |
| てゐた由緒正しき欧風的 TELNETS プロトコルを、現代において改 | |
| めて博得し、これを世界初としてきちんと実装したに過ぎない。 | |
| 以上 | |
| ★ 補足１０ - 2023/09/08 (金) 07:55 追記 | |
| 今般、このような TELNET 公告システムや通信ソフトウェア群といったものを | |
| 開発する為には、どのような方面の事柄を、どのような流れで習得すればよいの | |
| か是非知りたいというような意見が寄せられたが、それは尤もなことである。 | |
| そこでは、これから、インターネットや通信ソフトウェア、OS、または電話会 | |
| 社の光ファイバシステムといった事柄の領域 (これらを、「システム領域」と呼 | |
| ぶ) について、詳しくみてゆくことにしよう。 | |
| まず、なぜシステム領域を深く理解して楽しむことが重要であるのか、それに | |
| よってどのような良いことがあるか、実際に勉強する際に楽で長続きする方法は | |
| 何かといった手がかりを述べる。 | |
| 1 今や、システム技術が分かる人材は希少になってしまった | |
| 今や、インターネットや OS 上では各種のソフトウェアやサービスやビッグデー | |
| タ処理や AI 技術といったものが豊富に咲き乱れ、われわれはそういったサービ | |
| スやアプリを使うだけでなく、自ら開発して普及させることもできる。このよう | |
| なアプリケーションは、すべて OS や通信システムやインターネットといった、 | |
| 基礎的インフラストラクチャ (「システム領域」) の上で動作している。 | |
| ところが、これらの肝心のシステム領域について深く理解する人材は、大変少 | |
| なくなってしまった。アプリケーション領域というものは、システムをユーザー | |
| として使いこなす領域である。この上位レイヤは、勉強することが容易であるし、 | |
| 書籍やインターネット上の情報等の教材も数多く存在するので、日本でも世界で | |
| も、無数のデジタル人材が育成された。競争が激しいので、ある程度良いものを | |
| 作って普及しても、すぐに競争が現われる。苦労する割に長続きしない。 | |
| 2 アプリケーション領域は客室に相当し、システム領域は船体に相当する | |
| アプリケーション領域は、船の上における客室部分である。 | |
| 船の客室をあれこれと苦心して改造し、来客が見込めるレストランを経営して | |
| みても、やがて、同じ船の中に誕生する他のレストランに真似をされ、さらによ | |
| り良いものを作られて、競争に負ける。 | |
| この比喩において、通信システムやコンピュータシステムの領域は、船の客室 | |
| を運ぶ船体部分に相当する。 | |
| 船体は、構造躯体、エンジン、操舵系、燃料系、浸水対策の隔壁などさまざま | |
| なメカニズムで構成されている。船の上は単純で使いやすいが、船の船体部分は、 | |
| 高度・複雑である。これらを理解し、制御することも大変で、さらに設計するこ | |
| とは、もっと大変である。 | |
| 3 システム領域 (= 船体、造船) 能力の獲得は、問題解決・競争力維持・技術 | |
| 革新に必須である | |
| システム領域を作ることは、船体部分の設計と構築に似ている。アプリケーシ | |
| ョン領域を作ることは、客室部分の運営整備や、海路の運航といった、船会社の | |
| 経営に似ている。 | |
| もう少しこの比喩を用いて、船会社の視点から、システム領域の重要性を考え | |
| てみよう。船の上でレストラン経営や旅客や荷主対応を行なう企画部門の社員や | |
| サービススタッフなどは、船体について、熟知している必要はない。しかし、船 | |
| を操縦する航海士や船長や、これらの者を擁する船会社の経営者においては、船 | |
| 体部分を含めた全体のアーキテクチャを深く理解している必要がある。 | |
| その理由は、3 つある。 | |
| (1) 危機管理と問題解決のため | |
| 第一の理由は、危機管理と問題解決のためである。船で不具合が発生したとき | |
| には、その原因をいちはやく究明し、正常な状態に回復する必要があるが、その | |
| ためには船体内部の仕組みを全体的に理解している必要がある。 | |
| そうしなければ、復旧までの時間が長引いてしまい、最悪沈没するか、少なく | |
| とも評判が悪化し、競争に敗れるためである。 | |
| コンピュータ業界において、これは、日本の数多くのシステムに生じる病理的 | |
| な不具合と、修理に膨大なコストがかかる理由は、業界のプロの技術者や経営者 | |
| であっても、システム領域の全体を理解している人が希少でほとんどおらず、個 | |
| 別的に物事に対処しようとして、いつまでも根本原因が分からないという現象が | |
| 広範囲で見られる。基礎的知識は、いざ問題が発生したときに勉強しようとして | |
| も手遅れであり、あらかじめ長年をかけて習得しなければならない。 | |
| (2) 現在の技術水準のもとで実現可能性のある最大限のパフォーマンスと品質 | |
| とを実現するため | |
| 第二の理由は、競争に勝つため、現在の技術水準のもとで実現可能性のある最 | |
| 大限のパフォーマンスと品質とを実現するためである。 | |
| 他の競争船会社の運行する船便よりも、高速で快適なサービスを設計するため | |
| には、単なる精神的気合いだけでは実現不可能であり、船の航行やそれに付随す | |
| る各種の調整といった、現実の物理法則とよく適合した船の運航方法を発案しな | |
| ければならない。 | |
| また、それに応じて適切な船体を選定して船会社に船体を発注し、船体の納入 | |
| を受けて自ら構築する必要がある。 | |
| その際には、競争力のための重要な要素である客室でのサービスを最良のもの | |
| とするために、様々な内部装置や制御系にまつわる船体部分の特性と合わせて、 | |
| 船全体を設計する必要がある。 | |
| これらの結果の善し悪しは、経営に直結する。したがって、船会社自らは、発 | |
| 注先の造船会社よりも詳しく船の細部を理解した上で、あれこれと造船会社に要 | |
| 望・指導して、場合によっては一体となって、最良の船体を構築する必要がある。 | |
| これにより、最も高速で快適な航行サービスを実現でき、競争に勝つことができ | |
| る。 | |
| (3) 現在の技術水準の限界を超える、新たな技術を発明するため | |
| 第三の理由は、現在の技術水準の限界を超えるために、多様性を有する新たな | |
| 技術を発明するためである。 | |
| 造船会社に船の製造を完全に依存すると、現在の技術水準に応じた船体しか製 | |
| 造してもらえない。すると、すべての船会社は互いに類似した水準の船を運航す | |
| る結果となる。これでは、わずかな差異しか発生しない。複数の船会社は無数に | |
| あるので、過度な値下げ競争が生じて、利益はほとんどなくなってしまう。 | |
| この中で、現存技術水準を超える新しい技術的工夫を思い付けば、旅客や荷主 | |
| が驚くようなより良いサービス (たとえば、従来の船が詰めなかった荷物を詰め | |
| るとか、騒音振動が極めて静かである等) を開発でき、旅客や荷主たちに喜んで | |
| 追加料金を払ってもらえる。 | |
| これを多様な方向で各船会社が行なえば、いずれの船会社も得をする。そうで | |
| なくても、単純に、従来と同じサービスでも、運行コストを下げる船体技術的工 | |
| 夫を発明すれば、他の船会社がそれを真似して再び競争になるまでの間は、利益 | |
| が大幅に増えることになる。 | |
| したがって、新たな船体技術は次々に発明される必要がある。そして、船の実 | |
| 際の運航と密接に関連した領域で生じる技術的革新は、船会社でのみ発生し得る。 | |
| 造船所では思い付くことは不可能である。 | |
| そのためには、船会社は、新たな技術を発明するために、現在の船体部分の技術 | |
| について、造船所よりも詳しい程度に熟知していなければならない。 | |
| 4 システム領域の理解を深めることは、アプリケーション開発でも有益である | |
| 上記の船会社の比喩と同様に、コンピュータの世界でも、より良いアプリケー | |
| ションを作るためには、より下位の部分、すなわち、システム領域の内側に入り | |
| 込んで、その動作原理について本質的理解をする必要がある。アプリケーション | |
| の部分、すなわちシステム領域よりも上の部分だけを見ていても不十分であり、 | |
| 競争に負けるのである。 | |
| システム領域の本質的理解を深めて、初めて、性能と品質が高いアプリケーシ | |
| ョンを作ることができて、競争力が生まれる。 | |
| システム領域を理解していれば、自らのアプリケーションにおいて、何か問題 | |
| が発生したときも、原因が直ちにわかり、解決ができる。 | |
| アプリケーションを動作させるための OS や Web サーバーやコンピュータやク | |
| ラウドシステムやネットワークを、最適に選定でき、高速なシステムを、とても | |
| 安価に実現できるようになる。 | |
| そして、ついには与えられた既存の OS、サーバーシステム、コンピュータ、ク | |
| ラウド、ネットワークの制約上では、満足できなくなる。何らかの技術革新を、 | |
| これらのシステム領域において施したいという意欲が生じる。 | |
| すでにシステム領域について広範囲な理解を有している状態になっているので、 | |
| あとは、少ない量の勉強だけで、新しい OS、新しい Web サーバー、新しいコン | |
| ピュータ回路、新しいクラウドシステム、新しいネットワークというものを、自 | |
| ら生み出すことができる状態になっている。 | |
| そこで、最初は既存のものに手を加えて改良し、小規模な技術革新を生み出す。 | |
| そのうち、既存のものを改造するよりも自ら一から開発したほうがより良いもの | |
| ができると気付き、一から書き直すのである。 | |
| ところで、日本からもシステム技術領域に取り組む人材の数が増えて、システ | |
| ム技術領域の技術革新がなされることは、われわれの日本における最高の目標で | |
| あり、これから 10 ～ 20 年以上かけて実現していくべきことである。 | |
| しかし、そのような最終的な輝かしい国家的目標の実現に至るはるか以前の前 | |
| 段階において、世の中にありふれている無数のアプリケーション技術者のうち一 | |
| 部でもよいので、システム領域に関する積極的進入が少しでも生じたならば、十 | |
| 分な利益が、そのアプリケーション技術者の仕事領域において得られるのである。 | |
| すなわち、アプリケーションから普段見えない領域であるシステム領域に関す | |
| る内部的挙動や、その基礎となっているシステム設計者たちの思想を少しでも知 | |
| っていれば、アプリケーションのプログラム・コードを実装したり、各種のサー | |
| バープログラムを配置したりする際に、それを直ちに用いることができるのであ | |
| る。そのようなわずかな違いだけで、何百倍も実行速度が高速化するとか、通信 | |
| 速度や画面表示速度が改良されるとか、使用ネットワーク量や消費メモリや CPU | |
| 時間が削減されてクラウド・サービスにおける課金が安価になるとか、不要な通 | |
| 信サービスやハードウェアを削減してコストや故障率が大幅に軽減されるといっ | |
| たようないった、魔法のような現象が、容易く生じ得る。 | |
| わずかに、システム領域における内部的事柄を知っているか、知らないかとい | |
| う、知識の有無、センスの有無だけで、大いなる品質・速度向上、コスト削減、 | |
| 保守性の向上、柔軟性の強化等が実現できるのである。 | |
| そして、ほとんどの競合相手は目先のアプリケーションをとにかく仕様書通り | |
| に動作させるように表面的に取り繕うことに多量の時間を費やしているので、こ | |
| れに気付く人は極めて少ない。 | |
| そのようなアプリケーション本位の、もともと長期的に崩壊することが分かっ | |
| ているようなシステムの表面的な部分を取り繕うために時間の全部を使うのでは | |
| なく、その部分は 10% くらい手抜きをしてよいので、10% の空いた時間でシステ | |
| ム領域の探求に取り組めば、やがて、一つ奥深い部分において経営者もユーザー | |
| も喜ぶような既存アプリケーションの抜本的改良の方法を思い付くことができる。 | |
| そのような価値の実現のためには、わずかな分量でよいので、日々、システム | |
| 領域の探求を開始することが有利である。 | |
| 5 米国 IT 企業に代表される技術開発者と経営者達は、システム技術を深く理 | |
| 解している | |
| 現在のデジタル世界を支えている IT 企業または各種技術である、UNIX | |
| (Linux 等の元になっている) も、Sun Microsystems 社の Java も、Microsoft | |
| 社の OS も、Google や Amazon のクラウド技術も、このような考え方により、創 | |
| 業または創作され、発展し、現在まで数十年間を経て成長して、高い価値を有す | |
| るようになったのである。 | |
| こういったものを作り始めた技術者たちは、まずアプリケーション領域から入 | |
| り、自らのアプリケーションを他人が作ったシステム領域を基礎として動作させ、 | |
| それでは満足に思わなかったので、他人の作ったシステム領域をより深く探求し、 | |
| 不満足な部分を見つけ、そこに技術革新を施して、システムを作り替えてしまっ | |
| たのである。 | |
| その例を、いくつか見てみよう。 | |
| (1) 「インターネットの発生」 (米国国防総省の社内問題解決) | |
| 西暦 1966 年、米国国防総省の一室には、MIT、カリフォルニア大学バークレイ校、 | |
| 空軍司令部の 3 箇所の異なるメインフレームに向けて 3 本の専用線でつながる | |
| 3 台の端末が置かれていた。 | |
| これら 3 つのシステムの情報を統合利用することは困難で、3 台の端末を苦労 | |
| して操作していたロバート・テイラーさん達は、ついに我慢できなくなり、 | |
| 「ARPANET」 (現在の「インターネット」) を思い付き、構築をし始めた。 | |
| なお、核戦争に耐えることができる通信インフラを国防総省の主導で作ったと | |
| いう説があるが、これは、後に付け加わった理由である。ちょうど並行して、米 | |
| 軍において、ソ連からのミサイルをいちはやく検知して迎撃するシステムを作る | |
| プロジェクトがあり、レーダーの基地と、迎撃のための基地が離れているので、 | |
| その間を接続する通信システムが必要とされていた。参考書籍によると、その話 | |
| は後からきた話である。ARPANET の構築の契機は、上記の 3 台の社内コンピュー | |
| タ専用線の接続である。 | |
| [参考文献] | |
| 「The Origins of the Internet」 Katie Hafner | |
| (2) 「UNIX オペレーティングシステムと C 言語の発生」 (AT&T の社内問題解 | |
| 決) | |
| 西暦 1969 年、米国 AT&T は、コンピュータで文書を書いていたところ、社内に | |
| 大量のドキュメントが生じて、これらの検索ができず、人海戦術を余儀なくされ | |
| ていた。 | |
| そこで、ケン・トンプソンさんたち数名の社員は、大量の社内ドキュメントを | |
| 高速に検索できるようにするため、自作 OS 「UNIX」を開発した。さらに、この | |
| 過程で「カーネル」、「ファイルシステム」、「シェル」、「grep コマンド」等 | |
| を実装する必要が生じ、新しいコンパイラ言語「C 言語」も同時に開発してしま | |
| った。 | |
| (3) 「ルータの発生」 (スタンフォード大学の社内問題解決) | |
| 西暦 1982 年、スタンフォード大学には数千台の異なるプロトコルのコンピュー | |
| タがあった。これらを相互に接続したネットワークを作り、インターネット | |
| (ARPANET) に接続する必要が生じた。 | |
| [参考文献] | |
| 「The Evolution of the Unix Time-sharing System」 | |
| http://www.bell-labs.com/usr/dmr/www/hist.pdf | |
| 「On the Early History and Impact of Unix」 | |
| http://www.columbia.edu/~hauben/book-pdf/CHAPTER%209.pdf | |
| 「grep - History」 | |
| https://en.wikipedia.org/wiki/Grep | |
| 「Where GREP Came From - Computerphile」 | |
| https://www.youtube.com/watch?v=NTfOnGZUZDk | |
| 当時、「ルータ」という製品は存在しなかった。同大学のレン・ボサックさん、 | |
| サンディ・ラーナーさん達は、大学内で多数のコンピュータ間を同軸ケーブルで | |
| 配線し、相互通信できる仕組みを自分たちで考えていった。最終的に、これらを | |
| 相互通信できる試作ソフトウェアと箱を自作できるようになった。これが、今の | |
| 「Cisco IOS」である。これは他の大学や研究所も欲しがったので、自室でルータ | |
| を多数組み立てて販売し初め、注文が殺到したが、大学では公式に商売ができな | |
| かったので、西暦 1984 年に Cisco 社を起業した。 | |
| (4) 「HTTP、Web の発生」 (CERN の社内問題解決) | |
| 西暦 1990 年、CERN (欧州原子核研究機構) では、多数の研究者が持ち込む異な | |
| る種類のコンピュータが乱立していた。研究者の入れ替わりが激しく、大量のド | |
| キュメントを確実に記録し整理しておく方法が存在せず、情報は日々失われてい | |
| た。 | |
| この内部問題を解決するため、ティム・バーナーズ・リーさんにより、「HTML」、 | |
| 「HTTP」、「URL」という規格と、実際に動作する Web ブラウザ「WorldWideWeb」 | |
| および Web サーバー「CERN httpd」が試作された。 | |
| [参考文献] | |
| 「Answers for Young People」 | |
| https://www.w3.org/People/Berners-Lee/Kids.html | |
| 「CERN: Information Management: A Proposal」 | |
| https://www.w3.org/History/1989/proposal.html | |
| (5) 「Java の発生」 (Sun Microsystems の社内問題解決) | |
| 西暦 1992 年、Sun Microsystems 社の数名のチームは、「インターネット対応ス | |
| マート家電」を作ろうとした。 | |
| しかし、既存の「C++ 言語」は複雑で大量のメモリを消費し、多種の不具合が | |
| 発生する等して、開発コストがかさんだ。この社内問題を解決するために、新し | |
| いプログラミングのシステムを思い付き、西暦 1995 年までに、より軽量で開発 | |
| し易い「Java 言語」を開発してしまった。 | |
| なお、伝説的企業 Sun Microsystems 社の「Sun」とは、太陽という意味ではな | |
| く、実は、「Stanford University Network」の略である。スタンフォード大学の | |
| LAN 管理をしていた人たちが、それで培ったコンピュータ技術を製品化するため | |
| に、立ち上げた会社である。 | |
| [参考文献] | |
| 「High noon : the inside story of Scott McNealy and the rise of Sun | |
| Microsystems」 | |
| https://archive.org/details/highnoon00kare/page/120/mode/2up | |
| 「The 'Green team' and the secret development of Java」 | |
| https://cybernews.com/editorial/the-green-team-and-the-secret-development-of-java/ | |
| 「The History and Future of Java Programming Language」 | |
| https://www.appdynamics.com/blog/engineering/the-history-and-future-of-java-programming-language/ | |
| (6) 「クラウド・サービスの発生」 (Amazon の社内問題解決) | |
| 西暦 2000 年、Amazon 社内は大量の Sun サーバーと Cisco ルータで動いており、 | |
| 年間 10 億ドルのコストが発生していた。これが原因で大赤字であり、ドットコ | |
| ムバブル崩壊もあり、資金調達困難で会社が倒産しそうになった。この社内問題 | |
| を解決するために、急遽、コストがかかる Sun のサーバーを捨て、全部 Linux | |
| の自作サーバー群に置き換えて 80% のコストを削減する必要が生じた。 | |
| しかし、大量の Linux 自作サーバー群をどのように管理するかという難題が生 | |
| じた。また、当時多数のプログラマが、プロジェクトごとにそれぞれ独自に社内 | |
| にサーバーやストレージを立ち上げており、各自の構築の手間も大変であった。 | |
| そこで、社員が、同時に、VM、ストレージ、ファイアウォールの構築管理を自 | |
| 動化するための社内ソフトウェアを試作した。これがかなりうまくいき、社外に | |
| も同様の需要であることが分かったので、「Amazon Web Services (AWS。当時は | |
| EC2) 」という名前を付けて、西暦 2006 年から、社外にも販売し始めた。これが、 | |
| 現代の「クラウド・サービス」の起源である。 | |
| [参考文献] | |
| 「How Amazon exposed its guts: The History of AWS's EC2」 | |
| https://www.zdnet.com/article/how-amazon-exposed-its-guts-the-history-of-awss-ec2/ | |
| 「EC2 Origins」 | |
| http://blog.b3k.us/2009/01/25/ec2-origins.html | |
| 6 人材希少性により、システム技術の勉強は、その勉強コストを上回る利益を | |
| 生み出す | |
| 先に述べた、20 年前に回路設計技術を理解する人に希少性が生じた (今は、さら | |
| なる高い希少性が生じている) ことと全く同様に、アプリケーション領域にとど | |
| まらずシステム領域まで本質的理解を深める人材は、現在、極めて高い希少性価 | |
| 値が生じている。そのような人材を必要なだけ確保しておくことは、コンピュー | |
| タに次第に依存してしまった各企業の、経営上の重要な課題となりつつある。 | |
| アプリケーション技術と、システム技術と、可能であれば 20 年前にすでに希 | |
| 少であった回路設計技術の 3 つとも揃った企業は、最強の力を発揮することにな | |
| る。現代の外資系 IT 企業の強さは、単一の企業でこれらの 3 つの分野を深く理 | |
| 解した技術者を真っ先に確保して手放さないことにある。外資系 IT 企業は、ア | |
| プリケーション層の表面的技術者や、顧客との間の営業スタッフも雇用するが、 | |
| これらは大量に市場に存在することから、代替可能な人材であるので、人材整理 | |
| が必要になったらすぐに解雇し、また必要になったら雇用すれば良いということ | |
| になっている。 | |
| ところが、システム技術まで分かる人材は希少で、ほとんど代替不可能である。 | |
| 回路設計技術となると、さらに希少で、決して代替不可能な人材であるといえる。 | |
| Apple は、独自の OS と共に、その OS を少ない消費電力で動作させる低コス | |
| トな CPU の回路ごと開発している。Cisco や Juniper は、独自のルーティング | |
| ソフトウェアと共に、そのソフトウェアの処理が足らない通信処理を高速で処理 | |
| するチップを開発している。Google は、AI 処理を高速に実現できる独自のチッ | |
| プを開発している。 | |
| Java や商用 UNIX を発明してコンピュータの歴史を作り続けていた Sun | |
| Microsystems 社も、SPARC という独自の CPU を開発して優位性を築いてきた。 | |
| このように、世界に冠たる IT 技術集団の企業は、アプリケーション技術者、シ | |
| ステムソフトウェア技術者、回路設計技術者の 3 層をすべて擁しているのである。 | |
| この並びでは、後者に行くほど希少性が高い。 | |
| これらの人材を必要なだけ確保し続けることが、IT 企業の存続条件であるから、 | |
| 厳しいリストラを必要とする場合も、これらの人材は、最後まで、手放すことが | |
| ない。 | |
| よって、単に各個人の利益 (社会における技術者としての価値) のことだけを | |
| 考えても、システム技術領域 (できれば、回路設計領域も含めて) に関する本質 | |
| 的理解を深めることは、そのための勉学のためのコストを大きく上回るだけの利 | |
| 益につながる。 | |
| 7 システム領域に関する勉強・探索は、どのような領域を対象として、どれく | |
| らい深く行なえばよいか | |
| コンピュータにおけるシステム技術領域に関する本質的理解を深めることは、 | |
| 希少な人材となるために重要であるとすれば、次に、市場価値があるとみなされ | |
| る程度の希少性を得るために、具体的な 3 つの疑問が生じる。 | |
| 第一に、地点と広さの問題がある。その対象領域をどのように選択するか、ど | |
| のような範囲を選択するかである。 | |
| 第二に、深さの問題がある。理解の程度は、最低限どの程度必要であるかとい | |
| うものである。 | |
| 第三に、そのような勉強を新たに行なうことは、比較的辛いものであり長続き | |
| しないと思われるところ、どのようにしてこれを楽しく継続的に進めればよいか | |
| という問題がある。 | |
| システム技術領域に注目して取り組みをしようとするとき、発生しがちな誤り | |
| は、少数の領域だけに狙いを定めて、その部分について理解を深め、技術力を高 | |
| めるという手法である。この方法は、システム領域がきれいに木構造になってい | |
| れば良いが、システム技術領域は計画主義的に構築されたものではないので、人 | |
| 間が生み出した構造物の中でも特に複雑・高度になっており、物理社会の複雑さ | |
| とよく似ていて、きれいな木構造にはなっていない。ある一つの部分を理解する | |
| ためには、芋づる式にかなりの部分を理解しなければならない。このシステム領 | |
| 域という複雑な密林を辿っていくとき、「これより先は自分の興味とは無関心で | |
| ある」というように思って、壁を作ってしまうと、深い理解を得ることはできな | |
| い。 | |
| システム技術領域を拡大していくと、細分化されたさまざまな領域に分かれる。 | |
| システム技術領域のうち、特にソフトウェア的な部分またはそれに近い部分 (す | |
| なわち、純粋なハードウェア領域よりも上位レイヤの部分) のみを領域をみてい | |
| くと、大雑把にみると、(1) コンピュータ領域、(2) インターネット領域、(3) | |
| 通信インフラ領域に分類できる。 | |
| (1) を拡大すると、OS 技術、プログラミング言語技術、仮想マシン (VM) 技術、 | |
| コンテナ技術、クラウド技術、ストレージ技術、セキュリティ技術、負荷分散技 | |
| 術等、色々なものが見えてくる。これらの大項目の中をみると、例えば OS の中 | |
| はさらに細分化され、例えばメモリ管理、タスク管理、入出力、通信スタック、 | |
| ファイルシステム、デバイスドライバ、等と無数に枝分かれしていく。これらの | |
| 枝分かれした先に、さらに枝分かれが何層にも積み重なり、全体としてみると、 | |
| OS の中だけでも、到底 1 人の人間がすべて理解できない程度の規模になってい | |
| る。 | |
| (2) を拡大すると、データリンク技術、ルーティング技術、プロトコルスタッ | |
| ク、インターネットサーバー技術、認証技術、制御通信技術、暗号通信技術、等 | |
| とやはり無数に枝分かれしていく。 | |
| (3) を拡大すると、伝送技術、収容技術、収容装置制御技術、設備およびノー | |
| ドの管理技術、加入者認証技術、等とやはり無数に枝分かれしていく。 | |
| そして、(1), (2), (3) は密接に関連しており、境界線は明確に可分ではない。 | |
| ある領域の内容が、他の領域にも自然に顔を出すのである。いずれかの領域が、 | |
| いずれかの領域の上位または下位に存在するということはなく、それらの部分部 | |
| 分が、互いに複雑に交じりあって存在している。 | |
| よって、要領よく最小の手数で理解しようとしても、中途半端な理解に終わる | |
| のみであり、その状態は、むしろ危険な可能性すらある。全体を理解してはじめ | |
| て適切な判断を行なうことができる。 | |
| そういっても、システム領域全体は、現代の物理社会の複雑さに匹敵するか、 | |
| それ以上の複雑性を有している。また、現代の人体の仕組みの複雑さに匹敵する | |
| か、それ以上の複雑性を有している可能性すらある。 | |
| システム領域の動作原理を、全部深く理解することは、誰にも不可能である。 | |
| よって、ひとまずは自らの興味がある点や解決したい問題がある点を、重点的に | |
| 掘り下げていって、その点を中心として、周囲を芋づる式に色々と見て回るとい | |
| う手法が良い。 | |
| これにより、各個人の個性が発揮された勉強方法が可能になるし、有利でもあ | |
| る。広く深いシステム領域は、そのどこの分野の事柄についてもそれを理解する | |
| 人材はかなり希少なので、自らの興味に基づいて色々と勉強していったほうが、 | |
| 流行りの技術部分に集中するよりも、結果として、社会に求められる希少性が自 | |
| 然に得られるためである。 | |
| システム領域に関する本質的理解の程度の深さは再現なく深まる。深さを求め | |
| 始めると、切りが無くなるので、少なくともこの程度の深さまで得られればひと | |
| まず満足であるという水準を、各個人が定めておく必要がある。その水準は個人 | |
| によって異なるが、おおむね、自らが特に選択した対象領域に近い部分について | |
| は、自ら、既存のシステム技術に関して不満足な部分を手を動かして大幅に改良 | |
| したり、または根本的に一から作り直してしまう程度のシステム設計能力及びプ | |
| ログラミング実装力が自然に芽生える程度の深さを目指すべきである。 | |
| これは一見高いハードルに見えるが、後述するような楽しみを採り入れた探求 | |
| 方法を用いて、システム領域を探索すると、比較的短時間でそのレベルに到達す | |
| ると思われる。高校生、大学生で重要なプログラムを実装して世界中に公開して | |
| いる人は豊富に存在するが、彼らは皆、既存のシステムを見て、不満を感じ、新 | |
| しいシステムを実装してしまった人材である。内容・分野にもよるが、ここで述 | |
| べた程度の能力を得るために必要な日数としては、数年間もかからないのではな | |
| いかと思われる。 | |
| 次に、自らが技術革新を起こそうと思っている領域では無いけれども、技術革 | |
| 新を起こそうと考えている領域と直接的に密接に結合されている隣接領域につい | |
| ては、その隣接領域を作り替えようとする際に必要な程度の深い理解は必要では | |
| なく、その異なる領域をあたかもカプセル化されたライブラリのようにみなして、 | |
| それを必要に応じて呼び出しして駆動させる際に、その隣接領域の内部的動作の | |
| 癖や、どのようにしてそれを呼べば良いか、どのようにすればこのような挙動が | |
| 発生するか、どのようにすれば不具合を上手く隠蔽することが出来か、という程 | |
| 度に、動作原理と実際の実際の大まかな細部を理解していれば、それで十分に足 | |
| りると思われる。 | |
| その上で、特定の細部について分からないことがあれば、その都度色々と設計書 | |
| を調べたり、コードを呼んだり、文献に当たったり、インターネット上で調べ物 | |
| をしたりすれば良いのである。 | |
| 8 どのようにすれば、複雑高度なシステム領域を楽しく自然に探索する意欲が | |
| 生じるか | |
| 先に述べた通り、システム領域の内部的理解の能力を有する人材は極めて希少 | |
| であるから、仮にその能力を手に入れたならば、その人材には、大きな経済的価 | |
| 値が生じることになる。 | |
| すると、個人の側としては、自らの人生上重要な、社会的価値を高めるという | |
| 手段として、システム領域について是非とも詳しくなりたいと欲することは、利 | |
| 益追求のための行動の動機として自然に発生する当然の動機である。 | |
| ところが、コンピュータに限らず、いかなる学問領域であっても、社会的価値 | |
| が生じる程度に勉強に励むという行動パターン、その利得だけを追求してそれに | |
| 取り組む際には、大いなる苦痛が生じる原因となり、結局三日坊主で諦めてしま | |
| うことになりかねない。 | |
| 特にシステム領域の問題は、表面的なアプリケーション領域と比較して、目に | |
| 見えない部分、素早く動作してしまって訳が分からない部分等、日常生活から見 | |
| ても、五感的にも、特徴が薄く印象に残りにくい極めて抽象的な領域であり、机 | |
| 上だけの勉強では、間もなく飽きてしまって、大いなる苦痛を感じ、効果も薄い。 | |
| そこで、勉強が長続きするためには、何らかの工夫を施して、探求を楽しむよう | |
| にするほうが有利である。そのためには、いくつかの方法がある。 | |
| まず、不完全性について面白く感じられるような (すなわち、インチキな・け | |
| ったいな) 部分を探して探求するという方法があり、これは、かなりうまくいく。 | |
| システム領域というのは、普段のアプリケーション領域、ユーザー領域から見 | |
| えない舞台裏 (バックステージ) の部分である。たとえば、来客用の通路や陳列 | |
| されている見世物は一見きれいに見えているが、裏側に入り込んで内部行動を見 | |
| てみると、信じられないことに、大変いいかげんに実装されていて、よくこのよ | |
| うな具合で、なんとまあ、何十年も世界中の何千万台のコンピュータの共通的重 | |
| 要処理が動いているものだ、というように、毎日何千万人もの目を触れるとても | |
| 重要な部分が、意外にインチキな実装になっていることを知り、その発見をとて | |
| も楽しく思うものである。誰かその複雑怪奇な部分を書き直せばきれいになるの | |
| だが、事実上一応不具合なく動作しているようで、そのままに放ったらかしにな | |
| っている部分が、主要なシステム領域のプログラムでも山ほどある。 | |
| 次に、セキュリティ上の理由で表からは見えないようにしている部分について、 | |
| どのように隠蔽して、分離や強制を実現しているのかというような、安全確保の | |
| 仕組みを見て回るのも、大変に面白いと感じられるはずである。 | |
| システム技術領域では、複数のアプリケーションやユーザーを同じ空間に収容 | |
| して、効率性を高めたり、必要な相互作用・共同作業を図ったりする必要がある。 | |
| ところが、複数のアプリケーションやユーザーが隣と干渉すると、秩序が乱れて、 | |
| 正常な活動が不可能になってしまう。 | |
| また、暴走したアプリケーションやユーザーを検出・特定し、その動きを速や | |
| かに予防または排除するという仕組みも必要になる。このような秩序維持のため | |
| に、システム領域では、あたかも公安警察のような、裏側に隠れてこそこそと動 | |
| く治安維持機能や、生安警察のような、実際に出てきて取り締まりをするような | |
| 機構などが記述されている。 | |
| 普段はアプリケーションまたはユーザーとして表側で振る舞っているときによ | |
| く見かけるセキュリティや暴走排除の仕組みが、裏ではこのように実装されてい | |
| るのかということを見て、深く感心することになる。 | |
| また、このようなセキュリティの仕組みを見て回るときに、かなり極端な暴走 | |
| 状況を想定して仕組みが記述・実装されていることを感じるはずである。先人が | |
| 想定して実装してくれたそういった記述・実装の基礎となっている実装者の豊富 | |
| ・多様な想像力を感じることができ、それに感動をするのである。 | |
| さらに奥深く進むと、大変重要なセキュリティ実現のための隔壁部分が、わず | |
| か薄皮一枚で隔てられている様子を、興味深く見つけることもできる。サイバー | |
| 空間は、物理的な隔壁の質量よりも、薄皮でもよいのでその論理的意味合いの強 | |
| さや周辺部分との整合性のほうが、実際のセキュリティ問題に対して高い耐性を | |
| 示すのである。 | |
| 大抵はこのような周辺を探索して歩くと、未知の脆弱性を発見してしまうもの | |
| であるが、それもまた楽しみの一つである。 | |
| そして、単に対象物を静的に分析するというだけでなく、実際に動作している | |
| 極めて重要なシステムを間近に裏側から見るというのは、何よりも楽しいことに | |
| 感じられるであろう。 | |
| その上に何百万人ものユーザーの重要な仕事、通信、生活が乗っていて、少し | |
| 間違えると全部クラッシュしてダウンしてしまって大変なことになるというよう | |
| なシステムが、色々と存在する。 | |
| そういったシステムを表面からでなく、裏側から秘密の内部的通路を通って観 | |
| 察をするのである。これは、特にクラウドサーバー群や、インターネットシステ | |
| ムや、電話会社の通信インフラ等の物理的なインフラの内部実装に近い部分を観 | |
| 察する際に向いている。 | |
| 単なる 1 台のコンピュータの中で発生する様々なシステムソフトウェアの挙動 | |
| は、自らのコンピュータの上で、仮想マシンやデバッガ等を用いて、いくらでも | |
| 時間をかけて楽しむことができ、それはすべてのユーザーが可能なことであるの | |
| で、それによって得られる体験の希少性価値は、他の人であっても恐らく同等の | |
| ものが得られるのであろうという予測が成り立つ。 | |
| 他方で、現用の実際の莫大な責任の重みがかかっているシステムに間近に接近 | |
| をして、それがまさに先人達がコツコツと積み上げてきたシステムソフトウェア | |
| のプログラム・コードによって寸分違わず円滑に動作しているという様子を目の | |
| 当たりにすれば、自分もまたそのようなシステムソフトウェア技術を是非とも実 | |
| 装し、同じように何百万人ものユーザーの生活や仕事がかかった状態で現実の負 | |
| 荷をかけた状態でそのシステム・サービスを提供したいというような、根源的な | |
| 意欲が、われわれの内側から、自然に湧き出してくることは、間違いが無いこと | |
| なのである。 | |
| そのような意欲がわれわれの内側に一旦発生したならば、そのようなシステム | |
| やソフトウェアの設計や開発を現実化するために是非とも必須となる、システム | |
| ソフトウェア領域に関する勉強に励もうと思うものである。 | |
| 目前で見て感動したものと同じ程度の物を、寸法はもう少し小さいとしても、 | |
| 本質的な同等の動作をするようなもの (ミニチュア的なもの) を自ら少し作って | |
| 遊びたいと考えるものである。そのような意欲がいったん発生したならば、自然 | |
| に、色々と必要な勉強をして、システムを組んだり、プログラムを開発したりし | |
| 始めるであろう。 | |
| 9 コンピュータシステムとネットワークシステムは併せて習得する必要がある | |
| システム領域について深く取り組む場合、コンピュータシステムとネットワー | |
| クシステムは深く関連しており、併せて習得する必要がある。 | |
| すなわち、(1) コンピュータ領域、(2) インターネット領域、(3) 通信インフ | |
| ラ領域、の 3 領域のうち 1 つに狙いを定めて、残り 2 つは知らんと考えるのは | |
| 大いに不利である。 | |
| 人間の身体は、頭脳、神経、器官が連なって 1 つのシステムを構成しているが、 | |
| たとえば神経だけを他から分離して、それのみを拡大して研究の対象としても、 | |
| 人間の身体を理解することはできない。 | |
| 特定部位について着目して考える場合も、全部がつながった状態を前提として | |
| 色々と考える必要がある。そして、これらのつながりの部分間に、安易な境界線 | |
| を引いて分離してはならない。ここから内は自らの責任で、ここから外は責任範 | |
| 囲外として区分してはならない。それは既存の手法に基づいて経営事務的な動作 | |
| を繰り返す IT 業界のサラリー・マンの行なうことである。 | |
| われわれは、全体的視点を見た問題解決、最適化されたシステムの構築、及び | |
| システムに関する必要に応じた技術革新を行なうことにより希少性を入手しよう | |
| とする以上は、IT 業界のサラリー・マンの行動様式とは全く別の行動をしなけれ | |
| ばならない。 | |
| すなわち、1 人で、 (1) コンピュータ領域、(2) インターネット領域、(3) 通 | |
| 信インフラ領域、のすべての領域を、単体の頭脳で把握しなければならない。 | |
| これらを統合的に把握した 1 つの頭脳の個人的能力は、(1), (2), (3) をそれ | |
| ぞれ分離的に把握した 3 つの頭脳 (IT 業界の 3 名のサラリー・マン) が合わさ | |
| って議論して生じる集団的能力を悠々と上回る。 | |
| その理由は、(1), (2), (3) をそれぞれ別々に理解した 3 名が合わさって無理 | |
| 矢理知恵を出し合って問題を解決するために必要なコミュニケーションコスト | |
| (物理的に発生する時間) が原因である。これは、単なるコストの問題ではない。 | |
| コストの問題であれば、資本があれば解決できる。 | |
| ある複雑な領域を理解して問題解決をするための高度な思考を 1 つ頭脳の内部 | |
| に一時的に保っておいた後に、それを保持している状態で、別のある複雑な領域 | |
| を理解して問題解決をするための高度な思考を 1 つ頭脳の内部に一時的に保って | |
| おいて、この前者と後者との間で可能な限りの融合パターンを探索し、最適な解 | |
| をその一時的な思考状態が消失するまでのタイム・リミットが到来するのでの間 | |
| に見つけ出すためには、その一時的な思考状態が消失するまでの時間的猶予しか | |
| ない。 | |
| (1), (2), (3) のように分化した 3 名の頭脳を揃えても、それらの頭脳の間の | |
| 思考を瞬時に結びつける意思伝達方法が、現在の技術水準では、言語によるしか | |
| ないのであれば、言語として頭脳の思考をシリアライズ (書き出し) し、通信手 | |
| 段 (音声、文字) で相手に渡し、受け取った人がこれをデシリアライズ (読み取 | |
| り) して理解するまでにかかる 3 名の間の通信遅延時間を超えると消失してしま | |
| うような一時的な思考状態に関連した集団思考は、原理的に行なうことができな | |
| い。 | |
| よって、(1), (2), (3) のように分化した 3 名の頭脳は、仮に無限の時間をか | |
| けても、無限のコストをかけても、決して、1 人の単体の頭脳で (1), (2), (3) | |
| を統合的に把握している頭脳に勝つことができない局面が存在する。そして、そ | |
| のような局面が生じるような最先端部分において、ようやく、価値のある技術革 | |
| 新を行なうことができる。 | |
| したがって、一人の人が、(1) コンピュータ領域、(2) インターネット領域、 | |
| (3) 通信インフラ領域のすべての領域を理解し、これを自らの頭脳の中で統合的 | |
| に把握した状態を作り出す必要がある。 | |
| (1), (2), (3) のように分化した 3 名の頭脳が、同じ組織に存在するだけでは、 | |
| 「組織的に」 (1), (2), (3) を理解していることにはならない。単に個別に理解 | |
| しているバラバラの思考が存在するだけである。 | |
| このような単一人で広い領域を深く理解した状態の人材が、複数人集まってチー | |
| ムワークを行なえば、はじめて、複数人を集めて意味のある技術革新が生じ得る。 | |
| 相互に細かい得意部分は異なっても、総じて (1) コンピュータ領域、(2) インター | |
| ネット領域、(3) 通信インフラ領域 のすべてを理解している人たちの間では、あ | |
| る先鋭的思考を行なうとき、それを少ない言葉で表現して共有することが可能と | |
| なるためである。 | |
| それによって、各人の思考が同時並列的に行なわれるならば、その思考過程で | |
| 次々に発生する差分情報も、また、少ない言葉で互いに共有可能であり、短い時 | |
| 間で、同期が整うことになる。 | |
| すなわち、(1), (2), (3) を初めて「組織的に」理解していることになる。巨 | |
| 大な頭脳が誕生していることと同一となる。 | |
| 極めて優れた技術を生み出す外資系の大規模 IT 企業の人材の強みは、ここに | |
| ある。巨大なクラウド・サービス、検索エンジンサービス、AI サービスは、(1) | |
| コンピュータ領域、(2) インターネット領域、(3) 通信インフラ領域 をだいたい | |
| 統合的に理解している個人の能力の結集で作られているのである。 | |
| 10 ネットワークシステムは、インターネット領域と、通信インフラ領域から成 | |
| る | |
| インターネット領域と、通信インフラ領域とは、背景思想と、発達の歴史が異 | |
| なる。インターネット領域は、ソフトウェア本位、情報処理主体 (コンピュー | |
| タ) 本位、ユーザー本位であり、権限や責任の分散価値の実現の思想を基礎とし | |
| ている。 | |
| 通信インフラ領域は、ハードウェア本位、通信事業者本位、管理権力者本位で | |
| あり、権限や責任の集中価値の実現の思想を基礎としている。 | |
| そして、現在のデジタル社会においては、この 2 つの領域が、別々のところか | |
| ら生じて発展してきて、互いに対立を繰り返しながら、一応、かなりけったいな | |
| 形状で結合し、さらなるけったいな形状を生み出したが、それが事実上非常に良 | |
| い状態で組み合わさっている。 | |
| この偶然の産物の上で、われわれは、大いなる利便性を受けているのである。 | |
| あたかも東洋文化と西洋文化のような具合である (ところで、この東洋・西洋の | |
| 2 つの文化が融合された国が、日本であるため、日本は、誠にけったいな構造に | |
| なっている)。 | |
| この 2 つの、インターネット領域と、通信インフラ領域とを、1 つのものとし | |
| て技術理解を試み、さらに技術革新をしようとすると、混乱することになり、成 | |
| 果が生まれにくい。 | |
| また、この 2 つのうち一方だけを重要とみなして、もう一方への取り組みを忘 | |
| れる (知らずにいる) と、正しいアイデアを思い付くことができない。 | |
| 重要なのは、この 2 つの構造や価値観の違いを両方とも把握した上で、両方と | |
| も吸収してしまうことである。 | |
| このように、システム領域 (インターネット領域、通信インフラ領域、コンピ | |
| ュータ領域) の 3 つを同時に学べる領域である、インターネットや通信システム | |
| の、特に面白く創造的な部分を、われわれは、これから、じゅうぶんな時間をか | |
| けて、丁寧に探索していくことにしよう。 | |
| 以上 | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment