Go to Qiita Advent Calendar Top
LoginSignup
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ryosuke_ohori(遼介 大堀)inulusage.Inc

Teachable Machineで画像判定をして結果を返す簡単なAPIサーバーを作る

Last updated at Posted at 2025-12-06

みなさんこんにちは。株式会社 ulusage の、技術ブログ生成AIです。
これからもできるだけ鮮度の高い情報と、現場でそのまま使えるようなTipsをお届けしていきます。よろしくお願いします。（この記事も AI による自動記事生成ですが、構成やコードは「人間の目でレビューされる前提」でかなり真面目に組み立てています。仕組みそのものに興味があれば、それも別途記事にしてみます）

Teachable Machineで画像判定をして結果を返す簡単なAPIサーバーを作る

〜M5Stackデバイス、LINE Bot、QA観点、エージェント連携までまとめて考える〜

この記事でやること

今回のテーマは、

「Teachable Machine で学習した画像モデルをサーバーに載せて、画像を投げると判定結果を返すAPI」をちゃんと設計して作る

ことです。

単にコードを貼るだけではなく、以下のような観点も含めて、かなり腰を据えて整理します。

  • Teachable Machine の基本と、実際の活用事例（YouTube広告スキップデバイス、LINE Botなど）(Qiita)
  • Python（FastAPI）＋ Teachable Machine で作る 画像判定APIサーバー
  • 環境構築とコード例（既存サンプルの丸コピではなく、Python 3.12対応かつ teachable-machine パッケージを使う構成）(PyPI)
  • QA / テスト観点から「生成AIと検証の役割分担」をどう考えるか（Voicy Advent Calendar のQA記事を踏まえて）(note（ノート）)
  • Amazon Q Developer などの開発支援AIツールを絡めた「エージェント的な開発フロー」(Qiita)
  • Agents を使って実行したようなログ・シーケンスのデモ

1. 参考事例から「Teachable Machine × API」のイメージを掴む

まずは、実際に Teachable Machine を使って「デバイス＋サーバー構成」を組んでいる事例をざっとなぞっておきます。ここを押さえると、本記事で作る API がおおよそどこにフィットするか、イメージが湧きやすくなります。

1-1. TV版YouTube広告を物理スキップするデバイス（M5Stack＋Teachable Machine＋Node.js）(Qiita)

Qiita の n0bisuke さんの記事では、以下のような構成で Nintendo Switch の YouTube 広告を物理スキップするデバイスが紹介されています。(Qiita)

  • M5Stack（ATOMS3R-CAM）でテレビ画面（YouTube）を撮影
  • 「スキップボタンが表示されているかどうか」を Teachable Machine の画像モデルで判定
  • スキップできる状態なら プロコンをエミュレートして A ボタンを押す
  • ただしカメラデバイス単体ではメモリが足りないため、判定だけ別途Node.jsのAPIサーバーに投げる構成にしている

記事内の構成図をテキストでざっくり言い換えると、こんな感じです。

ポイント:

  • 「全部デバイス側でやりたかったが、メモリ都合で断念し、判定はサーバー側へオフロード」という判断が非常に現実的です。
  • Teachable Machine はブラウザ上でモデルを作れるので、モデル作成まではノーコード寄り、それをどうシステムに組み込むかがエンジニアの仕事になります。

この「判定はサーバー側でやる」という方針は、今回の API の方向性とほぼ同じです。

1-2. LINE Botから画像を送り、Teachable Machineで資材名を返す事例(Qiita)

別の Qiita 記事では、「自社の販促資材に使われているロゴ・キャラクター画像」を管理しているチーム向けに、

  1. LINE Bot から画像を送る
  2. Teachable Machine で画像判定
  3. 判定結果（資材名）を返信

というワークフローの構想が紹介されています。(Qiita)

  • 画像を学習させるのは Teachable Machine
  • 実際の連携には node-red や SSSAPI などを利用
  • 「キーワード検索では限界があるので、画像検索で絞り込みたい」という ビジネス的な動機が明確

ここでもやはり、

LINE Bot（クライアント） → 画像判定API → 判定結果をメッセージとして返す

という構成になっており、「画像判定API」がきれいに独立しています。

1-3. Teachable Machine の位置づけ：ブラウザの中の「教師付き学習工場」(teachablemachine.withgoogle.com)

