「バイブコーディング」で終わるな Googleエンジニアが説くAI時代のプロフェッショナル論

Google Cloudのケーシー・ウェスト氏が自身のブログで「Agentic Manifesto」（エージェンティック・マニフェスト）を発表した。マニフェストの真意、これからの時代の開発者へのメッセージなどについて聞いた。

[末岡洋子，ITmedia]

　ソフトウェア開発の歴史はパラダイムシフトの連続だった。1970年代に確立したウオーターフォール開発は、厳格な要件定義と段階的な開発プロセスで大規模システムの構築を可能にした。だが、変化への対応が難しいなどの課題から、2001年に17人のソフトウェア開発者が「Agile Manifesto」（アジャイル・マニフェスト）を発表し、反復的で柔軟な開発手法への転換を促した。

Google Cloud ケーシー・ウェスト氏（筆者撮影）

　2025年11月1日、Google CloudのCasey West氏（以下、ウェスト氏）が自身のブログで「Agentic Manifesto」（エージェンティック・マニフェスト）を発表した。自律的に判断し行動するエージェンティックAIの台頭を受けてのものだ。「50年間、われわれはコードを書けば結果を制御できるという前提に依存してきた。だが、その時代は終わりつつある」という。

　同氏がエージェンティック・マニフェストを発表した直後に、SAPがドイツ・ベルリンで開催した「SAP TechEd」で、ウェスト氏に話を聞く機会があった。マニフェストの真意、これからの時代の開発者へのメッセージなどについて意見を聞いた。

決定論から非決定論へ　ソフトウェア開発の前提が変わる

　ウェスト氏は、Google Cloudでリード デベロッパー アドボケイトを務める他、開発組織の世界的指標である「DORA（DevOps研究プログラム）」にも深く関与している。また、GoogleとSAPの技術提携（「BigQuery」と「SAP S/4HANA」の連携など）を通じ、エンタープライズ領域におけるAI活用について支援をしている。

　エージェンティック・マニフェストの作成に至ったのは、DORA 2024年版レポートが示した矛盾がきっかけだった。AI導入によってエンジニアのコーディング速度は向上したものの、組織全体のソフトウェアデリバリーパフォーマンスは改善しなかったのだ。

　「過去2〜3年、私は組織がAIを採用、構築するのを支援してきた。従来のソフトウェア開発とは少し異なるシフトがあると感じた」（ウェスト氏）

　そこで、2001年のアジャイル・マニフェストを起点にAI時代の開発原則の再定義を試み、エージェンティック・マニフェストを作成した。アジャイル・マニフェストが開発プロセスの俊敏性を変えたように、エージェンティック・マニフェストはシステムの本質的な性質の変化に対応するものだ。

　アジャイル・マニフェストも「コードを書けば出力は予測可能」という決定論的な前提は変わらなかった。しかしエージェンティックAIは本質的に非決定論的な動きをする。つまり、同じ入力でも異なる出力を生成し、コーディングされていない創発的な振る舞いをする。

　「従来のソフトウェア開発では、アジリティの時代でさえ、多くの構造や直接的な手動管理、バイナリテスト、決定論的システムに焦点を当てている。しかしエージェンティックな環境では、自律的な改善と継続的なチューニング、ガードレールとメトリクスで考える必要がある」

　さらに重要な違いがある。アジャイル開発におけるテストは「言った通りに動いたかどうか」を確認するものだった。しかしエージェンティックシステムでは「やって欲しかったことをやったかどうか」を測定する必要がある。「検証（verification）の世界から妥当性の確認（validation）の世界へ移行している」とウェスト氏は指摘する。

　もう一つの重要な違いは、開発の工程を示す「デリバリー・ライフ・サイクル」の在り方だ。ウェスト氏は「これまでのライフサイクルは、アイデアを本番環境へ実装するためのビジネスプロセスを体系化したものだ。しかし、エージェンティックなシステム開発においては、その前提が根本から覆る」と指摘する。

　「解決しようとしている問題に関するビジネスの深い理解を、最初からプロセス全体を通じて持ち込む必要がある」とウェスト氏は話す。

　「従来は、ビジネス側が適切な要件を提示できれば、エンジニア側はそれ以上の介入を求めずとも本番実装まで完結させられた。しかしAIによる開発では、ビジネスの課題をプログラミング言語ではなく、英語や日本語といった自然言語で解決していく。解決策を記述する言葉自体がビジネスの言語である以上、開発ライフサイクルのあらゆる段階にビジネスの深い専門知識が必要になる」

