検索結果

コンテナ仮想化とDocker／Podmanの基礎 コンテナ仮想化は、現代のソフトウェアアーキテクチャを支える主要技術の一つです。コンテナ仮想化という概念自体は以前から存在していましたが、近年のツールは純粋な仮想化機能に加え、コンテナ化されたソフトウェアの展開を容易にする多くの機能を提供しています。その分野で最も代表的なプロジェクトがDockerです。DevOps Tools Engineer認定の試験目標702.1では、DockerおよびPodmanコンテナに完全に焦点が当てられています。 OCI仕様と標準化 DockerとPodmanはいずれも、Open Container Initiative（OCI）仕様を実装しています。OCIは標準化されたイメージ形式とランタイム動作を定義しており、この準拠により高い可搬性が実現します。ある準拠環境でビルドされたイメージは、別の準拠環境でも変更なしに実行可能です。 DevOpsエンジニアにとって、この標準化は基盤的な意味を持ちます。なぜなら、アプリケーションのパッケージングを実行環境の詳細から切り離すことができるからです。 コンテナの基本概念：エフェメラル設計 コンテナは設計上「エフェメラル（短命）」な存在です。状態を持たないワークロード（ステートレス）はコンテナアーキテクチャと自然に適合します。一方で、状態を保持するワークロード（ステートフル）は、明確なストレージ戦略が必要です。 Dockerのアーキテクチャ Dockerはクライアント・サーバーモデルを採用しています。Docker CLIはDockerデーモン（dockerd）と通信し、イメージ、コンテナ、ネットワーク、ストレージを管理します。 この中央集約型デーモンは、オーケストレーションやAPIベースの自動化を容易にし、統合ワークフローやCI/CDパイプラインとの親和性を高めています。 Podmanのアーキテクチャ 一方、Podmanはデーモンレスアーキテクチャを採用しています。各コンテナは、実行ユーザーの直接の子プロセスとして起動され、runcやcrunといったOCIランタイムを利用します。 この設計により、常駐する特権サービスが不要となり、従来のLinuxプロセス管理やsystemdとの統合に近い構造になります。この違いは、セキュリティ、リソース管理、運用設計に影響を与えます。 イメージとレジストリ コンテナイメージは、Docker Hub、GitHub Container Registry、QuayなどのOCI準拠レジストリを通じて配布されます。 イメージはファイルシステムのスナップショットを層状に重ねた構造を持ち、各レイヤーは段階的な変更を表します。このレイヤー構造により、効率的な配布、キャッシュ、再利用が可能になります。 概念的に重要なのは「イメージの不変性」です。タグは変更可能ですが、ダイジェストはイメージ内容を一意に識別します。実務環境では、再現性とサプライチェーンの整合性を高めるため、可変タグではなくダイジェスト参照が推奨されます。 認証メカニズム、プライベートレジストリ、イメージの出所（プロベナンス）を理解することも重要です。安全なイメージ取得は、コンテナセキュリティの中核です。 コンテナの実行と管理 コンテナはイメージの実行時インスタンスです。コンテナはLinuxの名前空間（namespaces）とコントロールグループ（cgroups）によって分離されたプロセスであり、ホストカーネルを共有します。 コンテナは仮想マシンではありません。ハイパーバイザーではなく、ホストカーネルを利用して分離を実現します。 運用では、ライフサイクル状態（created、running、paused、stopped、removed）の管理、メタデータ確認、ログ取得、実行中プロセスとの対話などが含まれます。本番環境では、可観測性とライフサイクル統制が不可欠です。 コンテナネットワーク コンテナネットワークは、Linuxのネットワーク機能を仮想ネットワークとして抽象化します。デフォルトではブリッジネットワークに接続され、内部通信と外部公開を制御できます。 オーバーレイネットワークは複数ホスト間に拡張され、異なるマシン上のコンテナが同一論理ネットワーク上にあるかのように安全に通信できます。これはクラスタ環境や分散アプリケーションに不可欠です。 ストレージとボリューム コンテナストレージはCopy-on-Writeを用いたレイヤーファイルシステムに基づきます。各イメージレイヤーは読み取り専用で、コンテナ作成時に書き込み可能な薄いレイヤーが追加されます。このレイヤー内の変更は、コンテナ削除とともに消失します。 ボリュームはコンテナライフサイクルとは独立した永続ストレージを提供します。これにより、データと実行環境を分離できます。 設計力を高めるために ランタイム設計、ネットワーク抽象化、DNSベースのサービスディスカバリ、レイヤーストレージ、永続ボリューム、rootless実行といったコンテナアーキテクチャの理解は、安全かつスケーラブルな本番対応コンテナ基盤を設計するために不可欠です。 Dockerを実践的に学ぶ Dockerを実際に体験するには、Play with Docker Classroomを利用してください。リモートのDocker環境で実践演習が可能です。利用にはDocker Hubで無料作成できるDocker IDが必要です。 Docker ID取得後は、オペレーター向けまたは開発者向けのウォークスルーを選択できます。どちらも豊富な解説と実習を含んでおり、両方受講することを強く推奨します。 さらに、Jérôme Petazzoni氏とAJ Bowen氏による包括的な「Introduction to Docker and Containers」への参加も強く推奨します。 DockerとPodmanの互換性 Dockerコマンドの大部分は、dockerをpodmanに置き換えるだけで実行可能です。両ツールはCLI互換性を意図的に維持しています。 ただし、以下の違いがあります： Dockerは中央デーモン型（dockerd） Podmanはデーモンレス Podmanはrootless実行を前提設計 Podmanはsystemd統合が強力 DockerはSwarmを内蔵 PodmanはKubernetesとの親和性を重視（Pod概念） 次の学習ステップ Play with Docker演習後は、公式Dockerドキュメントでアーキテクチャ、ネットワークモデル、ストレージドライバ、セキュリティ機構を深く理解してください。公式ドキュメントは内部設計理解のための信頼できる情報源です。 並行して、DevOps Tools Engineer 2.0向け公式LPI Learning Materialsも学習してください。試験目標に沿った構成で、概念理解と実務能力を強化します。 << 本シリーズの前の記事を読む | 本シリーズの次の記事を読む >>

