はじめに
生成AIを開発に使い始めて約2年ちょい？（調べたらリリースは2022年だった）。結局ずっと感じている課題感を改めてClaudeとの壁打ちで整理した記録。
この2年間で進化してきたと感じる部分
生成AIを利用しての開発体験を振り返ると、変化は確かにある。
| 時期 | 変化 | 本質 |
|---|---|---|
| GPT-3.5→4→5 | 精度向上 | 同じことがより正確に |
| ChatGPT→Cursor | UIの進化 | 同じことがより楽に |
| 単発→MCP/Agent | 統合の進化 | 同じことがより自動で |
| プロンプト→ルール/メモリ | 永続化 | 同じことを繰り返さなくていい |
変わったこと（AI駆動開発内での進歩）
- ルール/スキルでコンテキストの永続化ができるようになった
- MCPで外部ツール連携が標準化された
- エージェントが並列・自律的に動けるようになってきた
- コードベース全体をスキャンして参照できるようになった
- プロンプトの精度を上げなくても、それなりの生成ができるようになった
変わってないこと（AI駆動開発の根本）
- コンテキストの限界（長いやり取りで情報が薄れる）
- ドメイン知識は毎回注入が必要
- 生成物の品質担保は人間依存
- 「いい感じに」はまだできない
- バグは出るし、レビューは前以上に必要
本質的課題のリスト
壁打ちの中で整理した、「現状の対策では本質的に解決しない」課題たち。
1. コンテキスト消失
問題: AIは長期記憶を持たない。セッションが長くなると以前の情報が薄れる。コンテキストウィンドウは有限。
今やってる対策: プロンプトの工夫、ドキュメント化、メモリ機能、RAG
対策の限界: どれも「人間が補助輪をつけてる」状態。モデル自体が解決してるわけじゃない。
本質的に必要なこと: モデルが真の長期記憶を持つ。経験から学習・保持できる。
2. ドメイン理解の欠如
問題: AIは汎用的な知識は持つが、特定プロジェクト/ドメインの文脈を理解していない。毎回説明が必要。
今やってる対策: 毎回説明する、ルール/プロンプトへの注入、RAG、Few-shot examples
対策の限界: 注入できる量に限界がある。「暗黙知」は言語化が難しい。
本質的に必要なこと: モデルがドメインを学習・保持できる。プロジェクト固有の文脈を内在化。
3. 成果物の劣化
問題: AI生成コードは時間とともに、または大規模になると品質が劣化する傾向。一貫性が失われる。
今やってる対策: 人間によるレビュー、lint、静的解析、テスト、既存パターンの提示
対策の限界: レビューがボトルネックになる。AI生成速度 >> 人間レビュー速度。
本質的に必要なこと: モデルが自己検証・修正できる。内省的な正しさの判断。
4. 再利用性の低下
問題: AI生成コードは局所最適になりがち。コードベース全体の一貫性、再利用性が考慮されない。
今やってる対策: 規約の明文化、パターン提示、既存コードの参照指示
対策の限界: 全部をコンテキストに入れられない。AIは「今のタスク」に集中しがち。
本質的に必要なこと: モデルがコードベース全体を理解。アーキテクチャレベルの判断。
5. 自律的イテレーションの限界
問題: AIが自律的に試行錯誤を回せない。人間がチェックポイントで介入する必要がある。
今やってる対策: 人間が段階的に指示、エージェントフレームワーク、ワークフローの自動化
対策の限界: 「判断」の部分で人間が必要。AIだけで回すと暴走リスク。
本質的に必要なこと: モデルが信頼できる判断をする。不確実性を正確に認識。
6. 曖昧さへの対処
問題: 人間の指示は曖昧。AIは推測で進めるが、その推測が正しいとは限らない。
今やってる対策: プロンプトを詳細に書く、曖昧な場合は質問させる、テンプレート化
対策の限界: 人間側の負荷が増える。「いい感じに」やってほしいのにできない。
本質的に必要なこと: モデルが文脈から適切に推論。または適切なタイミングで確認。
7. 確率的出力の不安定性
問題: 同じ入力でも出力がブレる。再現性がない。
今やってる対策: Temperatureを下げる、Seed固定、出力形式を厳密に指定
対策の限界: 完全な再現性は得られない。本質的に確率的。
本質的に必要なこと: 必要に応じて決定論的な出力。または不確実性の明示。
共通点：「人間が補助輪をつけてる」
7つの課題を並べてみて気づいたのは、どれも「人間が補助輪をつけてる」状態だということ。
| 課題 | 今やってる対策 | 本質的に必要なこと |
|---|---|---|
| コンテキスト消失 | プロンプト工夫、ドキュメント化 | モデルが長期記憶を持つ |
| ドメイン理解の欠如 | 毎回説明、ルール注入 | モデルがドメインを学習・保持 |
| 成果物の劣化 | レビュー、lint、テスト | モデルが自己検証・修正できる |
| 再利用性の低下 | 規約の明文化 | モデルがコードベース全体を理解 |
| 自律的イテレーション | 人間がチェックポイントで介入 | モデルが信頼できる判断をする |
| 曖昧さへの対処 | 詳細なプロンプト | 文脈からの適切な推論 |
| 確率的出力の不安定性 | Temperature調整 | 決定論的出力 or 不確実性の明示 |
フロー/プロンプトでは超えられない壁
どれだけ工夫しても超えられない壁がある：
- コンテキストウィンドウは有限 → 全部は入らない
- プロンプトは毎回リセット → 学習が蓄積しない
- モデルは確率的 → 同じ入力でも出力がブレる
- 自己認識がない → 「わからない」「間違えた」を正確に判断できない
これらはプロンプトやフローでは超えられない。モデルアーキテクチャレベルの変化が必要。
じゃあ今できることは無意味か？
ここで壁打ち中に出た問い：「本質的解決を待つしかないなら、対処療法的に今対策やプラクティスとしてやってることは無駄なのか？」
結論としては、無駄ではないが、過度な期待もすべきじゃない。
「待つ」と「やる」の二層構造
- 待つ: モデルの進化、新しいアーキテクチャ、研究のブレークスルー
- やる: 手作業の自動化、ログの蓄積、再現性の確保
外部ツールで対応できるのは「やる」側。本質的解決は「待つ」しかない。
「やる」ことの価値
-
ブレークスルーが来るまでの間、現実の仕事は止められない
- 「3年後に完璧なツールが出る」としても、今日の仕事は今日やる
- その間の効率化には意味がある
-
モデル進化が遅い/頭打ちになった場合の保険
- モデルが80点止まりなら、残り20点を埋める仕組みに意味がある
- モデルが99点になるなら、その仕組みは不要になる
-
ドメイン固有の問題は残る
- 汎用モデルが進化しても、自社/自分のコードベース、ドメイン知識、ワークフローを理解してるわけじゃない
- ここは常に「自分で埋める」領域
補足：AIツールのロックインへの警戒
特定のAIツールにロックインされてるとコスト問題やサービスの統廃合等で、いざ使えなくなったとき困る。そのためどのAIモデルでも汎用的に効果があるプロンプトやフローの知見をストックしたりすると良いのではないか？と考えている
結論：温度感の整理
本質的課題について
- 現在の対策（フロー/プロンプト/外部ツール）では本質的に解決しない
- モデルアーキテクチャレベルのブレークスルーを待つしかない
- それがいつ来るか、来るかどうかは不明
今できることについて
- 本質的解決ではないが、ツールやプラクティスを駆使しての効率化・再現性向上には意味がある
- ルール化したり小さく試して、効果を見て、続けるか捨てるか判断する
自分なりの今後の期待感
- 過度な期待はしない: 確実にブレークスルーが起きるわけではない
おわりに
2年間使ってきて、「精度が上がり、様々な機能が増えて便利になった」のは間違いない。でも「AI開発体験の中で感じた課題が根本解決した」かというと、まだそこまでではない。
そもそも、この整理自体AIとの壁打ちで言語化したものだけど、こういう 「自分の考えを整理する」用途では確実に役立っている。