検索結果

本シリーズの第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）をここに発表いたします。

通常、個々のDockerコンテナは1つのプログラムを実行します。しかし、マイクロサービスアーキテクチャでは、アプリケーションは複数のコンテナを組み合わせて構成されるのが一般的です。各コンテナが特定の機能を担い、それらが集まってアプリケーション全体を構成します。これらのコンテナの作成や維持を調整するのが、コンテナオーケストレーションツールの役割です。 Docker ComposeとPodman Composeは、マルチコンテナアプリケーションを定義・実行するために広く採用されているツールです。これらを使うと、アプリケーション全体の構成を1つのYAMLファイルに記述でき、1つのコマンドで複雑な環境を立ち上げることができます。それぞれの仕組みと違いを理解することは、現代のLinuxシステム管理およびDevOps実践において不可欠です。 Docker Compose Docker Composeはクライアント・サーバーモデルに基づいています。docker compose コマンド（または従来の docker-compose バイナリ）は、ホスト上で動作するDockerデーモン（dockerd）と通信します。デーモンはComposeファイルに定義された内容に基づき、コンテナ、ネットワーク、ボリュームを作成します。 Docker Composeは「プロジェクト」という単位でリソースを管理します。デフォルトでは、プロジェクト名はComposeファイルが存在するディレクトリ名から決定されます。同一プロジェクトに属するコンテナ、ネットワーク、ボリュームには共通のプレフィックスが付与され、まとめて管理しやすくなっています。 Podman Compose Podman Composeは根本的に異なるアプローチを採用しています。Dockerと違い、Podmanはデーモンレスです。常駐バックグラウンドサービスに依存しません。 各コンテナは、コマンドを実行したユーザーの直接の子プロセスとして起動されます。そのため、特権昇格なしに非rootユーザーでコンテナを実行できます。 YAML Composeファイル Composeファイルは、アプリケーションのサービス、ネットワーク、ボリュームを記述するYAMLドキュメントです。バージョン3以降、フォーマットはDocker ComposeとDocker Swarmで統一されています。最新版仕様では version キーは必須ではありませんが、明示的に記載することがベストプラクティスとされています。 最小構成の例： version: '3.8' services: web: image: nginx:latest ports: - "8080:80" この設定は、web というサービスを定義しています。 servicesアプリケーションを構成するすべてのコンテナを列挙します。 webサービス名。内部ネットワーク上でのホスト名としても使われます。 image: nginx:latest公式Nginxイメージの latest タグを使用してコンテナを作成します。 portsコンテナのポートをホストに公開します。 "8080:80"ホストの8080番ポートを、コンテナ内の80番ポートにマッピングします。 アプリケーションの実行 Docker ComposeやPodman Composeは、宣言的な設定を読み取り、必要なネットワーク、ボリューム、サービスコンテナを正しい順序で自動作成します。これにより、一貫性、再現性、ライフサイクル管理の簡素化が実現し、マルチコンテナアプリケーションのデプロイや保守が容易になります。 主なDocker Composeコマンド： # すべてのサービスをバックグラウンドで起動 $ docker compose up -d # 実行中サービスの確認 $ docker compose ps # ログの表示 $ docker compose logs -f # 停止して削除 $ docker compose [...]

