「いい感じに作って」でどこまで作れる？Codexを使ったバイブコーディング検証

はじめに

最近、「バイブコーディング」という言葉を耳にする機会が増えました。
バイブコーディングとは、細かい設計や実装方法を人間がすべて決めるのではなく、開発者が「意図・雰囲気・方向性」を自然言語で伝え、AI がそれを解釈して設計やコードを提案し、対話しながら共創してアプリケーションを作っていく開発スタイルです。
今回は、Codex（※）に同じアプリケーションを異なる粒度の指示で作成してもらい、指示内容によって成果物にどのような違いが出るのかを検証しました。
※OpenAI ChatGPT Desktop AppからCodex エージェント（codex‑1 モデル） を使用
なお、この記事はバイブコーディングの良し悪しを決めるものではなく、実際の利用時に注意すべき点を確認することを目的としています。

今回作成するもの

今回は、指定したフォルダ内のログファイルからERRORを含む行を抽出する簡単なツールを作成します。
想定する機能は以下です。

• 指定フォルダ内の.logファイルを読み込む
• ERRORを含む行を抽出する
• ファイル名、行番号、内容をCSVに出力する
• フォルダが存在しない場合にエラーを表示する
• 対象ファイルが存在しない場合にメッセージを表示する

開発言語をC#とし、実行形式はコンソールアプリケーションとしました。

検証方法

同じ内容のツールを、以下の2種類の指示で作成してもらいました。

1. 曖昧な指示
2. 要件を具体的にした指示

それぞれ別のプロジェクトとして作成し、以下の項目を比較します。

• 初回の指示だけでビルドできたか
• 想定した機能が実装されたか
• 例外処理が実装されたか
• 追加の指示が何回必要だったか
• AIが独自に判断した仕様

検証1：曖昧な指示

最初は、バイブコーディングらしく、かなり曖昧な指示を出しました。

C#でログファイルからエラーを探すツールを作ってください。
使いやすい感じでお願いします。

この指示では、以下の内容を指定していません。

• 対象となるファイルの拡張子
• 検索対象の文字列
• 検索結果の出力方法
• フォルダの指定方法
• エラー発生時の動作
• 使用する.NETのバージョン

生成された内容
Codexは、ログファイルを読み込み特定の文字列を検索するGUIアプリ(Windows Forms)を作成しました。

ただし、明示していなかった部分については、Codexが独自に仕様を決めていました。
例えば、以下のような点です。

• 検索対象をERRORにする
• 対象ファイルを.logに限定する
• フォルダパスを画面に入力する
• 検索結果を画面に表示する
• サブフォルダは検索しない

最低限の機能は作成されましたが、画面の表示が見切れてしまう等の表示の不具合がありました。
また、存在しないフォルダを入力した場合の処理はありましたが、アクセス権限のないファイルや読み込み途中で例外が発生した場合の考慮が十分ではありませんでした。

不足している機能を追加するため、以下のような指示を追加しました。

検索結果を表示した際に画面上部が見切れてしまうので修正してください。

フォルダが存在しない場合や、
ログファイルを読み込めなかった場合にも、
アプリケーションが異常終了しないようにしてください。

最終的に、想定していた機能を実装するまでに、合計で数回の追加指示が必要になりました。

検証2：具体的な指示

次に、最初から要件を具体的にして指示しました。

.NET 8のC#コンソールアプリケーションを作成してください。

コマンドライン引数でフォルダパスを受け取ります。
指定フォルダの直下にある、拡張子が.logのファイルを対象にしてください。
各ログファイルを1行ずつ読み込み、
大文字・小文字を区別せずにERRORを含む行を抽出してください。
抽出結果はresult.csvに出力してください。

CSVには以下の項目を出力してください。
・ファイル名
・行番号
・ログの内容

以下の場合も異常終了しないようにしてください。
・コマンドライン引数が指定されていない
・指定フォルダが存在しない
・対象となるログファイルが存在しない
・ログファイルの読み込みに失敗した
・CSVファイルの書き込みに失敗した

処理は適切な単位でメソッドに分割してください。

生成された内容
コンソールアプリケーションが作成され、初回の生成時点で、想定していた機能の多くが実装されました。

特に、以下の点は曖昧な指示の場合よりも改善されていました。

• 入力値のチェック
• ログファイルの検索条件
• CSVの出力項目
• 例外処理
• メソッドの分割
• エラーメッセージの表示

一方で、具体的に指示していない部分については、今回もCodexが独自に判断していました。
例えば、CSVファイルをどのフォルダに出力するかについては、実行ファイルと同じフォルダに出力する実装となっていました。
また、CSV内のダブルクォーテーションや改行をどのようにエスケープするかについても、生成されたコードを確認する必要がありました。

生成されたコードの例
以下は、ログファイルからERRORを含む行を抽出する処理の一例です。

