検索結果

LPIとOSSMalta、マルタのオープンソース人材育成を推進するための覚書（MoU）を締結 マルタ・バレッタ／カナダ・オンタリオ、2026年6月10日 — オープンソース認定資格のグローバルスタンダードであるLinux Professional Institute（LPI）と、Open Source Society Malta（OSSMalta）は、このたび覚書（MoU）を締結したことを発表しました。 この画期的な合意は、オープンソース教育と需要の高いIT人材の育成を結びつけることで、マルタがグローバルなデジタル経済において成功を収めるための基盤を築くことを目的としています。 20年にわたるオープンソース推進の実績 今回のMoUは、マルタ諸島において20年にわたりオープンテクノロジーを推進してきたOSSMaltaの実績を基盤とし、教育機関、学生、そしてLPI認定取得者（LPI Alumni）をつなぐ専任窓口としての役割を正式に位置づけるものです。 LPIの世界水準の認定制度と、OSSMaltaが持つ強力なコミュニティ基盤を組み合わせることで、将来に対応できる人材育成のための明確なロードマップを提供します。 地中海地域のテクノロジー産業を見据えた戦略的ビジョン マルタは、その独自の地理的条件から、ヨーロッパと地中海地域を結ぶハイテク分野の架け橋として理想的な位置にあります。 今回のMoUでは、次世代のIT人材には理論的な知識だけでなく、国際的な舞台で活躍するための世界的に認知された資格が必要であるとの認識を共有しています。 MoUの主な柱 次世代人材の育成 OSSMaltaは、学校や大学と連携する戦略的な窓口として機能し、LPIの教育プログラムの導入を促進します。これにより、学生が業界で即戦力となるスキルを身につけて卒業できるよう支援します。 LPI認定取得者コミュニティの支援 本覚書は、マルタ国内のLPI認定取得者ネットワークを支援し、生涯学習、メンタリング、そして専門家同士のネットワーキングの場を提供します。 地域成長の推進 マルタの戦略的な立地を活かし、地中海地域全体のテクノロジー産業を支える技術人材の育成を目指します。 コミュニティ主導による発展 OSSMaltaは、マルタのオープンソースエコシステムを支えるユーザーや貢献者によって支えられ、20年にわたり成長を続けてきました。そのコミュニティ主導の精神を今後も大切にしていきます。 「マルタには、オープンソース人材育成における地域の中核拠点となる可能性があります。このMoUは、コミュニティ、教育、そして産業界を結ぶ架け橋となり、学生やプロフェッショナルが世界的に認められるスキルを身につけ、イノベーション、雇用機会、そしてデジタル主権の向上につながることを支援します」と、Linux Professional Institute（LPI）のHernán Pachas Magallanes氏は述べています。 「20年にわたるOSSMaltaのリーダーシップにより、マルタの学生やプロフェッショナルが国際的なテクノロジー分野で活躍するための環境を整える最適なパートナーとなっています。」 また、OSSMalta創設者のWarren Camilleri氏は次のように述べています。 「OSSMaltaは20年にわたり、オープンソースこそがデジタルの自律性とイノベーションの鍵であるという信念を掲げてきました。しかし、私たちの成功を支えてきた真の原動力は常に『人』でした。メンバー、貢献者、そしてマルタで日々オープンソースを活用するユーザーの皆さんが、このコミュニティを築いてきたのです。LPIとの今回のMoUは、そうした皆さまの献身への敬意を表すものであり、そしてこれからその後に続く学生たちに対しても、認定資格を通じたグローバルな成功への道筋を提供するものです。」 Linux Professional Institute（LPI）について **Linux Professional Institute（LPI）**は、オープンソース分野のプロフェッショナルに向けた認定資格基準とキャリア支援を提供する国際的な組織です。 35万人を超える認定取得者を擁し、ベンダーニュートラルなLinuxおよびオープンソース認定機関として、世界初かつ最大規模を誇ります。180か国以上で認定資格を提供し、多言語での試験実施と、世界各地の数百に及ぶトレーニングパートナーとの連携を行っています。 詳細は、www.lpi.org をご覧ください。 Open Source Society Malta（OSSMalta）について OSSMaltaは20年以上前に設立された、マルタ諸島におけるオープンソースソフトウェアおよびオープンスタンダード分野の主要団体です。 同団体は、マルタおよび地中海地域におけるイノベーション、教育、そしてデジタルの自由を促進するため、協力的なエコシステムの構築に取り組んでいます。 詳細は ossmalta.eu をご覧ください。 メディアお問い合わせ先 Warren CamilleriFounderOpen Source Society Malta（OSSMalta）warren@ossmalta.eu Shamiul HossainCommunicationsLinux Professional Institute（LPI）shossain@lpi.org

