00:00:00Claude Codeは昨年の5月22日、Claude 4のリリースと同時に一般公開されました。
00:00:06しかし、その前にはリサーチプレビュー期間もありました。なので私はこのツールを
00:00:111年以上使い続けています。実際に計算してみたのですが、
00:00:15Claudeへのプロンプト入力、コードの確認、監視に費やした全時間を合計すると、
00:00:21これまでに2,000時間以上も使用してきました。ですから、皆さんに教えられることが山ほどあります。この動画ではそれをお伝えしたいのです。
00:00:27今から、皆さんに私の「実戦で鍛え抜かれた戦略」をすべて共有します。これを使えば、
00:00:31Claude Codeの初心者から一気にパワーユーザーへと駆け上がれるはずです。それらをすべて
00:00:37「WISCフレームワーク」という形にまとめました。ここで重要なのは、これらの戦略が本物だということです。私は、
00:00:43ここ数ヶ月で急にClaude Codeの流行に乗っただけのAIコンテンツクリエイターではありません。
00:00:48先ほど言ったように、1年以上毎日このツールを使い込んできました。ですから、これらの戦略は
00:00:54どんなコードベースでも、たとえ大規模なものや複数のコードベースにまたがるプロジェクトでも通用します。
00:01:00エンタープライズレベルでの適用も見てきましたので、皆さんが何に取り組んでいても役立つはずです。また、
00:01:05これは他のAIコーディングアシスタントにも応用可能です。今はClaude Codeが最高なので、これに焦点を当てているだけです。
00:01:10ここでは、皆さんがClaude Codeの基礎を理解しており、
00:01:15さらに上のレベルを目指したいと考えていることを前提としています。AIコーディングのためのシステム構築の基礎については、
00:01:21別の動画がありますので、ここにリンクを貼っておきます。今回の戦略は、
00:01:25実際の、そして複雑になりがちなコードベースを扱うためのものです。というのも、
00:01:32「コンテキスト管理」に関する戦略を多数用意しているからです。これは非常に重要です。なぜなら、「コンテキストの劣化」こそが、
00:01:38現在のAIコーディングアシスタントにおける最大の問題だからです。Claude Codeに100万トークンの制限が導入されたとしても、
00:01:43コンテキストは最も貴重なリソースとして、慎重に設計（エンジニアリング）しなければならないことに変わりはありません。
00:01:49WISCフレームワークのW、I、S、Cは、すべてこの戦略に当てはまります。そして、
00:01:56これらはすべて、皆さんのプロジェクトにすぐに適用できるものばかりです。
00:02:00ですから、ここでは分かりやすくシンプルに解説していきます。さて、皆さんが疑問に思うのは、
00:02:05「コール、なぜそんなにコンテキスト管理にこだわるんだ？」ということでしょう。
00:02:11「2,000時間も使って、焦点を当てるのがそこなのか？」と。私の答えは「イエス」です。
00:02:17かなり専門的な話に聞こえるかもしれませんが、今こそコンテキストの劣化とその回避方法に注力すべきなのです。
00:02:23コーディングエージェントがコードベースで失敗する原因の約80%は、
00:02:28コンテキストを十分に管理できていないことにあります。まずはコンテキスト劣化の問題から始め、
00:02:33すぐにWISCフレームワークの各パートの詳細に入っていきます。ただ、その前に前提としてコンテキスト劣化について話すのは、
00:02:38その理由をしっかり理解してほしいからです。WISCフレームワークを適用すれば、
00:02:45複雑なコードベースであっても、AIコーディングの信頼性が一気に向上するのを実感できるはずです。
00:02:50大規模で複雑なコードベースを強調し続けるのは、まさにそこでコンテキストの劣化が
00:02:56大きな問題になるからです。さて、業界ではコンテキスト劣化について
00:03:02多くの研究がなされていますが、私のお気に入りで、最も実用的かつ人気があるのは
00:03:07「Chroma Technical Report」です。これは、入力トークンの増加がLLMのパフォーマンスにどう影響するかを扱っています。
00:03:13その核心は、「LLMのコンテキストウィンドウに一定量のトークンが入るからといって、
00:03:18それをすべて詰め込むべきではない」ということです。これは100万トークン制限のClaude Codeにも当てはまります。
00:03:24なぜなら、大規模言語モデル（LLM）も人間と同じように、情報が多すぎると圧倒されてしまうからです。
00:03:30これは「干し草の山から針を探す（Needle in a Haystack）」問題と呼ばれます。特定の情報、
00:03:35あるいはコーディングエージェントが読み取った特定のファイルを思い出させる必要があるとき、
00:03:41コンテキストウィンドウが埋まりすぎていなければ、短期メモリからうまく情報を引き出すことができます。
00:03:47しかし、コンテキストが膨大になると、「ディストラクター（邪魔者）」と呼ばれるものが現れ始めます。
00:03:52これは、LLMに思い出してほしい情報と似ているけれど、
00:03:58微妙に異なる情報のことです。AIコーディング、特に大規模なコードベースではこれがよく起こります。
00:04:04コードベース全体で同じようなパターンを使い回しているため、
00:04:09実装の異なる部分で多くの類似点が生じます。その結果、LLMは
00:04:14誤った情報を引き出してしまい、しかもその修正や実装に絶対の自信を持って提示してくるのです。皆さんも
00:04:19よく目にする光景ではないでしょうか。この「針探し」の問題は、
00:04:24AIコーディングにおいて常に発生しています。これがコンテキスト劣化の概念です。
00:04:30ウィンドウが大きくなればなるほど、エージェントがその瞬間に必要な情報を正確に
00:04:36引き出すのが難しくなります。図に戻って、具体的に説明しましょう。
00:04:42これらの戦略が解決しようとしているのは、「エージェントに必要なコンテキストをすべて与えつつ、
00:04:48いかにコンテキストウィンドウを最小限に保つか」という問いです。これこそが
00:04:53私たちがここで行うコンテキスト・エンジニアリングです。これから一つひとつの戦略を説明していきます。
00:04:57それぞれの例を、複雑なコードベースを使ってライブでお見せします。
00:05:02例として使用するコマンド、ルール、ドキュメントはすべて、概要欄にある
00:05:06リンク先のフォルダにまとめてあります。概念としてだけでなく、
00:05:12この「.claude」フォルダにあるコマンドを例として実際に活用してみてください。では、
00:05:17個別の戦略を見ていきましょう。WはWrite（書く）、IはIsolate（隔離する）、SはSelect（選択する）、CはCompress（圧縮する）です。
00:05:24まずはWの「Write」、つまりエージェントのメモリを外部化することから始めます。
00:05:30主要な決定事項や作業内容をできるだけ記録し、
00:05:34将来のセッションでエージェントを素早く同期させ、
00:05:40本当にやってほしいことを理解させるためのトークン消費を抑えるのが目的です。そして最初の戦略は、
00:05:46「git logを長期メモリとして使う」ことです。これが最高なのは、
00:05:52世の中にはコーディングエージェントのために超複雑なメモリ・フレームワークを作りたがる人が多い中、
00:05:56実際には誰もがすでにバージョン管理にgitやGitHubを使っているからです。つまり、
00:06:01既にあるツールを活用してエージェントに長期メモリを提供できるのです。では、
00:06:07実際のコードベースでどういうことかお見せしましょう。今回、
00:06:12すべての例で使用するコードベースは、新しい「Archon」です。ここ数ヶ月、
00:06:18舞台裏で必死に作り込んできました。これは、より長期間実行されるAIコーディングワークフローを
00:06:23作成、管理、実行できる「AIコマンドセンター」です。現在はワークフロービルダーも開発中です。
00:06:28AIコーディング界の「n8n」のような存在になるでしょう。ワークフローを開始したり、
00:06:33ミッションコントロールでログを監視したりできます。過去の実行履歴を見て、
00:06:39何が起きたか正確に確認することも可能です。これはコードベース全体のプルリクエストを検証するための
00:06:44非常に長いワークフローの例です。Archonの詳細は近日公開予定ですが、これを見るだけでも
00:06:47多くの可動パーツがあることが分かるでしょう。非常に複雑なコードベースです。ですから、
00:06:51これから紹介するすべての戦略を説明するのに最適な例となります。
00:06:57gitを長期メモリとして使う方法ですが、ここに最近の全コミットメッセージを
00:07:03一行で表示する例を出します。
00:07:09ここで注目してほしいのは、コミットメッセージの作成方法が非常に標準化されている点です。マージだけでなく、
00:07:13機能の実装や修正もすべて含まれています。形式を標準化している理由は、
00:07:19コミットメッセージを頼りに「最近何を作ったか」をエージェントに伝えられるからです。
00:07:24次に何をすべきかの指針になることが多いですからね。なぜここまで
00:07:29標準化できているかというと、「commit」コマンドを実行しているからです。単なる「git commit」は簡単ですが、
00:07:36メッセージを標準化し、エージェントにその補助をさせるなら、
00:07:40専用のコマンドを持つことが非常に強力です。これは、エージェントとの
00:07:46単一のコンテキストウィンドウで行った実装の全記録です。今、実装が終わり、
00:07:51コミットする準備ができました。ここで「/commit」を実行するだけです。すると、
00:07:55作業内容をどう記録するかという標準化されたルールに基づいたコマンドが走ります。さらに、
00:08:01ルールやコマンドの改善点も記録されます。つまり「何を作ったか」と「AIレイヤーをどう改善したか」の
00:08:06二部構成のコマンドです。これでコミットが作成されます。中身を見てみましょう。
00:08:10コミットメッセージを見ると、CLIのテストが改善されたことがわかります。
00:08:14適切なプレフィックスの後に詳細が続き、さらに、
00:08:19エージェント自身が自分のルールやコマンドがどう進化したか把握できるように、
00:08:23例えば「plan」コマンドを改善した際などは、その内容もコミットメッセージに含めます。
00:08:29もちろん、この「commit」コマンドもリポジトリのリソースとして用意しています。
00:08:33出発点として使っていただきたいですが、ご自身の環境に合わせて
00:08:37カスタマイズすることをお勧めします。重要なのは、メッセージを詳細かつ標準化し、
00:08:41長期メモリとして使えるようにすることです。さて、2つ目の「Write」戦略は、
00:08:47「コードを書くときは常に新しいコンテキストウィンドウから始める」ことです。何に取り組むにせよ、
00:08:53私のワークフローは常にこうです。まずエージェントと1つの会話で「計画」を立てます。
00:08:57構造化された計画を含むMarkdownファイルを作成し、それを「唯一のコンテキスト」として
00:09:03新しいセッションに読み込ませて実装に入ります。ここで重要なのは、
00:09:08その仕様書に、コード作成と検証に必要な全コンテキストが含まれていることです。例えば、この会話では
00:09:14計画だけを行っています。まず「prime」を実行して…これについては後で話します。
00:09:18コンテキストを読み込み、このコマンドで計画を作成します。これも
00:09:24リソースとして提供しているものです。これは本質的に、エージェントに対し、
00:09:28「単一のMarkdownドキュメントとして作成すべき正確な構造」を指示するものです。短期メモリから
00:09:331つの文書へと移行させるわけです。そして、ここでセッションを終了します。まっさらな
00:09:38コンテキストウィンドウを開き、実装に移ります。ここで「execute」コマンドを使い、
00:09:42作成した計画ファイルへのパスを指定します。他のコンテキストは一切入れません。この計画に必要なすべてが
00:09:48詰まっているはずだからです。これにより、エージェントを目の前のタスクに極限まで集中させることができます。
00:09:53計画と同じ場所で実装を行うと、調査内容などが混ざってコンテキストが濁ってしまいます。
00:09:57エージェントのメモリを外部化する最後の「Write」戦略は、
00:10:03「進捗ファイルと決定ログ」です。より洗練されたAIコーディングフレームワークでは、
00:10:08「handoff.md」や「todo.md」を使って、サブエージェント間やチーム、
00:10:13あるいは単に異なるセッション間でやり取りをするのをよく見かけます。
00:10:17コンテキストが少なくなってきたら、今終わったことの要約を作成するのが定石です。
00:10:22会話が長引いてエージェントが幻覚（ハルシネーション）を見始める前に、
00:10:27新しいセッションに移行するためです。もちろん、長い会話自体を避けるのが理想ですが、
00:10:33どうしても必要な場合もあります。例えば、Archonの開発でよくやるのは、
00:10:38Vercelのagent-browser CLIを使って、ブラウザ内でのエンドツーエンド（E2E）テストを実行させることです。
00:10:44様々なユーザージャーニーやエッジケースのテストをさせるため、
00:10:49膨大なコンテキストを消費します。下の表示を見ると、すでに対話だけで20万トークン、
00:10:56100万トークンの制限に対しあっという間に埋まってしまいます。そして数万、
00:11:01数十万トークンを超えたあたりから、エージェントのパフォーマンス低下が顕著になります。そこで、
00:11:05「/handoff」を実行します。このコマンドは要約を作成し、それを次のセッションに引き継ぐことで、
00:11:11別のエージェントが作業を続行できるようにします。これにより、新しいエージェントは
00:11:16ウィンドウ内に何十万トークンもの過去のツール実行履歴などを抱え込まずに済みます。
00:11:21このハンドオフ・コマンドは、次に必要な情報を文書化するプロセスを
00:11:25定義しているだけです。これでWのセクションは終了です。各戦略は、
00:11:31将来のセッションで素早く再開するために、重要な決定を記録するという点で非常に重要です。
00:11:36かなり早足で説明していますが、もし詳しく動画にしてほしい
00:11:40特定の戦略があれば、コメント欄で教えてください。どれも1本の動画になる内容ですから。
00:11:45さて、次はIの「Isolate（隔離する）」、サブエージェントの活用です。
00:11:52私はあらゆるリサーチにおいて、ほぼ毎セッションでサブエージェントを愛用しています。
00:11:56ここで重要なのは、「メインのコンテキストをクリーンに保つ」ことです。サブエージェントを使えば、
00:12:03コードベースやWeb全体にわたる数万、数十万トークン規模の調査を任せることができ、
00:12:10その必要な要約だけをメインのClaude Codeウィンドウに持ち込めます。つまり、
00:12:16メインウィンドウに数万トークンの調査結果を詰め込む代わりに、500トークン程度で済むのです。
00:12:21必要な核心情報は得つつ、Anthropicの研究によれば、メインエージェントにすべてをやらせるより、
00:12:28サブエージェントに事前調査を行わせることで90.2%もの効率改善が見込めます。
00:12:33簡単な例をお見せしましょう。これは会話の最初、あるいは先ほどの
00:12:38計画プロセスの前に行います。私はここでサブエージェントを多用します。見ていてください。
00:12:43「Archonにワークフロービルダーを組み込みたい。
00:12:502つのサブエージェントを立ち上げてくれ。1つはコードベースを徹底的に調査し、
00:12:55ワークフロービルダーの実装方法と、それがArchonにどう影響するかを確認する。もう1つは、
00:13:01このテックスタックにおけるベストプラクティスをWebで調査してくれ。Reactを使うなら
00:13:06どのライブラリが最適か、Diffyやn8nのようなビルダーをどう作るべきかを調べてくれ」
00:13:12音声入力ツールでプロンプトを飛ばします。これでOK。
00:13:16隔離のメリットだけでなく、「スピード」も得られます。サブエージェントが並列で走り、
00:13:21要約を持って戻ってきたら、メインエージェントがそれを統合して最終判断を下すからです。
00:13:26ご覧の通り、2つのサブエージェントが裏で並行して動いています。それぞれのログを確認することも可能です。
00:13:31調査が終われば、最終レポートが提出されます。
00:13:36サブエージェントが完了しました。メインウィンドウで数十万トークン消費する代わりに、
00:13:41（これはサブエージェントが実際に調査で消費した量ですが）
00:13:46メインでは44,000トークン、わずか4%の消費で済みました。これがサブエージェントの力です。
00:13:53実装にはお勧めしません。実装時は全コンテキストが必要だからです。しかし、
00:13:57リサーチにおいては極めて強力です。隔離とサブエージェントは計画プロセスにおいて非常に重要です。
00:14:04もう一つの使い方は、私が「スカウト・パターン」と呼んでいるものです。
00:14:09メインのコンテキストを確定させる前に、「偵察隊」を送り出すわけです。コードベースや
00:14:14ドキュメントの一部が、メインのClaude Codeセッションに
00:14:21読み込む価値があるかどうか、事前にサブエージェントに探らせます。つまり、
00:14:25「これは重要だから読み込むべき」「これは関係ないから飛ばそう」という判断を事前に行わせます。
00:14:30例えばArchonには、コードベースの特定の部分を深く掘り下げたMarkdownがいくつかあります。
00:14:36常に必要ではないので、通常のルールには含めたくない内容です。でも、
00:14:41たまに読み込みたい時があります。ConfluenceやGoogle Driveにある資料を想像してみてください。
00:14:45このメインの会話に戻って、
00:14:48「サブエージェントを立ち上げ、.claude/docs内をすべて調査してくれ。
00:14:54計画のためにメインコンテキストに読み込むべき重要なドキュメントはあるか？」
00:14:59と指示します。エージェントが判断し、必要なものだけを読み込みます。ほら、
00:15:04ここで「explore」サブエージェントが起動しました。全文書をチェックし、1つの読み込みを推奨してきました。
00:15:09私が「了解、読み込んで」と言えば完了です。これは計画において非常に重要です。
00:15:13単なる調査だけでなく、メインウィンドウに必須だと思われる
00:15:18ドキュメントの選別にも、この「スカウト・パターン」が有効です。
00:15:23以上が「隔離」に関する話です。リサーチと計画において
00:15:28サブエージェントを徹底的に活用することを忘れないでください。そして次はSの「Select（選択する）」です。
00:15:34コンテキストは「念のため」ではなく「今まさに必要」な時にだけ読み込みましょう。
00:15:40ある情報が今エージェントに必要だと100%確信できないなら、読み込むべきではありません。
00:15:46これを実現するために、階層的なアプローチをとります。まずは「グローバル・ルール」から。
00:15:51これは、エージェントに常に意識しておいてほしい制約や慣習です。
00:15:57このファイルは簡潔にする必要があり、私は通常500〜700行程度に収めています。
00:16:02もっと少なくすべきと言う人もいますが、アーキテクチャや実行コマンド、
00:16:08テストやログの戦略などを記述します。これはArchonの例ですが、
00:16:12エージェントが常に把握しておくべき基本的な事項です。そして第2層は、
00:16:18私が「オンデマンド・コンテキスト」と呼んでいるものです。これは特定の作業時にのみ適用されるルールです。
00:16:23例えばフロントエンドの作業中なら（常にではありませんが）、
00:16:28フロントエンド用のグローバル・ルールや、APIエンドポイント作成用のルールを追加します。
00:16:33特定のタスクタイプに合わせて、基本ルールにこれらを上乗せするわけです。
00:16:38例を挙げると、先ほどエージェントが持ってきたワークフローのYAMLリファレンスがそれにあたります。
00:16:43ワークフローをいじっている時は重要ですが、そうでない時は不要です。
00:16:48Archonの開発中、常にこの特定の部分を触っているわけではないので、
00:16:52基本ルールには含めません。これが「オンデマンド・コンテキスト」です。そして
00:16:57第3層は「スキル」です。これは現在、Claude Codeの内外で非常に人気があります。
00:17:05段階的なアプローチをとっており、エージェントが実際に必要だと判断した時にのみ、
00:17:10そのスキルの指示や機能を探索します。まず、
00:17:15基本ルールと共に非常に少量の「スキルの説明」が読み込まれます。
00:17:20エージェントがそのスキルを使いたいと決めたら、そこで初めて「skill.md」の全文が読み込まれます。
00:17:25さらに深く掘り下げる場合は、そこから他のスクリプトや参照ドキュメントへとリンクされます。
00:17:29例として、私の「agent-browser」スキルを紹介します。これは、
00:17:35先ほどお見せしたE2Eテスト用のブラウザ自動化に使っているものです。毎日使っています。
00:17:40E2Eテストを行う時だけ、この指示セットを読み込ませることで、
00:17:46エージェントにブラウザの使い方を理解させます。最後に第4層として、
00:17:52「prime」コマンドがあります。これまでに紹介したのは、たまに更新する静的なドキュメントですが、
00:17:57時にはライブのコードベースを探索させる必要があります。
00:18:02情報が完全に最新であることを保証する必要がある場合、事前にサブエージェントにトークンを割いて実行させます。
00:18:07それが「prime」コマンドの役割です。
00:18:11計画プロセスの最初にコードベースを探索させ、何を作るべきか理解させるわけです。
00:18:16ご覧の通り、commandsフォルダには多くの「prime」コマンドがあります。
00:18:22作りたいものに応じて、理解させたいコードの部分が異なるからです。
00:18:27これが汎用的な「prime」コマンドの例です。
00:18:32Archonのコードベースをハイレベルで把握するよう指示しています。
00:18:36git logを含め、何を読み込むべきかステップバイステップで記述されています。
00:18:41git logは長期メモリとして使うために重要ですからね。また、特定のエンジンをいじる時のための
00:18:47特化型コマンドもあります。これを会話の最初に実行することで、
00:18:53エージェントが必要なものを即座に読み込めるようにします。コードを理解したことを確認してから、
00:18:58先ほどお見せした計画プロセスに入ります。まとめると、
00:19:03グローバル・ルールは常にロード。オンデマンド・コンテキストは、
00:19:09特定の文書化されたパーツを触る時にロード。スキルは、
00:19:13特定の機能（E2Eテストなど）が必要な時にロード。
00:19:18そしてprimeコマンドは、計画を立てるための土台作りのために、
00:19:22会話の最初に実行します。以上が「Select」についてでした。さて、
00:19:28最後は「Compress（圧縮する）」です。ここは一番短いセクションになります。なぜなら、
00:19:34Write、Isolate、Selectが正しくできていれば、圧縮はほとんど必要ないからです。
00:19:39コンテキストをスリムに保つ戦略をとっていれば、圧縮自体を避けられます。
00:19:46圧縮は可能な限り避けるべきものですから、これは良いことです。どうしても圧縮が必要な場合は、
00:19:522つの戦略があります。それは
00:19:56「ハンドオフ」と「フォーカス・コンパクション（重点圧縮）」です。Claude Codeを見てみましょう。
00:20:02「ハンドオフ」については「Write」ですでに説明しました。今やったことをすべて要約し、
00:20:06別のエージェント（またはメモリ圧縮後の同じエージェント）に引き継ぐ方法です。そしてもう一つ、
00:20:12Claude Codeには組み込みの「/compact」コマンドがあります。これは会話を要約し、
00:20:18履歴を消去して、その要約をコンテキストウィンドウの先頭に配置します。
00:20:23ハンドオフは、情報の記憶方法を独自のワークフローとして定義できるので非常に強力です。
00:20:28ただ「/compact」も便利で、特に要約の仕方を指示できる点が優れています。
00:20:34どうしても圧縮が必要なときは、必ずこれを使います。例えば、
00:20:41「今テストしたエッジケースに焦点を当ててくれ」のように。そうすれば、
00:20:48エージェントは短期メモリの特定の部分により注意を払って要約を作成します。スペルが少し違っても
00:20:53大丈夫です、そのまま実行してくれます。ハンドオフと「/compact」は、どちらか一方を使うことが多いですが、
00:20:58両方を組み合わせて使う場面もあります。特に圧縮を2回以上繰り返す必要があるなら、
00:21:03会話が肥大化しすぎている証拠なので、ハンドオフを使って新しいセッションを始めるべきです。
00:21:091回きりなら「/compact」で十分でしょう。ただ、
00:21:14圧縮した後でも、エージェントが本当に正しく理解しているか、
00:21:19「何を覚えているか教えてくれ」といった形で確認するようにしています。
00:21:24理想的ではありませんが。圧縮は極力避けてください。最高の圧縮戦略は、圧縮を不要にすることです。
00:21:30以上が「WISCフレームワーク」です。
00:21:36盛りだくさんでしたが、役に立ったなら嬉しいです。さらに深掘りしてほしい
00:21:41特定の戦略があれば教えてください。1つだけで動画が作れるレベルですから。
00:21:46これがWISCフレームワークです。皆さんがClaude Code、
00:21:52あるいは他のAIコーディングアシスタントを使いこなす助けになれば幸いです。
00:21:59この動画が参考になり、今後もAIコーディングや
00:22:04実践的なフレームワークについて知りたい方は、ぜひ高評価とチャンネル登録をお願いします。
00:22:09それでは次の動画でお会いしましょう。あ、最後にもう一つだけ！見逃せないお知らせがあります。
00:22:144月2日、私のYouTubeチャンネルで「AIトランスフォーメーション・ワークショップ」を無料ライブ開催します。
00:22:20CTOXの創設者であるLior Weinstein氏も一緒です。これは大きなイベントになります。
00:22:27Liorは組織全体のAI化について、私は信頼性が高く再現性のある
00:22:32コーディングエージェント・システムを構築するための、私のAIコーディング手法をすべて伝授します。
00:22:38概要欄に特設ページのリンクを貼っておきます。私のチャンネルでライブ配信しますので、
00:22:42このボタンから通知をオンにしておいてください。当日お会いしましょう！