検索結果

関数型プログラミングは、プログラミング言語を分類するうえでの基本的な区分のひとつであり、その起源はプログラミングの初期にまでさかのぼります。特に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にとって本カンファレンスは、北米のオープンソースコミュニティとの有意義な交流の場であると同時に、変化する技術環境において認定資格がキャリア形成をどのように支えているかについての貴重なフィードバックを得る機会となりました。

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

2026年3月12日、カナダ・オンタリオ —Linux Professional Institute（LPI）は、新たに公開した年次レビューにおいて、2025年の主な成果と取り組みを発表しました。本レポートでは、DevOps Tools Engineer 2.0認定の正式リリース、ラーニングマテリアルの新たな翻訳、認定取得者向けデジタルバッジの導入、ガバナンスの取り組み、グローバルパートナーシップの拡大、各種イベントなどが紹介されています。レポートはLPIのWebサイトからPDF形式でダウンロードできます。 2025年におけるLPIの大きなマイルストーンの一つは、大幅に改訂されたDevOps Tools Engineer 2.0認定のリリースです。更新版では試験構成が現代化され、現在の求人市場で高く評価されるDevOpsツールやスキルに重点を置きつつ、LPIの中核であるオープンソースの理念を維持しています。 世界中の学習者を支援するため、グローバルな非営利団体であるLPIは、更新された試験に対応した無料のラーニングマテリアルを、同団体の学習プラットフォーム（learning.lpi.org）で公開しました。また、翻訳プロジェクトも引き続き進展し、Security Essentials試験向けにスペイン語およびポルトガル語の無料教材が、Open Source Essentials試験向けに日本語およびベトナム語の無料教材が提供されました。 同年初めには、LPIはCredly（Pearson提供）と提携し、認定取得者向けのデジタルバッジを導入しました。これらのバッジは、メール署名、デジタル履歴書、さらにはLinkedIn、Facebook、XなどのSNSプロフィールに追加することができ、求職者としての可視性を高め、企業からの注目を集めるのに役立ちます。 2025年は、LPIのガバナンスにとっても重要な年となりました。新たな理事が選出され、さまざまな国や文化、視点を代表する13名からなる多様性に富んだ理事会が構成されました。この多様性は、「オープンソースに関わる人々を支援することで、その利用を促進する」というLPIの使命をさらに強化するものです。この使命はグローバルなものであり、特にIT分野で十分に代表されていない地域への支援にも力を入れています。 また、Open Source JobHubとの協力により、LPIは「Open Source Professionals Job Survey Report」の第2版を発表しました。528名のオープンソース専門家からの回答に基づくこのレポートは、採用担当者がオープンソースコミュニティのニーズにより適した職務設計を行うための示唆を提供しています。第3回調査に基づくレポートも、近日公開予定です。 年次レビューでは、新たに開始された「Become a Partner」ポータルも紹介されています。このポータルは、企業や団体がLPI公式パートナーとして申請するための主要な窓口となります。さらに、パートナーシップ、メンバーシップ、ボランティア活動、そして2025年にLPIチームが参加したイベントに関する最新情報も掲載されています。 2025年を通じて、LPIは43の国際的イベントを支援しました。これにはニューヨークで開催された「United Nations Open Source Week」も含まれます。また、「Software Freedom Day 2025」の成功にも貢献し、コミュニティ主導のオープンソース活動の世界的な広がりを後押ししました。 LPIのエグゼクティブディレクターであるG. Matthew Riceは、次のように述べています。「ボランティア、パートナー、理事、スタッフを含むコミュニティの皆さまが、フリーおよびオープンソースソフトウェアの分野でキャリアを目指す人々を支援し続けてくださっていることに、心より感謝いたします。今後もLPIは、オープンソーススキルを通じて、世界中のより多くの人々を支援していきます。」 2025年年次レビューは以下よりダウンロードできます：https://www.lpi.org/AR2025 Linux Professional Institute（LPI）について Linux Professional Institute（LPI）は、オープンソース分野の専門家に向けたグローバルな認定基準およびキャリア支援を提供する組織です。35万人以上の認定取得者を擁し、ベンダーニュートラルなLinuxおよびオープンソース認定機関としては世界初かつ最大規模を誇ります。LPIは180か国以上で認定を行い、多言語で試験を提供するとともに、数百のトレーニングパートナーと連携しています。詳しくは www.lpi.org をご覧ください。 メディア連絡先 Shamiul HossainCommunicationsLinux Professional Institute（LPI）shossain@lpi.org