本シリーズの第1回では、コンテナが実用的な選択肢となる直前の分散コンピューティングの状況を見てきました。今回は、その後の展開を現在まで追っていきます。 Dockerプロジェクトによって「コンテナ」という言葉が広く知られるようになりましたが、その考え方の起源は、一般的に2000年にFreeBSDがリリースした「Jails（ジェイル）」という機能までさかのぼります。この機能自体も、さらに古いUnixの「chroot」という仕組みに基づいています。chrootは、特定のディレクトリをプロセスのルートディレクトリとして定義し、その外側のファイルシステムへのアクセスを禁止することで、プロセスを隔離する技術です。しかし、Jailsは広く利用されるには機能が十分ではなく、他のオペレーティングシステムでも実装されませんでした。 2008年初頭、LinuxカーネルにはGoogleが2006年に開発したcgroups（control groups）が組み込まれました。この機能により、管理者はカーネルレベルでプロセスを分離し、メモリやCPU使用量を制限するなど、さまざまなプロセス管理を行えるようになりました。QEMUやXENをはじめとする多くの仮想化ツールがcgroupsを採用し、仮想化技術は徐々に発展していきました。 そして2013年が大きな転換点となります。この年にDockerとKubernetesの両方が誕生したのです。2013年3月にはDockerが正式に発表されました。またGoogleは同年夏にコンテナオーケストレーションプラットフォームについて言及し、2015年7月にKubernetesをリリースしました。 Dockerはまさに時代の要請から生まれた存在でした。Linux上で動作し、開発者や管理者にとって馴染み深いLinuxライクなコマンド体系を採用しています。 他の現代的な管理ツールと同様に、Dockerは設定ファイルをもとにイメージを作成します。多少の複雑さもあり、例えばビルドは2段階で行われます。第1段階ではインスタンスをコンパイルするためのツール一式を用意し、第2段階では実行に必要な最小限の環境だけを含めます。それでもプロセス全体は比較的シンプルであり、現代のソフトウェア開発に求められる継続的な更新に対応した迅速な再ビルドを可能にしています。 Docker、そしてその後のKubernetesによって、分散コンピューティングにおける「ちょうどよい落としどころ（sweet spot）」が埋められました。しかし、分散コンピューティングには数多くの管理タスクが伴います。Kubernetesの開発者たちは、そのすべてを自ら解決しようとはしませんでした。新たなCORBA、DCE、あるいはOpenStackを作るつもりはなかったのです。その代わり、後から登場する解決策が生まれやすい基盤を整えました。 それでは、どのようなツールが必要だったのでしょうか。 オーケストレーションの役割 「オーケストレーション」という言葉は、しばしば「ガバナンス」と同様に、分散環境における管理タスク全般を指す抽象的で少し難解な用語として使われます。 分散コンピューティングにおいて、開発者や管理者が実行しなければならない主なタスクには次のようなものがあります。 自動スケーリング 多くのアプリケーションでは、アクセス負荷が急激に変動します。特にWebサイトでは、一度に大量のリクエストが集中することがあります（これは何十年も前から「SlashDot効果」として知られています）。 分散システムは、トラフィックの増加を検知すると必要に応じてクラウド上に新しいノードを追加し、不要になれば迅速に解放する必要があります。 自動再起動と状態維持 負荷を処理するために30台のノードが必要だと判断した場合、1台が障害を起こせば代替ノードを立ち上げなければなりません。 理想的には、障害（ソフトウェアのバグ、ネットワーク切断、ハードウェア故障など）が発生した際には管理者に通知され、根本原因が修正されます。しかし、その間も分散システムは自動的に同一のインスタンスを起動し、システムの望ましい状態を維持しなければなりません。 ロードバランシング 通常、独立したプロキシが使用され、ワーカーノードへ公平にリクエストを振り分けます。 サービスディスカバリー 専用のDNSサーバーやその他の仕組みを通じて、各ノードは依存しているサービスを見つけられる必要があります。 ローリングアップデート これは、現代のコンピューティングにおけるもう一つの重要な要素である「頻繁で段階的なソフトウェア更新」に関わるテーマです。 ユーザーからの既存のリクエストを処理し続けながら各ノードを更新したい場合、分散システムはアイドル状態のノードを順次停止して新しいノードに置き換え、最終的にすべてのノードを最新状態へ移行できる必要があります。 さらに、これらのタスクにはログ管理、監視、アラート通知など、多くの自動化機能が求められます。 Kubernetesという巨大な存在 Dockerが初めてリリースされてから1年半後の2014年11月、前述した機能をすべて提供するSwarmのバージョン1.0がリリースされました。 Swarmは一定の人気を集めましたが、業界のKubernetesへの熱狂を抑えることはできませんでした。現在では、主にテスト用途や小規模プロジェクト向けの選択肢として見られています。 現在でもDockerはコンテナイメージを作成する重要なツールとして利用されていますが、その多くはKubernetes上で実行されています。 2018年には、Red HatがDockerのほぼ代替となるPodmanを開発しました。Podmanの大きな魅力は、ホストシステム上でroot権限を必要とせず、ユーザーモードで動作する点です（Dockerも「rootless mode」で動作できますが、機能や性能に制限があります）。 PodmanはDockerとのアーキテクチャの違いからSwarmには対応しておらず、「Podman Swarm」が登場することもありません。スケーリングやその他のオーケストレーション機能については、Podmanの開発者もKubernetesを利用しています。 （Red Hatは戦略を全面的にKubernetesへシフトしています。PodmanをはじめとするKubernetes関連ツールを多数開発しているだけでなく、自社の主要製品であるOpenShiftクラウドもKubernetesを基盤としています。） Kubernetesの強力さを示す例のひとつが、Persistent Volume（永続ボリューム）機能です。 コンテナ（また、仮想マシンやFaaSインスタンスも同様）は一時的な存在であり、サービス全体に影響を与えることなく消滅することを前提に設計されています。そのため、顧客情報など保存が必要な状態データや、後続のプログラムで利用するデータはコンテナ外部に保存する必要があります。 Persistent Volumeは、このニーズを非常に洗練された形で満たしており、Kubernetesと密接に統合されています。 私は、Kubernetesの成功は、莫大なリソースを持つGoogleによる積極的な取り組みと、絶妙なタイミングにあったと考えています。 GoogleはKubernetesを社内プロジェクトを基に開発しました。非常に大きな投資を行っていたため、経営陣はオープンソース化に慎重でした。しかし、最終的に決め手となったのは次の認識だったようです。 「顧客は大量のCPUに対して料金を支払っているが、仮想マシンを利用しているため、その利用率は極めて低い。」 つまりGoogleは、信頼できる強力なオーケストレーションツールを無償かつオープンソースで提供すれば、自社クラウドビジネスを大きく拡大できると判断したのです。 実際、Cloud Foundry（VMwareが2009年に立ち上げたオープンソースプロジェクト）をはじめ、あらゆるPaaSベンダーが、自社サービス上でコンテナを実行するための基盤としてKubernetesを歓迎しました。 Androidと同様に、業界ではGoogle製品には継続的なサポートが期待されています。一方で、オープンソースであることは、誰かがソフトウェアを取り上げたり、利用者のニーズに反する方向へ開発を強制したりできないという信頼につながります。 しかしGoogleは、多くの企業のようにソフトウェアを公開して終わりにはしませんでした。リリースからわずか1年後の2015年7月、Googleはオープンソース界のもう一つの巨人であるLinux Foundationと提携し、ベンダーニュートラルなCloud Native Computing Foundation（CNCF）を設立しました。 CNCFにはコンピューティング業界のほぼすべての主要企業が参加しており、多数の管理ツールを育成するインキュベーターの役割を果たしています。 ここでいう「クラウド」という言葉は限定的な意味で使われています。彼らが対象としているのは仮想マシンではありません。その活動のほとんどはKubernetesに向けられています。 また、Red HatやCNCFが多大なリソースを投入しなくても、コミュニティはKubernetesの複雑な運用を容易にするためのツール群を次々と生み出していたでしょう。 もし「K」で始まるソフトウェア名を耳にしたなら、その多くはKubernetes向けのツールだと考えてよいでしょう。（デスクトップ環境のKDEも同じ命名規則ですが、用途が大きく異なるため混同することはほとんどありません。） まとめ 数多くの競合プロジェクト（プロプライエタリ、オープンソースを問わず）が存在する中で、Kubernetesは絶妙なタイミングで登場し、現実の顧客ニーズに応え、強力な組織の支援を受けたことで勝者となりました。 また、そのオープンソースライセンスと活発なコミュニティ活動は、Kubernetesを現代コンピューティングにおける最も重要なプロジェクトのひとつへと押し上げる決定的な要因となっています。 << 本記事の第1回を読む