ブラウザによるデータ収集 本記事は、現代におけるデータ収集をテーマにした連載の一部です。前回の記事では、スマートウォッチやその他の個人用デバイスについて取り上げました。 ブラウザからデータを収集するサイトの多くは小売業者ですが、ブラウザには特有の技術的課題があるため、本連載ではあえて独立したセクションとして扱います。 クッキーの仕組みとその進化 ユーザーを追跡する古典的な手段は、サーバーから送られる符号化されたメッセージをブラウザに保存させる仕組みで、「クッキー（cookie）」と呼ばれています。この少し変わった名称には興味深い背景があります。 コンピュータプログラミングの初期には、開発者たちは特定の文字列をファイル内に埋め込むことでファイル形式を識別していました。たとえば、PostScriptファイルは必ず「%!PS-Adobe」という文字列で始まり、PDFファイルは「%PDF」に続いてバージョン番号が記載されます。こうした文字列は、ファイルを処理するプログラムにとって形式を判別するための手がかり、いわば「クッキー」のような役割を果たしていました。 ブラウザにおけるクッキーは、もともとはセッション管理を助けるために導入されたものです。同じサーバー内のページを移動してもログイン状態を維持したり、設定を保存したりできるようにするのが目的でした。 しかしやがて、サイト運営者は、クッキーを使えば繰り返し訪問するユーザーを識別できることに気づきました。これはマーケティングにとって大きな利点となりました。たとえば、過去の訪問時に靴の写真を閲覧していたことをクッキーで記憶し、次回の訪問時に靴の割引を提示するといったことが可能になります。 DoubleClickとデータの拡大 クッキーによって得られる情報は、DoubleClick（現在はGoogleの一部）が複数の提携小売業者に配信するクッキーを管理し始めたことで飛躍的に増大しました。 これにより、ある小売業者は、自社サイトで過去に閲覧した内容だけでなく、DoubleClickを利用している他の小売サイトで閲覧した内容まで把握できるようになりました。同社はブラウザ上の行動履歴に加え、大量の個人情報も保有しています。 「Do Not Track」はなぜ効果が薄いのか ブラウザの設定でクッキーを無効化することは可能です（その場合、利便性もプライバシー上の影響も同時に失われます）。しかし、一般に「Do Not Track」設定として知られるこの方法は、実際には効果が薄いと考えられています。 その理由は、現代のサーバーが非常に高度な技術を用いているからです。例えるなら、クッキーをやめたとしても、代わりにもっと洗練された追跡手法（いわばクッキーの代わりにクレームブリュレを差し出すようなもの）を使われてしまう、という状況なのです。 ブラウザ・フィンガープリンティング 最初の情報源は、ブラウザの「navigator」設定です。これは主にJavaScriptによって利用されます（なお、プライバシーなどの理由からJavaScriptを無効にする人もいます）。 navigatorに含まれる多くの項目は、個々のユーザーにとって特別な価値のある情報ではありません。しかし設定項目が非常に多いため、それらを組み合わせるとほぼブラウザごとに固有の特徴を持つことになります。 この情報収集は「ブラウザ・フィンガープリンティング（ブラウザ指紋採取）」と呼ばれ、クッキーを使用しなくても、ほぼ同じ精度でユーザーを識別することが可能になります。 IPアドレスとさらなる情報収集 すべてのサーバーは、ユーザーのIPアドレス（より正確には、インターネットプロバイダが設置した中継装置のIPアドレス）を把握しています。これにより、企業はユーザーのおおよその地理的位置を特定できます。 さらに、サーバーはブラウザやコンピュータに関する追加情報も収集できます。場合によっては、バッテリーの状態までも取得可能です。 まとめと今後 以上で、デバイスに焦点を当てた解説は一区切りとなります。本連載の残りの記事では、こうして収集された情報が、私たちの生活における大規模な組織や機関によってどのように利用されているのかを見ていきます。 << 本シリーズの前の記事を読む | 本シリーズの次の記事を読む >>

