検索結果

本記事は、現代におけるデータ収集をテーマにした連載の最終回です。最後は、企業の管理者による従業員の追跡について取り上げます。 この連載の読者の多くは、私と同様に「ナレッジワーカー」、いわゆる「クリエイティブクラス」に属しており、製造ライン上の部品のように単純に追跡されることはないと考えているかもしれません。しかし実際には、非常に多くの労働者がきわめて侵襲的な監視の対象となっています。 こうした広範な追跡は、雇用主との契約の一部として合法的に行われるものであり、以下のような内容が含まれる場合があります。 キーストローク（キー入力）の記録 画面の監視 インターネット利用状況 メールの内容 ソフトウェアの利用状況 通話時間および通話内容 ボイスメールやインスタントメッセージ GPSによる位置情報の追跡 入退館時のバッジ記録 ビデオ監視 指紋や顔認識スキャンなどの生体情報 もちろん、これらすべてがすべての従業員に対して使用されるわけではありません。たとえば、紙の書類からデータベースへ入力する業務では、作業速度や長時間の休憩の有無を確認するためにキーストロークの記録が使われることがあります。一方で、トラック運転手（郵便配達員を含む）の場合は、業務の進行状況や業務外利用の有無を把握するためにGPSが利用されることが一般的です。 ある企業は、マウスやキーボードの操作を追跡するサービスを提供しており、次のように顧客へ訴求しています。「従業員に関する重要な疑問に答えます：誰が仕事への関与を失っているのか？誰が遅れを取っているのか？誰が燃え尽きのリスクにあるのか？リモートワークやハイブリッド勤務は生産性にどのような影響を与えているのか？」（最後の問いは、集計データに基づく一般的な分析です。） また、ある調査で高評価を得た企業は、非常に幅広いユーザー活動を追跡しています。「画面の録画、従業員PCのリアルタイム監視、メールの追跡、キーストロークの記録、さらにはZoomセッションに至るまで、多岐にわたる活動を追跡します。」 なお、米国では企業側から隔離されている重要な個人情報の分野があります。それは健康情報です。HIPAA（医療保険の相互運用性と説明責任に関する法律）により、従業員は雇用主が提供する医療保険を利用しても、診断内容や治療内容が雇用主に知られることはありません。 << このシリーズの前の記事を読む | 次の記事を読む >>

