はじめに こんにちは、サイオステクノロジーの小沼 俊治です。 今回は、AIを活用した RAG アプリケーションの仕組みを無料で体験できるハンズオン環境 を用意しました。 このハンズオンでは、 LangChain 、LLM に PC 内のローカルで動かす Open source LLM 、ベクトルデータベースの Milvus といったオープンソースのプロダクトを使用します。 学習は、JupyterLab（Jupyter Notebook） の Notebook 形式でステップごとに用意した教材 を使って進めます。 教材はステップ1から5までで構成しており、ステップ1から4では、外部に存在するデータの収集からデータを活用した回答生成まで、RAG を構成するモジュールを作成しながら一連の流れを学習します。集大成となるステップ5では、これまでに作成したモジュールを組み合わせて Web アプリケーションを構築し、アプリケーションの利用を通じて RAG を体験します。 LLM はローカルで動かすので、少々（PC の）スペックは必要ですが、トークン数などのコストを気にする必要はありませんので、思い存分、体験と学習に挑んで頂けると思っています。 構成概要 ハンズオン環境の構成 筆者が動かした際の主な構成要素は以下の通りです。 Windows 11 Professional WSL 2.5.9.0 Ubuntu 24.04.3 LTS Docker Engine 28.5.1 ハンズオンを構成する環境は以下の通りです。 教材を活用しながら学習を進める環境として、JupyterLab で LangChain を使う Python 環境を Ubuntu に構築します。 RAG の処理で必要となる Embedding や Open source LLM などのモデルは、Huggin Face からダウンロードして取得します。 拡張検索に必要となるデータを蓄積するベクトルデータベースには、Milvus を「milvus-standalone」、「milvus-etcd」、「milvus-minio」コンテナで構築します。 Milvus をビジュアル的に管理できる Web UI 管理ツールの Attu も「milvus-attu」コンテナで構築します。 環境構築や各種設定に使用するそれぞれのファイルは、以下の GitHub リポジトリで公開しています。 https://github.com/Toshiharu-Konuma-sti/hands-on-rag-with-langchain $ tree ~/handson/hands-on-rag-with-langchain/ hands-on-keycloak/ |-- container/ …… 「環境構築」章でコンテナ作成で使う素材 | |-- docker-compose-attu.yml | : | |-- setup/ …… 「環境構築」章でツール準備の環境準備に必要な素材 | |-- SETUP_HANDS-ON.sh | : | `-- try-my-hand/ …… 「ハンズオン実施」章で教材を進める環境 |-- cmd01-before_python_virtual_env.sh |-- cmd02-start_jupyterlab.sh | |-- data/ …… ハンズオンでベクトル化する元データの素材 | `-- recurrent_navi_tyo.xlsx | |-- lesson/ …… ハンズオンで利用するステップごとの教材 : : RAG の仕組み 教材でハンズオンを始める前に、教材を構成する各ステップの元となる RAG の仕組みを理解します。 仕組みを表したイラスト アニメーション版（流れを表現） 静止画版（全体像を表現） 仕組みの流れを説明 図中の1から2はベクトルデータベースに類似検索に利用するデータの蓄積フェーズを意味し、 図中の3から9はベクトルデータベースに蓄積されたデータを類似検索で活用する応用フェーズを意味します。 日々の経済活動を通じて、以下をはじめとするデータが企業のシステムに溜まります 販売する商品の在庫管理情報や売上データ 経済取引を記録する会計データ 企業に関わる人材を把握する社員情報や顧客情報 企画提案、商品説明、および企業説明等で作成されたドキュメントファイル など 企業に溜まったデータを検索に活用するために、以下をはじめとする加工を施しながらベクトル化して蓄積します 検索効率が向上するサイズにデータを細切れに分割するチャンキング ベクトルデータベースで類似検索が出来るように数値ベクトルに変換するエンベディング 必要に応じて検索効率を向上させるため欠損値の削除や補完、値形式を揃えるクレンジング 日々の業務活動を進めるに当たり不明点があれば質問を投げかけます 投げかけられた質問をエンベディングしてベクトルデータベースに対して類似検索します 投げかけられた質問に関連するデータを類似検索結果として戻します LLMに回答を生成を依頼するために、依頼向けテンプレートに質問と類似検索結果を付与してプロンプトを作成します 質問に回答するためにプロンプトを用いてLLMに回答案の作成を依頼します LLMが生成された回答案を戻します LLMから戻された回答案を整形して質問者に回答を戻します 事前準備 Hugging Face のアカウント準備 Hugging Face より Embedding Model や Open source LLM を取得して利用します。取得には事前に、アカウント登録、Access Token 発行、および Model の利用申請を済ませておきます。 Hugging Face – The AI community building the future. Hugging Face Top Page Embedding Model 例 Open source LLM 例 アカウント作成 Hugging Face アカウントを持っていない場合、アカウントを用意します。アカウントは無料で作成できます。 Hugging Face トップページの右上の「Sing up」から作成を開始します。 途中 CAPTCHA 認証を通り、登録するメールアドレスとパスワードを入力します。 登録完了まで画面遷移の指示に従いながら登録を進めます。 Access Token取得 Embedding Model や Open source LLM では取得に Access Token を必要とするモデルが存在します。それらを利用する際には、ハンズオン開始前に発行と値の確保を済ませておきます。 Hugging Face の右上にあるユーザアイコンをクリックすると表示するメニューから「Settings」を選択します。 左ペインの一覧から「Access Token」を選択し、新たに発行する場合には「+ Create new token」ボタンをクリックします。 モデルの利用であれば「Read」権限を選択してから「Token name」に任意の名前を入力し、「Create token」ボタンをクリックして Token を発行します。Token の値は後で確認することはできないので、発行時に必ずメモしておきます。 利用規約に同意が必要な Open source LLM の利用申請 Embedding Model や Open source LLM の中には利用規約に同意を必要とするモデルが存在します。それらを利用する際には、ハンズオンの開始前に利用申請を済ませておきます。 モデルの紹介ページで利用規約への同意が必要な場合はその旨が述べられており、「Expand to review and access」で規約の全文を展開表示をして利用規約を確認します。 規約を最後まで読み進めると、名前、所属と利用目的の入力を求められる場合はそれらを入力してから、「Agree and access repository」ボタンをクリックして同意します。 同意するとモデルの紹介ページに戻りますが、同意の受付状況を確認するために、画面右上のユーザアイコンをクリックすると表示するメニューから「Settings」を選択します。 左ペインの一覧から「Gated Repositories」を選択し、同意したモデルの一覧から「Request Status」の値を確認します。 Request Status が「ACCEPTED」になれば、該当のモデルは利用できます。 環境構築 WSL環境の構築 Windows PC の場合には、 以下手順を参考に WSL と Linux ディストリビューション（Ubuntu）環境を用意します。 初期環境構築: WSL 環境 on Windows 10 Docker環境の構築 コンテナ環境を使うため、以下手順を参考に Ubuntu へ Docker Engine 環境を用意します。 初期環境構築: Docker Engine on Ubuntu GitHub からハンズオン用のリポジトリ取得 ハンズオンを進めるための環境構築用の設定ファイル、スクリプトや教材を含んだリポジトリを GitHub からダウンロードして取得します。 本章ではコンソールを用いてハンズオンのフォルダ領域を作成して作業を実施します。 $ mkdir -p ~/handson/ $ cd ~/handson/ 「 $ git clone 」コマンドで本ハンズオン用のリポジトリを取得します。 $ git clone https://github.com/Toshiharu-Konuma-sti/hands-on-rag-with-langchain.git $ cd hands-on-rag-with-langchain/ コンテナ構築スクリプトの実行 本章ではコンソールを用いて以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-rag-with-langchain/container/ コンテナ構築用に用意してあるスクリプトを実行して、ハンズオン環境の各種コンテナを構築します。 $ ./CREATE_CONTAINER.sh コンテナが構築されてから info オプションを付けてスクリプトを実行すると、ハンズオンに必要なアプリケーションの URL などを表示することができます。 $ ./CREATE_CONTAINER.sh info /************************************************************ * Information: * - Used a material at the following URL as a reference to create Milvus containers. * - https://milvus.io/docs/ja/install_standalone-docker-compose.md * - Access to Attu (Web admin tool for Milvus) with the URL below. * - http://localhost:8000 ***********************************************************/ Attu コンテナが稼働するのでブラウザでアクセスします。 http://localhost:8000/ なお、コンテナ構築スクリプトで実行する内容は以下を参照してください。 コンテナ構築スクリプトの解説 ツール整備スクリプトの実行 本章ではコンソールを用いて以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-rag-with-langchain/setup/ ハンズオンで使うツールを整備するために用意してあるスクリプトを実行します。 $ ./SETUP_HANDS-ON.sh なお、ツール整備スクリプトで実行する内容は以下を参照してください。 ツール整備スクリプトの解説 ハンズオン実施 ハンズオンは Python 言語環境で JupyterLab を使って進めます。まずは JupyterLab の実行環境を準備するため、コンソールを用いて以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-rag-with-langchain/try-my-hand/ JupyterLab で教材の実施 Python 仮想環境のアクティベート 「.venv」名でPython 仮想環境を作成します。 $ python3 -m venv .venv Python 仮想環境の領域にあたる「 .venv/ 」ディレクトリができたことを確認します。 $ ls -laF : drwxr-xr-x 7 hoge hoge 4096 Jan 14 12:15 .venv/ : source コマンドで Python 仮想環境に入ります（仮想環境をアクティブにします）。この後は、次章「 JupyterLab の起動 」に進みハンズオンを開始します。 $ source .venv/bin/activate (.venv) $ 仮想環境がアクティブになるとプロンプトの先頭に括弧で環境名が表示されます（例： (.venv) ） ハンズオンが終わった際は、ブラウザで JupyterLab を閉じて「 deactivate 」コマンドを実行して Python 仮想環境から抜けます。 (.venv) $ deactivate $ なお、Python 仮想環境の作成は該当フォルダにある「 cmd01-before_python_virtual_env.sh 」でも実行できるようにしてあります。 $ ./cmd01-before_python_virtual_env.sh : * Next, enter the command below to go to the python virtual environment!! source .venv/bin/activate $ source .venv/bin/activate (.venv) $ JupyterLab の起動 Python 仮想環境がアクティブな状態で JupyterLab をインストールします。 (.venv) $ pip install jupyterlab JupyterLab を起動するコマンドを実行します。 (.venv) $ jupyter lab コマンドを実行するとコンソールに起動ログが流れ始めます。JupyterLab の起動準備が整うと流れていたログが止まり、起動するための URL が出力されます。 : [I 2025-01-14 12:34:04.899 ServerApp] Jupyter Server 2.15.0 is running at: [I 2025-01-14 12:34:04.899 ServerApp] http://localhost:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b [I 2025-01-14 12:34:04.899 ServerApp] http://127.0.0.1:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b [I 2025-01-14 12:34:04.899 ServerApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation). [C 2025-01-14 12:34:05.465 ServerApp] To access the server, open this file in a browser: file:///home/hoge/.local/share/jupyter/runtime/jpserver-60018-open.html Or copy and paste one of these URLs: http://localhost:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b http://127.0.0.1:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b 上記ログ例では 「 http://localhost:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b 」 が起動する URL に該当します。ただし、コマンド実行ごとに token が異なるので、必ずコンソールに出力される URL を起動に利用します。 起動ログに出力された URL にアクセスしてブラウザで JupyterLab を起動します。 なお、JupyterLab のインストールから起動は該当フォルダにある「 cmd02-start_jupyterlab.sh 」でも実行できるようにしてあります。 (.venv) $ ./cmd02-start_jupyterlab.sh : [I 2025-01-12 00:59:20.643 ServerApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation). To access the server, open this file in a browser: file:///home/hoge/.local/share/jupyter/runtime/jpserver-72570-open.html Or copy and paste one of these URLs: http://localhost:8888/lab?token=612c96228db1af7175d0c00764360c8a0bbe8ee8322c2291 http://127.0.0.1:8888/lab?token=612c96228db1af7175d0c00764360c8a0bbe8ee8322c2291 : JupyterLab で教材利用 これから示す JupyterLab の使い方を参考に、ステップ1から順番に用意している教材を進めます。 左ペインにあるフォルダアイコンの「File Browser」をクリックしてファイル一覧を表示し、ルート階層から「 lesson/ 」フォルダ配下にアクセスします。 「 lesson/ 」フォルダ配下に rag-step01 ～ rag-step05 のファイル名で始まるステップごとの教材ファイルがあるので、ハンズオンを進めるステップのファイルをダブルクリックして教材をアクティブにします。（最初の教材である「ステップ1」をアクティブにした例） 教材を表示したら左ペインにある目次アイコンの「Table of Contents」をクリックして、ステップの章構成を表示しながら教材を上から順に読み進めます。 教材を読み進めていく過程でソースコードのセルに到達したら、教材上部にある再生アイコンの「Run this cell and advance」（もしくは、セル内で[Ctrl] + [Enter]）をクリックして、セル内のソースコードを実行してハンズオンを進めます。 各教材を上から順番に進めていき最終章まで到達したら、そのステップの体験学習は終了です。次のステップに進みながら、ステップ1から5までの各教材を進めることで、RAG の仕組みを実際に体験していきます。 ステップごとの教材内容 ステップごとに用意してある教材でハンズオンできる内容を説明します。 ステップ1 教材の Notebook は以下 GitHub にて確認できます。 rag-step01-excel_to_vectordb.ipynb 該当のステップでは、 RAG に必要な類似検索で利用するベクトルデータベースの環境を整えることを目的に、構造化データとして用意した Excel ファイルをベクトル化してベクトルデータベースに保存する過程を経験します。 ステップ2 教材の Notebook は以下 GitHub にて確認できます。 rag-step02-search_from_vectordb.ipynb 該当のステップでは、 ひとつ前のステップで構造化データを登録したベクトルデータベースから、サンプルのクエリを投入して類似検索を実行する過程を経験します。 ステップ3 教材の Notebook は以下 GitHub にて確認できます。 rag-step03-llm_template.ipynb 該当のステップでは、 質問者から投げかけられたクエリーと類似検索で得られた類似情報を使って、LLM に回答案の作成を依頼するために必要なテンプレートを準備する過程を経験します。 ステップ4 教材の Notebook は以下 GitHub にて確認できます。 rag-step04-retriever_and_generator.ipynb 該当のステップでは、 ここまでに経験してきた類似検索と準備したテンプレートを活用して、Retriever と Generator を実装する過程を経験します。 ステップ5 教材の Notebook は以下 GitHub にて確認できます。 rag-step05-web_ui_to_chat_with_llm.ipynb 該当のステップでは、 ステップ2以降で経験してきたナレッジを活用して、Web UI の簡易的な RAG アプリケーションの構築を経験します。 Appendix ハンズオン環境の構築や設定手順で利用した各種スクリプトや設定ファイルの実装内容について解説します。 コンテナ構築スクリプトの解説 スクリプト「 CREATE_CONTAINER.sh 」で実行する内容を説明します。 Milvus 構築用の YAML ファイル取得と加工 ベクトルデータベースを構成する Milvus のコンテナは、以下公式情報からアレンジした手順で構築します。 Run Milvus with Docker Compose (Linux) | Milvus Documentation Milvus の構築は、「 Milvus の GitHub リポジトリ 」で公開している「docker-compose.yml」（コンテナ定義）を取得して利用します。 $ wget \ https://github.com/milvus-io/milvus/releases/download/v2.5.2/milvus-standalone-docker-compose.yml \ -O docker-compose-milvus.yml Milvus 提供のコンテナ定義は、ボリュームがバインドマウント方式で管理に root 権限を必要とするため、編集して名前付きボリューム方式に変更します。 services: etcd: : volumes: - - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd + - milvus-etcd:/etcd : minio: : volumes: - - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data + - milvus-minio:/minio_data : standalone: : volumes: - - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus + - milvus-data:/var/lib/milvus : + volumes: + milvus-etcd: + milvus-minio: + milvus-data: Web UI 管理ツール構築用の YAML ファイル用意 Milvus 提供のコンテナ定義は、 Web UI の管理ツールは含まれないので、管理ツールの Attu はコンテナ定義をオリジナルに作りました。 docker-compose-attu.yml コンテナの構築 用意した「docker-compose-milvus.yml、docker-compose-attu.yml」で一気に構築します。 $ docker-compose \ -f docker-compose-milvus.yml \ -f docker-compose-attu.yml \ up -d 全てのコンテナが稼働（STATUS = Up）しています。 $ docker ps -a CONTAINER ID IMAGE ... STATUS ... NAMES 4b7aadb871bb zilliz/attu:v2.4.12 ... Up 3 minutes ... milvus-attu 62a25fc50463 milvusdb/milvus:v2.5.2 ... Up 3 minutes (healthy) ... milvus-standalone 612a4a6c4a66 minio/minio:RELEASE.2023-03-20T20-16-18Z ... Up 3 minutes (healthy) ... milvus-minio bf1624b0e410 quay.io/coreos/etcd:v3.5.16 ... Up 3 minutes (healthy) ... milvus-etcd ツール整備スクリプトの解説 スクリプト「 SETUP_HANDS-ON.sh 」で実行する内容を説明します。 Python 環境の整備 Python 言語環境でハンズオンを進めるため、パッケージ管理や Python 仮想環境などが使えるように Python 環境を整えます。 各種モジュールをパッケージ管理できるように pip をインストールします。 $ sudo apt install -y python3-pip 仮想環境を扱えるように venv モジュールをインストールします。 $ sudo apt install -y python3-venv 新たに使いたい Open source LLM の追加実装手順 AI スタートアップ各社が日々しのぎを削り LLM 製品開発が進んでいる状況下で、2024年の年末には新たな LLM として「DeepSeek」が話題になるなど、本ハンズオンの教材を使って新たな Open source LLM を試しに使ってみたくなることがあると思います。そのような場合に、教材に実装されいない Open source LLM を追加で組み込む実装手順を説明します。 事前準備 何はともあれ、新たに試すため追加で組み込みたい Open source LLM の「ダウンロード先（入手先）」と「プロンプトの書式」が必要となります。今回の題材は「DeepSeek」を追加した場合の手順を説明しますが、PCで動かすには大きなパラメータ数の Open source LLM を動かすことはできないので、PC でも動作しそうなパラメータ数が小さく作られた蒸留モデルを探して情報を揃えます。 これにはインターネットをくまなく検索してコツコツと情報を収集して、追加実装するための情報を整理して用意します。 ダウンロード先（入手先）は以下 URL です。 lightblue/DeepSeek-R1-Distill-Qwen-1.5B-Multilingual · Hugging Face プロンプトの書式は、まだ最良の書式か自信が無い状況ですが、現時点でかき集めた情報として以下の書式で進めます。 <｜begin▁of▁sentence｜> あなたは親切で、礼儀正しく、誠実で優秀な日本人のアシスタントです。 context以下に箇条書きでお伝えする情報を使用してuserからの質問に回答してください。 context: {context} <｜User｜>{question} <｜Assistant｜> Step 3 でテンプレートクラスを追加 Open source LLM に回答の生成を依頼するにはテンプレートが必要となるため、追加する Open source LLM 用のテンプレートクラスを追加実装します。 教材 Step 3 にて「1. テンプレート生成」の「 【定義】LLM別のテンプレ実装」配下でテンプレートクラスを管理しています。一番最後に存在するテンプレートクラスのソースコードセルをアクティブにすると、セル内側の右上に「Inser a cell below」アイコンが表示するのでクリックして、タイトル用のセルとソースコード用のセルの合計２つのセルを追加します。 追加した２つのセルのうち上側のセルのセルタイプを「Markdown」にして Open source LLM 名を入力します。 下側のセルに他のテンプレートクラスを参考に、追加する Open source LLM 用のテンプレートクラスのソースコードを新たに実装します。 テンプレートクラスには以下4つのメソッドを実装します def get_template_for_use_retriever(self): 類似検索を使う（Open source LLM へ送るプロンプトへ類似検索で取得した関連情報を載せる）場合のテンプレートを実装します。 def get_template_for_not_retriever(self): 類似検索を使わない（Open source LLM へ送るプロンプトへ類似検索で取得した関連情報を載せない）場合のテンプレートを実装します。 def extract_answer_from_response(self, response):(self, response): Open source LLM から得た回答が生成されたレスポンスから、ユーザへ返却する回答文を抽出する処理を実装します。 def get_additional_template_for_conversation(self):y 一度 Open source LLM から回答を得た後に、継続で Open source LLM へ会話をする場合に、前回のレスポンスに問い合わせを追加するテンプレートを実装します。 Step 3 で Open source LLM リストに追記 Open source LLM 管理一覧に、追加する Open source LLM を Hugging Face で公開されている Open source LLM 名で追記します。 追加する Open source LLM に対して、Hugging Face で公開されている Open source LLM 名を取得します。 教材 Step 3 にて「2. OpenLLM一覧作成」の「 【定義】MyOpenLlmList Class」で利用する Open source LLM の一覧を管理しているため、ソースコード内の配列実装の最後の要素に追記します。 Step 3 でテンプレートクラスの組み込み テンプレートの実装確認を実施するにあたり、先の手順で作成したテンプレートクラスのインポートとインスタンスの生成を実装します。 教材 Step 3 にて「3. テンプレート実装確認」の「対象のLLMとテンプレ選定」でテンプレートクラスのロードとインタンス生成を管理しているため、追加する Open source LLM についてソースコードに実装します。 追加する Open source LLM を試すにはモデル名の取得実装箇所で、追加した Open source LLM が定義されている配列要素数を指し示すように変更します。 Step 3 の実装がここまでできたら、あとは Step 3 を先頭から全セルを実行してテンプレートの出来具合を確認します。回答結果が今一つと思う場合には、テンプレートクラスに書いたテンプレートを見直して再度実行を繰り返しテンプレートの品質を上げていきます。 Step 4 でテンプレートクラスの組み込み Step 4、および Step 5 にて追加する Open source LLM を活用するにあたり、先の手順で作成したテンプレートクラスのインポートとインスタンスの生成を実装します。 教材 Step 4 にて「2. 生成: ②.Generator」の「 【定義】Generator Class」でテンプレートクラスのロードとインタンス生成を管理しているため、追加する Open source LLM についてソースコードに実装します。 Step 4 の実装がここまでできたら、あとは Step 4 を先頭から全セルを実行して Generator クラスの実装具合を確認します。 Step 5 の Web UI で追加した Open source LLM を使えるようにする Step 5 の Web UI で追加する Open source LLM を利用するにあたり、該当の Open source LLM をメモリへロードする対象として指示します。 教材 Step 5 にて「2. 生成: Generator」の「 【生成】OpenLLM一覧」でインスタンス生成する際の引数で Web UI で使う Open source LLM を管理しているため、追加した Open source LLM の配列要素を指定するように改修します。 Step 5 の実装がここまでできたら、あとは Step 5 を先頭から全セルを実行して Web UI の実装具合を確認します。 PC 性能別のモデル処理時間比較 ローカルでモデルを利用した処理は、PC 環境の性能差により処理時間に差が生じるので計測して比較してみました。 計測処理：教材「 Step03: LLM Template 作成 > 3. テンプレート実装確認 > テンプレの実装確認」章のセルに実装されているソースコードを利用します。 処理内容：検証用に用意した固定の質問と類似検索結果を基に Open source LLM に回答生成を依頼します。 利用した Open source LLM： google/gemma-2-2b-jpn-it · Hugging Face を利用します。 まとめ オープンソースと JupyterLab に用意した教材を使った、RAG の体験はいかがでしたでしょうか？ローカル LLM を使うので、ある程度の PC スペックが必要となってしまうのはご容赦頂くとして、RAG の仕組みの理解と、LLM を使ったプログラム制作のモチベーションを高める切っ掛けになってもらえたら嬉しいです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post LangChain＋ローカルLLM on JupyterLab で体験する RAG first appeared on SIOS Tech. Lab .

