AI・テクノロジー

ローカルLLMでハードウェア設計を自動化する——MCPツール呼び出しベンチマークが明かしたエージェント設計の実践知

docker agent

• 16 min read
Share

はじめに：設計ツールの操作は、なぜAIエージェントと相性がいいのか

組み込みシステム向けSoC（System-on-Chip）の設計では、コンポーネントの作成、ポートの追加、サブコンポーネントのインスタンス化、配線といった操作を繰り返します。コンポーネントはVLNV（Vendor／Library／Name／Versionの4つ組）で一意に識別される設計部品です。「ベンダーacme、ライブラリcore、名前top、バージョン1.0のコンポーネントを作成し、1bitの入力クロックポートclkを追加して保存する」——こうした定型作業は現場に大量にあり、人手による入力ミスや確認コストの温床になっています。

これらの操作は単なるコマンド列ではありません。ポートが存在しないと接続できず、サブコンポーネントが存在しないとそのポートを参照できない、という強い依存関係があります。つまり設計ツールは「状態を持つアプリケーション」であり、エージェントの仕事は「現在の状態を読み取りながら、正しい順序でツールを呼び続ける」ことです。この「状態付きアプリケーションへの順序付きツール呼び出し」は、推論と行動を交互に繰り返すLLMエージェントの構造と噛み合いがよいのです。

主要ツールもこうした操作をAPIやスクリプトから呼び出せるよう設計されています。商用ではSynopsys Virtualizer、オープンソースではIP-XACT規格準拠のコンポーネントエディタであるKactus2が代表例です。環境が整っているのに自動化が進まない理由は、技術ではなく機密性にあります。部品仕様や命名規則は未発表製品の情報を漏らし得るため、クラウドAPIには送れません。

ある研究（arXiv:2608.26199）は、この制約の下で「ローカルに展開したオープンソースLLMで、エキスパートが定義したハードウェア設計ワークフローを信頼できる形で自動化できるのか」を問いました。具体的には、14ツールを公開するMCPサーバーと8種類のタスクスイートを構築し、7つのオープンソースモデルを評価しています。本記事では、その設計思想とモデル間の実力差を紹介し、「モデル選び以上に、プロンプト・ツール説明・コンテキスト管理・アーキテクチャというエージェント構成が実力を左右する」という実証結果を、実際の運用に生かせる形で解説します。

前提知識：MCPとは何か、なぜローカルLLMなのか

MCP（Model Context Protocol）は、Anthropicが2024年11月に公開したオープン規格で、LLMアプリケーションと外部システムを標準化された形で接続するためのプロトコルです。MCP以前は、LLMにツールを使わせるたびに接続先ごとの個別実装が必要でしたが、MCPはこの接続部分を共通化します。構成は3層で理解できます。アプリケーション側のMCP Host、ホスト内で接続を仲介するMCP Client、そしてツールやリソースを公開する側のMCP Serverです。LLMはサーバーが公開する「ツール」を呼び出すことで、外部世界（ここでは設計ツールの状態）に作用します。

「APIは1対1の接続、MCPはN対Mの標準化」という対比が本質をつかみます。従来のAPIはクライアントとサービスが1組で結ばれており、ツールを増やすたびに接続を個別に実装し直す必要がありました。一方MCPでは、サーバーを1つ実装すれば複数のAIクライアントから同じツール群を呼び出せます。ツール側の実装コストが1回で済む点が最大の利点です。

では、なぜローカルLLMが前提になるのか。最大の理由は機密性です。半導体設計の現場では、部品仕様・ポート名・命名規則が未発表製品の手がかりになり得るため、外部のクラウドAPIに送信できません。研究でも、ホスト型のプロプライエタリAPIを除外し、自社・自宅で稼働するローカルモデルに対象を限定しています。実行環境は、7つのオープンソースモデルをOllamaで4bit量子化したもので、いずれも一般的なワークステーションで稼働する規模です。

flowchart LR
  A[エンジニア] -->|自然言語のタスク| B[MCP Host]
  B --> C[MCP Client]
  C <-->|JSON-RPC| D[MCP Server]
  D --> E[(設計ツールの状態)]
  B --> F[ローカルLLM（Ollama・4bit量子化）]

