0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@DaokFrontier

RAG構築の壁を越える！ローカル×クラウドのハイブリッド構成とコスト戦略

0
Posted at

RAG構築の壁を越える！ローカル×クラウドのハイブリッド構成とコスト戦略

「RAGを導入したはいいものの、思ったように検索精度が出ない」「クラウドサービスを使うとコストが跳ね上がる」「機密データを扱いたいが、外部サービスに渡すのは不安」――実務でRAGシステムを構築する際、多くのエンジニアがこのような課題に直面します。特に、精度とコスト、そしてデータ機密性のバランスは、RAG導入の成否を分ける重要なポイントです。

この記事では、これらの課題を解決するためのRAGハイブリッド構成に焦点を当て、ローカルLLMとマネージド型クラウドサービスを組み合わせた具体的な設計パターン、データ前処理や検索チューニングのベストプラクティス、さらに導入・運用のリアルなコスト構造とコスト最適化戦略をハンズオン形式で解説します。本記事を読むことで、あなたのRAGシステムは、より高い精度と堅牢性、そして経済性を両立できるようになるでしょう。

1. RAGシステムの基本とハイブリッド構成が求められる背景

このセクションでは、RAG（Retrieval-Augmented Generation：検索拡張生成）の基本概念と、実務でRAGハイブリッド構成がなぜ重要になるのか、その背景にある課題を解説します。

RAGは、大規模言語モデル（LLM）が外部の知識やデータを参照しながら回答を生成する仕組みです。これにより、LLMのハルシネーション（もっともらしい嘘）を抑制し、学習済みデータに含まれない最新情報や社内規定などに基づいた、信頼性の高い回答を可能にします。RAGは主に以下の2つのフェーズで構成されます。

  1. Retrieval（検索）: ユーザーの質問に関連するドキュメントを知識ベースから検索する。
  2. Generation（生成）: 検索されたドキュメントとユーザーの質問をLLMに渡し、回答を生成させる。

しかし、RAGシステムを実運用する際には、以下の課題に直面することが少なくありません。

  • 検索精度の壁: 関連性の低いドキュメントが検索されたり、必要な情報が漏れたりすることで、LLMの回答品質が低下する。
  • 計算コスト: 大規模な埋め込みモデルやLLMのAPI利用料、ベクトルストアの運用費用などが高額になる。特にプロトタイプから本番運用へ移行する際に顕在化しやすい。
  • データプライバシー・セキュリティ: 機密性の高い社内データをクラウドサービスに預けることへの懸念。
  • 運用負荷: システムの構築、チューニング、監視、評価など、継続的な運用に多大なリソースが必要。

これらの課題に対し、ローカル環境で動作するLLMやベクトルストアと、クラウドのマネージドサービスを組み合わせたRAGハイブリッド構成が有効な解決策となります。これにより、データ機密性の確保、コスト削減、そして精度の向上をバランス良く実現できます。

RAGシステムの主要技術要素

RAGシステムを理解し、ハイブリッド構成を設計するために不可欠な主要技術要素を以下にまとめます。

  • ハイブリッド検索: ベクトル検索（意味的な類似度）とキーワード検索（完全一致）を組み合わせ、検索精度を高めます。
  • リランキング (Re-ranking): 検索結果をさらに高精度なモデル（例: Cohere Rerank v3）で再評価し、LLMに渡すコンテキストの質を向上させます。実務では標準的なアプローチです。
  • チャンキング戦略: ドキュメントを検索可能な単位（チャンク）に分割する手法。チャンクサイズやオーバーラップは検索精度に大きく影響します。日本語では300〜500文字程度が目安です。
  • ベクトルストア: ベクトル化されたドキュメントを保存し、類似度検索を可能にするデータベース（例: pgvector, Chroma, Amazon Bedrock Knowledge Basesなど）。
  • 埋め込み（Embedding）モデル: テキストを数値表現（ベクトル）に変換するモデル（例: nomic-embed-text-v1.5, Hugging Faceモデル）。
  • LLM (大規模言語モデル): 質問応答を行うモデル（例: OpenAI GPT-4, LLaMA, Gemma）。ローカルで動作するLLMとしてはLM StudioやOllamaで利用できるモデルが挙げられます。
  • フレームワーク: RAGシステム構築を支援するライブラリ（例: LangChain, LlamaIndex）。
  • 評価指標: RAGの精度を定量的に評価するための指標とツール（例: Context Precision, RAGAS）。

