LangGraphで始める複数AIモデル連携による次世代ワークフロー構築

2025-06-20

LangGraphで始める複数AIモデル連携による次世代ワークフロー構築

記事をシェアする

こんにちは。経営企画本部AI推進室の窪田です。近年、AIエージェントの進化によって、業務自動化や複雑なタスクの効率化が急速に進んでいます。特に複数のAIモデルやAPI、各種ツールをシームレスに連携させ、柔軟なワークフローを構築できるプラットフォームへの関心が高まっています。

本記事では、その中で話題となっているLangGraphについて、実際の活用事例を交えて紹介します。

背景と課題

ソフトウェア開発におけるリリースノートは、ユーザーに変更点を伝え、リリースの価値を明確にする重要なコミュニケーション手段です。しかし、実際には多くのマージリクエストやIssueを整理し、技術的内容を分かりやすくまとめるには大きな手間が発生します。開発現場では、APIやCI/CDパイプラインを活用し、独自の自動化プロセスを構築していることと思われます。

こうした課題にLangGraphを使ってGitLab APIとLLMを連携することで取り組んだ事例を解説します。

全体構成

今回作成したリリースノート自動生成ツールは、次のような流れで動作します。

GitLab APIからコミット、マージリクエスト、Issue情報を取得し、それをもとにリリースノートを生成します。生成されたリリースノートは、LLMによる複数回の自動レビューと修正を通じて精度を向上させます。最後に人が最終チェックを行い、完成版となります。

以下がワークフローの全体図です。LangGraphの機能で出力できます。

graph TD;
        __start__([__start__]):::first
        collect_commits(collect_commits)
        preprocess_commits(preprocess_commits)
        prepare_llm_input(prepare_llm_input)
        generate_notes(generate_notes)
        review_notes(review_notes)
        human_review(human_review)
        modify_release_notes(modify_release_notes)
        format_output(format_output)
        temp_output(temp_output)
        save_output(save_output)
        cancel_output(cancel_output)
        __end__([__end__]):::last
        __start__ --> collect_commits;
        cancel_output --> __end__;
        collect_commits --> preprocess_commits;
        format_output --> temp_output;
        generate_notes --> review_notes;
        modify_release_notes --> review_notes;
        prepare_llm_input --> generate_notes;
        preprocess_commits --> prepare_llm_input;
        save_output --> __end__;
        temp_output --> human_review;
        review_notes -.  fail  .-> modify_release_notes;
        review_notes -.  pass  .-> format_output;
        human_review -.  approve  .-> save_output;
        human_review -.  reject  .-> cancel_output;

この流れは、普段の手作業では次のように置き換えられます。

作成者がGitLabの情報を収集する
収集した情報をもとにリリースノートを作成し、レビュー担当者に依頼する
作成者とレビュー担当者がやりとりし、一定の品質に達するまでリリースノートを修正・レビューする

このような複雑な作業ですが、LangGraphを活用することで、これら一連の流れを自動化するワークフローを簡単に構築することが可能です。

ここでLangGraphについて簡単に説明します。

LangGraph

LangGraph ⧉は、言語モデル（LLM）を中心としたワークフローを、グラフ形式で直感的に設計し、可視化やデバッグが可能なオープンソースフレームワークです。各処理をノード、処理の流れをエッジとして定義し、これらを組み合わせてワークフローを構築します。条件分岐やループも簡単に実装できるため、複雑な業務プロセスにも柔軟に対応できます。

リリースノート自動生成ツールにおけるLangGraphの活用ポイント

ここでは、リリースノート自動生成ツールにおけるLangGraphの活用ポイントを解説します。

状態管理

今回のように処理が複雑になると、状態管理が難しくなります。LangGraphでは、ワークフロー全体で共通して使う「状態（State）」を定義することで、スムーズに管理できます。

全体構成で紹介したワークフローの冒頭にあたる、GitLabから各種情報を収集するノード（collect_commits）と、その情報の前処理をするノード（preprocess_commits）を例にします。まず、2つのノード間で共有したい状態を、次のように定義します。

1
# 状態の定義
2
class State(TypedDict):
3
    raw_commits: List[Dict[str, Any]]
4
    merge_requests: List[Dict[str, Any]]
5
    issues: List[Any]

定義した状態は、グラフ作成時に引数として渡すだけで利用できます。

1
# グラフ作成
2
builder = StateGraph(State)

状態を更新する場合は、対象の情報を返り値として返すだけです。

1
def collect_from_gitlab(state):
2
    """GitLab APIを使用してリリース情報を収集"""
3

4
（中略）
5

6
    return {
7
        "raw_commits": commits,
8
        "merge_requests": merge_requests,
9
        "issues": issues,
10
    }

状態を取得する場合も、引数で渡される状態から必要な情報を取り出すだけです。

