{"content_id":"5mvogdwkj2","slug":"graph-engineering-ai-agent-workflow-guide","locale":"ja","schema_type":"TechArticle","category":"ai_data","category_name":"AIデータ","title":"グラフエンジニアリング：AIエージェントワークフローを構造化する設計原則","summary":"グラフエンジニアリングは、複雑なAIタスクをノードと遷移ルールに分割し、状態、検証、障害復旧、ユーザー承認を明示的に設計するアプローチである。すべての段階をAIに任せるのではなく、コード・モデル・人間の役割を区別することが核心である。","sponsorship_disclosure":null,"author":{"name":"Injoys 編集部","url":"https://injoys.com/ko/about"},"key_points":["グラフエンジニアリングは、モデルによる一度の回答ではなく、タスク全体の経路、状態、分岐、反復、終了条件を設計する。","ノードはタスクを実行し、エッジは移動経路を定義し、状態は段階間のデータを受け渡し、条件は次の経路を選択する。","ルーティング、並列実行、生成者・評価者の反復、ユーザー承認は、代表的なエージェントグラフのパターンである。","形式検証や数値比較のような決定論的な作業はコードに、曖昧な解釈はAIに、高リスクの意思決定は人間に割り当てるほうが有利である。","運用可能なグラフには、状態スキーマ、再試行の上限、重複実行の防止、可観測性、権限の境界、コスト予算が必要である。"],"content_markdown":"グラフエンジニアリング（Graph Engineering）は、1つのAIモデルの回答品質だけを高めるのではなく、複数のタスクやツールをどのような順序と条件で実行するかを設計するアプローチである。複雑な業務をノードと接続関係で表現すれば、各段階の入力・出力、失敗原因、再試行経路、人による承認ポイントを分けて管理できる。\n\nただし、この表現はまだ業界全体で合意された単一の標準用語ではない。エージェントワークフロー設計、グラフベースのオーケストレーション、マルチエージェント制御を包括する実務的な概念として理解するのが正確である。\n\n## AIエンジニアリングでグラフが登場した背景\n\nAIアプリケーションにおける設計上の関心は、次のように拡張してきた。これは、すべての組織が同様にたどる公式な発展段階というより、相互に補完し合う設計レイヤーである。\n\n| レイヤー | 核心となる問い | 主な設計対象 |\n|---|---|---|\n| プロンプトエンジニアリング | モデルにどのように指示するか？ | 指示文、例、出力形式 |\n| コンテキストエンジニアリング | 判断に必要な情報を何で構成するか？ | 検索結果、メモリ、ツール結果、システムルール |\n| ループエンジニアリング | 計画・実行・検証・修正をどのように繰り返すか？ | 反復条件、評価基準、終了条件 |\n| グラフエンジニアリング | 複数のタスクと判断主体をどの経路でつなぐか？ | ノード、遷移、状態、分岐、並列化、承認 |\n\nプロンプトとコンテキストは、グラフ内でも引き続き必要である。ループもグラフの循環エッジとして表現できる。したがって、グラフエンジニアリングは先行する手法を廃棄する技術ではなく、それらを実行構造の中に配置する上位レベルの設計観点に近い。\n\n## グラフエンジニアリングの構成要素\n\n### ノード\n\nノード（Node）は、1つの明確な責任を持つタスク単位である。LLMの呼び出しだけでなく、データベース照会、検索APIの呼び出し、形式検証、計算、ユーザー承認の待機といった通常のコードもノードになり得る。\n\n優れたノードは入力と出力が明確で、独立してテストできる。`市場調査`のように範囲の広い名前より、`指定業界の最新資料の収集`、`出典の重複除去`、`主張ごとの根拠確認`のように責任を絞るほうがデバッグに有利である。\n\n### エッジ\n\nエッジ（Edge）は、あるノードから次のノードへ移動する遷移である。常に同じ次の段階へ移動する固定エッジ、状態を確認して経路を選択する条件付きエッジ、複数のタスクを同時に開始する分岐エッジがある。\n\n### 状態\n\n状態（State）は、グラフの実行中に共有されるデータである。ユーザーのリクエスト、中間成果物、検索元、エラーコード、承認結果、反復回数などが含まれ得る。\n\n状態は単なる会話履歴とは異なる。どのフィールドが必須なのか、誰が変更できるのか、並列結果をどのように統合するのか、機密情報をいつ削除するのかを、スキーマとルールで定義しなければならない。\n\n### 条件\n\n条件（Condition）は、次の経路を選択するルールである。`出典が3件以上あるか`のような決定的条件は、コードで判定できる。一方、`根拠が結論を十分に裏付けているか`のように意味判断が必要な条件には、モデルによる評価や人によるレビューが必要な場合がある。\n\n## 単一エージェントより制御しやすい理由\n\n1つのエージェントに調査、分析、作成、検証をすべて任せると、結果が誤っていたときに原因を切り分けにくい。計画の誤りなのか、検索漏れなのか、ツール呼び出しの失敗なのか、根拠のない生成なのかが、1つの実行記録に混在するためである。\n\nタスクをグラフに分解すると、次の項目を段階ごとに管理できる。\n\n- ノードごとに許可されたツールとデータへのアクセス権限を制限する。\n- 中間成果物を保存し、独立して評価する。\n- 失敗したノードだけを再実行し、コストと時間を削減する。\n- 重要な外部操作の直前に人の承認を得る。\n- 実行経路、遅延時間、トークン使用量、エラーを追跡する。\n\nしかし、ノードを多く分ければ自動的に信頼性が高まるわけではない。状態の受け渡しが不正確だったり、評価基準が曖昧だったりすると、エラーが複数の段階にわたって増幅される可能性がある。\n\n## 代表的なグラフ活用パターン\n\n### ルーターパターン\n\nルーターは、リクエストの種類やリスクの度合いに応じて異なる経路を選択する。たとえば、返金に関する問い合わせはポリシー検索ノードへ、技術的な障害は診断ノードへ送ることができる。\n\nルーティング基準が単純なキーワードやアカウント状態であれば、コードが適している。文脈を解釈する必要がある場合はモデル分類を使用できるが、信頼度が低いときにデフォルト経路や人によるレビューへ送る安全策が必要である。\n\n### 並列実行パターン\n\n相互に依存しないタスクを同時に実行した後、集約ノードで結合する。市場、顧客、競合他社の調査を並列で実行する方式が代表的である。\n\n並列化は遅延時間を短縮できるが、呼び出し回数と瞬間的なコストは増加する。結果が同じ状態フィールドを同時に変更する場合は、競合解決ルールとマージ順序も定めなければならない。\n\n### 生成者・評価者パターン\n\n生成者が草案を作成し、評価者が基準に従って合格、修正、または再作成を決定する。評価結果が生成者に戻るため、グラフ内にループが形成される。\n\n評価者もLLMであれば、誤った判定をする可能性がある。可能な項目は、スキーマ検査、テスト実行、引用URLの確認といった決定的な検証で補完し、最大反復回数を設定して無限ループを防がなければならない。\n\n### ユーザー承認パターン\n\n外部システムの変更、メッセージ送信、決済、デプロイのように、元に戻すことが難しい、または責任の重い操作の前に実行を中断し、人の判断を待つ。承認画面には最終結果だけを表示するより、実行する操作、使用するデータ、予想される影響、元に戻す方法を併せて提示するほうが安全である。\n\n### 管理者・専門家パターン\n\n管理者ノードがタスクを分解し、検索、分析、作成などの専門ノードに割り当てた後、結果を取りまとめる。役割分担は有用だが、エージェント数を増やすこと自体が目標になってはならない。固定された手順には、明示的なワークフローのほうが予測可能な場合がある。\n\n## AI、コード、人の役割を分ける原則\n\n| タスクの性質 | 優先手段 | 例 |\n|---|---|---|\n| 結果が同一であるべき明確なルール | 通常のコード | 件数計算、日付比較、JSONスキーマ検査 |\n| 自然言語の意味と曖昧さを扱う判断 | AIモデル | 意図分類、要約、草案作成、定性評価 |\n| 責任・倫理・高リスクの判断が必要な決定 | 人 | 外部送信の承認、例外の許可、高リスク措置の承認 |\n\nルールが明確であるにもかかわらずLLMを使用すると、コスト、遅延、非決定性が不必要に増加する。反対に、すべての判断をコードのルールに固定すると、表現が多様な実際の入力を処理しにくい。優れたグラフは3つの手段の長所を組み合わせ、それぞれの境界で入力と出力を検証する。\n\n## ナレッジグラフとグラフエンジニアリングの違い\n\n2つの概念は関連する場合があるが、同一ではない。\n\n- **ナレッジグラフ**は、人、組織、文書、概念のようなエンティティと、その関係を構造化したデータ表現である。\n- **エージェント実行グラフ**は、タスクがどのような順序と条件で実行されるかを表現する。\n- **グラフエンジニアリング**は、実行グラフの構造、状態、制御、検証、運用方法を設計する実務を指し得る。\n\nナレッジグラフ検索を1つのノードとして接続することはできるが、グラフエンジニアリングにナレッジグラフが必ず必要なわけではない。反対に、ナレッジグラフを構築したからといって、再試行や承認経路を備えたエージェントワークフローが自動的に作られるわけでもない。\n\n## 運用品質を決定する隠れた設計要素\n\nグラフの図だけでは、本番システムは完成しない。実際の信頼性を左右する要素は、実行セマンティクスと運用契約である。\n\n### 状態契約とバージョン管理\n\n各ノードの入出力スキーマ、必須フィールド、データの出典と更新権限を定義しなければならない。グラフを変更した後でも、すでに中断されていた実行を再開できるよう、状態スキーマとワークフローバージョンの互換性も管理する必要がある。\n\n### 障害復旧と冪等性\n\nネットワークエラーの後にノードを再実行すると、メール送信や決済が重複する可能性がある。外部への副作用があるタスクには、冪等性キー、実行前の確認、補償処理、または重複防止ストレージが必要である。\n\n失敗もすべて同じではない。一時的なAPIエラーは再試行し、誤った入力はユーザーに差し戻し、ポリシー違反は直ちに中断するというように、エラーの種類ごとに経路を区別しなければならない。\n\n### 終了条件とコスト予算\n\n生成者・評価者ループには、最大反復回数、時間制限、トークンまたはコストの上限を設けなければならない。品質向上がわずかであれば終了する、または人に引き継ぐ条件も必要である。\n\nグラフの総コストは、個々のモデル呼び出しコストだけでなく、再試行、並列呼び出し、状態保存、外部ツール、観測システムまで含めて計算しなければならない。\n\n### 可観測性と評価\n\n運用記録には、どのノードとモデルが実行されたか、どの経路が選択されたか、入出力とエラーが何であったかを残す必要がある。ただし、個人情報、認証情報、機密性の高い業務データがログにそのまま保存されないよう、マスキングと保存期間を適用しなければならない。\n\n評価は最終回答のスコアだけで終わらない。ルーティング精度、ツール成功率、根拠充足率、承認前のリスク検知率、平均再試行回数のような、ノードや経路ごとの指標も併せて測定しなければ、ボトルネックを見つけることはできない。\n\n### セキュリティと権限境界\n\n検索文書やユーザー入力に含まれる指示によってシステムルールが変更されるプロンプトインジェクションを考慮しなければならない。モデルが生成したツール引数は実行前に検証し、各ノードには業務遂行に必要な最小限の権限だけを付与する。読み取り、書き込み、削除、外部送信の権限を分離すれば、1つのノードのエラーがシステム全体の事故へ拡大することを抑えられる。\n\n## グラフエンジニアリングが適している場合\n\n次の条件が複数重なるほど、グラフ構造の有用性は高まる。\n\n- 入力に応じて異なる専門処理経路が必要である。\n- 独立したタスクを並列に実行できる。\n- 特定の段階が失敗した場合、定められた地点へ戻る必要がある。\n- 中間成果物を検証または監査する必要がある。\n- 外部システムを変更する前に承認が必要である。\n- 実行時間が長く、中断後に再開したり状態を保存したりする必要がある。\n- ツールごとの権限とデータアクセス範囲を分離する必要がある。\n\n単純な要約、1回の分類、短い質疑応答には、単一のモデル呼び出しや短い逐次パイプラインのほうが適している。グラフの導入によって生じる状態管理、テスト、観測、デプロイの負担が、得られる利益より大きいのであれば、オーバーエンジニアリングである。\n\n## 設計レビューチェックリスト\n\n1. 最終結果と成功基準を測定可能な形で定義する。\n2. 各ノードを1つの責任とテスト可能な入出力に制限する。\n3. 明確なルールはコードで実装し、LLMの判断範囲を最小化する。\n4. 状態スキーマと並列結果のマージルールを定義する。\n5. 再試行可能なエラーと即時中断すべきエラーを区別する。\n6. 反復回数、実行時間、コストの上限を設定する。\n7. 外部への副作用があるノードに、重複実行を防止する仕組みを設ける。\n8. 高リスク操作の前に、人による承認と十分な説明を配置する。\n9. ノード・経路ごとのログ、評価指標、個人情報保護ルールを整備する。\n10. より単純な構造で同じ信頼性を達成できないか、改めて確認する。\n\n## 要点整理\n\n単一エージェントが、有能な従業員1人に複数の業務を一度に任せる方式だとすれば、グラフエンジニアリングは、組織の役割、業務の引き渡し経路、検収手順、承認経路を設計することに近い。\n\n核心はエージェントの数ではなく、制御可能な構造である。どの段階でAIが判断し、どこでコードが検証し、いつ人が責任ある決定を下すのかが明確でなければならない。これに状態契約、障害復旧、可観測性、権限制御、コスト上限が備わってこそ、グラフは単なる図を超えて、運用可能なAIシステムとなる。","content_html":"\u003cp\u003eグラフエンジニアリング（Graph Engineering）は、1つのAIモデルの回答品質だけを高めるのではなく、複数のタスクやツールをどのような順序と条件で実行するかを設計するアプローチである。複雑な業務をノードと接続関係で表現すれば、各段階の入力・出力、失敗原因、再試行経路、人による承認ポイントを分けて管理できる。\u003c/p\u003e\n\u003cp\u003eただし、この表現はまだ業界全体で合意された単一の標準用語ではない。エージェントワークフロー設計、グラフベースのオーケストレーション、マルチエージェント制御を包括する実務的な概念として理解するのが正確である。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#ai%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%A7%E3%82%B0%E3%83%A9%E3%83%95%E3%81%8C%E7%99%BB%E5%A0%B4%E3%81%97%E3%81%9F%E8%83%8C%E6%99%AF\" class=\"anchor\" id=\"aiエンジニアリングでグラフが登場した背景\"\u003e\u003c/a\u003eAIエンジニアリングでグラフが登場した背景\u003c/h2\u003e\n\u003cp\u003eAIアプリケーションにおける設計上の関心は、次のように拡張してきた。これは、すべての組織が同様にたどる公式な発展段階というより、相互に補完し合う設計レイヤーである。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eレイヤー\u003c/th\u003e\n\u003cth\u003e核心となる問い\u003c/th\u003e\n\u003cth\u003e主な設計対象\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"レイヤー\"\u003eプロンプトエンジニアリング\u003c/td\u003e\n\u003ctd data-label=\"核心となる問い\"\u003eモデルにどのように指示するか？\u003c/td\u003e\n\u003ctd data-label=\"主な設計対象\"\u003e指示文、例、出力形式\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"レイヤー\"\u003eコンテキストエンジニアリング\u003c/td\u003e\n\u003ctd data-label=\"核心となる問い\"\u003e判断に必要な情報を何で構成するか？\u003c/td\u003e\n\u003ctd data-label=\"主な設計対象\"\u003e検索結果、メモリ、ツール結果、システムルール\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"レイヤー\"\u003eループエンジニアリング\u003c/td\u003e\n\u003ctd data-label=\"核心となる問い\"\u003e計画・実行・検証・修正をどのように繰り返すか？\u003c/td\u003e\n\u003ctd data-label=\"主な設計対象\"\u003e反復条件、評価基準、終了条件\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"レイヤー\"\u003eグラフエンジニアリング\u003c/td\u003e\n\u003ctd data-label=\"核心となる問い\"\u003e複数のタスクと判断主体をどの経路でつなぐか？\u003c/td\u003e\n\u003ctd data-label=\"主な設計対象\"\u003eノード、遷移、状態、分岐、並列化、承認\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eプロンプトとコンテキストは、グラフ内でも引き続き必要である。ループもグラフの循環エッジとして表現できる。したがって、グラフエンジニアリングは先行する手法を廃棄する技術ではなく、それらを実行構造の中に配置する上位レベルの設計観点に近い。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E3%82%B0%E3%83%A9%E3%83%95%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AE%E6%A7%8B%E6%88%90%E8%A6%81%E7%B4%A0\" class=\"anchor\" id=\"グラフエンジニアリングの構成要素\"\u003e\u003c/a\u003eグラフエンジニアリングの構成要素\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E3%83%8E%E3%83%BC%E3%83%89\" class=\"anchor\" id=\"ノード\"\u003e\u003c/a\u003eノード\u003c/h3\u003e\n\u003cp\u003eノード（Node）は、1つの明確な責任を持つタスク単位である。LLMの呼び出しだけでなく、データベース照会、検索APIの呼び出し、形式検証、計算、ユーザー承認の待機といった通常のコードもノードになり得る。\u003c/p\u003e\n\u003cp\u003e優れたノードは入力と出力が明確で、独立してテストできる。\u003ccode\u003e市場調査\u003c/code\u003eのように範囲の広い名前より、\u003ccode\u003e指定業界の最新資料の収集\u003c/code\u003e、\u003ccode\u003e出典の重複除去\u003c/code\u003e、\u003ccode\u003e主張ごとの根拠確認\u003c/code\u003eのように責任を絞るほうがデバッグに有利である。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E3%82%A8%E3%83%83%E3%82%B8\" class=\"anchor\" id=\"エッジ\"\u003e\u003c/a\u003eエッジ\u003c/h3\u003e\n\u003cp\u003eエッジ（Edge）は、あるノードから次のノードへ移動する遷移である。常に同じ次の段階へ移動する固定エッジ、状態を確認して経路を選択する条件付きエッジ、複数のタスクを同時に開始する分岐エッジがある。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%8A%B6%E6%85%8B\" class=\"anchor\" id=\"状態\"\u003e\u003c/a\u003e状態\u003c/h3\u003e\n\u003cp\u003e状態（State）は、グラフの実行中に共有されるデータである。ユーザーのリクエスト、中間成果物、検索元、エラーコード、承認結果、反復回数などが含まれ得る。\u003c/p\u003e\n\u003cp\u003e状態は単なる会話履歴とは異なる。どのフィールドが必須なのか、誰が変更できるのか、並列結果をどのように統合するのか、機密情報をいつ削除するのかを、スキーマとルールで定義しなければならない。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E6%9D%A1%E4%BB%B6\" class=\"anchor\" id=\"条件\"\u003e\u003c/a\u003e条件\u003c/h3\u003e\n\u003cp\u003e条件（Condition）は、次の経路を選択するルールである。\u003ccode\u003e出典が3件以上あるか\u003c/code\u003eのような決定的条件は、コードで判定できる。一方、\u003ccode\u003e根拠が結論を十分に裏付けているか\u003c/code\u003eのように意味判断が必要な条件には、モデルによる評価や人によるレビューが必要な場合がある。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E5%8D%98%E4%B8%80%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88%E3%82%88%E3%82%8A%E5%88%B6%E5%BE%A1%E3%81%97%E3%82%84%E3%81%99%E3%81%84%E7%90%86%E7%94%B1\" class=\"anchor\" id=\"単一エージェントより制御しやすい理由\"\u003e\u003c/a\u003e単一エージェントより制御しやすい理由\u003c/h2\u003e\n\u003cp\u003e1つのエージェントに調査、分析、作成、検証をすべて任せると、結果が誤っていたときに原因を切り分けにくい。計画の誤りなのか、検索漏れなのか、ツール呼び出しの失敗なのか、根拠のない生成なのかが、1つの実行記録に混在するためである。\u003c/p\u003e\n\u003cp\u003eタスクをグラフに分解すると、次の項目を段階ごとに管理できる。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eノードごとに許可されたツールとデータへのアクセス権限を制限する。\u003c/li\u003e\n\u003cli\u003e中間成果物を保存し、独立して評価する。\u003c/li\u003e\n\u003cli\u003e失敗したノードだけを再実行し、コストと時間を削減する。\u003c/li\u003e\n\u003cli\u003e重要な外部操作の直前に人の承認を得る。\u003c/li\u003e\n\u003cli\u003e実行経路、遅延時間、トークン使用量、エラーを追跡する。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eしかし、ノードを多く分ければ自動的に信頼性が高まるわけではない。状態の受け渡しが不正確だったり、評価基準が曖昧だったりすると、エラーが複数の段階にわたって増幅される可能性がある。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E4%BB%A3%E8%A1%A8%E7%9A%84%E3%81%AA%E3%82%B0%E3%83%A9%E3%83%95%E6%B4%BB%E7%94%A8%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3\" class=\"anchor\" id=\"代表的なグラフ活用パターン\"\u003e\u003c/a\u003e代表的なグラフ活用パターン\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E3%83%AB%E3%83%BC%E3%82%BF%E3%83%BC%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3\" class=\"anchor\" id=\"ルーターパターン\"\u003e\u003c/a\u003eルーターパターン\u003c/h3\u003e\n\u003cp\u003eルーターは、リクエストの種類やリスクの度合いに応じて異なる経路を選択する。たとえば、返金に関する問い合わせはポリシー検索ノードへ、技術的な障害は診断ノードへ送ることができる。\u003c/p\u003e\n\u003cp\u003eルーティング基準が単純なキーワードやアカウント状態であれば、コードが適している。文脈を解釈する必要がある場合はモデル分類を使用できるが、信頼度が低いときにデフォルト経路や人によるレビューへ送る安全策が必要である。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E4%B8%A6%E5%88%97%E5%AE%9F%E8%A1%8C%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3\" class=\"anchor\" id=\"並列実行パターン\"\u003e\u003c/a\u003e並列実行パターン\u003c/h3\u003e\n\u003cp\u003e相互に依存しないタスクを同時に実行した後、集約ノードで結合する。市場、顧客、競合他社の調査を並列で実行する方式が代表的である。\u003c/p\u003e\n\u003cp\u003e並列化は遅延時間を短縮できるが、呼び出し回数と瞬間的なコストは増加する。結果が同じ状態フィールドを同時に変更する場合は、競合解決ルールとマージ順序も定めなければならない。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%94%9F%E6%88%90%E8%80%85%E8%A9%95%E4%BE%A1%E8%80%85%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3\" class=\"anchor\" id=\"生成者評価者パターン\"\u003e\u003c/a\u003e生成者・評価者パターン\u003c/h3\u003e\n\u003cp\u003e生成者が草案を作成し、評価者が基準に従って合格、修正、または再作成を決定する。評価結果が生成者に戻るため、グラフ内にループが形成される。\u003c/p\u003e\n\u003cp\u003e評価者もLLMであれば、誤った判定をする可能性がある。可能な項目は、スキーマ検査、テスト実行、引用URLの確認といった決定的な検証で補完し、最大反復回数を設定して無限ループを防がなければならない。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E6%89%BF%E8%AA%8D%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3\" class=\"anchor\" id=\"ユーザー承認パターン\"\u003e\u003c/a\u003eユーザー承認パターン\u003c/h3\u003e\n\u003cp\u003e外部システムの変更、メッセージ送信、決済、デプロイのように、元に戻すことが難しい、または責任の重い操作の前に実行を中断し、人の判断を待つ。承認画面には最終結果だけを表示するより、実行する操作、使用するデータ、予想される影響、元に戻す方法を併せて提示するほうが安全である。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%AE%A1%E7%90%86%E8%80%85%E5%B0%82%E9%96%80%E5%AE%B6%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3\" class=\"anchor\" id=\"管理者専門家パターン\"\u003e\u003c/a\u003e管理者・専門家パターン\u003c/h3\u003e\n\u003cp\u003e管理者ノードがタスクを分解し、検索、分析、作成などの専門ノードに割り当てた後、結果を取りまとめる。役割分担は有用だが、エージェント数を増やすこと自体が目標になってはならない。固定された手順には、明示的なワークフローのほうが予測可能な場合がある。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#ai%E3%82%B3%E3%83%BC%E3%83%89%E4%BA%BA%E3%81%AE%E5%BD%B9%E5%89%B2%E3%82%92%E5%88%86%E3%81%91%E3%82%8B%E5%8E%9F%E5%89%87\" class=\"anchor\" id=\"aiコード人の役割を分ける原則\"\u003e\u003c/a\u003eAI、コード、人の役割を分ける原則\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eタスクの性質\u003c/th\u003e\n\u003cth\u003e優先手段\u003c/th\u003e\n\u003cth\u003e例\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"タスクの性質\"\u003e結果が同一であるべき明確なルール\u003c/td\u003e\n\u003ctd data-label=\"優先手段\"\u003e通常のコード\u003c/td\u003e\n\u003ctd data-label=\"例\"\u003e件数計算、日付比較、JSONスキーマ検査\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"タスクの性質\"\u003e自然言語の意味と曖昧さを扱う判断\u003c/td\u003e\n\u003ctd data-label=\"優先手段\"\u003eAIモデル\u003c/td\u003e\n\u003ctd data-label=\"例\"\u003e意図分類、要約、草案作成、定性評価\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"タスクの性質\"\u003e責任・倫理・高リスクの判断が必要な決定\u003c/td\u003e\n\u003ctd data-label=\"優先手段\"\u003e人\u003c/td\u003e\n\u003ctd data-label=\"例\"\u003e外部送信の承認、例外の許可、高リスク措置の承認\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eルールが明確であるにもかかわらずLLMを使用すると、コスト、遅延、非決定性が不必要に増加する。反対に、すべての判断をコードのルールに固定すると、表現が多様な実際の入力を処理しにくい。優れたグラフは3つの手段の長所を組み合わせ、それぞれの境界で入力と出力を検証する。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E3%83%8A%E3%83%AC%E3%83%83%E3%82%B8%E3%82%B0%E3%83%A9%E3%83%95%E3%81%A8%E3%82%B0%E3%83%A9%E3%83%95%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AE%E9%81%95%E3%81%84\" class=\"anchor\" id=\"ナレッジグラフとグラフエンジニアリングの違い\"\u003e\u003c/a\u003eナレッジグラフとグラフエンジニアリングの違い\u003c/h2\u003e\n\u003cp\u003e2つの概念は関連する場合があるが、同一ではない。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eナレッジグラフ\u003c/strong\u003eは、人、組織、文書、概念のようなエンティティと、その関係を構造化したデータ表現である。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eエージェント実行グラフ\u003c/strong\u003eは、タスクがどのような順序と条件で実行されるかを表現する。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eグラフエンジニアリング\u003c/strong\u003eは、実行グラフの構造、状態、制御、検証、運用方法を設計する実務を指し得る。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eナレッジグラフ検索を1つのノードとして接続することはできるが、グラフエンジニアリングにナレッジグラフが必ず必要なわけではない。反対に、ナレッジグラフを構築したからといって、再試行や承認経路を備えたエージェントワークフローが自動的に作られるわけでもない。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E9%81%8B%E7%94%A8%E5%93%81%E8%B3%AA%E3%82%92%E6%B1%BA%E5%AE%9A%E3%81%99%E3%82%8B%E9%9A%A0%E3%82%8C%E3%81%9F%E8%A8%AD%E8%A8%88%E8%A6%81%E7%B4%A0\" class=\"anchor\" id=\"運用品質を決定する隠れた設計要素\"\u003e\u003c/a\u003e運用品質を決定する隠れた設計要素\u003c/h2\u003e\n\u003cp\u003eグラフの図だけでは、本番システムは完成しない。実際の信頼性を左右する要素は、実行セマンティクスと運用契約である。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%8A%B6%E6%85%8B%E5%A5%91%E7%B4%84%E3%81%A8%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%AE%A1%E7%90%86\" class=\"anchor\" id=\"状態契約とバージョン管理\"\u003e\u003c/a\u003e状態契約とバージョン管理\u003c/h3\u003e\n\u003cp\u003e各ノードの入出力スキーマ、必須フィールド、データの出典と更新権限を定義しなければならない。グラフを変更した後でも、すでに中断されていた実行を再開できるよう、状態スキーマとワークフローバージョンの互換性も管理する必要がある。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E9%9A%9C%E5%AE%B3%E5%BE%A9%E6%97%A7%E3%81%A8%E5%86%AA%E7%AD%89%E6%80%A7\" class=\"anchor\" id=\"障害復旧と冪等性\"\u003e\u003c/a\u003e障害復旧と冪等性\u003c/h3\u003e\n\u003cp\u003eネットワークエラーの後にノードを再実行すると、メール送信や決済が重複する可能性がある。外部への副作用があるタスクには、冪等性キー、実行前の確認、補償処理、または重複防止ストレージが必要である。\u003c/p\u003e\n\u003cp\u003e失敗もすべて同じではない。一時的なAPIエラーは再試行し、誤った入力はユーザーに差し戻し、ポリシー違反は直ちに中断するというように、エラーの種類ごとに経路を区別しなければならない。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%B5%82%E4%BA%86%E6%9D%A1%E4%BB%B6%E3%81%A8%E3%82%B3%E3%82%B9%E3%83%88%E4%BA%88%E7%AE%97\" class=\"anchor\" id=\"終了条件とコスト予算\"\u003e\u003c/a\u003e終了条件とコスト予算\u003c/h3\u003e\n\u003cp\u003e生成者・評価者ループには、最大反復回数、時間制限、トークンまたはコストの上限を設けなければならない。品質向上がわずかであれば終了する、または人に引き継ぐ条件も必要である。\u003c/p\u003e\n\u003cp\u003eグラフの総コストは、個々のモデル呼び出しコストだけでなく、再試行、並列呼び出し、状態保存、外部ツール、観測システムまで含めて計算しなければならない。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%8F%AF%E8%A6%B3%E6%B8%AC%E6%80%A7%E3%81%A8%E8%A9%95%E4%BE%A1\" class=\"anchor\" id=\"可観測性と評価\"\u003e\u003c/a\u003e可観測性と評価\u003c/h3\u003e\n\u003cp\u003e運用記録には、どのノードとモデルが実行されたか、どの経路が選択されたか、入出力とエラーが何であったかを残す必要がある。ただし、個人情報、認証情報、機密性の高い業務データがログにそのまま保存されないよう、マスキングと保存期間を適用しなければならない。\u003c/p\u003e\n\u003cp\u003e評価は最終回答のスコアだけで終わらない。ルーティング精度、ツール成功率、根拠充足率、承認前のリスク検知率、平均再試行回数のような、ノードや経路ごとの指標も併せて測定しなければ、ボトルネックを見つけることはできない。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%81%A8%E6%A8%A9%E9%99%90%E5%A2%83%E7%95%8C\" class=\"anchor\" id=\"セキュリティと権限境界\"\u003e\u003c/a\u003eセキュリティと権限境界\u003c/h3\u003e\n\u003cp\u003e検索文書やユーザー入力に含まれる指示によってシステムルールが変更されるプロンプトインジェクションを考慮しなければならない。モデルが生成したツール引数は実行前に検証し、各ノードには業務遂行に必要な最小限の権限だけを付与する。読み取り、書き込み、削除、外部送信の権限を分離すれば、1つのノードのエラーがシステム全体の事故へ拡大することを抑えられる。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E3%82%B0%E3%83%A9%E3%83%95%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%8C%E9%81%A9%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E5%A0%B4%E5%90%88\" class=\"anchor\" id=\"グラフエンジニアリングが適している場合\"\u003e\u003c/a\u003eグラフエンジニアリングが適している場合\u003c/h2\u003e\n\u003cp\u003e次の条件が複数重なるほど、グラフ構造の有用性は高まる。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e入力に応じて異なる専門処理経路が必要である。\u003c/li\u003e\n\u003cli\u003e独立したタスクを並列に実行できる。\u003c/li\u003e\n\u003cli\u003e特定の段階が失敗した場合、定められた地点へ戻る必要がある。\u003c/li\u003e\n\u003cli\u003e中間成果物を検証または監査する必要がある。\u003c/li\u003e\n\u003cli\u003e外部システムを変更する前に承認が必要である。\u003c/li\u003e\n\u003cli\u003e実行時間が長く、中断後に再開したり状態を保存したりする必要がある。\u003c/li\u003e\n\u003cli\u003eツールごとの権限とデータアクセス範囲を分離する必要がある。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e単純な要約、1回の分類、短い質疑応答には、単一のモデル呼び出しや短い逐次パイプラインのほうが適している。グラフの導入によって生じる状態管理、テスト、観測、デプロイの負担が、得られる利益より大きいのであれば、オーバーエンジニアリングである。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E8%A8%AD%E8%A8%88%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%83%AA%E3%82%B9%E3%83%88\" class=\"anchor\" id=\"設計レビューチェックリスト\"\u003e\u003c/a\u003e設計レビューチェックリスト\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e最終結果と成功基準を測定可能な形で定義する。\u003c/li\u003e\n\u003cli\u003e各ノードを1つの責任とテスト可能な入出力に制限する。\u003c/li\u003e\n\u003cli\u003e明確なルールはコードで実装し、LLMの判断範囲を最小化する。\u003c/li\u003e\n\u003cli\u003e状態スキーマと並列結果のマージルールを定義する。\u003c/li\u003e\n\u003cli\u003e再試行可能なエラーと即時中断すべきエラーを区別する。\u003c/li\u003e\n\u003cli\u003e反復回数、実行時間、コストの上限を設定する。\u003c/li\u003e\n\u003cli\u003e外部への副作用があるノードに、重複実行を防止する仕組みを設ける。\u003c/li\u003e\n\u003cli\u003e高リスク操作の前に、人による承認と十分な説明を配置する。\u003c/li\u003e\n\u003cli\u003eノード・経路ごとのログ、評価指標、個人情報保護ルールを整備する。\u003c/li\u003e\n\u003cli\u003eより単純な構造で同じ信頼性を達成できないか、改めて確認する。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E8%A6%81%E7%82%B9%E6%95%B4%E7%90%86\" class=\"anchor\" id=\"要点整理\"\u003e\u003c/a\u003e要点整理\u003c/h2\u003e\n\u003cp\u003e単一エージェントが、有能な従業員1人に複数の業務を一度に任せる方式だとすれば、グラフエンジニアリングは、組織の役割、業務の引き渡し経路、検収手順、承認経路を設計することに近い。\u003c/p\u003e\n\u003cp\u003e核心はエージェントの数ではなく、制御可能な構造である。どの段階でAIが判断し、どこでコードが検証し、いつ人が責任ある決定を下すのかが明確でなければならない。これに状態契約、障害復旧、可観測性、権限制御、コスト上限が備わってこそ、グラフは単なる図を超えて、運用可能なAIシステムとなる。\u003c/p\u003e\n","tags":["生成AI","コンテキストエンジニアリング","ハーネスエンジニアリング","AIエージェント","AI開発","開発ツール"],"faqs":[{"question":"グラフエンジニアリングとは何ですか？","answer":"複雑なAIタスクをノードに分割し、タスク間の遷移経路、共有状態、分岐条件、反復、承認手順を明示的に設計するアプローチである。業界全体で合意された単一の標準用語というより、グラフベースのエージェントオーケストレーションを説明する実務的な表現に近い。"},{"question":"グラフエンジニアリングとプロンプトエンジニアリングはどのように異なりますか？","answer":"プロンプトエンジニアリングは、個々のモデル呼び出しにどのような指示や例を与えるかを扱う。グラフエンジニアリングは、複数のモデル呼び出し、コード、ツール、人間の判断をどのような順序と条件でつなぐかを扱う。プロンプトは、グラフを構成する各ノード内で引き続き使用される。"},{"question":"グラフエンジニアリングとナレッジグラフは同じ概念ですか？","answer":"いいえ。ナレッジグラフはエンティティと関係を構造化したデータであり、エージェント実行グラフはタスクの順序と制御フローを表す。ナレッジグラフ検索を実行グラフの1つのノードとして使用することはできるが、どちらか一方がもう一方の必須条件というわけではない。"},{"question":"すべてのノードをAIエージェントにする必要がありますか？","answer":"その必要はない。個数の計算、日付の比較、形式の検査のように結果が明確なタスクは、通常のコードのほうが速く、安価で、予測可能である。自然言語の解釈と定性的な判断はAIに、責任が重い、または取り消しが難しい決定は人間に任せる方法が適している。"},{"question":"生成者・評価者ループでは、どのように無限反復を防ぎますか？","answer":"最大反復回数、時間とコストの上限、合格基準をあらかじめ定める必要がある。反復しても品質が改善しない場合や、評価の確信度が低い場合は、それまでで最善の結果を返すか、人間によるレビュー経路へ送る終了条件も必要である。"},{"question":"マルチエージェントシステムは、常に単一エージェントより優れていますか？","answer":"いいえ。役割が増えると、呼び出しコスト、状態伝達エラー、遅延、デバッグの負担も増える。専門的な役割間の分離が実際に品質や権限制御に寄与する場合にのみマルチエージェント構造を選択し、固定された手順は通常のコードワークフローで処理するほうがよい場合もある。"},{"question":"グラフの状態には何を保存すべきですか？","answer":"ユーザーのリクエスト、検証済みの中間結果、出典、エラーの種類、反復回数、承認状態など、次の段階に必要なデータだけを保存するのが原則である。フィールドごとの形式と変更権限を定義し、認証情報や不要な個人情報は保存しないか、マスキングする必要がある。"},{"question":"失敗したノードを再試行する際に注意すべき点は何ですか？","answer":"エラーが一時的なものか、入力自体が誤っているのか、ポリシー上中断すべきなのかを、まず区別する必要がある。メール送信、決済、データ変更のように外部への副作用があるタスクでは、冪等性キーと重複実行チェックを使用する必要がある。"},{"question":"グラフエンジニアリングが必要ないタスクは何ですか？","answer":"簡単な要約、短い質疑応答、1回の分類のように、単一の呼び出しで十分なタスクには、通常は必要ない。グラフを追加することで生じる状態管理と運用コストが、品質、制御、または復旧能力の向上を上回るなら、単純な構造を維持するほうがよい。"}],"sources":[{"url":"https://www.anthropic.com/research/building-effective-agents","title":"効果的なエージェントの構築","type":"source"},{"url":"https://github.com/langchain-ai/langgraph","title":"LangGraph","type":"source"},{"url":"https://docs.temporal.io/","title":"Temporalドキュメント","type":"source"},{"url":"https://www.nist.gov/itl/ai-risk-management-framework","title":"NIST AIリスクマネジメントフレームワーク","type":"source"},{"url":"https://github.com/getzep/graphiti","title":"Graphiti","type":"source"},{"url":"https://genai.owasp.org/llm-top-10/","title":"大規模言語モデルアプリケーション向けOWASP Top 10","type":"source"}],"images":[{"id":809,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTA0NzMsInB1ciI6ImJsb2JfaWQifX0=--ef1105ce6a385a669f3ac38d2daca7268be12737/ai-8a9b7d63.webp","is_representative":true,"generation_method":"ai_photo","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"서버실에서 여성이 터치스크린의 연결된 워크플로 그래프를 조작하는 모습","caption":"엔지니어가 노드와 경로로 구성된 AI 에이전트 워크플로를 점검하고 있다.","description":null},"en":{"alt":"Woman operating a connected workflow graph on a touchscreen in a server room","caption":"An engineer examines an AI agent workflow composed of interconnected nodes and paths.","description":null},"ja":{"alt":"サーバールームでタッチ画面上のワークフローグラフを操作する女性","caption":"エンジニアがノードと経路で構成されたAIエージェントのワークフローを確認している。","description":null},"es":{"alt":"Mujer operando un grafo de flujo de trabajo en una pantalla táctil de una sala de servidores","caption":"Una ingeniera examina un flujo de agentes de IA compuesto por nodos y rutas conectados.","description":null},"id":{"alt":"Perempuan mengoperasikan grafik alur kerja pada layar sentuh di ruang server","caption":"Seorang insinyur memeriksa alur kerja agen AI yang tersusun dari simpul dan jalur terhubung.","description":null},"pt":{"alt":"Mulher operando um grafo de fluxo de trabalho em uma tela sensível ao toque numa sala de servidores","caption":"Uma engenheira analisa um fluxo de agentes de IA formado por nós e caminhos interligados.","description":null},"zh-hant":{"alt":"女子在伺服器機房操作觸控螢幕上的工作流程圖","caption":"工程師正在檢視由節點與路徑連接而成的 AI 代理工作流程。","description":null},"de":{"alt":"Frau bedient in einem Serverraum einen vernetzten Workflow-Graphen auf einem Touchscreen","caption":"Eine Ingenieurin prüft einen KI-Agenten-Workflow aus verbundenen Knoten und Pfaden.","description":null}}},{"id":810,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTA0NzksInB1ciI6ImJsb2JfaWQifX0=--dcdc470a0909904f41c12684bf7ee53b4ab8a805/ai-03b3a3b1.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"AI 에이전트, 데이터 대시보드, 보안 단계를 화살표로 연결한 워크플로 다이어그램","caption":"데이터 처리와 검증, 보안, 사람의 승인을 연결하는 AI 에이전트 워크플로를 보여준다.","description":null},"en":{"alt":"Workflow diagram linking AI agents, data dashboards, validation, security, and human review","caption":"The diagram shows a structured AI agent workflow spanning data processing, validation, security, and human approval.","description":null},"ja":{"alt":"AIエージェント、データ画面、検証、セキュリティ、人の確認を矢印で結んだワークフロー図","caption":"データ処理から検証、セキュリティ、人による承認までをつなぐAIエージェントの流れを示している。","description":null},"es":{"alt":"Diagrama de flujo con agentes de IA, paneles de datos, validación, seguridad y revisión humana","caption":"El diagrama muestra un flujo estructurado de agentes de IA con procesamiento, validación, seguridad y aprobación humana.","description":null},"id":{"alt":"Diagram alur yang menghubungkan agen AI, dasbor data, validasi, keamanan, dan tinjauan manusia","caption":"Diagram ini menunjukkan alur kerja agen AI terstruktur dari pemrosesan data hingga validasi, keamanan, dan persetujuan manusia.","description":null},"pt":{"alt":"Diagrama de fluxo com agentes de IA, painéis de dados, validação, segurança e revisão humana","caption":"O diagrama mostra um fluxo estruturado de agentes de IA com processamento, validação, segurança e aprovação humana.","description":null},"zh-hant":{"alt":"以箭頭連結 AI 代理、資料儀表板、驗證、安全與人工審核的工作流程圖","caption":"此圖呈現串聯資料處理、驗證、安全控管與人工核准的 AI 代理工作流程。","description":null},"de":{"alt":"Workflow-Diagramm mit KI-Agenten, Daten-Dashboards, Validierung, Sicherheit und menschlicher Prüfung","caption":"Das Diagramm zeigt einen strukturierten KI-Agenten-Workflow von der Datenverarbeitung bis zur Validierung und Freigabe.","description":null}}}],"published_at":"2026-08-21T02:29:06+09:00","updated_at":"2026-08-21T02:29:06+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/ja/articles/graph-engineering-ai-agent-workflow-guide"}