LangGraph：既存ワークフローへのAgentの追加（マルチエージェントワークフローの構築）
先日作成した『書類要約ワークフロー』に新しいAgentを追加して機能拡張する手順を整理します。
『書類要約ワークフロー』の詳しいコードは以下をご参照ください。
1. 追加するもの
前回と今回のワークフローを比較します。
前回は以下のNodeで構成されていました。
select_file: 要約するファイル選択する（ToolNode）
summarize: ファイルを要約する（Agent）
この後に以下のノードを追加します。
create_report: ファイル全体からレポートを作成する（Agent）
2. コードの修正
2.1 Stateの修正
最終レポートを保存するためのfinal_reportをSummarizationStateに追加します。
# 状態の定義
class SummarizationState(TypedDict):
files: Annotated[List[str], "処理すべきファイルのリスト"]
current_file: Annotated[str, "現在処理中のファイル"]
summaries: Annotated[dict[str, str], "各ファイルの要約"]
messages: Annotated[List[HumanMessage | AIMessage], "メッセージ履歴"]
final_report: Annotated[str, "最終的なレポート"] # 追加2.2 Agentを定義
追加するcreate_report_agentを定義します。summarize_agent関数の後ろに追加します。
# レポート作成エージェント（追加）
def create_report_agent(state: SummarizationState) -> SummarizationState:
all_summaries = "\n\n".join(f"{file}: {summary}" for file, summary in state['summaries'].items())
human_message = HumanMessage(content=f"""以下のファイル毎の要約に基づき、ファイル群全体の簡潔な要約を作成してください:
{all_summaries}
""")
overall_summary = model.invoke([human_message])
# 確認ファイルリストを機械的に生成
file_list = "\n".join(state['summaries'].keys())
# 最終レポートを組み立て
state['final_report'] = f"""最終レポート
1. 確認ファイルリスト:
{file_list}
2. 全てのファイルの要約:
{overall_summary.content}
"""
state['messages'].extend([human_message, overall_summary])
return stateここでの処理は以下の通りです。
① summarizeの結果をModelに投げて、ファイル全体の要約を作成
② ファイルリスト、ファイルの要約をレポート形式にまとめる
③ final_reportとmessagesのやり取りをstateに保管
2.3 Conditional Edgeの修正
条件付きエッジ後の動きに変更があります。
前回：残りファイルがないことを確認→END(workflow終了)
今回：残りファイルがないことを確認→create_reportエージェント
上記の変更をshould_continue関数に反映します。
# 続行するかどうかを決定する関数（修正）
def should_continue(state: SummarizationState) -> Literal["select_file", "create_report"]:
if state['files']:
return "select_file"
return "create_report"2.4 Workflow定義の修正
Workflowに以下を追加します。
先ほど定義したcreate_reportエージェント
create_reportエージェントの処理後、ワークフロー終了（END）につながるエッジ
# グラフの構築
workflow = StateGraph(SummarizationState)
# ノードの追加
workflow.add_node("select_file", select_next_file)
workflow.add_node("summarize", summarize_agent)
workflow.add_node("create_report", create_report_agent) # 追加
# エッジの追加
workflow.add_edge("select_file", "summarize")
workflow.add_edge("create_report", END) # 追加
# 条件付きエッジの追加
workflow.add_conditional_edges(
# 開始ノードを定義
"summarize",
# 次に呼び出されるノードを決定する関数を渡す
should_continue,
)
# エントリーポイントの設定
workflow.set_entry_point("select_file")
# グラフのコンパイル
app = workflow.compile()3. 結果確認
これらの変更によってワークフローがきちんと変わっているかを確認します。
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=[],
final_report="", # 追加
)# ワークフローの実行
for s in app.stream(
initial_state,
config={"recursion_limit": 150}
):
print(s)
print("----")これを実行すると以下の結果が得られました。無事、create_reportまで呼び出されています。
{'select_file': {'files': ['/content/documents/受注業務(標準)の業務フロー.md'], 'current_file': '/content/documents/システム機能階層図.md', 'summaries': {}, 'messages': [], 'final_report': ''}}
----
{'summarize': {'files': ['/content/documents/受注業務(標準)の業務フロー.md'], 'current_file': '/content/documents/システム機能階層図.md', 'summaries': {'/content/documents/システム機能階層図.md': 'このシステム機能階層図は、販売管理システム、在庫管理システム、売掛管理システムの業務機能を階層的に示しています。\n\n### 販売管理システム\n1. **販売業務**\n - 新規取引\n - 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）\n - 受注\n - 引き合い、見積り、注文受け、出荷指図\n - 出荷\n - 在庫引当、製造指図、納品、受注台帳更新、売上計上\n\n2. **新規取引**\n - 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）\n\n3. **受注管理**\n - 受注案件登録、受注内容登録\n\n4. **出荷管理**\n - 出荷予定登録、出荷依頼\n\n### 在庫管理システム\n- 在庫引当（在庫確認、在庫引当）\n- 製品有高帳更新（参照、更新）\n\n### 売掛管理システム\n- 債権管理（債権計上データ取込、請求書発行）\n- 入金管理（入金入力、入金予定変更）\n\nこの図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。'}, 'messages': [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### 販売管理システム\n1. **販売業務**\n - 新規取引\n - 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）\n - 受注\n - 引き合い、見積り、注文受け、出荷指図\n - 出荷\n - 在庫引当、製造指図、納品、受注台帳更新、売上計上\n\n2. **新規取引**\n - 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）\n\n3. **受注管理**\n - 受注案件登録、受注内容登録\n\n4. **出荷管理**\n - 出荷予定登録、出荷依頼\n\n### 在庫管理システム\n- 在庫引当（在庫確認、在庫引当）\n- 製品有高帳更新（参照、更新）\n\n### 売掛管理システム\n- 債権管理（債権計上データ取込、請求書発行）\n- 入金管理（入金入力、入金予定変更）\n\nこの図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。', additional_kwargs={'refusal': None}, response_metadata={'token_usage': {'completion_tokens': 355, 'prompt_tokens': 624, 'total_tokens': 979}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-70a75f33-cafd-4a52-8195-b401f9f26015-0', usage_metadata={'input_tokens': 624, 'output_tokens': 355, 'total_tokens': 979})], 'final_report': ''}}
----
{'select_file': {'files': [], 'current_file': '/content/documents/受注業務(標準)の業務フロー.md', 'summaries': {'/content/documents/システム機能階層図.md': 'このシステム機能階層図は、販売管理システム、在庫管理システム、売掛管理システムの業務機能を階層的に示しています。\n\n### 販売管理システム\n1. **販売業務**\n - 新規取引\n - 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）\n - 受注\n - 引き合い、見積り、注文受け、出荷指図\n - 出荷\n - 在庫引当、製造指図、納品、受注台帳更新、売上計上\n\n2. **新規取引**\n - 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）\n\n3. **受注管理**\n - 受注案件登録、受注内容登録\n\n4. **出荷管理**\n - 出荷予定登録、出荷依頼\n\n### 在庫管理システム\n- 在庫引当（在庫確認、在庫引当）\n- 製品有高帳更新（参照、更新）\n\n### 売掛管理システム\n- 債権管理（債権計上データ取込、請求書発行）\n- 入金管理（入金入力、入金予定変更）\n\nこの図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。'}, 'messages': [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### 販売管理システム\n1. **販売業務**\n - 新規取引\n - 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）\n - 受注\n - 引き合い、見積り、注文受け、出荷指図\n - 出荷\n - 在庫引当、製造指図、納品、受注台帳更新、売上計上\n\n2. **新規取引**\n - 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）\n\n3. **受注管理**\n - 受注案件登録、受注内容登録\n\n4. **出荷管理**\n - 出荷予定登録、出荷依頼\n\n### 在庫管理システム\n- 在庫引当（在庫確認、在庫引当）\n- 製品有高帳更新（参照、更新）\n\n### 売掛管理システム\n- 債権管理（債権計上データ取込、請求書発行）\n- 入金管理（入金入力、入金予定変更）\n\nこの図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。', additional_kwargs={'refusal': None}, response_metadata={'token_usage': {'completion_tokens': 355, 'prompt_tokens': 624, 'total_tokens': 979}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-70a75f33-cafd-4a52-8195-b401f9f26015-0', usage_metadata={'input_tokens': 624, 'output_tokens': 355, 'total_tokens': 979})], 'final_report': ''}}
----
{'summarize': {'files': [], 'current_file': '/content/documents/受注業務(標準)の業務フロー.md', 'summaries': {'/content/documents/システム機能階層図.md': 'このシステム機能階層図は、販売管理システム、在庫管理システム、売掛管理システムの業務機能を階層的に示しています。\n\n### 販売管理システム\n1. **販売業務**\n - 新規取引\n - 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）\n - 受注\n - 引き合い、見積り、注文受け、出荷指図\n - 出荷\n - 在庫引当、製造指図、納品、受注台帳更新、売上計上\n\n2. **新規取引**\n - 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）\n\n3. **受注管理**\n - 受注案件登録、受注内容登録\n\n4. **出荷管理**\n - 出荷予定登録、出荷依頼\n\n### 在庫管理システム\n- 在庫引当（在庫確認、在庫引当）\n- 製品有高帳更新（参照、更新）\n\n### 売掛管理システム\n- 債権管理（債権計上データ取込、請求書発行）\n- 入金管理（入金入力、入金予定変更）\n\nこの図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。', '/content/documents/受注業務(標準)の業務フロー.md': '受注業務の標準フローは、顧客からの引き合い（見積依頼）を受け、販売担当者が申込書類を送付し、見積書および契約書を作成する一連のプロセスを示しています。次に販売承認者がこれらを確認し、受注内容を登録し出荷予定を登録します。倉庫部は出荷を行い、システムは出荷依頼メールを送信します。業務フローは異なる部門（顧客、販売担当者、販売承認者、倉庫部、システム、関連システム）をレーンで区分し、業務の流れを明示しています。新規顧客の信用調査に関するフローは別途記載されています。'}, 'messages': [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### 販売管理システム\n1. **販売業務**\n - 新規取引\n - 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）\n - 受注\n - 引き合い、見積り、注文受け、出荷指図\n - 出荷\n - 在庫引当、製造指図、納品、受注台帳更新、売上計上\n\n2. **新規取引**\n - 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）\n\n3. **受注管理**\n - 受注案件登録、受注内容登録\n\n4. **出荷管理**\n - 出荷予定登録、出荷依頼\n\n### 在庫管理システム\n- 在庫引当（在庫確認、在庫引当）\n- 製品有高帳更新（参照、更新）\n\n### 売掛管理システム\n- 債権管理（債権計上データ取込、請求書発行）\n- 入金管理（入金入力、入金予定変更）\n\nこの図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。', additional_kwargs={'refusal': None}, response_metadata={'token_usage': {'completion_tokens': 355, 'prompt_tokens': 624, 'total_tokens': 979}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-70a75f33-cafd-4a52-8195-b401f9f26015-0', usage_metadata={'input_tokens': 624, 'output_tokens': 355, 'total_tokens': 979}), 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': 193, 'prompt_tokens': 873, 'total_tokens': 1066}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-3ca5b8ee-bb9f-4a11-a352-c91b6814b863-0', usage_metadata={'input_tokens': 873, 'output_tokens': 193, 'total_tokens': 1066})], 'final_report': ''}}
----
{'create_report': {'files': [], 'current_file': '/content/documents/受注業務(標準)の業務フロー.md', 'summaries': {'/content/documents/システム機能階層図.md': 'このシステム機能階層図は、販売管理システム、在庫管理システム、売掛管理システムの業務機能を階層的に示しています。\n\n### 販売管理システム\n1. **販売業務**\n - 新規取引\n - 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）\n - 受注\n - 引き合い、見積り、注文受け、出荷指図\n - 出荷\n - 在庫引当、製造指図、納品、受注台帳更新、売上計上\n\n2. **新規取引**\n - 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）\n\n3. **受注管理**\n - 受注案件登録、受注内容登録\n\n4. **出荷管理**\n - 出荷予定登録、出荷依頼\n\n### 在庫管理システム\n- 在庫引当（在庫確認、在庫引当）\n- 製品有高帳更新（参照、更新）\n\n### 売掛管理システム\n- 債権管理（債権計上データ取込、請求書発行）\n- 入金管理（入金入力、入金予定変更）\n\nこの図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。', '/content/documents/受注業務(標準)の業務フロー.md': '受注業務の標準フローは、顧客からの引き合い（見積依頼）を受け、販売担当者が申込書類を送付し、見積書および契約書を作成する一連のプロセスを示しています。次に販売承認者がこれらを確認し、受注内容を登録し出荷予定を登録します。倉庫部は出荷を行い、システムは出荷依頼メールを送信します。業務フローは異なる部門（顧客、販売担当者、販売承認者、倉庫部、システム、関連システム）をレーンで区分し、業務の流れを明示しています。新規顧客の信用調査に関するフローは別途記載されています。'}, 'messages': [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### 販売管理システム\n1. **販売業務**\n - 新規取引\n - 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）\n - 受注\n - 引き合い、見積り、注文受け、出荷指図\n - 出荷\n - 在庫引当、製造指図、納品、受注台帳更新、売上計上\n\n2. **新規取引**\n - 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）\n\n3. **受注管理**\n - 受注案件登録、受注内容登録\n\n4. **出荷管理**\n - 出荷予定登録、出荷依頼\n\n### 在庫管理システム\n- 在庫引当（在庫確認、在庫引当）\n- 製品有高帳更新（参照、更新）\n\n### 売掛管理システム\n- 債権管理（債権計上データ取込、請求書発行）\n- 入金管理（入金入力、入金予定変更）\n\nこの図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。', additional_kwargs={'refusal': None}, response_metadata={'token_usage': {'completion_tokens': 355, 'prompt_tokens': 624, 'total_tokens': 979}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-70a75f33-cafd-4a52-8195-b401f9f26015-0', usage_metadata={'input_tokens': 624, 'output_tokens': 355, 'total_tokens': 979}), 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': 193, 'prompt_tokens': 873, 'total_tokens': 1066}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-3ca5b8ee-bb9f-4a11-a352-c91b6814b863-0', usage_metadata={'input_tokens': 873, 'output_tokens': 193, 'total_tokens': 1066}), HumanMessage(content='以下のファイル毎の要約に基づき、ファイル群全体の簡潔な要約を作成してください:\n\n /content/documents/システム機能階層図.md: このシステム機能階層図は、販売管理システム、在庫管理システム、売掛管理システムの業務機能を階層的に示しています。\n\n### 販売管理システム\n1. **販売業務**\n - 新規取引\n - 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）\n - 受注\n - 引き合い、見積り、注文受け、出荷指図\n - 出荷\n - 在庫引当、製造指図、納品、受注台帳更新、売上計上\n\n2. **新規取引**\n - 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）\n\n3. **受注管理**\n - 受注案件登録、受注内容登録\n\n4. **出荷管理**\n - 出荷予定登録、出荷依頼\n\n### 在庫管理システム\n- 在庫引当（在庫確認、在庫引当）\n- 製品有高帳更新（参照、更新）\n\n### 売掛管理システム\n- 債権管理（債権計上データ取込、請求書発行）\n- 入金管理（入金入力、入金予定変更）\n\nこの図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。\n\n/content/documents/受注業務(標準)の業務フロー.md: 受注業務の標準フローは、顧客からの引き合い（見積依頼）を受け、販売担当者が申込書類を送付し、見積書および契約書を作成する一連のプロセスを示しています。次に販売承認者がこれらを確認し、受注内容を登録し出荷予定を登録します。倉庫部は出荷を行い、システムは出荷依頼メールを送信します。業務フローは異なる部門（顧客、販売担当者、販売承認者、倉庫部、システム、関連システム）をレーンで区分し、業務の流れを明示しています。新規顧客の信用調査に関するフローは別途記載されています。\n '), AIMessage(content='このファイル群は、販売管理システム、在庫管理システム、売掛管理システムの業務機能と受注業務の標準フローを体系的に示しています。システム機能階層図では各システムの業務機能を階層的に整理し、販売業務、新規取引、受注管理、出荷管理、在庫管理、債権管理、入金管理が含まれています。受注業務の標準フローでは、顧客からの引き合いを受けてから出荷に至るまでのプロセスが詳細に説明され、各部門の役割が明示されています。この情報は、業務機能の理解と効率化を図るための基礎となります。', additional_kwargs={'refusal': None}, response_metadata={'token_usage': {'completion_tokens': 186, 'prompt_tokens': 623, 'total_tokens': 809}, 'model_name': 'gpt-4o-mini-2024-07-18', 'system_fingerprint': 'fp_48196bc67a', 'finish_reason': 'stop', 'logprobs': None}, id='run-b8c76703-f17f-4a36-b9bc-57c7d3441918-0', usage_metadata={'input_tokens': 623, 'output_tokens': 186, 'total_tokens': 809})], 'final_report': '最終レポート\n\n1. 確認ファイルリスト:\n/content/documents/システム機能階層図.md\n/content/documents/受注業務(標準)の業務フロー.md\n\n2. 全てのファイルの要約:\nこのファイル群は、販売管理システム、在庫管理システム、売掛管理システムの業務機能と受注業務の標準フローを体系的に示しています。システム機能階層図では各システムの業務機能を階層的に整理し、販売業務、新規取引、受注管理、出荷管理、在庫管理、債権管理、入金管理が含まれています。受注業務の標準フローでは、顧客からの引き合いを受けてから出荷に至るまでのプロセスが詳細に説明され、各部門の役割が明示されています。この情報は、業務機能の理解と効率化を図るための基礎となります。\n'}}
----最終状態をわかりやすく表示してみます。
# 最終結果の表示
print("処理完了。最終状態:")
print("----")
for file_path, summary in s['create_report']['summaries'].items():
print(f"ファイル: {file_path}")
print(f"要約: {summary}\n")
print("----")
print(s['create_report']['final_report'])結果は以下のように出力されます。
処理完了。最終状態:
----
ファイル: /content/documents/システム機能階層図.md
要約: このシステム機能階層図は、販売管理システム、在庫管理システム、売掛管理システムの業務機能を階層的に示しています。
### 販売管理システム
1. **販売業務**
- 新規取引
- 信用調査（取引受付、外部調査依頼、調査報告書作成、与信設定）
- 受注
- 引き合い、見積り、注文受け、出荷指図
- 出荷
- 在庫引当、製造指図、納品、受注台帳更新、売上計上
2. **新規取引**
- 新規取引申請（申請、申請承認）、信用調査結果登録（与信限度額登録、販売条件登録）
3. **受注管理**
- 受注案件登録、受注内容登録
4. **出荷管理**
- 出荷予定登録、出荷依頼
### 在庫管理システム
- 在庫引当（在庫確認、在庫引当）
- 製品有高帳更新（参照、更新）
### 売掛管理システム
- 債権管理（債権計上データ取込、請求書発行）
- 入金管理（入金入力、入金予定変更）
この図は、業務機能を実現するための情報システムの階層構造を明確にすることを目的としています。
ファイル: /content/documents/受注業務(標準)の業務フロー.md
要約: 受注業務の標準フローは、顧客からの引き合い（見積依頼）を受け、販売担当者が申込書類を送付し、見積書および契約書を作成する一連のプロセスを示しています。次に販売承認者がこれらを確認し、受注内容を登録し出荷予定を登録します。倉庫部は出荷を行い、システムは出荷依頼メールを送信します。業務フローは異なる部門（顧客、販売担当者、販売承認者、倉庫部、システム、関連システム）をレーンで区分し、業務の流れを明示しています。新規顧客の信用調査に関するフローは別途記載されています。
----
最終レポート
1. 確認ファイルリスト:
/content/documents/システム機能階層図.md
/content/documents/受注業務(標準)の業務フロー.md
2. 全てのファイルの要約:
このファイル群は、販売管理システム、在庫管理システム、売掛管理システムの業務機能と受注業務の標準フローを体系的に示しています。システム機能階層図では各システムの業務機能を階層的に整理し、販売業務、新規取引、受注管理、出荷管理、在庫管理、債権管理、入金管理が含まれています。受注業務の標準フローでは、顧客からの引き合いを受けてから出荷に至るまでのプロセスが詳細に説明され、各部門の役割が明示されています。この情報は、業務機能の理解と効率化を図るための基礎となります。きちんと最終レポートが作成されていることが確認できました。
まとめ
LLM-Based Agentを1つから2つに拡張し、Multi Agent Workflowとすることができました。意図通り動いてくれています。
LLM-Based Agentの真髄はやはりReActを使うところにあると思います。今後は、ツールを与えればうまく結果を返してくれるようなAgentを含むワークフローを作成してみたいと考えています。