2. ローカル×クラウドのRAGハイブリッド構成の実装例

このセクションでは、ローカル環境でデータの前処理、埋め込み、ベクトル検索を行い、ローカルLLMで応答するRAGハイブリッド構成の具体的な実装例を、PythonとLangChainを用いて示します。これにより、データ機密性を担保しつつ、クラウドAPI利用料を抑えることが可能です。

前提:

  • Python 3.9以上がインストールされていること
  • 以下のライブラリがインストールされていること: 
    pip install langchain langchain-community chromadb ollama
  • LM StudioまたはOllamaでローカルLLMが動作していること（後述のコード例で設定方法を説明します）。

2.1. ローカルでのデータ準備と埋め込み（LangChain + ChromaDB + HuggingFaceEmbeddings）

まず、ローカルのドキュメントをチャンクに分割し、埋め込みモデルでベクトル化して、ローカルのChromaDBに保存する手順です。これは、機密性の高いデータを外部に公開せずにRAGを構築したい場合に特に有効です。

import os
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter

# 1. ドキュメントの読み込み
# 例として、ローカルのテキストファイルを読み込みます。
# 事前に './data/my_document.txt' ファイルを作成し、RAGに関するテキストを記述してください。
# 例: "RAGのハイブリッド構成は、ローカルとクラウドの利点を組み合わせることで、コストとセキュリティのバランスを取ることができます。"
# このファイルには、社内規定や機密情報など、外部に出したくないデータを想定します。
os.makedirs("./data", exist_ok=True)
with open("./data/my_document.txt", "w", encoding="utf-8") as f:
    f.write("RAGのハイブリッド構成は、ローカルとクラウドの利点を組み合わせることで、コストとセキュリティのバランスを取ることができます。\n")
    f.write("ローカルLLMの利用は、API利用料を削減し、データプライバシーを保護する上で非常に有効です。\n")
    f.write("クラウドのマネージドRAGサービスは、スケーラビリティと運用負荷の低減に貢献します。\n")
    f.write("最適なRAGシステムは、要件に応じてこれらの要素を組み合わせることで実現されます。\n")

loader = TextLoader("./data/my_document.txt", encoding="utf-8")
documents = loader.load()

# 2. チャンク分割
# 日本語ドキュメントの場合、文脈の連続性を保ちつつ、適切なチャンクサイズとオーバーラップを設定することが重要です。
# 小さすぎると文脈が失われ、大きすぎるとLLMのコンテキストウィンドウを圧迫し、コスト増につながります。
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,  # チャンクの最大文字数
    chunk_overlap=100,  # チャンク間の重複文字数
    separators=["\n\n", "\n", " ", ""], # ドキュメントの構造を考慮したセパレータ
    length_function=len,
    add_start_index=True,
)
chunks = text_splitter.split_documents(documents)
print(f"ドキュメントを {len(chunks)} 個のチャンクに分割しました。")

# 3. 埋め込みモデルの準備
# `nomic-embed-text-v1.5` は、ローカルで利用可能な高性能な埋め込みモデルの一例です。
# 初回実行時にモデルがダウンロードされます。ネットワーク接続が必要です。
embeddings = HuggingFaceEmbeddings(model_name="nomic-embed-text-v1.5")
print("埋め込みモデルをロードしました。")

# 4. ベクトルストアへの保存（ローカルのChromaDBを使用）
# `persist_directory` を指定することで、データをファイルシステムに永続化できます。
# これにより、アプリケーションを再起動してもベクトルデータが失われることはありません。
vectordb = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"
)
vectordb.persist()
print(f"ローカルのChromaDBに {len(chunks)} 個のドキュメントが保存されました。")

