はじめに

生成AIの出現/進化で2025年は生成AIに頼りっぱなしになっていた。

何をするにも生成AIに質問して、その回答を時には鵜呑みにして、時には疑いを持って仕事に使っていた。

その中で生成AIの出してきたコードを信じ切って、検証を進めていたら自分で構造を把握できないために先輩方に総ツッコミを受けたり、自分がエンジニアとして成長できているのか疑問に感じる日が多々あった。

そのような悶々とした1年を過ごしてきて年末年始にタイトルの本が発売されたので、今の生成AI時代にどのようなエンジニアになるかメンタルモデルについて知れるかもしれないと思い手に取ることにした。

https://www.oreilly.co.jp/books/9784814401420/

1章 序論：バイブコーディングとは何か？

バイブコーディングとAI支援エンジニアリングの2つのアプローチがある。

バイブコーディング

  • AIが書いたコードはインターン生が書いたコードのように丁寧にレビューする。
  • バイブコーディングは、トップダウンで探索的。
  • バイブコーディングで重要なのはコンテキストウィンドウのサイズ。
    • Geminiは全てのAIモデルの中で最も長いコンテキストウィンドウを提供していて大規模プロジェクトに向いている。

「バイブコーディングは低品質の作業の言い訳ではない」と言い聞かせています。バイブコーディングは解決策の「開始」であるべきであり、終了ではないのです。

低品質の言い訳にしてはいけないのはその通り。

バイブコーディングは有効なユースケース

  • ゼロからのプロダクト開発
  • 機能のプロトタイピングと CRUDアプリケーション
  • グルー（つなぎ）コードと統合
  • 最新のフレームワークの活用
  • 繰り返しのコード生成

AI支援エンジニアリング

AI支援エンジニアリングは「動作する」コードを素早く得ることではなく、「高品質」のコードをより効率的に得ること。

  • AI支援エンジニアリングは、体系的で反復的。
  • 計画や仕様を書く->AIに的を絞ってプロンプトを送る->AIがスニペットを出力->レビューして、反復改善する。
  • 保守可能なプロダクトを作るならAI支援エンジニアリング

バイブコーディングはPdMやデザイナーが好む。経験豊富なエンジニアやエンジニアチームはAI支援エンジニアリングを好む(ミニPRDを書いている)。

開発者の役割が変わる

  • 構文を入力することで「何を」構築すべきかよりも、「なぜ」コードが動作するのかをレビューするようになる
  • 低レベルのスキルを失う可能性がある
  • ボイラーテンプレートの量産が得意な人の需要が減り、システム設計、コンポーネント統合、正しさを検証できる人の需要が増える。

AIが苦労する点

  • 非常に複雑なシステム
  • 低レベルの最適化とシステムプログラミング
  • 独自の、あるいはニッチなフレームワーク
  • 創造的なUI/UXデザイン
  • 意図と要件の解釈

利点

  • より高速な開発サイクル
  • プロトタイピングと実験の強化
  • すぐに利用できる知識
  • 一貫性と標準化

トレードオフになる関係

  • 変わりやすい出力品質
  • プロンプトの曖昧さがコードの曖昧さにつながる
  • 過度の依存とスキルの退化
  • プライバシーとセキュリティの懸念
  • AI出力のバイアス
  • 人的要因と信頼

2章 プロンプトの 芸術：AIと効果的にコミュニケーションする

伝わるプロンプトを書く

  • 例えば 「ソート関数を書いて」ではなく以下のように書く
（ そ れ ぞ れ が first_name、last_nameフ ィ ー ル ド を 持 つ ）顧 客 レ コ ー ド の リ ス ト を 受 け 取
り、last_nameを ア ル フ ァ ベ ッ ト 順 に ソ ー ト し た リ ス ト を 返 す、Python関 数 sort_by_
lastname(customers)を書いて。簡単な docstringを含め、空の文字列として扱うことで、姓が
ない場合に対処して。

具体性のための戦略

  • 言語や環境について言及する
  • 出力の範囲を定義する
    • 「関数の実装だけを提供して」と「実行可能なスクリプト一式を提供して」では、応答が異なる
  • 要件と制約を含める
  • 曖昧な参照を避ける
  • 望ましい出力形式を指定する

やってはいけないこと

  • 小説を書かない
    • よくある「あなたはxxxのスペシャリストです。」みたいなことはいらない。
  • AIが細部を正しく埋めてくれると想定しない
  • 決定論的な出力が必要な場合、制約のない「創造的な」プロンプトを避ける
    • 「データを分析するコードを書いて」だと何を分析すれば良いかわからない。「数値のリストの平均値と標準偏差を計算して」とかく。