Linux ― 未来を支えるテクノロジー 未来は、すでにここにあります。そして、本シリーズで振り返ってきた歴史が示すように、その理由は驚くほどシンプルです。未来はどこかへ行ってしまったのではなく、ずっと私たちのそばにあったのです。 私たちは今、テクノロジーが生活のあらゆる瞬間に浸透している時代を生きています。技術革新はあまりにも当たり前の存在となり、その恩恵に気付くことすら少なくなりました。私たちはそれを日常の一部として受け入れ、当然のものとして利用しています。 そして、その中心には Linux があります。 ポケットの中の Android スマートフォンは Linux 上で動作しています。インターネットを支えるサーバー群も Linux に依存しています。スマートホーム機器、IoT デバイス、自動車システム――そのすべてが Linux を基盤として動いています。 目立つことなく、静かに、そして確実に。Linux はすでに私たちの技術的な未来の中に深く組み込まれているのです。 しかし、Linux の真の影響力を数行で説明しようとすると、そこに大きな問題があります。実際に Linux が担っている役割や運用面での重要性は、どんな短い説明よりもはるかに大きいからです。 だからこそ、より深く掘り下げて見ていく必要があります。 本シリーズは、そのためのものです。 デスクトップ：転換点を迎えるのか？ 長年にわたり、Linux は「Linuxデスクトップの年」が訪れると言われ続けてきました。 しかし、2026年は本当にその転換点になるかもしれません。 その理由は、具体的で構造的な変化が起きているからです。 Windows 10 のサポート終了、Windows 11 が求める高いハードウェア要件、そして電子廃棄物（E-waste）への関心の高まり。これらの要素が重なり、Linux にとってこれまでになかった追い風が生まれています。 クラウドとサーバー：見えないオペレーティングシステム クラウドを支える膨大な数のマシン――ネットワーク機器、ゲートウェイ、監視プローブ、基盤インフラなど――の大半は Linux ベースです。 例えば、Linux はクラウド環境の 90.1％、機械学習ワークロードの 87.8％ で利用されています。 この圧倒的な普及率は、驚くべきことであると同時に、ある意味では当然の結果でもあります。 もし世界中の Linux システムがわずか5分間停止したらどうなるでしょうか？ 本シリーズでは、IaaS や PaaS を支える基盤技術、Infrastructure as Code（IaC）の役割、そして Linux がどのようにクラウドを静かに、確実に支え続けているのかを見ていきます。 仮想マシンとコンテナ：対立か、それとも融合か？ 仮想化とコンテナ化は、単純な技術の置き換えでもなければ、自社運用からクラウドデータセンターへの移行を意味するものでもありません。 これらは、システムの分離性、柔軟性、そして現代的なインフラ運用の効率性を実現するためのアーキテクチャ層として発展してきました。 本シリーズでは、それぞれの技術がどのように共存し、補完し合っているのかを探ります。 x86から、その先へ：アーキテクチャの転換 約50年にわたりコンピューティングの中心であり続けた Intel の x86 アーキテクチャですが、現在、新たな転換期を迎えています。 ARM や RISC-V は単なる代替手段ではありません。 それらは、新しい可能性を切り開くフロンティアです。 そして Linux は、すでにその最前線で適応を続けています。 人工知能：製品ではなくプラットフォーム AI は単一のツールではありません。 それは巨大なエコシステムです。 重要なのは [...]

