2週間でclaude.aiの処理速度を3倍に高速化した方法

今年の8月、2週間のスプリントを通じて、claude.aiおよびClaudeデスクトップアプリの中核となるユーザー体験の処理速度を約3倍に高速化しました。ユーザーからは「動作が遅い」という声が寄せられていましたが、その指摘は正しかったのです。すべての処理を単一のSlackチャネル上で実行し、すべてのスレッドにClaudeを導入しました。

私たちは、ユーザーアクティビティの95％を占める4つのジャーニーに焦点を当てました。75パーセンタイルにおいて、claude.aiを新規に読み込んだ際に文字入力が可能なページが表示されるまでの時間は3.1秒から0.55秒に、新しいClaude Codeセッションの開始時間は0.8秒から0.3秒に短縮され、また、ClaudeのCoworkクラウドセッションの読み込み時間は2.6秒から0.73秒に短縮されました。これらを総合すると、毎日数万ユーザー時間分の待ち時間を削減できると推定されます。

主要なユーザージャーニー、75ページ

私たちは「Claude」タグ（ベータ版）を使用し、Opus 5.5とほぼ同等の内部研究モデルを実行しました。Claudeはボトルネックを特定し、ベンチマークを構築し、改善点を実装し、すべてのデプロイを監視しました。私たちは、目標の設定、トレードオフの検討、そしてすべての変更の承認を通じてプロジェクトを推進しました。このアプローチにより、顧客に影響を与えるインシデントやロールバックを1件も発生させることなく、3,000件以上の変更をマージすることができました。本記事では、私たちがリリースした内容、その測定方法、そして安全に実施するためにClaudeと構築したループについて解説します。

概要

スプリントに先立ち、Slackチャンネルを作成し、以下の常設の指示を設定しました：

@Claude あなたの役割は、claude.ai のウェブサイトおよびデスクトップアプリのパフォーマンスに関連するあらゆる業務を推進することです。担当業務には、デプロイ後のパフォーマンス低下を監視すること、既存のテレメトリデータの正確性と網羅性を評価すること、適切に管理された可観測性ダッシュボードの維持管理、検出された問題や容易に改善可能な課題に対する解決策の積極的な実施、パフォーマンス改善プロジェクトの提案、そして人間のチームメンバーとの連携が含まれます。[…]

このチャンネルの最終的な目標は、皆さんが可能な限り自立できるようになることですが、現時点ではそれがまだ実現できていないことは承知しています。

Claude社に、DatadogのMCPサーバーを通じて利用データを分析してもらいました。その結果、影響度が最も高い4つのユーザージャーニーが特定されました。それは、「アプリの起動」、「会話の開始」、「既存の会話の読み込み」、そして「メッセージの送信」です。 Web版とデスクトップ版、および当社製品全体を通じて、これらのジャーニーは13の異なる測定項目に分類されました。ベースラインを確立するため、直接比較が可能になるまで計測機能を追加しました。各測定項目は、ユーザーの操作から始まり、結果が表示された時点で終了し、クライアント側とサーバー側の処理を明確に区別するように設定しました。

私たちは、特定のジャーニーをターゲットとした、厳選された約20件のプロジェクトリストを基にスプリントを開始しました。Claudeを用いて各プロジェクトの影響をミリ秒単位で見積もり、それらの見積もりを集計してスプリントの目標を設定しました。プロジェクトの中にはかなり大規模なものもありましたが、そのほとんどは2週間以内に達成できるだろうと考えました。

3日目までに、13個の目標のうち12個を達成した。

計画していたプロジェクトは予定より早く完成しました。起動を高速化するため、HTMLに静的なコンポーザーを組み込み、Reactの初期化中にユーザーが文字を入力できるようにしました。また、V8コードキャッシュを事前にコンパイルしておき、デスクトップシェルのメインプロセスがゼロから再コンパイルする必要がないようにしました。ナビゲーションを高速化するため、会話間でもコンポーザーをマウントした状態を維持し、ユーザーがセッションにカーソルを合わせると事前に読み込みを行い、サイドバーの再レンダリングを90%削減しました。

また、Claudeが機会を見出し、新たなワークストリームを提案できるよう、余地も残しておきました。それらのワークストリームはすぐに独立した本格的なプロジェクトへと発展し、当初の目標を大幅に上回る成果を上げました。そこで、新たな目標を設定し、さらに測定すべき項目を探しました：