プロンプトの書き方について

高度なプロンプトエンジニアリングは、満足するまで、プロンプト → AI出力 → レビュー → プロンプトを改良 → AI出力→…）のようになる

デバッグの場合は以下のようなプロンプトを投げる

これはラバーダックデバッグのプロンプト

この関数を 1行ずつ順を追って確認し、各手順で合計値を追跡して。正しく累計されていない。
どこで、ロジックが間違っている？

部分的に役にたたない場合は以下のようにフォローアップの質問をする

その説明は理にかなっている。コードの修正方法を教えてくれる？ 修正したコードを提供して。

プロンプトの種類

  • ゼロショットプロンプティング
    • 指示以外に例や追加の指針を提供することなく、モデルに何かをするように求めるだけ
  • ワンショットプロンプティング
    • プロンプトの一部として、欲しいものの例（入力と望ましい出力）を1つだけ提供すること
  • Few-Shotプロンプティング
    • いくつか（通常は2から5）の例を提供すること
  • メタプロンプティング
    • 解決策が何をすべきかだけでなく、出力自体について指示を与えること
    • あれ？でもプロンプトの組み合わせで「あなたはxxxのスペシャリストです」構文が出てきたぞ。この章に意味がないと言っていたけどな。

プロンプトに関するtips

  • あまり長すぎるタスクを書かない。分割する。
  • AIの出力が明らかにおかしい場合、同じプロンプトをそのまま再試行しない。少し時間を置いて、表現を調整する。
  • 効果的にコミュニケーションすれば、AIはより良いサービスを提供してくれる
  • 人とコミュニケーションするのと同じようにコミュニケーションをする。段階的に話を進めるように心がける。

3章 70 %問題：実際に動作する AI支援ワークフロー

AIツールの現状

  • AIは7割を作成してくるが残り3割を作成するのにものすごく手こずる。砂上の楼閣コード(ちょっとしたことで脆く崩れる)のようだと言っている。
  • AIツールが強力になるほど、単なるコーダーではなくシステムアーキテクトであり続けるための専門知識の維持が、より重要になる。
  • ソフトウェアの原理を深く理解することによってのみ、この驚くべきツールがエンジニアの能力を低下させるのではなく、むしろ向上させるようにすることができる

実践的なレベルでは、プロジェクトのREADMEに「AI使用のヒント」セクションを設け、そこで「私たちは関数コンポーネントのみを使います」や「AxiosではなくFetch APIを使うことを好みます」といったことを明記し、開発者がAIにプロンプトで指示する際に留意できるようにします。

プロジェクトのREADMEにAI開発のヒントを書いておくのはとても良い。

AI支援開発のベストプラクティス

  • 異なるタスクのために、新しいAIセッションを開始する
  • プロンプトを焦点を絞って簡潔にする
  • 頻繁に変更のレビューとコミットを行う
  • 緊密なフィードバックループを維持する
  • AIを使用する場合はブランチやコミットを分けるべき
  • 理解できないコードをマージしない
    • ほんとそれ
  • システム設計、デバッグ、アーキテクチャのスキルを養うことに集中

4章 70 %を超えて：人の貢献を最大化する

ミドルエンジニアのAIとの付き合い方

所感

もしジュニアスタッフが、AIの生の出力を単にあなたに渡してくるようなら、差し戻してください。彼らが、AIが生成した作業を最初に検証しなければならないプロセスを確立して、あなたが唯一の安全網ではなくなるようにしてください

そうだよね。ごめんなさい。

学習分野

ミドルエンジニアが以下の分野の高度な知識を得ることを含め、コンピュータサイエンスの基礎を深める

  • データ構造とアルゴリズム
  • 分散システムの原則
  • データベースの内部構造とクエリの最適化
  • ネットワークプロトコルとセキュリティ

ドメイン知識をつける

ミドルエンジニアはドメイン知識を特化させる。

  • 規制要件のある金融システム
  • プライバシーに関わる医療システム
  • パフォーマンス要件が厳しいリアルタイムシステム
  • 機械学習の基盤

システムが本番環境でどのように動くか理解する

システムが本番環境にどのように動作しているか理解することが価値がある。

  • 監視と可観測性
  • パフォーマンスのプロファイリングと最適化
  • セキュリティのプラクティスとコンプライアンス
  • コストの管理と最適化

横断的なコミュニケーションがますます有効

  • 要件の収集と分析
  • 技術文書の作成と文書化
  • プロジェクトの計画と見積もり
  • チームのリーダーシップと指導

