AIがエンタープライズソフトウェア開発をどう変えているか

[0:02] – ジョン・バーク：[音楽] こんにちは、ネメルテスのCTO、ジョン・バークです。今回は共同司会者の…

[0:07] – スコット・ロボーン：私はスコット・ロボーンです。SolutionalのCEOであり、ここPacket Pushersで放送されている姉妹番組『Total Network Operations』のホストを務めています。

[0:14] – ジョン・バーク：今お聴きいただいているのは『Heavy Strategy』です。この番組は「正しい答え」を与えるのではなく、「正しい問い」を投げかけることを目指しています。本日のゲストは、BlueCat Networksの最高戦略責任者（CSO）、アンドルー・ワートキンさんです。アンドルーさん、ご出演ありがとうございます。

[0:25] – アンドルー・ワートキン：お招きいただきありがとうございます。楽しみにしています。

[0:30] – ジョン・バーク：そして今日の番組では、まさにネットワーク管理会社が取り上げるような話題、つまりエンタープライズネットワークの自動化にAIを活用する際の課題について話し合います。IT担当者がネットワーク自動化の取り組みを加速させるためにAIを活用しようとしていることは、皆さんご存知の通りです。 なぜ、それは思ったほど単純ではないのでしょうか？なぜ、99％のケースで、単にクロードの言うことを鵜呑みにできないのでしょうか？

[0:50] – スコット・ロボーン：そうですね、つまり、許可モードにして「実行」をクリックするだけですね。[笑い] これで完了です。

[0:55] – アンドルー・ワートキン：そうですね。興味深い話なのですが、私は物心ついた頃からずっとソフトウェア開発をしてきました。私が手書きで文字を書けないのには理由があります。人生の大半をキーボードを打って過ごしてきたからです。そして、この仕事を心から楽しんできました。 しかし、ネットワークの側面では興味深いことが起きています。というのも、チームが本当に素晴らしい仕事をしているからです。ここで言う「チーム」とは、自動化やプリコード生成、プリLLMを推進し、ソフトウェア開発会社がソフトウェアを開発するのと同様に、ソフトウェア開発の方法論を成熟させようと真摯に取り組んでいるネットワークエンジニアたちのことを指しています。

[1:37] – アンドルー・ワートキン：そしてAIやLLMによる自動生成コードの場合、そうしたベストプラクティスなしでは、ネットワーク上で何が起こるか考えると少し恐ろしいですね。 つまり、おそらくは、ソフトウェア開発に関するより洗練されたプロセスへと、それらのチームがさらに変革していく必要があるということになるでしょう。なぜなら、物事がより速く作成されるようになればなるほど、おそらく不具合も増えるからです。

[2:04] – スコット・ロボーン：あなたの主張には本当に共感しますよね？ 私が担っているもう一つの役割として、Network Automation Forumという組織の共同創設者があります。そして、今日の収録時点で、ドイツのミュンヘンで開催された前回の会議「AutoCon 5」から戻ったばかりなんです。 AIが話題に上る前から、ネットワーク自動化の導入に対する抵抗感について議論を始めていましたよね？ 自動化をフル稼働させることに対しては、常に一定レベルの抵抗感がありました。そして今、ボットやエージェントが登場すると、白目をむくような反応が見られ、懐疑的な見方が強まっています。

[2:55] – スコット・ロボーン：その例えをこの会話の一部として使わせていただきたいですね。私も同感です。 ソフトウェアエンジニアリングやソフトウェア開発において、優れたベストプラクティスが確立される必要があります。なぜなら、ネットワーク運用における私たちの業務の多くは、その下流に位置するからです。冒頭で少し時間をとりすぎているかもしれませんが、これが私の見解であり、あなたとこの対話を交わすことに本当に興味があります。

[3:20] – ジョン・バーク：そうですね、素晴らしい。まさにその通りだと思います。ネットワーク部門における自動化への不信感は、25年もの間根強く続いています。私たちはこれまで、自動化を過度に、そして早すぎる段階で信頼しすぎたことで、何度も大きな痛手を負ってきました。

[3:41] – アンドルー・ワートキン：そうですね。私がいつも耳にするのは「信頼」という言葉です。特に、繰り返し行われるテンプレート化された作業においてはなおさらです。

[3:46] – ジョン・バーク：そうですね。

[3:46] – アンドルー・ワートキン：もしそれが、単純で、反復可能で、テンプレート化された範囲外のものなら、そこからは信頼の欠如がかなり深刻に現れ始めます。 そして、私たちの業界の仲間ならご存知の通り、ベンダーが「ポイント＆クリックするだけで、シンプルで簡単な自動化」と売り込んでくるのは、エンドユーザーからの信頼を得る上で、おそらく最悪の方法でしょう。不透明であればあるほど、通常は懸念も大きくなり、AIの世界ではその潜在的な不信感を加速させてしまいます。どうでしょうか。 この問題への取り組み方や信頼を高める方法については議論できますが、これはネットワーク分野に限った話ではありません。明らかに、あらゆる分野に共通する問題なのです。

[4:44] – アンドルー・ワートキン: 私たちの多くは、ソースコード管理が行われていなかったり、レビューが適切に行われていなかったり、現在の環境に適しているか精査されることなくどこからかコードがコピー＆ペーストされたりといった環境で働いた経験があります。その例を挙げればきりがありません。 そして、そのペースを加速させただけで、1日で10件もの重大な問題に遭遇することになりかねません。

[5:11] – アンドルー・ワートキン：確かに、それは非常に大きな可能性を秘めています。しかし、これは単なるソフトウェア開発だけのことではないですよね？ デバッグや、本番環境で何が起きているのか、なぜ動作しないのかを突き止めようとする作業も含まれます。そうした分野のいくつかでは、適切な専門知識を持つ人がいて、伝えられる情報に対して批判的な姿勢を保ちさえすれば、短時間で成し遂げられる仕事の量は驚くほどです。 本当に驚くべきことです。ただ、「ああ、そう言われたから、そういうことなんだ」と鵜呑みにしない限りは。 よし、こうしよう。こうすべきだ」と安易に受け入れてしまわない限りは。そこが懸念される点なのです。なぜなら、LLMは、どんなに別のプロンプトを与えようとも、根本原因を見つけたと思い込んで、物事を白黒はっきりさせがちだからです。