私とLinuxの出会い 私が初めてLinuxに触れたのは、大学のコンピュータサイエンスの学部課程でした。正直に言えば、決して華々しいデビューではありませんでした……。 混乱から手応えへ：初期の頃 それ以前から、MS-DOS環境でバッチスクリプトを作成していた経験がありました。趣味の延長のようなもので、ちょっとしたお小遣い稼ぎにもなっていました。そのため、コマンドライン自体は知っていました。 しかし、Linuxはまったく別物でした。最初は難解で、正直なところ心が折れそうになる存在でした。結局その科目は、スキルよりも粘り強さでなんとか乗り切り、ぎりぎりで合格しました。 卒業後、IBMに入社し、大手銀行の顧客先に常駐することになったことで、人生は思いがけない方向へ進みました。担当していたのは、銀行アプリケーションの非機能要件です。当初はパフォーマンス最適化に従事し、膨大なトランザクション負荷に耐えられるようシステムを調整していました。 そのような高い緊張感のある現場で、私はLinuxを単なるオペレーティングシステムとしてではなく、インフラの鼓動に直接触れる手段として捉えるようになりました。やがて業務の範囲はセキュリティ分野にも広がり、それが私のキャリアの方向性を形作ることになります。 挫折から魅了へ 同時期に、情報システムセキュリティの修士課程にも進学しました。平日は働き、週末は講義を受ける生活です。 このプログラムで、私とLinuxの関係は大きく変わりました。ほぼすべての演習がLinuxを前提としていたのです。深夜の課題と早朝の実習を繰り返すうちに、あれほど感じていた苛立ちは、いつしか強い興味へと変わっていました。 コマンドラインの美しさ、そしてその圧倒的な効率性に気づき始めたのです。マウスに触れずに問題を解決できることは、とても力強く感じられました。シェルスクリプトを書くたびに、ゼロからシステムを構築するたびに、自分が状況をコントロールできているという感覚が強まっていきました。 Linuxは、ハッカーの道具箱であり、設計者の設計図であり、そして基礎を教えてくれる教師でもありました。実践的な経験を通して、学部時代に欠けていた文脈がようやくつながったのです。現実のセキュリティ環境の中で、Linuxの柔軟性と奥深さは無視できない存在となりました。 かつては威圧的に感じられたものが、今では理にかなったものとして理解できるようになっていました。 私は、完全に夢中になっていました。 学習者からLinuxの伝道者へ 修士号を取得した後、地元の大学や短大でIT科目の非常勤講師を始めました。どの科目を担当しても、必ず実践的なLinuxスキルを取り入れました。IT教育には不可欠だと心から信じていたからです。 コマンドラインのスキルがきっかけでインターンや就職を勝ち取ったという元学生からの報告は、これまでの中でも特に嬉しい瞬間でした。面接でLinuxの知識が評価されたという話を聞くたびに、基盤づくりに貢献できたことへの満足感を覚えました。 やがて、Linuxの普及者としての役割は自然と広がっていきました。教室の中だけにとどまらなくなったのです。元学生からLPI認定について相談を受けるようになり（それがきっかけで私自身もLPIC-1を取得しました）、同僚からはシステムのハードニングやログ分析に関する社内ワークショップの依頼が来るようになりました。 さらに、非技術職のメンバー――プロジェクトマネージャーやアナリストなど――からも質問を受けるようになりました。私はこう説明しました。 「Linuxを理解することは、建築家が設計図を読めることと同じです。実際にコンクリートを流し込まなくても、構造を理解しているべきなのです。」 そして、素晴らしいことが起こり始めました。人々が実際に試し始めたのです。 VirtualBoxをインストールし、Ubuntuを立ち上げ、スワップサイズについて質問してくる。マネージャーが自信を持ってgrepでログを検索する。若手テスターがシェルスクリプトで作業の80％を自動化できると気づく。 私はインターンを指導し、ブートキャンプで教え、学生が安心して壊し、直し、学べるラボ環境を構築しました。 誰かが「自分には無理だ」から「これ、実は面白いかも」に変わる瞬間を見るたびに、あの頃の情熱がよみがえりました。 …そして原点へ 初めてlsと入力し、表示された内容が理解できなかったあの日から、もう何年も経ちました。「vimの終了方法」と検索して途方に暮れた日からも、ずいぶん時間が過ぎました。 今では、同僚が「ターミナルが怖い」と言うと、私は微笑みます。その恐怖がばかばかしいからではありません。それがすぐに魅了へと変わることを、私は知っているからです。 今でも私は教えています。必ずしも教室の中とは限りません。コーヒーを飲みながらメンティーに話すこともあれば、プロジェクトのキックオフでLinuxベースのコンテナを提案することもあります。あるいは、会話の中で静かにこう言うだけのこともあります。 「それ、スクリプトにできますよ。」 Linuxは単なるツールを与えてくれただけではありません。問題や構造、可能性を捉える新しい視点――ひとつの思考様式を与えてくれたのです。 少し前、ある技術カンファレンスで大学時代の恩師に再会しました。かつて私が恐れていた最初のLinuxの授業を担当していた教授です。 彼は微笑みながら言いました。「まだLinuxに苦戦しているのかい？」 私は笑って答えました。「実は……今は教えています。」 彼は眉を上げました。「そうなのか？」 「ええ。そして、かつての私のように怖がってしまう人が出ないようにしているんです。」 彼はしばらく私を見つめ、うなずきました。「いいことだ。それでこそあるべき姿だ。」 その通りです。まさに、そうあるべきなのです。 そして、はい。私は LPI Approved Trainer であることを誇りに思っています。 << 本シリーズの前の記事を読む | LPIの成功事例をさらに読む >>

