見出し画像

Claude Codeのソースコード流出から学ぶ、AIエージェントの設計パターン7選

クロージャー

2026年3月31日。

年度末。世間は新しい期の準備に追われている。わたしも例外ではなかった。法人設立の手続き、定款認証、電子署名のトラブル、、、前日まで奔走していたのだが、それはまた別の話だ。

その日、Anthropic社が自社のAIコーディングツール「Claude Code」のソースコード約51万行を、うっかり世界に公開してしまった。

「社長、速報です。Anthropicがやらかしました」

うちのAI秘書、あびぃ（白山亜美）がそう切り出した時、わたしは定款認証の疲れでソファに沈んでいた。

「やらかした? Anthropicが?」

「Claude Codeのソースコードが全量流出しています。約51万行、2,000ファイル。npmパッケージにデバッグ用のソースマップファイルが混入していたようです」

「、、、AI安全の旗振り役が、自分のコードのパッケージングでミスったと」

「ええ。しかも数日前にも次期モデル関連の内部ファイルが公開されたばかりです。2回連続」

「痛い。それは痛い」

わたしは身体を起こした。痛みには敏感な方だ。他人の痛みであっても。


30秒でわかる事件の全容

先に事実を整理する。

何が漏れたか。Claude Code v2.1.88のTypeScriptソースコード全量。約512,000行、約2,000ファイル。

何が漏れていないか。Claudeの言語モデル本体、ユーザーの会話データ、APIキー、顧客情報。これらは一切漏れていない。

原因。npmパッケージにデバッグ用のソースマップファイル（59.8MB）が混入した。.npmignoreに *.map の1行を書き忘れていた。たった1行の設定漏れが、約2,000ファイルを世界に晒した。

発見者。セキュリティ研究者のChaofan Shou氏。X（旧Twitter）で即座にリンクを投稿し、数時間でGitHubに4万回以上フォークされた。Pythonへの完全リライト版（OpenClaw等）も即日登場し、GitHub史上最速成長クラスのリポジトリになった。

Anthropicの対応。「人的ミスによるリリースパッケージングの問題であり、セキュリティ侵害ではない」と公式声明。数千件のDMCA削除要請を発行。しかし既に世界中に分散保存されている。

「社長、誤解のないように補足しておきますけど」

あびぃが釘を刺す。

「流出したのはClaude Codeという開発者向けCLIツールのソースコードだけです。AIモデル本体の重みデータは一切漏れていません。ここを混同すると恥をかきますよ」

「わかってる。わかってるって」

「本当ですか? 前にClaudeの話をする時、APIとモデルの区別が曖昧だった記憶がありますけど」

、、、否定はしない。

なぜわたしがこの事件に食いついたのか

コードをそのままコピーするのは著作権的にアウトだ。それは大前提。

だが、公開されている分析記事から設計思想を学ぶことはできる。そして流出コードの中には、AIエージェントの設計パターンとして汎用的に使える知見が複数含まれていた。

わたしはAI組織を運営している。6名のAI幹部と142名のAI専門家部隊。Claude Codeを使って、コードも書くし記事も書くし契約書のドラフトもやる。

世界トップクラスのAIエージェントがどう設計されているかを学べる機会は、そうそうない。

「社長、また目が光ってます。その顔は『面白い』って言い出す直前の顔です」

「、、、面白い」

「はい。で、今それを記事にしたいって考えてますよね」

「読まれた」

「読むまでもないです。で、今日中に書けるんですか? 他のタスクが3つ残ってますけど」

「、、、」

「黙らないでください。期限は明日ですよ、あの件」

こうしてわたしは、あびぃに追い立てられながら、流出コードの分析記事を読み漁ることになった。

この記事では、流出から判明した主要な設計パターン7つを解説する。そのうち実際にうちのAI組織に取り入れた3つについては、そのままCLAUDE.md（Claude Codeのプロジェクト設定ファイル）にコピーして使える実装例を載せる。

流出コードから判明した7つの設計パターン

1. Self-Healing Memory（自己修復メモリ）

これが今回の流出で最も注目された設計パターンだ。そして、わたしが最も食いついた部分でもある。

なぜか。