Kubernetesは多くのレイヤーと機能で構成されており、それに対応して宣言的な管理ルールも非常に複雑です。Kubernetes自体を理解することは重要ですが、DevOpsの受験者は、Kubernetes管理を容易にするために登場した代表的なオープンソースプロジェクトについても習熟しておく必要があります。LPI DevOps Tools Engineer認定では、Helm、Kustomize、Flux CD、Argo CDに関する基本的な知識が求められます。 Helm Kubernetesアプリケーションの管理において最も重要なツールの一つがHelmです。Helmはパッケージマネージャーであり、アプリケーションの定義、インストール、ライフサイクル管理を簡素化します。 Helmのインストールは簡単で、環境や好みに応じて複数の方法があります。Debian系やRed Hat系のLinuxディストリビューションでは、公式のインストールスクリプトを使用するのが最も簡単で、セットアップ全体を自動化できます。 Chartとは何か Helmにおける基本単位はChartです。Chartは、Kubernetesリソースの集合を記述した構造化ファイル群であり、テンプレート、デフォルト設定、メタデータなどを含みます。これにより、アプリケーションを異なる環境でも一貫してデプロイできます。 Releaseは、Kubernetesクラスター内にデプロイされたChartのインスタンスを指します。Chartをインストールするたびに新しいReleaseが作成され、一意の名前が付与されて状態が管理されます。これにより、同一アプリケーションの複数インスタンスを異なる設定で共存させることが可能になります。 Valuesは、Chartをカスタマイズするための設定値で、通常はvalues.yamlというファイルに定義されます。このファイルにはテンプレートに適用されるデフォルト値が含まれています。 ユーザーはインストール時やアップグレード時にこれらの値を上書きできるため、テンプレート自体を変更することなく柔軟な設定が可能です。この「テンプレートと値の分離」はHelmの重要な設計思想であり、再利用性と一貫性を高めます。 Helmを使ったインストール・更新・削除 Helmはアプリケーションのライフサイクル管理をシンプルに行うためのワークフローを提供します。helm installコマンドによりChartをクラスターへデプロイし、新しいReleaseが作成されます。 Helmのセットアップ後は、Chartリポジトリを追加します。利用可能なリポジトリはArtifact Hubで確認できます。リポジトリの追加は以下のように行います。 $ helm repo add bitnami https://charts.bitnami.com/bitnami 追加後、以下のコマンドでChartを検索できます。 $ helm search repo bitnami アプリケーションをデプロイするにはhelm installコマンドを使用します。まずローカルのリポジトリ情報を更新します。 $ helm repo update 次にChartをインストールします。以下の例ではMySQLをインストールしています。 $ helm install bitnami/mysql この処理により、Chartがダウンロードされ、テンプレートが値に基づいてレンダリングされ、新しいReleaseとしてクラスターにデプロイされます。 既存アプリケーションの更新にはhelm upgradeを使用します。このコマンドは差分更新を行い、イメージ更新や設定変更、新機能の有効化などを反映します。また、Helmは各Releaseの履歴を保持しており、必要に応じてロールバックも可能です。 デプロイ済みアプリケーションの確認にはhelm listを使用します。クラスターまたは特定の名前空間内のRelease一覧を確認できます。 不要になったアプリケーションはhelm uninstallで削除できます。関連リソースも含めて削除されるため、不要なオブジェクトが残ることはありません。 values.yamlによるカスタマイズ Helmにおけるカスタマイズは主にvalues.yamlファイルで行います。このファイルにはレプリカ数、イメージバージョン、サービスタイプ、リソース制限などの設定が含まれます。 このファイルを編集する、またはデプロイ時に別の値を指定することで、開発環境・検証環境・本番環境などに応じた設定が可能になります。 コマンドラインオプションや追加のYAMLファイルによる上書きも可能で、ベース設定を維持しつつ環境ごとの差分を適用できます。テンプレートエンジンはこれらの値を動的に処理し、Kubernetesマニフェストへ反映します。 この仕組みによりモジュール性が高まり、同一Chartを複数の環境で再利用できるようになります。 Kustomize Kustomizeは、Helmとは異なるアプローチでKubernetes設定を管理するツールです。テンプレートではなく、既存のYAMLマニフェストに対してレイヤーやパッチを適用することに重点を置いています。 ベース設定を定義し、その上にオーバーレイを重ねて特定の項目のみ変更できるため、元のファイルを変更せずに柔軟な構成管理が可能です。 Kustomizeはkubectlに標準で組み込まれており、追加インストールなしで利用できます。テンプレート言語を導入せず、宣言的な構成管理を維持したいチームに適しています。 Helmがパッケージ化とパラメータ化を重視するのに対し、Kustomizeは構成の合成と変換を重視します。用途に応じて両者を併用することも可能です。 Flux CDとArgo CD Flux CDとArgo CDは、Gitリポジトリを基盤としてKubernetesリソースのデプロイと同期を自動化するGitOpsツールです。HelmやKustomizeの概念を拡張し、継続的デリバリーを実現します。 GitOpsモデルでは、クラスターの望ましい状態をGitリポジトリに保存します。Flux CDとArgo CDはこれを継続的に監視し、実際のクラスター状態を定義通りに保ちます。 これにより、一貫性、追跡性、自動復旧が実現されます。 Argo CDは豊富なUIと詳細な可視化機能を提供し、Flux CDは軽量でKubernetesとの統合が強力です。どちらもHelmやKustomizeに対応しており、柔軟なデプロイ戦略を実現できます。 HelmとGitOpsツールを組み合わせることで、完全に自動化された再現性のあるアプリケーションデリバリーパイプラインを構築できます。 Kubernetesアプリケーション管理と関連ツールへの理解を深めるうえで、LPI DevOps Tools Engineer認定の公式ラーニングマテリアルは非常に有用です。これらは無料で提供されており、Chart、Release、Values、アプリケーションのライフサイクル管理などのトピックを体系的に学習できます。学習内容の整理と理解の定着に役立つでしょう。 << このシリーズの前の記事を読む | 次の記事を読む >>

2026年3月26日、日本・東京 —Linux Professional Institute（LPI）日本支部は、2026年度よりタイ王国の日本型高等専門学校（Thai KOSEN）において、Security EssentialsおよびLinux Essentials International認定に対応したLPIの英語版ラーニングマテリアルが採用されることを発表しました。これらの教材は、ITセキュリティおよびLinuxの基礎を網羅しています。 タイの工科系高等教育機関においてサイバーセキュリティ教育を推進する際、基礎的な技術コンテンツを一から開発し、それを教材として整備することは、教員にとって非常に大きな負担となっていました。さらに、急速に進化するサイバーセキュリティ分野において、内容の最新性と正確性を維持することも大きな課題でした。 こうした背景のもと、世界的に評価され、実績のあるLPIの英語カリキュラムを採用することで、教育者の負担を軽減しつつ、高品質で国際的に通用するIT教育を提供できる環境が整えられました。 学生はこれらの教材をWeb上から直接ダウンロードし、印刷して学習することができます。 Security Essentials：ITセキュリティにおいて、個人および組織が必ず守るべき基本要素を網羅しています。初めてセキュリティを学ぶ学生や、安全にITを活用するための基礎スキルを身につけたい方を対象としています。 Linux Essentials：オープンソースコミュニティの基盤であるLinuxの基礎を体系的に学べる内容となっています。 これらの英語版ラーニングマテリアルは、学生が技術的知識を習得できるよう設計されており、デジタル形式と紙媒体の両方で学習を支援します。 本カリキュラムを通じて、学生はサイバー空間で自らを守る方法を学びます。さらに、LPI認定資格を取得することで、将来の雇用主や顧客に対して、自身の知識とスキルを客観的に証明できるようになります。 タイの高等専門学校の卒業生は、タイ国内にとどまらず、日本企業やグローバルなIT市場においても、即戦力となるセキュリティ人材として活躍することが期待されています。 Linux Professional Institute（LPI）について Linux Professional Institute（LPI）は、オープンソース分野の専門家のスキル向上を支援する世界最大の非営利団体です。180か国以上で試験を実施し、多言語の教育教材を提供することで、IT人材のキャリア開発を支援しています。 メディア連絡先 大野 真Linux Professional Institute 日本支部info-ja@lpi.org