# 5. ベクトルストアからの検索（例）
# 正しくデータが保存されたか確認するために、簡単なクエリで検索を試みます。
query = "RAGのハイブリッド構成について教えてください。"
retriever = vectordb.as_retriever()
retrieved_docs = retriever.invoke(query)
print("\n--- 検索結果（ローカルChromaDB） ---")
for i, doc in enumerate(retrieved_docs):
    print(f"[{i+1}] {doc.page_content[:100]}...") # 最初の100文字を表示
    print(f"   (Source: {doc.metadata.get('source', 'N/A')}, Start Index: {doc.metadata.get('start_index', 'N/A')})")

2.2. ローカルLLMとの連携（LM StudioまたはOllamaのOpenAI互換API）

LM StudioやOllamaは、ローカルでLLMを動作させ、OpenAI互換のAPIエンドポイントを提供します。これにより、既存のLangChainコードをほとんど変更することなく、ローカルLLMを利用できます。

準備:

  1. LM StudioまたはOllamaのインストール: それぞれの公式サイトからダウンロードし、インストールしてください。
  2. LLMのダウンロード・起動:
    • LM Studioの場合: アプリ内で任意のモデル（例: TheBloke/Mistral-7B-Instruct-v0.2-GGUF）をダウンロードし、「Start Server」ボタンでOpenAI互換APIサーバーを起動します。通常、http://localhost:1234/v1 で利用可能です。
    • Ollamaの場合: CLIで ollama pull mistral などのコマンドでモデルをダウンロードし、 ollama run mistral でモデルを起動します。通常、http://localhost:11434/v1 で利用可能です。
import os
from langchain_community.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate

# LM StudioまたはOllamaのAPIエンドポイントを設定
# 実行前にLM StudioまたはOllamaでLLMを起動し、適切なポートを設定してください。
# LM Studioの場合の例
os.environ["OPENAI_API_BASE"] = "http://localhost:1234/v1"
# Ollamaの場合の例 (LM Studioを使用しない場合はコメントアウトを外してください)
# os.environ["OPENAI_API_BASE"] = "http://localhost:11434/v1"

# ローカルLLMではAPIキーは不要な場合が多いため、ダミーを設定
os.environ["OPENAI_API_KEY"] = "not-needed"

# ローカルLLMのモデル名を指定
# LM Studioでダウンロードしたモデル名、またはOllamaでpullしたモデル名に合わせて変更してください。
# 例: LM Studioで "TheBloke/Mistral-7B-Instruct-v0.2-GGUF" をダウンロードした場合、モデル名は "Mistral-7B-Instruct-v0.2-GGUF" など。
# 例: Ollamaで "ollama pull mistral" した場合、モデル名は "mistral" など。
# モデル名が不明な場合は、LM StudioのUIやOllamaのCLIで確認してください。
llm = ChatOpenAI(model_name="Mistral-7B-Instruct-v0.2-GGUF", temperature=0.0) # LM Studioの例
# llm = ChatOpenAI(model_name="mistral", temperature=0.0) # Ollamaの例

# RetrievalQAチェーンの構築
# 検索で取得したドキュメントをLLMのプロンプトに詰め込む (stuff) 方式で回答を生成します。
# return_source_documents=True にすることで、LLMが参照したドキュメントも結果に含まれます。
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectordb.as_retriever(), # 前のステップで作成したローカルのvectordbを使用
    return_source_documents=True
)

# 質問応答
question = "RAGのハイブリッド構成のメリットは何ですか？"
print(f"\n--- 質問: {question} ---")
try:
    result = qa_chain.invoke({"query": question})
    print("\n--- LLMによる回答 ---")
    print(result["result"])
    print("\n--- 参照ドキュメント ---")
    for doc in result["source_documents"]:
        print(f"- {doc.page_content[:100]}...")
except Exception as e:
    print(f"\nエラーが発生しました。LM StudioまたはOllamaのLLMサーバーが起動しているか、モデル名が正しいか確認してください: {e}")

2.3. クラウドのマネージドRAGサービスとの連携（概念）

クラウドのマネージドRAGサービス（AWS Bedrock Knowledge Bases, Google Vertex AI Agent Builder, Azure AI Searchなど）を利用する場合、データ取り込み、チャンク分割、ベクトル化、DB保管、検索までの一連のパイプラインが自動化されているため、上記のコードを自前で書く必要は少なくなります。