ジュニアエンジニアのAIとの付き合い方

付き合い方

  • 例えば、AIがあなたにコードの一部を示したら、「なぜ」そのアプローチを選んだのかを尋ねたり、コードを一行ずつ説明させたりしてください。

    • すっごく大事！！
  • 「AIなしの日」を作る 開発力養うため
  • AIに実装を頼む前に、自分で平易な言葉で解決策を概説してみる
  • AIを、超強力なStack Overflowのようなものだと考える
  • AIが提案した内容と異なる場合には特に、なぜ一方の解決策を選ぶのかをシニア開発者に遠慮なく尋ねる
  • AIの出力を、すべての質問を終わらせる回答としてではなく、対話型の学習教材として扱うこと

学習分野

  • システム設計とアーキテクチャの専門知識を強化する
  • システム思考を実践し、全体像のコンテキストの理解を維持する
  • 批判的思考、問題解決、先見性のスキルを磨く
  • 専門ドメインにおける専門知識を築く
  • コードレビュー、テスト、デバッグ、品質保証を行う
  • コミュニケーションと協働のスキルを向上させる
  • 変化に適応する
  • 継続的に学習し、基礎を固めながら、新しいスキルを身につけ、知識を更新する
  • AIを使う

5章 生成されたコードを理解する：レビュー、改良、所有

所感

注意深く、コードを全部読んでください。あなたの頭の中で、あるいは紙の上で、そのコードをステップ実行してください。

自分が想像していた意図通りの処理なのか確かめる

（一般的な場合に対応するため）やや冗長なスタイルでコードをレイアウトする

確かにこれはよくあるな。

気を付けるべき他の潜在的な問題

  • オフバイワンエラー
  • 未処理の例外
  • パフォーマンスの落とし穴
  • ライブラリの使用
  • 非一貫性
  • 構文のちょっとした問題
  • 時代遅れのAPIの使用
  • プレースホルダー

デバッグのための6段階のアプローチ

  • 問題を再現する
  • 問題の原因を突き止める
  • プロンプトをコードと照合する
  • デバッグにAI を活用する！
  • コードを修正する
  • 再度、テストする

リファクタリング向けの6段階のプロセス

  • スタイルのガイドラインに合わせる
  • 名前付けと構造を改善する
  • 不要な部分を除去する
  • ドキュメントを追加する
  • 必要に応じて最適化する
  • 必要なら単純化する

6章 AI駆動プロトタイピング：ツールとテクニック

所感

vercel v0というツールがあるのか https://v0.app/

純粋な「経験と勘による」バイブコーディングよりも責任あるアプローチを提唱しているが、早いフィードバックサイクルは間違いなくプロトタイプに取り入れるべき

プロトタイプをAIで作らせるのは効果的

シェーンが小さなwebアプリをプロトタイプで作らせ、それを強化していく話がよかった。

気をつけること

プロトタイプに「もう1つ」追加して、どんどん進めたくなることがある。これを「スコープクリープ」という。

プロトタイプを作ることがゴールではない。あなたが答えたい重要な質問や、実証すべき中心的な体験に焦点を絞ることです。

7章 AIでウェブアプリケーションを構築する

協働を最適化するための戦略

  • ボイラープレートにAIを使い、カスタムロジックを自分で書く
  • AIを使って、やることリストに1つずつ取り組む
  • AIにプロンプトで指示して、コード品質を向上させる
  • AIを使って、再確認を行う
  • AIを使って、あなたのチームと調整する

tips

  • JavaScript、Python、Javaといった人気の言語は、トレーニングコーパスにオープンソースリポジトリ、ドキュメント、教材が豊富に含まれているため、通常、強力なサポートを得られる
  • AIを常に利用可能なペアプログラマーとして扱う

8章 セキュリティ、保守性、信頼性

AIが生成したコードに見られる典型的なセキュリティ問題

  • ハードコードされた秘密や認証情報
  • SQLインジェクションの脆弱性
  • ウェブアプリでのクロスサイトスクリプティング（XSS）
  • 不適切な認証認可
  • 安全でないデフォルトや構成
  • 機密情報が漏れるエラー処理
  • 依存関係の管理と更新

セキュリティの対策

  • 別の AIをレビュアーとして使う
  • 以下のようなチェックリストを使う