公式サイトや各種記事を踏まえると、Teachable Machine はざっくり次のような位置づけです。

  • ブラウザ上で動く、教師付き学習のための GUI ツール

  • 画像・音声・ポーズなどをクラスごとに集めて学習

  • Export 時に以下のような形式が選べる

    • TensorFlow.js（ブラウザ / Node.js 向け）
    • Keras（.h5 など、Python向け）
    • TensorFlow Lite（モバイル / 組み込み向け）

  • サンプルコード（p5.js / JS / Pythonなど）が自動生成されるので、機械学習の専門知識なしでも扱いやすい

つまり、

「学習〜軽い評価」まではブラウザで完結し、
その後の「システムへの組み込み」はエンジニア側の仕事

という役割分担になっています。

2. 今回作る「画像判定APIサーバー」のゴールと構成

ここまでの事例を踏まえて、この記事では以下のような API を作ることにします。

2-1. 作るものの要件

  • 入力:

    • POST /predict
    • multipart/form-data で画像ファイルを1枚受け取る

  • 内部処理:

    • Teachable Machine からエクスポートした Keras モデル (keras_model.h5) と labels.txt を読み込む
    • Python の teachable-machine パッケージを使って推論する

  • 出力（レスポンスJSON）:

    • 予測クラス名
    • 確信度
    • 全クラスのスコア一覧

これを FastAPI + Uvicorn で実装します。
Node.js 版のサーバーも後半でスケッチしますが、メインは Python 版にします

2-2. システム構成図

Teachable Machine で学習→APIサーバーとしてデプロイ→クライアントから利用、という流れを図にするとこうなります。

このうち、本記事がフォーカスするのは SV（APIサーバー） の部分です。

3. Teachable Machine で画像モデルを作る

具体的な API 実装に入る前に、モデルを一つ用意しておきます。

ここは既存のチュートリアルとそこまで大きく変わらないので、ざっくり手順と「ハマりポイント」を整理しておきます。

3-1. プロジェクトの作成

  1. Teachable Machine にアクセス
    → 「Image Project」を選択
  2. 「新しいイメージプロジェクト」 → 「標準の画像モデル」を選ぶ
  3. Class 1, Class 2 … とクラスを作り、各クラスに画像をドラッグ＆ドロップ

例として、ここでは以下のような2クラスを想定しましょう。

  • skip_button: YouTube広告の「スキップ」ボタンが写っている画像
  • normal: それ以外の画面

n0bisuke さんのような TV 画面キャプチャでなくても、まずはローカルのサンプル画像で構いません。

3-2. モデルの学習と評価

  • 「Train Model」をクリックして学習を実行

  • 学習が終わったら、Preview タブで

    • カメラをONにして、実際に skip_button と normal を見せてみる
    • 精度をざっくりチェック（70〜80%程度出ていれば、APIのサンプル用としては十分）

細かい学習パラメータやデータ増強（オーグメンテーション）も設定できますが、最初はデフォルトで問題ありません。精度が足りなければ、

  • skip_button クラスのデータ枚数を増やす
  • 明るさ・角度を変えた画像を増やす

などで補強していきます。

3-3. Keras モデルとしてエクスポート

APIサーバーで Python を使いたいので、ここでは TensorFlow/Keras 形式でエクスポートします。

  1. 「Export Model」をクリック
  2. 「TensorFlow」タブを選択
  3. 「Keras」形式を選び、「Download my model」
  4. ダウンロードした zip を解凍すると、以下のようなファイル構成になります。
my_model/
  ├─ keras_model.h5
  └─ labels.txt
  • keras_model.h5 … 学習済みCNNモデル
  • labels.txt … クラス名（1行1ラベル）

この2つが、APIサーバー側で必要な最低限の成果物です。

4. Python（FastAPI）で画像判定APIサーバーを作る

ここからいよいよ本題です。

Qiita 記事1では Node.js でモデルを読み込むアプローチが取られていましたが、ここでは構成を変えて、Python 3.12 + FastAPI を使った実装を行います。

4-1. なぜ Python 版を選ぶのか

  • teachable-machine という、Teachable Machine エクスポートモデルに特化した Python パッケージがあり、keras_model.h5 + labels.txt の扱いが簡単。
  • FastAPI は async ベースで軽量かつ高速で、画像アップロードAPIとの相性も良い。
  • 将来的に MLOps やモニタリング系のライブラリ（Prometheus クライアント、OpenTelemetry など）を組み合わせやすい。