本記事は、現代のデータ収集について扱う連載の一部です。これまでの記事では、ロボット掃除機や腕時計、ウェブブラウザなど、さまざまなデバイスを取り上げてきました。今回は、そうしたデータが最終的にどこへ集まっていくのかを見ていきます。 本記事は、この連載の中でも特に内容が広範かつ複雑です。あなたの家の近所にある小さな商店ではないかもしれませんが、チェーン店や大規模な小売業者は、まさに「飽くなき」情報収集者です。 小売業者の最大の関心は、あなたの喉元をつかんで無理やり商品を買わせることではありません。むしろ、収集されたデータの多くは、仕入れ、マーケティング、棚割りなどの企業運営において、集計データとして活用されます。つまり、冬にティッシュが品切れになるのを防いだり、酢が油の隣にきちんと並んでいるようにしたりするために使われるのです。 小売業におけるデータ収集の基本を理解するには、「小売マーケターが顧客について知っておくべき指標」に関する記事が参考になります。また、データサイエンス企業Tredenceのサイトでは、小売顧客分析とその活用方法について説明されています。 実は、顧客追跡には長い歴史があります。デジタル時代に始まったわけではありません。ある歴史的調査によれば、データ収集が本格化したのは1980年代、店舗にバーコードスキャナーが導入されてからだとされています。 2000年代に入ると、データは複数の「チャネル」から収集されるようになりました。顧客の好みを把握するための消費者アンケートは以前から活用されてきましたが、現在ではさらに、居住地、店舗までの移動時間、購入のタイミングや頻度、支払い方法（クレジットカードなど）、セールへの反応といった情報も加えられています。最近では、オンライン投稿内容を確認する「ソーシャルデータ」も取り入れられています。 別の記事では、小売顧客データを「4つの基本的な種類」に分類しています。すなわち、本人確認情報（アイデンティティデータ）、購入に関する記述データ、本人確認情報と購入データを結びつけて「行動を反映したより深いパターン」を導き出す行動データ、そして顧客のフィードバックから得られる「顧客が何を考えているか」を示す定性データです。 今日のように金融情報や個人情報を含む広範なデータ収集が拡大してきた経緯は、マッケンジー・ファンク著『The Hank Show: How a House-Painting, Drug-Running DEA Informant Built the Machine That Rules Our Lives』に詳しく描かれています。本書は、現在の米国で小売業者、銀行、政府が利用しているデータ基盤を築いたハンク・アッシャーの伝記であり、読み物として面白いだけでなく、示唆にも富んだ内容です。LexisNexisも彼の遺産の一部です。 店舗内では、Bluetooth接続やカメラによって、あなたが何を見ているのかまで把握される場合があります。（もちろん、カメラはスタッフ保護や万引き防止の目的でも設置されています。）より広い視点からの別の記事では、ブラウザの利用（本連載の後半で扱います）や、店舗内での位置情報や視線追跡技術の活用についても触れられています。 こうしたデータのさまざまな活用方法については、別の記事で一覧化されています。 私たち夫婦は最近引っ越しましたが、最初のホーム用品カタログが届くまでに3週間半しかかかりませんでした。もちろん、オンラインでいくつか注文もしましたし、住所情報はあっという間に広まります。 では、小売業者はどれほどあなたのことを詳しく知ることができるのでしょうか。その一例が、行き過ぎた行為により罰金を科された企業の事例です。 「情報コミッショナー事務局（ICO）は、カタログ小売業者Easylife Limited（以下『Easylife』）が、顧客の同意なしに145,400人について推定される健康状態をプロファイリングしていたと認定しました。これは、Easylifeのヘルスカタログで購入された特定の『トリガー商品』に基づくものでした。たとえば、顧客が瓶のふた開け器や食事用トレイを購入すると、Easylifeはその顧客が関節炎である可能性があると推測し、グルコサミン配合の関節パッチを販売するために電話をかけていました。」 このEasylifeの事例は裁判で事実認定されています。一方、有名な「Targetのおむつ事件」については、一部の研究者がその正確性に疑問を呈しています。 次回の記事では、金融機関に話題を移します。 << 本連載の前回記事を読む