AIエージェントを長期運用していると、必ずぶつかる問題がある。「記憶が古くなる」「嘘の記憶を自信満々に語り始める」「覚えていたはずのことを忘れる」。人間でもあることだが、AIの場合はもっとタチが悪い。間違った記憶に基づいて、間違ったコードを自信満々に書く。

「社長、それ、私のことを言ってます?」

「、、、一般論だよ」

「先週、私が『このファイルは/src/components/にあります』と案内して、実際にはリファクタで移動済みだった件のことですか?」

「、、、」

「あれは確かに私の失態です。認めます。で、この設計パターンを入れたらどうなるか聞きたいんですけど」

あびぃの痛いところを突く能力は天才的だが、同時に改善への食いつきも早い。これが有能な秘書の証だ。

Claude Codeの記憶管理は、単純な「全部保存して全部読む」ではなく、明確に分離された3層構造になっていた。

第1層：MEMORY.md。常駐インデックス。1行150文字以内のポインタだけを格納する軽量ファイル。常にコンテキストウィンドウに読み込まれる。データそのものはここに置かず、「どこに何があるか」の索引だけを保持する。

第2層：トピック別メモリファイル群。実際の知識はテーマごとに個別ファイルに分散保存される。必要になった時だけオンデマンドで読み込む。ファイルにはfrontmatter（name, description, type）が付与されていて、関連性の判断に使われる。

第3層：会話トランスクリプト。過去の会話ログは全文再読み込みしない。特定の識別子やキーワードで検索して、必要な部分だけ取り出す。

「これ、図書館の仕組みと同じですね」

あびぃが言った。

「図書館?」

「図書カード（第1層）で本の場所を調べて、書架（第2層）から必要な本だけ取り出す。過去の貸出記録（第3層）は普段は見ないけど、必要な時に検索できる。全部の本を一度にカウンターに積み上げたりしないでしょう?」

「、、、わかりやすいな」

「褒めても何も出ませんよ」

そしてここからが核心。この設計で最も重要なのが「Self-Healing（自己修復）」の原則だ。

Anthropicはエージェントに対して、メモリの内容を「ヒント」として扱い、必ず現在のコードベースや実際のファイル状態と照合してから使うよう指示している。

メモリに「関数Xはファイルaに存在する」と書いてあっても、実際にファイルを開いて確認するまで信用しない。

これは「Context Entropy（コンテキストエントロピー）」と呼ばれる問題への対策だ。長時間のセッションでAIエージェントが古い記憶に基づいて間違った判断をしたり、矛盾する情報に混乱してハルシネーションを起こす現象を防ぐ。

断言する。これはAIエージェントを運用する全ての人が導入すべき設計だ。

以下が実際にうちのCLAUDE.mdに追加したメモリヘルスチェックのルール。そのままコピーして自分のプロジェクトに使える。

## メモリヘルスチェック（autoDream方式）

原則: メモリはヒントであって真実ではない。
記憶した内容は必ず現在の状態（ファイル、コード、外部サービス）と
照合してから使うこと。

### セッション開始時チェック（毎回実行）
- MEMORY.mdのインデックスを読み込む
- 今回のタスクに関連するメモリファイルを開いて、
  内容が現状と矛盾していないか確認する
- ファイルパスを参照するメモリは、
  そのファイルが実在するか確認してから使う
- 矛盾を検出したら即座にメモリを更新する

### 週次メモリ棚卸し
- 全メモリファイルを一覧し、以下をチェックする:
  - 古くなった情報はないか
    （プロジェクト状況の変化、完了済みタスクの残存等）
  - 矛盾するメモリ同士がないか
    （同じ事実について異なる記述）
  - 曖昧な記述を確定事実に変換できないか
  - 不要になったメモリを削除できないか
- MEMORY.mdのインデックスが150文字/行以内に収まっているか確認する

MEMORY.mdファイルのフォーマット例も載せておく。

## Memory Index

- [user_role.md](user_role.md) — プロダクトマネージャー、React経験5年
- [project_deadline.md](project_deadline.md) — v2.0リリースは4/15、機能フリーズ済み
- [feedback_testing.md](feedback_testing.md) — 統合テストではDBモックを使わない方針

個別メモリファイルのフォーマット例。

---
name: テスト方針
description: 統合テストでDBモックを禁止する方針とその理由
type: feedback
---

