世界を動かす技術を、日本語で。
この赤対青のチームは、専門的な利用におけるLLMの能力や現在の活用法を理解するのにいい方法だね。テストは通常安価だから、ほぼ無差別に追加してくれるのを信頼してる。もし間違ってたら、簡単に削除したり修正したりできるし、正しければ価値を加えるからね。でも、しばしばコア機能のテストはしてくれない。最高のテストは自分で書かなきゃならないことが多い。バグを直したり機能を追加したりするのはもっと難しい。LLMはチートしたり、実際の問題を解決せずにテストを通過するための特別なコードパスを書いたりするからね。
テストは通常安価だから、ほぼ無差別に追加してくれるのを信頼してる。レガシーコードベースで働いた経験から言うと、これは非常に間違っていて有害だよ。テストはコードよりも真実の源なんだから、間違ったテストは間違ったコードよりもさらに有害だよ。レガシーコードベースで働いた経験から、一番難しい問題の一つは「なぜこの壊れたテストがここにあって、私たちがサポートしていない動作をテストしているのか」を判断することなんだ。バグがあるのか？それとも悪いテストなのか？逆に、実際には気にしないシナリオのテストがあると、そのテストが意味があるのか、単に「書かれたコードをテストしているから追加されたのか」を判断するのは不可能だよ。
俺は全く逆の考えだな。テストは自分のもので、しっかり理解しておきたいから、俺が真の審判になって、LLMにコードを自由にいじらせられるようにしたいんだ。もしテストがAI製だったら、エージェントに他のコードベースを触らせるのが不安になる。
Rustコードのテストを生成するためにLLMを試してみたんだけど、役に立つどころか害が多かった。確かにたくさんのテストはあったけど、重要なカバレッジが欠けてて、生成されたコードの量のせいで何が抜けてるのか見えにくかった。将来的にコードの挙動を変えるには、手動で書いたテストの数行を直すよりも、たくさんのテストを修正しなきゃいけないんだ。
「誰もテストをテストしないから、テストは自明に正しいに違いない」という言い回しがあるよね。それで、アレンジ・アクト・アサートパターンが生まれたんだ。最近のお気に入りのユニットテストは、既知の入力-出力ペアを保存して、それに対してコードを検証するやつ。コーナーケースをテストするのが簡単で、出力が期待通りに動くか確認できるんだ。
大きなポイントは分かるけど、ここでの情報セキュリティの枠組みは変だね。防御の努力が最も弱い部分の強さに依存するっていうのは、素朴で危険な見方だよ。そんな風にセキュリティプログラムを構築してたら、負けるよ。複数の防御層を持つことが大事なんだ。なぜなら、どんな単一の層でも100%の安全を一貫して得ることはできないから。人はミスをするし、知らないシステムもあるしね。その点では、攻撃側と防御側はそれほど違わない。主な違いは、多くの攻撃者は自分のミスの結果から守られているのに対し、企業の防御者はそうじゃないことだね。でも、君たちは自分のホームグラウンドで戦っているというアドバンテージもあるし、攻撃者は比較的暗闇の中にいるからね。それを無駄にしたら... うん、厳しくなるよ。
私は全然セキュリティの専門家じゃないけど、このコメントは聞いたことのあるベストプラクティスに反してる気がする。例えば、最良の防御はオープンソースでよくテストされたプロトコルを使い、攻撃面を極小化することだよね。ここで何を理解していないのか、ちょっと気になるな。
攻撃って防御の別の層じゃないの？言うじゃん、最良の防御は良い攻撃だって。
うーん、彼の例（ロックされたドア＋開いた窓）は理解できるし、攻撃者がジャックポットに到達するために通過しなきゃいけない複数の層の概念も当てはまると思う。でも、ドアと窓は同じ層にあって、そこで最も弱いリンクがチェーンの強さを完全に定義するんだ。ウェブの世界での似たような例を挙げると、メインのログインエンドポイントは非常にしっかり保護されていて、監査もされていて、強力な認証方法だけを使っているのに、/v1/legacy/external_backoffice エンドポイントが完全にオープンで認証なしで、同じプロダクションLAN内の忘れられたマシンにアクセスできる状態だと、それが最も弱いリンクになるよね。そしたら、そのマシンにアクセスした攻撃者を抑えるための他の内部層があるかもしれないけど、それが「複数の防御層」のポイントになるんだ。
これはただの不適切なアナロジーだと思う。読んでみると、「最も弱いリンク」はシステムに侵入する最も簡単な道だと理解したけど、それが複数の層を突破しなきゃならないなら、難しくなるよね。でも、君の言う通り、それは曖昧で、単一の層の脆弱性として解釈される可能性もあるね。
「防御の努力は最も弱いリンクと同じ強さしかない」というのは、素朴で危険な見解だ。まあ、正直言うと、君は投稿にはない言葉を追加したけどね。> 「ブルーチームの出力は、最も弱いリンクと同じ強さしかない。強い要素と弱い要素からなるセキュリティシステムは、結局不安定になる（しかも、強い要素が偽の安心感を与えることもある）。」君は「防御の努力」を追加したけど、それは記事の主張を無効にするものじゃないし、むしろそれを基にしている。テレンスが言ってることは真実で、事実として正しい。セキュリティの黄金律だよ。だからこそ、君の「努力」は、異なる方法や戦略、対策を重ねることに集中すべきなんだ。層を重ねていくことで、一つの弱いリンクが壊れても、他のものが損害を検知したり、制限したり、修正したりすることができる。だけど、実際には、最も弱いリンクが「内部」になることが多いのも事実。最近の例で言うと、顧客のパスワードをチェックなしでリセットしてしまったコグニザントのデスクの人たちの話がある。顧客は「適切なセキュリティ」を持っていて、VPNや2FAも使ってた。でも、リカバリーメカニズムは、最も弱いリンクであるヘルプデスクにアウトソースされてしまった。攻撃者は（おそらく）電話をかけて、認証情報を求めてそれを手に入れた。それが最も弱いリンクで、壊れてしまった。彼らの苦情によれば、攻撃者は内部システムにアクセスし、十分なデータを集めて再びヘルプデスクに電話し、「ITセキュリティ」アカウントの2FAをリセットした（最初のものとは別）。それも成功したらしい。彼らは攻撃者を3時間で検知してアクセスを停止したと言ってるけど、それは「検知と緩和」であって「防止」じゃない。攻撃者はすでに内部にいて、システムを漁ってたんだ。VPNや2FAがあったことで「偽の安心感」を与えられていたけど、最も弱いリンクは「アカウント回復」だった。（テレンスは正しい）。内部にもっと層があって、2番目のアカウントアクセスを検知して約3時間後にそれを排除したのは、君が言ってること（そして君は正しい）で、深層防御も機能するってことだ。だから、両方とも正しい。最近の情報セキュリティの世界は、「防止」を売るのから「緩和」を促進する方向に移ってきた。なぜなら、単純に防げないことがあるってことが明らかになったから。だから、リスクを緩和すること、表面を制限すること、信頼を低くすること、すべてを儚いものとして扱うことに集中するんだ。
私の理解では、これがRSAアルゴリズムの作り方なんだ。今、サイモン・シンの「The Code Book」がどこにあるか分からないけど、確かリベストとシャミールがアイデアを出して、アドレマンの主な役割はセキュリティの欠陥を見つけることだったと思う。あ、ウィキペディアのページに載ってるね：https://en.wikipedia.org/wiki/RSA_cryptosystem 数学の青チーム/赤チーム、やったね！
知ってる認知科学者のペアを思い出すな。彼らはよくコラボするんだけど、一人は広がりがあって冗長で、しばしば脱線することが多い。もう一人は非常に論理的で正確。彼らの論文の作り方は、最初に一人が書いて、もう一人が削除するって感じ。
小さいコンテキストサイズだけど、その中でめちゃくちゃ推論が得意なLLMがあるとするよね。そういうLLMは、巨大なコンテキストを持ってるけど、推論がちょっと弱いLLMとは違うタスクに役立つと思う。LLMのトレーニングや推論のどの側面も、あるタスクには向いてるけど、別のタスクには向いてないっていうトレードオフがあるんだよね。例えば、10msで結果を返すような強く量子化されたモデルが、200msかかるモデルよりも役立つ場合もあるかもしれない。
形式的な証明はどうなの？LLMがもっと「ブルーチーム」の役割で助けてくれることを期待してない？例えば、数学者が「技術的証明」について話すとき、何千ものケースを列挙するけど、俺の印象では、LLMが時間を節約して、数学者が実際に難しい部分（面倒な部分ではなく）に集中できるように助けてくれると思う。
形式的な検証やケースの自動化は、数学者が各ケースを手でチェックしなくても自動でできるよ。LLM以前の古い例として、四色定理を見てみて。
サイバーセキュリティでは、レッドチームとブルーチームは対等な力だと思う。ソフトウェア開発では、そのアナロジーはちょっと無理があると思うけど、コーディングとテストは対等な力じゃない。テストもコードだし、バグもある。テストはポリスパラドックスにぶつかる。「警察を監視するのは誰か？」警察が警察を監視するんだ。
「警察、警察、警察、警察、警察、警察、警察。」
ブルーチームは望ましい製品を作るために明らかに必要だが、レッドチームも同様に重要で、セキュリティのないシステムを展開することで生じる損害を考えると。 > AIツールの提案された多くの使用例は、コードを作成するなど、こうしたツールを「ブルーチーム」カテゴリに置こうとする。 > しかし、こうしたツールの信頼性や不透明性を考えると、ブルーチームの人間の専門家の出力を直接置き換えるのではなく、レッドチームでその出力を批評する方が良いかもしれない。... レッドチームは、利益を増やすためにリスクを取ることを躊躇う臆病者にとってだけ必要だ。テストやセキュリティをするのは面倒だから、四半期のボーナスを増やすためにそれをやらない方がいいじゃん？テレンス・タオの経験は、リスクを避ける高名な機関に偏っていると思う。人々は、90年代後半からあまり投資されていない業務アプリの上に新しいインターフェースをダクトテープで貼り付けようとしているときに、偉大な数学者の一人に自分の仕事をチェックしてもらおうとは思わないだろう。逆に、新しいネットワークプロトコルやファイルシステムのための最先端のアルゴリズムを書いている人たちは、ランダムなチャットボットからコードをコピペして、できるだけ早く安くコードを出そうとはしていないことを願う。プログラマーの給料を切り詰めて、目に見えない技術的負債を分単位で積み上げている人たちがたくさんいる。彼らは、欠けているレッドチームを作るためにAIツールを追加しようとしているんじゃなくて、持っている唯一のチームであるブルーチーム（実際には一人の過労のIT担当者）を減らそうとしているんだ。
タオはシステムについて話してるんだよね。システムは自己持続的な動的ネットワークで、個々のアクターや組織が誰であっても独立して機能するんだ。青チームのシステムの中心にある独占を壊しても（アメリカがスタンダードオイルやAT&Tでやったみたいに）、世代を超えて合併を通じて再形成されるだけなんだよね（実際、エクソン・モービルやベライゾンでそうなってる）。関わってる人を全員解雇したり殺したりしても、同じ役割を果たす他の人が入ってくるだけ。詳細は変わるかもしれないけど、全体のダイナミクスは同じまま。ここで、君が言ってることをしてる会社は、実は赤チームそのものなんだ。彼らは信頼性がなくて、追加的で、エコシステムの中で使い捨て可能なプレイヤーなんだよ。青チームはインセンティブによって青チームになってる。彼らは、役割が正しく機能するためには、すべての部分が信頼できてうまく連携する必要がある組織で、もしその役割を果たす個々の人がその資質を持っていなければ、失敗して、そういう資質を持った人に置き換えられるんだ。
今日のコーディングフローは、LLMにコードを生成させる（青チーム）ことが多くて、その後に僕がコードレビューして書き直してスケーラブルにする（赤チーム？）。このアナロジーは崩れるけど、僕が安全性と正確性を提供してるからね。LLMはスタート地点を提供してくれる。AIを使ったインフラやモニタリングツールには期待してる。理解できない長いシステムログがあるとき、LLMはすごく助けてくれる。でも、最終的な分析をして、次のデバッグが時間の良い使い方になるようにするのは僕の仕事なんだ。だから、この場合も赤チーム/青チームとは言えないかな。
このアナロジーは安全性や正確性についてじゃなくて、誰が生産して、誰が評価・分析・突っついてるかについてなんだよね。
メタだけど、ウェブサイトのフォントって他の人には読みづらい？僕には線が区別しにくくて、全体がちょっとぼやけて見えるんだ。開発ツールを開いて、フォントをOSのフォントの一つに戻さなきゃいけなかった。
なんでこの記事がLLMとタオの哲学的概念についてだと思ったのか、よくわからないな。