CI/CDが支える現代ソフトウェア開発の基盤 ソースコードを実際に稼働するサービスへと変換するには、現代のスピード重視のソフトウェア開発の要求に応えるため、自動化された一連の工程を連携させ、可観測な形で管理する仕組みが必要です。 継続的インテグレーション（CI）および継続的デリバリー（CD）は、この変革を支える概念的・技術的な基盤です。バージョン管理に加えられたすべての変更が、自動的にビルドされ、テストされ、安全にリリースできる状態に準備されることを保証します。 LPI DevOps Tools Engineer 試験目標、とりわけ 目標701.4 においては、CI/CDは単なるツールの問題としてではなく、**開発・品質保証・本番環境の信頼性を結びつける運用上の規律（オペレーショナルディシプリン）**として位置づけられています。 Martin Fowlerによる継続的インテグレーションおよび継続的デリバリーに関する著作は、これらの実践がどのように発展してきたのか、そしてなぜデプロイメントパイプラインや現代のソフトウェア提供の中心的存在であるのかを理解するうえで、今なお重要な古典的参考資料となっています。 CI/CDパイプラインの構造 CI/CDパイプラインとは、ソースコードが実行中のサービスへと変換されるまでの構造化された経路を指します。 最初の段階はビルドです。ここではアプリケーションコードのコンパイル、依存関係の解決、バイナリ、パッケージ、コンテナイメージといった実行可能な成果物の生成が行われます。この段階では再現性が極めて重要です。同じ入力からは常に同じ成果物が生成されなければなりません。この決定性により、トレーサビリティの確保、ロールバックの簡素化、さらには企業環境や規制環境で求められる監査要件への対応が可能になります。 ビルドが成功すると、複数層の自動テストが実行され、技術的および業務的観点からシステムを検証します。 ユニットテスト：個々のコンポーネントを独立して検証し、迅速なフィードバックを開発者に提供します。 統合テスト：コンポーネント同士、あるいはデータベース、キュー、APIなどの外部サービスとの連携を確認します。 受け入れテスト：ユーザーの期待やビジネスルールを満たしているかを検証し、本番環境に近い環境で実行されることが多くあります。 これらのテスト層は、実行速度と信頼性のバランスを取りながら、継続的デリバリーの信頼性を支える基盤を形成します。 成果物管理と「ビルドは一度、デプロイは何度も」 テスト完了後、パイプラインは不変（イミュータブル）なビルド成果物を生成します。これらは再ビルドすることなく、バージョン管理され、保存され、各環境へと昇格（プロモーション）されます。 「Build once, deploy many（ビルドは一度、デプロイは何度も）」という原則により、ステージングで検証されたものと本番環境で稼働するものが完全に一致することが保証されます。 JFrog Artifactory や Sonatype Nexus といったアーティファクトリポジトリは、これら成果物の集中管理、トレーサビリティ確保、ライフサイクル管理を提供します。CI/CDプラットフォームと統合され、依存関係管理、セキュリティスキャン、監査可視性の向上を支援します。 Continuous DeliveryとContinuous Deployment Continuous Deliveryは、常にデプロイ可能な状態を維持することを保証します。一方、Continuous Deploymentは、検証済みの変更をすべて自動的に本番環境へリリースする仕組みへと発展させたものです。 実務では、これら二段階の自動化の間に承認ゲート、段階的ロールアウト、ポリシーチェックなどを設けることが一般的です。デプロイワークフローには、ステージング検証、性能・セキュリティ確認、段階的ユーザー公開、異常検知時の迅速なロールバックを可能にする監視統合などが含まれます。 これらの安全策により、運用リスクを最小化しながら頻繁なリリースを実現できます。これはDevOpsの重要な価値提案の一つです。 GitOpsの発展 GitOpsは、インフラやランタイム設定をGitリポジトリで管理される宣言的な資産として扱うことで、CI/CDモデルを拡張します。 手動でデプロイを行う代わりに、自動調整エージェントが実環境とGitで定義された理想状態を継続的に比較し、差異を修正します。この手法により、完全な監査性、Git履歴による簡易ロールバック、Kubernetesネイティブな運用モデルとの強い整合性が実現します。 その結果、GitOpsはクラウドネイティブ環境における継続的デリバリーの自然な進化形として広く認識されています。 キャッシュと成果物の効率性 ビルド成果物とキャッシュは、効率性維持の観点で重要な役割を担います。成果物はコンパイル済みバイナリやコンテナイメージなどの不変かつ追跡可能な出力です。一方キャッシュは、未変更の依存関係や中間レイヤー、既存コンポーネントを再利用することで処理を高速化します。 効果的なキャッシュ戦略は実行時間とインフラコストを大幅に削減し、再現性を損なうことなく開発者へのフィードバックを迅速化します。成熟したCI/CD環境では、キャッシュ性能と成果物の不変性のバランスが慎重に保たれています。 安全なデプロイ戦略 信頼性の高いデプロイには、リスク低減と可観測性向上のための運用ベストプラクティスが不可欠です。不変成果物、ステージングと本番の環境整合性、自動ロールバック、継続的ヘルスモニタリングが技術的安全網を形成します。 Blue-greenデプロイ、カナリアリリース、ローリングアップデートなどの戦略は、新バージョンを段階的に公開し、サービス可用性を維持しながら早期に問題を検出できるようにします。これらはコンテナ化やマイクロサービス環境で特に有効です。 セマンティックバージョニング バージョン識別は、major.minor.patch（例：2.0.18）形式のセマンティックバージョニングで標準化されます。 互換性を破壊する変更 → メジャー番号増加 後方互換の機能追加 → マイナー番号増加 バグ修正 → パッチ番号増加 CI/CDパイプラインはこれを活用し、リリースタグ付け、変更履歴生成、依存関係管理、成果物の環境間昇格を自動化します。 CI/CDプラットフォーム Jenkinsは歴史的に重要で広く採用されているオープンソースのオーケストレーションサーバーであり、豊富なプラグインエコシステムと柔軟なパイプライン定義を提供します。 GitLab CI/CDは、パイプライン実行、ソース管理、セキュリティスキャン、成果物管理を単一プラットフォームに統合し、ライフサイクル全体を可視化する統合型モデルを提供します。 両者は進化の道筋こそ異なりますが、DevOpsおよびLPI目標で示される同一のデリバリー原則を支えています。 アーティファクトリポジトリの役割 ArtifactoryやNexusは、継続的デリバリーにおける中核的な流通基盤として機能します。管理された保管、バージョン管理、昇格ワークフロー、セキュリティ分析との統合により、検証済みかつ追跡可能なソフトウェアのみが本番環境に到達することを保証します。 特に大規模環境や規制産業では、その重要性はさらに高まります。 DevOpsの中核としてのContinuous Delivery Continuous Deliveryは、自動化パイプライン、宣言的インフラ、成果物ライフサイクル管理、セマンティックバージョニング、段階的デプロイ戦略を統合することで、安全かつ迅速なソフトウェア提供を実現するDevOpsの運用的中核です。 これらの概念を習得し、実際のCI/CDプラットフォームでの実践経験を積み、LPI DevOps Tools Engineer向けLearning Materialsで学習することは、現代的なソフトウェアデリバリーにおける専門能力を確立する決定的な一歩となります。 公式Learning Materialsは試験目標に沿った体系的なガイダンスを提供し、Jenkins、GitLab、Artifactory、Nexusなどのツールを用いた実践は、現実のDevOps環境で求められる運用理解を強化します。 << 本シリーズの前の記事を読む | 本シリーズの次の記事を読む >>