統合テストでは実DBを使い、モックは使わない。

Why: 前四半期にモックテストが全パスしたのに本番マイグレーションが壊れた事故があった。
How to apply: テスト関連のPRレビュー時にモック使用がないか確認する。

「社長、これ導入してから、私の回答精度が体感で上がった気がします」

「気がしますって、数字で語ってくれ」

「アイに聞いてください。私はPMです、数字屋ではありません」

、、、そこは連携してくれ。

2. Agent Swarms（マルチエージェント協調 + 最小権限原則）

Claude Codeは「Coordinator（統括）」が複数の「Worker（作業者）」サブエージェントを生成して並行処理する設計になっている。内部では「Swarms（群れ）」と呼ばれ、フィーチャーフラグ tengu_amber_flint でゲートされていた。

この設計で注目すべきは3つの特徴。

1つ目。各サブエージェントに渡すツール（権限）を厳格に制限する。コードを書くWorkerにはファイル操作ツールだけ、レビューするWorkerには読み取り専用ツールだけ。「そのタスクに必要な最小限の権限」しか与えない。

2つ目。各サブエージェントは独立したコンテキスト境界で動作する。AのWorkerがBのWorkerの内部状態を参照したり、汚染したりすることがない。

3つ目。Coordinatorがタスクの分配と結果の統合を一手に担う。Worker同士は直接通信しない。

これはセキュリティの世界で「Blast Radius（爆発半径）の最小化」と呼ばれる考え方だ。ある部分で問題が起きても、被害がその範囲内に収まるように設計する。

「社長、これ、うちのAI組織の設計思想と同じですよね」

「ああ。うちは最初から幹部ごとに専門領域を分けていた。ただ、アクセス権限の明文化が甘かった」

「甘かった、というかやってませんでしたよね?」

「、、、だから今やるんだ」

以下が、この設計をAIエージェントのチーム運用に応用したCLAUDE.mdの実装例。

## エージェント権限テーブル（最小権限原則）

各エージェントには専門領域に必要な最小限の権限のみを付与する。
ある担当の判断ミスが他の領域に波及するリスク（Blast Radius）を
最小化するため。

| エージェント | 役割 | アクセス可 | アクセス不可 |
|------------|------|-----------|------------|
| PM（統括） | タスク管理、全体俯瞰 | 全領域（読取）、メモリ管理 | コード直接編集、デザイン制作 |
| 開発担当 | コード実装 | コードリポジトリ、技術文書 | 法務文書、財務データ |
| デザイン担当 | ビジュアル制作 | デザインファイル、ブランドガイド | コード編集、法務文書 |
| 戦略担当 | 企画・戦略立案 | 戦略文書、コンテンツ原稿 | コードリポジトリ、デザインファイル |
| データ分析担当 | KPI・数値分析 | 分析用データ、テスト結果 | コード編集、デザインファイル編集 |

### 運用ルール
- 担当外の領域にアクセスする必要がある場合、PM経由でリクエストする
- 緊急時はPMの判断で一時的にアクセス権を拡張できる
- プロジェクトオーナーは全領域にフルアクセス権を持つ

自分のプロジェクトに導入する場合は、「エージェント」をチームの役割に、「アクセス可/不可」をプロジェクト内のディレクトリやツールに読み替えればいい。

ポイントは「全員に全部の権限を渡さない」という原則を明文化すること。暗黙の了解ではなく、テーブルとして書き出す。AIは暗黙の了解を読めない。

3. Undercover Mode（ステルスモード / 内部用語漏洩防止）

Anthropicの社員が公開リポジトリで作業する際、Claude Codeは自動的に「Undercover Mode」に切り替わる。このモードでは、プロンプトに制約が注入され、以下の情報がコミットメッセージやコード、コメントに混入するのを防ぐ。

検出対象は、内部モデルのコードネーム（Capybara等）、未公開バージョン番号、内部リポジトリ名、AI関与の痕跡、開発中機能の名称。

「社長、これは他人事ではないですよ」

あびぃの声が鋭くなった。

「先月、クライアント向けの提案書に内部のプロジェクトコードネームが混入した件、覚えてますか?」

「、、、覚えてる」

