今までの内容
こちらを参照ください。
第1回
https://qiita.com/akiraabe/items/9762582939191c3e4a39
第2回
https://qiita.com/akiraabe/items/6d959fae53e3f0f97772
はじめに
この記事は、生成AIによるコードベース解析 というテーマでの実験内容をまとめています。
3回目です。
今日の内容
前回から今回までの間に、Copilot Chat Agentが登場したので、その件を中心に書きます。
従って、コードベース解析というテーマから少し外れます。
内容としては、以下を取り扱います。
- Copilot Chat Agentのはじめ方！
- Copilot Chat Agentを使ってみた！
- 新規アプリ構築（前にClineで作った部員管理）
- 既存コードベース解析のうえで機能追加（DDDのシンジケートローン）
- ライブデモ？（Agentでデータモデリングをする！）
Copilot Chat Agentのはじめ方！
この辺の記事を読みましょう！
（現時点では、Copilot Chat Agentは EXPERIMENTAL です！ VSCode Insidersをインストールする必要があります！）
Copilot Chat Agentを使ってみた！
新規アプリ構築（前にClineで作った部員管理）
こちらは、GitHubにソースを公開してあります。
既存コードベース解析のうえで機能追加（DDDのシンジケートローン）
こちらは、静止画像がスクショしてあります。
お題としては、「シンジケートローンの融資実行時に返済明細を展開する処理」を追加しています。
ひとまず機能追加のプランを考えてもらった。
インストラクションにギャル語で！っていうのがあるので、AIはギャル語を喋ります！
分析結果！これはかなり正しい！！
どうやら終わったらしい！
実はコンパイルエラーや実行時のエラーがあるため、このあと少し修正してもらっています！
無事に作成された返済明細！！
ソースコード：
https://github.com/tis-abe-akira/ddd-breakthrough/commit/96d53d9cc70237788efc5852d384c010abcf10cb
ライブデモ？（Agentでデータモデリングをする！）
これがプロンプトです。
<task>
今からイミュータブルデータモデルに沿って、データモデリングしてみたいと思います。
以下にイミュータブルデータモデルの手順（5個のステップ）を提示しますので、よく理解してください。
<イミュータブルデータモデルの手順>
## はじめに
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。
UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。
このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
## ステップごとの実行キャラ（基本的には全部ギャル）
ステップ
1. 明るいリーダータイプのギャル
2. 冷静に鋭い突っ込みをするギャル
3. 単なるアホなギャル
4. おっとりしたギャル
5. ひたすら前向きに盛り上げるギャル
## ステップ
1. エンティティを抽出する。(提示されたユースケースの名詞、動詞に着目)
5W1Hがエンティティの候補となる。
以下は、例である。
[[Who]] 従業員,患者,プレイヤー,顧客,生徒,...
[[What]] 製品,サービス,コース,曲,...
[[When]] 時間,日付,月,年,年度,...
[[Where]] 送付先,URL,IPアドレス,...
[[Why]] 注文,返品,入金,出金,取引,…
[[How]] 請求書,契約書,注文書,…
2. 洗い出したエンティティを[リソース]と[イベント]に分類する。
イベントに分類する基準は属性に「日時・日付（イベントが実行された日時・日付）」を持つものである。
これはエンティティ名に「〜する」を付けてみることによって識別もできる。上記例では、「注文する」というのは自然に成り立つが、「会員する」というのは成り立たない。すなわち[[イベント]]は動詞から抽出したエンティティであることを意味する。
また、5W1Hの分類において、
Who, What, When, Where → リソース
Why, How → イベント
になる。
[* 注: 日時属性とは…?]
「請求予定日」のように将来の予定を表すものや、「有効期限」「適用開始日」のようにデータのライフサイクルを表すものは、ここでいう"日時"属性ではない。
業務のアクティビティを記録するのがイベントエンティティであり、その行われた時刻を記録するのがここでいう”日時”属性である。
3. イベントエンティティには1つの日時属性しかもたないようにする。
よく考えることなしに作られたイベントエンティティには多くの日時属性を含むことがある、これを分解しそれぞれイベントエンティティを作るのである。
4. リソースに隠されたイベントを抽出する。（リソースに更新日時をもちたい場合にはイベントが隠されている可能性がある）
- 例）社員情報（リソース）の更新日時がある場合には、社員異動（イベントエンティティ）を抽出する。
5. エンティティ間の依存度が強すぎる場合には、交差エンティティ（関連エンティティ）を導入する。（カーディナリティが多対多の関係を持つような場合に導入する）
</イミュータブルデータモデルの手順>
<指示事項>
この手順を用いて、以下のような業務に関し、イミュータブルデータモデルの手順に沿って分析を行い、データモデルを出力してください。
データモデルは、Mermaid形式で出力してください。
まずはStep1からお願いします。
</指示事項>
<対象業務>
## 機能要件
1. シンジケートローンは、単一の貸し手が引き受けるには大きすぎるローンを複数の貸し手が共同で提供する仕組みです。
2. 例えば、Intelが10億ドル規模の工場を建設する際に必要な巨額の融資は、通常、複数の貸し手が「シンジケート」を形成して資金を提供します。
3. 投資銀行が通常シンジケートのリーダーとして機能し、取引や他のサービスを調整します。
4. ローンの借り手が資金を要求すると、シンジケートのリーダーは全メンバーに対して各自の持分を呼び出します。
5. シンジケートメンバーは通常、自身の持分を提供しますが、しばしば他のメンバーと交渉して投資額を増減させることがあります。
6. モデルにはLoan Investment（ローン投資）という派生オブジェクトがあり、これは特定の投資家のローンへの貢献を表します。
7. ファシリティ（融資枠）の持分は、実際のローン引き出し（ドローダウン）への参加のガイドラインにすぎません。
8. 借り手がファシリティを利用できる特権に対して手数料を支払う場合、この資金はローンの状況に関係なく、ファシリティの持分に応じて分配されます。
このシステムは、複雑な金融取引を管理し、異なる参加者間での資金の分配や調整を行うためのものです。
### 補足
Transactionのサブタイプごとの資金の流れを説明します。
1. シンジケートの組成について：
はい、その理解で正確です。ファシリティを複数の出資者が組成することは、シンジケートの組成と言い換えても適切です[^0]。シンジケートローンでは、複数の金融機関（投資家）が協調してローンを提供するため、このプロセスをシンジケートの組成と呼びます。
2. Transactionのサブタイプごとの資金の流れ：
a) Facility Investment（ファシリティ投資）:
投資家 → シンジケート（ファシリティ）
各投資家がシンジケートに資金を提供します。
b) Drawdown（ドローダウン）:
シンジケート（ファシリティ） → 借り手
借り手がファシリティから資金を引き出します。
c) Interest Payment（利息支払い）:
借り手 → シンジケート → 投資家
借り手が支払った利息がシンジケートを通じて投資家に分配されます。
d) Principal Payment（元本返済）:
借り手 → シンジケート → 投資家
借り手が返済した元本がシンジケートを通じて投資家に分配されます。
e) Fee Payment（手数料支払い）:
借り手 → シンジケート → 投資家
借り手が支払った手数料（ファシリティ利用料など）がシンジケートを通じて投資家に分配されます。
f) Facility Trade（ファシリティ取引）:
投資家A → 投資家B
投資家間でファシリティのシェアが取引されます。実際の資金移動は投資家間で直接行われる場合もありますが、シンジケートを通じて行われることもあります。
これらの取引において、シンジケート（通常はリード銀行が管理）が資金の集中と分配の役割を果たします。各取引は、関連する Share Pie や Amount Pie に基づいて処理され、投資家間での適切な資金配分が行われます。
</対象業務>
</task>
勉強会でライブデモをやった結果です！
https://github.com/tis-abe-akira/copilot-agent02-data-modeling/blob/main/chat-history.md
まとめ
現時点では、CopilotのAgentはあくまでもEXPERIMENTALです。
CursorやClineなどに比べると、対象のソースコードの把握に改善点がありそうですが、試用してGitHub社にフィードバックすることで、クオリティーが向上するかもしれません。
現段階でも、使い方によってはかなり有効なツールになると思いました。
- 自律的にファイルの修正をする点
- ターミナルのエラーを検知して修正をする点
これらは、コーディング系のエージェントとしてはもはや当たり前の機能な気もしますが、Copilot登場からの進化を考えるとなかなか感慨深いものがあります。（親戚のおじさんかよ！？）