LangGraph v1.0徹底解説：StateGraphでRAG構築【2025】

「LangChainで複雑な条件分岐やループを実装しようとして、コードが複雑になり挫折した…」そんな経験はありませんか？この記事では、その限界を打ち破るLangGraphの核心を徹底解説。グラフ構造を用いて、柔軟で強力なAIエージェントを構築する具体的な手順を、豊富な図解とコードでマスターできます。

この記事の結論：LangGraphは、エージェントの状態を共有する「StateGraph」を中核に、条件分岐・ループ・HITL（人手介入）・永続化まで一貫管理できる実運用志向のフレームワークです。

• 要点1：StateGraphが基本 ─ 複数ステップや条件分岐、長期対話・中断/再開が少しでも想定されるなら、まずは StateGraph から設計するのが定石。
• 要点2：Graphは軽量フローに ─ Graph でも分岐・ループは可能。ただし共有Stateが不要な軽量ワークフローや明確な入出力変換中心ならGraph、状態管理が要る複雑系はStateGraphに軍配。
• 要点3：MessageGraphはレガシー/非推奨方向 ─ 特にLangGraph.jsではStateGraph＋Messages系Annotationへ移行推奨。Pythonでも新規はStateGraph前提でOK。

Q1. LangChainとLangGraphの最も大きな違いは何ですか？

A. 状態管理とフロー制御の柔軟性です。LangChain（特にLCEL）でも分岐は可能ですが、LangGraphはエージェントの「状態」全体を管理しながら、その状態に応じて次のアクションを動的に決定する複雑なワークフローを、より直感的かつ堅牢に設計できます。

Q2. どのような場合にLangGraphを使うべきですか？

A. 「もし〇〇ならA、△△ならB」といった条件分岐が多数ある場合、処理を中断・再開する必要がある場合、複数のAIエージェントが連携するシステムを構築する場合に特に有効です。

Q3. Checkpointerは必ず使うべきですか？

A. 短時間で完了する単純な処理であれば必須ではありません。しかし、ユーザーとの対話が続くチャットボットや、完了までに数分以上かかる可能性があるタスクを実行するエージェントなど、状態を失いたくないアプリケーションでは実質的に必須の機能です。

LangChainで構築するAIエージェントの基本構造

要約：AIエージェントの基本概念から、その開発を支えるフレームワークLangChainの主要コンポーネントと従来の課題までを解説。AI開発の前提知識を整理します。

AIエージェントの概念と進化

AIエージェントとは、特定の目標に向かって自律的に行動し、環境と相互作用しながら問題を解決する知的なシステムです。従来のチャットボットが単一の入力に対して回答を返すだけだったのに対し、AIエージェントは複数のステップを経て目標達成を目指します。

AIエージェントの最大の利点は、複雑なタスクを自律的にこなせる点にあります。例えば、情報収集、分析、意思決定、そして行動といった一連のプロセスを自動化できるため、人間の作業効率を飛躍的に向上させる可能性を秘めています。

近年のAIエージェントの進化により、以下のような発展が見られます：

• 単純な反応型から計画型へ: 単に刺激に反応するだけでなく、将来を見据えた計画を立てられるようになりました。
• 専門特化から汎用性へ: 特定のタスクだけでなく、様々な領域で活用できるエージェントが登場しています。
• 単独行動から協調行動へ: 複数のエージェントが協力して複雑な問題を解決するマルチエージェントシステムへと発展しています。

LangChainの全体像と主要コンポーネント

LangChainは、大規模言語モデル（LLM）を活用したアプリケーション開発のためのオープンソースフレームワークです。2022年末に登場して以来、LLMベースのアプリケーション開発において最も広く使われているフレームワークの一つとなっています。

LangChainについて詳しくは、筆者の解説記事「LangChain使い方完全ガイド｜OpenAI API連携」もご参照ください（内部リンク最適化済み）。このブログでは、LangChainの基本から応用までを詳しく解説しています。

LangChainは、以下の主要コンポーネントで構成されています：

1. 言語モデル（LLMs）:
   OpenAI、Anthropic、Google、LLaMAなど様々な言語モデルを統一的なインターフェースで利用可能にします。
2. プロンプトテンプレート（Prompts）:
   言語モデルへの指示を動的に構築するためのテンプレート機能を提供します。