Kubernetesが注目される理由 ― クラウド時代の新しい標準 現在、多くのベンダーが、規模を問わずさまざまな組織にクラウドサービスの導入を勧めています。その中でも、開発者やシステム管理者に対して専門家たちが特に強く推奨しているのが Kubernetes（クバネティス） です。 Kubernetesを習得すれば、あらゆるクラウドサービス上でプログラムを実行できるようになります。そして、世界中の企業における仕事のチャンスも大きく広がります。 本シリーズでは、Kubernetesが2015年の初回リリース以降、なぜこれほど短期間で中心的な存在になったのかを解説します。 そのために、コンテナの仕組みを、コンピューター資源を共有する他の代表的な2つの形態と比較していきます。 仮想マシン（Virtual Machines）（Infrastructure as a Service：IaaS） Functions as a Service（FaaS） さらに、Kubernetesが、特にDockerを中心とする豊かなコンテナ技術の環境の中でどのように登場し、それまで存在していた仕組みを活かしながら発展していったのかも紹介します。 なお、このシリーズでは「サーバーレスコンピューティング」という言葉は使いません。その理由は、この言葉が曖昧で、PaaSにもFaaSにも使われることがあるためです。そして何より、少し誤解を招く表現でもあります。というのも、実際には必ずどこかにサーバーが存在するからです。 Kubernetesは、LPI DevOps Tools Engineer認定資格でも扱われています。 コンピューター資源共有の代表的な3つの形態 このシリーズの読者の多くは、IaaS、Platform as a Service（PaaS：コンテナ化が含まれる領域）、そしてFaaSの違いをすでに理解しているかもしれません。 ここでは、それぞれの歴史を簡単に紹介しながら、どのような用途に向いているのか、そしてどのように普及していったのかを見ていきます。 まずは基本から整理してみましょう。 IaaS（仮想マシン） IaaSでは、OSやドライバを含む「ひとつの完全なコンピューターシステム」をエミュレートした環境が、別のシステムの上で動作します。 複数の仮想マシン（VM）は同じハードウェアとホストソフトウェア（ハイパーバイザー）を共有しますが、それぞれは互いを認識できず、他のVMの存在も見えません。 PaaS（コンテナ化） PaaSでは、アプリケーションとその実行環境（ライブラリ、場合によってはログ機能などの補助サービスを含む）が、共有OSの上で独立して動作します。 DockerやKubernetesは、このPaaS全体を構成する要素の一部です。 FaaS FaaSでは、独立したステートレスな関数が、ホストシステムが提供するプラットフォーム上で実行されます。そのプラットフォームには、関数を動かすために必要な環境があらかじめ用意されています。 この3つを比べると、段階が進むにつれて、ホストシステムとそのベンダーがより多くのソフトウェアと責任を担うようになります。 その結果、利用者側の開発者やシステム管理者は、自分たちが管理すべきソフトウェアの範囲を絞ることができます。 IaaSもFaaSも重要な技術ですが、Kubernetesはそれらを大きく上回る勢いで普及し、PaaSの分野でも圧倒的な存在となっています。 まずは仮想マシンとFaaSの歴史を見て、そのあとでコンテナ化について掘り下げていきます。 仮想マシン 完全なコンピューターシステムをエミュレートするという考え方、そしてそれを低コストで顧客に提供するという発想は、かなり古くから存在していました。 IBMは1967年の時点で、System/360 上で仮想マシンをサポートしていました。System/360は、1960〜70年代に「コンピューター」といえば真っ先に思い浮かぶほど有名な存在でした。 その後、 VMware：1998年 Amazon Web Services（AWS）：2006年 と、仮想化技術は広がっていきます。 また、1台のデスクトップPC上で複数のコンピューター環境を個別に動かせるエミュレーターも多数存在しました。 代表例のひとつが QEMU です。QEMUは2003年に登場し、GNU/Linux上で広く利用されています。 仮想マシンの大きな利点 仮想マシンの大きなメリットは、ホストOSとゲストOSを別々にできることです。 多くのクラウドベンダーはホスト側にLinuxを採用していますが、顧客の中にはWindowsを動かしたい企業も多くあります。 たとえば Microsoft Azure は、その名の通りWindowsホスト上で動いています。 このように、利用者は自分の用途に合ったOSを自由に選べることが、仮想マシンの強みでした。 2013年にDockerが登場するまでは、仮想マシンは最先端技術と考えられていました。 しかし、仮想化には標準化が不足しており、それを補うためにさまざまな取り組みが行われました。 代表的なオープンソース実装として、 XEN KVM（Kernel-based Virtual Machine） があります。 XENは2003年にオープンソースとして公開され、「Linuxが仮想マシンのホストになれる」ことを示しました。Amazon EC2やGoogleも、かつてクラウド基盤にXENを利用していました。 KVMは2006年に登場しました。 （QEMUとXenは、LPIC-3 Virtualization and Containerization認定でも扱われています。） OpenStackという標準 仮想マシンの分野で最も大きな標準といえるのが OpenStack です。 OpenStackは、大手ホスティング企業Rackspaceの技術をもとに構築され、2010年に発表されました。 非常に野心的なプロジェクトであり、 ネットワーク ID管理（アクセス制御） テレメトリ（監視・計測） 3種類のストレージ など、30以上のソフトウェアコンポーネントで構成されています。 OpenStackは、膨大なデータ管理が必要な企業に適していると言えるでしょう。 たとえば、何百万もの顧客向けクラウドサービスを運用し、会計、監視、可観測性など、企業に必要な機能を包括的に提供できます。 ただし、それ自体がひとつの巨大な世界でもあります。 著者はOpenStackを、過去の巨大な標準化の試みに重ねています。 ひとつは CORBA（Common Object Request Broker Architecture）。 これは独立したプログラム同士を連携させるための仕組みでしたが、あまりにも多くを実現しようとした結果、複雑化しすぎて広く定着しませんでした。 最終的には、WebベースのRESTモデルが、多くの課題を解決することになります。 もうひとつは [...]