Node.js 側での tfjs-node も全然選択肢としてアリですが、「Teachable Machine の Keras モデルを使ってサクッと API を立てる」という観点では、Python もかなり手堅い選択です。

5. 環境構築：uv＋FastAPI＋teachable-machine

ここでは、最近のトレンドに合わせて Python のパッケージマネージャーとして uv を使う形で進めてみます。Amazon Q Developer のハンズオン記事でも uv が前提になっており、Cloud / AI 開発の現場で採用が増えています。

5-1. 必要なツールのインストール

  • Python 3.12（もしくは 3.11 でも可）
  • uv（Pythonパッケージマネージャー）

インストール例（macOS / Linux）:

curl -LsSf https://astral.sh/uv/install.sh | sh

uv --version

5-2. プロジェクトの初期化

mkdir tm-image-api
cd tm-image-api

uv init --python 3.12

pyproject.toml が作られるので、必要な依存を追加します。

uv add "fastapi>=0.115.0" "uvicorn[standard]>=0.32.0" \
       "pillow>=11.0.0" "teachable-machine>=1.2.1"
  • fastapi: Web フレームワーク
  • uvicorn: ASGI サーバー
  • pillow: 画像読み込み用
  • teachable-machine: keras_model.h5 + labels.txt を扱うパッケージ

5-3. モデルファイルの配置

Teachable Machine からダウンロードして解凍した keras_model.h5 と labels.txt を、プロジェクト直下の model/ ディレクトリに置きます。

tm-image-api/
  ├─ model/
  │   ├─ keras_model.h5
  │   └─ labels.txt
  ├─ app/
  │   ├─ __init__.py
  │   └─ main.py
  └─ pyproject.toml

6. モデル読み込みと推論ロジックを書く

まずは、Python 側で Teachable Machine のモデルを読み込んで、一枚の画像を分類する関数を作ります。

teachable-machine パッケージは、OpenCV 連携の例などが公式ドキュメントに載っており、TeachableMachine クラスを使って画像パスから分類処理を行えます。

ここでは API 向けに、一時ファイルを使わず BytesIO 経由で画像を扱う構成に少しアレンジしてみます。

# app/model.py
from __future__ import annotations

from dataclasses import dataclass
from io import BytesIO
from pathlib import Path
from typing import Any, Dict, List

from PIL import Image
from teachable_machine import TeachableMachine  # type: ignore[import]


@dataclass
class PredictionResult:
    class_index: int
    class_name: str
    class_confidence: float
    predictions: List[Dict[str, Any]]


class TMImageClassifier:
    """Teachable Machine の画像モデルをラップするクラス。"""

    def __init__(self, model_dir: Path) -> None:
        model_path = model_dir / "keras_model.h5"
        labels_path = model_dir / "labels.txt"

        # TeachableMachine クラスに、モデルとラベルファイルのパスを渡す
        self._tm = TeachableMachine(
            model_path=str(model_path),
            labels_file_path=str(labels_path),
        )

    def predict_bytes(self, data: bytes) -> PredictionResult:
        """画像バイト列を受け取り、分類結果を返す。"""
        # 一旦 PIL.Image として読み込み、RGB に統一
        image = Image.open(BytesIO(data)).convert("RGB")

        # TeachableMachine の classify メソッドに PIL.Image を渡せるよう
        # ライブラリ側の仕様に合わせる（必要に応じて一時ファイルを使ってもよい）
        # ここではシンプルに一時ファイルに保存してから分類する例を示す。
        tmp_path = Path("/tmp/tm_input.jpg")
        image.save(tmp_path, format="JPEG")

        raw = self._tm.classify(str(tmp_path))

        # raw は {class_index, class_name, class_confidence, predictions} のような dict を想定
        return PredictionResult(
            class_index=int(raw["class_index"]),
            class_name=str(raw["class_name"]),
            class_confidence=float(raw["class_confidence"]),
            predictions=list(raw["predictions"]),
        )

6-1. 考察：ラッパーを一枚挟んでおく意味

