「[[.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]
...

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS