「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -戻る([[LLMのユースケース]]、[[イキナリCA>オリジナル・コンテンツ(イキナリLLMコーディング・エージェント)]]) -戻る([[LLMのユースケース]]、[[CAのユースケース>オリジナル・コンテンツ(イキナリLLMコーディング・エージェント)]]) --[[生成AIを活用したプログラミング]] --生成AIを活用したシステム開発 --[[生成AIを活用した設計書のブレークダウン]] *目次 [#iaafb80e] #contents *概要 [#rea2e43d] [[プログラミング>生成AIを活用したプログラミング]]がメインだが、システム開発のスコープにも適用可能。 *詳細 [#oa82b177] **[[シェル・スクリプティング>https://techinfoofmicrosofttech.osscons.jp/index.php?%E3%82%B7%E3%82%A7%E3%83%AB]] [#zab33943] ***[[Bat>https://techinfoofmicrosofttech.osscons.jp/index.php?BAT]] [#o1da0e41] ***[[PowerShell>https://techinfoofmicrosofttech.osscons.jp/index.php?PowerShell]] [#o1b29037] ***[[Bash>https://techinfoofmicrosofttech.osscons.jp:443/index.php?Bash]] [#dcb960e9] ***クラウド [#pa03c13b] -[[Azureのシェル>https://techinfoofmicrosofttech.osscons.jp/index.php?Azure%E3%81%AE%E3%82%B7%E3%82%A7%E3%83%AB]] **IaC:Infrastructure as Code [#b772daeb] ***ツール [#d0667f2a] -[[Chef]] -[[Ansible]] -[[Puppet]] ***コンテナ [#rca4374c] -[[Dockerfile>Dockerファイル]] -[[Dockerコマンド]] -[[DockerCompose>Dockerコンポーズ]] ***CaaS [#d485b211] -[[AzureのCaaS>https://techinfoofmicrosofttech.osscons.jp/index.php?Azure%E3%81%AEPaaS#i19a4534]] **CI/CD:Continuous Integration/Delivery [#ib944988] ***GitHub [#d7151751] GitHub Actions:https://github.com/OpenTouryoProject/OpenTouryo/issues/517 ***Azure [#nc562ff9] Azure Pipelines とか Azure DevOps とか。 **システム運用系(構築時に含まれる) [#x36c76d5] ***監視・SRE [#d06de718] -Datadog, Prometheus, OpenTelemetry -ダッシュボード/アラートコード生成/ログ解析と自動復旧手順構築 ***DevSecOps [#adf6eede] -OPA, Trivy, SonarQube -パッケージ更新、セキュリティポリシー違反の自動修正PR作成 ***DB & Data [#r4d86372] -Liquibase, Prisma, PostgreSQL -マイグレーションコード生成、モックデータ生成 ***テスト・QA [#t626e445] -Playwright, JUnit, pytest -API/E2Eテスト自動生成、未通過テストの自己修復 ***Modernization [#h72fbcec] -Terraformer, Mermaid, Go -レガシーインフラのコード化、構成ドキュメントの自動更新 **機能開発 [#o9e2b9ba] コチラは開発ツールとして使用するのではなく、ランタイム的に組み込む話。 ***UI・表示系 [#l2dbffab] -UI生成:ユーザーの入力やコンテキストに応じて、LLMがその場でUI生成。固定のフォームではなく「今必要な入力項目」を都度組み立てる。 -パーソナライズ:通知メッセージ、ダッシュボードの見せ方、エラーメッセージなどをユーザー属性に応じてランタイムで生成し出し分ける。 ***フロントエンド代替系 [#d26f43a2] -チャットボットの主インターフェース化:従来のGUI操作の代わりに、対話がそのままバックエンド操作のトリガーになる。 -オンデマンド翻訳/ローカライズ:表示のたびにその場で翻訳・要約するランタイム処理。 ***データI/O系 [#y8816ccf] データI/O系に適用する。 -入力:入力補正・正規化:住所や氏名などの表記ゆれを、LLMがランタイムで正規化してから保存する。 -入出力:ETL/マッピングの動的推論:連携先のスキーマが変わった際に、マッピングルールをLLMがその都度推測して変換する。 -出力:自然言語→SQL/API変換: ユーザーの自然言語問い合わせをその場でクエリに変換して実行。スキーマ変更にも比較的柔軟に追従できる。 ***データ変更 [#d35e3b8b] データ変更に適用する。 -データストアを変更すると、UIにリニアに反映が掛かる仕組みなどは面白い(オートメーションにも見える)。 -処理要求を一度、データストアに登録し、コレを非同期に実行する仕組みにしておけば、AIによる処理要求が可能になる。 ***業務・意思決定系 [#r58595e3] -ルール・エンジンの代替:承認フローや条件分岐など、ハードコードしていた業務ルールをLLMが自然言語の方針から都度判断。 -イベント・トリアージ:ログやイベントストリームをLLMがリアルタイムに解釈し、優先度判定やアラートの要否を決める。 ***自己修復・運用系 [#v9480188] -エラー・ハンドリング/自己修復:実行時エラーをLLMが解析し、リトライ方法の変更や簡単な自動パッチを提案・適用。 -動的オーケストレーション:複数APIのレスポンスをLLMが解釈し、次にどのAPIを呼ぶかをエージェント的に決定。 *事例 [#o1ee800c] **Linux構築 [#y271d910] 既に「[[この辺>LLMのFT#a8ccf18b]]」で多用。 ***入力の作成 [#m6e76c9b] シェル・スクリプトを作成する。 ***出力の読取 [#k2d53c3b] シェル・スクリプトの実行結果を読み取る。 **WSL2上でのコンテナ開発 [#x48980e6] ***定義 [#q79667b8] [[Dockerfile>Dockerファイル]]、[[DockerCompose>Dockerコンポーズ]]を書いて実行できる。 ***実行 [#cfe71338] -[[Docker Desktop>https://techinfoofmicrosofttech.osscons.jp/index.php?Docker%20Desktop%20for%20Windows]]が無くてもPowerShellで記述してWSL2に入らずDockerコマンドを実行できる。 -ただし、Desktop系プロダクトを活用した方が、PowerShell依存を軽減できるため保守性は良くなる。 **PaaS、CaaSのIaC [#y30502e3] ***開発環境 [#p753a9dc] 開発環境向けのコンテナ・オーケストレーション。 ***稼働環境 [#p5447857] 稼働環境向けのコンテナ・オーケストレーション。 **OAuth2/OIDCアーキテクチャ開発 [#c6cc9290] IdP、ResourceServerをコンテナ化 ***開発環境 [#neaea94f] 開発環境向けのコンテナ・オーケストレーション。 ***稼働環境 [#gb12f80f] 稼働向けのコンテナ・オーケストレーション。 **CI/CDパイプラインの構築 [#ja9e8c15] *考察 [#gbae3334] **システム構築に向く [#ja8cdf1c] ***環境差異、冪等性の罠に対応 [#j0bb60c1] [[Chef]]、[[Ansible]]、[[Puppet]]のような構成管理・インフラ自動化(パッケージ導入、設定ファイル配布、サービス管理、権限設定など)は、 -環境の状態に強く依存する(冪等性の罠):「今の状態」に応じて挙動が変わることが前提。まっさらな環境では動いても、そうではない環境では失敗する。 -対象環境を事前に完全に把握できない:どのディストリか、どのパッケージマネージャか、SELinuxが有効か、既存の設定ファイルに何が書いてあるか。 -副作用を持つ操作が多い:ファイル書き換え、サービス再起動、パッケージインストールなど「実行してみないと結果が分からない」操作の比率が通常のアプリコードより高い。 -エラーメッセージの抽象度が低い:「Permission denied」「Package not found」のようなエラーが、実際の原因を直接教えてくれないことが多く、原因特定に一往復必要になりがち。 などの、問題のあるタスクに対応するツールだったが、[[推論エージェント(コーディング・エージェント)>推論エージェント#l70a7dd0]]は自然言語定義でこれらを実施できる。 ***低コストで人手に戻れない。 [#g60d13bc] エージェントは失敗コストがほぼゼロに近いので進出後、人手に戻れない。 -自分でコマンドを叩いて失敗すると、原因調査・ログ確認・再実行という一連の作業を全部自分の時間でやる必要がある。 -エージェントはコマンド実行 → 結果確認 → 修正のサイクルをコンテキスト・スイッチなし即座に回せる。 -原因は不明のケースでも「事例を検索しnパターン試して当たりを引く」と言う試行を力技でやってくれる。 **Linux構築 [#ac263557] ***そもそも、Linux(CUI)は難しかったか? [#g12fad62] -WSL(2)の登場で非常に敷居が下った。敷居が下った結果、ピンキリだが難しくはないという印象。 -むしろ、CUIのため、コピペで手順を再現できるため、エンジニア向けではあるという印象。 -深い点は難易度が高い。ただし、インターネット上に情報はあるので対応は可能な印象。 ***LLMとCUIの親和性の高さがプラスに作用 [#b5b364a1] -CUIは「Character」UIなのでLLMとの親和性が高い。 -GUIと比べると、実行手順の提示や実行結果の提示に有利。 -ネットで得た手順をLLMに解説させて実行することで問題発生を抑止できる。 -また、推論エージェントにより実行手順の自動実行まで可能になった。 -これによって、Windows App Development CLI (winapp CLI)などの開発も進んでいる。 ※ WindowsもPowerShellを強化しており、シェル・スクリプトでの本格的な構築が可能になっている。 **WSL2を用いたコンテナ開発 [#m4d563e5] ***冪等性の罠 [#oaf3502b] WSL2のコンテナ起動停止まわりは特に「叩いてみないと分からない」要素が複合した、典型的な試行錯誤ゾーン。 -「Windows側から見たプロセス状態」と「Linux側の実際の状態」の食い違いでリトライ・ポーリングが必要になりがち。 -WSL2内のsystemdが有効かどうかで挙動が変わる(/etc/wsl.conf の [boot]セクション に systemd=true と書く) -WSL2の2つのネットワークモード(NAT/mirrored)の初期化タイミングの差異で同様にリトライ・ポーリングが必要になりがち。 -起動直後は見えているのに数秒後に見えなくなる、みたいな非決定性(継続的に状態が安定していることを複数回確認する必要がある) ***Desktopナシ [#t61ffadb] -[[Docker Desktop>https://techinfoofmicrosofttech.osscons.jp/index.php?Docker%20Desktop%20for%20Windows]]有償化で企業内利用が廃れたのが普及の足枷としては大きかった。 -WSL2からDockerを利用できるようになったが、BATで気軽に実行できなくなった。PowerShellで実装すればWSL2に入らず実行できる。 --コーディング・エージェントで、トラブルシュートしながらPowerShellを記述している所を観測したが人手では難しそうだった。 --コーディング・エージェントによって得たナレッジを明文化しておけば、人手での対応でも再現可能な可能性はある。 --しかし、実際は人手での実装は困難と言う結論(コレだけのために、専門職をアサインする必要があるレベル感)。 ***Desktopアリ [#ic11ed3e] -OSSの、Rancher Desktopや、Podman Desktopの登場により、再び、Windows上からDockerコマンドを実行することが出来るようになった。 -Desktopのブラック・ボックス問題(トリプル・レイヤー・ネットワークなど)も顕在化しているがエージェントで対応はできそう。 ***どちら? [#p00fbd0f] 生成AIは[[Rancher Desktop>https://techinfoofmicrosofttech.osscons.jp/index.php?Rancher%20Desktop%20for%20Windows]]ような実績のあるOSSツールを会社として検証・標準化するのがコスパが良いと提案。 **PaaS、CaaSのIaC [#x5340389] ... **OAuth2/OIDCアーキテクチャ開発 [#yaf3ac82] コチラは環境構築の手数が多いのでDockerなど、コンテナを使用して負荷軽減するのだが、そもそもコンテナ自体が難しいと言う... -... **CI/CDパイプラインの構築 [#k88a7f4b] ... *参考 [#gfd1e303] ...