DevOps Tools Engineer 2.0試験の目標703.2では、「Kubernetesの基本操作」が扱われます。この分野は試験の中でも重要な割合を占めており、Kubernetes上でアプリケーションをデプロイおよび管理する方法について、しっかりとした理解が求められます。受験者は、次のことができる必要があります。 宣言的なYAMLファイルを用いてKubernetesリソースを操作できる Podが基本的な実行単位であることを理解している Deploymentを使ってアプリケーションのライフサイクル（スケーリングやローリングアップデートを含む）を管理できる ServiceやIngressを使ってアプリケーションを公開する方法を理解している PersistentVolumeClaimを用いて永続ストレージを提供できる この目標は非常に重要であるため、概念の理解だけでなく、Kubernetesクラスターを使った実践的な演習にも十分な時間を割く必要があります。 YAMLファイルを用いたKubernetesリソースの宣言 Kubernetesのリソースは通常、YAMLファイルを用いた宣言的な方法で定義されます。これらのファイルはシステムの「望ましい状態」を記述し、Kubernetesは実際の状態がその定義と一致するように管理します。この宣言的な構成により、バージョン管理、再現性、自動化といったDevOpsの重要な原則を実現できます。 一般的なKubernetesのYAMLファイルには、以下の要素が含まれます。 apiVersion：Kubernetesコントローラと通信するAPIのバージョン kind：リソースの種類 metadata：名前やラベルなどのリソース情報 spec：望ましい状態の定義 以下はシンプルなPod定義の例です。 apiVersion: v1 kind: Pod metadata: name: my-pod labels: app: web spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 リソースを作成するには、次のコマンドを実行します。 $ kubectl apply -f pod.yaml Podの基本概念 PodはKubernetesにおける最小のデプロイ単位です。1つ以上のコンテナをまとめた単位であり、以下を共有します。 同一のネットワーク名前空間（IPアドレスやポート） 共有ストレージボリューム ライフサイクル管理 Podは本質的に一時的（エフェメラル）な存在であり、通常はDeploymentなどの上位コントローラによって管理されます。 以下は複数コンテナを持つPodの例です。 apiVersion: v1 kind: Pod metadata: name: multi-container-pod spec: containers: - name: app image: myapp:1.0 - name: sidecar image: log-collector:1.0 このYAMLでは、同一環境内で2つのコンテナが動作します。 appコンテナ：メインアプリケーション（myapp:1.0） sidecarコンテナ：ログ収集などの補助機能（log-collector:1.0） 両コンテナはlocalhostで通信可能で、ストレージも共有できます。この構成は「サイドカーパターン」と呼ばれます。 Deploymentの利用方法 DeploymentはPodを管理し、常に指定された数のレプリカが稼働するようにします。主な機能は以下の通りです。 宣言的アップデート 自己修復（Podの再作成） スケーリング ローリングアップデートおよびロールバック 例： apiVersion: apps/v1 kind: Deployment metadata: name: web-deployment spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: [...]

本記事は、現代のデータ収集について扱う連載の一部です。これまでの記事では、さまざまな機関において情報の侵入がいかに広範に行われているかを示してきましたが、今回は多くの人が特に注目する「政府」に焦点を当てます。 このセクションは、1970年代にさかのぼるあるエピソードから始めます。私の友人2人が結婚予定を住んでいた町の役所に届け出ました。これは、結婚を法的に認めてもらうために誰もが行う通常の手続きです。ところがその後すぐ、地元の百貨店から結婚登録（ウェディングレジストリ）を勧める案内が届き始めました。百貨店が彼らの婚約を知る手段は、町の役所以外には考えられません。つまり、地方自治体が住民に提出を義務付けた情報を利用し、それを収益化していたということです。 以前にも触れたように、政府は人権活動家やテロリストといった「敵」を特定するために高度な監視を行います。しかし、この結婚の例が示す通り、政府は日常業務の中で、私たち一人ひとりに関するごく一般的な情報も大量に記録しています。各種登録制度は、私たちが政府に提供しなければならない情報の多さを思い出させます。その一部を挙げると、次のようなものがあります。 世帯構成員（年齢、人種、退役軍人かどうかなどの詳細情報） 学齢児童（健康診断や予防接種の情報など） 土地、住宅、その他の建築物、および大規模な建設工事 税申告書に記載される収入などの情報 性犯罪に関する情報 自動車 銃器 結婚 犬、場合によっては猫 さらに、次のような情報も記録されます。 政府が提供する医療保険に関連する健康情報 投票行動や政治献金を含む政治活動に関する情報 軍歴 カメラによって収集される自動車や歩行者に関する情報 実際のところ、米国政府は多くの納税者について、税額を自動計算できるほどの情報を把握しています。多くの国ではすでにそのような仕組みが存在します。それにもかかわらず、何億人ものアメリカ人が毎年手作業で申告書を作成しなければならないのは、強力な税務申告業界によるロビー活動の影響が大きいとされています。 政府が一般市民や居住者から収集するデータの包括的な一覧については、Privacy.Netの記事やElectronic Privacy Information Center（EPIC）のサイトが参考になります。政府が記録している情報の一部を簡単に挙げると、次の通りです。 基本的な個人情報（氏名、住所、生年月日、社会保障番号など） 生体情報（指紋、顔認識画像、DNA、虹彩スキャンなど） 移民関連情報（渡航履歴、移民申請時に提出された詳細情報） 法執行関連情報（通話記録、交友関係や家族関係、鑑識情報、裏付けのない告発など） 情報機関による情報（秘密裏の活動で得られた情報） こうしたデータが、政府にとって好ましくない人物の特定や訴追に利用される可能性については、多くの懸念が指摘されています。 また、政府が収集した情報の一部は公開されます。米国では、どの政党に投票したかという情報や政治献金は公開情報です。このようなオープンデータは透明性の確保に役立ちますが、地域によっては警察に通報しただけでも、その情報が公開される場合があります。 影響が過大に語られがちなデータ収集の例として、中国の「社会信用システム」があります。確かに、これはさまざまな情報源から住民のデータを一元化する仕組みです。しかし主な用途は企業に対するものであり、食品汚染などの問題を防ぐことが目的とされています。 この社会信用制度については、人材関連企業RemotePadが公開している約1時間のレポート動画を強くおすすめします。同社が香港に拠点を置いているため視点に偏りがある可能性はありますが、制度の実態について非常に詳細に解説されており、信頼できる内容となっています。 本連載の最終回では、雇用主によるデータ収集を取り上げ、現代におけるプライバシーの全体像について総括します。 << 本シリーズの前回記事を読む | 次回記事を読む >>

