本動画は、Anthropic社の「Claude Code」が誤ってリークされた事件を題材に、25億ドル規模の事業を支えるエージェントシステムの裏側にあるアーキテクチャを詳細に解説するものである。表面的な新機能の話題にとどまらず、ツールレジストリ、権限システム、セッションの永続化など、実運用に不可欠な12の重要な基盤技術（プリミティブ）を明らかにする。さらに、視聴者が自身のエージェント開発にこれらの知見を応用できるよう、実践的なフレームワーク評価スキルの提供についても紹介し、AIエージェント構築の核心が地味で堅実なバックエンドエンジニアリングにあることを説いている。
前代未聞のClaude Codeリーク事件
これ以上大きな出来事はありません。Anthropicが誤ってClaude Codeをリークしてしまったのです。これは年間25億ドルの売上を見込む製品です。Claude Codeがどのように機能するかを説明する、まさに秘伝のソースと言えるものです。そして、その中身は実は、多くの人が注目しているようなことではありません。私はブログや息を呑むような報道、そして熱狂的な記事を読んできましたが、無効になっている機能フラグや、Claude Codeが数週間後にリリースする予定のものにばかり過剰な焦点が当てられているように見えます。まあ、それはそれで構いません。
しかし、そんな話題は数週間しか持ちません。私が見たかったのは、この25億ドル規模のビジネスを支えるClaude Codeの根底にあるアーキテクチャは何なのか、ということです。より具体的には、企業向けにエージェントを成功裏に稼働させるための、基盤となるインフラストラクチャの知見として、私たちが学び、応用できるものは何かということです。Claude Codeがリークされ、誰もがアクセスできるようになった今、その秘伝のソースの一部をどのように取り入れ、「なるほど、ここから何を学べるだろうか」「これを効果的に構築するにはどうすればいいのだろうか」と考えることができるはずです。だからこそ、私は詳細にリポジトリをレビューして学んだことについてお話しするつもりです。
また、皆さんが独自のエージェンティックなフレームワークやハーネスを評価し、Claude Codeから学んだことに基づいて、システムへの変更を提案するのに役立つ特別なスキルもリリースします。これは、今回の件から私たちが得られる、最も堅実で有用かつ実践的な収穫の一つだと思います。
リークの背景と開発のスピード
向こう2週間のAnthropicのロードマップを覗き見できるといった、浮かれた話題は本当はどうでもいいのです。彼らは猛スピードで新機能をリリースしますから、すぐにその期間は過ぎ去り、また別のものをリリースし始めるでしょう。本当に重要なのは、成功するエージェンティックな本番システムを維持するために、Anthropicが水面下で何を構築しているのかを学ぶことです。
それが重要なんです。「これはClaude Codeだけに関係する話なの？」と疑問に思っているなら、答えはノーです。Claude Codeから学べることは、私たち全員に当てはまります。だからこそ、私はCodexに特化したスキルもリリースし、Claude Codeから学べる教訓を結びつけています。そうすることで、私たちが知識を共有し、選択したLLMが何であれ、エージェントが時間とともにどのように仕事を推進し、維持していくのかを本当に理解し始めることができるのです。
しかしその前に、ありのままの事実をはっきりさせておきたいと思います。これはここ数日でAnthropicから起きた2度目の重大なリークであり、なぜこんなことが起きたのか、私たちは自問してみる価値があります。今週初め、Fortune誌は、Anthropicが新しいモデルであるClaude Mythosを説明するブログの草稿を、一般に公開されたサーバーに放置していたと報じました。
そして5日後の今、ビルド構成のエラーによってClaude Codeがリークされる事態となりました。はっきりさせておきたいのですが、これらは全く異なるメカニズムによるものです。システム自体も異なりますが、同じ週に同じ会社で起こったことなのです。Mythosや他のAIモデルがこのリークを引き起こしたと言いたいわけではありません。Anthropicは人為的なミスだと言っていますし、それに反するような公的な証拠は確かにありません。
しかし、このパターンは、AI支援開発を利用して構築を行っているすべてのチームが自問すべき疑問を私に抱かせます。あなたのチームの開発スピードは、運用の規律を置き去りにしていませんか。その点に関して言えば、Claude Codeがどのようにリークされたかについて、開発者コミュニティのデフォルトの推測が、AIモデルのエラーを巻き込んだものになっているのは、私にとって非常に象徴的です。
Alex Vulkov氏によって推測として明確にフラグ付けされ、Xで出回っている理論はこうです。Anthropic社内の誰かが誤って適応的推論モードに切り替えられ、そのClaude CodeセッションがClaude Sonnetにフォールバックした結果、モデルが日常的なビルドステップの一部として、リーク元となったマップファイルをコミットしてしまったというものです。もちろん、それが本当に起きたことなのか確証はありません。しかし、AI自身のコードをリークするビルド成果物をAIがコミットしたという事実が議論の一部になっていること、そしてそれが外部から見て非常に理にかなった一連の出来事として合理的に推測できるということは、2026年現在の開発スピードとビルドセキュリティの現状について、知るべきことのすべてを物語っています。
Anthropicが言っているように、AIがコードの90%を書き、エンジニアが一人当たり1日に複数のリリース、場合によっては最大5回のリリースを出荷しているような状況では、構成のズレが生じる表面積は非常に大きくなります。
正確な一連の出来事が何であれ、その開発スピードが今週何らかの結果をもたらしたことは私には明らかです。Anthropicにとって2つの重大なリークがありました。チームがどのように引き締めを図り、運用の規律を取り戻すのかに興味があります。おそらく、彼らはリリースのペースを大幅に調整することなく、それを行う方法を見つけるだろうという気がしています。
開発のスピードはこれからも続くでしょうし、運用のペースもそれに追いついていくはずです。皮肉なことに、AIの基盤技術について話すときにこれから触れる内容のいくつかは、まさに私がAnthropicがこれ以上同じことを繰り返さないように引き締めを図る上で頼りにするだろうと推測する、退屈な事柄なのです。それはビルドパイプラインの構成や、公開ステップの検証といった、誤って何かをリークしないようにするために必要な作業のことです。
彼らはこの混乱の後始末を続ける中で、そういった退屈で基本的な基盤技術をもう一度見直すことになるだろうと私は思っています。
Claude Codeを支える12の基盤技術
さて、Claude Codeを可能にしている信じられないような配管作業について、私たちは何を学べるでしょうか。「信じられないような配管作業だって？ネイト、一体何を言っているんだ？」と思うかもしれません。でも、これは本当のことなんです。これこそが秘伝のソースなのです。
これまでClaude Codeの裏側を覗き見たことはありませんでした。私はこの情報を、複数の階層に編成された12の具体的な基盤技術として整理する作業を行いました。これは提示順に並べているわけでも、コードベースでの順序でもありません。Anthropicがどのようにシステムを構築しているかを私たちが理解する上で、合理的で理にかなった順序になっています。
私はあなたに代わってコードベースの分析を行いました。ですから、これらは独自のエージェンティックなシステムを構築する際に考えるべき順序で提示されており、それは理にかなっていると思います。12のカテゴリーがあり、3つの階層に分かれています。そして、それぞれの基盤技術について、私は3つのことを挙げていきます。つまり、普遍的なパターン、どんなエージェンティックなシステムにも当てはまる設計原則ですね。次にClaude Codeでの現れ方、つまりそのパターンの本番環境レベルの具体的な実装です。そして最後に、これがあなたのシステムではどう展開される可能性があるか、という点です。それでは早速始めましょう。
デイワンで実装すべき基本の基盤技術
もしあなたがエージェントをゼロから構築しているなら、それを正しく行う方法についてClaude Codeは何を教えてくれるでしょうか。最初から譲れない要素とは何でしょうか。
ナンバーワン。メタデータを第一に考えたツールレジストリの設計を考えてください。 Claude Codeを熱心に追っている人なら、これはそこまで目新しいことではありませんが、今回のClaude Codeのリークからは、それについて本当に大量の詳細が分かります。パターンは非常に明確です。実装コードを書く前に、データ構造としてエージェントの機能を定義するのです。レジストリは、何も実行することなく、「何が存在し、それは何をするのか」という問いに答えるべきです。
では、これはClaude Codeの中でどうなっているのでしょうか。私が発見したのは、Claude Codeが2つの並行したレジストリを維持しているということです。ユーザー向けのアクションのための207のエントリを持つコマンドレジストリと、モデル向けの機能のための184のエントリを持つ並行ツールレジストリです。そこにあるすべてのエントリは、辞書のようなものです。名前、ソースのヒント、そして役割の説明を持っています。
レジストリは信頼できる唯一の情報源であり、実装はそこからオンデマンドで読み込まれます。つまり、この分離はモデルの推論に依存していません。構造的なものなのです。なぜこれが重要なのでしょうか。クリーンなツールレジストリがなければ、コンテキストによってツールをフィルタリングすることはできません。副作用を引き起こすことなくシステムを内部調査することもできません。そして、新しいツールを追加するたびに、オーケストレーションのコードを変更する必要が生じます。レジストリは他のすべてが構築される土台なのです。
これを自分にどう当てはめるかを考えるなら、必ずしも呼び出す必要なしに、登録されているすべての機能のメタデータを返すリストツール関数のようなものを考えてみてください。実行時のフィルタリングをサポートできるようにすべきです。各ツールを名前と短い説明で明確に定義できるようにすべきです。そして、モデルにツールの実行や選択を考えるよう依頼する前に、その関数を書けるようにしておくべきです。これがツールレジストリです。非常に基本的なことです。
もし私がClaude Codeのリークに基づいてエージェントを構築するなら、初日から検討するであろうもう一つのことは、権限システムです。ナンバーツーですね。 すべてのツールが同じリスクを伴うわけではありません。そのリスクを分類し、カテゴリごとに異なる承認レベルを適用するのです。コードの中で私が見つけたのは、Claudeがその機能を3つの異なる信頼レベルに分割しているということです。
最も信頼レベルが高く常に利用可能な組み込みツール。中程度の信頼レベルでコマンドによって無効にできるプラグインツール。そして、デフォルトで最も信頼レベルが低くユーザーが定義するスキルです。そうです、この仕組みの中ではスキルもツールと見なされているのです。すべてのレベルで、読み込みの動作、権限の要件、そして障害への対応が異なります。
そして、bashツールと呼ばれるシェル実行ツールだけでも、18のモジュールからなるセキュリティアーキテクチャを備えています。これはタイプミスではありませんよ。事前に承認されたコマンドパターンから、破壊的なコマンドに対する警告、Git固有のセキュリティチェック、サンドボックスの終了まで、18の独立したモジュールがあるのです。彼らはこれに本当に細心の注意を払っています。なぜなら、シェル実行スクリプトとしてのbashツールは、一歩間違えればあっという間に大惨事になりかねないからです。
そしてこれはすべて関連しています。Mythosのリーク以来、会話を支配しているセキュリティの懸念そのものに直結しているからです。Open Clawのようなシステムでもそうです。結論として、もしあなたのエージェントが世界に対してアクションを起こせるなら、もしエージェントがコードを実行でき、APIを呼び出せ、メッセージを送信でき、ファイルを変更できるのに、権限のレイヤーを持っていなければ、あなたが持っているのは単なるデモに過ぎません。製品ではないのです。安全に実行できるものは何も持っていないことになります。
ですから、単一のツールに対する18のモジュールのセキュリティスタックについて考えるとき、私はAnthropicが偏執狂的になっているとは思いません。25億ドル規模のビジネスレベルで安全に機能するシステムと、小さなノートブックの中でだけ動くシステムとを分けるものこそが、これなのだと思います。
では、これはセキュリティと権限についてどう考えるべきかについて、何を示唆しているのでしょうか。まず、事前の分類について考えてください。このアクションは読み取り専用ですか。変更を加えるものですか。潜在的に破壊的なアクションですか。安全だと分かっている、事前に承認されたパターンはありますか。削除や上書きを行う可能性のあるアクションを事前にフラグ付けできる、破壊の検出機能はありますか。ドメイン固有の安全性はどうですか。心配している特定のリスク要因に対する、的を絞ったチェックを行っていますか。権限のログ記録はしていますか。許可または拒否されたすべての決定を、その決定を再現できる十分なコンテキストとともに記録していますか。これらは、Claude Codeのリークにすでに含まれている、あなたが考えるべき事柄なのです。
ナンバースリー。華やかではありませんが、非常に重要です。クラッシュを乗り越えるセッションの永続化です。 ここで見られるパターンはとてもシンプルです。エージェントのセッションは、単なる会話の履歴ではありません。会話を含む回復可能な状態なのです。利用状況の指標も含みます。権限の決定も含みます。そして設定も含みます。要するに、すべての要素の集合体なのです。セッションを再開するときにこれらのどれかが欠けていたら、元のセッションと同じようには機能しません。
コードを読み解いて私が発見したのは、Claude Codeがそれらのセッションを、JSONファイルの形で完全に保存しているということです。セッションIDをキャプチャし、メッセージをキャプチャし、入出力のトークン使用量をキャプチャします。そして基本的に、クエリエンジンは保存されたそのセッションから完全に再構築することができます。
クラッシュの後でも、ロード機能を使って会話の記録を再構築し、カウンターを復元することで、セッション全体を再インスタンス化できます。基本的に、完全に機能するエージェンティックなエンジンをクラッシュから復帰させることができるのです。
なぜこれが気になるのでしょうか。エージェントはクラッシュするからです。しょっちゅうクラッシュします。接続が切れたり、ユーザーがタブを閉じたりします。もしあなたのエージェントが、どのツールが利用可能だったか、どのような権限が付与されていたか、どれだけのトークンが消費されたかを含めて、中断したところから確実に再開できないのなら、中断されるたびに再起動することになります。そして、再起動するたびに顧客体験は低下していくのです。
ですから、これのあなた自身のバージョンを構築すべきです。再開に必要なすべてをキャプチャするセッション状態の構造を検討すべきです。単なるシャットダウン時だけでなく、重大なイベントの後にどのように永続化できるかを検討すべきです。そして、単なる会話履歴だけでなく、エージェンティックな状態全体を再構築するセッション再開機能を構築できるようにすべきです。
ナンバーフォー。ワークフローステート（作業フローの状態）です。 これは非常に重要なことですが、全く話題にされていません。パターンはシンプルです。会話を再開することと、ワークフローを再開することは同じではありません。チャットの記録は「私たちは何を話したか」に答えますが、ワークフローの状態は「私たちはどの段階にいるのか」「そのワークフローの結果としてどのような副作用が起きたのか」「この操作は再試行しても安全か」「再起動した後、どうすべきか」という問いに答えます。
これはセッションの永続化と非常に密接に関連していますが、別のものです。ほとんどすべてのエージェンティックなフレームワークは、会話の状態とタスクの状態を混同しています。しかし、これらは異なる解決策を必要とする異なる問題なのです。
ワークフローステートを持っていなければ、エージェントを以前と全く同じ状態に再インスタンス化することはできても、ワークフローのどこにいたかを自動的に思い出すことはありません。ワークフローはエージェントを超えて持続するものだからです。ツールの実行途中でエージェントがクラッシュした場合、書き込みを重複して行ったり、メッセージを二重に送信したり、再実行したりすることなく生き残ることはできません。再実行は非常にコストのかかる操作であり、潜在的に非常に破壊的です。ワークフローを再試行する明確な方法が必要であり、エージェントがクラッシュしたときにどこにいたかを知る必要があります。
ですから、長く実行される作業を、非常に明確な状態としてモデル化すべきです。「計画済み」「承認待ち」は状態の一例です。「実行中」も状態の一例です。「外部関係者の待ち」も状態の一例です。それらのチェックポイントを常に永続化したいはずです。1990年代に、コンピューターがクラッシュしてゲームのデータが消えるのを恐れて、2秒ごとにゲームをセーブしていたのと同じ考え方です。偏執狂的になってください。ワークフローの状態を保存するのです。
ナンバーファイブ。トークン予算の状況はどうなっていますか。 私が発見したのは、Claude Codeのクエリエンジンの設定が、トークン使用量に対する非常に厳格な制限を定義しているということです。会話の最大ターン数があります。会話におけるトークンの最大予算があります。そして、会話を自動的に圧縮する圧縮のしきい値があります。ターンごとに、予測されるトークン使用量を計算します。予測が予算を超える場合、API呼び出しが行われる前に、構造化された停止理由とともに実行がただ停止します。
これは、私たちが実際に日常でClaudeをどのように使用しているかからも確認できます。これは極めて重要です。なぜなら、予算の追跡を行わなければ、トークン制限を超えてしまったことに気づくことになるからです。これは単なる常識です。暴走ループに陥り、使うつもりのなかったお金を使ってしまうことになります。
Claudeは実際、Anthropicにとって利益にならない、顧客の長期的な健全性に利益をもたらすようなチェックを組み込んでいます。なぜなら、Anthropicの短期的な利益を考えれば、トークンを燃やしてAnthropicにお金を使ってほしいと思うはずだからです。Anthropicはここで非常に責任ある市民として振る舞い、「お客様が明確に意図していないような、予算の暴走的な支出をしてほしくないのです」と言っているわけです。これは、短期的な利益にはならないかもしれないけれど長期的な顧客の信頼を高めるために、Amazonが返品を容易にしているのと同じことです。同じ理屈ですね。
彼らはトークンを簡単に追跡できるようにすることで、顧客の信頼を高めているのです。もしあなたがエージェントを構築しているなら、トークン予算の管理も構築すべきです。入力トークン、出力トークン、予算、ハードストップを設けるべきです。これは譲れない条件です。2026年において責任を持って開発を行うなら、当然のことなのです。
ナンバーシックスは非常に大きな意味を持ちます。 これはClaudeに特有の機能で、長期的に真の信頼を築くものです。Claudeは構造化されたストリーミングイベントに投資しています。Claudeの「思考のプロセス」について話すとき、私たちが意味しているのはこれです。パターンは非常に明確で、私たちはフロントエンドでそれを常に目にしています。ストリーミングは単にテキストを表示することではありません。モデルが実行されている間に目にするすべてのストリーミングイベントは、そのモデルで何が起きているかを知る機会なのです。
モデルはシステムの状態をあなたに伝える必要があります。ですから、エージェントがどのツールを使おうと考えているのか、どれだけのトークンが消費されたのか、エージェントが作業をまとめようとしているのか、といったことを伝える必要があるのです。あなたのことは分かりませんが、私はClaudeを使うとき、このストリーミング状態を常に利用しています。モデルがどこに向かおうとしているのかを教えてくれるからです。そして、モデルの思考のプロセスを読み取って、軌道から外れそうだと分かれば、メッセージを打ち込んで介入することもあります。
つまり、これは極めて有用なものですが、自動的に備わるものではありません。そのように設計しなければならないのです。私が発見したのは、Claude Codeのクエリエンジンが、メッセージの開始、コマンドの一致、ツールの一致など、ストリームで使用される型付けされたイベントを発行するということです。基本的には、このクエリストリームを構築する際に呼び出すことができる、あらゆる種類の型付けされたイベントです。
そして重要なのは、クラッシュした場合や問題が発生した場合です。私がクラッシュや問題について何度話したかお気づきですか。優れたエンジニアリングは失敗の経路を想定し、そのための計画を立てます。このケースでは、Claudeチームはエージェントが時々クラッシュすることを想定しており、問題が発生した場合には、ストリームが送信する最後のメッセージとして、クラッシュの理由を含む特別な型付けイベントを含めています。まるでクラッシュしたときの小さなブラックボックスのようです。
ですから、メッセージをどのように送り返すかを考えるとき、単に生の思考のプロセスなどをそのまま送ればいいとは考えないでください。時間をかけて、ユーザーに実際の情報を伝え、ユーザーが何が起きているかを理解できるような、意味のあるストリーミングイベントを送信してください。そして、必ずクラッシュに備えた計画を立ててください。
さて、関連するナンバーセブンです。システムイベントのログ記録です。 ナンバーシックスがストリーミングイベントやモデルが考えていること、あるいは少し洗練された思考のプロセスに関するものだったとすれば、システムイベントのログ記録は、何か問題が発生したときのものです。ここでも失敗のケースです。エンジニアリングにおいては失敗のケースについて考えてください。これはメタ的な要素の一つです。何か問題が発生したとき、会話の記録は、エージェントが「何を言ったか」だけでなく「何をしたか」をユーザーに伝える必要があります。
そのため、会話やストリーミングイベントとは別に、Claude Codeはシステムイベントの履歴ログを維持しています。これが信頼できる唯一の情報源となります。どのようなコンテキストを読み込んだのか。レジストリの初期化はどのようなものだったのか。Claudeはどのようなルーティングの決定を下したのか。実行回数は何回だったか。Claudeはどのような権限の拒否や承認を経験したのか。すべてのイベントにはカテゴリがあり、構造化された詳細とともに提示されるため、エージェンティックな実行プロセスを簡単に再構築することができます。
これは、エンタープライズ向けのシステムを構築する際に行うべきことです。真剣に稼働させるシステムを構築しようとするなら、このように準備するのです。ですから、本格的なエージェントを構築しようとしているなら、イベントログについて考える必要があります。システムが、言われたことだけでなく行われたことの記録をどのように維持し、それをどのようにして証明可能な形で遡ることができるかを考える必要があるのです。
ナンバーエイト。Claude Codeは検証を真剣に受け止めています。 これは2つのレベルで行われており、私たちは普段そのうちの1つしか目にしていないため、その両方について話したいと思います。私たちが目にする方は非常に明白で、すぐに話が終わると思います。イベントのストリームを見ていくと、Claudeが自分の作業をチェックするための独立したステップを持っているのが分かります。
それは想定内のことであり、Claude Codeが明示的に提供している機能です。それはハーネスの一部です。行われた作業が正しいことを確認する。素晴らしい。よくできました。Aプラスです。
しかし、まだ終わりではありません。Claude Codeのリークから読み取れる、非常に重要だと思われるパート2です。エージェンティックなハーネスに対して人間が加えた変更についても、検証できるようにする必要があることを認識しなければなりません。つまり、あるエージェントの実行が正常に完了したかどうかだけではないのです。それは重要ですし、良いことです。しかしそれに加えて、私がハーネスに変更を加え、その後のすべてのエージェントの実行方法を変えたとき、何かを壊していないという確信を持ってそれを行えているか、ということなのです。
ここで必要になるのが、変更後もモデルが一般的なガードレールに沿って機能し続けるかどうかをテストする、特別な検証テストです。例えば、この変更を行った後も、破壊的なツールは常に承認を必要としているか、といったことです。それは合理的なガードレールだからです。あるいは、トークンがなくなったとき、モデルはどうなるのか。私たちが期待するように適切に停止するのか、それともハードクラッシュのようなことが起きるのか。これらは、あらゆるエージェンティックな体験においてガードレールとして備えておきたい事柄です。
それらに名前を付け、ログに記録すべきです。そしてこれが、私たちが普段あまり考えない、ハーネスの進化を見据えた第二レベルの検証なのです。
運用を成熟させるための高度な基盤技術
さて、以上がデイワンで実装すべき基本でした。これらは、チームがハーネスを組み立てる際に、検討が遅れたり、全く検討されなかったりするのをよく見かける事柄です。ここからは、運用の成熟度に向けてステップアップし、私たちが学べるより大きく深い教訓について考えていきましょう。ここで4つの教訓を紹介しますが、もっと知りたい方はサブスタックにまとめてありますのでご覧ください。
まずはナンバーワン。ツールプールのアセンブリです。早口言葉みたいですね。 ここで話しているのは、184のツールがあったとしても、Claudeはエージェントを実行するたびに、それらのツールすべてを組み合わせて利用可能なプールを作るわけではないという考え方です。代わりに、モードのフラグ、権限のコンテキスト、拒否リストなどに基づいて、そのタスクを完了させるために使用されるツールのグループである、セッション固有のツールプールを組み立てるのです。
設計者として学ぶべきことは、汎用的なエージェントは、実行の準備をする際にツールの候補リストを動的に組み立てる必要があるかもしれないという考え方です。これは、多くのエンタープライズワークフローで、「これらが利用可能なツールです」とハードコーディングされているのをよく目にする部分です。Claudeが示唆しているのは、より汎用的な問題解決エージェントを持つ場合、エージェントが効率的に読み取れるような幅広いツールのサブセットを与え、そこから特定のタスクに必要なツールをエージェント自身に選ばせるようにする方がよいかもしれない、ということです。
ナンバーツーはよく話題に上るものです。トランスクリプト（会話記録）の圧縮です。 これについてもう少し詳しく掘り下げてみましょう。会話の履歴は明らかにトークンを消費するリソースであり、Claude Codeは設定可能なターン数の後に履歴を圧縮することで、それを自動的に管理しています。圧縮する際には最近のエントリを保持し、古いものは破棄する傾向があります。トランスクリプトストアは、データ損失を防ぐために、それが永続化されたかどうかを追跡します。
長く実行されるエージェントに対して、どのように自動圧縮を構築するかを考える必要があります。しきい値はどうするか、何を圧縮し、何を保持するか、保持しているものが正しいかどうかをどうやって知るか、といったことです。長く実行されるエージェントについて考えるとき、これは非常に重要なテーマです。エージェントを起動させた最初の指示をどのように保持しつつも、エージェントの現在の状態とは無関係な途中の会話の分岐点やアクションを、スペースを大幅に節約できるような形でどのようにカットしていくかを考えなければならないからです。
というわけで、圧縮はその一つです。すでに話した通りです。Claude Codeが裏側でどうやっているかを見られるのは素晴らしいことです。今後数ヶ月のうちに、誰もがこの分野にさらに多くの労力を注ぐことになるでしょう。
ナンバースリー。これは少し高度になりますが、権限の監査トレール（証跡）について考えてください。 私は常に監査し、説明できるように準備しておくべきものとして権限について話していますが、Claude Codeは実際にこれを容易にしています。なぜなら、彼らは権限を単なる「はい」か「いいえ」のブール値のゲートとして扱っていないからです。代わりに、権限の状態を、照会が容易なファーストクラスのオブジェクトとして扱っているのです。
そしてClaudeは実際、異なるコンテキストに機能するために3つの独立した権限ハンドラを構築しています。人間が介在する（ヒューマンインザループ）ためのインタラクティブなハンドラがあります。複数のエージェントを調整する際に、オーケストレーターエージェントが権限を付与する必要がある場合のコーディネーターハンドラがあります。そして、オーケストレーターエージェントによって管理される自律的な実行を行うスウォームワーカーレベルのハンドラもあります。
つまり、それぞれ異なる権限構造を必要とする3つの異なるタイプのエージェントがあり、Claude Codeの権限アーキテクチャはそれらすべてを考慮しているのです。あなたもそうすべきです。
そして最後になりますが、Claude Codeにはエージェントのタイプシステムがあり、私の知る限り、これはこれまでリークされていなかったものです。 Claude Codeは、Explore（探索）、Plan（計画）、Verify（検証）、Guide（ガイド）、General Purpose（汎用）、Status Line Setup（ステータスライン設定）という6つの組み込みエージェントタイプを定義しています。これらのエージェントタイプはそれぞれ、独自のプロンプト、許可された独自のツール、独自の行動制約を持っています。例えば、Exploreエージェントは定義上、ファイルを編集することはできません。Planエージェントはコードを実行しません。
ここで応用できる教訓は、ミニオンズをクローンするようにむやみにエージェントを発生させるな、ということです。そうではなく、作業を分割する際に役割を非常に明確に制限し、管理可能な数のタイプに分類することです。そうすることで、それらのタイプを管理してエージェント集団全体をコントロールし、彼らが生み出す作業の効率を管理できるようになります。これは、より大規模なマルチエージェントシステムについて考えるための素晴らしい方法です。
リリースするエージェント構築スキルの紹介
さて、たくさんの内容がありましたね。ここで、私がリリースするもの、そして私が構築したものについて少しお話ししましょう。私は、私たちが実行している独自のエージェントにこれらの知識の一部を運用できるようにするための、エージェントハーネススキルをリリースします。そうです、「自分のOpen Clawエージェントでも動くの？」「どんなエージェンティックな設定でも使えるの？」と疑問に思っているなら、答えはイエスです。絶対に実行できますし、良いヒントを与えてくれるはずです。
では、これは何をするものなのでしょうか。2つのモードがあります。設計モードでは、チャットアシスタント、ワークフローオーケストレーター、コードエージェントなど、あなたが構築したいプロダクトを説明することができます。するとこのスキルは、構造化された設計プロセスを通してあなたをガイドし、ハーネスの形を提案します。最低限有用な基盤技術のセットを特定し、実装をフェーズごとに順序付けし、検証の基準を定義します。そして、これらすべては、あなたがハーネスのためのコードを1行も書く前に行われるのです。
これは単なる定型文（ボイラープレート）を生成するわけではありません。今日の本番環境で最も成功しているエージェントがどのように動いているかから学べることに深く根ざした根拠を持つ、アーキテクチャを生成するのです。
また、もう一つのモードである評価モードもあります。すでに既存のハーネスを持っている場合、それを自分のコードベースに向けることができます。自分のcloud.mmarkdown（アーキテクチャドキュメントなど）に向けると、何が欠けているか、何がないか、今回のClaude Codeのリリースで明らかになった知識から何を学べるかを教えてくれます。
アーキテクチャ、安全性と権限、状態と耐久性など、私がこの動画で特定した原則に照らし合わせて、コードベース全体のすべての次元を評価し、重要度順に並べられた発見事項、優先順位付けされたアップグレードの道筋、そして修正が機能することを確認するための具体的なテストを返してくれます。
さて、なぜこれは単なるドキュメントではなく、スキルなのでしょうか。簡単に言えば、スキルであればAIを使って動的に何かを行うことができるからです。そして、それがこの目的のすべてなのです。今日私たちが持っているエージェンティックな設定を実際に実装して修正し、Claude Codeが教えてくれることに基づいて、より良いエージェンティックな設定を設計することです。
それが、単に話題を煽り立てるよりも、今回のリークから実用性や有用性を引き出すための、はるかに持続可能な道筋だと思います。そしてそうです、私はこのスキルを、ClaudeのスキルパッケージとしてのClaude Code向けと、Codex固有のメタデータパターンやエージェントのルーティングを備えたOpenAIのCodex向けの両方で構築しました。
そして中核となるロジックは同一です。基盤技術の評価方法、評価基準の評価方法、設計プレイブックの評価方法などは同じです。その理由は、これらの基盤技術は非常にうまくスケールすると私が考えているからです。私たちが選択するLLMに関係なく、より堅牢なシステムを構築するために共に学び、活用できるものとして、エージェンティックな開発の基盤技術について私たち全員が確実に向き合うための、これは非常に意図的な選択でした。
正直に言いましょう。このスキルは独断的です。正当な理由がない限り、無駄のない単独のメンテナンス可能なアーキテクチャに偏っています。マルチエージェント設計を推進する本当に良い理由を与えない限り、単一エージェントの設計から始まります。シンプルさを重視しています。なぜなら、シンプルさはメンテナンス可能だからです。
そしてこれは非常に意図的です。なぜなら、私がエージェンティックなシステムで見てきた最も一般的な失敗のパターンは、エンジニアリング不足ではないからです。実際には過剰なエンジニアリングなのです。機能する権限システムを持つ前に、非常に複雑なマルチエージェントの調整レイヤーを構築してしまうとか、セッションがクラッシュから生き残れるようになる前に、プラグインのマーケットプレイスを実装してしまうとかです。そのため、このスキルは不必要な複雑さには反発します。はっきり言って、時期尚早な複雑さこそが、ほとんどのプロジェクトが死を迎える場所だからです。
エージェント開発の真髄は地味な配管作業
事態が落ち着いた後で、Claude Codeのリークを一歩引いて見てみると、ここでの収穫は何でしょうか。最大の収穫は、エージェントの構築は80%が華やかさのない地味な配管作業であり、AIは20%に過ぎないということです。
私がこの動画で時間を割いて話したことの多くは、ほとんどの人が目を丸くして退屈がるようなことですが、それこそがエージェントを数十億ドル規模のレベルで成功させるための、まさに地味で重要な要素なのです。これこそが、何百万人もの人々にサービスを提供することを可能にしているのです。
失敗のケースについて考えなければなりません。セキュリティについて考えなければなりません。エージェントがクラッシュからどのように回復するかを考えなければなりません。エージェントが限られたスキーマから選択し、さまざまなシナリオにわたって有用な情報を返せるようにするための型付けされたイベントをどのように用意するかを考えなければなりません。これがスケールするためのアーキテクチャなのです。
私にとって驚くべきことは、これらすべての多くが、本質的には優れたバックエンドエンジニアリングの機能であるということです。その意味で、進化はしていません。私たちはただ、優れたバックエンドエンジニアリングをこれらのエージェンティックなパイプラインに適用し、「おや、これはかなりうまく機能するぞ」と発見しているだけなのです。
配管作業はあまり華やかではないかもしれませんが、私がそれについて話しているのは、それがすべてだと信じているからです。そして、人々がこれを理解するのに苦労してほしくないので、それを簡単にするためのスキルを立ち上げています。これらの原則を推論するために、あなた自身がClaude Codeのリークをわざわざ調べる必要はありません。コミュニティとして、それらを引き出して議論できるようにすべきです。
ですから、コメントで教えてください。私が言及しなかったことで、あなたがClaude Codeから学んだことは何ですか。そして、私たち全員がClaude Codeから学び、自分たちのエージェントをより良くできると思うことで、将来のエージェント作業に含まれてほしいと思うものは何ですか。ぜひ聞かせてください。それでは。
コメント