CloudflareがClaudeを使ってOAuthを構築し、すべてのプロンプトを公開

元記事: 2025年6月2日原文(github.com)

概要

このリストは、 2025年3月から5月 にかけての コミット履歴 を示すもの。日付ごとに authored （作成）と committed （コミット）の区別あり。複数の日付や アクション が混在。 英単語 が繰り返し出現。履歴の 整理と理解 が必要。

Gitコミット履歴の読み方

authored は、コミットの 作成者 を示す用語。
committed は、リポジトリへ 実際にコミット されたことを表現。
"Commits on [日付]" は、その日に行われた コミット の一覧。
- 例：「Commits on May 19, 2025」は 2025年5月19日 のコミット。
authored と committed が同じ日付に並ぶ場合、 同一内容 または 複数作業 の可能性。
and が含まれる場合、 複数の操作 の同時実施を示唆。

コミット履歴の整理方法

日付ごと に 作成（authored） と 反映（committed） を区分。
複数回 のコミットがある日は、 内容の詳細 も確認推奨。
履歴管理 や 進捗把握 に役立つ一覧。
英語表記 のまま運用されることが多い点に注意。
履歴の可視化 や レビュー に最適。

コミット履歴の活用例

変更履歴 の追跡および バグ発見 時の調査。
作業分担 や 担当者確認 のための記録。
開発進捗 や リリース管理 の根拠資料。
自動化ツール による 分析や可視化 の入力データ。
ドキュメント作成 や 報告書 の参考情報。

注意点とベストプラクティス

authored と committed の違いを明確に理解。
日付順 や 担当者別 での整理が重要。
コミットメッセージ の統一と簡潔化を推奨。
履歴の一貫性 を保つため、 定期的なレビュー が有効。
GitHub や GitLab などの プラットフォーム での管理が一般的。

提供: ハクソク · 要約更新: 2025年6月3日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

READMEからの引用: このライブラリ（スキーマのドキュメントも含む）は、主にAnthropicのAIモデルであるClaudeの助けを借りて書かれました。Claudeの出力は、Cloudflareのエンジニアによって徹底的にレビューされ、セキュリティと基準への準拠に細心の注意が払われました。初期の出力には多くの改善が加えられ、ほとんどがClaudeにプロンプトを与えて、その結果をレビューする形で行われました。コミット履歴をチェックして、Claudeにどのようにプロンプトを与えたか、どんなコードが生成されたかを見てみてください。「NOOOOOOOO!!!! LLMを使って認証ライブラリを書くなんて無理だよ！」「はは、GPUはバリバリ動くね」真面目な話、2ヶ月前（2025年1月）には、私（@kentonv）も同意していたと思います。私はAIに懐疑的でした。LLMは実際にはコードを理解せず、新しいものを生み出せない、ただのグロリファイド・マルコフ連鎖生成器だと思っていました。このプロジェクトは、AIがひどいコードを生成するのを笑うつもりで始めたんです。そしたら、実際にコードが結構良さそうに見えたんですよ。完璧ではないけど、AIに修正を頼んだらちゃんと直してくれました。驚きました。強調したいのは、これは「雰囲気でコーディング」したわけではないということです。すべての行は、関連するRFCと照らし合わせて、セキュリティの専門家によって徹底的にレビューされました。私は自分の懐疑心を検証しようとしていましたが、結局自分が間違っていたことを証明してしまいました。ぜひコミット履歴を見てください。特に初期のコミットをチェックして、どういう経緯だったのか理解してください。

└

同じことを感じてるけど、Claudeだけは使いやすい。他のモデルは使うのが辛い。

└

うん、最近はAIに対して懐疑的な気持ちが強いけど、それでもワークフローにAIを取り入れようとしてる。実際、楽しんでるわけじゃなくて、やりたいことを説明するのが難しくて、実際にやるよりも大変だと感じてる。でも、これはなくならないし、ある意味「未来」だってことは明らかだと思う。新しい道具を学んでおく方が、知らないままでいるよりいいと思う。ただ、まだこの分野のツールは発展途上だと思うから、面白いUXが出てくるのを楽しみにしてる。

└