まとめると、MCPは「AIとツールを繋ぐ標準レイヤー」、ローカルLLMは「機密情報を外に出さないための制約」であり、この2つが本稿の評価対象（モデルとエージェント構成）を評価する土台になります。

実験設計：14ツールのMCPサーバーと8つのタスクスイート

実験では、プロプライエタリな設計ツールの本番APIを直接呼ばず、その「状態・データモデル・依存制約」を忠実に再現する14ツールのMCPサーバーを実装しました（本番APIとベンチマークは機密のため非公開）。ツールは役割別に3系統に分類されます。

分類 ツール
Adder（追加系） create_component、add_signal_port、add_transactional_port、add_user_parameter、add_generator_parameter、add_subcomponent、add_subcomponent_connection
Getter（参照系） get_component_details、get_element、list_components
Other（その他） delete_element、delete_component、save_component、load_component

「ポートが存在してからでないと接続できない」「サブコンポーネントが存在してからでないとそのポートを参照できない」といった依存制約はサーバー側で強制され、違反する呼び出しは拒否されます。

タスクスイートは、プロの設計ユーザーが反復作業を洗い出し、期待呼び出し列を実サーバー上で検証して構築した8種・計340問です。

スイート 問題数 内容
Easy／Medium／Hard 各40 期待呼び出し1回／2回／3〜5回。タスク長の影響を分離
History 40 識別子を省略し「前のタスクで作ったコンポーネント」を文脈から復元
Errors 40 スペルミス混入プロンプト20問＋「正解＝何も呼ばない」20問
Cross 40 依存チェーン・横断参照・パターン展開・エラー検出を1セッションに混在
Easy-Noise／Hard-Noise 各60 GDBデバッグ用とGitバージョン管理用のMCPサーバーを併設し、ルーティング能力を試すマルチサーバー環境

評価はタスク成功ではなくコール（呼び出し）レベルで行われます。後続コールが依存する状態を汚さないよう順序非依存でマッチングし、依存違反はサーバー側が拒否します。指標は次の4つです。ECC（期待呼び出しのうち正しく実行された割合、↑）、EVCR（要求されていないのに成功した余分な呼び出しの割合、↓）、TFR（サーバーに拒否された呼び出しの割合、↓）、NCA（空の期待呼び出しタスクで「正しく何も呼ばない」割合、↑）。

flowchart LR
  T[タスクプロンプト] --> A[エージェント]
  A <--> S[MCPサーバー<br/>14ツール・状態・依存制約]
  A --> C[呼び出し列]
  C --> M{期待呼び出しと照合}
  M -->|正しい| E[ECCに加算]
  M -->|成功だが余分| V[EVCRに加算]
  M -->|サーバー拒否| F[TFRに加算]

結果1：モデルが能力の範囲を決め、構成が実力を決める

7つのオープンソースモデルを同じMCPサーバーに接続し、プロンプト・ツール説明・コンテキスト管理・アーキテクチャを変えながら性能を比較した結果、最も明確な結論は「モデルが能力の範囲を決め、構成が実力を決める」でした。最適ReAct構成での平均ECC（Easy／Medium／Hard／History／Errors／Crossの6スイート）は以下の通りです。

モデル 平均ECC
Gemma 4 31B 0.990
Gemma 4 26B 0.958
GPT-OSS 20B 0.951
Qwen 3.5 27B 0.880
Qwen 3.6 27B 0.858
Gemma 4 E4B 0.811
Llama 3.1 8B 0.554

上位3モデルは0.95以上とほぼ完璧なカバレッジを達成し、ローカルLLMによるハードウェア設計自動化は実用域に入ったと言えます。ただしこれは構成探索後の「最良観測値」であり、初期設定のままの性能ではない点に注意が必要です。

モデル間格差はタスク構造によって拡大します。Gemma 4 E4Bは6スイート中5つで31Bモデルと14%以内の差に収まる一方、依存チェーンを横断するCrossでは0.517対0.972と47%差に開きました。Llama 3.1 8Bも独立タスク（Easy／Medium／Hard）では0.753を出しながら、状態を引き継ぐHistory／Crossでは0.139まで82%低下します。「簡単なタスクの成績は状態依存タスクの成績を予測しない」ことがはっきり表れています。