これらのサービスは、大規模なデータセットや高いスケーラビリティが求められる場合に特に有効です。一方で、API利用料やベンダーロックインのリスクも考慮する必要があります。

# AWS Bedrock Knowledge BasesのPython SDKを利用する際の概念的なコード
# 機密性の低い、汎用的な大規模データを扱う場合に適しています。
# import boto3
# client = boto3.client("bedrock-agent-runtime")
# response = client.retrieve_and_generate(
#     input={"text": "RAGのハイブリッド構成のメリットは何ですか？"},
#     retrieveAndGenerateConfiguration={
#         "type": "KNOWLEDGE_BASE",
#         "knowledgeBaseConfiguration": {
#             "knowledgeBaseId": "YOUR_KNOWLEDGE_BASE_ID", # AWSコンソールで作成したKnowledge BaseのID
#             "modelArn": "YOUR_LLM_MODEL_ARN" # 使用するLLMのARN (例: Anthropic Claude v2)
#         }
#     }
# )
# print(response["output"]["text"])

RAGハイブリッド構成の全体像:
これらの実装例を組み合わせることで、以下のようなRAGハイブリッド構成が考えられます。

  • ローカル環境: 機密性の高い社内ドキュメント、頻繁に更新される情報、開発・テスト環境。
  • クラウドマネージドサービス: 公開された大規模データ、汎用的な知識ベース、本番運用環境でのスケーラビリティが必要な場合。

これにより、それぞれの利点を最大限に活かし、コスト最適化とセキュリティを両立したRAGシステムを構築できます。

3. よくあるエラー・ハマりどころと回避策

RAGシステムの構築において、エンジニアが直面しやすい問題とその回避策を、特にRAGハイブリッド構成の視点も交えながら解説します。

3.1. 検索精度が出ない（Garbage In, Garbage Out）

最も一般的な問題は、ユーザーの質問に対して関連性の低いドキュメントが検索されたり、必要な情報が検索漏れしたりすることです。

  • ハマりどころ: ベクトル検索だけでは、キーワードの厳密な一致や特定の固有名詞の検索が苦手な場合がある。チャンク分割が不適切だと文脈が分断され、意味のある情報が検索できない。
  • 回避策:
    • チャンキング戦略の最適化: ドキュメントの構造（見出し、段落、表など）を意識した分割が重要です。固定長で機械的に分割するのではなく、セマンティックチャンキングや再帰的なチャンキング（RecursiveCharacterTextSplitter）を検討します。適切なチャンクサイズとオーバーラップの設定が、検索精度に直結します。
    • ハイブリッド検索の導入: ベクトル検索（意味的な類似度）とキーワード検索（BM25など）を組み合わせることで、両者の弱点を補完し、検索精度を向上させます。クラウドサービスではAzure AI Searchなどがハイブリッド検索をサポートしています。
    • リランキングの導入: 検索で取得した上位ドキュメントを、より高精度なCross-Encoderモデル（例: Cohere Rerank v3）で再評価し、関連性の高い順に並び替えます。これにより、LLMに渡すコンテキストの質が劇的に向上します。
    • データ品質の向上: 重複コンテンツの除去、フォーマットの統一、不要な情報の排除など、データクレンジングを徹底します。品質の低いデータからは良い回答は生まれません。
    • メタデータの活用: ドキュメントの作成日、著者、カテゴリなどのメタデータをチャンクに紐付け、検索時にフィルタリングや重み付けに利用することで、より関連性の高い情報を絞り込むことができます。

3.2. ハルシネーション（もっともらしい嘘）の発生

LLMが検索結果にない情報を補完して、事実に基づかない回答を生成してしまう問題です。

  • ハマりどころ: LLMは与えられたコンテキストが不十分でも、あたかも知っているかのように情報を生成しようとする性質があります。
  • 回避策:
    • プロンプトエンジニアリング: LLMへの指示として、「参照情報に記載がない場合は『わかりません』と答えてください」「憶測や一般知識は使わないでください」といった生成制約を明確に含めることが重要です。
    • Context Selection: リランキング後の上位数件のみを抽出し、LLMのプロンプトに組み込むことで、LLMが参照する情報を厳選し、ノイズや誤った情報を減らします。
    • Corrective RAG (CRAG): 取得した文書の品質をリアルタイムで評価し、品質が低い場合にWeb検索などの代替ソースで情報を補正する高度な手法も研究されています。

