検索結果

2025年12月12日（金）12:00より、LPI日本支部主催のWebinar「WDE試験合格に重要 JavaScript/Node.js/データベース」を開催します。 本ウェビナーでは、堀 光 様が詳しく解説します。 今回は、LPI 認定試験 (Web Development Essentials)の合格に向けて Webシステム開発で使用されるJavaScriptやNode.js、データベースについて解説します。 クライアント側の動的処理やサーバー側での処理を、講義と実習を通して学習します。 クラウド上の仮想マシンによる演習も用意されているので、Webシステム開発をより実践的に学ぶことができます。 登録はこちらから!

2025年11月29日（土）11:00より、LPI日本支部主催のWebinar「＜改訂版＞【学生・初心者向け】Webエンジニアになろう～WDEを習得！④Node.js入門編〜」を開催します。 本ウェビナーでは、かわむら かな 様が詳しく解説します。 今回は、10月18日(土)に開催されたOSC Online/Fallで講演した Web開発エンジニアになるための初級講座、Node.jsとExpress編の内容をアップデートしてお届けいたします。 登録はこちらから!

このシリーズの前回の記事では、ウェブページをダイナミックにし、エンドユーザーとのインタラクションを可能にするフロントエンド・プログラミング言語、JavaScriptについてお話した。 JavaScriptは長年にわたってサーバーサイドの機能も拡張し、バックエンドのプログラミングに応用されてきた。 そこでNode.jsの出番となる。 バックエンドプログラミングのためのNode.js Node.jsは、JavaScriptで書かれたプログラムを実行することで、ウェブサーバーで受け取ったリクエストを処理できる実行環境だ。 Node.jsは、もともとクライアントサイド言語であったJavaScriptを、他のプログラミング言語と同じようにブラウザの外で実行できるようにした本格的な開発プラットフォームである。 本来はブラウザーの中だけで実行されるはずだった言語が、今ではブラウザーの外で実行されるのだ。 このことから、以下のような多くの利点が生まれる： 学習が容易： すでにJavaScriptに慣れ親しみ、クライアント側のプログラミングに取り組んできた開発者は、サーバー側のアプリケーションを開発するために別のプログラミング言語を学ぶ必要はない。 すでにJavaScriptをマスターしているフロントエンド開発者は、それほど苦労することなく、アプリケーションのバックエンド部分に簡単に取りかかることができる。 完全かつ機能的なアプリケーションを作成する能力： JavaScriptという1つのプログラミング言語の知識だけでも、クライアントサイドとサーバーサイドの両方の開発に精通したフルスタック開発者として働くことが可能です。 これにより、包括的で完全に機能するアプリケーションを作成することができる。 様々なアプリケーションを作成可能 JavaScriptコードを実行できる環境があれば、ウェブブラウザに依存しないスタンドアローンプログラムを作成することができます。 これにより、さまざまなタイプやシナリオのアプリケーションを作成する可能性が広がる。 しかし、なぜNode.jsはこれほどまでに開発者に愛されているのだろうか？ 前述の利点に加え、Node.jsはオープンソースでクロスプラットフォーム環境であり、世界中の開発者の大規模なコミュニティを誇っている。 さらに、非同期、ノンブロッキング、シングルスレッド、イベントドリブンI/Oモデルに基づいており、高いパフォーマンスと優れた実行速度を保証します。 クライアントからのリクエストを効率的に管理する。 Linux Professional Institute (LPI)のWeb Development Essentials認定資格は、このシリーズのコンテンツに特化しており、簡単なNode.jsアプリケーションの作成を段階的にガイドしています。 さらに、HTML、CSS、JavaScriptを使用してウェブページを作成したことがあれば、アプリケーションのバックエンドロジックの構築を開始し、特定のユーザーリクエストに対してサーバーがどのように応答すべきかを定義することができます。 アプリケーションの強化方法 Node.jsプロジェクトでは、他の開発者によって作成されたさまざまな無料のリソースやツールを利用して、追加機能を組み込んだり、生産性を向上させたり、作業を容易にしたりすることができます。 npmはNode Package Managerの略で、Node.jsプラットフォームのパッケージ・マネージャーです。 コマンドラインインターフェイスを通じて、パッケージ（他の開発者が作成した、特定の機能を実装するビルド済みのプロジェクト）のインストール、削除、管理を行うことができる。 npmはNode.jsパッケージの大規模なオンラインリポジトリで、それぞれが独自の機能を備えていると考えてください。 数え切れないほどあるパッケージの中には、データベースとのやりとりに特化したものもある。 この連載の第1回で述べたように、バックエンド・プログラミングは、データベースとの統合を含め、エンドユーザーから直接見えないすべての側面を包含する。 アプリケーションが外部データにアクセスする必要がある場合、ほとんどの場合データベースを通じてアクセスすることになる。 LPIのWeb Development Essentialsでは、リレーショナルデータベース管理システム（RDBMS）を実装したソフトウェアライブラリであるSQLiteを特に取り上げています。 このタイプのデータベースでは、データは相互に接続されたテーブルに格納され、シンプルで直感的なクエリを使って照会することができる。 データベース照会 リレーショナル・データベースを自由に使えるようになったとき、そのデータベースに対してどのような操作を行なえばよいのか悩むかもしれない。SQLはStructured Query Languageの略で、リレーショナルデータベース内のデータを操作するためのクエリ言語です。 非常に人気があり、ユーザーフレンドリーな言語である： テーブルの作成と削除 スキーマと呼ばれる、各テーブルで使用可能なフィールドとデータタイプを定義する。 テーブルのデータを更新する テーブルの行の挿入と削除 情報の取得 データベースの保守と最適化 これで、リレーショナル・データベースがSQLデータベースとも呼ばれる理由が明らかになった！ 開発者がSQLを使うのは、SQLがさまざまなプログラミング言語と非常にうまく統合できるからだ。 例えば、Node.jsでSQLiteを使うには、先に述べたnpmパッケージ・マネージャーを使ってモジュールをインストールするだけでよい。 これをインストールすると、リレーショナル・データベースの作成と保守を可能にする一連の関数にアクセスできるようになる。 関連するテーブルに情報を格納するリレーショナル・データベースに加え、NoSQLデータベースとも呼ばれる非リレーショナル・データベースもある。 これらはより柔軟なスキーマを持ち、バックエンドアプリケーションでも同様に使用できる。 非リレーショナル・データベースは、特定のアプリケーションと格納されるデータに最適化されたストレージモデルを使用する（例えば、情報は単純なキーと値のペアとして格納できる）。 この種のデータベースは、開発が容易で高性能、優れた柔軟性と拡張性が特徴である。 以下の表は、バックエンドアプリケーションで一般的に使用される、最も一般的なリレーショナルデータベースと非リレーショナルデータベースの一覧です： SQL Database NoSQL Database Microsoft SQL Server MongoDB SQLite CouchDB MySQL Redis MariaDB PostgreSQL   SQL言語とSQLiteデータベースに慣れたら、練習がてら非リレーショナル・データベースでデータを操作し、その長所と短所を発見してみよう。 次はどうする？ 今回と前回の連載では、WDE認定資格でカバーされる主な技術（HTML、CSS、JavaScript、Node.js、SQL）と、Web開発者としての第一歩を踏み出すためのプログラミング環境について分析してきました。 まだ解明されていないのは、どの学習リソースが実際の認定試験に最も適した準備ができるかということだ。 これからの連載では、Web [...]