Dockerはコンテナの起動や管理を容易にしますが、そのコンテナを実行するための基盤となるシステムは依然として必要です。これらのシステムはコンテナが稼働するインフラストラクチャを構成し、DevOps Tools Engineer試験の目的702.3で扱われています。 コンテナイメージは、現代のクラウドネイティブなインフラストラクチャの基盤です。アプリケーションを実行環境、依存関係、設定とともにパッケージ化し、移植性と再現性を確保する手段を提供します。Docker、Podman、その他OCI準拠ツールを扱うDevOpsエンジニアにとって、イメージの作成方法、安全な管理、適切な配布方法を理解することは不可欠です。 コンテナイメージの作成は、Dockerfile（Podman環境ではContainerfile）から始まります。このファイルには、イメージのビルド方法が宣言的に記述されます。たとえば、シンプルなNode.jsアプリケーションでは、FROM node:25-alpineのようにFROM命令でベースイメージを指定することから始まります。この記述は、既存のOCI準拠イメージを基盤として使用することを意味します。 その後の各命令は新しいイメージレイヤーを作成します。WORKDIRはコンテナ内の作業ディレクトリを指定し、COPYはアプリケーションのソースコードをイメージに取り込み、RUNはnpm installなどのコマンドを実行します。最後に、CMDまたはENTRYPOINTによってコンテナ起動時の動作が定義されます。 最小構成の例は以下のとおりです。 FROM node:20-alpine # コンテナ内の作業ディレクトリを設定 WORKDIR /app # ホストからアプリケーションファイルをコピー COPY . . # 依存関係をインストール RUN npm install # 使用するポートを公開 EXPOSE 3000 # アプリケーションを起動 CMD ["node", "server.js"] このイメージは軽量なAlpineベースのNodeイメージから開始され、作業ディレクトリを/appに設定し、アプリケーションファイルをコピー、依存関係をインストールし、node server.jsでサーバーを起動するように構成されます。 「docker build -t myapp:1.0 .」コマンドを実行すると、DockerはDockerfileを読み込み、myappという名前でタグ1.0のイメージを作成します。 タグの形式はOCIの命名規則に従い、通常は以下のように構成されます： [registry]/[namespace]/[repository]:[tag] たとえば、docker.io/library/nginx:latestは、Docker Hubレジストリ、library名前空間、nginxリポジトリ、latestタグを示します。 OCIイメージ名は標準化されており、異なるコンテナエンジン間でも互換性が保たれます。たとえば、ghcr.io/example/api:2.1は、レジストリ（GitHub Container Registry）、組織、リポジトリ、バージョンを明確に示しています。レジストリを省略した場合、DockerはデフォルトでDocker Hubを使用します。この命名構造を理解することは、異なる環境間でイメージを取得・タグ付け・プッシュする際に非常に重要です。 イメージをビルドした後は、他のシステムやデプロイメントパイプラインから利用できるようにレジストリへアップロードする必要があります。その際にはdocker loginで認証を行い、適切にタグ付けした後、docker image pushでアップロードします。 たとえば、myapp:1.0に対してregistry.example.com/team/myapp:1.0というタグを付与してプッシュすれば、CI/CDシステムやKubernetesクラスターから利用可能になります。レジストリにはDocker Hubのような公開型と、企業内で運用されるプライベート型があります。 セキュリティはコンテナイメージ管理において非常に重要です。コンテナイメージには、ベースイメージ由来の脆弱性や、アプリケーション依存関係による問題が含まれる可能性があります。 イメージスキャナは既知のCVE（共通脆弱性識別子）、古いライブラリ、不適切な設定を検出します。Trivy, Clair, Docker Scoutといったツールはイメージレイヤーを解析し、脆弱性データベースと照合します。たとえば、古いOpenSSLが含まれている場合、デプロイ前に警告が出され、修正済みの依存関係で再ビルドすることが可能になります。 コンテナ仮想化には固有のセキュリティリスクも存在します。コンテナはプロセスを分離しますが、ホストのカーネルを共有しています。そのため、rootで実行される不適切に設定されたコンテナは、カーネルの脆弱性を悪用したり、隔離を突破する可能性があります。 対策としては、USER命令で非rootユーザーを使用する、イメージサイズを最小化する、読み取り専用ファイルシステムを利用する、プロセスの権限を制限する、定期的にスキャンを行う、などが挙げられます。また、VOLUME命令はデータ漏えいを防ぐため慎重に使用する必要があります。EXPOSEはポートを文書化するだけであり、実際の通信制御はランタイム側で行う必要があります。 ビルド時のリスク軽減と性能向上のため、最新のコンテナエンジンは高度なビルダー機能を提供しています。Docker BuildKitは並列ビルド、レイヤーキャッシュ、シークレット管理により性能を向上させます。また、ビルド時にSSHキーを一時的にマウントし、最終イメージに残さないといった高度な構文もサポートしています。 Docker buildxはさらに拡張され、amd64やarm64など複数アーキテクチャ向けのイメージを同時にビルドできます。これはクラウドやエッジ環境などの異種混在環境において特に重要です。 Podmanではpodman buildコマンドを使用してContainerfileを読み込み、デーモン不要でOCI準拠イメージを作成します。Buildahはさらに細かい制御を可能にし、スクリプト化やrootlessビルドに対応します。これらのツールはLinuxのnamespacesやcgroupsと連携し、セキュリティ重視の設計となっています。 また、.dockerignoreファイルも重要です。これは不要なファイルや機密情報がイメージに含まれるのを防ぎます。たとえば、.gitディレクトリやローカル設定ファイル、認証情報などは除外することで、イメージサイズの削減と情報漏えい防止につながります。 まとめると、DockerfileおよびOCIイメージ管理を習得するには、技術面とセキュリティ面の両方を理解する必要があります。イメージの作成は単なるパッケージングではなく、不変で移植性のある成果物を構築し、それを最適化・バージョン管理・スキャン・安全に配布するプロセスです。 適切なDockerfile設計、レジストリ運用、脆弱性スキャン、BuildKitやbuildx、Podman build、Buildahといった最新ツールを組み合わせることで、DevOpsエンジニアは効率的かつ安全で本番運用に適したコンテナ環境を実現できます。 また、LPIはDevOps Tools Engineer 2.0試験向けの公式ラーニングマテリアルを提供しています。これらは包括的で無償公開されており、試験範囲に完全準拠した優れた学習リソースです。 << 本シリーズの前回の記事を読む | 次回の記事を読む >>