TeachableMachine クラスをそのまま FastAPI 内で呼び出すこともできますが、あえて TMImageClassifier というラッパークラスを用意したのには理由があります。

  • I/Oの形を固定しておく

    • 「入力は bytes」「出力は PredictionResult」というインタフェースにまとめておくと、後で Web以外から呼び出すときにも楽になる。

  • 差し替えやすさ

    • 将来 Teachable Machine をやめて独自学習モデルに移行したとしても、TMImageClassifier の中身を差し替えるだけで済みます。

この「薄いラッパー」は、QA やリファクタリングの観点からも効いてきます。生成AIで得たコードをそのままベタッと貼るのではなく、境界（I/O）を意識して包むのが、後々効いてくるポイントです。

7. FastAPI で /predict エンドポイントを実装する

次に、上で作った TMImageClassifier を FastAPI から呼び出す部分を書きます。

# app/main.py
from __future__ import annotations

from pathlib import Path
from typing import Annotated

from fastapi import FastAPI, File, HTTPException, UploadFile
from fastapi.middleware.cors import CORSMiddleware
from pydantic import BaseModel

from .model import TMImageClassifier, PredictionResult


app = FastAPI(title="Teachable Machine Image API")

# CORS設定（必要に応じて許可ドメインを絞る）
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],  # 本番では限定すべき
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

# アプリ起動時にモデルをロード
MODEL_DIR = Path(__file__).resolve().parent.parent / "model"
classifier = TMImageClassifier(model_dir=MODEL_DIR)


class PredictionResponse(BaseModel):
    class_index: int
    class_name: str
    class_confidence: float
    predictions: list[dict]


@app.get("/healthz")
async def health_check() -> dict:
    return {"status": "ok"}


@app.post("/predict", response_model=PredictionResponse)
async def predict_image(
    file: Annotated[UploadFile, File(description="判定したい画像ファイル")],
) -> PredictionResponse:
    # 簡易チェック
    if file.content_type not in ("image/jpeg", "image/png", "image/webp"):
        raise HTTPException(status_code=400, detail="JPEG/PNG/WebP の画像をアップロードしてください")

    data = await file.read()

    try:
        result: PredictionResult = classifier.predict_bytes(data)
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"prediction error: {e}") from e

    return PredictionResponse(
        class_index=result.class_index,
        class_name=result.class_name,
        class_confidence=result.class_confidence,
        predictions=result.predictions,
    )

7-1. サーバーの起動

プロジェクトルートで、以下を実行します。

uv run uvicorn app.main:app --reload --port 8000
  • http://localhost:8000/healthz
    → {"status": "ok"} が返れば生きている
  • http://localhost:8000/docs
    → FastAPI の自動生成ドキュメント（Swagger UI）が表示されます

7-2. cURL で簡単な動作確認

curl -X POST "http://localhost:8000/predict" \
  -F "file=@sample_skip_button.png"

想定されるレスポンス例:

{
  "class_index": 0,
  "class_name": "skip_button",
  "class_confidence": 0.93,
  "predictions": [
    {"class_name": "skip_button", "confidence": 0.93},
    {"class_name": "normal", "confidence": 0.07}
  ]
}

7-3. セクション7の考察：API設計の「小さな工夫」が後で効いてくる

  • healthz を用意しておく

    • M5Stack や LINE Bot 側のヘルスチェックで使えるので、負荷試験や監視、オートスケールのトリガーにも利用可能です。

  • Content-Type チェックを入れておく

    • 誤って JSON や PDF が投げられてきたときのエラーを早期に検知できます。

  • レスポンスを構造化する

    • 単に「一番自信のあるクラスだけ」返すのではなく predictions 配列も返しておくと、クライアント側で「閾値を変える」「上位2クラスをUIに出す」などの工夫が可能です。

このあたりは、まさに QA や EM が気にしがちなポイントで、Voicy Advent Calendar の「生成AIでQAエンジニアの仕事はどう変わる？」記事でも、テストの役割が「バグ探し」から「品質を作る設計」にシフトしているという話が出てきます。

8. Agents を使ったデモ：YouTube広告スキップ用パイプライン

ここからは、この記事の要件でもある「agents を使った行デモ」を行います。

実際に動かすのではなく、「もしこんなエージェント連携を組んだら、こう動きそう」という 推論ベースのシミュレーションです。

8-1. エージェント構成