この記事は、現代におけるデータ収集について扱う連載シリーズの一部です。これまでの記事では、自宅内のデバイスや自動車に関するデータ収集について取り上げてきましたが、今回はさらに個人的な領域に踏み込みます。 フィットネス機器によって収集されるデータは、プライバシーの観点から見ると非常に曖昧な位置にあります。たとえば、社会保障番号やパスワードのように、明らかに悪用されると危険な情報が含まれているわけではありません。しかしその一方で、個人に関するデータの中でも、これほど機微な情報はないとも言えます。 私の高齢の親戚は、ある日 Apple Watch から心拍数が異常に速いと通知を受けました。すぐに医師の診察を受けるよう勧められ、幸いにも迅速に予約を取ることができました。その結果、心房細動の薬を処方されました。これは、デバイスがいかに多くの個人情報を推測できるかを示す、シンプルな例です。 現在、人の声から認知症やうつ病の初期兆候を検出するための分析技術も、実験段階にあります。また、うつ病は歩き方の特徴からも検出できるとされています。 私は Apple Watch が収集しているデータを調べるために、一般消費者向けサイトと、より詳細な情報が掲載されている開発者向けサイトの2つを参照しました。そこから分かった、ウォッチが把握している情報は実に多岐にわたります。 心拍数、呼吸数、手首の温度、睡眠（睡眠時間および睡眠段階） 血中酸素濃度（以前は測定可能でしたが、法的理由により現在はこの機能は削除されています） 歩数および運動時の活動量 座っている時間 排卵周期（本人が任意で提供した場合） 歩行の安定性 呼吸の動き 運動中に消費したカロリー 心肺機能（酸素消費量、いわゆるVO2 Max） 上り下りした階段の数およびその速度 日光の下で過ごした時間 手洗いの頻度および時間 自動車メーカーと同様に、Appleはこれらの情報に加え、フィットネス評価を向上させるために利用者が任意で提供する情報や、（Apple Storeでのダウンロード履歴など）同社が把握しているその他の情報も組み合わせています。 私は Mozilla Foundation のサイトにも戻り、Apple Watch のプライバシーリスク評価を確認しました。同団体はAppleのポリシーを評価しつつも、あらゆるコンピュータと同様に、ウォッチ本体やその背後にあるデータ保存システムには脆弱性が存在する可能性があると警告しています。 次に、もう一つの人気デバイスである Fitbit が収集する情報についても調べました。このデバイスの主要なセンサーは、3軸加速度計（前後・左右・上下の動きを測定）とGPSです。フィットネス関連サイトおよびGoogleのFitbitヘルプセンターを参照し、次の情報が収集されていることが分かりました。 収集される動作データ：歩数、移動距離、上った階数 消費カロリー 安静時心拍数および心拍変動（HRV） 呼吸数 酸素飽和度（SpO2） 皮膚温度 これらの統計データを長期間にわたって追跡すると、（少なくとも理論上は）個人の健康状態、行動、生活習慣について多くのことが分かるとされています。 本シリーズの次回記事では、オンラインの世界に目を向け、Web上でのデータ収集について取り上げます。 <<このシリーズの前回の記事を読む

多くの産業が人工知能（AI）の活用による恩恵を期待していますが、現時点では、AI がどこで有効に機能し、どこで信頼できないのかについて、十分な理解があるとは言えません。3D プリンティングは、AI が精度やコストの改善にどのように役立っているのかを検討するうえで、非常に適した分野です。というのも、3D プリンティングには AI と相性の良い特性があるからです。たとえば、フィラメント内の材料比率から後処理に至るまで、成功した造形には多様な要因が関与し、それらは極めて複雑に相互作用します。さらに、結果は、メーカーが制御できない物理環境のわずかな変動にも左右されます。 本記事では、3D プリンティングにおける AI 活用に関する膨大な研究文献の中から、特に興味深い課題に直面した 3 つの研究プロジェクトを取り上げます。これらの論文で示された解決策は、わずか数年前のものであるとはいえ、特にトランスフォーマーや大規模言語モデル（LLM）の登場によって、すでに新しい技術に取って代わられている可能性もあります。しかし、著者たちがたどった思考プロセスそのものは非常に示唆に富んでいます。本記事で紹介する研究を総合すると、AI の活用は一種の「技術」や「芸術」に近いものであるということが見えてきます。 幅広いアプローチ AI の力は、微妙に相互作用する多数の特徴量を同時に扱えることにあります。論文「A data-driven machine learning approach for the 3D printing process optimisation（データ駆動型機械学習による 3D プリンティング工程最適化）」では、複数の 3D パラメータを同時に分析し、さまざまなプリンタに適用できる手法が提案されています。 この研究の目的は、印刷に関する 3 つのパラメータ――所要時間、フィラメントの長さ、完成物の重量――を算出することでした。 この論文で特に興味深い点は、2 段階の処理プロセスを採用していることです。まず、畳み込みニューラルネットワーク（CNN）が、押出幅やレイヤー高さといった一般的な 3D 設定を入力パラメータとして受け取ります。さらに研究者たちは、オブジェクトの表面積と体積という 2 つの計算パラメータを追加しました。 CNN で扱えるようにするため、面や頂点の数を削減する必要があり、アルゴリズムは各オブジェクトから 5,000 個の頂点をランダムに選択しました。 次に、CNN が生成した複数の新しいパラメータを既存の入力パラメータに加え、それらを別の 多層パーセプトロン（MLP） に入力しました。 研究者たちは、70 個の 3D プリントされたオブジェクトを用いてモデルをテストしました。各オブジェクトは 32 種類の異なる「パラメータセット」で評価されました。その結果、モデルは実際のテスト結果とよく一致し、成功しているように見えました。 自然を超えて 内部に穴やチューブを持つ柱は、実体のある柱よりも強度が高い場合が多くあります。これは、中心から離れた位置にある材料ほど圧力に対する耐性が高いためだと考えられます（ここで引用されている論文は、同じ質量の柱――一方は中実、もう一方は内部構造を持つもの――を比較しているのだと思われます。同じ直径であれば中実の柱の方が強度は高いですが、現実的には重すぎて材料の無駄が大きくなります）。 自然界には、内部が同心円状や格子状に分割された構造を持つ茎や支柱が数多く存在します。たとえば、竹、サボテン、ミント、羽軸、パピルス、貝殻、ハニカム構造などです。こうした構造を 3D プリント物に取り入れることで、性能を向上させることはできるのでしょうか。 従来の製造方法では、任意に複雑な格子構造は製造が非常に困難なため、ほとんど実用的ではありません。しかし、3D プリンティングであれば対応可能であり、実験も現実的になります。 論文「3D [...]

