ステップ1は、**「LLM APIを使って、小さい業務ツールを3つ作る」**に絞ります。
ここでの目的は、生成AIの理論理解ではなく、仕事で使えるAI機能を自分で実装できる状態になることです。
ステップ1のゴール
まず1〜2週間で、以下の3つを作ってください。
| No | 作るもの | 学ぶこと |
|---|---|---|
| 1 | 問い合わせ分類ツール | プロンプト、JSON出力、分類 |
| 2 | 議事録要約ツール | 要約、アクション抽出、業務文書処理 |
| 3 | 設計書レビュー補助ツール | レビュー観点、指摘生成、実務応用 |
この3つを作ると、SEとして必要な基礎がかなり身につきます。
まず使う技術
最初はこれで十分です。
推奨構成
| 項目 | 推奨 |
|---|---|
| 言語 | Python |
| API | OpenAI API |
| 実行環境 | ローカルPC |
| エディタ | VS Code |
| パッケージ管理 | venv または uv |
| 入出力 | 最初はCLI、後でStreamlit |
| 保存 | CSV / JSONファイル |
OpenAI APIは、現在の公式ドキュメントでも Responses API が主要なAPIとして案内されています。テキスト生成だけでなく、画像入力、組み込みツール、function callingなどにも対応しています。最初はResponses APIだけ触れば大丈夫です。(OpenAI Developers)
学習教材：買うならこれ
最優先：DeepLearning.AI
ChatGPT Prompt Engineering for Developers
これは最初に受けてよいです。
DeepLearning.AIの短期講座で、OpenAIのIsa Fulford氏とAndrew Ng氏による講座です。LLM APIを使って、要約、推論、変換、拡張、チャットボットなどを作る内容です。(deeplearning.ai)
おすすめ度：★★★★★
理由はシンプルで、あなたのステップ1にかなり直結します。
英語ですが、難しすぎません。プロンプトの考え方とAPI利用の感覚を短時間でつかめます。
日本語で動画学習したい場合：Udemy
Udemyなら、以下の条件で選んでください。
選定条件
- OpenAI APIを使う
- Pythonで実装する
- RAGより前に、まずAPI・プロンプト・JSON出力を扱う
- 更新日が新しい
- LangChainだけに依存しすぎていない
- 最終成果物がある
UdemyにはLangChainやRAGの日本語コースが複数あります。たとえばRAG実装コースでは、社内チャットボットのような用途を想定し、PythonでRAGを実装する内容が紹介されています。(Udemy)
ただし、ステップ1ではRAG講座は少し早いです。まずはOpenAI API単体を触ってからでよいです。
書籍は今すぐ必須ではない
ステップ1に限れば、本よりも公式ドキュメントと動画で十分です。
ただし買うなら、今は基盤本ではなく、次の実装系が合います。
『LangChainとLangGraphによるRAG・AIエージェント［実践］入門』
これはステップ2以降で使う本です。
ステップ1ではまだ不要ですが、RAGやエージェントに進むなら買ってよいです。
公式ドキュメントで見る場所
OpenAIの公式ドキュメントでは、まずこの3つだけ見ればいいです。
1. Quickstart
APIキー作成から最初のAPI呼び出しまで。OpenAI公式のQuickstartは、APIキー作成と最初のAPI呼び出しから始める構成です。(OpenAI Developers)
2. Python SDK
OpenAI公式のPythonライブラリでは、Responses APIが主要なAPIとして説明されています。Pythonで始めるならここを見ます。(OpenAI Developers)
3. Structured Outputs
業務システム連携ではここが重要です。Structured Outputsは、指定したJSON Schemaに従った出力を得るための機能です。公式ドキュメントでも、モデル出力をJSON Schemaに準拠させるための機能として説明されています。(OpenAI Developers)
1〜2週間の具体的スケジュール
Day 1：環境構築
やることはこれだけです。
mkdir genai-step1
cd genai-step1
python -m venv .venv
source .venv/bin/activate # Windowsなら .venv\Scripts\activate
pip install openai python-dotenv pydantic
.envファイルを作ります。
OPENAI_API_KEY=あなたのAPIキー
プロジェクト構成はこれで十分です。
genai-step1/
.env
requirements.txt
01_classify_inquiry.py
02_summarize_meeting.py
03_review_design_doc.py
data/
inquiry_samples.txt
meeting_sample.txt
design_doc_sample.txt
outputs/
Day 2〜3：問い合わせ分類ツール
作るもの
顧客や社内からの問い合わせ文を入力すると、以下のようなJSONを返すツールです。
{
"category": "障害報告",
"priority": "high",
"summary": "ログイン時に500エラーが発生している",
"required_action": "障害調査チームにエスカレーション",
"reply_draft": "お問い合わせありがとうございます。現在、ログイン時のエラーについて確認を進めます。"
}
業務での使い道
- 問い合わせ一次分類
- ヘルプデスク支援
- チケット起票の自動補助
- 優先度判定
- 返信文ドラフト作成
最初のサンプル入力
本日10時頃から、管理画面にログインしようとすると500エラーになります。
複数名で同じ事象が発生しており、業務が止まっています。
至急確認をお願いします。
プロンプト方針
ここで学ぶべきことは、曖昧な自然文を、業務システムで扱える構造化データに変換することです。
分類軸は最初から固定します。
category は以下から選ぶ:
- 障害報告
- 操作質問
- 仕様確認
- 改善要望
- 契約・料金
- その他
priority は以下から選ぶ:
- low
- medium
- high
- critical
ここで身につけること
- プロンプト設計
- 分類タスク
- JSON出力
- enum制約
- 業務システム連携の考え方
この課題は実務に直結します。
SEとしては、ここを雑にせず、分類結果をそのままチケット管理システムに渡せる品質を目指してください。
Day 4〜5：議事録要約ツール
作るもの
会議メモを入力すると、以下を抽出します。
{
"meeting_title": "新機能リリース前確認",
"summary": "リリース前の残課題、テスト状況、リリース判断について確認した。",
"decisions": [
"リリース日は5月10日を維持する",
"性能試験の再実施結果を見て最終判断する"
],
"action_items": [
{
"task": "性能試験を再実施する",
"owner": "田中",
"due_date": "2026-05-02"
}
],
"risks": [
"ピーク時のレスポンス劣化が解消していない可能性"
]
}
業務での使い道
- 会議メモの整理
- アクションアイテム抽出
- 課題管理表の下書き
- 上司向け報告作成
- 議事録作成補助
サンプル入力
新機能リリース前の確認会を実施。
リリース日は5月10日の予定で変えない方針。
ただし、性能試験でピーク時レスポンスが遅いという指摘があり、田中さんが5月2日までに再試験する。
佐藤さんはユーザー向けFAQを5月7日までに更新。
最終判断は5月8日の定例で行う。
ここで大事なこと
単なる要約ではなく、業務で使える単位に分解することです。
特に抽出すべき項目は、
- 決定事項
- TODO
- 担当者
- 期限
- リスク
- 未決事項
です。
ここで身につけること
- 要約
- 情報抽出
- 日付抽出
- 担当者抽出
- 業務ドキュメント整形
このツールはすぐ仕事に使えます。会議後にメモを貼り付けて、課題管理表やTeams投稿の下書きにできます。
Day 6〜7：設計書レビュー補助ツール
作るもの
設計書の一部を入力すると、レビュー観点ごとに指摘を返すツールです。
{
"overall_assessment": "基本方針は妥当だが、異常系と権限制御の記載が不足している。",
"findings": [
{
"severity": "high",
"category": "セキュリティ",
"point": "管理者権限が必要な操作の認可チェック仕様が記載されていない。",
"suggestion": "API単位で必要権限を明記し、権限不足時のHTTPステータスとエラーメッセージを定義する。"
},
{
"severity": "medium",
"category": "異常系",
"point": "外部APIタイムアウト時の挙動が不明。",
"suggestion": "タイムアウト秒数、リトライ回数、ユーザー表示メッセージを追記する。"
}
],
"missing_sections": [
"認可仕様",
"外部API障害時の挙動",
"ログ出力方針"
]
}
レビュー観点
最初はこの観点で固定してください。
レビュー観点:
- 要件充足性
- 異常系
- セキュリティ
- 権限制御
- データ整合性
- ログ出力
- 運用保守
- 性能
- テスト容易性
サンプル入力
ユーザーは管理画面から商品情報を登録できる。
商品名、価格、在庫数を入力し、登録ボタンを押すと商品マスタに保存する。
登録完了後は一覧画面に戻る。
価格は0円以上とする。
想定されるAI指摘
- 権限チェックが書かれていない
- 入力値の桁数上限がない
- 商品名の重複可否が不明
- DB保存失敗時の挙動が不明
- 操作ログの記載がない
- テスト観点が不足
ここで身につけること
- レビュー観点のプロンプト化
- 指摘の構造化
- severity判定
- 業務ノウハウのAI化
- AI出力をレビュー補助として使う感覚
これはSEにかなり向いています。
実務では、AIに「正解」を出させるというより、レビューの抜け漏れを減らす副操縦士として使うのが現実的です。
Day 8〜10：3つのツールを共通化する
ここから少しSEらしくします。
共通処理を作る
llm_client.py
に以下をまとめます。
- API呼び出し
- モデル名
- エラー処理
- リトライ
- ログ出力
- トークン使用量の記録
- JSONパース
ログに残す項目
最低限これを保存してください。
{
"timestamp": "2026-04-29T18:00:00+09:00",
"tool_name": "inquiry_classifier",
"input_chars": 120,
"output_json": {},
"model": "使用モデル名",
"status": "success",
"error": null
}
ここで身につけること
- AI機能の共通部品化
- エラー処理
- ログ設計
- 運用を意識した実装
仕事で使うなら、プロンプトよりログの方が大事です。
後から「なぜこの判断をしたのか」「どの入力で失敗したのか」を追えるようにしておく必要があります。
Day 11〜14：簡易UIをつける
CLIだけでもよいですが、仕事で見せるならUIがあると強いです。
最初は Streamlit で十分です。
pip install streamlit
作る画面はシンプルでいいです。
app.py
機能：
- タブ1：問い合わせ分類
- タブ2：議事録要約
- タブ3：設計書レビュー
- テキスト入力欄
- 実行ボタン
- JSON結果表示
- Markdown表示
- 結果ダウンロード
この状態まで作ると、社内デモできます。
最初の到達基準
ステップ1が完了したと言える基準はこれです。
必須
- OpenAI APIをPythonから呼べる
- 入力文に対してJSON形式で出力できる
- 3種類の業務ツールが動く
- エラー時に落ちずにメッセージを返せる
- 結果をJSONファイルに保存できる
- 同じ入力で大きくブレないようにできる
できれば
- Streamlitで簡易UIがある
- ログを保存している
- サンプル入力を10件以上用意している
- 出力の良し悪しを手で評価している
- プロンプトを別ファイル管理している
評価用サンプルを作る
ここは重要です。
AIツールは「動いた」で満足すると危険です。
各ツールに対して、最低10件のテストデータを作ってください。
問い合わせ分類
例：
| No | 入力 | 期待カテゴリ | 期待優先度 |
|---|---|---|---|
| 1 | ログインできない、業務停止 | 障害報告 | high |
| 2 | パスワード変更方法を知りたい | 操作質問 | low |
| 3 | CSV出力項目を追加したい | 改善要望 | medium |
| 4 | 請求金額について確認したい | 契約・料金 | medium |
議事録要約
見るポイント：
- 決定事項を拾えているか
- TODOを拾えているか
- 担当者が正しいか
- 期限が正しいか
- リスクを過剰に作っていないか
設計書レビュー
見るポイント：
- 重要な不足を指摘できているか
- どうでもいい指摘が多すぎないか
- severityが妥当か
- 改善案が具体的か
- 断定しすぎていないか
プロンプトの作り方
最初はこの型で十分です。
あなたは業務システム開発に詳しいシステムエンジニアです。
以下の入力を分析してください。
目的:
...
出力条件:
- 必ずJSONで出力する
- 不明な項目は null にする
- 推測で断定しない
- 選択肢がある項目は指定されたenumから選ぶ
入力:
"""
{input_text}
"""
重要なのは、役割・目的・制約・出力形式・入力を分けることです。
モデル選定
最初は高性能モデルで品質を確認し、その後に軽量モデルでコストを下げるのがいいです。
学習・検証時
- 高性能モデルを使う
- 出力品質を見る
- プロンプトを固める
実運用想定
- 軽量モデルも試す
- 分類や抽出は安いモデルに寄せる
- レビューや複雑な判断は高性能モデルを使う
OpenAI APIの価格はモデルや入出力トークン数によって変わります。公式価格ページで最新価格を確認しながら使うのが安全です。(OpenAI)
投資額の目安
ステップ1なら、投資はこのくらいで十分です。
| 項目 | 目安 |
|---|---|
| OpenAI API利用料 | 数百円〜数千円 |
| DeepLearning.AI | 無料または低コストの短期講座中心 |
| Udemy | セール時 1,500〜3,000円程度 |
| 書籍 | 今は必須ではない |
| 合計 | まずは 5,000円以内でも十分 |
ただし、あなたが「仕事で使えるようになるための投資は惜しまない」なら、私は以下をおすすめします。
投資優先順位
- OpenAI API利用料
- DeepLearning.AIの短期講座
- UdemyのOpenAI API / LangChain講座
- ステップ2用にRAG・LangGraph本
- Azure環境が必要ならMicrosoft Learn + Azure検証環境
最初から高いスクールに行く必要はありません。
SEなら、教材よりも自分で業務ツールを作る時間に投資した方が伸びます。
ステップ1で作るべき成果物一覧
最終的に、この状態を目指してください。
genai-step1/
app.py
llm_client.py
tools/
inquiry_classifier.py
meeting_summarizer.py
design_reviewer.py
prompts/
inquiry_classifier.md
meeting_summarizer.md
design_reviewer.md
data/
inquiry_samples.jsonl
meeting_samples.jsonl
design_doc_samples.jsonl
outputs/
logs.jsonl
results/
README.md
READMEには以下を書きます。
# 生成AI業務ツール PoC
## 概要
OpenAI APIを使って、問い合わせ分類、議事録要約、設計書レビューを行う。
## 機能
- 問い合わせ分類
- 議事録要約
- 設計書レビュー
## 使用技術
- Python
- OpenAI API
- Streamlit
- Pydantic
## 実行方法
...
## 今後の改善
- RAG対応
- Teams連携
- チケット管理システム連携
- 評価データセット追加
ここまでできると、単なる勉強ではなく、社内PoCの原型になります。
仕事で使うために必ず意識すること
1. 個人情報・機密情報を入れない
最初の学習段階では、実データをそのまま入れないでください。
必ずダミーデータか、匿名化したデータを使ってください。
2. AIの出力を確定情報として扱わない
特に設計書レビューでは、AIは補助です。
最終判断は人間が行う前提にします。
3. ログを残す
業務利用では、失敗時に原因を追えることが重要です。
4. JSON出力を徹底する
システム連携では自然文よりJSONです。
Structured Outputsを使うと、JSON Schemaに沿った出力を得やすくなります。(OpenAI Developers)
5. Function Callingは次の段階でよい
外部APIやDBと連携する段階ではFunction Callingが重要です。OpenAI公式では、Function Callingはモデルが外部システムやアプリケーション側のデータ・処理にアクセスするための仕組みとして説明されています。(OpenAI Developers)
ただし、ステップ1ではまずJSON出力までで十分です。
あなた向けの具体的な開始手順
まず今日やることはこれです。
今日やること
- OpenAI APIキーを作る
- Python環境を作る
- Quickstartを1回動かす
- 問い合わせ分類ツールを1ファイルで作る
- サンプル問い合わせを5件流す
- JSON結果を保存する
明日やること
- Structured Outputsを試す
- category / priority のenumを固定する
- 期待結果とAI結果を比較する
- プロンプトを改善する
週末までにやること
- 問い合わせ分類
- 議事録要約
- 設計書レビュー
この3つをCLIで動かす。
2週間以内にやること
- 共通部品化
- ログ保存
- Streamlit UI
- README作成
- 社内PoC風にまとめる
ここまでできたらステップ2へ
ステップ1が終わったら、次は RAG です。
ただし、RAGに行く前に以下ができていないなら、まだ進まない方がいいです。
- API呼び出しが自力で書ける
- JSON出力を安定させられる
- プロンプトを改善できる
- エラー時の挙動を設計できる
- 出力品質を評価できる
ここができてからRAGに行くと、かなり吸収が早いです。
結論
ステップ1では、これを作ってください。
- 問い合わせ分類ツール
- 議事録要約ツール
- 設計書レビュー補助ツール
教材は、
- OpenAI API公式Quickstart
- Structured Outputs公式ドキュメント
- DeepLearning.AI「ChatGPT Prompt Engineering for Developers」
- 必要なら UdemyのOpenAI API / LangChain系講座
この順で十分です。
あなたの場合、理論書を読むより、実務で見覚えのある文章をAIに処理させるミニアプリを作る方が明らかに向いています。まずは問い合わせ分類ツールから作るのが一番いいです。