In previous discussions about DevOps tools, we explored container virtualization and how containers transformed the way applications are packaged and deployed. One of the major advantages of containers is their extremely fast startup time combined with minimal resource overhead compared to traditional virtual machines. Because containers share the host [...]

While Docker makes it easy to start and manage containers, there must still be a base system hosting the containers. These systems form the infrastructure on which containers run and are covered by objective 702.3 of the DevOps Tools Engineer exam. Container images are the foundation of modern cloud-native infrastructure. [...]

本記事は、現代のデータ収集について解説する連載の一部です。前回の記事では、小売業者がどれほど大量の情報を収集しているかを紹介しました。それと比べると、金融機関はかなり控えめに見えます。私が調べた資料の中には、銀行が顧客の性格や美的嗜好に興味を持っていると示すものはありませんでした。 一方で、銀行が収集する情報は、詳細な金融情報や機密性の高いデータであり、もし情報漏えいが発生した場合には、非常に大きな被害につながる可能性があります。例えば、「氏名、住所、電話番号、社会保障番号、納税者識別番号、セキュリティコードやアクセスコードを含まない金融口座情報、生年月日」などが含まれる場合があります。ただし、本記事では主にデータの本来の利用目的について説明しており、セキュリティ攻撃のリスクについては詳しく扱っていません。これらはまた別の重要な問題であり、悪用の可能性という新たな側面を加えるものです。 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による高速化を利用できます。 次回の記事では、実際に利用されているデータベース製品をいくつか取り上げていきます。