LangGraph：書類要約ワークフローの構築

!pip install langgraph langchain_openai langchain_core

import os
import glob
from typing import TypedDict, Annotated, List, Literal
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, AIMessage

# 環境変数・モデルの準備
from google.colab import userdata
os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
model = ChatOpenAI(model="gpt-4o-mini")

# 状態の定義
class SummarizationState(TypedDict):
    files: Annotated[List[str], "処理すべきファイルのリスト"]
    current_file: Annotated[str, "現在処理中のファイル"]
    summaries: Annotated[dict[str, str], "各ファイルの要約"]
    messages: Annotated[List[HumanMessage | AIMessage], "メッセージ履歴"]

# ファイル読み込みツール（Agentから使用される）
def read_file(file_path: str) -> str:
    try:
        with open(file_path, 'r', encoding='utf-8') as file:
            return file.read()
    except IOError as e:
        print(f"ファイルの読み込みエラー: {e}")
        return f"ファイル '{file_path}' の読み込みに失敗しました。"

# ファイル選択ツール（Tool Node）
def select_next_file(state: SummarizationState) -> SummarizationState:
    if state['files']:
        state['current_file'] = state['files'].pop(0)
    else:
        state['current_file'] = None
    return state

# 要約エージェント
def summarize_agent(state: SummarizationState) -> SummarizationState:
    if state['current_file']:
        file_content = read_file(state['current_file'])
        human_message = HumanMessage(content=f"以下の内容を要約してください:\n\n{file_content}")
        ai_message = model.invoke([human_message])
        state['summaries'][state['current_file']] = ai_message.content
        state['messages'].extend([human_message, ai_message])
    return state

# 続行するかどうかを決定する関数
def should_continue(state: SummarizationState) -> Literal["select_file", END]:
    if state['files']:
        return "select_file"
    return END

# グラフの構築
workflow = StateGraph(SummarizationState)

# ノードの追加
workflow.add_node("select_file", select_next_file)
workflow.add_node("summarize", summarize_agent)

# エッジの追加
workflow.add_edge("select_file", "summarize")

# 条件付きエッジの追加
workflow.add_conditional_edges(
    # 開始ノードを定義
    "summarize",
    # 次に呼び出されるノードを決定する関数を渡す
    should_continue,
)

# エントリーポイントの設定
workflow.set_entry_point("select_file")

# グラフのコンパイル
app = workflow.compile()

from IPython.display import Image, display
display(Image(app.get_graph().draw_mermaid_png()))

# documentsフォルダ内の全ファイルを取得
documents_path = os.path.join(os.getcwd(), 'documents')
all_files = glob.glob(os.path.join(documents_path, '**', '*.*'), recursive=True)
print(all_files)

# 初期状態の設定
initial_state = SummarizationState(
    files=all_files,
    current_file="",
    summaries={},
    messages=[]
)

# ワークフローの実行
for s in app.stream(
    initial_state,
    config={"recursion_limit": 150}
):
    print(s)
    print("----")