3. チェーン（Chains）: 複数のコンポーネントを連携させて一連の処理を行う仕組みです。
4. メモリ（Memory）: 会話の履歴や状態を保持する機能です。
5. ツール（Tools）:
   外部API、データベース、検索エンジンなど外部リソースを活用するための機能です。
6. 検索（Retrieval）:
   ドキュメント検索や情報取得のための機能です。RAG（検索拡張生成）の実装に必須のコンポーネントです。
7. エージェント（Agents）: 自律的に行動し、ツールを適切に選択・利用する機能です。

従来のLangChainの限界と課題

LangChainは多くの強力な機能を提供していますが、複雑なワークフローやエージェントの実装においては、以下のような限界と課題がありました：

❶ 限定的な非線形処理:
従来のLangChain（特に初期のChains）は線形的な処理の流れ（A→B→C）を前提とする設計が主流でした。バージョン0.2以降のLCEL（LangChain Expression Language）により分岐やループも表現可能になりましたが、エージェントの状態に基づいて動的にフローを決定するような、複雑な状態主導の分岐を直感的に設計・管理するのは依然として煩雑でした。

❷ 状態管理の複雑さ:
複数のコンポーネント間での状態の共有や管理が煩雑でした。特に長いチェーンやループを含むフローでは、状態の受け渡しや更新が複雑になりがちでした。

❸ デバッグの難しさ:
複雑なチェーンやエージェントの挙動を理解し、デバッグすることが難しいという課題がありました。処理の流れが視覚的に把握しづらく、問題の特定が困難でした。

LangGraph v1.0で変わるAIエージェント設計の最前線【StateGraph活用】

要約：LangChainの限界を克服するLangGraphの核心、グラフ構造の概念を解説。ノード・エッジ・ステートといった基本要素と、動的な処理分岐を実現する手法を学びます。

LangGraphの基本概念とグラフ構造

LangGraphは、LangChainのエコシステムの一部として開発された、AIエージェントの動作フローを効率的に設計・実装するためのライブラリです。LangChainが提供するコンポーネントをグラフ構造で接続することで、より柔軟で高度なAIエージェントの構築を可能にします。採用事例も、Klarna、LinkedIn、Uber、Elasticといった先進的な企業で増加しています。

開発元とライセンス情報

LangGraphは、LangChainを開発するLangChain, Inc.によって開発・提供されています。LangChainと同様に、LangGraphもオープンソースソフトウェアとして公開されており、MIT ライセンスの下で配布されています。このライセンスにより、商用・非商用を問わず自由に利用・改変が可能です。

LangGraphの核心は、グラフ構造によって処理の流れを表現する点にあります。グラフ理論を応用することで、AIエージェントの行動や意思決定のプロセスを直感的に設計し、管理することが可能になります。

LangGraphをレストランの運営に例えると、次のようになります：

• ノード（Node） は「調理ステーション」のようなもの。それぞれが具体的な作業を担当します。
• エッジ（Edge） は「料理の流れ」を示し、ステーション間の受け渡しルートです。
• ステート（State） は「注文票」のようなもの。処理に必要な情報が記載されています。

ノード、エッジ、ステートの活用法

図2: ノード、エッジ、ステートのイメージ図LangGraphにおけるグラフ構造は主に以下の要素で構成されます。

❶ ノード (Node): 各処理の単位を表します。「ユーザー入力の解析」「情報検索」「回答生成」などの機能をノードとして定義します。

❷ エッジ (Edge): ノード間の接続関係を表し、処理の流れを定義します。

❸ ステート (State): グラフ全体で共有される状態を保持する仕組みです。会話履歴や中間結果などを保存します。通常、`TypedDict`を使って型安全に定義します。

from typing import TypedDict, List, Dict, Any
from langchain_core.messages import BaseMessage

# LangGraphでやり取りされる状態（State）を定義
class AgentState(TypedDict):
    messages: List[BaseMessage]  # 会話履歴をBaseMessageのリストとして管理
    context: Dict[str, Any]      # コンテキスト情報
    tools_used: List[str]        # 使用したツールのリスト

LangGraphのルーティング設計：条件分岐の最適化

LangGraphで特に重要な概念が条件付きエッジ (Conditional Edge)とルーター (Router)です。これらにより、状態に応じて処理の流れを動的に分岐させることができます。

