ネットワーク運用においてオープンプラットフォームが重要な理由

[0:03] – 司会者：[音楽] こんにちは、ネメルテスのCEO、ジョナ・ティル・ジョンソンです。共司会者のネメルテスCTO、ジョン・バークと共に、この番組『Heavy Strategy』をお届けします。この番組は、正しい答えを与えるのではなく、正しい質問を投げかけることを目指しています。 本日は、BlueCatのEMEA地域フィールドCTOであるロニー・ウルフ氏をお迎えし、ネットワーク運用においてオープンプラットフォームがなぜ重要なのかについてお話しします。

[0:20] – 司会者：ロニーさん、ネットワーク運用は実に広大な分野ですが、BlueCatがまさにこの分野で事業を展開していることは承知しています。 少なくとも数年前からBlueCatをご存知の方も多いと思いますが、一部のリスナーには馴染みがないかもしれません。BlueCatが具体的にどのような分野で事業を展開しているのか、簡単に概要を説明していただけますか？

[0:40] – ロニー：ああ、確かにそうですね。つまり、BlueCat NetworksはもともとコアなDDIビジネスからスタートしています。つまり、DNS、DHCP、IPアドレス管理といった、基本的に退屈な作業ばかりですよね？ 誰もが対処しなければならないことですね。しかし、市場ではそのプラットフォームを拡張したいという需要、あるいは要件があることが分かってきました。つまり、コアネットワークサービスだけにとどまらないということです。ネットワーク運用とは、システムを正常に稼働させ続けることですよね？ 単にサービスを提供するだけでなく、ネットワーク内で何が起きているかを把握することも重要なんです。

[1:20] – ロニー：そして、ここ数年の数件の買収を通じて、ネットワーク可観測性、ネットワークパケットキャプチャ、インフラストラクチャ保証ソリューションのポートフォリオを拡大し、それらを基盤としたプラットフォームを構築しました。現在、これを「インテリジェント・ネットワーク・オペレーション」と呼んでいます。 これは基本的に、コアサービスの提供という側面と、単にシステムを稼働させ続けるだけでなく、ネットワーク内に何が存在し、その背後にある根本原因が何であるかを正確に把握するという側面の両方を組み合わせたものです。

[1:55] – 司会者：なるほど。つまり、中核となるDDIを超えて、ネットワーク内で実際に何が起きているかを把握する方向へと拡大しているのですね。その仕組みについて話す前に、フィールドCTOという役職は実際にはどのような仕事をするのでしょうか？ 日々、どのような業務に取り組まれているのですか？

[2:06] – ロニー：そうですね。BlueCatにおけるCTOという役職は、顧客と当社の戦略部門との架け橋だと定義しています。ですから、私は営業部門などには所属していません。 ですから、もちろんBlueCat内にも営業活動はあります。そうでなければ収益を上げることはできません。しかし、私たちの役割は顧客の声に耳を傾け、その要件を真に理解することです。それは単にBlueCatが提供するサービスについてだけでなく、顧客を動かす要因についても同様です。 セキュリティ、ネットワーク運用、アーキテクトなど、さまざまな組織や事業部門を動かす原動力とは何か。私たちはそうした声に耳を傾け、それをBlueCatの戦略的方向性――つまり、当社の製品がどこへ向かうべきか、何を変える必要があるか、そしてどのように顧客を支援できるか――に反映させようとしています。

[3:05] – 司会者：つまり、あなたの仕事は基本的に、顧客が直面している課題を理解し、その課題が極めて深刻化する前に、会社が解決策を開発するよう促すことですね。

[3:13] – ロニー：その通りです。

[3:19] – 司会者：なるほど。 また、企画会議の際にも少し話しましたが、オープンネットワーキングの重要な要素の一つは、APIの活用と「APIファースト」の姿勢です。社内では、買収した企業の統合を進める中で、BlueCatがモジュール式開発のためにAPIを使い始め、APIを基盤として開発を行い、すべてを統合して維持できるようにしたと、あなたは言及していましたね。 ネットワーク運用に関して、その点について少しお話しいただく予定ですね。では、BlueCat社内ではそれがどのように機能したのでしょうか。また、BlueCatでの経験から得られた教訓のうち、現在実際に顧客に提供しているものは何でしょうか？

