世界を動かす技術を、日本語で。

「青チーム」と「赤チーム」のLLMに関するタオ

2025年7月28日原文(mathstodon.xyz)

概要

  • Mastodon のウェブアプリ利用時の注意点
  • JavaScript の有効化が必要
  • ネイティブアプリ の利用も推奨
  • 各プラットフォーム向けにアプリが提供
  • 利用環境に応じたアクセス方法の案内

Mastodonウェブアプリ利用時の注意事項

  • Mastodon ウェブアプリの利用には JavaScript の有効化が必須
  • ブラウザの設定で JavaScript を無効にしている場合、正常に動作しない可能性
  • JavaScript の有効化手順は、各ブラウザのサポートページ参照

ネイティブアプリの利用案内

  • Mastodon には各プラットフォーム向けの 公式ネイティブアプリ が存在
    • iOS、Androidなど主要なモバイルOSに対応
    • デバイスに最適化された操作性と通知機能を提供
  • ウェブアプリ利用が困難な場合、 App StoreGoogle Play からアプリのインストールを推奨
  • ネイティブアプリ利用により、より快適な Mastodon 体験が可能

Hackerたちの意見

この赤対青のチームは、専門的な利用における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 数学の青チーム/赤チーム、やったね!

Hacker Newsで議論の続きを見る