from langgraph.graph import StateGraph, END
from langchain_core.messages import BaseMessage
from typing import TypedDict, List

# 1. ステート定義
class AgentState(TypedDict):
    messages: List[BaseMessage]

# (search_func, summarize_func, respond_func, decide_func は別途定義済みとする)

# 2. グラフビルダー初期化
builder = StateGraph(AgentState)

# 3. ノードの追加
builder.add_node("search_node", search_func)
builder.add_node("summarize_node", summarize_func)
builder.add_node("respond_node", respond_func)
builder.add_node("decision_node", decide_func)

# 4. 条件分岐を定義するルーター関数
def router(state: AgentState) -> str:
    """最後のメッセージの内容に応じて次に進むノードを決定する"""
    last_message = state["messages"][-1]
    
    if "検索" in last_message.content:
        return "search_node"
    elif "要約" in last_message.content:
        return "summarize_node"
    else:
        return "respond_node"

# 5. 条件付きエッジを追加
builder.add_conditional_edges(
    "decision_node",
    router,
    {
        "search_node": "search_node",
        "summarize_node": "summarize_node",
        "respond_node": "respond_node"
    }
)
# 6. エントリーポイントを設定
builder.set_entry_point("decision_node")

# 7. 各処理後の遷移先を定義（ループ構造）
builder.add_edge("search_node", "decision_node") # 検索後は再判断
builder.add_edge("summarize_node", "decision_node") # 要約後も再判断
builder.add_edge("respond_node", END) # 応答したら処理完了

# 8. グラフをビルド
graph = builder.compile()

LangGraphの種類と特性

要約：LangGraphの主要なグラフタイプである「基本グラフ」「メッセージグラフ」「ステートグラフ」それぞれの特徴と用途を比較。最適なグラフ選択の指針を得られます。

基本グラフ、メッセージグラフ、ステートグラフの違い

LangGraphには用途に応じて複数の種類が用意されていますが、現在のベストプラクティスは明確です。

1. ステートグラフ (StateGraph) -【推奨】
最も強力で汎用性が高いグラフ型です。`TypedDict`を用いて型安全な状態定義が可能で、AIエージェントのような複雑なアプリケーション構築に最適です。会話履歴、ツール使用状況、中間結果など、あらゆる情報を一元管理できます。現在の新規開発では、まず`StateGraph`を選択するのが定石です。

2. 基本グラフ (Graph)
任意の型の入出力を持つノードを接続できるシンプルなグラフです。一直線の単純なデータ変換パイプラインなど、用途が限定される場合に適しています。

3. メッセージグラフ (MessageGraph) ─【レガシー/非推奨方向】
LangGraph.jsではStateGraph＋Messages系Annotationへの移行が推奨されており、MessageGraphはレガシー扱いです。Pythonでも新規開発はStateGraphが基本方針。互換は当面維持されますが、将来の扱いは公式アナウンスを参照してください。

グラフのコンパイルと実行

※以下は独立した最小例です（前節の builder とは別）。

LangGraphは「定義」「コンパイル」「実行」の3ステップで動作します。コンパイルされたグラフは `invoke` で最終結果を、`stream` で中間結果をリアルタイムに取得できます。

from langchain_core.messages import HumanMessage
# (builderで定義・ビルド済みとする)
graph = builder.compile()

# 実行
initial_state = {"messages": [HumanMessage(content="東京の天気と、おすすめの服装を検索して")]}
result = graph.invoke(initial_state)

# 中間状態を逐次取得（更新のみ）
for chunk in graph.stream(initial_state, stream_mode="updates"):
    print(chunk)
    print("----")

※ `stream_mode=”updates”` は v1.0 αドキュメント準拠。将来の変更は公式ドキュメントを参照してください。

`graph.stream()` は、ワークフローの途中経過をユーザーに提示したり、詳細なデバッグを行ったりする際に非常に強力です。

LangGraphによるスマートRAGフローの実践 (Graph-based AI Workflow)

要約：検索拡張生成（RAG）をLangGraphで実装する具体的な手法をコードで紹介。毎回検索する非効率をなくし、より賢く、低コストなRAGシステムを構築します。

高度なRAG実装：必要なときだけ検索する

応答を高速化し、無駄なAPIコストを削減するために、ユーザーの質問に応じて「検索が必要か、LLMの内部知識だけで答えられるか」を判断するスマートなRAGを構築します。