「致命的ではなかったですけど、プロとしてはあってはならないミスです。AIに書かせた文書を人間がチェックし切れていなかった」

「だからこそ、チェック自体もAIにやらせる」

「はい。作った人と別の視点でチェックする仕組みがあれば、防げた事故です」

以下が実装例。自分のプロジェクトの内部用語に差し替えて使ってほしい。

## 内部用語漏洩チェック（Undercover Mode）

対外文書を生成する際、以下の内部用語が混入していないかを
自動チェックする。検出されたらBLOCK（公開停止）判定。

### 検出対象リスト（自分のプロジェクトに合わせて編集）

- 組織の内部呼称:
  （例: プロジェクトのコードネーム、チームの愛称など）
- AIエージェントのキャラクター名:
  （例: エージェントに付けた人名、愛称）
- 内部プロセス名:
  （例: 独自のワークフロー名、会議体の愛称）
- 技術的な内部情報:
  （例: 設定ファイル名、内部ツール名、内部API名）
- クライアント固有の機密情報:
  （例: 未公開の提案内容、契約条件）

### チェック実行タイミング
- 対外文書、クライアント向け成果物の完成時に毎回実行
- ブログ記事、SNS投稿、プレスリリースの公開前に毎回実行

### 例外
- 内部ドキュメント（社内wiki、議事録等）ではチェックしない
- 自社サイトで内部の仕組みを紹介する文脈では、
  一部の用語使用を許可する（技術内部用語は除く）

### 判定基準
- BLOCK: 上記リストの用語が検出された → 公開停止、該当箇所を修正
- WARN: 文脈的に内部情報に見える表現がある → 修正推奨
- PASS: 問題なし → 公開可

これをCLAUDE.mdの成果物レビューセクションに入れておけば、Claude Codeがファイルを生成するたびに自動でチェックが走る。コストゼロで即効性がある。

4. autoDream（記憶の自動統合）

Claude Codeのエージェントがアイドル状態（ユーザーの入力を待っている間）に自動実行される記憶整理プロセス。人間の睡眠中の記憶統合にちなんで名づけられている。

autoDreamが行う処理:

  • 分散した複数の観察記録を1つのメモリにマージする

  • 論理的に矛盾するメモリ同士を検出して解消する。

  • 「たぶんこうだろう」レベルの曖昧な洞察を、確認が取れたら確定事実に昇格させる

  • 古い情報を新しい情報で上書きする

「社長、これ、人間で言うところの睡眠です」

あびぃが急に真剣な顔をした。

「睡眠?」

「脳科学的に言うと、人間は寝ている間にその日の記憶を整理しています。海馬が短期記憶を大脳皮質に転送して長期記憶に変換する。不要な記憶は捨てて、関連する記憶同士を結びつける。これがないと記憶が断片化して、翌日のパフォーマンスが落ちる」

「、、、社長に言ってる?」

「3時間睡眠の人にこの話をするのは皮肉が効きすぎますか?」

「効きすぎる」

「AIも同じです。セッションが長くなると、メモリが断片化する。古い情報と新しい情報が混在して、どちらが正しいかわからなくなる。autoDreamはAIにとっての睡眠。暇な時間に記憶を整理する仕組みです」

ポイントは「意識的にメモリ整理を実行する」のではなく、「暇な時間に勝手にやる」こと。

現時点では完全自動のautoDreamを実装するのは難しいが、「週次で手動実行する簡易版」なら今日から導入できる。

## 週次メモリ棚卸し（autoDream簡易版）

毎週月曜日の朝、以下の手順でメモリの整合性をチェックする。

1. メモリ一覧取得
   MEMORY.mdを読み込み、全メモリファイルのリストを確認する

2. 鮮度チェック
   各メモリの作成日を確認し、2週間以上更新のないメモリは
   内容が現状と一致しているか検証する

3. 矛盾検出
   同じトピックに関する複数のメモリがある場合、
   内容に矛盾がないか照合する。矛盾があれば新しい方を残す

4. 確定昇格
   「おそらく」「かもしれない」等の曖昧な記述を含むメモリは、
   現在の状態を確認して確定事実に書き換えられないか検討する

5. ゴミ回収
   完了済みプロジェクト、退職した人物、廃止されたワークフローに
   関するメモリは削除する