[5:58] – ジョン・バーク：自動化を加速させるという考え方の良い点は、人々がより良い実践を加速できるよう支援できるという点です。 AIを活用してより良い実践方法を取り入れれば、自動化プロジェクトをより頻繁に完了できるようになります。中途半端な状態で放置したり、4分の3ほどしか終わっていないまま、デバッグもドキュメント化も完全には行わずに、次の緊急案件に移ってしまうようなことはなくなるでしょう。 1日、あるいは2日、1週間、2週間のうちに、プロジェクトを最後までやり遂げ、不安や恐れを抱くことなく、自信を持って再び活用できる成果物を残せる可能性が高まるのです。

[6:39] – アンドルー・ワートキン：そうですね。そうですね。その多くは単にアーキテクチャの問題です。また、その多くは、適切な開発者のマインドセットに関わっています。つまり、「将来これを保守する人々のために書いているのだ」という意識を持ち、そのことを常に念頭に置いておくということです。

[6:58] – ジョン・バーク：それは当然のことですよね？ どの開発者も、初日からそのことを考えているものです。

[6:58] – アンドルー・ワートキン：ええ。その通りです。[笑い] そうですね、特に「ああ、この問題を解決するために手っ取り早いスクリプトが必要だ」というところから始まって、6ヶ月後に誰かがそれを見つけ出すような場合です。

[7:15] – アンドルー・ワートキン：つまり、その多くはアーキテクチャに帰着するのです。その自動化に含まれる要素の多くは繰り返しになるでしょう？ 認証はどう行うか？ ロギングに関する基準は何か、あるいはどのようにログを記録したいか？ デバイスとはどのように連携するか？ パスワードはどのように保管され、保管場所からどのように取り出すか？ どのようにテストを行うか、あるいは変更を元に戻すことをどう考えるべきか、といった点です。 私が今挙げたほぼすべての要素は、この適切な方法論において繰り返し利用可能なものです。そうすれば、他の要素をすべて実装する必要はなく、ビジネスロジックを追加するだけで済みます。その結果、すべてのコードは常に最新の状態が保たれ、テストも実施され続けることになります。

[8:01] – アンドルー・ワートキン：でも、何かを素早く作り上げるのは本当に簡単です。そして、私が今挙げたすべてのことは、8人がそれぞれ8つの異なる、完全に機能するAからZまでのスクリプトやアプリケーション（何を作っているにせよ）を次々と作り上げるよりも、時間がかかりそうにも聞こえます。 ですから、正しいスタートを切り、これをいかに持続可能なものにするか、どこに人間を関与させるか、どこで人間の関与が不可欠か、そしてこれを安全に行うためにどのような実践を取り入れるかを考えることが、これまで以上に重要になっているでしょう。

[8:50] – アンドルー・ワートキン：その多くは、過去数十年にわたってソフトウェアを構築する中で、私たちが常に考慮してきたことや懸念してきたことと同じですよね？ その一部は、単に「今ならどれほど迅速に実現できるか」という違いに過ぎません。そして、単にStack Exchangeからコードをコピー＆ペーストしているだけというわけではありません。誰でも、その環境で動作するコードを生成できるようになったのです。それは簡単にできますが、2年前にはそうではなかったのです。

[9:28] – スコット・ロボーン：そうですね、私たちは今、この急速に変化し、実験的な時代の真っ只中にいると思いますよね？ほんの数年前にさかのぼれば、人々はチャットベースのツールを初めて体験し、その結果は千差万別でした。 LLM（大規模言語モデル）の非決定性という問題、それが私たちの最初の経験でした。その後、「バイブコーディング」が登場し、それがプロトタイピングにとってどれほど強力なツールであるか、一方で企業のコードベースにとってどれほどスパゲッティのような混乱を招く可能性があるかも目の当たりにしました。そして今、仕様駆動開発やテスト駆動開発といった新しい手法が台頭してきています。 私の最初のChatGPT 3.x体験とは対照的に、「よし、ツールの使い方はこうだ。そして、テクノロジーへの信頼を実際に築くにはこうすればいい」という考え方が、今まさに台頭してきているのではないでしょうか？ こうした戦略や再現性のあるツールが登場する中で、これらの側面について、あなたはどのような動向を感じていますか？

[10:30] – アンドルー・ワートキン：ええ。確かにそうした事例は目にしていて、私たちもいくつか試行錯誤しながら導入しています。 興味深いことに、私の会社としても、また私個人としても最も成功を収めたのは、私のキャリアの中で（会社ではなく、私個人として）おそらく最も時間を割いてこなかった部分、つまり事前の仕様策定と、LLMを活用したトレードオフの検討です。 そここそが、私の経験を活かせる部分です。「どうアプローチすべきか？」という点を、初期段階で時間をかけ、作業を適切な単位に分解し、適切なガードレールを設けるといった取り組みは、単に「望む結果を正確に記述したプロンプト」を入力しようとするのとは対照的に、画期的な変化をもたらしました。

[11:27] – アンドルー・ワートキン：これは、いわば反復的な仕様とテストの開発で、「よし、高速なeBPFロガーを作りたい」というところから始まるんですよね？ 「そんなことは今までやったことがない」ですよね？ だから、どのようなトレードオフがあるのかさえ分からないのです。それなのに、返ってくる結果をどこまで信頼できるでしょうか？ しかし、非常に大まかなレベルから始めることはできます。「これをやりたい。あなたの意図は何ですか？」と。

[11:57] – ジョン・バーク：その通りですね。ええ。その一つ下のレベルに、非常に重要なポイントがあると思います。それは、自分の意図やニーズを非常に明確に伝えることが不可欠だということです。 ネットワーク上のハードウェアの設定をソフトウェアでいじっているとき、間違った設定をいじってしまうと、トラフィックの流れが遮断されたり、プロセッサに過大な負荷がかかって、ログの生成や送信にすべてのリソースが割かれてしまい、パフォーマンスが著しく低下したりする可能性があります。 つまり、インフラストラクチャ上のミスが起こりうる環境にあり、そのミスは自動化のスピードで発生し、非常に大きな影響を及ぼす可能性があるのです。

[12:47] – アンドルー・ワートキン：ええ、その通りです。つまり、DNSの世界、特にパブリックな側面だけを見ても、大手公開企業が発表した直近の数回の大規模なサービス停止事例を振り返ると、その80％は、自動化によるDNSの変更が原因でシステム全体がダウンしたケースだったと思います。 そのことについて、LLMを非難するつもりは微塵もありません。しかし、解決策を導き出すスピードが速ければ速いほど、そして特に、コーディングパートナーやデバッグパートナー、パフォーマンスパートナーが、どのようなユースケースであれ、確信を持っていれば持つほど、「ああ、そうか」と納得しやすくなるでしょう。 さらに、誰もが「許可疲れ」に陥り、指が勝手にキーを押し続けてしまうこともあります。ですから、こうした事態が起きないよう、その挙動を適切に監視し、確実に防ぐことも重要になります。