　「ビジネス側からの継続的なインプットを欠いたエンジニアリングチームは、AI時代において決して成功を収めることはできない」とウェスト氏は話す。AIの登場によってその重要性は増している。

エージェンティック・マニフェストの核心――4つの価値観とADLC

　エージェンティック・マニフェストは、4つの価値観と12の原則、そして新しい開発ライフサイクル「ADLC」（Agentic Delivery Lifecycle：エージェンティック・デリバリー・ライフサイクル）で構成される。マニフェストが掲げる価値観は以下の4つだ。

1．「事前定義」から「創発」へ

　エージェンティックAIは、明示的にコーディングされていない創発的な振る舞いをする。「従来は厳格な命令と統制が必要だったが、非決定論的な性質により、ガードレールとメトリクスで考える必要がある」とウェスト氏は説明する。

2．「静的要件」から「動的ゴール」へ

　厳格な機能仕様ではなく、柔軟な目標状態を定義する。マニフェストは、エージェントの動作を正確に定義するのではなく、絶対に超えてはいけない境界線と、達成すべき目標というインセンティブ構造を定義することを推奨する。ビジネスにおける自然言語で問題を解決するため、ビジネス専門家が開発ライフサイクル全体に深く関与する必要があるとウェスト氏は強調した。

3．「バイナリテスト」から「継続的チューニング」へ

　従来のコードカバレッジ指標を、「Well-Curated Evaluation Suite」（よく整備された評価スイート）に置き換える。大規模でバージョン管理されたシナリオや、敵対的プロンプト、質的スコアリングの集合だ。マニフェストは、これが非決定論的システムを客観的に測定し、プロンプトチューニングによる「見えないリグレッション」を検出する唯一の方法と指摘する。マスタープロンプトへの小さな調整や、RAG知識ベースへの1文書の追加が、システムの「パーソナリティー」を根本的に変えてしまう可能性があるからだ。

4．「手動管理」から「自動化されたガバナンス」へ

　ウェスト氏は「自律エージェントが財務的または評判的な損害を引き起こす行動を取ったとき、『モデルがハルシネーションをした』という根本原因分析では受け入れられない」とする。

　ハルシネーションを軽減する技術や手法は既に存在しており、「本番環境レベルのエンタープライズ環境でAIを提供するなら、それらを実装する必要がある」と断言する。Googleが提供する「Model Armor」といったプロンプトインジェクション攻撃や機密データの流出を防ぐセキュリティツールもその一つだ。

ADLC:　Agentic Delivery Lifecycle

　これらの価値観を実現するため、マニフェストは従来のSDLC（Software Delivery Lifecycle）に代わるADLCを提案する。ADLCは5つのフェーズで構成される。

　フェーズ1は厳格な機能仕様ではなく、倫理的ガードレールとエスカレーションパスを確立する。フェーズ2と3は「Inner Loop」を形成し、プロンプトエンジニアリングや知識ベース構築、ツール統合により、エージェントの環境を整備し（フェーズ2）、評価スイートで行動を検証する（フェーズ3）。フェーズ4でカナリアリリースと段階的展開によって本番環境に導入する。

　そしてフェーズ5が「Outer Loop」だ。「これがADLCの心臓部だ。従来のソフトウェアでは『メンテナンス』はコストセンターだが、エージェンティックシステムでは、この『Outer Loop』はメンテナンスではない。ROIの主要エンジンだ」とウェスト氏は強調する。

　本番環境での相互作用を継続的に監視し、チューニング機会を特定する。このフェーズはフェーズ2に戻り、システムは継続的に価値を高める資産となる。

バイブコーディングは通用しない　エンタープライズAI開発の現実

　開発現場にもAIの波は押し寄せている。自然言語で対話しながらAIにコードを生成させる「バイブコーディング（Vibe Coding）」だ。だがウェスト氏は、エンタープライズの開発におけるバイブコーディングの限界を指摘する。

　「AIモデルは指示に従うのが得意だ。十分なコンテキストと情報を与えれば良い結果を出すだろう」とウェスト氏は認める。ただし「25年のキャリアを持つプロフェッショナル開発者の目から見ると、1年目のインターンが出すような結果を出すことが多い」という。エンタープライズが求める高品質、保守性、信頼性などの要求を満たすことはできないというのだ。

　「バイブコーディングモデルは、一見すると完成したソリューションに見えるが、実装を実際に見て検証しなければ、トラブルに巻き込まれる可能性がある」。実際、組織がAIソリューションを提供して予期しない動作をした公開事例も存在する。