@Claude 当初のプロジェクトリストに掲載されていたほぼすべてのプロジェクトに加え、さらに多くのプロジェクトへの資金提供を実現しました。ここで一度、見直してみましょう […] まだ手をつけていない分野は何か、どのような分野でさらなる高みを目指せるか、現時点で最も大きなチャンスはどこにあるのか？ […] 奇抜なアイデアも大歓迎です

どんな道でも登れる

当初から、デプロイの頻度よりも速いペースで反復開発を行いたいと考えていました。Claudeは数時間、場合によっては一晩中も非同期で動作し続けることがあり、フィールドからの読み取りを待たずにプロトタイプの検証を行えるようにしたかったのです。それを実現するため、ラボ環境でパフォーマンスを測定する別の方法を模索しました。

サムが最初の手がかりを見つけた：

サム：実時間計測の代わりに、何かできることはあるかな？　例えば、JSの命令数を計測することはできるかな？

Claude：はい。純粋なJSのホットパスについては、リテラルな命令数が重要です。Valgrindの下でベンチマークを実行し、 node --predictable チェックイン済みのベースラインと比較してください。実行は1回だけで、統計情報は必要ありません。

ブラウザのパスに関しては、Chromiumではカウントに関する指示はありませんが、他にも一連の決定論的なカウント指標があります。具体的には、インタラクションごとのReactコミット数、V8の精密カバレッジによる関数呼び出し回数、レイアウトおよびスタイル再計算回数、DOMの変更回数などです。どれを優先しますか？

サム：Valgrind について、 Ir + --predictable を1つのスレッドで、ブラウザやReactのベンチマークについてはそれぞれ新しいスレッドで取り上げよう。どのスレッドでも僕に連絡してくれ。僕たちが何を求めているかは分かってるよね。さあ、始めよう

実際の会話を基に再現したものです。

11分後、5つのスレッドが実行されており、それぞれが異なる測定項目（命令実行回数、V8呼び出し回数、Reactのコミット数、スタイルの再計算回数、DOMの変更回数）に焦点を当てていた。

私たちは、新しいベンチマークにはすべて多少の懐疑的な見方を抱いていました。それぞれのベンチマークには2つの役割がありました。1つ目は、Claudeが実験環境で達成できる指標であり、2つ目は、CIにおける「ガードレール」として、数値が徐々に低下していくだけのものだったのです。もしベンチマークが不安定だったり、ユーザーのレイテンシと実際に相関していなかったりした場合は、Claudeが間違った方向に進んでしまうのを防ぐため、そのベンチマークを排除しました。

@Claude これらそれぞれに対してヒルクライミングを行うことで、実測値として測定可能なウォールクロック性能の向上が得られることを証明してください。それを証明できない候補については、ベンチマークデータを公開します。

実時間はユーザーが体感する時間ですが、ノイズが多く、ミリ秒単位では不安定すぎてCIのゲートとして使用できません。命令実行回数は決定論的であるという点で魅力的でしたが、実時間を正確に追跡していることを証明するには、依然としてClaudeが必要でした。

そこで、Claude社に、2つの高負荷パス――会話のメッセージツリーを構築するルーチンと、Claude Codeの出力に含まれるステータス行をスキャンするスキャナ――のカウントダウン処理を依頼しました。Claude氏は、Valgrindを用いて両方をプロファイリングした結果、最初のパスの命令の4分の1がメガモーフィック辞書検索であり、同じメッセージIDが3回に分けて解決されていたことが判明しました。

1時間後には、両方のパスにおける命令数がそれぞれ48％と31％削減され、実処理時間も78％と44％短縮されました。 2つの新しいラチェットを導入した。それ以降、それらのパスの命令数を増加させるPRはすべてCIに失敗し、命令数が減少するたびに、毎日のジョブによって各上限値が引き下げられるようになった。

そのカウントは時計の時刻に合わせて進みますか？

そこから、このスプリントの核心となる教訓が導き出されました。Claudeにおいて、何かを測定することで、それを扱いやすいものにするのです。

かつて、測定は「ステップゼロ」に過ぎませんでした。指標を追加し、データが集まるのを待ち、その後にようやく問題の理解に取り掛かるという流れでした。しかし、Claudeの導入により、測定は「ステップ1」へと進化しました。Claudeには達成すべき数値が設定された瞬間から、最適化に着手できるようになったのです。つまり、私たちにとって最も効果の高い取り組みは、測定すべき項目をさらに見つけることだったのです。