[13:46] – アンドルー・ワートキン：そうですね。つまり、意図をより的確に表現するには、そうした要素を含める必要があるのです。 何が問題になり得るか？ 何が懸念事項か？ 実際にテストすべきことは何か？ ここでいう「負荷」とは具体的に何を指すのか？ 負荷がかかった際、システムはどのように振る舞うべきか？ これらすべてを最初から明確にしておく必要はありませんが、考慮すべき事項のカテゴリーを把握できるだけの適切な経験を持っていることは重要です。

[14:21] – アンドルー・ワートキン：しかし、あなたがする必要のないこと――これは、この半年間という信じられないほど短い期間で、ツールとプロセスの両面で本当に成熟してきたと思うのですが――それは、具体的に何を納品すべきかについて4ページもの指示書から書き始めることです。 もしフロンティアモデルではなく、より安価でランニングレート型のモデルを使っているならそうするべきですが、その場合はフロンティアモデルにランニングレート型モデルの仕様書を作成させればいいのです。プロンプトの生成に関しては、LLMほど上手にはなれないでしょう？

[14:57] – スコット・ロボーン：そうですね、私はあるテクニックを取り入れています。基本的には、LLMに私へのインタビューをさせるというものです。 1ページ半ほどの、かなり詳細な意図を提示するんです。そして、このプロセスを使ってSDD用の適切なマークダウンファイルをすべて作成する場合、第一に、コストが安いんです。 トークンコストはかかりますが、インタビュープロセスを経て検証・確認できる、人間が読みやすいドキュメントを作成できるのです。先週、素晴らしいコメントを耳にしました。「コードはある意味、無料だ」と。 私たちは、コードを完璧に仕上げるために苦労することを当たり前のように考えてきましたが、今ではエージェントにコードを書いてもらい、反復作業を行い、ゴミのように見えるものは捨ててしまうことができるのです。そして、それが実際にゴミであるかどうかを見極めるには、十分なドメイン知識が必要ですよね？

[15:52] – アンドルー・ワートキン：その通りです。そして、その最後の点は、個人的な側面としては、10年後にすべてがどうなっているかという私の懸念でもあるのですが、同時に、今この瞬間において最も重要なことでもあります。 ドメイン知識や、物事がどのように失敗し得るか、どう機能すべきか、どう gracefully fail すべきかといった経験や専門知識がなければ、トラブルを招くことになります。 でも、そうですね、その考え方は気に入っていますし、私もそうしています。おそらくあなたほど厳格なやり方ではないですが、「ここで私が考え落としていることは何か？」という視点は大切にしています。

[16:29] – ジョン・バーク：その通りです。ここで他に何が問題になり得るでしょうか？LLMは、美味しくて食べられるキノコと同じくらい喜んで、致命的な毒キノコを持ってくることもありますし、ざっと見ただけでは[咳払い]区別がつかないのですから、そうしたドメインの専門知識はかけがえのない、絶対に不可欠なものになります。

[16:50] – アンドルー・ワートキン：そうですね。そして、ここで何が起こるのか、そしてなぜプロセスがこれほど重要なのかを説明しましょう。人々は座って、LLMと認識が一致していると思い込み、数週間はそれが真実のように見えます。一見、LLMは物事を記憶しているように見えるのです。 ところが7日目に新しいセッションを始めると、LLMはこれまで知っていたことをすべて忘れてしまったかのように振る舞い、その1週間の間に性能が徐々に低下していたことに気づきます。というのも、これを文書化していなかったからです。適切な記憶を保存したり、プロンプトやその他すべてを確実に更新したりしていなかったのです。 そして、信じられないほど幼稚な判断を下すのです。私たちはこうしたシステムを人間化して捉えてしまうため、「私は分身と仕事をしているのだろうか？　一緒に仕事をしているこの人物は一体誰なのか？　どうしてこんなことを忘れてしまったのか？」といった考えが頭をよぎるのです。

[17:34] – アンドルー・ワートキン： つまり、オペレーターや開発者、ネットワークオペレーターなど、それを使用する人がセッションのメモリ状態を明確に把握しておらず、必ずしも決定論的なものではなくとも、少なくとも過去の経験に基づいた何かが起きると想定してしまうような瞬間に、多くのエラーが発生するのです。 そして、予期せぬ事態が発生します。これを何と呼べばいいでしょうか？　その一部は、単に「再発見のコスト」です。適切なドキュメントが作成されていないため、トークンやクレジットなど、多額のコストを費やして、同じことを何度も何度も再発見することになってしまうのです。

[18:22] – アンドルー・ワートキン：そして、これらは一般的に、使用するコーディングツールにもよりますが、LLMが本当に得意とする分野です。私はClaudeをよく使いますが、それ以外にもいくつか使ってきたことがあります。 セッションを終えるたびに、私はこう尋ねます。「今日、何をしたのか？ 何を再発見する必要があったのか？ そして、再発見する必要があったことのうち、二度と再発見しなくて済むように、何を適切に文書化すべきか？」もちろん、これだけで全てではありません。実験も有効ですから。時には、失敗から多くのことを学ぶこともあります。

[18:54] – アンドルー・ワートキン：そして、個人的な側面でありながらも、やはりプロフェッショナルな側面である「鍛え抜かれたソフトウェア」について話を戻すと、いわゆる「実戦」でも機能するソフトウェアのことです。実験室だけで動くわけでも、順調なケースだけで動くわけでもありません。とにかく動くのです。 プレッシャーがかかっても、それでも機能するのです。そのレベルに到達するには、実際にやってみた経験、とりわけ失敗した経験が必要です。

[19:21] – アンドルー・ワートキン：それは、以前そのミスをしたことがあるから、あるいはその出来事が起きた時に現場にいたから、「何かがおかしい」と感じるようなものです。そして、その種の学習は、私たちの脳が処理する非常に大規模な文脈に特有のものなのです。メモを見直す必要さえありません。 失敗した経験があれば、そのパターンを即座に見抜くことができます。それは脳に組み込まれているのです。そして、目的がなければ、そうしたことがどうやって起こるのか、私にはまったく分かりません。目的がなければ、です。