from typing import TypedDict, List, Dict
from langchain_core.messages import BaseMessage, AIMessage, HumanMessage
from langchain_core.documents import Document

# (query_extractor_llm, vector_db, llm, search_necessity_llm は外部で定義済みのオブジェクトとする)
# ===========================
# ✅ RAGシステムの状態定義
# ===========================
class RAGState(TypedDict):
    messages: List[BaseMessage]
    query: str
    search_results: List[Document]
    context: str

# ===========================
# 🔍 RAGの各処理ノード (関数として定義)
# ===========================
def extract_query(state: RAGState) -> Dict:
    # (実装は省略)
    pass
def perform_search(state: RAGState) -> Dict:
    # (実装は省略)
    pass
def prepare_context(state: RAGState) -> Dict:
    # (実装は省略)
    pass
def generate_answer(state: RAGState) -> Dict:
    # (実装は省略)
    pass
def direct_answer(state: RAGState) -> Dict:
    # (LLMの知識だけで回答するノード)
    pass

# ===========================
# 🔁 検索の必要性を判断するルーター関数
# ===========================
def search_router(state: RAGState) -> str:
    last_message = state["messages"][-1].content
    needs_search_response = search_necessity_llm.invoke(
        f"この質問に答えるために外部情報の検索が必要ですか？ はい/いいえ で答えてください: {last_message}"
    )
    # LLMの応答の揺らぎを考慮する
    if "はい" in needs_search_response.content or "必要" in needs_search_response.content:
        print(">>> 判断: 検索が必要")
        return "extract_query" # → クエリ抽出から始まるRAGフローへ
    else:
        print(">>> 判断: 検索は不要")
        return "direct_answer" # → LLMの知識だけで直接回答するフローへ

【プロの視点】判断コストとRAG品質向上の定石

このスマートな構成は強力ですが、いくつか実運用上のポイントがあります。

• 判断コストとのトレードオフ: 検索の必要性を判断するためにもLLMコールが発生します。この判断用LLMには、メインのLLMより軽量で高速なモデル（例: Claude 3 Haiku, Gemini 1.5 Flash）を使い、コストと速度のバランスを取るのが定石です。
• 高度な検索技術: 検索精度を高めるため、従来のベクトル検索に加えて、キーワードベースのBM25を組み合わせるハイブリッド検索や、一度取得した検索結果を別のLLMで並べ替える再ランキング（Re-ranking）が有効です。
• 引用と信頼性: 生成した回答に、どの情報を参照したかの引用（Attribution）を明記することで、回答の信頼性が向上し、ハルシネーションを抑制できます。

Agentic RAGのベンチマーク設計：品質×速度×コスト

実運用では、回答品質（人手評価/自動評価）、レイテンシ、推論/検索コストの三点を指標化し、回帰テストをLangSmith等で継続評価するのが定石です。AutoRAGや再ランキング、ハイブリッド検索の導入可否もこの指標で意思決定します。

長期記憶の実装：2025年8月20日に公開されたMongoDB Store for LangGraphにより、
エージェントがセッションを跨いで情報を記憶する長期メモリを実装できます。
短期メモリ（スレッド単位のCheckpointer）を補完し、クロススレッドな永続化を実現。
公式手順：pip install langgraph-store-mongodb

※ 公式ブログ（2025/8/20）でクロスセッション永続化などを解説。詳細仕様は該当エントリを参照してください。

実運用を見据えたAgentic Workflowの要点

要約：開発したエージェントを本番環境で安定稼働させるために不可欠な、永続化、監視、安全性の考え方を解説します。

Checkpointer：エージェントの状態を永続化する

AIエージェントが長時間のタスクを実行する場合や、ユーザーとの対話を中断・再開できるようにするためには、処理の途中の状態（ステート）を保存する仕組みが不可欠です。これを実現するのがCheckpointer（チェックポインター）です。

Checkpointerを使うことで、以下のようなメリットがあります。

• 中断と再開: ユーザーがブラウザを閉じても、後から対話を再開できます。
• 耐障害性: 処理中にエラーが発生しても、最後の状態から処理を再実行できます。
• 監査とデバッグ: 過去の任意の状態を復元し、エージェントの挙動を再現・分析できます。

