6,631 文字
今回も端末で動作する軽量なコーディングエージェントを紹介します。おそらく約1ヶ月前、このチャンネルでClaude Codeエージェントを紹介し、Cloudflare Workersアプリケーションを構築するために私たちのプロンプトツールを使用しました。これは約1,300行、おそらく1,400行ほどの特定のプロンプトで、これらのエージェントがCloudflare Workersアプリケーションを作成するのを助けるものです。そして今日は、数時間前にオープンソース化されたばかりのOpenAIのCodeex（新しいコーディングエージェント）を使って同じことをやってみたいと思います。インストール方法などの情報は説明欄にリンクを貼っておきます。GitHubのリポジトリも貼っておくので確認してみてください。何を構築するかはまだ決まっていませんが、色々と試してみて、何が面白いか見てみましょう。
まずはターミナルに入って、「npm create cloudflare@latest」を実行します。これがCloudflareウィザードで、さまざまなテンプレートを使ってCloudflareアプリケーションを作成できます。これを「codeex-openai-test」と名付けて、ここで進めていきましょう。「application starter」を選択して、何か面白いことをやってみましょう。「Workersで基本的なAPIの構築を始める」というのはいいですね。「OpenAPI準拠」も素晴らしいです。これによりテンプレートがクローンされ、依存関係がインストールされます。また、Cloudflare Workersアプリケーション用のコマンドラインツールであるWranglerもインストールされます。
Gitの使用には「はい」と答え、今すぐアプリケーションをデプロイするかには「いいえ」と答えます。それからこれをZellageに入れて、複数のタブやペインなどをマルチプレックスできるようにします。開発モードで実行すると「npm run dev」、これが現在localhost:8787で実行されていることがわかります。それを開いてみると、デフォルトでOpenAPIルートがあります。OpenAPIとOpenAIが同じプロジェクトにあると混乱するかもしれませんが、できるだけ明確に説明します。ここにはタスクのリスト化、タスクの作成などのすべてのルートが表示されています。
次にCodexを使ってみましょう。「npm i」を実行してグローバルに「@openai/codeex」をインストールできますが、私はプロジェクトのdev依存関係としてインストールするだけにします。「npm i -D」で依存関係としてインストールします。インストール後、「npx codeex」を実行すると、OpenAI APIキーが不足していることがわかります。そのキーを取得して、「export OPENAI_API_KEY=」として設定します。そのAPIキーをカメラの外で取得して入力します。
キーを設定して履歴をクリアしたので、「npx codeex」を実行します。すでに起動していて、いくつかのモデルが表示されています。新しいはずの「o4-mini」を使用しています。作業ディレクトリは「developer/codeex-openai-test」です。
ここでプロンプトを行う方法を考える必要があります。セットアップのための多くのオプションがあります。セキュリティモデルの設定など、単に何でもできるようにするか、承認を必要とするかを選べます。また、メモリとプロジェクトドキュメントもあります。「codeex.md」をリポジトリのルートまたは現在の作業ディレクトリにサブパッケージの詳細を記述できます。このプロンプトを探して全体をコピーし、「codeex.md」に貼り付けます。
再度開くと、プロジェクトドキュメントの長さを超えて切り捨てられたことがわかります。一部だけでも役立つでしょう。まず「このコードベースを説明してください」と尋ねます。考え始め、プロダクトドキュメントを読み直し、いくつかのコマンドを実行します。READMEを取得し、Hanoを使用していることがわかり、codeex.mdを解析するなど、あらゆる種類の作業を行っています。
エージェントが考えている間に、ここで何を構築するかを考えてみましょう。新しいペインを開いて、現在利用可能なリソースを見てみましょう。デフォルトではサービスは設定されておらず、バインディングもありません。しかし、このOpenAPIエンドポイントがタスク用であることはわかっています。KVネームスペース（キーバリューストア）をセットアップして、Codeexにこれらすべてを実装させるのも面白いかもしれません。
「npx wrangler kv namespace create」を実行し、「codeex-test」と名付けます。それをコピーして「wrangler.toml」に入れます。エージェントが完了し、プロジェクトの仕組みや構成に関するさまざまな情報が表示されています。出力に関して気づいたことの一つは、Claude Codeと比較すると、これは明らかに読みにくいことです。ただの生のテキストを出力しているように見え、このメッセージがCodeexからのものであるという表示があるかもしれませんが、Claude Codeよりも読みにくいです。
「Ctrl+C」で一旦止めて、新しいwrangler.tomlを追加しました。これで開いて、実際に何かをさせることができます。「KVネームスペースをこのプロジェクトに追加しました。それを使用してタスクを永続化し、APIエンドポイントを更新してKVネームスペースと対話できますか？」と尋ねます。考え始め、ファイルを検索し、おそらくwrangler.tomlを調べてKVネームスペースの名前を確認し、すべてのエンドポイントを見るでしょう。
基本的に、ここで合格基準を満たすために必要なことは、まずバインディングを取得し、各リクエストにバインディングが注入されることを理解する必要があります。これは標準的なCloudflare Workersの仕組みです。メモリリークもあるのが興味深いです。つまり、ここではさまざまな奇妙なことが起こっていますが、基本的にはKVネームスペースを見つけ、エンドポイント内で使用し始め、それを使用してKVネームスペースと対話する必要があります。
約83秒間考えていますが、興味深いことにどんな作業をしているかです。実際にはHanoライブラリ内のnode_modulesを調べ、すべての型を確認しています。バインディングへのアクセス方法を理解しようとしているのか、理解できないランダムなことをしているのかはわかりません。Claude Codeと比較すると、あちこちに飛び回っているように感じます。一方、Claude Codeはアクセスするものについてより意図的で、単に作業を始めたように思えました。おそらくそれは裏で行われていて、Codeexが出力しているのと同じ程度の可視性がなかっただけかもしれません。
codeex.mdがプロジェクトドキュメントの長さを超えているという警告が常に表示されます。何かをするたびに毎回発生しています。正しい方向に進んでいるかどうかはわかりませんが、実行を続けて何が出てくるか見てみましょう。
152秒（約2分半）経過しました。多くの思考を行い、KVネームスペースのインポートに成功しました。出力はやや混乱していますが、これが見たいものだと思います。タイプをここでインポートし、バインディングを正しく設定しています。Codeex-testはKVネームスペースの名前です。これは実際にかなり良く見えます。時間がかかりましたが、今のところ結果は正しいようです。
「はい」と答えて、そのファイルを編集させます。ファイルごとに実行するのか、単に「何でも変更してください」と言えるのかはわかりません。ここで見守りましょう。ああ、実際にはこれは素晴らしいです。正しいことをしています。疑うべきではありませんでした。時間がかかっただけです。
このテンプレートには「独自のオブジェクト挿入を実装する」というコメントがありましたが、今ではKVネームスペースに入り、ここにタスクを追加しています。JSONに文字列化し、すべて正しく見えます。そして情報を返しています。出力はCloud Codeと比較すると少し奇妙ですが、正しいことをしています。「はい」と答えると、何かを変更するたびに毎回プロンプトが表示されるようです。
READMEでは、これはセキュリティモデルとパーミッションで変更できます。承認モードフラグを与え、「full-auto」または「auto-edit」と設定することもできます。「auto-edit」の方が少し安全かもしれませんが、それでも私が望むだけのことができるでしょう。すべてのコードをレビューする代わりに、単に「はい」と言い続けて何が起こるか見てみましょう。
完了したようです。合計時間は372秒なので約6分かかりました。出力には「4つのタスクエンドポイントすべてをネームスペースに配線しました」とあります。基本的なセットアップを行い、タスク作成用のエンドポイント、特定のタスクの取得、すべてのタスクのリスト表示を追加しました。
さらに、プレフィックスのアイデアを思いつくほど賢かったのも興味深いです。これはKVの特性で、複数のオブジェクトをリストしたい場合、それらに何らかの記述子（この場合は「task」）をプレフィックスとして付けます。そして各オブジェクトをフェッチして解析し、オプションで完了したものでフィルタリングし、配列を返します。タスク削除も非常に簡単です。
これは素晴らしいです。私が構築したであろう方法とまったく同じで、本当に印象的です。約6分半でそれを行いました。実際に実行して何が起こるか見てみましょう。今まで実行していたローカルサーバーを停止し、再度開きます。
OpenAI APIキーを紛失したので、ここで素早くリセットします。以前はZellageでこれを開く前にOpenAI APIキーを実行していたので、この新しいターミナル内で再度実行する必要がありました。ここに来て、これが私のローカルのもので、「タスクを一覧表示」と言います。ページ1（ゼロか1かわかりませんが）を試してみると、タスクがないと返ってきました。これは正しいです。明らかにまだタスクを設定していません。
新しいタスクを作成してみましょう。デフォルトのものを使ってみます。実行するとtrueが返ってきました。素晴らしいです。これをもう一度実行すると、タスクが戻ってきました。おそらく以前も機能していたと思います。テンプレートはある程度似ていたのでしょう。本当の疑問は、これを停止して再度開いた場合、永続性は得られるのでしょうか？これがうまく機能したかどうかを知る方法です。
KVネームスペースがセットアップされ、ローカルでシミュレートされていることがわかります。それが機能しているかどうかは実際にわかりますか？すべて正しそうです。ここで2番目のタスクを追加してみましょう。「second task」というタイトルで、スラッグは「second」、期限は前のタスクより1日後に設定します。実行すると、2番目のタスクが表示されます。素晴らしいです。もう一度リストすると、2番目のタスクも戻ってくるはずです。実際にそうなりました。
これは素晴らしいです。すべてが正確に行われたようです。スラグを使用して特定のタスクを取得してみましょう。このタスクは「second」と呼ばれています。それを取得しましょう。すべて問題ありません。最後に、それを削除してデータベースを単一のタスクに戻しましょう。実行すると最初は機能し、2回目は404 Not Foundが返ってきました。これは正しいと思います。
予想通りすべてが機能しており、すべてのルートが正しく表示されています。これは大成功です。とても素晴らしいです。
再度言及しておきたいのは、ここでの出力が少し奇妙だということです。解析するのが少し難しいです。その一部は私自身の問題で、Zellageを実行し、ターミナルベースの作業をたくさん行っています。それは最も基本的なターミナルセットアップではありません。それは私自身の問題かもしれません。
これをデプロイして何が起こるか見てみましょう。設定すると、これを開くことができます。なお、ここではOpenAI APIキーを設定する必要はありません。それはCodeexを使用していた時のローカルのみで必要でした。ここではすべてが予想通りに設定されており、APIキーは不要です。
成功しました。タスクは空で、まだタスクが設定されていません。これは全く理にかなっています。実際の本番タスクを作成し、スラッグを「prod」とします。実行すると戻ってきます。すべて問題ありません。これをもう一度実行しても、まだタスクは戻ってきません。これはKVの結果整合性の問題かもしれません。もう一度試してみましょう。表示されました。少し遅延がありましたが、Workers KVを使用する場合は予想されることです。それでもほんの数秒の遅延でした。
他のものもテストして、KVネームスペースをクリーンアップしましょう。これを「prod」と呼びました。それを取得しましょう。すべて問題ありません。最後にここで削除してみます。実行すると完了します。もう一度実行すると、404エラー「タスクが見つかりません」が表示されるはずです。
完全に機能しました。すべてがとてもうまく機能しました。本当に素晴らしいです。Cloud Codeのビデオとは異なり、今回はCodeexにもう少し難しいタスクを与えたと思います。モデルがどんどん良くなっていることの証明であり、素晴らしいことです。また、システムプロンプトも前回のビデオで使用した時から更新されているはずです。全体的に本当に感銘を受けました。
これは「developers.cloudflare.com/workers」にアクセスし、「getting started」セクションで「prompting」を見つけることができます。さまざまな場所でこれを使用する方法についての指示がたくさんあります。Windsurf、Cursor、Zedなど、何を使用していても組み込むことができます。Copilotもあります。そしてもちろん、これらのターミナル内エージェントを使用している場合も、これを行う方法があります。
全体的に本当に感銘を受けました。前回のCloud Codeよりも難しいタスクを与えたと思いますが、非常にうまく対応しました。問題を解決し、すべてを行うのに約6分半かかりました。プロンプトを少し短くしていれば、もう少し速かったかもしれませんが、完全なプロンプトを送信して、それ自体が理解できるようにする方が良いでしょう。
これはかなり素晴らしいです。私たちはいわゆる「バイブコーディング」を行いました。何かをするように頼み、それがどう解決するか見守るだけです。最終結果は大成功でした。本当に素晴らしいです。Codeexに非常に感銘を受けました。説明欄にリンクを貼っておきます。
コメントで、これらのコーディングエージェントをもっと取り上げて、Cloudflare WorkersやCloudflareの開発スタック全体と統合する様子を見たいかどうか教えてください。これはとても楽しく、これらのものが本当に強力です。こういうものを思いつき、あなたのために物事を構築できるのは本当に素晴らしいことです。そして、あなたがする必要があるのは、そこに座って「はい、それをしましょう」「いいえ、それはしないでください」と言うだけです。本当に素晴らしいです。
視聴いただきありがとうございます。お役に立てば幸いです。次回もお楽しみに。
コメント