[20:08] – ジョン・バーク：また、時々「もうそう遠くない将来、AIにスクリプトやプログラムの開発を任せることさえなくなるだろう」という話を耳にします。私たちはただ、どうしたいかを伝えるだけで済むようになるのです。 AIがバックグラウンドでプログラムを起動し、実行させて、仕事を片付けてくれる。次に同じ作業が必要になった時も、AIがプログラムを生成して実行させれば、それで完了だ。つまり、AIが私たちのために自動化を作るのではなく、AIそのものが自動化そのものになるのだ。

[20:34] – アンドルー・ワートキン：そうですね。

[20:34] – ジョン・バーク：私としては、今あなたが言っていることは、それに対する反論だと思います。 つまり、「なるほど」とは思うのですが、この問題を2回目に遭遇し、解決するためのプログラムを生成する段階になったとき、前回どう解決したかを覚えているでしょうか？何が問題で、どう修正したかを覚えているでしょうか？覚えているかもしれないし、覚えていないかもしれません。 その問題が解決されるまでは――あなたが言うように、実際に怒りの渦中にあっても機能するもので解決されるまでは、つまり、AIにプロンプトを入力する際に私がどれほど怒っていても、それでも正しい答えや良い答えを返してくれるようになるまでは、問題は解決されていないと思います。

[21:08] – アンドルー・ワートキン：そうですね、それだけでは解決しません。それに付け加えるとしたら、逆の問題に直面するということです。なぜなら、LLMは基本的にパターンを照合しているだけだからです。ですから、何かが特定のパターンに当てはまるように見えても、それが正解だとは限りません。 皮肉なことに、この種の事例がほんの数件しかない場合――例えば、「何かが失敗した、理由はこれだ、このパターンは分かっている」といった場合――、何かが無理やりそのパターンに当てはめられてしまう可能性が高くなります。彼らは、たとえわずかに合うだけでも、丸いペグを四角い穴に無理やり押し込もうとするでしょう。

[21:52] – アンドルー・ワートキン：そして、特にブラウンフィールドの世界では、「よし、 「意図を伝えさえすれば、スクリプトが作成され、作業が完了し、二度と確認する必要はない」という考え方と、実際にエンタープライズネットワークでそれを実行する間には、まだ少し隔たりがあると思います。現時点では、それを実現するためのツールがすべて揃っているわけではないからです。 現時点では、それを実現するための予算が必ずしも確保できていないのです。さらに、過去の経緯があり、その中にはAIの世界では好ましくない要素――例えば、暗黙知やその場限りの対応といったもの――が含まれています。そして、これは非常に具体的な理由で行われたことですが、その周りには「立入禁止」の黄色いテープが張られているような状態です。 理由は誰にもわかりませんが、変更すればすべてが機能しなくなることはわかっているため、もう変更は行っていません。これは一度も文書化されていませんでした。あれも文書化されていませんでした。

[22:43] – アンドルー・ワートキン：そこで、ソフトウェア開発における非常に有名な基礎書の一つに立ち返りたいと思います。ツールや戦術は変わりましたが、この本は今なおその真価を失っていません。マーティン・ファウラーの『リファクタリング』です。 序文の最初の数段落に、もしテストできないなら、この本を本棚に戻してください、と書かれていると思います。要約していますが、要はそういうことです。テストできなければ、変更することはできません。 そして、暗黙の知識や特例が横行し、すべてがパターンに従っているわけではないこの世界において、どのようにそれに取り組めばよいのでしょうか？特に、テスト対象となるものが何もない場合はなおさらです。実験環境には、そうした特例は存在しません。実験環境においては、「これを実際にどのように適切にテストすればよいのか？」という課題に直面することになります。

[23:39] – アンドルー・ワートキン：そして、それが変更管理プロセスを長引かせる原因となっているのです。組織は、「そこを触ると壊れてしまう」ということを学んでしまったのです。 だから、変更作業は3時間半という特定の「変更ウィンドウ」の中でしか行われず、その時間帯には他の予定を一切入れられないのです。根本的な問題は解決されておらず、単にプロセスをその問題に巻き付けているだけなのです。ですから、企業や組織も、こうした問題にどこから着手すべきかを見極める必要があります。 言うまでもありませんが、新規システムはそもそもこのように構築されています。素晴らしいことです。既存のものを変更すること――それがソフトウェアであれネットワークアーキテクチャであれ――は、人間にとってもLLMにとってもはるかに困難です。しかし、少なくとも人間には、ある程度の「暗黙知」があることを期待したいものです。

[24:33] – スコット・ロボーン： さて、あなたが先ほど説明したすべてに関する指摘に関連して、ここにもう一つエキサイティングなことが待ち受けていると思います。LLM（大規模言語モデル）があれば、すべてがプロンプトのように見えるでしょう？そして、LLMにとってすべてが問題というわけではないと、私たちの多くが気づき始めていると思います。 私たちの目の前には、非常に興味深く、潜在的に有用な一連の新しい計算技術が広がっていますが、他の手法がすべて不要になったわけではありません。AIの分野において、機械学習は依然として他の用途で非常に有用です。統計的回帰については、私の知る限り、トークンをほとんど消費しませんよね？

[25:11] – ジョン・バーク：そうですね。

[25:11] – スコット・ロボーン：つまり、自分のツールボックスに新たなツールを追加しているわけです。そして、私たち全員が直面することになる本当に面白い課題は、適切な仕事に適切なツールを使うことですね。LLMが適している場面ではLLMを、MLが適している場面ではMLを、回帰分析が適している場面では回帰分析を使う、といった具合です。 おそらく、あなたが指摘した「質問があるたびに一から作り直す」という問題については、私の制約条件の一部として次のようなものが考えられます。「よし、問題を解決したので、それをITサービスカタログに登録した。 そして、もし私のサービスカタログの中に、このプロンプトに90％以上一致するものがあるなら、サービスカタログにあるものを使い、そのための別のソリューションを作成するためにトークンを浪費しないようにする。 そうですよね？ これはあくまで私の思いつきですが。しかし、私たちが皆でこの問題を解決していく上で、こうしたアプローチはすべて検討すべきだと考えています。そして、私はこの件について、懐疑的というよりはむしろ前向きに捉えています。1年後にまた話を聞いて、私が同じように感じているかどうか確かめてみてください。