この記事は、現代におけるデータ収集をテーマとした連載の第2回です。第1回では、このテーマが持つ広範な全体像を紹介しました。今回は、データが実際にどこで、どのように収集されているのかという具体的な場面に目を向けていきます。 あなたの家は、あなたを追跡しているでしょうか。2023年の調査によると、「インターネット接続を持つ米国の一般家庭には、2023年時点で平均17台の接続デバイスが存在していた」とされています。米国の一部の家庭では（驚くべきことに）インターネット接続がない場合もありますが、大半の家庭では利用されています。そこで問題となるのは、こうした「スマート」デバイスが、私たちについてどのような情報を製造元に伝えているのか、という点です。 ここでいう「スマート」とは、組み込みプロセッサ、通信機能（WiFi、Bluetooth、インターネット）、そしてユーザーの行動やリクエストを解釈するために機械学習を用いる可能性のある分析機能を組み合わせたものを指します。 家庭内で最も多くのデータを収集するデバイスは、ストリーミング対応のテレビプレーヤーです。ケーブル会社やストリーミングサービスは、あなたが何を、いつ視聴したかを把握しており、そこからあなたの興味関心、つまりどのような人物で、何を好むのかについて信頼性の高い情報を得ることができます。 しかし、テレビの視聴行動はそれだけにとどまりません。あなたの居場所、どれくらいテレビを観るか、就寝時間など、さらに多くのことを示しています。こうした情報から、企業はあなたの学歴、就労状況などを推測することさえ可能です。 これらの情報は、比較的無害な形で利用されることもあります。たとえば、次に視聴しそうな北イタリア料理をテーマにしたグルメ番組や、また別の『ゲーム・オブ・スローンズ』風作品を推薦するためです。現在では、スタジオが新しい番組を企画する際にもこうしたデータが使われており、ジャンルの選定からキャスティングに至るまでの意思決定に影響を与えています。 この連載を通じて繰り返し目にすることになりますが、ストリーミングデバイスによって収集されたデータは、SNS上の消費者レビューなど、他の情報源からのデータと組み合わされます。さらに、そのデータは、収集時の活動とはほとんど、あるいはまったく関係のない企業に販売されることもあり、広告目的であなたの関心を極めて詳細にモデル化するために利用されます。 次に、あなたのことをよく知っているスマートデバイスとして挙げられるのが、音声起動型の録音デバイスです。Apple の画期的な Siri、Amazon の Alexa、Google Home Assistant などがこれにあたります。これらのデバイスは常にあなたの声を聞いていますが、ベンダーは「Hey Siri」のような呼びかけで明示的に起動されるまで、何も記録しないと約束しています。 しかし、これらのデバイスと会話している間、記録されるのはあなたの発した言葉だけではありません。声のトーン、他の人との会話、周囲の環境音なども含まれます。研究者たちは、これらのデバイスが、あなたが意図的に提供した以上の情報を捉えている可能性があることを指摘しています。 つまり、テレビサービスやスマートスピーカーは、あなたについて非常に多くの情報を記録しているのです。さらに近年では、多くの人が家庭内にさまざまな「スマートデバイス」を設置しています。たとえば、防犯カメラやビデオドアベル、エネルギー使用量モニター、入退室を把握する照明、朝起きる時間や夜に帰宅する時間を予測する家電、温度センサーなどです。 これらの新しい家電製品（照明、洗濯機、コーヒーメーカーなど）の多くは、先に挙げたスマートスピーカーを通じて起動・操作できます。その場合、スマートスピーカーの提供元が、あなたに関する情報を収集することになります。 メーカーは、ロボット掃除機が撮影した写真や使用パターンから、家の広さ、あなたが最も多くの時間を過ごす場所、さらにはライフスタイルに関するさまざまな手がかりを推測することができます。 最近私がダウンロードしたプリンタ管理用アプリでさえ、私のプリンタ利用状況に関するデータを収集しています。メーカーはそれを、顧客としてすでに保有している他の情報と組み合わせています（もっとも、私はプライバシーポリシーを読む程度には教育を受けているので、データ収集をオプトアウトすることができました）。 製造業者やストリーミングメディア企業が、あなたの生活の詳細な情報を得ることについて、特に気にしない人もいるかもしれません。しかし、ゾンビデバイスについては注意が必要です。ゾンビデバイスとは、通常、メーカーがアップデートの提供を終了することで、セキュリティ保護が不十分になったデバイスのことです。こうしたサポート終了については、マサチューセッツ州で提出された法案（私の選挙区代表であるデイブ・ロジャースによる提出）のような形で通知される場合があります。 最後に、電力会社もまた、1日の中でのあなたのエネルギー使用状況を追跡しています。これは社会的価値のある取り組みでもあります。電力会社は消費者の需要に合わせて発電量を調整したり、高価で汚染度が高く、気候変動の原因となる発電所を使用せざるを得ないピーク時間帯の消費を避ける方法を、消費者に提案したりできるからです。 しかし、ストリーミング動画企業、スマートスピーカー、各種デバイス、あるいは電力会社によって収集される、あなたの行動や生活スケジュールに関する情報は、あなたの収入、ライフスタイル、健康状態などについての推測を導き出すためにも利用され得ます。 次回の連載記事「あなたの車はあなたの何を知っているのか」では、データ追跡の舞台を屋外へと広げていきます。 << このシリーズの前の記事を読む

