「.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上でのコンテナ開発 †
定義 †
Dockerfile、DockerComposeを書いて実行できる。
実行 †
- Docker Desktopが無くてもPowerShell?で記述してWSL2に入らずDockerコマンドを実行できる。
- ただし、Desktop系プロダクトを活用した方が、PowerShell?依存を軽減できるため保守性は良くなる。
PaaS、CaaSのIaC †
開発環境 †
開発環境向けのコンテナ・オーケストレーション。
稼働環境 †
稼働環境向けのコンテナ・オーケストレーション。
OAuth2/OIDCアーキテクチャ開発 †
IdP、ResourceServer?をコンテナ化
開発環境 †
開発環境向けのコンテナ・オーケストレーション。
稼働環境 †
稼働向けのコンテナ・オーケストレーション。
CI/CDパイプラインの構築 †
考察 †
システム構築に向く †
環境差異、冪等性の罠に対応 †
Chef、Ansible、Puppetのような構成管理・インフラ自動化(パッケージ導入、設定ファイル配布、サービス管理、権限設定など)は、
- 環境の状態に強く依存する(冪等性の罠)：「今の状態」に応じて挙動が変わることが前提。まっさらな環境では動いても、そうではない環境では失敗する。
- 対象環境を事前に完全に把握できない：どのディストリか、どのパッケージマネージャか、SELinuxが有効か、既存の設定ファイルに何が書いてあるか。
- 副作用を持つ操作が多い：ファイル書き換え、サービス再起動、パッケージインストールなど「実行してみないと結果が分からない」操作の比率が通常のアプリコードより高い。
- エラーメッセージの抽象度が低い：「Permission denied」「Package not found」のようなエラーが、実際の原因を直接教えてくれないことが多く、原因特定に一往復必要になりがち。
などの、問題のあるタスクに対応するツールだったが、推論エージェント（コーディング・エージェント）は自然言語定義でこれらを実施できる。
低コストで人手に戻れない。 †
エージェントは失敗コストがほぼゼロに近いので進出後、人手に戻れない。
- 自分でコマンドを叩いて失敗すると、原因調査・ログ確認・再実行という一連の作業を全部自分の時間でやる必要がある。
- エージェントはコマンド実行 → 結果確認 → 修正のサイクルをコンテキスト・スイッチなし即座に回せる。
- 原因は不明のケースでも「事例を検索しｎパターン試して当たりを引く」と言う試行を力技でやってくれる。
Linux構築 †
そもそも、Linux（CUI）は難しかったか？ †
- WSL(2)の登場で非常に敷居が下った。敷居が下った結果、ピンキリだが難しくはないという印象。
- むしろ、CUIのため、コピペで手順を再現できるため、エンジニア向けではあるという印象。
- 深い点は難易度が高い。ただし、インターネット上に情報はあるので対応は可能な印象。
LLMとCUIの親和性の高さがプラスに作用 †
- CUIは「Character」UIなのでLLMとの親和性が高い。
- GUIと比べると、実行手順の提示や実行結果の提示に有利。
- ネットで得た手順をLLMに解説させて実行することで問題発生を抑止できる。
- また、推論エージェントにより実行手順の自動実行まで可能になった。
- これによって、Windows App Development CLI (winapp CLI)などの開発も進んでいる。
※ WindowsもPowerShell?を強化しており、シェル・スクリプトでの本格的な構築が可能になっている。
WSL2を用いたコンテナ開発 †
冪等性の罠 †
WSL2のコンテナ起動停止まわりは特に「叩いてみないと分からない」要素が複合した、典型的な試行錯誤ゾーン。
- 「Windows側から見たプロセス状態」と「Linux側の実際の状態」の食い違いでリトライ・ポーリングが必要になりがち。
- WSL2内のsystemdが有効かどうかで挙動が変わる（/etc/wsl.conf の [boot]セクション に systemd=true と書く）
- WSL2の2つのネットワークモード(NAT/mirrored)の初期化タイミングの差異で同様にリトライ・ポーリングが必要になりがち。
- 起動直後は見えているのに数秒後に見えなくなる、みたいな非決定性（継続的に状態が安定していることを複数回確認する必要がある）
Desktopナシ †
- WSL2からDockerを利用できるようになったが、BATで気軽に実行できなくなった。PowerShell?で実装すればWSL2に入らず実行できる。
- コーディング・エージェントで、トラブルシュートしながらPowerShell?を記述している所を観測したが人手では難しそうだった。
- コーディング・エージェントによって得たナレッジを明文化しておけば、人手での対応でも再現可能な可能性はある。
- しかし、実際は人手での実装は困難と言う結論（コレだけのために、専門職をアサインする必要があるレベル感）。
Desktopアリ †
- OSSの、Rancher Desktopや、Podman Desktopの登場により、再び、Windows上からDockerコマンドを実行することが出来るようになった。
- Desktopのブラック・ボックス問題（トリプル・レイヤー・ネットワークなど）も顕在化しているがエージェントで対応はできそう。
どちら？ †
生成AIはRancher Desktopような実績のあるOSSツールを会社として検証・標準化するのがコスパが良いと提案。
PaaS、CaaSのIaC †
...
OAuth2/OIDCアーキテクチャ開発 †
コチラは環境構築の手数が多いのでDockerなど、コンテナを使用して負荷軽減するのだが、そもそもコンテナ自体が難しいと言う...
CI/CDパイプラインの構築 †
...
参考 †
...
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