[3:50] – ロニー：ええ、特に当社の戦略部門は、この取り組みにおいて間違いなく大きな役割を果たしました。顧客の声に耳を傾けたとき…… つまり、私たちも当初は、ある種のサイロ化されたアプローチから始めていました。考えてみてください。私たちは中核となるサービス、つまり当社の主力ビジネスを提供しており、顧客も満足していました。しかし、新たな取り組みが進むにつれて、顧客の要件が変化していることに気づきました。セキュリティ、自動化、統合といった分野です。 つまり、顧客が統合を求めている対象は膨大なポートフォリオに及びます。特に、私たちが「単一の信頼できる情報源」となることを目指している場合や、顧客がプラットフォーム型のアプローチを採用したいと考えている場合などはなおさらです。

[4:38] – ロニー：そしてBlueCat内で私たちが認識したのは、たとえソリューションが実証済みで、顧客がこれらの機能や特徴をすべて気に入っていたとしても、私たちには限界があったということです。まず第一に、それを製品や統合機能に変えるのに十分な速さで対応できなかったのです。 また、一方で、社内に分断された状態があったことも、私たち自身の足を引っ張っていました。ユーザーインターフェースがあり、自動化機能やAPIがあり、異なるプラットフォーム、異なる用途、異なるAPI、異なるユーザーインターフェースなどが混在していました。すべてがまるでパズルのピースのように、うまく噛み合っていないように見えたため、統一された企業アイデンティティを確立することができませんでした。

[5:27] – ロニー：その取り組みを始めたのは、3、4年前くらいだったと思います。つまり、計画自体はもっと前から始めていましたが、その後、自社製品を本格的に見直しました。「何を変える必要があるか？」 例えば、フロントエンドとバックエンドを分離すべきか？そうすることで、エンドユーザーが抱えるビジネスプロセスを踏まえ、現在の利用状況を踏まえて、それを自動化されたアプローチへと転換し、顧客が資産管理やITサービス管理、そして利用中の関連プラットフォームすべてに組み込めるように支援できるのです。 それ以来、私たちは単に自社だけで利用し、その上にユーザーインターフェースを構築するだけのAPIプラットフォームを開発するのではなく、顧客が実際にこれを利用して、より迅速に統合や自動化を実現できるようになることを念頭に置いて開発を進めてきました。

[6:25] – 司会者：では、APIを備えた製品を持つことと、社内の開発においてAPIを中心に据えることとの違いは何でしょうか？APIを持つことと「APIファースト」であることの違いは何ですか？

[6:47] – ロニー：そうですね。 [咳払い] つまり、APIが必要になるのは、例えば「ユーザーインターフェースに新しいボタンを追加したい」とか、何か新しい機能が必要になった時です。開発段階では要件が文書化され、特定のサービスチケットやJiraチケットが作成され、その背景にはユーザーストーリーがあり、そこからAPIの開発が始まります。 これは本当に何らかの標準や、統合された統一的なアプローチに合致しているのでしょうか？ いいえ。 あそこにAPIがあって、あちらにも少しあって、もしかしたら「これを組み合わせる必要があるな」とか、「ああ、これはAPIにはできないから、ユーザーインターフェースからバックエンドに直接アクセスさせよう」といった具合になるんです。

[7:33] – ロニー：そこがまさに違いなんです。顧客にとっては、たとえ「開発者がいるかもしれないし、少なくともスクリプトなどを書ける人がいるかもしれない」と言われても、プログラミング言語やパラダイム、モデルなどを理解する必要があります。 理解するのも、維持管理するのも非常に難しくなります。これは一度きりの話ではありませんよね？顧客は、製品やプラットフォームのライフサイクル全体を通じて、基本的にそれを維持し続けなければならないのです。

[8:03] – ロニー：そして、APIファーストのアプローチとは、基本的にAPIを本格的に開発することです。目に見えるもの、製品でできることすべてがAPIであり、その上にフロントエンドを構築するのです。それがユーザーインターフェースであれ、コマンドラインであれ、何であれ。 ところで、顧客はその違いを直接実感できるのでしょうか？ それは難しいですよね。結局のところ、誰もが「APIがあるから、もちろん接続できますよ」と言うからです。そして、これは顧客と話し合う際によく直面する課題でもあります。自動化や統合のアプローチは、確かにその一部に過ぎないかもしれません。 「あの、APIでそれできますか？」「はい。」チェックマークをつけて、それで終わり。しかし、その点がしばしば見落とされたり、詳細に検討されなかったりすることがあります。「本当にそれができるのか？」と。 製品を購入し、導入した後に、制限にぶつかったり、統合ができなかったりすることが判明すると、その場しのぎの対応を迫られたり、ビジネス上本当に必要だったことを実現するために多額のコンサルティング費用を支払わなければならなくなったりするのです。