LangGraphでは、インメモリの`MemorySaver`のほか、`SqliteSaver`や各種クラウドストレージに対応したCheckpointerが提供されており、本番環境ではデータベースなどへの永続化が必須となります。

from langgraph.checkpoint.sqlite import SqliteSaver
from langchain_core.messages import HumanMessage

# 本番は ":memory:" ではなく、"file:checkpoints.db" や実DB接続文字列を推奨
memory = SqliteSaver.from_conn_string("file:checkpoints.db")
graph = builder.compile(checkpointer=memory)

# configでスレッドIDを指定して実行することで、状態が保存・復元される
config = {"configurable": {"thread_id": "user_123"}}
result = graph.invoke(initial_state, config=config)

# 後から同じthread_idで実行すれば、前回の続きから再開できる
result_continued = graph.invoke({"messages": [HumanMessage(content="ありがとう")]}, config=config)

※ SQLiteを使う場合は別途 pip install langgraph-checkpoint-sqlite を実行してください（詳細はPyPIを参照）。その後、from langgraph.checkpoint.sqlite import SqliteSaver をimportしてください。

LangSmithによる監視とツールの安全性

複雑なエージェントの挙動を把握し、問題の原因を特定するために、LangSmithのような観測プラットフォームの利用が推奨されます。LangSmithを使うと、エージェントの内部的な思考プロセス（どのノードを通り、どのツールを呼び出し、どのような結果を得たか）をステップバイステップで視覚的に追跡できます。

また、エージェントにファイル削除やAPI経由でのデータ更新など、リスクの高い操作を許可するツールを渡す場合は、安全策が不可欠です。具体的には、以下のような対策が考えられます。

• スコープの限定: ツールがアクセスできる範囲（ファイルやAPIエンドポイント）を最小限に絞ります。
• 人間による承認: 高リスクなツールを実行する直前に、必ず人間のオペレーターに承認を求めるステップをグラフ内に組み込みます。

LangGraph Platform 最新機能（2025 Q3）：LangSmith監視・Studio Trace Mode・Revision Queueing（詳細は公式Changelog）

• LangSmith UIでのデプロイ監視（2025年7月）：
  LangSmithからPlatformデプロイのCPU/メモリ、APIレイテンシ等を直接監視。ボトルネック特定を迅速化。
• StudioのTrace Mode（2025年8月）：
  Studio内でLangSmithトレースをリアルタイム表示／注釈・データセット登録まで一気通貫。
• Revision Queueing（2025年8月）：
  新バージョンをキュー管理し、段階的ロールアウトと即時ロールバックを両立。

まとめ

本記事の要点を振り返り、LangGraphがAIエージェント開発にもたらす革新性を再確認。複雑なワークフローを直感的に実装できる本ツールの将来性を展望します。

LangGraphは、従来のLangChainが抱えていた状態管理の複雑さを「グラフ理論」によって打ち破る、革新的なフレームワークです。ノード、エッジ、そして特に`StateGraph`と`Checkpointer`を用いることで、条件分岐やループ、中断・再開を含む複雑なAIエージェントのワークフローを、驚くほど直感的かつ堅牢に実装できます。本記事で解説したスマートRAGや実運用を見据えた設計は、皆さまのプロジェクトを次のレベルへ引き上げる確かな一手となるでしょう。

専門用語まとめ

LangGraph

処理の流れをグラフ構造で定義するAIエージェント開発用ライブラリ。複雑な条件分岐や状態管理を得意とする。

Checkpointer

エージェントの状態（ステート）をデータベースなどに保存（永続化）する仕組み。中断・再開や耐障害性を実現する。

LangSmith

LangChain/LangGraphで構築したアプリケーションの実行過程を可視化・デバッグ・評価するための観測プラットフォーム。

RAG (Retrieval-Augmented Generation)

検索拡張生成。LLMが外部データベースを検索し、その情報を基に回答することで、より正確な応答を可能にする技術。

ステート (State)

グラフ全体で共有される「状態」や「データ」。会話履歴や中間結果などを保持するメモ帳の役割。

よくある質問（FAQ）

Q1. LangChainとLangGraphの最も大きな違いは何ですか？

A1. 状態管理とフロー制御の柔軟性です。LangChain（特にLCEL）でも分岐は可能ですが、LangGraphはエージェントの「状態」全体を管理しながら、その状態に応じて次のアクションを動的に決定する複雑なワークフローを、より直感的かつ堅牢に設計できます。