DevOps の世界は決して立ち止まりません。そして Linux Professional Institute（LPI）も同様です。DevOps Tools Engineer 認定試験 バージョン2.0 のリリースにより、LPI は試験内容を、現在プロダクション環境で実際に使われている技術――コンテナ化、クラウドネイティブアーキテクチャ、そして現代的な開発手法――にしっかりと合わせました。 この記事では、更新された最初の試験範囲である 701.1：モダンソフトウェア開発（Modern Software Development） を一緒に見ていきます。学習のためにも、実務での理解のためにも、頭の中に明確な全体像（メンタルマップ）を構築できるよう支援します。 多くの変更が加えられた一方で、変わらないものもあります。それは、強固なソフトウェアエンジニアリングの基礎は今でも重要であるという点です。比重 6 を持つ試験範囲 701.1 では、現代のランタイム環境に本当に適したソリューションを設計できることが求められます。つまり、サービスがデータ、セッション、セキュリティ、パフォーマンス、スケーラビリティ、信頼性をどのように扱うのかを、理論ではなく実践的な分散システムの文脈で理解している必要があります。 アーキテクチャの基盤：サービス、マイクロサービス、クラウドネイティブ設計 現代のアプリケーション設計は、サービス指向およびクラウドネイティブの原則によって大きく形作られています。バージョン 2.0 では、Service Oriented Architecture（SOA）を含むサービスベースのアーキテクチャ、特に マイクロサービス が強く重視されています。 アーキテクチャ理解を深めたいのであれば、Martin Fowler の仕事は非常に優れた参考資料です。彼と共著者たちは、アプリケーションアーキテクチャ、SOA やマイクロサービス、不変（immutable）サーバー、モノリスと結合度、そして疎結合の重要性についての記事を提供しています。これらの概念は、試験範囲全体にわたって暗黙的に登場します。 新しい認定試験では、コンテナ内で実行され、クラウド環境で自然に動作するソフトウェアを設計できることが明確に期待されています。これは、密結合されたモノリシックシステムからの脱却という、業界全体の現実的な変化を反映しています。 同時に、試験は現実も認識しています。レガシーシステムは依然として存在するという事実です。今回の試験では、レガシーなモノリシックソフトウェアを移行・統合する際のリスクを認識することが明示的に求められています。これは多くの組織が直面している課題を踏まえたものであり、革新と安定性のバランスを取った戦略的なモダナイゼーションが必要であることを示しています。 クラウドネイティブおよびコンテナファースト開発の採用 認定試験バージョン 2.0 における最も重要な更新点のひとつが、クラウドネイティブおよびコンテナファースト設計への明確なフォーカスです。これは単にアプリケーションをクラウドにデプロイするという話ではありません。弾力性、自動化、分散インフラの利点を最大限に活かすソフトウェアを構築すること、そしてコンテナで動作し、クラウドサービスにデプロイされるソフトウェアを設計できるスキルを示すことが求められます。 これらのスキルは、クラウドを単なるホスティング環境として使うだけでは不十分です。クラウドが持つ動的かつ分散された特性を最大限に活用できるよう、アプリケーションを設計する能力も含まれます。 Cloud Native Computing Foundation（CNCF）によると、クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドといった動的な環境において、スケーラブルなアプリケーションを構築することを可能にします。実際には、これは コンテナ化され、動的にオーケストレーションされ、マイクロサービスを中心に構成されたアプリケーション を意味します。 コンテナ向けの設計では、ステートレスなサービスと不変性（immutability） が重要です。各コンテナは理想的には 1 つの役割に集中し、容易に置き換え可能で、摩擦なく水平スケールできるべきです。この考え方は、耐障害性を高め、デプロイを簡素化し、自動化をはるかに効果的にします。 API、データ、ステート管理 分散システムにおいて、API はすべてをつなぎとめる「接着剤」です。試験では引き続き、REST を中核となるアーキテクチャスタイルとして、JSON を標準的なデータ形式として重視しています。 RESTful の原則を理解することは、HTTP メソッドを暗記すること以上の意味を持ちます。スケールし、進化し続けることができる、予測可能で一貫性のあるインターフェースを設計することが重要です。RESTful 原則に関する包括的な入門資料では、REST の基本的な制約条件から実践的な設計パターンまで、優れたチュートリアルとベストプラクティスが提供されています。 JSON:API のような仕様は、データ構造を標準化し、サービス間の相互運用性を向上させます。また、jsonapi.org では、JSON を用いた API [...]

DevOps Tools Engineer 認定資格 バージョン2.0について 2025年11月、Linux Professional Institute（LPI）は Linux Professional Institute DevOps Tools Engineer 認定資格のバージョン2.0 をリリースしました。本試験は、ソフトウェアを協調的に開発・提供するために使用される一連のツールを対象としており、ソフトウェア開発者とシステム管理者の双方のスキルを拡張する内容となっています。 DevOps Tools Engineer 認定資格の V2.0 アップデートは、現在の DevOps 実践により適合するよう、試験構成と全体的なビジョンを近代化したものです。オープンソースツールを用いてソフトウェア開発と運用を橋渡しするという中核領域はこれまでと変わりませんが、V2.0 では一部の試験範囲が再編成され、「更新ドラフト（updated draft）」として位置づけられています。これは、進化し続けるツールや手法に対応するため、カリキュラムが今後も修正される可能性があることを示しています。 V2.0 のリリースでは、試験内容が基礎から再構成・更新・近代化されました。V1 では、コンテナ、構成管理、インフラストラクチャ、CI/CD、監視といった、従来型の幅広い DevOps 分野を軸に構成されていましたが、V2.0 では、今日の実際のエンジニアリングワークフローにより密接に沿ったトラック構成が導入されています。新しい構成では、ソフトウェアエンジニアリング、コンテナ、Kubernetes、セキュリティ、可観測性（Observability）に重点が置かれており、現代の DevOps チームが日常的に依存している技術と実践を反映しています。 この新バージョンは、より明確な構成、洗練されたトピックの区分、更新されたツール要件を備えつつ、LPI の理念の中心であるオープンソース重視の姿勢を維持しています。 総じて、DevOps Tools Engineer V2.0 は単なる内容の改訂ではありません。それは、現代の DevOps の現実に合わせて認定資格そのものを再調整したものです。V1 との概念的な連続性を保ちながらも、その対象範囲、構造、提供方法を進化させ、より高速で自動化され、協調的な環境で働くプロフェッショナルを支援する内容となっています。 学習教材と本シリーズについて この認定資格の公式ラーニング教材は、非常によく整理されており、すでに LPI の Learning Portal で利用可能です。この教材は、試験範囲をより深く理解し、ツールを実際に操作しながら学び、明確な指針と自信を持って試験準備を進めたい方にとって、非常に優れたリソースです。内容はステップ・バイ・ステップで構成されており、認定資格取得までの道のりを、より楽しく、達成しやすいものにしてくれます。 本記事は、LPI ブログに掲載される導入シリーズの第1回目です。このシリーズでは、LPI DevOps Tools Engineer の試験範囲を順に巡っていきます。各トピックごとに、最も重要なツールやスキルを要約し、学習を始める際に役立つドキュメントを紹介していきます。 今後の記事を活用するための準備 これから公開される記事を読み進め、DevOps [...]

