Claude Codeでアプリを作って見えた「AIコーディングの限界」

AIでコードが書ける時代になった。GitHub Copilot、Cursor、Claude Code——ツールは急速に進化し、「プログラミング経験がなくてもアプリが作れる」という言説が広がっている。

自分は大学教員で、プロのエンジニアではない。それでもClaude Codeを使って、ペルシア語学習アプリ、英語学習プラットフォーム、投資分析ツールなど複数のアプリを実際に動くところまで作ってきた。AIコーディングの恩恵を実感している側の人間だ。

だからこそ書ける。AIコーディングには明確な限界がある。

「動くコード」は書ける。「意図通りのコード」が書けない。

Claude Codeに「発音が悪くても次に進めるようにして」と頼んだ。返ってきたのは、発音スコアを完全に無視して何でも通す実装だった。「進める」を「全部通す」と解釈したのだ。

修正を頼む。今度は「2回失敗したらスキップ」。方向としては悪くないが、求めていたのはそういうことではなかった。Speakアプリのように、話せば基本的に進むが単語ごとに色分けフィードバックが出て弱い部分がわかる——そういうバランスだ。

これがAIコーディングの核心的な問題だ。自然言語の指示は常に解釈の余地を含む。人間の開発者なら「ああ、Duolingoみたいな感じね」と通じるニュアンスが、AIには通じない。通じないどころか、通じたふりをして極端な実装をしてくる。

修正が破壊的

1箇所直してほしいだけなのに、周辺のコードまで書き換える。動いていたものが動かなくなる。型エラーが出る。UIが崩れる。「使えたものが使えなくなる」——この感覚は、AIコーディングを実際に体験した人なら誰でも知っているだろう。

既存の正解を忘れる

ペルシア語アプリの「声に出そう」機能でWhisperが使われていた。しかし同じアプリのシャドーイング機能では、Azure Speech SDKのPronunciation Assessment——まさに求めている機能——が既に実装されていた。AIはコードベース全体にアクセスできるのに、既存リソースを活用する判断ができない。

コンテキストが長くなると迷走する

会話が長くなると、品質が目に見えて落ちる。初期の指示を忘れる。同じ提案を繰り返す。さっき否定された方向にまた進む。100万トークンのコンテキストがあっても、会話の初期の重要な決定が後半では事実上「圧縮」される。

「どう伝えればいいかわからない」問題

最も根本的な問題はユーザー側にある。「Speakアプリみたいにして」——人間同士なら通じる。しかしAIには「話した後に単語ごとの色分けフィードバックを表示し、緑は80%以上、黄は40%以上…」くらいの粒度が必要になる。

コーディングにおけるプロンプトは、単なる文章術ではない。ソフトウェア設計の解像度そのものだ。

それでもAIコーディングを使う理由

自分はプロのエンジニアではないが、Claude Codeを使って複数のアプリを本番環境にデプロイしている。Next.js、Supabase、Stripe、Azure Speech SDK——フルスタックアプリケーションを数日で形にできる。10年前なら考えられなかったことだ。

重要なのは「AIに任せきりにしない」こと。AIはコードを書く道具であって、設計者ではない。AIが書いたコードを読み、理解し、必要なら手で修正する。この姿勢がなければ、AIコーディングは「動くが意図と違うもの」を量産する機械になる。

結論

AIコーディングは、プログラミングの民主化ではなく、プログラミングの敷居を下げるツールだ。「AIがあればプログラマー不要」という言説は、「電卓があれば数学者不要」と言うのと同じくらい的外れだ。

AIコーディングを使いこなすために本当に必要なのは、プロンプトの書き方でもプログラミング言語の知識でもなく、「自分が何を作りたいか」の明確なビジョンだ。そしてAIの出力に対して「これは違う」と言える判断力。

道具は進化する。使う側も、進化する必要がある。