関数型プログラミングは、プログラミング言語を分類するうえでの基本的な区分のひとつであり、その起源はプログラミングの初期にまでさかのぼります。特にLISPやMLが代表的です。本シリーズでは、現代の関数型言語の主要な提唱者へのインタビューを通じて、その重要性や影響を探ります。 私たちの多くは、命令型言語でプログラミングを学びました。そこでは、レシピのように1つの文が次の文へと順番に実行されます。ループは繰り返し処理を行い、if文は分岐を可能にします。また、あらかじめ定義された処理を再利用するために、文は関数やサブルーチンとしてまとめられます。 命令型や関数型に加えて、プログラミング言語のもうひとつの大きな分類が宣言型プログラミングです。その代表例がPrologです。宣言型プログラミングでは、プログラマや管理者がシステムの「望ましい状態」を定義し、プログラムがその状態を実現します。この手法は、Ansibleのような現代のシステム管理ツールで広く使われており、多くの場合YAMLファイルが用いられます。 現在でも比較的新しいとされる関数型言語には、以下のようなものがあります。 Erlang（1980年代後半に開発） Haskell（1980年代後半〜1990年代初頭に開発） OCaml（1996年に公開） F#（2002年、Microsoftによる参入） Scala（2004年に公開） これらの言語は話題になることは多かったものの、大規模な普及には至りませんでした。私が勤務していたO'Reilly Mediaでも、これらの言語に関する書籍を出版していました。本シリーズでは、その当時O'Reillyと関わりのあった著者たちにインタビューを行っています。本シリーズでは、これらの言語がどのように使われているのか、関数型プログラミングがコンピュータサイエンス全体にどのような貢献をしてきたのか、そしてその間にプロのプログラミングがどのように変化してきたのかを見ていきます。 本シリーズでは、関数型プログラミングの革新的な特徴を2つのカテゴリーに分けています。ひとつは主に構文的で学びやすい特徴で、これらは命令型言語にも取り入れられてきました。もうひとつは本質的な特徴であり、関数型プログラミングを関数型たらしめている要素です。この後者は、命令型プログラミングとは概念的に大きく隔たっています。 こうした歴史を踏まえ、インタビューした専門家の中には、自分たちの言語（ひいては関数型言語全般）を「プログラミングの実験場」と捉える人もいます。新しいアイデアを発見し、それを外の世界へ提供する場というわけです。O'Reillyの書籍『Erlang Programming』や『Designing for Scalability with Erlang/OTP』の著者であるFrancesco Cesariniは、すべてのコンピュータサイエンス教育課程で関数型プログラミングが教えられるべきだと考えています。 関数型プログラミングの背景 「関数型プログラミング」という用語はどこから来たのでしょうか。あるAI検索では「1960年代の研究の一環としてPeter Landinがこの用語を作った」とされていますが、その出典は確認できませんでした。別の検索では「この用語の発明者として特定の人物はいない」とされています。 ここで関数型プログラミングの厳密な定義を行うつもりはありませんし、「純粋関数型かどうか」といった不毛な議論に立ち入るつもりもありません。 本質的には、関数型プログラミングの理念は「副作用を持たないこと」です。他の言語では、関数内で変数の値を変更したり、関数外にグローバル変数を定義したりできます。一方、関数型プログラミングでは、関数は値を返すこと以外に影響を持ちません。Haskellコンパイラ（Glasgow Haskell Compiler）の開発に長年携わってきたSimon Peyton Jonesは、次のように説明しています。 「関数型プログラミング（数学と同様）では、変数は値を表します。一方、命令型プログラミングでは、変数は変更可能な記憶領域を指し、その値は時間とともに変化します。」 実用面では、関数型モデルは2つの重要な概念を導入します。それは「不変（イミュータブル）な変数」と「非同期通信」です。変数が変更されないと分かっていれば、コンパイラはより効率的に処理をスケジュールできます。また、非同期通信はロックやバリアを不要にし、並行処理を容易にします。 これに対して命令型言語は、変更可能な変数に依存しています。関数は変数を書き換えることで状態を表現し、それが関数間のコミュニケーション手段となります。 （ストレージなどにおける不変性の広範な活用については、ACM Queueの古典的な記事が参考になります。） もちろん、関数型プログラムも最終的には結果を出力したり、外部に影響を与えたりする必要があるため、「副作用なし」という原則を完全には守れません。ファイルへの書き込みやネットワーク送信などは不可避です。しかし、特にHaskellのIOシステムやErlangのI/Oプロトコルでは、副作用を伴う処理とそうでない処理を厳密に分離します。ほとんどの関数は純粋であり、外部に影響を与えません。関数型言語は、The Whoの『Tommy』に登場する「目も耳も口も不自由だがピンボールは得意な少年」にたとえられるかもしれません。 ダンス会場の壁の花 過去数十年にわたる関数型言語の人気については、十分な情報が得にくいのが現状です。TIOBEインデックスは長期的な統計を公開していますが、対象はわずか10言語で、本記事で扱う言語は含まれていません。Redmonkのランキングでも、過去14年間で言及されているのはScalaのみです。 現在の人気については、ZDNETの2024年ランキングやIEEE Spectrum、Statistaの2025年調査などで確認できますが、本シリーズで扱う言語はいずれも上位には登場しません。 比較のために見ると、Visual Basic、Fortran、Adaといった一部では時代遅れと見なされる言語の方が上位にランクインしています。これは、既存の利用基盤が大きいことが理由でしょう。 しかし、人気は言語の価値を測る適切な指標ではありません。JavaScriptやTypeScriptはWebページ表示のために設計されているため人気がありますが、ニッチな用途で高い価値を持つ言語も存在します。 Scala Scalaは、本シリーズで取り上げる言語の中では比較的多くの利用者を獲得しました。これは、ScalaがJava仮想マシン（JVM）上で動作するバイトコードにコンパイルされるためです。同様の言語としてKotlin、Clojure、Groovyなどがあります。Javaと同じ環境で動作するため、長年蓄積されたJavaライブラリを活用できる点が大きな利点です。 ただし、関係者によればScalaの人気はピークを過ぎているとされています。Redmonkランキングでは一定の地位を維持していますが、勢いは落ちています。 『Programming Scala』の著者であるDean Wamplerは、Scalaを「研究的な言語」と位置づけています（Haskellも同様です）。そのため、改善のために後方互換性が犠牲になることもありますが、これは大規模に普及した言語では避けられる傾向があります。 Scalaは当初、Javaの冗長さに不満を持つ開発者に支持されました。「Javaが停滞していた時期に、Scalaでは1行で書けるクラスがJavaでは20行必要だった」とWamplerは述べています。その簡潔さは衝撃的でした。しかし、Java 8でラムダ式などの関数型機能が導入されたことで、Scalaの優位性は相対的に低下しました。 現在では、Scalaは「言語好きのための言語」となっています。特にAI分野では豊富なライブラリが利用できるため、強力な言語よりもPythonのようなシンプルな接着言語で十分だと指摘されています。 Haskell Peyton JonesもHaskellを「実験場」と見なしており、必要に応じて後方互換性を犠牲にすることを認めています。コミュニティが密接である限り、柔軟な進化が可能です。ただし、普及が進むにつれて互換性への配慮も強まっています。 Haskellは革新の源泉としての役割を今後も担い続けると期待されています。たとえば、Peyton Jonesが開発したトランザクショナルメモリは、複数操作の原子性を保証するだけでなく、ミューテックスなしでスレッド同士の待機を可能にします。この機能は非常に有用で、Microsoftが.NETへの導入を試みたものの、命令型言語では実現が困難だったといいます。 また、Haskellには一般化代数的データ型（GADT）といった高度な機能もあり、これは強力な型システムに支えられています。 Erlang Cesariniは、関数型言語がそれほど普及しない理由として、その有用なアイデアが他の言語に取り込まれている点を挙げています。 現在、多くの開発者がErlang仮想マシン上で動作するElixirを利用しています。Elixirの周辺では活発な開発が行われており、WebフレームワークのPhoenixは「21世紀のRuby on Rails」とも呼ばれています。また、AI向けのNumerical Elixirや、組み込み向けのNervesプロジェクトも注目されています。 本シリーズの第2回（最終回）では、命令型言語がどのように関数型の概念を取り入れてきたか、ただしその本質までは取り入れていない点について見ていきます。また、プログラミングの未来についての考察も提示します。

