AI拡張型開発の実践：Cloudflare Pages Functions実装での失敗と学び

はじめに

AI拡張型開発を実践している中で、興味深い事例に遭遇しました。Cloudflare Pages Functionsを使った不動産問い合わせフォームの実装で、AIが陥った典型的な失敗パターンと、人間のエンジニアリング経験がどのように問題を解決したかを共有します。

実装タスクの概要

既存のシステム開発用問い合わせフォーム（otoiawase-form.ts）が稼働している状況で、新たに不動産専用の多言語対応問い合わせフォーム（real-estate-contact.ts）を実装する必要がありました。

要件：

• Cloudflare Pages Functions使用
• Gmail API経由でのメール送信
• 日本語・英語・中国語の多言語対応
• 既存の動作実績のあるコードが存在

AIが陥った典型的な失敗パターン

1. 過度な抽象化と複雑化

AIは最初に以下のような提案をしました：

functions/
├── real-estate-contact.ts
├── templates/
│   ├── real-estate-email-ja.txt
│   ├── real-estate-email-en.txt
│   └── real-estate-email-zh-CN.txt
└── utils/
    └── email-utils.ts  # メール関連ユーティリティ

私の指摘：「email-utils.tsは何でしょうか？必要ですか？」

シンプルな要件に対して、不要な抽象化層を追加しようとする傾向がありました。

2. 動作実績のあるコードを無視

最も顕著だったのはJWT署名の実装です。隣に動作しているotoiawase-form.tsがあるにも関わらず、AIは独自のbase64url実装にこだわり続けました：

// AIが提案した複雑な実装
function base64UrlEncode(buffer: ArrayBuffer): string {
  // 独自の複雑な実装...
}

// 実際に動いているシンプルな実装
const base64url = btoa(JSON.stringify(header)) + '.' + btoa(JSON.stringify(claimSet));

3. エラーの表面的な解釈

「invalid JWT signature」というエラーに対して、AIは署名アルゴリズムの修正に執着しました。実際の原因は環境変数の設定ミスという単純なものでした。

人間の判断がAIを導いた瞬間：経験が介在した2つの転換点

転換点1：実用主義の視点

私：「非効率です！otoiawase-form.tsは稼働している実績のあるコードです。これと同じにすればいいだけでは？」

この一言で、AIは複雑な独自実装から、動作実績のあるコードの流用に方針を転換しました。

転換点2：過去の知識資産の活用

私：「src/content/blog/tech/tech009-gmail-with-cloudflare-implement.mdx こちらも参考にしてください。」

自分が過去に書いたブログ記事を参照することで、AIは正しい実装パターンを理解できました。

AI拡張型開発における教訓

1. AIの強みと弱み

AIは確かに広範な知識を持ち、即座にコードを生成できる能力があります。多様なアプローチを提案し、人間なら疲れてしまうような試行錯誤も延々と続けることができます。しかし、この「知識の豊富さ」が逆に弱点にもなっています。

AIは実用性より「正しさ」を優先する傾向が顕著です。今回の例でも、既に動作している実装があるにも関わらず、「より正しい」base64url実装にこだわり続けました。動作実績の価値を理解せず、エンジニアリングにおける最も重要な判断—「時間対効果」を考慮できないのです。

2. 効果的な協働パターン

1. AIが複雑化し始めたら止める

   • 「もっと簡単な方法はないか」と問い直す

2. 動作実績を最優先する

   • 「これと同じにすればいいのでは？」という指摘

3. 過去の資産を活用する

   • ブログ記事、ドキュメント、動作コードの提示

4. 違和感を大切にする

   • 「このコード変じゃない？」という直感

3. AIの「中級者的限界」と人間の成熟度

興味深いことに、AIの振る舞いは中級エンジニアの段階で止まっています。エンジニアの成長過程を見ると、初級者はサンプルコードをただコピペするだけで、なぜ動くのか理解していません。中級者になると、すべて自分で実装したがり、サンプルコードを使うことを「負け」だと感じます。そして上級者は、実績のあるコードを賢く活用し、本当に重要な部分に時間を使います。