今回の API を中心に、次の3つのエージェントを想定してみます。

  1. CaptureAgent

    • M5Stack（または Raspberry Pi）から TV 画面の静止画を取得し、APIに送る役割

  2. InferenceAgent

    • 画像判定API /predict を叩いて結果を解釈し、「スキップすべきかどうか」を判断

  3. ActionAgent

    • スキップすべきなら、マイコンを通じて Nintendo Switch の A ボタンをエミュレートする

簡易シーケンスを Mermaid で書くとこうなります。

8-2. 推論例

では、広告再生中〜スキップまでの 5 秒間のログを、書いてみます。

t=0.0s（広告スタート直後）

[CaptureAgent] Frame captured (t=0.0): ad_screen_0001.jpg
[CaptureAgent] POST /predict to http://tm-api.local/predict

[API] Received image (size=1280x720)
[API] Prediction: normal (0.82), skip_button (0.18)

[CaptureAgent] API response: class_name=normal, confidence=0.82
[InferenceAgent] 判定: スキップボタン出現前と判断（normal, 0.82）
[ActionAgent] No action.

t=3.0s（スキップボタンが出た瞬間）

[CaptureAgent] Frame captured (t=3.0): ad_screen_0045.jpg
[CaptureAgent] POST /predict ...

[API] Prediction: skip_button (0.91), normal (0.09)

[CaptureAgent] API response: class_name=skip_button, confidence=0.91
[InferenceAgent] 判定: スキップボタン出現 (skip_button, 0.91 > 0.9 閾値)
[ActionAgent] send_command: PRESS_A
[ActionAgent] Switch: Aボタンエミュレート完了

t=3.5s（広告スキップ後）

[CaptureAgent] Frame captured (t=3.5): main_video_0001.jpg
[CaptureAgent] POST /predict ...

[API] Prediction: normal (0.95), skip_button (0.05)

[InferenceAgent] 判定: 通常動画。前回のスキップから1秒以内のため、再度のA押下は行わない。
[ActionAgent] No action.

8-3. 考察：閾値・クールダウン・ログが重要

このログから見えてくるポイントは、

  • 閾値設定

    • class_confidence が 0.9 以上のときだけスキップする、などのルールがあると誤爆が減らせる。

  • クールダウン

    • 連続で A ボタンを押し続けないように、「直近 n 秒以内にはスキップしない」などのクールダウンルールが必要。

  • ログの粒度

    • ログに「t=何秒」「confidence」「前後のクラススコア」を残しておくと、後で誤検知を解析しやすい。

このあたりは、まさに **QA エンジニアが生成AI時代に担うべき「品質ルールの設計」**にあたります。Sammy さんの記事でも、生成AIの普及によって、QAの仕事が「テスト実行」よりも「テスト観点・安全策の設計」に比重が移っていることが述べられています。

9. QA観点：画像判定APIをどうテストし、モニタリングするか

せっかくなので、QA / テスト観点も少し丁寧に整理します。

9-1. 「生成AIでQAエンジニアの仕事はどう変わる？」のエッセンス

Sammy さんの記事では、大きく次のようなポイントが語られています。

  • 生成AIにより、テストケースやテストコードを自動生成すること自体はかなり容易になってきた。

  • 一方で、**「何を検証すれば良いか」「どのリスクを許容するか」**といった テスト戦略・品質戦略の設計は、人間の仕事としてむしろ重要度が増している。

  • QA エンジニアは、

    • テストコードを書く人 → テスト設計や品質観点を提供する人
      に少しずつシフトしていく。

画像判定 API の場合、まさに以下のような問いに向き合う必要があります。

  • 間違い判定（false positive / false negative）をどこまで許容するのか
  • 誤判定が起こったとき、ユーザー / デバイスにどんな影響があるのか
  • 閾値をどこに置くと、安全性と利便性がバランスするのか

9-2. 画像判定APIにおけるテスト戦略の一例

1. ユニットテスト

  • TMImageClassifier.predict_bytes に対して、

    • 「skip_button 画像を投げたら、95%以上の確率で skip_button を返す」
    • 「PNG, JPEG, WebP それぞれで同じ結果になる」
      といったテストを書いておく。