構成の影響も同規模です。Llama 3.1 8Bの全体最適構成はHistoryでECC 0.113しか出ないのに、History特化の最適構成なら0.538まで回復します。Gemma 4 E4Bも悪い構成では0.811から0.168へ急落します。実力は「モデルの素質」と「構成の良し悪し」の掛け算で決まると言えるでしょう。

エラー処理にも顕著な差が出ました。正解が「何も呼ばないこと」のタスクで正しく沈黙できた割合（NCA）は、Gemma 4 31Bが0.80、Qwen 3.5 27Bが0.70でした。これに対し、GPT-OSS 20Bは0.25、Llama 3.1 8Bは0.00です。失敗には「呼び過ぎる」タイプと「サーバーに拒否されまくる」タイプの2種類があり、モデルによって出現パターンが異なります。

最後に、GDBデバッグ用・Gitバージョン管理用のMCPサーバーを併設したマルチサーバー環境では、全モデルでECCはほぼ不変でした。一方、要求されていないのに成功した余分な呼び出しの割合（EVCR）は上昇します。ツールコンテキストの拡大は「正しい呼び出しの取りこぼし」ではなく「余計な呼び出し」を増やす方向に作用するのです。

結果2：プロンプトとツール説明——小さな設定変更が失敗率を左右する

エージェント構成のうち、まず試しやすいのがシステムプロンプトの書式です。プロンプトをMarkdownで構造化した形式は7モデル中5つで最良のECCを記録したものの、構造化なしや最低限の説明との差は概ね0.04未満と小さいものでした。プロンプト全体の書き換えよりも、後述するツール説明の粒度を調整する方が効果が大きいのです。

一方、few-shot（例題付きプロンプト）は本ベンチマークが最も強調する「落とし穴」です。5モデルではECCの変化が±0.04以内かむしろ改善だったのに対し、Gemma 4 31Bは0.956→0.571、Gemma 4 E4Bは0.731→0.179と激減しました。特徴的なのは「間違える」のではなく「行動しなくなる」ことです。ECC・EVCR・TFRが同時に低下するinaction（無応答）と呼ばれる現象で、呼び出し数そのものが減るため、失敗の内訳を分析する余地もなく性能が崩れます。プロンプト工学には「上振れは小さく、ミスマッチの下振れは致命的」という非対称なリスク構造があると考えてよいでしょう。

最も一貫した改善要因はツール説明の記述量でした。各ツールの目的・パラメータの意味論・制約・失敗条件を盛り込んだ包括的な説明から、1文だけの最小限の説明に切り替えると、全モデルでTFRが悪化し、多くは約2倍に達しました。42のモデル×スイートの組み合わせ中35ケース（83%）で、最良構成が包括的説明を使用しています。実践的な含意はシンプルです。ツール定義に「どういう引数が有効か」「どういうときに失敗するか」を明記するだけで、拒否される呼び出しは劇的に減ります。

flowchart TB
  subgraph ツール説明の粒度
    C[包括的: 目的+引数意味+制約+失敗条件] --> R1[TFR低・信頼性高]
    M[最小限: 1文のみ] --> R2[TFR約2倍・失敗増]
  end

結果3：コンテキスト管理とマルチエージェントの使い分け

コンテキスト管理の最初の論点は、履歴をどこまで保持するかです。セッション全体で履歴を蓄積するrunスコープと、タスクごとに文脈をリセットするtaskスコープを比較すると、独立タスク（Easy／Medium／Hard）では7モデル中6つで影響は最大0.031と小さくなりました。例外はLlama 3.1 8Bで、累積履歴によって独立タスクのECCが0.667→0.192と71%も低下しました。しかもTFRも同時に下がっており、「間違った呼び出しをする」のではなく「何も呼ばなくなる」沈黙という形で性能が崩れます。コンテキストウィンドウが小さいモデルにとって、不要な履歴の保持は単なる無駄ではなく能動的な害になるのです。

次に、エージェントアーキテクチャの比較を見ます。ReActは単一エージェントが「推論→1回のツール呼び出し」のループを回す古典的な構成です。一方Plan-and-Actは、プランナーが要求をステップに分解し、バリデータが計画を検証（再計画は1回まで）し、独立したReActワーカーが各ステップを実行するマルチエージェント構成です。この2つをモデルごとに切り替えた結果、分解の効果はワーカーの実力に強く依存することが分かりました。