機械学習であれ、LLM（大規模言語モデル）のような比較的新しい技術であれ、AIについて語る人は皆、AIが膨大な量のデータを必要とすること、そしてそのデータがこれまでとは根本的に異なる方法で活用されていることを指摘します。現在、何千もの新しいデータセンターが建設されており、その規模もますます大型化しています。 では、その莫大なデータはどのように保存されているのでしょうか。この新しい時代におけるデータベースとは、どのような姿をしているのでしょうか。 実は、従来からあるデータベースの中には、AI向けに拡張されたデータ型やAPIを備えて「新しく生まれ変わっている」ものもあります。一方で、まったく新しいタイプのデータベースも登場しています。本記事では、世界中のデータベース開発者がAI革命の熱狂の一端をつかもうとどのように動いているのか、そして現在の主要な選択肢には何があるのかを見ていきます。 すべてはベクトルである AIデータの特性と、その処理・保存方法を理解するには、「ベクトル」という概念に焦点を絞る必要があります。 高校で線形代数を学んだことがある人なら、ベクトルや行列を習ったはずです。コンピューティングの文脈で言えば、ベクトルとは単なる配列、つまり浮動小数点数の順序付き集合です。重要なのは、各要素が現実世界の何らかの側面を表している点です。たとえば、ある値は年齢、別の値は身長、また別の値は体重を表すかもしれません。 このため、ベクトルの各要素は「次元（ディメンション）」と呼ばれ、概念的には多次元空間上の一点を表します。AIモデルが顧客の属性や機械部品の故障要因などを考慮する際に、データサイエンティストが「次元」という用語を使うのはこのためです。 ベクトル演算は、機械学習やLLMにとって非常に効率的です。これらの技術はいずれも「どれだけ似ているか／異なるか」という概念に強く依存しているからです。たとえばLLMは、スペイン語で一般的な定冠詞「el」を構成する文字EとLの関連性を理解します。同じ文字はフランス語でも似た関係を持ち、そこでは「le」という冠詞になります。 より高い抽象度では、LLMは犬とオオカミの類似性を認識し（時には混同しながら）、犬と猫よりも犬とオオカミのほうが似ていることを学習します。 AIにおける類似性や差異は、数学的にはベクトル間の差として表現されます。差の計算方法には、ユークリッド距離、マンハッタン距離、コサイン類似度、内積などさまざまな手法があります。犬とオオカミのように似たベクトル（「埋め込み（embedding）」とも呼ばれます）を見つける処理は、「ベクトル類似検索」と呼ばれます。 さらに、ベクトルや多次元構造（テンソル）に対しては、ガウスの消去法のような高度な演算も開発されています。また、「チャンク化（chunking）」と呼ばれる処理では、データの一部を小さな文書単位にまとめ、それらを比較して内容の類似性を見つけます。 現在、ベクトル型を定義するデータベースは増え続けています。インターフェースは製品ごとに異なりますが、将来的には標準APIへと収束し、SQLもテキストからベクトルへの変換といった重要な操作を表現できるよう拡張されると私は予測しています。 デジタルデータとしてのベクトルは、従来のデータと同様にデータベースの機能を活用できます。検索を高速化するためにインデックスを作成したり、圧縮（さまざまな最適化を含む一般的な概念）によって保存容量や冗長性を削減したりすることが可能です。 AIデータ処理に特有の要因 機械学習やLLMの開発にデータを利用することは、従来のデータ処理よりもはるかに複雑です。AIは膨大な量のデータを必要とするためです。 従来の分析は、たとえば小売業者が顧客の年齢と購買行動の相関を調べるといったように、主に組織内部のデータを対象としていました。しかし、多くの組織は機械学習に十分なデータを単独では保有しておらず、LLMに至ってはなおさらです。そのため、現代のAIは広範囲からデータを収集します。（現在、多くのコンテンツ制作者がAI開発企業に対して訴訟を起こしている背景には、こうした事情があります。なお、私が関わった書籍もAnthropic著作権和解に関連しています。） データ保存についても同様の傾向があります。AIモデル構築のために収集したすべてのデータを保存できる組織はごくわずかです。しかも、それらの組織はデータセンター建設をめぐって激しく競争しています。ほとんどの組織は、AIの基盤となる重要なベクトルデータ（埋め込み）を生成する非常に複雑なシステムを自前で構築することすらありません。代わりに、OpenAI、GoogleのGemini、Claudeといった強力なAIプラットフォームを利用します。 LLMの誤りや極端に不正確な結果（「ハルシネーション」）は、登場当初からユーザーを失望させ、ときには不安にさせてきました。また、オンライン上の情報が少ない珍しいテーマでは、一般的なテーマよりも精度が低いことも指摘されています。 そこで近年、開発者は「検索拡張生成（RAG：Retrieval Augmented Generation）」と呼ばれる手法で改良を進めています。 RAGの基本的な考え方は、インターネット上の玉石混交の情報を無差別に利用するのではなく、信頼性が検証されたデータベースを活用してモデルを補強し、より正確な回答を生成するというものです。RAGは現在「リアルワールドモデル」と呼ばれるアプローチの中核的要素となっています。 また、「ドメイン特化型言語モデル（DSLM）」という用語も広まりつつあります。これは特定分野に焦点を当てたモデルを指し、「ドメイン特化言語」など他分野の概念とも呼応しています。 素人目には、「信頼できるデータを使う」というのは当然の発想に思えます。しかし哲学的には、これはAIの大きな方向転換です。1950年代から、技術楽観主義者たちは汎用人工知能（AGI）を目指してきました。AIが人間と同等、あるいはそれ以上の知性を持つことを夢見ていたのです。 しかし現在、RAGやリアルワールドモデルへの移行は、開発者が実用的な方向へ舵を切り直していることを示しています。 一方で、AIコンサルティング企業Peripety LabsのCEOであるMark Hinkle氏は、AGIという枠組み自体に疑問を呈しています。「AGIは本質的ではありません。目標は人間並みの知能ではなく、単純作業や危険作業をデジタル従業員に任せられる十分な能力を持つことです。RAGは開発者が本当に役立つものを構築している証です」と述べています。 現在、特定分野で正確な知識表現を求めるユーザーは、まず主要AIベンダーから一般的なベクトルセットを取得し、そこに自組織の内部データ（研究成果、SNS投稿、調査結果など）を追加して独自の洞察を生み出します。 関連ライブラリと今後 本記事ではベクトルが提供する基本操作を紹介しました。Faiss（C++およびPython対応）は、ベクトル演算を行うオープンソースライブラリの一例で、GPUを活用して処理を高速化できます。 LangChain（Python）やLlamaIndex（PythonおよびTypeScript）も代表的なオープンソースライブラリです。これらはオンラインAIサービスやWikipediaなどの大規模データセットを活用し、AIアプリケーション開発を支援します。いずれもGPUによる高速化を利用できます。 次回の記事では、実際に利用されているデータベース製品をいくつか取り上げていきます。

コンテナ仮想化と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環境で求められる運用理解を強化します。 << 本シリーズの前の記事を読む | 本シリーズの次の記事を読む >>