Q2. どのような場合にLangGraphを使うべきですか？

A2. 「もし〇〇ならA、△△ならB」といった条件分岐が多数ある場合、処理を中断・再開する必要がある場合、複数のAIエージェントが連携するシステムを構築する場合に特に有効です。

Q3. Checkpointerは必ず使うべきですか？

A3. 短時間で完了する単純な処理であれば必須ではありません。しかし、ユーザーとの対話が続くチャットボットや、完了までに数分以上かかる可能性があるタスクを実行するエージェントなど、状態を失いたくないアプリケーションでは実質的に必須の機能です。

Q4. LangGraph v1.0αで何が変わりますか？

A4. v1.0αではStateGraph中心の設計方針が明確化し、LangGraph.jsではStateGraph＋Messages系Annotationへの移行が公式に推奨されています。具体的な削除時期は公式のリリースノートを参照してください。加えてPlatformのTrace ModeやRevision Queueing、LangSmith監視が整い、Agentic RAGの本番運用（デバッグ/段階リリース/監視）が容易になります。

Q5. LangGraphとCrewAIやAutoGen、AutoRAGの違いは？

短答：
LangGraphは「グラフ（StateGraph）で制御フローと状態を設計し、永続化・監視まで含めて本番運用に耐えるワークフロー/エージェント基盤」。
CrewAIは「役割ベースのマルチエージェント実装を素早く作るプロダクティビティ重視のフレームワーク」。
AutoGenは「対話駆動のエージェント間協調をプログラミングするMS発の研究/実務両用フレームワーク（v0.4で拡張性と安定性を強化）」。
AutoRAGは「RAGパイプラインのモジュール自動探索・評価に特化した最適化ツール」。

• 設計思想：LangGraphは状態共有＋条件分岐/ループの明示設計（StateGraph, Checkpointer, 監視/デプロイ連携）。CrewAIはロール/タスク定義と編成（crew）に最適化。AutoGenはエージェント同士の会話・ツール実行をコードで記述。AutoRAGはRAG構成の自動探索/評価に専念。
• 本番運用：LangGraphは永続化（Checkpointer）/ストリーミング/デバッグ/デプロイ監視が公式スタックで揃う（LangSmith・PlatformのTrace ModeやRevision Queueing）。CrewAI/AutoGenでも本番構築は可能だが、可観測性やデプロイ統合は自前設計の比重が大きい。AutoRAGは本番推論の基盤ではなく評価・探索が主目的。
• マルチエージェント：LangGraphはグラフで複数エージェントを編成（条件付きエッジ/ルータで制御）。CrewAIは役割ベースのチーム編成が得意。AutoGenは会話ループとツール使用を強化しており研究実装も豊富。
• RAG領域：LangGraphはスマートRAG/Agentic RAGの制御と運用に向く。AutoRAGはBM25/ベクトル/リランク等の組合せを自動探索・評価でき、LangGraphやCrewAI/AutoGenで組んだRAGの改善にも相性が良い。

選び方の目安：
「制御フローの透明性・永続化・監視まで一貫」ならLangGraph。
「役割分担のチームで素早く自動化」ならCrewAI。
「対話駆動の協調とツール連携を柔軟に」ならAutoGen。
「自分のデータでRAG構成を自動で最適化」ならAutoRAG。
実務ではLangGraph（運用
基盤）＋AutoRAG（RAG評価/探索）の併用も有効です。

主な参考サイト

• LangGraph Official Documentation
• LangGraph: Multi-Agent Workflows – LangChain Blog
• LangSmith Documentation
• 機能API版のクロススレッド永続化How-to
• 公式Changelog集約サイト（日時・機能単位で網羅）
• MongoDB公式アナウンス（LangGraph向けStoreの公開）

合わせて読みたい

• CrewAI入門：次世代マルチエージェントフレームワーク解説
• AutoGen入門講座：AIマルチエージェントの未来と活用法
• Agentic RAGとは？AIエージェントでRAGを強化する実践ガイド
• MetaGPT完全ガイド｜MGX商用版と企業導入ROI・事例【2025年版】

更新履歴

• 2025年4月2日 初版公開
• 2025年9月26日 v1.0α対応、FAQ拡充、E-E-A-T強化を含む改訂