Llama 3.1 8Bをワーカーにすると平均ECCは0.554→0.718へ改善し、特にHistoryは0.113→0.650、Crossは0.166→0.450と劇的に回復しました。計画の分解を強いモデルに任せ、弱いモデルには単純なステップだけを渡す効果です。逆にGemma 4 26Bをワーカーにすると分解は逆効果でカバレッジが低下しました。強い単一エージェントは、セッション全体の文脈を自前で保持する方が有利なのです。ただし例外もあり、長時間セッション（Hard-Noise・累積履歴）では0.858→0.950へ回復するものの、余分な成功呼び出し（EVCR）の上昇というコストを伴います。

まとめると、マルチエージェント分解は「弱いワーカー」か「単一エージェントの文脈蓄積がボトルネックになる長いセッション」のために取っておくべき選択肢であり、強いモデルへの適用は逆効果になり得ます。

sequenceDiagram
  participant U as ユーザー
  participant P as プランナー
  participant V as バリデータ
  participant W as ReActワーカー
  U->>P: タスク要求
  P->>V: 分解した計画
  V->>P: VALID（または再計画）
  P->>W: ステップNを実行
  W->>W: ツール呼び出しループ
  W-->>P: ステップ結果
  P->>U: 合成した回答

安定性の検証：結果はサンプリングの産物ではない

LLMエージェントの評価結果は、サンプリングのランダムネスに左右されることがあります。ここまでの結果が偶然ではないことを確かめるため、2種類の安定性検証が行われました。まず、サンプリングのランダムネスを制御する温度を0／0.5／1.0で切り替えるスイープを実施したところ、モデルの順位は維持されました。Gemma 4 26BのECCは0.881〜0.896の範囲に収まり、温度による変動は誤差程度です。

続いて、同一条件での再実行を10回行い、実行間の分散（run-to-run分散）を測定しました。Gemma 4 26Bの最良構成では標準偏差0.008と極めて安定で、ほぼ毎回同じカバレッジを再現します。一方、Llama 3.1 8Bの最悪構成は標準偏差0.109と桁違いに大きく、しかも10回中9回がほぼ完全崩壊という二峰的な挙動を示しました。平均値だけを見ると「やや不安定」と読めますが、実際には「たまに成功し、ほぼ確実に失敗する」という再現性の欠如であり、単なるノイズではないのです。

もうひとつ直感に反する結果もあります。「温度を下げれば失敗が減る＝低温度ほど安全」という想定は、このベンチマークでは成立しませんでした。温度を下げてもTFRは一貫して低下せず、失敗率を強く支配するのは温度ではなくエージェント構成でした。

検証項目 対象 結果
温度スイープ（0／0.5／1.0） 全7モデル モデル順位は維持。Gemma 4 26BのECCは0.881〜0.896
同一条件で10回再実行 Gemma 4 26B・最良構成 標準偏差0.008と極めて安定
同一条件で10回再実行 Llama 3.1 8B・最悪構成 標準偏差0.109。10回中9回がほぼ完全崩壊
温度低下とTFR 全7モデル サーバー拒否率は一貫して低下しない

安定性の検証は全体として、本ベンチマークで観測されたモデル順位と構成の効果が再現性のある実体であることを裏付けています。運用時には、モデル選択と同じ重みで構成のチューニングに時間を割くべきでしょう。

実践ガイド：ローカルLLMエージェントを本番運用する5つの教訓

ベンチマークの結果を運用設計に落とし込むと、次の5つの教訓に集約されます。

教訓1：ターゲットモデルでプロンプトをテストせよ。 few-shotの無応答リスクはモデル依存で、Gemma 4 31BはECC 0.956→0.571、Gemma 4 E4Bは0.731→0.179へ激減しました。特徴的なのは、間違えるのではなく「何も呼ばなくなる」inaction型の失敗であることです。プロンプトの効果は他モデルの事例から推定せず、必ず本番で使うモデルと同一条件で検証してください。

教訓2：包括的なツール説明を使え。 各ツールの目的・パラメータの意味論・制約・失敗条件を明記するだけで、全モデルでTFRが削減されました。最小限の1文説明に切り替えると拒否は多く約2倍に悪化し、42のモデル×スイート組み合わせ中83%の最良構成が包括的説明を使用しています。「どういう引数が有効か」「どういうときに失敗するか」を書くコストは、失敗の再試行コストよりはるかに安いのです。