1
def preprocess_commits(state):
2
    """コミット情報を前処理"""
3
    raw_commits = state.get("raw_commits", [])

このように、ワークフロー全体での状態管理がシンプルに実現できます。

AIによるレビューと修正サイクル

リリースノートの品質を向上させるために、システム開発におけるレビュー工程を活用しました。具体的には、LLMによるリリースノートの自動レビュー処理と、そのレビュー結果に基づく自動修正処理を組み合わせています。このレビューと修正のサイクルは、一定の品質基準（スコア）に達するまで自動的に反復実行されます。

以下は、実際に自動レビューを行った際の出力例です。

1
レビュー結果: {
2
    "score": 75,
3
    "reason": [
4
        "リリース情報が明確に記載されているが、バージョン情報やリリース日が不足している。",
5
        "各内容は具体的に記載されているが、詳細な影響範囲が明示されていない。",
6
        "注意事項や既知の問題についての記載がないため、ユーザーが注意すべき点が不明。",
7
        "アップデート手順や導入方法の説明が欠けているため、ユーザーが新機能を利用する際に困難を感じる可能性がある。",
8
        "全体的に分かりやすいが、構成がやや冗長で、情報の優先順位が不明瞭。"
9
    ],
10
    "feedback": [
11
        "リリースノートの冒頭にバージョン情報とリリース日を明記する。",
12
        "各変更点に対して影響範囲を明示し、どのユーザーや機能に影響を与えるかを記載する。",
13
        "注意事項や既知の問題を追加し、ユーザーが事前に知っておくべき情報を提供する。",
14
        "アップデート手順や導入方法を具体的に説明し、ユーザーがスムーズに新機能を利用できるようにする。",
15
        "情報の構成を見直し、重要な情報を先に記載し、冗長な部分を削減することで、より明確で簡潔なリリースノートにする。"
16
    ]
17
}
18

19
レビュー結果: {
20
    "score": 85,
21
    "reason": [
22
        "リリース情報が明確に記載されており、バージョン情報、リリース日、対象システムが明確である。",
23
        "追加箇所や修正箇所が具体的に記載されており、内容が適切である。",
24
        "影響範囲については明示されているが、もう少し具体的にどのユーザーに影響があるかを示すと良い。",
25
        "注意事項や既知の問題についての記載はあるが、具体的な内容が不足している。",
26
        "アップデート手順や導入方法については別途文書を参照するように記載されているが、具体的な手順があればより親切。",
27
        "全体的に分かりやすく構成されているが、もう少し簡潔にまとめることで読みやすさが向上する可能性がある。"
28
    ],
29
    "feedback": [
30
        "影響範囲を具体的に示すために、どのユーザーやシステムに影響があるかを明記する。",
31
        "注意事項や既知の問題について、具体的な内容を追加し、ユーザーが注意すべき点を明確にする。",
32
        "アップデート手順や導入方法を簡潔にまとめ、必要に応じて具体的な手順をリリースノートに含める。",
33
        "全体の文体をもう少し簡潔にし、冗長な表現を避けることで、読みやすさを向上させる。"
34
    ]
35
}

出力内容は以下の通りです。

score：評価点数（0～100）
reason ：その点数となった理由
feedback ：さらなる改善点

レビュー結果が複数回出力される理由は、スコアが80点以上になるまでプロセスを自動的に反復実行する条件を設定しているためです。初回レビューの結果が75点だったため、修正後にレビューが再実行されました。

初回レビューのreasonでは、

1
リリース情報が明確に記載されているが、バージョン情報やリリース日が不足している。
2
注意事項や既知の問題についての記載がないため、ユーザーが注意すべき点が不明。

といった指摘が出ています。2回目（修正後）のレビューでは、

1
リリース情報が明確に記載されており、バージョン情報、リリース日、対象システムが明確である。
2
注意事項や既知の問題についての記載はあるが、具体的な内容が不足している。

と評価が改善されています。このように、レビューと修正を繰り返すことで、リリースノートの詳細さや有用性が着実に向上します。

こうした連携フローもLangGraphの機能を活用することで、簡潔かつ効率的に実現できます。まず、レビュー処理（review_notes）と、指摘内容を反映した修正処理（modify_release_notes）を用意します。これらをそれぞれノードとして定義します。

1
builder.add_node("review_notes", review_release_notes, retry=retry_policy)
2
builder.add_node("modify_release_notes", modify_release_notes, retry=retry_policy)

次に、2つの処理をエッジで接続します。レビューの結果に応じて修正の再実行を分岐させるため、条件付きエッジ（add_conditional_edges）を使用して判定し、修正後は必ず再レビューにつなげるループを構成します。

1
builder.add_conditional_edges("review_notes", check_review_score, path_map={"fail": "modify_release_notes", "pass": "format_output"})
2
builder.add_edge("modify_release_notes", "review_notes")

