はじめに
こんにちは、現役でSaaSの開発をしているプロダクトエンジニアです。
ここ最近、開発プロセスの中にAIを組み込むことが当たり前になり、エンジニアの仕事の仕方も大きく変化していると感じています。
AIを活用した開発の最大のメリットの一つに 「検証スピードの圧倒的な向上」 があげられます。
不確実性を下げるために、まずは動くもの（PoC）を作ってスプリントレビューなどでフィードバックをもらう、という開発スタイルが定番化していました。
しかし、AI開発のパラダイムが変わる中で、私はある 「罠」 に陥っていることに気づきました。
「とにかくトークンを使え」というフェーズの終焉
ここ数年、市場全体が「とにかくAIで何かやれ」「技術検証を兼ねてトークンをガンガン使え」という、いわば「祭り」のようなフェーズにありました。
しかし、そのトレンドは完全に変わりつつあります。
Forbes Japanの記事でも指摘されているように、現在は世界的に 「生成AIの投資対効果（ROI）」への視線が急速にシビアに なっています。
参考記事：
「生成AI」の投資対効果に高まる企業の不満、期待過剰の「幻滅期」に突入か | Forbes JAPAN 公式サイト
これまでは「AIを動かすこと」「最先端の技術に触れること」自体が評価されていましたが、これからは 「かけたコスト（開発リソース、トークン費用）に見合うビジネス成果」 が厳しく求められる成熟期に入っています。
そんな中で自分の開発を振り返ると、いつしか「スプリントレビューで動くものを見せること」自体が目的化し、 何を検証するべきPoCなのかが曖昧なまま、手当たり次第に実装して（トークンを消費して）しまっていた 自戒があります。
その検証は本当に「実装して動かす」必要があるのか？
不確実性を下げるためにプロトタイプを作るアプローチ自体は、今でも極めて重要です。
しかし、「目的の明確化」 と 「最適なアプローチの選択」 を考える必要があります。
手軽に作れるからこそ、使い所を考えて「最小限のコストで最大のリターン（確実性）」を得られる手法を選択する必要があります。検証のグラデーションを意識すると、アプローチは以下のように整理できます。
| 検証したい目的 | 必要なこと | 最適なアプローチ | コスト |
|---|---|---|---|
| ユーザーのニーズ・UX | 画面の触り心地や、業務への馴染みやすさを見る | Figmaのプロトタイプ（動かせるモック） | 極小 |
| システム統合・性能 | 既存システムとの連携やレスポンス速度を見る | ここで初めて、コードを書くPoC | 大 |
「動くものを作る」のは、あくまで検証の手段の一つに過ぎません。
一番コストの高い「コードを書いて実装するPoC」を最初から選択するのは、今や悪手になり得ます。
思ったこと
「目的を研ぎ澄まし、いかに無駄な実装をせずに不確実性を下げる」考え方は、AI活用が進んだために生まれた課題ではなく、それ以前の開発スタイルでも考えていたことのはずです。
AIという強力なツールを銀の弾丸的に捉えてしまっていた節があると反省しています。
- このPoCの目的（何を検証したいか）は明確か？
- それは本当に実装しないとダメなのか？Figmaで代替できないか？
開発を始める前に、一度立ち止まってこの問いを自分に投げかける癖をつけていきたいです。