「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
「生成AIを活用したプログラミング」ページ中で紹介したコーディング・エージェントは、
「Master Vibe Coding with AI Coding Agents：Claude Code...」にあるように使用できる。
...つまり、以下のようなユースケースで活用可能と言える。
基礎知識 †
なお、以下の基礎知識があることが望ましい（必要・前提の知識ではない）。
ユースケース †
YOLO（フィジスタ、PoC、MVP） †
要件のみ渡して開発を進める。フィジスタ、PoC、MVPなどで有用。
プロ用（フェーズ毎の実装＆検収） †
※ カスタム・フレームワークについての考察
ドキュメント・フォワード †
- YOLOで、要件のみで開発ができることから明らかだが、要件から仕様や計画へのブレークダウンができる。
- プロ・ユースの仕様や計画をエージェントが生成し、人間が確認＆修正を行ってから実行するなども可能。
※ 「生成AIを活用した設計書のブレークダウン」
システム開発（インフラ構築） †
- 構築系のシェル生成、シェル・スクリプト生成、IaC生成（Terraform、CloudFormation?、ARM Template、Infrastructure Manager）
- Docker系の定義ファイルの生成（開発環境にも適用可能）、CaaSデプロイのシェル生成、シェル・スクリプト生成
※ 「生成AIを活用したシステム開発」（インフラ構築）
移行・マイグレーション †
大規模コードベースを分析してAGENTS.md、AGENTS.md（CLAUDE.md）を生成できるので。また、事例も多数あるもよう。
（コレだけ単純なI/Fの話なのでユースケースから外した。YOLO/プロ用は厳密にはモードの話だがユースケースが異なる事が多いので）
実は大きな際はない。また、実はCLIの方が操作性も良い（ChatGUIもプロンプトなので）。
詳細 †
共通 †
プロダクトごとに共通
MDファイル †
- 一般的には、AGENTS.mdとPLAN.mdがある。
その他にも、SPEC.mdなど、任意のMDファイルがあっても良い。
- 実行前には、読む必要のあるMDファイルをエージェントに通知する。
- 「AGENTS.mdを参照し、SPEC.mdを生成して下さい。」（DOCフォワード）
- 「AGENTS.md、SPEC.mdを参照し、PLAN.mdを生成して下さい。」（プランニング）
- 「AGENTS.md、SPEC.mdを参照し、PLAN.mdを参照し、PLAN の Phase N を実行してください。」（コーディング）
- ファイルの配置場所
- プロジェクトに適用されるMDファイルはリポジトリ内に配置する。
- 階層が深い場合、サブ・プロジェクトのサブ・フォルダ毎に配置しても良い。
- 個人に適用されるMDファイルはユーザ・ディレクトリの.プロダクト名フォルダに配置する。
- 一般的には、AGENTS.md、PLAN.mdだが、
- Claude Codeの場合は、CLAUDE.md＝AGENTS.mdなので、
- CLAUDE.mdからAGENTS.mdをリンクするなどとすると共通化出来る。
- リンクには、MD記法（相対パスが必要）と「@」メンション（プロダクト依存）の２つがある。
- ユーザ・ディレクトリの.プロダクト名フォルダ名は
- Cursor：.cursor
- GitHub Copilot：.copilot
- Claude Code：.claude
- OpenAI Codex：.codex
- Antigravity：.agents
- コーディング基準は、
CODING_GUIDE.md（OSSではCONTRIBUTING.md）
- 実装ガイドは、以下の様にするのが良い。
- 概要をMDファイルをIMPLEMENTATION_GUIDE.md
- 必要に応じて詳細をスキルとして実装
タスク †
タスクはエージェントに与えたお題に対して実行する作業単位を指す。
プロ・ユースでは、以下の様なタスクが考えられる。
- DOCフォワード：
- 内容：要件→仕様（基本・詳細設計）へのブレークダウン
- プロンプト：「AGENTS.mdを参照し、SPEC.mdを生成して下さい。」
- プランニング：
- 内容：仕様（設計書）→実装計画へのブレークダウン
- プロンプト：「AGENTS.md、SPEC.mdを参照し、PLAN.mdを生成して下さい。」
- コーディング：
- 内容：実装計画（概要）→実装計画（詳細）を作成してのコーディング・テストなど。
- プロンプト：「AGENTS.md、SPEC.mdを参照し、PLAN.mdを参照し、PLAN の Phase N を実行してください。」
YOLO †
YOLOモードは、確認無しにドンドン実装が進むオートパイロット的なモード。
- レアだが危険な操作がされる可能性があるので、サンド・ボックスで実行するのが一般的。
- CLAUDE.md＝AGENTS.mdのみで、SPECやPLANはエージェントに立案させるケースが多い。
- 受入者も未知の技術を使用しPoC、MVPを実装させるケースで有用（コントロールは弱いが、シェフにお任せ的な期待ができる）。
プロ用 †
プロ・モードはYOLOモードでなく、都度確認を行う。
- フェーズやステップ毎に実装を細切れに実行させ、都度作業内容を検収（Gitコミット）する。
- ちなみに、SPECやPLANのブレークダウンをエージェントの助けを受けながら行っても良い。
- エンプラ開発のウォーターフォールや、サービス開発のアジャイルのプロセス中の任意の作業単位毎に実行する。
Chat †
利用の流れ †
- AGENTS.md、PLAN.md、SPEC.mdなどを与えると別途計画を立ててから実装を実行する（エージェントが別のPLAN.mdを生成する）。
- 細かくフェーズやステップを分ける場合、「PLANn.md、SPECn.mdを参照し、PLANn.mdのxフェーズ、yステップを実行してください。」などと指示すると良い。
- エージェントが生成したPLAN.mdに問題がなければ実装を実行する。計画を見るのが面倒なら実行結果を見て問題があったら、PLAN.mdにフィードバックするでも良い。
使える機能 †
CLIと同じ。ただし、CLIの「-」コマンドは使用できない。
CLI †
Chatと同じ。違いは、指示がし易い点。
- 何気に、ChatもGUIと見せかけて文字列ベースなので、その差は、一般的な GUI vs CUI と言う程でもない。
- 両方文字列ベースのI/Fだと、機能差は無くとも、CLI風のI/Fの方が柔軟性が高い（詳しくは「利用の流れ」で）。
利用の流れ †
- 基本は、Chatと同じだが、以下の点で、CLIが優れている。
- 「/」コマンドの活用
- /status：実行にあたっての様々な状態を一望できる。
- /context、/compact、/clear：などでコンテキスト管理が容易
- 実はインタラクティブ性能もCLIの方が高い。
- Chatだと基本は文字列になる。一部、Chatでの対応もされている。
- しかし、近年のCLIは「Chatでの対応」より優れたインタラクティブ機能がサポートされている。
- 疑似タブ切り替え（Tabs）
- セレクトボックス（Select / List Prompt）
- マルチセレクト / チェックボックス（Checkbox / Multi-select）
- トグル / トグルスイッチ（Toggle / Confirm）
使える機能 †
各種機能が利用可能
- MDファイル、ツール、MCP、Slashコマンド、スキル、フック、プラグイン
- フック、プラグインはClaude Code発だった。
- 今となっては、GHCのチャットUIからも機能する。
- ただし、コマンドはCLIのモノと、LLMのモノとで内容が異なる。
- CLIの「-」コマンドは所謂、CLIのコマンドとして機能する。
- LLMの「/」コマンドは、プロンプト・フローの動作に影響を与える。
機能 †
ツール †
- メイン・エージェントで使用可能なMCPサーバを追加する。
- セキュアに大規模なSaaS（GitHubやAtlassian）機能を活用する...的な文脈で使用
- 認証が必要で再認証しないとエラーになったりすることが多い（/mcp → Re-authenticateが作法"笑"）。
- 最小限のものであれば、MDファイル１つで定義可能。
- 定義中に、外部スクリプトファイルなどを含めても良い。
カスタムSlashコマンド †
以前はcommandsに実装していたが、現在はskillsに実装するようになってきている。
- この際、name属性をcommandとして利用可能な文字列にする。
- つまり、スキル ≒ カスタムSlashコマンドだが、
- skillsはcommand的に実行できない（LLMの判断による）点が異なる。
- 逆にskills的に実装したcommand（つまり適切なname属性でdescription属性がある）はLLM判断で利用される。
サブ・エージェント †
- 別のコンテキスト・ウィンドウで実行する。
- メイン・エージェントと並列で動作させることができる。
- 使用するLLM、ツール、システム・プロンプトを追加する。
- 単純作業を廉価なLLMで実行したりすると良い。
フック †
- あまり使用されない。
- イベント発生時に自動的に処理を実行するなどの目的で使用する。
事例 †
手順 †
プロ・ユースでは、タスクに書いた手順で進めて行く。
DOCフォワード †
プランニング †
コーディング †
MDファイル †
ルートフォルダは、「.docs」などとする。
AIに聞く：コーディング・エージェントに渡すMarkDown?ファイルのルートフォルダ名は？
AGENTS.md †
記載項目
- 各種要件
- ビジネス要件：なぜやるか
- 業務要件：業務をどう変えるか
- システム要件：システムに何を求めるか
- 機能要件：システムに求める機能の要件（モジュール（責務（役割））一覧）
- 非機能要件：システムに求める非機能（品質系：性能、可用性など）の要件
- プランニング方針
- 始点と終点：要件からか仕様からか（何処までがFIXしているか？）
- 共通的な開発フロー：プラン概要を詳細プランにブレークダウンする際に使用。
- 設計：
・既存パターンを確認し、無いパターンは追加しない。
・新規実装の追加時は再利用を確認する。
- 実装
・最初に、必要となるD層や共通部品を実装する。
・次いで、画面項目定義から画面を実装する。
・次いで、トランザクションルートとなるB層メソッドの土台を実装する。
・次いで、必要に応じてトランザクションを引き継ぐB層、引き継がないB層メソッドの土台を実装する。
・次いで、画面イベントのハンドラを実装し、共通部品やトランザクションルートのB層メソッド呼び出しを行う。
・次いで、B層メソッドを実装し、共通部品やD層メソッド呼び出しを行う。
- テスト：
・基本方針：TDD的か？など。
・テスト実施タイミング：B層D層P層コード作成・修正後
SPEC.md †
開発対象のシステム機能の一覧と仕様を記載
- 一覧：機能一覧、画面一覧、画面遷移
- 機能要件が主入力。
- ただし、業務要件・非機能要件から派生する機能も確認する。
- 仕様：画面項目一覧、イベント一覧、イベント定義
- 前述の一覧が主入力（画面一覧、画面遷移）。
- 加えて、非機能要件、業務要件（業務ルール、権限、外部連携、運用制約）などを加味して具体化する。
※ 参考：生成AIを活用した設計書のブレークダウン
PLAN.md †
- ハイレベルの実装計画を記載
- 個別のプランは実装開始前にエージェントがホームディレクトリに自動生成する。
*_GUIDE.md †
- コーディング基準：CODING_GUIDE.md
- ネーミング基準：NAMING_GUIDE.md
- 実装ガイド：IMPLEMENTATION_GUIDE.md
- その他、必要に応じて追加：MMI標準など, etc.
スキル †
実装ガイドの具体的な内容をスキル化する。
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