教訓3：ワークロードを代表するタスクでベンチマークせよ。 チュートリアル的な簡単タスクの成績は、状態を引き継ぐ依存性の高いタスクの成績を予測しません。Llama 3.1 8Bは独立タスクでECC 0.753を出しながら、状態依存タスクでは0.139まで落ちました。評価は実際の操作列に近い依存関係を含むタスクで行わないと、本番での劣化を見逃します。

教訓4：制約のあるモデルではコンテキストを管理せよ。 累積履歴はLlama 3.1 8Bで独立タスクのECCを0.667→0.192（71%減）に落としました。タスクごとに文脈をリセットするtaskスコープや履歴の要約・破棄を導入し、コンテキストウィンドウの小さいモデルでは「履歴をためない」設計を徹底してください。

教訓5：マルチエージェント分解は限定的に使え。 分解の恩恵は弱いワーカー（Llama 8BでECC 0.554→0.718）と長いセッションに限定され、強いモデルには逆効果です。さらに余計な呼び出しEVCRが増えるコストも伴います。単一エージェントの文脈蓄積がボトルネックになる場面だけ、プランナー＋バリデータ＋ReActワーカーの構成を検討すべきでしょう。

モデル選択の目安としては、Gemma 4 31B／26B、GPT-OSS 20Bが上位で、最適構成なら実用域（ECC 0.95以上）に達します。8B級モデルは文脈管理に弱いため、タスクスコープ管理か分解支援とセットで使うのが現実的です。以上の教訓は、ハードウェア設計以外のステートフルなツール連携にもそのまま応用できます。

flowchart LR
  M[モデル選択<br/>Gemma 4 31B/26B・GPT-OSS 20B] --> C[構成]
  C --> P[包括的ツール説明]
  C --> S[ターゲットモデルで検証したプロンプト]
  C --> X[文脈管理 taskスコープ/要約]
  C --> A[マルチエージェントは弱いワーカー・長セッション限定]

限界と今後の課題：ベンチマークの適用範囲を正しく見極める

ここまでの結果は「ローカルLLMによる設計自動化は実用域に入った」と読めますが、このベンチマークの適用範囲は4つの限界によって限定されています。まず、コンテキスト管理は「タスクごとにリセットするtaskスコープ」と「セッション全体で累積するrunスコープ」の2値しか比較していません。古いターンを要約・破棄して有効な文脈を保つ可変メモリウィンドウは未検証で、コンテキストウィンドウの小さいモデルに改善余地を示唆するものの、その効果は実証されていません。

次に、評価指標の粒度にも穴があります。EVCRは余分な呼び出しの「重大度」を重み付けしません。不要なユーザーパラメータの追加と、誤ったサブコンポーネントの接続はどちらも余分な呼び出し1回として同点に数えられますが、後者は設計データを破壊するコストがはるかに大きいのです。また、レイテンシは一切計測されておらず、モデルサイズと応答時間のトレードオフ（27B級と8B級の体感速度差）は本指標では捉えられません。

さらに、評価環境は実製品のAPIではなく、その状態・データモデル・依存制約を再現した「忠実なレプリカ」です。実APIのタイムアウト、エラー形式、権限制約といったプロダクション挙動とのギャップは残ります。サーバーとベンチマーク自体は機密のため非公開で、付録に代表タスク例が掲載されるのみです。したがって本結果は「ツール呼び出しエージェントの設計に関する傾向」を示すものであり、特定ツールの性能保証ではありません。

今後の課題は、可変メモリウィンドウの実装と検証、重大度で重み付けしたEVCRの導入、実ツールとの連携評価、より長いセッションでの検証が挙げられます。特に可変メモリウィンドウは、Llama 3.1 8Bで累積履歴が71%の性能低下を招いた事例への直接的な対策候補であり、実装コストに見合う効果があるかの検証が待たれます。

限界 影響 今後の課題
文脈管理が2値のみ 履歴の要約・破棄の効果は未実証 可変メモリウィンドウの検証
EVCRが重大度非考慮 軽微な余分呼び出しと破壊的な誤接続が同点 重大度重み付きEVCR
レイテンシ未計測 モデルサイズと応答速度の関係が不明 レイテンシ計測の追加
サーバーが忠実なレプリカ 実APIとの挙動差が残る 実ツール連携での評価