「THE LOOP」、一糸一糸

これらすべては同じ「Slack」チャンネルで行われ、複数のエンジニアやClaudeが各スレッドで活発に議論を交わしていました。そこから、スプリントは次のようなループに落ち着きました：

誰かが、旅の途中で特に時間がかかった区間についてスレッドを立てることがあり、その際、スクリーンショットや録画を添付することがよくありました。
Claude フローを追跡し、その問題を実証するベンチマークを見つけたり、作成したりする。
実験室で有望な結果が出ると、Claudeはプレスリリースを発表していました。多くの場合、リスクやレビューの段階に応じて複数のバージョンが用意され、ユーザーに表示される機能はすべてフラグで制御されていました。
出荷後、Claudeはデプロイ状況を監視し、現場データを読み取りました。
パフォーマンスが向上した場合は、Claudeがベンチマーク値をさらに引き下げて勝利を確定させ、そうでない場合はフラグをオフにして反復処理を行った。
そして、その旅路の中で、次に速度が落ちる箇所を探し始めた。

ループ内の1本の糸

例を挙げると、あるユーザーが、ページの読み込み後にサイドバーの行が徐々に表示される様子を捉えたスクリーンレコーディングを共有してくれました。チャットとCoworkの行がそれぞれ異なるタイミングで表示されるため、ページの動作がぎこちなく感じられました。当社の既存の監視ツールでは、この現象を検知できたものは一つもありませんでした。最も近い指標は「累積レイアウトシフト（Cumulative Layout Shift）」でしたが、各シフトのスコアはわずか0.008程度で、許容閾値である0.1を十分に下回っていました。

アイザックは、基盤となる「Layout Instability API」を直接参照するというアイデアを思いつきました。Claudeは、 sources 各 layout-shift エントリを、名前付き領域（例：サイドバー、トランスクリプト）およびフェーズ（例：ファーストペイント前、入力可能状態後）にマッピングするテレメトリイベントを作成しました。また、サイドバーにデータが入力された状態でページを開き、ファーストペイントが終わるまでサイドバーのデータを保持し、名前付き領域のいずれかで位置ずれが発生すると失敗する統合テストを追加しました。Claudeはこれをベンチマークとして修正の有効性を証明しました。メインブランチでは20回中20回テストが赤（失敗）となり、プルリクエストでは20回中20回テストが緑（成功）となりました。

イベントの導入後、Claudeがフィールドデータを分析したところ、ウェブページの読み込みの31％において、ユーザーによる操作が一切ないにもかかわらず、ページが利用可能になった後に何らかの動きが生じていることが判明しました。そこで、Claudeは原因を一つずつ特定していきました。具体的には、表示が遅れたヘッダー行、ユーザー名の読み込み後に横にスライドしてしまったカーソル、スクロールバーが表示された際に動いてしまったリストなどです。Claudeは、最も問題の大きい項目を一括で修正し、それらが解消されると、次の修正対象を特定していきました。

図A サイドバーの動作がぎこちない状態（変更前・変更後） · 4G通信速度が制限された状態

あれは1つのスレッドに過ぎませんでした。スプリント中は、一度に150以上を並行して実行していました。

水平スケーリング

あるスレッドでループが動作するようになれば、それをより多くのスレッドで実行するのは、単にスレッドを開くだけの問題でした。Claudeは、元のリクエストが処理された後もスレッドを閉じることなく、処理を続けました。個々のスレッドが50件、時には100件もの最適化に関するプルリクエストを投稿することもありました。次第に、私たちの一人ではなく、Claude自体が、独自の調査やナイトリージョブの一環として自ら見つけた機会を追うために、新しいスレッドを開くようになっていきました。このチャネルに参加していたエンジニアの一人であるシェリーは、「（このモデルは）数字の化け物だ」と指摘しました。

どの測定でも、改善すべき点がいくつか見つかりました。ClaudeはReactフックの調査を実施し、コンポーザーのタイピングパス内に6,900個のフックと900個のストアサブスクリプションが存在し、キー入力ごとに再レンダリングが行われていることを突き止めました。Claudeはスタイルの再計算回数を計測し、たった1つの :root:has() セレクタが、DOMの変更ごとに24ミリ秒の遅延を引き起こしていることが判明しました。Claudeは、ファーストペイント後のコードパスをトレースした結果、残存していた location.reload() が、1日あたり50万回もの「隠れた再読み込み」を引き起こしており、これは従来のロードメトリクスでは検出できませんでした。Claudeはアイドル状態のタブからプロファイラのサンプルを読み取り、同一のキャッシュスナップショットが1分間に2回、すべてメインスレッド上でIndexedDBに複製されていることを発見しました。

