Skip to content

DNET_LLMCodingAgent

Jump to bottom
nishi_74322014 edited this page Sep 12, 2026 · 2 revisions

オリジナル・コンテンツ（イキナリLLMコーディング・エージェント）

概要

「生成AIを活用したプログラミング」ページ中で紹介したコーディング・エージェントは、
「Master Vibe Coding with AI Coding Agents：Claude Code...」にあるように使用できる。

...つまり、以下のようなユースケースで活用可能と言える。
なお、以下の基礎知識があることが望ましい（必要・前提の知識ではない）。

基礎知識

LLM本体

LLMのPE

LLMのFT

LLMエージェント

推論エージェント

ユースケース

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

要件のみ渡して開発を進める。フィジスタ、PoC、MVPなどで有用。

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

※ カスタム・フレームワークについての考察

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

  • YOLOで、要件のみで開発ができることから明らかだが、要件から仕様や計画へのブレークダウンができる。
  • プロ・ユースの仕様や計画をエージェントが生成し、人間が確認＆修正を行ってから実行するなども可能。

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

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

（開発環境にも適用可能）

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

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

移行・マイグレーション

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

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

アーキテクトであればコーディング・エージェントとチャットしさえすれば流れでアセットが構築される。

  • 環境構築スクリプト開発
  • 開発用テンプレート実装
  • 各種の治工具ツール開発
  • 自動化スクリプト開発、自動化スキル（元 Wiki 側にページの実体が無いリンク）開発
  • 各種の問題点の修正：Review → Issue → Pull Request
  • , etc.

Coworkと変わらないカモ

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

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

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

  • WordドキュメントのMarkDown化（Wiki公開）

  • バグ・トラッキング・ツールのデータのメンテ、分析など。

  • LLMの提案

    • ブレークダウン

      • 要件からの仕様書生成
      • 仕様書からの実装プラン生成（工数見積も可能）

    • 品質管理とリスク検知

      • 非エンジニア目線でのセキュリティ・パフォーマンスリスク評価
      • 「OWASP Top 10に基づく脆弱性」「ボトルネックになるクエリ」「ログ・ベースの調査」

    • クロス・リファレンス系

      • 影響範囲（ブラストレジアス）の自動特定
      • コードベースからのアーキテクチャ・依存関係の自動図式化
      • その他、仕様と実装の乖離を調査する。

    • 保守・運用フェーズ

      • リリースノート・変更履歴の自動生成
      • 障害対応（インシデント）時の一次解析

Chat / CLI（UIの差異）

実は大きな差異はない。

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

利用の流れ（Chat）

コチラ

使える機能（Chat）

CLIと同じ。ただし、CLIの「-」コマンドは使用できない。

CLI

Chatと同じ。違いは、指示がし易い点。

  • 何気に、ChatもGUIと見せかけて文字列ベースなので、その差は、一般的な GUI vs CUI と言う程でもない。
  • 両方文字列ベースのI/Fだと、機能差は無くとも、CLI風のI/Fの方が柔軟性が高い（詳しくは「利用の流れ」で）。

利用の流れ（CLI）

  • 基本は、Chatと同じだが、以下の点で、CLIが優れている。

  • 「/」コマンドの活用

    • /status：実行にあたっての様々な状態を一望できる。
    • /context、/compact、/clear：などでコンテキスト管理が容易

  • 実はインタラクティブ性能もCLIの方が高い。

    • Chatだと基本は文字列になる。一部、Chatでの対応もされている。
    • しかし、近年のCLIは「Chatでの対応」より優れたインタラクティブ機能がサポートされている。
      • 疑似タブ切り替え（Tabs）
      • セレクトボックス（Select / List Prompt）
      • マルチセレクト / チェックボックス（Checkbox / Multi-select）
      • トグル / トグルスイッチ（Toggle / Confirm）

使える機能（CLI）

各種機能が利用可能

実装可能機能

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

ツール

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

MCP

  • MCP

  • メイン・エージェントで使用可能なMCPサーバを追加する。

  • セキュアに大規模なSaaS（GitHubやAtlassian）機能を活用する...的な文脈で使用

  • 認証が必要で再認証しないとエラーになったりすることが多い（/mcp → Re-authenticateが作法"笑"）。

サブ・エージェント

  • 別のコンテキスト・ウィンドウで実行する。

  • メイン・エージェントと並列で動作させることができる。

  • 使用するLLM、ツール、システム・プロンプトを追加する。

  • 単純作業を廉価なLLMで実行したりすると良い。

コマンド

（カスタムSlashコマンド）

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

スキル

  • スキル

  • 以前はcommandsに実装していたが、現在はskillsに実装するようになってきている。

  • name属性をcommandとして利用可能な文字列にすれば、カスタムSlashコマンドと同じ様に使用可能。

  • 最小限のものであれば、MDファイル１つで定義可能。定義中に、外部スクリプトファイルなどを含めても良い。

フック

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

プラグイン

事例

手順

  • プロ・ユースでは、タスクに書いた粒度で順に進めて行く。

  • なお「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.

スキル

...

開発のコツ

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

    • スキルはある意味、MD形式の文字列開発と言える。

      • 新規作成時はドキュメントやコードを読ませ立ち上げ、以降、修正・検証エージェントのループに入れる。
      • 生成された文字列は人間が読むよりアテンションの効いた推論LLMエージェントが読むのに適した文字列になっている気がする。
      • カナリ多くのスキルを開発してみたが、自分で書くことはほぼ無く、既存コード・マニュアルから起こし以降フィードバッグ・ループで改善

    • スキル開発で人間が主に指摘した事

      • 「重複、分割、記載箇所、実測したがスキル記載には不要。」など、現物に強いが全体最適化、抽象化が苦手。
      • AI曰く編集規律「正確性、正しい配置・範囲、簡潔さ、体系化、一貫性と網羅性。メタ指示（類似を洗え）」が中心。

  • 環境構築、自動化スキル

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

参考

移行メモ

  • 「戻る」の並びにある自ページは、その旨を補ってプレーン・テキストとした。
  • 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
  • PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
  • 元 Wiki の行頭空白によるプレフォーマット・ブロックは、 フェンス付きコードブロックにした。
  • 同名の見出し（「使える機能」「利用の流れ」）が Chat / CLI の節に 重複するため、括弧で文脈を補って一意にした。
  • 「自動化スキル」のリンク先（スキル）は元 Wiki 側にページの実体が無い （リンク切れ）ため注記に変更した。

Tags: 移行, コーディング・エージェント, LLM, YOLO, Vibe Coding, Chat, CLI, スキル, MCP

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally