見出し画像

Codexでもループエンジニアリングはできる｜FizzBuzzで小さく試してみた

とあるITエンジニア | AIと仕事の仕組み化

Claude Codeでやっていたみたいな、AIが書いて、動かして、失敗を見て、自分で直してまた回す。あの流れ、Codexでもできるのかなと思って試してみた。

先に言うと、ふつうにできる。しかも、かなり相性がいい。

大げさな題材でやると話がぼやけるので、今回はFizzBuzzで小さく確認した。こういう古典はいい。どこで間違えたかが見えやすいし、テストの役割もはっきりする。変に背伸びしたサンプルより、ずっとわかりやすい。

要するに何を試したのか

やったことは単純です。

  1. わざと少し間違えたFizzBuzzを書く

  2. テストを書いて期待値を固定する

  3. 実行して、どこで失敗するかを見る

  4. 原因を絞って最小差分で直す

  5. もう一度実行してPASSするまで回す

これだけ。

ループエンジニアリングという名前だと大げさに聞こえるけど、やっていることはけっきょくこれです。
実装する。採点する。赤が入ったら直す。合格するまで回す。やっぱり夏休みの宿題とあまり変わらない。

題材は「15でだけ間違えるFizzBuzz」

今回用意したのは、15 のときだけ正しく動かないFizzBuzz。

最初の実装の考え方はこうです。

  • 3で割れたら Fizz

  • 5で割れたら Buzz

  • それ以外は数字を返す

この時点で、もうオチは見えている。
15 が FizzBuzz ではなく Fizz（3で割れる判定が先に来るから） になる。定番のミスです。

でも、こういう「わかりやすく壊れる例」がちょうどいい。AIとの反復って、派手なクラッシュより、小さいズレのほうが観察しやすいので。

先にテストを書く

今回は unittest で4つだけ確認した。

  • 通常の数はそのまま返るか

  • 3の倍数は Fizz になるか

  • 5の倍数は Buzz になるか

  • 15の倍数は FizzBuzz になるか

大事なのは、15はFizzBuzz を先に固定しておくことです。
AIにコードだけ書かせると、なんとなく動いている雰囲気で先に進みがちだけど、テストがあるとそこで止まる。ここはかなり大きい。

実際に回したら、落ちたのは本当に 15 のケースだけだった。

AssertionError: 'Fizz' != 'FizzBuzz'

情報量としてちょうどいい失敗です。
何がズレたかが一瞬でわかる。

Codexはこの往復がやりやすい

失敗が見えたあとにやることは単純です。

  1. どのケースが落ちたか読む

  2. 原因を絞る

  3. 必要なぶんだけ直す

  4. すぐ再実行する

今回の修正は本当に最小だった。
3 の判定より先に、15 の判定を置くだけ。

def fizzbuzz(value: int) -> str:
    if value % 15 == 0:
        return "FizzBuzz"
    if value % 3 == 0:
        return "Fizz"
    if value % 5 == 0:
        return "Buzz"
    return str(value)

そのあともう一度テストを回すと、4件すべてPASS。
この流れがかなり自然だった。

ファイルを読んで、その場で小さく直して、すぐ実行して、また結果を見る。Codexはこの反復を前に進めやすい。説明だけ立派で手が止まる感じが薄い。ここはかなり強みだと思った。

なんで「できる」より「得意」と感じたのか

ここが今回いちばん大事な感想です。

「Codexでもできますよ」だけだと、Claude Codeの代わりに見えやすい。
でも実際に触ると、感触はもう少し前向きだった。

  • 失敗をちゃんと観測できる

  • 修正が最小差分で済む

  • その場ですぐ再確認できる

  • ループのテンポがいい

このへんが揃っていると、単なる代替というより、こういう反復はむしろ得意 と言ったほうが近い。

もちろん、これがそのまま大規模開発の全部を解決するわけではない。READMEを読む、設定を追う、散らばったファイルをつなぐ、みたいな面倒さは普通にある。そこは人間でもしんどい。コーヒーだけでは解決しない。

でも少なくとも、実装 -> 実行 -> 失敗確認 -> 修正 -> 再実行 の短いループとは、かなり相性がいいです。

広げ先もイメージしやすい

FizzBuzzは小さい例だけど、広げ先はそのまま見える。

  • サンプルコードの試作

  • CLIツールのたたき台

  • 記事用の検証コード

  • 小さな自動化スクリプト

  • テスト追加つきの軽い修正

このあたりは、まさにAIと一緒に回したくなる仕事です。

まとめ

Codexでもループエンジニアリングはできる。
そして今回の感触で言うと、かなり自然に回せた。

特によかったのは、

  • バグ入り実装を置く

  • テストで失敗を固定する

  • 実行結果から原因を絞る

  • 最小差分で直す

  • すぐ再実行する

この流れを遠回りせずに進められたこと。

なので結論はこれです。
Codexでもできる で止めるより、Codexはこういう反復がわりと得意 と言ったほうが、実感には近い。

まずは小さい題材で1回回してみるのがおすすめです。FizzBuzzくらいで十分。小さいけど、見えることは多い。


いいなと思ったら応援しよう！