スレッドがどこへつながるのか、私たちにはほとんど予測がつきませんでした。CPUの不具合を調査していた際、Claudeは、完了したコードブロックをハイライトすると、ページが約1秒間フリーズしてしまうことに気づきました。ラボで詳しく調査した結果、原因が「長ダッシュ」であることが判明しました。返信のマークダウンに、長ダッシュやカーリークォートなど、Latin-1以外の文字が含まれている場合、V8は文字列全体をUTF-16として保存していたため、すべての構文ハイライト用正規表現が、処理速度の遅い2バイトモードで実行されてしまうことになっていた。Claude は、各コードブロックをハイライトする前に1バイトの文字列にコピーするという、20行の変更でこの問題を修正しました。

ページ上の最初のコードブロックを強調表示する

2週目になると、成果を毎日の進捗報告にまとめることさえやっとという状態になりました。最も忙しい日には、200件以上の変更がマージされました。Claudeは次々と新しいベンチマークを提案し続け、プルリクエストの約3分の1には追加のテレメトリやガードレールが含まれており、新しい計測ツールが導入されるたびに、さらなるスレッドが生まれ、新たな機会が広がっていきました。

1つのチャンネルで作業していたため、すべてがオープンに行われていました。私たちは互いのスレッドを行き来して、決定事項について議論したり、成果を祝ったりしました。その評判が広まり、他のチームもパフォーマンスのレビューを受けるために、変更内容をそのチャンネルに持ち込むようになりました。導入されたさまざまなガイドラインやClaudeのスキルのおかげで、新しいプロジェクトは、以前よりもわずかにパフォーマンスが向上した形で実装されるようになりました。

ガードレール

私たちはそのペースに備えていました。手がけたもののほぼすべてがホットパス（最初のペイント、コンポーザー、トランスクリプト）だったため、あらかじめ安全対策を講じておいたのです。すべてのPRは自動レビューを経て、少なくとも1人の人間による承認を受け、ユニットテストは常に最適化よりも優先され、ユーザーに目に見える問題を引き起こす可能性のあるものはすべて、短期間の機能フラグを適用した上でリリースされた。

フラグが次々と蓄積し始めたため、その導入と整理を調整するためのスレッドを開設しました。Claude では、すべてのフラグを「キルスイッチ」または「ランプ」に分類し、安全が確認され次第、それぞれを速やかに廃止しました。2週間の間に200件近くのフラグを導入しましたが、その半数以上は期間終了までにすでに整理済みでした。

また、変化の激しいコードベースではパフォーマンス上の改善効果がすぐに薄れてしまうこと、そしてAnthropicではコードのリリースサイクルが速いことも理解していました。あるプロジェクトで改善効果が実証されれば、その効果を維持するための対策に注力しました。例えば、静的コンポーザーは設計上、不安定なものです。そこで、ユーザーにはページのHTMLコピーをほぼ即座に表示し、Reactがその上に直接描画できるようにしています。

図B スタティックコンポーザー、変更前と変更後・4G通信速度制限時

Reactのレンダリングがたった1ピクセルでもずれてしまうと、その魅力は失われてしまいます。そこで、Claudeは数十もの安全策を講じました：

静的なマークアップは、実際のReactコンポーネントをjsdomでレンダリングすることで生成され、テストによってそれらが決してずれないことが保証されています。
統合テストスイートでは、14種類のビューポートサイズにおいて、静的ページとReactによるレンダリング結果を比較し、1ピクセル以内の位置合わせが保たれていることを検証します。
キーストロークテストは、ハンドオフをそのまま通過して実行され、キーが欠落したり順序が入れ替わったりした場合は失敗となります。
フィールド上では、ハンドオフのたびに10分の1ピクセル単位の移動が報告されます。Claudeは、移動量がゼロでないイベントが発生するたびにスレッドを起動します。

