こんにちは！SCSKの野口です。 前回の記事では、RAGの全体像（Indexing / Retrieval / Augmentation / Generation）と、「LLMの性能そのものより、前段の設計で品質が決まる」ことを整理しました。 （シリーズ1：RAGの基本情報 / 第1回）RAGとは：全体像、なぜ必要か、基本フローと設計の勘所 RAG（検索拡張生成）の定義、なぜ必要か、基本フロー（Indexing/検索/補強/生成）を整理します。 blog.usize-tech.com 2026.01.27 今回はシリーズ1（RAGの基本要素）の第2回として、 「チャンキング（チャンク化）」 を扱います。 早速ですが皆さんに質問です。 「検索結果は返ってくるのに、回答が噛み合わない／断片的になる」こと、ありませんか？ 現場でよく起きるこの状況、Retrieval（検索）の問題に見えますが、実は Indexing時に“根拠をどう切り出して保存したか” が原因になっているケースが少なくありません。 というのも、RAGは「検索したチャンク（断片）」をコンテキストとしてLLMに渡す仕組みなので、 そもそもチャンクの単位が悪ければ、検索が当たっていても“回答に必要な情報が揃わない” 状態になります。 RAGからの情報検索自体は成功しているのに取得した情報の品質が低い——これはRAGの“あるある”です。 そこで本記事では、まず RAG全体像の中でチャンキングがどこに位置し、どのような役割を果たしているのか を図で押さえたうえで、サイズ・オーバーラップ・戦略の選び方、そして簡単な検証デモまで一気に整理します。 本記事で扱う範囲 チャンキングの位置づけ ：RAGのIndexing工程の中で、チャンキングが検索品質にどう効くか 設計パラメータと戦略 ：chunk size / overlap の勘所と、代表的なチャンキング戦略の使い分け 検証の進め方 ：LangChain + Vertex AI Embeddings（Google）で、戦略差を“取得チャンク”として見える化するデモ ※評価（Ragasなどの定量評価）は重要なので触れますが、詳細は次回（評価編）で扱います。 RAGのIndexing工程 チャンキングは、RAGのIndexing（インデックス作成）工程の中核です。ここでの設計が、後続のRetrieval品質に直結します。 Indexingの基本フロー 文書を取り込む（Parsing / 整形） 文書をチャンクに分割する（Chunking） チャンクを埋め込みに変換する（Embeddings） ベクトルDB（または検索基盤）に保存する（Indexing） 基本フローに関しては、私が発表した下記資料「RAGの全体像とチャンキングの位置付け」でまとめているので一読ください。 ※Parsing部分については表現を省いた図を載せています。 2026年1月 豊洲会（発表資料）     また、下記AWSブログでもRAGの流れが記載されています。 Evaluate the reliability of Retrieval Augmented Generation applications using Amazon Bedrock | Amazon Web Services In this post, we show you how to evaluate the performance, trustworthiness, and potential biases of your RAG pipelines a... aws.amazon.com チャンキング（チャンク化）とは チャンキング（Chunking）とは、長いドキュメントを 検索と生成に扱いやすい単位 へ分割し、各チャンクを埋め込み（Embedding）に変換して保存する工程です。 ポイントは、チャンキングが単なる「文章を切る」作業ではなく、 検索精度・文脈保持・コスト・レイテンシを制御する重要な作業 だという点です。極端に言えば、LLMがどれだけ高性能でも、 “拾う根拠がズレていれば、ズレたまま賢く答える” だけです。 先程の発表資料内でも触れていますが、「 不適切なチャンクは、ゴミを入れてゴミを出す（Garbage In, Gargabe Out） 」と言い換えることができます。   まず押さえる：サイズとオーバーラップ（最重要パラメータ） チャンキング設計の基本は、 chunk size（サイズ） と chunk overlap（オーバーラップ） です。ここを外すと、後段の「戦略（splitter）の種類」をどれだけ工夫しても、Retrieval品質が安定しません。 用語整理：chunk / chunk size / chunk overlapについて ここでいう chunk は「検索・生成で扱うために分割したテキストのひとかたまり」を指します。 そのひとかたまりの上限長が chunk size 、隣り合うチャンク同士で 重複させる長さ が chunk overlap です。 chunk size ：1チャンクに含めるテキスト量（上限）。単位は トークン （推奨）または文字数。 chunk overlap ：隣接チャンク間で重複させる量。境界で情報が欠けるのを緩和する役割を持つ。 図解：size=500, overlap=100 のとき何が起きる？ 例えば chunk size = 500 、 overlap = 100 なら、 1つ目のチャンクが 0〜500、2つ目は 400〜900 のように 100分だけ重なります 。 （※開始位置は (n-1) × (size - overlap) のスライディングウィンドウになります） 図　例）サイズとオーバーラップの関係 精度・文脈・コストへの影響について chunk size と overlap は、 検索精度（ノイズ） 、 文脈保持（断片化耐性） 、 コスト／レイテンシ に影響を与えます。 ここでは「 回答がどう崩れているか 」の感覚が掴めるように、ポイントだけ整理します。 1) chunk size が影響を与えるもの（ノイズ ↔ 文脈） 大きすぎる ：1チャンクに関係ない情報が混ざりやすく、検索でノイズが乗る（ベクトルが“平均化”され、クエリとの整合が甘くなる）。生成側も入力トークンが増え、コスト・レイテンシが増える。 小さすぎる ：条件・例外・参照（主語、前提）がチャンク境界で別れやすくなり、回答が断片的になりやすい。チャンク数が増えるため、検索（Top-k / rerank）負荷も増えやすい。 2) chunk overlap が影響を与えるもの（境界欠落 ↔ 冗長） 固定長分割では、文の途中や「ただし〜」などの条件節が境界で切れやすく、取得はできても「例外条件が落ちる」「主語が消える」といった形で回答が崩れることがあります。 overlap はこの“境界欠落”を緩和 します。 overlap を増やす ：断片化に強くなる（必要な根拠が同じチャンクに残りやすい）。 overlap を増やしすぎる ：同じ内容が複数チャンクに入って検索結果が冗長になり、コストも増える（インデックスサイズ・取得チャンク重複）。 3) chunk size / overlapの調整 まず 固定長 + overlap をベースラインにして、 回答がどう崩れているか（断片化／ノイズ混入など） を見ながら調整するのが堅実です。 回答が断片的  → overlap を増やす、または size を少し大きくする 関係ない文が混ざる（ノイズ） → overlap を減らす、size を小さくする、必要なら構造認識・メタデータを活用する 目安としては、まず overlap を chunk size の 10〜20% 程度から始めると、境界問題を抑えつつコストもそこまで増えることはないかと思います。 トークン基準で考えることの重要性 チャンクサイズを文字数で切ると、モデル側のトークナイザ差分で 想定以上にトークンが膨らむ ことがあります。 そのため、文字数を基準にチャンクサイズを選択するのではなく、「トークンベースでサイズを管理」する事が重要となります（特に日本語は差が出やすい）。 下記の公式情報は参考になるので、ご確認ください。 ・Azure AI Search：チャンキングの考え方／推奨の出発点（例：512 tokens + 25% overlap） Chunk documents - Azure AI Search Learn strategies for chunking PDFs, HTML files, and other large documents for agentic retrieval and vector search. learn.microsoft.com ・Google Cloud：取り込み時の chunk_size / chunk_overlap、レイアウト解析の統合（RAG Engine） Use Document AI layout parser with Vertex AI RAG Engine  |  Generative AI on Vertex AI  |  Google Cloud Documentation cloud.google.com ・Weaviate：chunkingのベースラインと発展手法の整理（overlap目安含む） Chunking Strategies to Improve Your RAG Performance | Weaviate Learn how chunking strategies can help improve your RAG performance and explore different chunking methods. weaviate.io チャンキング戦略の全体像：代表6パターン（＋発展2） ここからは、チャンキング戦略の手法を整理します。 チャンキング戦略を選択する際は、いきなり高度な戦略に飛ぶのではなく、 固定長 or 再帰でベースラインを作る 回答の崩れ方（断片化／ノイズ／表崩れ） から原因を推定する 必要なところだけチャンキング戦略変更（構造認識／セマンティック／階層／コンテキスト付与） の順が、検証コストが小さくなるかと思います。 それぞれのチャンキング戦略の説明とLangChainでの実装コードについて簡単に説明します。 (1) 固定長（トークン）＋オーバーラップ 位置づけ ：最初に作るべき ベースライン 。チューニング（size/overlap）とログ観察がしやすく、改善サイクルの起点になります。 強み ：実装が簡単。速度・コスト見積もりがしやすい。比較実験（A/B）で差分を取りやすい。 弱み ：文の途中で切れたり、表・コード・章節構造を無視して分割しがち（＝構造がある文書では品質が低くなりやすい）。   LangChain最小実装 from langchain_text_splitters import CharacterTextSplitter splitter = CharacterTextSplitter.from_tiktoken_encoder( chunk_sise=512, chunk_overlap=128, separator="", keep_separator=False, ) chunks = splitter.split_text(text) # text: str (2) 再帰的分割（段落→改行→空白…の優先順位） 仕組み ：自然な区切り（段落・改行）を優先しつつ上限サイズに収める。 強み ：固定長より「読みやすいチャンク」になりやすく、検索が安定しやすい。 弱み ：表やコードなど“構造を持つデータ”では崩れることがある（前処理が重要）。 向く文書 ：議事録、ブログ、一般ドキュメント、自然言語中心の資料。   LangChain最小実装 from langchain_text_splitters import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter(chunk_sise=1200, chunk_overlap=100) chunks = splitter.split_text(text) # 必要であれば、下記のように「優先する区切り」を明示する splitter = RecursiveCharacterTextSplitter( chunk_size=1200, chunk_overlap=100, separators=["\n\n", "\n", "。", " ", ""] ) chunks = splitter.split_text(text) (3) 構造認識（見出し・表・リスト・レイアウト） 仕組み ：見出し階層、箇条書き、表、HTMLタグ、PDFレイアウト等を解析して「論理単位」で分割。 強み ：仕様書やPDFで起こりがちな「表崩れ」「章節の断絶」を抑えやすい。メタデータ（章タイトルなど）も付けやすい。 弱み ：前処理（パース）の品質がボトルネック。導入コストも上がりやすい。 向く文書 ：Markdown/HTML/PDF/Office文書（特に表が多い資料）。   LangChain最小実装 「構造認識」は入力形式で実装が分かれます。 ここでは、 HTML / Markdownの見出しをメタデータ化して分割 する例を示します。 HTML（タグ単位で分割） from langchain_text_splitters import HTMLHeaderTextSplitter headers_to_split_on = [ ("h1", "Header 1"), ("h2", "Header 2"), ("h3", "Header 3") ] splitter = HTMLHeaderTextSplitter(headers_to_split_on) docs = splitter.split_text(html_text) # html_text: str   Markdown（見出しで分割） from langchain_text_splitters import MarkdownHeaderTextSplitter headers_to_split_on = [ ("#", "Header 1"), ("##", "Header 2"), ("###", "Header 3") ] splitter = MarkdownHeaderTextSplitter(headers_to_split_on=[("#","h1"), ("##","h2"), ("###","h3")]) docs = splitter.split_text(markdown_text) (4) セマンティック分割（意味の変わり目で切る） 仕組み ：隣接文の埋め込み類似度が落ちる地点をbreakpointとして分割。 強み ：トピック境界を捉えやすく、長文・論文で“概念の連続性”を保ちやすい。 弱み ：前処理コストが増える。閾値（どこで切るか）のチューニングが必要。 向く文書 ：長文記事、論文、説明書（話題が頻繁に切り替わる資料）。   LangChain最小実装 ここでは、埋め込み類似度でbreakpointを打つことでセマンティック分割を実装する例を示します。 import numpy as np from langchain_google_vertexai import VertexAIEmbeddings emb = VertexAIEmbeddings(model_name="gemini-embedding-001") sents = text.split("。") # 例：粗めの文分割（実際はもっと丁寧に分割） vecs = np.array(emb.embed_documents(sents)) sim = (vecs[:-1] * vecs[1:]).sum(axis=1) / (np.linalg.norm(vecs[:-1],axis=1)*np.linalg.norm(vecs[1:],axis=1)) breaks = np.where(sim < 0.75)[0] # 閾値は要調整 # breaks を境界にチャンクを組み立てる（ここは数行では割愛） 上記の例では、「VertexAIEmbeddings」を利用しています。 しかし、LangChainの公式ドキュメントを確認すると、「VertexAIEmbeddings」は 非推奨（将来リリースで削除） となっています。 VertexAIEmbeddings - Docs by LangChain docs.langchain.com                    公式ドキュメントに記載のとおり、「GoogleGenerativeAIEmbeddings」で代替してください。 https://docs.langchain.com/oss/python/integrations/text_embedding/google_generative_ai (5) 階層（Hierarchical） 仕組み ：検索は小チャンクで行い、生成の際は親チャンク（より大きい文脈）を渡す。 強み ：条件・例外・前提などの“背景”が回答に乗りやすく、断片化に強い。 弱み ：親サイズを大きくしすぎるとコスト増。親子の設計（サイズ比・親サイズの選び方）が要点。 向く文書 ：規約・設計書・仕様書・研究資料（参照関係が強い資料）。   LangChain最小実装 「子で検索し、親を渡す」までの一連の流れを最小構成で示します。 from langchain.retrievers import ParentDocumentRetriever from langchain.storage import InMemoryStore from langchain_text_splitters import RecursiveCharacterTextSplitter child = RecursiveCharacterTextSplitter(chunk_size=400, chunk_overlap=50) # 子: 小さい単位 parent = RecursiveCharacterTextSplitter(chunk_size=1500, chunk_overlap=100) # 親: 大きい単位 store = InMemoryStore() retriever = ParentDocumentRetriever( vectorstore=vs, docstore=store, child_splitter=child, parent_splitter=parent ) retriever.add_documents(docs) # docs: List[Document]   (6) メタデータ駆動（フィルタ/分割/並べ替え） 仕組み ：章節、日付、システム名、部品名などのメタデータを付け、検索時にフィルタや優先順位付けに活用する。 強み ：専門用語が多い領域で、誤ヒットやノイズを抑えやすい。運用の“説明責任”にも効く。 弱み ：付与設計が雑だと逆効果（フィルタが効かない、メタデータが不整合など）。 向く文書 ：社内ドキュメント全般（AP基盤ドキュメントは特に相性が良い）。   LangChain最小実装 分割自体は再帰的分割・構造認識を利用し、 metadataを付けて検索時にフィルタ するのがポイントです（これはVectorStore側の機能に依存します）。 from langchain_core.documents import Document docs = [ Document(page_content="...", metadata={"system":"AP基盤", "version":"v1"}), Document(page_content="...", metadata={"system":"AP基盤", "version":"v2"}), ] vectorstore.add_documents(docs) retriever = vectorstore.as_retriever(search_kwargs={"k": 5, "filter": {"system": "AP基盤"}}) hits = retriever.invoke("デフォルト設定値は？") 上記では、 filter= でフィルタリングを行っています。このフィルタリングが効くかどうかはVectorStore実装依存です。 （例： Pinecone / Weaviate 等は強い、FAISSは弱い） [発展] コンテキスト付与（チャンクに“位置づけ説明”を足す） チャンク単体では主語や前提が抜けがちな場合、チャンクに短い説明（文書内での位置づけ）を付与してから埋め込む、という発展的アプローチがあります。主に「指示代名詞が多い」「前提が多い」文書で効きますが、索引コストは増えます。   LangChain最小実装 チャンク本文に短い前置き（タイトル / 章 /目的など）をつけて埋め込む例を示します。 from langchain_core.documents import Document enriched = [] for d in docs: # docs: Document[] prefix = f"[{d.metadata.get('h2','')}/{d.metadata.get('h3','')}] " enriched.append(Document(page_content=prefix + d.page_content, metadata=d.metadata)) vectorstore.add_documents(enriched) [発展] Late Chunking（先に文書全体でエンコード→後で分割） 通常は「chunk→embed」ですが、先に文書全体を通して文脈を持たせたベクトル表現を得てから分割する、という発展的な考え方です。文書全体の文脈が効く一方、適用条件やコスト面の検討が必要です。 参考 ・LangChain：Text Splitters（概念と実装） LangChain overview - Docs by LangChain LangChain is an open source framework with a pre-built agent architecture and integrations for any model or tool — so yo... python.langchain.com ・Google Cloud：layout parser統合（構造認識の入口として有用） Use Document AI layout parser with Vertex AI RAG Engine  |  Generative AI on Vertex AI  |  Google Cloud Documentation cloud.google.com ・Pinecone：semantic/contextual chunking を含む戦略整理 Chunking Strategies for LLM Applications | Pinecone In the context of building LLM-related applications, chunking is the process of breaking down large pieces of text into ... www.pinecone.io ・Weaviate：chunking戦略（＋発展手法）整理 Chunking Strategies to Improve Your RAG Performance | Weaviate Learn how chunking strategies can help improve your RAG performance and explore different chunking methods. weaviate.io ・IBM watsonx：LangChain互換Chunker/隣接チャンク拡張（window search） RAG - IBM watsonx.ai ibm.github.io 戦略別比較表：精度・コスト・実装難度のトレードオフ 各戦略は万能ではありません。 精度（Precision）／ノイズ耐性 ／ 実装難度 ／ コスト ／ レイテンシ のトレードオフを確認し、どの戦略を利用するかを判断する必要があります。 下記表に各チャンキング戦略の特徴をまとめています。 表. チャンキング戦略比較 戦略 精度 ノイズ耐性 実装難度 コスト レイテンシ 固定長 + overlap 低〜中 低 低 低 低 再帰的分割 中 中 低 低 低 構造認識 中〜高 高 中 中 中 セマンティック 高 高 高 高 高 階層（small-to-big） 中〜高 中 中 中 中 コンテキスト付与/発展 中〜高 高 中〜高 中〜高 中〜高   この表は「どれが最強か」を決めるものではありません。各チャンキング戦略に得意な文章構造などがあるため、事前にその内容を加味して選択する必要があります。また、最初に選んだ戦略であまり精度が出なかった場合は、他のチャンキング戦略を採用してみるなどの トライ&エラー も必要になります。 チャンキング戦略　選び方 一度採用した戦略で思うような精度が出ない場合は 「回答パターン」 を確認するとよいです。 回答パターンとその原因・対策の一例を示します。下記が正解ではありませんが、参考にしていただければと思います。 表. 回答パターンの原因とその対策 回答の崩れ方（よくあるパターン） ありがちな原因 優先して試す対策 回答が断片的（例外条件が落ちる） サイズ小さすぎ / overlap不足 overlap増 / 階層（small-to-big） 関係ない文が混ざる（ノイズ多い） サイズ大きすぎ / 前処理不足 サイズ削減 / 構造認識 / メタデータフィルタ 表の数値が崩れる PDF/表のパース崩れ 構造認識（layout parser等）/ 取り込み前処理の改善 同じ用語でも別文書がヒットする メタデータ不足 / フィルタ無し メタデータ付与（システム/部品/版数）+ フィルタ 検索は当たるのに主語が不明 参照が多い / 文脈が抜ける overlap増 / コンテキスト付与 検証デモ：LangChain + Vertex AI ここからはデモパートです。今回は「チャンキング戦略によって、検索で拾える根拠がどう変わるか」を、LangChainでサクッと比較できる形にします。 なお、本デモの内容をもう少し詳しくした内容についてはGitHubで公開しているので、ぜひ確認してみてください。 GitHub - HiaHia1969/chunking_demo_public Contribute to HiaHia1969/chunking_demo_public development by creating an account on GitHub. github.com 構成 ：TextSplitter（戦略） → Embeddings（Vertex AI） → VectorStore（ローカル） → Retriever → 取得チャンクの比較 前提：環境構築 今回は uv を利用して環境構築を行います。 # 作業ディレクトリ準備 mkdir langchain_demo && cd langchain_demo # uv初期化 uv init # ライブラリ準備 uv add langchain \ langchain-community \ langchain-text-splitters \ langchain-google-genai \ faiss-cpu \ python-dotenv \ numpy \ tiktoken # GitHubリポジトリを参考にする場合は、下記コマンドで依存関係を解決できます。 uv sync 図 ディレクトリ構造 図 pyproject.tomlの内容 環境変数 .env ファイルにVertexAI経由でGoogleモデルを呼び出すための設定を行います。 APIキーは事前に発行しておく必要があります。 GOOGLE_API_KEY=<取得したAPIキー> GOOGLE_CLOUD_PROJECT=<Google Cloudのプロジェクト名> GOOGLE_CLOUD_LOCATION=<リージョン名> GOOGLE_GENAI_USE_VERTEXAI=true EMBEDDING_MODEL=gemini-embedding-001 図 環境変数の設定   共通：ベクトル化と検索のユーティリティ import os from dataclasses import dataclass from typing import List, Tuple from dotenv import load_dotenv from langchain_google_genai import GoogleGenerativeAIEmbeddings from langchain_community.vectorstores import FAISS # LangChain splitters from langchain_text_splitters import RecursiveCharacterTextSplitter # 環境変数の読み込み load_dotenv() @dataclass class SearchResult: label: str docs: List[str] def build_vs(chunks: List[str], embeddings: GoogleGenerativeAIEmbeddings) -> FAISS: """Build a local FAISS vector store from plain text chunks.""" return FAISS.from_texts(chunks, embedding=embeddings) def topk_texts(vs: FAISS, query: str, k: int = 3) -> List[str]: docs = vs.similarity_search(query, k=k) return [d.page_content for d in docs] def show(title: str, texts: List[str]) -> None: print(f"\n===== {title} =====") for i, t in enumerate(texts, 1): print(f"\n--- top{i} ---\n{t}") # Embeddings（Google Generative AI） # 本記事では、gemini-embedding-001を利用します。利用できるモデルは下記を確認してください embeddings = GoogleGenerativeAIEmbeddings( model=os.getenv("EMBEDDING_MODEL", "gemini-embedding-001"), api_key=os.getenv("GOOGLE_API_KEY"), project=os.getenv("GOOGLE_CLOUD_PROJECT"), location=os.getenv("GOOGLE_CLOUD_LOCATION"), vertexai=os.getenv("GOOGLE_GENAI_USE_VERTEXAI", "true").lower() == "true", ) デモ1：overlapの有無で「例外条件が落ちる」を再現 対応ソース ： demos/demo1_overlap_effect.py 目的：単発ケースだけでなく複数ケースでも、overlap が Top1 の根拠取得に与える影響を確認します。 このデモで確認すること 目的 ：境界分断が起きたとき、overlap が Top1 の根拠欠落をどこまで緩和できるかを確認する 設定 ： chunk_size=120 、 overlap=0 と overlap=20 、検索は k=1 （Top1）で比較 期待される差分 ：overlap ありの方が「基本 + 例外」が同一チャンクに残りやすく、Top1 欠落が減る 読み方 ：`判定` 行と `Top1で基本+例外を同時取得できた件数`（再現率）を見る from langchain_text_splitters import RecursiveCharacterTextSplitter # 共通ユーティリティ（build_vs / topk_texts / show）と embeddings は前節を利用 def make_doc(noise_repeat: int) -> str: return ( "背景説明。" * noise_repeat + "A部品の設定方針は次の通り。基本はX=ONとする。" + "ただしBモード時のみ例外でX=OFFとする。" ) query = "A部品の設定方針を教えてください。基本設定(X=ON)と例外設定(X=OFF)を両方含めてください。" # チャンク化：境界でX=ONが分断される設定 chunk_size = 120 overlap0 = 0 overlap1 = 20 split0 = RecursiveCharacterTextSplitter(chunk_size=chunk_size, chunk_overlap=overlap0) split1 = RecursiveCharacterTextSplitter(chunk_size=chunk_size, chunk_overlap=overlap1) # 代表ケース（noise_repeat=20） doc = make_doc(20) chunks0 = split0.split_text(doc) chunks1 = split1.split_text(doc) show("overlap=0（境界で例外が落ちやすい）", topk_texts(build_vs(chunks0, embeddings), query, k=1)) show("overlap=20（例外が同居しやすい）", topk_texts(build_vs(chunks1, embeddings), query, k=1)) # 複数ケース for r in [16, 18, 20, 22, 24]: d = make_doc(r) c0 = split0.split_text(d) c1 = split1.split_text(d) t0 = topk_texts(build_vs(c0, embeddings), query, k=1) t1 = topk_texts(build_vs(c1, embeddings), query, k=1) ok0 = any("X=ON" in t and "X=OFF" in t for t in t0) ok1 = any("X=ON" in t and "X=OFF" in t for t in t1) print(f"noise_repeat={r}: overlap=0 -> {'○' if ok0 else '×'}, overlap=20 -> {'○' if ok1 else '×'}") 実行結果 実行コマンド 出力結果（要約） [設定] chunk_size=120 【代表ケース】noise_repeat=20 overlap=0 : 判定 × 例外設定(X=OFF)が欠落 overlap=20 : 判定 ○ 基本設定と例外設定の両方が含まれる 【追加検証】複数ケースでの再現率（Top1） noise_repeat=16: overlap=0 -> ×, overlap=20 -> × noise_repeat=18: overlap=0 -> ×, overlap=20 -> × noise_repeat=20: overlap=0 -> ×, overlap=20 -> ○ noise_repeat=22: overlap=0 -> ○, overlap=20 -> ○ noise_repeat=24: overlap=0 -> ○, overlap=20 -> ○ Top1で基本+例外を同時取得できた件数 overlap=0: 2/5 overlap=20: 3/5 考察 代表ケースでは overlap=0 で取りこぼし、overlap=20 で回収できることを再現しました。 複数ケースでも overlap=20 の方が Top1 で根拠が揃う件数が多く（3/5 vs 2/5）、改善傾向を確認できました。 差分は境界位置に依存するため、実務では overlap 単体ではなく chunk_size と k を合わせて調整するのが妥当です。 今回のミニデモでは差分は限定的ですが、実務プロジェクトの長文・多条件文書では境界分断が増えるため、overlapの効き目は一般に大きくなります。 観察ポイント overlapは常に効く魔法ではなく、境界依存の問題を緩和する手段 Top1運用では、境界情報を残す保険として有効に働きやすい デモ2：固定長（token） vs 再帰分割で「読みやすいチャンク」を比較 対応ソース ： demos/demo2_token_vs_recursive.py 目的：固定長だと文がブツ切れになり、人間が読んでも意味が取りづらい（＝LLMにも厳しい）ことを示します。 ※token側は日本語で文字化けしにくい `token_splitter()` を使います。langchaignの「CharacterTextSplitter」を利用しています。 今回のデモを作成するにあたり、当初は「TokenTextSplitter」を利用していました。 しかし、日本語のチャンキング時にチャンク文字列が文字化けしてしまうという事象が発生していました。 下記のような感じです。         ...制御する� �計判断です。 どうやら「TokenTextSplitter」では、日本語などのマルチバイト文字を含む文字列を分割すると、分割後に文字化けが発生する可能性があるようです。 そのため、今回は「TokenTextSplitter」ではなく、「CharacterTextSplitter」を採用しています。 langchain公式ドキュメント Text splitter integrations - Docs by LangChain Integrate with text splitters using LangChain. docs.langchain.com   このデモで確認すること 目的 ：固定長分割と再帰分割で、チャンクの可読性と意味まとまりがどう変わるかを比較する 設定 ：Token側は chunk_size=25 、Recursive側は chunk_size=120 、どちらも overlap=0 期待される差分 ：Token分割は文途中で切れやすく、Recursive分割は自然な文境界を保ちやすい 読み方 ：Token側の `[NG] 文の途中で切断` と、Recursive側の `[OK] 自然な区切り` を比較する from langchain_text_splitters import RecursiveCharacterTextSplitter from src.splitters import token_splitter text = """ RAGのチャンキングは単なる分割ではありません。 検索精度と文脈保持、さらにコストとレイテンシのトレードオフを制御する設計判断です。 例えば、条件・例外・参照が多い仕様書では、文脈の断片化が致命的になります。 """ token_split = token_splitter(chunk_size=25, chunk_overlap=0) rec_split = RecursiveCharacterTextSplitter(chunk_size=120, chunk_overlap=0) token_chunks = token_split.split_text(text) rec_chunks = rec_split.split_text(text) print("\n===== token split（固定長のイメージ） =====") for c in token_chunks: print("-", c) print("\n===== recursive split（自然なまとまり） =====") for c in rec_chunks: print("-", c) 実行結果 実行コマンド 出力結果（要約） 【パターン1】Token分割 (chunk_size=25トークン) 結果: 7個のチャンクに分割 例: - 『RAGのチャンキングは単なる分割ではありま』 - 『せん。検索精度と文脈保』 【パターン2】Recursive分割 (chunk_size=120文字) 結果: 1個のチャンクに分割 例: - 『RAGのチャンキングは単なる分割ではありません。...（全文）』 考察 Token分割は長さ制御には強い一方、文の途中切断が連続し、意味まとまりが崩れやすいことが確認できました。 Recursive分割は今回のテキストでは1チャンクに収まり、文脈の一貫性を保持できています。 日本語では「文字化けしないtoken分割」を使っても、 文脈保持の観点ではRecursive優位 になりやすい、という位置づけが妥当です。 デモ3：構造認識（レイアウト解析）に寄せると何が嬉しいか 対応ソース ： demos/demo3_semantic_breakpoints.py 目的：構造なしの分割と、見出し構造を使った分割で、チャンクの意味的まとまりがどう変わるかを比較します。 このデモで確認すること 目的 ：平文分割と見出し分割で、トピック完結性と検索向けメタデータの有無を比較する 設定 ：平文は RecursiveCharacterTextSplitter 、構造ありは MarkdownHeaderTextSplitter （Header 1〜3） 期待される差分 ：見出し分割の方が章単位でまとまり、Headerメタデータが付与される 読み方 ：`メタデータ` 行と、平文側の「トピック混在」有無を確認する from src.splitters import markdown_header_splitter, recursive_splitter plain_doc = """ システム設定ガイド A部品の設定 基本設定 A部品の設定方針は次の通りです。 基本は「X=ON」とする。 例外設定 ただし、Bモードの場合は例外で、X=OFFとする。 """ markdown_doc = """ # システム設定ガイド ## 1. A部品の設定 ### 基本設定 A部品の設定方針は次の通りです。 基本は「X=ON」とする。 ### 例外設定 ただし、Bモードの場合は例外で、X=OFFとする。 """ # パターン1: 構造なし（Recursive） plain_chunks = recursive_splitter(chunk_size=100, chunk_overlap=0).split_text(plain_doc) # パターン2: 構造認識（Markdown Header） headers_to_split_on = [("#", "Header 1"), ("##", "Header 2"), ("###", "Header 3")] md_docs = markdown_header_splitter(headers_to_split_on).split_text(markdown_doc) print("plain chunks:", len(plain_chunks)) print("markdown header chunks:", len(md_docs)) for d in md_docs: print(d.metadata, d.page_content[:40]) 実行結果 実行コマンド 出力結果（要約） 【パターン1】構造なし（Recursive） 結果: 3個のチャンク - Chunk 2 に「例外設定」と「認証設定」が同居し、トピックが混在 【パターン2】Markdown Header分割 結果: 4個のチャンク（見出し単位） - Chunk 1 metadata: {'Header 1': 'システム設定ガイド', 'Header 2': '1. A部品の設定', 'Header 3': '基本設定'} - Chunk 2 metadata: {'Header 1': 'システム設定ガイド', 'Header 2': '1. A部品の設定', 'Header 3': '例外設定'} 考察 構造なし分割では「見出しだけ残る」「異なる章が同居する」状態が発生し、検索時の解釈が不安定になります。 見出し分割ではチャンク境界が文書構造と一致し、 トピック完結性とメタデータ活用性 が大きく向上します。 仕様書・手順書・運用ドキュメントのような構造化文書では、まずHeader分割を優先するのが実践的です。 観察ポイント 構造なし分割では、見出しと本文が混在しやすく、トピックが分散しやすい 見出し分割では、Headerメタデータ付きでトピック単位にまとまりやすい 参考 ・LangChain：Text Splitters（概念と実装） LangChain overview - Docs by LangChain LangChain is an open source framework with a pre-built agent architecture and integrations for any model or tool — so yo... python.langchain.com ・LangChain：Vertex AI embeddings integration Google Vertex AI integration - Docs by LangChain Integrate with the Google Vertex AI embedding model using LangChain Python. python.langchain.com ・Google Cloud：layout parser統合（構造認識の入口として有用） Use Document AI layout parser with Vertex AI RAG Engine  |  Generative AI on Vertex AI  |  Google Cloud Documentation cloud.google.com 評価（次回記事）：チャンキング改善はどう測る？ チャンキングは“それっぽく”改善できてしまう一方で、主観評価に寄ると迷走しがちです。最低限、次の指標で定量的に「良くなった／悪くなった」を測れる状態にしておくのが安全です（詳細は次回で扱います）。 Context Recall ：正解に必要な根拠がTop-kに入っているか Context Precision ：Top-kがノイズだらけになっていないか Faithfulness ：回答が取得した根拠に接地しているか Answer Relevancy ：質問にちゃんと答えているか おすすめの評価・改善ループは、 代表クエリ50件（ファクト系/分析系/手順系を混ぜる） ベースライン（固定長+overlap or 再帰）でTop-kログを保存 1つだけ条件を変えて比較（サイズだけ、overlapだけ、構造認識だけ…） です。これで“改善の方向性”が掴めます。 （補足）Amazon Bedrock Knowledge Basesで考える場合 シリーズ2以降で本格的に検証予定ですが、「マネージドサービスで楽をしたい」場合の整理も置いておきます。 AWSでは、Amazon Bedrock Knowledge Basesというマネージドサービスが提供されており、RAG環境を簡単に構築することが可能です。2026年2月時点で利用できるAmazon Bedrock Knowledge Bases（Bedrock KB）で利用できるチャンキング戦略は下記となります。 これまで説明してきたチャンキング戦略と対応付けると、ざっくり次のイメージです（詳細はTipsシリーズで検証します）。 表. Amazon Bedrock Knowledge Bases で利用可能なチャンキング戦略 Bedrock KB 一般戦略の読み替え 一言 Default ベースライン 迷ったらまずこれ Fixed-size 固定長 + overlap 速度・コスト優先 Hierarchical 階層（Hierarchical） 複雑文脈向け Semantic セマンティック 高精度寄り（コスト増に注意） None 分割なし 前処理済み/FAQ向け まとめ 本記事では、RAGにおけるチャンキング戦略について説明してきました。 まずは固定長 + overlap／再帰分割でベースラインを作る 断片化・ノイズ・表崩れなど、 回答がどう崩れているか から原因を推定し、必要なところだけ高度化する デモのように、取得チャンクを比較して「どこが壊れているか」を観察する 改善は評価指標（Recall/Precision/Faithfulness等）で“定量的に測れる状態”にして進める 次回は、この改善が本当に効いているかを判断するために、 RAGの評価（定量評価） を扱います。Ragasなどの評価指標で「良くなった／悪くなった」を測れる状態にしていきましょう。 次回もぜひご覧ください。 「その質問、ドキュメントに書いてある」問題を終わらせたい：RAG連載を始めます 社内ナレッジをRAGで活用し、膨大なドキュメントから必要情報を素早く見つける仕組みを目指します。本記事では連載開始の背景と、RAG基礎〜Bedrock実装・アプリ/エージェント構築までの構成を紹介します。 blog.usize-tech.com 2026.01.27 （シリーズ1：RAGの基本情報 / 第1回）RAGとは：全体像、なぜ必要か、基本フローと設計の勘所 RAG（検索拡張生成）の定義、なぜ必要か、基本フロー（Indexing/検索/補強/生成）を整理します。 blog.usize-tech.com 2026.01.27

