Microsoft LLM ワークショップへ参加したので、その時の学びを記録する。
1. 理解重視のエンジニアへ
-
「動いたら終わり」ではなく、挙動と構造を理解するエンジニアになる必要がある。
- サンプルコードを動かすだけでなく、ドキュメントを読み、動作原理・設計意図を理解することが重要。
- LLM活用も同様で、動作したあとに挙動を理解する姿勢が求められる。
-
ブログ記事や古い教材の信頼性は低下している。
- LLM登場以降、情報更新が早く、古い記事はライブラリや依存関係が動作しない場合が多い。
-
新しいツール（例：Azureリソース）を積極的に触ることで理解が深まる。
2. AI駆動開発
ワークショップでは、以下のシステム設計〜実装の一連の流れを、AIで一気にやるデモがあった。
開発ステップ
-
課題設定
- 成功事例・失敗事例を整理し、課題を具体化する。
-
アクター定義とユースケース設計
- 例：「この課題に対してどんなユーザーがどう使うか」
- AIに「課題からユーザーストーリーを抽出してください」と依頼。
-
要件定義・機能要件
-
非機能要件
-
アーキテクチャ設計（Mermaid記法などで図示）
-
データモデル設計（ER図）
-
画面遷移図
- ※「データフロー図」と「画面遷移図」があれば、他の設計は柔軟に補える。
-
サンプルデータ作成
- SQL／NoSQLいずれでも可。挿入手順書も生成可能。
実装フェーズ
- DB作成 → データ挿入文生成
- Vue.js3 で画面構築
- 環境構築手順書の作成
- ダミーデータでUI動作確認
- Azure FunctionでAPI実装（DB連携前）
- 画面とAPIの連携
- APIとDBを統合
- レポート出力用クエリの作成
- Azureリソース選定支援
- デプロイ手順の生成と自動化
AIに「設計書」「手順書」まで作成させることがポイント。
3. 会話型開発のすすめ
- 全自動化よりも、会話を重ねながら進める開発が望ましい。
- 毎回エージェントをリセットせず、継続的な会話（＝RAG的な利用）でコンテキストを保持する。
- LLMはステートレスのため、入力トークンが多いとコスト・精度ともに悪化する。
→ 対話を分割し、小さく繰り返すやり方が効率的。
4. LLMアプリに組み込むロードマップ
5. モデルと開発アプローチの知見
モデル理解
- reasoning（推論）モデルの進化により、
「例示」「手順」を細かく書かなくても、ゴールとタスクを明示するだけで動作するようになっている。 - シンプルなプロンプト設計が今後主流になる？
開発の考え方
- コード修正より新規作成の方が早いケースも出てくる。
→ 既存コードの資産価値は下がる傾向。 -
論理モデル（概念設計）を中心に管理し、
DB種別やUIは後から最適化できるように疎結合で設計。
6. ドキュメント化のポイント
- Markdown形式で成果物を残し、リポジトリの
docsフォルダ等に格納。 - 会議・メール・議事録が企画や要件の出発点となるので、重要な情報。
7. キャリア・役割の考え方
-
プロジェクトマネージャー（PM）：進行管理中心。
-
プロダクトマネージャー（PdM）：価値・収益を設計し、事業とつなぐ役割。
→ エンジニアとPdMの協会がなくなっていく -
仕様を作れる力が重要。企画・要件定義を主導できる人材が求められている。
-
技術者もIR（投資家向け資料）を読めるレベルの事業理解が必要。
→「何が収益を生み出しているか」を把握し、提案できるエンジニアへ。
まとめ
-
理解を起点にする
- サンプルを動かして終わりではなく、挙動・設計意図・依存関係まで把握する。LLM活用も「動いた後に理解」で精度と再現性を高める。
-
会話型で小さく回す
- 全自動化に拘らず、RAG 的にコンテキストを保ちながら短い対話で分割・反復。トークン・コスト・精度を最適化する。
-
設計の型を先に固める
- 課題→アクター/ユースケース→機能/非機能→アーキ→ER/画面遷移→サンプルデータの順で進め、AIには設計書・手順書まで生成させる。
-
論理モデル中心
- DB 種別・UI・実装は後で差し替え可能にし、論理（概念）モデルを資産化。既存コードの改修より新規の方が速い場面も想定する。
-
ドキュメントはテキスト基盤
- Markdown を基本に
docs/に集約。会議・メール・議事録を出発点に要件化し、更新しやすい形式で残す。
- Markdown を基本に
-
役割のシフト
- PM（進行）だけでなく、PdM（価値/収益）視点を取り込み、仕様を作る力を強化。IR を読み、事業の収益ドライバーを理解して提案できる状態へ。