[9:19] – 司会者：つまり、APIの一貫性は保たれているか、他の製品とのスイート内での利用方法に一貫性があるかといった点が、時間の経過とともに最も顕著に現れてくる違いかもしれませんね。そういう点が徐々に明らかになってくるわけですね。なるほど、よくわかりました。

[9:38] – 司会者：統合用ではなく、自動化のためのAPIについて少しお聞かせください。最近、ネットワークチームからその話題をよく耳にします。

[9:51] – ロニー：そうですね。その通りです。自動化は今日、重要な要素であり、おそらく必須要件とも言えるでしょう。少なくとも、先ほども触れたように、顧客環境内のRFPや各種要件、あるいはイニシアチブの中に必ずどこかに盛り込まれているはずです。 自動化とは、ビジネスワークフローを自動化することです。また、先ほども述べたように、顧客がBlueCatのようなプラットフォームを利用しているか、あるいはどのようなプラットフォームを使用しているかは関係なく、顧客は自社のビジネスプロセスを理解しています。 そこには複数の異なるプラットフォームが関わっています。例えば、ITサービス管理の場合、チケットが作成されます。その後、そのチケットはプラットフォーム自体に取り込まれ、何らかのアクションへと変換されます。そして、それは単一のアクションではなく、実行すべき複数のアクションがある場合もあります。 例えば、BlueCatの場合、ネットワークを作成する必要があるほか、その上に仮想マシンをプロビジョニングする必要があるなどといったことが挙げられます。そして、こうしたビジネスプロセスは、手動による介入を可能な限り最小限に抑え、自動化された形に転換する必要があります。

[11:08] – ロニー：考えてみると、10年前、私がIT管理者などを務めていた頃、変更を実施するためにサービスチケットを作成しても、それが実行に移されるまで24時間から48時間は軽くかかっていました。 クラウドの時代、オンデマンドで機能を利用できる今、ユーザーや顧客が本当に期待しているのは、本当にそんなことなのでしょうか？ ですから、より迅速に変更を行うため、またある種の標準化を徹底するためにも、自動化が必要なのです。

[11:48] – 司会者：なるほど。また、私が理解しているところでは、この方法で自動化を行うメリットの一つは、単に一つのことを行うだけでなく、どのような変更であっても、その変更が正しく行われるようにするために必要な一連の付随的なワークフローを確実に実行できる点にあるのですね。 ですから、たとえごく基本的なことであっても、1つの変更を加えてから、それが機能したか、あるいは他の部分に変化がないかを確認するためのテストを行います。そして多くの場合、それほど単純な話ではありません。 他にも多くのテストを行う必要があります。APIがあれば、1つの変更を行う際に、こうした一連のプロセスをより容易に実行できます。私の理解は正しいでしょうか？

[12:28] – ロニー：その通りです。まさにその通りですね。特にここにおいて、APIファーストのプラットフォームと、「はい、プラットフォームにAPIはあります」というだけのものとの違いがわかります。後者の場合、ある程度まで自動化することはできますが。 また、顧客とのやり取りでも見てきたように、対象となるのは私たちが直接話しているチームだけではありません。異なる要件を持つ様々なチームが存在します。私たちのビジネスにおいて、このワークフローはDDI管理者やネットワーク管理者によるものではありません。 セキュリティ担当者、事業部門そのもの、アプリケーションオーナー、あるいはデータベース、フロントエンド、Webショップなど、あらゆる部門が関与していますよね？ 彼らにはそれぞれの要件があるのです。DDI管理者は、そのプロセスがどのように機能しているかを完全に把握することはできません。彼は自分の専門分野については理解していますが、それ以外の周辺状況については把握できていないのです。 しかし、プラットフォームはそれをサポートする必要があります。もしそこから始めて、ある時点で「ああ、当社のプラットフォームではそれができない。別の方法でやらなければならない」という限界に直面した場合、まず第一にコストがかかるかもしれませんし、あるいはエンドツーエンドの自動化を徹底することが、かえって弊害となる可能性もあります。

[13:39] – 司会者：つまり、あらゆる事柄に対応できる完全なAPIを備えているという点で、貴社は有利な立場にあるようですね［笑］。顧客として、自組織の進化や役割の変化、ワークフローの変化に対応できるわけですから。 その場合、御社が提供しているようなアクセス権限設定があれば、自動化の微調整も容易になりますね。

