「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
スニペット生成レベルから †
LLMによるコード生成 †
生成AI（LLMによる）に主にプログラミング・コードを生成させる。
- ChatGPTの登場に合わせて、このユースケースが増えていった。
- ただし、この程度のことは実はGPT-2（2019）でも出来ていた。
対応するインストラクション †
以下のようなインストラクションにも対応
- 「AAA, BBB, CCC, DDD...をアルファベット順で並び替えるプログラムを JavaScriptで書いてください。」など。
- 「簡単なゲームを作成する例」もあるが暗記物件を提示しているダケに見える（指示詳細がないので当然と言えば当然）。
- プログラミングだけでなく、フレームワーク導入の際の導入手順なども出力できるのが良い。
- このため、開発ツールも生成AIと親和性が高いGUIからCUIにシフトしているという話がある。
- （Visual Studio や、他のIDEの新規作成→プロジェクトが、VSCなどのエディタ＋CLI化）
- リバース・エンジニアリング、リファクタリング、コンバージョンなどの用途でも使える。
- トラブルシューティングでは、現象の説明（エラー・ログなど）を入力し問題を特定
- お陰で「stackoverflow.com」のPV激減に繋がった。
- 開発者コミュニティ依存から、GitHub上での公式と開発者のやり取りへのシフトが進んでいる可能性。
ソリューション開発エージェントへ †
コレにより、
- 従来のコード補完（クラス・メソッド生成、スニペット生成、オートコンプリート）から、
- プロジェクト・ソリューションの開発を代行できるコーディング・エージェントとなった。
様々なユースケース †
- アーキテクト代行
- アーキテクチャ策定
- フレームワーク導入
- テンプレート開発
- 開発環境構築
- 技術リサーチ補助
- 品質管理とセキュリティ（レビュー・フェーズ）
- 自動コードレビュー（PRチェッカー）
- 各種デバッグ、トラブルシュート
- 性能対策（クエリの高速化・最適化など）
- セキュリティ脆弱性の検知と修正パッチ作成
- データと外部連携（インテグレーションフェーズ）
- データ移行（ETL）スクリプトの作成
- サードパーティAPIとの連携コード実装
- 既存コードの維持・改善（保守・運用フェーズ）
- レガシーコードのモダン化・リプレイス
- テストコードの自動生成と網羅率（カバレッジ）向上
- リファクタリングとコードスメル（不吉な臭い）の修正
- ドキュメント・コメントの自動生成
- ビジネス運用効率化（ローカル開発＆実行/EUC支援）
- 表計算ソフトの関数記述、マクロ、VBAの作成
- BI：データ処理、クエリ作成、ダッシュボード構築
- 社内業務自動化ツール（GAS/マクロ）の作成
さらなる進歩がアレば... †
...アレば、何かしら書く。
詳細 †
使い方 †
ツール類 †
スニペット生成機能 †
- GitHub Copilot、Cursorなどが、コード補完（オートコンプリート）中で使うコーダー向け機能を提供していた。
- コード補完のスニペットではスコープの広いフレームワーク導入などの分野は苦手（アーキテクトはChatUIがメイン）
- コマンドやChatUIも用意されているが、ヤッていることは、PE（Context Injection）レベルだった。
コーディング・エージェント †
- 大きなContextウィンドウを持つ推論エージェントによって、
- 推論生成した実行計画をコンテキストに加え、高度な処理を実行できる。
- これによって、プロジェクト、ソリューション更生を考慮した広範囲のコードが可能になった。
Vibe ～ †
コーディング・エージェントを用いた開発手法。
Vibe Coding †
自然言語のプロンプトを用い（、オートパイロットで）、コード生成のすべてをAIに委ねる開発スタイル
- 「書く」から「対話する」、「理解」より「反復」など。
- 思想としては「手抜き」ではなく人間は「クリエイティブな意思決定に集中」する。
- 顧客エキスパート自身がVibe Codingでプロトタイピングすることは非常に有効。
- 無限ループ課金やセキュリティ事故が発生しているので生成物はレビューが必要。
※ Proから見るとEUC向けの認識だが、フィジスタ、PoC、MVP作成などの用途に大きな可能性がある。
Vibe Engineering †
YOLOモードのコーディング・エージェント「使い」をVibe Codingと呼ぶのに対し、
ステップを分割して制御したコーディング・エージェント「使い」をVibe Engineeringと呼ぶ。
EUC or Pro †
EUC向け †
- 前述のビジネス運用効率化（ローカル開発＆実行/EUC支援）
- Vibe Coding（ホビー、データ加工ダッシュボード開発、治工具開発などのEUC全般）
Pro向け †
- 前述の
- 二大ユースケース
- アーキテクト代行
- 品質管理とセキュリティ（レビュー・フェーズ）
- 既存コードの維持・改善（保守・運用フェーズ）
事例 †
Vibe Coding、Vibe Engineering †
レガシー・アプリケーション開発 †
コチラも処理可能であることは確認した。
フロントエンド開発 †
kanban、pmなどで検索してヒットするカンバンPJ管理アプリのフロント
ML/DL Pythonプログラミング †
パッケージのアップデートが頻繁で生成されたコードが動作しない（LLM単体利用の時期の話でエージェントで精度が上がれば解決する？）。
考察 †
初歩的な †
一般的なプログラミング †
- 「プログラミング言語、やりたいことや仕様」をプロンプトとして伝えてプログラムを生成できる。
- 「生成した、作成した」プログラムのワーニング、コンパイル・エラー、実行エラーなどを修正できる。
- 昨今は、開発環境多用化で、開発環境準備段階にも適用できる（エディタ化に加えAI対応でCLI化が加速）
- 粒度の大きいタスクはChatUIから、粒度の細かいコード補完（オートコンプリート）はタスクはIDE、エディタ上から利用。
- 人間があまり得意ではないマークアップ言語（HTML、◯ML、JSON）や非手続き言語（SQL、正規表現）などにも強い。
- ただし、Snippetableなマークアップ言語であるCSSは苦手（「正しさ」の検証がテキスト空間で完結しないため）
...については生成AIを活用したシステム開発で。
アーキテクト向け †
主にフレームワーク導入、テンプレート開発、リファクタリングについてChat上で実施。
- 段階を経て利用
- 開発環境の準備
- プロジェクト準備
- フレームワーク導入
- プロジェクト・テンプレート化
- コンパイラのワーニング・エラー、実行エラーの修正
- 機能の実装（やりたいことや仕様を入力）
- リファクタリング（共通化、パッケージ導入、フォルダ構成見直し）
- 粒度毎の考慮事項
- 小：ワンライナーやスニペット・レベルのコード生成は簡単なプロンプトで対応出来る。
- 中：コード量が増える場合も、必要に応じて対応する仕様を詳細に記載すれば良いレベル。
- 大：複数ファイルに渡る変更は、明確な方針に基づいて指示を行う必要がある。
- ヤりたいことに基づいた処理方式の明確化、パッケージの選定など。
- 選定した処理方式、パッケージでも実装を指摘の実装箇所に実装する。
- 反復的リファインメント
- 生成AIも人間と同じで、一回の生成で正確な処理を生成し切ることが難しい（特定のお代で丸暗記しているケースを除く）。
- 従って、生成されたコードを次コンテキストとして利用し、コードを正解に近づけて行くようにする。
職業プログラマ向け入力支援 †
IDE、エディタ上からコード補完（オートコンプリート）が利用できるが、
- ワンライナー、スニペット生成、コンパイラのワーニング・エラー修正、類似見直し等に便利ではある。
- コード量産フェーズでは邪魔になる事があるのでOFFにすることを検討しても良い。
デバッグ、トラブルシュート †
- コンパイラのワーニング・エラーなどはIDE、エディタ上からコード補完（オートコンプリート）で修正可能に。
- 実行エラーの原因の特定に必要な情報は生成AIが手引きするので指示された情報をChatUIからプロンプトで正確に渡すようにする。
Vibe ～ †
- Vibe Coding は「LLMのポテンシャルを味わう」フェーズとして最高、初期探索やアイデア爆発には最適。
- しかし、本気で価値を生むプロダクトやシステムを作るとなると、Vibe Engineering 寄りにシフトする必要が出てくる。
Vibe Coding †
LLMコーディング・エージェントによるVibe Codingは、
- LLMというアーティファクトを核としたシミュレータに近い。
- 一般的に、プロ向けではないが、フィジスタ、PoC、MVP作成などの用途ではプロでも使用し得る。
Vibe Engineering †
一方で、Vibe Engineeringでは、
- より自由な条件に制限を掛けつつ動作させるため、シミュレータと言うよりも指示を遂行するボット的になる。
- AIスクラムチームに発注し、納品された成果物（PR）を検収する。と言ったスタイルがワリと現実味を帯びてきている。
事例ベース †
レガシー・アプリケーション開発 †
- 大規模コードベース、カスタム・フレームワーク対応が必要になってくる。
- ...
フロントエンド開発 †
以下、生成AIの支援を受けながらの作業が捗る。
- 多言語化（JS、ES、TS、Dart、WebAssembly系、Android系、iOS系）が進んでいるため。
- 同一プラットフォーム上でも言語、フレームワーク、パッケージなどが乱立しているため。
- UI開発で使用されるマークアップ言語は人間があまり得意でない分野。
- UIサブシステムはフレームワークやパッケージの塊なので、実装を始める前の定義や初期化が多い。
※ ココでの生成AIは、SPAの闇を照らすランタンのようなもの。
※ そもそも、ブラウザ・プロセス上のUIサブシステムのアーキテクチャが難しい。
ML/DL Pythonプログラミング †
以下、生成AIの支援を受けながらの作業が捗る。
- ML/DLで使用されるPythonは配列 / 行列 / テンソル操作に特化した言語仕様が多いため。
- 特に、入出力の行列・テンソルの形状が問われるので、生成AIは便利複雑なテンソル形状の推論
※ ただし、LLM系のLangChainやHugging Faceなどの変更が激しいパッケージに関するコード生成は上手く出来ないことが多い。
品質やセキュリティに関する考慮点 †
ググった結果の利用と同じ †
- コレは、プログラミングに限らず、生成AIが騒がれ出したときから「ググった結果の利用と同じ」と言っている通り。
- 生成されたコードを使用する際は、「ググった結果の利用と同じ」で、以下のようにすると良い。
- 使用するコードがどのようなものか？を一通り読む（生成AIにクロスチェックさせても良い）。
- 生成されたプログラムを実行した際にシステム上でどの様に振る舞うか？を理解した上で問題が無いことを推察できる必要がある。
- 生成されたプログラムはコメントが少ないので、コメント比率を上げる（コード補完（オートコンプリート）を使用しても良い）。
末端作業員は... †
- 「決められたコードパターンでコードを量産する際のコード補完（オートコンプリート）」レベルの使用に留めると良い。
- 新しいパターンでのコード実装や、共通関数の抽出などを生成AIを用いて行った場合、上位エンジニアのチェックを受ける。
参考 †
Vibe Coding †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
