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] – スコット・ロボーン：あなたの主張には、私も強く共感していますよね？ 実は、私が担っているもう一つの役割として、「ネットワーク・オートメーション・フォーラム」という組織の共同創設者という立場があります。そして、今日の収録時点では、ドイツのミュンヘンで開催された前回の会議「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人のメンバーが、AからZまで完全に機能する8つの異なるスクリプトやアプリケーション（何を構築するにせよ）を次々と作り上げるよりも、時間がかかりそうにも聞こえます。 ですから、正しいスタートを切り、これをいかに持続可能なものにするか、人間がどの段階でプロセスに関与し、どの段階でその関与が不可欠なのか、そしてこれを安全に行うためにどのような実践を取り入れるかを考えることが、これまで以上に重要になっているでしょう。

[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] – アンドルー・ワートキン：しかし、あなたがする必要のないこと、そしてこれは過去6ヶ月という信じられないほど短い期間で、ツールとプロセスの両面で本当に成熟してきたと思うのは、具体的に何を納品すべきかについて4ページものプロンプトを書き始めることです。 もし、フロンティアモデルではなく、より安価でランニングコスト重視のモデルを使用している場合はそうする必要がありますが、その場合でも、フロンティアモデルにランニングコスト重視モデルの仕様書を作成させればよいのです。プロンプトの生成に関しては、LLMほど上手にはなれないでしょう？

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

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

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

[16:50] – アンドルー・ワートキン：そうですね。そして、ここで何が起こるのか、そしてなぜプロセスがこれほど重要なのかを説明します。人々は座って、LLMと認識が一致していると思い込み、数週間はそれが正しいように見えます。一見、LLMは情報を記憶しているように見えるのです。 ところが7日目に新しいセッションを始めると、これまで知っていたことをすべて忘れてしまったかのように見え、その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] – Andrew Wertkin: 特にブラウンフィールド環境においては、「よし、 『意図を伝えるだけで、スクリプトが自動生成され、作業が完了し、二度と確認する必要はない』という考え方と、実際にエンタープライズネットワークでそれを実現することの間には、依然として少なからず隔たりがあると思います。現時点では、それを実現するためのツールがすべて揃っているわけではないからです。 現時点では、それを実現するための予算が必ずしも確保できていない。さらに、過去の経緯があり、その中には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] – アンドルー・ワートキン：ちょっとしたエピソードです。 何年も前、私はアプリケーションライフサイクル管理分野の企業の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] – Andrew Wertkin: しかし、私たちが提供するもののうちの一部は、単に 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] – アンドルー・ワートキン：ええ、それほど昔のことではありませんね。当初、Salesforceのマーケティングキャンペーンは、「ソフトウェア不要」や「私たちがすべて用意します」といった、SaaSの素晴らしさを謳う内容ばかりでした。

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

[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部門の今後の方向性を考える上で、深く検討すべき点が数多くありました。スコット、本日ご出演いただき、本当にありがとうございました。 そして、いつも通り、ご覧いただいている皆様にも感謝申し上げます。