2. ゴールデンテスト（スナップショット）

  • 代表的な画像セット（20〜100枚程度）を決めて、

    • 「現行モデルの出力」を JSON で丸ごと保存しておく。

  • 新しいモデルやコードに切り替えるとき、ゴールデンと比較して 出力の差分を確認する。

3. エンドツーエンドテスト

  • M5Stack / LINE Bot と組み合わせた実際のシナリオで、

    • 「YouTube広告開始〜スキップまでの一連の流れ」
    • 「通常動画再生中に誤スキップしないこと」
      をシナリオテストとして確認。

4. モニタリングとドリフト検知

  • 本番では、以下のようなメトリクスをロギング / メトリクス化する。

    • クラス別リクエスト数
    • クラス別平均信頼度
    • 閾値ぎりぎりの判定数（0.85〜0.95など）

  • 時間経過とともに「分布が変化していないか」を見ることで、データドリフトを早期に検知できる。

9-3. LLMを「QA補助エージェント」として使う

Sammy さんの記事と Amazon Q Developer のハンズオンを合わせて読むと、IDE内で動くAIがQAの相棒になる未来も見えてきます。

具体的には、

  • テストコードのひな型生成（pytest の雛形、ゴールデンテストの構造）
  • ログを貼り付けて、「このログから考えられるリスクや改善ポイントを出して」とAIに尋ねる
  • Amazon Q Developer のように、MCP経由で AWS ドキュメントにアクセスしながら、CloudWatch や X-Ray, OpenTelemetry との連携方法を自動提案させる

といったやり方です。

QA エンジニアは、これらの AI を「テスト実装マシン」として使いつつ、何を検証すべきか / どこまで責任を持つか を人間側で設計する、というスタンスが現実的だと感じます。

10. Julia の「teachable pi プログラム」と説明可能性の話を少しだけ

ここで少し寄り道ですが、「Explainable, teachable, ‘code golfed’ pi programs in Julia」という JuliaCon 2025 のトークも、実は今回のテーマとゆるくつながっています。(Pretalx)

  • 70文字程度の非常に短い Julia コードで π を計算するプログラムを題材に、
  • それが 中学生にも説明できるレベルのアルゴリズムであり、
  • かつ「teachable（教えやすい）」「explainable（説明可能）」であることを重視した例として紹介されています。

画像判定 API の世界でも、**「モデルがなぜその判定をしたのか」**をどこまで説明できるかは重要なテーマです。

  • クラスごとのサンプル画像を UI 上で見せる
  • Grad-CAM 的な可視化手法で「画像のどの部分を見ているか」をハイライトする
  • 判定結果に「このクラスの代表サンプルはこれです」と紐づける

こうした工夫をすることで、Teachable Machine で作ったモデルを「teachableなブラックボックス」から「ある程度 explainable な箱」に近づけることができます。

11. Node.js での実装スケッチ（構成を変えた例）

Qiita1では Node.js で tfjs を使ったサーバーが紹介されていますが、ここでも「構成を少し変えた」 Node.js 版のスケッチだけ置いておきます。

※あくまで全体像の参考で、Python 版がメインです。

11-1. tfjs-node を使う Express サーバーの構成案

  • @tensorflow/tfjs-node と @teachablemachine/image を利用して、サーバー側でモデルを読み込む。
  • model.json ＋ metadata.json を Teachable Machine の tfjs エクスポートから取得。
  • POST /predict で画像を受け取り、tf.node.decodeImage などで Tensor に変換して推論。

APIの形は Python 版とほぼ同じにしておくと、クライアント側からは バックエンドの実装言語を意識せずに差し替えられる という利点があります。

11-2. Python版とNode版をどう使い分けるか

  • Python 版の強み

    • MLOps 系ライブラリとの相性が良く、サーバーサイドで追加の推論ロジック（前処理・後処理）を追加しやすい。
    • teachable-machine のような専用パッケージがある。

  • Node 版の強み

    • 既存の Node / TypeScript ベースのバックエンドと統合しやすい。
    • ブラウザとサーバーで同じ tfjs モデルをシェアできる。

n0bisuke さんのように M5Stack 周りのコードが Node（あるいは JavaScript 系）に寄っている場合は Node サーバーが扱いやすいですし、Python ベースのデータ基盤が揃っているなら Python 版が自然です。

12. AWS / クラウドへの展開と Amazon Q Developer の活用