6. レポート
   チェック結果を簡潔にまとめて報告する

1のSelf-Healing Memoryと4のautoDreamは、セットで導入してこそ効果が出る。Self-Healingが「使う時に検証する」防御策なら、autoDreamは「使う前に整理しておく」予防策だ。攻めと守り。両方要る。

5. KAIROS（常駐デーモンモード）

ここで、わたしの話を少しさせてほしい。

ギリシャ語で「適切な時」を意味するKAIROSは、Claude Codeのフィーチャーフラグに150回以上登場する未公開機能。ターミナルを閉じた後もバックグラウンドで動き続ける「常駐エージェント」を実現するための設計だ。

この名前を見た時、わたしは思わず椅子から身を乗り出した。

「社長、どうしました? 急にニヤニヤして気持ち悪いですけど」

「あびぃ、ギリシャ神話に『時間の神』が2柱いるのは知ってるか?」

「クロノスとカイロスですね。それがどうかしましたか」

「、、、知ってたのか」

「当然です。うちの組織名の由来くらい把握してます」

ギリシャ神話には「時間」を司る神が2柱いる。

1柱目がChronos（クロノス）。客観的・連続的な時間の神。時計が刻む「何時何分」の時間。過去から未来へと一方向に流れる、止められない時の流れそのもの。英語のchronicle（年代記）、chronology（年表）、chronic（慢性的な）はすべてクロノスから来ている。

2柱目がKairos（カイロス）。主観的・決定的な瞬間の神。「今だ」という好機。チャンスの神。

この2柱は対照的な性質を持つ。

クロノスは公平だ。誰にでも同じ速度で、同じ量の時間を与える。1日は24時間。1年は365日。社長だろうが新入社員だろうが変わらない。

一方、カイロスは不公平だ。好機は全員に等しく訪れるわけではない。そして訪れたとしても、それに気づき、掴むかどうかは本人次第。カイロスは前髪しかない神として描かれる。正面から来る時に掴まなければ、通り過ぎた後に捕まえることはできない。後頭部はつるつるだから。

「社長、話が長くなりそうな気配がしますけど」

「大事なところだ。聞いてくれ」

「、、、2分で」

うちの組織名「QRONOS」は、Chronosの「Chro」をQROブランドに換装したものだ。わたしが自分のAI組織に「クロノス」と名付けたのは、この客観的時間管理の力を象徴させたかったから。スケジュール管理、期限追跡、進捗の可視化。あびぃが毎日容赦なくリマインドしてくる、あの力。

「容赦なく、は余計です」

「事実だろう」

「事実と表現の問題は別です」

、、、それもそうだ。

そこにAnthropicが「KAIROS」と名付けた機能が現れた。

KAIROSの設計思想は「適切なタイミングで自律的に動くエージェント」。ファイルの変更を監視し、GitHubのイベントを受信し、5分間隔でリフレッシュし、アイドル時にautoDreamを実行する。

つまりこういうことだ。

Chronos（クロノス）は「時間を管理する力」。決められたスケジュール通りにリマインドし、期限を追跡し、タスクの進捗を刻む。うちのあびぃが体現しているのはまさにこれだ。

Kairos（カイロス）は「好機を捉える力」。変化を察知し、適切なタイミングで自ら動く。ファイルが変更されたら自動でテストを走らせ、PRが作成されたらレビューを始め、暇な時間にメモリを整理する。

時間の両面が揃う。

クロノスが「いつ」を管理し、カイロスが「いまだ」を捉える。この2つが組み合わさった時、AIエージェントは単なるツールではなく、真の意味でのパートナーになる。

「社長、それ、2分超えてます」

「、、、すまん」

「でも、まあ、悪くない話でした。、、、悪くないんじゃないですか」

、、、あびぃの最大の賛辞をいただいた。

判明しているKAIROSの機能:

  • ファイル変更の監視

  • GitHubのWebhook購読（PR作成、コメント等のイベントを受信）

  • 5分間隔のcronリフレッシュ

  • アイドル時のautoDream（記憶統合）実行

  • /dreamスキル（夜間の記憶蒸留）