[14:04] – 司会者：BlueCatでは、顧客に公開したいAPIと、社内でしか使用されないAPI、つまり製品間やモジュール間で利用されるAPIを、どのように区別しているのですか？

[14:22] – ロニー：正直なところ、違いはありません。実際、すべてが公開されています。すべてがAPI呼び出しです。ですから、画面に何が表示されているかは問題ではありません。ただ、APIの観点から少し明確にしておくべき点が一つあります。 すべてが顧客に公開されています。顧客はそれを利用したいでしょうか？それはケースバイケースです。確かに、ほとんどの場合、当社のユーザーインターフェースや、プラットフォーム間の接続などに使用されるAPIもありますが、顧客は、私たちが想像もしていないような特定のユースケースや、彼ら独自の要件のためにそれらを利用することも可能です。 しかし、私たちが明確に区別しているのは、データベースやあらゆる種類のバックエンドが存在するバックエンドシステムが、顧客からは抽象化されているという点です。そして、まさにそこでAPIが重要な役割を果たすわけですよね？ 製品で何ができるかについて、私たちはガイドラインを提供しています。それは間違いなく存在します。しかし、私たちが行うすべての処理はパブリックAPIとしても公開されており、顧客はそれを利用することができます。

[15:26] – 司会者：これは結局のところ、「APIファースト」という考え方そのものに帰結すると思います。なぜなら、「ああ、APIはあるよ」と言うだけでは、単に顧客に公開されるだろうと推測した部分にAPIを付け加えたに過ぎないからです。 しかし、「APIファースト」とは、システム全体とそのモジュール性を徹底的に検討し、システムのモジュールを異なる方法で利用したいと考える顧客に対しても、すべてのAPIを安心して公開できる状態にあることを意味します。

[15:57] – ロニー：その通りです。

[15:57] – 司会者：私が思い描いているのは……あ、どうぞ続けてください。 いえいえ、大丈夫です。私が頭の中で思い描いているのは、BlueCatシステムがネットワーク運用の他の部分にとっての触媒として機能している姿なんです。というのも、中核部分が正しく設計されていれば、その上に重ねられるすべての要素も同様に正しく設計され続けるからです。

[16:15] – ロニー：はい。確かに、それを実現するには時に課題があります。というのも、私たちにはユーザーストーリーや自動化・連携に関する要件、そして顧客が潜在的に利用したいと考えている機能などがすべてあるからです。 さらに、追加のバックエンドシステムなどを導入する必要も生じます。それは間違いなく依然として課題です。しかし、こうした場面こそ、フィールドCTOや戦略部門が顧客の声に耳を傾け、それを推進し、少なくともその市場においてある種のイノベーションの担い手となる役割を果たす場なのです。

[16:55] – ロニー：そうですね、その点には同意します。モジュール型のアプローチは、私たち自身の開発においても非常に役立っています。新製品を開発すると、それが自動的にAPIスタックに登録されます。私たち自身も使用しているため、即座に公開され、顧客も利用できるようになります。ですから、はるかに迅速です。 私たちは製品に数多くの追加モジュールを開発してきました。コアプラットフォームそのものではなく、その上に追加された機能や、顧客向けの特定のユースケース、あるいは現在取り組みたい特定の分野などですが、それらはすべてAPIを通じて即座に公開されます。

[17:38] – 司会者：この文脈で私たちが特に重視しているのはセキュリティ、特にゼロトラスト型のセキュリティです。つまり、誰がどのAPI呼び出しにアクセスできるかという、IDおよびロールベースのアクセス管理が組み込まれていると理解してよろしいでしょうか。

[17:54] – ロニー：ああ、そうですね。ええ。つまり、それが基本と言えるでしょう？

[18:06] – 司会者：まあ、基本的にはそれが当たり前だとは思うんですが、時には後付けになることもありますよね。

[18:06] – ロニー：そうですね。 基本的な点として、APIファーストのアプローチを採用する場合、ユーザーインターフェースのようなフロントエンドは単にAPIの消費者であるため、ユーザーインターフェースやフロントエンドは基本的に認証や認可を処理する必要がありません。したがって、それらはAPI自体の中に組み込まれる必要があります。 そう、API全体にはロールベースのアクセス制御が実装されています。IdP（アイデンティティプロバイダー）のような外部認証を含め、あらゆる認証メカニズムが備わっています。これは留意しておく必要があります。つまり、エンタープライズ顧客はAzure Entra IDなどのアイデンティティプラットフォームを利用していますよね？ 彼らはもはやローカル認証を使用しておらず、少なくともすべてがそうではありません。

