# GAOS相談窓口を開設

## 従兄に渡したAI端末、その先を考えて

前回、古いPCをAI端末として再利用し、従兄に使ってもらう話を書きました。GAOS Autoは、単にChatGPTが起動するPCを作ることが目的ではありません。

実際に使う人がいて、相談したり、必要な情報を受け取ったり、その内容を整理したり。

**AI端末として、外とのやり取りまで含めて使える形にしたい。**

そこで今回、そのための受け口として、

**「GAOS相談窓口」**

を開設しまし、AI端末の連絡用としました。

まだ有料サービスとして始めたものではありません。

まずは実際のやり取りの中で、

* どんな相談が来るのか

* どうやって資料を受け取るか

* AI側でどこまで対応できるか

* どこで人間の確認を入れるか

このあたりを確認するための窓口です。

そして、開設して間もなく、昔からの友人から実際の相談が入りました。

内容は、

**Raspberry Piを使って炉の異常を検知し、LINEへ通知する仕組み**

についてです。

思っていたより早く、GAOS相談窓口の実証が始まりました。

## 最初の相談はLINEから

最初の相談はLINEでした。

送られてきたのは、実際に動いている様子の動画。

動画を見れば、Raspberry Piを使っていること。

GPIO入力を監視していること。

異常信号を受けてLINEへ通知していること。

このくらいまでは分かります。

ただ、動画だけではプログラムの細かい処理までは確認できません。

そこで、「実際のPythonコードを見た方が早い」

ということになりました。

ここから、GAOS相談窓口の出番です。

## LINEからメールへ

相談自体はLINEで受けました。

ただ、ソースコードや資料をLINEだけでやり取りすると、後から管理しづらくなります。

そこで相談内容をGAOS相談窓口へ渡し、友人のメールアドレスを確認。

こちらから、

**Pythonコードを送ってもらうための案内メール**

を送信しました。

GAOS側からメールを送信し、相手側でも受信を確認。

その後、友人からPythonコードが返信されてきました。

この時の反応が、

**「スゲー」**

でした。

メールを送るという機能だけを見れば、特別珍しいものではありません。

・相談内容を受ける。

・必要な情報を判断する。

・相手に資料送付を依頼する。

・返信された資料を受け取る。

ここまでを一つの流れとして動かすと、少し意味が変わってきます。

単なるAIチャットではなく、

**AIを実際の業務フローの中へ組み込む**

という形になってきます。

## 受け取ったPythonコードを確認

返信されてきたPythonコードを確認しました。

構成は比較的シンプルです。

Raspberry PiのGPIOを監視し、異常信号が入ると処理を実行。

その中からLINE Messaging APIを利用して、異常通知を送信する仕組みでした。

試作としては分かりやすく、基本的な動作も成立しています。

一方で、実設備として継続して使うことを考えると、いくつか改善できそうな部分も見えてきます。

例えば、

* 認証情報をソースコードから分離する

* 通信失敗時の再送処理

* 異常発生日時や通信結果のログ保存

* Raspberry Pi起動時の自動起動

* 監視プログラムが正常に起動したことの通知

* 誤通知や連続通知への対策

こうした部分です。

コードそのものだけを見るなら、

「ここを直せばいい」

で終わります。

でも今回確認したかったのは、そこだけではありません。

## コードを直す前後まで含めて動かす

今回、実際に動いた流れは、

**相談受付

↓

内容確認

↓

不足している情報の判断

↓

コード送付依頼

↓

メールでコード受領

↓

コード解析

↓

問題点整理

↓

修正案作成**

ここまでです。

つまり、

**AIにコードを直してもらう**

という使い方ではなく、

**技術相談そのものをAI端末の業務フローへ組み込む**

ところまで確認できました。

これは、GAOS Autoでやりたかったことの一つです。

## 最終判断は人間

GAOSでは、

**AIに全部を任せる**

という考え方はしていません。

最終判断は人間です。

今回も、GAOS側で解析や修正案を作成しても、相手へ返却する前には私が承認します。

ただし、毎回ソースコードの全行、すべての変更内容を確認するのは現実的ではありません。

そこで今後は、

**承認用の概略報告**

を作る形にしていきます。

例えば、

・依頼内容

・確認した内容

・問題点

・修正した内容

・注意点

・未確認事項

・相手へ送付する内容

このあたりを簡潔にまとめます。

その概略報告を見て、

**この内容なら送付してよい**

と人間が最終判断する。

GAOSが詳細を確認し、人間は要点を確認する。

この役割分担が、実際の運用では良さそうです。

## 今回はココナラ経由ではありません

今回の相談相手は昔からの友人です。

そのため、

当然、ココナラでの販売実績でもありません。

今回はあくまで、

**実際の外部ユーザーを相手にした実証**

・実際に相談を受け

・動画を確認

・必要なコードを依頼

・メールで受領

・内容を解析

修正案を作れるところまで進める。

この一連の流れが実際に成立しました。

これは十分、実証実績として残せると思っています。

## 今後はココナラ向けにコンテンツ化

今回の実証で、

プログラム修正や小規模な技術相談であれば、GAOS相談窓口を使って対応できる感触がかなり出てきました。

例えば、

・Pythonプログラムの修正

・Raspberry Pi関連の相談

・既存プログラムの改善

・動かないコードの原因確認

・小規模な自動化

・組込み・制御周辺の技術相談

このあたりは、今後サービスとして形にできそうです。

ただ、すぐに出品するつもりはありません。

今回の流れを整理し、

・案件管理。

・承認方法。

・対応範囲。

・料金。

・責任分界。

・返却方法。

このあたりをもう少し整えます。

その上で、

今回の実証をベースに、ココナラ向け技術支援コンテンツとして育てる*

予定です。

## 売る前に、まず動かす

・まず試す。

・動かす。

・問題を出す。

・直す。

・もう一度確認する。

というやり方で仕事をしてきました。

今回も同じです。

いきなり、

「GAOS相談窓口というサービスを始めました」

ではありません。

・まず実際に使ってみる。

・どこで止まるのか。

・何が足りないのか。

・人間が確認する場所はどこなのか。

そこを確認してから商品にする。

AIだからといって、この順番は変わりません。

むしろAIだからこそ、

**実際の運用の中で確認することが大事**

だと思っています。

## 思っていたより早かった

正直なところ、

GAOS相談窓口が実際の技術相談まで使えるようになるのは、もう少し先だと思っていました。

ところが、窓口を作った直後に実際の相談が入り、

受付からコード受領、解析、修正案作成まで動きました。

まだ一件です。

副業として完成したわけでもありません。

**「こういうことが出来たらいい」**

と思っていたものが、

**「実際に出来た」**

へ変わりました。

少しずつでも実績感が出てくると、やっぱり嬉しいですね。

焦るつもりはありません。

まずは仕組みを整える。

そして実績を少しずつ積む。

その先で、

**GAOS相談窓口をココナラ提供できる技術支援サービスへ育てます。**

GAOS Auto。

少しずつですが、ただのAI端末から、

**実際に仕事を手伝う端末**

へ変わり始めています。