外から見ると、小さな決断に見えることがあります。ドキュメントを開く。ファイルをダウンロードする。そして「今日こそ始めよう」と自分に言い聞かせる。 けれど、ときにその静かな瞬間が、すべてを変えることがあります。 私にとって、その瞬間はワルシャワの11月のある朝に訪れました。私は長い間、Linux Essentials試験への挑戦を先延ばしにしていました。しかし、その日ついに待つのをやめたのです。LPIのLearning Materialsをダウンロードし、本格的な学習を始めました。それは、その後のキャリアに大きな影響を与える取り組みの始まりとなりました。 2024年11月13日 この日は、LPI Linux Essentials試験に向けた準備が、「いつかやろうと思っていること」から「今すぐ行動すること」へと変わった日でした。 もう準備を先延ばしにしている時間はない、と感じていました。 「今やらなければ、もう二度とやらないかもしれない」 私はそう自分に言い聞かせ、学習を始めました。 最初に驚いたのは、LPIがLinux Essentials試験のために、質の高いLearning Materialsを無料で提供していることでした。外部の教材を探し回る必要はありませんでした。必要なものはすべてそこにそろっていました。 私が最初にしたことは、Learning Materialsをダウンロードすることでした。そして、Topic 1、Lesson 1.1「Linux Evolution and Popular Operating Systems」から学習を始めました。 学習は、坂道を転がり始めた石のように勢いよく進み始めました。必要だったのは、その最初のひと押しだけだったのです。 2024年11月〜2025年1月 学習は本当に楽しいものでした。 無料で提供されている教材のおかげで、Linuxで作業するうえで重要なトピックを順を追って学ぶことができました。そして正直に言えば、そのどれもが重要だと感じました。 私はもともとLinuxについて少し知識がありましたが、すぐに気づきました。自分の知識は氷山の一角に過ぎなかったのだと。 水面の下に隠れている大部分こそ、これから学ぶべき内容だったのです。 最も大きな課題のひとつは、やはりターミナルで使う基本コマンドを覚えることでした。システム内を移動するためのコマンドやその使い方を理解するのは、最初は簡単ではありませんでした。 また、Linuxでプロセスがどのように動作し、どのように管理されているのかを理解するのにも苦労しました。 学びを進めるうちに、ターミナルそのものも「動いているプロセス」であることを知りました。そしてLinuxでは、「すべてがプロセスかファイルのどちらかである」という考え方に触れました。 WindowsからLinuxへ移行する中で、もうひとつ驚いたのがセキュリティモデルの違いでした。 Linuxでは、ユーザー・グループ・権限（おなじみの rwx ビット）、さらに sudo コマンドや root ユーザーによって、厳密なアクセス管理が行われています。一方でWindowsは、一般ユーザーと管理者（Admin）の権限の分離が中心です。 この違いは非常に興味深いものでした。 もうひとつ、魔法のように感じた瞬間であり、同時に大きな挑戦でもあったのが、絶対パスと相対パスを使ったファイルシステムの操作を学んだときです。 また、シンボリックリンクとハードリンクの違いを理解するのも、最初は少し魔法のように感じられました。 さらに、オペレーティングシステムの構成要素が、それぞれ特定のディレクトリに整理されていることも学びました。 たとえば、重要なシステムバイナリは /bin や /sbin にあり、ログのような可変データは /var に保存されています。そして、システムの中心であるカーネルは /boot ディレクトリに存在します。 Linuxシステムは、こうした特別なファイル群によって、その性能と安定性が支えられているのです。 もうひとつ大きな壁だったのは、オープンソース と フリーソフトウェア の考え方を深く理解することでした。 なぜそれらが存在するのか。Linuxはそれとどのように関係しているのか。 Windows環境で育ってきた私にとって、ソフトウェアライセンスに対する考え方はかなり限定的なものでした。Windows中心の環境の中で自然と身についた「プロプライエタリ（独占的）な考え方」を、私は少しずつ手放していったのです。 もちろん、大変なことばかりではありませんでした。 難しく感じる内容もあれば、とても自然に理解できるテーマもありました。 たとえば、ハードウェアやネットワークの基礎に関するレッスンは特に好きでした。 簡単という意味ではありません。しかし、私にとってはとても自然で、学ぶこと自体が楽しいテーマでした。以前から多少知識があったのかもしれませんし、あるいはLinuxが物理的なマシンとどうつながっているのか、その仕組みに強く惹かれていたのかもしれません。 この学習の中で、頭の中に散らばっていたパズルのピースが、ようやくひとつの形としてつながり始めました。 LinuxというOSがハードウェアと対話し、ネットワークのレイヤーで動いている姿が、はっきりと見えてきたのです。 ここでは本当に多くの気づきを得ました。 Linuxは /dev ディレクトリを通してハードウェアと通信しており、ハードディスクやUSBポートのようなデバイスも「ファイル」として扱われていることを学びました。 また、LinuxはBIOSまたはUEFIから制御を受け取り、それがGRUBのようなブートローダーへ渡され、その後で最初のプロセスである init や systemd が起動することも理解しました。 この「親」プロセスから、さらに多くの「子」プロセスが生まれていきます。 私はそれを、自分なりに 「Linux Tree」 と呼ぶようになりました。 2025年2月 この月、私はそれまであまり意識していなかった大きな課題に気づきました。 それは、計画性と自己管理です。 Linux Essentialsは私にとって初めてのIT試験でした。そのため、他の人がどのように学習しているのかよくわかりませんでした。 オンライン動画もいくつか見ましたが、自分の目標や学習スタイルにぴったり合うものは見つかりませんでした。 そこで私は、自分なりの学習スタイルを作ることにしました。 ベースにしたのはポモドーロ・テクニックです。 40分集中して勉強し、その後10〜15分休憩する。休憩中は水分補給をし、ストレッチをして、新鮮な空気を吸う。 この方法のおかげで、集中力を保ちながらも頭を疲れさせすぎずに勉強を続けることができました。 学習計画 毎回の学習の前に、私は明確な目標を決めていました。 たとえば、 「今日は1.1から1.3まで終わらせる」 というようにです。 この計画のおかげで、「何をやればよいかわからない」という不安がなくなり、自分の進捗も確認しやすくなりました。 進歩していることを実感できたことは、自分の努力を前向きに受け止める大きな励みになりました。 ノート作成 これがなければ、頭の中はきっと混乱していたと思います。 大量の情報を扱うとき、ノートは知識を整理するために欠かせません。 難しい部分を読み返したり、自分の理解が不十分な箇所を見つけたりするために、とても役立ちました。 テストと演習 LPIのLearning Materialsが素晴らしいと感じた理由のひとつが、各レッスンのあとに確認問題や実践的な演習が用意されていることです。 これは本当に飛ばさずに取り組むことをおすすめします。 答えがわからなくても心配する必要はありません。 そのためにテストがあるのです。 どこに重点を置いて復習すればよいのかを教えてくれます。 私の国にはこんなことわざがあります。 「探し続ける人は、必ず見つける。」 2025年3月 Learning Materialsを終えに近づくにつれて、私は少しずつこう思うようになりました。 「今月だ。」 ついに試験を受ける月が来たのだ、と。 この時期は、それまで学んだことを繰り返し復習していました。そして、その中心にあったのがノートでした。 IPアドレス、ファイル権限、スクリプトの基礎など、ノートを見返すだけですぐに記憶を呼び戻すことができました。 頭の中でバラバラだったパズルのピースが、ようやくしっかりとかみ合った感覚がありました。 2025年3月26日〜27日 この2日間は、試験に向けた最終準備に追われていました。 私はポーランド・ワルシャワにある試験センターで受験することに決めました。 個人的にはオンライン受験よりも、会場で受験するスタイルのほうが好きです。 試験会場へ向かう緊張感や高揚感、そして少しのストレスも含めて、そのすべてを体験したいと思ったからです。 2025年3月28日 ついに、その日が来ました。 私は再び人生の大きな転機に立っていました。 緊張していて心臓は高鳴っていましたが、それと同時に、成功できるという確かな感覚もありました。 緊張を少しでも減らすため、事前に試験会場までのルートを確認しておき、確実に間に合うよう1時間も早く到着しました。 試験センターのスタッフの皆さんは本当に親切でした。 丁寧な対応と明確な説明のおかげで、コンピューターの前に座るころには、かなり落ち着くことができました。 試験そのものは非常に集中力のいるものでした。 コマンドラインの構文からライセンスに関する知識まで、幅広い内容について自分の理解が試されました。 そして最後のボタンをクリックした瞬間、画面に 「PASSED」 の文字が表示されました。 その瞬間、喜びが一気にあふれました。 本当に誇らしい気持ちでした。 LPIのLearning Materialsのページ一つひとつに、自分がどれほどの時間、努力、規律を注いできたかを、自分自身が一番よく知っていたからです。 最後に これが、Linux Essentials試験に向けて準備し、認定資格を取得するまでの私のストーリーです。 しかし、私の旅は、この1枚の認定証で終わりではありません。 むしろ、それは今、もっと大きなものへと成長し続けています。 << このシリーズの前回の記事を読む [...]

