-
Notifications
You must be signed in to change notification settings - Fork 0
DNET_GenAISystemDevelopment
-
戻る
- 生成AIを活用したプログラミング
- 生成AIを活用したシステム開発（本ページ）
- 生成AIを活用した設計書のブレークダウン
プログラミングがメインだが、システム開発のスコープにも適用可能。
- AzureのCaaS（AzureのPaaSの該当節を参照）
GitHub Actions
Azure Pipelines とか Azure DevOps とか。
コチラは開発ツールとして使用するのではなく、ランタイム的に組み込む話。
- UI生成：ユーザーの入力やコンテキストに応じて、LLMがその場でUI生成。固定のフォームではなく「今必要な入力項目」を都度組み立てる。
- パーソナライズ：通知メッセージ、ダッシュボードの見せ方、エラーメッセージなどをユーザー属性に応じてランタイムで生成し出し分ける。
- チャットボットの主インターフェース化：従来のGUI操作の代わりに、対話がそのままバックエンド操作のトリガーになる。
- オンデマンド翻訳/ローカライズ：表示のたびにその場で翻訳・要約するランタイム処理。
データI/O系に適用する。
- 入力：入力補正・正規化：住所や氏名などの表記ゆれを、LLMがランタイムで正規化してから保存する。
- 入出力：ETL/マッピングの動的推論：連携先のスキーマが変わった際に、マッピングルールをLLMがその都度推測して変換する。
- 出力：自然言語→SQL/API変換: ユーザーの自然言語問い合わせをその場でクエリに変換して実行。スキーマ変更にも比較的柔軟に追従できる。
データ変更に適用する。
- データストアを変更すると、UIにリニアに反映が掛かる仕組みなどは面白い（オートメーションにも見える）。
- 処理要求を一度、データストアに登録し、コレを非同期に実行する仕組みにしておけば、AIによる処理要求が可能になる。
- ルール・エンジンの代替：承認フローや条件分岐など、ハードコードしていた業務ルールをLLMが自然言語の方針から都度判断。
- イベント・トリアージ：ログやイベントストリームをLLMがリアルタイムに解釈し、優先度判定やアラートの要否を決める。
- エラー・ハンドリング/自己修復：実行時エラーをLLMが解析し、リトライ方法の変更や簡単な自動パッチを提案・適用。
- 動的オーケストレーション：複数APIのレスポンスをLLMが解釈し、次にどのAPIを呼ぶかをエージェント的に決定。
既に「この辺（LLMのFTの該当節を参照）」で多用。
シェル・スクリプトを作成する。
シェル・スクリプトの実行結果を読み取る。
Dockerfile、DockerComposeを書いて実行できる。
- Docker Desktopが無くてもPowerShellで記述してWSL2に入らずDockerコマンドを実行できる。
- ただし、Desktop系プロダクトを活用した方が、PowerShell依存を軽減できるため保守性は良くなる。
開発環境向けのコンテナ・オーケストレーション。
稼働環境向けのコンテナ・オーケストレーション。
IdP、ResourceServerをコンテナ化
開発環境向けのコンテナ・オーケストレーション。
稼働向けのコンテナ・オーケストレーション。
Chef、Ansible、Puppetのような構成管理・インフラ自動化(パッケージ導入、設定ファイル配布、サービス管理、権限設定など)は、
- 環境の状態に強く依存する(冪等性の罠)：「今の状態」に応じて挙動が変わることが前提。まっさらな環境では動いても、そうではない環境では失敗する。
- 対象環境を事前に完全に把握できない：どのディストリか、どのパッケージマネージャか、SELinuxが有効か、既存の設定ファイルに何が書いてあるか。
- 副作用を持つ操作が多い：ファイル書き換え、サービス再起動、パッケージインストールなど「実行してみないと結果が分からない」操作の比率が通常のアプリコードより高い。
- エラーメッセージの抽象度が低い：「Permission denied」「Package not found」のようなエラーが、実際の原因を直接教えてくれないことが多く、原因特定に一往復必要になりがち。
などの、問題のあるタスクに対応するツールだったが、推論エージェント（コーディング・エージェント）（推論エージェントの該当節を参照）は自然言語定義でこれらを実施できる。
エージェントは失敗コストがほぼゼロに近いので進出後、人手に戻れない。
- 自分でコマンドを叩いて失敗すると、原因調査・ログ確認・再実行という一連の作業を全部自分の時間でやる必要がある。
- エージェントはコマンド実行 → 結果確認 → 修正のサイクルをコンテキスト・スイッチなし即座に回せる。
- 原因は不明のケースでも「事例を検索しｎパターン試して当たりを引く」と言う試行を力技でやってくれる。
- WSL(2)の登場で非常に敷居が下った。敷居が下った結果、ピンキリだが難しくはないという印象。
- むしろ、CUIのため、コピペで手順を再現できるため、エンジニア向けではあるという印象。
- 深い点は難易度が高い。ただし、インターネット上に情報はあるので対応は可能な印象。
- CUIは「Character」UIなのでLLMとの親和性が高い。
- GUIと比べると、実行手順の提示や実行結果の提示に有利。
- ネットで得た手順をLLMに解説させて実行することで問題発生を抑止できる。
- また、推論エージェントにより実行手順の自動実行まで可能になった。
- これによって、Windows App Development CLI (winapp CLI)などの開発も進んでいる。
※ WindowsもPowerShellを強化しており、シェル・スクリプトでの本格的な構築が可能になっている。
WSL2のコンテナ起動停止まわりは特に「叩いてみないと分からない」要素が複合した、典型的な試行錯誤ゾーン。
- 「Windows側から見たプロセス状態」と「Linux側の実際の状態」の食い違いでリトライ・ポーリングが必要になりがち。
- WSL2内のsystemdが有効かどうかで挙動が変わる（/etc/wsl.conf の [boot]セクション に systemd=true と書く）
- WSL2の2つのネットワークモード(NAT/mirrored)の初期化タイミングの差異で同様にリトライ・ポーリングが必要になりがち。
- 起動直後は見えているのに数秒後に見えなくなる、みたいな非決定性（継続的に状態が安定していることを複数回確認する必要がある）
-
Docker Desktop有償化で企業内利用が廃れたのが普及の足枷としては大きかった。
-
WSL2からDockerを利用できるようになったが、BATで気軽に実行できなくなった。PowerShellで実装すればWSL2に入らず実行できる。
- コーディング・エージェントで、トラブルシュートしながらPowerShellを記述している所を観測したが人手では難しそうだった。
- コーディング・エージェントによって得たナレッジを明文化しておけば、人手での対応でも再現可能な可能性はある。
- しかし、実際は人手での実装は困難と言う結論（コレだけのために、専門職をアサインする必要があるレベル感）。
- OSSの、Rancher Desktopや、Podman Desktopの登場により、再び、Windows上からDockerコマンドを実行することが出来るようになった。
- Desktopのブラック・ボックス問題（トリプル・レイヤー・ネットワークなど）も顕在化しているがエージェントで対応はできそう。
生成AIはRancher Desktopような実績のあるOSSツールを会社として検証・標準化するのがコスパが良いと提案。
...
コチラは環境構築の手数が多いのでDockerなど、コンテナを使用して負荷軽減するのだが、そもそもコンテナ自体が難しいと言う...
- ...
...
...
移行メモ
- 「戻る」の並びにある自ページは、その旨を補ってプレーン・テキストとした。
- 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
- PukiWiki のページ内アンカ（
#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名の該当節を参照）」の形に置き換えた。- 元 Wiki の行頭空白によるプレフォーマット・ブロックは、 フェンス付きコードブロックにした。
- 同名の見出し（「CI/CDパイプラインの構築」「Linux構築」 「OAuth2/OIDCアーキテクチャ開発」「PaaS、CaaSのIaC」「稼働環境」「開発環境」）が 複数あり GitHub Wiki でアンカが衝突するため、括弧で文脈を補って一意にした。
Tags: 移行, 生成AI, システム開発, IaC, CI/CD, Linux構築, OAuth2/OIDC, LLM
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。