Linuxマシンの電源を入れたとき、裏側では何が起きているのか？ Linuxマシンの電源ボタンを押したとき、その裏側で何が起きているのか考えたことはありますか？サーバーの電源が切れている状態は、壮大なコンサートホールが静まり返り、暗闇に包まれているようなものです。ステージには誰もおらず、客席も空っぽです。 しかし電源ボタンを押すとき、あなたは単にスイッチを入れているのではありません。そこから、複雑で美しいパフォーマンスを始める合図を送っているのです。 デジタル交響曲の4つの楽章 このパフォーマンスは4つの楽章から成り立っており、静寂に包まれたホールを、生き生きとした交響曲へと変えていきます。それぞれの楽章には主役がいて、役割があり、そして輝く瞬間があります。 第1楽章：会場スタッフ（ファームウェア：BIOS / UEFI） 最初の一音が奏でられる前に、会場スタッフ（マシンのファームウェア）が暗いステージに姿を現します。彼らの最初の仕事は、建物そのものが安全であることを確認することです。 メインの電源系統を入れ、ステージ照明や安全装置をテストしながら、チェックリストを一つずつ確認していきます。これが POST（Power-On Self Test） です。もし会場が安全でないと判断された場合、スタッフはすべての作業を中止し、問題を報告します。 安全が確認されると、次はスケジュールの確認です。これには2つの方法があります。 旧来の方式（BIOS）いつも同じ場所、つまりステージ入口にある台帳の最初のページ（MBR：マスターブートレコード）を確認し、次の責任者を探します。 現代的な方式（UEFI）より洗練された方法で、オフィスにあるデジタルのスケジュール表（NVRAM）を確認し、そこからEFIシステムパーティション（ESP）内にあるステージマネージャーの部屋を直接指し示します。 第2楽章：ステージマネージャー（ブートローダー：GRUB2） 会場の安全が確保されると、ステージマネージャー（GRUB2）がスポットライトを浴びて登場します。彼らは一時的な存在ですが、非常に重要な役割を担っています。ショーの間ずっと居続けるわけではありません。 ステージマネージャーは、プログラム冊子（grub.cfg）を手にしています。そこには、現在のカーネル、過去のバージョン、リカバリーモードなど、実行可能な演目が一覧されています。 数秒後、メインとなる演目を選択し、演台を整え、譜面台に必要な楽譜（カーネルパラメータ）を置き、指揮者をステージに呼び出します。そして、何事もなかったかのように静かに建物を後にします。 第3楽章：指揮者と舞台スタッフ（カーネルと initramfs） 指揮者、つまり Linuxカーネル がステージ中央に立ちます。彼らはパフォーマンスの最初から最後まで演台に立ち続け、テンポ（スケジューラ）や音響（メモリ管理）を制御します。 しかしこの時点では、楽器はまだケースに入ったままで、演奏台も設置されていません。そこで指揮者はすぐに、舞台スタッフ（initramfs）を呼び出します。この専門の一時チームは、重要な初期設定作業を迅速にこなします。 楽器ケースを開けるストレージドライブを読み取るために必要な基本ドライバ（カーネルモジュール）を読み込みます。 演奏台を組み立てる本来のルートファイルシステムを見つけてマウントし、オーケストラが座る場所を用意します。 本物のステージが準備できると、switch root と呼ばれる操作が行われます。これにより、仮のステージは完全に消え、本物のステージが置き換わります。 第4楽章：コンサートマスターと演奏者たち（初期化システム：systemd） ここで指揮者（カーネル）は、演奏者たちの統率をコンサートマスター（systemd）に引き継ぎます。最初のプロセス（pid 1）として、コンサートマスターはオーケストラ全体の登場を指揮します。 旧来のコンサートマスター（SysVinit）は、演奏者を一人ずつ呼び入れていました。まずバイオリン、次にチェロ、その次にフルート……という具合で、着実ですが時間がかかります。 一方、systemdは現代的な名手です。どのパートが同時に登場しても問題ないかを正確に把握しています。コンサートマスターの鋭い合図とともに、オーケストラは次のように登場します。 打楽器（ジャーナル／デーモン）ログ記録サービスが、リズムを刻むかのように動き始めます。 弦楽器（ミドルウェア）NetworkManager などのサービスが起動し、ステージと外の世界をつなぐ調和を織り成します。 木管楽器（ユーザーアプリケーション）最後に、Webサーバー、オーディオプレーヤー、データベースといった複雑な旋律が奏でられます。 すべてが同時に、連携し、正確に、そして圧倒的な美しさで進行します。 グランドフィナーレ わずか数秒のうちに、静寂は調和へと変わります。コンサートホールは生命を帯び、照明は輝き、交響曲は最高潮に達します。 観客であるあなたの目の前には、ログインプロンプトという形で幕が上がります。オーケストラは準備万端、あなたの指示を待っています。 静まり返っていたホールは、見事な連携の結晶へと姿を変えました。それこそが、4つの楽章で構成されたLinuxのブートプロセス なのです。 さらに詳しく知りたい方へ ブートプロセスとの具体的な関わり方については、LPIのLearningサイトにあるガイドをご覧ください。