TL;DR
2025年の開発トレンドは、CLI型LLMツール（Amazon Q CLI / KiroCLIなど）を用い、実装だけでなく動作確認・デバッグまでAIに行わせる**AI-DLC（AI駆動開発）でした。しかし、LLMの記憶容量限界であるCWO（Context Window Overflow）**が開発の障壁となるため、これを回避・管理する工夫が鍵となります。そのベストプラクティスについて語ります。
はじめに
開発エンジニアのみなさん、ツール作っていますか？ 文系の方でもRPAでツール作って仕事を改善する時代、まだの方はパパッと作って楽しましょう。
2024年後半から始まったLLMコード生成機能の普及は当初大きな驚きでしかありませんでしたが、2025年は新モデルが発表されるたびに、「試す→ 評価する」を繰り返す一年でした。つい2年程前までは、業務の合間にツールを作るのは時間が必要で、なかなか手が出せない方も多かったと思いますが、2025年はゲームチェンジの年となり、たかだか数時間で満足のいくツールが作れるようになりました。
この記事では、なんとなくから始めたLLMコーディングがVibeCodingとよばれ AI-DLC(AI-Driven Development Life Cycle)という概念を生み出されるまでの過程を振り返りながら、2025年末でのLLMによるツール開発の肝について触れたいと思います。
AI-DLCとは何？美味しいの？
日本語ではAI駆動開発とも訳されます。流行りの言葉です。食べられませんが、美味しい思いはできます😋 多分。
いわゆる「コード生成」との違い
2024末ごろにしきりと謳われるようになった「コード生成」とも若干違います。
同じ文脈で語られるVibeCodingも同じですが、コード生成だけではなくて、実行して動作確認やデバッグもAIに行なわせる点が一つ大きな違いです。
開発エンジニアでも、人間に変わって動作確認できることをそもそも知らない方もいるかもしれません。これは提供されるLLMサービスの形態が大きく関わるためです。
LLMサービス形態で、動作確認やデバッグを代行させられるのは CLI です
例えば、ChatGPTのUIは文字通り「チャット」が主目的のため、コードまでは生成できても特定のローカルディレクトリへの生成コード保存すら人間が代行しないといけません。このタイプはマシンローカルへのアクセス禁止を前提に設計されているため、当然と言えば当然の振る舞いです。
CLIによる「コード生成」＋「動作確認（含むデバッグ）」
一方、Amazon Q Developper CLI (現在はKiroCLIと改称)や ClaudeCodeMax CLIのようにターミナル内でコマンドとして動くCLIアプリケーション形態のLLMサービスはファイルアクセスを前提としているので、コードを実行したり、ログファイルを出力させてそれを読んだり、PlaywrighMCPを使わせればWebUIのデバッグまでできます。
以下は、デバッグを指示したところ。
AmazonQ-CLI(現在の名称はKiro-CLI)は、バックエンドでClaude-sonnet-4を使っていますが、最初はほぼ生成コード動きません。いつものようにぶつぶつ言いながら、色々と調べてデバッグしていきます。
おっ、動くようになったみたいですね。コードの正常起動が確認できると、キー操作を代行もしてくれます。この辺は PlaywrightMCPのおかげですね。
デバッグと動作確認がおわると、こんな感じでreportを出してくれます。余談ですが、いつも思うんですが、Cluade系のこの下りやたら自信満々なんですよね。自信がないのもこっちが不安になるので困りますが、この辺はフランス人のメンタリティなんでしょうか。
AI駆動開発とは？ VibeCodingと何がどう違う？
「VibeCodingとどう違うの？」LLMでコード開発している皆さんが感じる疑問でしょう。
AI駆動開発とVibeCoding、ともに解説記事が多いことから、この際 LLM(GPT5.2 Thingking）に比較表を作成してもらいました。Gemini 3 Proとほぼ同一でしたし、人間が見ても違和感ないのでこちらで説明します。
ざっくりとした定義
- ふわっとしたお願い（≒雑なお願い）がVibeCoding
- 仕様を細かく指定するのがAI-DLC
| 観点 | AI-DLC（AI-Driven Development Life Cycle）[4] | Vibe coding（バイブ・コーディング）[5] |
|---|---|---|
| ざっくり言うと | 開発プロセスそのものをAI前提で作り直す | AIに書かせて動かしながら進める |
| 範囲 | 要件〜運用まで 全部 | 主に 実装〜動作確認 |
| 進め方のノリ | AIで回すけど、人が判断＆レビューで締める | プロンプト→生成→実行→直す を高速ループ（コードは深追いしない意味合いが強め） |
| 人の役割 | 仕様決め、レビュー、リスク管理、品質ゲート設計 | 指示出し、結果の確認、方向修正（“動いた”中心になりがち） |
| 品質の作り込み | テスト/レビュー/運用監視を 最初から組み込む（本番前提） | あとから困りやすい（保守性・安全性が詰みがち） [6] |
| できあがりがち | 仕様・設計・テスト・運用まで含む セット | 動くデモ / PoC / 短命ツール [7] |
| 向いてる場面 | チーム開発、長期運用、セキュリティ/監査が効く現場 | アイデア検証、ハッカソン、個人の爆速試作 [7] |
| つらいところ | ルール/体制づくりが必要で、導入は重め | 仕様漏れ・バグ・脆弱性・保守不能が出やすい |
2024後半からVibeCodingが広まるにつれ、その雑なコードに気づいて、皆さん「こりゃいかん」と細かい指示を出すようになっていきました。それを改めて振り返って「これって人間同士の開発と一緒やん」「やっぱり雑な依頼はあかんねんな」と襟を正したのがAI-DLCというところでしょうか。襟を正した分、表現は格調高くなっています。
AI-DLCと人間だけでの設計開発と違うところは、仕様設計もAIに提案させる点でしょうか？人間の役割は「仕様の追加」「提案された仕様の修正指示」と「承認」になります。
そうは言っても人間が全ての仕様やライブラリ、最新のベストプラクティスに詳しいわけではないので、LLMに説明させて説明がもっとらしいかどうかや、別のLLMに出てきた仕様を入力してセカンドオピニオンを取ったりします。そうして整えられた仕様でコード生成するとVibeとは全く違う品質のコードが生成されます。まあ当たり前ですよね。人間だって何も指示なくて作成したら「いやそうじゃんなくて」「こうして欲しかったんだよね」みたいなことになりがちですよね。
# 雑ながらも 基本的な仕様を記載したプロンプトの例（「当たり前」を書いとかないとダメージでかい）
WebUIで動作するテトリスのコードを生成して
- TypeScriptで作成してください
- 矢印キーとスペースキーで操作できるように
- npmプロジェクトにして
まあ、ちゃんと事前に設計詳細を伝えておくことが要点になります。AIでだろうと人間だろうと同じですな。
DIVE into 'AI-DLC Development' with CWO
ここからは、AI-DLCを実践する上で取り入れてほしい「"要点"」について解説していきます
[要点１] 現実的なアプローチはVibeとのハイブリッド
ここでいう「ハイブリッド」の意味は、開発タスクを小規模に分割してちょっとずつLLMに開発させるという意味です。
2025年末でも、実は厳密なAI-DLCアプローチ（＝仕様を作り込んで一気にコード生成させるアプローチ）はうまくいきません。
なぜなら、生成されたコードがうんともすんとも動かないからです。上の簡単なテトリス生成例でも、「ううっ、動かない」といきなりLLMが泣きを入れていました。このような状態ですので、いきなり大規模なコードを先に生成させると、どんなに仕様を詳細化しても必ず大きめのバグが入ります。結果、数十のバグ入り巨大コードが残り、地獄のデバッグが始まります。
ベストプラクティスは、以下のようなハイブリッドなやり方となります。小規模タスク分割が肝です。
1. まず設計をAI-DLCに従ってドキュメント化させ、
2. 開発単位を簡単に動作確認できる大きさに区切って、
3. VibeCoding的にコード生成と動作確認を小さな単位で進める
4. 全体フレームワークだけを作る（詳細未実装でよい）
5. 細部では、LLMが使う動作確認機能を先行実装させる（ログ/UI表示/ユニットテスト）
6. コア機能は切り離して開発。別PJとして先行途検証する
結局、先人が作った道のりをLLMにも辿らせることとなります。
"コードはアウトプットから書け" 日立製作所中央研究所フェロー 宮武博士(1992)
[重要][なぜ小さく分割？] Context Window Overflow 問題
’Context Window Overflow’ をご存知ですか？
通常のLLMチャットを使っている限りではほとんどこの問題に直面するユーザはいないと思います。一方、コード生成などをLLMに適用すると途端にこの問題へぶち当たります。
CWO: Context Window Overflow（コンテキストウィンドウ・オーバーフロー）
LLMが一度に処理・記憶できる情報量（トークン数）の上限を超えてしまう現象
AIには「短期記憶」のような容量制限があり、これを超過すると、過去の会話内容や指示を忘れたり、エラーで回答が生成できなくなったりします。非常に長い文章を読み込ませた際や、会話が長く続いた際に発生しやすく、情報の要約や古い履歴の削除といった対策が必要になります。
コード生成でなぜCWOが問題か?
最初に与えた仕様や、LLM自身が生成したコードの内容を忘れてしまうからです。
＜具体的なCWO後のダメージ事例＞
- LLM自身が生成したファイルの場所を忘れ、importに失敗するコード生成
- 巨大クラス生成中にCWO発生、再開すると自作メソッドを完全無視したコード生成
- LLM自身が一度FIXまでたどり着いたバグを平然ともう一度書き込む
- 前回の指示(プロンプト)をまず間違いなく忘れる。指示再入力が必須
KiroなどのLLM CLIでは、この問題でのユーザ負担を軽減するため、以下のようにContextの残容量をプロンプト表示に付与したりインジケータ表示コマンドを提供しています
[要点２] CWOを意識した開発タスク分割
CWO後のトラブル対策として、以下のようなTIPSを共有します。
以下はその実例です。これらを実施させることで、トラブルの影響を最小限に抑えることができます
# プロンプト例と LLMレスポンス
ありがとう。ここまでのKiroの作業内容をドキュメントに追加してください
- 概要はREADME.mdに。Kiroのコード修正履歴はChangeLog.mdに残してください
- コード設計に使った方針やベストプラクティス事例があれば、Architecture.mdに残してください
- コードのデバッグに評価した内容はユニットテストとしてまとめてください
# LLMレスポンス
'I will share my reasoning process (using tool: thinking):' ユーザーから以下の作業を依頼されました：
1. README.mdに概要を記載
2. ChangeLog.mdにKiroのコード修正履歴を記載
3. Architecture.mdにコード設計方針やベストプラクティスを記載
4. デバッグ内容をユニットテストとしてまとめる
会話履歴から以下の情報を整理する必要があります：
- Tetrisゲームの作成（HTML、TypeScript）
- TypeScriptコンパイル
- ローカルサーバーでのテスト
- ブラウザでの動作確認
- npmプロジェクト化
これらを適切にドキュメント化し、テストを作成します。
- Completed in 0.0s
...
生成されたREADME.md
Tetris Game
TypeScriptで実装されたWebブラウザ向けテトリスゲーム
概要
HTML5 CanvasとTypeScriptを使用したクラシックなテトリスゲームです。7種類の標準テトリスピース、回転、ライン消去、スコアリング機能を備えています。
機能
- 10x20のゲームボード
- 7種類の標準テトリスピース（I, O, T, S, Z, J, L）
- ピースの回転と移動
- ライン消去とスコアリング
- キーボード操作（矢印キー、スペースバー）
- ゲームオーバー検出
操作方法
- 左右矢印キー: ピースの左右移動
- 上矢印キー: ピースの回転
- 下矢印キー: ピースの高速落下
- スペースバー: ピースのハードドロップ
セットアップ
# 依存関係のインストール
npm install
# TypeScriptのコンパイル
npm run build
# ローカルサーバーの起動
npm start
# ビルド＋サーバー起動
npm run dev
ブラウザで http://localhost:3000 にアクセスしてゲームを開始してください。
技術スタック
- フロントエンド: HTML5 Canvas, TypeScript/JavaScript, CSS
- 開発環境: Node.js, npm, TypeScript Compiler
- サーバー: Python HTTP Server（開発用）
ファイル構成
-
index.html- HTMLレイアウトとCanvas要素 -
tetris.ts- TypeScriptでのゲームロジック実装 -
tetris.js- コンパイル済みJavaScript -
package.json- npmプロジェクト設定
生成されたChangeLog.md
# ChangeLog2025-12-23 - Kiroによる開発履歴
初期実装
- index.html作成: HTMLレイアウトとCanvas要素、操作説明を含む基本構造を実装
-
tetris.ts作成: TypeScriptでテトリスゲームのメインロジックを実装
- 7種類のテトリスピース定義（I, O, T, S, Z, J, L）
- 10x20ゲームボード
- ピースの回転・移動・落下システム
- ライン消去とスコアリング機能
- キーボード操作（矢印キー、スペースバー）
- ゲームオーバー検出
コンパイルとテスト
-
TypeScriptコンパイル:
npx tsc tetris.ts --target es2017でJavaScriptに変換 - ローカルサーバー起動: Python HTTP Serverでポート3000/8000での動作確認
-
ブラウザテスト: Playwrightを使用した自動テストで以下を検証
- Canvas描画の確認
- キーボード操作の動作確認
- スコア表示の確認
- ゲーム状態の検証
プロジェクト構造化
-
package.json作成: npmプロジェクト化
- TypeScript依存関係の追加
- ビルド・起動スクリプトの定義
- プロジェクトメタデータの設定
- npm install実行: 依存関係のインストール完了
検証項目
- ✅ HTML5 Canvasでの描画
- ✅ TypeScript→JavaScriptコンパイル
- ✅ キーボードイベント処理
- ✅ ゲームロジック（ピース移動、回転、ライン消去）
- ✅ スコアリングシステム
- ✅ ローカルサーバーでの動作
[要点３] LLMによるプロジェクト破壊に備える
2025末のLLM-CLIでは聞かなくなりましたが、2025春先には、LLMがホームディレクトリを勝手にいじったり最悪幾つかのファイルを削除、といった事故がありました。
現在でも時々あるのが、プロジェクトの破壊的なコード更新です。
これはデバッグを依頼した場面でたまに発生します。一般にこのケースでは、動作確認をして動作不良が見つかるとコードを修正しようとします。ただ、CWO直後、バグの特定を誤ることが多く、注意しないとせっかく動作しているコードを書き壊すことがあります。CWO前のFIX内容を覚えていないことが多く、前回の状態の復元が困難なこともしばしばです。そこで、以下のような対策をとっていただけると良いでしょう。
# プロンプト例
ありがとう。
gitのローカルリポジトリを作成して、コミットしておいてください
# LLMのレスポンス
I will run the following command: cd /private/tmp/tetoris && git init (using tool: shell)
Purpose: gitリポジトリを初期化
Initialized empty Git repository in /private/tmp/tetoris/.git/
- Completed in 0.108s
I will create the following file: /private/tmp/tetoris/.gitignore (using tool: write)
Purpose: .gitignoreファイルを作成
+ 1: node_modules/
+ 2: *.log
+ 3: .DS_Store
+ 4: server.log
Creating: /private/tmp/tetoris/.gitignore
- Completed in 0.6s
I will run the following command: cd /private/tmp/tetoris && git add . (using tool: shell)
Purpose: 全ファイルをステージング
- Completed in 0.35s
I will run the following command: cd /private/tmp/tetoris && git commit -m "Initial commit: Tetris game implementation
- HTML5 Canvas based Tetris game
- TypeScript implementation with 7 piece types
- Keyboard controls (arrow keys, spacebar)
- Line clearing and scoring system
- npm project structure with build scripts
- Unit tests for core functionality
- Documentation (README, ChangeLog, Architecture)" (using tool: shell)
Purpose: 初回コミットを実行
[master (root-commit) 30e968e] Initial commit: Tetris game implementation
10 files changed, 694 insertions(+)
create mode 100644 .gitignore
create mode 100644 Architecture.md
create mode 100644 ChangeLog.md
create mode 100644 README.md
create mode 100644 index.html
create mode 100644 package-lock.json
create mode 100644 package.json
create mode 100644 test.html
create mode 100644 tetris.js
create mode 100644 tetris.ts
- Completed in 8.718s
I will modify the following file: package.json (using tool: write)
Purpose: テストスクリプトを追加
6, 6: "scripts": {
7, 7: "build": "tsc tetris.ts --target es2017",
8, 8: "start": "python3 -m http.server 3000",
- 9 : "dev": "npm run build && npm start"
+ 9: "dev": "npm run build && npm start",
+ 10: "test": "python3 -m http.server 8080 & sleep 2 && open http://localhost:8080/test.html"
10, 11: },
Updating: package.json
- Completed in 0.2s
I will run the following command: cd /private/tmp/tetoris && git add package.json && git commit -m "Add test script to package.json" (using tool: shell)
Purpose: テストスクリプト追加をコミット
...
...
I will run the following command: cd /private/tmp/tetoris && git log --oneline (using tool: shell)
Purpose: コミット履歴を確認
a5a2913 Add test script to package.json
30e968e Initial commit: Tetris game implementation
- Completed in 0.28s
> 完了しました！以下のドキュメントとプロジェクト構造を作成しました：
## 作成したドキュメント
1. README.md - プロジェクト概要、セットアップ手順、技術スタック
2. ChangeLog.md - Kiroによる開発履歴と検証項目
3. Architecture.md - 設計方針、ベストプラクティス、技術選択の理由
4. test.html - ユニットテスト（7つのテストケース）
## Gitリポジトリ
- ローカルリポジトリを初期化
- .gitignoreでnode_modules等を除外
- 2つのコミット：
- 初回コミット：全体実装
- テストスクリプト追加
## 利用可能なコマンド
- npm run build - TypeScriptコンパイル
- npm start - サーバー起動
- npm run dev - ビルド＋サーバー起動
- npm test - テストページを開く
プロジェクトが完全にドキュメント化され、バージョン管理下に置かれました。
▸ Time: 1m 29s
要点まとめ
以上３つの要点をまとめます。
いずれもCWOがもたらすLLM状態リセットによる悪影響を最小化するためのものです
以上を適用いただければ AI-DLCベースの開発がスムーズに進むはずです
まとめ
AI-DLCという大上段の視点からLLMコーディングを行う際に必要なベストプラクティスを紹介しました。私が開発体験をもとに作り上げたもので、人柱としての歴史でもあります。
CWO(Context Window Overflow)というLLM固有の問題が、AI-DLCのようなコード開発技術へ当面影響し続けるはずですので、ぜひ活用してほしいTIPSだと考えています。
AI-DLCの観点からも、その重要なプロンプトの一部として、読者の仕様の一部に取り入れていただけると幸いです。LLMコーディングのメリットを最大限享受できると思います。
一方で、CWOはLLM実装に固有の問題であり、LLMの進化によってやがて消えていくと考えています。例えば大昔のPCプログラミングであった「セグメントとオフセット(Intel 8086アーキテクチャのリアルモード)」のように、やがて消えていくはずです。CWOへの対策もまた、後世から見れば「黎明期特有の苦労」として懐しまれる対象となるでしょう。昨今のLLM進化の速度をみると、もしかして2026末には解決しているかもしれません。
それまでの短い間「CWOがあってAI-DLCを難しくしてる」とご記憶いただけると幸いです。
それでは。楽しい聖夜を。Merry Chrismas!🎄🎅⛄️🎂
参考文献
- @nishiemon(N372Drag): Qiita記事「AI-DLC x SDD x バイブコーディングどれを使えばいいのかよくわからないので自分なりに整理してみた」
- SIGNATE総研: バイブコーディングとは？AIに任せるプログラミングのメリットと注意点
- "AI-Driven Development Life Cycle: Reimagining Software ..."
- "Vibe coding"
- "Claude Code's creator explains the limits of vibe coding"
- "What is Vibe Coding? How To Vibe Your App to Life - Replit Blog"
- Xiao, G., Tian, Y., Chen, B., Han, S., & Lewis, M. (2024). StreamingLLM: A Framework for Endless Generation with Attention Sinks. In Proceedings of the International Conference on Learning Representations (ICLR). https://arxiv.org/abs/2309.17453
- Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157–173. https://arxiv.org/abs/2307.03172
- 小林 悟郎, 栗林 樹生, 横井 祥, 乾 健太郎. (2024). 長い文脈を考慮した大規模言語モデルの評価と分析. 言語処理学会 第30回年次大会 (NLP2024). https://www.anlp.jp/proceedings/annual_meeting/2024/
Appendix: Context Window Overflowの最新動向
記事本文のように、CWO問題は直近のLLM開発応用において、我々が直面している厄介な物理的制約の一つです。
無限のように思える生成AIの対話能力も、ひとたびコンテキスト長の境界を越えれば、情報の忘却や幻覚（ハルシネーション）、あるいは機能不全といった形でその限界を露呈します。これは、AI-DLCというフレームワークでコード開発するものにとって大きな障害です。しかし、LLM研究や応用の現場では、この制約と向き合い、ハックすることこそが、現時点におけるAIエンジニアリングの醍醐味であるとも言えます。
ここでは、このCWO問題に対する最新の学術的なアプローチとして、特に示唆に富む3つの文献を紹介します。これらは、現在のLLMが抱える構造的な弱点と、それを乗り越えるためのアルゴリズム的工夫を理解する上で、極めて重要な視座を提供してくれると思います。
コンテキストの「量」と「質」の非対称性
まずは、コンテキストウィンドウが拡張された2025年でもなお残る課題についてです。
Liu et al. (2024) による研究は、単にウィンドウサイズを拡大するだけでは問題が解決しないことを冷徹に示しました。彼らが提唱した "Lost in the Middle" という現象は、モデルが入力の「冒頭」と「末尾」の情報には鋭敏である一方、中間部に埋没した情報に対しては著しくアクセス能力が低下することを示唆しています。
これは、CWOが単なる「あふれ」の問題ではなく、ウィンドウ内における「注意（Attention）の配分密度」の問題であることを意味します。我々がRAG（検索拡張生成）システムやAI-DLCのような膨大なContext Windowを利用する場合、重要なコードやドキュメントを不用意にコンテキストの中間に配置することにリスクがあることを示しています。
"Attention Sink" という特異点
次に、Context Windowの終わりを超えて、生成をいかに継続するかという課題です。
通常、Window Limitを超えた際のFIFO（First-In, First-Out）的なトークン破棄は、モデルの崩壊（PPLの急激な悪化）を招きます。
Xiao et al. (2024) は、この挙動に対し "StreamingLLM" というフレームワークで鮮やかな解を提示しました。彼らの発見によれば、Attentionメカニズムは、意味の有無に関わらず「最初の数トークン」に過剰な注意を払う性質（Attention Sink）を持っています。この数トークンを「アンカー（錨）」としてメモリに残し続けるだけで、中間履歴を破棄してもモデルは安定を保ち、実質的に無限長のコンテキスト処理が可能になるのです。
これは、コンテキスト管理における「ガベージコレクション」のアルゴリズムに一石を投じる、非常にエレガントなハックとなりうるでしょう。
日本語空間における評価
最後に、我々の主戦場である日本語環境での研究動向です。
トークン化の粒度が異なる日本語において、英語圏の知見がそのまま適用できるとは限りません。小林ら (2024) の研究は、日本語LLMにおける長文脈処理の耐性と限界について、詳細な評価を行っています。特に実運用におけるRAGの設計や、日本語特有の情報の「詰め込み」がモデルに与える負荷を理解する上で、避けては通れない文献です。
CWO問題の今後
CWOは、現行のTransformerアーキテクチャに付随する「仕様」であり、避けて通れない壁です。しかし、前述の文献にもある通り、これはLLMの進化過程における一過性の課題に過ぎないと考えています。
かつてのMS-DOS時代、プログラマたちが「640KBの壁」や「セグメントとオフセット」の管理に知恵を絞ったように、CWOへの対策もまた、後世から見れば「黎明期特有の苦労」として懐しまれる対象となるでしょう。昨今の技術進化の速度を鑑みれば、その「後世」は数年後、あるいは来年には訪れている可能性すらあります。
2026年が楽しみですね。
以上