こんにちは、広野です。 最近 Amazon API Gateway REST API を検証用途で作成する機会があり、検証用とは言え認証なしで公開するのは嫌だなぁ、、、ということで、API キーを使用したものを AWS CloudFormation でデプロイしました。普段 Amazon Cognito 認証とのセットで作成しているので、REST API を単体で作成する機会がなく、今さら？になりました。 Amazon API Gateway はときどき細かいアップデートが入っているみたいで、以前よりもオプションが増えていて、テンプレート作成に少々調査が必要だったのでそれについてもここに残しておきます。   AWS マネジメントコンソール上の設定 Amazon API Gateway の API キーを作成すると、以下のようになります。 使用量プラン、API、ステージとの関連付けがあります。使用量プランを定義しないといけないわけですね。 あと、この API キーをどこか (例えば Secrets Manager とか) に自動保存できないかな、と思ったのですが、AWS CloudFormation の出力に出せない情報だったので、あきらめました。リソース作成後は、この画面で API キーを確認しています。 次に Amazon API Gateway REST API の設定画面です。 アプリから API キーを X-Api-Key ヘッダーに入れて送る場合は、API キーのソースを「Header」にします。デフォルトでそうなっています。 それ以外に、「新規」と書いてある設定がありました。 セキュリティポリシーで、使用する TLS バージョン (というか API がサポートする暗号化アルゴリズム) を選択できるようです。ALB を使ったことがある人なら、想像しやすいと思います。ところが AWS 公式ドキュメントに書いてあるオプションと画面のオプションがだいぶ異なっていたので、はてどう記述したらよいのだろう？と悩みましたが AWS マネジメントコンソールで表示されるままに書いてみたら通りました。 セキュリティポリシーを明示的に定義する場合には、エンドポイントアクセスモードも定義する必要があるようです。ここも AWS CloudFormation テンプレートの公式ドキュメントに記述方法が載っておらず悩みましたが、オプションが 2つしかないようでして、BASIC を書いてみたら通りました。 これまで AWS CloudFormation テンプレートを書きすぎて、どう書けば通るのか勘が利くようになってきましたね。笑   AWS CloudFormation テンプレート AWS Lambda 関数との統合付きテンプレートにしていますが、Lambda 関数コードは省略しています。ARN を入れる箇所だけそのように明記しておきます。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates an API Gateway REST API with an API key. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SystemName: Type: String Description: System name. use lower case only. (e.g. example) Default: example MaxLength: 10 MinLength: 1 AllowedPattern: "^[a-z0-9]+$" SubName: Type: String Description: System sub name. use lower case only. (e.g. prod or dev) Default: dev MaxLength: 10 MinLength: 1 AllowedPattern: "^[a-z0-9]+$" Metadata: AWS::CloudFormation::Interface: ParameterGroups: - Label: default: "General Configuration" Parameters: - SystemName - SubName Resources: # ------------------------------------------------------------# # API Gateway REST API # ------------------------------------------------------------# RestApi: Type: AWS::ApiGateway::RestApi Properties: Name: !Sub restapi-${SystemName}-${SubName} Description: !Sub REST API to call Lambda-${SystemName}-${SubName} ApiKeySourceType: HEADER EndpointAccessMode: BASIC EndpointConfiguration: Types: - REGIONAL IpAddressType: dualstack SecurityPolicy: SecurityPolicy_TLS13_1_2_2021_06 Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} RestApiDeployment: Type: AWS::ApiGateway::Deployment Properties: RestApiId: !Ref RestApi DependsOn: - RestApiMethodPost - RestApiMethodOptions RestApiStage: Type: AWS::ApiGateway::Stage Properties: StageName: prod Description: production stage RestApiId: !Ref RestApi DeploymentId: !Ref RestApiDeployment MethodSettings: - ResourcePath: "/*" HttpMethod: "*" LoggingLevel: INFO DataTraceEnabled : true TracingEnabled: false Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} RestApiKey: Type: AWS::ApiGateway::ApiKey Properties: Description: !Sub API Key for ${SystemName}-${SubName} Enabled: true Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} RestApiUsagePlan: Type: AWS::ApiGateway::UsagePlan Properties: UsagePlanName: !Sub usage-plan-${SystemName}-${SubName} ApiStages: - ApiId: !Ref RestApi Stage: !Ref RestApiStage Throttle: RateLimit: 100 BurstLimit: 200 RestApiUsagePlanKey: Type: AWS::ApiGateway::UsagePlanKey Properties: KeyId: !Ref RestApiKey KeyType: API_KEY UsagePlanId: !Ref RestApiUsagePlan RestApiResource: Type: AWS::ApiGateway::Resource Properties: RestApiId: !Ref RestApi ParentId: !GetAtt RestApi.RootResourceId PathPart: post RestApiMethodPost: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApi ResourceId: !Ref RestApiResource HttpMethod: POST AuthorizationType: NONE ApiKeyRequired: true Integration: Type: AWS_PROXY IntegrationHttpMethod: POST Credentials: !GetAtt ApigLambdaInvocationRole.Arn # 以下に Lambda 関数の ARN を入れる箇所がある Uri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/Lambda関数のARN/invocations" DependsOn: - ApigLambdaInvocationRole RestApiMethodOptions: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApi ResourceId: !Ref RestApiResource HttpMethod: OPTIONS AuthorizationType: NONE Integration: Type: MOCK Credentials: !GetAtt ApigLambdaInvocationRole.Arn IntegrationResponses: - ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Api-Key'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" ResponseTemplates: application/json: '' StatusCode: '200' PassthroughBehavior: WHEN_NO_MATCH RequestTemplates: application/json: '{"statusCode": 200}' MethodResponses: - ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true method.response.header.Access-Control-Allow-Origin: true StatusCode: '200' # ------------------------------------------------------------# # API Gateway Lambda Invocation Role (IAM) # ------------------------------------------------------------# ApigLambdaInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigLambdaInvocationRole-${SystemName}-${SubName} Description: This role allows API Gateway to invoke specific Lambda functions. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / Policies: - PolicyName: !Sub ApigLambdaInvocationPolicy-${SystemName}-${SubName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - lambda:InvokeFunction Resource: # ここに Lambda 関数の ARN を入れる # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: # API Gateway APIGatewayEndpoint: Value: !Sub https://${RestApi}.execute-api.${AWS::Region}.${AWS::URLSuffix}/${RestApiStage}/post   まとめ いかがでしたでしょうか？ 本記事が、お困りの方の検索に引っかかってお役に立てれば幸いです。

こんにちは。SCSKの太田です。   TechHarmonyは初投稿ですので、つたない部分はご容赦ください。 本記事では Azure でのランサムウェア対策 について最近プレビューとなった機能を紹介と思います。 概要 2025年11月に Microsoft Defender for Cloud 統合を使用した Azure Backup での脅威検出 の機能がプレビューとなりました。 ■何ができるのか？？ →VM バックアップに対して、ランサムウェア感染の可能性を検出し、復元ポイントの正常性を評価できるようになった。 手順 ■前提条件 ・サブスクリプションで Microsoft Defender for Servers プラン 1 or 2 を有効にする ・仮想マシンで Microsoft Defender for Endpoint (MDE) を有効にする ・Microsoft Sentinel で双方向アラート同期を有効にして、バックアップ復旧ポイントを識別する   ■手順1 ・回復性を使用して脅威検出を構成する   ■手順2 ・ RecoveryServiceコンテナーのプロパティからの脅威検出を構成する ■手順 3 ・回復ポイントの一覧から、[最近のスキャン状態] が[疑わしい (Suspicious)]になっているものがあるか確認する   ■手順 4 ・[疑わしい (Suspicious)]になっている原因となったアラートを確認する まとめ ■まとめ Azure VM バックアップで、マルウェアのスキャンや正常性評価ができるようになりました。 ※2026/1現在、まだプレビュー中です。   ■ポイント 🔍プロアクティブな脅威識別 バックアップ復元ポイントに潜むランサムウェアやマルウェア感染の可能性を自動検出。 攻撃中でも安全な復元ポイントを識別でき、復旧の信頼性を向上可能。 ⚡ 迅速な復旧 安全な復元ポイントを迅速に特定できるため、復旧にかかる時間を短縮できる。 🔗 統合されたセキュリティ管理 Microsoft Defender for Servers と連携し、Azure ワークロード全体で統一されたセキュリティ エクスペリエンスを提供。 📊 可視性の向上 Azure Portal 上で 脅威検出の構成状態と概要を監視可能。 「脅威なし」「疑わしい」「不明」などのステータスで直感的に把握。   参考 Microsoft Defender for Cloud 統合を使用した Azure Backup での脅威検出について – Azure Backup | Microsoft Learn チュートリアル – 脅威検出を構成し、 Azure VM バックアップの正常性を管理する – Azure Backup | Microsoft Learn

こんにちは！SCSK江嶋です。 本記事では、Azureのサービスを用いたRAGの構築方法について説明します。 そもそもRAGとは？ AzureでRAGを構築する際、どのサービスをどう使えばいい？ Azure AI Search、Azure OpenAIって聞いたことあるけど何者？ 上記のような疑問を持っている 入門者 向けに記事を書きます。少しでも参考になると幸いです！   RAG(Retrieval Augmented Generation)とは RAGの概要 RAG（Retrieval Augmented Generation：検索拡張生成）は、LLM（大規模言語モデル）の回答生成に、 社内文書やナレッジベースなど「外部データの検索結果」を組み合わせて回答精度を高める アプローチです。 LLMは非常に強力ですが、基本的には「学習時点までの知識」と「入力されたプロンプト」に依存して回答します。そのため、次のような課題が起こりがちです。 社内規程や設計書など、 モデルが学習していない最新情報 には弱い もっともらしく見えるが誤っている回答（いわゆる ハルシネーション ）が混ざる 「その回答の根拠はどこ？」という 出典提示が難しい 下図にRAGのありなしの比較図を掲載します。 RAGは、これらの弱点を補うために、 質問に関連する文書を先に探し（Retrieval）、その内容を材料として回答を作る（Generation）という流れを取ります。図でいうと 「RAGなし」 ではユーザーの質問がそのままLLMに渡るのに対し、 「RAGあり」 では検索→関連情報の抽出→LLM という“参照プロセス”が挟まります。結果として、LLMは見つけた根拠をもとに答える形になります。 Azureでどう実現する？ 本記事のテーマである Azure OpenAI × Azure AI Search は、RAG構成の王道パターンです。ざっくり役割分担は次の通りです。 Azure AI Search ：文書を索引化し、キーワード検索／ベクトル検索で関連情報を取得する Azure OpenAI（LLM） ：検索で得た根拠を使って自然な文章として回答を生成する この構成にすることで、LLM単体では難しい「 社内データに基づく回答 」を実現しやすくなります。 (参考) 学習（ファインチューニング）ではなくRAGを使う理由 「社内情報を覚えさせたいなら学習すればいいのでは？」と思うかもしれません。 しかし、RAGがよく選ばれるのは次の理由からです。 情報更新に強い ：文書を差し替えるだけで反映できる（再学習が不要） 根拠を提示しやすい ：どの文書を参照したか追跡できる 運用と統制がしやすい ：アクセス制御や監査ログなど、検索基盤側で管理しやすい 特に業務利用では「最新の規程に従う」「回答の根拠が説明できる」が重要になるため、RAGは現実的な選択肢になりやすいです。     Azure AI Searchとは Azure AI Searchの概要 Azure AI Searchは、Azure上で提供される フルマネージドの検索サービス です。 Azure AI Searchの役割を一言で言うと、 「検索できる形に文書を整えて、必要なときに素早く取り出す仕組み」 です。 文書を取り込み、 検索用のデータ構造（インデックス） を作る 検索クエリ に対して、関連度が高いデータを返す 検索結果に スコアリング や フィルタ 、 並び替え などを適用する RAGにおいては、ここで返ってきた検索結果（根拠）をプロンプトに含めて、Azure OpenAIが回答文を生成する流れになります。 構成要素 図に描かれている要素を、RAGの準備〜検索までの流れに沿って整理します。 (1) インデックス（Index） 検索対象の本体 です。 文書のテキストやメタデータを フィールド として定義し、検索に使う属性（検索対象・フィルタ可能・返却対象など）を設計します。 インデックス設計例： content （本文テキスト） title （タイトル） sourceUrl （参照元URL） category / updatedAt （絞り込み用メタデータ） contentVector （ベクトル検索用の埋め込み） RAGでは、 本文＋メタデータ＋ベクトル を持たせる設計が定番です。 (2) データソース（Data Source） インデックスに取り込みたい 元データの置き場所 です。 Blob Storage、SQL、Cosmos DB など、様々なストレージ／DB、様々なファイル形式を検索対象として扱えるのがポイントです。 (3) インデクサー（Indexer） データソースから文書を読み取り、インデックスに反映する 取り込みジョブで す。 定期実行により、 更新や追加をインデックスへ追従 させることもできます。 (4) スキルセット（Skillset） 取り込み時に、文書へ前処理（エンリッチメント）をかける仕組み です。 例として、PDFからのテキスト抽出、OCR、言語判定、キーフレーズ抽出などがあり、「検索しやすい形」に整えるときに使用します。 まとめると、 データソース →（インデクサー＋スキルセット）→ インデックス → アプリから検索 という流れになります。     Azure OpenAIとは Azure OpenAIの概要 Azure OpenAI は、OpenAIの大規模言語モデル（LLM）を Azure上のマネージドサービスとして利用できるサービス です。 チャット（対話）や文章要約、情報抽出、分類、コード生成などの生成AI機能を、 Azureの認証・ネットワーク・監査 といった企業利用向けの仕組みと合わせて扱えるのが特徴です。 RAGでは、Azure OpenAIは「 検索で集めた根拠（コンテキスト）を使って、自然な回答文を作る役 」を担当します。 前章の Azure AI Search が “探す” なら、Azure OpenAI は “答えを文章にする” 側 です。 RAGでよく使う機能 チャット／テキスト生成 RAGの 「最終回答」を生成する 中心機能です。 検索で取った根拠を本文に含め、根拠に基づいて回答するように指示して出力させます。 よくあるプロンプト方針： 根拠（コンテキスト）に含まれる内容のみで答える 根拠が不足している場合は「分からない」や「追加情報が必要」と返す 参照元URLや文書タイトルを引用として添える（根拠提示） Embeddings（埋め込み） 文章をベクトル化 する機能です。 RAGでは、文書や質問文をEmbeddingしてベクトル検索を行うケースが多いため、 検索の精度そのもの に影響します。 文書側：チャンク化したテキストをEmbeddingしてインデックスへ格納 質問側：質問文をEmbeddingし、近い文書チャンクを検索   リソースを作成してみよう 使用するサービスについてなんとなく理解できましたか？ここから実際にリソースを作成してみましょう！ データソースの作成 検索対象ファイルの準備 今回検索対象とする社内文書として架空の契約書を準備しました。このドキュメントをデータソースとして登録し、AI Searchにインデックスとして登録する流れです。この架空の書類の情報は当然LLMは知らないので、動作確認でこの書類の情報を参照して回答してくれたら成功というわけです。 Azureのstorageに格納 上記で用意したファイルをAzureのストレージに配置します。今回はBlobに格納します。 ストレージアカウントを作成した後、コンテナを作成し、下図のように対象ファイルをコンテナにアップロードします。 Azure OpenAIでモデルをデプロイする Azure OpenAIのリソースを作成し概要タブから「Foundryポータルの詳細」を押しFoundryポータルを開きます。 チャットタブからモデルを選択しデプロイする。 モデルカタログタブからembeddingモデルを選択しデプロイする。 Azure AI Searchでインデックスを作成する 次にインデックスを作成します。Azure AI Searchのリソースを作成したあと、概要タブから「データのインポート(新規)」を押します。 データソースを選択します。 シナリオはRAGを選択します。 データへの接続画面では、作成したストレージアカウントと対象コンテナを選択する。 テキストをベクトル化する画面では、デプロイしたEmbeddingモデルを選択する。 作成ボタンを押すとインデックス、インデクサー、スキルが自動生成されます。   動作確認してみよう ここまでで、インデックスの作成まで完了しました。ここからMicrosoft Foundryで動作確認をしてみましょう！   Foundryポータルを開き、デプロイしたチャットモデル画面に移動します。データソースの追加ボタンから 対象AI Searchのインデックスを選択すると、データソースとして紐づけができます。 ここまできたら、いよいよチャット画面で動作確認です。 LLMが知りえないデータソースとして追加した社内文書の内容を聞いてみると、データソースを参照した結果を含んでLLMが 回答を返してくれました！！   さいごに 本記事では、 Azure OpenAI と Azure AI Search を使ったRAGの基本構成 を、全体像から実装の入口まで一通り紹介しました。 LLM単体では難しい「社内文書や最新情報に基づく回答」を、 検索（Azure AI Search）で根拠を取得し、生成（Azure OpenAI）で文章化する ことで実現できるのがRAGの大きな強みです。 入門としては、まず 「検索で正しい根拠を取れること」 が最優先です。RAGの品質はLLMよりも、実は チャンク設計・メタデータ設計・検索方式（キーワード/ベクトル/ハイブリッド） の影響を強く受けます。うまく回答できない場合は、モデルやプロンプトをいじる前に、 AI Search側のインデックスと検索結果 を先に疑うのが近道です。 なお、今回は入門として “検索→根拠→生成” の最小構成 に絞って説明しましたが、実運用では要件に応じてさらに色々な拡張アプローチがあります。たとえば、検索前処理を高度化する カスタムスキル 、LLMの外部処理を組み込む Function Calling 、PDFや帳票から構造化情報を抽出する Azure AI Document Intelligence などを組み合わせることで、取り込み精度・検索精度・回答品質を段階的に引き上げられます。必要になったタイミングで、これらの選択肢も検討すると良いでしょう。 この記事が、RAGをAzureで始める際の最初の一歩になれば嬉しいです。 ここまでお付き合いいただきありがとうございました！！

