ハクソク

世界を動かす技術を、日本語で。

CloudflareのClaude生成のコミットをすべて読みました

2025年6月7日原文(maxemitchell.com)

概要

CloudflareのOAuth 2.1ライブラリ開発にて、AI（Claude）と人間の協働プロセスがgitコミットで詳細に記録。 プロンプトの履歴が意図のドキュメントとして機能し、新たな開発手法の可能性を示唆。 AIによるコード生成は95%以上だが、人間の介入と判断が不可欠。 プロンプト管理や多段階プロンプトの重要性が浮き彫り。 将来的にはプロンプト自体がソースコードとなる可能性も議論。

Cloudflare OAuth 2.1ライブラリ開発におけるAIと人間の協働

  • Cloudflareがオープンソース化したOAuth 2.1ライブラリの開発記録

    • ほぼ全てのコードをAI（Claude）が生成
    • 開発プロセス全体をgitコミットメッセージで詳細に記録

  • コミットごとにプロンプト内容を明示

    • すべてのプロンプト、修正指示、人間の介入履歴を保存
    • 人間とAIの「会話履歴」としてのアーカイブ

  • リードエンジニアKenton（@kentonv）のAI懐疑からの変化

    • 最初はAIへの懐疑心で参加
    • 結果的に自分の先入観を覆す体験

  • プロンプト管理の実践

    • 各コミットにプロンプトを記録し、将来の保守・デバッグに有用なコンテキストを提供
    • プロンプト自体が意図や設計思想のドキュメントとなる

  • 具体例を用いたプロンプト設計

    • 実際の利用例コードを初期プロンプトとして提示
    • メソッドシグネチャや現実的な利用条件の曖昧さを排除

  • シンプルな修正指示の有効性

    • 「You did X, but we should do Y. pls fix.」のような簡潔な指示
    • 状況説明、変更理由、具体的な指示を明確に伝達

  • ドキュメント生成の自動化

    • 1行プロンプトで包括的なスキーマドキュメントを自動生成
    • モデルによるドキュメント生成の得意分野

  • AIの限界と人間の介入

    • クラス宣言の移動や重複コードの修正などで人間が手動対応
    • grepやsedによる手動修正も発生
    • スタイリングや未使用メソッド削除など、AIが苦手なタスクは人間が担当

  • AI生成コードの割合と人間の役割

    • コードの95%以上をAIが生成
    • ただし全体を通じて人間の監督・判断が不可欠

AIコーディングツール活用のベストプラクティス

  • 成果物重視のプロンプト設計

    • バックエンドサービスならエンドポイントと期待動作
    • CLIツールなら使用例、ライブラリなら統合例を提示

  • プロンプトをバージョン管理資産として扱う

    • コミットメッセージにプロンプトを含め、将来的なメンテナンス性向上

  • マルチショットプロンプティングの前提

    • ほぼ全ての機能で複数回のプロンプトと修正が必要
    • これは制約ではなく、協働の本質

  • 手動介入の重要性

    • バグ修正やスタイリングなど、手動の方が速いケースも多い
    • 介入タイミングの見極めがスキル

プロンプトをソースコードとする未来への示唆

  • プロンプト履歴を「実際のソースコード」として扱う発想

    • プロンプトをバージョン管理し、将来的に最新AIで再生成可能
    • 英語が読めれば誰でもビジネスロジックの意図を理解できる自己文書化アプリケーション

  • モデルの厳格なプロンプト遵守と高い信頼性が前提

    • 現実にはデプロイ・テスト・メンテナンスが不可欠
    • だが、プロンプト履歴自体が「アプリケーション」となる可能性

現状のAIコーディングの限界と展望

  • AIの自律的な大規模ライブラリ実装にはまだ課題

    • ほぼ全ての機能でマルチショットプロンプトと人間の戦略的介入が必要
    • 一部のバグや機能は手動の方が迅速

  • Claude Codeの登場と急速な進化

    • 公開からわずか2週間で実用レベルの協働を実現
    • AIは自ら進化し続ける「自己改善型ツール」

  • AIと人間の新たな創造的ダイナミクス

    • AIが機械的実装を担い、人間が方向性・文脈・判断を提供
    • 今後も人間の関与は不可欠だが、AI活用の可能性は拡大

  • まとめ：AIを「改善し続ける道具」として捉え、今後の進化と協働の深化に期待

Hackerたちの意見

面白いレビューだけど、こういうテクノユートピア的な決定論は本当に嫌いだな。「モデルは必然的に改善される…」って、誰が言ってるの？それがどうして必然なの？もしかして、もう限界に達してるかもしれないじゃん？

└

モデルは毎日改善されてるよ。人々はトレーニングやハードウェアの効率を向上させるための数千の異なる最適化を見つけてる。2025年6月の今が改善が止まる時期だなんて信じられない。限界に近づいているかもしれないけど、それは急に進歩が止まるのではなく、シグモイド曲線になるはず。

└

この3ヶ月でモデルはかなり改善された。でも、もう3年も「もしかして、もう限界に達してるかも？」って言ってる人がいるよね。

└