よくある質問

Q. ローカルLLMでもハードウェア設計の自動化は実用になるの？

はい。本ベンチマークの最適構成では、Gemma 4 31Bが期待呼び出しカバレッジ（ECC）0.990、Gemma 4 26Bが0.958を達成しており、コンポーネント作成やポート追加といった反復操作をほぼ取りこぼしなく実行できます。ただし「モデルの実力」と「エージェント構成の良し悪し」は別物です。構成を誤ると、Gemma 4 E4BのようにECCが0.811から0.168まで落ちる例もあります。モデル選びだけでなく、プロンプトやツール説明の粒度を含めた設定全体で判断してください。

Q. MCPって結局何？APIと何が違うの？

MCPは、LLMアプリケーションと外部ツールを標準化された形で接続するオープン規格で、Anthropicが2024年11月に公開しました。通常のAPIがツールごとに1対1の接続を個別実装するのに対し、MCPはサーバーを1つ実装すれば複数のAIクライアントから同じツール群を利用できる「標準レイヤー」です。ツールの追加・差し替えがクライアント側の改修なしで済むのが最大の利点になります。

Q. few-shotプロンプトは使わないほうがいいの？

モデル依存です。7モデルのうち5つでは無害〜やや改善だったのに対し、Gemma 4 31BはECCが0.956→0.571、Gemma 4 E4Bは0.731→0.179に急落しました。特徴的なのは「間違った呼び出しをする」のではなく「何も行動しなくなる」点で、エラーを出さず静かに沈黙するため検出が難しいのが厄介です。導入前に必ずターゲットモデルで検証してください。

Q. どのローカルモデルを選べばいい？

このベンチマークではGemma 4 31B／26BとGPT-OSS 20Bが上位で、いずれも最適構成でECC 0.95を超えます。一方、Llama 3.1 8Bのような小規模モデルは累積コンテキストに弱く、履歴が溜まると独立タスクのECCが0.667→0.192（71%減）まで落ちる例が確認されました。単体運用より、タスクスコープのリセットかマルチエージェント分解とセットで使うのが現実的です。

Q. マルチエージェントにすれば全部解決する？

しません。プランナーとワーカーに分けるPlan-and-Act構成は、Llama 3.1 8Bをワーカーにした場合（平均ECC 0.554→0.718）や長いセッションでは効果を発揮します。しかし、強い単一エージェント（Gemma 4 26Bなど）には分解が逆効果であることも確認されています。さらに余計な成功呼び出し（EVCR）が増えるコストも伴うため、適用は「弱いワーカー」か「コンテキスト蓄積がボトルネックになる長セッション」に限定すべきです。

まとめ

本記事で紹介したベンチマークは、ローカル展開した7つのオープンソースLLMが「状態を持つ設計ツールの操作」をどこまで自動化できるかを、14ツールを公開するMCPサーバーと8つのタスクスイート、4つのコールレベル指標（ECC・EVCR・TFR・NCA）によって実証したものです。結果の核心は「モデルが能力の範囲を決め、構成が実力を決める」という一文に集約されます。最上位モデルは最適構成でECC 0.990（Gemma 4 31B）を達成し、実用域に達しました。

その一方で、few-shotプロンプトによる無応答（Gemma 4 31Bで0.956→0.571）、累積履歴による沈黙（Llama 3.1 8Bで独立タスクのECCが71%減）、ツール説明の最小限化によるサーバー拒否率の約2倍化といった「構成要因」が、実運用の成否を左右することも明らかになりました。機密性の制約からクラウドAPIを使えずローカルLLMが必須となる設計環境において、MCPを介したエージェント運用は「適切に構成すれば実用的である」——これが本ベンチマークの実証された結論です。

本記事で整理した5つの教訓（ターゲットモデルでのプロンプト事前検証、包括的なツール説明、ワークロードを代表するタスクでの評価、コンテキスト管理、マルチエージェントの限定利用）は、ハードウェア設計に限らず、状態を持つツールを順序付きで操作するあらゆるステートフルな連携にそのまま応用できます。モデル選びだけに注力するのではなく、プロンプト・ツール説明・コンテキスト管理・アーキテクチャの各要素を自環境で測定して改善する習慣こそが、ローカルLLMによる自動化を成功へ導く最短経路です。

参考資料

関連記事