オリジナル・コンテンツ（イキナリLLMコーディング・エージェント）のバックアップ(No.25)

構築系のシェル生成、シェル・スクリプト生成、IaC定義生成（Terraform、CloudFormation?、ARM Template、Infrastructure Manager）
Docker系の定義ファイル生成（Dockerfile、DockerCompose?）、実行ファイル生成（Dockerコマンド、WSL2経由）、CaaSデプロイのシェル生成

※ 「生成AIを活用したシステム開発」（インフラ構築）

↑

移行・マイグレーション †

大規模コードベースを分析してAGENTS.md、AGENTS.md（CLAUDE.md）を生成できるので。また、事例も多数あるもよう。

↑

アーキテクトの作業アレコレ †

アーキテクトであればコーディング・エージェントとチャットしさえすれば流れでアセットが構築される。
- 環境構築スクリプト開発
- 開発用テンプレート実装
- 各種の治工具ツール開発
- 自動化スクリプト開発、自動化スキル?開発
- 各種の問題点の修正：Review → Issue → Pull Request
- , etc.

開発のコツなどがあるかも
- 環境構築、自動化スクリプト
  - 「生成AIを活用したシステム開発」にも書いたが「環境差異、冪等性の罠に対応」している所が強み。
  - 揺らぎがあり、且つ、高コストなのでエージェントが自然言語で実行した処理を最後にスクリプト化してもらうなどすると良い？。

スキルはある意味、MD形式の文字列開発と言える。
- 新規作成時はドキュメントやコードを読ませ立ち上げ、以降、修正・検証エージェントのループに入れる。
- 生成された文字列は人間が読むよりアテンションの効いた推論LLMエージェントが読むのに適した文字列になっている気がする。

↑

Coworkと変わらないカモ †

Claude Cowork ≒ 推論エージェント
Anthropic社製の推論エージェントラインナップ
Coworkはエンド向けで、Codeでも同等のことが出来る。
- 機能や処理のベースは同じなので、CodeでCoworkと同等のこと（ファイル操作やデータ処理など）を行うことは技術的に可能。
- GUIの操作性を重視するならCowork、ターミナル環境でのカスタマイズや完全な自動化を求めるならCodeという住み分けになる。

↑

PJマネージャーの作業アレコレ †

PJマネージャーの作業は、アーキテクトの作業と比べCowork的なので

WordドキュメントのMarkDown?化（Wiki公開）
バグ・トラッキング・ツールのデータのメンテ、分析など。
,etc.

↑

Chat / CLI（UIの差異） †

↑

実は大きな差異はない。 †

GUIとCUIだが、そもそも文字列をプロンプトとして使用するLLMなので、Desktopアプリケーションの様な大きな違いはない。
（ただし、IDE組込系チャットやパーソナルRAG系など、入力プロンプト以上にプロンプト・エンジニアリングするDesktopアプリではエンドユーザー領域でGUIの恩恵も大きい）
また、昨今のCUIの隆盛によって、実はCLIの方が操作性も良い（ChatGUIもプロンプトなので）。

↑

ユースケースへの影響 †

コレだけ単純なI/Fの話なのでユースケースから外した（本質的にはユースケースに影響しない）。

これに対し、モードの話のYOLO/プロ用は、本質的なユースケースが異なる事が多い。
強いて言えば、Cowork系は、エンドユーザー向けなので、I/FとしてDesktopアプリ（GUI）を選択しているが、CLIの方が熟練者に対応できる。

↑

詳細 †

↑

共通 †

プロダクトごとに共通

↑

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 †

↑

利用の流れ †

コチラ

↑

使える機能 †

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、コマンド、サブ・エージェント、スキル、フック、プラグイン
- コマンド、サブ・エージェント、スキル、フック、プラグインはClaude Code発だった。
- 今となっては、GHCのチャットUIからも機能する。

ただし、コマンドはCLIのモノと、LLMのモノとで内容が異なる。
- CLIの「-」コマンドは所謂、CLIのコマンドとして機能する。
- LLMの「/」コマンドは、プロンプト・フローの動作に影響を与える。