はじめに：テレワークの運動不足を「技術」で解決する クラウドエンジニアの皆さん、運動していますか？ 私は毎日リモートワークで、気づけば一日中座りっぱなし……という日が珍しくありません。 「1時間おきに運動すればいい」と分かっていても、自分に甘いのが人間です。そこで思いました。 「サボったらLINEで怒られるシステムを作ればいいのでは？」 と。 しかし、私は普段インフラ設計がメインで、アプリケーションコード（Pythonなど）を書くのは正直苦手です。 そこで今回は、特別な開発ツールは一切使わず、 「Gemini」 と 「Google Cloud Shell」 だけを使って、 完全AI任せ での構築に挑戦しました。 ロジック（コード）: Gemini に書いてもらう インフラ（デプロイ）: Gemini にコマンドを作ってもらい、Cloud Shellに貼り付ける ローカル環境の構築すら不要。ブラウザだけで完結させた記録を共有します。 構想フェーズ：AIを「壁打ち相手」にして要件を固める いきなり作り始める前に、まずは Gemini とチャットをして「どんな構成にするか」を相談しました。 この 「要件定義の壁打ち」 が非常に実りある時間でした。 1. クラウド選定：AWS か Google Cloud か？ 普段業務で使っているのは AWS ですが、今回は個人開発です。 Gemini に相談したところ、 「個人の小規模アプリなら、Cloud Run (Functions Gen2) の無料枠が手厚い Google Cloud がおすすめ」 と提案されました。 また、私自身が最近 Google Cloud認定資格 (PCA: Professional Cloud Architect) を取得したばかりだったので、「得た知識を実際の構築で試してみたい」というモチベーションとも合致し、Google Cloudの採用即決となりました。 2. 入力デバイス：物理ボタン か スマホ か？ 当初は「IoTボタンのような物理デバイスを買おうか」とも悩みましたが、Gemini は 「手持ちの Apple Watch と iPhone のショートカット機能を使えば、追加ハードウェアなしで実現できる」 と提案してくれました。 実はこれ、私にとって渡りに船でした。 ちょうど Apple Watch を買ったばかり で、単なる時計や通知確認以外に「ガジェットとして面白い使い道はないか？」と探していたタイミングだったからです。 作ったもの：サーバーレス・スクワット監視 今回構築したシステムの全体像はこちらです。 処理の流れ Input: Apple Watchの「ショートカット」ボタンをタップ。 Process: Cloud Run functions がリクエストを受け、Firestoreに「スクワット実施ログ」を保存。 Monitoring: Cloud Schedulerが平日9時〜18時の間、1時間おきに巡回。 Notification: 直近1時間にログがなければ、LINE Messaging API経由で 「座りっぱなしです！」 と警告通知。 0. 前準備：土台を整える AIにコードを書かせる前に、データの保存先と通知の宛先だけは用意する必要があります。 1. LINE Messaging API の開設 LINE Developersコンソールでチャネルを作成し、以下の2つを取得して控えておきます。 チャネルアクセストークン（長期） ユーザーID（自分のLINEアカウント宛） ※LINE Messaging APIの具体的な開設手順やコンソールの操作については、過去記事「 Amazon Bedrockでブログ要約をLINE通知する 」で解説しています。設定に迷った場合は、こちらも合わせて参考にしてください。 2. Firestore (データベース) の作成 Google Cloud側でデータを保存する場所を作ります。ここもGUIでポチポチやってもいいのですが、せっかくなので Gemini に頼んでみました。 Geminiへの指示: 「Firestoreをネイティブモードで、東京リージョン(asia-northeast1)に作成するコマンドを教えて」 提示されたコマンドを Cloud Shell に貼り付けて実行し、一瞬でデータベースの準備が完了しました。 # 実際に実行したコマンド gcloud firestore databases create --location=asia-northeast1 ※初めて実行する場合、「APIを有効にしますか？」と聞かれるので Y を押して進めます。 開発フェーズ1：Geminiに「ロジック」を書かせる 土台ができたらアプリケーションのコード（Python）です。 ここでのポイントは、 「自分では1行も書かない」 ことです。 普段ならエディタを開いて「どう書くんだっけ…」と悩みますが、今回は Gemini に向かって、やりたいことをそのまま伝えました。 Geminiへの相談内容: 「Apple Watchからデータを受け取ってFirestoreに保存したい」 「1時間おきにチェックして、データがなかったらLINEに警告を送る機能がほしい」 このように要件を伝えていくと、Gemini はすぐに main.py のコード全文を生成してくれました。 私は内容をざっと見て、おかしなところがないか確認するだけです。 実際に作成されたコードがこちらです。 （※トークン部分は環境変数から読み込むように記述されています） 作成された main.py import os from datetime import datetime, timedelta import pytz import functions_framework from google.cloud import firestore from linebot import LineBotApi from linebot.models import TextSendMessage Firestoreクライアントの初期化 db = firestore.Client() JST = pytz.timezone('Asia/Tokyo') @functions_framework.http def record_squat(request): """ Apple Watchからのリクエストを受け取り、 Firestoreに現在時刻と回数を保存する関数 """ doc_ref = db.collection('squat_logs').document() doc_ref.set({ 'created_at': datetime.now(JST), 'count': 10 }) return 'Squat Recorded!', 200 @functions_framework.http def check_and_notify(request): """ 直近1時間のログを確認し、 運動していなければLINEに通知を送る関数 """ # LINE設定の読み込み（ここで読み込まないとエラーになるため） line_access_token = os.environ.get('LINE_CHANNEL_ACCESS_TOKEN') line_user_id = os.environ.get('LINE_USER_ID') if not line_access_token or not line_user_id: # 環境変数が設定されていない場合はエラーを返す print("Error: LINE configuration not found.") return 'Error: Env vars not set', 500 # トークンがある場合のみ初期化 line_bot_api = LineBotApi(line_access_token) now = datetime.now(JST) one_hour_ago = now - timedelta(hours=1) # 1時間以内のログがあるか検索 docs = db.collection('squat_logs') \ .where('created_at', '>=', one_hour_ago) \ .limit(1) \ .stream() if any(docs): return 'Good Job! You moved.', 200 else: # ログがなければ警告送信 try: line_bot_api.push_message( line_user_id, TextSendMessage(text='⚠️ 座りっぱなしです！スクワットをしてください！') ) return 'Alert Sent', 200 except Exception as e: print(f"LINE Error: {e}") return 'Error sending notification', 500 また、Geminiは必要なライブラリをまとめた requirements.txt も教えてくれました。 これも同じ場所に保存します。これが抜けているとデプロイ時にエラーになるので注意してください。 requirements.txt google-cloud-firestore line-bot-sdk functions-framework pytz 【Tips】Cloud Shell エディタを使うと便利 ファイルの作成は、ターミナルでコマンドを叩かなくても大丈夫です。 画面上部にある 「エディタを開く（鉛筆アイコン）」 をクリックすると、VS Codeのような画面が開きます。 そこで右クリックして「新しいファイル」を作成し、上記のコードを貼り付けるのが一番カンタンです。 開発フェーズ2：Geminiで「インフラ」を作る コードができたらデプロイです。 ここでは、Geminiに生成してもらったコマンドを少し調整して、 「記録用」 と 「監視用」 の2つの関数をデプロイしました。 1. 記録用関数のデプロイ Apple Watchから叩かれる関数です。認証なしでアクセスできるように設定します。 gcloud functions deploy record-squat --gen2 --runtime=python311 --region=asia-northeast1 --source=. --entry-point=record_squat --trigger-http --allow-unauthenticated ※途中「APIを有効にしますか？」と聞かれたら Y で進めてください。 2. 監視用関数のデプロイ こちらはLINEへの通知機能を持つため、環境変数でトークンを渡します。 （※コマンド内の [YOUR_TOKEN] などの部分は、前準備で控えた自分の値に書き換えて実行してください） gcloud functions deploy check-and-notify --gen2 --runtime=python311 --region=asia-northeast1 --source=. --entry-point=check_and_notify --trigger-http --allow-unauthenticated --set-env-vars LINE_CHANNEL_ACCESS_TOKEN="[YOUR_TOKEN]",LINE_USER_ID="[YOUR_ID]" 【Tips】Cloud Functions と Cloud Run の関係 デプロイ完了後、コンソールを確認して少し驚きました。 「Cloud Functions」を作ったはずが、 「Cloud Run」 のサービス一覧に表示されていたからです。 実はこれ、現在の Google Cloud の仕様です。 第2世代の Functions (Gen2) は、裏側の実体が Cloud Run で動いています。そのため、名称も現在は Cloud Run functions となっており、このように Cloud Run の管理画面からも「関数」として確認できるのです。 3. 定期実行（Cloud Scheduler）の設定 最後に、監視用関数を「平日の9時〜18時の間、1時間おき」に実行するジョブを作成しました。 （※ uri の部分は、 check-and-notify のデプロイ後に表示されたURLを入れてください） gcloud scheduler jobs create http squat-police-job --schedule="0 9-18 * * 1-5" --time-zone="Asia/Tokyo" --uri="[監視用関数 check-and-notify のURL]" --http-method=GET 次のステップへの準備：URLをコピーする すべてのデプロイが完了したら、Apple Watch用に 「記録用関数 (record-squat)」のURL を控えておきます。 （Cloud Run のサービス詳細画面で、 record-squat の名前の下にあるURLをコピーするのが簡単です） 連携設定：物理世界とクラウドを繋ぐ バックエンドができたら、あとはApple Watchの設定です。 iPhoneの「ショートカット」アプリを開き、新しいショートカットを作成します。 使うアクションは 「URLの内容を取得」 です。 URL: 先ほどコピーした record-squat のURL 方法 (Method): POST に変更（これをしないと動きません！） これを「Apple Watchに表示」設定にするだけで、手首に 「スクワット完了ボタン」 が出現します。 結果：こうなりました 実際に運用してみた様子がこちらです。 1. サボった時 1時間以上ボタンを押さないと、Cloud Schedulerが作動し、容赦なくLINEが飛んできます。(※画像はテスト通知時の画面です) 2. ちゃんと運動した時 スクワットをしてApple Watchのボタンを押すと、Firestoreにデータが保存されます。 データもバッチリ届いています。 このログがある限り、次の監視タイミングでは通知がスキップされます。 「LINE通知を止めるためにスクワットをする」 という、奇妙ですが強力な習慣化サイクルが完成しました。 まとめ：インフラエンジニアこそAIを使うべき 今回、簡単なアプリ構築を通して感じたことは以下の3点です。 ブラウザひとつで開発が完結する Cloud ShellとGeminiさえあれば、環境構築もコーディングもデプロイもすべて完結します。 インフラ操作は「対話」で行う時代へ CLIコマンドを暗記しなくても、やりたいことを伝えれば適切なコマンドが出てきます。 サーバーレス × 個人開発の相性の良さ 今回の構成（Cloud Run functions + Firestore）なら、個人利用レベルではほぼ 無料 です。 AWSエンジニアの私にとって、Google Cloudの Cloud Shell の手軽さと、Geminiによる的確なコマンド支援は強力な武器になると感じました。 皆さんも、AIを相棒にして「自分専用の便利ツール」を作ってみてはいかがでしょうか？

AWS LambdaでMCPサーバーを動的インストール：サーバーレスAIエージェントの実装 はじめに 前回の記事では、Amazon Bedrock AgentsとMCPサーバーの統合について検証しました。本記事では、その技術をAWS Lambda上で実装し、MCPサーバーの動的インストールとサーバーレス実行を実現する方法について解説します。 検証の背景と目的 AIエージェントシステムを本番環境で運用する際、以下の課題があるのではないでしょうか。 スケーラビリティ : ユーザー数の増加に応じて自動的にスケールする必要がある コスト効率 : 使用した分だけ課金されるサーバーレスアーキテクチャが望ましい 柔軟性 : ユーザーごとに異なるMCPサーバーセットを動的に利用できる必要がある AWS Lambdaを活用することで、これらの課題を解決できます。 アーキテクチャ概要 システム構成 [ユーザーリクエスト] ↓ [Lambda関数] ├─ DynamoDBからMCPサーバー設定を取得 ├─ MCPサーバーを動的インストール (uvx/npx) ├─ MCPクライアント生成 └─ Bedrock Agentを実行 ↓ [レスポンス] 主要コンポーネント DynamoDB : ユーザーごとのMCPサーバー設定を保存 Lambda関数 : MCPサーバーのインストールとエージェント実行 Bedrock Agent : LLMとMCPツールの統合実行 実装の詳細 1. Lambda関数のエントリーポイント import os, json, asyncio, logging from pathlib import Path import boto3 import mcp_manager as mm from mcp_manager import create_mcp_client, get_user_mcp_config, install_server from bedrock_agent import agent_invoke def lambda_handler(event, context): # Lambda実行環境の初期化 for d in ("/tmp/.local/share", "/tmp/uv-cache", "/tmp/uv-tools", "/tmp/.local/share/uv", "/tmp/.local/share/uv/tools"): Path(d).mkdir(parents=True, exist_ok=True) os.environ["HOME"] = "/tmp" os.environ["XDG_DATA_HOME"] = "/tmp/.local/share" os.environ["UV_CACHE_DIR"] = "/tmp/uv-cache" os.environ["UV_TOOLS_DIR"] = "/tmp/uv-tools" os.environ["PATH"] = "/var/task/bin:" + os.environ.get("PATH", "") mm.DATA_DIR = Path("/tmp/data") mm.DATA_DIR.mkdir(parents=True, exist_ok=True) os.environ.setdefault("BEDROCK_MODEL", "anthropic.claude-3-5-sonnet-20241022-v2:0") # 入力パラメータの取得 user = event.get("user", "default") query = event.get("query", "Hello from Lambda.") # DynamoDBからMCPサーバー設定を取得 ddb_servers = load_servers_from_ddb(user) ev_servers = event.get("servers") servers = ev_servers if isinstance(ev_servers, list) else ddb_servers # MCPサーバーのインストール for s in servers: try: install_server(user, s) except Exception: logging.exception(f"install_server で例外が発生: {s.get('name')}") # MCPクライアント生成とエージェント実行 cfg = get_user_mcp_config(user) mcp_client = create_mcp_client(cfg) resp = asyncio.run(agent_invoke(mcp_client, query)) return { "statusCode": 200, "body": json.dumps({"response": resp}, ensure_ascii=False) } 2. DynamoDBからの設定取得 def load_servers_from_ddb(user: str): """DynamoDBからユーザーのMCPサーバー設定を取得""" table_name = os.environ.get("SERVERS_TABLE") if not table_name: logging.warning("SERVERS_TABLE が未設定") return [] ddb = boto3.resource("dynamodb") table = ddb.Table(table_name) try: resp = table.get_item(Key={"user": user}) item = resp.get("Item") if not item: logging.info(f"DynamoDBに user={user} のレコードが見つかりません") return [] servers = item.get("servers", []) # JSON文字列の場合はパース if isinstance(servers, str): servers = json.loads(servers) if not isinstance(servers, list): logging.warning(f"servers が配列ではありません: {type(servers)}") return [] return servers except Exception: logging.exception("DynamoDB GetItem に失敗") return [] 3. MCPサーバーの動的インストール def install_server(user: str, server_info: Dict[str, Any]): # Lambda環境用のディレクトリ作成 for p in ['/tmp/.local/share', '/tmp/uv-tools', '/tmp/uv-cache', '/tmp/.local/share/uv', '/tmp/.local/share/uv/tools']: Path(p).mkdir(parents=True, exist_ok=True) cfg = get_user_mcp_config(user) if "mcpServers" not in cfg: cfg["mcpServers"] = {} server_name = server_info.get("name") if not server_name: raise ValueError("server_info に 'name' キーがありません") if server_name in cfg["mcpServers"]: raise ValueError(f"MCPサーバー '{server_name}' は既に存在します") protocol = server_info.get("protocol") url = server_info.get("url", None) install = server_info.get("install", {}) # 環境変数の補強（uvx/uv用） env_vars = install.get("env", {}) if install.get("command") in ["uv", "uvx"]: env_vars["UV_CACHE_DIR"] = "/tmp/uv-cache" env_vars["UV_TOOLS_DIR"] = "/tmp/uv-tools" env_vars["HOME"] = "/tmp" env_vars["XDG_DATA_HOME"] = "/tmp/.local/share" # サーバー設定の保存 if url is not None: server_config = { "protocol": protocol, "url": url, "headers": server_info.get("headers", {}), "auth": server_info.get("auth", {}) } else: server_config = { "command": install.get("command"), "args": install.get("args", []), "env": env_vars } cfg["mcpServers"][server_name] = server_config save_user_mcp_config(user, cfg) 4. Bedrock Agentとの統合 async def agent_invoke(mcp_client, query): model = os.getenv('BEDROCK_MODEL', 'anthropic.claude-3-5-sonnet-20241022-v2:0') agent = ConverseAgent(model) agent.tools = ConverseToolManager() agent.system_prompt = """You are a knowledgeable and reliable AI assistant. Please answer users' questions accurately and concisely. Tools should only be used when clearly necessary to address the user's question.""" async with mcp_client: tools = await mcp_client.list_tools() for tool in tools: agent.tools.register_tool( name=tool.name, func=mcp_client.call_tool, description=tool.description, input_schema={'json': tool.inputSchema} ) try: response = await agent.invoke_with_prompt(query) return response except Exception as e: print(f"Error occurred: {e}") raise DynamoDB設定 テーブル構造 テーブル名: ServersTable パーティションキー: user (String) 属性: servers (List) データ例 { "user": "takayuki", "servers": [ { "name": "fs", "install": { "command": "uvx", "args": ["mcp-server-filesystem", "--root", "/var/task"] } }, { "name": "time", "install": { "command": "uvx", "args": ["mcp-server-time"] } }, { "name": "gdrive", "install": { "command": "npx", "args": ["--yes", "@modelcontextprotocol/server-google-drive"] } } ] } 検証結果 1. uvxコマンドによる動的インストール テストイベント: { "user": "test-user", "query": "あなたは何ができますか。", "servers": [ { "name": "mcp_server", "install": { "command": "uv", "args": ["tool", "run", "mcp-server-time"], "env": { "HOME": "/tmp", "XDG_DATA_HOME": "/tmp/.local/share", "UV_CACHE_DIR": "/tmp/uv-cache", "UV_TOOLS_DIR": "/tmp/uv-tools" } } } ] } 結果: 成功 { "statusCode": 200, "body": "{\"response\": \"私は時間に関する以下の2つの主要な機能を提供できます：\\n\\n1. 特定のタイムゾーンの現在時刻を取得\\n- 世界中の任意のタイムゾーンの現在時刻を確認できます\\n- 例：東京、ニューヨーク、ロンドンなどの現在時刻\\n\\n2. タイムゾーン間の時刻変換\\n- ある地域の時刻を別の地域の時刻に変換できます\\n- 例：日本時間の15:00をニューヨーク時間に変換する、など\"}" } 2. Zapier（StreamableHTTP）へのアクセス テストイベント: { "user": "test-user", "query": "あなたは何ができますか。", "servers": [ { "name": "mcp_server", "protocol": "StreamableHttp", "url": "https://mcp.zapier.com/api/mcp/s/.../mcp", "headers": {}, "auth": {} } ] } 結果: 成功 { "statusCode": 200, "body": "{\"response\": \"私は主に以下の機能を提供できます：\\n\\n1. Gmailのメール検索\\n- メールの送信者、受信者、件名、内容などで検索\\n- 添付ファイルの有無での検索\\n- 日付による検索\\n- ラベルによる検索など\\n\\n2. Googleカレンダーの予定検索\\n- 特定の期間の予定を検索\\n- イベント名や説明文での検索\\n- 定期的な予定の展開\\n- 複数のカレンダーからの検索\"}" } 結論: Lambdaからの動的インストールとZapierへのアクセスの両方が正常に動作することを確認しました。 技術的なポイントと工夫 1. Lambda環境の制約への対応 Lambda関数は読み取り専用のファイルシステムを持ち、書き込み可能なのは /tmp ディレクトリのみです。この制約に対応するため、以下の工夫を行いました。 # 環境変数の設定 os.environ["HOME"] = "/tmp" os.environ["XDG_DATA_HOME"] = "/tmp/.local/share" os.environ["UV_CACHE_DIR"] = "/tmp/uv-cache" os.environ["UV_TOOLS_DIR"] = "/tmp/uv-tools" これにより、uvxやnpxが /tmp 配下にパッケージをインストールできるようになります。 2. 依存ライブラリのパッケージング Lambda Layerまたはデプロイパッケージに以下のライブラリを含める必要があります： python3.12 -m pip install \ "pydantic[email]==2.11.10" \ fastmcp \ mcp \ pydantic-settings \ uv \ uvx \ -t ~/lambda_build 重要: Lambdaのランタイムバージョンとビルド環境のPythonバージョンを一致させる必要があります（今回の検証ではPython 3.12）。 3. Node.jsツールのサポート npxコマンドを使用するため、Lambda環境にNode.jsをバンドルする必要があります： # Node.jsとnpmのインストール curl -fsSL https://rpm.nodesource.com/setup_18.x | sudo bash - sudo yum install -y nodejs # パッケージのインストール npm install @modelcontextprotocol/server-filesystem --prefix ~/lambda_build Lambda関数のPATH環境変数に、Node.jsバイナリのパスを追加します： os.environ["PATH"] = "/var/task/bin:" + os.environ.get("PATH", "") 4. IAMロールの設定 Lambda実行ロールに以下の権限が必要です。 Bedrock : bedrock:InvokeModel （InvokeModelだけで十分、FullAccessは過剰） DynamoDB : dynamodb:GetItem （GetItemだけで十分、FullAccessは過剰） 本番環境では、最小権限の原則に従い、必要最小限の権限のみを付与することを推奨します。 5. コールドスタート対策 Lambda関数の初回実行時（コールドスタート）は、MCPサーバーのインストールに時間がかかります。以下の対策が考えられます。 Provisioned Concurrency : 事前にウォームアップされたインスタンスを確保 キャッシュ戦略 : よく使われるMCPサーバーをLambda Layerに事前インストール 非同期処理 : インストール処理を並列化 苦労したポイント 1. Lambda環境でのuvx実行 uvxコマンドは通常、ユーザーのホームディレクトリにツールをインストールしますが、Lambdaでは /tmp のみが書き込み可能です。環境変数 HOME 、 XDG_DATA_HOME 、 UV_CACHE_DIR 、 UV_TOOLS_DIR を適切に設定することで解決しましたが、この組み合わせを見つけるまでに試行錯誤が必要でした。 2. 依存ライブラリのバージョン互換性 FastMCPとMCPライブラリのバージョン互換性に注意が必要でした。特に、Pydanticのバージョン（2.11.10）を明示的に指定することで、依存関係の問題を回避しました。 3. 非同期処理の扱い Bedrock AgentとMCPクライアントは非同期処理を使用しますが、Lambda関数のエントリーポイントは同期関数です。 asyncio.run() を使用して非同期処理を同期的に実行する必要がありました。 resp = asyncio.run(agent_invoke(mcp_client, query)) 4. DynamoDBのデータ型変換 DynamoDBから取得したデータは、DynamoDB固有の型（ {'S': 'value'} など）で返されることがあります。boto3のresourceインターフェースを使用することで、自動的にPythonネイティブ型に変換されますが、JSON文字列として保存されている場合の処理も考慮する必要がありました。 5. タイムアウトとメモリ設定 MCPサーバーのインストールとエージェント実行には時間がかかるため、Lambda関数のタイムアウトを十分に長く設定する必要があります（推奨: 5分以上）。また、メモリも1024MB以上を推奨します。 パフォーマンス考察 コールドスタート時間 MCPサーバーなし: 約2-3秒 MCPサーバー1つ（uvx）: 約10-15秒 MCPサーバー複数: 約20-30秒 ウォームスタート時間 約1-2秒（MCPサーバーは既にインストール済み） コスト試算 Lambda実行時間: 15秒（平均） メモリ: 1024MB 月間実行回数: 10,000回 推定コスト: 約$3-5/月 まとめ 本検証により、以下のことが実証されました。 AWS Lambda上でMCPサーバーの動的インストール が可能 uvx/npxコマンド を使用したパッケージの実行時インストールが機能 DynamoDB を使用したユーザーごとの設定管理が有効 StreamableHTTP プロトコルでの外部サービス（Zapier）連携が可能 サーバーレスアーキテクチャでの スケーラブルなAIエージェントシステム の実現 本番環境への適用に向けて 本番環境で運用する際は、以下の点に注意が必要です。 IAM権限の最小化 : FullAccessではなく、必要最小限の権限のみを付与 エラーハンドリング : MCPサーバーのインストール失敗時の適切な処理 ログとモニタリング : CloudWatch Logsでの詳細なログ記録 コスト最適化 : Provisioned Concurrencyの適切な設定 セキュリティ : VPC内での実行、シークレット管理（Secrets Manager） 検証環境 AWS Lambda (Python 3.12) Amazon DynamoDB Amazon Bedrock FastMCP uv/uvx, Node.js/npx