[26:05] – アンドルー・ワートキン：そうですね、サービスカタログの側面は興味深いですね。つまり、良い点は、LLMに「この問題を以前に解決したことがあるか」と確認させればよいということですし、繰り返しになりますが、LLMはパターンの照合が極めて得意ですから、何か見つけてくれるでしょう。 実際、ここ1年ほどで私が開発してきた手法の中で、自分が何をしたかというドキュメントと、実際に何をしたかとの間のその密接な関連性は、[鼻を鳴らす] 非常に価値があるものです。それは、……という観点からも……

[26:43] – アンドルー・ワートキン：ちょっとしたエピソードを。 何年も前のことですが、私はアプリケーションライフサイクル管理（ALM）分野の企業のCTOを務めていました。つまり、ソフトウェア開発を支援するソフトウェアを構築していたわけですが、当社の理想的な顧客像の一部には、安全性に関わる組み込みソフトウェア分野が含まれていました。そこでは、欠陥がオペレーターに危害を及ぼす可能性があり、例えば自動車業界などが挙げられます。

[27:08] – アンドルー・ワートキン：そうした世界には、ISO 26262やAutomotive SPICEなど、あらゆる種類の規格が存在します。 そして、それらの規格の一部として、要件とコードの間にはトレーサビリティが確保されていなければならない、ですよね？ もし要件やコードが変更された場合、そのトレーサビリティに問題が生じる可能性があり、私はその影響をすべて洗い出さなければならなくなります。 「今回の変更では、コードを変更しましたが、要件は依然として正しく、テストケースも正しく、アーキテクチャも正しいままです」と説明しなければなりません。こうした疑わしいトレースについて、すべてその作業を行わなければならないのです。

[27:38] – アンドルー・ワートキン：B2Bソフトウェアを開発している人に、そのレベルのトレーサビリティが必要だと説得することはできないでしょうが、私はLLMを活用した開発を行う際にはそうしています。なぜなら、その効果は驚くべきものだからです。 第一に、まあ、私はそれをとても楽しんでいるという理由もありますが、LLMが追跡を行ってくれるからです。LLMはドキュメントまで遡って追跡できるため、なぜ私たちがそのように実装したのかを素早く把握できます。そして、そのドキュメントを執筆しているのはLLM自身であり、LLMは自分自身のためにドキュメントを書く方法を知っているのです。

[28:14] – アンドルー・ワートキン：それは、たとえ……時々私は「人間向けに書いてください」と言うこともあります。また、「ソフトウェア開発の仕組みを知っているかもしれないし、知らないかもしれない顧客、あるいはPythonを一度もインストールしたことがないかもしれない顧客のために、このドキュメントを書いてください」と言うこともあります。 しかし、そうしたドキュメントの場合、LLM専用の補遺を付けるか、あるいは最初からLLM向けに書くように指示することがよくあります。第一に、文章が簡潔になりますし、第二に、LLMは、効率や読み込みコストの観点から、自分たちが読むためのドキュメントを作成するのがかなり得意ですよね？ 人間向けのバージョンはコストがかかります。

[28:57] – アンドルー・ワートキン：しかし、それとは別に、もう一つ重要な点があります。つまり、「次の人（開発者）がメンテナンスできるようにソフトウェアを書く」ことに加えて、「次のLLMがメンテナンスできるようにソフトウェアを書く」ことも考慮に入れ、当然ながら、大量のテキストを迅速に取り込んで解析する能力も与えているということです。 ええ、コード内でもコード外でも、これほど優れたドキュメントは今まで見たことがありません。人間として、これほど多くのドキュメントを作成することは決してなかったでしょう。なぜなら、人間がドキュメントを書く際に抱く「ああ、これは覚えているだろう。 「うん、これはかなり読みやすい。コードを読めばわかる、明らかだ」とか、「私が何を意味していたかは誰にでも理解できるだろう」といった前提で、人間としてこれほど多くのドキュメントを作成することは、絶対にあり得なかったでしょう。

[29:46] – ジョン・バーク：ええ、その通りです。

[29:46] – アンドルー・ワートキン：ええ、「ソート中」と言ったんです。「今、ソートしてるんだ」ってね。そういうことが膨大な数の不具合につながるんですが、それ以上に、時にはもっと悪いこともあるんです…… あの古い格言は何だったっけ？ インターネットに接続できないことより悪いのは、接続が不安定なインターネットだけだ、ってやつだ。

[30:05] – ジョン・バーク：その通りですね。はい。

[30:05] – アンドルー・ワートキン：そうですね。ドキュメントについても同じことが言えます。

[30:05] – ジョン・バーク：つまりある意味、 あなたはAIに対して、その専門知識を向上させるための指導を行い、物理的なデバイスからなるネットワークを運用することの意味、リスク、実験の限界などについてより深く教える一方で、コードのドキュメント化や自身の動作の説明といった行動を通じて、良いチームメンバーになるための指導も同時に行っているのです。

[30:42] – アンドルー・ワートキン：その通りです。いや、それは良い例えですね。というのも、私が普段、特にシニア層の人たちにアドバイスしていることそのものだからです。「自信に満ちていて、自分たちのやり方が正しいと確信している、ジュニアから中級レベルのソフトウェア開発者が4人、あなたと一緒に働いていると想像してみてください」と。 そこで、そのうちの1人が「これが最善のやり方です」と言ってきたら、あなたはこう尋ねるでしょう。「なぜ？ どんな根拠がある？ 十分な根拠はあるのか？ その解決策にたどり着く前に、どのような代替案を検討したのですか？」と尋ねるはずです。こうした視点でやり取りを考えれば、常に適切な質問を思いつくようになるでしょう。

[31:32] – アンドルー・ワートキン：機能するコードを素早く生成する能力という点では、これはジュニアや中級レベルのソフトウェア開発者ではありません。しかし、思考プロセスという点では、多くの場合、中級レベルのソフトウェア開発者の方が優れた思考プロセスを持っています。つまり、重要なのは思考プロセスなのです。 パターンマッチングやLLMの持つその他の「魔法」のような機能の話ではないのです。

[32:00] – アンドルー・ワートキン：それが最大の過ちだと思います。バイアスであれ、確証バイアスであれ、人々は「こうやるんだ」という肯定的な答えを求めているものです。もし彼らが「ねえ、これについて考えていたんだけど、 これっていいアイデアかな？」と尋ねてきた場合、それがLLMとのやり取りにおいて最悪の方法であることは誰もが知っています。なぜなら、LLMは喜んで「素晴らしい。うわー、あなたは本当に賢いですね。それは私が今まで聞いた中で最高の方法です」と返してくるからです。