3.3. コストとレイテンシの増大

RAGシステムの運用において、検索や生成の処理に時間がかかったり、API利用料やインフラ費用が想定以上に膨らんだりする問題です。特に大規模なデータを扱う場合や、ユーザー数が増加する場合に顕著になります。

  • ハマりどころ: LLMのAPI利用料はトークン数に比例するため、不要な情報までLLMに渡すとコストが急増します。また、高性能な埋め込みモデルやリランキングモデルは計算リソースを多く消費します。
  • 回避策:
    • チャンクサイズとTop-Kの最適化: 小さすぎるチャンクはベクトルインデックスサイズと検索件数を増やし、大きすぎるチャンクはLLMへの入力トークンを増やします。同様に、検索で取得するドキュメント数（Top-K）も、多すぎるとLLMの入力トークンが増え、少なすぎると必要な情報が欠落する可能性があります。これらのパラメータをトレードオフを考慮して調整することで、RAGのコスト最適化を図ります。
    • リランキングモデルの選定: Cross-Encoderは高精度ですが計算コストが高いです。初期検索には軽量なBi-Encoderを使用し、リランキングでCross-Encoderを用いる多段構成を検討することで、精度とコストのバランスを取ります。
    • ローカルLLMの活用: プライバシー要件やコスト削減のため、LM StudioやOllamaなどのローカルLLMを導入することは非常に有効です。特に開発・テスト段階や、応答速度がそこまでシビアでない業務では、クラウドLLMの代替として大きなメリットがあります。
    • クラウドとローカルの使い分け: 機密性の高いデータや頻繁に更新されるデータはローカルで処理し、汎用的な知識や大規模なデータはクラウドのマネージドサービスを利用するなど、RAGハイブリッド構成でコストとセキュリティのバランスを取ります。
    • ベクトル次元の最適化: 埋め込みベクトルの次元数を減らすことで、保存容量や計算コストを削減できる場合があります。ただし、精度とのトレードオフになります。
    • メタデータフィルターの活用: Semantic similarityによるベクトル検索の前に、テナントやアクセス制御、文書種別、言語などのメタデータフィルターで検索空間を絞り込むことで、不要な処理を削減し、コストを最適化しつつ、セキュリティも強化できます。

4. 設計上のトレードオフとベストプラクティス

RAGシステムの設計には、様々なトレードオフが存在します。このセクションでは、システムの目的や要件に応じて最適な選択を行うための考え方と、実務で役立つベストプラクティスを解説します。特にRAGハイブリッド構成を意識した設計指針を示します。

4.1. 設計上のトレードオフ

  • 検索精度 vs コスト・レイテンシ:
    • ハイブリッド検索やリランキングは検索精度を向上させますが、計算コストやレイテンシが増加します。特にリランキングは推論コストが高い傾向にあります。
    • チャンクサイズも同様で、小さすぎると検索精度が上がる可能性がありますが、embedding件数やベクトルインデックスサイズが増え、ストレージコストや検索コスト増につながります。
  • ローカル構築 vs クラウドマネージドサービス:
    • ローカル構築: 高い柔軟性、データ主権（閉域網での運用）、API利用料の削減によるコスト低減のメリットがありますが、インフラ構築・保守の負担が大きく、スケーラビリティの確保も自前で検討する必要があります。開発・テスト段階や、機密性の高いデータ、特定のカスタマイズが必要な場合に有利です。
    • クラウドマネージドサービス: インフラ構築・保守の負担が少なく、最短で本番運用を開始でき、高いスケーラビリティと可用性が提供されます。しかし、ベンダーロックインやクラウド利用コストが発生します。汎用的な大規模データや、迅速なデプロイが求められる場合に適しています。
  • RAG vs ファインチューニング:
    • RAGは「最新の外部知識を参照する」ことに向いており、データ更新頻度が高い場合や、回答の根拠提示が求められる場合に有利です。
    • ファインチューニングは「特定のスタイル・形式・ドメイン語彙を内在化させる」ことに向いており、モデルの内部パラメータを更新するため、開発コストが高いです。
    • 多くの本番システムでは、ファインチューニングしたモデルの上にRAGレイヤーを組み合わせるハイブリッド構成が採用されます。これにより、モデルの特定の特性を強化しつつ、最新情報への対応も可能になります。