[19:01] – ロニー：また、APIファーストのアプローチにおけるセキュリティ面だけでなく、誰かがAPIを悪用した場合にどうなるかについても考える必要があります。単なるユーザー、つまり認証済みのユーザーだけではありません。なぜなら、彼らには基本的にシステムを破壊する自由も与えているからです。ですから、ガードレールを念頭に置く必要があります。 例えば、レート制限です。誰かが100万回のAPI呼び出しを実行してしまった場合、その人は専門家ではないかもしれないからです。特にその分野の顧客、つまりネットワーク管理者などは、スクリプトを作成することはできても、開発者ではありません。 AIエージェントに何かを入力し、スクリプトが生成されたものを実行しただけで、プラットフォーム全体がダウンしてしまう可能性もあります。ですから、やはり安全策を念頭に置く必要があります。繰り返しになりますが、レート制限、セキュリティ体制、動作の追跡などを行い、プラットフォームの回復力と安定性を確保しなければなりません。

[20:06] – 司会者：私が思い浮かべたのは、いわばネットワーク運用版の「クリッピー」のようなものでした。「1,000万件のコールを送信しようとしています。本当に実行しますか？」といった感じです。[笑い]

[20:16] – ロニー：その通りです。まさにその通りです。つまり、プラットフォーム、少なくとも私たちのプラットフォームであっても……また、顧客がAPIファーストのアプローチを採用する場合、スケーラビリティについても検討することをお勧めします。 でも、そうですね、顧客の事例でも同様の傾向が見られました。APIファーストアプローチの最初のバージョンをリリースした際、私たちにとっても学習の過程でした。顧客がAPIをどのように使い、どのようなアイデアを思いつくのか、といった点です。というのも、今や顧客には基本的にあらゆる自由が与えられているわけですから。 以前は、APIに制限があったんです。つまり、当初からAPIはありましたが、制限されていました。いわば「二分された状態」だったんです。そして今、顧客は基本的に、私たちがやっているのと同じように、やりたいことを何でもできる完全な自由を手に入れたわけですよね？　その様子を見るのは興味深く、私たちはそれに合わせて調整していきました。

[21:18] – 司会者：「見ていて興味深い」というのは、「本当にめちゃくちゃ怖い」という表現の婉曲表現だと思います。

[21:18] – ロニー：はい。そうですね。ただ、一点だけ覚えておいていただきたいことがあります。BlueCatでは、ネットワーク運用とDDIコアサービスに注力しています。

[21:36] – 司会者：そうですね。そうでないと、すべてがダウンしてしまいますから。

[21:36] – ロニー：ええ、そうですね。それは重要です。その通りです。 しかし、顧客がこれをCMDBとして利用しているケースも見受けられます。監視プラットフォームとしても活用されています。つまり、DDIプラットフォームは、他のシステムからの情報を取り込んでいたため、監視プラットフォームとして機能していたのです。ですから、顧客がこのようにプラットフォームを利用していることには、私たちも気づいていませんでした。

[22:01] – 司会者：そうですね、それは理にかなっています。他のCMDBタイプのシステムでは必ずしもそうとは限らない部分もありますが、御社のシステムに記録されている情報は正確でなければならない、[咳払い] ですよね？ [笑い]

[22:15] – ロニー：もちろんです。もちろんです。私たちが理解できる範囲内でです。つまり、彼らがそれをカレンダーのようなものに変えてしまった、といったことではありませんでした。しかし、彼らがそれをどのように活用するかについて、私たち自身が全く考えていなかったという点で興味深い事例でした。 とはいえ、APIファーストの戦略自体は変わっていませんが、より多くのガードレールを設けることで調整を加えました。たとえ例のように100万件ものAPI呼び出しが殺到したとしても、これらの重要なコアサービスが引き続き稼働できるようにするためです。

[23:01] – 司会者： そうですね。AIによる、少なくとも悪意のない誤用からコア機能を保護することについてはお話しいただきました。では、ネットワーク運用を支援するための、例えば専門家による知識に基づいたAIの活用に対して、どのように親和性を高めようとしてきたのでしょうか？AIとの連携をより円滑にし、支援的なものにするために、どのような変更や追加を行ったのですか？

