Day 66 手法 1: レッドチェア・テクニック Method 1 :The Red Chair Technique
Day 66 手法 1: レッドチェア・テクニック
攻撃者にテーブルの席を与える。
以前触れた、この視点の取り方を覚えているだろうか。
今日はそれを実装していく。
私が「空の椅子」のアイデアに初めて出会ったのは、ICF PCCコーチングを学び、実践していた時だった。この概念自体は新しいものではない。フリッツ・パールズによって開発されたファシリテーション実践やゲシュタルト療法だ。空の椅子は不在の声を外在化し、暗黙の視点を可視化し、議論可能にするために使われる。
しかし、レッドチェアで私たちが行うことは、根本的に異なる。
これは療法ではない。
それ自体のための内省でもない。
レッドチェアは、セキュリティ設計の道具だ。
その独自性は、体系的な適用にある：
- 定義された交代ルール（誰が、いつ椅子に座るか）
- 構造化された質問フレームワーク（攻撃者のインセンティブと制約に基づく）
- 承認と意思決定プロセスへの明示的な統合（ワークショップやトレーニングセッションではなく）
目的は感情的な洞察ではない。目的は脅威モデリングを具体化することだ。
敵対者に物理的な席をテーブルに与えることで、抽象を排除する。リアルなワークフロー内で、出荷前に、人間のスピードで、意思決定をストレステストすることを強制する。
仕組み
すべての設計レビューで、実際のレッドチェアを部屋に置く。物理的でも仮想的でも。
これが攻撃者の椅子だ。
ルールはシンプル：
- 誰かがレッドチェアに座る。設計について議論するたび。
- その唯一の仕事は攻撃者視点の質問をすること。
- その質問に答えなければならない。承認の前に。
- 席は交代する。全員が順番に攻撃者になる。
ヒエラルキーなし。特別な資格なし。ただ一つの明確な期待は敵対者のように考える。
レッドチェアが問うこと
新しいAPIエンドポイント
- 「すべてのユーザーを列挙したい場合、どうやるか？」
- 「毎秒10,000リクエストを送ったら何が起きる？」
- 「IDパラメータを変更して他のユーザーのデータにアクセスできるか？」
認証
- 「何回ログイン試行したらブロックされる？」
- 「エラーメッセージはアカウントが存在するかどうか漏らすか？」
- 「パスワード変更後もログイン状態を維持できるか？」
ファイルアップロード
- 「画像を装ったPHPシェルをアップロードできるか？」
- 「アップロードされたファイルはどこに保存される？実行できるか？」
- 「サーバーがクラッシュする前の最大ファイルサイズは？」
これはネガティブさではない。これはリテラシーだ。
なぜレッドチェアは機能するのか
心理的：
敵対的思考を可視化し、社会的に正当化する。全員がそれを見る。
実践的：
攻撃シナリオが早期に浮上する、コード前に、修正が安い時に。
文化的：
セキュリティが共有責任になる、部署ではなく、マインドセットに。
経済的：
設計段階で脆弱性を捕捉する。ある研究によれば、修正コストは本番環境より30倍から100倍安く、ミッションクリティカルな障害に直面する複雑なシステムでは、潜在的に数百倍も安い（HackerOne, 2025; Stecklein et al., 2004）。
こんな場面を想像してほしい...
レッドチェアなし
- 開発者: 「PDF出力機能を追加します。」
- マネージャー: 「いいね。タイムラインは？」
- Dev: 「2日。」
- マネージャー: 「承認。」
レッドチェアあり
- 開発者: 「PDF出力機能を追加します。」
- レッドチェア: 「10億行のPDFを出力してサーバーをクラッシュさせることを防ぐものは？」
- 開発者: 「レート制限とファイルサイズガードが必要です。」
- レッドチェア: 「悪意あるデータでレンダリングを壊すことができたら？」
- 開発者: 「入力をサニタイズし、安全なライブラリを使います。」
- レッドチェア: 「他のユーザーのデータを出力することを止めるものは？」
- 開発者 「生成前のアクセスチェック。」
同じ機能。異なる未来。
3つの追加質問。完全に異なるセキュリティ態勢。
定着させる方法
Week 1: 椅子を導入する
一つの設計ミーティングに置く。一人のボランティアを指名する。ルールを説明する。人々に観察させる。
Week 2: 役割を交代させる
毎回のミーティングで、異なる人が椅子に座る。ジュニア開発者。プロダクトマネージャー。QAエンジニア。例外なし。
Week 3: チェックリストを形式化する
シンプルなテンプレートを作る。攻撃者はここで何を試みるか？ すべての設計レビュードキュメントの一部にする。
Week 4: 影響を追跡する
コード前に捕捉されたすべての脆弱性を文書化する。勝利を共有する。節約を定量化する。
Month 2: 必須にする
レッドチェアのサインオフなしでは設計承認なし。Jira、Notion、Confluence等のワークフローツールに組み込む。
ワークショップを超えて存続させる方法
レッドチェアは、パフォーマンスになると形骸化する。自動的になると存続する。
オンボーディングの一部にする。
新入社員を2週目にレッドチェアに座る。彼らは学ぶ。ここでは、攻撃者のように考えなくてはいけない。
レッドチェアの発見を称賛する。
椅子に座った誰かが本当の脅威にフラグを立てたら、公に認識する。敵対的思考を敵対的ではなく、英雄的にする。
リーダーシップを交代させる。
ジュニアチームメンバーにレッドチェアセッションを運営させる。実践を民主化する。セキュリティの流暢さは、全員が教える時に最も速く広がる。
ツールに統合する。
テンプレートに「レッドチェアレビュー」チェックボックスを追加する。設計ドキュメントに必須フィールドにする。摩擦が儀式を生む。儀式が習慣を生む。
AI速度の脅威に耐える方法
AIは攻撃を加速するだけではない。意思決定と結果の間のギャップを加速する。
レッドチェアは問うことで適応する。例えば、
- 「予想負荷の100倍で攻撃されたら何が起きる？」
AIは瞬時に攻撃をスケールできるから。 - 「LLMが入力を作成したら？」
敵対者は今や無限の創造性を持つから。 - 「攻撃者がその仕組みを正確に知っている時、この設計は耐えられるか？」
AIは数秒でシステムをリバースエンジニアリングできるから。
レッドチェアはAI速度を人間の速度で戦わない。人間の先見性でAI速度と戦う。
AIが脆弱性を見つける頃には、既に扉は閉じている。なぜなら誰かがコード出荷前に正しい質問をしたから。
しかし、先見性だけでAIと戦うのではない。AIでAIと戦う。
レッドチェアをAIで安全に増幅する
第一鉄則：サードパーティAIに、社外秘のコードや実データを絶対に送らない。
設計ドキュメントには、ビジネスロジックがある。コードには、アーキテクチャの意思決定がある。APIスキーマは、攻撃面そのものを語ってしまう。
それらを外部AIに渡すのは、レッドチェアが防ぐべき「脆弱性」を、自ら作る行為だ。AIを使う以上、データセキュリティの基本を破ってはならない。これは妥協条件ではない。最優先事項であり、最重要事項だ。
では、守るべきものを漏らさずにAIを使うには？
ミーティング前：AIに地形を偵察させる
実システムをもとに、中身が分からない形にした設計の地形を作る。
削除するのは、次のような情報だ。
- 会社名
- 実際のエンドポイント
- 独自のアルゴリズム
- 内部でしか使わない識別子
- 個人情報
- その他の機密情報
こうして作った汎用的な設計パターンを、LLMに渡してこう尋ねる。
「この認証フローについて、攻撃者ならどんな質問をするか、20個挙げてほしい。」
その中から、最も鋭い問いだけをレッドチェアの場に持ち込む。
AIには、抽象化された例、地形を偵察をさせる。
人間は、その問いを実システムに当てはめて判断する。
役割は明確だ。
AIは視野を広げる。
人間は責任を持って決める。
ミーティング中：ペイロードではなく原則
レッドチェアの問いは、こうだ。
「もし攻撃者がXをしたら？」
ここでAIを使う。ただし、実装を攻撃させるためではない。攻撃の"型"を洗い出すために使う。
問うのは、こういう質問だ。
- 「SQLインジェクションの代表的なバリエーションを5つ挙げて」
- 「パーサーを壊しやすい一般的なUnicodeの落とし穴は？」
- 「認証フローで起こりうるタイミング攻撃には何がある？」
問わない。
- 「このクエリをテストして：SELECT * FROM users WHERE...」
- 「この入力チェックのコードをレビューして」
- 「実際のAPIスキーマを分析して」
AIにやらせるのは、汎用的な攻撃手法を表に出すこと。
判断するのは、人間だ。
AIは、考えうる選択肢の幅を一気に広げる。
人間は、その中から本当に重要なものを選び、設計に反映する。
速く考えるのはAI。
責任を持って決めるのは、人間。
承認後：封じ込められたAI、実コード
設計が承認され、実装分析に進む段階では、使ってよいAIははっきり限定される。
使用するのは、次のいずれかだけだ。
- セルフホスト型のAIモデル
- 厳格なデータ保護と保存場所の保証を持つエンタープライズAI
たとえば
- GitHub Copilot Enterprise（企業向けIP管理）
- AWS CodeWhisperer（データはVPC内に留まる）
- 社内にデプロイしたオンプレミスのコード特化型LLM
重要なのは、コードが組織の外に出ないこと。AIは使う。だが、境界は絶対に越えさせない。高いコンプライアンスが求められる環境では、さらに慎重になる。
AIは、攻撃パターンを学ぶための教材として使う。実際のコードベースそのものの分析には使わない。
AIに任せるのは「知識」。
判断と責任は、常に人間が持つ。
運用モデル
レッドチェアが、問いを投げる。AIが、攻撃パターンを洗い出す。人間が、その教訓を実コードに落とし込む。
これは、人間 対 AI ではない。
人間の判断 × AIのスケール対攻撃者の創造性 × AIの自動化
役割は明確だ。
レッドチェアが、敵対的マインドセットを与える。
AIが、敵対的知識を広げる。
セキュリティ境界が、それらを安全に封じ込める。
その結果、実践はこう変わる。
「SQLインジェクションをテストすべきだ。」結局、何も起こらない。
そこから、「AIが8種類のSQLインジェクションを示した。そのうち、どれが私たちに本当に当てはまる？」
具体的。実行可能。安全。
それが、セキュリティを"語る"ことと、守るべきものを漏らさずに"実証する"ことの違いだ。
認識から、自動性へ
最初、人は少し緊張する。
次に、好奇心が芽生える。
そして、ある日気づく。ミーティングが始まる前に、もう問いが出ている。
会議の前に、AIで攻撃パターンを調べ始める。社外秘のコードではなく、公開例を使って。
それは、意識的な努力ではない。
本能になる。
筋肉記憶になる。
文化になる。
こうして敵対的思考は、ワークショップで「やるもの」ではなく、組織の考え方そのものになる。
なぜなら、
理論は、気づきを生む。
実践は、スキルを育てる。
習慣は、レジリエンスをつくる。
そしてレジリエンスこそが、現実を生き抜く力だ。
明日は、手法2 ― ユースケースと並ぶアビューズケースを見ていく。
すべての機能には、二つの物語がある。
私たちが設計する物語。
そして、攻撃者が対抗して設計する物語。
その両方を描けたとき、設計は、初めて現実に耐え始める。
---
Method 1 :The Red Chair Technique
Remember the principle from earlier discussions about giving attackers a seat at the table?
Today, we make it real.
I first encountered the idea of the empty chair while studying for ICF PCC coaching and giving the workshops. The concept itself is not new. In facilitation practices and Gestalt therapy, developed by Fritz Perls, the empty chair is used to externalize an absent voice, to make implicit perspectives visible and discussable.
But what we're doing with the Red Chair is fundamentally different.
This is not therapy.
This is not introspection for its own sake.
The Red Chair is a security design instrument.
What makes it distinct is its systematic application:
- Defined rotation rules(who sits in the chair, and when)
- A structured question frameworkgrounded in attacker incentives and constraints
- Explicit integration into approval and decision processes--not workshops or training sessions
The purpose is not emotional insight. The purpose is threat modeling made tangible.
By giving the adversary a physical seat at the table, we eliminate abstraction. We force decisions to be stress-tested before they ship, at human speed, inside real workflows.
You cannot defend what you have never tried to break.
How It Works
In every design review, place an actual red chair in the room--physical or virtual.
This is the Attacker's Chair.
The rules are simple:
- Someone sits in the Red Chairevery time you discuss a design.
- Their only job: ask attacker-perspective questions.
- Their questions must be answeredbefore approval.
- The seat rotates--everyone takes turns being the attacker.
No hierarchy. No special qualifications.
Just one clear expectation: think like the adversary.
What the Red Chair Asks
New API endpoint
- "If I wanted to enumerate all users, how would I do it?"
- "What happens when I send 10,000 requests per second?"
- "Can I access other users' data by changing the ID parameter?"
Authentication
- "How many login attempts before I get blocked?"
- "Do error messages leak whether accounts exist?"
- "Can I stay logged in even after a password change?"
File upload
- "Can I upload a PHP shell disguised as an image?"
- "Where are uploaded files stored? Can I execute them?"
- "What's the maximum file size before the server crashes?"
This is not negativity.
This is literacy.
Why the Red Chair Works
Psychological:
It makes adversarial thinking visible and socially legitimate. Well, everyone sees it.
Practical:
Attack scenarios are surfaced early, before code, when fixes are cheap.
Cultural:
Security becomes a shared responsibility, not a department, a mindset.
Economic:
It catches vulnerabilities at the design stage, where research consistently shows fixes are 30 to 100 times cheaper than in production and for complex systems facing mission-critical failures, potentially hundreds of times less expensive (HackerOne, 2025; Stecklein et al., 2004).
Imagine This...
Without Red Chair
- Dev:"We'll add a PDF export feature."
- Manager:"Great. Timeline?"
- Dev:"Two days."
- Manager:"Approved."
With Red Chair
- Dev:"We'll add a PDF export feature."
- Red Chair:"What prevents me from exporting billion-row PDFs and crashing your servers?"
- Dev:"We need rate limits and file size guards."
- Red Chair:"What if I craft malicious data to break rendering?"
- Dev:"We'll sanitize inputs and use a safe library."
- Red Chair:"What stops me from exporting other users' data?"
- Dev:"Access checks before generation."
Same feature. Different future.
Three extra questions. A completely different security posture.
How to Embed It
Week 1: Introduce the chair
Place it in one design meeting. Assign one volunteer. Explain the rules. Let people observe.
Week 2: Rotate the role
Every meeting, a different person sits in the chair. Junior devs. Product managers. QA engineers. No exceptions.
Week 3: Formalize the checklist
Create a simple template: What would an attacker try here? Make it part of every design review doc.
Week 4: Track impact
Document every vulnerability caught before code. Share the wins. Quantify the savings.
Month 2: Make it non-negotiable
No design approval without Red Chair sign-off. Embed it in your workflow tools-Jira, Notion, Confluence.
How to Make It Outlive the Workshop
The Red Chair disappears when it becomes performative. It survives when it becomes automatic.
Make it part of onboarding.
New hires sit in the Red Chair in their second week. They learn, here, we think like attackers.
Celebrate Red Chair catches.
When someone in the chair flags a real threat, recognize it publicly. Make adversarial thinking heroic, not hostile.
Rotate leadership.
Let junior team members run Red Chair sessions. Democratize the practice. Security fluency spreads fastest when everyone teaches.
Integrate it into tools.
Add a "Red Chair Review" checkbox in your templates. Make it a required field in design docs. Friction creates ritual. Ritual creates habit.
How to Make It Survive AI-Speed Threats
AI doesn't just accelerate attacks. It accelerates the gap between decision and consequence.
The Red Chair adapts by asking:
- "What happens when this gets hit by 100x the expected load?"
Because AI can scale attacks instantly. - "What if an LLM crafts the input?"
Because adversaries now have infinite creativity on tap. - "Can this design survive when the attacker knows exactly how it works?"
Because AI can reverse-engineer systems in seconds.
How to Make It Survive AI-Speed Threats
AI doesn't just accelerate attacks. It accelerates the gap between decision and consequence.
The Red Chair adapts by asking:
- "What happens when this gets hit by 100x the expected load?"
Because AI can scale attacks instantly. - "What if an LLM crafts the input?"
Because adversaries now have infinite creativity on tap. - "Can this design survive when the attacker knows exactly how it works?"
Because AI can reverse-engineer systems in seconds.
The Red Chair doesn't fight AI speed with human speed. It fights AI speed with human foresight. By the time AI finds the vulnerability, you've already closed it because someone asked the right question before the code shipped.
But here's where it gets interesting.
You don't fight AI with foresight alone. You fight AI with AI.
Amplifying the Red Chair with AI securely
Critical first principle:
Never feed proprietary code or real data into third-party AI services.
Design documents contain business logic.
Code contains architectural decisions.
API schemas reveal your attack surface.
Sending these to external AI systems creates exactly the vulnerability the Red Chair is meant to prevent.
So how do you use AI without leaking what you're protecting?
Before the meeting: let AI scout the terrain
Create sanitized design patterns derived from your real systems.
Strip out:
- Company names
- Real endpoints
- Proprietary algorithms
- Internal identifiers
Feed these generic patterns into an LLM and ask:
"Generate 20 attacker questions for this authentication flow."
Bring the strongest questions into the Red Chair session.
Let AI do reconnaissance on abstracted examples.
Let humans apply judgment to real systems.
During the meeting: principles, not payloads
When the Red Chair asks: "What if an attacker does X?"
Use AI to generate attack patterns in principle, never against your actual implementation.
Ask:
- "Generate five SQL injection variants."
- "What Unicode edge cases commonly break parsers?"
- "What timing attacks apply to authentication flows?"
Don't ask:
- "Test this query: SELECT * FROM users WHERE..."
- "Review this validation function."
- "Analyze our actual API schema."
Watch AI surface generic exploit techniques. Now apply human judgment to your specific architecture. AI expands the option space. Humans decide what actually matters.
After approval: contained AI, real code
Once you move into implementation analysis, use:
- Self-hosted models, or
- Enterprise AI with strict data residency guarantees
Examples:
- GitHub Copilot Enterprise (enterprise IP controls)
- AWS CodeWhisperer (data stays in your VPC)
- On-premise models (Code-focused LLMs deployed internally)
For high-compliance environments: Use AI to train teams on attack patterns not to analyze the live codebase itself.
The operating model:
The Red Chair asks the questions.
AI stress-tests the patterns.
Humans apply the lessons to real code.
This isn't human versus AI.
It's:
Human judgment + AI scale
versus
Attacker creativity + AI automation
The Red Chair provides the adversarial mindset. AI provides the adversarial knowledge base. Your security boundary provides containment.
The practice shifts from:
"We should probably test for SQL injection." (which never happens)
To:
"AI just showed us eight SQL injection variants. Which three actually apply?"
Specific. Actionable. Safe.
That's the difference between talking about security and demonstrating it without leaking what you're protecting.
From Awareness to Automaticity
At first, people are nervous.
Then they get curious.
Then, without even realizing it, they start asking these questions before the meeting.
They start researching attack patterns with AI before sitting in the Red Chair using public examples, not proprietary code.
It becomes instinct.
It becomes muscle memory.
It becomes culture.
That's how adversarial thinking stops being a workshop and starts being the way your organization thinks.
Because theory sparks awareness.
Practice creates skill.
Habit creates resilience.
And resilience is how we survive reality.
Tomorrow, we will look at Method 2: Abuse Cases Alongside Use Cases.
Because every feature has two stories:
The one we design for...
And the one attackers design against.
References will be added at the end of the series.
参考文献・出典は、このシリーズの最後に一覧としてまとめます。