現代のデジタル社会において、そしてAIの普及が進む今、自分のデータと評判を守ることの重要性は、かつてないほど高まっています。私たちが広大な情報技術の世界を生きていく中で、ITセキュリティの基本原則を理解することは、仕事の場面だけでなく、個人のデジタルライフにおいても欠かせないものになっています。 まず、ITセキュリティにおける**機密性（Confidentiality）・完全性（Integrity）・可用性（Availability）**の重要性について考えてみてください。これらは単なる抽象的な概念ではなく、私たちのデジタルな安全を支える土台です。これらの基本的な目標を理解することで、潜在的な脅威を軽減し、機密情報を守るための基盤を築くことができます。 その中で、リスク評価とリスク管理は欠かせない取り組みです。これは単に脆弱性を見つけるだけではなく、どのリスクにどれだけ迅速に対応すべきかを理解することでもあります。 私たちはセキュリティインシデントをどのように捉えるべきでしょうか。そして、そのリスクを軽減するためにどのような対策を講じることができるでしょうか。 こうした問いは、ソフトウェア開発者やデジタルサービス提供者が、今日のオンライン社会において担っている倫理的責任の大きさを示しています。 その防御戦略の中核となるのが暗号化です。対称暗号と公開鍵暗号（非対称暗号）の仕組みを理解することで、私たちはデータを第三者の不正な閲覧から守ることができます。 さらに、**Perfect Forward Secrecy（完全前方秘匿性）**のような考え方や、X.509証明書のような技術は、複雑なデジタルセキュリティの世界をより安全に進むための重要な手段となります。 また、私たちの取り組みはデジタル空間の中だけにとどまりません。ハードウェアとストレージのセキュリティにも目を向ける必要があります。 デバイスへの物理的なアクセスがもたらすリスクや、USB、Bluetooth、RFIDといった技術に潜む脆弱性にも向き合わなければなりません。これらの課題に正面から取り組むことで、私たちはデジタル基盤の防御をより強固なものにできます。 一方で、世界がますます相互接続されることで、新たな課題も生まれています。ネットワークセキュリティの脅威は非常に大きく、中間者攻撃（Man-in-the-Middle Attack）からDDoS攻撃まで、その種類は多岐にわたります。 こうした脅威に対して、暗号化の力は大きな防御手段となります。VPNのような技術は、潜在的な侵害から私たちを守る盾となります。 そして、これらすべての取り組みの中心にあるのが、個人のアイデンティティとプライバシーの保護です。 急速にデジタル化が進む時代において、**多要素認証（MFA）**のような認証手法や、厳格なプライバシー設定は、私たちにとって強力な味方になります。これらは、個人情報の盗難やオンライン上の人格の損失を防ぎ、デジタル社会における私たちの評判を守るための防波堤となります。 要するに、データと評判を守るための取り組みは、一つの方法だけでは不十分であり、多方面から進める必要があります。 そのためには、技術的な知識だけでなく、倫理的な判断力、そして責任あるデジタル市民としての意識が求められます。 変化し続けるこの環境の中で、私たちはITセキュリティの原則を、丁寧に、そして強い意志を持って実践していく必要があります。 なぜなら、私たちのデジタルな未来は、それにかかっているからです。 << このシリーズの前回の記事を読む

カナダ・オンタリオ州、2026年5月8日 — Linux Professional Institute（LPI） は、Open Source JobHub（OSJH） との協力により、「2026 Open Source Professionals Job Survey Report（オープンソース・プロフェッショナル職業調査レポート）」を公開しました。本レポートでは、両団体が共同で実施した3回目となるFree and Open Source Software（FOSS）プロフェッショナル調査の結果がまとめられています。 システム管理者、開発者、そして非技術職のプロフェッショナルから寄せられた回答をもとに、オープンソース分野で働く人々が仕事において何を重視しているのかを明らかにしています。これらの調査結果は、企業が優秀な人材を惹きつけ、採用し、長期的に活躍してもらうための参考資料として活用できます。 前年と同様に、オープンソースのプロフェッショナルが仕事を選ぶ際に最も重視しているのは「仕事における充実感」であることがわかりました。これは、魅力的なプロジェクトへの参加、人脈形成の機会、達成感などと関連する要素です。回答者の97.06％が、この要素を「不可欠」「非常に重要」または「ある程度重要」と評価しました。 これに続いて、「ワークライフバランス」（96.08％）、「企業文化や企業の価値観」（94.85％）が高く評価されています。 また、トレーニングや認定資格も、キャリア選択において重要な要素であることが示されました。回答者の83.58％が、企業から提供される研修制度を、仕事を選ぶ際に重要だと回答しています。さらに、92.16％が、オープンソースソフトウェアの利用や貢献に関するガイドラインを求めていると回答しました。 レポートではさらに、回答者の67.48％が「現在積極的に新しい仕事を探している」または「条件が合えば新たな機会を検討したい」と考えていることも明らかになっています。 今回の調査によるさらに詳しい分析を含む完全版レポートは、以下よりダウンロードできます。 2026 Open Source Professionals Job Survey Report G. Matthew Rice 氏（Linux Professional Institute エグゼクティブディレクター）は、次のように述べています。 「オープンソースのプロフェッショナルは、テクノロジーの未来を形づくる存在です。そして、彼らのモチベーションを理解することは、人材の獲得と定着を目指す企業にとって非常に重要です。このレポートは、プロフェッショナル自身の声を通して、現在のオープンソース人材が何を優先し、何を期待しているのかを企業がより深く理解する助けとなるものです。」 また、Brian Osborn 氏（OSJH創設者、Linux New Media CEO兼Publisher）は次のようにコメントしています。 「このレポートは、オープンソースのプロフェッショナルが仕事に何を求めているのかを知るうえで、非常に貴重な視点を提供しています。特に変化の激しい現在の雇用市場において、その意義は大きいと言えます。システム管理者、開発者、そして非技術職の人々が何を重視しているかを理解することは、優れたオープンソース人材を見つけ、維持するための鍵になります。」 Linux Professional Institute（LPI）について Linux Professional Institute（LPI） は、オープンソースのプロフェッショナルのための国際的な認定基準を提供し、キャリア支援を行うグローバル組織です。35万人を超える認定取得者を擁し、ベンダーニュートラルなLinuxおよびオープンソース認定機関として、世界で最初かつ最大規模を誇ります。 LPIは180か国以上で認定を提供しており、試験は複数の言語で受験可能です。また、世界各地に数百のトレーニングパートナーを有しています。 詳しくは、公式サイトをご覧ください。 Open Source JobHubについて Open Source JobHub は、求職者がオープンソースエコシステムの中で自分に合った活躍の場を見つけるための求人サイトです。優秀な人材を求める企業と求職者をつなぐプラットフォームとして運営されています。 詳細は公式サイトをご覧ください。 メディアお問い合わせ先 Shamiul HossainCommunicationsLinux Professional Institute [...]