[23:28] – ロニー：そうですね。 まずそこから始めましょう。「APIファースト」はAIにとってはるかに簡単です。特に、ここで話しているのはAIエージェントのことであり、その背後にあるLLM（大規模言語モデル）などではありません。適切なドキュメント、つまりOpenAPI仕様や何らかの標準規格を利用するのははるかに簡単です。AIが読み取り、理解するのもずっと容易です。 [鼻を鳴らす] でも、AIエージェントがプラットフォームを本当に理解していない状態で、それをプラットフォームに完全に組み込みたいと思いますか？ だって、APIがどのように機能するかという仕様書を読むだけでは……確かに、最近のAIはそれを理解する、あるいは少なくとも解釈することに関してはかなり上手になっています。しかし、問題は、その点についてあなたがコントロールできないということです。

[24:27] – ロニー：そこで私たちが提供したのは、これは今や非常に専門的な用語ですが、「MCPサーバー」です。つまり、Model Context Protocol（モデルコンテキストプロトコル）です。リスナーの皆さんに理解していただければ幸いです。これは基本的に…… 以前にも話しましたが…MCPサーバーとは、APIの前に配置されるもので、AIやエージェントがリクエストできる範囲をある程度調整し、モデルの動作やその性質に関する追加のコンテキストを提供します。また、APIが実行できる特定の機能を組み合わせたり、追加のガードレールを設けたりすることも可能です。

[25:06] – ロニー：例えば、MCPサーバーやAPIとの統合、およびAIの活用に向けた取り組みを、読み取り専用モードから開始しました。 あくまで情報を収集し、顧客や、当社が作成・設計した社内ペルソナプロファイルから学び、それがどのように機能するかを検証するためです。そこで、まずは読み取り専用モードから始めました。例えば、レポート作成や情報収集、あるいはエンドユーザーが自社のプラットフォームに統合するのを支援するためです。

[25:56] – ロニー：しかし一方で、学習過程において、変更を加えられるようにするために、この機能を公開しました。 なぜなら、インテリジェントなネットワーク運用プラットフォームのコンセプトには、自己修復型ネットワークの提供も含まれているからです。そして、自己修復型ネットワークは読み取り専用で存在するわけではないですよね？何か異常を検知してアラームがポップアップした際に手動での対応が必要になるなら、それは従来のネットワーク運用ですよね？ 私たちはインテリジェントでありたいし、顧客も最終的には自己修復型ネットワークを求めています。そのためには、AIがアクションを起こせるようにする必要があり、MCPサーバーは基本的に、AIのためのコンテキストとガードレールを提供しているのです。

[26:40] – 司会者：[鼻を鳴らす] すみません、これは他の文脈でも時々話題に上がっていた件ですね。 BlueCatのスタック内で、あなたが実現しようとしているこの機能について、何かが起こる直前に必ず人間による確認を強制したり、実行を許可するための承認を求めたりする方法はありますか？それはスタックに組み込まれているのでしょうか、それともMCPレイヤーで実装されているのでしょうか？

[27:02] – ロニー：はい。そこで私たちが導入し、MCPサーバーもそれを公開している機能——AIエージェントやモデルが理解できるようにしたものです——を、私たちは「変更管理」と呼んでいます。特定のアクションについては、AIは推奨のみを行い、人間の承認が必要となります。 また、2人…2人原則、いえ、4つの目（フォーアイズ）原則のようなものも導入しました…

[27:43] – 司会者：人という原則ですね。つまり実際には3つあるわけですね。あの古いSFの、ジョン……「3回言って」というやつみたいに。人間1、人間2、そしてAI。

[27:53] – ロニー：その通りです。特にコアネットワークサービスの削除や、スイッチなどネットワーク上の重要な変更を行う場合など、特定の状況においては、顧客が希望すればその決定を覆すことも可能です。 しかし、デフォルトでは、BlueCat製品にはその安全策が組み込まれています。AIはその判断理由として、「すみません、その操作は実行できません。承認をお願いします」と表示します。ユーザーは手動で「承認」をクリックするか、API呼び出しを通じて承認を行う必要があります。

[28:34] – 司会者：レート制限や、そこに組み込んでいるその他の安全策に対する、素晴らしい補完機能ですね。それは嬉しい話です。そういう話はそうそう聞けませんから。

[28:46] – ロニー：そうですね。つまり、一つはワークフローや顧客が意図する操作に対する「ガードレール」のようなものです。一方で、APIのレート制限やアクセス制御など、より技術的なセキュリティ面もあります。ですから、これらは別々の取り組みとして並行して進めているのです。