[32:33] – スコット・ロボーン：すべてのプロンプトに「おべっか使いは禁止」と明記しておけばいいんです。

[32:38] – アンドルー・ワートキン：[笑い] そうですね。 いや、100％その通りです。そうしてください。だって、同僚や部下、両親からそんなことを求められる必要はないのですから、LLMから求められる必要など絶対にありません。ただ、妻からはたまにはそう言ってもらえると嬉しいですし、子供たちからは間違いなくそう言ってもらいたいですね。 でも、それはさておき、そうですね。「ここでの専門家はあなた自身であり、あなたが作りたいもの、それがどう機能すべきか、成功とはどのようなものか、そして過去にどう失敗したかについて、あなたよりも知識が少ないものと一緒に仕事をしている」という考え方を、ぜひ持ち続けてください。その考え方を持ち続けてください。その考え方を持ち続けてください。

[33:12] – アンドルー・ワートキン：そしてある時点で、世界で最も優秀な4人のインターンが自分のために働いてくれているような気分になるんです。私にとっては、彼ら全員がまさにそれだからです。 たぶん5人、時には7人かもしれません。しかし、重要なのは「今夜中にこれを終わらせられる」というスピード感です。「10個の並列エージェントを起動してください」と。ちなみに、私は「お願いします」とは言いません。 「並列エージェントを10個起動して、当社のブリッツテストプロトコルを実行してくれ」。そうして朝目が覚めると、チーム全員が夜通し作業をしてくれていて、私は罪悪感を感じません。コーヒーを飲みながら結果を確認するだけです。これは非常に強力な体験です。

[33:51] – ジョン・バーク：そうですね。そして、あなたは暗に、あなたのようなベンダーがエンタープライズネットワーク部門におけるこの種の業務を支援するために何ができるかを示唆していると思います。それは基本的に、適切な安全機能を備えた、それらのAIが活用できる「パワーツール」を構築することです。 つまり、丸のこには自動停止機能が付いているので、以前ほど簡単に自分の指を切断してしまうことはありません。そういうことです。あなたが提供しているパワーツールを使って、当然すべきことを怠ったためにネットワークをクラッシュさせてしまわないよう、彼らを支援したいということですね。

[34:29] – アンドルー・ワートキン：そうですね。興味深い話ですが、今日の多くのソフトウェアベンダーと同様、私たちもバックエンド製品向けのMCPサーバーを開発しており、いくつかのバックエンド製品を抱えています。 そして、世の中の多くのベンダーと同様、当初は単に「よし、OpenAPIツールをこの新しいプロトコルでラップして公開すれば、LLMが何とか理解してくれるだろう」という考えでした。しかし、それが全く正しいアプローチではないことに、すぐに気づくのです。 ただ大量のトークンを浪費するだけです。推測の連続になります。LLMが何度も何度も推測を繰り返すのを、ただ座って見ているだけになってしまうのです。

[35:03] – アンドルー・ワートキン：そうですね、LLMはREST APIの使い方をかなり素早く理解できますし、MCPツールでラップされていれば、さらに速くなります。 しかし、だからといって、それがあなたのドメインを理解しているわけではありません。確かに、特に最先端のモデルは、単にあなたのドメインだけでなく、あなたが思っている以上にあなたの製品について理解している可能性が高いでしょう。

[35:33] – アンドルー・ワートキン：しかし、私たちが提供するもののうちの一部は、単にOpenAPIよりもドメイン特化度の高いツールだけではありません。LLMが認識している以上に、MCPサーバーと私たちのバックエンドサーバーの間で多くのやり取りが行われているという点です。 例えば、パケットキャプチャを例に挙げましょう。20メガバイトものパケットキャプチャをLLMに送る理由はありません。それだけでは何の役にも立ちません。 あるいは、AIではなくMLに送るべき時系列データ全体をLLMに送る必要もありません。では、LLMに必要なデータをどう提供すればよいのでしょうか？要約されたデータ、場合によっては「主観的な」データです。私たちは自社のシステムを熟知しているため、ある種の「見解」を組み込んだデータを提供できるのです。

[36:15] – アンドルー・ワートキン：ユーザーの質問――例えば「なぜこれが動かないのか？」といったもの――に答えるために、LLMには何が必要でしょうか？単に……というのではなく、そうした点をじっくりと検討する必要があります。 「怠惰」という言葉を使いたいところですが、「ナイーブ」という表現の方が適切でしょう。LLMがこうしたことをうまく解決してくれると単純に想定するのはナイーブです。特に、その処理を少しでも再現可能にしたいのであればなおさらです。ですから、確かに私たちはそうしていますが、それだけでは到底足りません。

[36:39] – アンドルー・ワートキン：さて、ソフトウェア開発に関する話は先ほど終わりました。これで、お客様は当社の製品に対して大量の自動化スクリプトなどを次々と作成できるようになりました。素晴らしいですね。では、お客様が自動化によってシステムダウンを招くことのないよう、そのためのベストプラクティスをどのように組み込めばよいでしょうか？ つまり、お客様に理解してもらうためには。 そこで、ネットワークアドバイザーなどの機能を通じて、プロンプトや具体的なコード、機能、トレーニング資料などを活用し、お客様が自動化を成功させられるよう支援しています。なぜなら、私たちの業界、特にDDI分野、とりわけDNSやIPAMの世界において、この業界の追い風は常に自動化だったからです。 こうした変化には、より迅速に対応しなければなりません。だからこそ、私たちは顧客の成功を願っているのです。

[37:30] – アンドルー・ワートキン：それは私たちにとって痛手です。数年前のことですが、LLMが登場するずっと前の話で、これはソフトウェア開発のプロセスがない場合に起こりうる被害の例に遡ります。 彼らは、当社の製品に対してスクリプトを作成する方法を独学で学んでいたようなもので、管理ユーザー権限も持っていました。スクリプトを作成してテストしたところ、社内のDNS環境全体を削除してしまい、その結果、即座にシステムから締め出されてしまいました。Active Directoryがダウンし、彼らはそれをLDAPに使用していたため、その他もろもろの問題が発生しました。結局、何かが壊れるしかなかったのです。

[38:05] – アンドルー・ワートキン：彼らがそこに座っている様子が目に浮かびます。私も以前、同じような経験をしたことがあります。大学時代、古いIBM PCで動作するアプリケーションにエンドレスループを書いてしまったことが一度あったと思います。あのPCではControl-Cが効かなかったんです。 3時間も作業したのに、できることはコンピュータを再起動することだけでした。これは、「やばい」という絶望的な気分を味わった、いくつかの例（その中には仕事上のものもあります）の一つです。[笑い] そうですね。あの人の頭の中で何が渦巻いていたか、想像がつきますよ。