4.2. ベストプラクティス

RAGハイブリッド構成を成功させるための具体的なベストプラクティスを以下に示します。

  • 段階的な導入と評価:
    • PoC（概念実証）の段階では、まずローカル環境でRAGシステムの基本的な仕組みを理解し、その有効性を検証します。その後、業務での利用時にはクラウドサービスを部分的に活用したり、より堅牢なハイブリッド構成に移行したりするアプローチが有効です。
    • RAGの精度改善は、「どの工程で失敗しているか」を評価指標とログで切り分け、データ準備 → 検索 → 生成 → 評価 → 運用の順に直すことで、PoC止まりから本番運用の壁を超えやすくなります。
    • RAGASなどの評価ツールを用いて、Context Precision、Context Recall、Faithfulness、Answer Relevancyなどの定量的な評価指標で継続的に品質を測定し、改善サイクルを回しましょう。
  • データ準備の徹底:
    • RAGの回答品質の8割は、LLMモデルの性能ではなく「検索でどれだけ正しいコンテキストを渡せたか」で決まります。
    • データクレンジング（重複除去、フォーマット統一、表記揺れ修正）を徹底し、高品質なデータソースを選別することが最重要です。
    • ドキュメントの構造を考慮したチャンキング戦略を設計し、文脈の損失を最小限に抑えます。
  • ハイブリッド検索とリランキングの活用:
    • 実務レベルの複雑な要求に応えるためには、ベクトル検索単体では限界があることを理解し、ハイブリッド検索とリランキングを組み合わせることを標準的なアプローチとします。
  • コスト最適化の視点:
    • RAGの費用は、LLMのAPI利用料だけでなく、Query処理、embedding、検索、rerank、文書取得、index更新、storageなど、パイプライン全体の費用とレイテンシを考慮して設計します。
    • Semantic similarityの前に、テナントやアクセス制御、文書種別、言語などのメタデータフィルターで検索空間を絞り込むことで、不要な処理を削減し、コストを最適化します。
    • ローカルLLMやオープンソースの埋め込みモデルの活用も、コスト削減の大きな鍵となります。
  • セキュリティとプライバシー:
    • 機密性の高い情報を扱う場合は、データ主権を確保できるローカル環境や閉域網でのRAG構築を検討します。これはRAGハイブリッド構成の最大の利点の一つです。
    • 権限フィルターは費用最適化以前の必須要件であり、検索後に権限のないチャンクを除く設計では、情報がモデルへ渡る可能性があるため、検索前に権限で空間を絞る設計が重要です。

まとめ

本記事では、RAGシステム構築における「検索精度」「コスト」「データ機密性」といった実務課題に対し、ローカル×クラウドのRAGハイブリッド構成が有効な解決策となることを解説しました。

具体的には、ローカル環境でのデータ準備、埋め込み、ベクトルストアの構築、そしてローカルLLMとの連携方法をハンズオン形式で示し、機密データの保護とコスト最適化を実現する手法を紹介しました。また、検索精度の向上策としてのハイブリッド検索やリランキング、ハルシネーション対策、そしてRAGのコスト最適化戦略についても深掘りしました。

RAGハイブリッド構成を導入することで、開発・テストの柔軟性を高めつつ、本番運用におけるスケーラビリティと堅牢性、そして何よりもセキュリティと経済性を両立したRAGシステムを実現できます。

次のステップとして、ご自身のプロジェクトの要件に合わせて、どのコンポーネントをローカルに置き、どのコンポーネントをクラウドに委ねるかを検討してみてください。そして、今回紹介したベストプラクティスを参考に、段階的にシステムを構築し、評価と改善を繰り返していくことが成功への鍵となるでしょう。

より詳細な情報や最新の動向については、LangChainやLlamaIndex、各クラウドプロバイダーの公式ドキュメントを参照することをお勧めします。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?