　ウェスト氏もAIコーディング支援ツールを使用したものの現実は厳しいと話す。「エンジニアとしてソリューションを提供する速度は上がったと思う。しかし、それでも非常に手間がかかる。多くのガイダンス、多くのコンテキストを提供する必要がある」。インターネットで話題になるような“魔法のツール”ではなく、プロフェッショナルとして使いこなすには依然として深い専門知識と労力が必要だという。

　「バイブコーディングをして、それが本番グレードだと考えるタイプのエンジニアなら、AIに置き換えられるだろう。しかし、ソフトウェアエンジニアリングをプロフェッショナルな視点から考え、信頼できるシステムを構築するために必要な厳格さを理解しているなら、AIに置き換えられない。AIをエンパワーメントと加速のためのツールとして使える」

　「チームに信頼できるセーフガードとガードレールを構築する機会を与えることが重要だ」とウェスト氏は語る。評価スイート、プロンプトエンジニアリングとコンテキストエンジニアリングのガードレール、適切なコンテキストの提供。これらの技術と手法を実装することで安全を保てる。

レガシーシステムを抱える企業のAI戦略

　レガシーシステムを抱える大規模組織にとって、AI導入は新たな課題だ。ウェスト氏はオーストラリア政府のデジタル化でアドバイザリー業務を経験しており、この問題に精通している。

　「レガシーシステムは『古い』『悪い』と言われがちだが、実態は違う。ミッションクリティカルでビジネスクリティカルなシステムだ。長年使われ続けているのは、まさに企業の収益を支えているからだ」。

　ウェスト氏は自身のマイクロサービス移行の経験が参考になると指摘する。

　「大規模なモノリシックシステムを小さなマイクロサービスに分解する動きがあったが、その狙いは技術そのものではなく、組織や開発チームの働きやすさの改善だった。大きく複雑に絡み合ったシステムを、小さく独立したサービスに分けることで、各サービスの開発や保守が容易になる」

　具体的な移行戦略として、段階的に古いシステムを置き換える「Strangler Pattern」（ストラングラーパターン）や新しいインタフェースで古いシステムを覆う「Facade」（ファサード）といったソフトウェア設計パターンを挙げる。レガシーシステムをモダナイズしたい場合、一度に全てを変えるのは高コストでリスクが高すぎるため、段階的に進めるのが現実的だとウェスト氏は説明する。

　AI統合でも同様だ。AIを新しいフロントエンド、新しいファサードとして既存システムの上に載せていく形だ。

　ただし簡単に進むとは見ていない。「レガシーシステムは収益源だ。移行には時間とコストがかかるだろう」とウェスト氏は語る。

開発者に求められるスキル――ツールではなく問題理解を

　ウェスト氏は学生や若手開発者へのメッセージとして、継続的な学習の重要性を強調する。

　「経験年数に関わらず、新しいことを学び続けること。欲を言えば、素早く学べることが重要だ」とウェスト氏は強調する。AIツールを正しく使えば、学習を加速できる。逆に「継続的に学んでいない開発者は、仕事を維持するのが難しくなる」という厳しい指摘もした。

　「特定のツールや技術ではなく、将来も持続する技術と実践に焦点を当てる必要がある。プロンプトエンジニアリングやコンテキストエンジニアリングのようなスキルは持続する。しかし、『Gemini』か『Perplexity』か、『ADK』（Agent Development Kit）かMCP（Model Context Protocol）かといった具体的なツールは、そのうち新しい技術に置き換えられる可能性がある。特定のツールチェーンを使いこなすのではない。解決すべき問題を深く理解する必要がある」

　最も重要なのがドメイン知識だ。ウェスト氏は「AI導入で最も重要なのは、解決すべき問題についての深い専門知識だ」と強調する。その知識は、エンドユーザーや顧客が持っていることもあれば、プロダクトマネジメントチームやカスタマーサービスチームが持っていることもある。

　「ドメインを最も理解している人々と継続的に関わっていないエンジニアリングチームは、高品質なAIソリューションの提供に失敗する」

　ウェスト氏はエージェンティック・マニフェストが少しでも広まり、開発者をはじめAIを実装する企業の助けになればいいと述べる。マニフェストは最後に、技術リーダーに向けて次のように記している。

　「技術リーダーの仕事は変わった。コードを書いて機械を作るだけではなく、AIエージェントが適切に振る舞うようガバナンスする役割が求められる。その認識で取り組むべきだ」