これまでのDevOpsツールに関する解説では、コンテナ仮想化と、それによってアプリケーションのパッケージ化やデプロイ方法がどのように変革されたかを見てきました。コンテナの大きな利点のひとつは、従来の仮想マシンと比較してリソースのオーバーヘッドが非常に小さいにもかかわらず、起動が非常に高速である点です。コンテナはホストOSのカーネルを共有するため、数秒で起動でき、同一のインフラ上で多くの分離されたワークロードを効率よく実行できます。 しかし、コンテナによってアプリケーションのパッケージ化や実行は簡素化された一方で、複数のサーバーにまたがる大量のコンテナを管理することは急速に複雑になります。現代のアプリケーションは、数十、場合によっては数百のコンテナで構成され、それらをスケジューリングし、監視し、障害時には再起動し、需要に応じて動的にスケールさせる必要があります。これらの作業を手動で行うことは、本番環境では現実的ではありません。 この課題を解決するために登場したのが、コンテナオーケストレーションプラットフォームです。これらは、複数のマシンからなるクラスター上で、コンテナのデプロイ、スケーリング、ネットワーク管理、ライフサイクル管理を自動化することを目的としています。その中でも、Kubernetesはコンテナ化されたワークロードのオーケストレーションにおいて、最も広く採用されているソリューションとなっています。 KubernetesはもともとGoogleによって開発され、その後Cloud Native Computing Foundationに寄贈されました。分散されたコンテナアプリケーションを信頼性高く大規模に管理できる、強力かつ拡張性の高いアーキテクチャを提供しています。 Pods, Services, Deployments,controllersといった概念を導入することで、管理者やDevOpsエンジニアはインフラの「望ましい状態（Desired State）」を定義でき、プラットフォーム側がその状態を維持するよう継続的に制御します。 本章では、Kubernetesのアーキテクチャ、クラスターの主要コンポーネント、そしてkubectlなどのツールを使ってクラスターの状態を確認し、リソースを管理する方法について解説します。 Kubernetesクラスターのアーキテクチャ Kubernetesクラスターは、2つの主要な要素から構成される分散システムです。 コントロールプレーンはクラスターを管理しスケジューリングを行い、ワーカーノードはアプリケーションのワークロードを実行します。 このアーキテクチャにより、Kubernetesはアプリケーションの望ましい状態を維持できます。管理者はサーバー上で手動でプロセスを起動する代わりに、意図する構成を宣言するだけで、Kubernetesがその状態に一致するようクラスターを自動的に調整します。 コントロールプレーンの主要コンポーネント コントロールプレーンには、クラスター管理とオーケストレーションを担う重要なコンポーネントが含まれます。 API Server Kubernetes API Server（kube-apiserver）は、クラスターの中心となる通信ハブです。管理者がkubectlや内部コンポーネント、各種自動化ツールを通じて行うすべての操作は、このAPIを経由します。 主な役割は以下の通りです。 Kubernetes REST APIの公開 リクエストの認証および認可 リソース定義の検証 クラスター状態のetcdへの保存 クラスターへの入口となるため、ステートレスなサービスとして設計されており、水平スケーリングが可能です。 etcd etcdは、Kubernetesの永続ストレージとして使用される分散型キーバリューデータベースです。設定情報、ノード情報、リソース定義など、クラスターに関するすべての情報を保存します。 Pod、Deployment、Serviceなど、すべてのKubernetesオブジェクトはetcdに記録されます。そのため、etcdはクラスターの「唯一の信頼できる情報源（Single Source of Truth）」となります。 etcdが利用できなくなると、すでに動作中のワークロードは継続する可能性がありますが、新規作成や更新などの変更は行えなくなります。 Controller Manager Controller Manager（kube-controller-manager）は、複数のコントローラーを実行し、クラスターの状態を継続的に監視して、望ましい構成を維持します。 コントローラーは「リコンシリエーションループ」を実装しており、実際の状態と望ましい状態を繰り返し比較し、差異があれば修正を行います。 主なコントローラーの例： Node Controller ReplicaSet Controller Deployment Controller Service Controller これにより、ワークロードの可用性と一貫性が保たれます。 Scheduler Kubernetes Scheduler（kube-scheduler）は、新しく作成されたPodをクラスター内のどのノードで実行するかを決定します。リソースの空き状況や制約、ポリシーを考慮して最適なノードを選択します。 主な判断基準： CPUやメモリの空き状況 ノードアフィニティルール テイントとトレラント ワークロードのバランス ワーカーノードの構成要素 ワーカーノードはアプリケーションのワークロードを実行し、通常は以下のコンポーネントを含みます。 kubelet：コントロールプレーンと通信するノードエージェント コンテナランタイム：containerdやDockerなど kube-proxy：ネットワークおよびサービスルーティングを担当 これらにより、Podの実行と状態報告が可能になります。 kubectlの設定 kubectlは、Kubernetesクラスターと通信するためのコマンドラインツールです。APIサーバーと連携し、リソースの管理やクラスター状態の取得を行います。 設定は通常、~/.kube/config ファイルに保存され、以下の情報を含みます。 クラスターのエンドポイント 認証情報 コンテキスト ネームスペース 設定の管理には kubectl config コマンドを使用します。 kubectl get リソース情報の取得は、Kubernetes操作の中でも最も基本的な作業です。 例： $ kubectl get pods $ kubectl get [...]

