この記事は プレセナ・ストラテジック・パートナーズ Advent Calendar 2025 7日目の投稿です。
Introduction
昨今、OpenAIからリリースされた「Codex」のような自律型エージェントを用い、プロンプトだけで開発を進める「Vibe Coding」が注目されています。
今回、エンジニアリング組織に参加したばかりの非エンジニアメンバー（Aさん）が、このCodexを用いて実際に社内ツールの改修を行いました。 結論から言えば、機能自体はAIへの指示のみで実装できましたが、その後のPRレビューではエンジニアリングの観点から 7件の修正指摘 が必要となりました。
本記事では、Vibe Codingで「動くもの」を作る過程と、そこから製品レベルに引き上げるために必要だった「エンジニアによる補正（テスト・設計）」のポイントについて共有します。
登場人物と背景
- 私（筆者）: エンジニア。今回は環境構築のサポートと、最終的なコードレビューを担当
- Aさん（パートナー）: 元非エンジニア。エンジニアリング領域への興味から異動してきた新メンバー。業務外でAIを使ったアプリ制作経験あり
- 対象プロダクト: 社内で毎日稼働している「朝会Slack Bot」
課題とミッション
今回改修対象となったのは、エンジニアの朝会で使用しているSlack Botです。もともとは「朝会の司会をランダムに指名する」「今日休暇のメンバーを表示する」というシンプルな機能を持っていました。
しかし、運用を続ける中で、利用者であるエンジニアたちから「もっとこうしてほしい」という要望が挙がっていました。
- 会議被りの考慮漏れ: 「休暇ではないが、別MTG等で朝会に出られない人」が司会に当たってしまう。朝会欠席者がわかるようにしたい
- 長期休暇中のノイズ: 定期実行のため、年末年始など全員が休みの期間も投稿されてしまい煩わしい
- 手動運用の限界: 翌日の定例や振り返りのために「議事録の準備」が必要だが、このリマインド設定を手動で行っており、忘れがち
これらの「日々のちょっとした面倒くさい」を解決し、Botをアップデートすることが今回のミッションです。
開発アプローチ：必然的な「Vibe Coding」
今回の開発は、新メンバーであるAさんが主導しました。
Aさんはエンジニアリング組織に参加したばかりで、自力で複雑な実装コードをバリバリ書くスキルはまだありません。そのため、実験的な縛りとしてではなく、「Aさんが実装を進めるための現実的な手段」として、自然とAIへの指示のみで開発を行う「Vibe Coding」スタイルになりました。
- 環境構築などの土台は私がサポート
- 実装はAさんがCodexに指示を出して行う
- 私は基本的にコードの手直しをせず、最後にレビューを行う
という役割分担です。
開発プロセス：AIと人間の二人三脚
最初の壁：環境構築は「人間」の仕事
開発を始めてすぐに、最初の壁にぶつかりました。環境構築です。
リポジトリにはREADMEがありましたが、あくまで「エンジニア経験者向け」に書かれていました。パスを通す、ライブラリの依存関係を解決するといった「暗黙の了解」が多かったため、Aさんと私の二人で構築を進めました。
また、環境構築の最後にプロジェクト固有のエラーも発生しました。ここからCodexにバトンタッチし、エラーログを読ませて解決策を提示させることで、なんとか開発環境を整えることができました。
「AIにコードを書かせる以前に、AIを動かすための土台を作る段階では、まだ人間の知見（あるいは非常に丁寧なドキュメント）が不可欠である」ということを痛感したスタートでした。
実装フェーズ：爆速の実装、泥臭い検証
環境さえ整えば、開発は驚くほどスムーズでした。
Aさんが「カレンダーから予定を取得して判定したい」「祝日は除外したい」と自然言語で指示を出すと、Codexは迷うことなくコードを生成していきます。
しかし、ここでVibe Codingの落とし穴がありました。「検証」です。
今回のBotは社内の簡易なツールであったため、テストコードが一切存在しませんでした。また、Slack Botという性質上、テスト環境を用意するのも手間がかかります。
結果として、「AIが生成したコードを手動で実行し、Slackへの投稿を目視で確認する」という泥臭い作業の繰り返しになりました。「コードを書く」時間は劇的に短縮されましたが、「正しく動くか確かめる」コストは人間が払わなければなりません。テスト環境がない状態でのVibe Codingは、想像以上に検証負荷が高いものでした。
クライマックス：PRレビューの現実
手動テストを繰り返し、なんとかローカルでの動作確認は完了。機能としては要件を満たすものができあがりました。
AさんからPRが出され、私がレビューを行いました。PRの指摘事項は7箇所となりました。そのうち1つは文言修正の戻しという軽微なものでしたが、残りの6つはエンジニアリングの観点から見て重要な指摘でした。
AIが書いたコードには、具体的にどのような問題があったのでしょうか。
1. 「文脈（コンテキスト）」の無視とコードの重複
最も大きな問題は、既存コードとの整合性です。
既存のコードベースには、すでに「朝会の時間に予定が被っているかどうかを判定するメソッド」が存在していました。
しかし、Codexはその既存資産に気づかず（あるいは無視して）、似たような処理を行う新しい重複メソッドを勝手に実装してしまいました。
機能としては動きます。しかし、同じロジックが2箇所に散らばることは、保守性の観点から許容できません（DRY原則の違反）。AIは「その機能を実装すること」には集中しますが、「プロジェクト全体の設計思想や既存資産」までは読み取ってくれませんでした。
2. ロジックの破綻と現在時刻依存
カレンダー判定のロジックについても、最初はAIが生成した考え方自体が間違っており、期待通りに動作しませんでした。これについては、私が具体的な修正方針を伝えて直してもらいました。
さらに問題だったのは、修正後のコードが Date.now() （現在時刻）に強く依存していたことです。 外部依存が切り離されていないため、自動テストを書くのが極めて困難な状態になっていました。
3. 頼んでいないリファクタリング
指摘はしませんでしたが、機能追加とは関係のない箇所のフォーマット修正やリファクタリングが混入していました。AIは時折、頼んでいないことまで気を利かせて（あるいは文脈を無視して）行ってしまうことがあります。
このリファクタリングは、一見問題ないように見えますが、レビュー負荷を増大させる一因となっていました。普段エンジニアが目的外のリファクタリングを行うときはPR内で意図が説明されています。CodexはPR作成にかかわらせていないため、この意図の説明がありませんでした。そのため、レビュアーがその意図を推察する必要がありました。
考察とまとめ
教訓：AIコードの「テスタビリティ」問題
今回の経験から得られた最大の教訓は、「Vibe Codingを行うなら、テスト環境が必須条件である」ということです。
AIは「動くもの」はすぐに作れますが、「テストしやすいもの（保守性の高いもの）」を作ってくれるとは限りません。今回のように現在時刻への依存などを埋め込んでくることもあります。 AIに爆速でコードを書かせるなら、その検証も自動化（テストコード化）されていないと、検証コストが肥大化してAIのメリットが薄れてしまいます。
AIは「優秀な新入り」だが「空気は読めない」
OpenAI Codexのようなツールは、一般的なアルゴリズムや構文を書く能力は非常に高いです。 しかし、「既存のコードベースに合わせて、調和を取る」という整合性の担保は苦手です。
「朝会時間の判定」といったドメイン固有のロジックを、既存のクラスから再利用すべきか、新しく作るべきか。そういった判断は、まだ人間のレビューアが交通整理をする必要があります。 AIは「一般的によくあるコード」は書けますが、「このチームのこのプロダクトにとって正しいコード」を書くには、コンテキストの注入と人間のガイドが必要です。
これからのエンジニアの役割と、Aさんの成果
正直に言えば、単純な実装スピードだけを見れば、エンジニアがゼロから書いたほうが早かったでしょう。Aさんは他業務との兼務で多忙な中、細切れの時間を使って粘り強く取り組みましたが、着手から実装完了までには長い時間がかかりました。また、レビューする側としても、AI特有の「一見正しそうだが文脈が抜けているコード」を読み解くのは骨が折れました。
しかし、これを「コスト」と見るか「投資」と見るかで評価は変わります。
今回の取り組みで、「エンジニアのリソースを消費せず、非エンジニアがAIを活用して自力で機能追加を行える」という選択肢がチームに生まれました。 Aさんが、コードがどう動き、なぜ整合性が重要なのかを、実装プロセスを通じて体験したこと。この「共通言語」がチームに生まれたことこそが、今回の最大の成果です。
おわりに
現在、Aさんはこれらのレビュー指摘を受けて、コードの品質をさらに高めるためのブラッシュアップに取り組んでいる最中です。
「機能を作る」フェーズから、「良いコードを書く（選ぶ）」フェーズへ。 AIを相棒に、エンジニアとしての階段を駆け上がっていくAさんの挑戦を、これからもサポートしていきたいと思います。