Amazon Bedrock AgentsとMCPサーバーの統合検証：権限制御とプロトコル対応 AIエージェントシステムの実用化において、適切な権限制御と外部ツールとの柔軟な連携は重要な課題です。本記事では、Amazon Bedrock Agentsを用いたマルチエージェント構成において、ユーザーごとのエージェント利用制限と、Model Context Protocol（MCP）サーバーの複数プロトコル対応について検証してみました。 検証の背景と目的 企業でAIエージェント導入を検討する際、以下の要件が求められることが多いのではないでしょうか。 権限制御 : ユーザーの役割や権限に応じて、利用可能なエージェント機能を制限する 柔軟な外部連携 : 様々な通信プロトコルに対応し、多様な外部サービスと統合する 私が開発に携わるSCSKのAIサービスInfoWeaveにおいてもMCPサーバー対応を検討しており、これらの要件を満たす実装方式を実際に検証しました。 検証1: Bedrock Agentsにおける権限制御の実装 実装方式 Supervisorエージェントに対するリクエスト時に、 promptSessionAttributes を活用して利用不可能なCollaborator（サブエージェント）を指定し、システムプロンプトでその制約を強制する方式を採用しました。 システムプロンプトの設計 以下はシステムプロンプトの例です。promptSessionAttributesにリストされているサブエージェントを 利用しないよう強く指示 しています。 # Supervisor Agent Instruction あなたは「Supervisor Agent」です。 目的は **ユーザーの要求を正確に理解し、最短経路で解決するために 最適なサブエージェント／ツールをリストアップする** ことです。 ## 基本行動 1. promptSessionAttributesにリストされている Collaborator は利用不可の為、 **絶対に** 利用しない。 2. 利用不可の Collaborator を確認する。 3. 各タスクを完遂するために、以下の Collaborator を状況に応じて組み合わせる。 - task-creation - task-validation - function1 - function2 - function3 - function4 実装コード 以下は実装コードの例です。 import boto3 import json import uuid def lambda_handler(event, context): input_text = "今日の東京の天気を教えてください。" agent_id = 'xxxxxxxx' agent_alias_id = 'yyyyyyyy' session_id = str(uuid.uuid1()) # promptSessionAttributesで利用不可のCollaboratorを指定 session_state = { "promptSessionAttributes": { "non-use-agent1": "function4" } } client = boto3.client("bedrock-agent-runtime") response = client.invoke_agent( inputText=input_text, agentId=agent_id, agentAliasId=agent_alias_id, sessionId=session_id, enableTrace=False, sessionState=session_state ) event_stream = response['completion'] for event in event_stream: if 'chunk' in event: data = event['chunk']['bytes'].decode("utf-8") print(data) 出力結果 Start RequestId: xxxxxxxxxx-xxxxxxxx-xxxx-xxxx Version: $LATEST 1. ユーザーの要求を分析： - 目的: 東京の今日の天気情報を取得 - 必要な情報: 場所（東京）、日時（今日）は明確 2. タスク分解と必要な Collaborator の選出: - タスク状況の確認と分解 - 天気情報の取得（Web APIまたはブラウザ利用） - 結果の検証 3. 利用不可の Collaborator: - function4 は利用不可 4. 実施計画: 天気情報取得には function1 が最適 (1) task-creation (2) function1 (3) task-validation 利用不可な Collaborator は「function4」です END RequestId: xxxxxxxxxx-xxxxxxxx-xxxx-xxxx ※実際にはfunction1～function4には、例えば外部API呼び出し機能やWeb検索機能等の機能が備わっています。ユーザー要望の「東京の天気を調べる」為に、使用可能な機能の中からどの機能を呼び出せばいいのかをSupervisorが判断して組み合わせています。 例えば今回の例だとfunction4に天気情報検索API、function1にWeb検索機能が割当てられている場合、直感的にfunction4を使いたくなりますが使用不可リストに入っているため、function1のWeb検索を利用してユーザー要望を達成する、という流れになります。 検証結果 結論 : promptSessionAttributesに利用不可のCollaboratorを指定することで、指定されたCollaboratorは使用しないようにすることができました。Supervisorは、promptSessionAttributesでリストされているCollaboratorを除外した上で、最適なCollaboratorを選択し実行計画を立てることを確認しました。もちろん利用可能なCollaboratorを指定することで、リストされたCollaboratorのみを使用することも可能です。 技術的なポイントと工夫 1. システムプロンプトでの強制力 単にpromptSessionAttributesに情報を渡すだけでなく、システムプロンプトで「 絶対に 利用しない」という強い表現を使用することで、LLMの判断を確実に制御しています。 2. 出力フォーマットの明示 利用不可のCollaboratorを明示的に出力させることで、権限制御が正しく機能していることを可視化し、デバッグやログ分析を容易にしています。 検証2: MCPサーバーの複数プロトコル対応 MCPプロトコルの種類 Model Context Protocol（MCP）は、AIエージェントと外部ツールを接続するための標準プロトコルです。主に以下の3つの通信方式があります。 STDIO : 標準入出力を使用した通信（ローカル実行向け） SSE (Server-Sent Events) : HTTPベースの一方向ストリーミング StreamableHTTP : HTTPベースの双方向通信 実装アーキテクチャ FastMCPライブラリを使用し、複数のプロトコルに対応したMCPクライアントを実装しました。 from typing import Dict, Any from fastmcp import FastMCP, Client from fastmcp.client.transports import ( UvxStdioTransport, NpxStdioTransport, FastMCPTransport, StreamableHttpTransport, SSETransport ) def create_mcp_client(config: Dict[str, Any]) -> Client: composite_server = FastMCP() for prefix, server_cfg in config.get('mcpServers', {}).items(): # StreamableHTTP型 if "url" in server_cfg and server_cfg.get("protocol") == "StreamableHttp": url = server_cfg["url"] headers = server_cfg.get("headers", {}) transport = StreamableHttpTransport(url=url, headers=headers) composite_server.mount(prefix=prefix, server=FastMCP.as_proxy(transport)) # SSE型 elif "url" in server_cfg and server_cfg.get("protocol") == "sse": url = server_cfg["url"] headers = server_cfg.get("headers", {}) transport = SSETransport(url=url, headers=headers) composite_server.mount(prefix=prefix, server=FastMCP.as_proxy(transport)) # STDIO型 elif "command" in server_cfg: tool_command = server_cfg.get('command') tool_args = server_cfg.get('args', []) env_vars = server_cfg.get('env', {}) if tool_command == 'uvx': transport = UvxStdioTransport( tool_name=tool_args[0], tool_args=tool_args[1:], env_vars=env_vars ) elif tool_command == 'npx': transport = NpxStdioTransport( package=tool_args[1], args=tool_args[2:], env_vars=env_vars ) composite_server.mount(prefix=prefix, server=FastMCP.as_proxy(transport)) transport = FastMCPTransport(mcp=composite_server) client = Client(transport) return client 検証したMCPサーバー StreamableHTTP : Zapier MCP Server — 以下２機能を設定・有効化 Gmail検索機能 Googleカレンダー連携 SSE : 自作MCPサーバー — 以下２機能を実装 エコーツール 現在時刻取得ツール SSE型MCPサーバーの実装例 from mcp.server.fastmcp import FastMCP mcp = FastMCP("minimal-mcp-server") @mcp.tool() def echo(message: str) -> str: """入力されたメッセージをそのまま返す簡単なツール""" return f"Echo: {message}" @mcp.tool() def get_current_time() -> str: """現在の日時を取得するツール""" from datetime import datetime now = datetime.now() return f"現在の日時: {now.strftime('%Y-%m-%d %H:%M:%S')}" if __name__ == "__main__": mcp.run(transport="sse") 検証結果 結論 : StreamableHTTPとSSEの両方のプロトコルで、MCPサーバーとの通信が正常に動作することを確認しました。 Zapier（StreamableHTTP）経由でのGmail検索が成功 自作SSEサーバーからの時刻取得が成功 複数のMCPサーバーを同時に利用可能 技術的なポイントと工夫 1. プロトコルの自動判別 設定ファイルの構造から適切なTransportクラスを自動的に選択できるため、ユーザーは意識せず複数プロトコルを利用できます。 2. 統一的なインターフェース FastMCPの composite_server パターンを使用することで、異なるプロトコルのMCPサーバーを単一のクライアントから透過的に利用できます。 3. 設定の柔軟性 JSON形式の設定ファイルで、プロトコルタイプ・認証情報・ヘッダー等を柔軟に指定できる設計です。 { "mcpServers": { "zapier-mcp-sh": { "protocol": "StreamableHttp", "url": "https://mcp.zapier.com/api/mcp/s/...", "headers": {}, "auth": {} }, "test-mcp-sse": { "protocol": "sse", "url": "http://127.0.0.1:8000/sse", "headers": {}, "auth": {} } } } 苦労ポイント 1. promptSessionAttributesの活用方法の発見 当初、Bedrock Agentsでの権限制御をどのように実現するかの検討から始まりました。promptSessionAttributesとシステムプロンプトの組み合わせで制約実現できるまで試行錯誤が必要でした。 2. MCPプロトコルごとの微妙な差異 各プロトコルで必要なパラメータや初期化方法が異なり、統一的なインターフェースを提供する抽象化レイヤー設計に工夫が必要に。特にSSEとStreamableHTTPでのヘッダー処理の違いに注意が要りました。 3. FastMCPライブラリの活用 FastMCPライブラリのドキュメントが限定的で、ソースコードを読み解きcomposite_serverパターンやas_proxyメソッドの使い方を理解する必要がありました。 まとめ 本検証により、以下のことが確認できました。 promptSessionAttributes とシステムプロンプトの組み合わせにより、Bedrock Agentsでユーザーごとの権限制御が実現可能 FastMCPライブラリ を活用することで、STDIO、SSE、StreamableHTTPの複数プロトコルに対応したMCPサーバー統合が可能 異なるプロトコルのMCPサーバーを 単一のクライアントから透過的に利用 できる これらの技術により、エンタープライズ環境でのAIエージェント導入における、セキュリティと拡張性の両立が可能となります。 次回の記事では、これらの技術をAWS Lambda上で動作させ、サーバーレスアーキテクチャでの実装について解説します。 検証環境 Amazon Bedrock Agents Python 3.12 FastMCP Zapier MCP Server

リモートワークが定着し、脱PPAPやファイルサーバーのクラウド化が当たり前となった今、改めて「クラウドストレージの選定」が重要視されています。 「Microsoft 365があるからOneDriveで良いのでは？」「セキュリティならBox一択？」 そのような議論の中で、なぜ今Dropboxが選ばれるのか。エンジニア視点での同期技術の違いや、ユーザー体験（UX）の観点から競合製品と比較し、導入によって組織にもたらされる期待効果を解説します。 クラウドストレージは「保管場所」から「ワークスペース」へ 現状の課題:ファイルサーバーの単なる置き換え（リフト＆シフト）では、結局VPN帯域の圧迫や、ファイルの先祖返り、検索性の低さといった課題が解決しきれていない。 トレンド:単にファイルを置くだけのストレージ（Storage）から、共同作業を行うための「スマートワークスペース」への進化が求められている。 主要3サービス（Dropbox / Box / OneDrive）徹底比較 ここでは、エンタープライズで比較検討されやすい Box、OneDrive for Business (SharePoint)と比較します。 (1) 技術的な「同期」の仕組みの違い Dropboxの強み: ブロックレベルの差分同期:ファイル全体ではなく、変更箇所（バイナリ差分）のみを転送するため、特に大容量ファイル（CAD、動画、解析データなど）の同期が圧倒的に速い。 LAN同期:同じネットワーク内の別PCにファイルがある場合、インターネットを経由せずローカルネットワーク内で同期を完結させる技術。オフィス回線の負荷軽減に寄与する。 競合との差:他社製品はファイル単位のアップロードになりがちで、同期速度や帯域負荷でDropboxに分があるケースが多い。 (2) UI/UXとユーザビリティ Dropbox:「エクスプローラー/Finder」との親和性が極めて高く、OS標準の操作感で使えるため、ITリテラシーが高くないユーザーでも教育コストがほぼ不要。 Box:Webブラウザベースでの利用に強みがあるが、デスクトップアプリの挙動において、ヘビーユーザーはDropboxの軽快さを好む傾向がある。 OneDrive:Windowsとの統合は最強だが、Macユーザーが混在する環境や、社外との共有フローにおいて柔軟性に欠ける場合がある。 (3) エコシステムの柔軟性 Dropbox:Microsoft (Office系) と Google (Workspace系) の両方と等距離で連携可能。 比較:「Slack」「Zoom」「Adobe CC」など、ベストオブブリード型でSaaSを組み合わせる企業にとって、ハブとしての機能が優れている。 比較項目 Dropbox Box OneDrive/Sharepoint 同期技術 差分同期・LAN同期 (高速) ファイル単位 差分同期 (Office系に特化) 得意なデータ クリエイティブ・大容量データ 文書管理・権限管理 一般的なOffice文書 UI/UX デスクトップ統合 (OSライク) ブラウザベース・プレビュー Windows統合 社外共有 直感的・Transfer機能あり 高度な権限設定 ゲスト招待が必要な場合あり   Dropbox導入で得られる3つの期待効果（ROI） ① 業務スピードの向上（「待つ時間」の削減） GB単位のデータ同期待ち時間が短縮されることで、クリエイティブ部門や設計部門のリードタイムが短縮される。 「スマートシンク」機能により、ローカルディスクの容量を消費せずに数TBのデータにアクセス可能。PC更改時のデータ移行作業も不要になる。 ② 「シャドーIT」の撲滅とガバナンス強化 使い勝手が悪いストレージを導入すると、現場は無料の転送サービスや個人用ドライブを使い始めてしまう。 「使いやすい（ユーザーが使いたくなる）ツール」を公式に提供することが、結果として最も効果的なセキュリティ対策となる。 ③ コラボレーションの質的変化 「Dropbox Paper」や動画へのタイムスタンプ付きコメント機能（Dropbox Replay）などにより、メールやチャットでの「ファイル添付→修正→送付」の往復ラリーが消滅する。 SCSKが提案する、セキュアで快適なDropbox活用 SCSKの付加価値: 単なるライセンス販売だけでなく、既存ファイルサーバーからのデータ移行支援。 IDaaSやCASBと組み合わせた、エンタープライズレベルのゼロトラストセキュリティ環境の構築。 「BoxかDropboxか」で迷われているお客様への、業務特性に合わせたフラットな選定支援。 最後に：ツール選びは「ユーザー体験（EX）」への投資 クラウドストレージの選定において、容量単価やセキュリティ要件の〇×表だけで判断してしまうと、導入後に「同期が遅くて仕事にならない」「使いにくくて現場が使ってくれない」という課題に直面しがちです。 今回ご紹介したように、Dropboxは 「圧倒的な同期技術（スピード）」と「直感的なUI（使いやすさ）」 において、エンジニアやクリエイターの業務効率を最大化する強力な強みを持っています。 特に、大容量ファイルを扱う業務や、Mac/Windowsが混在する環境、ベストオブブリードで様々なSaaSを使いこなす組織にとって、Dropboxは単なる「ファイル置き場」を超えた、業務変革のエンジンとなり得ます。 「うちの環境ではBoxとDropbox、どちらが適しているのか？」 「既存のファイルサーバーからの移行はどう進めればよいか？」 「セキュリティ（ID管理やCASB）も含めた全体設計を相談したい」 SCSKでは、特定の製品に縛られず、お客様の業務特性や解決したい課題に合わせた最適なクラウドストレージ環境をご提案いたします。検証環境の構築やPoC（概念実証）のご支援も可能ですので、まずは「TechHarmonyを読んだ」とお気軽にご相談ください。 本ブログのお問合せ：　 Dropbox-sales@scsk.jp

