「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
プログラミングがメインだが、システム開発のスコープにも適用可能。
詳細 †
クラウド †
IaC †
コンテナ †
CaaS †
CI/CD †
GitHub Actions
Azure †
Azure Pipelines とか Azure DevOps? とか。
機能開発 †
コチラは開発ツールとして使用するのではなく、ランタイム的に組み込む話。
UI・表示系 †
- UI生成：ユーザーの入力やコンテキストに応じて、LLMがその場でUI生成。固定のフォームではなく「今必要な入力項目」を都度組み立てる。
- パーソナライズ：通知メッセージ、ダッシュボードの見せ方、エラーメッセージなどをユーザー属性に応じてランタイムで生成し出し分ける。
フロントエンド代替系 †
- チャットボットの主インターフェース化：従来のGUI操作の代わりに、対話がそのままバックエンド操作のトリガーになる。
- オンデマンド翻訳/ローカライズ：表示のたびにその場で翻訳・要約するランタイム処理。
データI/O系 †
データI/O系に適用する。
- 入力：入力補正・正規化：住所や氏名などの表記ゆれを、LLMがランタイムで正規化してから保存する。
- 入出力：ETL/マッピングの動的推論：連携先のスキーマが変わった際に、マッピングルールをLLMがその都度推測して変換する。
- 出力：自然言語→SQL/API変換: ユーザーの自然言語問い合わせをその場でクエリに変換して実行。スキーマ変更にも比較的柔軟に追従できる。
データ変更 †
データ変更に適用する。
- データストアを変更すると、UIにリニアに反映が掛かる仕組みなどは面白い（オートメーションにも見える）。
- 処理要求を一度、データストアに登録し、コレを非同期に実行する仕組みにしておけば、AIによる処理要求が可能になる。
業務・意思決定系 †
- ルール・エンジンの代替：承認フローや条件分岐など、ハードコードしていた業務ルールをLLMが自然言語の方針から都度判断。
- イベント・トリアージ：ログやイベントストリームをLLMがリアルタイムに解釈し、優先度判定やアラートの要否を決める。
自己修復・運用系 †
- エラー・ハンドリング/自己修復：実行時エラーをLLMが解析し、リトライ方法の変更や簡単な自動パッチを提案・適用。
- 動的オーケストレーション：複数APIのレスポンスをLLMが解釈し、次にどのAPIを呼ぶかをエージェント的に決定。
事例 †
Linux構築 †
既に「この辺」で多用。
WSL2上でのコンテナ開発 †
OAuth2/OIDCアーキテクチャ開発 †
PaaS、CaaSのIaC †
- コンテナ開発 → コンテナ活用開発 → コンテナ・デプロイ
- 稼働環境向けのコンテナ・オーケストレーション。
CI/CDパイプラインの構築 †
考察 †
Linux構築 †
そもそも、Linuxは難しかったか？ †
- WSL2の登場で非常に敷居が下った。敷居が下った結果、ピンキリだが難しくはないという印象。
- むしろ、CLIのため、コピペで手順を再現できるため、エンジニア向けではあるという印象。
- 深い点は難易度が高い。ただし、インターネット上に情報はあるので対応は可能な印象。
LLMとCLIの親和性 †
- CLIは「Character」UIなのでLLMとの親和性が高い。
- GUIと比べると、実行手順の提示や実行結果の提示に有利。
- ネットで得た手順をLLMに解説させて実行することで問題発生を抑止できる。
- また、推論エージェントにより実行手順の自動実行まで可能になった。
- これによって、Windows App Development CLI (winapp CLI)などの開発も進んでいる。
WSL2上でのコンテナ開発 †
Docker Desktop（の企業内利用）が廃れたのが普及の足枷としては大きかった（Rancher Desktop、Podman Desktopを使ったら？）。
Desktopアリ †
- Docker Desktop有償化も、WSL2からDockerを利用できるようになったが、BATで気軽に実行できなくなった。
- また、Docker Desktopのブラック・ボックス問題も顕在化した（トリプル・レイヤー・ネットワークなど）。
Desktopナシ †
PowerShell?で記述してWSL2に入らず実行できる。
- コーディング・エージェントで、トラブルシュートしながらPowerShell?を記述している所を観測したが人手では難しそうだった。
- コーディング・エージェントによって得たナレッジを明文化しておけば、人手での対応でも再現可能な可能性はある。
- 人手での実装は困難と言う結論（コレだけのために、専門職をアサインする必要があるレベル感）。
どちら？ †
生成AIはRancher Desktopような実績のあるOSSツールを会社として検証・標準化するのがコスパが良いと提案をした。
OAuth2/OIDCアーキテクチャ開発 †
コチラは環境構築の手数が多いのでDockerなど、コンテナを使用して負荷軽減するのだが、そもそもコンテナ自体が難しいと言う...
PaaS、CaaSのIaC †
...
CI/CDパイプラインの構築 †
...
参考 †
...
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