本シリーズの第1回では、機械学習やLLMにおけるベクターの役割と、ソフトウェアにおけるベクター表現について説明しました。本記事では、データベースの観点から、AIが直面する現代的な課題にどのように対応しているのかを概観します。 ベクターデータベース AIは本質的にベクターで構成されており、ベクターがAIそのものとも言えます。では、前回説明したようなベクター演算を中心に設計されたデータベースを使えばよいのではないでしょうか。過去10年ほどで、そのようなデータベースが数多く登場しています。代表的なオープンソースソフトウェアとしては、Milvus, Qdrant, Weaviate, Vespa, ChromaDB, LanceDB.などがあります。 これらのデータベースの違いは何でしょうか。いくつかの記事で比較されていますが、プロトタイプなどの小規模用途に最適化されたものもあれば、本番環境向けに設計されたものもあります。また、本シリーズ前回で述べたように、主要なAIサービスとの連携が重要であることから、各データベースは外部サービスとの統合機能でも競争しています。さらに、さまざまなインデックス方式やレプリケーションなどのデータ管理機能も提供されています。多くの企業がこれらのデータベースをクラウドサービスとして提供しています。 一方で、PostgreSQL内でベクター操作を扱うツールを提供するTigerData（旧Timescale）は、AI用途にベクターデータベースは適していないと主張しています。その主張の要点は、ベクターは通常、元となるコンテンツ（テキスト、音声、動画、化学・生物配列など）と一緒に参照されるという点です。したがって、多様なデータを一元的に管理するほうが合理的であるとしています。また、ベクターはデータベース用語でいう「派生データ」であり、元データの変更に応じて更新される必要があるため、元データから切り離されると価値が大きく低下すると指摘しています。 筆者はこの主張の妥当性について判断はしませんが、別の記事では従来型データベースとベクターデータベースのトレードオフがよりバランスよく論じられています。多くの組織では、外部のAIサービスを利用してベクターを生成し、その後は元データを保持しない、あるいは参照しないケースもあります。Weaviateのように、元データとベクターの両方を保存できるベクターデータベースも存在します。また、ベクターデータベースが特定の役割を非常に高い性能で果たすのであれば、他システムとの統合コストを考慮しても採用する価値はあるでしょう。 Tursoの創業者であるGlauber Costaは、元データに対するテキスト検索の方がベクター検索よりも優れた結果を出す場合があると指摘する専門家の意見も紹介しています。 最終的には、各組織が自らのニーズに応じて最適なデータベースを選択する必要があります。近年では、汎用データベースもAI対応を進めており、次にそれらを見ていきます。 ベクター操作のためのSQL SQLにおけるVECTORデータ型の登場により、リレーショナルデータベースもAI対応を進めています。MySQLおよびそのフォークであるMariaDBでは、ベクター間の距離を計算する基本機能が提供されています。AIコンサルティング企業Peripety LabsのCEOであるMark Hinkleによれば、現時点ではMariaDBの方がMySQLよりもベクター対応が進んでいるものの、どちらもまだ初期段階にあるとのことです。 MySQLやMariaDBがシンプルさを重視して設計されているのに対し、PostgreSQLは非常に多機能で、幅広い用途に対応できることを目指しています。SQLデータベースで実現したい機能があれば、PostgreSQLにはそれを実現する機能や拡張がほぼ存在すると言えるでしょう。 TigerDataが提供するpgaiおよびpgvectorという拡張機能は、PostgreSQLをAIの世界と接続します。pgaiは元データの変更に応じてベクターを自動更新し、pgvectorはベクター類似検索を提供します。 また、PostgreSQLはGPUによる高速化にも対応しています。TigerDataの資料では、ベクターデータベースよりも高速にベクター処理が可能であるとするベンチマーク結果も示されています。 さらに、TursoはSQLiteをベースに、ベクター列を持ち、データ更新時に自動でベクターを更新する新たなオープンソースデータベースを開発しています。 そのほか、YugabyteやClickHouseなども、SQLインターフェースとAI向け機能を兼ね備えたオープンソースデータベースとして注目されています。 ベクターデータベースを選ぶか、汎用データベースを選ぶかは、埋め込み（embedding）以外のデータ検索が必要かどうかによって判断されることが多いです。「ハイブリッド検索」と呼ばれる手法では、ベクター検索と従来の検索を組み合わせてデータを取得します。Open Tech StrategiesのKarl Fogelは、特定の高性能要件がない限り、ベクター機能を備えた汎用データベースを使うことを推奨しています。 その他の動向 AI分野に乗り遅れまいと、多くのデータベースが対応を進めています。よく言われる「乗り遅れるな」という表現の通り、あらゆる技術がこの分野に参入しています。 MongoDBは「Atlas Vector Search」を提供し、主要AIサービスと連携したデータ検索機能をアピールしています。ドキュメントには、データベースへのデータ格納例も掲載されています。NoSQL時代を代表するデータベースであるCassandraも、生成AIへの適用を打ち出しています。 テキスト検索分野で長い歴史を持つElasticsearchも、ベクターのインデックス作成・保存・検索を行う拡張機能を提供しています。 さらに、グラフデータベースもAI分野に進出しており、「Neo4j for GenAI」といった取り組みがその一例です。 AIエコシステム 「エコシステム」という言葉はやや使われすぎている感もありますが、さまざまなツールが連携して動作するAIの世界を表現するには適切な言葉です。特にオープンソースの分野では、多様なツールがそれぞれの役割を担い、アプリケーション全体を構成しています。 AIの本質は、非構造化データから有用な構造を生み出すことです。本記事が、構造化データがどのように現代のAIを支えているのかを理解する一助となれば幸いです。 << 本シリーズの前回記事はこちら