DevOps Tools Introduction #16：まとめ おめでとうございます。ついに「DevOps Tools Introduction」シリーズの最終回までたどり着きました。この数か月にわたり、毎週新しいテーマを一つずつ取り上げてきました。 ここまで紹介してきたリソースに取り組むには、多くの時間と労力が必要だったと思います。その努力の結果として、今ではますます重要性が高まっている技術スタックについて、しっかりとした基礎知識を身につけることができました。 このシリーズでは、モダンなアプリケーション設計、バージョン管理、継続的インテグレーションと継続的デリバリー（CI/CD）、コンテナ仮想化、オーケストレーション、インフラストラクチャ、構成管理の自動化、監視、ログ管理まで、幅広いテーマを取り上げてきました。 これらの新しいツールは、サービスの作り方や提供方法そのものを大きく変えています。今週は（ほとんど）新しい参考資料の紹介はありませんが、その代わりに、これらのツールをどのように活用すれば、日々の仕事をより効率的に、そしてより面白くできるか、少し立ち止まって考えてみてください。 本日ぜひ共有したいリンクがひとつあります。それが Periodic Table of DevOps Tools（DevOpsツールの周期表） です。このページを見ると、DevOpsツールのエコシステムがどれほど多様になっているかがよくわかります。ツールはカテゴリごとに整理されており、このシリーズを通して、その多くのカテゴリの中から少なくとも1つずつツールに触れてきたことが確認できるはずです。 このブログシリーズで紹介してきたツールは、LPI DevOps Tools Engineer試験で扱われるものです。これらはコミュニティでの議論や公開ディスカッションを重ねて選定されたものであり、DevOpsを学び始めるうえで、実践的かつ信頼できる選択肢だと言えます。 これらのツールに関する知識を身につけた今、LPI DevOps Tools Engineer認定資格 の取得を検討してみるのもよいでしょう。この認定資格は、DevOpsツールに関するスキルと知識を証明するものです。 ここまでブログシリーズを読み進めてきた今、改めて試験の出題範囲（Exam Objectives）を確認してみてください。そこには試験で求められる知識の範囲が明確に示されています。印刷して、すでによく理解しているタスクやツールにチェックを入れながら確認していくのもおすすめです。そして、まだ自信のないテーマについては、関連するブログ記事やLearning Materialsをあらためて見直してみてください。 最後の仕上げとして、もう一度コマンドラインに戻り、試験範囲に含まれるタスクを実際にやり直してみましょう。もしうまく動かないものがあれば、そのテーマをもう一度復習するための時間を確保してください。 また、試験に向けて覚えておきたい内容があればメモを取っておくのも効果的です。試験では、原則や概念に関する問題だけでなく、コマンド、ファイル、設定項目に関する問題も出題されることを忘れないでください。 試験日が近づいてきたら、自分のノートを定期的に見返しながら内容を整理し、少しずつ要点を絞り込んでいきましょう。そして準備が整ったら、LPI公式サイトやLPI Marketplaceにアクセスして、試験の予約方法を確認してください。 もしあなたがLinux Professional Institute DevOps Tools Engineerを目指しているなら、ノートを見直し、試験範囲を確認し、試験対象のツールを実際に触りながら学ぶための時間と余裕が持てることを願っています。そしてもちろん、試験での成功を心から祈っています。 最後に、このシリーズを締めくくるにあたり、この連載の中で紹介してきた素晴らしいリソースの制作者の皆さまに感謝を伝えたいと思います。知識や経験を共有してくださったことに深く感謝します。 そして何より、このシリーズを読んでくださったすべての皆さまにも、時間を割いてご覧いただいたことに心から感謝します。私自身がこのシリーズを書くことを楽しんだのと同じように、皆さまにも楽しんでいただけていたら嬉しく思います。 このシリーズはここで終了となりますが、ぜひ今後もLPIブログにご注目ください。これからも魅力的なコンテンツをたくさんお届けしていきます。 << このシリーズの前回の記事を読む | シリーズの最初の記事から読む >>