[38:42] – アンドルー・ワートキン：ええ、もちろんこれは極端な例ですが、私が言いたいのは、ソフトウェア開発の現場では常に指標や測定基準について質問されるのですが、必ず誰かが「まあ、君たちは単にコード行数とかを使ってるだけだろう」と言うんです。それはまるで……

[39:00] – スコット・ロボーン：その通りですね。ええ。ソフトウェアエンジニアリングに携わる人なら誰でも、「書いたコード行数が多ければ多いほど良い」という考え方が適切な指標だというのは、正気の沙汰ではありません。

[39:13] – アンドルー・ワートキン：そうですね。ですから、私たちはそうはせず、誰もそれを提案しません。しかし、私が言いたいのは、適切な指標について考え始める際、確かにSaaSの世界ではもちろん、今ではこうしたスクリプトの世界においても、それだけではないということです。 重要なのは、「期待通りに機能したか？」、「この自動化は成功したか？」ということです。そして、成功しなかった部分から何を学び、それをどう取り入れてフィードバックループを回すか、ということです。もちろん、問題を解決するためのコード行数は少ないほど良いですが、何よりも重要なのは、「実際に問題は解決されたか？」ということです。

[39:52] – スコット・ロボーン：そうですね。もう一つの指標として「コード行数を最小限に抑える」ことを目指すと、別の問題を引き起こす可能性もありますよね？ それに、この環境や議論全体の中で私が本当にワクワクしていることの一つは、制約を定義する「技術」が、おそらく私たちのキャリアの中でかつてないほど重要になってきているという点ですよね？ 私たちには電動工具があります。適切なブレードガードやアースプラグをどこに取り付ければいいのでしょうか？私の祖父はポーター・ケーブル社向けに電動工具を作っていました。実は、彼の古い試作品がいくつか手元にあるのですが、指を失わないようにするための部品が欠けているため、デッキを作るのに使うことは絶対にありません。

[40:27] – アンドルー・ワートキン：そうですね。その通りです。

[40:27] – スコット・ロボーン：つまり、システム思考のことですね。そして、誰かが引き継ぐことになる「部族の知識」というものも……

[40:34] – アンドルー・ワートキン：[笑い] 確かにそうですね。

[40:40] – スコット・ロボーン：ジョン、この話題はいろんな方向に進みそうですね。どこへ話を進めたいですか？

[40:40] – ジョン・バーク：さて、話をまとめると、今やビジネスに携わる人々は、自社のソフトウェアポートフォリオを、最終的には人間の手ではなくロボットの手によって操作される「パワーツール」として捉える必要があるという考えについて、さらに掘り下げたいと思います。そして、それがエンタープライズソフトウェアの風景をどのように変えていくのか、という点についてもです。 これを使う際の企業内のプロセスがどう変わるかについては少し話しましたが、それ以外の部分についてはどうでしょうか？ ライセンス制度は変わるのでしょうか？ 他にどのような変化がもたらされるのでしょうか？

[41:18] – アンドルー・ワートキン：確かに。その一因は、株式市場やプライベートマーケット全般で見られた、一部のソフトウェア企業の時価総額下落にあると思います。まあ、株式市場は独自の動きをするものだということは、私たち皆が知っているはずですが。

[41:33] – ジョン・バーク：そうですね。

[41:41] – アンドルー・ワートキン：しかし、それとは別に、ライセンスモデルは間違いなく変化するでしょう。もしライセンスモデルが単に「ユーザー単位」に基づいているとしたら――もちろん、誰もが全員を解雇すると言っているわけではありませんが――「エージェントとは何か？」という点を考えなければなりません。 エージェントはユーザーなのでしょうか？ 企業は、適切な測定基準が何であるかを考えなければならないでしょう。多くの企業が、クレジット制へと移行しつつあります。真の価値は、このLLMを通じてどれだけの処理を行ったかという点にあるのです。しかし、企業は毎月予期せぬ請求書が届くことを好まないのです。

[42:20] – アンドルー・ワートキン：彼らは一貫性を好みます。そして初期段階では、特にLLM企業やAI企業自体が、価格がどんどん上昇し続けることが誰もが知っているような、不透明なクレジット型モデルに明らかに重点を置いていると思います。しかし、私たちにはそれができません。 ネットワークベンダーが「すみません、今月の請求額が2倍になりました。クレジットとトークンの比率を変更したからです。ちなみに、製品を改善して性能が向上したので、その分追加料金を支払っていただくことになります」などと言うことはできないでしょう。 私たちの世界では、そんなやり方は通用しません。ですから、確かに、ライセンスモデルは変わらざるを得ないと思います。

[42:57] – アンドルー・ワートキン：しかし、それだけにとどまりません。プラットフォームとベスト・オブ・ブリードの間で、いつも行き来しているのをご存知ですよね？ 今後は再び「ベスト・オブ・ブリード」へと回帰していくと思います。というのも、特にMCPのような技術のおかげで、異なる製品間の相互運用性の課題は以前よりはるかに簡単に解決できるようになったからです。もはやITSMシステムとの特定の統合機能は必要ないと思います。なぜなら、すべてのITSMシステムがMCPと連携できる機能を備えているからです。

[43:43] – アンドルー・ワートキン：そう考えると、プラットフォームとベスト・オブ・ブリードのどちらを選ぶかという判断が容易になります。 ですから、特定の分野では、プラットフォームにできるだけ多くの機能を詰め込むことだけを目標としていた企業にとっては、大きな打撃となるでしょう。これまで、そうした企業に太刀打ちできる者など誰もいませんでした。しかし、状況は変わろうとしています。そして私は……この話題について詳しく話すべきでしょうか？

[44:05] – ジョン・バーク：そうですね。

[44:05] – アンドルー・ワートキン：60秒……いや、30秒版で説明します。

[44:10] – スコット・ロボーン：30秒ですね。ええ。

[44:10] – アンドルー・ワートキン：そうですね。かつては、大規模で扱いにくい中央集権型システム――例えば巨大なERPシステムなど、誰も変更できないようなもの――の世界では、企業は決算報告で「今四半期の業績が未達だったのは、この巨大な社内システムのアップグレードが失敗したためだ」と説明することがよくありました。