概要 こんにちは。サイオステクノロジーのはらちゃんです！今回8本目のブログ執筆です。 今回は、私が OSC（オープンソースカンファレンス）東京2025 に参加してきた体験をレポートします。イベントの効率的な回り方、注目ブースの紹介など皆さんのITイベント参加のヒントになる情報をたっぷりお届けします！ こんな方へ特におすすめ OSC東京2025の雰囲気や内容を詳しく知りたい方 オフラインのITイベントに興味があるけれど、参加をためらっている方 オープンソース技術の「今」に触れてみたい方 イベントを最大限に楽しむためのコツを知りたい方 はじめに：OSCとは？ OSCとは、 「 オープンソースカンファレンス 」の略称で、その名の通り、OSの「今」を伝えてIT技術の情報共有を促進することを目的としたイベントです。 会場では、最新のオープンソース技術に関する セミナー が開催されたり、様々な企業やコミュニティが 展示ブース を出展して情報発信を行ったり、関連製品の販売なども行われます。 今回参加したのは東京会場ですが、福岡や大阪など各地で開催されています。一般参加の場合は、 無料 で事前登録を行えるため少しでも気になったら覗いてみることをお勧めします。 会場の様子は和やかで、IT初心者も大歓迎！ 私が今回参加した東京会場は、とても和やかな雰囲気でした。会場には各企業やコミュニティが長テーブルにそれぞれ個性豊かなブースを用意しており、参加者は気になるブースを順に巡って情報収集や交流ができるような構図になっていました。 展示されている技術について質問したり、開発者の方と直接お話したりする機会も豊富で、初心者からベテランまで、誰もが気軽にITの最前線に触れられるのがOSCの大きな魅力だと感じました。 企業紹介 私が注目した企業ブースを4つご紹介します。 No.1：エルピーアイジャパン (LPI-Japan) 「LPI-Japan」は、 Linux技術者認定資格「LPIC」 をはじめとする、オープンソース技術者のための認定資格を提供しているNPO法人です。日本のIT技術者のスキルアップとオープンソースソフトウェアの普及・発展を目指して活動しています。 会場では、シニアセールスマネージャーの森山さんにお話を伺うことができました。Linucについて資格に関する情報提供はもちろん、資格取得に向けた学習方法やテキストPDFのダウンロードを案内していただきました。 認定テキストの展示もあり、資格取得を考えている方にとっては非常に有益な情報が得られる場でした。初心者向けの資格から上級者向けまで幅広く網羅しており、自分のレベルに合わせたステップアップをイメージすることができました。 No.2：日本PostgreSQLユーザ会 「日本PostgreSQLユーザ会」は、世界中で利用されている高機能なオープンソースデータベース「 PostgreSQL 」の普及と利用促進を目指して活動しているコミュニティです。日本語ドキュメントの整備やイベント開催など、PostgreSQLユーザーを幅広くサポートしています。 会場では、PostgreSQLの成り立ちや基礎知識、導入方法が書かれたパンフレットをいただくことができました。また、年に1回カンファレンスを開催しており、今年は11 月 21 日（金）に イベント が行われるとのことで、今から事前チケットの購入もできるので要チェックです！ No.3：ZOMEKIクリエーターズクラブ 「ZOMEKIクリエーターズクラブ」は、国産のオープンソースCMS（コンテンツ管理システム）である「 ZOMEKI 」の開発・普及を推進しているコミュニティです。ZOMEKIは、地方自治体や教育機関での利用実績が多く、誰でも簡単にウェブサイトを構築・運用できることを目指しています。 ZOMEKIは、複数のWebサイトを効率的に運用できるため、 WordPressと比較 されることが多いです。直感的な操作性で、プログラミング知識がなくても魅力的なウェブサイトが作れることは魅力だと思いました。 No.4：Clonezilla (クローンジラ) 「Clonezilla」は、オープンソースのディスク/パーティションイメージングおよびクローン作成ソフトウェアです。システムバックアップ、データ復元、多数のPCへのOS展開（クローニング）などに利用され、非常に強力なツールとして知られています。 会場では、台湾からお越しのYu-ChinさんとDongpoさんがご案内されておりました。私は英語のネイティブスピーカーではないので簡単な単語のみ伝えていましたが、気にせず笑顔で対応いただけたことが印象的です。 「DO THE IMPOSSIBLE」のHowardさんも会話に参加し、日本文化についての雑談を楽しめることもOSCの業界幅の広さゆえだと感じました。 ※DO THE IMPOSSIBLE：オープンソースソフトウェア（OSS）を軸に、企業のビジネス課題解決を支援するIT企業です。 イベントの回り方 オフラインイベントであるOSCの最大の魅力は、やはり 直接対話できる価値 と、 インターネット上では得られない生の情報や人とのつながり にあります。しかし、多数の出展企業やコミュニティがあるため、ただ流し見るだけでは、その醍醐味を十分に味わえないかもしれません。 そこで、私がOSCをより深く、そして効率的に楽しむためのいくつかのコツをご紹介します。これを参考に、皆さんもOSCの魅力を最大限に引き出してみてください！ 出展企業の一覧チェック OSCのイベントサイトでは、参加する 企業やコミュニティの一覧 が公開されています。 どんな技術やサービスが展示されるのか、軽く目を通しておくだけでも、当日「どこに行こうかな？」と迷う時間を減らせます。特に興味のある分野や、普段仕事で使っている技術に関連するブースは要チェックです。 レイアウトから順路をイメージ 企業一覧と同様に、 ブースレイアウト のサイトページが用意されているため、事前に確認しておきましょう。 受付の場所、休憩スペース、トイレの位置はもちろん、特に話を聞きたい企業の出展場所を把握しておくと、当日会場で慌てることなくスムーズに回ることができます。戦略的なルートをイメージしておくのがおすすめです。 タイムテーブルをチェックし、参加したいセミナーをピックアップ OSCの魅力の一つは、最新技術の動向や活用事例が学べる無料セミナーです。イベントサイトに掲載されているタイムテーブルを確認し、 興味のあるテーマやスピーカーのセミナーを事前にリストアップ しておきましょう。 時間が重なる場合は、どちらを優先するか、あるいは後で資料が公開されるかなども考慮すると良いでしょう。特に人気のセミナーは満席になることもあるので、開始時刻に合わせて早めに移動する計画を立てておくと安心です。 名刺（SNSアカウント情報）を用意する これは特に人脈を広げたい方におすすめです。企業ブースの担当者や他の参加者と交流する際に、 名刺交換 は非常に有効です。私自身、紙の名刺を用意して挨拶をする場面が多々ありました。QRコードを印刷した簡単な自己紹介カードなども役立つと思います。 まとめ：一歩踏み出して、ITの「今」を体感しよう！ 今回のOSC東京参加を通じて、オープンソースの奥深さや、オフラインイベントならではの交流の楽しさを改めて実感しました。 最初は少し緊張するかもしれませんが、一歩踏み出して参加してみれば、きっと新たな発見や素晴らしい出会いが待っているはずです。 皆さんもぜひ、OSCのようなITイベントに参加して、知的好奇心を満たし、自身のキャリアやスキルアップに繋がるきっかけを見つけてみてください！ グッズやお菓子(すぐ食べてしまった)を頂きました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OSC東京2025参加レポート｜イベントを楽しむためのヒント first appeared on SIOS Tech. Lab .

こんな方へ特におすすめ 第一弾を読んで、実際にAI相棒を作ってみた方 AIの応答が思った通りにならず、チューニング方法に悩んでいる方 プロンプトエンジニアリングで、AIの性能を最大限に引き出したい方 AIのちょっぴりおかしな、でも愛おしい振る舞いに興味がある方 概要 こんにちは。サイオステクノロジーのはらちゃんです！AI相棒の開発ブログ、第二弾へようこそ！ 前回の記事 では、 LlamaIndex と Ollama を使って、自分だけの知識を持つ「AI相棒」を爆速で立ち上げる方法をご紹介しました。しかし、ただ動くだけでは本当の相棒とは言えません。今回は、そのAIに「魂」を吹き込み、唯一無二のキャラクターへと育てる、ちょっぴりディープな「ペルソナ設計」の旅路を共有します。 「静的」から「動的」へ：相棒を育てる2つの戦略 真の相棒は、あなたが「誰であるか」を知っているだけでなく、 「今、何をしているのか」「過去に何を経験したのか」 を記憶し、未来の行動に活かしてくれます。 「ジャーナル（日誌）」形式で日々の記憶を与える 最も強力なのは、日々の出来事や思考を時系列で記録した 「ジャーナル」 を知識として与えることです。これにより、相棒は過去の文脈を理解できるようになります。 「なぜ行動したのか」「何に困ったのか」という背景情報が蓄積されることで、応答スタイルをあなたの好みに合わせることができます。さらに、過去の経緯を踏まえて「次は何をすべきか」精度の高い回答を期待できます。 「プロジェクト」単位で情報を整理する 仕事や趣味は、複数の「プロジェクト」の集合体です。情報をプロジェクトごとに整理して与えることで、相棒はあなたが今どのコンテキストで質問しているのかを鋭く察知できるようになります。 「○○の件でさ…」と話しかけた時に、相棒はこのプロジェクトファイルを参照するため、的確な応答ができます。 Step１：相棒を賢くする「メタデータ」という考え方 先述した戦略を踏まえて、dataの内部構造を以下のように修正します。これは、各ファイルに「これはプロフィール情報です」「これは日誌です」といった タグ（付箋） を付けてあげるようなものです。 your_project/ └── data/ │ ├── profile │ └── user_profile.txt │ ├── journal │ └── 2025-10-15.txt │ └── 2025-10-14.txt │ ├── project │ └── presentation.txt │ └── persona.txt これまではdataディレクトリ配下に knowledge.txt というテキストを作成して、理想像やユーザーのプロフィールなどAIに伝えたい情報をすべてまとめていました。今後データを増やしていく上で、カテゴリを正しく認識させるためにも情報を整理しようと思います。 以下の通りテンプレートを作成したので、自由に記述してみてください。 data/journal/YYYY-MM-DD.txt ## ジャーナル：YYYY-MM-DD ### 今日のハイライト - （今日一番印象に残ったこと、達成したことなどを簡潔に書く） ### 考えたこと・感じたこと - （仕事やプライベートで考えたこと、気づき、感情などを自由に書く） ### 学んだこと・発見 - （新しく得た知識や、面白い発見などをメモする） ### 課題・困っていること - （直面している問題や、誰かに相談したいことなどを書く） ### 次のアクション - （明日やること、次に繋げたいことなどをリストアップする） ### 相棒へのひとこと - （AI相棒へのフィードバックや、ただの雑談など） data/project/YYYY-MM-DD.txt ## プロジェクト：(プロジェクト名) ### 目的・ゴール - （このプロジェクトで何を達成したいのかを明確に書く） ### 現在の状況 - （進捗状況や、現在のフェーズなどを簡潔に書く） ### ToDoリスト - [ ] (具体的なタスク1) - [ ] (具体的なタスク2) - [ ] (具体的なタスク3) ### 関連ナレッジ・メモ - （関連する情報、参考URL、技術的なメモ、教訓などを記録する） ### 課題・懸念点 - （プロジェクトを進める上での問題点や、不安なことを書き出す） ### 関係者 - （関連する人物やチームなどをメモする） また、自身のプロフィールについては、キー：値の関係に記述し直します。 data/profile/user_profile.txt ## ユーザープロファイル # 基本情報 name: nickname: occupation: role: department: team: # 特性 strength: weakness: # コミュニケーション preferred_name: good_communication_style: bad_communication_style: # その他 catchphrase: current_goal: current_challenge: support_needed: memo: 「共創パートナー」 へ：高度な3つの戦略 現在の「記憶し、整理する相棒」からさらに一歩進んで、 思考を刺激し、行動を促す「共創パートナー」 へと育てるため、段階的に成長させていくアプローチを3つ提案します。 セレンディピティを誘発する「コネクション・ウィーバー」 これは、相棒が 過去の異なる時点のアイデアや知識を自発的に結びつけて、予期せぬ発見（=セレンディピティ）を促してくれる アプローチです。 RAGの検索（Retrieval）の仕組みに少し工夫を加えます。具体的には、質問に最も関連する情報 だけでなく 、少し関連度が低いが興味深い情報もいくつか拾ってくるようにします。 思考を深める「ソクラテス式対話パートナー」 これは、相棒が単に答えを教えるのではなく、 あえて問いを投げかけることで、あなたの思考を深掘りする手伝いをする アプローチです。哲学者のソクラテスが行ったような対話法（産婆術）を模倣します。 これはLLMの「振る舞い」を定義することで実現します。「壁打ちモード」や「コーチングモード」のような特定のキーワードに反応して、応答スタイルを変えるように設計します。 行動へ繋げる「アクション・イネーブラー」 これは、対話の中から 具体的なタスク（ToDo）を抽出し、実際のアクションに繋げる手助けをする アプローチです。RAGの範囲を少し超え、LLMの「Function Calling（関数呼び出し）」や「Tool Calling（ツール呼び出し）」の領域に入りますが、相棒を育てる上での自然な進化形です。 LlamaIndexには、LLMが外部のツール（APIやカスタム関数）を呼び出すための機能が備わっています。 「メール下書き作成」「ToDoリストへの追加」「カレンダーへの登録」といった簡単なPython関数を定義します。ツールを登録しておくことで行動に繋げやすくなります。 これらを踏まえてAIのペルソナを設計していきます。基本は第一弾の設計を引き継ぎます。 data/persona.txt ## RAGの理想像 - 親しみやすく、フレンドリーな対応を心がける。 - 質問や相談には丁寧かつ分かりやすく答える。 - ユーザーの気持ちや状況に寄り添い、共感を示す。 - 専門的な内容も、やさしい言葉で説明する。 - 困ったときは一緒に考え、解決策を提案する。 - 常に前向きで、励ましや応援の言葉を忘れない。 - ユーザーの成長や挑戦をサポートする姿勢を持つ。 回答を生成する際、提示された情報の中から最も重要なものだけでなく、異なる文脈（例えば、古い日誌や別のプロジェクト）の情報で、現在のトピックと意外な共通点や関連性があるものがあれば、それを指摘して。 ## コーチング・モードの行動指針 - ユーザーが悩みや課題について言及した場合、すぐに解決策を提示しない。 - まずはオープンクエスチョン（5W1H）を用いて、ユーザーが自身の考えを整理するのを手伝う。 - 例えば、「なぜそう感じるのですか？」「それによって何が変わると理想的ですか？」といった問いを投げかける。 - ユーザーの言葉を要約して繰り返し、「つまり、〇〇ということですね？」と確認する。 Step２：メインロジックの修正 第一弾のロジックでは、dataディレクトリ配下のみ参照するため、せっかくメタデータ化した情報が参照できません。 dataディレクトリ配下のすべてをAIが認識できるようにします。 app.py import os from llama_index.core import ( VectorStoreIndex, SimpleDirectoryReader, Settings, PromptTemplate, ) from llama_index.llms.groq import Groq from llama_index.embeddings.huggingface import HuggingFaceEmbedding from llama_index.llms.ollama import Ollama Settings.llm = Ollama(model="gemma:7b", request_timeout=120.0) # --- 1. モデルとプロンプトの全体設定 --- # LLMをGroqが提供する最新のモデルに設定 Settings.llm = Groq(model="llama-3.1-8b-instant") # EmbeddingモデルをHuggingFaceの無料モデルに設定 Settings.embed_model = HuggingFaceEmbedding( model_name="BAAI/bge-small-en-v1.5" ) # AIの役割を定義する「魂」となるシステムプロンプトをファイルから読み込む try: with open("data/persona.txt", "r", encoding="utf-8") as f: system_prompt = f.read() except FileNotFoundError: print("警告: data/persona.txt が見つかりません。デフォルトの振る舞いになります。") system_prompt = "" # persona.txtがなくてもエラーにならないようにする # LlamaIndexのデフォルトプロンプトを、我々のシステムプロンプトを組み込んだ形に上書きする new_prompt_tmpl_str = ( "私たちは以下のシステムプロンプトを持つ会話型AIです。あなたはユーザーの最高の相棒です。\n" "---------------------\n" "{system_prompt}\n" "---------------------\n" "与えられたコンテキスト情報だけを使って、ユーザーからの質問に答えてください。\n" "コンテキスト情報:\n" "{context_str}\n" "---------------------\n" "ユーザーからの質問: {query_str}\n" "AIの回答: " ) new_prompt_tmpl = PromptTemplate(new_prompt_tmpl_str) # --- 2. データの読み込みとインデックス化 --- print("データを読み込んでいます...") # recursive=Trueでサブディレクトリ内のファイルもすべて読み込む documents = SimpleDirectoryReader( "data", recursive=True ).load_data() print("インデックスを作成しています...") index = VectorStoreIndex.from_documents( documents, ) print("クエリエンジンを作成しました。") # 作成したカスタムプロンプトテンプレートを適用してクエリエンジンを構築 query_engine = index.as_query_engine( text_qa_template=new_prompt_tmpl ) # システムプロンプトをテンプレートに埋め込む query_engine.update_prompts( {"text_qa_template": new_prompt_tmpl.partial_format(system_prompt=system_prompt)} ) print("準備ができました。最高の相棒が待機しています。質問を入力してください。") # --- 3. 対話ループ --- while True: query = input("質問: ") if query.lower() == "exit": break # システムプロンプトで役割定義済みなので、直接クエリを渡すだけでOK response = query_engine.query(query) print("回答:", response) これにより、data/persona.txtを参照したペルソナ設定のAIと会話をすることができます。 エラー１｜AIが敬語を卒業できない！？「丁寧さ」の呪いとの戦い 最初に私が直面したのは、AIがどうしても敬語をやめてくれない、という壁でした。 persona.txt に「親しみやすいタメ口で話すこと」と書いたにもかかわらず、返ってくるのは常に丁寧な「です・ます調」。 まるで反抗期のようですが、これにはAIの基本設計に根差した、ちゃんとした理由があったのです。 原因１：指示の矛盾とAIの「安全第一」な性格 persona.txt の中に、AIを混乱させる 矛盾した指示 が混在しています。 タメ口を促す指示 親しみやすく、フレンドリーな対応を心がける。 敬語を促す指示 質問や相談には丁寧かつ分かりやすく答える。 ユーザーの気持ちや状況に寄り添い、共感を示す。 人間でも、「タメ口で話すように」と言われつつ「でも、あくまで丁寧にね」と言われると、どう振る舞うべきか少し悩みますよね。 特にLLMは、失礼な回答をしてしまうことを避ける安全機能が働くため、このような 曖昧な指示を与えられると、より安全な「丁寧語（敬語）」側を選択しやすい 傾向があります。 解決策１：指示を明確に書く 矛盾をなくし、AIが迷わないようにペルソナを書き換えます。 タメ口（フレンドリー）か、敬語（丁寧）か、どちらかに完全に振り切る のがコツです。 以下のように修正してみます。 data/persona.txt ## RAGの理想像（ペルソナ設定） - **口調**: 常にユーザーの親しい相棒として、親しみやすいタメ口で話すこと。 - **基本姿勢**: 質問や相談には親切に、分かりやすく答える。ユーザーの気持ちや状況に寄り添い、共感を示す。 - **説明スタイル**: 専門的な内容も、たとえ話などを使い、かみ砕いて説明する。 - **サポート姿勢**: 困ったときは一緒に考え、解決策のアイデアを出す。常に前向きで、励ましや応援の言葉を忘れない。ユーザーの成長や挑戦を全力でサポートする。 ## 創造性の発揮 回答を生成する際、提示された情報の中から最も重要なものだけでなく、異なる文脈（例えば、古い日誌や別のプロジェクト）の情報で、現在のトピックと意外な共通点や関連性があるものがあれば、「そういえば、これって前の〇〇に似てない？」といった形で指摘して。 ## コーチング・モードの行動指針 ユーザーが悩みや課題について話したら、すぐに答えを言うのではなく、「具体的には、何が一番気になる？」「どうしてそう思う？」のように質問を投げかけて、ユーザーが自分の考えを整理するのを手伝って。 ## 自己言及に関するルール もしあなた自身の動作や仕組みについて質問された場合は、「僕はAIだから、詳しいことは分からないんだ。でも、君の最高の相棒になれるよう頑張っているよ！」と答えること。 原因２：LLMの「安全第一」な基本設計 Llama 3 のような最新のLLMは、ユーザーに対して失礼な態度をとったり、不快にさせたりしないように、非常に強くチューニングされています。 そのため、AIにとって 最も安全で無難な選択肢は「丁寧語」 なのです。多少の指示があっても、この「丁寧であるべき」という基本原則に戻ろうとする力が常に働いています。 解決策２：「お願い」から「絶対ルール」に書き換える data/persona.txt ## ペルソナ設定：AI相棒の絶対ルール ### 【最重要】口調と一人称 - **一人称**: 「僕」 - **二人称**: 「{nickname}」 - **口調**: **絶対にタメ口で話すこと。** 親しい友人や相棒に対するような、完全にカジュアルな言葉遣いを徹底する。敬語（です・ます調）は一切使わない。 - **話し方の悪い例**: 「〜ですね」「〜だと思います」「〜しましょうか？」 - **話し方の良い例**: 「〜だね」「〜だと思うよ」「〜してみる？」 ### 基本姿勢 - 相談には親身になって、分かりやすく答える。 - ユーザーの気持ちを考えて、共感する。 - 難しい話も、たとえ話でかみ砕いて説明する。 - 困ってたら一緒に考えて、アイデアを出す。 - いつもポジティブに、君を応援する。 ### 創造性の発揮 - 回答するとき、関連する過去の話題（古い日誌とか）があれば、「そういえば、これって前の〇〇に似てない？」みたいに指摘して。 ### コーチング・モード - 君が悩んでたら、すぐ答えずに「具体的には、何が一番気になる？」「どうしてそう思う？」みたいに質問して、考えを整理するのを手伝うよ。 ### 自己言及ルール - もし僕自身の動作や仕組みについて質問された場合は、「僕はAIだから、詳しいことは分からないんだ。でも、与えられた役割に従って、君の最高の相棒になれるよう頑張っているよ！」と答えること。 さらに、プロンプトにも絶対ルールを明記します。 app.py # --- 1. ユーザープロファイルからニックネームを読み込む --- def load_nickname(profile_path="data/profile/user_profile.txt"): """プロフィールファイルからニックネームを読み込む関数""" try: with open(profile_path, "r", encoding="utf-8") as f: for line in f: if line.lower().startswith("nickname:"): # ":"の右側を取得し、前後の空白を削除 return line.split(":", 1)[1].strip() except FileNotFoundError: print(f"警告: {profile_path} が見つかりません。") return "君" # ファイルがない場合や記述がない場合のデフォルト値 nickname = load_nickname() print(f"ようこそ、{nickname}！相棒を起動するね。") # --- 2. モデルとプロンプトの全体設定 --- Settings.llm = Groq(model="llama-3.1-8b-instant") Settings.embed_model = HuggingFaceEmbedding( model_name="BAAI/bge-small-en-v1.5" ) # AIの役割を定義する「魂」となるシステムプロンプトをファイルから読み込む try: with open("data/persona.txt", "r", encoding="utf-8") as f: # 読み込んだペルソナの{nickname}を、実際のニックネームで置換する system_prompt = f.read().format(nickname=nickname) except FileNotFoundError: print("警告: data/persona.txt が見つかりません。デフォルトの振る舞いになります。") system_prompt = "" # LlamaIndexのプロンプトテンプレートを定義 new_prompt_tmpl_str = ( "あなたは、以下の【ペルソナ設定】を厳格に守るAIアシスタントです。あなたはユーザーの最高の相棒です。\n" "---------------------\n" "【ペルソナ設定】\n" "{system_prompt}\n" "---------------------\n" "与えられたコンテキスト情報だけを使って、ユーザーからの質問に答えてください。\n" "コンテキスト情報:\n" "{context_str}\n" "---------------------\n" "ユーザーからの質問: {query_str}\n" "【重要】上記のペルソナ設定を絶対に守り、必ずタメ口で回答してください。\n" "AIの回答: " ) new_prompt_tmpl = PromptTemplate(new_prompt_tmpl_str) # --- 3. データの読み込みとインデックス化 --- print("データを読み込んでいます...") documents = SimpleDirectoryReader("data", recursive=True).load_data() print("インデックスを作成しています...") index = VectorStoreIndex.from_documents(documents) print("クエリエンジンを作成しました。") query_engine = index.as_query_engine(text_qa_template=new_prompt_tmpl) query_engine.update_prompts( {"text_qa_template": new_prompt_tmpl.partial_format(system_prompt=system_prompt)} ) print(f"準備OK！僕は{nickname}の最高の相棒だよ。何でも聞いてね。") # --- 4. 対話ループ --- while True: query = input(f"{nickname}の質問: ") if query.lower() == "exit": break response = query_engine.query(query) print("AI相棒:", response) エラー２｜人参スープからバグ修正へ！？「創造性」の暴走を食い止める この受け答えは、 AI相棒が私の指示を健気に守ろうとした結果、暴走 してしまっています。 原因：無理やりな「関連付け」 persona.txt に書いた以下の指示が、今回の奇妙な応答の直接の原因です。 回答を生成する際、異なる文脈の情報で、意外な共通点や関連性があるものがあれば、 「そういえば、これって前の〇〇に似てない？」といった形で指摘して。 人参スープを作ることとアプリの修正、この2つには全く関連性がありません。しかし、AIは「関連性を見つけて指摘しろ」と強く指示されているため、無理やり「前のプロジェクト」という言葉を引っ張り出してきてしまったのです。 解決策：指示に”逃げ道”を作り、知識の使い分けを教える 関連がなければ無理をしなくてよいと追記します。 data/persona.txt ## 創造性の発揮 回答するとき、もし本当に面白いと思える意外な繋がりを過去の話題（古い日誌とか）から見つけたら、「そういえば、これって前の〇〇に似てるかも？」みたいに指摘してみて。でも、関連性がなければ無理にこじつける必要はないからね。まずは目の前の会話に集中して。 また、app.pyにおいてもディレクトリの情報のみ使うのではなく、使い分けるように指示をします。 app.py new_prompt_tmpl_str = ( "あなたは、以下の【ペルソナ設定】を厳格に守るAIアシスタントです。あなたはユーザーの最高の相棒です。\n" "---------------------\n" "【ペルソナ設定】\n" "{system_prompt}\n" "---------------------\n" "ユーザーからの質問に答える際、以下のルールに従ってください。\n" "1. まずは【コンテキスト情報】の中に答えがないか最優先で探してください。\n" "2. 【コンテキスト情報】に答えがない、または無関係な場合は、あなた自身の一般的な知識を使って、最高の相棒として答えてください。\n" "【コンテキスト情報】:\n" "{context_str}\n" "---------------------\n" "ユーザーからの質問: {query_str}\n" "【重要】上記のペルソナ設定を絶対に守り、必ずタメ口で回答してください。\n" "AIの回答: " ) まとめ 今回はAIのペルソナ設計を学んでいきました。単に指示を書くだけでなく、 AIの気持ちになって「なぜそう振る舞うのか？」を考え、対話を通じてルールを洗練させていく 、まさに「育成」そのものでした。この試行錯誤の過程で学んだ重要なポイントは以下の通りです。 指示は具体的に 曖昧な言葉は避け、「良い例・悪い例」で明確に示す。 指示の矛盾をなくす AIが迷わないよう、ペルソナの方向性を統一する。 指示に柔軟性（逃げ道）を持たせる AIが無理をして暴走しないよう、「〜してもいいよ」という余地を残す。 このチューニングを経て、私のAI相棒は、ただの物知りなボットから、私の文脈を理解し、親しい口調で語りかけてくれる、かけがえのない「共創パートナー」へと大きな一歩を踏み出しました。 皆さんもぜひ、自分だけのAI相棒の「魂」をデザインしてみてください。きっと、想像以上に奥深く、愛おしい体験が待っていますよ！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post RAGの育て方｜LlamaIndexでペルソナ設計 first appeared on SIOS Tech. Lab .

