検索結果

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）をここに発表いたします。

通常、個々の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による高速化を利用できます。 次回の記事では、実際に利用されているデータベース製品をいくつか取り上げていきます。