私にとっての疑問は、専門家が関与しない場合、どの時点でそれをやるのが合理的だと感じるかってことかな？編集として、いくつかのプロンプトを読んだ後、非専門家がそれらのプロンプトを考えつく可能性はどれくらいあるのか？本当に興味深いのは、AIが実際にプロンプトを生成できるかどうかだと思う。

└

真面目な話、2ヶ月前（2025年1月）には、私（@kentonv）も同意していたと思います。「私（@kentonv）」って何を意味してるのか混乱してるんだけど、kentonvは別のユーザーだよね。[0] これはあなたの別アカウントってこと？それとも誤字/誤解？編集: あなたの投稿のほとんどがREADMEを引用していることに気づいた。明確にするために、>や*の文字を使うことを考えてみて。 [0] https://news.ycombinator.com/user?id=kentonv

└

一方で、スキルのあるエンジニアがこれらのツールを正しく使ってプロンプトを与えれば、LLMがそういうコードを生成できると思ってる。OAuthは新しいものじゃないし、公共プロジェクトからトレーニングデータとして盗める動作例がたくさんあるし、ほとんどのユースケースやニーズに合ったさまざまな言語もある。でも、私が懐疑的なのは、これが全く新しいもの、つまり研究や材料科学、経済、発明などに繋がるっていう主張が続いていること。これは、実際にその瞬間に生成している情報源から「リアルタイム」で学ぶ必要があるからで、文脈のない数十年分のStack Overflowの回答では無理なんだよね。そういう話は何年もされてきたけど、具体的に選ばれた例以外に証拠はないし、しかもそれはかなり制御された環境からのものが多い。私は、優秀なエンジニアがいれば、これらのツールを使って過去のデータセットから「新しい」コードを生成できるとは疑っていない。ただ、環境的にも社会的にもそのコストを考えると、これらのツールの有用性には疑問を持ち続けている。

└

もう一度、コミット履歴を確認してみて。特に初期のコミットを見れば、どうなったかが分かるよ。履歴の最初のページへの直接リンク: https://github.com/cloudflare/workers-oauth-provider/commits... たくさんの明確で具体的なプロンプトがあって、直接的な指示もある。最初のページのいくつかの例: https://github.com/cloudflare/workers-oauth-provider/commit/... https://github.com/cloudflare/workers-oauth-provider/commit/...

└

すべての行は、関連するRFCと照らし合わせて、以前にそのRFCに関わったセキュリティ専門家によって徹底的にレビューされました。これはコーディングのようだけど、もっと遅いね。

└

そうだね、YouTubeにはティックタックトーやフライングシミュレーターをLLMで作ってる人たちの例がたくさんあるよね。それが何を証明するの？OAuthはもう日常的なものだし。

これがAI支援のコーディングの進むべき方向だと思ってる。ソフトウェアエンジニアが追い出されて、ビジネスパーソンがボタンを押すだけで完全なアプリができる、みたいな幻想が広がってるけど、実際には経験豊富なエンジニアがAIを使ってコードの一部を生成し、それを丁寧にレビューしてテストする形になると思う。百万ドルの（文字通りかもしれない）質問は、@kentonvがAIの助けなしにこのライブラリをもっと早く書けたかどうかだね。

└

百万ドルの（文字通りかもしれない）質問は、@kentonvがAIの助けなしにこのライブラリをもっと早く書けたかどうかだね。私の考えでは、答えは明らかに「ノー」だと思う。少なくとも、今持っているツールで達成できることを考えると、今後3〜6ヶ月でAIを使って新しいソリューションを完全にコーディングするのが、効果的に使えば絶対に早くなると思う。たくさんの作業が必要だと思うけど、しっかり文書化され、構造化されたコードベースで、迅速なフィードバックループ（良いリンティングやユニットテストなど）があれば、そこに向かって進んでいると思う。

└

「ソフトウェアエンジニアが追い出されるわけではなく…むしろ経験豊富なエンジニアがAIを使ってコードの一部を生成し、それを丁寧にレビューしてテストしている。」でも、もし最後に20個のkentonvの代わりに2個だけ必要だったらどうする？他の18個を占める新しいタスクが見つかると思う？それが問題だと思う。著者はこの場合、かなり技術的なプロジェクトを実装してるけど、ルーチンのLoBアプリ開発はどうなの？

Hacker Newsで議論の続きを見る