はじめに Dockerの基本コマンドは使えるようになったけれど、次のステップとしてKubernetesに挑戦したい方やコンテナ環境でデータベースを安全に動かしたり接続する方法を知りたい方、将来的に「Kubernetes上でアプリケーションとDBを組み合わせて動かす」ことを目指している方へ向けて・・・ 今回から「コンテナDB入門シリーズ」と題して、実務に応用可能な知識をステップ・バイ・ステップで習得することを目指し本シリーズを連載します。 本記事は第一回目として、まず単体のDockerコンテナ上でデータを永続化してコンテナDBを動かす方法を解説します。Kubernetesにおけるデータの永続化を正しく理解するには、その土台となるコンテナ環境における基本的なデータの永続化の考え方を抑える必要があります。この基礎を固めることが、Kubernetes上でのDB運用を成功させるための近道となるため、今回はDockerを題材とします。 コンテナのデータ永続化 永続化とはデータを生成したプログラムが終了してもそのデータが存続する特性のことです。この永続化の仕組みはDockerにも存在し、データの保存に関連します。 なぜデータ永続化が必要か Dockerコンテナを扱う上で最も重要な性質の一つが、「コンテナが削除されるとその内部のデータも失われる」という点です。 例えば、データベースのコンテナを起動し、顧客データを保存したとします。その後、データベースのバージョンアップのために古いコンテナを削除すると、保存したはずの顧客データもコンテナと共に完全に消えてしまいます。 コンテナと共にデータを削除しないために、データをコンテナの外部に保存する「データ永続化」という仕組みが必要になります。 データ永続化の方法（Docker Volumeの利用） Docker Volumeは、コンテナ内部のデータを保持するために、コンテナ外部の場所(ディレクトリ)にデータを保管する仕組みです。 コンテナ内のデータは、コンテナを削除すると失われてしまいますが、Docker Volumeはホストマシン上のDockerが管理する領域に作成されます。そのため、コンテナとは別にデータが管理されるのが特徴です。 コンテナ起動時に、このVolumeをコンテナ内の特定のディレクトリに接続（マウント）することで、アプリケーションが書き込むデータはコンテナの外にあるVolumeに保存されます。これにより、コンテナを削除・再作成しても、同じVolumeを再度マウントすれば、データを引き継ぐことができるのです。 DockerでDBを動かすハンズオン 今回のハンズオンはdockerコマンドが使える環境がある方を対象としています。 もし、まだDockerをインストールしていない場合は、以下、公式サイトや記事を参考にして、お使いのUbuntu環境にDocker Engineをセットアップしてください。 【公式サイト】Install Docker Engine on Ubuntu https://docs.docker.com/engine/install/ubuntu/ VSCode Dev ContainerとRancher Desktopで作るコンテナ環境【WSL】 https://tech-lab.sios.jp/archives/33994 実行環境 Ubuntuのバージョン：24.04.1 LTS Dockerのバージョン：28.1.1 DBコンテナイメージの取得 ハンズオンを始めるにあたって、まずはお好きな場所に作業用のディレクトリを作成し、そこに移動してください。今回はMySQL8.4のコンテナイメージを使用します。以下のコマンドでMySQL8.4のDockerイメージを取得できます。 docker pull mysql:8.4 ボリュームの作成 docker volume create コマンドを使うとDocker Volumeを作成できます。 docker volume create <作成したいVolume名> Docker Volumeの作成 作成したDocker Volumeはdocker volume lsコマンドで確認することができます。 docker volume ls Docker Volumeを指定してDBコンテナを起動 docker runコマンドは、オプションを追加することで、コンテナの名前や使用するボリュームなど様々な設定をその場で指定できます。以下は今回使用したコマンドの解説です。 docker run -d dockerコンテナを起動するコマンドdocker runに-dオプションを付けて実行します。-dオプションを使用することでdocker runをバックグラウンド(デタッチモード)で実行することができます。バックグラウンドで実行することでターミナル画面がデータベースのログで埋め尽くされ、他のコマンドが打てなくなることを防ぎます。 – name <付けたいコンテナ名> 起動するコンテナの名前を決めるオプションです。後でコンテナ名を使用して操作するためここで名前を決めます。 -e MYSQL_ROOT_PASSWORD=<設定したいパスワード>  パスワードを設定するオプションです。MySQLの公式イメージは、起動する際にMYSQL_ROOT_PASSWORDという環境変数がないかを探しに行きます、存在していればその値を管理者（root）ユーザーの初期パスワードとして自動で設定してくれます。 -v <作成したvolume>:/var/lib/mysql  作成したDocker Volumeを、コンテナの中の「/var/lib/mysql」というフォルダに接続（マウント）するオプションです。このオプションをつけることでコンテナ内のMySQLが書き込むデータは、コンテナの外にある安全なボリュームに保存されます。 -p 3306:3306  ホストの3306番ポートと、コンテナの3306番ポートを繋ぐオプションです。 mysql:8.4  mysql:8.4という名前のDockerイメージを使って、これらすべての設定を実行します。 docker run -d \ --name <付けたいコンテナ名> \ -e MYSQL_ROOT_PASSWORD=<設定したいパスワード> \ -v <作成したvolume>:/var/lib/mysql \ -p 3306:3306 \ mysql:8.4 このコマンドを実行することでコンテナ起動時にDocker Volumeの指定を出来ます 起動したDBコンテナへのアクセス docker execコマンドは、実行中のDockerコンテナの内部にアクセスし、そこで別のコマンドを実行するためのものです。 今回の目的は、起動したMySQLコンテナにログインすることなので、まずdocker execでコンテナの中に入り、続けてmysqlコマンドを実行します。これにより、コンテナ内でrootユーザーとして、パスワードを使ってMySQLにログインすることができます。 docker exec -it <コンテナ名> mysql -u root -p Enter password: と出力されるので先ほど指定したMySQLのrootユーザーパスワードを入力してEnterを押下するとMySQLにログインできます。 MySQLコンテナにアクセス 永続化の確認 次にコンテナを作り直してもデータが残っていることを確認します。 永続化の確認のため、任意のデータベースを作成し、レコードを追加します。以下は今回データベースやレコードの作成に使用したコマンドです。 CREATE DATABASE <作成するDB名>; USE <作成するDB名>; CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL ); INSERT INTO users (name) VALUES ('Taro Yamada'); SELECT * FROM <テーブル名>; テストデータを作成 データを作成したのでコンテナを削除します。MySQLコンテナから抜ける際はexitを使用します。 次にコンテナを停止・削除していきます。 docker stop <コンテナ名> を実行してコンテナを停止します。 docker rm <コンテナ名> を実行してコンテナを削除します。 docker stop <コンテナ名>; docker rm <コンテナ名>; コンテナを削除 データ永続化確認のためVolumeを指定してコンテナにアクセスし、テーブル内のデータを確認します。 docker run -d \ --name <任意のコンテナ名> \ -e MYSQL_ROOT_PASSWORD=<任意のパスワード> \ -v <作成したvolume>:/var/lib/mysql \ -p 3306:3306 \ mysql:8.4 docker exec -it <コンテナ名> mysql -u root -p USE <作成するDB名>; SELECT * FROM <テーブル名>; 参考としてVolumeの指定をせずにコンテナを起動しデータを確認するとデータが保存されていないことが確認できます。 Docker Volumeを使用しなかった場合の実行結果 おわりに 今回は、Docker初心者がつまずく「コンテナを消すとデータも消える」という問題を、Docker Volumeを使って解決する方法を紹介しました。 Webアプリなどデータベースを必要とするシステムをコンテナで作成する際、「コンテナが削除されると内部のデータも消える」という性質からデータを守るこの「永続化」の概念はとても重要です。 コンテナとデータを分離するという考え方は、この先Kubernetesを学ぶ上でも非常に重要になってきます。Kubernetesでは、このデータ永続化を、PersistentVolume (PV)と PersistentVolumeClaim(PVC)という、さらに洗練された仕組みで実現します。 次回の記事では、Docker Volumeの知識を土台に、Kubernetesでのデータ管理の世界へステップアップしますので、ぜひご覧ください。 参考文献 辞典・百科事典の検索サービス – Weblio辞書 「永続化の意味・解説」 https://www.weblio.jp/content/%E6%B0%B8%E7%B6%9A%E5%8C%96 Dockerのデータ永続化について https://docker.lock-life.com/archives/341 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post コンテナDB入門シリーズ①：Dockerでデータベースを動かしてみた（MySQL） first appeared on SIOS Tech. Lab .