条件付きエッジでは、第2引数で指定した関数(check_review_score)の返り値によって、次に進むノードが決まります。上記の例では、返り値がfailならmodify_release_notesノード、passならformat_output(リリースノート出力内容の整形)ノードへ進みます。

check_review_score関数は、評価点数が80点以上なら「レビュー完了(pass)」、それ未満なら「修正(fail)」と判断するよう定義します。

1
def check_review_score(state):
2
    if 80 <= state.get('review_score', 0):
3
        return "pass"
4
    return "fail"

以上のように、LangGraphの条件分岐やループ機能を活用することで、レビューと修正のサイクルをワークフローに自然に組み込むことができました。これにより、リリースノートの品質向上プロセスを自動化し、継続的な改善を通じて高品質なドキュメント生成を実現しています。

Human-in-the-Loopの導入

AIによる自動化は非常に強力ですが、最終成果物の品質保証や細かなニュアンスの調整には、人間の判断が不可欠です。LangGraphは、Human-in-the-Loop (HITL) 機能をワークフローに組み込む手段を提供しています。

リリースノート自動生成ツールでも、LLMが作成した案に対し、最後は人が内容を確認・修正できるプロセスを設けています。

HITLを組み込む際は、グラフを一時停止し、その時点の状態を保存して、人間による承認が行われるまで待機する形を取ります。LangGraphでは、グラフのコンパイル時に一時的なデータを保存するメモリ（状態保持先）を指定し、承認が必要なノードでinterrupt関数を使用します。

詳細な実装方法については、以下の公式ドキュメントを参照してください。

https://langchain-ai.github.io/langgraph/how-tos/human_in_the_loop/review-tool-calls/ ⧉ https://langchain-ai.github.io/langgraph/tutorials/customer-support/customer-support/#part-3-conditional-interrupt ⧉

実際の運用では、以下のような手順となります。

LLMが生成したリリースノートが一時ファイル（RELEASE_NOTES_TEMP.md）として保存されます。

ユーザーは内容を確認・修正し、問題がなければ「y」、中止する場合は「n」を入力します。

1
リリースノートの内容（RELEASE_NOTES_TEMP.md）を確認してください。
2
必要に応じて修正し、問題なければ「y」と入力してください。
3
リリースノートの生成を中止する場合は「n」と入力してください。

「y」の場合、確認・修正済みのリリースノートが正式ファイル（RELEASE_NOTES.md）に保存され、処理が完了します。
```
1
y
2
リリースノートを RELEASE_NOTES.md に保存しました
3
リリースノート自動生成処理完了
```

「n」の場合、一時ファイルが削除され、処理を終了します。

1
n
2
RELEASE_NOTES_TEMP.md を削除しました
3
リリースノート自動生成処理完了

今回はHITLの実装を優先し「仮ファイル→承認→正式ファイル」という流れとしましたが、将来的には承認後に外部システムへ直接リリースノートを反映できる形を目指しています。

環境構築

リリースノート自動生成ツールは、Pythonを用いてWindows上で開発しています。作成時には、GitLab APIを利用するためのライブラリやLangGraphなど、必要なライブラリをインストールしています。

1
pip install python-gitlab langgraph openai python-dotenv

APIキーやトークン、エンドポイントなどの値は.envファイル（環境設定ファイル）を用意し、それを使用して環境変数として読み込む設定を行いました。

1
# AzureOpenAI設定
2
AZURE_OPENAI_API_KEY=YOUR_API_KEY_HERE       # 例: abcdef1234567890
3
AZURE_OPENAI_ENDPOINT=https://example.com    # 例: https://api.openai.azure.com/
4
AZURE_OPENAI_DEPLOYMENT=YOUR_DEPLOYMENT_NAME # 例: my-gpt-deployment
5
AZURE_OPENAI_API_VERSION=2023-01-01          # 例: 2023-01-01
6

7
# Git/GitLab設定
8
GITLAB_URL=https://gitlab.com                 # GitLabのインスタンスURL
9
GITLAB_TOKEN=YOUR_ACCESS_TOKEN_HERE           # アクセストークン
10
GITLAB_PROJECT_ID=123456                      # プロジェクトID

コマンドラインから、以下のコマンドを実行することで操作できます。情報取得範囲は、コマンドライン引数でタグを指定することで、柔軟にコントロールできます。

1
python main.py --previous-tag vX.Y.Z --current-tag vA.B.C

たとえば、上記のようにcurrent-tagとprevious-tagを指定すると、2つのタグ間の変更内容をリリースノートの対象として柔軟にコントロールできます。 current-tagを省略した場合は、previous-tag以降の最新のコミットが自動的に対象になります。

1
python main.py --previous-tag vX.Y.Z

