스크립트
00:00:00Claudeに自身の作業の評価を任せることはできません。これは大きな問題ですが、このスキルがそれを解決します。
00:00:05「Claudex Loop」と呼ばれるもので、やり方はシンプルです。Claudeにすべてを任せる代わりに、
00:00:09計画の立案、実行、そして自己評価をさせるのではなく、なぜCodexも呼び出して一緒に確認させないのでしょうか？
00:00:16Claudeの計画と実行を見て、「ここは良い、ここはダメだ、こうした方がいい」と言ってもらうのです。
00:00:22世の中のあらゆるAIモデルに共通する大きな問題の1つは、
00:00:25自分の仕事に対して非常に甘い評価を下すということです。Claudeに自分が作った計画の出来栄えを聞くと、
00:00:30「完璧です」と答えるでしょう。だからこそ、システムを導入することが重要です。
00:00:35第2の視点を持ち込んで、最初のモデルが構築したものを確認し、良し悪しとその理由を
00:00:40判断させることができます。本日は、このスキルの提供だけでなく、その仕組みや
00:00:44簡単なデモも紹介します。このスキルは4つのフェーズに分かれており、
00:00:48何らかの機能を追加する前や、まったく新しいグリーンフィールドのプロジェクトを始める際に呼び出します。
00:00:53一般的な流れとして、最初のモデルが考え出した計画や実行結果に対し、
00:00:58第2のモデルが「素晴らしい」と確認するまで、重要な作業を進めずに待ちます。
00:01:02まず第1フェーズでは、情報収集を行います。Claudeが実際にウェブ上で
00:01:07答えが存在するかどうかを偵察します。
00:01:10得られる回答をより深く掘り下げたい場合は、組み込みの動的ワークフローである「ディープリサーチ」を呼び出すオプションもあります。
00:01:15その次は、尋問（インターロゲーション）フェーズです。
00:01:20これは拡張された計画モードの一連の質問のようなもので、Claudeが最初の計画を立てる前に、
00:01:25認識を一致させようと試みます。次に、ここで2つ目のモデルを登場させます。
00:01:28これがレビュー段階です。私たちが話し合い、調査したすべてをもとに計画を立てた後、Claude Codeは
00:01:34標準的な「plan.md」を作成します。
00:01:38そこから、Codexが読み取り専用のサンドボックスでその計画をレビューし、
00:01:43「承認された」、あるいは「X、Y、Zを修正する必要がある」と伝えます。そしてその回答と修正案を
00:01:49Claude Codeに送り返します。Claude Codeはそれに目を通し、同意するかどうかを判断し、
00:01:55変更点を送り返します。このループは最大5回まで続きます。これまで、
00:02:015回に達しても承認状態に達しなかったことはありませんが、
00:02:065回で停止するように設定しています。変な無限ループに陥って永遠にトークンを消費し続けるのを防ぐため、
00:02:11スキル側で簡単に変更可能です。これにより明確な制限が設けられ、
00:02:15そのような状況に陥るのを防ぎます。最後に、ClaudeとCodexが合意に達し、計画が作成されたら、
00:02:20ビルドフェーズへと移行します。このスキルでは、Claudeにビルドさせるだけでなく、
00:02:24Codexにも構築作業を行わせることができます。しかし、どちらのモデルがビルドするにせよ、
00:02:30次のステップに進む前に、2つ目のモデルが実際に作成されたものをもう一度確認します。
00:02:34繰り返しになりますが、内部には調整可能なさまざまな変数があります。
00:02:38先ほど述べたように、レビューセクションは5回に設定されています。ビルドセクションでは、
00:02:43私たちが構築したものをCodexに確認させる回数を、無限ループのシナリオに陥らないよう、
00:02:48再び2回に減らしています。これまでのところ、「ここを増やす必要があるな」と感じるような問題には
00:02:52直面していませんが、調整することは可能です。さらに、必要に応じて、
00:02:56Codexの代わりにローカルモデルを持ち込むこともできます。
00:03:00前バージョンの「Grill Me Codex」を使用していた場合、Claudex Loopで注目すべき変更点は、
00:03:04さらに強化された尋問モードです。質問のラインがより深くなっています。
00:03:08また、実行フェーズではCodexがより統合されており、
00:03:13実際に作成されたコードに対しても目を光らせることができます。次は実際のデモですが、
00:03:18その前に、今日のスポンサーである私からの短いお知らせです。
00:03:23「Chase AI plus」内で提供している「Claude Code Masterclass」の
00:03:28完全アップデート版をリリースしました。ゼロからAI開発者になるためのナンバーワンの方法であり、
00:03:33特に技術的なバックグラウンドがない方に最適です。実際のユースケースに焦点を当てており、
00:03:38毎週アップデートされます。この素晴らしいツールのスキルを向上させたいけれど、
00:03:42ソフトウェア開発の背景がないという方にはぴったりの内容です。
00:03:47チェックしたい方は、固定コメントにあるリンクからどうぞ。さて、本日のデモでは、
00:03:51Claudex Loopを使って「Calendee」を再作成します。「Calendee」をご存知ない方のために説明すると、
00:03:56これはスケジュール調整用のウェブアプリで、リンクを共有すると相手がカレンダーを見て時間を選択でき、
00:04:00ZoomリンクまたはGoogle Meetを自動生成してくれます。多くの人が利用し、お金を払っているサービスです。
00:04:05しかし、自分で作れば月額10ドル（いくらか把握していませんが）の節約になるのではないかと考えました。
00:04:09そこで私がすることは、「/Claudex loop」と入力し、思いつくままにこう伝えることです。
00:04:13「Claudex Loopを使用して、独自のCalendeeバージョンを作成したい」と。
00:04:18現時点では、Zoomの代わりにGoogle Meetを使用させたいと思います。
00:04:25しかし、自分のカレンダーと連携させ、Calendeeの主要機能を基本的にすべて再現したいのです。
00:04:32それでは実行してみましょう。開始時、私たちはリサーチフェーズであるフェーズ0にいます。
00:04:38「このリサーチを実際どのように進めますか？」と尋ねられます。
00:04:41標準的なClaudeがいくつかのサブエージェントを派遣するウェブ検索にするか、
00:04:46本格的なディープリサーチにするかを選びます。このスキルでは、Opusを使用するようにピン留めしています。
00:04:50ご存知の通り、ディープリサーチを実行するとサブエージェントが呼び出され、利用枠を大量消費する可能性があります。
00:04:56そのため現時点では、便宜上あらかじめOpusで行うようにしています。
00:05:01ウェブ検索が推奨されていますが、正直なところ、どんな結果が返ってくるか見るためにディープリサーチを実行します。
00:05:05提案されるディープリサーチのプロンプトと、答えを得ようとしている質問が表示されます。
00:05:10Googleカレンダー、Meet、スケジュール管理領域の落とし穴、および一般的なスタックについて知る必要があります。
00:05:14それを承認する場合は「実行してください」と伝えるだけでよく、編集したい場合も非常に簡単です。
00:05:19Claudeがディープリサーチを完了し、「前提台帳（アシンプション・レジャー）」を作成しました。
00:05:25これは、このプロジェクトで発生させたいこととしてClaudeが想定しているすべてのリストです。
00:05:29この後、さまざまなパスに分岐できる追加の質問が提示されます。
00:05:36これらは「ここに大きな疑問はないと思う」という部分であり、
00:05:40「いいね」を押して計画に組み込むか、「いや、実際にはスタックを変更したい」
00:05:44あるいは「リマインダーの処理方法を変更したい」と伝えることができます。
00:05:48しかし今は、「これで確認完了です」と伝えて、
00:05:53いわゆる「耐力構造（ロードベアリング）」の階層へと移行します。
00:05:57「耐力」という言葉が好きですよね。今やClaudeがすることすべてにこの言葉が付けられています。
00:06:01そこで、耐力に関する質問に移行します。最初の質問は、
00:06:05「実際のカレンダーはどのGoogleアカウントにありますか？」というものです。
00:06:09プロジェクトに関わらず、これらの質問にはすべて、推奨事項とともに一連の質問が提示されます。
00:06:13見当がつかない場合は、推奨事項に従えば問題ありません。しかしベストプラクティスとして、
00:06:17潜在的な回答や何が起きているのかについて、Claudeが言っている意味が全く分からない場合は、
00:06:23別のセクションに進み、「これについてさらに詳しく説明して」と伝えることを強くお勧めします。
00:06:27そうしてこそ、AIや開発において成長でき、推奨されたものをただ受け入れるだけの
00:06:32「承認モンキー」にならずに済むのです。分からないなら、
00:06:35自分が理解できるまでClaudeに説明し続けるよう頼んでください。
00:06:40それが真に学ぶ唯一の方法ですが、今回の動画の主旨からは少し外れます。
00:06:44そのため個人用Gmailを使用します。このフェーズの仕組みはお分かりいただけたと思うので、
00:06:49すべての質問に答えた後の場面までスキップします。
00:06:53耐力に関する質問に答えた後、アプリケーションの基本機能を変更しない
00:06:58いくつかの「外観に関する決定事項（コスメティック・ディシジョン）」に移行します。
00:07:02このシナリオでは、前提台帳と同様にすべてがリストアップされます。
00:07:08そのため、「これで問題ない」としてそのまま進めることも、「1番や2番、その他を変更してほしい」と
00:07:12伝えることもできます。このプロセスをスピードアップできるように、このように設定しています。
00:07:16これらの外観に関する質問に答えたら、フェーズ2に移行します。Claudeが
00:07:20「plan.markdown」ファイルを書き、それがGPT-5.6 Solを使ったCodexに送信されます。
00:07:27そこから、承認された判断に達するまで最大5ラウンドのやり取りが行われます。
00:07:32ClaudeとCodexは5ラウンドにわたってやり取りを行いました。最初、ラウンド1では27件の課題が
00:07:37提起され、ラウンド5に到達したものの、まだいくつかの問題が残っており、
00:07:43承認された判断には至っていません。以前、これが起きたことは一度もないと言いましたが、
00:07:47今回ここで起きたのは良かったと思います。5ラウンドに達しましたが、まだ解決していません。
00:07:51いくつかの細かい問題が残っています。どうしたいですか？選択肢はあります。
00:07:56ここで停止して現状維持にするか、デッドロック状態を受け入れるか、あるいは2ラウンド延長するかです。
00:08:012ラウンド延長することにします。そうして最終的にどうなるか
00:08:05見守りましょう。ただ、このような厳しい制限、
00:08:11例えば5ラウンドという制限があったとしても、そこで行き詰まるわけではないということがお分かりいただけたかと思います。
00:08:15今回のように、簡単に延長することができるのです。7ラウンドを経て合意に至り、
00:08:19次は実際にこれをどちらに構築させるかという選択になります。
00:08:24Claudeに構築させてCodexに確認させることもできますし、逆にCodexに構築させてClaudeに確認させることもできます。
00:08:29状況や作業内容によっては、共同ビルドという選択肢が提示されることもあります。
00:08:33例えば、アセット生成やGPT画像などを組み込む必要があるものを
00:08:38作成している場合、「この特定のプロジェクト部分にはCodexを投入しよう」といった提案がなされます。
00:08:43しかし今回は、Claudeに構築してもらう形にします。そして、いわゆる
00:08:47「オープンブック」の作成が始まります。これにより、Claudeはカレンダーのデモの作成を完了させることができます。
00:08:51今画面で見ているのがそれです。それでは、実際に動くか確認してみましょう。
00:08:55その後で、Codexがこのプロセス全体にどのような影響を与えたのかを詳しく見ていきます。導入用の通話と、実際の作業セッションがあります。
00:09:01導入用通話に移動すると、私のGmailカレンダーと実際に同期されている様々な時間やスケジュールを確認できます。
00:09:07例えば、31日の日程を選択するとしましょう。10時を選びます。
00:09:12名前を追加し、メールアドレスを入力します。そして予約の確定を行います。
00:09:23参加リンク付きのメールが届いたことが確認できます。また、カレンダー全体も見ることができますし、
00:09:28シンプルな成果物も作成するようにしました。コードデックスがこのプロセス全体に
00:09:33どのような追加をもたらしたかを視覚的に分解するものです。先ほどお話しした、
00:09:38Claudeが計画を持ち、コードデックスが調整や提案を行ったあのやりとりの段階は、
00:09:42最初は27件の問題から始まり、ラウンドを重ねるごとに減っていき、ラウンド7でようやく承認された評決に至りました。
00:09:48それでは、計画段階でCodexが実際にClaudeの注意を促した点についていくつか見ていきましょう。
00:09:52ダブルブッキングの制約がコンパイルできないといった問題や、
00:09:57コンパイルできない問題や、OAuth連携フローの不具合などが挙げられます。さらに並行処理の問題として
00:10:03並行処理の問題など、エッジケースに関する多くの事項が次々と挙げられました。
00:10:08構築フェーズでは、7ラウンドを経て改善された計画をClaudeが実装しました。
00:10:12その後、完全にまっさらなメモリと新しいコンテキストウィンドウを持つ新しいCodexセッションが立ち上がりました。この時点では計画を読んでいません。
00:10:17そして、実際の仕様、つまり実際に作成されたものと計画されたものを照らし合わせてコードを読み込みました。
00:10:23その結果、23件の指摘事項が上がり、19件が採用されて修正され、4件が却下されました。
00:10:29この構築フェーズでCodexが発見した問題には、会議のたびにタイムグリッドがずれていくことや、
00:10:34管理トークンがプレーンテキストのまま置かれていたこと、すべてのイベントが誤った時間をブロックしていたことなどがあります。
00:10:39これらもまた、エッジケースだと言えるかもしれませんが、Claudeがこれらを発見するには
00:10:44相当な時間がかかったはずです。もし最初からCodexが関わっていなかったとしたら、
00:10:48どうなっていたでしょうか。機能が壊れていたり、データベースにしか存在しない予約が発生していたりしたことでしょう。
00:10:53もっとも、Claudeだけに頼っていた場合でも実際こうなっていたかというと、おそらく最初はさらに試行錯誤を重ね、
00:10:58最終的には動作するものにたどり着いていたとは思います。
00:11:03しかしCodexのおかげで、こうした多くの問題を計画段階で発見することができました。
00:11:08その結果、後からトークンを無駄に消費せずに済みました。また、
00:11:14本番環境に移行する前に、Codexを使ってこれらのテストや確認を行うことができました。総合的に見て、
00:11:21これにより時間とコストを大幅に節約できます。これが「Claudexループ」の実践です。
00:11:26これらを手に入れたい場合は、固定コメントにリンクを掲載しておきます。それでは、またお会いしましょう。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기