99%のケースで、明日は昨日と同じようになるって意味で「必然的」だよ。LLMは何年も継続的に改善されてきた。驚くべきことは、さらに改善されないことだよ。研究を少しでも追っていれば、しばらくは改善されるって分かる。商業モデルにまだ全てのブレークスルーが反映されてないからね。「テクノユートピア的決定論」じゃなくて、明らかに見える軌道なんだ。一方で、もし改善されなかったら、全体の観察には大きな変化はないよ。それはちょっとした細かいことを言ってるだけ。厳密なプロンプトの遵守とプロンプトのアーカイブがプログラミングのやり方を変える可能性があるっていう観察は本当だし、過去に何度も見た現象でもある。もうコンパイラのアセンブリ出力を保存してる人はいないしね。文章には確かに有効な批判があって、過度に楽観的だと思う。ほとんどの非自明なプロンプトはまだ不十分に指定されていて、複数の実装が可能で、必ずしも正しいわけじゃないから。それはもっと有用な批判で、LLMの改善とは全く関係ないんだ。

└

コンピュータの性能が上がれば、処理が速くなって、コンテキストも増えるよね。

└

皮肉なことに、もしAIが今後5〜10年で大半のコードを書くって理論を信じるなら、その後何をトレーニングするの？自分自身？「必然的に良くなる」って理論的な軌道は、人間が質の高いトレーニングデータを生産している場合にだけ当てはまる気がする。コードLLMが生成するコードの質は、言語やプロジェクトの成熟度や普及度に非常に比例してるよ。

これらのコミットを読みながらアイデアが浮かんだんだけど、プロンプトを実際のソースコードとして扱ったらどうなるだろう？生成した機能に使ったプロンプトをコミットするバージョン管理システムを想像してみて。お願いだから、そんなことは絶対にやらないで。まず、ストレージがほぼ無料なのに生成されたソースコードをコミットしない理由は何？それは色々な意味でクレイジーだと思う。 > モデルが必然的に改善されるとき、最新のバージョンを接続して、強化された能力でコードベース全体を再生成できる。もしコードがコミットされていなかったら、どうやってそれが良くなったのか悪くなったのか分かるの？ソースコードがない状態で、セキュリティの脆弱性を監査したりデバッグしたりするのはどうするの？

└

プロンプトを実際のソースコードとして扱ったらどうなる？ そんなことはしないよ。プログラミング言語とは違って、自然言語は曖昧だから、ソフトウェアを完全に指定するには不十分なんだ。

└

ほとんどの人がプログラミングするときに「ソフトウェアエンジニアリング」をしてるわけじゃないと思う。WordPressやDreamweaverみたいなプログラミングの世界もあって、そこでのミスの影響はあまり重要じゃないしね。LLMは決定論的な出力に設定することもできるよ。

└

言ってること自体はあまり良くないアイデアだけど、ちょっと工夫すれば期待できそうだね。LLMでコードを生成して、そのコードに対してテストを書く。テストはLLMを使っても自分でやってもいい。もちろん、実際にプログラムを動かすためには実際のコードをコミットする必要があるけど、生成したプロンプトのチェーンもどこかに保存しておく。で、（記事に書いてある通り）もっと良いモデルが出てきたら、そのチェーンを再実行する。たぶん「このプロジェクトを効率重視で作って」や「Rustでこのプロジェクトを作って」みたいなプロンプトを使う感じかな。新しいコードベースに対してテストを実行して、スイートが通れば、かなり改善されたコードベースで進められる。これが、以前生成したコードをLLMに渡して「可読性を改善して」って言うのと違うのは、新しい（より良い）LLMが前のLLMの「悪い」決定の文脈に縛られないから。もちろん、実際にはそんなに簡単じゃないけど、テストはすべてをキャッチするわけじゃないし（ファズテストや完全カバレッジでほとんどの問題は捕まえられるけど）、プログラマーはそれをすべてキャッチするかのように扱うことが多いから、やる価値はあるかもしれないね。

└

私の仕事は、ほぼ完全に生成されたコードのプロジェクトに10年以上関わってきた。AIが生成したわけじゃなくて、実際のプロジェクトの作業はコードジェネレーターを作ることなんだ。私たちがすぐに学んだことの一つは、生成されたソースコードを実際のソースコードと同じリポジトリに置くのは持続可能じゃないってこと。変更をレビューする性質が全然違うからね。もう一つすぐに分かったのは、生成されたコードを修正しようとするのは持続可能じゃないし、100%生成されたコードベースを目指すのも無理だってこと。その結果、プロジェクトを大幅に再設計して、生成されたコードの任意の場所に手作りのコードを注入する必要があった。さらに、コードジェネレーターに変更があるときは、機能フラグを設ける必要があるってことも学んだ。誰かが古い動作に依存していたからね。

└

もっとひどい。モデルは決定論的じゃないんだ！ランダム性をコントロールするために温度値を使って、局所的な最小値から逃げるためにね！再生成されたコードは、動作が異なるかもしれないし、異なるバグが出るかもしれない（最悪の場合）、全く動かないかもしれない（最良の場合）。

Hacker Newsで議論の続きを見る