比較検証

リリースノート自動生成ツールで生成したリリースノートについて、システム担当者が作成済みのリリースノートを比較してみます。具体的には、2つのリリースノートを以下のプロンプトでgpt-4oに評価してもらいました。いわゆるLLM-as-a-Judgeと呼ばれるアプローチです。

あなたはリリースノートの品質評価を専門とする中立的な審査員です。 2つのリリースノートを以下6つの観点で評価してください。

評価観点

正確性：正しい内容が反映されており、誤解を生まないか。

網羅性：重要な更新点（バグ修正、新機能、仕様変更など）が漏れなく記載されているか。

明瞭さ：表現や説明がわかりやすいか。不明瞭や曖昧な表現がないか。

簡潔さ：冗長な説明を避けて、簡潔に書かれているか。

読みやすさ：構成やレイアウトが適切で、情報が探しやすいか。

ユーザー視点：ユーザーの立場で関心のある・影響の大きい変更が明確に伝わるか。

評価方法

各観点について1・2それぞれに「1～5点」でスコアを付与し、簡単な理由を述べてください。

最終的にどちらが総合的に優れたリリースノートかを判定し、その理由も述べてください。

リリースノート1:

{note1}

リリースノート2:

{note2}

実際の回答は以下の通りです（理由についてはリリースノートの内容が含まれるため、記載を省略しています）。リリースノート1は自動生成されたリリースノートを、リリースノート2は人が作成したリリースノートを指しています。今回は比較のために、自動生成されたリリースノートについては即座に承認し、修正を加えていない状態のまま使用しています。

1
### リリースノート1:
2

3
#### 1. 正確性: **5/5**
4
#### 2. 網羅性: **5/5**
5
#### 3. 明瞭さ: **4/5**
6
#### 4. 簡潔さ: **4/5**
7
#### 5. 読みやすさ: **5/5**
8
#### 6. ユーザー視点: **5/5**
9
**総合スコア: 28/30**
10

11
### リリースノート2:
12

13
#### 1. 正確性: **4/5**
14
#### 2. 網羅性: **3/5**
15
#### 3. 明瞭さ: **3/5**
16
#### 4. 簡潔さ: **5/5**
17
#### 5. 読みやすさ: **4/5**
18
#### 6. ユーザー視点: **3/5**
19
**総合スコア: 22/30**
20

21
### 総合評価
22

23
**リリースノート1**が総合的に優れています。
24

25
#### 理由
26
1. **網羅性**と**正確性**が高く、重要な変更点が漏れなく記載されています。
27
2. **読みやすさ**と**ユーザー視点**が優れており、ユーザーにとって影響の大きい変更が明確に伝わります。
28
3. 一部冗長な箇所はあるものの、全体の構成がしっかりしており、情報を探しやすいです。
29

30
一方、リリースノート2は簡潔で読みやすいものの、背景や意図の説明が不足しており、網羅性やユーザー視点の観点で劣ります。そのため、リリースノート1がより高品質と判断されます。

上記合わせて、3つのバージョンについて評価しました。

リリースノート1（自動生成したリリースノート）

	バージョン①	バージョン②	バージョン③	平均点
正確性	5	5	4	4.7
網羅性	5	5	5	5.0
明瞭さ	4	4	3	3.7
簡潔さ	4	3	3	3.3
読みやすさ	5	4	4	4.3
ユーザー視点	5	5	4	4.7
総合スコア	28	26	23	25.7

リリースノート2（人が作成したリリースノート）

	バージョン①	バージョン②	バージョン③	平均点
正確性	4	4	5	4.3
網羅性	3	3	4	3.3
明瞭さ	3	4	5	4.0
簡潔さ	5	5	5	5.0
読みやすさ	4	5	5	4.7
ユーザー視点	3	3	5	3.7
総合スコア	22	24	29	25.0

自動生成したリリースノートの総合スコアは平均25.7、人が作成したものは25.0と、遜色ない品質を確保できました。

まとめ

今回はLangGraphを活用し、GitLabを用いたリリースノート自動生成ツールを作成し、その品質と実用性について評価を行いました。AIによる自動生成では、正確性や網羅性など一定の効果が確認されました。一方で、業務運用や品質面では改良すべき課題も残っています。具体的な課題としては、以下の点が明らかになっています。

任意のフォーマット指定に対応したリリースノート生成
人による承認後、自動で投稿まで行うワークフローの拡張

今後もLangGraphやAI、関連ツールを積極的に活用し、業務効率化や作業時間の短縮を目指したさらなるワークフローの高度化に取り組んでいきます。

参考文献

LangGraph公式サイト ⧉: ドキュメントやGitHubのページはここからたどれます。
Build a Customer Support Bot ⧉: HITLの実装で特に参考となったサイトです。

記事をシェアする