[44:29] – ジョン・バーク：それほど昔のことじゃないですね。

[44:29] – アンドルー・ワートキン：ええ、それほど昔のことではありません。当初のセールスフォースのマーケティングキャンペーンは、まさに「ソフトウェア不要」や「私たちがお手伝いします」といった、SaaSの素晴らしさを謳ったものでした。

[44:40] – アンドルー・ワートキン：その世界において、こうしたシステムがどのように変革され始めたかというと、使い勝手の良いSaaSベースのシステムを提供する新興企業が次々と登場したからです。 大規模なシステムは依然として「システム・オブ・レコード」としての役割を果たしていましたが、そこにHRや出張管理、購買など、システムのあらゆる分野に向けた「システム・オブ・エンゲージメント」という新しいシステムが登場したのです。そして当然のことながら、その分野の大手企業は、そうしたスタートアップを次から次へと買収していきました。 ある程度までは、買収が行われるかどうかは定かではありません。買収すべき対象が多すぎるからです。多くの企業が、既存のプラットフォームに対して「エンゲージメント・システム」のような価値提案を行い、徐々にユーザーやシステムのエンゲージメントを奪い始めていくことになるでしょう。

[45:28] – アンドルー・ワートキン：そして、それは、人事部門の旅行管理や目標設定、あるいは購買、あるいは大規模な社内システムに対してこうした取り組みを始めた「エンゲージメント・システム」と呼ばれるものよりも、はるかに速いスピードで起こるでしょう。 つまり、既存のプラットフォームのごく一部を、統合の道筋がほぼ整っている状態で、破壊的革新を起こす、あるいは少なくとも改善することがより簡単になったこの世界では、私たちは再び「ベスト・オブ・ブリード」へと回帰することになると思います。

[45:54] – ジョン・バーク：その考え方をさらに突き詰めることも想像できます。私たちのために働くAIだけが、現在のソフトウェアポートフォリオを本当に理解しているのです。なぜなら、新しいサービスが登場し、機能領域Xにおいて、必要な作業の半分を、より良く、より速く、より安くこなせることをAIが認識するからです。 そうなると、その分野には2つの選択肢があり、どの作業をどちらに割り当てるかを管理するのはAIになります。これは、いわばソフトウェアベンダーの冗長アレイのようなアプローチです。私は、AIが私にとって最も重要だと理解している基準――時間の節約、コスト削減、パフォーマンスの向上など――に基づいて、どこが最も適しているかを見極めて、最適な選択を行うだけです。

[46:36] – スコット・ロボーン：そうですね。興味深いですね。

[46:42] – アンドルー・ワートキン：そうですね。最近のテック系展示会、特にネットワーク分野だけでなく、ほぼすべての技術関連分野に行ってみると、AI向けプラットフォームを売り込む企業が次から次へと並んでいるのがわかります。 出自がどこであれ、今やどの企業もマルチベンダー対応のAIプラットフォームを保有しています。そうする理由がないわけがないでしょう？ どの企業もMCPサーバーを持っています。では、企業としてはどうすべきでしょうか？ エージェント運用に複数のプラットフォームを採用するのでしょうか？ 単一のプラットフォームでしょうか？ あるいは、他のエージェントプラットフォーム群を管理する単一のメタエージェントでしょうか？ もしここで間違ったものを選んでしまったらどうなるのか、そしてどれくらいの速さで変更できるのでしょうか？

[47:25] – アンドルー・ワートキン：そして、一見すると――私は自分の働き方とは異なるのでこの部分は理解できませんが――人々は「ああ、彼らは『これ全部、私の代わりに処理できる』と言っていたから、その言葉をそのまま信じる」という安易な偏見を抱きがちです。 結局、このテーマに帰着するんです。面白いことに、先ほど実例を挙げましたが、私はこれまでeBPFのカーネル空間向け高速ロガーを書いたことがなかったのですが、今では書けるようになりました。それでも、まだ書けなかったんです。 私はこれを実験として使ってみました。仕組みはよく理解しているものの、実際にその分野でソフトウェアを書いたことがない領域で、このプロセスに従ったらどうなるか？ そこから何を学べるだろうか？

[48:05] – アンドルー・ワートキン：私が学んだのは、事前にやり方が分からなかったことでも、どれほど迅速に実行できるかということです。先ほど話していたような、基準や終了条件、私が懸念している点などを明確にしておくだけで、機能するものが手に入るのです。 それが当初抱えていた問題を解決する最善の方法かどうかは分かりません。ただ、それが機能し、かつ保守性の高いコードであることは確かです。それどころか、ドキュメントも非常に充実しています。つまり、私が言いたいのは、人々はこうしたことを学び続け、その経験を活かしていく必要があるということです。

[48:48] – アンドルー・ワートキン：この技術を高く評価しているとはいえ、それが私の最大の懸念でもあります。 最悪のミスは、常に誰かが「自分は正しい」と信じ込んだときに始まります。そして、周囲の人々は、その人物に圧倒されすぎたり、スターに魅了されすぎたり、畏敬の念を抱きすぎたり、あるいは単に怠惰すぎて、確実に物事を成し遂げる方法を知っているその人物に疑問を呈することができないのです。その結果、本来なら防げたはずの問題を引き起こす事態になってしまいます。 これはテクノロジーから社会環境、その他あらゆる場面で見られる現象です。集団思考、あるいは……

[49:27] – アンドルー・ワートキン：しかし、そここそが私が専門家たちに頼る理由です。たとえ彼らにとってそれが正しく聞こえたとしても、実際、正しく聞こえれば聞こえるほど、彼らはそれを鵜呑みにしなくなるのです。なぜなら、そこには何か間違いがあるに違いないからです。 それは何なのか？ それは謎です。彼らの多くはエンジニアですから。ですから、私はテクノロジーを高く評価し、活用し、推進し、価値を創出しているとはいえ、その一部についてはどうしても違和感を覚えるのです。

[50:12] – ジョン・バーク：会話を締めくくるのにふさわしい、確固たる警告ですね。

[50:12] – アンドルー・ワートキン：そうですね。

[50:18] – ジョン・バーク：アンドルー、本日はご出演いただきありがとうございました。非常に興味深いお話でした。企業の戦略担当者の方々も、自社のIT部門の今後の方向性を考える上で、深く考えさせられる点がたくさんあったことでしょう。スコット、本日ご出演いただき、本当にありがとうございました。 そして、いつものように、ご覧いただいている皆様、ありがとうございました。