AIは永遠にこの「中級者」の段階に留まっているようです。自分で解決しようとし、プライドが高く、「正しい実装」にこだわり、5分でコピーして解決できることに1時間以上費やしてしまう。初級者ならむしろ素直にコピペしているでしょう。

プロトタイプと実用システムの決定的な違い

AI開発ツールには様々な種類があります。人間が主導する「拡張型」から、AIがより自律的に動く「駆動型」まで。しかし、どのツールを使うかより重要なのは、使う人間のエンジニアリング能力です。

プロトタイプやモックアップの作成はAIツールの得意分野です。しかし、そこから実用に耐えるシステムへのブラッシュアップには、必ずエンジニアリングが必要です。エンジニアリングを知らない人には、この本質的な違いは理解できません。「どちらも動く」という表面的な共通点しか見えないのです。

エンジニアリングの本質を見失った現代の開発現場

今回の事例は、単なるAIの限界を示すだけでなく、現代の開発現場が抱える根本的な問題を浮き彫りにしています。「動けばいい」という発想は、一見実用的に見えますが、実はエンジニアリングの放棄です。

料理の世界で例えるなら、忙しい主婦が「食べられればいい」と作る料理と、プロの料理人が作る料理の違いです。見た目は同じ「カレー」でも、素材の選定、下ごしらえ、火加減、スパイスの配合—すべてに理由があり、その積み重ねが「プロの仕事」になります。

同様に、エンジニアリングにも「なぜこのアーキテクチャなのか」「なぜこの実装方法なのか」という理由があるべきです。しかし現代の開発現場では、Stack Overflowからコピペして「動いたからOK」で済ませる人が増えています。これはプロとしてあるまじき行為です。

皮肉なことに、AIもまた別の形でエンジニアリングを理解していません。「動けばいい」の対極にある「理論的に正しければいい」という罠に陥っています。どちらも本質を見失っているという点では同じです。

まとめ：エンジニアリングの本質とAI時代の開発

AI拡張型開発は強力なアプローチですが、その効果は使う人のエンジニアリング能力に完全に依存します。今回の事例が示すのは、AIも現代の多くの開発者も、エンジニアリングの本質を理解していないという現実です。

AIは「理論的正しさ」に固執し、多くの開発者は「動けばいい」で思考停止する。どちらも、エンジニアリングの核心である「限られたリソースで最大の価値を生み出す判断」ができていません。これはノーコード・ローコードツールの限界と同じ構造です—道具は使う人のレベル以上のものを作れません。

（※技術的な補足：AIが「理論的正しさ」に固執するように見えるのは、実際には学習データに含まれる「教科書的な実装パターン」を再現しているに過ぎません。パターンマッチングと論理的推論の組み合わせでは、「動作実績のあるコードを優先する」といったエンジニアリング判断は学習できないのです。）

35年の経験から言えることは、エンジニアリングとは「判断の技術」だということ。その判断力は、失敗と成功、悔しさと達成感の積み重ねからしか生まれません。「AIが1時間かけて解決できなかった問題を5分で解決した」—これは、経験に基づく判断力の価値を示す証明です。

しかし、これは悲観的な話ではありません。むしろ、真のエンジニアリング能力を持つ人にとって、AIは最強の増幅器になります。重要なのは、AIを「知識豊富だが経験不足の中級エンジニア」として適切に導くこと。そのためには、エンジニアリングの本質を理解し、適切な判断ができる人間が不可欠です。

AI時代だからこそ、本物のエンジニアリング能力の価値は高まっています。ツールに振り回されるのではなく、ツールを使いこなす。そのために必要なのは、エンジニアリングを知る人たちから学ぶことです。知識も大事ですが、エンジニアリングは現場でしか習得できません。「なぜ」を問い続け、失敗から学び、経験豊富なエンジニアの判断を観察し、その思考プロセスを理解する—これこそが成長への道です。

これがAI拡張型開発の現実であり、可能性でもあります。

参考記事

• Gmail API with Cloudflare Workers 実装ガイド

この記事は、実際のAI拡張型開発セッションの記録を基に執筆しました。