「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
プログラミングがメインだが、システム開発のスコープにも適用可能。
詳細 †
クラウド †
IaC：Infrastructure as Code †
コンテナ †
CaaS †
CI/CD：Continuous Integration/Delivery †
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)などの開発も進んでいる。
※ WindowsもPowerShell?を強化しており、シェル・スクリプトでの本格的な構築が可能になっている。
WSL2上でのコンテナ開発 †
Docker Desktop（の企業内利用）が廃れたのが普及の足枷としては大きかった（Rancher Desktop、Podman Desktopを使ったら？）。
Desktopアリ †
- Docker Desktop有償化も、WSL2からDockerを利用できるようになったが、BATで気軽に実行できなくなった。
- また、Docker Desktopのブラック・ボックス問題も顕在化した（トリプル・レイヤー・ネットワークなど）。
Desktopナシ †
PowerShell?で記述してWSL2に入らず実行できる。
- コーディング・エージェントで、トラブルシュートしながらPowerShell?を記述している所を観測したが人手では難しそうだった。
- コーディング・エージェントによって得たナレッジを明文化しておけば、人手での対応でも再現可能な可能性はある。
- 人手での実装は困難と言う結論（コレだけのために、専門職をアサインする必要があるレベル感）。
どちら？ †
生成AIはRancher Desktopような実績のあるOSSツールを会社として検証・標準化するのがコスパが良いと提案をした。
...そもそも †
- Ansibleのような構成管理・インフラ自動化(パッケージ導入、設定ファイル配布、サービス管理、権限設定など)は、
- 環境の状態に強く依存する(冪等性の罠)：「今の状態」に応じて挙動が変わることが前提。まっさらな環境では動いても、そうではない環境では失敗する。
- 対象環境を事前に完全に把握できない：どのディストリか、どのパッケージマネージャか、SELinuxが有効か、既存の設定ファイルに何が書いてあるか。
- 副作用を持つ操作が多い：ファイル書き換え、サービス再起動、パッケージインストールなど「実行してみないと結果が分からない」操作の比率が通常のアプリコードより高い。
- エラーメッセージの抽象度が低い：「Permission denied」「Package not found」のようなエラーが、実際の原因を直接教えてくれないことが多く、原因特定に一往復必要になりがち。
- WSL2のコンテナ起動停止まわりは特に「叩いてみないと分からない」要素が複合した、典型的な試行錯誤ゾーン。
- wsl.exe経由の呼び出しとWindows側プロセスの状態の食い違い
- WSL2内のsystemdが有効かどうかで挙動が変わる（/etc/wsl.conf の [boot]セクション に systemd=true と書く）
- ネットワーク周り(NAT/mirrored)の初期化タイミング
- 起動直後は見えているのに数秒後に見えなくなる、みたいな非決定性
- エージェントは失敗コストがほぼゼロに近いので進出後、人手には戻れない。
- 自分でコマンドを叩いて失敗すると、原因調査・ログ確認・再実行という一連の作業を全部自分の時間でやる必要がある。
- エージェントに任せると「10パターン試して当たりを引く」を並行的に、しかも自分の集中力を消費せずにやってくれる。
- 探索と検証のループが速い
- コマンド実行→結果確認→修正、のサイクルをエージェントは待ち時間以外ほぼ即座に回せるので、体感の効率が段違い。
- 人間が手でこれをやると、コンテキストスイッチのコストが毎回発生します。
- 「なぜ失敗したか」より「動くまで回す」で片付く場面が実は多い
- 特に環境依存の強い領域だと、根本原因を完全に理解するよりも、動く組み合わせを見つける方が実用上のゴールになることが多く、これはエージェント向きの働き方と相性がいい。
- 一方で気をつけたいのは、試行錯誤で「たまたま動いた」設定がなぜ動いたのか分からないまま採用されるケースだが、最近のエージェントはココまで解決する能力はある。
OAuth2/OIDCアーキテクチャ開発 †
コチラは環境構築の手数が多いのでDockerなど、コンテナを使用して負荷軽減するのだが、そもそもコンテナ自体が難しいと言う...
PaaS、CaaSのIaC †
...
CI/CDパイプラインの構築 †
...
参考 †
...
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