□認証フロー：それらは堅牢ですか？
□データがシステムに入るあらゆる場所：入力を検証していますか？
□データがシステムから出るあらゆる場所：出力をサニタイズしていますか？ 機密データを保護
していますか？
□外部APIの使用：失敗に対処していますか？ キーを公開していませんか？
□データベースへのアクセス：ORMを安全に使っていますか？ パラメーター化されたクエリを
使っていますか？
□低レベルコードのメモリ管理：AIがC/C++やRustを書いている場合、オーバーフローはあり
ませんか？ 誤用はありませんか？
  • ペネトレーションテストとファジングを行う
  • セキュリティに焦点を当てた単体テストを追加する
  • トレーニングカットオフを補う更新を提供する
  • ロギングの最適化
  • セキュリティに重点を置いた、更新されたモデルやツールを使う
  • コンテキストにおける警告に注意を払う
  • 速度を落とす
    • 徹底的なレビューのための時間をスケジュールする
  • 追跡可能性のために「2025/05/01にGPT-4の助けを借りて生成した」とコメントするチームもある

所感

「AIが書いて、テストを通過した」という理由だけで、コードが正しいと想定しないでください。批判的に考えて、ロジックの推論を試みてください。

はい。。。

「信頼せよ、されど確認せよ」（Trust but verify）

AIを使う上でとても大事なので覚えておく。

9章 バイブコーディングの倫理的課題

所感

忘れてはならないのは、AIの知識の裏側には、コードを公開してきた何千人もの開発者たちの貢献があるということ

「はい、AIを使いましたが、徹底的にテスト済みです」や「この部分は難しかったので、AIに初期コードを生成させた後、私たちで検証しました」といった説明

同僚にこのように説明することが大事。

一部の開発者は、AIの助けを借りたことを認めると、自分の貢献やスキルが過小評価されたり、「不正行為」とみなされたりするのではないかと恐れるかもしれません。しかし、バイブコーディングが一般化するにつれて、このような汚名は次第に薄れていく

時代が変われば評価も変わる

あまり意識していなかったが、生成AIにも多様性という観点は確かに必要か。

責任あるAIチェックリストがついていて便利

開発プロセスのさまざまな段階でバイアスを認識、緩和する方法

  • 多様な例によるテスト
  • 包括性のためのプロンプティング
  • 多様なチームを雇う

バイブコーディングにおける一連の責任あるプラクティス

  • 常にヒューマンインザループを維持する
  • 自分のコードに責任を持つ
    • 「わからない、GitHub Copilotがそうした」と答えない
  • ユーザーのプライバシーを守り、同意を求める
  • 法律や規制を遵守する
  • 組織内に責任あるAI 文化を醸成する
  • ガードレールと安全網を作成する
  • チーム内でAI の使用に関する決定を文書化する
  • バイアス、差別、不公平を避けるために積極的に取り組む
  • 著作権的な観点で生成AIの出力が不安なら「ライブラリからのコピーではなく、独自の実装を提供して。」と命令する。

10章 自律型バックグラウンドコーディングエージェント

所感

Google Julesなんてコーディングエージェントがあるんだ。 https://jules.google/

エージェント固有のレビューチェックリストを整備することを検討する

エージェントと作業する中で見つけたよくある癖を記録しておく

11章 コード生成を超えて：AI拡張開発の未来

AIが可能にすること

  • タスク配分
  • スケジューリングとスプリント計画
  • リスク分析と管理
  • 意思決定の支援
  • 自然言語によるステータスクエリ
  • 感情やチームの健康状態の把握

「プログラミングの未来は、もはや完璧なコードを書くことではないのかもしれません。むしろ、自分の望みを完璧に説明することなのかもしれません」。

確かに。

基本的な原則やアイデア

  • 実装よりも意図を重視する
  • 協働パートナーとしてのAI
  • 倫理と責任
  • AIはコード生成を超える
  • スキルは進化し続けているが、基礎は不変である

読者であり実践者であるあなたにできる行動

  • 実験する
  • 発見を共有する
  • ツールに貢献する
  • 前向きな変化を提唱する
  • 生涯にわたって学ぶ姿勢を持ち続ける
  • 熱意と慎重さのバランスを取る
  • 次世代を指導する

根本にあるのは、コーディングは常に創造と問題解決のための営みだということ

終わりに

とても多くのことを学ぶことができた。

特にAIと共同して仕事をこなしていくには、AIが書いたコードを常に批判的な目線で疑うことがチームのため、自身のためになることを改めて学ぶことができた。

この本と通してコードの背景やアーキテクチャの選定理由を詳しく解説してくれる、Claude Codeのスラッシュコマンドを作成することができた。

https://github.com/jacoloves/dotfile/blob/master/.claude/commands/digger.md