↑

実装可能機能 †

スキル、コマンド、サブ・エージェント、フックなど、Claude Code初の技術が多い。
標準化も進んでおり、選んだプラットフォームにまだ適用されていない場合は、恐らくそう遠くないウチに使用できるようになるモノと思われる。

↑

ツール †

所謂一つの「Function calling」のツールで、サブ・エージェントの定義にツールを指定する。
ただ、通常のエージェントでは基本的なツールは使えるようで、特にナニかを追加で設定するということはなかった。

↑

MCP †

メイン・エージェントで使用可能なMCPサーバを追加する。
セキュアに大規模なSaaS（GitHubやAtlassian）機能を活用する...的な文脈で使用
認証が必要で再認証しないとエラーになったりすることが多い（/mcp → Re-authenticateが作法"笑"）。

↑

サブ・エージェント †

別のコンテキスト・ウィンドウで実行する。
メイン・エージェントと並列で動作させることができる。

使用するLLM、ツール、システム・プロンプトを追加する。
単純作業を廉価なLLMで実行したりすると良い。

↑

コマンド †

（カスタムSlashコマンド）

name属性をcommandとして利用可能な文字列を指定。
description属性にユースケースについての解説を書く。
メインコンテンツにコマンドが実行する内容を書く。

↑

スキル †

以前はcommandsに実装していたが、現在はskillsに実装するようになってきている。
name属性をcommandとして利用可能な文字列にすれば、カスタムSlashコマンドと同じ様に使用可能。
最小限のものであれば、MDファイル１つで定義可能。定義中に、外部スクリプトファイルなどを含めても良い。

↑

フック †

あまり使用されない。
イベント発生時に自動的に処理を実行するなどの目的で使用する。

↑

プラグイン †

マーケット・プレイスからMCP、スキル、コマンド、サブ・エージェント、フックを一括インストールする仕組み。
これらの複数の機能を活用して、１つの処理（論理的な機能）を実現するなどの目的で各機能をパッケージ化する。

↑

事例 †

↑

手順 †

プロ・ユースでは、タスクに書いた粒度で順に進めて行く。
なお「AGENTS.md」には様々なガイドラインへのリンクを張っておくと良い。

AGENTS.md、SPEC.md、PLAN.md等を与え、別途計画を立ててから実装を実行する（エージェントが別のPLAN.mdを生成する）。
- 細かくフェーズやステップを分ける場合、「PLAN_X.md、SPEC_X.mdを参照し、PLAN_X.mdのxフェーズ、yステップを実行してください。」などと指示すると良い。
- エージェントが生成したPLAN.mdに問題がなければ実装を実行する。計画を見るのが面倒なら実行結果を見て問題があったら、PLAN*.mdにフィードバックしても良い。

↑

DOCフォワード †

以下プロンプト例

「AGENTS.mdを参照し、SPEC.mdを生成して下さい。」
「AGENTS.md、SPEC.mdを参照し、モジュールXを対象としたSPEC_X.mdを生成して下さい。」
...

↑

プランニング †

以下プロンプト例

「AGENTS.md、SPEC.mdを参照し、PLAN.mdを生成して下さい。」
「AGENTS.md、SPEC_X.mdを参照し、PLAN_X.mdを生成して下さい。」
...

↑

コーディング †

以下プロンプト例

「AGENTS.md、SPEC(_X).mdを参照し、PLAN(_X).mdを実行してください。」
「AGENTS.md、SPEC(_X).md、PLAN(_X).mdを参照し、PLAN(_X) の Phase N を実行してください。」
...

※ エージェントがコーディングの前に「ホーム・ディレクトリ\.（プロダクト名）\plans\plan*.md」を自動生成する。

↑

MDファイル †

AGENTS.mdはリポジトリ直下に配置。
エージェントの実装可能機能の定義はプロダクト指定のフォルダに配置。
（ルートフォルダ名以外は標準化されているケースが多い）
ソレ以外のMDファイルのルート・フォルダは「docs」などとする