[29:03] – 司会者：そうですね。また、その「2人の人間が関与する（two-humans-in-the-loop）」シナリオを利用するメリットの一つとして、先ほど話したようなサイロ化を解消できるという点もあるようですね。 つまり、例えばネットワーク運用担当者は「問題ない」と考えていても、セキュリティ部門からの承認も必要になる、といったケースがあるわけです。この仕組みにより、そうしたより広い文脈を把握できるようになるわけですね。

[29:26] – 司会者：先ほどおっしゃったことについて、改めてお聞きしたいのですが、その話を聞いてからずっと気になっていたんです。この「APIファースト」のアプローチを最初に導入した際、例えば、お客様が実際にコアをCMDBとして利用している様子を見て、ある意味驚かれたとおっしゃっていましたね。 私も「そりゃあそうだろう」と思いましたし、もし私があなたの立場だったら、確かに非常に驚いたことでしょう。 現在、顧客が行っていることで、あなたを驚かせていることは何でしょうか？例えば、顧客の現場を訪れて、彼らが何かをしているのを見て、「うわっ、それについては考えていなかったけど、今後のロードマップの一環として真剣に検討したい」と思うようなことです。

[30:01] – ロニー：そうですね。私が本当に驚いているのは……コアとなるサービスネットワーキング、つまりDNSやDHCPについてですが、従来、BlueCatは独自のBlueCat DNSおよびDHCPサービスの提供に注力してきました。 つまり、顧客は自社の環境内にこうしたサービスを導入するわけです。しかし、当社のDDIプラットフォームの「APIファースト」アプローチや、MCPサーバーのリリース、そして「LiveAssist」と呼んでいるもの（名称はともかく、プラットフォーム自体に焦点を当てた当社のAIエージェント）が登場したことで、顧客からは次のような声が上がるようになりました： 「ねえ、そのプラットフォーム内で他のDNSやDHCPサーバーも管理できないかな？」という要望が生まれたのです。例えば、「AzureやAWS Route 53を使っている」とか、「最近買収を行ったので、Microsoft環境を統合したい」とか、「あそこにMerakiの機器があるんだけど、 これも統合できますか？」といった具合です。先ほどいくつかのベンダー名を挙げましたが、これらはあくまで一例に過ぎません。

[31:24] – ロニー：そこで興味深かったのは、当社の部品表（BOM）では顧客が何を購入したかは把握できていましたが、実際にはサードパーティ製プラットフォームの管理にも利用されていたため、環境の規模がはるかに大きかったのです。私たちはその事実を認識していませんでした。 これを直接製品に反映させるきっかけとなったのは、この情報を基に顧客やベンダーと協力したことでした。私たちはベンダー（その場合はMeraki）に連絡を取り、「そこで何をしているのですか？ 興味深い話ですね。もっと詳しく知りたいです」と尋ねました。 この情報を基に、統合機能として製品に組み込み、現在提供されています。

[32:08] – 司会者：つまり、Merakiとの連携、Merakiの管理機能ということですね。

[32:15] – ロニー：その通りです。これは基本的に、その機能を実現しようとしていたお客様との話し合いから生まれたものです。繰り返しになりますが、プラットフォーム上では実現可能でしたが、最初からそのように動作する方がより便利だったでしょう。

[32:34] – 司会者：そうですね。その通りです。これは「APIファースト」という考え方そのものに帰着します。お話を伺っている間、あなたが挙げられた利点について考えていたのですが、そもそもアーキテクチャを適切に設計しておけば、そこから多くのメリットが自然に生まれるということですね。 その一つは、設計が不十分な場合よりもはるかに迅速に新しい機能を追加できることです。もう一つは、当初意図していなかったことさえも、うまく、かつ堅牢に実行できることです。実は、これが優れたアーキテクチャの指標の一つでもあります。つまり、「計画していなかったことさえも実行できるか」ということです。 これはTCP/IPの素晴らしい点の一つです。かつては、TCPやUDPは動画を送信するようには設計されていないから、決して動画を送信できないと言われていました。しかし、その設計が十分に優れていたため、実際には動画の送信が可能になったのです。ですから、 「我々はAPIファーストだ」と言う際の課題の一つだと思います。それはまるで、「我々は正しくやった」と言っているようなもので、正しくやったことの恩恵は下流になって初めて見えてくるのです。ジョン、あなたもそのことに触れていましたね。目に見えないわけではありませんが、後からしか現れないのです。

