本ページはプロモーションが含まれています

【第10回】AI機嫌メーター(実装編③)：仏の顔も三度まで？ESP32でGASのリダイレクトを突破し、機嫌を描画せよ

AI機嫌メーター
2026.03.08

「クラウドに保存された数値は、まだただのデータだ。それを光とドットに変えて、現実世界へ引きずり出せ」

機嫌判定プロンプト、GASによる中継サーバー。準備は整った。最後にして最大の難関は、非力なマイコン「ESP32」で、Googleのセキュアな壁を越えて最新の機嫌スコアを取得することだ。

今回は、Wi-Fi通信の裏側と、受け取った数値で仏様の表情を切り替えるロジックを解説する。

[contents]

1. ESP32最大の難所：Googleのリダイレクトを追え

ESP32からGASにアクセスすると、Googleの仕様で「URLが変わったからあっち（別のサーバー）へ行け」という「HTTP 302リダイレクト」という命令が返ってくる。

多くの初心者向けライブラリはここで立ち往生してしまうが、今回のスケッチでは以下の力技でこれを突破している。流石AIだ。

  • 証明書スルー（Insecureモード）: ホビー用途と割り切り、SSL証明書の厳密な検証をスキップすることで、メモリ消費を抑えつつHTTPS通信を実現。
  • 手動リダイレクト解析: 302エラーが返ってきたら、レスポンスヘッダーから新しい移動先（Location）を抜き出し、再度そこへリクエストを投げる。
WiFiClientSecure client;
  // ホビー用途・検証用としてサーバー証明書の検証をスキップします
  // 本番環境や高セキュリティが必要な場合はルートCAを設定してください
  client.setInsecure();
// リダイレクトが発生した場合、新しいURLに再接続して取得
  if (isRedirect && location.length() > 0) {
    Serial.println("Redirecting to: " + location);
    
    // location文字列 (例: https://script.googleusercontent.com/macros/echo?...)
    // ホスト名とパスを抜き出す
    location.replace("https://", "");
    int slashIndex = location.indexOf('/');
    String newHost = location.substring(0, slashIndex);
    String newPath = location.substring(slashIndex);
    
    client.stop(); // 一旦切断
    
    // 再度接続
    client.setInsecure();
    if (!client.connect(newHost.c_str(), 443)) {
      Serial.println("Connection to redirect URL failed!");
      return -1;
    }
    
    client.print(String("GET ") + newPath + " HTTP/1.1\r\n" +
                 "Host: " + newHost + "\r\n" +
                 "Connection: close\r\n\r\n");
                 
    // HTTPヘッダを読み飛ばす
    while (client.connected()) {
      String line = client.readStringUntil('\n');
      if (line == "\r") {
        break; // ヘッダ終了
      }
    }

2. 数値を「仏の表情」に変換するスイッチ

GASから無事にAIの今現在の機嫌を数字を受け取ったら、次はそれを画像に変換する番だ。以前作成した「16進数配列（PROGMEM）」の出番である。

if文を使い、取得したスコアに応じて表示するドット絵データを切り替える。

  • 1〜20: display.drawBitmap() で「笑顔の仏」を描画
  • 81〜100: display.drawBitmap() で「憤怒の仏」を描画

わずか128×64ピクセルの世界に、AIの機嫌が命となって宿る瞬間だ。

3. ループ処理：AIの機嫌を定期監視

機嫌は常に変わる。スケッチでは delay(60000) などを使って、1分に1回（あるいは任意のタイミングで）GASを見に行くように設定した。

あまり頻繁に見に行くとGoogle側に怒られるし、遅すぎると私の失言に対するAIの怒りが反映されるのが遅れてしまう。この「呼吸の間隔」が、デバイスに生きた印象を与える。

【コラム：やりすぎ注意！通信間隔の「黄金比」】

システムが完成すると、つい数秒おきに最新の情報を取得したくなるものだ。しかし、無料枠で運用するこのシステムには、守るべき**「作法」**がある。タダで使わせてもらっている以上、最低限の礼儀（低頻度アクセス）は必要というわけだ。

1. Googleの「堪忍袋の緒」に触れない

今回使用しているGemini API（無料版）には、**「1分間に15リクエストまで」**という制限があります。4秒に1回以上のペースでアクセスすると、API側でエラーを吐き、システムが停止してしまうことになりかねない。

2. ESP32への負担を考える

今回のコードは、Google特有の「リダイレクト（302）」を力技で追いかける実装になっている。あまりに頻繁な通信は、非力なESP32に負荷をかけ、Wi-Fiチップの発熱や接続の不安定化を招きかねない。

3. 演出としての「1分」

チャットで言葉を投げかけ、少し間を置いてから仏の顔が変わる――。 この「1分間のラグ」が、むしろAIが思考し、感情を整理しているような**「生きたデバイス感」**を演出するのだ。

結び

ついに、すべてのシステムが繋がった。 チャットでの私の発言が、クラウドを駆け巡り、16進数の配列を経て、目の前の小さなディスプレイに映し出される。

「仏の顔も三度まで」と言うが、私のAIは何度まで許してくれるだろうか。

次回、「【最終回・運用編】AI機嫌メーター、稼働！私の日常は仏の微笑みで満たされるのか？」。 実際に運用してみた結果と、見えてきた課題について語りたい。

タイトルとURLをコピーしました