↑

AGENTS.md †

記載項目

各種要件
- ビジネス要件：なぜやるか
- 業務要件：業務をどう変えるか
- システム要件：システムに何を求めるか
  - 機能要件：システムに求める機能の要件（モジュール（責務（役割））一覧）
  - 非機能要件：システムに求める非機能（品質系：性能、可用性など）の要件

環境構築
- 開発環境
- デプロイ先環境

プランニング方針

始点と終点：要件からか仕様からか（何処までがFIXしているか？）

共通的な開発フロー：プラン概要を詳細プランにブレークダウンする際に使用。

設計：

・既存パターンを確認し、無いパターンは追加しない。
・新規実装の追加時は再利用を確認する。

実装

・最初に、必要となるD層や共通部品を実装する。
・次いで、画面項目定義から画面を実装する。
・次いで、トランザクションルートとなるB層メソッドの土台を実装する。
・次いで、必要に応じてトランザクションを引き継ぐB層、引き継がないB層メソッドの土台を実装する。
・次いで、画面イベントのハンドラを実装し、共通部品やトランザクションルートのB層メソッド呼び出しを行う。
・次いで、B層メソッドを実装し、共通部品やD層メソッド呼び出しを行う。

テスト：

・基本方針：TDD的か？など。
・テスト実施タイミング：D層、B層、P層コード作成・修正後

その他
- プロダクトに依っては、CLAUDE.md、GEMINI.mdに書く。
- CLAUDE.md、GEMINI.md内からインポート構文で「@AGENTS.md」とすれば共通化できる。

↑

SPEC.md †

開発対象のシステム機能の一覧と仕様を記載する。
共通仕様をSPEC.md、個別仕様をSPEC_X.mdに記載するなど。

一覧：機能一覧、画面一覧、画面遷移
- 機能要件が主入力。
- ただし、業務要件・非機能要件から派生する機能も確認する。

仕様：画面項目一覧、イベント一覧、イベント定義
- 前述の一覧が主入力（画面一覧、画面遷移）。
- 加えて、非機能要件、業務要件（業務ルール、権限、外部連携、運用制約）などを加味して具体化する。

※ 参考：生成AIを活用した設計書のブレークダウン

↑

PLAN.md †

ハイレベルの実装計画をPLAN.mdに記述、サブプランをPLAN_X.mdに生成して修正する。
個別のプランは実装開始前にエージェントがホーム・ディレクトリに自動生成する。

↑

*_GUIDE.md †

コーディング基準：CODING_GUIDE.md
ネーミング基準：NAMING_GUIDE.md
実装ガイド：IMPLEMENTATION_GUIDE.md
その他、必要に応じて追加：MMI標準など, etc.

↑

スキル †

実装ガイドの具体的な内容をスキル化する。

↑

オリジナル・コンテンツ（イキナリLLMコーディング・エージェント） のバックアップ(No.25)

目次 †

概要 †

基礎知識 †

ユースケース †

YOLO（フィジスタ、PoC、MVP） †

プロ用（フェーズ毎の実装＆検収） †

ドキュメント・フォワード †

システム開発（インフラ構築） †

移行・マイグレーション †

アーキテクトの作業アレコレ †

Coworkと変わらないカモ †

PJマネージャーの作業アレコレ †

Chat / CLI（UIの差異） †

実は大きな差異はない。 †

ユースケースへの影響 †

詳細 †

共通 †

MDファイル †

タスク †

YOLO †

プロ用 †

Chat †

利用の流れ †

使える機能 †

CLI †

利用の流れ †

使える機能 †

実装可能機能 †

ツール †

サブ・エージェント †

コマンド †

フック †

事例 †

手順 †

DOCフォワード †

プランニング †

コーディング †

MDファイル †

AGENTS.md †

SPEC.md †

PLAN.md †

*_GUIDE.md †

参考 †

オリジナル・コンテンツ（イキナリLLMコーディング・エージェント）のバックアップ(No.25)