金曜の夕方。あなたがオフィスを出ようとしたそのとき、あの嫌な電話が鳴ります。「本番サーバーが応答しません。確認できますか？」 社内VPNに接続しますが、2分おきに切断されてしまいます。3時間後も、実際の問題解決ではなくネットワーク設定と格闘している状態です。 こうした日常的なストレスが、何千人もの開発者やシステム管理者に代替手段を探させてきました。そこで登場するのがNetBirdです（図1）。 [caption id="attachment_36861" align="aligncenter" width="1920"] 図1：接続済みピア、分かりやすい名前、接続状態を表示するNetBirdのダッシュボード[/caption] 実際に機能するネットワーク NetBirdは、見た目だけを改良した単なるVPNではありません。トラフィックを中央のボトルネックに通すのではなく、デバイス同士が直接通信するメッシュネットワークを構築します。 仕組みは、エージェントをインストールした瞬間から動き出します。手動設定や.ovpnファイル、ポートフォワーディングは不要です。新しいデバイスは、自動的に許可されたすべてのピアからアクセス可能になります。 設定ゼロで最大のセキュリティ 自宅ラボを考えてみてください。監視用のRaspberry Pi、バックアップ用のNAS、あるいはJellyfinサーバーなどがあるかもしれません。通常であればポート開放やDDNS設定、IPアドレス変更への対応が必要です。 しかしNetBirdなら、その複雑さは消えます。すべてのデバイスに分かりやすい名前と固定IPアドレスが割り当てられます。 Grafanaのダッシュボードを確認したい場合も、もはやssh -L 3000:192.168.1.15:3000のようなコマンドは不要です。ブラウザで grafana.superkali.lan を開くだけでアクセスできます（図2）。NetBirdのプライベートDNSにより、まるで常に自宅ネットワーク内にいるかのように利用できます。 [caption id="attachment_36871" align="aligncenter" width="1920"] 図2：ブラウザでgrafana.superkali.lanにアクセスし、Grafanaが表示されている様子[/caption] 分散チームのためのツール リモートチームでの作業にも最適です。例えば、あなたのノートPC上のPostgreSQLデータベースを、ベルリンのデザイナーのMacBookやAWS上のステージングサーバーから簡単に利用できます。 セットアップキーを使えばオンボーディングも瞬時です。新しい開発者にはキーを渡すだけ。エージェントをインストールすれば、数秒で内部サービスにアクセス可能になります。チュートリアルもサポートも不要、「自分の環境では動くのに…」といった問題も減少します。 インテリジェントなP2P接続 従来のVPNがすべての通信を中央サーバー経由で処理するのに対し、NetBirdはWebRTC技術を使ってデバイス同士を直接接続します。これはビデオ通話にも使われている技術です。NATやファイアウォールを自動的に突破し、ピアツーピア接続を確立します（図3）。 [caption id="attachment_36881" align="aligncenter" width="1920"] 図3：NetBirdによる直接のピアツーピア接続[/caption] ただし、モバイルネットワークや厳しい企業ファイアウォールなどでは直接接続が失敗する場合もあります。その場合はリレーサーバーにフォールバックしつつ、WireGuardによるエンドツーエンド暗号化を維持します。リレーは暗号化されたデータを中継するだけで、中身を読むことはできません。 内部では、WireGuard（暗号化）、Pion ICE（WebRTC）、Coturn（NAT越え）、Rosenpass（耐量子暗号）などが使われています。また、Google Workspace、Okta、ZitadelなどとのSSOやMFAにも対応しています。 オープンソースと柔軟な料金体系 NetBirdはオープンソース（BSD-3-Clause/AGPLv3）です。セルフホストなら完全無料で制限もありません。クラウド版は5ユーザー・100デバイスまで無料、それ以上は1ユーザーあたり月額5ドルです。 細かなアクセス制御 アクセス管理はIPアドレスではなく、論理グループで行います。例えば「開発者はステージングにはアクセス可能だが本番には不可」といった設定も、グループとポリシーで簡単に実現できます（図4）。 [caption id="attachment_36891" align="aligncenter" width="1920"] 図4：グループ管理インターフェース[/caption] この制御はネットワークレベルで適用され、アプリごとの設定は不要です。NetBirdはアイデンティティと権限を理解するスマートファイアウォールを備えています。 オープンに開発されるプロジェクト NetBirdは、エンタープライズ向けネットワークの複雑さに不満を持ったエンジニア、Misha Bragin氏とMaycon Santos氏によって生まれました。 「誰でも設定の専門家にならずに安全なネットワークを使えるべき」という理念のもと開発されています。 GitHubでは1万以上のスターを獲得し、コミュニティも活発です。耐量子暗号の対応などはユーザーの要望から追加されました。オープンソースであるため、特定ベンダーに縛られることもありません。 実際のパフォーマンス 性能は重要です。従来のVPNで10GBのバックアップをNASに転送した場合は18MB/sでしたが、NetBirdの直接接続では95MB/sに達しました。中央ゲートウェイではなく、実際の回線速度がボトルネックになります。 通常の環境では、80〜90%の接続が直接P2Pで確立されます。つまり、ほとんどの通信は最大速度でやり取りされます。 ネットワークの未来 NetBirdは、「セキュアなネットワークは自然に動くべき」という未来を体現しています。iptablesの知識は不要で、デバイスの追加も数秒で完了します。 3か月前まではVPN設定の維持に週末を費やしていましたが、今ではプロジェクト開発に時間を使えています。優れたインフラとは、意識せずに使えるものです。 分散チーム、自宅ラボ、企業インフラのいずれにおいても、NetBirdは「本来存在すべきでない問題」を解消します。VPNがボトルネックであってはなりません。 試してみませんか？セルフホスト版のNetBirdは完全無料のオープンソースで、セットアップはこの記事を読むより短時間で完了します。