private static IEnumerable<LogEntry> FindErrors(string filePath)
{
    var lineNumber = 0;

    foreach (var line in File.ReadLines(filePath))
    {
        lineNumber++;

        if (line.Contains(
            "ERROR",
            StringComparison.OrdinalIgnoreCase))
        {
            yield return new LogEntry(
                Path.GetFileName(filePath),
                lineNumber,
                line);
        }
    }
}

ログファイルをすべて一度に読み込むのではなく、File.ReadLinesを使用して1行ずつ処理する形になっています。
小規模なログファイルであれば大きな差はありませんが、ファイルサイズが大きい場合は、全行を一括で読み込むよりもメモリ使用量を抑えられます。
一方で、ファイルの文字コードについては考慮されていませんでした。
実際の業務では、UTF-8以外のログファイルを扱う可能性もあるため、対象となるファイルの文字コードを確認する必要があります。

比較結果

今回の結果をまとめると、以下のようになりました。

比較項目	曖昧な指示	具体的な指示
初回ビルド	成功	成功
ログ検索	実装された	実装された
CSV出力	実装された	実装された
入力値チェック	一部のみ	実装された
例外処理	一部のみ	実装された
追加指示	多い	少ない
独自に判断された仕様	多い	少ない
動作確認の必要性	あり	あり

具体的な指示を出した方が、想定した成果物に近いものが早い段階で生成されました。
一方で、どれだけ詳しく指示しても、人間による確認が不要になるわけではありませんでした。

検証して分かったこと

1.曖昧な指示でも、動くものは作られる
今回のような小規模なツールであれば、曖昧な指示でも最低限動作するものが生成されました。
プログラムのたたき台を作る用途では、非常に便利だと感じました。
特に、作りたいもののイメージはあるものの、最初のコードをどのように書けばよいか分からない場合には有効です。

2.指定していない部分はAIが決める
当然ではありますが、指示していない仕様については、AIが何らかの判断を行います。
今回の例では、以下のような項目が該当しました。

• 入力方法
• 出力先
• 対象ファイルの範囲
• 文字コード
• CSVの形式
• エラー発生時の動作

AIが決めた仕様と利用者の期待が一致するとは限りません。
そのため、重要な条件については、最初の指示に含める必要があります。

3.正常系だけでなく、異常系も指示する必要がある
「ログファイルを検索する」という正常系の処理は、比較的簡単に生成されました。
一方で、以下のような異常系は、明示的に指示しなければ十分に実装されない場合があります。

• ファイルが存在しない
• フォルダにアクセスできない
• ファイルの読み込み中に例外が発生する
• 出力先に書き込み権限がない
• 想定外の文字コードが使用されている

業務で使用するツールでは、正常系よりも異常系の考慮が重要になる場合があります。

AIが生成したコードに問題が発生した場合、最終的に修正や判断を行うのは利用者です。
少なくとも、生成されたコードの概要や処理の流れを理解できる状態で使用する必要があります。

バイブコーディングが向いている場面

今回の検証を通して、以下のような場面ではバイブコーディングを活用しやすいと感じました。

• 小規模な業務効率化ツール
• プログラムのたたき台作成
• サンプルコードの作成
• 定型的な処理の実装
• 既存コードの説明
• 単体テストの作成
• エラー原因の調査

特に、失敗した場合の影響が小さく、利用者自身が動作確認できるツールとは相性がよいと考えます。

バイブコーディングに注意が必要な場面

一方で、以下のような場面では、より慎重な確認が必要です。

• 個人情報や機密情報を扱う処理
• 認証や権限管理
• 金額を扱う処理
• データを更新または削除する処理
• 外部システムと連携する処理
• 障害発生時の影響が大きいシステム
• 社内規定により生成AIの利用が制限されている環境

動作しているように見えても、セキュリティや性能、保守性に問題が残っている可能性があります。
また、業務上のコードやデータをAIに入力する場合は、所属組織のルールを確認する必要があります。

まとめ

今回は、Codexに曖昧な指示と具体的な指示を出し、生成されるアプリケーションの違いを比較しました。
検証した結果、以下のことが分かりました。

• 曖昧な指示でも、簡単なアプリケーションは作成できる
• 指定していない仕様はAIが独自に判断する
• 具体的な指示ほど、想定した成果物に近づきやすい
• 異常系や境界値は明示的に指示した方がよい
• 生成されたコードには人間による検証が必要
• バイブコーディングでも、要件を整理する力は重要

バイブコーディングは、「何も考えずにAIへ任せる開発方法」というよりも、AIと対話しながら仕様を整理し、成果物を改善していく開発方法だと感じました。
コードを書く作業は減らせますが、何を作るのか、どのような条件を満たす必要があるのか、生成されたものが正しいのかを判断する役割は、引き続き人間に残ります。
今後は、機能追加を繰り返した場合のコード品質や、単体テストをAIに作成させた場合の網羅性についても検証してみたいと思います。


著者: F.T (株式会社ウィズツーワン)