こんにちは。SCSKの井上です。 複雑なマイクロサービス環境で、障害の原因を素早く特定するにはAPMが欠かせません。本記事では、分散トレーシングの仕組みとAPMをPHPアプリに導入する手順もあわせて解説します。   はじめに APM（Application Performance Monitoring）は、アプリケーションのパフォーマンスを監視し、問題を早期に発見するための仕組みです。遅延の原因はインフラ側かアプリケーション側か、詳細な分析で原因の特定を行うことができます。この記事ではAPMの重要な機能の一つである分散トレーシングの仕組みとPHPアプリケーションの導入手順について解説します。   APMの概要 APMはアプリケーションの稼働状況をユーザー目線で可視化します。ユーザーに影響を与える可能性がある問題を特定したり、アプリケーションのパフォーマンスを改善する手助けになります。対応言語はGo, Java,.NET,Node.js,PHP,Python,Rubyをはじめとする主要な言語に対応しています。開発担当者が安心してリリースを継続でき、ユーザー影響を最小限に抑えながら市場の変化に迅速に対応するためには、APMが必要不可欠になってきています。 主に以下の機能を提供します。 アプリのレスポンス、エラー率、スループットをリアルタイム監視 トランザクション分析や分散トレーシングでボトルネックを特定 データベースや外部サービスのパフォーマンスを可視化 アラート設定やカスタムダッシュボードで運用を効率化   New Relic APM Features Features newrelic.com   APMが必要とする背景 ユーザーに影響を与えている問題を検出して対策するには、ユーザー目線でアプリケーションを監視することが必要になってきます。検出できてもその問題の分析や特定といった処置が遅れてしまうとビジネス影響は拡大していきます。特定や解決に時間がかかると工数もかかり、機会損失にもつながります。APMは、ユーザー目線での監視を実施することで、アプリケーション内の構成要素や処理の流れを可視化し、特定から対処までの時間を短縮することができます。APMが重要視されている背景について2つの観点から紹介します。 1つ目はアーキテクチャの変化 。クラウドやサーバｰレスの技術が普及することで、1つのユーザーリクエストが複数のサービスを経由して処理されるようになっています。いくつものコンポーネントを経由する構成では、どのサービスで遅延やエラーが発生しているかを特定するのが難しくなります。 APMを導入することで、サービス間の依存関係の可視化、トランザクションの遅延やエラーの原因追及、構成変更の影響分析が可能になります。 2つ目は開発プロセスの変化 。クラウドやAIなどの技術進化が速く、新しいサービスや機能が次々と登場しています。顧客は最新トレンドを取り入れたいというニーズが高まっており、従来のウォーターフォール型開発では市場の変化に対応できない状況です。そのため、CI/CDによる頻繁なリリースと、価値を早く提供することが求められていますが、システム変更には性能劣化や障害のリスクがあります。 APMを導入することで、構成変更の影響や変更前後の性能を追跡し、安心してリリースを継続できます。   New Relic実践入門 第2版 オブザーバビリティの基礎と実現 | 翔泳社 あらゆるデータを収集・分析・可視化して、システム／サービスの変化に能動的に対処せよITシステムやサービスが複雑化する現代において、オブザーバビリティ（Observability：可観測性）という考え方が極めて重要になっています。オブザーバビ... www.shoeisha.co.jp   APMでできること ページの表示速度、API応答時間、フロントエンドからバックエンドまでの経路などユーザーが操作する視点で確認することで、ユーザー満足度の低下やビジネス機会損失の影響を最小限に抑えます。APMを導入することで、以下のようなことが実現できます。 できること 説明 導入効果 サービスレベルの可視化 ユーザー視点での各サービスの可用性、レイテンシ、エラーレートなどのサービス単位の健康状態を表示 重要サービスの健全性を一目で把握 SLO逸脱の早期検知 E2Eの可視化(New Relicブラウザモニタリングが有効の場合) ユーザー操作からレスポンスまで、外部を含めた全経路を横断的に表示 ユーザー影響の把握 依存関係の可視化 トランザクションの可視化 1つの処理（購入、決済、検索等）の流れを時系列で可視化（ステップごとの時間・結果） 遅延ステップの特定 リトライ・タイムアウトの検知 UX改善の根拠提示 分散トレーシング 一連のトランザクションの処理を横断的に分析 遅延、エラーの原因箇所を迅速特定 MTTR短縮 サーバーレスアプリ監視 Lambda、Functions等の実行時間、失敗率、同時実行数 実行コストと性能の最適化 イベント連鎖の不具合検知 スケール時の安定性向上 エラートラッキング 頻度、ユーザー影響の継続的追跡 優先度付け（頻度・影響） 脱ログ中心の確認 インフラ・フロントエンド監視統合 サーバ、ネットワーク、コンテナとブラウザを同画面で表示 インフラ・アプリ運用のコミュニケーション円滑化 構成変更の記録 パラメータ、バージョン、リリースノート等のリリース前後の影響範囲 いつ・誰が・何を変えたかを追跡し障害と変更の相関を即確認 変更管理の品質向上 脆弱性の検出と可視化 サードパーティーライブラリの脆弱性をスキャンして可視化 重大脆弱性の早期発見・優先度付け パッチ適用計画の支援 コンプライアンス強化   New Relic実践入門 第2版 オブザーバビリティの基礎と実現 | 翔泳社 あらゆるデータを収集・分析・可視化して、システム／サービスの変化に能動的に対処せよITシステムやサービスが複雑化する現代において、オブザーバビリティ（Observability：可観測性）という考え方が極めて重要になっています。オブザーバビ... www.shoeisha.co.jp   分散トレーシング 分散トレーシングは、複数のサービスで構成されたシステムで、1つのリクエストがどのように処理されているかを追跡する技術です。マイクロサービスが主流になり、1つのリクエストが複数のサービスを経由します。例えば、Web画面 → API → 在庫サービス → データベースという流れのとき、どこで遅延やエラーが起きているかを1つ1つログを確認して見つけるには時間がかかり、迅速な復旧が難しくなります。そのため分散トレーシングを使ってリクエストの流れを可視化し、問題箇所を特定します。 分散トレーシングを必要とする理由 分散トレーシングを導入することで、障害対応の迅速化により本番環境で発生した問題を素早く特定し、解決までの時間を短縮できます。また、遅延の原因となるボトルネックを明確にして対策することで、システム全体のパフォーマンスを最適化できます。チーム間のコミュニケーションにおいては、開発と運用の両チームが共通の画面で確認することで、 コードの問題か、インフラの負荷が問題か、認識の齟齬が軽減され、問題がユーザー体験に与える影響を把握し、初動を早めることが可能 になります。サービス間の依存関係を分析することでアーキテクチャを改善し、リソース計画やスケーリングの判断に役立つデータも得られます。 基本構造 New Relicの分散トレーシングはOpenTelemetryの標準をベースに、スパン単位で操作を記録し、トレース全体をツリー構造で管理しています。 Trace 複数のサービスを通過する単一のリクエストのE2E経路を表し、一意のトレースIDで識別されます。1つのユーザ操作やリクエスト全体を識別するためのIDで、トレースが終わるまで不変の値です。この値が変わってしまうと、処理の繋がりが追えなくなってしまうためです。   Span サービス内の個々の操作や動作を表します。開始時間と終了時間、所要時間、関連するメタデータに関する情報を含みます。各スパンは、ステップがいつ始まり、いつ終わったか、そして何か問題があったかどうかを確認できます。SpanにもIDがついています。Span ID は各スパン固有のIDで、親子関係を示すために Parent ID とともに使われます。   Context metadata トレースの連続性を維持するためにサービス間で伝播される情報を指します。トレースIDはトレースを一意に識別するものであり、親スパンIDのような他のコンテキスト情報も含まれます。トレースコンテキストは、各サービスが自らのスパンを正しいトレースにリンクし、全体のトレース構造を維持できるようにします。各区間を同じ経路に結びつける重要な情報が入っており、途中で何も失われないようにしています。   ディストリビューティッド（分散）トレーシング：マイクロサービス全体でリクエストを追跡 | New Relic Documentation What is distributed tracing? An intro to New Relic's distributed tracing feature. docs.newrelic.com   ディストリビューティッド（分散）トレーシングに関する技術的な詳細 | New Relic Documentation Technical details of New Relic's distributed tracing, including limits, explanation of sampling, trace data structure, a... docs.newrelic.com   分散トレーシングのサンプリング 全リクエストを記録すると、システムのパフォーマンスに影響するだけでなく、データコストも増加します。そのため、New Relicではデフォルトでヘッドベースサンプリングを採用し、トレースの一部のみを選んでNew Relicに送信しています。テールベースサンプリングを利用する場合は、All Capabilitiesから「Infinite Tracing settings」を選択して有効化する必要があります。 項目 ヘッドベースサンプリング テールベースサンプリング サンプリングのタイミング リクエスト開始時に決定 リクエスト完了後に決定 メリット – 導入が簡単 – 起動が速い – パフォーマンスへの影響ほぼなし – コストが低い – 完了したトレースを見て判断できる – エラーや遅延を含むトレースを優先的に保存 – 問題箇所を確実に把握 デメリット – エラーや遅延があるか事前にわからない – データ送信・保存コストが高い – 管理が複雑 適した環境 – トランザクション量が少ないアプリ – マイクロサービス混在環境 – エラー調査や異常検知を重視する環境 – 高精度なトレース分析が必要な場合   ディストリビューティッド（分散）トレーシングに関する技術的な詳細 | New Relic Documentation Technical details of New Relic's distributed tracing, including limits, explanation of sampling, trace data structure, a... docs.newrelic.com   Complete Guide to Distributed Tracing Learn about distributed tracing, a powerful diagnostic tool, and how to use it, including examples from New Relic. newrelic.com   W3C Trace Context トレースコンテキストは、分散トレーシングにおいてサービス間のリクエストを関連付けるため、複数のサービス間を流れるリクエストを一意に識別し、関連付けるメタデータです。New Relicでは、HTTPヘッダーに以下の表のデータを伝播させることで、E2Eのトレースを構築しています。分散トレーシングの標準仕様であるW3C Trace Contextに準拠することで、トレースIDやスパンIDのフォーマットが標準化し、異なるAPMツールやオープンソース（例：OpenTelemetry）においても統一的な分散トレーシングが可能になっています。 属性名 説明 traceId トレース全体を一意に識別するID。分散トレーシングで全サービス共通。 guid / parentId 現在のスパンID。次のサービスに渡すときは「親ID」として利用。 parent.type 親の種類（ブラウザ、モバイル、APMなど）。 timestamp ペイロード作成時のUNIXタイムスタンプ（ミリ秒）。 transactionId トランザクションイベントの一意識別子。 priority サンプリング優先度（ランダム値）。サンプリング制御に利用。 sampled true / false。このトレースを収集するかどうか。 traceparent W3C標準ヘッダー。トレースID、スパンID、サンプリング情報を含む。 tracestate ベンダー固有情報を追加するためのW3C標準ヘッダー。   ディストリビューティッド（分散）トレーシングに関する技術的な詳細 | New Relic Documentation Technical details of New Relic's distributed tracing, including limits, explanation of sampling, trace data structure, a... docs.newrelic.com   ブラウザモニタリング New Relicブラウザモニタリング機能を導入することで、APMはサーバー側、Browserはクライアント側としてエンドツーエンドの監視が可能になります。ユーザー操作からシステム内部の導線を一つのトレースで確認可能になることでボトルネックがフロントかバックエンドかを即座に判断できます。ブラウザモニタリングはAPM導入と同時に設定することができます。ブラウザモニタリングの機能については、別記事にて紹介します。   分散型トレーシングにおけるブラウザデータ | New Relic Documentation Browser: How to enable browser-side (end-user) data for distributed tracing in New Relic. docs.newrelic.com   PHPエージェント導入前提条件 New Relic PHPエージェント導入にあたり、PHPバージョンの要件や動作条件があります。サポート外のPHPバージョンまたはプラットフォームを使用している場合は、パッケージ管理による自動更新によって互換性の問題が発生する可能性があります。PHPエージェントのパッケージ自動更新を無効化にすることが推奨されています。 サポートされているPHPバージョン情報は以下をご参照ください。 PHP エージェントの EOL ポリシー | New Relic Documentation Policies, start and end dates for support of New Relic PHP agent releases. docs.newrelic.com   PHPバージョンを含め、New Relic PHPエージェントが動作するOS、アーキテクチャの情報は以下をご参照ください。 PHPエージェントの互換性と要件 | New Relic Documentation A summary of the New Relic PHP agent's system requirements and the supported PHP frameworks and libraries. docs.newrelic.com   ファイアウォールやセキュリティポリシーで外部との通信制限がされている場合は、以下をご参照ください。New Relicエージェントがデータ送信できるようにドメインやエンドポイントを追加する必要があります。 New Relicネットワークトラフィック | New Relic Documentation Network connections used by New Relic for sending and receiving data: IP addresses, domains, ports, endpoints. docs.newrelic.com   エージェント導入前の注意事項 システム要件を確認したうえで、PHPエージェント導入にはいくつか注意点があります。既存システムへの影響がないことをテスト環境で十分に検証し、その後本番環境へ導入することを推奨します。以下は一例になります。 WEBサーバーの再起動 本番環境で導入する場合は、インストールのタイミング調整が必要です。エージェント導入後や設定の変更、PHPおよびPHPエージェントのアップデート後はApacheやPHP-FPM、NginxなどのWEBサーバーを再起動する必要があります。WEBサーバーが起動して PHP を読み込むと、PHP エージェントも読み込まれます。 ウェブサーバーを再起動する理由と実施のタイミング（PHP） | New Relic Documentation Why and when you must restart your web server when using the New Relic PHP agent, with links to detailed procedures and ... docs.newrelic.com   拡張モジュールの競合 競合製品がすでに導入されていないかを確認する必要があります。Xdebug、Blackfire、DrupalなどPHPのデバックやパフォーマンス監視、他APM製品が導入されている場合、競合により動作不具合やオーバーヘッドが増加する可能性があります。 PHP agent v11.5.0.18 | New Relic Documentation PHP agent v11.5.0.18 docs.newrelic.com   長時間実行される処理がある 本番環境へ導入する前に、テスト環境にてエージェント導入後、リソースが高騰していないかを確認する必要があります。処理が数分から数時間続く場合、New Relicへのデータ送信が遅れ、メモリ使用量が増える可能性があります。エージェントはトランザクションデータをメモリに保持します。長時間タスクでは保持時間が長くなるため、メモリ使用量が増加し、オーバーヘッドが大きくなります。 長時間実行されるPHPタスクでの高いメモリ負荷 | New Relic Documentation Using the PHP Agent with an application that has long running tasks can cause high memory usage. docs.newrelic.com   セキュア情報が含まれるログの扱い ログに個人情報や認証に関わるデータが出力されていないかを確認する必要があります。New Relicのプラットフォームはデータ転送は暗号化され、データ保存はセキュアな環境で管理されていますが、個人情報や機密データはNew Relicに送信しないよう対処する必要があります。 Data privacy with New Relic | New Relic Documentation Links to detailed information about how New Relic protects you and your customers' data privacy. Also see our security w... docs.newrelic.com   SQLクエリのリテラル値（文字列や数値）はNew Relicエージェント側で難読化処理したうえで、New Relicにデータを送信します。また、ユーザーがフォームに入力した値はデフォルトで収集対象外となっていますが、ログに出力される場合はマスキングや該当ログは転送除外設定が必要です。   Security and transaction traces | New Relic Documentation An explanation of the data security features for transaction traces in APM. docs.newrelic.com   データ転送量の増加 必要に応じて取得するデータ量の調整が必要となる場合があります。PHPエージェントに限らず、APMを導入すると、アプリケーションのトランザクション、エラー、SQLに加え、複数のサービスやシステムを経由するリクエストの流れを追跡する分散トレーシング機能が有効になります。そのため、New Relicへ送信されるデータ量は増加します。   PHPエージェント導入手順 PHPエージェントを導入すると、アプリケーションのレスポンス時間やデータベースのクエリの詳細を可視化でき、問題の特定や改善が容易になります。本手順では、Linux環境へエージェントのインストールから設定までの流れを説明します。 PHPエージェントのインストール方法(Linux) PHPエージェントのインストール方法は以下が用意されています。 方法 説明 On a host (CLI) New Relicが提供するインストールスクリプトをコマンドラインで実行して導入する方法。CLIで手動実行。 On a host (tar archive) 汎用的なインストール方法。tarファイルを展開して手動で設定する。パッケージ管理を使わない。 On a host (package manager) Linuxのパッケージ管理ツール（aptやyum）を使ってインストール。依存関係の自動解決やアップデートが容易。自動更新を有効にすると互換性リスクあり。 Docker Dockerコンテナ内でエージェントをインストール。コンテナ化されたアプリケーション向け。 Kubernetes Kubernetesクラスタにエージェントを導入。Podやノードの監視に対応。 Ansible,Chef,Puppet 構成管理ツールで自動化による導入。   PHPエージェントのインストール手順(Linux) PHPエージェントのインストールをCLI形式で実行した場合は、Infrastructureエージェントのインストールも同時に行われます。PHPエージェントインストール後は、設定ファイルを編集する必要があるため、その反映にはWEBサーバーの再起動は再度必要になります。インストール作業は、WEBサーバへの既存の監視アラート（死活監視）の無効化や再起動によるサービス影響を確認した上で実施してください。 1.「Integrations & Agents」から、「Guided install」をクリックします。 2.APMのタブをクリックし、「PHP」を選択します。 3.この手順ではOn a host (CLI)で進めます。 4.User keyを入力し、「Continue」をクリックします。 5.「Copy to clipboard」をクリックします。 6.対象のサーバにログインし、コピーしたコマンドを実行します。途中、APMの名前を入力する箇所がありますので、任意の名前を入力します(後ほど名前変更可能です)。 7.WEBサーバの再起動の許可を選択する画面が表示されます。後から再起動する場合は、Nと入力します。本手順ではYで進めます。 8.PHPエージェントのインストール許可を選択する画面が表示されます。Yを入力します。 9.実行後、以下の赤枠でinstalledとなっていることを確認します。 10.項番5の画面で「Continue」をクリックします。New Relicと通信状態が表示されます。導入環境によって表示項目は異なります。Apacheへの導入は「Install Apache」をクリックします。 11.「Guided」をクリックします。 12.同様にUser keyを入力後に表示されるコマンドをコピーし、対象のサーバーで実行後、以下の赤枠が表示されていることを確認します。 13.New Relicとの通信確認でApacheがinstalledとなっていることを確認します。「See your data」をクリックします。本記事ではAWSとのインテグレーション設定はスキップします。 14.APMのサマリー画面が表示され、収集されたデータを確認することができます。   PHPエージェントのインストレーション概要 | New Relic Documentation Overview of installing the New Relic PHP agent for RedHat, CentOS, Ubuntu, or Debian, or for the tar archive. docs.newrelic.com   Apache monitoring integration | New Relic Documentation Apache monitoring integration docs.newrelic.com   設定ファイルの編集 設定できる内容が多いので、基本設定やデータ削減に関係のある個所のみを主にピックアップして下記にデフォルト値を記載しています。設定ファイルを編集後はWEBサーバーの再起動が必須になります。PHPエージェント導入後、データ転送量が増大している場合は、必要に応じて設定値を調整する必要があります。 設定ファイル：/etc/php.d/newrelic.ini   機能カテゴリ 設定項目 意味 基本設定 newrelic.enabled = true エージェントの有効化（falseで無効）   newrelic.license = “*********************NRAL” New Relicライセンスキーの設定 環境変数で外出しが望ましい   newrelic.appname = “アプリケーションの名前” APM上で表示するアプリケーション名 ログ設定 newrelic.loglevel = “info” PHPエージェントのログ出力レベル（info, debugなど）   newrelic.daemon.loglevel = “info” デーモンのログ出力レベル エラー収集 newrelic.error_collector.enabled = true PHPエラーの収集を有効化 ブラウザ監視 newrelic.browser_monitoring.auto_instrument = true HTMLにブラウザ監視スクリプトを自動挿入 トランザクション詳細 newrelic.transaction_tracer.enabled = true トランザクション詳細トレースを有効化   newrelic.transaction_tracer.threshold = “apdex_f” トレース対象の閾値（例：apdex_f）   newrelic.transaction_tracer.slow_sql = true 遅いSQLクエリの収集を有効化   newrelic.transaction_tracer.stack_trace_threshold = 500 スタックトレースを取得するSQLの閾値（ms）   newrelic.transaction_tracer.explain_enabled = true SQLのEXPLAINを有効化   newrelic.transaction_tracer.explain_threshold = true EXPLAINを実行するSQLの閾値（ms） イベント設定 newrelic.transaction_events.enabled = true トランザクションイベントの有効化   newrelic.custom_events.max_samples_stored =  カスタムイベントの最大保持件数 ログ収集 newrelic.application_logging.enabled = true アプリケーションログ収集を有効化   newrelic.application_logging.forwarding.enabled = true アプリケーションログをNew Relicへ転送を有効化 PHPエージェントの設定 | New Relic Documentation New Relic PHP agent configuration: How to edit newrelic.ini config settings (like app name, slow traces, parameters, log... docs.newrelic.com   UIから設定できる項目もあります。UI上から設定した場合、エージェント設定ファイルと競合する箇所は上書きされ、UIの設定が優先となりますが、 PHPの場合は例外とされています。 サーバーサイドのエージェント設定 | New Relic Documentation New Relic APM server-side config lets you manage some agent settings from the New Relic side, instead of the agent confi... docs.newrelic.com   ユーザ体験の可視化指標：Apdex アプリケーションのパフォーマンスに対するユーザー体験を数値化する指標としてApdexがあります。1.0に近いほど、ユーザー体験は問題ないとされています。以下についてはベンダーごとに評価基準は異なります。 Apdex 値の範囲 評価（ Rating） 0.94 ～ 1.00 Excellent（非常に良い） 0.85 ～ 0.93 Good（良い） 0.70 ～ 0.84 Fair（普通） 0.50 ～ 0.69 Poor（悪い） 0.00 ～ 0.49 Unacceptable（許容外）   Application Performance Index – ApdexTechnical Specificationの資料によると、計算式については以下と定義されています。 Apdex(T) = (Satisfied count + (Tolerating count ÷ 2)) ÷ Total samples 不満と感じるのは満足の閾値から4倍の値と上記資料で報告されています。計算する際は満足・許容・不満の3つのカテゴリに分けられています。 満足（Satisfied）      ：レスポンスタイム ≤ T 許容（Tolerating）    ：T < レスポンスタイム ≤ 4T 不満足（Frustrated）：レスポンスタイム > 4T 実際の計算式についてNew Relicの公式サイトを参考に算出します。今回、外形監視を例に、ログインからログイン完了後のページを表示する際に満足できるレスポンスタイムを3秒(=T)とします。デフォルトではApdex Tの値が0.5秒となっています。 満足（Satisfied）      ： レスポンスタイム ≤  3秒 許容（Tolerating）    ：3秒 < レスポンスタイム ≤ 12秒 不満足（Frustrated）：レスポンスタイム > 12秒   100回測定した結果が以下となったとします。 満足数：60回 許容数：30回 不満足 :10回 これらを先ほどの式に当てはめてみると、Apdex(T3)=(60+(30÷2))÷100 =0.75となりました。0.75はApdexの範囲で示すと”普通”に該当します。ただし、この基準はあくまで目安です。ユーザー体験はレスポンスタイム以外にもユーザーインタフェースのわかりやすさや、機能の充実度などにも影響します。普段とは大きくApdexスコアが下がっているなど、傾向と合わせて確認することで効率的に活用できます。 デフォルト値で設定されているtransaction_tracer.threshold = “apdex_f” の場合、上記の結果では不満足の10 件(12 秒を超えているもの)がトランザクショントレース対象になります。10件すべてを記録するわけではなく、1分間の収集サイクルで閾値を超えたものをプールし、最も遅い1件だけをトレースとして記録しています。 参考: https://www.apdex.org/index.php/documents/   Apdex：ユーザー満足度の測定 | New Relic Documentation New Relic uses Apdex to measure whether users are satisfied, tolerating, or dissatisfied with your app's response time. docs.newrelic.com トランザクショントレースの概要 | New Relic Documentation In APM, transaction traces record in-depth data from your application's slowest HTTP requests and database queries. docs.newrelic.com   トラブルシューティング New RelicのPHPエージェントは、バックグラウンドで動作するnewrelic-daemonプロセスにデータを渡します。このデーモンがデータを集約し、New Relicのプラットフォームへ送信する仕組みです。エージェント関連で問題が発生した場合は、状況に応じて以下のログを確認します。 状況・問題 確認するログ ログで確認するポイント 次のアクション New Relicにデータが送信されない newrelic-daemon.log ・daemonが起動しているか ・サーバーへの接続エラー ・キューが溜まっていないか ・daemonを再起動 ・ネットワーク疎通確認 ・Proxy設定確認 ・アクセス権の確認 PHPアプリのメトリクスがNew Relicに表示されない php_agent.log ・エージェントが正しく読み込まれているか ・設定ファイル読み込みエラー ・php.ini設定確認 ・PHP再起動   New Relic デーモンのプロセス | New Relic Documentation Information about daemons for New Relic PHP agent installations prior to 3.0. docs.newrelic.com   データが表示されない（PHP） | New Relic Documentation Start here if your encounter problems with your New Relic PHP agent installation. docs.newrelic.com   エージェントの再送処理 エージェントは、トランザクション、エラー、カスタムイベントなどのデータを即時送信せず、メモリに一時保持します。その保持したデータを定期的にNew Relicのコレクターへ送信するタイミングをハーベストサイクルと言います。この仕組みにより、アプリへの負荷を防ぎ、New Relicとの通信を効率化させています。いずれもメモリ上限やイベント種別ごとの制約により、すべて送信されるわけではありません。 データ内容 再送 理由 トランザクションイベント 〇 メモリに保持し、ハーベストサイクルで送信。 エラーイベント 〇 メモリに保持し、再送可能。 カスタムイベント 〇 最大30,000件/分（newrelic.custom_events.max_samples_storedで調整可）。HTTPリクエストが1MBを超える場合は破棄。New Relicに送信できるイベント数は833件/5秒 のため、イベント数によってはすべて送信されずサンプリングとなる場合あり。 スパンイベント（分散トレーシング） 〇 再送可能。上限超過分は破棄。 メトリクス（レスポンスタイム等） 〇 集計値をメモリに保持し、再送可能（CPU,メモリなどのインフラメトリクスは再送不可）。 ログ（ログフォワーディング） × リアルタイム送信のみ。通信切断時は保持されない。 Event limits and sampling for APM and mobile monitoring | New Relic Documentation How APM and mobile agents limit the reporting of events and perform sampling when those limits are exceeded. docs.newrelic.com   APM: Report custom events and attributes | New Relic Documentation How to report APM custom events and attributes in New Relic. docs.newrelic.com   PHPエージェントの更新 最新の技術を使うためにはエージェントの更新が必要となってきます。更新により、最新のセキュリティ対策やパフォーマンス改善が適用され、より正確な計測や新機能の利用が可能になります。古いバージョンを使い続けると、互換性の問題やサポート切れによるリスクが生じるため、定期的な更新が重要になります。   PHPエージェントの更新 | New Relic Documentation How to update your APM PHP agent, and notes on EOL support for early agent versions. docs.newrelic.com   PHP agent release notes | New Relic Documentation PHP agent release notes docs.newrelic.com   さいごに この記事では、分散トレーシングの機能とPHP環境へのAPM導入手順、設定について解説しました。分散トレーシングは奥が深く、実際の障害対応や運用を通じて理解をさらに深め、設定をブラッシュアップしていくことが重要です。今回はPHP環境を紹介しましたが、今後はJavaなど他言語への導入方法ついても、より幅広い環境での可観測性向上の一助となる情報を目指していきます。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

こんにちは、SCSKの嶋谷です。 サーバを監視する際には、監視項目と検知条件を決定する必要があります。 監視項目はCPUやメモリ、ログといったように監視項目のイメージが湧きやすいと思います。 これら監視項目に対する検知条件を皆さんは即座に決定することができるでしょうか。 長年サーバ監視の業務に携わっている方であれば、経験則から一般的な設定値を理解しているでしょう。 しかし、経験が浅い方は「CPUはどれくらいになれば異常と判断すればよいのだろう」と即座に判断することが難しいと思います。 Mackerelには、正常時の状態を学習し、異常を検知した際にアラートを発生させる「ロール内異常検知」という機能があります。 今回、この機能が検知条件を決める際の手助けになると考え、実際にロール内異常検知の挙動を確認しました。 ロール内異常検知とは ロール内異常検知は、 機械学習 を用いて学習した正常なパターンから外れたメトリックの経過を異常と判断し、アラートを発生させる機能です。指定されたロールに含まれるサーバの過去のメトリックを学習し、正常な動きのパターンを認識します。 ロールに属するサーバのメトリック(CPU、メモリ、ディスク)を過去数十日分学習し、混合ガウス分布を用いて正常/異常の判定を行います。混合ガウス分布を用いることで、昼夜・平日・週末のように「負荷の波があるパターン」でも対応が可能です。 ロール内異常検知のメリットを下記に記載します。 複雑な監視ルールの設定が不要 ロール内のメトリックデータを機械学習で自動的に学習して正常時の状態を把握するため、 ユーザ自身で細かな閾値を設定する必要がありません 。 閾値の調整やメンテナンスの手間が少ない サーバの特性変化に応じて手作業で検知条件を更新する必要がなく、学習モデルは日々更新される仕様となっています。 そのため、メンテナンスの頻度が減少します。 サーバ監視の初心者でも導入しやすい 専門知識が無くても、簡単な設定で異常検知を実装することが可能です。 詳細は下記をご参照ください。 混合ガウス分布（GMM）の意味と役立つ例 – 具体例で学ぶ数学 ロール内異常検知による監視をおこなう – Mackerel ヘルプ 設定手順 構成 今回の記事ではAWSのEC2を2台を作成して、同じロールに含めて検証を実施しました。 ロール内に含まれるサーバのメトリックデータをMackerelに送信し、Mackerelでロール内異常検知の設定を組み込みことで簡単に異常検知を実装することができます。 設定方法 Mackerelコンソールの監視ルールタブを選択し、「監視ルール追加」をクリック ロール内異常検知をクリック 下記情報を入力 ・対象のロール：監視するロールを選択 ・センシティビティ：検知する変化の粒度を選択(sensitive、normal、insensitiveから選択) ・最大試行回数：アラート発生条件の異常状態継続回数 「作成」をクリック 今回私が作成した設定の一例を下記に示します。 今回は小さな変化も検知できるようにセンシティビティを「sensitive」に設定しています。 ※ロール内異常検知では、エージェントが収集するシステムメトリック全体を学習の対象としているため、 学習対象を個別のメトリックに絞り込むことはできません 。メトリックについては下記をご参照ください。 メトリック仕様 – Mackerel ヘルプ 監視ルールが作成されると、機械学習による学習が開始されます。 学習中は作成した監視ルールに赤いチェックマークが表示され、完了すると緑のチェックマークが表示されます。 これにより、設定が完了し異常検知を実施することができます。   異常検知検証 今回はCPU、Memory、Diskにそれぞれ負荷を与え、ロール内異常検知の挙動を確認しました。 検証に用いたサーバは検証用に作成したため、サーバ上にアプリケーションなどは構築していません。そのため、CPUやMemoryは常時低負荷の状態で推移しています。 CPU 下記コマンドでサーバ1台に対して、CPU使用率が100%で5分間推移するように負荷を与えてみるとアラートが発生しました。 stress-ng --cpu 0 --cpu-load 100 --timeout 5m 発生したアラート内容は以下となります。常時0%の状態から負荷を与えることで通常時とは異なると判断してアラートが発生しました。 掲載している図は100%で負荷を与えた場合ですが、60%や80%の負荷を与えた場合でも同様にアラートが発生しました。 CPUの中でもcpu.user.percentage（アプリケーションがCPUを利用した割合）が高騰しています。 Memory 下記コマンドでサーバ1台に対して、Memory使用率が60%で5分間推移するように負荷を与えてみるとアラートが発生しました。 stress-ng --vm 1 --vm-bytes 60% --timeout 5m 発生したアラート内容は以下で、Memory使用率ではなくCPU使用率でのアラートが発生しました。 疑問に思い、ヘルプページを確認してみると以下の記載がありました。 「ロール内異常検知によるアラートでは、該当ホストで普段と最も様子が異なるメトリックのグラフを表示します。各種通知でもこのグラフが表示されるので、障害の初期対応に活用できます(必ずしも障害の根本原因を表わしているというわけではありません)。」 つまり、Memoryに負荷を与えた際に CPU 使用率が 100% 程度まで上昇したため、Memory高騰よりも CPU 高騰が通常と最も異なる挙動として判定されました。その結果、CPU 使用率の高騰でアラートが発生したようです。 Disk 下記コマンドでサーバ1台に対して、Disk使用率が60%で5分間推移するように負荷を与えてみるとアラートが発生しました。 stress-ng -d 1 --hdd-bytes 4G --temp-path パス --timeout 5m 発生したアラート内容は以下で、CPU使用率の高騰でした。こちらもMemoryでの検証と同様にDisk使用率の高騰と共にCPU使用率も高騰してしまい、CPU使用率の高騰が通常と最も異なると判定されています。 また、CPUの中でもCPU・Memoryの検証で高騰していたcpu.user.percentageとは異なり、cpu.iowait.percentage（ディスク・ネットワーク I/Oの完了待ちでアイドル状態になっている割合）が高騰しています。 CPU・Memory・DiskでCPUアラートが発生しましたが、具体的に高騰している値は異なるものでした。 2台同時に負荷をかけた場合 構成図で示した通り、今回はロール内に2つのサーバを含めています。 これまでは1台のみに負荷を与えることで検証実施しましたが、ここでは2台同時に負荷をかけた場合の挙動について確認します。 下記のコマンドで、1台のみで検証したDiskとは異なるDiskに負荷を与えました。 stress-ng -d 1 --hdd-bytes 8M --temp-path パス --timeout 5m 結果としては、異なるアラートとして2台それぞれでアラートが発生しました。メトリックのグラフ推移としては同様の推移となっております。 ただ、今回高騰しているCPUのメトリックはcpu.system.percentage（カーネルが使用している割合）で、負荷を与えるDsikによっても挙動が変わることに驚きました。ホスト単位でアラートが発生することで、異常状態のホストを見逃すことはないと感じました。 小話 今回のブログを書くにあたり、まず検証でアラートが発生することを確認しました。 この際に、結果のスクリーンショットは撮影していませんでした。 ブログ執筆のため、同様の事象でアラートを発生させようとするとアラートが発生しませんでした。 1/10と1/20に下記コマンドを実行すると、1/10ではアラートが発生し1/20では発生しませんでした。 stress-ng --cpu 0 --cpu-load 100 --timeout 5m --metrics はてな社に問い合わせてみると、学習モデルは定期的に更新されているようで、1/10時点での学習モデルと1/20時点での学習モデルは同じものではありませんでした。1/20の学習モデルは検証で負荷を与えたメトリックデータを含んで学習されていたため、同じ事象(正常)とみなしてアラートが発生しなかったようです。 新しくサーバを作成して同様の事象を発生させることが必要でとても苦労しました。 ただ、学習モデルが自動的に日々更新される点はとても便利な機能だと感じました。 まとめ 今回はMackerelのロール内異常検知の機能に触れてみました。 サーバへ急激に負荷を与えると、正しく異常が検知されたのでAIのすごさも再認識しました。 ヘルプページにも記載されている通り根本原因を検知できるわけではないので、使い方が重要だと感じました。 ロール内異常検知は 正常時と異なる挙動を検知する機能 ですので、導入部分で触れた閾値決定の手助けで利用するのは難しいと感じました。また、学習モデルに使用されるデータは過去数十日のため、月一回の定期作業で発生する負荷を異常として判断する可能性もあります。 そのため別の用途として、サーバの挙動が変化したことに気付き、根本原因調査の足掛かりとして利用できるのではないかと感じました。 ただ、今回は実運用で使用しているサーバを対象としていないため、今後は実運用のサーバでの挙動も確認して利用用途考えていきたいです！ 最後までお読みいただきありがとうございました！

本記事では、ServiceNowのフローで使用できるレコード操作関連のアクションについて紹介します。 レコード関連のアクションについて Create Record 指定したテーブルにレコードを作成するアクション。 テーブルの各フィールド値の指定は基本的に任意ですが、必須のフィールド値については指定が必要となります。 Look Up Record 指定したテーブルから条件に合致するレコードを1件取得するアクション。 ※ 条件に合うレコードが複数ある場合は、最初の1件のみを返します。 複数取得したい場合は「Look Up Record s 」を使います。 Update Record 指定したレコードの指定したフィールドの値を更新するアクション。 Delete Record 指定したテーブルの指定したレコードを1件削除するアクション。 使い方 準備 事前にIncidentテーブルに更新用と削除用のレコードを2つ作成します。 Short descriptionは、Before update、Before deleteとします。 フローを作成 検証用のフローを作成していきます。 新しいレコードを作成するアクション「Create Record」を追加。 事前に作成しておいた更新用レコードを検索するアクション「Look Up Record」を追加。 レコードを更新するアクション「Update Record」を追加。 更新するレコードに手順2で取得したレコードを指定。 事前に作成しておいた削除用レコードを検索するアクション「Look Up Record」を追加。 レコードを削除するアクション「Delete Record」を追加。 削除するレコードに手順5で取得したレコードを指定。 フローを実行 「Save」を押下して保存してから、「Test」を押下してフローを実行します。 結果を確認 Incidentテーブルを見ると、フローで作成したレコード（Short description: Successfully created）が追加されており、更新用レコードのShort descriptionがBefore updateからSuccessfully updatedに更新されています。 また、削除用レコードが削除されています。 まとめ 本記事で、ServiceNow上でレコードの新規作成から取得・更新・削除までの基本操作をフローから実行する方法を理解できたと思います。これらのアクションを活用することで、レコード管理業務の効率化や、業務フローの自動化が簡単になります。 実際の業務に応じて他のアクションと組み合わせて、より複雑な処理や通知などにも発展させることができますので、今後のサービス開発や運用効率化にぜひ役立ててください！

こんにちは、SCSKの小川です。 パブリッククラウドが主流となる中、いまだオンプレのシステム稼働の需要は高く、お客様環境に個別の仮想基盤が多く稼働しています。 そのため、VMware問題に悩むお客様も多く、新たな仮想基盤へのリプレースの提案依頼が増えてきています。 今回は、新たなオンプレ仮想基盤ソリューションとして、everRunを紹介します。 VMware以外の仮想基盤ソリューションをご検討中の方は、ぜひご確認ください！   everRunとは everRunはStratus社が提供する高信頼性仮想化システムを実現するソフトウェアソリューションです。 ●everRunシステム構成イメージ everRunの最大の特徴は、仮想マシン毎に設定した保護レベルが設定できることです。 最も信頼性を高める「Fault Tolerant（FT）構成」の場合、 仮想マシンを「無停止」「無瞬断」で稼働 させられます。 ＜設定可能な保護レベル＞ 仮想マシン毎に以下の3つの保護レベルから選択可能 FT（Fault Tolerant）　CPUステータス・メモリ同期 / HDD同期 / ネットワーク冗長化 HA (High Availability）  HDD同期 / ネットワーク冗長化  ※CPUステータス・メモリ同期は行わない 無し      　　　　　　　（障害時仮想マシンは停止）   everRunの採用ポイント 一般的な仮想基盤ソリューションの比較結果を以下に記載します。 製品比較表（ 筆者の見解）   品名 製品タイプ 主な特長・機能 可用性／冗長性 運用管理 サポート体制 ライセンス／価格 VMware vSphere/ESXi ハイパーバイザー型 仮想化ソフトウェア 業界標準・高い安定性、多機能性、 高度な管理、仮想ネットワークや ストレージ連携 vMotion/HA/DRSなど 多彩な冗長・可用性機能、 ホスト構成2台～ vCenterによる集中管理 ○⇒ ？(見直し中) グローバル・国内とも充実 ○⇒ ？(見直し中) サブスクリプション （最近体系が変更） Microsoft Hyper-V ハイパーバイザー型 仮想化ソフトウェア Windows OSと統合、 シンプルな運用、コスト効率、 Active Directory連携 クラスタ―構成、 ライブマイグレーション、 ホスト構成2台～ SCVMMなど管理ツール △ Microsoft標準 サポート ◎ Windows Serverライセンス含む Nutanix AHV ハイパーコンバージド インフラ（HCI） ※KVMベース 仮想化＋ストレージ＋ネットワークが一体化、スケーラブル、 運用自動化 分散ストレージ、 障害時自動復旧、 ホスト構成3台～ Prismによるシンプル管理 ○ Nutanixから一元サポート × ハード＋ソフトサブスクリプション Stratus everRun フォールトトレランス 仮想化ソフトウェア ※KVMベース サーバ障害時の自動切替・ゼロダウン、追従型ハードウェア冗長 完全な冗長化、ミラーリング、 ホスト構成2台／セット Webベース管理ツール ○ Stratus社サポート ○ ノード数による ライセンス 凡例 赤字：主な留意点 everRunの採用ポイント 強み：シンプルな構成・運用、専用の管理ツールによる分かりやすい操作性、低コストな導入・運用を実現します。 弱み：1対1の2台構成 　　　⇒ VMwareのようなN対1構成による拡張性が無いため、原則小規模単位の導入を推奨します。   お客様の声 ＜お客様の業種：製造業＞ システム要件で自社サーバ室でVMware環境を運用していたが、VMware問題に伴いサポート体制やコストに不安を感じていました。 そのため、HWの保守切れに伴いVMware以外の仮想基盤にリプレースを検討していた。 everRunを知らなかったため初めは抵抗感を感じたが、丁寧な製品紹介を聞いた結果、以下の理由でeverRunの採用を決定しました。 　①KVMベースのため、他社製品と主要機能の範囲では大きな差は無いと感じた。 　②工場系システムに対して、VMwareの可用性を超えるFT環境を、容易にかつ安価に導入することができる。 　③国内の導入事例も多い。（国内600件以上の導入実績）   さいごに everRunは、VMwareのコストやサポート面への不安を背景に、国内でも着実に採用が進む新たな仮想化基盤の選択肢です。 特に小規模で高可用性が求められる現場、限られたITリソースでシステムを安定稼働させたいお客様におすすめです。 オンプレ仮想環境の継続活用にお悩みの方は、ぜひご検討ください。 詳しい内容をお知りになりたいかたは、以下のメールアドレスにご連絡ください。 お問い合わせ： west-marketing-info@scsk.jp

SCSKの畑です。 前回のエントリ に引き続き、今年度のアプリケーション性能改善の取り組みについて説明していきたいと思います。今回はテーブルデータのバリデーションチェック機能の性能改善について説明していきます。   はじめに テーブルデータのバリデーションチェック機能についての背景や概要については、昨年度投稿したエントリで一通り説明していましたので詳細はこちらをご覧頂ければと思います。 Amazon Redshift テーブルのデータメンテナンス機能についての補足その2 案件事例にて実装したアプリケーションの Redshift テーブルのデータメンテナンス機能に関する補足その2です。データメンテナンス機能の対象となる Redshift の特性を踏まえた上で、アプリケーションの実装において考慮する必要があったポイント及び機能について記載しました。 blog.usize-tech.com 2025.02.25 簡単に本稿でも説明すると、本アプリケーションを使用して Redshift のテーブルを更新する際にデータの整合性を担保する目的で、テーブル定義に基づく各種制約（列のデータ型定義によるものや NOT NULL制約、PK/UK/FK 制約） をアプリケーション側でチェックするための機能です。特に PK/UK/FK 制約については Redshift 上で制約として機能しないことから、テーブルデータを更新する前にアプリケーション側でチェックできないと制約に反するデータを更新できてしまうため、データの整合性を担保する観点において重要な機能でした。 具体的な実装としては、こちらも前回のエントリで取り上げている tabulator というテーブルデータを取り扱うためのライブラリの組み込み機能をそのまま使用していました。ただ、複合キーによる PK/UK や FK 制約についてはさすがに用意されていなかったため、自前で実装したものをライブラリの組み込み機能にカスタムバリデータとして組み込むことで実装しました。 Tabulator - Data Validation Validate user entered data before accepting it into the table tabulator.info このバリデーションチェックは Redshift 上のテーブルに更新を反映する前の事前チェックとして、編集中のデータに対して画面上で実行されますが、特にデータ量の大きいテーブルでの所要時間が大幅に伸びるケース（最大10分程度）が散見されるようになりました。数分程度ならまだしも10分を超えてくるようなら改善して欲しい旨お客さんからも打診頂き、改善に向けて取り組むことになりました。   今回の取り組みに至った原因とその背景 前回エントリとほぼ同じなのですが、「 本アプリケーションで扱うテーブル（定義・データ）の長大化 」が主な原因でした。 テーブル定義に従ってデータのバリデーションチェックをする以上、対象データの増加に伴い計算量が増えるのは自明なことです。また、扱うテーブルの定義自体も昨年度のアプリケーションリリース時からすると相対的により複雑化・長大化の傾向があり、テーブルの列や制約の数が増えることでバリデーションチェックの対象も増加し、最終的には同じように計算コストの増加に繋がってしまいました。   実装上の問題点 こちらも前回エントリの問題点と概ね同じで、先述した通り tabulator の組み込み機能を使用していることでした。昨年度リリース時点のテーブル定義やデータ量でテストした限りだと、一番データ量の大きなテーブル（数万行）でも十数秒だったのですが、場合によっては数分〜十分程度を要するようになってしまいました。 tabulator 標準のバリデータを使用している処理もあったので、当初はそれも含めて全てカスタムバリデータに変更することで改善できないかとも考えたのですが、tabulator 標準のバリデータでチェックしている内容は相対的に単純で工夫の余地が少なそうだったため、tabulator の組み込み機能ではなく バックエンド側にバリデーションチェック処理を移管する方向性 で検討することにしました。 バックエンドに処理を移管することで、フロントエンド（tabulator）で処理していた場合と比較してデータ量の少ない/シンプルな定義のテーブルについてはトータルの処理時間が伸びてしまうケースもあります。ただ今回のケースではデータ量の多い/複雑な定義のテーブルについて処理時間を短縮すること（スループットを改善すること）がゴールであったため、そちらを優先しました。 また、本機能は実質的にオンラインバッチであるため、今まで（非常に）短かった処理時間が少々長くなったとしても機能要件は満たしていた（相対的にユーザに受け入れられやすかった）という点もあったと思います。前回のエントリで取り上げた更新差分情報の表示については、バックエンド側で更新差分の計算をした上でそれをフロントエンドで表示する処理が重かったためレスポンスの改善自体がゴールであり、本件とは少し事情が異なりました。   改修の方向性 さて、本件については改修の方向性は最初からはっきりしており、具体的には 個々のデータバリデーションを並列実行すること で処理時間を短縮するアプローチを考えていました。以下2点が主な理由です。 個々のバリデーションチェック（データ型定義や NOT NULL/PK/UK/FK 制約）はそれぞれ独立しており、支障なく並列実行可能であることから高速化が期待できる バックエンドに処理を移管することでバックエンド側の計算リソースをフル活用可能 特に2点目はフロントエンドから処理を移管する大きな理由となりました。仮にフロントエンド（tabulator）の機能でバリデーションチェックの並列化が可能だったとしても、それによりクライアントの計算リソースをフル活用することになってしまうため、それはそれで支障があったものと思います。例えば Web ブラウザからページ内処理が重くなってしまっている旨の警告が出る、Web ブラウザ側で処理を中断されるなどの可能性があると考えました。 本アプリケーションによるバックエンド処理は基本的に Lambda （Python）で実装しているので、新しくバリデーションチェック用の Lambda を作って並列実行すれば良いかなとこの時点では楽観的に考えていたのですが・・   Lambda における並列実行の問題点と解決策 Python における並列実行はマルチスレッドとマルチプロセスの2種類がありますが、バリデーションチェックに必要な計算処理の特性（基本的には CPU バウンド）を考えるとマルチプロセス一択でした。よって、まず ProcessPoolExecutor を使用したマルチプロセスによる並列実行のプロトタイプを Lambda 上で動かしてみたところ、以下のようなエラーが出てしまいました。 { "errorMessage": "[Errno 13] Permission denied", "errorType": "PermissionError", "requestId": "4e125fb8-8d71-47f3-b70c-91e37f2023df", "stackTrace": [ " File \"/var/task/lambda_function.py\", line 5, in lambda_handler\n main()\n", " File \"/var/task/lambda_function.py\", line 16, in main\n with ProcessPoolExecutor(max_workers=4) as executor:\n", " File \"/var/lang/lib/python3.11/concurrent/futures/process.py\", line 732, in __init__\n self._call_queue = _SafeQueue(\n", " File \"/var/lang/lib/python3.11/concurrent/futures/process.py\", line 173, in __init__\n super().__init__(max_size, ctx=ctx)\n", " File \"/var/lang/lib/python3.11/multiprocessing/queues.py\", line 43, in __init__\n self._rlock = ctx.Lock()\n", " File \"/var/lang/lib/python3.11/multiprocessing/context.py\", line 68, in Lock\n return Lock(ctx=self.get_context())\n", " File \"/var/lang/lib/python3.11/multiprocessing/synchronize.py\", line 169, in __init__\n SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)\n", " File \"/var/lang/lib/python3.11/multiprocessing/synchronize.py\", line 57, in __init__\n sl = self._semlock = _multiprocessing.SemLock(\n" ] } んー？プロトタイプレベルの実装なんだからコードに間違いはないと思うし、そもそもエラーの内容が良く分からないな・・と思いながら調べてみたところ、本事象に該当する情報が AWS 公式含めてゴロゴロ出てきました。要するに、 ProcessPoolExecutor は共有メモリ（/dev/shm） 経由で親子プロセス間の通信や管理を行うが、Lambda がそれをサポートしていないため実行できない というのが理由のようでした。 Parallel Processing in Python with AWS Lambda | Amazon Web Services If you develop an AWS Lambda function with Node.js, you can call multiple web services without waiting for a response du... aws.amazon.com マルチスレッドは使えるものの、先述の通り CPU バウンドな処理の高速化は原理上望めない＆試したみたところ想定通りの結果となったためどうしたものかと思っていたのですが、Web 上の情報を色々調べていくと共有メモリ（/dev/shm） を使用しない実装でマルチプロセス処理を実現している例も複数見受けられたことから、それらの情報を参考にさせて頂きつつ自前で実装することにしました。具体的には、 multiprocessing.Process により子プロセスを生成の上、multiprocessing.Pipe （パイプ）により親子プロセス間で通信して各種情報のやり取りを行うような方式 となります。上記の AWS 公式 URL でも同じような方式が記載されていました。 ちなみに 他のクラウドサービスにおける同等のサービス（CloudRun Function (GCP)、OCI Functions (OCI)）では使用できました。これらのサービスが動作しているアーキテクチャ（実行環境）の差異に起因しているものと思います。 以下、各構成要素における実装例を記載していきます。   バックエンド (Amplify/AppSync) 先述の通り元々はフロントエンド（tabulator）で完結していたため新規実装になっています。ただ、バリデーションチェック結果を画面表示するために必要な情報（フォーマット）は現行のフロントエンド実装より明らかであり、かつ変更の必要はなかったため、スキーマ設計をフロントエンド実装に合わせるような形となりました。 enum ValiType {   PK   UK   FK   NOT_NULL   DATA_TYPE_INT   DATA_TYPE_CHAR   DEL_FLG } type ValiInfo {   type: ValiType!   columns: [String!]! } type ValiResult {   index: Int!   info: [ValiInfo!]! } 内容についても簡単に説明します。 バリデーションチェックの結果として、テーブル定義に基づく各種制約に違反している行の情報が ValiResult の配列に格納される ValiResult には制約違反した特定の行の番号、及びその行に含まれる制約違反の詳細情報の配列が格納される 前回のエントリと同じように、テーブルデータにおける特定の一意な行を取得するために行番号を使用している 制約違反の詳細情報は、制約違反の種類を示す ValiType (enum) と、列名の組み合わせで表現   バックエンド (Lambda) 以下、並列実行部分の一部抜粋です。先述の通り、Lambda における Python マルチプロセス処理の実装方式はほぼ限られていると思われるので特に目新しさはないですが、ちょっとだけ工夫した部分もあるので備忘を兼ねて。。 なお、最終的なバリデーションチェックの結果に行番号が含まれていますが、前回のエントリの内容を対応後に本件に着手したこともあり、以下2点の理由で特に問題なく実装できました。  S3 に一時保存された編集中のデータに対してバリデーションチェックを実施することで行番号を取得できる 画面からバリデーションチェックを実施するタイミングで編集中データを S3 に一時保存するよう、画面側のロジックを微修正 各種制約チェックの実施にあたり表データを DataFrame に格納しているが、編集中のデータから取得した行番号の列（ROW_ID）をindex として指定することで、DataFrame に対する制約チェック結果から直接行番号を導出できる def validation_worker(task_pipe, result_pipe,                      df_serialized: bytes, table_data_info: Dict, fk_reference_data_serialized: bytes):     """バリデーションワーカープロセス（動的タスク取得）"""     try:         df = pickle.loads(df_serialized)         fk_reference_data = pickle.loads(fk_reference_data_serialized)                 func_map = {             'validate_primary_key': validate_primary_key,             'validate_unique_key': validate_unique_key,             'validate_foreign_key': validate_foreign_key,             'validate_not_null': validate_not_null,             'validate_integer_type': validate_integer_type,             'validate_char_type': validate_char_type,             'validate_delete_flag': validate_delete_flag         }                 while True:             # タスクをリクエストして受信（同一Pipeで双方向通信）             task_pipe.send('READY')             task = task_pipe.recv()                         if task is None:  # 終了シグナル                 break                         try:                 # バリデーションタイプに対応した関数を取得                 vali_type, func_name, args = task                 func = func_map[func_name]                                 # バリデーションタイプに応じて関数に渡す引数を変更                 if func_name == 'validate_foreign_key':                     fk_info, ref_data_key = args                     ref_data = fk_reference_data[ref_data_key]                     violations = func(df, fk_info, ref_data)                 elif func_name == 'validate_delete_flag':                     violations = func(df)                 else:                     violations = func(df, args[0])                                 # バリデーションチェック結果を親プロセスに送信                 for violation in violations:                     result_pipe.send({                         'index': violation['index'],                         'info': [{'type': vali_type, 'columns': violation['columns']}]                     })             except Exception as e:                 logger.error(f"Validation task error: {e}")                     except Exception as e:         logger.error(f"Validation worker error: {e}")     finally:         task_pipe.close()         result_pipe.close() def validate_constraints_parallel(df: pd.DataFrame, table_data_info: Dict, fk_reference_data: Dict) -> List[Dict[str, Any]]:     """制約チェックを並列実行（動的タスク割り当て）"""     df_serialized = pickle.dumps(df)     fk_reference_data_serialized = pickle.dumps(fk_reference_data)     tasks = prepare_validation_tasks(table_data_info, df.columns, fk_reference_data)         # バリデーションチェックタスクがない場合は空配列を返して終了     if not tasks:         return []         # ワーカー数決定     num_workers = min(MAX_WORKERS, len(tasks), multiprocessing.cpu_count())         # プロセスとパイプを作成（2種類）     processes = []     task_pipes = []     # ワーカーとの双方向通信用     result_pipes = []   # ワーカーからの結果受信用         # ワーカープロセスの並列起動     for _ in range(num_workers):         task_parent, task_child = multiprocessing.Pipe()         result_parent, result_child = multiprocessing.Pipe()                 task_pipes.append(task_parent)         result_pipes.append(result_parent)                 p = multiprocessing.Process(             target=validation_worker,             args=(task_child, result_child, df_serialized, table_data_info, fk_reference_data_serialized)         )         p.start()         processes.append(p)         task_index = 0     active_workers = num_workers     all_violations = []         # タスク割り当てとバリデーションチェック結収集のループ実行     while active_workers > 0:         # タスク割り当て処理         for i, task_pipe in enumerate(task_pipes):             if task_pipe.closed:                 continue                             if task_pipe.poll(0.01):  # 10msタイムアウトでポーリング                 try:                     msg = task_pipe.recv()                     if msg == 'READY':                         if task_index < len(tasks):                             # 次のタスクを送信                             task_pipe.send(tasks[task_index])                             task_index += 1                         else:                             # 全タスク完了、終了シグナルを送信                             task_pipe.send(None)                             task_pipe.close()                             active_workers -= 1                 except Exception as e:                     logger.error(f"Dispatcher error: {e}")                 # バリデーションチェック結果を並行収集         for result_pipe in result_pipes:             if result_pipe.closed:                 continue             while result_pipe.poll(0):  # ノンブロッキングでポーリング                 try:                     violation = result_pipe.recv()                     all_violations.append(violation)                 except:                     break         # アクティブワーカーが0になった後、残りのバリデーションチェック結果を収集     for result_pipe in result_pipes:         while result_pipe.poll(0.1):             try:                 violation = result_pipe.recv()                 all_violations.append(violation)             except:                 break         result_pipe.close()         # プロセス終了を待機     for p in processes:         p.join()         # バリデーションチェック結果を行番号でマージ/ソートして返却     return merge_and_sort_violations(all_violations) validate_constraints_parallel メソッドがバリデーションチェックを並列実行するためのコーディネータ、validation_worker メソッドがマルチプロセスにより個々のバリデーションチェックタスクを実行するワーカーです。それぞれの内容についても簡単にまとめます。   validate_constraints_parallel いまいまの Lambda の仕様におけるベーシックなマルチプロセス処理の実装は、multiprocessing.Process により生成した子プロセスに対してタスクをラウンドロビンで事前に割り当てることだと思いますが、この場合子プロセスに割り当てられたタスクの内容によって子プロセスごとの処理時間にバラつきが出やすくなる可能性があるため、キューイングにより子プロセスへのタスク割り当てを行っています。 マルチプロセスにおけるキューイング処理のため素直に multiprocessing.Queue などを使用して実装したいところなのですが、先述の通り Lambda で共有メモリ（/dev/shm）がサポートされていないためこちらも使用できません。このため、具体的には親子プロセス間で2つの Pipe を用意し、以下のような用途で使い分けることでキューイング処理を実現しています。共有メモリを使用できる実装と比較するとやや力業というか、厳密には擬似的な実装となってしまいますが・・ 双方向通信用 Pipe（親プロセス ↔ 子プロセス）：task_pipes 親子プロセス間の実行制御に使用 片方向通信用 Pipe（親プロセス ← 子プロセス）：result_pipes 子プロセスで実行したバリデーションチェック結果を親プロセスに返すために使用 双方用通信用 Pipe（task_pipes）については、代わりに片方向通信用 Pipe を2つ用意することでも同等の実装が可能です。実装としてはそちらの方が素直かもしれません。task_pipes を双方向通信用として使用できるのは、（後述するシーケンスの通り）実行制御の過程で子プロセス→親プロセスの通信と親プロセス→子プロセスの通信が必ず交互に行われるため、結果的にデッドロックを防げることが理由です。 その上で、以下のようなシーケンスで処理を実行することで、キューイングにより子プロセスへのタスク割り当てを行っています。 算出された並列度で子プロセスを起動 起動された子プロセスから親プロセスにタスクの割り当て要求シグナルとして「READY」文字列を送信 タスク割り当てを要求後は定期的に task_pipes を polling し、タスク割り当てを待つ 「None」を受信した場合は割り当てられるタスクが残存していないことを意味しているため、子プロセスを終了 親プロセスで task_pipes を定期的に polling し、「READY」が受信できたらタスクのキュー配列からタスクを取り出し、対応する子プロセスに task_pipes 経由でタスク情報を送信（割り当て） 並行して result_pipes も定期的に polling し、子プロセス側で完了しているバリデーションチェックの結果があれば取得 親プロセス側で定期的に result_pipes の中身を取得しないと Pipe のバッファサイズ（64KB）を超過してしまい、子プロセスにおける result_pipes への書き込み（送信）処理がブロッキングされてしまう可能性があるため タスクを割り当てられた子プロセスでバリデーションチェック処理を実行し、結果を result_pipes 経由で送信 結果送信後は 2. に戻り、次のタスク割り当てを待つ タスクのキュー配列に格納されていた全タスクの取り出しが完了次第、各子プロセスに終了シグナルとして「None」を送信 子プロセスで実行中のタスクがあればその完了後に終了、そうでなければ即時終了 全子プロセスの終了後、result_pipes に残存しているバリデーションチェックの結果を全て取得の上、適切なフォーマットに変換して呼び出し元のメインハンドラに返す ちなみに、上記の通り Pipe のバッファサイズ（64KB）超過対策は一応実施していますが、バリデーションチェックの結果として制約違反が極めて大量に発生した場合は超過する可能性は残ります。 ただ、先般のスキーマ定義の通り個々のバリデーションチェック結果の情報量（サイズ）は小さめであること、Pipe のバッファサイズ制限が適用されるのは個々のバリデーションチェックに対してであり、単一のチェック項目のみで大量に制約違反が出る可能性は相対的に低いことの2点より、現時点ではおそらく大丈夫であろうとは思っています。 最も、それ以前の問題として画面側で大量にバリデーションチェック違反が出てしまうことを正直あまり考慮できていないので、仮にそのような事態が発生した場合はおそらく先にそちらから手を入れる必要があるかと思います。。 一応シーケンス図も書いてみましたが、さすがにちょっと面倒だったので Kiro にお願いしてみました。こういう用途に使えるようになったのは本当に便利ですよね・・      validation_worker 個々のバリデーションチェックを実行するために、親プロセスから起動される子プロセス内の実装を記述しています。よって実装内容自体は上記シーケンスで示されている通りとなるため、ここで特筆すべき点は特にありません。 強いて言うなら、親プロセスから引数経由で DataFrame の受け渡しがあるため、その前後で pickle でシリアライズ/デシリアライズしているくらいでしょうか。それから、個々のバリデーションチェックはそれぞれメソッドとして定義しており、親プロセスからは対応するメソッド名のみを受け取っています。   フロントエンド (typescript) こちらは今回の一連の変更前後で実装を変更していませんが、備忘がてら合わせて残しておきます。前回のエントリで言及した内容と同じように rowFormatter コールバックを使用した実装となっており、行番号を使用して制約違反に該当する行を導出し、フォーマット（色）を変更しています。 // テーブルデータ編集時のrowFormatter設定 const ecRowsFormatter = function(row){     // バリデーションエラー行の色付け     // ValidationInfos.value配列のROW_IDと、row.getIndex()が一致する行をフィルタ     const row_vali_info = ValidationInfos.value.filter(info => info.ROW_ID === row.getIndex());     for ( const vali_info of row_vali_info ) {         for ( const cell of row.getCells() ) {             if (cell.getColumn().getDefinition().title === vali_info.col_name){                 cell.getElement().style.backgroundColor = "#fca5a5";                 break             }         }     } } 以上の一連の対応により、データサイズが数万行単位/テーブルの列数が十数個となる大きなテーブルにおいてもバリデーションチェックの所要時間を最大数十秒程度まで短縮することができ、解決と相成りました。   まとめ 本件はバックエンドの Lambda をマルチプロセスで動かせれば解決できるだろうという目論見が割と早くからあったものの、ちゃんとマルチプロセス処理を動かすのに思ったより時間がかかってしまいました。本件に関する Web 上の情報もかなり多いので裏を返すとそれだけニーズがあるようにも思えるのですが、実現に至らないのは Lambda のアーキテクチャ（実行環境）におけるアイソレーション絡みの話あたりが理由なのかなーと思います。 Lambda は水平方向にスケールする思想のサービスというのは認識しているのですが、今回のケースでその思想に素直に従うと、極端な話フロントエンド側が並列処理のコーディネータをするような実装にもなりかねないのがちょっとイマイチだなと思っていて。もちろん現実解は StepFunctions あたりを間に挟むような実装でしょうが、気合を入れてシャードしないといけないような計算コストの高い処理はともかく、今回のようなケースだと正直オーバースペック＆かえって面倒に感じてしまいます。それこそ、その必要性が出てきてからの対応でも遅くないくらいというか。今回のようにちょっと頑張ればマルチプロセスで動かせるだけ全然マシなんですけど、やっぱりもうちょっと楽に実装できたらなあと個人的には思います。。 本記事がどなたかの役に立てば幸いです。

前回、Azure Functionsの開発環境の準備からTimer Triggerを簡単に動かすところまでを実施しました。 【初心者向け】Azure FunctionsでPythonを実行する(Timer Trigger) Azure FunctionsでPythonを実行するための初心者向けのガイドを行います。 開発するために必要な事前準備や、処理の実装を行う箇所や注意点等をわかりやすく整理しています。 blog.usize-tech.com 2026.01.30 続いてHTTP Triggerを試してみます。 機能は少し薄いですが、HTTP TriggerではAzure Functions単体でAPI公開が可能です。 Pythonコード開発 前回の記事の最後から開始します。 HTTP Triggerの追加 「WORKSPACE」の「Local Project」で⚡のマークを押します。 HTTP Triggerを選択します。 既にある「function_app.py」の中にHTTP Triggerを追加するので、「Add http Trigger function to an existing file」を選択します。 作成する関数名を指定します。 特にこだわりが無ければデフォルトでOKです。 承認レベルは「ANONIMOUS」とします。 自動でHTTP Triggerを「function_app.py」に追加してくれます。 処理実装 作成されている「function_app.py」の中に処理を実装していくことになります。 赤枠の部分に実装していきましょう。 注意 @app.routeが、HTTP実行をつかさどる部分になりますので、この行は削除NGです。 URLのパスを変更したい等あれば、この部分の「route=」の部分変更しましょう。 とりあえず動かすだけなので、処理内容は変えずこのまま動作テストしてみます。 Timer Triggerの部分はあっても問題ありませんが、不要であれば削除するかコメントアウトしてしまいましょう。 HTTP Triggerを使うにはStorage Accountが必要になるのですが、ローカルPC環境にはないので、「Azurite」で代替します。 VSCode上で「Ctrl + Shift + p」でコマンドパレットを起動して、「Azurite: Start」を実行しましょう。 Azuriteが起動したら、VSCodeでコマンドプロンプトのターミナルを起動して以下のコマンドを実行しましょう。 正常に起動するとローカル環境でAPIが起動します。 <blockquote> <div class=”line number7 index6 alt2″ data-bidi-marker=”true”><code class=”java string”>func start</code></div></blockquote> 表示されたURLにアクセスすると正常に応答返ってきます。 デフォルトで書かれている処理は、クエリパラメータのnameをもとに動的に内容を変えてくれます。 表示されたURLに「?name=hogehoge」を追加してアクセスしてみましょう。 Azure Functionsデプロイ メニューからAzureのマークに移動して、「ACCOUNTS & TENANTS」で「Singn in to Azure…」を押下しましょう。 MicroSoftのログイン画面が表示されますので、デプロイ先のAzureアカウントのユーザーでログインしましょう。 ログインできたら、「WORKSPACE」の「Local Project」で雲のマークを押します。 既にAzure Functionsは作成済みなので、リストに出てきたFunctionsを指定します。 正常に完了したら、デプロイ先のAzure Functionsにコードがデプロイされています。   実行確認 実際にAPIが公開されているかを確認してみましょう。 デプロイされた「http_trigger」を押下します。 「関数のURLの取得」を押下すると公開されているAPIのURLが表示されます。 ローカルでテストしたときと同様にブラウザからアクセスしてみましょう。 これでAzure FunctionsをHTTP Triggerで実装完了です。 IPアドレス制限 このままでは全世界公開されており、誰でもアクセスできてしまうのでよろしくありません。 Azure Functionsだけでも簡単な接続元制限はできますので、かけておきましょう。 メニューの「設定」から「ネットワーク」に遷移します。 「受信トラフィックの構成」で「公衆ネットワークアクセス」のリンクを押下しましょう。 デフォルトだと「アクセス制限なしで有効」になっていると思います。 「選択した仮想ネットワークとIPアドレスから有効」で「一致しないルールのアクション」は「拒否」にして、 「追加」を押下します。 必須入力の箇所を入力して、「規則の追加」を行いましょう。 「IPアドレスブロック」の箇所が許可される通信元になります。 最後に忘れずに「保存」を押下しましょう。 このまま画面遷移すると設定が消えてしまいます。 これで設定したIPアドレス以外からの通信は拒否されて以下のような画面になります。 まとめ Azure FunctionsでHTTP Triggerを開発してみました。 まずは簡単な動作検証のみなので、中身は何も作りこんでいない状況ですが、 デプロイしてすぐにHTTPSのAPIが公開されました。 接続元IPの制限もできますので、 後は中の処理を作りこめば処理はかなり柔軟にできそうです。 APIとしてはバージョン管理やスロットリング、APIキー等の機能が薄いので、 がっつりAPI基盤として扱うには物足りないかもしれません。 その場合は、Azure API Managementと組み合わせることを検討してみるのがよさそうですね。

Dropboxなどのクラウドストレージサービスを利用開始するにあたり、多くの方が既存のファイルサーバなどに保存しているデータをどうやってDropboxに移せばよいか悩まれるのではないでしょうか？ 今回、SCSKのDropbox技術者が開発した移行ツールを、SCSKでDropboxの営業を担当している筆者が使用し、使い勝手などを忖度なくレビ ューしてみました。   Dropboxのデータ移行 データ移行の方法はいくつかあり、典型的なものは以下の3方式と考えられます。 ①Dropbox上の移行先フォルダをWEBブラウザで開き、移行元のフォルダ、ファイルを選択、あるいはドロップしてアップロードする ②Dropboxのデスクトップクライアントをインストールし、Dropboxの同期機能を活用してアップロードする ③ 移行ツールを活用してアップロードする   これらの使い分けは、企業の環境や要件などによるところになりますが、一般に下記のような条件下では①または②で移行をするケースが多いと思われます。 ・移行対象のファイル数が少ない（～1万ファイル未満） ・移行時、フォルダ構成を変更しない   しかし、ファイルの数、容量が増大し、フォルダ構成も複雑化してくると右から左へドラッグ＆ドロップで単純に移していくことができなくなってきます。Dropbox上でフォルダ構成を最適化するために、フォルダ構成を見直し、フォルダの分割などが必要となるケースも出てくると考えられます。移行作業は長期になり、平日の業務でデータを使っている最中でも進めていくことが多くなります。そのようなケースではデータ移行作業を弊社のような業者に委託することが最適な選択肢となります。 しかし、もしあなたのファイルサーバ上のデータが数十GB～数百GB程度で数個～数十個のトップフォルダから構成されていたらどうでしょう？ 移行にはおそらく数日かかることが予測されます。他の業務を行いながらでも、できなくはないかもしれない。。。でも初めて取り扱うDropboxに対する不安もある。 かといって、業者に発注するとコストがかかる。。。 悩んだ末に、自身で進めて後で後悔する。。。 そんなケースを対象に安全に、効率的に移行を進めることを目的として開発されたのが、今回レビューする移行ツール、「セルフデータ移行ツール」です。                 セルフデータ移行ツール 「セルフデータ移行ツール」には、多くのDropboxデータ移行プロジェクトで培ったＳＣＳＫの知見を詰め込まれています。 本ツールの特長をまとめると以下の通りです。 ・お客様ご自身でデータ移行を進めることを前提に提供 ・1カ月単位での貸出で、移行容量に合わせた期間の利用が可能 ・GUIで簡単操作、結果の確認が可能 ・SCSKがデータ移行プロジェクトで活用してきたツールがベース つまり、「簡単にできるので自分で移行作業してください。」というものだ。 ということで、本ツールの開発には携わっていない筆者が、「本当に簡単にデータ移行ができるのか」という観点で使ってみた。 セルフデータ移行ツールのインストール ここはセルフ データ移行ツールの利用ガイドに沿って進めます。 インストールそのものはzipファイルを展開して、インストーラーを起動するだけなので至極簡単。 ただ、そのあとの設定で、SSL証明書のインストールや、ライセンスキーの登録、Dropboxリンクの作成といった作業が必要となりました。筆者はここで少し時間がかかりましたが、利用ガイドの通りに進めて設定を完了することができました。 設定が完了すると[ジョブリスト]や[ジョブ作成]のボタンが押せるようになります。 セルフデータ移行ツールでデータ移行 セルフデータ移行ツールの操作性 起動すると図１の画面が表示されます。（注意書きは表示されなくなり、ボタンが有効化された状態） データ移行を開始するには[ジョブ作成]ボタンをクリックします。 　　　   入力が必須なのは、ジョブ名、移行ユーザー、移行元パス、移行先パスで、同時データ送信とコミット数は予めデフォルト値が設定されているため、今回はデフォルト値のまま使ってみます。 ジョブ名：　　　任意の文字列を指定できるが、このジョブで移行するデータを識別できる 　　　　　　　　ような名前を付けておくと結果を見るときに分かりやすい。 移行ユーザー：　 この移行を実行するために割り当てるDropboxユーザー名を指定する。 　　　　　　　　移行するデータに対するアクセス権が必要になるので適切に選択する。 移行元パス：　　 ファイルサーバ側の移行したいファイルがあるフォルダを指定する。 移行先パス：　　Dropbox上の保存先フォルダを指定する。 例として 　移行元(ファイルサーバ)： 　　Dir1 ——- Subdir1   ———— File11                    |                         |—–  File12                  |—  Subdir2                  |—  Subdir3 　移行先(Dropbox)： 　　TeamFolder1 があり、移行元のSubdir1以下をSubdir1フォルダも含めてDropbox上のTeamFolder1の下に移行したい場合、下記のように指定する必要があります。 移行元パス： \Dir1\Subdir1 移行先パス： \TeamFolder1\Subdir1 このためにDropbox上のTeamFolder1配下に予めSubdir1を手動で作成しておく必要があります。 必須項目の入力が完了したら[登録]ボタンをクリックします。 尚、必要に応じてスケジュール実行も可能となっているので、ジョブの登録だけ業務時間帯に行い、ジョブの実行は夜間や週末に実行させることも可能となっています。 今回は、”即時実行”で移行してみます。 [登録]ボタンをクリックすると、ジョブの実行が開始されます。 実行結果の確認もジョブリスト画面上で一覧表示されています。 更にジョブ名をクリックすると詳細の確認が可能で、ジョブの実行ログやサマリー（移行したファイル数やエラーがあったファイル数、実行時間など）だけを表示することも可能となっています。   セルフデータ移行ツールの操作性のまとめ 操作自体は決して難しい部分はありませんでした。おそらく、最適なパフォーマンスで移行を進めようとすると今回デフォルト値のままにした”同時データ送信”などのパラメータをチューニングする必要が出てくると思われますが、特にそのままでもデータ移行はできました。 指定が必須なパラメータは４個だけで、パス指定もGUIでの選択ができるので簡単だでした。 また、一度登録したジョブを元に編集して別のジョブを作成できる点も便利だと感じました。 ただ、既にDropboxを本番利用していて、多くのユーザーが登録されている環境だと移行ユーザーのリストが膨大になるため、ユーザ指定が少々苦労します。工夫が必要なポイントと感じたので開発者にフィードバックしました。 【検証】セルフデータ移行ツールの移行スピードとパフォーマンス 今回レビューの為に、1ファイルのサイズが500KB, 2.5MB, 5MB の3パターンでアップロードする総容量が1GBとなるようデータを準備し、検証をおこなってみました。データ移行に要した時間は以下の表のとおりです。 No. 1ファイルのサイズ ファイル数 1回目 2回目 3回目 平均 1 500KB 2,000 1,592秒 1,660秒 1,651秒 1,634秒 2 2.5MB 400 425秒 298秒 299秒 341秒 3 5MB 200 323秒 249秒 256秒 276秒 今回の検証から、本ツールでのデータ移行時間はアップロードするデータの総容量よりもファイルの数に依存し、ファイルの数が増えるとアップロード時間が長くなる傾向がありそうです。 転送時間そのものが速いとか遅いとかの評価もあると思いますが、これはネットワークを中心に環境に依存する部分も大きく、今回の検証結果はSCSKの社内からDropboxにデータを移行した場合の一例としてとらえてください。 オフィス系のファイルが多い組織の場合、ファイルサーバ上の平均ファイルサイズは2MB～3MB程度が多いことから、本ツールを利用するとおおよそどの程度の時間がかかるかの参考にしていただけると思います。   まとめ 本ブログの冒頭に記載した他のデータ移行方法で500KBのファイル2,000個の移行を試してみました。 ①ブラウザでDropboxのフォルダを開いて、移行したいファイルをドラッグ＆ドロップする 　　⇒ 約1200秒 　　　（WEBブラウザのDropboxフォルダに移行対象ファイルをマウスでドロップしてから、ブラウザ内 に「アップロードが完了しました」と表示されるまで） ②デスクトップクライアントを導入して、Dropboxフォルダに同期する 　　⇒ 約180秒　 　　　（Dropboxフォルダにファイルサーバのファイルをコピー操作してからデスクトップクライアントで「すべて最新状態」と表示されるまで） これらの時間と比べるとツールを使うと遅くなるように見えます。 しかし、ツールを使う価値は1フォルダのデータ移行の時間だけではなく以下のようなメリットがあります。 ・同期では推奨されないファイル数（30万ファイル以上）を対象にした 移行も対応可能です 。 ・エラーが発生した場合、どのファイルがエラーでアップロードできなかったのかすぐに識別ができます。 ・個々のフォルダを手動で操作し、人が張り付いて完了を目視で確認したりするような作業を軽減することが可能で、全体としては作業負荷を低減できます。 ・日中は通常業務に集中し、夜間に安全にデータを移すことが可能です ・差分移行（1回アップロードした後、元のファイルサーバ側で追加や変更されたファイル（差分）だけをアップロードする方法）にも対応しているため、業務で使いながらの移行も可能です。 データ移行方法の凡その使い分けを以下の表にまとめましたので、参考にしてください。 移行方法 スピード 大量ファイル対応 管理性（ログ/エラー確認） ①ブラウザ 〇 △ (数千件まで) × ②同期クライアント ◎ △ (30万制限あり) × ③セルフデータ移行ツール 〇 ◎ ◎ 詳細ログあり Dropboxへのデータ移行をご検討の方は、是非とも「セルフデータ移行ツール」を候補の一つとしてご検討いただきたい。   本ツールに関するお問合せ先：　 Dropbox-sales@scsk.jp

皆様、はじめまして！ SCSKの秋葉 大樹と申します。 2025年度SCSKに新卒入社し、現在はUSiZEのネットワーク担当として日々業務に励んでいます。 配属されてからこれまでの業務や学習の中で 「STP（Spanning Tree Protocol）」 という言葉をよく耳にしますが、 実際にどのような動作をしているのかイメージしづらい部分も多くありました。 そこで今回は、 Cisco Packet Tracer を使用してスパニングツリー構成を実際に組み、 その動きを確認してみたので、その内容をまとめます。 STP（Spanning Tree Protocol）とは STP（Spanning Tree Protocol）は、 レイヤ2ネットワークにおけるループを防止するためのプロトコル です。 スイッチを冗長構成で接続すると、以下のような問題が発生します。 ブロードキャストストームの発生 MACアドレステーブルのフラッピング ネットワーク全体の通信障害 これを防ぐために、STPは以下を自動で行います。 ルートブリッジの選出 ループとなるポートのブロッキング 障害時の経路切り替え   今回の検証環境 使用ツール Cisco Packet Tracer 構成概要 スイッチ3台によるシンプルな冗長構成を作成しました。 この構成で STP がどのように動作するかを確認します。   設定内容 Ciscoのスイッチでは、 STPはデフォルトで有効 になっています。 今回は特別な設定は行わず、デフォルトのSTP動作を確認します。 実行結果と確認ポイント ① ルートブリッジの確認 まずはSTPにおけるルートブリッジを確認します。 ルートブリッジとはSTPにおいて、 ネットワーク内のループを防ぐための中心的役割を担うスイッチ のことを指します。 今回はSwitch0で以下のコマンドを入力し、STPの状態を確認してみました。 確認コマンド： show spanning-tree 出力結果を見ると 「This bridge is the root」 という表示があることがわかります。 このことから、 Switch0 がルートブリッジ になっていることが確認できました。 （ルートブリッジはブリッジIDの大小比較により選出されますが、具体的な比較方法を割愛します） ② ポートの状態確認 STPではポートが以下の状態になります。 状態 説明 フォワーディング 通信可能 ブロッキング ループ防止のため遮断 リスニング/ラーニング 状態遷移状態 Packet Tracerでは、 各スイッチのインターフェースに表示されている点滅の色がポートの状態を表しています。 今回の場合だと、 Switch0 / Switch1：すべて フォワーディング（緑色のランプ） Switch2：片方のポートがブロッキング（オレンジ色のランプ） となっています。 ブロッキング状態のポートがあるおかげで、 ループを防ぐことが可能 になるということですね。 （ちなみに、ルートブリッジの全ポートは基本的にフォワーディングになります） ③ ケーブルを抜いてみる 次に、 あえてSwitch0⇔Switch1間のケーブルを切断してみました。 すると… Switch2のブロッキング状態のポートがフォワーディングに遷移（緑色に変わった） 通信は継続 自動で経路が切り替わる（切替えに数秒かかった） 👉 STPによる 冗長構成の効果 を確認できました！！   USiZE環境との関係 配属されてからこれまでの業務を通して、USiZE環境は冗長構成が作られていることがわかりました。 そのため、STPがどのように通信を制御しているのかを理解しておくことは、設計・運用の両面で非常に重要だと感じました。 ⇩USiZEに関する記事はこちらもご参照ください！⇩ USiZEってなに？～新人目線でまとめてみた～ SCSKが運営するクラウドサービスについて、新人目線でまとめてみました。 blog.usize-tech.com 2023.12.22 SCSKのプライベートクラウド「USiZEシェアードモデル」とは？ SCSKのプライベートクラウド「USiZEシェアードモデル」（ユーサイズシェアードモデル）についてご紹介します。 blog.usize-tech.com 2023.12.19 データ主権を担保したソブリンクラウド ユーサイズ│SCSK株式会社｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション 高可用性、高機密を備えた国産のSCSKのプライベートクラウドです。ファシリティスタンダード最高レベルのティア4に適合する日本国内のデータセンター上で稼働し、お客様データの保護とデータ主権を確保します。 www.scsk.jp   まとめ 今回、Packet Tracer を使って STP を実際に動かしてみて、以下の点が理解できました！ STPはループ防止のために必須の仕組み ルートブリッジを基準にポートステータスが決まる 障害時も自動で経路が切り替わる さらに調べてみると、 STP有効時には、スイッチの各ポートに役割（ルートポート / 指定ポート / 非指定ポート） が割り当てられていること STPには RSTP や MSTP といった複数の種類があり、用途や構成によって使い分けられていること など、まだまだ奥が深い技術だということも分かってきました。 今回は基本的な動作確認まででしたが、 今後は RSTP や MSTP の違い、実務での使い分け、トラブルシュート時の考え方 なども掘り下げていきたいと思います。 Packet Tracer は手軽に試せるので、ネットワークの知識を深めたい人にはかなりおすすめです！ 以下に参考URLを貼っておきます。 Cisco Packet Tracer Gain real skills with our powerful network simulation tool where you practice networking, IoT, and cybersecurity skills ... www.netacad.com   おわりに 今回は、Cisco Packet Tracer を使って STP（スパニングツリー）の動きを実際に確認してみました。 正直、最初は 「STPってループを防ぐやつでしょ？」 くらいの理解だったのですが、 実際に構成を組んでみると動きが目に見えて分かり、かなり理解が深まりました。 実際の業務でも、冗長構成や障害対応の考え方は共通している部分が多いと思うので、 今回勉強した内容は、今後の業務にも活かせそうだと感じました！ 最後まで読んでいただきありがとうございました！！

本記事ではDropboxの共同編集について紹介したいと思います。 はじめに Dropbox では、他のユーザーと共有するファイルを共同編集できます。共同編集する作業は、利用するツール（Webブラウザ、デスクトップアプリ、モバイルデバイス）やファイルの種類によって方法が異なります。 今回は、Windows PC上のWebブラウザを使った Dropbox での Microsoft Office ファイルの共同編集について記載します。 前提条件と制限事項 はじめに「Webブラウザ」と「デスクトップアプリ」、それぞれの 前提条件 と 制限事項 を確認します。 前提条件 項目 内容 Webブラウザ デスクトップアプリ Dropboxアカウント 共同編集者全員が Dropbox アカウント を所有している必要があります。 ○ 個人向けプラン（Basic、Plusなど）でも問題ありません。 ○ チームプラン（Standard、Advanced、Businessなど）を利用している必要があります。 ファイル共有 アクセス権限 共同編集したい相手に「 編集可能 」のアクセス権限を付与してファイルを共有します。 ○   ○ Microsoft 365 のライセンス 共同編集には、Office 365 Business 以上のライセンスが必要です。 永続ライセンスでは、デスクトップ上での共同作業機能を使用することはできません。 △ Dropbox Basic 、Plus または Family アカウントをお持ちの場合、Microsoft アカウントや Office ライセンスがなくてもファイルを編集できます。   Dropbox チーム アカウントをお持ちの場合は、Office Online での編集を許可するライセンスが付いた、企業向け Microsoft アカウント（Business/Business Premium/ProPlus/E3/E4/E5）が必要です。   Dropbox から Office Online ファイルを作成するには Office Online のプランに加入する必要があります。 ○     Office のバージョン デスクトップで共同編集を行う場合、Office バージョン 2 311 以降 が推奨されます。 ○ ○ OS 環境   × Windows パソコンでWebブラウザから使用できます。 ○ Windows 10 以降を使用している必要があります。 Dropbox設定 チーム管理者にて、管理コンソールから設定します。 ×   ○ 管理コンソールから共同作業をオンにする必要があります。 Dropboxデスクトップアプリ   × ○ Dropboxデスクトップアプリ　バージョン 29 以上がインストールされている必要があります。 MSIX版 Dropbox デスクトップアプリ（Microsoft のアプリ ストアからインストールした Dropbox アプリ）は対象外です。 制限事項     Webブラウザ デスクトップアプリ ファイルサイズ   ○ docx（100 MB 未満） .xlsx（100 MB 未満） .pptx（2 GB 未満） ○ 500 MB を超えるファイルは共同編集モードで開けず、オフラインモードでの編集となります。 ファイル形式   ○ ファイル形式（.docx、.xlsx、.pptx）である必要があります。 ○ ファイル形式（.docx、.xlsx、.pptx、.xlsm）である必要があります。 保護機能 パスワード保護されたファイルは共同編集できません。 ○ 数式・グラフ・マクロなどの要素 は、正確に表示されない場合があります。 大量の行や列を含むファイル、または構造が非常に複雑なファイルは、プレビューの対象外となる可能性があります。 ○ 基本的な共有と設定 共同編集を行うには、まず対象のユーザーに「編集権限」を付与したフォルダを共有する必要があります。 Dropboxでは複数人が同時に同じファイルを編集すると「 競合コピー 」が作成されることがあるため、オンライン状態での共同編集が推奨されます。 共有フォルダに共同作業を行うファイルをアップロードして、共同編集を開始します。   共有フォルダの作成: dropbox.com でフォルダを選択し、「 共有 」をクリックしてユーザーを招待します。 権限の確認: 共有時に「閲覧可能」ではなく「 編集可能 」に設定されていることを確認してください。 続いて、「Webブラウザ」での Microsoft Office ファイルの共同編集を利用する手順を確認します。 Web ブラウザ（Office Online）を利用する Web ブラウザ（Office Online）を利用する場合、追加のソフトをインストールすることなく、Webブラウザ上で完結して、Word、Excel、PowerPoint ファイルを複数のユーザーで同時に編集できます。  Web ブラウザでの共同編集手順 ログイン: dropbox.com にログインします。 ファイルを選択: 共有フォルダ内にある Word、Excel、または PowerPoint ファイル（.docx, .xlsx, .pptx）をクリックします。 Office Online で開く: プレビュー画面上部の「 次のアプリで 開く 」から「 [Word/Excel/PowerPoint] for the web 」を選択します。                              または、ファイル名の下にある「ファイル」から「 次のアプリで 開く 」＞「 [アプリ名] for the web 」を選択します。             編集開始: ブラウザの別タブで Office Online が起動します。他のユーザーも同じ手順でファイルを開くと、リアルタイムで誰がどこを編集しているかが表示され、同時に作業ができます。 保存: 変更内容は 自動的に Dropbox へ保存 されます。作業終了後はタブを閉じるだけで完了です。 補足 スムーズに運用するためのコツ デフォルト設定の変更: 毎回「[Word/Excel/PowerPoint] for the web」を選択するのが面倒な場合は、dropbox.com でアバター（プロフィール写真またはイニシャル）をクリック、[設定] ＞ [アプリ] ＞ [デフォルトの編集アプリ] から、Office ファイルを常に [ [アプリ名] for the web ] で開くように設定できます。         デフォルトの編集アプリ画面 Excel にて「常に読み取り専用で開く」を設定しても… Excel にて「常に読み取り専用で開く」（Excelにて[ ファイル ] メニューの [情報] ＞[ ブックの保護 ] ＞[常に読み取り専用で開く]を選択）に設定している場合も、Dropbox上では「Excel for the Web」で編集が可能になってしまいます。  これは、Dropbox 側で制御できる仕様ではなく、 Excel Online（Excel for the Web）において「読み取り専用」の設定が反映されないことが確認されている、現時点（2025/11）での想定された動作 です。（Dropbox 上で Excel ファイルを開いた際にも、Excel Online の仕様に準じて動作する。）                      Excel にて「常に読み取り専用で開く」を設定 閲覧モードでExcelファイルを参照する アクセス権限「閲覧可能」が付与されているフォルダに対象の Excel ファイルを保存すると、Dropboxからファイルを開くときに常に閲覧モードで開くように制御できます。 dropbox.com でアバター（プロフィール写真またはイニシャル）をクリック、[設定] ＞ [アプリ] ＞ [デフォルトの編集アプリ]にて 閲覧したいファイル形式の「次で開く」の設定を「dropbox.comで閲覧する」に設定すると、Webブラウザからファイルを開くときに 閲覧モード で開くことがでます。ただし、Webブラウザから 閲覧モード でファイルを開いた際の表示では、Excel表記（文字が見切れたり等）が気になる場合があります。 アクセス権限「閲覧可能」が付与されているフォルダにファイルを保存し、「Excel for the Web」で開くことで、閲覧モードでの表示が可能となります。この方法では、Web 上でも Excel に近い表示で、編集不可の状態でファイルを参照できます。 まとめ 共同編集は Web ブラウザとデスクトップアプリで利用可能 各利用方法に前提条件と制限事項がある 共同編集する場合は共有ファイルを「編集可能」で共有する必要がある Web ブラウザ（Office Online）を利用するのに追加設定は不要 共同編集は競合防止しながらリアルタイム編集が可能 参照情報 Dropbox 内で共同作業を有効にする方法 https://help.dropbox.com/ja-jp/view-edit/admin-guide-co-authoring Dropbox での Microsoft Office の共同編集 https://help.dropbox.com/ja-jp/view-edit/collaborate-on-microsoft-office Microsoft Office 365 で Dropbox を場所として追加する方法 https://help.dropbox.com/ja-jp/integrations/adding-place-microsoft-office Dropbox 向け Microsoft Office に関するよくある質問 https://help.dropbox.com/ja-jp/integrations/microsoft-office-faq

こんにちは SCSKの庄司です。 今回は、ServiceNowにおけるインポートセットについて紹介します。 本記事は執筆時点（2026年2月）の情報になります。最新の内容は製品ドキュメントを参考にしてください。   インポートセットとは インポートセットとは、外部のデータをServiceNowに取り込んでレコード化するための機能です。 一般的にはExcelやCSVのデータをインポートします。 特徴としては、ファイル内容を読み込んで直接テーブルに叩き込むのではなく、一度「インポートセットテーブル」というデータの仮置き場を経由する点があります。 ここでデータの不備をチェックしたりできます。 そのあとに、「変換マップ」という、インポートセットテーブル上の項目とターゲットとなるテーブル上の項目を紐づけるマップを通して実際のテーブル上にレコードをインポートします。 変換マップ内ではスクリプトを実行することもできるので、ServiceNow上のレコードとして登録するためのデータ成型なども可能です。   インポートセットの実行手順 インポートセットのおおまかな手順は下記です。 1.データソースの作成 まずは システムインポートセット>データのロード に遷移し、ExcelやCSVファイルをアップロードし、[送信]を押下します。 インポートセットテーブルで「テーブルの作成」を選択すれば、インポートセットテーブルが自動で作成されます。事前に手動で作成することや、以前自動作成したものを再利用することも可能です。 アップロード完了後、[送信]を押下します。   2.変換マップの作成 システムインポートセット>変換マップの作成 に遷移して[作成]を押下して、ファイル内の列とターゲットテーブルの列との紐づけを行い、各種データの行き先を指定します。 前述の通り、ここではスクリプトを設定することもできます。 スクリプトでは、例えばddmmyyyyの形式で送られてきた日付データをyyyy/mm/dd形式に成形したり、特定の値の場合は取り込みをスキップしたり、様々なことが出来ます。   3.変換 システムインポートセット>変換の実行 に遷移して、対象のインポートセットと変換マップを選択します。 [変換]ボタンを押すと、データが本番テーブルへと流し込まれます。 完了後のログを見て、エラーがないか確認すれば終了です。   txt形式のファイル取込み 番外編です。 今回はこの機能の紹介をしたくてこの記事を書き始めたといっても過言ではないです。 ExcelかCSV形式での取込みが一般的ですが、「独自の区切り文字を使った .txtファイルしか出せないシステムからの取り込みを実行したい」ということもあるかもしれません。 その際、txtファイルをインポートできるかの検証をしようとしてみても、データのロード画面からではエラーとなって取り込むことが出来ません。 この画面を見て「.txtは対応してないから無理です」と断る前に、これを試してみてください。   txtファイル取り込み手順 1.データソースの作成 システムインポートセット>アドミニストレーション>データソース に遷移します。 [新規]を押下し、下記条件で新しいレコードを作成します。 インポートセットテーブル名：任意のインポートセットテーブル名（既存でも新規でも可、新規の場合は自動でテーブル作成される） タイプ：ファイル フォーマット：CSV ファイル取得方法：添付ファイル CSV区切り文字：該当txtファイルで使用されている区切り文字（タブの場合は入力不要）   2.txtファイルの取り込み データソースレコードにtxtファイルを添付します。 今回は、以下のような内容のファイルで取り込みます。 区切り文字は「^」です。 user_id^first_name^last_name^email^department tanaka.taro^Taro^Tanaka^tanaka.taro@example.com^IT sato.hanako^Hanako^Sato^sato.hanako@example.com^Sales suzuki.ichiro^Ichiro^Suzuki^suzuki.ichiro@example.com^HR takahashi.ken^Ken^Takahashi^takahashi.ken@example.com^Finance ito.maki^Maki^Ito^ito.maki@example.com^Marketing ファイル添付後、「すべてのレコードをロード」関連リンクを押下し、レコード取込みを実行します。   3.変換マップの作成 ここから先は通常のインポートセットと変わりません。 必要に応じて変換マップを作成します。 変換マップは同じインポートセットテーブルやターゲットテーブルが同じであれば使いまわすこともできます。   4.変換 インポートセットと変換マップを紐づけ、変換を実行します。 ユーザーテーブルを確認しに行くと、レコードが作成されていることが確認できます。   以上がtxtファイルをインポートする手順です。 今回は手動でインポートする方法でしたが、API経由でもtxtファイルを取り込むことは可能です。 気になる方はpostman等のAPIを叩くことが出来るツールを使って試してみてください。   まとめ 以上、今回はServiceNowの基本機能である「インポートセット」の使い方と、意外と知られていない「txt形式ファイルの取り込み方法」をご紹介しました。 インポートセットはマスタデータの連携などで利用することも多い機能ですので、是非参考にしてみてください。

こんにちは。新人のtknです。最近、急にめっきり寒くなりましたね。 今年が明けてからでしょうか、冠婚葬祭イベントが急に発生し、装備一式を急遽用意することになりお財布もすっかり寂しくなってしまいました。昔は全て制服で済んでいたのに……大人になるってこういうことでしょうか……。 さて本日は、私の配属部署で取り扱っている、InfoWeaveという製品の RAGサービスにおいて扱える 3つのベクトルデータベース（ Pinecone , Amazon Bedrock Knowledge Bases , Amazon Kendra ）の違い について調査していこうと思います。 はじめに InfoWeaveとは「 RAGやAIエージェントなどを利用できる環境をお客様のAWSアカウントに素早く・簡単に構築できるサービス 」です。InfoWeaveのRAGサービスの詳細については、以下のサイトやブログ記事をご参照いただけますと幸いです。 生成AI RAG構築ソリューション – InfoWeave かんたんRAG環境構築 S-Cred+ InfoWeaveをリリースしました InfoWeave RAG構築ソリューションのアーキテクチャについて InfoWeaveでは、RAG検索用のベクトルデータベースとしてPinecone, Knowlege Bases ( Amazon OpenSearch Serverless ), Amazon Kendraを選択可能としており、以下のように目的に応じてお客様に最適なLLMとベクトルデータベース組み合わせを選んでいただけることが魅力の1つとなっています。 この選択肢の多さを初めて知ったとき、AWS初心者の私は「 実際に金額や精度などにおいてどれくらい差があるものなのだろう？ 」と疑問に思いました。 そのため今回は、金銭面や精度面などから3つのベクトルデータベースについて調査、比較した結果をお届けしたいと思います。 この記事がInfoWeaveの導入を検討しているお客様の参考になりましたら幸いです！ 調査結果 早速、3つのベクトルデータベースの比較結果を以下に示します。   Pinecone Knowledge Bases (OpenSearch Serverless) Amazon Kendra 最低利用金額 0円/月または 50ドル (7,785円) / 月 172.8ドル (26,905円) / 月 230.4ドル (35,874円) / 月 基本的な従量課金要素 プランに応じた 月額制 ベクトルデータベースの 起動時間 Indexの 起動秒数 , コネクタでの同期秒数 規定値を超過した場合の 従量課金要素 データの読み込み/書き込み量, 保存量 OpenSearch Compute Units (OCU) の増加数 実行クエリ数, データ保存量 Indexにかかる料金 Index自体への課金無し 0.24ドル (38円) / 時 0.32ドル (50円)  / 時 検索アルゴリズム ANN検索 (近似最近傍法) k-NN検索（k近傍法） 自然言語処理&機械学習 検索精度 やや高い 高い 最も高い 連携可能なAWSサービス S3, Secrets Manager, Knowledge Bases , Sage Makerなど S3, Aurora, Neptune Analytics, Amazon Kendra など S3, Aurora, RDS, DynamoDB, FSx, Bedrockなど いかがでしょうか？同じベクトルデータベースでも、課金要素から検索アルゴリズムまでちゃんと違いがあるように見えますね。 それでは、これから各ベクトルデータベースの具体的な違いについてご説明したいと思います。 Pinecone Pineconeとは、高次元のベクトルデータの扱いに優れた、クラウドネイティブなフルマネージド型のベクトルデータベースサービスです。特長として以下の4つが挙げられています。 高性能：低レイテンシーのクエリにより、新しいデータを即座にベクトルデータ化して格納できる サーバーレス：需要に応じてスケーリングできる 高信頼性：稼働率99.95%のSLAを備えている 安全性：データは保存・転送時に暗号化され、ロールと権限管理によりアクセス制御も可能 （出典：Pinecone 「Pincone Database」） 1000万レコードに対する処理速度の図（p50は約半数の割合、p90は約9割の処理速度平均を示す） 特に速度については、1000万レコードのクエリに対して処理時間がおよそ 最短16ms ととても速いです。 そして、Pineconeの最も嬉しいところは 無料のStarterプラン があることです！！ （参考： Pricing | Pinecone ） Index（ベクトルデータの管理単位、データベース）を最大5つまでしか作れないことや、格納できるデータが2GBまでであるなどの制約はありますが、 RAGサービスのPoC利用や小規模でのRAGサービス展開などに非常に有用 です。 また、Standard以上の有料プランについても、Pineconeではデータの読み込み/書き込み・保存量への従量課金のため 比較的安価に導入することが可能 です。 一方で、Pineconeは検索アプローチに ANN（近似最近傍）検索 を行っており、データの中から総当たりで似ているものを見つけるのではなく、関連していそうなグループの中だけを見るため、完全一致のデータではなく十分に近い一致データの発見を目標としています。 簡単に言うと、「時間をかけて100点満点の回答よりも、 高速に95点くらいの回答を目指す 」という感じでしょうか。 どこかのビジネス本のタイトルにありそうですね。 Knowledge Bases Knowledge Basesとは、Amazon Bedrockの機能の1つであり、RAGワークフロー全体の実装に役立つ機能を提供するフルマネージド型サービスです。具体的には、 参照したいデータを格納したデータソース、ベクトル化したデータを保存するベクトルデータベース、回答を生成する基盤モデル間の連携を自動で行ってくれる ため、RAG構築時のユーザの負担をぐっと軽減してくれます。 （出典：Amazon Web Services 「Amazon OpenSearch Serverless とは」） また、Knowledge BasesはAWSのサービスであることから、ベクトルデータベースとしてAmazon Aurora、Amazon Opensearch Serverless、Amazon Neptune Analyticsを選ぶことができ、他にもMongoDB、Pinecone、Redis Enterprise Cloudなど幅広い選択肢から選ぶことが可能です。 ちなみにInfoWeaveでKnowledge Basesを利用する際には、ベクトルデータベースに Opensearch Serverless が設定されています。Opensearch Serverlessは使用状況に合わせてコンピューティング容量が自動的にスケーリングされるため、 低頻度でのサービスの利用や、利用状況の予測が難しい方にとってお得 になるそうです！ （参考： Amazon OpenSearch Serverless – Amazon OpenSearch Service ） さて、お得というキーワードが出たところで、皆さんが気になっているであろうKnowledge Basesの利用料金についてですが、Knowledge Bases自体ではなく、 使用するベクトルデータベースに対して料金がかかります 。InfoWeaveで利用しているOpensearch Serverlessでは、ベクトルデータベース利用時に作成される OpenSearch Compute Units (OCU) の起動時間に対して課金 ……つまり、 作成から削除までの間に1秒単位で課金 されるため、ご利用時には長期に渡るリソースの削除忘れにご注意ください。 （参考： Amazon OpenSearch Service – 料金 ） またOpensearch Serverlessのベクトル検索では、 k-NN（k近傍法） を用いており、ベクトルデータベースの中からクエリとの距離が近い=類似しているものを上位からk個探しだす手法を取っています。k-NN検索は、95点を目指すPineconeのANN検索と反対に、 全てのデータの中から100点満点の回答を探します 。 また、ベクトルエンジンには様々なオプションがあり、条件に応じたフィルタリングなども可能なため、ユーザの利用目的に応じて検索法を調整できるのも魅力かもしれませんね！ （参考： Vector search API – OpenSearch Documentation ） Amazon Kendra Amazon Kendraとは、高度な機械学習を利用したエンタープライズ向けのインテリジェント検索サービスです。 「インテリジェントとは？」と私同様に思った方もいらっしゃるかもしれませんが、それは 自然言語処理と機械学習の併用 により、ユーザの入力クエリから 文章の”意図”を汲み取り、最適な検索結果を返す ことにあります。 ただのテキスト一致検索ではなく、意図を理解して探してくれるというのは非常に強力なパートナーを得た気分ですね。 （参考： ML 駆動の検索エンジンで企業の情報管理を革新 ! Amazon Kendra をグラレコで解説 ）   またAmazon Kendraでは、その豊富なコネクタにより AWS/SaaS/オンプレミスなどの多様なデータソース 、構造化/非構造化データなどの 多様なデータ形式 、 36の言語でのキーワード検索など幅広い検索要素に対応 しています。 自然言語での検索には、英語、日本語、スペイン語、フランス語、ドイツ語、ポルトガル語、韓国語、中国語の8言語が対応しており、1つのデータソースの中に複数言語の資料があっても検索可能である優秀さです。   そんなに優秀ってことは… はい、高性能納得のお値段です Amazon Kendraを利用する際にはIndexという高性能なデータベースを作成する必要がありますが、こちらはKnowledge Basesと同様に 作成から削除まで 1秒単位で料金が発生 します。加えて、Amazon Kendraはその優秀さにつき、Knowledge Basesよりも時間当たりの料金が高くなっています。問い合わせなどの利用した時間ではなく、削除までの”存在時間”に課金されるため、「うっかり削除忘れてた！」なんて時には緊急会議が開かれるかもしれませんので、ご利用にはご注意ください……。 （参考： Amazon Kendra の料金 – Amazon Web Services ） まとめ いかがでしたでしょうか。 こうして見ると「InfoWeaveはコスト・検索精度においてバランスの良いラインナップを揃えているんだなぁ」と、製品担当者の1人として思いました。検索ロジックに大きな違いがあるというのもとても興味深い点でした。 3つの選択肢のうち中心のものが選ばれやすいというゴルディロックス効果に基づくと、Knowledge Basesが選ばれやすい……なんてことは企業様向けですので無いかもしれませんね。 今回も最後までお付き合いいただきありがとうございました。 暦の上では大寒になりました。一年で一番冷え込む季節、皆さま体調に気を付けてお過ごしください。

こんにちは、SCSKの伊藤です。 前回 は、LifeKeeperをバージョンアップする際の事前準備とLifeKeeper for Linuxのバージョンアップ画面についてご紹介しました。 後編の本記事では、LifeKeeper for Windowsのバージョンアップ画面をご紹介します。   LifeKeeper for Windowsのバージョンアップもやってみた。 前回に続き、LifeKeeper for Windowsのバージョンアップを実施します。 作業環境は以下の通り。 ■環境情報 ホスト名 アクティブサーバ　＝　WIN19-01 スタンバイサーバ　＝　WIN19-02 OS Windows Server 2019 LifeKeeper製品 バージョンアップ前　＝　LifeKeeper for Windows v8.10 バージョンアップ後　＝　LifeKeeper for Windows v10.0 ■リソース階層 QSP.Task クイックサービスプロテクションリソース 　Vol.X データレプリケーションリソース 　　IP-192.168.10.220 IPアドレスリソース ■インストール実行ファイル LifeKeeperインストーラー ＜デスクトップ＞ \LK-Win-10-0-0\LKWin-10.0.0-setup.exe ローカライズ言語サプリメントインストーラー ＜デスクトップ＞ \LK-Win-10-0-0\LKLangSup-10.0.0-Setup.exe   １．LifeKeeperGUIから、LifeKeeperのリソースが正常状態であることを確認します。   ２．スタンバイサーバにて、LifeKeeper関連サービスの停止およびスタートアップの無効化を実施します。 (スタートアップの無効化は必要に応じて実施) ■LifeKeeper関連サービス ・LifeKeeper ・LifeKeeper External Interfaces ・SIOS DataKeeper   ３．スタンバイサーバの「プログラムと機能」から、ローカライズ言語サプリメント『LifeKeeper for Windows Localized Language Supplement』をアンインストールします。   ４．スタンバイサーバにて、『LifeKeeperインストーラー』を起動します。   ５．インストーラーが起動したらセットアップを進めていきます。   ６．機能の選択画面(Select Features)が表示されたら、不要なリカバリキットのチェックを外します。   ７．LifeKeeperサービスの停止確認が表示されますので、「はい(Y)」をクリックしてセットアップを進めます。   ８．ファイアウォール設定変更確認が複数回表示されるので、それぞれ「はい(Y)」をクリックしてセットアップを進めます。   ９．LifeKeeperのセットアップが完了しますので「Finish」をクリックしてDataKeeperのセットアップが開始されるのを待ちます。   １０．DataKeeperサービスの停止確認が表示されますので、「はい(Y)」をクリックしてセットアップを進めます。   １１．ファイアウォール設定変更確認が表示されるので、それぞれ「はい(Y)」をクリックしてセットアップを進めます。   １２．サービスログオンアカウント設定が表示されるので、環境にあわせて選択してセットアップを進めます。 (本手順では「LocalSystem account」を選択)   １３．DataKeeperのセットアップが完了しますので「Finish」をクリックします。 １４．ライセンスキーマネージャが表示されるので内容を確認して「終了(E)」をクリックします。   １５．セットアップ後のOS再起動画面が表示されるので「Yes, I want to restart my computer now.」を選択して 「Finish」をクリックします。   １６．スタンバイサーバのOS再起動後、『ローカライズ言語サプリメントインストーラー』を起動します。   １７．インストーラーが起動したらセットアップを進めて、インストールを完了させます。   １８．「プログラムと機能」からLifeKeeperのバージョンを確認します。   １９．スタンバイサーバのLifeKeeper関連サービスのスタートアップの有効化およびサービス起動を実施します。 ■LifeKeeper関連サービス ・LifeKeeper ・LifeKeeper External Interfaces ・SIOS DataKeeper バージョンによっては、SIOS DataKeeperの自動起動無効化が解除されており、既に起動している場合があります。   ２０．スタンバイサーバの LifeKeeperGUIを起動すると、本バージョンアップでは対向側のステータスが「不明」になっていますので アクティブサーバ側のLifeKeeperGUIから「サービス停止」を実施します。 スタンバイサーバのDataKeeperリソースが「ミラーリング」になっているためデータ同期自体は実施されておりますが、 バージョンや設定によって動作が異なる場合があるので、サポートに事前確認しておくことを推奨します。   ２１．アクティブサーバ側のLifeKeeperGUIでサービス停止が完了したら、スタンバイサーバ側のLifeKeeperGUIから「サービス起動」を実施して、スタンバイサーバ側ですべてのリソースを起動します。   ２２．アクティブサーバにて、LifeKeeper関連サービスの停止およびスタートアップの無効化を実施します。 (スタートアップの無効化は必要に応じて実施) ■LifeKeeper関連サービス ・LifeKeeper ・LifeKeeper External Interfaces ・SIOS DataKeeper   ２３．アクティブサーバの「プログラムと機能」から、ローカライズ言語サプリメント『LifeKeeper for Windows Localized Language Supplement』をアンインストールします。   ２４．アクティブサーバにて、『LifeKeeperのインストーラー』を起動します。   ２５．インストーラーが起動したらセットアップを進めていきます。   ２６．機能の選択画面(Select Features)が表示されたら、不要なリカバリキットのチェックを外します。   ２７．LifeKeeperサービスの停止確認が表示されますので、「はい(Y)」をクリックしてセットアップを進めます。   ２８．ファイアウォール設定変更確認が複数回表示されるので、それぞれ「はい(Y)」をクリックしてセットアップを進めます。   ２９．LifeKeeperのセットアップが完了しますので「Finish」をクリックしてDataKeeperのセットアップが開始されるのを待ちます。   ３０．DataKeeperサービスの停止確認が表示されますので、「はい(Y)」をクリックしてセットアップを進めます。   ３１．ファイアウォール設定変更確認が表示されるので、それぞれ「はい(Y)」をクリックしてセットアップを進めます。   ３２．サービスログオンアカウント設定が表示されるので、環境にあわせて選択してセットアップを進めます。 (本手順では「LocalSystem account」を選択)   ３３．DataKeeperのセットアップが完了しますので「Finish」をクリックします。   ３４．ライセンスキーマネージャが表示されるので内容を確認して「終了(E)」をクリックします。   ３５．セットアップ後のOS再起動画面が表示されるので「Yes, I want to restart my computer now.」を選択して 「Finish」をクリックします。   ３６．アクティブサーバのOS再起動後、『ローカライズ言語サプリメントインストーラー』を起動します。   ３７．インストーラーが起動したらセットアップを進めて、インストールを完了させます。   ３８．アクティブサーバの「プログラムと機能」からLifeKeeperバージョンを確認します。   ３９．アクティブサーバのLifeKeeper関連サービスのスタートアップの有効化およびサービス起動を実施します。 ■LifeKeeper関連サービス ・LifeKeeper ・LifeKeeper External Interfaces ・SIOS DataKeeper   ４０．LifeKeeperGUI上のサーバステータスがそれぞれ正常であることを確認し、アクティブサーバ側にリソースをスイッチバック します。   ４１．アクティブサーバ側でリソース起動が完了したら、LifeKeeper for Windowsのバージョンアップは完了です。   さいごに 事前準備やバージョンアップ後の動作テスト等を考えなければ、バージョンアップだけなら実は簡単な作業です。 PoC環境等での事前検証をする場合等にでも、少しでも参考になれば幸いです。   詳しい内容をお知りになりたいかたは、以下のバナーからSCSKLifekeeper公式サイトまで