本記事は、現代のデータ収集について解説する連載の一部です。前回の記事では、小売業者がどれほど大量の情報を収集しているかを紹介しました。それと比べると、金融機関はかなり控えめに見えます。私が調べた資料の中には、銀行が顧客の性格や美的嗜好に興味を持っていると示すものはありませんでした。 一方で、銀行が収集する情報は、詳細な金融情報や機密性の高いデータであり、もし情報漏えいが発生した場合には、非常に大きな被害につながる可能性があります。例えば、「氏名、住所、電話番号、社会保障番号、納税者識別番号、セキュリティコードやアクセスコードを含まない金融口座情報、生年月日」などが含まれる場合があります。ただし、本記事では主にデータの本来の利用目的について説明しており、セキュリティ攻撃のリスクについては詳しく扱っていません。これらはまた別の重要な問題であり、悪用の可能性という新たな側面を加えるものです。 Equifaxの信用情報レポートには、破産歴の有無や、債務が回収機関に移管されたかどうかといった、客観的で妥当と考えられる情報が含まれています。また、Bank of Americaは、事業売上などの「現在の重要事項」に関心を持っていると述べています。 Consumer Financial Protection Bureau（米国消費者金融保護局）の文書のセクション2.2.1および3.1.2では、信用情報レポートに含まれる情報について説明されています。そこには、住宅ローンや雇用状況といった、ごく一般的な情報が記載されています。 金融機関が信用力（クレジットの信頼性）を評価する際に通常利用する情報には、次のようなものがあります。 雇用情報 住宅ローンに関する情報 債務回収、支払い遅延、民事訴訟、税金の差し押さえ、破産歴 クレジット口座の数や種類、利用可能な信用額、口座の保有期間 誰がその信用情報を照会したか 同一口座を共有している他の人物 業界では、こうしたレポートに誤った情報が含まれる可能性があることも認識されています。ある研究者は「消費者が確認した信用情報レポートの19.2％に、ヘッダー情報や取引履歴データの中に、消費者自身が不正確だと考える項目が少なくとも1つ含まれていた」と報告しています。 もちろん、信用力を評価するためのデータには多くの偏り（バイアス）が存在する可能性があります。こうした偏りは、住宅ローン、雇用機会、その他の重要な資源へのアクセスが制限されてきた人々の状況に由来します。例えば、2007年の米国のサブプライムローン危機では、過去のレッドライニング（住宅差別政策）や資産格差、その他の差別の影響により、黒人やラテン系の借り手が白人よりも大きな影響を受けました。 しかしながら、銀行によるデータの利用そのものは、比較的厳格に管理され、限定された範囲で行われているようです。 この連載の次回記事では、意外に思われるかもしれないある機関によるデータ収集とプライバシー侵害について取り上げます。 << 本連載の前回記事を読む ｜ 次回の記事を読む >>

Linux Professional Institute（LPI）は、2026年6月に開催予定の年次総会（AGM）をここに発表いたします。