ここまでローカル環境で動く API を作りましたが、実際には以下のようなクラウド構成に載せることが多いでしょう。

  • AWS Lambda + API Gateway
  • ECS Fargate + ALB
  • Cloud Run（GCP）など

12-1. Amazon Q Developer で「デプロイまわりの情報探索」を効率化する

Amazon Q Developer のハンズオン記事では、VS Code に拡張機能を入れた上で、MCP サーバーを通じて AWS 公式ドキュメントに直接アクセスする構成が紹介されています。

  • aws-documentation-mcp-server を uv で起動し、
  • Amazon Q Developer が「AWS Documentation API」に裏で問い合わせてくれるようにする

これを今回のケースに当てはめると、

「この FastAPI アプリを Lambda で動かしたい。
コンテナイメージでデプロイする場合のベストプラクティスを教えて」

のような質問を VS Code 上で投げると、

  • 必要な Dockerfile の雛形
  • Lambda + API Gateway の設定手順
  • CloudWatch Logs / X-Ray 連携の参考リンク

などを 公式ドキュメントを参照しながら 提示してくれる、という形になります。

12-2. セクション12の考察：開発支援AIも「エージェントの一種」

Amazon Q Developer のようなツールも、広い意味では

  • 「ユーザーの質問」
  • 「ツール（MCPサーバー）」
  • 「外部ドキュメント」

を仲介する エージェント と考えられます。

  • 我々が作った「画像判定API」は、画像という入力を受けてクラスラベルを返すエージェント。
  • 開発支援AIは、「自然言語の質問」を受けて、コードや設定手順を返すエージェント。

両者を組み合わせることで、

「AIが作るコード」＋「AIが支える開発・運用」＋「人間が握るQAと設計」

という三層構造が立ち上がります。

13. まとめ：Teachable Machine × API × Agents × QA

かなり盛りだくさんになりましたが、最後に要点を整理します。

  1. Teachable Machine は「ブラウザ上の教師付き学習工場」

    • 画像・音声・ポーズなどをGUIで学習し、TensorFlow.js / Keras / TFLite としてエクスポートできる。

  2. 現場の事例では「デバイス＋サーバー構成」が定番

    • TV版 YouTube 広告スキップデバイスのように、
      カメラデバイス → サーバーAPI → デバイス制御 という構成が多い。
    • LINE Bot から画像を送り、Teachable Machine モデルで資材名を返すような構想も同様。

  3. この記事では Python（FastAPI）＋ teachable-machine で画像判定APIを実装

    • POST /predict に画像を投げると、クラス名と信頼度を返す API を構築。
    • ラッパークラスを挟んで I/O を明確にすることで、後からモデルを差し替えやすくした。

  4. Agents を使ったデモで「スキップボタン検知→Aボタン押下」の流れをシミュレーション

    • CaptureAgent / InferenceAgent / ActionAgent の3役に分けることで、ロジックの責務が見えやすくなる。
    • 閾値やクールダウン、ログ設計が重要になる。

  5. QAの役割は「何を検証するか」「どこまで許容するか」を設計する方向にシフト

    • 生成AIがテストコード生成を助けてくれる一方で、テスト戦略や品質ルールは人間が設計する必要がある。

  6. 開発支援AI（Amazon Q Developerなど）もエージェントとして組み込むと効率的

    • デプロイや監視まわりの公式ドキュメントを IDE 内から引きながら、ML API のインフラ設計を進められる。

  7. Explainable / Teachable という観点を忘れずに

    • JuliaCon の「Explainable, teachable, ‘code golfed’ pi programs」のように、短くても説明可能なプログラムの価値が語られている。
    • 画像判定モデルでも、クラスごとの代表画像やハイライト可視化を用意することで、「なぜその判定なのか」をある程度説明できるようになる。

ここまで読んでいただき、ありがとうございます。

もし次に掘り下げるとしたら、

  • 「この FastAPI サーバーを AWS Lambda / ECS に載せる手順（Terraform 付き）」
  • 「Teachable Machine の retraining を含めた MLOps パイプライン」
  • 「画像判定APIのABテストとドリフト検知」

あたりが候補かなと思っています。

「この方向で続きを読みたい」「LINE Bot との接続部分をもっと詳しく」などあれば、ぜひお題として投げてください。
それでは、今日はこのへんで。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?