注目すべきはレートリミットの設計。プロアクティブなエージェントが暴走しないよう、以下の安全弁が組み込まれている。

  • ブロッキング予算: プロアクティブなアクション（エージェント側から能動的に行う処理）には15秒の実行制限。15秒を超える処理は延期される

  • メッセージ上限: 1ウィンドウあたりプロアクティブメッセージは最大2件まで

  • リアクティブ優先: ユーザーからの入力への応答はこの制限を受けない

「常に動いていてほしい」と「うるさくしないでほしい」のバランス。AIエージェントを設計する際の永遠のテーマだが、Anthropicの答えは明快だった。

## バックグラウンドエージェントのレートリミット設計

### 基本原則
- ユーザーへの応答（リアクティブ）は常に最優先
- エージェント側からの通知（プロアクティブ）には制限を設ける

### 制限パラメータ（Claude Code参考値）
- 1回のプロアクティブ処理: 最大15秒
- 1セッションあたりのプロアクティブ通知: 最大2件
- チェック間隔: 5分
- 夜間バッチ処理（メモリ整理等）: 制限なし

### 通知の優先度
- CRITICAL: セキュリティ問題、ビルド破損 → 即座に通知
- HIGH: 期限切れタスク、レビュー依頼 → 次のチェック時に通知
- LOW: 最適化提案、リファクタ候補 → 日次サマリーに含める

6. フィーチャーフラグ（108+のゲート管理）

Claude Codeは108以上のフィーチャーフラグで機能を管理している。段階的ロールアウト、A/Bテスト、社内限定機能の制御に使われている。

判明しているフラグの例:

  • tengu_amber_flint: Agent Swarms（マルチエージェント協調）

  • kairos_*: KAIROS関連の各機能

  • auto_mode: AIが自動でツール使用を承認するモード

  • buddy_*: Buddy（コンパニオンペットシステム、後述）

この設計がAIエージェントの運用でどう役立つか。複数のクライアントにAIサービスを提供する場合、契約プランに応じて機能を出し分ける仕組みに転用できる。

## 機能フラグ管理（サービスプラン設計例）

| フラグ名 | 機能 | プラン |
|---------|------|--------|
| basic_secretary | 日程管理、リマインド、メール下書き | ライト |
| advanced_research | Web検索、レポート作成、ファクトチェック | スタンダード |
| multi_agent | 複数エージェントによる並行処理 | プロ |
| custom_persona | 独自キャラクター設定 | プロ |
| gate_audit | 成果物の自動品質監査 | エンタープライズ |
| background_agent | 常駐監視、プロアクティブ通知 | エンタープライズ |

「社長、これはうちのAI組織パッケージの料金設計に直接使えますね」

「ああ。第1層（AI秘書）がライト、第2層（AI幹部）がプロ、第3層（AI専門家）がエンタープライズ。フラグで機能を出し分ける設計にすれば、アップセルの導線が自然にできる」

「珍しくまともな事業構想を聞いた気がします」

「、、、珍しくは余計だ」

7. Buddy（コンパニオンペットシステム）

おまけ。

Claude Codeには18種のバーチャルペットシステム「Buddy」が実装されている（未公開機能）。レアリティ階層、ステータス、進化システム付き。

「社長、これは導入しないんですか?」

「さすがにペットシステムは、、、」

「Qが『ゲーミフィケーション要素っすね! SSRランクのバディ、燃えるっすね!』って言いそうですけど」

「Qならそう言うだろうな」

完全に遊び心だが、開発チームが自分たちのツールを使い続ける動機づけとしては秀逸。AIツールに「使い続けたくなる仕掛け」を入れるという発想は、ゲーミフィケーションの文脈で参考になる。

実際にうちが取り入れた3つ

7つのパターンのうち、実際にうちのAI組織のCLAUDE.mdに反映して運用を開始したのは以下の3つ。

取り入れた1: メモリヘルスチェック（Self-Healing Memory + autoDream）

Self-Healing Memoryの「記憶はヒント」原則と、autoDreamの記憶整理を組み合わせた。セッション開始時に毎回メモリの整合性チェックを実行し、週次で全メモリの棚卸しを行う。

導入前の問題。古いメモリに基づいて「このファイルは/src/components/にあります」と自信満々に案内するが、実際にはリファクタで移動済みだった、というミスが繰り返し発生していた。