SCALE 23xは、2026年3月6日から8日にかけてカリフォルニア州パサデナで開催され、北米のオープンソースコミュニティが一堂に会する、地域最大級のコミュニティ主導型Linuxカンファレンスの一つとなりました。本イベントでは、Linuxシステム管理、セキュリティ、コンテナ化、コミュニティガバナンス、そして新興技術に関する多数のセッションが実施されました。 LPIはブース出展および講演セッションで参加しました。Jon “maddog” Hall（名誉理事長）は、量子耐性セキュリティと高等教育におけるオープンソースに関する2つの講演を行いました。また、Matthew Rice（LPIエグゼクティブディレクター）およびTed Matsumura（LPIチャンピオン兼理事）とともに、会期中はブース対応を行いました。 ブースでの交流と認定資格の動向 LPIのブースには、既存の認定資格保有者と今後取得を検討している来場者の双方から、継続的に多くの来訪がありました。来場者の中には、CompTIA Linux+のホワイトラベル提携時代である2013年頃の資格を含め、すでにLPI認定を保有している方も多数見られました。こうした対話を通じて、LPI認定資格が10年以上にわたりLinuxエコシステムにおけるキャリア形成をどのように支えてきたかについて、貴重な知見が得られました。 同様に重要だったのは、今後の認定取得に関心を示す来場者の多さです。多くの参加者が「同僚にもLPI資格を勧めたい」と述べており、専門家ネットワーク内での口コミによる自然な広がりが見て取れました。 また、ブースは高度な技術者との議論の場としても機能しました。長年の経験と深いLinuxの専門知識を持つ来場者からは、業界の最新ニーズや技術動向に関する有益な意見が寄せられ、LPIの取り組みが幅広いスキルレベルにおいて重要であることが示されました。 展示会場では、小規模なオープンソースプロジェクトから大手テクノロジー企業、コミュニティ活動、教育プログラムまで、現代のLinuxエコシステムの広がりが示されていました。この多様性により、教育関係者やトレーニング機関、コミュニティリーダーと認定資格の活用について議論する機会も生まれました。 国際的な広がり 本カンファレンスは、LPIの国際的な活動範囲も強く印象づけました。イタリアからの複数の参加者グループが来場し、その中にはMoreno Razzoli（Morrolinuxの名で動画やLPIブログを発信）による教材を学習している学生も含まれていました。こうした交流は、ある地域で作成されたコンテンツが世界中のLinux教育に貢献していることを実感させるものでした。 また、カリフォルニア北部のSLAC国立加速器研究所の関係者もブースを訪れ、将来的な施設見学の招待が行われました。 カンファレンスの特徴と運営 SCALEは草の根的な雰囲気を保ちながらも、インフラ自動化、クラウドネイティブコンピューティング、組み込みシステム、セキュリティといった現代的な技術課題に対応していました。講演だけでなく、廊下やブース、さらにはGame Nightのようなコミュニティイベントを通じた非公式な交流の機会も豊富に用意されていました。 Ilan Rabinovitch氏とSCALEのボランティアチームは、会場運営を非常に効率的に行い、セッション会場や展示スペースの管理、細部への配慮により、複数日にわたるイベントを円滑に進行させました。 技術領域の広がり 各セッションでは、従来のサーバー用途にとどまらないLinuxの役割の拡大が取り上げられました。組み込みシステム、AIインフラ、エッジコンピューティング、サイバーセキュリティなど、いずれの分野においてもLinuxは基盤技術として重要な役割を担っています。この幅広い適用範囲は、多様な技術領域で活躍できるLinux人材の育成が不可欠であることを改めて示しました。 成長を続けるオープンソースコミュニティ SCALE 23xは、Linux人材育成および認定資格に対する強い需要が現在も続いていることを裏付けるものとなりました。長年の資格保有者と新たな受験希望者が共存する状況は、LPI認定資格の持続的な価値と今後の成長可能性の両方を示しています。 LPIにとって本カンファレンスは、北米のオープンソースコミュニティとの有意義な交流の場であると同時に、変化する技術環境において認定資格がキャリア形成をどのように支えているかについての貴重なフィードバックを得る機会となりました。

