エージェント連携の単一障害点は、直接の依存先ではない
はじめに
自社のエージェントが、取引先のエージェントに与信照会を直接投げます。相手のエージェントは、その照会に答えるために内側で別の外部サービスを呼んでいます。契約書に名前が出てくるのは取引先までで、その先に何がいるかは書かれていません。
この形の依存は、金融機関どうしの与信関係とよく似た構造になります。金融ではこの構造の危険を測る研究が積み上がっていて、伝染の経路をどう追うか、どこが単一障害点になるかを扱う道具が揃っています。エージェントの連携にそのまま持ち込める部分と、持ち込めない部分があります。
先に結論を書くと、危ないのは直接依存されている数が多いノードではありません。依存を1段たどった先にいて、契約上は誰の視界にも入っていない共通基盤のほうです。
対象読者:
- 外部のエージェントやAPIに依存する構成を設計・審査する立場の方
- 委託先の先にある依存をどこまで把握すべきか判断したい方
- 障害の波及範囲を見積もる枠組みを探している方
記事のポイント:
- 組織間の依存を有向グラフとして見たときに、波及範囲がどの量で決まるかを整理します
- 中心性指標のどれが共通基盤を捉え、どれが外すかを構造から説明します
- 金融のシステミックリスク研究から借りられるものと、借りられないものを分けます
波及範囲を決めるのは、依存されている数ではない
依存関係を有向グラフとして書きます。組織Aが組織Bのエージェントを呼ぶなら、AからBへ辺を張ります。Bが止まればAが止まるので、障害は辺を逆にたどって広がります。
あるノードが落ちたときの被害範囲は、そのノードから到達できるノードの集合、つまり到達可能集合の大きさで決まります。直接つながっている数を数えても、この量には届きません。2つの値はずれますし、ずれ方に規則があります。
取引先として名前が出るノードは、多くの組織から直接依存されます。数だけを見れば大きくなります。ところが取引先自身は、業務を完結させるために少数の基盤サービスを呼んでいるだけで、その先に広い到達可能集合を持ちません。一方で、複数の取引先が共通して呼んでいる基盤サービスは、直接依存されている数が少なく見えます。1段目の組織から見ると、そこは契約の相手ですらありません。しかしその1つが止まると、それを呼んでいる取引先すべてが止まり、さらにその先の組織まで届きます。
依存の階層が2段以上あると、直接依存の数の順位と到達可能集合の順位はずれます。ずれ方は構造で決まっていて、前者は1段目を数え、後者は最後まで数えます。1段しかない構成なら両者は一致するので、この問題は依存が入れ子になった時点で初めて出てきます。
説明のために200組織ぶんの依存関係を作って、各ノードの到達可能な組織数を数えたのが上の図です。直接依存されている数がいちばん多いのは中央の連携先で26件ですが、そこから影響が届くのは34組織にとどまります。左端の共通基盤は直接依存が13件から15件と少ないのに、届く先は154組織から176組織です。直接の数では5倍近く劣るノードのほうが、波及範囲では5倍広いという関係になります。
この数は伝播の確率を置いた計算ではなく、辺をたどって到達できるかどうかを数えただけのものです。層の構造がこうなっていれば、確率をどう置いても順位の関係は変わりません。
中心性指標が何を測っているか
ネットワークの重要ノードを測る指標はいくつもありますが、この問題に対して当たるものと外すものがあります。
出次数は直接呼んでいる先の数です。1段目しか見ないので、上で述べたずれをそのまま踏みます。
媒介中心性（betweenness centrality）は、ノード対の最短経路が何本そこを通るかを測ります。経路の途中にいるノードを高く評価する指標なので、依存の末端にいる共通基盤は低く出ます。基盤サービスは何も呼んでいないため、どの経路でも終点にしかならず、途中を通りません。この指標は原理的に共通基盤を外します。
到達可能ノード数は、まさに測りたい量です。ただし障害が確率的に伝わる場合、到達可能な全ノードが必ず落ちるわけではありません。遠いノードほど届きにくくなります。
Katz中心性は、経路の長さに応じて減衰させながら経路の本数を数えます。減衰係数を伝わりやすさに合わせておけば、確率的な伝播の期待被害に近い量になります。
固有ベクトル中心性は、この用途では使えません。依存関係のグラフは通常、閉路を持ちません。AがBに依存し、BがAに依存する構成は運用が成立しないからです。閉路がないと隣接行列は冪零になり、固有値がすべて0になります。固有ベクトル中心性は最大固有値に対応する固有ベクトルとして定義されるので、ここでは値が定まりません。Katz中心性が使えるのは、単位行列を足す形になっていてこの退化を避けているからです。
金融から借りられるもの、借りられないもの
金融のシステミックリスク研究は、同じ構造をずっと前から扱っています。借りられるものが3つあります。
1つは、伝染経路を分けて考える枠組みです。金融では、直接の与信関係を通じた伝染と、共通の資産を持っていることによる同時被弾を区別します。エージェントの構成でも、呼び出し関係を通じた停止と、同じ基盤サービスに依存していることによる同時停止は別の経路です。前者は依存をたどれば見えますが、後者は自社の依存表には現れません。
2つめは集中度の指標です。総量ではなく、それが少数のノードに集まっているかを見ます。総量が同じでも、少数に集中している構成はそのノードを守れば大きく下がります。分散している構成では、どこを守っても効きません。守る場所を決める判断がここで変わります。
3つめは裾を見る発想です。平均的な波及範囲が小さくても、まれに大きく広がる場合に備える必要があります。分布の端を扱う道具立ては、極値統計の考え方がそのまま使えます。
借りられないものもあります。金融では監督当局が全参加者の相互与信を報告させ、ネットワーク全体を把握できます。エージェントの連携にそういう仕組みはありません。自組織から見えるのは、自分が結んだ契約の1段目までです。金融の手法は「ネットワークが分かっている」前提に立っているので、その前提が無いところに持ち込むと、計算する対象そのものがありません。
もう1つ、金融では取引の記録が残ります。エージェントの呼び出しは、相手側のログにしか残らないことがあります。事後に経路を再構成できるかどうかは、契約の時点で決めておく話になります。
依存の2段目を聞き取ることから始める
以上を踏まえると、最初にやるべきは計算ではありません。依存の2段目を書き出すことです。
自社のエージェントが呼んでいる外部の相手を並べたら、その相手に対して、その処理のために何を呼んでいるかを訊きます。全部は答えてもらえないかもしれませんが、複数の取引先の答えに同じ名前が出てくるかどうかだけは分かります。同じ名前が2つ以上の経路に出てきたら、そこが共通基盤です。契約上は誰の相手でもないので、放っておくと誰も監視しません。
聞き取れたら、次は記録の側を整えます。呼び出しに識別子を通して、相手側のログと突き合わせられる状態にしておきます。障害が起きてから経路をたどろうとすると、自社のログだけでは1段目で行き止まりになります。
代替経路の用意は、共通基盤が見つかってから考えます。見つかる前に冗長化を検討すると、冗長化した2系統が同じ基盤に着地していることがあります。
まとめ
組織間でエージェントがつながると、依存関係は有向グラフになります。障害の波及範囲は到達可能集合の大きさで決まるので、直接依存されている数を数えても順位は当たりません。依存が2段以上になった時点で、両者はずれます。危ないのは、複数の経路が共通して着地している基盤サービスのほうです。
中心性指標を選ぶときは、その指標が経路のどこを見ているかを確かめます。媒介中心性は経路の途中を評価する指標なので、末端の共通基盤を原理的に外します。固有ベクトル中心性は、閉路のない依存グラフでは値が定まりません。
金融のシステミックリスク研究からは、伝染経路を分ける枠組み、集中度の指標、裾を見る発想を借りられます。借りられないのは、ネットワーク全体が見えているという前提です。この領域では、測る前に見える範囲を広げる作業が要ります。次の打ち合わせで、いま呼んでいる外部の相手に「その処理のために何を呼んでいますか」と1つ訊いてみてください。同じ名前が2社から出てきたら、そこが最初に手を入れる場所です。