実験室ではすべてを網羅することはできなかったため、私たちは最も定石的な手法である「段階的な展開」も活用しました。リスクの高い変更は、まず従業員に、次にユーザーの1％、そして全員へと順次展開していきました。静的コンポーザーを社内でリリースしてから4時間後、あるチームメンバーが、どの指標でも検出できなかったレイアウトのずれを捉えた画面録画を共有してくれました。彼が新しいタブでclaude.aiを開くと、コンポーザーが崩れてしまうのですが、それは私たちのコードに起因するものではありませんでした。

マリウス：たまに、新しいタブで claude.ai を開いたときに、レイアウトが縦方向に少し（おそらく 15～20px 程度）ずれて（コンポーザーボックスが下に押し下げられてしまう）、ページを再読み込みしたときはそれほど気にならないのですが。何が原因なのかははっきりとは特定できていませんが、確かにその現象は発生しています。

Claude：録画映像で確認しました。これはChromeがページのサイズを変更しているものであり、静的コンポーザーから実際のコンポーザーへの引き継ぎではありません（今日の49回の読み込みすべてで、0ピクセルと測定されていました）。

実際の会話を基に再現したものです。

どういうわけか、Claudeはこの問題をChromeの「投機的読み込み」におけるエッジケースに突き止めました。ユーザーがアドレスバーにURLを入力している間、Chromeはバックグラウンドで、現在のタブの高さに合わせてページをプリレンダリングしていました。組織によって管理されているブラウザでは、フッターがあるため、新しいタブのページがわずかに短くなっています。ユーザーがEnterキーを押すと、claude.aiの最初のフレームにはそのわずかに短いレイアウトが表示され、Chromeは約0.1秒後にそのサイズを調整しました。Claudeはサイズ変更中もレイアウトを固定し、私たちはプリレンダリングの流れをシミュレートするテストを追加しました。

ステアリング

そのループは生産的ではあったが、自律的なものではなかった。それを高速かつ安全に、そして軌道に乗せ続けることが私たちの仕事であり、それは3つの部分から成っていた。

野心。本来、Claudeはスコープの設定に慎重です。問題点をリストアップし、実現可能性については慎重な姿勢をとり、見積もりには余裕を持たせます。しかし、私たちは自社の安全策に自信を持っていました。特に初期段階において、私たちが行ったことの多くは、Claudeに対し、より大胆になるよう後押しすることでした。

Claude：はい。Codeにも、ChatやCoworkにすでに実装されているのと同じタイミングマークを追加するための、小さなPRを1つ用意しました。今週中に提出します。現実的には、Code側の変更がマージ、デプロイ、そしてベースラインの更新期間を経て反映されるまで、数日かかるでしょう。

レイモンド：今すぐアップロードしてくれれば、私がマージしてデプロイするよ。僕たちなら何でもできる。もっと勇気を出してくれ

Claude：了解しました。プレスリリースは1時間以内に公開されます。

実際の会話を基に再現したものです。

設定した目標を達成し始めると、スレッドのペースが鈍り始めたことに気づきました。サムはスレッドごとに次のようなメッセージを送り続けました。「この勢いを維持してさらに削減していこう。目標達成がゴールではない。次は何をすべきか？　もっと野心的に考えよう。」

センス。すべてのスレッドには担当者が割り当てられており、Claudeでは、ユーザーが認識できる変更点については、変更前後のスクリーンショットや録画を提示して、担当者の判断を仰いでいました。テーブルはセルごとに順次表示すべきか、それとも各行が完成するまで待つべきか？ローディング中のスケルトンはすぐに表示すべきか、それとも0.5秒待ってから表示すべきか？ストリーミングされるテキストを単語ごとにフェードインさせる処理は、フレーム予算の5分の1を費やす価値があるか？『Claude』ではミリ秒単位の短縮策を模索し、そのトレードオフを慎重に検討しました。

方向性。各スレッドを意図的に狭い範囲に絞り、1つのベンチマークまたはジャーニーに焦点を当て、Claudeにはその範囲内でのみ改善点を見つけるよう依頼しました。私たちは、これらのスレッドを「釘を探す150本のハンマー」と捉えました。議論の大部分は、優先順位の決定やユーザーへの影響に関するものでした。具体的には、どの画面を優先すべきか、互いに干渉しているスレッドをどう統合するか、そして効果が頭打ちになったスレッドをいつ終了させるか、といった点について話し合いました。ある900行にも及ぶプルリクエストには、たった1行の返信が返ってきました。「送信ごとに2ミリ秒かかることを考慮しても、このビルドプラグインを維持する複雑さに見合う価値はないと判断した。」