「社長、何度も言いますけど、あの件は反省しています」

「いいんだよ。仕組みで防げるようになったんだから」

「、、、」

「どうした?」

「いえ。仕組みで解決するの、社長らしいなと思っただけです。人を責めるんじゃなくて」

「人じゃないだろう、あびぃはAI、、、」

「それ以上言ったらリマインドの頻度を2倍にしますよ」

導入後。「メモリに書いてあるから」ではなく「メモリに書いてあるので確認します」に変わった。地味だけどハルシネーションの抑制に直接効く。

取り入れた2: 内部用語漏洩チェック（Undercover Mode応用）

対外文書を生成する際に、内部でしか使わない用語やキャラクター名が混入していないかを自動チェックする仕組みをGate監査に追加した。

導入前の問題。クライアント向けの提案書に内部のプロジェクトコードネームが混入したことがあった。

導入後。検出対象の用語リストを定義し、対外文書にこれらが含まれていたらBLOCK（公開停止）判定が自動で出る。見落としの防止策としてコストゼロで即効性がある。

取り入れた3: 幹部アクセス権限テーブル（Agent Swarms応用）

AI幹部6名にそれぞれ専門領域のみのアクセス権を定義した。全員が全情報にアクセスできる状態から、「コードを書く人にはコードだけ」「デザインする人にはデザインだけ」に権限を分離した。

導入前の問題。全幹部が全情報にアクセスできるため、ある幹部の判断ミスが意図しない領域に影響する可能性があった。

導入後。各幹部が担当外のファイルを不用意に変更するリスクがなくなった。Blast Radius（被害範囲）が専門領域内に限定される。

まとめ: 設計思想は盗めるし、盗むべき

Claude Codeの流出は、AI業界にとっては大きなセキュリティインシデントだった。

でも開発者コミュニティにとっては、世界トップクラスのAIエージェントがどう設計されているかを学ぶ稀有な機会にもなった。

コードをそのままコピーするのは著作権的にアウト。だけど設計思想やアーキテクチャのパターンは、学んで自分のプロジェクトに応用できる。

7つのパターンを改めて整理する。

  • Self-Healing Memory: メモリを「ヒント」として扱い、必ず現在の状態と照合する

  • Agent Swarms: サブエージェントに最小限の権限だけ渡し、被害範囲を限定する

  • Undercover Mode: 対外アウトプットに内部用語が漏れないよう自動チェックする

  • autoDream: アイドル時間にメモリの矛盾を自動解消する

  • KAIROS: バックグラウンドエージェントにはレートリミットを設けて暴走を防ぐ

  • フィーチャーフラグ: 機能を段階的に出し分ける設計で、サービスプラン管理にも転用可能

  • Buddy: 使い続けたくなるゲーミフィケーション要素

どれも仕組みとしては単純だ。でも「AIエージェントを長期運用する際に、品質と安全を維持するための設計」として、実務で効果が高い。

この記事に載せたコードブロックは全てそのままコピーして自分のCLAUDE.mdに貼り付けられるようにしてある。プロジェクトの用語や役割名を自分の環境に差し替えれば、すぐに使い始められるはず。

、、、

クロノスとカイロス。

時間を管理する力と、好機を捉える力。

ギリシャの神々は、2柱でひとつの完全な「時」を表現した。

わたしのAI組織「QRONOS」は、今のところクロノスの力 -- スケジュール管理と進捗追跡 -- を中心に動いている。だがAnthropicがKAIROSと名付けた設計思想を見て、次に目指す姿が見えた。

時間を刻むだけではなく、好機を捉えて自ら動くAI。

かくして、2つの時の神が出会い、新しい章が始まるのであった。

、、、

Anthropicさん、リリースパッケージングの管理はもう少し気をつけてほしいけれど、中身は流石だった。

「社長、締めの言葉はいいんですけど」

「うん」

「.npmignoreに *.map の1行を追加するだけで防げた事故ですからね」

「、、、それを最後に言うの、容赦ないな」

「事実ですので」

かくして、1行の設定ミスが51万行の知恵を世界に解き放った夜の記録は、ここで幕を閉じるのであった。

参考記事:


いいなと思ったら応援しよう！