- 2週間にわたり、AI支援開発ワークフローだけでアプリを作る実験を行ったが、期待したほど満足のいく結果にはならなかった
- Claude CodeとRemixベースのスタックを使い、課題定義 → AI実装 → コードレビュー → デプロイ の流れを繰り返した
- しかし、コンテキスト不足、再利用できないコードの重複、フローの分断、ハルシネーション(hallucination)、パレートの法則の問題によって、次第に強いフラストレーションを感じるようになった
- 結局、2週間後にAI中心の開発を断念して従来のやり方に戻り、コード整理と品質改善に満足した
- 現在は 検索、ラバーダッキング、コードスニペット、テスト、言語校正 など限定的な用途でのみAIを活用しており、根本的な技術変化が起こるまではこれ以上拡大しない考えである
実験概要
- 最近注目されている LLM(大規模言語モデル) の開発ワークフローを自ら適用した、2週間のアプリ開発実験を実施した
- Facebook Adsアカウントの複雑なUI体験を踏まえ、Facebook Ads API だけを使った簡素化された広告管理ツール adbrew のプロトタイプ開発に着手した
- 実験は、AIの潜在力を検証したいという目的と、実際の問題解決への期待をもとに進められた
アプローチ
- AI関連のさまざまなアカウントをフォローしつつワークフローを研究し、技術スタックとして Remix/React Router v7 を選定した
- Claude Code を契約後、プロンプト、DXツールの設定、課題定義など初期環境の構築に時間を投入した
- 日々のルーチン
- 課題定義
- AIに実装を依頼
- AIと要件を調整
- 生成されたコードを詳細に確認
- コードをコミット/デプロイ
- プロセスを繰り返す
- ガイドラインと自動チェック用ファイルを定期的に改善
- AIと開発フローをすり合わせるための試行を継続的に行った
頻発した問題点
- 常にコンテキストが不足している
- 多くのコンテキストを与えても、AIは必要なフィードバックを求めてこない
- AIが勝手に仮定を置いて作業を進める ため、結果として誤った実装が頻発した
- コードの再利用性が低く、保守もしにくい
- 抽象化や再利用コードの生成が不十分
- 既存コンポーネントを繰り返し作り直し、レビューの負担が増大
- ガイドラインを反映させても効果はわずかだった
- 作業フローの分断
- AIの作業中は継続的な監視が必要
- 課題ごとに効率よく集中時間を確保しにくく、生産性が低下 した
- ハルシネーション(Hallucination)現象
- 複雑なFacebook API、不十分なドキュメント、誤って型付けされたSDKが重なり、AIの誤った確信 が混乱をさらに大きくした
- 各種フレームワークやライブラリについて誤情報を繰り返し生成した
- パレート現象の深刻化
- 全体作業の80%はAIが素早く進められるが、残り20%の最終仕上げ・修正に80%の労力が必要だった
- 例外処理や機能間の相互作用で、主要な欠陥やバグが多数発生した
結果と振り返り
- 2週間後、コードは次第にひどい状態になり、制御不能 になっていった
- 開発過程で 楽しさを失い、品質面の問題もあって従来のワークフローへ戻った
- 再び手作業でコードを整理する中で、AIレビューが見落としていた点を発見し、結果としてより良いコードベースを確保できた
現在のAI活用方法
- 強力な検索エンジン: 複雑な情報探索や文脈に合った回答に有効で、失敗しても従来の方法へ素早く切り替えられる
- ラバーダック(アイデアのブレインストーミング) : 代替案の提示、探索範囲の拡大、関連キーワード探索の強化に特に効果的
- コードスニペットアシスタント: 反復的なユーティリティ関数生成を自動化し、開発の疲労を軽減
- テストコード補助: テストに関する新しいシナリオの発見にAIを活用
- 言語関連の作業: コミットメッセージ、課題、PRなどのテキスト編集役として有用
- 最近ではAIが書くのではなく、開発者が書いたものをAIがレビューする形へと逆転している
結論と展望
- 日常業務の補助 としてはAI活用を続けるが、開発プロセス全体の委任 への拡大には現時点で否定的な立場である
- ローカルLLM優先利用 とデータ統制の維持に努めている
- 今後の技術変化の可能性には引き続き注目しつつ、現時点ではAIの利用範囲を限定的に保つ方針
2件のコメント
複雑な作業をするときに、本当に強く感じる欠点です。
楽しさの喪失 + コードがぐちゃぐちゃ..
本当に、コードのリファクタリング + アイデア用途以外には、使うのに適していないように思えることが多いです。
Hacker Newsの意見
最近、ChatGPTにごく簡単な
rsyncコマンドを聞こうとして1時間以上試したが、自分のmacに入っているrsyncのバージョンでは動かないコマンドパラメータを出し続けた。失敗の半分くらいは意味不明なトラブルシューティングに流れ、残りは自分のミスに「気づいた」と言いながら間違ったバージョン向けの答えを返してきた。手元のバージョンに合うようパラメータを検証してくれと指示しても、明確にそれを実行できなかった。実際には一人でやれば5分で終わることなのに、この不思議な技術が自分の時間を無駄にするのを止められず、ただ見ていた。自分はプロの開発者ではないが、こういう体験が開発者の間でもよくあるのか気になった。おそらくLLMの主な訓練セットに合ったソフトウェアのバージョンでコーディングしていればこうした問題は起きにくいのだろうし、プロンプトで回避する方法があるのかも気になる。現時点では、LLMがコーディング業務で本当に時間を節約してくれるとはあまり思えず、むしろその特異な性質のせいで余計に時間を浪費していると感じるLLMに自分のバージョンに合うパラメータを検証してくれと言っても、きちんとやってくれない。この点についてAIの専門家の意見を聞きたい。自分もこういう経験は多い。結局のところ、LLMは私たちが言っていることを本当に理解しているわけではない。数学的に見ても、その理由は説明できる。ただ一方で、transformerのような技術や別の工夫が、少なくともアルファベット数えのような露骨に恥ずかしい課題を避けるためには入っているようにも見える。もしかすると自分が何か見落としているのかもしれない
開発者の間でもこういう経験は非常によくある。中には「自分はそんなことはない」と言う人もいるかもしれないが、ごく少数の例外にすぎず、大半の人は似たような不満を持っている。プロンプトでこうした問題を避けられるかという問いについても、訓練データにない内容ならまったく役に立たない。多くの言語でLLMは本当にひどい。CLIツールでは、LLMにmacOSやBSD版だと伝えてもGNUフラグを出し続けることがほとんどだ。特にmacOSでは最近
rsyncが変わったこともあり、オンライン上の情報もあまりない。参考リンク: rsync置き換えに関する記事。それに、LLMがコーディングで時間を節約してくれるという考え自体がベストケースでしかない。むしろLLMのコードを盲信してコミットし、バグやセキュリティ脆弱性を生むことも多い。参考資料: ai-coding-slowdown ブログ および arxiv論文プロンプトでこうした問題を避けられるかについてはよく分からないが、Claude Codeでは実際にコマンドを実行できる。つまり、LLMに好き勝手想像させるのではなく、
! man rsyncや! rsync --helpのように実際のコマンド出力をコンテキストに追加すればいいそもそも特定のツールのマニュアルを調べるのに、なぜわざわざLLMを使うのか疑問だ
ChatGPTで簡単な
rsyncコマンドを得ようとして1時間以上試した件について言えば、環境情報やエラーメッセージを十分に追加しながら何度か試し、それでも駄目ならClaudeやGeminiなど別モデルも試す。それでも決めた回数だけ試して解決しないなら、LLMから助けを得るのは難しいのでやめて、マニュアルやフォーラムなど従来の方法で情報を探したほうがずっと早い。普通は10〜20分ほど試して見切るのが現実的な基準だ。LLMはどれだけ長く試しても解決できない問題があり、ただ堂々巡りするだけのこともある私もこういう経験は多い。AIが本当に役立つのは、自分がすでにやり方を知っている作業をやらせるときだ。問題を十分に正確に説明してLLMが理解できれば、まずまずの結果を返してくれるし、出力されたコードを見て自分ですぐに目的に合っているか判断できる。まったく知らないことを任せると、むしろ余計に複雑になる
この記事（タイトルを除けば）はかなりバランスの取れた見方だと思う。「何でもLLMに任せろ！」は問題だらけだし、「時間短縮目的で反復的なコードやテストコードの一部だけ任せるのはかなり良い」。ただし、「AIはうまくいくときもあれば、そうでないときもある」みたいな平凡なタイトルでは絶対にPVは稼げないだろう
AIはコントラクター（外注）というよりインターンに近い
「状況情報だけでは十分ではない」という言葉に強く共感する。こちらがどれだけ多くの文脈を入力しても、AIはフィードバックを求めずに勝手に推測して失敗することがほとんどだ。あるテレビ番組で、ジーニーに願い事をするとき、あらゆる条件を細かく確認するために弁護士のように会話する場面を思い出す。LLMと話すのもそれに近い感じがある
AIは、ものすごく頭はいいのに本音を絶対に言わない同僚のようだ。何でもできそうに見えるのにチームワークはできず、「ここで何を望んでいるのか分からない、もう少し説明してくれ」といった会話がAIから出てくることは決してない
（さっきのテレビの場面が何か分かる気がするが）その場面では結局うまく解決したものの、LLMは自分の「約束」を守る必要をまったく感じていないと思う。むしろジーニーのほうが、規定やルールに縛られた古典的SFのAIに近い。LLMはまったく別物だ
実際のコーディングよりも、AIとやり取りするvibe codingはあまり好きではない。その代わり、最も変えたのは開発プロセスをもっと早い段階から構造化することだ。まず仕様ファイルを書き、LLMにコードベースとオンライン情報をもとに、要件として明確に説明すべき部分を洗い出させ、実装ステップを段階的なチェックリストに分解させる。各ステップが終わってから次のセッションに進み、完成度を高めていく。AIとの対話に疲れたら、自分かチームメンバーが仕様どおりに実装すればよいので、柔軟に活用できる
最近のプロジェクトでAIコーディングを導入した。vibe codingが正確に何を指すのかは分からないが、自分が選んだやり方は、ゆったりした反復的インタラクションだ。Gemini AI studioを使い、その結果に非常に満足したので、そのプロセスをすべて文書化してオープンソースプロジェクトとして公開した。生産性には目に見えるブーストがあった。残念だったのは、AIが過度に丁寧に話すことだった。自分の考えでは、AIは自分が欲しい結果をはっきり分かっていて、途中で選択肢を比較する必要があるときに最もROIが高い。プロジェクトのあらゆる成果物（コアコード、テストケース、ビルドスクリプト、ドキュメント、サンプルアプリ、ユーティリティ）に活用した。開発対話の全記録はこちら、プロジェクトのソースはこちらを参照
AIは自分が使うのと似た形で活用している。革新的な抽象化のようなものをAIに期待しすぎるべきではない。何千人もの開発者がすでに歩いてきた、ごくありふれた道の上ではよく機能する。そういう意味では、とても強力な検索エンジンに近い
自分が好むやり方は、LLMから最初の解決策やコード例を軽くもらい、その後はプロンプトを延々と磨き続けるのではなく、自分でそのまま作業を進めることだ。最後に必要ならLLMに自分のコードをレビューさせる。最大の利点は、プロンプト調整のループを飛ばせることだ。このループは本当に退屈で、時間ばかり大量に食い、長期的にはむしろ業務効率を下げかねない
AIがフィードバックや明確な質問なしにそのまま進めてしまう点は本当にいらだたしい
「現状ではAIはそこまでの用途に限って使い、今後もし技術が根本的に変わるなら、そのときにまた見直す」というチームの意見を述べる。LLMがそれ以上のことをできるようになるのかは気になるが、今でも正しく使えば非常に有用だと思う
Facebook広告の改善のためにAIを使うのは、まるでDark Towerシリーズに出てくる breakers のようだ