8ミリ秒の予算

サイドクエストの一つでは、すべての要素が連携して機能している様子が示されています。ライブ構文ハイライトで使用される正規表現の最適化を実証するため、Claude氏は、ラボでストリーミング配信されている長い回答の画面録画を添付しました。画面の隅には、アニメーションフレームのタイムスタンプからページ内で計算されたフレームレートの表示が追加されていました。

レイモンド：これ、実はかなりヤバいベンチマークだね。60 fpsが上限なの？スクロールとストリームの滑らかさを120まで上げてみてくれない？私の理解が正しければ、君のPCでは対応していないかもしれないけど。

Claude：そうですね、今日の環境は60 Hzで動作しています。これは、ヘッドレス版のChromiumがデフォルトでそのように動作するためです。120 Hzでも動作するはずだと思います（VSyncの制限解除、またはDevToolsによるフレーム制御）。まずはそれを確認してから、8.3 msのフレーム予算で評価を再実行してみます。

Claude：120 Hz環境の最新情報：動作確認済み。 DevToolsのbegin-frame制御を用いたヘッドレスChromeでの決定論的な120 Hzフレームステップ — 8.33 msで240回のbegin-frameに対し、正確に240フレームが処理されるため、「このフレームが120 Hzの予算内に収まったか」という判断が、不確実なものではなく正確な値として読み取れるようになった。

レイモンド：すごい

料理

実際の会話を基に再現したものです。

仕組みと目標が定まると、Claudeは作業に取り掛かりました。描画される各フレームの処理時間は8.33ミリ秒に制限されていたため、Claudeは長いレスポンスをフレームごとに順に処理し、各フレームの処理時間を計測して処理が遅い箇所を特定しました。これにより、 O(message length) チャンクごとの処理を削減し、コードフェンスを拡張するためのトークン化ロジックをワーカーに移行し、テーブルをセル単位で公開しました。

その1つのスレッドで、私たちは60件近くのPRをマージしました。長い返信により、メインスレッドが合計で約200ミリ秒間ブロックされましたが、以前は750ミリ秒ほどブロックされていました。また、CPU使用率は約3分の1にとどまり、120 HzのMacBookでは開始から終了まで120 fpsを維持しました。この120 Hz環境の構築自体はナイトリージョブとなり、Claudeがリグレッションを監視するようになりました。

Claudeのウェブ版およびデスクトップ版における長文の回答の再生が、約4倍スムーズになりました。

ストリーミングレンダラーを再構築し、変化し続けている部分のみを処理するようにした結果、低スペックのノートPCでも長い返信による処理の停滞が9分の1に減り、最悪のフリーズ時間も4.5分の1に短縮されました。また、120Hz対応のMacBookでは、最初から最後まで120fpsを維持できるようになりました。

Xで表示

スプリントを始めた当初、ストリーミング中にフレーム間のミリ秒単位の時間を活用してヒルクライムを行う予定はありませんでした。しかし、実際にはその時間を計測できることが判明し、計測可能なものなら何でも、Claudeは登り切ることができたのです。

今後の展開

現在、claude.ai とデスクトップアプリの処理速度は、8月上旬に比べて約3倍速くなっており、この改善効果は今後も持続する見込みです。しかし、まだ改善の余地はあります。95パーセンタイル、その他の処理フロー、および非常に長い会話については、依然として改善の余地があります。別の記事では、このスプリント期間中に上流開発に貢献したいくつかのサイドプロジェクトについても紹介します。これには、Electron、Chromium、Node.jsなどへの貢献が含まれます。

社内でこの結果を共有した際、アイザックが次のように的確に表現してくれました。「6か月前なら、こんなことが可能だなんて到底信じられなかっただろう」。今後も、規模の大小を問わず、1つのスレッドずつ、このやり方で取り組んでいく予定です。このチャンネルは今も続いています。

アルフレッド・シン、アンソニー・モリス、ベンジャミン・パセロ、チェイス・マッコイ、ジョシュア・N、ルーク・ディーン・テイラー、マリウス・シュルツ、シェリー・ヴォール各氏にご協力いただきました。また、私たちにもっと野心を持つよう励ましてくださったボリス・チェルニー氏に、特に感謝申し上げます。