{'select_file': {'files': ['/content/documents/システム機能階層図.md'], 'current_file': '/content/documents/受注業務(標準)の業務フロー.md', 'summaries': {}, 'messages': []}}
----
{'summarize': {'files': ['/content/documents/システム機能階層図.md'], 'current_file': '/content/documents/受注業務(標準)の業務フロー.md', 'summaries': {'/content/documents/受注業務(標準)の業務フロー.md': '受注業務（標準）の業務フローは、顧客からの引き合い（見積依頼）から始まり、販売担当者、販売承認者、倉庫部を経て出荷に至る一連の流れを示しています。具体的には、顧客が見積依頼を行い、販売担当者が申し込み書類を送付後、見積書の確認や契約書の作成を行います。次に、販売承認者が注文書や契約書を確認し、受注内容を登録して出荷予定を決定します。その後、倉庫部で出荷が行われ、出荷依頼メールが送信されます。この業務フローは、各部門が異なるレーンで表現されており、システム間のデータのやり取りも存在しますが、図には明示的には示されていません。新規顧客に関するフローは別紙に記載されています。'}, 'messages': [HumanMessage(content='以下の内容を要約してください:\n\n# 受注業務(標準)の業務フロー\n\n## 3 - 1\n\n- 工事建物DBプロジェクトなどで使用したLFD（Lane Flow Diagram）を用いて業務フローを記述した例を示す。\n- 受注業務を次の３ケースのフローで表現する。\n  - フローNo.1 受注業務（標準）\n  - フローNo.2 受注業務（新規）\n  - フローNo.3 受注業務（OEM製品）\n\n## 受注業務（標準）の業務フロー\n\n```mermaid\ngraph TD\n    subgraph 顧客\n        A[引き合い（見積依頼）]\n        B[注文請書受領]\n    end\n\n    subgraph 販売担当者\n        C[受付け・申込書類送付]\n        D[見積書確認・注文書作成・契約書作成]\n    end\n\n    subgraph 販売承認者\n        E[注文書、契約書確認・注文請書作成、送付・受注内容登録・出荷予定登録]\n    end\n\n    subgraph 倉庫部\n        F[出荷]\n    end\n\n    subgraph システム\n        G[バッチ誘導]\n        H[バッチ誘導]\n        I[出荷依頼メール送信]\n    end\n\n    subgraph 関連システム\n        J[営業システム]\n        K[見積システム]\n    end\n\n    A -->|※電話。ｲﾝﾀｰﾈｯﾄも検討| C\n    C --> D\n    D --> E\n    E --> B\n    E --> F\n    E --> I\n    G --> J\n    H --> K\n    I -->|Mail| F\n\n    style A fill:#f9f,stroke:#333,stroke-width:2px\n    style B fill:#f9f,stroke:#333,stroke-width:2px\n    style C fill:#bbf,stroke:#333,stroke-width:2px\n    style D fill:#bbf,stroke:#333,stroke-width:2px\n    style E fill:#bfb,stroke:#333,stroke-width:2px\n    style F fill:#fbb,stroke:#333,stroke-width:2px\n    style G fill:#ff9,stroke:#333,stroke-width:2px\n    style H fill:#ff9,stroke:#333,stroke-width:2px\n    style I fill:#ff9,stroke:#333,stroke-width:2px\n    style J fill:#f99,stroke:#333,stroke-width:2px\n    style K fill:#f99,stroke:#333,stroke-width:2px\n```\n\n### 補足説明\n- 図中の矢印は業務の流れを示しています。\n- 各部門（顧客、販売担当者、販売承認者、倉庫部、システム、関連システム）は別々のレーンで表現されています。\n- 新規顧客の場合のフロー（信用調査）は別紙で記載されているため、このフロー図には含まれていません。\n- システムと関連システムの間のデータのやり取り（受注データ、出荷データ、顧客管理データ、見積単価データ、得意先マスター）は図中に明示的に示されていませんが、存在します。\n\n## メタデータ\n\n- ID: 3-2s-00702\n- 作成日付: [記載なし]\n- 更新日付: [記載なし]\n- 作成者: [記載なし]\n- 承認者: [記載なし]\n- ソース: SoftwareEngineeringCenter SEC\n'), AIMessage(content='受注業務（標準）の業務フローは、顧客からの引き合い（見積依頼）から始まり、販売担当者、販売承認者、倉庫部を経て出荷に至る一連の流れを示しています。具体的には、顧客が見積依頼を行い、販売担当者が申し込み書類を送付後、見積書の確認や契約書の作成を行います。次に、販売承認者が注文書や契約書を確認し、受注内容を登録して出荷予定を決定します。その後、倉庫部で出荷が行われ、出荷依頼メールが送信されます。この業務フローは、各部門が異なるレーンで表現されており、システム間のデータのやり取りも存在しますが、図には明示的には示されていません。新規顧客に関するフローは別紙に記載されています。', additional_kwargs={'refusal': None}, response_metadata={'token_usage': {'completion_tokens': 232, 'prompt_tokens': 873, 'total_tokens': 1105}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-fde400dc-d558-4d93-84af-3f1236e2a3e9-0', usage_metadata={'input_tokens': 873, 'output_tokens': 232, 'total_tokens': 1105})]}}
----
{'select_file': {'files': [], 'current_file': '/content/documents/システム機能階層図.md', 'summaries': {'/content/documents/受注業務(標準)の業務フロー.md': '受注業務（標準）の業務フローは、顧客からの引き合い（見積依頼）から始まり、販売担当者、販売承認者、倉庫部を経て出荷に至る一連の流れを示しています。具体的には、顧客が見積依頼を行い、販売担当者が申し込み書類を送付後、見積書の確認や契約書の作成を行います。次に、販売承認者が注文書や契約書を確認し、受注内容を登録して出荷予定を決定します。その後、倉庫部で出荷が行われ、出荷依頼メールが送信されます。この業務フローは、各部門が異なるレーンで表現されており、システム間のデータのやり取りも存在しますが、図には明示的には示されていません。新規顧客に関するフローは別紙に記載されています。'}, 'messages': [HumanMessage(content='以下の内容を要約してください:\n\n# 受注業務(標準)の業務フロー\n\n## 3 - 1\n\n- 工事建物DBプロジェクトなどで使用したLFD（Lane Flow Diagram）を用いて業務フローを記述した例を示す。\n- 受注業務を次の３ケースのフローで表現する。\n  - フローNo.1 受注業務（標準）\n  - フローNo.2 受注業務（新規）\n  - フローNo.3 受注業務（OEM製品）\n\n## 受注業務（標準）の業務フロー\n\n```mermaid\ngraph TD\n    subgraph 顧客\n        A[引き合い（見積依頼）]\n        B[注文請書受領]\n    end\n\n    subgraph 販売担当者\n        C[受付け・申込書類送付]\n        D[見積書確認・注文書作成・契約書作成]\n    end\n\n    subgraph 販売承認者\n        E[注文書、契約書確認・注文請書作成、送付・受注内容登録・出荷予定登録]\n    end\n\n    subgraph 倉庫部\n        F[出荷]\n    end\n\n    subgraph システム\n        G[バッチ誘導]\n        H[バッチ誘導]\n        I[出荷依頼メール送信]\n    end\n\n    subgraph 関連システム\n        J[営業システム]\n        K[見積システム]\n    end\n\n    A -->|※電話。ｲﾝﾀｰﾈｯﾄも検討| C\n    C --> D\n    D --> E\n    E --> B\n    E --> F\n    E --> I\n    G --> J\n    H --> K\n    I -->|Mail| F\n\n    style A fill:#f9f,stroke:#333,stroke-width:2px\n    style B fill:#f9f,stroke:#333,stroke-width:2px\n    style C fill:#bbf,stroke:#333,stroke-width:2px\n    style D fill:#bbf,stroke:#333,stroke-width:2px\n    style E fill:#bfb,stroke:#333,stroke-width:2px\n    style F fill:#fbb,stroke:#333,stroke-width:2px\n    style G fill:#ff9,stroke:#333,stroke-width:2px\n    style H fill:#ff9,stroke:#333,stroke-width:2px\n    style I fill:#ff9,stroke:#333,stroke-width:2px\n    style J fill:#f99,stroke:#333,stroke-width:2px\n    style K fill:#f99,stroke:#333,stroke-width:2px\n```\n\n### 補足説明\n- 図中の矢印は業務の流れを示しています。\n- 各部門（顧客、販売担当者、販売承認者、倉庫部、システム、関連システム）は別々のレーンで表現されています。\n- 新規顧客の場合のフロー（信用調査）は別紙で記載されているため、このフロー図には含まれていません。\n- システムと関連システムの間のデータのやり取り（受注データ、出荷データ、顧客管理データ、見積単価データ、得意先マスター）は図中に明示的に示されていませんが、存在します。\n\n## メタデータ\n\n- ID: 3-2s-00702\n- 作成日付: [記載なし]\n- 更新日付: [記載なし]\n- 作成者: [記載なし]\n- 承認者: [記載なし]\n- ソース: SoftwareEngineeringCenter SEC\n'), AIMessage(content='受注業務（標準）の業務フローは、顧客からの引き合い（見積依頼）から始まり、販売担当者、販売承認者、倉庫部を経て出荷に至る一連の流れを示しています。具体的には、顧客が見積依頼を行い、販売担当者が申し込み書類を送付後、見積書の確認や契約書の作成を行います。次に、販売承認者が注文書や契約書を確認し、受注内容を登録して出荷予定を決定します。その後、倉庫部で出荷が行われ、出荷依頼メールが送信されます。この業務フローは、各部門が異なるレーンで表現されており、システム間のデータのやり取りも存在しますが、図には明示的には示されていません。新規顧客に関するフローは別紙に記載されています。', additional_kwargs={'refusal': None}, response_metadata={'token_usage': {'completion_tokens': 232, 'prompt_tokens': 873, 'total_tokens': 1105}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-fde400dc-d558-4d93-84af-3f1236e2a3e9-0', usage_metadata={'input_tokens': 873, 'output_tokens': 232, 'total_tokens': 1105})]}}
----
{'summarize': {'files': [], 'current_file': '/content/documents/システム機能階層図.md', 'summaries': {'/content/documents/受注業務(標準)の業務フロー.md': '受注業務（標準）の業務フローは、顧客からの引き合い（見積依頼）から始まり、販売担当者、販売承認者、倉庫部を経て出荷に至る一連の流れを示しています。具体的には、顧客が見積依頼を行い、販売担当者が申し込み書類を送付後、見積書の確認や契約書の作成を行います。次に、販売承認者が注文書や契約書を確認し、受注内容を登録して出荷予定を決定します。その後、倉庫部で出荷が行われ、出荷依頼メールが送信されます。この業務フローは、各部門が異なるレーンで表現されており、システム間のデータのやり取りも存在しますが、図には明示的には示されていません。新規顧客に関するフローは別紙に記載されています。', '/content/documents/システム機能階層図.md': 'この図は、販売管理システム、在庫管理システム、売掛管理システムの機能階層を示しています。\n\n### 販売管理システム\n- **販売業務**には新規取引、受注、出荷が含まれる。\n  - **新規取引**では信用調査、取引受付、外部調査依頼、調査報告書作成、与信設定が行われる。\n  - **受注**では引き合い、見積り、注文受け、出荷指図が行われる。\n  - **出荷**では在庫引当、製造指図、納品、受注台帳更新、売上計上が行われる。\n\n### 在庫管理システム\n- **在庫引当**では在庫確認と在庫引当が行われ、製品有高帳の更新も含まれる。\n\n### 売掛管理システム\n- **債権管理**では債権計上データの取り込みと請求書発行が行われ、入金管理では入金の入力と予定変更が行われる。\n\nこの図は、業務機能を実現する情報システムの階層構造を明確化することを目的としています。'}, 'messages': [HumanMessage(content='以下の内容を要約してください:\n\n# 受注業務(標準)の業務フロー\n\n## 3 - 1\n\n- 工事建物DBプロジェクトなどで使用したLFD（Lane Flow Diagram）を用いて業務フローを記述した例を示す。\n- 受注業務を次の３ケースのフローで表現する。\n  - フローNo.1 受注業務（標準）\n  - フローNo.2 受注業務（新規）\n  - フローNo.3 受注業務（OEM製品）\n\n## 受注業務（標準）の業務フロー\n\n```mermaid\ngraph TD\n    subgraph 顧客\n        A[引き合い（見積依頼）]\n        B[注文請書受領]\n    end\n\n    subgraph 販売担当者\n        C[受付け・申込書類送付]\n        D[見積書確認・注文書作成・契約書作成]\n    end\n\n    subgraph 販売承認者\n        E[注文書、契約書確認・注文請書作成、送付・受注内容登録・出荷予定登録]\n    end\n\n    subgraph 倉庫部\n        F[出荷]\n    end\n\n    subgraph システム\n        G[バッチ誘導]\n        H[バッチ誘導]\n        I[出荷依頼メール送信]\n    end\n\n    subgraph 関連システム\n        J[営業システム]\n        K[見積システム]\n    end\n\n    A -->|※電話。ｲﾝﾀｰﾈｯﾄも検討| C\n    C --> D\n    D --> E\n    E --> B\n    E --> F\n    E --> I\n    G --> J\n    H --> K\n    I -->|Mail| F\n\n    style A fill:#f9f,stroke:#333,stroke-width:2px\n    style B fill:#f9f,stroke:#333,stroke-width:2px\n    style C fill:#bbf,stroke:#333,stroke-width:2px\n    style D fill:#bbf,stroke:#333,stroke-width:2px\n    style E fill:#bfb,stroke:#333,stroke-width:2px\n    style F fill:#fbb,stroke:#333,stroke-width:2px\n    style G fill:#ff9,stroke:#333,stroke-width:2px\n    style H fill:#ff9,stroke:#333,stroke-width:2px\n    style I fill:#ff9,stroke:#333,stroke-width:2px\n    style J fill:#f99,stroke:#333,stroke-width:2px\n    style K fill:#f99,stroke:#333,stroke-width:2px\n```\n\n### 補足説明\n- 図中の矢印は業務の流れを示しています。\n- 各部門（顧客、販売担当者、販売承認者、倉庫部、システム、関連システム）は別々のレーンで表現されています。\n- 新規顧客の場合のフロー（信用調査）は別紙で記載されているため、このフロー図には含まれていません。\n- システムと関連システムの間のデータのやり取り（受注データ、出荷データ、顧客管理データ、見積単価データ、得意先マスター）は図中に明示的に示されていませんが、存在します。\n\n## メタデータ\n\n- ID: 3-2s-00702\n- 作成日付: [記載なし]\n- 更新日付: [記載なし]\n- 作成者: [記載なし]\n- 承認者: [記載なし]\n- ソース: SoftwareEngineeringCenter SEC\n'), AIMessage(content='受注業務（標準）の業務フローは、顧客からの引き合い（見積依頼）から始まり、販売担当者、販売承認者、倉庫部を経て出荷に至る一連の流れを示しています。具体的には、顧客が見積依頼を行い、販売担当者が申し込み書類を送付後、見積書の確認や契約書の作成を行います。次に、販売承認者が注文書や契約書を確認し、受注内容を登録して出荷予定を決定します。その後、倉庫部で出荷が行われ、出荷依頼メールが送信されます。この業務フローは、各部門が異なるレーンで表現されており、システム間のデータのやり取りも存在しますが、図には明示的には示されていません。新規顧客に関するフローは別紙に記載されています。', additional_kwargs={'refusal': None}, response_metadata={'token_usage': {'completion_tokens': 232, 'prompt_tokens': 873, 'total_tokens': 1105}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-fde400dc-d558-4d93-84af-3f1236e2a3e9-0', usage_metadata={'input_tokens': 873, 'output_tokens': 232, 'total_tokens': 1105}), HumanMessage(content='以下の内容を要約してください:\n\n# システム機能階層図\n\n```mermaid\ngraph TD\n    subgraph 販売管理システム\n        A[販売業務]\n        A --> B[新規取引]\n        A --> C[受注]\n        A --> D[出荷]\n        \n        B --> B1[信用調査]\n        B1 --> B11[新規取引受付]\n        B1 --> B12[外部調査依頼]\n        B1 --> B13[調査報告書作成]\n        B1 --> B14[与信設定]\n        \n        C --> C1[引き合い]\n        C --> C2[見積り]\n        C --> C3[注文受け]\n        C --> C4[出荷指図]\n        \n        D --> D1[在庫引当]\n        D --> D2[製造指図]\n        D --> D3[納品]\n        D --> D4[受注台帳更新]\n        D --> D5[売上計上]\n        \n        E[新規取引]\n        E --> E1[新規取引申請]\n        E --> E2[信用調査結果登録]\n        \n        F[受注管理]\n        F --> F1[受注案件登録]\n        F --> F2[受注内容登録]\n        \n        G[出荷管理]\n        G --> G1[出荷予定登録]\n        G --> G2[出荷依頼]\n        \n        E1 --> E11[新規取引申請]\n        E1 --> E12[新規取引申請承認]\n        \n        E2 --> E21[与信限度額登録]\n        E2 --> E22[販売条件登録]\n    end\n    \n    subgraph 在庫管理システム\n        H[在庫引当]\n        H --> H1[在庫確認]\n        H --> H2[在庫引当]\n        \n        I[製品有高帳更新]\n        I --> I1[製品有高帳参照]\n        I --> I2[製品有高帳更新]\n    end\n    \n    subgraph 売掛管理システム\n        J[債権管理]\n        J --> J1[債権計上データ取込]\n        J --> J2[請求書発行]\n        \n        K[入金管理]\n        K --> K1[入金入力]\n        K --> K2[入金予定変更]\n    end\n```\n\n## 補足情報\n\n- ID: 3-2s-00800\n- 作成者: SoftwareEngineeringCenter\n- 承認者: SEC\n\n本図は、業務機能を実現する情報システムの階層構造を明確にすることを目的としています。\n'), AIMessage(content='この図は、販売管理システム、在庫管理システム、売掛管理システムの機能階層を示しています。\n\n### 販売管理システム\n- **販売業務**には新規取引、受注、出荷が含まれる。\n  - **新規取引**では信用調査、取引受付、外部調査依頼、調査報告書作成、与信設定が行われる。\n  - **受注**では引き合い、見積り、注文受け、出荷指図が行われる。\n  - **出荷**では在庫引当、製造指図、納品、受注台帳更新、売上計上が行われる。\n\n### 在庫管理システム\n- **在庫引当**では在庫確認と在庫引当が行われ、製品有高帳の更新も含まれる。\n\n### 売掛管理システム\n- **債権管理**では債権計上データの取り込みと請求書発行が行われ、入金管理では入金の入力と予定変更が行われる。\n\nこの図は、業務機能を実現する情報システムの階層構造を明確化することを目的としています。', additional_kwargs={'refusal': None}, response_metadata={'token_usage': {'completion_tokens': 296, 'prompt_tokens': 624, 'total_tokens': 920}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-7435e7a0-7416-4ae9-9832-487c7309d82d-0', usage_metadata={'input_tokens': 624, 'output_tokens': 296, 'total_tokens': 920})]}}
----

# 最終結果の表示
print("処理完了。最終状態:")
for file_path, summary in s['summarize']['summaries'].items():
    print(f"ファイル: {file_path}")
    print(f"要約: {summary}\n")

処理完了。最終状態:
ファイル: /content/documents/受注業務(標準)の業務フロー.md
要約: 受注業務（標準）の業務フローは、顧客からの引き合い（見積依頼）から始まり、販売担当者、販売承認者、倉庫部を経て出荷に至る一連の流れを示しています。具体的には、顧客が見積依頼を行い、販売担当者が申し込み書類を送付後、見積書の確認や契約書の作成を行います。次に、販売承認者が注文書や契約書を確認し、受注内容を登録して出荷予定を決定します。その後、倉庫部で出荷が行われ、出荷依頼メールが送信されます。この業務フローは、各部門が異なるレーンで表現されており、システム間のデータのやり取りも存在しますが、図には明示的には示されていません。新規顧客に関するフローは別紙に記載されています。

ファイル: /content/documents/システム機能階層図.md
要約: この図は、販売管理システム、在庫管理システム、売掛管理システムの機能階層を示しています。

### 販売管理システム
- **販売業務**には新規取引、受注、出荷が含まれる。
  - **新規取引**では信用調査、取引受付、外部調査依頼、調査報告書作成、与信設定が行われる。
  - **受注**では引き合い、見積り、注文受け、出荷指図が行われる。
  - **出荷**では在庫引当、製造指図、納品、受注台帳更新、売上計上が行われる。

### 在庫管理システム
- **在庫引当**では在庫確認と在庫引当が行われ、製品有高帳の更新も含まれる。

### 売掛管理システム
- **債権管理**では債権計上データの取り込みと請求書発行が行われ、入金管理では入金の入力と予定変更が行われる。

この図は、業務機能を実現する情報システムの階層構造を明確化することを目的としています。