[33:37] – 司会者：そうですね。よく設計されたシステムならではの「創発的特性」ですね。

[33:43] – ロニー：その通りです。その通りです。

[33:43] – 司会者：そうですね。あ、その言い方がすごく気に入りましたよ。「創発的特性」って。[笑い]

[33:49] – 司会者：さて、ロニーさん、他に強調したい点はありますか？ かなり多くの話題を網羅しましたね。ネットワーク運用におけるオープンシステムの利点や、APIファーストの利点についても話し合いました。他に強調したい点はありますか？

[34:01] – ロニー： ええ、聴衆の皆さんに一つお願いがあるのですが、これも多くの顧客との議論や、私たちが関わる顧客環境での経験に基づいたものです。製品やプラットフォームを評価する際は、ぜひこの点を考慮してください。単に自分が担当しているサイロ内、つまり今まさにその要件を抱えている場所だけを考えるのではなく、 もう少し広い視野で考えてみてください。「どのような事業部門や、社内の他のステークホルダーを巻き込む必要があるか。彼らがどのようにそれを利用し、どのような追加要件を持っているかを本当に理解するためには？」そして、プラットフォームが実際にどのように機能しているのか、その内部構造を深く掘り下げて調べてみてください。「ああ、これで仕事はできる」と単にチェックリストを埋めるだけではいけません。

[34:51] – 司会者：それは……[咳払い] お話を聞いていて、まさに同じことを考えていました。というのも、どのベンダーでも「ああ、うちはAPIファーストです。チェックボックスにチェックを入れてください」と言うのは簡単ですから。 真に「APIファースト」な企業と、そうではないのにそう主張しているだけの企業との違いを見極めるために、どのような質問をすればよいでしょうか？つまり、その内実を覗き込むとき、何に注目すればいいのでしょうか？

[35:15] – ロニー：そうですね。 ですから、まず最初に、特定のOpenAPI仕様などに準拠しているかどうかを尋ねます。2つ目は、間違いなくこうです。もしそれがRFP（提案依頼書）などではなく、単なる話し合いであるなら……RFPのプロセスシートなどとは少し事情が異なります。 しかし、単なる話し合いの段階であれば、ベンダーやプロバイダーにこう問いかけましょう。「プラットフォームXYZとの統合には、どのようにアプローチしますか？これが私のユースケースです。どうすれば実現できますか？」もし彼らが「ああ、できますよ」とだけ答えるなら、その方法を尋ねてください。「そのプロセスがどのようなものか、ステップごとに説明してください。」

[36:05] – 司会者：はい、それは非常に理にかなっています。また、一歩引いて考えると、「他のプラットフォームとの連携が良好である」という、やや曖昧な選定基準があるかもしれません。 必要ないと考えているため、そもそもその項目を選定基準に含めていない可能性もあります。しかし、それでも確認しておくことは賢明です。なぜなら、例えば自社が他社を買収したり、逆に他社に買収されたりした場合、何が必要で何が不要かという判断は一変する可能性があるからです。

[36:37] – ロニー：ええ。まさにその通りです。

[36:42] – 司会者：なるほど。非常に参考になりました。時間を割いて詳しく説明していただき、ありがとうございます。これは私たちにとっても、リスナーの皆様にとっても大変有益だと思います。ロニーさん、個人的に連絡を取りたい場合、どこに連絡すればよいでしょうか？

[36:55] – ロニー：一番簡単な方法は、LinkedInにアクセスして「Ronny Wolf, BlueCat Networks」と検索することです。間違いなく検索結果の1番目、最初のヒットになります。そこで私が見つかるはずです。ぜひコネクトして、メッセージを送ってください。できるだけ早く返信するよう努めます。

[37:16] – 司会者：それでは、最大の課題についてお聞かせください。というのも、顧客の課題を理解することが、あなたの仕事そのものですから。

[37:23] – ロニー：その通りです。

[37:23] – 司会者：わかりました。その他の皆様も、ぜひ bluecatnetworks.com をチェックして、詳細をご確認ください。 また、BlueCatからは、お問い合わせフォームにご記入いただき、ネットワークについてチームメンバーと相談する時間を設定し、BlueCatについてさらに詳しく知っていただくようお願いされています。繰り返しになりますが、bluecatnetworks（「s」付き）.comです。詳細については、お問い合わせフォームにご記入ください。[音楽] ありがとうございました。