0.3 AI フルスタック能力マップ

まず図を見ます。コースは1本のエンジニアリングの道です。
今は細部を全部理解しなくて大丈夫です。
| 詰まっていること | 戻る場所 |
|---|---|
| コードが動かない | ツールと Python |
| 入力が乱れている | データ |
| 答えが信頼できない | 評価と RAG |
| 行動が制御できない | Agent trace と権限 |
| 層 | 対応章 | 最初に見える証拠 | 深い問い |
|---|---|---|---|
| ツール | 1 | 再現可能なプロジェクトフォルダと Git 履歴 | 他の人が再実行できるか |
| Python | 2 | 入力と出力が明確な小さなスクリプト | 読みやすく、型があり、テストできるか |
| データ | 3 | 整った表、グラフ、メモ | どこに誤りやバイアスがあるか分かるか |
| モデル | 4-6 | 学習または点検したモデル実験 | どの指標が判断を変えるか |
| LLM | 7 | prompt、tokens、embeddings、Transformer の直感 | 振る舞いは data、decoding、context のどこから来るか |
| RAG | 8 | 検索トレースと回答評価 | 答えは正しい根拠を使ったか |
| Agent | 9 | ツールトレース、権限、記憶境界、デプロイメモ | ユーザー、ファイル、操作が本物になったらどこで失敗するか |
| 専門分野 / ランタイム成果物 | 10-13 と選択モジュール | vision/NLP/マルチモーダル/オープンソース LLM デモ、書き出した成果物、デプロイメモ | ドメイン制約とランタイム制約がプロダクト判断をどう変えるか |
この講座はトピックの山ではなく、デバッグの積み重ねであり、ポートフォリオの積み重ねでもあります。AI アプリケーションの挙動が悪いとき、原因は見ている機能より何層も下にあることがあります。レビューする人に何を作ったか聞かれたとき、証拠はどの層を制御したかを示す必要があります。
1つのプロジェクト軸で多層を積む
Section titled “1つのプロジェクト軸で多層を積む”キャリア転換に強い project は、小さな assistant や automation から始め、章ごとに信頼性を増やせます。
| 層 | ポートフォリオに追加する証拠 |
|---|---|
| ツール | repository、README コマンド、スクリーンショット、整理されたファイル構成 |
| Python | 入力、出力、エラー、テストが見える CLI または script |
| データ | サンプル dataset、クリーニングメモ、グラフ、境界例 |
| モデル | baseline、指標表、比較、失敗サンプル |
| LLM | Prompt variants、structured output、token/cost メモ、限界 |
| RAG | documents、chunks、retrieval trace、citation check、answer evaluation |
| Agent | tool permission boundary、action trace、memory rule、rollback note |
| 専門分野 / ランタイム成果物 | vision、NLP、multimodal、オープンソース LLM ランタイム、deployment、またはプロダクト固有のレビュー証拠 |
メインラインと拡張トラック
Section titled “メインラインと拡張トラック”まず第1-9章を標準のメインラインとして進めます。第9章まで終えると、小さな LLM/RAG/Agent プロジェクトを、根拠、ログ、安全境界つきで作れる状態を目指します。
その後、第10-13章はプロダクト上の必要に合わせて選びます。
| 必要なこと | 選ぶ章 | 理由 |
|---|---|---|
| 画像、カメラ、OCR、検出、セグメンテーション | 第10章 Computer Vision | 出力がラベル、枠、マスク、文字、動画イベントなどの視覚結果になる |
| テキストラベル、抽出、要約、言語評価 | 第11章 NLP | 出力がラベル、フィールド、範囲、生成テキストなどのテキストタスクになる |
| 画像、PDF、音声、動画、クリエイティブ素材、multimodal RAG | 第12章 Multimodal/AIGC | モダリティが混ざり、出典、プロンプト、レビュー、書き出し記録が必要になる |
| オープンソースモデルのホスティング、私有化配置、ランタイム所有 | 第13章 Open-Source LLM Deployment | model files、serving API、license、cost、fine-tuning 判断をプロジェクト側で制御する必要がある |
| デプロイ、Python 上級、古典的 ML の深掘り | 選択モジュール | メインプロジェクトに特定のエンジニアリングまたはアルゴリズムの補助スキルが必要になる |
マップの使い方
Section titled “マップの使い方”プロジェクトを始める前に、最も危険な層を1つ印づけます。たとえば PDF 質問応答アプリは、チャット UI ではなくデータ整備と検索で先に失敗しがちです。自動化 Agent は、プロンプトの言い回しではなくツール権限、状態、評価で先に失敗しがちです。
各章では、その層が動くことを証明する成果物を1つ残します。スクリーンショットも役に立ちますが、ログ、README コマンド、小さなデータセット、指標表、失敗メモのほうが、後でデバッグしやすい証拠になります。
任意の背景:これらの能力がどのように発展してきたかを知りたい場合は、AI 発展史 15 段階マップを軽く見てください。
次に、メインルートをどう進めるか計画します。
この map は、現在の layer、次に一番 risk が高い layer、進捗を証明する portfolio artifact を 1 つ言えれば合格です。
このページを終えたら、この証拠カードを残します。
- 機能マップ
- tools、Python、data、math、ML、DL、LLM、RAG、Agent、専門分野、ランタイムの関連付け
- プロジェクト軸
- assistant、automation、analysis、または multimodal project の案を1つ
- 現在位置
- すでに分かっていることと、後回しにすること
- 次の行動
- 次に始める具体的な章かワークショップを1つ
- リスク確認
- 何でも一度に学び、証拠を飛ばし、または中核ルートを見失うこと
- 期待される成果
- プロジェクト軸と1つの即時行動が書かれた、印付きの個人コースマップ