この記事は、現代のデータ収集について解説する連載の一部です。これまでの記事では、各種デバイスによるデータ収集や、小売業者や銀行といった機関による収集について取り上げてきました。 これまで見てきたように、実店舗やオンラインで利用する小売業者は、顔認識から閲覧したウェブページに至るまで、あらゆる情報を活用して私たち個人をより深く理解しようとしています。こうした動きに不快感を覚える人も多いですが、現代の商取引においては避けがたい側面となっています。 実は多くの場合、教会も同様のことを行っています。何千もの教会が、自らの信徒やウェブサイト訪問者に対してマーケティングを行い、関心を引くコンテンツを提供しようとしています。この分野に特化した企業も急速に成長しています。教会は、あなたがいつ出入りしたのかを把握し、オンライン上では不安や抑うつといった状態まで推測し、それに応じたウェブページを表示して、さらに関与を深めようとします。 小売業者と同様に、教会も個人単位のデータと集計データの両方を利用しています。集計データは比較的無害であり、たとえば礼拝の参加人数を予測するなど、運営計画に役立ちます。一方で、個人データの利用については疑問を感じる人もいるでしょう。たとえば、教会があなたの落ち込みを検知して励ましのメッセージを送ってきた場合、そのメッセージがあなたの精神状態に関する詳細な情報に基づいていることに気づかないかもしれません。そのメッセージは慰めとなる一方で、教会側にとっては、さらなる活動参加を促すという目的も持っています。 この連載の次回では、ついに最も大きく、最も強力な存在である「政府」によるデータ収集について取り上げます。 << 本シリーズの前回の記事を読む ｜ 次回の記事を読む >>