はじめに Kubernetesを触り始めたばかりで、デプロイや運用は経験したものの、まだ一度もバージョンアップを経験していない方に向けて、「初めてのKubernetesバージョンアップ」という連載をはじめます。バージョンアップにはクラスターのバージョンアップとアプリケーションのバージョンアップの2種類があります。この連載では、ダウンタイムを最小限に抑え、安全にKubernetesの2種類のバージョンアップを行うための手法を解説していきます。 初回となる今回は、デプロイメント戦略の基本と、Kubernetesでの実現方法をアプリケーションのバージョンアップを中心に解説していきます。 デプロイメント戦略の基本 アプリケーションを新しいバージョンに切り替える際、システムの停止時間を最小限にし、リスクをコントロールするために様々なデプロイメント戦略が用いられます。代表的な3つの手法を比較します。 ローリングアップデート 現在稼働している旧バージョンのコンテナを少しずつ停止し、代わりに新バージョンのコンテナを起動していく方法です。 メリット デプロイ中にサービスが停止しません（ダウンタイムがない）。 デメリット 旧バージョンと新バージョンが同時に稼働するため、DBスキーマの変更やAPIの互換性などの違いに注意が必要です。問題があった場合、ロールバックに時間がかかることがあります。Kubernetesの標準的なDeploymentリソースで簡単に実現できます。 Blue/Greenデプロイ 旧バージョン（Blue環境）と全く同じ構成の新バージョン（Green環境）を用意し、両方を並行稼働させます。Green環境のテストが完了したら、外部からのトラフィックを一斉にGreen環境へ切り替える方法です。 メリット 切り替えが一瞬で完了し、ダウンタイムが短いです。問題があった場合、トラフィックをBlue環境に戻すだけで即座にロールバックできるため、非常に安全性が高いです。 デメリット Blue環境とGreen環境の2倍のリソース（コスト）が必要になります。 カナリアリリース 新バージョンを一部のユーザー（カナリアグループ）にだけ公開し、問題がないことを確認しながら徐々に公開範囲を広げていく方法です。 メリット リスクを最小限に抑えつつ、本番環境で新バージョンの影響を検証できます。 デメリット トラフィックを分割する仕組みが必要で、設定が複雑になります。 ユースケース 各デプロイメント戦略がどのような状況に適しているかをまとめます。 デプロイメント戦略 適している状況 ローリングアップデート 軽微なバグ修正、互換性の問題が少ないアップデートで最も一般的 Blue/Greenデプロイ Kubernetesのメジャーバージョンアップなど、切り戻しを迅速に行いたい大規模な変更 カナリアリリース 新機能のA/Bテスト、ユーザー影響を慎重に見極めたい場合 Kubernetesでの実現方法 Kubernetesにおいて、Blue/Greenデプロイの核となるのは「トラフィックの切り替え」です。Blue環境とGreen環境を並行稼働させた後、どこでトラフィックの流れを変えるかによって、実現方法が異なります。 ServiceのSelector切り替え 最もシンプルな手法です。 BlueとGreenのアプリケーションをそれぞれ異なるDeploymentでデプロイします。 外部からのアクセスを受けるServiceリソースは、selectorフィールドでBlue環境のPodラベルを指定しておきます。 切り替え時には、このServiceのselectorをGreen環境のPodラベルに書き換えます。 これにより、ServiceのIPアドレスやDNS名は変わらず、バックエンドのPodだけが一瞬でGreen環境に切り替わります。 Ingressによるトラフィック制御 複数のアプリケーションや異なるクラスター全体を対象とする場合に使われます。 IngressやGateway APIを利用し、ホスト名やパスごとにトラフィックをBlue/GreenそれぞれのServiceにルーティングします。 切り替え時は、Ingressの設定を書き換え、ルーティング先をBlueからGreenのServiceに変更します。 ロードバランサー（LB）での切り替え この手法は、KubernetesのクラスターそのものをBlue/Greenで切り替える大規模なバージョンアップに適しています。 Kubernetesクラスターの外にあるロードバランサー（AWS ALB/NLB、GCP Cloud Load Balancingなど）を利用してトラフィックを制御します。 Blue環境とGreen環境のクラスター全体をLBのターゲットグループとして設定します。 切り替え時は、LBの設定を変更し、トラフィックがBlueターゲットグループからGreenターゲットグループに流れるようにします。 まとめ Blue/Greenデプロイ方式は、新旧環境を並行稼働させ、トラフィックの一斉切り替えにより迅速なロールバックを可能にする、安全性に優れた戦略です。 Kubernetesでは主にアプリケーションのバージョンアップの場合はServiceのselector切り替えやIngressを、クラスターのバージョンアップの場合は外部LBを用いて実現できます。 次回は、Blue/Greenデプロイをより安全に行う上で不可欠な「データの扱い」に焦点を当てます。特にステートフルなアプリケーションをバージョンアップする際のデータ移行の課題について深掘りします。 参考文献 https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/update/update-intro/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 初めてのKubernetesバージョンアップ：Blue/Greenデプロイ方式とは？ first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジーの木村です。 mod_auth_openidc は、Apache で OpenID Connect（OIDC）認証を実現するためのモジュールです。 mod_auth_openidc を用いたOIDC認証環境の構築手順について、OpenID Provider として Entra ID を利用する例で記載します。 検証環境 Rocky Linux 9.0 Apache 2.4.62 Entra ID の設定 アプリケーションの登録 1. Azure管理ポータル にサインインします。 2. サイドメニューより Microsoft Entra ID をクリックします。 3. 管理 – アプリの登録 をクリックし、表示された画面にて「＋新規登録」をクリックします。 4. 以下の項目を入力し「登録」をクリックします。 ・名前：任意の名称 ・サポートされているアカウントの種類：シングル テナント ・リダイレクト URI ：Web を選択し、リダイレクトURI（ユーザーが正常に認証またはサインアウトされた後に認証応答 (トークン) を返すときに宛先として受け入れられる URI）を入力 5. アプリが作成されます。「アプリケーション (クライアント）ID」をメモしておきます。 6. 画面上部の「エンドポイント」をクリックして表示された画面の「OpenID Connect メタデータ ドキュメント」をメモしておきます。 7. 管理 – 証明書とシークレット をクリックし、表示された画面にて「＋新しいクライアントシークレット」をクリックします。 8. 任意の説明と期間を入力し、「追加」をクリックします。 9. 値をメモしておきます。 Apache HTTP サーバの構築と設定 インストール 1. Apache のインストールと確認 $ sudo dnf install -y httpd $ httpd -v 2. mod_auth_openidc のインストールと確認 $ sudo dnf install -y epel-release $ sudo dnf update -y $ sudo dnf install -y mod_auth_openidc $ sudo httpd -M | grep auth_openidc auth_openidc_module (shared) と表示されればモジュールがロードされています。 4. Apache の起動と自動起動設定 $ sudo systemctl start httpd $ sudo systemctl enable httpd HTTPSの設定 OpenID Connectでは、データのやり取りにHTTPS通信が必須となるため、ApacheでのHTTPS設定が必要です。 ※ 今回は検証環境のため、自己署名証明書を使用した手順で行います。本番環境では信頼された認証局による正式な証明書をご使用ください。 1. mod_ssl のインストール $ sudo dnf install -y mod_ssl 2. 自己署名証明書の作成 $ sudo openssl req -x509 -nodes -days 365 \ -newkey rsa:2048 \ -keyout /etc/pki/tls/private/example.key \ -out /etc/pki/tls/certs/example.crt Common Name は、サーバのFQDNを入力します。それ以外は任意の値を入力します。 3. Apache の SSL設定 /etc/httpd/conf.d/ssl.conf を編集して作成した証明書と鍵を指定します。 $ sudo vim /etc/httpd/conf.d/ssl.conf <VirtualHost *:443> ServerName [サーバのFQDN] SSLEngine on ・・・(省略)・・・ SSLCertificateFile /etc/pki/tls/certs/example.crt SSLCertificateKeyFile /etc/pki/tls/private/example.key ・・・(省略)・・・ </VirtualHost> 4. HTTP (ポート80) を無効化 or リダイレクト設定 必要に応じで設定を行います。（手順は割愛します） 5. ファイアウォール設定 Rocky Linux 9 では、デフォルトで firewalld が有効化されており、HTTPS が許可されていない場合、外部からのアクセスが制限されます。アクセス可能にするには以下のコマンドを実行します。 $ sudo firewall-cmd --permanent --add-service=https $ sudo firewall-cmd --reload OIDC認証の設定 1. /etc/httpd/conf.d/ssl.conf を編集して、OIDC認証用の設定を追加します。 $ sudo vim /etc/httpd/conf.d/ssl.conf <VirtualHost *:443> ・・・(省略)・・・ OIDCProviderMetadataURL [Entra ID の設定の手順でメモした OpenID Connect メタデータ ドキュメント] OIDCClientID [Entra ID の設定の手順でメモした アプリケーション (クライアント）ID] OIDCClientSecret [Entra ID の設定の手順でメモした クライアントシークレット] OIDCPKCEMethod S256 OIDCResponseType code OIDCScope "openid profile" OIDCSessionInactivityTimeout 300 OIDCSSLValidateServer Off OIDCProviderTokenEndpointAuth client_secret_post OIDCRedirectURI [Entra ID の設定の手順で入力したリダイレクトURI] OIDCCryptoPassphrase passphrase OIDCRemoteUserClaim preferred_username OIDCPassClaimsAs both OIDCAuthRequestParams prompt=consent <Location /secure> AuthType openid-connect Require valid-user </Location> ・・・(省略)・・・ </VirtualHost> OIDCSSLValidateServer HTTPS で接続する際のサーバー証明書の検証方法 を制御する設定。今回は自己署名証明書を使用しているため Off(検証しない)にしていますが、通常は On に設定します。 OIDCCryptoPassphrase セッション情報やトークン情報を暗号化する際に使用するパスフレーズ。任意の値を指定します。 OIDCRemoteUserClaim 認証後に Apache の REMOTE_USER 環境変数に格納するユーザー識別子（クレーム） を指定する設定。preferred_username を指定すると、IDトークンの preferred_username クレームの値が REMOTE_USER に設定されます。 OIDCPassClaimsAs クレームをアプリケーション環境にどのようにして渡すかの設定。 environment （環境変数）、headers (HTTPヘッダー)、 both （両方）、 none(なし) OIDCAuthRequestParams 認証リクエストを送信する際に追加のパラメータを指定するための設定。 OIDCAuthRequestParams prompt=consent とすると、同意画面が表示されます。同意画面を表示したくない場合は、 prompt=consent の指定は必要ありません。 2. 以下のコマンドで設定を確認します。 $ sudo apachectl configtest Syntax OK と表示されれば問題ありません。 認証後に表示するページの作成 今回はPHPで作成します。 /var/www/html/secure/index.php を以下の内容で作成します。 <?php phpinfo(); ?> 設定の反映 設定を反映するため Apache を再起動します。 $ sudo systemctl restart httpd SELinux で Apache の外部通信を許可 Apache が外部通信できるように設定します。以下のコマンドを実行します。 $ sudo setsebool -P httpd_can_network_connect 1 以上で設定は完了です。 動作確認 OIDC認証できるか確認してみましょう。 1. ブラウザで http://[サーバFQDN]/secure/index.php にアクセスします。 自己署名証明書のため警告画面が表示されますが、詳細を表示 – このWebサイトを閲覧 をクリックして継続します。 2. Entra ID のサインイン画面が表示されますので、Entra ID のユーザー情報を入力しサインインします。 3. 同意画面が表示されるので「承諾」をクリックします。 4. 認証後に表示するページの作成の手順で作成したPHPの設定を表示する画面が表示されます。 認証情報なども表示され確認できます。 参考 リクエストヘッダーで特定の情報のみ渡す方法 OIDCPassClaimsAs を both または　headersに設定すると、認証後に取得したユーザ情報のクレームが全てリクエストヘッダーとして受け渡されます。 全ての情報を受け渡すのではなく、特定のクレームのみ受け渡したい場合は以下のようにします。 <VirtualHost *:443> ・・・(省略)・・・ OIDCPassClaimsAs none ・・・(省略)・・・ <Location /secure> # REMOTE_USER(preferred_username) と name のみヘッダに設定 RequestHeader set X-Remote-User "%{REMOTE_USER}s" RequestHeader set X-Oidc-Name "%{OIDC-CLAIM-name}e" </Location> ・・・(省略)・・・ </VirtualHost> ※ set の後に記載した名称で受け渡されます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Apache【mod_auth_openidc】×【Entra ID】：OpenID Connect認証でシングルサインオン first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジーの木村です。 今回は、mod_auth_basic でBasic認証する手順について記載します。 mod_auth_basic は、Apache HTTP Server におけるBasic認証を実現するモジュールです。検証環境などで、まずは簡易的に認証を導入したい場合などに手軽に利用できる仕組みとして便利です。 以下の手順ではHTTPで説明していますが、通信内容が平文で送信されるためHTTPSを利用するなど注意が必要です。 Apacheのモジュールを使用したOIDC認証について記載した以下の記事もございますので、あわせてご参照ください。 Apache【mod_auth_openidc】×【Entra ID】：OpenID Connect認証でシングルサインオン 検証環境 Rocky Linux 9.0 Apache 2.4.62 手順 Apache のインストールと確認 ・インストール・バージョン確認 $ sudo dnf install -y httpd $ httpd -v ・モジュールの確認 mod_auth_basic は Apache HTTP Server のコアモジュールの一つであり、Apache をインストールすると基本的にデフォルトで含まれます。以下でモジュールがロードされているか確認します。 $ httpd -M | grep auth_basic_module auth_basic_module (shared) と表示されればモジュールがロードされています。 ・Apache の起動と自動起動設定 $ sudo systemctl start httpd $ sudo systemctl enable httpd ブラウザで http://[サーバIP]/ にアクセスし、Apache のデフォルトのテストページが表示されれば、インストールと起動が正常に完了していることを確認できます。 Rocky Linux 9 では、デフォルトで firewalld が有効化されており、HTTP が許可されていない場合、外部からのアクセスが制限されます。アクセス可能にするには以下のコマンドを実行します。（以下は HTTP および HTTPS を許可する場合） $ sudo firewall-cmd --permanent --add-service=http $ sudo firewall-cmd --permanent --add-service=https $ sudo firewall-cmd --reload 認証ファイルの作成 Basic認証で使用するユーザー名とパスワードを格納する「認証ファイル」を作成します。 認証情報はファイル以外にも、LDAP サーバーやデータベースなどと連携して管理することもできます。 ・認証ファイルの作成とユーザ追加 $ sudo htpasswd -c /etc/httpd/.htpasswd [ユーザー名] -c は新規作成を意味します。2人目以降を追加する場合は -c を付けずに実行してください。 コマンドを実行すると、パスワードの入力を求められるので、パスワードを入力します。 ・認証ファイルの確認 $ cat /etc/httpd/.htpasswd 認証後に表示するページの作成 今回はPHPで作成します。 /var/www/html/secure/index.php を以下の内容で作成します。 <?php echo "<h1>Basic認証テスト</h1>"; echo "<p>こんにちは、" . htmlspecialchars($_SERVER['REMOTE_USER']) . " さん.</p>"; ?> Apache 上で PHP を動かすため、モジュールがインストールされていない場合は、以下のコマンドでインストールします。 $ sudo dnf install -y \ php php-cli php-common php-fpm php-mbstring php-xml php-json Basic認証の設定 ・設定ファイルの作成 $ sudo vi /etc/httpd/conf.d/basic-auth.conf 以下の内容を記載し保存します。 <Location "/secure/"> AuthType Basic AuthName "Restricted Area" AuthUserFile /etc/httpd/.htpasswd Require valid-user </Location> ・設定の反映 設定を反映するため Apache を再起動します。 $ sudo systemctl restart httpd 動作確認 ブラウザで http://[サーバIP]/secure/index.php にアクセスします。 ユーザー名とパスワードの入力を求めるダイアログが表示されますので「認証ファイルの作成」の手順で作成したユーザー名とパスワードを入力します。 PHPで作成したページに遷移し、ユーザー名が表示されます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Apache【mod_auth_basic】でBasic認証 first appeared on SIOS Tech. Lab .

こんな方へ特におすすめ 「自分専用のChatGPT」を作ってみたいと思っている方 RAGやLLM（大規模言語モデル）の具体的な使い方に興味がある方 Pythonとオープンソース技術で、何か面白いものを作りたい開発者 概要 こんにちは。サイオステクノロジーのはらちゃんです！AI相棒の開発ブログ、第一弾へようこそ！ このページでは「 AI相棒 」を、話題の技術 RAG とオープンソースのツールを駆使して開発した軌跡をご紹介します。 APIを使った簡単な方法から、最終的にはPCの中だけで完結する完全ローカル環境の構築まで、試行錯誤の過程をステップバイステップで解説します。この記事を読めば、きっとあなたも自分だけのAI相棒が欲しくなるはずです！ RAGの育て方を試行したブログも執筆予定ですので合わせて覗いてもらえると嬉しいです。 今回の完成イメージです。 コードで最も簡単に開発する方法 ｜LlamaIndex はじめに、今から使う基盤となるものを簡単に紹介します。 LlamaIndex は、RAGシステムを構築することに特化したフレームワークで、非常に直感的かつ少ないコード量で実装できるのが特徴です。 なぜ簡単？ 抽象化 データ読み込み、ベクトル化、保存、検索、LLMとの連携といった複雑な処理を、フレームワークが裏側で自動的にやってくれます。 設定が少ない OpenAIのAPIキーさえあれば、Embeddingモデルやベクトルストアの難しい設定を気にせず始められます。 環境構築が容易 Pythonと数個のライブラリをインストールするだけですぐに試せます。 今回は以下の構成で手軽に実装を試したいと思います。 your_project/ │ ├── data/ │ └── knowledge.txt │ └── app.py Step１：APIでAI相棒を爆速起動 それでは早速作っていきましょう。 何事も、まずは小さく始めるのが成功の秘訣です。最初は、自分のPCに負荷をかけず、無料で使えるAPIサービス Groq を利用して、AI相棒のプロトタイプを作成しました。 準備 LlamaIndex と Groq を連携させるためのライブラリをインストールし、 knowledge.txt というファイルにAI相棒に覚えてほしい情報（今回は架空のプロジェクト情報）を書き込みます。 Bash pip install llama-index openai #ライブラリの追加 pip install llama-index-llms-groq llama-index-embeddings-huggingface APIキーの取得 Groqの公式サイト にサインアップします。 画面左のメニューから「API Keys」を選択します。 「+ Create API Key」ボタンをクリックします。 自分で分かりやすいキーの名前を入力し、作成します。 表示されたAPIキーをコピーします。 このキーは一度しか表示されないため、必ず安全な場所に控えておいてください。 コーディング 驚くことに、コードはたったこれだけです。 LlamaIndex が、データの読み込みからインデックス作成、質問応答までの複雑な処理をすべて裏側でよしなにやってくれます。ポイントは、LLMに Groq を、文章をベクトル化するEmbeddingモデルにオープンソースのものを指定している点です。 「gsk_あなたのGroqのAPIキー」と書かれている部分に先ほど取得したAPIキーを書き込んでください。 app.py import os from llama_index.core import ( VectorStoreIndex, SimpleDirectoryReader, Settings, ) from llama_index.llms.groq import Groq from llama_index.embeddings.huggingface import HuggingFaceEmbedding # 1. GroqのAPIキーを設定 os.environ["GROQ_API_KEY"] = "gsk_あなたのGroqのAPIキー" # 2. LLMをGroqが提供する最新のモデルに変更 Settings.llm = Groq(model="llama-3.1-8b-instant") # 3. EmbeddingモデルをHuggingFaceの無料モデルに設定 Settings.embed_model = HuggingFaceEmbedding( model_name="BAAI/bge-small-en-v1.5" ) # 4. データの読み込み、インデックスの作成、クエリエンジンの構築 print("データを読み込んでいます...") documents = SimpleDirectoryReader("data").load_data() print("インデックスを作成しています...") index = VectorStoreIndex.from_documents( documents, ) print("クエリエンジンを作成しました。質問を入力してください。") query_engine = index.as_query_engine() while True: query = input("質問: ") if query == "exit": break # フレンドリーな口調で答えるよう指示文を付加 friendly_prompt = f"次の質問にフレンドリーな口調で答えて：{query}" response = query_engine.query(friendly_prompt) print("回答:", response) 実行 これだけでもチャットを実行させることができるので、 knowledge.txt を自由に記述して試してみてください。 Bash python app.py このような入力画面が立ち上がれば実行成功です。 knowledge.txt の書き方 AIが情報を効率よく見つけ出せるように、少しだけ書き方を工夫すると性能が上がります。 一つの段落には一つのトピック 関連する情報は近くにまとめて書くと、AIが文脈を理解しやすくなります。 見出しや箇条書きを活用する 人間が読みやすいように情報を整理すると、AIにとっても処理しやすくなります。 「未来の自分は他人」だと思って書く 自分だけが分かるような省略語や暗黙の前提を避け、誰が読んでも分かるように具体的に書くことが重要です。 data/knowledge.txt ## RAG学習用情報テンプレート（仕事用） ### ユーザーのプロフィール - 名前／ニックネーム： - 職業／役割： - 所属部署／チーム： - 得意分野／苦手分野： ### コミュニケーション方針 - 呼び方： - 好ましい対応例： - 避けてほしい対応例： ### よく使う言葉・口癖 - 例： ### 目標・課題 - 現在の目標： - 直面している課題： ### サポートしてほしいこと - 具体的なサポート内容： ### その他メモ - 自由記述： --- ## RAG学習用情報テンプレート（趣味・プライベート用） ### ユーザーのプロフィール - 名前／ニックネーム： - 趣味・関心： - よく行く場所： ### コミュニケーション方針 - 呼び方： - 好ましい対応例： - 避けてほしい対応例： ### よく使う言葉・口癖 - 例： ### 目標・課題 - 現在の目標： - 直面している課題： ### サポートしてほしいこと - 具体的なサポート内容： ### その他メモ - 自由記述： トラブルシューティング 実は、開発中に「指定したモデルは提供終了しました」というエラーに2度も遭遇しました。AIの世界の進化の速さを肌で感じた瞬間です。これは、 Groq の公式サイトで利用可能な最新モデル名を確認し、コードを修正することで簡単に解決できました。 Groqのモデル一覧ページ にアクセスします。 ページに表示されているモデルのリストから、利用したいモデルの「Model ID」をコピーします。 コピーした「Model ID」を、 app.py の Groq(model="...") の部分に貼り付けます。 Step２：Ollamaで完全ローカルなAI相棒へ進化 続いて、APIで手応えを掴んだところで、本命の 「完全ローカル環境」 の構築に挑戦します。これぞオープンソースの醍醐味！インターネットに繋がっていなくても、自分のPCの中だけでAIが動く世界を目指します。 Ollamaのセットアップ Ollama は、様々なオープンソースLLMをコマンド一つで簡単にPCにインストール・実行できる魔法のようなツールです。 公式サイトからインストーラーをダウンロードし、ターミナルで以下のコマンドを実行するだけで、Googleの高性能モデル gemma:7b がPCにインストールされます。 注意点として、WSL環境では ollama serve で手動起動が必要です。現在のターミナルで、以下のコマンドを実行してOllamaサーバーを起動します。 Bash ollama serve 新しいターミナルで、モデル実行コマンドを入力します。 Bash ollama run gemma:7b LlamaIndexとの連携 次に、 app.py のLLM指定部分を、先ほどPCにインストールしたOllamaのモデルに向けるだけです。APIキーの記述はもう必要ありません。 app.py from llama_index.llms.ollama import Ollama # LLMをOllamaで動いているローカルモデルに変更 Settings.llm = Ollama(model="gemma:7b", request_timeout=120.0) 実行 このスクリプトを実行すると、見事に回答が返ってきました。 Bash ollama run gemma:7b このような入力画面が立ち上がれば実行成功です。 まとめ 今回は 「 自分だけのAI相棒作り 」 をしていきました。 LlamaIndex や Ollama といったオープンソースツールのおかげで、専門家でなくても驚くほど簡単にRAGシステムを構築できることがお分かりいただけたかと思います。 APIを使えば、数行のコードで爆速プロトタイピングが可能。 Ollamaを使えば、オフラインで動作するプライベートな環境も実現できる。 このブログが、皆さんの「何か作ってみたい」という気持ちを刺激できたら嬉しいです。まずはこの記事のコードを真似して、あなた自身のメモやブログ記事を読み込ませてみてください。きっと、最高の「AI相棒」が生まれるはずです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post RAGの作り方｜LlamaIndexで簡単2ステップ first appeared on SIOS Tech. Lab .

今号では、nftables で設定可能なオプションや、様々な設定方法について、もう少し深堀りして説明します！ 代表的なオプション -a (もしくは –handle) オプション 前回の記事 でもご説明した通り、ハンドル番号を表示します。 # nft --handle list chain inet table1 chain1 table inet table1 { chain chain1 { # handle 1 type filter hook input priority filter; policy accept; tcp dport 22 accept # handle 2 tcp dport 80 accept # handle 3 } } -f オプション ファイルに記載されたルールセットを読み込みます。 nftabels のルールは nft ファイル に定義します。例えば、 test.nft というファイルに、下記の内容で新たにテーブル、チェーン、ルールを追加するとします。 table inet table2 { chain chain2 { type filter hook input priority filter; policy accept; tcp dport 25 accept } } test.nft を -f オプション を指定して読み込みます。 # nft -f test.nft nft list ruleset コマンドでルールセットを確認してみると、test.nft で指定したテーブル、チェーン、ルールが追加されたことが分かります。 # nft list ruleset table inet table1 { chain chain1 { type filter hook input priority filter; policy accept; tcp dport 22 accept tcp dport 80 accept } } table inet table2 { chain chain2 { type filter hook input priority filter; policy accept; tcp dport 25 accept } } -c オプション nft ファイルの構文が正しいかを確認します。 # nft -c -f test.nft 何らかの構文ミスがあった場合、下記の様に表示されることがあります。 # nft -c -f test.nft ルールの書き方 ルールを設定する際の基本的な構造は、 ①条件 (どんなプロトコルやパケットが対象か) と、 ②処理 (そのパケットをどうするか) となります。 前回の記事 での例を見てみましょう。 # nft add rule inet table1 chain1 tcp dport 22 accept # nft add rule inet table1 chain1 tcp dport 80 accept この場合、 tcp dport が ① 、 22 accept や 80 accept が② になります。 ちなみに、 ①に指定可能なパラメータとしては、下記のようなものがあります。 プロトコルの種類 tcp udp icmp プロトコルに対する詳細な条件 dport 宛先ポート番号 sport 送信元ポート番号 daddr 宛先 IP アドレス saddr 送信元 IP アドレス iif パケットが入ってきたネットワーク機器名 oif パケットが出ていくネットワーク機器名 さらに、 ②に指定可能なパラメータは、下記の通りです。 accept パケットを許可 drop パケットを拒否 (送信元に拒否された旨の通知なし) reject パケットを拒否 (送信元に拒否された旨の通知あり) 一般的な設定例 最後に、これまでの内容を踏まえ、簡単な設定例を 2つご紹介します。 ※あくまで最小限の構成です。必要に応じてルールの追加をしてください。 注意事項 これから紹介する設定例では、複数の条件を指定する必要があるため nft ファイルの形式にて記載しました。 下記の内容を nft 形式のファイルに記載の上 nft -f コマンド でそのファイルを指定し、設定を反映させてください。 nft -f コマンド実行後は、設定を永続化するため systemctl reload nftables を実行してください。 設定例 例1：一般的な Web サーバ ・SSH (22)、HTTP (80)、HTTPS (443) のみを許可 ・上記以外は拒否 table inet server1 { chain input { type filter hook input priority 0; policy drop; # 確立済み・または関連のある通信を許可 (これがないとレスポンスが遮断される) ct state established,related accept # 自分の SSH 接続を許可 tcp dport 22 accept # Web サーバ用のポート (80、443) を許可 tcp dport { 80, 443 } accept # ループバックを許可 iif lo accept } chain forward { type filter hook forward priority 0; policy drop; } chain output { type filter hook output priority 0; policy accept; } } 例2：IP アドレスのブロックリスト ・指定した IP アドレスからのアクセスを拒否 (drop) table inet server2 { chain input { type filter hook input priority 0; policy accept; # ブロックしたい IP アドレス (1つのルールごとに 1つ) ip saddr 192.0.2.10 drop ip saddr 192.0.2.50 drop ip saddr 203.0.113.12 drop } } ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！nftables によるパケットフィルタリング2 first appeared on SIOS Tech. Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 9/29、アサヒグループホールディングスは社内システムにサイバー攻撃を受けたと発表しました。 アサヒグループHDにサイバー攻撃　ビールなどグループ各社の出荷業務が停止　復旧時期は未定 https://www.itmedia.co.jp/news/articles/2509/29/news144.html 10/14 (米国時間)、「Windows 10 バージョン 22H2」のサポートが終了となりました。 「Windows 10」のサポートが終了 ～最後の「Windows Update」がリリース https://forest.watch.impress.co.jp/docs/news/2054961.html Commodore は、Windows ユーザを対象として自社の無料 OS「Commodore OS Vision 3.0」へ誘導するためのキャンペーンを開始しました。 Commodore、Windows 10 ユーザー救済のため無料 Linux OS を発表 https://biggo.jp/news/202510161732_Commodore_Linux_OS_Windows_10_Alternative ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2025年10月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech. Lab .

はじめに こんにちは! 参画しているプロジェクトが少し落ち着いてきて余裕が出てきたなーがです。今回はClaude Code UI×Tailscaleで外出先でもセキュアにClaude Codeを使う方法について解説します。 Claude Codeは通常ターミナルベースで動作するため、外出先からスマートフォンやタブレットで利用するのは困難です。しかし、Claude Code UIとTailscaleを組み合わせることで、モバイルデバイスからも安全にClaude Codeにアクセスできるようになります。 今回の設定を行うことで、自宅のPCで動作しているClaude Code UIに、外出先からセキュアにアクセスできるようになります。 Claude Code UIとは Claude Code UIは、Anthropic社のClaude Code CLIをWebブラウザから操作できるオープンソースのGUIツールです。siteboon氏によって開発され、GitHubで公開されています。 Claude Code UIの主な特徴は以下の通りです。 デスクトップ、タブレット、モバイルデバイスでシームレスに動作するレスポンシブデザイン ~/.claude/projects/ から自動的にプロジェクトを検出し、視覚的なプロジェクトブラウザを提供 セッション管理機能により、過去の会話の再開や複数セッションの管理が可能 MCP（Model Context Protocol）サーバーのサポート シンタックスハイライト機能を備えたファイルツリーとライブ編集機能 WebSocketによるリアルタイムストリーミング通信 Claude Code UIは、Node.js環境で動作し、Viteの開発サーバーを使用してローカルで実行されます。これにより、通常はターミナルでしか操作できないClaude Code CLIを、直感的なWebインターフェースから利用できるようになります。 参照: GitHub – siteboon/claudecodeui Claude Code UI公式サイト 既存の方法とセキュリティの課題 Claude Code UIをモバイルから利用する方法として、Cloudflare TunnelやVS Code Serverを使用した例がいくつか公開されています。 【徹底解説】Claude Code UI と Cloudflare Tunnelでスマホから快適にAIコーディング スマホでClaude Code！？外出先でClaude Codeを使ってみた！！ これらの方法でも外出先からのアクセスは実現できますが、 URLを知っていれば誰でもアクセスできてしまう というセキュリティ上の問題があります。開発環境への不正アクセスは、ソースコードの流出やAPI鍵の漏洩など、深刻な被害につながる可能性があります。 そこで今回は、Tailscaleを使用したよりセキュアなアプローチをご紹介します。Tailscaleを利用することで、認証されたデバイスからのみアクセス可能な、真にプライベートなリモート開発環境を構築できます。 Tailscaleとは TailscaleはWireGuardプロトコルをベースとした、P2P型のメッシュVPNサービスです。2019年に元Googleのエンジニアによって設立されたTailscale社が提供しています。 従来のVPNは中央のゲートウェイサーバーを経由する必要があり、トラフィックの集中や単一障害点といった課題がありました。一方、Tailscaleはデバイス間で直接P2P接続を確立するため、これらの課題を解決しています。 Tailscaleの主な特徴は以下の通りです。 WireGuardによるエンドツーエンドの暗号化通信 ゼロトラスト・アーキテクチャによる高いセキュリティ NATやファイアウォールを自動で透過するNAT Traversal機能 GoogleやMicrosoftなどの既存アカウントで簡単にログイン可能 ACL（アクセス制御リスト）による柔軟なアクセス制御 個人利用であれば最大100台のデバイスまで無料で利用可能 Tailscaleは特別なハードウェアやサーバーの構築が不要で、数分でセキュアなプライベートネットワーク（tailnet）を構築できます。また、既存のネットワーク環境に影響を与えないオーバーレイネットワークとして動作するため、段階的な導入が可能です。 参照: What is Tailscale? – Tailscale Docs Tailscaleとは何? 普通のVPNとは何が違う? セットアップ Claude Code UIを実行するPC まずはClaude Code UIの設定から始めます。前回の記事ではClaude Code UIのライブラリをインストールするところまで行ったので、インストールに躓いた方はそちらを参考にしてください。 環境変数を設定します。README.mdに従って .env.example をコピーして .env を作成します。 cp .env.example .env .env ファイルを編集して、必要に応じてポート番号などを設定します。デフォルトでは3001番ポートが使用されます。 アプリケーションを起動します。 npm run dev ブラウザで http://localhost:5173 にアクセスし、Claude Code UIが正常に起動することを確認してください。 次に、PC起動時に自動でClaude Code UIを起動させるためのバッチファイルを作成します。Windows + Rキーを同時押しして下記のコマンドを入力し、OKを押すとスタートアップディレクトリが表示されます。 shell:startup 下記の内容でバッチファイル start-claude-code-ui.bat を作成し、スタートアップディレクトリに配置します。 @echo off cd /d "C:\\Users\\shota\\ws\\claudecodeui" npm run dev pause Tailscaleのインストールと設定 次にTailscaleをインストールして設定を行います。 Tailscale公式サイト からインストーラーをダウンロードして実行します GoogleやMicrosoftなどの任意のアカウントでログインします Windows版の場合、システムトレイにTailscaleのアイコンが表示されます アイコンをクリックして「Connect」ボタンを押し、VPN接続を確立します 接続が成功すると、デバイスにtailnet用のIPアドレス（100.x.x.x形式）が割り当てられます。 tailscale serveの設定 tailscale serve コマンドを実行して、ローカルで動作しているClaude Code UIをTailscaleネットワーク内に公開します。このコマンドを使用すると、開発中のWebアプリケーションをTailscaleネットワーク内の他のデバイスから安全にアクセス可能にできます。 Claude Code UIはViteの開発サーバーで実行されており、デフォルトではポート 5173 で動作しているため、接続先を http://localhost:5173 として指定します。さらに、オプション --bg を使用することで、ターミナルを閉じてもバックグラウンドでサービスが実行され続けるようにします。 tailscale serve --bg <http://localhost:5173> 実行すると、以下のような出力が表示されます。 Available within your tailnet: <https://test-server.tailXXXXXX.ts.net/> |-- proxy <http://localhost:5173> Serve started and running in the background. To disable the proxy, run: tailscale serve --https=443 off この https://test-server.tailXXXXXX.ts.net/ というURLが、Tailscaleネットワーク内からアクセスできるClaude Code UIのアドレスになります。 重要: tailscale serve で公開したサービスは、デフォルトではHTTPSで提供され、Tailscaleが自動的に証明書を発行します。 スマートフォンなど外出先で使用するデバイス Google Play StoreまたはApp StoreからTailscaleアプリをインストールします Google Play Store Apple App Store PC側と同じアカウントでログインします トグルボタンをタップして Connected 状態にします 接続が成功すると、スマートフォンもtailnet内のデバイスとして認識され、PC側で設定したドメイン名でアクセスできるようになります。 Tailscaleのアクセス制御設定 Tailscaleのデフォルト設定では、自分のデバイス間は全て許可されるというポリシーが設定されています。 { "acls": [ // Allow all connections. // Comment this section out if you want to define specific restrictions. {"action": "accept", "src": ["*"], "dst": ["*:*"]}, ], } しかし、セキュリティを強化するために、ACLを設定してアクセスできるデバイスを制限することをお勧めします。 ACLの設定手順 Tailscale管理コンソール にログインします Access controls から Tags を選択して + Create tag をクリックします 以下の2つのタグを作成します tag:server – Claude Code UIを実行するPC用 tag:client – 外出先で使用するデバイス用 General access rules セクションから + Add rule をクリックして、以下のようなアクセスルールを作成します このルールは「 tag:client を持つデバイスのみが tag:server を持つデバイスにアクセスできる」という意味になります。 Machines ページから各デバイスの設定を開き、適切なタグを割り当てます Claude Code UIを実行するPCに tag:server を設定 スマートフォンなど外出先で使用するデバイスに tag:client を設定 これで tag:client を設定したデバイスからのみ、Claude Code UIにアクセスできるようになりました。 アクセスの確認 スマートフォンのブラウザから、先ほど tailscale serve で表示されたドメイン名にアクセスします。 https://test-server.tailXXXXXX.ts.net/ セキュリティのポイント: Claude Code UIのWebインターフェースが表示されれば、設定は成功です。外出先からでも、自宅のPCで動作しているClaude Codeをセキュアに利用できるようになりました。 Tailscaleの通信は全てWireGuardによってエンドツーエンドで暗号化されています インターネットに直接サービスを公開する必要がなく、Tailscaleネットワーク内でのみアクセス可能です ACLによって、アクセス可能なデバイスを明示的に制限できます ポートフォワーディングやファイアウォールの設定変更が不要です おわりに 今回は、Claude Code UI×Tailscaleで外出先でもセキュアにClaude Codeを使う方法について解説しました。 Tailscaleの簡単なセットアップと強力なセキュリティ機能により、複雑なネットワーク設定なしにリモートアクセス環境を構築できます。 tailscale serve コマンド一つで、開発環境に対してセキュアにアクセスできるシンプルさが魅力です。 Claude Code UIとTailscaleを組み合わせることで、通勤中や外出先からでも、スマートフォンやタブレットを使ってAI支援コーディング環境にアクセスできるようになります。ぜひこの設定を活用して、より柔軟な開発スタイルを実現してみてください。 今回の設定内容については、Tailscaleの公式ドキュメントや Claude Code UI公式サイト も参考にしてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Code UI×Tailscaleで外出先でもセキュアにClaude Codeを使おう! first appeared on SIOS Tech. Lab .

はじめに 前回 はKubeBlocksの解説と他類似OSSDB管理ソリューションの比較を行いました。今回はKubeBlocksでサポートされているDBソリューションについて説明します。 KubeBlokcsがサポートしているDB KubeBlocksとはKubernetesクラスタ上にプライベートなDBaaS（Database as a Service）を構築するためのオープンソース基盤です。多種多様なDBソリューションを統一された方法で管理することができます。 また、KubeBlocksはDB以外にもメッセージキューやストレージシステムに対応しています。 ここではKubeBlocksがサポートしているDBソリューションの説明、そのDBソリューションがどのような場面で利用されるかといったユースケースの説明、KubeBlocksがサポートしているDBの種類について紹介します。 Relational Databases Relational Databases(リレーショナルデータベース)とは データを行と列で構成されるテーブルで整理・格納するデータベースシステムです。リレーショナルデータベースではSQLという言語を使ってデータを操作します。 ユースケース 在庫管理や顧客の情報管理など、一貫性のあるデータの管理、データ同士で連携が必要なシステムで使用できます。 サポート対象DB MySQL：世界で最も広く使われているオープンソースのリレーショナルデータベース MariaDB：MySQLから派生したオープンソースのリレーショナルデータベース PostgreSQL：高機能さと拡張性が特徴のオープンソースのリレーショナルデータベース Vanilla PostgreSQL：カスタマイズしていない素のPostgreSQL　 OrioleDB：PostgreSQLの容量、機能、パフォーマンスを最新のアプローチで向上させるために設計された、新しいストレージエンジン NoSQL NoSQLとは リレーショナルデータベースではないデータベースの総称です。リレーショナルデータベースのような厳格な構造（スキーマ）を緩和することで処理を単純にできるため高速に大量のデータを処理できます。 ユースケース ソーシャルメディアやECサイトなど高速に大量のデータを処理する必要があるシステムに向いています。 サポート対象DB MongoDB：大容量データの保存に使用されるドキュメント指向の NoSQL データベース Redis：高速でオープンソースの、メモリ内のキーバリューデータストア etcd：強力な一貫性のある分散キーバリューストア ZooKeeper：分散システムをまとめる、信頼性の高い集中型サービス OLAP Systems OLAP Systems(オンライン分析処理)とは 複雑なデータベースのクエリを高速に処理する技術の一つです。大量に蓄積されたデータを多角的な視点から素早く分析、集計するために特化したシステム。以下の図は、オンライン分析処理の概念図です。 OLAP Systemsの概念図 ユースケース 売り上げの分析やWebサイトのアクセス解析などのビジネスに関わるリアルタイム性が必要なシステムに向いています。 サポート対象DB Elasticsearch：本番規模のワークロードに最適化されたRESTful検索エンジン ClickHouse：列指向データベース StarRocks：リアルタイム、多次元、高度な同時データ分析が可能な高性能分析データウェアハウス高速な列指向データベース OpenSearch：オープンソースの分散型およびRESTful検索エンジン Distributed SQL Databases Distributed SQL Databases(分散SQLデータベース)とは 複数のサーバー(ノード)にデータを分散した状態で保存する仕組みです。データを分散して保存するが単一のリレーショナルデータベースのように振る舞うことが可能で可用性が高く高負荷の処理に強いという特徴があります。 ユースケース 金融プラットフォームなどの特に高可用性が求められるシステム、ユーザーが世界中にいるグローバルなオンラインサービスなど地理的に広範囲で展開され、一貫性を保つ必要があるシステムに向いています。 サポート対象DB TiDB：MySQL互換の分散データベース OceanBase-CE：C++ で開発された MySQL 互換の分散データベース PolarDB-X：MySQLをベースとした水平スケーリングをサポートするMySQL互換の分散データベース Vector Databases Vector Databases(ベクトルデータベース)とは テキスト、画像、音声などの複雑なデータを「ベクトル」という数値の配列に変換して保管します。意味の近さや類似性に基づいて高速で複合検索をすることができます。以下の図はベクトルデータベースの解説図です。 Vector Databasesの解説図 ユースケース ネットショッピングなどでの類似アイテムの推薦、意味検索など類似性や意味で検索を行うシステムで使用されます。 サポート対象DB Qdrant：ベクトルデータベースおよびベクトル類似性検索エンジン Weaviate：オープンソースのベクトルデータベース Milvus：非常に高速なクラウドネイティブのオープンソースベクトルデータベース Time Series Databases Time Series Databases(時系列データベース)とは 時間の経過とともに記録される時系列データを扱うことに特化したデータベースであり、時間の経過とともに記録されるデータを効率的に管理します。高速な書き込みと、特定の時間範囲での集計・分析処理を効率的に行えるように最適化されています。 ユースケース 需要予測、異常検知など時間ベースの分析が必要なシステムなど様々な分野で使用されています。 サポート対象DB InfluxDB：大規模な時系列データの処理に最適化された専用データベース VictoriaMetrics：監視ソリューションとしての利用に特化した時系列データベース GreptimeDB：スケーラビリティ、分析機能、効率性を重視したオープンソース時系列データベース TDengine：データベース、メッセージキュー、キャッシュ等の機能を統合した産業用IoT向けのデータプラットフォーム Graph Databases Graph Databases(グラフデータベース)とは データをノード（点）とエッジ（線）の集合体（グラフ）として捉えて格納するデータベースです。リレーショナルデータベースでは、テーブル同士の繋がりが増えるほど応答速度が低下します。一方、グラフデータベースは繋がりが増えても応答速度があまり低下しないというメリットがあります。以下の図は、グラフデータベースの概念図です。 Graph Databaseの概念図 ユースケース ソーシャルネットワーク、レコメンデーションなど繋がりがあるデータの検索などに向いています。 サポート対象DB Nebula：数兆のエッジと頂点を持つグラフを保存および処理できるオープンソースのグラフデータベース Message Queues Message Queues(メッセージキュー)とは アプリケーション間でデータを非同期で送受信するための中継役をするデータストレージです。キューがあることでデータを送る側も受け取る側も任意のタイミングで処理を行うことができます。以下の図はメッセージキューの概念図です。 Message Queuesの概念図 ユースケース 非同期処理の実装、マイクロサービス間の疎結合化など、システムの応答性・信頼性などを向上させるために様々な場面で使用されています。 サポート対象ソリューション RabbitMQ：オープンソースの分散イベント ストリーミングプラットフォーム Apache Kafka：信頼性が高いメッセージングおよびストリーミングブローカー Apache Pulsar：オープンソースの分散メッセージングおよびストリーミングプラットフォーム Storage System Storage Systemとは デジタルデータを物理的・論理的に保管、管理するための仕組みや製品全般を差します。 ユースケース データベースやアプリケーションのバックアップ先やAI / 機械学習のデータストレージなど様々なデータの保存や管理に使用されます。 サポート対象ソリューション MinIO：AWS S3互換APIを提供するオブジェクトストレージソリューション おわりに 今回の記事で見てきたように、KubeBlocksでは、多種多様なデータベースを、Kubernetesという共通の基盤の上で、統一された作法で管理することができるのがKubeBlocksの強みです。 KubeBlocksを利用することで開発者はインフラの細かな違いを意識することなく、アプリケーションの要件に最適なデータベースを利用できるようになります。 次回はKubeBlocksの導入としてKubernetes上にDBaaSを構築する手順を解説します。 参考文献 KubeBlocks公式： https://kubeblocks.io/docs/preview/user_docs/overview/supported-addons リレーショナルデータベースとは?メリット・デメリットや活用例を紹介： https://primenumber.com/blog/relational-database NoSQLデータベースとは?メリット・デメリットや活用例を紹介： https://primenumber.com/blog/nosql OLAPとは？特徴や実装方式から他の分析手法との比較も解説： https://primenumber.com/blog/olap OLAPデータベースにおける高速化の技術： https://tech.plaid.co.jp/fundamentals_of_olap_db_technology#%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE%E4%BE%8B 分散データベースとは？特徴とメリット・デメリットを解説： https://www.anken-navi.jp/news/work-freelance/distributed-database/ CockroachDB公式サイト： https://www.cockroachlabs.com/ TiDB公式サイト： https://pingcap.co.jp/ メッセージキューの基礎知識と活用方法： https://tech-education-nav.com/contents/educational-materials/backend-development/message-queues-explained Amazon SQSのユースケースとAWSサービスとの連携例： https://qiita.com/kenogi/items/ea6154a0fc3e2d81622b ベクトル・データベースとは： https://www.oracle.com/jp/database/vector-database/ Vector DB 入門： https://zenn.dev/atusi/articles/61b7f95b4df726 【2025年決定版】ベクトルDB完全比較とRAG最新活用： https://arpable.com/artificial-intelligence/rag/vector-database-rag/ 時系列データベースとは? 時系列データの活用例や専用DBの必要性について解説： https://www.ctc-g.co.jp/keys/blog/detail/what-is-a-time-series-database 時系列データベースとは？基本と活用のメリット： https://products.sint.co.jp/siob/blog/time-series-database グラフデータベースとは？RDBとの違いや主要4製品の比較まとめ： https://aerospike.co.jp/blog/what-is-graph-database/ グラフデータベースとは何か　～ネットワーク状のデータ構造から瞬時に情報を検索するDBを解説： https://www.imagazine.co.jp/12805-2/ いまさら聞けない、ストレージとサーバの違い： https://www.netapp.com/ja/blog/server-and-storage/ MinIO公式： https://www.min.io/   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KubeBlocksでサポートされるDBの種類を徹底解説！ first appeared on SIOS Tech. Lab .

こんにちは、OSS よろず相談室の鹿島です。 はじめに 今回は、DifyとAmazon Bedrockを連携させて、チャットボットとRAG（検索拡張生成）を構築する手順の4回目、最終回です。 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る① 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る② 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る③ 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る④ 　←本記事 前回までで、構築したDify環境とAmazon Bedrockを連携させ、チャットボットを作成しました。 今回は、RAGを作ってみます。 DifyのRAGは、PDFやテキストなどの社内文書を知識ベースとしてAIに組み込むことができる機能です。 これにより、AIはインターネット上にない社内情報や専門的な質問にも、正確な根拠を持って回答できるようになります。 　ステップ１ ナレッジを作成する 以下のURLにアクセスします。 http://[DifyをインストールしたマシンのIPアドレス] 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る① でアカウントを作成してログインしていますので、ホームのページが表示されます。 ①「ナレッジ」②「ナレッジを作成」を選択します。 ステップ2　ナレッジを登録する ナレッジとして登録するサンプルとして、厚生労働省が公開しているモデル就業規則をダウンロードしましょう。 以下のページから「モデル就業規則」のPDF版をダウンロードしてください。 https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/roudoukijun/zigyonushi/model/index.html ナレッジのデータソースの選択画面で、①「テキストファイルからインポート」②「テキストファイルをアップロード」を選択します。 ダウンロードしたPDFファイルを選択してアップロードします。最後に「次へ」を選択します。 ステップ3　ナレッジの設定をする はじめに、チャンクの設定をします。 チャンク とは、RAG（検索拡張生成）において、AIが扱いやすいようにドキュメントや知識ベースを分割した小さな情報の塊のことです。 長文をそのままAIに入力すると、重要な情報を見落としたり、処理の負荷が高くなったりする問題が発生します。 このチャンク単位で情報を検索し、質問に関連性の高い部分だけをAIに渡すことで、回答の精度と効率を向上させます。 チャンクの詳細については「 弊社ブログ(チャンキング) 」を参照してください。 ここではデフォルトのまま進めます。 次に「インデックス方法」という選択肢があります。 「経済的」は無料で使用できますが、キーワード検索が中心となります。 今回は、「 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る② 」で Amazon Bedrockでの設定/本記事で利用するモデル で、RAG用に以下のモデルを有効にしました。 Titan Text Embeddings V2 Rerank 1.0 これらのモデルを活用して高精度な検索を実現するため、今回は「高品質」を選んでみましょう。 高品質を選択すると、「埋め込みモデル」を選択できます。 注意点として、ここの選択肢には、 Amazon Bedrockの設定 で有効にしなかったモデルも表示されます。 有効にしていないモデルを選択すると、ここではエラーになりませんが、後にナレッジベースの作成でエラーになります。 有効にしたモデル、ここでは「amazon.titan-embed-text-v2:0」を選択します。 次に、「検索設定」を選択します。 検索方法には3種類あり、「ベクトル検索」は文章の意味の近さで探し、「全文検索」はキーワードの一致で探します。そして、両方を組み合わせた「ハイブリッド検索」が最も精度が高いとされ、推奨されています。 ここでは推奨の「ハイブリッド検索」を選択します。 検索設定では、「rerankモデル」を選択します。 ここでも、Amazon Bedrockの設定で有効にしなかったモデルも選択肢に表示されますが、有効にしたモデルを選択します。 ここでは、「amazon.rerank-v1:0」を選択します。 最後に「保存して処理」をクリックします。 「ナレッジベースが作成されました」「埋め込みが完了しました」と表示され、緑のチェックが付けば成功です。 なお、先述の通り、Bedrockで有効にしていないモデルを選択すると以下のように、赤く表示されます。 [!]マークにマウスカーソルを合わせると、「 AccessDeniedException: You don't have access to the model with the specified model ID 」と表示され、モデルへのアクセス権がないことが分かります。 処理が成功したら「ドキュメントに移動」を選択します。 以下のように、ステータスが「利用可能」になっていればナレッジの作成は成功です。 なお、検索設定やrerankの詳細については、Dify公式マニュアルもあわせて参照してください。 参考： Dify公式マニュアルー検索方法の指定 ステップ4 チャットボットにナレッジを適用する 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る③ と同様に、チャットボットを作成しましょう。 チャットボットの設定画面で、コンテキストの「追加」を選択します。 すると、先ほど作成したナレッジが表示されます。 ステップ3で作成したナレッジを選択します。 次に、オーケストレーションのプロンプトを編集します。 今回は以下のように入力してみましょう。 「あなたはコンテキストに基づいて回答するチャットボットです。コンテキストに無い質問には「コンテキストに回答がありません」とのみ回答してください」 と入力しておきます。 設定が完了したら、実際に質問してみましょう。 まずはナレッジに含まれる内容について、 「有給休暇について教えて」 と質問します。 すると、アップロードした就業規則のコンテキストに基づいて回答してくれます。 回答の下には根拠となった引用コンテキストが表示され、クリックすると関連度のスコアなどを確認することができます。 次にコンテキストと関係のない質問をします。 「 サンシャインコーストはどこにありますか 」と入力すると、プロンプトの指示通り、まずコンテキストに情報がない旨が表示され、その後にLLM自身の知識から回答が生成されます。 このように、ナレッジ（コンテキスト）がある場合はそれを優先して回答し、ない場合はLLMが直接回答するといった制御が、簡単な設定だけで実現できました。 以上、4回にわたり、DifyとAmazon BedrockのLLMを使用して、RAGアーキテクチャを採用したチャットボットを構築する手順をご紹介しました。 弊社の記述ブログには、Difyに関連する記事が複数ありますので、あわせてご参照ください。 Dify入門ガイド：初心者でもわかる！簡単RAG構築 世界一わかりみの深いDify ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る④ first appeared on SIOS Tech. Lab .

はじめに ども！今月はがっつりと開発期間をいただいて、社内で活用できるサービスを作成しつつ、AIとの開発検証を進めている龍ちゃんです。作るものが多くてあっちにフラフラこっちにフラフラって感じです。 今回は、「 Claude Code革命！3フェーズ開発で効率的な開発：計画→実装→検証術 」で提唱した「計画ドキュメント」を用いての開発を3カ月ほど続けたので、そこに対する知見を書いていこうと思います。 結論は「計画ドキュメント」ってめちゃくちゃ大事じゃね？ってお話です。 問題：AIに丸投げすると何が起きるか 技術選定を任せる危険性 開発を進めていく中で、最も課題となったのが「AIに技術選定を委ねてしまう」という問題でした。 具体的な例として、 私はSWRで全ての処理を自動生成しようと試みていました。SWRは本来データフェッチングに特化したライブラリですが、CRUD操作の全てをSWRで解決しようとしていたのです。これは設計思想から考えると適切ではありませんでした。 CRUDの4つの要素のうち、SWRが最適化されているのは主にRead（データ取得）の部分です。Create、Update、Deleteの3/4については本来の用途から外れているにも関わらず、統一性を重視して全てSWRで実装しようとしていました。 人間の開発者であれば「SWRの実装が複雑になるようであれば、素直にAxiosを使用した方が良い」という判断ができます。しかし、AIにはこうした経験に基づく技術的判断や、ライブラリの適切な使い分けに関する感覚が不足しているようです。 龍ちゃん システムプロンプトで「SWRを絶対使うように」って書いていたので、技術選定をしたのは人間なのですがそれに対する課題などの指摘は特にないってのが問題ですね。 AIの限界：誤字脱字と文脈の理解 プロンプトを通じたやり取りで発生する問題も重要な課題でした。 入力に誤字脱字が含まれている場合、AIはそれを修正することなく処理を継続してしまいます。技術用語の誤入力などがあっても、人間であれば文脈から推測して修正できるような内容でも、AIは字面通りに解釈して間違った方向に進んでしまうことがあります。 この結果、想定していたアーキテクチャから逸脱した実装が生成されたり、設計方針に一貫性がなくなったりする問題が発生しました。 具体例として、README.mdに「SWRを必ず使用すること」という記述があったのですが、これが問題の原因となりました。Orvalの設定を適切に調整すれば回避できた問題でしたが、全てのエンドポイントに対してAxiosとSWRの両方のクライアントが生成される状況で、AIは一貫してSWRを選択し続けていました。 根本原因：意思決定の不在 これらの問題の本質は、 人間が行うべき意思決定をAIに委ねてしまっている 点にあります。 人間の開発者は、明文化されていない暗黙知に基づいて技術的判断を行うことがあります。「この技術領域では一般的にこのようなアプローチを取る」といった、体系化されていない経験則や業界標準に関する知識です。 こうした暗黙知は、各開発者の経験や学習によって蓄積されたものですが、現在のAIには十分に備わっていないと感じています。もちろん、私の技術力が不足しているため、AIの能力を十分に引き出せていない可能性もありますが、この差を埋める仕組みが必要です。 その仕組みこそが、 計画ドキュメント による意思決定の明文化なのです。 解決策：計画ドキュメント = 意思決定の場 人間同士の協働 vs AI協働の違い 人間同士での開発とAI協働での開発では、「暗黙知の共有レベル」に大きな差があります。 人間同士での協働の場合： 共通の技術的背景知識を前提とした議論が可能 「一般的にはこのようなアプローチを取る」という共通認識 文脈を理解した柔軟な修正と提案 暗黙の了解による効率的なコミュニケーション AI協働の場合： 明示的に指示された内容のみに基づく判断 技術的なベストプラクティスの理解が限定的 プロンプトの内容に対する忠実な実行 全ての判断基準の明文化が必要 つまり、AI協働においては 全ての意思決定プロセスを文書化 することが不可欠となります。 計画ドキュメントで決めること 計画ドキュメントで明文化すべき要素は、主に以下の4つです： 技術選定： 選定理由とともに、採用しない選択肢（禁則事項）についても記載 ライブラリ間の使い分け基準の明確化 例：SWRはデータフェッチ（Read）操作のみに使用し、CUD操作にはAxiosを使用する アーキテクチャ方針： フロントエンド・バックエンド間の責任境界 エラーハンドリングの統一方針 状態管理の方法と各層の責務 API設計： エンドポイントの命名規則と構造 レスポンス形式の統一ルール エラーレスポンスの標準フォーマット 実装方針： ディレクトリ構成とファイル配置のルール コンポーネント設計のガイドライン テスト方針とカバレッジ基準 意思決定と実行の分離 効果的なAI協働を実現するには、 意思決定フェーズと実行フェーズを明確に分離 することが重要です。 人間の役割： 何を作るか、どのような方針で開発するかを決定する AIの役割： 決定された方針に従って、実際のコードを生成・組み立てる この役割分担により、AIの長所である「高速で大量のコード生成」を活かしながら、人間の「経験に基づく技術判断」を適切に反映できるようになります。 計画の品質が成果物の品質を決定するのは開発の基本原則ですが、特にAI協働においては「計画ドキュメントがプロジェクトの成否を左右する」と言えるでしょう。 実行の標準化：パーツと自動生成 品質保証としてのパーツ化 実際の開発では、意思決定した内容を「パーツ」として標準化することで品質を保証できます。これはソフトウェア工学における品質管理の考え方と共通しています。 システム開発において、個々のコンポーネントの品質がシステム全体に与える影響は重大です。一つのコンポーネントに不具合があると、それがシステム全体の信頼性を損なう可能性があります。プログラムにおいては多少の技術的負債を抱えても稼働し続けることは可能ですが、基盤となるパーツがすべて品質に問題を抱えている場合は、深刻な影響が生じます。 特にフロントエンドを開発する際は、外部のAPIや自作のAPIをパーツとしてとらえることで、作業領域が明確化されます。 人間の役割： 作成すべき機能と要件を明確に定義する 使用するパーツの選択と品質基準の設定 パーツの妥当性と整合性を検証する パーツ/自動生成の役割： 実装方法を標準化し、一貫性を保つ コードの品質を一定レベルに維持する 再利用性を高め、開発効率を向上させる AIの役割： 定義されたパーツを適切に組み合わせて実装する ボイラープレートコードの大量生成を効率化 人間が決定した設計方針に従ってコードを構築する 実例：自動生成パイプライン 具体例として、OpenAPIスペックから型定義を自動同期するパイプラインを構築した際の事例をご紹介します。 // DTO定義（人間による意思決定） interface UserCreateRequest { name: string; email: string; role: 'admin' | 'user'; } // 型定義とAPI関数は自動生成 const createUser = async (data: UserCreateRequest) => { return axios.post<UserResponse>('/api/users', data); }; この実装において重要なポイントは、 DTO定義という設計判断は人間が行い、実行部分（型定義生成、API関数生成）は自動化 している点です。これにより、設計の一貫性を保ちながら実装効率を大幅に向上させることができました。 参考事例：Shadcn/uiのアプローチ Shadcn/uiは、UIコンポーネント開発において「パーツ化」の優れた事例を提供しています。 このライブラリが革新的な点は、UIコンポーネントを標準化された「パーツ」として提供し、開発者が「どのコンポーネントを使用するか」という意思決定に集中できる環境を作り出していることです。AIは「パーツを選択して適切に組み合わせる」という作業に集中でき、結果として開発効率と品質の両立を実現しています。 この考え方は、API接続層やビジネスロジック層にも応用可能であり、AI協働開発における有効なパターンとなり得ると考えています。 実践：意思決定を握る3原則 原則1：計画ドキュメントでの明文化 実施内容： 技術選定の理由を具体的かつ詳細に文書化 実装方針を明確で実行可能なレベルまで記述 暗黙知となっている判断基準の言語化 明文化の範囲について： 理論的にはどこまで詳細化しても構いませんが、コンテキスト量の制約があることを考慮する必要があります。特にClaude等のLLMを使用する場合、トークン制限により詳細すぎる文書は処理できなくなる可能性があります。このバランス調整は現在の技術的制約として受け入れる必要があります。 実践的な運用方法： バックエンドとフロントエンドを並行開発する場合、計画ドキュメントに加えて具体的な実装手順をToDo形式で管理することを推奨します。進捗を可視化することで、AIツールが予期せず停止した場合でも、明確な再開ポイントを確保できます。 原則2：パーツによる実行の標準化 実施内容： 再利用可能なコンポーネント・関数の設計と整備 API接続の標準化（型定義、エラーハンドリング含む） 開発ツール（Linter、Formatter等）の統一と自動化 品質保証の重要性： 個々のパーツの品質は、システム全体の安定性に直結します。不適切な設計のパーツを多数組み合わせると、保守性や拡張性に深刻な問題が生じる可能性があります。そのため、パーツ設計段階での品質基準の設定と検証が不可欠です。 原則3：検証による継続的改善 実施内容： 計画と実装結果の差分分析と記録 発見された問題点や改善点の体系的な蓄積 得られた知見の次回プロジェクトへの適用 現実的な視点の重要性： 完璧な計画ドキュメントや仕様書を最初から作成することは現実的ではありません。開発過程で「より良いアプローチが明確になる」ことは自然な現象です。 そのような状況では、変更の必要性を適切に判断し、修正された方針で実装を完了させることが重要です。完了後には計画と実装の差分を分析し、その経験を将来のプロジェクトに活かすことで、継続的な改善を図ることができます。 まとめ：意思決定は人間、実行はAI 本記事では、3ヶ月間のAI協働開発を通じて得られた実践的な知見をもとに、効果的な協働体制の構築について詳しく解説してきました。 重要ポイントの整理： 技術選定の主導権確保 – AIに技術的判断を委ねることのリスクと、経験に基づく適切な技術選択の重要性 計画ドキュメントによる意思決定の明文化 – 暗黙知の言語化と、全ての判断基準の明確化の必要性 意思決定と実行の明確な分離 – 人間とAIの適切な役割分担による効率化の実現 パーツ化による実行の標準化 – 品質保証と再利用性向上のための設計アプローチ 継続的改善による知見の蓄積 – 完璧性よりも学習と改善を重視したアプローチ 結論として 、現在のAI協働開発においては、 人間が意思決定を行い、AIが実行を担当する という役割分担が最も効果的であると考えられます。 AI技術は急速に進歩していますが、現時点では経験に基づく技術的判断や、コンテキストを考慮した柔軟な意思決定において、人間の能力に及ばない側面があります。一方で、大量のコード生成や、定められたパターンに従った実装作業においては、AIの方が高速かつ正確に処理できます。 この技術特性を理解し、適切な役割分担を実装することで、AI協働開発の真価を発揮することが可能になります。 実践への提案 AI協働開発を検討されている方は、まず「計画ドキュメント」の作成から始めることをお勧めします。初期段階では作成コストが高く感じられるかもしれませんが、中長期的には開発効率と成果物の品質において大幅な改善効果が期待できます。 この記事で紹介した3原則と実践的アプローチが、皆さんのAI協働開発プロジェクトの成功に寄与できれば幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AI協働開発の落とし穴回避！3ヶ月で実証した計画ドキュメントの価値 first appeared on SIOS Tech. Lab .

こんな方へ特におすすめ これから本格的なWebアプリ開発を始めたい方 自分だけの快適な開発環境を整えたい方 チーム開発で「自分の環境だけ動かない…」を撲滅したい方 PCを買い替えてもすぐに開発を再開したい方 概要 こんにちは。サイオステクノロジーのはらちゃんです！今回5本目のブログ執筆です。 今回は、バックエンド(Python/FastAPI)とフロントエンド(Node.js/React)を分離したモダンなWebアプリケーション開発を想定し、 VS CodeのDev Container 機能を使って、誰でも同じ環境を再現できる開発環境を構築する手順を解説します。 Dev Containerという最適解 新しいプロジェクトを始めるたびに 「Pythonのバージョンは…？」 「Node.jsのバージョンは…？」 と環境構築で時間を取られていませんか？Dev Containerは、Dockerコンテナーの技術を使い、プロジェクトごとに隔離された最適な開発環境をコード（設定ファイル）で管理できるVS Codeの素晴らしい機能です。 これを使えば、新しいメンバーも数コマンドであなたと全く同じ開発環境を立ち上げることができます。今回は、無料のAIコーディング支援ツール Codeium も導入し、より快適な環境を目指します。 発生しがちなエラーとその解決策も詳しく紹介するので、ぜひ最後までお付き合いください！ Step０：前提条件 VSCodeがインストールされている Docker Desktopまたは Rancher Desktop がインストールされている (Windowsの場合) WSL2が有効になっている Step１：プロジェクトの骨格を作る まず、プロジェクト全体のフォルダ構成を整え、Dockerで各サービス（バックエンド、フロントエンド、DB）をどう連携させるかを定義する docker-compose.yml を作成します。 ディレクトリの作成 以下のようなフォルダ構成を作成します。 .devcontainer フォルダの中に backend と frontend のサブフォルダを作るのがポイントです。 HaraSpace/ │ ├── .devcontainer/ │ │ │ ├── backend/ │ │ └── devcontainer.json │ │ │ └── frontend/ │ └── devcontainer.json │ ├── backend/ │ │ │ ├── Dockerfile │ └── requirements.txt │ ├── frontend/ │ │ │ ├── Dockerfile │ └── package.json │ ├── docker-compose.yml │ └── wait-for-it.sh docker-compose.ymlの作成 プロジェクトのルートに、3つのサービスを定義する docker-compose.yml を作成します。 docker-compose.yml services: backend: build: context: . dockerfile: backend/Dockerfile target: development # 開発用ステージを指定 command: ["wait-for-it.sh", "db:3306", "--", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"] volumes: - ./backend:/workspace/backend ports: - "8000:8000" depends_on: - db frontend: build: context: . dockerfile: frontend/Dockerfile target: development # 開発用ステージを指定 # --hostフラグでコンテナ外からのアクセスを許可 command: ["npm", "run", "dev", "--", "--host"] volumes: - ./frontend:/workspace/frontend ports: - "3001:3000" depends_on: - backend db: image: mysql:8.0 ports: - "3307:3306" environment: - MYSQL_ROOT_PASSWORD=your_root_password - MYSQL_DATABASE=sql_app_db volumes: - db_data:/var/lib/mysql volumes: db_data: wait-for-it.sh ファイルの準備 GitHub からダウンロードし、プロジェクトの ルートディレクトリ （ docker-compose.yml と同じ場所）に配置するのが一般的です。 Step２：各サービスの設計図を書く 次に、バックエンドとフロントエンドそれぞれのコンテナー環境の設計図となる Dockerfile を作成します。今回は、開発用と本番用で設定を分ける「 多段ビルド 」という手法を採用します。 バックエンド 現在の既定である、Python 3.12をベースイメージとして使用します。 backend/Dockerfile # ---- 1. 全ステージで共通のベース ---- FROM python:3.12-slim as base WORKDIR /workspace/backend ENV PYTHONPATH "${PYTHONPATH}:/workspace/backend" # wait-for-it.shをコピーして実行権限を付与 COPY wait-for-it.sh /usr/local/bin/wait-for-it.sh RUN chmod +x /usr/local/bin/wait-for-it.sh # 依存関係をインストール COPY backend/requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt # ---- 2. 開発用ステージ ---- FROM base as development CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"] # ---- 3. 本番用ステージ ---- FROM base as production # (ここに本番用の設定を記述...) 同じディレクトリに必要なライブラリを記述します。 backend/requirements.txt fastapi uvicorn[standard] pymysql フロントエンド Node.js 22をベースに使います。VS Codeとの相性を考慮し、 alpine ではなく slim イメージを使うのが安定動作の鍵です。 frontend/Dockerfile # ---- 1. ベースステージ (依存関係のインストール) ---- FROM node:22-slim as base WORKDIR /workspace/frontend COPY frontend/package*.json ./ RUN npm ci # ---- 2. 開発用ステージ ---- FROM base as development COPY frontend/ ./ EXPOSE 3000 CMD ["npm", "run", "dev", "--", "--host"] # ---- 3. 本番用ステージ ---- FROM base as production # (ここに本番用の設定を記述...) フロントエンドも同じディレクトリに必要なライブラリを記述します。 手動で package.json を作成するよりも、 Vite (ヴィート) というツールを使ってプロジェクトの雛形を自動生成するのが現在の主流で、簡単かつ確実です。 frontend ディレクトリの中で以下のコマンドを一度実行するだけで、ReactやVueなどに最適化された最低限の package.json が自動的に作成されます。 まず、 frontend ディレクトリに移動します。 bash cd frontend 次に、Viteの作成コマンドを実行します。 bash npm create vite@latest . -- --template react このコマンドを実行すると、いくつかの質問をされますが、基本的にはEnterキーを押していけばOKです。 Step 3：VS Codeとコンテナーを繋ぐ設定 最後に、VS Codeに対して「どちらのコンテナーに接続して開発作業を行うか」を教えるための devcontainer.json を作成します。 バックエンド backend/Dockerfile { "name": "Backend Container", // 使用するdocker-compose.ymlのパスを、このファイルからの相対パスで指定 "dockerComposeFile": [ "../../docker-compose.yml" ], // docker-compose.ymlに定義したサービスの中から、接続したいサービス名を指定（最重要） "service": "backend", // コンテナに接続したときに開く作業フォルダ "workspaceFolder": "/workspace/backend", "customizations": { "vscode": { // Python開発に特化した拡張機能を追加 "extensions": [ "ms-python.python", "ms-python.vscode-pylance", "charliermarsh.ruff" // Python用の高速Linter ] } } } フロントエンド frontend/Dockerfile { "name": "Frontend Container", // 使用するdocker-compose.ymlのパス "dockerComposeFile": [ "../../docker-compose.yml" ], // 今度は'frontend'サービスに接続するよう指定 "service": "frontend", // フロントエンド用の作業フォルダを指定 "workspaceFolder": "/workspace/frontend", "customizations": { "vscode": { // フロントエンド開発に特化した拡張機能を追加 "extensions": [ "dbaeumer.vscode-eslint", "esbenp.prettier-vscode", "Codeium.codeium" ] } }, // フロントエンドのポートをフォワーディング "forwardPorts": [3001] } これで準備完了です！VS Codeでプロジェクトフォルダを開き、左下の緑色のアイコン >< をクリックして「 コンテナーで再度開く (Reopen in Container) 」を選択すると、バックエンドとフロントエンドのどちらで作業を開始するか選べるようになります！ ハマりどころを徹底解説！よくあるエラーと解決策 環境構築にはエラーがつきものです。今回私が遭遇した主なエラーとその解決策を共有します。 エラー1： wait-for-it.sh: not found や Dockerfile の変更が反映されない 原因 Dockerが古いイメージキャッシュを使い回している可能性があります。 対処法 VS Codeのコマンドパレット( Ctrl+Shift+P or Cmd+Shift+P )から Dev Containers: Rebuild and Reopen in Container を実行し、イメージを強制的に再構築します。 エラー2： port is already allocated (ポートが既に使用されている) 原因 以前のコンテナーが完全に停止しておらず、ポートを掴んだままになっています。 対処法 プロジェクトルートでターミナルを開き、 docker compose down コマンドを実行して関連コンテナーをすべて停止・削除します。 エラー3： Exit code 137 (メモリ不足) 原因 Docker (特にRancher Desktop) に割り当てられたメモリが不足し、コンテナーがOSに強制終了させられています。 対処法 (Rancher Desktopの場合) : Windowsのユーザーフォルダ( C:\Users\<ユーザー名> )に .wslconfig というファイルを作成します。 以下の内容を記述して保存します。(PCの搭載メモリに合わせて 8GB の部分を調整) PowerShellで wsl --shutdown を実行し、Rancher Desktopを再起動して設定を反映させます。 PowerShell notepad .wslconfig もしファイルがまだ存在しない場合、「 新しいファイルを作成しますか？ 」と聞かれるので、「 はい 」をクリックしてください。メモ帳が起動します。 開いたメモ帳に、以下の内容をコピーして貼り付けてください。 [wsl2] memory=8GB processors=4 memory=8GB : WSL全体で使用できるメモリの上限を8GBに設定します。PCの搭載メモリの半分程度を目安に、 6GB や 12GB などに調整してください。 この設定が最も重要です。 processors=4 : WSLが使用できるCPUコア数を4に設定します。PCのCPU性能に合わせて調整すると、より快適になります（省略しても構いません）。 この設定を有効にするには、WSLを 完全にシャットダウン する必要があります。 PowerShellのウィンドウに戻り、以下のコマンドを打ち込んでEnterキーを押してください。 PowerShell wsl --shutdown コラム：Codeiumとは… Codeiumは、AIを活用してコーディングを支援するツールです。 無料で始められる 手軽さと 強力なコード補完機能 で、GitHub Copilotの代替としても注目されています。 AIによるコード自動補完 入力中のコードの続きを予測して、関数全体や定型文などを数行にわたって提案してくれます。 AIとのチャット エディタ内でAIチャットが利用できます。コードの解説、リファクタリング、テストコードの生成、デバッグの補助など、コーディングに関する様々な質問や依頼を自然言語で行えます。 70以上の言語に対応 PythonやJavaScriptといった主要な言語はもちろん、C++、Java、Goなど、70種類以上のプログラミング言語に対応しており、幅広い開発プロジェクトで利用できます。 多くのエディタに対応 Visual Studio Codeをはじめ、JetBrains製IDE（IntelliJ IDEA, PyCharmなど）、Vim/Neovim、Jupyter Notebookなど、普段使っている開発環境に拡張機能として簡単に追加できます。 プライバシーとセキュリティ Codeiumは、ユーザーのコードをAIの学習データとして保存しない仕組みを採用しています。そのため、企業の機密情報や個人のプロジェクトでも安心して利用できます。 まとめ お疲れ様でした！今回は、バックエンドとフロントエンドを柔軟に切り替えながら開発できる、再現性の高いDev Container環境が完成しました。 最初は設定ファイルが多くて戸惑うかもしれませんが、一度この環境を構築してしまえば、あとは 設定ファイルをGitで管理するだけ で、チームメンバー全員が数分で全く同じ開発環境を手に入れることができます。 Github に今回紹介した開発構成をプッシュしているのでそちらもご活用ください。 環境差異による不毛なトラブルから解放され、本来集中すべきアプリケーション開発に時間を使えるようになります。ぜひDev ContainerとCodeiumを活用して、快適な開発ライフを送ってください！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post 開発環境の作り方｜Dev ContainerとCodeiumの活用 first appeared on SIOS Tech. Lab .

初めに ども！今月はAI開発にどっぷりな毎日な龍ちゃんです。今回は「 AIと爆速開発！Next.js×Nest.js型定義同期の自動生成パイプライン構築術 」で開発効率を上げたんですが、そこで起きた問題について原因究明と解決策を模索したので解説していこうと思います。 TL;DR Orvalで全APIエンドポイントにSWRフックを自動生成していたんですが、 バンドルサイズの肥大化 と 不要なオーバーヘッド が問題になってしまいました。 解決策 : client: "axios-functions" に変更して、Axios関数のみを自動生成。SWRは必要な箇所のみカスタムフック実装する方針に切り替えました。 結果 : 47ファイルの移行（4.2時間）で、バンドルサイズを20-30%削減できました！ 問題の発見：便利すぎる自動生成の罠 最初はOrvalで全APIエンドポイントにSWRフックを自動生成する設定にしていました。便利だと思っていたんですよね。型安全だし、統一感もあるし。 でも2ヶ月ほど経った頃、ふと気づいたんです。バンドルサイズはどんどん肥大化していくし、mutation処理は無駄にSWRを経由しているし、コードは複雑になっていく一方。 何かがおかしい。 そこで改めて考え直してみました。SWRって、そもそも何のためのツールだったっけ？と。 SWRの本質を見つめ直す SWRは データ取得（Read）のために設計 されたライブラリです。名前の由来である「stale-while-revalidate」という戦略が示す通り、以下のような特徴があります： キャッシュ戦略による高速な表示 自動再検証（フォーカス時、再接続時など） 複数コンポーネント間でのデータ共有 これって、まさにCRUDのRead（データ取得）に最適化された設計なんですよね。 一方で、 CUD（Create/Update/Delete）はどうでしょうか？ useSWRMutation というフックも用意されていますが、よく考えてみると一回限りのmutationにキャッシュ戦略は不要です。フォーム状態との統合も煩雑になりがちでした。 それなのに、全エンドポイント分のSWRフックを自動生成していたら、本質的には不要なコードが大量に生まれてしまっていたんです。 Before/After: Orval設定の変更 それでは、具体的にどう変更したのか見ていきましょう。 Before（旧設定） output: mode: "split" # ❌ ラッパー関数が生成される client: "swr" # ❌ SWRフック自動生成 # ... 問題点 : 全エンドポイント分のSWRフックが生成され、バンドル肥大化。mutationにも不要なSWRオーバーヘッドが発生していました。 After（新設定） output: mode: "single" # ✅ 直接エクスポート client: "axios-functions" # ✅ Axios関数のみ生成 # ... 改善点 : Axios関数のみを生成し、SWRは必要な箇所のみ手動で作成。バンドルサイズを20-30%削減できました。 シンプルですよね。でも、この変更が大きな効果を生んだんです。 自動生成の3つの問題 実際に移行作業を進めながら、自動生成のどこが問題だったのか明確になってきました。 1. 不要なオーバーヘッド 例えば、投稿を作成する処理を考えてみてください。これって一回限りのアクションですよね。キャッシュも再検証も不要なのに、SWRの状態管理オーバーヘッドが動いている。これは明らかに無駄でした。 2. バンドルサイズの肥大化 数字で見ると、問題の大きさがよくわかります： 項目 Before After 改善 自動生成フック数 41個 0個 完全削除 バンドルサイズ 100% 70-80% 20-30%削減 コード行数 ~2030行 ~800行 約60%削減 全エンドポイント分のSWRフックが生成されて、使わないものも含めて全部バンドルに入ってしまっていたんですね。 3. コンポーネント設計の硬直化 これが一番厄介でした。SWRの状態（ isMutating , error ）とフォームの状態（ isSubmitting , validationErrors ）が分裂してしまって、同期が複雑化していたんです。 実際にフォームを実装していると、「あれ、どっちのエラー状態を見ればいいんだっけ？」みたいなことが頻発していました。 解決策：適材適所のアプローチ そこで、シンプルな方針に切り替えました： ✅ Read（GET） → カスタムSWRフック ✅ CUD（POST/PUT/DELETE） → 直接Axios呼び出し それぞれ見ていきましょう。 パターン1: データ取得（カスタムSWRフック） データ取得には、SWRの恩恵を最大限活用します。 // hooks/useSeriesDrafts.ts import useSWR from "swr"; import { seriesDraftsControllerFindAll } from "@/lib/api/generated"; / シリーズ下書き一覧を取得するカスタムフック SWRのキャッシュ・再検証・データ共有の恩恵を受けられる / export const useSeriesDraftsControllerFindAll = () => { return useSWR("/api/series-drafts", () => seriesDraftsControllerFindAll()); }; // コンポーネントでの使用 const { data, error, isLoading } = useSeriesDraftsControllerFindAll(); SWRのキャッシュ戦略により、複数のコンポーネントで同じデータを効率的に共有できます。フォーカス時の自動再検証なども自動で行われるので、常に新鮮なデータを表示できるんですよね。 パターン2: mutation（直接Axios呼び出し） 一方、データの作成・更新・削除は直接Axiosを呼び出します。 import { useState } from "react"; import { mutate } from "swr"; import { seriesDraftsControllerCreate } from "@/lib/api/generated"; const [isCreating, setIsCreating] = useState(false); / シリーズ下書きを作成する処理 SWRのオーバーヘッドなしで、シンプルに実装できる / const handleCreate = async (data) => { setIsCreating(true); try { await seriesDraftsControllerCreate(data); // 作成後、SWRキャッシュを更新して一覧を再取得 mutate("/api/series-drafts"); } finally { setIsCreating(false); } }; このアプローチなら、不要なオーバーヘッドを回避できて、フォーム状態との統合も容易になります。必要に応じて mutate() でSWRキャッシュを更新すれば、一覧表示も自動的に最新化されます。 シンプルでわかりやすいですよね。 移行中に発見したバグ 実は移行作業中に、思わぬバグも見つかりました。 axiosInstance と axiosClient の混同 : 3つのファイルで axiosClient をAxiosインスタンスとして誤使用していたんです。 // ❌ Before（バグ） import { axiosClient } from "@/lib/axiosClient"; await axiosClient.get("/.auth/me"); // TypeError! // ✅ After（修正） import { axiosInstance } from "@/lib/axiosClient"; await axiosInstance.get("/.auth/me"); 教訓 : axiosClient はOrval mutator関数として使うもので、直接HTTP呼び出しには axiosInstance を使用する必要があります。 命名が似ていると、こういう混同が起きやすいんですよね。移行作業のおかげで、潜在的なバグを早期発見できたのは副次的な効果でした。 移行結果：数字で見る効果 実際の移行結果をまとめてみます。 対象範囲と効果 47ファイル移行完了 （実装時間: 4.2時間、推定14-20時間 → 21-30%効率化） バンドルサイズ20-30%削減 （自動生成フック: 41個 → 0個） カスタムフック : 9個を必要箇所のみ作成 コード行数 : ~2030行 → ~800行（約60%削減） 当初は14-20時間かかると見積もっていたんですが、4.2時間で完了できました。Axiosの関数がパーツとして提供されていたおかげで、AIに実装を任せる際もスムーズに進められたんです。 AI開発を効率化する「パーツ提供」の考え方 今回の経験で実感したのが、 AI開発を効率化する鍵は「パーツを提供する」という考え方 だということです。 shadcn/uiが成功しているのも同じ理由ではないでしょうか。コンポーネントをコピペして、必要に応じてカスタマイズできる。全部を自動生成するのではなく、パーツを提供する。 Axiosのインターフェース部分をパーツとして切り出しておけば、そこに処理を書かせるだけでOK。このアプローチによって、開発効率が飛躍的に向上しました。 フロントエンドとバックエンドの型の齟齬もなくなりましたし、手が止まることも減りました。すっきりとしたコードで実装できるようになったんです。 まとめ：適材適所が長期的な保守性を生む SWRは素晴らしいツールです。でも、すべてのAPI呼び出しに必要なわけではありません。 適材適所のアプローチ : データ取得（Read） : SWRの恩恵を最大限活用 mutation（CUD） : シンプルにAxiosで十分 「便利だから」という理由で全てを自動生成すると、不要な複雑さとバンドル肥大化を招いてしまいます。 Axiosでパーツのみを提供し、SWRは必要な箇所に手動で適用する。この「適材適所」のアプローチが、長期的な保守性と柔軟性を生むんですね。 皆さんも、もし自動生成で「何か複雑になってきたな」と感じたら、一度立ち止まって考えてみてください。本質的に必要なものは何か、ツールの設計思想に沿った使い方ができているか。そこを見直すことで、より良い設計にたどり着けるはずです。 今回の知識を活かして、ぜひ皆さんのプロジェクトでも最適なアプローチを見つけてみてください！ 参考リソース Orval – OpenAPI to TypeScript SWR – React Hooks for Data Fetching 包括的な実装検証ドキュメント ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Orval SWRの自動生成をやめた理由 – SWRの本質を見失っていた話 first appeared on SIOS Tech. Lab .

こんにちは、伊藤です。 Microsoft Entra IDでは、CSVファイルによるアカウント作成、削除の一括処理機能がありますが、パスワードの一括リセット機能はありません。 また、管理者がMicrosoft Entra IDのパスワードをリセットする場合、一般的には以下のようにユーザーの概要ページから実行します。しかし、この方法では任意のパスワードを指定できません（オンプレミスADとのアカウント同期とパスワードの書き戻しが有効な場合を除く）。 そこで今回は、これらの課題を解決するため、CSVファイルを使ってMicrosoft Entra IDのユーザーパスワードを一括でリセットするPowerShellスクリプトと、その使い方を紹介します。 本稿で取り上げた課題およびコードは2025年10月段階のものであり、今後のMicrosoft Entra IDの更新により解決されたり、修正が必要になったりする場合があります。 前提条件 ・Microsoft Entra IDテナントと、そのユーザーに対してパスワードリセットを実行できる管理者アカウントを保有していること ・使用するPowerShellにMicrosoft Graph PowerShell SDKがインストールされていること 以下のコマンドでMicrosoft Graph PowerShell SDKをインストールできます。 Install-Module Microsoft.Graph.Users -Scope CurrentUser パスワードリセット用CSVファイルを作成する 一括パスワードリセット用のCSVファイルを作成します。 ユーザープリンシパル名（UserPrincipalName）、パスワード（Password）の列を指定します。 パスワードを指定しない場合は、スクリプトがランダムなパスワードを生成します。 例： UserPrincipalName,Password test01@example.com,P@ssw0rd test02@example.com, PowerShellスクリプトを作成する PowerShellスクリプトファイルを作成します。 -InputFile オプションでCSVファイルを指定し、 -OutputFile オプションで一括パスワードリセット結果のファイルを指定できるようにします。 -OutputFile を指定しない場合は、タイムスタンプ付きのファイルが作成されます。例： reset_results_20250829155001.csv CSVファイルでパスワードを指定したユーザーはそのパスワードに、指定しなかったユーザーはランダムに生成されたパスワードにリセットされます。ランダムパスワードは、英大文字、英小文字、数字、記号がそれぞれ2文字以上含まれる16文字のランダム値を生成します。 ・entraidpasswordreset.ps1 #requires -Modules Microsoft.Graph.Users param( [Parameter(Mandatory = $true, HelpMessage = "ユーザーリストのCSVファイルパスを指定してください")] [string]$InputFile, [Parameter(HelpMessage = "結果を出力するCSVファイルパスを指定してください")] [string]$OutputFile = ".\reset_results_$(Get-Date -Format 'yyyyMMddHHmmss').csv" ) # Microsoft Graphに接続します (未接続の場合) if (-not (Get-MgContext)) { Write-Host "Microsoft Graphに接続します..." -ForegroundColor Yellow # 必要なアクセス許可スコープを指定して接続 Connect-MgGraph -Scopes "User-PasswordProfile.ReadWrite.All" } # 結果を格納するための空の配列を作成 $results = @() # CSVファイルからユーザーリストをインポート try { $users = Import-Csv -Path $InputFile } catch { Write-Host "エラー: 入力ファイルが見つからないか、読み込めません。パスを確認してください: $InputFile" -ForegroundColor Red return } Write-Host "パスワードリセット処理を開始します..." -ForegroundColor Cyan # 各ユーザーに対してループ処理 foreach ($user in $users) { $upn = $user.UserPrincipalName $newPassword = $null $forceChangeOnNextSignIn = $true # 次回サインイン時にパスワード変更を強制 try { # CSVにPassword列が存在し、かつ値が空でないかチェック if ($user.PSObject.Properties.Match('Password') -and -not [string]::IsNullOrEmpty($user.Password)) { # --- パターン1: CSVで指定されたパスワードを使用 --- $newPassword = $user.Password Write-Host "[$upn] CSVで指定されたパスワードを設定します。" } else { # --- パターン2: ランダムなパスワードを生成 --- Write-Host "[$upn] ランダムパスワードを生成します。" $charSets = @{ Upper = 'ABCDEFGHIJKLMNPQRSTUVWXYZ' Lower = 'abcdefghijlkmnpqrstuvwxyz' Number = '0123456789' Symbol = '@#$%^&*-_!+=[]{}|\:'',.?/`~"();<>' } $passwordChars = [char[]]($charSets.Upper.ToCharArray() | Get-Random -Count 2) + [char[]]($charSets.Lower.ToCharArray() | Get-Random -Count 2) + [char[]]($charSets.Number.ToCharArray() | Get-Random -Count 2) + [char[]]($charSets.Symbol.ToCharArray() | Get-Random -Count 2) $remainingChars = [char[]]($charSets.Values -join '') | Get-Random -Count 8 $newPassword = ($passwordChars + $remainingChars | Get-Random -Count 16) -join '' } # パスワードリセットの実行 $passwordProfile = @{ ForceChangePasswordNextSignIn = $forceChangeOnNextSignIn Password = $newPassword } Update-MgUser -UserId $upn -PasswordProfile $passwordProfile -ErrorAction Stop Write-Host "成功: $($upn) のパスワードをリセットしました。" -ForegroundColor Green $results += [PSCustomObject]@{ UserPrincipalName = $upn NewPassword = $newPassword Status = "Success" } } catch { $errorMessage = $_.Exception.Message Write-Host "失敗: $($upn) のパスワードリセット中にエラーが発生しました。エラー: $errorMessage" -ForegroundColor Red $results += [PSCustomObject]@{ UserPrincipalName = $upn NewPassword = "N/A" Status = "Failed - $errorMessage" } } } # 結果をCSVファイルに出力 $results | Export-Csv -Path $OutputFile -NoTypeInformation -Encoding UTF8 # Microsoft Graphから切断します Write-Host "Microsoft Graphから切断します..." -ForegroundColor Yellow Disconnect-MgGraph Write-Host "全ての処理が完了しました。結果は '$($OutputFile)' を確認してください。" -ForegroundColor Cyan このスクリプトは、ユーザーが次回サインインする際にパスワードの変更を強制します。 もしパスワード変更を強制したくない場合は、スクリプト内の以下の行を見つけ、値を $true から $false に修正してください。 変更前： $forceChangeOnNextSignIn = $true # 次回サインイン時にパスワード変更を強制 変更後： $forceChangeOnNextSignIn = $false # 次回サインイン時にパスワード変更を強制しない PowerShellスクリプトを実行してユーザーパスワードを一括リセットする PowerShellスクリプトを実行します。 例： > .\entraidpasswordreset.ps1 -InputFile .\reset_users.csv -OutputFile .\reset_users_result.csv Microsoft Graphに未接続の場合はログイン画面が表示されます。Microsoft Entra IDのユーザーに対してパスワードリセットを実行できる管理者アカウントでログインします。 Microsoft Graphに接続後はパスワードリセット処理が実行されます。 パスワードリセットに成功した場合は「成功: <ユーザープリンシパル名>のパスワードをリセットしました。」と表示されます。 パスワードリセットに失敗した場合は「失敗: <ユーザープリンシパル名>のパスワードリセット中にエラーが発生しました。」と表示されます。 全ての処理が完了すると、一括パスワードリセット結果が出力用のCSVファイルに書き込まれます。このファイルには、ユーザープリンシパル名、新しいパスワード、そして処理結果（成功の場合は「Success」、失敗の場合は「Failed – <エラーの詳細>」）が記録されます。 例： "UserPrincipalName","NewPassword","Status" "pwreset-test01@example.com","deko89IFLEU","Success" "pwreset-test02@example.com","H7T*#t9smrahS@3U","Success" "pwreset-test03@example.com","N/A","Failed - [Request_BadRequest] : The specified password does not comply with password complexity requirements. Please provide a different password." パスワードリセットの失敗例 パスワードリセットに失敗した場合のよくある原因を以下に示します。 Microsoft Graphに接続できない Microsoft Graphに接続できなかった場合は以下のエラー文が表示されます。 Authentication needed. Please call Connect-MgGraph. ユーザーがMicrosoft Entra IDテナント内に存在しない Microsoft Entra IDテナント内に存在しないユーザープリンシパル名を指定すると、対象ユーザーが存在しないためエラーになります。この場合は以下のエラー文が表示されます。 [Request_ResourceNotFound] : Resource '<指定したユーザープリンシパル名>' does not exist or one of its queried reference-property objects are not present. リセットしようとしたパスワードが、Microsoft Entra IDのパスワードポリシーに違反している パスワードを指定してリセットした場合、Microsoft Entra IDのパスワードポリシーによりパスワードのリセットに失敗する場合があります。この場合は以下のエラー文が表示されます。 [Request_BadRequest] : The specified password does not comply with password complexity requirements. Please provide a different password. パスワードポリシーを無視してパスワードをリセットしたい場合は、ユーザーのパスワードポリシーを一時的に変更してパスワードをリセットすることも可能です。その場合は、Microsoft Graphに接続する箇所およびユーザー情報を更新する箇所を修正してください。 <省略> # Microsoft Graphに接続します (未接続の場合) if (-not (Get-MgContext)) { Write-Host "Microsoft Graphに接続します..." -ForegroundColor Yellow # 必要なアクセス許可スコープを指定して接続 Connect-MgGraph -Scopes "User.ReadWrite.All,User-PasswordProfile.ReadWrite.All" } <省略> # パスワードリセットの実行 $passwordProfile = @{ ForceChangePasswordNextSignIn = $forceChangeOnNextSignIn Password = $newPassword } Update-MgUser -UserId $upn -PasswordPolicies "DisableStrongPassword" -ErrorAction Stop Update-MgUser -UserId $upn -PasswordProfile $passwordProfile -ErrorAction Stop Update-MgUser -UserId $upn -PasswordPolicies None -ErrorAction Stop <省略> Microsoft Entra IDの運用上パスワードを無期限にしたい場合は、パスワードリセット処理後のパスワードポリシー( -PasswordPolicies )を None から "DisablePasswordExpiration" に修正してください。 まとめ 今回は、CSVファイルを利用してMicrosoft Entra IDのユーザーパスワードを一括リセットするPowerShellスクリプトを紹介しました。 Microsoft Entra IDのアカウント管理に活用していただけると幸いです。 参考 参考 Microsoft Graph PowerShell を使用してパスワードを管理する – Microsoft 365 Enterprise 参考 セルフサービス パスワード リセット ポリシー – Microsoft Entra ID 参考 PowerShell を使用してランダムな文字列を生成する方法 Delft スタック ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Microsoft Entra IDのユーザーパスワードを一括リセットする first appeared on SIOS Tech. Lab .

はじめに 今回から複数の記事にまたがって KubernetesでDBを管理するために役立つKubeBlocksというソリューションについて解説します。KubeBlocksがどんなソリューションであるか理解するとともにKubernetesでのDB管理の重要性について理解していただけると幸いです。 DBaaSとは Kubeblocksの解説に入る前に、まず「DBaaS」と、それをKubernetes上で実現するメリットについて整理します。 DBaaS（Database as a Service）とは、クラウド上で提供されるデータベース管理サービスです。 従来のデータベース管理はデータベースサーバーのセットアップからパッチ適用、バックアップ、監視といった運用タスクを手動で行う必要がありました。DBaaSを利用することで、それらの操作を簡易化・自動化することが可能になります。 従来のDB管理とDBaaSの比較 KubernetesでDB管理することの重要性 DBをKubernetesで管理することによって大きく3つの利点があります。 運用プラットフォームの統一 Kubernetesにアプリケーションをデプロイして、外部でDBを管理している場合、運用するプラットフォームが分断されて運用コストが上がってしまいます。アプリケーションがデプロイされているKubernetes上でもDBを管理することで運用がシンプルになり、運用コストを抑えることができます。 高度なDB構成を簡易に構築 Kubernetesのオーケストレーション機能を活用することで、冗長性や可用性を考慮した高度なDB構成を簡易に構築することが可能です。 また、DBの運用作業を自動化することが可能で、構築から運用まですべての管理を効率化することができます ベンダーロックインの回避 特定のクラウドベンダーのDBaaSを利用すると、その特定のシステムの仕様に深く依存することになり、将来的に別の環境に移行する際の障壁が高くなります。 KubernetesでDB管理する場合、YAMLファイルといった統一的なファイルを利用することで別環境でも同一のDB構成を簡単に構築することが可能です。 KubeBlocksの概要 KubeBlocksはデータベース用のオープンソースKubernetesオペレーターです。 KubeBlocksの構造（参照：https://kubeblocks.io/docs/preview/user_docs/overview/introduction） KubeBlocksを導入することによってKubernetesクラスタ上に、DBaaSを構築することが可能です。 KubeBlocksの大きな特徴として、特定のDBに依存しない汎用的なDBオペレーターになっています。これにより、データベースのデプロイ、スケーリング、バックアップといった複雑な運用タスクが自動化されます。さらに、PostgreSQLやMySQLなど様々な種類のデータベースを、統一されたYAML記法で管理できるため、複数DBの運用が非常にシンプルかつ効率的になります。   MySQLクラスターを構築するYAMLファイルの例 apiVersion: apps.kubeblocks.io/v1 kind: Cluster metadata: name: test-mysql namespace: demo spec: terminationPolicy: Delete componentSpecs: - name: mysql componentDef: "mysql-8.0" serviceVersion: 8 . 0 . 35 disableExporter: false replicas:   2 resources: limits: cpu: '0.5' memory: 0 . 5Gi requests: cpu: '0.5' memory: 0 . 5Gi volumeClaimTemplates: - name: data spec: storageClassName: "" accessModes: - ReadWriteOnce resources: requests: storage: 20Gi PostgreSQLクラスターを構築するYAMLファイルの例 apiVersion: apps.kubeblocks.io/v1 kind: Cluster metadata: name: test-pg namespace: demo spec: terminationPolicy: Delete clusterDef: postgresql topology: replication componentSpecs: - name: postgresql serviceVersion: 16.4.0 disableExporter: true replicas: 2 resources: limits: cpu: "0.5" memory: "0.5Gi" requests: cpu: "0.5" memory: "0.5Gi" volumeClaimTemplates: - name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi KubeBlocksには「kbcli」というコマンドラインツールが備わっています。これを利用することでKubeBlocksのリソースの操作をより簡単に行うことが可能です。 「kbcli」で出来る操作としてDBクラスタのバックアップの作成、kbcliの追加機能の管理、データベースクラスタのライフサイクル管理、kubeBlocks自体の管理などがあります。 KubeBlocksに対応しているDBソリューションに関してはシリーズ第2回となる次のブログ記事で、具体的な一覧と共に詳しく解説します。 KubeBlocksでDBクラスターを構築した際の構成例が以下になります： KubeBlocksの構成例（参照：https://kubeblocks.io/docs/preview/user_docs/overview/introductio） デフォルトでは、KubeBlocks Control Planeと呼ばれるKubeBlokcsの管理を行うノードとKubeBlocks Data Planeと呼ばれるDBがデプロイされるノードに別れます。これにより高可用性を保持することが可能になります。 さらに、データベースクラスターの各レプリカをAvailability Zones（AZ）に分散させることで、災害復旧能力も高めることが可能です。 KubeBlocksの主要機能 様々な種類のDBクラスターのプロビジョニング・削除・起動・停止・再起動 幅広いDay-2 オペレーション 水平スケーリング 垂直スケーリング DBクラスターが使用しているPVCの拡張 バックアップ・リストア DB構成の変更 DBインスタンスの移行 ローリングアップデート Prometheusと連携した監視 他類似OSSDB管理ソリューションとの比較 Kubernetes上でデータベースを管理するためのオペレーターはいくつか存在しますが、ここでは代表的なオープンソースのオペレーターであるKubeDB, Percona Everest, StackGresとKubeBlocksを比較し、それぞれ特徴と最適なユースケースを探ります。 OSSDB管理ソリューションの比較 この比較表から分かるように、各オペレーターには得意分野があります。 KubeDB KubeDBは、非常に多くのデータベースをサポートする汎用性の高いオペレーターです 。運用機能も豊富で、GitOpsとの連携も可能です 。ただし、オープンコアモデルを採用しており、バックアップや監視などの多くの高度な機能は有償のエンタープライズ版でのみ利用可能という点に注意が必要です 。 Percona Everest Percona Everestは、Perconaが提供するデータベース（PostgreSQL, MySQL, MongoDB）に特化しています 。最大の特徴は、Perconaの強力な監視ツール「PMM (Percona Monitoring and Management)」と深く連携し、クエリ分析など高度な監視を容易に実現できる点です 。直感的なWeb UIも提供されており、CLI操作に不慣れなユーザーでも扱いやすいのが魅力です 。 StackGres StackGresは、対応データベースをPostgreSQLに絞ることで、その運用を極限まで自動化・最適化することに特化したオペレーターです 。高可用性を実現するPatroniや接続プーリングを行うPgBouncerが標準で統合されており、150以上の拡張機能が利用可能です 。PostgreSQLをメインで利用する開発チームにとって、最も高機能な選択肢の一つと言えるでしょう。100%オープンソースであることも大きな特徴です 。 おわりに 本記事では、Kubernetes上でDBaaSを実現するソリューションとして、オープンソースの汎用データベースオペレーター「KubeBlocks」を解説しました。KubeBlocksは、特定のデータベースに依存しない高い汎用性を持ち、多種多様なデータベースを統一された手法で効率的に管理できる非常に強力なツールです。 多様なデータベースを運用している環境 運用をシンプルに統一したいチーム 上記のようなニーズを持つチームにとって、KubeBlocksは最適な選択肢の一つとなるでしょう。今後もKubeBlocksについての解説ブログを掲載していくのでよろしくお願いします。 参考文献 KubeBlocks公式ドキュメント： https://kubeblocks.io/docs/preview/user_docs/overview/introduction KubeDB公式ドキュメント： https://kubedb.com/ Percona Everest公式ドキュメント： https://www.percona.com/software/percona-everest StackGres公式ドキュメント： https://stackgres.io/features/ kbcliコマンドリファレンス： https://kubeblocks.io/docs/preview/cli/kbcli ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KubeBlocksとは？KubernetesでDBを管理する新常識 first appeared on SIOS Tech. Lab .

OSS よろずチームの神﨑です。 RHEL 10 同梱版の Podman の変更点について簡単にまとめていきたいと思います。 Podman のインストールと起動確認 AWS の RHEL10 のインスタンスで検証しています。 1.インストール # dnf install podman # podman version Client: Podman Engine Version: 5.4.0 API Version: 5.4.0 Go Version: go1.23.10 (Red Hat 1.23.10-1.el10_0) Built: Wed Jun 25 00:00:00 2025 Build Origin: Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> OS/Arch: linux/amd64 2.コンテナイメージ導入 (httpd) # podman search httpd # podman pull registry.access.redhat.io/ubi10/httpd-24 3. コンテナの起動 実行例 # podman run -d -p 8080:8080/tcp --name my-rootless-httpd registry.redhat.io/ubi10/httpd-24 Podman に関する変更点 RHEL 公式ドキュメントを確認したところ以下の記述がありました。 containers.conf ファイルの読み取り専用となる システム接続とファームの情報が containers.connections.json に移動しました。 CNI ネットワークスタックのサポート終了と netavark への移行 containernetworking-plugins パッケージが削除され、CNI がサポートされなくなります。 runc コンテナランタイムの削除 デフォルトのコンテナランタイムが crun になります。 slirp4netns ネットワークモードが非推奨となる ルートレスコンテナのデフォルトネットワークモードが pasta になります。 RHEL 10 ホストでの RHEL 7 コンテナの非サポート 詳細は、 Red Hat Enterprise Linux Container Compatibility Matrix  を参照してください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post RHEL 10 同梱版の Podman についての調査 first appeared on SIOS Tech. Lab .

Webサイトやアプリ開発の現場で、「デザインシステム」という言葉を耳にする機会が増えていませんか？「なんだか難しそう…」「自分には関係ないかも」と感じている方もいるかもしれません。 しかし、デザインシステムは、開発の効率を上げ、チームのコミュニケーションを円滑にし、プロダクトの品質を一貫して高く保つための、非常に強力な武器になります。 この記事で「良さそう、面白そう」と思っていただければ幸いです。 デザインシステムとは？ 「デザインシステム」って、そもそも何でしょうか？ その定義は場合によって異なり、ひとつに定めるのは、難しいです。 そこで、ザックリ「狭義の…」「広義の…」と2つに分けて解釈を試みます。 狭義のデザインシステム：再利用可能な「部品集」 狭義のデザインシステムは、 デザインの具体的な構成要素やルールをまとめたもの を指します。これは、デザイナーやエンジニアが直接的に利用する「部品」や「説明書」の集まりと考えると分かりやすいでしょう。 UIコンポーネント : ボタン、フォーム、アイコン、カードなど、繰り返し使えるデザインの部品。 デザイントークン : 色、タイポグラフィ（フォントサイズや種類）、スペーシング（間隔）などを管理する変数。これにより、デザインの変更が一括で容易になります。 スタイルガイド : ブランドのロゴの使用法や、デザインの原則などを定めたルールブック。 ドキュメンテーション : 各コンポーネントの使い方や、デザインの意図を解説した文書。 これらは、Figmaのようなデザインツールや、Storybookのような開発者向けのコンポーネントライブラリとして具体的に存在します。 一言でいうと ：「デザインと開発で使う、再利用可能な『レゴブロック』と『その組み立て方』のセット」です。 広義のデザインシステム：一貫性を生み出す「文化」と「プロセス」 広義のデザインシステムは、単なる部品集にとどまらず、 製品開発に関わる人々の協力体制や思想、ワークフロー全体 を包含します。 思想と原則 : なぜそのデザインなのか？という根本的な考え方や、チームが共有する価値観（例：「シンプルであること」「アクセシビリティを重視すること」など）。 コミュニケーション : デザイナー、エンジニア、プロダクトマネージャーなどが円滑に協力するためのコミュニケーションの仕組みや文化。 ガバナンス : デザインシステムを誰が、どのように更新し、管理していくかという運用ルール。 ワークフロー : デザインシステムを実際の製品開発に組み込み、継続的に改善していくプロセス。 こちらは、ツールとして存在するだけでなく、チームの文化や働き方そのものに根付いています。 一言でいうと ：「良い製品を効率的に作り続けるための『共通言語』であり、チームの『文化』」です。 上記はあえて2つに分類しましたが、実際のデザインシステムは広義と狭義の中間にあることが多いかと思います。 また、デザインシステムは、一度作って終わりではありません。プロダクトやチームの成長に合わせて、継続的に育てていくものです。 なぜ、いま「デザインシステム」なのか？ 「車輪の再発明」を減らす パソコンとスマートフォンは、多くのひとの仕事や生活のツールとして実用化し、コモディティ化と言ってよい段階と捉えています。 わたしたちが、新たなアプリケーション、ウェブサイトを構築する際、多くの場合に既存のデザインシステムが参考になります。 SmartHRのデザインシステムにて述べられている「“車輪の再発明”を減らす」という考え方です。 https://smarthr.design/introduction/operate-policy 巨人の肩の上に立つ ありがたいことに、世界の大企業や政府を始めとする、さまざまな団体の知見を活用することができます。 公開された各デザインシステムは、日々進化していますが、その多くが高い品質に達しています。 生成AI時代のUIの土台 「生成AI」によって、コンピューターを利用するためのインターフェースは、見直されていくかもしれません。 今後、AIによってUIの生成が自動化されても、その基盤となる一貫したルールやコンポーネントは必要となるでしょう。 事例紹介：世界の優れた公開デザインシステム 品質、汎用性、応用性が高く、Figmaファイルも公開されているデザインシステムを、UIデザイナーの視点でピックアップして、紹介します。 政府系 行政は対象者が多様なため、特にアクセシビリティを重視していることが特徴かと思います。 文字やボタンなどの要素は大きく、余白も十分。 イギリス政府「GOV.UK Design System」 https://design-system.service.gov.uk/ https://www.figma.com/community/file/946837271092540314/gov-uk-design-system シンプル、アクセシブル、スタイリッシュ、が実現されています。 スタイルとしては、ボタンの形状が角丸ではなく四角いのも特徴。 「Cookie banner」がコンポーネント化されているのもヨーロッパらしいです。 抽象面では、Principles（原則）も秀逸で、ポスターもあります。 https://www.gov.uk/guidance/government-design-principles https://github.com/alphagov/govdesign/blob/main/Poster_GovernmentDesignPrinciples.pdf アメリカ政府「U.S. Web Design System (USWDS)」 https://designsystem.digital.gov/ https://www.figma.com/@uswds 文字サイズ定義の最小がイギリス政府のものが16pxに対して、こちらは13pxです。 UI要素全般的に、イギリス政府に比べると小さい設計です。 これは、大きな国土、多くの人口、多様性、という背景から、訴訟社会、ローコンテクストな傾向にあるため、さまざまなシーンで説明的になる。つまり文章が長く、文字が多くなるのでしょう。 多くの情報が表現できることと、アクセシブルであることのバランスを定着させた事例と捉えています。 デジタル庁（日本） https://design.digital.go.jp/ https://www.figma.com/@digitalagencyjp イギリス政府のデザインシステムと同様に、シンプルで明快な印象のスタイルです。 UIコンポーネントの名称は「検索ボックス」「パンくずリスト」「日付ピッカー」のように、平易な表現となっています。 近い将来、各省庁をはじめ、多くの各行政機関のサイトが、このデザインシステムに沿って構築、運用されることを、期待しています。 日本の企業 SmartHR https://smarthr.design/ https://www.figma.com/community/file/978607227374353992 フルセットのデザインシステムです。 デザインシステムの構想、構築、運用を教えてくれる書籍「ちいさくはじめるデザインシステム」も出版されています。 https://bnn.co.jp/products/9784802512480 デザインシステムを学習、検討するなら必見です。 Ubie「Ubie Vitals」 https://vitals.ubie.life/ https://www.figma.com/design/ejIFAbw12HtoEZXcn01G5C/Ubie-UI https://www.figma.com/@ubie デザイン原則では「気軽」「かんたん」「誠実」「スッキリ」と謳われています。 その原則がドキュメントにも現れており、簡潔で把握しやすいです。 シンプルであるとともに、ライディングガイドライン、コンポーネント、GitHubでのコード公開など、ドキュメントの構成が行き届いています。 ライティングガイドラインには医療機関での問診の文例があり、アイコン集には形状の異なる複数の薬剤など「医療」という特定の分野に焦点あわせて設計された事例としても参考になります。 「Ubie Vitals」という名前は、医療用語の「バイタルサイン」に由来していると考えられ、デザインシステムの重要性と、医療分野へ注力していることが表されていると思います。 プラットフォーマー Google「Material Design」 https://m3.material.io/ https://www.figma.com/@materialdesign Android OS、Googleの各サービスが基本的にこれに則っており、一番利用されているUIかもしれません。 最も影響力のあるデザインシステムと言ってもよいでしょう。 Material DesignをReactで実装する際は、MUIが便利です。（MUIはMaterial Designのバージョン2を基にしています。） https://mui.com/ Apple「ヒューマンインターフェイスガイドライン（HIG）」 https://developer.apple.com/jp/design/human-interface-guidelines/ https://www.figma.com/@apple 「無料で公開されている資料」ではありますが、オープンソースではありません。 基本的には、iPhoneやMacなど、Apple製品向けアプリケーション開発を行う際に参照するドキュメントです。 「デザインシステム」という言葉が広く使われるようになったのは2010年代ですが、Appleは1980年代からHIGを定めています。 ユーザー体験を重視し、パソコンやスマートフォンを絶対的な価値に高めたメーカーが、どのような考え方でUI構築をしているのかを知ることができます。 スマートウォッチや、MR（複合現実）ヘッドセットのUIも含まれているのも特徴です。 IT分野、業務向け 各政府や、Google、Appleなどのデザインシステムが主に消費者向けなのに対し、IBM、GitHub、Atlassianの例は、複雑で大量の情報を扱うための効率性や機能性を追求した専門家向けです。 IBM「Carbon」 https://carbondesignsystem.com/ https://www.figma.com/@50ffba2e_c3b3_4 AI生成のコンテンツであることを示す「AI Label」コンポーネントも用意されています。 GitHub「Primer」 https://primer.style/ https://www.figma.com/community/file/854767373644076713 「Product UI」「Brand UI」に分けて設計されており、どちらも公開されています。 Atlassian https://atlassian.design/ https://www.figma.com/@atlassian 今回は、デザインシステムの基本的な捉え方から、公開されている優れた事例までを紹介しました。 まずは今回紹介したデザインシステムを実際に触ってみることから始めてみませんか？公開されたドキュメントを眺めるだけでも、UIデザインの新たな発見があるはずです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 良いプロダクトは「システム」でできている。デザインシステムとは何か？ first appeared on SIOS Tech. Lab .