DevOps Tools Introduction #15：分散トレーシングとOpenTelemetry入門 この数か月にわたり、「DevOps Tools Introduction」シリーズでは、毎週さまざまなテーマを取り上げてきました。今回が最終回となり、DevOpsエンジニアが知っておくべき、もうひとつの重要なトピックをご紹介します。 現代の分散システムは非常に複雑であり、従来の監視手法だけでは十分とは言えません。アプリケーションがマイクロサービスとして分割されると、ひとつのリクエストが複数のサービス、ネットワーク、インフラレイヤーをまたいで処理されることがあります。 このような環境において、分散トレーシング（Distributed Tracing） は、システムの動作を理解し、問題を診断し、パフォーマンスを改善するために欠かせない技術となっています。 本記事では、トレーシングの基本概念を紹介し、OpenTelemetry の基礎を解説します。また、よく利用されるオープンソースのテレメトリー分析ツールの概要と、アプリケーション計測（Instrumentation）の重要な考え方についてもご紹介します。 トレーシングとは？ トレーシングとは、リクエストが分散システム内の複数のコンポーネントを通過していく一連の流れを追跡する仕組みです。 ログが個々のイベントを記録し、メトリクスが集計された数値データを示すのに対し、トレーシングは処理がどのような因果関係で実行されたのかをサービス横断で可視化します。 OpenTelemetryを理解する前に、トレーシングに関する基本用語を押さえておきましょう。 分散トレース（Distributed Trace） とは、ひとつのリクエストがシステム全体を通過する完全な流れを表します。 そのトレースは複数の スパン（Span） で構成されます。スパンは、サービスやコンポーネントが実行するひとつの処理単位を表します。 スパンは階層構造で管理され、ツリーのような形で各処理の関係性を示します。 それぞれのトレースには固有の Trace ID があり、各スパンには個別の Span ID が割り当てられます。 これらの識別子によって、異なるサービス間のイベント同士を関連づけることができます。 通常、スパンには以下の情報が含まれます。 開始時刻と終了時刻などのタイミング情報 処理に関するメタデータ 親スパン・子スパンとの関係性 この構造によって、エンジニアは遅延を可視化し、ボトルネックを特定し、サービス間の依存関係を理解できるようになります。 分散トレースの主要要素 トレーシングシステムを効果的に活用するには、スパンやトレースを構成する主要な要素を理解することが重要です。 Span Attributes（スパン属性） スパン属性はキーと値のペアで構成される情報で、HTTPメソッド、データベースクエリ、ユーザーIDなど、処理に関するコンテキストを表します。 これにより、トレースに詳細な情報が加わり、分析しやすくなります。 Events（イベント） イベントは、スパンの中に記録される時刻付きの注釈です。 リトライ処理やエラー発生など、実行中の重要な出来事を記録するために利用されます。 Links（リンク） リンクは、直接の親子関係ではないものの、因果関係を持つスパン同士を関連づける仕組みです。 非同期処理やバッチ処理などで特に有効です。 Status（ステータス） スパンの実行結果を示します。 成功・失敗といった状態や、エラー内容の説明が含まれることがあります。 Kind（種類） スパンがシステム内でどの役割を担っているかを示します。 たとえば以下のような種類があります。 Client Server Producer Consumer これによって、その処理が全体の中でどの位置づけにあるのかがわかりやすくなります。 コンテキスト伝播（Context Propagation） 分散トレーシングで最も重要な概念のひとつが コンテキスト伝播 です。 リクエストが複数のサービス間を移動する際、トレーシングのコンテキスト情報も引き継がれなければなりません。 このコンテキストには、以下のような情報が含まれます。 Trace ID Span ID その他のメタデータ これが正しく伝播されないと、トレースが途中で分断され、リクエスト全体の流れを再構築できなくなります。 実際には、HTTPヘッダーやメッセージングシステムを通じてコンテキストが伝達されることが一般的です。 これにより、各サービスは自分のスパンを正しいトレースに紐づけることができます。 OpenTelemetry OpenTelemetry は、トレース、メトリクス、ログを統一的に収集するためのオープンソースObservabilityフレームワークです。 Cloud Native Computing Foundation によって管理されており、現代のシステムにおけるテレメトリー計測の事実上の標準となっています。 OpenTelemetryでは以下を定義しています。 テレメトリーデータ生成のためのAPI データ処理・エクスポートのためのSDK 命名や構造を統一するセマンティック規約 OpenTelemetryを採用することで、特定ベンダーへの依存を避けながら、さまざまなObservabilityツールとの相互運用が可能になります。 アプリケーションは特定のバックエンドに直接接続するのではなく、OpenTelemetryを通じて収集したデータを、トレース基盤、メトリクス基盤、ログ集約システムなど複数の環境へ出力できます。 アプリケーション計測（Instrumentation） Instrumentationとは、テレメトリーデータを生成するためにアプリケーションへ計測処理を組み込むことです。 主に次の2つの方法があります。 手動Instrumentation 開発者がコード内で明示的にスパンを生成し、属性を追加します。 細かな制御が可能ですが、実装の手間がかかります。 自動Instrumentation ライブラリやエージェントを利用し、HTTPサーバー、データベースクライアント、メッセージングシステムなどに対して自動でスパンを生成します。 開発工数を減らし、導入を加速できるのがメリットです。 効果的なInstrumentationでは、不要なノイズを増やしすぎず、必要な可視性を確保することが重要です。 オープンソースのテレメトリー分析ツール テレメトリーデータは収集しただけでは意味がありません。 保存・検索・可視化できる仕組みが必要です。 この用途で広く使われているオープンソースツールには以下があります。 Jaeger もともとUberによって開発された分散トレーシングシステムです。 以下のような強力な機能があります。 トレースの可視化 サービス依存関係分析 パフォーマンス監視 Grafana Tempo Grafana Labs のエコシステムと統合しやすい、高スケーラブルなトレーシングバックエンドです。 メタデータのみをインデックス化し、トレース本体はオブジェクトストレージに保存することで、コスト効率の高い運用を実現します。 これらのツールを使うことで、エンジニアはトレースを探索し、レイテンシ問題を見つけ、複雑なシステム内でリクエストがどのように流れているかを把握できます。 なぜトレーシングが重要なのか トレーシングは、ログやメトリクスだけでは得られない分散システム内部の可視性を提供します。 チームは以下を実現できます。 [...]

カナダ・オンタリオ州、2026年4月30日 — Linux Professional Institute（LPI） は、Security Essentials認定向けの無料Learning Materials（学習教材）のベトナム語版を公開したことを発表しました。 Security Essentials認定は、ITセキュリティの主要分野を理解するために必要な基礎知識を学べる資格です。ITセキュリティの入門コースを修了した学生をはじめ、サイバーセキュリティのスキル向上を目指す社会人や、安全な情報技術の活用に関する確かな基礎を身につけたい方に向けて設計されています。 LPI シニアプロダクトマネージャーのMarkus Wirtz 博士は、次のように述べています。 「今回の公開により、LPIのLearning Materialsはすべてベトナム語で利用できるようになりました。翻訳者であるMinh Trang Nguyễn 氏と Thoa Huỳnh 氏の、丁寧で一貫した素晴らしいご協力に心より感謝します。」 また、LPI日本支部コミュニケーションディレクターの伊藤健二 氏は次のようにコメントしています。 「この新しい翻訳が、ベトナムの受験者の皆さんにとってITセキュリティの世界へ踏み出す第一歩となり、さらに高い目標へ挑戦するきっかけになることを願っています。」 Learning Materialsは、講師や学習者のために提供されている無料の学習リソースで、試験対策を支援することを目的に開発されています。説明・演習・解答が明確に分かれた授業向けの構成となっており、内容は常に最新の状態に保たれるよう定期的に更新されています。 Security Essentials Learning Materialsは現在、7言語で全訳または一部翻訳が提供されています。複数の言語で提供することで、LPIは言語の壁を減らし、より多くの人がサイバーセキュリティ教育にアクセスしやすい環境づくりを目指しています。これにより、学習者は母国語で実践的かつ仕事に直結するスキルを身につけることができ、キャリア形成や、日常のデジタル環境におけるセキュリティ意識の向上にもつながります。 Security Essentials Learning Materials ベトナム語版は、こちらから利用できます。 Security Essentials Learning Materials（ベトナム語版） Linux Professional Institute（LPI）について Linux Professional Institute（LPI） は、オープンソースのプロフェッショナルのためのグローバルな認定機関であり、キャリア支援を行う国際的な組織です。35万人を超える認定取得者を擁し、ベンダーニュートラルなLinuxおよびオープンソース認定機関として、世界で最初かつ最大規模を誇ります。 LPIは180か国以上で認定試験を提供しており、多言語での受験に対応しています。また、世界各地に数多くのトレーニングパートナーを有しています。 Linux Professional Instituteについて詳しくは、公式サイトをご覧ください。 メディアお問い合わせ先 Shamiul HossainCommunicationsLinux Professional Institute (LPI)shossain@lpi.org